1This is gccint.info, produced by makeinfo version 6.5 from gccint.texi. 2 3Copyright (C) 1988-2019 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-2019 Free Software Foundation, Inc. 30 31 Permission is granted to copy, distribute and/or modify this document 32under the terms of the GNU Free Documentation License, Version 1.3 or 33any later version published by the Free Software Foundation; with the 34Invariant Sections being "Funding Free Software", the Front-Cover Texts 35being (a) (see below), and with the Back-Cover Texts being (b) (see 36below). A copy of the license is included in the section entitled "GNU 37Free Documentation License". 38 39 (a) The FSF's Front-Cover Text is: 40 41 A GNU Manual 42 43 (b) The FSF's Back-Cover Text is: 44 45 You have freedom to copy and modify this GNU Manual, like GNU software. 46Copies published by the Free Software Foundation raise funds for GNU 47development. 48 49 50File: gccint.info, Node: Top, Next: Contributing 51 52Introduction 53************ 54 55This manual documents the internals of the GNU compilers, including how 56to port them to new targets and some information about how to write 57front ends for new languages. It corresponds to the compilers (GCC) 58version 9.4.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* poly_int:: Representation of runtime sizes and offsets. 86* GENERIC:: Language-independent representation generated by Front Ends 87* GIMPLE:: Tuple representation used by Tree SSA optimizers 88* Tree SSA:: Analysis and optimization of GIMPLE 89* RTL:: Machine-dependent low-level intermediate representation. 90* Control Flow:: Maintaining and manipulating the control flow graph. 91* Loop Analysis and Representation:: Analysis and representation of loops 92* Machine Desc:: How to write machine description instruction patterns. 93* Target Macros:: How to write the machine description C macros and functions. 94* Host Config:: Writing the 'xm-MACHINE.h' file. 95* Fragments:: Writing the 't-TARGET' and 'x-HOST' files. 96* Collect2:: How 'collect2' works; how it finds 'ld'. 97* Header Dirs:: Understanding the standard header file directories. 98* Type Information:: GCC's memory management; generating type information. 99* Plugins:: Extending the compiler with plugins. 100* LTO:: Using Link-Time Optimization. 101 102* Match and Simplify:: How to write expression simplification patterns for GIMPLE and GENERIC 103* User Experience Guidelines:: Guidelines for implementing diagnostics and options. 104* Funding:: How to help assure funding for free software. 105* GNU Project:: The GNU Project and GNU/Linux. 106 107* Copying:: GNU General Public License says 108 how you can copy and share GCC. 109* GNU Free Documentation License:: How you can copy and share this manual. 110* Contributors:: People who have contributed to GCC. 111 112* Option Index:: Index to command line options. 113* Concept Index:: Index of concepts and symbol names. 114 115 116File: gccint.info, Node: Contributing, Next: Portability, Up: Top 117 1181 Contributing to GCC Development 119********************************* 120 121If you would like to help pretest GCC releases to assure they work well, 122current development sources are available via Git (see 123<http://gcc.gnu.org/git.html>). Source and binary snapshots are also 124available for FTP; see <http://gcc.gnu.org/snapshots.html>. 125 126 If you would like to work on improvements to GCC, please read the 127advice at these URLs: 128 129 <http://gcc.gnu.org/contribute.html> 130 <http://gcc.gnu.org/contributewhy.html> 131 132for information on how to make useful contributions and avoid 133duplication of effort. Suggested projects are listed at 134<http://gcc.gnu.org/projects/>. 135 136 137File: gccint.info, Node: Portability, Next: Interface, Prev: Contributing, Up: Top 138 1392 GCC and Portability 140********************* 141 142GCC itself aims to be portable to any machine where 'int' is at least a 14332-bit type. It aims to target machines with a flat (non-segmented) 144byte addressed data address space (the code address space can be 145separate). Target ABIs may have 8, 16, 32 or 64-bit 'int' type. 'char' 146can be wider than 8 bits. 147 148 GCC gets most of the information about the target machine from a 149machine description which gives an algebraic formula for each of the 150machine's instructions. This is a very clean way to describe the 151target. But when the compiler needs information that is difficult to 152express in this fashion, ad-hoc parameters have been defined for machine 153descriptions. The purpose of portability is to reduce the total work 154needed on the compiler; it was not of interest for its own sake. 155 156 GCC does not contain machine dependent code, but it does contain code 157that depends on machine parameters such as endianness (whether the most 158significant byte has the highest or lowest address of the bytes in a 159word) and the availability of autoincrement addressing. In the 160RTL-generation pass, it is often necessary to have multiple strategies 161for generating code for a particular kind of syntax tree, strategies 162that are usable for different combinations of parameters. Often, not 163all possible cases have been addressed, but only the common ones or only 164the ones that have been encountered. As a result, a new target may 165require additional strategies. You will know if this happens because 166the compiler will call 'abort'. Fortunately, the new strategies can be 167added in a machine-independent fashion, and will affect only the target 168machines that need them. 169 170 171File: gccint.info, Node: Interface, Next: Libgcc, Prev: Portability, Up: Top 172 1733 Interfacing to GCC Output 174*************************** 175 176GCC is normally configured to use the same function calling convention 177normally in use on the target system. This is done with the 178machine-description macros described (*note Target Macros::). 179 180 However, returning of structure and union values is done differently on 181some target machines. As a result, functions compiled with PCC 182returning such types cannot be called from code compiled with GCC, and 183vice versa. This does not cause trouble often because few Unix library 184routines return structures or unions. 185 186 GCC code returns structures and unions that are 1, 2, 4 or 8 bytes long 187in the same registers used for 'int' or 'double' return values. (GCC 188typically allocates variables of such types in registers also.) 189Structures and unions of other sizes are returned by storing them into 190an address passed by the caller (usually in a register). The target 191hook 'TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address. 192 193 By contrast, PCC on most target machines returns structures and unions 194of any size by copying the data into an area of static storage, and then 195returning the address of that storage as if it were a pointer value. 196The caller must copy the data from that memory area to the place where 197the value is wanted. This is slower than the method used by GCC, and 198fails to be reentrant. 199 200 On some target machines, such as RISC machines and the 80386, the 201standard system convention is to pass to the subroutine the address of 202where to return the value. On these machines, GCC has been configured 203to be compatible with the standard compiler, when this method is used. 204It may not be compatible for structures of 1, 2, 4 or 8 bytes. 205 206 GCC uses the system's standard convention for passing arguments. On 207some machines, the first few arguments are passed in registers; in 208others, all are passed on the stack. It would be possible to use 209registers for argument passing on any machine, and this would probably 210result in a significant speedup. But the result would be complete 211incompatibility with code that follows the standard convention. So this 212change is practical only if you are switching to GCC as the sole C 213compiler for the system. We may implement register argument passing on 214certain machines once we have a complete GNU system so that we can 215compile the libraries with GCC. 216 217 On some machines (particularly the SPARC), certain types of arguments 218are passed "by invisible reference". This means that the value is 219stored in memory, and the address of the memory location is passed to 220the subroutine. 221 222 If you use 'longjmp', beware of automatic variables. ISO C says that 223automatic variables that are not declared 'volatile' have undefined 224values after a 'longjmp'. And this is all GCC promises to do, because 225it is very difficult to restore register variables correctly, and one of 226GCC's features is that it can put variables in registers without your 227asking it to. 228 229 230File: gccint.info, Node: Libgcc, Next: Languages, Prev: Interface, Up: Top 231 2324 The GCC low-level runtime library 233*********************************** 234 235GCC provides a low-level runtime library, 'libgcc.a' or 'libgcc_s.so.1' 236on some platforms. GCC generates calls to routines in this library 237automatically, whenever it needs to perform some operation that is too 238complicated to emit inline code for. 239 240 Most of the routines in 'libgcc' handle arithmetic operations that the 241target processor cannot perform directly. This includes integer 242multiply and divide on some machines, and all floating-point and 243fixed-point operations on other machines. 'libgcc' also includes 244routines for exception handling, and a handful of miscellaneous 245operations. 246 247 Some of these routines can be defined in mostly machine-independent C. 248Others must be hand-written in assembly language for each processor that 249needs them. 250 251 GCC will also generate calls to C library routines, such as 'memcpy' 252and 'memset', in some cases. The set of routines that GCC may possibly 253use is documented in *note (gcc)Other Builtins::. 254 255 These routines take arguments and return values of a specific machine 256mode, not a specific C type. *Note Machine Modes::, for an explanation 257of this concept. For illustrative purposes, in this chapter the 258floating point type 'float' is assumed to correspond to 'SFmode'; 259'double' to 'DFmode'; and 'long double' to both 'TFmode' and 'XFmode'. 260Similarly, the integer types 'int' and 'unsigned int' correspond to 261'SImode'; 'long' and 'unsigned long' to 'DImode'; and 'long long' and 262'unsigned long long' to 'TImode'. 263 264* Menu: 265 266* Integer library routines:: 267* Soft float library routines:: 268* Decimal float library routines:: 269* Fixed-point fractional library routines:: 270* Exception handling routines:: 271* Miscellaneous routines:: 272 273 274File: gccint.info, Node: Integer library routines, Next: Soft float library routines, Up: Libgcc 275 2764.1 Routines for integer arithmetic 277=================================== 278 279The integer arithmetic routines are used on platforms that don't provide 280hardware support for arithmetic operations on some modes. 281 2824.1.1 Arithmetic functions 283-------------------------- 284 285 -- Runtime Function: int __ashlsi3 (int A, int B) 286 -- Runtime Function: long __ashldi3 (long A, int B) 287 -- Runtime Function: long long __ashlti3 (long long A, int B) 288 These functions return the result of shifting A left by B bits. 289 290 -- Runtime Function: int __ashrsi3 (int A, int B) 291 -- Runtime Function: long __ashrdi3 (long A, int B) 292 -- Runtime Function: long long __ashrti3 (long long A, int B) 293 These functions return the result of arithmetically shifting A 294 right by B bits. 295 296 -- Runtime Function: int __divsi3 (int A, int B) 297 -- Runtime Function: long __divdi3 (long A, long B) 298 -- Runtime Function: long long __divti3 (long long A, long long B) 299 These functions return the quotient of the signed division of A and 300 B. 301 302 -- Runtime Function: int __lshrsi3 (int A, int B) 303 -- Runtime Function: long __lshrdi3 (long A, int B) 304 -- Runtime Function: long long __lshrti3 (long long A, int B) 305 These functions return the result of logically shifting A right by 306 B bits. 307 308 -- Runtime Function: int __modsi3 (int A, int B) 309 -- Runtime Function: long __moddi3 (long A, long B) 310 -- Runtime Function: long long __modti3 (long long A, long long B) 311 These functions return the remainder of the signed division of A 312 and B. 313 314 -- Runtime Function: int __mulsi3 (int A, int B) 315 -- Runtime Function: long __muldi3 (long A, long B) 316 -- Runtime Function: long long __multi3 (long long A, long long B) 317 These functions return the product of A and B. 318 319 -- Runtime Function: long __negdi2 (long A) 320 -- Runtime Function: long long __negti2 (long long A) 321 These functions return the negation of A. 322 323 -- Runtime Function: unsigned int __udivsi3 (unsigned int A, unsigned 324 int B) 325 -- Runtime Function: unsigned long __udivdi3 (unsigned long A, unsigned 326 long B) 327 -- Runtime Function: unsigned long long __udivti3 (unsigned long long 328 A, unsigned long long B) 329 These functions return the quotient of the unsigned division of A 330 and B. 331 332 -- Runtime Function: unsigned long __udivmoddi4 (unsigned long A, 333 unsigned long B, unsigned long *C) 334 -- Runtime Function: unsigned long long __udivmodti4 (unsigned long 335 long A, unsigned long long B, unsigned long long *C) 336 These functions calculate both the quotient and remainder of the 337 unsigned division of A and B. The return value is the quotient, 338 and the remainder is placed in variable pointed to by C. 339 340 -- Runtime Function: unsigned int __umodsi3 (unsigned int A, unsigned 341 int B) 342 -- Runtime Function: unsigned long __umoddi3 (unsigned long A, unsigned 343 long B) 344 -- Runtime Function: unsigned long long __umodti3 (unsigned long long 345 A, unsigned long long B) 346 These functions return the remainder of the unsigned division of A 347 and B. 348 3494.1.2 Comparison functions 350-------------------------- 351 352The following functions implement integral comparisons. These functions 353implement a low-level compare, upon which the higher level comparison 354operators (such as less than and greater than or equal to) can be 355constructed. The returned values lie in the range zero to two, to allow 356the high-level operators to be implemented by testing the returned 357result using either signed or unsigned comparison. 358 359 -- Runtime Function: int __cmpdi2 (long A, long B) 360 -- Runtime Function: int __cmpti2 (long long A, long long B) 361 These functions perform a signed comparison of A and B. If A is 362 less than B, they return 0; if A is greater than B, they return 2; 363 and if A and B are equal they return 1. 364 365 -- Runtime Function: int __ucmpdi2 (unsigned long A, unsigned long B) 366 -- Runtime Function: int __ucmpti2 (unsigned long long A, unsigned long 367 long B) 368 These functions perform an unsigned comparison of A and B. If A is 369 less than B, they return 0; if A is greater than B, they return 2; 370 and if A and B are equal they return 1. 371 3724.1.3 Trapping arithmetic functions 373----------------------------------- 374 375The following functions implement trapping arithmetic. These functions 376call the libc function 'abort' upon signed arithmetic overflow. 377 378 -- Runtime Function: int __absvsi2 (int A) 379 -- Runtime Function: long __absvdi2 (long A) 380 These functions return the absolute value of A. 381 382 -- Runtime Function: int __addvsi3 (int A, int B) 383 -- Runtime Function: long __addvdi3 (long A, long B) 384 These functions return the sum of A and B; that is 'A + B'. 385 386 -- Runtime Function: int __mulvsi3 (int A, int B) 387 -- Runtime Function: long __mulvdi3 (long A, long B) 388 The functions return the product of A and B; that is 'A * B'. 389 390 -- Runtime Function: int __negvsi2 (int A) 391 -- Runtime Function: long __negvdi2 (long A) 392 These functions return the negation of A; that is '-A'. 393 394 -- Runtime Function: int __subvsi3 (int A, int B) 395 -- Runtime Function: long __subvdi3 (long A, long B) 396 These functions return the difference between B and A; that is 'A - 397 B'. 398 3994.1.4 Bit operations 400-------------------- 401 402 -- Runtime Function: int __clzsi2 (unsigned int A) 403 -- Runtime Function: int __clzdi2 (unsigned long A) 404 -- Runtime Function: int __clzti2 (unsigned long long A) 405 These functions return the number of leading 0-bits in A, starting 406 at the most significant bit position. If A is zero, the result is 407 undefined. 408 409 -- Runtime Function: int __ctzsi2 (unsigned int A) 410 -- Runtime Function: int __ctzdi2 (unsigned long A) 411 -- Runtime Function: int __ctzti2 (unsigned long long A) 412 These functions return the number of trailing 0-bits in A, starting 413 at the least significant bit position. If A is zero, the result is 414 undefined. 415 416 -- Runtime Function: int __ffsdi2 (unsigned long A) 417 -- Runtime Function: int __ffsti2 (unsigned long long A) 418 These functions return the index of the least significant 1-bit in 419 A, or the value zero if A is zero. The least significant bit is 420 index one. 421 422 -- Runtime Function: int __paritysi2 (unsigned int A) 423 -- Runtime Function: int __paritydi2 (unsigned long A) 424 -- Runtime Function: int __parityti2 (unsigned long long A) 425 These functions return the value zero if the number of bits set in 426 A is even, and the value one otherwise. 427 428 -- Runtime Function: int __popcountsi2 (unsigned int A) 429 -- Runtime Function: int __popcountdi2 (unsigned long A) 430 -- Runtime Function: int __popcountti2 (unsigned long long A) 431 These functions return the number of bits set in A. 432 433 -- Runtime Function: int32_t __bswapsi2 (int32_t A) 434 -- Runtime Function: int64_t __bswapdi2 (int64_t A) 435 These functions return the A byteswapped. 436 437 438File: gccint.info, Node: Soft float library routines, Next: Decimal float library routines, Prev: Integer library routines, Up: Libgcc 439 4404.2 Routines for floating point emulation 441========================================= 442 443The software floating point library is used on machines which do not 444have hardware support for floating point. It is also used whenever 445'-msoft-float' is used to disable generation of floating point 446instructions. (Not all targets support this switch.) 447 448 For compatibility with other compilers, the floating point emulation 449routines can be renamed with the 'DECLARE_LIBRARY_RENAMES' macro (*note 450Library Calls::). In this section, the default names are used. 451 452 Presently the library does not support 'XFmode', which is used for 453'long double' on some architectures. 454 4554.2.1 Arithmetic functions 456-------------------------- 457 458 -- Runtime Function: float __addsf3 (float A, float B) 459 -- Runtime Function: double __adddf3 (double A, double B) 460 -- Runtime Function: long double __addtf3 (long double A, long double 461 B) 462 -- Runtime Function: long double __addxf3 (long double A, long double 463 B) 464 These functions return the sum of A and B. 465 466 -- Runtime Function: float __subsf3 (float A, float B) 467 -- Runtime Function: double __subdf3 (double A, double B) 468 -- Runtime Function: long double __subtf3 (long double A, long double 469 B) 470 -- Runtime Function: long double __subxf3 (long double A, long double 471 B) 472 These functions return the difference between B and A; that is, 473 A - B. 474 475 -- Runtime Function: float __mulsf3 (float A, float B) 476 -- Runtime Function: double __muldf3 (double A, double B) 477 -- Runtime Function: long double __multf3 (long double A, long double 478 B) 479 -- Runtime Function: long double __mulxf3 (long double A, long double 480 B) 481 These functions return the product of A and B. 482 483 -- Runtime Function: float __divsf3 (float A, float B) 484 -- Runtime Function: double __divdf3 (double A, double B) 485 -- Runtime Function: long double __divtf3 (long double A, long double 486 B) 487 -- Runtime Function: long double __divxf3 (long double A, long double 488 B) 489 These functions return the quotient of A and B; that is, A / B. 490 491 -- Runtime Function: float __negsf2 (float A) 492 -- Runtime Function: double __negdf2 (double A) 493 -- Runtime Function: long double __negtf2 (long double A) 494 -- Runtime Function: long double __negxf2 (long double A) 495 These functions return the negation of A. They simply flip the 496 sign bit, so they can produce negative zero and negative NaN. 497 4984.2.2 Conversion functions 499-------------------------- 500 501 -- Runtime Function: double __extendsfdf2 (float A) 502 -- Runtime Function: long double __extendsftf2 (float A) 503 -- Runtime Function: long double __extendsfxf2 (float A) 504 -- Runtime Function: long double __extenddftf2 (double A) 505 -- Runtime Function: long double __extenddfxf2 (double A) 506 These functions extend A to the wider mode of their return type. 507 508 -- Runtime Function: double __truncxfdf2 (long double A) 509 -- Runtime Function: double __trunctfdf2 (long double A) 510 -- Runtime Function: float __truncxfsf2 (long double A) 511 -- Runtime Function: float __trunctfsf2 (long double A) 512 -- Runtime Function: float __truncdfsf2 (double A) 513 These functions truncate A to the narrower mode of their return 514 type, rounding toward zero. 515 516 -- Runtime Function: int __fixsfsi (float A) 517 -- Runtime Function: int __fixdfsi (double A) 518 -- Runtime Function: int __fixtfsi (long double A) 519 -- Runtime Function: int __fixxfsi (long double A) 520 These functions convert A to a signed integer, rounding toward 521 zero. 522 523 -- Runtime Function: long __fixsfdi (float A) 524 -- Runtime Function: long __fixdfdi (double A) 525 -- Runtime Function: long __fixtfdi (long double A) 526 -- Runtime Function: long __fixxfdi (long double A) 527 These functions convert A to a signed long, rounding toward zero. 528 529 -- Runtime Function: long long __fixsfti (float A) 530 -- Runtime Function: long long __fixdfti (double A) 531 -- Runtime Function: long long __fixtfti (long double A) 532 -- Runtime Function: long long __fixxfti (long double A) 533 These functions convert A to a signed long long, rounding toward 534 zero. 535 536 -- Runtime Function: unsigned int __fixunssfsi (float A) 537 -- Runtime Function: unsigned int __fixunsdfsi (double A) 538 -- Runtime Function: unsigned int __fixunstfsi (long double A) 539 -- Runtime Function: unsigned int __fixunsxfsi (long double A) 540 These functions convert A to an unsigned integer, rounding toward 541 zero. Negative values all become zero. 542 543 -- Runtime Function: unsigned long __fixunssfdi (float A) 544 -- Runtime Function: unsigned long __fixunsdfdi (double A) 545 -- Runtime Function: unsigned long __fixunstfdi (long double A) 546 -- Runtime Function: unsigned long __fixunsxfdi (long double A) 547 These functions convert A to an unsigned long, rounding toward 548 zero. Negative values all become zero. 549 550 -- Runtime Function: unsigned long long __fixunssfti (float A) 551 -- Runtime Function: unsigned long long __fixunsdfti (double A) 552 -- Runtime Function: unsigned long long __fixunstfti (long double A) 553 -- Runtime Function: unsigned long long __fixunsxfti (long double A) 554 These functions convert A to an unsigned long long, rounding toward 555 zero. Negative values all become zero. 556 557 -- Runtime Function: float __floatsisf (int I) 558 -- Runtime Function: double __floatsidf (int I) 559 -- Runtime Function: long double __floatsitf (int I) 560 -- Runtime Function: long double __floatsixf (int I) 561 These functions convert I, a signed integer, to floating point. 562 563 -- Runtime Function: float __floatdisf (long I) 564 -- Runtime Function: double __floatdidf (long I) 565 -- Runtime Function: long double __floatditf (long I) 566 -- Runtime Function: long double __floatdixf (long I) 567 These functions convert I, a signed long, to floating point. 568 569 -- Runtime Function: float __floattisf (long long I) 570 -- Runtime Function: double __floattidf (long long I) 571 -- Runtime Function: long double __floattitf (long long I) 572 -- Runtime Function: long double __floattixf (long long I) 573 These functions convert I, a signed long long, to floating point. 574 575 -- Runtime Function: float __floatunsisf (unsigned int I) 576 -- Runtime Function: double __floatunsidf (unsigned int I) 577 -- Runtime Function: long double __floatunsitf (unsigned int I) 578 -- Runtime Function: long double __floatunsixf (unsigned int I) 579 These functions convert I, an unsigned integer, to floating point. 580 581 -- Runtime Function: float __floatundisf (unsigned long I) 582 -- Runtime Function: double __floatundidf (unsigned long I) 583 -- Runtime Function: long double __floatunditf (unsigned long I) 584 -- Runtime Function: long double __floatundixf (unsigned long I) 585 These functions convert I, an unsigned long, to floating point. 586 587 -- Runtime Function: float __floatuntisf (unsigned long long I) 588 -- Runtime Function: double __floatuntidf (unsigned long long I) 589 -- Runtime Function: long double __floatuntitf (unsigned long long I) 590 -- Runtime Function: long double __floatuntixf (unsigned long long I) 591 These functions convert I, an unsigned long long, to floating 592 point. 593 5944.2.3 Comparison functions 595-------------------------- 596 597There are two sets of basic comparison functions. 598 599 -- Runtime Function: int __cmpsf2 (float A, float B) 600 -- Runtime Function: int __cmpdf2 (double A, double B) 601 -- Runtime Function: int __cmptf2 (long double A, long double B) 602 These functions calculate a <=> b. That is, if A is less than B, 603 they return -1; if A is greater than B, they return 1; and if A and 604 B are equal they return 0. If either argument is NaN they return 605 1, but you should not rely on this; if NaN is a possibility, use 606 one of the higher-level comparison functions. 607 608 -- Runtime Function: int __unordsf2 (float A, float B) 609 -- Runtime Function: int __unorddf2 (double A, double B) 610 -- Runtime Function: int __unordtf2 (long double A, long double B) 611 These functions return a nonzero value if either argument is NaN, 612 otherwise 0. 613 614 There is also a complete group of higher level functions which 615correspond directly to comparison operators. They implement the ISO C 616semantics for floating-point comparisons, taking NaN into account. Pay 617careful attention to the return values defined for each set. Under the 618hood, all of these routines are implemented as 619 620 if (__unordXf2 (a, b)) 621 return E; 622 return __cmpXf2 (a, b); 623 624where E is a constant chosen to give the proper behavior for NaN. Thus, 625the meaning of the return value is different for each set. Do not rely 626on this implementation; only the semantics documented below are 627guaranteed. 628 629 -- Runtime Function: int __eqsf2 (float A, float B) 630 -- Runtime Function: int __eqdf2 (double A, double B) 631 -- Runtime Function: int __eqtf2 (long double A, long double B) 632 These functions return zero if neither argument is NaN, and A and B 633 are equal. 634 635 -- Runtime Function: int __nesf2 (float A, float B) 636 -- Runtime Function: int __nedf2 (double A, double B) 637 -- Runtime Function: int __netf2 (long double A, long double B) 638 These functions return a nonzero value if either argument is NaN, 639 or if A and B are unequal. 640 641 -- Runtime Function: int __gesf2 (float A, float B) 642 -- Runtime Function: int __gedf2 (double A, double B) 643 -- Runtime Function: int __getf2 (long double A, long double B) 644 These functions return a value greater than or equal to zero if 645 neither argument is NaN, and A is greater than or equal to B. 646 647 -- Runtime Function: int __ltsf2 (float A, float B) 648 -- Runtime Function: int __ltdf2 (double A, double B) 649 -- Runtime Function: int __lttf2 (long double A, long double B) 650 These functions return a value less than zero if neither argument 651 is NaN, and A is strictly less than B. 652 653 -- Runtime Function: int __lesf2 (float A, float B) 654 -- Runtime Function: int __ledf2 (double A, double B) 655 -- Runtime Function: int __letf2 (long double A, long double B) 656 These functions return a value less than or equal to zero if 657 neither argument is NaN, and A is less than or equal to B. 658 659 -- Runtime Function: int __gtsf2 (float A, float B) 660 -- Runtime Function: int __gtdf2 (double A, double B) 661 -- Runtime Function: int __gttf2 (long double A, long double B) 662 These functions return a value greater than zero if neither 663 argument is NaN, and A is strictly greater than B. 664 6654.2.4 Other floating-point functions 666------------------------------------ 667 668 -- Runtime Function: float __powisf2 (float A, int B) 669 -- Runtime Function: double __powidf2 (double A, int B) 670 -- Runtime Function: long double __powitf2 (long double A, int B) 671 -- Runtime Function: long double __powixf2 (long double A, int B) 672 These functions convert raise A to the power B. 673 674 -- Runtime Function: complex float __mulsc3 (float A, float B, float C, 675 float D) 676 -- Runtime Function: complex double __muldc3 (double A, double B, 677 double C, double D) 678 -- Runtime Function: complex long double __multc3 (long double A, long 679 double B, long double C, long double D) 680 -- Runtime Function: complex long double __mulxc3 (long double A, long 681 double B, long double C, long double D) 682 These functions return the product of A + iB and C + iD, following 683 the rules of C99 Annex G. 684 685 -- Runtime Function: complex float __divsc3 (float A, float B, float C, 686 float D) 687 -- Runtime Function: complex double __divdc3 (double A, double B, 688 double C, double D) 689 -- Runtime Function: complex long double __divtc3 (long double A, long 690 double B, long double C, long double D) 691 -- Runtime Function: complex long double __divxc3 (long double A, long 692 double B, long double C, long double D) 693 These functions return the quotient of A + iB and C + iD (i.e., (A 694 + iB) / (C + iD)), following the rules of C99 Annex G. 695 696 697File: gccint.info, Node: Decimal float library routines, Next: Fixed-point fractional library routines, Prev: Soft float library routines, Up: Libgcc 698 6994.3 Routines for decimal floating point emulation 700================================================= 701 702The software decimal floating point library implements IEEE 754-2008 703decimal floating point arithmetic and is only activated on selected 704targets. 705 706 The software decimal floating point library supports either DPD 707(Densely Packed Decimal) or BID (Binary Integer Decimal) encoding as 708selected at configure time. 709 7104.3.1 Arithmetic functions 711-------------------------- 712 713 -- Runtime Function: _Decimal32 __dpd_addsd3 (_Decimal32 A, _Decimal32 714 B) 715 -- Runtime Function: _Decimal32 __bid_addsd3 (_Decimal32 A, _Decimal32 716 B) 717 -- Runtime Function: _Decimal64 __dpd_adddd3 (_Decimal64 A, _Decimal64 718 B) 719 -- Runtime Function: _Decimal64 __bid_adddd3 (_Decimal64 A, _Decimal64 720 B) 721 -- Runtime Function: _Decimal128 __dpd_addtd3 (_Decimal128 A, 722 _Decimal128 B) 723 -- Runtime Function: _Decimal128 __bid_addtd3 (_Decimal128 A, 724 _Decimal128 B) 725 These functions return the sum of A and B. 726 727 -- Runtime Function: _Decimal32 __dpd_subsd3 (_Decimal32 A, _Decimal32 728 B) 729 -- Runtime Function: _Decimal32 __bid_subsd3 (_Decimal32 A, _Decimal32 730 B) 731 -- Runtime Function: _Decimal64 __dpd_subdd3 (_Decimal64 A, _Decimal64 732 B) 733 -- Runtime Function: _Decimal64 __bid_subdd3 (_Decimal64 A, _Decimal64 734 B) 735 -- Runtime Function: _Decimal128 __dpd_subtd3 (_Decimal128 A, 736 _Decimal128 B) 737 -- Runtime Function: _Decimal128 __bid_subtd3 (_Decimal128 A, 738 _Decimal128 B) 739 These functions return the difference between B and A; that is, 740 A - B. 741 742 -- Runtime Function: _Decimal32 __dpd_mulsd3 (_Decimal32 A, _Decimal32 743 B) 744 -- Runtime Function: _Decimal32 __bid_mulsd3 (_Decimal32 A, _Decimal32 745 B) 746 -- Runtime Function: _Decimal64 __dpd_muldd3 (_Decimal64 A, _Decimal64 747 B) 748 -- Runtime Function: _Decimal64 __bid_muldd3 (_Decimal64 A, _Decimal64 749 B) 750 -- Runtime Function: _Decimal128 __dpd_multd3 (_Decimal128 A, 751 _Decimal128 B) 752 -- Runtime Function: _Decimal128 __bid_multd3 (_Decimal128 A, 753 _Decimal128 B) 754 These functions return the product of A and B. 755 756 -- Runtime Function: _Decimal32 __dpd_divsd3 (_Decimal32 A, _Decimal32 757 B) 758 -- Runtime Function: _Decimal32 __bid_divsd3 (_Decimal32 A, _Decimal32 759 B) 760 -- Runtime Function: _Decimal64 __dpd_divdd3 (_Decimal64 A, _Decimal64 761 B) 762 -- Runtime Function: _Decimal64 __bid_divdd3 (_Decimal64 A, _Decimal64 763 B) 764 -- Runtime Function: _Decimal128 __dpd_divtd3 (_Decimal128 A, 765 _Decimal128 B) 766 -- Runtime Function: _Decimal128 __bid_divtd3 (_Decimal128 A, 767 _Decimal128 B) 768 These functions return the quotient of A and B; that is, A / B. 769 770 -- Runtime Function: _Decimal32 __dpd_negsd2 (_Decimal32 A) 771 -- Runtime Function: _Decimal32 __bid_negsd2 (_Decimal32 A) 772 -- Runtime Function: _Decimal64 __dpd_negdd2 (_Decimal64 A) 773 -- Runtime Function: _Decimal64 __bid_negdd2 (_Decimal64 A) 774 -- Runtime Function: _Decimal128 __dpd_negtd2 (_Decimal128 A) 775 -- Runtime Function: _Decimal128 __bid_negtd2 (_Decimal128 A) 776 These functions return the negation of A. They simply flip the 777 sign bit, so they can produce negative zero and negative NaN. 778 7794.3.2 Conversion functions 780-------------------------- 781 782 -- Runtime Function: _Decimal64 __dpd_extendsddd2 (_Decimal32 A) 783 -- Runtime Function: _Decimal64 __bid_extendsddd2 (_Decimal32 A) 784 -- Runtime Function: _Decimal128 __dpd_extendsdtd2 (_Decimal32 A) 785 -- Runtime Function: _Decimal128 __bid_extendsdtd2 (_Decimal32 A) 786 -- Runtime Function: _Decimal128 __dpd_extendddtd2 (_Decimal64 A) 787 -- Runtime Function: _Decimal128 __bid_extendddtd2 (_Decimal64 A) 788 -- Runtime Function: _Decimal32 __dpd_truncddsd2 (_Decimal64 A) 789 -- Runtime Function: _Decimal32 __bid_truncddsd2 (_Decimal64 A) 790 -- Runtime Function: _Decimal32 __dpd_trunctdsd2 (_Decimal128 A) 791 -- Runtime Function: _Decimal32 __bid_trunctdsd2 (_Decimal128 A) 792 -- Runtime Function: _Decimal64 __dpd_trunctddd2 (_Decimal128 A) 793 -- Runtime Function: _Decimal64 __bid_trunctddd2 (_Decimal128 A) 794 These functions convert the value A from one decimal floating type 795 to another. 796 797 -- Runtime Function: _Decimal64 __dpd_extendsfdd (float A) 798 -- Runtime Function: _Decimal64 __bid_extendsfdd (float A) 799 -- Runtime Function: _Decimal128 __dpd_extendsftd (float A) 800 -- Runtime Function: _Decimal128 __bid_extendsftd (float A) 801 -- Runtime Function: _Decimal128 __dpd_extenddftd (double A) 802 -- Runtime Function: _Decimal128 __bid_extenddftd (double A) 803 -- Runtime Function: _Decimal128 __dpd_extendxftd (long double A) 804 -- Runtime Function: _Decimal128 __bid_extendxftd (long double A) 805 -- Runtime Function: _Decimal32 __dpd_truncdfsd (double A) 806 -- Runtime Function: _Decimal32 __bid_truncdfsd (double A) 807 -- Runtime Function: _Decimal32 __dpd_truncxfsd (long double A) 808 -- Runtime Function: _Decimal32 __bid_truncxfsd (long double A) 809 -- Runtime Function: _Decimal32 __dpd_trunctfsd (long double A) 810 -- Runtime Function: _Decimal32 __bid_trunctfsd (long double A) 811 -- Runtime Function: _Decimal64 __dpd_truncxfdd (long double A) 812 -- Runtime Function: _Decimal64 __bid_truncxfdd (long double A) 813 -- Runtime Function: _Decimal64 __dpd_trunctfdd (long double A) 814 -- Runtime Function: _Decimal64 __bid_trunctfdd (long double A) 815 These functions convert the value of A from a binary floating type 816 to a decimal floating type of a different size. 817 818 -- Runtime Function: float __dpd_truncddsf (_Decimal64 A) 819 -- Runtime Function: float __bid_truncddsf (_Decimal64 A) 820 -- Runtime Function: float __dpd_trunctdsf (_Decimal128 A) 821 -- Runtime Function: float __bid_trunctdsf (_Decimal128 A) 822 -- Runtime Function: double __dpd_extendsddf (_Decimal32 A) 823 -- Runtime Function: double __bid_extendsddf (_Decimal32 A) 824 -- Runtime Function: double __dpd_trunctddf (_Decimal128 A) 825 -- Runtime Function: double __bid_trunctddf (_Decimal128 A) 826 -- Runtime Function: long double __dpd_extendsdxf (_Decimal32 A) 827 -- Runtime Function: long double __bid_extendsdxf (_Decimal32 A) 828 -- Runtime Function: long double __dpd_extendddxf (_Decimal64 A) 829 -- Runtime Function: long double __bid_extendddxf (_Decimal64 A) 830 -- Runtime Function: long double __dpd_trunctdxf (_Decimal128 A) 831 -- Runtime Function: long double __bid_trunctdxf (_Decimal128 A) 832 -- Runtime Function: long double __dpd_extendsdtf (_Decimal32 A) 833 -- Runtime Function: long double __bid_extendsdtf (_Decimal32 A) 834 -- Runtime Function: long double __dpd_extendddtf (_Decimal64 A) 835 -- Runtime Function: long double __bid_extendddtf (_Decimal64 A) 836 These functions convert the value of A from a decimal floating type 837 to a binary floating type of a different size. 838 839 -- Runtime Function: _Decimal32 __dpd_extendsfsd (float A) 840 -- Runtime Function: _Decimal32 __bid_extendsfsd (float A) 841 -- Runtime Function: _Decimal64 __dpd_extenddfdd (double A) 842 -- Runtime Function: _Decimal64 __bid_extenddfdd (double A) 843 -- Runtime Function: _Decimal128 __dpd_extendtftd (long double A) 844 -- Runtime Function: _Decimal128 __bid_extendtftd (long double A) 845 -- Runtime Function: float __dpd_truncsdsf (_Decimal32 A) 846 -- Runtime Function: float __bid_truncsdsf (_Decimal32 A) 847 -- Runtime Function: double __dpd_truncdddf (_Decimal64 A) 848 -- Runtime Function: double __bid_truncdddf (_Decimal64 A) 849 -- Runtime Function: long double __dpd_trunctdtf (_Decimal128 A) 850 -- Runtime Function: long double __bid_trunctdtf (_Decimal128 A) 851 These functions convert the value of A between decimal and binary 852 floating types of the same size. 853 854 -- Runtime Function: int __dpd_fixsdsi (_Decimal32 A) 855 -- Runtime Function: int __bid_fixsdsi (_Decimal32 A) 856 -- Runtime Function: int __dpd_fixddsi (_Decimal64 A) 857 -- Runtime Function: int __bid_fixddsi (_Decimal64 A) 858 -- Runtime Function: int __dpd_fixtdsi (_Decimal128 A) 859 -- Runtime Function: int __bid_fixtdsi (_Decimal128 A) 860 These functions convert A to a signed integer. 861 862 -- Runtime Function: long __dpd_fixsddi (_Decimal32 A) 863 -- Runtime Function: long __bid_fixsddi (_Decimal32 A) 864 -- Runtime Function: long __dpd_fixdddi (_Decimal64 A) 865 -- Runtime Function: long __bid_fixdddi (_Decimal64 A) 866 -- Runtime Function: long __dpd_fixtddi (_Decimal128 A) 867 -- Runtime Function: long __bid_fixtddi (_Decimal128 A) 868 These functions convert A to a signed long. 869 870 -- Runtime Function: unsigned int __dpd_fixunssdsi (_Decimal32 A) 871 -- Runtime Function: unsigned int __bid_fixunssdsi (_Decimal32 A) 872 -- Runtime Function: unsigned int __dpd_fixunsddsi (_Decimal64 A) 873 -- Runtime Function: unsigned int __bid_fixunsddsi (_Decimal64 A) 874 -- Runtime Function: unsigned int __dpd_fixunstdsi (_Decimal128 A) 875 -- Runtime Function: unsigned int __bid_fixunstdsi (_Decimal128 A) 876 These functions convert A to an unsigned integer. Negative values 877 all become zero. 878 879 -- Runtime Function: unsigned long __dpd_fixunssddi (_Decimal32 A) 880 -- Runtime Function: unsigned long __bid_fixunssddi (_Decimal32 A) 881 -- Runtime Function: unsigned long __dpd_fixunsdddi (_Decimal64 A) 882 -- Runtime Function: unsigned long __bid_fixunsdddi (_Decimal64 A) 883 -- Runtime Function: unsigned long __dpd_fixunstddi (_Decimal128 A) 884 -- Runtime Function: unsigned long __bid_fixunstddi (_Decimal128 A) 885 These functions convert A to an unsigned long. Negative values all 886 become zero. 887 888 -- Runtime Function: _Decimal32 __dpd_floatsisd (int I) 889 -- Runtime Function: _Decimal32 __bid_floatsisd (int I) 890 -- Runtime Function: _Decimal64 __dpd_floatsidd (int I) 891 -- Runtime Function: _Decimal64 __bid_floatsidd (int I) 892 -- Runtime Function: _Decimal128 __dpd_floatsitd (int I) 893 -- Runtime Function: _Decimal128 __bid_floatsitd (int I) 894 These functions convert I, a signed integer, to decimal floating 895 point. 896 897 -- Runtime Function: _Decimal32 __dpd_floatdisd (long I) 898 -- Runtime Function: _Decimal32 __bid_floatdisd (long I) 899 -- Runtime Function: _Decimal64 __dpd_floatdidd (long I) 900 -- Runtime Function: _Decimal64 __bid_floatdidd (long I) 901 -- Runtime Function: _Decimal128 __dpd_floatditd (long I) 902 -- Runtime Function: _Decimal128 __bid_floatditd (long I) 903 These functions convert I, a signed long, to decimal floating 904 point. 905 906 -- Runtime Function: _Decimal32 __dpd_floatunssisd (unsigned int I) 907 -- Runtime Function: _Decimal32 __bid_floatunssisd (unsigned int I) 908 -- Runtime Function: _Decimal64 __dpd_floatunssidd (unsigned int I) 909 -- Runtime Function: _Decimal64 __bid_floatunssidd (unsigned int I) 910 -- Runtime Function: _Decimal128 __dpd_floatunssitd (unsigned int I) 911 -- Runtime Function: _Decimal128 __bid_floatunssitd (unsigned int I) 912 These functions convert I, an unsigned integer, to decimal floating 913 point. 914 915 -- Runtime Function: _Decimal32 __dpd_floatunsdisd (unsigned long I) 916 -- Runtime Function: _Decimal32 __bid_floatunsdisd (unsigned long I) 917 -- Runtime Function: _Decimal64 __dpd_floatunsdidd (unsigned long I) 918 -- Runtime Function: _Decimal64 __bid_floatunsdidd (unsigned long I) 919 -- Runtime Function: _Decimal128 __dpd_floatunsditd (unsigned long I) 920 -- Runtime Function: _Decimal128 __bid_floatunsditd (unsigned long I) 921 These functions convert I, an unsigned long, to decimal floating 922 point. 923 9244.3.3 Comparison functions 925-------------------------- 926 927 -- Runtime Function: int __dpd_unordsd2 (_Decimal32 A, _Decimal32 B) 928 -- Runtime Function: int __bid_unordsd2 (_Decimal32 A, _Decimal32 B) 929 -- Runtime Function: int __dpd_unorddd2 (_Decimal64 A, _Decimal64 B) 930 -- Runtime Function: int __bid_unorddd2 (_Decimal64 A, _Decimal64 B) 931 -- Runtime Function: int __dpd_unordtd2 (_Decimal128 A, _Decimal128 B) 932 -- Runtime Function: int __bid_unordtd2 (_Decimal128 A, _Decimal128 B) 933 These functions return a nonzero value if either argument is NaN, 934 otherwise 0. 935 936 There is also a complete group of higher level functions which 937correspond directly to comparison operators. They implement the ISO C 938semantics for floating-point comparisons, taking NaN into account. Pay 939careful attention to the return values defined for each set. Under the 940hood, all of these routines are implemented as 941 942 if (__bid_unordXd2 (a, b)) 943 return E; 944 return __bid_cmpXd2 (a, b); 945 946where E is a constant chosen to give the proper behavior for NaN. Thus, 947the meaning of the return value is different for each set. Do not rely 948on this implementation; only the semantics documented below are 949guaranteed. 950 951 -- Runtime Function: int __dpd_eqsd2 (_Decimal32 A, _Decimal32 B) 952 -- Runtime Function: int __bid_eqsd2 (_Decimal32 A, _Decimal32 B) 953 -- Runtime Function: int __dpd_eqdd2 (_Decimal64 A, _Decimal64 B) 954 -- Runtime Function: int __bid_eqdd2 (_Decimal64 A, _Decimal64 B) 955 -- Runtime Function: int __dpd_eqtd2 (_Decimal128 A, _Decimal128 B) 956 -- Runtime Function: int __bid_eqtd2 (_Decimal128 A, _Decimal128 B) 957 These functions return zero if neither argument is NaN, and A and B 958 are equal. 959 960 -- Runtime Function: int __dpd_nesd2 (_Decimal32 A, _Decimal32 B) 961 -- Runtime Function: int __bid_nesd2 (_Decimal32 A, _Decimal32 B) 962 -- Runtime Function: int __dpd_nedd2 (_Decimal64 A, _Decimal64 B) 963 -- Runtime Function: int __bid_nedd2 (_Decimal64 A, _Decimal64 B) 964 -- Runtime Function: int __dpd_netd2 (_Decimal128 A, _Decimal128 B) 965 -- Runtime Function: int __bid_netd2 (_Decimal128 A, _Decimal128 B) 966 These functions return a nonzero value if either argument is NaN, 967 or if A and B are unequal. 968 969 -- Runtime Function: int __dpd_gesd2 (_Decimal32 A, _Decimal32 B) 970 -- Runtime Function: int __bid_gesd2 (_Decimal32 A, _Decimal32 B) 971 -- Runtime Function: int __dpd_gedd2 (_Decimal64 A, _Decimal64 B) 972 -- Runtime Function: int __bid_gedd2 (_Decimal64 A, _Decimal64 B) 973 -- Runtime Function: int __dpd_getd2 (_Decimal128 A, _Decimal128 B) 974 -- Runtime Function: int __bid_getd2 (_Decimal128 A, _Decimal128 B) 975 These functions return a value greater than or equal to zero if 976 neither argument is NaN, and A is greater than or equal to B. 977 978 -- Runtime Function: int __dpd_ltsd2 (_Decimal32 A, _Decimal32 B) 979 -- Runtime Function: int __bid_ltsd2 (_Decimal32 A, _Decimal32 B) 980 -- Runtime Function: int __dpd_ltdd2 (_Decimal64 A, _Decimal64 B) 981 -- Runtime Function: int __bid_ltdd2 (_Decimal64 A, _Decimal64 B) 982 -- Runtime Function: int __dpd_lttd2 (_Decimal128 A, _Decimal128 B) 983 -- Runtime Function: int __bid_lttd2 (_Decimal128 A, _Decimal128 B) 984 These functions return a value less than zero if neither argument 985 is NaN, and A is strictly less than B. 986 987 -- Runtime Function: int __dpd_lesd2 (_Decimal32 A, _Decimal32 B) 988 -- Runtime Function: int __bid_lesd2 (_Decimal32 A, _Decimal32 B) 989 -- Runtime Function: int __dpd_ledd2 (_Decimal64 A, _Decimal64 B) 990 -- Runtime Function: int __bid_ledd2 (_Decimal64 A, _Decimal64 B) 991 -- Runtime Function: int __dpd_letd2 (_Decimal128 A, _Decimal128 B) 992 -- Runtime Function: int __bid_letd2 (_Decimal128 A, _Decimal128 B) 993 These functions return a value less than or equal to zero if 994 neither argument is NaN, and A is less than or equal to B. 995 996 -- Runtime Function: int __dpd_gtsd2 (_Decimal32 A, _Decimal32 B) 997 -- Runtime Function: int __bid_gtsd2 (_Decimal32 A, _Decimal32 B) 998 -- Runtime Function: int __dpd_gtdd2 (_Decimal64 A, _Decimal64 B) 999 -- Runtime Function: int __bid_gtdd2 (_Decimal64 A, _Decimal64 B) 1000 -- Runtime Function: int __dpd_gttd2 (_Decimal128 A, _Decimal128 B) 1001 -- Runtime Function: int __bid_gttd2 (_Decimal128 A, _Decimal128 B) 1002 These functions return a value greater than zero if neither 1003 argument is NaN, and A is strictly greater than B. 1004 1005 1006File: gccint.info, Node: Fixed-point fractional library routines, Next: Exception handling routines, Prev: Decimal float library routines, Up: Libgcc 1007 10084.4 Routines for fixed-point fractional emulation 1009================================================= 1010 1011The software fixed-point library implements fixed-point fractional 1012arithmetic, and is only activated on selected targets. 1013 1014 For ease of comprehension 'fract' is an alias for the '_Fract' type, 1015'accum' an alias for '_Accum', and 'sat' an alias for '_Sat'. 1016 1017 For illustrative purposes, in this section the fixed-point fractional 1018type 'short fract' is assumed to correspond to machine mode 'QQmode'; 1019'unsigned short fract' to 'UQQmode'; 'fract' to 'HQmode'; 1020'unsigned fract' to 'UHQmode'; 'long fract' to 'SQmode'; 1021'unsigned long fract' to 'USQmode'; 'long long fract' to 'DQmode'; and 1022'unsigned long long fract' to 'UDQmode'. Similarly the fixed-point 1023accumulator type 'short accum' corresponds to 'HAmode'; 1024'unsigned short accum' to 'UHAmode'; 'accum' to 'SAmode'; 1025'unsigned accum' to 'USAmode'; 'long accum' to 'DAmode'; 1026'unsigned long accum' to 'UDAmode'; 'long long accum' to 'TAmode'; and 1027'unsigned long long accum' to 'UTAmode'. 1028 10294.4.1 Arithmetic functions 1030-------------------------- 1031 1032 -- Runtime Function: short fract __addqq3 (short fract A, short fract 1033 B) 1034 -- Runtime Function: fract __addhq3 (fract A, fract B) 1035 -- Runtime Function: long fract __addsq3 (long fract A, long fract B) 1036 -- Runtime Function: long long fract __adddq3 (long long fract A, long 1037 long fract B) 1038 -- Runtime Function: unsigned short fract __adduqq3 (unsigned short 1039 fract A, unsigned short fract B) 1040 -- Runtime Function: unsigned fract __adduhq3 (unsigned fract A, 1041 unsigned fract B) 1042 -- Runtime Function: unsigned long fract __addusq3 (unsigned long fract 1043 A, unsigned long fract B) 1044 -- Runtime Function: unsigned long long fract __addudq3 (unsigned long 1045 long fract A, unsigned long long fract B) 1046 -- Runtime Function: short accum __addha3 (short accum A, short accum 1047 B) 1048 -- Runtime Function: accum __addsa3 (accum A, accum B) 1049 -- Runtime Function: long accum __addda3 (long accum A, long accum B) 1050 -- Runtime Function: long long accum __addta3 (long long accum A, long 1051 long accum B) 1052 -- Runtime Function: unsigned short accum __adduha3 (unsigned short 1053 accum A, unsigned short accum B) 1054 -- Runtime Function: unsigned accum __addusa3 (unsigned accum A, 1055 unsigned accum B) 1056 -- Runtime Function: unsigned long accum __adduda3 (unsigned long accum 1057 A, unsigned long accum B) 1058 -- Runtime Function: unsigned long long accum __adduta3 (unsigned long 1059 long accum A, unsigned long long accum B) 1060 These functions return the sum of A and B. 1061 1062 -- Runtime Function: short fract __ssaddqq3 (short fract A, short fract 1063 B) 1064 -- Runtime Function: fract __ssaddhq3 (fract A, fract B) 1065 -- Runtime Function: long fract __ssaddsq3 (long fract A, long fract B) 1066 -- Runtime Function: long long fract __ssadddq3 (long long fract A, 1067 long long fract B) 1068 -- Runtime Function: short accum __ssaddha3 (short accum A, short accum 1069 B) 1070 -- Runtime Function: accum __ssaddsa3 (accum A, accum B) 1071 -- Runtime Function: long accum __ssaddda3 (long accum A, long accum B) 1072 -- Runtime Function: long long accum __ssaddta3 (long long accum A, 1073 long long accum B) 1074 These functions return the sum of A and B with signed saturation. 1075 1076 -- Runtime Function: unsigned short fract __usadduqq3 (unsigned short 1077 fract A, unsigned short fract B) 1078 -- Runtime Function: unsigned fract __usadduhq3 (unsigned fract A, 1079 unsigned fract B) 1080 -- Runtime Function: unsigned long fract __usaddusq3 (unsigned long 1081 fract A, unsigned long fract B) 1082 -- Runtime Function: unsigned long long fract __usaddudq3 (unsigned 1083 long long fract A, unsigned long long fract B) 1084 -- Runtime Function: unsigned short accum __usadduha3 (unsigned short 1085 accum A, unsigned short accum B) 1086 -- Runtime Function: unsigned accum __usaddusa3 (unsigned accum A, 1087 unsigned accum B) 1088 -- Runtime Function: unsigned long accum __usadduda3 (unsigned long 1089 accum A, unsigned long accum B) 1090 -- Runtime Function: unsigned long long accum __usadduta3 (unsigned 1091 long long accum A, unsigned long long accum B) 1092 These functions return the sum of A and B with unsigned saturation. 1093 1094 -- Runtime Function: short fract __subqq3 (short fract A, short fract 1095 B) 1096 -- Runtime Function: fract __subhq3 (fract A, fract B) 1097 -- Runtime Function: long fract __subsq3 (long fract A, long fract B) 1098 -- Runtime Function: long long fract __subdq3 (long long fract A, long 1099 long fract B) 1100 -- Runtime Function: unsigned short fract __subuqq3 (unsigned short 1101 fract A, unsigned short fract B) 1102 -- Runtime Function: unsigned fract __subuhq3 (unsigned fract A, 1103 unsigned fract B) 1104 -- Runtime Function: unsigned long fract __subusq3 (unsigned long fract 1105 A, unsigned long fract B) 1106 -- Runtime Function: unsigned long long fract __subudq3 (unsigned long 1107 long fract A, unsigned long long fract B) 1108 -- Runtime Function: short accum __subha3 (short accum A, short accum 1109 B) 1110 -- Runtime Function: accum __subsa3 (accum A, accum B) 1111 -- Runtime Function: long accum __subda3 (long accum A, long accum B) 1112 -- Runtime Function: long long accum __subta3 (long long accum A, long 1113 long accum B) 1114 -- Runtime Function: unsigned short accum __subuha3 (unsigned short 1115 accum A, unsigned short accum B) 1116 -- Runtime Function: unsigned accum __subusa3 (unsigned accum A, 1117 unsigned accum B) 1118 -- Runtime Function: unsigned long accum __subuda3 (unsigned long accum 1119 A, unsigned long accum B) 1120 -- Runtime Function: unsigned long long accum __subuta3 (unsigned long 1121 long accum A, unsigned long long accum B) 1122 These functions return the difference of A and B; that is, 'A - B'. 1123 1124 -- Runtime Function: short fract __sssubqq3 (short fract A, short fract 1125 B) 1126 -- Runtime Function: fract __sssubhq3 (fract A, fract B) 1127 -- Runtime Function: long fract __sssubsq3 (long fract A, long fract B) 1128 -- Runtime Function: long long fract __sssubdq3 (long long fract A, 1129 long long fract B) 1130 -- Runtime Function: short accum __sssubha3 (short accum A, short accum 1131 B) 1132 -- Runtime Function: accum __sssubsa3 (accum A, accum B) 1133 -- Runtime Function: long accum __sssubda3 (long accum A, long accum B) 1134 -- Runtime Function: long long accum __sssubta3 (long long accum A, 1135 long long accum B) 1136 These functions return the difference of A and B with signed 1137 saturation; that is, 'A - B'. 1138 1139 -- Runtime Function: unsigned short fract __ussubuqq3 (unsigned short 1140 fract A, unsigned short fract B) 1141 -- Runtime Function: unsigned fract __ussubuhq3 (unsigned fract A, 1142 unsigned fract B) 1143 -- Runtime Function: unsigned long fract __ussubusq3 (unsigned long 1144 fract A, unsigned long fract B) 1145 -- Runtime Function: unsigned long long fract __ussubudq3 (unsigned 1146 long long fract A, unsigned long long fract B) 1147 -- Runtime Function: unsigned short accum __ussubuha3 (unsigned short 1148 accum A, unsigned short accum B) 1149 -- Runtime Function: unsigned accum __ussubusa3 (unsigned accum A, 1150 unsigned accum B) 1151 -- Runtime Function: unsigned long accum __ussubuda3 (unsigned long 1152 accum A, unsigned long accum B) 1153 -- Runtime Function: unsigned long long accum __ussubuta3 (unsigned 1154 long long accum A, unsigned long long accum B) 1155 These functions return the difference of A and B with unsigned 1156 saturation; that is, 'A - B'. 1157 1158 -- Runtime Function: short fract __mulqq3 (short fract A, short fract 1159 B) 1160 -- Runtime Function: fract __mulhq3 (fract A, fract B) 1161 -- Runtime Function: long fract __mulsq3 (long fract A, long fract B) 1162 -- Runtime Function: long long fract __muldq3 (long long fract A, long 1163 long fract B) 1164 -- Runtime Function: unsigned short fract __muluqq3 (unsigned short 1165 fract A, unsigned short fract B) 1166 -- Runtime Function: unsigned fract __muluhq3 (unsigned fract A, 1167 unsigned fract B) 1168 -- Runtime Function: unsigned long fract __mulusq3 (unsigned long fract 1169 A, unsigned long fract B) 1170 -- Runtime Function: unsigned long long fract __muludq3 (unsigned long 1171 long fract A, unsigned long long fract B) 1172 -- Runtime Function: short accum __mulha3 (short accum A, short accum 1173 B) 1174 -- Runtime Function: accum __mulsa3 (accum A, accum B) 1175 -- Runtime Function: long accum __mulda3 (long accum A, long accum B) 1176 -- Runtime Function: long long accum __multa3 (long long accum A, long 1177 long accum B) 1178 -- Runtime Function: unsigned short accum __muluha3 (unsigned short 1179 accum A, unsigned short accum B) 1180 -- Runtime Function: unsigned accum __mulusa3 (unsigned accum A, 1181 unsigned accum B) 1182 -- Runtime Function: unsigned long accum __muluda3 (unsigned long accum 1183 A, unsigned long accum B) 1184 -- Runtime Function: unsigned long long accum __muluta3 (unsigned long 1185 long accum A, unsigned long long accum B) 1186 These functions return the product of A and B. 1187 1188 -- Runtime Function: short fract __ssmulqq3 (short fract A, short fract 1189 B) 1190 -- Runtime Function: fract __ssmulhq3 (fract A, fract B) 1191 -- Runtime Function: long fract __ssmulsq3 (long fract A, long fract B) 1192 -- Runtime Function: long long fract __ssmuldq3 (long long fract A, 1193 long long fract B) 1194 -- Runtime Function: short accum __ssmulha3 (short accum A, short accum 1195 B) 1196 -- Runtime Function: accum __ssmulsa3 (accum A, accum B) 1197 -- Runtime Function: long accum __ssmulda3 (long accum A, long accum B) 1198 -- Runtime Function: long long accum __ssmulta3 (long long accum A, 1199 long long accum B) 1200 These functions return the product of A and B with signed 1201 saturation. 1202 1203 -- Runtime Function: unsigned short fract __usmuluqq3 (unsigned short 1204 fract A, unsigned short fract B) 1205 -- Runtime Function: unsigned fract __usmuluhq3 (unsigned fract A, 1206 unsigned fract B) 1207 -- Runtime Function: unsigned long fract __usmulusq3 (unsigned long 1208 fract A, unsigned long fract B) 1209 -- Runtime Function: unsigned long long fract __usmuludq3 (unsigned 1210 long long fract A, unsigned long long fract B) 1211 -- Runtime Function: unsigned short accum __usmuluha3 (unsigned short 1212 accum A, unsigned short accum B) 1213 -- Runtime Function: unsigned accum __usmulusa3 (unsigned accum A, 1214 unsigned accum B) 1215 -- Runtime Function: unsigned long accum __usmuluda3 (unsigned long 1216 accum A, unsigned long accum B) 1217 -- Runtime Function: unsigned long long accum __usmuluta3 (unsigned 1218 long long accum A, unsigned long long accum B) 1219 These functions return the product of A and B with unsigned 1220 saturation. 1221 1222 -- Runtime Function: short fract __divqq3 (short fract A, short fract 1223 B) 1224 -- Runtime Function: fract __divhq3 (fract A, fract B) 1225 -- Runtime Function: long fract __divsq3 (long fract A, long fract B) 1226 -- Runtime Function: long long fract __divdq3 (long long fract A, long 1227 long fract B) 1228 -- Runtime Function: short accum __divha3 (short accum A, short accum 1229 B) 1230 -- Runtime Function: accum __divsa3 (accum A, accum B) 1231 -- Runtime Function: long accum __divda3 (long accum A, long accum B) 1232 -- Runtime Function: long long accum __divta3 (long long accum A, long 1233 long accum B) 1234 These functions return the quotient of the signed division of A and 1235 B. 1236 1237 -- Runtime Function: unsigned short fract __udivuqq3 (unsigned short 1238 fract A, unsigned short fract B) 1239 -- Runtime Function: unsigned fract __udivuhq3 (unsigned fract A, 1240 unsigned fract B) 1241 -- Runtime Function: unsigned long fract __udivusq3 (unsigned long 1242 fract A, unsigned long fract B) 1243 -- Runtime Function: unsigned long long fract __udivudq3 (unsigned long 1244 long fract A, unsigned long long fract B) 1245 -- Runtime Function: unsigned short accum __udivuha3 (unsigned short 1246 accum A, unsigned short accum B) 1247 -- Runtime Function: unsigned accum __udivusa3 (unsigned accum A, 1248 unsigned accum B) 1249 -- Runtime Function: unsigned long accum __udivuda3 (unsigned long 1250 accum A, unsigned long accum B) 1251 -- Runtime Function: unsigned long long accum __udivuta3 (unsigned long 1252 long accum A, unsigned long long accum B) 1253 These functions return the quotient of the unsigned division of A 1254 and B. 1255 1256 -- Runtime Function: short fract __ssdivqq3 (short fract A, short fract 1257 B) 1258 -- Runtime Function: fract __ssdivhq3 (fract A, fract B) 1259 -- Runtime Function: long fract __ssdivsq3 (long fract A, long fract B) 1260 -- Runtime Function: long long fract __ssdivdq3 (long long fract A, 1261 long long fract B) 1262 -- Runtime Function: short accum __ssdivha3 (short accum A, short accum 1263 B) 1264 -- Runtime Function: accum __ssdivsa3 (accum A, accum B) 1265 -- Runtime Function: long accum __ssdivda3 (long accum A, long accum B) 1266 -- Runtime Function: long long accum __ssdivta3 (long long accum A, 1267 long long accum B) 1268 These functions return the quotient of the signed division of A and 1269 B with signed saturation. 1270 1271 -- Runtime Function: unsigned short fract __usdivuqq3 (unsigned short 1272 fract A, unsigned short fract B) 1273 -- Runtime Function: unsigned fract __usdivuhq3 (unsigned fract A, 1274 unsigned fract B) 1275 -- Runtime Function: unsigned long fract __usdivusq3 (unsigned long 1276 fract A, unsigned long fract B) 1277 -- Runtime Function: unsigned long long fract __usdivudq3 (unsigned 1278 long long fract A, unsigned long long fract B) 1279 -- Runtime Function: unsigned short accum __usdivuha3 (unsigned short 1280 accum A, unsigned short accum B) 1281 -- Runtime Function: unsigned accum __usdivusa3 (unsigned accum A, 1282 unsigned accum B) 1283 -- Runtime Function: unsigned long accum __usdivuda3 (unsigned long 1284 accum A, unsigned long accum B) 1285 -- Runtime Function: unsigned long long accum __usdivuta3 (unsigned 1286 long long accum A, unsigned long long accum B) 1287 These functions return the quotient of the unsigned division of A 1288 and B with unsigned saturation. 1289 1290 -- Runtime Function: short fract __negqq2 (short fract A) 1291 -- Runtime Function: fract __neghq2 (fract A) 1292 -- Runtime Function: long fract __negsq2 (long fract A) 1293 -- Runtime Function: long long fract __negdq2 (long long fract A) 1294 -- Runtime Function: unsigned short fract __neguqq2 (unsigned short 1295 fract A) 1296 -- Runtime Function: unsigned fract __neguhq2 (unsigned fract A) 1297 -- Runtime Function: unsigned long fract __negusq2 (unsigned long fract 1298 A) 1299 -- Runtime Function: unsigned long long fract __negudq2 (unsigned long 1300 long fract A) 1301 -- Runtime Function: short accum __negha2 (short accum A) 1302 -- Runtime Function: accum __negsa2 (accum A) 1303 -- Runtime Function: long accum __negda2 (long accum A) 1304 -- Runtime Function: long long accum __negta2 (long long accum A) 1305 -- Runtime Function: unsigned short accum __neguha2 (unsigned short 1306 accum A) 1307 -- Runtime Function: unsigned accum __negusa2 (unsigned accum A) 1308 -- Runtime Function: unsigned long accum __neguda2 (unsigned long accum 1309 A) 1310 -- Runtime Function: unsigned long long accum __neguta2 (unsigned long 1311 long accum A) 1312 These functions return the negation of A. 1313 1314 -- Runtime Function: short fract __ssnegqq2 (short fract A) 1315 -- Runtime Function: fract __ssneghq2 (fract A) 1316 -- Runtime Function: long fract __ssnegsq2 (long fract A) 1317 -- Runtime Function: long long fract __ssnegdq2 (long long fract A) 1318 -- Runtime Function: short accum __ssnegha2 (short accum A) 1319 -- Runtime Function: accum __ssnegsa2 (accum A) 1320 -- Runtime Function: long accum __ssnegda2 (long accum A) 1321 -- Runtime Function: long long accum __ssnegta2 (long long accum A) 1322 These functions return the negation of A with signed saturation. 1323 1324 -- Runtime Function: unsigned short fract __usneguqq2 (unsigned short 1325 fract A) 1326 -- Runtime Function: unsigned fract __usneguhq2 (unsigned fract A) 1327 -- Runtime Function: unsigned long fract __usnegusq2 (unsigned long 1328 fract A) 1329 -- Runtime Function: unsigned long long fract __usnegudq2 (unsigned 1330 long long fract A) 1331 -- Runtime Function: unsigned short accum __usneguha2 (unsigned short 1332 accum A) 1333 -- Runtime Function: unsigned accum __usnegusa2 (unsigned accum A) 1334 -- Runtime Function: unsigned long accum __usneguda2 (unsigned long 1335 accum A) 1336 -- Runtime Function: unsigned long long accum __usneguta2 (unsigned 1337 long long accum A) 1338 These functions return the negation of A with unsigned saturation. 1339 1340 -- Runtime Function: short fract __ashlqq3 (short fract A, int B) 1341 -- Runtime Function: fract __ashlhq3 (fract A, int B) 1342 -- Runtime Function: long fract __ashlsq3 (long fract A, int B) 1343 -- Runtime Function: long long fract __ashldq3 (long long fract A, int 1344 B) 1345 -- Runtime Function: unsigned short fract __ashluqq3 (unsigned short 1346 fract A, int B) 1347 -- Runtime Function: unsigned fract __ashluhq3 (unsigned fract A, int 1348 B) 1349 -- Runtime Function: unsigned long fract __ashlusq3 (unsigned long 1350 fract A, int B) 1351 -- Runtime Function: unsigned long long fract __ashludq3 (unsigned long 1352 long fract A, int B) 1353 -- Runtime Function: short accum __ashlha3 (short accum A, int B) 1354 -- Runtime Function: accum __ashlsa3 (accum A, int B) 1355 -- Runtime Function: long accum __ashlda3 (long accum A, int B) 1356 -- Runtime Function: long long accum __ashlta3 (long long accum A, int 1357 B) 1358 -- Runtime Function: unsigned short accum __ashluha3 (unsigned short 1359 accum A, int B) 1360 -- Runtime Function: unsigned accum __ashlusa3 (unsigned accum A, int 1361 B) 1362 -- Runtime Function: unsigned long accum __ashluda3 (unsigned long 1363 accum A, int B) 1364 -- Runtime Function: unsigned long long accum __ashluta3 (unsigned long 1365 long accum A, int B) 1366 These functions return the result of shifting A left by B bits. 1367 1368 -- Runtime Function: short fract __ashrqq3 (short fract A, int B) 1369 -- Runtime Function: fract __ashrhq3 (fract A, int B) 1370 -- Runtime Function: long fract __ashrsq3 (long fract A, int B) 1371 -- Runtime Function: long long fract __ashrdq3 (long long fract A, int 1372 B) 1373 -- Runtime Function: short accum __ashrha3 (short accum A, int B) 1374 -- Runtime Function: accum __ashrsa3 (accum A, int B) 1375 -- Runtime Function: long accum __ashrda3 (long accum A, int B) 1376 -- Runtime Function: long long accum __ashrta3 (long long accum A, int 1377 B) 1378 These functions return the result of arithmetically shifting A 1379 right by B bits. 1380 1381 -- Runtime Function: unsigned short fract __lshruqq3 (unsigned short 1382 fract A, int B) 1383 -- Runtime Function: unsigned fract __lshruhq3 (unsigned fract A, int 1384 B) 1385 -- Runtime Function: unsigned long fract __lshrusq3 (unsigned long 1386 fract A, int B) 1387 -- Runtime Function: unsigned long long fract __lshrudq3 (unsigned long 1388 long fract A, int B) 1389 -- Runtime Function: unsigned short accum __lshruha3 (unsigned short 1390 accum A, int B) 1391 -- Runtime Function: unsigned accum __lshrusa3 (unsigned accum A, int 1392 B) 1393 -- Runtime Function: unsigned long accum __lshruda3 (unsigned long 1394 accum A, int B) 1395 -- Runtime Function: unsigned long long accum __lshruta3 (unsigned long 1396 long accum A, int B) 1397 These functions return the result of logically shifting A right by 1398 B bits. 1399 1400 -- Runtime Function: fract __ssashlhq3 (fract A, int B) 1401 -- Runtime Function: long fract __ssashlsq3 (long fract A, int B) 1402 -- Runtime Function: long long fract __ssashldq3 (long long fract A, 1403 int B) 1404 -- Runtime Function: short accum __ssashlha3 (short accum A, int B) 1405 -- Runtime Function: accum __ssashlsa3 (accum A, int B) 1406 -- Runtime Function: long accum __ssashlda3 (long accum A, int B) 1407 -- Runtime Function: long long accum __ssashlta3 (long long accum A, 1408 int B) 1409 These functions return the result of shifting A left by B bits with 1410 signed saturation. 1411 1412 -- Runtime Function: unsigned short fract __usashluqq3 (unsigned short 1413 fract A, int B) 1414 -- Runtime Function: unsigned fract __usashluhq3 (unsigned fract A, int 1415 B) 1416 -- Runtime Function: unsigned long fract __usashlusq3 (unsigned long 1417 fract A, int B) 1418 -- Runtime Function: unsigned long long fract __usashludq3 (unsigned 1419 long long fract A, int B) 1420 -- Runtime Function: unsigned short accum __usashluha3 (unsigned short 1421 accum A, int B) 1422 -- Runtime Function: unsigned accum __usashlusa3 (unsigned accum A, int 1423 B) 1424 -- Runtime Function: unsigned long accum __usashluda3 (unsigned long 1425 accum A, int B) 1426 -- Runtime Function: unsigned long long accum __usashluta3 (unsigned 1427 long long accum A, int B) 1428 These functions return the result of shifting A left by B bits with 1429 unsigned saturation. 1430 14314.4.2 Comparison functions 1432-------------------------- 1433 1434The following functions implement fixed-point comparisons. These 1435functions implement a low-level compare, upon which the higher level 1436comparison operators (such as less than and greater than or equal to) 1437can be constructed. The returned values lie in the range zero to two, 1438to allow the high-level operators to be implemented by testing the 1439returned result using either signed or unsigned comparison. 1440 1441 -- Runtime Function: int __cmpqq2 (short fract A, short fract B) 1442 -- Runtime Function: int __cmphq2 (fract A, fract B) 1443 -- Runtime Function: int __cmpsq2 (long fract A, long fract B) 1444 -- Runtime Function: int __cmpdq2 (long long fract A, long long fract 1445 B) 1446 -- Runtime Function: int __cmpuqq2 (unsigned short fract A, unsigned 1447 short fract B) 1448 -- Runtime Function: int __cmpuhq2 (unsigned fract A, unsigned fract B) 1449 -- Runtime Function: int __cmpusq2 (unsigned long fract A, unsigned 1450 long fract B) 1451 -- Runtime Function: int __cmpudq2 (unsigned long long fract A, 1452 unsigned long long fract B) 1453 -- Runtime Function: int __cmpha2 (short accum A, short accum B) 1454 -- Runtime Function: int __cmpsa2 (accum A, accum B) 1455 -- Runtime Function: int __cmpda2 (long accum A, long accum B) 1456 -- Runtime Function: int __cmpta2 (long long accum A, long long accum 1457 B) 1458 -- Runtime Function: int __cmpuha2 (unsigned short accum A, unsigned 1459 short accum B) 1460 -- Runtime Function: int __cmpusa2 (unsigned accum A, unsigned accum B) 1461 -- Runtime Function: int __cmpuda2 (unsigned long accum A, unsigned 1462 long accum B) 1463 -- Runtime Function: int __cmputa2 (unsigned long long accum A, 1464 unsigned long long accum B) 1465 These functions perform a signed or unsigned comparison of A and B 1466 (depending on the selected machine mode). If A is less than B, 1467 they return 0; if A is greater than B, they return 2; and if A and 1468 B are equal they return 1. 1469 14704.4.3 Conversion functions 1471-------------------------- 1472 1473 -- Runtime Function: fract __fractqqhq2 (short fract A) 1474 -- Runtime Function: long fract __fractqqsq2 (short fract A) 1475 -- Runtime Function: long long fract __fractqqdq2 (short fract A) 1476 -- Runtime Function: short accum __fractqqha (short fract A) 1477 -- Runtime Function: accum __fractqqsa (short fract A) 1478 -- Runtime Function: long accum __fractqqda (short fract A) 1479 -- Runtime Function: long long accum __fractqqta (short fract A) 1480 -- Runtime Function: unsigned short fract __fractqquqq (short fract A) 1481 -- Runtime Function: unsigned fract __fractqquhq (short fract A) 1482 -- Runtime Function: unsigned long fract __fractqqusq (short fract A) 1483 -- Runtime Function: unsigned long long fract __fractqqudq (short fract 1484 A) 1485 -- Runtime Function: unsigned short accum __fractqquha (short fract A) 1486 -- Runtime Function: unsigned accum __fractqqusa (short fract A) 1487 -- Runtime Function: unsigned long accum __fractqquda (short fract A) 1488 -- Runtime Function: unsigned long long accum __fractqquta (short fract 1489 A) 1490 -- Runtime Function: signed char __fractqqqi (short fract A) 1491 -- Runtime Function: short __fractqqhi (short fract A) 1492 -- Runtime Function: int __fractqqsi (short fract A) 1493 -- Runtime Function: long __fractqqdi (short fract A) 1494 -- Runtime Function: long long __fractqqti (short fract A) 1495 -- Runtime Function: float __fractqqsf (short fract A) 1496 -- Runtime Function: double __fractqqdf (short fract A) 1497 -- Runtime Function: short fract __fracthqqq2 (fract A) 1498 -- Runtime Function: long fract __fracthqsq2 (fract A) 1499 -- Runtime Function: long long fract __fracthqdq2 (fract A) 1500 -- Runtime Function: short accum __fracthqha (fract A) 1501 -- Runtime Function: accum __fracthqsa (fract A) 1502 -- Runtime Function: long accum __fracthqda (fract A) 1503 -- Runtime Function: long long accum __fracthqta (fract A) 1504 -- Runtime Function: unsigned short fract __fracthquqq (fract A) 1505 -- Runtime Function: unsigned fract __fracthquhq (fract A) 1506 -- Runtime Function: unsigned long fract __fracthqusq (fract A) 1507 -- Runtime Function: unsigned long long fract __fracthqudq (fract A) 1508 -- Runtime Function: unsigned short accum __fracthquha (fract A) 1509 -- Runtime Function: unsigned accum __fracthqusa (fract A) 1510 -- Runtime Function: unsigned long accum __fracthquda (fract A) 1511 -- Runtime Function: unsigned long long accum __fracthquta (fract A) 1512 -- Runtime Function: signed char __fracthqqi (fract A) 1513 -- Runtime Function: short __fracthqhi (fract A) 1514 -- Runtime Function: int __fracthqsi (fract A) 1515 -- Runtime Function: long __fracthqdi (fract A) 1516 -- Runtime Function: long long __fracthqti (fract A) 1517 -- Runtime Function: float __fracthqsf (fract A) 1518 -- Runtime Function: double __fracthqdf (fract A) 1519 -- Runtime Function: short fract __fractsqqq2 (long fract A) 1520 -- Runtime Function: fract __fractsqhq2 (long fract A) 1521 -- Runtime Function: long long fract __fractsqdq2 (long fract A) 1522 -- Runtime Function: short accum __fractsqha (long fract A) 1523 -- Runtime Function: accum __fractsqsa (long fract A) 1524 -- Runtime Function: long accum __fractsqda (long fract A) 1525 -- Runtime Function: long long accum __fractsqta (long fract A) 1526 -- Runtime Function: unsigned short fract __fractsquqq (long fract A) 1527 -- Runtime Function: unsigned fract __fractsquhq (long fract A) 1528 -- Runtime Function: unsigned long fract __fractsqusq (long fract A) 1529 -- Runtime Function: unsigned long long fract __fractsqudq (long fract 1530 A) 1531 -- Runtime Function: unsigned short accum __fractsquha (long fract A) 1532 -- Runtime Function: unsigned accum __fractsqusa (long fract A) 1533 -- Runtime Function: unsigned long accum __fractsquda (long fract A) 1534 -- Runtime Function: unsigned long long accum __fractsquta (long fract 1535 A) 1536 -- Runtime Function: signed char __fractsqqi (long fract A) 1537 -- Runtime Function: short __fractsqhi (long fract A) 1538 -- Runtime Function: int __fractsqsi (long fract A) 1539 -- Runtime Function: long __fractsqdi (long fract A) 1540 -- Runtime Function: long long __fractsqti (long fract A) 1541 -- Runtime Function: float __fractsqsf (long fract A) 1542 -- Runtime Function: double __fractsqdf (long fract A) 1543 -- Runtime Function: short fract __fractdqqq2 (long long fract A) 1544 -- Runtime Function: fract __fractdqhq2 (long long fract A) 1545 -- Runtime Function: long fract __fractdqsq2 (long long fract A) 1546 -- Runtime Function: short accum __fractdqha (long long fract A) 1547 -- Runtime Function: accum __fractdqsa (long long fract A) 1548 -- Runtime Function: long accum __fractdqda (long long fract A) 1549 -- Runtime Function: long long accum __fractdqta (long long fract A) 1550 -- Runtime Function: unsigned short fract __fractdquqq (long long fract 1551 A) 1552 -- Runtime Function: unsigned fract __fractdquhq (long long fract A) 1553 -- Runtime Function: unsigned long fract __fractdqusq (long long fract 1554 A) 1555 -- Runtime Function: unsigned long long fract __fractdqudq (long long 1556 fract A) 1557 -- Runtime Function: unsigned short accum __fractdquha (long long fract 1558 A) 1559 -- Runtime Function: unsigned accum __fractdqusa (long long fract A) 1560 -- Runtime Function: unsigned long accum __fractdquda (long long fract 1561 A) 1562 -- Runtime Function: unsigned long long accum __fractdquta (long long 1563 fract A) 1564 -- Runtime Function: signed char __fractdqqi (long long fract A) 1565 -- Runtime Function: short __fractdqhi (long long fract A) 1566 -- Runtime Function: int __fractdqsi (long long fract A) 1567 -- Runtime Function: long __fractdqdi (long long fract A) 1568 -- Runtime Function: long long __fractdqti (long long fract A) 1569 -- Runtime Function: float __fractdqsf (long long fract A) 1570 -- Runtime Function: double __fractdqdf (long long fract A) 1571 -- Runtime Function: short fract __fracthaqq (short accum A) 1572 -- Runtime Function: fract __fracthahq (short accum A) 1573 -- Runtime Function: long fract __fracthasq (short accum A) 1574 -- Runtime Function: long long fract __fracthadq (short accum A) 1575 -- Runtime Function: accum __fracthasa2 (short accum A) 1576 -- Runtime Function: long accum __fracthada2 (short accum A) 1577 -- Runtime Function: long long accum __fracthata2 (short accum A) 1578 -- Runtime Function: unsigned short fract __fracthauqq (short accum A) 1579 -- Runtime Function: unsigned fract __fracthauhq (short accum A) 1580 -- Runtime Function: unsigned long fract __fracthausq (short accum A) 1581 -- Runtime Function: unsigned long long fract __fracthaudq (short accum 1582 A) 1583 -- Runtime Function: unsigned short accum __fracthauha (short accum A) 1584 -- Runtime Function: unsigned accum __fracthausa (short accum A) 1585 -- Runtime Function: unsigned long accum __fracthauda (short accum A) 1586 -- Runtime Function: unsigned long long accum __fracthauta (short accum 1587 A) 1588 -- Runtime Function: signed char __fracthaqi (short accum A) 1589 -- Runtime Function: short __fracthahi (short accum A) 1590 -- Runtime Function: int __fracthasi (short accum A) 1591 -- Runtime Function: long __fracthadi (short accum A) 1592 -- Runtime Function: long long __fracthati (short accum A) 1593 -- Runtime Function: float __fracthasf (short accum A) 1594 -- Runtime Function: double __fracthadf (short accum A) 1595 -- Runtime Function: short fract __fractsaqq (accum A) 1596 -- Runtime Function: fract __fractsahq (accum A) 1597 -- Runtime Function: long fract __fractsasq (accum A) 1598 -- Runtime Function: long long fract __fractsadq (accum A) 1599 -- Runtime Function: short accum __fractsaha2 (accum A) 1600 -- Runtime Function: long accum __fractsada2 (accum A) 1601 -- Runtime Function: long long accum __fractsata2 (accum A) 1602 -- Runtime Function: unsigned short fract __fractsauqq (accum A) 1603 -- Runtime Function: unsigned fract __fractsauhq (accum A) 1604 -- Runtime Function: unsigned long fract __fractsausq (accum A) 1605 -- Runtime Function: unsigned long long fract __fractsaudq (accum A) 1606 -- Runtime Function: unsigned short accum __fractsauha (accum A) 1607 -- Runtime Function: unsigned accum __fractsausa (accum A) 1608 -- Runtime Function: unsigned long accum __fractsauda (accum A) 1609 -- Runtime Function: unsigned long long accum __fractsauta (accum A) 1610 -- Runtime Function: signed char __fractsaqi (accum A) 1611 -- Runtime Function: short __fractsahi (accum A) 1612 -- Runtime Function: int __fractsasi (accum A) 1613 -- Runtime Function: long __fractsadi (accum A) 1614 -- Runtime Function: long long __fractsati (accum A) 1615 -- Runtime Function: float __fractsasf (accum A) 1616 -- Runtime Function: double __fractsadf (accum A) 1617 -- Runtime Function: short fract __fractdaqq (long accum A) 1618 -- Runtime Function: fract __fractdahq (long accum A) 1619 -- Runtime Function: long fract __fractdasq (long accum A) 1620 -- Runtime Function: long long fract __fractdadq (long accum A) 1621 -- Runtime Function: short accum __fractdaha2 (long accum A) 1622 -- Runtime Function: accum __fractdasa2 (long accum A) 1623 -- Runtime Function: long long accum __fractdata2 (long accum A) 1624 -- Runtime Function: unsigned short fract __fractdauqq (long accum A) 1625 -- Runtime Function: unsigned fract __fractdauhq (long accum A) 1626 -- Runtime Function: unsigned long fract __fractdausq (long accum A) 1627 -- Runtime Function: unsigned long long fract __fractdaudq (long accum 1628 A) 1629 -- Runtime Function: unsigned short accum __fractdauha (long accum A) 1630 -- Runtime Function: unsigned accum __fractdausa (long accum A) 1631 -- Runtime Function: unsigned long accum __fractdauda (long accum A) 1632 -- Runtime Function: unsigned long long accum __fractdauta (long accum 1633 A) 1634 -- Runtime Function: signed char __fractdaqi (long accum A) 1635 -- Runtime Function: short __fractdahi (long accum A) 1636 -- Runtime Function: int __fractdasi (long accum A) 1637 -- Runtime Function: long __fractdadi (long accum A) 1638 -- Runtime Function: long long __fractdati (long accum A) 1639 -- Runtime Function: float __fractdasf (long accum A) 1640 -- Runtime Function: double __fractdadf (long accum A) 1641 -- Runtime Function: short fract __fracttaqq (long long accum A) 1642 -- Runtime Function: fract __fracttahq (long long accum A) 1643 -- Runtime Function: long fract __fracttasq (long long accum A) 1644 -- Runtime Function: long long fract __fracttadq (long long accum A) 1645 -- Runtime Function: short accum __fracttaha2 (long long accum A) 1646 -- Runtime Function: accum __fracttasa2 (long long accum A) 1647 -- Runtime Function: long accum __fracttada2 (long long accum A) 1648 -- Runtime Function: unsigned short fract __fracttauqq (long long accum 1649 A) 1650 -- Runtime Function: unsigned fract __fracttauhq (long long accum A) 1651 -- Runtime Function: unsigned long fract __fracttausq (long long accum 1652 A) 1653 -- Runtime Function: unsigned long long fract __fracttaudq (long long 1654 accum A) 1655 -- Runtime Function: unsigned short accum __fracttauha (long long accum 1656 A) 1657 -- Runtime Function: unsigned accum __fracttausa (long long accum A) 1658 -- Runtime Function: unsigned long accum __fracttauda (long long accum 1659 A) 1660 -- Runtime Function: unsigned long long accum __fracttauta (long long 1661 accum A) 1662 -- Runtime Function: signed char __fracttaqi (long long accum A) 1663 -- Runtime Function: short __fracttahi (long long accum A) 1664 -- Runtime Function: int __fracttasi (long long accum A) 1665 -- Runtime Function: long __fracttadi (long long accum A) 1666 -- Runtime Function: long long __fracttati (long long accum A) 1667 -- Runtime Function: float __fracttasf (long long accum A) 1668 -- Runtime Function: double __fracttadf (long long accum A) 1669 -- Runtime Function: short fract __fractuqqqq (unsigned short fract A) 1670 -- Runtime Function: fract __fractuqqhq (unsigned short fract A) 1671 -- Runtime Function: long fract __fractuqqsq (unsigned short fract A) 1672 -- Runtime Function: long long fract __fractuqqdq (unsigned short fract 1673 A) 1674 -- Runtime Function: short accum __fractuqqha (unsigned short fract A) 1675 -- Runtime Function: accum __fractuqqsa (unsigned short fract A) 1676 -- Runtime Function: long accum __fractuqqda (unsigned short fract A) 1677 -- Runtime Function: long long accum __fractuqqta (unsigned short fract 1678 A) 1679 -- Runtime Function: unsigned fract __fractuqquhq2 (unsigned short 1680 fract A) 1681 -- Runtime Function: unsigned long fract __fractuqqusq2 (unsigned short 1682 fract A) 1683 -- Runtime Function: unsigned long long fract __fractuqqudq2 (unsigned 1684 short fract A) 1685 -- Runtime Function: unsigned short accum __fractuqquha (unsigned short 1686 fract A) 1687 -- Runtime Function: unsigned accum __fractuqqusa (unsigned short fract 1688 A) 1689 -- Runtime Function: unsigned long accum __fractuqquda (unsigned short 1690 fract A) 1691 -- Runtime Function: unsigned long long accum __fractuqquta (unsigned 1692 short fract A) 1693 -- Runtime Function: signed char __fractuqqqi (unsigned short fract A) 1694 -- Runtime Function: short __fractuqqhi (unsigned short fract A) 1695 -- Runtime Function: int __fractuqqsi (unsigned short fract A) 1696 -- Runtime Function: long __fractuqqdi (unsigned short fract A) 1697 -- Runtime Function: long long __fractuqqti (unsigned short fract A) 1698 -- Runtime Function: float __fractuqqsf (unsigned short fract A) 1699 -- Runtime Function: double __fractuqqdf (unsigned short fract A) 1700 -- Runtime Function: short fract __fractuhqqq (unsigned fract A) 1701 -- Runtime Function: fract __fractuhqhq (unsigned fract A) 1702 -- Runtime Function: long fract __fractuhqsq (unsigned fract A) 1703 -- Runtime Function: long long fract __fractuhqdq (unsigned fract A) 1704 -- Runtime Function: short accum __fractuhqha (unsigned fract A) 1705 -- Runtime Function: accum __fractuhqsa (unsigned fract A) 1706 -- Runtime Function: long accum __fractuhqda (unsigned fract A) 1707 -- Runtime Function: long long accum __fractuhqta (unsigned fract A) 1708 -- Runtime Function: unsigned short fract __fractuhquqq2 (unsigned 1709 fract A) 1710 -- Runtime Function: unsigned long fract __fractuhqusq2 (unsigned fract 1711 A) 1712 -- Runtime Function: unsigned long long fract __fractuhqudq2 (unsigned 1713 fract A) 1714 -- Runtime Function: unsigned short accum __fractuhquha (unsigned fract 1715 A) 1716 -- Runtime Function: unsigned accum __fractuhqusa (unsigned fract A) 1717 -- Runtime Function: unsigned long accum __fractuhquda (unsigned fract 1718 A) 1719 -- Runtime Function: unsigned long long accum __fractuhquta (unsigned 1720 fract A) 1721 -- Runtime Function: signed char __fractuhqqi (unsigned fract A) 1722 -- Runtime Function: short __fractuhqhi (unsigned fract A) 1723 -- Runtime Function: int __fractuhqsi (unsigned fract A) 1724 -- Runtime Function: long __fractuhqdi (unsigned fract A) 1725 -- Runtime Function: long long __fractuhqti (unsigned fract A) 1726 -- Runtime Function: float __fractuhqsf (unsigned fract A) 1727 -- Runtime Function: double __fractuhqdf (unsigned fract A) 1728 -- Runtime Function: short fract __fractusqqq (unsigned long fract A) 1729 -- Runtime Function: fract __fractusqhq (unsigned long fract A) 1730 -- Runtime Function: long fract __fractusqsq (unsigned long fract A) 1731 -- Runtime Function: long long fract __fractusqdq (unsigned long fract 1732 A) 1733 -- Runtime Function: short accum __fractusqha (unsigned long fract A) 1734 -- Runtime Function: accum __fractusqsa (unsigned long fract A) 1735 -- Runtime Function: long accum __fractusqda (unsigned long fract A) 1736 -- Runtime Function: long long accum __fractusqta (unsigned long fract 1737 A) 1738 -- Runtime Function: unsigned short fract __fractusquqq2 (unsigned long 1739 fract A) 1740 -- Runtime Function: unsigned fract __fractusquhq2 (unsigned long fract 1741 A) 1742 -- Runtime Function: unsigned long long fract __fractusqudq2 (unsigned 1743 long fract A) 1744 -- Runtime Function: unsigned short accum __fractusquha (unsigned long 1745 fract A) 1746 -- Runtime Function: unsigned accum __fractusqusa (unsigned long fract 1747 A) 1748 -- Runtime Function: unsigned long accum __fractusquda (unsigned long 1749 fract A) 1750 -- Runtime Function: unsigned long long accum __fractusquta (unsigned 1751 long fract A) 1752 -- Runtime Function: signed char __fractusqqi (unsigned long fract A) 1753 -- Runtime Function: short __fractusqhi (unsigned long fract A) 1754 -- Runtime Function: int __fractusqsi (unsigned long fract A) 1755 -- Runtime Function: long __fractusqdi (unsigned long fract A) 1756 -- Runtime Function: long long __fractusqti (unsigned long fract A) 1757 -- Runtime Function: float __fractusqsf (unsigned long fract A) 1758 -- Runtime Function: double __fractusqdf (unsigned long fract A) 1759 -- Runtime Function: short fract __fractudqqq (unsigned long long fract 1760 A) 1761 -- Runtime Function: fract __fractudqhq (unsigned long long fract A) 1762 -- Runtime Function: long fract __fractudqsq (unsigned long long fract 1763 A) 1764 -- Runtime Function: long long fract __fractudqdq (unsigned long long 1765 fract A) 1766 -- Runtime Function: short accum __fractudqha (unsigned long long fract 1767 A) 1768 -- Runtime Function: accum __fractudqsa (unsigned long long fract A) 1769 -- Runtime Function: long accum __fractudqda (unsigned long long fract 1770 A) 1771 -- Runtime Function: long long accum __fractudqta (unsigned long long 1772 fract A) 1773 -- Runtime Function: unsigned short fract __fractudquqq2 (unsigned long 1774 long fract A) 1775 -- Runtime Function: unsigned fract __fractudquhq2 (unsigned long long 1776 fract A) 1777 -- Runtime Function: unsigned long fract __fractudqusq2 (unsigned long 1778 long fract A) 1779 -- Runtime Function: unsigned short accum __fractudquha (unsigned long 1780 long fract A) 1781 -- Runtime Function: unsigned accum __fractudqusa (unsigned long long 1782 fract A) 1783 -- Runtime Function: unsigned long accum __fractudquda (unsigned long 1784 long fract A) 1785 -- Runtime Function: unsigned long long accum __fractudquta (unsigned 1786 long long fract A) 1787 -- Runtime Function: signed char __fractudqqi (unsigned long long fract 1788 A) 1789 -- Runtime Function: short __fractudqhi (unsigned long long fract A) 1790 -- Runtime Function: int __fractudqsi (unsigned long long fract A) 1791 -- Runtime Function: long __fractudqdi (unsigned long long fract A) 1792 -- Runtime Function: long long __fractudqti (unsigned long long fract 1793 A) 1794 -- Runtime Function: float __fractudqsf (unsigned long long fract A) 1795 -- Runtime Function: double __fractudqdf (unsigned long long fract A) 1796 -- Runtime Function: short fract __fractuhaqq (unsigned short accum A) 1797 -- Runtime Function: fract __fractuhahq (unsigned short accum A) 1798 -- Runtime Function: long fract __fractuhasq (unsigned short accum A) 1799 -- Runtime Function: long long fract __fractuhadq (unsigned short accum 1800 A) 1801 -- Runtime Function: short accum __fractuhaha (unsigned short accum A) 1802 -- Runtime Function: accum __fractuhasa (unsigned short accum A) 1803 -- Runtime Function: long accum __fractuhada (unsigned short accum A) 1804 -- Runtime Function: long long accum __fractuhata (unsigned short accum 1805 A) 1806 -- Runtime Function: unsigned short fract __fractuhauqq (unsigned short 1807 accum A) 1808 -- Runtime Function: unsigned fract __fractuhauhq (unsigned short accum 1809 A) 1810 -- Runtime Function: unsigned long fract __fractuhausq (unsigned short 1811 accum A) 1812 -- Runtime Function: unsigned long long fract __fractuhaudq (unsigned 1813 short accum A) 1814 -- Runtime Function: unsigned accum __fractuhausa2 (unsigned short 1815 accum A) 1816 -- Runtime Function: unsigned long accum __fractuhauda2 (unsigned short 1817 accum A) 1818 -- Runtime Function: unsigned long long accum __fractuhauta2 (unsigned 1819 short accum A) 1820 -- Runtime Function: signed char __fractuhaqi (unsigned short accum A) 1821 -- Runtime Function: short __fractuhahi (unsigned short accum A) 1822 -- Runtime Function: int __fractuhasi (unsigned short accum A) 1823 -- Runtime Function: long __fractuhadi (unsigned short accum A) 1824 -- Runtime Function: long long __fractuhati (unsigned short accum A) 1825 -- Runtime Function: float __fractuhasf (unsigned short accum A) 1826 -- Runtime Function: double __fractuhadf (unsigned short accum A) 1827 -- Runtime Function: short fract __fractusaqq (unsigned accum A) 1828 -- Runtime Function: fract __fractusahq (unsigned accum A) 1829 -- Runtime Function: long fract __fractusasq (unsigned accum A) 1830 -- Runtime Function: long long fract __fractusadq (unsigned accum A) 1831 -- Runtime Function: short accum __fractusaha (unsigned accum A) 1832 -- Runtime Function: accum __fractusasa (unsigned accum A) 1833 -- Runtime Function: long accum __fractusada (unsigned accum A) 1834 -- Runtime Function: long long accum __fractusata (unsigned accum A) 1835 -- Runtime Function: unsigned short fract __fractusauqq (unsigned accum 1836 A) 1837 -- Runtime Function: unsigned fract __fractusauhq (unsigned accum A) 1838 -- Runtime Function: unsigned long fract __fractusausq (unsigned accum 1839 A) 1840 -- Runtime Function: unsigned long long fract __fractusaudq (unsigned 1841 accum A) 1842 -- Runtime Function: unsigned short accum __fractusauha2 (unsigned 1843 accum A) 1844 -- Runtime Function: unsigned long accum __fractusauda2 (unsigned accum 1845 A) 1846 -- Runtime Function: unsigned long long accum __fractusauta2 (unsigned 1847 accum A) 1848 -- Runtime Function: signed char __fractusaqi (unsigned accum A) 1849 -- Runtime Function: short __fractusahi (unsigned accum A) 1850 -- Runtime Function: int __fractusasi (unsigned accum A) 1851 -- Runtime Function: long __fractusadi (unsigned accum A) 1852 -- Runtime Function: long long __fractusati (unsigned accum A) 1853 -- Runtime Function: float __fractusasf (unsigned accum A) 1854 -- Runtime Function: double __fractusadf (unsigned accum A) 1855 -- Runtime Function: short fract __fractudaqq (unsigned long accum A) 1856 -- Runtime Function: fract __fractudahq (unsigned long accum A) 1857 -- Runtime Function: long fract __fractudasq (unsigned long accum A) 1858 -- Runtime Function: long long fract __fractudadq (unsigned long accum 1859 A) 1860 -- Runtime Function: short accum __fractudaha (unsigned long accum A) 1861 -- Runtime Function: accum __fractudasa (unsigned long accum A) 1862 -- Runtime Function: long accum __fractudada (unsigned long accum A) 1863 -- Runtime Function: long long accum __fractudata (unsigned long accum 1864 A) 1865 -- Runtime Function: unsigned short fract __fractudauqq (unsigned long 1866 accum A) 1867 -- Runtime Function: unsigned fract __fractudauhq (unsigned long accum 1868 A) 1869 -- Runtime Function: unsigned long fract __fractudausq (unsigned long 1870 accum A) 1871 -- Runtime Function: unsigned long long fract __fractudaudq (unsigned 1872 long accum A) 1873 -- Runtime Function: unsigned short accum __fractudauha2 (unsigned long 1874 accum A) 1875 -- Runtime Function: unsigned accum __fractudausa2 (unsigned long accum 1876 A) 1877 -- Runtime Function: unsigned long long accum __fractudauta2 (unsigned 1878 long accum A) 1879 -- Runtime Function: signed char __fractudaqi (unsigned long accum A) 1880 -- Runtime Function: short __fractudahi (unsigned long accum A) 1881 -- Runtime Function: int __fractudasi (unsigned long accum A) 1882 -- Runtime Function: long __fractudadi (unsigned long accum A) 1883 -- Runtime Function: long long __fractudati (unsigned long accum A) 1884 -- Runtime Function: float __fractudasf (unsigned long accum A) 1885 -- Runtime Function: double __fractudadf (unsigned long accum A) 1886 -- Runtime Function: short fract __fractutaqq (unsigned long long accum 1887 A) 1888 -- Runtime Function: fract __fractutahq (unsigned long long accum A) 1889 -- Runtime Function: long fract __fractutasq (unsigned long long accum 1890 A) 1891 -- Runtime Function: long long fract __fractutadq (unsigned long long 1892 accum A) 1893 -- Runtime Function: short accum __fractutaha (unsigned long long accum 1894 A) 1895 -- Runtime Function: accum __fractutasa (unsigned long long accum A) 1896 -- Runtime Function: long accum __fractutada (unsigned long long accum 1897 A) 1898 -- Runtime Function: long long accum __fractutata (unsigned long long 1899 accum A) 1900 -- Runtime Function: unsigned short fract __fractutauqq (unsigned long 1901 long accum A) 1902 -- Runtime Function: unsigned fract __fractutauhq (unsigned long long 1903 accum A) 1904 -- Runtime Function: unsigned long fract __fractutausq (unsigned long 1905 long accum A) 1906 -- Runtime Function: unsigned long long fract __fractutaudq (unsigned 1907 long long accum A) 1908 -- Runtime Function: unsigned short accum __fractutauha2 (unsigned long 1909 long accum A) 1910 -- Runtime Function: unsigned accum __fractutausa2 (unsigned long long 1911 accum A) 1912 -- Runtime Function: unsigned long accum __fractutauda2 (unsigned long 1913 long accum A) 1914 -- Runtime Function: signed char __fractutaqi (unsigned long long accum 1915 A) 1916 -- Runtime Function: short __fractutahi (unsigned long long accum A) 1917 -- Runtime Function: int __fractutasi (unsigned long long accum A) 1918 -- Runtime Function: long __fractutadi (unsigned long long accum A) 1919 -- Runtime Function: long long __fractutati (unsigned long long accum 1920 A) 1921 -- Runtime Function: float __fractutasf (unsigned long long accum A) 1922 -- Runtime Function: double __fractutadf (unsigned long long accum A) 1923 -- Runtime Function: short fract __fractqiqq (signed char A) 1924 -- Runtime Function: fract __fractqihq (signed char A) 1925 -- Runtime Function: long fract __fractqisq (signed char A) 1926 -- Runtime Function: long long fract __fractqidq (signed char A) 1927 -- Runtime Function: short accum __fractqiha (signed char A) 1928 -- Runtime Function: accum __fractqisa (signed char A) 1929 -- Runtime Function: long accum __fractqida (signed char A) 1930 -- Runtime Function: long long accum __fractqita (signed char A) 1931 -- Runtime Function: unsigned short fract __fractqiuqq (signed char A) 1932 -- Runtime Function: unsigned fract __fractqiuhq (signed char A) 1933 -- Runtime Function: unsigned long fract __fractqiusq (signed char A) 1934 -- Runtime Function: unsigned long long fract __fractqiudq (signed char 1935 A) 1936 -- Runtime Function: unsigned short accum __fractqiuha (signed char A) 1937 -- Runtime Function: unsigned accum __fractqiusa (signed char A) 1938 -- Runtime Function: unsigned long accum __fractqiuda (signed char A) 1939 -- Runtime Function: unsigned long long accum __fractqiuta (signed char 1940 A) 1941 -- Runtime Function: short fract __fracthiqq (short A) 1942 -- Runtime Function: fract __fracthihq (short A) 1943 -- Runtime Function: long fract __fracthisq (short A) 1944 -- Runtime Function: long long fract __fracthidq (short A) 1945 -- Runtime Function: short accum __fracthiha (short A) 1946 -- Runtime Function: accum __fracthisa (short A) 1947 -- Runtime Function: long accum __fracthida (short A) 1948 -- Runtime Function: long long accum __fracthita (short A) 1949 -- Runtime Function: unsigned short fract __fracthiuqq (short A) 1950 -- Runtime Function: unsigned fract __fracthiuhq (short A) 1951 -- Runtime Function: unsigned long fract __fracthiusq (short A) 1952 -- Runtime Function: unsigned long long fract __fracthiudq (short A) 1953 -- Runtime Function: unsigned short accum __fracthiuha (short A) 1954 -- Runtime Function: unsigned accum __fracthiusa (short A) 1955 -- Runtime Function: unsigned long accum __fracthiuda (short A) 1956 -- Runtime Function: unsigned long long accum __fracthiuta (short A) 1957 -- Runtime Function: short fract __fractsiqq (int A) 1958 -- Runtime Function: fract __fractsihq (int A) 1959 -- Runtime Function: long fract __fractsisq (int A) 1960 -- Runtime Function: long long fract __fractsidq (int A) 1961 -- Runtime Function: short accum __fractsiha (int A) 1962 -- Runtime Function: accum __fractsisa (int A) 1963 -- Runtime Function: long accum __fractsida (int A) 1964 -- Runtime Function: long long accum __fractsita (int A) 1965 -- Runtime Function: unsigned short fract __fractsiuqq (int A) 1966 -- Runtime Function: unsigned fract __fractsiuhq (int A) 1967 -- Runtime Function: unsigned long fract __fractsiusq (int A) 1968 -- Runtime Function: unsigned long long fract __fractsiudq (int A) 1969 -- Runtime Function: unsigned short accum __fractsiuha (int A) 1970 -- Runtime Function: unsigned accum __fractsiusa (int A) 1971 -- Runtime Function: unsigned long accum __fractsiuda (int A) 1972 -- Runtime Function: unsigned long long accum __fractsiuta (int A) 1973 -- Runtime Function: short fract __fractdiqq (long A) 1974 -- Runtime Function: fract __fractdihq (long A) 1975 -- Runtime Function: long fract __fractdisq (long A) 1976 -- Runtime Function: long long fract __fractdidq (long A) 1977 -- Runtime Function: short accum __fractdiha (long A) 1978 -- Runtime Function: accum __fractdisa (long A) 1979 -- Runtime Function: long accum __fractdida (long A) 1980 -- Runtime Function: long long accum __fractdita (long A) 1981 -- Runtime Function: unsigned short fract __fractdiuqq (long A) 1982 -- Runtime Function: unsigned fract __fractdiuhq (long A) 1983 -- Runtime Function: unsigned long fract __fractdiusq (long A) 1984 -- Runtime Function: unsigned long long fract __fractdiudq (long A) 1985 -- Runtime Function: unsigned short accum __fractdiuha (long A) 1986 -- Runtime Function: unsigned accum __fractdiusa (long A) 1987 -- Runtime Function: unsigned long accum __fractdiuda (long A) 1988 -- Runtime Function: unsigned long long accum __fractdiuta (long A) 1989 -- Runtime Function: short fract __fracttiqq (long long A) 1990 -- Runtime Function: fract __fracttihq (long long A) 1991 -- Runtime Function: long fract __fracttisq (long long A) 1992 -- Runtime Function: long long fract __fracttidq (long long A) 1993 -- Runtime Function: short accum __fracttiha (long long A) 1994 -- Runtime Function: accum __fracttisa (long long A) 1995 -- Runtime Function: long accum __fracttida (long long A) 1996 -- Runtime Function: long long accum __fracttita (long long A) 1997 -- Runtime Function: unsigned short fract __fracttiuqq (long long A) 1998 -- Runtime Function: unsigned fract __fracttiuhq (long long A) 1999 -- Runtime Function: unsigned long fract __fracttiusq (long long A) 2000 -- Runtime Function: unsigned long long fract __fracttiudq (long long 2001 A) 2002 -- Runtime Function: unsigned short accum __fracttiuha (long long A) 2003 -- Runtime Function: unsigned accum __fracttiusa (long long A) 2004 -- Runtime Function: unsigned long accum __fracttiuda (long long A) 2005 -- Runtime Function: unsigned long long accum __fracttiuta (long long 2006 A) 2007 -- Runtime Function: short fract __fractsfqq (float A) 2008 -- Runtime Function: fract __fractsfhq (float A) 2009 -- Runtime Function: long fract __fractsfsq (float A) 2010 -- Runtime Function: long long fract __fractsfdq (float A) 2011 -- Runtime Function: short accum __fractsfha (float A) 2012 -- Runtime Function: accum __fractsfsa (float A) 2013 -- Runtime Function: long accum __fractsfda (float A) 2014 -- Runtime Function: long long accum __fractsfta (float A) 2015 -- Runtime Function: unsigned short fract __fractsfuqq (float A) 2016 -- Runtime Function: unsigned fract __fractsfuhq (float A) 2017 -- Runtime Function: unsigned long fract __fractsfusq (float A) 2018 -- Runtime Function: unsigned long long fract __fractsfudq (float A) 2019 -- Runtime Function: unsigned short accum __fractsfuha (float A) 2020 -- Runtime Function: unsigned accum __fractsfusa (float A) 2021 -- Runtime Function: unsigned long accum __fractsfuda (float A) 2022 -- Runtime Function: unsigned long long accum __fractsfuta (float A) 2023 -- Runtime Function: short fract __fractdfqq (double A) 2024 -- Runtime Function: fract __fractdfhq (double A) 2025 -- Runtime Function: long fract __fractdfsq (double A) 2026 -- Runtime Function: long long fract __fractdfdq (double A) 2027 -- Runtime Function: short accum __fractdfha (double A) 2028 -- Runtime Function: accum __fractdfsa (double A) 2029 -- Runtime Function: long accum __fractdfda (double A) 2030 -- Runtime Function: long long accum __fractdfta (double A) 2031 -- Runtime Function: unsigned short fract __fractdfuqq (double A) 2032 -- Runtime Function: unsigned fract __fractdfuhq (double A) 2033 -- Runtime Function: unsigned long fract __fractdfusq (double A) 2034 -- Runtime Function: unsigned long long fract __fractdfudq (double A) 2035 -- Runtime Function: unsigned short accum __fractdfuha (double A) 2036 -- Runtime Function: unsigned accum __fractdfusa (double A) 2037 -- Runtime Function: unsigned long accum __fractdfuda (double A) 2038 -- Runtime Function: unsigned long long accum __fractdfuta (double A) 2039 These functions convert from fractional and signed non-fractionals 2040 to fractionals and signed non-fractionals, without saturation. 2041 2042 -- Runtime Function: fract __satfractqqhq2 (short fract A) 2043 -- Runtime Function: long fract __satfractqqsq2 (short fract A) 2044 -- Runtime Function: long long fract __satfractqqdq2 (short fract A) 2045 -- Runtime Function: short accum __satfractqqha (short fract A) 2046 -- Runtime Function: accum __satfractqqsa (short fract A) 2047 -- Runtime Function: long accum __satfractqqda (short fract A) 2048 -- Runtime Function: long long accum __satfractqqta (short fract A) 2049 -- Runtime Function: unsigned short fract __satfractqquqq (short fract 2050 A) 2051 -- Runtime Function: unsigned fract __satfractqquhq (short fract A) 2052 -- Runtime Function: unsigned long fract __satfractqqusq (short fract 2053 A) 2054 -- Runtime Function: unsigned long long fract __satfractqqudq (short 2055 fract A) 2056 -- Runtime Function: unsigned short accum __satfractqquha (short fract 2057 A) 2058 -- Runtime Function: unsigned accum __satfractqqusa (short fract A) 2059 -- Runtime Function: unsigned long accum __satfractqquda (short fract 2060 A) 2061 -- Runtime Function: unsigned long long accum __satfractqquta (short 2062 fract A) 2063 -- Runtime Function: short fract __satfracthqqq2 (fract A) 2064 -- Runtime Function: long fract __satfracthqsq2 (fract A) 2065 -- Runtime Function: long long fract __satfracthqdq2 (fract A) 2066 -- Runtime Function: short accum __satfracthqha (fract A) 2067 -- Runtime Function: accum __satfracthqsa (fract A) 2068 -- Runtime Function: long accum __satfracthqda (fract A) 2069 -- Runtime Function: long long accum __satfracthqta (fract A) 2070 -- Runtime Function: unsigned short fract __satfracthquqq (fract A) 2071 -- Runtime Function: unsigned fract __satfracthquhq (fract A) 2072 -- Runtime Function: unsigned long fract __satfracthqusq (fract A) 2073 -- Runtime Function: unsigned long long fract __satfracthqudq (fract A) 2074 -- Runtime Function: unsigned short accum __satfracthquha (fract A) 2075 -- Runtime Function: unsigned accum __satfracthqusa (fract A) 2076 -- Runtime Function: unsigned long accum __satfracthquda (fract A) 2077 -- Runtime Function: unsigned long long accum __satfracthquta (fract A) 2078 -- Runtime Function: short fract __satfractsqqq2 (long fract A) 2079 -- Runtime Function: fract __satfractsqhq2 (long fract A) 2080 -- Runtime Function: long long fract __satfractsqdq2 (long fract A) 2081 -- Runtime Function: short accum __satfractsqha (long fract A) 2082 -- Runtime Function: accum __satfractsqsa (long fract A) 2083 -- Runtime Function: long accum __satfractsqda (long fract A) 2084 -- Runtime Function: long long accum __satfractsqta (long fract A) 2085 -- Runtime Function: unsigned short fract __satfractsquqq (long fract 2086 A) 2087 -- Runtime Function: unsigned fract __satfractsquhq (long fract A) 2088 -- Runtime Function: unsigned long fract __satfractsqusq (long fract A) 2089 -- Runtime Function: unsigned long long fract __satfractsqudq (long 2090 fract A) 2091 -- Runtime Function: unsigned short accum __satfractsquha (long fract 2092 A) 2093 -- Runtime Function: unsigned accum __satfractsqusa (long fract A) 2094 -- Runtime Function: unsigned long accum __satfractsquda (long fract A) 2095 -- Runtime Function: unsigned long long accum __satfractsquta (long 2096 fract A) 2097 -- Runtime Function: short fract __satfractdqqq2 (long long fract A) 2098 -- Runtime Function: fract __satfractdqhq2 (long long fract A) 2099 -- Runtime Function: long fract __satfractdqsq2 (long long fract A) 2100 -- Runtime Function: short accum __satfractdqha (long long fract A) 2101 -- Runtime Function: accum __satfractdqsa (long long fract A) 2102 -- Runtime Function: long accum __satfractdqda (long long fract A) 2103 -- Runtime Function: long long accum __satfractdqta (long long fract A) 2104 -- Runtime Function: unsigned short fract __satfractdquqq (long long 2105 fract A) 2106 -- Runtime Function: unsigned fract __satfractdquhq (long long fract A) 2107 -- Runtime Function: unsigned long fract __satfractdqusq (long long 2108 fract A) 2109 -- Runtime Function: unsigned long long fract __satfractdqudq (long 2110 long fract A) 2111 -- Runtime Function: unsigned short accum __satfractdquha (long long 2112 fract A) 2113 -- Runtime Function: unsigned accum __satfractdqusa (long long fract A) 2114 -- Runtime Function: unsigned long accum __satfractdquda (long long 2115 fract A) 2116 -- Runtime Function: unsigned long long accum __satfractdquta (long 2117 long fract A) 2118 -- Runtime Function: short fract __satfracthaqq (short accum A) 2119 -- Runtime Function: fract __satfracthahq (short accum A) 2120 -- Runtime Function: long fract __satfracthasq (short accum A) 2121 -- Runtime Function: long long fract __satfracthadq (short accum A) 2122 -- Runtime Function: accum __satfracthasa2 (short accum A) 2123 -- Runtime Function: long accum __satfracthada2 (short accum A) 2124 -- Runtime Function: long long accum __satfracthata2 (short accum A) 2125 -- Runtime Function: unsigned short fract __satfracthauqq (short accum 2126 A) 2127 -- Runtime Function: unsigned fract __satfracthauhq (short accum A) 2128 -- Runtime Function: unsigned long fract __satfracthausq (short accum 2129 A) 2130 -- Runtime Function: unsigned long long fract __satfracthaudq (short 2131 accum A) 2132 -- Runtime Function: unsigned short accum __satfracthauha (short accum 2133 A) 2134 -- Runtime Function: unsigned accum __satfracthausa (short accum A) 2135 -- Runtime Function: unsigned long accum __satfracthauda (short accum 2136 A) 2137 -- Runtime Function: unsigned long long accum __satfracthauta (short 2138 accum A) 2139 -- Runtime Function: short fract __satfractsaqq (accum A) 2140 -- Runtime Function: fract __satfractsahq (accum A) 2141 -- Runtime Function: long fract __satfractsasq (accum A) 2142 -- Runtime Function: long long fract __satfractsadq (accum A) 2143 -- Runtime Function: short accum __satfractsaha2 (accum A) 2144 -- Runtime Function: long accum __satfractsada2 (accum A) 2145 -- Runtime Function: long long accum __satfractsata2 (accum A) 2146 -- Runtime Function: unsigned short fract __satfractsauqq (accum A) 2147 -- Runtime Function: unsigned fract __satfractsauhq (accum A) 2148 -- Runtime Function: unsigned long fract __satfractsausq (accum A) 2149 -- Runtime Function: unsigned long long fract __satfractsaudq (accum A) 2150 -- Runtime Function: unsigned short accum __satfractsauha (accum A) 2151 -- Runtime Function: unsigned accum __satfractsausa (accum A) 2152 -- Runtime Function: unsigned long accum __satfractsauda (accum A) 2153 -- Runtime Function: unsigned long long accum __satfractsauta (accum A) 2154 -- Runtime Function: short fract __satfractdaqq (long accum A) 2155 -- Runtime Function: fract __satfractdahq (long accum A) 2156 -- Runtime Function: long fract __satfractdasq (long accum A) 2157 -- Runtime Function: long long fract __satfractdadq (long accum A) 2158 -- Runtime Function: short accum __satfractdaha2 (long accum A) 2159 -- Runtime Function: accum __satfractdasa2 (long accum A) 2160 -- Runtime Function: long long accum __satfractdata2 (long accum A) 2161 -- Runtime Function: unsigned short fract __satfractdauqq (long accum 2162 A) 2163 -- Runtime Function: unsigned fract __satfractdauhq (long accum A) 2164 -- Runtime Function: unsigned long fract __satfractdausq (long accum A) 2165 -- Runtime Function: unsigned long long fract __satfractdaudq (long 2166 accum A) 2167 -- Runtime Function: unsigned short accum __satfractdauha (long accum 2168 A) 2169 -- Runtime Function: unsigned accum __satfractdausa (long accum A) 2170 -- Runtime Function: unsigned long accum __satfractdauda (long accum A) 2171 -- Runtime Function: unsigned long long accum __satfractdauta (long 2172 accum A) 2173 -- Runtime Function: short fract __satfracttaqq (long long accum A) 2174 -- Runtime Function: fract __satfracttahq (long long accum A) 2175 -- Runtime Function: long fract __satfracttasq (long long accum A) 2176 -- Runtime Function: long long fract __satfracttadq (long long accum A) 2177 -- Runtime Function: short accum __satfracttaha2 (long long accum A) 2178 -- Runtime Function: accum __satfracttasa2 (long long accum A) 2179 -- Runtime Function: long accum __satfracttada2 (long long accum A) 2180 -- Runtime Function: unsigned short fract __satfracttauqq (long long 2181 accum A) 2182 -- Runtime Function: unsigned fract __satfracttauhq (long long accum A) 2183 -- Runtime Function: unsigned long fract __satfracttausq (long long 2184 accum A) 2185 -- Runtime Function: unsigned long long fract __satfracttaudq (long 2186 long accum A) 2187 -- Runtime Function: unsigned short accum __satfracttauha (long long 2188 accum A) 2189 -- Runtime Function: unsigned accum __satfracttausa (long long accum A) 2190 -- Runtime Function: unsigned long accum __satfracttauda (long long 2191 accum A) 2192 -- Runtime Function: unsigned long long accum __satfracttauta (long 2193 long accum A) 2194 -- Runtime Function: short fract __satfractuqqqq (unsigned short fract 2195 A) 2196 -- Runtime Function: fract __satfractuqqhq (unsigned short fract A) 2197 -- Runtime Function: long fract __satfractuqqsq (unsigned short fract 2198 A) 2199 -- Runtime Function: long long fract __satfractuqqdq (unsigned short 2200 fract A) 2201 -- Runtime Function: short accum __satfractuqqha (unsigned short fract 2202 A) 2203 -- Runtime Function: accum __satfractuqqsa (unsigned short fract A) 2204 -- Runtime Function: long accum __satfractuqqda (unsigned short fract 2205 A) 2206 -- Runtime Function: long long accum __satfractuqqta (unsigned short 2207 fract A) 2208 -- Runtime Function: unsigned fract __satfractuqquhq2 (unsigned short 2209 fract A) 2210 -- Runtime Function: unsigned long fract __satfractuqqusq2 (unsigned 2211 short fract A) 2212 -- Runtime Function: unsigned long long fract __satfractuqqudq2 2213 (unsigned short fract A) 2214 -- Runtime Function: unsigned short accum __satfractuqquha (unsigned 2215 short fract A) 2216 -- Runtime Function: unsigned accum __satfractuqqusa (unsigned short 2217 fract A) 2218 -- Runtime Function: unsigned long accum __satfractuqquda (unsigned 2219 short fract A) 2220 -- Runtime Function: unsigned long long accum __satfractuqquta 2221 (unsigned short fract A) 2222 -- Runtime Function: short fract __satfractuhqqq (unsigned fract A) 2223 -- Runtime Function: fract __satfractuhqhq (unsigned fract A) 2224 -- Runtime Function: long fract __satfractuhqsq (unsigned fract A) 2225 -- Runtime Function: long long fract __satfractuhqdq (unsigned fract A) 2226 -- Runtime Function: short accum __satfractuhqha (unsigned fract A) 2227 -- Runtime Function: accum __satfractuhqsa (unsigned fract A) 2228 -- Runtime Function: long accum __satfractuhqda (unsigned fract A) 2229 -- Runtime Function: long long accum __satfractuhqta (unsigned fract A) 2230 -- Runtime Function: unsigned short fract __satfractuhquqq2 (unsigned 2231 fract A) 2232 -- Runtime Function: unsigned long fract __satfractuhqusq2 (unsigned 2233 fract A) 2234 -- Runtime Function: unsigned long long fract __satfractuhqudq2 2235 (unsigned fract A) 2236 -- Runtime Function: unsigned short accum __satfractuhquha (unsigned 2237 fract A) 2238 -- Runtime Function: unsigned accum __satfractuhqusa (unsigned fract A) 2239 -- Runtime Function: unsigned long accum __satfractuhquda (unsigned 2240 fract A) 2241 -- Runtime Function: unsigned long long accum __satfractuhquta 2242 (unsigned fract A) 2243 -- Runtime Function: short fract __satfractusqqq (unsigned long fract 2244 A) 2245 -- Runtime Function: fract __satfractusqhq (unsigned long fract A) 2246 -- Runtime Function: long fract __satfractusqsq (unsigned long fract A) 2247 -- Runtime Function: long long fract __satfractusqdq (unsigned long 2248 fract A) 2249 -- Runtime Function: short accum __satfractusqha (unsigned long fract 2250 A) 2251 -- Runtime Function: accum __satfractusqsa (unsigned long fract A) 2252 -- Runtime Function: long accum __satfractusqda (unsigned long fract A) 2253 -- Runtime Function: long long accum __satfractusqta (unsigned long 2254 fract A) 2255 -- Runtime Function: unsigned short fract __satfractusquqq2 (unsigned 2256 long fract A) 2257 -- Runtime Function: unsigned fract __satfractusquhq2 (unsigned long 2258 fract A) 2259 -- Runtime Function: unsigned long long fract __satfractusqudq2 2260 (unsigned long fract A) 2261 -- Runtime Function: unsigned short accum __satfractusquha (unsigned 2262 long fract A) 2263 -- Runtime Function: unsigned accum __satfractusqusa (unsigned long 2264 fract A) 2265 -- Runtime Function: unsigned long accum __satfractusquda (unsigned 2266 long fract A) 2267 -- Runtime Function: unsigned long long accum __satfractusquta 2268 (unsigned long fract A) 2269 -- Runtime Function: short fract __satfractudqqq (unsigned long long 2270 fract A) 2271 -- Runtime Function: fract __satfractudqhq (unsigned long long fract A) 2272 -- Runtime Function: long fract __satfractudqsq (unsigned long long 2273 fract A) 2274 -- Runtime Function: long long fract __satfractudqdq (unsigned long 2275 long fract A) 2276 -- Runtime Function: short accum __satfractudqha (unsigned long long 2277 fract A) 2278 -- Runtime Function: accum __satfractudqsa (unsigned long long fract A) 2279 -- Runtime Function: long accum __satfractudqda (unsigned long long 2280 fract A) 2281 -- Runtime Function: long long accum __satfractudqta (unsigned long 2282 long fract A) 2283 -- Runtime Function: unsigned short fract __satfractudquqq2 (unsigned 2284 long long fract A) 2285 -- Runtime Function: unsigned fract __satfractudquhq2 (unsigned long 2286 long fract A) 2287 -- Runtime Function: unsigned long fract __satfractudqusq2 (unsigned 2288 long long fract A) 2289 -- Runtime Function: unsigned short accum __satfractudquha (unsigned 2290 long long fract A) 2291 -- Runtime Function: unsigned accum __satfractudqusa (unsigned long 2292 long fract A) 2293 -- Runtime Function: unsigned long accum __satfractudquda (unsigned 2294 long long fract A) 2295 -- Runtime Function: unsigned long long accum __satfractudquta 2296 (unsigned long long fract A) 2297 -- Runtime Function: short fract __satfractuhaqq (unsigned short accum 2298 A) 2299 -- Runtime Function: fract __satfractuhahq (unsigned short accum A) 2300 -- Runtime Function: long fract __satfractuhasq (unsigned short accum 2301 A) 2302 -- Runtime Function: long long fract __satfractuhadq (unsigned short 2303 accum A) 2304 -- Runtime Function: short accum __satfractuhaha (unsigned short accum 2305 A) 2306 -- Runtime Function: accum __satfractuhasa (unsigned short accum A) 2307 -- Runtime Function: long accum __satfractuhada (unsigned short accum 2308 A) 2309 -- Runtime Function: long long accum __satfractuhata (unsigned short 2310 accum A) 2311 -- Runtime Function: unsigned short fract __satfractuhauqq (unsigned 2312 short accum A) 2313 -- Runtime Function: unsigned fract __satfractuhauhq (unsigned short 2314 accum A) 2315 -- Runtime Function: unsigned long fract __satfractuhausq (unsigned 2316 short accum A) 2317 -- Runtime Function: unsigned long long fract __satfractuhaudq 2318 (unsigned short accum A) 2319 -- Runtime Function: unsigned accum __satfractuhausa2 (unsigned short 2320 accum A) 2321 -- Runtime Function: unsigned long accum __satfractuhauda2 (unsigned 2322 short accum A) 2323 -- Runtime Function: unsigned long long accum __satfractuhauta2 2324 (unsigned short accum A) 2325 -- Runtime Function: short fract __satfractusaqq (unsigned accum A) 2326 -- Runtime Function: fract __satfractusahq (unsigned accum A) 2327 -- Runtime Function: long fract __satfractusasq (unsigned accum A) 2328 -- Runtime Function: long long fract __satfractusadq (unsigned accum A) 2329 -- Runtime Function: short accum __satfractusaha (unsigned accum A) 2330 -- Runtime Function: accum __satfractusasa (unsigned accum A) 2331 -- Runtime Function: long accum __satfractusada (unsigned accum A) 2332 -- Runtime Function: long long accum __satfractusata (unsigned accum A) 2333 -- Runtime Function: unsigned short fract __satfractusauqq (unsigned 2334 accum A) 2335 -- Runtime Function: unsigned fract __satfractusauhq (unsigned accum A) 2336 -- Runtime Function: unsigned long fract __satfractusausq (unsigned 2337 accum A) 2338 -- Runtime Function: unsigned long long fract __satfractusaudq 2339 (unsigned accum A) 2340 -- Runtime Function: unsigned short accum __satfractusauha2 (unsigned 2341 accum A) 2342 -- Runtime Function: unsigned long accum __satfractusauda2 (unsigned 2343 accum A) 2344 -- Runtime Function: unsigned long long accum __satfractusauta2 2345 (unsigned accum A) 2346 -- Runtime Function: short fract __satfractudaqq (unsigned long accum 2347 A) 2348 -- Runtime Function: fract __satfractudahq (unsigned long accum A) 2349 -- Runtime Function: long fract __satfractudasq (unsigned long accum A) 2350 -- Runtime Function: long long fract __satfractudadq (unsigned long 2351 accum A) 2352 -- Runtime Function: short accum __satfractudaha (unsigned long accum 2353 A) 2354 -- Runtime Function: accum __satfractudasa (unsigned long accum A) 2355 -- Runtime Function: long accum __satfractudada (unsigned long accum A) 2356 -- Runtime Function: long long accum __satfractudata (unsigned long 2357 accum A) 2358 -- Runtime Function: unsigned short fract __satfractudauqq (unsigned 2359 long accum A) 2360 -- Runtime Function: unsigned fract __satfractudauhq (unsigned long 2361 accum A) 2362 -- Runtime Function: unsigned long fract __satfractudausq (unsigned 2363 long accum A) 2364 -- Runtime Function: unsigned long long fract __satfractudaudq 2365 (unsigned long accum A) 2366 -- Runtime Function: unsigned short accum __satfractudauha2 (unsigned 2367 long accum A) 2368 -- Runtime Function: unsigned accum __satfractudausa2 (unsigned long 2369 accum A) 2370 -- Runtime Function: unsigned long long accum __satfractudauta2 2371 (unsigned long accum A) 2372 -- Runtime Function: short fract __satfractutaqq (unsigned long long 2373 accum A) 2374 -- Runtime Function: fract __satfractutahq (unsigned long long accum A) 2375 -- Runtime Function: long fract __satfractutasq (unsigned long long 2376 accum A) 2377 -- Runtime Function: long long fract __satfractutadq (unsigned long 2378 long accum A) 2379 -- Runtime Function: short accum __satfractutaha (unsigned long long 2380 accum A) 2381 -- Runtime Function: accum __satfractutasa (unsigned long long accum A) 2382 -- Runtime Function: long accum __satfractutada (unsigned long long 2383 accum A) 2384 -- Runtime Function: long long accum __satfractutata (unsigned long 2385 long accum A) 2386 -- Runtime Function: unsigned short fract __satfractutauqq (unsigned 2387 long long accum A) 2388 -- Runtime Function: unsigned fract __satfractutauhq (unsigned long 2389 long accum A) 2390 -- Runtime Function: unsigned long fract __satfractutausq (unsigned 2391 long long accum A) 2392 -- Runtime Function: unsigned long long fract __satfractutaudq 2393 (unsigned long long accum A) 2394 -- Runtime Function: unsigned short accum __satfractutauha2 (unsigned 2395 long long accum A) 2396 -- Runtime Function: unsigned accum __satfractutausa2 (unsigned long 2397 long accum A) 2398 -- Runtime Function: unsigned long accum __satfractutauda2 (unsigned 2399 long long accum A) 2400 -- Runtime Function: short fract __satfractqiqq (signed char A) 2401 -- Runtime Function: fract __satfractqihq (signed char A) 2402 -- Runtime Function: long fract __satfractqisq (signed char A) 2403 -- Runtime Function: long long fract __satfractqidq (signed char A) 2404 -- Runtime Function: short accum __satfractqiha (signed char A) 2405 -- Runtime Function: accum __satfractqisa (signed char A) 2406 -- Runtime Function: long accum __satfractqida (signed char A) 2407 -- Runtime Function: long long accum __satfractqita (signed char A) 2408 -- Runtime Function: unsigned short fract __satfractqiuqq (signed char 2409 A) 2410 -- Runtime Function: unsigned fract __satfractqiuhq (signed char A) 2411 -- Runtime Function: unsigned long fract __satfractqiusq (signed char 2412 A) 2413 -- Runtime Function: unsigned long long fract __satfractqiudq (signed 2414 char A) 2415 -- Runtime Function: unsigned short accum __satfractqiuha (signed char 2416 A) 2417 -- Runtime Function: unsigned accum __satfractqiusa (signed char A) 2418 -- Runtime Function: unsigned long accum __satfractqiuda (signed char 2419 A) 2420 -- Runtime Function: unsigned long long accum __satfractqiuta (signed 2421 char A) 2422 -- Runtime Function: short fract __satfracthiqq (short A) 2423 -- Runtime Function: fract __satfracthihq (short A) 2424 -- Runtime Function: long fract __satfracthisq (short A) 2425 -- Runtime Function: long long fract __satfracthidq (short A) 2426 -- Runtime Function: short accum __satfracthiha (short A) 2427 -- Runtime Function: accum __satfracthisa (short A) 2428 -- Runtime Function: long accum __satfracthida (short A) 2429 -- Runtime Function: long long accum __satfracthita (short A) 2430 -- Runtime Function: unsigned short fract __satfracthiuqq (short A) 2431 -- Runtime Function: unsigned fract __satfracthiuhq (short A) 2432 -- Runtime Function: unsigned long fract __satfracthiusq (short A) 2433 -- Runtime Function: unsigned long long fract __satfracthiudq (short A) 2434 -- Runtime Function: unsigned short accum __satfracthiuha (short A) 2435 -- Runtime Function: unsigned accum __satfracthiusa (short A) 2436 -- Runtime Function: unsigned long accum __satfracthiuda (short A) 2437 -- Runtime Function: unsigned long long accum __satfracthiuta (short A) 2438 -- Runtime Function: short fract __satfractsiqq (int A) 2439 -- Runtime Function: fract __satfractsihq (int A) 2440 -- Runtime Function: long fract __satfractsisq (int A) 2441 -- Runtime Function: long long fract __satfractsidq (int A) 2442 -- Runtime Function: short accum __satfractsiha (int A) 2443 -- Runtime Function: accum __satfractsisa (int A) 2444 -- Runtime Function: long accum __satfractsida (int A) 2445 -- Runtime Function: long long accum __satfractsita (int A) 2446 -- Runtime Function: unsigned short fract __satfractsiuqq (int A) 2447 -- Runtime Function: unsigned fract __satfractsiuhq (int A) 2448 -- Runtime Function: unsigned long fract __satfractsiusq (int A) 2449 -- Runtime Function: unsigned long long fract __satfractsiudq (int A) 2450 -- Runtime Function: unsigned short accum __satfractsiuha (int A) 2451 -- Runtime Function: unsigned accum __satfractsiusa (int A) 2452 -- Runtime Function: unsigned long accum __satfractsiuda (int A) 2453 -- Runtime Function: unsigned long long accum __satfractsiuta (int A) 2454 -- Runtime Function: short fract __satfractdiqq (long A) 2455 -- Runtime Function: fract __satfractdihq (long A) 2456 -- Runtime Function: long fract __satfractdisq (long A) 2457 -- Runtime Function: long long fract __satfractdidq (long A) 2458 -- Runtime Function: short accum __satfractdiha (long A) 2459 -- Runtime Function: accum __satfractdisa (long A) 2460 -- Runtime Function: long accum __satfractdida (long A) 2461 -- Runtime Function: long long accum __satfractdita (long A) 2462 -- Runtime Function: unsigned short fract __satfractdiuqq (long A) 2463 -- Runtime Function: unsigned fract __satfractdiuhq (long A) 2464 -- Runtime Function: unsigned long fract __satfractdiusq (long A) 2465 -- Runtime Function: unsigned long long fract __satfractdiudq (long A) 2466 -- Runtime Function: unsigned short accum __satfractdiuha (long A) 2467 -- Runtime Function: unsigned accum __satfractdiusa (long A) 2468 -- Runtime Function: unsigned long accum __satfractdiuda (long A) 2469 -- Runtime Function: unsigned long long accum __satfractdiuta (long A) 2470 -- Runtime Function: short fract __satfracttiqq (long long A) 2471 -- Runtime Function: fract __satfracttihq (long long A) 2472 -- Runtime Function: long fract __satfracttisq (long long A) 2473 -- Runtime Function: long long fract __satfracttidq (long long A) 2474 -- Runtime Function: short accum __satfracttiha (long long A) 2475 -- Runtime Function: accum __satfracttisa (long long A) 2476 -- Runtime Function: long accum __satfracttida (long long A) 2477 -- Runtime Function: long long accum __satfracttita (long long A) 2478 -- Runtime Function: unsigned short fract __satfracttiuqq (long long A) 2479 -- Runtime Function: unsigned fract __satfracttiuhq (long long A) 2480 -- Runtime Function: unsigned long fract __satfracttiusq (long long A) 2481 -- Runtime Function: unsigned long long fract __satfracttiudq (long 2482 long A) 2483 -- Runtime Function: unsigned short accum __satfracttiuha (long long A) 2484 -- Runtime Function: unsigned accum __satfracttiusa (long long A) 2485 -- Runtime Function: unsigned long accum __satfracttiuda (long long A) 2486 -- Runtime Function: unsigned long long accum __satfracttiuta (long 2487 long A) 2488 -- Runtime Function: short fract __satfractsfqq (float A) 2489 -- Runtime Function: fract __satfractsfhq (float A) 2490 -- Runtime Function: long fract __satfractsfsq (float A) 2491 -- Runtime Function: long long fract __satfractsfdq (float A) 2492 -- Runtime Function: short accum __satfractsfha (float A) 2493 -- Runtime Function: accum __satfractsfsa (float A) 2494 -- Runtime Function: long accum __satfractsfda (float A) 2495 -- Runtime Function: long long accum __satfractsfta (float A) 2496 -- Runtime Function: unsigned short fract __satfractsfuqq (float A) 2497 -- Runtime Function: unsigned fract __satfractsfuhq (float A) 2498 -- Runtime Function: unsigned long fract __satfractsfusq (float A) 2499 -- Runtime Function: unsigned long long fract __satfractsfudq (float A) 2500 -- Runtime Function: unsigned short accum __satfractsfuha (float A) 2501 -- Runtime Function: unsigned accum __satfractsfusa (float A) 2502 -- Runtime Function: unsigned long accum __satfractsfuda (float A) 2503 -- Runtime Function: unsigned long long accum __satfractsfuta (float A) 2504 -- Runtime Function: short fract __satfractdfqq (double A) 2505 -- Runtime Function: fract __satfractdfhq (double A) 2506 -- Runtime Function: long fract __satfractdfsq (double A) 2507 -- Runtime Function: long long fract __satfractdfdq (double A) 2508 -- Runtime Function: short accum __satfractdfha (double A) 2509 -- Runtime Function: accum __satfractdfsa (double A) 2510 -- Runtime Function: long accum __satfractdfda (double A) 2511 -- Runtime Function: long long accum __satfractdfta (double A) 2512 -- Runtime Function: unsigned short fract __satfractdfuqq (double A) 2513 -- Runtime Function: unsigned fract __satfractdfuhq (double A) 2514 -- Runtime Function: unsigned long fract __satfractdfusq (double A) 2515 -- Runtime Function: unsigned long long fract __satfractdfudq (double 2516 A) 2517 -- Runtime Function: unsigned short accum __satfractdfuha (double A) 2518 -- Runtime Function: unsigned accum __satfractdfusa (double A) 2519 -- Runtime Function: unsigned long accum __satfractdfuda (double A) 2520 -- Runtime Function: unsigned long long accum __satfractdfuta (double 2521 A) 2522 The functions convert from fractional and signed non-fractionals to 2523 fractionals, with saturation. 2524 2525 -- Runtime Function: unsigned char __fractunsqqqi (short fract A) 2526 -- Runtime Function: unsigned short __fractunsqqhi (short fract A) 2527 -- Runtime Function: unsigned int __fractunsqqsi (short fract A) 2528 -- Runtime Function: unsigned long __fractunsqqdi (short fract A) 2529 -- Runtime Function: unsigned long long __fractunsqqti (short fract A) 2530 -- Runtime Function: unsigned char __fractunshqqi (fract A) 2531 -- Runtime Function: unsigned short __fractunshqhi (fract A) 2532 -- Runtime Function: unsigned int __fractunshqsi (fract A) 2533 -- Runtime Function: unsigned long __fractunshqdi (fract A) 2534 -- Runtime Function: unsigned long long __fractunshqti (fract A) 2535 -- Runtime Function: unsigned char __fractunssqqi (long fract A) 2536 -- Runtime Function: unsigned short __fractunssqhi (long fract A) 2537 -- Runtime Function: unsigned int __fractunssqsi (long fract A) 2538 -- Runtime Function: unsigned long __fractunssqdi (long fract A) 2539 -- Runtime Function: unsigned long long __fractunssqti (long fract A) 2540 -- Runtime Function: unsigned char __fractunsdqqi (long long fract A) 2541 -- Runtime Function: unsigned short __fractunsdqhi (long long fract A) 2542 -- Runtime Function: unsigned int __fractunsdqsi (long long fract A) 2543 -- Runtime Function: unsigned long __fractunsdqdi (long long fract A) 2544 -- Runtime Function: unsigned long long __fractunsdqti (long long fract 2545 A) 2546 -- Runtime Function: unsigned char __fractunshaqi (short accum A) 2547 -- Runtime Function: unsigned short __fractunshahi (short accum A) 2548 -- Runtime Function: unsigned int __fractunshasi (short accum A) 2549 -- Runtime Function: unsigned long __fractunshadi (short accum A) 2550 -- Runtime Function: unsigned long long __fractunshati (short accum A) 2551 -- Runtime Function: unsigned char __fractunssaqi (accum A) 2552 -- Runtime Function: unsigned short __fractunssahi (accum A) 2553 -- Runtime Function: unsigned int __fractunssasi (accum A) 2554 -- Runtime Function: unsigned long __fractunssadi (accum A) 2555 -- Runtime Function: unsigned long long __fractunssati (accum A) 2556 -- Runtime Function: unsigned char __fractunsdaqi (long accum A) 2557 -- Runtime Function: unsigned short __fractunsdahi (long accum A) 2558 -- Runtime Function: unsigned int __fractunsdasi (long accum A) 2559 -- Runtime Function: unsigned long __fractunsdadi (long accum A) 2560 -- Runtime Function: unsigned long long __fractunsdati (long accum A) 2561 -- Runtime Function: unsigned char __fractunstaqi (long long accum A) 2562 -- Runtime Function: unsigned short __fractunstahi (long long accum A) 2563 -- Runtime Function: unsigned int __fractunstasi (long long accum A) 2564 -- Runtime Function: unsigned long __fractunstadi (long long accum A) 2565 -- Runtime Function: unsigned long long __fractunstati (long long accum 2566 A) 2567 -- Runtime Function: unsigned char __fractunsuqqqi (unsigned short 2568 fract A) 2569 -- Runtime Function: unsigned short __fractunsuqqhi (unsigned short 2570 fract A) 2571 -- Runtime Function: unsigned int __fractunsuqqsi (unsigned short fract 2572 A) 2573 -- Runtime Function: unsigned long __fractunsuqqdi (unsigned short 2574 fract A) 2575 -- Runtime Function: unsigned long long __fractunsuqqti (unsigned short 2576 fract A) 2577 -- Runtime Function: unsigned char __fractunsuhqqi (unsigned fract A) 2578 -- Runtime Function: unsigned short __fractunsuhqhi (unsigned fract A) 2579 -- Runtime Function: unsigned int __fractunsuhqsi (unsigned fract A) 2580 -- Runtime Function: unsigned long __fractunsuhqdi (unsigned fract A) 2581 -- Runtime Function: unsigned long long __fractunsuhqti (unsigned fract 2582 A) 2583 -- Runtime Function: unsigned char __fractunsusqqi (unsigned long fract 2584 A) 2585 -- Runtime Function: unsigned short __fractunsusqhi (unsigned long 2586 fract A) 2587 -- Runtime Function: unsigned int __fractunsusqsi (unsigned long fract 2588 A) 2589 -- Runtime Function: unsigned long __fractunsusqdi (unsigned long fract 2590 A) 2591 -- Runtime Function: unsigned long long __fractunsusqti (unsigned long 2592 fract A) 2593 -- Runtime Function: unsigned char __fractunsudqqi (unsigned long long 2594 fract A) 2595 -- Runtime Function: unsigned short __fractunsudqhi (unsigned long long 2596 fract A) 2597 -- Runtime Function: unsigned int __fractunsudqsi (unsigned long long 2598 fract A) 2599 -- Runtime Function: unsigned long __fractunsudqdi (unsigned long long 2600 fract A) 2601 -- Runtime Function: unsigned long long __fractunsudqti (unsigned long 2602 long fract A) 2603 -- Runtime Function: unsigned char __fractunsuhaqi (unsigned short 2604 accum A) 2605 -- Runtime Function: unsigned short __fractunsuhahi (unsigned short 2606 accum A) 2607 -- Runtime Function: unsigned int __fractunsuhasi (unsigned short accum 2608 A) 2609 -- Runtime Function: unsigned long __fractunsuhadi (unsigned short 2610 accum A) 2611 -- Runtime Function: unsigned long long __fractunsuhati (unsigned short 2612 accum A) 2613 -- Runtime Function: unsigned char __fractunsusaqi (unsigned accum A) 2614 -- Runtime Function: unsigned short __fractunsusahi (unsigned accum A) 2615 -- Runtime Function: unsigned int __fractunsusasi (unsigned accum A) 2616 -- Runtime Function: unsigned long __fractunsusadi (unsigned accum A) 2617 -- Runtime Function: unsigned long long __fractunsusati (unsigned accum 2618 A) 2619 -- Runtime Function: unsigned char __fractunsudaqi (unsigned long accum 2620 A) 2621 -- Runtime Function: unsigned short __fractunsudahi (unsigned long 2622 accum A) 2623 -- Runtime Function: unsigned int __fractunsudasi (unsigned long accum 2624 A) 2625 -- Runtime Function: unsigned long __fractunsudadi (unsigned long accum 2626 A) 2627 -- Runtime Function: unsigned long long __fractunsudati (unsigned long 2628 accum A) 2629 -- Runtime Function: unsigned char __fractunsutaqi (unsigned long long 2630 accum A) 2631 -- Runtime Function: unsigned short __fractunsutahi (unsigned long long 2632 accum A) 2633 -- Runtime Function: unsigned int __fractunsutasi (unsigned long long 2634 accum A) 2635 -- Runtime Function: unsigned long __fractunsutadi (unsigned long long 2636 accum A) 2637 -- Runtime Function: unsigned long long __fractunsutati (unsigned long 2638 long accum A) 2639 -- Runtime Function: short fract __fractunsqiqq (unsigned char A) 2640 -- Runtime Function: fract __fractunsqihq (unsigned char A) 2641 -- Runtime Function: long fract __fractunsqisq (unsigned char A) 2642 -- Runtime Function: long long fract __fractunsqidq (unsigned char A) 2643 -- Runtime Function: short accum __fractunsqiha (unsigned char A) 2644 -- Runtime Function: accum __fractunsqisa (unsigned char A) 2645 -- Runtime Function: long accum __fractunsqida (unsigned char A) 2646 -- Runtime Function: long long accum __fractunsqita (unsigned char A) 2647 -- Runtime Function: unsigned short fract __fractunsqiuqq (unsigned 2648 char A) 2649 -- Runtime Function: unsigned fract __fractunsqiuhq (unsigned char A) 2650 -- Runtime Function: unsigned long fract __fractunsqiusq (unsigned char 2651 A) 2652 -- Runtime Function: unsigned long long fract __fractunsqiudq (unsigned 2653 char A) 2654 -- Runtime Function: unsigned short accum __fractunsqiuha (unsigned 2655 char A) 2656 -- Runtime Function: unsigned accum __fractunsqiusa (unsigned char A) 2657 -- Runtime Function: unsigned long accum __fractunsqiuda (unsigned char 2658 A) 2659 -- Runtime Function: unsigned long long accum __fractunsqiuta (unsigned 2660 char A) 2661 -- Runtime Function: short fract __fractunshiqq (unsigned short A) 2662 -- Runtime Function: fract __fractunshihq (unsigned short A) 2663 -- Runtime Function: long fract __fractunshisq (unsigned short A) 2664 -- Runtime Function: long long fract __fractunshidq (unsigned short A) 2665 -- Runtime Function: short accum __fractunshiha (unsigned short A) 2666 -- Runtime Function: accum __fractunshisa (unsigned short A) 2667 -- Runtime Function: long accum __fractunshida (unsigned short A) 2668 -- Runtime Function: long long accum __fractunshita (unsigned short A) 2669 -- Runtime Function: unsigned short fract __fractunshiuqq (unsigned 2670 short A) 2671 -- Runtime Function: unsigned fract __fractunshiuhq (unsigned short A) 2672 -- Runtime Function: unsigned long fract __fractunshiusq (unsigned 2673 short A) 2674 -- Runtime Function: unsigned long long fract __fractunshiudq (unsigned 2675 short A) 2676 -- Runtime Function: unsigned short accum __fractunshiuha (unsigned 2677 short A) 2678 -- Runtime Function: unsigned accum __fractunshiusa (unsigned short A) 2679 -- Runtime Function: unsigned long accum __fractunshiuda (unsigned 2680 short A) 2681 -- Runtime Function: unsigned long long accum __fractunshiuta (unsigned 2682 short A) 2683 -- Runtime Function: short fract __fractunssiqq (unsigned int A) 2684 -- Runtime Function: fract __fractunssihq (unsigned int A) 2685 -- Runtime Function: long fract __fractunssisq (unsigned int A) 2686 -- Runtime Function: long long fract __fractunssidq (unsigned int A) 2687 -- Runtime Function: short accum __fractunssiha (unsigned int A) 2688 -- Runtime Function: accum __fractunssisa (unsigned int A) 2689 -- Runtime Function: long accum __fractunssida (unsigned int A) 2690 -- Runtime Function: long long accum __fractunssita (unsigned int A) 2691 -- Runtime Function: unsigned short fract __fractunssiuqq (unsigned int 2692 A) 2693 -- Runtime Function: unsigned fract __fractunssiuhq (unsigned int A) 2694 -- Runtime Function: unsigned long fract __fractunssiusq (unsigned int 2695 A) 2696 -- Runtime Function: unsigned long long fract __fractunssiudq (unsigned 2697 int A) 2698 -- Runtime Function: unsigned short accum __fractunssiuha (unsigned int 2699 A) 2700 -- Runtime Function: unsigned accum __fractunssiusa (unsigned int A) 2701 -- Runtime Function: unsigned long accum __fractunssiuda (unsigned int 2702 A) 2703 -- Runtime Function: unsigned long long accum __fractunssiuta (unsigned 2704 int A) 2705 -- Runtime Function: short fract __fractunsdiqq (unsigned long A) 2706 -- Runtime Function: fract __fractunsdihq (unsigned long A) 2707 -- Runtime Function: long fract __fractunsdisq (unsigned long A) 2708 -- Runtime Function: long long fract __fractunsdidq (unsigned long A) 2709 -- Runtime Function: short accum __fractunsdiha (unsigned long A) 2710 -- Runtime Function: accum __fractunsdisa (unsigned long A) 2711 -- Runtime Function: long accum __fractunsdida (unsigned long A) 2712 -- Runtime Function: long long accum __fractunsdita (unsigned long A) 2713 -- Runtime Function: unsigned short fract __fractunsdiuqq (unsigned 2714 long A) 2715 -- Runtime Function: unsigned fract __fractunsdiuhq (unsigned long A) 2716 -- Runtime Function: unsigned long fract __fractunsdiusq (unsigned long 2717 A) 2718 -- Runtime Function: unsigned long long fract __fractunsdiudq (unsigned 2719 long A) 2720 -- Runtime Function: unsigned short accum __fractunsdiuha (unsigned 2721 long A) 2722 -- Runtime Function: unsigned accum __fractunsdiusa (unsigned long A) 2723 -- Runtime Function: unsigned long accum __fractunsdiuda (unsigned long 2724 A) 2725 -- Runtime Function: unsigned long long accum __fractunsdiuta (unsigned 2726 long A) 2727 -- Runtime Function: short fract __fractunstiqq (unsigned long long A) 2728 -- Runtime Function: fract __fractunstihq (unsigned long long A) 2729 -- Runtime Function: long fract __fractunstisq (unsigned long long A) 2730 -- Runtime Function: long long fract __fractunstidq (unsigned long long 2731 A) 2732 -- Runtime Function: short accum __fractunstiha (unsigned long long A) 2733 -- Runtime Function: accum __fractunstisa (unsigned long long A) 2734 -- Runtime Function: long accum __fractunstida (unsigned long long A) 2735 -- Runtime Function: long long accum __fractunstita (unsigned long long 2736 A) 2737 -- Runtime Function: unsigned short fract __fractunstiuqq (unsigned 2738 long long A) 2739 -- Runtime Function: unsigned fract __fractunstiuhq (unsigned long long 2740 A) 2741 -- Runtime Function: unsigned long fract __fractunstiusq (unsigned long 2742 long A) 2743 -- Runtime Function: unsigned long long fract __fractunstiudq (unsigned 2744 long long A) 2745 -- Runtime Function: unsigned short accum __fractunstiuha (unsigned 2746 long long A) 2747 -- Runtime Function: unsigned accum __fractunstiusa (unsigned long long 2748 A) 2749 -- Runtime Function: unsigned long accum __fractunstiuda (unsigned long 2750 long A) 2751 -- Runtime Function: unsigned long long accum __fractunstiuta (unsigned 2752 long long A) 2753 These functions convert from fractionals to unsigned 2754 non-fractionals; and from unsigned non-fractionals to fractionals, 2755 without saturation. 2756 2757 -- Runtime Function: short fract __satfractunsqiqq (unsigned char A) 2758 -- Runtime Function: fract __satfractunsqihq (unsigned char A) 2759 -- Runtime Function: long fract __satfractunsqisq (unsigned char A) 2760 -- Runtime Function: long long fract __satfractunsqidq (unsigned char 2761 A) 2762 -- Runtime Function: short accum __satfractunsqiha (unsigned char A) 2763 -- Runtime Function: accum __satfractunsqisa (unsigned char A) 2764 -- Runtime Function: long accum __satfractunsqida (unsigned char A) 2765 -- Runtime Function: long long accum __satfractunsqita (unsigned char 2766 A) 2767 -- Runtime Function: unsigned short fract __satfractunsqiuqq (unsigned 2768 char A) 2769 -- Runtime Function: unsigned fract __satfractunsqiuhq (unsigned char 2770 A) 2771 -- Runtime Function: unsigned long fract __satfractunsqiusq (unsigned 2772 char A) 2773 -- Runtime Function: unsigned long long fract __satfractunsqiudq 2774 (unsigned char A) 2775 -- Runtime Function: unsigned short accum __satfractunsqiuha (unsigned 2776 char A) 2777 -- Runtime Function: unsigned accum __satfractunsqiusa (unsigned char 2778 A) 2779 -- Runtime Function: unsigned long accum __satfractunsqiuda (unsigned 2780 char A) 2781 -- Runtime Function: unsigned long long accum __satfractunsqiuta 2782 (unsigned char A) 2783 -- Runtime Function: short fract __satfractunshiqq (unsigned short A) 2784 -- Runtime Function: fract __satfractunshihq (unsigned short A) 2785 -- Runtime Function: long fract __satfractunshisq (unsigned short A) 2786 -- Runtime Function: long long fract __satfractunshidq (unsigned short 2787 A) 2788 -- Runtime Function: short accum __satfractunshiha (unsigned short A) 2789 -- Runtime Function: accum __satfractunshisa (unsigned short A) 2790 -- Runtime Function: long accum __satfractunshida (unsigned short A) 2791 -- Runtime Function: long long accum __satfractunshita (unsigned short 2792 A) 2793 -- Runtime Function: unsigned short fract __satfractunshiuqq (unsigned 2794 short A) 2795 -- Runtime Function: unsigned fract __satfractunshiuhq (unsigned short 2796 A) 2797 -- Runtime Function: unsigned long fract __satfractunshiusq (unsigned 2798 short A) 2799 -- Runtime Function: unsigned long long fract __satfractunshiudq 2800 (unsigned short A) 2801 -- Runtime Function: unsigned short accum __satfractunshiuha (unsigned 2802 short A) 2803 -- Runtime Function: unsigned accum __satfractunshiusa (unsigned short 2804 A) 2805 -- Runtime Function: unsigned long accum __satfractunshiuda (unsigned 2806 short A) 2807 -- Runtime Function: unsigned long long accum __satfractunshiuta 2808 (unsigned short A) 2809 -- Runtime Function: short fract __satfractunssiqq (unsigned int A) 2810 -- Runtime Function: fract __satfractunssihq (unsigned int A) 2811 -- Runtime Function: long fract __satfractunssisq (unsigned int A) 2812 -- Runtime Function: long long fract __satfractunssidq (unsigned int A) 2813 -- Runtime Function: short accum __satfractunssiha (unsigned int A) 2814 -- Runtime Function: accum __satfractunssisa (unsigned int A) 2815 -- Runtime Function: long accum __satfractunssida (unsigned int A) 2816 -- Runtime Function: long long accum __satfractunssita (unsigned int A) 2817 -- Runtime Function: unsigned short fract __satfractunssiuqq (unsigned 2818 int A) 2819 -- Runtime Function: unsigned fract __satfractunssiuhq (unsigned int A) 2820 -- Runtime Function: unsigned long fract __satfractunssiusq (unsigned 2821 int A) 2822 -- Runtime Function: unsigned long long fract __satfractunssiudq 2823 (unsigned int A) 2824 -- Runtime Function: unsigned short accum __satfractunssiuha (unsigned 2825 int A) 2826 -- Runtime Function: unsigned accum __satfractunssiusa (unsigned int A) 2827 -- Runtime Function: unsigned long accum __satfractunssiuda (unsigned 2828 int A) 2829 -- Runtime Function: unsigned long long accum __satfractunssiuta 2830 (unsigned int A) 2831 -- Runtime Function: short fract __satfractunsdiqq (unsigned long A) 2832 -- Runtime Function: fract __satfractunsdihq (unsigned long A) 2833 -- Runtime Function: long fract __satfractunsdisq (unsigned long A) 2834 -- Runtime Function: long long fract __satfractunsdidq (unsigned long 2835 A) 2836 -- Runtime Function: short accum __satfractunsdiha (unsigned long A) 2837 -- Runtime Function: accum __satfractunsdisa (unsigned long A) 2838 -- Runtime Function: long accum __satfractunsdida (unsigned long A) 2839 -- Runtime Function: long long accum __satfractunsdita (unsigned long 2840 A) 2841 -- Runtime Function: unsigned short fract __satfractunsdiuqq (unsigned 2842 long A) 2843 -- Runtime Function: unsigned fract __satfractunsdiuhq (unsigned long 2844 A) 2845 -- Runtime Function: unsigned long fract __satfractunsdiusq (unsigned 2846 long A) 2847 -- Runtime Function: unsigned long long fract __satfractunsdiudq 2848 (unsigned long A) 2849 -- Runtime Function: unsigned short accum __satfractunsdiuha (unsigned 2850 long A) 2851 -- Runtime Function: unsigned accum __satfractunsdiusa (unsigned long 2852 A) 2853 -- Runtime Function: unsigned long accum __satfractunsdiuda (unsigned 2854 long A) 2855 -- Runtime Function: unsigned long long accum __satfractunsdiuta 2856 (unsigned long A) 2857 -- Runtime Function: short fract __satfractunstiqq (unsigned long long 2858 A) 2859 -- Runtime Function: fract __satfractunstihq (unsigned long long A) 2860 -- Runtime Function: long fract __satfractunstisq (unsigned long long 2861 A) 2862 -- Runtime Function: long long fract __satfractunstidq (unsigned long 2863 long A) 2864 -- Runtime Function: short accum __satfractunstiha (unsigned long long 2865 A) 2866 -- Runtime Function: accum __satfractunstisa (unsigned long long A) 2867 -- Runtime Function: long accum __satfractunstida (unsigned long long 2868 A) 2869 -- Runtime Function: long long accum __satfractunstita (unsigned long 2870 long A) 2871 -- Runtime Function: unsigned short fract __satfractunstiuqq (unsigned 2872 long long A) 2873 -- Runtime Function: unsigned fract __satfractunstiuhq (unsigned long 2874 long A) 2875 -- Runtime Function: unsigned long fract __satfractunstiusq (unsigned 2876 long long A) 2877 -- Runtime Function: unsigned long long fract __satfractunstiudq 2878 (unsigned long long A) 2879 -- Runtime Function: unsigned short accum __satfractunstiuha (unsigned 2880 long long A) 2881 -- Runtime Function: unsigned accum __satfractunstiusa (unsigned long 2882 long A) 2883 -- Runtime Function: unsigned long accum __satfractunstiuda (unsigned 2884 long long A) 2885 -- Runtime Function: unsigned long long accum __satfractunstiuta 2886 (unsigned long long A) 2887 These functions convert from unsigned non-fractionals to 2888 fractionals, with saturation. 2889 2890 2891File: gccint.info, Node: Exception handling routines, Next: Miscellaneous routines, Prev: Fixed-point fractional library routines, Up: Libgcc 2892 28934.5 Language-independent routines for exception handling 2894======================================================== 2895 2896document me! 2897 2898 _Unwind_DeleteException 2899 _Unwind_Find_FDE 2900 _Unwind_ForcedUnwind 2901 _Unwind_GetGR 2902 _Unwind_GetIP 2903 _Unwind_GetLanguageSpecificData 2904 _Unwind_GetRegionStart 2905 _Unwind_GetTextRelBase 2906 _Unwind_GetDataRelBase 2907 _Unwind_RaiseException 2908 _Unwind_Resume 2909 _Unwind_SetGR 2910 _Unwind_SetIP 2911 _Unwind_FindEnclosingFunction 2912 _Unwind_SjLj_Register 2913 _Unwind_SjLj_Unregister 2914 _Unwind_SjLj_RaiseException 2915 _Unwind_SjLj_ForcedUnwind 2916 _Unwind_SjLj_Resume 2917 __deregister_frame 2918 __deregister_frame_info 2919 __deregister_frame_info_bases 2920 __register_frame 2921 __register_frame_info 2922 __register_frame_info_bases 2923 __register_frame_info_table 2924 __register_frame_info_table_bases 2925 __register_frame_table 2926 2927 2928File: gccint.info, Node: Miscellaneous routines, Prev: Exception handling routines, Up: Libgcc 2929 29304.6 Miscellaneous runtime library routines 2931========================================== 2932 29334.6.1 Cache control functions 2934----------------------------- 2935 2936 -- Runtime Function: void __clear_cache (char *BEG, char *END) 2937 This function clears the instruction cache between BEG and END. 2938 29394.6.2 Split stack functions and variables 2940----------------------------------------- 2941 2942 -- Runtime Function: void * __splitstack_find (void *SEGMENT_ARG, void 2943 *SP, size_t LEN, void **NEXT_SEGMENT, void **NEXT_SP, void 2944 **INITIAL_SP) 2945 When using '-fsplit-stack', this call may be used to iterate over 2946 the stack segments. It may be called like this: 2947 void *next_segment = NULL; 2948 void *next_sp = NULL; 2949 void *initial_sp = NULL; 2950 void *stack; 2951 size_t stack_size; 2952 while ((stack = __splitstack_find (next_segment, next_sp, 2953 &stack_size, &next_segment, 2954 &next_sp, &initial_sp)) 2955 != NULL) 2956 { 2957 /* Stack segment starts at stack and is 2958 stack_size bytes long. */ 2959 } 2960 2961 There is no way to iterate over the stack segments of a different 2962 thread. However, what is permitted is for one thread to call this 2963 with the SEGMENT_ARG and SP arguments NULL, to pass NEXT_SEGMENT, 2964 NEXT_SP, and INITIAL_SP to a different thread, and then to suspend 2965 one way or another. A different thread may run the subsequent 2966 '__splitstack_find' iterations. Of course, this will only work if 2967 the first thread is suspended while the second thread is calling 2968 '__splitstack_find'. If not, the second thread could be looking at 2969 the stack while it is changing, and anything could happen. 2970 2971 -- Variable: __morestack_segments 2972 -- Variable: __morestack_current_segment 2973 -- Variable: __morestack_initial_sp 2974 Internal variables used by the '-fsplit-stack' implementation. 2975 2976 2977File: gccint.info, Node: Languages, Next: Source Tree, Prev: Libgcc, Up: Top 2978 29795 Language Front Ends in GCC 2980**************************** 2981 2982The interface to front ends for languages in GCC, and in particular the 2983'tree' structure (*note GENERIC::), was initially designed for C, and 2984many aspects of it are still somewhat biased towards C and C-like 2985languages. It is, however, reasonably well suited to other procedural 2986languages, and front ends for many such languages have been written for 2987GCC. 2988 2989 Writing a compiler as a front end for GCC, rather than compiling 2990directly to assembler or generating C code which is then compiled by 2991GCC, has several advantages: 2992 2993 * GCC front ends benefit from the support for many different target 2994 machines already present in GCC. 2995 * GCC front ends benefit from all the optimizations in GCC. Some of 2996 these, such as alias analysis, may work better when GCC is 2997 compiling directly from source code then when it is compiling from 2998 generated C code. 2999 * Better debugging information is generated when compiling directly 3000 from source code than when going via intermediate generated C code. 3001 3002 Because of the advantages of writing a compiler as a GCC front end, GCC 3003front ends have also been created for languages very different from 3004those for which GCC was designed, such as the declarative 3005logic/functional language Mercury. For these reasons, it may also be 3006useful to implement compilers created for specialized purposes (for 3007example, as part of a research project) as GCC front ends. 3008 3009 3010File: gccint.info, Node: Source Tree, Next: Testsuites, Prev: Languages, Up: Top 3011 30126 Source Tree Structure and Build System 3013**************************************** 3014 3015This chapter describes the structure of the GCC source tree, and how GCC 3016is built. The user documentation for building and installing GCC is in 3017a separate manual (<http://gcc.gnu.org/install/>), with which it is 3018presumed that you are familiar. 3019 3020* Menu: 3021 3022* Configure Terms:: Configuration terminology and history. 3023* Top Level:: The top level source directory. 3024* gcc Directory:: The 'gcc' subdirectory. 3025 3026 3027File: gccint.info, Node: Configure Terms, Next: Top Level, Up: Source Tree 3028 30296.1 Configure Terms and History 3030=============================== 3031 3032The configure and build process has a long and colorful history, and can 3033be confusing to anyone who doesn't know why things are the way they are. 3034While there are other documents which describe the configuration process 3035in detail, here are a few things that everyone working on GCC should 3036know. 3037 3038 There are three system names that the build knows about: the machine 3039you are building on ("build"), the machine that you are building for 3040("host"), and the machine that GCC will produce code for ("target"). 3041When you configure GCC, you specify these with '--build=', '--host=', 3042and '--target='. 3043 3044 Specifying the host without specifying the build should be avoided, as 3045'configure' may (and once did) assume that the host you specify is also 3046the build, which may not be true. 3047 3048 If build, host, and target are all the same, this is called a "native". 3049If build and host are the same but target is different, this is called a 3050"cross". If build, host, and target are all different this is called a 3051"canadian" (for obscure reasons dealing with Canada's political party 3052and the background of the person working on the build at that time). If 3053host and target are the same, but build is different, you are using a 3054cross-compiler to build a native for a different system. Some people 3055call this a "host-x-host", "crossed native", or "cross-built native". 3056If build and target are the same, but host is different, you are using a 3057cross compiler to build a cross compiler that produces code for the 3058machine you're building on. This is rare, so there is no common way of 3059describing it. There is a proposal to call this a "crossback". 3060 3061 If build and host are the same, the GCC you are building will also be 3062used to build the target libraries (like 'libstdc++'). If build and 3063host are different, you must have already built and installed a cross 3064compiler that will be used to build the target libraries (if you 3065configured with '--target=foo-bar', this compiler will be called 3066'foo-bar-gcc'). 3067 3068 In the case of target libraries, the machine you're building for is the 3069machine you specified with '--target'. So, build is the machine you're 3070building on (no change there), host is the machine you're building for 3071(the target libraries are built for the target, so host is the target 3072you specified), and target doesn't apply (because you're not building a 3073compiler, you're building libraries). The configure/make process will 3074adjust these variables as needed. It also sets '$with_cross_host' to 3075the original '--host' value in case you need it. 3076 3077 The 'libiberty' support library is built up to three times: once for 3078the host, once for the target (even if they are the same), and once for 3079the build if build and host are different. This allows it to be used by 3080all programs which are generated in the course of the build process. 3081 3082 3083File: gccint.info, Node: Top Level, Next: gcc Directory, Prev: Configure Terms, Up: Source Tree 3084 30856.2 Top Level Source Directory 3086============================== 3087 3088The top level source directory in a GCC distribution contains several 3089files and directories that are shared with other software distributions 3090such as that of GNU Binutils. It also contains several subdirectories 3091that contain parts of GCC and its runtime libraries: 3092 3093'boehm-gc' 3094 The Boehm conservative garbage collector, optionally used as part 3095 of the ObjC runtime library when configured with 3096 '--enable-objc-gc'. 3097 3098'config' 3099 Autoconf macros and Makefile fragments used throughout the tree. 3100 3101'contrib' 3102 Contributed scripts that may be found useful in conjunction with 3103 GCC. One of these, 'contrib/texi2pod.pl', is used to generate man 3104 pages from Texinfo manuals as part of the GCC build process. 3105 3106'fixincludes' 3107 The support for fixing system headers to work with GCC. See 3108 'fixincludes/README' for more information. The headers fixed by 3109 this mechanism are installed in 'LIBSUBDIR/include-fixed'. Along 3110 with those headers, 'README-fixinc' is also installed, as 3111 'LIBSUBDIR/include-fixed/README'. 3112 3113'gcc' 3114 The main sources of GCC itself (except for runtime libraries), 3115 including optimizers, support for different target architectures, 3116 language front ends, and testsuites. *Note The 'gcc' Subdirectory: 3117 gcc Directory, for details. 3118 3119'gnattools' 3120 Support tools for GNAT. 3121 3122'include' 3123 Headers for the 'libiberty' library. 3124 3125'intl' 3126 GNU 'libintl', from GNU 'gettext', for systems which do not include 3127 it in 'libc'. 3128 3129'libada' 3130 The Ada runtime library. 3131 3132'libatomic' 3133 The runtime support library for atomic operations (e.g. for 3134 '__sync' and '__atomic'). 3135 3136'libcpp' 3137 The C preprocessor library. 3138 3139'libdecnumber' 3140 The Decimal Float support library. 3141 3142'libffi' 3143 The 'libffi' library, used as part of the Go runtime library. 3144 3145'libgcc' 3146 The GCC runtime library. 3147 3148'libgfortran' 3149 The Fortran runtime library. 3150 3151'libgo' 3152 The Go runtime library. The bulk of this library is mirrored from 3153 the master Go repository (https://github.com/golang/go). 3154 3155'libgomp' 3156 The GNU Offloading and Multi Processing Runtime Library. 3157 3158'libiberty' 3159 The 'libiberty' library, used for portability and for some 3160 generally useful data structures and algorithms. *Note 3161 Introduction: (libiberty)Top, for more information about this 3162 library. 3163 3164'libitm' 3165 The runtime support library for transactional memory. 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'libphobos' 3174 The D standard and runtime library. The bulk of this library is 3175 mirrored from the master D repositories (https://github.com/dlang). 3176 3177'libssp' 3178 The Stack protector runtime library. 3179 3180'libstdc++-v3' 3181 The C++ runtime library. 3182 3183'lto-plugin' 3184 Plugin used by the linker if link-time optimizations are enabled. 3185 3186'maintainer-scripts' 3187 Scripts used by the 'gccadmin' account on 'gcc.gnu.org'. 3188 3189'zlib' 3190 The 'zlib' compression library, used for compressing and 3191 uncompressing GCC's intermediate language in LTO object files. 3192 3193 The build system in the top level directory, including how recursion 3194into subdirectories works and how building runtime libraries for 3195multilibs is handled, is documented in a separate manual, included with 3196GNU Binutils. *Note GNU configure and build system: (configure)Top, for 3197details. 3198 3199 3200File: gccint.info, Node: gcc Directory, Prev: Top Level, Up: Source Tree 3201 32026.3 The 'gcc' Subdirectory 3203========================== 3204 3205The 'gcc' directory contains many files that are part of the C sources 3206of GCC, other files used as part of the configuration and build process, 3207and subdirectories including documentation and a testsuite. The files 3208that are sources of GCC are documented in a separate chapter. *Note 3209Passes and Files of the Compiler: Passes. 3210 3211* Menu: 3212 3213* Subdirectories:: Subdirectories of 'gcc'. 3214* Configuration:: The configuration process, and the files it uses. 3215* Build:: The build system in the 'gcc' directory. 3216* Makefile:: Targets in 'gcc/Makefile'. 3217* Library Files:: Library source files and headers under 'gcc/'. 3218* Headers:: Headers installed by GCC. 3219* Documentation:: Building documentation in GCC. 3220* Front End:: Anatomy of a language front end. 3221* Back End:: Anatomy of a target back end. 3222 3223 3224File: gccint.info, Node: Subdirectories, Next: Configuration, Up: gcc Directory 3225 32266.3.1 Subdirectories of 'gcc' 3227----------------------------- 3228 3229The 'gcc' directory contains the following subdirectories: 3230 3231'LANGUAGE' 3232 Subdirectories for various languages. Directories containing a 3233 file 'config-lang.in' are language subdirectories. The contents of 3234 the subdirectories 'c' (for C), 'cp' (for C++), 'objc' (for 3235 Objective-C), 'objcp' (for Objective-C++), and 'lto' (for LTO) are 3236 documented in this manual (*note Passes and Files of the Compiler: 3237 Passes.); those for other languages are not. *Note Anatomy of a 3238 Language Front End: Front End, for details of the files in these 3239 directories. 3240 3241'common' 3242 Source files shared between the compiler drivers (such as 'gcc') 3243 and the compilers proper (such as 'cc1'). If an architecture 3244 defines target hooks shared between those places, it also has a 3245 subdirectory in 'common/config'. *Note Target Structure::. 3246 3247'config' 3248 Configuration files for supported architectures and operating 3249 systems. *Note Anatomy of a Target Back End: Back End, for details 3250 of the files in this directory. 3251 3252'doc' 3253 Texinfo documentation for GCC, together with automatically 3254 generated man pages and support for converting the installation 3255 manual to HTML. *Note Documentation::. 3256 3257'ginclude' 3258 System headers installed by GCC, mainly those required by the C 3259 standard of freestanding implementations. *Note Headers Installed 3260 by GCC: Headers, for details of when these and other headers are 3261 installed. 3262 3263'po' 3264 Message catalogs with translations of messages produced by GCC into 3265 various languages, 'LANGUAGE.po'. This directory also contains 3266 'gcc.pot', the template for these message catalogues, 'exgettext', 3267 a wrapper around 'gettext' to extract the messages from the GCC 3268 sources and create 'gcc.pot', which is run by 'make gcc.pot', and 3269 'EXCLUDES', a list of files from which messages should not be 3270 extracted. 3271 3272'testsuite' 3273 The GCC testsuites (except for those for runtime libraries). *Note 3274 Testsuites::. 3275 3276 3277File: gccint.info, Node: Configuration, Next: Build, Prev: Subdirectories, Up: gcc Directory 3278 32796.3.2 Configuration in the 'gcc' Directory 3280------------------------------------------ 3281 3282The 'gcc' directory is configured with an Autoconf-generated script 3283'configure'. The 'configure' script is generated from 'configure.ac' 3284and 'aclocal.m4'. From the files 'configure.ac' and 'acconfig.h', 3285Autoheader generates the file 'config.in'. The file 'cstamp-h.in' is 3286used as a timestamp. 3287 3288* Menu: 3289 3290* Config Fragments:: Scripts used by 'configure'. 3291* System Config:: The 'config.build', 'config.host', and 3292 'config.gcc' files. 3293* Configuration Files:: Files created by running 'configure'. 3294 3295 3296File: gccint.info, Node: Config Fragments, Next: System Config, Up: Configuration 3297 32986.3.2.1 Scripts Used by 'configure' 3299................................... 3300 3301'configure' uses some other scripts to help in its work: 3302 3303 * The standard GNU 'config.sub' and 'config.guess' files, kept in the 3304 top level directory, are used. 3305 3306 * The file 'config.gcc' is used to handle configuration specific to 3307 the particular target machine. The file 'config.build' is used to 3308 handle configuration specific to the particular build machine. The 3309 file 'config.host' is used to handle configuration specific to the 3310 particular host machine. (In general, these should only be used 3311 for features that cannot reasonably be tested in Autoconf feature 3312 tests.) *Note The 'config.build'; 'config.host'; and 'config.gcc' 3313 Files: System Config, for details of the contents of these files. 3314 3315 * Each language subdirectory has a file 'LANGUAGE/config-lang.in' 3316 that is used for front-end-specific configuration. *Note The Front 3317 End 'config-lang.in' File: Front End Config, for details of this 3318 file. 3319 3320 * A helper script 'configure.frag' is used as part of creating the 3321 output of 'configure'. 3322 3323 3324File: gccint.info, Node: System Config, Next: Configuration Files, Prev: Config Fragments, Up: Configuration 3325 33266.3.2.2 The 'config.build'; 'config.host'; and 'config.gcc' Files 3327................................................................. 3328 3329The 'config.build' file contains specific rules for particular systems 3330which GCC is built on. This should be used as rarely as possible, as 3331the behavior of the build system can always be detected by autoconf. 3332 3333 The 'config.host' file contains specific rules for particular systems 3334which GCC will run on. This is rarely needed. 3335 3336 The 'config.gcc' file contains specific rules for particular systems 3337which GCC will generate code for. This is usually needed. 3338 3339 Each file has a list of the shell variables it sets, with descriptions, 3340at the top of the file. 3341 3342 FIXME: document the contents of these files, and what variables should 3343be set to control build, host and target configuration. 3344 3345 3346File: gccint.info, Node: Configuration Files, Prev: System Config, Up: Configuration 3347 33486.3.2.3 Files Created by 'configure' 3349.................................... 3350 3351Here we spell out what files will be set up by 'configure' in the 'gcc' 3352directory. Some other files are created as temporary files in the 3353configuration process, and are not used in the subsequent build; these 3354are not documented. 3355 3356 * 'Makefile' is constructed from 'Makefile.in', together with the 3357 host and target fragments (*note Makefile Fragments: Fragments.) 3358 't-TARGET' and 'x-HOST' from 'config', if any, and language 3359 Makefile fragments 'LANGUAGE/Make-lang.in'. 3360 * 'auto-host.h' contains information about the host machine 3361 determined by 'configure'. If the host machine is different from 3362 the build machine, then 'auto-build.h' is also created, containing 3363 such information about the build machine. 3364 * 'config.status' is a script that may be run to recreate the current 3365 configuration. 3366 * 'configargs.h' is a header containing details of the arguments 3367 passed to 'configure' to configure GCC, and of the thread model 3368 used. 3369 * 'cstamp-h' is used as a timestamp. 3370 * If a language 'config-lang.in' file (*note The Front End 3371 'config-lang.in' File: Front End Config.) sets 'outputs', then the 3372 files listed in 'outputs' there are also generated. 3373 3374 The following configuration headers are created from the Makefile, 3375using 'mkconfig.sh', rather than directly by 'configure'. 'config.h', 3376'bconfig.h' and 'tconfig.h' all contain the 'xm-MACHINE.h' header, if 3377any, appropriate to the host, build and target machines respectively, 3378the configuration headers for the target, and some definitions; for the 3379host and build machines, these include the autoconfigured headers 3380generated by 'configure'. The other configuration headers are 3381determined by 'config.gcc'. They also contain the typedefs for 'rtx', 3382'rtvec' and 'tree'. 3383 3384 * 'config.h', for use in programs that run on the host machine. 3385 * 'bconfig.h', for use in programs that run on the build machine. 3386 * 'tconfig.h', for use in programs and libraries for the target 3387 machine. 3388 * 'tm_p.h', which includes the header 'MACHINE-protos.h' that 3389 contains prototypes for functions in the target 'MACHINE.c' file. 3390 The 'MACHINE-protos.h' header is included after the 'rtl.h' and/or 3391 'tree.h' would have been included. The 'tm_p.h' also includes the 3392 header 'tm-preds.h' which is generated by 'genpreds' program during 3393 the 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 the 3539 installation instructions. 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 Obj-C++ front end depends on the C++ and ObjC front ends, so sets 3923 'lang_requires="objc 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 The 'MACHINE.h' header is included very early in GCC's standard 4105sequence of header files, while 'MACHINE-protos.h' is included late in 4106the sequence. Thus 'MACHINE-protos.h' can include declarations 4107referencing types that are not defined when 'MACHINE.h' is included, 4108specifically including those from 'rtl.h' and 'tree.h'. Since both RTL 4109and tree types may not be available in every context where 4110'MACHINE-protos.h' is included, in this file you should guard 4111declarations using these types inside appropriate '#ifdef RTX_CODE' or 4112'#ifdef TREE_CODE' conditional code segments. 4113 4114 If the backend uses shared data structures that require 'GTY' markers 4115for garbage collection (*note Type Information::), you must declare 4116those in 'MACHINE.h' rather than 'MACHINE-protos.h'. Any definitions 4117required for building libgcc must also go in 'MACHINE.h'. 4118 4119 GCC uses the macro 'IN_TARGET_CODE' to distinguish between 4120machine-specific '.c' and '.cc' files and machine-independent '.c' and 4121'.cc' files. Machine-specific files should use the directive: 4122 4123 #define IN_TARGET_CODE 1 4124 4125 before including 'config.h'. 4126 4127 If the back end is added to the official GCC source repository, the 4128following are also necessary: 4129 4130 * An entry for the target architecture in 'readings.html' on the GCC 4131 web site, with any relevant links. 4132 * Details of the properties of the back end and target architecture 4133 in 'backends.html' on the GCC web site. 4134 * A news item about the contribution of support for that target 4135 architecture, in 'index.html' on the GCC web site. 4136 * Normally, one or more maintainers of that target listed in 4137 'MAINTAINERS'. Some existing architectures may be unmaintained, 4138 but it would be unusual to add support for a target that does not 4139 have a maintainer when support is added. 4140 * Target triplets covering all 'config.gcc' stanzas for the target, 4141 in the list in 'contrib/config-list.mk'. 4142 4143 4144File: gccint.info, Node: Testsuites, Next: Options, Prev: Source Tree, Up: Top 4145 41467 Testsuites 4147************ 4148 4149GCC contains several testsuites to help maintain compiler quality. Most 4150of the runtime libraries and language front ends in GCC have testsuites. 4151Currently only the C language testsuites are documented here; FIXME: 4152document the others. 4153 4154* Menu: 4155 4156* Test Idioms:: Idioms used in testsuite code. 4157* Test Directives:: Directives used within DejaGnu tests. 4158* Ada Tests:: The Ada language testsuites. 4159* C Tests:: The C language testsuites. 4160* LTO Testing:: Support for testing link-time optimizations. 4161* gcov Testing:: Support for testing gcov. 4162* profopt Testing:: Support for testing profile-directed optimizations. 4163* compat Testing:: Support for testing binary compatibility. 4164* Torture Tests:: Support for torture testing using multiple options. 4165* GIMPLE Tests:: Support for testing GIMPLE passes. 4166* RTL Tests:: Support for testing RTL passes. 4167 4168 4169File: gccint.info, Node: Test Idioms, Next: Test Directives, Up: Testsuites 4170 41717.1 Idioms Used in Testsuite Code 4172================================= 4173 4174In general, C testcases have a trailing '-N.c', starting with '-1.c', in 4175case other testcases with similar names are added later. If the test is 4176a test of some well-defined feature, it should have a name referring to 4177that feature such as 'FEATURE-1.c'. If it does not test a well-defined 4178feature but just happens to exercise a bug somewhere in the compiler, 4179and a bug report has been filed for this bug in the GCC bug database, 4180'prBUG-NUMBER-1.c' is the appropriate form of name. Otherwise (for 4181miscellaneous bugs not filed in the GCC bug database), and previously 4182more generally, test cases are named after the date on which they were 4183added. This allows people to tell at a glance whether a test failure is 4184because of a recently found bug that has not yet been fixed, or whether 4185it may be a regression, but does not give any other information about 4186the bug or where discussion of it may be found. Some other language 4187testsuites follow similar conventions. 4188 4189 In the 'gcc.dg' testsuite, it is often necessary to test that an error 4190is indeed a hard error and not just a warning--for example, where it is 4191a constraint violation in the C standard, which must become an error 4192with '-pedantic-errors'. The following idiom, where the first line 4193shown is line LINE of the file and the line that generates the error, is 4194used for this: 4195 4196 /* { dg-bogus "warning" "warning in place of error" } */ 4197 /* { dg-error "REGEXP" "MESSAGE" { target *-*-* } LINE } */ 4198 4199 It may be necessary to check that an expression is an integer constant 4200expression and has a certain value. To check that 'E' has value 'V', an 4201idiom similar to the following is used: 4202 4203 char x[((E) == (V) ? 1 : -1)]; 4204 4205 In 'gcc.dg' tests, '__typeof__' is sometimes used to make assertions 4206about the types of expressions. See, for example, 4207'gcc.dg/c99-condexpr-1.c'. The more subtle uses depend on the exact 4208rules for the types of conditional expressions in the C standard; see, 4209for example, 'gcc.dg/c99-intconst-1.c'. 4210 4211 It is useful to be able to test that optimizations are being made 4212properly. This cannot be done in all cases, but it can be done where 4213the optimization will lead to code being optimized away (for example, 4214where flow analysis or alias analysis should show that certain code 4215cannot be called) or to functions not being called because they have 4216been expanded as built-in functions. Such tests go in 4217'gcc.c-torture/execute'. Where code should be optimized away, a call to 4218a nonexistent function such as 'link_failure ()' may be inserted; a 4219definition 4220 4221 #ifndef __OPTIMIZE__ 4222 void 4223 link_failure (void) 4224 { 4225 abort (); 4226 } 4227 #endif 4228 4229will also be needed so that linking still succeeds when the test is run 4230without optimization. When all calls to a built-in function should have 4231been optimized and no calls to the non-built-in version of the function 4232should remain, that function may be defined as 'static' to call 'abort 4233()' (although redeclaring a function as static may not work on all 4234targets). 4235 4236 All testcases must be portable. Target-specific testcases must have 4237appropriate code to avoid causing failures on unsupported systems; 4238unfortunately, the mechanisms for this differ by directory. 4239 4240 FIXME: discuss non-C testsuites here. 4241 4242 4243File: gccint.info, Node: Test Directives, Next: Ada Tests, Prev: Test Idioms, Up: Testsuites 4244 42457.2 Directives used within DejaGnu tests 4246======================================== 4247 4248* Menu: 4249 4250* Directives:: Syntax and descriptions of test directives. 4251* Selectors:: Selecting targets to which a test applies. 4252* Effective-Target Keywords:: Keywords describing target attributes. 4253* Add Options:: Features for 'dg-add-options' 4254* Require Support:: Variants of 'dg-require-SUPPORT' 4255* Final Actions:: Commands for use in 'dg-final' 4256 4257 4258File: gccint.info, Node: Directives, Next: Selectors, Up: Test Directives 4259 42607.2.1 Syntax and Descriptions of test directives 4261------------------------------------------------ 4262 4263Test directives appear within comments in a test source file and begin 4264with 'dg-'. Some of these are defined within DejaGnu and others are 4265local to the GCC testsuite. 4266 4267 The order in which test directives appear in a test can be important: 4268directives local to GCC sometimes override information used by the 4269DejaGnu directives, which know nothing about the GCC directives, so the 4270DejaGnu directives must precede GCC directives. 4271 4272 Several test directives include selectors (*note Selectors::) which are 4273usually preceded by the keyword 'target' or 'xfail'. 4274 42757.2.1.1 Specify how to build the test 4276..................................... 4277 4278'{ dg-do DO-WHAT-KEYWORD [{ target/xfail SELECTOR }] }' 4279 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 4280 is executed. It is one of: 4281 4282 'preprocess' 4283 Compile with '-E' to run only the preprocessor. 4284 'compile' 4285 Compile with '-S' to produce an assembly code file. 4286 'assemble' 4287 Compile with '-c' to produce a relocatable object file. 4288 'link' 4289 Compile, assemble, and link to produce an executable file. 4290 'run' 4291 Produce and run an executable file, which is expected to 4292 return an exit code of 0. 4293 4294 The default is 'compile'. That can be overridden for a set of 4295 tests by redefining 'dg-do-what-default' within the '.exp' file for 4296 those tests. 4297 4298 If the directive includes the optional '{ target SELECTOR }' then 4299 the test is skipped unless the target system matches the SELECTOR. 4300 4301 If DO-WHAT-KEYWORD is 'run' and the directive includes the optional 4302 '{ xfail SELECTOR }' and the selector is met then the test is 4303 expected to fail. The 'xfail' clause is ignored for other values 4304 of DO-WHAT-KEYWORD; those tests can use directive 'dg-xfail-if'. 4305 43067.2.1.2 Specify additional compiler options 4307........................................... 4308 4309'{ dg-options OPTIONS [{ target SELECTOR }] }' 4310 This DejaGnu directive provides a list of compiler options, to be 4311 used if the target system matches SELECTOR, that replace the 4312 default options used for this set of tests. 4313 4314'{ dg-add-options FEATURE ... }' 4315 Add any compiler options that are needed to access certain 4316 features. This directive does nothing on targets that enable the 4317 features by default, or that don't provide them at all. It must 4318 come after all 'dg-options' directives. For supported values of 4319 FEATURE see *note Add Options::. 4320 4321'{ dg-additional-options OPTIONS [{ target SELECTOR }] }' 4322 This directive provides a list of compiler options, to be used if 4323 the target system matches SELECTOR, that are added to the default 4324 options used for this set of tests. 4325 43267.2.1.3 Modify the test timeout value 4327..................................... 4328 4329The normal timeout limit, in seconds, is found by searching the 4330following in order: 4331 4332 * the value defined by an earlier 'dg-timeout' directive in the test 4333 4334 * variable TOOL_TIMEOUT defined by the set of tests 4335 4336 * GCC,TIMEOUT set in the target board 4337 4338 * 300 4339 4340'{ dg-timeout N [{target SELECTOR }] }' 4341 Set the time limit for the compilation and for the execution of the 4342 test to the specified number of seconds. 4343 4344'{ dg-timeout-factor X [{ target SELECTOR }] }' 4345 Multiply the normal time limit for compilation and execution of the 4346 test by the specified floating-point factor. 4347 43487.2.1.4 Skip a test for some targets 4349.................................... 4350 4351'{ dg-skip-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4352 Arguments INCLUDE-OPTS and EXCLUDE-OPTS are lists in which each 4353 element is a string of zero or more GCC options. Skip the test if 4354 all of the following conditions are met: 4355 * the test system is included in SELECTOR 4356 4357 * for at least one of the option strings in INCLUDE-OPTS, every 4358 option from that string is in the set of options with which 4359 the test would be compiled; use '"*"' for an INCLUDE-OPTS list 4360 that matches any options; that is the default if INCLUDE-OPTS 4361 is not specified 4362 4363 * for each of the option strings in EXCLUDE-OPTS, at least one 4364 option from that string is not in the set of options with 4365 which the test would be compiled; use '""' for an empty 4366 EXCLUDE-OPTS list; that is the default if EXCLUDE-OPTS is not 4367 specified 4368 4369 For example, to skip a test if option '-Os' is present: 4370 4371 /* { dg-skip-if "" { *-*-* } { "-Os" } { "" } } */ 4372 4373 To skip a test if both options '-O2' and '-g' are present: 4374 4375 /* { dg-skip-if "" { *-*-* } { "-O2 -g" } { "" } } */ 4376 4377 To skip a test if either '-O2' or '-O3' is present: 4378 4379 /* { dg-skip-if "" { *-*-* } { "-O2" "-O3" } { "" } } */ 4380 4381 To skip a test unless option '-Os' is present: 4382 4383 /* { dg-skip-if "" { *-*-* } { "*" } { "-Os" } } */ 4384 4385 To skip a test if either '-O2' or '-O3' is used with '-g' but not 4386 if '-fpic' is also present: 4387 4388 /* { dg-skip-if "" { *-*-* } { "-O2 -g" "-O3 -g" } { "-fpic" } } */ 4389 4390'{ dg-require-effective-target KEYWORD [{ SELECTOR }] }' 4391 Skip the test if the test target, including current multilib flags, 4392 is not covered by the effective-target keyword. If the directive 4393 includes the optional '{ SELECTOR }' then the effective-target test 4394 is only performed if the target system matches the SELECTOR. This 4395 directive must appear after any 'dg-do' directive in the test and 4396 before any 'dg-additional-sources' directive. *Note 4397 Effective-Target Keywords::. 4398 4399'{ dg-require-SUPPORT args }' 4400 Skip the test if the target does not provide the required support. 4401 These directives must appear after any 'dg-do' directive in the 4402 test and before any 'dg-additional-sources' directive. They 4403 require at least one argument, which can be an empty string if the 4404 specific procedure does not examine the argument. *Note Require 4405 Support::, for a complete list of these directives. 4406 44077.2.1.5 Expect a test to fail for some targets 4408.............................................. 4409 4410'{ dg-xfail-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4411 Expect the test to fail if the conditions (which are the same as 4412 for 'dg-skip-if') are met. This does not affect the execute step. 4413 4414'{ dg-xfail-run-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4415 Expect the execute step of a test to fail if the conditions (which 4416 are the same as for 'dg-skip-if') are met. 4417 44187.2.1.6 Expect the test executable to fail 4419.......................................... 4420 4421'{ dg-shouldfail COMMENT [{ SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]]] }' 4422 Expect the test executable to return a nonzero exit status if the 4423 conditions (which are the same as for 'dg-skip-if') are met. 4424 44257.2.1.7 Verify compiler messages 4426................................ 4427 4428Where LINE is an accepted argument for these commands, a value of '0' 4429can be used if there is no line associated with the message. 4430 4431'{ dg-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }' 4432 This DejaGnu directive appears on a source line that is expected to 4433 get an error message, or else specifies the source line associated 4434 with the message. If there is no message for that line or if the 4435 text of that message is not matched by REGEXP then the check fails 4436 and COMMENT is included in the 'FAIL' message. The check does not 4437 look for the string 'error' unless it is part of REGEXP. 4438 4439'{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }' 4440 This DejaGnu directive appears on a source line that is expected to 4441 get a warning message, or else specifies the source line associated 4442 with the message. If there is no message for that line or if the 4443 text of that message is not matched by REGEXP then the check fails 4444 and COMMENT is included in the 'FAIL' message. The check does not 4445 look for the string 'warning' unless it is part of REGEXP. 4446 4447'{ dg-message REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }' 4448 The line is expected to get a message other than an error or 4449 warning. If there is no message for that line or if the text of 4450 that message is not matched by REGEXP then the check fails and 4451 COMMENT is included in the 'FAIL' message. 4452 4453'{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }' 4454 This DejaGnu directive appears on a source line that should not get 4455 a message matching REGEXP, or else specifies the source line 4456 associated with the bogus message. It is usually used with 'xfail' 4457 to indicate that the message is a known problem for a particular 4458 set of targets. 4459 4460'{ dg-line LINENUMVAR }' 4461 This DejaGnu directive sets the variable LINENUMVAR to the line 4462 number of the source line. The variable LINENUMVAR can then be 4463 used in subsequent 'dg-error', 'dg-warning', 'dg-message' and 4464 'dg-bogus' directives. For example: 4465 4466 int a; /* { dg-line first_def_a } */ 4467 float a; /* { dg-error "conflicting types of" } */ 4468 /* { dg-message "previous declaration of" "" { target *-*-* } first_def_a } */ 4469 4470'{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }' 4471 This DejaGnu directive indicates that the test is expected to fail 4472 due to compiler messages that are not handled by 'dg-error', 4473 'dg-warning' or 'dg-bogus'. For this directive 'xfail' has the 4474 same effect as 'target'. 4475 4476'{ dg-prune-output REGEXP }' 4477 Prune messages matching REGEXP from the test output. 4478 44797.2.1.8 Verify output of the test executable 4480............................................ 4481 4482'{ dg-output REGEXP [{ target/xfail SELECTOR }] }' 4483 This DejaGnu directive compares REGEXP to the combined output that 4484 the test executable writes to 'stdout' and 'stderr'. 4485 44867.2.1.9 Specify environment variables for a test 4487................................................ 4488 4489'{ dg-set-compiler-env-var VAR_NAME "VAR_VALUE" }' 4490 Specify that the environment variable VAR_NAME needs to be set to 4491 VAR_VALUE before invoking the compiler on the test file. 4492 4493'{ dg-set-target-env-var VAR_NAME "VAR_VALUE" }' 4494 Specify that the environment variable VAR_NAME needs to be set to 4495 VAR_VALUE before execution of the program created by the test. 4496 44977.2.1.10 Specify additional files for a test 4498............................................ 4499 4500'{ dg-additional-files "FILELIST" }' 4501 Specify additional files, other than source files, that must be 4502 copied to the system where the compiler runs. 4503 4504'{ dg-additional-sources "FILELIST" }' 4505 Specify additional source files to appear in the compile line 4506 following the main test file. 4507 45087.2.1.11 Add checks at the end of a test 4509........................................ 4510 4511'{ dg-final { LOCAL-DIRECTIVE } }' 4512 This DejaGnu directive is placed within a comment anywhere in the 4513 source file and is processed after the test has been compiled and 4514 run. Multiple 'dg-final' commands are processed in the order in 4515 which they appear in the source file. *Note Final Actions::, for a 4516 list of directives that can be used within 'dg-final'. 4517 4518 4519File: gccint.info, Node: Selectors, Next: Effective-Target Keywords, Prev: Directives, Up: Test Directives 4520 45217.2.2 Selecting targets to which a test applies 4522----------------------------------------------- 4523 4524Several test directives include SELECTORs to limit the targets for which 4525a test is run or to declare that a test is expected to fail on 4526particular targets. 4527 4528 A selector is: 4529 * one or more target triplets, possibly including wildcard 4530 characters; use '*-*-*' to match any target 4531 * a single effective-target keyword (*note Effective-Target 4532 Keywords::) 4533 * a logical expression 4534 4535 Depending on the context, the selector specifies whether a test is 4536skipped and reported as unsupported or is expected to fail. A context 4537that allows either 'target' or 'xfail' also allows '{ target SELECTOR1 4538xfail SELECTOR2 }' to skip the test for targets that don't match 4539SELECTOR1 and the test to fail for targets that match SELECTOR2. 4540 4541 A selector expression appears within curly braces and uses a single 4542logical operator: one of '!', '&&', or '||'. An operand is another 4543selector expression, an effective-target keyword, a single target 4544triplet, or a list of target triplets within quotes or curly braces. 4545For example: 4546 4547 { target { ! "hppa*-*-* ia64*-*-*" } } 4548 { target { powerpc*-*-* && lp64 } } 4549 { xfail { lp64 || vect_no_align } } 4550 4551 4552File: gccint.info, Node: Effective-Target Keywords, Next: Add Options, Prev: Selectors, Up: Test Directives 4553 45547.2.3 Keywords describing target attributes 4555------------------------------------------- 4556 4557Effective-target keywords identify sets of targets that support 4558particular functionality. They are used to limit tests to be run only 4559for particular targets, or to specify that particular sets of targets 4560are expected to fail some tests. 4561 4562 Effective-target keywords are defined in 'lib/target-supports.exp' in 4563the GCC testsuite, with the exception of those that are documented as 4564being local to a particular test directory. 4565 4566 The 'effective target' takes into account all of the compiler options 4567with which the test will be compiled, including the multilib options. 4568By convention, keywords ending in '_nocache' can also include options 4569specified for the particular test in an earlier 'dg-options' or 4570'dg-add-options' directive. 4571 45727.2.3.1 Endianness 4573.................. 4574 4575'be' 4576 Target uses big-endian memory order for multi-byte and multi-word 4577 data. 4578 4579'le' 4580 Target uses little-endian memory order for multi-byte and 4581 multi-word data. 4582 45837.2.3.2 Data type sizes 4584....................... 4585 4586'ilp32' 4587 Target has 32-bit 'int', 'long', and pointers. 4588 4589'lp64' 4590 Target has 32-bit 'int', 64-bit 'long' and pointers. 4591 4592'llp64' 4593 Target has 32-bit 'int' and 'long', 64-bit 'long long' and 4594 pointers. 4595 4596'double64' 4597 Target has 64-bit 'double'. 4598 4599'double64plus' 4600 Target has 'double' that is 64 bits or longer. 4601 4602'longdouble128' 4603 Target has 128-bit 'long double'. 4604 4605'int32plus' 4606 Target has 'int' that is at 32 bits or longer. 4607 4608'int16' 4609 Target has 'int' that is 16 bits or shorter. 4610 4611'long_neq_int' 4612 Target has 'int' and 'long' with different sizes. 4613 4614'int_eq_float' 4615 Target has 'int' and 'float' with the same size. 4616 4617'ptr_eq_long' 4618 Target has pointers ('void *') and 'long' with the same size. 4619 4620'large_double' 4621 Target supports 'double' that is longer than 'float'. 4622 4623'large_long_double' 4624 Target supports 'long double' that is longer than 'double'. 4625 4626'ptr32plus' 4627 Target has pointers that are 32 bits or longer. 4628 4629'size20plus' 4630 Target has a 20-bit or larger address space, so at least supports 4631 16-bit array and structure sizes. 4632 4633'size32plus' 4634 Target has a 32-bit or larger address space, so at least supports 4635 24-bit array and structure sizes. 4636 4637'4byte_wchar_t' 4638 Target has 'wchar_t' that is at least 4 bytes. 4639 4640'floatN' 4641 Target has the '_FloatN' type. 4642 4643'floatNx' 4644 Target has the '_FloatNx' type. 4645 4646'floatN_runtime' 4647 Target has the '_FloatN' type, including runtime support for any 4648 options added with 'dg-add-options'. 4649 4650'floatNx_runtime' 4651 Target has the '_FloatNx' type, including runtime support for any 4652 options added with 'dg-add-options'. 4653 4654'floatn_nx_runtime' 4655 Target has runtime support for any options added with 4656 'dg-add-options' for any '_FloatN' or '_FloatNx' type. 4657 4658'inf' 4659 Target supports floating point infinite ('inf') for type 'double'. 4660 46617.2.3.3 Fortran-specific attributes 4662................................... 4663 4664'fortran_integer_16' 4665 Target supports Fortran 'integer' that is 16 bytes or longer. 4666 4667'fortran_real_10' 4668 Target supports Fortran 'real' that is 10 bytes or longer. 4669 4670'fortran_real_16' 4671 Target supports Fortran 'real' that is 16 bytes or longer. 4672 4673'fortran_large_int' 4674 Target supports Fortran 'integer' kinds larger than 'integer(8)'. 4675 4676'fortran_large_real' 4677 Target supports Fortran 'real' kinds larger than 'real(8)'. 4678 46797.2.3.4 Vector-specific attributes 4680.................................. 4681 4682'vect_align_stack_vars' 4683 The target's ABI allows stack variables to be aligned to the 4684 preferred vector alignment. 4685 4686'vect_avg_qi' 4687 Target supports both signed and unsigned averaging operations on 4688 vectors of bytes. 4689 4690'vect_condition' 4691 Target supports vector conditional operations. 4692 4693'vect_cond_mixed' 4694 Target supports vector conditional operations where comparison 4695 operands have different type from the value operands. 4696 4697'vect_double' 4698 Target supports hardware vectors of 'double'. 4699 4700'vect_double_cond_arith' 4701 Target supports conditional addition, subtraction, multiplication, 4702 division, minimum and maximum on vectors of 'double', via the 4703 'cond_' optabs. 4704 4705'vect_element_align_preferred' 4706 The target's preferred vector alignment is the same as the element 4707 alignment. 4708 4709'vect_float' 4710 Target supports hardware vectors of 'float' when 4711 '-funsafe-math-optimizations' is in effect. 4712 4713'vect_float_strict' 4714 Target supports hardware vectors of 'float' when 4715 '-funsafe-math-optimizations' is not in effect. This implies 4716 'vect_float'. 4717 4718'vect_int' 4719 Target supports hardware vectors of 'int'. 4720 4721'vect_long' 4722 Target supports hardware vectors of 'long'. 4723 4724'vect_long_long' 4725 Target supports hardware vectors of 'long long'. 4726 4727'vect_fully_masked' 4728 Target supports fully-masked (also known as fully-predicated) 4729 loops, so that vector loops can handle partial as well as full 4730 vectors. 4731 4732'vect_masked_store' 4733 Target supports vector masked stores. 4734 4735'vect_scatter_store' 4736 Target supports vector scatter stores. 4737 4738'vect_aligned_arrays' 4739 Target aligns arrays to vector alignment boundary. 4740 4741'vect_hw_misalign' 4742 Target supports a vector misalign access. 4743 4744'vect_no_align' 4745 Target does not support a vector alignment mechanism. 4746 4747'vect_peeling_profitable' 4748 Target might require to peel loops for alignment purposes. 4749 4750'vect_no_int_min_max' 4751 Target does not support a vector min and max instruction on 'int'. 4752 4753'vect_no_int_add' 4754 Target does not support a vector add instruction on 'int'. 4755 4756'vect_no_bitwise' 4757 Target does not support vector bitwise instructions. 4758 4759'vect_char_mult' 4760 Target supports 'vector char' multiplication. 4761 4762'vect_short_mult' 4763 Target supports 'vector short' multiplication. 4764 4765'vect_int_mult' 4766 Target supports 'vector int' multiplication. 4767 4768'vect_long_mult' 4769 Target supports 64 bit 'vector long' multiplication. 4770 4771'vect_extract_even_odd' 4772 Target supports vector even/odd element extraction. 4773 4774'vect_extract_even_odd_wide' 4775 Target supports vector even/odd element extraction of vectors with 4776 elements 'SImode' or larger. 4777 4778'vect_interleave' 4779 Target supports vector interleaving. 4780 4781'vect_strided' 4782 Target supports vector interleaving and extract even/odd. 4783 4784'vect_strided_wide' 4785 Target supports vector interleaving and extract even/odd for wide 4786 element types. 4787 4788'vect_perm' 4789 Target supports vector permutation. 4790 4791'vect_perm_byte' 4792 Target supports permutation of vectors with 8-bit elements. 4793 4794'vect_perm_short' 4795 Target supports permutation of vectors with 16-bit elements. 4796 4797'vect_perm3_byte' 4798 Target supports permutation of vectors with 8-bit elements, and for 4799 the default vector length it is possible to permute: 4800 { a0, a1, a2, b0, b1, b2, ... } 4801 to: 4802 { a0, a0, a0, b0, b0, b0, ... } 4803 { a1, a1, a1, b1, b1, b1, ... } 4804 { a2, a2, a2, b2, b2, b2, ... } 4805 using only two-vector permutes, regardless of how long the sequence 4806 is. 4807 4808'vect_perm3_int' 4809 Like 'vect_perm3_byte', but for 32-bit elements. 4810 4811'vect_perm3_short' 4812 Like 'vect_perm3_byte', but for 16-bit elements. 4813 4814'vect_shift' 4815 Target supports a hardware vector shift operation. 4816 4817'vect_unaligned_possible' 4818 Target prefers vectors to have an alignment greater than element 4819 alignment, but also allows unaligned vector accesses in some 4820 circumstances. 4821 4822'vect_variable_length' 4823 Target has variable-length vectors. 4824 4825'vect_widen_sum_hi_to_si' 4826 Target supports a vector widening summation of 'short' operands 4827 into 'int' results, or can promote (unpack) from 'short' to 'int'. 4828 4829'vect_widen_sum_qi_to_hi' 4830 Target supports a vector widening summation of 'char' operands into 4831 'short' results, or can promote (unpack) from 'char' to 'short'. 4832 4833'vect_widen_sum_qi_to_si' 4834 Target supports a vector widening summation of 'char' operands into 4835 'int' results. 4836 4837'vect_widen_mult_qi_to_hi' 4838 Target supports a vector widening multiplication of 'char' operands 4839 into 'short' results, or can promote (unpack) from 'char' to 4840 'short' and perform non-widening multiplication of 'short'. 4841 4842'vect_widen_mult_hi_to_si' 4843 Target supports a vector widening multiplication of 'short' 4844 operands into 'int' results, or can promote (unpack) from 'short' 4845 to 'int' and perform non-widening multiplication of 'int'. 4846 4847'vect_widen_mult_si_to_di_pattern' 4848 Target supports a vector widening multiplication of 'int' operands 4849 into 'long' results. 4850 4851'vect_sdot_qi' 4852 Target supports a vector dot-product of 'signed char'. 4853 4854'vect_udot_qi' 4855 Target supports a vector dot-product of 'unsigned char'. 4856 4857'vect_sdot_hi' 4858 Target supports a vector dot-product of 'signed short'. 4859 4860'vect_udot_hi' 4861 Target supports a vector dot-product of 'unsigned short'. 4862 4863'vect_pack_trunc' 4864 Target supports a vector demotion (packing) of 'short' to 'char' 4865 and from 'int' to 'short' using modulo arithmetic. 4866 4867'vect_unpack' 4868 Target supports a vector promotion (unpacking) of 'char' to 'short' 4869 and from 'char' to 'int'. 4870 4871'vect_intfloat_cvt' 4872 Target supports conversion from 'signed int' to 'float'. 4873 4874'vect_uintfloat_cvt' 4875 Target supports conversion from 'unsigned int' to 'float'. 4876 4877'vect_floatint_cvt' 4878 Target supports conversion from 'float' to 'signed int'. 4879 4880'vect_floatuint_cvt' 4881 Target supports conversion from 'float' to 'unsigned int'. 4882 4883'vect_intdouble_cvt' 4884 Target supports conversion from 'signed int' to 'double'. 4885 4886'vect_doubleint_cvt' 4887 Target supports conversion from 'double' to 'signed int'. 4888 4889'vect_max_reduc' 4890 Target supports max reduction for vectors. 4891 4892'vect_sizes_16B_8B' 4893 Target supports 16- and 8-bytes vectors. 4894 4895'vect_sizes_32B_16B' 4896 Target supports 32- and 16-bytes vectors. 4897 4898'vect_logical_reduc' 4899 Target supports AND, IOR and XOR reduction on vectors. 4900 4901'vect_fold_extract_last' 4902 Target supports the 'fold_extract_last' optab. 4903 49047.2.3.5 Thread Local Storage attributes 4905....................................... 4906 4907'tls' 4908 Target supports thread-local storage. 4909 4910'tls_native' 4911 Target supports native (rather than emulated) thread-local storage. 4912 4913'tls_runtime' 4914 Test system supports executing TLS executables. 4915 49167.2.3.6 Decimal floating point attributes 4917......................................... 4918 4919'dfp' 4920 Targets supports compiling decimal floating point extension to C. 4921 4922'dfp_nocache' 4923 Including the options used to compile this particular test, the 4924 target supports compiling decimal floating point extension to C. 4925 4926'dfprt' 4927 Test system can execute decimal floating point tests. 4928 4929'dfprt_nocache' 4930 Including the options used to compile this particular test, the 4931 test system can execute decimal floating point tests. 4932 4933'hard_dfp' 4934 Target generates decimal floating point instructions with current 4935 options. 4936 49377.2.3.7 ARM-specific attributes 4938............................... 4939 4940'arm32' 4941 ARM target generates 32-bit code. 4942 4943'arm_eabi' 4944 ARM target adheres to the ABI for the ARM Architecture. 4945 4946'arm_fp_ok' 4947 ARM target defines '__ARM_FP' using '-mfloat-abi=softfp' or 4948 equivalent options. Some multilibs may be incompatible with these 4949 options. 4950 4951'arm_hf_eabi' 4952 ARM target adheres to the VFP and Advanced SIMD Register Arguments 4953 variant of the ABI for the ARM Architecture (as selected with 4954 '-mfloat-abi=hard'). 4955 4956'arm_softfloat' 4957 ARM target uses the soft-float ABI with no floating-point 4958 instructions used whatsoever (as selected with '-mfloat-abi=soft'). 4959 4960'arm_hard_vfp_ok' 4961 ARM target supports '-mfpu=vfp -mfloat-abi=hard'. Some multilibs 4962 may be incompatible with these options. 4963 4964'arm_iwmmxt_ok' 4965 ARM target supports '-mcpu=iwmmxt'. Some multilibs may be 4966 incompatible with this option. 4967 4968'arm_neon' 4969 ARM target supports generating NEON instructions. 4970 4971'arm_tune_string_ops_prefer_neon' 4972 Test CPU tune supports inlining string operations with NEON 4973 instructions. 4974 4975'arm_neon_hw' 4976 Test system supports executing NEON instructions. 4977 4978'arm_neonv2_hw' 4979 Test system supports executing NEON v2 instructions. 4980 4981'arm_neon_ok' 4982 ARM Target supports '-mfpu=neon -mfloat-abi=softfp' or compatible 4983 options. Some multilibs may be incompatible with these options. 4984 4985'arm_neon_ok_no_float_abi' 4986 ARM Target supports NEON with '-mfpu=neon', but without any 4987 -mfloat-abi= option. Some multilibs may be incompatible with this 4988 option. 4989 4990'arm_neonv2_ok' 4991 ARM Target supports '-mfpu=neon-vfpv4 -mfloat-abi=softfp' or 4992 compatible options. Some multilibs may be incompatible with these 4993 options. 4994 4995'arm_fp16_ok' 4996 Target supports options to generate VFP half-precision 4997 floating-point instructions. Some multilibs may be incompatible 4998 with these options. This test is valid for ARM only. 4999 5000'arm_fp16_hw' 5001 Target supports executing VFP half-precision floating-point 5002 instructions. This test is valid for ARM only. 5003 5004'arm_neon_fp16_ok' 5005 ARM Target supports '-mfpu=neon-fp16 -mfloat-abi=softfp' or 5006 compatible options, including '-mfp16-format=ieee' if necessary to 5007 obtain the '__fp16' type. Some multilibs may be incompatible with 5008 these options. 5009 5010'arm_neon_fp16_hw' 5011 Test system supports executing Neon half-precision float 5012 instructions. (Implies previous.) 5013 5014'arm_fp16_alternative_ok' 5015 ARM target supports the ARM FP16 alternative format. Some 5016 multilibs may be incompatible with the options needed. 5017 5018'arm_fp16_none_ok' 5019 ARM target supports specifying none as the ARM FP16 format. 5020 5021'arm_thumb1_ok' 5022 ARM target generates Thumb-1 code for '-mthumb'. 5023 5024'arm_thumb2_ok' 5025 ARM target generates Thumb-2 code for '-mthumb'. 5026 5027'arm_vfp_ok' 5028 ARM target supports '-mfpu=vfp -mfloat-abi=softfp'. Some multilibs 5029 may be incompatible with these options. 5030 5031'arm_vfp3_ok' 5032 ARM target supports '-mfpu=vfp3 -mfloat-abi=softfp'. Some 5033 multilibs may be incompatible with these options. 5034 5035'arm_v8_vfp_ok' 5036 ARM target supports '-mfpu=fp-armv8 -mfloat-abi=softfp'. Some 5037 multilibs may be incompatible with these options. 5038 5039'arm_v8_neon_ok' 5040 ARM target supports '-mfpu=neon-fp-armv8 -mfloat-abi=softfp'. Some 5041 multilibs may be incompatible with these options. 5042 5043'arm_v8_1a_neon_ok' 5044 ARM target supports options to generate ARMv8.1-A Adv.SIMD 5045 instructions. Some multilibs may be incompatible with these 5046 options. 5047 5048'arm_v8_1a_neon_hw' 5049 ARM target supports executing ARMv8.1-A Adv.SIMD instructions. 5050 Some multilibs may be incompatible with the options needed. 5051 Implies arm_v8_1a_neon_ok. 5052 5053'arm_acq_rel' 5054 ARM target supports acquire-release instructions. 5055 5056'arm_v8_2a_fp16_scalar_ok' 5057 ARM target supports options to generate instructions for ARMv8.2-A 5058 and scalar instructions from the FP16 extension. Some multilibs 5059 may be incompatible with these options. 5060 5061'arm_v8_2a_fp16_scalar_hw' 5062 ARM target supports executing instructions for ARMv8.2-A and scalar 5063 instructions from the FP16 extension. Some multilibs may be 5064 incompatible with these options. Implies arm_v8_2a_fp16_neon_ok. 5065 5066'arm_v8_2a_fp16_neon_ok' 5067 ARM target supports options to generate instructions from ARMv8.2-A 5068 with the FP16 extension. Some multilibs may be incompatible with 5069 these options. Implies arm_v8_2a_fp16_scalar_ok. 5070 5071'arm_v8_2a_fp16_neon_hw' 5072 ARM target supports executing instructions from ARMv8.2-A with the 5073 FP16 extension. Some multilibs may be incompatible with these 5074 options. Implies arm_v8_2a_fp16_neon_ok and 5075 arm_v8_2a_fp16_scalar_hw. 5076 5077'arm_v8_2a_dotprod_neon_ok' 5078 ARM target supports options to generate instructions from ARMv8.2-A 5079 with the Dot Product extension. Some multilibs may be incompatible 5080 with these options. 5081 5082'arm_v8_2a_dotprod_neon_hw' 5083 ARM target supports executing instructions from ARMv8.2-A with the 5084 Dot Product extension. Some multilibs may be incompatible with 5085 these options. Implies arm_v8_2a_dotprod_neon_ok. 5086 5087'arm_fp16fml_neon_ok' 5088 ARM target supports extensions to generate the 'VFMAL' and 'VFMLS' 5089 half-precision floating-point instructions available from ARMv8.2-A 5090 and onwards. Some multilibs may be incompatible with these 5091 options. 5092 5093'arm_prefer_ldrd_strd' 5094 ARM target prefers 'LDRD' and 'STRD' instructions over 'LDM' and 5095 'STM' instructions. 5096 5097'arm_thumb1_movt_ok' 5098 ARM target generates Thumb-1 code for '-mthumb' with 'MOVW' and 5099 'MOVT' instructions available. 5100 5101'arm_thumb1_cbz_ok' 5102 ARM target generates Thumb-1 code for '-mthumb' with 'CBZ' and 5103 'CBNZ' instructions available. 5104 5105'arm_divmod_simode' 5106 ARM target for which divmod transform is disabled, if it supports 5107 hardware div instruction. 5108 5109'arm_cmse_ok' 5110 ARM target supports ARMv8-M Security Extensions, enabled by the 5111 '-mcmse' option. 5112 5113'arm_coproc1_ok' 5114 ARM target supports the following coprocessor instructions: 'CDP', 5115 'LDC', 'STC', 'MCR' and 'MRC'. 5116 5117'arm_coproc2_ok' 5118 ARM target supports all the coprocessor instructions also listed as 5119 supported in *note arm_coproc1_ok:: in addition to the following: 5120 'CDP2', 'LDC2', 'LDC2l', 'STC2', 'STC2l', 'MCR2' and 'MRC2'. 5121 5122'arm_coproc3_ok' 5123 ARM target supports all the coprocessor instructions also listed as 5124 supported in *note arm_coproc2_ok:: in addition the following: 5125 'MCRR' and 'MRRC'. 5126 5127'arm_coproc4_ok' 5128 ARM target supports all the coprocessor instructions also listed as 5129 supported in *note arm_coproc3_ok:: in addition the following: 5130 'MCRR2' and 'MRRC2'. 5131 51327.2.3.8 AArch64-specific attributes 5133................................... 5134 5135'aarch64_asm_<ext>_ok' 5136 AArch64 assembler supports the architecture extension 'ext' via the 5137 '.arch_extension' pseudo-op. 5138'aarch64_tiny' 5139 AArch64 target which generates instruction sequences for tiny 5140 memory model. 5141'aarch64_small' 5142 AArch64 target which generates instruction sequences for small 5143 memory model. 5144'aarch64_large' 5145 AArch64 target which generates instruction sequences for large 5146 memory model. 5147'aarch64_little_endian' 5148 AArch64 target which generates instruction sequences for little 5149 endian. 5150'aarch64_big_endian' 5151 AArch64 target which generates instruction sequences for big 5152 endian. 5153'aarch64_small_fpic' 5154 Binutils installed on test system supports relocation types 5155 required by -fpic for AArch64 small memory model. 5156 5157'aarch64_fjcvtzs_hw' 5158 AArch64 target that is able to generate and execute armv8.3-a 5159 FJCVTZS instruction. 5160 51617.2.3.9 MIPS-specific attributes 5162................................ 5163 5164'mips64' 5165 MIPS target supports 64-bit instructions. 5166 5167'nomips16' 5168 MIPS target does not produce MIPS16 code. 5169 5170'mips16_attribute' 5171 MIPS target can generate MIPS16 code. 5172 5173'mips_loongson' 5174 MIPS target is a Loongson-2E or -2F target using an ABI that 5175 supports the Loongson vector modes. 5176 5177'mips_msa' 5178 MIPS target supports '-mmsa', MIPS SIMD Architecture (MSA). 5179 5180'mips_newabi_large_long_double' 5181 MIPS target supports 'long double' larger than 'double' when using 5182 the new ABI. 5183 5184'mpaired_single' 5185 MIPS target supports '-mpaired-single'. 5186 51877.2.3.10 PowerPC-specific attributes 5188.................................... 5189 5190'dfp_hw' 5191 PowerPC target supports executing hardware DFP instructions. 5192 5193'p8vector_hw' 5194 PowerPC target supports executing VSX instructions (ISA 2.07). 5195 5196'powerpc64' 5197 Test system supports executing 64-bit instructions. 5198 5199'powerpc_altivec' 5200 PowerPC target supports AltiVec. 5201 5202'powerpc_altivec_ok' 5203 PowerPC target supports '-maltivec'. 5204 5205'powerpc_eabi_ok' 5206 PowerPC target supports '-meabi'. 5207 5208'powerpc_elfv2' 5209 PowerPC target supports '-mabi=elfv2'. 5210 5211'powerpc_fprs' 5212 PowerPC target supports floating-point registers. 5213 5214'powerpc_hard_double' 5215 PowerPC target supports hardware double-precision floating-point. 5216 5217'powerpc_htm_ok' 5218 PowerPC target supports '-mhtm' 5219 5220'powerpc_p8vector_ok' 5221 PowerPC target supports '-mpower8-vector' 5222 5223'powerpc_popcntb_ok' 5224 PowerPC target supports the 'popcntb' instruction, indicating that 5225 this target supports '-mcpu=power5'. 5226 5227'powerpc_ppu_ok' 5228 PowerPC target supports '-mcpu=cell'. 5229 5230'powerpc_spe' 5231 PowerPC target supports PowerPC SPE. 5232 5233'powerpc_spe_nocache' 5234 Including the options used to compile this particular test, the 5235 PowerPC target supports PowerPC SPE. 5236 5237'powerpc_spu' 5238 PowerPC target supports PowerPC SPU. 5239 5240'powerpc_vsx_ok' 5241 PowerPC target supports '-mvsx'. 5242 5243'powerpc_405_nocache' 5244 Including the options used to compile this particular test, the 5245 PowerPC target supports PowerPC 405. 5246 5247'ppc_recip_hw' 5248 PowerPC target supports executing reciprocal estimate instructions. 5249 5250'spu_auto_overlay' 5251 SPU target has toolchain that supports automatic overlay 5252 generation. 5253 5254'vmx_hw' 5255 PowerPC target supports executing AltiVec instructions. 5256 5257'vsx_hw' 5258 PowerPC target supports executing VSX instructions (ISA 2.06). 5259 52607.2.3.11 Other hardware attributes 5261.................................. 5262 5263'autoincdec' 5264 Target supports autoincrement/decrement addressing. 5265 5266'avx' 5267 Target supports compiling 'avx' instructions. 5268 5269'avx_runtime' 5270 Target supports the execution of 'avx' instructions. 5271 5272'avx2' 5273 Target supports compiling 'avx2' instructions. 5274 5275'avx2_runtime' 5276 Target supports the execution of 'avx2' instructions. 5277 5278'avx512f' 5279 Target supports compiling 'avx512f' instructions. 5280 5281'avx512f_runtime' 5282 Target supports the execution of 'avx512f' instructions. 5283 5284'cell_hw' 5285 Test system can execute AltiVec and Cell PPU instructions. 5286 5287'coldfire_fpu' 5288 Target uses a ColdFire FPU. 5289 5290'divmod' 5291 Target supporting hardware divmod insn or divmod libcall. 5292 5293'divmod_simode' 5294 Target supporting hardware divmod insn or divmod libcall for 5295 SImode. 5296 5297'hard_float' 5298 Target supports FPU instructions. 5299 5300'non_strict_align' 5301 Target does not require strict alignment. 5302 5303'pie_copyreloc' 5304 The x86-64 target linker supports PIE with copy reloc. 5305 5306'rdrand' 5307 Target supports x86 'rdrand' instruction. 5308 5309'sqrt_insn' 5310 Target has a square root instruction that the compiler can 5311 generate. 5312 5313'sse' 5314 Target supports compiling 'sse' instructions. 5315 5316'sse_runtime' 5317 Target supports the execution of 'sse' instructions. 5318 5319'sse2' 5320 Target supports compiling 'sse2' instructions. 5321 5322'sse2_runtime' 5323 Target supports the execution of 'sse2' instructions. 5324 5325'sync_char_short' 5326 Target supports atomic operations on 'char' and 'short'. 5327 5328'sync_int_long' 5329 Target supports atomic operations on 'int' and 'long'. 5330 5331'ultrasparc_hw' 5332 Test environment appears to run executables on a simulator that 5333 accepts only 'EM_SPARC' executables and chokes on 'EM_SPARC32PLUS' 5334 or 'EM_SPARCV9' executables. 5335 5336'vect_cmdline_needed' 5337 Target requires a command line argument to enable a SIMD 5338 instruction set. 5339 5340'xorsign' 5341 Target supports the xorsign optab expansion. 5342 53437.2.3.12 Environment attributes 5344............................... 5345 5346'c' 5347 The language for the compiler under test is C. 5348 5349'c++' 5350 The language for the compiler under test is C++. 5351 5352'c99_runtime' 5353 Target provides a full C99 runtime. 5354 5355'correct_iso_cpp_string_wchar_protos' 5356 Target 'string.h' and 'wchar.h' headers provide C++ required 5357 overloads for 'strchr' etc. functions. 5358 5359'd_runtime' 5360 Target provides the D runtime. 5361 5362'dummy_wcsftime' 5363 Target uses a dummy 'wcsftime' function that always returns zero. 5364 5365'fd_truncate' 5366 Target can truncate a file from a file descriptor, as used by 5367 'libgfortran/io/unix.c:fd_truncate'; i.e. 'ftruncate' or 'chsize'. 5368 5369'fenv' 5370 Target provides 'fenv.h' include file. 5371 5372'fenv_exceptions' 5373 Target supports 'fenv.h' with all the standard IEEE exceptions and 5374 floating-point exceptions are raised by arithmetic operations. 5375 5376'freestanding' 5377 Target is 'freestanding' as defined in section 4 of the C99 5378 standard. Effectively, it is a target which supports no extra 5379 headers or libraries other than what is considered essential. 5380 5381'gettimeofday' 5382 Target supports 'gettimeofday'. 5383 5384'init_priority' 5385 Target supports constructors with initialization priority 5386 arguments. 5387 5388'inttypes_types' 5389 Target has the basic signed and unsigned types in 'inttypes.h'. 5390 This is for tests that GCC's notions of these types agree with 5391 those in the header, as some systems have only 'inttypes.h'. 5392 5393'lax_strtofp' 5394 Target might have errors of a few ULP in string to floating-point 5395 conversion functions and overflow is not always detected correctly 5396 by those functions. 5397 5398'mempcpy' 5399 Target provides 'mempcpy' function. 5400 5401'mmap' 5402 Target supports 'mmap'. 5403 5404'newlib' 5405 Target supports Newlib. 5406 5407'newlib_nano_io' 5408 GCC was configured with '--enable-newlib-nano-formatted-io', which 5409 reduces the code size of Newlib formatted I/O functions. 5410 5411'pow10' 5412 Target provides 'pow10' function. 5413 5414'pthread' 5415 Target can compile using 'pthread.h' with no errors or warnings. 5416 5417'pthread_h' 5418 Target has 'pthread.h'. 5419 5420'run_expensive_tests' 5421 Expensive testcases (usually those that consume excessive amounts 5422 of CPU time) should be run on this target. This can be enabled by 5423 setting the 'GCC_TEST_RUN_EXPENSIVE' environment variable to a 5424 non-empty string. 5425 5426'simulator' 5427 Test system runs executables on a simulator (i.e. slowly) rather 5428 than hardware (i.e. fast). 5429 5430'signal' 5431 Target has 'signal.h'. 5432 5433'stabs' 5434 Target supports the stabs debugging format. 5435 5436'stdint_types' 5437 Target has the basic signed and unsigned C types in 'stdint.h'. 5438 This will be obsolete when GCC ensures a working 'stdint.h' for all 5439 targets. 5440 5441'stpcpy' 5442 Target provides 'stpcpy' function. 5443 5444'trampolines' 5445 Target supports trampolines. 5446 5447'uclibc' 5448 Target supports uClibc. 5449 5450'unwrapped' 5451 Target does not use a status wrapper. 5452 5453'vxworks_kernel' 5454 Target is a VxWorks kernel. 5455 5456'vxworks_rtp' 5457 Target is a VxWorks RTP. 5458 5459'wchar' 5460 Target supports wide characters. 5461 54627.2.3.13 Other attributes 5463......................... 5464 5465'automatic_stack_alignment' 5466 Target supports automatic stack alignment. 5467 5468'branch_cost' 5469 Target supports '-branch-cost=N'. 5470 5471'cxa_atexit' 5472 Target uses '__cxa_atexit'. 5473 5474'default_packed' 5475 Target has packed layout of structure members by default. 5476 5477'exceptions' 5478 Target supports exceptions. 5479 5480'fgraphite' 5481 Target supports Graphite optimizations. 5482 5483'fixed_point' 5484 Target supports fixed-point extension to C. 5485 5486'fopenacc' 5487 Target supports OpenACC via '-fopenacc'. 5488 5489'fopenmp' 5490 Target supports OpenMP via '-fopenmp'. 5491 5492'fpic' 5493 Target supports '-fpic' and '-fPIC'. 5494 5495'freorder' 5496 Target supports '-freorder-blocks-and-partition'. 5497 5498'fstack_protector' 5499 Target supports '-fstack-protector'. 5500 5501'gas' 5502 Target uses GNU 'as'. 5503 5504'gc_sections' 5505 Target supports '--gc-sections'. 5506 5507'gld' 5508 Target uses GNU 'ld'. 5509 5510'keeps_null_pointer_checks' 5511 Target keeps null pointer checks, either due to the use of 5512 '-fno-delete-null-pointer-checks' or hardwired into the target. 5513 5514'llvm_binutils' 5515 Target is using an LLVM assembler and/or linker, instead of GNU 5516 Binutils. 5517 5518'lto' 5519 Compiler has been configured to support link-time optimization 5520 (LTO). 5521 5522'lto_incremental' 5523 Compiler and linker support link-time optimization relocatable 5524 linking with '-r' and '-flto' options. 5525 5526'naked_functions' 5527 Target supports the 'naked' function attribute. 5528 5529'named_sections' 5530 Target supports named sections. 5531 5532'natural_alignment_32' 5533 Target uses natural alignment (aligned to type size) for types of 5534 32 bits or less. 5535 5536'target_natural_alignment_64' 5537 Target uses natural alignment (aligned to type size) for types of 5538 64 bits or less. 5539 5540'nonpic' 5541 Target does not generate PIC by default. 5542 5543'offload_gcn' 5544 Target has been configured for OpenACC/OpenMP offloading on AMD 5545 GCN. 5546 5547'pie_enabled' 5548 Target generates PIE by default. 5549 5550'pcc_bitfield_type_matters' 5551 Target defines 'PCC_BITFIELD_TYPE_MATTERS'. 5552 5553'pe_aligned_commons' 5554 Target supports '-mpe-aligned-commons'. 5555 5556'pie' 5557 Target supports '-pie', '-fpie' and '-fPIE'. 5558 5559'rdynamic' 5560 Target supports '-rdynamic'. 5561 5562'scalar_all_fma' 5563 Target supports all four fused multiply-add optabs for both 'float' 5564 and 'double'. These optabs are: 'fma_optab', 'fms_optab', 5565 'fnma_optab' and 'fnms_optab'. 5566 5567'section_anchors' 5568 Target supports section anchors. 5569 5570'short_enums' 5571 Target defaults to short enums. 5572 5573'stack_size' 5574 Target has limited stack size. The stack size limit can be 5575 obtained using the STACK_SIZE macro defined by *note 5576 'dg-add-options' feature 'stack_size': stack_size_ao. 5577 5578'static' 5579 Target supports '-static'. 5580 5581'static_libgfortran' 5582 Target supports statically linking 'libgfortran'. 5583 5584'string_merging' 5585 Target supports merging string constants at link time. 5586 5587'ucn' 5588 Target supports compiling and assembling UCN. 5589 5590'ucn_nocache' 5591 Including the options used to compile this particular test, the 5592 target supports compiling and assembling UCN. 5593 5594'unaligned_stack' 5595 Target does not guarantee that its 'STACK_BOUNDARY' is greater than 5596 or equal to the required vector alignment. 5597 5598'vector_alignment_reachable' 5599 Vector alignment is reachable for types of 32 bits or less. 5600 5601'vector_alignment_reachable_for_64bit' 5602 Vector alignment is reachable for types of 64 bits or less. 5603 5604'wchar_t_char16_t_compatible' 5605 Target supports 'wchar_t' that is compatible with 'char16_t'. 5606 5607'wchar_t_char32_t_compatible' 5608 Target supports 'wchar_t' that is compatible with 'char32_t'. 5609 5610'comdat_group' 5611 Target uses comdat groups. 5612 56137.2.3.14 Local to tests in 'gcc.target/i386' 5614............................................ 5615 5616'3dnow' 5617 Target supports compiling '3dnow' instructions. 5618 5619'aes' 5620 Target supports compiling 'aes' instructions. 5621 5622'fma4' 5623 Target supports compiling 'fma4' instructions. 5624 5625'mfentry' 5626 Target supports the '-mfentry' option that alters the position of 5627 profiling calls such that they precede the prologue. 5628 5629'ms_hook_prologue' 5630 Target supports attribute 'ms_hook_prologue'. 5631 5632'pclmul' 5633 Target supports compiling 'pclmul' instructions. 5634 5635'sse3' 5636 Target supports compiling 'sse3' instructions. 5637 5638'sse4' 5639 Target supports compiling 'sse4' instructions. 5640 5641'sse4a' 5642 Target supports compiling 'sse4a' instructions. 5643 5644'ssse3' 5645 Target supports compiling 'ssse3' instructions. 5646 5647'vaes' 5648 Target supports compiling 'vaes' instructions. 5649 5650'vpclmul' 5651 Target supports compiling 'vpclmul' instructions. 5652 5653'xop' 5654 Target supports compiling 'xop' instructions. 5655 56567.2.3.15 Local to tests in 'gcc.target/spu/ea' 5657.............................................. 5658 5659'ealib' 5660 Target '__ea' library functions are available. 5661 56627.2.3.16 Local to tests in 'gcc.test-framework' 5663............................................... 5664 5665'no' 5666 Always returns 0. 5667 5668'yes' 5669 Always returns 1. 5670 5671 5672File: gccint.info, Node: Add Options, Next: Require Support, Prev: Effective-Target Keywords, Up: Test Directives 5673 56747.2.4 Features for 'dg-add-options' 5675----------------------------------- 5676 5677The supported values of FEATURE for directive 'dg-add-options' are: 5678 5679'arm_fp' 5680 '__ARM_FP' definition. Only ARM targets support this feature, and 5681 only then in certain modes; see the *note arm_fp_ok effective 5682 target keyword: arm_fp_ok. 5683 5684'arm_neon' 5685 NEON support. Only ARM targets support this feature, and only then 5686 in certain modes; see the *note arm_neon_ok effective target 5687 keyword: arm_neon_ok. 5688 5689'arm_fp16' 5690 VFP half-precision floating point support. This does not select 5691 the FP16 format; for that, use *note arm_fp16_ieee: arm_fp16_ieee. 5692 or *note arm_fp16_alternative: arm_fp16_alternative. instead. This 5693 feature is only supported by ARM targets and then only in certain 5694 modes; see the *note arm_fp16_ok effective target keyword: 5695 arm_fp16_ok. 5696 5697'arm_fp16_ieee' 5698 ARM IEEE 754-2008 format VFP half-precision floating point support. 5699 This feature is only supported by ARM targets and then only in 5700 certain modes; see the *note arm_fp16_ok effective target keyword: 5701 arm_fp16_ok. 5702 5703'arm_fp16_alternative' 5704 ARM Alternative format VFP half-precision floating point support. 5705 This feature is only supported by ARM targets and then only in 5706 certain modes; see the *note arm_fp16_ok effective target keyword: 5707 arm_fp16_ok. 5708 5709'arm_neon_fp16' 5710 NEON and half-precision floating point support. Only ARM targets 5711 support this feature, and only then in certain modes; see the *note 5712 arm_neon_fp16_ok effective target keyword: arm_neon_fp16_ok. 5713 5714'arm_vfp3' 5715 arm vfp3 floating point support; see the *note arm_vfp3_ok 5716 effective target keyword: arm_vfp3_ok. 5717 5718'arm_v8_1a_neon' 5719 Add options for ARMv8.1-A with Adv.SIMD support, if this is 5720 supported by the target; see the *note arm_v8_1a_neon_ok: 5721 arm_v8_1a_neon_ok. effective target keyword. 5722 5723'arm_v8_2a_fp16_scalar' 5724 Add options for ARMv8.2-A with scalar FP16 support, if this is 5725 supported by the target; see the *note arm_v8_2a_fp16_scalar_ok: 5726 arm_v8_2a_fp16_scalar_ok. effective target keyword. 5727 5728'arm_v8_2a_fp16_neon' 5729 Add options for ARMv8.2-A with Adv.SIMD FP16 support, if this is 5730 supported by the target; see the *note arm_v8_2a_fp16_neon_ok: 5731 arm_v8_2a_fp16_neon_ok. effective target keyword. 5732 5733'arm_v8_2a_dotprod_neon' 5734 Add options for ARMv8.2-A with Adv.SIMD Dot Product support, if 5735 this is supported by the target; see the *note 5736 arm_v8_2a_dotprod_neon_ok:: effective target keyword. 5737 5738'arm_fp16fml_neon' 5739 Add options to enable generation of the 'VFMAL' and 'VFMSL' 5740 instructions, if this is supported by the target; see the *note 5741 arm_fp16fml_neon_ok:: effective target keyword. 5742 5743'bind_pic_locally' 5744 Add the target-specific flags needed to enable functions to bind 5745 locally when using pic/PIC passes in the testsuite. 5746 5747'c99_runtime' 5748 Add the target-specific flags needed to access the C99 runtime. 5749 5750'floatN' 5751 Add the target-specific flags needed to use the '_FloatN' type. 5752 5753'floatNx' 5754 Add the target-specific flags needed to use the '_FloatNx' type. 5755 5756'ieee' 5757 Add the target-specific flags needed to enable full IEEE compliance 5758 mode. 5759 5760'mips16_attribute' 5761 'mips16' function attributes. Only MIPS targets support this 5762 feature, and only then in certain modes. 5763 5764'stack_size' 5765 Add the flags needed to define macro STACK_SIZE and set it to the 5766 stack size limit associated with the *note 'stack_size' effective 5767 target: stack_size_et. 5768 5769'sqrt_insn' 5770 Add the target-specific flags needed to enable hardware square root 5771 instructions, if any. 5772 5773'tls' 5774 Add the target-specific flags needed to use thread-local storage. 5775 5776 5777File: gccint.info, Node: Require Support, Next: Final Actions, Prev: Add Options, Up: Test Directives 5778 57797.2.5 Variants of 'dg-require-SUPPORT' 5780-------------------------------------- 5781 5782A few of the 'dg-require' directives take arguments. 5783 5784'dg-require-iconv CODESET' 5785 Skip the test if the target does not support iconv. CODESET is the 5786 codeset to convert to. 5787 5788'dg-require-profiling PROFOPT' 5789 Skip the test if the target does not support profiling with option 5790 PROFOPT. 5791 5792'dg-require-stack-check CHECK' 5793 Skip the test if the target does not support the '-fstack-check' 5794 option. If CHECK is '""', support for '-fstack-check' is checked, 5795 for '-fstack-check=("CHECK")' otherwise. 5796 5797'dg-require-stack-size SIZE' 5798 Skip the test if the target does not support a stack size of SIZE. 5799 5800'dg-require-visibility VIS' 5801 Skip the test if the target does not support the 'visibility' 5802 attribute. If VIS is '""', support for 'visibility("hidden")' is 5803 checked, for 'visibility("VIS")' otherwise. 5804 5805 The original 'dg-require' directives were defined before there was 5806support for effective-target keywords. The directives that do not take 5807arguments could be replaced with effective-target keywords. 5808 5809'dg-require-alias ""' 5810 Skip the test if the target does not support the 'alias' attribute. 5811 5812'dg-require-ascii-locale ""' 5813 Skip the test if the host does not support an ASCII locale. 5814 5815'dg-require-compat-dfp ""' 5816 Skip this test unless both compilers in a 'compat' testsuite 5817 support decimal floating point. 5818 5819'dg-require-cxa-atexit ""' 5820 Skip the test if the target does not support '__cxa_atexit'. This 5821 is equivalent to 'dg-require-effective-target cxa_atexit'. 5822 5823'dg-require-dll ""' 5824 Skip the test if the target does not support DLL attributes. 5825 5826'dg-require-fork ""' 5827 Skip the test if the target does not support 'fork'. 5828 5829'dg-require-gc-sections ""' 5830 Skip the test if the target's linker does not support the 5831 '--gc-sections' flags. This is equivalent to 5832 'dg-require-effective-target gc-sections'. 5833 5834'dg-require-host-local ""' 5835 Skip the test if the host is remote, rather than the same as the 5836 build system. Some tests are incompatible with DejaGnu's handling 5837 of remote hosts, which involves copying the source file to the host 5838 and compiling it with a relative path and "'-o a.out'". 5839 5840'dg-require-mkfifo ""' 5841 Skip the test if the target does not support 'mkfifo'. 5842 5843'dg-require-named-sections ""' 5844 Skip the test is the target does not support named sections. This 5845 is equivalent to 'dg-require-effective-target named_sections'. 5846 5847'dg-require-weak ""' 5848 Skip the test if the target does not support weak symbols. 5849 5850'dg-require-weak-override ""' 5851 Skip the test if the target does not support overriding weak 5852 symbols. 5853 5854 5855File: gccint.info, Node: Final Actions, Prev: Require Support, Up: Test Directives 5856 58577.2.6 Commands for use in 'dg-final' 5858------------------------------------ 5859 5860The GCC testsuite defines the following directives to be used within 5861'dg-final'. 5862 58637.2.6.1 Scan a particular file 5864.............................. 5865 5866'scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]' 5867 Passes if REGEXP matches text in FILENAME. 5868'scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]' 5869 Passes if REGEXP does not match text in FILENAME. 5870'scan-module MODULE REGEXP [{ target/xfail SELECTOR }]' 5871 Passes if REGEXP matches in Fortran module MODULE. 5872 58737.2.6.2 Scan the assembly output 5874................................ 5875 5876'scan-assembler REGEX [{ target/xfail SELECTOR }]' 5877 Passes if REGEX matches text in the test's assembler output. 5878 5879'scan-assembler-not REGEX [{ target/xfail SELECTOR }]' 5880 Passes if REGEX does not match text in the test's assembler output. 5881 5882'scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]' 5883 Passes if REGEX is matched exactly NUM times in the test's 5884 assembler output. 5885 5886'scan-assembler-dem REGEX [{ target/xfail SELECTOR }]' 5887 Passes if REGEX matches text in the test's demangled assembler 5888 output. 5889 5890'scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]' 5891 Passes if REGEX does not match text in the test's demangled 5892 assembler output. 5893 5894'scan-hidden SYMBOL [{ target/xfail SELECTOR }]' 5895 Passes if SYMBOL is defined as a hidden symbol in the test's 5896 assembly output. 5897 5898'scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]' 5899 Passes if SYMBOL is not defined as a hidden symbol in the test's 5900 assembly output. 5901 59027.2.6.3 Scan optimization dump files 5903.................................... 5904 5905These commands are available for KIND of 'tree', 'ltrans-tree', 5906'offload-tree', 'rtl', 'offload-rtl', 'ipa', and 'wpa-ipa'. 5907 5908'scan-KIND-dump REGEX SUFFIX [{ target/xfail SELECTOR }]' 5909 Passes if REGEX matches text in the dump file with suffix SUFFIX. 5910 5911'scan-KIND-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5912 Passes if REGEX does not match text in the dump file with suffix 5913 SUFFIX. 5914 5915'scan-KIND-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]' 5916 Passes if REGEX is found exactly NUM times in the dump file with 5917 suffix SUFFIX. 5918 5919'scan-KIND-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]' 5920 Passes if REGEX matches demangled text in the dump file with suffix 5921 SUFFIX. 5922 5923'scan-KIND-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5924 Passes if REGEX does not match demangled text in the dump file with 5925 suffix SUFFIX. 5926 59277.2.6.4 Check for output files 5928.............................. 5929 5930'output-exists [{ target/xfail SELECTOR }]' 5931 Passes if compiler output file exists. 5932 5933'output-exists-not [{ target/xfail SELECTOR }]' 5934 Passes if compiler output file does not exist. 5935 5936'scan-symbol REGEXP [{ target/xfail SELECTOR }]' 5937 Passes if the pattern is present in the final executable. 5938 5939'scan-symbol-not REGEXP [{ target/xfail SELECTOR }]' 5940 Passes if the pattern is absent from the final executable. 5941 59427.2.6.5 Checks for 'gcov' tests 5943............................... 5944 5945'run-gcov SOURCEFILE' 5946 Check line counts in 'gcov' tests. 5947 5948'run-gcov [branches] [calls] { OPTS SOURCEFILE }' 5949 Check branch and/or call counts, in addition to line counts, in 5950 'gcov' tests. 5951 59527.2.6.6 Clean up generated test files 5953..................................... 5954 5955Usually the test-framework removes files that were generated during 5956testing. If a testcase, for example, uses any dumping mechanism to 5957inspect a passes dump file, the testsuite recognized the dump option 5958passed to the tool and schedules a final cleanup to remove these files. 5959 5960 There are, however, following additional cleanup directives that can be 5961used to annotate a testcase "manually". 5962'cleanup-coverage-files' 5963 Removes coverage data files generated for this test. 5964 5965'cleanup-modules "LIST-OF-EXTRA-MODULES"' 5966 Removes Fortran module files generated for this test, excluding the 5967 module names listed in keep-modules. Cleaning up module files is 5968 usually done automatically by the testsuite by looking at the 5969 source files and removing the modules after the test has been 5970 executed. 5971 module MoD1 5972 end module MoD1 5973 module Mod2 5974 end module Mod2 5975 module moD3 5976 end module moD3 5977 module mod4 5978 end module mod4 5979 ! { dg-final { cleanup-modules "mod1 mod2" } } ! redundant 5980 ! { dg-final { keep-modules "mod3 mod4" } } 5981 5982'keep-modules "LIST-OF-MODULES-NOT-TO-DELETE"' 5983 Whitespace separated list of module names that should not be 5984 deleted by cleanup-modules. If the list of modules is empty, all 5985 modules defined in this file are kept. 5986 module maybe_unneeded 5987 end module maybe_unneeded 5988 module keep1 5989 end module keep1 5990 module keep2 5991 end module keep2 5992 ! { dg-final { keep-modules "keep1 keep2" } } ! just keep these two 5993 ! { dg-final { keep-modules "" } } ! keep all 5994 5995'dg-keep-saved-temps "LIST-OF-SUFFIXES-NOT-TO-DELETE"' 5996 Whitespace separated list of suffixes that should not be deleted 5997 automatically in a testcase that uses '-save-temps'. 5998 // { dg-options "-save-temps -fpch-preprocess -I." } 5999 int main() { return 0; } 6000 // { dg-keep-saved-temps ".s" } ! just keep assembler file 6001 // { dg-keep-saved-temps ".s" ".i" } ! ... and .i 6002 // { dg-keep-saved-temps ".ii" ".o" } ! or just .ii and .o 6003 6004'cleanup-profile-file' 6005 Removes profiling files generated for this test. 6006 6007'cleanup-repo-files' 6008 Removes files generated for this test for '-frepo'. 6009 6010 6011File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites 6012 60137.3 Ada Language Testsuites 6014=========================== 6015 6016The Ada testsuite includes executable tests from the ACATS testsuite, 6017publicly available at <http://www.ada-auth.org/acats.html>. 6018 6019 These tests are integrated in the GCC testsuite in the 'ada/acats' 6020directory, and enabled automatically when running 'make check', assuming 6021the Ada language has been enabled when configuring GCC. 6022 6023 You can also run the Ada testsuite independently, using 'make 6024check-ada', or run a subset of the tests by specifying which chapter to 6025run, e.g.: 6026 6027 $ make check-ada CHAPTERS="c3 c9" 6028 6029 The tests are organized by directory, each directory corresponding to a 6030chapter of the Ada Reference Manual. So for example, 'c9' corresponds 6031to chapter 9, which deals with tasking features of the language. 6032 6033 The tests are run using two 'sh' scripts: 'run_acats' and 'run_all.sh'. 6034To run the tests using a simulator or a cross target, see the small 6035customization section at the top of 'run_all.sh'. 6036 6037 These tests are run using the build tree: they can be run without doing 6038a 'make install'. 6039 6040 6041File: gccint.info, Node: C Tests, Next: LTO Testing, Prev: Ada Tests, Up: Testsuites 6042 60437.4 C Language Testsuites 6044========================= 6045 6046GCC contains the following C language testsuites, in the 'gcc/testsuite' 6047directory: 6048 6049'gcc.dg' 6050 This contains tests of particular features of the C compiler, using 6051 the more modern 'dg' harness. Correctness tests for various 6052 compiler features should go here if possible. 6053 6054 Magic comments determine whether the file is preprocessed, 6055 compiled, linked or run. In these tests, error and warning message 6056 texts are compared against expected texts or regular expressions 6057 given in comments. These tests are run with the options '-ansi 6058 -pedantic' unless other options are given in the test. Except as 6059 noted below they are not run with multiple optimization options. 6060'gcc.dg/compat' 6061 This subdirectory contains tests for binary compatibility using 6062 'lib/compat.exp', which in turn uses the language-independent 6063 support (*note Support for testing binary compatibility: compat 6064 Testing.). 6065'gcc.dg/cpp' 6066 This subdirectory contains tests of the preprocessor. 6067'gcc.dg/debug' 6068 This subdirectory contains tests for debug formats. Tests in this 6069 subdirectory are run for each debug format that the compiler 6070 supports. 6071'gcc.dg/format' 6072 This subdirectory contains tests of the '-Wformat' format checking. 6073 Tests in this directory are run with and without '-DWIDE'. 6074'gcc.dg/noncompile' 6075 This subdirectory contains tests of code that should not compile 6076 and does not need any special compilation options. They are run 6077 with multiple optimization options, since sometimes invalid code 6078 crashes the compiler with optimization. 6079'gcc.dg/special' 6080 FIXME: describe this. 6081 6082'gcc.c-torture' 6083 This contains particular code fragments which have historically 6084 broken easily. These tests are run with multiple optimization 6085 options, so tests for features which only break at some 6086 optimization levels belong here. This also contains tests to check 6087 that certain optimizations occur. It might be worthwhile to 6088 separate the correctness tests cleanly from the code quality tests, 6089 but it hasn't been done yet. 6090 6091'gcc.c-torture/compat' 6092 FIXME: describe this. 6093 6094 This directory should probably not be used for new tests. 6095'gcc.c-torture/compile' 6096 This testsuite contains test cases that should compile, but do not 6097 need to link or run. These test cases are compiled with several 6098 different combinations of optimization options. All warnings are 6099 disabled for these test cases, so this directory is not suitable if 6100 you wish to test for the presence or absence of compiler warnings. 6101 While special options can be set, and tests disabled on specific 6102 platforms, by the use of '.x' files, mostly these test cases should 6103 not contain platform dependencies. FIXME: discuss how defines such 6104 as 'STACK_SIZE' are used. 6105'gcc.c-torture/execute' 6106 This testsuite contains test cases that should compile, link and 6107 run; otherwise the same comments as for 'gcc.c-torture/compile' 6108 apply. 6109'gcc.c-torture/execute/ieee' 6110 This contains tests which are specific to IEEE floating point. 6111'gcc.c-torture/unsorted' 6112 FIXME: describe this. 6113 6114 This directory should probably not be used for new tests. 6115'gcc.misc-tests' 6116 This directory contains C tests that require special handling. 6117 Some of these tests have individual expect files, and others share 6118 special-purpose expect files: 6119 6120 'bprob*.c' 6121 Test '-fbranch-probabilities' using 6122 'gcc.misc-tests/bprob.exp', which in turn uses the generic, 6123 language-independent framework (*note Support for testing 6124 profile-directed optimizations: profopt Testing.). 6125 6126 'gcov*.c' 6127 Test 'gcov' output using 'gcov.exp', which in turn uses the 6128 language-independent support (*note Support for testing gcov: 6129 gcov Testing.). 6130 6131 'i386-pf-*.c' 6132 Test i386-specific support for data prefetch using 6133 'i386-prefetch.exp'. 6134 6135'gcc.test-framework' 6136 'dg-*.c' 6137 Test the testsuite itself using 6138 'gcc.test-framework/test-framework.exp'. 6139 6140 FIXME: merge in 'testsuite/README.gcc' and discuss the format of test 6141cases and magic comments more. 6142 6143 6144File: gccint.info, Node: LTO Testing, Next: gcov Testing, Prev: C Tests, Up: Testsuites 6145 61467.5 Support for testing link-time optimizations 6147=============================================== 6148 6149Tests for link-time optimizations usually require multiple source files 6150that are compiled separately, perhaps with different sets of options. 6151There are several special-purpose test directives used for these tests. 6152 6153'{ dg-lto-do DO-WHAT-KEYWORD }' 6154 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 6155 is executed. It is one of: 6156 6157 'assemble' 6158 Compile with '-c' to produce a relocatable object file. 6159 'link' 6160 Compile, assemble, and link to produce an executable file. 6161 'run' 6162 Produce and run an executable file, which is expected to 6163 return an exit code of 0. 6164 6165 The default is 'assemble'. That can be overridden for a set of 6166 tests by redefining 'dg-do-what-default' within the '.exp' file for 6167 those tests. 6168 6169 Unlike 'dg-do', 'dg-lto-do' does not support an optional 'target' 6170 or 'xfail' list. Use 'dg-skip-if', 'dg-xfail-if', or 6171 'dg-xfail-run-if'. 6172 6173'{ dg-lto-options { { OPTIONS } [{ OPTIONS }] } [{ target SELECTOR }]}' 6174 This directive provides a list of one or more sets of compiler 6175 options to override LTO_OPTIONS. Each test will be compiled and 6176 run with each of these sets of options. 6177 6178'{ dg-extra-ld-options OPTIONS [{ target SELECTOR }]}' 6179 This directive adds OPTIONS to the linker options used. 6180 6181'{ dg-suppress-ld-options OPTIONS [{ target SELECTOR }]}' 6182 This directive removes OPTIONS from the set of linker options used. 6183 6184 6185File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: LTO Testing, Up: Testsuites 6186 61877.6 Support for testing 'gcov' 6188============================== 6189 6190Language-independent support for testing 'gcov', and for checking that 6191branch profiling produces expected values, is provided by the expect 6192file 'lib/gcov.exp'. 'gcov' tests also rely on procedures in 6193'lib/gcc-dg.exp' to compile and run the test program. A typical 'gcov' 6194test contains the following DejaGnu commands within comments: 6195 6196 { dg-options "--coverage" } 6197 { dg-do run { target native } } 6198 { dg-final { run-gcov sourcefile } } 6199 6200 Checks of 'gcov' output can include line counts, branch percentages, 6201and call return percentages. All of these checks are requested via 6202commands that appear in comments in the test's source file. Commands to 6203check line counts are processed by default. Commands to check branch 6204percentages and call return percentages are processed if the 'run-gcov' 6205command has arguments 'branches' or 'calls', respectively. For example, 6206the following specifies checking both, as well as passing '-b' to 6207'gcov': 6208 6209 { dg-final { run-gcov branches calls { -b sourcefile } } } 6210 6211 A line count command appears within a comment on the source line that 6212is expected to get the specified count and has the form 'count(CNT)'. A 6213test should only check line counts for lines that will get the same 6214count for any architecture. 6215 6216 Commands to check branch percentages ('branch') and call return 6217percentages ('returns') are very similar to each other. A beginning 6218command appears on or before the first of a range of lines that will 6219report the percentage, and the ending command follows that range of 6220lines. The beginning command can include a list of percentages, all of 6221which are expected to be found within the range. A range is terminated 6222by the next command of the same kind. A command 'branch(end)' or 6223'returns(end)' marks the end of a range without starting a new one. For 6224example: 6225 6226 if (i > 10 && j > i && j < 20) /* branch(27 50 75) */ 6227 /* branch(end) */ 6228 foo (i, j); 6229 6230 For a call return percentage, the value specified is the percentage of 6231calls reported to return. For a branch percentage, the value is either 6232the expected percentage or 100 minus that value, since the direction of 6233a branch can differ depending on the target or the optimization level. 6234 6235 Not all branches and calls need to be checked. A test should not check 6236for branches that might be optimized away or replaced with predicated 6237instructions. Don't check for calls inserted by the compiler or ones 6238that might be inlined or optimized away. 6239 6240 A single test can check for combinations of line counts, branch 6241percentages, and call return percentages. The command to check a line 6242count must appear on the line that will report that count, but commands 6243to check branch percentages and call return percentages can bracket the 6244lines that report them. 6245 6246 6247File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites 6248 62497.7 Support for testing profile-directed optimizations 6250====================================================== 6251 6252The file 'profopt.exp' provides language-independent support for 6253checking correct execution of a test built with profile-directed 6254optimization. This testing requires that a test program be built and 6255executed twice. The first time it is compiled to generate profile data, 6256and the second time it is compiled to use the data that was generated 6257during the first execution. The second execution is to verify that the 6258test produces the expected results. 6259 6260 To check that the optimization actually generated better code, a test 6261can be built and run a third time with normal optimizations to verify 6262that the performance is better with the profile-directed optimizations. 6263'profopt.exp' has the beginnings of this kind of support. 6264 6265 'profopt.exp' provides generic support for profile-directed 6266optimizations. Each set of tests that uses it provides information 6267about a specific optimization: 6268 6269'tool' 6270 tool being tested, e.g., 'gcc' 6271 6272'profile_option' 6273 options used to generate profile data 6274 6275'feedback_option' 6276 options used to optimize using that profile data 6277 6278'prof_ext' 6279 suffix of profile data files 6280 6281'PROFOPT_OPTIONS' 6282 list of options with which to run each test, similar to the lists 6283 for torture tests 6284 6285'{ dg-final-generate { LOCAL-DIRECTIVE } }' 6286 This directive is similar to 'dg-final', but the LOCAL-DIRECTIVE is 6287 run after the generation of profile data. 6288 6289'{ dg-final-use { LOCAL-DIRECTIVE } }' 6290 The LOCAL-DIRECTIVE is run after the profile data have been used. 6291 6292 6293File: gccint.info, Node: compat Testing, Next: Torture Tests, Prev: profopt Testing, Up: Testsuites 6294 62957.8 Support for testing binary compatibility 6296============================================ 6297 6298The file 'compat.exp' provides language-independent support for binary 6299compatibility testing. It supports testing interoperability of two 6300compilers that follow the same ABI, or of multiple sets of compiler 6301options that should not affect binary compatibility. It is intended to 6302be used for testsuites that complement ABI testsuites. 6303 6304 A test supported by this framework has three parts, each in a separate 6305source file: a main program and two pieces that interact with each other 6306to split up the functionality being tested. 6307 6308'TESTNAME_main.SUFFIX' 6309 Contains the main program, which calls a function in file 6310 'TESTNAME_x.SUFFIX'. 6311 6312'TESTNAME_x.SUFFIX' 6313 Contains at least one call to a function in 'TESTNAME_y.SUFFIX'. 6314 6315'TESTNAME_y.SUFFIX' 6316 Shares data with, or gets arguments from, 'TESTNAME_x.SUFFIX'. 6317 6318 Within each test, the main program and one functional piece are 6319compiled by the GCC under test. The other piece can be compiled by an 6320alternate compiler. If no alternate compiler is specified, then all 6321three source files are all compiled by the GCC under test. You can 6322specify pairs of sets of compiler options. The first element of such a 6323pair specifies options used with the GCC under test, and the second 6324element of the pair specifies options used with the alternate compiler. 6325Each test is compiled with each pair of options. 6326 6327 'compat.exp' defines default pairs of compiler options. These can be 6328overridden by defining the environment variable 'COMPAT_OPTIONS' as: 6329 6330 COMPAT_OPTIONS="[list [list {TST1} {ALT1}] 6331 ...[list {TSTN} {ALTN}]]" 6332 6333 where TSTI and ALTI are lists of options, with TSTI used by the 6334compiler under test and ALTI used by the alternate compiler. For 6335example, with '[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]', 6336the test is first built with '-g -O0' by the compiler under test and 6337with '-O3' by the alternate compiler. The test is built a second time 6338using '-fpic' by the compiler under test and '-fPIC -O2' by the 6339alternate compiler. 6340 6341 An alternate compiler is specified by defining an environment variable 6342to be the full pathname of an installed compiler; for C define 6343'ALT_CC_UNDER_TEST', and for C++ define 'ALT_CXX_UNDER_TEST'. These 6344will be written to the 'site.exp' file used by DejaGnu. The default is 6345to build each test with the compiler under test using the first of each 6346pair of compiler options from 'COMPAT_OPTIONS'. When 6347'ALT_CC_UNDER_TEST' or 'ALT_CXX_UNDER_TEST' is 'same', each test is 6348built using the compiler under test but with combinations of the options 6349from 'COMPAT_OPTIONS'. 6350 6351 To run only the C++ compatibility suite using the compiler under test 6352and another version of GCC using specific compiler options, do the 6353following from 'OBJDIR/gcc': 6354 6355 rm site.exp 6356 make -k \ 6357 ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \ 6358 COMPAT_OPTIONS="LISTS AS SHOWN ABOVE" \ 6359 check-c++ \ 6360 RUNTESTFLAGS="compat.exp" 6361 6362 A test that fails when the source files are compiled with different 6363compilers, but passes when the files are compiled with the same 6364compiler, demonstrates incompatibility of the generated code or runtime 6365support. A test that fails for the alternate compiler but passes for 6366the compiler under test probably tests for a bug that was fixed in the 6367compiler under test but is present in the alternate compiler. 6368 6369 The binary compatibility tests support a small number of test framework 6370commands that appear within comments in a test file. 6371 6372'dg-require-*' 6373 These commands can be used in 'TESTNAME_main.SUFFIX' to skip the 6374 test if specific support is not available on the target. 6375 6376'dg-options' 6377 The specified options are used for compiling this particular source 6378 file, appended to the options from 'COMPAT_OPTIONS'. When this 6379 command appears in 'TESTNAME_main.SUFFIX' the options are also used 6380 to link the test program. 6381 6382'dg-xfail-if' 6383 This command can be used in a secondary source file to specify that 6384 compilation is expected to fail for particular options on 6385 particular targets. 6386 6387 6388File: gccint.info, Node: Torture Tests, Next: GIMPLE Tests, Prev: compat Testing, Up: Testsuites 6389 63907.9 Support for torture testing using multiple options 6391====================================================== 6392 6393Throughout the compiler testsuite there are several directories whose 6394tests are run multiple times, each with a different set of options. 6395These are known as torture tests. 'lib/torture-options.exp' defines 6396procedures to set up these lists: 6397 6398'torture-init' 6399 Initialize use of torture lists. 6400'set-torture-options' 6401 Set lists of torture options to use for tests with and without 6402 loops. Optionally combine a set of torture options with a set of 6403 other options, as is done with Objective-C runtime options. 6404'torture-finish' 6405 Finalize use of torture lists. 6406 6407 The '.exp' file for a set of tests that use torture options must 6408include calls to these three procedures if: 6409 6410 * It calls 'gcc-dg-runtest' and overrides DG_TORTURE_OPTIONS. 6411 6412 * It calls ${TOOL}'-torture' or ${TOOL}'-torture-execute', where TOOL 6413 is 'c', 'fortran', or 'objc'. 6414 6415 * It calls 'dg-pch'. 6416 6417 It is not necessary for a '.exp' file that calls 'gcc-dg-runtest' to 6418call the torture procedures if the tests should use the list in 6419DG_TORTURE_OPTIONS defined in 'gcc-dg.exp'. 6420 6421 Most uses of torture options can override the default lists by defining 6422TORTURE_OPTIONS or add to the default list by defining 6423ADDITIONAL_TORTURE_OPTIONS. Define these in a '.dejagnurc' file or add 6424them to the 'site.exp' file; for example 6425 6426 set ADDITIONAL_TORTURE_OPTIONS [list \ 6427 { -O2 -ftree-loop-linear } \ 6428 { -O2 -fpeel-loops } ] 6429 6430 6431File: gccint.info, Node: GIMPLE Tests, Next: RTL Tests, Prev: Torture Tests, Up: Testsuites 6432 64337.10 Support for testing GIMPLE passes 6434====================================== 6435 6436As of gcc 7, C functions can be tagged with '__GIMPLE' to indicate that 6437the function body will be GIMPLE, rather than C. The compiler requires 6438the option '-fgimple' to enable this functionality. For example: 6439 6440 /* { dg-do compile } */ 6441 /* { dg-options "-O -fgimple" } */ 6442 6443 void __GIMPLE (startwith ("dse2")) foo () 6444 { 6445 int a; 6446 6447 bb_2: 6448 if (a > 4) 6449 goto bb_3; 6450 else 6451 goto bb_4; 6452 6453 bb_3: 6454 a_2 = 10; 6455 goto bb_5; 6456 6457 bb_4: 6458 a_3 = 20; 6459 6460 bb_5: 6461 a_1 = __PHI (bb_3: a_2, bb_4: a_3); 6462 a_4 = a_1 + 4; 6463 6464 return; 6465 } 6466 6467 The 'startwith' argument indicates at which pass to begin. 6468 6469 Use the dump modifier '-gimple' (e.g. '-fdump-tree-all-gimple') to make 6470tree dumps more closely follow the format accepted by the GIMPLE parser. 6471 6472 Example DejaGnu tests of GIMPLE can be seen in the source tree at 6473'gcc/testsuite/gcc.dg/gimplefe-*.c'. 6474 6475 The '__GIMPLE' parser is integrated with the C tokenizer and 6476preprocessor, so it should be possible to use macros to build out test 6477coverage. 6478 6479 6480File: gccint.info, Node: RTL Tests, Prev: GIMPLE Tests, Up: Testsuites 6481 64827.11 Support for testing RTL passes 6483=================================== 6484 6485As of gcc 7, C functions can be tagged with '__RTL' to indicate that the 6486function body will be RTL, rather than C. For example: 6487 6488 double __RTL (startwith ("ira")) test (struct foo *f, const struct bar *b) 6489 { 6490 (function "test" 6491 [...snip; various directives go in here...] 6492 ) ;; function "test" 6493 } 6494 6495 The 'startwith' argument indicates at which pass to begin. 6496 6497 The parser expects the RTL body to be in the format emitted by this 6498dumping function: 6499 6500 DEBUG_FUNCTION void 6501 print_rtx_function (FILE *outfile, function *fn, bool compact); 6502 6503 when "compact" is true. So you can capture RTL in the correct format 6504from the debugger using: 6505 6506 (gdb) print_rtx_function (stderr, cfun, true); 6507 6508 and copy and paste the output into the body of the C function. 6509 6510 Example DejaGnu tests of RTL can be seen in the source tree under 6511'gcc/testsuite/gcc.dg/rtl'. 6512 6513 The '__RTL' parser is not integrated with the C tokenizer or 6514preprocessor, and works simply by reading the relevant lines within the 6515braces. In particular, the RTL body must be on separate lines from the 6516enclosing braces, and the preprocessor is not usable within it. 6517 6518 6519File: gccint.info, Node: Options, Next: Passes, Prev: Testsuites, Up: Top 6520 65218 Option specification files 6522**************************** 6523 6524Most GCC command-line options are described by special option definition 6525files, the names of which conventionally end in '.opt'. This chapter 6526describes the format of these files. 6527 6528* Menu: 6529 6530* Option file format:: The general layout of the files 6531* Option properties:: Supported option properties 6532 6533 6534File: gccint.info, Node: Option file format, Next: Option properties, Up: Options 6535 65368.1 Option file format 6537====================== 6538 6539Option files are a simple list of records in which each field occupies 6540its own line and in which the records themselves are separated by blank 6541lines. Comments may appear on their own line anywhere within the file 6542and are preceded by semicolons. Whitespace is allowed before the 6543semicolon. 6544 6545 The files can contain the following types of record: 6546 6547 * A language definition record. These records have two fields: the 6548 string 'Language' and the name of the language. Once a language 6549 has been declared in this way, it can be used as an option 6550 property. *Note Option properties::. 6551 6552 * A target specific save record to save additional information. 6553 These records have two fields: the string 'TargetSave', and a 6554 declaration type to go in the 'cl_target_option' structure. 6555 6556 * A variable record to define a variable used to store option 6557 information. These records have two fields: the string 'Variable', 6558 and a declaration of the type and name of the variable, optionally 6559 with an initializer (but without any trailing ';'). These records 6560 may be used for variables used for many options where declaring the 6561 initializer in a single option definition record, or duplicating it 6562 in many records, would be inappropriate, or for variables set in 6563 option handlers rather than referenced by 'Var' properties. 6564 6565 * A variable record to define a variable used to store option 6566 information. These records have two fields: the string 6567 'TargetVariable', and a declaration of the type and name of the 6568 variable, optionally with an initializer (but without any trailing 6569 ';'). 'TargetVariable' is a combination of 'Variable' and 6570 'TargetSave' records in that the variable is defined in the 6571 'gcc_options' structure, but these variables are also stored in the 6572 'cl_target_option' structure. The variables are saved in the 6573 target save code and restored in the target restore code. 6574 6575 * A variable record to record any additional files that the 6576 'options.h' file should include. This is useful to provide 6577 enumeration or structure definitions needed for target variables. 6578 These records have two fields: the string 'HeaderInclude' and the 6579 name of the include file. 6580 6581 * A variable record to record any additional files that the 6582 'options.c' or 'options-save.c' file should include. This is 6583 useful to provide inline functions needed for target variables 6584 and/or '#ifdef' sequences to properly set up the initialization. 6585 These records have two fields: the string 'SourceInclude' and the 6586 name of the include file. 6587 6588 * An enumeration record to define a set of strings that may be used 6589 as arguments to an option or options. These records have three 6590 fields: the string 'Enum', a space-separated list of properties and 6591 help text used to describe the set of strings in '--help' output. 6592 Properties use the same format as option properties; the following 6593 are valid: 6594 'Name(NAME)' 6595 This property is required; NAME must be a name (suitable for 6596 use in C identifiers) used to identify the set of strings in 6597 'Enum' option properties. 6598 6599 'Type(TYPE)' 6600 This property is required; TYPE is the C type for variables 6601 set by options using this enumeration together with 'Var'. 6602 6603 'UnknownError(MESSAGE)' 6604 The message MESSAGE will be used as an error message if the 6605 argument is invalid; for enumerations without 'UnknownError', 6606 a generic error message is used. MESSAGE should contain a 6607 single '%qs' format, which will be used to format the invalid 6608 argument. 6609 6610 * An enumeration value record to define one of the strings in a set 6611 given in an 'Enum' record. These records have two fields: the 6612 string 'EnumValue' and a space-separated list of properties. 6613 Properties use the same format as option properties; the following 6614 are valid: 6615 'Enum(NAME)' 6616 This property is required; NAME says which 'Enum' record this 6617 'EnumValue' record corresponds to. 6618 6619 'String(STRING)' 6620 This property is required; STRING is the string option 6621 argument being described by this record. 6622 6623 'Value(VALUE)' 6624 This property is required; it says what value (representable 6625 as 'int') should be used for the given string. 6626 6627 'Canonical' 6628 This property is optional. If present, it says the present 6629 string is the canonical one among all those with the given 6630 value. Other strings yielding that value will be mapped to 6631 this one so specs do not need to handle them. 6632 6633 'DriverOnly' 6634 This property is optional. If present, the present string 6635 will only be accepted by the driver. This is used for cases 6636 such as '-march=native' that are processed by the driver so 6637 that 'gcc -v' shows how the options chosen depended on the 6638 system on which the compiler was run. 6639 6640 * An option definition record. These records have the following 6641 fields: 6642 1. the name of the option, with the leading "-" removed 6643 2. a space-separated list of option properties (*note Option 6644 properties::) 6645 3. the help text to use for '--help' (omitted if the second field 6646 contains the 'Undocumented' property). 6647 6648 By default, all options beginning with "f", "W" or "m" are 6649 implicitly assumed to take a "no-" form. This form should not be 6650 listed separately. If an option beginning with one of these 6651 letters does not have a "no-" form, you can use the 6652 'RejectNegative' property to reject it. 6653 6654 The help text is automatically line-wrapped before being displayed. 6655 Normally the name of the option is printed on the left-hand side of 6656 the output and the help text is printed on the right. However, if 6657 the help text contains a tab character, the text to the left of the 6658 tab is used instead of the option's name and the text to the right 6659 of the tab forms the help text. This allows you to elaborate on 6660 what type of argument the option takes. 6661 6662 * A target mask record. These records have one field of the form 6663 'Mask(X)'. The options-processing script will automatically 6664 allocate a bit in 'target_flags' (*note Run-time Target::) for each 6665 mask name X and set the macro 'MASK_X' to the appropriate bitmask. 6666 It will also declare a 'TARGET_X' macro that has the value 1 when 6667 bit 'MASK_X' is set and 0 otherwise. 6668 6669 They are primarily intended to declare target masks that are not 6670 associated with user options, either because these masks represent 6671 internal switches or because the options are not available on all 6672 configurations and yet the masks always need to be defined. 6673 6674 6675File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options 6676 66778.2 Option properties 6678===================== 6679 6680The second field of an option record can specify any of the following 6681properties. When an option takes an argument, it is enclosed in 6682parentheses following the option property name. The parser that handles 6683option files is quite simplistic, and will be tricked by any nested 6684parentheses within the argument text itself; in this case, the entire 6685option argument can be wrapped in curly braces within the parentheses to 6686demarcate it, e.g.: 6687 6688 Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)}) 6689 6690'Common' 6691 The option is available for all languages and targets. 6692 6693'Target' 6694 The option is available for all languages but is target-specific. 6695 6696'Driver' 6697 The option is handled by the compiler driver using code not shared 6698 with the compilers proper ('cc1' etc.). 6699 6700'LANGUAGE' 6701 The option is available when compiling for the given language. 6702 6703 It is possible to specify several different languages for the same 6704 option. Each LANGUAGE must have been declared by an earlier 6705 'Language' record. *Note Option file format::. 6706 6707'RejectDriver' 6708 The option is only handled by the compilers proper ('cc1' etc.) and 6709 should not be accepted by the driver. 6710 6711'RejectNegative' 6712 The option does not have a "no-" form. All options beginning with 6713 "f", "W" or "m" are assumed to have a "no-" form unless this 6714 property is used. 6715 6716'Negative(OTHERNAME)' 6717 The option will turn off another option OTHERNAME, which is the 6718 option name with the leading "-" removed. This chain action will 6719 propagate through the 'Negative' property of the option to be 6720 turned off. The driver will prune options, removing those that are 6721 turned off by some later option. This pruning is not done for 6722 options with 'Joined' or 'JoinedOrMissing' properties, unless the 6723 options have either 'RejectNegative' property or the 'Negative' 6724 property mentions an option other than itself. 6725 6726 As a consequence, if you have a group of mutually-exclusive 6727 options, their 'Negative' properties should form a circular chain. 6728 For example, if options '-A', '-B' and '-C' are mutually exclusive, 6729 their respective 'Negative' properties should be 'Negative(B)', 6730 'Negative(C)' and 'Negative(A)'. 6731 6732'Joined' 6733'Separate' 6734 The option takes a mandatory argument. 'Joined' indicates that the 6735 option and argument can be included in the same 'argv' entry (as 6736 with '-mflush-func=NAME', for example). 'Separate' indicates that 6737 the option and argument can be separate 'argv' entries (as with 6738 '-o'). An option is allowed to have both of these properties. 6739 6740'JoinedOrMissing' 6741 The option takes an optional argument. If the argument is given, 6742 it will be part of the same 'argv' entry as the option itself. 6743 6744 This property cannot be used alongside 'Joined' or 'Separate'. 6745 6746'MissingArgError(MESSAGE)' 6747 For an option marked 'Joined' or 'Separate', the message MESSAGE 6748 will be used as an error message if the mandatory argument is 6749 missing; for options without 'MissingArgError', a generic error 6750 message is used. MESSAGE should contain a single '%qs' format, 6751 which will be used to format the name of the option passed. 6752 6753'Args(N)' 6754 For an option marked 'Separate', indicate that it takes N 6755 arguments. The default is 1. 6756 6757'UInteger' 6758 The option's argument is a non-negative integer consisting of 6759 either decimal or hexadecimal digits interpreted as 'int'. 6760 Hexadecimal integers may optionally start with the '0x' or '0X' 6761 prefix. The option parser validates and converts the argument 6762 before passing it to the relevant option handler. 'UInteger' 6763 should also be used with options like '-falign-loops' where both 6764 '-falign-loops' and '-falign-loops'=N are supported to make sure 6765 the saved options are given a full integer. Positive values of the 6766 argument in excess of 'INT_MAX' wrap around zero. 6767 6768'Host_Wide_Int' 6769 The option's argument is a non-negative integer consisting of 6770 either decimal or hexadecimal digits interpreted as the widest 6771 integer type on the host. As with an 'UInteger' argument, 6772 hexadecimal integers may optionally start with the '0x' or '0X' 6773 prefix. The option parser validates and converts the argument 6774 before passing it to the relevant option handler. 'Host_Wide_Int' 6775 should be used with options that need to accept very large values. 6776 Positive values of the argument in excess of 'HOST_WIDE_INT_M1U' 6777 are assigned 'HOST_WIDE_INT_M1U'. 6778 6779'IntegerRange(N, M)' 6780 The options's arguments are integers of type 'int'. The option's 6781 parser validates that the value of an option integer argument is 6782 within the closed range [N, M]. 6783 6784'ByteSize' 6785 A property applicable only to 'UInteger' or 'Host_Wide_Int' 6786 arguments. The option's integer argument is interpreted as if in 6787 infinite precision using saturation arithmetic in the corresponding 6788 type. The argument may be followed by a 'byte-size' suffix 6789 designating a multiple of bytes such as 'kB' and 'KiB' for kilobyte 6790 and kibibyte, respectively, 'MB' and 'MiB' for megabyte and 6791 mebibyte, 'GB' and 'GiB' for gigabyte and gigibyte, and so on. 6792 'ByteSize' should be used for with options that take a very large 6793 argument representing a size in bytes, such as '-Wlarger-than='. 6794 6795'ToLower' 6796 The option's argument should be converted to lowercase as part of 6797 putting it in canonical form, and before comparing with the strings 6798 indicated by any 'Enum' property. 6799 6800'NoDriverArg' 6801 For an option marked 'Separate', the option only takes an argument 6802 in the compiler proper, not in the driver. This is for 6803 compatibility with existing options that are used both directly and 6804 via '-Wp,'; new options should not have this property. 6805 6806'Var(VAR)' 6807 The state of this option should be stored in variable VAR (actually 6808 a macro for 'global_options.x_VAR'). The way that the state is 6809 stored depends on the type of option: 6810 6811'Deprecated' 6812 The option is deprecated and every usage of such option will result 6813 in a warning. 6814 6815'Var(VAR, SET)' 6816 The option controls an integer variable VAR and is active when VAR 6817 equals SET. The option parser will set VAR to SET when the 6818 positive form of the option is used and '!SET' when the "no-" form 6819 is used. 6820 6821 VAR is declared in the same way as for the single-argument form 6822 described above. 6823 6824 * If the option uses the 'Mask' or 'InverseMask' properties, VAR 6825 is the integer variable that contains the mask. 6826 6827 * If the option is a normal on/off switch, VAR is an integer 6828 variable that is nonzero when the option is enabled. The 6829 options parser will set the variable to 1 when the positive 6830 form of the option is used and 0 when the "no-" form is used. 6831 6832 * If the option takes an argument and has the 'UInteger' 6833 property, VAR is an integer variable that stores the value of 6834 the argument. 6835 6836 * If the option takes an argument and has the 'Enum' property, 6837 VAR is a variable (type given in the 'Type' property of the 6838 'Enum' record whose 'Name' property has the same argument as 6839 the 'Enum' property of this option) that stores the value of 6840 the argument. 6841 6842 * If the option has the 'Defer' property, VAR is a pointer to a 6843 'VEC(cl_deferred_option,heap)' that stores the option for 6844 later processing. (VAR is declared with type 'void *' and 6845 needs to be cast to 'VEC(cl_deferred_option,heap)' before 6846 use.) 6847 6848 * Otherwise, if the option takes an argument, VAR is a pointer 6849 to the argument string. The pointer will be null if the 6850 argument is optional and wasn't given. 6851 6852 The option-processing script will usually zero-initialize VAR. You 6853 can modify this behavior using 'Init'. 6854 6855'Init(VALUE)' 6856 The variable specified by the 'Var' property should be statically 6857 initialized to VALUE. If more than one option using the same 6858 variable specifies 'Init', all must specify the same initializer. 6859 6860'Mask(NAME)' 6861 The option is associated with a bit in the 'target_flags' variable 6862 (*note Run-time Target::) and is active when that bit is set. You 6863 may also specify 'Var' to select a variable other than 6864 'target_flags'. 6865 6866 The options-processing script will automatically allocate a unique 6867 bit for the option. If the option is attached to 'target_flags', 6868 the script will set the macro 'MASK_NAME' to the appropriate 6869 bitmask. It will also declare a 'TARGET_NAME' macro that has the 6870 value 1 when the option is active and 0 otherwise. If you use 6871 'Var' to attach the option to a different variable, the bitmask 6872 macro with be called 'OPTION_MASK_NAME'. 6873 6874'InverseMask(OTHERNAME)' 6875'InverseMask(OTHERNAME, THISNAME)' 6876 The option is the inverse of another option that has the 6877 'Mask(OTHERNAME)' property. If THISNAME is given, the 6878 options-processing script will declare a 'TARGET_THISNAME' macro 6879 that is 1 when the option is active and 0 otherwise. 6880 6881'Enum(NAME)' 6882 The option's argument is a string from the set of strings 6883 associated with the corresponding 'Enum' record. The string is 6884 checked and converted to the integer specified in the corresponding 6885 'EnumValue' record before being passed to option handlers. 6886 6887'Defer' 6888 The option should be stored in a vector, specified with 'Var', for 6889 later processing. 6890 6891'Alias(OPT)' 6892'Alias(OPT, ARG)' 6893'Alias(OPT, POSARG, NEGARG)' 6894 The option is an alias for '-OPT' (or the negative form of that 6895 option, depending on 'NegativeAlias'). In the first form, any 6896 argument passed to the alias is considered to be passed to '-OPT', 6897 and '-OPT' is considered to be negated if the alias is used in 6898 negated form. In the second form, the alias may not be negated or 6899 have an argument, and POSARG is considered to be passed as an 6900 argument to '-OPT'. In the third form, the alias may not have an 6901 argument, if the alias is used in the positive form then POSARG is 6902 considered to be passed to '-OPT', and if the alias is used in the 6903 negative form then NEGARG is considered to be passed to '-OPT'. 6904 6905 Aliases should not specify 'Var' or 'Mask' or 'UInteger'. Aliases 6906 should normally specify the same languages as the target of the 6907 alias; the flags on the target will be used to determine any 6908 diagnostic for use of an option for the wrong language, while those 6909 on the alias will be used to identify what command-line text is the 6910 option and what text is any argument to that option. 6911 6912 When an 'Alias' definition is used for an option, driver specs do 6913 not need to handle it and no 'OPT_' enumeration value is defined 6914 for it; only the canonical form of the option will be seen in those 6915 places. 6916 6917'NegativeAlias' 6918 For an option marked with 'Alias(OPT)', the option is considered to 6919 be an alias for the positive form of '-OPT' if negated and for the 6920 negative form of '-OPT' if not negated. 'NegativeAlias' may not be 6921 used with the forms of 'Alias' taking more than one argument. 6922 6923'Ignore' 6924 This option is ignored apart from printing any warning specified 6925 using 'Warn'. The option will not be seen by specs and no 'OPT_' 6926 enumeration value is defined for it. 6927 6928'SeparateAlias' 6929 For an option marked with 'Joined', 'Separate' and 'Alias', the 6930 option only acts as an alias when passed a separate argument; with 6931 a joined argument it acts as a normal option, with an 'OPT_' 6932 enumeration value. This is for compatibility with the Java '-d' 6933 option and should not be used for new options. 6934 6935'Warn(MESSAGE)' 6936 If this option is used, output the warning MESSAGE. MESSAGE is a 6937 format string, either taking a single operand with a '%qs' format 6938 which is the option name, or not taking any operands, which is 6939 passed to the 'warning' function. If an alias is marked 'Warn', 6940 the target of the alias must not also be marked 'Warn'. 6941 6942'Report' 6943 The state of the option should be printed by '-fverbose-asm'. 6944 6945'Warning' 6946 This is a warning option and should be shown as such in '--help' 6947 output. This flag does not currently affect anything other than 6948 '--help'. 6949 6950'Optimization' 6951 This is an optimization option. It should be shown as such in 6952 '--help' output, and any associated variable named using 'Var' 6953 should be saved and restored when the optimization level is changed 6954 with 'optimize' attributes. 6955 6956'PerFunction' 6957 This is an option that can be overridden on a per-function basis. 6958 'Optimization' implies 'PerFunction', but options that do not 6959 affect executable code generation may use this flag instead, so 6960 that the option is not taken into account in ways that might affect 6961 executable code generation. 6962 6963'Undocumented' 6964 The option is deliberately missing documentation and should not be 6965 included in the '--help' output. 6966 6967'Condition(COND)' 6968 The option should only be accepted if preprocessor condition COND 6969 is true. Note that any C declarations associated with the option 6970 will be present even if COND is false; COND simply controls whether 6971 the option is accepted and whether it is printed in the '--help' 6972 output. 6973 6974'Save' 6975 Build the 'cl_target_option' structure to hold a copy of the 6976 option, add the functions 'cl_target_option_save' and 6977 'cl_target_option_restore' to save and restore the options. 6978 6979'SetByCombined' 6980 The option may also be set by a combined option such as 6981 '-ffast-math'. This causes the 'gcc_options' struct to have a 6982 field 'frontend_set_NAME', where 'NAME' is the name of the field 6983 holding the value of this option (without the leading 'x_'). This 6984 gives the front end a way to indicate that the value has been set 6985 explicitly and should not be changed by the combined option. For 6986 example, some front ends use this to prevent '-ffast-math' and 6987 '-fno-fast-math' from changing the value of '-fmath-errno' for 6988 languages that do not use 'errno'. 6989 6990'EnabledBy(OPT)' 6991'EnabledBy(OPT || OPT2)' 6992'EnabledBy(OPT && OPT2)' 6993 If not explicitly set, the option is set to the value of '-OPT'; 6994 multiple options can be given, separated by '||'. The third form 6995 using '&&' specifies that the option is only set if both OPT and 6996 OPT2 are set. The options OPT and OPT2 must have the 'Common' 6997 property; otherwise, use 'LangEnabledBy'. 6998 6999'LangEnabledBy(LANGUAGE, OPT)' 7000'LangEnabledBy(LANGUAGE, OPT, POSARG, NEGARG)' 7001 When compiling for the given language, the option is set to the 7002 value of '-OPT', if not explicitly set. OPT can be also a list of 7003 '||' separated options. In the second form, if OPT is used in the 7004 positive form then POSARG is considered to be passed to the option, 7005 and if OPT is used in the negative form then NEGARG is considered 7006 to be passed to the option. It is possible to specify several 7007 different languages. Each LANGUAGE must have been declared by an 7008 earlier 'Language' record. *Note Option file format::. 7009 7010'NoDWARFRecord' 7011 The option is omitted from the producer string written by 7012 '-grecord-gcc-switches'. 7013 7014'PchIgnore' 7015 Even if this is a target option, this option will not be recorded / 7016 compared to determine if a precompiled header file matches. 7017 7018'CPP(VAR)' 7019 The state of this option should be kept in sync with the 7020 preprocessor option VAR. If this property is set, then properties 7021 'Var' and 'Init' must be set as well. 7022 7023'CppReason(CPP_W_ENUM)' 7024 This warning option corresponds to 'cpplib.h' warning reason code 7025 CPP_W_ENUM. This should only be used for warning options of the 7026 C-family front-ends. 7027 7028 7029File: gccint.info, Node: Passes, Next: poly_int, Prev: Options, Up: Top 7030 70319 Passes and Files of the Compiler 7032********************************** 7033 7034This chapter is dedicated to giving an overview of the optimization and 7035code generation passes of the compiler. In the process, it describes 7036some of the language front end interface, though this description is no 7037where near complete. 7038 7039* Menu: 7040 7041* Parsing pass:: The language front end turns text into bits. 7042* Gimplification pass:: The bits are turned into something we can optimize. 7043* Pass manager:: Sequencing the optimization passes. 7044* Tree SSA passes:: Optimizations on a high-level representation. 7045* RTL passes:: Optimizations on a low-level representation. 7046* Optimization info:: Dumping optimization information from passes. 7047 7048 7049File: gccint.info, Node: Parsing pass, Next: Gimplification pass, Up: Passes 7050 70519.1 Parsing pass 7052================ 7053 7054The language front end is invoked only once, via 7055'lang_hooks.parse_file', to parse the entire input. The language front 7056end may use any intermediate language representation deemed appropriate. 7057The C front end uses GENERIC trees (*note GENERIC::), plus a double 7058handful of language specific tree codes defined in 'c-common.def'. The 7059Fortran front end uses a completely different private representation. 7060 7061 At some point the front end must translate the representation used in 7062the front end to a representation understood by the language-independent 7063portions of the compiler. Current practice takes one of two forms. The 7064C front end manually invokes the gimplifier (*note GIMPLE::) on each 7065function, and uses the gimplifier callbacks to convert the 7066language-specific tree nodes directly to GIMPLE before passing the 7067function off to be compiled. The Fortran front end converts from a 7068private representation to GENERIC, which is later lowered to GIMPLE when 7069the function is compiled. Which route to choose probably depends on how 7070well GENERIC (plus extensions) can be made to match up with the source 7071language and necessary parsing data structures. 7072 7073 BUG: Gimplification must occur before nested function lowering, and 7074nested function lowering must be done by the front end before passing 7075the data off to cgraph. 7076 7077 TODO: Cgraph should control nested function lowering. It would only be 7078invoked when it is certain that the outer-most function is used. 7079 7080 TODO: Cgraph needs a gimplify_function callback. It should be invoked 7081when (1) it is certain that the function is used, (2) warning flags 7082specified by the user require some amount of compilation in order to 7083honor, (3) the language indicates that semantic analysis is not complete 7084until gimplification occurs. Hum... this sounds overly complicated. 7085Perhaps we should just have the front end gimplify always; in most cases 7086it's only one function call. 7087 7088 The front end needs to pass all function definitions and top level 7089declarations off to the middle-end so that they can be compiled and 7090emitted to the object file. For a simple procedural language, it is 7091usually most convenient to do this as each top level declaration or 7092definition is seen. There is also a distinction to be made between 7093generating functional code and generating complete debug information. 7094The only thing that is absolutely required for functional code is that 7095function and data _definitions_ be passed to the middle-end. For 7096complete debug information, function, data and type declarations should 7097all be passed as well. 7098 7099 In any case, the front end needs each complete top-level function or 7100data declaration, and each data definition should be passed to 7101'rest_of_decl_compilation'. Each complete type definition should be 7102passed to 'rest_of_type_compilation'. Each function definition should 7103be passed to 'cgraph_finalize_function'. 7104 7105 TODO: I know rest_of_compilation currently has all sorts of RTL 7106generation semantics. I plan to move all code generation bits (both 7107Tree and RTL) to compile_function. Should we hide cgraph from the front 7108ends and move back to rest_of_compilation as the official interface? 7109Possibly we should rename all three interfaces such that the names match 7110in some meaningful way and that is more descriptive than "rest_of". 7111 7112 The middle-end will, at its option, emit the function and data 7113definitions immediately or queue them for later processing. 7114 7115 7116File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Parsing pass, Up: Passes 7117 71189.2 Gimplification pass 7119======================= 7120 7121"Gimplification" is a whimsical term for the process of converting the 7122intermediate representation of a function into the GIMPLE language 7123(*note GIMPLE::). The term stuck, and so words like "gimplification", 7124"gimplify", "gimplifier" and the like are sprinkled throughout this 7125section of code. 7126 7127 While a front end may certainly choose to generate GIMPLE directly if 7128it chooses, this can be a moderately complex process unless the 7129intermediate language used by the front end is already fairly simple. 7130Usually it is easier to generate GENERIC trees plus extensions and let 7131the language-independent gimplifier do most of the work. 7132 7133 The main entry point to this pass is 'gimplify_function_tree' located 7134in 'gimplify.c'. From here we process the entire function gimplifying 7135each statement in turn. The main workhorse for this pass is 7136'gimplify_expr'. Approximately everything passes through here at least 7137once, and it is from here that we invoke the 'lang_hooks.gimplify_expr' 7138callback. 7139 7140 The callback should examine the expression in question and return 7141'GS_UNHANDLED' if the expression is not a language specific construct 7142that requires attention. Otherwise it should alter the expression in 7143some way to such that forward progress is made toward producing valid 7144GIMPLE. If the callback is certain that the transformation is complete 7145and the expression is valid GIMPLE, it should return 'GS_ALL_DONE'. 7146Otherwise it should return 'GS_OK', which will cause the expression to 7147be processed again. If the callback encounters an error during the 7148transformation (because the front end is relying on the gimplification 7149process to finish semantic checks), it should return 'GS_ERROR'. 7150 7151 7152File: gccint.info, Node: Pass manager, Next: Tree SSA passes, Prev: Gimplification pass, Up: Passes 7153 71549.3 Pass manager 7155================ 7156 7157The pass manager is located in 'passes.c', 'tree-optimize.c' and 7158'tree-pass.h'. It processes passes as described in 'passes.def'. Its 7159job is to run all of the individual passes in the correct order, and 7160take care of standard bookkeeping that applies to every pass. 7161 7162 The theory of operation is that each pass defines a structure that 7163represents everything we need to know about that pass--when it should be 7164run, how it should be run, what intermediate language form or 7165on-the-side data structures it needs. We register the pass to be run in 7166some particular order, and the pass manager arranges for everything to 7167happen in the correct order. 7168 7169 The actuality doesn't completely live up to the theory at present. 7170Command-line switches and 'timevar_id_t' enumerations must still be 7171defined elsewhere. The pass manager validates constraints but does not 7172attempt to (re-)generate data structures or lower intermediate language 7173form based on the requirements of the next pass. Nevertheless, what is 7174present is useful, and a far sight better than nothing at all. 7175 7176 Each pass should have a unique name. Each pass may have its own dump 7177file (for GCC debugging purposes). Passes with a name starting with a 7178star do not dump anything. Sometimes passes are supposed to share a 7179dump file / option name. To still give these unique names, you can use 7180a prefix that is delimited by a space from the part that is used for the 7181dump file / option name. E.g. When the pass name is "ud dce", the name 7182used for dump file/options is "dce". 7183 7184 TODO: describe the global variables set up by the pass manager, and a 7185brief description of how a new pass should use it. I need to look at 7186what info RTL passes use first... 7187 7188 7189File: gccint.info, Node: Tree SSA passes, Next: RTL passes, Prev: Pass manager, Up: Passes 7190 71919.4 Tree SSA passes 7192=================== 7193 7194The following briefly describes the Tree optimization passes that are 7195run after gimplification and what source files they are located in. 7196 7197 * Remove useless statements 7198 7199 This pass is an extremely simple sweep across the gimple code in 7200 which we identify obviously dead code and remove it. Here we do 7201 things like simplify 'if' statements with constant conditions, 7202 remove exception handling constructs surrounding code that 7203 obviously cannot throw, remove lexical bindings that contain no 7204 variables, and other assorted simplistic cleanups. The idea is to 7205 get rid of the obvious stuff quickly rather than wait until later 7206 when it's more work to get rid of it. This pass is located in 7207 'tree-cfg.c' and described by 'pass_remove_useless_stmts'. 7208 7209 * OpenMP lowering 7210 7211 If OpenMP generation ('-fopenmp') is enabled, this pass lowers 7212 OpenMP constructs into GIMPLE. 7213 7214 Lowering of OpenMP constructs involves creating replacement 7215 expressions for local variables that have been mapped using data 7216 sharing clauses, exposing the control flow of most synchronization 7217 directives and adding region markers to facilitate the creation of 7218 the control flow graph. The pass is located in 'omp-low.c' and is 7219 described by 'pass_lower_omp'. 7220 7221 * OpenMP expansion 7222 7223 If OpenMP generation ('-fopenmp') is enabled, this pass expands 7224 parallel regions into their own functions to be invoked by the 7225 thread library. The pass is located in 'omp-low.c' and is 7226 described by 'pass_expand_omp'. 7227 7228 * Lower control flow 7229 7230 This pass flattens 'if' statements ('COND_EXPR') and moves lexical 7231 bindings ('BIND_EXPR') out of line. After this pass, all 'if' 7232 statements will have exactly two 'goto' statements in its 'then' 7233 and 'else' arms. Lexical binding information for each statement 7234 will be found in 'TREE_BLOCK' rather than being inferred from its 7235 position under a 'BIND_EXPR'. This pass is found in 'gimple-low.c' 7236 and is described by 'pass_lower_cf'. 7237 7238 * Lower exception handling control flow 7239 7240 This pass decomposes high-level exception handling constructs 7241 ('TRY_FINALLY_EXPR' and 'TRY_CATCH_EXPR') into a form that 7242 explicitly represents the control flow involved. After this pass, 7243 'lookup_stmt_eh_region' will return a non-negative number for any 7244 statement that may have EH control flow semantics; examine 7245 'tree_can_throw_internal' or 'tree_can_throw_external' for exact 7246 semantics. Exact control flow may be extracted from 7247 'foreach_reachable_handler'. The EH region nesting tree is defined 7248 in 'except.h' and built in 'except.c'. The lowering pass itself is 7249 in 'tree-eh.c' and is described by 'pass_lower_eh'. 7250 7251 * Build the control flow graph 7252 7253 This pass decomposes a function into basic blocks and creates all 7254 of the edges that connect them. It is located in 'tree-cfg.c' and 7255 is described by 'pass_build_cfg'. 7256 7257 * Find all referenced variables 7258 7259 This pass walks the entire function and collects an array of all 7260 variables referenced in the function, 'referenced_vars'. The index 7261 at which a variable is found in the array is used as a UID for the 7262 variable within this function. This data is needed by the SSA 7263 rewriting routines. The pass is located in 'tree-dfa.c' and is 7264 described by 'pass_referenced_vars'. 7265 7266 * Enter static single assignment form 7267 7268 This pass rewrites the function such that it is in SSA form. After 7269 this pass, all 'is_gimple_reg' variables will be referenced by 7270 'SSA_NAME', and all occurrences of other variables will be 7271 annotated with 'VDEFS' and 'VUSES'; PHI nodes will have been 7272 inserted as necessary for each basic block. This pass is located 7273 in 'tree-ssa.c' and is described by 'pass_build_ssa'. 7274 7275 * Warn for uninitialized variables 7276 7277 This pass scans the function for uses of 'SSA_NAME's that are fed 7278 by default definition. For non-parameter variables, such uses are 7279 uninitialized. The pass is run twice, before and after 7280 optimization (if turned on). In the first pass we only warn for 7281 uses that are positively uninitialized; in the second pass we warn 7282 for uses that are possibly uninitialized. The pass is located in 7283 'tree-ssa.c' and is defined by 'pass_early_warn_uninitialized' and 7284 'pass_late_warn_uninitialized'. 7285 7286 * Dead code elimination 7287 7288 This pass scans the function for statements without side effects 7289 whose result is unused. It does not do memory life analysis, so 7290 any value that is stored in memory is considered used. The pass is 7291 run multiple times throughout the optimization process. It is 7292 located in 'tree-ssa-dce.c' and is described by 'pass_dce'. 7293 7294 * Dominator optimizations 7295 7296 This pass performs trivial dominator-based copy and constant 7297 propagation, expression simplification, and jump threading. It is 7298 run multiple times throughout the optimization process. It is 7299 located in 'tree-ssa-dom.c' and is described by 'pass_dominator'. 7300 7301 * Forward propagation of single-use variables 7302 7303 This pass attempts to remove redundant computation by substituting 7304 variables that are used once into the expression that uses them and 7305 seeing if the result can be simplified. It is located in 7306 'tree-ssa-forwprop.c' and is described by 'pass_forwprop'. 7307 7308 * Copy Renaming 7309 7310 This pass attempts to change the name of compiler temporaries 7311 involved in copy operations such that SSA->normal can coalesce the 7312 copy away. When compiler temporaries are copies of user variables, 7313 it also renames the compiler temporary to the user variable 7314 resulting in better use of user symbols. It is located in 7315 'tree-ssa-copyrename.c' and is described by 'pass_copyrename'. 7316 7317 * PHI node optimizations 7318 7319 This pass recognizes forms of PHI inputs that can be represented as 7320 conditional expressions and rewrites them into straight line code. 7321 It is located in 'tree-ssa-phiopt.c' and is described by 7322 'pass_phiopt'. 7323 7324 * May-alias optimization 7325 7326 This pass performs a flow sensitive SSA-based points-to analysis. 7327 The resulting may-alias, must-alias, and escape analysis 7328 information is used to promote variables from in-memory addressable 7329 objects to non-aliased variables that can be renamed into SSA form. 7330 We also update the 'VDEF'/'VUSE' memory tags for non-renameable 7331 aggregates so that we get fewer false kills. The pass is located 7332 in 'tree-ssa-alias.c' and is described by 'pass_may_alias'. 7333 7334 Interprocedural points-to information is located in 7335 'tree-ssa-structalias.c' and described by 'pass_ipa_pta'. 7336 7337 * Profiling 7338 7339 This pass instruments the function in order to collect runtime 7340 block and value profiling data. Such data may be fed back into the 7341 compiler on a subsequent run so as to allow optimization based on 7342 expected execution frequencies. The pass is located in 7343 'tree-profile.c' and is described by 'pass_ipa_tree_profile'. 7344 7345 * Static profile estimation 7346 7347 This pass implements series of heuristics to guess propababilities 7348 of branches. The resulting predictions are turned into edge 7349 profile by propagating branches across the control flow graphs. 7350 The pass is located in 'tree-profile.c' and is described by 7351 'pass_profile'. 7352 7353 * Lower complex arithmetic 7354 7355 This pass rewrites complex arithmetic operations into their 7356 component scalar arithmetic operations. The pass is located in 7357 'tree-complex.c' and is described by 'pass_lower_complex'. 7358 7359 * Scalar replacement of aggregates 7360 7361 This pass rewrites suitable non-aliased local aggregate variables 7362 into a set of scalar variables. The resulting scalar variables are 7363 rewritten into SSA form, which allows subsequent optimization 7364 passes to do a significantly better job with them. The pass is 7365 located in 'tree-sra.c' and is described by 'pass_sra'. 7366 7367 * Dead store elimination 7368 7369 This pass eliminates stores to memory that are subsequently 7370 overwritten by another store, without any intervening loads. The 7371 pass is located in 'tree-ssa-dse.c' and is described by 'pass_dse'. 7372 7373 * Tail recursion elimination 7374 7375 This pass transforms tail recursion into a loop. It is located in 7376 'tree-tailcall.c' and is described by 'pass_tail_recursion'. 7377 7378 * Forward store motion 7379 7380 This pass sinks stores and assignments down the flowgraph closer to 7381 their use point. The pass is located in 'tree-ssa-sink.c' and is 7382 described by 'pass_sink_code'. 7383 7384 * Partial redundancy elimination 7385 7386 This pass eliminates partially redundant computations, as well as 7387 performing load motion. The pass is located in 'tree-ssa-pre.c' 7388 and is described by 'pass_pre'. 7389 7390 Just before partial redundancy elimination, if 7391 '-funsafe-math-optimizations' is on, GCC tries to convert divisions 7392 to multiplications by the reciprocal. The pass is located in 7393 'tree-ssa-math-opts.c' and is described by 'pass_cse_reciprocal'. 7394 7395 * Full redundancy elimination 7396 7397 This is a simpler form of PRE that only eliminates redundancies 7398 that occur on all paths. It is located in 'tree-ssa-pre.c' and 7399 described by 'pass_fre'. 7400 7401 * Loop optimization 7402 7403 The main driver of the pass is placed in 'tree-ssa-loop.c' and 7404 described by 'pass_loop'. 7405 7406 The optimizations performed by this pass are: 7407 7408 Loop invariant motion. This pass moves only invariants that would 7409 be hard to handle on RTL level (function calls, operations that 7410 expand to nontrivial sequences of insns). With '-funswitch-loops' 7411 it also moves operands of conditions that are invariant out of the 7412 loop, so that we can use just trivial invariantness analysis in 7413 loop unswitching. The pass also includes store motion. The pass 7414 is implemented in 'tree-ssa-loop-im.c'. 7415 7416 Canonical induction variable creation. This pass creates a simple 7417 counter for number of iterations of the loop and replaces the exit 7418 condition of the loop using it, in case when a complicated analysis 7419 is necessary to determine the number of iterations. Later 7420 optimizations then may determine the number easily. The pass is 7421 implemented in 'tree-ssa-loop-ivcanon.c'. 7422 7423 Induction variable optimizations. This pass performs standard 7424 induction variable optimizations, including strength reduction, 7425 induction variable merging and induction variable elimination. The 7426 pass is implemented in 'tree-ssa-loop-ivopts.c'. 7427 7428 Loop unswitching. This pass moves the conditional jumps that are 7429 invariant out of the loops. To achieve this, a duplicate of the 7430 loop is created for each possible outcome of conditional jump(s). 7431 The pass is implemented in 'tree-ssa-loop-unswitch.c'. 7432 7433 Loop splitting. If a loop contains a conditional statement that is 7434 always true for one part of the iteration space and false for the 7435 other this pass splits the loop into two, one dealing with one side 7436 the other only with the other, thereby removing one inner-loop 7437 conditional. The pass is implemented in 'tree-ssa-loop-split.c'. 7438 7439 The optimizations also use various utility functions contained in 7440 'tree-ssa-loop-manip.c', 'cfgloop.c', 'cfgloopanal.c' and 7441 'cfgloopmanip.c'. 7442 7443 Vectorization. This pass transforms loops to operate on vector 7444 types instead of scalar types. Data parallelism across loop 7445 iterations is exploited to group data elements from consecutive 7446 iterations into a vector and operate on them in parallel. 7447 Depending on available target support the loop is conceptually 7448 unrolled by a factor 'VF' (vectorization factor), which is the 7449 number of elements operated upon in parallel in each iteration, and 7450 the 'VF' copies of each scalar operation are fused to form a vector 7451 operation. Additional loop transformations such as peeling and 7452 versioning may take place to align the number of iterations, and to 7453 align the memory accesses in the loop. The pass is implemented in 7454 'tree-vectorizer.c' (the main driver), 'tree-vect-loop.c' and 7455 'tree-vect-loop-manip.c' (loop specific parts and general loop 7456 utilities), 'tree-vect-slp' (loop-aware SLP functionality), 7457 'tree-vect-stmts.c' and 'tree-vect-data-refs.c'. Analysis of data 7458 references is in 'tree-data-ref.c'. 7459 7460 SLP Vectorization. This pass performs vectorization of 7461 straight-line code. The pass is implemented in 'tree-vectorizer.c' 7462 (the main driver), 'tree-vect-slp.c', 'tree-vect-stmts.c' and 7463 'tree-vect-data-refs.c'. 7464 7465 Autoparallelization. This pass splits the loop iteration space to 7466 run into several threads. The pass is implemented in 7467 'tree-parloops.c'. 7468 7469 Graphite is a loop transformation framework based on the polyhedral 7470 model. Graphite stands for Gimple Represented as Polyhedra. The 7471 internals of this infrastructure are documented in 7472 <http://gcc.gnu.org/wiki/Graphite>. The passes working on this 7473 representation are implemented in the various 'graphite-*' files. 7474 7475 * Tree level if-conversion for vectorizer 7476 7477 This pass applies if-conversion to simple loops to help vectorizer. 7478 We identify if convertible loops, if-convert statements and merge 7479 basic blocks in one big block. The idea is to present loop in such 7480 form so that vectorizer can have one to one mapping between 7481 statements and available vector operations. This pass is located 7482 in 'tree-if-conv.c' and is described by 'pass_if_conversion'. 7483 7484 * Conditional constant propagation 7485 7486 This pass relaxes a lattice of values in order to identify those 7487 that must be constant even in the presence of conditional branches. 7488 The pass is located in 'tree-ssa-ccp.c' and is described by 7489 'pass_ccp'. 7490 7491 A related pass that works on memory loads and stores, and not just 7492 register values, is located in 'tree-ssa-ccp.c' and described by 7493 'pass_store_ccp'. 7494 7495 * Conditional copy propagation 7496 7497 This is similar to constant propagation but the lattice of values 7498 is the "copy-of" relation. It eliminates redundant copies from the 7499 code. The pass is located in 'tree-ssa-copy.c' and described by 7500 'pass_copy_prop'. 7501 7502 A related pass that works on memory copies, and not just register 7503 copies, is located in 'tree-ssa-copy.c' and described by 7504 'pass_store_copy_prop'. 7505 7506 * Value range propagation 7507 7508 This transformation is similar to constant propagation but instead 7509 of propagating single constant values, it propagates known value 7510 ranges. The implementation is based on Patterson's range 7511 propagation algorithm (Accurate Static Branch Prediction by Value 7512 Range Propagation, J. R. C. Patterson, PLDI '95). In contrast to 7513 Patterson's algorithm, this implementation does not propagate 7514 branch probabilities nor it uses more than a single range per SSA 7515 name. This means that the current implementation cannot be used 7516 for branch prediction (though adapting it would not be difficult). 7517 The pass is located in 'tree-vrp.c' and is described by 'pass_vrp'. 7518 7519 * Folding built-in functions 7520 7521 This pass simplifies built-in functions, as applicable, with 7522 constant arguments or with inferable string lengths. It is located 7523 in 'tree-ssa-ccp.c' and is described by 'pass_fold_builtins'. 7524 7525 * Split critical edges 7526 7527 This pass identifies critical edges and inserts empty basic blocks 7528 such that the edge is no longer critical. The pass is located in 7529 'tree-cfg.c' and is described by 'pass_split_crit_edges'. 7530 7531 * Control dependence dead code elimination 7532 7533 This pass is a stronger form of dead code elimination that can 7534 eliminate unnecessary control flow statements. It is located in 7535 'tree-ssa-dce.c' and is described by 'pass_cd_dce'. 7536 7537 * Tail call elimination 7538 7539 This pass identifies function calls that may be rewritten into 7540 jumps. No code transformation is actually applied here, but the 7541 data and control flow problem is solved. The code transformation 7542 requires target support, and so is delayed until RTL. In the 7543 meantime 'CALL_EXPR_TAILCALL' is set indicating the possibility. 7544 The pass is located in 'tree-tailcall.c' and is described by 7545 'pass_tail_calls'. The RTL transformation is handled by 7546 'fixup_tail_calls' in 'calls.c'. 7547 7548 * Warn for function return without value 7549 7550 For non-void functions, this pass locates return statements that do 7551 not specify a value and issues a warning. Such a statement may 7552 have been injected by falling off the end of the function. This 7553 pass is run last so that we have as much time as possible to prove 7554 that the statement is not reachable. It is located in 'tree-cfg.c' 7555 and is described by 'pass_warn_function_return'. 7556 7557 * Leave static single assignment form 7558 7559 This pass rewrites the function such that it is in normal form. At 7560 the same time, we eliminate as many single-use temporaries as 7561 possible, so the intermediate language is no longer GIMPLE, but 7562 GENERIC. The pass is located in 'tree-outof-ssa.c' and is 7563 described by 'pass_del_ssa'. 7564 7565 * Merge PHI nodes that feed into one another 7566 7567 This is part of the CFG cleanup passes. It attempts to join PHI 7568 nodes from a forwarder CFG block into another block with PHI nodes. 7569 The pass is located in 'tree-cfgcleanup.c' and is described by 7570 'pass_merge_phi'. 7571 7572 * Return value optimization 7573 7574 If a function always returns the same local variable, and that 7575 local variable is an aggregate type, then the variable is replaced 7576 with the return value for the function (i.e., the function's 7577 DECL_RESULT). This is equivalent to the C++ named return value 7578 optimization applied to GIMPLE. The pass is located in 7579 'tree-nrv.c' and is described by 'pass_nrv'. 7580 7581 * Return slot optimization 7582 7583 If a function returns a memory object and is called as 'var = 7584 foo()', this pass tries to change the call so that the address of 7585 'var' is sent to the caller to avoid an extra memory copy. This 7586 pass is located in 'tree-nrv.c' and is described by 7587 'pass_return_slot'. 7588 7589 * Optimize calls to '__builtin_object_size' 7590 7591 This is a propagation pass similar to CCP that tries to remove 7592 calls to '__builtin_object_size' when the size of the object can be 7593 computed at compile-time. This pass is located in 7594 'tree-object-size.c' and is described by 'pass_object_sizes'. 7595 7596 * Loop invariant motion 7597 7598 This pass removes expensive loop-invariant computations out of 7599 loops. The pass is located in 'tree-ssa-loop.c' and described by 7600 'pass_lim'. 7601 7602 * Loop nest optimizations 7603 7604 This is a family of loop transformations that works on loop nests. 7605 It includes loop interchange, scaling, skewing and reversal and 7606 they are all geared to the optimization of data locality in array 7607 traversals and the removal of dependencies that hamper 7608 optimizations such as loop parallelization and vectorization. The 7609 pass is located in 'tree-loop-linear.c' and described by 7610 'pass_linear_transform'. 7611 7612 * Removal of empty loops 7613 7614 This pass removes loops with no code in them. The pass is located 7615 in 'tree-ssa-loop-ivcanon.c' and described by 'pass_empty_loop'. 7616 7617 * Unrolling of small loops 7618 7619 This pass completely unrolls loops with few iterations. The pass 7620 is located in 'tree-ssa-loop-ivcanon.c' and described by 7621 'pass_complete_unroll'. 7622 7623 * Predictive commoning 7624 7625 This pass makes the code reuse the computations from the previous 7626 iterations of the loops, especially loads and stores to memory. It 7627 does so by storing the values of these computations to a bank of 7628 temporary variables that are rotated at the end of loop. To avoid 7629 the need for this rotation, the loop is then unrolled and the 7630 copies of the loop body are rewritten to use the appropriate 7631 version of the temporary variable. This pass is located in 7632 'tree-predcom.c' and described by 'pass_predcom'. 7633 7634 * Array prefetching 7635 7636 This pass issues prefetch instructions for array references inside 7637 loops. The pass is located in 'tree-ssa-loop-prefetch.c' and 7638 described by 'pass_loop_prefetch'. 7639 7640 * Reassociation 7641 7642 This pass rewrites arithmetic expressions to enable optimizations 7643 that operate on them, like redundancy elimination and 7644 vectorization. The pass is located in 'tree-ssa-reassoc.c' and 7645 described by 'pass_reassoc'. 7646 7647 * Optimization of 'stdarg' functions 7648 7649 This pass tries to avoid the saving of register arguments into the 7650 stack on entry to 'stdarg' functions. If the function doesn't use 7651 any 'va_start' macros, no registers need to be saved. If 7652 'va_start' macros are used, the 'va_list' variables don't escape 7653 the function, it is only necessary to save registers that will be 7654 used in 'va_arg' macros. For instance, if 'va_arg' is only used 7655 with integral types in the function, floating point registers don't 7656 need to be saved. This pass is located in 'tree-stdarg.c' and 7657 described by 'pass_stdarg'. 7658 7659 7660File: gccint.info, Node: RTL passes, Next: Optimization info, Prev: Tree SSA passes, Up: Passes 7661 76629.5 RTL passes 7663============== 7664 7665The following briefly describes the RTL generation and optimization 7666passes that are run after the Tree optimization passes. 7667 7668 * RTL generation 7669 7670 The source files for RTL generation include 'stmt.c', 'calls.c', 7671 'expr.c', 'explow.c', 'expmed.c', 'function.c', 'optabs.c' and 7672 'emit-rtl.c'. Also, the file 'insn-emit.c', generated from the 7673 machine description by the program 'genemit', is used in this pass. 7674 The header file 'expr.h' is used for communication within this 7675 pass. 7676 7677 The header files 'insn-flags.h' and 'insn-codes.h', generated from 7678 the machine description by the programs 'genflags' and 'gencodes', 7679 tell this pass which standard names are available for use and which 7680 patterns correspond to them. 7681 7682 * Generation of exception landing pads 7683 7684 This pass generates the glue that handles communication between the 7685 exception handling library routines and the exception handlers 7686 within the function. Entry points in the function that are invoked 7687 by the exception handling library are called "landing pads". The 7688 code for this pass is located in 'except.c'. 7689 7690 * Control flow graph cleanup 7691 7692 This pass removes unreachable code, simplifies jumps to next, jumps 7693 to jump, jumps across jumps, etc. The pass is run multiple times. 7694 For historical reasons, it is occasionally referred to as the "jump 7695 optimization pass". The bulk of the code for this pass is in 7696 'cfgcleanup.c', and there are support routines in 'cfgrtl.c' and 7697 'jump.c'. 7698 7699 * Forward propagation of single-def values 7700 7701 This pass attempts to remove redundant computation by substituting 7702 variables that come from a single definition, and seeing if the 7703 result can be simplified. It performs copy propagation and 7704 addressing mode selection. The pass is run twice, with values 7705 being propagated into loops only on the second run. The code is 7706 located in 'fwprop.c'. 7707 7708 * Common subexpression elimination 7709 7710 This pass removes redundant computation within basic blocks, and 7711 optimizes addressing modes based on cost. The pass is run twice. 7712 The code for this pass is located in 'cse.c'. 7713 7714 * Global common subexpression elimination 7715 7716 This pass performs two different types of GCSE depending on whether 7717 you are optimizing for size or not (LCM based GCSE tends to 7718 increase code size for a gain in speed, while Morel-Renvoise based 7719 GCSE does not). When optimizing for size, GCSE is done using 7720 Morel-Renvoise Partial Redundancy Elimination, with the exception 7721 that it does not try to move invariants out of loops--that is left 7722 to the loop optimization pass. If MR PRE GCSE is done, code 7723 hoisting (aka unification) is also done, as well as load motion. 7724 If you are optimizing for speed, LCM (lazy code motion) based GCSE 7725 is done. LCM is based on the work of Knoop, Ruthing, and Steffen. 7726 LCM based GCSE also does loop invariant code motion. We also 7727 perform load and store motion when optimizing for speed. 7728 Regardless of which type of GCSE is used, the GCSE pass also 7729 performs global constant and copy propagation. The source file for 7730 this pass is 'gcse.c', and the LCM routines are in 'lcm.c'. 7731 7732 * Loop optimization 7733 7734 This pass performs several loop related optimizations. The source 7735 files 'cfgloopanal.c' and 'cfgloopmanip.c' contain generic loop 7736 analysis and manipulation code. Initialization and finalization of 7737 loop structures is handled by 'loop-init.c'. A loop invariant 7738 motion pass is implemented in 'loop-invariant.c'. Basic block 7739 level optimizations--unrolling, and peeling loops-- are implemented 7740 in 'loop-unroll.c'. Replacing of the exit condition of loops by 7741 special machine-dependent instructions is handled by 7742 'loop-doloop.c'. 7743 7744 * Jump bypassing 7745 7746 This pass is an aggressive form of GCSE that transforms the control 7747 flow graph of a function by propagating constants into conditional 7748 branch instructions. The source file for this pass is 'gcse.c'. 7749 7750 * If conversion 7751 7752 This pass attempts to replace conditional branches and surrounding 7753 assignments with arithmetic, boolean value producing comparison 7754 instructions, and conditional move instructions. In the very last 7755 invocation after reload/LRA, it will generate predicated 7756 instructions when supported by the target. The code is located in 7757 'ifcvt.c'. 7758 7759 * Web construction 7760 7761 This pass splits independent uses of each pseudo-register. This 7762 can improve effect of the other transformation, such as CSE or 7763 register allocation. The code for this pass is located in 'web.c'. 7764 7765 * Instruction combination 7766 7767 This pass attempts to combine groups of two or three instructions 7768 that are related by data flow into single instructions. It 7769 combines the RTL expressions for the instructions by substitution, 7770 simplifies the result using algebra, and then attempts to match the 7771 result against the machine description. The code is located in 7772 'combine.c'. 7773 7774 * Mode switching optimization 7775 7776 This pass looks for instructions that require the processor to be 7777 in a specific "mode" and minimizes the number of mode changes 7778 required to satisfy all users. What these modes are, and what they 7779 apply to are completely target-specific. The code for this pass is 7780 located in 'mode-switching.c'. 7781 7782 * Modulo scheduling 7783 7784 This pass looks at innermost loops and reorders their instructions 7785 by overlapping different iterations. Modulo scheduling is 7786 performed immediately before instruction scheduling. The code for 7787 this pass is located in 'modulo-sched.c'. 7788 7789 * Instruction scheduling 7790 7791 This pass looks for instructions whose output will not be available 7792 by the time that it is used in subsequent instructions. Memory 7793 loads and floating point instructions often have this behavior on 7794 RISC machines. It re-orders instructions within a basic block to 7795 try to separate the definition and use of items that otherwise 7796 would cause pipeline stalls. This pass is performed twice, before 7797 and after register allocation. The code for this pass is located 7798 in 'haifa-sched.c', 'sched-deps.c', 'sched-ebb.c', 'sched-rgn.c' 7799 and 'sched-vis.c'. 7800 7801 * Register allocation 7802 7803 These passes make sure that all occurrences of pseudo registers are 7804 eliminated, either by allocating them to a hard register, replacing 7805 them by an equivalent expression (e.g. a constant) or by placing 7806 them on the stack. This is done in several subpasses: 7807 7808 * The integrated register allocator (IRA). It is called 7809 integrated because coalescing, register live range splitting, 7810 and hard register preferencing are done on-the-fly during 7811 coloring. It also has better integration with the reload/LRA 7812 pass. Pseudo-registers spilled by the allocator or the 7813 reload/LRA have still a chance to get hard-registers if the 7814 reload/LRA evicts some pseudo-registers from hard-registers. 7815 The allocator helps to choose better pseudos for spilling 7816 based on their live ranges and to coalesce stack slots 7817 allocated for the spilled pseudo-registers. IRA is a regional 7818 register allocator which is transformed into Chaitin-Briggs 7819 allocator if there is one region. By default, IRA chooses 7820 regions using register pressure but the user can force it to 7821 use one region or regions corresponding to all loops. 7822 7823 Source files of the allocator are 'ira.c', 'ira-build.c', 7824 'ira-costs.c', 'ira-conflicts.c', 'ira-color.c', 'ira-emit.c', 7825 'ira-lives', plus header files 'ira.h' and 'ira-int.h' used 7826 for the communication between the allocator and the rest of 7827 the compiler and between the IRA files. 7828 7829 * Reloading. This pass renumbers pseudo registers with the 7830 hardware registers numbers they were allocated. Pseudo 7831 registers that did not get hard registers are replaced with 7832 stack slots. Then it finds instructions that are invalid 7833 because a value has failed to end up in a register, or has 7834 ended up in a register of the wrong kind. It fixes up these 7835 instructions by reloading the problematical values temporarily 7836 into registers. Additional instructions are generated to do 7837 the copying. 7838 7839 The reload pass also optionally eliminates the frame pointer 7840 and inserts instructions to save and restore call-clobbered 7841 registers around calls. 7842 7843 Source files are 'reload.c' and 'reload1.c', plus the header 7844 'reload.h' used for communication between them. 7845 7846 * This pass is a modern replacement of the reload pass. Source 7847 files are 'lra.c', 'lra-assign.c', 'lra-coalesce.c', 7848 'lra-constraints.c', 'lra-eliminations.c', 'lra-lives.c', 7849 'lra-remat.c', 'lra-spills.c', the header 'lra-int.h' used for 7850 communication between them, and the header 'lra.h' used for 7851 communication between LRA and the rest of compiler. 7852 7853 Unlike the reload pass, intermediate LRA decisions are 7854 reflected in RTL as much as possible. This reduces the number 7855 of target-dependent macros and hooks, leaving instruction 7856 constraints as the primary source of control. 7857 7858 LRA is run on targets for which TARGET_LRA_P returns true. 7859 7860 * Basic block reordering 7861 7862 This pass implements profile guided code positioning. If profile 7863 information is not available, various types of static analysis are 7864 performed to make the predictions normally coming from the profile 7865 feedback (IE execution frequency, branch probability, etc). It is 7866 implemented in the file 'bb-reorder.c', and the various prediction 7867 routines are in 'predict.c'. 7868 7869 * Variable tracking 7870 7871 This pass computes where the variables are stored at each position 7872 in code and generates notes describing the variable locations to 7873 RTL code. The location lists are then generated according to these 7874 notes to debug information if the debugging information format 7875 supports location lists. The code is located in 'var-tracking.c'. 7876 7877 * Delayed branch scheduling 7878 7879 This optional pass attempts to find instructions that can go into 7880 the delay slots of other instructions, usually jumps and calls. 7881 The code for this pass is located in 'reorg.c'. 7882 7883 * Branch shortening 7884 7885 On many RISC machines, branch instructions have a limited range. 7886 Thus, longer sequences of instructions must be used for long 7887 branches. In this pass, the compiler figures out what how far each 7888 instruction will be from each other instruction, and therefore 7889 whether the usual instructions, or the longer sequences, must be 7890 used for each branch. The code for this pass is located in 7891 'final.c'. 7892 7893 * Register-to-stack conversion 7894 7895 Conversion from usage of some hard registers to usage of a register 7896 stack may be done at this point. Currently, this is supported only 7897 for the floating-point registers of the Intel 80387 coprocessor. 7898 The code for this pass is located in 'reg-stack.c'. 7899 7900 * Final 7901 7902 This pass outputs the assembler code for the function. The source 7903 files are 'final.c' plus 'insn-output.c'; the latter is generated 7904 automatically from the machine description by the tool 'genoutput'. 7905 The header file 'conditions.h' is used for communication between 7906 these files. 7907 7908 * Debugging information output 7909 7910 This is run after final because it must output the stack slot 7911 offsets for pseudo registers that did not get hard registers. 7912 Source files are 'dbxout.c' for DBX symbol table format, 7913 'dwarfout.c' for DWARF symbol table format, files 'dwarf2out.c' and 7914 'dwarf2asm.c' for DWARF2 symbol table format, and 'vmsdbgout.c' for 7915 VMS debug symbol table format. 7916 7917 7918File: gccint.info, Node: Optimization info, Prev: RTL passes, Up: Passes 7919 79209.6 Optimization info 7921===================== 7922 7923This section is describes dump infrastructure which is common to both 7924pass dumps as well as optimization dumps. The goal for this 7925infrastructure is to provide both gcc developers and users detailed 7926information about various compiler transformations and optimizations. 7927 7928* Menu: 7929 7930* Dump setup:: Setup of optimization dumps. 7931* Optimization groups:: Groups made up of optimization passes. 7932* Dump files and streams:: Dump output file names and streams. 7933* Dump output verbosity:: How much information to dump. 7934* Dump types:: Various types of dump functions. 7935* Dump examples:: Sample usage. 7936 7937 7938File: gccint.info, Node: Dump setup, Next: Optimization groups, Up: Optimization info 7939 79409.6.1 Dump setup 7941---------------- 7942 7943A dump_manager class is defined in 'dumpfile.h'. Various passes 7944register dumping pass-specific information via 'dump_register' in 7945'passes.c'. During the registration, an optimization pass can select 7946its optimization group (*note Optimization groups::). After that 7947optimization information corresponding to the entire group (presumably 7948from multiple passes) can be output via command-line switches. Note 7949that if a pass does not fit into any of the pre-defined groups, it can 7950select 'OPTGROUP_NONE'. 7951 7952 Note that in general, a pass need not know its dump output file name, 7953whether certain flags are enabled, etc. However, for legacy reasons, 7954passes could also call 'dump_begin' which returns a stream in case the 7955particular pass has optimization dumps enabled. A pass could call 7956'dump_end' when the dump has ended. These methods should go away once 7957all the passes are converted to use the new dump infrastructure. 7958 7959 The recommended way to setup the dump output is via 'dump_start' and 7960'dump_end'. 7961 7962 7963File: gccint.info, Node: Optimization groups, Next: Dump files and streams, Prev: Dump setup, Up: Optimization info 7964 79659.6.2 Optimization groups 7966------------------------- 7967 7968The optimization passes are grouped into several categories. Currently 7969defined categories in 'dumpfile.h' are 7970 7971'OPTGROUP_IPA' 7972 IPA optimization passes. Enabled by '-ipa' 7973 7974'OPTGROUP_LOOP' 7975 Loop optimization passes. Enabled by '-loop'. 7976 7977'OPTGROUP_INLINE' 7978 Inlining passes. Enabled by '-inline'. 7979 7980'OPTGROUP_OMP' 7981 OMP (Offloading and Multi Processing) passes. Enabled by '-omp'. 7982 7983'OPTGROUP_VEC' 7984 Vectorization passes. Enabled by '-vec'. 7985 7986'OPTGROUP_OTHER' 7987 All other optimization passes which do not fall into one of the 7988 above. 7989 7990'OPTGROUP_ALL' 7991 All optimization passes. Enabled by '-optall'. 7992 7993 By using groups a user could selectively enable optimization 7994information only for a group of passes. By default, the optimization 7995information for all the passes is dumped. 7996 7997 7998File: gccint.info, Node: Dump files and streams, Next: Dump output verbosity, Prev: Optimization groups, Up: Optimization info 7999 80009.6.3 Dump files and streams 8001---------------------------- 8002 8003There are two separate output streams available for outputting 8004optimization information from passes. Note that both these streams 8005accept 'stderr' and 'stdout' as valid streams and thus it is possible to 8006dump output to standard output or error. This is specially handy for 8007outputting all available information in a single file by redirecting 8008'stderr'. 8009 8010'pstream' 8011 This stream is for pass-specific dump output. For example, 8012 '-fdump-tree-vect=foo.v' dumps tree vectorization pass output into 8013 the given file name 'foo.v'. If the file name is not provided, the 8014 default file name is based on the source file and pass number. 8015 Note that one could also use special file names 'stdout' and 8016 'stderr' for dumping to standard output and standard error 8017 respectively. 8018 8019'alt_stream' 8020 This steam is used for printing optimization specific output in 8021 response to the '-fopt-info'. Again a file name can be given. If 8022 the file name is not given, it defaults to 'stderr'. 8023 8024 8025File: gccint.info, Node: Dump output verbosity, Next: Dump types, Prev: Dump files and streams, Up: Optimization info 8026 80279.6.4 Dump output verbosity 8028--------------------------- 8029 8030The dump verbosity has the following options 8031 8032'optimized' 8033 Print information when an optimization is successfully applied. It 8034 is up to a pass to decide which information is relevant. For 8035 example, the vectorizer passes print the source location of loops 8036 which got successfully vectorized. 8037 8038'missed' 8039 Print information about missed optimizations. Individual passes 8040 control which information to include in the output. For example, 8041 8042 gcc -O2 -ftree-vectorize -fopt-info-vec-missed 8043 8044 will print information about missed optimization opportunities from 8045 vectorization passes on stderr. 8046 8047'note' 8048 Print verbose information about optimizations, such as certain 8049 transformations, more detailed messages about decisions etc. 8050 8051'all' 8052 Print detailed optimization information. This includes OPTIMIZED, 8053 MISSED, and NOTE. 8054 8055 8056File: gccint.info, Node: Dump types, Next: Dump examples, Prev: Dump output verbosity, Up: Optimization info 8057 80589.6.5 Dump types 8059---------------- 8060 8061'dump_printf' 8062 8063 This is a generic method for doing formatted output. It takes an 8064 additional argument 'dump_kind' which signifies the type of dump. 8065 This method outputs information only when the dumps are enabled for 8066 this particular 'dump_kind'. Note that the caller doesn't need to 8067 know if the particular dump is enabled or not, or even the file 8068 name. The caller only needs to decide which dump output 8069 information is relevant, and under what conditions. This 8070 determines the associated flags. 8071 8072 Consider the following example from 'loop-unroll.c' where an 8073 informative message about a loop (along with its location) is 8074 printed when any of the following flags is enabled 8075 8076 - optimization messages 8077 - RTL dumps 8078 - detailed dumps 8079 8080 int report_flags = MSG_OPTIMIZED_LOCATIONS | TDF_RTL | TDF_DETAILS; 8081 dump_printf_loc (report_flags, insn, 8082 "loop turned into non-loop; it never loops.\n"); 8083 8084'dump_basic_block' 8085 Output basic block. 8086'dump_generic_expr' 8087 Output generic expression. 8088'dump_gimple_stmt' 8089 Output gimple statement. 8090 8091 Note that the above methods also have variants prefixed with 8092 '_loc', such as 'dump_printf_loc', which are similar except they 8093 also output the source location information. The '_loc' variants 8094 take a 'const dump_location_t &'. This class can be constructed 8095 from a 'gimple *' or from a 'rtx_insn *', and so callers can pass a 8096 'gimple *' or a 'rtx_insn *' as the '_loc' argument. The 8097 'dump_location_t' constructor will extract the source location from 8098 the statement or instruction, along with the profile count, and the 8099 location in GCC's own source code (or the plugin) from which the 8100 dump call was emitted. Only the source location is currently used. 8101 There is also a 'dump_user_location_t' class, capturing the source 8102 location and profile count, but not the dump emission location, so 8103 that locations in the user's code can be passed around. This can 8104 also be constructed from a 'gimple *' and from a 'rtx_insn *', and 8105 it too can be passed as the '_loc' argument. 8106 8107 8108File: gccint.info, Node: Dump examples, Prev: Dump types, Up: Optimization info 8109 81109.6.6 Dump examples 8111------------------- 8112 8113 gcc -O3 -fopt-info-missed=missed.all 8114 8115 outputs missed optimization report from all the passes into 8116'missed.all'. 8117 8118 As another example, 8119 gcc -O3 -fopt-info-inline-optimized-missed=inline.txt 8120 8121 will output information about missed optimizations as well as optimized 8122locations from all the inlining passes into 'inline.txt'. 8123 8124 If the FILENAME is provided, then the dumps from all the applicable 8125optimizations are concatenated into the 'filename'. Otherwise the dump 8126is output onto 'stderr'. If OPTIONS is omitted, it defaults to 8127'optimized-optall', which means dump all information about successful 8128optimizations from all the passes. In the following example, the 8129optimization information is output on to 'stderr'. 8130 8131 gcc -O3 -fopt-info 8132 8133 Note that '-fopt-info-vec-missed' behaves the same as 8134'-fopt-info-missed-vec'. The order of the optimization group names and 8135message types listed after '-fopt-info' does not matter. 8136 8137 As another example, consider 8138 8139 gcc -fopt-info-vec-missed=vec.miss -fopt-info-loop-optimized=loop.opt 8140 8141 Here the two output file names 'vec.miss' and 'loop.opt' are in 8142conflict since only one output file is allowed. In this case, only the 8143first option takes effect and the subsequent options are ignored. Thus 8144only the 'vec.miss' is produced which containts dumps from the 8145vectorizer about missed opportunities. 8146 8147 8148File: gccint.info, Node: poly_int, Next: GENERIC, Prev: Passes, Up: Top 8149 815010 Sizes and offsets as runtime invariants 8151****************************************** 8152 8153GCC allows the size of a hardware register to be a runtime invariant 8154rather than a compile-time constant. This in turn means that various 8155sizes and offsets must also be runtime invariants rather than 8156compile-time constants, such as: 8157 8158 * the size of a general 'machine_mode' (*note Machine Modes::); 8159 8160 * the size of a spill slot; 8161 8162 * the offset of something within a stack frame; 8163 8164 * the number of elements in a vector; 8165 8166 * the size and offset of a 'mem' rtx (*note Regs and Memory::); and 8167 8168 * the byte offset in a 'subreg' rtx (*note Regs and Memory::). 8169 8170 The motivating example is the Arm SVE ISA, whose vector registers can 8171be any multiple of 128 bits between 128 and 2048 inclusive. The 8172compiler normally produces code that works for all SVE register sizes, 8173with the actual size only being known at runtime. 8174 8175 GCC's main representation of such runtime invariants is the 'poly_int' 8176class. This chapter describes what 'poly_int' does, lists the available 8177operations, and gives some general usage guidelines. 8178 8179* Menu: 8180 8181* Overview of poly_int:: 8182* Consequences of using poly_int:: 8183* Comparisons involving poly_int:: 8184* Arithmetic on poly_ints:: 8185* Alignment of poly_ints:: 8186* Computing bounds on poly_ints:: 8187* Converting poly_ints:: 8188* Miscellaneous poly_int routines:: 8189* Guidelines for using poly_int:: 8190 8191 8192File: gccint.info, Node: Overview of poly_int, Next: Consequences of using poly_int, Up: poly_int 8193 819410.1 Overview of 'poly_int' 8195=========================== 8196 8197We define indeterminates X1, ..., XN whose values are only known at 8198runtime and use polynomials of the form: 8199 8200 C0 + C1 * X1 + ... + CN * XN 8201 8202 to represent a size or offset whose value might depend on some of these 8203indeterminates. The coefficients C0, ..., CN are always known at 8204compile time, with the C0 term being the "constant" part that does not 8205depend on any runtime value. 8206 8207 GCC uses the 'poly_int' class to represent these coefficients. The 8208class has two template parameters: the first specifies the number of 8209coefficients (N + 1) and the second specifies the type of the 8210coefficients. For example, 'poly_int<2, unsigned short>' represents a 8211polynomial with two coefficients (and thus one indeterminate), with each 8212coefficient having type 'unsigned short'. When N is 0, the class 8213degenerates to a single compile-time constant C0. 8214 8215 The number of coefficients needed for compilation is a fixed property 8216of each target and is specified by the configuration macro 8217'NUM_POLY_INT_COEFFS'. The default value is 1, since most targets do 8218not have such runtime invariants. Targets that need a different value 8219should '#define' the macro in their 'CPU-modes.def' file. *Note Back 8220End::. 8221 8222 'poly_int' makes the simplifying requirement that each indeterminate 8223must be a nonnegative integer. An indeterminate value of 0 should 8224usually represent the minimum possible runtime value, with C0 specifying 8225the value in that case. 8226 8227 For example, when targetting the Arm SVE ISA, the single indeterminate 8228represents the number of 128-bit blocks in a vector _beyond the minimum 8229length of 128 bits_. Thus the number of 64-bit doublewords in a vector 8230is 2 + 2 * X1. If an aggregate has a single SVE vector and 16 8231additional bytes, its total size is 32 + 16 * X1 bytes. 8232 8233 The header file 'poly-int-types.h' provides typedefs for the most 8234common forms of 'poly_int', all having 'NUM_POLY_INT_COEFFS' 8235coefficients: 8236 8237'poly_uint16' 8238 a 'poly_int' with 'unsigned short' coefficients. 8239 8240'poly_int64' 8241 a 'poly_int' with 'HOST_WIDE_INT' coefficients. 8242 8243'poly_uint64' 8244 a 'poly_int' with 'unsigned HOST_WIDE_INT' coefficients. 8245 8246'poly_offset_int' 8247 a 'poly_int' with 'offset_int' coefficients. 8248 8249'poly_wide_int' 8250 a 'poly_int' with 'wide_int' coefficients. 8251 8252'poly_widest_int' 8253 a 'poly_int' with 'widest_int' coefficients. 8254 8255 Since the main purpose of 'poly_int' is to represent sizes and offsets, 8256the last two typedefs are only rarely used. 8257 8258 8259File: gccint.info, Node: Consequences of using poly_int, Next: Comparisons involving poly_int, Prev: Overview of poly_int, Up: poly_int 8260 826110.2 Consequences of using 'poly_int' 8262===================================== 8263 8264The two main consequences of using polynomial sizes and offsets are 8265that: 8266 8267 * there is no total ordering between the values at compile time, and 8268 8269 * some operations might yield results that cannot be expressed as a 8270 'poly_int'. 8271 8272 For example, if X is a runtime invariant, we cannot tell at compile 8273time whether: 8274 8275 3 + 4X <= 1 + 5X 8276 8277 since the condition is false when X <= 1 and true when X >= 2. 8278 8279 Similarly, 'poly_int' cannot represent the result of: 8280 8281 (3 + 4X) * (1 + 5X) 8282 8283 since it cannot (and in practice does not need to) store powers greater 8284than one. It also cannot represent the result of: 8285 8286 (3 + 4X) / (1 + 5X) 8287 8288 The following sections describe how we deal with these restrictions. 8289 8290 As described earlier, a 'poly_int<1, T>' has no indeterminates and so 8291degenerates to a compile-time constant of type T. It would be possible 8292in that case to do all normal arithmetic on the T, and to compare the T 8293using the normal C++ operators. We deliberately prevent 8294target-independent code from doing this, since the compiler needs to 8295support other 'poly_int<N, T>' as well, regardless of the current 8296target's 'NUM_POLY_INT_COEFFS'. 8297 8298 However, it would be very artificial to force target-specific code to 8299follow these restrictions if the target has no runtime indeterminates. 8300There is therefore an implicit conversion from 'poly_int<1, T>' to T 8301when compiling target-specific translation units. 8302 8303 8304File: gccint.info, Node: Comparisons involving poly_int, Next: Arithmetic on poly_ints, Prev: Consequences of using poly_int, Up: poly_int 8305 830610.3 Comparisons involving 'poly_int' 8307===================================== 8308 8309In general we need to compare sizes and offsets in two situations: those 8310in which the values need to be ordered, and those in which the values 8311can be unordered. More loosely, the distinction is often between values 8312that have a definite link (usually because they refer to the same 8313underlying register or memory location) and values that have no definite 8314link. An example of the former is the relationship between the inner 8315and outer sizes of a subreg, where we must know at compile time whether 8316the subreg is paradoxical, partial, or complete. An example of the 8317latter is alias analysis: we might want to check whether two arbitrary 8318memory references overlap. 8319 8320 Referring back to the examples in the previous section, it makes sense 8321to ask whether a memory reference of size '3 + 4X' overlaps one of size 8322'1 + 5X', but it does not make sense to have a subreg in which the outer 8323mode has '3 + 4X' bytes and the inner mode has '1 + 5X' bytes (or vice 8324versa). Such subregs are always invalid and should trigger an internal 8325compiler error if formed. 8326 8327 The underlying operators are the same in both cases, but the 8328distinction affects how they are used. 8329 8330* Menu: 8331 8332* Comparison functions for poly_int:: 8333* Properties of the poly_int comparisons:: 8334* Comparing potentially-unordered poly_ints:: 8335* Comparing ordered poly_ints:: 8336* Checking for a poly_int marker value:: 8337* Range checks on poly_ints:: 8338* Sorting poly_ints:: 8339 8340 8341File: gccint.info, Node: Comparison functions for poly_int, Next: Properties of the poly_int comparisons, Up: Comparisons involving poly_int 8342 834310.3.1 Comparison functions for 'poly_int' 8344------------------------------------------ 8345 8346'poly_int' provides the following routines for checking whether a 8347particular condition "may be" (might be) true: 8348 8349 maybe_lt maybe_le maybe_eq maybe_ge maybe_gt 8350 maybe_ne 8351 8352 The functions have their natural meaning: 8353 8354'maybe_lt(A, B)' 8355 Return true if A might be less than B. 8356 8357'maybe_le(A, B)' 8358 Return true if A might be less than or equal to B. 8359 8360'maybe_eq(A, B)' 8361 Return true if A might be equal to B. 8362 8363'maybe_ne(A, B)' 8364 Return true if A might not be equal to B. 8365 8366'maybe_ge(A, B)' 8367 Return true if A might be greater than or equal to B. 8368 8369'maybe_gt(A, B)' 8370 Return true if A might be greater than B. 8371 8372 For readability, 'poly_int' also provides "known" inverses of these 8373functions: 8374 8375 known_lt (A, B) == !maybe_ge (A, B) 8376 known_le (A, B) == !maybe_gt (A, B) 8377 known_eq (A, B) == !maybe_ne (A, B) 8378 known_ge (A, B) == !maybe_lt (A, B) 8379 known_gt (A, B) == !maybe_le (A, B) 8380 known_ne (A, B) == !maybe_eq (A, B) 8381 8382 8383File: gccint.info, Node: Properties of the poly_int comparisons, Next: Comparing potentially-unordered poly_ints, Prev: Comparison functions for poly_int, Up: Comparisons involving poly_int 8384 838510.3.2 Properties of the 'poly_int' comparisons 8386----------------------------------------------- 8387 8388All "maybe" relations except 'maybe_ne' are transitive, so for example: 8389 8390 maybe_lt (A, B) && maybe_lt (B, C) implies maybe_lt (A, C) 8391 8392 for all A, B and C. 'maybe_lt', 'maybe_gt' and 'maybe_ne' are 8393irreflexive, so for example: 8394 8395 !maybe_lt (A, A) 8396 8397 is true for all A. 'maybe_le', 'maybe_eq' and 'maybe_ge' are 8398reflexive, so for example: 8399 8400 maybe_le (A, A) 8401 8402 is true for all A. 'maybe_eq' and 'maybe_ne' are symmetric, so: 8403 8404 maybe_eq (A, B) == maybe_eq (B, A) 8405 maybe_ne (A, B) == maybe_ne (B, A) 8406 8407 for all A and B. In addition: 8408 8409 maybe_le (A, B) == maybe_lt (A, B) || maybe_eq (A, B) 8410 maybe_ge (A, B) == maybe_gt (A, B) || maybe_eq (A, B) 8411 maybe_lt (A, B) == maybe_gt (B, A) 8412 maybe_le (A, B) == maybe_ge (B, A) 8413 8414 However: 8415 8416 maybe_le (A, B) && maybe_le (B, A) does not imply !maybe_ne (A, B) [== known_eq (A, B)] 8417 maybe_ge (A, B) && maybe_ge (B, A) does not imply !maybe_ne (A, B) [== known_eq (A, B)] 8418 8419 One example is again 'A == 3 + 4X' and 'B == 1 + 5X', where 'maybe_le 8420(A, B)', 'maybe_ge (A, B)' and 'maybe_ne (A, B)' all hold. 'maybe_le' 8421and 'maybe_ge' are therefore not antisymetric and do not form a partial 8422order. 8423 8424 From the above, it follows that: 8425 8426 * All "known" relations except 'known_ne' are transitive. 8427 8428 * 'known_lt', 'known_ne' and 'known_gt' are irreflexive. 8429 8430 * 'known_le', 'known_eq' and 'known_ge' are reflexive. 8431 8432 Also: 8433 8434 known_lt (A, B) == known_gt (B, A) 8435 known_le (A, B) == known_ge (B, A) 8436 known_lt (A, B) implies !known_lt (B, A) [asymmetry] 8437 known_gt (A, B) implies !known_gt (B, A) 8438 known_le (A, B) && known_le (B, A) == known_eq (A, B) [== !maybe_ne (A, B)] 8439 known_ge (A, B) && known_ge (B, A) == known_eq (A, B) [== !maybe_ne (A, B)] 8440 8441 'known_le' and 'known_ge' are therefore antisymmetric and are partial 8442orders. However: 8443 8444 known_le (A, B) does not imply known_lt (A, B) || known_eq (A, B) 8445 known_ge (A, B) does not imply known_gt (A, B) || known_eq (A, B) 8446 8447 For example, 'known_le (4, 4 + 4X)' holds because the runtime 8448indeterminate X is a nonnegative integer, but neither 'known_lt (4, 4 + 84494X)' nor 'known_eq (4, 4 + 4X)' hold. 8450 8451 8452File: gccint.info, Node: Comparing potentially-unordered poly_ints, Next: Comparing ordered poly_ints, Prev: Properties of the poly_int comparisons, Up: Comparisons involving poly_int 8453 845410.3.3 Comparing potentially-unordered 'poly_int's 8455-------------------------------------------------- 8456 8457In cases where there is no definite link between two 'poly_int's, we can 8458usually make a conservatively-correct assumption. For example, the 8459conservative assumption for alias analysis is that two references 8460_might_ alias. 8461 8462 One way of checking whether [BEGIN1, END1) might overlap [BEGIN2, END2) 8463using the 'poly_int' comparisons is: 8464 8465 maybe_gt (END1, BEGIN2) && maybe_gt (END2, BEGIN1) 8466 8467 and another (equivalent) way is: 8468 8469 !(known_le (END1, BEGIN2) || known_le (END2, BEGIN1)) 8470 8471 However, in this particular example, it is better to use the range 8472helper functions instead. *Note Range checks on poly_ints::. 8473 8474 8475File: gccint.info, Node: Comparing ordered poly_ints, Next: Checking for a poly_int marker value, Prev: Comparing potentially-unordered poly_ints, Up: Comparisons involving poly_int 8476 847710.3.4 Comparing ordered 'poly_int's 8478------------------------------------ 8479 8480In cases where there is a definite link between two 'poly_int's, such as 8481the outer and inner sizes of subregs, we usually require the sizes to be 8482ordered by the 'known_le' partial order. 'poly_int' provides the 8483following utility functions for ordered values: 8484 8485'ordered_p (A, B)' 8486 Return true if A and B are ordered by the 'known_le' partial order. 8487 8488'ordered_min (A, B)' 8489 Assert that A and B are ordered by 'known_le' and return the 8490 minimum of the two. When using this function, please add a comment 8491 explaining why the values are known to be ordered. 8492 8493'ordered_max (A, B)' 8494 Assert that A and B are ordered by 'known_le' and return the 8495 maximum of the two. When using this function, please add a comment 8496 explaining why the values are known to be ordered. 8497 8498 For example, if a subreg has an outer mode of size OUTER and an inner 8499mode of size INNER: 8500 8501 * the subreg is complete if known_eq (INNER, OUTER) 8502 8503 * otherwise, the subreg is paradoxical if known_le (INNER, OUTER) 8504 8505 * otherwise, the subreg is partial if known_le (OUTER, INNER) 8506 8507 * otherwise, the subreg is ill-formed 8508 8509 Thus the subreg is only valid if 'ordered_p (OUTER, INNER)' is true. 8510If this condition is already known to be true then: 8511 8512 * the subreg is complete if known_eq (INNER, OUTER) 8513 8514 * the subreg is paradoxical if maybe_lt (INNER, OUTER) 8515 8516 * the subreg is partial if maybe_lt (OUTER, INNER) 8517 8518 with the three conditions being mutually exclusive. 8519 8520 Code that checks whether a subreg is valid would therefore generally 8521check whether 'ordered_p' holds (in addition to whatever other checks 8522are required for subreg validity). Code that is dealing with existing 8523subregs can assert that 'ordered_p' holds and use either of the 8524classifications above. 8525 8526 8527File: gccint.info, Node: Checking for a poly_int marker value, Next: Range checks on poly_ints, Prev: Comparing ordered poly_ints, Up: Comparisons involving poly_int 8528 852910.3.5 Checking for a 'poly_int' marker value 8530--------------------------------------------- 8531 8532It is sometimes useful to have a special "marker value" that is not 8533meant to be taken literally. For example, some code uses a size of -1 8534to represent an unknown size, rather than having to carry around a 8535separate boolean to say whether the size is known. 8536 8537 The best way of checking whether something is a marker value is 8538'known_eq'. Conversely the best way of checking whether something is 8539_not_ a marker value is 'maybe_ne'. 8540 8541 Thus in the size example just mentioned, 'known_eq (size, -1)' would 8542check for an unknown size and 'maybe_ne (size, -1)' would check for a 8543known size. 8544 8545 8546File: gccint.info, Node: Range checks on poly_ints, Next: Sorting poly_ints, Prev: Checking for a poly_int marker value, Up: Comparisons involving poly_int 8547 854810.3.6 Range checks on 'poly_int's 8549---------------------------------- 8550 8551As well as the core comparisons (*note Comparison functions for 8552poly_int::), 'poly_int' provides utilities for various kinds of range 8553check. In each case the range is represented by a start position and a 8554size rather than a start position and an end position; this is because 8555the former is used much more often than the latter in GCC. Also, the 8556sizes can be -1 (or all ones for unsigned sizes) to indicate a range 8557with a known start position but an unknown size. All other sizes must 8558be nonnegative. A range of size 0 does not contain anything or overlap 8559anything. 8560 8561'known_size_p (SIZE)' 8562 Return true if SIZE represents a known range size, false if it is 8563 -1 or all ones (for signed and unsigned types respectively). 8564 8565'ranges_maybe_overlap_p (POS1, SIZE1, POS2, SIZE2)' 8566 Return true if the range described by POS1 and SIZE1 _might_ 8567 overlap the range described by POS2 and SIZE2 (in other words, 8568 return true if we cannot prove that the ranges are disjoint). 8569 8570'ranges_known_overlap_p (POS1, SIZE1, POS2, SIZE2)' 8571 Return true if the range described by POS1 and SIZE1 is known to 8572 overlap the range described by POS2 and SIZE2. 8573 8574'known_subrange_p (POS1, SIZE1, POS2, SIZE2)' 8575 Return true if the range described by POS1 and SIZE1 is known to be 8576 contained in the range described by POS2 and SIZE2. 8577 8578'maybe_in_range_p (VALUE, POS, SIZE)' 8579 Return true if VALUE _might_ be in the range described by POS and 8580 SIZE (in other words, return true if we cannot prove that VALUE is 8581 outside that range). 8582 8583'known_in_range_p (VALUE, POS, SIZE)' 8584 Return true if VALUE is known to be in the range described by POS 8585 and SIZE. 8586 8587'endpoint_representable_p (POS, SIZE)' 8588 Return true if the range described by POS and SIZE is open-ended or 8589 if the endpoint (POS + SIZE) is representable in the same type as 8590 POS and SIZE. The function returns false if adding SIZE to POS 8591 makes conceptual sense but could overflow. 8592 8593 There is also a 'poly_int' version of the 'IN_RANGE_P' macro: 8594 8595'coeffs_in_range_p (X, LOWER, UPPER)' 8596 Return true if every coefficient of X is in the inclusive range 8597 [LOWER, UPPER]. This function can be useful when testing whether 8598 an operation would cause the values of coefficients to overflow. 8599 8600 Note that the function does not indicate whether X itself is in the 8601 given range. X can be either a constant or a 'poly_int'. 8602 8603 8604File: gccint.info, Node: Sorting poly_ints, Prev: Range checks on poly_ints, Up: Comparisons involving poly_int 8605 860610.3.7 Sorting 'poly_int's 8607-------------------------- 8608 8609'poly_int' provides the following routine for sorting: 8610 8611'compare_sizes_for_sort (A, B)' 8612 Compare A and B in reverse lexicographical order (that is, compare 8613 the highest-indexed coefficients first). This can be useful when 8614 sorting data structures, since it has the effect of separating 8615 constant and non-constant values. If all values are nonnegative, 8616 the constant values come first. 8617 8618 Note that the values do not necessarily end up in numerical order. 8619 For example, '1 + 1X' would come after '100' in the sort order, but 8620 may well be less than '100' at run time. 8621 8622 8623File: gccint.info, Node: Arithmetic on poly_ints, Next: Alignment of poly_ints, Prev: Comparisons involving poly_int, Up: poly_int 8624 862510.4 Arithmetic on 'poly_int's 8626============================== 8627 8628Addition, subtraction, negation and bit inversion all work normally for 8629'poly_int's. Multiplication by a constant multiplier and left shifting 8630by a constant shift amount also work normally. General multiplication 8631of two 'poly_int's is not supported and is not useful in practice. 8632 8633 Other operations are only conditionally supported: the operation might 8634succeed or might fail, depending on the inputs. 8635 8636 This section describes both types of operation. 8637 8638* Menu: 8639 8640* Using poly_int with C++ arithmetic operators:: 8641* wi arithmetic on poly_ints:: 8642* Division of poly_ints:: 8643* Other poly_int arithmetic:: 8644 8645 8646File: gccint.info, Node: Using poly_int with C++ arithmetic operators, Next: wi arithmetic on poly_ints, Up: Arithmetic on poly_ints 8647 864810.4.1 Using 'poly_int' with C++ arithmetic operators 8649----------------------------------------------------- 8650 8651The following C++ expressions are supported, where P1 and P2 are 8652'poly_int's and where C1 and C2 are scalars: 8653 8654 -P1 8655 ~P1 8656 8657 P1 + P2 8658 P1 + C2 8659 C1 + P2 8660 8661 P1 - P2 8662 P1 - C2 8663 C1 - P2 8664 8665 C1 * P2 8666 P1 * C2 8667 8668 P1 << C2 8669 8670 P1 += P2 8671 P1 += C2 8672 8673 P1 -= P2 8674 P1 -= C2 8675 8676 P1 *= C2 8677 P1 <<= C2 8678 8679 These arithmetic operations handle integer ranks in a similar way to 8680C++. The main difference is that every coefficient narrower than 8681'HOST_WIDE_INT' promotes to 'HOST_WIDE_INT', whereas in C++ everything 8682narrower than 'int' promotes to 'int'. For example: 8683 8684 poly_uint16 + int -> poly_int64 8685 unsigned int + poly_uint16 -> poly_int64 8686 poly_int64 + int -> poly_int64 8687 poly_int32 + poly_uint64 -> poly_uint64 8688 uint64 + poly_int64 -> poly_uint64 8689 poly_offset_int + int32 -> poly_offset_int 8690 offset_int + poly_uint16 -> poly_offset_int 8691 8692 In the first two examples, both coefficients are narrower than 8693'HOST_WIDE_INT', so the result has coefficients of type 'HOST_WIDE_INT'. 8694In the other examples, the coefficient with the highest rank "wins". 8695 8696 If one of the operands is 'wide_int' or 'poly_wide_int', the rules are 8697the same as for 'wide_int' arithmetic. 8698 8699 8700File: gccint.info, Node: wi arithmetic on poly_ints, Next: Division of poly_ints, Prev: Using poly_int with C++ arithmetic operators, Up: Arithmetic on poly_ints 8701 870210.4.2 'wi' arithmetic on 'poly_int's 8703------------------------------------- 8704 8705As well as the C++ operators, 'poly_int' supports the following 'wi' 8706routines: 8707 8708 wi::neg (P1, &OVERFLOW) 8709 8710 wi::add (P1, P2) 8711 wi::add (P1, C2) 8712 wi::add (C1, P1) 8713 wi::add (P1, P2, SIGN, &OVERFLOW) 8714 8715 wi::sub (P1, P2) 8716 wi::sub (P1, C2) 8717 wi::sub (C1, P1) 8718 wi::sub (P1, P2, SIGN, &OVERFLOW) 8719 8720 wi::mul (P1, C2) 8721 wi::mul (C1, P1) 8722 wi::mul (P1, C2, SIGN, &OVERFLOW) 8723 8724 wi::lshift (P1, C2) 8725 8726 These routines just check whether overflow occurs on any individual 8727coefficient; it is not possible to know at compile time whether the 8728final runtime value would overflow. 8729 8730 8731File: gccint.info, Node: Division of poly_ints, Next: Other poly_int arithmetic, Prev: wi arithmetic on poly_ints, Up: Arithmetic on poly_ints 8732 873310.4.3 Division of 'poly_int's 8734------------------------------ 8735 8736Division of 'poly_int's is possible for certain inputs. The functions 8737for division return true if the operation is possible and in most cases 8738return the results by pointer. The routines are: 8739 8740'multiple_p (A, B)' 8741'multiple_p (A, B, "IENT)' 8742 Return true if A is an exact multiple of B, storing the result in 8743 QUOTIENT if so. There are overloads for various combinations of 8744 polynomial and constant A, B and QUOTIENT. 8745 8746'constant_multiple_p (A, B)' 8747'constant_multiple_p (A, B, "IENT)' 8748 Like 'multiple_p', but also test whether the multiple is a 8749 compile-time constant. 8750 8751'can_div_trunc_p (A, B, "IENT)' 8752'can_div_trunc_p (A, B, "IENT, &REMAINDER)' 8753 Return true if we can calculate 'trunc (A / B)' at compile time, 8754 storing the result in QUOTIENT and REMAINDER if so. 8755 8756'can_div_away_from_zero_p (A, B, "IENT)' 8757 Return true if we can calculate 'A / B' at compile time, rounding 8758 away from zero. Store the result in QUOTIENT if so. 8759 8760 Note that this is true if and only if 'can_div_trunc_p' is true. 8761 The only difference is in the rounding of the result. 8762 8763 There is also an asserting form of division: 8764 8765'exact_div (A, B)' 8766 Assert that A is a multiple of B and return 'A / B'. The result is 8767 a 'poly_int' if A is a 'poly_int'. 8768 8769 8770File: gccint.info, Node: Other poly_int arithmetic, Prev: Division of poly_ints, Up: Arithmetic on poly_ints 8771 877210.4.4 Other 'poly_int' arithmetic 8773---------------------------------- 8774 8775There are tentative routines for other operations besides division: 8776 8777'can_ior_p (A, B, &RESULT)' 8778 Return true if we can calculate 'A | B' at compile time, storing 8779 the result in RESULT if so. 8780 8781 Also, ANDs with a value '(1 << Y) - 1' or its inverse can be treated as 8782alignment operations. *Note Alignment of poly_ints::. 8783 8784 In addition, the following miscellaneous routines are available: 8785 8786'coeff_gcd (A)' 8787 Return the greatest common divisor of all nonzero coefficients in 8788 A, or zero if A is known to be zero. 8789 8790'common_multiple (A, B)' 8791 Return a value that is a multiple of both A and B, where one value 8792 is a 'poly_int' and the other is a scalar. The result will be the 8793 least common multiple for some indeterminate values but not 8794 necessarily for all. 8795 8796'force_common_multiple (A, B)' 8797 Return a value that is a multiple of both 'poly_int' A and 8798 'poly_int' B, asserting that such a value exists. The result will 8799 be the least common multiple for some indeterminate values but not 8800 necessarily for all. 8801 8802 When using this routine, please add a comment explaining why the 8803 assertion is known to hold. 8804 8805 Please add any other operations that you find to be useful. 8806 8807 8808File: gccint.info, Node: Alignment of poly_ints, Next: Computing bounds on poly_ints, Prev: Arithmetic on poly_ints, Up: poly_int 8809 881010.5 Alignment of 'poly_int's 8811============================= 8812 8813'poly_int' provides various routines for aligning values and for 8814querying misalignments. In each case the alignment must be a power of 88152. 8816 8817'can_align_p (VALUE, ALIGN)' 8818 Return true if we can align VALUE up or down to the nearest 8819 multiple of ALIGN at compile time. The answer is the same for both 8820 directions. 8821 8822'can_align_down (VALUE, ALIGN, &ALIGNED)' 8823 Return true if 'can_align_p'; if so, set ALIGNED to the greatest 8824 aligned value that is less than or equal to VALUE. 8825 8826'can_align_up (VALUE, ALIGN, &ALIGNED)' 8827 Return true if 'can_align_p'; if so, set ALIGNED to the lowest 8828 aligned value that is greater than or equal to VALUE. 8829 8830'known_equal_after_align_down (A, B, ALIGN)' 8831 Return true if we can align A and B down to the nearest ALIGN 8832 boundary at compile time and if the two results are equal. 8833 8834'known_equal_after_align_up (A, B, ALIGN)' 8835 Return true if we can align A and B up to the nearest ALIGN 8836 boundary at compile time and if the two results are equal. 8837 8838'aligned_lower_bound (VALUE, ALIGN)' 8839 Return a result that is no greater than VALUE and that is aligned 8840 to ALIGN. The result will the closest aligned value for some 8841 indeterminate values but not necessarily for all. 8842 8843 For example, suppose we are allocating an object of SIZE bytes in a 8844 downward-growing stack whose current limit is given by LIMIT. If 8845 the object requires ALIGN bytes of alignment, the new stack limit 8846 is given by: 8847 8848 aligned_lower_bound (LIMIT - SIZE, ALIGN) 8849 8850'aligned_upper_bound (VALUE, ALIGN)' 8851 Likewise return a result that is no less than VALUE and that is 8852 aligned to ALIGN. This is the routine that would be used for 8853 upward-growing stacks in the scenario just described. 8854 8855'known_misalignment (VALUE, ALIGN, &MISALIGN)' 8856 Return true if we can calculate the misalignment of VALUE with 8857 respect to ALIGN at compile time, storing the result in MISALIGN if 8858 so. 8859 8860'known_alignment (VALUE)' 8861 Return the minimum alignment that VALUE is known to have (in other 8862 words, the largest alignment that can be guaranteed whatever the 8863 values of the indeterminates turn out to be). Return 0 if VALUE is 8864 known to be 0. 8865 8866'force_align_down (VALUE, ALIGN)' 8867 Assert that VALUE can be aligned down to ALIGN at compile time and 8868 return the result. When using this routine, please add a comment 8869 explaining why the assertion is known to hold. 8870 8871'force_align_up (VALUE, ALIGN)' 8872 Likewise, but aligning up. 8873 8874'force_align_down_and_div (VALUE, ALIGN)' 8875 Divide the result of 'force_align_down' by ALIGN. Again, please 8876 add a comment explaining why the assertion in 'force_align_down' is 8877 known to hold. 8878 8879'force_align_up_and_div (VALUE, ALIGN)' 8880 Likewise for 'force_align_up'. 8881 8882'force_get_misalignment (VALUE, ALIGN)' 8883 Assert that we can calculate the misalignment of VALUE with respect 8884 to ALIGN at compile time and return the misalignment. When using 8885 this function, please add a comment explaining why the assertion is 8886 known to hold. 8887 8888 8889File: gccint.info, Node: Computing bounds on poly_ints, Next: Converting poly_ints, Prev: Alignment of poly_ints, Up: poly_int 8890 889110.6 Computing bounds on 'poly_int's 8892==================================== 8893 8894'poly_int' also provides routines for calculating lower and upper 8895bounds: 8896 8897'constant_lower_bound (A)' 8898 Assert that A is nonnegative and return the smallest value it can 8899 have. 8900 8901'lower_bound (A, B)' 8902 Return a value that is always less than or equal to both A and B. 8903 It will be the greatest such value for some indeterminate values 8904 but necessarily for all. 8905 8906'upper_bound (A, B)' 8907 Return a value that is always greater than or equal to both A and 8908 B. It will be the least such value for some indeterminate values 8909 but necessarily for all. 8910 8911 8912File: gccint.info, Node: Converting poly_ints, Next: Miscellaneous poly_int routines, Prev: Computing bounds on poly_ints, Up: poly_int 8913 891410.7 Converting 'poly_int's 8915=========================== 8916 8917A 'poly_int<N, T>' can be constructed from up to N individual T 8918coefficients, with the remaining coefficients being implicitly zero. In 8919particular, this means that every 'poly_int<N, T>' can be constructed 8920from a single scalar T, or something compatible with T. 8921 8922 Also, a 'poly_int<N, T>' can be constructed from a 'poly_int<N, U>' if 8923T can be constructed from U. 8924 8925 The following functions provide other forms of conversion, or test 8926whether such a conversion would succeed. 8927 8928'VALUE.is_constant ()' 8929 Return true if 'poly_int' VALUE is a compile-time constant. 8930 8931'VALUE.is_constant (&C1)' 8932 Return true if 'poly_int' VALUE is a compile-time constant, storing 8933 it in C1 if so. C1 must be able to hold all constant values of 8934 VALUE without loss of precision. 8935 8936'VALUE.to_constant ()' 8937 Assert that VALUE is a compile-time constant and return its value. 8938 When using this function, please add a comment explaining why the 8939 condition is known to hold (for example, because an earlier phase 8940 of analysis rejected non-constants). 8941 8942'VALUE.to_shwi (&P2)' 8943 Return true if 'poly_int<N, T>' VALUE can be represented without 8944 loss of precision as a 'poly_int<N, 'HOST_WIDE_INT'>', storing it 8945 in that form in P2 if so. 8946 8947'VALUE.to_uhwi (&P2)' 8948 Return true if 'poly_int<N, T>' VALUE can be represented without 8949 loss of precision as a 'poly_int<N, 'unsigned HOST_WIDE_INT'>', 8950 storing it in that form in P2 if so. 8951 8952'VALUE.force_shwi ()' 8953 Forcibly convert each coefficient of 'poly_int<N, T>' VALUE to 8954 'HOST_WIDE_INT', truncating any that are out of range. Return the 8955 result as a 'poly_int<N, 'HOST_WIDE_INT'>'. 8956 8957'VALUE.force_uhwi ()' 8958 Forcibly convert each coefficient of 'poly_int<N, T>' VALUE to 8959 'unsigned HOST_WIDE_INT', truncating any that are out of range. 8960 Return the result as a 'poly_int<N, 'unsigned HOST_WIDE_INT'>'. 8961 8962'wi::shwi (VALUE, PRECISION)' 8963 Return a 'poly_int' with the same value as VALUE, but with the 8964 coefficients converted from 'HOST_WIDE_INT' to 'wide_int'. 8965 PRECISION specifies the precision of the 'wide_int' cofficients; if 8966 this is wider than a 'HOST_WIDE_INT', the coefficients of VALUE 8967 will be sign-extended to fit. 8968 8969'wi::uhwi (VALUE, PRECISION)' 8970 Like 'wi::shwi', except that VALUE has coefficients of type 8971 'unsigned HOST_WIDE_INT'. If PRECISION is wider than a 8972 'HOST_WIDE_INT', the coefficients of VALUE will be zero-extended to 8973 fit. 8974 8975'wi::sext (VALUE, PRECISION)' 8976 Return a 'poly_int' of the same type as VALUE, sign-extending every 8977 coefficient from the low PRECISION bits. This in effect applies 8978 'wi::sext' to each coefficient individually. 8979 8980'wi::zext (VALUE, PRECISION)' 8981 Like 'wi::sext', but for zero extension. 8982 8983'poly_wide_int::from (VALUE, PRECISION, SIGN)' 8984 Convert VALUE to a 'poly_wide_int' in which each coefficient has 8985 PRECISION bits. Extend the coefficients according to SIGN if the 8986 coefficients have fewer bits. 8987 8988'poly_offset_int::from (VALUE, SIGN)' 8989 Convert VALUE to a 'poly_offset_int', extending its coefficients 8990 according to SIGN if they have fewer bits than 'offset_int'. 8991 8992'poly_widest_int::from (VALUE, SIGN)' 8993 Convert VALUE to a 'poly_widest_int', extending its coefficients 8994 according to SIGN if they have fewer bits than 'widest_int'. 8995 8996 8997File: gccint.info, Node: Miscellaneous poly_int routines, Next: Guidelines for using poly_int, Prev: Converting poly_ints, Up: poly_int 8998 899910.8 Miscellaneous 'poly_int' routines 9000====================================== 9001 9002'print_dec (VALUE, FILE, SIGN)' 9003'print_dec (VALUE, FILE)' 9004 Print VALUE to FILE as a decimal value, interpreting the 9005 coefficients according to SIGN. The final argument is optional if 9006 VALUE has an inherent sign; for example, 'poly_int64' values print 9007 as signed by default and 'poly_uint64' values print as unsigned by 9008 default. 9009 9010 This is a simply a 'poly_int' version of a wide-int routine. 9011 9012 9013File: gccint.info, Node: Guidelines for using poly_int, Prev: Miscellaneous poly_int routines, Up: poly_int 9014 901510.9 Guidelines for using 'poly_int' 9016==================================== 9017 9018One of the main design goals of 'poly_int' was to make it easy to write 9019target-independent code that handles variable-sized registers even when 9020the current target has fixed-sized registers. There are two aspects to 9021this: 9022 9023 * The set of 'poly_int' operations should be complete enough that the 9024 question in most cases becomes "Can we do this operation on these 9025 particular 'poly_int' values? If not, bail out" rather than "Are 9026 these 'poly_int' values constant? If so, do the operation, 9027 otherwise bail out". 9028 9029 * If target-independent code compiles and runs correctly on a target 9030 with one value of 'NUM_POLY_INT_COEFFS', and if the code does not 9031 use asserting functions like 'to_constant', it is reasonable to 9032 assume that the code also works on targets with other values of 9033 'NUM_POLY_INT_COEFFS'. There is no need to check this during 9034 everyday development. 9035 9036 So the general principle is: if target-independent code is dealing with 9037a 'poly_int' value, it is better to operate on it as a 'poly_int' if at 9038all possible, choosing conservatively-correct behavior if a particular 9039operation fails. For example, the following code handles an index 'pos' 9040into a sequence of vectors that each have 'nunits' elements: 9041 9042 /* Calculate which vector contains the result, and which lane of 9043 that vector we need. */ 9044 if (!can_div_trunc_p (pos, nunits, &vec_entry, &vec_index)) 9045 { 9046 if (dump_enabled_p ()) 9047 dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location, 9048 "Cannot determine which vector holds the" 9049 " final result.\n"); 9050 return false; 9051 } 9052 9053 However, there are some contexts in which operating on a 'poly_int' is 9054not possible or does not make sense. One example is when handling 9055static initializers, since no current target supports the concept of a 9056variable-length static initializer. In these situations, a reasonable 9057fallback is: 9058 9059 if (POLY_VALUE.is_constant (&CONST_VALUE)) 9060 { 9061 ... 9062 /* Operate on CONST_VALUE. */ 9063 ... 9064 } 9065 else 9066 { 9067 ... 9068 /* Conservatively correct fallback. */ 9069 ... 9070 } 9071 9072 'poly_int' also provides some asserting functions like 'to_constant'. 9073Please only use these functions if there is a good theoretical reason to 9074believe that the assertion cannot fire. For example, if some work is 9075divided into an analysis phase and an implementation phase, the analysis 9076phase might reject inputs that are not 'is_constant', in which case the 9077implementation phase can reasonably use 'to_constant' on the remaining 9078inputs. The assertions should not be used to discover whether a 9079condition ever occurs "in the field"; in other words, they should not be 9080used to restrict code to constants at first, with the intention of only 9081implementing a 'poly_int' version if a user hits the assertion. 9082 9083 If a particular asserting function like 'to_constant' is needed more 9084than once for the same reason, it is probably worth adding a helper 9085function or macro for that situation, so that the justification only 9086needs to be given once. For example: 9087 9088 /* Return the size of an element in a vector of size SIZE, given that 9089 the vector has NELTS elements. The return value is in the same units 9090 as SIZE (either bits or bytes). 9091 9092 to_constant () is safe in this situation because vector elements are 9093 always constant-sized scalars. */ 9094 #define vector_element_size(SIZE, NELTS) \ 9095 (exact_div (SIZE, NELTS).to_constant ()) 9096 9097 Target-specific code in 'config/CPU' only needs to handle non-constant 9098'poly_int's if 'NUM_POLY_INT_COEFFS' is greater than one. For other 9099targets, 'poly_int' degenerates to a compile-time constant and is often 9100interchangable with a normal scalar integer. There are two main 9101exceptions: 9102 9103 * Sometimes an explicit cast to an integer type might be needed, such 9104 as to resolve ambiguities in a '?:' expression, or when passing 9105 values through '...' to things like print functions. 9106 9107 * Target macros are included in target-independent code and so do not 9108 have access to the implicit conversion to a scalar integer. If 9109 this becomes a problem for a particular target macro, the possible 9110 solutions, in order of preference, are: 9111 9112 * Convert the target macro to a target hook (for all targets). 9113 9114 * Put the target's implementation of the target macro in its 9115 'CPU.c' file and call it from the target macro in the 'CPU.h' 9116 file. 9117 9118 * Add 'to_constant ()' calls where necessary. The previous 9119 option is preferable because it will help with any future 9120 conversion of the macro to a hook. 9121 9122 9123File: gccint.info, Node: GENERIC, Next: GIMPLE, Prev: poly_int, Up: Top 9124 912511 GENERIC 9126********** 9127 9128The purpose of GENERIC is simply to provide a language-independent way 9129of representing an entire function in trees. To this end, it was 9130necessary to add a few new tree codes to the back end, but almost 9131everything was already there. If you can express it with the codes in 9132'gcc/tree.def', it's GENERIC. 9133 9134 Early on, there was a great deal of debate about how to think about 9135statements in a tree IL. In GENERIC, a statement is defined as any 9136expression whose value, if any, is ignored. A statement will always 9137have 'TREE_SIDE_EFFECTS' set (or it will be discarded), but a 9138non-statement expression may also have side effects. A 'CALL_EXPR', for 9139instance. 9140 9141 It would be possible for some local optimizations to work on the 9142GENERIC form of a function; indeed, the adapted tree inliner works fine 9143on GENERIC, but the current compiler performs inlining after lowering to 9144GIMPLE (a restricted form described in the next section). Indeed, 9145currently the frontends perform this lowering before handing off to 9146'tree_rest_of_compilation', but this seems inelegant. 9147 9148* Menu: 9149 9150* Deficiencies:: Topics net yet covered in this document. 9151* Tree overview:: All about 'tree's. 9152* Types:: Fundamental and aggregate types. 9153* Declarations:: Type declarations and variables. 9154* Attributes:: Declaration and type attributes. 9155* Expressions: Expression trees. Operating on data. 9156* Statements:: Control flow and related trees. 9157* Functions:: Function bodies, linkage, and other aspects. 9158* Language-dependent trees:: Topics and trees specific to language front ends. 9159* C and C++ Trees:: Trees specific to C and C++. 9160* Java Trees:: Trees specific to Java. 9161 9162 9163File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: GENERIC 9164 916511.1 Deficiencies 9166================= 9167 9168There are many places in which this document is incomplet and incorrekt. 9169It is, as of yet, only _preliminary_ documentation. 9170 9171 9172File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: GENERIC 9173 917411.2 Overview 9175============= 9176 9177The central data structure used by the internal representation is the 9178'tree'. These nodes, while all of the C type 'tree', are of many 9179varieties. A 'tree' is a pointer type, but the object to which it 9180points may be of a variety of types. From this point forward, we will 9181refer to trees in ordinary type, rather than in 'this font', except when 9182talking about the actual C type 'tree'. 9183 9184 You can tell what kind of node a particular tree is by using the 9185'TREE_CODE' macro. Many, many macros take trees as input and return 9186trees as output. However, most macros require a certain kind of tree 9187node as input. In other words, there is a type-system for trees, but it 9188is not reflected in the C type-system. 9189 9190 For safety, it is useful to configure GCC with '--enable-checking'. 9191Although this results in a significant performance penalty (since all 9192tree types are checked at run-time), and is therefore inappropriate in a 9193release version, it is extremely helpful during the development process. 9194 9195 Many macros behave as predicates. Many, although not all, of these 9196predicates end in '_P'. Do not rely on the result type of these macros 9197being of any particular type. You may, however, rely on the fact that 9198the type can be compared to '0', so that statements like 9199 if (TEST_P (t) && !TEST_P (y)) 9200 x = 1; 9201and 9202 int i = (TEST_P (t) != 0); 9203are legal. Macros that return 'int' values now may be changed to return 9204'tree' values, or other pointers in the future. Even those that 9205continue to return 'int' may return multiple nonzero codes where 9206previously they returned only zero and one. Therefore, you should not 9207write code like 9208 if (TEST_P (t) == 1) 9209as this code is not guaranteed to work correctly in the future. 9210 9211 You should not take the address of values returned by the macros or 9212functions described here. In particular, no guarantee is given that the 9213values are lvalues. 9214 9215 In general, the names of macros are all in uppercase, while the names 9216of functions are entirely in lowercase. There are rare exceptions to 9217this rule. You should assume that any macro or function whose name is 9218made up entirely of uppercase letters may evaluate its arguments more 9219than once. You may assume that a macro or function whose name is made 9220up entirely of lowercase letters will evaluate its arguments only once. 9221 9222 The 'error_mark_node' is a special tree. Its tree code is 9223'ERROR_MARK', but since there is only ever one node with that code, the 9224usual practice is to compare the tree against 'error_mark_node'. (This 9225test is just a test for pointer equality.) If an error has occurred 9226during front-end processing the flag 'errorcount' will be set. If the 9227front end has encountered code it cannot handle, it will issue a message 9228to the user and set 'sorrycount'. When these flags are set, any macro 9229or function which normally returns a tree of a particular kind may 9230instead return the 'error_mark_node'. Thus, if you intend to do any 9231processing of erroneous code, you must be prepared to deal with the 9232'error_mark_node'. 9233 9234 Occasionally, a particular tree slot (like an operand to an expression, 9235or a particular field in a declaration) will be referred to as "reserved 9236for the back end". These slots are used to store RTL when the tree is 9237converted to RTL for use by the GCC back end. However, if that process 9238is not taking place (e.g., if the front end is being hooked up to an 9239intelligent editor), then those slots may be used by the back end 9240presently in use. 9241 9242 If you encounter situations that do not match this documentation, such 9243as tree nodes of types not mentioned here, or macros documented to 9244return entities of a particular kind that instead return entities of 9245some different kind, you have found a bug, either in the front end or in 9246the documentation. Please report these bugs as you would any other bug. 9247 9248* Menu: 9249 9250* Macros and Functions::Macros and functions that can be used with all trees. 9251* Identifiers:: The names of things. 9252* Containers:: Lists and vectors. 9253 9254 9255File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview 9256 925711.2.1 Trees 9258------------ 9259 9260All GENERIC trees have two fields in common. First, 'TREE_CHAIN' is a 9261pointer that can be used as a singly-linked list to other trees. The 9262other is 'TREE_TYPE'. Many trees store the type of an expression or 9263declaration in this field. 9264 9265 These are some other functions for handling trees: 9266 9267'tree_size' 9268 Return the number of bytes a tree takes. 9269 9270'build0' 9271'build1' 9272'build2' 9273'build3' 9274'build4' 9275'build5' 9276'build6' 9277 9278 These functions build a tree and supply values to put in each 9279 parameter. The basic signature is 'code, type, [operands]'. 9280 'code' is the 'TREE_CODE', and 'type' is a tree representing the 9281 'TREE_TYPE'. These are followed by the operands, each of which is 9282 also a tree. 9283 9284 9285File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview 9286 928711.2.2 Identifiers 9288------------------ 9289 9290An 'IDENTIFIER_NODE' represents a slightly more general concept than the 9291standard C or C++ concept of identifier. In particular, an 9292'IDENTIFIER_NODE' may contain a '$', or other extraordinary characters. 9293 9294 There are never two distinct 'IDENTIFIER_NODE's representing the same 9295identifier. Therefore, you may use pointer equality to compare 9296'IDENTIFIER_NODE's, rather than using a routine like 'strcmp'. Use 9297'get_identifier' to obtain the unique 'IDENTIFIER_NODE' for a supplied 9298string. 9299 9300 You can use the following macros to access identifiers: 9301'IDENTIFIER_POINTER' 9302 The string represented by the identifier, represented as a 'char*'. 9303 This string is always 'NUL'-terminated, and contains no embedded 9304 'NUL' characters. 9305 9306'IDENTIFIER_LENGTH' 9307 The length of the string returned by 'IDENTIFIER_POINTER', not 9308 including the trailing 'NUL'. This value of 'IDENTIFIER_LENGTH 9309 (x)' is always the same as 'strlen (IDENTIFIER_POINTER (x))'. 9310 9311'IDENTIFIER_OPNAME_P' 9312 This predicate holds if the identifier represents the name of an 9313 overloaded operator. In this case, you should not depend on the 9314 contents of either the 'IDENTIFIER_POINTER' or the 9315 'IDENTIFIER_LENGTH'. 9316 9317'IDENTIFIER_TYPENAME_P' 9318 This predicate holds if the identifier represents the name of a 9319 user-defined conversion operator. In this case, the 'TREE_TYPE' of 9320 the 'IDENTIFIER_NODE' holds the type to which the conversion 9321 operator converts. 9322 9323 9324File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview 9325 932611.2.3 Containers 9327----------------- 9328 9329Two common container data structures can be represented directly with 9330tree nodes. A 'TREE_LIST' is a singly linked list containing two trees 9331per node. These are the 'TREE_PURPOSE' and 'TREE_VALUE' of each node. 9332(Often, the 'TREE_PURPOSE' contains some kind of tag, or additional 9333information, while the 'TREE_VALUE' contains the majority of the 9334payload. In other cases, the 'TREE_PURPOSE' is simply 'NULL_TREE', 9335while in still others both the 'TREE_PURPOSE' and 'TREE_VALUE' are of 9336equal stature.) Given one 'TREE_LIST' node, the next node is found by 9337following the 'TREE_CHAIN'. If the 'TREE_CHAIN' is 'NULL_TREE', then 9338you have reached the end of the list. 9339 9340 A 'TREE_VEC' is a simple vector. The 'TREE_VEC_LENGTH' is an integer 9341(not a tree) giving the number of nodes in the vector. The nodes 9342themselves are accessed using the 'TREE_VEC_ELT' macro, which takes two 9343arguments. The first is the 'TREE_VEC' in question; the second is an 9344integer indicating which element in the vector is desired. The elements 9345are indexed from zero. 9346 9347 9348File: gccint.info, Node: Types, Next: Declarations, Prev: Tree overview, Up: GENERIC 9349 935011.3 Types 9351========== 9352 9353All types have corresponding tree nodes. However, you should not assume 9354that there is exactly one tree node corresponding to each type. There 9355are often multiple nodes corresponding to the same type. 9356 9357 For the most part, different kinds of types have different tree codes. 9358(For example, pointer types use a 'POINTER_TYPE' code while arrays use 9359an 'ARRAY_TYPE' code.) However, pointers to member functions use the 9360'RECORD_TYPE' code. Therefore, when writing a 'switch' statement that 9361depends on the code associated with a particular type, you should take 9362care to handle pointers to member functions under the 'RECORD_TYPE' case 9363label. 9364 9365 The following functions and macros deal with cv-qualification of types: 9366'TYPE_MAIN_VARIANT' 9367 This macro returns the unqualified version of a type. It may be 9368 applied to an unqualified type, but it is not always the identity 9369 function in that case. 9370 9371 A few other macros and functions are usable with all types: 9372'TYPE_SIZE' 9373 The number of bits required to represent the type, represented as 9374 an 'INTEGER_CST'. For an incomplete type, 'TYPE_SIZE' will be 9375 'NULL_TREE'. 9376 9377'TYPE_ALIGN' 9378 The alignment of the type, in bits, represented as an 'int'. 9379 9380'TYPE_NAME' 9381 This macro returns a declaration (in the form of a 'TYPE_DECL') for 9382 the type. (Note this macro does _not_ return an 'IDENTIFIER_NODE', 9383 as you might expect, given its name!) You can look at the 9384 'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the 9385 type. The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a 9386 built-in type, the result of a typedef, or a named class type. 9387 9388'TYPE_CANONICAL' 9389 This macro returns the "canonical" type for the given type node. 9390 Canonical types are used to improve performance in the C++ and 9391 Objective-C++ front ends by allowing efficient comparison between 9392 two type nodes in 'same_type_p': if the 'TYPE_CANONICAL' values of 9393 the types are equal, the types are equivalent; otherwise, the types 9394 are not equivalent. The notion of equivalence for canonical types 9395 is the same as the notion of type equivalence in the language 9396 itself. For instance, 9397 9398 When 'TYPE_CANONICAL' is 'NULL_TREE', there is no canonical type 9399 for the given type node. In this case, comparison between this 9400 type and any other type requires the compiler to perform a deep, 9401 "structural" comparison to see if the two type nodes have the same 9402 form and properties. 9403 9404 The canonical type for a node is always the most fundamental type 9405 in the equivalence class of types. For instance, 'int' is its own 9406 canonical type. A typedef 'I' of 'int' will have 'int' as its 9407 canonical type. Similarly, 'I*' and a typedef 'IP' (defined to 9408 'I*') will has 'int*' as their canonical type. When building a new 9409 type node, be sure to set 'TYPE_CANONICAL' to the appropriate 9410 canonical type. If the new type is a compound type (built from 9411 other types), and any of those other types require structural 9412 equality, use 'SET_TYPE_STRUCTURAL_EQUALITY' to ensure that the new 9413 type also requires structural equality. Finally, if for some 9414 reason you cannot guarantee that 'TYPE_CANONICAL' will point to the 9415 canonical type, use 'SET_TYPE_STRUCTURAL_EQUALITY' to make sure 9416 that the new type-and any type constructed based on it-requires 9417 structural equality. If you suspect that the canonical type system 9418 is miscomparing types, pass '--param verify-canonical-types=1' to 9419 the compiler or configure with '--enable-checking' to force the 9420 compiler to verify its canonical-type comparisons against the 9421 structural comparisons; the compiler will then print any warnings 9422 if the canonical types miscompare. 9423 9424'TYPE_STRUCTURAL_EQUALITY_P' 9425 This predicate holds when the node requires structural equality 9426 checks, e.g., when 'TYPE_CANONICAL' is 'NULL_TREE'. 9427 9428'SET_TYPE_STRUCTURAL_EQUALITY' 9429 This macro states that the type node it is given requires 9430 structural equality checks, e.g., it sets 'TYPE_CANONICAL' to 9431 'NULL_TREE'. 9432 9433'same_type_p' 9434 This predicate takes two types as input, and holds if they are the 9435 same type. For example, if one type is a 'typedef' for the other, 9436 or both are 'typedef's for the same type. This predicate also 9437 holds if the two trees given as input are simply copies of one 9438 another; i.e., there is no difference between them at the source 9439 level, but, for whatever reason, a duplicate has been made in the 9440 representation. You should never use '==' (pointer equality) to 9441 compare types; always use 'same_type_p' instead. 9442 9443 Detailed below are the various kinds of types, and the macros that can 9444be used to access them. Although other kinds of types are used 9445elsewhere in G++, the types described here are the only ones that you 9446will encounter while examining the intermediate representation. 9447 9448'VOID_TYPE' 9449 Used to represent the 'void' type. 9450 9451'INTEGER_TYPE' 9452 Used to represent the various integral types, including 'char', 9453 'short', 'int', 'long', and 'long long'. This code is not used for 9454 enumeration types, nor for the 'bool' type. The 'TYPE_PRECISION' 9455 is the number of bits used in the representation, represented as an 9456 'unsigned int'. (Note that in the general case this is not the 9457 same value as 'TYPE_SIZE'; suppose that there were a 24-bit integer 9458 type, but that alignment requirements for the ABI required 32-bit 9459 alignment. Then, 'TYPE_SIZE' would be an 'INTEGER_CST' for 32, 9460 while 'TYPE_PRECISION' would be 24.) The integer type is unsigned 9461 if 'TYPE_UNSIGNED' holds; otherwise, it is signed. 9462 9463 The 'TYPE_MIN_VALUE' is an 'INTEGER_CST' for the smallest integer 9464 that may be represented by this type. Similarly, the 9465 'TYPE_MAX_VALUE' is an 'INTEGER_CST' for the largest integer that 9466 may be represented by this type. 9467 9468'REAL_TYPE' 9469 Used to represent the 'float', 'double', and 'long double' types. 9470 The number of bits in the floating-point representation is given by 9471 'TYPE_PRECISION', as in the 'INTEGER_TYPE' case. 9472 9473'FIXED_POINT_TYPE' 9474 Used to represent the 'short _Fract', '_Fract', 'long _Fract', 9475 'long long _Fract', 'short _Accum', '_Accum', 'long _Accum', and 9476 'long long _Accum' types. The number of bits in the fixed-point 9477 representation is given by 'TYPE_PRECISION', as in the 9478 'INTEGER_TYPE' case. There may be padding bits, fractional bits 9479 and integral bits. The number of fractional bits is given by 9480 'TYPE_FBIT', and the number of integral bits is given by 9481 'TYPE_IBIT'. The fixed-point type is unsigned if 'TYPE_UNSIGNED' 9482 holds; otherwise, it is signed. The fixed-point type is saturating 9483 if 'TYPE_SATURATING' holds; otherwise, it is not saturating. 9484 9485'COMPLEX_TYPE' 9486 Used to represent GCC built-in '__complex__' data types. The 9487 'TREE_TYPE' is the type of the real and imaginary parts. 9488 9489'ENUMERAL_TYPE' 9490 Used to represent an enumeration type. The 'TYPE_PRECISION' gives 9491 (as an 'int'), the number of bits used to represent the type. If 9492 there are no negative enumeration constants, 'TYPE_UNSIGNED' will 9493 hold. The minimum and maximum enumeration constants may be 9494 obtained with 'TYPE_MIN_VALUE' and 'TYPE_MAX_VALUE', respectively; 9495 each of these macros returns an 'INTEGER_CST'. 9496 9497 The actual enumeration constants themselves may be obtained by 9498 looking at the 'TYPE_VALUES'. This macro will return a 9499 'TREE_LIST', containing the constants. The 'TREE_PURPOSE' of each 9500 node will be an 'IDENTIFIER_NODE' giving the name of the constant; 9501 the 'TREE_VALUE' will be an 'INTEGER_CST' giving the value assigned 9502 to that constant. These constants will appear in the order in 9503 which they were declared. The 'TREE_TYPE' of each of these 9504 constants will be the type of enumeration type itself. 9505 9506'BOOLEAN_TYPE' 9507 Used to represent the 'bool' type. 9508 9509'POINTER_TYPE' 9510 Used to represent pointer types, and pointer to data member types. 9511 The 'TREE_TYPE' gives the type to which this type points. 9512 9513'REFERENCE_TYPE' 9514 Used to represent reference types. The 'TREE_TYPE' gives the type 9515 to which this type refers. 9516 9517'FUNCTION_TYPE' 9518 Used to represent the type of non-member functions and of static 9519 member functions. The 'TREE_TYPE' gives the return type of the 9520 function. The 'TYPE_ARG_TYPES' are a 'TREE_LIST' of the argument 9521 types. The 'TREE_VALUE' of each node in this list is the type of 9522 the corresponding argument; the 'TREE_PURPOSE' is an expression for 9523 the default argument value, if any. If the last node in the list 9524 is 'void_list_node' (a 'TREE_LIST' node whose 'TREE_VALUE' is the 9525 'void_type_node'), then functions of this type do not take variable 9526 arguments. Otherwise, they do take a variable number of arguments. 9527 9528 Note that in C (but not in C++) a function declared like 'void f()' 9529 is an unprototyped function taking a variable number of arguments; 9530 the 'TYPE_ARG_TYPES' of such a function will be 'NULL'. 9531 9532'METHOD_TYPE' 9533 Used to represent the type of a non-static member function. Like a 9534 'FUNCTION_TYPE', the return type is given by the 'TREE_TYPE'. The 9535 type of '*this', i.e., the class of which functions of this type 9536 are a member, is given by the 'TYPE_METHOD_BASETYPE'. The 9537 'TYPE_ARG_TYPES' is the parameter list, as for a 'FUNCTION_TYPE', 9538 and includes the 'this' argument. 9539 9540'ARRAY_TYPE' 9541 Used to represent array types. The 'TREE_TYPE' gives the type of 9542 the elements in the array. If the array-bound is present in the 9543 type, the 'TYPE_DOMAIN' is an 'INTEGER_TYPE' whose 'TYPE_MIN_VALUE' 9544 and 'TYPE_MAX_VALUE' will be the lower and upper bounds of the 9545 array, respectively. The 'TYPE_MIN_VALUE' will always be an 9546 'INTEGER_CST' for zero, while the 'TYPE_MAX_VALUE' will be one less 9547 than the number of elements in the array, i.e., the highest value 9548 which may be used to index an element in the array. 9549 9550'RECORD_TYPE' 9551 Used to represent 'struct' and 'class' types, as well as pointers 9552 to member functions and similar constructs in other languages. 9553 'TYPE_FIELDS' contains the items contained in this type, each of 9554 which can be a 'FIELD_DECL', 'VAR_DECL', 'CONST_DECL', or 9555 'TYPE_DECL'. You may not make any assumptions about the ordering 9556 of the fields in the type or whether one or more of them overlap. 9557 9558'UNION_TYPE' 9559 Used to represent 'union' types. Similar to 'RECORD_TYPE' except 9560 that all 'FIELD_DECL' nodes in 'TYPE_FIELD' start at bit position 9561 zero. 9562 9563'QUAL_UNION_TYPE' 9564 Used to represent part of a variant record in Ada. Similar to 9565 'UNION_TYPE' except that each 'FIELD_DECL' has a 'DECL_QUALIFIER' 9566 field, which contains a boolean expression that indicates whether 9567 the field is present in the object. The type will only have one 9568 field, so each field's 'DECL_QUALIFIER' is only evaluated if none 9569 of the expressions in the previous fields in 'TYPE_FIELDS' are 9570 nonzero. Normally these expressions will reference a field in the 9571 outer object using a 'PLACEHOLDER_EXPR'. 9572 9573'LANG_TYPE' 9574 This node is used to represent a language-specific type. The front 9575 end must handle it. 9576 9577'OFFSET_TYPE' 9578 This node is used to represent a pointer-to-data member. For a 9579 data member 'X::m' the 'TYPE_OFFSET_BASETYPE' is 'X' and the 9580 'TREE_TYPE' is the type of 'm'. 9581 9582 There are variables whose values represent some of the basic types. 9583These include: 9584'void_type_node' 9585 A node for 'void'. 9586 9587'integer_type_node' 9588 A node for 'int'. 9589 9590'unsigned_type_node.' 9591 A node for 'unsigned int'. 9592 9593'char_type_node.' 9594 A node for 'char'. 9595It may sometimes be useful to compare one of these variables with a type 9596in hand, using 'same_type_p'. 9597 9598 9599File: gccint.info, Node: Declarations, Next: Attributes, Prev: Types, Up: GENERIC 9600 960111.4 Declarations 9602================= 9603 9604This section covers the various kinds of declarations that appear in the 9605internal representation, except for declarations of functions 9606(represented by 'FUNCTION_DECL' nodes), which are described in *note 9607Functions::. 9608 9609* Menu: 9610 9611* Working with declarations:: Macros and functions that work on 9612declarations. 9613* Internal structure:: How declaration nodes are represented. 9614 9615 9616File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations 9617 961811.4.1 Working with declarations 9619-------------------------------- 9620 9621Some macros can be used with any kind of declaration. These include: 9622'DECL_NAME' 9623 This macro returns an 'IDENTIFIER_NODE' giving the name of the 9624 entity. 9625 9626'TREE_TYPE' 9627 This macro returns the type of the entity declared. 9628 9629'EXPR_FILENAME' 9630 This macro returns the name of the file in which the entity was 9631 declared, as a 'char*'. For an entity declared implicitly by the 9632 compiler (like '__builtin_memcpy'), this will be the string 9633 '"<internal>"'. 9634 9635'EXPR_LINENO' 9636 This macro returns the line number at which the entity was 9637 declared, as an 'int'. 9638 9639'DECL_ARTIFICIAL' 9640 This predicate holds if the declaration was implicitly generated by 9641 the compiler. For example, this predicate will hold of an 9642 implicitly declared member function, or of the 'TYPE_DECL' 9643 implicitly generated for a class type. Recall that in C++ code 9644 like: 9645 struct S {}; 9646 is roughly equivalent to C code like: 9647 struct S {}; 9648 typedef struct S S; 9649 The implicitly generated 'typedef' declaration is represented by a 9650 'TYPE_DECL' for which 'DECL_ARTIFICIAL' holds. 9651 9652 The various kinds of declarations include: 9653'LABEL_DECL' 9654 These nodes are used to represent labels in function bodies. For 9655 more information, see *note Functions::. These nodes only appear 9656 in block scopes. 9657 9658'CONST_DECL' 9659 These nodes are used to represent enumeration constants. The value 9660 of the constant is given by 'DECL_INITIAL' which will be an 9661 'INTEGER_CST' with the same type as the 'TREE_TYPE' of the 9662 'CONST_DECL', i.e., an 'ENUMERAL_TYPE'. 9663 9664'RESULT_DECL' 9665 These nodes represent the value returned by a function. When a 9666 value is assigned to a 'RESULT_DECL', that indicates that the value 9667 should be returned, via bitwise copy, by the function. You can use 9668 'DECL_SIZE' and 'DECL_ALIGN' on a 'RESULT_DECL', just as with a 9669 'VAR_DECL'. 9670 9671'TYPE_DECL' 9672 These nodes represent 'typedef' declarations. The 'TREE_TYPE' is 9673 the type declared to have the name given by 'DECL_NAME'. In some 9674 cases, there is no associated name. 9675 9676'VAR_DECL' 9677 These nodes represent variables with namespace or block scope, as 9678 well as static data members. The 'DECL_SIZE' and 'DECL_ALIGN' are 9679 analogous to 'TYPE_SIZE' and 'TYPE_ALIGN'. For a declaration, you 9680 should always use the 'DECL_SIZE' and 'DECL_ALIGN' rather than the 9681 'TYPE_SIZE' and 'TYPE_ALIGN' given by the 'TREE_TYPE', since 9682 special attributes may have been applied to the variable to give it 9683 a particular size and alignment. You may use the predicates 9684 'DECL_THIS_STATIC' or 'DECL_THIS_EXTERN' to test whether the 9685 storage class specifiers 'static' or 'extern' were used to declare 9686 a variable. 9687 9688 If this variable is initialized (but does not require a 9689 constructor), the 'DECL_INITIAL' will be an expression for the 9690 initializer. The initializer should be evaluated, and a bitwise 9691 copy into the variable performed. If the 'DECL_INITIAL' is the 9692 'error_mark_node', there is an initializer, but it is given by an 9693 explicit statement later in the code; no bitwise copy is required. 9694 9695 GCC provides an extension that allows either automatic variables, 9696 or global variables, to be placed in particular registers. This 9697 extension is being used for a particular 'VAR_DECL' if 9698 'DECL_REGISTER' holds for the 'VAR_DECL', and if 9699 'DECL_ASSEMBLER_NAME' is not equal to 'DECL_NAME'. In that case, 9700 'DECL_ASSEMBLER_NAME' is the name of the register into which the 9701 variable will be placed. 9702 9703'PARM_DECL' 9704 Used to represent a parameter to a function. Treat these nodes 9705 similarly to 'VAR_DECL' nodes. These nodes only appear in the 9706 'DECL_ARGUMENTS' for a 'FUNCTION_DECL'. 9707 9708 The 'DECL_ARG_TYPE' for a 'PARM_DECL' is the type that will 9709 actually be used when a value is passed to this function. It may 9710 be a wider type than the 'TREE_TYPE' of the parameter; for example, 9711 the ordinary type might be 'short' while the 'DECL_ARG_TYPE' is 9712 'int'. 9713 9714'DEBUG_EXPR_DECL' 9715 Used to represent an anonymous debug-information temporary created 9716 to hold an expression as it is optimized away, so that its value 9717 can be referenced in debug bind statements. 9718 9719'FIELD_DECL' 9720 These nodes represent non-static data members. The 'DECL_SIZE' and 9721 'DECL_ALIGN' behave as for 'VAR_DECL' nodes. The position of the 9722 field within the parent record is specified by a combination of 9723 three attributes. 'DECL_FIELD_OFFSET' is the position, counting in 9724 bytes, of the 'DECL_OFFSET_ALIGN'-bit sized word containing the bit 9725 of the field closest to the beginning of the structure. 9726 'DECL_FIELD_BIT_OFFSET' is the bit offset of the first bit of the 9727 field within this word; this may be nonzero even for fields that 9728 are not bit-fields, since 'DECL_OFFSET_ALIGN' may be greater than 9729 the natural alignment of the field's type. 9730 9731 If 'DECL_C_BIT_FIELD' holds, this field is a bit-field. In a 9732 bit-field, 'DECL_BIT_FIELD_TYPE' also contains the type that was 9733 originally specified for it, while DECL_TYPE may be a modified type 9734 with lesser precision, according to the size of the bit field. 9735 9736'NAMESPACE_DECL' 9737 Namespaces provide a name hierarchy for other declarations. They 9738 appear in the 'DECL_CONTEXT' of other '_DECL' nodes. 9739 9740 9741File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations 9742 974311.4.2 Internal structure 9744------------------------- 9745 9746'DECL' nodes are represented internally as a hierarchy of structures. 9747 9748* Menu: 9749 9750* Current structure hierarchy:: The current DECL node structure 9751hierarchy. 9752* Adding new DECL node types:: How to add a new DECL node to a 9753frontend. 9754 9755 9756File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure 9757 975811.4.2.1 Current structure hierarchy 9759.................................... 9760 9761'struct tree_decl_minimal' 9762 This is the minimal structure to inherit from in order for common 9763 'DECL' macros to work. The fields it contains are a unique ID, 9764 source location, context, and name. 9765 9766'struct tree_decl_common' 9767 This structure inherits from 'struct tree_decl_minimal'. It 9768 contains fields that most 'DECL' nodes need, such as a field to 9769 store alignment, machine mode, size, and attributes. 9770 9771'struct tree_field_decl' 9772 This structure inherits from 'struct tree_decl_common'. It is used 9773 to represent 'FIELD_DECL'. 9774 9775'struct tree_label_decl' 9776 This structure inherits from 'struct tree_decl_common'. It is used 9777 to represent 'LABEL_DECL'. 9778 9779'struct tree_translation_unit_decl' 9780 This structure inherits from 'struct tree_decl_common'. It is used 9781 to represent 'TRANSLATION_UNIT_DECL'. 9782 9783'struct tree_decl_with_rtl' 9784 This structure inherits from 'struct tree_decl_common'. It 9785 contains a field to store the low-level RTL associated with a 9786 'DECL' node. 9787 9788'struct tree_result_decl' 9789 This structure inherits from 'struct tree_decl_with_rtl'. It is 9790 used to represent 'RESULT_DECL'. 9791 9792'struct tree_const_decl' 9793 This structure inherits from 'struct tree_decl_with_rtl'. It is 9794 used to represent 'CONST_DECL'. 9795 9796'struct tree_parm_decl' 9797 This structure inherits from 'struct tree_decl_with_rtl'. It is 9798 used to represent 'PARM_DECL'. 9799 9800'struct tree_decl_with_vis' 9801 This structure inherits from 'struct tree_decl_with_rtl'. It 9802 contains fields necessary to store visibility information, as well 9803 as a section name and assembler name. 9804 9805'struct tree_var_decl' 9806 This structure inherits from 'struct tree_decl_with_vis'. It is 9807 used to represent 'VAR_DECL'. 9808 9809'struct tree_function_decl' 9810 This structure inherits from 'struct tree_decl_with_vis'. It is 9811 used to represent 'FUNCTION_DECL'. 9812 9813 9814File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure 9815 981611.4.2.2 Adding new DECL node types 9817................................... 9818 9819Adding a new 'DECL' tree consists of the following steps 9820 9821Add a new tree code for the 'DECL' node 9822 For language specific 'DECL' nodes, there is a '.def' file in each 9823 frontend directory where the tree code should be added. For 'DECL' 9824 nodes that are part of the middle-end, the code should be added to 9825 'tree.def'. 9826 9827Create a new structure type for the 'DECL' node 9828 These structures should inherit from one of the existing structures 9829 in the language hierarchy by using that structure as the first 9830 member. 9831 9832 struct tree_foo_decl 9833 { 9834 struct tree_decl_with_vis common; 9835 } 9836 9837 Would create a structure name 'tree_foo_decl' that inherits from 9838 'struct tree_decl_with_vis'. 9839 9840 For language specific 'DECL' nodes, this new structure type should 9841 go in the appropriate '.h' file. For 'DECL' nodes that are part of 9842 the middle-end, the structure type should go in 'tree.h'. 9843 9844Add a member to the tree structure enumerator for the node 9845 For garbage collection and dynamic checking purposes, each 'DECL' 9846 node structure type is required to have a unique enumerator value 9847 specified with it. For language specific 'DECL' nodes, this new 9848 enumerator value should go in the appropriate '.def' file. For 9849 'DECL' nodes that are part of the middle-end, the enumerator values 9850 are specified in 'treestruct.def'. 9851 9852Update 'union tree_node' 9853 In order to make your new structure type usable, it must be added 9854 to 'union tree_node'. For language specific 'DECL' nodes, a new 9855 entry should be added to the appropriate '.h' file of the form 9856 struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl; 9857 For 'DECL' nodes that are part of the middle-end, the additional 9858 member goes directly into 'union tree_node' in 'tree.h'. 9859 9860Update dynamic checking info 9861 In order to be able to check whether accessing a named portion of 9862 'union tree_node' is legal, and whether a certain 'DECL' node 9863 contains one of the enumerated 'DECL' node structures in the 9864 hierarchy, a simple lookup table is used. This lookup table needs 9865 to be kept up to date with the tree structure hierarchy, or else 9866 checking and containment macros will fail inappropriately. 9867 9868 For language specific 'DECL' nodes, their is an 'init_ts' function 9869 in an appropriate '.c' file, which initializes the lookup table. 9870 Code setting up the table for new 'DECL' nodes should be added 9871 there. For each 'DECL' tree code and enumerator value representing 9872 a member of the inheritance hierarchy, the table should contain 1 9873 if that tree code inherits (directly or indirectly) from that 9874 member. Thus, a 'FOO_DECL' node derived from 'struct 9875 decl_with_rtl', and enumerator value 'TS_FOO_DECL', would be set up 9876 as follows 9877 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1; 9878 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1; 9879 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1; 9880 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1; 9881 9882 For 'DECL' nodes that are part of the middle-end, the setup code 9883 goes into 'tree.c'. 9884 9885Add macros to access any new fields and flags 9886 9887 Each added field or flag should have a macro that is used to access 9888 it, that performs appropriate checking to ensure only the right 9889 type of 'DECL' nodes access the field. 9890 9891 These macros generally take the following form 9892 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname 9893 However, if the structure is simply a base class for further 9894 structures, something like the following should be used 9895 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT) 9896 #define BASE_STRUCT_FIELDNAME(NODE) \ 9897 (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname 9898 9899 Reading them from the generated 'all-tree.def' file (which in turn 9900 includes all the 'tree.def' files), 'gencheck.c' is used during 9901 GCC's build to generate the '*_CHECK' macros for all tree codes. 9902 9903 9904File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: GENERIC 9905 990611.5 Attributes in trees 9907======================== 9908 9909Attributes, as specified using the '__attribute__' keyword, are 9910represented internally as a 'TREE_LIST'. The 'TREE_PURPOSE' is the name 9911of the attribute, as an 'IDENTIFIER_NODE'. The 'TREE_VALUE' is a 9912'TREE_LIST' of the arguments of the attribute, if any, or 'NULL_TREE' if 9913there are no arguments; the arguments are stored as the 'TREE_VALUE' of 9914successive entries in the list, and may be identifiers or expressions. 9915The 'TREE_CHAIN' of the attribute is the next attribute in a list of 9916attributes applying to the same declaration or type, or 'NULL_TREE' if 9917there are no further attributes in the list. 9918 9919 Attributes may be attached to declarations and to types; these 9920attributes may be accessed with the following macros. All attributes 9921are stored in this way, and many also cause other changes to the 9922declaration or type or to other internal compiler data structures. 9923 9924 -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL) 9925 This macro returns the attributes on the declaration DECL. 9926 9927 -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE) 9928 This macro returns the attributes on the type TYPE. 9929 9930 9931File: gccint.info, Node: Expression trees, Next: Statements, Prev: Attributes, Up: GENERIC 9932 993311.6 Expressions 9934================ 9935 9936The internal representation for expressions is for the most part quite 9937straightforward. However, there are a few facts that one must bear in 9938mind. In particular, the expression "tree" is actually a directed 9939acyclic graph. (For example there may be many references to the integer 9940constant zero throughout the source program; many of these will be 9941represented by the same expression node.) You should not rely on 9942certain kinds of node being shared, nor should you rely on certain kinds 9943of nodes being unshared. 9944 9945 The following macros can be used with all expression nodes: 9946 9947'TREE_TYPE' 9948 Returns the type of the expression. This value may not be 9949 precisely the same type that would be given the expression in the 9950 original program. 9951 9952 In what follows, some nodes that one might expect to always have type 9953'bool' are documented to have either integral or boolean type. At some 9954point in the future, the C front end may also make use of this same 9955intermediate representation, and at this point these nodes will 9956certainly have integral type. The previous sentence is not meant to 9957imply that the C++ front end does not or will not give these nodes 9958integral type. 9959 9960 Below, we list the various kinds of expression nodes. Except where 9961noted otherwise, the operands to an expression are accessed using the 9962'TREE_OPERAND' macro. For example, to access the first operand to a 9963binary plus expression 'expr', use: 9964 9965 TREE_OPERAND (expr, 0) 9966 9967 As this example indicates, the operands are zero-indexed. 9968 9969* Menu: 9970 9971* Constants: Constant expressions. 9972* Storage References:: 9973* Unary and Binary Expressions:: 9974* Vectors:: 9975 9976 9977File: gccint.info, Node: Constant expressions, Next: Storage References, Up: Expression trees 9978 997911.6.1 Constant expressions 9980--------------------------- 9981 9982The table below begins with constants, moves on to unary expressions, 9983then proceeds to binary expressions, and concludes with various other 9984kinds of expressions: 9985 9986'INTEGER_CST' 9987 These nodes represent integer constants. Note that the type of 9988 these constants is obtained with 'TREE_TYPE'; they are not always 9989 of type 'int'. In particular, 'char' constants are represented 9990 with 'INTEGER_CST' nodes. The value of the integer constant 'e' is 9991 represented in an array of HOST_WIDE_INT. There are enough elements 9992 in the array to represent the value without taking extra elements 9993 for redundant 0s or -1. The number of elements used to represent 9994 'e' is available via 'TREE_INT_CST_NUNITS'. Element 'i' can be 9995 extracted by using 'TREE_INT_CST_ELT (e, i)'. 'TREE_INT_CST_LOW' 9996 is a shorthand for 'TREE_INT_CST_ELT (e, 0)'. 9997 9998 The functions 'tree_fits_shwi_p' and 'tree_fits_uhwi_p' can be used 9999 to tell if the value is small enough to fit in a signed 10000 HOST_WIDE_INT or an unsigned HOST_WIDE_INT respectively. The value 10001 can then be extracted using 'tree_to_shwi' and 'tree_to_uhwi'. 10002 10003'REAL_CST' 10004 10005 FIXME: Talk about how to obtain representations of this constant, 10006 do comparisons, and so forth. 10007 10008'FIXED_CST' 10009 10010 These nodes represent fixed-point constants. The type of these 10011 constants is obtained with 'TREE_TYPE'. 'TREE_FIXED_CST_PTR' 10012 points to a 'struct fixed_value'; 'TREE_FIXED_CST' returns the 10013 structure itself. 'struct fixed_value' contains 'data' with the 10014 size of two 'HOST_BITS_PER_WIDE_INT' and 'mode' as the associated 10015 fixed-point machine mode for 'data'. 10016 10017'COMPLEX_CST' 10018 These nodes are used to represent complex number constants, that is 10019 a '__complex__' whose parts are constant nodes. The 10020 'TREE_REALPART' and 'TREE_IMAGPART' return the real and the 10021 imaginary parts respectively. 10022 10023'VECTOR_CST' 10024 These nodes are used to represent vector constants. Each vector 10025 constant V is treated as a specific instance of an arbitrary-length 10026 sequence that itself contains 'VECTOR_CST_NPATTERNS (V)' 10027 interleaved patterns. Each pattern has the form: 10028 10029 { BASE0, BASE1, BASE1 + STEP, BASE1 + STEP * 2, ... } 10030 10031 The first three elements in each pattern are enough to determine 10032 the values of the other elements. However, if all STEPs are zero, 10033 only the first two elements are needed. If in addition each BASE1 10034 is equal to the corresponding BASE0, only the first element in each 10035 pattern is needed. The number of encoded elements per pattern is 10036 given by 'VECTOR_CST_NELTS_PER_PATTERN (V)'. 10037 10038 For example, the constant: 10039 10040 { 0, 1, 2, 6, 3, 8, 4, 10, 5, 12, 6, 14, 7, 16, 8, 18 } 10041 10042 is interpreted as an interleaving of the sequences: 10043 10044 { 0, 2, 3, 4, 5, 6, 7, 8 } 10045 { 1, 6, 8, 10, 12, 14, 16, 18 } 10046 10047 where the sequences are represented by the following patterns: 10048 10049 BASE0 == 0, BASE1 == 2, STEP == 1 10050 BASE0 == 1, BASE1 == 6, STEP == 2 10051 10052 In this case: 10053 10054 VECTOR_CST_NPATTERNS (V) == 2 10055 VECTOR_CST_NELTS_PER_PATTERN (V) == 3 10056 10057 The vector is therefore encoded using the first 6 elements ('{ 0, 10058 1, 2, 6, 3, 8 }'), with the remaining 10 elements being implicit 10059 extensions of them. 10060 10061 Sometimes this scheme can create two possible encodings of the same 10062 vector. For example { 0, 1 } could be seen as two patterns with 10063 one element each or one pattern with two elements (BASE0 and 10064 BASE1). The canonical encoding is always the one with the fewest 10065 patterns or (if both encodings have the same number of petterns) 10066 the one with the fewest encoded elements. 10067 10068 'vector_cst_encoding_nelts (V)' gives the total number of encoded 10069 elements in V, which is 6 in the example above. 10070 'VECTOR_CST_ENCODED_ELTS (V)' gives a pointer to the elements 10071 encoded in V and 'VECTOR_CST_ENCODED_ELT (V, I)' accesses the value 10072 of encoded element I. 10073 10074 'VECTOR_CST_DUPLICATE_P (V)' is true if V simply contains repeated 10075 instances of 'VECTOR_CST_NPATTERNS (V)' values. This is a 10076 shorthand for testing 'VECTOR_CST_NELTS_PER_PATTERN (V) == 1'. 10077 10078 'VECTOR_CST_STEPPED_P (V)' is true if at least one pattern in V has 10079 a nonzero step. This is a shorthand for testing 10080 'VECTOR_CST_NELTS_PER_PATTERN (V) == 3'. 10081 10082 The utility function 'vector_cst_elt' gives the value of an 10083 arbitrary index as a 'tree'. 'vector_cst_int_elt' gives the same 10084 value as a 'wide_int'. 10085 10086'STRING_CST' 10087 These nodes represent string-constants. The 'TREE_STRING_LENGTH' 10088 returns the length of the string, as an 'int'. The 10089 'TREE_STRING_POINTER' is a 'char*' containing the string itself. 10090 The string may not be 'NUL'-terminated, and it may contain embedded 10091 'NUL' characters. Therefore, the 'TREE_STRING_LENGTH' includes the 10092 trailing 'NUL' if it is present. 10093 10094 For wide string constants, the 'TREE_STRING_LENGTH' is the number 10095 of bytes in the string, and the 'TREE_STRING_POINTER' points to an 10096 array of the bytes of the string, as represented on the target 10097 system (that is, as integers in the target endianness). Wide and 10098 non-wide string constants are distinguished only by the 'TREE_TYPE' 10099 of the 'STRING_CST'. 10100 10101 FIXME: The formats of string constants are not well-defined when 10102 the target system bytes are not the same width as host system 10103 bytes. 10104 10105'POLY_INT_CST' 10106 These nodes represent invariants that depend on some 10107 target-specific runtime parameters. They consist of 10108 'NUM_POLY_INT_COEFFS' coefficients, with the first coefficient 10109 being the constant term and the others being multipliers that are 10110 applied to the runtime parameters. 10111 10112 'POLY_INT_CST_ELT (X, I)' references coefficient number I of 10113 'POLY_INT_CST' node X. Each coefficient is an 'INTEGER_CST'. 10114 10115 10116File: gccint.info, Node: Storage References, Next: Unary and Binary Expressions, Prev: Constant expressions, Up: Expression trees 10117 1011811.6.2 References to storage 10119---------------------------- 10120 10121'ARRAY_REF' 10122 These nodes represent array accesses. The first operand is the 10123 array; the second is the index. To calculate the address of the 10124 memory accessed, you must scale the index by the size of the type 10125 of the array elements. The type of these expressions must be the 10126 type of a component of the array. The third and fourth operands 10127 are used after gimplification to represent the lower bound and 10128 component size but should not be used directly; call 10129 'array_ref_low_bound' and 'array_ref_element_size' instead. 10130 10131'ARRAY_RANGE_REF' 10132 These nodes represent access to a range (or "slice") of an array. 10133 The operands are the same as that for 'ARRAY_REF' and have the same 10134 meanings. The type of these expressions must be an array whose 10135 component type is the same as that of the first operand. The range 10136 of that array type determines the amount of data these expressions 10137 access. 10138 10139'TARGET_MEM_REF' 10140 These nodes represent memory accesses whose address directly map to 10141 an addressing mode of the target architecture. The first argument 10142 is 'TMR_SYMBOL' and must be a 'VAR_DECL' of an object with a fixed 10143 address. The second argument is 'TMR_BASE' and the third one is 10144 'TMR_INDEX'. The fourth argument is 'TMR_STEP' and must be an 10145 'INTEGER_CST'. The fifth argument is 'TMR_OFFSET' and must be an 10146 'INTEGER_CST'. Any of the arguments may be NULL if the appropriate 10147 component does not appear in the address. Address of the 10148 'TARGET_MEM_REF' is determined in the following way. 10149 10150 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET 10151 10152 The sixth argument is the reference to the original memory access, 10153 which is preserved for the purposes of the RTL alias analysis. The 10154 seventh argument is a tag representing the results of tree level 10155 alias analysis. 10156 10157'ADDR_EXPR' 10158 These nodes are used to represent the address of an object. (These 10159 expressions will always have pointer or reference type.) The 10160 operand may be another expression, or it may be a declaration. 10161 10162 As an extension, GCC allows users to take the address of a label. 10163 In this case, the operand of the 'ADDR_EXPR' will be a 10164 'LABEL_DECL'. The type of such an expression is 'void*'. 10165 10166 If the object addressed is not an lvalue, a temporary is created, 10167 and the address of the temporary is used. 10168 10169'INDIRECT_REF' 10170 These nodes are used to represent the object pointed to by a 10171 pointer. The operand is the pointer being dereferenced; it will 10172 always have pointer or reference type. 10173 10174'MEM_REF' 10175 These nodes are used to represent the object pointed to by a 10176 pointer offset by a constant. The first operand is the pointer 10177 being dereferenced; it will always have pointer or reference type. 10178 The second operand is a pointer constant. Its type is specifying 10179 the type to be used for type-based alias analysis. 10180 10181'COMPONENT_REF' 10182 These nodes represent non-static data member accesses. The first 10183 operand is the object (rather than a pointer to it); the second 10184 operand is the 'FIELD_DECL' for the data member. The third operand 10185 represents the byte offset of the field, but should not be used 10186 directly; call 'component_ref_field_offset' instead. 10187 10188 10189File: gccint.info, Node: Unary and Binary Expressions, Next: Vectors, Prev: Storage References, Up: Expression trees 10190 1019111.6.3 Unary and Binary Expressions 10192----------------------------------- 10193 10194'NEGATE_EXPR' 10195 These nodes represent unary negation of the single operand, for 10196 both integer and floating-point types. The type of negation can be 10197 determined by looking at the type of the expression. 10198 10199 The behavior of this operation on signed arithmetic overflow is 10200 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 10201 10202'ABS_EXPR' 10203 These nodes represent the absolute value of the single operand, for 10204 both integer and floating-point types. This is typically used to 10205 implement the 'abs', 'labs' and 'llabs' builtins for integer types, 10206 and the 'fabs', 'fabsf' and 'fabsl' builtins for floating point 10207 types. The type of abs operation can be determined by looking at 10208 the type of the expression. 10209 10210 This node is not used for complex types. To represent the modulus 10211 or complex abs of a complex value, use the 'BUILT_IN_CABS', 10212 'BUILT_IN_CABSF' or 'BUILT_IN_CABSL' builtins, as used to implement 10213 the C99 'cabs', 'cabsf' and 'cabsl' built-in functions. 10214 10215'ABSU_EXPR' 10216 These nodes represent the absolute value of the single operand in 10217 equivalent unsigned type such that 'ABSU_EXPR' of TYPE_MIN is well 10218 defined. 10219 10220'BIT_NOT_EXPR' 10221 These nodes represent bitwise complement, and will always have 10222 integral type. The only operand is the value to be complemented. 10223 10224'TRUTH_NOT_EXPR' 10225 These nodes represent logical negation, and will always have 10226 integral (or boolean) type. The operand is the value being 10227 negated. The type of the operand and that of the result are always 10228 of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'. 10229 10230'PREDECREMENT_EXPR' 10231'PREINCREMENT_EXPR' 10232'POSTDECREMENT_EXPR' 10233'POSTINCREMENT_EXPR' 10234 These nodes represent increment and decrement expressions. The 10235 value of the single operand is computed, and the operand 10236 incremented or decremented. In the case of 'PREDECREMENT_EXPR' and 10237 'PREINCREMENT_EXPR', the value of the expression is the value 10238 resulting after the increment or decrement; in the case of 10239 'POSTDECREMENT_EXPR' and 'POSTINCREMENT_EXPR' is the value before 10240 the increment or decrement occurs. The type of the operand, like 10241 that of the result, will be either integral, boolean, or 10242 floating-point. 10243 10244'FIX_TRUNC_EXPR' 10245 These nodes represent conversion of a floating-point value to an 10246 integer. The single operand will have a floating-point type, while 10247 the complete expression will have an integral (or boolean) type. 10248 The operand is rounded towards zero. 10249 10250'FLOAT_EXPR' 10251 These nodes represent conversion of an integral (or boolean) value 10252 to a floating-point value. The single operand will have integral 10253 type, while the complete expression will have a floating-point 10254 type. 10255 10256 FIXME: How is the operand supposed to be rounded? Is this 10257 dependent on '-mieee'? 10258 10259'COMPLEX_EXPR' 10260 These nodes are used to represent complex numbers constructed from 10261 two expressions of the same (integer or real) type. The first 10262 operand is the real part and the second operand is the imaginary 10263 part. 10264 10265'CONJ_EXPR' 10266 These nodes represent the conjugate of their operand. 10267 10268'REALPART_EXPR' 10269'IMAGPART_EXPR' 10270 These nodes represent respectively the real and the imaginary parts 10271 of complex numbers (their sole argument). 10272 10273'NON_LVALUE_EXPR' 10274 These nodes indicate that their one and only operand is not an 10275 lvalue. A back end can treat these identically to the single 10276 operand. 10277 10278'NOP_EXPR' 10279 These nodes are used to represent conversions that do not require 10280 any code-generation. For example, conversion of a 'char*' to an 10281 'int*' does not require any code be generated; such a conversion is 10282 represented by a 'NOP_EXPR'. The single operand is the expression 10283 to be converted. The conversion from a pointer to a reference is 10284 also represented with a 'NOP_EXPR'. 10285 10286'CONVERT_EXPR' 10287 These nodes are similar to 'NOP_EXPR's, but are used in those 10288 situations where code may need to be generated. For example, if an 10289 'int*' is converted to an 'int' code may need to be generated on 10290 some platforms. These nodes are never used for C++-specific 10291 conversions, like conversions between pointers to different classes 10292 in an inheritance hierarchy. Any adjustments that need to be made 10293 in such cases are always indicated explicitly. Similarly, a 10294 user-defined conversion is never represented by a 'CONVERT_EXPR'; 10295 instead, the function calls are made explicit. 10296 10297'FIXED_CONVERT_EXPR' 10298 These nodes are used to represent conversions that involve 10299 fixed-point values. For example, from a fixed-point value to 10300 another fixed-point value, from an integer to a fixed-point value, 10301 from a fixed-point value to an integer, from a floating-point value 10302 to a fixed-point value, or from a fixed-point value to a 10303 floating-point value. 10304 10305'LSHIFT_EXPR' 10306'RSHIFT_EXPR' 10307 These nodes represent left and right shifts, respectively. The 10308 first operand is the value to shift; it will always be of integral 10309 type. The second operand is an expression for the number of bits 10310 by which to shift. Right shift should be treated as arithmetic, 10311 i.e., the high-order bits should be zero-filled when the expression 10312 has unsigned type and filled with the sign bit when the expression 10313 has signed type. Note that the result is undefined if the second 10314 operand is larger than or equal to the first operand's type size. 10315 Unlike most nodes, these can have a vector as first operand and a 10316 scalar as second operand. 10317 10318'BIT_IOR_EXPR' 10319'BIT_XOR_EXPR' 10320'BIT_AND_EXPR' 10321 These nodes represent bitwise inclusive or, bitwise exclusive or, 10322 and bitwise and, respectively. Both operands will always have 10323 integral type. 10324 10325'TRUTH_ANDIF_EXPR' 10326'TRUTH_ORIF_EXPR' 10327 These nodes represent logical "and" and logical "or", respectively. 10328 These operators are not strict; i.e., the second operand is 10329 evaluated only if the value of the expression is not determined by 10330 evaluation of the first operand. The type of the operands and that 10331 of the result are always of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'. 10332 10333'TRUTH_AND_EXPR' 10334'TRUTH_OR_EXPR' 10335'TRUTH_XOR_EXPR' 10336 These nodes represent logical and, logical or, and logical 10337 exclusive or. They are strict; both arguments are always 10338 evaluated. There are no corresponding operators in C or C++, but 10339 the front end will sometimes generate these expressions anyhow, if 10340 it can tell that strictness does not matter. The type of the 10341 operands and that of the result are always of 'BOOLEAN_TYPE' or 10342 'INTEGER_TYPE'. 10343 10344'POINTER_PLUS_EXPR' 10345 This node represents pointer arithmetic. The first operand is 10346 always a pointer/reference type. The second operand is always an 10347 unsigned integer type compatible with sizetype. This and 10348 POINTER_DIFF_EXPR are the only binary arithmetic operators that can 10349 operate on pointer types. 10350 10351'POINTER_DIFF_EXPR' 10352 This node represents pointer subtraction. The two operands always 10353 have pointer/reference type. It returns a signed integer of the 10354 same precision as the pointers. The behavior is undefined if the 10355 difference of the two pointers, seen as infinite precision 10356 non-negative integers, does not fit in the result type. The result 10357 does not depend on the pointer type, it is not divided by the size 10358 of the pointed-to type. 10359 10360'PLUS_EXPR' 10361'MINUS_EXPR' 10362'MULT_EXPR' 10363 These nodes represent various binary arithmetic operations. 10364 Respectively, these operations are addition, subtraction (of the 10365 second operand from the first) and multiplication. Their operands 10366 may have either integral or floating type, but there will never be 10367 case in which one operand is of floating type and the other is of 10368 integral type. 10369 10370 The behavior of these operations on signed arithmetic overflow is 10371 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 10372 10373'MULT_HIGHPART_EXPR' 10374 This node represents the "high-part" of a widening multiplication. 10375 For an integral type with B bits of precision, the result is the 10376 most significant B bits of the full 2B product. 10377 10378'RDIV_EXPR' 10379 This node represents a floating point division operation. 10380 10381'TRUNC_DIV_EXPR' 10382'FLOOR_DIV_EXPR' 10383'CEIL_DIV_EXPR' 10384'ROUND_DIV_EXPR' 10385 These nodes represent integer division operations that return an 10386 integer result. 'TRUNC_DIV_EXPR' rounds towards zero, 10387 'FLOOR_DIV_EXPR' rounds towards negative infinity, 'CEIL_DIV_EXPR' 10388 rounds towards positive infinity and 'ROUND_DIV_EXPR' rounds to the 10389 closest integer. Integer division in C and C++ is truncating, i.e. 10390 'TRUNC_DIV_EXPR'. 10391 10392 The behavior of these operations on signed arithmetic overflow, 10393 when dividing the minimum signed integer by minus one, is 10394 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 10395 10396'TRUNC_MOD_EXPR' 10397'FLOOR_MOD_EXPR' 10398'CEIL_MOD_EXPR' 10399'ROUND_MOD_EXPR' 10400 These nodes represent the integer remainder or modulus operation. 10401 The integer modulus of two operands 'a' and 'b' is defined as 'a - 10402 (a/b)*b' where the division calculated using the corresponding 10403 division operator. Hence for 'TRUNC_MOD_EXPR' this definition 10404 assumes division using truncation towards zero, i.e. 10405 'TRUNC_DIV_EXPR'. Integer remainder in C and C++ uses truncating 10406 division, i.e. 'TRUNC_MOD_EXPR'. 10407 10408'EXACT_DIV_EXPR' 10409 The 'EXACT_DIV_EXPR' code is used to represent integer divisions 10410 where the numerator is known to be an exact multiple of the 10411 denominator. This allows the backend to choose between the faster 10412 of 'TRUNC_DIV_EXPR', 'CEIL_DIV_EXPR' and 'FLOOR_DIV_EXPR' for the 10413 current target. 10414 10415'LT_EXPR' 10416'LE_EXPR' 10417'GT_EXPR' 10418'GE_EXPR' 10419'EQ_EXPR' 10420'NE_EXPR' 10421 These nodes represent the less than, less than or equal to, greater 10422 than, greater than or equal to, equal, and not equal comparison 10423 operators. The first and second operands will either be both of 10424 integral type, both of floating type or both of vector type. The 10425 result type of these expressions will always be of integral, 10426 boolean or signed integral vector type. These operations return 10427 the result type's zero value for false, the result type's one value 10428 for true, and a vector whose elements are zero (false) or minus one 10429 (true) for vectors. 10430 10431 For floating point comparisons, if we honor IEEE NaNs and either 10432 operand is NaN, then 'NE_EXPR' always returns true and the 10433 remaining operators always return false. On some targets, 10434 comparisons against an IEEE NaN, other than equality and 10435 inequality, may generate a floating point exception. 10436 10437'ORDERED_EXPR' 10438'UNORDERED_EXPR' 10439 These nodes represent non-trapping ordered and unordered comparison 10440 operators. These operations take two floating point operands and 10441 determine whether they are ordered or unordered relative to each 10442 other. If either operand is an IEEE NaN, their comparison is 10443 defined to be unordered, otherwise the comparison is defined to be 10444 ordered. The result type of these expressions will always be of 10445 integral or boolean type. These operations return the result 10446 type's zero value for false, and the result type's one value for 10447 true. 10448 10449'UNLT_EXPR' 10450'UNLE_EXPR' 10451'UNGT_EXPR' 10452'UNGE_EXPR' 10453'UNEQ_EXPR' 10454'LTGT_EXPR' 10455 These nodes represent the unordered comparison operators. These 10456 operations take two floating point operands and determine whether 10457 the operands are unordered or are less than, less than or equal to, 10458 greater than, greater than or equal to, or equal respectively. For 10459 example, 'UNLT_EXPR' returns true if either operand is an IEEE NaN 10460 or the first operand is less than the second. With the possible 10461 exception of 'LTGT_EXPR', all of these operations are guaranteed 10462 not to generate a floating point exception. The result type of 10463 these expressions will always be of integral or boolean type. 10464 These operations return the result type's zero value for false, and 10465 the result type's one value for true. 10466 10467'MODIFY_EXPR' 10468 These nodes represent assignment. The left-hand side is the first 10469 operand; the right-hand side is the second operand. The left-hand 10470 side will be a 'VAR_DECL', 'INDIRECT_REF', 'COMPONENT_REF', or 10471 other lvalue. 10472 10473 These nodes are used to represent not only assignment with '=' but 10474 also compound assignments (like '+='), by reduction to '=' 10475 assignment. In other words, the representation for 'i += 3' looks 10476 just like that for 'i = i + 3'. 10477 10478'INIT_EXPR' 10479 These nodes are just like 'MODIFY_EXPR', but are used only when a 10480 variable is initialized, rather than assigned to subsequently. 10481 This means that we can assume that the target of the initialization 10482 is not used in computing its own value; any reference to the lhs in 10483 computing the rhs is undefined. 10484 10485'COMPOUND_EXPR' 10486 These nodes represent comma-expressions. The first operand is an 10487 expression whose value is computed and thrown away prior to the 10488 evaluation of the second operand. The value of the entire 10489 expression is the value of the second operand. 10490 10491'COND_EXPR' 10492 These nodes represent '?:' expressions. The first operand is of 10493 boolean or integral type. If it evaluates to a nonzero value, the 10494 second operand should be evaluated, and returned as the value of 10495 the expression. Otherwise, the third operand is evaluated, and 10496 returned as the value of the expression. 10497 10498 The second operand must have the same type as the entire 10499 expression, unless it unconditionally throws an exception or calls 10500 a noreturn function, in which case it should have void type. The 10501 same constraints apply to the third operand. This allows array 10502 bounds checks to be represented conveniently as '(i >= 0 && i < 10) 10503 ? i : abort()'. 10504 10505 As a GNU extension, the C language front-ends allow the second 10506 operand of the '?:' operator may be omitted in the source. For 10507 example, 'x ? : 3' is equivalent to 'x ? x : 3', assuming that 'x' 10508 is an expression without side effects. In the tree representation, 10509 however, the second operand is always present, possibly protected 10510 by 'SAVE_EXPR' if the first argument does cause side effects. 10511 10512'CALL_EXPR' 10513 These nodes are used to represent calls to functions, including 10514 non-static member functions. 'CALL_EXPR's are implemented as 10515 expression nodes with a variable number of operands. Rather than 10516 using 'TREE_OPERAND' to extract them, it is preferable to use the 10517 specialized accessor macros and functions that operate specifically 10518 on 'CALL_EXPR' nodes. 10519 10520 'CALL_EXPR_FN' returns a pointer to the function to call; it is 10521 always an expression whose type is a 'POINTER_TYPE'. 10522 10523 The number of arguments to the call is returned by 10524 'call_expr_nargs', while the arguments themselves can be accessed 10525 with the 'CALL_EXPR_ARG' macro. The arguments are zero-indexed and 10526 numbered left-to-right. You can iterate over the arguments using 10527 'FOR_EACH_CALL_EXPR_ARG', as in: 10528 10529 tree call, arg; 10530 call_expr_arg_iterator iter; 10531 FOR_EACH_CALL_EXPR_ARG (arg, iter, call) 10532 /* arg is bound to successive arguments of call. */ 10533 ...; 10534 10535 For non-static member functions, there will be an operand 10536 corresponding to the 'this' pointer. There will always be 10537 expressions corresponding to all of the arguments, even if the 10538 function is declared with default arguments and some arguments are 10539 not explicitly provided at the call sites. 10540 10541 'CALL_EXPR's also have a 'CALL_EXPR_STATIC_CHAIN' operand that is 10542 used to implement nested functions. This operand is otherwise 10543 null. 10544 10545'CLEANUP_POINT_EXPR' 10546 These nodes represent full-expressions. The single operand is an 10547 expression to evaluate. Any destructor calls engendered by the 10548 creation of temporaries during the evaluation of that expression 10549 should be performed immediately after the expression is evaluated. 10550 10551'CONSTRUCTOR' 10552 These nodes represent the brace-enclosed initializers for a 10553 structure or an array. They contain a sequence of component values 10554 made out of a vector of constructor_elt, which is a ('INDEX', 10555 'VALUE') pair. 10556 10557 If the 'TREE_TYPE' of the 'CONSTRUCTOR' is a 'RECORD_TYPE', 10558 'UNION_TYPE' or 'QUAL_UNION_TYPE' then the 'INDEX' of each node in 10559 the sequence will be a 'FIELD_DECL' and the 'VALUE' will be the 10560 expression used to initialize that field. 10561 10562 If the 'TREE_TYPE' of the 'CONSTRUCTOR' is an 'ARRAY_TYPE', then 10563 the 'INDEX' of each node in the sequence will be an 'INTEGER_CST' 10564 or a 'RANGE_EXPR' of two 'INTEGER_CST's. A single 'INTEGER_CST' 10565 indicates which element of the array is being assigned to. A 10566 'RANGE_EXPR' indicates an inclusive range of elements to 10567 initialize. In both cases the 'VALUE' is the corresponding 10568 initializer. It is re-evaluated for each element of a 10569 'RANGE_EXPR'. If the 'INDEX' is 'NULL_TREE', then the initializer 10570 is for the next available array element. 10571 10572 In the front end, you should not depend on the fields appearing in 10573 any particular order. However, in the middle end, fields must 10574 appear in declaration order. You should not assume that all fields 10575 will be represented. Unrepresented fields will be cleared 10576 (zeroed), unless the CONSTRUCTOR_NO_CLEARING flag is set, in which 10577 case their value becomes undefined. 10578 10579'COMPOUND_LITERAL_EXPR' 10580 These nodes represent ISO C99 compound literals. The 10581 'COMPOUND_LITERAL_EXPR_DECL_EXPR' is a 'DECL_EXPR' containing an 10582 anonymous 'VAR_DECL' for the unnamed object represented by the 10583 compound literal; the 'DECL_INITIAL' of that 'VAR_DECL' is a 10584 'CONSTRUCTOR' representing the brace-enclosed list of initializers 10585 in the compound literal. That anonymous 'VAR_DECL' can also be 10586 accessed directly by the 'COMPOUND_LITERAL_EXPR_DECL' macro. 10587 10588'SAVE_EXPR' 10589 10590 A 'SAVE_EXPR' represents an expression (possibly involving side 10591 effects) that is used more than once. The side effects should 10592 occur only the first time the expression is evaluated. Subsequent 10593 uses should just reuse the computed value. The first operand to 10594 the 'SAVE_EXPR' is the expression to evaluate. The side effects 10595 should be executed where the 'SAVE_EXPR' is first encountered in a 10596 depth-first preorder traversal of the expression tree. 10597 10598'TARGET_EXPR' 10599 A 'TARGET_EXPR' represents a temporary object. The first operand 10600 is a 'VAR_DECL' for the temporary variable. The second operand is 10601 the initializer for the temporary. The initializer is evaluated 10602 and, if non-void, copied (bitwise) into the temporary. If the 10603 initializer is void, that means that it will perform the 10604 initialization itself. 10605 10606 Often, a 'TARGET_EXPR' occurs on the right-hand side of an 10607 assignment, or as the second operand to a comma-expression which is 10608 itself the right-hand side of an assignment, etc. In this case, we 10609 say that the 'TARGET_EXPR' is "normal"; otherwise, we say it is 10610 "orphaned". For a normal 'TARGET_EXPR' the temporary variable 10611 should be treated as an alias for the left-hand side of the 10612 assignment, rather than as a new temporary variable. 10613 10614 The third operand to the 'TARGET_EXPR', if present, is a 10615 cleanup-expression (i.e., destructor call) for the temporary. If 10616 this expression is orphaned, then this expression must be executed 10617 when the statement containing this expression is complete. These 10618 cleanups must always be executed in the order opposite to that in 10619 which they were encountered. Note that if a temporary is created 10620 on one branch of a conditional operator (i.e., in the second or 10621 third operand to a 'COND_EXPR'), the cleanup must be run only if 10622 that branch is actually executed. 10623 10624'VA_ARG_EXPR' 10625 This node is used to implement support for the C/C++ variable 10626 argument-list mechanism. It represents expressions like 'va_arg 10627 (ap, type)'. Its 'TREE_TYPE' yields the tree representation for 10628 'type' and its sole argument yields the representation for 'ap'. 10629 10630'ANNOTATE_EXPR' 10631 This node is used to attach markers to an expression. The first 10632 operand is the annotated expression, the second is an 'INTEGER_CST' 10633 with a value from 'enum annot_expr_kind', the third is an 10634 'INTEGER_CST'. 10635 10636 10637File: gccint.info, Node: Vectors, Prev: Unary and Binary Expressions, Up: Expression trees 10638 1063911.6.4 Vectors 10640-------------- 10641 10642'VEC_DUPLICATE_EXPR' 10643 This node has a single operand and represents a vector in which 10644 every element is equal to that operand. 10645 10646'VEC_SERIES_EXPR' 10647 This node represents a vector formed from a scalar base and step, 10648 given as the first and second operands respectively. Element I of 10649 the result is equal to 'BASE + I*STEP'. 10650 10651 This node is restricted to integral types, in order to avoid 10652 specifying the rounding behavior for floating-point types. 10653 10654'VEC_LSHIFT_EXPR' 10655'VEC_RSHIFT_EXPR' 10656 These nodes represent whole vector left and right shifts, 10657 respectively. The first operand is the vector to shift; it will 10658 always be of vector type. The second operand is an expression for 10659 the number of bits by which to shift. Note that the result is 10660 undefined if the second operand is larger than or equal to the 10661 first operand's type size. 10662 10663'VEC_WIDEN_MULT_HI_EXPR' 10664'VEC_WIDEN_MULT_LO_EXPR' 10665 These nodes represent widening vector multiplication of the high 10666 and low parts of the two input vectors, respectively. Their 10667 operands are vectors that contain the same number of elements ('N') 10668 of the same integral type. The result is a vector that contains 10669 half as many elements, of an integral type whose size is twice as 10670 wide. In the case of 'VEC_WIDEN_MULT_HI_EXPR' the high 'N/2' 10671 elements of the two vector are multiplied to produce the vector of 10672 'N/2' products. In the case of 'VEC_WIDEN_MULT_LO_EXPR' the low 10673 'N/2' elements of the two vector are multiplied to produce the 10674 vector of 'N/2' products. 10675 10676'VEC_UNPACK_HI_EXPR' 10677'VEC_UNPACK_LO_EXPR' 10678 These nodes represent unpacking of the high and low parts of the 10679 input vector, respectively. The single operand is a vector that 10680 contains 'N' elements of the same integral or floating point type. 10681 The result is a vector that contains half as many elements, of an 10682 integral or floating point type whose size is twice as wide. In 10683 the case of 'VEC_UNPACK_HI_EXPR' the high 'N/2' elements of the 10684 vector are extracted and widened (promoted). In the case of 10685 'VEC_UNPACK_LO_EXPR' the low 'N/2' elements of the vector are 10686 extracted and widened (promoted). 10687 10688'VEC_UNPACK_FLOAT_HI_EXPR' 10689'VEC_UNPACK_FLOAT_LO_EXPR' 10690 These nodes represent unpacking of the high and low parts of the 10691 input vector, where the values are converted from fixed point to 10692 floating point. The single operand is a vector that contains 'N' 10693 elements of the same integral type. The result is a vector that 10694 contains half as many elements of a floating point type whose size 10695 is twice as wide. In the case of 'VEC_UNPACK_FLOAT_HI_EXPR' the 10696 high 'N/2' elements of the vector are extracted, converted and 10697 widened. In the case of 'VEC_UNPACK_FLOAT_LO_EXPR' the low 'N/2' 10698 elements of the vector are extracted, converted and widened. 10699 10700'VEC_UNPACK_FIX_TRUNC_HI_EXPR' 10701'VEC_UNPACK_FIX_TRUNC_LO_EXPR' 10702 These nodes represent unpacking of the high and low parts of the 10703 input vector, where the values are truncated from floating point to 10704 fixed point. The single operand is a vector that contains 'N' 10705 elements of the same floating point type. The result is a vector 10706 that contains half as many elements of an integral type whose size 10707 is twice as wide. In the case of 'VEC_UNPACK_FIX_TRUNC_HI_EXPR' 10708 the high 'N/2' elements of the vector are extracted and converted 10709 with truncation. In the case of 'VEC_UNPACK_FIX_TRUNC_LO_EXPR' the 10710 low 'N/2' elements of the vector are extracted and converted with 10711 truncation. 10712 10713'VEC_PACK_TRUNC_EXPR' 10714 This node represents packing of truncated elements of the two input 10715 vectors into the output vector. Input operands are vectors that 10716 contain the same number of elements of the same integral or 10717 floating point type. The result is a vector that contains twice as 10718 many elements of an integral or floating point type whose size is 10719 half as wide. The elements of the two vectors are demoted and 10720 merged (concatenated) to form the output vector. 10721 10722'VEC_PACK_SAT_EXPR' 10723 This node represents packing of elements of the two input vectors 10724 into the output vector using saturation. Input operands are 10725 vectors that contain the same number of elements of the same 10726 integral type. The result is a vector that contains twice as many 10727 elements of an integral type whose size is half as wide. The 10728 elements of the two vectors are demoted and merged (concatenated) 10729 to form the output vector. 10730 10731'VEC_PACK_FIX_TRUNC_EXPR' 10732 This node represents packing of elements of the two input vectors 10733 into the output vector, where the values are converted from 10734 floating point to fixed point. Input operands are vectors that 10735 contain the same number of elements of a floating point type. The 10736 result is a vector that contains twice as many elements of an 10737 integral type whose size is half as wide. The elements of the two 10738 vectors are merged (concatenated) to form the output vector. 10739 10740'VEC_PACK_FLOAT_EXPR' 10741 This node represents packing of elements of the two input vectors 10742 into the output vector, where the values are converted from fixed 10743 point to floating point. Input operands are vectors that contain 10744 the same number of elements of an integral type. The result is a 10745 vector that contains twice as many elements of floating point type 10746 whose size is half as wide. The elements of the two vectors are 10747 merged (concatenated) to form the output vector. 10748 10749'VEC_COND_EXPR' 10750 These nodes represent '?:' expressions. The three operands must be 10751 vectors of the same size and number of elements. The second and 10752 third operands must have the same type as the entire expression. 10753 The first operand is of signed integral vector type. If an element 10754 of the first operand evaluates to a zero value, the corresponding 10755 element of the result is taken from the third operand. If it 10756 evaluates to a minus one value, it is taken from the second 10757 operand. It should never evaluate to any other value currently, 10758 but optimizations should not rely on that property. In contrast 10759 with a 'COND_EXPR', all operands are always evaluated. 10760 10761'SAD_EXPR' 10762 This node represents the Sum of Absolute Differences operation. 10763 The three operands must be vectors of integral types. The first 10764 and second operand must have the same type. The size of the vector 10765 element of the third operand must be at lease twice of the size of 10766 the vector element of the first and second one. The SAD is 10767 calculated between the first and second operands, added to the 10768 third operand, and returned. 10769 10770 10771File: gccint.info, Node: Statements, Next: Functions, Prev: Expression trees, Up: GENERIC 10772 1077311.7 Statements 10774=============== 10775 10776Most statements in GIMPLE are assignment statements, represented by 10777'GIMPLE_ASSIGN'. No other C expressions can appear at statement level; 10778a reference to a volatile object is converted into a 'GIMPLE_ASSIGN'. 10779 10780 There are also several varieties of complex statements. 10781 10782* Menu: 10783 10784* Basic Statements:: 10785* Blocks:: 10786* Statement Sequences:: 10787* Empty Statements:: 10788* Jumps:: 10789* Cleanups:: 10790* OpenMP:: 10791* OpenACC:: 10792 10793 10794File: gccint.info, Node: Basic Statements, Next: Blocks, Up: Statements 10795 1079611.7.1 Basic Statements 10797----------------------- 10798 10799'ASM_EXPR' 10800 10801 Used to represent an inline assembly statement. For an inline 10802 assembly statement like: 10803 asm ("mov x, y"); 10804 The 'ASM_STRING' macro will return a 'STRING_CST' node for '"mov x, 10805 y"'. If the original statement made use of the extended-assembly 10806 syntax, then 'ASM_OUTPUTS', 'ASM_INPUTS', and 'ASM_CLOBBERS' will 10807 be the outputs, inputs, and clobbers for the statement, represented 10808 as 'STRING_CST' nodes. The extended-assembly syntax looks like: 10809 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); 10810 The first string is the 'ASM_STRING', containing the instruction 10811 template. The next two strings are the output and inputs, 10812 respectively; this statement has no clobbers. As this example 10813 indicates, "plain" assembly statements are merely a special case of 10814 extended assembly statements; they have no cv-qualifiers, outputs, 10815 inputs, or clobbers. All of the strings will be 'NUL'-terminated, 10816 and will contain no embedded 'NUL'-characters. 10817 10818 If the assembly statement is declared 'volatile', or if the 10819 statement was not an extended assembly statement, and is therefore 10820 implicitly volatile, then the predicate 'ASM_VOLATILE_P' will hold 10821 of the 'ASM_EXPR'. 10822 10823'DECL_EXPR' 10824 10825 Used to represent a local declaration. The 'DECL_EXPR_DECL' macro 10826 can be used to obtain the entity declared. This declaration may be 10827 a 'LABEL_DECL', indicating that the label declared is a local 10828 label. (As an extension, GCC allows the declaration of labels with 10829 scope.) In C, this declaration may be a 'FUNCTION_DECL', 10830 indicating the use of the GCC nested function extension. For more 10831 information, *note Functions::. 10832 10833'LABEL_EXPR' 10834 10835 Used to represent a label. The 'LABEL_DECL' declared by this 10836 statement can be obtained with the 'LABEL_EXPR_LABEL' macro. The 10837 'IDENTIFIER_NODE' giving the name of the label can be obtained from 10838 the 'LABEL_DECL' with 'DECL_NAME'. 10839 10840'GOTO_EXPR' 10841 10842 Used to represent a 'goto' statement. The 'GOTO_DESTINATION' will 10843 usually be a 'LABEL_DECL'. However, if the "computed goto" 10844 extension has been used, the 'GOTO_DESTINATION' will be an 10845 arbitrary expression indicating the destination. This expression 10846 will always have pointer type. 10847 10848'RETURN_EXPR' 10849 10850 Used to represent a 'return' statement. Operand 0 represents the 10851 value to return. It should either be the 'RESULT_DECL' for the 10852 containing function, or a 'MODIFY_EXPR' or 'INIT_EXPR' setting the 10853 function's 'RESULT_DECL'. It will be 'NULL_TREE' if the statement 10854 was just 10855 return; 10856 10857'LOOP_EXPR' 10858 These nodes represent "infinite" loops. The 'LOOP_EXPR_BODY' 10859 represents the body of the loop. It should be executed forever, 10860 unless an 'EXIT_EXPR' is encountered. 10861 10862'EXIT_EXPR' 10863 These nodes represent conditional exits from the nearest enclosing 10864 'LOOP_EXPR'. The single operand is the condition; if it is 10865 nonzero, then the loop should be exited. An 'EXIT_EXPR' will only 10866 appear within a 'LOOP_EXPR'. 10867 10868'SWITCH_STMT' 10869 10870 Used to represent a 'switch' statement. The 'SWITCH_STMT_COND' is 10871 the expression on which the switch is occurring. See the 10872 documentation for an 'IF_STMT' for more information on the 10873 representation used for the condition. The 'SWITCH_STMT_BODY' is 10874 the body of the switch statement. The 'SWITCH_STMT_TYPE' is the 10875 original type of switch expression as given in the source, before 10876 any compiler conversions. 10877 10878'CASE_LABEL_EXPR' 10879 10880 Use to represent a 'case' label, range of 'case' labels, or a 10881 'default' label. If 'CASE_LOW' is 'NULL_TREE', then this is a 10882 'default' label. Otherwise, if 'CASE_HIGH' is 'NULL_TREE', then 10883 this is an ordinary 'case' label. In this case, 'CASE_LOW' is an 10884 expression giving the value of the label. Both 'CASE_LOW' and 10885 'CASE_HIGH' are 'INTEGER_CST' nodes. These values will have the 10886 same type as the condition expression in the switch statement. 10887 10888 Otherwise, if both 'CASE_LOW' and 'CASE_HIGH' are defined, the 10889 statement is a range of case labels. Such statements originate 10890 with the extension that allows users to write things of the form: 10891 case 2 ... 5: 10892 The first value will be 'CASE_LOW', while the second will be 10893 'CASE_HIGH'. 10894 10895'DEBUG_BEGIN_STMT' 10896 10897 Marks the beginning of a source statement, for purposes of debug 10898 information generation. 10899 10900 10901File: gccint.info, Node: Blocks, Next: Statement Sequences, Prev: Basic Statements, Up: Statements 10902 1090311.7.2 Blocks 10904------------- 10905 10906Block scopes and the variables they declare in GENERIC are expressed 10907using the 'BIND_EXPR' code, which in previous versions of GCC was 10908primarily used for the C statement-expression extension. 10909 10910 Variables in a block are collected into 'BIND_EXPR_VARS' in declaration 10911order through their 'TREE_CHAIN' field. Any runtime initialization is 10912moved out of 'DECL_INITIAL' and into a statement in the controlled 10913block. When gimplifying from C or C++, this initialization replaces the 10914'DECL_STMT'. These variables will never require cleanups. The scope of 10915these variables is just the body 10916 10917 Variable-length arrays (VLAs) complicate this process, as their size 10918often refers to variables initialized earlier in the block and their 10919initialization involves an explicit stack allocation. To handle this, 10920we add an indirection and replace them with a pointer to stack space 10921allocated by means of 'alloca'. In most cases, we also arrange for this 10922space to be reclaimed when the enclosing 'BIND_EXPR' is exited, the 10923exception to this being when there is an explicit call to 'alloca' in 10924the source code, in which case the stack is left depressed on exit of 10925the 'BIND_EXPR'. 10926 10927 A C++ program will usually contain more 'BIND_EXPR's than there are 10928syntactic blocks in the source code, since several C++ constructs have 10929implicit scopes associated with them. On the other hand, although the 10930C++ front end uses pseudo-scopes to handle cleanups for objects with 10931destructors, these don't translate into the GIMPLE form; multiple 10932declarations at the same level use the same 'BIND_EXPR'. 10933 10934 10935File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements 10936 1093711.7.3 Statement Sequences 10938-------------------------- 10939 10940Multiple statements at the same nesting level are collected into a 10941'STATEMENT_LIST'. Statement lists are modified and traversed using the 10942interface in 'tree-iterator.h'. 10943 10944 10945File: gccint.info, Node: Empty Statements, Next: Jumps, Prev: Statement Sequences, Up: Statements 10946 1094711.7.4 Empty Statements 10948----------------------- 10949 10950Whenever possible, statements with no effect are discarded. But if they 10951are nested within another construct which cannot be discarded for some 10952reason, they are instead replaced with an empty statement, generated by 10953'build_empty_stmt'. Initially, all empty statements were shared, after 10954the pattern of the Java front end, but this caused a lot of trouble in 10955practice. 10956 10957 An empty statement is represented as '(void)0'. 10958 10959 10960File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Empty Statements, Up: Statements 10961 1096211.7.5 Jumps 10963------------ 10964 10965Other jumps are expressed by either 'GOTO_EXPR' or 'RETURN_EXPR'. 10966 10967 The operand of a 'GOTO_EXPR' must be either a label or a variable 10968containing the address to jump to. 10969 10970 The operand of a 'RETURN_EXPR' is either 'NULL_TREE', 'RESULT_DECL', or 10971a 'MODIFY_EXPR' which sets the return value. It would be nice to move 10972the 'MODIFY_EXPR' into a separate statement, but the special return 10973semantics in 'expand_return' make that difficult. It may still happen 10974in the future, perhaps by moving most of that logic into 10975'expand_assignment'. 10976 10977 10978File: gccint.info, Node: Cleanups, Next: OpenMP, Prev: Jumps, Up: Statements 10979 1098011.7.6 Cleanups 10981--------------- 10982 10983Destructors for local C++ objects and similar dynamic cleanups are 10984represented in GIMPLE by a 'TRY_FINALLY_EXPR'. 'TRY_FINALLY_EXPR' has 10985two operands, both of which are a sequence of statements to execute. 10986The first sequence is executed. When it completes the second sequence 10987is executed. 10988 10989 The first sequence may complete in the following ways: 10990 10991 1. Execute the last statement in the sequence and fall off the end. 10992 10993 2. Execute a goto statement ('GOTO_EXPR') to an ordinary label outside 10994 the sequence. 10995 10996 3. Execute a return statement ('RETURN_EXPR'). 10997 10998 4. Throw an exception. This is currently not explicitly represented 10999 in GIMPLE. 11000 11001 The second sequence is not executed if the first sequence completes by 11002calling 'setjmp' or 'exit' or any other function that does not return. 11003The second sequence is also not executed if the first sequence completes 11004via a non-local goto or a computed goto (in general the compiler does 11005not know whether such a goto statement exits the first sequence or not, 11006so we assume that it doesn't). 11007 11008 After the second sequence is executed, if it completes normally by 11009falling off the end, execution continues wherever the first sequence 11010would have continued, by falling off the end, or doing a goto, etc. 11011 11012 'TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs 11013to appear on every edge out of the controlled block; this reduces the 11014freedom to move code across these edges. Therefore, the EH lowering 11015pass which runs before most of the optimization passes eliminates these 11016expressions by explicitly adding the cleanup to each edge. Rethrowing 11017the exception is represented using 'RESX_EXPR'. 11018 11019 11020File: gccint.info, Node: OpenMP, Next: OpenACC, Prev: Cleanups, Up: Statements 11021 1102211.7.7 OpenMP 11023------------- 11024 11025All the statements starting with 'OMP_' represent directives and clauses 11026used by the OpenMP API <https://www.openmp.org>. 11027 11028'OMP_PARALLEL' 11029 11030 Represents '#pragma omp parallel [clause1 ... clauseN]'. It has 11031 four operands: 11032 11033 Operand 'OMP_PARALLEL_BODY' is valid while in GENERIC and High 11034 GIMPLE forms. It contains the body of code to be executed by all 11035 the threads. During GIMPLE lowering, this operand becomes 'NULL' 11036 and the body is emitted linearly after 'OMP_PARALLEL'. 11037 11038 Operand 'OMP_PARALLEL_CLAUSES' is the list of clauses associated 11039 with the directive. 11040 11041 Operand 'OMP_PARALLEL_FN' is created by 'pass_lower_omp', it 11042 contains the 'FUNCTION_DECL' for the function that will contain the 11043 body of the parallel region. 11044 11045 Operand 'OMP_PARALLEL_DATA_ARG' is also created by 11046 'pass_lower_omp'. If there are shared variables to be communicated 11047 to the children threads, this operand will contain the 'VAR_DECL' 11048 that contains all the shared values and variables. 11049 11050'OMP_FOR' 11051 11052 Represents '#pragma omp for [clause1 ... clauseN]'. It has six 11053 operands: 11054 11055 Operand 'OMP_FOR_BODY' contains the loop body. 11056 11057 Operand 'OMP_FOR_CLAUSES' is the list of clauses associated with 11058 the directive. 11059 11060 Operand 'OMP_FOR_INIT' is the loop initialization code of the form 11061 'VAR = N1'. 11062 11063 Operand 'OMP_FOR_COND' is the loop conditional expression of the 11064 form 'VAR {<,>,<=,>=} N2'. 11065 11066 Operand 'OMP_FOR_INCR' is the loop index increment of the form 'VAR 11067 {+=,-=} INCR'. 11068 11069 Operand 'OMP_FOR_PRE_BODY' contains side effect code from operands 11070 'OMP_FOR_INIT', 'OMP_FOR_COND' and 'OMP_FOR_INC'. These side 11071 effects are part of the 'OMP_FOR' block but must be evaluated 11072 before the start of loop body. 11073 11074 The loop index variable 'VAR' must be a signed integer variable, 11075 which is implicitly private to each thread. Bounds 'N1' and 'N2' 11076 and the increment expression 'INCR' are required to be loop 11077 invariant integer expressions that are evaluated without any 11078 synchronization. The evaluation order, frequency of evaluation and 11079 side effects are unspecified by the standard. 11080 11081'OMP_SECTIONS' 11082 11083 Represents '#pragma omp sections [clause1 ... clauseN]'. 11084 11085 Operand 'OMP_SECTIONS_BODY' contains the sections body, which in 11086 turn contains a set of 'OMP_SECTION' nodes for each of the 11087 concurrent sections delimited by '#pragma omp section'. 11088 11089 Operand 'OMP_SECTIONS_CLAUSES' is the list of clauses associated 11090 with the directive. 11091 11092'OMP_SECTION' 11093 11094 Section delimiter for 'OMP_SECTIONS'. 11095 11096'OMP_SINGLE' 11097 11098 Represents '#pragma omp single'. 11099 11100 Operand 'OMP_SINGLE_BODY' contains the body of code to be executed 11101 by a single thread. 11102 11103 Operand 'OMP_SINGLE_CLAUSES' is the list of clauses associated with 11104 the directive. 11105 11106'OMP_MASTER' 11107 11108 Represents '#pragma omp master'. 11109 11110 Operand 'OMP_MASTER_BODY' contains the body of code to be executed 11111 by the master thread. 11112 11113'OMP_ORDERED' 11114 11115 Represents '#pragma omp ordered'. 11116 11117 Operand 'OMP_ORDERED_BODY' contains the body of code to be executed 11118 in the sequential order dictated by the loop index variable. 11119 11120'OMP_CRITICAL' 11121 11122 Represents '#pragma omp critical [name]'. 11123 11124 Operand 'OMP_CRITICAL_BODY' is the critical section. 11125 11126 Operand 'OMP_CRITICAL_NAME' is an optional identifier to label the 11127 critical section. 11128 11129'OMP_RETURN' 11130 11131 This does not represent any OpenMP directive, it is an artificial 11132 marker to indicate the end of the body of an OpenMP. It is used by 11133 the flow graph ('tree-cfg.c') and OpenMP region building code 11134 ('omp-low.c'). 11135 11136'OMP_CONTINUE' 11137 11138 Similarly, this instruction does not represent an OpenMP directive, 11139 it is used by 'OMP_FOR' (and similar codes) as well as 11140 'OMP_SECTIONS' to mark the place where the code needs to loop to 11141 the next iteration, or the next section, respectively. 11142 11143 In some cases, 'OMP_CONTINUE' is placed right before 'OMP_RETURN'. 11144 But if there are cleanups that need to occur right after the 11145 looping body, it will be emitted between 'OMP_CONTINUE' and 11146 'OMP_RETURN'. 11147 11148'OMP_ATOMIC' 11149 11150 Represents '#pragma omp atomic'. 11151 11152 Operand 0 is the address at which the atomic operation is to be 11153 performed. 11154 11155 Operand 1 is the expression to evaluate. The gimplifier tries 11156 three alternative code generation strategies. Whenever possible, 11157 an atomic update built-in is used. If that fails, a 11158 compare-and-swap loop is attempted. If that also fails, a regular 11159 critical section around the expression is used. 11160 11161'OMP_CLAUSE' 11162 11163 Represents clauses associated with one of the 'OMP_' directives. 11164 Clauses are represented by separate subcodes defined in 'tree.h'. 11165 Clauses codes can be one of: 'OMP_CLAUSE_PRIVATE', 11166 'OMP_CLAUSE_SHARED', 'OMP_CLAUSE_FIRSTPRIVATE', 11167 'OMP_CLAUSE_LASTPRIVATE', 'OMP_CLAUSE_COPYIN', 11168 'OMP_CLAUSE_COPYPRIVATE', 'OMP_CLAUSE_IF', 11169 'OMP_CLAUSE_NUM_THREADS', 'OMP_CLAUSE_SCHEDULE', 11170 'OMP_CLAUSE_NOWAIT', 'OMP_CLAUSE_ORDERED', 'OMP_CLAUSE_DEFAULT', 11171 'OMP_CLAUSE_REDUCTION', 'OMP_CLAUSE_COLLAPSE', 'OMP_CLAUSE_UNTIED', 11172 'OMP_CLAUSE_FINAL', and 'OMP_CLAUSE_MERGEABLE'. Each code 11173 represents the corresponding OpenMP clause. 11174 11175 Clauses associated with the same directive are chained together via 11176 'OMP_CLAUSE_CHAIN'. Those clauses that accept a list of variables 11177 are restricted to exactly one, accessed with 'OMP_CLAUSE_VAR'. 11178 Therefore, multiple variables under the same clause 'C' need to be 11179 represented as multiple 'C' clauses chained together. This 11180 facilitates adding new clauses during compilation. 11181 11182 11183File: gccint.info, Node: OpenACC, Prev: OpenMP, Up: Statements 11184 1118511.7.8 OpenACC 11186-------------- 11187 11188All the statements starting with 'OACC_' represent directives and 11189clauses used by the OpenACC API <https://www.openacc.org>. 11190 11191'OACC_CACHE' 11192 11193 Represents '#pragma acc cache (var ...)'. 11194 11195'OACC_DATA' 11196 11197 Represents '#pragma acc data [clause1 ... clauseN]'. 11198 11199'OACC_DECLARE' 11200 11201 Represents '#pragma acc declare [clause1 ... clauseN]'. 11202 11203'OACC_ENTER_DATA' 11204 11205 Represents '#pragma acc enter data [clause1 ... clauseN]'. 11206 11207'OACC_EXIT_DATA' 11208 11209 Represents '#pragma acc exit data [clause1 ... clauseN]'. 11210 11211'OACC_HOST_DATA' 11212 11213 Represents '#pragma acc host_data [clause1 ... clauseN]'. 11214 11215'OACC_KERNELS' 11216 11217 Represents '#pragma acc kernels [clause1 ... clauseN]'. 11218 11219'OACC_LOOP' 11220 11221 Represents '#pragma acc loop [clause1 ... clauseN]'. 11222 11223 See the description of the 'OMP_FOR' code. 11224 11225'OACC_PARALLEL' 11226 11227 Represents '#pragma acc parallel [clause1 ... clauseN]'. 11228 11229'OACC_UPDATE' 11230 11231 Represents '#pragma acc update [clause1 ... clauseN]'. 11232 11233 11234File: gccint.info, Node: Functions, Next: Language-dependent trees, Prev: Statements, Up: GENERIC 11235 1123611.8 Functions 11237============== 11238 11239A function is represented by a 'FUNCTION_DECL' node. It stores the 11240basic pieces of the function such as body, parameters, and return type 11241as well as information on the surrounding context, visibility, and 11242linkage. 11243 11244* Menu: 11245 11246* Function Basics:: Function names, body, and parameters. 11247* Function Properties:: Context, linkage, etc. 11248 11249 11250File: gccint.info, Node: Function Basics, Next: Function Properties, Up: Functions 11251 1125211.8.1 Function Basics 11253---------------------- 11254 11255A function has four core parts: the name, the parameters, the result, 11256and the body. The following macros and functions access these parts of 11257a 'FUNCTION_DECL' as well as other basic features: 11258'DECL_NAME' 11259 This macro returns the unqualified name of the function, as an 11260 'IDENTIFIER_NODE'. For an instantiation of a function template, 11261 the 'DECL_NAME' is the unqualified name of the template, not 11262 something like 'f<int>'. The value of 'DECL_NAME' is undefined 11263 when used on a constructor, destructor, overloaded operator, or 11264 type-conversion operator, or any function that is implicitly 11265 generated by the compiler. See below for macros that can be used 11266 to distinguish these cases. 11267 11268'DECL_ASSEMBLER_NAME' 11269 This macro returns the mangled name of the function, also an 11270 'IDENTIFIER_NODE'. This name does not contain leading underscores 11271 on systems that prefix all identifiers with underscores. The 11272 mangled name is computed in the same way on all platforms; if 11273 special processing is required to deal with the object file format 11274 used on a particular platform, it is the responsibility of the back 11275 end to perform those modifications. (Of course, the back end 11276 should not modify 'DECL_ASSEMBLER_NAME' itself.) 11277 11278 Using 'DECL_ASSEMBLER_NAME' will cause additional memory to be 11279 allocated (for the mangled name of the entity) so it should be used 11280 only when emitting assembly code. It should not be used within the 11281 optimizers to determine whether or not two declarations are the 11282 same, even though some of the existing optimizers do use it in that 11283 way. These uses will be removed over time. 11284 11285'DECL_ARGUMENTS' 11286 This macro returns the 'PARM_DECL' for the first argument to the 11287 function. Subsequent 'PARM_DECL' nodes can be obtained by 11288 following the 'TREE_CHAIN' links. 11289 11290'DECL_RESULT' 11291 This macro returns the 'RESULT_DECL' for the function. 11292 11293'DECL_SAVED_TREE' 11294 This macro returns the complete body of the function. 11295 11296'TREE_TYPE' 11297 This macro returns the 'FUNCTION_TYPE' or 'METHOD_TYPE' for the 11298 function. 11299 11300'DECL_INITIAL' 11301 A function that has a definition in the current translation unit 11302 will have a non-'NULL' 'DECL_INITIAL'. However, back ends should 11303 not make use of the particular value given by 'DECL_INITIAL'. 11304 11305 It should contain a tree of 'BLOCK' nodes that mirrors the scopes 11306 that variables are bound in the function. Each block contains a 11307 list of decls declared in a basic block, a pointer to a chain of 11308 blocks at the next lower scope level, then a pointer to the next 11309 block at the same level and a backpointer to the parent 'BLOCK' or 11310 'FUNCTION_DECL'. So given a function as follows: 11311 11312 void foo() 11313 { 11314 int a; 11315 { 11316 int b; 11317 } 11318 int c; 11319 } 11320 11321 you would get the following: 11322 11323 tree foo = FUNCTION_DECL; 11324 tree decl_a = VAR_DECL; 11325 tree decl_b = VAR_DECL; 11326 tree decl_c = VAR_DECL; 11327 tree block_a = BLOCK; 11328 tree block_b = BLOCK; 11329 tree block_c = BLOCK; 11330 BLOCK_VARS(block_a) = decl_a; 11331 BLOCK_SUBBLOCKS(block_a) = block_b; 11332 BLOCK_CHAIN(block_a) = block_c; 11333 BLOCK_SUPERCONTEXT(block_a) = foo; 11334 BLOCK_VARS(block_b) = decl_b; 11335 BLOCK_SUPERCONTEXT(block_b) = block_a; 11336 BLOCK_VARS(block_c) = decl_c; 11337 BLOCK_SUPERCONTEXT(block_c) = foo; 11338 DECL_INITIAL(foo) = block_a; 11339 11340 11341File: gccint.info, Node: Function Properties, Prev: Function Basics, Up: Functions 11342 1134311.8.2 Function Properties 11344-------------------------- 11345 11346To determine the scope of a function, you can use the 'DECL_CONTEXT' 11347macro. This macro will return the class (either a 'RECORD_TYPE' or a 11348'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is 11349a member. For a virtual function, this macro returns the class in which 11350the function was actually defined, not the base class in which the 11351virtual declaration occurred. 11352 11353 In C, the 'DECL_CONTEXT' for a function maybe another function. This 11354representation indicates that the GNU nested function extension is in 11355use. For details on the semantics of nested functions, see the GCC 11356Manual. The nested function can refer to local variables in its 11357containing function. Such references are not explicitly marked in the 11358tree structure; back ends must look at the 'DECL_CONTEXT' for the 11359referenced 'VAR_DECL'. If the 'DECL_CONTEXT' for the referenced 11360'VAR_DECL' is not the same as the function currently being processed, 11361and neither 'DECL_EXTERNAL' nor 'TREE_STATIC' hold, then the reference 11362is to a local variable in a containing function, and the back end must 11363take appropriate action. 11364 11365'DECL_EXTERNAL' 11366 This predicate holds if the function is undefined. 11367 11368'TREE_PUBLIC' 11369 This predicate holds if the function has external linkage. 11370 11371'TREE_STATIC' 11372 This predicate holds if the function has been defined. 11373 11374'TREE_THIS_VOLATILE' 11375 This predicate holds if the function does not return normally. 11376 11377'TREE_READONLY' 11378 This predicate holds if the function can only read its arguments. 11379 11380'DECL_PURE_P' 11381 This predicate holds if the function can only read its arguments, 11382 but may also read global memory. 11383 11384'DECL_VIRTUAL_P' 11385 This predicate holds if the function is virtual. 11386 11387'DECL_ARTIFICIAL' 11388 This macro holds if the function was implicitly generated by the 11389 compiler, rather than explicitly declared. In addition to 11390 implicitly generated class member functions, this macro holds for 11391 the special functions created to implement static initialization 11392 and destruction, to compute run-time type information, and so 11393 forth. 11394 11395'DECL_FUNCTION_SPECIFIC_TARGET' 11396 This macro returns a tree node that holds the target options that 11397 are to be used to compile this particular function or 'NULL_TREE' 11398 if the function is to be compiled with the target options specified 11399 on the command line. 11400 11401'DECL_FUNCTION_SPECIFIC_OPTIMIZATION' 11402 This macro returns a tree node that holds the optimization options 11403 that are to be used to compile this particular function or 11404 'NULL_TREE' if the function is to be compiled with the optimization 11405 options specified on the command line. 11406 11407 11408File: gccint.info, Node: Language-dependent trees, Next: C and C++ Trees, Prev: Functions, Up: GENERIC 11409 1141011.9 Language-dependent trees 11411============================= 11412 11413Front ends may wish to keep some state associated with various GENERIC 11414trees while parsing. To support this, trees provide a set of flags that 11415may be used by the front end. They are accessed using 11416'TREE_LANG_FLAG_n' where 'n' is currently 0 through 6. 11417 11418 If necessary, a front end can use some language-dependent tree codes in 11419its GENERIC representation, so long as it provides a hook for converting 11420them to GIMPLE and doesn't expect them to work with any (hypothetical) 11421optimizers that run before the conversion to GIMPLE. The intermediate 11422representation used while parsing C and C++ looks very little like 11423GENERIC, but the C and C++ gimplifier hooks are perfectly happy to take 11424it as input and spit out GIMPLE. 11425 11426 11427File: gccint.info, Node: C and C++ Trees, Next: Java Trees, Prev: Language-dependent trees, Up: GENERIC 11428 1142911.10 C and C++ Trees 11430===================== 11431 11432This section documents the internal representation used by GCC to 11433represent C and C++ source programs. When presented with a C or C++ 11434source program, GCC parses the program, performs semantic analysis 11435(including the generation of error messages), and then produces the 11436internal representation described here. This representation contains a 11437complete representation for the entire translation unit provided as 11438input to the front end. This representation is then typically processed 11439by a code-generator in order to produce machine code, but could also be 11440used in the creation of source browsers, intelligent editors, automatic 11441documentation generators, interpreters, and any other programs needing 11442the ability to process C or C++ code. 11443 11444 This section explains the internal representation. In particular, it 11445documents the internal representation for C and C++ source constructs, 11446and the macros, functions, and variables that can be used to access 11447these constructs. The C++ representation is largely a superset of the 11448representation used in the C front end. There is only one construct 11449used in C that does not appear in the C++ front end and that is the GNU 11450"nested function" extension. Many of the macros documented here do not 11451apply in C because the corresponding language constructs do not appear 11452in C. 11453 11454 The C and C++ front ends generate a mix of GENERIC trees and ones 11455specific to C and C++. These language-specific trees are higher-level 11456constructs than the ones in GENERIC to make the parser's job easier. 11457This section describes those trees that aren't part of GENERIC as well 11458as aspects of GENERIC trees that are treated in a language-specific 11459manner. 11460 11461 If you are developing a "back end", be it is a code-generator or some 11462other tool, that uses this representation, you may occasionally find 11463that you need to ask questions not easily answered by the functions and 11464macros available here. If that situation occurs, it is quite likely 11465that GCC already supports the functionality you desire, but that the 11466interface is simply not documented here. In that case, you should ask 11467the GCC maintainers (via mail to <gcc@gcc.gnu.org>) about documenting 11468the functionality you require. Similarly, if you find yourself writing 11469functions that do not deal directly with your back end, but instead 11470might be useful to other people using the GCC front end, you should 11471submit your patches for inclusion in GCC. 11472 11473* Menu: 11474 11475* Types for C++:: Fundamental and aggregate types. 11476* Namespaces:: Namespaces. 11477* Classes:: Classes. 11478* Functions for C++:: Overloading and accessors for C++. 11479* Statements for C++:: Statements specific to C and C++. 11480* C++ Expressions:: From 'typeid' to 'throw'. 11481 11482 11483File: gccint.info, Node: Types for C++, Next: Namespaces, Up: C and C++ Trees 11484 1148511.10.1 Types for C++ 11486--------------------- 11487 11488In C++, an array type is not qualified; rather the type of the array 11489elements is qualified. This situation is reflected in the intermediate 11490representation. The macros described here will always examine the 11491qualification of the underlying element type when applied to an array 11492type. (If the element type is itself an array, then the recursion 11493continues until a non-array type is found, and the qualification of this 11494type is examined.) So, for example, 'CP_TYPE_CONST_P' will hold of the 11495type 'const int ()[7]', denoting an array of seven 'int's. 11496 11497 The following functions and macros deal with cv-qualification of types: 11498'cp_type_quals' 11499 This function returns the set of type qualifiers applied to this 11500 type. This value is 'TYPE_UNQUALIFIED' if no qualifiers have been 11501 applied. The 'TYPE_QUAL_CONST' bit is set if the type is 11502 'const'-qualified. The 'TYPE_QUAL_VOLATILE' bit is set if the type 11503 is 'volatile'-qualified. The 'TYPE_QUAL_RESTRICT' bit is set if 11504 the type is 'restrict'-qualified. 11505 11506'CP_TYPE_CONST_P' 11507 This macro holds if the type is 'const'-qualified. 11508 11509'CP_TYPE_VOLATILE_P' 11510 This macro holds if the type is 'volatile'-qualified. 11511 11512'CP_TYPE_RESTRICT_P' 11513 This macro holds if the type is 'restrict'-qualified. 11514 11515'CP_TYPE_CONST_NON_VOLATILE_P' 11516 This predicate holds for a type that is 'const'-qualified, but 11517 _not_ 'volatile'-qualified; other cv-qualifiers are ignored as 11518 well: only the 'const'-ness is tested. 11519 11520 A few other macros and functions are usable with all types: 11521'TYPE_SIZE' 11522 The number of bits required to represent the type, represented as 11523 an 'INTEGER_CST'. For an incomplete type, 'TYPE_SIZE' will be 11524 'NULL_TREE'. 11525 11526'TYPE_ALIGN' 11527 The alignment of the type, in bits, represented as an 'int'. 11528 11529'TYPE_NAME' 11530 This macro returns a declaration (in the form of a 'TYPE_DECL') for 11531 the type. (Note this macro does _not_ return an 'IDENTIFIER_NODE', 11532 as you might expect, given its name!) You can look at the 11533 'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the 11534 type. The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a 11535 built-in type, the result of a typedef, or a named class type. 11536 11537'CP_INTEGRAL_TYPE' 11538 This predicate holds if the type is an integral type. Notice that 11539 in C++, enumerations are _not_ integral types. 11540 11541'ARITHMETIC_TYPE_P' 11542 This predicate holds if the type is an integral type (in the C++ 11543 sense) or a floating point type. 11544 11545'CLASS_TYPE_P' 11546 This predicate holds for a class-type. 11547 11548'TYPE_BUILT_IN' 11549 This predicate holds for a built-in type. 11550 11551'TYPE_PTRDATAMEM_P' 11552 This predicate holds if the type is a pointer to data member. 11553 11554'TYPE_PTR_P' 11555 This predicate holds if the type is a pointer type, and the pointee 11556 is not a data member. 11557 11558'TYPE_PTRFN_P' 11559 This predicate holds for a pointer to function type. 11560 11561'TYPE_PTROB_P' 11562 This predicate holds for a pointer to object type. Note however 11563 that it does not hold for the generic pointer to object type 'void 11564 *'. You may use 'TYPE_PTROBV_P' to test for a pointer to object 11565 type as well as 'void *'. 11566 11567 The table below describes types specific to C and C++ as well as 11568language-dependent info about GENERIC types. 11569 11570'POINTER_TYPE' 11571 Used to represent pointer types, and pointer to data member types. 11572 If 'TREE_TYPE' is a pointer to data member type, then 11573 'TYPE_PTRDATAMEM_P' will hold. For a pointer to data member type 11574 of the form 'T X::*', 'TYPE_PTRMEM_CLASS_TYPE' will be the type 11575 'X', while 'TYPE_PTRMEM_POINTED_TO_TYPE' will be the type 'T'. 11576 11577'RECORD_TYPE' 11578 Used to represent 'struct' and 'class' types in C and C++. If 11579 'TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member 11580 type. In that case, the 'TYPE_PTRMEMFUNC_FN_TYPE' is a 11581 'POINTER_TYPE' pointing to a 'METHOD_TYPE'. The 'METHOD_TYPE' is 11582 the type of a function pointed to by the pointer-to-member 11583 function. If 'TYPE_PTRMEMFUNC_P' does not hold, this type is a 11584 class type. For more information, *note Classes::. 11585 11586'UNKNOWN_TYPE' 11587 This node is used to represent a type the knowledge of which is 11588 insufficient for a sound processing. 11589 11590'TYPENAME_TYPE' 11591 Used to represent a construct of the form 'typename T::A'. The 11592 'TYPE_CONTEXT' is 'T'; the 'TYPE_NAME' is an 'IDENTIFIER_NODE' for 11593 'A'. If the type is specified via a template-id, then 11594 'TYPENAME_TYPE_FULLNAME' yields a 'TEMPLATE_ID_EXPR'. The 11595 'TREE_TYPE' is non-'NULL' if the node is implicitly generated in 11596 support for the implicit typename extension; in which case the 11597 'TREE_TYPE' is a type node for the base-class. 11598 11599'TYPEOF_TYPE' 11600 Used to represent the '__typeof__' extension. The 'TYPE_FIELDS' is 11601 the expression the type of which is being represented. 11602 11603 11604File: gccint.info, Node: Namespaces, Next: Classes, Prev: Types for C++, Up: C and C++ Trees 11605 1160611.10.2 Namespaces 11607------------------ 11608 11609The root of the entire intermediate representation is the variable 11610'global_namespace'. This is the namespace specified with '::' in C++ 11611source code. All other namespaces, types, variables, functions, and so 11612forth can be found starting with this namespace. 11613 11614 However, except for the fact that it is distinguished as the root of 11615the representation, the global namespace is no different from any other 11616namespace. Thus, in what follows, we describe namespaces generally, 11617rather than the global namespace in particular. 11618 11619 A namespace is represented by a 'NAMESPACE_DECL' node. 11620 11621 The following macros and functions can be used on a 'NAMESPACE_DECL': 11622 11623'DECL_NAME' 11624 This macro is used to obtain the 'IDENTIFIER_NODE' corresponding to 11625 the unqualified name of the name of the namespace (*note 11626 Identifiers::). The name of the global namespace is '::', even 11627 though in C++ the global namespace is unnamed. However, you should 11628 use comparison with 'global_namespace', rather than 'DECL_NAME' to 11629 determine whether or not a namespace is the global one. An unnamed 11630 namespace will have a 'DECL_NAME' equal to 11631 'anonymous_namespace_name'. Within a single translation unit, all 11632 unnamed namespaces will have the same name. 11633 11634'DECL_CONTEXT' 11635 This macro returns the enclosing namespace. The 'DECL_CONTEXT' for 11636 the 'global_namespace' is 'NULL_TREE'. 11637 11638'DECL_NAMESPACE_ALIAS' 11639 If this declaration is for a namespace alias, then 11640 'DECL_NAMESPACE_ALIAS' is the namespace for which this one is an 11641 alias. 11642 11643 Do not attempt to use 'cp_namespace_decls' for a namespace which is 11644 an alias. Instead, follow 'DECL_NAMESPACE_ALIAS' links until you 11645 reach an ordinary, non-alias, namespace, and call 11646 'cp_namespace_decls' there. 11647 11648'DECL_NAMESPACE_STD_P' 11649 This predicate holds if the namespace is the special '::std' 11650 namespace. 11651 11652'cp_namespace_decls' 11653 This function will return the declarations contained in the 11654 namespace, including types, overloaded functions, other namespaces, 11655 and so forth. If there are no declarations, this function will 11656 return 'NULL_TREE'. The declarations are connected through their 11657 'TREE_CHAIN' fields. 11658 11659 Although most entries on this list will be declarations, 11660 'TREE_LIST' nodes may also appear. In this case, the 'TREE_VALUE' 11661 will be an 'OVERLOAD'. The value of the 'TREE_PURPOSE' is 11662 unspecified; back ends should ignore this value. As with the other 11663 kinds of declarations returned by 'cp_namespace_decls', the 11664 'TREE_CHAIN' will point to the next declaration in this list. 11665 11666 For more information on the kinds of declarations that can occur on 11667 this list, *Note Declarations::. Some declarations will not appear 11668 on this list. In particular, no 'FIELD_DECL', 'LABEL_DECL', or 11669 'PARM_DECL' nodes will appear here. 11670 11671 This function cannot be used with namespaces that have 11672 'DECL_NAMESPACE_ALIAS' set. 11673 11674 11675File: gccint.info, Node: Classes, Next: Functions for C++, Prev: Namespaces, Up: C and C++ Trees 11676 1167711.10.3 Classes 11678--------------- 11679 11680Besides namespaces, the other high-level scoping construct in C++ is the 11681class. (Throughout this manual the term "class" is used to mean the 11682types referred to in the ANSI/ISO C++ Standard as classes; these include 11683types defined with the 'class', 'struct', and 'union' keywords.) 11684 11685 A class type is represented by either a 'RECORD_TYPE' or a 11686'UNION_TYPE'. A class declared with the 'union' tag is represented by a 11687'UNION_TYPE', while classes declared with either the 'struct' or the 11688'class' tag are represented by 'RECORD_TYPE's. You can use the 11689'CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular 11690type is a 'class' as opposed to a 'struct'. This macro will be true 11691only for classes declared with the 'class' tag. 11692 11693 Almost all members are available on the 'TYPE_FIELDS' list. Given one 11694member, the next can be found by following the 'TREE_CHAIN'. You should 11695not depend in any way on the order in which fields appear on this list. 11696All nodes on this list will be 'DECL' nodes. A 'FIELD_DECL' is used to 11697represent a non-static data member, a 'VAR_DECL' is used to represent a 11698static data member, and a 'TYPE_DECL' is used to represent a type. Note 11699that the 'CONST_DECL' for an enumeration constant will appear on this 11700list, if the enumeration type was declared in the class. (Of course, 11701the 'TYPE_DECL' for the enumeration type will appear here as well.) 11702There are no entries for base classes on this list. In particular, 11703there is no 'FIELD_DECL' for the "base-class portion" of an object. If 11704a function member is overloaded, each of the overloaded functions 11705appears; no 'OVERLOAD' nodes appear on the 'TYPE_FIELDS' list. 11706Implicitly declared functions (including default constructors, copy 11707constructors, assignment operators, and destructors) will appear on this 11708list as well. 11709 11710 The 'TYPE_VFIELD' is a compiler-generated field used to point to 11711virtual function tables. It may or may not appear on the 'TYPE_FIELDS' 11712list. However, back ends should handle the 'TYPE_VFIELD' just like all 11713the entries on the 'TYPE_FIELDS' list. 11714 11715 Every class has an associated "binfo", which can be obtained with 11716'TYPE_BINFO'. Binfos are used to represent base-classes. The binfo 11717given by 'TYPE_BINFO' is the degenerate case, whereby every class is 11718considered to be its own base-class. The base binfos for a particular 11719binfo are held in a vector, whose length is obtained with 11720'BINFO_N_BASE_BINFOS'. The base binfos themselves are obtained with 11721'BINFO_BASE_BINFO' and 'BINFO_BASE_ITERATE'. To add a new binfo, use 11722'BINFO_BASE_APPEND'. The vector of base binfos can be obtained with 11723'BINFO_BASE_BINFOS', but normally you do not need to use that. The 11724class type associated with a binfo is given by 'BINFO_TYPE'. It is not 11725always the case that 'BINFO_TYPE (TYPE_BINFO (x))', because of typedefs 11726and qualified types. Neither is it the case that 'TYPE_BINFO 11727(BINFO_TYPE (y))' is the same binfo as 'y'. The reason is that if 'y' 11728is a binfo representing a base-class 'B' of a derived class 'D', then 11729'BINFO_TYPE (y)' will be 'B', and 'TYPE_BINFO (BINFO_TYPE (y))' will be 11730'B' as its own base-class, rather than as a base-class of 'D'. 11731 11732 The access to a base type can be found with 'BINFO_BASE_ACCESS'. This 11733will produce 'access_public_node', 'access_private_node' or 11734'access_protected_node'. If bases are always public, 11735'BINFO_BASE_ACCESSES' may be 'NULL'. 11736 11737 'BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited 11738virtually or not. The other flags, 'BINFO_FLAG_0' to 'BINFO_FLAG_6', 11739can be used for language specific use. 11740 11741 The following macros can be used on a tree node representing a 11742class-type. 11743 11744'LOCAL_CLASS_P' 11745 This predicate holds if the class is local class _i.e._ declared 11746 inside a function body. 11747 11748'TYPE_POLYMORPHIC_P' 11749 This predicate holds if the class has at least one virtual function 11750 (declared or inherited). 11751 11752'TYPE_HAS_DEFAULT_CONSTRUCTOR' 11753 This predicate holds whenever its argument represents a class-type 11754 with default constructor. 11755 11756'CLASSTYPE_HAS_MUTABLE' 11757'TYPE_HAS_MUTABLE_P' 11758 These predicates hold for a class-type having a mutable data 11759 member. 11760 11761'CLASSTYPE_NON_POD_P' 11762 This predicate holds only for class-types that are not PODs. 11763 11764'TYPE_HAS_NEW_OPERATOR' 11765 This predicate holds for a class-type that defines 'operator new'. 11766 11767'TYPE_HAS_ARRAY_NEW_OPERATOR' 11768 This predicate holds for a class-type for which 'operator new[]' is 11769 defined. 11770 11771'TYPE_OVERLOADS_CALL_EXPR' 11772 This predicate holds for class-type for which the function call 11773 'operator()' is overloaded. 11774 11775'TYPE_OVERLOADS_ARRAY_REF' 11776 This predicate holds for a class-type that overloads 'operator[]' 11777 11778'TYPE_OVERLOADS_ARROW' 11779 This predicate holds for a class-type for which 'operator->' is 11780 overloaded. 11781 11782 11783File: gccint.info, Node: Functions for C++, Next: Statements for C++, Prev: Classes, Up: C and C++ Trees 11784 1178511.10.4 Functions for C++ 11786------------------------- 11787 11788A function is represented by a 'FUNCTION_DECL' node. A set of 11789overloaded functions is sometimes represented by an 'OVERLOAD' node. 11790 11791 An 'OVERLOAD' node is not a declaration, so none of the 'DECL_' macros 11792should be used on an 'OVERLOAD'. An 'OVERLOAD' node is similar to a 11793'TREE_LIST'. Use 'OVL_CURRENT' to get the function associated with an 11794'OVERLOAD' node; use 'OVL_NEXT' to get the next 'OVERLOAD' node in the 11795list of overloaded functions. The macros 'OVL_CURRENT' and 'OVL_NEXT' 11796are actually polymorphic; you can use them to work with 'FUNCTION_DECL' 11797nodes as well as with overloads. In the case of a 'FUNCTION_DECL', 11798'OVL_CURRENT' will always return the function itself, and 'OVL_NEXT' 11799will always be 'NULL_TREE'. 11800 11801 To determine the scope of a function, you can use the 'DECL_CONTEXT' 11802macro. This macro will return the class (either a 'RECORD_TYPE' or a 11803'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is 11804a member. For a virtual function, this macro returns the class in which 11805the function was actually defined, not the base class in which the 11806virtual declaration occurred. 11807 11808 If a friend function is defined in a class scope, the 11809'DECL_FRIEND_CONTEXT' macro can be used to determine the class in which 11810it was defined. For example, in 11811 class C { friend void f() {} }; 11812the 'DECL_CONTEXT' for 'f' will be the 'global_namespace', but the 11813'DECL_FRIEND_CONTEXT' will be the 'RECORD_TYPE' for 'C'. 11814 11815 The following macros and functions can be used on a 'FUNCTION_DECL': 11816'DECL_MAIN_P' 11817 This predicate holds for a function that is the program entry point 11818 '::code'. 11819 11820'DECL_LOCAL_FUNCTION_P' 11821 This predicate holds if the function was declared at block scope, 11822 even though it has a global scope. 11823 11824'DECL_ANTICIPATED' 11825 This predicate holds if the function is a built-in function but its 11826 prototype is not yet explicitly declared. 11827 11828'DECL_EXTERN_C_FUNCTION_P' 11829 This predicate holds if the function is declared as an ''extern 11830 "C"'' function. 11831 11832'DECL_LINKONCE_P' 11833 This macro holds if multiple copies of this function may be emitted 11834 in various translation units. It is the responsibility of the 11835 linker to merge the various copies. Template instantiations are 11836 the most common example of functions for which 'DECL_LINKONCE_P' 11837 holds; G++ instantiates needed templates in all translation units 11838 which require them, and then relies on the linker to remove 11839 duplicate instantiations. 11840 11841 FIXME: This macro is not yet implemented. 11842 11843'DECL_FUNCTION_MEMBER_P' 11844 This macro holds if the function is a member of a class, rather 11845 than a member of a namespace. 11846 11847'DECL_STATIC_FUNCTION_P' 11848 This predicate holds if the function a static member function. 11849 11850'DECL_NONSTATIC_MEMBER_FUNCTION_P' 11851 This macro holds for a non-static member function. 11852 11853'DECL_CONST_MEMFUNC_P' 11854 This predicate holds for a 'const'-member function. 11855 11856'DECL_VOLATILE_MEMFUNC_P' 11857 This predicate holds for a 'volatile'-member function. 11858 11859'DECL_CONSTRUCTOR_P' 11860 This macro holds if the function is a constructor. 11861 11862'DECL_NONCONVERTING_P' 11863 This predicate holds if the constructor is a non-converting 11864 constructor. 11865 11866'DECL_COMPLETE_CONSTRUCTOR_P' 11867 This predicate holds for a function which is a constructor for an 11868 object of a complete type. 11869 11870'DECL_BASE_CONSTRUCTOR_P' 11871 This predicate holds for a function which is a constructor for a 11872 base class sub-object. 11873 11874'DECL_COPY_CONSTRUCTOR_P' 11875 This predicate holds for a function which is a copy-constructor. 11876 11877'DECL_DESTRUCTOR_P' 11878 This macro holds if the function is a destructor. 11879 11880'DECL_COMPLETE_DESTRUCTOR_P' 11881 This predicate holds if the function is the destructor for an 11882 object a complete type. 11883 11884'DECL_OVERLOADED_OPERATOR_P' 11885 This macro holds if the function is an overloaded operator. 11886 11887'DECL_CONV_FN_P' 11888 This macro holds if the function is a type-conversion operator. 11889 11890'DECL_GLOBAL_CTOR_P' 11891 This predicate holds if the function is a file-scope initialization 11892 function. 11893 11894'DECL_GLOBAL_DTOR_P' 11895 This predicate holds if the function is a file-scope finalization 11896 function. 11897 11898'DECL_THUNK_P' 11899 This predicate holds if the function is a thunk. 11900 11901 These functions represent stub code that adjusts the 'this' pointer 11902 and then jumps to another function. When the jumped-to function 11903 returns, control is transferred directly to the caller, without 11904 returning to the thunk. The first parameter to the thunk is always 11905 the 'this' pointer; the thunk should add 'THUNK_DELTA' to this 11906 value. (The 'THUNK_DELTA' is an 'int', not an 'INTEGER_CST'.) 11907 11908 Then, if 'THUNK_VCALL_OFFSET' (an 'INTEGER_CST') is nonzero the 11909 adjusted 'this' pointer must be adjusted again. The complete 11910 calculation is given by the following pseudo-code: 11911 11912 this += THUNK_DELTA 11913 if (THUNK_VCALL_OFFSET) 11914 this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET] 11915 11916 Finally, the thunk should jump to the location given by 11917 'DECL_INITIAL'; this will always be an expression for the address 11918 of a function. 11919 11920'DECL_NON_THUNK_FUNCTION_P' 11921 This predicate holds if the function is _not_ a thunk function. 11922 11923'GLOBAL_INIT_PRIORITY' 11924 If either 'DECL_GLOBAL_CTOR_P' or 'DECL_GLOBAL_DTOR_P' holds, then 11925 this gives the initialization priority for the function. The 11926 linker will arrange that all functions for which 11927 'DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority 11928 before 'main' is called. When the program exits, all functions for 11929 which 'DECL_GLOBAL_DTOR_P' holds are run in the reverse order. 11930 11931'TYPE_RAISES_EXCEPTIONS' 11932 This macro returns the list of exceptions that a (member-)function 11933 can raise. The returned list, if non 'NULL', is comprised of nodes 11934 whose 'TREE_VALUE' represents a type. 11935 11936'TYPE_NOTHROW_P' 11937 This predicate holds when the exception-specification of its 11938 arguments is of the form ''()''. 11939 11940'DECL_ARRAY_DELETE_OPERATOR_P' 11941 This predicate holds if the function an overloaded 'operator 11942 delete[]'. 11943 11944 11945File: gccint.info, Node: Statements for C++, Next: C++ Expressions, Prev: Functions for C++, Up: C and C++ Trees 11946 1194711.10.5 Statements for C++ 11948-------------------------- 11949 11950A function that has a definition in the current translation unit will 11951have a non-'NULL' 'DECL_INITIAL'. However, back ends should not make 11952use of the particular value given by 'DECL_INITIAL'. 11953 11954 The 'DECL_SAVED_TREE' macro will give the complete body of the 11955function. 11956 1195711.10.5.1 Statements 11958.................... 11959 11960There are tree nodes corresponding to all of the source-level statement 11961constructs, used within the C and C++ frontends. These are enumerated 11962here, together with a list of the various macros that can be used to 11963obtain information about them. There are a few macros that can be used 11964with all statements: 11965 11966'STMT_IS_FULL_EXPR_P' 11967 In C++, statements normally constitute "full expressions"; 11968 temporaries created during a statement are destroyed when the 11969 statement is complete. However, G++ sometimes represents 11970 expressions by statements; these statements will not have 11971 'STMT_IS_FULL_EXPR_P' set. Temporaries created during such 11972 statements should be destroyed when the innermost enclosing 11973 statement with 'STMT_IS_FULL_EXPR_P' set is exited. 11974 11975 Here is the list of the various statement nodes, and the macros used to 11976access them. This documentation describes the use of these nodes in 11977non-template functions (including instantiations of template functions). 11978In template functions, the same nodes are used, but sometimes in 11979slightly different ways. 11980 11981 Many of the statements have substatements. For example, a 'while' loop 11982will have a body, which is itself a statement. If the substatement is 11983'NULL_TREE', it is considered equivalent to a statement consisting of a 11984single ';', i.e., an expression statement in which the expression has 11985been omitted. A substatement may in fact be a list of statements, 11986connected via their 'TREE_CHAIN's. So, you should always process the 11987statement tree by looping over substatements, like this: 11988 void process_stmt (stmt) 11989 tree stmt; 11990 { 11991 while (stmt) 11992 { 11993 switch (TREE_CODE (stmt)) 11994 { 11995 case IF_STMT: 11996 process_stmt (THEN_CLAUSE (stmt)); 11997 /* More processing here. */ 11998 break; 11999 12000 ... 12001 } 12002 12003 stmt = TREE_CHAIN (stmt); 12004 } 12005 } 12006 In other words, while the 'then' clause of an 'if' statement in C++ can 12007be only one statement (although that one statement may be a compound 12008statement), the intermediate representation will sometimes use several 12009statements chained together. 12010 12011'BREAK_STMT' 12012 12013 Used to represent a 'break' statement. There are no additional 12014 fields. 12015 12016'CLEANUP_STMT' 12017 12018 Used to represent an action that should take place upon exit from 12019 the enclosing scope. Typically, these actions are calls to 12020 destructors for local objects, but back ends cannot rely on this 12021 fact. If these nodes are in fact representing such destructors, 12022 'CLEANUP_DECL' will be the 'VAR_DECL' destroyed. Otherwise, 12023 'CLEANUP_DECL' will be 'NULL_TREE'. In any case, the 12024 'CLEANUP_EXPR' is the expression to execute. The cleanups executed 12025 on exit from a scope should be run in the reverse order of the 12026 order in which the associated 'CLEANUP_STMT's were encountered. 12027 12028'CONTINUE_STMT' 12029 12030 Used to represent a 'continue' statement. There are no additional 12031 fields. 12032 12033'CTOR_STMT' 12034 12035 Used to mark the beginning (if 'CTOR_BEGIN_P' holds) or end (if 12036 'CTOR_END_P' holds of the main body of a constructor. See also 12037 'SUBOBJECT' for more information on how to use these nodes. 12038 12039'DO_STMT' 12040 12041 Used to represent a 'do' loop. The body of the loop is given by 12042 'DO_BODY' while the termination condition for the loop is given by 12043 'DO_COND'. The condition for a 'do'-statement is always an 12044 expression. 12045 12046'EMPTY_CLASS_EXPR' 12047 12048 Used to represent a temporary object of a class with no data whose 12049 address is never taken. (All such objects are interchangeable.) 12050 The 'TREE_TYPE' represents the type of the object. 12051 12052'EXPR_STMT' 12053 12054 Used to represent an expression statement. Use 'EXPR_STMT_EXPR' to 12055 obtain the expression. 12056 12057'FOR_STMT' 12058 12059 Used to represent a 'for' statement. The 'FOR_INIT_STMT' is the 12060 initialization statement for the loop. The 'FOR_COND' is the 12061 termination condition. The 'FOR_EXPR' is the expression executed 12062 right before the 'FOR_COND' on each loop iteration; often, this 12063 expression increments a counter. The body of the loop is given by 12064 'FOR_BODY'. Note that 'FOR_INIT_STMT' and 'FOR_BODY' return 12065 statements, while 'FOR_COND' and 'FOR_EXPR' return expressions. 12066 12067'HANDLER' 12068 12069 Used to represent a C++ 'catch' block. The 'HANDLER_TYPE' is the 12070 type of exception that will be caught by this handler; it is equal 12071 (by pointer equality) to 'NULL' if this handler is for all types. 12072 'HANDLER_PARMS' is the 'DECL_STMT' for the catch parameter, and 12073 'HANDLER_BODY' is the code for the block itself. 12074 12075'IF_STMT' 12076 12077 Used to represent an 'if' statement. The 'IF_COND' is the 12078 expression. 12079 12080 If the condition is a 'TREE_LIST', then the 'TREE_PURPOSE' is a 12081 statement (usually a 'DECL_STMT'). Each time the condition is 12082 evaluated, the statement should be executed. Then, the 12083 'TREE_VALUE' should be used as the conditional expression itself. 12084 This representation is used to handle C++ code like this: 12085 12086 C++ distinguishes between this and 'COND_EXPR' for handling 12087 templates. 12088 12089 if (int i = 7) ... 12090 12091 where there is a new local variable (or variables) declared within 12092 the condition. 12093 12094 The 'THEN_CLAUSE' represents the statement given by the 'then' 12095 condition, while the 'ELSE_CLAUSE' represents the statement given 12096 by the 'else' condition. 12097 12098'SUBOBJECT' 12099 12100 In a constructor, these nodes are used to mark the point at which a 12101 subobject of 'this' is fully constructed. If, after this point, an 12102 exception is thrown before a 'CTOR_STMT' with 'CTOR_END_P' set is 12103 encountered, the 'SUBOBJECT_CLEANUP' must be executed. The 12104 cleanups must be executed in the reverse order in which they 12105 appear. 12106 12107'SWITCH_STMT' 12108 12109 Used to represent a 'switch' statement. The 'SWITCH_STMT_COND' is 12110 the expression on which the switch is occurring. See the 12111 documentation for an 'IF_STMT' for more information on the 12112 representation used for the condition. The 'SWITCH_STMT_BODY' is 12113 the body of the switch statement. The 'SWITCH_STMT_TYPE' is the 12114 original type of switch expression as given in the source, before 12115 any compiler conversions. 12116 12117'TRY_BLOCK' 12118 Used to represent a 'try' block. The body of the try block is 12119 given by 'TRY_STMTS'. Each of the catch blocks is a 'HANDLER' 12120 node. The first handler is given by 'TRY_HANDLERS'. Subsequent 12121 handlers are obtained by following the 'TREE_CHAIN' link from one 12122 handler to the next. The body of the handler is given by 12123 'HANDLER_BODY'. 12124 12125 If 'CLEANUP_P' holds of the 'TRY_BLOCK', then the 'TRY_HANDLERS' 12126 will not be a 'HANDLER' node. Instead, it will be an expression 12127 that should be executed if an exception is thrown in the try block. 12128 It must rethrow the exception after executing that code. And, if 12129 an exception is thrown while the expression is executing, 12130 'terminate' must be called. 12131 12132'USING_STMT' 12133 Used to represent a 'using' directive. The namespace is given by 12134 'USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node 12135 is needed inside template functions, to implement using directives 12136 during instantiation. 12137 12138'WHILE_STMT' 12139 12140 Used to represent a 'while' loop. The 'WHILE_COND' is the 12141 termination condition for the loop. See the documentation for an 12142 'IF_STMT' for more information on the representation used for the 12143 condition. 12144 12145 The 'WHILE_BODY' is the body of the loop. 12146 12147 12148File: gccint.info, Node: C++ Expressions, Prev: Statements for C++, Up: C and C++ Trees 12149 1215011.10.6 C++ Expressions 12151----------------------- 12152 12153This section describes expressions specific to the C and C++ front ends. 12154 12155'TYPEID_EXPR' 12156 12157 Used to represent a 'typeid' expression. 12158 12159'NEW_EXPR' 12160'VEC_NEW_EXPR' 12161 12162 Used to represent a call to 'new' and 'new[]' respectively. 12163 12164'DELETE_EXPR' 12165'VEC_DELETE_EXPR' 12166 12167 Used to represent a call to 'delete' and 'delete[]' respectively. 12168 12169'MEMBER_REF' 12170 12171 Represents a reference to a member of a class. 12172 12173'THROW_EXPR' 12174 12175 Represents an instance of 'throw' in the program. Operand 0, which 12176 is the expression to throw, may be 'NULL_TREE'. 12177 12178'AGGR_INIT_EXPR' 12179 An 'AGGR_INIT_EXPR' represents the initialization as the return 12180 value of a function call, or as the result of a constructor. An 12181 'AGGR_INIT_EXPR' will only appear as a full-expression, or as the 12182 second operand of a 'TARGET_EXPR'. 'AGGR_INIT_EXPR's have a 12183 representation similar to that of 'CALL_EXPR's. You can use the 12184 'AGGR_INIT_EXPR_FN' and 'AGGR_INIT_EXPR_ARG' macros to access the 12185 function to call and the arguments to pass. 12186 12187 If 'AGGR_INIT_VIA_CTOR_P' holds of the 'AGGR_INIT_EXPR', then the 12188 initialization is via a constructor call. The address of the 12189 'AGGR_INIT_EXPR_SLOT' operand, which is always a 'VAR_DECL', is 12190 taken, and this value replaces the first argument in the argument 12191 list. 12192 12193 In either case, the expression is void. 12194 12195 12196File: gccint.info, Node: Java Trees, Prev: C and C++ Trees, Up: GENERIC 12197 1219811.11 Java Trees 12199================ 12200 12201 12202File: gccint.info, Node: GIMPLE, Next: Tree SSA, Prev: GENERIC, Up: Top 12203 1220412 GIMPLE 12205********* 12206 12207GIMPLE is a three-address representation derived from GENERIC by 12208breaking down GENERIC expressions into tuples of no more than 3 operands 12209(with some exceptions like function calls). GIMPLE was heavily 12210influenced by the SIMPLE IL used by the McCAT compiler project at McGill 12211University, though we have made some different choices. For one thing, 12212SIMPLE doesn't support 'goto'. 12213 12214 Temporaries are introduced to hold intermediate values needed to 12215compute complex expressions. Additionally, all the control structures 12216used in GENERIC are lowered into conditional jumps, lexical scopes are 12217removed and exception regions are converted into an on the side 12218exception region tree. 12219 12220 The compiler pass which converts GENERIC into GIMPLE is referred to as 12221the 'gimplifier'. The gimplifier works recursively, generating GIMPLE 12222tuples out of the original GENERIC expressions. 12223 12224 One of the early implementation strategies used for the GIMPLE 12225representation was to use the same internal data structures used by 12226front ends to represent parse trees. This simplified implementation 12227because we could leverage existing functionality and interfaces. 12228However, GIMPLE is a much more restrictive representation than abstract 12229syntax trees (AST), therefore it does not require the full structural 12230complexity provided by the main tree data structure. 12231 12232 The GENERIC representation of a function is stored in the 12233'DECL_SAVED_TREE' field of the associated 'FUNCTION_DECL' tree node. It 12234is converted to GIMPLE by a call to 'gimplify_function_tree'. 12235 12236 If a front end wants to include language-specific tree codes in the 12237tree representation which it provides to the back end, it must provide a 12238definition of 'LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the 12239front end trees to GIMPLE. Usually such a hook will involve much of the 12240same code for expanding front end trees to RTL. This function can 12241return fully lowered GIMPLE, or it can return GENERIC trees and let the 12242main gimplifier lower them the rest of the way; this is often simpler. 12243GIMPLE that is not fully lowered is known as "High GIMPLE" and consists 12244of the IL before the pass 'pass_lower_cf'. High GIMPLE contains some 12245container statements like lexical scopes (represented by 'GIMPLE_BIND') 12246and nested expressions (e.g., 'GIMPLE_TRY'), while "Low GIMPLE" exposes 12247all of the implicit jumps for control and exception expressions directly 12248in the IL and EH region trees. 12249 12250 The C and C++ front ends currently convert directly from front end 12251trees to GIMPLE, and hand that off to the back end rather than first 12252converting to GENERIC. Their gimplifier hooks know about all the 12253'_STMT' nodes and how to convert them to GENERIC forms. There was some 12254work done on a genericization pass which would run first, but the 12255existence of 'STMT_EXPR' meant that in order to convert all of the C 12256statements into GENERIC equivalents would involve walking the entire 12257tree anyway, so it was simpler to lower all the way. This might change 12258in the future if someone writes an optimization pass which would work 12259better with higher-level trees, but currently the optimizers all expect 12260GIMPLE. 12261 12262 You can request to dump a C-like representation of the GIMPLE form with 12263the flag '-fdump-tree-gimple'. 12264 12265* Menu: 12266 12267* Tuple representation:: 12268* Class hierarchy of GIMPLE statements:: 12269* GIMPLE instruction set:: 12270* GIMPLE Exception Handling:: 12271* Temporaries:: 12272* Operands:: 12273* Manipulating GIMPLE statements:: 12274* Tuple specific accessors:: 12275* GIMPLE sequences:: 12276* Sequence iterators:: 12277* Adding a new GIMPLE statement code:: 12278* Statement and operand traversals:: 12279 12280 12281File: gccint.info, Node: Tuple representation, Next: Class hierarchy of GIMPLE statements, Up: GIMPLE 12282 1228312.1 Tuple representation 12284========================= 12285 12286GIMPLE instructions are tuples of variable size divided in two groups: a 12287header describing the instruction and its locations, and a variable 12288length body with all the operands. Tuples are organized into a 12289hierarchy with 3 main classes of tuples. 12290 1229112.1.1 'gimple' (gsbase) 12292------------------------ 12293 12294This is the root of the hierarchy, it holds basic information needed by 12295most GIMPLE statements. There are some fields that may not be relevant 12296to every GIMPLE statement, but those were moved into the base structure 12297to take advantage of holes left by other fields (thus making the 12298structure more compact). The structure takes 4 words (32 bytes) on 64 12299bit hosts: 12300 12301Field Size (bits) 12302'code' 8 12303'subcode' 16 12304'no_warning' 1 12305'visited' 1 12306'nontemporal_move' 1 12307'plf' 2 12308'modified' 1 12309'has_volatile_ops' 1 12310'references_memory_p' 1 12311'uid' 32 12312'location' 32 12313'num_ops' 32 12314'bb' 64 12315'block' 63 12316Total size 32 bytes 12317 12318 * 'code' Main identifier for a GIMPLE instruction. 12319 12320 * 'subcode' Used to distinguish different variants of the same basic 12321 instruction or provide flags applicable to a given code. The 12322 'subcode' flags field has different uses depending on the code of 12323 the instruction, but mostly it distinguishes instructions of the 12324 same family. The most prominent use of this field is in 12325 assignments, where subcode indicates the operation done on the RHS 12326 of the assignment. For example, a = b + c is encoded as 12327 'GIMPLE_ASSIGN <PLUS_EXPR, a, b, c>'. 12328 12329 * 'no_warning' Bitflag to indicate whether a warning has already been 12330 issued on this statement. 12331 12332 * 'visited' General purpose "visited" marker. Set and cleared by 12333 each pass when needed. 12334 12335 * 'nontemporal_move' Bitflag used in assignments that represent 12336 non-temporal moves. Although this bitflag is only used in 12337 assignments, it was moved into the base to take advantage of the 12338 bit holes left by the previous fields. 12339 12340 * 'plf' Pass Local Flags. This 2-bit mask can be used as general 12341 purpose markers by any pass. Passes are responsible for clearing 12342 and setting these two flags accordingly. 12343 12344 * 'modified' Bitflag to indicate whether the statement has been 12345 modified. Used mainly by the operand scanner to determine when to 12346 re-scan a statement for operands. 12347 12348 * 'has_volatile_ops' Bitflag to indicate whether this statement 12349 contains operands that have been marked volatile. 12350 12351 * 'references_memory_p' Bitflag to indicate whether this statement 12352 contains memory references (i.e., its operands are either global 12353 variables, or pointer dereferences or anything that must reside in 12354 memory). 12355 12356 * 'uid' This is an unsigned integer used by passes that want to 12357 assign IDs to every statement. These IDs must be assigned and used 12358 by each pass. 12359 12360 * 'location' This is a 'location_t' identifier to specify source code 12361 location for this statement. It is inherited from the front end. 12362 12363 * 'num_ops' Number of operands that this statement has. This 12364 specifies the size of the operand vector embedded in the tuple. 12365 Only used in some tuples, but it is declared in the base tuple to 12366 take advantage of the 32-bit hole left by the previous fields. 12367 12368 * 'bb' Basic block holding the instruction. 12369 12370 * 'block' Lexical block holding this statement. Also used for debug 12371 information generation. 12372 1237312.1.2 'gimple_statement_with_ops' 12374---------------------------------- 12375 12376This tuple is actually split in two: 'gimple_statement_with_ops_base' 12377and 'gimple_statement_with_ops'. This is needed to accommodate the way 12378the operand vector is allocated. The operand vector is defined to be an 12379array of 1 element. So, to allocate a dynamic number of operands, the 12380memory allocator ('gimple_alloc') simply allocates enough memory to hold 12381the structure itself plus 'N - 1' operands which run "off the end" of 12382the structure. For example, to allocate space for a tuple with 3 12383operands, 'gimple_alloc' reserves 'sizeof (struct 12384gimple_statement_with_ops) + 2 * sizeof (tree)' bytes. 12385 12386 On the other hand, several fields in this tuple need to be shared with 12387the 'gimple_statement_with_memory_ops' tuple. So, these common fields 12388are placed in 'gimple_statement_with_ops_base' which is then inherited 12389from the other two tuples. 12390 12391'gsbase' 256 12392'def_ops' 64 12393'use_ops' 64 12394'op' 'num_ops' * 64 12395Total 48 + 8 * 'num_ops' bytes 12396size 12397 12398 * 'gsbase' Inherited from 'struct gimple'. 12399 12400 * 'def_ops' Array of pointers into the operand array indicating all 12401 the slots that contain a variable written-to by the statement. 12402 This array is also used for immediate use chaining. Note that it 12403 would be possible to not rely on this array, but the changes 12404 required to implement this are pretty invasive. 12405 12406 * 'use_ops' Similar to 'def_ops' but for variables read by the 12407 statement. 12408 12409 * 'op' Array of trees with 'num_ops' slots. 12410 1241112.1.3 'gimple_statement_with_memory_ops' 12412----------------------------------------- 12413 12414This tuple is essentially identical to 'gimple_statement_with_ops', 12415except that it contains 4 additional fields to hold vectors related 12416memory stores and loads. Similar to the previous case, the structure is 12417split in two to accommodate for the operand vector 12418('gimple_statement_with_memory_ops_base' and 12419'gimple_statement_with_memory_ops'). 12420 12421Field Size (bits) 12422'gsbase' 256 12423'def_ops' 64 12424'use_ops' 64 12425'vdef_ops' 64 12426'vuse_ops' 64 12427'stores' 64 12428'loads' 64 12429'op' 'num_ops' * 64 12430Total size 80 + 8 * 'num_ops' bytes 12431 12432 * 'vdef_ops' Similar to 'def_ops' but for 'VDEF' operators. There is 12433 one entry per memory symbol written by this statement. This is 12434 used to maintain the memory SSA use-def and def-def chains. 12435 12436 * 'vuse_ops' Similar to 'use_ops' but for 'VUSE' operators. There is 12437 one entry per memory symbol loaded by this statement. This is used 12438 to maintain the memory SSA use-def chains. 12439 12440 * 'stores' Bitset with all the UIDs for the symbols written-to by the 12441 statement. This is different than 'vdef_ops' in that all the 12442 affected symbols are mentioned in this set. If memory partitioning 12443 is enabled, the 'vdef_ops' vector will refer to memory partitions. 12444 Furthermore, no SSA information is stored in this set. 12445 12446 * 'loads' Similar to 'stores', but for memory loads. (Note that 12447 there is some amount of redundancy here, it should be possible to 12448 reduce memory utilization further by removing these sets). 12449 12450 All the other tuples are defined in terms of these three basic ones. 12451Each tuple will add some fields. 12452 12453 12454File: gccint.info, Node: Class hierarchy of GIMPLE statements, Next: GIMPLE instruction set, Prev: Tuple representation, Up: GIMPLE 12455 1245612.2 Class hierarchy of GIMPLE statements 12457========================================= 12458 12459The following diagram shows the C++ inheritance hierarchy of statement 12460kinds, along with their relationships to 'GSS_' values (layouts) and 12461'GIMPLE_' values (codes): 12462 12463 gimple 12464 | layout: GSS_BASE 12465 | used for 4 codes: GIMPLE_ERROR_MARK 12466 | GIMPLE_NOP 12467 | GIMPLE_OMP_SECTIONS_SWITCH 12468 | GIMPLE_PREDICT 12469 | 12470 + gimple_statement_with_ops_base 12471 | | (no GSS layout) 12472 | | 12473 | + gimple_statement_with_ops 12474 | | | layout: GSS_WITH_OPS 12475 | | | 12476 | | + gcond 12477 | | | code: GIMPLE_COND 12478 | | | 12479 | | + gdebug 12480 | | | code: GIMPLE_DEBUG 12481 | | | 12482 | | + ggoto 12483 | | | code: GIMPLE_GOTO 12484 | | | 12485 | | + glabel 12486 | | | code: GIMPLE_LABEL 12487 | | | 12488 | | + gswitch 12489 | | code: GIMPLE_SWITCH 12490 | | 12491 | + gimple_statement_with_memory_ops_base 12492 | | layout: GSS_WITH_MEM_OPS_BASE 12493 | | 12494 | + gimple_statement_with_memory_ops 12495 | | | layout: GSS_WITH_MEM_OPS 12496 | | | 12497 | | + gassign 12498 | | | code GIMPLE_ASSIGN 12499 | | | 12500 | | + greturn 12501 | | code GIMPLE_RETURN 12502 | | 12503 | + gcall 12504 | | layout: GSS_CALL, code: GIMPLE_CALL 12505 | | 12506 | + gasm 12507 | | layout: GSS_ASM, code: GIMPLE_ASM 12508 | | 12509 | + gtransaction 12510 | layout: GSS_TRANSACTION, code: GIMPLE_TRANSACTION 12511 | 12512 + gimple_statement_omp 12513 | | layout: GSS_OMP. Used for code GIMPLE_OMP_SECTION 12514 | | 12515 | + gomp_critical 12516 | | layout: GSS_OMP_CRITICAL, code: GIMPLE_OMP_CRITICAL 12517 | | 12518 | + gomp_for 12519 | | layout: GSS_OMP_FOR, code: GIMPLE_OMP_FOR 12520 | | 12521 | + gomp_parallel_layout 12522 | | | layout: GSS_OMP_PARALLEL_LAYOUT 12523 | | | 12524 | | + gimple_statement_omp_taskreg 12525 | | | | 12526 | | | + gomp_parallel 12527 | | | | code: GIMPLE_OMP_PARALLEL 12528 | | | | 12529 | | | + gomp_task 12530 | | | code: GIMPLE_OMP_TASK 12531 | | | 12532 | | + gimple_statement_omp_target 12533 | | code: GIMPLE_OMP_TARGET 12534 | | 12535 | + gomp_sections 12536 | | layout: GSS_OMP_SECTIONS, code: GIMPLE_OMP_SECTIONS 12537 | | 12538 | + gimple_statement_omp_single_layout 12539 | | layout: GSS_OMP_SINGLE_LAYOUT 12540 | | 12541 | + gomp_single 12542 | | code: GIMPLE_OMP_SINGLE 12543 | | 12544 | + gomp_teams 12545 | code: GIMPLE_OMP_TEAMS 12546 | 12547 + gbind 12548 | layout: GSS_BIND, code: GIMPLE_BIND 12549 | 12550 + gcatch 12551 | layout: GSS_CATCH, code: GIMPLE_CATCH 12552 | 12553 + geh_filter 12554 | layout: GSS_EH_FILTER, code: GIMPLE_EH_FILTER 12555 | 12556 + geh_else 12557 | layout: GSS_EH_ELSE, code: GIMPLE_EH_ELSE 12558 | 12559 + geh_mnt 12560 | layout: GSS_EH_MNT, code: GIMPLE_EH_MUST_NOT_THROW 12561 | 12562 + gphi 12563 | layout: GSS_PHI, code: GIMPLE_PHI 12564 | 12565 + gimple_statement_eh_ctrl 12566 | | layout: GSS_EH_CTRL 12567 | | 12568 | + gresx 12569 | | code: GIMPLE_RESX 12570 | | 12571 | + geh_dispatch 12572 | code: GIMPLE_EH_DISPATCH 12573 | 12574 + gtry 12575 | layout: GSS_TRY, code: GIMPLE_TRY 12576 | 12577 + gimple_statement_wce 12578 | layout: GSS_WCE, code: GIMPLE_WITH_CLEANUP_EXPR 12579 | 12580 + gomp_continue 12581 | layout: GSS_OMP_CONTINUE, code: GIMPLE_OMP_CONTINUE 12582 | 12583 + gomp_atomic_load 12584 | layout: GSS_OMP_ATOMIC_LOAD, code: GIMPLE_OMP_ATOMIC_LOAD 12585 | 12586 + gimple_statement_omp_atomic_store_layout 12587 | layout: GSS_OMP_ATOMIC_STORE_LAYOUT, 12588 | code: GIMPLE_OMP_ATOMIC_STORE 12589 | 12590 + gomp_atomic_store 12591 | code: GIMPLE_OMP_ATOMIC_STORE 12592 | 12593 + gomp_return 12594 code: GIMPLE_OMP_RETURN 12595 12596 12597File: gccint.info, Node: GIMPLE instruction set, Next: GIMPLE Exception Handling, Prev: Class hierarchy of GIMPLE statements, Up: GIMPLE 12598 1259912.3 GIMPLE instruction set 12600=========================== 12601 12602The following table briefly describes the GIMPLE instruction set. 12603 12604Instruction High GIMPLE Low GIMPLE 12605'GIMPLE_ASM' x x 12606'GIMPLE_ASSIGN' x x 12607'GIMPLE_BIND' x 12608'GIMPLE_CALL' x x 12609'GIMPLE_CATCH' x 12610'GIMPLE_COND' x x 12611'GIMPLE_DEBUG' x x 12612'GIMPLE_EH_FILTER' x 12613'GIMPLE_GOTO' x x 12614'GIMPLE_LABEL' x x 12615'GIMPLE_NOP' x x 12616'GIMPLE_OMP_ATOMIC_LOAD' x x 12617'GIMPLE_OMP_ATOMIC_STORE' x x 12618'GIMPLE_OMP_CONTINUE' x x 12619'GIMPLE_OMP_CRITICAL' x x 12620'GIMPLE_OMP_FOR' x x 12621'GIMPLE_OMP_MASTER' x x 12622'GIMPLE_OMP_ORDERED' x x 12623'GIMPLE_OMP_PARALLEL' x x 12624'GIMPLE_OMP_RETURN' x x 12625'GIMPLE_OMP_SECTION' x x 12626'GIMPLE_OMP_SECTIONS' x x 12627'GIMPLE_OMP_SECTIONS_SWITCH' x x 12628'GIMPLE_OMP_SINGLE' x x 12629'GIMPLE_PHI' x 12630'GIMPLE_RESX' x 12631'GIMPLE_RETURN' x x 12632'GIMPLE_SWITCH' x x 12633'GIMPLE_TRY' x 12634 12635 12636File: gccint.info, Node: GIMPLE Exception Handling, Next: Temporaries, Prev: GIMPLE instruction set, Up: GIMPLE 12637 1263812.4 Exception Handling 12639======================= 12640 12641Other exception handling constructs are represented using 12642'GIMPLE_TRY_CATCH'. 'GIMPLE_TRY_CATCH' has two operands. The first 12643operand is a sequence of statements to execute. If executing these 12644statements does not throw an exception, then the second operand is 12645ignored. Otherwise, if an exception is thrown, then the second operand 12646of the 'GIMPLE_TRY_CATCH' is checked. The second operand may have the 12647following forms: 12648 12649 1. A sequence of statements to execute. When an exception occurs, 12650 these statements are executed, and then the exception is rethrown. 12651 12652 2. A sequence of 'GIMPLE_CATCH' statements. Each 'GIMPLE_CATCH' has a 12653 list of applicable exception types and handler code. If the thrown 12654 exception matches one of the caught types, the associated handler 12655 code is executed. If the handler code falls off the bottom, 12656 execution continues after the original 'GIMPLE_TRY_CATCH'. 12657 12658 3. A 'GIMPLE_EH_FILTER' statement. This has a list of permitted 12659 exception types, and code to handle a match failure. If the thrown 12660 exception does not match one of the allowed types, the associated 12661 match failure code is executed. If the thrown exception does 12662 match, it continues unwinding the stack looking for the next 12663 handler. 12664 12665 Currently throwing an exception is not directly represented in GIMPLE, 12666since it is implemented by calling a function. At some point in the 12667future we will want to add some way to express that the call will throw 12668an exception of a known type. 12669 12670 Just before running the optimizers, the compiler lowers the high-level 12671EH constructs above into a set of 'goto's, magic labels, and EH regions. 12672Continuing to unwind at the end of a cleanup is represented with a 12673'GIMPLE_RESX'. 12674 12675 12676File: gccint.info, Node: Temporaries, Next: Operands, Prev: GIMPLE Exception Handling, Up: GIMPLE 12677 1267812.5 Temporaries 12679================ 12680 12681When gimplification encounters a subexpression that is too complex, it 12682creates a new temporary variable to hold the value of the subexpression, 12683and adds a new statement to initialize it before the current statement. 12684These special temporaries are known as 'expression temporaries', and are 12685allocated using 'get_formal_tmp_var'. The compiler tries to always 12686evaluate identical expressions into the same temporary, to simplify 12687elimination of redundant calculations. 12688 12689 We can only use expression temporaries when we know that it will not be 12690reevaluated before its value is used, and that it will not be otherwise 12691modified(1). Other temporaries can be allocated using 12692'get_initialized_tmp_var' or 'create_tmp_var'. 12693 12694 Currently, an expression like 'a = b + 5' is not reduced any further. 12695We tried converting it to something like 12696 T1 = b + 5; 12697 a = T1; 12698 but this bloated the representation for minimal benefit. However, a 12699variable which must live in memory cannot appear in an expression; its 12700value is explicitly loaded into a temporary first. Similarly, storing 12701the value of an expression to a memory variable goes through a 12702temporary. 12703 12704 ---------- Footnotes ---------- 12705 12706 (1) These restrictions are derived from those in Morgan 4.8. 12707 12708 12709File: gccint.info, Node: Operands, Next: Manipulating GIMPLE statements, Prev: Temporaries, Up: GIMPLE 12710 1271112.6 Operands 12712============= 12713 12714In general, expressions in GIMPLE consist of an operation and the 12715appropriate number of simple operands; these operands must either be a 12716GIMPLE rvalue ('is_gimple_val'), i.e. a constant or a register variable. 12717More complex operands are factored out into temporaries, so that 12718 a = b + c + d 12719 becomes 12720 T1 = b + c; 12721 a = T1 + d; 12722 12723 The same rule holds for arguments to a 'GIMPLE_CALL'. 12724 12725 The target of an assignment is usually a variable, but can also be a 12726'MEM_REF' or a compound lvalue as described below. 12727 12728* Menu: 12729 12730* Compound Expressions:: 12731* Compound Lvalues:: 12732* Conditional Expressions:: 12733* Logical Operators:: 12734 12735 12736File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: Operands 12737 1273812.6.1 Compound Expressions 12739--------------------------- 12740 12741The left-hand side of a C comma expression is simply moved into a 12742separate statement. 12743 12744 12745File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: Operands 12746 1274712.6.2 Compound Lvalues 12748----------------------- 12749 12750Currently compound lvalues involving array and structure field 12751references are not broken down; an expression like 'a.b[2] = 42' is not 12752reduced any further (though complex array subscripts are). This 12753restriction is a workaround for limitations in later optimizers; if we 12754were to convert this to 12755 12756 T1 = &a.b; 12757 T1[2] = 42; 12758 12759 alias analysis would not remember that the reference to 'T1[2]' came by 12760way of 'a.b', so it would think that the assignment could alias another 12761member of 'a'; this broke 'struct-alias-1.c'. Future optimizer 12762improvements may make this limitation unnecessary. 12763 12764 12765File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: Operands 12766 1276712.6.3 Conditional Expressions 12768------------------------------ 12769 12770A C '?:' expression is converted into an 'if' statement with each branch 12771assigning to the same temporary. So, 12772 12773 a = b ? c : d; 12774 becomes 12775 if (b == 1) 12776 T1 = c; 12777 else 12778 T1 = d; 12779 a = T1; 12780 12781 The GIMPLE level if-conversion pass re-introduces '?:' expression, if 12782appropriate. It is used to vectorize loops with conditions using vector 12783conditional operations. 12784 12785 Note that in GIMPLE, 'if' statements are represented using 12786'GIMPLE_COND', as described below. 12787 12788 12789File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: Operands 12790 1279112.6.4 Logical Operators 12792------------------------ 12793 12794Except when they appear in the condition operand of a 'GIMPLE_COND', 12795logical 'and' and 'or' operators are simplified as follows: 'a = b && c' 12796becomes 12797 12798 T1 = (bool)b; 12799 if (T1 == true) 12800 T1 = (bool)c; 12801 a = T1; 12802 12803 Note that 'T1' in this example cannot be an expression temporary, 12804because it has two different assignments. 12805 1280612.6.5 Manipulating operands 12807---------------------------- 12808 12809All gimple operands are of type 'tree'. But only certain types of trees 12810are allowed to be used as operand tuples. Basic validation is 12811controlled by the function 'get_gimple_rhs_class', which given a tree 12812code, returns an 'enum' with the following values of type 'enum 12813gimple_rhs_class' 12814 12815 * 'GIMPLE_INVALID_RHS' The tree cannot be used as a GIMPLE operand. 12816 12817 * 'GIMPLE_TERNARY_RHS' The tree is a valid GIMPLE ternary operation. 12818 12819 * 'GIMPLE_BINARY_RHS' The tree is a valid GIMPLE binary operation. 12820 12821 * 'GIMPLE_UNARY_RHS' The tree is a valid GIMPLE unary operation. 12822 12823 * 'GIMPLE_SINGLE_RHS' The tree is a single object, that cannot be 12824 split into simpler operands (for instance, 'SSA_NAME', 'VAR_DECL', 12825 'COMPONENT_REF', etc). 12826 12827 This operand class also acts as an escape hatch for tree nodes that 12828 may be flattened out into the operand vector, but would need more 12829 than two slots on the RHS. For instance, a 'COND_EXPR' expression 12830 of the form '(a op b) ? x : y' could be flattened out on the 12831 operand vector using 4 slots, but it would also require additional 12832 processing to distinguish 'c = a op b' from 'c = a op b ? x : y'. 12833 Something similar occurs with 'ASSERT_EXPR'. In time, these 12834 special case tree expressions should be flattened into the operand 12835 vector. 12836 12837 For tree nodes in the categories 'GIMPLE_TERNARY_RHS', 12838'GIMPLE_BINARY_RHS' and 'GIMPLE_UNARY_RHS', they cannot be stored inside 12839tuples directly. They first need to be flattened and separated into 12840individual components. For instance, given the GENERIC expression 12841 12842 a = b + c 12843 12844 its tree representation is: 12845 12846 MODIFY_EXPR <VAR_DECL <a>, PLUS_EXPR <VAR_DECL <b>, VAR_DECL <c>>> 12847 12848 In this case, the GIMPLE form for this statement is logically identical 12849to its GENERIC form but in GIMPLE, the 'PLUS_EXPR' on the RHS of the 12850assignment is not represented as a tree, instead the two operands are 12851taken out of the 'PLUS_EXPR' sub-tree and flattened into the GIMPLE 12852tuple as follows: 12853 12854 GIMPLE_ASSIGN <PLUS_EXPR, VAR_DECL <a>, VAR_DECL <b>, VAR_DECL <c>> 12855 1285612.6.6 Operand vector allocation 12857-------------------------------- 12858 12859The operand vector is stored at the bottom of the three tuple structures 12860that accept operands. This means, that depending on the code of a given 12861statement, its operand vector will be at different offsets from the base 12862of the structure. To access tuple operands use the following accessors 12863 12864 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 12865 Returns the number of operands in statement G. 12866 12867 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 12868 Returns operand 'I' from statement 'G'. 12869 12870 -- GIMPLE function: tree * gimple_ops (gimple g) 12871 Returns a pointer into the operand vector for statement 'G'. This 12872 is computed using an internal table called 'gimple_ops_offset_'[]. 12873 This table is indexed by the gimple code of 'G'. 12874 12875 When the compiler is built, this table is filled-in using the sizes 12876 of the structures used by each statement code defined in 12877 gimple.def. Since the operand vector is at the bottom of the 12878 structure, for a gimple code 'C' the offset is computed as sizeof 12879 (struct-of 'C') - sizeof (tree). 12880 12881 This mechanism adds one memory indirection to every access when 12882 using 'gimple_op'(), if this becomes a bottleneck, a pass can 12883 choose to memoize the result from 'gimple_ops'() and use that to 12884 access the operands. 12885 1288612.6.7 Operand validation 12887------------------------- 12888 12889When adding a new operand to a gimple statement, the operand will be 12890validated according to what each tuple accepts in its operand vector. 12891These predicates are called by the 'gimple_NAME_set_...()'. Each tuple 12892will use one of the following predicates (Note, this list is not 12893exhaustive): 12894 12895 -- GIMPLE function: bool is_gimple_val (tree t) 12896 Returns true if t is a "GIMPLE value", which are all the 12897 non-addressable stack variables (variables for which 12898 'is_gimple_reg' returns true) and constants (expressions for which 12899 'is_gimple_min_invariant' returns true). 12900 12901 -- GIMPLE function: bool is_gimple_addressable (tree t) 12902 Returns true if t is a symbol or memory reference whose address can 12903 be taken. 12904 12905 -- GIMPLE function: bool is_gimple_asm_val (tree t) 12906 Similar to 'is_gimple_val' but it also accepts hard registers. 12907 12908 -- GIMPLE function: bool is_gimple_call_addr (tree t) 12909 Return true if t is a valid expression to use as the function 12910 called by a 'GIMPLE_CALL'. 12911 12912 -- GIMPLE function: bool is_gimple_mem_ref_addr (tree t) 12913 Return true if t is a valid expression to use as first operand of a 12914 'MEM_REF' expression. 12915 12916 -- GIMPLE function: bool is_gimple_constant (tree t) 12917 Return true if t is a valid gimple constant. 12918 12919 -- GIMPLE function: bool is_gimple_min_invariant (tree t) 12920 Return true if t is a valid minimal invariant. This is different 12921 from constants, in that the specific value of t may not be known at 12922 compile time, but it is known that it doesn't change (e.g., the 12923 address of a function local variable). 12924 12925 -- GIMPLE function: bool is_gimple_ip_invariant (tree t) 12926 Return true if t is an interprocedural invariant. This means that 12927 t is a valid invariant in all functions (e.g. it can be an address 12928 of a global variable but not of a local one). 12929 12930 -- GIMPLE function: bool is_gimple_ip_invariant_address (tree t) 12931 Return true if t is an 'ADDR_EXPR' that does not change once the 12932 program is running (and which is valid in all functions). 12933 1293412.6.8 Statement validation 12935--------------------------- 12936 12937 -- GIMPLE function: bool is_gimple_assign (gimple g) 12938 Return true if the code of g is 'GIMPLE_ASSIGN'. 12939 12940 -- GIMPLE function: bool is_gimple_call (gimple g) 12941 Return true if the code of g is 'GIMPLE_CALL'. 12942 12943 -- GIMPLE function: bool is_gimple_debug (gimple g) 12944 Return true if the code of g is 'GIMPLE_DEBUG'. 12945 12946 -- GIMPLE function: bool gimple_assign_cast_p (const_gimple g) 12947 Return true if g is a 'GIMPLE_ASSIGN' that performs a type cast 12948 operation. 12949 12950 -- GIMPLE function: bool gimple_debug_bind_p (gimple g) 12951 Return true if g is a 'GIMPLE_DEBUG' that binds the value of an 12952 expression to a variable. 12953 12954 -- GIMPLE function: bool is_gimple_omp (gimple g) 12955 Return true if g is any of the OpenMP codes. 12956 12957 -- GIMPLE function: gimple_debug_begin_stmt_p (gimple g) 12958 Return true if g is a 'GIMPLE_DEBUG' that marks the beginning of a 12959 source statement. 12960 12961 -- GIMPLE function: gimple_debug_inline_entry_p (gimple g) 12962 Return true if g is a 'GIMPLE_DEBUG' that marks the entry point of 12963 an inlined function. 12964 12965 -- GIMPLE function: gimple_debug_nonbind_marker_p (gimple g) 12966 Return true if g is a 'GIMPLE_DEBUG' that marks a program location, 12967 without any variable binding. 12968 12969 12970File: gccint.info, Node: Manipulating GIMPLE statements, Next: Tuple specific accessors, Prev: Operands, Up: GIMPLE 12971 1297212.7 Manipulating GIMPLE statements 12973=================================== 12974 12975This section documents all the functions available to handle each of the 12976GIMPLE instructions. 12977 1297812.7.1 Common accessors 12979----------------------- 12980 12981The following are common accessors for gimple statements. 12982 12983 -- GIMPLE function: enum gimple_code gimple_code (gimple g) 12984 Return the code for statement 'G'. 12985 12986 -- GIMPLE function: basic_block gimple_bb (gimple g) 12987 Return the basic block to which statement 'G' belongs to. 12988 12989 -- GIMPLE function: tree gimple_block (gimple g) 12990 Return the lexical scope block holding statement 'G'. 12991 12992 -- GIMPLE function: tree gimple_expr_type (gimple stmt) 12993 Return the type of the main expression computed by 'STMT'. Return 12994 'void_type_node' if 'STMT' computes nothing. This will only return 12995 something meaningful for 'GIMPLE_ASSIGN', 'GIMPLE_COND' and 12996 'GIMPLE_CALL'. For all other tuple codes, it will return 12997 'void_type_node'. 12998 12999 -- GIMPLE function: enum tree_code gimple_expr_code (gimple stmt) 13000 Return the tree code for the expression computed by 'STMT'. This 13001 is only meaningful for 'GIMPLE_CALL', 'GIMPLE_ASSIGN' and 13002 'GIMPLE_COND'. If 'STMT' is 'GIMPLE_CALL', it will return 13003 'CALL_EXPR'. For 'GIMPLE_COND', it returns the code of the 13004 comparison predicate. For 'GIMPLE_ASSIGN' it returns the code of 13005 the operation performed by the 'RHS' of the assignment. 13006 13007 -- GIMPLE function: void gimple_set_block (gimple g, tree block) 13008 Set the lexical scope block of 'G' to 'BLOCK'. 13009 13010 -- GIMPLE function: location_t gimple_locus (gimple g) 13011 Return locus information for statement 'G'. 13012 13013 -- GIMPLE function: void gimple_set_locus (gimple g, location_t locus) 13014 Set locus information for statement 'G'. 13015 13016 -- GIMPLE function: bool gimple_locus_empty_p (gimple g) 13017 Return true if 'G' does not have locus information. 13018 13019 -- GIMPLE function: bool gimple_no_warning_p (gimple stmt) 13020 Return true if no warnings should be emitted for statement 'STMT'. 13021 13022 -- GIMPLE function: void gimple_set_visited (gimple stmt, bool 13023 visited_p) 13024 Set the visited status on statement 'STMT' to 'VISITED_P'. 13025 13026 -- GIMPLE function: bool gimple_visited_p (gimple stmt) 13027 Return the visited status on statement 'STMT'. 13028 13029 -- GIMPLE function: void gimple_set_plf (gimple stmt, enum plf_mask 13030 plf, bool val_p) 13031 Set pass local flag 'PLF' on statement 'STMT' to 'VAL_P'. 13032 13033 -- GIMPLE function: unsigned int gimple_plf (gimple stmt, enum plf_mask 13034 plf) 13035 Return the value of pass local flag 'PLF' on statement 'STMT'. 13036 13037 -- GIMPLE function: bool gimple_has_ops (gimple g) 13038 Return true if statement 'G' has register or memory operands. 13039 13040 -- GIMPLE function: bool gimple_has_mem_ops (gimple g) 13041 Return true if statement 'G' has memory operands. 13042 13043 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 13044 Return the number of operands for statement 'G'. 13045 13046 -- GIMPLE function: tree * gimple_ops (gimple g) 13047 Return the array of operands for statement 'G'. 13048 13049 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 13050 Return operand 'I' for statement 'G'. 13051 13052 -- GIMPLE function: tree * gimple_op_ptr (gimple g, unsigned i) 13053 Return a pointer to operand 'I' for statement 'G'. 13054 13055 -- GIMPLE function: void gimple_set_op (gimple g, unsigned i, tree op) 13056 Set operand 'I' of statement 'G' to 'OP'. 13057 13058 -- GIMPLE function: bitmap gimple_addresses_taken (gimple stmt) 13059 Return the set of symbols that have had their address taken by 13060 'STMT'. 13061 13062 -- GIMPLE function: struct def_optype_d * gimple_def_ops (gimple g) 13063 Return the set of 'DEF' operands for statement 'G'. 13064 13065 -- GIMPLE function: void gimple_set_def_ops (gimple g, struct 13066 def_optype_d *def) 13067 Set 'DEF' to be the set of 'DEF' operands for statement 'G'. 13068 13069 -- GIMPLE function: struct use_optype_d * gimple_use_ops (gimple g) 13070 Return the set of 'USE' operands for statement 'G'. 13071 13072 -- GIMPLE function: void gimple_set_use_ops (gimple g, struct 13073 use_optype_d *use) 13074 Set 'USE' to be the set of 'USE' operands for statement 'G'. 13075 13076 -- GIMPLE function: struct voptype_d * gimple_vuse_ops (gimple g) 13077 Return the set of 'VUSE' operands for statement 'G'. 13078 13079 -- GIMPLE function: void gimple_set_vuse_ops (gimple g, struct 13080 voptype_d *ops) 13081 Set 'OPS' to be the set of 'VUSE' operands for statement 'G'. 13082 13083 -- GIMPLE function: struct voptype_d * gimple_vdef_ops (gimple g) 13084 Return the set of 'VDEF' operands for statement 'G'. 13085 13086 -- GIMPLE function: void gimple_set_vdef_ops (gimple g, struct 13087 voptype_d *ops) 13088 Set 'OPS' to be the set of 'VDEF' operands for statement 'G'. 13089 13090 -- GIMPLE function: bitmap gimple_loaded_syms (gimple g) 13091 Return the set of symbols loaded by statement 'G'. Each element of 13092 the set is the 'DECL_UID' of the corresponding symbol. 13093 13094 -- GIMPLE function: bitmap gimple_stored_syms (gimple g) 13095 Return the set of symbols stored by statement 'G'. Each element of 13096 the set is the 'DECL_UID' of the corresponding symbol. 13097 13098 -- GIMPLE function: bool gimple_modified_p (gimple g) 13099 Return true if statement 'G' has operands and the modified field 13100 has been set. 13101 13102 -- GIMPLE function: bool gimple_has_volatile_ops (gimple stmt) 13103 Return true if statement 'STMT' contains volatile operands. 13104 13105 -- GIMPLE function: void gimple_set_has_volatile_ops (gimple stmt, bool 13106 volatilep) 13107 Return true if statement 'STMT' contains volatile operands. 13108 13109 -- GIMPLE function: void update_stmt (gimple s) 13110 Mark statement 'S' as modified, and update it. 13111 13112 -- GIMPLE function: void update_stmt_if_modified (gimple s) 13113 Update statement 'S' if it has been marked modified. 13114 13115 -- GIMPLE function: gimple gimple_copy (gimple stmt) 13116 Return a deep copy of statement 'STMT'. 13117 13118 13119File: gccint.info, Node: Tuple specific accessors, Next: GIMPLE sequences, Prev: Manipulating GIMPLE statements, Up: GIMPLE 13120 1312112.8 Tuple specific accessors 13122============================= 13123 13124* Menu: 13125 13126* GIMPLE_ASM:: 13127* GIMPLE_ASSIGN:: 13128* GIMPLE_BIND:: 13129* GIMPLE_CALL:: 13130* GIMPLE_CATCH:: 13131* GIMPLE_COND:: 13132* GIMPLE_DEBUG:: 13133* GIMPLE_EH_FILTER:: 13134* GIMPLE_LABEL:: 13135* GIMPLE_GOTO:: 13136* GIMPLE_NOP:: 13137* GIMPLE_OMP_ATOMIC_LOAD:: 13138* GIMPLE_OMP_ATOMIC_STORE:: 13139* GIMPLE_OMP_CONTINUE:: 13140* GIMPLE_OMP_CRITICAL:: 13141* GIMPLE_OMP_FOR:: 13142* GIMPLE_OMP_MASTER:: 13143* GIMPLE_OMP_ORDERED:: 13144* GIMPLE_OMP_PARALLEL:: 13145* GIMPLE_OMP_RETURN:: 13146* GIMPLE_OMP_SECTION:: 13147* GIMPLE_OMP_SECTIONS:: 13148* GIMPLE_OMP_SINGLE:: 13149* GIMPLE_PHI:: 13150* GIMPLE_RESX:: 13151* GIMPLE_RETURN:: 13152* GIMPLE_SWITCH:: 13153* GIMPLE_TRY:: 13154* GIMPLE_WITH_CLEANUP_EXPR:: 13155 13156 13157File: gccint.info, Node: GIMPLE_ASM, Next: GIMPLE_ASSIGN, Up: Tuple specific accessors 13158 1315912.8.1 'GIMPLE_ASM' 13160------------------- 13161 13162 -- GIMPLE function: gasm *gimple_build_asm_vec ( const char *string, 13163 vec<tree, va_gc> *inputs, vec<tree, va_gc> *outputs, vec<tree, 13164 va_gc> *clobbers, vec<tree, va_gc> *labels) 13165 Build a 'GIMPLE_ASM' statement. This statement is used for 13166 building in-line assembly constructs. 'STRING' is the assembly 13167 code. 'INPUTS', 'OUTPUTS', 'CLOBBERS' and 'LABELS' are the inputs, 13168 outputs, clobbered registers and labels. 13169 13170 -- GIMPLE function: unsigned gimple_asm_ninputs (const gasm *g) 13171 Return the number of input operands for 'GIMPLE_ASM' 'G'. 13172 13173 -- GIMPLE function: unsigned gimple_asm_noutputs (const gasm *g) 13174 Return the number of output operands for 'GIMPLE_ASM' 'G'. 13175 13176 -- GIMPLE function: unsigned gimple_asm_nclobbers (const gasm *g) 13177 Return the number of clobber operands for 'GIMPLE_ASM' 'G'. 13178 13179 -- GIMPLE function: tree gimple_asm_input_op (const gasm *g, unsigned 13180 index) 13181 Return input operand 'INDEX' of 'GIMPLE_ASM' 'G'. 13182 13183 -- GIMPLE function: void gimple_asm_set_input_op (gasm *g, unsigned 13184 index, tree in_op) 13185 Set 'IN_OP' to be input operand 'INDEX' in 'GIMPLE_ASM' 'G'. 13186 13187 -- GIMPLE function: tree gimple_asm_output_op (const gasm *g, unsigned 13188 index) 13189 Return output operand 'INDEX' of 'GIMPLE_ASM' 'G'. 13190 13191 -- GIMPLE function: void gimple_asm_set_output_op (gasm *g, unsigned 13192 index, tree out_op) 13193 Set 'OUT_OP' to be output operand 'INDEX' in 'GIMPLE_ASM' 'G'. 13194 13195 -- GIMPLE function: tree gimple_asm_clobber_op (const gasm *g, unsigned 13196 index) 13197 Return clobber operand 'INDEX' of 'GIMPLE_ASM' 'G'. 13198 13199 -- GIMPLE function: void gimple_asm_set_clobber_op (gasm *g, unsigned 13200 index, tree clobber_op) 13201 Set 'CLOBBER_OP' to be clobber operand 'INDEX' in 'GIMPLE_ASM' 'G'. 13202 13203 -- GIMPLE function: const char * gimple_asm_string (const gasm *g) 13204 Return the string representing the assembly instruction in 13205 'GIMPLE_ASM' 'G'. 13206 13207 -- GIMPLE function: bool gimple_asm_volatile_p (const gasm *g) 13208 Return true if 'G' is an asm statement marked volatile. 13209 13210 -- GIMPLE function: void gimple_asm_set_volatile (gasm *g, bool 13211 volatile_p) 13212 Mark asm statement 'G' as volatile or non-volatile based on 13213 'VOLATILE_P'. 13214 13215 13216File: gccint.info, Node: GIMPLE_ASSIGN, Next: GIMPLE_BIND, Prev: GIMPLE_ASM, Up: Tuple specific accessors 13217 1321812.8.2 'GIMPLE_ASSIGN' 13219---------------------- 13220 13221 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, tree rhs) 13222 Build a 'GIMPLE_ASSIGN' statement. The left-hand side is an lvalue 13223 passed in lhs. The right-hand side can be either a unary or binary 13224 tree expression. The expression tree rhs will be flattened and its 13225 operands assigned to the corresponding operand slots in the new 13226 statement. This function is useful when you already have a tree 13227 expression that you want to convert into a tuple. However, try to 13228 avoid building expression trees for the sole purpose of calling 13229 this function. If you already have the operands in separate trees, 13230 it is better to use 'gimple_build_assign' with 'enum tree_code' 13231 argument and separate arguments for each operand. 13232 13233 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 13234 tree_code subcode, tree op1, tree op2, tree op3) 13235 This function is similar to two operand 'gimple_build_assign', but 13236 is used to build a 'GIMPLE_ASSIGN' statement when the operands of 13237 the right-hand side of the assignment are already split into 13238 different operands. 13239 13240 The left-hand side is an lvalue passed in lhs. Subcode is the 13241 'tree_code' for the right-hand side of the assignment. Op1, op2 13242 and op3 are the operands. 13243 13244 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 13245 tree_code subcode, tree op1, tree op2) 13246 Like the above 5 operand 'gimple_build_assign', but with the last 13247 argument 'NULL' - this overload should not be used for 13248 'GIMPLE_TERNARY_RHS' assignments. 13249 13250 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 13251 tree_code subcode, tree op1) 13252 Like the above 4 operand 'gimple_build_assign', but with the last 13253 argument 'NULL' - this overload should be used only for 13254 'GIMPLE_UNARY_RHS' and 'GIMPLE_SINGLE_RHS' assignments. 13255 13256 -- GIMPLE function: gimple gimplify_assign (tree dst, tree src, 13257 gimple_seq *seq_p) 13258 Build a new 'GIMPLE_ASSIGN' tuple and append it to the end of 13259 '*SEQ_P'. 13260 13261 'DST'/'SRC' are the destination and source respectively. You can pass 13262ungimplified trees in 'DST' or 'SRC', in which case they will be 13263converted to a gimple operand if necessary. 13264 13265 This function returns the newly created 'GIMPLE_ASSIGN' tuple. 13266 13267 -- GIMPLE function: enum tree_code gimple_assign_rhs_code (gimple g) 13268 Return the code of the expression computed on the 'RHS' of 13269 assignment statement 'G'. 13270 13271 -- GIMPLE function: enum gimple_rhs_class gimple_assign_rhs_class 13272 (gimple g) 13273 Return the gimple rhs class of the code for the expression computed 13274 on the rhs of assignment statement 'G'. This will never return 13275 'GIMPLE_INVALID_RHS'. 13276 13277 -- GIMPLE function: tree gimple_assign_lhs (gimple g) 13278 Return the 'LHS' of assignment statement 'G'. 13279 13280 -- GIMPLE function: tree * gimple_assign_lhs_ptr (gimple g) 13281 Return a pointer to the 'LHS' of assignment statement 'G'. 13282 13283 -- GIMPLE function: tree gimple_assign_rhs1 (gimple g) 13284 Return the first operand on the 'RHS' of assignment statement 'G'. 13285 13286 -- GIMPLE function: tree * gimple_assign_rhs1_ptr (gimple g) 13287 Return the address of the first operand on the 'RHS' of assignment 13288 statement 'G'. 13289 13290 -- GIMPLE function: tree gimple_assign_rhs2 (gimple g) 13291 Return the second operand on the 'RHS' of assignment statement 'G'. 13292 13293 -- GIMPLE function: tree * gimple_assign_rhs2_ptr (gimple g) 13294 Return the address of the second operand on the 'RHS' of assignment 13295 statement 'G'. 13296 13297 -- GIMPLE function: tree gimple_assign_rhs3 (gimple g) 13298 Return the third operand on the 'RHS' of assignment statement 'G'. 13299 13300 -- GIMPLE function: tree * gimple_assign_rhs3_ptr (gimple g) 13301 Return the address of the third operand on the 'RHS' of assignment 13302 statement 'G'. 13303 13304 -- GIMPLE function: void gimple_assign_set_lhs (gimple g, tree lhs) 13305 Set 'LHS' to be the 'LHS' operand of assignment statement 'G'. 13306 13307 -- GIMPLE function: void gimple_assign_set_rhs1 (gimple g, tree rhs) 13308 Set 'RHS' to be the first operand on the 'RHS' of assignment 13309 statement 'G'. 13310 13311 -- GIMPLE function: void gimple_assign_set_rhs2 (gimple g, tree rhs) 13312 Set 'RHS' to be the second operand on the 'RHS' of assignment 13313 statement 'G'. 13314 13315 -- GIMPLE function: void gimple_assign_set_rhs3 (gimple g, tree rhs) 13316 Set 'RHS' to be the third operand on the 'RHS' of assignment 13317 statement 'G'. 13318 13319 -- GIMPLE function: bool gimple_assign_cast_p (const_gimple s) 13320 Return true if 'S' is a type-cast assignment. 13321 13322 13323File: gccint.info, Node: GIMPLE_BIND, Next: GIMPLE_CALL, Prev: GIMPLE_ASSIGN, Up: Tuple specific accessors 13324 1332512.8.3 'GIMPLE_BIND' 13326-------------------- 13327 13328 -- GIMPLE function: gbind *gimple_build_bind (tree vars, gimple_seq 13329 body) 13330 Build a 'GIMPLE_BIND' statement with a list of variables in 'VARS' 13331 and a body of statements in sequence 'BODY'. 13332 13333 -- GIMPLE function: tree gimple_bind_vars (const gbind *g) 13334 Return the variables declared in the 'GIMPLE_BIND' statement 'G'. 13335 13336 -- GIMPLE function: void gimple_bind_set_vars (gbind *g, tree vars) 13337 Set 'VARS' to be the set of variables declared in the 'GIMPLE_BIND' 13338 statement 'G'. 13339 13340 -- GIMPLE function: void gimple_bind_append_vars (gbind *g, tree vars) 13341 Append 'VARS' to the set of variables declared in the 'GIMPLE_BIND' 13342 statement 'G'. 13343 13344 -- GIMPLE function: gimple_seq gimple_bind_body (gbind *g) 13345 Return the GIMPLE sequence contained in the 'GIMPLE_BIND' statement 13346 'G'. 13347 13348 -- GIMPLE function: void gimple_bind_set_body (gbind *g, gimple_seq 13349 seq) 13350 Set 'SEQ' to be sequence contained in the 'GIMPLE_BIND' statement 13351 'G'. 13352 13353 -- GIMPLE function: void gimple_bind_add_stmt (gbind *gs, gimple stmt) 13354 Append a statement to the end of a 'GIMPLE_BIND''s body. 13355 13356 -- GIMPLE function: void gimple_bind_add_seq (gbind *gs, gimple_seq 13357 seq) 13358 Append a sequence of statements to the end of a 'GIMPLE_BIND''s 13359 body. 13360 13361 -- GIMPLE function: tree gimple_bind_block (const gbind *g) 13362 Return the 'TREE_BLOCK' node associated with 'GIMPLE_BIND' 13363 statement 'G'. This is analogous to the 'BIND_EXPR_BLOCK' field in 13364 trees. 13365 13366 -- GIMPLE function: void gimple_bind_set_block (gbind *g, tree block) 13367 Set 'BLOCK' to be the 'TREE_BLOCK' node associated with 13368 'GIMPLE_BIND' statement 'G'. 13369 13370 13371File: gccint.info, Node: GIMPLE_CALL, Next: GIMPLE_CATCH, Prev: GIMPLE_BIND, Up: Tuple specific accessors 13372 1337312.8.4 'GIMPLE_CALL' 13374-------------------- 13375 13376 -- GIMPLE function: gcall *gimple_build_call (tree fn, unsigned nargs, 13377 ...) 13378 Build a 'GIMPLE_CALL' statement to function 'FN'. The argument 13379 'FN' must be either a 'FUNCTION_DECL' or a gimple call address as 13380 determined by 'is_gimple_call_addr'. 'NARGS' are the number of 13381 arguments. The rest of the arguments follow the argument 'NARGS', 13382 and must be trees that are valid as rvalues in gimple (i.e., each 13383 operand is validated with 'is_gimple_operand'). 13384 13385 -- GIMPLE function: gcall *gimple_build_call_from_tree (tree call_expr, 13386 tree fnptrtype) 13387 Build a 'GIMPLE_CALL' from a 'CALL_EXPR' node. The arguments and 13388 the function are taken from the expression directly. The type of 13389 the 'GIMPLE_CALL' is set from the second parameter passed by a 13390 caller. This routine assumes that 'call_expr' is already in GIMPLE 13391 form. That is, its operands are GIMPLE values and the function 13392 call needs no further simplification. All the call flags in 13393 'call_expr' are copied over to the new 'GIMPLE_CALL'. 13394 13395 -- GIMPLE function: gcall *gimple_build_call_vec (tree fn, 'vec<tree>' 13396 args) 13397 Identical to 'gimple_build_call' but the arguments are stored in a 13398 'vec<tree>'. 13399 13400 -- GIMPLE function: tree gimple_call_lhs (gimple g) 13401 Return the 'LHS' of call statement 'G'. 13402 13403 -- GIMPLE function: tree * gimple_call_lhs_ptr (gimple g) 13404 Return a pointer to the 'LHS' of call statement 'G'. 13405 13406 -- GIMPLE function: void gimple_call_set_lhs (gimple g, tree lhs) 13407 Set 'LHS' to be the 'LHS' operand of call statement 'G'. 13408 13409 -- GIMPLE function: tree gimple_call_fn (gimple g) 13410 Return the tree node representing the function called by call 13411 statement 'G'. 13412 13413 -- GIMPLE function: void gimple_call_set_fn (gcall *g, tree fn) 13414 Set 'FN' to be the function called by call statement 'G'. This has 13415 to be a gimple value specifying the address of the called function. 13416 13417 -- GIMPLE function: tree gimple_call_fndecl (gimple g) 13418 If a given 'GIMPLE_CALL''s callee is a 'FUNCTION_DECL', return it. 13419 Otherwise return 'NULL'. This function is analogous to 13420 'get_callee_fndecl' in 'GENERIC'. 13421 13422 -- GIMPLE function: tree gimple_call_set_fndecl (gimple g, tree fndecl) 13423 Set the called function to 'FNDECL'. 13424 13425 -- GIMPLE function: tree gimple_call_return_type (const gcall *g) 13426 Return the type returned by call statement 'G'. 13427 13428 -- GIMPLE function: tree gimple_call_chain (gimple g) 13429 Return the static chain for call statement 'G'. 13430 13431 -- GIMPLE function: void gimple_call_set_chain (gcall *g, tree chain) 13432 Set 'CHAIN' to be the static chain for call statement 'G'. 13433 13434 -- GIMPLE function: unsigned gimple_call_num_args (gimple g) 13435 Return the number of arguments used by call statement 'G'. 13436 13437 -- GIMPLE function: tree gimple_call_arg (gimple g, unsigned index) 13438 Return the argument at position 'INDEX' for call statement 'G'. 13439 The first argument is 0. 13440 13441 -- GIMPLE function: tree * gimple_call_arg_ptr (gimple g, unsigned 13442 index) 13443 Return a pointer to the argument at position 'INDEX' for call 13444 statement 'G'. 13445 13446 -- GIMPLE function: void gimple_call_set_arg (gimple g, unsigned index, 13447 tree arg) 13448 Set 'ARG' to be the argument at position 'INDEX' for call statement 13449 'G'. 13450 13451 -- GIMPLE function: void gimple_call_set_tail (gcall *s) 13452 Mark call statement 'S' as being a tail call (i.e., a call just 13453 before the exit of a function). These calls are candidate for tail 13454 call optimization. 13455 13456 -- GIMPLE function: bool gimple_call_tail_p (gcall *s) 13457 Return true if 'GIMPLE_CALL' 'S' is marked as a tail call. 13458 13459 -- GIMPLE function: bool gimple_call_noreturn_p (gimple s) 13460 Return true if 'S' is a noreturn call. 13461 13462 -- GIMPLE function: gimple gimple_call_copy_skip_args (gcall *stmt, 13463 bitmap args_to_skip) 13464 Build a 'GIMPLE_CALL' identical to 'STMT' but skipping the 13465 arguments in the positions marked by the set 'ARGS_TO_SKIP'. 13466 13467 13468File: gccint.info, Node: GIMPLE_CATCH, Next: GIMPLE_COND, Prev: GIMPLE_CALL, Up: Tuple specific accessors 13469 1347012.8.5 'GIMPLE_CATCH' 13471--------------------- 13472 13473 -- GIMPLE function: gcatch *gimple_build_catch (tree types, gimple_seq 13474 handler) 13475 Build a 'GIMPLE_CATCH' statement. 'TYPES' are the tree types this 13476 catch handles. 'HANDLER' is a sequence of statements with the code 13477 for the handler. 13478 13479 -- GIMPLE function: tree gimple_catch_types (const gcatch *g) 13480 Return the types handled by 'GIMPLE_CATCH' statement 'G'. 13481 13482 -- GIMPLE function: tree * gimple_catch_types_ptr (gcatch *g) 13483 Return a pointer to the types handled by 'GIMPLE_CATCH' statement 13484 'G'. 13485 13486 -- GIMPLE function: gimple_seq gimple_catch_handler (gcatch *g) 13487 Return the GIMPLE sequence representing the body of the handler of 13488 'GIMPLE_CATCH' statement 'G'. 13489 13490 -- GIMPLE function: void gimple_catch_set_types (gcatch *g, tree t) 13491 Set 'T' to be the set of types handled by 'GIMPLE_CATCH' 'G'. 13492 13493 -- GIMPLE function: void gimple_catch_set_handler (gcatch *g, 13494 gimple_seq handler) 13495 Set 'HANDLER' to be the body of 'GIMPLE_CATCH' 'G'. 13496 13497 13498File: gccint.info, Node: GIMPLE_COND, Next: GIMPLE_DEBUG, Prev: GIMPLE_CATCH, Up: Tuple specific accessors 13499 1350012.8.6 'GIMPLE_COND' 13501-------------------- 13502 13503 -- GIMPLE function: gcond *gimple_build_cond ( enum tree_code 13504 pred_code, tree lhs, tree rhs, tree t_label, tree f_label) 13505 Build a 'GIMPLE_COND' statement. 'A' 'GIMPLE_COND' statement 13506 compares 'LHS' and 'RHS' and if the condition in 'PRED_CODE' is 13507 true, jump to the label in 't_label', otherwise jump to the label 13508 in 'f_label'. 'PRED_CODE' are relational operator tree codes like 13509 'EQ_EXPR', 'LT_EXPR', 'LE_EXPR', 'NE_EXPR', etc. 13510 13511 -- GIMPLE function: gcond *gimple_build_cond_from_tree (tree cond, tree 13512 t_label, tree f_label) 13513 Build a 'GIMPLE_COND' statement from the conditional expression 13514 tree 'COND'. 'T_LABEL' and 'F_LABEL' are as in 13515 'gimple_build_cond'. 13516 13517 -- GIMPLE function: enum tree_code gimple_cond_code (gimple g) 13518 Return the code of the predicate computed by conditional statement 13519 'G'. 13520 13521 -- GIMPLE function: void gimple_cond_set_code (gcond *g, enum tree_code 13522 code) 13523 Set 'CODE' to be the predicate code for the conditional statement 13524 'G'. 13525 13526 -- GIMPLE function: tree gimple_cond_lhs (gimple g) 13527 Return the 'LHS' of the predicate computed by conditional statement 13528 'G'. 13529 13530 -- GIMPLE function: void gimple_cond_set_lhs (gcond *g, tree lhs) 13531 Set 'LHS' to be the 'LHS' operand of the predicate computed by 13532 conditional statement 'G'. 13533 13534 -- GIMPLE function: tree gimple_cond_rhs (gimple g) 13535 Return the 'RHS' operand of the predicate computed by conditional 13536 'G'. 13537 13538 -- GIMPLE function: void gimple_cond_set_rhs (gcond *g, tree rhs) 13539 Set 'RHS' to be the 'RHS' operand of the predicate computed by 13540 conditional statement 'G'. 13541 13542 -- GIMPLE function: tree gimple_cond_true_label (const gcond *g) 13543 Return the label used by conditional statement 'G' when its 13544 predicate evaluates to true. 13545 13546 -- GIMPLE function: void gimple_cond_set_true_label (gcond *g, tree 13547 label) 13548 Set 'LABEL' to be the label used by conditional statement 'G' when 13549 its predicate evaluates to true. 13550 13551 -- GIMPLE function: void gimple_cond_set_false_label (gcond *g, tree 13552 label) 13553 Set 'LABEL' to be the label used by conditional statement 'G' when 13554 its predicate evaluates to false. 13555 13556 -- GIMPLE function: tree gimple_cond_false_label (const gcond *g) 13557 Return the label used by conditional statement 'G' when its 13558 predicate evaluates to false. 13559 13560 -- GIMPLE function: void gimple_cond_make_false (gcond *g) 13561 Set the conditional 'COND_STMT' to be of the form 'if (1 == 0)'. 13562 13563 -- GIMPLE function: void gimple_cond_make_true (gcond *g) 13564 Set the conditional 'COND_STMT' to be of the form 'if (1 == 1)'. 13565 13566 13567File: gccint.info, Node: GIMPLE_DEBUG, Next: GIMPLE_EH_FILTER, Prev: GIMPLE_COND, Up: Tuple specific accessors 13568 1356912.8.7 'GIMPLE_DEBUG' 13570--------------------- 13571 13572 -- GIMPLE function: gdebug *gimple_build_debug_bind (tree var, tree 13573 value, gimple stmt) 13574 Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_BIND' 13575 'subcode'. The effect of this statement is to tell debug 13576 information generation machinery that the value of user variable 13577 'var' is given by 'value' at that point, and to remain with that 13578 value until 'var' runs out of scope, a dynamically-subsequent debug 13579 bind statement overrides the binding, or conflicting values reach a 13580 control flow merge point. Even if components of the 'value' 13581 expression change afterwards, the variable is supposed to retain 13582 the same value, though not necessarily the same location. 13583 13584 It is expected that 'var' be most often a tree for automatic user 13585 variables ('VAR_DECL' or 'PARM_DECL') that satisfy the requirements 13586 for gimple registers, but it may also be a tree for a scalarized 13587 component of a user variable ('ARRAY_REF', 'COMPONENT_REF'), or a 13588 debug temporary ('DEBUG_EXPR_DECL'). 13589 13590 As for 'value', it can be an arbitrary tree expression, but it is 13591 recommended that it be in a suitable form for a gimple assignment 13592 'RHS'. It is not expected that user variables that could appear as 13593 'var' ever appear in 'value', because in the latter we'd have their 13594 'SSA_NAME's instead, but even if they were not in SSA form, user 13595 variables appearing in 'value' are to be regarded as part of the 13596 executable code space, whereas those in 'var' are to be regarded as 13597 part of the source code space. There is no way to refer to the 13598 value bound to a user variable within a 'value' expression. 13599 13600 If 'value' is 'GIMPLE_DEBUG_BIND_NOVALUE', debug information 13601 generation machinery is informed that the variable 'var' is 13602 unbound, i.e., that its value is indeterminate, which sometimes 13603 means it is really unavailable, and other times that the compiler 13604 could not keep track of it. 13605 13606 Block and location information for the newly-created stmt are taken 13607 from 'stmt', if given. 13608 13609 -- GIMPLE function: tree gimple_debug_bind_get_var (gimple stmt) 13610 Return the user variable VAR that is bound at 'stmt'. 13611 13612 -- GIMPLE function: tree gimple_debug_bind_get_value (gimple stmt) 13613 Return the value expression that is bound to a user variable at 13614 'stmt'. 13615 13616 -- GIMPLE function: tree * gimple_debug_bind_get_value_ptr (gimple 13617 stmt) 13618 Return a pointer to the value expression that is bound to a user 13619 variable at 'stmt'. 13620 13621 -- GIMPLE function: void gimple_debug_bind_set_var (gimple stmt, tree 13622 var) 13623 Modify the user variable bound at 'stmt' to VAR. 13624 13625 -- GIMPLE function: void gimple_debug_bind_set_value (gimple stmt, tree 13626 var) 13627 Modify the value bound to the user variable bound at 'stmt' to 13628 VALUE. 13629 13630 -- GIMPLE function: void gimple_debug_bind_reset_value (gimple stmt) 13631 Modify the value bound to the user variable bound at 'stmt' so that 13632 the variable becomes unbound. 13633 13634 -- GIMPLE function: bool gimple_debug_bind_has_value_p (gimple stmt) 13635 Return 'TRUE' if 'stmt' binds a user variable to a value, and 13636 'FALSE' if it unbinds the variable. 13637 13638 -- GIMPLE function: gimple gimple_build_debug_begin_stmt (tree block, 13639 location_t location) 13640 Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_BEGIN_STMT' 13641 'subcode'. The effect of this statement is to tell debug 13642 information generation machinery that the user statement at the 13643 given 'location' and 'block' starts at the point at which the 13644 statement is inserted. The intent is that side effects (e.g. 13645 variable bindings) of all prior user statements are observable, and 13646 that none of the side effects of subsequent user statements are. 13647 13648 -- GIMPLE function: gimple gimple_build_debug_inline_entry (tree block, 13649 location_t location) 13650 Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_INLINE_ENTRY' 13651 'subcode'. The effect of this statement is to tell debug 13652 information generation machinery that a function call at 'location' 13653 underwent inline substitution, that 'block' is the enclosing 13654 lexical block created for the substitution, and that at the point 13655 of the program in which the stmt is inserted, all parameters for 13656 the inlined function are bound to the respective arguments, and 13657 none of the side effects of its stmts are observable. 13658 13659 13660File: gccint.info, Node: GIMPLE_EH_FILTER, Next: GIMPLE_LABEL, Prev: GIMPLE_DEBUG, Up: Tuple specific accessors 13661 1366212.8.8 'GIMPLE_EH_FILTER' 13663------------------------- 13664 13665 -- GIMPLE function: geh_filter *gimple_build_eh_filter (tree types, 13666 gimple_seq failure) 13667 Build a 'GIMPLE_EH_FILTER' statement. 'TYPES' are the filter's 13668 types. 'FAILURE' is a sequence with the filter's failure action. 13669 13670 -- GIMPLE function: tree gimple_eh_filter_types (gimple g) 13671 Return the types handled by 'GIMPLE_EH_FILTER' statement 'G'. 13672 13673 -- GIMPLE function: tree * gimple_eh_filter_types_ptr (gimple g) 13674 Return a pointer to the types handled by 'GIMPLE_EH_FILTER' 13675 statement 'G'. 13676 13677 -- GIMPLE function: gimple_seq gimple_eh_filter_failure (gimple g) 13678 Return the sequence of statement to execute when 'GIMPLE_EH_FILTER' 13679 statement fails. 13680 13681 -- GIMPLE function: void gimple_eh_filter_set_types (geh_filter *g, 13682 tree types) 13683 Set 'TYPES' to be the set of types handled by 'GIMPLE_EH_FILTER' 13684 'G'. 13685 13686 -- GIMPLE function: void gimple_eh_filter_set_failure (geh_filter *g, 13687 gimple_seq failure) 13688 Set 'FAILURE' to be the sequence of statements to execute on 13689 failure for 'GIMPLE_EH_FILTER' 'G'. 13690 13691 -- GIMPLE function: tree gimple_eh_must_not_throw_fndecl ( geh_mnt 13692 *eh_mnt_stmt) 13693 Get the function decl to be called by the MUST_NOT_THROW region. 13694 13695 -- GIMPLE function: void gimple_eh_must_not_throw_set_fndecl ( geh_mnt 13696 *eh_mnt_stmt, tree decl) 13697 Set the function decl to be called by GS to DECL. 13698 13699 13700File: gccint.info, Node: GIMPLE_LABEL, Next: GIMPLE_GOTO, Prev: GIMPLE_EH_FILTER, Up: Tuple specific accessors 13701 1370212.8.9 'GIMPLE_LABEL' 13703--------------------- 13704 13705 -- GIMPLE function: glabel *gimple_build_label (tree label) 13706 Build a 'GIMPLE_LABEL' statement with corresponding to the tree 13707 label, 'LABEL'. 13708 13709 -- GIMPLE function: tree gimple_label_label (const glabel *g) 13710 Return the 'LABEL_DECL' node used by 'GIMPLE_LABEL' statement 'G'. 13711 13712 -- GIMPLE function: void gimple_label_set_label (glabel *g, tree label) 13713 Set 'LABEL' to be the 'LABEL_DECL' node used by 'GIMPLE_LABEL' 13714 statement 'G'. 13715 13716 13717File: gccint.info, Node: GIMPLE_GOTO, Next: GIMPLE_NOP, Prev: GIMPLE_LABEL, Up: Tuple specific accessors 13718 1371912.8.10 'GIMPLE_GOTO' 13720--------------------- 13721 13722 -- GIMPLE function: ggoto *gimple_build_goto (tree dest) 13723 Build a 'GIMPLE_GOTO' statement to label 'DEST'. 13724 13725 -- GIMPLE function: tree gimple_goto_dest (gimple g) 13726 Return the destination of the unconditional jump 'G'. 13727 13728 -- GIMPLE function: void gimple_goto_set_dest (ggoto *g, tree dest) 13729 Set 'DEST' to be the destination of the unconditional jump 'G'. 13730 13731 13732File: gccint.info, Node: GIMPLE_NOP, Next: GIMPLE_OMP_ATOMIC_LOAD, Prev: GIMPLE_GOTO, Up: Tuple specific accessors 13733 1373412.8.11 'GIMPLE_NOP' 13735-------------------- 13736 13737 -- GIMPLE function: gimple gimple_build_nop (void) 13738 Build a 'GIMPLE_NOP' statement. 13739 13740 -- GIMPLE function: bool gimple_nop_p (gimple g) 13741 Returns 'TRUE' if statement 'G' is a 'GIMPLE_NOP'. 13742 13743 13744File: gccint.info, Node: GIMPLE_OMP_ATOMIC_LOAD, Next: GIMPLE_OMP_ATOMIC_STORE, Prev: GIMPLE_NOP, Up: Tuple specific accessors 13745 1374612.8.12 'GIMPLE_OMP_ATOMIC_LOAD' 13747-------------------------------- 13748 13749 -- GIMPLE function: gomp_atomic_load *gimple_build_omp_atomic_load ( 13750 tree lhs, tree rhs) 13751 Build a 'GIMPLE_OMP_ATOMIC_LOAD' statement. 'LHS' is the left-hand 13752 side of the assignment. 'RHS' is the right-hand side of the 13753 assignment. 13754 13755 -- GIMPLE function: void gimple_omp_atomic_load_set_lhs ( 13756 gomp_atomic_load *g, tree lhs) 13757 Set the 'LHS' of an atomic load. 13758 13759 -- GIMPLE function: tree gimple_omp_atomic_load_lhs ( const 13760 gomp_atomic_load *g) 13761 Get the 'LHS' of an atomic load. 13762 13763 -- GIMPLE function: void gimple_omp_atomic_load_set_rhs ( 13764 gomp_atomic_load *g, tree rhs) 13765 Set the 'RHS' of an atomic set. 13766 13767 -- GIMPLE function: tree gimple_omp_atomic_load_rhs ( const 13768 gomp_atomic_load *g) 13769 Get the 'RHS' of an atomic set. 13770 13771 13772File: gccint.info, Node: GIMPLE_OMP_ATOMIC_STORE, Next: GIMPLE_OMP_CONTINUE, Prev: GIMPLE_OMP_ATOMIC_LOAD, Up: Tuple specific accessors 13773 1377412.8.13 'GIMPLE_OMP_ATOMIC_STORE' 13775--------------------------------- 13776 13777 -- GIMPLE function: gomp_atomic_store *gimple_build_omp_atomic_store ( 13778 tree val) 13779 Build a 'GIMPLE_OMP_ATOMIC_STORE' statement. 'VAL' is the value to 13780 be stored. 13781 13782 -- GIMPLE function: void gimple_omp_atomic_store_set_val ( 13783 gomp_atomic_store *g, tree val) 13784 Set the value being stored in an atomic store. 13785 13786 -- GIMPLE function: tree gimple_omp_atomic_store_val ( const 13787 gomp_atomic_store *g) 13788 Return the value being stored in an atomic store. 13789 13790 13791File: gccint.info, Node: GIMPLE_OMP_CONTINUE, Next: GIMPLE_OMP_CRITICAL, Prev: GIMPLE_OMP_ATOMIC_STORE, Up: Tuple specific accessors 13792 1379312.8.14 'GIMPLE_OMP_CONTINUE' 13794----------------------------- 13795 13796 -- GIMPLE function: gomp_continue *gimple_build_omp_continue ( tree 13797 control_def, tree control_use) 13798 Build a 'GIMPLE_OMP_CONTINUE' statement. 'CONTROL_DEF' is the 13799 definition of the control variable. 'CONTROL_USE' is the use of 13800 the control variable. 13801 13802 -- GIMPLE function: tree gimple_omp_continue_control_def ( const 13803 gomp_continue *s) 13804 Return the definition of the control variable on a 13805 'GIMPLE_OMP_CONTINUE' in 'S'. 13806 13807 -- GIMPLE function: tree gimple_omp_continue_control_def_ptr ( 13808 gomp_continue *s) 13809 Same as above, but return the pointer. 13810 13811 -- GIMPLE function: tree gimple_omp_continue_set_control_def ( 13812 gomp_continue *s) 13813 Set the control variable definition for a 'GIMPLE_OMP_CONTINUE' 13814 statement in 'S'. 13815 13816 -- GIMPLE function: tree gimple_omp_continue_control_use ( const 13817 gomp_continue *s) 13818 Return the use of the control variable on a 'GIMPLE_OMP_CONTINUE' 13819 in 'S'. 13820 13821 -- GIMPLE function: tree gimple_omp_continue_control_use_ptr ( 13822 gomp_continue *s) 13823 Same as above, but return the pointer. 13824 13825 -- GIMPLE function: tree gimple_omp_continue_set_control_use ( 13826 gomp_continue *s) 13827 Set the control variable use for a 'GIMPLE_OMP_CONTINUE' statement 13828 in 'S'. 13829 13830 13831File: gccint.info, Node: GIMPLE_OMP_CRITICAL, Next: GIMPLE_OMP_FOR, Prev: GIMPLE_OMP_CONTINUE, Up: Tuple specific accessors 13832 1383312.8.15 'GIMPLE_OMP_CRITICAL' 13834----------------------------- 13835 13836 -- GIMPLE function: gomp_critical *gimple_build_omp_critical ( 13837 gimple_seq body, tree name) 13838 Build a 'GIMPLE_OMP_CRITICAL' statement. 'BODY' is the sequence of 13839 statements for which only one thread can execute. 'NAME' is an 13840 optional identifier for this critical block. 13841 13842 -- GIMPLE function: tree gimple_omp_critical_name ( const gomp_critical 13843 *g) 13844 Return the name associated with 'OMP_CRITICAL' statement 'G'. 13845 13846 -- GIMPLE function: tree * gimple_omp_critical_name_ptr ( gomp_critical 13847 *g) 13848 Return a pointer to the name associated with 'OMP' critical 13849 statement 'G'. 13850 13851 -- GIMPLE function: void gimple_omp_critical_set_name ( gomp_critical 13852 *g, tree name) 13853 Set 'NAME' to be the name associated with 'OMP' critical statement 13854 'G'. 13855 13856 13857File: gccint.info, Node: GIMPLE_OMP_FOR, Next: GIMPLE_OMP_MASTER, Prev: GIMPLE_OMP_CRITICAL, Up: Tuple specific accessors 13858 1385912.8.16 'GIMPLE_OMP_FOR' 13860------------------------ 13861 13862 -- GIMPLE function: gomp_for *gimple_build_omp_for (gimple_seq body, 13863 tree clauses, tree index, tree initial, tree final, tree incr, 13864 gimple_seq pre_body, enum tree_code omp_for_cond) 13865 Build a 'GIMPLE_OMP_FOR' statement. 'BODY' is sequence of 13866 statements inside the for loop. 'CLAUSES', are any of the loop 13867 construct's clauses. 'PRE_BODY' is the sequence of statements that 13868 are loop invariant. 'INDEX' is the index variable. 'INITIAL' is 13869 the initial value of 'INDEX'. 'FINAL' is final value of 'INDEX'. 13870 OMP_FOR_COND is the predicate used to compare 'INDEX' and 'FINAL'. 13871 'INCR' is the increment expression. 13872 13873 -- GIMPLE function: tree gimple_omp_for_clauses (gimple g) 13874 Return the clauses associated with 'OMP_FOR' 'G'. 13875 13876 -- GIMPLE function: tree * gimple_omp_for_clauses_ptr (gimple g) 13877 Return a pointer to the 'OMP_FOR' 'G'. 13878 13879 -- GIMPLE function: void gimple_omp_for_set_clauses (gimple g, tree 13880 clauses) 13881 Set 'CLAUSES' to be the list of clauses associated with 'OMP_FOR' 13882 'G'. 13883 13884 -- GIMPLE function: tree gimple_omp_for_index (gimple g) 13885 Return the index variable for 'OMP_FOR' 'G'. 13886 13887 -- GIMPLE function: tree * gimple_omp_for_index_ptr (gimple g) 13888 Return a pointer to the index variable for 'OMP_FOR' 'G'. 13889 13890 -- GIMPLE function: void gimple_omp_for_set_index (gimple g, tree 13891 index) 13892 Set 'INDEX' to be the index variable for 'OMP_FOR' 'G'. 13893 13894 -- GIMPLE function: tree gimple_omp_for_initial (gimple g) 13895 Return the initial value for 'OMP_FOR' 'G'. 13896 13897 -- GIMPLE function: tree * gimple_omp_for_initial_ptr (gimple g) 13898 Return a pointer to the initial value for 'OMP_FOR' 'G'. 13899 13900 -- GIMPLE function: void gimple_omp_for_set_initial (gimple g, tree 13901 initial) 13902 Set 'INITIAL' to be the initial value for 'OMP_FOR' 'G'. 13903 13904 -- GIMPLE function: tree gimple_omp_for_final (gimple g) 13905 Return the final value for 'OMP_FOR' 'G'. 13906 13907 -- GIMPLE function: tree * gimple_omp_for_final_ptr (gimple g) 13908 turn a pointer to the final value for 'OMP_FOR' 'G'. 13909 13910 -- GIMPLE function: void gimple_omp_for_set_final (gimple g, tree 13911 final) 13912 Set 'FINAL' to be the final value for 'OMP_FOR' 'G'. 13913 13914 -- GIMPLE function: tree gimple_omp_for_incr (gimple g) 13915 Return the increment value for 'OMP_FOR' 'G'. 13916 13917 -- GIMPLE function: tree * gimple_omp_for_incr_ptr (gimple g) 13918 Return a pointer to the increment value for 'OMP_FOR' 'G'. 13919 13920 -- GIMPLE function: void gimple_omp_for_set_incr (gimple g, tree incr) 13921 Set 'INCR' to be the increment value for 'OMP_FOR' 'G'. 13922 13923 -- GIMPLE function: gimple_seq gimple_omp_for_pre_body (gimple g) 13924 Return the sequence of statements to execute before the 'OMP_FOR' 13925 statement 'G' starts. 13926 13927 -- GIMPLE function: void gimple_omp_for_set_pre_body (gimple g, 13928 gimple_seq pre_body) 13929 Set 'PRE_BODY' to be the sequence of statements to execute before 13930 the 'OMP_FOR' statement 'G' starts. 13931 13932 -- GIMPLE function: void gimple_omp_for_set_cond (gimple g, enum 13933 tree_code cond) 13934 Set 'COND' to be the condition code for 'OMP_FOR' 'G'. 13935 13936 -- GIMPLE function: enum tree_code gimple_omp_for_cond (gimple g) 13937 Return the condition code associated with 'OMP_FOR' 'G'. 13938 13939 13940File: gccint.info, Node: GIMPLE_OMP_MASTER, Next: GIMPLE_OMP_ORDERED, Prev: GIMPLE_OMP_FOR, Up: Tuple specific accessors 13941 1394212.8.17 'GIMPLE_OMP_MASTER' 13943--------------------------- 13944 13945 -- GIMPLE function: gimple gimple_build_omp_master (gimple_seq body) 13946 Build a 'GIMPLE_OMP_MASTER' statement. 'BODY' is the sequence of 13947 statements to be executed by just the master. 13948 13949 13950File: gccint.info, Node: GIMPLE_OMP_ORDERED, Next: GIMPLE_OMP_PARALLEL, Prev: GIMPLE_OMP_MASTER, Up: Tuple specific accessors 13951 1395212.8.18 'GIMPLE_OMP_ORDERED' 13953---------------------------- 13954 13955 -- GIMPLE function: gimple gimple_build_omp_ordered (gimple_seq body) 13956 Build a 'GIMPLE_OMP_ORDERED' statement. 13957 13958 'BODY' is the sequence of statements inside a loop that will executed 13959in sequence. 13960 13961 13962File: gccint.info, Node: GIMPLE_OMP_PARALLEL, Next: GIMPLE_OMP_RETURN, Prev: GIMPLE_OMP_ORDERED, Up: Tuple specific accessors 13963 1396412.8.19 'GIMPLE_OMP_PARALLEL' 13965----------------------------- 13966 13967 -- GIMPLE function: gomp_parallel *gimple_build_omp_parallel 13968 (gimple_seq body, tree clauses, tree child_fn, tree data_arg) 13969 Build a 'GIMPLE_OMP_PARALLEL' statement. 13970 13971 'BODY' is sequence of statements which are executed in parallel. 13972'CLAUSES', are the 'OMP' parallel construct's clauses. 'CHILD_FN' is 13973the function created for the parallel threads to execute. 'DATA_ARG' 13974are the shared data argument(s). 13975 13976 -- GIMPLE function: bool gimple_omp_parallel_combined_p (gimple g) 13977 Return true if 'OMP' parallel statement 'G' has the 13978 'GF_OMP_PARALLEL_COMBINED' flag set. 13979 13980 -- GIMPLE function: void gimple_omp_parallel_set_combined_p (gimple g) 13981 Set the 'GF_OMP_PARALLEL_COMBINED' field in 'OMP' parallel 13982 statement 'G'. 13983 13984 -- GIMPLE function: gimple_seq gimple_omp_body (gimple g) 13985 Return the body for the 'OMP' statement 'G'. 13986 13987 -- GIMPLE function: void gimple_omp_set_body (gimple g, gimple_seq 13988 body) 13989 Set 'BODY' to be the body for the 'OMP' statement 'G'. 13990 13991 -- GIMPLE function: tree gimple_omp_parallel_clauses (gimple g) 13992 Return the clauses associated with 'OMP_PARALLEL' 'G'. 13993 13994 -- GIMPLE function: tree * gimple_omp_parallel_clauses_ptr ( 13995 gomp_parallel *g) 13996 Return a pointer to the clauses associated with 'OMP_PARALLEL' 'G'. 13997 13998 -- GIMPLE function: void gimple_omp_parallel_set_clauses ( 13999 gomp_parallel *g, tree clauses) 14000 Set 'CLAUSES' to be the list of clauses associated with 14001 'OMP_PARALLEL' 'G'. 14002 14003 -- GIMPLE function: tree gimple_omp_parallel_child_fn ( const 14004 gomp_parallel *g) 14005 Return the child function used to hold the body of 'OMP_PARALLEL' 14006 'G'. 14007 14008 -- GIMPLE function: tree * gimple_omp_parallel_child_fn_ptr ( 14009 gomp_parallel *g) 14010 Return a pointer to the child function used to hold the body of 14011 'OMP_PARALLEL' 'G'. 14012 14013 -- GIMPLE function: void gimple_omp_parallel_set_child_fn ( 14014 gomp_parallel *g, tree child_fn) 14015 Set 'CHILD_FN' to be the child function for 'OMP_PARALLEL' 'G'. 14016 14017 -- GIMPLE function: tree gimple_omp_parallel_data_arg ( const 14018 gomp_parallel *g) 14019 Return the artificial argument used to send variables and values 14020 from the parent to the children threads in 'OMP_PARALLEL' 'G'. 14021 14022 -- GIMPLE function: tree * gimple_omp_parallel_data_arg_ptr ( 14023 gomp_parallel *g) 14024 Return a pointer to the data argument for 'OMP_PARALLEL' 'G'. 14025 14026 -- GIMPLE function: void gimple_omp_parallel_set_data_arg ( 14027 gomp_parallel *g, tree data_arg) 14028 Set 'DATA_ARG' to be the data argument for 'OMP_PARALLEL' 'G'. 14029 14030 14031File: gccint.info, Node: GIMPLE_OMP_RETURN, Next: GIMPLE_OMP_SECTION, Prev: GIMPLE_OMP_PARALLEL, Up: Tuple specific accessors 14032 1403312.8.20 'GIMPLE_OMP_RETURN' 14034--------------------------- 14035 14036 -- GIMPLE function: gimple gimple_build_omp_return (bool wait_p) 14037 Build a 'GIMPLE_OMP_RETURN' statement. 'WAIT_P' is true if this is 14038 a non-waiting return. 14039 14040 -- GIMPLE function: void gimple_omp_return_set_nowait (gimple s) 14041 Set the nowait flag on 'GIMPLE_OMP_RETURN' statement 'S'. 14042 14043 -- GIMPLE function: bool gimple_omp_return_nowait_p (gimple g) 14044 Return true if 'OMP' return statement 'G' has the 14045 'GF_OMP_RETURN_NOWAIT' flag set. 14046 14047 14048File: gccint.info, Node: GIMPLE_OMP_SECTION, Next: GIMPLE_OMP_SECTIONS, Prev: GIMPLE_OMP_RETURN, Up: Tuple specific accessors 14049 1405012.8.21 'GIMPLE_OMP_SECTION' 14051---------------------------- 14052 14053 -- GIMPLE function: gimple gimple_build_omp_section (gimple_seq body) 14054 Build a 'GIMPLE_OMP_SECTION' statement for a sections statement. 14055 14056 'BODY' is the sequence of statements in the section. 14057 14058 -- GIMPLE function: bool gimple_omp_section_last_p (gimple g) 14059 Return true if 'OMP' section statement 'G' has the 14060 'GF_OMP_SECTION_LAST' flag set. 14061 14062 -- GIMPLE function: void gimple_omp_section_set_last (gimple g) 14063 Set the 'GF_OMP_SECTION_LAST' flag on 'G'. 14064 14065 14066File: gccint.info, Node: GIMPLE_OMP_SECTIONS, Next: GIMPLE_OMP_SINGLE, Prev: GIMPLE_OMP_SECTION, Up: Tuple specific accessors 14067 1406812.8.22 'GIMPLE_OMP_SECTIONS' 14069----------------------------- 14070 14071 -- GIMPLE function: gomp_sections *gimple_build_omp_sections ( 14072 gimple_seq body, tree clauses) 14073 Build a 'GIMPLE_OMP_SECTIONS' statement. 'BODY' is a sequence of 14074 section statements. 'CLAUSES' are any of the 'OMP' sections 14075 construct's clauses: private, firstprivate, lastprivate, reduction, 14076 and nowait. 14077 14078 -- GIMPLE function: gimple gimple_build_omp_sections_switch (void) 14079 Build a 'GIMPLE_OMP_SECTIONS_SWITCH' statement. 14080 14081 -- GIMPLE function: tree gimple_omp_sections_control (gimple g) 14082 Return the control variable associated with the 14083 'GIMPLE_OMP_SECTIONS' in 'G'. 14084 14085 -- GIMPLE function: tree * gimple_omp_sections_control_ptr (gimple g) 14086 Return a pointer to the clauses associated with the 14087 'GIMPLE_OMP_SECTIONS' in 'G'. 14088 14089 -- GIMPLE function: void gimple_omp_sections_set_control (gimple g, 14090 tree control) 14091 Set 'CONTROL' to be the set of clauses associated with the 14092 'GIMPLE_OMP_SECTIONS' in 'G'. 14093 14094 -- GIMPLE function: tree gimple_omp_sections_clauses (gimple g) 14095 Return the clauses associated with 'OMP_SECTIONS' 'G'. 14096 14097 -- GIMPLE function: tree * gimple_omp_sections_clauses_ptr (gimple g) 14098 Return a pointer to the clauses associated with 'OMP_SECTIONS' 'G'. 14099 14100 -- GIMPLE function: void gimple_omp_sections_set_clauses (gimple g, 14101 tree clauses) 14102 Set 'CLAUSES' to be the set of clauses associated with 14103 'OMP_SECTIONS' 'G'. 14104 14105 14106File: gccint.info, Node: GIMPLE_OMP_SINGLE, Next: GIMPLE_PHI, Prev: GIMPLE_OMP_SECTIONS, Up: Tuple specific accessors 14107 1410812.8.23 'GIMPLE_OMP_SINGLE' 14109--------------------------- 14110 14111 -- GIMPLE function: gomp_single *gimple_build_omp_single ( gimple_seq 14112 body, tree clauses) 14113 Build a 'GIMPLE_OMP_SINGLE' statement. 'BODY' is the sequence of 14114 statements that will be executed once. 'CLAUSES' are any of the 14115 'OMP' single construct's clauses: private, firstprivate, 14116 copyprivate, nowait. 14117 14118 -- GIMPLE function: tree gimple_omp_single_clauses (gimple g) 14119 Return the clauses associated with 'OMP_SINGLE' 'G'. 14120 14121 -- GIMPLE function: tree * gimple_omp_single_clauses_ptr (gimple g) 14122 Return a pointer to the clauses associated with 'OMP_SINGLE' 'G'. 14123 14124 -- GIMPLE function: void gimple_omp_single_set_clauses ( gomp_single 14125 *g, tree clauses) 14126 Set 'CLAUSES' to be the clauses associated with 'OMP_SINGLE' 'G'. 14127 14128 14129File: gccint.info, Node: GIMPLE_PHI, Next: GIMPLE_RESX, Prev: GIMPLE_OMP_SINGLE, Up: Tuple specific accessors 14130 1413112.8.24 'GIMPLE_PHI' 14132-------------------- 14133 14134 -- GIMPLE function: unsigned gimple_phi_capacity (gimple g) 14135 Return the maximum number of arguments supported by 'GIMPLE_PHI' 14136 'G'. 14137 14138 -- GIMPLE function: unsigned gimple_phi_num_args (gimple g) 14139 Return the number of arguments in 'GIMPLE_PHI' 'G'. This must 14140 always be exactly the number of incoming edges for the basic block 14141 holding 'G'. 14142 14143 -- GIMPLE function: tree gimple_phi_result (gimple g) 14144 Return the 'SSA' name created by 'GIMPLE_PHI' 'G'. 14145 14146 -- GIMPLE function: tree * gimple_phi_result_ptr (gimple g) 14147 Return a pointer to the 'SSA' name created by 'GIMPLE_PHI' 'G'. 14148 14149 -- GIMPLE function: void gimple_phi_set_result (gphi *g, tree result) 14150 Set 'RESULT' to be the 'SSA' name created by 'GIMPLE_PHI' 'G'. 14151 14152 -- GIMPLE function: struct phi_arg_d * gimple_phi_arg (gimple g, index) 14153 Return the 'PHI' argument corresponding to incoming edge 'INDEX' 14154 for 'GIMPLE_PHI' 'G'. 14155 14156 -- GIMPLE function: void gimple_phi_set_arg (gphi *g, index, struct 14157 phi_arg_d * phiarg) 14158 Set 'PHIARG' to be the argument corresponding to incoming edge 14159 'INDEX' for 'GIMPLE_PHI' 'G'. 14160 14161 14162File: gccint.info, Node: GIMPLE_RESX, Next: GIMPLE_RETURN, Prev: GIMPLE_PHI, Up: Tuple specific accessors 14163 1416412.8.25 'GIMPLE_RESX' 14165--------------------- 14166 14167 -- GIMPLE function: gresx *gimple_build_resx (int region) 14168 Build a 'GIMPLE_RESX' statement which is a statement. This 14169 statement is a placeholder for _Unwind_Resume before we know if a 14170 function call or a branch is needed. 'REGION' is the exception 14171 region from which control is flowing. 14172 14173 -- GIMPLE function: int gimple_resx_region (const gresx *g) 14174 Return the region number for 'GIMPLE_RESX' 'G'. 14175 14176 -- GIMPLE function: void gimple_resx_set_region (gresx *g, int region) 14177 Set 'REGION' to be the region number for 'GIMPLE_RESX' 'G'. 14178 14179 14180File: gccint.info, Node: GIMPLE_RETURN, Next: GIMPLE_SWITCH, Prev: GIMPLE_RESX, Up: Tuple specific accessors 14181 1418212.8.26 'GIMPLE_RETURN' 14183----------------------- 14184 14185 -- GIMPLE function: greturn *gimple_build_return (tree retval) 14186 Build a 'GIMPLE_RETURN' statement whose return value is retval. 14187 14188 -- GIMPLE function: tree gimple_return_retval (const greturn *g) 14189 Return the return value for 'GIMPLE_RETURN' 'G'. 14190 14191 -- GIMPLE function: void gimple_return_set_retval (greturn *g, tree 14192 retval) 14193 Set 'RETVAL' to be the return value for 'GIMPLE_RETURN' 'G'. 14194 14195 14196File: gccint.info, Node: GIMPLE_SWITCH, Next: GIMPLE_TRY, Prev: GIMPLE_RETURN, Up: Tuple specific accessors 14197 1419812.8.27 'GIMPLE_SWITCH' 14199----------------------- 14200 14201 -- GIMPLE function: gswitch *gimple_build_switch (tree index, tree 14202 default_label, 'vec'<tree> *args) 14203 Build a 'GIMPLE_SWITCH' statement. 'INDEX' is the index variable 14204 to switch on, and 'DEFAULT_LABEL' represents the default label. 14205 'ARGS' is a vector of 'CASE_LABEL_EXPR' trees that contain the 14206 non-default case labels. Each label is a tree of code 14207 'CASE_LABEL_EXPR'. 14208 14209 -- GIMPLE function: unsigned gimple_switch_num_labels ( const gswitch 14210 *g) 14211 Return the number of labels associated with the switch statement 14212 'G'. 14213 14214 -- GIMPLE function: void gimple_switch_set_num_labels (gswitch *g, 14215 unsigned nlabels) 14216 Set 'NLABELS' to be the number of labels for the switch statement 14217 'G'. 14218 14219 -- GIMPLE function: tree gimple_switch_index (const gswitch *g) 14220 Return the index variable used by the switch statement 'G'. 14221 14222 -- GIMPLE function: void gimple_switch_set_index (gswitch *g, tree 14223 index) 14224 Set 'INDEX' to be the index variable for switch statement 'G'. 14225 14226 -- GIMPLE function: tree gimple_switch_label (const gswitch *g, 14227 unsigned index) 14228 Return the label numbered 'INDEX'. The default label is 0, 14229 followed by any labels in a switch statement. 14230 14231 -- GIMPLE function: void gimple_switch_set_label (gswitch *g, unsigned 14232 index, tree label) 14233 Set the label number 'INDEX' to 'LABEL'. 0 is always the default 14234 label. 14235 14236 -- GIMPLE function: tree gimple_switch_default_label ( const gswitch 14237 *g) 14238 Return the default label for a switch statement. 14239 14240 -- GIMPLE function: void gimple_switch_set_default_label (gswitch *g, 14241 tree label) 14242 Set the default label for a switch statement. 14243 14244 14245File: gccint.info, Node: GIMPLE_TRY, Next: GIMPLE_WITH_CLEANUP_EXPR, Prev: GIMPLE_SWITCH, Up: Tuple specific accessors 14246 1424712.8.28 'GIMPLE_TRY' 14248-------------------- 14249 14250 -- GIMPLE function: gtry *gimple_build_try (gimple_seq eval, gimple_seq 14251 cleanup, unsigned int kind) 14252 Build a 'GIMPLE_TRY' statement. 'EVAL' is a sequence with the 14253 expression to evaluate. 'CLEANUP' is a sequence of statements to 14254 run at clean-up time. 'KIND' is the enumeration value 14255 'GIMPLE_TRY_CATCH' if this statement denotes a try/catch construct 14256 or 'GIMPLE_TRY_FINALLY' if this statement denotes a try/finally 14257 construct. 14258 14259 -- GIMPLE function: enum gimple_try_flags gimple_try_kind (gimple g) 14260 Return the kind of try block represented by 'GIMPLE_TRY' 'G'. This 14261 is either 'GIMPLE_TRY_CATCH' or 'GIMPLE_TRY_FINALLY'. 14262 14263 -- GIMPLE function: bool gimple_try_catch_is_cleanup (gimple g) 14264 Return the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 14265 14266 -- GIMPLE function: gimple_seq gimple_try_eval (gimple g) 14267 Return the sequence of statements used as the body for 'GIMPLE_TRY' 14268 'G'. 14269 14270 -- GIMPLE function: gimple_seq gimple_try_cleanup (gimple g) 14271 Return the sequence of statements used as the cleanup body for 14272 'GIMPLE_TRY' 'G'. 14273 14274 -- GIMPLE function: void gimple_try_set_catch_is_cleanup (gimple g, 14275 bool catch_is_cleanup) 14276 Set the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 14277 14278 -- GIMPLE function: void gimple_try_set_eval (gtry *g, gimple_seq eval) 14279 Set 'EVAL' to be the sequence of statements to use as the body for 14280 'GIMPLE_TRY' 'G'. 14281 14282 -- GIMPLE function: void gimple_try_set_cleanup (gtry *g, gimple_seq 14283 cleanup) 14284 Set 'CLEANUP' to be the sequence of statements to use as the 14285 cleanup body for 'GIMPLE_TRY' 'G'. 14286 14287 14288File: gccint.info, Node: GIMPLE_WITH_CLEANUP_EXPR, Prev: GIMPLE_TRY, Up: Tuple specific accessors 14289 1429012.8.29 'GIMPLE_WITH_CLEANUP_EXPR' 14291---------------------------------- 14292 14293 -- GIMPLE function: gimple gimple_build_wce (gimple_seq cleanup) 14294 Build a 'GIMPLE_WITH_CLEANUP_EXPR' statement. 'CLEANUP' is the 14295 clean-up expression. 14296 14297 -- GIMPLE function: gimple_seq gimple_wce_cleanup (gimple g) 14298 Return the cleanup sequence for cleanup statement 'G'. 14299 14300 -- GIMPLE function: void gimple_wce_set_cleanup (gimple g, gimple_seq 14301 cleanup) 14302 Set 'CLEANUP' to be the cleanup sequence for 'G'. 14303 14304 -- GIMPLE function: bool gimple_wce_cleanup_eh_only (gimple g) 14305 Return the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple. 14306 14307 -- GIMPLE function: void gimple_wce_set_cleanup_eh_only (gimple g, bool 14308 eh_only_p) 14309 Set the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple. 14310 14311 14312File: gccint.info, Node: GIMPLE sequences, Next: Sequence iterators, Prev: Tuple specific accessors, Up: GIMPLE 14313 1431412.9 GIMPLE sequences 14315===================== 14316 14317GIMPLE sequences are the tuple equivalent of 'STATEMENT_LIST''s used in 14318'GENERIC'. They are used to chain statements together, and when used in 14319conjunction with sequence iterators, provide a framework for iterating 14320through statements. 14321 14322 GIMPLE sequences are of type struct 'gimple_sequence', but are more 14323commonly passed by reference to functions dealing with sequences. The 14324type for a sequence pointer is 'gimple_seq' which is the same as struct 14325'gimple_sequence' *. When declaring a local sequence, you can define a 14326local variable of type struct 'gimple_sequence'. When declaring a 14327sequence allocated on the garbage collected heap, use the function 14328'gimple_seq_alloc' documented below. 14329 14330 There are convenience functions for iterating through sequences in the 14331section entitled Sequence Iterators. 14332 14333 Below is a list of functions to manipulate and query sequences. 14334 14335 -- GIMPLE function: void gimple_seq_add_stmt (gimple_seq *seq, gimple 14336 g) 14337 Link a gimple statement to the end of the sequence *'SEQ' if 'G' is 14338 not 'NULL'. If *'SEQ' is 'NULL', allocate a sequence before 14339 linking. 14340 14341 -- GIMPLE function: void gimple_seq_add_seq (gimple_seq *dest, 14342 gimple_seq src) 14343 Append sequence 'SRC' to the end of sequence *'DEST' if 'SRC' is 14344 not 'NULL'. If *'DEST' is 'NULL', allocate a new sequence before 14345 appending. 14346 14347 -- GIMPLE function: gimple_seq gimple_seq_deep_copy (gimple_seq src) 14348 Perform a deep copy of sequence 'SRC' and return the result. 14349 14350 -- GIMPLE function: gimple_seq gimple_seq_reverse (gimple_seq seq) 14351 Reverse the order of the statements in the sequence 'SEQ'. Return 14352 'SEQ'. 14353 14354 -- GIMPLE function: gimple gimple_seq_first (gimple_seq s) 14355 Return the first statement in sequence 'S'. 14356 14357 -- GIMPLE function: gimple gimple_seq_last (gimple_seq s) 14358 Return the last statement in sequence 'S'. 14359 14360 -- GIMPLE function: void gimple_seq_set_last (gimple_seq s, gimple 14361 last) 14362 Set the last statement in sequence 'S' to the statement in 'LAST'. 14363 14364 -- GIMPLE function: void gimple_seq_set_first (gimple_seq s, gimple 14365 first) 14366 Set the first statement in sequence 'S' to the statement in 14367 'FIRST'. 14368 14369 -- GIMPLE function: void gimple_seq_init (gimple_seq s) 14370 Initialize sequence 'S' to an empty sequence. 14371 14372 -- GIMPLE function: gimple_seq gimple_seq_alloc (void) 14373 Allocate a new sequence in the garbage collected store and return 14374 it. 14375 14376 -- GIMPLE function: void gimple_seq_copy (gimple_seq dest, gimple_seq 14377 src) 14378 Copy the sequence 'SRC' into the sequence 'DEST'. 14379 14380 -- GIMPLE function: bool gimple_seq_empty_p (gimple_seq s) 14381 Return true if the sequence 'S' is empty. 14382 14383 -- GIMPLE function: gimple_seq bb_seq (basic_block bb) 14384 Returns the sequence of statements in 'BB'. 14385 14386 -- GIMPLE function: void set_bb_seq (basic_block bb, gimple_seq seq) 14387 Sets the sequence of statements in 'BB' to 'SEQ'. 14388 14389 -- GIMPLE function: bool gimple_seq_singleton_p (gimple_seq seq) 14390 Determine whether 'SEQ' contains exactly one statement. 14391 14392 14393File: gccint.info, Node: Sequence iterators, Next: Adding a new GIMPLE statement code, Prev: GIMPLE sequences, Up: GIMPLE 14394 1439512.10 Sequence iterators 14396======================== 14397 14398Sequence iterators are convenience constructs for iterating through 14399statements in a sequence. Given a sequence 'SEQ', here is a typical use 14400of gimple sequence iterators: 14401 14402 gimple_stmt_iterator gsi; 14403 14404 for (gsi = gsi_start (seq); !gsi_end_p (gsi); gsi_next (&gsi)) 14405 { 14406 gimple g = gsi_stmt (gsi); 14407 /* Do something with gimple statement G. */ 14408 } 14409 14410 Backward iterations are possible: 14411 14412 for (gsi = gsi_last (seq); !gsi_end_p (gsi); gsi_prev (&gsi)) 14413 14414 Forward and backward iterations on basic blocks are possible with 14415'gsi_start_bb' and 'gsi_last_bb'. 14416 14417 In the documentation below we sometimes refer to enum 14418'gsi_iterator_update'. The valid options for this enumeration are: 14419 14420 * 'GSI_NEW_STMT' Only valid when a single statement is added. Move 14421 the iterator to it. 14422 14423 * 'GSI_SAME_STMT' Leave the iterator at the same statement. 14424 14425 * 'GSI_CONTINUE_LINKING' Move iterator to whatever position is 14426 suitable for linking other statements in the same direction. 14427 14428 Below is a list of the functions used to manipulate and use statement 14429iterators. 14430 14431 -- GIMPLE function: gimple_stmt_iterator gsi_start (gimple_seq seq) 14432 Return a new iterator pointing to the sequence 'SEQ''s first 14433 statement. If 'SEQ' is empty, the iterator's basic block is 14434 'NULL'. Use 'gsi_start_bb' instead when the iterator needs to 14435 always have the correct basic block set. 14436 14437 -- GIMPLE function: gimple_stmt_iterator gsi_start_bb (basic_block bb) 14438 Return a new iterator pointing to the first statement in basic 14439 block 'BB'. 14440 14441 -- GIMPLE function: gimple_stmt_iterator gsi_last (gimple_seq seq) 14442 Return a new iterator initially pointing to the last statement of 14443 sequence 'SEQ'. If 'SEQ' is empty, the iterator's basic block is 14444 'NULL'. Use 'gsi_last_bb' instead when the iterator needs to 14445 always have the correct basic block set. 14446 14447 -- GIMPLE function: gimple_stmt_iterator gsi_last_bb (basic_block bb) 14448 Return a new iterator pointing to the last statement in basic block 14449 'BB'. 14450 14451 -- GIMPLE function: bool gsi_end_p (gimple_stmt_iterator i) 14452 Return 'TRUE' if at the end of 'I'. 14453 14454 -- GIMPLE function: bool gsi_one_before_end_p (gimple_stmt_iterator i) 14455 Return 'TRUE' if we're one statement before the end of 'I'. 14456 14457 -- GIMPLE function: void gsi_next (gimple_stmt_iterator *i) 14458 Advance the iterator to the next gimple statement. 14459 14460 -- GIMPLE function: void gsi_prev (gimple_stmt_iterator *i) 14461 Advance the iterator to the previous gimple statement. 14462 14463 -- GIMPLE function: gimple gsi_stmt (gimple_stmt_iterator i) 14464 Return the current stmt. 14465 14466 -- GIMPLE function: gimple_stmt_iterator gsi_after_labels (basic_block 14467 bb) 14468 Return a block statement iterator that points to the first 14469 non-label statement in block 'BB'. 14470 14471 -- GIMPLE function: gimple * gsi_stmt_ptr (gimple_stmt_iterator *i) 14472 Return a pointer to the current stmt. 14473 14474 -- GIMPLE function: basic_block gsi_bb (gimple_stmt_iterator i) 14475 Return the basic block associated with this iterator. 14476 14477 -- GIMPLE function: gimple_seq gsi_seq (gimple_stmt_iterator i) 14478 Return the sequence associated with this iterator. 14479 14480 -- GIMPLE function: void gsi_remove (gimple_stmt_iterator *i, bool 14481 remove_eh_info) 14482 Remove the current stmt from the sequence. The iterator is updated 14483 to point to the next statement. When 'REMOVE_EH_INFO' is true we 14484 remove the statement pointed to by iterator 'I' from the 'EH' 14485 tables. Otherwise we do not modify the 'EH' tables. Generally, 14486 'REMOVE_EH_INFO' should be true when the statement is going to be 14487 removed from the 'IL' and not reinserted elsewhere. 14488 14489 -- GIMPLE function: void gsi_link_seq_before (gimple_stmt_iterator *i, 14490 gimple_seq seq, enum gsi_iterator_update mode) 14491 Links the sequence of statements 'SEQ' before the statement pointed 14492 by iterator 'I'. 'MODE' indicates what to do with the iterator 14493 after insertion (see 'enum gsi_iterator_update' above). 14494 14495 -- GIMPLE function: void gsi_link_before (gimple_stmt_iterator *i, 14496 gimple g, enum gsi_iterator_update mode) 14497 Links statement 'G' before the statement pointed-to by iterator 14498 'I'. Updates iterator 'I' according to 'MODE'. 14499 14500 -- GIMPLE function: void gsi_link_seq_after (gimple_stmt_iterator *i, 14501 gimple_seq seq, enum gsi_iterator_update mode) 14502 Links sequence 'SEQ' after the statement pointed-to by iterator 14503 'I'. 'MODE' is as in 'gsi_insert_after'. 14504 14505 -- GIMPLE function: void gsi_link_after (gimple_stmt_iterator *i, 14506 gimple g, enum gsi_iterator_update mode) 14507 Links statement 'G' after the statement pointed-to by iterator 'I'. 14508 'MODE' is as in 'gsi_insert_after'. 14509 14510 -- GIMPLE function: gimple_seq gsi_split_seq_after 14511 (gimple_stmt_iterator i) 14512 Move all statements in the sequence after 'I' to a new sequence. 14513 Return this new sequence. 14514 14515 -- GIMPLE function: gimple_seq gsi_split_seq_before 14516 (gimple_stmt_iterator *i) 14517 Move all statements in the sequence before 'I' to a new sequence. 14518 Return this new sequence. 14519 14520 -- GIMPLE function: void gsi_replace (gimple_stmt_iterator *i, gimple 14521 stmt, bool update_eh_info) 14522 Replace the statement pointed-to by 'I' to 'STMT'. If 14523 'UPDATE_EH_INFO' is true, the exception handling information of the 14524 original statement is moved to the new statement. 14525 14526 -- GIMPLE function: void gsi_insert_before (gimple_stmt_iterator *i, 14527 gimple stmt, enum gsi_iterator_update mode) 14528 Insert statement 'STMT' before the statement pointed-to by iterator 14529 'I', update 'STMT''s basic block and scan it for new operands. 14530 'MODE' specifies how to update iterator 'I' after insertion (see 14531 enum 'gsi_iterator_update'). 14532 14533 -- GIMPLE function: void gsi_insert_seq_before (gimple_stmt_iterator 14534 *i, gimple_seq seq, enum gsi_iterator_update mode) 14535 Like 'gsi_insert_before', but for all the statements in 'SEQ'. 14536 14537 -- GIMPLE function: void gsi_insert_after (gimple_stmt_iterator *i, 14538 gimple stmt, enum gsi_iterator_update mode) 14539 Insert statement 'STMT' after the statement pointed-to by iterator 14540 'I', update 'STMT''s basic block and scan it for new operands. 14541 'MODE' specifies how to update iterator 'I' after insertion (see 14542 enum 'gsi_iterator_update'). 14543 14544 -- GIMPLE function: void gsi_insert_seq_after (gimple_stmt_iterator *i, 14545 gimple_seq seq, enum gsi_iterator_update mode) 14546 Like 'gsi_insert_after', but for all the statements in 'SEQ'. 14547 14548 -- GIMPLE function: gimple_stmt_iterator gsi_for_stmt (gimple stmt) 14549 Finds iterator for 'STMT'. 14550 14551 -- GIMPLE function: void gsi_move_after (gimple_stmt_iterator *from, 14552 gimple_stmt_iterator *to) 14553 Move the statement at 'FROM' so it comes right after the statement 14554 at 'TO'. 14555 14556 -- GIMPLE function: void gsi_move_before (gimple_stmt_iterator *from, 14557 gimple_stmt_iterator *to) 14558 Move the statement at 'FROM' so it comes right before the statement 14559 at 'TO'. 14560 14561 -- GIMPLE function: void gsi_move_to_bb_end (gimple_stmt_iterator 14562 *from, basic_block bb) 14563 Move the statement at 'FROM' to the end of basic block 'BB'. 14564 14565 -- GIMPLE function: void gsi_insert_on_edge (edge e, gimple stmt) 14566 Add 'STMT' to the pending list of edge 'E'. No actual insertion is 14567 made until a call to 'gsi_commit_edge_inserts'() is made. 14568 14569 -- GIMPLE function: void gsi_insert_seq_on_edge (edge e, gimple_seq 14570 seq) 14571 Add the sequence of statements in 'SEQ' to the pending list of edge 14572 'E'. No actual insertion is made until a call to 14573 'gsi_commit_edge_inserts'() is made. 14574 14575 -- GIMPLE function: basic_block gsi_insert_on_edge_immediate (edge e, 14576 gimple stmt) 14577 Similar to 'gsi_insert_on_edge'+'gsi_commit_edge_inserts'. If a 14578 new block has to be created, it is returned. 14579 14580 -- GIMPLE function: void gsi_commit_one_edge_insert (edge e, 14581 basic_block *new_bb) 14582 Commit insertions pending at edge 'E'. If a new block is created, 14583 set 'NEW_BB' to this block, otherwise set it to 'NULL'. 14584 14585 -- GIMPLE function: void gsi_commit_edge_inserts (void) 14586 This routine will commit all pending edge insertions, creating any 14587 new basic blocks which are necessary. 14588 14589 14590File: gccint.info, Node: Adding a new GIMPLE statement code, Next: Statement and operand traversals, Prev: Sequence iterators, Up: GIMPLE 14591 1459212.11 Adding a new GIMPLE statement code 14593======================================== 14594 14595The first step in adding a new GIMPLE statement code, is modifying the 14596file 'gimple.def', which contains all the GIMPLE codes. Then you must 14597add a corresponding gimple subclass located in 'gimple.h'. This in 14598turn, will require you to add a corresponding 'GTY' tag in 14599'gsstruct.def', and code to handle this tag in 'gss_for_code' which is 14600located in 'gimple.c'. 14601 14602 In order for the garbage collector to know the size of the structure 14603you created in 'gimple.h', you need to add a case to handle your new 14604GIMPLE statement in 'gimple_size' which is located in 'gimple.c'. 14605 14606 You will probably want to create a function to build the new gimple 14607statement in 'gimple.c'. The function should be called 14608'gimple_build_NEW-TUPLE-NAME', and should return the new tuple as a 14609pointer to the appropriate gimple subclass. 14610 14611 If your new statement requires accessors for any members or operands it 14612may have, put simple inline accessors in 'gimple.h' and any non-trivial 14613accessors in 'gimple.c' with a corresponding prototype in 'gimple.h'. 14614 14615 You should add the new statement subclass to the class hierarchy 14616diagram in 'gimple.texi'. 14617 14618 14619File: gccint.info, Node: Statement and operand traversals, Prev: Adding a new GIMPLE statement code, Up: GIMPLE 14620 1462112.12 Statement and operand traversals 14622====================================== 14623 14624There are two functions available for walking statements and sequences: 14625'walk_gimple_stmt' and 'walk_gimple_seq', accordingly, and a third 14626function for walking the operands in a statement: 'walk_gimple_op'. 14627 14628 -- GIMPLE function: tree walk_gimple_stmt (gimple_stmt_iterator *gsi, 14629 walk_stmt_fn callback_stmt, walk_tree_fn callback_op, struct 14630 walk_stmt_info *wi) 14631 This function is used to walk the current statement in 'GSI', 14632 optionally using traversal state stored in 'WI'. If 'WI' is 14633 'NULL', no state is kept during the traversal. 14634 14635 The callback 'CALLBACK_STMT' is called. If 'CALLBACK_STMT' returns 14636 true, it means that the callback function has handled all the 14637 operands of the statement and it is not necessary to walk its 14638 operands. 14639 14640 If 'CALLBACK_STMT' is 'NULL' or it returns false, 'CALLBACK_OP' is 14641 called on each operand of the statement via 'walk_gimple_op'. If 14642 'walk_gimple_op' returns non-'NULL' for any operand, the remaining 14643 operands are not scanned. 14644 14645 The return value is that returned by the last call to 14646 'walk_gimple_op', or 'NULL_TREE' if no 'CALLBACK_OP' is specified. 14647 14648 -- GIMPLE function: tree walk_gimple_op (gimple stmt, walk_tree_fn 14649 callback_op, struct walk_stmt_info *wi) 14650 Use this function to walk the operands of statement 'STMT'. Every 14651 operand is walked via 'walk_tree' with optional state information 14652 in 'WI'. 14653 14654 'CALLBACK_OP' is called on each operand of 'STMT' via 'walk_tree'. 14655 Additional parameters to 'walk_tree' must be stored in 'WI'. For 14656 each operand 'OP', 'walk_tree' is called as: 14657 14658 walk_tree (&OP, CALLBACK_OP, WI, PSET) 14659 14660 If 'CALLBACK_OP' returns non-'NULL' for an operand, the remaining 14661 operands are not scanned. The return value is that returned by the 14662 last call to 'walk_tree', or 'NULL_TREE' if no 'CALLBACK_OP' is 14663 specified. 14664 14665 -- GIMPLE function: tree walk_gimple_seq (gimple_seq seq, walk_stmt_fn 14666 callback_stmt, walk_tree_fn callback_op, struct walk_stmt_info 14667 *wi) 14668 This function walks all the statements in the sequence 'SEQ' 14669 calling 'walk_gimple_stmt' on each one. 'WI' is as in 14670 'walk_gimple_stmt'. If 'walk_gimple_stmt' returns non-'NULL', the 14671 walk is stopped and the value returned. Otherwise, all the 14672 statements are walked and 'NULL_TREE' returned. 14673 14674 14675File: gccint.info, Node: Tree SSA, Next: RTL, Prev: GIMPLE, Up: Top 14676 1467713 Analysis and Optimization of GIMPLE tuples 14678********************************************* 14679 14680GCC uses three main intermediate languages to represent the program 14681during compilation: GENERIC, GIMPLE and RTL. GENERIC is a 14682language-independent representation generated by each front end. It is 14683used to serve as an interface between the parser and optimizer. GENERIC 14684is a common representation that is able to represent programs written in 14685all the languages supported by GCC. 14686 14687 GIMPLE and RTL are used to optimize the program. GIMPLE is used for 14688target and language independent optimizations (e.g., inlining, constant 14689propagation, tail call elimination, redundancy elimination, etc). Much 14690like GENERIC, GIMPLE is a language independent, tree based 14691representation. However, it differs from GENERIC in that the GIMPLE 14692grammar is more restrictive: expressions contain no more than 3 operands 14693(except function calls), it has no control flow structures and 14694expressions with side effects are only allowed on the right hand side of 14695assignments. See the chapter describing GENERIC and GIMPLE for more 14696details. 14697 14698 This chapter describes the data structures and functions used in the 14699GIMPLE optimizers (also known as "tree optimizers" or "middle end"). In 14700particular, it focuses on all the macros, data structures, functions and 14701programming constructs needed to implement optimization passes for 14702GIMPLE. 14703 14704* Menu: 14705 14706* Annotations:: Attributes for variables. 14707* SSA Operands:: SSA names referenced by GIMPLE statements. 14708* SSA:: Static Single Assignment representation. 14709* Alias analysis:: Representing aliased loads and stores. 14710* Memory model:: Memory model used by the middle-end. 14711 14712 14713File: gccint.info, Node: Annotations, Next: SSA Operands, Up: Tree SSA 14714 1471513.1 Annotations 14716================ 14717 14718The optimizers need to associate attributes with variables during the 14719optimization process. For instance, we need to know whether a variable 14720has aliases. All these attributes are stored in data structures called 14721annotations which are then linked to the field 'ann' in 'struct 14722tree_common'. 14723 14724 14725File: gccint.info, Node: SSA Operands, Next: SSA, Prev: Annotations, Up: Tree SSA 14726 1472713.2 SSA Operands 14728================= 14729 14730Almost every GIMPLE statement will contain a reference to a variable or 14731memory location. Since statements come in different shapes and sizes, 14732their operands are going to be located at various spots inside the 14733statement's tree. To facilitate access to the statement's operands, 14734they are organized into lists associated inside each statement's 14735annotation. Each element in an operand list is a pointer to a 14736'VAR_DECL', 'PARM_DECL' or 'SSA_NAME' tree node. This provides a very 14737convenient way of examining and replacing operands. 14738 14739 Data flow analysis and optimization is done on all tree nodes 14740representing variables. Any node for which 'SSA_VAR_P' returns nonzero 14741is considered when scanning statement operands. However, not all 14742'SSA_VAR_P' variables are processed in the same way. For the purposes 14743of optimization, we need to distinguish between references to local 14744scalar variables and references to globals, statics, structures, arrays, 14745aliased variables, etc. The reason is simple, the compiler can gather 14746complete data flow information for a local scalar. On the other hand, a 14747global variable may be modified by a function call, it may not be 14748possible to keep track of all the elements of an array or the fields of 14749a structure, etc. 14750 14751 The operand scanner gathers two kinds of operands: "real" and 14752"virtual". An operand for which 'is_gimple_reg' returns true is 14753considered real, otherwise it is a virtual operand. We also distinguish 14754between uses and definitions. An operand is used if its value is loaded 14755by the statement (e.g., the operand at the RHS of an assignment). If 14756the statement assigns a new value to the operand, the operand is 14757considered a definition (e.g., the operand at the LHS of an assignment). 14758 14759 Virtual and real operands also have very different data flow 14760properties. Real operands are unambiguous references to the full object 14761that they represent. For instance, given 14762 14763 { 14764 int a, b; 14765 a = b 14766 } 14767 14768 Since 'a' and 'b' are non-aliased locals, the statement 'a = b' will 14769have one real definition and one real use because variable 'a' is 14770completely modified with the contents of variable 'b'. Real definition 14771are also known as "killing definitions". Similarly, the use of 'b' 14772reads all its bits. 14773 14774 In contrast, virtual operands are used with variables that can have a 14775partial or ambiguous reference. This includes structures, arrays, 14776globals, and aliased variables. In these cases, we have two types of 14777definitions. For globals, structures, and arrays, we can determine from 14778a statement whether a variable of these types has a killing definition. 14779If the variable does, then the statement is marked as having a "must 14780definition" of that variable. However, if a statement is only defining 14781a part of the variable (i.e. a field in a structure), or if we know that 14782a statement might define the variable but we cannot say for sure, then 14783we mark that statement as having a "may definition". For instance, 14784given 14785 14786 { 14787 int a, b, *p; 14788 14789 if (...) 14790 p = &a; 14791 else 14792 p = &b; 14793 *p = 5; 14794 return *p; 14795 } 14796 14797 The assignment '*p = 5' may be a definition of 'a' or 'b'. If we 14798cannot determine statically where 'p' is pointing to at the time of the 14799store operation, we create virtual definitions to mark that statement as 14800a potential definition site for 'a' and 'b'. Memory loads are similarly 14801marked with virtual use operands. Virtual operands are shown in tree 14802dumps right before the statement that contains them. To request a tree 14803dump with virtual operands, use the '-vops' option to '-fdump-tree': 14804 14805 { 14806 int a, b, *p; 14807 14808 if (...) 14809 p = &a; 14810 else 14811 p = &b; 14812 # a = VDEF <a> 14813 # b = VDEF <b> 14814 *p = 5; 14815 14816 # VUSE <a> 14817 # VUSE <b> 14818 return *p; 14819 } 14820 14821 Notice that 'VDEF' operands have two copies of the referenced variable. 14822This indicates that this is not a killing definition of that variable. 14823In this case we refer to it as a "may definition" or "aliased store". 14824The presence of the second copy of the variable in the 'VDEF' operand 14825will become important when the function is converted into SSA form. 14826This will be used to link all the non-killing definitions to prevent 14827optimizations from making incorrect assumptions about them. 14828 14829 Operands are updated as soon as the statement is finished via a call to 14830'update_stmt'. If statement elements are changed via 'SET_USE' or 14831'SET_DEF', then no further action is required (i.e., those macros take 14832care of updating the statement). If changes are made by manipulating 14833the statement's tree directly, then a call must be made to 'update_stmt' 14834when complete. Calling one of the 'bsi_insert' routines or 14835'bsi_replace' performs an implicit call to 'update_stmt'. 14836 1483713.2.1 Operand Iterators And Access Routines 14838-------------------------------------------- 14839 14840Operands are collected by 'tree-ssa-operands.c'. They are stored inside 14841each statement's annotation and can be accessed through either the 14842operand iterators or an access routine. 14843 14844 The following access routines are available for examining operands: 14845 14846 1. 'SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return 14847 NULL unless there is exactly one operand matching the specified 14848 flags. If there is exactly one operand, the operand is returned as 14849 either a 'tree', 'def_operand_p', or 'use_operand_p'. 14850 14851 tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags); 14852 use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES); 14853 def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS); 14854 14855 2. 'ZERO_SSA_OPERANDS': This macro returns true if there are no 14856 operands matching the specified flags. 14857 14858 if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS)) 14859 return; 14860 14861 3. 'NUM_SSA_OPERANDS': This macro Returns the number of operands 14862 matching 'flags'. This actually executes a loop to perform the 14863 count, so only use this if it is really needed. 14864 14865 int count = NUM_SSA_OPERANDS (stmt, flags) 14866 14867 If you wish to iterate over some or all operands, use the 14868'FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator. For example, to print 14869all the operands for a statement: 14870 14871 void 14872 print_ops (tree stmt) 14873 { 14874 ssa_op_iter; 14875 tree var; 14876 14877 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS) 14878 print_generic_expr (stderr, var, TDF_SLIM); 14879 } 14880 14881 How to choose the appropriate iterator: 14882 14883 1. Determine whether you are need to see the operand pointers, or just 14884 the trees, and choose the appropriate macro: 14885 14886 Need Macro: 14887 ---- ------- 14888 use_operand_p FOR_EACH_SSA_USE_OPERAND 14889 def_operand_p FOR_EACH_SSA_DEF_OPERAND 14890 tree FOR_EACH_SSA_TREE_OPERAND 14891 14892 2. You need to declare a variable of the type you are interested in, 14893 and an ssa_op_iter structure which serves as the loop controlling 14894 variable. 14895 14896 3. Determine which operands you wish to use, and specify the flags of 14897 those you are interested in. They are documented in 14898 'tree-ssa-operands.h': 14899 14900 #define SSA_OP_USE 0x01 /* Real USE operands. */ 14901 #define SSA_OP_DEF 0x02 /* Real DEF operands. */ 14902 #define SSA_OP_VUSE 0x04 /* VUSE operands. */ 14903 #define SSA_OP_VDEF 0x08 /* VDEF operands. */ 14904 14905 /* These are commonly grouped operand flags. */ 14906 #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE) 14907 #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VDEF) 14908 #define SSA_OP_ALL_VIRTUALS (SSA_OP_VIRTUAL_USES | SSA_OP_VIRTUAL_DEFS) 14909 #define SSA_OP_ALL_USES (SSA_OP_VIRTUAL_USES | SSA_OP_USE) 14910 #define SSA_OP_ALL_DEFS (SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF) 14911 #define SSA_OP_ALL_OPERANDS (SSA_OP_ALL_USES | SSA_OP_ALL_DEFS) 14912 14913 So if you want to look at the use pointers for all the 'USE' and 'VUSE' 14914operands, you would do something like: 14915 14916 use_operand_p use_p; 14917 ssa_op_iter iter; 14918 14919 FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE)) 14920 { 14921 process_use_ptr (use_p); 14922 } 14923 14924 The 'TREE' macro is basically the same as the 'USE' and 'DEF' macros, 14925only with the use or def dereferenced via 'USE_FROM_PTR (use_p)' and 14926'DEF_FROM_PTR (def_p)'. Since we aren't using operand pointers, use and 14927defs flags can be mixed. 14928 14929 tree var; 14930 ssa_op_iter iter; 14931 14932 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE) 14933 { 14934 print_generic_expr (stderr, var, TDF_SLIM); 14935 } 14936 14937 'VDEF's are broken into two flags, one for the 'DEF' portion 14938('SSA_OP_VDEF') and one for the USE portion ('SSA_OP_VUSE'). 14939 14940 There are many examples in the code, in addition to the documentation 14941in 'tree-ssa-operands.h' and 'ssa-iterators.h'. 14942 14943 There are also a couple of variants on the stmt iterators regarding PHI 14944nodes. 14945 14946 'FOR_EACH_PHI_ARG' Works exactly like 'FOR_EACH_SSA_USE_OPERAND', 14947except it works over 'PHI' arguments instead of statement operands. 14948 14949 /* Look at every virtual PHI use. */ 14950 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES) 14951 { 14952 my_code; 14953 } 14954 14955 /* Look at every real PHI use. */ 14956 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES) 14957 my_code; 14958 14959 /* Look at every PHI use. */ 14960 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES) 14961 my_code; 14962 14963 'FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like 14964'FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a 14965statement or a 'PHI' node. These should be used when it is appropriate 14966but they are not quite as efficient as the individual 'FOR_EACH_PHI' and 14967'FOR_EACH_SSA' routines. 14968 14969 FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags) 14970 { 14971 my_code; 14972 } 14973 14974 FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags) 14975 { 14976 my_code; 14977 } 14978 1497913.2.2 Immediate Uses 14980--------------------- 14981 14982Immediate use information is now always available. Using the immediate 14983use iterators, you may examine every use of any 'SSA_NAME'. For 14984instance, to change each use of 'ssa_var' to 'ssa_var2' and call 14985fold_stmt on each stmt after that is done: 14986 14987 use_operand_p imm_use_p; 14988 imm_use_iterator iterator; 14989 tree ssa_var, stmt; 14990 14991 14992 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 14993 { 14994 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 14995 SET_USE (imm_use_p, ssa_var_2); 14996 fold_stmt (stmt); 14997 } 14998 14999 There are 2 iterators which can be used. 'FOR_EACH_IMM_USE_FAST' is 15000used when the immediate uses are not changed, i.e., you are looking at 15001the uses, but not setting them. 15002 15003 If they do get changed, then care must be taken that things are not 15004changed under the iterators, so use the 'FOR_EACH_IMM_USE_STMT' and 15005'FOR_EACH_IMM_USE_ON_STMT' iterators. They attempt to preserve the 15006sanity of the use list by moving all the uses for a statement into a 15007controlled position, and then iterating over those uses. Then the 15008optimization can manipulate the stmt when all the uses have been 15009processed. This is a little slower than the FAST version since it adds 15010a placeholder element and must sort through the list a bit for each 15011statement. This placeholder element must be also be removed if the loop 15012is terminated early. The macro 'BREAK_FROM_IMM_USE_SAFE' is provided to 15013do this : 15014 15015 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 15016 { 15017 if (stmt == last_stmt) 15018 BREAK_FROM_SAFE_IMM_USE (iter); 15019 15020 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 15021 SET_USE (imm_use_p, ssa_var_2); 15022 fold_stmt (stmt); 15023 } 15024 15025 There are checks in 'verify_ssa' which verify that the immediate use 15026list is up to date, as well as checking that an optimization didn't 15027break from the loop without using this macro. It is safe to simply 15028'break'; from a 'FOR_EACH_IMM_USE_FAST' traverse. 15029 15030 Some useful functions and macros: 15031 1. 'has_zero_uses (ssa_var)' : Returns true if there are no uses of 15032 'ssa_var'. 15033 2. 'has_single_use (ssa_var)' : Returns true if there is only a single 15034 use of 'ssa_var'. 15035 3. 'single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' : 15036 Returns true if there is only a single use of 'ssa_var', and also 15037 returns the use pointer and statement it occurs in, in the second 15038 and third parameters. 15039 4. 'num_imm_uses (ssa_var)' : Returns the number of immediate uses of 15040 'ssa_var'. It is better not to use this if possible since it 15041 simply utilizes a loop to count the uses. 15042 5. 'PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a 'PHI' node, 15043 return the index number for the use. An assert is triggered if the 15044 use isn't located in a 'PHI' node. 15045 6. 'USE_STMT (use_p)' : Return the statement a use occurs in. 15046 15047 Note that uses are not put into an immediate use list until their 15048statement is actually inserted into the instruction stream via a 'bsi_*' 15049routine. 15050 15051 It is also still possible to utilize lazy updating of statements, but 15052this should be used only when absolutely required. Both alias analysis 15053and the dominator optimizations currently do this. 15054 15055 When lazy updating is being used, the immediate use information is out 15056of date and cannot be used reliably. Lazy updating is achieved by 15057simply marking statements modified via calls to 'gimple_set_modified' 15058instead of 'update_stmt'. When lazy updating is no longer required, all 15059the modified statements must have 'update_stmt' called in order to bring 15060them up to date. This must be done before the optimization is finished, 15061or 'verify_ssa' will trigger an abort. 15062 15063 This is done with a simple loop over the instruction stream: 15064 block_stmt_iterator bsi; 15065 basic_block bb; 15066 FOR_EACH_BB (bb) 15067 { 15068 for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi)) 15069 update_stmt_if_modified (bsi_stmt (bsi)); 15070 } 15071 15072 15073File: gccint.info, Node: SSA, Next: Alias analysis, Prev: SSA Operands, Up: Tree SSA 15074 1507513.3 Static Single Assignment 15076============================= 15077 15078Most of the tree optimizers rely on the data flow information provided 15079by the Static Single Assignment (SSA) form. We implement the SSA form 15080as described in 'R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K. 15081Zadeck. Efficiently Computing Static Single Assignment Form and the 15082Control Dependence Graph. ACM Transactions on Programming Languages and 15083Systems, 13(4):451-490, October 1991'. 15084 15085 The SSA form is based on the premise that program variables are 15086assigned in exactly one location in the program. Multiple assignments 15087to the same variable create new versions of that variable. Naturally, 15088actual programs are seldom in SSA form initially because variables tend 15089to be assigned multiple times. The compiler modifies the program 15090representation so that every time a variable is assigned in the code, a 15091new version of the variable is created. Different versions of the same 15092variable are distinguished by subscripting the variable name with its 15093version number. Variables used in the right-hand side of expressions 15094are renamed so that their version number matches that of the most recent 15095assignment. 15096 15097 We represent variable versions using 'SSA_NAME' nodes. The renaming 15098process in 'tree-ssa.c' wraps every real and virtual operand with an 15099'SSA_NAME' node which contains the version number and the statement that 15100created the 'SSA_NAME'. Only definitions and virtual definitions may 15101create new 'SSA_NAME' nodes. 15102 15103 Sometimes, flow of control makes it impossible to determine the most 15104recent version of a variable. In these cases, the compiler inserts an 15105artificial definition for that variable called "PHI function" or "PHI 15106node". This new definition merges all the incoming versions of the 15107variable to create a new name for it. For instance, 15108 15109 if (...) 15110 a_1 = 5; 15111 else if (...) 15112 a_2 = 2; 15113 else 15114 a_3 = 13; 15115 15116 # a_4 = PHI <a_1, a_2, a_3> 15117 return a_4; 15118 15119 Since it is not possible to determine which of the three branches will 15120be taken at runtime, we don't know which of 'a_1', 'a_2' or 'a_3' to use 15121at the return statement. So, the SSA renamer creates a new version 15122'a_4' which is assigned the result of "merging" 'a_1', 'a_2' and 'a_3'. 15123Hence, PHI nodes mean "one of these operands. I don't know which". 15124 15125 The following functions can be used to examine PHI nodes 15126 15127 -- Function: gimple_phi_result (PHI) 15128 Returns the 'SSA_NAME' created by PHI node PHI (i.e., PHI's LHS). 15129 15130 -- Function: gimple_phi_num_args (PHI) 15131 Returns the number of arguments in PHI. This number is exactly the 15132 number of incoming edges to the basic block holding PHI. 15133 15134 -- Function: gimple_phi_arg (PHI, I) 15135 Returns Ith argument of PHI. 15136 15137 -- Function: gimple_phi_arg_edge (PHI, I) 15138 Returns the incoming edge for the Ith argument of PHI. 15139 15140 -- Function: gimple_phi_arg_def (PHI, I) 15141 Returns the 'SSA_NAME' for the Ith argument of PHI. 15142 1514313.3.1 Preserving the SSA form 15144------------------------------ 15145 15146Some optimization passes make changes to the function that invalidate 15147the SSA property. This can happen when a pass has added new symbols or 15148changed the program so that variables that were previously aliased 15149aren't anymore. Whenever something like this happens, the affected 15150symbols must be renamed into SSA form again. Transformations that emit 15151new code or replicate existing statements will also need to update the 15152SSA form. 15153 15154 Since GCC implements two different SSA forms for register and virtual 15155variables, keeping the SSA form up to date depends on whether you are 15156updating register or virtual names. In both cases, the general idea 15157behind incremental SSA updates is similar: when new SSA names are 15158created, they typically are meant to replace other existing names in the 15159program. 15160 15161 For instance, given the following code: 15162 15163 1 L0: 15164 2 x_1 = PHI (0, x_5) 15165 3 if (x_1 < 10) 15166 4 if (x_1 > 7) 15167 5 y_2 = 0 15168 6 else 15169 7 y_3 = x_1 + x_7 15170 8 endif 15171 9 x_5 = x_1 + 1 15172 10 goto L0; 15173 11 endif 15174 15175 Suppose that we insert new names 'x_10' and 'x_11' (lines '4' and '8'). 15176 15177 1 L0: 15178 2 x_1 = PHI (0, x_5) 15179 3 if (x_1 < 10) 15180 4 x_10 = ... 15181 5 if (x_1 > 7) 15182 6 y_2 = 0 15183 7 else 15184 8 x_11 = ... 15185 9 y_3 = x_1 + x_7 15186 10 endif 15187 11 x_5 = x_1 + 1 15188 12 goto L0; 15189 13 endif 15190 15191 We want to replace all the uses of 'x_1' with the new definitions of 15192'x_10' and 'x_11'. Note that the only uses that should be replaced are 15193those at lines '5', '9' and '11'. Also, the use of 'x_7' at line '9' 15194should _not_ be replaced (this is why we cannot just mark symbol 'x' for 15195renaming). 15196 15197 Additionally, we may need to insert a PHI node at line '11' because 15198that is a merge point for 'x_10' and 'x_11'. So the use of 'x_1' at 15199line '11' will be replaced with the new PHI node. The insertion of PHI 15200nodes is optional. They are not strictly necessary to preserve the SSA 15201form, and depending on what the caller inserted, they may not even be 15202useful for the optimizers. 15203 15204 Updating the SSA form is a two step process. First, the pass has to 15205identify which names need to be updated and/or which symbols need to be 15206renamed into SSA form for the first time. When new names are introduced 15207to replace existing names in the program, the mapping between the old 15208and the new names are registered by calling 'register_new_name_mapping' 15209(note that if your pass creates new code by duplicating basic blocks, 15210the call to 'tree_duplicate_bb' will set up the necessary mappings 15211automatically). 15212 15213 After the replacement mappings have been registered and new symbols 15214marked for renaming, a call to 'update_ssa' makes the registered 15215changes. This can be done with an explicit call or by creating 'TODO' 15216flags in the 'tree_opt_pass' structure for your pass. There are several 15217'TODO' flags that control the behavior of 'update_ssa': 15218 15219 * 'TODO_update_ssa'. Update the SSA form inserting PHI nodes for 15220 newly exposed symbols and virtual names marked for updating. When 15221 updating real names, only insert PHI nodes for a real name 'O_j' in 15222 blocks reached by all the new and old definitions for 'O_j'. If 15223 the iterated dominance frontier for 'O_j' is not pruned, we may end 15224 up inserting PHI nodes in blocks that have one or more edges with 15225 no incoming definition for 'O_j'. This would lead to uninitialized 15226 warnings for 'O_j''s symbol. 15227 15228 * 'TODO_update_ssa_no_phi'. Update the SSA form without inserting 15229 any new PHI nodes at all. This is used by passes that have either 15230 inserted all the PHI nodes themselves or passes that need only to 15231 patch use-def and def-def chains for virtuals (e.g., DCE). 15232 15233 * 'TODO_update_ssa_full_phi'. Insert PHI nodes everywhere they are 15234 needed. No pruning of the IDF is done. This is used by passes 15235 that need the PHI nodes for 'O_j' even if it means that some 15236 arguments will come from the default definition of 'O_j''s symbol 15237 (e.g., 'pass_linear_transform'). 15238 15239 WARNING: If you need to use this flag, chances are that your pass 15240 may be doing something wrong. Inserting PHI nodes for an old name 15241 where not all edges carry a new replacement may lead to silent 15242 codegen errors or spurious uninitialized warnings. 15243 15244 * 'TODO_update_ssa_only_virtuals'. Passes that update the SSA form 15245 on their own may want to delegate the updating of virtual names to 15246 the generic updater. Since FUD chains are easier to maintain, this 15247 simplifies the work they need to do. NOTE: If this flag is used, 15248 any OLD->NEW mappings for real names are explicitly destroyed and 15249 only the symbols marked for renaming are processed. 15250 1525113.3.2 Examining 'SSA_NAME' nodes 15252--------------------------------- 15253 15254The following macros can be used to examine 'SSA_NAME' nodes 15255 15256 -- Macro: SSA_NAME_DEF_STMT (VAR) 15257 Returns the statement S that creates the 'SSA_NAME' VAR. If S is 15258 an empty statement (i.e., 'IS_EMPTY_STMT (S)' returns 'true'), it 15259 means that the first reference to this variable is a USE or a VUSE. 15260 15261 -- Macro: SSA_NAME_VERSION (VAR) 15262 Returns the version number of the 'SSA_NAME' object VAR. 15263 1526413.3.3 Walking the dominator tree 15265--------------------------------- 15266 15267 -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB) 15268 15269 This function walks the dominator tree for the current CFG calling 15270 a set of callback functions defined in STRUCT DOM_WALK_DATA in 15271 'domwalk.h'. The call back functions you need to define give you 15272 hooks to execute custom code at various points during traversal: 15273 15274 1. Once to initialize any local data needed while processing BB 15275 and its children. This local data is pushed into an internal 15276 stack which is automatically pushed and popped as the walker 15277 traverses the dominator tree. 15278 15279 2. Once before traversing all the statements in the BB. 15280 15281 3. Once for every statement inside BB. 15282 15283 4. Once after traversing all the statements and before recursing 15284 into BB's dominator children. 15285 15286 5. It then recurses into all the dominator children of BB. 15287 15288 6. After recursing into all the dominator children of BB it can, 15289 optionally, traverse every statement in BB again (i.e., 15290 repeating steps 2 and 3). 15291 15292 7. Once after walking the statements in BB and BB's dominator 15293 children. At this stage, the block local data stack is 15294 popped. 15295 15296 15297File: gccint.info, Node: Alias analysis, Next: Memory model, Prev: SSA, Up: Tree SSA 15298 1529913.4 Alias analysis 15300=================== 15301 15302Alias analysis in GIMPLE SSA form consists of two pieces. First the 15303virtual SSA web ties conflicting memory accesses and provides a SSA 15304use-def chain and SSA immediate-use chains for walking possibly 15305dependent memory accesses. Second an alias-oracle can be queried to 15306disambiguate explicit and implicit memory references. 15307 15308 1. Memory SSA form. 15309 15310 All statements that may use memory have exactly one accompanied use 15311 of a virtual SSA name that represents the state of memory at the 15312 given point in the IL. 15313 15314 All statements that may define memory have exactly one accompanied 15315 definition of a virtual SSA name using the previous state of memory 15316 and defining the new state of memory after the given point in the 15317 IL. 15318 15319 int i; 15320 int foo (void) 15321 { 15322 # .MEM_3 = VDEF <.MEM_2(D)> 15323 i = 1; 15324 # VUSE <.MEM_3> 15325 return i; 15326 } 15327 15328 The virtual SSA names in this case are '.MEM_2(D)' and '.MEM_3'. 15329 The store to the global variable 'i' defines '.MEM_3' invalidating 15330 '.MEM_2(D)'. The load from 'i' uses that new state '.MEM_3'. 15331 15332 The virtual SSA web serves as constraints to SSA optimizers 15333 preventing illegitimate code-motion and optimization. It also 15334 provides a way to walk related memory statements. 15335 15336 2. Points-to and escape analysis. 15337 15338 Points-to analysis builds a set of constraints from the GIMPLE SSA 15339 IL representing all pointer operations and facts we do or do not 15340 know about pointers. Solving this set of constraints yields a 15341 conservatively correct solution for each pointer variable in the 15342 program (though we are only interested in SSA name pointers) as to 15343 what it may possibly point to. 15344 15345 This points-to solution for a given SSA name pointer is stored in 15346 the 'pt_solution' sub-structure of the 'SSA_NAME_PTR_INFO' record. 15347 The following accessor functions are available: 15348 15349 * 'pt_solution_includes' 15350 * 'pt_solutions_intersect' 15351 15352 Points-to analysis also computes the solution for two special set 15353 of pointers, 'ESCAPED' and 'CALLUSED'. Those represent all memory 15354 that has escaped the scope of analysis or that is used by pure or 15355 nested const calls. 15356 15357 3. Type-based alias analysis 15358 15359 Type-based alias analysis is frontend dependent though generic 15360 support is provided by the middle-end in 'alias.c'. TBAA code is 15361 used by both tree optimizers and RTL optimizers. 15362 15363 Every language that wishes to perform language-specific alias 15364 analysis should define a function that computes, given a 'tree' 15365 node, an alias set for the node. Nodes in different alias sets are 15366 not allowed to alias. For an example, see the C front-end function 15367 'c_get_alias_set'. 15368 15369 4. Tree alias-oracle 15370 15371 The tree alias-oracle provides means to disambiguate two memory 15372 references and memory references against statements. The following 15373 queries are available: 15374 15375 * 'refs_may_alias_p' 15376 * 'ref_maybe_used_by_stmt_p' 15377 * 'stmt_may_clobber_ref_p' 15378 15379 In addition to those two kind of statement walkers are available 15380 walking statements related to a reference ref. 15381 'walk_non_aliased_vuses' walks over dominating memory defining 15382 statements and calls back if the statement does not clobber ref 15383 providing the non-aliased VUSE. The walk stops at the first 15384 clobbering statement or if asked to. 'walk_aliased_vdefs' walks 15385 over dominating memory defining statements and calls back on each 15386 statement clobbering ref providing its aliasing VDEF. The walk 15387 stops if asked to. 15388 15389 15390File: gccint.info, Node: Memory model, Prev: Alias analysis, Up: Tree SSA 15391 1539213.5 Memory model 15393================= 15394 15395The memory model used by the middle-end models that of the C/C++ 15396languages. The middle-end has the notion of an effective type of a 15397memory region which is used for type-based alias analysis. 15398 15399 The following is a refinement of ISO C99 6.5/6, clarifying the block 15400copy case to follow common sense and extending the concept of a dynamic 15401effective type to objects with a declared type as required for C++. 15402 15403 The effective type of an object for an access to its stored value is 15404 the declared type of the object or the effective type determined by 15405 a previous store to it. If a value is stored into an object through 15406 an lvalue having a type that is not a character type, then the 15407 type of the lvalue becomes the effective type of the object for that 15408 access and for subsequent accesses that do not modify the stored value. 15409 If a value is copied into an object using memcpy or memmove, 15410 or is copied as an array of character type, then the effective type 15411 of the modified object for that access and for subsequent accesses that 15412 do not modify the value is undetermined. For all other accesses to an 15413 object, the effective type of the object is simply the type of the 15414 lvalue used for the access. 15415 15416 15417File: gccint.info, Node: RTL, Next: Control Flow, Prev: Tree SSA, Up: Top 15418 1541914 RTL Representation 15420********************* 15421 15422The last part of the compiler work is done on a low-level intermediate 15423representation called Register Transfer Language. In this language, the 15424instructions to be output are described, pretty much one by one, in an 15425algebraic form that describes what the instruction does. 15426 15427 RTL is inspired by Lisp lists. It has both an internal form, made up 15428of structures that point at other structures, and a textual form that is 15429used in the machine description and in printed debugging dumps. The 15430textual form uses nested parentheses to indicate the pointers in the 15431internal form. 15432 15433* Menu: 15434 15435* RTL Objects:: Expressions vs vectors vs strings vs integers. 15436* RTL Classes:: Categories of RTL expression objects, and their structure. 15437* Accessors:: Macros to access expression operands or vector elts. 15438* Special Accessors:: Macros to access specific annotations on RTL. 15439* Flags:: Other flags in an RTL expression. 15440* Machine Modes:: Describing the size and format of a datum. 15441* Constants:: Expressions with constant values. 15442* Regs and Memory:: Expressions representing register contents or memory. 15443* Arithmetic:: Expressions representing arithmetic on other expressions. 15444* Comparisons:: Expressions representing comparison of expressions. 15445* Bit-Fields:: Expressions representing bit-fields in memory or reg. 15446* Vector Operations:: Expressions involving vector datatypes. 15447* Conversions:: Extending, truncating, floating or fixing. 15448* RTL Declarations:: Declaring volatility, constancy, etc. 15449* Side Effects:: Expressions for storing in registers, etc. 15450* Incdec:: Embedded side-effects for autoincrement addressing. 15451* Assembler:: Representing 'asm' with operands. 15452* Debug Information:: Expressions representing debugging information. 15453* Insns:: Expression types for entire insns. 15454* Calls:: RTL representation of function call insns. 15455* Sharing:: Some expressions are unique; others *must* be copied. 15456* Reading RTL:: Reading textual RTL from a file. 15457 15458 15459File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL 15460 1546114.1 RTL Object Types 15462===================== 15463 15464RTL uses five kinds of objects: expressions, integers, wide integers, 15465strings and vectors. Expressions are the most important ones. An RTL 15466expression ("RTX", for short) is a C structure, but it is usually 15467referred to with a pointer; a type that is given the typedef name 'rtx'. 15468 15469 An integer is simply an 'int'; their written form uses decimal digits. 15470A wide integer is an integral object whose type is 'HOST_WIDE_INT'; 15471their written form uses decimal digits. 15472 15473 A string is a sequence of characters. In core it is represented as a 15474'char *' in usual C fashion, and it is written in C syntax as well. 15475However, strings in RTL may never be null. If you write an empty string 15476in a machine description, it is represented in core as a null pointer 15477rather than as a pointer to a null character. In certain contexts, 15478these null pointers instead of strings are valid. Within RTL code, 15479strings are most commonly found inside 'symbol_ref' expressions, but 15480they appear in other contexts in the RTL expressions that make up 15481machine descriptions. 15482 15483 In a machine description, strings are normally written with double 15484quotes, as you would in C. However, strings in machine descriptions may 15485extend over many lines, which is invalid C, and adjacent string 15486constants are not concatenated as they are in C. Any string constant 15487may be surrounded with a single set of parentheses. Sometimes this 15488makes the machine description easier to read. 15489 15490 There is also a special syntax for strings, which can be useful when C 15491code is embedded in a machine description. Wherever a string can 15492appear, it is also valid to write a C-style brace block. The entire 15493brace block, including the outermost pair of braces, is considered to be 15494the string constant. Double quote characters inside the braces are not 15495special. Therefore, if you write string constants in the C code, you 15496need not escape each quote character with a backslash. 15497 15498 A vector contains an arbitrary number of pointers to expressions. The 15499number of elements in the vector is explicitly present in the vector. 15500The written form of a vector consists of square brackets ('[...]') 15501surrounding the elements, in sequence and with whitespace separating 15502them. Vectors of length zero are not created; null pointers are used 15503instead. 15504 15505 Expressions are classified by "expression codes" (also called RTX 15506codes). The expression code is a name defined in 'rtl.def', which is 15507also (in uppercase) a C enumeration constant. The possible expression 15508codes and their meanings are machine-independent. The code of an RTX 15509can be extracted with the macro 'GET_CODE (X)' and altered with 15510'PUT_CODE (X, NEWCODE)'. 15511 15512 The expression code determines how many operands the expression 15513contains, and what kinds of objects they are. In RTL, unlike Lisp, you 15514cannot tell by looking at an operand what kind of object it is. 15515Instead, you must know from its context--from the expression code of the 15516containing expression. For example, in an expression of code 'subreg', 15517the first operand is to be regarded as an expression and the second 15518operand as a polynomial integer. In an expression of code 'plus', there 15519are two operands, both of which are to be regarded as expressions. In a 15520'symbol_ref' expression, there is one operand, which is to be regarded 15521as a string. 15522 15523 Expressions are written as parentheses containing the name of the 15524expression type, its flags and machine mode if any, and then the 15525operands of the expression (separated by spaces). 15526 15527 Expression code names in the 'md' file are written in lowercase, but 15528when they appear in C code they are written in uppercase. In this 15529manual, they are shown as follows: 'const_int'. 15530 15531 In a few contexts a null pointer is valid where an expression is 15532normally wanted. The written form of this is '(nil)'. 15533 15534 15535File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL 15536 1553714.2 RTL Classes and Formats 15538============================ 15539 15540The various expression codes are divided into several "classes", which 15541are represented by single characters. You can determine the class of an 15542RTX code with the macro 'GET_RTX_CLASS (CODE)'. Currently, 'rtl.def' 15543defines these classes: 15544 15545'RTX_OBJ' 15546 An RTX code that represents an actual object, such as a register 15547 ('REG') or a memory location ('MEM', 'SYMBOL_REF'). 'LO_SUM') is 15548 also included; instead, 'SUBREG' and 'STRICT_LOW_PART' are not in 15549 this class, but in class 'RTX_EXTRA'. 15550 15551'RTX_CONST_OBJ' 15552 An RTX code that represents a constant object. 'HIGH' is also 15553 included in this class. 15554 15555'RTX_COMPARE' 15556 An RTX code for a non-symmetric comparison, such as 'GEU' or 'LT'. 15557 15558'RTX_COMM_COMPARE' 15559 An RTX code for a symmetric (commutative) comparison, such as 'EQ' 15560 or 'ORDERED'. 15561 15562'RTX_UNARY' 15563 An RTX code for a unary arithmetic operation, such as 'NEG', 'NOT', 15564 or 'ABS'. This category also includes value extension (sign or 15565 zero) and conversions between integer and floating point. 15566 15567'RTX_COMM_ARITH' 15568 An RTX code for a commutative binary operation, such as 'PLUS' or 15569 'AND'. 'NE' and 'EQ' are comparisons, so they have class 15570 'RTX_COMM_COMPARE'. 15571 15572'RTX_BIN_ARITH' 15573 An RTX code for a non-commutative binary operation, such as 15574 'MINUS', 'DIV', or 'ASHIFTRT'. 15575 15576'RTX_BITFIELD_OPS' 15577 An RTX code for a bit-field operation. Currently only 15578 'ZERO_EXTRACT' and 'SIGN_EXTRACT'. These have three inputs and are 15579 lvalues (so they can be used for insertion as well). *Note 15580 Bit-Fields::. 15581 15582'RTX_TERNARY' 15583 An RTX code for other three input operations. Currently only 15584 'IF_THEN_ELSE', 'VEC_MERGE', 'SIGN_EXTRACT', 'ZERO_EXTRACT', and 15585 'FMA'. 15586 15587'RTX_INSN' 15588 An RTX code for an entire instruction: 'INSN', 'JUMP_INSN', and 15589 'CALL_INSN'. *Note Insns::. 15590 15591'RTX_MATCH' 15592 An RTX code for something that matches in insns, such as 15593 'MATCH_DUP'. These only occur in machine descriptions. 15594 15595'RTX_AUTOINC' 15596 An RTX code for an auto-increment addressing mode, such as 15597 'POST_INC'. 'XEXP (X, 0)' gives the auto-modified register. 15598 15599'RTX_EXTRA' 15600 All other RTX codes. This category includes the remaining codes 15601 used only in machine descriptions ('DEFINE_*', etc.). It also 15602 includes all the codes describing side effects ('SET', 'USE', 15603 'CLOBBER', etc.) and the non-insns that may appear on an insn 15604 chain, such as 'NOTE', 'BARRIER', and 'CODE_LABEL'. 'SUBREG' is 15605 also part of this class. 15606 15607 For each expression code, 'rtl.def' specifies the number of contained 15608objects and their kinds using a sequence of characters called the 15609"format" of the expression code. For example, the format of 'subreg' is 15610'ep'. 15611 15612 These are the most commonly used format characters: 15613 15614'e' 15615 An expression (actually a pointer to an expression). 15616 15617'i' 15618 An integer. 15619 15620'w' 15621 A wide integer. 15622 15623's' 15624 A string. 15625 15626'E' 15627 A vector of expressions. 15628 15629 A few other format characters are used occasionally: 15630 15631'u' 15632 'u' is equivalent to 'e' except that it is printed differently in 15633 debugging dumps. It is used for pointers to insns. 15634 15635'n' 15636 'n' is equivalent to 'i' except that it is printed differently in 15637 debugging dumps. It is used for the line number or code number of 15638 a 'note' insn. 15639 15640'S' 15641 'S' indicates a string which is optional. In the RTL objects in 15642 core, 'S' is equivalent to 's', but when the object is read, from 15643 an 'md' file, the string value of this operand may be omitted. An 15644 omitted string is taken to be the null string. 15645 15646'V' 15647 'V' indicates a vector which is optional. In the RTL objects in 15648 core, 'V' is equivalent to 'E', but when the object is read from an 15649 'md' file, the vector value of this operand may be omitted. An 15650 omitted vector is effectively the same as a vector of no elements. 15651 15652'B' 15653 'B' indicates a pointer to basic block structure. 15654 15655'p' 15656 A polynomial integer. At present this is used only for 15657 'SUBREG_BYTE'. 15658 15659'0' 15660 '0' means a slot whose contents do not fit any normal category. 15661 '0' slots are not printed at all in dumps, and are often used in 15662 special ways by small parts of the compiler. 15663 15664 There are macros to get the number of operands and the format of an 15665expression code: 15666 15667'GET_RTX_LENGTH (CODE)' 15668 Number of operands of an RTX of code CODE. 15669 15670'GET_RTX_FORMAT (CODE)' 15671 The format of an RTX of code CODE, as a C string. 15672 15673 Some classes of RTX codes always have the same format. For example, it 15674is safe to assume that all comparison operations have format 'ee'. 15675 15676'RTX_UNARY' 15677 All codes of this class have format 'e'. 15678 15679'RTX_BIN_ARITH' 15680'RTX_COMM_ARITH' 15681'RTX_COMM_COMPARE' 15682'RTX_COMPARE' 15683 All codes of these classes have format 'ee'. 15684 15685'RTX_BITFIELD_OPS' 15686'RTX_TERNARY' 15687 All codes of these classes have format 'eee'. 15688 15689'RTX_INSN' 15690 All codes of this class have formats that begin with 'iuueiee'. 15691 *Note Insns::. Note that not all RTL objects linked onto an insn 15692 chain are of class 'RTX_INSN'. 15693 15694'RTX_CONST_OBJ' 15695'RTX_OBJ' 15696'RTX_MATCH' 15697'RTX_EXTRA' 15698 You can make no assumptions about the format of these codes. 15699 15700 15701File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL 15702 1570314.3 Access to Operands 15704======================= 15705 15706Operands of expressions are accessed using the macros 'XEXP', 'XINT', 15707'XWINT' and 'XSTR'. Each of these macros takes two arguments: an 15708expression-pointer (RTX) and an operand number (counting from zero). 15709Thus, 15710 15711 XEXP (X, 2) 15712 15713accesses operand 2 of expression X, as an expression. 15714 15715 XINT (X, 2) 15716 15717accesses the same operand as an integer. 'XSTR', used in the same 15718fashion, would access it as a string. 15719 15720 Any operand can be accessed as an integer, as an expression or as a 15721string. You must choose the correct method of access for the kind of 15722value actually stored in the operand. You would do this based on the 15723expression code of the containing expression. That is also how you 15724would know how many operands there are. 15725 15726 For example, if X is an 'int_list' expression, you know that it has two 15727operands which can be correctly accessed as 'XINT (X, 0)' and 'XEXP (X, 157281)'. Incorrect accesses like 'XEXP (X, 0)' and 'XINT (X, 1)' would 15729compile, but would trigger an internal compiler error when rtl checking 15730is enabled. Nothing stops you from writing 'XEXP (X, 28)' either, but 15731this will access memory past the end of the expression with 15732unpredictable results. 15733 15734 Access to operands which are vectors is more complicated. You can use 15735the macro 'XVEC' to get the vector-pointer itself, or the macros 15736'XVECEXP' and 'XVECLEN' to access the elements and length of a vector. 15737 15738'XVEC (EXP, IDX)' 15739 Access the vector-pointer which is operand number IDX in EXP. 15740 15741'XVECLEN (EXP, IDX)' 15742 Access the length (number of elements) in the vector which is in 15743 operand number IDX in EXP. This value is an 'int'. 15744 15745'XVECEXP (EXP, IDX, ELTNUM)' 15746 Access element number ELTNUM in the vector which is in operand 15747 number IDX in EXP. This value is an RTX. 15748 15749 It is up to you to make sure that ELTNUM is not negative and is 15750 less than 'XVECLEN (EXP, IDX)'. 15751 15752 All the macros defined in this section expand into lvalues and 15753therefore can be used to assign the operands, lengths and vector 15754elements as well as to access them. 15755 15756 15757File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL 15758 1575914.4 Access to Special Operands 15760=============================== 15761 15762Some RTL nodes have special annotations associated with them. 15763 15764'MEM' 15765 'MEM_ALIAS_SET (X)' 15766 If 0, X is not in any alias set, and may alias anything. 15767 Otherwise, X can only alias 'MEM's in a conflicting alias set. 15768 This value is set in a language-dependent manner in the 15769 front-end, and should not be altered in the back-end. In some 15770 front-ends, these numbers may correspond in some way to types, 15771 or other language-level entities, but they need not, and the 15772 back-end makes no such assumptions. These set numbers are 15773 tested with 'alias_sets_conflict_p'. 15774 15775 'MEM_EXPR (X)' 15776 If this register is known to hold the value of some user-level 15777 declaration, this is that tree node. It may also be a 15778 'COMPONENT_REF', in which case this is some field reference, 15779 and 'TREE_OPERAND (X, 0)' contains the declaration, or another 15780 'COMPONENT_REF', or null if there is no compile-time object 15781 associated with the reference. 15782 15783 'MEM_OFFSET_KNOWN_P (X)' 15784 True if the offset of the memory reference from 'MEM_EXPR' is 15785 known. 'MEM_OFFSET (X)' provides the offset if so. 15786 15787 'MEM_OFFSET (X)' 15788 The offset from the start of 'MEM_EXPR'. The value is only 15789 valid if 'MEM_OFFSET_KNOWN_P (X)' is true. 15790 15791 'MEM_SIZE_KNOWN_P (X)' 15792 True if the size of the memory reference is known. 'MEM_SIZE 15793 (X)' provides its size if so. 15794 15795 'MEM_SIZE (X)' 15796 The size in bytes of the memory reference. This is mostly 15797 relevant for 'BLKmode' references as otherwise the size is 15798 implied by the mode. The value is only valid if 15799 'MEM_SIZE_KNOWN_P (X)' is true. 15800 15801 'MEM_ALIGN (X)' 15802 The known alignment in bits of the memory reference. 15803 15804 'MEM_ADDR_SPACE (X)' 15805 The address space of the memory reference. This will commonly 15806 be zero for the generic address space. 15807 15808'REG' 15809 'ORIGINAL_REGNO (X)' 15810 This field holds the number the register "originally" had; for 15811 a pseudo register turned into a hard reg this will hold the 15812 old pseudo register number. 15813 15814 'REG_EXPR (X)' 15815 If this register is known to hold the value of some user-level 15816 declaration, this is that tree node. 15817 15818 'REG_OFFSET (X)' 15819 If this register is known to hold the value of some user-level 15820 declaration, this is the offset into that logical storage. 15821 15822'SYMBOL_REF' 15823 'SYMBOL_REF_DECL (X)' 15824 If the 'symbol_ref' X was created for a 'VAR_DECL' or a 15825 'FUNCTION_DECL', that tree is recorded here. If this value is 15826 null, then X was created by back end code generation routines, 15827 and there is no associated front end symbol table entry. 15828 15829 'SYMBOL_REF_DECL' may also point to a tree of class ''c'', 15830 that is, some sort of constant. In this case, the 15831 'symbol_ref' is an entry in the per-file constant pool; again, 15832 there is no associated front end symbol table entry. 15833 15834 'SYMBOL_REF_CONSTANT (X)' 15835 If 'CONSTANT_POOL_ADDRESS_P (X)' is true, this is the constant 15836 pool entry for X. It is null otherwise. 15837 15838 'SYMBOL_REF_DATA (X)' 15839 A field of opaque type used to store 'SYMBOL_REF_DECL' or 15840 'SYMBOL_REF_CONSTANT'. 15841 15842 'SYMBOL_REF_FLAGS (X)' 15843 In a 'symbol_ref', this is used to communicate various 15844 predicates about the symbol. Some of these are common enough 15845 to be computed by common code, some are specific to the 15846 target. The common bits are: 15847 15848 'SYMBOL_FLAG_FUNCTION' 15849 Set if the symbol refers to a function. 15850 15851 'SYMBOL_FLAG_LOCAL' 15852 Set if the symbol is local to this "module". See 15853 'TARGET_BINDS_LOCAL_P'. 15854 15855 'SYMBOL_FLAG_EXTERNAL' 15856 Set if this symbol is not defined in this translation 15857 unit. Note that this is not the inverse of 15858 'SYMBOL_FLAG_LOCAL'. 15859 15860 'SYMBOL_FLAG_SMALL' 15861 Set if the symbol is located in the small data section. 15862 See 'TARGET_IN_SMALL_DATA_P'. 15863 15864 'SYMBOL_REF_TLS_MODEL (X)' 15865 This is a multi-bit field accessor that returns the 15866 'tls_model' to be used for a thread-local storage symbol. 15867 It returns zero for non-thread-local symbols. 15868 15869 'SYMBOL_FLAG_HAS_BLOCK_INFO' 15870 Set if the symbol has 'SYMBOL_REF_BLOCK' and 15871 'SYMBOL_REF_BLOCK_OFFSET' fields. 15872 15873 'SYMBOL_FLAG_ANCHOR' 15874 Set if the symbol is used as a section anchor. "Section 15875 anchors" are symbols that have a known position within an 15876 'object_block' and that can be used to access nearby 15877 members of that block. They are used to implement 15878 '-fsection-anchors'. 15879 15880 If this flag is set, then 'SYMBOL_FLAG_HAS_BLOCK_INFO' 15881 will be too. 15882 15883 Bits beginning with 'SYMBOL_FLAG_MACH_DEP' are available for 15884 the target's use. 15885 15886'SYMBOL_REF_BLOCK (X)' 15887 If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the 'object_block' 15888 structure to which the symbol belongs, or 'NULL' if it has not been 15889 assigned a block. 15890 15891'SYMBOL_REF_BLOCK_OFFSET (X)' 15892 If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the offset of X from 15893 the first object in 'SYMBOL_REF_BLOCK (X)'. The value is negative 15894 if X has not yet been assigned to a block, or it has not been given 15895 an offset within that block. 15896 15897 15898File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL 15899 1590014.5 Flags in an RTL Expression 15901=============================== 15902 15903RTL expressions contain several flags (one-bit bit-fields) that are used 15904in certain types of expression. Most often they are accessed with the 15905following macros, which expand into lvalues. 15906 15907'CROSSING_JUMP_P (X)' 15908 Nonzero in a 'jump_insn' if it crosses between hot and cold 15909 sections, which could potentially be very far apart in the 15910 executable. The presence of this flag indicates to other 15911 optimizations that this branching instruction should not be 15912 "collapsed" into a simpler branching construct. It is used when 15913 the optimization to partition basic blocks into hot and cold 15914 sections is turned on. 15915 15916'CONSTANT_POOL_ADDRESS_P (X)' 15917 Nonzero in a 'symbol_ref' if it refers to part of the current 15918 function's constant pool. For most targets these addresses are in 15919 a '.rodata' section entirely separate from the function, but for 15920 some targets the addresses are close to the beginning of the 15921 function. In either case GCC assumes these addresses can be 15922 addressed directly, perhaps with the help of base registers. 15923 Stored in the 'unchanging' field and printed as '/u'. 15924 15925'INSN_ANNULLED_BRANCH_P (X)' 15926 In a 'jump_insn', 'call_insn', or 'insn' indicates that the branch 15927 is an annulling one. See the discussion under 'sequence' below. 15928 Stored in the 'unchanging' field and printed as '/u'. 15929 15930'INSN_DELETED_P (X)' 15931 In an 'insn', 'call_insn', 'jump_insn', 'code_label', 15932 'jump_table_data', 'barrier', or 'note', nonzero if the insn has 15933 been deleted. Stored in the 'volatil' field and printed as '/v'. 15934 15935'INSN_FROM_TARGET_P (X)' 15936 In an 'insn' or 'jump_insn' or 'call_insn' in a delay slot of a 15937 branch, indicates that the insn is from the target of the branch. 15938 If the branch insn has 'INSN_ANNULLED_BRANCH_P' set, this insn will 15939 only be executed if the branch is taken. For annulled branches 15940 with 'INSN_FROM_TARGET_P' clear, the insn will be executed only if 15941 the branch is not taken. When 'INSN_ANNULLED_BRANCH_P' is not set, 15942 this insn will always be executed. Stored in the 'in_struct' field 15943 and printed as '/s'. 15944 15945'LABEL_PRESERVE_P (X)' 15946 In a 'code_label' or 'note', indicates that the label is referenced 15947 by code or data not visible to the RTL of a given function. Labels 15948 referenced by a non-local goto will have this bit set. Stored in 15949 the 'in_struct' field and printed as '/s'. 15950 15951'LABEL_REF_NONLOCAL_P (X)' 15952 In 'label_ref' and 'reg_label' expressions, nonzero if this is a 15953 reference to a non-local label. Stored in the 'volatil' field and 15954 printed as '/v'. 15955 15956'MEM_KEEP_ALIAS_SET_P (X)' 15957 In 'mem' expressions, 1 if we should keep the alias set for this 15958 mem unchanged when we access a component. Set to 1, for example, 15959 when we are already in a non-addressable component of an aggregate. 15960 Stored in the 'jump' field and printed as '/j'. 15961 15962'MEM_VOLATILE_P (X)' 15963 In 'mem', 'asm_operands', and 'asm_input' expressions, nonzero for 15964 volatile memory references. Stored in the 'volatil' field and 15965 printed as '/v'. 15966 15967'MEM_NOTRAP_P (X)' 15968 In 'mem', nonzero for memory references that will not trap. Stored 15969 in the 'call' field and printed as '/c'. 15970 15971'MEM_POINTER (X)' 15972 Nonzero in a 'mem' if the memory reference holds a pointer. Stored 15973 in the 'frame_related' field and printed as '/f'. 15974 15975'MEM_READONLY_P (X)' 15976 Nonzero in a 'mem', if the memory is statically allocated and 15977 read-only. 15978 15979 Read-only in this context means never modified during the lifetime 15980 of the program, not necessarily in ROM or in write-disabled pages. 15981 A common example of the later is a shared library's global offset 15982 table. This table is initialized by the runtime loader, so the 15983 memory is technically writable, but after control is transferred 15984 from the runtime loader to the application, this memory will never 15985 be subsequently modified. 15986 15987 Stored in the 'unchanging' field and printed as '/u'. 15988 15989'PREFETCH_SCHEDULE_BARRIER_P (X)' 15990 In a 'prefetch', indicates that the prefetch is a scheduling 15991 barrier. No other INSNs will be moved over it. Stored in the 15992 'volatil' field and printed as '/v'. 15993 15994'REG_FUNCTION_VALUE_P (X)' 15995 Nonzero in a 'reg' if it is the place in which this function's 15996 value is going to be returned. (This happens only in a hard 15997 register.) Stored in the 'return_val' field and printed as '/i'. 15998 15999'REG_POINTER (X)' 16000 Nonzero in a 'reg' if the register holds a pointer. Stored in the 16001 'frame_related' field and printed as '/f'. 16002 16003'REG_USERVAR_P (X)' 16004 In a 'reg', nonzero if it corresponds to a variable present in the 16005 user's source code. Zero for temporaries generated internally by 16006 the compiler. Stored in the 'volatil' field and printed as '/v'. 16007 16008 The same hard register may be used also for collecting the values 16009 of functions called by this one, but 'REG_FUNCTION_VALUE_P' is zero 16010 in this kind of use. 16011 16012'RTL_CONST_CALL_P (X)' 16013 In a 'call_insn' indicates that the insn represents a call to a 16014 const function. Stored in the 'unchanging' field and printed as 16015 '/u'. 16016 16017'RTL_PURE_CALL_P (X)' 16018 In a 'call_insn' indicates that the insn represents a call to a 16019 pure function. Stored in the 'return_val' field and printed as 16020 '/i'. 16021 16022'RTL_CONST_OR_PURE_CALL_P (X)' 16023 In a 'call_insn', true if 'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P' 16024 is true. 16025 16026'RTL_LOOPING_CONST_OR_PURE_CALL_P (X)' 16027 In a 'call_insn' indicates that the insn represents a possibly 16028 infinite looping call to a const or pure function. Stored in the 16029 'call' field and printed as '/c'. Only true if one of 16030 'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P' is true. 16031 16032'RTX_FRAME_RELATED_P (X)' 16033 Nonzero in an 'insn', 'call_insn', 'jump_insn', 'barrier', or 'set' 16034 which is part of a function prologue and sets the stack pointer, 16035 sets the frame pointer, or saves a register. This flag should also 16036 be set on an instruction that sets up a temporary register to use 16037 in place of the frame pointer. Stored in the 'frame_related' field 16038 and printed as '/f'. 16039 16040 In particular, on RISC targets where there are limits on the sizes 16041 of immediate constants, it is sometimes impossible to reach the 16042 register save area directly from the stack pointer. In that case, 16043 a temporary register is used that is near enough to the register 16044 save area, and the Canonical Frame Address, i.e., DWARF2's logical 16045 frame pointer, register must (temporarily) be changed to be this 16046 temporary register. So, the instruction that sets this temporary 16047 register must be marked as 'RTX_FRAME_RELATED_P'. 16048 16049 If the marked instruction is overly complex (defined in terms of 16050 what 'dwarf2out_frame_debug_expr' can handle), you will also have 16051 to create a 'REG_FRAME_RELATED_EXPR' note and attach it to the 16052 instruction. This note should contain a simple expression of the 16053 computation performed by this instruction, i.e., one that 16054 'dwarf2out_frame_debug_expr' can handle. 16055 16056 This flag is required for exception handling support on targets 16057 with RTL prologues. 16058 16059'SCHED_GROUP_P (X)' 16060 During instruction scheduling, in an 'insn', 'call_insn', 16061 'jump_insn' or 'jump_table_data', indicates that the previous insn 16062 must be scheduled together with this insn. This is used to ensure 16063 that certain groups of instructions will not be split up by the 16064 instruction scheduling pass, for example, 'use' insns before a 16065 'call_insn' may not be separated from the 'call_insn'. Stored in 16066 the 'in_struct' field and printed as '/s'. 16067 16068'SET_IS_RETURN_P (X)' 16069 For a 'set', nonzero if it is for a return. Stored in the 'jump' 16070 field and printed as '/j'. 16071 16072'SIBLING_CALL_P (X)' 16073 For a 'call_insn', nonzero if the insn is a sibling call. Stored 16074 in the 'jump' field and printed as '/j'. 16075 16076'STRING_POOL_ADDRESS_P (X)' 16077 For a 'symbol_ref' expression, nonzero if it addresses this 16078 function's string constant pool. Stored in the 'frame_related' 16079 field and printed as '/f'. 16080 16081'SUBREG_PROMOTED_UNSIGNED_P (X)' 16082 Returns a value greater then zero for a 'subreg' that has 16083 'SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is 16084 kept zero-extended, zero if it is kept sign-extended, and less then 16085 zero if it is extended some other way via the 'ptr_extend' 16086 instruction. Stored in the 'unchanging' field and 'volatil' field, 16087 printed as '/u' and '/v'. This macro may only be used to get the 16088 value it may not be used to change the value. Use 16089 'SUBREG_PROMOTED_UNSIGNED_SET' to change the value. 16090 16091'SUBREG_PROMOTED_UNSIGNED_SET (X)' 16092 Set the 'unchanging' and 'volatil' fields in a 'subreg' to reflect 16093 zero, sign, or other extension. If 'volatil' is zero, then 16094 'unchanging' as nonzero means zero extension and as zero means sign 16095 extension. If 'volatil' is nonzero then some other type of 16096 extension was done via the 'ptr_extend' instruction. 16097 16098'SUBREG_PROMOTED_VAR_P (X)' 16099 Nonzero in a 'subreg' if it was made when accessing an object that 16100 was promoted to a wider mode in accord with the 'PROMOTED_MODE' 16101 machine description macro (*note Storage Layout::). In this case, 16102 the mode of the 'subreg' is the declared mode of the object and the 16103 mode of 'SUBREG_REG' is the mode of the register that holds the 16104 object. Promoted variables are always either sign- or 16105 zero-extended to the wider mode on every assignment. Stored in the 16106 'in_struct' field and printed as '/s'. 16107 16108'SYMBOL_REF_USED (X)' 16109 In a 'symbol_ref', indicates that X has been used. This is 16110 normally only used to ensure that X is only declared external once. 16111 Stored in the 'used' field. 16112 16113'SYMBOL_REF_WEAK (X)' 16114 In a 'symbol_ref', indicates that X has been declared weak. Stored 16115 in the 'return_val' field and printed as '/i'. 16116 16117'SYMBOL_REF_FLAG (X)' 16118 In a 'symbol_ref', this is used as a flag for machine-specific 16119 purposes. Stored in the 'volatil' field and printed as '/v'. 16120 16121 Most uses of 'SYMBOL_REF_FLAG' are historic and may be subsumed by 16122 'SYMBOL_REF_FLAGS'. Certainly use of 'SYMBOL_REF_FLAGS' is 16123 mandatory if the target requires more than one bit of storage. 16124 16125 These are the fields to which the above macros refer: 16126 16127'call' 16128 In a 'mem', 1 means that the memory reference will not trap. 16129 16130 In a 'call', 1 means that this pure or const call may possibly 16131 infinite loop. 16132 16133 In an RTL dump, this flag is represented as '/c'. 16134 16135'frame_related' 16136 In an 'insn' or 'set' expression, 1 means that it is part of a 16137 function prologue and sets the stack pointer, sets the frame 16138 pointer, saves a register, or sets up a temporary register to use 16139 in place of the frame pointer. 16140 16141 In 'reg' expressions, 1 means that the register holds a pointer. 16142 16143 In 'mem' expressions, 1 means that the memory reference holds a 16144 pointer. 16145 16146 In 'symbol_ref' expressions, 1 means that the reference addresses 16147 this function's string constant pool. 16148 16149 In an RTL dump, this flag is represented as '/f'. 16150 16151'in_struct' 16152 In 'reg' expressions, it is 1 if the register has its entire life 16153 contained within the test expression of some loop. 16154 16155 In 'subreg' expressions, 1 means that the 'subreg' is accessing an 16156 object that has had its mode promoted from a wider mode. 16157 16158 In 'label_ref' expressions, 1 means that the referenced label is 16159 outside the innermost loop containing the insn in which the 16160 'label_ref' was found. 16161 16162 In 'code_label' expressions, it is 1 if the label may never be 16163 deleted. This is used for labels which are the target of non-local 16164 gotos. Such a label that would have been deleted is replaced with 16165 a 'note' of type 'NOTE_INSN_DELETED_LABEL'. 16166 16167 In an 'insn' during dead-code elimination, 1 means that the insn is 16168 dead code. 16169 16170 In an 'insn' or 'jump_insn' during reorg for an insn in the delay 16171 slot of a branch, 1 means that this insn is from the target of the 16172 branch. 16173 16174 In an 'insn' during instruction scheduling, 1 means that this insn 16175 must be scheduled as part of a group together with the previous 16176 insn. 16177 16178 In an RTL dump, this flag is represented as '/s'. 16179 16180'return_val' 16181 In 'reg' expressions, 1 means the register contains the value to be 16182 returned by the current function. On machines that pass parameters 16183 in registers, the same register number may be used for parameters 16184 as well, but this flag is not set on such uses. 16185 16186 In 'symbol_ref' expressions, 1 means the referenced symbol is weak. 16187 16188 In 'call' expressions, 1 means the call is pure. 16189 16190 In an RTL dump, this flag is represented as '/i'. 16191 16192'jump' 16193 In a 'mem' expression, 1 means we should keep the alias set for 16194 this mem unchanged when we access a component. 16195 16196 In a 'set', 1 means it is for a return. 16197 16198 In a 'call_insn', 1 means it is a sibling call. 16199 16200 In a 'jump_insn', 1 means it is a crossing jump. 16201 16202 In an RTL dump, this flag is represented as '/j'. 16203 16204'unchanging' 16205 In 'reg' and 'mem' expressions, 1 means that the value of the 16206 expression never changes. 16207 16208 In 'subreg' expressions, it is 1 if the 'subreg' references an 16209 unsigned object whose mode has been promoted to a wider mode. 16210 16211 In an 'insn' or 'jump_insn' in the delay slot of a branch 16212 instruction, 1 means an annulling branch should be used. 16213 16214 In a 'symbol_ref' expression, 1 means that this symbol addresses 16215 something in the per-function constant pool. 16216 16217 In a 'call_insn' 1 means that this instruction is a call to a const 16218 function. 16219 16220 In an RTL dump, this flag is represented as '/u'. 16221 16222'used' 16223 This flag is used directly (without an access macro) at the end of 16224 RTL generation for a function, to count the number of times an 16225 expression appears in insns. Expressions that appear more than 16226 once are copied, according to the rules for shared structure (*note 16227 Sharing::). 16228 16229 For a 'reg', it is used directly (without an access macro) by the 16230 leaf register renumbering code to ensure that each register is only 16231 renumbered once. 16232 16233 In a 'symbol_ref', it indicates that an external declaration for 16234 the symbol has already been written. 16235 16236'volatil' 16237 In a 'mem', 'asm_operands', or 'asm_input' expression, it is 1 if 16238 the memory reference is volatile. Volatile memory references may 16239 not be deleted, reordered or combined. 16240 16241 In a 'symbol_ref' expression, it is used for machine-specific 16242 purposes. 16243 16244 In a 'reg' expression, it is 1 if the value is a user-level 16245 variable. 0 indicates an internal compiler temporary. 16246 16247 In an 'insn', 1 means the insn has been deleted. 16248 16249 In 'label_ref' and 'reg_label' expressions, 1 means a reference to 16250 a non-local label. 16251 16252 In 'prefetch' expressions, 1 means that the containing insn is a 16253 scheduling barrier. 16254 16255 In an RTL dump, this flag is represented as '/v'. 16256 16257 16258File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 16259 1626014.6 Machine Modes 16261================== 16262 16263A machine mode describes a size of data object and the representation 16264used for it. In the C code, machine modes are represented by an 16265enumeration type, 'machine_mode', defined in 'machmode.def'. Each RTL 16266expression has room for a machine mode and so do certain kinds of tree 16267expressions (declarations and types, to be precise). 16268 16269 In debugging dumps and machine descriptions, the machine mode of an RTL 16270expression is written after the expression code with a colon to separate 16271them. The letters 'mode' which appear at the end of each machine mode 16272name are omitted. For example, '(reg:SI 38)' is a 'reg' expression with 16273machine mode 'SImode'. If the mode is 'VOIDmode', it is not written at 16274all. 16275 16276 Here is a table of machine modes. The term "byte" below refers to an 16277object of 'BITS_PER_UNIT' bits (*note Storage Layout::). 16278 16279'BImode' 16280 "Bit" mode represents a single bit, for predicate registers. 16281 16282'QImode' 16283 "Quarter-Integer" mode represents a single byte treated as an 16284 integer. 16285 16286'HImode' 16287 "Half-Integer" mode represents a two-byte integer. 16288 16289'PSImode' 16290 "Partial Single Integer" mode represents an integer which occupies 16291 four bytes but which doesn't really use all four. On some 16292 machines, this is the right mode to use for pointers. 16293 16294'SImode' 16295 "Single Integer" mode represents a four-byte integer. 16296 16297'PDImode' 16298 "Partial Double Integer" mode represents an integer which occupies 16299 eight bytes but which doesn't really use all eight. On some 16300 machines, this is the right mode to use for certain pointers. 16301 16302'DImode' 16303 "Double Integer" mode represents an eight-byte integer. 16304 16305'TImode' 16306 "Tetra Integer" (?) mode represents a sixteen-byte integer. 16307 16308'OImode' 16309 "Octa Integer" (?) mode represents a thirty-two-byte integer. 16310 16311'XImode' 16312 "Hexadeca Integer" (?) mode represents a sixty-four-byte integer. 16313 16314'QFmode' 16315 "Quarter-Floating" mode represents a quarter-precision (single 16316 byte) floating point number. 16317 16318'HFmode' 16319 "Half-Floating" mode represents a half-precision (two byte) 16320 floating point number. 16321 16322'TQFmode' 16323 "Three-Quarter-Floating" (?) mode represents a 16324 three-quarter-precision (three byte) floating point number. 16325 16326'SFmode' 16327 "Single Floating" mode represents a four byte floating point 16328 number. In the common case, of a processor with IEEE arithmetic 16329 and 8-bit bytes, this is a single-precision IEEE floating point 16330 number; it can also be used for double-precision (on processors 16331 with 16-bit bytes) and single-precision VAX and IBM types. 16332 16333'DFmode' 16334 "Double Floating" mode represents an eight byte floating point 16335 number. In the common case, of a processor with IEEE arithmetic 16336 and 8-bit bytes, this is a double-precision IEEE floating point 16337 number. 16338 16339'XFmode' 16340 "Extended Floating" mode represents an IEEE extended floating point 16341 number. This mode only has 80 meaningful bits (ten bytes). Some 16342 processors require such numbers to be padded to twelve bytes, 16343 others to sixteen; this mode is used for either. 16344 16345'SDmode' 16346 "Single Decimal Floating" mode represents a four byte decimal 16347 floating point number (as distinct from conventional binary 16348 floating point). 16349 16350'DDmode' 16351 "Double Decimal Floating" mode represents an eight byte decimal 16352 floating point number. 16353 16354'TDmode' 16355 "Tetra Decimal Floating" mode represents a sixteen byte decimal 16356 floating point number all 128 of whose bits are meaningful. 16357 16358'TFmode' 16359 "Tetra Floating" mode represents a sixteen byte floating point 16360 number all 128 of whose bits are meaningful. One common use is the 16361 IEEE quad-precision format. 16362 16363'QQmode' 16364 "Quarter-Fractional" mode represents a single byte treated as a 16365 signed fractional number. The default format is "s.7". 16366 16367'HQmode' 16368 "Half-Fractional" mode represents a two-byte signed fractional 16369 number. The default format is "s.15". 16370 16371'SQmode' 16372 "Single Fractional" mode represents a four-byte signed fractional 16373 number. The default format is "s.31". 16374 16375'DQmode' 16376 "Double Fractional" mode represents an eight-byte signed fractional 16377 number. The default format is "s.63". 16378 16379'TQmode' 16380 "Tetra Fractional" mode represents a sixteen-byte signed fractional 16381 number. The default format is "s.127". 16382 16383'UQQmode' 16384 "Unsigned Quarter-Fractional" mode represents a single byte treated 16385 as an unsigned fractional number. The default format is ".8". 16386 16387'UHQmode' 16388 "Unsigned Half-Fractional" mode represents a two-byte unsigned 16389 fractional number. The default format is ".16". 16390 16391'USQmode' 16392 "Unsigned Single Fractional" mode represents a four-byte unsigned 16393 fractional number. The default format is ".32". 16394 16395'UDQmode' 16396 "Unsigned Double Fractional" mode represents an eight-byte unsigned 16397 fractional number. The default format is ".64". 16398 16399'UTQmode' 16400 "Unsigned Tetra Fractional" mode represents a sixteen-byte unsigned 16401 fractional number. The default format is ".128". 16402 16403'HAmode' 16404 "Half-Accumulator" mode represents a two-byte signed accumulator. 16405 The default format is "s8.7". 16406 16407'SAmode' 16408 "Single Accumulator" mode represents a four-byte signed 16409 accumulator. The default format is "s16.15". 16410 16411'DAmode' 16412 "Double Accumulator" mode represents an eight-byte signed 16413 accumulator. The default format is "s32.31". 16414 16415'TAmode' 16416 "Tetra Accumulator" mode represents a sixteen-byte signed 16417 accumulator. The default format is "s64.63". 16418 16419'UHAmode' 16420 "Unsigned Half-Accumulator" mode represents a two-byte unsigned 16421 accumulator. The default format is "8.8". 16422 16423'USAmode' 16424 "Unsigned Single Accumulator" mode represents a four-byte unsigned 16425 accumulator. The default format is "16.16". 16426 16427'UDAmode' 16428 "Unsigned Double Accumulator" mode represents an eight-byte 16429 unsigned accumulator. The default format is "32.32". 16430 16431'UTAmode' 16432 "Unsigned Tetra Accumulator" mode represents a sixteen-byte 16433 unsigned accumulator. The default format is "64.64". 16434 16435'CCmode' 16436 "Condition Code" mode represents the value of a condition code, 16437 which is a machine-specific set of bits used to represent the 16438 result of a comparison operation. Other machine-specific modes may 16439 also be used for the condition code. These modes are not used on 16440 machines that use 'cc0' (*note Condition Code::). 16441 16442'BLKmode' 16443 "Block" mode represents values that are aggregates to which none of 16444 the other modes apply. In RTL, only memory references can have 16445 this mode, and only if they appear in string-move or vector 16446 instructions. On machines which have no such instructions, 16447 'BLKmode' will not appear in RTL. 16448 16449'VOIDmode' 16450 Void mode means the absence of a mode or an unspecified mode. For 16451 example, RTL expressions of code 'const_int' have mode 'VOIDmode' 16452 because they can be taken to have whatever mode the context 16453 requires. In debugging dumps of RTL, 'VOIDmode' is expressed by 16454 the absence of any mode. 16455 16456'QCmode, HCmode, SCmode, DCmode, XCmode, TCmode' 16457 These modes stand for a complex number represented as a pair of 16458 floating point values. The floating point values are in 'QFmode', 16459 'HFmode', 'SFmode', 'DFmode', 'XFmode', and 'TFmode', respectively. 16460 16461'CQImode, CHImode, CSImode, CDImode, CTImode, COImode, CPSImode' 16462 These modes stand for a complex number represented as a pair of 16463 integer values. The integer values are in 'QImode', 'HImode', 16464 'SImode', 'DImode', 'TImode', 'OImode', and 'PSImode', 16465 respectively. 16466 16467'BND32mode BND64mode' 16468 These modes stand for bounds for pointer of 32 and 64 bit size 16469 respectively. Mode size is double pointer mode size. 16470 16471 The machine description defines 'Pmode' as a C macro which expands into 16472the machine mode used for addresses. Normally this is the mode whose 16473size is 'BITS_PER_WORD', 'SImode' on 32-bit machines. 16474 16475 The only modes which a machine description must support are 'QImode', 16476and the modes corresponding to 'BITS_PER_WORD', 'FLOAT_TYPE_SIZE' and 16477'DOUBLE_TYPE_SIZE'. The compiler will attempt to use 'DImode' for 164788-byte structures and unions, but this can be prevented by overriding 16479the definition of 'MAX_FIXED_MODE_SIZE'. Alternatively, you can have 16480the compiler use 'TImode' for 16-byte structures and unions. Likewise, 16481you can arrange for the C type 'short int' to avoid using 'HImode'. 16482 16483 Very few explicit references to machine modes remain in the compiler 16484and these few references will soon be removed. Instead, the machine 16485modes are divided into mode classes. These are represented by the 16486enumeration type 'enum mode_class' defined in 'machmode.h'. The 16487possible mode classes are: 16488 16489'MODE_INT' 16490 Integer modes. By default these are 'BImode', 'QImode', 'HImode', 16491 'SImode', 'DImode', 'TImode', and 'OImode'. 16492 16493'MODE_PARTIAL_INT' 16494 The "partial integer" modes, 'PQImode', 'PHImode', 'PSImode' and 16495 'PDImode'. 16496 16497'MODE_FLOAT' 16498 Floating point modes. By default these are 'QFmode', 'HFmode', 16499 'TQFmode', 'SFmode', 'DFmode', 'XFmode' and 'TFmode'. 16500 16501'MODE_DECIMAL_FLOAT' 16502 Decimal floating point modes. By default these are 'SDmode', 16503 'DDmode' and 'TDmode'. 16504 16505'MODE_FRACT' 16506 Signed fractional modes. By default these are 'QQmode', 'HQmode', 16507 'SQmode', 'DQmode' and 'TQmode'. 16508 16509'MODE_UFRACT' 16510 Unsigned fractional modes. By default these are 'UQQmode', 16511 'UHQmode', 'USQmode', 'UDQmode' and 'UTQmode'. 16512 16513'MODE_ACCUM' 16514 Signed accumulator modes. By default these are 'HAmode', 'SAmode', 16515 'DAmode' and 'TAmode'. 16516 16517'MODE_UACCUM' 16518 Unsigned accumulator modes. By default these are 'UHAmode', 16519 'USAmode', 'UDAmode' and 'UTAmode'. 16520 16521'MODE_COMPLEX_INT' 16522 Complex integer modes. (These are not currently implemented). 16523 16524'MODE_COMPLEX_FLOAT' 16525 Complex floating point modes. By default these are 'QCmode', 16526 'HCmode', 'SCmode', 'DCmode', 'XCmode', and 'TCmode'. 16527 16528'MODE_CC' 16529 Modes representing condition code values. These are 'CCmode' plus 16530 any 'CC_MODE' modes listed in the 'MACHINE-modes.def'. *Note Jump 16531 Patterns::, also see *note Condition Code::. 16532 16533'MODE_POINTER_BOUNDS' 16534 Pointer bounds modes. Used to represent values of pointer bounds 16535 type. Operations in these modes may be executed as NOPs depending 16536 on hardware features and environment setup. 16537 16538'MODE_RANDOM' 16539 This is a catchall mode class for modes which don't fit into the 16540 above classes. Currently 'VOIDmode' and 'BLKmode' are in 16541 'MODE_RANDOM'. 16542 16543 'machmode.h' also defines various wrapper classes that combine a 16544'machine_mode' with a static assertion that a particular condition 16545holds. The classes are: 16546 16547'scalar_int_mode' 16548 A mode that has class 'MODE_INT' or 'MODE_PARTIAL_INT'. 16549 16550'scalar_float_mode' 16551 A mode that has class 'MODE_FLOAT' or 'MODE_DECIMAL_FLOAT'. 16552 16553'scalar_mode' 16554 A mode that holds a single numerical value. In practice this means 16555 that the mode is a 'scalar_int_mode', is a 'scalar_float_mode', or 16556 has class 'MODE_FRACT', 'MODE_UFRACT', 'MODE_ACCUM', 'MODE_UACCUM' 16557 or 'MODE_POINTER_BOUNDS'. 16558 16559'complex_mode' 16560 A mode that has class 'MODE_COMPLEX_INT' or 'MODE_COMPLEX_FLOAT'. 16561 16562'fixed_size_mode' 16563 A mode whose size is known at compile time. 16564 16565 Named modes use the most constrained of the available wrapper classes, 16566if one exists, otherwise they use 'machine_mode'. For example, 'QImode' 16567is a 'scalar_int_mode', 'SFmode' is a 'scalar_float_mode' and 'BLKmode' 16568is a plain 'machine_mode'. It is possible to refer to any mode as a raw 16569'machine_mode' by adding the 'E_' prefix, where 'E' stands for 16570"enumeration". For example, the raw 'machine_mode' names of the modes 16571just mentioned are 'E_QImode', 'E_SFmode' and 'E_BLKmode' respectively. 16572 16573 The wrapper classes implicitly convert to 'machine_mode' and to any 16574wrapper class that represents a more general condition; for example 16575'scalar_int_mode' and 'scalar_float_mode' both convert to 'scalar_mode' 16576and all three convert to 'fixed_size_mode'. The classes act like 16577'machine_mode's that accept only certain named modes. 16578 16579 'machmode.h' also defines a template class 'opt_mode<T>' that holds a 16580'T' or nothing, where 'T' can be either 'machine_mode' or one of the 16581wrapper classes above. The main operations on an 'opt_mode<T>' X are as 16582follows: 16583 16584'X.exists ()' 16585 Return true if X holds a mode rather than nothing. 16586 16587'X.exists (&Y)' 16588 Return true if X holds a mode rather than nothing, storing the mode 16589 in Y if so. Y must be assignment-compatible with T. 16590 16591'X.require ()' 16592 Assert that X holds a mode rather than nothing and return that 16593 mode. 16594 16595'X = Y' 16596 Set X to Y, where Y is a T or implicitly converts to a T. 16597 16598 The default constructor sets an 'opt_mode<T>' to nothing. There is 16599also a constructor that takes an initial value of type T. 16600 16601 It is possible to use the 'is-a.h' accessors on a 'machine_mode' or 16602machine mode wrapper X: 16603 16604'is_a <T> (X)' 16605 Return true if X meets the conditions for wrapper class T. 16606 16607'is_a <T> (X, &Y)' 16608 Return true if X meets the conditions for wrapper class T, storing 16609 it in Y if so. Y must be assignment-compatible with T. 16610 16611'as_a <T> (X)' 16612 Assert that X meets the conditions for wrapper class T and return 16613 it as a T. 16614 16615'dyn_cast <T> (X)' 16616 Return an 'opt_mode<T>' that holds X if X meets the conditions for 16617 wrapper class T and that holds nothing otherwise. 16618 16619 The purpose of these wrapper classes is to give stronger static type 16620checking. For example, if a function takes a 'scalar_int_mode', a 16621caller that has a general 'machine_mode' must either check or assert 16622that the code is indeed a scalar integer first, using one of the 16623functions above. 16624 16625 The wrapper classes are normal C++ classes, with user-defined 16626constructors. Sometimes it is useful to have a POD version of the same 16627type, particularly if the type appears in a 'union'. The template class 16628'pod_mode<T>' provides a POD version of wrapper class T. It is 16629assignment-compatible with T and implicitly converts to both 16630'machine_mode' and T. 16631 16632 Here are some C macros that relate to machine modes: 16633 16634'GET_MODE (X)' 16635 Returns the machine mode of the RTX X. 16636 16637'PUT_MODE (X, NEWMODE)' 16638 Alters the machine mode of the RTX X to be NEWMODE. 16639 16640'NUM_MACHINE_MODES' 16641 Stands for the number of machine modes available on the target 16642 machine. This is one greater than the largest numeric value of any 16643 machine mode. 16644 16645'GET_MODE_NAME (M)' 16646 Returns the name of mode M as a string. 16647 16648'GET_MODE_CLASS (M)' 16649 Returns the mode class of mode M. 16650 16651'GET_MODE_WIDER_MODE (M)' 16652 Returns the next wider natural mode. For example, the expression 16653 'GET_MODE_WIDER_MODE (QImode)' returns 'HImode'. 16654 16655'GET_MODE_SIZE (M)' 16656 Returns the size in bytes of a datum of mode M. 16657 16658'GET_MODE_BITSIZE (M)' 16659 Returns the size in bits of a datum of mode M. 16660 16661'GET_MODE_IBIT (M)' 16662 Returns the number of integral bits of a datum of fixed-point mode 16663 M. 16664 16665'GET_MODE_FBIT (M)' 16666 Returns the number of fractional bits of a datum of fixed-point 16667 mode M. 16668 16669'GET_MODE_MASK (M)' 16670 Returns a bitmask containing 1 for all bits in a word that fit 16671 within mode M. This macro can only be used for modes whose bitsize 16672 is less than or equal to 'HOST_BITS_PER_INT'. 16673 16674'GET_MODE_ALIGNMENT (M)' 16675 Return the required alignment, in bits, for an object of mode M. 16676 16677'GET_MODE_UNIT_SIZE (M)' 16678 Returns the size in bytes of the subunits of a datum of mode M. 16679 This is the same as 'GET_MODE_SIZE' except in the case of complex 16680 modes. For them, the unit size is the size of the real or 16681 imaginary part. 16682 16683'GET_MODE_NUNITS (M)' 16684 Returns the number of units contained in a mode, i.e., 16685 'GET_MODE_SIZE' divided by 'GET_MODE_UNIT_SIZE'. 16686 16687'GET_CLASS_NARROWEST_MODE (C)' 16688 Returns the narrowest mode in mode class C. 16689 16690 The following 3 variables are defined on every target. They can be 16691used to allocate buffers that are guaranteed to be large enough to hold 16692any value that can be represented on the target. The first two can be 16693overridden by defining them in the target's mode.def file, however, the 16694value must be a constant that can determined very early in the 16695compilation process. The third symbol cannot be overridden. 16696 16697'BITS_PER_UNIT' 16698 The number of bits in an addressable storage unit (byte). If you 16699 do not define this, the default is 8. 16700 16701'MAX_BITSIZE_MODE_ANY_INT' 16702 The maximum bitsize of any mode that is used in integer math. This 16703 should be overridden by the target if it uses large integers as 16704 containers for larger vectors but otherwise never uses the contents 16705 to compute integer values. 16706 16707'MAX_BITSIZE_MODE_ANY_MODE' 16708 The bitsize of the largest mode on the target. The default value 16709 is the largest mode size given in the mode definition file, which 16710 is always correct for targets whose modes have a fixed size. 16711 Targets that might increase the size of a mode beyond this default 16712 should define 'MAX_BITSIZE_MODE_ANY_MODE' to the actual upper limit 16713 in 'MACHINE-modes.def'. 16714 16715 The global variables 'byte_mode' and 'word_mode' contain modes whose 16716classes are 'MODE_INT' and whose bitsizes are either 'BITS_PER_UNIT' or 16717'BITS_PER_WORD', respectively. On 32-bit machines, these are 'QImode' 16718and 'SImode', respectively. 16719 16720 16721File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL 16722 1672314.7 Constant Expression Types 16724============================== 16725 16726The simplest RTL expressions are those that represent constant values. 16727 16728'(const_int I)' 16729 This type of expression represents the integer value I. I is 16730 customarily accessed with the macro 'INTVAL' as in 'INTVAL (EXP)', 16731 which is equivalent to 'XWINT (EXP, 0)'. 16732 16733 Constants generated for modes with fewer bits than in 16734 'HOST_WIDE_INT' must be sign extended to full width (e.g., with 16735 'gen_int_mode'). For constants for modes with more bits than in 16736 'HOST_WIDE_INT' the implied high order bits of that constant are 16737 copies of the top bit. Note however that values are neither 16738 inherently signed nor inherently unsigned; where necessary, 16739 signedness is determined by the rtl operation instead. 16740 16741 There is only one expression object for the integer value zero; it 16742 is the value of the variable 'const0_rtx'. Likewise, the only 16743 expression for integer value one is found in 'const1_rtx', the only 16744 expression for integer value two is found in 'const2_rtx', and the 16745 only expression for integer value negative one is found in 16746 'constm1_rtx'. Any attempt to create an expression of code 16747 'const_int' and value zero, one, two or negative one will return 16748 'const0_rtx', 'const1_rtx', 'const2_rtx' or 'constm1_rtx' as 16749 appropriate. 16750 16751 Similarly, there is only one object for the integer whose value is 16752 'STORE_FLAG_VALUE'. It is found in 'const_true_rtx'. If 16753 'STORE_FLAG_VALUE' is one, 'const_true_rtx' and 'const1_rtx' will 16754 point to the same object. If 'STORE_FLAG_VALUE' is -1, 16755 'const_true_rtx' and 'constm1_rtx' will point to the same object. 16756 16757'(const_double:M I0 I1 ...)' 16758 This represents either a floating-point constant of mode M or (on 16759 older ports that do not define 'TARGET_SUPPORTS_WIDE_INT') an 16760 integer constant too large to fit into 'HOST_BITS_PER_WIDE_INT' 16761 bits but small enough to fit within twice that number of bits. In 16762 the latter case, M will be 'VOIDmode'. For integral values 16763 constants for modes with more bits than twice the number in 16764 'HOST_WIDE_INT' the implied high order bits of that constant are 16765 copies of the top bit of 'CONST_DOUBLE_HIGH'. Note however that 16766 integral values are neither inherently signed nor inherently 16767 unsigned; where necessary, signedness is determined by the rtl 16768 operation instead. 16769 16770 On more modern ports, 'CONST_DOUBLE' only represents floating point 16771 values. New ports define 'TARGET_SUPPORTS_WIDE_INT' to make this 16772 designation. 16773 16774 If M is 'VOIDmode', the bits of the value are stored in I0 and I1. 16775 I0 is customarily accessed with the macro 'CONST_DOUBLE_LOW' and I1 16776 with 'CONST_DOUBLE_HIGH'. 16777 16778 If the constant is floating point (regardless of its precision), 16779 then the number of integers used to store the value depends on the 16780 size of 'REAL_VALUE_TYPE' (*note Floating Point::). The integers 16781 represent a floating point number, but not precisely in the target 16782 machine's or host machine's floating point format. To convert them 16783 to the precise bit pattern used by the target machine, use the 16784 macro 'REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data 16785 Output::). 16786 16787'(const_wide_int:M NUNITS ELT0 ...)' 16788 This contains an array of 'HOST_WIDE_INT's that is large enough to 16789 hold any constant that can be represented on the target. This form 16790 of rtl is only used on targets that define 16791 'TARGET_SUPPORTS_WIDE_INT' to be nonzero and then 'CONST_DOUBLE's 16792 are only used to hold floating-point values. If the target leaves 16793 'TARGET_SUPPORTS_WIDE_INT' defined as 0, 'CONST_WIDE_INT's are not 16794 used and 'CONST_DOUBLE's are as they were before. 16795 16796 The values are stored in a compressed format. The higher-order 0s 16797 or -1s are not represented if they are just the logical sign 16798 extension of the number that is represented. 16799 16800'CONST_WIDE_INT_VEC (CODE)' 16801 Returns the entire array of 'HOST_WIDE_INT's that are used to store 16802 the value. This macro should be rarely used. 16803 16804'CONST_WIDE_INT_NUNITS (CODE)' 16805 The number of 'HOST_WIDE_INT's used to represent the number. Note 16806 that this generally is smaller than the number of 'HOST_WIDE_INT's 16807 implied by the mode size. 16808 16809'CONST_WIDE_INT_ELT (CODE,I)' 16810 Returns the 'i'th element of the array. Element 0 is contains the 16811 low order bits of the constant. 16812 16813'(const_fixed:M ...)' 16814 Represents a fixed-point constant of mode M. The operand is a data 16815 structure of type 'struct fixed_value' and is accessed with the 16816 macro 'CONST_FIXED_VALUE'. The high part of data is accessed with 16817 'CONST_FIXED_VALUE_HIGH'; the low part is accessed with 16818 'CONST_FIXED_VALUE_LOW'. 16819 16820'(const_poly_int:M [C0 C1 ...])' 16821 Represents a 'poly_int'-style polynomial integer with coefficients 16822 C0, C1, .... The coefficients are 'wide_int'-based integers rather 16823 than rtxes. 'CONST_POLY_INT_COEFFS' gives the values of individual 16824 coefficients (which is mostly only useful in low-level routines) 16825 and 'const_poly_int_value' gives the full 'poly_int' value. 16826 16827'(const_vector:M [X0 X1 ...])' 16828 Represents a vector constant. The values in square brackets are 16829 elements of the vector, which are always 'const_int', 16830 'const_wide_int', 'const_double' or 'const_fixed' expressions. 16831 16832 Each vector constant V is treated as a specific instance of an 16833 arbitrary-length sequence that itself contains 16834 'CONST_VECTOR_NPATTERNS (V)' interleaved patterns. Each pattern 16835 has the form: 16836 16837 { BASE0, BASE1, BASE1 + STEP, BASE1 + STEP * 2, ... } 16838 16839 The first three elements in each pattern are enough to determine 16840 the values of the other elements. However, if all STEPs are zero, 16841 only the first two elements are needed. If in addition each BASE1 16842 is equal to the corresponding BASE0, only the first element in each 16843 pattern is needed. The number of determining elements per pattern 16844 is given by 'CONST_VECTOR_NELTS_PER_PATTERN (V)'. 16845 16846 For example, the constant: 16847 16848 { 0, 1, 2, 6, 3, 8, 4, 10, 5, 12, 6, 14, 7, 16, 8, 18 } 16849 16850 is interpreted as an interleaving of the sequences: 16851 16852 { 0, 2, 3, 4, 5, 6, 7, 8 } 16853 { 1, 6, 8, 10, 12, 14, 16, 18 } 16854 16855 where the sequences are represented by the following patterns: 16856 16857 BASE0 == 0, BASE1 == 2, STEP == 1 16858 BASE0 == 1, BASE1 == 6, STEP == 2 16859 16860 In this case: 16861 16862 CONST_VECTOR_NPATTERNS (V) == 2 16863 CONST_VECTOR_NELTS_PER_PATTERN (V) == 3 16864 16865 Thus the first 6 elements ('{ 0, 1, 2, 6, 3, 8 }') are enough to 16866 determine the whole sequence; we refer to them as the "encoded" 16867 elements. They are the only elements present in the square 16868 brackets for variable-length 'const_vector's (i.e. for 16869 'const_vector's whose mode M has a variable number of elements). 16870 However, as a convenience to code that needs to handle both 16871 'const_vector's and 'parallel's, all elements are present in the 16872 square brackets for fixed-length 'const_vector's; the encoding 16873 scheme simply reduces the amount of work involved in processing 16874 constants that follow a regular pattern. 16875 16876 Sometimes this scheme can create two possible encodings of the same 16877 vector. For example { 0, 1 } could be seen as two patterns with 16878 one element each or one pattern with two elements (BASE0 and 16879 BASE1). The canonical encoding is always the one with the fewest 16880 patterns or (if both encodings have the same number of petterns) 16881 the one with the fewest encoded elements. 16882 16883 'const_vector_encoding_nelts (V)' gives the total number of encoded 16884 elements in V, which is 6 in the example above. 16885 'CONST_VECTOR_ENCODED_ELT (V, I)' accesses the value of encoded 16886 element I. 16887 16888 'CONST_VECTOR_DUPLICATE_P (V)' is true if V simply contains 16889 repeated instances of 'CONST_VECTOR_NPATTERNS (V)' values. This is 16890 a shorthand for testing 'CONST_VECTOR_NELTS_PER_PATTERN (V) == 1'. 16891 16892 'CONST_VECTOR_STEPPED_P (V)' is true if at least one pattern in V 16893 has a nonzero step. This is a shorthand for testing 16894 'CONST_VECTOR_NELTS_PER_PATTERN (V) == 3'. 16895 16896 'CONST_VECTOR_NUNITS (V)' gives the total number of elements in V; 16897 it is a shorthand for getting the number of units in 'GET_MODE 16898 (V)'. 16899 16900 The utility function 'const_vector_elt' gives the value of an 16901 arbitrary element as an 'rtx'. 'const_vector_int_elt' gives the 16902 same value as a 'wide_int'. 16903 16904'(const_string STR)' 16905 Represents a constant string with value STR. Currently this is 16906 used only for insn attributes (*note Insn Attributes::) since 16907 constant strings in C are placed in memory. 16908 16909'(symbol_ref:MODE SYMBOL)' 16910 Represents the value of an assembler label for data. SYMBOL is a 16911 string that describes the name of the assembler label. If it 16912 starts with a '*', the label is the rest of SYMBOL not including 16913 the '*'. Otherwise, the label is SYMBOL, usually prefixed with 16914 '_'. 16915 16916 The 'symbol_ref' contains a mode, which is usually 'Pmode'. 16917 Usually that is the only mode for which a symbol is directly valid. 16918 16919'(label_ref:MODE LABEL)' 16920 Represents the value of an assembler label for code. It contains 16921 one operand, an expression, which must be a 'code_label' or a 16922 'note' of type 'NOTE_INSN_DELETED_LABEL' that appears in the 16923 instruction sequence to identify the place where the label should 16924 go. 16925 16926 The reason for using a distinct expression type for code label 16927 references is so that jump optimization can distinguish them. 16928 16929 The 'label_ref' contains a mode, which is usually 'Pmode'. Usually 16930 that is the only mode for which a label is directly valid. 16931 16932'(const:M EXP)' 16933 Represents a constant that is the result of an assembly-time 16934 arithmetic computation. The operand, EXP, contains only 16935 'const_int', 'symbol_ref', 'label_ref' or 'unspec' expressions, 16936 combined with 'plus' and 'minus'. Any such 'unspec's are 16937 target-specific and typically represent some form of relocation 16938 operator. M should be a valid address mode. 16939 16940'(high:M EXP)' 16941 Represents the high-order bits of EXP. The number of bits is 16942 machine-dependent and is normally the number of bits specified in 16943 an instruction that initializes the high order bits of a register. 16944 It is used with 'lo_sum' to represent the typical two-instruction 16945 sequence used in RISC machines to reference large immediate values 16946 and/or link-time constants such as global memory addresses. In the 16947 latter case, M is 'Pmode' and EXP is usually a constant expression 16948 involving 'symbol_ref'. 16949 16950 The macro 'CONST0_RTX (MODE)' refers to an expression with value 0 in 16951mode MODE. If mode MODE is of mode class 'MODE_INT', it returns 16952'const0_rtx'. If mode MODE is of mode class 'MODE_FLOAT', it returns a 16953'CONST_DOUBLE' expression in mode MODE. Otherwise, it returns a 16954'CONST_VECTOR' expression in mode MODE. Similarly, the macro 16955'CONST1_RTX (MODE)' refers to an expression with value 1 in mode MODE 16956and similarly for 'CONST2_RTX'. The 'CONST1_RTX' and 'CONST2_RTX' 16957macros are undefined for vector modes. 16958 16959 16960File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL 16961 1696214.8 Registers and Memory 16963========================= 16964 16965Here are the RTL expression types for describing access to machine 16966registers and to main memory. 16967 16968'(reg:M N)' 16969 For small values of the integer N (those that are less than 16970 'FIRST_PSEUDO_REGISTER'), this stands for a reference to machine 16971 register number N: a "hard register". For larger values of N, it 16972 stands for a temporary value or "pseudo register". The compiler's 16973 strategy is to generate code assuming an unlimited number of such 16974 pseudo registers, and later convert them into hard registers or 16975 into memory references. 16976 16977 M is the machine mode of the reference. It is necessary because 16978 machines can generally refer to each register in more than one 16979 mode. For example, a register may contain a full word but there 16980 may be instructions to refer to it as a half word or as a single 16981 byte, as well as instructions to refer to it as a floating point 16982 number of various precisions. 16983 16984 Even for a register that the machine can access in only one mode, 16985 the mode must always be specified. 16986 16987 The symbol 'FIRST_PSEUDO_REGISTER' is defined by the machine 16988 description, since the number of hard registers on the machine is 16989 an invariant characteristic of the machine. Note, however, that 16990 not all of the machine registers must be general registers. All 16991 the machine registers that can be used for storage of data are 16992 given hard register numbers, even those that can be used only in 16993 certain instructions or can hold only certain types of data. 16994 16995 A hard register may be accessed in various modes throughout one 16996 function, but each pseudo register is given a natural mode and is 16997 accessed only in that mode. When it is necessary to describe an 16998 access to a pseudo register using a nonnatural mode, a 'subreg' 16999 expression is used. 17000 17001 A 'reg' expression with a machine mode that specifies more than one 17002 word of data may actually stand for several consecutive registers. 17003 If in addition the register number specifies a hardware register, 17004 then it actually represents several consecutive hardware registers 17005 starting with the specified one. 17006 17007 Each pseudo register number used in a function's RTL code is 17008 represented by a unique 'reg' expression. 17009 17010 Some pseudo register numbers, those within the range of 17011 'FIRST_VIRTUAL_REGISTER' to 'LAST_VIRTUAL_REGISTER' only appear 17012 during the RTL generation phase and are eliminated before the 17013 optimization phases. These represent locations in the stack frame 17014 that cannot be determined until RTL generation for the function has 17015 been completed. The following virtual register numbers are 17016 defined: 17017 17018 'VIRTUAL_INCOMING_ARGS_REGNUM' 17019 This points to the first word of the incoming arguments passed 17020 on the stack. Normally these arguments are placed there by 17021 the caller, but the callee may have pushed some arguments that 17022 were previously passed in registers. 17023 17024 When RTL generation is complete, this virtual register is 17025 replaced by the sum of the register given by 17026 'ARG_POINTER_REGNUM' and the value of 'FIRST_PARM_OFFSET'. 17027 17028 'VIRTUAL_STACK_VARS_REGNUM' 17029 If 'FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this 17030 points to immediately above the first variable on the stack. 17031 Otherwise, it points to the first variable on the stack. 17032 17033 'VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the 17034 register given by 'FRAME_POINTER_REGNUM' and the value 17035 'TARGET_STARTING_FRAME_OFFSET'. 17036 17037 'VIRTUAL_STACK_DYNAMIC_REGNUM' 17038 This points to the location of dynamically allocated memory on 17039 the stack immediately after the stack pointer has been 17040 adjusted by the amount of memory desired. 17041 17042 This virtual register is replaced by the sum of the register 17043 given by 'STACK_POINTER_REGNUM' and the value 17044 'STACK_DYNAMIC_OFFSET'. 17045 17046 'VIRTUAL_OUTGOING_ARGS_REGNUM' 17047 This points to the location in the stack at which outgoing 17048 arguments should be written when the stack is pre-pushed 17049 (arguments pushed using push insns should always use 17050 'STACK_POINTER_REGNUM'). 17051 17052 This virtual register is replaced by the sum of the register 17053 given by 'STACK_POINTER_REGNUM' and the value 17054 'STACK_POINTER_OFFSET'. 17055 17056'(subreg:M1 REG:M2 BYTENUM)' 17057 17058 'subreg' expressions are used to refer to a register in a machine 17059 mode other than its natural one, or to refer to one register of a 17060 multi-part 'reg' that actually refers to several registers. 17061 17062 Each pseudo register has a natural mode. If it is necessary to 17063 operate on it in a different mode, the register must be enclosed in 17064 a 'subreg'. 17065 17066 There are currently three supported types for the first operand of 17067 a 'subreg': 17068 * pseudo registers This is the most common case. Most 'subreg's 17069 have pseudo 'reg's as their first operand. 17070 17071 * mem 'subreg's of 'mem' were common in earlier versions of GCC 17072 and are still supported. During the reload pass these are 17073 replaced by plain 'mem's. On machines that do not do 17074 instruction scheduling, use of 'subreg's of 'mem' are still 17075 used, but this is no longer recommended. Such 'subreg's are 17076 considered to be 'register_operand's rather than 17077 'memory_operand's before and during reload. Because of this, 17078 the scheduling passes cannot properly schedule instructions 17079 with 'subreg's of 'mem', so for machines that do scheduling, 17080 'subreg's of 'mem' should never be used. To support this, the 17081 combine and recog passes have explicit code to inhibit the 17082 creation of 'subreg's of 'mem' when 'INSN_SCHEDULING' is 17083 defined. 17084 17085 The use of 'subreg's of 'mem' after the reload pass is an area 17086 that is not well understood and should be avoided. There is 17087 still some code in the compiler to support this, but this code 17088 has possibly rotted. This use of 'subreg's is discouraged and 17089 will most likely not be supported in the future. 17090 17091 * hard registers It is seldom necessary to wrap hard registers 17092 in 'subreg's; such registers would normally reduce to a single 17093 'reg' rtx. This use of 'subreg's is discouraged and may not 17094 be supported in the future. 17095 17096 'subreg's of 'subreg's are not supported. Using 17097 'simplify_gen_subreg' is the recommended way to avoid this problem. 17098 17099 'subreg's come in two distinct flavors, each having its own usage 17100 and rules: 17101 17102 Paradoxical subregs 17103 When M1 is strictly wider than M2, the 'subreg' expression is 17104 called "paradoxical". The canonical test for this class of 17105 'subreg' is: 17106 17107 paradoxical_subreg_p (M1, M2) 17108 17109 Paradoxical 'subreg's can be used as both lvalues and rvalues. 17110 When used as an lvalue, the low-order bits of the source value 17111 are stored in REG and the high-order bits are discarded. When 17112 used as an rvalue, the low-order bits of the 'subreg' are 17113 taken from REG while the high-order bits may or may not be 17114 defined. 17115 17116 The high-order bits of rvalues are defined in the following 17117 circumstances: 17118 17119 * 'subreg's of 'mem' When M2 is smaller than a word, the 17120 macro 'LOAD_EXTEND_OP', can control how the high-order 17121 bits are defined. 17122 17123 * 'subreg' of 'reg's The upper bits are defined when 17124 'SUBREG_PROMOTED_VAR_P' is true. 17125 'SUBREG_PROMOTED_UNSIGNED_P' describes what the upper 17126 bits hold. Such subregs usually represent local 17127 variables, register variables and parameter pseudo 17128 variables that have been promoted to a wider mode. 17129 17130 BYTENUM is always zero for a paradoxical 'subreg', even on 17131 big-endian targets. 17132 17133 For example, the paradoxical 'subreg': 17134 17135 (set (subreg:SI (reg:HI X) 0) Y) 17136 17137 stores the lower 2 bytes of Y in X and discards the upper 2 17138 bytes. A subsequent: 17139 17140 (set Z (subreg:SI (reg:HI X) 0)) 17141 17142 would set the lower two bytes of Z to Y and set the upper two 17143 bytes to an unknown value assuming 'SUBREG_PROMOTED_VAR_P' is 17144 false. 17145 17146 Normal subregs 17147 When M1 is at least as narrow as M2 the 'subreg' expression is 17148 called "normal". 17149 17150 Normal 'subreg's restrict consideration to certain bits of 17151 REG. For this purpose, REG is divided into 17152 individually-addressable blocks in which each block has: 17153 17154 REGMODE_NATURAL_SIZE (M2) 17155 17156 bytes. Usually the value is 'UNITS_PER_WORD'; that is, most 17157 targets usually treat each word of a register as being 17158 independently addressable. 17159 17160 There are two types of normal 'subreg'. If M1 is known to be 17161 no bigger than a block, the 'subreg' refers to the 17162 least-significant part (or "lowpart") of one block of REG. If 17163 M1 is known to be larger than a block, the 'subreg' refers to 17164 two or more complete blocks. 17165 17166 When used as an lvalue, 'subreg' is a block-based accessor. 17167 Storing to a 'subreg' modifies all the blocks of REG that 17168 overlap the 'subreg', but it leaves the other blocks of REG 17169 alone. 17170 17171 When storing to a normal 'subreg' that is smaller than a 17172 block, the other bits of the referenced block are usually left 17173 in an undefined state. This laxity makes it easier to 17174 generate efficient code for such instructions. To represent 17175 an instruction that preserves all the bits outside of those in 17176 the 'subreg', use 'strict_low_part' or 'zero_extract' around 17177 the 'subreg'. 17178 17179 BYTENUM must identify the offset of the first byte of the 17180 'subreg' from the start of REG, assuming that REG is laid out 17181 in memory order. The memory order of bytes is defined by two 17182 target macros, 'WORDS_BIG_ENDIAN' and 'BYTES_BIG_ENDIAN': 17183 17184 * 'WORDS_BIG_ENDIAN', if set to 1, says that byte number 17185 zero is part of the most significant word; otherwise, it 17186 is part of the least significant word. 17187 17188 * 'BYTES_BIG_ENDIAN', if set to 1, says that byte number 17189 zero is the most significant byte within a word; 17190 otherwise, it is the least significant byte within a 17191 word. 17192 17193 On a few targets, 'FLOAT_WORDS_BIG_ENDIAN' disagrees with 17194 'WORDS_BIG_ENDIAN'. However, most parts of the compiler treat 17195 floating point values as if they had the same endianness as 17196 integer values. This works because they handle them solely as 17197 a collection of integer values, with no particular numerical 17198 value. Only real.c and the runtime libraries care about 17199 'FLOAT_WORDS_BIG_ENDIAN'. 17200 17201 Thus, 17202 17203 (subreg:HI (reg:SI X) 2) 17204 17205 on a 'BYTES_BIG_ENDIAN', 'UNITS_PER_WORD == 4' target is the 17206 same as 17207 17208 (subreg:HI (reg:SI X) 0) 17209 17210 on a little-endian, 'UNITS_PER_WORD == 4' target. Both 17211 'subreg's access the lower two bytes of register X. 17212 17213 Note that the byte offset is a polynomial integer; it may not 17214 be a compile-time constant on targets with variable-sized 17215 modes. However, the restrictions above mean that there are 17216 only a certain set of acceptable offsets for a given 17217 combination of M1 and M2. The compiler can always tell which 17218 blocks a valid subreg occupies, and whether the subreg is a 17219 lowpart of a block. 17220 17221 A 'MODE_PARTIAL_INT' mode behaves as if it were as wide as the 17222 corresponding 'MODE_INT' mode, except that it has an unknown number 17223 of undefined bits. For example: 17224 17225 (subreg:PSI (reg:SI 0) 0) 17226 17227 accesses the whole of '(reg:SI 0)', but the exact relationship 17228 between the 'PSImode' value and the 'SImode' value is not defined. 17229 If we assume 'REGMODE_NATURAL_SIZE (DImode) <= 4', then the 17230 following two 'subreg's: 17231 17232 (subreg:PSI (reg:DI 0) 0) 17233 (subreg:PSI (reg:DI 0) 4) 17234 17235 represent independent 4-byte accesses to the two halves of '(reg:DI 17236 0)'. Both 'subreg's have an unknown number of undefined bits. 17237 17238 If 'REGMODE_NATURAL_SIZE (PSImode) <= 2' then these two 'subreg's: 17239 17240 (subreg:HI (reg:PSI 0) 0) 17241 (subreg:HI (reg:PSI 0) 2) 17242 17243 represent independent 2-byte accesses that together span the whole 17244 of '(reg:PSI 0)'. Storing to the first 'subreg' does not affect 17245 the value of the second, and vice versa. '(reg:PSI 0)' has an 17246 unknown number of undefined bits, so the assignment: 17247 17248 (set (subreg:HI (reg:PSI 0) 0) (reg:HI 4)) 17249 17250 does not guarantee that '(subreg:HI (reg:PSI 0) 0)' has the value 17251 '(reg:HI 4)'. 17252 17253 The rules above apply to both pseudo REGs and hard REGs. If the 17254 semantics are not correct for particular combinations of M1, M2 and 17255 hard REG, the target-specific code must ensure that those 17256 combinations are never used. For example: 17257 17258 TARGET_CAN_CHANGE_MODE_CLASS (M2, M1, CLASS) 17259 17260 must be false for every class CLASS that includes REG. 17261 17262 GCC must be able to determine at compile time whether a subreg is 17263 paradoxical, whether it occupies a whole number of blocks, or 17264 whether it is a lowpart of a block. This means that certain 17265 combinations of variable-sized mode are not permitted. For 17266 example, if M2 holds N 'SI' values, where N is greater than zero, 17267 it is not possible to form a 'DI' 'subreg' of it; such a 'subreg' 17268 would be paradoxical when N is 1 but not when N is greater than 1. 17269 17270 The first operand of a 'subreg' expression is customarily accessed 17271 with the 'SUBREG_REG' macro and the second operand is customarily 17272 accessed with the 'SUBREG_BYTE' macro. 17273 17274 It has been several years since a platform in which 17275 'BYTES_BIG_ENDIAN' not equal to 'WORDS_BIG_ENDIAN' has been tested. 17276 Anyone wishing to support such a platform in the future may be 17277 confronted with code rot. 17278 17279'(scratch:M)' 17280 This represents a scratch register that will be required for the 17281 execution of a single instruction and not used subsequently. It is 17282 converted into a 'reg' by either the local register allocator or 17283 the reload pass. 17284 17285 'scratch' is usually present inside a 'clobber' operation (*note 17286 Side Effects::). 17287 17288'(cc0)' 17289 This refers to the machine's condition code register. It has no 17290 operands and may not have a machine mode. There are two ways to 17291 use it: 17292 17293 * To stand for a complete set of condition code flags. This is 17294 best on most machines, where each comparison sets the entire 17295 series of flags. 17296 17297 With this technique, '(cc0)' may be validly used in only two 17298 contexts: as the destination of an assignment (in test and 17299 compare instructions) and in comparison operators comparing 17300 against zero ('const_int' with value zero; that is to say, 17301 'const0_rtx'). 17302 17303 * To stand for a single flag that is the result of a single 17304 condition. This is useful on machines that have only a single 17305 flag bit, and in which comparison instructions must specify 17306 the condition to test. 17307 17308 With this technique, '(cc0)' may be validly used in only two 17309 contexts: as the destination of an assignment (in test and 17310 compare instructions) where the source is a comparison 17311 operator, and as the first operand of 'if_then_else' (in a 17312 conditional branch). 17313 17314 There is only one expression object of code 'cc0'; it is the value 17315 of the variable 'cc0_rtx'. Any attempt to create an expression of 17316 code 'cc0' will return 'cc0_rtx'. 17317 17318 Instructions can set the condition code implicitly. On many 17319 machines, nearly all instructions set the condition code based on 17320 the value that they compute or store. It is not necessary to 17321 record these actions explicitly in the RTL because the machine 17322 description includes a prescription for recognizing the 17323 instructions that do so (by means of the macro 'NOTICE_UPDATE_CC'). 17324 *Note Condition Code::. Only instructions whose sole purpose is to 17325 set the condition code, and instructions that use the condition 17326 code, need mention '(cc0)'. 17327 17328 On some machines, the condition code register is given a register 17329 number and a 'reg' is used instead of '(cc0)'. This is usually the 17330 preferable approach if only a small subset of instructions modify 17331 the condition code. Other machines store condition codes in 17332 general registers; in such cases a pseudo register should be used. 17333 17334 Some machines, such as the SPARC and RS/6000, have two sets of 17335 arithmetic instructions, one that sets and one that does not set 17336 the condition code. This is best handled by normally generating 17337 the instruction that does not set the condition code, and making a 17338 pattern that both performs the arithmetic and sets the condition 17339 code register (which would not be '(cc0)' in this case). For 17340 examples, search for 'addcc' and 'andcc' in 'sparc.md'. 17341 17342'(pc)' 17343 This represents the machine's program counter. It has no operands 17344 and may not have a machine mode. '(pc)' may be validly used only 17345 in certain specific contexts in jump instructions. 17346 17347 There is only one expression object of code 'pc'; it is the value 17348 of the variable 'pc_rtx'. Any attempt to create an expression of 17349 code 'pc' will return 'pc_rtx'. 17350 17351 All instructions that do not jump alter the program counter 17352 implicitly by incrementing it, but there is no need to mention this 17353 in the RTL. 17354 17355'(mem:M ADDR ALIAS)' 17356 This RTX represents a reference to main memory at an address 17357 represented by the expression ADDR. M specifies how large a unit 17358 of memory is accessed. ALIAS specifies an alias set for the 17359 reference. In general two items are in different alias sets if 17360 they cannot reference the same memory address. 17361 17362 The construct '(mem:BLK (scratch))' is considered to alias all 17363 other memories. Thus it may be used as a memory barrier in 17364 epilogue stack deallocation patterns. 17365 17366'(concatM RTX RTX)' 17367 This RTX represents the concatenation of two other RTXs. This is 17368 used for complex values. It should only appear in the RTL attached 17369 to declarations and during RTL generation. It should not appear in 17370 the ordinary insn chain. 17371 17372'(concatnM [RTX ...])' 17373 This RTX represents the concatenation of all the RTX to make a 17374 single value. Like 'concat', this should only appear in 17375 declarations, and not in the insn chain. 17376 17377 17378File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL 17379 1738014.9 RTL Expressions for Arithmetic 17381=================================== 17382 17383Unless otherwise specified, all the operands of arithmetic expressions 17384must be valid for mode M. An operand is valid for mode M if it has mode 17385M, or if it is a 'const_int' or 'const_double' and M is a mode of class 17386'MODE_INT'. 17387 17388 For commutative binary operations, constants should be placed in the 17389second operand. 17390 17391'(plus:M X Y)' 17392'(ss_plus:M X Y)' 17393'(us_plus:M X Y)' 17394 17395 These three expressions all represent the sum of the values 17396 represented by X and Y carried out in machine mode M. They differ 17397 in their behavior on overflow of integer modes. 'plus' wraps round 17398 modulo the width of M; 'ss_plus' saturates at the maximum signed 17399 value representable in M; 'us_plus' saturates at the maximum 17400 unsigned value. 17401 17402'(lo_sum:M X Y)' 17403 17404 This expression represents the sum of X and the low-order bits of 17405 Y. It is used with 'high' (*note Constants::) to represent the 17406 typical two-instruction sequence used in RISC machines to reference 17407 large immediate values and/or link-time constants such as global 17408 memory addresses. In the latter case, M is 'Pmode' and Y is 17409 usually a constant expression involving 'symbol_ref'. 17410 17411 The number of low order bits is machine-dependent but is normally 17412 the number of bits in mode M minus the number of bits set by 17413 'high'. 17414 17415'(minus:M X Y)' 17416'(ss_minus:M X Y)' 17417'(us_minus:M X Y)' 17418 17419 These three expressions represent the result of subtracting Y from 17420 X, carried out in mode M. Behavior on overflow is the same as for 17421 the three variants of 'plus' (see above). 17422 17423'(compare:M X Y)' 17424 Represents the result of subtracting Y from X for purposes of 17425 comparison. The result is computed without overflow, as if with 17426 infinite precision. 17427 17428 Of course, machines cannot really subtract with infinite precision. 17429 However, they can pretend to do so when only the sign of the result 17430 will be used, which is the case when the result is stored in the 17431 condition code. And that is the _only_ way this kind of expression 17432 may validly be used: as a value to be stored in the condition 17433 codes, either '(cc0)' or a register. *Note Comparisons::. 17434 17435 The mode M is not related to the modes of X and Y, but instead is 17436 the mode of the condition code value. If '(cc0)' is used, it is 17437 'VOIDmode'. Otherwise it is some mode in class 'MODE_CC', often 17438 'CCmode'. *Note Condition Code::. If M is 'VOIDmode' or 'CCmode', 17439 the operation returns sufficient information (in an unspecified 17440 format) so that any comparison operator can be applied to the 17441 result of the 'COMPARE' operation. For other modes in class 17442 'MODE_CC', the operation only returns a subset of this information. 17443 17444 Normally, X and Y must have the same mode. Otherwise, 'compare' is 17445 valid only if the mode of X is in class 'MODE_INT' and Y is a 17446 'const_int' or 'const_double' with mode 'VOIDmode'. The mode of X 17447 determines what mode the comparison is to be done in; thus it must 17448 not be 'VOIDmode'. 17449 17450 If one of the operands is a constant, it should be placed in the 17451 second operand and the comparison code adjusted as appropriate. 17452 17453 A 'compare' specifying two 'VOIDmode' constants is not valid since 17454 there is no way to know in what mode the comparison is to be 17455 performed; the comparison must either be folded during the 17456 compilation or the first operand must be loaded into a register 17457 while its mode is still known. 17458 17459'(neg:M X)' 17460'(ss_neg:M X)' 17461'(us_neg:M X)' 17462 These two expressions represent the negation (subtraction from 17463 zero) of the value represented by X, carried out in mode M. They 17464 differ in the behavior on overflow of integer modes. In the case 17465 of 'neg', the negation of the operand may be a number not 17466 representable in mode M, in which case it is truncated to M. 17467 'ss_neg' and 'us_neg' ensure that an out-of-bounds result saturates 17468 to the maximum or minimum signed or unsigned value. 17469 17470'(mult:M X Y)' 17471'(ss_mult:M X Y)' 17472'(us_mult:M X Y)' 17473 Represents the signed product of the values represented by X and Y 17474 carried out in machine mode M. 'ss_mult' and 'us_mult' ensure that 17475 an out-of-bounds result saturates to the maximum or minimum signed 17476 or unsigned value. 17477 17478 Some machines support a multiplication that generates a product 17479 wider than the operands. Write the pattern for this as 17480 17481 (mult:M (sign_extend:M X) (sign_extend:M Y)) 17482 17483 where M is wider than the modes of X and Y, which need not be the 17484 same. 17485 17486 For unsigned widening multiplication, use the same idiom, but with 17487 'zero_extend' instead of 'sign_extend'. 17488 17489'(fma:M X Y Z)' 17490 Represents the 'fma', 'fmaf', and 'fmal' builtin functions, which 17491 compute 'X * Y + Z' without doing an intermediate rounding step. 17492 17493'(div:M X Y)' 17494'(ss_div:M X Y)' 17495 Represents the quotient in signed division of X by Y, carried out 17496 in machine mode M. If M is a floating point mode, it represents 17497 the exact quotient; otherwise, the integerized quotient. 'ss_div' 17498 ensures that an out-of-bounds result saturates to the maximum or 17499 minimum signed value. 17500 17501 Some machines have division instructions in which the operands and 17502 quotient widths are not all the same; you should represent such 17503 instructions using 'truncate' and 'sign_extend' as in, 17504 17505 (truncate:M1 (div:M2 X (sign_extend:M2 Y))) 17506 17507'(udiv:M X Y)' 17508'(us_div:M X Y)' 17509 Like 'div' but represents unsigned division. 'us_div' ensures that 17510 an out-of-bounds result saturates to the maximum or minimum 17511 unsigned value. 17512 17513'(mod:M X Y)' 17514'(umod:M X Y)' 17515 Like 'div' and 'udiv' but represent the remainder instead of the 17516 quotient. 17517 17518'(smin:M X Y)' 17519'(smax:M X Y)' 17520 Represents the smaller (for 'smin') or larger (for 'smax') of X and 17521 Y, interpreted as signed values in mode M. When used with floating 17522 point, if both operands are zeros, or if either operand is 'NaN', 17523 then it is unspecified which of the two operands is returned as the 17524 result. 17525 17526'(umin:M X Y)' 17527'(umax:M X Y)' 17528 Like 'smin' and 'smax', but the values are interpreted as unsigned 17529 integers. 17530 17531'(not:M X)' 17532 Represents the bitwise complement of the value represented by X, 17533 carried out in mode M, which must be a fixed-point machine mode. 17534 17535'(and:M X Y)' 17536 Represents the bitwise logical-and of the values represented by X 17537 and Y, carried out in machine mode M, which must be a fixed-point 17538 machine mode. 17539 17540'(ior:M X Y)' 17541 Represents the bitwise inclusive-or of the values represented by X 17542 and Y, carried out in machine mode M, which must be a fixed-point 17543 mode. 17544 17545'(xor:M X Y)' 17546 Represents the bitwise exclusive-or of the values represented by X 17547 and Y, carried out in machine mode M, which must be a fixed-point 17548 mode. 17549 17550'(ashift:M X C)' 17551'(ss_ashift:M X C)' 17552'(us_ashift:M X C)' 17553 These three expressions represent the result of arithmetically 17554 shifting X left by C places. They differ in their behavior on 17555 overflow of integer modes. An 'ashift' operation is a plain shift 17556 with no special behavior in case of a change in the sign bit; 17557 'ss_ashift' and 'us_ashift' saturates to the minimum or maximum 17558 representable value if any of the bits shifted out differs from the 17559 final sign bit. 17560 17561 X have mode M, a fixed-point machine mode. C be a fixed-point mode 17562 or be a constant with mode 'VOIDmode'; which mode is determined by 17563 the mode called for in the machine description entry for the 17564 left-shift instruction. For example, on the VAX, the mode of C is 17565 'QImode' regardless of M. 17566 17567'(lshiftrt:M X C)' 17568'(ashiftrt:M X C)' 17569 Like 'ashift' but for right shift. Unlike the case for left shift, 17570 these two operations are distinct. 17571 17572'(rotate:M X C)' 17573'(rotatert:M X C)' 17574 Similar but represent left and right rotate. If C is a constant, 17575 use 'rotate'. 17576 17577'(abs:M X)' 17578'(ss_abs:M X)' 17579 Represents the absolute value of X, computed in mode M. 'ss_abs' 17580 ensures that an out-of-bounds result saturates to the maximum 17581 signed value. 17582 17583'(sqrt:M X)' 17584 Represents the square root of X, computed in mode M. Most often M 17585 will be a floating point mode. 17586 17587'(ffs:M X)' 17588 Represents one plus the index of the least significant 1-bit in X, 17589 represented as an integer of mode M. (The value is zero if X is 17590 zero.) The mode of X must be M or 'VOIDmode'. 17591 17592'(clrsb:M X)' 17593 Represents the number of redundant leading sign bits in X, 17594 represented as an integer of mode M, starting at the most 17595 significant bit position. This is one less than the number of 17596 leading sign bits (either 0 or 1), with no special cases. The mode 17597 of X must be M or 'VOIDmode'. 17598 17599'(clz:M X)' 17600 Represents the number of leading 0-bits in X, represented as an 17601 integer of mode M, starting at the most significant bit position. 17602 If X is zero, the value is determined by 17603 'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Note that this is one 17604 of the few expressions that is not invariant under widening. The 17605 mode of X must be M or 'VOIDmode'. 17606 17607'(ctz:M X)' 17608 Represents the number of trailing 0-bits in X, represented as an 17609 integer of mode M, starting at the least significant bit position. 17610 If X is zero, the value is determined by 17611 'CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Except for this case, 17612 'ctz(x)' is equivalent to 'ffs(X) - 1'. The mode of X must be M or 17613 'VOIDmode'. 17614 17615'(popcount:M X)' 17616 Represents the number of 1-bits in X, represented as an integer of 17617 mode M. The mode of X must be M or 'VOIDmode'. 17618 17619'(parity:M X)' 17620 Represents the number of 1-bits modulo 2 in X, represented as an 17621 integer of mode M. The mode of X must be M or 'VOIDmode'. 17622 17623'(bswap:M X)' 17624 Represents the value X with the order of bytes reversed, carried 17625 out in mode M, which must be a fixed-point machine mode. The mode 17626 of X must be M or 'VOIDmode'. 17627 17628 17629File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL 17630 1763114.10 Comparison Operations 17632=========================== 17633 17634Comparison operators test a relation on two operands and are considered 17635to represent a machine-dependent nonzero value described by, but not 17636necessarily equal to, 'STORE_FLAG_VALUE' (*note Misc::) if the relation 17637holds, or zero if it does not, for comparison operators whose results 17638have a 'MODE_INT' mode, 'FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the 17639relation holds, or zero if it does not, for comparison operators that 17640return floating-point values, and a vector of either 17641'VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of 17642zeros if it does not, for comparison operators that return vector 17643results. The mode of the comparison operation is independent of the 17644mode of the data being compared. If the comparison operation is being 17645tested (e.g., the first operand of an 'if_then_else'), the mode must be 17646'VOIDmode'. 17647 17648 There are two ways that comparison operations may be used. The 17649comparison operators may be used to compare the condition codes '(cc0)' 17650against zero, as in '(eq (cc0) (const_int 0))'. Such a construct 17651actually refers to the result of the preceding instruction in which the 17652condition codes were set. The instruction setting the condition code 17653must be adjacent to the instruction using the condition code; only 17654'note' insns may separate them. 17655 17656 Alternatively, a comparison operation may directly compare two data 17657objects. The mode of the comparison is determined by the operands; they 17658must both be valid for a common machine mode. A comparison with both 17659operands constant would be invalid as the machine mode could not be 17660deduced from it, but such a comparison should never exist in RTL due to 17661constant folding. 17662 17663 In the example above, if '(cc0)' were last set to '(compare X Y)', the 17664comparison operation is identical to '(eq X Y)'. Usually only one style 17665of comparisons is supported on a particular machine, but the combine 17666pass will try to merge the operations to produce the 'eq' shown in case 17667it exists in the context of the particular insn involved. 17668 17669 Inequality comparisons come in two flavors, signed and unsigned. Thus, 17670there are distinct expression codes 'gt' and 'gtu' for signed and 17671unsigned greater-than. These can produce different results for the same 17672pair of integer values: for example, 1 is signed greater-than -1 but not 17673unsigned greater-than, because -1 when regarded as unsigned is actually 17674'0xffffffff' which is greater than 1. 17675 17676 The signed comparisons are also used for floating point values. 17677Floating point comparisons are distinguished by the machine modes of the 17678operands. 17679 17680'(eq:M X Y)' 17681 'STORE_FLAG_VALUE' if the values represented by X and Y are equal, 17682 otherwise 0. 17683 17684'(ne:M X Y)' 17685 'STORE_FLAG_VALUE' if the values represented by X and Y are not 17686 equal, otherwise 0. 17687 17688'(gt:M X Y)' 17689 'STORE_FLAG_VALUE' if the X is greater than Y. If they are 17690 fixed-point, the comparison is done in a signed sense. 17691 17692'(gtu:M X Y)' 17693 Like 'gt' but does unsigned comparison, on fixed-point numbers 17694 only. 17695 17696'(lt:M X Y)' 17697'(ltu:M X Y)' 17698 Like 'gt' and 'gtu' but test for "less than". 17699 17700'(ge:M X Y)' 17701'(geu:M X Y)' 17702 Like 'gt' and 'gtu' but test for "greater than or equal". 17703 17704'(le:M X Y)' 17705'(leu:M X Y)' 17706 Like 'gt' and 'gtu' but test for "less than or equal". 17707 17708'(if_then_else COND THEN ELSE)' 17709 This is not a comparison operation but is listed here because it is 17710 always used in conjunction with a comparison operation. To be 17711 precise, COND is a comparison expression. This expression 17712 represents a choice, according to COND, between the value 17713 represented by THEN and the one represented by ELSE. 17714 17715 On most machines, 'if_then_else' expressions are valid only to 17716 express conditional jumps. 17717 17718'(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' 17719 Similar to 'if_then_else', but more general. Each of TEST1, TEST2, 17720 ... is performed in turn. The result of this expression is the 17721 VALUE corresponding to the first nonzero test, or DEFAULT if none 17722 of the tests are nonzero expressions. 17723 17724 This is currently not valid for instruction patterns and is 17725 supported only for insn attributes. *Note Insn Attributes::. 17726 17727 17728File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL 17729 1773014.11 Bit-Fields 17731================ 17732 17733Special expression codes exist to represent bit-field instructions. 17734 17735'(sign_extract:M LOC SIZE POS)' 17736 This represents a reference to a sign-extended bit-field contained 17737 or starting in LOC (a memory or register reference). The bit-field 17738 is SIZE bits wide and starts at bit POS. The compilation option 17739 'BITS_BIG_ENDIAN' says which end of the memory unit POS counts 17740 from. 17741 17742 If LOC is in memory, its mode must be a single-byte integer mode. 17743 If LOC is in a register, the mode to use is specified by the 17744 operand of the 'insv' or 'extv' pattern (*note Standard Names::) 17745 and is usually a full-word integer mode, which is the default if 17746 none is specified. 17747 17748 The mode of POS is machine-specific and is also specified in the 17749 'insv' or 'extv' pattern. 17750 17751 The mode M is the same as the mode that would be used for LOC if it 17752 were a register. 17753 17754 A 'sign_extract' cannot appear as an lvalue, or part thereof, in 17755 RTL. 17756 17757'(zero_extract:M LOC SIZE POS)' 17758 Like 'sign_extract' but refers to an unsigned or zero-extended 17759 bit-field. The same sequence of bits are extracted, but they are 17760 filled to an entire word with zeros instead of by sign-extension. 17761 17762 Unlike 'sign_extract', this type of expressions can be lvalues in 17763 RTL; they may appear on the left side of an assignment, indicating 17764 insertion of a value into the specified bit-field. 17765 17766 17767File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL 17768 1776914.12 Vector Operations 17770======================= 17771 17772All normal RTL expressions can be used with vector modes; they are 17773interpreted as operating on each part of the vector independently. 17774Additionally, there are a few new expressions to describe specific 17775vector operations. 17776 17777'(vec_merge:M VEC1 VEC2 ITEMS)' 17778 This describes a merge operation between two vectors. The result 17779 is a vector of mode M; its elements are selected from either VEC1 17780 or VEC2. Which elements are selected is described by ITEMS, which 17781 is a bit mask represented by a 'const_int'; a zero bit indicates 17782 the corresponding element in the result vector is taken from VEC2 17783 while a set bit indicates it is taken from VEC1. 17784 17785'(vec_select:M VEC1 SELECTION)' 17786 This describes an operation that selects parts of a vector. VEC1 17787 is the source vector, and SELECTION is a 'parallel' that contains a 17788 'const_int' (or another expression, if the selection can be made at 17789 runtime) for each of the subparts of the result vector, giving the 17790 number of the source subpart that should be stored into it. The 17791 result mode M is either the submode for a single element of VEC1 17792 (if only one subpart is selected), or another vector mode with that 17793 element submode (if multiple subparts are selected). 17794 17795'(vec_concat:M X1 X2)' 17796 Describes a vector concat operation. The result is a concatenation 17797 of the vectors or scalars X1 and X2; its length is the sum of the 17798 lengths of the two inputs. 17799 17800'(vec_duplicate:M X)' 17801 This operation converts a scalar into a vector or a small vector 17802 into a larger one by duplicating the input values. The output 17803 vector mode must have the same submodes as the input vector mode or 17804 the scalar modes, and the number of output parts must be an integer 17805 multiple of the number of input parts. 17806 17807'(vec_series:M BASE STEP)' 17808 This operation creates a vector in which element I is equal to 17809 'BASE + I*STEP'. M must be a vector integer mode. 17810 17811 17812File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL 17813 1781414.13 Conversions 17815================= 17816 17817All conversions between machine modes must be represented by explicit 17818conversion operations. For example, an expression which is the sum of a 17819byte and a full word cannot be written as '(plus:SI (reg:QI 34) (reg:SI 1782080))' because the 'plus' operation requires two operands of the same 17821machine mode. Therefore, the byte-sized operand is enclosed in a 17822conversion operation, as in 17823 17824 (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) 17825 17826 The conversion operation is not a mere placeholder, because there may 17827be more than one way of converting from a given starting mode to the 17828desired final mode. The conversion operation code says how to do it. 17829 17830 For all conversion operations, X must not be 'VOIDmode' because the 17831mode in which to do the conversion would not be known. The conversion 17832must either be done at compile-time or X must be placed into a register. 17833 17834'(sign_extend:M X)' 17835 Represents the result of sign-extending the value X to machine mode 17836 M. M must be a fixed-point mode and X a fixed-point value of a 17837 mode narrower than M. 17838 17839'(zero_extend:M X)' 17840 Represents the result of zero-extending the value X to machine mode 17841 M. M must be a fixed-point mode and X a fixed-point value of a 17842 mode narrower than M. 17843 17844'(float_extend:M X)' 17845 Represents the result of extending the value X to machine mode M. 17846 M must be a floating point mode and X a floating point value of a 17847 mode narrower than M. 17848 17849'(truncate:M X)' 17850 Represents the result of truncating the value X to machine mode M. 17851 M must be a fixed-point mode and X a fixed-point value of a mode 17852 wider than M. 17853 17854'(ss_truncate:M X)' 17855 Represents the result of truncating the value X to machine mode M, 17856 using signed saturation in the case of overflow. Both M and the 17857 mode of X must be fixed-point modes. 17858 17859'(us_truncate:M X)' 17860 Represents the result of truncating the value X to machine mode M, 17861 using unsigned saturation in the case of overflow. Both M and the 17862 mode of X must be fixed-point modes. 17863 17864'(float_truncate:M X)' 17865 Represents the result of truncating the value X to machine mode M. 17866 M must be a floating point mode and X a floating point value of a 17867 mode wider than M. 17868 17869'(float:M X)' 17870 Represents the result of converting fixed point value X, regarded 17871 as signed, to floating point mode M. 17872 17873'(unsigned_float:M X)' 17874 Represents the result of converting fixed point value X, regarded 17875 as unsigned, to floating point mode M. 17876 17877'(fix:M X)' 17878 When M is a floating-point mode, represents the result of 17879 converting floating point value X (valid for mode M) to an integer, 17880 still represented in floating point mode M, by rounding towards 17881 zero. 17882 17883 When M is a fixed-point mode, represents the result of converting 17884 floating point value X to mode M, regarded as signed. How rounding 17885 is done is not specified, so this operation may be used validly in 17886 compiling C code only for integer-valued operands. 17887 17888'(unsigned_fix:M X)' 17889 Represents the result of converting floating point value X to fixed 17890 point mode M, regarded as unsigned. How rounding is done is not 17891 specified. 17892 17893'(fract_convert:M X)' 17894 Represents the result of converting fixed-point value X to 17895 fixed-point mode M, signed integer value X to fixed-point mode M, 17896 floating-point value X to fixed-point mode M, fixed-point value X 17897 to integer mode M regarded as signed, or fixed-point value X to 17898 floating-point mode M. When overflows or underflows happen, the 17899 results are undefined. 17900 17901'(sat_fract:M X)' 17902 Represents the result of converting fixed-point value X to 17903 fixed-point mode M, signed integer value X to fixed-point mode M, 17904 or floating-point value X to fixed-point mode M. When overflows or 17905 underflows happen, the results are saturated to the maximum or the 17906 minimum. 17907 17908'(unsigned_fract_convert:M X)' 17909 Represents the result of converting fixed-point value X to integer 17910 mode M regarded as unsigned, or unsigned integer value X to 17911 fixed-point mode M. When overflows or underflows happen, the 17912 results are undefined. 17913 17914'(unsigned_sat_fract:M X)' 17915 Represents the result of converting unsigned integer value X to 17916 fixed-point mode M. When overflows or underflows happen, the 17917 results are saturated to the maximum or the minimum. 17918 17919 17920File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL 17921 1792214.14 Declarations 17923================== 17924 17925Declaration expression codes do not represent arithmetic operations but 17926rather state assertions about their operands. 17927 17928'(strict_low_part (subreg:M (reg:N R) 0))' 17929 This expression code is used in only one context: as the 17930 destination operand of a 'set' expression. In addition, the 17931 operand of this expression must be a non-paradoxical 'subreg' 17932 expression. 17933 17934 The presence of 'strict_low_part' says that the part of the 17935 register which is meaningful in mode N, but is not part of mode M, 17936 is not to be altered. Normally, an assignment to such a subreg is 17937 allowed to have undefined effects on the rest of the register when 17938 M is smaller than 'REGMODE_NATURAL_SIZE (N)'. 17939 17940 17941File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL 17942 1794314.15 Side Effect Expressions 17944============================= 17945 17946The expression codes described so far represent values, not actions. 17947But machine instructions never produce values; they are meaningful only 17948for their side effects on the state of the machine. Special expression 17949codes are used to represent side effects. 17950 17951 The body of an instruction is always one of these side effect codes; 17952the codes described above, which represent values, appear only as the 17953operands of these. 17954 17955'(set LVAL X)' 17956 Represents the action of storing the value of X into the place 17957 represented by LVAL. LVAL must be an expression representing a 17958 place that can be stored in: 'reg' (or 'subreg', 'strict_low_part' 17959 or 'zero_extract'), 'mem', 'pc', 'parallel', or 'cc0'. 17960 17961 If LVAL is a 'reg', 'subreg' or 'mem', it has a machine mode; then 17962 X must be valid for that mode. 17963 17964 If LVAL is a 'reg' whose machine mode is less than the full width 17965 of the register, then it means that the part of the register 17966 specified by the machine mode is given the specified value and the 17967 rest of the register receives an undefined value. Likewise, if 17968 LVAL is a 'subreg' whose machine mode is narrower than the mode of 17969 the register, the rest of the register can be changed in an 17970 undefined way. 17971 17972 If LVAL is a 'strict_low_part' of a subreg, then the part of the 17973 register specified by the machine mode of the 'subreg' is given the 17974 value X and the rest of the register is not changed. 17975 17976 If LVAL is a 'zero_extract', then the referenced part of the 17977 bit-field (a memory or register reference) specified by the 17978 'zero_extract' is given the value X and the rest of the bit-field 17979 is not changed. Note that 'sign_extract' cannot appear in LVAL. 17980 17981 If LVAL is '(cc0)', it has no machine mode, and X may be either a 17982 'compare' expression or a value that may have any mode. The latter 17983 case represents a "test" instruction. The expression '(set (cc0) 17984 (reg:M N))' is equivalent to '(set (cc0) (compare (reg:M N) 17985 (const_int 0)))'. Use the former expression to save space during 17986 the compilation. 17987 17988 If LVAL is a 'parallel', it is used to represent the case of a 17989 function returning a structure in multiple registers. Each element 17990 of the 'parallel' is an 'expr_list' whose first operand is a 'reg' 17991 and whose second operand is a 'const_int' representing the offset 17992 (in bytes) into the structure at which the data in that register 17993 corresponds. The first element may be null to indicate that the 17994 structure is also passed partly in memory. 17995 17996 If LVAL is '(pc)', we have a jump instruction, and the 17997 possibilities for X are very limited. It may be a 'label_ref' 17998 expression (unconditional jump). It may be an 'if_then_else' 17999 (conditional jump), in which case either the second or the third 18000 operand must be '(pc)' (for the case which does not jump) and the 18001 other of the two must be a 'label_ref' (for the case which does 18002 jump). X may also be a 'mem' or '(plus:SI (pc) Y)', where Y may be 18003 a 'reg' or a 'mem'; these unusual patterns are used to represent 18004 jumps through branch tables. 18005 18006 If LVAL is neither '(cc0)' nor '(pc)', the mode of LVAL must not be 18007 'VOIDmode' and the mode of X must be valid for the mode of LVAL. 18008 18009 LVAL is customarily accessed with the 'SET_DEST' macro and X with 18010 the 'SET_SRC' macro. 18011 18012'(return)' 18013 As the sole expression in a pattern, represents a return from the 18014 current function, on machines where this can be done with one 18015 instruction, such as VAXen. On machines where a multi-instruction 18016 "epilogue" must be executed in order to return from the function, 18017 returning is done by jumping to a label which precedes the 18018 epilogue, and the 'return' expression code is never used. 18019 18020 Inside an 'if_then_else' expression, represents the value to be 18021 placed in 'pc' to return to the caller. 18022 18023 Note that an insn pattern of '(return)' is logically equivalent to 18024 '(set (pc) (return))', but the latter form is never used. 18025 18026'(simple_return)' 18027 Like '(return)', but truly represents only a function return, while 18028 '(return)' may represent an insn that also performs other functions 18029 of the function epilogue. Like '(return)', this may also occur in 18030 conditional jumps. 18031 18032'(call FUNCTION NARGS)' 18033 Represents a function call. FUNCTION is a 'mem' expression whose 18034 address is the address of the function to be called. NARGS is an 18035 expression which can be used for two purposes: on some machines it 18036 represents the number of bytes of stack argument; on others, it 18037 represents the number of argument registers. 18038 18039 Each machine has a standard machine mode which FUNCTION must have. 18040 The machine description defines macro 'FUNCTION_MODE' to expand 18041 into the requisite mode name. The purpose of this mode is to 18042 specify what kind of addressing is allowed, on machines where the 18043 allowed kinds of addressing depend on the machine mode being 18044 addressed. 18045 18046'(clobber X)' 18047 Represents the storing or possible storing of an unpredictable, 18048 undescribed value into X, which must be a 'reg', 'scratch', 18049 'parallel' or 'mem' expression. 18050 18051 One place this is used is in string instructions that store 18052 standard values into particular hard registers. It may not be 18053 worth the trouble to describe the values that are stored, but it is 18054 essential to inform the compiler that the registers will be 18055 altered, lest it attempt to keep data in them across the string 18056 instruction. 18057 18058 If X is '(mem:BLK (const_int 0))' or '(mem:BLK (scratch))', it 18059 means that all memory locations must be presumed clobbered. If X 18060 is a 'parallel', it has the same meaning as a 'parallel' in a 'set' 18061 expression. 18062 18063 Note that the machine description classifies certain hard registers 18064 as "call-clobbered". All function call instructions are assumed by 18065 default to clobber these registers, so there is no need to use 18066 'clobber' expressions to indicate this fact. Also, each function 18067 call is assumed to have the potential to alter any memory location, 18068 unless the function is declared 'const'. 18069 18070 If the last group of expressions in a 'parallel' are each a 18071 'clobber' expression whose arguments are 'reg' or 'match_scratch' 18072 (*note RTL Template::) expressions, the combiner phase can add the 18073 appropriate 'clobber' expressions to an insn it has constructed 18074 when doing so will cause a pattern to be matched. 18075 18076 This feature can be used, for example, on a machine that whose 18077 multiply and add instructions don't use an MQ register but which 18078 has an add-accumulate instruction that does clobber the MQ 18079 register. Similarly, a combined instruction might require a 18080 temporary register while the constituent instructions might not. 18081 18082 When a 'clobber' expression for a register appears inside a 18083 'parallel' with other side effects, the register allocator 18084 guarantees that the register is unoccupied both before and after 18085 that insn if it is a hard register clobber. For pseudo-register 18086 clobber, the register allocator and the reload pass do not assign 18087 the same hard register to the clobber and the input operands if 18088 there is an insn alternative containing the '&' constraint (*note 18089 Modifiers::) for the clobber and the hard register is in register 18090 classes of the clobber in the alternative. You can clobber either 18091 a specific hard register, a pseudo register, or a 'scratch' 18092 expression; in the latter two cases, GCC will allocate a hard 18093 register that is available there for use as a temporary. 18094 18095 For instructions that require a temporary register, you should use 18096 'scratch' instead of a pseudo-register because this will allow the 18097 combiner phase to add the 'clobber' when required. You do this by 18098 coding ('clobber' ('match_scratch' ...)). If you do clobber a 18099 pseudo register, use one which appears nowhere else--generate a new 18100 one each time. Otherwise, you may confuse CSE. 18101 18102 There is one other known use for clobbering a pseudo register in a 18103 'parallel': when one of the input operands of the insn is also 18104 clobbered by the insn. In this case, using the same pseudo 18105 register in the clobber and elsewhere in the insn produces the 18106 expected results. 18107 18108'(clobber_high X)' 18109 Represents the storing or possible storing of an unpredictable, 18110 undescribed value into the upper parts of X. The mode of the 18111 expression represents the lower parts of the register which will 18112 not be overwritten. 'reg' must be a reg expression. 18113 18114 One place this is used is when calling into functions where the 18115 registers are preserved, but only up to a given number of bits. 18116 For example when using Aarch64 SVE, calling a TLS descriptor will 18117 cause only the lower 128 bits of each of the vector registers to be 18118 preserved. 18119 18120'(use X)' 18121 Represents the use of the value of X. It indicates that the value 18122 in X at this point in the program is needed, even though it may not 18123 be apparent why this is so. Therefore, the compiler will not 18124 attempt to delete previous instructions whose only effect is to 18125 store a value in X. X must be a 'reg' expression. 18126 18127 In some situations, it may be tempting to add a 'use' of a register 18128 in a 'parallel' to describe a situation where the value of a 18129 special register will modify the behavior of the instruction. A 18130 hypothetical example might be a pattern for an addition that can 18131 either wrap around or use saturating addition depending on the 18132 value of a special control register: 18133 18134 (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3) 18135 (reg:SI 4)] 0)) 18136 (use (reg:SI 1))]) 18137 18138 18139 This will not work, several of the optimizers only look at 18140 expressions locally; it is very likely that if you have multiple 18141 insns with identical inputs to the 'unspec', they will be optimized 18142 away even if register 1 changes in between. 18143 18144 This means that 'use' can _only_ be used to describe that the 18145 register is live. You should think twice before adding 'use' 18146 statements, more often you will want to use 'unspec' instead. The 18147 'use' RTX is most commonly useful to describe that a fixed register 18148 is implicitly used in an insn. It is also safe to use in patterns 18149 where the compiler knows for other reasons that the result of the 18150 whole pattern is variable, such as 'movmemM' or 'call' patterns. 18151 18152 During the reload phase, an insn that has a 'use' as pattern can 18153 carry a reg_equal note. These 'use' insns will be deleted before 18154 the reload phase exits. 18155 18156 During the delayed branch scheduling phase, X may be an insn. This 18157 indicates that X previously was located at this place in the code 18158 and its data dependencies need to be taken into account. These 18159 'use' insns will be deleted before the delayed branch scheduling 18160 phase exits. 18161 18162'(parallel [X0 X1 ...])' 18163 Represents several side effects performed in parallel. The square 18164 brackets stand for a vector; the operand of 'parallel' is a vector 18165 of expressions. X0, X1 and so on are individual side effect 18166 expressions--expressions of code 'set', 'call', 'return', 18167 'simple_return', 'clobber' 'use' or 'clobber_high'. 18168 18169 "In parallel" means that first all the values used in the 18170 individual side-effects are computed, and second all the actual 18171 side-effects are performed. For example, 18172 18173 (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) 18174 (set (mem:SI (reg:SI 1)) (reg:SI 1))]) 18175 18176 says unambiguously that the values of hard register 1 and the 18177 memory location addressed by it are interchanged. In both places 18178 where '(reg:SI 1)' appears as a memory address it refers to the 18179 value in register 1 _before_ the execution of the insn. 18180 18181 It follows that it is _incorrect_ to use 'parallel' and expect the 18182 result of one 'set' to be available for the next one. For example, 18183 people sometimes attempt to represent a jump-if-zero instruction 18184 this way: 18185 18186 (parallel [(set (cc0) (reg:SI 34)) 18187 (set (pc) (if_then_else 18188 (eq (cc0) (const_int 0)) 18189 (label_ref ...) 18190 (pc)))]) 18191 18192 But this is incorrect, because it says that the jump condition 18193 depends on the condition code value _before_ this instruction, not 18194 on the new value that is set by this instruction. 18195 18196 Peephole optimization, which takes place together with final 18197 assembly code output, can produce insns whose patterns consist of a 18198 'parallel' whose elements are the operands needed to output the 18199 resulting assembler code--often 'reg', 'mem' or constant 18200 expressions. This would not be well-formed RTL at any other stage 18201 in compilation, but it is OK then because no further optimization 18202 remains to be done. However, the definition of the macro 18203 'NOTICE_UPDATE_CC', if any, must deal with such insns if you define 18204 any peephole optimizations. 18205 18206'(cond_exec [COND EXPR])' 18207 Represents a conditionally executed expression. The EXPR is 18208 executed only if the COND is nonzero. The COND expression must not 18209 have side-effects, but the EXPR may very well have side-effects. 18210 18211'(sequence [INSNS ...])' 18212 Represents a sequence of insns. If a 'sequence' appears in the 18213 chain of insns, then each of the INSNS that appears in the sequence 18214 must be suitable for appearing in the chain of insns, i.e. must 18215 satisfy the 'INSN_P' predicate. 18216 18217 After delay-slot scheduling is completed, an insn and all the insns 18218 that reside in its delay slots are grouped together into a 18219 'sequence'. The insn requiring the delay slot is the first insn in 18220 the vector; subsequent insns are to be placed in the delay slot. 18221 18222 'INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to 18223 indicate that a branch insn should be used that will conditionally 18224 annul the effect of the insns in the delay slots. In such a case, 18225 'INSN_FROM_TARGET_P' indicates that the insn is from the target of 18226 the branch and should be executed only if the branch is taken; 18227 otherwise the insn should be executed only if the branch is not 18228 taken. *Note Delay Slots::. 18229 18230 Some back ends also use 'sequence' objects for purposes other than 18231 delay-slot groups. This is not supported in the common parts of 18232 the compiler, which treat such sequences as delay-slot groups. 18233 18234 DWARF2 Call Frame Address (CFA) adjustments are sometimes also 18235 expressed using 'sequence' objects as the value of a 18236 'RTX_FRAME_RELATED_P' note. This only happens if the CFA 18237 adjustments cannot be easily derived from the pattern of the 18238 instruction to which the note is attached. In such cases, the 18239 value of the note is used instead of best-guesing the semantics of 18240 the instruction. The back end can attach notes containing a 18241 'sequence' of 'set' patterns that express the effect of the parent 18242 instruction. 18243 18244 These expression codes appear in place of a side effect, as the body of 18245an insn, though strictly speaking they do not always describe side 18246effects as such: 18247 18248'(asm_input S)' 18249 Represents literal assembler code as described by the string S. 18250 18251'(unspec [OPERANDS ...] INDEX)' 18252'(unspec_volatile [OPERANDS ...] INDEX)' 18253 Represents a machine-specific operation on OPERANDS. INDEX selects 18254 between multiple machine-specific operations. 'unspec_volatile' is 18255 used for volatile operations and operations that may trap; 'unspec' 18256 is used for other operations. 18257 18258 These codes may appear inside a 'pattern' of an insn, inside a 18259 'parallel', or inside an expression. 18260 18261'(addr_vec:M [LR0 LR1 ...])' 18262 Represents a table of jump addresses. The vector elements LR0, 18263 etc., are 'label_ref' expressions. The mode M specifies how much 18264 space is given to each address; normally M would be 'Pmode'. 18265 18266'(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)' 18267 Represents a table of jump addresses expressed as offsets from 18268 BASE. The vector elements LR0, etc., are 'label_ref' expressions 18269 and so is BASE. The mode M specifies how much space is given to 18270 each address-difference. MIN and MAX are set up by branch 18271 shortening and hold a label with a minimum and a maximum address, 18272 respectively. FLAGS indicates the relative position of BASE, MIN 18273 and MAX to the containing insn and of MIN and MAX to BASE. See 18274 rtl.def for details. 18275 18276'(prefetch:M ADDR RW LOCALITY)' 18277 Represents prefetch of memory at address ADDR. Operand RW is 1 if 18278 the prefetch is for data to be written, 0 otherwise; targets that 18279 do not support write prefetches should treat this as a normal 18280 prefetch. Operand LOCALITY specifies the amount of temporal 18281 locality; 0 if there is none or 1, 2, or 3 for increasing levels of 18282 temporal locality; targets that do not support locality hints 18283 should ignore this. 18284 18285 This insn is used to minimize cache-miss latency by moving data 18286 into a cache before it is accessed. It should use only 18287 non-faulting data prefetch instructions. 18288 18289 18290File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL 18291 1829214.16 Embedded Side-Effects on Addresses 18293======================================== 18294 18295Six special side-effect expression codes appear as memory addresses. 18296 18297'(pre_dec:M X)' 18298 Represents the side effect of decrementing X by a standard amount 18299 and represents also the value that X has after being decremented. 18300 X must be a 'reg' or 'mem', but most machines allow only a 'reg'. 18301 M must be the machine mode for pointers on the machine in use. The 18302 amount X is decremented by is the length in bytes of the machine 18303 mode of the containing memory reference of which this expression 18304 serves as the address. Here is an example of its use: 18305 18306 (mem:DF (pre_dec:SI (reg:SI 39))) 18307 18308 This says to decrement pseudo register 39 by the length of a 18309 'DFmode' value and use the result to address a 'DFmode' value. 18310 18311'(pre_inc:M X)' 18312 Similar, but specifies incrementing X instead of decrementing it. 18313 18314'(post_dec:M X)' 18315 Represents the same side effect as 'pre_dec' but a different value. 18316 The value represented here is the value X has before being 18317 decremented. 18318 18319'(post_inc:M X)' 18320 Similar, but specifies incrementing X instead of decrementing it. 18321 18322'(post_modify:M X Y)' 18323 18324 Represents the side effect of setting X to Y and represents X 18325 before X is modified. X must be a 'reg' or 'mem', but most 18326 machines allow only a 'reg'. M must be the machine mode for 18327 pointers on the machine in use. 18328 18329 The expression Y must be one of three forms: '(plus:M X Z)', 18330 '(minus:M X Z)', or '(plus:M X I)', where Z is an index register 18331 and I is a constant. 18332 18333 Here is an example of its use: 18334 18335 (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42) 18336 (reg:SI 48)))) 18337 18338 This says to modify pseudo register 42 by adding the contents of 18339 pseudo register 48 to it, after the use of what ever 42 points to. 18340 18341'(pre_modify:M X EXPR)' 18342 Similar except side effects happen before the use. 18343 18344 These embedded side effect expressions must be used with care. 18345Instruction patterns may not use them. Until the 'flow' pass of the 18346compiler, they may occur only to represent pushes onto the stack. The 18347'flow' pass finds cases where registers are incremented or decremented 18348in one instruction and used as an address shortly before or after; these 18349cases are then transformed to use pre- or post-increment or -decrement. 18350 18351 If a register used as the operand of these expressions is used in 18352another address in an insn, the original value of the register is used. 18353Uses of the register outside of an address are not permitted within the 18354same insn as a use in an embedded side effect expression because such 18355insns behave differently on different machines and hence must be treated 18356as ambiguous and disallowed. 18357 18358 An instruction that can be represented with an embedded side effect 18359could also be represented using 'parallel' containing an additional 18360'set' to describe how the address register is altered. This is not done 18361because machines that allow these operations at all typically allow them 18362wherever a memory address is called for. Describing them as additional 18363parallel stores would require doubling the number of entries in the 18364machine description. 18365 18366 18367File: gccint.info, Node: Assembler, Next: Debug Information, Prev: Incdec, Up: RTL 18368 1836914.17 Assembler Instructions as Expressions 18370=========================================== 18371 18372The RTX code 'asm_operands' represents a value produced by a 18373user-specified assembler instruction. It is used to represent an 'asm' 18374statement with arguments. An 'asm' statement with a single output 18375operand, like this: 18376 18377 asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); 18378 18379is represented using a single 'asm_operands' RTX which represents the 18380value that is stored in 'outputvar': 18381 18382 (set RTX-FOR-OUTPUTVAR 18383 (asm_operands "foo %1,%2,%0" "a" 0 18384 [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] 18385 [(asm_input:M1 "g") 18386 (asm_input:M2 "di")])) 18387 18388Here the operands of the 'asm_operands' RTX are the assembler template 18389string, the output-operand's constraint, the index-number of the output 18390operand among the output operands specified, a vector of input operand 18391RTX's, and a vector of input-operand modes and constraints. The mode M1 18392is the mode of the sum 'x+y'; M2 is that of '*z'. 18393 18394 When an 'asm' statement has multiple output values, its insn has 18395several such 'set' RTX's inside of a 'parallel'. Each 'set' contains an 18396'asm_operands'; all of these share the same assembler template and 18397vectors, but each contains the constraint for the respective output 18398operand. They are also distinguished by the output-operand index 18399number, which is 0, 1, ... for successive output operands. 18400 18401 18402File: gccint.info, Node: Debug Information, Next: Insns, Prev: Assembler, Up: RTL 18403 1840414.18 Variable Location Debug Information in RTL 18405================================================ 18406 18407Variable tracking relies on 'MEM_EXPR' and 'REG_EXPR' annotations to 18408determine what user variables memory and register references refer to. 18409 18410 Variable tracking at assignments uses these notes only when they refer 18411to variables that live at fixed locations (e.g., addressable variables, 18412global non-automatic variables). For variables whose location may vary, 18413it relies on the following types of notes. 18414 18415'(var_location:MODE VAR EXP STAT)' 18416 Binds variable 'var', a tree, to value EXP, an RTL expression. It 18417 appears only in 'NOTE_INSN_VAR_LOCATION' and 'DEBUG_INSN's, with 18418 slightly different meanings. MODE, if present, represents the mode 18419 of EXP, which is useful if it is a modeless expression. STAT is 18420 only meaningful in notes, indicating whether the variable is known 18421 to be initialized or uninitialized. 18422 18423'(debug_expr:MODE DECL)' 18424 Stands for the value bound to the 'DEBUG_EXPR_DECL' DECL, that 18425 points back to it, within value expressions in 'VAR_LOCATION' 18426 nodes. 18427 18428'(debug_implicit_ptr:MODE DECL)' 18429 Stands for the location of a DECL that is no longer addressable. 18430 18431'(entry_value:MODE DECL)' 18432 Stands for the value a DECL had at the entry point of the 18433 containing function. 18434 18435'(debug_parameter_ref:MODE DECL)' 18436 Refers to a parameter that was completely optimized out. 18437 18438'(debug_marker:MODE)' 18439 Marks a program location. With 'VOIDmode', it stands for the 18440 beginning of a statement, a recommended inspection point logically 18441 after all prior side effects, and before any subsequent side 18442 effects. With 'BLKmode', it indicates an inline entry point: the 18443 lexical block encoded in the 'INSN_LOCATION' is the enclosing block 18444 that encloses the inlined function. 18445 18446 18447File: gccint.info, Node: Insns, Next: Calls, Prev: Debug Information, Up: RTL 18448 1844914.19 Insns 18450=========== 18451 18452The RTL representation of the code for a function is a doubly-linked 18453chain of objects called "insns". Insns are expressions with special 18454codes that are used for no other purpose. Some insns are actual 18455instructions; others represent dispatch tables for 'switch' statements; 18456others represent labels to jump to or various sorts of declarative 18457information. 18458 18459 In addition to its own specific data, each insn must have a unique 18460id-number that distinguishes it from all other insns in the current 18461function (after delayed branch scheduling, copies of an insn with the 18462same id-number may be present in multiple places in a function, but 18463these copies will always be identical and will only appear inside a 18464'sequence'), and chain pointers to the preceding and following insns. 18465These three fields occupy the same position in every insn, independent 18466of the expression code of the insn. They could be accessed with 'XEXP' 18467and 'XINT', but instead three special macros are always used: 18468 18469'INSN_UID (I)' 18470 Accesses the unique id of insn I. 18471 18472'PREV_INSN (I)' 18473 Accesses the chain pointer to the insn preceding I. If I is the 18474 first insn, this is a null pointer. 18475 18476'NEXT_INSN (I)' 18477 Accesses the chain pointer to the insn following I. If I is the 18478 last insn, this is a null pointer. 18479 18480 The first insn in the chain is obtained by calling 'get_insns'; the 18481last insn is the result of calling 'get_last_insn'. Within the chain 18482delimited by these insns, the 'NEXT_INSN' and 'PREV_INSN' pointers must 18483always correspond: if INSN is not the first insn, 18484 18485 NEXT_INSN (PREV_INSN (INSN)) == INSN 18486 18487is always true and if INSN is not the last insn, 18488 18489 PREV_INSN (NEXT_INSN (INSN)) == INSN 18490 18491is always true. 18492 18493 After delay slot scheduling, some of the insns in the chain might be 18494'sequence' expressions, which contain a vector of insns. The value of 18495'NEXT_INSN' in all but the last of these insns is the next insn in the 18496vector; the value of 'NEXT_INSN' of the last insn in the vector is the 18497same as the value of 'NEXT_INSN' for the 'sequence' in which it is 18498contained. Similar rules apply for 'PREV_INSN'. 18499 18500 This means that the above invariants are not necessarily true for insns 18501inside 'sequence' expressions. Specifically, if INSN is the first insn 18502in a 'sequence', 'NEXT_INSN (PREV_INSN (INSN))' is the insn containing 18503the 'sequence' expression, as is the value of 'PREV_INSN (NEXT_INSN 18504(INSN))' if INSN is the last insn in the 'sequence' expression. You can 18505use these expressions to find the containing 'sequence' expression. 18506 18507 Every insn has one of the following expression codes: 18508 18509'insn' 18510 The expression code 'insn' is used for instructions that do not 18511 jump and do not do function calls. 'sequence' expressions are 18512 always contained in insns with code 'insn' even if one of those 18513 insns should jump or do function calls. 18514 18515 Insns with code 'insn' have four additional fields beyond the three 18516 mandatory ones listed above. These four are described in a table 18517 below. 18518 18519'jump_insn' 18520 The expression code 'jump_insn' is used for instructions that may 18521 jump (or, more generally, may contain 'label_ref' expressions to 18522 which 'pc' can be set in that instruction). If there is an 18523 instruction to return from the current function, it is recorded as 18524 a 'jump_insn'. 18525 18526 'jump_insn' insns have the same extra fields as 'insn' insns, 18527 accessed in the same way and in addition contain a field 18528 'JUMP_LABEL' which is defined once jump optimization has completed. 18529 18530 For simple conditional and unconditional jumps, this field contains 18531 the 'code_label' to which this insn will (possibly conditionally) 18532 branch. In a more complex jump, 'JUMP_LABEL' records one of the 18533 labels that the insn refers to; other jump target labels are 18534 recorded as 'REG_LABEL_TARGET' notes. The exception is 'addr_vec' 18535 and 'addr_diff_vec', where 'JUMP_LABEL' is 'NULL_RTX' and the only 18536 way to find the labels is to scan the entire body of the insn. 18537 18538 Return insns count as jumps, but their 'JUMP_LABEL' is 'RETURN' or 18539 'SIMPLE_RETURN'. 18540 18541'call_insn' 18542 The expression code 'call_insn' is used for instructions that may 18543 do function calls. It is important to distinguish these 18544 instructions because they imply that certain registers and memory 18545 locations may be altered unpredictably. 18546 18547 'call_insn' insns have the same extra fields as 'insn' insns, 18548 accessed in the same way and in addition contain a field 18549 'CALL_INSN_FUNCTION_USAGE', which contains a list (chain of 18550 'expr_list' expressions) containing 'use', 'clobber' and sometimes 18551 'set' expressions that denote hard registers and 'mem's used or 18552 clobbered by the called function. 18553 18554 A 'mem' generally points to a stack slot in which arguments passed 18555 to the libcall by reference (*note TARGET_PASS_BY_REFERENCE: 18556 Register Arguments.) are stored. If the argument is caller-copied 18557 (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot 18558 will be mentioned in 'clobber' and 'use' entries; if it's 18559 callee-copied, only a 'use' will appear, and the 'mem' may point to 18560 addresses that are not stack slots. 18561 18562 Registers occurring inside a 'clobber' in this list augment 18563 registers specified in 'CALL_USED_REGISTERS' (*note Register 18564 Basics::). 18565 18566 If the list contains a 'set' involving two registers, it indicates 18567 that the function returns one of its arguments. Such a 'set' may 18568 look like a no-op if the same register holds the argument and the 18569 return value. 18570 18571'code_label' 18572 A 'code_label' insn represents a label that a jump insn can jump 18573 to. It contains two special fields of data in addition to the 18574 three standard ones. 'CODE_LABEL_NUMBER' is used to hold the 18575 "label number", a number that identifies this label uniquely among 18576 all the labels in the compilation (not just in the current 18577 function). Ultimately, the label is represented in the assembler 18578 output as an assembler label, usually of the form 'LN' where N is 18579 the label number. 18580 18581 When a 'code_label' appears in an RTL expression, it normally 18582 appears within a 'label_ref' which represents the address of the 18583 label, as a number. 18584 18585 Besides as a 'code_label', a label can also be represented as a 18586 'note' of type 'NOTE_INSN_DELETED_LABEL'. 18587 18588 The field 'LABEL_NUSES' is only defined once the jump optimization 18589 phase is completed. It contains the number of times this label is 18590 referenced in the current function. 18591 18592 The field 'LABEL_KIND' differentiates four different types of 18593 labels: 'LABEL_NORMAL', 'LABEL_STATIC_ENTRY', 'LABEL_GLOBAL_ENTRY', 18594 and 'LABEL_WEAK_ENTRY'. The only labels that do not have type 18595 'LABEL_NORMAL' are "alternate entry points" to the current 18596 function. These may be static (visible only in the containing 18597 translation unit), global (exposed to all translation units), or 18598 weak (global, but can be overridden by another symbol with the same 18599 name). 18600 18601 Much of the compiler treats all four kinds of label identically. 18602 Some of it needs to know whether or not a label is an alternate 18603 entry point; for this purpose, the macro 'LABEL_ALT_ENTRY_P' is 18604 provided. It is equivalent to testing whether 'LABEL_KIND (label) 18605 == LABEL_NORMAL'. The only place that cares about the distinction 18606 between static, global, and weak alternate entry points, besides 18607 the front-end code that creates them, is the function 18608 'output_alternate_entry_point', in 'final.c'. 18609 18610 To set the kind of a label, use the 'SET_LABEL_KIND' macro. 18611 18612'jump_table_data' 18613 A 'jump_table_data' insn is a placeholder for the jump-table data 18614 of a 'casesi' or 'tablejump' insn. They are placed after a 18615 'tablejump_p' insn. A 'jump_table_data' insn is not part o a basic 18616 blockm but it is associated with the basic block that ends with the 18617 'tablejump_p' insn. The 'PATTERN' of a 'jump_table_data' is always 18618 either an 'addr_vec' or an 'addr_diff_vec', and a 'jump_table_data' 18619 insn is always preceded by a 'code_label'. The 'tablejump_p' insn 18620 refers to that 'code_label' via its 'JUMP_LABEL'. 18621 18622'barrier' 18623 Barriers are placed in the instruction stream when control cannot 18624 flow past them. They are placed after unconditional jump 18625 instructions to indicate that the jumps are unconditional and after 18626 calls to 'volatile' functions, which do not return (e.g., 'exit'). 18627 They contain no information beyond the three standard fields. 18628 18629'note' 18630 'note' insns are used to represent additional debugging and 18631 declarative information. They contain two nonstandard fields, an 18632 integer which is accessed with the macro 'NOTE_LINE_NUMBER' and a 18633 string accessed with 'NOTE_SOURCE_FILE'. 18634 18635 If 'NOTE_LINE_NUMBER' is positive, the note represents the position 18636 of a source line and 'NOTE_SOURCE_FILE' is the source file name 18637 that the line came from. These notes control generation of line 18638 number data in the assembler output. 18639 18640 Otherwise, 'NOTE_LINE_NUMBER' is not really a line number but a 18641 code with one of the following values (and 'NOTE_SOURCE_FILE' must 18642 contain a null pointer): 18643 18644 'NOTE_INSN_DELETED' 18645 Such a note is completely ignorable. Some passes of the 18646 compiler delete insns by altering them into notes of this 18647 kind. 18648 18649 'NOTE_INSN_DELETED_LABEL' 18650 This marks what used to be a 'code_label', but was not used 18651 for other purposes than taking its address and was transformed 18652 to mark that no code jumps to it. 18653 18654 'NOTE_INSN_BLOCK_BEG' 18655 'NOTE_INSN_BLOCK_END' 18656 These types of notes indicate the position of the beginning 18657 and end of a level of scoping of variable names. They control 18658 the output of debugging information. 18659 18660 'NOTE_INSN_EH_REGION_BEG' 18661 'NOTE_INSN_EH_REGION_END' 18662 These types of notes indicate the position of the beginning 18663 and end of a level of scoping for exception handling. 18664 'NOTE_EH_HANDLER' identifies which region is associated with 18665 these notes. 18666 18667 'NOTE_INSN_FUNCTION_BEG' 18668 Appears at the start of the function body, after the function 18669 prologue. 18670 18671 'NOTE_INSN_VAR_LOCATION' 18672 This note is used to generate variable location debugging 18673 information. It indicates that the user variable in its 18674 'VAR_LOCATION' operand is at the location given in the RTL 18675 expression, or holds a value that can be computed by 18676 evaluating the RTL expression from that static point in the 18677 program up to the next such note for the same user variable. 18678 18679 'NOTE_INSN_BEGIN_STMT' 18680 This note is used to generate 'is_stmt' markers in line number 18681 debuggign information. It indicates the beginning of a user 18682 statement. 18683 18684 'NOTE_INSN_INLINE_ENTRY' 18685 This note is used to generate 'entry_pc' for inlined 18686 subroutines in debugging information. It indicates an 18687 inspection point at which all arguments for the inlined 18688 function have been bound, and before its first statement. 18689 18690 These codes are printed symbolically when they appear in debugging 18691 dumps. 18692 18693'debug_insn' 18694 The expression code 'debug_insn' is used for pseudo-instructions 18695 that hold debugging information for variable tracking at 18696 assignments (see '-fvar-tracking-assignments' option). They are 18697 the RTL representation of 'GIMPLE_DEBUG' statements (*note 18698 GIMPLE_DEBUG::), with a 'VAR_LOCATION' operand that binds a user 18699 variable tree to an RTL representation of the 'value' in the 18700 corresponding statement. A 'DEBUG_EXPR' in it stands for the value 18701 bound to the corresponding 'DEBUG_EXPR_DECL'. 18702 18703 'GIMPLE_DEBUG_BEGIN_STMT' and 'GIMPLE_DEBUG_INLINE_ENTRY' are 18704 expanded to RTL as a 'DEBUG_INSN' with a 'DEBUG_MARKER' 'PATTERN'; 18705 the difference is the RTL mode: the former's 'DEBUG_MARKER' is 18706 'VOIDmode', whereas the latter is 'BLKmode'; information about the 18707 inlined function can be taken from the lexical block encoded in the 18708 'INSN_LOCATION'. These 'DEBUG_INSN's, that do not carry 18709 'VAR_LOCATION' information, just 'DEBUG_MARKER's, can be detected 18710 by testing 'DEBUG_MARKER_INSN_P', whereas those that do can be 18711 recognized as 'DEBUG_BIND_INSN_P'. 18712 18713 Throughout optimization passes, 'DEBUG_INSN's are not reordered 18714 with respect to each other, particularly during scheduling. 18715 Binding information is kept in pseudo-instruction form, so that, 18716 unlike notes, it gets the same treatment and adjustments that 18717 regular instructions would. It is the variable tracking pass that 18718 turns these pseudo-instructions into 'NOTE_INSN_VAR_LOCATION', 18719 'NOTE_INSN_BEGIN_STMT' and 'NOTE_INSN_INLINE_ENTRY' notes, 18720 analyzing control flow, value equivalences and changes to registers 18721 and memory referenced in value expressions, propagating the values 18722 of debug temporaries and determining expressions that can be used 18723 to compute the value of each user variable at as many points 18724 (ranges, actually) in the program as possible. 18725 18726 Unlike 'NOTE_INSN_VAR_LOCATION', the value expression in an 18727 'INSN_VAR_LOCATION' denotes a value at that specific point in the 18728 program, rather than an expression that can be evaluated at any 18729 later point before an overriding 'VAR_LOCATION' is encountered. 18730 E.g., if a user variable is bound to a 'REG' and then a subsequent 18731 insn modifies the 'REG', the note location would keep mapping the 18732 user variable to the register across the insn, whereas the insn 18733 location would keep the variable bound to the value, so that the 18734 variable tracking pass would emit another location note for the 18735 variable at the point in which the register is modified. 18736 18737 The machine mode of an insn is normally 'VOIDmode', but some phases use 18738the mode for various purposes. 18739 18740 The common subexpression elimination pass sets the mode of an insn to 18741'QImode' when it is the first insn in a block that has already been 18742processed. 18743 18744 The second Haifa scheduling pass, for targets that can multiple issue, 18745sets the mode of an insn to 'TImode' when it is believed that the 18746instruction begins an issue group. That is, when the instruction cannot 18747issue simultaneously with the previous. This may be relied on by later 18748passes, in particular machine-dependent reorg. 18749 18750 Here is a table of the extra fields of 'insn', 'jump_insn' and 18751'call_insn' insns: 18752 18753'PATTERN (I)' 18754 An expression for the side effect performed by this insn. This 18755 must be one of the following codes: 'set', 'call', 'use', 18756 'clobber', 'return', 'simple_return', 'asm_input', 'asm_output', 18757 'addr_vec', 'addr_diff_vec', 'trap_if', 'unspec', 18758 'unspec_volatile', 'parallel', 'cond_exec', or 'sequence'. If it 18759 is a 'parallel', each element of the 'parallel' must be one these 18760 codes, except that 'parallel' expressions cannot be nested and 18761 'addr_vec' and 'addr_diff_vec' are not permitted inside a 18762 'parallel' expression. 18763 18764'INSN_CODE (I)' 18765 An integer that says which pattern in the machine description 18766 matches this insn, or -1 if the matching has not yet been 18767 attempted. 18768 18769 Such matching is never attempted and this field remains -1 on an 18770 insn whose pattern consists of a single 'use', 'clobber', 18771 'asm_input', 'addr_vec' or 'addr_diff_vec' expression. 18772 18773 Matching is also never attempted on insns that result from an 'asm' 18774 statement. These contain at least one 'asm_operands' expression. 18775 The function 'asm_noperands' returns a non-negative value for such 18776 insns. 18777 18778 In the debugging output, this field is printed as a number followed 18779 by a symbolic representation that locates the pattern in the 'md' 18780 file as some small positive or negative offset from a named 18781 pattern. 18782 18783'LOG_LINKS (I)' 18784 A list (chain of 'insn_list' expressions) giving information about 18785 dependencies between instructions within a basic block. Neither a 18786 jump nor a label may come between the related insns. These are 18787 only used by the schedulers and by combine. This is a deprecated 18788 data structure. Def-use and use-def chains are now preferred. 18789 18790'REG_NOTES (I)' 18791 A list (chain of 'expr_list', 'insn_list' and 'int_list' 18792 expressions) giving miscellaneous information about the insn. It 18793 is often information pertaining to the registers used in this insn. 18794 18795 The 'LOG_LINKS' field of an insn is a chain of 'insn_list' expressions. 18796Each of these has two operands: the first is an insn, and the second is 18797another 'insn_list' expression (the next one in the chain). The last 18798'insn_list' in the chain has a null pointer as second operand. The 18799significant thing about the chain is which insns appear in it (as first 18800operands of 'insn_list' expressions). Their order is not significant. 18801 18802 This list is originally set up by the flow analysis pass; it is a null 18803pointer until then. Flow only adds links for those data dependencies 18804which can be used for instruction combination. For each insn, the flow 18805analysis pass adds a link to insns which store into registers values 18806that are used for the first time in this insn. 18807 18808 The 'REG_NOTES' field of an insn is a chain similar to the 'LOG_LINKS' 18809field but it includes 'expr_list' and 'int_list' expressions in addition 18810to 'insn_list' expressions. There are several kinds of register notes, 18811which are distinguished by the machine mode, which in a register note is 18812really understood as being an 'enum reg_note'. The first operand OP of 18813the note is data whose meaning depends on the kind of note. 18814 18815 The macro 'REG_NOTE_KIND (X)' returns the kind of register note. Its 18816counterpart, the macro 'PUT_REG_NOTE_KIND (X, NEWKIND)' sets the 18817register note type of X to be NEWKIND. 18818 18819 Register notes are of three classes: They may say something about an 18820input to an insn, they may say something about an output of an insn, or 18821they may create a linkage between two insns. There are also a set of 18822values that are only used in 'LOG_LINKS'. 18823 18824 These register notes annotate inputs to an insn: 18825 18826'REG_DEAD' 18827 The value in OP dies in this insn; that is to say, altering the 18828 value immediately after this insn would not affect the future 18829 behavior of the program. 18830 18831 It does not follow that the register OP has no useful value after 18832 this insn since OP is not necessarily modified by this insn. 18833 Rather, no subsequent instruction uses the contents of OP. 18834 18835'REG_UNUSED' 18836 The register OP being set by this insn will not be used in a 18837 subsequent insn. This differs from a 'REG_DEAD' note, which 18838 indicates that the value in an input will not be used subsequently. 18839 These two notes are independent; both may be present for the same 18840 register. 18841 18842'REG_INC' 18843 The register OP is incremented (or decremented; at this level there 18844 is no distinction) by an embedded side effect inside this insn. 18845 This means it appears in a 'post_inc', 'pre_inc', 'post_dec' or 18846 'pre_dec' expression. 18847 18848'REG_NONNEG' 18849 The register OP is known to have a nonnegative value when this insn 18850 is reached. This is used by special looping instructions that 18851 terminate when the register goes negative. 18852 18853 The 'REG_NONNEG' note is added only to 'doloop_end' insns, if its 18854 pattern uses a 'ge' condition. 18855 18856'REG_LABEL_OPERAND' 18857 This insn uses OP, a 'code_label' or a 'note' of type 18858 'NOTE_INSN_DELETED_LABEL', but is not a 'jump_insn', or it is a 18859 'jump_insn' that refers to the operand as an ordinary operand. The 18860 label may still eventually be a jump target, but if so in an 18861 indirect jump in a subsequent insn. The presence of this note 18862 allows jump optimization to be aware that OP is, in fact, being 18863 used, and flow optimization to build an accurate flow graph. 18864 18865'REG_LABEL_TARGET' 18866 This insn is a 'jump_insn' but not an 'addr_vec' or 18867 'addr_diff_vec'. It uses OP, a 'code_label' as a direct or 18868 indirect jump target. Its purpose is similar to that of 18869 'REG_LABEL_OPERAND'. This note is only present if the insn has 18870 multiple targets; the last label in the insn (in the highest 18871 numbered insn-field) goes into the 'JUMP_LABEL' field and does not 18872 have a 'REG_LABEL_TARGET' note. *Note JUMP_LABEL: Insns. 18873 18874'REG_SETJMP' 18875 Appears attached to each 'CALL_INSN' to 'setjmp' or a related 18876 function. 18877 18878 The following notes describe attributes of outputs of an insn: 18879 18880'REG_EQUIV' 18881'REG_EQUAL' 18882 This note is only valid on an insn that sets only one register and 18883 indicates that that register will be equal to OP at run time; the 18884 scope of this equivalence differs between the two types of notes. 18885 The value which the insn explicitly copies into the register may 18886 look different from OP, but they will be equal at run time. If the 18887 output of the single 'set' is a 'strict_low_part' or 'zero_extract' 18888 expression, the note refers to the register that is contained in 18889 its first operand. 18890 18891 For 'REG_EQUIV', the register is equivalent to OP throughout the 18892 entire function, and could validly be replaced in all its 18893 occurrences by OP. ("Validly" here refers to the data flow of the 18894 program; simple replacement may make some insns invalid.) For 18895 example, when a constant is loaded into a register that is never 18896 assigned any other value, this kind of note is used. 18897 18898 When a parameter is copied into a pseudo-register at entry to a 18899 function, a note of this kind records that the register is 18900 equivalent to the stack slot where the parameter was passed. 18901 Although in this case the register may be set by other insns, it is 18902 still valid to replace the register by the stack slot throughout 18903 the function. 18904 18905 A 'REG_EQUIV' note is also used on an instruction which copies a 18906 register parameter into a pseudo-register at entry to a function, 18907 if there is a stack slot where that parameter could be stored. 18908 Although other insns may set the pseudo-register, it is valid for 18909 the compiler to replace the pseudo-register by stack slot 18910 throughout the function, provided the compiler ensures that the 18911 stack slot is properly initialized by making the replacement in the 18912 initial copy instruction as well. This is used on machines for 18913 which the calling convention allocates stack space for register 18914 parameters. See 'REG_PARM_STACK_SPACE' in *note Stack Arguments::. 18915 18916 In the case of 'REG_EQUAL', the register that is set by this insn 18917 will be equal to OP at run time at the end of this insn but not 18918 necessarily elsewhere in the function. In this case, OP is 18919 typically an arithmetic expression. For example, when a sequence 18920 of insns such as a library call is used to perform an arithmetic 18921 operation, this kind of note is attached to the insn that produces 18922 or copies the final value. 18923 18924 These two notes are used in different ways by the compiler passes. 18925 'REG_EQUAL' is used by passes prior to register allocation (such as 18926 common subexpression elimination and loop optimization) to tell 18927 them how to think of that value. 'REG_EQUIV' notes are used by 18928 register allocation to indicate that there is an available 18929 substitute expression (either a constant or a 'mem' expression for 18930 the location of a parameter on the stack) that may be used in place 18931 of a register if insufficient registers are available. 18932 18933 Except for stack homes for parameters, which are indicated by a 18934 'REG_EQUIV' note and are not useful to the early optimization 18935 passes and pseudo registers that are equivalent to a memory 18936 location throughout their entire life, which is not detected until 18937 later in the compilation, all equivalences are initially indicated 18938 by an attached 'REG_EQUAL' note. In the early stages of register 18939 allocation, a 'REG_EQUAL' note is changed into a 'REG_EQUIV' note 18940 if OP is a constant and the insn represents the only set of its 18941 destination register. 18942 18943 Thus, compiler passes prior to register allocation need only check 18944 for 'REG_EQUAL' notes and passes subsequent to register allocation 18945 need only check for 'REG_EQUIV' notes. 18946 18947 These notes describe linkages between insns. They occur in pairs: one 18948insn has one of a pair of notes that points to a second insn, which has 18949the inverse note pointing back to the first insn. 18950 18951'REG_CC_SETTER' 18952'REG_CC_USER' 18953 On machines that use 'cc0', the insns which set and use 'cc0' set 18954 and use 'cc0' are adjacent. However, when branch delay slot 18955 filling is done, this may no longer be true. In this case a 18956 'REG_CC_USER' note will be placed on the insn setting 'cc0' to 18957 point to the insn using 'cc0' and a 'REG_CC_SETTER' note will be 18958 placed on the insn using 'cc0' to point to the insn setting 'cc0'. 18959 18960 These values are only used in the 'LOG_LINKS' field, and indicate the 18961type of dependency that each link represents. Links which indicate a 18962data dependence (a read after write dependence) do not use any code, 18963they simply have mode 'VOIDmode', and are printed without any 18964descriptive text. 18965 18966'REG_DEP_TRUE' 18967 This indicates a true dependence (a read after write dependence). 18968 18969'REG_DEP_OUTPUT' 18970 This indicates an output dependence (a write after write 18971 dependence). 18972 18973'REG_DEP_ANTI' 18974 This indicates an anti dependence (a write after read dependence). 18975 18976 These notes describe information gathered from gcov profile data. They 18977are stored in the 'REG_NOTES' field of an insn. 18978 18979'REG_BR_PROB' 18980 This is used to specify the ratio of branches to non-branches of a 18981 branch insn according to the profile data. The note is represented 18982 as an 'int_list' expression whose integer value is an encoding of 18983 'profile_probability' type. 'profile_probability' provide member 18984 function 'from_reg_br_prob_note' and 'to_reg_br_prob_note' to 18985 extract and store the probability into the RTL encoding. 18986 18987'REG_BR_PRED' 18988 These notes are found in JUMP insns after delayed branch scheduling 18989 has taken place. They indicate both the direction and the 18990 likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_* 18991 values. 18992 18993'REG_FRAME_RELATED_EXPR' 18994 This is used on an RTX_FRAME_RELATED_P insn wherein the attached 18995 expression is used in place of the actual insn pattern. This is 18996 done in cases where the pattern is either complex or misleading. 18997 18998 The note 'REG_CALL_NOCF_CHECK' is used in conjunction with the 18999'-fcf-protection=branch' option. The note is set if a 'nocf_check' 19000attribute is specified for a function type or a pointer to function 19001type. The note is stored in the 'REG_NOTES' field of an insn. 19002 19003'REG_CALL_NOCF_CHECK' 19004 Users have control through the 'nocf_check' attribute to identify 19005 which calls to a function should be skipped from control-flow 19006 instrumentation when the option '-fcf-protection=branch' is 19007 specified. The compiler puts a 'REG_CALL_NOCF_CHECK' note on each 19008 'CALL_INSN' instruction that has a function type marked with a 19009 'nocf_check' attribute. 19010 19011 For convenience, the machine mode in an 'insn_list' or 'expr_list' is 19012printed using these symbolic codes in debugging dumps. 19013 19014 The only difference between the expression codes 'insn_list' and 19015'expr_list' is that the first operand of an 'insn_list' is assumed to be 19016an insn and is printed in debugging dumps as the insn's unique id; the 19017first operand of an 'expr_list' is printed in the ordinary way as an 19018expression. 19019 19020 19021File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL 19022 1902314.20 RTL Representation of Function-Call Insns 19024=============================================== 19025 19026Insns that call subroutines have the RTL expression code 'call_insn'. 19027These insns must satisfy special rules, and their bodies must use a 19028special RTL expression code, 'call'. 19029 19030 A 'call' expression has two operands, as follows: 19031 19032 (call (mem:FM ADDR) NBYTES) 19033 19034Here NBYTES is an operand that represents the number of bytes of 19035argument data being passed to the subroutine, FM is a machine mode 19036(which must equal as the definition of the 'FUNCTION_MODE' macro in the 19037machine description) and ADDR represents the address of the subroutine. 19038 19039 For a subroutine that returns no value, the 'call' expression as shown 19040above is the entire body of the insn, except that the insn might also 19041contain 'use' or 'clobber' expressions. 19042 19043 For a subroutine that returns a value whose mode is not 'BLKmode', the 19044value is returned in a hard register. If this register's number is R, 19045then the body of the call insn looks like this: 19046 19047 (set (reg:M R) 19048 (call (mem:FM ADDR) NBYTES)) 19049 19050This RTL expression makes it clear (to the optimizer passes) that the 19051appropriate register receives a useful value in this insn. 19052 19053 When a subroutine returns a 'BLKmode' value, it is handled by passing 19054to the subroutine the address of a place to store the value. So the 19055call insn itself does not "return" any value, and it has the same RTL 19056form as a call that returns nothing. 19057 19058 On some machines, the call instruction itself clobbers some register, 19059for example to contain the return address. 'call_insn' insns on these 19060machines should have a body which is a 'parallel' that contains both the 19061'call' expression and 'clobber' expressions that indicate which 19062registers are destroyed. Similarly, if the call instruction requires 19063some register other than the stack pointer that is not explicitly 19064mentioned in its RTL, a 'use' subexpression should mention that 19065register. 19066 19067 Functions that are called are assumed to modify all registers listed in 19068the configuration macro 'CALL_USED_REGISTERS' (*note Register Basics::) 19069and, with the exception of 'const' functions and library calls, to 19070modify all of memory. 19071 19072 Insns containing just 'use' expressions directly precede the 19073'call_insn' insn to indicate which registers contain inputs to the 19074function. Similarly, if registers other than those in 19075'CALL_USED_REGISTERS' are clobbered by the called function, insns 19076containing a single 'clobber' follow immediately after the call to 19077indicate which registers. 19078 19079 19080File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL 19081 1908214.21 Structure Sharing Assumptions 19083=================================== 19084 19085The compiler assumes that certain kinds of RTL expressions are unique; 19086there do not exist two distinct objects representing the same value. In 19087other cases, it makes an opposite assumption: that no RTL expression 19088object of a certain kind appears in more than one place in the 19089containing structure. 19090 19091 These assumptions refer to a single function; except for the RTL 19092objects that describe global variables and external functions, and a few 19093standard objects such as small integer constants, no RTL objects are 19094common to two functions. 19095 19096 * Each pseudo-register has only a single 'reg' object to represent 19097 it, and therefore only a single machine mode. 19098 19099 * For any symbolic label, there is only one 'symbol_ref' object 19100 referring to it. 19101 19102 * All 'const_int' expressions with equal values are shared. 19103 19104 * All 'const_poly_int' expressions with equal modes and values are 19105 shared. 19106 19107 * There is only one 'pc' expression. 19108 19109 * There is only one 'cc0' expression. 19110 19111 * There is only one 'const_double' expression with value 0 for each 19112 floating point mode. Likewise for values 1 and 2. 19113 19114 * There is only one 'const_vector' expression with value 0 for each 19115 vector mode, be it an integer or a double constant vector. 19116 19117 * No 'label_ref' or 'scratch' appears in more than one place in the 19118 RTL structure; in other words, it is safe to do a tree-walk of all 19119 the insns in the function and assume that each time a 'label_ref' 19120 or 'scratch' is seen it is distinct from all others that are seen. 19121 19122 * Only one 'mem' object is normally created for each static variable 19123 or stack slot, so these objects are frequently shared in all the 19124 places they appear. However, separate but equal objects for these 19125 variables are occasionally made. 19126 19127 * When a single 'asm' statement has multiple output operands, a 19128 distinct 'asm_operands' expression is made for each output operand. 19129 However, these all share the vector which contains the sequence of 19130 input operands. This sharing is used later on to test whether two 19131 'asm_operands' expressions come from the same statement, so all 19132 optimizations must carefully preserve the sharing if they copy the 19133 vector at all. 19134 19135 * No RTL object appears in more than one place in the RTL structure 19136 except as described above. Many passes of the compiler rely on 19137 this by assuming that they can modify RTL objects in place without 19138 unwanted side-effects on other insns. 19139 19140 * During initial RTL generation, shared structure is freely 19141 introduced. After all the RTL for a function has been generated, 19142 all shared structure is copied by 'unshare_all_rtl' in 19143 'emit-rtl.c', after which the above rules are guaranteed to be 19144 followed. 19145 19146 * During the combiner pass, shared structure within an insn can exist 19147 temporarily. However, the shared structure is copied before the 19148 combiner is finished with the insn. This is done by calling 19149 'copy_rtx_if_shared', which is a subroutine of 'unshare_all_rtl'. 19150 19151 19152File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL 19153 1915414.22 Reading RTL 19155================= 19156 19157To read an RTL object from a file, call 'read_rtx'. It takes one 19158argument, a stdio stream, and returns a single RTL object. This routine 19159is defined in 'read-rtl.c'. It is not available in the compiler itself, 19160only the various programs that generate the compiler back end from the 19161machine description. 19162 19163 People frequently have the idea of using RTL stored as text in a file 19164as an interface between a language front end and the bulk of GCC. This 19165idea is not feasible. 19166 19167 GCC was designed to use RTL internally only. Correct RTL for a given 19168program is very dependent on the particular target machine. And the RTL 19169does not contain all the information about the program. 19170 19171 The proper way to interface GCC to a new language front end is with the 19172"tree" data structure, described in the files 'tree.h' and 'tree.def'. 19173The documentation for this structure (*note GENERIC::) is incomplete. 19174 19175 19176File: gccint.info, Node: Control Flow, Next: Loop Analysis and Representation, Prev: RTL, Up: Top 19177 1917815 Control Flow Graph 19179********************* 19180 19181A control flow graph (CFG) is a data structure built on top of the 19182intermediate code representation (the RTL or 'GIMPLE' instruction 19183stream) abstracting the control flow behavior of a function that is 19184being compiled. The CFG is a directed graph where the vertices 19185represent basic blocks and edges represent possible transfer of control 19186flow from one basic block to another. The data structures used to 19187represent the control flow graph are defined in 'basic-block.h'. 19188 19189 In GCC, the representation of control flow is maintained throughout the 19190compilation process, from constructing the CFG early in 'pass_build_cfg' 19191to 'pass_free_cfg' (see 'passes.def'). The CFG takes various different 19192modes and may undergo extensive manipulations, but the graph is always 19193valid between its construction and its release. This way, transfer of 19194information such as data flow, a measured profile, or the loop tree, can 19195be propagated through the passes pipeline, and even from 'GIMPLE' to 19196'RTL'. 19197 19198 Often the CFG may be better viewed as integral part of instruction 19199chain, than structure built on the top of it. Updating the compiler's 19200intermediate representation for instructions cannot be easily done 19201without proper maintenance of the CFG simultaneously. 19202 19203* Menu: 19204 19205* Basic Blocks:: The definition and representation of basic blocks. 19206* Edges:: Types of edges and their representation. 19207* Profile information:: Representation of frequencies and probabilities. 19208* Maintaining the CFG:: Keeping the control flow graph and up to date. 19209* Liveness information:: Using and maintaining liveness information. 19210 19211 19212File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow 19213 1921415.1 Basic Blocks 19215================= 19216 19217A basic block is a straight-line sequence of code with only one entry 19218point and only one exit. In GCC, basic blocks are represented using the 19219'basic_block' data type. 19220 19221 Special basic blocks represent possible entry and exit points of a 19222function. These blocks are called 'ENTRY_BLOCK_PTR' and 19223'EXIT_BLOCK_PTR'. These blocks do not contain any code. 19224 19225 The 'BASIC_BLOCK' array contains all basic blocks in an unspecified 19226order. Each 'basic_block' structure has a field that holds a unique 19227integer identifier 'index' that is the index of the block in the 19228'BASIC_BLOCK' array. The total number of basic blocks in the function 19229is 'n_basic_blocks'. Both the basic block indices and the total number 19230of basic blocks may vary during the compilation process, as passes 19231reorder, create, duplicate, and destroy basic blocks. The index for any 19232block should never be greater than 'last_basic_block'. The indices 0 19233and 1 are special codes reserved for 'ENTRY_BLOCK' and 'EXIT_BLOCK', the 19234indices of 'ENTRY_BLOCK_PTR' and 'EXIT_BLOCK_PTR'. 19235 19236 Two pointer members of the 'basic_block' structure are the pointers 19237'next_bb' and 'prev_bb'. These are used to keep doubly linked chain of 19238basic blocks in the same order as the underlying instruction stream. 19239The chain of basic blocks is updated transparently by the provided API 19240for manipulating the CFG. The macro 'FOR_EACH_BB' can be used to visit 19241all the basic blocks in lexicographical order, except 'ENTRY_BLOCK' and 19242'EXIT_BLOCK'. The macro 'FOR_ALL_BB' also visits all basic blocks in 19243lexicographical order, including 'ENTRY_BLOCK' and 'EXIT_BLOCK'. 19244 19245 The functions 'post_order_compute' and 'inverted_post_order_compute' 19246can be used to compute topological orders of the CFG. The orders are 19247stored as vectors of basic block indices. The 'BASIC_BLOCK' array can 19248be used to iterate each basic block by index. Dominator traversals are 19249also possible using 'walk_dominator_tree'. Given two basic blocks A and 19250B, block A dominates block B if A is _always_ executed before B. 19251 19252 Each 'basic_block' also contains pointers to the first instruction (the 19253"head") and the last instruction (the "tail") or "end" of the 19254instruction stream contained in a basic block. In fact, since the 19255'basic_block' data type is used to represent blocks in both major 19256intermediate representations of GCC ('GIMPLE' and RTL), there are 19257pointers to the head and end of a basic block for both representations, 19258stored in intermediate representation specific data in the 'il' field of 19259'struct basic_block_def'. 19260 19261 For RTL, these pointers are 'BB_HEAD' and 'BB_END'. 19262 19263 In the RTL representation of a function, the instruction stream 19264contains not only the "real" instructions, but also "notes" or "insn 19265notes" (to distinguish them from "reg notes"). Any function that moves 19266or duplicates the basic blocks needs to take care of updating of these 19267notes. Many of these notes expect that the instruction stream consists 19268of linear regions, so updating can sometimes be tedious. All types of 19269insn notes are defined in 'insn-notes.def'. 19270 19271 In the RTL function representation, the instructions contained in a 19272basic block always follow a 'NOTE_INSN_BASIC_BLOCK', but zero or more 19273'CODE_LABEL' nodes can precede the block note. A basic block ends with 19274a control flow instruction or with the last instruction before the next 19275'CODE_LABEL' or 'NOTE_INSN_BASIC_BLOCK'. By definition, a 'CODE_LABEL' 19276cannot appear in the middle of the instruction stream of a basic block. 19277 19278 In addition to notes, the jump table vectors are also represented as 19279"pseudo-instructions" inside the insn stream. These vectors never 19280appear in the basic block and should always be placed just after the 19281table jump instructions referencing them. After removing the table-jump 19282it is often difficult to eliminate the code computing the address and 19283referencing the vector, so cleaning up these vectors is postponed until 19284after liveness analysis. Thus the jump table vectors may appear in the 19285insn stream unreferenced and without any purpose. Before any edge is 19286made "fall-thru", the existence of such construct in the way needs to be 19287checked by calling 'can_fallthru' function. 19288 19289 For the 'GIMPLE' representation, the PHI nodes and statements contained 19290in a basic block are in a 'gimple_seq' pointed to by the basic block 19291intermediate language specific pointers. Abstract containers and 19292iterators are used to access the PHI nodes and statements in a basic 19293blocks. These iterators are called "GIMPLE statement iterators" (GSIs). 19294Grep for '^gsi' in the various 'gimple-*' and 'tree-*' files. There is 19295a 'gimple_stmt_iterator' type for iterating over all kinds of statement, 19296and a 'gphi_iterator' subclass for iterating over PHI nodes. The 19297following snippet will pretty-print all PHI nodes the statements of the 19298current function in the GIMPLE representation. 19299 19300 basic_block bb; 19301 19302 FOR_EACH_BB (bb) 19303 { 19304 gphi_iterator pi; 19305 gimple_stmt_iterator si; 19306 19307 for (pi = gsi_start_phis (bb); !gsi_end_p (pi); gsi_next (&pi)) 19308 { 19309 gphi *phi = pi.phi (); 19310 print_gimple_stmt (dump_file, phi, 0, TDF_SLIM); 19311 } 19312 for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si)) 19313 { 19314 gimple stmt = gsi_stmt (si); 19315 print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM); 19316 } 19317 } 19318 19319 19320File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow 19321 1932215.2 Edges 19323========== 19324 19325Edges represent possible control flow transfers from the end of some 19326basic block A to the head of another basic block B. We say that A is a 19327predecessor of B, and B is a successor of A. Edges are represented in 19328GCC with the 'edge' data type. Each 'edge' acts as a link between two 19329basic blocks: The 'src' member of an edge points to the predecessor 19330basic block of the 'dest' basic block. The members 'preds' and 'succs' 19331of the 'basic_block' data type point to type-safe vectors of edges to 19332the predecessors and successors of the block. 19333 19334 When walking the edges in an edge vector, "edge iterators" should be 19335used. Edge iterators are constructed using the 'edge_iterator' data 19336structure and several methods are available to operate on them: 19337 19338'ei_start' 19339 This function initializes an 'edge_iterator' that points to the 19340 first edge in a vector of edges. 19341 19342'ei_last' 19343 This function initializes an 'edge_iterator' that points to the 19344 last edge in a vector of edges. 19345 19346'ei_end_p' 19347 This predicate is 'true' if an 'edge_iterator' represents the last 19348 edge in an edge vector. 19349 19350'ei_one_before_end_p' 19351 This predicate is 'true' if an 'edge_iterator' represents the 19352 second last edge in an edge vector. 19353 19354'ei_next' 19355 This function takes a pointer to an 'edge_iterator' and makes it 19356 point to the next edge in the sequence. 19357 19358'ei_prev' 19359 This function takes a pointer to an 'edge_iterator' and makes it 19360 point to the previous edge in the sequence. 19361 19362'ei_edge' 19363 This function returns the 'edge' currently pointed to by an 19364 'edge_iterator'. 19365 19366'ei_safe_safe' 19367 This function returns the 'edge' currently pointed to by an 19368 'edge_iterator', but returns 'NULL' if the iterator is pointing at 19369 the end of the sequence. This function has been provided for 19370 existing code makes the assumption that a 'NULL' edge indicates the 19371 end of the sequence. 19372 19373 The convenience macro 'FOR_EACH_EDGE' can be used to visit all of the 19374edges in a sequence of predecessor or successor edges. It must not be 19375used when an element might be removed during the traversal, otherwise 19376elements will be missed. Here is an example of how to use the macro: 19377 19378 edge e; 19379 edge_iterator ei; 19380 19381 FOR_EACH_EDGE (e, ei, bb->succs) 19382 { 19383 if (e->flags & EDGE_FALLTHRU) 19384 break; 19385 } 19386 19387 There are various reasons why control flow may transfer from one block 19388to another. One possibility is that some instruction, for example a 19389'CODE_LABEL', in a linearized instruction stream just always starts a 19390new basic block. In this case a "fall-thru" edge links the basic block 19391to the first following basic block. But there are several other reasons 19392why edges may be created. The 'flags' field of the 'edge' data type is 19393used to store information about the type of edge we are dealing with. 19394Each edge is of one of the following types: 19395 19396_jump_ 19397 No type flags are set for edges corresponding to jump instructions. 19398 These edges are used for unconditional or conditional jumps and in 19399 RTL also for table jumps. They are the easiest to manipulate as 19400 they may be freely redirected when the flow graph is not in SSA 19401 form. 19402 19403_fall-thru_ 19404 Fall-thru edges are present in case where the basic block may 19405 continue execution to the following one without branching. These 19406 edges have the 'EDGE_FALLTHRU' flag set. Unlike other types of 19407 edges, these edges must come into the basic block immediately 19408 following in the instruction stream. The function 19409 'force_nonfallthru' is available to insert an unconditional jump in 19410 the case that redirection is needed. Note that this may require 19411 creation of a new basic block. 19412 19413_exception handling_ 19414 Exception handling edges represent possible control transfers from 19415 a trapping instruction to an exception handler. The definition of 19416 "trapping" varies. In C++, only function calls can throw, but for 19417 Ada exceptions like division by zero or segmentation fault are 19418 defined and thus each instruction possibly throwing this kind of 19419 exception needs to be handled as control flow instruction. 19420 Exception edges have the 'EDGE_ABNORMAL' and 'EDGE_EH' flags set. 19421 19422 When updating the instruction stream it is easy to change possibly 19423 trapping instruction to non-trapping, by simply removing the 19424 exception edge. The opposite conversion is difficult, but should 19425 not happen anyway. The edges can be eliminated via 19426 'purge_dead_edges' call. 19427 19428 In the RTL representation, the destination of an exception edge is 19429 specified by 'REG_EH_REGION' note attached to the insn. In case of 19430 a trapping call the 'EDGE_ABNORMAL_CALL' flag is set too. In the 19431 'GIMPLE' representation, this extra flag is not set. 19432 19433 In the RTL representation, the predicate 'may_trap_p' may be used 19434 to check whether instruction still may trap or not. For the tree 19435 representation, the 'tree_could_trap_p' predicate is available, but 19436 this predicate only checks for possible memory traps, as in 19437 dereferencing an invalid pointer location. 19438 19439_sibling calls_ 19440 Sibling calls or tail calls terminate the function in a 19441 non-standard way and thus an edge to the exit must be present. 19442 'EDGE_SIBCALL' and 'EDGE_ABNORMAL' are set in such case. These 19443 edges only exist in the RTL representation. 19444 19445_computed jumps_ 19446 Computed jumps contain edges to all labels in the function 19447 referenced from the code. All those edges have 'EDGE_ABNORMAL' 19448 flag set. The edges used to represent computed jumps often cause 19449 compile time performance problems, since functions consisting of 19450 many taken labels and many computed jumps may have _very_ dense 19451 flow graphs, so these edges need to be handled with special care. 19452 During the earlier stages of the compilation process, GCC tries to 19453 avoid such dense flow graphs by factoring computed jumps. For 19454 example, given the following series of jumps, 19455 19456 goto *x; 19457 [ ... ] 19458 19459 goto *x; 19460 [ ... ] 19461 19462 goto *x; 19463 [ ... ] 19464 19465 factoring the computed jumps results in the following code sequence 19466 which has a much simpler flow graph: 19467 19468 goto y; 19469 [ ... ] 19470 19471 goto y; 19472 [ ... ] 19473 19474 goto y; 19475 [ ... ] 19476 19477 y: 19478 goto *x; 19479 19480 However, the classic problem with this transformation is that it 19481 has a runtime cost in there resulting code: An extra jump. 19482 Therefore, the computed jumps are un-factored in the later passes 19483 of the compiler (in the pass called 19484 'pass_duplicate_computed_gotos'). Be aware of that when you work 19485 on passes in that area. There have been numerous examples already 19486 where the compile time for code with unfactored computed jumps 19487 caused some serious headaches. 19488 19489_nonlocal goto handlers_ 19490 GCC allows nested functions to return into caller using a 'goto' to 19491 a label passed to as an argument to the callee. The labels passed 19492 to nested functions contain special code to cleanup after function 19493 call. Such sections of code are referred to as "nonlocal goto 19494 receivers". If a function contains such nonlocal goto receivers, 19495 an edge from the call to the label is created with the 19496 'EDGE_ABNORMAL' and 'EDGE_ABNORMAL_CALL' flags set. 19497 19498_function entry points_ 19499 By definition, execution of function starts at basic block 0, so 19500 there is always an edge from the 'ENTRY_BLOCK_PTR' to basic block 19501 0. There is no 'GIMPLE' representation for alternate entry points 19502 at this moment. In RTL, alternate entry points are specified by 19503 'CODE_LABEL' with 'LABEL_ALTERNATE_NAME' defined. This feature is 19504 currently used for multiple entry point prologues and is limited to 19505 post-reload passes only. This can be used by back-ends to emit 19506 alternate prologues for functions called from different contexts. 19507 In future full support for multiple entry functions defined by 19508 Fortran 90 needs to be implemented. 19509 19510_function exits_ 19511 In the pre-reload representation a function terminates after the 19512 last instruction in the insn chain and no explicit return 19513 instructions are used. This corresponds to the fall-thru edge into 19514 exit block. After reload, optimal RTL epilogues are used that use 19515 explicit (conditional) return instructions that are represented by 19516 edges with no flags set. 19517 19518 19519File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow 19520 1952115.3 Profile information 19522======================== 19523 19524In many cases a compiler must make a choice whether to trade speed in 19525one part of code for speed in another, or to trade code size for code 19526speed. In such cases it is useful to know information about how often 19527some given block will be executed. That is the purpose for maintaining 19528profile within the flow graph. GCC can handle profile information 19529obtained through "profile feedback", but it can also estimate branch 19530probabilities based on statics and heuristics. 19531 19532 The feedback based profile is produced by compiling the program with 19533instrumentation, executing it on a train run and reading the numbers of 19534executions of basic blocks and edges back to the compiler while 19535re-compiling the program to produce the final executable. This method 19536provides very accurate information about where a program spends most of 19537its time on the train run. Whether it matches the average run of course 19538depends on the choice of train data set, but several studies have shown 19539that the behavior of a program usually changes just marginally over 19540different data sets. 19541 19542 When profile feedback is not available, the compiler may be asked to 19543attempt to predict the behavior of each branch in the program using a 19544set of heuristics (see 'predict.def' for details) and compute estimated 19545frequencies of each basic block by propagating the probabilities over 19546the graph. 19547 19548 Each 'basic_block' contains two integer fields to represent profile 19549information: 'frequency' and 'count'. The 'frequency' is an estimation 19550how often is basic block executed within a function. It is represented 19551as an integer scaled in the range from 0 to 'BB_FREQ_BASE'. The most 19552frequently executed basic block in function is initially set to 19553'BB_FREQ_BASE' and the rest of frequencies are scaled accordingly. 19554During optimization, the frequency of the most frequent basic block can 19555both decrease (for instance by loop unrolling) or grow (for instance by 19556cross-jumping optimization), so scaling sometimes has to be performed 19557multiple times. 19558 19559 The 'count' contains hard-counted numbers of execution measured during 19560training runs and is nonzero only when profile feedback is available. 19561This value is represented as the host's widest integer (typically a 64 19562bit integer) of the special type 'gcov_type'. 19563 19564 Most optimization passes can use only the frequency information of a 19565basic block, but a few passes may want to know hard execution counts. 19566The frequencies should always match the counts after scaling, however 19567during updating of the profile information numerical error may 19568accumulate into quite large errors. 19569 19570 Each edge also contains a branch probability field: an integer in the 19571range from 0 to 'REG_BR_PROB_BASE'. It represents probability of 19572passing control from the end of the 'src' basic block to the 'dest' 19573basic block, i.e. the probability that control will flow along this 19574edge. The 'EDGE_FREQUENCY' macro is available to compute how frequently 19575a given edge is taken. There is a 'count' field for each edge as well, 19576representing same information as for a basic block. 19577 19578 The basic block frequencies are not represented in the instruction 19579stream, but in the RTL representation the edge frequencies are 19580represented for conditional jumps (via the 'REG_BR_PROB' macro) since 19581they are used when instructions are output to the assembly file and the 19582flow graph is no longer maintained. 19583 19584 The probability that control flow arrives via a given edge to its 19585destination basic block is called "reverse probability" and is not 19586directly represented, but it may be easily computed from frequencies of 19587basic blocks. 19588 19589 Updating profile information is a delicate task that can unfortunately 19590not be easily integrated with the CFG manipulation API. Many of the 19591functions and hooks to modify the CFG, such as 19592'redirect_edge_and_branch', do not have enough information to easily 19593update the profile, so updating it is in the majority of cases left up 19594to the caller. It is difficult to uncover bugs in the profile updating 19595code, because they manifest themselves only by producing worse code, and 19596checking profile consistency is not possible because of numeric error 19597accumulation. Hence special attention needs to be given to this issue 19598in each pass that modifies the CFG. 19599 19600 It is important to point out that 'REG_BR_PROB_BASE' and 'BB_FREQ_BASE' 19601are both set low enough to be possible to compute second power of any 19602frequency or probability in the flow graph, it is not possible to even 19603square the 'count' field, as modern CPUs are fast enough to execute 19604$2^32$ operations quickly. 19605 19606 19607File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow 19608 1960915.4 Maintaining the CFG 19610======================== 19611 19612An important task of each compiler pass is to keep both the control flow 19613graph and all profile information up-to-date. Reconstruction of the 19614control flow graph after each pass is not an option, since it may be 19615very expensive and lost profile information cannot be reconstructed at 19616all. 19617 19618 GCC has two major intermediate representations, and both use the 19619'basic_block' and 'edge' data types to represent control flow. Both 19620representations share as much of the CFG maintenance code as possible. 19621For each representation, a set of "hooks" is defined so that each 19622representation can provide its own implementation of CFG manipulation 19623routines when necessary. These hooks are defined in 'cfghooks.h'. 19624There are hooks for almost all common CFG manipulations, including block 19625splitting and merging, edge redirection and creating and deleting basic 19626blocks. These hooks should provide everything you need to maintain and 19627manipulate the CFG in both the RTL and 'GIMPLE' representation. 19628 19629 At the moment, the basic block boundaries are maintained transparently 19630when modifying instructions, so there rarely is a need to move them 19631manually (such as in case someone wants to output instruction outside 19632basic block explicitly). 19633 19634 In the RTL representation, each instruction has a 'BLOCK_FOR_INSN' 19635value that represents pointer to the basic block that contains the 19636instruction. In the 'GIMPLE' representation, the function 'gimple_bb' 19637returns a pointer to the basic block containing the queried statement. 19638 19639 When changes need to be applied to a function in its 'GIMPLE' 19640representation, "GIMPLE statement iterators" should be used. These 19641iterators provide an integrated abstraction of the flow graph and the 19642instruction stream. Block statement iterators are constructed using the 19643'gimple_stmt_iterator' data structure and several modifiers are 19644available, including the following: 19645 19646'gsi_start' 19647 This function initializes a 'gimple_stmt_iterator' that points to 19648 the first non-empty statement in a basic block. 19649 19650'gsi_last' 19651 This function initializes a 'gimple_stmt_iterator' that points to 19652 the last statement in a basic block. 19653 19654'gsi_end_p' 19655 This predicate is 'true' if a 'gimple_stmt_iterator' represents the 19656 end of a basic block. 19657 19658'gsi_next' 19659 This function takes a 'gimple_stmt_iterator' and makes it point to 19660 its successor. 19661 19662'gsi_prev' 19663 This function takes a 'gimple_stmt_iterator' and makes it point to 19664 its predecessor. 19665 19666'gsi_insert_after' 19667 This function inserts a statement after the 'gimple_stmt_iterator' 19668 passed in. The final parameter determines whether the statement 19669 iterator is updated to point to the newly inserted statement, or 19670 left pointing to the original statement. 19671 19672'gsi_insert_before' 19673 This function inserts a statement before the 'gimple_stmt_iterator' 19674 passed in. The final parameter determines whether the statement 19675 iterator is updated to point to the newly inserted statement, or 19676 left pointing to the original statement. 19677 19678'gsi_remove' 19679 This function removes the 'gimple_stmt_iterator' passed in and 19680 rechains the remaining statements in a basic block, if any. 19681 19682 In the RTL representation, the macros 'BB_HEAD' and 'BB_END' may be 19683used to get the head and end 'rtx' of a basic block. No abstract 19684iterators are defined for traversing the insn chain, but you can just 19685use 'NEXT_INSN' and 'PREV_INSN' instead. *Note Insns::. 19686 19687 Usually a code manipulating pass simplifies the instruction stream and 19688the flow of control, possibly eliminating some edges. This may for 19689example happen when a conditional jump is replaced with an unconditional 19690jump. Updating of edges is not transparent and each optimization pass 19691is required to do so manually. However only few cases occur in 19692practice. The pass may call 'purge_dead_edges' on a given basic block 19693to remove superfluous edges, if any. 19694 19695 Another common scenario is redirection of branch instructions, but this 19696is best modeled as redirection of edges in the control flow graph and 19697thus use of 'redirect_edge_and_branch' is preferred over more low level 19698functions, such as 'redirect_jump' that operate on RTL chain only. The 19699CFG hooks defined in 'cfghooks.h' should provide the complete API 19700required for manipulating and maintaining the CFG. 19701 19702 It is also possible that a pass has to insert control flow instruction 19703into the middle of a basic block, thus creating an entry point in the 19704middle of the basic block, which is impossible by definition: The block 19705must be split to make sure it only has one entry point, i.e. the head of 19706the basic block. The CFG hook 'split_block' may be used when an 19707instruction in the middle of a basic block has to become the target of a 19708jump or branch instruction. 19709 19710 For a global optimizer, a common operation is to split edges in the 19711flow graph and insert instructions on them. In the RTL representation, 19712this can be easily done using the 'insert_insn_on_edge' function that 19713emits an instruction "on the edge", caching it for a later 19714'commit_edge_insertions' call that will take care of moving the inserted 19715instructions off the edge into the instruction stream contained in a 19716basic block. This includes the creation of new basic blocks where 19717needed. In the 'GIMPLE' representation, the equivalent functions are 19718'gsi_insert_on_edge' which inserts a block statement iterator on an 19719edge, and 'gsi_commit_edge_inserts' which flushes the instruction to 19720actual instruction stream. 19721 19722 While debugging the optimization pass, the 'verify_flow_info' function 19723may be useful to find bugs in the control flow graph updating code. 19724 19725 19726File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow 19727 1972815.5 Liveness information 19729========================= 19730 19731Liveness information is useful to determine whether some register is 19732"live" at given point of program, i.e. that it contains a value that may 19733be used at a later point in the program. This information is used, for 19734instance, during register allocation, as the pseudo registers only need 19735to be assigned to a unique hard register or to a stack slot if they are 19736live. The hard registers and stack slots may be freely reused for other 19737values when a register is dead. 19738 19739 Liveness information is available in the back end starting with 19740'pass_df_initialize' and ending with 'pass_df_finish'. Three flavors of 19741live analysis are available: With 'LR', it is possible to determine at 19742any point 'P' in the function if the register may be used on some path 19743from 'P' to the end of the function. With 'UR', it is possible to 19744determine if there is a path from the beginning of the function to 'P' 19745that defines the variable. 'LIVE' is the intersection of the 'LR' and 19746'UR' and a variable is live at 'P' if there is both an assignment that 19747reaches it from the beginning of the function and a use that can be 19748reached on some path from 'P' to the end of the function. 19749 19750 In general 'LIVE' is the most useful of the three. The macros 19751'DF_[LR,UR,LIVE]_[IN,OUT]' can be used to access this information. The 19752macros take a basic block number and return a bitmap that is indexed by 19753the register number. This information is only guaranteed to be up to 19754date after calls are made to 'df_analyze'. See the file 'df-core.c' for 19755details on using the dataflow. 19756 19757 The liveness information is stored partly in the RTL instruction stream 19758and partly in the flow graph. Local information is stored in the 19759instruction stream: Each instruction may contain 'REG_DEAD' notes 19760representing that the value of a given register is no longer needed, or 19761'REG_UNUSED' notes representing that the value computed by the 19762instruction is never used. The second is useful for instructions 19763computing multiple values at once. 19764 19765 19766File: gccint.info, Node: Loop Analysis and Representation, Next: Machine Desc, Prev: Control Flow, Up: Top 19767 1976816 Analysis and Representation of Loops 19769*************************************** 19770 19771GCC provides extensive infrastructure for work with natural loops, i.e., 19772strongly connected components of CFG with only one entry block. This 19773chapter describes representation of loops in GCC, both on GIMPLE and in 19774RTL, as well as the interfaces to loop-related analyses (induction 19775variable analysis and number of iterations analysis). 19776 19777* Menu: 19778 19779* Loop representation:: Representation and analysis of loops. 19780* Loop querying:: Getting information about loops. 19781* Loop manipulation:: Loop manipulation functions. 19782* LCSSA:: Loop-closed SSA form. 19783* Scalar evolutions:: Induction variables on GIMPLE. 19784* loop-iv:: Induction variables on RTL. 19785* Number of iterations:: Number of iterations analysis. 19786* Dependency analysis:: Data dependency analysis. 19787 19788 19789File: gccint.info, Node: Loop representation, Next: Loop querying, Up: Loop Analysis and Representation 19790 1979116.1 Loop representation 19792======================== 19793 19794This chapter describes the representation of loops in GCC, and functions 19795that can be used to build, modify and analyze this representation. Most 19796of the interfaces and data structures are declared in 'cfgloop.h'. Loop 19797structures are analyzed and this information disposed or updated at the 19798discretion of individual passes. Still most of the generic CFG 19799manipulation routines are aware of loop structures and try to keep them 19800up-to-date. By this means an increasing part of the compilation 19801pipeline is setup to maintain loop structure across passes to allow 19802attaching meta information to individual loops for consumption by later 19803passes. 19804 19805 In general, a natural loop has one entry block (header) and possibly 19806several back edges (latches) leading to the header from the inside of 19807the loop. Loops with several latches may appear if several loops share 19808a single header, or if there is a branching in the middle of the loop. 19809The representation of loops in GCC however allows only loops with a 19810single latch. During loop analysis, headers of such loops are split and 19811forwarder blocks are created in order to disambiguate their structures. 19812Heuristic based on profile information and structure of the induction 19813variables in the loops is used to determine whether the latches 19814correspond to sub-loops or to control flow in a single loop. This means 19815that the analysis sometimes changes the CFG, and if you run it in the 19816middle of an optimization pass, you must be able to deal with the new 19817blocks. You may avoid CFG changes by passing 19818'LOOPS_MAY_HAVE_MULTIPLE_LATCHES' flag to the loop discovery, note 19819however that most other loop manipulation functions will not work 19820correctly for loops with multiple latch edges (the functions that only 19821query membership of blocks to loops and subloop relationships, or 19822enumerate and test loop exits, can be expected to work). 19823 19824 Body of the loop is the set of blocks that are dominated by its header, 19825and reachable from its latch against the direction of edges in CFG. The 19826loops are organized in a containment hierarchy (tree) such that all the 19827loops immediately contained inside loop L are the children of L in the 19828tree. This tree is represented by the 'struct loops' structure. The 19829root of this tree is a fake loop that contains all blocks in the 19830function. Each of the loops is represented in a 'struct loop' 19831structure. Each loop is assigned an index ('num' field of the 'struct 19832loop' structure), and the pointer to the loop is stored in the 19833corresponding field of the 'larray' vector in the loops structure. The 19834indices do not have to be continuous, there may be empty ('NULL') 19835entries in the 'larray' created by deleting loops. Also, there is no 19836guarantee on the relative order of a loop and its subloops in the 19837numbering. The index of a loop never changes. 19838 19839 The entries of the 'larray' field should not be accessed directly. The 19840function 'get_loop' returns the loop description for a loop with the 19841given index. 'number_of_loops' function returns number of loops in the 19842function. To traverse all loops, use 'FOR_EACH_LOOP' macro. The 19843'flags' argument of the macro is used to determine the direction of 19844traversal and the set of loops visited. Each loop is guaranteed to be 19845visited exactly once, regardless of the changes to the loop tree, and 19846the loops may be removed during the traversal. The newly created loops 19847are never traversed, if they need to be visited, this must be done 19848separately after their creation. The 'FOR_EACH_LOOP' macro allocates 19849temporary variables. If the 'FOR_EACH_LOOP' loop were ended using break 19850or goto, they would not be released; 'FOR_EACH_LOOP_BREAK' macro must be 19851used instead. 19852 19853 Each basic block contains the reference to the innermost loop it 19854belongs to ('loop_father'). For this reason, it is only possible to 19855have one 'struct loops' structure initialized at the same time for each 19856CFG. The global variable 'current_loops' contains the 'struct loops' 19857structure. Many of the loop manipulation functions assume that 19858dominance information is up-to-date. 19859 19860 The loops are analyzed through 'loop_optimizer_init' function. The 19861argument of this function is a set of flags represented in an integer 19862bitmask. These flags specify what other properties of the loop 19863structures should be calculated/enforced and preserved later: 19864 19865 * 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES': If this flag is set, no changes 19866 to CFG will be performed in the loop analysis, in particular, loops 19867 with multiple latch edges will not be disambiguated. If a loop has 19868 multiple latches, its latch block is set to NULL. Most of the loop 19869 manipulation functions will not work for loops in this shape. No 19870 other flags that require CFG changes can be passed to 19871 loop_optimizer_init. 19872 * 'LOOPS_HAVE_PREHEADERS': Forwarder blocks are created in such a way 19873 that each loop has only one entry edge, and additionally, the 19874 source block of this entry edge has only one successor. This 19875 creates a natural place where the code can be moved out of the 19876 loop, and ensures that the entry edge of the loop leads from its 19877 immediate super-loop. 19878 * 'LOOPS_HAVE_SIMPLE_LATCHES': Forwarder blocks are created to force 19879 the latch block of each loop to have only one successor. This 19880 ensures that the latch of the loop does not belong to any of its 19881 sub-loops, and makes manipulation with the loops significantly 19882 easier. Most of the loop manipulation functions assume that the 19883 loops are in this shape. Note that with this flag, the "normal" 19884 loop without any control flow inside and with one exit consists of 19885 two basic blocks. 19886 * 'LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS': Basic blocks and edges in 19887 the strongly connected components that are not natural loops (have 19888 more than one entry block) are marked with 'BB_IRREDUCIBLE_LOOP' 19889 and 'EDGE_IRREDUCIBLE_LOOP' flags. The flag is not set for blocks 19890 and edges that belong to natural loops that are in such an 19891 irreducible region (but it is set for the entry and exit edges of 19892 such a loop, if they lead to/from this region). 19893 * 'LOOPS_HAVE_RECORDED_EXITS': The lists of exits are recorded and 19894 updated for each loop. This makes some functions (e.g., 19895 'get_loop_exit_edges') more efficient. Some functions (e.g., 19896 'single_exit') can be used only if the lists of exits are recorded. 19897 19898 These properties may also be computed/enforced later, using functions 19899'create_preheaders', 'force_single_succ_latches', 19900'mark_irreducible_loops' and 'record_loop_exits'. The properties can be 19901queried using 'loops_state_satisfies_p'. 19902 19903 The memory occupied by the loops structures should be freed with 19904'loop_optimizer_finalize' function. When loop structures are setup to 19905be preserved across passes this function reduces the information to be 19906kept up-to-date to a minimum (only 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES' 19907set). 19908 19909 The CFG manipulation functions in general do not update loop 19910structures. Specialized versions that additionally do so are provided 19911for the most common tasks. On GIMPLE, 'cleanup_tree_cfg_loop' function 19912can be used to cleanup CFG while updating the loops structures if 19913'current_loops' is set. 19914 19915 At the moment loop structure is preserved from the start of GIMPLE loop 19916optimizations until the end of RTL loop optimizations. During this time 19917a loop can be tracked by its 'struct loop' and number. 19918 19919 19920File: gccint.info, Node: Loop querying, Next: Loop manipulation, Prev: Loop representation, Up: Loop Analysis and Representation 19921 1992216.2 Loop querying 19923================== 19924 19925The functions to query the information about loops are declared in 19926'cfgloop.h'. Some of the information can be taken directly from the 19927structures. 'loop_father' field of each basic block contains the 19928innermost loop to that the block belongs. The most useful fields of 19929loop structure (that are kept up-to-date at all times) are: 19930 19931 * 'header', 'latch': Header and latch basic blocks of the loop. 19932 * 'num_nodes': Number of basic blocks in the loop (including the 19933 basic blocks of the sub-loops). 19934 * 'outer', 'inner', 'next': The super-loop, the first sub-loop, and 19935 the sibling of the loop in the loops tree. 19936 19937 There are other fields in the loop structures, many of them used only 19938by some of the passes, or not updated during CFG changes; in general, 19939they should not be accessed directly. 19940 19941 The most important functions to query loop structures are: 19942 19943 * 'loop_depth': The depth of the loop in the loops tree, i.e., the 19944 number of super-loops of the loop. 19945 * 'flow_loops_dump': Dumps the information about loops to a file. 19946 * 'verify_loop_structure': Checks consistency of the loop structures. 19947 * 'loop_latch_edge': Returns the latch edge of a loop. 19948 * 'loop_preheader_edge': If loops have preheaders, returns the 19949 preheader edge of a loop. 19950 * 'flow_loop_nested_p': Tests whether loop is a sub-loop of another 19951 loop. 19952 * 'flow_bb_inside_loop_p': Tests whether a basic block belongs to a 19953 loop (including its sub-loops). 19954 * 'find_common_loop': Finds the common super-loop of two loops. 19955 * 'superloop_at_depth': Returns the super-loop of a loop with the 19956 given depth. 19957 * 'tree_num_loop_insns', 'num_loop_insns': Estimates the number of 19958 insns in the loop, on GIMPLE and on RTL. 19959 * 'loop_exit_edge_p': Tests whether edge is an exit from a loop. 19960 * 'mark_loop_exit_edges': Marks all exit edges of all loops with 19961 'EDGE_LOOP_EXIT' flag. 19962 * 'get_loop_body', 'get_loop_body_in_dom_order', 19963 'get_loop_body_in_bfs_order': Enumerates the basic blocks in the 19964 loop in depth-first search order in reversed CFG, ordered by 19965 dominance relation, and breath-first search order, respectively. 19966 * 'single_exit': Returns the single exit edge of the loop, or 'NULL' 19967 if the loop has more than one exit. You can only use this function 19968 if LOOPS_HAVE_MARKED_SINGLE_EXITS property is used. 19969 * 'get_loop_exit_edges': Enumerates the exit edges of a loop. 19970 * 'just_once_each_iteration_p': Returns true if the basic block is 19971 executed exactly once during each iteration of a loop (that is, it 19972 does not belong to a sub-loop, and it dominates the latch of the 19973 loop). 19974 19975 19976File: gccint.info, Node: Loop manipulation, Next: LCSSA, Prev: Loop querying, Up: Loop Analysis and Representation 19977 1997816.3 Loop manipulation 19979====================== 19980 19981The loops tree can be manipulated using the following functions: 19982 19983 * 'flow_loop_tree_node_add': Adds a node to the tree. 19984 * 'flow_loop_tree_node_remove': Removes a node from the tree. 19985 * 'add_bb_to_loop': Adds a basic block to a loop. 19986 * 'remove_bb_from_loops': Removes a basic block from loops. 19987 19988 Most low-level CFG functions update loops automatically. The following 19989functions handle some more complicated cases of CFG manipulations: 19990 19991 * 'remove_path': Removes an edge and all blocks it dominates. 19992 * 'split_loop_exit_edge': Splits exit edge of the loop, ensuring that 19993 PHI node arguments remain in the loop (this ensures that 19994 loop-closed SSA form is preserved). Only useful on GIMPLE. 19995 19996 Finally, there are some higher-level loop transformations implemented. 19997While some of them are written so that they should work on non-innermost 19998loops, they are mostly untested in that case, and at the moment, they 19999are only reliable for the innermost loops: 20000 20001 * 'create_iv': Creates a new induction variable. Only works on 20002 GIMPLE. 'standard_iv_increment_position' can be used to find a 20003 suitable place for the iv increment. 20004 * 'duplicate_loop_to_header_edge', 20005 'tree_duplicate_loop_to_header_edge': These functions (on RTL and 20006 on GIMPLE) duplicate the body of the loop prescribed number of 20007 times on one of the edges entering loop header, thus performing 20008 either loop unrolling or loop peeling. 'can_duplicate_loop_p' 20009 ('can_unroll_loop_p' on GIMPLE) must be true for the duplicated 20010 loop. 20011 * 'loop_version': This function creates a copy of a loop, and a 20012 branch before them that selects one of them depending on the 20013 prescribed condition. This is useful for optimizations that need 20014 to verify some assumptions in runtime (one of the copies of the 20015 loop is usually left unchanged, while the other one is transformed 20016 in some way). 20017 * 'tree_unroll_loop': Unrolls the loop, including peeling the extra 20018 iterations to make the number of iterations divisible by unroll 20019 factor, updating the exit condition, and removing the exits that 20020 now cannot be taken. Works only on GIMPLE. 20021 20022 20023File: gccint.info, Node: LCSSA, Next: Scalar evolutions, Prev: Loop manipulation, Up: Loop Analysis and Representation 20024 2002516.4 Loop-closed SSA form 20026========================= 20027 20028Throughout the loop optimizations on tree level, one extra condition is 20029enforced on the SSA form: No SSA name is used outside of the loop in 20030that it is defined. The SSA form satisfying this condition is called 20031"loop-closed SSA form" - LCSSA. To enforce LCSSA, PHI nodes must be 20032created at the exits of the loops for the SSA names that are used 20033outside of them. Only the real operands (not virtual SSA names) are 20034held in LCSSA, in order to save memory. 20035 20036 There are various benefits of LCSSA: 20037 20038 * Many optimizations (value range analysis, final value replacement) 20039 are interested in the values that are defined in the loop and used 20040 outside of it, i.e., exactly those for that we create new PHI 20041 nodes. 20042 * In induction variable analysis, it is not necessary to specify the 20043 loop in that the analysis should be performed - the scalar 20044 evolution analysis always returns the results with respect to the 20045 loop in that the SSA name is defined. 20046 * It makes updating of SSA form during loop transformations simpler. 20047 Without LCSSA, operations like loop unrolling may force creation of 20048 PHI nodes arbitrarily far from the loop, while in LCSSA, the SSA 20049 form can be updated locally. However, since we only keep real 20050 operands in LCSSA, we cannot use this advantage (we could have 20051 local updating of real operands, but it is not much more efficient 20052 than to use generic SSA form updating for it as well; the amount of 20053 changes to SSA is the same). 20054 20055 However, it also means LCSSA must be updated. This is usually 20056straightforward, unless you create a new value in loop and use it 20057outside, or unless you manipulate loop exit edges (functions are 20058provided to make these manipulations simple). 20059'rewrite_into_loop_closed_ssa' is used to rewrite SSA form to LCSSA, and 20060'verify_loop_closed_ssa' to check that the invariant of LCSSA is 20061preserved. 20062 20063 20064File: gccint.info, Node: Scalar evolutions, Next: loop-iv, Prev: LCSSA, Up: Loop Analysis and Representation 20065 2006616.5 Scalar evolutions 20067====================== 20068 20069Scalar evolutions (SCEV) are used to represent results of induction 20070variable analysis on GIMPLE. They enable us to represent variables with 20071complicated behavior in a simple and consistent way (we only use it to 20072express values of polynomial induction variables, but it is possible to 20073extend it). The interfaces to SCEV analysis are declared in 20074'tree-scalar-evolution.h'. To use scalar evolutions analysis, 20075'scev_initialize' must be used. To stop using SCEV, 'scev_finalize' 20076should be used. SCEV analysis caches results in order to save time and 20077memory. This cache however is made invalid by most of the loop 20078transformations, including removal of code. If such a transformation is 20079performed, 'scev_reset' must be called to clean the caches. 20080 20081 Given an SSA name, its behavior in loops can be analyzed using the 20082'analyze_scalar_evolution' function. The returned SCEV however does not 20083have to be fully analyzed and it may contain references to other SSA 20084names defined in the loop. To resolve these (potentially recursive) 20085references, 'instantiate_parameters' or 'resolve_mixers' functions must 20086be used. 'instantiate_parameters' is useful when you use the results of 20087SCEV only for some analysis, and when you work with whole nest of loops 20088at once. It will try replacing all SSA names by their SCEV in all 20089loops, including the super-loops of the current loop, thus providing a 20090complete information about the behavior of the variable in the loop 20091nest. 'resolve_mixers' is useful if you work with only one loop at a 20092time, and if you possibly need to create code based on the value of the 20093induction variable. It will only resolve the SSA names defined in the 20094current loop, leaving the SSA names defined outside unchanged, even if 20095their evolution in the outer loops is known. 20096 20097 The SCEV is a normal tree expression, except for the fact that it may 20098contain several special tree nodes. One of them is 'SCEV_NOT_KNOWN', 20099used for SSA names whose value cannot be expressed. The other one is 20100'POLYNOMIAL_CHREC'. Polynomial chrec has three arguments - base, step 20101and loop (both base and step may contain further polynomial chrecs). 20102Type of the expression and of base and step must be the same. A 20103variable has evolution 'POLYNOMIAL_CHREC(base, step, loop)' if it is (in 20104the specified loop) equivalent to 'x_1' in the following example 20105 20106 while (...) 20107 { 20108 x_1 = phi (base, x_2); 20109 x_2 = x_1 + step; 20110 } 20111 20112 Note that this includes the language restrictions on the operations. 20113For example, if we compile C code and 'x' has signed type, then the 20114overflow in addition would cause undefined behavior, and we may assume 20115that this does not happen. Hence, the value with this SCEV cannot 20116overflow (which restricts the number of iterations of such a loop). 20117 20118 In many cases, one wants to restrict the attention just to affine 20119induction variables. In this case, the extra expressive power of SCEV 20120is not useful, and may complicate the optimizations. In this case, 20121'simple_iv' function may be used to analyze a value - the result is a 20122loop-invariant base and step. 20123 20124 20125File: gccint.info, Node: loop-iv, Next: Number of iterations, Prev: Scalar evolutions, Up: Loop Analysis and Representation 20126 2012716.6 IV analysis on RTL 20128======================= 20129 20130The induction variable on RTL is simple and only allows analysis of 20131affine induction variables, and only in one loop at once. The interface 20132is declared in 'cfgloop.h'. Before analyzing induction variables in a 20133loop L, 'iv_analysis_loop_init' function must be called on L. After the 20134analysis (possibly calling 'iv_analysis_loop_init' for several loops) is 20135finished, 'iv_analysis_done' should be called. The following functions 20136can be used to access the results of the analysis: 20137 20138 * 'iv_analyze': Analyzes a single register used in the given insn. 20139 If no use of the register in this insn is found, the following 20140 insns are scanned, so that this function can be called on the insn 20141 returned by get_condition. 20142 * 'iv_analyze_result': Analyzes result of the assignment in the given 20143 insn. 20144 * 'iv_analyze_expr': Analyzes a more complicated expression. All its 20145 operands are analyzed by 'iv_analyze', and hence they must be used 20146 in the specified insn or one of the following insns. 20147 20148 The description of the induction variable is provided in 'struct 20149rtx_iv'. In order to handle subregs, the representation is a bit 20150complicated; if the value of the 'extend' field is not 'UNKNOWN', the 20151value of the induction variable in the i-th iteration is 20152 20153 delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)), 20154 20155 with the following exception: if 'first_special' is true, then the 20156value in the first iteration (when 'i' is zero) is 'delta + mult * 20157base'. However, if 'extend' is equal to 'UNKNOWN', then 'first_special' 20158must be false, 'delta' 0, 'mult' 1 and the value in the i-th iteration 20159is 20160 20161 subreg_{mode} (base + i * step) 20162 20163 The function 'get_iv_value' can be used to perform these calculations. 20164 20165 20166File: gccint.info, Node: Number of iterations, Next: Dependency analysis, Prev: loop-iv, Up: Loop Analysis and Representation 20167 2016816.7 Number of iterations analysis 20169================================== 20170 20171Both on GIMPLE and on RTL, there are functions available to determine 20172the number of iterations of a loop, with a similar interface. The 20173number of iterations of a loop in GCC is defined as the number of 20174executions of the loop latch. In many cases, it is not possible to 20175determine the number of iterations unconditionally - the determined 20176number is correct only if some assumptions are satisfied. The analysis 20177tries to verify these conditions using the information contained in the 20178program; if it fails, the conditions are returned together with the 20179result. The following information and conditions are provided by the 20180analysis: 20181 20182 * 'assumptions': If this condition is false, the rest of the 20183 information is invalid. 20184 * 'noloop_assumptions' on RTL, 'may_be_zero' on GIMPLE: If this 20185 condition is true, the loop exits in the first iteration. 20186 * 'infinite': If this condition is true, the loop is infinite. This 20187 condition is only available on RTL. On GIMPLE, conditions for 20188 finiteness of the loop are included in 'assumptions'. 20189 * 'niter_expr' on RTL, 'niter' on GIMPLE: The expression that gives 20190 number of iterations. The number of iterations is defined as the 20191 number of executions of the loop latch. 20192 20193 Both on GIMPLE and on RTL, it necessary for the induction variable 20194analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL). 20195On GIMPLE, the results are stored to 'struct tree_niter_desc' structure. 20196Number of iterations before the loop is exited through a given exit can 20197be determined using 'number_of_iterations_exit' function. On RTL, the 20198results are returned in 'struct niter_desc' structure. The 20199corresponding function is named 'check_simple_exit'. There are also 20200functions that pass through all the exits of a loop and try to find one 20201with easy to determine number of iterations - 'find_loop_niter' on 20202GIMPLE and 'find_simple_exit' on RTL. Finally, there are functions that 20203provide the same information, but additionally cache it, so that 20204repeated calls to number of iterations are not so costly - 20205'number_of_latch_executions' on GIMPLE and 'get_simple_loop_desc' on 20206RTL. 20207 20208 Note that some of these functions may behave slightly differently than 20209others - some of them return only the expression for the number of 20210iterations, and fail if there are some assumptions. The function 20211'number_of_latch_executions' works only for single-exit loops. The 20212function 'number_of_cond_exit_executions' can be used to determine 20213number of executions of the exit condition of a single-exit loop (i.e., 20214the 'number_of_latch_executions' increased by one). 20215 20216 On GIMPLE, below constraint flags affect semantics of some APIs of 20217number of iterations analyzer: 20218 20219 * 'LOOP_C_INFINITE': If this constraint flag is set, the loop is 20220 known to be infinite. APIs like 'number_of_iterations_exit' can 20221 return false directly without doing any analysis. 20222 * 'LOOP_C_FINITE': If this constraint flag is set, the loop is known 20223 to be finite, in other words, loop's number of iterations can be 20224 computed with 'assumptions' be true. 20225 20226 Generally, the constraint flags are set/cleared by consumers which are 20227loop optimizers. It's also the consumers' responsibility to set/clear 20228constraints correctly. Failing to do that might result in hard to track 20229down bugs in scev/niter consumers. One typical use case is vectorizer: 20230it drives number of iterations analyzer by setting 'LOOP_C_FINITE' and 20231vectorizes possibly infinite loop by versioning loop with analysis 20232result. In return, constraints set by consumers can also help number of 20233iterations analyzer in following optimizers. For example, 'niter' of a 20234loop versioned under 'assumptions' is valid unconditionally. 20235 20236 Other constraints may be added in the future, for example, a constraint 20237indicating that loops' latch must roll thus 'may_be_zero' would be false 20238unconditionally. 20239 20240 20241File: gccint.info, Node: Dependency analysis, Prev: Number of iterations, Up: Loop Analysis and Representation 20242 2024316.8 Data Dependency Analysis 20244============================= 20245 20246The code for the data dependence analysis can be found in 20247'tree-data-ref.c' and its interface and data structures are described in 20248'tree-data-ref.h'. The function that computes the data dependences for 20249all the array and pointer references for a given loop is 20250'compute_data_dependences_for_loop'. This function is currently used by 20251the linear loop transform and the vectorization passes. Before calling 20252this function, one has to allocate two vectors: a first vector will 20253contain the set of data references that are contained in the analyzed 20254loop body, and the second vector will contain the dependence relations 20255between the data references. Thus if the vector of data references is 20256of size 'n', the vector containing the dependence relations will contain 20257'n*n' elements. However if the analyzed loop contains side effects, 20258such as calls that potentially can interfere with the data references in 20259the current analyzed loop, the analysis stops while scanning the loop 20260body for data references, and inserts a single 'chrec_dont_know' in the 20261dependence relation array. 20262 20263 The data references are discovered in a particular order during the 20264scanning of the loop body: the loop body is analyzed in execution order, 20265and the data references of each statement are pushed at the end of the 20266data reference array. Two data references syntactically occur in the 20267program in the same order as in the array of data references. This 20268syntactic order is important in some classical data dependence tests, 20269and mapping this order to the elements of this array avoids costly 20270queries to the loop body representation. 20271 20272 Three types of data references are currently handled: ARRAY_REF, 20273INDIRECT_REF and COMPONENT_REF. The data structure for the data 20274reference is 'data_reference', where 'data_reference_p' is a name of a 20275pointer to the data reference structure. The structure contains the 20276following elements: 20277 20278 * 'base_object_info': Provides information about the base object of 20279 the data reference and its access functions. These access 20280 functions represent the evolution of the data reference in the loop 20281 relative to its base, in keeping with the classical meaning of the 20282 data reference access function for the support of arrays. For 20283 example, for a reference 'a.b[i][j]', the base object is 'a.b' and 20284 the access functions, one for each array subscript, are: '{i_init, 20285 + i_step}_1, {j_init, +, j_step}_2'. 20286 20287 * 'first_location_in_loop': Provides information about the first 20288 location accessed by the data reference in the loop and about the 20289 access function used to represent evolution relative to this 20290 location. This data is used to support pointers, and is not used 20291 for arrays (for which we have base objects). Pointer accesses are 20292 represented as a one-dimensional access that starts from the first 20293 location accessed in the loop. For example: 20294 20295 for1 i 20296 for2 j 20297 *((int *)p + i + j) = a[i][j]; 20298 20299 The access function of the pointer access is '{0, + 4B}_for2' 20300 relative to 'p + i'. The access functions of the array are 20301 '{i_init, + i_step}_for1' and '{j_init, +, j_step}_for2' relative 20302 to 'a'. 20303 20304 Usually, the object the pointer refers to is either unknown, or we 20305 cannot prove that the access is confined to the boundaries of a 20306 certain object. 20307 20308 Two data references can be compared only if at least one of these 20309 two representations has all its fields filled for both data 20310 references. 20311 20312 The current strategy for data dependence tests is as follows: If 20313 both 'a' and 'b' are represented as arrays, compare 'a.base_object' 20314 and 'b.base_object'; if they are equal, apply dependence tests (use 20315 access functions based on base_objects). Else if both 'a' and 'b' 20316 are represented as pointers, compare 'a.first_location' and 20317 'b.first_location'; if they are equal, apply dependence tests (use 20318 access functions based on first location). However, if 'a' and 'b' 20319 are represented differently, only try to prove that the bases are 20320 definitely different. 20321 20322 * Aliasing information. 20323 * Alignment information. 20324 20325 The structure describing the relation between two data references is 20326'data_dependence_relation' and the shorter name for a pointer to such a 20327structure is 'ddr_p'. This structure contains: 20328 20329 * a pointer to each data reference, 20330 * a tree node 'are_dependent' that is set to 'chrec_known' if the 20331 analysis has proved that there is no dependence between these two 20332 data references, 'chrec_dont_know' if the analysis was not able to 20333 determine any useful result and potentially there could exist a 20334 dependence between these data references, and 'are_dependent' is 20335 set to 'NULL_TREE' if there exist a dependence relation between the 20336 data references, and the description of this dependence relation is 20337 given in the 'subscripts', 'dir_vects', and 'dist_vects' arrays, 20338 * a boolean that determines whether the dependence relation can be 20339 represented by a classical distance vector, 20340 * an array 'subscripts' that contains a description of each subscript 20341 of the data references. Given two array accesses a subscript is 20342 the tuple composed of the access functions for a given dimension. 20343 For example, given 'A[f1][f2][f3]' and 'B[g1][g2][g3]', there are 20344 three subscripts: '(f1, g1), (f2, g2), (f3, g3)'. 20345 * two arrays 'dir_vects' and 'dist_vects' that contain classical 20346 representations of the data dependences under the form of direction 20347 and distance dependence vectors, 20348 * an array of loops 'loop_nest' that contains the loops to which the 20349 distance and direction vectors refer to. 20350 20351 Several functions for pretty printing the information extracted by the 20352data dependence analysis are available: 'dump_ddrs' prints with a 20353maximum verbosity the details of a data dependence relations array, 20354'dump_dist_dir_vectors' prints only the classical distance and direction 20355vectors for a data dependence relations array, and 20356'dump_data_references' prints the details of the data references 20357contained in a data reference array. 20358 20359 20360File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: Loop Analysis and Representation, Up: Top 20361 2036217 Machine Descriptions 20363*********************** 20364 20365A machine description has two parts: a file of instruction patterns 20366('.md' file) and a C header file of macro definitions. 20367 20368 The '.md' file for a target machine contains a pattern for each 20369instruction that the target machine supports (or at least each 20370instruction that is worth telling the compiler about). It may also 20371contain comments. A semicolon causes the rest of the line to be a 20372comment, unless the semicolon is inside a quoted string. 20373 20374 See the next chapter for information on the C header file. 20375 20376* Menu: 20377 20378* Overview:: How the machine description is used. 20379* Patterns:: How to write instruction patterns. 20380* Example:: An explained example of a 'define_insn' pattern. 20381* RTL Template:: The RTL template defines what insns match a pattern. 20382* Output Template:: The output template says how to make assembler code 20383 from such an insn. 20384* Output Statement:: For more generality, write C code to output 20385 the assembler code. 20386* Predicates:: Controlling what kinds of operands can be used 20387 for an insn. 20388* Constraints:: Fine-tuning operand selection. 20389* Standard Names:: Names mark patterns to use for code generation. 20390* Pattern Ordering:: When the order of patterns makes a difference. 20391* Dependent Patterns:: Having one pattern may make you need another. 20392* Jump Patterns:: Special considerations for patterns for jump insns. 20393* Looping Patterns:: How to define patterns for special looping insns. 20394* Insn Canonicalizations::Canonicalization of Instructions 20395* Expander Definitions::Generating a sequence of several RTL insns 20396 for a standard operation. 20397* Insn Splitting:: Splitting Instructions into Multiple Instructions. 20398* Including Patterns:: Including Patterns in Machine Descriptions. 20399* Peephole Definitions::Defining machine-specific peephole optimizations. 20400* Insn Attributes:: Specifying the value of attributes for generated insns. 20401* Conditional Execution::Generating 'define_insn' patterns for 20402 predication. 20403* Define Subst:: Generating 'define_insn' and 'define_expand' 20404 patterns from other patterns. 20405* Constant Definitions::Defining symbolic constants that can be used in the 20406 md file. 20407* Iterators:: Using iterators to generate patterns from a template. 20408 20409 20410File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc 20411 2041217.1 Overview of How the Machine Description is Used 20413==================================================== 20414 20415There are three main conversions that happen in the compiler: 20416 20417 1. The front end reads the source code and builds a parse tree. 20418 20419 2. The parse tree is used to generate an RTL insn list based on named 20420 instruction patterns. 20421 20422 3. The insn list is matched against the RTL templates to produce 20423 assembler code. 20424 20425 For the generate pass, only the names of the insns matter, from either 20426a named 'define_insn' or a 'define_expand'. The compiler will choose 20427the pattern with the right name and apply the operands according to the 20428documentation later in this chapter, without regard for the RTL template 20429or operand constraints. Note that the names the compiler looks for are 20430hard-coded in the compiler--it will ignore unnamed patterns and patterns 20431with names it doesn't know about, but if you don't provide a named 20432pattern it needs, it will abort. 20433 20434 If a 'define_insn' is used, the template given is inserted into the 20435insn list. If a 'define_expand' is used, one of three things happens, 20436based on the condition logic. The condition logic may manually create 20437new insns for the insn list, say via 'emit_insn()', and invoke 'DONE'. 20438For certain named patterns, it may invoke 'FAIL' to tell the compiler to 20439use an alternate way of performing that task. If it invokes neither 20440'DONE' nor 'FAIL', the template given in the pattern is inserted, as if 20441the 'define_expand' were a 'define_insn'. 20442 20443 Once the insn list is generated, various optimization passes convert, 20444replace, and rearrange the insns in the insn list. This is where the 20445'define_split' and 'define_peephole' patterns get used, for example. 20446 20447 Finally, the insn list's RTL is matched up with the RTL templates in 20448the 'define_insn' patterns, and those patterns are used to emit the 20449final assembly code. For this purpose, each named 'define_insn' acts 20450like it's unnamed, since the names are ignored. 20451 20452 20453File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc 20454 2045517.2 Everything about Instruction Patterns 20456========================================== 20457 20458A 'define_insn' expression is used to define instruction patterns to 20459which insns may be matched. A 'define_insn' expression contains an 20460incomplete RTL expression, with pieces to be filled in later, operand 20461constraints that restrict how the pieces can be filled in, and an output 20462template or C code to generate the assembler output. 20463 20464 A 'define_insn' is an RTL expression containing four or five operands: 20465 20466 1. An optional name N. When a name is present, the compiler 20467 automically generates a C++ function 'gen_N' that takes the 20468 operands of the instruction as arguments and returns the 20469 instruction's rtx pattern. The compiler also assigns the 20470 instruction a unique code 'CODE_FOR_N', with all such codes 20471 belonging to an enum called 'insn_code'. 20472 20473 These names serve one of two purposes. The first is to indicate 20474 that the instruction performs a certain standard job for the 20475 RTL-generation pass of the compiler, such as a move, an addition, 20476 or a conditional jump. The second is to help the target generate 20477 certain target-specific operations, such as when implementing 20478 target-specific intrinsic functions. 20479 20480 It is better to prefix target-specific names with the name of the 20481 target, to avoid any clash with current or future standard names. 20482 20483 The absence of a name is indicated by writing an empty string where 20484 the name should go. Nameless instruction patterns are never used 20485 for generating RTL code, but they may permit several simpler insns 20486 to be combined later on. 20487 20488 For the purpose of debugging the compiler, you may also specify a 20489 name beginning with the '*' character. Such a name is used only 20490 for identifying the instruction in RTL dumps; it is equivalent to 20491 having a nameless pattern for all other purposes. Names beginning 20492 with the '*' character are not required to be unique. 20493 20494 The name may also have the form '@N'. This has the same effect as 20495 a name 'N', but in addition tells the compiler to generate further 20496 helper functions; see *note Parameterized Names:: for details. 20497 20498 2. The "RTL template": This is a vector of incomplete RTL expressions 20499 which describe the semantics of the instruction (*note RTL 20500 Template::). It is incomplete because it may contain 20501 'match_operand', 'match_operator', and 'match_dup' expressions that 20502 stand for operands of the instruction. 20503 20504 If the vector has multiple elements, the RTL template is treated as 20505 a 'parallel' expression. 20506 20507 3. The condition: This is a string which contains a C expression. 20508 When the compiler attempts to match RTL against a pattern, the 20509 condition is evaluated. If the condition evaluates to 'true', the 20510 match is permitted. The condition may be an empty string, which is 20511 treated as always 'true'. 20512 20513 For a named pattern, the condition may not depend on the data in 20514 the insn being matched, but only the target-machine-type flags. 20515 The compiler needs to test these conditions during initialization 20516 in order to learn exactly which named instructions are available in 20517 a particular run. 20518 20519 For nameless patterns, the condition is applied only when matching 20520 an individual insn, and only after the insn has matched the 20521 pattern's recognition template. The insn's operands may be found 20522 in the vector 'operands'. 20523 20524 An instruction condition cannot become more restrictive as 20525 compilation progresses. If the condition accepts a particular RTL 20526 instruction at one stage of compilation, it must continue to accept 20527 that instruction until the final pass. For example, 20528 '!reload_completed' and 'can_create_pseudo_p ()' are both invalid 20529 instruction conditions, because they are true during the earlier 20530 RTL passes and false during the later ones. For the same reason, 20531 if a condition accepts an instruction before register allocation, 20532 it cannot later try to control register allocation by excluding 20533 certain register or value combinations. 20534 20535 Although a condition cannot become more restrictive as compilation 20536 progresses, the condition for a nameless pattern _can_ become more 20537 permissive. For example, a nameless instruction can require 20538 'reload_completed' to be true, in which case it only matches after 20539 register allocation. 20540 20541 4. The "output template" or "output statement": This is either a 20542 string, or a fragment of C code which returns a string. 20543 20544 When simple substitution isn't general enough, you can specify a 20545 piece of C code to compute the output. *Note Output Statement::. 20546 20547 5. The "insn attributes": This is an optional vector containing the 20548 values of attributes for insns matching this pattern (*note Insn 20549 Attributes::). 20550 20551 20552File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc 20553 2055417.3 Example of 'define_insn' 20555============================= 20556 20557Here is an example of an instruction pattern, taken from the machine 20558description for the 68000/68020. 20559 20560 (define_insn "tstsi" 20561 [(set (cc0) 20562 (match_operand:SI 0 "general_operand" "rm"))] 20563 "" 20564 "* 20565 { 20566 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 20567 return \"tstl %0\"; 20568 return \"cmpl #0,%0\"; 20569 }") 20570 20571This can also be written using braced strings: 20572 20573 (define_insn "tstsi" 20574 [(set (cc0) 20575 (match_operand:SI 0 "general_operand" "rm"))] 20576 "" 20577 { 20578 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 20579 return "tstl %0"; 20580 return "cmpl #0,%0"; 20581 }) 20582 20583 This describes an instruction which sets the condition codes based on 20584the value of a general operand. It has no condition, so any insn with 20585an RTL description of the form shown may be matched to this pattern. 20586The name 'tstsi' means "test a 'SImode' value" and tells the RTL 20587generation pass that, when it is necessary to test such a value, an insn 20588to do so can be constructed using this pattern. 20589 20590 The output control string is a piece of C code which chooses which 20591output template to return based on the kind of operand and the specific 20592type of CPU for which code is being generated. 20593 20594 '"rm"' is an operand constraint. Its meaning is explained below. 20595 20596 20597File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc 20598 2059917.4 RTL Template 20600================= 20601 20602The RTL template is used to define which insns match the particular 20603pattern and how to find their operands. For named patterns, the RTL 20604template also says how to construct an insn from specified operands. 20605 20606 Construction involves substituting specified operands into a copy of 20607the template. Matching involves determining the values that serve as 20608the operands in the insn being matched. Both of these activities are 20609controlled by special expression types that direct matching and 20610substitution of the operands. 20611 20612'(match_operand:M N PREDICATE CONSTRAINT)' 20613 This expression is a placeholder for operand number N of the insn. 20614 When constructing an insn, operand number N will be substituted at 20615 this point. When matching an insn, whatever appears at this 20616 position in the insn will be taken as operand number N; but it must 20617 satisfy PREDICATE or this instruction pattern will not match at 20618 all. 20619 20620 Operand numbers must be chosen consecutively counting from zero in 20621 each instruction pattern. There may be only one 'match_operand' 20622 expression in the pattern for each operand number. Usually 20623 operands are numbered in the order of appearance in 'match_operand' 20624 expressions. In the case of a 'define_expand', any operand numbers 20625 used only in 'match_dup' expressions have higher values than all 20626 other operand numbers. 20627 20628 PREDICATE is a string that is the name of a function that accepts 20629 two arguments, an expression and a machine mode. *Note 20630 Predicates::. During matching, the function will be called with 20631 the putative operand as the expression and M as the mode argument 20632 (if M is not specified, 'VOIDmode' will be used, which normally 20633 causes PREDICATE to accept any mode). If it returns zero, this 20634 instruction pattern fails to match. PREDICATE may be an empty 20635 string; then it means no test is to be done on the operand, so 20636 anything which occurs in this position is valid. 20637 20638 Most of the time, PREDICATE will reject modes other than M--but not 20639 always. For example, the predicate 'address_operand' uses M as the 20640 mode of memory ref that the address should be valid for. Many 20641 predicates accept 'const_int' nodes even though their mode is 20642 'VOIDmode'. 20643 20644 CONSTRAINT controls reloading and the choice of the best register 20645 class to use for a value, as explained later (*note Constraints::). 20646 If the constraint would be an empty string, it can be omitted. 20647 20648 People are often unclear on the difference between the constraint 20649 and the predicate. The predicate helps decide whether a given insn 20650 matches the pattern. The constraint plays no role in this 20651 decision; instead, it controls various decisions in the case of an 20652 insn which does match. 20653 20654'(match_scratch:M N CONSTRAINT)' 20655 This expression is also a placeholder for operand number N and 20656 indicates that operand must be a 'scratch' or 'reg' expression. 20657 20658 When matching patterns, this is equivalent to 20659 20660 (match_operand:M N "scratch_operand" CONSTRAINT) 20661 20662 but, when generating RTL, it produces a ('scratch':M) expression. 20663 20664 If the last few expressions in a 'parallel' are 'clobber' 20665 expressions whose operands are either a hard register or 20666 'match_scratch', the combiner can add or delete them when 20667 necessary. *Note Side Effects::. 20668 20669'(match_dup N)' 20670 This expression is also a placeholder for operand number N. It is 20671 used when the operand needs to appear more than once in the insn. 20672 20673 In construction, 'match_dup' acts just like 'match_operand': the 20674 operand is substituted into the insn being constructed. But in 20675 matching, 'match_dup' behaves differently. It assumes that operand 20676 number N has already been determined by a 'match_operand' appearing 20677 earlier in the recognition template, and it matches only an 20678 identical-looking expression. 20679 20680 Note that 'match_dup' should not be used to tell the compiler that 20681 a particular register is being used for two operands (example: 20682 'add' that adds one register to another; the second register is 20683 both an input operand and the output operand). Use a matching 20684 constraint (*note Simple Constraints::) for those. 'match_dup' is 20685 for the cases where one operand is used in two places in the 20686 template, such as an instruction that computes both a quotient and 20687 a remainder, where the opcode takes two input operands but the RTL 20688 template has to refer to each of those twice; once for the quotient 20689 pattern and once for the remainder pattern. 20690 20691'(match_operator:M N PREDICATE [OPERANDS...])' 20692 This pattern is a kind of placeholder for a variable RTL expression 20693 code. 20694 20695 When constructing an insn, it stands for an RTL expression whose 20696 expression code is taken from that of operand N, and whose operands 20697 are constructed from the patterns OPERANDS. 20698 20699 When matching an expression, it matches an expression if the 20700 function PREDICATE returns nonzero on that expression _and_ the 20701 patterns OPERANDS match the operands of the expression. 20702 20703 Suppose that the function 'commutative_operator' is defined as 20704 follows, to match any expression whose operator is one of the 20705 commutative arithmetic operators of RTL and whose mode is MODE: 20706 20707 int 20708 commutative_integer_operator (x, mode) 20709 rtx x; 20710 machine_mode mode; 20711 { 20712 enum rtx_code code = GET_CODE (x); 20713 if (GET_MODE (x) != mode) 20714 return 0; 20715 return (GET_RTX_CLASS (code) == RTX_COMM_ARITH 20716 || code == EQ || code == NE); 20717 } 20718 20719 Then the following pattern will match any RTL expression consisting 20720 of a commutative operator applied to two general operands: 20721 20722 (match_operator:SI 3 "commutative_operator" 20723 [(match_operand:SI 1 "general_operand" "g") 20724 (match_operand:SI 2 "general_operand" "g")]) 20725 20726 Here the vector '[OPERANDS...]' contains two patterns because the 20727 expressions to be matched all contain two operands. 20728 20729 When this pattern does match, the two operands of the commutative 20730 operator are recorded as operands 1 and 2 of the insn. (This is 20731 done by the two instances of 'match_operand'.) Operand 3 of the 20732 insn will be the entire commutative expression: use 'GET_CODE 20733 (operands[3])' to see which commutative operator was used. 20734 20735 The machine mode M of 'match_operator' works like that of 20736 'match_operand': it is passed as the second argument to the 20737 predicate function, and that function is solely responsible for 20738 deciding whether the expression to be matched "has" that mode. 20739 20740 When constructing an insn, argument 3 of the gen-function will 20741 specify the operation (i.e. the expression code) for the expression 20742 to be made. It should be an RTL expression, whose expression code 20743 is copied into a new expression whose operands are arguments 1 and 20744 2 of the gen-function. The subexpressions of argument 3 are not 20745 used; only its expression code matters. 20746 20747 When 'match_operator' is used in a pattern for matching an insn, it 20748 usually best if the operand number of the 'match_operator' is 20749 higher than that of the actual operands of the insn. This improves 20750 register allocation because the register allocator often looks at 20751 operands 1 and 2 of insns to see if it can do register tying. 20752 20753 There is no way to specify constraints in 'match_operator'. The 20754 operand of the insn which corresponds to the 'match_operator' never 20755 has any constraints because it is never reloaded as a whole. 20756 However, if parts of its OPERANDS are matched by 'match_operand' 20757 patterns, those parts may have constraints of their own. 20758 20759'(match_op_dup:M N[OPERANDS...])' 20760 Like 'match_dup', except that it applies to operators instead of 20761 operands. When constructing an insn, operand number N will be 20762 substituted at this point. But in matching, 'match_op_dup' behaves 20763 differently. It assumes that operand number N has already been 20764 determined by a 'match_operator' appearing earlier in the 20765 recognition template, and it matches only an identical-looking 20766 expression. 20767 20768'(match_parallel N PREDICATE [SUBPAT...])' 20769 This pattern is a placeholder for an insn that consists of a 20770 'parallel' expression with a variable number of elements. This 20771 expression should only appear at the top level of an insn pattern. 20772 20773 When constructing an insn, operand number N will be substituted at 20774 this point. When matching an insn, it matches if the body of the 20775 insn is a 'parallel' expression with at least as many elements as 20776 the vector of SUBPAT expressions in the 'match_parallel', if each 20777 SUBPAT matches the corresponding element of the 'parallel', _and_ 20778 the function PREDICATE returns nonzero on the 'parallel' that is 20779 the body of the insn. It is the responsibility of the predicate to 20780 validate elements of the 'parallel' beyond those listed in the 20781 'match_parallel'. 20782 20783 A typical use of 'match_parallel' is to match load and store 20784 multiple expressions, which can contain a variable number of 20785 elements in a 'parallel'. For example, 20786 20787 (define_insn "" 20788 [(match_parallel 0 "load_multiple_operation" 20789 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 20790 (match_operand:SI 2 "memory_operand" "m")) 20791 (use (reg:SI 179)) 20792 (clobber (reg:SI 179))])] 20793 "" 20794 "loadm 0,0,%1,%2") 20795 20796 This example comes from 'a29k.md'. The function 20797 'load_multiple_operation' is defined in 'a29k.c' and checks that 20798 subsequent elements in the 'parallel' are the same as the 'set' in 20799 the pattern, except that they are referencing subsequent registers 20800 and memory locations. 20801 20802 An insn that matches this pattern might look like: 20803 20804 (parallel 20805 [(set (reg:SI 20) (mem:SI (reg:SI 100))) 20806 (use (reg:SI 179)) 20807 (clobber (reg:SI 179)) 20808 (set (reg:SI 21) 20809 (mem:SI (plus:SI (reg:SI 100) 20810 (const_int 4)))) 20811 (set (reg:SI 22) 20812 (mem:SI (plus:SI (reg:SI 100) 20813 (const_int 8))))]) 20814 20815'(match_par_dup N [SUBPAT...])' 20816 Like 'match_op_dup', but for 'match_parallel' instead of 20817 'match_operator'. 20818 20819 20820File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc 20821 2082217.5 Output Templates and Operand Substitution 20823============================================== 20824 20825The "output template" is a string which specifies how to output the 20826assembler code for an instruction pattern. Most of the template is a 20827fixed string which is output literally. The character '%' is used to 20828specify where to substitute an operand; it can also be used to identify 20829places where different variants of the assembler require different 20830syntax. 20831 20832 In the simplest case, a '%' followed by a digit N says to output 20833operand N at that point in the string. 20834 20835 '%' followed by a letter and a digit says to output an operand in an 20836alternate fashion. Four letters have standard, built-in meanings 20837described below. The machine description macro 'PRINT_OPERAND' can 20838define additional letters with nonstandard meanings. 20839 20840 '%cDIGIT' can be used to substitute an operand that is a constant value 20841without the syntax that normally indicates an immediate operand. 20842 20843 '%nDIGIT' is like '%cDIGIT' except that the value of the constant is 20844negated before printing. 20845 20846 '%aDIGIT' can be used to substitute an operand as if it were a memory 20847reference, with the actual operand treated as the address. This may be 20848useful when outputting a "load address" instruction, because often the 20849assembler syntax for such an instruction requires you to write the 20850operand as if it were a memory reference. 20851 20852 '%lDIGIT' is used to substitute a 'label_ref' into a jump instruction. 20853 20854 '%=' outputs a number which is unique to each instruction in the entire 20855compilation. This is useful for making local labels to be referred to 20856more than once in a single template that generates multiple assembler 20857instructions. 20858 20859 '%' followed by a punctuation character specifies a substitution that 20860does not use an operand. Only one case is standard: '%%' outputs a '%' 20861into the assembler code. Other nonstandard cases can be defined in the 20862'PRINT_OPERAND' macro. You must also define which punctuation 20863characters are valid with the 'PRINT_OPERAND_PUNCT_VALID_P' macro. 20864 20865 The template may generate multiple assembler instructions. Write the 20866text for the instructions, with '\;' between them. 20867 20868 When the RTL contains two operands which are required by constraint to 20869match each other, the output template must refer only to the 20870lower-numbered operand. Matching operands are not always identical, and 20871the rest of the compiler arranges to put the proper RTL expression for 20872printing into the lower-numbered operand. 20873 20874 One use of nonstandard letters or punctuation following '%' is to 20875distinguish between different assembler languages for the same machine; 20876for example, Motorola syntax versus MIT syntax for the 68000. Motorola 20877syntax requires periods in most opcode names, while MIT syntax does not. 20878For example, the opcode 'movel' in MIT syntax is 'move.l' in Motorola 20879syntax. The same file of patterns is used for both kinds of output 20880syntax, but the character sequence '%.' is used in each place where 20881Motorola syntax wants a period. The 'PRINT_OPERAND' macro for Motorola 20882syntax defines the sequence to output a period; the macro for MIT syntax 20883defines it to do nothing. 20884 20885 As a special case, a template consisting of the single character '#' 20886instructs the compiler to first split the insn, and then output the 20887resulting instructions separately. This helps eliminate redundancy in 20888the output templates. If you have a 'define_insn' that needs to emit 20889multiple assembler instructions, and there is a matching 'define_split' 20890already defined, then you can simply use '#' as the output template 20891instead of writing an output template that emits the multiple assembler 20892instructions. 20893 20894 Note that '#' only has an effect while generating assembly code; it 20895does not affect whether a split occurs earlier. An associated 20896'define_split' must exist and it must be suitable for use after register 20897allocation. 20898 20899 If the macro 'ASSEMBLER_DIALECT' is defined, you can use construct of 20900the form '{option0|option1|option2}' in the templates. These describe 20901multiple variants of assembler language syntax. *Note Instruction 20902Output::. 20903 20904 20905File: gccint.info, Node: Output Statement, Next: Predicates, Prev: Output Template, Up: Machine Desc 20906 2090717.6 C Statements for Assembler Output 20908====================================== 20909 20910Often a single fixed template string cannot produce correct and 20911efficient assembler code for all the cases that are recognized by a 20912single instruction pattern. For example, the opcodes may depend on the 20913kinds of operands; or some unfortunate combinations of operands may 20914require extra machine instructions. 20915 20916 If the output control string starts with a '@', then it is actually a 20917series of templates, each on a separate line. (Blank lines and leading 20918spaces and tabs are ignored.) The templates correspond to the pattern's 20919constraint alternatives (*note Multi-Alternative::). For example, if a 20920target machine has a two-address add instruction 'addr' to add into a 20921register and another 'addm' to add a register to memory, you might write 20922this pattern: 20923 20924 (define_insn "addsi3" 20925 [(set (match_operand:SI 0 "general_operand" "=r,m") 20926 (plus:SI (match_operand:SI 1 "general_operand" "0,0") 20927 (match_operand:SI 2 "general_operand" "g,r")))] 20928 "" 20929 "@ 20930 addr %2,%0 20931 addm %2,%0") 20932 20933 If the output control string starts with a '*', then it is not an 20934output template but rather a piece of C program that should compute a 20935template. It should execute a 'return' statement to return the 20936template-string you want. Most such templates use C string literals, 20937which require doublequote characters to delimit them. To include these 20938doublequote characters in the string, prefix each one with '\'. 20939 20940 If the output control string is written as a brace block instead of a 20941double-quoted string, it is automatically assumed to be C code. In that 20942case, it is not necessary to put in a leading asterisk, or to escape the 20943doublequotes surrounding C string literals. 20944 20945 The operands may be found in the array 'operands', whose C data type is 20946'rtx []'. 20947 20948 It is very common to select different ways of generating assembler code 20949based on whether an immediate operand is within a certain range. Be 20950careful when doing this, because the result of 'INTVAL' is an integer on 20951the host machine. If the host machine has more bits in an 'int' than 20952the target machine has in the mode in which the constant will be used, 20953then some of the bits you get from 'INTVAL' will be superfluous. For 20954proper results, you must carefully disregard the values of those bits. 20955 20956 It is possible to output an assembler instruction and then go on to 20957output or compute more of them, using the subroutine 'output_asm_insn'. 20958This receives two arguments: a template-string and a vector of operands. 20959The vector may be 'operands', or it may be another array of 'rtx' that 20960you declare locally and initialize yourself. 20961 20962 When an insn pattern has multiple alternatives in its constraints, 20963often the appearance of the assembler code is determined mostly by which 20964alternative was matched. When this is so, the C code can test the 20965variable 'which_alternative', which is the ordinal number of the 20966alternative that was actually satisfied (0 for the first, 1 for the 20967second alternative, etc.). 20968 20969 For example, suppose there are two opcodes for storing zero, 'clrreg' 20970for registers and 'clrmem' for memory locations. Here is how a pattern 20971could use 'which_alternative' to choose between them: 20972 20973 (define_insn "" 20974 [(set (match_operand:SI 0 "general_operand" "=r,m") 20975 (const_int 0))] 20976 "" 20977 { 20978 return (which_alternative == 0 20979 ? "clrreg %0" : "clrmem %0"); 20980 }) 20981 20982 The example above, where the assembler code to generate was _solely_ 20983determined by the alternative, could also have been specified as 20984follows, having the output control string start with a '@': 20985 20986 (define_insn "" 20987 [(set (match_operand:SI 0 "general_operand" "=r,m") 20988 (const_int 0))] 20989 "" 20990 "@ 20991 clrreg %0 20992 clrmem %0") 20993 20994 If you just need a little bit of C code in one (or a few) alternatives, 20995you can use '*' inside of a '@' multi-alternative template: 20996 20997 (define_insn "" 20998 [(set (match_operand:SI 0 "general_operand" "=r,<,m") 20999 (const_int 0))] 21000 "" 21001 "@ 21002 clrreg %0 21003 * return stack_mem_p (operands[0]) ? \"push 0\" : \"clrmem %0\"; 21004 clrmem %0") 21005 21006 21007File: gccint.info, Node: Predicates, Next: Constraints, Prev: Output Statement, Up: Machine Desc 21008 2100917.7 Predicates 21010=============== 21011 21012A predicate determines whether a 'match_operand' or 'match_operator' 21013expression matches, and therefore whether the surrounding instruction 21014pattern will be used for that combination of operands. GCC has a number 21015of machine-independent predicates, and you can define machine-specific 21016predicates as needed. By convention, predicates used with 21017'match_operand' have names that end in '_operand', and those used with 21018'match_operator' have names that end in '_operator'. 21019 21020 All predicates are boolean functions (in the mathematical sense) of two 21021arguments: the RTL expression that is being considered at that position 21022in the instruction pattern, and the machine mode that the 21023'match_operand' or 'match_operator' specifies. In this section, the 21024first argument is called OP and the second argument MODE. Predicates 21025can be called from C as ordinary two-argument functions; this can be 21026useful in output templates or other machine-specific code. 21027 21028 Operand predicates can allow operands that are not actually acceptable 21029to the hardware, as long as the constraints give reload the ability to 21030fix them up (*note Constraints::). However, GCC will usually generate 21031better code if the predicates specify the requirements of the machine 21032instructions as closely as possible. Reload cannot fix up operands that 21033must be constants ("immediate operands"); you must use a predicate that 21034allows only constants, or else enforce the requirement in the extra 21035condition. 21036 21037 Most predicates handle their MODE argument in a uniform manner. If 21038MODE is 'VOIDmode' (unspecified), then OP can have any mode. If MODE is 21039anything else, then OP must have the same mode, unless OP is a 21040'CONST_INT' or integer 'CONST_DOUBLE'. These RTL expressions always 21041have 'VOIDmode', so it would be counterproductive to check that their 21042mode matches. Instead, predicates that accept 'CONST_INT' and/or 21043integer 'CONST_DOUBLE' check that the value stored in the constant will 21044fit in the requested mode. 21045 21046 Predicates with this behavior are called "normal". 'genrecog' can 21047optimize the instruction recognizer based on knowledge of how normal 21048predicates treat modes. It can also diagnose certain kinds of common 21049errors in the use of normal predicates; for instance, it is almost 21050always an error to use a normal predicate without specifying a mode. 21051 21052 Predicates that do something different with their MODE argument are 21053called "special". The generic predicates 'address_operand' and 21054'pmode_register_operand' are special predicates. 'genrecog' does not do 21055any optimizations or diagnosis when special predicates are used. 21056 21057* Menu: 21058 21059* Machine-Independent Predicates:: Predicates available to all back ends. 21060* Defining Predicates:: How to write machine-specific predicate 21061 functions. 21062 21063 21064File: gccint.info, Node: Machine-Independent Predicates, Next: Defining Predicates, Up: Predicates 21065 2106617.7.1 Machine-Independent Predicates 21067------------------------------------- 21068 21069These are the generic predicates available to all back ends. They are 21070defined in 'recog.c'. The first category of predicates allow only 21071constant, or "immediate", operands. 21072 21073 -- Function: immediate_operand 21074 This predicate allows any sort of constant that fits in MODE. It 21075 is an appropriate choice for instructions that take operands that 21076 must be constant. 21077 21078 -- Function: const_int_operand 21079 This predicate allows any 'CONST_INT' expression that fits in MODE. 21080 It is an appropriate choice for an immediate operand that does not 21081 allow a symbol or label. 21082 21083 -- Function: const_double_operand 21084 This predicate accepts any 'CONST_DOUBLE' expression that has 21085 exactly MODE. If MODE is 'VOIDmode', it will also accept 21086 'CONST_INT'. It is intended for immediate floating point 21087 constants. 21088 21089The second category of predicates allow only some kind of machine 21090register. 21091 21092 -- Function: register_operand 21093 This predicate allows any 'REG' or 'SUBREG' expression that is 21094 valid for MODE. It is often suitable for arithmetic instruction 21095 operands on a RISC machine. 21096 21097 -- Function: pmode_register_operand 21098 This is a slight variant on 'register_operand' which works around a 21099 limitation in the machine-description reader. 21100 21101 (match_operand N "pmode_register_operand" CONSTRAINT) 21102 21103 means exactly what 21104 21105 (match_operand:P N "register_operand" CONSTRAINT) 21106 21107 would mean, if the machine-description reader accepted ':P' mode 21108 suffixes. Unfortunately, it cannot, because 'Pmode' is an alias 21109 for some other mode, and might vary with machine-specific options. 21110 *Note Misc::. 21111 21112 -- Function: scratch_operand 21113 This predicate allows hard registers and 'SCRATCH' expressions, but 21114 not pseudo-registers. It is used internally by 'match_scratch'; it 21115 should not be used directly. 21116 21117The third category of predicates allow only some kind of memory 21118reference. 21119 21120 -- Function: memory_operand 21121 This predicate allows any valid reference to a quantity of mode 21122 MODE in memory, as determined by the weak form of 21123 'GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::). 21124 21125 -- Function: address_operand 21126 This predicate is a little unusual; it allows any operand that is a 21127 valid expression for the _address_ of a quantity of mode MODE, 21128 again determined by the weak form of 'GO_IF_LEGITIMATE_ADDRESS'. 21129 To first order, if '(mem:MODE (EXP))' is acceptable to 21130 'memory_operand', then EXP is acceptable to 'address_operand'. 21131 Note that EXP does not necessarily have the mode MODE. 21132 21133 -- Function: indirect_operand 21134 This is a stricter form of 'memory_operand' which allows only 21135 memory references with a 'general_operand' as the address 21136 expression. New uses of this predicate are discouraged, because 21137 'general_operand' is very permissive, so it's hard to tell what an 21138 'indirect_operand' does or does not allow. If a target has 21139 different requirements for memory operands for different 21140 instructions, it is better to define target-specific predicates 21141 which enforce the hardware's requirements explicitly. 21142 21143 -- Function: push_operand 21144 This predicate allows a memory reference suitable for pushing a 21145 value onto the stack. This will be a 'MEM' which refers to 21146 'stack_pointer_rtx', with a side effect in its address expression 21147 (*note Incdec::); which one is determined by the 'STACK_PUSH_CODE' 21148 macro (*note Frame Layout::). 21149 21150 -- Function: pop_operand 21151 This predicate allows a memory reference suitable for popping a 21152 value off the stack. Again, this will be a 'MEM' referring to 21153 'stack_pointer_rtx', with a side effect in its address expression. 21154 However, this time 'STACK_POP_CODE' is expected. 21155 21156The fourth category of predicates allow some combination of the above 21157operands. 21158 21159 -- Function: nonmemory_operand 21160 This predicate allows any immediate or register operand valid for 21161 MODE. 21162 21163 -- Function: nonimmediate_operand 21164 This predicate allows any register or memory operand valid for 21165 MODE. 21166 21167 -- Function: general_operand 21168 This predicate allows any immediate, register, or memory operand 21169 valid for MODE. 21170 21171Finally, there are two generic operator predicates. 21172 21173 -- Function: comparison_operator 21174 This predicate matches any expression which performs an arithmetic 21175 comparison in MODE; that is, 'COMPARISON_P' is true for the 21176 expression code. 21177 21178 -- Function: ordered_comparison_operator 21179 This predicate matches any expression which performs an arithmetic 21180 comparison in MODE and whose expression code is valid for integer 21181 modes; that is, the expression code will be one of 'eq', 'ne', 21182 'lt', 'ltu', 'le', 'leu', 'gt', 'gtu', 'ge', 'geu'. 21183 21184 21185File: gccint.info, Node: Defining Predicates, Prev: Machine-Independent Predicates, Up: Predicates 21186 2118717.7.2 Defining Machine-Specific Predicates 21188------------------------------------------- 21189 21190Many machines have requirements for their operands that cannot be 21191expressed precisely using the generic predicates. You can define 21192additional predicates using 'define_predicate' and 21193'define_special_predicate' expressions. These expressions have three 21194operands: 21195 21196 * The name of the predicate, as it will be referred to in 21197 'match_operand' or 'match_operator' expressions. 21198 21199 * An RTL expression which evaluates to true if the predicate allows 21200 the operand OP, false if it does not. This expression can only use 21201 the following RTL codes: 21202 21203 'MATCH_OPERAND' 21204 When written inside a predicate expression, a 'MATCH_OPERAND' 21205 expression evaluates to true if the predicate it names would 21206 allow OP. The operand number and constraint are ignored. Due 21207 to limitations in 'genrecog', you can only refer to generic 21208 predicates and predicates that have already been defined. 21209 21210 'MATCH_CODE' 21211 This expression evaluates to true if OP or a specified 21212 subexpression of OP has one of a given list of RTX codes. 21213 21214 The first operand of this expression is a string constant 21215 containing a comma-separated list of RTX code names (in lower 21216 case). These are the codes for which the 'MATCH_CODE' will be 21217 true. 21218 21219 The second operand is a string constant which indicates what 21220 subexpression of OP to examine. If it is absent or the empty 21221 string, OP itself is examined. Otherwise, the string constant 21222 must be a sequence of digits and/or lowercase letters. Each 21223 character indicates a subexpression to extract from the 21224 current expression; for the first character this is OP, for 21225 the second and subsequent characters it is the result of the 21226 previous character. A digit N extracts 'XEXP (E, N)'; a 21227 letter L extracts 'XVECEXP (E, 0, N)' where N is the 21228 alphabetic ordinal of L (0 for 'a', 1 for 'b', and so on). 21229 The 'MATCH_CODE' then examines the RTX code of the 21230 subexpression extracted by the complete string. It is not 21231 possible to extract components of an 'rtvec' that is not at 21232 position 0 within its RTX object. 21233 21234 'MATCH_TEST' 21235 This expression has one operand, a string constant containing 21236 a C expression. The predicate's arguments, OP and MODE, are 21237 available with those names in the C expression. The 21238 'MATCH_TEST' evaluates to true if the C expression evaluates 21239 to a nonzero value. 'MATCH_TEST' expressions must not have 21240 side effects. 21241 21242 'AND' 21243 'IOR' 21244 'NOT' 21245 'IF_THEN_ELSE' 21246 The basic 'MATCH_' expressions can be combined using these 21247 logical operators, which have the semantics of the C operators 21248 '&&', '||', '!', and '? :' respectively. As in Common Lisp, 21249 you may give an 'AND' or 'IOR' expression an arbitrary number 21250 of arguments; this has exactly the same effect as writing a 21251 chain of two-argument 'AND' or 'IOR' expressions. 21252 21253 * An optional block of C code, which should execute 'return true' if 21254 the predicate is found to match and 'return false' if it does not. 21255 It must not have any side effects. The predicate arguments, OP and 21256 MODE, are available with those names. 21257 21258 If a code block is present in a predicate definition, then the RTL 21259 expression must evaluate to true _and_ the code block must execute 21260 'return true' for the predicate to allow the operand. The RTL 21261 expression is evaluated first; do not re-check anything in the code 21262 block that was checked in the RTL expression. 21263 21264 The program 'genrecog' scans 'define_predicate' and 21265'define_special_predicate' expressions to determine which RTX codes are 21266possibly allowed. You should always make this explicit in the RTL 21267predicate expression, using 'MATCH_OPERAND' and 'MATCH_CODE'. 21268 21269 Here is an example of a simple predicate definition, from the IA64 21270machine description: 21271 21272 ;; True if OP is a 'SYMBOL_REF' which refers to the sdata section. 21273 (define_predicate "small_addr_symbolic_operand" 21274 (and (match_code "symbol_ref") 21275 (match_test "SYMBOL_REF_SMALL_ADDR_P (op)"))) 21276 21277And here is another, showing the use of the C block. 21278 21279 ;; True if OP is a register operand that is (or could be) a GR reg. 21280 (define_predicate "gr_register_operand" 21281 (match_operand 0 "register_operand") 21282 { 21283 unsigned int regno; 21284 if (GET_CODE (op) == SUBREG) 21285 op = SUBREG_REG (op); 21286 21287 regno = REGNO (op); 21288 return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno)); 21289 }) 21290 21291 Predicates written with 'define_predicate' automatically include a test 21292that MODE is 'VOIDmode', or OP has the same mode as MODE, or OP is a 21293'CONST_INT' or 'CONST_DOUBLE'. They do _not_ check specifically for 21294integer 'CONST_DOUBLE', nor do they test that the value of either kind 21295of constant fits in the requested mode. This is because target-specific 21296predicates that take constants usually have to do more stringent value 21297checks anyway. If you need the exact same treatment of 'CONST_INT' or 21298'CONST_DOUBLE' that the generic predicates provide, use a 21299'MATCH_OPERAND' subexpression to call 'const_int_operand', 21300'const_double_operand', or 'immediate_operand'. 21301 21302 Predicates written with 'define_special_predicate' do not get any 21303automatic mode checks, and are treated as having special mode handling 21304by 'genrecog'. 21305 21306 The program 'genpreds' is responsible for generating code to test 21307predicates. It also writes a header file containing function 21308declarations for all machine-specific predicates. It is not necessary 21309to declare these predicates in 'CPU-protos.h'. 21310 21311 21312File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Predicates, Up: Machine Desc 21313 2131417.8 Operand Constraints 21315======================== 21316 21317Each 'match_operand' in an instruction pattern can specify constraints 21318for the operands allowed. The constraints allow you to fine-tune 21319matching within the set of operands allowed by the predicate. 21320 21321 Constraints can say whether an operand may be in a register, and which 21322kinds of register; whether the operand can be a memory reference, and 21323which kinds of address; whether the operand may be an immediate 21324constant, and which possible values it may have. Constraints can also 21325require two operands to match. Side-effects aren't allowed in operands 21326of inline 'asm', unless '<' or '>' constraints are used, because there 21327is no guarantee that the side effects will happen exactly once in an 21328instruction that can update the addressing register. 21329 21330* Menu: 21331 21332* Simple Constraints:: Basic use of constraints. 21333* Multi-Alternative:: When an insn has two alternative constraint-patterns. 21334* Class Preferences:: Constraints guide which hard register to put things in. 21335* Modifiers:: More precise control over effects of constraints. 21336* Machine Constraints:: Existing constraints for some particular machines. 21337* Disable Insn Alternatives:: Disable insn alternatives using attributes. 21338* Define Constraints:: How to define machine-specific constraints. 21339* C Constraint Interface:: How to test constraints from C code. 21340 21341 21342File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints 21343 2134417.8.1 Simple Constraints 21345------------------------- 21346 21347The simplest kind of constraint is a string full of letters, each of 21348which describes one kind of operand that is permitted. Here are the 21349letters that are allowed: 21350 21351whitespace 21352 Whitespace characters are ignored and can be inserted at any 21353 position except the first. This enables each alternative for 21354 different operands to be visually aligned in the machine 21355 description even if they have different number of constraints and 21356 modifiers. 21357 21358'm' 21359 A memory operand is allowed, with any kind of address that the 21360 machine supports in general. Note that the letter used for the 21361 general memory constraint can be re-defined by a back end using the 21362 'TARGET_MEM_CONSTRAINT' macro. 21363 21364'o' 21365 A memory operand is allowed, but only if the address is 21366 "offsettable". This means that adding a small integer (actually, 21367 the width in bytes of the operand, as determined by its machine 21368 mode) may be added to the address and the result is also a valid 21369 memory address. 21370 21371 For example, an address which is constant is offsettable; so is an 21372 address that is the sum of a register and a constant (as long as a 21373 slightly larger constant is also within the range of 21374 address-offsets supported by the machine); but an autoincrement or 21375 autodecrement address is not offsettable. More complicated 21376 indirect/indexed addresses may or may not be offsettable depending 21377 on the other addressing modes that the machine supports. 21378 21379 Note that in an output operand which can be matched by another 21380 operand, the constraint letter 'o' is valid only when accompanied 21381 by both '<' (if the target machine has predecrement addressing) and 21382 '>' (if the target machine has preincrement addressing). 21383 21384'V' 21385 A memory operand that is not offsettable. In other words, anything 21386 that would fit the 'm' constraint but not the 'o' constraint. 21387 21388'<' 21389 A memory operand with autodecrement addressing (either predecrement 21390 or postdecrement) is allowed. In inline 'asm' this constraint is 21391 only allowed if the operand is used exactly once in an instruction 21392 that can handle the side effects. Not using an operand with '<' in 21393 constraint string in the inline 'asm' pattern at all or using it in 21394 multiple instructions isn't valid, because the side effects 21395 wouldn't be performed or would be performed more than once. 21396 Furthermore, on some targets the operand with '<' in constraint 21397 string must be accompanied by special instruction suffixes like 21398 '%U0' instruction suffix on PowerPC or '%P0' on IA-64. 21399 21400'>' 21401 A memory operand with autoincrement addressing (either preincrement 21402 or postincrement) is allowed. In inline 'asm' the same 21403 restrictions as for '<' apply. 21404 21405'r' 21406 A register operand is allowed provided that it is in a general 21407 register. 21408 21409'i' 21410 An immediate integer operand (one with constant value) is allowed. 21411 This includes symbolic constants whose values will be known only at 21412 assembly time or later. 21413 21414'n' 21415 An immediate integer operand with a known numeric value is allowed. 21416 Many systems cannot support assembly-time constants for operands 21417 less than a word wide. Constraints for these operands should use 21418 'n' rather than 'i'. 21419 21420'I', 'J', 'K', ... 'P' 21421 Other letters in the range 'I' through 'P' may be defined in a 21422 machine-dependent fashion to permit immediate integer operands with 21423 explicit integer values in specified ranges. For example, on the 21424 68000, 'I' is defined to stand for the range of values 1 to 8. 21425 This is the range permitted as a shift count in the shift 21426 instructions. 21427 21428'E' 21429 An immediate floating operand (expression code 'const_double') is 21430 allowed, but only if the target floating point format is the same 21431 as that of the host machine (on which the compiler is running). 21432 21433'F' 21434 An immediate floating operand (expression code 'const_double' or 21435 'const_vector') is allowed. 21436 21437'G', 'H' 21438 'G' and 'H' may be defined in a machine-dependent fashion to permit 21439 immediate floating operands in particular ranges of values. 21440 21441's' 21442 An immediate integer operand whose value is not an explicit integer 21443 is allowed. 21444 21445 This might appear strange; if an insn allows a constant operand 21446 with a value not known at compile time, it certainly must allow any 21447 known value. So why use 's' instead of 'i'? Sometimes it allows 21448 better code to be generated. 21449 21450 For example, on the 68000 in a fullword instruction it is possible 21451 to use an immediate operand; but if the immediate value is between 21452 -128 and 127, better code results from loading the value into a 21453 register and using the register. This is because the load into the 21454 register can be done with a 'moveq' instruction. We arrange for 21455 this to happen by defining the letter 'K' to mean "any integer 21456 outside the range -128 to 127", and then specifying 'Ks' in the 21457 operand constraints. 21458 21459'g' 21460 Any register, memory or immediate integer operand is allowed, 21461 except for registers that are not general registers. 21462 21463'X' 21464 Any operand whatsoever is allowed, even if it does not satisfy 21465 'general_operand'. This is normally used in the constraint of a 21466 'match_scratch' when certain alternatives will not actually require 21467 a scratch register. 21468 21469'0', '1', '2', ... '9' 21470 An operand that matches the specified operand number is allowed. 21471 If a digit is used together with letters within the same 21472 alternative, the digit should come last. 21473 21474 This number is allowed to be more than a single digit. If multiple 21475 digits are encountered consecutively, they are interpreted as a 21476 single decimal integer. There is scant chance for ambiguity, since 21477 to-date it has never been desirable that '10' be interpreted as 21478 matching either operand 1 _or_ operand 0. Should this be desired, 21479 one can use multiple alternatives instead. 21480 21481 This is called a "matching constraint" and what it really means is 21482 that the assembler has only a single operand that fills two roles 21483 considered separate in the RTL insn. For example, an add insn has 21484 two input operands and one output operand in the RTL, but on most 21485 CISC machines an add instruction really has only two operands, one 21486 of them an input-output operand: 21487 21488 addl #35,r12 21489 21490 Matching constraints are used in these circumstances. More 21491 precisely, the two operands that match must include one input-only 21492 operand and one output-only operand. Moreover, the digit must be a 21493 smaller number than the number of the operand that uses it in the 21494 constraint. 21495 21496 For operands to match in a particular case usually means that they 21497 are identical-looking RTL expressions. But in a few special cases 21498 specific kinds of dissimilarity are allowed. For example, '*x' as 21499 an input operand will match '*x++' as an output operand. For 21500 proper results in such cases, the output template should always use 21501 the output-operand's number when printing the operand. 21502 21503'p' 21504 An operand that is a valid memory address is allowed. This is for 21505 "load address" and "push address" instructions. 21506 21507 'p' in the constraint must be accompanied by 'address_operand' as 21508 the predicate in the 'match_operand'. This predicate interprets 21509 the mode specified in the 'match_operand' as the mode of the memory 21510 reference for which the address would be valid. 21511 21512OTHER-LETTERS 21513 Other letters can be defined in machine-dependent fashion to stand 21514 for particular classes of registers or other arbitrary operand 21515 types. 'd', 'a' and 'f' are defined on the 68000/68020 to stand 21516 for data, address and floating point registers. 21517 21518 In order to have valid assembler code, each operand must satisfy its 21519constraint. But a failure to do so does not prevent the pattern from 21520applying to an insn. Instead, it directs the compiler to modify the 21521code so that the constraint will be satisfied. Usually this is done by 21522copying an operand into a register. 21523 21524 Contrast, therefore, the two instruction patterns that follow: 21525 21526 (define_insn "" 21527 [(set (match_operand:SI 0 "general_operand" "=r") 21528 (plus:SI (match_dup 0) 21529 (match_operand:SI 1 "general_operand" "r")))] 21530 "" 21531 "...") 21532 21533which has two operands, one of which must appear in two places, and 21534 21535 (define_insn "" 21536 [(set (match_operand:SI 0 "general_operand" "=r") 21537 (plus:SI (match_operand:SI 1 "general_operand" "0") 21538 (match_operand:SI 2 "general_operand" "r")))] 21539 "" 21540 "...") 21541 21542which has three operands, two of which are required by a constraint to 21543be identical. If we are considering an insn of the form 21544 21545 (insn N PREV NEXT 21546 (set (reg:SI 3) 21547 (plus:SI (reg:SI 6) (reg:SI 109))) 21548 ...) 21549 21550the first pattern would not apply at all, because this insn does not 21551contain two identical subexpressions in the right place. The pattern 21552would say, "That does not look like an add instruction; try other 21553patterns". The second pattern would say, "Yes, that's an add 21554instruction, but there is something wrong with it". It would direct the 21555reload pass of the compiler to generate additional insns to make the 21556constraint true. The results might look like this: 21557 21558 (insn N2 PREV N 21559 (set (reg:SI 3) (reg:SI 6)) 21560 ...) 21561 21562 (insn N N2 NEXT 21563 (set (reg:SI 3) 21564 (plus:SI (reg:SI 3) (reg:SI 109))) 21565 ...) 21566 21567 It is up to you to make sure that each operand, in each pattern, has 21568constraints that can handle any RTL expression that could be present for 21569that operand. (When multiple alternatives are in use, each pattern 21570must, for each possible combination of operand expressions, have at 21571least one alternative which can handle that combination of operands.) 21572The constraints don't need to _allow_ any possible operand--when this is 21573the case, they do not constrain--but they must at least point the way to 21574reloading any possible operand so that it will fit. 21575 21576 * If the constraint accepts whatever operands the predicate permits, 21577 there is no problem: reloading is never necessary for this operand. 21578 21579 For example, an operand whose constraints permit everything except 21580 registers is safe provided its predicate rejects registers. 21581 21582 An operand whose predicate accepts only constant values is safe 21583 provided its constraints include the letter 'i'. If any possible 21584 constant value is accepted, then nothing less than 'i' will do; if 21585 the predicate is more selective, then the constraints may also be 21586 more selective. 21587 21588 * Any operand expression can be reloaded by copying it into a 21589 register. So if an operand's constraints allow some kind of 21590 register, it is certain to be safe. It need not permit all classes 21591 of registers; the compiler knows how to copy a register into 21592 another register of the proper class in order to make an 21593 instruction valid. 21594 21595 * A nonoffsettable memory reference can be reloaded by copying the 21596 address into a register. So if the constraint uses the letter 'o', 21597 all memory references are taken care of. 21598 21599 * A constant operand can be reloaded by allocating space in memory to 21600 hold it as preinitialized data. Then the memory reference can be 21601 used in place of the constant. So if the constraint uses the 21602 letters 'o' or 'm', constant operands are not a problem. 21603 21604 * If the constraint permits a constant and a pseudo register used in 21605 an insn was not allocated to a hard register and is equivalent to a 21606 constant, the register will be replaced with the constant. If the 21607 predicate does not permit a constant and the insn is re-recognized 21608 for some reason, the compiler will crash. Thus the predicate must 21609 always recognize any objects allowed by the constraint. 21610 21611 If the operand's predicate can recognize registers, but the constraint 21612does not permit them, it can make the compiler crash. When this operand 21613happens to be a register, the reload pass will be stymied, because it 21614does not know how to copy a register temporarily into memory. 21615 21616 If the predicate accepts a unary operator, the constraint applies to 21617the operand. For example, the MIPS processor at ISA level 3 supports an 21618instruction which adds two registers in 'SImode' to produce a 'DImode' 21619result, but only if the registers are correctly sign extended. This 21620predicate for the input operands accepts a 'sign_extend' of an 'SImode' 21621register. Write the constraint to indicate the type of register that is 21622required for the operand of the 'sign_extend'. 21623 21624 21625File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints 21626 2162717.8.2 Multiple Alternative Constraints 21628--------------------------------------- 21629 21630Sometimes a single instruction has multiple alternative sets of possible 21631operands. For example, on the 68000, a logical-or instruction can 21632combine register or an immediate value into memory, or it can combine 21633any kind of operand into a register; but it cannot combine one memory 21634location into another. 21635 21636 These constraints are represented as multiple alternatives. An 21637alternative can be described by a series of letters for each operand. 21638The overall constraint for an operand is made from the letters for this 21639operand from the first alternative, a comma, the letters for this 21640operand from the second alternative, a comma, and so on until the last 21641alternative. All operands for a single instruction must have the same 21642number of alternatives. Here is how it is done for fullword logical-or 21643on the 68000: 21644 21645 (define_insn "iorsi3" 21646 [(set (match_operand:SI 0 "general_operand" "=m,d") 21647 (ior:SI (match_operand:SI 1 "general_operand" "%0,0") 21648 (match_operand:SI 2 "general_operand" "dKs,dmKs")))] 21649 ...) 21650 21651 The first alternative has 'm' (memory) for operand 0, '0' for operand 1 21652(meaning it must match operand 0), and 'dKs' for operand 2. The second 21653alternative has 'd' (data register) for operand 0, '0' for operand 1, 21654and 'dmKs' for operand 2. The '=' and '%' in the constraints apply to 21655all the alternatives; their meaning is explained in the next section 21656(*note Class Preferences::). 21657 21658 If all the operands fit any one alternative, the instruction is valid. 21659Otherwise, for each alternative, the compiler counts how many 21660instructions must be added to copy the operands so that that alternative 21661applies. The alternative requiring the least copying is chosen. If two 21662alternatives need the same amount of copying, the one that comes first 21663is chosen. These choices can be altered with the '?' and '!' 21664characters: 21665 21666'?' 21667 Disparage slightly the alternative that the '?' appears in, as a 21668 choice when no alternative applies exactly. The compiler regards 21669 this alternative as one unit more costly for each '?' that appears 21670 in it. 21671 21672'!' 21673 Disparage severely the alternative that the '!' appears in. This 21674 alternative can still be used if it fits without reloading, but if 21675 reloading is needed, some other alternative will be used. 21676 21677'^' 21678 This constraint is analogous to '?' but it disparages slightly the 21679 alternative only if the operand with the '^' needs a reload. 21680 21681'$' 21682 This constraint is analogous to '!' but it disparages severely the 21683 alternative only if the operand with the '$' needs a reload. 21684 21685 When an insn pattern has multiple alternatives in its constraints, 21686often the appearance of the assembler code is determined mostly by which 21687alternative was matched. When this is so, the C code for writing the 21688assembler code can use the variable 'which_alternative', which is the 21689ordinal number of the alternative that was actually satisfied (0 for the 21690first, 1 for the second alternative, etc.). *Note Output Statement::. 21691 21692 21693File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints 21694 2169517.8.3 Register Class Preferences 21696--------------------------------- 21697 21698The operand constraints have another function: they enable the compiler 21699to decide which kind of hardware register a pseudo register is best 21700allocated to. The compiler examines the constraints that apply to the 21701insns that use the pseudo register, looking for the machine-dependent 21702letters such as 'd' and 'a' that specify classes of registers. The 21703pseudo register is put in whichever class gets the most "votes". The 21704constraint letters 'g' and 'r' also vote: they vote in favor of a 21705general register. The machine description says which registers are 21706considered general. 21707 21708 Of course, on some machines all registers are equivalent, and no 21709register classes are defined. Then none of this complexity is relevant. 21710 21711 21712File: gccint.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints 21713 2171417.8.4 Constraint Modifier Characters 21715------------------------------------- 21716 21717Here are constraint modifier characters. 21718 21719'=' 21720 Means that this operand is written to by this instruction: the 21721 previous value is discarded and replaced by new data. 21722 21723'+' 21724 Means that this operand is both read and written by the 21725 instruction. 21726 21727 When the compiler fixes up the operands to satisfy the constraints, 21728 it needs to know which operands are read by the instruction and 21729 which are written by it. '=' identifies an operand which is only 21730 written; '+' identifies an operand that is both read and written; 21731 all other operands are assumed to only be read. 21732 21733 If you specify '=' or '+' in a constraint, you put it in the first 21734 character of the constraint string. 21735 21736'&' 21737 Means (in a particular alternative) that this operand is an 21738 "earlyclobber" operand, which is written before the instruction is 21739 finished using the input operands. Therefore, this operand may not 21740 lie in a register that is read by the instruction or as part of any 21741 memory address. 21742 21743 '&' applies only to the alternative in which it is written. In 21744 constraints with multiple alternatives, sometimes one alternative 21745 requires '&' while others do not. See, for example, the 'movdf' 21746 insn of the 68000. 21747 21748 A operand which is read by the instruction can be tied to an 21749 earlyclobber operand if its only use as an input occurs before the 21750 early result is written. Adding alternatives of this form often 21751 allows GCC to produce better code when only some of the read 21752 operands can be affected by the earlyclobber. See, for example, 21753 the 'mulsi3' insn of the ARM. 21754 21755 Furthermore, if the "earlyclobber" operand is also a read/write 21756 operand, then that operand is written only after it's used. 21757 21758 '&' does not obviate the need to write '=' or '+'. As 21759 "earlyclobber" operands are always written, a read-only 21760 "earlyclobber" operand is ill-formed and will be rejected by the 21761 compiler. 21762 21763'%' 21764 Declares the instruction to be commutative for this operand and the 21765 following operand. This means that the compiler may interchange 21766 the two operands if that is the cheapest way to make all operands 21767 fit the constraints. '%' applies to all alternatives and must 21768 appear as the first character in the constraint. Only read-only 21769 operands can use '%'. 21770 21771 This is often used in patterns for addition instructions that 21772 really have only two operands: the result must go in one of the 21773 arguments. Here for example, is how the 68000 halfword-add 21774 instruction is defined: 21775 21776 (define_insn "addhi3" 21777 [(set (match_operand:HI 0 "general_operand" "=m,r") 21778 (plus:HI (match_operand:HI 1 "general_operand" "%0,0") 21779 (match_operand:HI 2 "general_operand" "di,g")))] 21780 ...) 21781 GCC can only handle one commutative pair in an asm; if you use 21782 more, the compiler may fail. Note that you need not use the 21783 modifier if the two alternatives are strictly identical; this would 21784 only waste time in the reload pass. The modifier is not 21785 operational after register allocation, so the result of 21786 'define_peephole2' and 'define_split's performed after reload 21787 cannot rely on '%' to make the intended insn match. 21788 21789'#' 21790 Says that all following characters, up to the next comma, are to be 21791 ignored as a constraint. They are significant only for choosing 21792 register preferences. 21793 21794'*' 21795 Says that the following character should be ignored when choosing 21796 register preferences. '*' has no effect on the meaning of the 21797 constraint as a constraint, and no effect on reloading. For LRA 21798 '*' additionally disparages slightly the alternative if the 21799 following character matches the operand. 21800 21801 Here is an example: the 68000 has an instruction to sign-extend a 21802 halfword in a data register, and can also sign-extend a value by 21803 copying it into an address register. While either kind of register 21804 is acceptable, the constraints on an address-register destination 21805 are less strict, so it is best if register allocation makes an 21806 address register its goal. Therefore, '*' is used so that the 'd' 21807 constraint letter (for data register) is ignored when computing 21808 register preferences. 21809 21810 (define_insn "extendhisi2" 21811 [(set (match_operand:SI 0 "general_operand" "=*d,a") 21812 (sign_extend:SI 21813 (match_operand:HI 1 "general_operand" "0,g")))] 21814 ...) 21815 21816 21817File: gccint.info, Node: Machine Constraints, Next: Disable Insn Alternatives, Prev: Modifiers, Up: Constraints 21818 2181917.8.5 Constraints for Particular Machines 21820------------------------------------------ 21821 21822Whenever possible, you should use the general-purpose constraint letters 21823in 'asm' arguments, since they will convey meaning more readily to 21824people reading your code. Failing that, use the constraint letters that 21825usually have very similar meanings across architectures. The most 21826commonly used constraints are 'm' and 'r' (for memory and 21827general-purpose registers respectively; *note Simple Constraints::), and 21828'I', usually the letter indicating the most common immediate-constant 21829format. 21830 21831 Each architecture defines additional constraints. These constraints 21832are used by the compiler itself for instruction generation, as well as 21833for 'asm' statements; therefore, some of the constraints are not 21834particularly useful for 'asm'. Here is a summary of some of the 21835machine-dependent constraints available on some particular machines; it 21836includes both constraints that are useful for 'asm' and constraints that 21837aren't. The compiler source file mentioned in the table heading for 21838each architecture is the definitive reference for the meanings of that 21839architecture's constraints. 21840 21841_AArch64 family--'config/aarch64/constraints.md'_ 21842 'k' 21843 The stack pointer register ('SP') 21844 21845 'w' 21846 Floating point register, Advanced SIMD vector register or SVE 21847 vector register 21848 21849 'Upl' 21850 One of the low eight SVE predicate registers ('P0' to 'P7') 21851 21852 'Upa' 21853 Any of the SVE predicate registers ('P0' to 'P15') 21854 21855 'I' 21856 Integer constant that is valid as an immediate operand in an 21857 'ADD' instruction 21858 21859 'J' 21860 Integer constant that is valid as an immediate operand in a 21861 'SUB' instruction (once negated) 21862 21863 'K' 21864 Integer constant that can be used with a 32-bit logical 21865 instruction 21866 21867 'L' 21868 Integer constant that can be used with a 64-bit logical 21869 instruction 21870 21871 'M' 21872 Integer constant that is valid as an immediate operand in a 21873 32-bit 'MOV' pseudo instruction. The 'MOV' may be assembled 21874 to one of several different machine instructions depending on 21875 the value 21876 21877 'N' 21878 Integer constant that is valid as an immediate operand in a 21879 64-bit 'MOV' pseudo instruction 21880 21881 'S' 21882 An absolute symbolic address or a label reference 21883 21884 'Y' 21885 Floating point constant zero 21886 21887 'Z' 21888 Integer constant zero 21889 21890 'Ush' 21891 The high part (bits 12 and upwards) of the pc-relative address 21892 of a symbol within 4GB of the instruction 21893 21894 'Q' 21895 A memory address which uses a single base register with no 21896 offset 21897 21898 'Ump' 21899 A memory address suitable for a load/store pair instruction in 21900 SI, DI, SF and DF modes 21901 21902_AMD GCN --'config/gcn/constraints.md'_ 21903 'I' 21904 Immediate integer in the range -16 to 64 21905 21906 'J' 21907 Immediate 16-bit signed integer 21908 21909 'Kf' 21910 Immediate constant -1 21911 21912 'L' 21913 Immediate 15-bit unsigned integer 21914 21915 'A' 21916 Immediate constant that can be inlined in an instruction 21917 encoding: integer -16..64, or float 0.0, +/-0.5, +/-1.0, 21918 +/-2.0, +/-4.0, 1.0/(2.0*PI) 21919 21920 'B' 21921 Immediate 32-bit signed integer that can be attached to an 21922 instruction encoding 21923 21924 'C' 21925 Immediate 32-bit integer in range -16..4294967295 (i.e. 21926 32-bit unsigned integer or 'A' constraint) 21927 21928 'DA' 21929 Immediate 64-bit constant that can be split into two 'A' 21930 constants 21931 21932 'DB' 21933 Immediate 64-bit constant that can be split into two 'B' 21934 constants 21935 21936 'U' 21937 Any 'unspec' 21938 21939 'Y' 21940 Any 'symbol_ref' or 'label_ref' 21941 21942 'v' 21943 VGPR register 21944 21945 'Sg' 21946 SGPR register 21947 21948 'SD' 21949 SGPR registers valid for instruction destinations, including 21950 VCC, M0 and EXEC 21951 21952 'SS' 21953 SGPR registers valid for instruction sources, including VCC, 21954 M0, EXEC and SCC 21955 21956 'Sm' 21957 SGPR registers valid as a source for scalar memory 21958 instructions (excludes M0 and EXEC) 21959 21960 'Sv' 21961 SGPR registers valid as a source or destination for vector 21962 instructions (excludes EXEC) 21963 21964 'ca' 21965 All condition registers: SCC, VCCZ, EXECZ 21966 21967 'cs' 21968 Scalar condition register: SCC 21969 21970 'cV' 21971 Vector condition register: VCC, VCC_LO, VCC_HI 21972 21973 'e' 21974 EXEC register (EXEC_LO and EXEC_HI) 21975 21976 'RB' 21977 Memory operand with address space suitable for 'buffer_*' 21978 instructions 21979 21980 'RF' 21981 Memory operand with address space suitable for 'flat_*' 21982 instructions 21983 21984 'RS' 21985 Memory operand with address space suitable for 's_*' 21986 instructions 21987 21988 'RL' 21989 Memory operand with address space suitable for 'ds_*' LDS 21990 instructions 21991 21992 'RG' 21993 Memory operand with address space suitable for 'ds_*' GDS 21994 instructions 21995 21996 'RD' 21997 Memory operand with address space suitable for any 'ds_*' 21998 instructions 21999 22000 'RM' 22001 Memory operand with address space suitable for 'global_*' 22002 instructions 22003 22004_ARC --'config/arc/constraints.md'_ 22005 'q' 22006 Registers usable in ARCompact 16-bit instructions: 'r0'-'r3', 22007 'r12'-'r15'. This constraint can only match when the '-mq' 22008 option is in effect. 22009 22010 'e' 22011 Registers usable as base-regs of memory addresses in ARCompact 22012 16-bit memory instructions: 'r0'-'r3', 'r12'-'r15', 'sp'. 22013 This constraint can only match when the '-mq' option is in 22014 effect. 22015 'D' 22016 ARC FPX (dpfp) 64-bit registers. 'D0', 'D1'. 22017 22018 'I' 22019 A signed 12-bit integer constant. 22020 22021 'Cal' 22022 constant for arithmetic/logical operations. This might be any 22023 constant that can be put into a long immediate by the assmbler 22024 or linker without involving a PIC relocation. 22025 22026 'K' 22027 A 3-bit unsigned integer constant. 22028 22029 'L' 22030 A 6-bit unsigned integer constant. 22031 22032 'CnL' 22033 One's complement of a 6-bit unsigned integer constant. 22034 22035 'CmL' 22036 Two's complement of a 6-bit unsigned integer constant. 22037 22038 'M' 22039 A 5-bit unsigned integer constant. 22040 22041 'O' 22042 A 7-bit unsigned integer constant. 22043 22044 'P' 22045 A 8-bit unsigned integer constant. 22046 22047 'H' 22048 Any const_double value. 22049 22050_ARM family--'config/arm/constraints.md'_ 22051 22052 'h' 22053 In Thumb state, the core registers 'r8'-'r15'. 22054 22055 'k' 22056 The stack pointer register. 22057 22058 'l' 22059 In Thumb State the core registers 'r0'-'r7'. In ARM state 22060 this is an alias for the 'r' constraint. 22061 22062 't' 22063 VFP floating-point registers 's0'-'s31'. Used for 32 bit 22064 values. 22065 22066 'w' 22067 VFP floating-point registers 'd0'-'d31' and the appropriate 22068 subset 'd0'-'d15' based on command line options. Used for 64 22069 bit values only. Not valid for Thumb1. 22070 22071 'y' 22072 The iWMMX co-processor registers. 22073 22074 'z' 22075 The iWMMX GR registers. 22076 22077 'G' 22078 The floating-point constant 0.0 22079 22080 'I' 22081 Integer that is valid as an immediate operand in a data 22082 processing instruction. That is, an integer in the range 0 to 22083 255 rotated by a multiple of 2 22084 22085 'J' 22086 Integer in the range -4095 to 4095 22087 22088 'K' 22089 Integer that satisfies constraint 'I' when inverted (ones 22090 complement) 22091 22092 'L' 22093 Integer that satisfies constraint 'I' when negated (twos 22094 complement) 22095 22096 'M' 22097 Integer in the range 0 to 32 22098 22099 'Q' 22100 A memory reference where the exact address is in a single 22101 register (''m'' is preferable for 'asm' statements) 22102 22103 'R' 22104 An item in the constant pool 22105 22106 'S' 22107 A symbol in the text segment of the current file 22108 22109 'Uv' 22110 A memory reference suitable for VFP load/store insns 22111 (reg+constant offset) 22112 22113 'Uy' 22114 A memory reference suitable for iWMMXt load/store 22115 instructions. 22116 22117 'Uq' 22118 A memory reference suitable for the ARMv4 ldrsb instruction. 22119 22120_AVR family--'config/avr/constraints.md'_ 22121 'l' 22122 Registers from r0 to r15 22123 22124 'a' 22125 Registers from r16 to r23 22126 22127 'd' 22128 Registers from r16 to r31 22129 22130 'w' 22131 Registers from r24 to r31. These registers can be used in 22132 'adiw' command 22133 22134 'e' 22135 Pointer register (r26-r31) 22136 22137 'b' 22138 Base pointer register (r28-r31) 22139 22140 'q' 22141 Stack pointer register (SPH:SPL) 22142 22143 't' 22144 Temporary register r0 22145 22146 'x' 22147 Register pair X (r27:r26) 22148 22149 'y' 22150 Register pair Y (r29:r28) 22151 22152 'z' 22153 Register pair Z (r31:r30) 22154 22155 'I' 22156 Constant greater than -1, less than 64 22157 22158 'J' 22159 Constant greater than -64, less than 1 22160 22161 'K' 22162 Constant integer 2 22163 22164 'L' 22165 Constant integer 0 22166 22167 'M' 22168 Constant that fits in 8 bits 22169 22170 'N' 22171 Constant integer -1 22172 22173 'O' 22174 Constant integer 8, 16, or 24 22175 22176 'P' 22177 Constant integer 1 22178 22179 'G' 22180 A floating point constant 0.0 22181 22182 'Q' 22183 A memory address based on Y or Z pointer with displacement. 22184 22185_Blackfin family--'config/bfin/constraints.md'_ 22186 'a' 22187 P register 22188 22189 'd' 22190 D register 22191 22192 'z' 22193 A call clobbered P register. 22194 22195 'qN' 22196 A single register. If N is in the range 0 to 7, the 22197 corresponding D register. If it is 'A', then the register P0. 22198 22199 'D' 22200 Even-numbered D register 22201 22202 'W' 22203 Odd-numbered D register 22204 22205 'e' 22206 Accumulator register. 22207 22208 'A' 22209 Even-numbered accumulator register. 22210 22211 'B' 22212 Odd-numbered accumulator register. 22213 22214 'b' 22215 I register 22216 22217 'v' 22218 B register 22219 22220 'f' 22221 M register 22222 22223 'c' 22224 Registers used for circular buffering, i.e. I, B, or L 22225 registers. 22226 22227 'C' 22228 The CC register. 22229 22230 't' 22231 LT0 or LT1. 22232 22233 'k' 22234 LC0 or LC1. 22235 22236 'u' 22237 LB0 or LB1. 22238 22239 'x' 22240 Any D, P, B, M, I or L register. 22241 22242 'y' 22243 Additional registers typically used only in prologues and 22244 epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and 22245 USP. 22246 22247 'w' 22248 Any register except accumulators or CC. 22249 22250 'Ksh' 22251 Signed 16 bit integer (in the range -32768 to 32767) 22252 22253 'Kuh' 22254 Unsigned 16 bit integer (in the range 0 to 65535) 22255 22256 'Ks7' 22257 Signed 7 bit integer (in the range -64 to 63) 22258 22259 'Ku7' 22260 Unsigned 7 bit integer (in the range 0 to 127) 22261 22262 'Ku5' 22263 Unsigned 5 bit integer (in the range 0 to 31) 22264 22265 'Ks4' 22266 Signed 4 bit integer (in the range -8 to 7) 22267 22268 'Ks3' 22269 Signed 3 bit integer (in the range -3 to 4) 22270 22271 'Ku3' 22272 Unsigned 3 bit integer (in the range 0 to 7) 22273 22274 'PN' 22275 Constant N, where N is a single-digit constant in the range 0 22276 to 4. 22277 22278 'PA' 22279 An integer equal to one of the MACFLAG_XXX constants that is 22280 suitable for use with either accumulator. 22281 22282 'PB' 22283 An integer equal to one of the MACFLAG_XXX constants that is 22284 suitable for use only with accumulator A1. 22285 22286 'M1' 22287 Constant 255. 22288 22289 'M2' 22290 Constant 65535. 22291 22292 'J' 22293 An integer constant with exactly a single bit set. 22294 22295 'L' 22296 An integer constant with all bits set except exactly one. 22297 22298 'H' 22299 22300 'Q' 22301 Any SYMBOL_REF. 22302 22303_CR16 Architecture--'config/cr16/cr16.h'_ 22304 22305 'b' 22306 Registers from r0 to r14 (registers without stack pointer) 22307 22308 't' 22309 Register from r0 to r11 (all 16-bit registers) 22310 22311 'p' 22312 Register from r12 to r15 (all 32-bit registers) 22313 22314 'I' 22315 Signed constant that fits in 4 bits 22316 22317 'J' 22318 Signed constant that fits in 5 bits 22319 22320 'K' 22321 Signed constant that fits in 6 bits 22322 22323 'L' 22324 Unsigned constant that fits in 4 bits 22325 22326 'M' 22327 Signed constant that fits in 32 bits 22328 22329 'N' 22330 Check for 64 bits wide constants for add/sub instructions 22331 22332 'G' 22333 Floating point constant that is legal for store immediate 22334 22335_C-SKY--'config/csky/constraints.md'_ 22336 22337 'a' 22338 The mini registers r0 - r7. 22339 22340 'b' 22341 The low registers r0 - r15. 22342 22343 'c' 22344 C register. 22345 22346 'y' 22347 HI and LO registers. 22348 22349 'l' 22350 LO register. 22351 22352 'h' 22353 HI register. 22354 22355 'v' 22356 Vector registers. 22357 22358 'z' 22359 Stack pointer register (SP). 22360 22361 The C-SKY back end supports a large set of additional constraints 22362 that are only useful for instruction selection or splitting rather 22363 than inline asm, such as constraints representing constant integer 22364 ranges accepted by particular instruction encodings. Refer to the 22365 source code for details. 22366 22367_Epiphany--'config/epiphany/constraints.md'_ 22368 'U16' 22369 An unsigned 16-bit constant. 22370 22371 'K' 22372 An unsigned 5-bit constant. 22373 22374 'L' 22375 A signed 11-bit constant. 22376 22377 'Cm1' 22378 A signed 11-bit constant added to -1. Can only match when the 22379 '-m1reg-REG' option is active. 22380 22381 'Cl1' 22382 Left-shift of -1, i.e., a bit mask with a block of leading 22383 ones, the rest being a block of trailing zeroes. Can only 22384 match when the '-m1reg-REG' option is active. 22385 22386 'Cr1' 22387 Right-shift of -1, i.e., a bit mask with a trailing block of 22388 ones, the rest being zeroes. Or to put it another way, one 22389 less than a power of two. Can only match when the 22390 '-m1reg-REG' option is active. 22391 22392 'Cal' 22393 Constant for arithmetic/logical operations. This is like 'i', 22394 except that for position independent code, no symbols / 22395 expressions needing relocations are allowed. 22396 22397 'Csy' 22398 Symbolic constant for call/jump instruction. 22399 22400 'Rcs' 22401 The register class usable in short insns. This is a register 22402 class constraint, and can thus drive register allocation. 22403 This constraint won't match unless '-mprefer-short-insn-regs' 22404 is in effect. 22405 22406 'Rsc' 22407 The the register class of registers that can be used to hold a 22408 sibcall call address. I.e., a caller-saved register. 22409 22410 'Rct' 22411 Core control register class. 22412 22413 'Rgs' 22414 The register group usable in short insns. This constraint 22415 does not use a register class, so that it only passively 22416 matches suitable registers, and doesn't drive register 22417 allocation. 22418 22419 'Car' 22420 Constant suitable for the addsi3_r pattern. This is a valid 22421 offset For byte, halfword, or word addressing. 22422 22423 'Rra' 22424 Matches the return address if it can be replaced with the link 22425 register. 22426 22427 'Rcc' 22428 Matches the integer condition code register. 22429 22430 'Sra' 22431 Matches the return address if it is in a stack slot. 22432 22433 'Cfm' 22434 Matches control register values to switch fp mode, which are 22435 encapsulated in 'UNSPEC_FP_MODE'. 22436 22437_FRV--'config/frv/frv.h'_ 22438 'a' 22439 Register in the class 'ACC_REGS' ('acc0' to 'acc7'). 22440 22441 'b' 22442 Register in the class 'EVEN_ACC_REGS' ('acc0' to 'acc7'). 22443 22444 'c' 22445 Register in the class 'CC_REGS' ('fcc0' to 'fcc3' and 'icc0' 22446 to 'icc3'). 22447 22448 'd' 22449 Register in the class 'GPR_REGS' ('gr0' to 'gr63'). 22450 22451 'e' 22452 Register in the class 'EVEN_REGS' ('gr0' to 'gr63'). Odd 22453 registers are excluded not in the class but through the use of 22454 a machine mode larger than 4 bytes. 22455 22456 'f' 22457 Register in the class 'FPR_REGS' ('fr0' to 'fr63'). 22458 22459 'h' 22460 Register in the class 'FEVEN_REGS' ('fr0' to 'fr63'). Odd 22461 registers are excluded not in the class but through the use of 22462 a machine mode larger than 4 bytes. 22463 22464 'l' 22465 Register in the class 'LR_REG' (the 'lr' register). 22466 22467 'q' 22468 Register in the class 'QUAD_REGS' ('gr2' to 'gr63'). Register 22469 numbers not divisible by 4 are excluded not in the class but 22470 through the use of a machine mode larger than 8 bytes. 22471 22472 't' 22473 Register in the class 'ICC_REGS' ('icc0' to 'icc3'). 22474 22475 'u' 22476 Register in the class 'FCC_REGS' ('fcc0' to 'fcc3'). 22477 22478 'v' 22479 Register in the class 'ICR_REGS' ('cc4' to 'cc7'). 22480 22481 'w' 22482 Register in the class 'FCR_REGS' ('cc0' to 'cc3'). 22483 22484 'x' 22485 Register in the class 'QUAD_FPR_REGS' ('fr0' to 'fr63'). 22486 Register numbers not divisible by 4 are excluded not in the 22487 class but through the use of a machine mode larger than 8 22488 bytes. 22489 22490 'z' 22491 Register in the class 'SPR_REGS' ('lcr' and 'lr'). 22492 22493 'A' 22494 Register in the class 'QUAD_ACC_REGS' ('acc0' to 'acc7'). 22495 22496 'B' 22497 Register in the class 'ACCG_REGS' ('accg0' to 'accg7'). 22498 22499 'C' 22500 Register in the class 'CR_REGS' ('cc0' to 'cc7'). 22501 22502 'G' 22503 Floating point constant zero 22504 22505 'I' 22506 6-bit signed integer constant 22507 22508 'J' 22509 10-bit signed integer constant 22510 22511 'L' 22512 16-bit signed integer constant 22513 22514 'M' 22515 16-bit unsigned integer constant 22516 22517 'N' 22518 12-bit signed integer constant that is negative--i.e. in the 22519 range of -2048 to -1 22520 22521 'O' 22522 Constant zero 22523 22524 'P' 22525 12-bit signed integer constant that is greater than zero--i.e. 22526 in the range of 1 to 2047. 22527 22528_FT32--'config/ft32/constraints.md'_ 22529 'A' 22530 An absolute address 22531 22532 'B' 22533 An offset address 22534 22535 'W' 22536 A register indirect memory operand 22537 22538 'e' 22539 An offset address. 22540 22541 'f' 22542 An offset address. 22543 22544 'O' 22545 The constant zero or one 22546 22547 'I' 22548 A 16-bit signed constant (-32768 ... 32767) 22549 22550 'w' 22551 A bitfield mask suitable for bext or bins 22552 22553 'x' 22554 An inverted bitfield mask suitable for bext or bins 22555 22556 'L' 22557 A 16-bit unsigned constant, multiple of 4 (0 ... 65532) 22558 22559 'S' 22560 A 20-bit signed constant (-524288 ... 524287) 22561 22562 'b' 22563 A constant for a bitfield width (1 ... 16) 22564 22565 'KA' 22566 A 10-bit signed constant (-512 ... 511) 22567 22568_Hewlett-Packard PA-RISC--'config/pa/pa.h'_ 22569 'a' 22570 General register 1 22571 22572 'f' 22573 Floating point register 22574 22575 'q' 22576 Shift amount register 22577 22578 'x' 22579 Floating point register (deprecated) 22580 22581 'y' 22582 Upper floating point register (32-bit), floating point 22583 register (64-bit) 22584 22585 'Z' 22586 Any register 22587 22588 'I' 22589 Signed 11-bit integer constant 22590 22591 'J' 22592 Signed 14-bit integer constant 22593 22594 'K' 22595 Integer constant that can be deposited with a 'zdepi' 22596 instruction 22597 22598 'L' 22599 Signed 5-bit integer constant 22600 22601 'M' 22602 Integer constant 0 22603 22604 'N' 22605 Integer constant that can be loaded with a 'ldil' instruction 22606 22607 'O' 22608 Integer constant whose value plus one is a power of 2 22609 22610 'P' 22611 Integer constant that can be used for 'and' operations in 22612 'depi' and 'extru' instructions 22613 22614 'S' 22615 Integer constant 31 22616 22617 'U' 22618 Integer constant 63 22619 22620 'G' 22621 Floating-point constant 0.0 22622 22623 'A' 22624 A 'lo_sum' data-linkage-table memory operand 22625 22626 'Q' 22627 A memory operand that can be used as the destination operand 22628 of an integer store instruction 22629 22630 'R' 22631 A scaled or unscaled indexed memory operand 22632 22633 'T' 22634 A memory operand for floating-point loads and stores 22635 22636 'W' 22637 A register indirect memory operand 22638 22639_Intel IA-64--'config/ia64/ia64.h'_ 22640 'a' 22641 General register 'r0' to 'r3' for 'addl' instruction 22642 22643 'b' 22644 Branch register 22645 22646 'c' 22647 Predicate register ('c' as in "conditional") 22648 22649 'd' 22650 Application register residing in M-unit 22651 22652 'e' 22653 Application register residing in I-unit 22654 22655 'f' 22656 Floating-point register 22657 22658 'm' 22659 Memory operand. If used together with '<' or '>', the operand 22660 can have postincrement and postdecrement which require 22661 printing with '%Pn' on IA-64. 22662 22663 'G' 22664 Floating-point constant 0.0 or 1.0 22665 22666 'I' 22667 14-bit signed integer constant 22668 22669 'J' 22670 22-bit signed integer constant 22671 22672 'K' 22673 8-bit signed integer constant for logical instructions 22674 22675 'L' 22676 8-bit adjusted signed integer constant for compare pseudo-ops 22677 22678 'M' 22679 6-bit unsigned integer constant for shift counts 22680 22681 'N' 22682 9-bit signed integer constant for load and store 22683 postincrements 22684 22685 'O' 22686 The constant zero 22687 22688 'P' 22689 0 or -1 for 'dep' instruction 22690 22691 'Q' 22692 Non-volatile memory for floating-point loads and stores 22693 22694 'R' 22695 Integer constant in the range 1 to 4 for 'shladd' instruction 22696 22697 'S' 22698 Memory operand except postincrement and postdecrement. This 22699 is now roughly the same as 'm' when not used together with '<' 22700 or '>'. 22701 22702_M32C--'config/m32c/m32c.c'_ 22703 'Rsp' 22704 'Rfb' 22705 'Rsb' 22706 '$sp', '$fb', '$sb'. 22707 22708 'Rcr' 22709 Any control register, when they're 16 bits wide (nothing if 22710 control registers are 24 bits wide) 22711 22712 'Rcl' 22713 Any control register, when they're 24 bits wide. 22714 22715 'R0w' 22716 'R1w' 22717 'R2w' 22718 'R3w' 22719 $r0, $r1, $r2, $r3. 22720 22721 'R02' 22722 $r0 or $r2, or $r2r0 for 32 bit values. 22723 22724 'R13' 22725 $r1 or $r3, or $r3r1 for 32 bit values. 22726 22727 'Rdi' 22728 A register that can hold a 64 bit value. 22729 22730 'Rhl' 22731 $r0 or $r1 (registers with addressable high/low bytes) 22732 22733 'R23' 22734 $r2 or $r3 22735 22736 'Raa' 22737 Address registers 22738 22739 'Raw' 22740 Address registers when they're 16 bits wide. 22741 22742 'Ral' 22743 Address registers when they're 24 bits wide. 22744 22745 'Rqi' 22746 Registers that can hold QI values. 22747 22748 'Rad' 22749 Registers that can be used with displacements ($a0, $a1, $sb). 22750 22751 'Rsi' 22752 Registers that can hold 32 bit values. 22753 22754 'Rhi' 22755 Registers that can hold 16 bit values. 22756 22757 'Rhc' 22758 Registers chat can hold 16 bit values, including all control 22759 registers. 22760 22761 'Rra' 22762 $r0 through R1, plus $a0 and $a1. 22763 22764 'Rfl' 22765 The flags register. 22766 22767 'Rmm' 22768 The memory-based pseudo-registers $mem0 through $mem15. 22769 22770 'Rpi' 22771 Registers that can hold pointers (16 bit registers for r8c, 22772 m16c; 24 bit registers for m32cm, m32c). 22773 22774 'Rpa' 22775 Matches multiple registers in a PARALLEL to form a larger 22776 register. Used to match function return values. 22777 22778 'Is3' 22779 -8 ... 7 22780 22781 'IS1' 22782 -128 ... 127 22783 22784 'IS2' 22785 -32768 ... 32767 22786 22787 'IU2' 22788 0 ... 65535 22789 22790 'In4' 22791 -8 ... -1 or 1 ... 8 22792 22793 'In5' 22794 -16 ... -1 or 1 ... 16 22795 22796 'In6' 22797 -32 ... -1 or 1 ... 32 22798 22799 'IM2' 22800 -65536 ... -1 22801 22802 'Ilb' 22803 An 8 bit value with exactly one bit set. 22804 22805 'Ilw' 22806 A 16 bit value with exactly one bit set. 22807 22808 'Sd' 22809 The common src/dest memory addressing modes. 22810 22811 'Sa' 22812 Memory addressed using $a0 or $a1. 22813 22814 'Si' 22815 Memory addressed with immediate addresses. 22816 22817 'Ss' 22818 Memory addressed using the stack pointer ($sp). 22819 22820 'Sf' 22821 Memory addressed using the frame base register ($fb). 22822 22823 'Ss' 22824 Memory addressed using the small base register ($sb). 22825 22826 'S1' 22827 $r1h 22828 22829_MicroBlaze--'config/microblaze/constraints.md'_ 22830 'd' 22831 A general register ('r0' to 'r31'). 22832 22833 'z' 22834 A status register ('rmsr', '$fcc1' to '$fcc7'). 22835 22836_MIPS--'config/mips/constraints.md'_ 22837 'd' 22838 A general-purpose register. This is equivalent to 'r' unless 22839 generating MIPS16 code, in which case the MIPS16 register set 22840 is used. 22841 22842 'f' 22843 A floating-point register (if available). 22844 22845 'h' 22846 Formerly the 'hi' register. This constraint is no longer 22847 supported. 22848 22849 'l' 22850 The 'lo' register. Use this register to store values that are 22851 no bigger than a word. 22852 22853 'x' 22854 The concatenated 'hi' and 'lo' registers. Use this register 22855 to store doubleword values. 22856 22857 'c' 22858 A register suitable for use in an indirect jump. This will 22859 always be '$25' for '-mabicalls'. 22860 22861 'v' 22862 Register '$3'. Do not use this constraint in new code; it is 22863 retained only for compatibility with glibc. 22864 22865 'y' 22866 Equivalent to 'r'; retained for backwards compatibility. 22867 22868 'z' 22869 A floating-point condition code register. 22870 22871 'I' 22872 A signed 16-bit constant (for arithmetic instructions). 22873 22874 'J' 22875 Integer zero. 22876 22877 'K' 22878 An unsigned 16-bit constant (for logic instructions). 22879 22880 'L' 22881 A signed 32-bit constant in which the lower 16 bits are zero. 22882 Such constants can be loaded using 'lui'. 22883 22884 'M' 22885 A constant that cannot be loaded using 'lui', 'addiu' or 22886 'ori'. 22887 22888 'N' 22889 A constant in the range -65535 to -1 (inclusive). 22890 22891 'O' 22892 A signed 15-bit constant. 22893 22894 'P' 22895 A constant in the range 1 to 65535 (inclusive). 22896 22897 'G' 22898 Floating-point zero. 22899 22900 'R' 22901 An address that can be used in a non-macro load or store. 22902 22903 'ZC' 22904 A memory operand whose address is formed by a base register 22905 and offset that is suitable for use in instructions with the 22906 same addressing mode as 'll' and 'sc'. 22907 22908 'ZD' 22909 An address suitable for a 'prefetch' instruction, or for any 22910 other instruction with the same addressing mode as 'prefetch'. 22911 22912_Motorola 680x0--'config/m68k/constraints.md'_ 22913 'a' 22914 Address register 22915 22916 'd' 22917 Data register 22918 22919 'f' 22920 68881 floating-point register, if available 22921 22922 'I' 22923 Integer in the range 1 to 8 22924 22925 'J' 22926 16-bit signed number 22927 22928 'K' 22929 Signed number whose magnitude is greater than 0x80 22930 22931 'L' 22932 Integer in the range -8 to -1 22933 22934 'M' 22935 Signed number whose magnitude is greater than 0x100 22936 22937 'N' 22938 Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate 22939 22940 'O' 22941 16 (for rotate using swap) 22942 22943 'P' 22944 Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate 22945 22946 'R' 22947 Numbers that mov3q can handle 22948 22949 'G' 22950 Floating point constant that is not a 68881 constant 22951 22952 'S' 22953 Operands that satisfy 'm' when -mpcrel is in effect 22954 22955 'T' 22956 Operands that satisfy 's' when -mpcrel is not in effect 22957 22958 'Q' 22959 Address register indirect addressing mode 22960 22961 'U' 22962 Register offset addressing 22963 22964 'W' 22965 const_call_operand 22966 22967 'Cs' 22968 symbol_ref or const 22969 22970 'Ci' 22971 const_int 22972 22973 'C0' 22974 const_int 0 22975 22976 'Cj' 22977 Range of signed numbers that don't fit in 16 bits 22978 22979 'Cmvq' 22980 Integers valid for mvq 22981 22982 'Capsw' 22983 Integers valid for a moveq followed by a swap 22984 22985 'Cmvz' 22986 Integers valid for mvz 22987 22988 'Cmvs' 22989 Integers valid for mvs 22990 22991 'Ap' 22992 push_operand 22993 22994 'Ac' 22995 Non-register operands allowed in clr 22996 22997_Moxie--'config/moxie/constraints.md'_ 22998 'A' 22999 An absolute address 23000 23001 'B' 23002 An offset address 23003 23004 'W' 23005 A register indirect memory operand 23006 23007 'I' 23008 A constant in the range of 0 to 255. 23009 23010 'N' 23011 A constant in the range of 0 to -255. 23012 23013_MSP430-'config/msp430/constraints.md'_ 23014 23015 'R12' 23016 Register R12. 23017 23018 'R13' 23019 Register R13. 23020 23021 'K' 23022 Integer constant 1. 23023 23024 'L' 23025 Integer constant -1^20..1^19. 23026 23027 'M' 23028 Integer constant 1-4. 23029 23030 'Ya' 23031 Memory references which do not require an extended MOVX 23032 instruction. 23033 23034 'Yl' 23035 Memory reference, labels only. 23036 23037 'Ys' 23038 Memory reference, stack only. 23039 23040_NDS32--'config/nds32/constraints.md'_ 23041 'w' 23042 LOW register class $r0 to $r7 constraint for V3/V3M ISA. 23043 'l' 23044 LOW register class $r0 to $r7. 23045 'd' 23046 MIDDLE register class $r0 to $r11, $r16 to $r19. 23047 'h' 23048 HIGH register class $r12 to $r14, $r20 to $r31. 23049 't' 23050 Temporary assist register $ta (i.e. $r15). 23051 'k' 23052 Stack register $sp. 23053 'Iu03' 23054 Unsigned immediate 3-bit value. 23055 'In03' 23056 Negative immediate 3-bit value in the range of -7-0. 23057 'Iu04' 23058 Unsigned immediate 4-bit value. 23059 'Is05' 23060 Signed immediate 5-bit value. 23061 'Iu05' 23062 Unsigned immediate 5-bit value. 23063 'In05' 23064 Negative immediate 5-bit value in the range of -31-0. 23065 'Ip05' 23066 Unsigned immediate 5-bit value for movpi45 instruction with 23067 range 16-47. 23068 'Iu06' 23069 Unsigned immediate 6-bit value constraint for addri36.sp 23070 instruction. 23071 'Iu08' 23072 Unsigned immediate 8-bit value. 23073 'Iu09' 23074 Unsigned immediate 9-bit value. 23075 'Is10' 23076 Signed immediate 10-bit value. 23077 'Is11' 23078 Signed immediate 11-bit value. 23079 'Is15' 23080 Signed immediate 15-bit value. 23081 'Iu15' 23082 Unsigned immediate 15-bit value. 23083 'Ic15' 23084 A constant which is not in the range of imm15u but ok for bclr 23085 instruction. 23086 'Ie15' 23087 A constant which is not in the range of imm15u but ok for bset 23088 instruction. 23089 'It15' 23090 A constant which is not in the range of imm15u but ok for btgl 23091 instruction. 23092 'Ii15' 23093 A constant whose compliment value is in the range of imm15u 23094 and ok for bitci instruction. 23095 'Is16' 23096 Signed immediate 16-bit value. 23097 'Is17' 23098 Signed immediate 17-bit value. 23099 'Is19' 23100 Signed immediate 19-bit value. 23101 'Is20' 23102 Signed immediate 20-bit value. 23103 'Ihig' 23104 The immediate value that can be simply set high 20-bit. 23105 'Izeb' 23106 The immediate value 0xff. 23107 'Izeh' 23108 The immediate value 0xffff. 23109 'Ixls' 23110 The immediate value 0x01. 23111 'Ix11' 23112 The immediate value 0x7ff. 23113 'Ibms' 23114 The immediate value with power of 2. 23115 'Ifex' 23116 The immediate value with power of 2 minus 1. 23117 'U33' 23118 Memory constraint for 333 format. 23119 'U45' 23120 Memory constraint for 45 format. 23121 'U37' 23122 Memory constraint for 37 format. 23123 23124_Nios II family--'config/nios2/constraints.md'_ 23125 23126 'I' 23127 Integer that is valid as an immediate operand in an 23128 instruction taking a signed 16-bit number. Range -32768 to 23129 32767. 23130 23131 'J' 23132 Integer that is valid as an immediate operand in an 23133 instruction taking an unsigned 16-bit number. Range 0 to 23134 65535. 23135 23136 'K' 23137 Integer that is valid as an immediate operand in an 23138 instruction taking only the upper 16-bits of a 32-bit number. 23139 Range 32-bit numbers with the lower 16-bits being 0. 23140 23141 'L' 23142 Integer that is valid as an immediate operand for a shift 23143 instruction. Range 0 to 31. 23144 23145 'M' 23146 Integer that is valid as an immediate operand for only the 23147 value 0. Can be used in conjunction with the format modifier 23148 'z' to use 'r0' instead of '0' in the assembly output. 23149 23150 'N' 23151 Integer that is valid as an immediate operand for a custom 23152 instruction opcode. Range 0 to 255. 23153 23154 'P' 23155 An immediate operand for R2 andchi/andci instructions. 23156 23157 'S' 23158 Matches immediates which are addresses in the small data 23159 section and therefore can be added to 'gp' as a 16-bit 23160 immediate to re-create their 32-bit value. 23161 23162 'U' 23163 Matches constants suitable as an operand for the rdprs and 23164 cache instructions. 23165 23166 'v' 23167 A memory operand suitable for Nios II R2 load/store exclusive 23168 instructions. 23169 23170 'w' 23171 A memory operand suitable for load/store IO and cache 23172 instructions. 23173 23174 'T' 23175 A 'const' wrapped 'UNSPEC' expression, representing a 23176 supported PIC or TLS relocation. 23177 23178_OpenRISC--'config/or1k/constraints.md'_ 23179 'I' 23180 Integer that is valid as an immediate operand in an 23181 instruction taking a signed 16-bit number. Range -32768 to 23182 32767. 23183 23184 'K' 23185 Integer that is valid as an immediate operand in an 23186 instruction taking an unsigned 16-bit number. Range 0 to 23187 65535. 23188 23189 'M' 23190 Signed 16-bit constant shifted left 16 bits. (Used with 23191 'l.movhi') 23192 23193 'O' 23194 Zero 23195 23196 'c' 23197 Register usable for sibcalls. 23198 23199_PDP-11--'config/pdp11/constraints.md'_ 23200 'a' 23201 Floating point registers AC0 through AC3. These can be loaded 23202 from/to memory with a single instruction. 23203 23204 'd' 23205 Odd numbered general registers (R1, R3, R5). These are used 23206 for 16-bit multiply operations. 23207 23208 'D' 23209 A memory reference that is encoded within the opcode, but not 23210 auto-increment or auto-decrement. 23211 23212 'f' 23213 Any of the floating point registers (AC0 through AC5). 23214 23215 'G' 23216 Floating point constant 0. 23217 23218 'h' 23219 Floating point registers AC4 and AC5. These cannot be loaded 23220 from/to memory with a single instruction. 23221 23222 'I' 23223 An integer constant that fits in 16 bits. 23224 23225 'J' 23226 An integer constant whose low order 16 bits are zero. 23227 23228 'K' 23229 An integer constant that does not meet the constraints for 23230 codes 'I' or 'J'. 23231 23232 'L' 23233 The integer constant 1. 23234 23235 'M' 23236 The integer constant -1. 23237 23238 'N' 23239 The integer constant 0. 23240 23241 'O' 23242 Integer constants 0 through 3; shifts by these amounts are 23243 handled as multiple single-bit shifts rather than a single 23244 variable-length shift. 23245 23246 'Q' 23247 A memory reference which requires an additional word (address 23248 or offset) after the opcode. 23249 23250 'R' 23251 A memory reference that is encoded within the opcode. 23252 23253_PowerPC and IBM RS6000--'config/rs6000/constraints.md'_ 23254 'b' 23255 Address base register 23256 23257 'd' 23258 Floating point register (containing 64-bit value) 23259 23260 'f' 23261 Floating point register (containing 32-bit value) 23262 23263 'v' 23264 Altivec vector register 23265 23266 'wa' 23267 Any VSX register if the '-mvsx' option was used or NO_REGS. 23268 23269 When using any of the register constraints ('wa', 'wd', 'wf', 23270 'wg', 'wh', 'wi', 'wj', 'wk', 'wl', 'wm', 'wo', 'wp', 'wq', 23271 'ws', 'wt', 'wu', 'wv', 'ww', or 'wy') that take VSX 23272 registers, you must use '%x<n>' in the template so that the 23273 correct register is used. Otherwise the register number 23274 output in the assembly file will be incorrect if an Altivec 23275 register is an operand of a VSX instruction that expects VSX 23276 register numbering. 23277 23278 asm ("xvadddp %x0,%x1,%x2" 23279 : "=wa" (v1) 23280 : "wa" (v2), "wa" (v3)); 23281 23282 is correct, but: 23283 23284 asm ("xvadddp %0,%1,%2" 23285 : "=wa" (v1) 23286 : "wa" (v2), "wa" (v3)); 23287 23288 is not correct. 23289 23290 If an instruction only takes Altivec registers, you do not 23291 want to use '%x<n>'. 23292 23293 asm ("xsaddqp %0,%1,%2" 23294 : "=v" (v1) 23295 : "v" (v2), "v" (v3)); 23296 23297 is correct because the 'xsaddqp' instruction only takes 23298 Altivec registers, while: 23299 23300 asm ("xsaddqp %x0,%x1,%x2" 23301 : "=v" (v1) 23302 : "v" (v2), "v" (v3)); 23303 23304 is incorrect. 23305 23306 'wb' 23307 Altivec register if '-mcpu=power9' is used or NO_REGS. 23308 23309 'wd' 23310 VSX vector register to hold vector double data or NO_REGS. 23311 23312 'we' 23313 VSX register if the '-mcpu=power9' and '-m64' options were 23314 used or NO_REGS. 23315 23316 'wf' 23317 VSX vector register to hold vector float data or NO_REGS. 23318 23319 'wg' 23320 If '-mmfpgpr' was used, a floating point register or NO_REGS. 23321 23322 'wh' 23323 Floating point register if direct moves are available, or 23324 NO_REGS. 23325 23326 'wi' 23327 FP or VSX register to hold 64-bit integers for VSX insns or 23328 NO_REGS. 23329 23330 'wj' 23331 FP or VSX register to hold 64-bit integers for direct moves or 23332 NO_REGS. 23333 23334 'wk' 23335 FP or VSX register to hold 64-bit doubles for direct moves or 23336 NO_REGS. 23337 23338 'wl' 23339 Floating point register if the LFIWAX instruction is enabled 23340 or NO_REGS. 23341 23342 'wm' 23343 VSX register if direct move instructions are enabled, or 23344 NO_REGS. 23345 23346 'wn' 23347 No register (NO_REGS). 23348 23349 'wo' 23350 VSX register to use for ISA 3.0 vector instructions, or 23351 NO_REGS. 23352 23353 'wp' 23354 VSX register to use for IEEE 128-bit floating point TFmode, or 23355 NO_REGS. 23356 23357 'wq' 23358 VSX register to use for IEEE 128-bit floating point, or 23359 NO_REGS. 23360 23361 'wr' 23362 General purpose register if 64-bit instructions are enabled or 23363 NO_REGS. 23364 23365 'ws' 23366 VSX vector register to hold scalar double values or NO_REGS. 23367 23368 'wt' 23369 VSX vector register to hold 128 bit integer or NO_REGS. 23370 23371 'wu' 23372 Altivec register to use for float/32-bit int loads/stores or 23373 NO_REGS. 23374 23375 'wv' 23376 Altivec register to use for double loads/stores or NO_REGS. 23377 23378 'ww' 23379 FP or VSX register to perform float operations under '-mvsx' 23380 or NO_REGS. 23381 23382 'wx' 23383 Floating point register if the STFIWX instruction is enabled 23384 or NO_REGS. 23385 23386 'wy' 23387 FP or VSX register to perform ISA 2.07 float ops or NO_REGS. 23388 23389 'wz' 23390 Floating point register if the LFIWZX instruction is enabled 23391 or NO_REGS. 23392 23393 'wA' 23394 Address base register if 64-bit instructions are enabled or 23395 NO_REGS. 23396 23397 'wB' 23398 Signed 5-bit constant integer that can be loaded into an 23399 altivec register. 23400 23401 'wD' 23402 Int constant that is the element number of the 64-bit scalar 23403 in a vector. 23404 23405 'wE' 23406 Vector constant that can be loaded with the XXSPLTIB 23407 instruction. 23408 23409 'wF' 23410 Memory operand suitable for power8 GPR load fusion 23411 23412 'wG' 23413 Memory operand suitable for TOC fusion memory references. 23414 23415 'wH' 23416 Altivec register if '-mvsx-small-integer'. 23417 23418 'wI' 23419 Floating point register if '-mvsx-small-integer'. 23420 23421 'wJ' 23422 FP register if '-mvsx-small-integer' and '-mpower9-vector'. 23423 23424 'wK' 23425 Altivec register if '-mvsx-small-integer' and 23426 '-mpower9-vector'. 23427 23428 'wL' 23429 Int constant that is the element number that the MFVSRLD 23430 instruction. targets. 23431 23432 'wM' 23433 Match vector constant with all 1's if the XXLORC instruction 23434 is available. 23435 23436 'wO' 23437 A memory operand suitable for the ISA 3.0 vector d-form 23438 instructions. 23439 23440 'wQ' 23441 A memory address that will work with the 'lq' and 'stq' 23442 instructions. 23443 23444 'wS' 23445 Vector constant that can be loaded with XXSPLTIB & sign 23446 extension. 23447 23448 'h' 23449 'VRSAVE', 'CTR', or 'LINK' register 23450 23451 'c' 23452 'CTR' register 23453 23454 'l' 23455 'LINK' register 23456 23457 'x' 23458 'CR' register (condition register) number 0 23459 23460 'y' 23461 'CR' register (condition register) 23462 23463 'z' 23464 'XER[CA]' carry bit (part of the XER register) 23465 23466 'I' 23467 Signed 16-bit constant 23468 23469 'J' 23470 Unsigned 16-bit constant shifted left 16 bits (use 'L' instead 23471 for 'SImode' constants) 23472 23473 'K' 23474 Unsigned 16-bit constant 23475 23476 'L' 23477 Signed 16-bit constant shifted left 16 bits 23478 23479 'M' 23480 Constant larger than 31 23481 23482 'N' 23483 Exact power of 2 23484 23485 'O' 23486 Zero 23487 23488 'P' 23489 Constant whose negation is a signed 16-bit constant 23490 23491 'G' 23492 Floating point constant that can be loaded into a register 23493 with one instruction per word 23494 23495 'H' 23496 Integer/Floating point constant that can be loaded into a 23497 register using three instructions 23498 23499 'm' 23500 Memory operand. Normally, 'm' does not allow addresses that 23501 update the base register. If '<' or '>' constraint is also 23502 used, they are allowed and therefore on PowerPC targets in 23503 that case it is only safe to use 'm<>' in an 'asm' statement 23504 if that 'asm' statement accesses the operand exactly once. 23505 The 'asm' statement must also use '%U<OPNO>' as a placeholder 23506 for the "update" flag in the corresponding load or store 23507 instruction. For example: 23508 23509 asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val)); 23510 23511 is correct but: 23512 23513 asm ("st %1,%0" : "=m<>" (mem) : "r" (val)); 23514 23515 is not. 23516 23517 'es' 23518 A "stable" memory operand; that is, one which does not include 23519 any automodification of the base register. This used to be 23520 useful when 'm' allowed automodification of the base register, 23521 but as those are now only allowed when '<' or '>' is used, 23522 'es' is basically the same as 'm' without '<' and '>'. 23523 23524 'Q' 23525 Memory operand that is an offset from a register (it is 23526 usually better to use 'm' or 'es' in 'asm' statements) 23527 23528 'Z' 23529 Memory operand that is an indexed or indirect from a register 23530 (it is usually better to use 'm' or 'es' in 'asm' statements) 23531 23532 'R' 23533 AIX TOC entry 23534 23535 'a' 23536 Address operand that is an indexed or indirect from a register 23537 ('p' is preferable for 'asm' statements) 23538 23539 'U' 23540 System V Release 4 small data area reference 23541 23542 'W' 23543 Vector constant that does not require memory 23544 23545 'j' 23546 Vector constant that is all zeros. 23547 23548_RL78--'config/rl78/constraints.md'_ 23549 23550 'Int3' 23551 An integer constant in the range 1 ... 7. 23552 'Int8' 23553 An integer constant in the range 0 ... 255. 23554 'J' 23555 An integer constant in the range -255 ... 0 23556 'K' 23557 The integer constant 1. 23558 'L' 23559 The integer constant -1. 23560 'M' 23561 The integer constant 0. 23562 'N' 23563 The integer constant 2. 23564 'O' 23565 The integer constant -2. 23566 'P' 23567 An integer constant in the range 1 ... 15. 23568 'Qbi' 23569 The built-in compare types-eq, ne, gtu, ltu, geu, and leu. 23570 'Qsc' 23571 The synthetic compare types-gt, lt, ge, and le. 23572 'Wab' 23573 A memory reference with an absolute address. 23574 'Wbc' 23575 A memory reference using 'BC' as a base register, with an 23576 optional offset. 23577 'Wca' 23578 A memory reference using 'AX', 'BC', 'DE', or 'HL' for the 23579 address, for calls. 23580 'Wcv' 23581 A memory reference using any 16-bit register pair for the 23582 address, for calls. 23583 'Wd2' 23584 A memory reference using 'DE' as a base register, with an 23585 optional offset. 23586 'Wde' 23587 A memory reference using 'DE' as a base register, without any 23588 offset. 23589 'Wfr' 23590 Any memory reference to an address in the far address space. 23591 'Wh1' 23592 A memory reference using 'HL' as a base register, with an 23593 optional one-byte offset. 23594 'Whb' 23595 A memory reference using 'HL' as a base register, with 'B' or 23596 'C' as the index register. 23597 'Whl' 23598 A memory reference using 'HL' as a base register, without any 23599 offset. 23600 'Ws1' 23601 A memory reference using 'SP' as a base register, with an 23602 optional one-byte offset. 23603 'Y' 23604 Any memory reference to an address in the near address space. 23605 'A' 23606 The 'AX' register. 23607 'B' 23608 The 'BC' register. 23609 'D' 23610 The 'DE' register. 23611 'R' 23612 'A' through 'L' registers. 23613 'S' 23614 The 'SP' register. 23615 'T' 23616 The 'HL' register. 23617 'Z08W' 23618 The 16-bit 'R8' register. 23619 'Z10W' 23620 The 16-bit 'R10' register. 23621 'Zint' 23622 The registers reserved for interrupts ('R24' to 'R31'). 23623 'a' 23624 The 'A' register. 23625 'b' 23626 The 'B' register. 23627 'c' 23628 The 'C' register. 23629 'd' 23630 The 'D' register. 23631 'e' 23632 The 'E' register. 23633 'h' 23634 The 'H' register. 23635 'l' 23636 The 'L' register. 23637 'v' 23638 The virtual registers. 23639 'w' 23640 The 'PSW' register. 23641 'x' 23642 The 'X' register. 23643 23644_RISC-V--'config/riscv/constraints.md'_ 23645 23646 'f' 23647 A floating-point register (if available). 23648 23649 'I' 23650 An I-type 12-bit signed immediate. 23651 23652 'J' 23653 Integer zero. 23654 23655 'K' 23656 A 5-bit unsigned immediate for CSR access instructions. 23657 23658 'A' 23659 An address that is held in a general-purpose register. 23660 23661_RX--'config/rx/constraints.md'_ 23662 'Q' 23663 An address which does not involve register indirect addressing 23664 or pre/post increment/decrement addressing. 23665 23666 'Symbol' 23667 A symbol reference. 23668 23669 'Int08' 23670 A constant in the range -256 to 255, inclusive. 23671 23672 'Sint08' 23673 A constant in the range -128 to 127, inclusive. 23674 23675 'Sint16' 23676 A constant in the range -32768 to 32767, inclusive. 23677 23678 'Sint24' 23679 A constant in the range -8388608 to 8388607, inclusive. 23680 23681 'Uint04' 23682 A constant in the range 0 to 15, inclusive. 23683 23684_S/390 and zSeries--'config/s390/s390.h'_ 23685 'a' 23686 Address register (general purpose register except r0) 23687 23688 'c' 23689 Condition code register 23690 23691 'd' 23692 Data register (arbitrary general purpose register) 23693 23694 'f' 23695 Floating-point register 23696 23697 'I' 23698 Unsigned 8-bit constant (0-255) 23699 23700 'J' 23701 Unsigned 12-bit constant (0-4095) 23702 23703 'K' 23704 Signed 16-bit constant (-32768-32767) 23705 23706 'L' 23707 Value appropriate as displacement. 23708 '(0..4095)' 23709 for short displacement 23710 '(-524288..524287)' 23711 for long displacement 23712 23713 'M' 23714 Constant integer with a value of 0x7fffffff. 23715 23716 'N' 23717 Multiple letter constraint followed by 4 parameter letters. 23718 '0..9:' 23719 number of the part counting from most to least 23720 significant 23721 'H,Q:' 23722 mode of the part 23723 'D,S,H:' 23724 mode of the containing operand 23725 '0,F:' 23726 value of the other parts (F--all bits set) 23727 The constraint matches if the specified part of a constant has 23728 a value different from its other parts. 23729 23730 'Q' 23731 Memory reference without index register and with short 23732 displacement. 23733 23734 'R' 23735 Memory reference with index register and short displacement. 23736 23737 'S' 23738 Memory reference without index register but with long 23739 displacement. 23740 23741 'T' 23742 Memory reference with index register and long displacement. 23743 23744 'U' 23745 Pointer with short displacement. 23746 23747 'W' 23748 Pointer with long displacement. 23749 23750 'Y' 23751 Shift count operand. 23752 23753_SPARC--'config/sparc/sparc.h'_ 23754 'f' 23755 Floating-point register on the SPARC-V8 architecture and lower 23756 floating-point register on the SPARC-V9 architecture. 23757 23758 'e' 23759 Floating-point register. It is equivalent to 'f' on the 23760 SPARC-V8 architecture and contains both lower and upper 23761 floating-point registers on the SPARC-V9 architecture. 23762 23763 'c' 23764 Floating-point condition code register. 23765 23766 'd' 23767 Lower floating-point register. It is only valid on the 23768 SPARC-V9 architecture when the Visual Instruction Set is 23769 available. 23770 23771 'b' 23772 Floating-point register. It is only valid on the SPARC-V9 23773 architecture when the Visual Instruction Set is available. 23774 23775 'h' 23776 64-bit global or out register for the SPARC-V8+ architecture. 23777 23778 'C' 23779 The constant all-ones, for floating-point. 23780 23781 'A' 23782 Signed 5-bit constant 23783 23784 'D' 23785 A vector constant 23786 23787 'I' 23788 Signed 13-bit constant 23789 23790 'J' 23791 Zero 23792 23793 'K' 23794 32-bit constant with the low 12 bits clear (a constant that 23795 can be loaded with the 'sethi' instruction) 23796 23797 'L' 23798 A constant in the range supported by 'movcc' instructions 23799 (11-bit signed immediate) 23800 23801 'M' 23802 A constant in the range supported by 'movrcc' instructions 23803 (10-bit signed immediate) 23804 23805 'N' 23806 Same as 'K', except that it verifies that bits that are not in 23807 the lower 32-bit range are all zero. Must be used instead of 23808 'K' for modes wider than 'SImode' 23809 23810 'O' 23811 The constant 4096 23812 23813 'G' 23814 Floating-point zero 23815 23816 'H' 23817 Signed 13-bit constant, sign-extended to 32 or 64 bits 23818 23819 'P' 23820 The constant -1 23821 23822 'Q' 23823 Floating-point constant whose integral representation can be 23824 moved into an integer register using a single sethi 23825 instruction 23826 23827 'R' 23828 Floating-point constant whose integral representation can be 23829 moved into an integer register using a single mov instruction 23830 23831 'S' 23832 Floating-point constant whose integral representation can be 23833 moved into an integer register using a high/lo_sum instruction 23834 sequence 23835 23836 'T' 23837 Memory address aligned to an 8-byte boundary 23838 23839 'U' 23840 Even register 23841 23842 'W' 23843 Memory address for 'e' constraint registers 23844 23845 'w' 23846 Memory address with only a base register 23847 23848 'Y' 23849 Vector zero 23850 23851_SPU--'config/spu/spu.h'_ 23852 'a' 23853 An immediate which can be loaded with the il/ila/ilh/ilhu 23854 instructions. const_int is treated as a 64 bit value. 23855 23856 'c' 23857 An immediate for and/xor/or instructions. const_int is 23858 treated as a 64 bit value. 23859 23860 'd' 23861 An immediate for the 'iohl' instruction. const_int is treated 23862 as a 64 bit value. 23863 23864 'f' 23865 An immediate which can be loaded with 'fsmbi'. 23866 23867 'A' 23868 An immediate which can be loaded with the il/ila/ilh/ilhu 23869 instructions. const_int is treated as a 32 bit value. 23870 23871 'B' 23872 An immediate for most arithmetic instructions. const_int is 23873 treated as a 32 bit value. 23874 23875 'C' 23876 An immediate for and/xor/or instructions. const_int is 23877 treated as a 32 bit value. 23878 23879 'D' 23880 An immediate for the 'iohl' instruction. const_int is treated 23881 as a 32 bit value. 23882 23883 'I' 23884 A constant in the range [-64, 63] for shift/rotate 23885 instructions. 23886 23887 'J' 23888 An unsigned 7-bit constant for conversion/nop/channel 23889 instructions. 23890 23891 'K' 23892 A signed 10-bit constant for most arithmetic instructions. 23893 23894 'M' 23895 A signed 16 bit immediate for 'stop'. 23896 23897 'N' 23898 An unsigned 16-bit constant for 'iohl' and 'fsmbi'. 23899 23900 'O' 23901 An unsigned 7-bit constant whose 3 least significant bits are 23902 0. 23903 23904 'P' 23905 An unsigned 3-bit constant for 16-byte rotates and shifts 23906 23907 'R' 23908 Call operand, reg, for indirect calls 23909 23910 'S' 23911 Call operand, symbol, for relative calls. 23912 23913 'T' 23914 Call operand, const_int, for absolute calls. 23915 23916 'U' 23917 An immediate which can be loaded with the il/ila/ilh/ilhu 23918 instructions. const_int is sign extended to 128 bit. 23919 23920 'W' 23921 An immediate for shift and rotate instructions. const_int is 23922 treated as a 32 bit value. 23923 23924 'Y' 23925 An immediate for and/xor/or instructions. const_int is sign 23926 extended as a 128 bit. 23927 23928 'Z' 23929 An immediate for the 'iohl' instruction. const_int is sign 23930 extended to 128 bit. 23931 23932_TI C6X family--'config/c6x/constraints.md'_ 23933 'a' 23934 Register file A (A0-A31). 23935 23936 'b' 23937 Register file B (B0-B31). 23938 23939 'A' 23940 Predicate registers in register file A (A0-A2 on C64X and 23941 higher, A1 and A2 otherwise). 23942 23943 'B' 23944 Predicate registers in register file B (B0-B2). 23945 23946 'C' 23947 A call-used register in register file B (B0-B9, B16-B31). 23948 23949 'Da' 23950 Register file A, excluding predicate registers (A3-A31, plus 23951 A0 if not C64X or higher). 23952 23953 'Db' 23954 Register file B, excluding predicate registers (B3-B31). 23955 23956 'Iu4' 23957 Integer constant in the range 0 ... 15. 23958 23959 'Iu5' 23960 Integer constant in the range 0 ... 31. 23961 23962 'In5' 23963 Integer constant in the range -31 ... 0. 23964 23965 'Is5' 23966 Integer constant in the range -16 ... 15. 23967 23968 'I5x' 23969 Integer constant that can be the operand of an ADDA or a SUBA 23970 insn. 23971 23972 'IuB' 23973 Integer constant in the range 0 ... 65535. 23974 23975 'IsB' 23976 Integer constant in the range -32768 ... 32767. 23977 23978 'IsC' 23979 Integer constant in the range -2^{20} ... 2^{20} - 1. 23980 23981 'Jc' 23982 Integer constant that is a valid mask for the clr instruction. 23983 23984 'Js' 23985 Integer constant that is a valid mask for the set instruction. 23986 23987 'Q' 23988 Memory location with A base register. 23989 23990 'R' 23991 Memory location with B base register. 23992 23993 'S0' 23994 On C64x+ targets, a GP-relative small data reference. 23995 23996 'S1' 23997 Any kind of 'SYMBOL_REF', for use in a call address. 23998 23999 'Si' 24000 Any kind of immediate operand, unless it matches the S0 24001 constraint. 24002 24003 'T' 24004 Memory location with B base register, but not using a long 24005 offset. 24006 24007 'W' 24008 A memory operand with an address that cannot be used in an 24009 unaligned access. 24010 24011 'Z' 24012 Register B14 (aka DP). 24013 24014_TILE-Gx--'config/tilegx/constraints.md'_ 24015 'R00' 24016 'R01' 24017 'R02' 24018 'R03' 24019 'R04' 24020 'R05' 24021 'R06' 24022 'R07' 24023 'R08' 24024 'R09' 24025 'R10' 24026 Each of these represents a register constraint for an 24027 individual register, from r0 to r10. 24028 24029 'I' 24030 Signed 8-bit integer constant. 24031 24032 'J' 24033 Signed 16-bit integer constant. 24034 24035 'K' 24036 Unsigned 16-bit integer constant. 24037 24038 'L' 24039 Integer constant that fits in one signed byte when incremented 24040 by one (-129 ... 126). 24041 24042 'm' 24043 Memory operand. If used together with '<' or '>', the operand 24044 can have postincrement which requires printing with '%In' and 24045 '%in' on TILE-Gx. For example: 24046 24047 asm ("st_add %I0,%1,%i0" : "=m<>" (*mem) : "r" (val)); 24048 24049 'M' 24050 A bit mask suitable for the BFINS instruction. 24051 24052 'N' 24053 Integer constant that is a byte tiled out eight times. 24054 24055 'O' 24056 The integer zero constant. 24057 24058 'P' 24059 Integer constant that is a sign-extended byte tiled out as 24060 four shorts. 24061 24062 'Q' 24063 Integer constant that fits in one signed byte when incremented 24064 (-129 ... 126), but excluding -1. 24065 24066 'S' 24067 Integer constant that has all 1 bits consecutive and starting 24068 at bit 0. 24069 24070 'T' 24071 A 16-bit fragment of a got, tls, or pc-relative reference. 24072 24073 'U' 24074 Memory operand except postincrement. This is roughly the same 24075 as 'm' when not used together with '<' or '>'. 24076 24077 'W' 24078 An 8-element vector constant with identical elements. 24079 24080 'Y' 24081 A 4-element vector constant with identical elements. 24082 24083 'Z0' 24084 The integer constant 0xffffffff. 24085 24086 'Z1' 24087 The integer constant 0xffffffff00000000. 24088 24089_TILEPro--'config/tilepro/constraints.md'_ 24090 'R00' 24091 'R01' 24092 'R02' 24093 'R03' 24094 'R04' 24095 'R05' 24096 'R06' 24097 'R07' 24098 'R08' 24099 'R09' 24100 'R10' 24101 Each of these represents a register constraint for an 24102 individual register, from r0 to r10. 24103 24104 'I' 24105 Signed 8-bit integer constant. 24106 24107 'J' 24108 Signed 16-bit integer constant. 24109 24110 'K' 24111 Nonzero integer constant with low 16 bits zero. 24112 24113 'L' 24114 Integer constant that fits in one signed byte when incremented 24115 by one (-129 ... 126). 24116 24117 'm' 24118 Memory operand. If used together with '<' or '>', the operand 24119 can have postincrement which requires printing with '%In' and 24120 '%in' on TILEPro. For example: 24121 24122 asm ("swadd %I0,%1,%i0" : "=m<>" (mem) : "r" (val)); 24123 24124 'M' 24125 A bit mask suitable for the MM instruction. 24126 24127 'N' 24128 Integer constant that is a byte tiled out four times. 24129 24130 'O' 24131 The integer zero constant. 24132 24133 'P' 24134 Integer constant that is a sign-extended byte tiled out as two 24135 shorts. 24136 24137 'Q' 24138 Integer constant that fits in one signed byte when incremented 24139 (-129 ... 126), but excluding -1. 24140 24141 'T' 24142 A symbolic operand, or a 16-bit fragment of a got, tls, or 24143 pc-relative reference. 24144 24145 'U' 24146 Memory operand except postincrement. This is roughly the same 24147 as 'm' when not used together with '<' or '>'. 24148 24149 'W' 24150 A 4-element vector constant with identical elements. 24151 24152 'Y' 24153 A 2-element vector constant with identical elements. 24154 24155_Visium--'config/visium/constraints.md'_ 24156 'b' 24157 EAM register 'mdb' 24158 24159 'c' 24160 EAM register 'mdc' 24161 24162 'f' 24163 Floating point register 24164 24165 'k' 24166 Register for sibcall optimization 24167 24168 'l' 24169 General register, but not 'r29', 'r30' and 'r31' 24170 24171 't' 24172 Register 'r1' 24173 24174 'u' 24175 Register 'r2' 24176 24177 'v' 24178 Register 'r3' 24179 24180 'G' 24181 Floating-point constant 0.0 24182 24183 'J' 24184 Integer constant in the range 0 .. 65535 (16-bit immediate) 24185 24186 'K' 24187 Integer constant in the range 1 .. 31 (5-bit immediate) 24188 24189 'L' 24190 Integer constant in the range -65535 .. -1 (16-bit negative 24191 immediate) 24192 24193 'M' 24194 Integer constant -1 24195 24196 'O' 24197 Integer constant 0 24198 24199 'P' 24200 Integer constant 32 24201 24202_x86 family--'config/i386/constraints.md'_ 24203 'R' 24204 Legacy register--the eight integer registers available on all 24205 i386 processors ('a', 'b', 'c', 'd', 'si', 'di', 'bp', 'sp'). 24206 24207 'q' 24208 Any register accessible as 'Rl'. In 32-bit mode, 'a', 'b', 24209 'c', and 'd'; in 64-bit mode, any integer register. 24210 24211 'Q' 24212 Any register accessible as 'Rh': 'a', 'b', 'c', and 'd'. 24213 24214 'l' 24215 Any register that can be used as the index in a base+index 24216 memory access: that is, any general register except the stack 24217 pointer. 24218 24219 'a' 24220 The 'a' register. 24221 24222 'b' 24223 The 'b' register. 24224 24225 'c' 24226 The 'c' register. 24227 24228 'd' 24229 The 'd' register. 24230 24231 'S' 24232 The 'si' register. 24233 24234 'D' 24235 The 'di' register. 24236 24237 'A' 24238 The 'a' and 'd' registers. This class is used for 24239 instructions that return double word results in the 'ax:dx' 24240 register pair. Single word values will be allocated either in 24241 'ax' or 'dx'. For example on i386 the following implements 24242 'rdtsc': 24243 24244 unsigned long long rdtsc (void) 24245 { 24246 unsigned long long tick; 24247 __asm__ __volatile__("rdtsc":"=A"(tick)); 24248 return tick; 24249 } 24250 24251 This is not correct on x86-64 as it would allocate tick in 24252 either 'ax' or 'dx'. You have to use the following variant 24253 instead: 24254 24255 unsigned long long rdtsc (void) 24256 { 24257 unsigned int tickl, tickh; 24258 __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh)); 24259 return ((unsigned long long)tickh << 32)|tickl; 24260 } 24261 24262 'U' 24263 The call-clobbered integer registers. 24264 24265 'f' 24266 Any 80387 floating-point (stack) register. 24267 24268 't' 24269 Top of 80387 floating-point stack ('%st(0)'). 24270 24271 'u' 24272 Second from top of 80387 floating-point stack ('%st(1)'). 24273 24274 'Yk' 24275 Any mask register that can be used as a predicate, i.e. 24276 'k1-k7'. 24277 24278 'k' 24279 Any mask register. 24280 24281 'y' 24282 Any MMX register. 24283 24284 'x' 24285 Any SSE register. 24286 24287 'v' 24288 Any EVEX encodable SSE register ('%xmm0-%xmm31'). 24289 24290 'w' 24291 Any bound register. 24292 24293 'Yz' 24294 First SSE register ('%xmm0'). 24295 24296 'Yi' 24297 Any SSE register, when SSE2 and inter-unit moves are enabled. 24298 24299 'Yj' 24300 Any SSE register, when SSE2 and inter-unit moves from vector 24301 registers are enabled. 24302 24303 'Ym' 24304 Any MMX register, when inter-unit moves are enabled. 24305 24306 'Yn' 24307 Any MMX register, when inter-unit moves from vector registers 24308 are enabled. 24309 24310 'Yp' 24311 Any integer register when 'TARGET_PARTIAL_REG_STALL' is 24312 disabled. 24313 24314 'Ya' 24315 Any integer register when zero extensions with 'AND' are 24316 disabled. 24317 24318 'Yb' 24319 Any register that can be used as the GOT base when calling 24320 '___tls_get_addr': that is, any general register except 'a' 24321 and 'sp' registers, for '-fno-plt' if linker supports it. 24322 Otherwise, 'b' register. 24323 24324 'Yf' 24325 Any x87 register when 80387 floating-point arithmetic is 24326 enabled. 24327 24328 'Yr' 24329 Lower SSE register when avoiding REX prefix and all SSE 24330 registers otherwise. 24331 24332 'Yv' 24333 For AVX512VL, any EVEX-encodable SSE register 24334 ('%xmm0-%xmm31'), otherwise any SSE register. 24335 24336 'Yh' 24337 Any EVEX-encodable SSE register, that has number factor of 24338 four. 24339 24340 'Bf' 24341 Flags register operand. 24342 24343 'Bg' 24344 GOT memory operand. 24345 24346 'Bm' 24347 Vector memory operand. 24348 24349 'Bc' 24350 Constant memory operand. 24351 24352 'Bn' 24353 Memory operand without REX prefix. 24354 24355 'Bs' 24356 Sibcall memory operand. 24357 24358 'Bw' 24359 Call memory operand. 24360 24361 'Bz' 24362 Constant call address operand. 24363 24364 'BC' 24365 SSE constant -1 operand. 24366 24367 'I' 24368 Integer constant in the range 0 ... 31, for 32-bit shifts. 24369 24370 'J' 24371 Integer constant in the range 0 ... 63, for 64-bit shifts. 24372 24373 'K' 24374 Signed 8-bit integer constant. 24375 24376 'L' 24377 '0xFF' or '0xFFFF', for andsi as a zero-extending move. 24378 24379 'M' 24380 0, 1, 2, or 3 (shifts for the 'lea' instruction). 24381 24382 'N' 24383 Unsigned 8-bit integer constant (for 'in' and 'out' 24384 instructions). 24385 24386 'O' 24387 Integer constant in the range 0 ... 127, for 128-bit shifts. 24388 24389 'G' 24390 Standard 80387 floating point constant. 24391 24392 'C' 24393 SSE constant zero operand. 24394 24395 'e' 24396 32-bit signed integer constant, or a symbolic reference known 24397 to fit that range (for immediate operands in sign-extending 24398 x86-64 instructions). 24399 24400 'We' 24401 32-bit signed integer constant, or a symbolic reference known 24402 to fit that range (for sign-extending conversion operations 24403 that require non-'VOIDmode' immediate operands). 24404 24405 'Wz' 24406 32-bit unsigned integer constant, or a symbolic reference 24407 known to fit that range (for zero-extending conversion 24408 operations that require non-'VOIDmode' immediate operands). 24409 24410 'Wd' 24411 128-bit integer constant where both the high and low 64-bit 24412 word satisfy the 'e' constraint. 24413 24414 'Z' 24415 32-bit unsigned integer constant, or a symbolic reference 24416 known to fit that range (for immediate operands in 24417 zero-extending x86-64 instructions). 24418 24419 'Tv' 24420 VSIB address operand. 24421 24422 'Ts' 24423 Address operand without segment register. 24424 24425_Xstormy16--'config/stormy16/stormy16.h'_ 24426 'a' 24427 Register r0. 24428 24429 'b' 24430 Register r1. 24431 24432 'c' 24433 Register r2. 24434 24435 'd' 24436 Register r8. 24437 24438 'e' 24439 Registers r0 through r7. 24440 24441 't' 24442 Registers r0 and r1. 24443 24444 'y' 24445 The carry register. 24446 24447 'z' 24448 Registers r8 and r9. 24449 24450 'I' 24451 A constant between 0 and 3 inclusive. 24452 24453 'J' 24454 A constant that has exactly one bit set. 24455 24456 'K' 24457 A constant that has exactly one bit clear. 24458 24459 'L' 24460 A constant between 0 and 255 inclusive. 24461 24462 'M' 24463 A constant between -255 and 0 inclusive. 24464 24465 'N' 24466 A constant between -3 and 0 inclusive. 24467 24468 'O' 24469 A constant between 1 and 4 inclusive. 24470 24471 'P' 24472 A constant between -4 and -1 inclusive. 24473 24474 'Q' 24475 A memory reference that is a stack push. 24476 24477 'R' 24478 A memory reference that is a stack pop. 24479 24480 'S' 24481 A memory reference that refers to a constant address of known 24482 value. 24483 24484 'T' 24485 The register indicated by Rx (not implemented yet). 24486 24487 'U' 24488 A constant that is not between 2 and 15 inclusive. 24489 24490 'Z' 24491 The constant 0. 24492 24493_Xtensa--'config/xtensa/constraints.md'_ 24494 'a' 24495 General-purpose 32-bit register 24496 24497 'b' 24498 One-bit boolean register 24499 24500 'A' 24501 MAC16 40-bit accumulator register 24502 24503 'I' 24504 Signed 12-bit integer constant, for use in MOVI instructions 24505 24506 'J' 24507 Signed 8-bit integer constant, for use in ADDI instructions 24508 24509 'K' 24510 Integer constant valid for BccI instructions 24511 24512 'L' 24513 Unsigned constant valid for BccUI instructions 24514 24515 24516File: gccint.info, Node: Disable Insn Alternatives, Next: Define Constraints, Prev: Machine Constraints, Up: Constraints 24517 2451817.8.6 Disable insn alternatives using the 'enabled' attribute 24519-------------------------------------------------------------- 24520 24521There are three insn attributes that may be used to selectively disable 24522instruction alternatives: 24523 24524'enabled' 24525 Says whether an alternative is available on the current subtarget. 24526 24527'preferred_for_size' 24528 Says whether an enabled alternative should be used in code that is 24529 optimized for size. 24530 24531'preferred_for_speed' 24532 Says whether an enabled alternative should be used in code that is 24533 optimized for speed. 24534 24535 All these attributes should use '(const_int 1)' to allow an alternative 24536or '(const_int 0)' to disallow it. The attributes must be a static 24537property of the subtarget; they cannot for example depend on the current 24538operands, on the current optimization level, on the location of the insn 24539within the body of a loop, on whether register allocation has finished, 24540or on the current compiler pass. 24541 24542 The 'enabled' attribute is a correctness property. It tells GCC to act 24543as though the disabled alternatives were never defined in the first 24544place. This is useful when adding new instructions to an existing 24545pattern in cases where the new instructions are only available for 24546certain cpu architecture levels (typically mapped to the '-march=' 24547command-line option). 24548 24549 In contrast, the 'preferred_for_size' and 'preferred_for_speed' 24550attributes are strong optimization hints rather than correctness 24551properties. 'preferred_for_size' tells GCC which alternatives to 24552consider when adding or modifying an instruction that GCC wants to 24553optimize for size. 'preferred_for_speed' does the same thing for speed. 24554Note that things like code motion can lead to cases where code optimized 24555for size uses alternatives that are not preferred for size, and 24556similarly for speed. 24557 24558 Although 'define_insn's can in principle specify the 'enabled' 24559attribute directly, it is often clearer to have subsiduary attributes 24560for each architectural feature of interest. The 'define_insn's can then 24561use these subsiduary attributes to say which alternatives require which 24562features. The example below does this for 'cpu_facility'. 24563 24564 E.g. the following two patterns could easily be merged using the 24565'enabled' attribute: 24566 24567 24568 (define_insn "*movdi_old" 24569 [(set (match_operand:DI 0 "register_operand" "=d") 24570 (match_operand:DI 1 "register_operand" " d"))] 24571 "!TARGET_NEW" 24572 "lgr %0,%1") 24573 24574 (define_insn "*movdi_new" 24575 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 24576 (match_operand:DI 1 "register_operand" " d,d,f"))] 24577 "TARGET_NEW" 24578 "@ 24579 lgr %0,%1 24580 ldgr %0,%1 24581 lgdr %0,%1") 24582 24583 24584 to: 24585 24586 24587 (define_insn "*movdi_combined" 24588 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 24589 (match_operand:DI 1 "register_operand" " d,d,f"))] 24590 "" 24591 "@ 24592 lgr %0,%1 24593 ldgr %0,%1 24594 lgdr %0,%1" 24595 [(set_attr "cpu_facility" "*,new,new")]) 24596 24597 24598 with the 'enabled' attribute defined like this: 24599 24600 24601 (define_attr "cpu_facility" "standard,new" (const_string "standard")) 24602 24603 (define_attr "enabled" "" 24604 (cond [(eq_attr "cpu_facility" "standard") (const_int 1) 24605 (and (eq_attr "cpu_facility" "new") 24606 (ne (symbol_ref "TARGET_NEW") (const_int 0))) 24607 (const_int 1)] 24608 (const_int 0))) 24609 24610 24611 24612File: gccint.info, Node: Define Constraints, Next: C Constraint Interface, Prev: Disable Insn Alternatives, Up: Constraints 24613 2461417.8.7 Defining Machine-Specific Constraints 24615-------------------------------------------- 24616 24617Machine-specific constraints fall into two categories: register and 24618non-register constraints. Within the latter category, constraints which 24619allow subsets of all possible memory or address operands should be 24620specially marked, to give 'reload' more information. 24621 24622 Machine-specific constraints can be given names of arbitrary length, 24623but they must be entirely composed of letters, digits, underscores 24624('_'), and angle brackets ('< >'). Like C identifiers, they must begin 24625with a letter or underscore. 24626 24627 In order to avoid ambiguity in operand constraint strings, no 24628constraint can have a name that begins with any other constraint's name. 24629For example, if 'x' is defined as a constraint name, 'xy' may not be, 24630and vice versa. As a consequence of this rule, no constraint may begin 24631with one of the generic constraint letters: 'E F V X g i m n o p r s'. 24632 24633 Register constraints correspond directly to register classes. *Note 24634Register Classes::. There is thus not much flexibility in their 24635definitions. 24636 24637 -- MD Expression: define_register_constraint name regclass docstring 24638 All three arguments are string constants. NAME is the name of the 24639 constraint, as it will appear in 'match_operand' expressions. If 24640 NAME is a multi-letter constraint its length shall be the same for 24641 all constraints starting with the same letter. REGCLASS can be 24642 either the name of the corresponding register class (*note Register 24643 Classes::), or a C expression which evaluates to the appropriate 24644 register class. If it is an expression, it must have no side 24645 effects, and it cannot look at the operand. The usual use of 24646 expressions is to map some register constraints to 'NO_REGS' when 24647 the register class is not available on a given subarchitecture. 24648 24649 DOCSTRING is a sentence documenting the meaning of the constraint. 24650 Docstrings are explained further below. 24651 24652 Non-register constraints are more like predicates: the constraint 24653definition gives a boolean expression which indicates whether the 24654constraint matches. 24655 24656 -- MD Expression: define_constraint name docstring exp 24657 The NAME and DOCSTRING arguments are the same as for 24658 'define_register_constraint', but note that the docstring comes 24659 immediately after the name for these expressions. EXP is an RTL 24660 expression, obeying the same rules as the RTL expressions in 24661 predicate definitions. *Note Defining Predicates::, for details. 24662 If it evaluates true, the constraint matches; if it evaluates 24663 false, it doesn't. Constraint expressions should indicate which 24664 RTL codes they might match, just like predicate expressions. 24665 24666 'match_test' C expressions have access to the following variables: 24667 24668 OP 24669 The RTL object defining the operand. 24670 MODE 24671 The machine mode of OP. 24672 IVAL 24673 'INTVAL (OP)', if OP is a 'const_int'. 24674 HVAL 24675 'CONST_DOUBLE_HIGH (OP)', if OP is an integer 'const_double'. 24676 LVAL 24677 'CONST_DOUBLE_LOW (OP)', if OP is an integer 'const_double'. 24678 RVAL 24679 'CONST_DOUBLE_REAL_VALUE (OP)', if OP is a floating-point 24680 'const_double'. 24681 24682 The *VAL variables should only be used once another piece of the 24683 expression has verified that OP is the appropriate kind of RTL 24684 object. 24685 24686 Most non-register constraints should be defined with 24687'define_constraint'. The remaining two definition expressions are only 24688appropriate for constraints that should be handled specially by 'reload' 24689if they fail to match. 24690 24691 -- MD Expression: define_memory_constraint name docstring exp 24692 Use this expression for constraints that match a subset of all 24693 memory operands: that is, 'reload' can make them match by 24694 converting the operand to the form '(mem (reg X))', where X is a 24695 base register (from the register class specified by 24696 'BASE_REG_CLASS', *note Register Classes::). 24697 24698 For example, on the S/390, some instructions do not accept 24699 arbitrary memory references, but only those that do not make use of 24700 an index register. The constraint letter 'Q' is defined to 24701 represent a memory address of this type. If 'Q' is defined with 24702 'define_memory_constraint', a 'Q' constraint can handle any memory 24703 operand, because 'reload' knows it can simply copy the memory 24704 address into a base register if required. This is analogous to the 24705 way an 'o' constraint can handle any memory operand. 24706 24707 The syntax and semantics are otherwise identical to 24708 'define_constraint'. 24709 24710 -- MD Expression: define_special_memory_constraint name docstring exp 24711 Use this expression for constraints that match a subset of all 24712 memory operands: that is, 'reload' cannot make them match by 24713 reloading the address as it is described for 24714 'define_memory_constraint' or such address reload is undesirable 24715 with the performance point of view. 24716 24717 For example, 'define_special_memory_constraint' can be useful if 24718 specifically aligned memory is necessary or desirable for some insn 24719 operand. 24720 24721 The syntax and semantics are otherwise identical to 24722 'define_constraint'. 24723 24724 -- MD Expression: define_address_constraint name docstring exp 24725 Use this expression for constraints that match a subset of all 24726 address operands: that is, 'reload' can make the constraint match 24727 by converting the operand to the form '(reg X)', again with X a 24728 base register. 24729 24730 Constraints defined with 'define_address_constraint' can only be 24731 used with the 'address_operand' predicate, or machine-specific 24732 predicates that work the same way. They are treated analogously to 24733 the generic 'p' constraint. 24734 24735 The syntax and semantics are otherwise identical to 24736 'define_constraint'. 24737 24738 For historical reasons, names beginning with the letters 'G H' are 24739reserved for constraints that match only 'const_double's, and names 24740beginning with the letters 'I J K L M N O P' are reserved for 24741constraints that match only 'const_int's. This may change in the 24742future. For the time being, constraints with these names must be 24743written in a stylized form, so that 'genpreds' can tell you did it 24744correctly: 24745 24746 (define_constraint "[GHIJKLMNOP]..." 24747 "DOC..." 24748 (and (match_code "const_int") ; 'const_double' for G/H 24749 CONDITION...)) ; usually a 'match_test' 24750 24751 It is fine to use names beginning with other letters for constraints 24752that match 'const_double's or 'const_int's. 24753 24754 Each docstring in a constraint definition should be one or more 24755complete sentences, marked up in Texinfo format. _They are currently 24756unused._ In the future they will be copied into the GCC manual, in 24757*note Machine Constraints::, replacing the hand-maintained tables 24758currently found in that section. Also, in the future the compiler may 24759use this to give more helpful diagnostics when poor choice of 'asm' 24760constraints causes a reload failure. 24761 24762 If you put the pseudo-Texinfo directive '@internal' at the beginning of 24763a docstring, then (in the future) it will appear only in the internals 24764manual's version of the machine-specific constraint tables. Use this 24765for constraints that should not appear in 'asm' statements. 24766 24767 24768File: gccint.info, Node: C Constraint Interface, Prev: Define Constraints, Up: Constraints 24769 2477017.8.8 Testing constraints from C 24771--------------------------------- 24772 24773It is occasionally useful to test a constraint from C code rather than 24774implicitly via the constraint string in a 'match_operand'. The 24775generated file 'tm_p.h' declares a few interfaces for working with 24776constraints. At present these are defined for all constraints except 24777'g' (which is equivalent to 'general_operand'). 24778 24779 Some valid constraint names are not valid C identifiers, so there is a 24780mangling scheme for referring to them from C. Constraint names that do 24781not contain angle brackets or underscores are left unchanged. 24782Underscores are doubled, each '<' is replaced with '_l', and each '>' 24783with '_g'. Here are some examples: 24784 24785 *Original* *Mangled* 24786 x x 24787 P42x P42x 24788 P4_x P4__x 24789 P4>x P4_gx 24790 P4>> P4_g_g 24791 P4_g> P4__g_g 24792 24793 Throughout this section, the variable C is either a constraint in the 24794abstract sense, or a constant from 'enum constraint_num'; the variable M 24795is a mangled constraint name (usually as part of a larger identifier). 24796 24797 -- Enum: constraint_num 24798 For each constraint except 'g', there is a corresponding 24799 enumeration constant: 'CONSTRAINT_' plus the mangled name of the 24800 constraint. Functions that take an 'enum constraint_num' as an 24801 argument expect one of these constants. 24802 24803 -- Function: inline bool satisfies_constraint_M (rtx EXP) 24804 For each non-register constraint M except 'g', there is one of 24805 these functions; it returns 'true' if EXP satisfies the constraint. 24806 These functions are only visible if 'rtl.h' was included before 24807 'tm_p.h'. 24808 24809 -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num 24810 C) 24811 Like the 'satisfies_constraint_M' functions, but the constraint to 24812 test is given as an argument, C. If C specifies a register 24813 constraint, this function will always return 'false'. 24814 24815 -- Function: enum reg_class reg_class_for_constraint (enum 24816 constraint_num C) 24817 Returns the register class associated with C. If C is not a 24818 register constraint, or those registers are not available for the 24819 currently selected subtarget, returns 'NO_REGS'. 24820 24821 Here is an example use of 'satisfies_constraint_M'. In peephole 24822optimizations (*note Peephole Definitions::), operand constraint strings 24823are ignored, so if there are relevant constraints, they must be tested 24824in the C condition. In the example, the optimization is applied if 24825operand 2 does _not_ satisfy the 'K' constraint. (This is a simplified 24826version of a peephole definition from the i386 machine description.) 24827 24828 (define_peephole2 24829 [(match_scratch:SI 3 "r") 24830 (set (match_operand:SI 0 "register_operand" "") 24831 (mult:SI (match_operand:SI 1 "memory_operand" "") 24832 (match_operand:SI 2 "immediate_operand" "")))] 24833 24834 "!satisfies_constraint_K (operands[2])" 24835 24836 [(set (match_dup 3) (match_dup 1)) 24837 (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))] 24838 24839 "") 24840 24841 24842File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc 24843 2484417.9 Standard Pattern Names For Generation 24845========================================== 24846 24847Here is a table of the instruction names that are meaningful in the RTL 24848generation pass of the compiler. Giving one of these names to an 24849instruction pattern tells the RTL generation pass that it can use the 24850pattern to accomplish a certain task. 24851 24852'movM' 24853 Here M stands for a two-letter machine mode name, in lowercase. 24854 This instruction pattern moves data with that machine mode from 24855 operand 1 to operand 0. For example, 'movsi' moves full-word data. 24856 24857 If operand 0 is a 'subreg' with mode M of a register whose own mode 24858 is wider than M, the effect of this instruction is to store the 24859 specified value in the part of the register that corresponds to 24860 mode M. Bits outside of M, but which are within the same target 24861 word as the 'subreg' are undefined. Bits which are outside the 24862 target word are left unchanged. 24863 24864 This class of patterns is special in several ways. First of all, 24865 each of these names up to and including full word size _must_ be 24866 defined, because there is no other way to copy a datum from one 24867 place to another. If there are patterns accepting operands in 24868 larger modes, 'movM' must be defined for integer modes of those 24869 sizes. 24870 24871 Second, these patterns are not used solely in the RTL generation 24872 pass. Even the reload pass can generate move insns to copy values 24873 from stack slots into temporary registers. When it does so, one of 24874 the operands is a hard register and the other is an operand that 24875 can need to be reloaded into a register. 24876 24877 Therefore, when given such a pair of operands, the pattern must 24878 generate RTL which needs no reloading and needs no temporary 24879 registers--no registers other than the operands. For example, if 24880 you support the pattern with a 'define_expand', then in such a case 24881 the 'define_expand' mustn't call 'force_reg' or any other such 24882 function which might generate new pseudo registers. 24883 24884 This requirement exists even for subword modes on a RISC machine 24885 where fetching those modes from memory normally requires several 24886 insns and some temporary registers. 24887 24888 During reload a memory reference with an invalid address may be 24889 passed as an operand. Such an address will be replaced with a 24890 valid address later in the reload pass. In this case, nothing may 24891 be done with the address except to use it as it stands. If it is 24892 copied, it will not be replaced with a valid address. No attempt 24893 should be made to make such an address into a valid address and no 24894 routine (such as 'change_address') that will do so may be called. 24895 Note that 'general_operand' will fail when applied to such an 24896 address. 24897 24898 The global variable 'reload_in_progress' (which must be explicitly 24899 declared if required) can be used to determine whether such special 24900 handling is required. 24901 24902 The variety of operands that have reloads depends on the rest of 24903 the machine description, but typically on a RISC machine these can 24904 only be pseudo registers that did not get hard registers, while on 24905 other machines explicit memory references will get optional 24906 reloads. 24907 24908 If a scratch register is required to move an object to or from 24909 memory, it can be allocated using 'gen_reg_rtx' prior to life 24910 analysis. 24911 24912 If there are cases which need scratch registers during or after 24913 reload, you must provide an appropriate secondary_reload target 24914 hook. 24915 24916 The macro 'can_create_pseudo_p' can be used to determine if it is 24917 unsafe to create new pseudo registers. If this variable is 24918 nonzero, then it is unsafe to call 'gen_reg_rtx' to allocate a new 24919 pseudo. 24920 24921 The constraints on a 'movM' must permit moving any hard register to 24922 any other hard register provided that 'TARGET_HARD_REGNO_MODE_OK' 24923 permits mode M in both registers and 'TARGET_REGISTER_MOVE_COST' 24924 applied to their classes returns a value of 2. 24925 24926 It is obligatory to support floating point 'movM' instructions into 24927 and out of any registers that can hold fixed point values, because 24928 unions and structures (which have modes 'SImode' or 'DImode') can 24929 be in those registers and they may have floating point members. 24930 24931 There may also be a need to support fixed point 'movM' instructions 24932 in and out of floating point registers. Unfortunately, I have 24933 forgotten why this was so, and I don't know whether it is still 24934 true. If 'TARGET_HARD_REGNO_MODE_OK' rejects fixed point values in 24935 floating point registers, then the constraints of the fixed point 24936 'movM' instructions must be designed to avoid ever trying to reload 24937 into a floating point register. 24938 24939'reload_inM' 24940'reload_outM' 24941 These named patterns have been obsoleted by the target hook 24942 'secondary_reload'. 24943 24944 Like 'movM', but used when a scratch register is required to move 24945 between operand 0 and operand 1. Operand 2 describes the scratch 24946 register. See the discussion of the 'SECONDARY_RELOAD_CLASS' macro 24947 in *note Register Classes::. 24948 24949 There are special restrictions on the form of the 'match_operand's 24950 used in these patterns. First, only the predicate for the reload 24951 operand is examined, i.e., 'reload_in' examines operand 1, but not 24952 the predicates for operand 0 or 2. Second, there may be only one 24953 alternative in the constraints. Third, only a single register 24954 class letter may be used for the constraint; subsequent constraint 24955 letters are ignored. As a special exception, an empty constraint 24956 string matches the 'ALL_REGS' register class. This may relieve 24957 ports of the burden of defining an 'ALL_REGS' constraint letter 24958 just for these patterns. 24959 24960'movstrictM' 24961 Like 'movM' except that if operand 0 is a 'subreg' with mode M of a 24962 register whose natural mode is wider, the 'movstrictM' instruction 24963 is guaranteed not to alter any of the register except the part 24964 which belongs to mode M. 24965 24966'movmisalignM' 24967 This variant of a move pattern is designed to load or store a value 24968 from a memory address that is not naturally aligned for its mode. 24969 For a store, the memory will be in operand 0; for a load, the 24970 memory will be in operand 1. The other operand is guaranteed not 24971 to be a memory, so that it's easy to tell whether this is a load or 24972 store. 24973 24974 This pattern is used by the autovectorizer, and when expanding a 24975 'MISALIGNED_INDIRECT_REF' expression. 24976 24977'load_multiple' 24978 Load several consecutive memory locations into consecutive 24979 registers. Operand 0 is the first of the consecutive registers, 24980 operand 1 is the first memory location, and operand 2 is a 24981 constant: the number of consecutive registers. 24982 24983 Define this only if the target machine really has such an 24984 instruction; do not define this if the most efficient way of 24985 loading consecutive registers from memory is to do them one at a 24986 time. 24987 24988 On some machines, there are restrictions as to which consecutive 24989 registers can be stored into memory, such as particular starting or 24990 ending register numbers or only a range of valid counts. For those 24991 machines, use a 'define_expand' (*note Expander Definitions::) and 24992 make the pattern fail if the restrictions are not met. 24993 24994 Write the generated insn as a 'parallel' with elements being a 24995 'set' of one register from the appropriate memory location (you may 24996 also need 'use' or 'clobber' elements). Use a 'match_parallel' 24997 (*note RTL Template::) to recognize the insn. See 'rs6000.md' for 24998 examples of the use of this insn pattern. 24999 25000'store_multiple' 25001 Similar to 'load_multiple', but store several consecutive registers 25002 into consecutive memory locations. Operand 0 is the first of the 25003 consecutive memory locations, operand 1 is the first register, and 25004 operand 2 is a constant: the number of consecutive registers. 25005 25006'vec_load_lanesMN' 25007 Perform an interleaved load of several vectors from memory operand 25008 1 into register operand 0. Both operands have mode M. The 25009 register operand is viewed as holding consecutive vectors of mode 25010 N, while the memory operand is a flat array that contains the same 25011 number of elements. The operation is equivalent to: 25012 25013 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 25014 for (j = 0; j < GET_MODE_NUNITS (N); j++) 25015 for (i = 0; i < c; i++) 25016 operand0[i][j] = operand1[j * c + i]; 25017 25018 For example, 'vec_load_lanestiv4hi' loads 8 16-bit values from 25019 memory into a register of mode 'TI'. The register contains two 25020 consecutive vectors of mode 'V4HI'. 25021 25022 This pattern can only be used if: 25023 TARGET_ARRAY_MODE_SUPPORTED_P (N, C) 25024 is true. GCC assumes that, if a target supports this kind of 25025 instruction for some mode N, it also supports unaligned loads for 25026 vectors of mode N. 25027 25028 This pattern is not allowed to 'FAIL'. 25029 25030'vec_mask_load_lanesMN' 25031 Like 'vec_load_lanesMN', but takes an additional mask operand 25032 (operand 2) that specifies which elements of the destination 25033 vectors should be loaded. Other elements of the destination 25034 vectors are set to zero. The operation is equivalent to: 25035 25036 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 25037 for (j = 0; j < GET_MODE_NUNITS (N); j++) 25038 if (operand2[j]) 25039 for (i = 0; i < c; i++) 25040 operand0[i][j] = operand1[j * c + i]; 25041 else 25042 for (i = 0; i < c; i++) 25043 operand0[i][j] = 0; 25044 25045 This pattern is not allowed to 'FAIL'. 25046 25047'vec_store_lanesMN' 25048 Equivalent to 'vec_load_lanesMN', with the memory and register 25049 operands reversed. That is, the instruction is equivalent to: 25050 25051 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 25052 for (j = 0; j < GET_MODE_NUNITS (N); j++) 25053 for (i = 0; i < c; i++) 25054 operand0[j * c + i] = operand1[i][j]; 25055 25056 for a memory operand 0 and register operand 1. 25057 25058 This pattern is not allowed to 'FAIL'. 25059 25060'vec_mask_store_lanesMN' 25061 Like 'vec_store_lanesMN', but takes an additional mask operand 25062 (operand 2) that specifies which elements of the source vectors 25063 should be stored. The operation is equivalent to: 25064 25065 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 25066 for (j = 0; j < GET_MODE_NUNITS (N); j++) 25067 if (operand2[j]) 25068 for (i = 0; i < c; i++) 25069 operand0[j * c + i] = operand1[i][j]; 25070 25071 This pattern is not allowed to 'FAIL'. 25072 25073'gather_loadM' 25074 Load several separate memory locations into a vector of mode M. 25075 Operand 1 is a scalar base address and operand 2 is a vector of 25076 offsets from that base. Operand 0 is a destination vector with the 25077 same number of elements as the offset. For each element index I: 25078 25079 * extend the offset element I to address width, using zero 25080 extension if operand 3 is 1 and sign extension if operand 3 is 25081 zero; 25082 * multiply the extended offset by operand 4; 25083 * add the result to the base; and 25084 * load the value at that address into element I of operand 0. 25085 25086 The value of operand 3 does not matter if the offsets are already 25087 address width. 25088 25089'mask_gather_loadM' 25090 Like 'gather_loadM', but takes an extra mask operand as operand 5. 25091 Bit I of the mask is set if element I of the result should be 25092 loaded from memory and clear if element I of the result should be 25093 set to zero. 25094 25095'scatter_storeM' 25096 Store a vector of mode M into several distinct memory locations. 25097 Operand 0 is a scalar base address and operand 1 is a vector of 25098 offsets from that base. Operand 4 is the vector of values that 25099 should be stored, which has the same number of elements as the 25100 offset. For each element index I: 25101 25102 * extend the offset element I to address width, using zero 25103 extension if operand 2 is 1 and sign extension if operand 2 is 25104 zero; 25105 * multiply the extended offset by operand 3; 25106 * add the result to the base; and 25107 * store element I of operand 4 to that address. 25108 25109 The value of operand 2 does not matter if the offsets are already 25110 address width. 25111 25112'mask_scatter_storeM' 25113 Like 'scatter_storeM', but takes an extra mask operand as operand 25114 5. Bit I of the mask is set if element I of the result should be 25115 stored to memory. 25116 25117'vec_setM' 25118 Set given field in the vector value. Operand 0 is the vector to 25119 modify, operand 1 is new value of field and operand 2 specify the 25120 field index. 25121 25122'vec_extractMN' 25123 Extract given field from the vector value. Operand 1 is the 25124 vector, operand 2 specify field index and operand 0 place to store 25125 value into. The N mode is the mode of the field or vector of 25126 fields that should be extracted, should be either element mode of 25127 the vector mode M, or a vector mode with the same element mode and 25128 smaller number of elements. If N is a vector mode, the index is 25129 counted in units of that mode. 25130 25131'vec_initMN' 25132 Initialize the vector to given values. Operand 0 is the vector to 25133 initialize and operand 1 is parallel containing values for 25134 individual fields. The N mode is the mode of the elements, should 25135 be either element mode of the vector mode M, or a vector mode with 25136 the same element mode and smaller number of elements. 25137 25138'vec_duplicateM' 25139 Initialize vector output operand 0 so that each element has the 25140 value given by scalar input operand 1. The vector has mode M and 25141 the scalar has the mode appropriate for one element of M. 25142 25143 This pattern only handles duplicates of non-constant inputs. 25144 Constant vectors go through the 'movM' pattern instead. 25145 25146 This pattern is not allowed to 'FAIL'. 25147 25148'vec_seriesM' 25149 Initialize vector output operand 0 so that element I is equal to 25150 operand 1 plus I times operand 2. In other words, create a linear 25151 series whose base value is operand 1 and whose step is operand 2. 25152 25153 The vector output has mode M and the scalar inputs have the mode 25154 appropriate for one element of M. This pattern is not used for 25155 floating-point vectors, in order to avoid having to specify the 25156 rounding behavior for I > 1. 25157 25158 This pattern is not allowed to 'FAIL'. 25159 25160'while_ultMN' 25161 Set operand 0 to a mask that is true while incrementing operand 1 25162 gives a value that is less than operand 2. Operand 0 has mode N 25163 and operands 1 and 2 are scalar integers of mode M. The operation 25164 is equivalent to: 25165 25166 operand0[0] = operand1 < operand2; 25167 for (i = 1; i < GET_MODE_NUNITS (N); i++) 25168 operand0[i] = operand0[i - 1] && (operand1 + i < operand2); 25169 25170'vec_cmpMN' 25171 Output a vector comparison. Operand 0 of mode N is the destination 25172 for predicate in operand 1 which is a signed vector comparison with 25173 operands of mode M in operands 2 and 3. Predicate is computed by 25174 element-wise evaluation of the vector comparison with a truth value 25175 of all-ones and a false value of all-zeros. 25176 25177'vec_cmpuMN' 25178 Similar to 'vec_cmpMN' but perform unsigned vector comparison. 25179 25180'vec_cmpeqMN' 25181 Similar to 'vec_cmpMN' but perform equality or non-equality vector 25182 comparison only. If 'vec_cmpMN' or 'vec_cmpuMN' instruction 25183 pattern is supported, it will be preferred over 'vec_cmpeqMN', so 25184 there is no need to define this instruction pattern if the others 25185 are supported. 25186 25187'vcondMN' 25188 Output a conditional vector move. Operand 0 is the destination to 25189 receive a combination of operand 1 and operand 2, which are of mode 25190 M, dependent on the outcome of the predicate in operand 3 which is 25191 a signed vector comparison with operands of mode N in operands 4 25192 and 5. The modes M and N should have the same size. Operand 0 25193 will be set to the value OP1 & MSK | OP2 & ~MSK where MSK is 25194 computed by element-wise evaluation of the vector comparison with a 25195 truth value of all-ones and a false value of all-zeros. 25196 25197'vconduMN' 25198 Similar to 'vcondMN' but performs unsigned vector comparison. 25199 25200'vcondeqMN' 25201 Similar to 'vcondMN' but performs equality or non-equality vector 25202 comparison only. If 'vcondMN' or 'vconduMN' instruction pattern is 25203 supported, it will be preferred over 'vcondeqMN', so there is no 25204 need to define this instruction pattern if the others are 25205 supported. 25206 25207'vcond_mask_MN' 25208 Similar to 'vcondMN' but operand 3 holds a pre-computed result of 25209 vector comparison. 25210 25211'maskloadMN' 25212 Perform a masked load of vector from memory operand 1 of mode M 25213 into register operand 0. Mask is provided in register operand 2 of 25214 mode N. 25215 25216 This pattern is not allowed to 'FAIL'. 25217 25218'maskstoreMN' 25219 Perform a masked store of vector from register operand 1 of mode M 25220 into memory operand 0. Mask is provided in register operand 2 of 25221 mode N. 25222 25223 This pattern is not allowed to 'FAIL'. 25224 25225'vec_permM' 25226 Output a (variable) vector permutation. Operand 0 is the 25227 destination to receive elements from operand 1 and operand 2, which 25228 are of mode M. Operand 3 is the "selector". It is an integral 25229 mode vector of the same width and number of elements as mode M. 25230 25231 The input elements are numbered from 0 in operand 1 through 2*N-1 25232 in operand 2. The elements of the selector must be computed modulo 25233 2*N. Note that if 'rtx_equal_p(operand1, operand2)', this can be 25234 implemented with just operand 1 and selector elements modulo N. 25235 25236 In order to make things easy for a number of targets, if there is 25237 no 'vec_perm' pattern for mode M, but there is for mode Q where Q 25238 is a vector of 'QImode' of the same width as M, the middle-end will 25239 lower the mode M 'VEC_PERM_EXPR' to mode Q. 25240 25241 See also 'TARGET_VECTORIZER_VEC_PERM_CONST', which performs the 25242 analogous operation for constant selectors. 25243 25244'pushM1' 25245 Output a push instruction. Operand 0 is value to push. Used only 25246 when 'PUSH_ROUNDING' is defined. For historical reason, this 25247 pattern may be missing and in such case an 'mov' expander is used 25248 instead, with a 'MEM' expression forming the push operation. The 25249 'mov' expander method is deprecated. 25250 25251'addM3' 25252 Add operand 2 and operand 1, storing the result in operand 0. All 25253 operands must have mode M. This can be used even on two-address 25254 machines, by means of constraints requiring operands 1 and 0 to be 25255 the same location. 25256 25257'ssaddM3', 'usaddM3' 25258'subM3', 'sssubM3', 'ussubM3' 25259'mulM3', 'ssmulM3', 'usmulM3' 25260'divM3', 'ssdivM3' 25261'udivM3', 'usdivM3' 25262'modM3', 'umodM3' 25263'uminM3', 'umaxM3' 25264'andM3', 'iorM3', 'xorM3' 25265 Similar, for other arithmetic operations. 25266 25267'addvM4' 25268 Like 'addM3' but takes a 'code_label' as operand 3 and emits code 25269 to jump to it if signed overflow occurs during the addition. This 25270 pattern is used to implement the built-in functions performing 25271 signed integer addition with overflow checking. 25272 25273'subvM4', 'mulvM4' 25274 Similar, for other signed arithmetic operations. 25275 25276'uaddvM4' 25277 Like 'addvM4' but for unsigned addition. That is to say, the 25278 operation is the same as signed addition but the jump is taken only 25279 on unsigned overflow. 25280 25281'usubvM4', 'umulvM4' 25282 Similar, for other unsigned arithmetic operations. 25283 25284'addptrM3' 25285 Like 'addM3' but is guaranteed to only be used for address 25286 calculations. The expanded code is not allowed to clobber the 25287 condition code. It only needs to be defined if 'addM3' sets the 25288 condition code. If adds used for address calculations and normal 25289 adds are not compatible it is required to expand a distinct pattern 25290 (e.g. using an unspec). The pattern is used by LRA to emit address 25291 calculations. 'addM3' is used if 'addptrM3' is not defined. 25292 25293'fmaM4' 25294 Multiply operand 2 and operand 1, then add operand 3, storing the 25295 result in operand 0 without doing an intermediate rounding step. 25296 All operands must have mode M. This pattern is used to implement 25297 the 'fma', 'fmaf', and 'fmal' builtin functions from the ISO C99 25298 standard. 25299 25300'fmsM4' 25301 Like 'fmaM4', except operand 3 subtracted from the product instead 25302 of added to the product. This is represented in the rtl as 25303 25304 (fma:M OP1 OP2 (neg:M OP3)) 25305 25306'fnmaM4' 25307 Like 'fmaM4' except that the intermediate product is negated before 25308 being added to operand 3. This is represented in the rtl as 25309 25310 (fma:M (neg:M OP1) OP2 OP3) 25311 25312'fnmsM4' 25313 Like 'fmsM4' except that the intermediate product is negated before 25314 subtracting operand 3. This is represented in the rtl as 25315 25316 (fma:M (neg:M OP1) OP2 (neg:M OP3)) 25317 25318'sminM3', 'smaxM3' 25319 Signed minimum and maximum operations. When used with floating 25320 point, if both operands are zeros, or if either operand is 'NaN', 25321 then it is unspecified which of the two operands is returned as the 25322 result. 25323 25324'fminM3', 'fmaxM3' 25325 IEEE-conformant minimum and maximum operations. If one operand is 25326 a quiet 'NaN', then the other operand is returned. If both 25327 operands are quiet 'NaN', then a quiet 'NaN' is returned. In the 25328 case when gcc supports signaling 'NaN' (-fsignaling-nans) an 25329 invalid floating point exception is raised and a quiet 'NaN' is 25330 returned. 25331 25332 All operands have mode M, which is a scalar or vector 25333 floating-point mode. These patterns are not allowed to 'FAIL'. 25334 25335'reduc_smin_scal_M', 'reduc_smax_scal_M' 25336 Find the signed minimum/maximum of the elements of a vector. The 25337 vector is operand 1, and operand 0 is the scalar result, with mode 25338 equal to the mode of the elements of the input vector. 25339 25340'reduc_umin_scal_M', 'reduc_umax_scal_M' 25341 Find the unsigned minimum/maximum of the elements of a vector. The 25342 vector is operand 1, and operand 0 is the scalar result, with mode 25343 equal to the mode of the elements of the input vector. 25344 25345'reduc_plus_scal_M' 25346 Compute the sum of the elements of a vector. The vector is operand 25347 1, and operand 0 is the scalar result, with mode equal to the mode 25348 of the elements of the input vector. 25349 25350'reduc_and_scal_M' 25351'reduc_ior_scal_M' 25352'reduc_xor_scal_M' 25353 Compute the bitwise 'AND'/'IOR'/'XOR' reduction of the elements of 25354 a vector of mode M. Operand 1 is the vector input and operand 0 is 25355 the scalar result. The mode of the scalar result is the same as 25356 one element of M. 25357 25358'extract_last_M' 25359 Find the last set bit in mask operand 1 and extract the associated 25360 element of vector operand 2. Store the result in scalar operand 0. 25361 Operand 2 has vector mode M while operand 0 has the mode 25362 appropriate for one element of M. Operand 1 has the usual mask 25363 mode for vectors of mode M; see 'TARGET_VECTORIZE_GET_MASK_MODE'. 25364 25365'fold_extract_last_M' 25366 If any bits of mask operand 2 are set, find the last set bit, 25367 extract the associated element from vector operand 3, and store the 25368 result in operand 0. Store operand 1 in operand 0 otherwise. 25369 Operand 3 has mode M and operands 0 and 1 have the mode appropriate 25370 for one element of M. Operand 2 has the usual mask mode for 25371 vectors of mode M; see 'TARGET_VECTORIZE_GET_MASK_MODE'. 25372 25373'fold_left_plus_M' 25374 Take scalar operand 1 and successively add each element from vector 25375 operand 2. Store the result in scalar operand 0. The vector has 25376 mode M and the scalars have the mode appropriate for one element of 25377 M. The operation is strictly in-order: there is no reassociation. 25378 25379'sdot_prodM' 25380'udot_prodM' 25381 Compute the sum of the products of two signed/unsigned elements. 25382 Operand 1 and operand 2 are of the same mode. Their product, which 25383 is of a wider mode, is computed and added to operand 3. Operand 3 25384 is of a mode equal or wider than the mode of the product. The 25385 result is placed in operand 0, which is of the same mode as operand 25386 3. 25387 25388'ssadM' 25389'usadM' 25390 Compute the sum of absolute differences of two signed/unsigned 25391 elements. Operand 1 and operand 2 are of the same mode. Their 25392 absolute difference, which is of a wider mode, is computed and 25393 added to operand 3. Operand 3 is of a mode equal or wider than the 25394 mode of the absolute difference. The result is placed in operand 25395 0, which is of the same mode as operand 3. 25396 25397'widen_ssumM3' 25398'widen_usumM3' 25399 Operands 0 and 2 are of the same mode, which is wider than the mode 25400 of operand 1. Add operand 1 to operand 2 and place the widened 25401 result in operand 0. (This is used express accumulation of 25402 elements into an accumulator of a wider mode.) 25403 25404'vec_shl_insert_M' 25405 Shift the elements in vector input operand 1 left one element (i.e. 25406 away from element 0) and fill the vacated element 0 with the scalar 25407 in operand 2. Store the result in vector output operand 0. 25408 Operands 0 and 1 have mode M and operand 2 has the mode appropriate 25409 for one element of M. 25410 25411'vec_shr_M' 25412 Whole vector right shift in bits, i.e. towards element 0. Operand 25413 1 is a vector to be shifted. Operand 2 is an integer shift amount 25414 in bits. Operand 0 is where the resulting shifted vector is 25415 stored. The output and input vectors should have the same modes. 25416 25417'vec_pack_trunc_M' 25418 Narrow (demote) and merge the elements of two vectors. Operands 1 25419 and 2 are vectors of the same mode having N integral or floating 25420 point elements of size S. Operand 0 is the resulting vector in 25421 which 2*N elements of size N/2 are concatenated after narrowing 25422 them down using truncation. 25423 25424'vec_pack_sbool_trunc_M' 25425 Narrow and merge the elements of two vectors. Operands 1 and 2 are 25426 vectors of the same type having N boolean elements. Operand 0 is 25427 the resulting vector in which 2*N elements are concatenated. The 25428 last operand (operand 3) is the number of elements in the output 25429 vector 2*N as a 'CONST_INT'. This instruction pattern is used when 25430 all the vector input and output operands have the same scalar mode 25431 M and thus using 'vec_pack_trunc_M' would be ambiguous. 25432 25433'vec_pack_ssat_M', 'vec_pack_usat_M' 25434 Narrow (demote) and merge the elements of two vectors. Operands 1 25435 and 2 are vectors of the same mode having N integral elements of 25436 size S. Operand 0 is the resulting vector in which the elements of 25437 the two input vectors are concatenated after narrowing them down 25438 using signed/unsigned saturating arithmetic. 25439 25440'vec_pack_sfix_trunc_M', 'vec_pack_ufix_trunc_M' 25441 Narrow, convert to signed/unsigned integral type and merge the 25442 elements of two vectors. Operands 1 and 2 are vectors of the same 25443 mode having N floating point elements of size S. Operand 0 is the 25444 resulting vector in which 2*N elements of size N/2 are 25445 concatenated. 25446 25447'vec_packs_float_M', 'vec_packu_float_M' 25448 Narrow, convert to floating point type and merge the elements of 25449 two vectors. Operands 1 and 2 are vectors of the same mode having 25450 N signed/unsigned integral elements of size S. Operand 0 is the 25451 resulting vector in which 2*N elements of size N/2 are 25452 concatenated. 25453 25454'vec_unpacks_hi_M', 'vec_unpacks_lo_M' 25455 Extract and widen (promote) the high/low part of a vector of signed 25456 integral or floating point elements. The input vector (operand 1) 25457 has N elements of size S. Widen (promote) the high/low elements of 25458 the vector using signed or floating point extension and place the 25459 resulting N/2 values of size 2*S in the output vector (operand 0). 25460 25461'vec_unpacku_hi_M', 'vec_unpacku_lo_M' 25462 Extract and widen (promote) the high/low part of a vector of 25463 unsigned integral elements. The input vector (operand 1) has N 25464 elements of size S. Widen (promote) the high/low elements of the 25465 vector using zero extension and place the resulting N/2 values of 25466 size 2*S in the output vector (operand 0). 25467 25468'vec_unpacks_sbool_hi_M', 'vec_unpacks_sbool_lo_M' 25469 Extract the high/low part of a vector of boolean elements that have 25470 scalar mode M. The input vector (operand 1) has N elements, the 25471 output vector (operand 0) has N/2 elements. The last operand 25472 (operand 2) is the number of elements of the input vector N as a 25473 'CONST_INT'. These patterns are used if both the input and output 25474 vectors have the same scalar mode M and thus using 25475 'vec_unpacks_hi_M' or 'vec_unpacks_lo_M' would be ambiguous. 25476 25477'vec_unpacks_float_hi_M', 'vec_unpacks_float_lo_M' 25478'vec_unpacku_float_hi_M', 'vec_unpacku_float_lo_M' 25479 Extract, convert to floating point type and widen the high/low part 25480 of a vector of signed/unsigned integral elements. The input vector 25481 (operand 1) has N elements of size S. Convert the high/low 25482 elements of the vector using floating point conversion and place 25483 the resulting N/2 values of size 2*S in the output vector (operand 25484 0). 25485 25486'vec_unpack_sfix_trunc_hi_M', 25487'vec_unpack_sfix_trunc_lo_M' 25488'vec_unpack_ufix_trunc_hi_M' 25489'vec_unpack_ufix_trunc_lo_M' 25490 Extract, convert to signed/unsigned integer type and widen the 25491 high/low part of a vector of floating point elements. The input 25492 vector (operand 1) has N elements of size S. Convert the high/low 25493 elements of the vector to integers and place the resulting N/2 25494 values of size 2*S in the output vector (operand 0). 25495 25496'vec_widen_umult_hi_M', 'vec_widen_umult_lo_M' 25497'vec_widen_smult_hi_M', 'vec_widen_smult_lo_M' 25498'vec_widen_umult_even_M', 'vec_widen_umult_odd_M' 25499'vec_widen_smult_even_M', 'vec_widen_smult_odd_M' 25500 Signed/Unsigned widening multiplication. The two inputs (operands 25501 1 and 2) are vectors with N signed/unsigned elements of size S. 25502 Multiply the high/low or even/odd elements of the two vectors, and 25503 put the N/2 products of size 2*S in the output vector (operand 0). 25504 A target shouldn't implement even/odd pattern pair if it is less 25505 efficient than lo/hi one. 25506 25507'vec_widen_ushiftl_hi_M', 'vec_widen_ushiftl_lo_M' 25508'vec_widen_sshiftl_hi_M', 'vec_widen_sshiftl_lo_M' 25509 Signed/Unsigned widening shift left. The first input (operand 1) 25510 is a vector with N signed/unsigned elements of size S. Operand 2 25511 is a constant. Shift the high/low elements of operand 1, and put 25512 the N/2 results of size 2*S in the output vector (operand 0). 25513 25514'mulhisi3' 25515 Multiply operands 1 and 2, which have mode 'HImode', and store a 25516 'SImode' product in operand 0. 25517 25518'mulqihi3', 'mulsidi3' 25519 Similar widening-multiplication instructions of other widths. 25520 25521'umulqihi3', 'umulhisi3', 'umulsidi3' 25522 Similar widening-multiplication instructions that do unsigned 25523 multiplication. 25524 25525'usmulqihi3', 'usmulhisi3', 'usmulsidi3' 25526 Similar widening-multiplication instructions that interpret the 25527 first operand as unsigned and the second operand as signed, then do 25528 a signed multiplication. 25529 25530'smulM3_highpart' 25531 Perform a signed multiplication of operands 1 and 2, which have 25532 mode M, and store the most significant half of the product in 25533 operand 0. The least significant half of the product is discarded. 25534 25535'umulM3_highpart' 25536 Similar, but the multiplication is unsigned. 25537 25538'maddMN4' 25539 Multiply operands 1 and 2, sign-extend them to mode N, add operand 25540 3, and store the result in operand 0. Operands 1 and 2 have mode M 25541 and operands 0 and 3 have mode N. Both modes must be integer or 25542 fixed-point modes and N must be twice the size of M. 25543 25544 In other words, 'maddMN4' is like 'mulMN3' except that it also adds 25545 operand 3. 25546 25547 These instructions are not allowed to 'FAIL'. 25548 25549'umaddMN4' 25550 Like 'maddMN4', but zero-extend the multiplication operands instead 25551 of sign-extending them. 25552 25553'ssmaddMN4' 25554 Like 'maddMN4', but all involved operations must be 25555 signed-saturating. 25556 25557'usmaddMN4' 25558 Like 'umaddMN4', but all involved operations must be 25559 unsigned-saturating. 25560 25561'msubMN4' 25562 Multiply operands 1 and 2, sign-extend them to mode N, subtract the 25563 result from operand 3, and store the result in operand 0. Operands 25564 1 and 2 have mode M and operands 0 and 3 have mode N. Both modes 25565 must be integer or fixed-point modes and N must be twice the size 25566 of M. 25567 25568 In other words, 'msubMN4' is like 'mulMN3' except that it also 25569 subtracts the result from operand 3. 25570 25571 These instructions are not allowed to 'FAIL'. 25572 25573'umsubMN4' 25574 Like 'msubMN4', but zero-extend the multiplication operands instead 25575 of sign-extending them. 25576 25577'ssmsubMN4' 25578 Like 'msubMN4', but all involved operations must be 25579 signed-saturating. 25580 25581'usmsubMN4' 25582 Like 'umsubMN4', but all involved operations must be 25583 unsigned-saturating. 25584 25585'divmodM4' 25586 Signed division that produces both a quotient and a remainder. 25587 Operand 1 is divided by operand 2 to produce a quotient stored in 25588 operand 0 and a remainder stored in operand 3. 25589 25590 For machines with an instruction that produces both a quotient and 25591 a remainder, provide a pattern for 'divmodM4' but do not provide 25592 patterns for 'divM3' and 'modM3'. This allows optimization in the 25593 relatively common case when both the quotient and remainder are 25594 computed. 25595 25596 If an instruction that just produces a quotient or just a remainder 25597 exists and is more efficient than the instruction that produces 25598 both, write the output routine of 'divmodM4' to call 25599 'find_reg_note' and look for a 'REG_UNUSED' note on the quotient or 25600 remainder and generate the appropriate instruction. 25601 25602'udivmodM4' 25603 Similar, but does unsigned division. 25604 25605'ashlM3', 'ssashlM3', 'usashlM3' 25606 Arithmetic-shift operand 1 left by a number of bits specified by 25607 operand 2, and store the result in operand 0. Here M is the mode 25608 of operand 0 and operand 1; operand 2's mode is specified by the 25609 instruction pattern, and the compiler will convert the operand to 25610 that mode before generating the instruction. The shift or rotate 25611 expander or instruction pattern should explicitly specify the mode 25612 of the operand 2, it should never be 'VOIDmode'. The meaning of 25613 out-of-range shift counts can optionally be specified by 25614 'TARGET_SHIFT_TRUNCATION_MASK'. *Note 25615 TARGET_SHIFT_TRUNCATION_MASK::. Operand 2 is always a scalar type. 25616 25617'ashrM3', 'lshrM3', 'rotlM3', 'rotrM3' 25618 Other shift and rotate instructions, analogous to the 'ashlM3' 25619 instructions. Operand 2 is always a scalar type. 25620 25621'vashlM3', 'vashrM3', 'vlshrM3', 'vrotlM3', 'vrotrM3' 25622 Vector shift and rotate instructions that take vectors as operand 2 25623 instead of a scalar type. 25624 25625'avgM3_floor' 25626'uavgM3_floor' 25627 Signed and unsigned average instructions. These instructions add 25628 operands 1 and 2 without truncation, divide the result by 2, round 25629 towards -Inf, and store the result in operand 0. This is 25630 equivalent to the C code: 25631 narrow op0, op1, op2; 25632 ... 25633 op0 = (narrow) (((wide) op1 + (wide) op2) >> 1); 25634 where the sign of 'narrow' determines whether this is a signed or 25635 unsigned operation. 25636 25637'avgM3_ceil' 25638'uavgM3_ceil' 25639 Like 'avgM3_floor' and 'uavgM3_floor', but round towards +Inf. 25640 This is equivalent to the C code: 25641 narrow op0, op1, op2; 25642 ... 25643 op0 = (narrow) (((wide) op1 + (wide) op2 + 1) >> 1); 25644 25645'bswapM2' 25646 Reverse the order of bytes of operand 1 and store the result in 25647 operand 0. 25648 25649'negM2', 'ssnegM2', 'usnegM2' 25650 Negate operand 1 and store the result in operand 0. 25651 25652'negvM3' 25653 Like 'negM2' but takes a 'code_label' as operand 2 and emits code 25654 to jump to it if signed overflow occurs during the negation. 25655 25656'absM2' 25657 Store the absolute value of operand 1 into operand 0. 25658 25659'sqrtM2' 25660 Store the square root of operand 1 into operand 0. Both operands 25661 have mode M, which is a scalar or vector floating-point mode. 25662 25663 This pattern is not allowed to 'FAIL'. 25664 25665'rsqrtM2' 25666 Store the reciprocal of the square root of operand 1 into operand 25667 0. Both operands have mode M, which is a scalar or vector 25668 floating-point mode. 25669 25670 On most architectures this pattern is only approximate, so either 25671 its C condition or the 'TARGET_OPTAB_SUPPORTED_P' hook should check 25672 for the appropriate math flags. (Using the C condition is more 25673 direct, but using 'TARGET_OPTAB_SUPPORTED_P' can be useful if a 25674 target-specific built-in also uses the 'rsqrtM2' pattern.) 25675 25676 This pattern is not allowed to 'FAIL'. 25677 25678'fmodM3' 25679 Store the remainder of dividing operand 1 by operand 2 into operand 25680 0, rounded towards zero to an integer. All operands have mode M, 25681 which is a scalar or vector floating-point mode. 25682 25683 This pattern is not allowed to 'FAIL'. 25684 25685'remainderM3' 25686 Store the remainder of dividing operand 1 by operand 2 into operand 25687 0, rounded to the nearest integer. All operands have mode M, which 25688 is a scalar or vector floating-point mode. 25689 25690 This pattern is not allowed to 'FAIL'. 25691 25692'scalbM3' 25693 Raise 'FLT_RADIX' to the power of operand 2, multiply it by operand 25694 1, and store the result in operand 0. All operands have mode M, 25695 which is a scalar or vector floating-point mode. 25696 25697 This pattern is not allowed to 'FAIL'. 25698 25699'ldexpM3' 25700 Raise 2 to the power of operand 2, multiply it by operand 1, and 25701 store the result in operand 0. Operands 0 and 1 have mode M, which 25702 is a scalar or vector floating-point mode. Operand 2's mode has 25703 the same number of elements as M and each element is wide enough to 25704 store an 'int'. The integers are signed. 25705 25706 This pattern is not allowed to 'FAIL'. 25707 25708'cosM2' 25709 Store the cosine of operand 1 into operand 0. Both operands have 25710 mode M, which is a scalar or vector floating-point mode. 25711 25712 This pattern is not allowed to 'FAIL'. 25713 25714'sinM2' 25715 Store the sine of operand 1 into operand 0. Both operands have 25716 mode M, which is a scalar or vector floating-point mode. 25717 25718 This pattern is not allowed to 'FAIL'. 25719 25720'sincosM3' 25721 Store the cosine of operand 2 into operand 0 and the sine of 25722 operand 2 into operand 1. All operands have mode M, which is a 25723 scalar or vector floating-point mode. 25724 25725 Targets that can calculate the sine and cosine simultaneously can 25726 implement this pattern as opposed to implementing individual 25727 'sinM2' and 'cosM2' patterns. The 'sin' and 'cos' built-in 25728 functions will then be expanded to the 'sincosM3' pattern, with one 25729 of the output values left unused. 25730 25731'tanM2' 25732 Store the tangent of operand 1 into operand 0. Both operands have 25733 mode M, which is a scalar or vector floating-point mode. 25734 25735 This pattern is not allowed to 'FAIL'. 25736 25737'asinM2' 25738 Store the arc sine of operand 1 into operand 0. Both operands have 25739 mode M, which is a scalar or vector floating-point mode. 25740 25741 This pattern is not allowed to 'FAIL'. 25742 25743'acosM2' 25744 Store the arc cosine of operand 1 into operand 0. Both operands 25745 have mode M, which is a scalar or vector floating-point mode. 25746 25747 This pattern is not allowed to 'FAIL'. 25748 25749'atanM2' 25750 Store the arc tangent of operand 1 into operand 0. Both operands 25751 have mode M, which is a scalar or vector floating-point mode. 25752 25753 This pattern is not allowed to 'FAIL'. 25754 25755'expM2' 25756 Raise e (the base of natural logarithms) to the power of operand 1 25757 and store the result in operand 0. Both operands have mode M, 25758 which is a scalar or vector floating-point mode. 25759 25760 This pattern is not allowed to 'FAIL'. 25761 25762'expm1M2' 25763 Raise e (the base of natural logarithms) to the power of operand 1, 25764 subtract 1, and store the result in operand 0. Both operands have 25765 mode M, which is a scalar or vector floating-point mode. 25766 25767 For inputs close to zero, the pattern is expected to be more 25768 accurate than a separate 'expM2' and 'subM3' would be. 25769 25770 This pattern is not allowed to 'FAIL'. 25771 25772'exp10M2' 25773 Raise 10 to the power of operand 1 and store the result in operand 25774 0. Both operands have mode M, which is a scalar or vector 25775 floating-point mode. 25776 25777 This pattern is not allowed to 'FAIL'. 25778 25779'exp2M2' 25780 Raise 2 to the power of operand 1 and store the result in operand 25781 0. Both operands have mode M, which is a scalar or vector 25782 floating-point mode. 25783 25784 This pattern is not allowed to 'FAIL'. 25785 25786'logM2' 25787 Store the natural logarithm of operand 1 into operand 0. Both 25788 operands have mode M, which is a scalar or vector floating-point 25789 mode. 25790 25791 This pattern is not allowed to 'FAIL'. 25792 25793'log1pM2' 25794 Add 1 to operand 1, compute the natural logarithm, and store the 25795 result in operand 0. Both operands have mode M, which is a scalar 25796 or vector floating-point mode. 25797 25798 For inputs close to zero, the pattern is expected to be more 25799 accurate than a separate 'addM3' and 'logM2' would be. 25800 25801 This pattern is not allowed to 'FAIL'. 25802 25803'log10M2' 25804 Store the base-10 logarithm of operand 1 into operand 0. Both 25805 operands have mode M, which is a scalar or vector floating-point 25806 mode. 25807 25808 This pattern is not allowed to 'FAIL'. 25809 25810'log2M2' 25811 Store the base-2 logarithm of operand 1 into operand 0. Both 25812 operands have mode M, which is a scalar or vector floating-point 25813 mode. 25814 25815 This pattern is not allowed to 'FAIL'. 25816 25817'logbM2' 25818 Store the base-'FLT_RADIX' logarithm of operand 1 into operand 0. 25819 Both operands have mode M, which is a scalar or vector 25820 floating-point mode. 25821 25822 This pattern is not allowed to 'FAIL'. 25823 25824'significandM2' 25825 Store the significand of floating-point operand 1 in operand 0. 25826 Both operands have mode M, which is a scalar or vector 25827 floating-point mode. 25828 25829 This pattern is not allowed to 'FAIL'. 25830 25831'powM3' 25832 Store the value of operand 1 raised to the exponent operand 2 into 25833 operand 0. All operands have mode M, which is a scalar or vector 25834 floating-point mode. 25835 25836 This pattern is not allowed to 'FAIL'. 25837 25838'atan2M3' 25839 Store the arc tangent (inverse tangent) of operand 1 divided by 25840 operand 2 into operand 0, using the signs of both arguments to 25841 determine the quadrant of the result. All operands have mode M, 25842 which is a scalar or vector floating-point mode. 25843 25844 This pattern is not allowed to 'FAIL'. 25845 25846'floorM2' 25847 Store the largest integral value not greater than operand 1 in 25848 operand 0. Both operands have mode M, which is a scalar or vector 25849 floating-point mode. If '-ffp-int-builtin-inexact' is in effect, 25850 the "inexact" exception may be raised for noninteger operands; 25851 otherwise, it may not. 25852 25853 This pattern is not allowed to 'FAIL'. 25854 25855'btruncM2' 25856 Round operand 1 to an integer, towards zero, and store the result 25857 in operand 0. Both operands have mode M, which is a scalar or 25858 vector floating-point mode. If '-ffp-int-builtin-inexact' is in 25859 effect, the "inexact" exception may be raised for noninteger 25860 operands; otherwise, it may not. 25861 25862 This pattern is not allowed to 'FAIL'. 25863 25864'roundM2' 25865 Round operand 1 to the nearest integer, rounding away from zero in 25866 the event of a tie, and store the result in operand 0. Both 25867 operands have mode M, which is a scalar or vector floating-point 25868 mode. If '-ffp-int-builtin-inexact' is in effect, the "inexact" 25869 exception may be raised for noninteger operands; otherwise, it may 25870 not. 25871 25872 This pattern is not allowed to 'FAIL'. 25873 25874'ceilM2' 25875 Store the smallest integral value not less than operand 1 in 25876 operand 0. Both operands have mode M, which is a scalar or vector 25877 floating-point mode. If '-ffp-int-builtin-inexact' is in effect, 25878 the "inexact" exception may be raised for noninteger operands; 25879 otherwise, it may not. 25880 25881 This pattern is not allowed to 'FAIL'. 25882 25883'nearbyintM2' 25884 Round operand 1 to an integer, using the current rounding mode, and 25885 store the result in operand 0. Do not raise an inexact condition 25886 when the result is different from the argument. Both operands have 25887 mode M, which is a scalar or vector floating-point mode. 25888 25889 This pattern is not allowed to 'FAIL'. 25890 25891'rintM2' 25892 Round operand 1 to an integer, using the current rounding mode, and 25893 store the result in operand 0. Raise an inexact condition when the 25894 result is different from the argument. Both operands have mode M, 25895 which is a scalar or vector floating-point mode. 25896 25897 This pattern is not allowed to 'FAIL'. 25898 25899'lrintMN2' 25900 Convert operand 1 (valid for floating point mode M) to fixed point 25901 mode N as a signed number according to the current rounding mode 25902 and store in operand 0 (which has mode N). 25903 25904'lroundMN2' 25905 Convert operand 1 (valid for floating point mode M) to fixed point 25906 mode N as a signed number rounding to nearest and away from zero 25907 and store in operand 0 (which has mode N). 25908 25909'lfloorMN2' 25910 Convert operand 1 (valid for floating point mode M) to fixed point 25911 mode N as a signed number rounding down and store in operand 0 25912 (which has mode N). 25913 25914'lceilMN2' 25915 Convert operand 1 (valid for floating point mode M) to fixed point 25916 mode N as a signed number rounding up and store in operand 0 (which 25917 has mode N). 25918 25919'copysignM3' 25920 Store a value with the magnitude of operand 1 and the sign of 25921 operand 2 into operand 0. All operands have mode M, which is a 25922 scalar or vector floating-point mode. 25923 25924 This pattern is not allowed to 'FAIL'. 25925 25926'xorsignM3' 25927 Equivalent to 'op0 = op1 * copysign (1.0, op2)': store a value with 25928 the magnitude of operand 1 and the sign of operand 2 into operand 25929 0. All operands have mode M, which is a scalar or vector 25930 floating-point mode. 25931 25932 This pattern is not allowed to 'FAIL'. 25933 25934'ffsM2' 25935 Store into operand 0 one plus the index of the least significant 25936 1-bit of operand 1. If operand 1 is zero, store zero. 25937 25938 M is either a scalar or vector integer mode. When it is a scalar, 25939 operand 1 has mode M but operand 0 can have whatever scalar integer 25940 mode is suitable for the target. The compiler will insert 25941 conversion instructions as necessary (typically to convert the 25942 result to the same width as 'int'). When M is a vector, both 25943 operands must have mode M. 25944 25945 This pattern is not allowed to 'FAIL'. 25946 25947'clrsbM2' 25948 Count leading redundant sign bits. Store into operand 0 the number 25949 of redundant sign bits in operand 1, starting at the most 25950 significant bit position. A redundant sign bit is defined as any 25951 sign bit after the first. As such, this count will be one less 25952 than the count of leading sign bits. 25953 25954 M is either a scalar or vector integer mode. When it is a scalar, 25955 operand 1 has mode M but operand 0 can have whatever scalar integer 25956 mode is suitable for the target. The compiler will insert 25957 conversion instructions as necessary (typically to convert the 25958 result to the same width as 'int'). When M is a vector, both 25959 operands must have mode M. 25960 25961 This pattern is not allowed to 'FAIL'. 25962 25963'clzM2' 25964 Store into operand 0 the number of leading 0-bits in operand 1, 25965 starting at the most significant bit position. If operand 1 is 0, 25966 the 'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 25967 result is undefined or has a useful value. 25968 25969 M is either a scalar or vector integer mode. When it is a scalar, 25970 operand 1 has mode M but operand 0 can have whatever scalar integer 25971 mode is suitable for the target. The compiler will insert 25972 conversion instructions as necessary (typically to convert the 25973 result to the same width as 'int'). When M is a vector, both 25974 operands must have mode M. 25975 25976 This pattern is not allowed to 'FAIL'. 25977 25978'ctzM2' 25979 Store into operand 0 the number of trailing 0-bits in operand 1, 25980 starting at the least significant bit position. If operand 1 is 0, 25981 the 'CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 25982 result is undefined or has a useful value. 25983 25984 M is either a scalar or vector integer mode. When it is a scalar, 25985 operand 1 has mode M but operand 0 can have whatever scalar integer 25986 mode is suitable for the target. The compiler will insert 25987 conversion instructions as necessary (typically to convert the 25988 result to the same width as 'int'). When M is a vector, both 25989 operands must have mode M. 25990 25991 This pattern is not allowed to 'FAIL'. 25992 25993'popcountM2' 25994 Store into operand 0 the number of 1-bits in operand 1. 25995 25996 M is either a scalar or vector integer mode. When it is a scalar, 25997 operand 1 has mode M but operand 0 can have whatever scalar integer 25998 mode is suitable for the target. The compiler will insert 25999 conversion instructions as necessary (typically to convert the 26000 result to the same width as 'int'). When M is a vector, both 26001 operands must have mode M. 26002 26003 This pattern is not allowed to 'FAIL'. 26004 26005'parityM2' 26006 Store into operand 0 the parity of operand 1, i.e. the number of 26007 1-bits in operand 1 modulo 2. 26008 26009 M is either a scalar or vector integer mode. When it is a scalar, 26010 operand 1 has mode M but operand 0 can have whatever scalar integer 26011 mode is suitable for the target. The compiler will insert 26012 conversion instructions as necessary (typically to convert the 26013 result to the same width as 'int'). When M is a vector, both 26014 operands must have mode M. 26015 26016 This pattern is not allowed to 'FAIL'. 26017 26018'one_cmplM2' 26019 Store the bitwise-complement of operand 1 into operand 0. 26020 26021'movmemM' 26022 Block move instruction. The destination and source blocks of 26023 memory are the first two operands, and both are 'mem:BLK's with an 26024 address in mode 'Pmode'. 26025 26026 The number of bytes to move is the third operand, in mode M. 26027 Usually, you specify 'Pmode' for M. However, if you can generate 26028 better code knowing the range of valid lengths is smaller than 26029 those representable in a full Pmode pointer, you should provide a 26030 pattern with a mode corresponding to the range of values you can 26031 handle efficiently (e.g., 'QImode' for values in the range 0-127; 26032 note we avoid numbers that appear negative) and also a pattern with 26033 'Pmode'. 26034 26035 The fourth operand is the known shared alignment of the source and 26036 destination, in the form of a 'const_int' rtx. Thus, if the 26037 compiler knows that both source and destination are word-aligned, 26038 it may provide the value 4 for this operand. 26039 26040 Optional operands 5 and 6 specify expected alignment and size of 26041 block respectively. The expected alignment differs from alignment 26042 in operand 4 in a way that the blocks are not required to be 26043 aligned according to it in all cases. This expected alignment is 26044 also in bytes, just like operand 4. Expected size, when unknown, 26045 is set to '(const_int -1)'. 26046 26047 Descriptions of multiple 'movmemM' patterns can only be beneficial 26048 if the patterns for smaller modes have fewer restrictions on their 26049 first, second and fourth operands. Note that the mode M in 26050 'movmemM' does not impose any restriction on the mode of 26051 individually moved data units in the block. 26052 26053 These patterns need not give special consideration to the 26054 possibility that the source and destination strings might overlap. 26055 26056'movstr' 26057 String copy instruction, with 'stpcpy' semantics. Operand 0 is an 26058 output operand in mode 'Pmode'. The addresses of the destination 26059 and source strings are operands 1 and 2, and both are 'mem:BLK's 26060 with addresses in mode 'Pmode'. The execution of the expansion of 26061 this pattern should store in operand 0 the address in which the 26062 'NUL' terminator was stored in the destination string. 26063 26064 This patern has also several optional operands that are same as in 26065 'setmem'. 26066 26067'setmemM' 26068 Block set instruction. The destination string is the first 26069 operand, given as a 'mem:BLK' whose address is in mode 'Pmode'. 26070 The number of bytes to set is the second operand, in mode M. The 26071 value to initialize the memory with is the third operand. Targets 26072 that only support the clearing of memory should reject any value 26073 that is not the constant 0. See 'movmemM' for a discussion of the 26074 choice of mode. 26075 26076 The fourth operand is the known alignment of the destination, in 26077 the form of a 'const_int' rtx. Thus, if the compiler knows that 26078 the destination is word-aligned, it may provide the value 4 for 26079 this operand. 26080 26081 Optional operands 5 and 6 specify expected alignment and size of 26082 block respectively. The expected alignment differs from alignment 26083 in operand 4 in a way that the blocks are not required to be 26084 aligned according to it in all cases. This expected alignment is 26085 also in bytes, just like operand 4. Expected size, when unknown, 26086 is set to '(const_int -1)'. Operand 7 is the minimal size of the 26087 block and operand 8 is the maximal size of the block (NULL if it 26088 cannot be represented as CONST_INT). Operand 9 is the probable 26089 maximal size (i.e. we cannot rely on it for correctness, but it can 26090 be used for choosing proper code sequence for a given size). 26091 26092 The use for multiple 'setmemM' is as for 'movmemM'. 26093 26094'cmpstrnM' 26095 String compare instruction, with five operands. Operand 0 is the 26096 output; it has mode M. The remaining four operands are like the 26097 operands of 'movmemM'. The two memory blocks specified are 26098 compared byte by byte in lexicographic order starting at the 26099 beginning of each string. The instruction is not allowed to 26100 prefetch more than one byte at a time since either string may end 26101 in the first byte and reading past that may access an invalid page 26102 or segment and cause a fault. The comparison terminates early if 26103 the fetched bytes are different or if they are equal to zero. The 26104 effect of the instruction is to store a value in operand 0 whose 26105 sign indicates the result of the comparison. 26106 26107'cmpstrM' 26108 String compare instruction, without known maximum length. Operand 26109 0 is the output; it has mode M. The second and third operand are 26110 the blocks of memory to be compared; both are 'mem:BLK' with an 26111 address in mode 'Pmode'. 26112 26113 The fourth operand is the known shared alignment of the source and 26114 destination, in the form of a 'const_int' rtx. Thus, if the 26115 compiler knows that both source and destination are word-aligned, 26116 it may provide the value 4 for this operand. 26117 26118 The two memory blocks specified are compared byte by byte in 26119 lexicographic order starting at the beginning of each string. The 26120 instruction is not allowed to prefetch more than one byte at a time 26121 since either string may end in the first byte and reading past that 26122 may access an invalid page or segment and cause a fault. The 26123 comparison will terminate when the fetched bytes are different or 26124 if they are equal to zero. The effect of the instruction is to 26125 store a value in operand 0 whose sign indicates the result of the 26126 comparison. 26127 26128'cmpmemM' 26129 Block compare instruction, with five operands like the operands of 26130 'cmpstrM'. The two memory blocks specified are compared byte by 26131 byte in lexicographic order starting at the beginning of each 26132 block. Unlike 'cmpstrM' the instruction can prefetch any bytes in 26133 the two memory blocks. Also unlike 'cmpstrM' the comparison will 26134 not stop if both bytes are zero. The effect of the instruction is 26135 to store a value in operand 0 whose sign indicates the result of 26136 the comparison. 26137 26138'strlenM' 26139 Compute the length of a string, with three operands. Operand 0 is 26140 the result (of mode M), operand 1 is a 'mem' referring to the first 26141 character of the string, operand 2 is the character to search for 26142 (normally zero), and operand 3 is a constant describing the known 26143 alignment of the beginning of the string. 26144 26145'floatMN2' 26146 Convert signed integer operand 1 (valid for fixed point mode M) to 26147 floating point mode N and store in operand 0 (which has mode N). 26148 26149'floatunsMN2' 26150 Convert unsigned integer operand 1 (valid for fixed point mode M) 26151 to floating point mode N and store in operand 0 (which has mode N). 26152 26153'fixMN2' 26154 Convert operand 1 (valid for floating point mode M) to fixed point 26155 mode N as a signed number and store in operand 0 (which has mode 26156 N). This instruction's result is defined only when the value of 26157 operand 1 is an integer. 26158 26159 If the machine description defines this pattern, it also needs to 26160 define the 'ftrunc' pattern. 26161 26162'fixunsMN2' 26163 Convert operand 1 (valid for floating point mode M) to fixed point 26164 mode N as an unsigned number and store in operand 0 (which has mode 26165 N). This instruction's result is defined only when the value of 26166 operand 1 is an integer. 26167 26168'ftruncM2' 26169 Convert operand 1 (valid for floating point mode M) to an integer 26170 value, still represented in floating point mode M, and store it in 26171 operand 0 (valid for floating point mode M). 26172 26173'fix_truncMN2' 26174 Like 'fixMN2' but works for any floating point value of mode M by 26175 converting the value to an integer. 26176 26177'fixuns_truncMN2' 26178 Like 'fixunsMN2' but works for any floating point value of mode M 26179 by converting the value to an integer. 26180 26181'truncMN2' 26182 Truncate operand 1 (valid for mode M) to mode N and store in 26183 operand 0 (which has mode N). Both modes must be fixed point or 26184 both floating point. 26185 26186'extendMN2' 26187 Sign-extend operand 1 (valid for mode M) to mode N and store in 26188 operand 0 (which has mode N). Both modes must be fixed point or 26189 both floating point. 26190 26191'zero_extendMN2' 26192 Zero-extend operand 1 (valid for mode M) to mode N and store in 26193 operand 0 (which has mode N). Both modes must be fixed point. 26194 26195'fractMN2' 26196 Convert operand 1 of mode M to mode N and store in operand 0 (which 26197 has mode N). Mode M and mode N could be fixed-point to 26198 fixed-point, signed integer to fixed-point, fixed-point to signed 26199 integer, floating-point to fixed-point, or fixed-point to 26200 floating-point. When overflows or underflows happen, the results 26201 are undefined. 26202 26203'satfractMN2' 26204 Convert operand 1 of mode M to mode N and store in operand 0 (which 26205 has mode N). Mode M and mode N could be fixed-point to 26206 fixed-point, signed integer to fixed-point, or floating-point to 26207 fixed-point. When overflows or underflows happen, the instruction 26208 saturates the results to the maximum or the minimum. 26209 26210'fractunsMN2' 26211 Convert operand 1 of mode M to mode N and store in operand 0 (which 26212 has mode N). Mode M and mode N could be unsigned integer to 26213 fixed-point, or fixed-point to unsigned integer. When overflows or 26214 underflows happen, the results are undefined. 26215 26216'satfractunsMN2' 26217 Convert unsigned integer operand 1 of mode M to fixed-point mode N 26218 and store in operand 0 (which has mode N). When overflows or 26219 underflows happen, the instruction saturates the results to the 26220 maximum or the minimum. 26221 26222'extvM' 26223 Extract a bit-field from register operand 1, sign-extend it, and 26224 store it in operand 0. Operand 2 specifies the width of the field 26225 in bits and operand 3 the starting bit, which counts from the most 26226 significant bit if 'BITS_BIG_ENDIAN' is true and from the least 26227 significant bit otherwise. 26228 26229 Operands 0 and 1 both have mode M. Operands 2 and 3 have a 26230 target-specific mode. 26231 26232'extvmisalignM' 26233 Extract a bit-field from memory operand 1, sign extend it, and 26234 store it in operand 0. Operand 2 specifies the width in bits and 26235 operand 3 the starting bit. The starting bit is always somewhere 26236 in the first byte of operand 1; it counts from the most significant 26237 bit if 'BITS_BIG_ENDIAN' is true and from the least significant bit 26238 otherwise. 26239 26240 Operand 0 has mode M while operand 1 has 'BLK' mode. Operands 2 26241 and 3 have a target-specific mode. 26242 26243 The instruction must not read beyond the last byte of the 26244 bit-field. 26245 26246'extzvM' 26247 Like 'extvM' except that the bit-field value is zero-extended. 26248 26249'extzvmisalignM' 26250 Like 'extvmisalignM' except that the bit-field value is 26251 zero-extended. 26252 26253'insvM' 26254 Insert operand 3 into a bit-field of register operand 0. Operand 1 26255 specifies the width of the field in bits and operand 2 the starting 26256 bit, which counts from the most significant bit if 26257 'BITS_BIG_ENDIAN' is true and from the least significant bit 26258 otherwise. 26259 26260 Operands 0 and 3 both have mode M. Operands 1 and 2 have a 26261 target-specific mode. 26262 26263'insvmisalignM' 26264 Insert operand 3 into a bit-field of memory operand 0. Operand 1 26265 specifies the width of the field in bits and operand 2 the starting 26266 bit. The starting bit is always somewhere in the first byte of 26267 operand 0; it counts from the most significant bit if 26268 'BITS_BIG_ENDIAN' is true and from the least significant bit 26269 otherwise. 26270 26271 Operand 3 has mode M while operand 0 has 'BLK' mode. Operands 1 26272 and 2 have a target-specific mode. 26273 26274 The instruction must not read or write beyond the last byte of the 26275 bit-field. 26276 26277'extv' 26278 Extract a bit-field from operand 1 (a register or memory operand), 26279 where operand 2 specifies the width in bits and operand 3 the 26280 starting bit, and store it in operand 0. Operand 0 must have mode 26281 'word_mode'. Operand 1 may have mode 'byte_mode' or 'word_mode'; 26282 often 'word_mode' is allowed only for registers. Operands 2 and 3 26283 must be valid for 'word_mode'. 26284 26285 The RTL generation pass generates this instruction only with 26286 constants for operands 2 and 3 and the constant is never zero for 26287 operand 2. 26288 26289 The bit-field value is sign-extended to a full word integer before 26290 it is stored in operand 0. 26291 26292 This pattern is deprecated; please use 'extvM' and 'extvmisalignM' 26293 instead. 26294 26295'extzv' 26296 Like 'extv' except that the bit-field value is zero-extended. 26297 26298 This pattern is deprecated; please use 'extzvM' and 26299 'extzvmisalignM' instead. 26300 26301'insv' 26302 Store operand 3 (which must be valid for 'word_mode') into a 26303 bit-field in operand 0, where operand 1 specifies the width in bits 26304 and operand 2 the starting bit. Operand 0 may have mode 26305 'byte_mode' or 'word_mode'; often 'word_mode' is allowed only for 26306 registers. Operands 1 and 2 must be valid for 'word_mode'. 26307 26308 The RTL generation pass generates this instruction only with 26309 constants for operands 1 and 2 and the constant is never zero for 26310 operand 1. 26311 26312 This pattern is deprecated; please use 'insvM' and 'insvmisalignM' 26313 instead. 26314 26315'movMODEcc' 26316 Conditionally move operand 2 or operand 3 into operand 0 according 26317 to the comparison in operand 1. If the comparison is true, operand 26318 2 is moved into operand 0, otherwise operand 3 is moved. 26319 26320 The mode of the operands being compared need not be the same as the 26321 operands being moved. Some machines, sparc64 for example, have 26322 instructions that conditionally move an integer value based on the 26323 floating point condition codes and vice versa. 26324 26325 If the machine does not have conditional move instructions, do not 26326 define these patterns. 26327 26328'addMODEcc' 26329 Similar to 'movMODEcc' but for conditional addition. Conditionally 26330 move operand 2 or (operands 2 + operand 3) into operand 0 according 26331 to the comparison in operand 1. If the comparison is false, 26332 operand 2 is moved into operand 0, otherwise (operand 2 + operand 26333 3) is moved. 26334 26335'cond_addMODE' 26336'cond_subMODE' 26337'cond_mulMODE' 26338'cond_divMODE' 26339'cond_udivMODE' 26340'cond_modMODE' 26341'cond_umodMODE' 26342'cond_andMODE' 26343'cond_iorMODE' 26344'cond_xorMODE' 26345'cond_sminMODE' 26346'cond_smaxMODE' 26347'cond_uminMODE' 26348'cond_umaxMODE' 26349 When operand 1 is true, perform an operation on operands 2 and 3 26350 and store the result in operand 0, otherwise store operand 4 in 26351 operand 0. The operation works elementwise if the operands are 26352 vectors. 26353 26354 The scalar case is equivalent to: 26355 26356 op0 = op1 ? op2 OP op3 : op4; 26357 26358 while the vector case is equivalent to: 26359 26360 for (i = 0; i < GET_MODE_NUNITS (M); i++) 26361 op0[i] = op1[i] ? op2[i] OP op3[i] : op4[i]; 26362 26363 where, for example, OP is '+' for 'cond_addMODE'. 26364 26365 When defined for floating-point modes, the contents of 'op3[i]' are 26366 not interpreted if 'op1[i]' is false, just like they would not be 26367 in a normal C '?:' condition. 26368 26369 Operands 0, 2, 3 and 4 all have mode M. Operand 1 is a scalar 26370 integer if M is scalar, otherwise it has the mode returned by 26371 'TARGET_VECTORIZE_GET_MASK_MODE'. 26372 26373'cond_fmaMODE' 26374'cond_fmsMODE' 26375'cond_fnmaMODE' 26376'cond_fnmsMODE' 26377 Like 'cond_addM', except that the conditional operation takes 3 26378 operands rather than two. For example, the vector form of 26379 'cond_fmaMODE' is equivalent to: 26380 26381 for (i = 0; i < GET_MODE_NUNITS (M); i++) 26382 op0[i] = op1[i] ? fma (op2[i], op3[i], op4[i]) : op5[i]; 26383 26384'negMODEcc' 26385 Similar to 'movMODEcc' but for conditional negation. Conditionally 26386 move the negation of operand 2 or the unchanged operand 3 into 26387 operand 0 according to the comparison in operand 1. If the 26388 comparison is true, the negation of operand 2 is moved into operand 26389 0, otherwise operand 3 is moved. 26390 26391'notMODEcc' 26392 Similar to 'negMODEcc' but for conditional complement. 26393 Conditionally move the bitwise complement of operand 2 or the 26394 unchanged operand 3 into operand 0 according to the comparison in 26395 operand 1. If the comparison is true, the complement of operand 2 26396 is moved into operand 0, otherwise operand 3 is moved. 26397 26398'cstoreMODE4' 26399 Store zero or nonzero in operand 0 according to whether a 26400 comparison is true. Operand 1 is a comparison operator. Operand 2 26401 and operand 3 are the first and second operand of the comparison, 26402 respectively. You specify the mode that operand 0 must have when 26403 you write the 'match_operand' expression. The compiler 26404 automatically sees which mode you have used and supplies an operand 26405 of that mode. 26406 26407 The value stored for a true condition must have 1 as its low bit, 26408 or else must be negative. Otherwise the instruction is not 26409 suitable and you should omit it from the machine description. You 26410 describe to the compiler exactly which value is stored by defining 26411 the macro 'STORE_FLAG_VALUE' (*note Misc::). If a description 26412 cannot be found that can be used for all the possible comparison 26413 operators, you should pick one and use a 'define_expand' to map all 26414 results onto the one you chose. 26415 26416 These operations may 'FAIL', but should do so only in relatively 26417 uncommon cases; if they would 'FAIL' for common cases involving 26418 integer comparisons, it is best to restrict the predicates to not 26419 allow these operands. Likewise if a given comparison operator will 26420 always fail, independent of the operands (for floating-point modes, 26421 the 'ordered_comparison_operator' predicate is often useful in this 26422 case). 26423 26424 If this pattern is omitted, the compiler will generate a 26425 conditional branch--for example, it may copy a constant one to the 26426 target and branching around an assignment of zero to the target--or 26427 a libcall. If the predicate for operand 1 only rejects some 26428 operators, it will also try reordering the operands and/or 26429 inverting the result value (e.g. by an exclusive OR). These 26430 possibilities could be cheaper or equivalent to the instructions 26431 used for the 'cstoreMODE4' pattern followed by those required to 26432 convert a positive result from 'STORE_FLAG_VALUE' to 1; in this 26433 case, you can and should make operand 1's predicate reject some 26434 operators in the 'cstoreMODE4' pattern, or remove the pattern 26435 altogether from the machine description. 26436 26437'cbranchMODE4' 26438 Conditional branch instruction combined with a compare instruction. 26439 Operand 0 is a comparison operator. Operand 1 and operand 2 are 26440 the first and second operands of the comparison, respectively. 26441 Operand 3 is the 'code_label' to jump to. 26442 26443'jump' 26444 A jump inside a function; an unconditional branch. Operand 0 is 26445 the 'code_label' to jump to. This pattern name is mandatory on all 26446 machines. 26447 26448'call' 26449 Subroutine call instruction returning no value. Operand 0 is the 26450 function to call; operand 1 is the number of bytes of arguments 26451 pushed as a 'const_int'; operand 2 is the number of registers used 26452 as operands. 26453 26454 On most machines, operand 2 is not actually stored into the RTL 26455 pattern. It is supplied for the sake of some RISC machines which 26456 need to put this information into the assembler code; they can put 26457 it in the RTL instead of operand 1. 26458 26459 Operand 0 should be a 'mem' RTX whose address is the address of the 26460 function. Note, however, that this address can be a 'symbol_ref' 26461 expression even if it would not be a legitimate memory address on 26462 the target machine. If it is also not a valid argument for a call 26463 instruction, the pattern for this operation should be a 26464 'define_expand' (*note Expander Definitions::) that places the 26465 address into a register and uses that register in the call 26466 instruction. 26467 26468'call_value' 26469 Subroutine call instruction returning a value. Operand 0 is the 26470 hard register in which the value is returned. There are three more 26471 operands, the same as the three operands of the 'call' instruction 26472 (but with numbers increased by one). 26473 26474 Subroutines that return 'BLKmode' objects use the 'call' insn. 26475 26476'call_pop', 'call_value_pop' 26477 Similar to 'call' and 'call_value', except used if defined and if 26478 'RETURN_POPS_ARGS' is nonzero. They should emit a 'parallel' that 26479 contains both the function call and a 'set' to indicate the 26480 adjustment made to the frame pointer. 26481 26482 For machines where 'RETURN_POPS_ARGS' can be nonzero, the use of 26483 these patterns increases the number of functions for which the 26484 frame pointer can be eliminated, if desired. 26485 26486'untyped_call' 26487 Subroutine call instruction returning a value of any type. Operand 26488 0 is the function to call; operand 1 is a memory location where the 26489 result of calling the function is to be stored; operand 2 is a 26490 'parallel' expression where each element is a 'set' expression that 26491 indicates the saving of a function return value into the result 26492 block. 26493 26494 This instruction pattern should be defined to support 26495 '__builtin_apply' on machines where special instructions are needed 26496 to call a subroutine with arbitrary arguments or to save the value 26497 returned. This instruction pattern is required on machines that 26498 have multiple registers that can hold a return value (i.e. 26499 'FUNCTION_VALUE_REGNO_P' is true for more than one register). 26500 26501'return' 26502 Subroutine return instruction. This instruction pattern name 26503 should be defined only if a single instruction can do all the work 26504 of returning from a function. 26505 26506 Like the 'movM' patterns, this pattern is also used after the RTL 26507 generation phase. In this case it is to support machines where 26508 multiple instructions are usually needed to return from a function, 26509 but some class of functions only requires one instruction to 26510 implement a return. Normally, the applicable functions are those 26511 which do not need to save any registers or allocate stack space. 26512 26513 It is valid for this pattern to expand to an instruction using 26514 'simple_return' if no epilogue is required. 26515 26516'simple_return' 26517 Subroutine return instruction. This instruction pattern name 26518 should be defined only if a single instruction can do all the work 26519 of returning from a function on a path where no epilogue is 26520 required. This pattern is very similar to the 'return' instruction 26521 pattern, but it is emitted only by the shrink-wrapping optimization 26522 on paths where the function prologue has not been executed, and a 26523 function return should occur without any of the effects of the 26524 epilogue. Additional uses may be introduced on paths where both 26525 the prologue and the epilogue have executed. 26526 26527 For such machines, the condition specified in this pattern should 26528 only be true when 'reload_completed' is nonzero and the function's 26529 epilogue would only be a single instruction. For machines with 26530 register windows, the routine 'leaf_function_p' may be used to 26531 determine if a register window push is required. 26532 26533 Machines that have conditional return instructions should define 26534 patterns such as 26535 26536 (define_insn "" 26537 [(set (pc) 26538 (if_then_else (match_operator 26539 0 "comparison_operator" 26540 [(cc0) (const_int 0)]) 26541 (return) 26542 (pc)))] 26543 "CONDITION" 26544 "...") 26545 26546 where CONDITION would normally be the same condition specified on 26547 the named 'return' pattern. 26548 26549'untyped_return' 26550 Untyped subroutine return instruction. This instruction pattern 26551 should be defined to support '__builtin_return' on machines where 26552 special instructions are needed to return a value of any type. 26553 26554 Operand 0 is a memory location where the result of calling a 26555 function with '__builtin_apply' is stored; operand 1 is a 26556 'parallel' expression where each element is a 'set' expression that 26557 indicates the restoring of a function return value from the result 26558 block. 26559 26560'nop' 26561 No-op instruction. This instruction pattern name should always be 26562 defined to output a no-op in assembler code. '(const_int 0)' will 26563 do as an RTL pattern. 26564 26565'indirect_jump' 26566 An instruction to jump to an address which is operand zero. This 26567 pattern name is mandatory on all machines. 26568 26569'casesi' 26570 Instruction to jump through a dispatch table, including bounds 26571 checking. This instruction takes five operands: 26572 26573 1. The index to dispatch on, which has mode 'SImode'. 26574 26575 2. The lower bound for indices in the table, an integer constant. 26576 26577 3. The total range of indices in the table--the largest index 26578 minus the smallest one (both inclusive). 26579 26580 4. A label that precedes the table itself. 26581 26582 5. A label to jump to if the index has a value outside the 26583 bounds. 26584 26585 The table is an 'addr_vec' or 'addr_diff_vec' inside of a 26586 'jump_table_data'. The number of elements in the table is one plus 26587 the difference between the upper bound and the lower bound. 26588 26589'tablejump' 26590 Instruction to jump to a variable address. This is a low-level 26591 capability which can be used to implement a dispatch table when 26592 there is no 'casesi' pattern. 26593 26594 This pattern requires two operands: the address or offset, and a 26595 label which should immediately precede the jump table. If the 26596 macro 'CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then 26597 the first operand is an offset which counts from the address of the 26598 table; otherwise, it is an absolute address to jump to. In either 26599 case, the first operand has mode 'Pmode'. 26600 26601 The 'tablejump' insn is always the last insn before the jump table 26602 it uses. Its assembler code normally has no need to use the second 26603 operand, but you should incorporate it in the RTL pattern so that 26604 the jump optimizer will not delete the table as unreachable code. 26605 26606'doloop_end' 26607 Conditional branch instruction that decrements a register and jumps 26608 if the register is nonzero. Operand 0 is the register to decrement 26609 and test; operand 1 is the label to jump to if the register is 26610 nonzero. *Note Looping Patterns::. 26611 26612 This optional instruction pattern should be defined for machines 26613 with low-overhead looping instructions as the loop optimizer will 26614 try to modify suitable loops to utilize it. The target hook 26615 'TARGET_CAN_USE_DOLOOP_P' controls the conditions under which 26616 low-overhead loops can be used. 26617 26618'doloop_begin' 26619 Companion instruction to 'doloop_end' required for machines that 26620 need to perform some initialization, such as loading a special 26621 counter register. Operand 1 is the associated 'doloop_end' pattern 26622 and operand 0 is the register that it decrements. 26623 26624 If initialization insns do not always need to be emitted, use a 26625 'define_expand' (*note Expander Definitions::) and make it fail. 26626 26627'canonicalize_funcptr_for_compare' 26628 Canonicalize the function pointer in operand 1 and store the result 26629 into operand 0. 26630 26631 Operand 0 is always a 'reg' and has mode 'Pmode'; operand 1 may be 26632 a 'reg', 'mem', 'symbol_ref', 'const_int', etc and also has mode 26633 'Pmode'. 26634 26635 Canonicalization of a function pointer usually involves computing 26636 the address of the function which would be called if the function 26637 pointer were used in an indirect call. 26638 26639 Only define this pattern if function pointers on the target machine 26640 can have different values but still call the same function when 26641 used in an indirect call. 26642 26643'save_stack_block' 26644'save_stack_function' 26645'save_stack_nonlocal' 26646'restore_stack_block' 26647'restore_stack_function' 26648'restore_stack_nonlocal' 26649 Most machines save and restore the stack pointer by copying it to 26650 or from an object of mode 'Pmode'. Do not define these patterns on 26651 such machines. 26652 26653 Some machines require special handling for stack pointer saves and 26654 restores. On those machines, define the patterns corresponding to 26655 the non-standard cases by using a 'define_expand' (*note Expander 26656 Definitions::) that produces the required insns. The three types 26657 of saves and restores are: 26658 26659 1. 'save_stack_block' saves the stack pointer at the start of a 26660 block that allocates a variable-sized object, and 26661 'restore_stack_block' restores the stack pointer when the 26662 block is exited. 26663 26664 2. 'save_stack_function' and 'restore_stack_function' do a 26665 similar job for the outermost block of a function and are used 26666 when the function allocates variable-sized objects or calls 26667 'alloca'. Only the epilogue uses the restored stack pointer, 26668 allowing a simpler save or restore sequence on some machines. 26669 26670 3. 'save_stack_nonlocal' is used in functions that contain labels 26671 branched to by nested functions. It saves the stack pointer 26672 in such a way that the inner function can use 26673 'restore_stack_nonlocal' to restore the stack pointer. The 26674 compiler generates code to restore the frame and argument 26675 pointer registers, but some machines require saving and 26676 restoring additional data such as register window information 26677 or stack backchains. Place insns in these patterns to save 26678 and restore any such required data. 26679 26680 When saving the stack pointer, operand 0 is the save area and 26681 operand 1 is the stack pointer. The mode used to allocate the save 26682 area defaults to 'Pmode' but you can override that choice by 26683 defining the 'STACK_SAVEAREA_MODE' macro (*note Storage Layout::). 26684 You must specify an integral mode, or 'VOIDmode' if no save area is 26685 needed for a particular type of save (either because no save is 26686 needed or because a machine-specific save area can be used). 26687 Operand 0 is the stack pointer and operand 1 is the save area for 26688 restore operations. If 'save_stack_block' is defined, operand 0 26689 must not be 'VOIDmode' since these saves can be arbitrarily nested. 26690 26691 A save area is a 'mem' that is at a constant offset from 26692 'virtual_stack_vars_rtx' when the stack pointer is saved for use by 26693 nonlocal gotos and a 'reg' in the other two cases. 26694 26695'allocate_stack' 26696 Subtract (or add if 'STACK_GROWS_DOWNWARD' is undefined) operand 1 26697 from the stack pointer to create space for dynamically allocated 26698 data. 26699 26700 Store the resultant pointer to this space into operand 0. If you 26701 are allocating space from the main stack, do this by emitting a 26702 move insn to copy 'virtual_stack_dynamic_rtx' to operand 0. If you 26703 are allocating the space elsewhere, generate code to copy the 26704 location of the space to operand 0. In the latter case, you must 26705 ensure this space gets freed when the corresponding space on the 26706 main stack is free. 26707 26708 Do not define this pattern if all that must be done is the 26709 subtraction. Some machines require other operations such as stack 26710 probes or maintaining the back chain. Define this pattern to emit 26711 those operations in addition to updating the stack pointer. 26712 26713'check_stack' 26714 If stack checking (*note Stack Checking::) cannot be done on your 26715 system by probing the stack, define this pattern to perform the 26716 needed check and signal an error if the stack has overflowed. The 26717 single operand is the address in the stack farthest from the 26718 current stack pointer that you need to validate. Normally, on 26719 platforms where this pattern is needed, you would obtain the stack 26720 limit from a global or thread-specific variable or register. 26721 26722'probe_stack_address' 26723 If stack checking (*note Stack Checking::) can be done on your 26724 system by probing the stack but without the need to actually access 26725 it, define this pattern and signal an error if the stack has 26726 overflowed. The single operand is the memory address in the stack 26727 that needs to be probed. 26728 26729'probe_stack' 26730 If stack checking (*note Stack Checking::) can be done on your 26731 system by probing the stack but doing it with a "store zero" 26732 instruction is not valid or optimal, define this pattern to do the 26733 probing differently and signal an error if the stack has 26734 overflowed. The single operand is the memory reference in the 26735 stack that needs to be probed. 26736 26737'nonlocal_goto' 26738 Emit code to generate a non-local goto, e.g., a jump from one 26739 function to a label in an outer function. This pattern has four 26740 arguments, each representing a value to be used in the jump. The 26741 first argument is to be loaded into the frame pointer, the second 26742 is the address to branch to (code to dispatch to the actual label), 26743 the third is the address of a location where the stack is saved, 26744 and the last is the address of the label, to be placed in the 26745 location for the incoming static chain. 26746 26747 On most machines you need not define this pattern, since GCC will 26748 already generate the correct code, which is to load the frame 26749 pointer and static chain, restore the stack (using the 26750 'restore_stack_nonlocal' pattern, if defined), and jump indirectly 26751 to the dispatcher. You need only define this pattern if this code 26752 will not work on your machine. 26753 26754'nonlocal_goto_receiver' 26755 This pattern, if defined, contains code needed at the target of a 26756 nonlocal goto after the code already generated by GCC. You will 26757 not normally need to define this pattern. A typical reason why you 26758 might need this pattern is if some value, such as a pointer to a 26759 global table, must be restored when the frame pointer is restored. 26760 Note that a nonlocal goto only occurs within a unit-of-translation, 26761 so a global table pointer that is shared by all functions of a 26762 given module need not be restored. There are no arguments. 26763 26764'exception_receiver' 26765 This pattern, if defined, contains code needed at the site of an 26766 exception handler that isn't needed at the site of a nonlocal goto. 26767 You will not normally need to define this pattern. A typical 26768 reason why you might need this pattern is if some value, such as a 26769 pointer to a global table, must be restored after control flow is 26770 branched to the handler of an exception. There are no arguments. 26771 26772'builtin_setjmp_setup' 26773 This pattern, if defined, contains additional code needed to 26774 initialize the 'jmp_buf'. You will not normally need to define 26775 this pattern. A typical reason why you might need this pattern is 26776 if some value, such as a pointer to a global table, must be 26777 restored. Though it is preferred that the pointer value be 26778 recalculated if possible (given the address of a label for 26779 instance). The single argument is a pointer to the 'jmp_buf'. 26780 Note that the buffer is five words long and that the first three 26781 are normally used by the generic mechanism. 26782 26783'builtin_setjmp_receiver' 26784 This pattern, if defined, contains code needed at the site of a 26785 built-in setjmp that isn't needed at the site of a nonlocal goto. 26786 You will not normally need to define this pattern. A typical 26787 reason why you might need this pattern is if some value, such as a 26788 pointer to a global table, must be restored. It takes one 26789 argument, which is the label to which builtin_longjmp transferred 26790 control; this pattern may be emitted at a small offset from that 26791 label. 26792 26793'builtin_longjmp' 26794 This pattern, if defined, performs the entire action of the 26795 longjmp. You will not normally need to define this pattern unless 26796 you also define 'builtin_setjmp_setup'. The single argument is a 26797 pointer to the 'jmp_buf'. 26798 26799'eh_return' 26800 This pattern, if defined, affects the way '__builtin_eh_return', 26801 and thence the call frame exception handling library routines, are 26802 built. It is intended to handle non-trivial actions needed along 26803 the abnormal return path. 26804 26805 The address of the exception handler to which the function should 26806 return is passed as operand to this pattern. It will normally need 26807 to copied by the pattern to some special register or memory 26808 location. If the pattern needs to determine the location of the 26809 target call frame in order to do so, it may use 26810 'EH_RETURN_STACKADJ_RTX', if defined; it will have already been 26811 assigned. 26812 26813 If this pattern is not defined, the default action will be to 26814 simply copy the return address to 'EH_RETURN_HANDLER_RTX'. Either 26815 that macro or this pattern needs to be defined if call frame 26816 exception handling is to be used. 26817 26818'prologue' 26819 This pattern, if defined, emits RTL for entry to a function. The 26820 function entry is responsible for setting up the stack frame, 26821 initializing the frame pointer register, saving callee saved 26822 registers, etc. 26823 26824 Using a prologue pattern is generally preferred over defining 26825 'TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the 26826 prologue. 26827 26828 The 'prologue' pattern is particularly useful for targets which 26829 perform instruction scheduling. 26830 26831'window_save' 26832 This pattern, if defined, emits RTL for a register window save. It 26833 should be defined if the target machine has register windows but 26834 the window events are decoupled from calls to subroutines. The 26835 canonical example is the SPARC architecture. 26836 26837'epilogue' 26838 This pattern emits RTL for exit from a function. The function exit 26839 is responsible for deallocating the stack frame, restoring callee 26840 saved registers and emitting the return instruction. 26841 26842 Using an epilogue pattern is generally preferred over defining 26843 'TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the 26844 epilogue. 26845 26846 The 'epilogue' pattern is particularly useful for targets which 26847 perform instruction scheduling or which have delay slots for their 26848 return instruction. 26849 26850'sibcall_epilogue' 26851 This pattern, if defined, emits RTL for exit from a function 26852 without the final branch back to the calling function. This 26853 pattern will be emitted before any sibling call (aka tail call) 26854 sites. 26855 26856 The 'sibcall_epilogue' pattern must not clobber any arguments used 26857 for parameter passing or any stack slots for arguments passed to 26858 the current function. 26859 26860'trap' 26861 This pattern, if defined, signals an error, typically by causing 26862 some kind of signal to be raised. 26863 26864'ctrapMM4' 26865 Conditional trap instruction. Operand 0 is a piece of RTL which 26866 performs a comparison, and operands 1 and 2 are the arms of the 26867 comparison. Operand 3 is the trap code, an integer. 26868 26869 A typical 'ctrap' pattern looks like 26870 26871 (define_insn "ctrapsi4" 26872 [(trap_if (match_operator 0 "trap_operator" 26873 [(match_operand 1 "register_operand") 26874 (match_operand 2 "immediate_operand")]) 26875 (match_operand 3 "const_int_operand" "i"))] 26876 "" 26877 "...") 26878 26879'prefetch' 26880 This pattern, if defined, emits code for a non-faulting data 26881 prefetch instruction. Operand 0 is the address of the memory to 26882 prefetch. Operand 1 is a constant 1 if the prefetch is preparing 26883 for a write to the memory address, or a constant 0 otherwise. 26884 Operand 2 is the expected degree of temporal locality of the data 26885 and is a value between 0 and 3, inclusive; 0 means that the data 26886 has no temporal locality, so it need not be left in the cache after 26887 the access; 3 means that the data has a high degree of temporal 26888 locality and should be left in all levels of cache possible; 1 and 26889 2 mean, respectively, a low or moderate degree of temporal 26890 locality. 26891 26892 Targets that do not support write prefetches or locality hints can 26893 ignore the values of operands 1 and 2. 26894 26895'blockage' 26896 This pattern defines a pseudo insn that prevents the instruction 26897 scheduler and other passes from moving instructions and using 26898 register equivalences across the boundary defined by the blockage 26899 insn. This needs to be an UNSPEC_VOLATILE pattern or a volatile 26900 ASM. 26901 26902'memory_blockage' 26903 This pattern, if defined, represents a compiler memory barrier, and 26904 will be placed at points across which RTL passes may not propagate 26905 memory accesses. This instruction needs to read and write volatile 26906 BLKmode memory. It does not need to generate any machine 26907 instruction. If this pattern is not defined, the compiler falls 26908 back to emitting an instruction corresponding to 'asm volatile ("" 26909 ::: "memory")'. 26910 26911'memory_barrier' 26912 If the target memory model is not fully synchronous, then this 26913 pattern should be defined to an instruction that orders both loads 26914 and stores before the instruction with respect to loads and stores 26915 after the instruction. This pattern has no operands. 26916 26917'speculation_barrier' 26918 If the target can support speculative execution, then this pattern 26919 should be defined to an instruction that will block subsequent 26920 execution until any prior speculation conditions has been resolved. 26921 The pattern must also ensure that the compiler cannot move memory 26922 operations past the barrier, so it needs to be an UNSPEC_VOLATILE 26923 pattern. The pattern has no operands. 26924 26925 If this pattern is not defined then the default expansion of 26926 '__builtin_speculation_safe_value' will emit a warning. You can 26927 suppress this warning by defining this pattern with a final 26928 condition of '0' (zero), which tells the compiler that a 26929 speculation barrier is not needed for this target. 26930 26931'sync_compare_and_swapMODE' 26932 This pattern, if defined, emits code for an atomic compare-and-swap 26933 operation. Operand 1 is the memory on which the atomic operation 26934 is performed. Operand 2 is the "old" value to be compared against 26935 the current contents of the memory location. Operand 3 is the 26936 "new" value to store in the memory if the compare succeeds. 26937 Operand 0 is the result of the operation; it should contain the 26938 contents of the memory before the operation. If the compare 26939 succeeds, this should obviously be a copy of operand 2. 26940 26941 This pattern must show that both operand 0 and operand 1 are 26942 modified. 26943 26944 This pattern must issue any memory barrier instructions such that 26945 all memory operations before the atomic operation occur before the 26946 atomic operation and all memory operations after the atomic 26947 operation occur after the atomic operation. 26948 26949 For targets where the success or failure of the compare-and-swap 26950 operation is available via the status flags, it is possible to 26951 avoid a separate compare operation and issue the subsequent branch 26952 or store-flag operation immediately after the compare-and-swap. To 26953 this end, GCC will look for a 'MODE_CC' set in the output of 26954 'sync_compare_and_swapMODE'; if the machine description includes 26955 such a set, the target should also define special 'cbranchcc4' 26956 and/or 'cstorecc4' instructions. GCC will then be able to take the 26957 destination of the 'MODE_CC' set and pass it to the 'cbranchcc4' or 26958 'cstorecc4' pattern as the first operand of the comparison (the 26959 second will be '(const_int 0)'). 26960 26961 For targets where the operating system may provide support for this 26962 operation via library calls, the 'sync_compare_and_swap_optab' may 26963 be initialized to a function with the same interface as the 26964 '__sync_val_compare_and_swap_N' built-in. If the entire set of 26965 __SYNC builtins are supported via library calls, the target can 26966 initialize all of the optabs at once with 'init_sync_libfuncs'. 26967 For the purposes of C++11 'std::atomic::is_lock_free', it is 26968 assumed that these library calls do _not_ use any kind of 26969 interruptable locking. 26970 26971'sync_addMODE', 'sync_subMODE' 26972'sync_iorMODE', 'sync_andMODE' 26973'sync_xorMODE', 'sync_nandMODE' 26974 These patterns emit code for an atomic operation on memory. 26975 Operand 0 is the memory on which the atomic operation is performed. 26976 Operand 1 is the second operand to the binary operator. 26977 26978 This pattern must issue any memory barrier instructions such that 26979 all memory operations before the atomic operation occur before the 26980 atomic operation and all memory operations after the atomic 26981 operation occur after the atomic operation. 26982 26983 If these patterns are not defined, the operation will be 26984 constructed from a compare-and-swap operation, if defined. 26985 26986'sync_old_addMODE', 'sync_old_subMODE' 26987'sync_old_iorMODE', 'sync_old_andMODE' 26988'sync_old_xorMODE', 'sync_old_nandMODE' 26989 These patterns emit code for an atomic operation on memory, and 26990 return the value that the memory contained before the operation. 26991 Operand 0 is the result value, operand 1 is the memory on which the 26992 atomic operation is performed, and operand 2 is the second operand 26993 to the binary operator. 26994 26995 This pattern must issue any memory barrier instructions such that 26996 all memory operations before the atomic operation occur before the 26997 atomic operation and all memory operations after the atomic 26998 operation occur after the atomic operation. 26999 27000 If these patterns are not defined, the operation will be 27001 constructed from a compare-and-swap operation, if defined. 27002 27003'sync_new_addMODE', 'sync_new_subMODE' 27004'sync_new_iorMODE', 'sync_new_andMODE' 27005'sync_new_xorMODE', 'sync_new_nandMODE' 27006 These patterns are like their 'sync_old_OP' counterparts, except 27007 that they return the value that exists in the memory location after 27008 the operation, rather than before the operation. 27009 27010'sync_lock_test_and_setMODE' 27011 This pattern takes two forms, based on the capabilities of the 27012 target. In either case, operand 0 is the result of the operand, 27013 operand 1 is the memory on which the atomic operation is performed, 27014 and operand 2 is the value to set in the lock. 27015 27016 In the ideal case, this operation is an atomic exchange operation, 27017 in which the previous value in memory operand is copied into the 27018 result operand, and the value operand is stored in the memory 27019 operand. 27020 27021 For less capable targets, any value operand that is not the 27022 constant 1 should be rejected with 'FAIL'. In this case the target 27023 may use an atomic test-and-set bit operation. The result operand 27024 should contain 1 if the bit was previously set and 0 if the bit was 27025 previously clear. The true contents of the memory operand are 27026 implementation defined. 27027 27028 This pattern must issue any memory barrier instructions such that 27029 the pattern as a whole acts as an acquire barrier, that is all 27030 memory operations after the pattern do not occur until the lock is 27031 acquired. 27032 27033 If this pattern is not defined, the operation will be constructed 27034 from a compare-and-swap operation, if defined. 27035 27036'sync_lock_releaseMODE' 27037 This pattern, if defined, releases a lock set by 27038 'sync_lock_test_and_setMODE'. Operand 0 is the memory that 27039 contains the lock; operand 1 is the value to store in the lock. 27040 27041 If the target doesn't implement full semantics for 27042 'sync_lock_test_and_setMODE', any value operand which is not the 27043 constant 0 should be rejected with 'FAIL', and the true contents of 27044 the memory operand are implementation defined. 27045 27046 This pattern must issue any memory barrier instructions such that 27047 the pattern as a whole acts as a release barrier, that is the lock 27048 is released only after all previous memory operations have 27049 completed. 27050 27051 If this pattern is not defined, then a 'memory_barrier' pattern 27052 will be emitted, followed by a store of the value to the memory 27053 operand. 27054 27055'atomic_compare_and_swapMODE' 27056 This pattern, if defined, emits code for an atomic compare-and-swap 27057 operation with memory model semantics. Operand 2 is the memory on 27058 which the atomic operation is performed. Operand 0 is an output 27059 operand which is set to true or false based on whether the 27060 operation succeeded. Operand 1 is an output operand which is set 27061 to the contents of the memory before the operation was attempted. 27062 Operand 3 is the value that is expected to be in memory. Operand 4 27063 is the value to put in memory if the expected value is found there. 27064 Operand 5 is set to 1 if this compare and swap is to be treated as 27065 a weak operation. Operand 6 is the memory model to be used if the 27066 operation is a success. Operand 7 is the memory model to be used 27067 if the operation fails. 27068 27069 If memory referred to in operand 2 contains the value in operand 3, 27070 then operand 4 is stored in memory pointed to by operand 2 and 27071 fencing based on the memory model in operand 6 is issued. 27072 27073 If memory referred to in operand 2 does not contain the value in 27074 operand 3, then fencing based on the memory model in operand 7 is 27075 issued. 27076 27077 If a target does not support weak compare-and-swap operations, or 27078 the port elects not to implement weak operations, the argument in 27079 operand 5 can be ignored. Note a strong implementation must be 27080 provided. 27081 27082 If this pattern is not provided, the '__atomic_compare_exchange' 27083 built-in functions will utilize the legacy 'sync_compare_and_swap' 27084 pattern with an '__ATOMIC_SEQ_CST' memory model. 27085 27086'atomic_loadMODE' 27087 This pattern implements an atomic load operation with memory model 27088 semantics. Operand 1 is the memory address being loaded from. 27089 Operand 0 is the result of the load. Operand 2 is the memory model 27090 to be used for the load operation. 27091 27092 If not present, the '__atomic_load' built-in function will either 27093 resort to a normal load with memory barriers, or a compare-and-swap 27094 operation if a normal load would not be atomic. 27095 27096'atomic_storeMODE' 27097 This pattern implements an atomic store operation with memory model 27098 semantics. Operand 0 is the memory address being stored to. 27099 Operand 1 is the value to be written. Operand 2 is the memory 27100 model to be used for the operation. 27101 27102 If not present, the '__atomic_store' built-in function will attempt 27103 to perform a normal store and surround it with any required memory 27104 fences. If the store would not be atomic, then an 27105 '__atomic_exchange' is attempted with the result being ignored. 27106 27107'atomic_exchangeMODE' 27108 This pattern implements an atomic exchange operation with memory 27109 model semantics. Operand 1 is the memory location the operation is 27110 performed on. Operand 0 is an output operand which is set to the 27111 original value contained in the memory pointed to by operand 1. 27112 Operand 2 is the value to be stored. Operand 3 is the memory model 27113 to be used. 27114 27115 If this pattern is not present, the built-in function 27116 '__atomic_exchange' will attempt to preform the operation with a 27117 compare and swap loop. 27118 27119'atomic_addMODE', 'atomic_subMODE' 27120'atomic_orMODE', 'atomic_andMODE' 27121'atomic_xorMODE', 'atomic_nandMODE' 27122 These patterns emit code for an atomic operation on memory with 27123 memory model semantics. Operand 0 is the memory on which the 27124 atomic operation is performed. Operand 1 is the second operand to 27125 the binary operator. Operand 2 is the memory model to be used by 27126 the operation. 27127 27128 If these patterns are not defined, attempts will be made to use 27129 legacy 'sync' patterns, or equivalent patterns which return a 27130 result. If none of these are available a compare-and-swap loop 27131 will be used. 27132 27133'atomic_fetch_addMODE', 'atomic_fetch_subMODE' 27134'atomic_fetch_orMODE', 'atomic_fetch_andMODE' 27135'atomic_fetch_xorMODE', 'atomic_fetch_nandMODE' 27136 These patterns emit code for an atomic operation on memory with 27137 memory model semantics, and return the original value. Operand 0 27138 is an output operand which contains the value of the memory 27139 location before the operation was performed. Operand 1 is the 27140 memory on which the atomic operation is performed. Operand 2 is 27141 the second operand to the binary operator. Operand 3 is the memory 27142 model to be used by the operation. 27143 27144 If these patterns are not defined, attempts will be made to use 27145 legacy 'sync' patterns. If none of these are available a 27146 compare-and-swap loop will be used. 27147 27148'atomic_add_fetchMODE', 'atomic_sub_fetchMODE' 27149'atomic_or_fetchMODE', 'atomic_and_fetchMODE' 27150'atomic_xor_fetchMODE', 'atomic_nand_fetchMODE' 27151 These patterns emit code for an atomic operation on memory with 27152 memory model semantics and return the result after the operation is 27153 performed. Operand 0 is an output operand which contains the value 27154 after the operation. Operand 1 is the memory on which the atomic 27155 operation is performed. Operand 2 is the second operand to the 27156 binary operator. Operand 3 is the memory model to be used by the 27157 operation. 27158 27159 If these patterns are not defined, attempts will be made to use 27160 legacy 'sync' patterns, or equivalent patterns which return the 27161 result before the operation followed by the arithmetic operation 27162 required to produce the result. If none of these are available a 27163 compare-and-swap loop will be used. 27164 27165'atomic_test_and_set' 27166 This pattern emits code for '__builtin_atomic_test_and_set'. 27167 Operand 0 is an output operand which is set to true if the previous 27168 previous contents of the byte was "set", and false otherwise. 27169 Operand 1 is the 'QImode' memory to be modified. Operand 2 is the 27170 memory model to be used. 27171 27172 The specific value that defines "set" is implementation defined, 27173 and is normally based on what is performed by the native atomic 27174 test and set instruction. 27175 27176'atomic_bit_test_and_setMODE' 27177'atomic_bit_test_and_complementMODE' 27178'atomic_bit_test_and_resetMODE' 27179 These patterns emit code for an atomic bitwise operation on memory 27180 with memory model semantics, and return the original value of the 27181 specified bit. Operand 0 is an output operand which contains the 27182 value of the specified bit from the memory location before the 27183 operation was performed. Operand 1 is the memory on which the 27184 atomic operation is performed. Operand 2 is the bit within the 27185 operand, starting with least significant bit. Operand 3 is the 27186 memory model to be used by the operation. Operand 4 is a flag - it 27187 is 'const1_rtx' if operand 0 should contain the original value of 27188 the specified bit in the least significant bit of the operand, and 27189 'const0_rtx' if the bit should be in its original position in the 27190 operand. 'atomic_bit_test_and_setMODE' atomically sets the 27191 specified bit after remembering its original value, 27192 'atomic_bit_test_and_complementMODE' inverts the specified bit and 27193 'atomic_bit_test_and_resetMODE' clears the specified bit. 27194 27195 If these patterns are not defined, attempts will be made to use 27196 'atomic_fetch_orMODE', 'atomic_fetch_xorMODE' or 27197 'atomic_fetch_andMODE' instruction patterns, or their 'sync' 27198 counterparts. If none of these are available a compare-and-swap 27199 loop will be used. 27200 27201'mem_thread_fence' 27202 This pattern emits code required to implement a thread fence with 27203 memory model semantics. Operand 0 is the memory model to be used. 27204 27205 For the '__ATOMIC_RELAXED' model no instructions need to be issued 27206 and this expansion is not invoked. 27207 27208 The compiler always emits a compiler memory barrier regardless of 27209 what expanding this pattern produced. 27210 27211 If this pattern is not defined, the compiler falls back to 27212 expanding the 'memory_barrier' pattern, then to emitting 27213 '__sync_synchronize' library call, and finally to just placing a 27214 compiler memory barrier. 27215 27216'get_thread_pointerMODE' 27217'set_thread_pointerMODE' 27218 These patterns emit code that reads/sets the TLS thread pointer. 27219 Currently, these are only needed if the target needs to support the 27220 '__builtin_thread_pointer' and '__builtin_set_thread_pointer' 27221 builtins. 27222 27223 The get/set patterns have a single output/input operand 27224 respectively, with MODE intended to be 'Pmode'. 27225 27226'stack_protect_combined_set' 27227 This pattern, if defined, moves a 'ptr_mode' value from an address 27228 whose declaration RTX is given in operand 1 to the memory in 27229 operand 0 without leaving the value in a register afterward. If 27230 several instructions are needed by the target to perform the 27231 operation (eg. to load the address from a GOT entry then load the 27232 'ptr_mode' value and finally store it), it is the backend's 27233 responsibility to ensure no intermediate result gets spilled. This 27234 is to avoid leaking the value some place that an attacker might use 27235 to rewrite the stack guard slot after having clobbered it. 27236 27237 If this pattern is not defined, then the address declaration is 27238 expanded first in the standard way and a 'stack_protect_set' 27239 pattern is then generated to move the value from that address to 27240 the address in operand 0. 27241 27242'stack_protect_set' 27243 This pattern, if defined, moves a 'ptr_mode' value from the valid 27244 memory location in operand 1 to the memory in operand 0 without 27245 leaving the value in a register afterward. This is to avoid 27246 leaking the value some place that an attacker might use to rewrite 27247 the stack guard slot after having clobbered it. 27248 27249 Note: on targets where the addressing modes do not allow to load 27250 directly from stack guard address, the address is expanded in a 27251 standard way first which could cause some spills. 27252 27253 If this pattern is not defined, then a plain move pattern is 27254 generated. 27255 27256'stack_protect_combined_test' 27257 This pattern, if defined, compares a 'ptr_mode' value from an 27258 address whose declaration RTX is given in operand 1 with the memory 27259 in operand 0 without leaving the value in a register afterward and 27260 branches to operand 2 if the values were equal. If several 27261 instructions are needed by the target to perform the operation (eg. 27262 to load the address from a GOT entry then load the 'ptr_mode' value 27263 and finally store it), it is the backend's responsibility to ensure 27264 no intermediate result gets spilled. This is to avoid leaking the 27265 value some place that an attacker might use to rewrite the stack 27266 guard slot after having clobbered it. 27267 27268 If this pattern is not defined, then the address declaration is 27269 expanded first in the standard way and a 'stack_protect_test' 27270 pattern is then generated to compare the value from that address to 27271 the value at the memory in operand 0. 27272 27273'stack_protect_test' 27274 This pattern, if defined, compares a 'ptr_mode' value from the 27275 valid memory location in operand 1 with the memory in operand 0 27276 without leaving the value in a register afterward and branches to 27277 operand 2 if the values were equal. 27278 27279 If this pattern is not defined, then a plain compare pattern and 27280 conditional branch pattern is used. 27281 27282'clear_cache' 27283 This pattern, if defined, flushes the instruction cache for a 27284 region of memory. The region is bounded to by the Pmode pointers 27285 in operand 0 inclusive and operand 1 exclusive. 27286 27287 If this pattern is not defined, a call to the library function 27288 '__clear_cache' is used. 27289 27290 27291File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc 27292 2729317.10 When the Order of Patterns Matters 27294======================================== 27295 27296Sometimes an insn can match more than one instruction pattern. Then the 27297pattern that appears first in the machine description is the one used. 27298Therefore, more specific patterns (patterns that will match fewer 27299things) and faster instructions (those that will produce better code 27300when they do match) should usually go first in the description. 27301 27302 In some cases the effect of ordering the patterns can be used to hide a 27303pattern when it is not valid. For example, the 68000 has an instruction 27304for converting a fullword to floating point and another for converting a 27305byte to floating point. An instruction converting an integer to 27306floating point could match either one. We put the pattern to convert 27307the fullword first to make sure that one will be used rather than the 27308other. (Otherwise a large integer might be generated as a single-byte 27309immediate quantity, which would not work.) Instead of using this 27310pattern ordering it would be possible to make the pattern for 27311convert-a-byte smart enough to deal properly with any constant value. 27312 27313 27314File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc 27315 2731617.11 Interdependence of Patterns 27317================================= 27318 27319In some cases machines support instructions identical except for the 27320machine mode of one or more operands. For example, there may be 27321"sign-extend halfword" and "sign-extend byte" instructions whose 27322patterns are 27323 27324 (set (match_operand:SI 0 ...) 27325 (extend:SI (match_operand:HI 1 ...))) 27326 27327 (set (match_operand:SI 0 ...) 27328 (extend:SI (match_operand:QI 1 ...))) 27329 27330Constant integers do not specify a machine mode, so an instruction to 27331extend a constant value could match either pattern. The pattern it 27332actually will match is the one that appears first in the file. For 27333correct results, this must be the one for the widest possible mode 27334('HImode', here). If the pattern matches the 'QImode' instruction, the 27335results will be incorrect if the constant value does not actually fit 27336that mode. 27337 27338 Such instructions to extend constants are rarely generated because they 27339are optimized away, but they do occasionally happen in nonoptimized 27340compilations. 27341 27342 If a constraint in a pattern allows a constant, the reload pass may 27343replace a register with a constant permitted by the constraint in some 27344cases. Similarly for memory references. Because of this substitution, 27345you should not provide separate patterns for increment and decrement 27346instructions. Instead, they should be generated from the same pattern 27347that supports register-register add insns by examining the operands and 27348generating the appropriate machine instruction. 27349 27350 27351File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc 27352 2735317.12 Defining Jump Instruction Patterns 27354======================================== 27355 27356GCC does not assume anything about how the machine realizes jumps. The 27357machine description should define a single pattern, usually a 27358'define_expand', which expands to all the required insns. 27359 27360 Usually, this would be a comparison insn to set the condition code and 27361a separate branch insn testing the condition code and branching or not 27362according to its value. For many machines, however, separating compares 27363and branches is limiting, which is why the more flexible approach with 27364one 'define_expand' is used in GCC. The machine description becomes 27365clearer for architectures that have compare-and-branch instructions but 27366no condition code. It also works better when different sets of 27367comparison operators are supported by different kinds of conditional 27368branches (e.g. integer vs. floating-point), or by conditional branches 27369with respect to conditional stores. 27370 27371 Two separate insns are always used if the machine description 27372represents a condition code register using the legacy RTL expression 27373'(cc0)', and on most machines that use a separate condition code 27374register (*note Condition Code::). For machines that use '(cc0)', in 27375fact, the set and use of the condition code must be separate and 27376adjacent(1), thus allowing flags in 'cc_status' to be used (*note 27377Condition Code::) and so that the comparison and branch insns could be 27378located from each other by using the functions 'prev_cc0_setter' and 27379'next_cc0_user'. 27380 27381 Even in this case having a single entry point for conditional branches 27382is advantageous, because it handles equally well the case where a single 27383comparison instruction records the results of both signed and unsigned 27384comparison of the given operands (with the branch insns coming in 27385distinct signed and unsigned flavors) as in the x86 or SPARC, and the 27386case where there are distinct signed and unsigned compare instructions 27387and only one set of conditional branch instructions as in the PowerPC. 27388 27389 ---------- Footnotes ---------- 27390 27391 (1) 'note' insns can separate them, though. 27392 27393 27394File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc 27395 2739617.13 Defining Looping Instruction Patterns 27397=========================================== 27398 27399Some machines have special jump instructions that can be utilized to 27400make loops more efficient. A common example is the 68000 'dbra' 27401instruction which performs a decrement of a register and a branch if the 27402result was greater than zero. Other machines, in particular digital 27403signal processors (DSPs), have special block repeat instructions to 27404provide low-overhead loop support. For example, the TI TMS320C3x/C4x 27405DSPs have a block repeat instruction that loads special registers to 27406mark the top and end of a loop and to count the number of loop 27407iterations. This avoids the need for fetching and executing a 27408'dbra'-like instruction and avoids pipeline stalls associated with the 27409jump. 27410 27411 GCC has two special named patterns to support low overhead looping. 27412They are 'doloop_begin' and 'doloop_end'. These are emitted by the loop 27413optimizer for certain well-behaved loops with a finite number of loop 27414iterations using information collected during strength reduction. 27415 27416 The 'doloop_end' pattern describes the actual looping instruction (or 27417the implicit looping operation) and the 'doloop_begin' pattern is an 27418optional companion pattern that can be used for initialization needed 27419for some low-overhead looping instructions. 27420 27421 Note that some machines require the actual looping instruction to be 27422emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting 27423the true RTL for a looping instruction at the top of the loop can cause 27424problems with flow analysis. So instead, a dummy 'doloop' insn is 27425emitted at the end of the loop. The machine dependent reorg pass checks 27426for the presence of this 'doloop' insn and then searches back to the top 27427of the loop, where it inserts the true looping insn (provided there are 27428no instructions in the loop which would cause problems). Any additional 27429labels can be emitted at this point. In addition, if the desired 27430special iteration counter register was not allocated, this machine 27431dependent reorg pass could emit a traditional compare and jump 27432instruction pair. 27433 27434 For the 'doloop_end' pattern, the loop optimizer allocates an 27435additional pseudo register as an iteration counter. This pseudo 27436register cannot be used within the loop (i.e., general induction 27437variables cannot be derived from it), however, in many cases the loop 27438induction variable may become redundant and removed by the flow pass. 27439 27440 The 'doloop_end' pattern must have a specific structure to be handled 27441correctly by GCC. The example below is taken (slightly simplified) from 27442the PDP-11 target: 27443 27444 (define_expand "doloop_end" 27445 [(parallel [(set (pc) 27446 (if_then_else 27447 (ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m") 27448 (const_int 1)) 27449 (label_ref (match_operand 1 "" "")) 27450 (pc))) 27451 (set (match_dup 0) 27452 (plus:HI (match_dup 0) 27453 (const_int -1)))])] 27454 "" 27455 "{ 27456 if (GET_MODE (operands[0]) != HImode) 27457 FAIL; 27458 }") 27459 27460 (define_insn "doloop_end_insn" 27461 [(set (pc) 27462 (if_then_else 27463 (ne (match_operand:HI 0 "nonimmediate_operand" "+r,!m") 27464 (const_int 1)) 27465 (label_ref (match_operand 1 "" "")) 27466 (pc))) 27467 (set (match_dup 0) 27468 (plus:HI (match_dup 0) 27469 (const_int -1)))] 27470 "" 27471 27472 { 27473 if (which_alternative == 0) 27474 return "sob %0,%l1"; 27475 27476 /* emulate sob */ 27477 output_asm_insn ("dec %0", operands); 27478 return "bne %l1"; 27479 }) 27480 27481 The first part of the pattern describes the branch condition. GCC 27482supports three cases for the way the target machine handles the loop 27483counter: 27484 * Loop terminates when the loop register decrements to zero. This is 27485 represented by a 'ne' comparison of the register (its old value) 27486 with constant 1 (as in the example above). 27487 * Loop terminates when the loop register decrements to -1. This is 27488 represented by a 'ne' comparison of the register with constant 27489 zero. 27490 * Loop terminates when the loop register decrements to a negative 27491 value. This is represented by a 'ge' comparison of the register 27492 with constant zero. For this case, GCC will attach a 'REG_NONNEG' 27493 note to the 'doloop_end' insn if it can determine that the register 27494 will be non-negative. 27495 27496 Since the 'doloop_end' insn is a jump insn that also has an output, the 27497reload pass does not handle the output operand. Therefore, the 27498constraint must allow for that operand to be in memory rather than a 27499register. In the example shown above, that is handled (in the 27500'doloop_end_insn' pattern) by using a loop instruction sequence that can 27501handle memory operands when the memory alternative appears. 27502 27503 GCC does not check the mode of the loop register operand when 27504generating the 'doloop_end' pattern. If the pattern is only valid for 27505some modes but not others, the pattern should be a 'define_expand' 27506pattern that checks the operand mode in the preparation code, and issues 27507'FAIL' if an unsupported mode is found. The example above does this, 27508since the machine instruction to be used only exists for 'HImode'. 27509 27510 If the 'doloop_end' pattern is a 'define_expand', there must also be a 27511'define_insn' or 'define_insn_and_split' matching the generated pattern. 27512Otherwise, the compiler will fail during loop optimization. 27513 27514 27515File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc 27516 2751717.14 Canonicalization of Instructions 27518====================================== 27519 27520There are often cases where multiple RTL expressions could represent an 27521operation performed by a single machine instruction. This situation is 27522most commonly encountered with logical, branch, and multiply-accumulate 27523instructions. In such cases, the compiler attempts to convert these 27524multiple RTL expressions into a single canonical form to reduce the 27525number of insn patterns required. 27526 27527 In addition to algebraic simplifications, following canonicalizations 27528are performed: 27529 27530 * For commutative and comparison operators, a constant is always made 27531 the second operand. If a machine only supports a constant as the 27532 second operand, only patterns that match a constant in the second 27533 operand need be supplied. 27534 27535 * For associative operators, a sequence of operators will always 27536 chain to the left; for instance, only the left operand of an 27537 integer 'plus' can itself be a 'plus'. 'and', 'ior', 'xor', 27538 'plus', 'mult', 'smin', 'smax', 'umin', and 'umax' are associative 27539 when applied to integers, and sometimes to floating-point. 27540 27541 * For these operators, if only one operand is a 'neg', 'not', 'mult', 27542 'plus', or 'minus' expression, it will be the first operand. 27543 27544 * In combinations of 'neg', 'mult', 'plus', and 'minus', the 'neg' 27545 operations (if any) will be moved inside the operations as far as 27546 possible. For instance, '(neg (mult A B))' is canonicalized as 27547 '(mult (neg A) B)', but '(plus (mult (neg B) C) A)' is 27548 canonicalized as '(minus A (mult B C))'. 27549 27550 * For the 'compare' operator, a constant is always the second operand 27551 if the first argument is a condition code register or '(cc0)'. 27552 27553 * For instructions that inherently set a condition code register, the 27554 'compare' operator is always written as the first RTL expression of 27555 the 'parallel' instruction pattern. For example, 27556 27557 (define_insn "" 27558 [(set (reg:CCZ FLAGS_REG) 27559 (compare:CCZ 27560 (plus:SI 27561 (match_operand:SI 1 "register_operand" "%r") 27562 (match_operand:SI 2 "register_operand" "r")) 27563 (const_int 0))) 27564 (set (match_operand:SI 0 "register_operand" "=r") 27565 (plus:SI (match_dup 1) (match_dup 2)))] 27566 "" 27567 "addl %0, %1, %2") 27568 27569 * An operand of 'neg', 'not', 'mult', 'plus', or 'minus' is made the 27570 first operand under the same conditions as above. 27571 27572 * '(ltu (plus A B) B)' is converted to '(ltu (plus A B) A)'. 27573 Likewise with 'geu' instead of 'ltu'. 27574 27575 * '(minus X (const_int N))' is converted to '(plus X (const_int 27576 -N))'. 27577 27578 * Within address computations (i.e., inside 'mem'), a left shift is 27579 converted into the appropriate multiplication by a power of two. 27580 27581 * De Morgan's Law is used to move bitwise negation inside a bitwise 27582 logical-and or logical-or operation. If this results in only one 27583 operand being a 'not' expression, it will be the first one. 27584 27585 A machine that has an instruction that performs a bitwise 27586 logical-and of one operand with the bitwise negation of the other 27587 should specify the pattern for that instruction as 27588 27589 (define_insn "" 27590 [(set (match_operand:M 0 ...) 27591 (and:M (not:M (match_operand:M 1 ...)) 27592 (match_operand:M 2 ...)))] 27593 "..." 27594 "...") 27595 27596 Similarly, a pattern for a "NAND" instruction should be written 27597 27598 (define_insn "" 27599 [(set (match_operand:M 0 ...) 27600 (ior:M (not:M (match_operand:M 1 ...)) 27601 (not:M (match_operand:M 2 ...))))] 27602 "..." 27603 "...") 27604 27605 In both cases, it is not necessary to include patterns for the many 27606 logically equivalent RTL expressions. 27607 27608 * The only possible RTL expressions involving both bitwise 27609 exclusive-or and bitwise negation are '(xor:M X Y)' and '(not:M 27610 (xor:M X Y))'. 27611 27612 * The sum of three items, one of which is a constant, will only 27613 appear in the form 27614 27615 (plus:M (plus:M X Y) CONSTANT) 27616 27617 * Equality comparisons of a group of bits (usually a single bit) with 27618 zero will be written using 'zero_extract' rather than the 27619 equivalent 'and' or 'sign_extract' operations. 27620 27621 * '(sign_extend:M1 (mult:M2 (sign_extend:M2 X) (sign_extend:M2 Y)))' 27622 is converted to '(mult:M1 (sign_extend:M1 X) (sign_extend:M1 Y))', 27623 and likewise for 'zero_extend'. 27624 27625 * '(sign_extend:M1 (mult:M2 (ashiftrt:M2 X S) (sign_extend:M2 Y)))' 27626 is converted to '(mult:M1 (sign_extend:M1 (ashiftrt:M2 X S)) 27627 (sign_extend:M1 Y))', and likewise for patterns using 'zero_extend' 27628 and 'lshiftrt'. If the second operand of 'mult' is also a shift, 27629 then that is extended also. This transformation is only applied 27630 when it can be proven that the original operation had sufficient 27631 precision to prevent overflow. 27632 27633 Further canonicalization rules are defined in the function 27634'commutative_operand_precedence' in 'gcc/rtlanal.c'. 27635 27636 27637File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc 27638 2763917.15 Defining RTL Sequences for Code Generation 27640================================================ 27641 27642On some target machines, some standard pattern names for RTL generation 27643cannot be handled with single insn, but a sequence of RTL insns can 27644represent them. For these target machines, you can write a 27645'define_expand' to specify how to generate the sequence of RTL. 27646 27647 A 'define_expand' is an RTL expression that looks almost like a 27648'define_insn'; but, unlike the latter, a 'define_expand' is used only 27649for RTL generation and it can produce more than one RTL insn. 27650 27651 A 'define_expand' RTX has four operands: 27652 27653 * The name. Each 'define_expand' must have a name, since the only 27654 use for it is to refer to it by name. 27655 27656 * The RTL template. This is a vector of RTL expressions representing 27657 a sequence of separate instructions. Unlike 'define_insn', there 27658 is no implicit surrounding 'PARALLEL'. 27659 27660 * The condition, a string containing a C expression. This expression 27661 is used to express how the availability of this pattern depends on 27662 subclasses of target machine, selected by command-line options when 27663 GCC is run. This is just like the condition of a 'define_insn' 27664 that has a standard name. Therefore, the condition (if present) 27665 may not depend on the data in the insn being matched, but only the 27666 target-machine-type flags. The compiler needs to test these 27667 conditions during initialization in order to learn exactly which 27668 named instructions are available in a particular run. 27669 27670 * The preparation statements, a string containing zero or more C 27671 statements which are to be executed before RTL code is generated 27672 from the RTL template. 27673 27674 Usually these statements prepare temporary registers for use as 27675 internal operands in the RTL template, but they can also generate 27676 RTL insns directly by calling routines such as 'emit_insn', etc. 27677 Any such insns precede the ones that come from the RTL template. 27678 27679 * Optionally, a vector containing the values of attributes. *Note 27680 Insn Attributes::. 27681 27682 Every RTL insn emitted by a 'define_expand' must match some 27683'define_insn' in the machine description. Otherwise, the compiler will 27684crash when trying to generate code for the insn or trying to optimize 27685it. 27686 27687 The RTL template, in addition to controlling generation of RTL insns, 27688also describes the operands that need to be specified when this pattern 27689is used. In particular, it gives a predicate for each operand. 27690 27691 A true operand, which needs to be specified in order to generate RTL 27692from the pattern, should be described with a 'match_operand' in its 27693first occurrence in the RTL template. This enters information on the 27694operand's predicate into the tables that record such things. GCC uses 27695the information to preload the operand into a register if that is 27696required for valid RTL code. If the operand is referred to more than 27697once, subsequent references should use 'match_dup'. 27698 27699 The RTL template may also refer to internal "operands" which are 27700temporary registers or labels used only within the sequence made by the 27701'define_expand'. Internal operands are substituted into the RTL 27702template with 'match_dup', never with 'match_operand'. The values of 27703the internal operands are not passed in as arguments by the compiler 27704when it requests use of this pattern. Instead, they are computed within 27705the pattern, in the preparation statements. These statements compute 27706the values and store them into the appropriate elements of 'operands' so 27707that 'match_dup' can find them. 27708 27709 There are two special macros defined for use in the preparation 27710statements: 'DONE' and 'FAIL'. Use them with a following semicolon, as 27711a statement. 27712 27713'DONE' 27714 Use the 'DONE' macro to end RTL generation for the pattern. The 27715 only RTL insns resulting from the pattern on this occasion will be 27716 those already emitted by explicit calls to 'emit_insn' within the 27717 preparation statements; the RTL template will not be generated. 27718 27719'FAIL' 27720 Make the pattern fail on this occasion. When a pattern fails, it 27721 means that the pattern was not truly available. The calling 27722 routines in the compiler will try other strategies for code 27723 generation using other patterns. 27724 27725 Failure is currently supported only for binary (addition, 27726 multiplication, shifting, etc.) and bit-field ('extv', 'extzv', 27727 and 'insv') operations. 27728 27729 If the preparation falls through (invokes neither 'DONE' nor 'FAIL'), 27730then the 'define_expand' acts like a 'define_insn' in that the RTL 27731template is used to generate the insn. 27732 27733 The RTL template is not used for matching, only for generating the 27734initial insn list. If the preparation statement always invokes 'DONE' 27735or 'FAIL', the RTL template may be reduced to a simple list of operands, 27736such as this example: 27737 27738 (define_expand "addsi3" 27739 [(match_operand:SI 0 "register_operand" "") 27740 (match_operand:SI 1 "register_operand" "") 27741 (match_operand:SI 2 "register_operand" "")] 27742 "" 27743 " 27744 { 27745 handle_add (operands[0], operands[1], operands[2]); 27746 DONE; 27747 }") 27748 27749 Here is an example, the definition of left-shift for the SPUR chip: 27750 27751 (define_expand "ashlsi3" 27752 [(set (match_operand:SI 0 "register_operand" "") 27753 (ashift:SI 27754 (match_operand:SI 1 "register_operand" "") 27755 (match_operand:SI 2 "nonmemory_operand" "")))] 27756 "" 27757 " 27758 27759 { 27760 if (GET_CODE (operands[2]) != CONST_INT 27761 || (unsigned) INTVAL (operands[2]) > 3) 27762 FAIL; 27763 }") 27764 27765This example uses 'define_expand' so that it can generate an RTL insn 27766for shifting when the shift-count is in the supported range of 0 to 3 27767but fail in other cases where machine insns aren't available. When it 27768fails, the compiler tries another strategy using different patterns 27769(such as, a library call). 27770 27771 If the compiler were able to handle nontrivial condition-strings in 27772patterns with names, then it would be possible to use a 'define_insn' in 27773that case. Here is another case (zero-extension on the 68000) which 27774makes more use of the power of 'define_expand': 27775 27776 (define_expand "zero_extendhisi2" 27777 [(set (match_operand:SI 0 "general_operand" "") 27778 (const_int 0)) 27779 (set (strict_low_part 27780 (subreg:HI 27781 (match_dup 0) 27782 0)) 27783 (match_operand:HI 1 "general_operand" ""))] 27784 "" 27785 "operands[1] = make_safe_from (operands[1], operands[0]);") 27786 27787Here two RTL insns are generated, one to clear the entire output operand 27788and the other to copy the input operand into its low half. This 27789sequence is incorrect if the input operand refers to [the old value of] 27790the output operand, so the preparation statement makes sure this isn't 27791so. The function 'make_safe_from' copies the 'operands[1]' into a 27792temporary register if it refers to 'operands[0]'. It does this by 27793emitting another RTL insn. 27794 27795 Finally, a third example shows the use of an internal operand. 27796Zero-extension on the SPUR chip is done by 'and'-ing the result against 27797a halfword mask. But this mask cannot be represented by a 'const_int' 27798because the constant value is too large to be legitimate on this 27799machine. So it must be copied into a register with 'force_reg' and then 27800the register used in the 'and'. 27801 27802 (define_expand "zero_extendhisi2" 27803 [(set (match_operand:SI 0 "register_operand" "") 27804 (and:SI (subreg:SI 27805 (match_operand:HI 1 "register_operand" "") 27806 0) 27807 (match_dup 2)))] 27808 "" 27809 "operands[2] 27810 = force_reg (SImode, GEN_INT (65535)); ") 27811 27812 _Note:_ If the 'define_expand' is used to serve a standard binary or 27813unary arithmetic operation or a bit-field operation, then the last insn 27814it generates must not be a 'code_label', 'barrier' or 'note'. It must 27815be an 'insn', 'jump_insn' or 'call_insn'. If you don't need a real insn 27816at the end, emit an insn to copy the result of the operation into 27817itself. Such an insn will generate no code, but it can avoid problems 27818in the compiler. 27819 27820 27821File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc 27822 2782317.16 Defining How to Split Instructions 27824======================================== 27825 27826There are two cases where you should specify how to split a pattern into 27827multiple insns. On machines that have instructions requiring delay 27828slots (*note Delay Slots::) or that have instructions whose output is 27829not available for multiple cycles (*note Processor pipeline 27830description::), the compiler phases that optimize these cases need to be 27831able to move insns into one-instruction delay slots. However, some 27832insns may generate more than one machine instruction. These insns 27833cannot be placed into a delay slot. 27834 27835 Often you can rewrite the single insn as a list of individual insns, 27836each corresponding to one machine instruction. The disadvantage of 27837doing so is that it will cause the compilation to be slower and require 27838more space. If the resulting insns are too complex, it may also 27839suppress some optimizations. The compiler splits the insn if there is a 27840reason to believe that it might improve instruction or delay slot 27841scheduling. 27842 27843 The insn combiner phase also splits putative insns. If three insns are 27844merged into one insn with a complex expression that cannot be matched by 27845some 'define_insn' pattern, the combiner phase attempts to split the 27846complex pattern into two insns that are recognized. Usually it can 27847break the complex pattern into two patterns by splitting out some 27848subexpression. However, in some other cases, such as performing an 27849addition of a large constant in two insns on a RISC machine, the way to 27850split the addition into two insns is machine-dependent. 27851 27852 The 'define_split' definition tells the compiler how to split a complex 27853insn into several simpler insns. It looks like this: 27854 27855 (define_split 27856 [INSN-PATTERN] 27857 "CONDITION" 27858 [NEW-INSN-PATTERN-1 27859 NEW-INSN-PATTERN-2 27860 ...] 27861 "PREPARATION-STATEMENTS") 27862 27863 INSN-PATTERN is a pattern that needs to be split and CONDITION is the 27864final condition to be tested, as in a 'define_insn'. When an insn 27865matching INSN-PATTERN and satisfying CONDITION is found, it is replaced 27866in the insn list with the insns given by NEW-INSN-PATTERN-1, 27867NEW-INSN-PATTERN-2, etc. 27868 27869 The PREPARATION-STATEMENTS are similar to those statements that are 27870specified for 'define_expand' (*note Expander Definitions::) and are 27871executed before the new RTL is generated to prepare for the generated 27872code or emit some insns whose pattern is not fixed. Unlike those in 27873'define_expand', however, these statements must not generate any new 27874pseudo-registers. Once reload has completed, they also must not 27875allocate any space in the stack frame. 27876 27877 There are two special macros defined for use in the preparation 27878statements: 'DONE' and 'FAIL'. Use them with a following semicolon, as 27879a statement. 27880 27881'DONE' 27882 Use the 'DONE' macro to end RTL generation for the splitter. The 27883 only RTL insns generated as replacement for the matched input insn 27884 will be those already emitted by explicit calls to 'emit_insn' 27885 within the preparation statements; the replacement pattern is not 27886 used. 27887 27888'FAIL' 27889 Make the 'define_split' fail on this occasion. When a 27890 'define_split' fails, it means that the splitter was not truly 27891 available for the inputs it was given, and the input insn will not 27892 be split. 27893 27894 If the preparation falls through (invokes neither 'DONE' nor 'FAIL'), 27895then the 'define_split' uses the replacement template. 27896 27897 Patterns are matched against INSN-PATTERN in two different 27898circumstances. If an insn needs to be split for delay slot scheduling 27899or insn scheduling, the insn is already known to be valid, which means 27900that it must have been matched by some 'define_insn' and, if 27901'reload_completed' is nonzero, is known to satisfy the constraints of 27902that 'define_insn'. In that case, the new insn patterns must also be 27903insns that are matched by some 'define_insn' and, if 'reload_completed' 27904is nonzero, must also satisfy the constraints of those definitions. 27905 27906 As an example of this usage of 'define_split', consider the following 27907example from 'a29k.md', which splits a 'sign_extend' from 'HImode' to 27908'SImode' into a pair of shift insns: 27909 27910 (define_split 27911 [(set (match_operand:SI 0 "gen_reg_operand" "") 27912 (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] 27913 "" 27914 [(set (match_dup 0) 27915 (ashift:SI (match_dup 1) 27916 (const_int 16))) 27917 (set (match_dup 0) 27918 (ashiftrt:SI (match_dup 0) 27919 (const_int 16)))] 27920 " 27921 { operands[1] = gen_lowpart (SImode, operands[1]); }") 27922 27923 When the combiner phase tries to split an insn pattern, it is always 27924the case that the pattern is _not_ matched by any 'define_insn'. The 27925combiner pass first tries to split a single 'set' expression and then 27926the same 'set' expression inside a 'parallel', but followed by a 27927'clobber' of a pseudo-reg to use as a scratch register. In these cases, 27928the combiner expects exactly two new insn patterns to be generated. It 27929will verify that these patterns match some 'define_insn' definitions, so 27930you need not do this test in the 'define_split' (of course, there is no 27931point in writing a 'define_split' that will never produce insns that 27932match). 27933 27934 Here is an example of this use of 'define_split', taken from 27935'rs6000.md': 27936 27937 (define_split 27938 [(set (match_operand:SI 0 "gen_reg_operand" "") 27939 (plus:SI (match_operand:SI 1 "gen_reg_operand" "") 27940 (match_operand:SI 2 "non_add_cint_operand" "")))] 27941 "" 27942 [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) 27943 (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] 27944 " 27945 { 27946 int low = INTVAL (operands[2]) & 0xffff; 27947 int high = (unsigned) INTVAL (operands[2]) >> 16; 27948 27949 if (low & 0x8000) 27950 high++, low |= 0xffff0000; 27951 27952 operands[3] = GEN_INT (high << 16); 27953 operands[4] = GEN_INT (low); 27954 }") 27955 27956 Here the predicate 'non_add_cint_operand' matches any 'const_int' that 27957is _not_ a valid operand of a single add insn. The add with the smaller 27958displacement is written so that it can be substituted into the address 27959of a subsequent operation. 27960 27961 An example that uses a scratch register, from the same file, generates 27962an equality comparison of a register and a large constant: 27963 27964 (define_split 27965 [(set (match_operand:CC 0 "cc_reg_operand" "") 27966 (compare:CC (match_operand:SI 1 "gen_reg_operand" "") 27967 (match_operand:SI 2 "non_short_cint_operand" ""))) 27968 (clobber (match_operand:SI 3 "gen_reg_operand" ""))] 27969 "find_single_use (operands[0], insn, 0) 27970 && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ 27971 || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" 27972 [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) 27973 (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] 27974 " 27975 { 27976 /* Get the constant we are comparing against, C, and see what it 27977 looks like sign-extended to 16 bits. Then see what constant 27978 could be XOR'ed with C to get the sign-extended value. */ 27979 27980 int c = INTVAL (operands[2]); 27981 int sextc = (c << 16) >> 16; 27982 int xorv = c ^ sextc; 27983 27984 operands[4] = GEN_INT (xorv); 27985 operands[5] = GEN_INT (sextc); 27986 }") 27987 27988 To avoid confusion, don't write a single 'define_split' that accepts 27989some insns that match some 'define_insn' as well as some insns that 27990don't. Instead, write two separate 'define_split' definitions, one for 27991the insns that are valid and one for the insns that are not valid. 27992 27993 The splitter is allowed to split jump instructions into sequence of 27994jumps or create new jumps in while splitting non-jump instructions. As 27995the control flow graph and branch prediction information needs to be 27996updated, several restriction apply. 27997 27998 Splitting of jump instruction into sequence that over by another jump 27999instruction is always valid, as compiler expect identical behavior of 28000new jump. When new sequence contains multiple jump instructions or new 28001labels, more assistance is needed. Splitter is required to create only 28002unconditional jumps, or simple conditional jump instructions. 28003Additionally it must attach a 'REG_BR_PROB' note to each conditional 28004jump. A global variable 'split_branch_probability' holds the 28005probability of the original branch in case it was a simple conditional 28006jump, -1 otherwise. To simplify recomputing of edge frequencies, the 28007new sequence is required to have only forward jumps to the newly created 28008labels. 28009 28010 For the common case where the pattern of a define_split exactly matches 28011the pattern of a define_insn, use 'define_insn_and_split'. It looks 28012like this: 28013 28014 (define_insn_and_split 28015 [INSN-PATTERN] 28016 "CONDITION" 28017 "OUTPUT-TEMPLATE" 28018 "SPLIT-CONDITION" 28019 [NEW-INSN-PATTERN-1 28020 NEW-INSN-PATTERN-2 28021 ...] 28022 "PREPARATION-STATEMENTS" 28023 [INSN-ATTRIBUTES]) 28024 28025 28026 INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used 28027as in 'define_insn'. The NEW-INSN-PATTERN vector and the 28028PREPARATION-STATEMENTS are used as in a 'define_split'. The 28029SPLIT-CONDITION is also used as in 'define_split', with the additional 28030behavior that if the condition starts with '&&', the condition used for 28031the split will be the constructed as a logical "and" of the split 28032condition with the insn condition. For example, from i386.md: 28033 28034 (define_insn_and_split "zero_extendhisi2_and" 28035 [(set (match_operand:SI 0 "register_operand" "=r") 28036 (zero_extend:SI (match_operand:HI 1 "register_operand" "0"))) 28037 (clobber (reg:CC 17))] 28038 "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size" 28039 "#" 28040 "&& reload_completed" 28041 [(parallel [(set (match_dup 0) 28042 (and:SI (match_dup 0) (const_int 65535))) 28043 (clobber (reg:CC 17))])] 28044 "" 28045 [(set_attr "type" "alu1")]) 28046 28047 28048 In this case, the actual split condition will be 28049'TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'. 28050 28051 The 'define_insn_and_split' construction provides exactly the same 28052functionality as two separate 'define_insn' and 'define_split' patterns. 28053It exists for compactness, and as a maintenance tool to prevent having 28054to ensure the two patterns' templates match. 28055 28056 28057File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc 28058 2805917.17 Including Patterns in Machine Descriptions. 28060================================================= 28061 28062The 'include' pattern tells the compiler tools where to look for 28063patterns that are in files other than in the file '.md'. This is used 28064only at build time and there is no preprocessing allowed. 28065 28066 It looks like: 28067 28068 28069 (include 28070 PATHNAME) 28071 28072 For example: 28073 28074 28075 (include "filestuff") 28076 28077 28078 Where PATHNAME is a string that specifies the location of the file, 28079specifies the include file to be in 'gcc/config/target/filestuff'. The 28080directory 'gcc/config/target' is regarded as the default directory. 28081 28082 Machine descriptions may be split up into smaller more manageable 28083subsections and placed into subdirectories. 28084 28085 By specifying: 28086 28087 28088 (include "BOGUS/filestuff") 28089 28090 28091 the include file is specified to be in 28092'gcc/config/TARGET/BOGUS/filestuff'. 28093 28094 Specifying an absolute path for the include file such as; 28095 28096 (include "/u2/BOGUS/filestuff") 28097 28098 is permitted but is not encouraged. 28099 2810017.17.1 RTL Generation Tool Options for Directory Search 28101-------------------------------------------------------- 28102 28103The '-IDIR' option specifies directories to search for machine 28104descriptions. For example: 28105 28106 28107 genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md 28108 28109 28110 Add the directory DIR to the head of the list of directories to be 28111searched for header files. This can be used to override a system 28112machine definition file, substituting your own version, since these 28113directories are searched before the default machine description file 28114directories. If you use more than one '-I' option, the directories are 28115scanned in left-to-right order; the standard default directory come 28116after. 28117 28118 28119File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc 28120 2812117.18 Machine-Specific Peephole Optimizers 28122========================================== 28123 28124In addition to instruction patterns the 'md' file may contain 28125definitions of machine-specific peephole optimizations. 28126 28127 The combiner does not notice certain peephole optimizations when the 28128data flow in the program does not suggest that it should try them. For 28129example, sometimes two consecutive insns related in purpose can be 28130combined even though the second one does not appear to use a register 28131computed in the first one. A machine-specific peephole optimizer can 28132detect such opportunities. 28133 28134 There are two forms of peephole definitions that may be used. The 28135original 'define_peephole' is run at assembly output time to match insns 28136and substitute assembly text. Use of 'define_peephole' is deprecated. 28137 28138 A newer 'define_peephole2' matches insns and substitutes new insns. 28139The 'peephole2' pass is run after register allocation but before 28140scheduling, which may result in much better code for targets that do 28141scheduling. 28142 28143* Menu: 28144 28145* define_peephole:: RTL to Text Peephole Optimizers 28146* define_peephole2:: RTL to RTL Peephole Optimizers 28147 28148 28149File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions 28150 2815117.18.1 RTL to Text Peephole Optimizers 28152--------------------------------------- 28153 28154A definition looks like this: 28155 28156 (define_peephole 28157 [INSN-PATTERN-1 28158 INSN-PATTERN-2 28159 ...] 28160 "CONDITION" 28161 "TEMPLATE" 28162 "OPTIONAL-INSN-ATTRIBUTES") 28163 28164The last string operand may be omitted if you are not using any 28165machine-specific information in this machine description. If present, 28166it must obey the same rules as in a 'define_insn'. 28167 28168 In this skeleton, INSN-PATTERN-1 and so on are patterns to match 28169consecutive insns. The optimization applies to a sequence of insns when 28170INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next, 28171and so on. 28172 28173 Each of the insns matched by a peephole must also match a 28174'define_insn'. Peepholes are checked only at the last stage just before 28175code generation, and only optionally. Therefore, any insn which would 28176match a peephole but no 'define_insn' will cause a crash in code 28177generation in an unoptimized compilation, or at various optimization 28178stages. 28179 28180 The operands of the insns are matched with 'match_operands', 28181'match_operator', and 'match_dup', as usual. What is not usual is that 28182the operand numbers apply to all the insn patterns in the definition. 28183So, you can check for identical operands in two insns by using 28184'match_operand' in one insn and 'match_dup' in the other. 28185 28186 The operand constraints used in 'match_operand' patterns do not have 28187any direct effect on the applicability of the peephole, but they will be 28188validated afterward, so make sure your constraints are general enough to 28189apply whenever the peephole matches. If the peephole matches but the 28190constraints are not satisfied, the compiler will crash. 28191 28192 It is safe to omit constraints in all the operands of the peephole; or 28193you can write constraints which serve as a double-check on the criteria 28194previously tested. 28195 28196 Once a sequence of insns matches the patterns, the CONDITION is 28197checked. This is a C expression which makes the final decision whether 28198to perform the optimization (we do so if the expression is nonzero). If 28199CONDITION is omitted (in other words, the string is empty) then the 28200optimization is applied to every sequence of insns that matches the 28201patterns. 28202 28203 The defined peephole optimizations are applied after register 28204allocation is complete. Therefore, the peephole definition can check 28205which operands have ended up in which kinds of registers, just by 28206looking at the operands. 28207 28208 The way to refer to the operands in CONDITION is to write 'operands[I]' 28209for operand number I (as matched by '(match_operand I ...)'). Use the 28210variable 'insn' to refer to the last of the insns being matched; use 28211'prev_active_insn' to find the preceding insns. 28212 28213 When optimizing computations with intermediate results, you can use 28214CONDITION to match only when the intermediate results are not used 28215elsewhere. Use the C expression 'dead_or_set_p (INSN, OP)', where INSN 28216is the insn in which you expect the value to be used for the last time 28217(from the value of 'insn', together with use of 'prev_nonnote_insn'), 28218and OP is the intermediate value (from 'operands[I]'). 28219 28220 Applying the optimization means replacing the sequence of insns with 28221one new insn. The TEMPLATE controls ultimate output of assembler code 28222for this combined insn. It works exactly like the template of a 28223'define_insn'. Operand numbers in this template are the same ones used 28224in matching the original sequence of insns. 28225 28226 The result of a defined peephole optimizer does not need to match any 28227of the insn patterns in the machine description; it does not even have 28228an opportunity to match them. The peephole optimizer definition itself 28229serves as the insn pattern to control how the insn is output. 28230 28231 Defined peephole optimizers are run as assembler code is being output, 28232so the insns they produce are never combined or rearranged in any way. 28233 28234 Here is an example, taken from the 68000 machine description: 28235 28236 (define_peephole 28237 [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) 28238 (set (match_operand:DF 0 "register_operand" "=f") 28239 (match_operand:DF 1 "register_operand" "ad"))] 28240 "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" 28241 { 28242 rtx xoperands[2]; 28243 xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1); 28244 #ifdef MOTOROLA 28245 output_asm_insn ("move.l %1,(sp)", xoperands); 28246 output_asm_insn ("move.l %1,-(sp)", operands); 28247 return "fmove.d (sp)+,%0"; 28248 #else 28249 output_asm_insn ("movel %1,sp@", xoperands); 28250 output_asm_insn ("movel %1,sp@-", operands); 28251 return "fmoved sp@+,%0"; 28252 #endif 28253 }) 28254 28255 The effect of this optimization is to change 28256 28257 jbsr _foobar 28258 addql #4,sp 28259 movel d1,sp@- 28260 movel d0,sp@- 28261 fmoved sp@+,fp0 28262 28263into 28264 28265 jbsr _foobar 28266 movel d1,sp@ 28267 movel d0,sp@- 28268 fmoved sp@+,fp0 28269 28270 INSN-PATTERN-1 and so on look _almost_ like the second operand of 28271'define_insn'. There is one important difference: the second operand of 28272'define_insn' consists of one or more RTX's enclosed in square brackets. 28273Usually, there is only one: then the same action can be written as an 28274element of a 'define_peephole'. But when there are multiple actions in 28275a 'define_insn', they are implicitly enclosed in a 'parallel'. Then you 28276must explicitly write the 'parallel', and the square brackets within it, 28277in the 'define_peephole'. Thus, if an insn pattern looks like this, 28278 28279 (define_insn "divmodsi4" 28280 [(set (match_operand:SI 0 "general_operand" "=d") 28281 (div:SI (match_operand:SI 1 "general_operand" "0") 28282 (match_operand:SI 2 "general_operand" "dmsK"))) 28283 (set (match_operand:SI 3 "general_operand" "=d") 28284 (mod:SI (match_dup 1) (match_dup 2)))] 28285 "TARGET_68020" 28286 "divsl%.l %2,%3:%0") 28287 28288then the way to mention this insn in a peephole is as follows: 28289 28290 (define_peephole 28291 [... 28292 (parallel 28293 [(set (match_operand:SI 0 "general_operand" "=d") 28294 (div:SI (match_operand:SI 1 "general_operand" "0") 28295 (match_operand:SI 2 "general_operand" "dmsK"))) 28296 (set (match_operand:SI 3 "general_operand" "=d") 28297 (mod:SI (match_dup 1) (match_dup 2)))]) 28298 ...] 28299 ...) 28300 28301 28302File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions 28303 2830417.18.2 RTL to RTL Peephole Optimizers 28305-------------------------------------- 28306 28307The 'define_peephole2' definition tells the compiler how to substitute 28308one sequence of instructions for another sequence, what additional 28309scratch registers may be needed and what their lifetimes must be. 28310 28311 (define_peephole2 28312 [INSN-PATTERN-1 28313 INSN-PATTERN-2 28314 ...] 28315 "CONDITION" 28316 [NEW-INSN-PATTERN-1 28317 NEW-INSN-PATTERN-2 28318 ...] 28319 "PREPARATION-STATEMENTS") 28320 28321 The definition is almost identical to 'define_split' (*note Insn 28322Splitting::) except that the pattern to match is not a single 28323instruction, but a sequence of instructions. 28324 28325 It is possible to request additional scratch registers for use in the 28326output template. If appropriate registers are not free, the pattern 28327will simply not match. 28328 28329 Scratch registers are requested with a 'match_scratch' pattern at the 28330top level of the input pattern. The allocated register (initially) will 28331be dead at the point requested within the original sequence. If the 28332scratch is used at more than a single point, a 'match_dup' pattern at 28333the top level of the input pattern marks the last position in the input 28334sequence at which the register must be available. 28335 28336 Here is an example from the IA-32 machine description: 28337 28338 (define_peephole2 28339 [(match_scratch:SI 2 "r") 28340 (parallel [(set (match_operand:SI 0 "register_operand" "") 28341 (match_operator:SI 3 "arith_or_logical_operator" 28342 [(match_dup 0) 28343 (match_operand:SI 1 "memory_operand" "")])) 28344 (clobber (reg:CC 17))])] 28345 "! optimize_size && ! TARGET_READ_MODIFY" 28346 [(set (match_dup 2) (match_dup 1)) 28347 (parallel [(set (match_dup 0) 28348 (match_op_dup 3 [(match_dup 0) (match_dup 2)])) 28349 (clobber (reg:CC 17))])] 28350 "") 28351 28352This pattern tries to split a load from its use in the hopes that we'll 28353be able to schedule around the memory load latency. It allocates a 28354single 'SImode' register of class 'GENERAL_REGS' ('"r"') that needs to 28355be live only at the point just before the arithmetic. 28356 28357 A real example requiring extended scratch lifetimes is harder to come 28358by, so here's a silly made-up example: 28359 28360 (define_peephole2 28361 [(match_scratch:SI 4 "r") 28362 (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" "")) 28363 (set (match_operand:SI 2 "" "") (match_dup 1)) 28364 (match_dup 4) 28365 (set (match_operand:SI 3 "" "") (match_dup 1))] 28366 "/* determine 1 does not overlap 0 and 2 */" 28367 [(set (match_dup 4) (match_dup 1)) 28368 (set (match_dup 0) (match_dup 4)) 28369 (set (match_dup 2) (match_dup 4)) 28370 (set (match_dup 3) (match_dup 4))] 28371 "") 28372 28373 There are two special macros defined for use in the preparation 28374statements: 'DONE' and 'FAIL'. Use them with a following semicolon, as 28375a statement. 28376 28377'DONE' 28378 Use the 'DONE' macro to end RTL generation for the peephole. The 28379 only RTL insns generated as replacement for the matched input insn 28380 will be those already emitted by explicit calls to 'emit_insn' 28381 within the preparation statements; the replacement pattern is not 28382 used. 28383 28384'FAIL' 28385 Make the 'define_peephole2' fail on this occasion. When a 28386 'define_peephole2' fails, it means that the replacement was not 28387 truly available for the particular inputs it was given. In that 28388 case, GCC may still apply a later 'define_peephole2' that also 28389 matches the given insn pattern. (Note that this is different from 28390 'define_split', where 'FAIL' prevents the input insn from being 28391 split at all.) 28392 28393 If the preparation falls through (invokes neither 'DONE' nor 'FAIL'), 28394then the 'define_peephole2' uses the replacement template. 28395 28396If we had not added the '(match_dup 4)' in the middle of the input 28397sequence, it might have been the case that the register we chose at the 28398beginning of the sequence is killed by the first or second 'set'. 28399 28400 28401File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc 28402 2840317.19 Instruction Attributes 28404============================ 28405 28406In addition to describing the instruction supported by the target 28407machine, the 'md' file also defines a group of "attributes" and a set of 28408values for each. Every generated insn is assigned a value for each 28409attribute. One possible attribute would be the effect that the insn has 28410on the machine's condition code. This attribute can then be used by 28411'NOTICE_UPDATE_CC' to track the condition codes. 28412 28413* Menu: 28414 28415* Defining Attributes:: Specifying attributes and their values. 28416* Expressions:: Valid expressions for attribute values. 28417* Tagging Insns:: Assigning attribute values to insns. 28418* Attr Example:: An example of assigning attributes. 28419* Insn Lengths:: Computing the length of insns. 28420* Constant Attributes:: Defining attributes that are constant. 28421* Mnemonic Attribute:: Obtain the instruction mnemonic as attribute value. 28422* Delay Slots:: Defining delay slots required for a machine. 28423* Processor pipeline description:: Specifying information for insn scheduling. 28424 28425 28426File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes 28427 2842817.19.1 Defining Attributes and their Values 28429-------------------------------------------- 28430 28431The 'define_attr' expression is used to define each attribute required 28432by the target machine. It looks like: 28433 28434 (define_attr NAME LIST-OF-VALUES DEFAULT) 28435 28436 NAME is a string specifying the name of the attribute being defined. 28437Some attributes are used in a special way by the rest of the compiler. 28438The 'enabled' attribute can be used to conditionally enable or disable 28439insn alternatives (*note Disable Insn Alternatives::). The 'predicable' 28440attribute, together with a suitable 'define_cond_exec' (*note 28441Conditional Execution::), can be used to automatically generate 28442conditional variants of instruction patterns. The 'mnemonic' attribute 28443can be used to check for the instruction mnemonic (*note Mnemonic 28444Attribute::). The compiler internally uses the names 'ce_enabled' and 28445'nonce_enabled', so they should not be used elsewhere as alternative 28446names. 28447 28448 LIST-OF-VALUES is either a string that specifies a comma-separated list 28449of values that can be assigned to the attribute, or a null string to 28450indicate that the attribute takes numeric values. 28451 28452 DEFAULT is an attribute expression that gives the value of this 28453attribute for insns that match patterns whose definition does not 28454include an explicit value for this attribute. *Note Attr Example::, for 28455more information on the handling of defaults. *Note Constant 28456Attributes::, for information on attributes that do not depend on any 28457particular insn. 28458 28459 For each defined attribute, a number of definitions are written to the 28460'insn-attr.h' file. For cases where an explicit set of values is 28461specified for an attribute, the following are defined: 28462 28463 * A '#define' is written for the symbol 'HAVE_ATTR_NAME'. 28464 28465 * An enumerated class is defined for 'attr_NAME' with elements of the 28466 form 'UPPER-NAME_UPPER-VALUE' where the attribute name and value 28467 are first converted to uppercase. 28468 28469 * A function 'get_attr_NAME' is defined that is passed an insn and 28470 returns the attribute value for that insn. 28471 28472 For example, if the following is present in the 'md' file: 28473 28474 (define_attr "type" "branch,fp,load,store,arith" ...) 28475 28476the following lines will be written to the file 'insn-attr.h'. 28477 28478 #define HAVE_ATTR_type 1 28479 enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, 28480 TYPE_STORE, TYPE_ARITH}; 28481 extern enum attr_type get_attr_type (); 28482 28483 If the attribute takes numeric values, no 'enum' type will be defined 28484and the function to obtain the attribute's value will return 'int'. 28485 28486 There are attributes which are tied to a specific meaning. These 28487attributes are not free to use for other purposes: 28488 28489'length' 28490 The 'length' attribute is used to calculate the length of emitted 28491 code chunks. This is especially important when verifying branch 28492 distances. *Note Insn Lengths::. 28493 28494'enabled' 28495 The 'enabled' attribute can be defined to prevent certain 28496 alternatives of an insn definition from being used during code 28497 generation. *Note Disable Insn Alternatives::. 28498 28499'mnemonic' 28500 The 'mnemonic' attribute can be defined to implement instruction 28501 specific checks in e.g. the pipeline description. *Note Mnemonic 28502 Attribute::. 28503 28504 For each of these special attributes, the corresponding 28505'HAVE_ATTR_NAME' '#define' is also written when the attribute is not 28506defined; in that case, it is defined as '0'. 28507 28508 Another way of defining an attribute is to use: 28509 28510 (define_enum_attr "ATTR" "ENUM" DEFAULT) 28511 28512 This works in just the same way as 'define_attr', except that the list 28513of values is taken from a separate enumeration called ENUM (*note 28514define_enum::). This form allows you to use the same list of values for 28515several attributes without having to repeat the list each time. For 28516example: 28517 28518 (define_enum "processor" [ 28519 model_a 28520 model_b 28521 ... 28522 ]) 28523 (define_enum_attr "arch" "processor" 28524 (const (symbol_ref "target_arch"))) 28525 (define_enum_attr "tune" "processor" 28526 (const (symbol_ref "target_tune"))) 28527 28528 defines the same attributes as: 28529 28530 (define_attr "arch" "model_a,model_b,..." 28531 (const (symbol_ref "target_arch"))) 28532 (define_attr "tune" "model_a,model_b,..." 28533 (const (symbol_ref "target_tune"))) 28534 28535 but without duplicating the processor list. The second example defines 28536two separate C enums ('attr_arch' and 'attr_tune') whereas the first 28537defines a single C enum ('processor'). 28538 28539 28540File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes 28541 2854217.19.2 Attribute Expressions 28543----------------------------- 28544 28545RTL expressions used to define attributes use the codes described above 28546plus a few specific to attribute definitions, to be discussed below. 28547Attribute value expressions must have one of the following forms: 28548 28549'(const_int I)' 28550 The integer I specifies the value of a numeric attribute. I must 28551 be non-negative. 28552 28553 The value of a numeric attribute can be specified either with a 28554 'const_int', or as an integer represented as a string in 28555 'const_string', 'eq_attr' (see below), 'attr', 'symbol_ref', simple 28556 arithmetic expressions, and 'set_attr' overrides on specific 28557 instructions (*note Tagging Insns::). 28558 28559'(const_string VALUE)' 28560 The string VALUE specifies a constant attribute value. If VALUE is 28561 specified as '"*"', it means that the default value of the 28562 attribute is to be used for the insn containing this expression. 28563 '"*"' obviously cannot be used in the DEFAULT expression of a 28564 'define_attr'. 28565 28566 If the attribute whose value is being specified is numeric, VALUE 28567 must be a string containing a non-negative integer (normally 28568 'const_int' would be used in this case). Otherwise, it must 28569 contain one of the valid values for the attribute. 28570 28571'(if_then_else TEST TRUE-VALUE FALSE-VALUE)' 28572 TEST specifies an attribute test, whose format is defined below. 28573 The value of this expression is TRUE-VALUE if TEST is true, 28574 otherwise it is FALSE-VALUE. 28575 28576'(cond [TEST1 VALUE1 ...] DEFAULT)' 28577 The first operand of this expression is a vector containing an even 28578 number of expressions and consisting of pairs of TEST and VALUE 28579 expressions. The value of the 'cond' expression is that of the 28580 VALUE corresponding to the first true TEST expression. If none of 28581 the TEST expressions are true, the value of the 'cond' expression 28582 is that of the DEFAULT expression. 28583 28584 TEST expressions can have one of the following forms: 28585 28586'(const_int I)' 28587 This test is true if I is nonzero and false otherwise. 28588 28589'(not TEST)' 28590'(ior TEST1 TEST2)' 28591'(and TEST1 TEST2)' 28592 These tests are true if the indicated logical function is true. 28593 28594'(match_operand:M N PRED CONSTRAINTS)' 28595 This test is true if operand N of the insn whose attribute value is 28596 being determined has mode M (this part of the test is ignored if M 28597 is 'VOIDmode') and the function specified by the string PRED 28598 returns a nonzero value when passed operand N and mode M (this part 28599 of the test is ignored if PRED is the null string). 28600 28601 The CONSTRAINTS operand is ignored and should be the null string. 28602 28603'(match_test C-EXPR)' 28604 The test is true if C expression C-EXPR is true. In non-constant 28605 attributes, C-EXPR has access to the following variables: 28606 28607 INSN 28608 The rtl instruction under test. 28609 WHICH_ALTERNATIVE 28610 The 'define_insn' alternative that INSN matches. *Note Output 28611 Statement::. 28612 OPERANDS 28613 An array of INSN's rtl operands. 28614 28615 C-EXPR behaves like the condition in a C 'if' statement, so there 28616 is no need to explicitly convert the expression into a boolean 0 or 28617 1 value. For example, the following two tests are equivalent: 28618 28619 (match_test "x & 2") 28620 (match_test "(x & 2) != 0") 28621 28622'(le ARITH1 ARITH2)' 28623'(leu ARITH1 ARITH2)' 28624'(lt ARITH1 ARITH2)' 28625'(ltu ARITH1 ARITH2)' 28626'(gt ARITH1 ARITH2)' 28627'(gtu ARITH1 ARITH2)' 28628'(ge ARITH1 ARITH2)' 28629'(geu ARITH1 ARITH2)' 28630'(ne ARITH1 ARITH2)' 28631'(eq ARITH1 ARITH2)' 28632 These tests are true if the indicated comparison of the two 28633 arithmetic expressions is true. Arithmetic expressions are formed 28634 with 'plus', 'minus', 'mult', 'div', 'mod', 'abs', 'neg', 'and', 28635 'ior', 'xor', 'not', 'ashift', 'lshiftrt', and 'ashiftrt' 28636 expressions. 28637 28638 'const_int' and 'symbol_ref' are always valid terms (*note Insn 28639 Lengths::,for additional forms). 'symbol_ref' is a string denoting 28640 a C expression that yields an 'int' when evaluated by the 28641 'get_attr_...' routine. It should normally be a global variable. 28642 28643'(eq_attr NAME VALUE)' 28644 NAME is a string specifying the name of an attribute. 28645 28646 VALUE is a string that is either a valid value for attribute NAME, 28647 a comma-separated list of values, or '!' followed by a value or 28648 list. If VALUE does not begin with a '!', this test is true if the 28649 value of the NAME attribute of the current insn is in the list 28650 specified by VALUE. If VALUE begins with a '!', this test is true 28651 if the attribute's value is _not_ in the specified list. 28652 28653 For example, 28654 28655 (eq_attr "type" "load,store") 28656 28657 is equivalent to 28658 28659 (ior (eq_attr "type" "load") (eq_attr "type" "store")) 28660 28661 If NAME specifies an attribute of 'alternative', it refers to the 28662 value of the compiler variable 'which_alternative' (*note Output 28663 Statement::) and the values must be small integers. For example, 28664 28665 (eq_attr "alternative" "2,3") 28666 28667 is equivalent to 28668 28669 (ior (eq (symbol_ref "which_alternative") (const_int 2)) 28670 (eq (symbol_ref "which_alternative") (const_int 3))) 28671 28672 Note that, for most attributes, an 'eq_attr' test is simplified in 28673 cases where the value of the attribute being tested is known for 28674 all insns matching a particular pattern. This is by far the most 28675 common case. 28676 28677'(attr_flag NAME)' 28678 The value of an 'attr_flag' expression is true if the flag 28679 specified by NAME is true for the 'insn' currently being scheduled. 28680 28681 NAME is a string specifying one of a fixed set of flags to test. 28682 Test the flags 'forward' and 'backward' to determine the direction 28683 of a conditional branch. 28684 28685 This example describes a conditional branch delay slot which can be 28686 nullified for forward branches that are taken (annul-true) or for 28687 backward branches which are not taken (annul-false). 28688 28689 (define_delay (eq_attr "type" "cbranch") 28690 [(eq_attr "in_branch_delay" "true") 28691 (and (eq_attr "in_branch_delay" "true") 28692 (attr_flag "forward")) 28693 (and (eq_attr "in_branch_delay" "true") 28694 (attr_flag "backward"))]) 28695 28696 The 'forward' and 'backward' flags are false if the current 'insn' 28697 being scheduled is not a conditional branch. 28698 28699 'attr_flag' is only used during delay slot scheduling and has no 28700 meaning to other passes of the compiler. 28701 28702'(attr NAME)' 28703 The value of another attribute is returned. This is most useful 28704 for numeric attributes, as 'eq_attr' and 'attr_flag' produce more 28705 efficient code for non-numeric attributes. 28706 28707 28708File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes 28709 2871017.19.3 Assigning Attribute Values to Insns 28711------------------------------------------- 28712 28713The value assigned to an attribute of an insn is primarily determined by 28714which pattern is matched by that insn (or which 'define_peephole' 28715generated it). Every 'define_insn' and 'define_peephole' can have an 28716optional last argument to specify the values of attributes for matching 28717insns. The value of any attribute not specified in a particular insn is 28718set to the default value for that attribute, as specified in its 28719'define_attr'. Extensive use of default values for attributes permits 28720the specification of the values for only one or two attributes in the 28721definition of most insn patterns, as seen in the example in the next 28722section. 28723 28724 The optional last argument of 'define_insn' and 'define_peephole' is a 28725vector of expressions, each of which defines the value for a single 28726attribute. The most general way of assigning an attribute's value is to 28727use a 'set' expression whose first operand is an 'attr' expression 28728giving the name of the attribute being set. The second operand of the 28729'set' is an attribute expression (*note Expressions::) giving the value 28730of the attribute. 28731 28732 When the attribute value depends on the 'alternative' attribute (i.e., 28733which is the applicable alternative in the constraint of the insn), the 28734'set_attr_alternative' expression can be used. It allows the 28735specification of a vector of attribute expressions, one for each 28736alternative. 28737 28738 When the generality of arbitrary attribute expressions is not required, 28739the simpler 'set_attr' expression can be used, which allows specifying a 28740string giving either a single attribute value or a list of attribute 28741values, one for each alternative. 28742 28743 The form of each of the above specifications is shown below. In each 28744case, NAME is a string specifying the attribute to be set. 28745 28746'(set_attr NAME VALUE-STRING)' 28747 VALUE-STRING is either a string giving the desired attribute value, 28748 or a string containing a comma-separated list giving the values for 28749 succeeding alternatives. The number of elements must match the 28750 number of alternatives in the constraint of the insn pattern. 28751 28752 Note that it may be useful to specify '*' for some alternative, in 28753 which case the attribute will assume its default value for insns 28754 matching that alternative. 28755 28756'(set_attr_alternative NAME [VALUE1 VALUE2 ...])' 28757 Depending on the alternative of the insn, the value will be one of 28758 the specified values. This is a shorthand for using a 'cond' with 28759 tests on the 'alternative' attribute. 28760 28761'(set (attr NAME) VALUE)' 28762 The first operand of this 'set' must be the special RTL expression 28763 'attr', whose sole operand is a string giving the name of the 28764 attribute being set. VALUE is the value of the attribute. 28765 28766 The following shows three different ways of representing the same 28767attribute value specification: 28768 28769 (set_attr "type" "load,store,arith") 28770 28771 (set_attr_alternative "type" 28772 [(const_string "load") (const_string "store") 28773 (const_string "arith")]) 28774 28775 (set (attr "type") 28776 (cond [(eq_attr "alternative" "1") (const_string "load") 28777 (eq_attr "alternative" "2") (const_string "store")] 28778 (const_string "arith"))) 28779 28780 The 'define_asm_attributes' expression provides a mechanism to specify 28781the attributes assigned to insns produced from an 'asm' statement. It 28782has the form: 28783 28784 (define_asm_attributes [ATTR-SETS]) 28785 28786where ATTR-SETS is specified the same as for both the 'define_insn' and 28787the 'define_peephole' expressions. 28788 28789 These values will typically be the "worst case" attribute values. For 28790example, they might indicate that the condition code will be clobbered. 28791 28792 A specification for a 'length' attribute is handled specially. The way 28793to compute the length of an 'asm' insn is to multiply the length 28794specified in the expression 'define_asm_attributes' by the number of 28795machine instructions specified in the 'asm' statement, determined by 28796counting the number of semicolons and newlines in the string. 28797Therefore, the value of the 'length' attribute specified in a 28798'define_asm_attributes' should be the maximum possible length of a 28799single machine instruction. 28800 28801 28802File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes 28803 2880417.19.4 Example of Attribute Specifications 28805------------------------------------------- 28806 28807The judicious use of defaulting is important in the efficient use of 28808insn attributes. Typically, insns are divided into "types" and an 28809attribute, customarily called 'type', is used to represent this value. 28810This attribute is normally used only to define the default value for 28811other attributes. An example will clarify this usage. 28812 28813 Assume we have a RISC machine with a condition code and in which only 28814full-word operations are performed in registers. Let us assume that we 28815can divide all insns into loads, stores, (integer) arithmetic 28816operations, floating point operations, and branches. 28817 28818 Here we will concern ourselves with determining the effect of an insn 28819on the condition code and will limit ourselves to the following possible 28820effects: The condition code can be set unpredictably (clobbered), not be 28821changed, be set to agree with the results of the operation, or only 28822changed if the item previously set into the condition code has been 28823modified. 28824 28825 Here is part of a sample 'md' file for such a machine: 28826 28827 (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) 28828 28829 (define_attr "cc" "clobber,unchanged,set,change0" 28830 (cond [(eq_attr "type" "load") 28831 (const_string "change0") 28832 (eq_attr "type" "store,branch") 28833 (const_string "unchanged") 28834 (eq_attr "type" "arith") 28835 (if_then_else (match_operand:SI 0 "" "") 28836 (const_string "set") 28837 (const_string "clobber"))] 28838 (const_string "clobber"))) 28839 28840 (define_insn "" 28841 [(set (match_operand:SI 0 "general_operand" "=r,r,m") 28842 (match_operand:SI 1 "general_operand" "r,m,r"))] 28843 "" 28844 "@ 28845 move %0,%1 28846 load %0,%1 28847 store %0,%1" 28848 [(set_attr "type" "arith,load,store")]) 28849 28850 Note that we assume in the above example that arithmetic operations 28851performed on quantities smaller than a machine word clobber the 28852condition code since they will set the condition code to a value 28853corresponding to the full-word result. 28854 28855 28856File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes 28857 2885817.19.5 Computing the Length of an Insn 28859--------------------------------------- 28860 28861For many machines, multiple types of branch instructions are provided, 28862each for different length branch displacements. In most cases, the 28863assembler will choose the correct instruction to use. However, when the 28864assembler cannot do so, GCC can when a special attribute, the 'length' 28865attribute, is defined. This attribute must be defined to have numeric 28866values by specifying a null string in its 'define_attr'. 28867 28868 In the case of the 'length' attribute, two additional forms of 28869arithmetic terms are allowed in test expressions: 28870 28871'(match_dup N)' 28872 This refers to the address of operand N of the current insn, which 28873 must be a 'label_ref'. 28874 28875'(pc)' 28876 For non-branch instructions and backward branch instructions, this 28877 refers to the address of the current insn. But for forward branch 28878 instructions, this refers to the address of the next insn, because 28879 the length of the current insn is to be computed. 28880 28881 For normal insns, the length will be determined by value of the 28882'length' attribute. In the case of 'addr_vec' and 'addr_diff_vec' insn 28883patterns, the length is computed as the number of vectors multiplied by 28884the size of each vector. 28885 28886 Lengths are measured in addressable storage units (bytes). 28887 28888 Note that it is possible to call functions via the 'symbol_ref' 28889mechanism to compute the length of an insn. However, if you use this 28890mechanism you must provide dummy clauses to express the maximum length 28891without using the function call. You can an example of this in the 'pa' 28892machine description for the 'call_symref' pattern. 28893 28894 The following macros can be used to refine the length computation: 28895 28896'ADJUST_INSN_LENGTH (INSN, LENGTH)' 28897 If defined, modifies the length assigned to instruction INSN as a 28898 function of the context in which it is used. LENGTH is an lvalue 28899 that contains the initially computed length of the insn and should 28900 be updated with the correct length of the insn. 28901 28902 This macro will normally not be required. A case in which it is 28903 required is the ROMP. On this machine, the size of an 'addr_vec' 28904 insn must be increased by two to compensate for the fact that 28905 alignment may be required. 28906 28907 The routine that returns 'get_attr_length' (the value of the 'length' 28908attribute) can be used by the output routine to determine the form of 28909the branch instruction to be written, as the example below illustrates. 28910 28911 As an example of the specification of variable-length branches, 28912consider the IBM 360. If we adopt the convention that a register will 28913be set to the starting address of a function, we can jump to labels 28914within 4k of the start using a four-byte instruction. Otherwise, we 28915need a six-byte sequence to load the address from memory and then branch 28916to it. 28917 28918 On such a machine, a pattern for a branch instruction might be 28919specified as follows: 28920 28921 (define_insn "jump" 28922 [(set (pc) 28923 (label_ref (match_operand 0 "" "")))] 28924 "" 28925 { 28926 return (get_attr_length (insn) == 4 28927 ? "b %l0" : "l r15,=a(%l0); br r15"); 28928 } 28929 [(set (attr "length") 28930 (if_then_else (lt (match_dup 0) (const_int 4096)) 28931 (const_int 4) 28932 (const_int 6)))]) 28933 28934 28935File: gccint.info, Node: Constant Attributes, Next: Mnemonic Attribute, Prev: Insn Lengths, Up: Insn Attributes 28936 2893717.19.6 Constant Attributes 28938--------------------------- 28939 28940A special form of 'define_attr', where the expression for the default 28941value is a 'const' expression, indicates an attribute that is constant 28942for a given run of the compiler. Constant attributes may be used to 28943specify which variety of processor is used. For example, 28944 28945 (define_attr "cpu" "m88100,m88110,m88000" 28946 (const 28947 (cond [(symbol_ref "TARGET_88100") (const_string "m88100") 28948 (symbol_ref "TARGET_88110") (const_string "m88110")] 28949 (const_string "m88000")))) 28950 28951 (define_attr "memory" "fast,slow" 28952 (const 28953 (if_then_else (symbol_ref "TARGET_FAST_MEM") 28954 (const_string "fast") 28955 (const_string "slow")))) 28956 28957 The routine generated for constant attributes has no parameters as it 28958does not depend on any particular insn. RTL expressions used to define 28959the value of a constant attribute may use the 'symbol_ref' form, but may 28960not use either the 'match_operand' form or 'eq_attr' forms involving 28961insn attributes. 28962 28963 28964File: gccint.info, Node: Mnemonic Attribute, Next: Delay Slots, Prev: Constant Attributes, Up: Insn Attributes 28965 2896617.19.7 Mnemonic Attribute 28967-------------------------- 28968 28969The 'mnemonic' attribute is a string type attribute holding the 28970instruction mnemonic for an insn alternative. The attribute values will 28971automatically be generated by the machine description parser if there is 28972an attribute definition in the md file: 28973 28974 (define_attr "mnemonic" "unknown" (const_string "unknown")) 28975 28976 The default value can be freely chosen as long as it does not collide 28977with any of the instruction mnemonics. This value will be used whenever 28978the machine description parser is not able to determine the mnemonic 28979string. This might be the case for output templates containing more 28980than a single instruction as in '"mvcle\t%0,%1,0\;jo\t.-4"'. 28981 28982 The 'mnemonic' attribute set is not generated automatically if the 28983instruction string is generated via C code. 28984 28985 An existing 'mnemonic' attribute set in an insn definition will not be 28986overriden by the md file parser. That way it is possible to manually 28987set the instruction mnemonics for the cases where the md file parser 28988fails to determine it automatically. 28989 28990 The 'mnemonic' attribute is useful for dealing with instruction 28991specific properties in the pipeline description without defining 28992additional insn attributes. 28993 28994 (define_attr "ooo_expanded" "" 28995 (cond [(eq_attr "mnemonic" "dlr,dsgr,d,dsgf,stam,dsgfr,dlgr") 28996 (const_int 1)] 28997 (const_int 0))) 28998 28999 29000File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Mnemonic Attribute, Up: Insn Attributes 29001 2900217.19.8 Delay Slot Scheduling 29003----------------------------- 29004 29005The insn attribute mechanism can be used to specify the requirements for 29006delay slots, if any, on a target machine. An instruction is said to 29007require a "delay slot" if some instructions that are physically after 29008the instruction are executed as if they were located before it. Classic 29009examples are branch and call instructions, which often execute the 29010following instruction before the branch or call is performed. 29011 29012 On some machines, conditional branch instructions can optionally 29013"annul" instructions in the delay slot. This means that the instruction 29014will not be executed for certain branch outcomes. Both instructions 29015that annul if the branch is true and instructions that annul if the 29016branch is false are supported. 29017 29018 Delay slot scheduling differs from instruction scheduling in that 29019determining whether an instruction needs a delay slot is dependent only 29020on the type of instruction being generated, not on data flow between the 29021instructions. See the next section for a discussion of data-dependent 29022instruction scheduling. 29023 29024 The requirement of an insn needing one or more delay slots is indicated 29025via the 'define_delay' expression. It has the following form: 29026 29027 (define_delay TEST 29028 [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 29029 DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 29030 ...]) 29031 29032 TEST is an attribute test that indicates whether this 'define_delay' 29033applies to a particular insn. If so, the number of required delay slots 29034is determined by the length of the vector specified as the second 29035argument. An insn placed in delay slot N must satisfy attribute test 29036DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns 29037may be annulled if the branch is true. Similarly, ANNUL-FALSE-N 29038specifies which insns in the delay slot may be annulled if the branch is 29039false. If annulling is not supported for that delay slot, '(nil)' 29040should be coded. 29041 29042 For example, in the common case where branch and call insns require a 29043single delay slot, which may contain any insn other than a branch or 29044call, the following would be placed in the 'md' file: 29045 29046 (define_delay (eq_attr "type" "branch,call") 29047 [(eq_attr "type" "!branch,call") (nil) (nil)]) 29048 29049 Multiple 'define_delay' expressions may be specified. In this case, 29050each such expression specifies different delay slot requirements and 29051there must be no insn for which tests in two 'define_delay' expressions 29052are both true. 29053 29054 For example, if we have a machine that requires one delay slot for 29055branches but two for calls, no delay slot can contain a branch or call 29056insn, and any valid insn in the delay slot for the branch can be 29057annulled if the branch is true, we might represent this as follows: 29058 29059 (define_delay (eq_attr "type" "branch") 29060 [(eq_attr "type" "!branch,call") 29061 (eq_attr "type" "!branch,call") 29062 (nil)]) 29063 29064 (define_delay (eq_attr "type" "call") 29065 [(eq_attr "type" "!branch,call") (nil) (nil) 29066 (eq_attr "type" "!branch,call") (nil) (nil)]) 29067 29068 29069File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes 29070 2907117.19.9 Specifying processor pipeline description 29072------------------------------------------------- 29073 29074To achieve better performance, most modern processors (super-pipelined, 29075superscalar RISC, and VLIW processors) have many "functional units" on 29076which several instructions can be executed simultaneously. An 29077instruction starts execution if its issue conditions are satisfied. If 29078not, the instruction is stalled until its conditions are satisfied. 29079Such "interlock (pipeline) delay" causes interruption of the fetching of 29080successor instructions (or demands nop instructions, e.g. for some MIPS 29081processors). 29082 29083 There are two major kinds of interlock delays in modern processors. 29084The first one is a data dependence delay determining "instruction 29085latency time". The instruction execution is not started until all 29086source data have been evaluated by prior instructions (there are more 29087complex cases when the instruction execution starts even when the data 29088are not available but will be ready in given time after the instruction 29089execution start). Taking the data dependence delays into account is 29090simple. The data dependence (true, output, and anti-dependence) delay 29091between two instructions is given by a constant. In most cases this 29092approach is adequate. The second kind of interlock delays is a 29093reservation delay. The reservation delay means that two instructions 29094under execution will be in need of shared processors resources, i.e. 29095buses, internal registers, and/or functional units, which are reserved 29096for some time. Taking this kind of delay into account is complex 29097especially for modern RISC processors. 29098 29099 The task of exploiting more processor parallelism is solved by an 29100instruction scheduler. For a better solution to this problem, the 29101instruction scheduler has to have an adequate description of the 29102processor parallelism (or "pipeline description"). GCC machine 29103descriptions describe processor parallelism and functional unit 29104reservations for groups of instructions with the aid of "regular 29105expressions". 29106 29107 The GCC instruction scheduler uses a "pipeline hazard recognizer" to 29108figure out the possibility of the instruction issue by the processor on 29109a given simulated processor cycle. The pipeline hazard recognizer is 29110automatically generated from the processor pipeline description. The 29111pipeline hazard recognizer generated from the machine description is 29112based on a deterministic finite state automaton (DFA): the instruction 29113issue is possible if there is a transition from one automaton state to 29114another one. This algorithm is very fast, and furthermore, its speed is 29115not dependent on processor complexity(1). 29116 29117 The rest of this section describes the directives that constitute an 29118automaton-based processor pipeline description. The order of these 29119constructions within the machine description file is not important. 29120 29121 The following optional construction describes names of automata 29122generated and used for the pipeline hazards recognition. Sometimes the 29123generated finite state automaton used by the pipeline hazard recognizer 29124is large. If we use more than one automaton and bind functional units 29125to the automata, the total size of the automata is usually less than the 29126size of the single automaton. If there is no one such construction, 29127only one finite state automaton is generated. 29128 29129 (define_automaton AUTOMATA-NAMES) 29130 29131 AUTOMATA-NAMES is a string giving names of the automata. The names are 29132separated by commas. All the automata should have unique names. The 29133automaton name is used in the constructions 'define_cpu_unit' and 29134'define_query_cpu_unit'. 29135 29136 Each processor functional unit used in the description of instruction 29137reservations should be described by the following construction. 29138 29139 (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 29140 29141 UNIT-NAMES is a string giving the names of the functional units 29142separated by commas. Don't use name 'nothing', it is reserved for other 29143goals. 29144 29145 AUTOMATON-NAME is a string giving the name of the automaton with which 29146the unit is bound. The automaton should be described in construction 29147'define_automaton'. You should give "automaton-name", if there is a 29148defined automaton. 29149 29150 The assignment of units to automata are constrained by the uses of the 29151units in insn reservations. The most important constraint is: if a unit 29152reservation is present on a particular cycle of an alternative for an 29153insn reservation, then some unit from the same automaton must be present 29154on the same cycle for the other alternatives of the insn reservation. 29155The rest of the constraints are mentioned in the description of the 29156subsequent constructions. 29157 29158 The following construction describes CPU functional units analogously 29159to 'define_cpu_unit'. The reservation of such units can be queried for 29160an automaton state. The instruction scheduler never queries reservation 29161of functional units for given automaton state. So as a rule, you don't 29162need this construction. This construction could be used for future code 29163generation goals (e.g. to generate VLIW insn templates). 29164 29165 (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 29166 29167 UNIT-NAMES is a string giving names of the functional units separated 29168by commas. 29169 29170 AUTOMATON-NAME is a string giving the name of the automaton with which 29171the unit is bound. 29172 29173 The following construction is the major one to describe pipeline 29174characteristics of an instruction. 29175 29176 (define_insn_reservation INSN-NAME DEFAULT_LATENCY 29177 CONDITION REGEXP) 29178 29179 DEFAULT_LATENCY is a number giving latency time of the instruction. 29180There is an important difference between the old description and the 29181automaton based pipeline description. The latency time is used for all 29182dependencies when we use the old description. In the automaton based 29183pipeline description, the given latency time is only used for true 29184dependencies. The cost of anti-dependencies is always zero and the cost 29185of output dependencies is the difference between latency times of the 29186producing and consuming insns (if the difference is negative, the cost 29187is considered to be zero). You can always change the default costs for 29188any description by using the target hook 'TARGET_SCHED_ADJUST_COST' 29189(*note Scheduling::). 29190 29191 INSN-NAME is a string giving the internal name of the insn. The 29192internal names are used in constructions 'define_bypass' and in the 29193automaton description file generated for debugging. The internal name 29194has nothing in common with the names in 'define_insn'. It is a good 29195practice to use insn classes described in the processor manual. 29196 29197 CONDITION defines what RTL insns are described by this construction. 29198You should remember that you will be in trouble if CONDITION for two or 29199more different 'define_insn_reservation' constructions is TRUE for an 29200insn. In this case what reservation will be used for the insn is not 29201defined. Such cases are not checked during generation of the pipeline 29202hazards recognizer because in general recognizing that two conditions 29203may have the same value is quite difficult (especially if the conditions 29204contain 'symbol_ref'). It is also not checked during the pipeline 29205hazard recognizer work because it would slow down the recognizer 29206considerably. 29207 29208 REGEXP is a string describing the reservation of the cpu's functional 29209units by the instruction. The reservations are described by a regular 29210expression according to the following syntax: 29211 29212 regexp = regexp "," oneof 29213 | oneof 29214 29215 oneof = oneof "|" allof 29216 | allof 29217 29218 allof = allof "+" repeat 29219 | repeat 29220 29221 repeat = element "*" number 29222 | element 29223 29224 element = cpu_function_unit_name 29225 | reservation_name 29226 | result_name 29227 | "nothing" 29228 | "(" regexp ")" 29229 29230 * ',' is used for describing the start of the next cycle in the 29231 reservation. 29232 29233 * '|' is used for describing a reservation described by the first 29234 regular expression *or* a reservation described by the second 29235 regular expression *or* etc. 29236 29237 * '+' is used for describing a reservation described by the first 29238 regular expression *and* a reservation described by the second 29239 regular expression *and* etc. 29240 29241 * '*' is used for convenience and simply means a sequence in which 29242 the regular expression are repeated NUMBER times with cycle 29243 advancing (see ','). 29244 29245 * 'cpu_function_unit_name' denotes reservation of the named 29246 functional unit. 29247 29248 * 'reservation_name' -- see description of construction 29249 'define_reservation'. 29250 29251 * 'nothing' denotes no unit reservations. 29252 29253 Sometimes unit reservations for different insns contain common parts. 29254In such case, you can simplify the pipeline description by describing 29255the common part by the following construction 29256 29257 (define_reservation RESERVATION-NAME REGEXP) 29258 29259 RESERVATION-NAME is a string giving name of REGEXP. Functional unit 29260names and reservation names are in the same name space. So the 29261reservation names should be different from the functional unit names and 29262cannot be the reserved name 'nothing'. 29263 29264 The following construction is used to describe exceptions in the 29265latency time for given instruction pair. This is so called bypasses. 29266 29267 (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES 29268 [GUARD]) 29269 29270 NUMBER defines when the result generated by the instructions given in 29271string OUT_INSN_NAMES will be ready for the instructions given in string 29272IN_INSN_NAMES. Each of these strings is a comma-separated list of 29273filename-style globs and they refer to the names of 29274'define_insn_reservation's. For example: 29275 (define_bypass 1 "cpu1_load_*, cpu1_store_*" "cpu1_load_*") 29276 defines a bypass between instructions that start with 'cpu1_load_' or 29277'cpu1_store_' and those that start with 'cpu1_load_'. 29278 29279 GUARD is an optional string giving the name of a C function which 29280defines an additional guard for the bypass. The function will get the 29281two insns as parameters. If the function returns zero the bypass will 29282be ignored for this case. The additional guard is necessary to 29283recognize complicated bypasses, e.g. when the consumer is only an 29284address of insn 'store' (not a stored value). 29285 29286 If there are more one bypass with the same output and input insns, the 29287chosen bypass is the first bypass with a guard in description whose 29288guard function returns nonzero. If there is no such bypass, then bypass 29289without the guard function is chosen. 29290 29291 The following five constructions are usually used to describe VLIW 29292processors, or more precisely, to describe a placement of small 29293instructions into VLIW instruction slots. They can be used for RISC 29294processors, too. 29295 29296 (exclusion_set UNIT-NAMES UNIT-NAMES) 29297 (presence_set UNIT-NAMES PATTERNS) 29298 (final_presence_set UNIT-NAMES PATTERNS) 29299 (absence_set UNIT-NAMES PATTERNS) 29300 (final_absence_set UNIT-NAMES PATTERNS) 29301 29302 UNIT-NAMES is a string giving names of functional units separated by 29303commas. 29304 29305 PATTERNS is a string giving patterns of functional units separated by 29306comma. Currently pattern is one unit or units separated by 29307white-spaces. 29308 29309 The first construction ('exclusion_set') means that each functional 29310unit in the first string cannot be reserved simultaneously with a unit 29311whose name is in the second string and vice versa. For example, the 29312construction is useful for describing processors (e.g. some SPARC 29313processors) with a fully pipelined floating point functional unit which 29314can execute simultaneously only single floating point insns or only 29315double floating point insns. 29316 29317 The second construction ('presence_set') means that each functional 29318unit in the first string cannot be reserved unless at least one of 29319pattern of units whose names are in the second string is reserved. This 29320is an asymmetric relation. For example, it is useful for description 29321that VLIW 'slot1' is reserved after 'slot0' reservation. We could 29322describe it by the following construction 29323 29324 (presence_set "slot1" "slot0") 29325 29326 Or 'slot1' is reserved only after 'slot0' and unit 'b0' reservation. 29327In this case we could write 29328 29329 (presence_set "slot1" "slot0 b0") 29330 29331 The third construction ('final_presence_set') is analogous to 29332'presence_set'. The difference between them is when checking is done. 29333When an instruction is issued in given automaton state reflecting all 29334current and planned unit reservations, the automaton state is changed. 29335The first state is a source state, the second one is a result state. 29336Checking for 'presence_set' is done on the source state reservation, 29337checking for 'final_presence_set' is done on the result reservation. 29338This construction is useful to describe a reservation which is actually 29339two subsequent reservations. For example, if we use 29340 29341 (presence_set "slot1" "slot0") 29342 29343 the following insn will be never issued (because 'slot1' requires 29344'slot0' which is absent in the source state). 29345 29346 (define_reservation "insn_and_nop" "slot0 + slot1") 29347 29348 but it can be issued if we use analogous 'final_presence_set'. 29349 29350 The forth construction ('absence_set') means that each functional unit 29351in the first string can be reserved only if each pattern of units whose 29352names are in the second string is not reserved. This is an asymmetric 29353relation (actually 'exclusion_set' is analogous to this one but it is 29354symmetric). For example it might be useful in a VLIW description to say 29355that 'slot0' cannot be reserved after either 'slot1' or 'slot2' have 29356been reserved. This can be described as: 29357 29358 (absence_set "slot0" "slot1, slot2") 29359 29360 Or 'slot2' cannot be reserved if 'slot0' and unit 'b0' are reserved or 29361'slot1' and unit 'b1' are reserved. In this case we could write 29362 29363 (absence_set "slot2" "slot0 b0, slot1 b1") 29364 29365 All functional units mentioned in a set should belong to the same 29366automaton. 29367 29368 The last construction ('final_absence_set') is analogous to 29369'absence_set' but checking is done on the result (state) reservation. 29370See comments for 'final_presence_set'. 29371 29372 You can control the generator of the pipeline hazard recognizer with 29373the following construction. 29374 29375 (automata_option OPTIONS) 29376 29377 OPTIONS is a string giving options which affect the generated code. 29378Currently there are the following options: 29379 29380 * "no-minimization" makes no minimization of the automaton. This is 29381 only worth to do when we are debugging the description and need to 29382 look more accurately at reservations of states. 29383 29384 * "time" means printing time statistics about the generation of 29385 automata. 29386 29387 * "stats" means printing statistics about the generated automata such 29388 as the number of DFA states, NDFA states and arcs. 29389 29390 * "v" means a generation of the file describing the result automata. 29391 The file has suffix '.dfa' and can be used for the description 29392 verification and debugging. 29393 29394 * "w" means a generation of warning instead of error for non-critical 29395 errors. 29396 29397 * "no-comb-vect" prevents the automaton generator from generating two 29398 data structures and comparing them for space efficiency. Using a 29399 comb vector to represent transitions may be better, but it can be 29400 very expensive to construct. This option is useful if the build 29401 process spends an unacceptably long time in genautomata. 29402 29403 * "ndfa" makes nondeterministic finite state automata. This affects 29404 the treatment of operator '|' in the regular expressions. The 29405 usual treatment of the operator is to try the first alternative 29406 and, if the reservation is not possible, the second alternative. 29407 The nondeterministic treatment means trying all alternatives, some 29408 of them may be rejected by reservations in the subsequent insns. 29409 29410 * "collapse-ndfa" modifies the behavior of the generator when 29411 producing an automaton. An additional state transition to collapse 29412 a nondeterministic NDFA state to a deterministic DFA state is 29413 generated. It can be triggered by passing 'const0_rtx' to 29414 state_transition. In such an automaton, cycle advance transitions 29415 are available only for these collapsed states. This option is 29416 useful for ports that want to use the 'ndfa' option, but also want 29417 to use 'define_query_cpu_unit' to assign units to insns issued in a 29418 cycle. 29419 29420 * "progress" means output of a progress bar showing how many states 29421 were generated so far for automaton being processed. This is 29422 useful during debugging a DFA description. If you see too many 29423 generated states, you could interrupt the generator of the pipeline 29424 hazard recognizer and try to figure out a reason for generation of 29425 the huge automaton. 29426 29427 As an example, consider a superscalar RISC machine which can issue 29428three insns (two integer insns and one floating point insn) on the cycle 29429but can finish only two insns. To describe this, we define the 29430following functional units. 29431 29432 (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline") 29433 (define_cpu_unit "port0, port1") 29434 29435 All simple integer insns can be executed in any integer pipeline and 29436their result is ready in two cycles. The simple integer insns are 29437issued into the first pipeline unless it is reserved, otherwise they are 29438issued into the second pipeline. Integer division and multiplication 29439insns can be executed only in the second integer pipeline and their 29440results are ready correspondingly in 9 and 4 cycles. The integer 29441division is not pipelined, i.e. the subsequent integer division insn 29442cannot be issued until the current division insn finished. Floating 29443point insns are fully pipelined and their results are ready in 3 cycles. 29444Where the result of a floating point insn is used by an integer insn, an 29445additional delay of one cycle is incurred. To describe all of this we 29446could specify 29447 29448 (define_cpu_unit "div") 29449 29450 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 29451 "(i0_pipeline | i1_pipeline), (port0 | port1)") 29452 29453 (define_insn_reservation "mult" 4 (eq_attr "type" "mult") 29454 "i1_pipeline, nothing*2, (port0 | port1)") 29455 29456 (define_insn_reservation "div" 9 (eq_attr "type" "div") 29457 "i1_pipeline, div*7, div + (port0 | port1)") 29458 29459 (define_insn_reservation "float" 3 (eq_attr "type" "float") 29460 "f_pipeline, nothing, (port0 | port1)) 29461 29462 (define_bypass 4 "float" "simple,mult,div") 29463 29464 To simplify the description we could describe the following reservation 29465 29466 (define_reservation "finish" "port0|port1") 29467 29468 and use it in all 'define_insn_reservation' as in the following 29469construction 29470 29471 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 29472 "(i0_pipeline | i1_pipeline), finish") 29473 29474 ---------- Footnotes ---------- 29475 29476 (1) However, the size of the automaton depends on processor 29477complexity. To limit this effect, machine descriptions can split 29478orthogonal parts of the machine description among several automata: but 29479then, since each of these must be stepped independently, this does cause 29480a small decrease in the algorithm's performance. 29481 29482 29483File: gccint.info, Node: Conditional Execution, Next: Define Subst, Prev: Insn Attributes, Up: Machine Desc 29484 2948517.20 Conditional Execution 29486=========================== 29487 29488A number of architectures provide for some form of conditional 29489execution, or predication. The hallmark of this feature is the ability 29490to nullify most of the instructions in the instruction set. When the 29491instruction set is large and not entirely symmetric, it can be quite 29492tedious to describe these forms directly in the '.md' file. An 29493alternative is the 'define_cond_exec' template. 29494 29495 (define_cond_exec 29496 [PREDICATE-PATTERN] 29497 "CONDITION" 29498 "OUTPUT-TEMPLATE" 29499 "OPTIONAL-INSN-ATTRIBUES") 29500 29501 PREDICATE-PATTERN is the condition that must be true for the insn to be 29502executed at runtime and should match a relational operator. One can use 29503'match_operator' to match several relational operators at once. Any 29504'match_operand' operands must have no more than one alternative. 29505 29506 CONDITION is a C expression that must be true for the generated pattern 29507to match. 29508 29509 OUTPUT-TEMPLATE is a string similar to the 'define_insn' output 29510template (*note Output Template::), except that the '*' and '@' special 29511cases do not apply. This is only useful if the assembly text for the 29512predicate is a simple prefix to the main insn. In order to handle the 29513general case, there is a global variable 'current_insn_predicate' that 29514will contain the entire predicate if the current insn is predicated, and 29515will otherwise be 'NULL'. 29516 29517 OPTIONAL-INSN-ATTRIBUTES is an optional vector of attributes that gets 29518appended to the insn attributes of the produced cond_exec rtx. It can 29519be used to add some distinguishing attribute to cond_exec rtxs produced 29520that way. An example usage would be to use this attribute in 29521conjunction with attributes on the main pattern to disable particular 29522alternatives under certain conditions. 29523 29524 When 'define_cond_exec' is used, an implicit reference to the 29525'predicable' instruction attribute is made. *Note Insn Attributes::. 29526This attribute must be a boolean (i.e. have exactly two elements in its 29527LIST-OF-VALUES), with the possible values being 'no' and 'yes'. The 29528default and all uses in the insns must be a simple constant, not a 29529complex expressions. It may, however, depend on the alternative, by 29530using a comma-separated list of values. If that is the case, the port 29531should also define an 'enabled' attribute (*note Disable Insn 29532Alternatives::), which should also allow only 'no' and 'yes' as its 29533values. 29534 29535 For each 'define_insn' for which the 'predicable' attribute is true, a 29536new 'define_insn' pattern will be generated that matches a predicated 29537version of the instruction. For example, 29538 29539 (define_insn "addsi" 29540 [(set (match_operand:SI 0 "register_operand" "r") 29541 (plus:SI (match_operand:SI 1 "register_operand" "r") 29542 (match_operand:SI 2 "register_operand" "r")))] 29543 "TEST1" 29544 "add %2,%1,%0") 29545 29546 (define_cond_exec 29547 [(ne (match_operand:CC 0 "register_operand" "c") 29548 (const_int 0))] 29549 "TEST2" 29550 "(%0)") 29551 29552generates a new pattern 29553 29554 (define_insn "" 29555 [(cond_exec 29556 (ne (match_operand:CC 3 "register_operand" "c") (const_int 0)) 29557 (set (match_operand:SI 0 "register_operand" "r") 29558 (plus:SI (match_operand:SI 1 "register_operand" "r") 29559 (match_operand:SI 2 "register_operand" "r"))))] 29560 "(TEST2) && (TEST1)" 29561 "(%3) add %2,%1,%0") 29562 29563 29564File: gccint.info, Node: Define Subst, Next: Constant Definitions, Prev: Conditional Execution, Up: Machine Desc 29565 2956617.21 RTL Templates Transformations 29567=================================== 29568 29569For some hardware architectures there are common cases when the RTL 29570templates for the instructions can be derived from the other RTL 29571templates using simple transformations. E.g., 'i386.md' contains an RTL 29572template for the ordinary 'sub' instruction-- '*subsi_1', and for the 29573'sub' instruction with subsequent zero-extension--'*subsi_1_zext'. Such 29574cases can be easily implemented by a single meta-template capable of 29575generating a modified case based on the initial one: 29576 29577 (define_subst "NAME" 29578 [INPUT-TEMPLATE] 29579 "CONDITION" 29580 [OUTPUT-TEMPLATE]) 29581 INPUT-TEMPLATE is a pattern describing the source RTL template, which 29582will be transformed. 29583 29584 CONDITION is a C expression that is conjunct with the condition from 29585the input-template to generate a condition to be used in the 29586output-template. 29587 29588 OUTPUT-TEMPLATE is a pattern that will be used in the resulting 29589template. 29590 29591 'define_subst' mechanism is tightly coupled with the notion of the 29592subst attribute (*note Subst Iterators::). The use of 'define_subst' is 29593triggered by a reference to a subst attribute in the transforming RTL 29594template. This reference initiates duplication of the source RTL 29595template and substitution of the attributes with their values. The 29596source RTL template is left unchanged, while the copy is transformed by 29597'define_subst'. This transformation can fail in the case when the 29598source RTL template is not matched against the input-template of the 29599'define_subst'. In such case the copy is deleted. 29600 29601 'define_subst' can be used only in 'define_insn' and 'define_expand', 29602it cannot be used in other expressions (e.g. in 29603'define_insn_and_split'). 29604 29605* Menu: 29606 29607* Define Subst Example:: Example of 'define_subst' work. 29608* Define Subst Pattern Matching:: Process of template comparison. 29609* Define Subst Output Template:: Generation of output template. 29610 29611 29612File: gccint.info, Node: Define Subst Example, Next: Define Subst Pattern Matching, Up: Define Subst 29613 2961417.21.1 'define_subst' Example 29615------------------------------ 29616 29617To illustrate how 'define_subst' works, let us examine a simple template 29618transformation. 29619 29620 Suppose there are two kinds of instructions: one that touches flags and 29621the other that does not. The instructions of the second type could be 29622generated with the following 'define_subst': 29623 29624 (define_subst "add_clobber_subst" 29625 [(set (match_operand:SI 0 "" "") 29626 (match_operand:SI 1 "" ""))] 29627 "" 29628 [(set (match_dup 0) 29629 (match_dup 1)) 29630 (clobber (reg:CC FLAGS_REG))] 29631 29632 This 'define_subst' can be applied to any RTL pattern containing 'set' 29633of mode SI and generates a copy with clobber when it is applied. 29634 29635 Assume there is an RTL template for a 'max' instruction to be used in 29636'define_subst' mentioned above: 29637 29638 (define_insn "maxsi" 29639 [(set (match_operand:SI 0 "register_operand" "=r") 29640 (max:SI 29641 (match_operand:SI 1 "register_operand" "r") 29642 (match_operand:SI 2 "register_operand" "r")))] 29643 "" 29644 "max\t{%2, %1, %0|%0, %1, %2}" 29645 [...]) 29646 29647 To mark the RTL template for 'define_subst' application, 29648subst-attributes are used. They should be declared in advance: 29649 29650 (define_subst_attr "add_clobber_name" "add_clobber_subst" "_noclobber" "_clobber") 29651 29652 Here 'add_clobber_name' is the attribute name, 'add_clobber_subst' is 29653the name of the corresponding 'define_subst', the third argument 29654('_noclobber') is the attribute value that would be substituted into the 29655unchanged version of the source RTL template, and the last argument 29656('_clobber') is the value that would be substituted into the second, 29657transformed, version of the RTL template. 29658 29659 Once the subst-attribute has been defined, it should be used in RTL 29660templates which need to be processed by the 'define_subst'. So, the 29661original RTL template should be changed: 29662 29663 (define_insn "maxsi<add_clobber_name>" 29664 [(set (match_operand:SI 0 "register_operand" "=r") 29665 (max:SI 29666 (match_operand:SI 1 "register_operand" "r") 29667 (match_operand:SI 2 "register_operand" "r")))] 29668 "" 29669 "max\t{%2, %1, %0|%0, %1, %2}" 29670 [...]) 29671 29672 The result of the 'define_subst' usage would look like the following: 29673 29674 (define_insn "maxsi_noclobber" 29675 [(set (match_operand:SI 0 "register_operand" "=r") 29676 (max:SI 29677 (match_operand:SI 1 "register_operand" "r") 29678 (match_operand:SI 2 "register_operand" "r")))] 29679 "" 29680 "max\t{%2, %1, %0|%0, %1, %2}" 29681 [...]) 29682 (define_insn "maxsi_clobber" 29683 [(set (match_operand:SI 0 "register_operand" "=r") 29684 (max:SI 29685 (match_operand:SI 1 "register_operand" "r") 29686 (match_operand:SI 2 "register_operand" "r"))) 29687 (clobber (reg:CC FLAGS_REG))] 29688 "" 29689 "max\t{%2, %1, %0|%0, %1, %2}" 29690 [...]) 29691 29692 29693File: gccint.info, Node: Define Subst Pattern Matching, Next: Define Subst Output Template, Prev: Define Subst Example, Up: Define Subst 29694 2969517.21.2 Pattern Matching in 'define_subst' 29696------------------------------------------ 29697 29698All expressions, allowed in 'define_insn' or 'define_expand', are 29699allowed in the input-template of 'define_subst', except 'match_par_dup', 29700'match_scratch', 'match_parallel'. The meanings of expressions in the 29701input-template were changed: 29702 29703 'match_operand' matches any expression (possibly, a subtree in 29704RTL-template), if modes of the 'match_operand' and this expression are 29705the same, or mode of the 'match_operand' is 'VOIDmode', or this 29706expression is 'match_dup', 'match_op_dup'. If the expression is 29707'match_operand' too, and predicate of 'match_operand' from the input 29708pattern is not empty, then the predicates are compared. That can be 29709used for more accurate filtering of accepted RTL-templates. 29710 29711 'match_operator' matches common operators (like 'plus', 'minus'), 29712'unspec', 'unspec_volatile' operators and 'match_operator's from the 29713original pattern if the modes match and 'match_operator' from the input 29714pattern has the same number of operands as the operator from the 29715original pattern. 29716 29717 29718File: gccint.info, Node: Define Subst Output Template, Prev: Define Subst Pattern Matching, Up: Define Subst 29719 2972017.21.3 Generation of output template in 'define_subst' 29721------------------------------------------------------- 29722 29723If all necessary checks for 'define_subst' application pass, a new 29724RTL-pattern, based on the output-template, is created to replace the old 29725template. Like in input-patterns, meanings of some RTL expressions are 29726changed when they are used in output-patterns of a 'define_subst'. 29727Thus, 'match_dup' is used for copying the whole expression from the 29728original pattern, which matched corresponding 'match_operand' from the 29729input pattern. 29730 29731 'match_dup N' is used in the output template to be replaced with the 29732expression from the original pattern, which matched 'match_operand N' 29733from the input pattern. As a consequence, 'match_dup' cannot be used to 29734point to 'match_operand's from the output pattern, it should always 29735refer to a 'match_operand' from the input pattern. If a 'match_dup N' 29736occurs more than once in the output template, its first occurrence is 29737replaced with the expression from the original pattern, and the 29738subsequent expressions are replaced with 'match_dup N', i.e., a 29739reference to the first expression. 29740 29741 In the output template one can refer to the expressions from the 29742original pattern and create new ones. For instance, some operands could 29743be added by means of standard 'match_operand'. 29744 29745 After replacing 'match_dup' with some RTL-subtree from the original 29746pattern, it could happen that several 'match_operand's in the output 29747pattern have the same indexes. It is unknown, how many and what indexes 29748would be used in the expression which would replace 'match_dup', so such 29749conflicts in indexes are inevitable. To overcome this issue, 29750'match_operands' and 'match_operators', which were introduced into the 29751output pattern, are renumerated when all 'match_dup's are replaced. 29752 29753 Number of alternatives in 'match_operand's introduced into the output 29754template 'M' could differ from the number of alternatives in the 29755original pattern 'N', so in the resultant pattern there would be 'N*M' 29756alternatives. Thus, constraints from the original pattern would be 29757duplicated 'N' times, constraints from the output pattern would be 29758duplicated 'M' times, producing all possible combinations. 29759 29760 29761File: gccint.info, Node: Constant Definitions, Next: Iterators, Prev: Define Subst, Up: Machine Desc 29762 2976317.22 Constant Definitions 29764========================== 29765 29766Using literal constants inside instruction patterns reduces legibility 29767and can be a maintenance problem. 29768 29769 To overcome this problem, you may use the 'define_constants' 29770expression. It contains a vector of name-value pairs. From that point 29771on, wherever any of the names appears in the MD file, it is as if the 29772corresponding value had been written instead. You may use 29773'define_constants' multiple times; each appearance adds more constants 29774to the table. It is an error to redefine a constant with a different 29775value. 29776 29777 To come back to the a29k load multiple example, instead of 29778 29779 (define_insn "" 29780 [(match_parallel 0 "load_multiple_operation" 29781 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 29782 (match_operand:SI 2 "memory_operand" "m")) 29783 (use (reg:SI 179)) 29784 (clobber (reg:SI 179))])] 29785 "" 29786 "loadm 0,0,%1,%2") 29787 29788 You could write: 29789 29790 (define_constants [ 29791 (R_BP 177) 29792 (R_FC 178) 29793 (R_CR 179) 29794 (R_Q 180) 29795 ]) 29796 29797 (define_insn "" 29798 [(match_parallel 0 "load_multiple_operation" 29799 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 29800 (match_operand:SI 2 "memory_operand" "m")) 29801 (use (reg:SI R_CR)) 29802 (clobber (reg:SI R_CR))])] 29803 "" 29804 "loadm 0,0,%1,%2") 29805 29806 The constants that are defined with a define_constant are also output 29807in the insn-codes.h header file as #defines. 29808 29809 You can also use the machine description file to define enumerations. 29810Like the constants defined by 'define_constant', these enumerations are 29811visible to both the machine description file and the main C code. 29812 29813 The syntax is as follows: 29814 29815 (define_c_enum "NAME" [ 29816 VALUE0 29817 VALUE1 29818 ... 29819 VALUEN 29820 ]) 29821 29822 This definition causes the equivalent of the following C code to appear 29823in 'insn-constants.h': 29824 29825 enum NAME { 29826 VALUE0 = 0, 29827 VALUE1 = 1, 29828 ... 29829 VALUEN = N 29830 }; 29831 #define NUM_CNAME_VALUES (N + 1) 29832 29833 where CNAME is the capitalized form of NAME. It also makes each VALUEI 29834available in the machine description file, just as if it had been 29835declared with: 29836 29837 (define_constants [(VALUEI I)]) 29838 29839 Each VALUEI is usually an upper-case identifier and usually begins with 29840CNAME. 29841 29842 You can split the enumeration definition into as many statements as you 29843like. The above example is directly equivalent to: 29844 29845 (define_c_enum "NAME" [VALUE0]) 29846 (define_c_enum "NAME" [VALUE1]) 29847 ... 29848 (define_c_enum "NAME" [VALUEN]) 29849 29850 Splitting the enumeration helps to improve the modularity of each 29851individual '.md' file. For example, if a port defines its 29852synchronization instructions in a separate 'sync.md' file, it is 29853convenient to define all synchronization-specific enumeration values in 29854'sync.md' rather than in the main '.md' file. 29855 29856 Some enumeration names have special significance to GCC: 29857 29858'unspecv' 29859 If an enumeration called 'unspecv' is defined, GCC will use it when 29860 printing out 'unspec_volatile' expressions. For example: 29861 29862 (define_c_enum "unspecv" [ 29863 UNSPECV_BLOCKAGE 29864 ]) 29865 29866 causes GCC to print '(unspec_volatile ... 0)' as: 29867 29868 (unspec_volatile ... UNSPECV_BLOCKAGE) 29869 29870'unspec' 29871 If an enumeration called 'unspec' is defined, GCC will use it when 29872 printing out 'unspec' expressions. GCC will also use it when 29873 printing out 'unspec_volatile' expressions unless an 'unspecv' 29874 enumeration is also defined. You can therefore decide whether to 29875 keep separate enumerations for volatile and non-volatile 29876 expressions or whether to use the same enumeration for both. 29877 29878 Another way of defining an enumeration is to use 'define_enum': 29879 29880 (define_enum "NAME" [ 29881 VALUE0 29882 VALUE1 29883 ... 29884 VALUEN 29885 ]) 29886 29887 This directive implies: 29888 29889 (define_c_enum "NAME" [ 29890 CNAME_CVALUE0 29891 CNAME_CVALUE1 29892 ... 29893 CNAME_CVALUEN 29894 ]) 29895 29896 where CVALUEI is the capitalized form of VALUEI. However, unlike 29897'define_c_enum', the enumerations defined by 'define_enum' can be used 29898in attribute specifications (*note define_enum_attr::). 29899 29900 29901File: gccint.info, Node: Iterators, Prev: Constant Definitions, Up: Machine Desc 29902 2990317.23 Iterators 29904=============== 29905 29906Ports often need to define similar patterns for more than one machine 29907mode or for more than one rtx code. GCC provides some simple iterator 29908facilities to make this process easier. 29909 29910* Menu: 29911 29912* Mode Iterators:: Generating variations of patterns for different modes. 29913* Code Iterators:: Doing the same for codes. 29914* Int Iterators:: Doing the same for integers. 29915* Subst Iterators:: Generating variations of patterns for define_subst. 29916* Parameterized Names:: Specifying iterator values in C++ code. 29917 29918 29919File: gccint.info, Node: Mode Iterators, Next: Code Iterators, Up: Iterators 29920 2992117.23.1 Mode Iterators 29922---------------------- 29923 29924Ports often need to define similar patterns for two or more different 29925modes. For example: 29926 29927 * If a processor has hardware support for both single and double 29928 floating-point arithmetic, the 'SFmode' patterns tend to be very 29929 similar to the 'DFmode' ones. 29930 29931 * If a port uses 'SImode' pointers in one configuration and 'DImode' 29932 pointers in another, it will usually have very similar 'SImode' and 29933 'DImode' patterns for manipulating pointers. 29934 29935 Mode iterators allow several patterns to be instantiated from one '.md' 29936file template. They can be used with any type of rtx-based construct, 29937such as a 'define_insn', 'define_split', or 'define_peephole2'. 29938 29939* Menu: 29940 29941* Defining Mode Iterators:: Defining a new mode iterator. 29942* Substitutions:: Combining mode iterators with substitutions 29943* Examples:: Examples 29944 29945 29946File: gccint.info, Node: Defining Mode Iterators, Next: Substitutions, Up: Mode Iterators 29947 2994817.23.1.1 Defining Mode Iterators 29949................................. 29950 29951The syntax for defining a mode iterator is: 29952 29953 (define_mode_iterator NAME [(MODE1 "COND1") ... (MODEN "CONDN")]) 29954 29955 This allows subsequent '.md' file constructs to use the mode suffix 29956':NAME'. Every construct that does so will be expanded N times, once 29957with every use of ':NAME' replaced by ':MODE1', once with every use 29958replaced by ':MODE2', and so on. In the expansion for a particular 29959MODEI, every C condition will also require that CONDI be true. 29960 29961 For example: 29962 29963 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 29964 29965 defines a new mode suffix ':P'. Every construct that uses ':P' will be 29966expanded twice, once with every ':P' replaced by ':SI' and once with 29967every ':P' replaced by ':DI'. The ':SI' version will only apply if 29968'Pmode == SImode' and the ':DI' version will only apply if 'Pmode == 29969DImode'. 29970 29971 As with other '.md' conditions, an empty string is treated as "always 29972true". '(MODE "")' can also be abbreviated to 'MODE'. For example: 29973 29974 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 29975 29976 means that the ':DI' expansion only applies if 'TARGET_64BIT' but that 29977the ':SI' expansion has no such constraint. 29978 29979 Iterators are applied in the order they are defined. This can be 29980significant if two iterators are used in a construct that requires 29981substitutions. *Note Substitutions::. 29982 29983 29984File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Iterators, Up: Mode Iterators 29985 2998617.23.1.2 Substitution in Mode Iterators 29987........................................ 29988 29989If an '.md' file construct uses mode iterators, each version of the 29990construct will often need slightly different strings or modes. For 29991example: 29992 29993 * When a 'define_expand' defines several 'addM3' patterns (*note 29994 Standard Names::), each expander will need to use the appropriate 29995 mode name for M. 29996 29997 * When a 'define_insn' defines several instruction patterns, each 29998 instruction will often use a different assembler mnemonic. 29999 30000 * When a 'define_insn' requires operands with different modes, using 30001 an iterator for one of the operand modes usually requires a 30002 specific mode for the other operand(s). 30003 30004 GCC supports such variations through a system of "mode attributes". 30005There are two standard attributes: 'mode', which is the name of the mode 30006in lower case, and 'MODE', which is the same thing in upper case. You 30007can define other attributes using: 30008 30009 (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")]) 30010 30011 where NAME is the name of the attribute and VALUEI is the value 30012associated with MODEI. 30013 30014 When GCC replaces some :ITERATOR with :MODE, it will scan each string 30015and mode in the pattern for sequences of the form '<ITERATOR:ATTR>', 30016where ATTR is the name of a mode attribute. If the attribute is defined 30017for MODE, the whole '<...>' sequence will be replaced by the appropriate 30018attribute value. 30019 30020 For example, suppose an '.md' file has: 30021 30022 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 30023 (define_mode_attr load [(SI "lw") (DI "ld")]) 30024 30025 If one of the patterns that uses ':P' contains the string 30026'"<P:load>\t%0,%1"', the 'SI' version of that pattern will use 30027'"lw\t%0,%1"' and the 'DI' version will use '"ld\t%0,%1"'. 30028 30029 Here is an example of using an attribute for a mode: 30030 30031 (define_mode_iterator LONG [SI DI]) 30032 (define_mode_attr SHORT [(SI "HI") (DI "SI")]) 30033 (define_insn ... 30034 (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...) 30035 30036 The 'ITERATOR:' prefix may be omitted, in which case the substitution 30037will be attempted for every iterator expansion. 30038 30039 30040File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Iterators 30041 3004217.23.1.3 Mode Iterator Examples 30043................................ 30044 30045Here is an example from the MIPS port. It defines the following modes 30046and attributes (among others): 30047 30048 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 30049 (define_mode_attr d [(SI "") (DI "d")]) 30050 30051 and uses the following template to define both 'subsi3' and 'subdi3': 30052 30053 (define_insn "sub<mode>3" 30054 [(set (match_operand:GPR 0 "register_operand" "=d") 30055 (minus:GPR (match_operand:GPR 1 "register_operand" "d") 30056 (match_operand:GPR 2 "register_operand" "d")))] 30057 "" 30058 "<d>subu\t%0,%1,%2" 30059 [(set_attr "type" "arith") 30060 (set_attr "mode" "<MODE>")]) 30061 30062 This is exactly equivalent to: 30063 30064 (define_insn "subsi3" 30065 [(set (match_operand:SI 0 "register_operand" "=d") 30066 (minus:SI (match_operand:SI 1 "register_operand" "d") 30067 (match_operand:SI 2 "register_operand" "d")))] 30068 "" 30069 "subu\t%0,%1,%2" 30070 [(set_attr "type" "arith") 30071 (set_attr "mode" "SI")]) 30072 30073 (define_insn "subdi3" 30074 [(set (match_operand:DI 0 "register_operand" "=d") 30075 (minus:DI (match_operand:DI 1 "register_operand" "d") 30076 (match_operand:DI 2 "register_operand" "d")))] 30077 "" 30078 "dsubu\t%0,%1,%2" 30079 [(set_attr "type" "arith") 30080 (set_attr "mode" "DI")]) 30081 30082 30083File: gccint.info, Node: Code Iterators, Next: Int Iterators, Prev: Mode Iterators, Up: Iterators 30084 3008517.23.2 Code Iterators 30086---------------------- 30087 30088Code iterators operate in a similar way to mode iterators. *Note Mode 30089Iterators::. 30090 30091 The construct: 30092 30093 (define_code_iterator NAME [(CODE1 "COND1") ... (CODEN "CONDN")]) 30094 30095 defines a pseudo rtx code NAME that can be instantiated as CODEI if 30096condition CONDI is true. Each CODEI must have the same rtx format. 30097*Note RTL Classes::. 30098 30099 As with mode iterators, each pattern that uses NAME will be expanded N 30100times, once with all uses of NAME replaced by CODE1, once with all uses 30101replaced by CODE2, and so on. *Note Defining Mode Iterators::. 30102 30103 It is possible to define attributes for codes as well as for modes. 30104There are two standard code attributes: 'code', the name of the code in 30105lower case, and 'CODE', the name of the code in upper case. Other 30106attributes are defined using: 30107 30108 (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")]) 30109 30110 Here's an example of code iterators in action, taken from the MIPS 30111port: 30112 30113 (define_code_iterator any_cond [unordered ordered unlt unge uneq ltgt unle ungt 30114 eq ne gt ge lt le gtu geu ltu leu]) 30115 30116 (define_expand "b<code>" 30117 [(set (pc) 30118 (if_then_else (any_cond:CC (cc0) 30119 (const_int 0)) 30120 (label_ref (match_operand 0 "")) 30121 (pc)))] 30122 "" 30123 { 30124 gen_conditional_branch (operands, <CODE>); 30125 DONE; 30126 }) 30127 30128 This is equivalent to: 30129 30130 (define_expand "bunordered" 30131 [(set (pc) 30132 (if_then_else (unordered:CC (cc0) 30133 (const_int 0)) 30134 (label_ref (match_operand 0 "")) 30135 (pc)))] 30136 "" 30137 { 30138 gen_conditional_branch (operands, UNORDERED); 30139 DONE; 30140 }) 30141 30142 (define_expand "bordered" 30143 [(set (pc) 30144 (if_then_else (ordered:CC (cc0) 30145 (const_int 0)) 30146 (label_ref (match_operand 0 "")) 30147 (pc)))] 30148 "" 30149 { 30150 gen_conditional_branch (operands, ORDERED); 30151 DONE; 30152 }) 30153 30154 ... 30155 30156 30157File: gccint.info, Node: Int Iterators, Next: Subst Iterators, Prev: Code Iterators, Up: Iterators 30158 3015917.23.3 Int Iterators 30160--------------------- 30161 30162Int iterators operate in a similar way to code iterators. *Note Code 30163Iterators::. 30164 30165 The construct: 30166 30167 (define_int_iterator NAME [(INT1 "COND1") ... (INTN "CONDN")]) 30168 30169 defines a pseudo integer constant NAME that can be instantiated as INTI 30170if condition CONDI is true. Each INT must have the same rtx format. 30171*Note RTL Classes::. Int iterators can appear in only those rtx fields 30172that have 'i' as the specifier. This means that each INT has to be a 30173constant defined using define_constant or define_c_enum. 30174 30175 As with mode and code iterators, each pattern that uses NAME will be 30176expanded N times, once with all uses of NAME replaced by INT1, once with 30177all uses replaced by INT2, and so on. *Note Defining Mode Iterators::. 30178 30179 It is possible to define attributes for ints as well as for codes and 30180modes. Attributes are defined using: 30181 30182 (define_int_attr NAME [(INT1 "VALUE1") ... (INTN "VALUEN")]) 30183 30184 Here's an example of int iterators in action, taken from the ARM port: 30185 30186 (define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG]) 30187 30188 (define_int_attr absneg [(UNSPEC_VQABS "abs") (UNSPEC_VQNEG "neg")]) 30189 30190 (define_insn "neon_vq<absneg><mode>" 30191 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 30192 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 30193 (match_operand:SI 2 "immediate_operand" "i")] 30194 QABSNEG))] 30195 "TARGET_NEON" 30196 "vq<absneg>.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 30197 [(set_attr "type" "neon_vqneg_vqabs")] 30198 ) 30199 30200 30201 This is equivalent to: 30202 30203 (define_insn "neon_vqabs<mode>" 30204 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 30205 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 30206 (match_operand:SI 2 "immediate_operand" "i")] 30207 UNSPEC_VQABS))] 30208 "TARGET_NEON" 30209 "vqabs.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 30210 [(set_attr "type" "neon_vqneg_vqabs")] 30211 ) 30212 30213 (define_insn "neon_vqneg<mode>" 30214 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 30215 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 30216 (match_operand:SI 2 "immediate_operand" "i")] 30217 UNSPEC_VQNEG))] 30218 "TARGET_NEON" 30219 "vqneg.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 30220 [(set_attr "type" "neon_vqneg_vqabs")] 30221 ) 30222 30223 30224 30225File: gccint.info, Node: Subst Iterators, Next: Parameterized Names, Prev: Int Iterators, Up: Iterators 30226 3022717.23.4 Subst Iterators 30228----------------------- 30229 30230Subst iterators are special type of iterators with the following 30231restrictions: they could not be declared explicitly, they always have 30232only two values, and they do not have explicit dedicated name. 30233Subst-iterators are triggered only when corresponding subst-attribute is 30234used in RTL-pattern. 30235 30236 Subst iterators transform templates in the following way: the templates 30237are duplicated, the subst-attributes in these templates are replaced 30238with the corresponding values, and a new attribute is implicitly added 30239to the given 'define_insn'/'define_expand'. The name of the added 30240attribute matches the name of 'define_subst'. Such attributes are 30241declared implicitly, and it is not allowed to have a 'define_attr' named 30242as a 'define_subst'. 30243 30244 Each subst iterator is linked to a 'define_subst'. It is declared 30245implicitly by the first appearance of the corresponding 30246'define_subst_attr', and it is not allowed to define it explicitly. 30247 30248 Declarations of subst-attributes have the following syntax: 30249 30250 (define_subst_attr "NAME" 30251 "SUBST-NAME" 30252 "NO-SUBST-VALUE" 30253 "SUBST-APPLIED-VALUE") 30254 30255 NAME is a string with which the given subst-attribute could be referred 30256to. 30257 30258 SUBST-NAME shows which 'define_subst' should be applied to an 30259RTL-template if the given subst-attribute is present in the 30260RTL-template. 30261 30262 NO-SUBST-VALUE is a value with which subst-attribute would be replaced 30263in the first copy of the original RTL-template. 30264 30265 SUBST-APPLIED-VALUE is a value with which subst-attribute would be 30266replaced in the second copy of the original RTL-template. 30267 30268 30269File: gccint.info, Node: Parameterized Names, Prev: Subst Iterators, Up: Iterators 30270 3027117.23.5 Parameterized Names 30272--------------------------- 30273 30274Ports sometimes need to apply iterators using C++ code, in order to get 30275the code or RTL pattern for a specific instruction. For example, 30276suppose we have the 'neon_vq<absneg><mode>' pattern given above: 30277 30278 (define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG]) 30279 30280 (define_int_attr absneg [(UNSPEC_VQABS "abs") (UNSPEC_VQNEG "neg")]) 30281 30282 (define_insn "neon_vq<absneg><mode>" 30283 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 30284 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 30285 (match_operand:SI 2 "immediate_operand" "i")] 30286 QABSNEG))] 30287 ... 30288 ) 30289 30290 A port might need to generate this pattern for a variable 'QABSNEG' 30291value and a variable 'VDQIW' mode. There are two ways of doing this. 30292The first is to build the rtx for the pattern directly from C++ code; 30293this is a valid technique and avoids any risk of combinatorial 30294explosion. The second is to prefix the instruction name with the 30295special character '@', which tells GCC to generate the four additional 30296functions below. In each case, NAME is the name of the instruction 30297without the leading '@' character, without the '<...>' placeholders, and 30298with any underscore before a '<...>' placeholder removed if keeping it 30299would lead to a double or trailing underscore. 30300 30301'insn_code maybe_code_for_NAME (I1, I2, ...)' 30302 See whether replacing the first '<...>' placeholder with iterator 30303 value I1, the second with iterator value I2, and so on, gives a 30304 valid instruction. Return its code if so, otherwise return 30305 'CODE_FOR_nothing'. 30306 30307'insn_code code_for_NAME (I1, I2, ...)' 30308 Same, but abort the compiler if the requested instruction does not 30309 exist. 30310 30311'rtx maybe_gen_NAME (I1, I2, ..., OP0, OP1, ...)' 30312 Check for a valid instruction in the same way as 30313 'maybe_code_for_NAME'. If the instruction exists, generate an 30314 instance of it using the operand values given by OP0, OP1, and so 30315 on, otherwise return null. 30316 30317'rtx gen_NAME (I1, I2, ..., OP0, OP1, ...)' 30318 Same, but abort the compiler if the requested instruction does not 30319 exist, or if the instruction generator invoked the 'FAIL' macro. 30320 30321 For example, changing the pattern above to: 30322 30323 (define_insn "@neon_vq<absneg><mode>" 30324 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 30325 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 30326 (match_operand:SI 2 "immediate_operand" "i")] 30327 QABSNEG))] 30328 ... 30329 ) 30330 30331 would define the same patterns as before, but in addition would 30332generate the four functions below: 30333 30334 insn_code maybe_code_for_neon_vq (int, machine_mode); 30335 insn_code code_for_neon_vq (int, machine_mode); 30336 rtx maybe_gen_neon_vq (int, machine_mode, rtx, rtx, rtx); 30337 rtx gen_neon_vq (int, machine_mode, rtx, rtx, rtx); 30338 30339 Calling 'code_for_neon_vq (UNSPEC_VQABS, V8QImode)' would then give 30340'CODE_FOR_neon_vqabsv8qi'. 30341 30342 It is possible to have multiple '@' patterns with the same name and 30343same types of iterator. For example: 30344 30345 (define_insn "@some_arithmetic_op<mode>" 30346 [(set (match_operand:INTEGER_MODES 0 "register_operand") ...)] 30347 ... 30348 ) 30349 30350 (define_insn "@some_arithmetic_op<mode>" 30351 [(set (match_operand:FLOAT_MODES 0 "register_operand") ...)] 30352 ... 30353 ) 30354 30355 would produce a single set of functions that handles both 30356'INTEGER_MODES' and 'FLOAT_MODES'. 30357 30358 30359File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top 30360 3036118 Target Description Macros and Functions 30362****************************************** 30363 30364In addition to the file 'MACHINE.md', a machine description includes a C 30365header file conventionally given the name 'MACHINE.h' and a C source 30366file named 'MACHINE.c'. The header file defines numerous macros that 30367convey the information about the target machine that does not fit into 30368the scheme of the '.md' file. The file 'tm.h' should be a link to 30369'MACHINE.h'. The header file 'config.h' includes 'tm.h' and most 30370compiler source files include 'config.h'. The source file defines a 30371variable 'targetm', which is a structure containing pointers to 30372functions and data relating to the target machine. 'MACHINE.c' should 30373also contain their definitions, if they are not defined elsewhere in 30374GCC, and other functions called through the macros defined in the '.h' 30375file. 30376 30377* Menu: 30378 30379* Target Structure:: The 'targetm' variable. 30380* Driver:: Controlling how the driver runs the compilation passes. 30381* Run-time Target:: Defining '-m' options like '-m68000' and '-m68020'. 30382* Per-Function Data:: Defining data structures for per-function information. 30383* Storage Layout:: Defining sizes and alignments of data. 30384* Type Layout:: Defining sizes and properties of basic user data types. 30385* Registers:: Naming and describing the hardware registers. 30386* Register Classes:: Defining the classes of hardware registers. 30387* Stack and Calling:: Defining which way the stack grows and by how much. 30388* Varargs:: Defining the varargs macros. 30389* Trampolines:: Code set up at run time to enter a nested function. 30390* Library Calls:: Controlling how library routines are implicitly called. 30391* Addressing Modes:: Defining addressing modes valid for memory operands. 30392* Anchored Addresses:: Defining how '-fsection-anchors' should work. 30393* Condition Code:: Defining how insns update the condition code. 30394* Costs:: Defining relative costs of different operations. 30395* Scheduling:: Adjusting the behavior of the instruction scheduler. 30396* Sections:: Dividing storage into text, data, and other sections. 30397* PIC:: Macros for position independent code. 30398* Assembler Format:: Defining how to write insns and pseudo-ops to output. 30399* Debugging Info:: Defining the format of debugging output. 30400* Floating Point:: Handling floating point for cross-compilers. 30401* Mode Switching:: Insertion of mode-switching instructions. 30402* Target Attributes:: Defining target-specific uses of '__attribute__'. 30403* Emulated TLS:: Emulated TLS support. 30404* MIPS Coprocessors:: MIPS coprocessor support and how to customize it. 30405* PCH Target:: Validity checking for precompiled headers. 30406* C++ ABI:: Controlling C++ ABI changes. 30407* D Language and ABI:: Controlling D ABI changes. 30408* Named Address Spaces:: Adding support for named address spaces 30409* Misc:: Everything else. 30410 30411 30412File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros 30413 3041418.1 The Global 'targetm' Variable 30415================================== 30416 30417 -- Variable: struct gcc_target targetm 30418 The target '.c' file must define the global 'targetm' variable 30419 which contains pointers to functions and data relating to the 30420 target machine. The variable is declared in 'target.h'; 30421 'target-def.h' defines the macro 'TARGET_INITIALIZER' which is used 30422 to initialize the variable, and macros for the default initializers 30423 for elements of the structure. The '.c' file should override those 30424 macros for which the default definition is inappropriate. For 30425 example: 30426 #include "target.h" 30427 #include "target-def.h" 30428 30429 /* Initialize the GCC target structure. */ 30430 30431 #undef TARGET_COMP_TYPE_ATTRIBUTES 30432 #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes 30433 30434 struct gcc_target targetm = TARGET_INITIALIZER; 30435 30436 Where a macro should be defined in the '.c' file in this manner to form 30437part of the 'targetm' structure, it is documented below as a "Target 30438Hook" with a prototype. Many macros will change in future from being 30439defined in the '.h' file to being part of the 'targetm' structure. 30440 30441 Similarly, there is a 'targetcm' variable for hooks that are specific 30442to front ends for C-family languages, documented as "C Target Hook". 30443This is declared in 'c-family/c-target.h', the initializer 30444'TARGETCM_INITIALIZER' in 'c-family/c-target-def.h'. If targets 30445initialize 'targetcm' themselves, they should set 30446'target_has_targetcm=yes' in 'config.gcc'; otherwise a default 30447definition is used. 30448 30449 Similarly, there is a 'targetm_common' variable for hooks that are 30450shared between the compiler driver and the compilers proper, documented 30451as "Common Target Hook". This is declared in 'common/common-target.h', 30452the initializer 'TARGETM_COMMON_INITIALIZER' in 30453'common/common-target-def.h'. If targets initialize 'targetm_common' 30454themselves, they should set 'target_has_targetm_common=yes' in 30455'config.gcc'; otherwise a default definition is used. 30456 30457 Similarly, there is a 'targetdm' variable for hooks that are specific 30458to the D language front end, documented as "D Target Hook". This is 30459declared in 'd/d-target.h', the initializer 'TARGETDM_INITIALIZER' in 30460'd/d-target-def.h'. If targets initialize 'targetdm' themselves, they 30461should set 'target_has_targetdm=yes' in 'config.gcc'; otherwise a 30462default definition is used. 30463 30464 30465File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros 30466 3046718.2 Controlling the Compilation Driver, 'gcc' 30468============================================== 30469 30470You can control the compilation driver. 30471 30472 -- Macro: DRIVER_SELF_SPECS 30473 A list of specs for the driver itself. It should be a suitable 30474 initializer for an array of strings, with no surrounding braces. 30475 30476 The driver applies these specs to its own command line between 30477 loading default 'specs' files (but not command-line specified ones) 30478 and choosing the multilib directory or running any subcommands. It 30479 applies them in the order given, so each spec can depend on the 30480 options added by earlier ones. It is also possible to remove 30481 options using '%<OPTION' in the usual way. 30482 30483 This macro can be useful when a port has several interdependent 30484 target options. It provides a way of standardizing the command 30485 line so that the other specs are easier to write. 30486 30487 Do not define this macro if it does not need to do anything. 30488 30489 -- Macro: OPTION_DEFAULT_SPECS 30490 A list of specs used to support configure-time default options 30491 (i.e. '--with' options) in the driver. It should be a suitable 30492 initializer for an array of structures, each containing two 30493 strings, without the outermost pair of surrounding braces. 30494 30495 The first item in the pair is the name of the default. This must 30496 match the code in 'config.gcc' for the target. The second item is 30497 a spec to apply if a default with this name was specified. The 30498 string '%(VALUE)' in the spec will be replaced by the value of the 30499 default everywhere it occurs. 30500 30501 The driver will apply these specs to its own command line between 30502 loading default 'specs' files and processing 'DRIVER_SELF_SPECS', 30503 using the same mechanism as 'DRIVER_SELF_SPECS'. 30504 30505 Do not define this macro if it does not need to do anything. 30506 30507 -- Macro: CPP_SPEC 30508 A C string constant that tells the GCC driver program options to 30509 pass to CPP. It can also specify how to translate options you give 30510 to GCC into options for GCC to pass to the CPP. 30511 30512 Do not define this macro if it does not need to do anything. 30513 30514 -- Macro: CPLUSPLUS_CPP_SPEC 30515 This macro is just like 'CPP_SPEC', but is used for C++, rather 30516 than C. If you do not define this macro, then the value of 30517 'CPP_SPEC' (if any) will be used instead. 30518 30519 -- Macro: CC1_SPEC 30520 A C string constant that tells the GCC driver program options to 30521 pass to 'cc1', 'cc1plus', 'f771', and the other language front 30522 ends. It can also specify how to translate options you give to GCC 30523 into options for GCC to pass to front ends. 30524 30525 Do not define this macro if it does not need to do anything. 30526 30527 -- Macro: CC1PLUS_SPEC 30528 A C string constant that tells the GCC driver program options to 30529 pass to 'cc1plus'. It can also specify how to translate options 30530 you give to GCC into options for GCC to pass to the 'cc1plus'. 30531 30532 Do not define this macro if it does not need to do anything. Note 30533 that everything defined in CC1_SPEC is already passed to 'cc1plus' 30534 so there is no need to duplicate the contents of CC1_SPEC in 30535 CC1PLUS_SPEC. 30536 30537 -- Macro: ASM_SPEC 30538 A C string constant that tells the GCC driver program options to 30539 pass to the assembler. It can also specify how to translate 30540 options you give to GCC into options for GCC to pass to the 30541 assembler. See the file 'sun3.h' for an example of this. 30542 30543 Do not define this macro if it does not need to do anything. 30544 30545 -- Macro: ASM_FINAL_SPEC 30546 A C string constant that tells the GCC driver program how to run 30547 any programs which cleanup after the normal assembler. Normally, 30548 this is not needed. See the file 'mips.h' for an example of this. 30549 30550 Do not define this macro if it does not need to do anything. 30551 30552 -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT 30553 Define this macro, with no value, if the driver should give the 30554 assembler an argument consisting of a single dash, '-', to instruct 30555 it to read from its standard input (which will be a pipe connected 30556 to the output of the compiler proper). This argument is given 30557 after any '-o' option specifying the name of the output file. 30558 30559 If you do not define this macro, the assembler is assumed to read 30560 its standard input if given no non-option arguments. If your 30561 assembler cannot read standard input at all, use a '%{pipe:%e}' 30562 construct; see 'mips.h' for instance. 30563 30564 -- Macro: LINK_SPEC 30565 A C string constant that tells the GCC driver program options to 30566 pass to the linker. It can also specify how to translate options 30567 you give to GCC into options for GCC to pass to the linker. 30568 30569 Do not define this macro if it does not need to do anything. 30570 30571 -- Macro: LIB_SPEC 30572 Another C string constant used much like 'LINK_SPEC'. The 30573 difference between the two is that 'LIB_SPEC' is used at the end of 30574 the command given to the linker. 30575 30576 If this macro is not defined, a default is provided that loads the 30577 standard C library from the usual place. See 'gcc.c'. 30578 30579 -- Macro: LIBGCC_SPEC 30580 Another C string constant that tells the GCC driver program how and 30581 when to place a reference to 'libgcc.a' into the linker command 30582 line. This constant is placed both before and after the value of 30583 'LIB_SPEC'. 30584 30585 If this macro is not defined, the GCC driver provides a default 30586 that passes the string '-lgcc' to the linker. 30587 30588 -- Macro: REAL_LIBGCC_SPEC 30589 By default, if 'ENABLE_SHARED_LIBGCC' is defined, the 'LIBGCC_SPEC' 30590 is not directly used by the driver program but is instead modified 30591 to refer to different versions of 'libgcc.a' depending on the 30592 values of the command line flags '-static', '-shared', 30593 '-static-libgcc', and '-shared-libgcc'. On targets where these 30594 modifications are inappropriate, define 'REAL_LIBGCC_SPEC' instead. 30595 'REAL_LIBGCC_SPEC' tells the driver how to place a reference to 30596 'libgcc' on the link command line, but, unlike 'LIBGCC_SPEC', it is 30597 used unmodified. 30598 30599 -- Macro: USE_LD_AS_NEEDED 30600 A macro that controls the modifications to 'LIBGCC_SPEC' mentioned 30601 in 'REAL_LIBGCC_SPEC'. If nonzero, a spec will be generated that 30602 uses '--as-needed' or equivalent options and the shared 'libgcc' in 30603 place of the static exception handler library, when linking without 30604 any of '-static', '-static-libgcc', or '-shared-libgcc'. 30605 30606 -- Macro: LINK_EH_SPEC 30607 If defined, this C string constant is added to 'LINK_SPEC'. When 30608 'USE_LD_AS_NEEDED' is zero or undefined, it also affects the 30609 modifications to 'LIBGCC_SPEC' mentioned in 'REAL_LIBGCC_SPEC'. 30610 30611 -- Macro: STARTFILE_SPEC 30612 Another C string constant used much like 'LINK_SPEC'. The 30613 difference between the two is that 'STARTFILE_SPEC' is used at the 30614 very beginning of the command given to the linker. 30615 30616 If this macro is not defined, a default is provided that loads the 30617 standard C startup file from the usual place. See 'gcc.c'. 30618 30619 -- Macro: ENDFILE_SPEC 30620 Another C string constant used much like 'LINK_SPEC'. The 30621 difference between the two is that 'ENDFILE_SPEC' is used at the 30622 very end of the command given to the linker. 30623 30624 Do not define this macro if it does not need to do anything. 30625 30626 -- Macro: THREAD_MODEL_SPEC 30627 GCC '-v' will print the thread model GCC was configured to use. 30628 However, this doesn't work on platforms that are multilibbed on 30629 thread models, such as AIX 4.3. On such platforms, define 30630 'THREAD_MODEL_SPEC' such that it evaluates to a string without 30631 blanks that names one of the recognized thread models. '%*', the 30632 default value of this macro, will expand to the value of 30633 'thread_file' set in 'config.gcc'. 30634 30635 -- Macro: SYSROOT_SUFFIX_SPEC 30636 Define this macro to add a suffix to the target sysroot when GCC is 30637 configured with a sysroot. This will cause GCC to search for 30638 usr/lib, et al, within sysroot+suffix. 30639 30640 -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC 30641 Define this macro to add a headers_suffix to the target sysroot 30642 when GCC is configured with a sysroot. This will cause GCC to pass 30643 the updated sysroot+headers_suffix to CPP, causing it to search for 30644 usr/include, et al, within sysroot+headers_suffix. 30645 30646 -- Macro: EXTRA_SPECS 30647 Define this macro to provide additional specifications to put in 30648 the 'specs' file that can be used in various specifications like 30649 'CC1_SPEC'. 30650 30651 The definition should be an initializer for an array of structures, 30652 containing a string constant, that defines the specification name, 30653 and a string constant that provides the specification. 30654 30655 Do not define this macro if it does not need to do anything. 30656 30657 'EXTRA_SPECS' is useful when an architecture contains several 30658 related targets, which have various '..._SPECS' which are similar 30659 to each other, and the maintainer would like one central place to 30660 keep these definitions. 30661 30662 For example, the PowerPC System V.4 targets use 'EXTRA_SPECS' to 30663 define either '_CALL_SYSV' when the System V calling sequence is 30664 used or '_CALL_AIX' when the older AIX-based calling sequence is 30665 used. 30666 30667 The 'config/rs6000/rs6000.h' target file defines: 30668 30669 #define EXTRA_SPECS \ 30670 { "cpp_sysv_default", CPP_SYSV_DEFAULT }, 30671 30672 #define CPP_SYS_DEFAULT "" 30673 30674 The 'config/rs6000/sysv.h' target file defines: 30675 #undef CPP_SPEC 30676 #define CPP_SPEC \ 30677 "%{posix: -D_POSIX_SOURCE } \ 30678 %{mcall-sysv: -D_CALL_SYSV } \ 30679 %{!mcall-sysv: %(cpp_sysv_default) } \ 30680 %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}" 30681 30682 #undef CPP_SYSV_DEFAULT 30683 #define CPP_SYSV_DEFAULT "-D_CALL_SYSV" 30684 30685 while the 'config/rs6000/eabiaix.h' target file defines 30686 'CPP_SYSV_DEFAULT' as: 30687 30688 #undef CPP_SYSV_DEFAULT 30689 #define CPP_SYSV_DEFAULT "-D_CALL_AIX" 30690 30691 -- Macro: LINK_LIBGCC_SPECIAL_1 30692 Define this macro if the driver program should find the library 30693 'libgcc.a'. If you do not define this macro, the driver program 30694 will pass the argument '-lgcc' to tell the linker to do the search. 30695 30696 -- Macro: LINK_GCC_C_SEQUENCE_SPEC 30697 The sequence in which libgcc and libc are specified to the linker. 30698 By default this is '%G %L %G'. 30699 30700 -- Macro: POST_LINK_SPEC 30701 Define this macro to add additional steps to be executed after 30702 linker. The default value of this macro is empty string. 30703 30704 -- Macro: LINK_COMMAND_SPEC 30705 A C string constant giving the complete command line need to 30706 execute the linker. When you do this, you will need to update your 30707 port each time a change is made to the link command line within 30708 'gcc.c'. Therefore, define this macro only if you need to 30709 completely redefine the command line for invoking the linker and 30710 there is no other way to accomplish the effect you need. 30711 Overriding this macro may be avoidable by overriding 30712 'LINK_GCC_C_SEQUENCE_SPEC' instead. 30713 30714 -- Common Target Hook: bool TARGET_ALWAYS_STRIP_DOTDOT 30715 True if '..' components should always be removed from directory 30716 names computed relative to GCC's internal directories, false 30717 (default) if such components should be preserved and directory 30718 names containing them passed to other tools such as the linker. 30719 30720 -- Macro: MULTILIB_DEFAULTS 30721 Define this macro as a C expression for the initializer of an array 30722 of string to tell the driver program which options are defaults for 30723 this target and thus do not need to be handled specially when using 30724 'MULTILIB_OPTIONS'. 30725 30726 Do not define this macro if 'MULTILIB_OPTIONS' is not defined in 30727 the target makefile fragment or if none of the options listed in 30728 'MULTILIB_OPTIONS' are set by default. *Note Target Fragment::. 30729 30730 -- Macro: RELATIVE_PREFIX_NOT_LINKDIR 30731 Define this macro to tell 'gcc' that it should only translate a 30732 '-B' prefix into a '-L' linker option if the prefix indicates an 30733 absolute file name. 30734 30735 -- Macro: MD_EXEC_PREFIX 30736 If defined, this macro is an additional prefix to try after 30737 'STANDARD_EXEC_PREFIX'. 'MD_EXEC_PREFIX' is not searched when the 30738 compiler is built as a cross compiler. If you define 30739 'MD_EXEC_PREFIX', then be sure to add it to the list of directories 30740 used to find the assembler in 'configure.ac'. 30741 30742 -- Macro: STANDARD_STARTFILE_PREFIX 30743 Define this macro as a C string constant if you wish to override 30744 the standard choice of 'libdir' as the default prefix to try when 30745 searching for startup files such as 'crt0.o'. 30746 'STANDARD_STARTFILE_PREFIX' is not searched when the compiler is 30747 built as a cross compiler. 30748 30749 -- Macro: STANDARD_STARTFILE_PREFIX_1 30750 Define this macro as a C string constant if you wish to override 30751 the standard choice of '/lib' as a prefix to try after the default 30752 prefix when searching for startup files such as 'crt0.o'. 30753 'STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is 30754 built as a cross compiler. 30755 30756 -- Macro: STANDARD_STARTFILE_PREFIX_2 30757 Define this macro as a C string constant if you wish to override 30758 the standard choice of '/lib' as yet another prefix to try after 30759 the default prefix when searching for startup files such as 30760 'crt0.o'. 'STANDARD_STARTFILE_PREFIX_2' is not searched when the 30761 compiler is built as a cross compiler. 30762 30763 -- Macro: MD_STARTFILE_PREFIX 30764 If defined, this macro supplies an additional prefix to try after 30765 the standard prefixes. 'MD_EXEC_PREFIX' is not searched when the 30766 compiler is built as a cross compiler. 30767 30768 -- Macro: MD_STARTFILE_PREFIX_1 30769 If defined, this macro supplies yet another prefix to try after the 30770 standard prefixes. It is not searched when the compiler is built 30771 as a cross compiler. 30772 30773 -- Macro: INIT_ENVIRONMENT 30774 Define this macro as a C string constant if you wish to set 30775 environment variables for programs called by the driver, such as 30776 the assembler and loader. The driver passes the value of this 30777 macro to 'putenv' to initialize the necessary environment 30778 variables. 30779 30780 -- Macro: LOCAL_INCLUDE_DIR 30781 Define this macro as a C string constant if you wish to override 30782 the standard choice of '/usr/local/include' as the default prefix 30783 to try when searching for local header files. 'LOCAL_INCLUDE_DIR' 30784 comes before 'NATIVE_SYSTEM_HEADER_DIR' (set in 'config.gcc', 30785 normally '/usr/include') in the search order. 30786 30787 Cross compilers do not search either '/usr/local/include' or its 30788 replacement. 30789 30790 -- Macro: NATIVE_SYSTEM_HEADER_COMPONENT 30791 The "component" corresponding to 'NATIVE_SYSTEM_HEADER_DIR'. See 30792 'INCLUDE_DEFAULTS', below, for the description of components. If 30793 you do not define this macro, no component is used. 30794 30795 -- Macro: INCLUDE_DEFAULTS 30796 Define this macro if you wish to override the entire default search 30797 path for include files. For a native compiler, the default search 30798 path usually consists of 'GCC_INCLUDE_DIR', 'LOCAL_INCLUDE_DIR', 30799 'GPLUSPLUS_INCLUDE_DIR', and 'NATIVE_SYSTEM_HEADER_DIR'. In 30800 addition, 'GPLUSPLUS_INCLUDE_DIR' and 'GCC_INCLUDE_DIR' are defined 30801 automatically by 'Makefile', and specify private search areas for 30802 GCC. The directory 'GPLUSPLUS_INCLUDE_DIR' is used only for C++ 30803 programs. 30804 30805 The definition should be an initializer for an array of structures. 30806 Each array element should have four elements: the directory name (a 30807 string constant), the component name (also a string constant), a 30808 flag for C++-only directories, and a flag showing that the includes 30809 in the directory don't need to be wrapped in 'extern 'C'' when 30810 compiling C++. Mark the end of the array with a null element. 30811 30812 The component name denotes what GNU package the include file is 30813 part of, if any, in all uppercase letters. For example, it might 30814 be 'GCC' or 'BINUTILS'. If the package is part of a 30815 vendor-supplied operating system, code the component name as '0'. 30816 30817 For example, here is the definition used for VAX/VMS: 30818 30819 #define INCLUDE_DEFAULTS \ 30820 { \ 30821 { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \ 30822 { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \ 30823 { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \ 30824 { ".", 0, 0, 0}, \ 30825 { 0, 0, 0, 0} \ 30826 } 30827 30828 Here is the order of prefixes tried for exec files: 30829 30830 1. Any prefixes specified by the user with '-B'. 30831 30832 2. The environment variable 'GCC_EXEC_PREFIX' or, if 'GCC_EXEC_PREFIX' 30833 is not set and the compiler has not been installed in the 30834 configure-time PREFIX, the location in which the compiler has 30835 actually been installed. 30836 30837 3. The directories specified by the environment variable 30838 'COMPILER_PATH'. 30839 30840 4. The macro 'STANDARD_EXEC_PREFIX', if the compiler has been 30841 installed in the configured-time PREFIX. 30842 30843 5. The location '/usr/libexec/gcc/', but only if this is a native 30844 compiler. 30845 30846 6. The location '/usr/lib/gcc/', but only if this is a native 30847 compiler. 30848 30849 7. The macro 'MD_EXEC_PREFIX', if defined, but only if this is a 30850 native compiler. 30851 30852 Here is the order of prefixes tried for startfiles: 30853 30854 1. Any prefixes specified by the user with '-B'. 30855 30856 2. The environment variable 'GCC_EXEC_PREFIX' or its automatically 30857 determined value based on the installed toolchain location. 30858 30859 3. The directories specified by the environment variable 30860 'LIBRARY_PATH' (or port-specific name; native only, cross compilers 30861 do not use this). 30862 30863 4. The macro 'STANDARD_EXEC_PREFIX', but only if the toolchain is 30864 installed in the configured PREFIX or this is a native compiler. 30865 30866 5. The location '/usr/lib/gcc/', but only if this is a native 30867 compiler. 30868 30869 6. The macro 'MD_EXEC_PREFIX', if defined, but only if this is a 30870 native compiler. 30871 30872 7. The macro 'MD_STARTFILE_PREFIX', if defined, but only if this is a 30873 native compiler, or we have a target system root. 30874 30875 8. The macro 'MD_STARTFILE_PREFIX_1', if defined, but only if this is 30876 a native compiler, or we have a target system root. 30877 30878 9. The macro 'STANDARD_STARTFILE_PREFIX', with any sysroot 30879 modifications. If this path is relative it will be prefixed by 30880 'GCC_EXEC_PREFIX' and the machine suffix or 'STANDARD_EXEC_PREFIX' 30881 and the machine suffix. 30882 30883 10. The macro 'STANDARD_STARTFILE_PREFIX_1', but only if this is a 30884 native compiler, or we have a target system root. The default for 30885 this macro is '/lib/'. 30886 30887 11. The macro 'STANDARD_STARTFILE_PREFIX_2', but only if this is a 30888 native compiler, or we have a target system root. The default for 30889 this macro is '/usr/lib/'. 30890 30891 30892File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros 30893 3089418.3 Run-time Target Specification 30895================================== 30896 30897Here are run-time target specifications. 30898 30899 -- Macro: TARGET_CPU_CPP_BUILTINS () 30900 This function-like macro expands to a block of code that defines 30901 built-in preprocessor macros and assertions for the target CPU, 30902 using the functions 'builtin_define', 'builtin_define_std' and 30903 'builtin_assert'. When the front end calls this macro it provides 30904 a trailing semicolon, and since it has finished command line option 30905 processing your code can use those results freely. 30906 30907 'builtin_assert' takes a string in the form you pass to the 30908 command-line option '-A', such as 'cpu=mips', and creates the 30909 assertion. 'builtin_define' takes a string in the form accepted by 30910 option '-D' and unconditionally defines the macro. 30911 30912 'builtin_define_std' takes a string representing the name of an 30913 object-like macro. If it doesn't lie in the user's namespace, 30914 'builtin_define_std' defines it unconditionally. Otherwise, it 30915 defines a version with two leading underscores, and another version 30916 with two leading and trailing underscores, and defines the original 30917 only if an ISO standard was not requested on the command line. For 30918 example, passing 'unix' defines '__unix', '__unix__' and possibly 30919 'unix'; passing '_mips' defines '__mips', '__mips__' and possibly 30920 '_mips', and passing '_ABI64' defines only '_ABI64'. 30921 30922 You can also test for the C dialect being compiled. The variable 30923 'c_language' is set to one of 'clk_c', 'clk_cplusplus' or 30924 'clk_objective_c'. Note that if we are preprocessing assembler, 30925 this variable will be 'clk_c' but the function-like macro 30926 'preprocessing_asm_p()' will return true, so you might want to 30927 check for that first. If you need to check for strict ANSI, the 30928 variable 'flag_iso' can be used. The function-like macro 30929 'preprocessing_trad_p()' can be used to check for traditional 30930 preprocessing. 30931 30932 -- Macro: TARGET_OS_CPP_BUILTINS () 30933 Similarly to 'TARGET_CPU_CPP_BUILTINS' but this macro is optional 30934 and is used for the target operating system instead. 30935 30936 -- Macro: TARGET_OBJFMT_CPP_BUILTINS () 30937 Similarly to 'TARGET_CPU_CPP_BUILTINS' but this macro is optional 30938 and is used for the target object format. 'elfos.h' uses this 30939 macro to define '__ELF__', so you probably do not need to define it 30940 yourself. 30941 30942 -- Variable: extern int target_flags 30943 This variable is declared in 'options.h', which is included before 30944 any target-specific headers. 30945 30946 -- Common Target Hook: int TARGET_DEFAULT_TARGET_FLAGS 30947 This variable specifies the initial value of 'target_flags'. Its 30948 default setting is 0. 30949 30950 -- Common Target Hook: bool TARGET_HANDLE_OPTION (struct gcc_options 30951 *OPTS, struct gcc_options *OPTS_SET, const struct 30952 cl_decoded_option *DECODED, location_t LOC) 30953 This hook is called whenever the user specifies one of the 30954 target-specific options described by the '.opt' definition files 30955 (*note Options::). It has the opportunity to do some 30956 option-specific processing and should return true if the option is 30957 valid. The default definition does nothing but return true. 30958 30959 DECODED specifies the option and its arguments. OPTS and OPTS_SET 30960 are the 'gcc_options' structures to be used for storing option 30961 state, and LOC is the location at which the option was passed 30962 ('UNKNOWN_LOCATION' except for options passed via attributes). 30963 30964 -- C Target Hook: bool TARGET_HANDLE_C_OPTION (size_t CODE, const char 30965 *ARG, int VALUE) 30966 This target hook is called whenever the user specifies one of the 30967 target-specific C language family options described by the '.opt' 30968 definition files(*note Options::). It has the opportunity to do 30969 some option-specific processing and should return true if the 30970 option is valid. The arguments are like for 30971 'TARGET_HANDLE_OPTION'. The default definition does nothing but 30972 return false. 30973 30974 In general, you should use 'TARGET_HANDLE_OPTION' to handle 30975 options. However, if processing an option requires routines that 30976 are only available in the C (and related language) front ends, then 30977 you should use 'TARGET_HANDLE_C_OPTION' instead. 30978 30979 -- C Target Hook: tree TARGET_OBJC_CONSTRUCT_STRING_OBJECT (tree 30980 STRING) 30981 Targets may provide a string object type that can be used within 30982 and between C, C++ and their respective Objective-C dialects. A 30983 string object might, for example, embed encoding and length 30984 information. These objects are considered opaque to the compiler 30985 and handled as references. An ideal implementation makes the 30986 composition of the string object match that of the Objective-C 30987 'NSString' ('NXString' for GNUStep), allowing efficient 30988 interworking between C-only and Objective-C code. If a target 30989 implements string objects then this hook should return a reference 30990 to such an object constructed from the normal 'C' string 30991 representation provided in STRING. At present, the hook is used by 30992 Objective-C only, to obtain a common-format string object when the 30993 target provides one. 30994 30995 -- C Target Hook: void TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE 30996 (const char *CLASSNAME) 30997 Declare that Objective C class CLASSNAME is referenced by the 30998 current TU. 30999 31000 -- C Target Hook: void TARGET_OBJC_DECLARE_CLASS_DEFINITION (const char 31001 *CLASSNAME) 31002 Declare that Objective C class CLASSNAME is defined by the current 31003 TU. 31004 31005 -- C Target Hook: bool TARGET_STRING_OBJECT_REF_TYPE_P (const_tree 31006 STRINGREF) 31007 If a target implements string objects then this hook should return 31008 'true' if STRINGREF is a valid reference to such an object. 31009 31010 -- C Target Hook: void TARGET_CHECK_STRING_OBJECT_FORMAT_ARG (tree 31011 FORMAT_ARG, tree ARGS_LIST) 31012 If a target implements string objects then this hook should should 31013 provide a facility to check the function arguments in ARGS_LIST 31014 against the format specifiers in FORMAT_ARG where the type of 31015 FORMAT_ARG is one recognized as a valid string reference type. 31016 31017 -- Target Hook: void TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE (void) 31018 This target function is similar to the hook 31019 'TARGET_OPTION_OVERRIDE' but is called when the optimize level is 31020 changed via an attribute or pragma or when it is reset at the end 31021 of the code affected by the attribute or pragma. It is not called 31022 at the beginning of compilation when 'TARGET_OPTION_OVERRIDE' is 31023 called so if you want to perform these actions then, you should 31024 have 'TARGET_OPTION_OVERRIDE' call 31025 'TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE'. 31026 31027 -- Macro: C_COMMON_OVERRIDE_OPTIONS 31028 This is similar to the 'TARGET_OPTION_OVERRIDE' hook but is only 31029 used in the C language frontends (C, Objective-C, C++, 31030 Objective-C++) and so can be used to alter option flag variables 31031 which only exist in those frontends. 31032 31033 -- Common Target Hook: const struct default_options * 31034 TARGET_OPTION_OPTIMIZATION_TABLE 31035 Some machines may desire to change what optimizations are performed 31036 for various optimization levels. This variable, if defined, 31037 describes options to enable at particular sets of optimization 31038 levels. These options are processed once just after the 31039 optimization level is determined and before the remainder of the 31040 command options have been parsed, so may be overridden by other 31041 options passed explicitly. 31042 31043 This processing is run once at program startup and when the 31044 optimization options are changed via '#pragma GCC optimize' or by 31045 using the 'optimize' attribute. 31046 31047 -- Common Target Hook: void TARGET_OPTION_INIT_STRUCT (struct 31048 gcc_options *OPTS) 31049 Set target-dependent initial values of fields in OPTS. 31050 31051 -- Common Target Hook: void TARGET_OPTION_DEFAULT_PARAMS (void) 31052 Set target-dependent default values for '--param' settings, using 31053 calls to 'set_default_param_value'. 31054 31055 -- Common Target Hook: bool TARGET_OPTION_VALIDATE_PARAM (int, INT) 31056 Validate target-dependent value for '--param' settings, using calls 31057 to 'set_param_value'. 31058 31059 -- Macro: SWITCHABLE_TARGET 31060 Some targets need to switch between substantially different 31061 subtargets during compilation. For example, the MIPS target has 31062 one subtarget for the traditional MIPS architecture and another for 31063 MIPS16. Source code can switch between these two subarchitectures 31064 using the 'mips16' and 'nomips16' attributes. 31065 31066 Such subtargets can differ in things like the set of available 31067 registers, the set of available instructions, the costs of various 31068 operations, and so on. GCC caches a lot of this type of 31069 information in global variables, and recomputing them for each 31070 subtarget takes a significant amount of time. The compiler 31071 therefore provides a facility for maintaining several versions of 31072 the global variables and quickly switching between them; see 31073 'target-globals.h' for details. 31074 31075 Define this macro to 1 if your target needs this facility. The 31076 default is 0. 31077 31078 -- Target Hook: bool TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P 31079 (void) 31080 Returns true if the target supports IEEE 754 floating-point 31081 exceptions and rounding modes, false otherwise. This is intended 31082 to relate to the 'float' and 'double' types, but not necessarily 31083 'long double'. By default, returns true if the 'adddf3' 31084 instruction pattern is available and false otherwise, on the 31085 assumption that hardware floating point supports exceptions and 31086 rounding modes but software floating point does not. 31087 31088 31089File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros 31090 3109118.4 Defining data structures for per-function information. 31092=========================================================== 31093 31094If the target needs to store information on a per-function basis, GCC 31095provides a macro and a couple of variables to allow this. Note, just 31096using statics to store the information is a bad idea, since GCC supports 31097nested functions, so you can be halfway through encoding one function 31098when another one comes along. 31099 31100 GCC defines a data structure called 'struct function' which contains 31101all of the data specific to an individual function. This structure 31102contains a field called 'machine' whose type is 'struct machine_function 31103*', which can be used by targets to point to their own specific data. 31104 31105 If a target needs per-function specific data it should define the type 31106'struct machine_function' and also the macro 'INIT_EXPANDERS'. This 31107macro should be used to initialize the function pointer 31108'init_machine_status'. This pointer is explained below. 31109 31110 One typical use of per-function, target specific data is to create an 31111RTX to hold the register containing the function's return address. This 31112RTX can then be used to implement the '__builtin_return_address' 31113function, for level 0. 31114 31115 Note--earlier implementations of GCC used a single data area to hold 31116all of the per-function information. Thus when processing of a nested 31117function began the old per-function data had to be pushed onto a stack, 31118and when the processing was finished, it had to be popped off the stack. 31119GCC used to provide function pointers called 'save_machine_status' and 31120'restore_machine_status' to handle the saving and restoring of the 31121target specific information. Since the single data area approach is no 31122longer used, these pointers are no longer supported. 31123 31124 -- Macro: INIT_EXPANDERS 31125 Macro called to initialize any target specific information. This 31126 macro is called once per function, before generation of any RTL has 31127 begun. The intention of this macro is to allow the initialization 31128 of the function pointer 'init_machine_status'. 31129 31130 -- Variable: void (*)(struct function *) init_machine_status 31131 If this function pointer is non-'NULL' it will be called once per 31132 function, before function compilation starts, in order to allow the 31133 target to perform any target specific initialization of the 'struct 31134 function' structure. It is intended that this would be used to 31135 initialize the 'machine' of that structure. 31136 31137 'struct machine_function' structures are expected to be freed by 31138 GC. Generally, any memory that they reference must be allocated by 31139 using GC allocation, including the structure itself. 31140 31141 31142File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros 31143 3114418.5 Storage Layout 31145=================== 31146 31147Note that the definitions of the macros in this table which are sizes or 31148alignments measured in bits do not need to be constant. They can be C 31149expressions that refer to static variables, such as the 'target_flags'. 31150*Note Run-time Target::. 31151 31152 -- Macro: BITS_BIG_ENDIAN 31153 Define this macro to have the value 1 if the most significant bit 31154 in a byte has the lowest number; otherwise define it to have the 31155 value zero. This means that bit-field instructions count from the 31156 most significant bit. If the machine has no bit-field 31157 instructions, then this must still be defined, but it doesn't 31158 matter which value it is defined to. This macro need not be a 31159 constant. 31160 31161 This macro does not affect the way structure fields are packed into 31162 bytes or words; that is controlled by 'BYTES_BIG_ENDIAN'. 31163 31164 -- Macro: BYTES_BIG_ENDIAN 31165 Define this macro to have the value 1 if the most significant byte 31166 in a word has the lowest number. This macro need not be a 31167 constant. 31168 31169 -- Macro: WORDS_BIG_ENDIAN 31170 Define this macro to have the value 1 if, in a multiword object, 31171 the most significant word has the lowest number. This applies to 31172 both memory locations and registers; see 'REG_WORDS_BIG_ENDIAN' if 31173 the order of words in memory is not the same as the order in 31174 registers. This macro need not be a constant. 31175 31176 -- Macro: REG_WORDS_BIG_ENDIAN 31177 On some machines, the order of words in a multiword object differs 31178 between registers in memory. In such a situation, define this 31179 macro to describe the order of words in a register. The macro 31180 'WORDS_BIG_ENDIAN' controls the order of words in memory. 31181 31182 -- Macro: FLOAT_WORDS_BIG_ENDIAN 31183 Define this macro to have the value 1 if 'DFmode', 'XFmode' or 31184 'TFmode' floating point numbers are stored in memory with the word 31185 containing the sign bit at the lowest address; otherwise define it 31186 to have the value 0. This macro need not be a constant. 31187 31188 You need not define this macro if the ordering is the same as for 31189 multi-word integers. 31190 31191 -- Macro: BITS_PER_WORD 31192 Number of bits in a word. If you do not define this macro, the 31193 default is 'BITS_PER_UNIT * UNITS_PER_WORD'. 31194 31195 -- Macro: MAX_BITS_PER_WORD 31196 Maximum number of bits in a word. If this is undefined, the 31197 default is 'BITS_PER_WORD'. Otherwise, it is the constant value 31198 that is the largest value that 'BITS_PER_WORD' can have at 31199 run-time. 31200 31201 -- Macro: UNITS_PER_WORD 31202 Number of storage units in a word; normally the size of a 31203 general-purpose register, a power of two from 1 or 8. 31204 31205 -- Macro: MIN_UNITS_PER_WORD 31206 Minimum number of units in a word. If this is undefined, the 31207 default is 'UNITS_PER_WORD'. Otherwise, it is the constant value 31208 that is the smallest value that 'UNITS_PER_WORD' can have at 31209 run-time. 31210 31211 -- Macro: POINTER_SIZE 31212 Width of a pointer, in bits. You must specify a value no wider 31213 than the width of 'Pmode'. If it is not equal to the width of 31214 'Pmode', you must define 'POINTERS_EXTEND_UNSIGNED'. If you do not 31215 specify a value the default is 'BITS_PER_WORD'. 31216 31217 -- Macro: POINTERS_EXTEND_UNSIGNED 31218 A C expression that determines how pointers should be extended from 31219 'ptr_mode' to either 'Pmode' or 'word_mode'. It is greater than 31220 zero if pointers should be zero-extended, zero if they should be 31221 sign-extended, and negative if some other sort of conversion is 31222 needed. In the last case, the extension is done by the target's 31223 'ptr_extend' instruction. 31224 31225 You need not define this macro if the 'ptr_mode', 'Pmode' and 31226 'word_mode' are all the same width. 31227 31228 -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE) 31229 A macro to update M and UNSIGNEDP when an object whose type is TYPE 31230 and which has the specified mode and signedness is to be stored in 31231 a register. This macro is only called when TYPE is a scalar type. 31232 31233 On most RISC machines, which only have operations that operate on a 31234 full register, define this macro to set M to 'word_mode' if M is an 31235 integer mode narrower than 'BITS_PER_WORD'. In most cases, only 31236 integer modes should be widened because wider-precision 31237 floating-point operations are usually more expensive than their 31238 narrower counterparts. 31239 31240 For most machines, the macro definition does not change UNSIGNEDP. 31241 However, some machines, have instructions that preferentially 31242 handle either signed or unsigned quantities of certain modes. For 31243 example, on the DEC Alpha, 32-bit loads from memory and 32-bit add 31244 instructions sign-extend the result to 64 bits. On such machines, 31245 set UNSIGNEDP according to which kind of extension is more 31246 efficient. 31247 31248 Do not define this macro if it would never modify M. 31249 31250 -- Target Hook: enum flt_eval_method TARGET_C_EXCESS_PRECISION (enum 31251 excess_precision_type TYPE) 31252 Return a value, with the same meaning as the C99 macro 31253 'FLT_EVAL_METHOD' that describes which excess precision should be 31254 applied. TYPE is either 'EXCESS_PRECISION_TYPE_IMPLICIT', 31255 'EXCESS_PRECISION_TYPE_FAST', or 'EXCESS_PRECISION_TYPE_STANDARD'. 31256 For 'EXCESS_PRECISION_TYPE_IMPLICIT', the target should return 31257 which precision and range operations will be implictly evaluated in 31258 regardless of the excess precision explicitly added. For 31259 'EXCESS_PRECISION_TYPE_STANDARD' and 'EXCESS_PRECISION_TYPE_FAST', 31260 the target should return the explicit excess precision that should 31261 be added depending on the value set for 31262 '-fexcess-precision=[standard|fast]'. Note that unpredictable 31263 explicit excess precision does not make sense, so a target should 31264 never return 'FLT_EVAL_METHOD_UNPREDICTABLE' when TYPE is 31265 'EXCESS_PRECISION_TYPE_STANDARD' or 'EXCESS_PRECISION_TYPE_FAST'. 31266 31267 -- Target Hook: machine_mode TARGET_PROMOTE_FUNCTION_MODE (const_tree 31268 TYPE, machine_mode MODE, int *PUNSIGNEDP, const_tree FUNTYPE, 31269 int FOR_RETURN) 31270 Like 'PROMOTE_MODE', but it is applied to outgoing function 31271 arguments or function return values. The target hook should return 31272 the new mode and possibly change '*PUNSIGNEDP' if the promotion 31273 should change signedness. This function is called only for scalar 31274 _or pointer_ types. 31275 31276 FOR_RETURN allows to distinguish the promotion of arguments and 31277 return values. If it is '1', a return value is being promoted and 31278 'TARGET_FUNCTION_VALUE' must perform the same promotions done here. 31279 If it is '2', the returned mode should be that of the register in 31280 which an incoming parameter is copied, or the outgoing result is 31281 computed; then the hook should return the same mode as 31282 'promote_mode', though the signedness may be different. 31283 31284 TYPE can be NULL when promoting function arguments of libcalls. 31285 31286 The default is to not promote arguments and return values. You can 31287 also define the hook to 31288 'default_promote_function_mode_always_promote' if you would like to 31289 apply the same rules given by 'PROMOTE_MODE'. 31290 31291 -- Macro: PARM_BOUNDARY 31292 Normal alignment required for function parameters on the stack, in 31293 bits. All stack parameters receive at least this much alignment 31294 regardless of data type. On most machines, this is the same as the 31295 size of an integer. 31296 31297 -- Macro: STACK_BOUNDARY 31298 Define this macro to the minimum alignment enforced by hardware for 31299 the stack pointer on this machine. The definition is a C 31300 expression for the desired alignment (measured in bits). This 31301 value is used as a default if 'PREFERRED_STACK_BOUNDARY' is not 31302 defined. On most machines, this should be the same as 31303 'PARM_BOUNDARY'. 31304 31305 -- Macro: PREFERRED_STACK_BOUNDARY 31306 Define this macro if you wish to preserve a certain alignment for 31307 the stack pointer, greater than what the hardware enforces. The 31308 definition is a C expression for the desired alignment (measured in 31309 bits). This macro must evaluate to a value equal to or larger than 31310 'STACK_BOUNDARY'. 31311 31312 -- Macro: INCOMING_STACK_BOUNDARY 31313 Define this macro if the incoming stack boundary may be different 31314 from 'PREFERRED_STACK_BOUNDARY'. This macro must evaluate to a 31315 value equal to or larger than 'STACK_BOUNDARY'. 31316 31317 -- Macro: FUNCTION_BOUNDARY 31318 Alignment required for a function entry point, in bits. 31319 31320 -- Macro: BIGGEST_ALIGNMENT 31321 Biggest alignment that any data type can require on this machine, 31322 in bits. Note that this is not the biggest alignment that is 31323 supported, just the biggest alignment that, when violated, may 31324 cause a fault. 31325 31326 -- Target Hook: HOST_WIDE_INT TARGET_ABSOLUTE_BIGGEST_ALIGNMENT 31327 If defined, this target hook specifies the absolute biggest 31328 alignment that a type or variable can have on this machine, 31329 otherwise, 'BIGGEST_ALIGNMENT' is used. 31330 31331 -- Macro: MALLOC_ABI_ALIGNMENT 31332 Alignment, in bits, a C conformant malloc implementation has to 31333 provide. If not defined, the default value is 'BITS_PER_WORD'. 31334 31335 -- Macro: ATTRIBUTE_ALIGNED_VALUE 31336 Alignment used by the '__attribute__ ((aligned))' construct. If 31337 not defined, the default value is 'BIGGEST_ALIGNMENT'. 31338 31339 -- Macro: MINIMUM_ATOMIC_ALIGNMENT 31340 If defined, the smallest alignment, in bits, that can be given to 31341 an object that can be referenced in one operation, without 31342 disturbing any nearby object. Normally, this is 'BITS_PER_UNIT', 31343 but may be larger on machines that don't have byte or half-word 31344 store operations. 31345 31346 -- Macro: BIGGEST_FIELD_ALIGNMENT 31347 Biggest alignment that any structure or union field can require on 31348 this machine, in bits. If defined, this overrides 31349 'BIGGEST_ALIGNMENT' for structure and union fields only, unless the 31350 field alignment has been set by the '__attribute__ ((aligned (N)))' 31351 construct. 31352 31353 -- Macro: ADJUST_FIELD_ALIGN (FIELD, TYPE, COMPUTED) 31354 An expression for the alignment of a structure field FIELD of type 31355 TYPE if the alignment computed in the usual way (including applying 31356 of 'BIGGEST_ALIGNMENT' and 'BIGGEST_FIELD_ALIGNMENT' to the 31357 alignment) is COMPUTED. It overrides alignment only if the field 31358 alignment has not been set by the '__attribute__ ((aligned (N)))' 31359 construct. Note that FIELD may be 'NULL_TREE' in case we just 31360 query for the minimum alignment of a field of type TYPE in 31361 structure context. 31362 31363 -- Macro: MAX_STACK_ALIGNMENT 31364 Biggest stack alignment guaranteed by the backend. Use this macro 31365 to specify the maximum alignment of a variable on stack. 31366 31367 If not defined, the default value is 'STACK_BOUNDARY'. 31368 31369 -- Macro: MAX_OFILE_ALIGNMENT 31370 Biggest alignment supported by the object file format of this 31371 machine. Use this macro to limit the alignment which can be 31372 specified using the '__attribute__ ((aligned (N)))' construct for 31373 functions and objects with static storage duration. The alignment 31374 of automatic objects may exceed the object file format maximum up 31375 to the maximum supported by GCC. If not defined, the default value 31376 is 'BIGGEST_ALIGNMENT'. 31377 31378 On systems that use ELF, the default (in 'config/elfos.h') is the 31379 largest supported 32-bit ELF section alignment representable on a 31380 32-bit host e.g. '(((uint64_t) 1 << 28) * 8)'. On 32-bit ELF the 31381 largest supported section alignment in bits is '(0x80000000 * 8)', 31382 but this is not representable on 32-bit hosts. 31383 31384 -- Target Hook: HOST_WIDE_INT TARGET_STATIC_RTX_ALIGNMENT (machine_mode 31385 MODE) 31386 This hook returns the preferred alignment in bits for a 31387 statically-allocated rtx, such as a constant pool entry. MODE is 31388 the mode of the rtx. The default implementation returns 31389 'GET_MODE_ALIGNMENT (MODE)'. 31390 31391 -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN) 31392 If defined, a C expression to compute the alignment for a variable 31393 in the static store. TYPE is the data type, and BASIC-ALIGN is the 31394 alignment that the object would ordinarily have. The value of this 31395 macro is used instead of that alignment to align the object. 31396 31397 If this macro is not defined, then BASIC-ALIGN is used. 31398 31399 One use of this macro is to increase alignment of medium-size data 31400 to make it all fit in fewer cache lines. Another is to cause 31401 character arrays to be word-aligned so that 'strcpy' calls that 31402 copy constants to character arrays can be done inline. 31403 31404 -- Macro: DATA_ABI_ALIGNMENT (TYPE, BASIC-ALIGN) 31405 Similar to 'DATA_ALIGNMENT', but for the cases where the ABI 31406 mandates some alignment increase, instead of optimization only 31407 purposes. E.g. AMD x86-64 psABI says that variables with array 31408 type larger than 15 bytes must be aligned to 16 byte boundaries. 31409 31410 If this macro is not defined, then BASIC-ALIGN is used. 31411 31412 -- Target Hook: HOST_WIDE_INT TARGET_CONSTANT_ALIGNMENT (const_tree 31413 CONSTANT, HOST_WIDE_INT BASIC_ALIGN) 31414 This hook returns the alignment in bits of a constant that is being 31415 placed in memory. CONSTANT is the constant and BASIC_ALIGN is the 31416 alignment that the object would ordinarily have. 31417 31418 The default definition just returns BASIC_ALIGN. 31419 31420 The typical use of this hook is to increase alignment for string 31421 constants to be word aligned so that 'strcpy' calls that copy 31422 constants can be done inline. The function 31423 'constant_alignment_word_strings' provides such a definition. 31424 31425 -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN) 31426 If defined, a C expression to compute the alignment for a variable 31427 in the local store. TYPE is the data type, and BASIC-ALIGN is the 31428 alignment that the object would ordinarily have. The value of this 31429 macro is used instead of that alignment to align the object. 31430 31431 If this macro is not defined, then BASIC-ALIGN is used. 31432 31433 One use of this macro is to increase alignment of medium-size data 31434 to make it all fit in fewer cache lines. 31435 31436 If the value of this macro has a type, it should be an unsigned 31437 type. 31438 31439 -- Target Hook: HOST_WIDE_INT TARGET_VECTOR_ALIGNMENT (const_tree TYPE) 31440 This hook can be used to define the alignment for a vector of type 31441 TYPE, in order to comply with a platform ABI. The default is to 31442 require natural alignment for vector types. The alignment returned 31443 by this hook must be a power-of-two multiple of the default 31444 alignment of the vector element type. 31445 31446 -- Macro: STACK_SLOT_ALIGNMENT (TYPE, MODE, BASIC-ALIGN) 31447 If defined, a C expression to compute the alignment for stack slot. 31448 TYPE is the data type, MODE is the widest mode available, and 31449 BASIC-ALIGN is the alignment that the slot would ordinarily have. 31450 The value of this macro is used instead of that alignment to align 31451 the slot. 31452 31453 If this macro is not defined, then BASIC-ALIGN is used when TYPE is 31454 'NULL'. Otherwise, 'LOCAL_ALIGNMENT' will be used. 31455 31456 This macro is to set alignment of stack slot to the maximum 31457 alignment of all possible modes which the slot may have. 31458 31459 If the value of this macro has a type, it should be an unsigned 31460 type. 31461 31462 -- Macro: LOCAL_DECL_ALIGNMENT (DECL) 31463 If defined, a C expression to compute the alignment for a local 31464 variable DECL. 31465 31466 If this macro is not defined, then 'LOCAL_ALIGNMENT (TREE_TYPE 31467 (DECL), DECL_ALIGN (DECL))' is used. 31468 31469 One use of this macro is to increase alignment of medium-size data 31470 to make it all fit in fewer cache lines. 31471 31472 If the value of this macro has a type, it should be an unsigned 31473 type. 31474 31475 -- Macro: MINIMUM_ALIGNMENT (EXP, MODE, ALIGN) 31476 If defined, a C expression to compute the minimum required 31477 alignment for dynamic stack realignment purposes for EXP (a type or 31478 decl), MODE, assuming normal alignment ALIGN. 31479 31480 If this macro is not defined, then ALIGN will be used. 31481 31482 -- Macro: EMPTY_FIELD_BOUNDARY 31483 Alignment in bits to be given to a structure bit-field that follows 31484 an empty field such as 'int : 0;'. 31485 31486 If 'PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro. 31487 31488 -- Macro: STRUCTURE_SIZE_BOUNDARY 31489 Number of bits which any structure or union's size must be a 31490 multiple of. Each structure or union's size is rounded up to a 31491 multiple of this. 31492 31493 If you do not define this macro, the default is the same as 31494 'BITS_PER_UNIT'. 31495 31496 -- Macro: STRICT_ALIGNMENT 31497 Define this macro to be the value 1 if instructions will fail to 31498 work if given data not on the nominal alignment. If instructions 31499 will merely go slower in that case, define this macro as 0. 31500 31501 -- Macro: PCC_BITFIELD_TYPE_MATTERS 31502 Define this if you wish to imitate the way many other C compilers 31503 handle alignment of bit-fields and the structures that contain 31504 them. 31505 31506 The behavior is that the type written for a named bit-field ('int', 31507 'short', or other integer type) imposes an alignment for the entire 31508 structure, as if the structure really did contain an ordinary field 31509 of that type. In addition, the bit-field is placed within the 31510 structure so that it would fit within such a field, not crossing a 31511 boundary for it. 31512 31513 Thus, on most machines, a named bit-field whose type is written as 31514 'int' would not cross a four-byte boundary, and would force 31515 four-byte alignment for the whole structure. (The alignment used 31516 may not be four bytes; it is controlled by the other alignment 31517 parameters.) 31518 31519 An unnamed bit-field will not affect the alignment of the 31520 containing structure. 31521 31522 If the macro is defined, its definition should be a C expression; a 31523 nonzero value for the expression enables this behavior. 31524 31525 Note that if this macro is not defined, or its value is zero, some 31526 bit-fields may cross more than one alignment boundary. The 31527 compiler can support such references if there are 'insv', 'extv', 31528 and 'extzv' insns that can directly reference memory. 31529 31530 The other known way of making bit-fields work is to define 31531 'STRUCTURE_SIZE_BOUNDARY' as large as 'BIGGEST_ALIGNMENT'. Then 31532 every structure can be accessed with fullwords. 31533 31534 Unless the machine has bit-field instructions or you define 31535 'STRUCTURE_SIZE_BOUNDARY' that way, you must define 31536 'PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value. 31537 31538 If your aim is to make GCC use the same conventions for laying out 31539 bit-fields as are used by another compiler, here is how to 31540 investigate what the other compiler does. Compile and run this 31541 program: 31542 31543 struct foo1 31544 { 31545 char x; 31546 char :0; 31547 char y; 31548 }; 31549 31550 struct foo2 31551 { 31552 char x; 31553 int :0; 31554 char y; 31555 }; 31556 31557 main () 31558 { 31559 printf ("Size of foo1 is %d\n", 31560 sizeof (struct foo1)); 31561 printf ("Size of foo2 is %d\n", 31562 sizeof (struct foo2)); 31563 exit (0); 31564 } 31565 31566 If this prints 2 and 5, then the compiler's behavior is what you 31567 would get from 'PCC_BITFIELD_TYPE_MATTERS'. 31568 31569 -- Macro: BITFIELD_NBYTES_LIMITED 31570 Like 'PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited 31571 to aligning a bit-field within the structure. 31572 31573 -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELD (void) 31574 When 'PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine 31575 whether unnamed bitfields affect the alignment of the containing 31576 structure. The hook should return true if the structure should 31577 inherit the alignment requirements of an unnamed bitfield's type. 31578 31579 -- Target Hook: bool TARGET_NARROW_VOLATILE_BITFIELD (void) 31580 This target hook should return 'true' if accesses to volatile 31581 bitfields should use the narrowest mode possible. It should return 31582 'false' if these accesses should use the bitfield container type. 31583 31584 The default is 'false'. 31585 31586 -- Target Hook: bool TARGET_MEMBER_TYPE_FORCES_BLK (const_tree FIELD, 31587 machine_mode MODE) 31588 Return true if a structure, union or array containing FIELD should 31589 be accessed using 'BLKMODE'. 31590 31591 If FIELD is the only field in the structure, MODE is its mode, 31592 otherwise MODE is VOIDmode. MODE is provided in the case where 31593 structures of one field would require the structure's mode to 31594 retain the field's mode. 31595 31596 Normally, this is not needed. 31597 31598 -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED) 31599 Define this macro as an expression for the alignment of a type 31600 (given by TYPE as a tree node) if the alignment computed in the 31601 usual way is COMPUTED and the alignment explicitly specified was 31602 SPECIFIED. 31603 31604 The default is to use SPECIFIED if it is larger; otherwise, use the 31605 smaller of COMPUTED and 'BIGGEST_ALIGNMENT' 31606 31607 -- Macro: MAX_FIXED_MODE_SIZE 31608 An integer expression for the size in bits of the largest integer 31609 machine mode that should actually be used. All integer machine 31610 modes of this size or smaller can be used for structures and unions 31611 with the appropriate sizes. If this macro is undefined, 31612 'GET_MODE_BITSIZE (DImode)' is assumed. 31613 31614 -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL) 31615 If defined, an expression of type 'machine_mode' that specifies the 31616 mode of the save area operand of a 'save_stack_LEVEL' named pattern 31617 (*note Standard Names::). SAVE_LEVEL is one of 'SAVE_BLOCK', 31618 'SAVE_FUNCTION', or 'SAVE_NONLOCAL' and selects which of the three 31619 named patterns is having its mode specified. 31620 31621 You need not define this macro if it always returns 'Pmode'. You 31622 would most commonly define this macro if the 'save_stack_LEVEL' 31623 patterns need to support both a 32- and a 64-bit mode. 31624 31625 -- Macro: STACK_SIZE_MODE 31626 If defined, an expression of type 'machine_mode' that specifies the 31627 mode of the size increment operand of an 'allocate_stack' named 31628 pattern (*note Standard Names::). 31629 31630 You need not define this macro if it always returns 'word_mode'. 31631 You would most commonly define this macro if the 'allocate_stack' 31632 pattern needs to support both a 32- and a 64-bit mode. 31633 31634 -- Target Hook: scalar_int_mode TARGET_LIBGCC_CMP_RETURN_MODE (void) 31635 This target hook should return the mode to be used for the return 31636 value of compare instructions expanded to libgcc calls. If not 31637 defined 'word_mode' is returned which is the right choice for a 31638 majority of targets. 31639 31640 -- Target Hook: scalar_int_mode TARGET_LIBGCC_SHIFT_COUNT_MODE (void) 31641 This target hook should return the mode to be used for the shift 31642 count operand of shift instructions expanded to libgcc calls. If 31643 not defined 'word_mode' is returned which is the right choice for a 31644 majority of targets. 31645 31646 -- Target Hook: scalar_int_mode TARGET_UNWIND_WORD_MODE (void) 31647 Return machine mode to be used for '_Unwind_Word' type. The 31648 default is to use 'word_mode'. 31649 31650 -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (const_tree 31651 RECORD_TYPE) 31652 This target hook returns 'true' if bit-fields in the given 31653 RECORD_TYPE are to be laid out following the rules of Microsoft 31654 Visual C/C++, namely: (i) a bit-field won't share the same storage 31655 unit with the previous bit-field if their underlying types have 31656 different sizes, and the bit-field will be aligned to the highest 31657 alignment of the underlying types of itself and of the previous 31658 bit-field; (ii) a zero-sized bit-field will affect the alignment of 31659 the whole enclosing structure, even if it is unnamed; except that 31660 (iii) a zero-sized bit-field will be disregarded unless it follows 31661 another bit-field of nonzero size. If this hook returns 'true', 31662 other macros that control bit-field layout are ignored. 31663 31664 When a bit-field is inserted into a packed record, the whole size 31665 of the underlying type is used by one or more same-size adjacent 31666 bit-fields (that is, if its long:3, 32 bits is used in the record, 31667 and any additional adjacent long bit-fields are packed into the 31668 same chunk of 32 bits. However, if the size changes, a new field 31669 of that size is allocated). In an unpacked record, this is the 31670 same as using alignment, but not equivalent when packing. 31671 31672 If both MS bit-fields and '__attribute__((packed))' are used, the 31673 latter will take precedence. If '__attribute__((packed))' is used 31674 on a single field when MS bit-fields are in use, it will take 31675 precedence for that field, but the alignment of the rest of the 31676 structure may affect its placement. 31677 31678 -- Target Hook: bool TARGET_DECIMAL_FLOAT_SUPPORTED_P (void) 31679 Returns true if the target supports decimal floating point. 31680 31681 -- Target Hook: bool TARGET_FIXED_POINT_SUPPORTED_P (void) 31682 Returns true if the target supports fixed-point arithmetic. 31683 31684 -- Target Hook: void TARGET_EXPAND_TO_RTL_HOOK (void) 31685 This hook is called just before expansion into rtl, allowing the 31686 target to perform additional initializations or analysis before the 31687 expansion. For example, the rs6000 port uses it to allocate a 31688 scratch stack slot for use in copying SDmode values between memory 31689 and floating point registers whenever the function being expanded 31690 has any SDmode usage. 31691 31692 -- Target Hook: void TARGET_INSTANTIATE_DECLS (void) 31693 This hook allows the backend to perform additional instantiations 31694 on rtl that are not actually in any insns yet, but will be later. 31695 31696 -- Target Hook: const char * TARGET_MANGLE_TYPE (const_tree TYPE) 31697 If your target defines any fundamental types, or any types your 31698 target uses should be mangled differently from the default, define 31699 this hook to return the appropriate encoding for these types as 31700 part of a C++ mangled name. The TYPE argument is the tree 31701 structure representing the type to be mangled. The hook may be 31702 applied to trees which are not target-specific fundamental types; 31703 it should return 'NULL' for all such types, as well as arguments it 31704 does not recognize. If the return value is not 'NULL', it must 31705 point to a statically-allocated string constant. 31706 31707 Target-specific fundamental types might be new fundamental types or 31708 qualified versions of ordinary fundamental types. Encode new 31709 fundamental types as 'u N NAME', where NAME is the name used for 31710 the type in source code, and N is the length of NAME in decimal. 31711 Encode qualified versions of ordinary types as 'U N NAME CODE', 31712 where NAME is the name used for the type qualifier in source code, 31713 N is the length of NAME as above, and CODE is the code used to 31714 represent the unqualified version of this type. (See 31715 'write_builtin_type' in 'cp/mangle.c' for the list of codes.) In 31716 both cases the spaces are for clarity; do not include any spaces in 31717 your string. 31718 31719 This hook is applied to types prior to typedef resolution. If the 31720 mangled name for a particular type depends only on that type's main 31721 variant, you can perform typedef resolution yourself using 31722 'TYPE_MAIN_VARIANT' before mangling. 31723 31724 The default version of this hook always returns 'NULL', which is 31725 appropriate for a target that does not define any new fundamental 31726 types. 31727 31728 31729File: gccint.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros 31730 3173118.6 Layout of Source Language Data Types 31732========================================= 31733 31734These macros define the sizes and other characteristics of the standard 31735basic data types used in programs being compiled. Unlike the macros in 31736the previous section, these apply to specific features of C and related 31737languages, rather than to fundamental aspects of storage layout. 31738 31739 -- Macro: INT_TYPE_SIZE 31740 A C expression for the size in bits of the type 'int' on the target 31741 machine. If you don't define this, the default is one word. 31742 31743 -- Macro: SHORT_TYPE_SIZE 31744 A C expression for the size in bits of the type 'short' on the 31745 target machine. If you don't define this, the default is half a 31746 word. (If this would be less than one storage unit, it is rounded 31747 up to one unit.) 31748 31749 -- Macro: LONG_TYPE_SIZE 31750 A C expression for the size in bits of the type 'long' on the 31751 target machine. If you don't define this, the default is one word. 31752 31753 -- Macro: ADA_LONG_TYPE_SIZE 31754 On some machines, the size used for the Ada equivalent of the type 31755 'long' by a native Ada compiler differs from that used by C. In 31756 that situation, define this macro to be a C expression to be used 31757 for the size of that type. If you don't define this, the default 31758 is the value of 'LONG_TYPE_SIZE'. 31759 31760 -- Macro: LONG_LONG_TYPE_SIZE 31761 A C expression for the size in bits of the type 'long long' on the 31762 target machine. If you don't define this, the default is two 31763 words. If you want to support GNU Ada on your machine, the value 31764 of this macro must be at least 64. 31765 31766 -- Macro: CHAR_TYPE_SIZE 31767 A C expression for the size in bits of the type 'char' on the 31768 target machine. If you don't define this, the default is 31769 'BITS_PER_UNIT'. 31770 31771 -- Macro: BOOL_TYPE_SIZE 31772 A C expression for the size in bits of the C++ type 'bool' and C99 31773 type '_Bool' on the target machine. If you don't define this, and 31774 you probably shouldn't, the default is 'CHAR_TYPE_SIZE'. 31775 31776 -- Macro: FLOAT_TYPE_SIZE 31777 A C expression for the size in bits of the type 'float' on the 31778 target machine. If you don't define this, the default is one word. 31779 31780 -- Macro: DOUBLE_TYPE_SIZE 31781 A C expression for the size in bits of the type 'double' on the 31782 target machine. If you don't define this, the default is two 31783 words. 31784 31785 -- Macro: LONG_DOUBLE_TYPE_SIZE 31786 A C expression for the size in bits of the type 'long double' on 31787 the target machine. If you don't define this, the default is two 31788 words. 31789 31790 -- Macro: SHORT_FRACT_TYPE_SIZE 31791 A C expression for the size in bits of the type 'short _Fract' on 31792 the target machine. If you don't define this, the default is 31793 'BITS_PER_UNIT'. 31794 31795 -- Macro: FRACT_TYPE_SIZE 31796 A C expression for the size in bits of the type '_Fract' on the 31797 target machine. If you don't define this, the default is 31798 'BITS_PER_UNIT * 2'. 31799 31800 -- Macro: LONG_FRACT_TYPE_SIZE 31801 A C expression for the size in bits of the type 'long _Fract' on 31802 the target machine. If you don't define this, the default is 31803 'BITS_PER_UNIT * 4'. 31804 31805 -- Macro: LONG_LONG_FRACT_TYPE_SIZE 31806 A C expression for the size in bits of the type 'long long _Fract' 31807 on the target machine. If you don't define this, the default is 31808 'BITS_PER_UNIT * 8'. 31809 31810 -- Macro: SHORT_ACCUM_TYPE_SIZE 31811 A C expression for the size in bits of the type 'short _Accum' on 31812 the target machine. If you don't define this, the default is 31813 'BITS_PER_UNIT * 2'. 31814 31815 -- Macro: ACCUM_TYPE_SIZE 31816 A C expression for the size in bits of the type '_Accum' on the 31817 target machine. If you don't define this, the default is 31818 'BITS_PER_UNIT * 4'. 31819 31820 -- Macro: LONG_ACCUM_TYPE_SIZE 31821 A C expression for the size in bits of the type 'long _Accum' on 31822 the target machine. If you don't define this, the default is 31823 'BITS_PER_UNIT * 8'. 31824 31825 -- Macro: LONG_LONG_ACCUM_TYPE_SIZE 31826 A C expression for the size in bits of the type 'long long _Accum' 31827 on the target machine. If you don't define this, the default is 31828 'BITS_PER_UNIT * 16'. 31829 31830 -- Macro: LIBGCC2_GNU_PREFIX 31831 This macro corresponds to the 'TARGET_LIBFUNC_GNU_PREFIX' target 31832 hook and should be defined if that hook is overriden to be true. 31833 It causes function names in libgcc to be changed to use a '__gnu_' 31834 prefix for their name rather than the default '__'. A port which 31835 uses this macro should also arrange to use 't-gnu-prefix' in the 31836 libgcc 'config.host'. 31837 31838 -- Macro: WIDEST_HARDWARE_FP_SIZE 31839 A C expression for the size in bits of the widest floating-point 31840 format supported by the hardware. If you define this macro, you 31841 must specify a value less than or equal to the value of 31842 'LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the 31843 value of 'LONG_DOUBLE_TYPE_SIZE' is the default. 31844 31845 -- Macro: DEFAULT_SIGNED_CHAR 31846 An expression whose value is 1 or 0, according to whether the type 31847 'char' should be signed or unsigned by default. The user can 31848 always override this default with the options '-fsigned-char' and 31849 '-funsigned-char'. 31850 31851 -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void) 31852 This target hook should return true if the compiler should give an 31853 'enum' type only as many bytes as it takes to represent the range 31854 of possible values of that type. It should return false if all 31855 'enum' types should be allocated like 'int'. 31856 31857 The default is to return false. 31858 31859 -- Macro: SIZE_TYPE 31860 A C expression for a string describing the name of the data type to 31861 use for size values. The typedef name 'size_t' is defined using 31862 the contents of the string. 31863 31864 The string can contain more than one keyword. If so, separate them 31865 with spaces, and write first any length keyword, then 'unsigned' if 31866 appropriate, and finally 'int'. The string must exactly match one 31867 of the data type names defined in the function 31868 'c_common_nodes_and_builtins' in the file 'c-family/c-common.c'. 31869 You may not omit 'int' or change the order--that would cause the 31870 compiler to crash on startup. 31871 31872 If you don't define this macro, the default is '"long unsigned 31873 int"'. 31874 31875 -- Macro: SIZETYPE 31876 GCC defines internal types ('sizetype', 'ssizetype', 'bitsizetype' 31877 and 'sbitsizetype') for expressions dealing with size. This macro 31878 is a C expression for a string describing the name of the data type 31879 from which the precision of 'sizetype' is extracted. 31880 31881 The string has the same restrictions as 'SIZE_TYPE' string. 31882 31883 If you don't define this macro, the default is 'SIZE_TYPE'. 31884 31885 -- Macro: PTRDIFF_TYPE 31886 A C expression for a string describing the name of the data type to 31887 use for the result of subtracting two pointers. The typedef name 31888 'ptrdiff_t' is defined using the contents of the string. See 31889 'SIZE_TYPE' above for more information. 31890 31891 If you don't define this macro, the default is '"long int"'. 31892 31893 -- Macro: WCHAR_TYPE 31894 A C expression for a string describing the name of the data type to 31895 use for wide characters. The typedef name 'wchar_t' is defined 31896 using the contents of the string. See 'SIZE_TYPE' above for more 31897 information. 31898 31899 If you don't define this macro, the default is '"int"'. 31900 31901 -- Macro: WCHAR_TYPE_SIZE 31902 A C expression for the size in bits of the data type for wide 31903 characters. This is used in 'cpp', which cannot make use of 31904 'WCHAR_TYPE'. 31905 31906 -- Macro: WINT_TYPE 31907 A C expression for a string describing the name of the data type to 31908 use for wide characters passed to 'printf' and returned from 31909 'getwc'. The typedef name 'wint_t' is defined using the contents 31910 of the string. See 'SIZE_TYPE' above for more information. 31911 31912 If you don't define this macro, the default is '"unsigned int"'. 31913 31914 -- Macro: INTMAX_TYPE 31915 A C expression for a string describing the name of the data type 31916 that can represent any value of any standard or extended signed 31917 integer type. The typedef name 'intmax_t' is defined using the 31918 contents of the string. See 'SIZE_TYPE' above for more 31919 information. 31920 31921 If you don't define this macro, the default is the first of 31922 '"int"', '"long int"', or '"long long int"' that has as much 31923 precision as 'long long int'. 31924 31925 -- Macro: UINTMAX_TYPE 31926 A C expression for a string describing the name of the data type 31927 that can represent any value of any standard or extended unsigned 31928 integer type. The typedef name 'uintmax_t' is defined using the 31929 contents of the string. See 'SIZE_TYPE' above for more 31930 information. 31931 31932 If you don't define this macro, the default is the first of 31933 '"unsigned int"', '"long unsigned int"', or '"long long unsigned 31934 int"' that has as much precision as 'long long unsigned int'. 31935 31936 -- Macro: SIG_ATOMIC_TYPE 31937 -- Macro: INT8_TYPE 31938 -- Macro: INT16_TYPE 31939 -- Macro: INT32_TYPE 31940 -- Macro: INT64_TYPE 31941 -- Macro: UINT8_TYPE 31942 -- Macro: UINT16_TYPE 31943 -- Macro: UINT32_TYPE 31944 -- Macro: UINT64_TYPE 31945 -- Macro: INT_LEAST8_TYPE 31946 -- Macro: INT_LEAST16_TYPE 31947 -- Macro: INT_LEAST32_TYPE 31948 -- Macro: INT_LEAST64_TYPE 31949 -- Macro: UINT_LEAST8_TYPE 31950 -- Macro: UINT_LEAST16_TYPE 31951 -- Macro: UINT_LEAST32_TYPE 31952 -- Macro: UINT_LEAST64_TYPE 31953 -- Macro: INT_FAST8_TYPE 31954 -- Macro: INT_FAST16_TYPE 31955 -- Macro: INT_FAST32_TYPE 31956 -- Macro: INT_FAST64_TYPE 31957 -- Macro: UINT_FAST8_TYPE 31958 -- Macro: UINT_FAST16_TYPE 31959 -- Macro: UINT_FAST32_TYPE 31960 -- Macro: UINT_FAST64_TYPE 31961 -- Macro: INTPTR_TYPE 31962 -- Macro: UINTPTR_TYPE 31963 C expressions for the standard types 'sig_atomic_t', 'int8_t', 31964 'int16_t', 'int32_t', 'int64_t', 'uint8_t', 'uint16_t', 'uint32_t', 31965 'uint64_t', 'int_least8_t', 'int_least16_t', 'int_least32_t', 31966 'int_least64_t', 'uint_least8_t', 'uint_least16_t', 31967 'uint_least32_t', 'uint_least64_t', 'int_fast8_t', 'int_fast16_t', 31968 'int_fast32_t', 'int_fast64_t', 'uint_fast8_t', 'uint_fast16_t', 31969 'uint_fast32_t', 'uint_fast64_t', 'intptr_t', and 'uintptr_t'. See 31970 'SIZE_TYPE' above for more information. 31971 31972 If any of these macros evaluates to a null pointer, the 31973 corresponding type is not supported; if GCC is configured to 31974 provide '<stdint.h>' in such a case, the header provided may not 31975 conform to C99, depending on the type in question. The defaults 31976 for all of these macros are null pointers. 31977 31978 -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION 31979 The C++ compiler represents a pointer-to-member-function with a 31980 struct that looks like: 31981 31982 struct { 31983 union { 31984 void (*fn)(); 31985 ptrdiff_t vtable_index; 31986 }; 31987 ptrdiff_t delta; 31988 }; 31989 31990 The C++ compiler must use one bit to indicate whether the function 31991 that will be called through a pointer-to-member-function is 31992 virtual. Normally, we assume that the low-order bit of a function 31993 pointer must always be zero. Then, by ensuring that the 31994 vtable_index is odd, we can distinguish which variant of the union 31995 is in use. But, on some platforms function pointers can be odd, 31996 and so this doesn't work. In that case, we use the low-order bit 31997 of the 'delta' field, and shift the remainder of the 'delta' field 31998 to the left. 31999 32000 GCC will automatically make the right selection about where to 32001 store this bit using the 'FUNCTION_BOUNDARY' setting for your 32002 platform. However, some platforms such as ARM/Thumb have 32003 'FUNCTION_BOUNDARY' set such that functions always start at even 32004 addresses, but the lowest bit of pointers to functions indicate 32005 whether the function at that address is in ARM or Thumb mode. If 32006 this is the case of your architecture, you should define this macro 32007 to 'ptrmemfunc_vbit_in_delta'. 32008 32009 In general, you should not have to define this macro. On 32010 architectures in which function addresses are always even, 32011 according to 'FUNCTION_BOUNDARY', GCC will automatically define 32012 this macro to 'ptrmemfunc_vbit_in_pfn'. 32013 32014 -- Macro: TARGET_VTABLE_USES_DESCRIPTORS 32015 Normally, the C++ compiler uses function pointers in vtables. This 32016 macro allows the target to change to use "function descriptors" 32017 instead. Function descriptors are found on targets for whom a 32018 function pointer is actually a small data structure. Normally the 32019 data structure consists of the actual code address plus a data 32020 pointer to which the function's data is relative. 32021 32022 If vtables are used, the value of this macro should be the number 32023 of words that the function descriptor occupies. 32024 32025 -- Macro: TARGET_VTABLE_ENTRY_ALIGN 32026 By default, the vtable entries are void pointers, the so the 32027 alignment is the same as pointer alignment. The value of this 32028 macro specifies the alignment of the vtable entry in bits. It 32029 should be defined only when special alignment is necessary. */ 32030 32031 -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE 32032 There are a few non-descriptor entries in the vtable at offsets 32033 below zero. If these entries must be padded (say, to preserve the 32034 alignment specified by 'TARGET_VTABLE_ENTRY_ALIGN'), set this to 32035 the number of words in each data entry. 32036 32037 32038File: gccint.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros 32039 3204018.7 Register Usage 32041=================== 32042 32043This section explains how to describe what registers the target machine 32044has, and how (in general) they can be used. 32045 32046 The description of which registers a specific instruction can use is 32047done with register classes; see *note Register Classes::. For 32048information on using registers to access a stack frame, see *note Frame 32049Registers::. For passing values in registers, see *note Register 32050Arguments::. For returning values in registers, see *note Scalar 32051Return::. 32052 32053* Menu: 32054 32055* Register Basics:: Number and kinds of registers. 32056* Allocation Order:: Order in which registers are allocated. 32057* Values in Registers:: What kinds of values each reg can hold. 32058* Leaf Functions:: Renumbering registers for leaf functions. 32059* Stack Registers:: Handling a register stack such as 80387. 32060 32061 32062File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers 32063 3206418.7.1 Basic Characteristics of Registers 32065----------------------------------------- 32066 32067Registers have various characteristics. 32068 32069 -- Macro: FIRST_PSEUDO_REGISTER 32070 Number of hardware registers known to the compiler. They receive 32071 numbers 0 through 'FIRST_PSEUDO_REGISTER-1'; thus, the first pseudo 32072 register's number really is assigned the number 32073 'FIRST_PSEUDO_REGISTER'. 32074 32075 -- Macro: FIXED_REGISTERS 32076 An initializer that says which registers are used for fixed 32077 purposes all throughout the compiled code and are therefore not 32078 available for general allocation. These would include the stack 32079 pointer, the frame pointer (except on machines where that can be 32080 used as a general register when no frame pointer is needed), the 32081 program counter on machines where that is considered one of the 32082 addressable registers, and any other numbered register with a 32083 standard use. 32084 32085 This information is expressed as a sequence of numbers, separated 32086 by commas and surrounded by braces. The Nth number is 1 if 32087 register N is fixed, 0 otherwise. 32088 32089 The table initialized from this macro, and the table initialized by 32090 the following one, may be overridden at run time either 32091 automatically, by the actions of the macro 32092 'CONDITIONAL_REGISTER_USAGE', or by the user with the command 32093 options '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG'. 32094 32095 -- Macro: CALL_USED_REGISTERS 32096 Like 'FIXED_REGISTERS' but has 1 for each register that is 32097 clobbered (in general) by function calls as well as for fixed 32098 registers. This macro therefore identifies the registers that are 32099 not available for general allocation of values that must live 32100 across function calls. 32101 32102 If a register has 0 in 'CALL_USED_REGISTERS', the compiler 32103 automatically saves it on function entry and restores it on 32104 function exit, if the register is used within the function. 32105 32106 -- Macro: CALL_REALLY_USED_REGISTERS 32107 Like 'CALL_USED_REGISTERS' except this macro doesn't require that 32108 the entire set of 'FIXED_REGISTERS' be included. 32109 ('CALL_USED_REGISTERS' must be a superset of 'FIXED_REGISTERS'). 32110 This macro is optional. If not specified, it defaults to the value 32111 of 'CALL_USED_REGISTERS'. 32112 32113 -- Target Hook: bool TARGET_HARD_REGNO_CALL_PART_CLOBBERED (rtx_insn 32114 *INSN, unsigned int REGNO, machine_mode MODE) 32115 This hook should return true if REGNO is partly call-saved and 32116 partly call-clobbered, and if a value of mode MODE would be partly 32117 clobbered by call instruction INSN. If INSN is NULL then it should 32118 return true if any call could partly clobber the register. For 32119 example, if the low 32 bits of REGNO are preserved across a call 32120 but higher bits are clobbered, this hook should return true for a 32121 64-bit mode but false for a 32-bit mode. 32122 32123 The default implementation returns false, which is correct for 32124 targets that don't have partly call-clobbered registers. 32125 32126 -- Target Hook: void TARGET_REMOVE_EXTRA_CALL_PRESERVED_REGS (rtx_insn 32127 *INSN, HARD_REG_SET *USED_REGS) 32128 This hook removes registers from the set of call-clobbered 32129 registers in USED_REGS if, contrary to the default rules, something 32130 guarantees that 'insn' preserves those registers. For example, 32131 some targets support variant ABIs in which functions preserve more 32132 registers than normal functions would. Removing those extra 32133 registers from USED_REGS can lead to better register allocation. 32134 32135 The default implementation does nothing, which is always safe. 32136 Defining the hook is purely an optimization. 32137 32138 -- Target Hook: rtx_insn * TARGET_RETURN_CALL_WITH_MAX_CLOBBERS 32139 (rtx_insn *CALL_1, rtx_insn *CALL_2) 32140 This hook returns a pointer to the call that partially clobbers the 32141 most registers. If a platform supports multiple ABIs where the 32142 registers that are partially clobbered may vary, this function 32143 compares two calls and returns a pointer to the one that clobbers 32144 the most registers. If both calls clobber the same registers, 32145 CALL_1 must be returned. 32146 32147 The registers clobbered in different ABIs must be a proper subset 32148 or superset of all other ABIs. CALL_1 must always be a call insn, 32149 call_2 may be NULL or a call insn. 32150 32151 -- Target Hook: const char * TARGET_GET_MULTILIB_ABI_NAME (void) 32152 This hook returns name of multilib ABI name. 32153 32154 -- Target Hook: void TARGET_CONDITIONAL_REGISTER_USAGE (void) 32155 This hook may conditionally modify five variables 'fixed_regs', 32156 'call_used_regs', 'global_regs', 'reg_names', and 32157 'reg_class_contents', to take into account any dependence of these 32158 register sets on target flags. The first three of these are of 32159 type 'char []' (interpreted as boolean vectors). 'global_regs' is 32160 a 'const char *[]', and 'reg_class_contents' is a 'HARD_REG_SET'. 32161 Before the macro is called, 'fixed_regs', 'call_used_regs', 32162 'reg_class_contents', and 'reg_names' have been initialized from 32163 'FIXED_REGISTERS', 'CALL_USED_REGISTERS', 'REG_CLASS_CONTENTS', and 32164 'REGISTER_NAMES', respectively. 'global_regs' has been cleared, 32165 and any '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG' 32166 command options have been applied. 32167 32168 If the usage of an entire class of registers depends on the target 32169 flags, you may indicate this to GCC by using this macro to modify 32170 'fixed_regs' and 'call_used_regs' to 1 for each of the registers in 32171 the classes which should not be used by GCC. Also make 32172 'define_register_constraint's return 'NO_REGS' for constraints that 32173 shouldn't be used. 32174 32175 (However, if this class is not included in 'GENERAL_REGS' and all 32176 of the insn patterns whose constraints permit this class are 32177 controlled by target switches, then GCC will automatically avoid 32178 using these registers when the target switches are opposed to 32179 them.) 32180 32181 -- Macro: INCOMING_REGNO (OUT) 32182 Define this macro if the target machine has register windows. This 32183 C expression returns the register number as seen by the called 32184 function corresponding to the register number OUT as seen by the 32185 calling function. Return OUT if register number OUT is not an 32186 outbound register. 32187 32188 -- Macro: OUTGOING_REGNO (IN) 32189 Define this macro if the target machine has register windows. This 32190 C expression returns the register number as seen by the calling 32191 function corresponding to the register number IN as seen by the 32192 called function. Return IN if register number IN is not an inbound 32193 register. 32194 32195 -- Macro: LOCAL_REGNO (REGNO) 32196 Define this macro if the target machine has register windows. This 32197 C expression returns true if the register is call-saved but is in 32198 the register window. Unlike most call-saved registers, such 32199 registers need not be explicitly restored on function exit or 32200 during non-local gotos. 32201 32202 -- Macro: PC_REGNUM 32203 If the program counter has a register number, define this as that 32204 register number. Otherwise, do not define it. 32205 32206 32207File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers 32208 3220918.7.2 Order of Allocation of Registers 32210--------------------------------------- 32211 32212Registers are allocated in order. 32213 32214 -- Macro: REG_ALLOC_ORDER 32215 If defined, an initializer for a vector of integers, containing the 32216 numbers of hard registers in the order in which GCC should prefer 32217 to use them (from most preferred to least). 32218 32219 If this macro is not defined, registers are used lowest numbered 32220 first (all else being equal). 32221 32222 One use of this macro is on machines where the highest numbered 32223 registers must always be saved and the save-multiple-registers 32224 instruction supports only sequences of consecutive registers. On 32225 such machines, define 'REG_ALLOC_ORDER' to be an initializer that 32226 lists the highest numbered allocable register first. 32227 32228 -- Macro: ADJUST_REG_ALLOC_ORDER 32229 A C statement (sans semicolon) to choose the order in which to 32230 allocate hard registers for pseudo-registers local to a basic 32231 block. 32232 32233 Store the desired register order in the array 'reg_alloc_order'. 32234 Element 0 should be the register to allocate first; element 1, the 32235 next register; and so on. 32236 32237 The macro body should not assume anything about the contents of 32238 'reg_alloc_order' before execution of the macro. 32239 32240 On most machines, it is not necessary to define this macro. 32241 32242 -- Macro: HONOR_REG_ALLOC_ORDER 32243 Normally, IRA tries to estimate the costs for saving a register in 32244 the prologue and restoring it in the epilogue. This discourages it 32245 from using call-saved registers. If a machine wants to ensure that 32246 IRA allocates registers in the order given by REG_ALLOC_ORDER even 32247 if some call-saved registers appear earlier than call-used ones, 32248 then define this macro as a C expression to nonzero. Default is 0. 32249 32250 -- Macro: IRA_HARD_REGNO_ADD_COST_MULTIPLIER (REGNO) 32251 In some case register allocation order is not enough for the 32252 Integrated Register Allocator (IRA) to generate a good code. If 32253 this macro is defined, it should return a floating point value 32254 based on REGNO. The cost of using REGNO for a pseudo will be 32255 increased by approximately the pseudo's usage frequency times the 32256 value returned by this macro. Not defining this macro is 32257 equivalent to having it always return '0.0'. 32258 32259 On most machines, it is not necessary to define this macro. 32260 32261 32262File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers 32263 3226418.7.3 How Values Fit in Registers 32265---------------------------------- 32266 32267This section discusses the macros that describe which kinds of values 32268(specifically, which machine modes) each register can hold, and how many 32269consecutive registers are needed for a given mode. 32270 32271 -- Target Hook: unsigned int TARGET_HARD_REGNO_NREGS (unsigned int 32272 REGNO, machine_mode MODE) 32273 This hook returns the number of consecutive hard registers, 32274 starting at register number REGNO, required to hold a value of mode 32275 MODE. This hook must never return zero, even if a register cannot 32276 hold the requested mode - indicate that with 32277 'TARGET_HARD_REGNO_MODE_OK' and/or 'TARGET_CAN_CHANGE_MODE_CLASS' 32278 instead. 32279 32280 The default definition returns the number of words in MODE. 32281 32282 -- Macro: HARD_REGNO_NREGS_HAS_PADDING (REGNO, MODE) 32283 A C expression that is nonzero if a value of mode MODE, stored in 32284 memory, ends with padding that causes it to take up more space than 32285 in registers starting at register number REGNO (as determined by 32286 multiplying GCC's notion of the size of the register when 32287 containing this mode by the number of registers returned by 32288 'TARGET_HARD_REGNO_NREGS'). By default this is zero. 32289 32290 For example, if a floating-point value is stored in three 32-bit 32291 registers but takes up 128 bits in memory, then this would be 32292 nonzero. 32293 32294 This macros only needs to be defined if there are cases where 32295 'subreg_get_info' would otherwise wrongly determine that a 'subreg' 32296 can be represented by an offset to the register number, when in 32297 fact such a 'subreg' would contain some of the padding not stored 32298 in registers and so not be representable. 32299 32300 -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE) 32301 For values of REGNO and MODE for which 32302 'HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression 32303 returning the greater number of registers required to hold the 32304 value including any padding. In the example above, the value would 32305 be four. 32306 32307 -- Macro: REGMODE_NATURAL_SIZE (MODE) 32308 Define this macro if the natural size of registers that hold values 32309 of mode MODE is not the word size. It is a C expression that 32310 should give the natural size in bytes for the specified mode. It 32311 is used by the register allocator to try to optimize its results. 32312 This happens for example on SPARC 64-bit where the natural size of 32313 floating-point registers is still 32-bit. 32314 32315 -- Target Hook: bool TARGET_HARD_REGNO_MODE_OK (unsigned int REGNO, 32316 machine_mode MODE) 32317 This hook returns true if it is permissible to store a value of 32318 mode MODE in hard register number REGNO (or in several registers 32319 starting with that one). The default definition returns true 32320 unconditionally. 32321 32322 You need not include code to check for the numbers of fixed 32323 registers, because the allocation mechanism considers them to be 32324 always occupied. 32325 32326 On some machines, double-precision values must be kept in even/odd 32327 register pairs. You can implement that by defining this hook to 32328 reject odd register numbers for such modes. 32329 32330 The minimum requirement for a mode to be OK in a register is that 32331 the 'movMODE' instruction pattern support moves between the 32332 register and other hard register in the same class and that moving 32333 a value into the register and back out not alter it. 32334 32335 Since the same instruction used to move 'word_mode' will work for 32336 all narrower integer modes, it is not necessary on any machine for 32337 this hook to distinguish between these modes, provided you define 32338 patterns 'movhi', etc., to take advantage of this. This is useful 32339 because of the interaction between 'TARGET_HARD_REGNO_MODE_OK' and 32340 'TARGET_MODES_TIEABLE_P'; it is very desirable for all integer 32341 modes to be tieable. 32342 32343 Many machines have special registers for floating point arithmetic. 32344 Often people assume that floating point machine modes are allowed 32345 only in floating point registers. This is not true. Any registers 32346 that can hold integers can safely _hold_ a floating point machine 32347 mode, whether or not floating arithmetic can be done on it in those 32348 registers. Integer move instructions can be used to move the 32349 values. 32350 32351 On some machines, though, the converse is true: fixed-point machine 32352 modes may not go in floating registers. This is true if the 32353 floating registers normalize any value stored in them, because 32354 storing a non-floating value there would garble it. In this case, 32355 'TARGET_HARD_REGNO_MODE_OK' should reject fixed-point machine modes 32356 in floating registers. But if the floating registers do not 32357 automatically normalize, if you can store any bit pattern in one 32358 and retrieve it unchanged without a trap, then any machine mode may 32359 go in a floating register, so you can define this hook to say so. 32360 32361 The primary significance of special floating registers is rather 32362 that they are the registers acceptable in floating point arithmetic 32363 instructions. However, this is of no concern to 32364 'TARGET_HARD_REGNO_MODE_OK'. You handle it by writing the proper 32365 constraints for those instructions. 32366 32367 On some machines, the floating registers are especially slow to 32368 access, so that it is better to store a value in a stack frame than 32369 in such a register if floating point arithmetic is not being done. 32370 As long as the floating registers are not in class 'GENERAL_REGS', 32371 they will not be used unless some pattern's constraint asks for 32372 one. 32373 32374 -- Macro: HARD_REGNO_RENAME_OK (FROM, TO) 32375 A C expression that is nonzero if it is OK to rename a hard 32376 register FROM to another hard register TO. 32377 32378 One common use of this macro is to prevent renaming of a register 32379 to another register that is not saved by a prologue in an interrupt 32380 handler. 32381 32382 The default is always nonzero. 32383 32384 -- Target Hook: bool TARGET_MODES_TIEABLE_P (machine_mode MODE1, 32385 machine_mode MODE2) 32386 This hook returns true if a value of mode MODE1 is accessible in 32387 mode MODE2 without copying. 32388 32389 If 'TARGET_HARD_REGNO_MODE_OK (R, MODE1)' and 32390 'TARGET_HARD_REGNO_MODE_OK (R, MODE2)' are always the same for any 32391 R, then 'TARGET_MODES_TIEABLE_P (MODE1, MODE2)' should be true. If 32392 they differ for any R, you should define this hook to return false 32393 unless some other mechanism ensures the accessibility of the value 32394 in a narrower mode. 32395 32396 You should define this hook to return true in as many cases as 32397 possible since doing so will allow GCC to perform better register 32398 allocation. The default definition returns true unconditionally. 32399 32400 -- Target Hook: bool TARGET_HARD_REGNO_SCRATCH_OK (unsigned int REGNO) 32401 This target hook should return 'true' if it is OK to use a hard 32402 register REGNO as scratch reg in peephole2. 32403 32404 One common use of this macro is to prevent using of a register that 32405 is not saved by a prologue in an interrupt handler. 32406 32407 The default version of this hook always returns 'true'. 32408 32409 -- Macro: AVOID_CCMODE_COPIES 32410 Define this macro if the compiler should avoid copies to/from 32411 'CCmode' registers. You should only define this macro if support 32412 for copying to/from 'CCmode' is incomplete. 32413 32414 32415File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers 32416 3241718.7.4 Handling Leaf Functions 32418------------------------------ 32419 32420On some machines, a leaf function (i.e., one which makes no calls) can 32421run more efficiently if it does not make its own register window. Often 32422this means it is required to receive its arguments in the registers 32423where they are passed by the caller, instead of the registers where they 32424would normally arrive. 32425 32426 The special treatment for leaf functions generally applies only when 32427other conditions are met; for example, often they may use only those 32428registers for its own variables and temporaries. We use the term "leaf 32429function" to mean a function that is suitable for this special handling, 32430so that functions with no calls are not necessarily "leaf functions". 32431 32432 GCC assigns register numbers before it knows whether the function is 32433suitable for leaf function treatment. So it needs to renumber the 32434registers in order to output a leaf function. The following macros 32435accomplish this. 32436 32437 -- Macro: LEAF_REGISTERS 32438 Name of a char vector, indexed by hard register number, which 32439 contains 1 for a register that is allowable in a candidate for leaf 32440 function treatment. 32441 32442 If leaf function treatment involves renumbering the registers, then 32443 the registers marked here should be the ones before 32444 renumbering--those that GCC would ordinarily allocate. The 32445 registers which will actually be used in the assembler code, after 32446 renumbering, should not be marked with 1 in this vector. 32447 32448 Define this macro only if the target machine offers a way to 32449 optimize the treatment of leaf functions. 32450 32451 -- Macro: LEAF_REG_REMAP (REGNO) 32452 A C expression whose value is the register number to which REGNO 32453 should be renumbered, when a function is treated as a leaf 32454 function. 32455 32456 If REGNO is a register number which should not appear in a leaf 32457 function before renumbering, then the expression should yield -1, 32458 which will cause the compiler to abort. 32459 32460 Define this macro only if the target machine offers a way to 32461 optimize the treatment of leaf functions, and registers need to be 32462 renumbered to do this. 32463 32464 'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE' must 32465usually treat leaf functions specially. They can test the C variable 32466'current_function_is_leaf' which is nonzero for leaf functions. 32467'current_function_is_leaf' is set prior to local register allocation and 32468is valid for the remaining compiler passes. They can also test the C 32469variable 'current_function_uses_only_leaf_regs' which is nonzero for 32470leaf functions which only use leaf registers. 32471'current_function_uses_only_leaf_regs' is valid after all passes that 32472modify the instructions have been run and is only useful if 32473'LEAF_REGISTERS' is defined. 32474 32475 32476File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers 32477 3247818.7.5 Registers That Form a Stack 32479---------------------------------- 32480 32481There are special features to handle computers where some of the 32482"registers" form a stack. Stack registers are normally written by 32483pushing onto the stack, and are numbered relative to the top of the 32484stack. 32485 32486 Currently, GCC can only handle one group of stack-like registers, and 32487they must be consecutively numbered. Furthermore, the existing support 32488for stack-like registers is specific to the 80387 floating point 32489coprocessor. If you have a new architecture that uses stack-like 32490registers, you will need to do substantial work on 'reg-stack.c' and 32491write your machine description to cooperate with it, as well as defining 32492these macros. 32493 32494 -- Macro: STACK_REGS 32495 Define this if the machine has any stack-like registers. 32496 32497 -- Macro: STACK_REG_COVER_CLASS 32498 This is a cover class containing the stack registers. Define this 32499 if the machine has any stack-like registers. 32500 32501 -- Macro: FIRST_STACK_REG 32502 The number of the first stack-like register. This one is the top 32503 of the stack. 32504 32505 -- Macro: LAST_STACK_REG 32506 The number of the last stack-like register. This one is the bottom 32507 of the stack. 32508 32509 32510File: gccint.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros 32511 3251218.8 Register Classes 32513===================== 32514 32515On many machines, the numbered registers are not all equivalent. For 32516example, certain registers may not be allowed for indexed addressing; 32517certain registers may not be allowed in some instructions. These 32518machine restrictions are described to the compiler using "register 32519classes". 32520 32521 You define a number of register classes, giving each one a name and 32522saying which of the registers belong to it. Then you can specify 32523register classes that are allowed as operands to particular instruction 32524patterns. 32525 32526 In general, each register will belong to several classes. In fact, one 32527class must be named 'ALL_REGS' and contain all the registers. Another 32528class must be named 'NO_REGS' and contain no registers. Often the union 32529of two classes will be another class; however, this is not required. 32530 32531 One of the classes must be named 'GENERAL_REGS'. There is nothing 32532terribly special about the name, but the operand constraint letters 'r' 32533and 'g' specify this class. If 'GENERAL_REGS' is the same as 32534'ALL_REGS', just define it as a macro which expands to 'ALL_REGS'. 32535 32536 Order the classes so that if class X is contained in class Y then X has 32537a lower class number than Y. 32538 32539 The way classes other than 'GENERAL_REGS' are specified in operand 32540constraints is through machine-dependent operand constraint letters. 32541You can define such letters to correspond to various classes, then use 32542them in operand constraints. 32543 32544 You must define the narrowest register classes for allocatable 32545registers, so that each class either has no subclasses, or that for some 32546mode, the move cost between registers within the class is cheaper than 32547moving a register in the class to or from memory (*note Costs::). 32548 32549 You should define a class for the union of two classes whenever some 32550instruction allows both classes. For example, if an instruction allows 32551either a floating point (coprocessor) register or a general register for 32552a certain operand, you should define a class 'FLOAT_OR_GENERAL_REGS' 32553which includes both of them. Otherwise you will get suboptimal code, or 32554even internal compiler errors when reload cannot find a register in the 32555class computed via 'reg_class_subunion'. 32556 32557 You must also specify certain redundant information about the register 32558classes: for each class, which classes contain it and which ones are 32559contained in it; for each pair of classes, the largest class contained 32560in their union. 32561 32562 When a value occupying several consecutive registers is expected in a 32563certain class, all the registers used must belong to that class. 32564Therefore, register classes cannot be used to enforce a requirement for 32565a register pair to start with an even-numbered register. The way to 32566specify this requirement is with 'TARGET_HARD_REGNO_MODE_OK'. 32567 32568 Register classes used for input-operands of bitwise-and or shift 32569instructions have a special requirement: each such class must have, for 32570each fixed-point machine mode, a subclass whose registers can transfer 32571that mode to or from memory. For example, on some machines, the 32572operations for single-byte values ('QImode') are limited to certain 32573registers. When this is so, each register class that is used in a 32574bitwise-and or shift instruction must have a subclass consisting of 32575registers from which single-byte values can be loaded or stored. This 32576is so that 'PREFERRED_RELOAD_CLASS' can always have a possible value to 32577return. 32578 32579 -- Data type: enum reg_class 32580 An enumerated type that must be defined with all the register class 32581 names as enumerated values. 'NO_REGS' must be first. 'ALL_REGS' 32582 must be the last register class, followed by one more enumerated 32583 value, 'LIM_REG_CLASSES', which is not a register class but rather 32584 tells how many classes there are. 32585 32586 Each register class has a number, which is the value of casting the 32587 class name to type 'int'. The number serves as an index in many of 32588 the tables described below. 32589 32590 -- Macro: N_REG_CLASSES 32591 The number of distinct register classes, defined as follows: 32592 32593 #define N_REG_CLASSES (int) LIM_REG_CLASSES 32594 32595 -- Macro: REG_CLASS_NAMES 32596 An initializer containing the names of the register classes as C 32597 string constants. These names are used in writing some of the 32598 debugging dumps. 32599 32600 -- Macro: REG_CLASS_CONTENTS 32601 An initializer containing the contents of the register classes, as 32602 integers which are bit masks. The Nth integer specifies the 32603 contents of class N. The way the integer MASK is interpreted is 32604 that register R is in the class if 'MASK & (1 << R)' is 1. 32605 32606 When the machine has more than 32 registers, an integer does not 32607 suffice. Then the integers are replaced by sub-initializers, 32608 braced groupings containing several integers. Each sub-initializer 32609 must be suitable as an initializer for the type 'HARD_REG_SET' 32610 which is defined in 'hard-reg-set.h'. In this situation, the first 32611 integer in each sub-initializer corresponds to registers 0 through 32612 31, the second integer to registers 32 through 63, and so on. 32613 32614 -- Macro: REGNO_REG_CLASS (REGNO) 32615 A C expression whose value is a register class containing hard 32616 register REGNO. In general there is more than one such class; 32617 choose a class which is "minimal", meaning that no smaller class 32618 also contains the register. 32619 32620 -- Macro: BASE_REG_CLASS 32621 A macro whose definition is the name of the class to which a valid 32622 base register must belong. A base register is one used in an 32623 address which is the register value plus a displacement. 32624 32625 -- Macro: MODE_BASE_REG_CLASS (MODE) 32626 This is a variation of the 'BASE_REG_CLASS' macro which allows the 32627 selection of a base register in a mode dependent manner. If MODE 32628 is VOIDmode then it should return the same value as 32629 'BASE_REG_CLASS'. 32630 32631 -- Macro: MODE_BASE_REG_REG_CLASS (MODE) 32632 A C expression whose value is the register class to which a valid 32633 base register must belong in order to be used in a base plus index 32634 register address. You should define this macro if base plus index 32635 addresses have different requirements than other base register 32636 uses. 32637 32638 -- Macro: MODE_CODE_BASE_REG_CLASS (MODE, ADDRESS_SPACE, OUTER_CODE, 32639 INDEX_CODE) 32640 A C expression whose value is the register class to which a valid 32641 base register for a memory reference in mode MODE to address space 32642 ADDRESS_SPACE must belong. OUTER_CODE and INDEX_CODE define the 32643 context in which the base register occurs. OUTER_CODE is the code 32644 of the immediately enclosing expression ('MEM' for the top level of 32645 an address, 'ADDRESS' for something that occurs in an 32646 'address_operand'). INDEX_CODE is the code of the corresponding 32647 index expression if OUTER_CODE is 'PLUS'; 'SCRATCH' otherwise. 32648 32649 -- Macro: INDEX_REG_CLASS 32650 A macro whose definition is the name of the class to which a valid 32651 index register must belong. An index register is one used in an 32652 address where its value is either multiplied by a scale factor or 32653 added to another register (as well as added to a displacement). 32654 32655 -- Macro: REGNO_OK_FOR_BASE_P (NUM) 32656 A C expression which is nonzero if register number NUM is suitable 32657 for use as a base register in operand addresses. 32658 32659 -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE) 32660 A C expression that is just like 'REGNO_OK_FOR_BASE_P', except that 32661 that expression may examine the mode of the memory reference in 32662 MODE. You should define this macro if the mode of the memory 32663 reference affects whether a register may be used as a base 32664 register. If you define this macro, the compiler will use it 32665 instead of 'REGNO_OK_FOR_BASE_P'. The mode may be 'VOIDmode' for 32666 addresses that appear outside a 'MEM', i.e., as an 32667 'address_operand'. 32668 32669 -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE) 32670 A C expression which is nonzero if register number NUM is suitable 32671 for use as a base register in base plus index operand addresses, 32672 accessing memory in mode MODE. It may be either a suitable hard 32673 register or a pseudo register that has been allocated such a hard 32674 register. You should define this macro if base plus index 32675 addresses have different requirements than other base register 32676 uses. 32677 32678 Use of this macro is deprecated; please use the more general 32679 'REGNO_MODE_CODE_OK_FOR_BASE_P'. 32680 32681 -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, ADDRESS_SPACE, 32682 OUTER_CODE, INDEX_CODE) 32683 A C expression which is nonzero if register number NUM is suitable 32684 for use as a base register in operand addresses, accessing memory 32685 in mode MODE in address space ADDRESS_SPACE. This is similar to 32686 'REGNO_MODE_OK_FOR_BASE_P', except that that expression may examine 32687 the context in which the register appears in the memory reference. 32688 OUTER_CODE is the code of the immediately enclosing expression 32689 ('MEM' if at the top level of the address, 'ADDRESS' for something 32690 that occurs in an 'address_operand'). INDEX_CODE is the code of 32691 the corresponding index expression if OUTER_CODE is 'PLUS'; 32692 'SCRATCH' otherwise. The mode may be 'VOIDmode' for addresses that 32693 appear outside a 'MEM', i.e., as an 'address_operand'. 32694 32695 -- Macro: REGNO_OK_FOR_INDEX_P (NUM) 32696 A C expression which is nonzero if register number NUM is suitable 32697 for use as an index register in operand addresses. It may be 32698 either a suitable hard register or a pseudo register that has been 32699 allocated such a hard register. 32700 32701 The difference between an index register and a base register is 32702 that the index register may be scaled. If an address involves the 32703 sum of two registers, neither one of them scaled, then either one 32704 may be labeled the "base" and the other the "index"; but whichever 32705 labeling is used must fit the machine's constraints of which 32706 registers may serve in each capacity. The compiler will try both 32707 labelings, looking for one that is valid, and will reload one or 32708 both registers only if neither labeling works. 32709 32710 -- Target Hook: reg_class_t TARGET_PREFERRED_RENAME_CLASS (reg_class_t 32711 RCLASS) 32712 A target hook that places additional preference on the register 32713 class to use when it is necessary to rename a register in class 32714 RCLASS to another class, or perhaps NO_REGS, if no preferred 32715 register class is found or hook 'preferred_rename_class' is not 32716 implemented. Sometimes returning a more restrictive class makes 32717 better code. For example, on ARM, thumb-2 instructions using 32718 'LO_REGS' may be smaller than instructions using 'GENERIC_REGS'. 32719 By returning 'LO_REGS' from 'preferred_rename_class', code size can 32720 be reduced. 32721 32722 -- Target Hook: reg_class_t TARGET_PREFERRED_RELOAD_CLASS (rtx X, 32723 reg_class_t RCLASS) 32724 A target hook that places additional restrictions on the register 32725 class to use when it is necessary to copy value X into a register 32726 in class RCLASS. The value is a register class; perhaps RCLASS, or 32727 perhaps another, smaller class. 32728 32729 The default version of this hook always returns value of 'rclass' 32730 argument. 32731 32732 Sometimes returning a more restrictive class makes better code. 32733 For example, on the 68000, when X is an integer constant that is in 32734 range for a 'moveq' instruction, the value of this macro is always 32735 'DATA_REGS' as long as RCLASS includes the data registers. 32736 Requiring a data register guarantees that a 'moveq' will be used. 32737 32738 One case where 'TARGET_PREFERRED_RELOAD_CLASS' must not return 32739 RCLASS is if X is a legitimate constant which cannot be loaded into 32740 some register class. By returning 'NO_REGS' you can force X into a 32741 memory location. For example, rs6000 can load immediate values 32742 into general-purpose registers, but does not have an instruction 32743 for loading an immediate value into a floating-point register, so 32744 'TARGET_PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a 32745 floating-point constant. If the constant can't be loaded into any 32746 kind of register, code generation will be better if 32747 'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 32748 instead of using 'TARGET_PREFERRED_RELOAD_CLASS'. 32749 32750 If an insn has pseudos in it after register allocation, reload will 32751 go through the alternatives and call repeatedly 32752 'TARGET_PREFERRED_RELOAD_CLASS' to find the best one. Returning 32753 'NO_REGS', in this case, makes reload add a '!' in front of the 32754 constraint: the x86 back-end uses this feature to discourage usage 32755 of 387 registers when math is done in the SSE registers (and vice 32756 versa). 32757 32758 -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS) 32759 A C expression that places additional restrictions on the register 32760 class to use when it is necessary to copy value X into a register 32761 in class CLASS. The value is a register class; perhaps CLASS, or 32762 perhaps another, smaller class. On many machines, the following 32763 definition is safe: 32764 32765 #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS 32766 32767 Sometimes returning a more restrictive class makes better code. 32768 For example, on the 68000, when X is an integer constant that is in 32769 range for a 'moveq' instruction, the value of this macro is always 32770 'DATA_REGS' as long as CLASS includes the data registers. 32771 Requiring a data register guarantees that a 'moveq' will be used. 32772 32773 One case where 'PREFERRED_RELOAD_CLASS' must not return CLASS is if 32774 X is a legitimate constant which cannot be loaded into some 32775 register class. By returning 'NO_REGS' you can force X into a 32776 memory location. For example, rs6000 can load immediate values 32777 into general-purpose registers, but does not have an instruction 32778 for loading an immediate value into a floating-point register, so 32779 'PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a 32780 floating-point constant. If the constant cannot be loaded into any 32781 kind of register, code generation will be better if 32782 'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 32783 instead of using 'TARGET_PREFERRED_RELOAD_CLASS'. 32784 32785 If an insn has pseudos in it after register allocation, reload will 32786 go through the alternatives and call repeatedly 32787 'PREFERRED_RELOAD_CLASS' to find the best one. Returning 32788 'NO_REGS', in this case, makes reload add a '!' in front of the 32789 constraint: the x86 back-end uses this feature to discourage usage 32790 of 387 registers when math is done in the SSE registers (and vice 32791 versa). 32792 32793 -- Target Hook: reg_class_t TARGET_PREFERRED_OUTPUT_RELOAD_CLASS (rtx 32794 X, reg_class_t RCLASS) 32795 Like 'TARGET_PREFERRED_RELOAD_CLASS', but for output reloads 32796 instead of input reloads. 32797 32798 The default version of this hook always returns value of 'rclass' 32799 argument. 32800 32801 You can also use 'TARGET_PREFERRED_OUTPUT_RELOAD_CLASS' to 32802 discourage reload from using some alternatives, like 32803 'TARGET_PREFERRED_RELOAD_CLASS'. 32804 32805 -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS) 32806 A C expression that places additional restrictions on the register 32807 class to use when it is necessary to be able to hold a value of 32808 mode MODE in a reload register for which class CLASS would 32809 ordinarily be used. 32810 32811 Unlike 'PREFERRED_RELOAD_CLASS', this macro should be used when 32812 there are certain modes that simply cannot go in certain reload 32813 classes. 32814 32815 The value is a register class; perhaps CLASS, or perhaps another, 32816 smaller class. 32817 32818 Don't define this macro unless the target machine has limitations 32819 which require the macro to do something nontrivial. 32820 32821 -- Target Hook: reg_class_t TARGET_SECONDARY_RELOAD (bool IN_P, rtx X, 32822 reg_class_t RELOAD_CLASS, machine_mode RELOAD_MODE, 32823 secondary_reload_info *SRI) 32824 Many machines have some registers that cannot be copied directly to 32825 or from memory or even from other types of registers. An example 32826 is the 'MQ' register, which on most machines, can only be copied to 32827 or from general registers, but not memory. Below, we shall be 32828 using the term 'intermediate register' when a move operation cannot 32829 be performed directly, but has to be done by copying the source 32830 into the intermediate register first, and then copying the 32831 intermediate register to the destination. An intermediate register 32832 always has the same mode as source and destination. Since it holds 32833 the actual value being copied, reload might apply optimizations to 32834 re-use an intermediate register and eliding the copy from the 32835 source when it can determine that the intermediate register still 32836 holds the required value. 32837 32838 Another kind of secondary reload is required on some machines which 32839 allow copying all registers to and from memory, but require a 32840 scratch register for stores to some memory locations (e.g., those 32841 with symbolic address on the RT, and those with certain symbolic 32842 address on the SPARC when compiling PIC). Scratch registers need 32843 not have the same mode as the value being copied, and usually hold 32844 a different value than that being copied. Special patterns in the 32845 md file are needed to describe how the copy is performed with the 32846 help of the scratch register; these patterns also describe the 32847 number, register class(es) and mode(s) of the scratch register(s). 32848 32849 In some cases, both an intermediate and a scratch register are 32850 required. 32851 32852 For input reloads, this target hook is called with nonzero IN_P, 32853 and X is an rtx that needs to be copied to a register of class 32854 RELOAD_CLASS in RELOAD_MODE. For output reloads, this target hook 32855 is called with zero IN_P, and a register of class RELOAD_CLASS 32856 needs to be copied to rtx X in RELOAD_MODE. 32857 32858 If copying a register of RELOAD_CLASS from/to X requires an 32859 intermediate register, the hook 'secondary_reload' should return 32860 the register class required for this intermediate register. If no 32861 intermediate register is required, it should return NO_REGS. If 32862 more than one intermediate register is required, describe the one 32863 that is closest in the copy chain to the reload register. 32864 32865 If scratch registers are needed, you also have to describe how to 32866 perform the copy from/to the reload register to/from this closest 32867 intermediate register. Or if no intermediate register is required, 32868 but still a scratch register is needed, describe the copy from/to 32869 the reload register to/from the reload operand X. 32870 32871 You do this by setting 'sri->icode' to the instruction code of a 32872 pattern in the md file which performs the move. Operands 0 and 1 32873 are the output and input of this copy, respectively. Operands from 32874 operand 2 onward are for scratch operands. These scratch operands 32875 must have a mode, and a single-register-class output constraint. 32876 32877 When an intermediate register is used, the 'secondary_reload' hook 32878 will be called again to determine how to copy the intermediate 32879 register to/from the reload operand X, so your hook must also have 32880 code to handle the register class of the intermediate operand. 32881 32882 X might be a pseudo-register or a 'subreg' of a pseudo-register, 32883 which could either be in a hard register or in memory. Use 32884 'true_regnum' to find out; it will return -1 if the pseudo is in 32885 memory and the hard register number if it is in a register. 32886 32887 Scratch operands in memory (constraint '"=m"' / '"=&m"') are 32888 currently not supported. For the time being, you will have to 32889 continue to use 'TARGET_SECONDARY_MEMORY_NEEDED' for that purpose. 32890 32891 'copy_cost' also uses this target hook to find out how values are 32892 copied. If you want it to include some extra cost for the need to 32893 allocate (a) scratch register(s), set 'sri->extra_cost' to the 32894 additional cost. Or if two dependent moves are supposed to have a 32895 lower cost than the sum of the individual moves due to expected 32896 fortuitous scheduling and/or special forwarding logic, you can set 32897 'sri->extra_cost' to a negative amount. 32898 32899 -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X) 32900 -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X) 32901 -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X) 32902 These macros are obsolete, new ports should use the target hook 32903 'TARGET_SECONDARY_RELOAD' instead. 32904 32905 These are obsolete macros, replaced by the 32906 'TARGET_SECONDARY_RELOAD' target hook. Older ports still define 32907 these macros to indicate to the reload phase that it may need to 32908 allocate at least one register for a reload in addition to the 32909 register to contain the data. Specifically, if copying X to a 32910 register CLASS in MODE requires an intermediate register, you were 32911 supposed to define 'SECONDARY_INPUT_RELOAD_CLASS' to return the 32912 largest register class all of whose registers can be used as 32913 intermediate registers or scratch registers. 32914 32915 If copying a register CLASS in MODE to X requires an intermediate 32916 or scratch register, 'SECONDARY_OUTPUT_RELOAD_CLASS' was supposed 32917 to be defined be defined to return the largest register class 32918 required. If the requirements for input and output reloads were 32919 the same, the macro 'SECONDARY_RELOAD_CLASS' should have been used 32920 instead of defining both macros identically. 32921 32922 The values returned by these macros are often 'GENERAL_REGS'. 32923 Return 'NO_REGS' if no spare register is needed; i.e., if X can be 32924 directly copied to or from a register of CLASS in MODE without 32925 requiring a scratch register. Do not define this macro if it would 32926 always return 'NO_REGS'. 32927 32928 If a scratch register is required (either with or without an 32929 intermediate register), you were supposed to define patterns for 32930 'reload_inM' or 'reload_outM', as required (*note Standard Names::. 32931 These patterns, which were normally implemented with a 32932 'define_expand', should be similar to the 'movM' patterns, except 32933 that operand 2 is the scratch register. 32934 32935 These patterns need constraints for the reload register and scratch 32936 register that contain a single register class. If the original 32937 reload register (whose class is CLASS) can meet the constraint 32938 given in the pattern, the value returned by these macros is used 32939 for the class of the scratch register. Otherwise, two additional 32940 reload registers are required. Their classes are obtained from the 32941 constraints in the insn pattern. 32942 32943 X might be a pseudo-register or a 'subreg' of a pseudo-register, 32944 which could either be in a hard register or in memory. Use 32945 'true_regnum' to find out; it will return -1 if the pseudo is in 32946 memory and the hard register number if it is in a register. 32947 32948 These macros should not be used in the case where a particular 32949 class of registers can only be copied to memory and not to another 32950 class of registers. In that case, secondary reload registers are 32951 not needed and would not be helpful. Instead, a stack location 32952 must be used to perform the copy and the 'movM' pattern should use 32953 memory as an intermediate storage. This case often occurs between 32954 floating-point and general registers. 32955 32956 -- Target Hook: bool TARGET_SECONDARY_MEMORY_NEEDED (machine_mode MODE, 32957 reg_class_t CLASS1, reg_class_t CLASS2) 32958 Certain machines have the property that some registers cannot be 32959 copied to some other registers without using memory. Define this 32960 hook on those machines to return true if objects of mode M in 32961 registers of CLASS1 can only be copied to registers of class CLASS2 32962 by storing a register of CLASS1 into memory and loading that memory 32963 location into a register of CLASS2. The default definition returns 32964 false for all inputs. 32965 32966 -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE) 32967 Normally when 'TARGET_SECONDARY_MEMORY_NEEDED' is defined, the 32968 compiler allocates a stack slot for a memory location needed for 32969 register copies. If this macro is defined, the compiler instead 32970 uses the memory location defined by this macro. 32971 32972 Do not define this macro if you do not define 32973 'TARGET_SECONDARY_MEMORY_NEEDED'. 32974 32975 -- Target Hook: machine_mode TARGET_SECONDARY_MEMORY_NEEDED_MODE 32976 (machine_mode MODE) 32977 If 'TARGET_SECONDARY_MEMORY_NEEDED' tells the compiler to use 32978 memory when moving between two particular registers of mode MODE, 32979 this hook specifies the mode that the memory should have. 32980 32981 The default depends on 'TARGET_LRA_P'. Without LRA, the default is 32982 to use a word-sized mode for integral modes that are smaller than a 32983 a word. This is right thing to do on most machines because it 32984 ensures that all bits of the register are copied and prevents 32985 accesses to the registers in a narrower mode, which some machines 32986 prohibit for floating-point registers. 32987 32988 However, this default behavior is not correct on some machines, 32989 such as the DEC Alpha, that store short integers in floating-point 32990 registers differently than in integer registers. On those 32991 machines, the default widening will not work correctly and you must 32992 define this hook to suppress that widening in some cases. See the 32993 file 'alpha.c' for details. 32994 32995 With LRA, the default is to use MODE unmodified. 32996 32997 -- Target Hook: void TARGET_SELECT_EARLY_REMAT_MODES (sbitmap MODES) 32998 On some targets, certain modes cannot be held in registers around a 32999 standard ABI call and are relatively expensive to spill to the 33000 stack. The early rematerialization pass can help in such cases by 33001 aggressively recomputing values after calls, so that they don't 33002 need to be spilled. 33003 33004 This hook returns the set of such modes by setting the associated 33005 bits in MODES. The default implementation selects no modes, which 33006 has the effect of disabling the early rematerialization pass. 33007 33008 -- Target Hook: bool TARGET_CLASS_LIKELY_SPILLED_P (reg_class_t RCLASS) 33009 A target hook which returns 'true' if pseudos that have been 33010 assigned to registers of class RCLASS would likely be spilled 33011 because registers of RCLASS are needed for spill registers. 33012 33013 The default version of this target hook returns 'true' if RCLASS 33014 has exactly one register and 'false' otherwise. On most machines, 33015 this default should be used. For generally register-starved 33016 machines, such as i386, or machines with right register 33017 constraints, such as SH, this hook can be used to avoid excessive 33018 spilling. 33019 33020 This hook is also used by some of the global intra-procedural code 33021 transformations to throtle code motion, to avoid increasing 33022 register pressure. 33023 33024 -- Target Hook: unsigned char TARGET_CLASS_MAX_NREGS (reg_class_t 33025 RCLASS, machine_mode MODE) 33026 A target hook returns the maximum number of consecutive registers 33027 of class RCLASS needed to hold a value of mode MODE. 33028 33029 This is closely related to the macro 'TARGET_HARD_REGNO_NREGS'. In 33030 fact, the value returned by 'TARGET_CLASS_MAX_NREGS (RCLASS, MODE)' 33031 target hook should be the maximum value of 'TARGET_HARD_REGNO_NREGS 33032 (REGNO, MODE)' for all REGNO values in the class RCLASS. 33033 33034 This target hook helps control the handling of multiple-word values 33035 in the reload pass. 33036 33037 The default version of this target hook returns the size of MODE in 33038 words. 33039 33040 -- Macro: CLASS_MAX_NREGS (CLASS, MODE) 33041 A C expression for the maximum number of consecutive registers of 33042 class CLASS needed to hold a value of mode MODE. 33043 33044 This is closely related to the macro 'TARGET_HARD_REGNO_NREGS'. In 33045 fact, the value of the macro 'CLASS_MAX_NREGS (CLASS, MODE)' should 33046 be the maximum value of 'TARGET_HARD_REGNO_NREGS (REGNO, MODE)' for 33047 all REGNO values in the class CLASS. 33048 33049 This macro helps control the handling of multiple-word values in 33050 the reload pass. 33051 33052 -- Target Hook: bool TARGET_CAN_CHANGE_MODE_CLASS (machine_mode FROM, 33053 machine_mode TO, reg_class_t RCLASS) 33054 This hook returns true if it is possible to bitcast values held in 33055 registers of class RCLASS from mode FROM to mode TO and if doing so 33056 preserves the low-order bits that are common to both modes. The 33057 result is only meaningful if RCLASS has registers that can hold 33058 both 'from' and 'to'. The default implementation returns true. 33059 33060 As an example of when such bitcasting is invalid, loading 32-bit 33061 integer or floating-point objects into floating-point registers on 33062 Alpha extends them to 64 bits. Therefore loading a 64-bit object 33063 and then storing it as a 32-bit object does not store the low-order 33064 32 bits, as would be the case for a normal register. Therefore, 33065 'alpha.h' defines 'TARGET_CAN_CHANGE_MODE_CLASS' to return: 33066 33067 (GET_MODE_SIZE (from) == GET_MODE_SIZE (to) 33068 || !reg_classes_intersect_p (FLOAT_REGS, rclass)) 33069 33070 Even if storing from a register in mode TO would be valid, if both 33071 FROM and 'raw_reg_mode' for RCLASS are wider than 'word_mode', then 33072 we must prevent TO narrowing the mode. This happens when the 33073 middle-end assumes that it can load or store pieces of an N-word 33074 pseudo, and that the pseudo will eventually be allocated to N 33075 'word_mode' hard registers. Failure to prevent this kind of mode 33076 change will result in the entire 'raw_reg_mode' being modified 33077 instead of the partial value that the middle-end intended. 33078 33079 -- Target Hook: reg_class_t TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS 33080 (int, REG_CLASS_T, REG_CLASS_T) 33081 A target hook which can change allocno class for given pseudo from 33082 allocno and best class calculated by IRA. 33083 33084 The default version of this target hook always returns given class. 33085 33086 -- Target Hook: bool TARGET_LRA_P (void) 33087 A target hook which returns true if we use LRA instead of reload 33088 pass. The default version of this target hook returns true. New 33089 ports should use LRA, and existing ports are encouraged to convert. 33090 33091 -- Target Hook: int TARGET_REGISTER_PRIORITY (int) 33092 A target hook which returns the register priority number to which 33093 the register HARD_REGNO belongs to. The bigger the number, the 33094 more preferable the hard register usage (when all other conditions 33095 are the same). This hook can be used to prefer some hard register 33096 over others in LRA. For example, some x86-64 register usage needs 33097 additional prefix which makes instructions longer. The hook can 33098 return lower priority number for such registers make them less 33099 favorable and as result making the generated code smaller. The 33100 default version of this target hook returns always zero. 33101 33102 -- Target Hook: bool TARGET_REGISTER_USAGE_LEVELING_P (void) 33103 A target hook which returns true if we need register usage 33104 leveling. That means if a few hard registers are equally good for 33105 the assignment, we choose the least used hard register. The 33106 register usage leveling may be profitable for some targets. Don't 33107 use the usage leveling for targets with conditional execution or 33108 targets with big register files as it hurts if-conversion and 33109 cross-jumping optimizations. The default version of this target 33110 hook returns always false. 33111 33112 -- Target Hook: bool TARGET_DIFFERENT_ADDR_DISPLACEMENT_P (void) 33113 A target hook which returns true if an address with the same 33114 structure can have different maximal legitimate displacement. For 33115 example, the displacement can depend on memory mode or on operand 33116 combinations in the insn. The default version of this target hook 33117 returns always false. 33118 33119 -- Target Hook: bool TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P (rtx SUBST) 33120 A target hook which returns 'true' if SUBST can't substitute safely 33121 pseudos with equivalent memory values during register allocation. 33122 The default version of this target hook returns 'false'. On most 33123 machines, this default should be used. For generally machines with 33124 non orthogonal register usage for addressing, such as SH, this hook 33125 can be used to avoid excessive spilling. 33126 33127 -- Target Hook: bool TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT (rtx 33128 *OFFSET1, rtx *OFFSET2, poly_int64 ORIG_OFFSET, machine_mode 33129 MODE) 33130 This hook tries to split address offset ORIG_OFFSET into two parts: 33131 one that should be added to the base address to create a local 33132 anchor point, and an additional offset that can be applied to the 33133 anchor to address a value of mode MODE. The idea is that the local 33134 anchor could be shared by other accesses to nearby locations. 33135 33136 The hook returns true if it succeeds, storing the offset of the 33137 anchor from the base in OFFSET1 and the offset of the final address 33138 from the anchor in OFFSET2. The default implementation returns 33139 false. 33140 33141 -- Target Hook: reg_class_t TARGET_SPILL_CLASS (reg_class_t, 33142 MACHINE_MODE) 33143 This hook defines a class of registers which could be used for 33144 spilling pseudos of the given mode and class, or 'NO_REGS' if only 33145 memory should be used. Not defining this hook is equivalent to 33146 returning 'NO_REGS' for all inputs. 33147 33148 -- Target Hook: bool TARGET_ADDITIONAL_ALLOCNO_CLASS_P (reg_class_t) 33149 This hook should return 'true' if given class of registers should 33150 be an allocno class in any way. Usually RA uses only one register 33151 class from all classes containing the same register set. In some 33152 complicated cases, you need to have two or more such classes as 33153 allocno ones for RA correct work. Not defining this hook is 33154 equivalent to returning 'false' for all inputs. 33155 33156 -- Target Hook: scalar_int_mode TARGET_CSTORE_MODE (enum insn_code 33157 ICODE) 33158 This hook defines the machine mode to use for the boolean result of 33159 conditional store patterns. The ICODE argument is the instruction 33160 code for the cstore being performed. Not definiting this hook is 33161 the same as accepting the mode encoded into operand 0 of the cstore 33162 expander patterns. 33163 33164 -- Target Hook: int TARGET_COMPUTE_PRESSURE_CLASSES (enum reg_class 33165 *PRESSURE_CLASSES) 33166 A target hook which lets a backend compute the set of pressure 33167 classes to be used by those optimization passes which take register 33168 pressure into account, as opposed to letting IRA compute them. It 33169 returns the number of register classes stored in the array 33170 PRESSURE_CLASSES. 33171 33172 33173File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros 33174 3317518.9 Stack Layout and Calling Conventions 33176========================================= 33177 33178This describes the stack layout and calling conventions. 33179 33180* Menu: 33181 33182* Frame Layout:: 33183* Exception Handling:: 33184* Stack Checking:: 33185* Frame Registers:: 33186* Elimination:: 33187* Stack Arguments:: 33188* Register Arguments:: 33189* Scalar Return:: 33190* Aggregate Return:: 33191* Caller Saves:: 33192* Function Entry:: 33193* Profiling:: 33194* Tail Calls:: 33195* Shrink-wrapping separate components:: 33196* Stack Smashing Protection:: 33197* Miscellaneous Register Hooks:: 33198 33199 33200File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling 33201 3320218.9.1 Basic Stack Layout 33203------------------------- 33204 33205Here is the basic stack layout. 33206 33207 -- Macro: STACK_GROWS_DOWNWARD 33208 Define this macro to be true if pushing a word onto the stack moves 33209 the stack pointer to a smaller address, and false otherwise. 33210 33211 -- Macro: STACK_PUSH_CODE 33212 This macro defines the operation used when something is pushed on 33213 the stack. In RTL, a push operation will be '(set (mem 33214 (STACK_PUSH_CODE (reg sp))) ...)' 33215 33216 The choices are 'PRE_DEC', 'POST_DEC', 'PRE_INC', and 'POST_INC'. 33217 Which of these is correct depends on the stack direction and on 33218 whether the stack pointer points to the last item on the stack or 33219 whether it points to the space for the next item on the stack. 33220 33221 The default is 'PRE_DEC' when 'STACK_GROWS_DOWNWARD' is true, which 33222 is almost always right, and 'PRE_INC' otherwise, which is often 33223 wrong. 33224 33225 -- Macro: FRAME_GROWS_DOWNWARD 33226 Define this macro to nonzero value if the addresses of local 33227 variable slots are at negative offsets from the frame pointer. 33228 33229 -- Macro: ARGS_GROW_DOWNWARD 33230 Define this macro if successive arguments to a function occupy 33231 decreasing addresses on the stack. 33232 33233 -- Target Hook: HOST_WIDE_INT TARGET_STARTING_FRAME_OFFSET (void) 33234 This hook returns the offset from the frame pointer to the first 33235 local variable slot to be allocated. If 'FRAME_GROWS_DOWNWARD', it 33236 is the offset to _end_ of the first slot allocated, otherwise it is 33237 the offset to _beginning_ of the first slot allocated. The default 33238 implementation returns 0. 33239 33240 -- Macro: STACK_ALIGNMENT_NEEDED 33241 Define to zero to disable final alignment of the stack during 33242 reload. The nonzero default for this macro is suitable for most 33243 ports. 33244 33245 On ports where 'TARGET_STARTING_FRAME_OFFSET' is nonzero or where 33246 there is a register save block following the local block that 33247 doesn't require alignment to 'STACK_BOUNDARY', it may be beneficial 33248 to disable stack alignment and do it in the backend. 33249 33250 -- Macro: STACK_POINTER_OFFSET 33251 Offset from the stack pointer register to the first location at 33252 which outgoing arguments are placed. If not specified, the default 33253 value of zero is used. This is the proper value for most machines. 33254 33255 If 'ARGS_GROW_DOWNWARD', this is the offset to the location above 33256 the first location at which outgoing arguments are placed. 33257 33258 -- Macro: FIRST_PARM_OFFSET (FUNDECL) 33259 Offset from the argument pointer register to the first argument's 33260 address. On some machines it may depend on the data type of the 33261 function. 33262 33263 If 'ARGS_GROW_DOWNWARD', this is the offset to the location above 33264 the first argument's address. 33265 33266 -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL) 33267 Offset from the stack pointer register to an item dynamically 33268 allocated on the stack, e.g., by 'alloca'. 33269 33270 The default value for this macro is 'STACK_POINTER_OFFSET' plus the 33271 length of the outgoing arguments. The default is correct for most 33272 machines. See 'function.c' for details. 33273 33274 -- Macro: INITIAL_FRAME_ADDRESS_RTX 33275 A C expression whose value is RTL representing the address of the 33276 initial stack frame. This address is passed to 'RETURN_ADDR_RTX' 33277 and 'DYNAMIC_CHAIN_ADDRESS'. If you don't define this macro, a 33278 reasonable default value will be used. Define this macro in order 33279 to make frame pointer elimination work in the presence of 33280 '__builtin_frame_address (count)' and '__builtin_return_address 33281 (count)' for 'count' not equal to zero. 33282 33283 -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR) 33284 A C expression whose value is RTL representing the address in a 33285 stack frame where the pointer to the caller's frame is stored. 33286 Assume that FRAMEADDR is an RTL expression for the address of the 33287 stack frame itself. 33288 33289 If you don't define this macro, the default is to return the value 33290 of FRAMEADDR--that is, the stack frame address is also the address 33291 of the stack word that points to the previous frame. 33292 33293 -- Macro: SETUP_FRAME_ADDRESSES 33294 A C expression that produces the machine-specific code to setup the 33295 stack so that arbitrary frames can be accessed. For example, on 33296 the SPARC, we must flush all of the register windows to the stack 33297 before we can access arbitrary stack frames. You will seldom need 33298 to define this macro. The default is to do nothing. 33299 33300 -- Target Hook: rtx TARGET_BUILTIN_SETJMP_FRAME_VALUE (void) 33301 This target hook should return an rtx that is used to store the 33302 address of the current frame into the built in 'setjmp' buffer. 33303 The default value, 'virtual_stack_vars_rtx', is correct for most 33304 machines. One reason you may need to define this target hook is if 33305 'hard_frame_pointer_rtx' is the appropriate value on your machine. 33306 33307 -- Macro: FRAME_ADDR_RTX (FRAMEADDR) 33308 A C expression whose value is RTL representing the value of the 33309 frame address for the current frame. FRAMEADDR is the frame 33310 pointer of the current frame. This is used for 33311 __builtin_frame_address. You need only define this macro if the 33312 frame address is not the same as the frame pointer. Most machines 33313 do not need to define it. 33314 33315 -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR) 33316 A C expression whose value is RTL representing the value of the 33317 return address for the frame COUNT steps up from the current frame, 33318 after the prologue. FRAMEADDR is the frame pointer of the COUNT 33319 frame, or the frame pointer of the COUNT - 1 frame if 33320 'RETURN_ADDR_IN_PREVIOUS_FRAME' is nonzero. 33321 33322 The value of the expression must always be the correct address when 33323 COUNT is zero, but may be 'NULL_RTX' if there is no way to 33324 determine the return address of other frames. 33325 33326 -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME 33327 Define this macro to nonzero value if the return address of a 33328 particular stack frame is accessed from the frame pointer of the 33329 previous stack frame. The zero default for this macro is suitable 33330 for most ports. 33331 33332 -- Macro: INCOMING_RETURN_ADDR_RTX 33333 A C expression whose value is RTL representing the location of the 33334 incoming return address at the beginning of any function, before 33335 the prologue. This RTL is either a 'REG', indicating that the 33336 return value is saved in 'REG', or a 'MEM' representing a location 33337 in the stack. 33338 33339 You only need to define this macro if you want to support call 33340 frame debugging information like that provided by DWARF 2. 33341 33342 If this RTL is a 'REG', you should also define 33343 'DWARF_FRAME_RETURN_COLUMN' to 'DWARF_FRAME_REGNUM (REGNO)'. 33344 33345 -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN 33346 A C expression whose value is an integer giving a DWARF 2 column 33347 number that may be used as an alternative return column. The 33348 column must not correspond to any gcc hard register (that is, it 33349 must not be in the range of 'DWARF_FRAME_REGNUM'). 33350 33351 This macro can be useful if 'DWARF_FRAME_RETURN_COLUMN' is set to a 33352 general register, but an alternative column needs to be used for 33353 signal frames. Some targets have also used different frame return 33354 columns over time. 33355 33356 -- Macro: DWARF_ZERO_REG 33357 A C expression whose value is an integer giving a DWARF 2 register 33358 number that is considered to always have the value zero. This 33359 should only be defined if the target has an architected zero 33360 register, and someone decided it was a good idea to use that 33361 register number to terminate the stack backtrace. New ports should 33362 avoid this. 33363 33364 -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char 33365 *LABEL, rtx PATTERN, int INDEX) 33366 This target hook allows the backend to emit frame-related insns 33367 that contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame 33368 debugging info engine will invoke it on insns of the form 33369 (set (reg) (unspec [...] UNSPEC_INDEX)) 33370 and 33371 (set (reg) (unspec_volatile [...] UNSPECV_INDEX)). 33372 to let the backend emit the call frame instructions. LABEL is the 33373 CFI label attached to the insn, PATTERN is the pattern of the insn 33374 and INDEX is 'UNSPEC_INDEX' or 'UNSPECV_INDEX'. 33375 33376 -- Target Hook: unsigned int TARGET_DWARF_POLY_INDETERMINATE_VALUE 33377 (unsigned int I, unsigned int *FACTOR, int *OFFSET) 33378 Express the value of 'poly_int' indeterminate I as a DWARF 33379 expression, with I counting from 1. Return the number of a DWARF 33380 register R and set '*FACTOR' and '*OFFSET' such that the value of 33381 the indeterminate is: 33382 value_of(R) / FACTOR - OFFSET 33383 33384 A target only needs to define this hook if it sets 33385 'NUM_POLY_INT_COEFFS' to a value greater than 1. 33386 33387 -- Macro: INCOMING_FRAME_SP_OFFSET 33388 A C expression whose value is an integer giving the offset, in 33389 bytes, from the value of the stack pointer register to the top of 33390 the stack frame at the beginning of any function, before the 33391 prologue. The top of the frame is defined to be the value of the 33392 stack pointer in the previous frame, just before the call 33393 instruction. 33394 33395 You only need to define this macro if you want to support call 33396 frame debugging information like that provided by DWARF 2. 33397 33398 -- Macro: DEFAULT_INCOMING_FRAME_SP_OFFSET 33399 Like 'INCOMING_FRAME_SP_OFFSET', but must be the same for all 33400 functions of the same ABI, and when using GAS '.cfi_*' directives 33401 must also agree with the default CFI GAS emits. Define this macro 33402 only if 'INCOMING_FRAME_SP_OFFSET' can have different values 33403 between different functions of the same ABI or when 33404 'INCOMING_FRAME_SP_OFFSET' does not agree with GAS default CFI. 33405 33406 -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL) 33407 A C expression whose value is an integer giving the offset, in 33408 bytes, from the argument pointer to the canonical frame address 33409 (cfa). The final value should coincide with that calculated by 33410 'INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable 33411 during virtual register instantiation. 33412 33413 The default value for this macro is 'FIRST_PARM_OFFSET (fundecl) + 33414 crtl->args.pretend_args_size', which is correct for most machines; 33415 in general, the arguments are found immediately before the stack 33416 frame. Note that this is not the case on some targets that save 33417 registers into the caller's frame, such as SPARC and rs6000, and so 33418 such targets need to define this macro. 33419 33420 You only need to define this macro if the default is incorrect, and 33421 you want to support call frame debugging information like that 33422 provided by DWARF 2. 33423 33424 -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL) 33425 If defined, a C expression whose value is an integer giving the 33426 offset in bytes from the frame pointer to the canonical frame 33427 address (cfa). The final value should coincide with that 33428 calculated by 'INCOMING_FRAME_SP_OFFSET'. 33429 33430 Normally the CFA is calculated as an offset from the argument 33431 pointer, via 'ARG_POINTER_CFA_OFFSET', but if the argument pointer 33432 is variable due to the ABI, this may not be possible. If this 33433 macro is defined, it implies that the virtual register 33434 instantiation should be based on the frame pointer instead of the 33435 argument pointer. Only one of 'FRAME_POINTER_CFA_OFFSET' and 33436 'ARG_POINTER_CFA_OFFSET' should be defined. 33437 33438 -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL) 33439 If defined, a C expression whose value is an integer giving the 33440 offset in bytes from the canonical frame address (cfa) to the frame 33441 base used in DWARF 2 debug information. The default is zero. A 33442 different value may reduce the size of debug information on some 33443 ports. 33444 33445 33446File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling 33447 3344818.9.2 Exception Handling Support 33449--------------------------------- 33450 33451 -- Macro: EH_RETURN_DATA_REGNO (N) 33452 A C expression whose value is the Nth register number used for data 33453 by exception handlers, or 'INVALID_REGNUM' if fewer than N 33454 registers are usable. 33455 33456 The exception handling library routines communicate with the 33457 exception handlers via a set of agreed upon registers. Ideally 33458 these registers should be call-clobbered; it is possible to use 33459 call-saved registers, but may negatively impact code size. The 33460 target must support at least 2 data registers, but should define 4 33461 if there are enough free registers. 33462 33463 You must define this macro if you want to support call frame 33464 exception handling like that provided by DWARF 2. 33465 33466 -- Macro: EH_RETURN_STACKADJ_RTX 33467 A C expression whose value is RTL representing a location in which 33468 to store a stack adjustment to be applied before function return. 33469 This is used to unwind the stack to an exception handler's call 33470 frame. It will be assigned zero on code paths that return 33471 normally. 33472 33473 Typically this is a call-clobbered hard register that is otherwise 33474 untouched by the epilogue, but could also be a stack slot. 33475 33476 Do not define this macro if the stack pointer is saved and restored 33477 by the regular prolog and epilog code in the call frame itself; in 33478 this case, the exception handling library routines will update the 33479 stack location to be restored in place. Otherwise, you must define 33480 this macro if you want to support call frame exception handling 33481 like that provided by DWARF 2. 33482 33483 -- Macro: EH_RETURN_HANDLER_RTX 33484 A C expression whose value is RTL representing a location in which 33485 to store the address of an exception handler to which we should 33486 return. It will not be assigned on code paths that return 33487 normally. 33488 33489 Typically this is the location in the call frame at which the 33490 normal return address is stored. For targets that return by 33491 popping an address off the stack, this might be a memory address 33492 just below the _target_ call frame rather than inside the current 33493 call frame. If defined, 'EH_RETURN_STACKADJ_RTX' will have already 33494 been assigned, so it may be used to calculate the location of the 33495 target call frame. 33496 33497 Some targets have more complex requirements than storing to an 33498 address calculable during initial code generation. In that case 33499 the 'eh_return' instruction pattern should be used instead. 33500 33501 If you want to support call frame exception handling, you must 33502 define either this macro or the 'eh_return' instruction pattern. 33503 33504 -- Macro: RETURN_ADDR_OFFSET 33505 If defined, an integer-valued C expression for which rtl will be 33506 generated to add it to the exception handler address before it is 33507 searched in the exception handling tables, and to subtract it again 33508 from the address before using it to return to the exception 33509 handler. 33510 33511 -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL) 33512 This macro chooses the encoding of pointers embedded in the 33513 exception handling sections. If at all possible, this should be 33514 defined such that the exception handling section will not require 33515 dynamic relocations, and so may be read-only. 33516 33517 CODE is 0 for data, 1 for code labels, 2 for function pointers. 33518 GLOBAL is true if the symbol may be affected by dynamic 33519 relocations. The macro should return a combination of the 33520 'DW_EH_PE_*' defines as found in 'dwarf2.h'. 33521 33522 If this macro is not defined, pointers will not be encoded but 33523 represented directly. 33524 33525 -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE, 33526 ADDR, DONE) 33527 This macro allows the target to emit whatever special magic is 33528 required to represent the encoding chosen by 33529 'ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of 33530 pc-relative and indirect encodings; this must be defined if the 33531 target uses text-relative or data-relative encodings. 33532 33533 This is a C statement that branches to DONE if the format was 33534 handled. ENCODING is the format chosen, SIZE is the number of 33535 bytes that the format occupies, ADDR is the 'SYMBOL_REF' to be 33536 emitted. 33537 33538 -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS) 33539 This macro allows the target to add CPU and operating system 33540 specific code to the call-frame unwinder for use when there is no 33541 unwind data available. The most common reason to implement this 33542 macro is to unwind through signal frames. 33543 33544 This macro is called from 'uw_frame_state_for' in 'unwind-dw2.c', 33545 'unwind-dw2-xtensa.c' and 'unwind-ia64.c'. CONTEXT is an 33546 '_Unwind_Context'; FS is an '_Unwind_FrameState'. Examine 33547 'context->ra' for the address of the code being executed and 33548 'context->cfa' for the stack pointer value. If the frame can be 33549 decoded, the register save addresses should be updated in FS and 33550 the macro should evaluate to '_URC_NO_REASON'. If the frame cannot 33551 be decoded, the macro should evaluate to '_URC_END_OF_STACK'. 33552 33553 For proper signal handling in Java this macro is accompanied by 33554 'MAKE_THROW_FRAME', defined in 'libjava/include/*-signal.h' 33555 headers. 33556 33557 -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS) 33558 This macro allows the target to add operating system specific code 33559 to the call-frame unwinder to handle the IA-64 '.unwabi' unwinding 33560 directive, usually used for signal or interrupt frames. 33561 33562 This macro is called from 'uw_update_context' in libgcc's 33563 'unwind-ia64.c'. CONTEXT is an '_Unwind_Context'; FS is an 33564 '_Unwind_FrameState'. Examine 'fs->unwabi' for the abi and context 33565 in the '.unwabi' directive. If the '.unwabi' directive can be 33566 handled, the register save addresses should be updated in FS. 33567 33568 -- Macro: TARGET_USES_WEAK_UNWIND_INFO 33569 A C expression that evaluates to true if the target requires unwind 33570 info to be given comdat linkage. Define it to be '1' if comdat 33571 linkage is necessary. The default is '0'. 33572 33573 33574File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling 33575 3357618.9.3 Specifying How Stack Checking is Done 33577-------------------------------------------- 33578 33579GCC will check that stack references are within the boundaries of the 33580stack, if the option '-fstack-check' is specified, in one of three ways: 33581 33582 1. If the value of the 'STACK_CHECK_BUILTIN' macro is nonzero, GCC 33583 will assume that you have arranged for full stack checking to be 33584 done at appropriate places in the configuration files. GCC will 33585 not do other special processing. 33586 33587 2. If 'STACK_CHECK_BUILTIN' is zero and the value of the 33588 'STACK_CHECK_STATIC_BUILTIN' macro is nonzero, GCC will assume that 33589 you have arranged for static stack checking (checking of the static 33590 stack frame of functions) to be done at appropriate places in the 33591 configuration files. GCC will only emit code to do dynamic stack 33592 checking (checking on dynamic stack allocations) using the third 33593 approach below. 33594 33595 3. If neither of the above are true, GCC will generate code to 33596 periodically "probe" the stack pointer using the values of the 33597 macros defined below. 33598 33599 If neither STACK_CHECK_BUILTIN nor STACK_CHECK_STATIC_BUILTIN is 33600defined, GCC will change its allocation strategy for large objects if 33601the option '-fstack-check' is specified: they will always be allocated 33602dynamically if their size exceeds 'STACK_CHECK_MAX_VAR_SIZE' bytes. 33603 33604 -- Macro: STACK_CHECK_BUILTIN 33605 A nonzero value if stack checking is done by the configuration 33606 files in a machine-dependent manner. You should define this macro 33607 if stack checking is required by the ABI of your machine or if you 33608 would like to do stack checking in some more efficient way than the 33609 generic approach. The default value of this macro is zero. 33610 33611 -- Macro: STACK_CHECK_STATIC_BUILTIN 33612 A nonzero value if static stack checking is done by the 33613 configuration files in a machine-dependent manner. You should 33614 define this macro if you would like to do static stack checking in 33615 some more efficient way than the generic approach. The default 33616 value of this macro is zero. 33617 33618 -- Macro: STACK_CHECK_PROBE_INTERVAL_EXP 33619 An integer specifying the interval at which GCC must generate stack 33620 probe instructions, defined as 2 raised to this integer. You will 33621 normally define this macro so that the interval be no larger than 33622 the size of the "guard pages" at the end of a stack area. The 33623 default value of 12 (4096-byte interval) is suitable for most 33624 systems. 33625 33626 -- Macro: STACK_CHECK_MOVING_SP 33627 An integer which is nonzero if GCC should move the stack pointer 33628 page by page when doing probes. This can be necessary on systems 33629 where the stack pointer contains the bottom address of the memory 33630 area accessible to the executing thread at any point in time. In 33631 this situation an alternate signal stack is required in order to be 33632 able to recover from a stack overflow. The default value of this 33633 macro is zero. 33634 33635 -- Macro: STACK_CHECK_PROTECT 33636 The number of bytes of stack needed to recover from a stack 33637 overflow, for languages where such a recovery is supported. The 33638 default value of 4KB/8KB with the 'setjmp'/'longjmp'-based 33639 exception handling mechanism and 8KB/12KB with other exception 33640 handling mechanisms should be adequate for most architectures and 33641 operating systems. 33642 33643 The following macros are relevant only if neither STACK_CHECK_BUILTIN 33644nor STACK_CHECK_STATIC_BUILTIN is defined; you can omit them altogether 33645in the opposite case. 33646 33647 -- Macro: STACK_CHECK_MAX_FRAME_SIZE 33648 The maximum size of a stack frame, in bytes. GCC will generate 33649 probe instructions in non-leaf functions to ensure at least this 33650 many bytes of stack are available. If a stack frame is larger than 33651 this size, stack checking will not be reliable and GCC will issue a 33652 warning. The default is chosen so that GCC only generates one 33653 instruction on most systems. You should normally not change the 33654 default value of this macro. 33655 33656 -- Macro: STACK_CHECK_FIXED_FRAME_SIZE 33657 GCC uses this value to generate the above warning message. It 33658 represents the amount of fixed frame used by a function, not 33659 including space for any callee-saved registers, temporaries and 33660 user variables. You need only specify an upper bound for this 33661 amount and will normally use the default of four words. 33662 33663 -- Macro: STACK_CHECK_MAX_VAR_SIZE 33664 The maximum size, in bytes, of an object that GCC will place in the 33665 fixed area of the stack frame when the user specifies 33666 '-fstack-check'. GCC computed the default from the values of the 33667 above macros and you will normally not need to override that 33668 default. 33669 33670 -- Target Hook: HOST_WIDE_INT 33671 TARGET_STACK_CLASH_PROTECTION_ALLOCA_PROBE_RANGE (void) 33672 Some targets have an ABI defined interval for which no probing 33673 needs to be done. When a probe does need to be done this same 33674 interval is used as the probe distance up when doing stack clash 33675 protection for alloca. On such targets this value can be set to 33676 override the default probing up interval. Define this variable to 33677 return nonzero if such a probe range is required or zero otherwise. 33678 Defining this hook also requires your functions which make use of 33679 alloca to have at least 8 byesof outgoing arguments. If this is 33680 not the case the stack will be corrupted. You need not define this 33681 macro if it would always have the value zero. 33682 33683 33684File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling 33685 3368618.9.4 Registers That Address the Stack Frame 33687--------------------------------------------- 33688 33689This discusses registers that address the stack frame. 33690 33691 -- Macro: STACK_POINTER_REGNUM 33692 The register number of the stack pointer register, which must also 33693 be a fixed register according to 'FIXED_REGISTERS'. On most 33694 machines, the hardware determines which register this is. 33695 33696 -- Macro: FRAME_POINTER_REGNUM 33697 The register number of the frame pointer register, which is used to 33698 access automatic variables in the stack frame. On some machines, 33699 the hardware determines which register this is. On other machines, 33700 you can choose any register you wish for this purpose. 33701 33702 -- Macro: HARD_FRAME_POINTER_REGNUM 33703 On some machines the offset between the frame pointer and starting 33704 offset of the automatic variables is not known until after register 33705 allocation has been done (for example, because the saved registers 33706 are between these two locations). On those machines, define 33707 'FRAME_POINTER_REGNUM' the number of a special, fixed register to 33708 be used internally until the offset is known, and define 33709 'HARD_FRAME_POINTER_REGNUM' to be the actual hard register number 33710 used for the frame pointer. 33711 33712 You should define this macro only in the very rare circumstances 33713 when it is not possible to calculate the offset between the frame 33714 pointer and the automatic variables until after register allocation 33715 has been completed. When this macro is defined, you must also 33716 indicate in your definition of 'ELIMINABLE_REGS' how to eliminate 33717 'FRAME_POINTER_REGNUM' into either 'HARD_FRAME_POINTER_REGNUM' or 33718 'STACK_POINTER_REGNUM'. 33719 33720 Do not define this macro if it would be the same as 33721 'FRAME_POINTER_REGNUM'. 33722 33723 -- Macro: ARG_POINTER_REGNUM 33724 The register number of the arg pointer register, which is used to 33725 access the function's argument list. On some machines, this is the 33726 same as the frame pointer register. On some machines, the hardware 33727 determines which register this is. On other machines, you can 33728 choose any register you wish for this purpose. If this is not the 33729 same register as the frame pointer register, then you must mark it 33730 as a fixed register according to 'FIXED_REGISTERS', or arrange to 33731 be able to eliminate it (*note Elimination::). 33732 33733 -- Macro: HARD_FRAME_POINTER_IS_FRAME_POINTER 33734 Define this to a preprocessor constant that is nonzero if 33735 'hard_frame_pointer_rtx' and 'frame_pointer_rtx' should be the 33736 same. The default definition is '(HARD_FRAME_POINTER_REGNUM == 33737 FRAME_POINTER_REGNUM)'; you only need to define this macro if that 33738 definition is not suitable for use in preprocessor conditionals. 33739 33740 -- Macro: HARD_FRAME_POINTER_IS_ARG_POINTER 33741 Define this to a preprocessor constant that is nonzero if 33742 'hard_frame_pointer_rtx' and 'arg_pointer_rtx' should be the same. 33743 The default definition is '(HARD_FRAME_POINTER_REGNUM == 33744 ARG_POINTER_REGNUM)'; you only need to define this macro if that 33745 definition is not suitable for use in preprocessor conditionals. 33746 33747 -- Macro: RETURN_ADDRESS_POINTER_REGNUM 33748 The register number of the return address pointer register, which 33749 is used to access the current function's return address from the 33750 stack. On some machines, the return address is not at a fixed 33751 offset from the frame pointer or stack pointer or argument pointer. 33752 This register can be defined to point to the return address on the 33753 stack, and then be converted by 'ELIMINABLE_REGS' into either the 33754 frame pointer or stack pointer. 33755 33756 Do not define this macro unless there is no other way to get the 33757 return address from the stack. 33758 33759 -- Macro: STATIC_CHAIN_REGNUM 33760 -- Macro: STATIC_CHAIN_INCOMING_REGNUM 33761 Register numbers used for passing a function's static chain 33762 pointer. If register windows are used, the register number as seen 33763 by the called function is 'STATIC_CHAIN_INCOMING_REGNUM', while the 33764 register number as seen by the calling function is 33765 'STATIC_CHAIN_REGNUM'. If these registers are the same, 33766 'STATIC_CHAIN_INCOMING_REGNUM' need not be defined. 33767 33768 The static chain register need not be a fixed register. 33769 33770 If the static chain is passed in memory, these macros should not be 33771 defined; instead, the 'TARGET_STATIC_CHAIN' hook should be used. 33772 33773 -- Target Hook: rtx TARGET_STATIC_CHAIN (const_tree FNDECL_OR_TYPE, 33774 bool INCOMING_P) 33775 This hook replaces the use of 'STATIC_CHAIN_REGNUM' et al for 33776 targets that may use different static chain locations for different 33777 nested functions. This may be required if the target has function 33778 attributes that affect the calling conventions of the function and 33779 those calling conventions use different static chain locations. 33780 33781 The default version of this hook uses 'STATIC_CHAIN_REGNUM' et al. 33782 33783 If the static chain is passed in memory, this hook should be used 33784 to provide rtx giving 'mem' expressions that denote where they are 33785 stored. Often the 'mem' expression as seen by the caller will be 33786 at an offset from the stack pointer and the 'mem' expression as 33787 seen by the callee will be at an offset from the frame pointer. 33788 The variables 'stack_pointer_rtx', 'frame_pointer_rtx', and 33789 'arg_pointer_rtx' will have been initialized and should be used to 33790 refer to those items. 33791 33792 -- Macro: DWARF_FRAME_REGISTERS 33793 This macro specifies the maximum number of hard registers that can 33794 be saved in a call frame. This is used to size data structures 33795 used in DWARF2 exception handling. 33796 33797 Prior to GCC 3.0, this macro was needed in order to establish a 33798 stable exception handling ABI in the face of adding new hard 33799 registers for ISA extensions. In GCC 3.0 and later, the EH ABI is 33800 insulated from changes in the number of hard registers. 33801 Nevertheless, this macro can still be used to reduce the runtime 33802 memory requirements of the exception handling routines, which can 33803 be substantial if the ISA contains a lot of registers that are not 33804 call-saved. 33805 33806 If this macro is not defined, it defaults to 33807 'FIRST_PSEUDO_REGISTER'. 33808 33809 -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS 33810 33811 This macro is similar to 'DWARF_FRAME_REGISTERS', but is provided 33812 for backward compatibility in pre GCC 3.0 compiled code. 33813 33814 If this macro is not defined, it defaults to 33815 'DWARF_FRAME_REGISTERS'. 33816 33817 -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO) 33818 33819 Define this macro if the target's representation for dwarf 33820 registers is different than the internal representation for unwind 33821 column. Given a dwarf register, this macro should return the 33822 internal unwind column number to use instead. 33823 33824 -- Macro: DWARF_FRAME_REGNUM (REGNO) 33825 33826 Define this macro if the target's representation for dwarf 33827 registers used in .eh_frame or .debug_frame is different from that 33828 used in other debug info sections. Given a GCC hard register 33829 number, this macro should return the .eh_frame register number. 33830 The default is 'DBX_REGISTER_NUMBER (REGNO)'. 33831 33832 -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH) 33833 33834 Define this macro to map register numbers held in the call frame 33835 info that GCC has collected using 'DWARF_FRAME_REGNUM' to those 33836 that should be output in .debug_frame ('FOR_EH' is zero) and 33837 .eh_frame ('FOR_EH' is nonzero). The default is to return 'REGNO'. 33838 33839 -- Macro: REG_VALUE_IN_UNWIND_CONTEXT 33840 33841 Define this macro if the target stores register values as 33842 '_Unwind_Word' type in unwind context. It should be defined if 33843 target register size is larger than the size of 'void *'. The 33844 default is to store register values as 'void *' type. 33845 33846 -- Macro: ASSUME_EXTENDED_UNWIND_CONTEXT 33847 33848 Define this macro to be 1 if the target always uses extended unwind 33849 context with version, args_size and by_value fields. If it is 33850 undefined, it will be defined to 1 when 33851 'REG_VALUE_IN_UNWIND_CONTEXT' is defined and 0 otherwise. 33852 33853 -- Macro: DWARF_LAZY_REGISTER_VALUE (REGNO, VALUE) 33854 Define this macro if the target has pseudo DWARF registers whose 33855 values need to be computed lazily on demand by the unwinder (such 33856 as when referenced in a CFA expression). The macro returns true if 33857 REGNO is such a register and stores its value in '*VALUE' if so. 33858 33859 33860File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling 33861 3386218.9.5 Eliminating Frame Pointer and Arg Pointer 33863------------------------------------------------ 33864 33865This is about eliminating the frame pointer and arg pointer. 33866 33867 -- Target Hook: bool TARGET_FRAME_POINTER_REQUIRED (void) 33868 This target hook should return 'true' if a function must have and 33869 use a frame pointer. This target hook is called in the reload 33870 pass. If its return value is 'true' the function will have a frame 33871 pointer. 33872 33873 This target hook can in principle examine the current function and 33874 decide according to the facts, but on most machines the constant 33875 'false' or the constant 'true' suffices. Use 'false' when the 33876 machine allows code to be generated with no frame pointer, and 33877 doing so saves some time or space. Use 'true' when there is no 33878 possible advantage to avoiding a frame pointer. 33879 33880 In certain cases, the compiler does not know how to produce valid 33881 code without a frame pointer. The compiler recognizes those cases 33882 and automatically gives the function a frame pointer regardless of 33883 what 'targetm.frame_pointer_required' returns. You don't need to 33884 worry about them. 33885 33886 In a function that does not require a frame pointer, the frame 33887 pointer register can be allocated for ordinary usage, unless you 33888 mark it as a fixed register. See 'FIXED_REGISTERS' for more 33889 information. 33890 33891 Default return value is 'false'. 33892 33893 -- Macro: ELIMINABLE_REGS 33894 This macro specifies a table of register pairs used to eliminate 33895 unneeded registers that point into the stack frame. 33896 33897 The definition of this macro is a list of structure 33898 initializations, each of which specifies an original and 33899 replacement register. 33900 33901 On some machines, the position of the argument pointer is not known 33902 until the compilation is completed. In such a case, a separate 33903 hard register must be used for the argument pointer. This register 33904 can be eliminated by replacing it with either the frame pointer or 33905 the argument pointer, depending on whether or not the frame pointer 33906 has been eliminated. 33907 33908 In this case, you might specify: 33909 #define ELIMINABLE_REGS \ 33910 {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ 33911 {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ 33912 {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} 33913 33914 Note that the elimination of the argument pointer with the stack 33915 pointer is specified first since that is the preferred elimination. 33916 33917 -- Target Hook: bool TARGET_CAN_ELIMINATE (const int FROM_REG, const 33918 int TO_REG) 33919 This target hook should return 'true' if the compiler is allowed to 33920 try to replace register number FROM_REG with register number 33921 TO_REG. This target hook will usually be 'true', since most of the 33922 cases preventing register elimination are things that the compiler 33923 already knows about. 33924 33925 Default return value is 'true'. 33926 33927 -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR) 33928 This macro returns the initial difference between the specified 33929 pair of registers. The value would be computed from information 33930 such as the result of 'get_frame_size ()' and the tables of 33931 registers 'df_regs_ever_live_p' and 'call_used_regs'. 33932 33933 -- Target Hook: void TARGET_COMPUTE_FRAME_LAYOUT (void) 33934 This target hook is called once each time the frame layout needs to 33935 be recalculated. The calculations can be cached by the target and 33936 can then be used by 'INITIAL_ELIMINATION_OFFSET' instead of 33937 re-computing the layout on every invocation of that hook. This is 33938 particularly useful for targets that have an expensive frame layout 33939 function. Implementing this callback is optional. 33940 33941 33942File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling 33943 3394418.9.6 Passing Function Arguments on the Stack 33945---------------------------------------------- 33946 33947The macros in this section control how arguments are passed on the 33948stack. See the following section for other macros that control passing 33949certain arguments in registers. 33950 33951 -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (const_tree FNTYPE) 33952 This target hook returns 'true' if an argument declared in a 33953 prototype as an integral type smaller than 'int' should actually be 33954 passed as an 'int'. In addition to avoiding errors in certain 33955 cases of mismatch, it also makes for better code on certain 33956 machines. The default is to not promote prototypes. 33957 33958 -- Macro: PUSH_ARGS 33959 A C expression. If nonzero, push insns will be used to pass 33960 outgoing arguments. If the target machine does not have a push 33961 instruction, set it to zero. That directs GCC to use an alternate 33962 strategy: to allocate the entire argument block and then store the 33963 arguments into it. When 'PUSH_ARGS' is nonzero, 'PUSH_ROUNDING' 33964 must be defined too. 33965 33966 -- Macro: PUSH_ARGS_REVERSED 33967 A C expression. If nonzero, function arguments will be evaluated 33968 from last to first, rather than from first to last. If this macro 33969 is not defined, it defaults to 'PUSH_ARGS' on targets where the 33970 stack and args grow in opposite directions, and 0 otherwise. 33971 33972 -- Macro: PUSH_ROUNDING (NPUSHED) 33973 A C expression that is the number of bytes actually pushed onto the 33974 stack when an instruction attempts to push NPUSHED bytes. 33975 33976 On some machines, the definition 33977 33978 #define PUSH_ROUNDING(BYTES) (BYTES) 33979 33980 will suffice. But on other machines, instructions that appear to 33981 push one byte actually push two bytes in an attempt to maintain 33982 alignment. Then the definition should be 33983 33984 #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) 33985 33986 If the value of this macro has a type, it should be an unsigned 33987 type. 33988 33989 -- Macro: ACCUMULATE_OUTGOING_ARGS 33990 A C expression. If nonzero, the maximum amount of space required 33991 for outgoing arguments will be computed and placed into 33992 'crtl->outgoing_args_size'. No space will be pushed onto the stack 33993 for each call; instead, the function prologue should increase the 33994 stack frame size by this amount. 33995 33996 Setting both 'PUSH_ARGS' and 'ACCUMULATE_OUTGOING_ARGS' is not 33997 proper. 33998 33999 -- Macro: REG_PARM_STACK_SPACE (FNDECL) 34000 Define this macro if functions should assume that stack space has 34001 been allocated for arguments even when their values are passed in 34002 registers. 34003 34004 The value of this macro is the size, in bytes, of the area reserved 34005 for arguments passed in registers for the function represented by 34006 FNDECL, which can be zero if GCC is calling a library function. 34007 The argument FNDECL can be the FUNCTION_DECL, or the type itself of 34008 the function. 34009 34010 This space can be allocated by the caller, or be a part of the 34011 machine-dependent stack frame: 'OUTGOING_REG_PARM_STACK_SPACE' says 34012 which. 34013 34014 -- Macro: INCOMING_REG_PARM_STACK_SPACE (FNDECL) 34015 Like 'REG_PARM_STACK_SPACE', but for incoming register arguments. 34016 Define this macro if space guaranteed when compiling a function 34017 body is different to space required when making a call, a situation 34018 that can arise with K&R style function definitions. 34019 34020 -- Macro: OUTGOING_REG_PARM_STACK_SPACE (FNTYPE) 34021 Define this to a nonzero value if it is the responsibility of the 34022 caller to allocate the area reserved for arguments passed in 34023 registers when calling a function of FNTYPE. FNTYPE may be NULL if 34024 the function called is a library function. 34025 34026 If 'ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls 34027 whether the space for these arguments counts in the value of 34028 'crtl->outgoing_args_size'. 34029 34030 -- Macro: STACK_PARMS_IN_REG_PARM_AREA 34031 Define this macro if 'REG_PARM_STACK_SPACE' is defined, but the 34032 stack parameters don't skip the area specified by it. 34033 34034 Normally, when a parameter is not passed in registers, it is placed 34035 on the stack beyond the 'REG_PARM_STACK_SPACE' area. Defining this 34036 macro suppresses this behavior and causes the parameter to be 34037 passed on the stack in its natural location. 34038 34039 -- Target Hook: poly_int64 TARGET_RETURN_POPS_ARGS (tree FUNDECL, tree 34040 FUNTYPE, poly_int64 SIZE) 34041 This target hook returns the number of bytes of its own arguments 34042 that a function pops on returning, or 0 if the function pops no 34043 arguments and the caller must therefore pop them all after the 34044 function returns. 34045 34046 FUNDECL is a C variable whose value is a tree node that describes 34047 the function in question. Normally it is a node of type 34048 'FUNCTION_DECL' that describes the declaration of the function. 34049 From this you can obtain the 'DECL_ATTRIBUTES' of the function. 34050 34051 FUNTYPE is a C variable whose value is a tree node that describes 34052 the function in question. Normally it is a node of type 34053 'FUNCTION_TYPE' that describes the data type of the function. From 34054 this it is possible to obtain the data types of the value and 34055 arguments (if known). 34056 34057 When a call to a library function is being considered, FUNDECL will 34058 contain an identifier node for the library function. Thus, if you 34059 need to distinguish among various library functions, you can do so 34060 by their names. Note that "library function" in this context means 34061 a function used to perform arithmetic, whose name is known 34062 specially in the compiler and was not mentioned in the C code being 34063 compiled. 34064 34065 SIZE is the number of bytes of arguments passed on the stack. If a 34066 variable number of bytes is passed, it is zero, and argument 34067 popping will always be the responsibility of the calling function. 34068 34069 On the VAX, all functions always pop their arguments, so the 34070 definition of this macro is SIZE. On the 68000, using the standard 34071 calling convention, no functions pop their arguments, so the value 34072 of the macro is always 0 in this case. But an alternative calling 34073 convention is available in which functions that take a fixed number 34074 of arguments pop them but other functions (such as 'printf') pop 34075 nothing (the caller pops all). When this convention is in use, 34076 FUNTYPE is examined to determine whether a function takes a fixed 34077 number of arguments. 34078 34079 -- Macro: CALL_POPS_ARGS (CUM) 34080 A C expression that should indicate the number of bytes a call 34081 sequence pops off the stack. It is added to the value of 34082 'RETURN_POPS_ARGS' when compiling a function call. 34083 34084 CUM is the variable in which all arguments to the called function 34085 have been accumulated. 34086 34087 On certain architectures, such as the SH5, a call trampoline is 34088 used that pops certain registers off the stack, depending on the 34089 arguments that have been passed to the function. Since this is a 34090 property of the call site, not of the called function, 34091 'RETURN_POPS_ARGS' is not appropriate. 34092 34093 34094File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling 34095 3409618.9.7 Passing Arguments in Registers 34097------------------------------------- 34098 34099This section describes the macros which let you control how various 34100types of arguments are passed in registers or how they are arranged in 34101the stack. 34102 34103 -- Target Hook: rtx TARGET_FUNCTION_ARG (cumulative_args_t CA, 34104 machine_mode MODE, const_tree TYPE, bool NAMED) 34105 Return an RTX indicating whether a function argument is passed in a 34106 register and if so, which register. 34107 34108 The arguments are CA, which summarizes all the previous arguments; 34109 MODE, the machine mode of the argument; TYPE, the data type of the 34110 argument as a tree node or 0 if that is not known (which happens 34111 for C support library functions); and NAMED, which is 'true' for an 34112 ordinary argument and 'false' for nameless arguments that 34113 correspond to '...' in the called function's prototype. TYPE can 34114 be an incomplete type if a syntax error has previously occurred. 34115 34116 The return value is usually either a 'reg' RTX for the hard 34117 register in which to pass the argument, or zero to pass the 34118 argument on the stack. 34119 34120 The return value can be a 'const_int' which means argument is 34121 passed in a target specific slot with specified number. Target 34122 hooks should be used to store or load argument in such case. See 34123 'TARGET_STORE_BOUNDS_FOR_ARG' and 'TARGET_LOAD_BOUNDS_FOR_ARG' for 34124 more information. 34125 34126 The value of the expression can also be a 'parallel' RTX. This is 34127 used when an argument is passed in multiple locations. The mode of 34128 the 'parallel' should be the mode of the entire argument. The 34129 'parallel' holds any number of 'expr_list' pairs; each one 34130 describes where part of the argument is passed. In each 34131 'expr_list' the first operand must be a 'reg' RTX for the hard 34132 register in which to pass this part of the argument, and the mode 34133 of the register RTX indicates how large this part of the argument 34134 is. The second operand of the 'expr_list' is a 'const_int' which 34135 gives the offset in bytes into the entire argument of where this 34136 part starts. As a special exception the first 'expr_list' in the 34137 'parallel' RTX may have a first operand of zero. This indicates 34138 that the entire argument is also stored on the stack. 34139 34140 The last time this hook is called, it is called with 'MODE == 34141 VOIDmode', and its result is passed to the 'call' or 'call_value' 34142 pattern as operands 2 and 3 respectively. 34143 34144 The usual way to make the ISO library 'stdarg.h' work on a machine 34145 where some arguments are usually passed in registers, is to cause 34146 nameless arguments to be passed on the stack instead. This is done 34147 by making 'TARGET_FUNCTION_ARG' return 0 whenever NAMED is 'false'. 34148 34149 You may use the hook 'targetm.calls.must_pass_in_stack' in the 34150 definition of this macro to determine if this argument is of a type 34151 that must be passed in the stack. If 'REG_PARM_STACK_SPACE' is not 34152 defined and 'TARGET_FUNCTION_ARG' returns nonzero for such an 34153 argument, the compiler will abort. If 'REG_PARM_STACK_SPACE' is 34154 defined, the argument will be computed in the stack and then loaded 34155 into a register. 34156 34157 -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (machine_mode MODE, 34158 const_tree TYPE) 34159 This target hook should return 'true' if we should not pass TYPE 34160 solely in registers. The file 'expr.h' defines a definition that 34161 is usually appropriate, refer to 'expr.h' for additional 34162 documentation. 34163 34164 -- Target Hook: rtx TARGET_FUNCTION_INCOMING_ARG (cumulative_args_t CA, 34165 machine_mode MODE, const_tree TYPE, bool NAMED) 34166 Define this hook if the caller and callee on the target have 34167 different views of where arguments are passed. Also define this 34168 hook if there are functions that are never directly called, but are 34169 invoked by the hardware and which have nonstandard calling 34170 conventions. 34171 34172 In this case 'TARGET_FUNCTION_ARG' computes the register in which 34173 the caller passes the value, and 'TARGET_FUNCTION_INCOMING_ARG' 34174 should be defined in a similar fashion to tell the function being 34175 called where the arguments will arrive. 34176 34177 'TARGET_FUNCTION_INCOMING_ARG' can also return arbitrary address 34178 computation using hard register, which can be forced into a 34179 register, so that it can be used to pass special arguments. 34180 34181 If 'TARGET_FUNCTION_INCOMING_ARG' is not defined, 34182 'TARGET_FUNCTION_ARG' serves both purposes. 34183 34184 -- Target Hook: bool TARGET_USE_PSEUDO_PIC_REG (void) 34185 This hook should return 1 in case pseudo register should be created 34186 for pic_offset_table_rtx during function expand. 34187 34188 -- Target Hook: void TARGET_INIT_PIC_REG (void) 34189 Perform a target dependent initialization of pic_offset_table_rtx. 34190 This hook is called at the start of register allocation. 34191 34192 -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (cumulative_args_t CUM, 34193 machine_mode MODE, tree TYPE, bool NAMED) 34194 This target hook returns the number of bytes at the beginning of an 34195 argument that must be put in registers. The value must be zero for 34196 arguments that are passed entirely in registers or that are 34197 entirely pushed on the stack. 34198 34199 On some machines, certain arguments must be passed partially in 34200 registers and partially in memory. On these machines, typically 34201 the first few words of arguments are passed in registers, and the 34202 rest on the stack. If a multi-word argument (a 'double' or a 34203 structure) crosses that boundary, its first few words must be 34204 passed in registers and the rest must be pushed. This macro tells 34205 the compiler when this occurs, and how many bytes should go in 34206 registers. 34207 34208 'TARGET_FUNCTION_ARG' for these arguments should return the first 34209 register to be used by the caller for this argument; likewise 34210 'TARGET_FUNCTION_INCOMING_ARG', for the called function. 34211 34212 -- Target Hook: bool TARGET_PASS_BY_REFERENCE (cumulative_args_t CUM, 34213 machine_mode MODE, const_tree TYPE, bool NAMED) 34214 This target hook should return 'true' if an argument at the 34215 position indicated by CUM should be passed by reference. This 34216 predicate is queried after target independent reasons for being 34217 passed by reference, such as 'TREE_ADDRESSABLE (type)'. 34218 34219 If the hook returns true, a copy of that argument is made in memory 34220 and a pointer to the argument is passed instead of the argument 34221 itself. The pointer is passed in whatever way is appropriate for 34222 passing a pointer to that type. 34223 34224 -- Target Hook: bool TARGET_CALLEE_COPIES (cumulative_args_t CUM, 34225 machine_mode MODE, const_tree TYPE, bool NAMED) 34226 The function argument described by the parameters to this hook is 34227 known to be passed by reference. The hook should return true if 34228 the function argument should be copied by the callee instead of 34229 copied by the caller. 34230 34231 For any argument for which the hook returns true, if it can be 34232 determined that the argument is not modified, then a copy need not 34233 be generated. 34234 34235 The default version of this hook always returns false. 34236 34237 -- Macro: CUMULATIVE_ARGS 34238 A C type for declaring a variable that is used as the first 34239 argument of 'TARGET_FUNCTION_ARG' and other related values. For 34240 some target machines, the type 'int' suffices and can hold the 34241 number of bytes of argument so far. 34242 34243 There is no need to record in 'CUMULATIVE_ARGS' anything about the 34244 arguments that have been passed on the stack. The compiler has 34245 other variables to keep track of that. For target machines on 34246 which all arguments are passed on the stack, there is no need to 34247 store anything in 'CUMULATIVE_ARGS'; however, the data structure 34248 must exist and should not be empty, so use 'int'. 34249 34250 -- Macro: OVERRIDE_ABI_FORMAT (FNDECL) 34251 If defined, this macro is called before generating any code for a 34252 function, but after the CFUN descriptor for the function has been 34253 created. The back end may use this macro to update CFUN to reflect 34254 an ABI other than that which would normally be used by default. If 34255 the compiler is generating code for a compiler-generated function, 34256 FNDECL may be 'NULL'. 34257 34258 -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL, 34259 N_NAMED_ARGS) 34260 A C statement (sans semicolon) for initializing the variable CUM 34261 for the state at the beginning of the argument list. The variable 34262 has type 'CUMULATIVE_ARGS'. The value of FNTYPE is the tree node 34263 for the data type of the function which will receive the args, or 0 34264 if the args are to a compiler support library function. For direct 34265 calls that are not libcalls, FNDECL contain the declaration node of 34266 the function. FNDECL is also set when 'INIT_CUMULATIVE_ARGS' is 34267 used to find arguments for the function being compiled. 34268 N_NAMED_ARGS is set to the number of named arguments, including a 34269 structure return address if it is passed as a parameter, when 34270 making a call. When processing incoming arguments, N_NAMED_ARGS is 34271 set to -1. 34272 34273 When processing a call to a compiler support library function, 34274 LIBNAME identifies which one. It is a 'symbol_ref' rtx which 34275 contains the name of the function, as a string. LIBNAME is 0 when 34276 an ordinary C function call is being processed. Thus, each time 34277 this macro is called, either LIBNAME or FNTYPE is nonzero, but 34278 never both of them at once. 34279 34280 -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME) 34281 Like 'INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls, it 34282 gets a 'MODE' argument instead of FNTYPE, that would be 'NULL'. 34283 INDIRECT would always be zero, too. If this macro is not defined, 34284 'INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is used instead. 34285 34286 -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME) 34287 Like 'INIT_CUMULATIVE_ARGS' but overrides it for the purposes of 34288 finding the arguments for the function being compiled. If this 34289 macro is undefined, 'INIT_CUMULATIVE_ARGS' is used instead. 34290 34291 The value passed for LIBNAME is always 0, since library routines 34292 with special calling conventions are never compiled with GCC. The 34293 argument LIBNAME exists for symmetry with 'INIT_CUMULATIVE_ARGS'. 34294 34295 -- Target Hook: void TARGET_FUNCTION_ARG_ADVANCE (cumulative_args_t CA, 34296 machine_mode MODE, const_tree TYPE, bool NAMED) 34297 This hook updates the summarizer variable pointed to by CA to 34298 advance past an argument in the argument list. The values MODE, 34299 TYPE and NAMED describe that argument. Once this is done, the 34300 variable CUM is suitable for analyzing the _following_ argument 34301 with 'TARGET_FUNCTION_ARG', etc. 34302 34303 This hook need not do anything if the argument in question was 34304 passed on the stack. The compiler knows how to track the amount of 34305 stack space used for arguments without any special help. 34306 34307 -- Target Hook: HOST_WIDE_INT TARGET_FUNCTION_ARG_OFFSET (machine_mode 34308 MODE, const_tree TYPE) 34309 This hook returns the number of bytes to add to the offset of an 34310 argument of type TYPE and mode MODE when passed in memory. This is 34311 needed for the SPU, which passes 'char' and 'short' arguments in 34312 the preferred slot that is in the middle of the quad word instead 34313 of starting at the top. The default implementation returns 0. 34314 34315 -- Target Hook: pad_direction TARGET_FUNCTION_ARG_PADDING (machine_mode 34316 MODE, const_tree TYPE) 34317 This hook determines whether, and in which direction, to pad out an 34318 argument of mode MODE and type TYPE. It returns 'PAD_UPWARD' to 34319 insert padding above the argument, 'PAD_DOWNWARD' to insert padding 34320 below the argument, or 'PAD_NONE' to inhibit padding. 34321 34322 The _amount_ of padding is not controlled by this hook, but by 34323 'TARGET_FUNCTION_ARG_ROUND_BOUNDARY'. It is always just enough to 34324 reach the next multiple of that boundary. 34325 34326 This hook has a default definition that is right for most systems. 34327 For little-endian machines, the default is to pad upward. For 34328 big-endian machines, the default is to pad downward for an argument 34329 of constant size shorter than an 'int', and upward otherwise. 34330 34331 -- Macro: PAD_VARARGS_DOWN 34332 If defined, a C expression which determines whether the default 34333 implementation of va_arg will attempt to pad down before reading 34334 the next argument, if that argument is smaller than its aligned 34335 space as controlled by 'PARM_BOUNDARY'. If this macro is not 34336 defined, all such arguments are padded down if 'BYTES_BIG_ENDIAN' 34337 is true. 34338 34339 -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST) 34340 Specify padding for the last element of a block move between 34341 registers and memory. FIRST is nonzero if this is the only 34342 element. Defining this macro allows better control of register 34343 function parameters on big-endian machines, without using 34344 'PARALLEL' rtl. In particular, 'MUST_PASS_IN_STACK' need not test 34345 padding and mode of types in registers, as there is no longer a 34346 "wrong" part of a register; For example, a three byte aggregate may 34347 be passed in the high part of a register if so required. 34348 34349 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_BOUNDARY (machine_mode 34350 MODE, const_tree TYPE) 34351 This hook returns the alignment boundary, in bits, of an argument 34352 with the specified mode and type. The default hook returns 34353 'PARM_BOUNDARY' for all arguments. 34354 34355 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_ROUND_BOUNDARY 34356 (machine_mode MODE, const_tree TYPE) 34357 Normally, the size of an argument is rounded up to 'PARM_BOUNDARY', 34358 which is the default value for this hook. You can define this hook 34359 to return a different value if an argument size must be rounded to 34360 a larger value. 34361 34362 -- Macro: FUNCTION_ARG_REGNO_P (REGNO) 34363 A C expression that is nonzero if REGNO is the number of a hard 34364 register in which function arguments are sometimes passed. This 34365 does _not_ include implicit arguments such as the static chain and 34366 the structure-value address. On many machines, no registers can be 34367 used for this purpose since all function arguments are pushed on 34368 the stack. 34369 34370 -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (const_tree TYPE) 34371 This hook should return true if parameter of type TYPE are passed 34372 as two scalar parameters. By default, GCC will attempt to pack 34373 complex arguments into the target's word size. Some ABIs require 34374 complex arguments to be split and treated as their individual 34375 components. For example, on AIX64, complex floats should be passed 34376 in a pair of floating point registers, even though a complex float 34377 would fit in one 64-bit floating point register. 34378 34379 The default value of this hook is 'NULL', which is treated as 34380 always false. 34381 34382 -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void) 34383 This hook returns a type node for 'va_list' for the target. The 34384 default version of the hook returns 'void*'. 34385 34386 -- Target Hook: int TARGET_ENUM_VA_LIST_P (int IDX, const char **PNAME, 34387 tree *PTREE) 34388 This target hook is used in function 'c_common_nodes_and_builtins' 34389 to iterate through the target specific builtin types for va_list. 34390 The variable IDX is used as iterator. PNAME has to be a pointer to 34391 a 'const char *' and PTREE a pointer to a 'tree' typed variable. 34392 The arguments PNAME and PTREE are used to store the result of this 34393 macro and are set to the name of the va_list builtin type and its 34394 internal type. If the return value of this macro is zero, then 34395 there is no more element. Otherwise the IDX should be increased 34396 for the next call of this macro to iterate through all types. 34397 34398 -- Target Hook: tree TARGET_FN_ABI_VA_LIST (tree FNDECL) 34399 This hook returns the va_list type of the calling convention 34400 specified by FNDECL. The default version of this hook returns 34401 'va_list_type_node'. 34402 34403 -- Target Hook: tree TARGET_CANONICAL_VA_LIST_TYPE (tree TYPE) 34404 This hook returns the va_list type of the calling convention 34405 specified by the type of TYPE. If TYPE is not a valid va_list 34406 type, it returns 'NULL_TREE'. 34407 34408 -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree 34409 TYPE, gimple_seq *PRE_P, gimple_seq *POST_P) 34410 This hook performs target-specific gimplification of 'VA_ARG_EXPR'. 34411 The first two parameters correspond to the arguments to 'va_arg'; 34412 the latter two are as in 'gimplify.c:gimplify_expr'. 34413 34414 -- Target Hook: bool TARGET_VALID_POINTER_MODE (scalar_int_mode MODE) 34415 Define this to return nonzero if the port can handle pointers with 34416 machine mode MODE. The default version of this hook returns true 34417 for both 'ptr_mode' and 'Pmode'. 34418 34419 -- Target Hook: bool TARGET_REF_MAY_ALIAS_ERRNO (struct ao_ref *REF) 34420 Define this to return nonzero if the memory reference REF may alias 34421 with the system C library errno location. The default version of 34422 this hook assumes the system C library errno location is either a 34423 declaration of type int or accessed by dereferencing a pointer to 34424 int. 34425 34426 -- Target Hook: machine_mode TARGET_TRANSLATE_MODE_ATTRIBUTE 34427 (machine_mode MODE) 34428 Define this hook if during mode attribute processing, the port 34429 should translate machine_mode MODE to another mode. For example, 34430 rs6000's 'KFmode', when it is the same as 'TFmode'. 34431 34432 The default version of the hook returns that mode that was passed 34433 in. 34434 34435 -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (scalar_mode MODE) 34436 Define this to return nonzero if the port is prepared to handle 34437 insns involving scalar mode MODE. For a scalar mode to be 34438 considered supported, all the basic arithmetic and comparisons must 34439 work. 34440 34441 The default version of this hook returns true for any mode required 34442 to handle the basic C types (as defined by the port). Included 34443 here are the double-word arithmetic supported by the code in 34444 'optabs.c'. 34445 34446 -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (machine_mode MODE) 34447 Define this to return nonzero if the port is prepared to handle 34448 insns involving vector mode MODE. At the very least, it must have 34449 move patterns for this mode. 34450 34451 -- Target Hook: opt_machine_mode TARGET_ARRAY_MODE (machine_mode MODE, 34452 unsigned HOST_WIDE_INT NELEMS) 34453 Return the mode that GCC should use for an array that has NELEMS 34454 elements, with each element having mode MODE. Return no mode if 34455 the target has no special requirements. In the latter case, GCC 34456 looks for an integer mode of the appropriate size if available and 34457 uses BLKmode otherwise. Usually the search for the integer mode is 34458 limited to 'MAX_FIXED_MODE_SIZE', but the 34459 'TARGET_ARRAY_MODE_SUPPORTED_P' hook allows a larger mode to be 34460 used in specific cases. 34461 34462 The main use of this hook is to specify that an array of vectors 34463 should also have a vector mode. The default implementation returns 34464 no mode. 34465 34466 -- Target Hook: bool TARGET_ARRAY_MODE_SUPPORTED_P (machine_mode MODE, 34467 unsigned HOST_WIDE_INT NELEMS) 34468 Return true if GCC should try to use a scalar mode to store an 34469 array of NELEMS elements, given that each element has mode MODE. 34470 Returning true here overrides the usual 'MAX_FIXED_MODE' limit and 34471 allows GCC to use any defined integer mode. 34472 34473 One use of this hook is to support vector load and store operations 34474 that operate on several homogeneous vectors. For example, ARM NEON 34475 has operations like: 34476 34477 int8x8x3_t vld3_s8 (const int8_t *) 34478 34479 where the return type is defined as: 34480 34481 typedef struct int8x8x3_t 34482 { 34483 int8x8_t val[3]; 34484 } int8x8x3_t; 34485 34486 If this hook allows 'val' to have a scalar mode, then 'int8x8x3_t' 34487 can have the same mode. GCC can then store 'int8x8x3_t's in 34488 registers rather than forcing them onto the stack. 34489 34490 -- Target Hook: bool TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P 34491 (scalar_float_mode MODE) 34492 Define this to return nonzero if libgcc provides support for the 34493 floating-point mode MODE, which is known to pass 34494 'TARGET_SCALAR_MODE_SUPPORTED_P'. The default version of this hook 34495 returns true for all of 'SFmode', 'DFmode', 'XFmode' and 'TFmode', 34496 if such modes exist. 34497 34498 -- Target Hook: opt_scalar_float_mode TARGET_FLOATN_MODE (int N, bool 34499 EXTENDED) 34500 Define this to return the machine mode to use for the type 34501 '_FloatN', if EXTENDED is false, or the type '_FloatNx', if 34502 EXTENDED is true. If such a type is not supported, return 34503 'opt_scalar_float_mode ()'. The default version of this hook 34504 returns 'SFmode' for '_Float32', 'DFmode' for '_Float64' and 34505 '_Float32x' and 'TFmode' for '_Float128', if those modes exist and 34506 satisfy the requirements for those types and pass 34507 'TARGET_SCALAR_MODE_SUPPORTED_P' and 34508 'TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P'; for '_Float64x', it 34509 returns the first of 'XFmode' and 'TFmode' that exists and 34510 satisfies the same requirements; for other types, it returns 34511 'opt_scalar_float_mode ()'. The hook is only called for values of 34512 N and EXTENDED that are valid according to ISO/IEC TS 18661-3:2015; 34513 that is, N is one of 32, 64, 128, or, if EXTENDED is false, 16 or 34514 greater than 128 and a multiple of 32. 34515 34516 -- Target Hook: bool TARGET_FLOATN_BUILTIN_P (int FUNC) 34517 Define this to return true if the '_FloatN' and '_FloatNx' built-in 34518 functions should implicitly enable the built-in function without 34519 the '__builtin_' prefix in addition to the normal built-in function 34520 with the '__builtin_' prefix. The default is to only enable 34521 built-in functions without the '__builtin_' prefix for the GNU C 34522 langauge. In strict ANSI/ISO mode, the built-in function without 34523 the '__builtin_' prefix is not enabled. The argument 'FUNC' is the 34524 'enum built_in_function' id of the function to be enabled. 34525 34526 -- Target Hook: bool TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P 34527 (machine_mode MODE) 34528 Define this to return nonzero for machine modes for which the port 34529 has small register classes. If this target hook returns nonzero 34530 for a given MODE, the compiler will try to minimize the lifetime of 34531 registers in MODE. The hook may be called with 'VOIDmode' as 34532 argument. In this case, the hook is expected to return nonzero if 34533 it returns nonzero for any mode. 34534 34535 On some machines, it is risky to let hard registers live across 34536 arbitrary insns. Typically, these machines have instructions that 34537 require values to be in specific registers (like an accumulator), 34538 and reload will fail if the required hard register is used for 34539 another purpose across such an insn. 34540 34541 Passes before reload do not know which hard registers will be used 34542 in an instruction, but the machine modes of the registers set or 34543 used in the instruction are already known. And for some machines, 34544 register classes are small for, say, integer registers but not for 34545 floating point registers. For example, the AMD x86-64 architecture 34546 requires specific registers for the legacy x86 integer 34547 instructions, but there are many SSE registers for floating point 34548 operations. On such targets, a good strategy may be to return 34549 nonzero from this hook for 'INTEGRAL_MODE_P' machine modes but zero 34550 for the SSE register classes. 34551 34552 The default version of this hook returns false for any mode. It is 34553 always safe to redefine this hook to return with a nonzero value. 34554 But if you unnecessarily define it, you will reduce the amount of 34555 optimizations that can be performed in some cases. If you do not 34556 define this hook to return a nonzero value when it is required, the 34557 compiler will run out of spill registers and print a fatal error 34558 message. 34559 34560 34561File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling 34562 3456318.9.8 How Scalar Function Values Are Returned 34564---------------------------------------------- 34565 34566This section discusses the macros that control returning scalars as 34567values--values that can fit in registers. 34568 34569 -- Target Hook: rtx TARGET_FUNCTION_VALUE (const_tree RET_TYPE, 34570 const_tree FN_DECL_OR_TYPE, bool OUTGOING) 34571 34572 Define this to return an RTX representing the place where a 34573 function returns or receives a value of data type RET_TYPE, a tree 34574 node representing a data type. FN_DECL_OR_TYPE is a tree node 34575 representing 'FUNCTION_DECL' or 'FUNCTION_TYPE' of a function being 34576 called. If OUTGOING is false, the hook should compute the register 34577 in which the caller will see the return value. Otherwise, the hook 34578 should return an RTX representing the place where a function 34579 returns a value. 34580 34581 On many machines, only 'TYPE_MODE (RET_TYPE)' is relevant. 34582 (Actually, on most machines, scalar values are returned in the same 34583 place regardless of mode.) The value of the expression is usually 34584 a 'reg' RTX for the hard register where the return value is stored. 34585 The value can also be a 'parallel' RTX, if the return value is in 34586 multiple places. See 'TARGET_FUNCTION_ARG' for an explanation of 34587 the 'parallel' form. Note that the callee will populate every 34588 location specified in the 'parallel', but if the first element of 34589 the 'parallel' contains the whole return value, callers will use 34590 that element as the canonical location and ignore the others. The 34591 m68k port uses this type of 'parallel' to return pointers in both 34592 '%a0' (the canonical location) and '%d0'. 34593 34594 If 'TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply 34595 the same promotion rules specified in 'PROMOTE_MODE' if VALTYPE is 34596 a scalar type. 34597 34598 If the precise function being called is known, FUNC is a tree node 34599 ('FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This 34600 makes it possible to use a different value-returning convention for 34601 specific functions when all their calls are known. 34602 34603 Some target machines have "register windows" so that the register 34604 in which a function returns its value is not the same as the one in 34605 which the caller sees the value. For such machines, you should 34606 return different RTX depending on OUTGOING. 34607 34608 'TARGET_FUNCTION_VALUE' is not used for return values with 34609 aggregate data types, because these are returned in another way. 34610 See 'TARGET_STRUCT_VALUE_RTX' and related macros, below. 34611 34612 -- Macro: FUNCTION_VALUE (VALTYPE, FUNC) 34613 This macro has been deprecated. Use 'TARGET_FUNCTION_VALUE' for a 34614 new target instead. 34615 34616 -- Macro: LIBCALL_VALUE (MODE) 34617 A C expression to create an RTX representing the place where a 34618 library function returns a value of mode MODE. 34619 34620 Note that "library function" in this context means a compiler 34621 support routine, used to perform arithmetic, whose name is known 34622 specially by the compiler and was not mentioned in the C code being 34623 compiled. 34624 34625 -- Target Hook: rtx TARGET_LIBCALL_VALUE (machine_mode MODE, const_rtx 34626 FUN) 34627 Define this hook if the back-end needs to know the name of the 34628 libcall function in order to determine where the result should be 34629 returned. 34630 34631 The mode of the result is given by MODE and the name of the called 34632 library function is given by FUN. The hook should return an RTX 34633 representing the place where the library function result will be 34634 returned. 34635 34636 If this hook is not defined, then LIBCALL_VALUE will be used. 34637 34638 -- Macro: FUNCTION_VALUE_REGNO_P (REGNO) 34639 A C expression that is nonzero if REGNO is the number of a hard 34640 register in which the values of called function may come back. 34641 34642 A register whose use for returning values is limited to serving as 34643 the second of a pair (for a value of type 'double', say) need not 34644 be recognized by this macro. So for most machines, this definition 34645 suffices: 34646 34647 #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) 34648 34649 If the machine has register windows, so that the caller and the 34650 called function use different registers for the return value, this 34651 macro should recognize only the caller's register numbers. 34652 34653 This macro has been deprecated. Use 34654 'TARGET_FUNCTION_VALUE_REGNO_P' for a new target instead. 34655 34656 -- Target Hook: bool TARGET_FUNCTION_VALUE_REGNO_P (const unsigned int 34657 REGNO) 34658 A target hook that return 'true' if REGNO is the number of a hard 34659 register in which the values of called function may come back. 34660 34661 A register whose use for returning values is limited to serving as 34662 the second of a pair (for a value of type 'double', say) need not 34663 be recognized by this target hook. 34664 34665 If the machine has register windows, so that the caller and the 34666 called function use different registers for the return value, this 34667 target hook should recognize only the caller's register numbers. 34668 34669 If this hook is not defined, then FUNCTION_VALUE_REGNO_P will be 34670 used. 34671 34672 -- Macro: APPLY_RESULT_SIZE 34673 Define this macro if 'untyped_call' and 'untyped_return' need more 34674 space than is implied by 'FUNCTION_VALUE_REGNO_P' for saving and 34675 restoring an arbitrary return value. 34676 34677 -- Target Hook: bool TARGET_OMIT_STRUCT_RETURN_REG 34678 Normally, when a function returns a structure by memory, the 34679 address is passed as an invisible pointer argument, but the 34680 compiler also arranges to return the address from the function like 34681 it would a normal pointer return value. Define this to true if 34682 that behavior is undesirable on your target. 34683 34684 -- Target Hook: bool TARGET_RETURN_IN_MSB (const_tree TYPE) 34685 This hook should return true if values of type TYPE are returned at 34686 the most significant end of a register (in other words, if they are 34687 padded at the least significant end). You can assume that TYPE is 34688 returned in a register; the caller is required to check this. 34689 34690 Note that the register provided by 'TARGET_FUNCTION_VALUE' must be 34691 able to hold the complete return value. For example, if a 1-, 2- 34692 or 3-byte structure is returned at the most significant end of a 34693 4-byte register, 'TARGET_FUNCTION_VALUE' should provide an 'SImode' 34694 rtx. 34695 34696 34697File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling 34698 3469918.9.9 How Large Values Are Returned 34700------------------------------------ 34701 34702When a function value's mode is 'BLKmode' (and in some other cases), the 34703value is not returned according to 'TARGET_FUNCTION_VALUE' (*note Scalar 34704Return::). Instead, the caller passes the address of a block of memory 34705in which the value should be stored. This address is called the 34706"structure value address". 34707 34708 This section describes how to control returning structure values in 34709memory. 34710 34711 -- Target Hook: bool TARGET_RETURN_IN_MEMORY (const_tree TYPE, 34712 const_tree FNTYPE) 34713 This target hook should return a nonzero value to say to return the 34714 function value in memory, just as large structures are always 34715 returned. Here TYPE will be the data type of the value, and FNTYPE 34716 will be the type of the function doing the returning, or 'NULL' for 34717 libcalls. 34718 34719 Note that values of mode 'BLKmode' must be explicitly handled by 34720 this function. Also, the option '-fpcc-struct-return' takes effect 34721 regardless of this macro. On most systems, it is possible to leave 34722 the hook undefined; this causes a default definition to be used, 34723 whose value is the constant 1 for 'BLKmode' values, and 0 34724 otherwise. 34725 34726 Do not use this hook to indicate that structures and unions should 34727 always be returned in memory. You should instead use 34728 'DEFAULT_PCC_STRUCT_RETURN' to indicate this. 34729 34730 -- Macro: DEFAULT_PCC_STRUCT_RETURN 34731 Define this macro to be 1 if all structure and union return values 34732 must be in memory. Since this results in slower code, this should 34733 be defined only if needed for compatibility with other compilers or 34734 with an ABI. If you define this macro to be 0, then the 34735 conventions used for structure and union return values are decided 34736 by the 'TARGET_RETURN_IN_MEMORY' target hook. 34737 34738 If not defined, this defaults to the value 1. 34739 34740 -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING) 34741 This target hook should return the location of the structure value 34742 address (normally a 'mem' or 'reg'), or 0 if the address is passed 34743 as an "invisible" first argument. Note that FNDECL may be 'NULL', 34744 for libcalls. You do not need to define this target hook if the 34745 address is always passed as an "invisible" first argument. 34746 34747 On some architectures the place where the structure value address 34748 is found by the called function is not the same place that the 34749 caller put it. This can be due to register windows, or it could be 34750 because the function prologue moves it to a different place. 34751 INCOMING is '1' or '2' when the location is needed in the context 34752 of the called function, and '0' in the context of the caller. 34753 34754 If INCOMING is nonzero and the address is to be found on the stack, 34755 return a 'mem' which refers to the frame pointer. If INCOMING is 34756 '2', the result is being used to fetch the structure value address 34757 at the beginning of a function. If you need to emit adjusting 34758 code, you should do it at this point. 34759 34760 -- Macro: PCC_STATIC_STRUCT_RETURN 34761 Define this macro if the usual system convention on the target 34762 machine for returning structures and unions is for the called 34763 function to return the address of a static variable containing the 34764 value. 34765 34766 Do not define this if the usual system convention is for the caller 34767 to pass an address to the subroutine. 34768 34769 This macro has effect in '-fpcc-struct-return' mode, but it does 34770 nothing when you use '-freg-struct-return' mode. 34771 34772 -- Target Hook: fixed_size_mode TARGET_GET_RAW_RESULT_MODE (int REGNO) 34773 This target hook returns the mode to be used when accessing raw 34774 return registers in '__builtin_return'. Define this macro if the 34775 value in REG_RAW_MODE is not correct. 34776 34777 -- Target Hook: fixed_size_mode TARGET_GET_RAW_ARG_MODE (int REGNO) 34778 This target hook returns the mode to be used when accessing raw 34779 argument registers in '__builtin_apply_args'. Define this macro if 34780 the value in REG_RAW_MODE is not correct. 34781 34782 -- Target Hook: bool TARGET_EMPTY_RECORD_P (const_tree TYPE) 34783 This target hook returns true if the type is an empty record. The 34784 default is to return 'false'. 34785 34786 -- Target Hook: void TARGET_WARN_PARAMETER_PASSING_ABI 34787 (cumulative_args_t CA, tree TYPE) 34788 This target hook warns about the change in empty class parameter 34789 passing ABI. 34790 34791 34792File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling 34793 3479418.9.10 Caller-Saves Register Allocation 34795---------------------------------------- 34796 34797If you enable it, GCC can save registers around function calls. This 34798makes it possible to use call-clobbered registers to hold variables that 34799must live across calls. 34800 34801 -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS) 34802 A C expression specifying which mode is required for saving NREGS 34803 of a pseudo-register in call-clobbered hard register REGNO. If 34804 REGNO is unsuitable for caller save, 'VOIDmode' should be returned. 34805 For most machines this macro need not be defined since GCC will 34806 select the smallest suitable mode. 34807 34808 34809File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling 34810 3481118.9.11 Function Entry and Exit 34812------------------------------- 34813 34814This section describes the macros that output function entry 34815("prologue") and exit ("epilogue") code. 34816 34817 -- Target Hook: void TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY (FILE 34818 *FILE, unsigned HOST_WIDE_INT PATCH_AREA_SIZE, bool RECORD_P) 34819 Generate a patchable area at the function start, consisting of 34820 PATCH_AREA_SIZE NOP instructions. If the target supports named 34821 sections and if RECORD_P is true, insert a pointer to the current 34822 location in the table of patchable functions. The default 34823 implementation of the hook places the table of pointers in the 34824 special section named '__patchable_function_entries'. 34825 34826 -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE) 34827 If defined, a function that outputs the assembler code for entry to 34828 a function. The prologue is responsible for setting up the stack 34829 frame, initializing the frame pointer register, saving registers 34830 that must be saved, and allocating SIZE additional bytes of storage 34831 for the local variables. FILE is a stdio stream to which the 34832 assembler code should be output. 34833 34834 The label for the beginning of the function need not be output by 34835 this macro. That has already been done when the macro is run. 34836 34837 To determine which registers to save, the macro can refer to the 34838 array 'regs_ever_live': element R is nonzero if hard register R is 34839 used anywhere within the function. This implies the function 34840 prologue should save register R, provided it is not one of the 34841 call-used registers. ('TARGET_ASM_FUNCTION_EPILOGUE' must likewise 34842 use 'regs_ever_live'.) 34843 34844 On machines that have "register windows", the function entry code 34845 does not save on the stack the registers that are in the windows, 34846 even if they are supposed to be preserved by function calls; 34847 instead it takes appropriate steps to "push" the register stack, if 34848 any non-call-used registers are used in the function. 34849 34850 On machines where functions may or may not have frame-pointers, the 34851 function entry code must vary accordingly; it must set up the frame 34852 pointer if one is wanted, and not otherwise. To determine whether 34853 a frame pointer is in wanted, the macro can refer to the variable 34854 'frame_pointer_needed'. The variable's value will be 1 at run time 34855 in a function that needs a frame pointer. *Note Elimination::. 34856 34857 The function entry code is responsible for allocating any stack 34858 space required for the function. This stack space consists of the 34859 regions listed below. In most cases, these regions are allocated 34860 in the order listed, with the last listed region closest to the top 34861 of the stack (the lowest address if 'STACK_GROWS_DOWNWARD' is 34862 defined, and the highest address if it is not defined). You can 34863 use a different order for a machine if doing so is more convenient 34864 or required for compatibility reasons. Except in cases where 34865 required by standard or by a debugger, there is no reason why the 34866 stack layout used by GCC need agree with that used by other 34867 compilers for a machine. 34868 34869 -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE) 34870 If defined, a function that outputs assembler code at the end of a 34871 prologue. This should be used when the function prologue is being 34872 emitted as RTL, and you have some extra assembler that needs to be 34873 emitted. *Note prologue instruction pattern::. 34874 34875 -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE) 34876 If defined, a function that outputs assembler code at the start of 34877 an epilogue. This should be used when the function epilogue is 34878 being emitted as RTL, and you have some extra assembler that needs 34879 to be emitted. *Note epilogue instruction pattern::. 34880 34881 -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE) 34882 If defined, a function that outputs the assembler code for exit 34883 from a function. The epilogue is responsible for restoring the 34884 saved registers and stack pointer to their values when the function 34885 was called, and returning control to the caller. This macro takes 34886 the same argument as the macro 'TARGET_ASM_FUNCTION_PROLOGUE', and 34887 the registers to restore are determined from 'regs_ever_live' and 34888 'CALL_USED_REGISTERS' in the same way. 34889 34890 On some machines, there is a single instruction that does all the 34891 work of returning from the function. On these machines, give that 34892 instruction the name 'return' and do not define the macro 34893 'TARGET_ASM_FUNCTION_EPILOGUE' at all. 34894 34895 Do not define a pattern named 'return' if you want the 34896 'TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target 34897 switches to control whether return instructions or epilogues are 34898 used, define a 'return' pattern with a validity condition that 34899 tests the target switches appropriately. If the 'return' pattern's 34900 validity condition is false, epilogues will be used. 34901 34902 On machines where functions may or may not have frame-pointers, the 34903 function exit code must vary accordingly. Sometimes the code for 34904 these two cases is completely different. To determine whether a 34905 frame pointer is wanted, the macro can refer to the variable 34906 'frame_pointer_needed'. The variable's value will be 1 when 34907 compiling a function that needs a frame pointer. 34908 34909 Normally, 'TARGET_ASM_FUNCTION_PROLOGUE' and 34910 'TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially. 34911 The C variable 'current_function_is_leaf' is nonzero for such a 34912 function. *Note Leaf Functions::. 34913 34914 On some machines, some functions pop their arguments on exit while 34915 others leave that for the caller to do. For example, the 68020 34916 when given '-mrtd' pops arguments in functions that take a fixed 34917 number of arguments. 34918 34919 Your definition of the macro 'RETURN_POPS_ARGS' decides which 34920 functions pop their own arguments. 'TARGET_ASM_FUNCTION_EPILOGUE' 34921 needs to know what was decided. The number of bytes of the current 34922 function's arguments that this function should pop is available in 34923 'crtl->args.pops_args'. *Note Scalar Return::. 34924 34925 * A region of 'crtl->args.pretend_args_size' bytes of uninitialized 34926 space just underneath the first argument arriving on the stack. 34927 (This may not be at the very start of the allocated stack region if 34928 the calling sequence has pushed anything else since pushing the 34929 stack arguments. But usually, on such machines, nothing else has 34930 been pushed yet, because the function prologue itself does all the 34931 pushing.) This region is used on machines where an argument may be 34932 passed partly in registers and partly in memory, and, in some cases 34933 to support the features in '<stdarg.h>'. 34934 34935 * An area of memory used to save certain registers used by the 34936 function. The size of this area, which may also include space for 34937 such things as the return address and pointers to previous stack 34938 frames, is machine-specific and usually depends on which registers 34939 have been used in the function. Machines with register windows 34940 often do not require a save area. 34941 34942 * A region of at least SIZE bytes, possibly rounded up to an 34943 allocation boundary, to contain the local variables of the 34944 function. On some machines, this region and the save area may 34945 occur in the opposite order, with the save area closer to the top 34946 of the stack. 34947 34948 * Optionally, when 'ACCUMULATE_OUTGOING_ARGS' is defined, a region of 34949 'crtl->outgoing_args_size' bytes to be used for outgoing argument 34950 lists of the function. *Note Stack Arguments::. 34951 34952 -- Macro: EXIT_IGNORE_STACK 34953 Define this macro as a C expression that is nonzero if the return 34954 instruction or the function epilogue ignores the value of the stack 34955 pointer; in other words, if it is safe to delete an instruction to 34956 adjust the stack pointer before a return from the function. The 34957 default is 0. 34958 34959 Note that this macro's value is relevant only for functions for 34960 which frame pointers are maintained. It is never safe to delete a 34961 final stack adjustment in a function that has no frame pointer, and 34962 the compiler knows this regardless of 'EXIT_IGNORE_STACK'. 34963 34964 -- Macro: EPILOGUE_USES (REGNO) 34965 Define this macro as a C expression that is nonzero for registers 34966 that are used by the epilogue or the 'return' pattern. The stack 34967 and frame pointer registers are already assumed to be used as 34968 needed. 34969 34970 -- Macro: EH_USES (REGNO) 34971 Define this macro as a C expression that is nonzero for registers 34972 that are used by the exception handling mechanism, and so should be 34973 considered live on entry to an exception edge. 34974 34975 -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree 34976 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT VCALL_OFFSET, 34977 tree FUNCTION) 34978 A function that outputs the assembler code for a thunk function, 34979 used to implement C++ virtual function calls with multiple 34980 inheritance. The thunk acts as a wrapper around a virtual 34981 function, adjusting the implicit object parameter before handing 34982 control off to the real function. 34983 34984 First, emit code to add the integer DELTA to the location that 34985 contains the incoming first argument. Assume that this argument 34986 contains a pointer, and is the one used to pass the 'this' pointer 34987 in C++. This is the incoming argument _before_ the function 34988 prologue, e.g. '%o0' on a sparc. The addition must preserve the 34989 values of all other incoming arguments. 34990 34991 Then, if VCALL_OFFSET is nonzero, an additional adjustment should 34992 be made after adding 'delta'. In particular, if P is the adjusted 34993 pointer, the following adjustment should be made: 34994 34995 p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)] 34996 34997 After the additions, emit code to jump to FUNCTION, which is a 34998 'FUNCTION_DECL'. This is a direct pure jump, not a call, and does 34999 not touch the return address. Hence returning from FUNCTION will 35000 return to whoever called the current 'thunk'. 35001 35002 The effect must be as if FUNCTION had been called directly with the 35003 adjusted first argument. This macro is responsible for emitting 35004 all of the code for a thunk function; 35005 'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE' 35006 are not invoked. 35007 35008 The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already 35009 been extracted from it.) It might possibly be useful on some 35010 targets, but probably not. 35011 35012 If you do not define this macro, the target-independent code in the 35013 C++ front end will generate a less efficient heavyweight thunk that 35014 calls FUNCTION instead of jumping to it. The generic approach does 35015 not support varargs. 35016 35017 -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (const_tree 35018 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT VCALL_OFFSET, 35019 const_tree FUNCTION) 35020 A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would be 35021 able to output the assembler code for the thunk function specified 35022 by the arguments it is passed, and false otherwise. In the latter 35023 case, the generic approach will be used by the C++ front end, with 35024 the limitations previously exposed. 35025 35026 35027File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling 35028 3502918.9.12 Generating Code for Profiling 35030------------------------------------- 35031 35032These macros will help you generate code for profiling. 35033 35034 -- Macro: FUNCTION_PROFILER (FILE, LABELNO) 35035 A C statement or compound statement to output to FILE some 35036 assembler code to call the profiling subroutine 'mcount'. 35037 35038 The details of how 'mcount' expects to be called are determined by 35039 your operating system environment, not by GCC. To figure them out, 35040 compile a small program for profiling using the system's installed 35041 C compiler and look at the assembler code that results. 35042 35043 Older implementations of 'mcount' expect the address of a counter 35044 variable to be loaded into some register. The name of this 35045 variable is 'LP' followed by the number LABELNO, so you would 35046 generate the name using 'LP%d' in a 'fprintf'. 35047 35048 -- Macro: PROFILE_HOOK 35049 A C statement or compound statement to output to FILE some assembly 35050 code to call the profiling subroutine 'mcount' even the target does 35051 not support profiling. 35052 35053 -- Macro: NO_PROFILE_COUNTERS 35054 Define this macro to be an expression with a nonzero value if the 35055 'mcount' subroutine on your system does not need a counter variable 35056 allocated for each function. This is true for almost all modern 35057 implementations. If you define this macro, you must not use the 35058 LABELNO argument to 'FUNCTION_PROFILER'. 35059 35060 -- Macro: PROFILE_BEFORE_PROLOGUE 35061 Define this macro if the code for function profiling should come 35062 before the function prologue. Normally, the profiling code comes 35063 after. 35064 35065 -- Target Hook: bool TARGET_KEEP_LEAF_WHEN_PROFILED (void) 35066 This target hook returns true if the target wants the leaf flag for 35067 the current function to stay true even if it calls mcount. This 35068 might make sense for targets using the leaf flag only to determine 35069 whether a stack frame needs to be generated or not and for which 35070 the call to mcount is generated before the function prologue. 35071 35072 35073File: gccint.info, Node: Tail Calls, Next: Shrink-wrapping separate components, Prev: Profiling, Up: Stack and Calling 35074 3507518.9.13 Permitting tail calls 35076----------------------------- 35077 35078 -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree 35079 EXP) 35080 True if it is OK to do sibling call optimization for the specified 35081 call expression EXP. DECL will be the called function, or 'NULL' 35082 if this is an indirect call. 35083 35084 It is not uncommon for limitations of calling conventions to 35085 prevent tail calls to functions outside the current unit of 35086 translation, or during PIC compilation. The hook is used to 35087 enforce these restrictions, as the 'sibcall' md pattern cannot 35088 fail, or fall over to a "normal" call. The criteria for successful 35089 sibling call optimization may vary greatly between different 35090 architectures. 35091 35092 -- Target Hook: void TARGET_EXTRA_LIVE_ON_ENTRY (bitmap REGS) 35093 Add any hard registers to REGS that are live on entry to the 35094 function. This hook only needs to be defined to provide registers 35095 that cannot be found by examination of FUNCTION_ARG_REGNO_P, the 35096 callee saved registers, STATIC_CHAIN_INCOMING_REGNUM, 35097 STATIC_CHAIN_REGNUM, TARGET_STRUCT_VALUE_RTX, FRAME_POINTER_REGNUM, 35098 EH_USES, FRAME_POINTER_REGNUM, ARG_POINTER_REGNUM, and the 35099 PIC_OFFSET_TABLE_REGNUM. 35100 35101 -- Target Hook: void TARGET_SET_UP_BY_PROLOGUE (struct 35102 hard_reg_set_container *) 35103 This hook should add additional registers that are computed by the 35104 prologue to the hard regset for shrink-wrapping optimization 35105 purposes. 35106 35107 -- Target Hook: bool TARGET_WARN_FUNC_RETURN (tree) 35108 True if a function's return statements should be checked for 35109 matching the function's return type. This includes checking for 35110 falling off the end of a non-void function. Return false if no 35111 such check should be made. 35112 35113 35114File: gccint.info, Node: Shrink-wrapping separate components, Next: Stack Smashing Protection, Prev: Tail Calls, Up: Stack and Calling 35115 3511618.9.14 Shrink-wrapping separate components 35117------------------------------------------- 35118 35119The prologue may perform a variety of target dependent tasks such as 35120saving callee-saved registers, saving the return address, aligning the 35121stack, creating a stack frame, initializing the PIC register, setting up 35122the static chain, etc. 35123 35124 On some targets some of these tasks may be independent of others and 35125thus may be shrink-wrapped separately. These independent tasks are 35126referred to as components and are handled generically by the target 35127independent parts of GCC. 35128 35129 Using the following hooks those prologue or epilogue components can be 35130shrink-wrapped separately, so that the initialization (and possibly 35131teardown) those components do is not done as frequently on execution 35132paths where this would unnecessary. 35133 35134 What exactly those components are is up to the target code; the generic 35135code treats them abstractly, as a bit in an 'sbitmap'. These 'sbitmap's 35136are allocated by the 'shrink_wrap.get_separate_components' and 35137'shrink_wrap.components_for_bb' hooks, and deallocated by the generic 35138code. 35139 35140 -- Target Hook: sbitmap TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS 35141 (void) 35142 This hook should return an 'sbitmap' with the bits set for those 35143 components that can be separately shrink-wrapped in the current 35144 function. Return 'NULL' if the current function should not get any 35145 separate shrink-wrapping. Don't define this hook if it would 35146 always return 'NULL'. If it is defined, the other hooks in this 35147 group have to be defined as well. 35148 35149 -- Target Hook: sbitmap TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB 35150 (basic_block) 35151 This hook should return an 'sbitmap' with the bits set for those 35152 components where either the prologue component has to be executed 35153 before the 'basic_block', or the epilogue component after it, or 35154 both. 35155 35156 -- Target Hook: void TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS (sbitmap 35157 COMPONENTS, edge E, sbitmap EDGE_COMPONENTS, bool IS_PROLOGUE) 35158 This hook should clear the bits in the COMPONENTS bitmap for those 35159 components in EDGE_COMPONENTS that the target cannot handle on edge 35160 E, where IS_PROLOGUE says if this is for a prologue or an epilogue 35161 instead. 35162 35163 -- Target Hook: void TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS 35164 (sbitmap) 35165 Emit prologue insns for the components indicated by the parameter. 35166 35167 -- Target Hook: void TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS 35168 (sbitmap) 35169 Emit epilogue insns for the components indicated by the parameter. 35170 35171 -- Target Hook: void TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS 35172 (sbitmap) 35173 Mark the components in the parameter as handled, so that the 35174 'prologue' and 'epilogue' named patterns know to ignore those 35175 components. The target code should not hang on to the 'sbitmap', 35176 it will be deleted after this call. 35177 35178 35179File: gccint.info, Node: Stack Smashing Protection, Next: Miscellaneous Register Hooks, Prev: Shrink-wrapping separate components, Up: Stack and Calling 35180 3518118.9.15 Stack smashing protection 35182--------------------------------- 35183 35184 -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void) 35185 This hook returns a 'DECL' node for the external variable to use 35186 for the stack protection guard. This variable is initialized by 35187 the runtime to some random value and is used to initialize the 35188 guard value that is placed at the top of the local stack frame. 35189 The type of this variable must be 'ptr_type_node'. 35190 35191 The default version of this hook creates a variable called 35192 '__stack_chk_guard', which is normally defined in 'libgcc2.c'. 35193 35194 -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void) 35195 This hook returns a 'CALL_EXPR' that alerts the runtime that the 35196 stack protect guard variable has been modified. This expression 35197 should involve a call to a 'noreturn' function. 35198 35199 The default version of this hook invokes a function called 35200 '__stack_chk_fail', taking no arguments. This function is normally 35201 defined in 'libgcc2.c'. 35202 35203 -- Target Hook: bool TARGET_STACK_PROTECT_RUNTIME_ENABLED_P (void) 35204 Returns true if the target wants GCC's default stack protect 35205 runtime support, otherwise return false. The default 35206 implementation always returns true. 35207 35208 -- Common Target Hook: bool TARGET_SUPPORTS_SPLIT_STACK (bool REPORT, 35209 struct gcc_options *OPTS) 35210 Whether this target supports splitting the stack when the options 35211 described in OPTS have been passed. This is called after options 35212 have been parsed, so the target may reject splitting the stack in 35213 some configurations. The default version of this hook returns 35214 false. If REPORT is true, this function may issue a warning or 35215 error; if REPORT is false, it must simply return a value 35216 35217 -- Common Target Hook: vec<const char *> TARGET_GET_VALID_OPTION_VALUES 35218 (int OPTION_CODE, const char *PREFIX) 35219 The hook is used for options that have a non-trivial list of 35220 possible option values. OPTION_CODE is option code of opt_code 35221 enum type. PREFIX is used for bash completion and allows an 35222 implementation to return more specific completion based on the 35223 prefix. All string values should be allocated from heap memory and 35224 consumers should release them. The result will be pruned to cases 35225 with PREFIX if not NULL. 35226 35227 35228File: gccint.info, Node: Miscellaneous Register Hooks, Prev: Stack Smashing Protection, Up: Stack and Calling 35229 3523018.9.16 Miscellaneous register hooks 35231------------------------------------ 35232 35233 -- Target Hook: bool TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS 35234 Set to true if each call that binds to a local definition 35235 explicitly clobbers or sets all non-fixed registers modified by 35236 performing the call. That is, by the call pattern itself, or by 35237 code that might be inserted by the linker (e.g. stubs, veneers, 35238 branch islands), but not including those modifiable by the callee. 35239 The affected registers may be mentioned explicitly in the call 35240 pattern, or included as clobbers in CALL_INSN_FUNCTION_USAGE. The 35241 default version of this hook is set to false. The purpose of this 35242 hook is to enable the fipa-ra optimization. 35243 35244 35245File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros 35246 3524718.10 Implementing the Varargs Macros 35248===================================== 35249 35250GCC comes with an implementation of '<varargs.h>' and '<stdarg.h>' that 35251work without change on machines that pass arguments on the stack. Other 35252machines require their own implementations of varargs, and the two 35253machine independent header files must have conditionals to include it. 35254 35255 ISO '<stdarg.h>' differs from traditional '<varargs.h>' mainly in the 35256calling convention for 'va_start'. The traditional implementation takes 35257just one argument, which is the variable in which to store the argument 35258pointer. The ISO implementation of 'va_start' takes an additional 35259second argument. The user is supposed to write the last named argument 35260of the function here. 35261 35262 However, 'va_start' should not use this argument. The way to find the 35263end of the named arguments is with the built-in functions described 35264below. 35265 35266 -- Macro: __builtin_saveregs () 35267 Use this built-in function to save the argument registers in memory 35268 so that the varargs mechanism can access them. Both ISO and 35269 traditional versions of 'va_start' must use '__builtin_saveregs', 35270 unless you use 'TARGET_SETUP_INCOMING_VARARGS' (see below) instead. 35271 35272 On some machines, '__builtin_saveregs' is open-coded under the 35273 control of the target hook 'TARGET_EXPAND_BUILTIN_SAVEREGS'. On 35274 other machines, it calls a routine written in assembler language, 35275 found in 'libgcc2.c'. 35276 35277 Code generated for the call to '__builtin_saveregs' appears at the 35278 beginning of the function, as opposed to where the call to 35279 '__builtin_saveregs' is written, regardless of what the code is. 35280 This is because the registers must be saved before the function 35281 starts to use them for its own purposes. 35282 35283 -- Macro: __builtin_next_arg (LASTARG) 35284 This builtin returns the address of the first anonymous stack 35285 argument, as type 'void *'. If 'ARGS_GROW_DOWNWARD', it returns 35286 the address of the location above the first anonymous stack 35287 argument. Use it in 'va_start' to initialize the pointer for 35288 fetching arguments from the stack. Also use it in 'va_start' to 35289 verify that the second parameter LASTARG is the last named argument 35290 of the current function. 35291 35292 -- Macro: __builtin_classify_type (OBJECT) 35293 Since each machine has its own conventions for which data types are 35294 passed in which kind of register, your implementation of 'va_arg' 35295 has to embody these conventions. The easiest way to categorize the 35296 specified data type is to use '__builtin_classify_type' together 35297 with 'sizeof' and '__alignof__'. 35298 35299 '__builtin_classify_type' ignores the value of OBJECT, considering 35300 only its data type. It returns an integer describing what kind of 35301 type that is--integer, floating, pointer, structure, and so on. 35302 35303 The file 'typeclass.h' defines an enumeration that you can use to 35304 interpret the values of '__builtin_classify_type'. 35305 35306 These machine description macros help implement varargs: 35307 35308 -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void) 35309 If defined, this hook produces the machine-specific code for a call 35310 to '__builtin_saveregs'. This code will be moved to the very 35311 beginning of the function, before any parameter access are made. 35312 The return value of this function should be an RTX that contains 35313 the value to use as the return of '__builtin_saveregs'. 35314 35315 -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (cumulative_args_t 35316 ARGS_SO_FAR, machine_mode MODE, tree TYPE, int 35317 *PRETEND_ARGS_SIZE, int SECOND_TIME) 35318 This target hook offers an alternative to using 35319 '__builtin_saveregs' and defining the hook 35320 'TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous 35321 register arguments into the stack so that all the arguments appear 35322 to have been passed consecutively on the stack. Once this is done, 35323 you can use the standard implementation of varargs that works for 35324 machines that pass all their arguments on the stack. 35325 35326 The argument ARGS_SO_FAR points to the 'CUMULATIVE_ARGS' data 35327 structure, containing the values that are obtained after processing 35328 the named arguments. The arguments MODE and TYPE describe the last 35329 named argument--its machine mode and its data type as a tree node. 35330 35331 The target hook should do two things: first, push onto the stack 35332 all the argument registers _not_ used for the named arguments, and 35333 second, store the size of the data thus pushed into the 35334 'int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value 35335 that you store here will serve as additional offset for setting up 35336 the stack frame. 35337 35338 Because you must generate code to push the anonymous arguments at 35339 compile time without knowing their data types, 35340 'TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that 35341 have just a single category of argument register and use it 35342 uniformly for all data types. 35343 35344 If the argument SECOND_TIME is nonzero, it means that the arguments 35345 of the function are being analyzed for the second time. This 35346 happens for an inline function, which is not actually compiled 35347 until the end of the source file. The hook 35348 'TARGET_SETUP_INCOMING_VARARGS' should not generate any 35349 instructions in this case. 35350 35351 -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (cumulative_args_t 35352 CA) 35353 Define this hook to return 'true' if the location where a function 35354 argument is passed depends on whether or not it is a named 35355 argument. 35356 35357 This hook controls how the NAMED argument to 'TARGET_FUNCTION_ARG' 35358 is set for varargs and stdarg functions. If this hook returns 35359 'true', the NAMED argument is always true for named arguments, and 35360 false for unnamed arguments. If it returns 'false', but 35361 'TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns 'true', then all 35362 arguments are treated as named. Otherwise, all named arguments 35363 except the last are treated as named. 35364 35365 You need not define this hook if it always returns 'false'. 35366 35367 -- Target Hook: void TARGET_CALL_ARGS (rtx, TREE) 35368 While generating RTL for a function call, this target hook is 35369 invoked once for each argument passed to the function, either a 35370 register returned by 'TARGET_FUNCTION_ARG' or a memory location. 35371 It is called just before the point where argument registers are 35372 stored. The type of the function to be called is also passed as 35373 the second argument; it is 'NULL_TREE' for libcalls. The 35374 'TARGET_END_CALL_ARGS' hook is invoked just after the code to copy 35375 the return reg has been emitted. This functionality can be used to 35376 perform special setup of call argument registers if a target needs 35377 it. For functions without arguments, the hook is called once with 35378 'pc_rtx' passed instead of an argument register. Most ports do not 35379 need to implement anything for this hook. 35380 35381 -- Target Hook: void TARGET_END_CALL_ARGS (void) 35382 This target hook is invoked while generating RTL for a function 35383 call, just after the point where the return reg is copied into a 35384 pseudo. It signals that all the call argument and return registers 35385 for the just emitted call are now no longer in use. Most ports do 35386 not need to implement anything for this hook. 35387 35388 -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED 35389 (cumulative_args_t CA) 35390 If you need to conditionally change ABIs so that one works with 35391 'TARGET_SETUP_INCOMING_VARARGS', but the other works like neither 35392 'TARGET_SETUP_INCOMING_VARARGS' nor 'TARGET_STRICT_ARGUMENT_NAMING' 35393 was defined, then define this hook to return 'true' if 35394 'TARGET_SETUP_INCOMING_VARARGS' is used, 'false' otherwise. 35395 Otherwise, you should not define this hook. 35396 35397 -- Target Hook: rtx TARGET_LOAD_BOUNDS_FOR_ARG (rtx SLOT, rtx ARG, rtx 35398 SLOT_NO) 35399 This hook is used by expand pass to emit insn to load bounds of ARG 35400 passed in SLOT. Expand pass uses this hook in case bounds of ARG 35401 are not passed in register. If SLOT is a memory, then bounds are 35402 loaded as for regular pointer loaded from memory. If SLOT is not a 35403 memory then SLOT_NO is an integer constant holding number of the 35404 target dependent special slot which should be used to obtain 35405 bounds. Hook returns RTX holding loaded bounds. 35406 35407 -- Target Hook: void TARGET_STORE_BOUNDS_FOR_ARG (rtx ARG, rtx SLOT, 35408 rtx BOUNDS, rtx SLOT_NO) 35409 This hook is used by expand pass to emit insns to store BOUNDS of 35410 ARG passed in SLOT. Expand pass uses this hook in case BOUNDS of 35411 ARG are not passed in register. If SLOT is a memory, then BOUNDS 35412 are stored as for regular pointer stored in memory. If SLOT is not 35413 a memory then SLOT_NO is an integer constant holding number of the 35414 target dependent special slot which should be used to store BOUNDS. 35415 35416 -- Target Hook: rtx TARGET_LOAD_RETURNED_BOUNDS (rtx SLOT) 35417 This hook is used by expand pass to emit insn to load bounds 35418 returned by function call in SLOT. Hook returns RTX holding loaded 35419 bounds. 35420 35421 -- Target Hook: void TARGET_STORE_RETURNED_BOUNDS (rtx SLOT, rtx 35422 BOUNDS) 35423 This hook is used by expand pass to emit insn to store BOUNDS 35424 returned by function call into SLOT. 35425 35426 -- Target Hook: void TARGET_SETUP_INCOMING_VARARG_BOUNDS 35427 (cumulative_args_t ARGS_SO_FAR, machine_mode MODE, tree TYPE, 35428 int *PRETEND_ARGS_SIZE, int SECOND_TIME) 35429 Use it to store bounds for anonymous register arguments stored into 35430 the stack. Arguments meaning is similar to 35431 'TARGET_SETUP_INCOMING_VARARGS'. 35432 35433 35434File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros 35435 3543618.11 Support for Nested Functions 35437================================== 35438 35439Taking the address of a nested function requires special compiler 35440handling to ensure that the static chain register is loaded when the 35441function is invoked via an indirect call. 35442 35443 GCC has traditionally supported nested functions by creating an 35444executable "trampoline" at run time when the address of a nested 35445function is taken. This is a small piece of code which normally resides 35446on the stack, in the stack frame of the containing function. The 35447trampoline loads the static chain register and then jumps to the real 35448address of the nested function. 35449 35450 The use of trampolines requires an executable stack, which is a 35451security risk. To avoid this problem, GCC also supports another 35452strategy: using descriptors for nested functions. Under this model, 35453taking the address of a nested function results in a pointer to a 35454non-executable function descriptor object. Initializing the static 35455chain from the descriptor is handled at indirect call sites. 35456 35457 On some targets, including HPPA and IA-64, function descriptors may be 35458mandated by the ABI or be otherwise handled in a target-specific way by 35459the back end in its code generation strategy for indirect calls. GCC 35460also provides its own generic descriptor implementation to support the 35461'-fno-trampolines' option. In this case runtime detection of function 35462descriptors at indirect call sites relies on descriptor pointers being 35463tagged with a bit that is never set in bare function addresses. Since 35464GCC's generic function descriptors are not ABI-compliant, this option is 35465typically used only on a per-language basis (notably by Ada) or when it 35466can otherwise be applied to the whole program. 35467 35468 Define the following hook if your backend either implements 35469ABI-specified descriptor support, or can use GCC's generic descriptor 35470implementation for nested functions. 35471 35472 -- Target Hook: int TARGET_CUSTOM_FUNCTION_DESCRIPTORS 35473 If the target can use GCC's generic descriptor mechanism for nested 35474 functions, define this hook to a power of 2 representing an unused 35475 bit in function pointers which can be used to differentiate 35476 descriptors at run time. This value gives the number of bytes by 35477 which descriptor pointers are misaligned compared to function 35478 pointers. For example, on targets that require functions to be 35479 aligned to a 4-byte boundary, a value of either 1 or 2 is 35480 appropriate unless the architecture already reserves the bit for 35481 another purpose, such as on ARM. 35482 35483 Define this hook to 0 if the target implements ABI support for 35484 function descriptors in its standard calling sequence, like for 35485 example HPPA or IA-64. 35486 35487 Using descriptors for nested functions eliminates the need for 35488 trampolines that reside on the stack and require it to be made 35489 executable. 35490 35491 The following macros tell GCC how to generate code to allocate and 35492initialize an executable trampoline. You can also use this interface if 35493your back end needs to create ABI-specified non-executable descriptors; 35494in this case the "trampoline" created is the descriptor containing data 35495only. 35496 35497 The instructions in an executable trampoline must do two things: load a 35498constant address into the static chain register, and jump to the real 35499address of the nested function. On CISC machines such as the m68k, this 35500requires two instructions, a move immediate and a jump. Then the two 35501addresses exist in the trampoline as word-long immediate operands. On 35502RISC machines, it is often necessary to load each address into a 35503register in two parts. Then pieces of each address form separate 35504immediate operands. 35505 35506 The code generated to initialize the trampoline must store the variable 35507parts--the static chain value and the function address--into the 35508immediate operands of the instructions. On a CISC machine, this is 35509simply a matter of copying each address to a memory reference at the 35510proper offset from the start of the trampoline. On a RISC machine, it 35511may be necessary to take out pieces of the address and store them 35512separately. 35513 35514 -- Target Hook: void TARGET_ASM_TRAMPOLINE_TEMPLATE (FILE *F) 35515 This hook is called by 'assemble_trampoline_template' to output, on 35516 the stream F, assembler code for a block of data that contains the 35517 constant parts of a trampoline. This code should not include a 35518 label--the label is taken care of automatically. 35519 35520 If you do not define this hook, it means no template is needed for 35521 the target. Do not define this hook on systems where the block 35522 move code to copy the trampoline into place would be larger than 35523 the code to generate it on the spot. 35524 35525 -- Macro: TRAMPOLINE_SECTION 35526 Return the section into which the trampoline template is to be 35527 placed (*note Sections::). The default value is 35528 'readonly_data_section'. 35529 35530 -- Macro: TRAMPOLINE_SIZE 35531 A C expression for the size in bytes of the trampoline, as an 35532 integer. 35533 35534 -- Macro: TRAMPOLINE_ALIGNMENT 35535 Alignment required for trampolines, in bits. 35536 35537 If you don't define this macro, the value of 'FUNCTION_ALIGNMENT' 35538 is used for aligning trampolines. 35539 35540 -- Target Hook: void TARGET_TRAMPOLINE_INIT (rtx M_TRAMP, tree FNDECL, 35541 rtx STATIC_CHAIN) 35542 This hook is called to initialize a trampoline. M_TRAMP is an RTX 35543 for the memory block for the trampoline; FNDECL is the 35544 'FUNCTION_DECL' for the nested function; STATIC_CHAIN is an RTX for 35545 the static chain value that should be passed to the function when 35546 it is called. 35547 35548 If the target defines 'TARGET_ASM_TRAMPOLINE_TEMPLATE', then the 35549 first thing this hook should do is emit a block move into M_TRAMP 35550 from the memory block returned by 'assemble_trampoline_template'. 35551 Note that the block move need only cover the constant parts of the 35552 trampoline. If the target isolates the variable parts of the 35553 trampoline to the end, not all 'TRAMPOLINE_SIZE' bytes need be 35554 copied. 35555 35556 If the target requires any other actions, such as flushing caches 35557 or enabling stack execution, these actions should be performed 35558 after initializing the trampoline proper. 35559 35560 -- Target Hook: rtx TARGET_TRAMPOLINE_ADJUST_ADDRESS (rtx ADDR) 35561 This hook should perform any machine-specific adjustment in the 35562 address of the trampoline. Its argument contains the address of 35563 the memory block that was passed to 'TARGET_TRAMPOLINE_INIT'. In 35564 case the address to be used for a function call should be different 35565 from the address at which the template was stored, the different 35566 address should be returned; otherwise ADDR should be returned 35567 unchanged. If this hook is not defined, ADDR will be used for 35568 function calls. 35569 35570 Implementing trampolines is difficult on many machines because they 35571have separate instruction and data caches. Writing into a stack 35572location fails to clear the memory in the instruction cache, so when the 35573program jumps to that location, it executes the old contents. 35574 35575 Here are two possible solutions. One is to clear the relevant parts of 35576the instruction cache whenever a trampoline is set up. The other is to 35577make all trampolines identical, by having them jump to a standard 35578subroutine. The former technique makes trampoline execution faster; the 35579latter makes initialization faster. 35580 35581 To clear the instruction cache when a trampoline is initialized, define 35582the following macro. 35583 35584 -- Macro: CLEAR_INSN_CACHE (BEG, END) 35585 If defined, expands to a C expression clearing the _instruction 35586 cache_ in the specified interval. The definition of this macro 35587 would typically be a series of 'asm' statements. Both BEG and END 35588 are both pointer expressions. 35589 35590 To use a standard subroutine, define the following macro. In addition, 35591you must make sure that the instructions in a trampoline fill an entire 35592cache line with identical instructions, or else ensure that the 35593beginning of the trampoline code is always aligned at the same point in 35594its cache line. Look in 'm68k.h' as a guide. 35595 35596 -- Macro: TRANSFER_FROM_TRAMPOLINE 35597 Define this macro if trampolines need a special subroutine to do 35598 their work. The macro should expand to a series of 'asm' 35599 statements which will be compiled with GCC. They go in a library 35600 function named '__transfer_from_trampoline'. 35601 35602 If you need to avoid executing the ordinary prologue code of a 35603 compiled C function when you jump to the subroutine, you can do so 35604 by placing a special label of your own in the assembler code. Use 35605 one 'asm' statement to generate an assembler label, and another to 35606 make the label global. Then trampolines can use that label to jump 35607 directly to your special assembler code. 35608 35609 35610File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros 35611 3561218.12 Implicit Calls to Library Routines 35613======================================== 35614 35615Here is an explanation of implicit calls to library routines. 35616 35617 -- Macro: DECLARE_LIBRARY_RENAMES 35618 This macro, if defined, should expand to a piece of C code that 35619 will get expanded when compiling functions for libgcc.a. It can be 35620 used to provide alternate names for GCC's internal library 35621 functions if there are ABI-mandated names that the compiler should 35622 provide. 35623 35624 -- Target Hook: void TARGET_INIT_LIBFUNCS (void) 35625 This hook should declare additional library routines or rename 35626 existing ones, using the functions 'set_optab_libfunc' and 35627 'init_one_libfunc' defined in 'optabs.c'. 'init_optabs' calls this 35628 macro after initializing all the normal library routines. 35629 35630 The default is to do nothing. Most ports don't need to define this 35631 hook. 35632 35633 -- Target Hook: bool TARGET_LIBFUNC_GNU_PREFIX 35634 If false (the default), internal library routines start with two 35635 underscores. If set to true, these routines start with '__gnu_' 35636 instead. E.g., '__muldi3' changes to '__gnu_muldi3'. This 35637 currently only affects functions defined in 'libgcc2.c'. If this 35638 is set to true, the 'tm.h' file must also '#define 35639 LIBGCC2_GNU_PREFIX'. 35640 35641 -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON) 35642 This macro should return 'true' if the library routine that 35643 implements the floating point comparison operator COMPARISON in 35644 mode MODE will return a boolean, and FALSE if it will return a 35645 tristate. 35646 35647 GCC's own floating point libraries return tristates from the 35648 comparison operators, so the default returns false always. Most 35649 ports don't need to define this macro. 35650 35651 -- Macro: TARGET_LIB_INT_CMP_BIASED 35652 This macro should evaluate to 'true' if the integer comparison 35653 functions (like '__cmpdi2') return 0 to indicate that the first 35654 operand is smaller than the second, 1 to indicate that they are 35655 equal, and 2 to indicate that the first operand is greater than the 35656 second. If this macro evaluates to 'false' the comparison 35657 functions return -1, 0, and 1 instead of 0, 1, and 2. If the 35658 target uses the routines in 'libgcc.a', you do not need to define 35659 this macro. 35660 35661 -- Macro: TARGET_HAS_NO_HW_DIVIDE 35662 This macro should be defined if the target has no hardware divide 35663 instructions. If this macro is defined, GCC will use an algorithm 35664 which make use of simple logical and arithmetic operations for 35665 64-bit division. If the macro is not defined, GCC will use an 35666 algorithm which make use of a 64-bit by 32-bit divide primitive. 35667 35668 -- Macro: TARGET_EDOM 35669 The value of 'EDOM' on the target machine, as a C integer constant 35670 expression. If you don't define this macro, GCC does not attempt 35671 to deposit the value of 'EDOM' into 'errno' directly. Look in 35672 '/usr/include/errno.h' to find the value of 'EDOM' on your system. 35673 35674 If you do not define 'TARGET_EDOM', then compiled code reports 35675 domain errors by calling the library function and letting it report 35676 the error. If mathematical functions on your system use 'matherr' 35677 when there is an error, then you should leave 'TARGET_EDOM' 35678 undefined so that 'matherr' is used normally. 35679 35680 -- Macro: GEN_ERRNO_RTX 35681 Define this macro as a C expression to create an rtl expression 35682 that refers to the global "variable" 'errno'. (On certain systems, 35683 'errno' may not actually be a variable.) If you don't define this 35684 macro, a reasonable default is used. 35685 35686 -- Target Hook: bool TARGET_LIBC_HAS_FUNCTION (enum function_class 35687 FN_CLASS) 35688 This hook determines whether a function from a class of functions 35689 FN_CLASS is present at the runtime. 35690 35691 -- Macro: NEXT_OBJC_RUNTIME 35692 Set this macro to 1 to use the "NeXT" Objective-C message sending 35693 conventions by default. This calling convention involves passing 35694 the object, the selector and the method arguments all at once to 35695 the method-lookup library function. This is the usual setting when 35696 targeting Darwin/Mac OS X systems, which have the NeXT runtime 35697 installed. 35698 35699 If the macro is set to 0, the "GNU" Objective-C message sending 35700 convention will be used by default. This convention passes just 35701 the object and the selector to the method-lookup function, which 35702 returns a pointer to the method. 35703 35704 In either case, it remains possible to select code-generation for 35705 the alternate scheme, by means of compiler command line switches. 35706 35707 35708File: gccint.info, Node: Addressing Modes, Next: Anchored Addresses, Prev: Library Calls, Up: Target Macros 35709 3571018.13 Addressing Modes 35711====================== 35712 35713This is about addressing modes. 35714 35715 -- Macro: HAVE_PRE_INCREMENT 35716 -- Macro: HAVE_PRE_DECREMENT 35717 -- Macro: HAVE_POST_INCREMENT 35718 -- Macro: HAVE_POST_DECREMENT 35719 A C expression that is nonzero if the machine supports 35720 pre-increment, pre-decrement, post-increment, or post-decrement 35721 addressing respectively. 35722 35723 -- Macro: HAVE_PRE_MODIFY_DISP 35724 -- Macro: HAVE_POST_MODIFY_DISP 35725 A C expression that is nonzero if the machine supports pre- or 35726 post-address side-effect generation involving constants other than 35727 the size of the memory operand. 35728 35729 -- Macro: HAVE_PRE_MODIFY_REG 35730 -- Macro: HAVE_POST_MODIFY_REG 35731 A C expression that is nonzero if the machine supports pre- or 35732 post-address side-effect generation involving a register 35733 displacement. 35734 35735 -- Macro: CONSTANT_ADDRESS_P (X) 35736 A C expression that is 1 if the RTX X is a constant which is a 35737 valid address. On most machines the default definition of 35738 '(CONSTANT_P (X) && GET_CODE (X) != CONST_DOUBLE)' is acceptable, 35739 but a few machines are more restrictive as to which constant 35740 addresses are supported. 35741 35742 -- Macro: CONSTANT_P (X) 35743 'CONSTANT_P', which is defined by target-independent code, accepts 35744 integer-values expressions whose values are not explicitly known, 35745 such as 'symbol_ref', 'label_ref', and 'high' expressions and 35746 'const' arithmetic expressions, in addition to 'const_int' and 35747 'const_double' expressions. 35748 35749 -- Macro: MAX_REGS_PER_ADDRESS 35750 A number, the maximum number of registers that can appear in a 35751 valid memory address. Note that it is up to you to specify a value 35752 equal to the maximum number that 'TARGET_LEGITIMATE_ADDRESS_P' 35753 would ever accept. 35754 35755 -- Target Hook: bool TARGET_LEGITIMATE_ADDRESS_P (machine_mode MODE, 35756 rtx X, bool STRICT) 35757 A function that returns whether X (an RTX) is a legitimate memory 35758 address on the target machine for a memory operand of mode MODE. 35759 35760 Legitimate addresses are defined in two variants: a strict variant 35761 and a non-strict one. The STRICT parameter chooses which variant 35762 is desired by the caller. 35763 35764 The strict variant is used in the reload pass. It must be defined 35765 so that any pseudo-register that has not been allocated a hard 35766 register is considered a memory reference. This is because in 35767 contexts where some kind of register is required, a pseudo-register 35768 with no hard register must be rejected. For non-hard registers, 35769 the strict variant should look up the 'reg_renumber' array; it 35770 should then proceed using the hard register number in the array, or 35771 treat the pseudo as a memory reference if the array holds '-1'. 35772 35773 The non-strict variant is used in other passes. It must be defined 35774 to accept all pseudo-registers in every context where some kind of 35775 register is required. 35776 35777 Normally, constant addresses which are the sum of a 'symbol_ref' 35778 and an integer are stored inside a 'const' RTX to mark them as 35779 constant. Therefore, there is no need to recognize such sums 35780 specifically as legitimate addresses. Normally you would simply 35781 recognize any 'const' as legitimate. 35782 35783 Usually 'PRINT_OPERAND_ADDRESS' is not prepared to handle constant 35784 sums that are not marked with 'const'. It assumes that a naked 35785 'plus' indicates indexing. If so, then you _must_ reject such 35786 naked constant sums as illegitimate addresses, so that none of them 35787 will be given to 'PRINT_OPERAND_ADDRESS'. 35788 35789 On some machines, whether a symbolic address is legitimate depends 35790 on the section that the address refers to. On these machines, 35791 define the target hook 'TARGET_ENCODE_SECTION_INFO' to store the 35792 information into the 'symbol_ref', and then check for it here. 35793 When you see a 'const', you will have to look inside it to find the 35794 'symbol_ref' in order to determine the section. *Note Assembler 35795 Format::. 35796 35797 Some ports are still using a deprecated legacy substitute for this 35798 hook, the 'GO_IF_LEGITIMATE_ADDRESS' macro. This macro has this 35799 syntax: 35800 35801 #define GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL) 35802 35803 and should 'goto LABEL' if the address X is a valid address on the 35804 target machine for a memory operand of mode MODE. 35805 35806 Compiler source files that want to use the strict variant of this 35807 macro define the macro 'REG_OK_STRICT'. You should use an '#ifdef 35808 REG_OK_STRICT' conditional to define the strict variant in that 35809 case and the non-strict variant otherwise. 35810 35811 Using the hook is usually simpler because it limits the number of 35812 files that are recompiled when changes are made. 35813 35814 -- Macro: TARGET_MEM_CONSTRAINT 35815 A single character to be used instead of the default ''m'' 35816 character for general memory addresses. This defines the 35817 constraint letter which matches the memory addresses accepted by 35818 'TARGET_LEGITIMATE_ADDRESS_P'. Define this macro if you want to 35819 support new address formats in your back end without changing the 35820 semantics of the ''m'' constraint. This is necessary in order to 35821 preserve functionality of inline assembly constructs using the 35822 ''m'' constraint. 35823 35824 -- Macro: FIND_BASE_TERM (X) 35825 A C expression to determine the base term of address X, or to 35826 provide a simplified version of X from which 'alias.c' can easily 35827 find the base term. This macro is used in only two places: 35828 'find_base_value' and 'find_base_term' in 'alias.c'. 35829 35830 It is always safe for this macro to not be defined. It exists so 35831 that alias analysis can understand machine-dependent addresses. 35832 35833 The typical use of this macro is to handle addresses containing a 35834 label_ref or symbol_ref within an UNSPEC. 35835 35836 -- Target Hook: rtx TARGET_LEGITIMIZE_ADDRESS (rtx X, rtx OLDX, 35837 machine_mode MODE) 35838 This hook is given an invalid memory address X for an operand of 35839 mode MODE and should try to return a valid memory address. 35840 35841 X will always be the result of a call to 'break_out_memory_refs', 35842 and OLDX will be the operand that was given to that function to 35843 produce X. 35844 35845 The code of the hook should not alter the substructure of X. If it 35846 transforms X into a more legitimate form, it should return the new 35847 X. 35848 35849 It is not necessary for this hook to come up with a legitimate 35850 address, with the exception of native TLS addresses (*note Emulated 35851 TLS::). The compiler has standard ways of doing so in all cases. 35852 In fact, if the target supports only emulated TLS, it is safe to 35853 omit this hook or make it return X if it cannot find a valid way to 35854 legitimize the address. But often a machine-dependent strategy can 35855 generate better code. 35856 35857 -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, 35858 WIN) 35859 A C compound statement that attempts to replace X, which is an 35860 address that needs reloading, with a valid memory address for an 35861 operand of mode MODE. WIN will be a C statement label elsewhere in 35862 the code. It is not necessary to define this macro, but it might 35863 be useful for performance reasons. 35864 35865 For example, on the i386, it is sometimes possible to use a single 35866 reload register instead of two by reloading a sum of two pseudo 35867 registers into a register. On the other hand, for number of RISC 35868 processors offsets are limited so that often an intermediate 35869 address needs to be generated in order to address a stack slot. By 35870 defining 'LEGITIMIZE_RELOAD_ADDRESS' appropriately, the 35871 intermediate addresses generated for adjacent some stack slots can 35872 be made identical, and thus be shared. 35873 35874 _Note_: This macro should be used with caution. It is necessary to 35875 know something of how reload works in order to effectively use 35876 this, and it is quite easy to produce macros that build in too much 35877 knowledge of reload internals. 35878 35879 _Note_: This macro must be able to reload an address created by a 35880 previous invocation of this macro. If it fails to handle such 35881 addresses then the compiler may generate incorrect code or abort. 35882 35883 The macro definition should use 'push_reload' to indicate parts 35884 that need reloading; OPNUM, TYPE and IND_LEVELS are usually 35885 suitable to be passed unaltered to 'push_reload'. 35886 35887 The code generated by this macro must not alter the substructure of 35888 X. If it transforms X into a more legitimate form, it should 35889 assign X (which will always be a C variable) a new value. This 35890 also applies to parts that you change indirectly by calling 35891 'push_reload'. 35892 35893 The macro definition may use 'strict_memory_address_p' to test if 35894 the address has become legitimate. 35895 35896 If you want to change only a part of X, one standard way of doing 35897 this is to use 'copy_rtx'. Note, however, that it unshares only a 35898 single level of rtl. Thus, if the part to be changed is not at the 35899 top level, you'll need to replace first the top level. It is not 35900 necessary for this macro to come up with a legitimate address; but 35901 often a machine-dependent strategy can generate better code. 35902 35903 -- Target Hook: bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx ADDR, 35904 addr_space_t ADDRSPACE) 35905 This hook returns 'true' if memory address ADDR in address space 35906 ADDRSPACE can have different meanings depending on the machine mode 35907 of the memory reference it is used for or if the address is valid 35908 for some modes but not others. 35909 35910 Autoincrement and autodecrement addresses typically have 35911 mode-dependent effects because the amount of the increment or 35912 decrement is the size of the operand being addressed. Some 35913 machines have other mode-dependent addresses. Many RISC machines 35914 have no mode-dependent addresses. 35915 35916 You may assume that ADDR is a valid address for the machine. 35917 35918 The default version of this hook returns 'false'. 35919 35920 -- Target Hook: bool TARGET_LEGITIMATE_CONSTANT_P (machine_mode MODE, 35921 rtx X) 35922 This hook returns true if X is a legitimate constant for a 35923 MODE-mode immediate operand on the target machine. You can assume 35924 that X satisfies 'CONSTANT_P', so you need not check this. 35925 35926 The default definition returns true. 35927 35928 -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X) 35929 This hook is used to undo the possibly obfuscating effects of the 35930 'LEGITIMIZE_ADDRESS' and 'LEGITIMIZE_RELOAD_ADDRESS' target macros. 35931 Some backend implementations of these macros wrap symbol references 35932 inside an 'UNSPEC' rtx to represent PIC or similar addressing 35933 modes. This target hook allows GCC's optimizers to understand the 35934 semantics of these opaque 'UNSPEC's by converting them back into 35935 their original form. 35936 35937 -- Target Hook: bool TARGET_CONST_NOT_OK_FOR_DEBUG_P (rtx X) 35938 This hook should return true if X should not be emitted into debug 35939 sections. 35940 35941 -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (machine_mode MODE, 35942 rtx X) 35943 This hook should return true if X is of a form that cannot (or 35944 should not) be spilled to the constant pool. MODE is the mode of 35945 X. 35946 35947 The default version of this hook returns false. 35948 35949 The primary reason to define this hook is to prevent reload from 35950 deciding that a non-legitimate constant would be better reloaded 35951 from the constant pool instead of spilling and reloading a register 35952 holding the constant. This restriction is often true of addresses 35953 of TLS symbols for various targets. 35954 35955 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (machine_mode 35956 MODE, const_rtx X) 35957 This hook should return true if pool entries for constant X can be 35958 placed in an 'object_block' structure. MODE is the mode of X. 35959 35960 The default version returns false for all constants. 35961 35962 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_DECL_P (const_tree DECL) 35963 This hook should return true if pool entries for DECL should be 35964 placed in an 'object_block' structure. 35965 35966 The default version returns true for all decls. 35967 35968 -- Target Hook: tree TARGET_BUILTIN_RECIPROCAL (tree FNDECL) 35969 This hook should return the DECL of a function that implements the 35970 reciprocal of the machine-specific builtin function FNDECL, or 35971 'NULL_TREE' if such a function is not available. 35972 35973 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void) 35974 This hook should return the DECL of a function F that given an 35975 address ADDR as an argument returns a mask M that can be used to 35976 extract from two vectors the relevant data that resides in ADDR in 35977 case ADDR is not properly aligned. 35978 35979 The autovectorizer, when vectorizing a load operation from an 35980 address ADDR that may be unaligned, will generate two vector loads 35981 from the two aligned addresses around ADDR. It then generates a 35982 'REALIGN_LOAD' operation to extract the relevant data from the two 35983 loaded vectors. The first two arguments to 'REALIGN_LOAD', V1 and 35984 V2, are the two vectors, each of size VS, and the third argument, 35985 OFF, defines how the data will be extracted from these two vectors: 35986 if OFF is 0, then the returned vector is V2; otherwise, the 35987 returned vector is composed from the last VS-OFF elements of V1 35988 concatenated to the first OFF elements of V2. 35989 35990 If this hook is defined, the autovectorizer will generate a call to 35991 F (using the DECL tree that this hook returns) and will use the 35992 return value of F as the argument OFF to 'REALIGN_LOAD'. 35993 Therefore, the mask M returned by F should comply with the 35994 semantics expected by 'REALIGN_LOAD' described above. If this hook 35995 is not defined, then ADDR will be used as the argument OFF to 35996 'REALIGN_LOAD', in which case the low log2(VS) - 1 bits of ADDR 35997 will be considered. 35998 35999 -- Target Hook: int TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST (enum 36000 vect_cost_for_stmt TYPE_OF_COST, tree VECTYPE, int MISALIGN) 36001 Returns cost of different scalar or vector statements for 36002 vectorization cost model. For vector memory operations the cost 36003 may depend on type (VECTYPE) and misalignment value (MISALIGN). 36004 36005 -- Target Hook: poly_uint64 TARGET_VECTORIZE_PREFERRED_VECTOR_ALIGNMENT 36006 (const_tree TYPE) 36007 This hook returns the preferred alignment in bits for accesses to 36008 vectors of type TYPE in vectorized code. This might be less than 36009 or greater than the ABI-defined value returned by 36010 'TARGET_VECTOR_ALIGNMENT'. It can be equal to the alignment of a 36011 single element, in which case the vectorizer will not try to 36012 optimize for alignment. 36013 36014 The default hook returns 'TYPE_ALIGN (TYPE)', which is correct for 36015 most targets. 36016 36017 -- Target Hook: bool TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE 36018 (const_tree TYPE, bool IS_PACKED) 36019 Return true if vector alignment is reachable (by peeling N 36020 iterations) for the given scalar type TYPE. IS_PACKED is false if 36021 the scalar access using TYPE is known to be naturally aligned. 36022 36023 -- Target Hook: bool TARGET_VECTORIZE_VEC_PERM_CONST (machine_mode 36024 MODE, rtx OUTPUT, rtx IN0, rtx IN1, const vec_perm_indices 36025 &SEL) 36026 This hook is used to test whether the target can permute up to two 36027 vectors of mode MODE using the permutation vector 'sel', and also 36028 to emit such a permutation. In the former case IN0, IN1 and OUT 36029 are all null. In the latter case IN0 and IN1 are the source 36030 vectors and OUT is the destination vector; all three are registers 36031 of mode MODE. IN1 is the same as IN0 if SEL describes a 36032 permutation on one vector instead of two. 36033 36034 Return true if the operation is possible, emitting instructions for 36035 it if rtxes are provided. 36036 36037 If the hook returns false for a mode with multibyte elements, GCC 36038 will try the equivalent byte operation. If that also fails, it 36039 will try forcing the selector into a register and using the 36040 VEC_PERMMODE instruction pattern. There is no need for the hook to 36041 handle these two implementation approaches itself. 36042 36043 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_CONVERSION (unsigned 36044 CODE, tree DEST_TYPE, tree SRC_TYPE) 36045 This hook should return the DECL of a function that implements 36046 conversion of the input vector of type SRC_TYPE to type DEST_TYPE. 36047 The value of CODE is one of the enumerators in 'enum tree_code' and 36048 specifies how the conversion is to be applied (truncation, 36049 rounding, etc.). 36050 36051 If this hook is defined, the autovectorizer will use the 36052 'TARGET_VECTORIZE_BUILTIN_CONVERSION' target hook when vectorizing 36053 conversion. Otherwise, it will return 'NULL_TREE'. 36054 36055 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION 36056 (unsigned CODE, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 36057 This hook should return the decl of a function that implements the 36058 vectorized variant of the function with the 'combined_fn' code CODE 36059 or 'NULL_TREE' if such a function is not available. The return 36060 type of the vectorized function shall be of vector type 36061 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 36062 36063 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION 36064 (tree FNDECL, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 36065 This hook should return the decl of a function that implements the 36066 vectorized variant of target built-in function 'fndecl'. The 36067 return type of the vectorized function shall be of vector type 36068 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 36069 36070 -- Target Hook: bool TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT 36071 (machine_mode MODE, const_tree TYPE, int MISALIGNMENT, bool 36072 IS_PACKED) 36073 This hook should return true if the target supports misaligned 36074 vector store/load of a specific factor denoted in the MISALIGNMENT 36075 parameter. The vector store/load should be of machine mode MODE 36076 and the elements in the vectors should be of type TYPE. IS_PACKED 36077 parameter is true if the memory access is defined in a packed 36078 struct. 36079 36080 -- Target Hook: machine_mode TARGET_VECTORIZE_PREFERRED_SIMD_MODE 36081 (scalar_mode MODE) 36082 This hook should return the preferred mode for vectorizing scalar 36083 mode MODE. The default is equal to 'word_mode', because the 36084 vectorizer can do some transformations even in absence of 36085 specialized SIMD hardware. 36086 36087 -- Target Hook: machine_mode TARGET_VECTORIZE_SPLIT_REDUCTION 36088 (machine_mode) 36089 This hook should return the preferred mode to split the final 36090 reduction step on MODE to. The reduction is then carried out 36091 reducing upper against lower halves of vectors recursively until 36092 the specified mode is reached. The default is MODE which means no 36093 splitting. 36094 36095 -- Target Hook: void TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES 36096 (vector_sizes *SIZES) 36097 If the mode returned by 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE' is 36098 not the only one that is worth considering, this hook should add 36099 all suitable vector sizes to SIZES, in order of decreasing 36100 preference. The first one should be the size of 36101 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE'. 36102 36103 The hook does not need to do anything if the vector returned by 36104 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE' is the only one relevant for 36105 autovectorization. The default implementation does nothing. 36106 36107 -- Target Hook: opt_machine_mode TARGET_VECTORIZE_GET_MASK_MODE 36108 (poly_uint64 NUNITS, poly_uint64 LENGTH) 36109 A vector mask is a value that holds one boolean result for every 36110 element in a vector. This hook returns the machine mode that 36111 should be used to represent such a mask when the vector in question 36112 is LENGTH bytes long and contains NUNITS elements. The hook 36113 returns an empty 'opt_machine_mode' if no such mode exists. 36114 36115 The default implementation returns the mode of an integer vector 36116 that is LENGTH bytes long and that contains NUNITS elements, if 36117 such a mode exists. 36118 36119 -- Target Hook: bool TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE (unsigned 36120 IFN) 36121 This hook returns true if masked internal function IFN (really of 36122 type 'internal_fn') should be considered expensive when the mask is 36123 all zeros. GCC can then try to branch around the instruction 36124 instead. 36125 36126 -- Target Hook: void * TARGET_VECTORIZE_INIT_COST (struct loop 36127 *LOOP_INFO) 36128 This hook should initialize target-specific data structures in 36129 preparation for modeling the costs of vectorizing a loop or basic 36130 block. The default allocates three unsigned integers for 36131 accumulating costs for the prologue, body, and epilogue of the loop 36132 or basic block. If LOOP_INFO is non-NULL, it identifies the loop 36133 being vectorized; otherwise a single block is being vectorized. 36134 36135 -- Target Hook: unsigned TARGET_VECTORIZE_ADD_STMT_COST (void *DATA, 36136 int COUNT, enum vect_cost_for_stmt KIND, struct _stmt_vec_info 36137 *STMT_INFO, int MISALIGN, enum vect_cost_model_location WHERE) 36138 This hook should update the target-specific DATA in response to 36139 adding COUNT copies of the given KIND of statement to a loop or 36140 basic block. The default adds the builtin vectorizer cost for the 36141 copies of the statement to the accumulator specified by WHERE, (the 36142 prologue, body, or epilogue) and returns the amount added. The 36143 return value should be viewed as a tentative cost that may later be 36144 revised. 36145 36146 -- Target Hook: void TARGET_VECTORIZE_FINISH_COST (void *DATA, unsigned 36147 *PROLOGUE_COST, unsigned *BODY_COST, unsigned *EPILOGUE_COST) 36148 This hook should complete calculations of the cost of vectorizing a 36149 loop or basic block based on DATA, and return the prologue, body, 36150 and epilogue costs as unsigned integers. The default returns the 36151 value of the three accumulators. 36152 36153 -- Target Hook: void TARGET_VECTORIZE_DESTROY_COST_DATA (void *DATA) 36154 This hook should release DATA and any related data structures 36155 allocated by TARGET_VECTORIZE_INIT_COST. The default releases the 36156 accumulator. 36157 36158 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_GATHER (const_tree 36159 MEM_VECTYPE, const_tree INDEX_TYPE, int SCALE) 36160 Target builtin that implements vector gather operation. 36161 MEM_VECTYPE is the vector type of the load and INDEX_TYPE is scalar 36162 type of the index, scaled by SCALE. The default is 'NULL_TREE' 36163 which means to not vectorize gather loads. 36164 36165 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_SCATTER (const_tree 36166 VECTYPE, const_tree INDEX_TYPE, int SCALE) 36167 Target builtin that implements vector scatter operation. VECTYPE 36168 is the vector type of the store and INDEX_TYPE is scalar type of 36169 the index, scaled by SCALE. The default is 'NULL_TREE' which means 36170 to not vectorize scatter stores. 36171 36172 -- Target Hook: int TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN 36173 (struct cgraph_node *, struct cgraph_simd_clone *, TREE, INT) 36174 This hook should set VECSIZE_MANGLE, VECSIZE_INT, VECSIZE_FLOAT 36175 fields in SIMD_CLONE structure pointed by CLONE_INFO argument and 36176 also SIMDLEN field if it was previously 0. The hook should return 36177 0 if SIMD clones shouldn't be emitted, or number of VECSIZE_MANGLE 36178 variants that should be emitted. 36179 36180 -- Target Hook: void TARGET_SIMD_CLONE_ADJUST (struct cgraph_node *) 36181 This hook should add implicit 'attribute(target("..."))' attribute 36182 to SIMD clone NODE if needed. 36183 36184 -- Target Hook: int TARGET_SIMD_CLONE_USABLE (struct cgraph_node *) 36185 This hook should return -1 if SIMD clone NODE shouldn't be used in 36186 vectorized loops in current function, or non-negative number if it 36187 is usable. In that case, the smaller the number is, the more 36188 desirable it is to use it. 36189 36190 -- Target Hook: int TARGET_SIMT_VF (void) 36191 Return number of threads in SIMT thread group on the target. 36192 36193 -- Target Hook: bool TARGET_GOACC_VALIDATE_DIMS (tree DECL, int *DIMS, 36194 int FN_LEVEL, unsigned USED) 36195 This hook should check the launch dimensions provided for an 36196 OpenACC compute region, or routine. Defaulted values are 36197 represented as -1 and non-constant values as 0. The FN_LEVEL is 36198 negative for the function corresponding to the compute region. For 36199 a routine is is the outermost level at which partitioned execution 36200 may be spawned. The hook should verify non-default values. If 36201 DECL is NULL, global defaults are being validated and unspecified 36202 defaults should be filled in. Diagnostics should be issued as 36203 appropriate. Return true, if changes have been made. You must 36204 override this hook to provide dimensions larger than 1. 36205 36206 -- Target Hook: int TARGET_GOACC_DIM_LIMIT (int AXIS) 36207 This hook should return the maximum size of a particular dimension, 36208 or zero if unbounded. 36209 36210 -- Target Hook: bool TARGET_GOACC_FORK_JOIN (gcall *CALL, const int 36211 *DIMS, bool IS_FORK) 36212 This hook can be used to convert IFN_GOACC_FORK and IFN_GOACC_JOIN 36213 function calls to target-specific gimple, or indicate whether they 36214 should be retained. It is executed during the oacc_device_lower 36215 pass. It should return true, if the call should be retained. It 36216 should return false, if it is to be deleted (either because 36217 target-specific gimple has been inserted before it, or there is no 36218 need for it). The default hook returns false, if there are no RTL 36219 expanders for them. 36220 36221 -- Target Hook: void TARGET_GOACC_REDUCTION (gcall *CALL) 36222 This hook is used by the oacc_transform pass to expand calls to the 36223 GOACC_REDUCTION internal function, into a sequence of gimple 36224 instructions. CALL is gimple statement containing the call to the 36225 function. This hook removes statement CALL after the expanded 36226 sequence has been inserted. This hook is also responsible for 36227 allocating any storage for reductions when necessary. 36228 36229 -- Target Hook: tree TARGET_PREFERRED_ELSE_VALUE (unsigned IFN, tree 36230 TYPE, unsigned NOPS, tree *OPS) 36231 This hook returns the target's preferred final argument for a call 36232 to conditional internal function IFN (really of type 36233 'internal_fn'). TYPE specifies the return type of the function and 36234 OPS are the operands to the conditional operation, of which there 36235 are NOPS. 36236 36237 For example, if IFN is 'IFN_COND_ADD', the hook returns a value of 36238 type TYPE that should be used when 'OPS[0]' and 'OPS[1]' are 36239 conditionally added together. 36240 36241 This hook is only relevant if the target supports conditional 36242 patterns like 'cond_addM'. The default implementation returns a 36243 zero constant of type TYPE. 36244 36245 36246File: gccint.info, Node: Anchored Addresses, Next: Condition Code, Prev: Addressing Modes, Up: Target Macros 36247 3624818.14 Anchored Addresses 36249======================== 36250 36251GCC usually addresses every static object as a separate entity. For 36252example, if we have: 36253 36254 static int a, b, c; 36255 int foo (void) { return a + b + c; } 36256 36257 the code for 'foo' will usually calculate three separate symbolic 36258addresses: those of 'a', 'b' and 'c'. On some targets, it would be 36259better to calculate just one symbolic address and access the three 36260variables relative to it. The equivalent pseudocode would be something 36261like: 36262 36263 int foo (void) 36264 { 36265 register int *xr = &x; 36266 return xr[&a - &x] + xr[&b - &x] + xr[&c - &x]; 36267 } 36268 36269 (which isn't valid C). We refer to shared addresses like 'x' as 36270"section anchors". Their use is controlled by '-fsection-anchors'. 36271 36272 The hooks below describe the target properties that GCC needs to know 36273in order to make effective use of section anchors. It won't use section 36274anchors at all unless either 'TARGET_MIN_ANCHOR_OFFSET' or 36275'TARGET_MAX_ANCHOR_OFFSET' is set to a nonzero value. 36276 36277 -- Target Hook: HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET 36278 The minimum offset that should be applied to a section anchor. On 36279 most targets, it should be the smallest offset that can be applied 36280 to a base register while still giving a legitimate address for 36281 every mode. The default value is 0. 36282 36283 -- Target Hook: HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET 36284 Like 'TARGET_MIN_ANCHOR_OFFSET', but the maximum (inclusive) offset 36285 that should be applied to section anchors. The default value is 0. 36286 36287 -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X) 36288 Write the assembly code to define section anchor X, which is a 36289 'SYMBOL_REF' for which 'SYMBOL_REF_ANCHOR_P (X)' is true. The hook 36290 is called with the assembly output position set to the beginning of 36291 'SYMBOL_REF_BLOCK (X)'. 36292 36293 If 'ASM_OUTPUT_DEF' is available, the hook's default definition 36294 uses it to define the symbol as '. + SYMBOL_REF_BLOCK_OFFSET (X)'. 36295 If 'ASM_OUTPUT_DEF' is not available, the hook's default definition 36296 is 'NULL', which disables the use of section anchors altogether. 36297 36298 -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (const_rtx X) 36299 Return true if GCC should attempt to use anchors to access 36300 'SYMBOL_REF' X. You can assume 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)' 36301 and '!SYMBOL_REF_ANCHOR_P (X)'. 36302 36303 The default version is correct for most targets, but you might need 36304 to intercept this hook to handle things like target-specific 36305 attributes or target-specific sections. 36306 36307 36308File: gccint.info, Node: Condition Code, Next: Costs, Prev: Anchored Addresses, Up: Target Macros 36309 3631018.15 Condition Code Status 36311=========================== 36312 36313The macros in this section can be split in two families, according to 36314the two ways of representing condition codes in GCC. 36315 36316 The first representation is the so called '(cc0)' representation (*note 36317Jump Patterns::), where all instructions can have an implicit clobber of 36318the condition codes. The second is the condition code register 36319representation, which provides better schedulability for architectures 36320that do have a condition code register, but on which most instructions 36321do not affect it. The latter category includes most RISC machines. 36322 36323 The implicit clobbering poses a strong restriction on the placement of 36324the definition and use of the condition code. In the past the 36325definition and use were always adjacent. However, recent changes to 36326support trapping arithmatic may result in the definition and user being 36327in different blocks. Thus, there may be a 'NOTE_INSN_BASIC_BLOCK' 36328between them. Additionally, the definition may be the source of 36329exception handling edges. 36330 36331 These restrictions can prevent important optimizations on some 36332machines. For example, on the IBM RS/6000, there is a delay for taken 36333branches unless the condition code register is set three instructions 36334earlier than the conditional branch. The instruction scheduler cannot 36335perform this optimization if it is not permitted to separate the 36336definition and use of the condition code register. 36337 36338 For this reason, it is possible and suggested to use a register to 36339represent the condition code for new ports. If there is a specific 36340condition code register in the machine, use a hard register. If the 36341condition code or comparison result can be placed in any general 36342register, or if there are multiple condition registers, use a pseudo 36343register. Registers used to store the condition code value will usually 36344have a mode that is in class 'MODE_CC'. 36345 36346 Alternatively, you can use 'BImode' if the comparison operator is 36347specified already in the compare instruction. In this case, you are not 36348interested in most macros in this section. 36349 36350* Menu: 36351 36352* CC0 Condition Codes:: Old style representation of condition codes. 36353* MODE_CC Condition Codes:: Modern representation of condition codes. 36354 36355 36356File: gccint.info, Node: CC0 Condition Codes, Next: MODE_CC Condition Codes, Up: Condition Code 36357 3635818.15.1 Representation of condition codes using '(cc0)' 36359------------------------------------------------------- 36360 36361The file 'conditions.h' defines a variable 'cc_status' to describe how 36362the condition code was computed (in case the interpretation of the 36363condition code depends on the instruction that it was set by). This 36364variable contains the RTL expressions on which the condition code is 36365currently based, and several standard flags. 36366 36367 Sometimes additional machine-specific flags must be defined in the 36368machine description header file. It can also add additional 36369machine-specific information by defining 'CC_STATUS_MDEP'. 36370 36371 -- Macro: CC_STATUS_MDEP 36372 C code for a data type which is used for declaring the 'mdep' 36373 component of 'cc_status'. It defaults to 'int'. 36374 36375 This macro is not used on machines that do not use 'cc0'. 36376 36377 -- Macro: CC_STATUS_MDEP_INIT 36378 A C expression to initialize the 'mdep' field to "empty". The 36379 default definition does nothing, since most machines don't use the 36380 field anyway. If you want to use the field, you should probably 36381 define this macro to initialize it. 36382 36383 This macro is not used on machines that do not use 'cc0'. 36384 36385 -- Macro: NOTICE_UPDATE_CC (EXP, INSN) 36386 A C compound statement to set the components of 'cc_status' 36387 appropriately for an insn INSN whose body is EXP. It is this 36388 macro's responsibility to recognize insns that set the condition 36389 code as a byproduct of other activity as well as those that 36390 explicitly set '(cc0)'. 36391 36392 This macro is not used on machines that do not use 'cc0'. 36393 36394 If there are insns that do not set the condition code but do alter 36395 other machine registers, this macro must check to see whether they 36396 invalidate the expressions that the condition code is recorded as 36397 reflecting. For example, on the 68000, insns that store in address 36398 registers do not set the condition code, which means that usually 36399 'NOTICE_UPDATE_CC' can leave 'cc_status' unaltered for such insns. 36400 But suppose that the previous insn set the condition code based on 36401 location 'a4@(102)' and the current insn stores a new value in 36402 'a4'. Although the condition code is not changed by this, it will 36403 no longer be true that it reflects the contents of 'a4@(102)'. 36404 Therefore, 'NOTICE_UPDATE_CC' must alter 'cc_status' in this case 36405 to say that nothing is known about the condition code value. 36406 36407 The definition of 'NOTICE_UPDATE_CC' must be prepared to deal with 36408 the results of peephole optimization: insns whose patterns are 36409 'parallel' RTXs containing various 'reg', 'mem' or constants which 36410 are just the operands. The RTL structure of these insns is not 36411 sufficient to indicate what the insns actually do. What 36412 'NOTICE_UPDATE_CC' should do when it sees one is just to run 36413 'CC_STATUS_INIT'. 36414 36415 A possible definition of 'NOTICE_UPDATE_CC' is to call a function 36416 that looks at an attribute (*note Insn Attributes::) named, for 36417 example, 'cc'. This avoids having detailed information about 36418 patterns in two places, the 'md' file and in 'NOTICE_UPDATE_CC'. 36419 36420 36421File: gccint.info, Node: MODE_CC Condition Codes, Prev: CC0 Condition Codes, Up: Condition Code 36422 3642318.15.2 Representation of condition codes using registers 36424--------------------------------------------------------- 36425 36426 -- Macro: SELECT_CC_MODE (OP, X, Y) 36427 On many machines, the condition code may be produced by other 36428 instructions than compares, for example the branch can use directly 36429 the condition code set by a subtract instruction. However, on some 36430 machines when the condition code is set this way some bits (such as 36431 the overflow bit) are not set in the same way as a test 36432 instruction, so that a different branch instruction must be used 36433 for some conditional branches. When this happens, use the machine 36434 mode of the condition code register to record different formats of 36435 the condition code register. Modes can also be used to record 36436 which compare instruction (e.g. a signed or an unsigned comparison) 36437 produced the condition codes. 36438 36439 If other modes than 'CCmode' are required, add them to 36440 'MACHINE-modes.def' and define 'SELECT_CC_MODE' to choose a mode 36441 given an operand of a compare. This is needed because the modes 36442 have to be chosen not only during RTL generation but also, for 36443 example, by instruction combination. The result of 36444 'SELECT_CC_MODE' should be consistent with the mode used in the 36445 patterns; for example to support the case of the add on the SPARC 36446 discussed above, we have the pattern 36447 36448 (define_insn "" 36449 [(set (reg:CCNZ 0) 36450 (compare:CCNZ 36451 (plus:SI (match_operand:SI 0 "register_operand" "%r") 36452 (match_operand:SI 1 "arith_operand" "rI")) 36453 (const_int 0)))] 36454 "" 36455 "...") 36456 36457 together with a 'SELECT_CC_MODE' that returns 'CCNZmode' for 36458 comparisons whose argument is a 'plus': 36459 36460 #define SELECT_CC_MODE(OP,X,Y) \ 36461 (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ 36462 ? ((OP == LT || OP == LE || OP == GT || OP == GE) \ 36463 ? CCFPEmode : CCFPmode) \ 36464 : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ 36465 || GET_CODE (X) == NEG || GET_CODE (x) == ASHIFT) \ 36466 ? CCNZmode : CCmode)) 36467 36468 Another reason to use modes is to retain information on which 36469 operands were used by the comparison; see 'REVERSIBLE_CC_MODE' 36470 later in this section. 36471 36472 You should define this macro if and only if you define extra CC 36473 modes in 'MACHINE-modes.def'. 36474 36475 -- Target Hook: void TARGET_CANONICALIZE_COMPARISON (int *CODE, rtx 36476 *OP0, rtx *OP1, bool OP0_PRESERVE_VALUE) 36477 On some machines not all possible comparisons are defined, but you 36478 can convert an invalid comparison into a valid one. For example, 36479 the Alpha does not have a 'GT' comparison, but you can use an 'LT' 36480 comparison instead and swap the order of the operands. 36481 36482 On such machines, implement this hook to do any required 36483 conversions. CODE is the initial comparison code and OP0 and OP1 36484 are the left and right operands of the comparison, respectively. 36485 If OP0_PRESERVE_VALUE is 'true' the implementation is not allowed 36486 to change the value of OP0 since the value might be used in RTXs 36487 which aren't comparisons. E.g. the implementation is not allowed 36488 to swap operands in that case. 36489 36490 GCC will not assume that the comparison resulting from this macro 36491 is valid but will see if the resulting insn matches a pattern in 36492 the 'md' file. 36493 36494 You need not to implement this hook if it would never change the 36495 comparison code or operands. 36496 36497 -- Macro: REVERSIBLE_CC_MODE (MODE) 36498 A C expression whose value is one if it is always safe to reverse a 36499 comparison whose mode is MODE. If 'SELECT_CC_MODE' can ever return 36500 MODE for a floating-point inequality comparison, then 36501 'REVERSIBLE_CC_MODE (MODE)' must be zero. 36502 36503 You need not define this macro if it would always returns zero or 36504 if the floating-point format is anything other than 36505 'IEEE_FLOAT_FORMAT'. For example, here is the definition used on 36506 the SPARC, where floating-point inequality comparisons are given 36507 either 'CCFPEmode' or 'CCFPmode': 36508 36509 #define REVERSIBLE_CC_MODE(MODE) \ 36510 ((MODE) != CCFPEmode && (MODE) != CCFPmode) 36511 36512 -- Macro: REVERSE_CONDITION (CODE, MODE) 36513 A C expression whose value is reversed condition code of the CODE 36514 for comparison done in CC_MODE MODE. The macro is used only in 36515 case 'REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in 36516 case machine has some non-standard way how to reverse certain 36517 conditionals. For instance in case all floating point conditions 36518 are non-trapping, compiler may freely convert unordered compares to 36519 ordered ones. Then definition may look like: 36520 36521 #define REVERSE_CONDITION(CODE, MODE) \ 36522 ((MODE) != CCFPmode ? reverse_condition (CODE) \ 36523 : reverse_condition_maybe_unordered (CODE)) 36524 36525 -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int 36526 *P1, unsigned int *P2) 36527 On targets which do not use '(cc0)', and which use a hard register 36528 rather than a pseudo-register to hold condition codes, the regular 36529 CSE passes are often not able to identify cases in which the hard 36530 register is set to a common value. Use this hook to enable a small 36531 pass which optimizes such cases. This hook should return true to 36532 enable this pass, and it should set the integers to which its 36533 arguments point to the hard register numbers used for condition 36534 codes. When there is only one such register, as is true on most 36535 systems, the integer pointed to by P2 should be set to 36536 'INVALID_REGNUM'. 36537 36538 The default version of this hook returns false. 36539 36540 -- Target Hook: machine_mode TARGET_CC_MODES_COMPATIBLE (machine_mode 36541 M1, machine_mode M2) 36542 On targets which use multiple condition code modes in class 36543 'MODE_CC', it is sometimes the case that a comparison can be 36544 validly done in more than one mode. On such a system, define this 36545 target hook to take two mode arguments and to return a mode in 36546 which both comparisons may be validly done. If there is no such 36547 mode, return 'VOIDmode'. 36548 36549 The default version of this hook checks whether the modes are the 36550 same. If they are, it returns that mode. If they are different, 36551 it returns 'VOIDmode'. 36552 36553 -- Target Hook: unsigned int TARGET_FLAGS_REGNUM 36554 If the target has a dedicated flags register, and it needs to use 36555 the post-reload comparison elimination pass, then this value should 36556 be set appropriately. 36557 36558 36559File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros 36560 3656118.16 Describing Relative Costs of Operations 36562============================================= 36563 36564These macros let you describe the relative speed of various operations 36565on the target machine. 36566 36567 -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO) 36568 A C expression for the cost of moving data of mode MODE from a 36569 register in class FROM to one in class TO. The classes are 36570 expressed using the enumeration values such as 'GENERAL_REGS'. A 36571 value of 2 is the default; other values are interpreted relative to 36572 that. 36573 36574 It is not required that the cost always equal 2 when FROM is the 36575 same as TO; on some machines it is expensive to move between 36576 registers if they are not general registers. 36577 36578 If reload sees an insn consisting of a single 'set' between two 36579 hard registers, and if 'REGISTER_MOVE_COST' applied to their 36580 classes returns a value of 2, reload does not check to ensure that 36581 the constraints of the insn are met. Setting a cost of other than 36582 2 will allow reload to verify that the constraints are met. You 36583 should do this if the 'movM' pattern's constraints do not allow 36584 such copying. 36585 36586 These macros are obsolete, new ports should use the target hook 36587 'TARGET_REGISTER_MOVE_COST' instead. 36588 36589 -- Target Hook: int TARGET_REGISTER_MOVE_COST (machine_mode MODE, 36590 reg_class_t FROM, reg_class_t TO) 36591 This target hook should return the cost of moving data of mode MODE 36592 from a register in class FROM to one in class TO. The classes are 36593 expressed using the enumeration values such as 'GENERAL_REGS'. A 36594 value of 2 is the default; other values are interpreted relative to 36595 that. 36596 36597 It is not required that the cost always equal 2 when FROM is the 36598 same as TO; on some machines it is expensive to move between 36599 registers if they are not general registers. 36600 36601 If reload sees an insn consisting of a single 'set' between two 36602 hard registers, and if 'TARGET_REGISTER_MOVE_COST' applied to their 36603 classes returns a value of 2, reload does not check to ensure that 36604 the constraints of the insn are met. Setting a cost of other than 36605 2 will allow reload to verify that the constraints are met. You 36606 should do this if the 'movM' pattern's constraints do not allow 36607 such copying. 36608 36609 The default version of this function returns 2. 36610 36611 -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN) 36612 A C expression for the cost of moving data of mode MODE between a 36613 register of class CLASS and memory; IN is zero if the value is to 36614 be written to memory, nonzero if it is to be read in. This cost is 36615 relative to those in 'REGISTER_MOVE_COST'. If moving between 36616 registers and memory is more expensive than between two registers, 36617 you should define this macro to express the relative cost. 36618 36619 If you do not define this macro, GCC uses a default cost of 4 plus 36620 the cost of copying via a secondary reload register, if one is 36621 needed. If your machine requires a secondary reload register to 36622 copy between memory and a register of CLASS but the reload 36623 mechanism is more complex than copying via an intermediate, define 36624 this macro to reflect the actual cost of the move. 36625 36626 GCC defines the function 'memory_move_secondary_cost' if secondary 36627 reloads are needed. It computes the costs due to copying via a 36628 secondary register. If your machine copies from memory using a 36629 secondary register in the conventional way but the default base 36630 value of 4 is not correct for your machine, define this macro to 36631 add some other value to the result of that function. The arguments 36632 to that function are the same as to this macro. 36633 36634 These macros are obsolete, new ports should use the target hook 36635 'TARGET_MEMORY_MOVE_COST' instead. 36636 36637 -- Target Hook: int TARGET_MEMORY_MOVE_COST (machine_mode MODE, 36638 reg_class_t RCLASS, bool IN) 36639 This target hook should return the cost of moving data of mode MODE 36640 between a register of class RCLASS and memory; IN is 'false' if the 36641 value is to be written to memory, 'true' if it is to be read in. 36642 This cost is relative to those in 'TARGET_REGISTER_MOVE_COST'. If 36643 moving between registers and memory is more expensive than between 36644 two registers, you should add this target hook to express the 36645 relative cost. 36646 36647 If you do not add this target hook, GCC uses a default cost of 4 36648 plus the cost of copying via a secondary reload register, if one is 36649 needed. If your machine requires a secondary reload register to 36650 copy between memory and a register of RCLASS but the reload 36651 mechanism is more complex than copying via an intermediate, use 36652 this target hook to reflect the actual cost of the move. 36653 36654 GCC defines the function 'memory_move_secondary_cost' if secondary 36655 reloads are needed. It computes the costs due to copying via a 36656 secondary register. If your machine copies from memory using a 36657 secondary register in the conventional way but the default base 36658 value of 4 is not correct for your machine, use this target hook to 36659 add some other value to the result of that function. The arguments 36660 to that function are the same as to this target hook. 36661 36662 -- Macro: BRANCH_COST (SPEED_P, PREDICTABLE_P) 36663 A C expression for the cost of a branch instruction. A value of 1 36664 is the default; other values are interpreted relative to that. 36665 Parameter SPEED_P is true when the branch in question should be 36666 optimized for speed. When it is false, 'BRANCH_COST' should return 36667 a value optimal for code size rather than performance. 36668 PREDICTABLE_P is true for well-predicted branches. On many 36669 architectures the 'BRANCH_COST' can be reduced then. 36670 36671 Here are additional macros which do not specify precise relative costs, 36672but only that certain actions are more expensive than GCC would 36673ordinarily expect. 36674 36675 -- Macro: SLOW_BYTE_ACCESS 36676 Define this macro as a C expression which is nonzero if accessing 36677 less than a word of memory (i.e. a 'char' or a 'short') is no 36678 faster than accessing a word of memory, i.e., if such access 36679 require more than one instruction or if there is no difference in 36680 cost between byte and (aligned) word loads. 36681 36682 When this macro is not defined, the compiler will access a field by 36683 finding the smallest containing object; when it is defined, a 36684 fullword load will be used if alignment permits. Unless bytes 36685 accesses are faster than word accesses, using word accesses is 36686 preferable since it may eliminate subsequent memory access if 36687 subsequent accesses occur to other fields in the same word of the 36688 structure, but to different bytes. 36689 36690 -- Target Hook: bool TARGET_SLOW_UNALIGNED_ACCESS (machine_mode MODE, 36691 unsigned int ALIGN) 36692 This hook returns true if memory accesses described by the MODE and 36693 ALIGNMENT parameters have a cost many times greater than aligned 36694 accesses, for example if they are emulated in a trap handler. This 36695 hook is invoked only for unaligned accesses, i.e. when 'ALIGNMENT < 36696 GET_MODE_ALIGNMENT (MODE)'. 36697 36698 When this hook returns true, the compiler will act as if 36699 'STRICT_ALIGNMENT' were true when generating code for block moves. 36700 This can cause significantly more instructions to be produced. 36701 Therefore, do not make this hook return true if unaligned accesses 36702 only add a cycle or two to the time for a memory access. 36703 36704 The hook must return true whenever 'STRICT_ALIGNMENT' is true. The 36705 default implementation returns 'STRICT_ALIGNMENT'. 36706 36707 -- Macro: MOVE_RATIO (SPEED) 36708 The threshold of number of scalar memory-to-memory move insns, 36709 _below_ which a sequence of insns should be generated instead of a 36710 string move insn or a library call. Increasing the value will 36711 always make code faster, but eventually incurs high cost in 36712 increased code size. 36713 36714 Note that on machines where the corresponding move insn is a 36715 'define_expand' that emits a sequence of insns, this macro counts 36716 the number of such sequences. 36717 36718 The parameter SPEED is true if the code is currently being 36719 optimized for speed rather than size. 36720 36721 If you don't define this, a reasonable default is used. 36722 36723 -- Target Hook: bool TARGET_USE_BY_PIECES_INFRASTRUCTURE_P (unsigned 36724 HOST_WIDE_INT SIZE, unsigned int ALIGNMENT, enum 36725 by_pieces_operation OP, bool SPEED_P) 36726 GCC will attempt several strategies when asked to copy between two 36727 areas of memory, or to set, clear or store to memory, for example 36728 when copying a 'struct'. The 'by_pieces' infrastructure implements 36729 such memory operations as a sequence of load, store or move insns. 36730 Alternate strategies are to expand the 'movmem' or 'setmem' optabs, 36731 to emit a library call, or to emit unit-by-unit, loop-based 36732 operations. 36733 36734 This target hook should return true if, for a memory operation with 36735 a given SIZE and ALIGNMENT, using the 'by_pieces' infrastructure is 36736 expected to result in better code generation. Both SIZE and 36737 ALIGNMENT are measured in terms of storage units. 36738 36739 The parameter OP is one of: 'CLEAR_BY_PIECES', 'MOVE_BY_PIECES', 36740 'SET_BY_PIECES', 'STORE_BY_PIECES' or 'COMPARE_BY_PIECES'. These 36741 describe the type of memory operation under consideration. 36742 36743 The parameter SPEED_P is true if the code is currently being 36744 optimized for speed rather than size. 36745 36746 Returning true for higher values of SIZE can improve code 36747 generation for speed if the target does not provide an 36748 implementation of the 'movmem' or 'setmem' standard names, if the 36749 'movmem' or 'setmem' implementation would be more expensive than a 36750 sequence of insns, or if the overhead of a library call would 36751 dominate that of the body of the memory operation. 36752 36753 Returning true for higher values of 'size' may also cause an 36754 increase in code size, for example where the number of insns 36755 emitted to perform a move would be greater than that of a library 36756 call. 36757 36758 -- Target Hook: int TARGET_COMPARE_BY_PIECES_BRANCH_RATIO (machine_mode 36759 MODE) 36760 When expanding a block comparison in MODE, gcc can try to reduce 36761 the number of branches at the expense of more memory operations. 36762 This hook allows the target to override the default choice. It 36763 should return the factor by which branches should be reduced over 36764 the plain expansion with one comparison per MODE-sized piece. A 36765 port can also prevent a particular mode from being used for block 36766 comparisons by returning a negative number from this hook. 36767 36768 -- Macro: MOVE_MAX_PIECES 36769 A C expression used by 'move_by_pieces' to determine the largest 36770 unit a load or store used to copy memory is. Defaults to 36771 'MOVE_MAX'. 36772 36773 -- Macro: STORE_MAX_PIECES 36774 A C expression used by 'store_by_pieces' to determine the largest 36775 unit a store used to memory is. Defaults to 'MOVE_MAX_PIECES', or 36776 two times the size of 'HOST_WIDE_INT', whichever is smaller. 36777 36778 -- Macro: COMPARE_MAX_PIECES 36779 A C expression used by 'compare_by_pieces' to determine the largest 36780 unit a load or store used to compare memory is. Defaults to 36781 'MOVE_MAX_PIECES'. 36782 36783 -- Macro: CLEAR_RATIO (SPEED) 36784 The threshold of number of scalar move insns, _below_ which a 36785 sequence of insns should be generated to clear memory instead of a 36786 string clear insn or a library call. Increasing the value will 36787 always make code faster, but eventually incurs high cost in 36788 increased code size. 36789 36790 The parameter SPEED is true if the code is currently being 36791 optimized for speed rather than size. 36792 36793 If you don't define this, a reasonable default is used. 36794 36795 -- Macro: SET_RATIO (SPEED) 36796 The threshold of number of scalar move insns, _below_ which a 36797 sequence of insns should be generated to set memory to a constant 36798 value, instead of a block set insn or a library call. Increasing 36799 the value will always make code faster, but eventually incurs high 36800 cost in increased code size. 36801 36802 The parameter SPEED is true if the code is currently being 36803 optimized for speed rather than size. 36804 36805 If you don't define this, it defaults to the value of 'MOVE_RATIO'. 36806 36807 -- Macro: USE_LOAD_POST_INCREMENT (MODE) 36808 A C expression used to determine whether a load postincrement is a 36809 good thing to use for a given mode. Defaults to the value of 36810 'HAVE_POST_INCREMENT'. 36811 36812 -- Macro: USE_LOAD_POST_DECREMENT (MODE) 36813 A C expression used to determine whether a load postdecrement is a 36814 good thing to use for a given mode. Defaults to the value of 36815 'HAVE_POST_DECREMENT'. 36816 36817 -- Macro: USE_LOAD_PRE_INCREMENT (MODE) 36818 A C expression used to determine whether a load preincrement is a 36819 good thing to use for a given mode. Defaults to the value of 36820 'HAVE_PRE_INCREMENT'. 36821 36822 -- Macro: USE_LOAD_PRE_DECREMENT (MODE) 36823 A C expression used to determine whether a load predecrement is a 36824 good thing to use for a given mode. Defaults to the value of 36825 'HAVE_PRE_DECREMENT'. 36826 36827 -- Macro: USE_STORE_POST_INCREMENT (MODE) 36828 A C expression used to determine whether a store postincrement is a 36829 good thing to use for a given mode. Defaults to the value of 36830 'HAVE_POST_INCREMENT'. 36831 36832 -- Macro: USE_STORE_POST_DECREMENT (MODE) 36833 A C expression used to determine whether a store postdecrement is a 36834 good thing to use for a given mode. Defaults to the value of 36835 'HAVE_POST_DECREMENT'. 36836 36837 -- Macro: USE_STORE_PRE_INCREMENT (MODE) 36838 This macro is used to determine whether a store preincrement is a 36839 good thing to use for a given mode. Defaults to the value of 36840 'HAVE_PRE_INCREMENT'. 36841 36842 -- Macro: USE_STORE_PRE_DECREMENT (MODE) 36843 This macro is used to determine whether a store predecrement is a 36844 good thing to use for a given mode. Defaults to the value of 36845 'HAVE_PRE_DECREMENT'. 36846 36847 -- Macro: NO_FUNCTION_CSE 36848 Define this macro to be true if it is as good or better to call a 36849 constant function address than to call an address kept in a 36850 register. 36851 36852 -- Macro: LOGICAL_OP_NON_SHORT_CIRCUIT 36853 Define this macro if a non-short-circuit operation produced by 36854 'fold_range_test ()' is optimal. This macro defaults to true if 36855 'BRANCH_COST' is greater than or equal to the value 2. 36856 36857 -- Target Hook: bool TARGET_OPTAB_SUPPORTED_P (int OP, machine_mode 36858 MODE1, machine_mode MODE2, optimization_type OPT_TYPE) 36859 Return true if the optimizers should use optab OP with modes MODE1 36860 and MODE2 for optimization type OPT_TYPE. The optab is known to 36861 have an associated '.md' instruction whose C condition is true. 36862 MODE2 is only meaningful for conversion optabs; for direct optabs 36863 it is a copy of MODE1. 36864 36865 For example, when called with OP equal to 'rint_optab' and MODE1 36866 equal to 'DFmode', the hook should say whether the optimizers 36867 should use optab 'rintdf2'. 36868 36869 The default hook returns true for all inputs. 36870 36871 -- Target Hook: bool TARGET_RTX_COSTS (rtx X, machine_mode MODE, int 36872 OUTER_CODE, int OPNO, int *TOTAL, bool SPEED) 36873 This target hook describes the relative costs of RTL expressions. 36874 36875 The cost may depend on the precise form of the expression, which is 36876 available for examination in X, and the fact that X appears as 36877 operand OPNO of an expression with rtx code OUTER_CODE. That is, 36878 the hook can assume that there is some rtx Y such that 'GET_CODE 36879 (Y) == OUTER_CODE' and such that either (a) 'XEXP (Y, OPNO) == X' 36880 or (b) 'XVEC (Y, OPNO)' contains X. 36881 36882 MODE is X's machine mode, or for cases like 'const_int' that do not 36883 have a mode, the mode in which X is used. 36884 36885 In implementing this hook, you can use the construct 'COSTS_N_INSNS 36886 (N)' to specify a cost equal to N fast instructions. 36887 36888 On entry to the hook, '*TOTAL' contains a default estimate for the 36889 cost of the expression. The hook should modify this value as 36890 necessary. Traditionally, the default costs are 'COSTS_N_INSNS 36891 (5)' for multiplications, 'COSTS_N_INSNS (7)' for division and 36892 modulus operations, and 'COSTS_N_INSNS (1)' for all other 36893 operations. 36894 36895 When optimizing for code size, i.e. when 'speed' is false, this 36896 target hook should be used to estimate the relative size cost of an 36897 expression, again relative to 'COSTS_N_INSNS'. 36898 36899 The hook returns true when all subexpressions of X have been 36900 processed, and false when 'rtx_cost' should recurse. 36901 36902 -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS, machine_mode 36903 MODE, addr_space_t AS, bool SPEED) 36904 This hook computes the cost of an addressing mode that contains 36905 ADDRESS. If not defined, the cost is computed from the ADDRESS 36906 expression and the 'TARGET_RTX_COST' hook. 36907 36908 For most CISC machines, the default cost is a good approximation of 36909 the true cost of the addressing mode. However, on RISC machines, 36910 all instructions normally have the same length and execution time. 36911 Hence all addresses will have equal costs. 36912 36913 In cases where more than one form of an address is known, the form 36914 with the lowest cost will be used. If multiple forms have the 36915 same, lowest, cost, the one that is the most complex will be used. 36916 36917 For example, suppose an address that is equal to the sum of a 36918 register and a constant is used twice in the same basic block. 36919 When this macro is not defined, the address will be computed in a 36920 register and memory references will be indirect through that 36921 register. On machines where the cost of the addressing mode 36922 containing the sum is no higher than that of a simple indirect 36923 reference, this will produce an additional instruction and possibly 36924 require an additional register. Proper specification of this macro 36925 eliminates this overhead for such machines. 36926 36927 This hook is never called with an invalid address. 36928 36929 On machines where an address involving more than one register is as 36930 cheap as an address computation involving only one register, 36931 defining 'TARGET_ADDRESS_COST' to reflect this can cause two 36932 registers to be live over a region of code where only one would 36933 have been if 'TARGET_ADDRESS_COST' were not defined in that manner. 36934 This effect should be considered in the definition of this macro. 36935 Equivalent costs should probably only be given to addresses with 36936 different numbers of registers on machines with lots of registers. 36937 36938 -- Target Hook: int TARGET_INSN_COST (rtx_insn *INSN, bool SPEED) 36939 This target hook describes the relative costs of RTL instructions. 36940 36941 In implementing this hook, you can use the construct 'COSTS_N_INSNS 36942 (N)' to specify a cost equal to N fast instructions. 36943 36944 When optimizing for code size, i.e. when 'speed' is false, this 36945 target hook should be used to estimate the relative size cost of an 36946 expression, again relative to 'COSTS_N_INSNS'. 36947 36948 -- Target Hook: unsigned int TARGET_MAX_NOCE_IFCVT_SEQ_COST (edge E) 36949 This hook returns a value in the same units as 'TARGET_RTX_COSTS', 36950 giving the maximum acceptable cost for a sequence generated by the 36951 RTL if-conversion pass when conditional execution is not available. 36952 The RTL if-conversion pass attempts to convert conditional 36953 operations that would require a branch to a series of unconditional 36954 operations and 'movMODEcc' insns. This hook returns the maximum 36955 cost of the unconditional instructions and the 'movMODEcc' insns. 36956 RTL if-conversion is cancelled if the cost of the converted 36957 sequence is greater than the value returned by this hook. 36958 36959 'e' is the edge between the basic block containing the conditional 36960 branch to the basic block which would be executed if the condition 36961 were true. 36962 36963 The default implementation of this hook uses the 36964 'max-rtl-if-conversion-[un]predictable' parameters if they are set, 36965 and uses a multiple of 'BRANCH_COST' otherwise. 36966 36967 -- Target Hook: bool TARGET_NOCE_CONVERSION_PROFITABLE_P (rtx_insn 36968 *SEQ, struct noce_if_info *IF_INFO) 36969 This hook returns true if the instruction sequence 'seq' is a good 36970 candidate as a replacement for the if-convertible sequence 36971 described in 'if_info'. 36972 36973 -- Target Hook: bool TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P (void) 36974 This predicate controls the use of the eager delay slot filler to 36975 disallow speculatively executed instructions being placed in delay 36976 slots. Targets such as certain MIPS architectures possess both 36977 branches with and without delay slots. As the eager delay slot 36978 filler can decrease performance, disabling it is beneficial when 36979 ordinary branches are available. Use of delay slot branches filled 36980 using the basic filler is often still desirable as the delay slot 36981 can hide a pipeline bubble. 36982 36983 -- Target Hook: HOST_WIDE_INT TARGET_ESTIMATED_POLY_VALUE (poly_int64 36984 VAL) 36985 Return an estimate of the runtime value of VAL, for use in things 36986 like cost calculations or profiling frequencies. The default 36987 implementation returns the lowest possible value of VAL. 36988 36989 36990File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros 36991 3699218.17 Adjusting the Instruction Scheduler 36993========================================= 36994 36995The instruction scheduler may need a fair amount of machine-specific 36996adjustment in order to produce good code. GCC provides several target 36997hooks for this purpose. It is usually enough to define just a few of 36998them: try the first ones in this list first. 36999 37000 -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void) 37001 This hook returns the maximum number of instructions that can ever 37002 issue at the same time on the target machine. The default is one. 37003 Although the insn scheduler can define itself the possibility of 37004 issue an insn on the same cycle, the value can serve as an 37005 additional constraint to issue insns on the same simulated 37006 processor cycle (see hooks 'TARGET_SCHED_REORDER' and 37007 'TARGET_SCHED_REORDER2'). This value must be constant over the 37008 entire compilation. If you need it to vary depending on what the 37009 instructions are, you must use 'TARGET_SCHED_VARIABLE_ISSUE'. 37010 37011 -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int 37012 VERBOSE, rtx_insn *INSN, int MORE) 37013 This hook is executed by the scheduler after it has scheduled an 37014 insn from the ready list. It should return the number of insns 37015 which can still be issued in the current cycle. The default is 37016 'MORE - 1' for insns other than 'CLOBBER' and 'USE', which normally 37017 are not counted against the issue rate. You should define this 37018 hook if some insns take more machine resources than others, so that 37019 fewer insns can follow them in the same cycle. FILE is either a 37020 null pointer, or a stdio stream to write any debug output to. 37021 VERBOSE is the verbose level provided by '-fsched-verbose-N'. INSN 37022 is the instruction that was scheduled. 37023 37024 -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx_insn *INSN, int 37025 DEP_TYPE1, rtx_insn *DEP_INSN, int COST, unsigned int DW) 37026 This function corrects the value of COST based on the relationship 37027 between INSN and DEP_INSN through a dependence of type dep_type, 37028 and strength DW. It should return the new value. The default is 37029 to make no adjustment to COST. This can be used for example to 37030 specify to the scheduler using the traditional pipeline description 37031 that an output- or anti-dependence does not incur the same cost as 37032 a data-dependence. If the scheduler using the automaton based 37033 pipeline description, the cost of anti-dependence is zero and the 37034 cost of output-dependence is maximum of one and the difference of 37035 latency times of the first and the second insns. If these values 37036 are not acceptable, you could use the hook to modify them too. See 37037 also *note Processor pipeline description::. 37038 37039 -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx_insn *INSN, int 37040 PRIORITY) 37041 This hook adjusts the integer scheduling priority PRIORITY of INSN. 37042 It should return the new priority. Increase the priority to 37043 execute INSN earlier, reduce the priority to execute INSN later. 37044 Do not define this hook if you do not need to adjust the scheduling 37045 priorities of insns. 37046 37047 -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, 37048 rtx_insn **READY, int *N_READYP, int CLOCK) 37049 This hook is executed by the scheduler after it has scheduled the 37050 ready list, to allow the machine description to reorder it (for 37051 example to combine two small instructions together on 'VLIW' 37052 machines). FILE is either a null pointer, or a stdio stream to 37053 write any debug output to. VERBOSE is the verbose level provided 37054 by '-fsched-verbose-N'. READY is a pointer to the ready list of 37055 instructions that are ready to be scheduled. N_READYP is a pointer 37056 to the number of elements in the ready list. The scheduler reads 37057 the ready list in reverse order, starting with READY[*N_READYP - 1] 37058 and going to READY[0]. CLOCK is the timer tick of the scheduler. 37059 You may modify the ready list and the number of ready insns. The 37060 return value is the number of insns that can issue this cycle; 37061 normally this is just 'issue_rate'. See also 37062 'TARGET_SCHED_REORDER2'. 37063 37064 -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE, 37065 rtx_insn **READY, int *N_READYP, int CLOCK) 37066 Like 'TARGET_SCHED_REORDER', but called at a different time. That 37067 function is called whenever the scheduler starts a new cycle. This 37068 one is called once per iteration over a cycle, immediately after 37069 'TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list and 37070 return the number of insns to be scheduled in the same cycle. 37071 Defining this hook can be useful if there are frequent situations 37072 where scheduling one insn causes other insns to become ready in the 37073 same cycle. These other insns can then be taken into account 37074 properly. 37075 37076 -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_P (void) 37077 This hook is used to check whether target platform supports macro 37078 fusion. 37079 37080 -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_PAIR_P (rtx_insn *PREV, 37081 rtx_insn *CURR) 37082 This hook is used to check whether two insns should be macro fused 37083 for a target microarchitecture. If this hook returns true for the 37084 given insn pair (PREV and CURR), the scheduler will put them into a 37085 sched group, and they will not be scheduled apart. The two insns 37086 will be either two SET insns or a compare and a conditional jump 37087 and this hook should validate any dependencies needed to fuse the 37088 two insns together. 37089 37090 -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK 37091 (rtx_insn *HEAD, rtx_insn *TAIL) 37092 This hook is called after evaluation forward dependencies of insns 37093 in chain given by two parameter values (HEAD and TAIL 37094 correspondingly) but before insns scheduling of the insn chain. 37095 For example, it can be used for better insn classification if it 37096 requires analysis of dependencies. This hook can use backward and 37097 forward dependencies of the insn scheduler because they are already 37098 calculated. 37099 37100 -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int 37101 MAX_READY) 37102 This hook is executed by the scheduler at the beginning of each 37103 block of instructions that are to be scheduled. FILE is either a 37104 null pointer, or a stdio stream to write any debug output to. 37105 VERBOSE is the verbose level provided by '-fsched-verbose-N'. 37106 MAX_READY is the maximum number of insns in the current scheduling 37107 region that can be live at the same time. This can be used to 37108 allocate scratch space if it is needed, e.g. by 37109 'TARGET_SCHED_REORDER'. 37110 37111 -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE) 37112 This hook is executed by the scheduler at the end of each block of 37113 instructions that are to be scheduled. It can be used to perform 37114 cleanup of any actions done by the other scheduling hooks. FILE is 37115 either a null pointer, or a stdio stream to write any debug output 37116 to. VERBOSE is the verbose level provided by '-fsched-verbose-N'. 37117 37118 -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int VERBOSE, 37119 int OLD_MAX_UID) 37120 This hook is executed by the scheduler after function level 37121 initializations. FILE is either a null pointer, or a stdio stream 37122 to write any debug output to. VERBOSE is the verbose level 37123 provided by '-fsched-verbose-N'. OLD_MAX_UID is the maximum insn 37124 uid when scheduling begins. 37125 37126 -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int 37127 VERBOSE) 37128 This is the cleanup hook corresponding to 37129 'TARGET_SCHED_INIT_GLOBAL'. FILE is either a null pointer, or a 37130 stdio stream to write any debug output to. VERBOSE is the verbose 37131 level provided by '-fsched-verbose-N'. 37132 37133 -- Target Hook: rtx TARGET_SCHED_DFA_PRE_CYCLE_INSN (void) 37134 The hook returns an RTL insn. The automaton state used in the 37135 pipeline hazard recognizer is changed as if the insn were scheduled 37136 when the new simulated processor cycle starts. Usage of the hook 37137 may simplify the automaton pipeline description for some VLIW 37138 processors. If the hook is defined, it is used only for the 37139 automaton based pipeline description. The default is not to change 37140 the state when the new simulated processor cycle starts. 37141 37142 -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void) 37143 The hook can be used to initialize data used by the previous hook. 37144 37145 -- Target Hook: rtx_insn * TARGET_SCHED_DFA_POST_CYCLE_INSN (void) 37146 The hook is analogous to 'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used 37147 to changed the state as if the insn were scheduled when the new 37148 simulated processor cycle finishes. 37149 37150 -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void) 37151 The hook is analogous to 'TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but 37152 used to initialize data used by the previous hook. 37153 37154 -- Target Hook: void TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE (void) 37155 The hook to notify target that the current simulated cycle is about 37156 to finish. The hook is analogous to 37157 'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used to change the state in 37158 more complicated situations - e.g., when advancing state on a 37159 single insn is not enough. 37160 37161 -- Target Hook: void TARGET_SCHED_DFA_POST_ADVANCE_CYCLE (void) 37162 The hook to notify target that new simulated cycle has just 37163 started. The hook is analogous to 37164 'TARGET_SCHED_DFA_POST_CYCLE_INSN' but used to change the state in 37165 more complicated situations - e.g., when advancing state on a 37166 single insn is not enough. 37167 37168 -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 37169 (void) 37170 This hook controls better choosing an insn from the ready insn 37171 queue for the DFA-based insn scheduler. Usually the scheduler 37172 chooses the first insn from the queue. If the hook returns a 37173 positive value, an additional scheduler code tries all permutations 37174 of 'TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD ()' subsequent 37175 ready insns to choose an insn whose issue will result in maximal 37176 number of issued insns on the same cycle. For the VLIW processor, 37177 the code could actually solve the problem of packing simple insns 37178 into the VLIW insn. Of course, if the rules of VLIW packing are 37179 described in the automaton. 37180 37181 This code also could be used for superscalar RISC processors. Let 37182 us consider a superscalar RISC processor with 3 pipelines. Some 37183 insns can be executed in pipelines A or B, some insns can be 37184 executed only in pipelines B or C, and one insn can be executed in 37185 pipeline B. The processor may issue the 1st insn into A and the 37186 2nd one into B. In this case, the 3rd insn will wait for freeing B 37187 until the next cycle. If the scheduler issues the 3rd insn the 37188 first, the processor could issue all 3 insns per cycle. 37189 37190 Actually this code demonstrates advantages of the automaton based 37191 pipeline hazard recognizer. We try quickly and easy many insn 37192 schedules to choose the best one. 37193 37194 The default is no multipass scheduling. 37195 37196 -- Target Hook: int 37197 TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD 37198 (rtx_insn *INSN, int READY_INDEX) 37199 37200 This hook controls what insns from the ready insn queue will be 37201 considered for the multipass insn scheduling. If the hook returns 37202 zero for INSN, the insn will be considered in multipass scheduling. 37203 Positive return values will remove INSN from consideration on the 37204 current round of multipass scheduling. Negative return values will 37205 remove INSN from consideration for given number of cycles. 37206 Backends should be careful about returning non-zero for highest 37207 priority instruction at position 0 in the ready list. READY_INDEX 37208 is passed to allow backends make correct judgements. 37209 37210 The default is that any ready insns can be chosen to be issued. 37211 37212 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN (void 37213 *DATA, signed char *READY_TRY, int N_READY, bool 37214 FIRST_CYCLE_INSN_P) 37215 This hook prepares the target backend for a new round of multipass 37216 scheduling. 37217 37218 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE (void 37219 *DATA, signed char *READY_TRY, int N_READY, rtx_insn *INSN, 37220 const void *PREV_DATA) 37221 This hook is called when multipass scheduling evaluates instruction 37222 INSN. 37223 37224 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK 37225 (const void *DATA, signed char *READY_TRY, int N_READY) 37226 This is called when multipass scheduling backtracks from evaluation 37227 of an instruction. 37228 37229 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END (const void 37230 *DATA) 37231 This hook notifies the target about the result of the concluded 37232 current round of multipass scheduling. 37233 37234 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT (void 37235 *DATA) 37236 This hook initializes target-specific data used in multipass 37237 scheduling. 37238 37239 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI (void 37240 *DATA) 37241 This hook finalizes target-specific data used in multipass 37242 scheduling. 37243 37244 -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *DUMP, int 37245 VERBOSE, rtx_insn *INSN, int LAST_CLOCK, int CLOCK, int 37246 *SORT_P) 37247 This hook is called by the insn scheduler before issuing INSN on 37248 cycle CLOCK. If the hook returns nonzero, INSN is not issued on 37249 this processor cycle. Instead, the processor cycle is advanced. 37250 If *SORT_P is zero, the insn ready queue is not sorted on the new 37251 cycle start as usually. DUMP and VERBOSE specify the file and 37252 verbosity level to use for debugging output. LAST_CLOCK and CLOCK 37253 are, respectively, the processor cycle on which the previous insn 37254 has been issued, and the current processor cycle. 37255 37256 -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (struct _dep 37257 *_DEP, int COST, int DISTANCE) 37258 This hook is used to define which dependences are considered costly 37259 by the target, so costly that it is not advisable to schedule the 37260 insns that are involved in the dependence too close to one another. 37261 The parameters to this hook are as follows: The first parameter 37262 _DEP is the dependence being evaluated. The second parameter COST 37263 is the cost of the dependence as estimated by the scheduler, and 37264 the third parameter DISTANCE is the distance in cycles between the 37265 two insns. The hook returns 'true' if considering the distance 37266 between the two insns the dependence between them is considered 37267 costly by the target, and 'false' otherwise. 37268 37269 Defining this hook can be useful in multiple-issue out-of-order 37270 machines, where (a) it's practically hopeless to predict the actual 37271 data/resource delays, however: (b) there's a better chance to 37272 predict the actual grouping that will be formed, and (c) correctly 37273 emulating the grouping can be very important. In such targets one 37274 may want to allow issuing dependent insns closer to one 37275 another--i.e., closer than the dependence distance; however, not in 37276 cases of "costly dependences", which this hooks allows to define. 37277 37278 -- Target Hook: void TARGET_SCHED_H_I_D_EXTENDED (void) 37279 This hook is called by the insn scheduler after emitting a new 37280 instruction to the instruction stream. The hook notifies a target 37281 backend to extend its per instruction data structures. 37282 37283 -- Target Hook: void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void) 37284 Return a pointer to a store large enough to hold target scheduling 37285 context. 37286 37287 -- Target Hook: void TARGET_SCHED_INIT_SCHED_CONTEXT (void *TC, bool 37288 CLEAN_P) 37289 Initialize store pointed to by TC to hold target scheduling 37290 context. It CLEAN_P is true then initialize TC as if scheduler is 37291 at the beginning of the block. Otherwise, copy the current context 37292 into TC. 37293 37294 -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC) 37295 Copy target scheduling context pointed to by TC to the current 37296 context. 37297 37298 -- Target Hook: void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *TC) 37299 Deallocate internal data in target scheduling context pointed to by 37300 TC. 37301 37302 -- Target Hook: void TARGET_SCHED_FREE_SCHED_CONTEXT (void *TC) 37303 Deallocate a store for target scheduling context pointed to by TC. 37304 37305 -- Target Hook: int TARGET_SCHED_SPECULATE_INSN (rtx_insn *INSN, 37306 unsigned int DEP_STATUS, rtx *NEW_PAT) 37307 This hook is called by the insn scheduler when INSN has only 37308 speculative dependencies and therefore can be scheduled 37309 speculatively. The hook is used to check if the pattern of INSN 37310 has a speculative version and, in case of successful check, to 37311 generate that speculative pattern. The hook should return 1, if 37312 the instruction has a speculative form, or -1, if it doesn't. 37313 REQUEST describes the type of requested speculation. If the return 37314 value equals 1 then NEW_PAT is assigned the generated speculative 37315 pattern. 37316 37317 -- Target Hook: bool TARGET_SCHED_NEEDS_BLOCK_P (unsigned int 37318 DEP_STATUS) 37319 This hook is called by the insn scheduler during generation of 37320 recovery code for INSN. It should return 'true', if the 37321 corresponding check instruction should branch to recovery code, or 37322 'false' otherwise. 37323 37324 -- Target Hook: rtx TARGET_SCHED_GEN_SPEC_CHECK (rtx_insn *INSN, 37325 rtx_insn *LABEL, unsigned int DS) 37326 This hook is called by the insn scheduler to generate a pattern for 37327 recovery check instruction. If MUTATE_P is zero, then INSN is a 37328 speculative instruction for which the check should be generated. 37329 LABEL is either a label of a basic block, where recovery code 37330 should be emitted, or a null pointer, when requested check doesn't 37331 branch to recovery code (a simple check). If MUTATE_P is nonzero, 37332 then a pattern for a branchy check corresponding to a simple check 37333 denoted by INSN should be generated. In this case LABEL can't be 37334 null. 37335 37336 -- Target Hook: void TARGET_SCHED_SET_SCHED_FLAGS (struct spec_info_def 37337 *SPEC_INFO) 37338 This hook is used by the insn scheduler to find out what features 37339 should be enabled/used. The structure *SPEC_INFO should be filled 37340 in by the target. The structure describes speculation types that 37341 can be used in the scheduler. 37342 37343 -- Target Hook: bool TARGET_SCHED_CAN_SPECULATE_INSN (rtx_insn *INSN) 37344 Some instructions should never be speculated by the schedulers, 37345 usually because the instruction is too expensive to get this wrong. 37346 Often such instructions have long latency, and often they are not 37347 fully modeled in the pipeline descriptions. This hook should 37348 return 'false' if INSN should not be speculated. 37349 37350 -- Target Hook: int TARGET_SCHED_SMS_RES_MII (struct ddg *G) 37351 This hook is called by the swing modulo scheduler to calculate a 37352 resource-based lower bound which is based on the resources 37353 available in the machine and the resources required by each 37354 instruction. The target backend can use G to calculate such bound. 37355 A very simple lower bound will be used in case this hook is not 37356 implemented: the total number of instructions divided by the issue 37357 rate. 37358 37359 -- Target Hook: bool TARGET_SCHED_DISPATCH (rtx_insn *INSN, int X) 37360 This hook is called by Haifa Scheduler. It returns true if 37361 dispatch scheduling is supported in hardware and the condition 37362 specified in the parameter is true. 37363 37364 -- Target Hook: void TARGET_SCHED_DISPATCH_DO (rtx_insn *INSN, int X) 37365 This hook is called by Haifa Scheduler. It performs the operation 37366 specified in its second parameter. 37367 37368 -- Target Hook: bool TARGET_SCHED_EXPOSED_PIPELINE 37369 True if the processor has an exposed pipeline, which means that not 37370 just the order of instructions is important for correctness when 37371 scheduling, but also the latencies of operations. 37372 37373 -- Target Hook: int TARGET_SCHED_REASSOCIATION_WIDTH (unsigned int OPC, 37374 machine_mode MODE) 37375 This hook is called by tree reassociator to determine a level of 37376 parallelism required in output calculations chain. 37377 37378 -- Target Hook: void TARGET_SCHED_FUSION_PRIORITY (rtx_insn *INSN, int 37379 MAX_PRI, int *FUSION_PRI, int *PRI) 37380 This hook is called by scheduling fusion pass. It calculates 37381 fusion priorities for each instruction passed in by parameter. The 37382 priorities are returned via pointer parameters. 37383 37384 INSN is the instruction whose priorities need to be calculated. 37385 MAX_PRI is the maximum priority can be returned in any cases. 37386 FUSION_PRI is the pointer parameter through which INSN's fusion 37387 priority should be calculated and returned. PRI is the pointer 37388 parameter through which INSN's priority should be calculated and 37389 returned. 37390 37391 Same FUSION_PRI should be returned for instructions which should be 37392 scheduled together. Different PRI should be returned for 37393 instructions with same FUSION_PRI. FUSION_PRI is the major sort 37394 key, PRI is the minor sort key. All instructions will be scheduled 37395 according to the two priorities. All priorities calculated should 37396 be between 0 (exclusive) and MAX_PRI (inclusive). To avoid false 37397 dependencies, FUSION_PRI of instructions which need to be scheduled 37398 together should be smaller than FUSION_PRI of irrelevant 37399 instructions. 37400 37401 Given below example: 37402 37403 ldr r10, [r1, 4] 37404 add r4, r4, r10 37405 ldr r15, [r2, 8] 37406 sub r5, r5, r15 37407 ldr r11, [r1, 0] 37408 add r4, r4, r11 37409 ldr r16, [r2, 12] 37410 sub r5, r5, r16 37411 37412 On targets like ARM/AArch64, the two pairs of consecutive loads 37413 should be merged. Since peephole2 pass can't help in this case 37414 unless consecutive loads are actually next to each other in 37415 instruction flow. That's where this scheduling fusion pass works. 37416 This hook calculates priority for each instruction based on its 37417 fustion type, like: 37418 37419 ldr r10, [r1, 4] ; fusion_pri=99, pri=96 37420 add r4, r4, r10 ; fusion_pri=100, pri=100 37421 ldr r15, [r2, 8] ; fusion_pri=98, pri=92 37422 sub r5, r5, r15 ; fusion_pri=100, pri=100 37423 ldr r11, [r1, 0] ; fusion_pri=99, pri=100 37424 add r4, r4, r11 ; fusion_pri=100, pri=100 37425 ldr r16, [r2, 12] ; fusion_pri=98, pri=88 37426 sub r5, r5, r16 ; fusion_pri=100, pri=100 37427 37428 Scheduling fusion pass then sorts all ready to issue instructions 37429 according to the priorities. As a result, instructions of same 37430 fusion type will be pushed together in instruction flow, like: 37431 37432 ldr r11, [r1, 0] 37433 ldr r10, [r1, 4] 37434 ldr r15, [r2, 8] 37435 ldr r16, [r2, 12] 37436 add r4, r4, r10 37437 sub r5, r5, r15 37438 add r4, r4, r11 37439 sub r5, r5, r16 37440 37441 Now peephole2 pass can simply merge the two pairs of loads. 37442 37443 Since scheduling fusion pass relies on peephole2 to do real fusion 37444 work, it is only enabled by default when peephole2 is in effect. 37445 37446 This is firstly introduced on ARM/AArch64 targets, please refer to 37447 the hook implementation for how different fusion types are 37448 supported. 37449 37450 -- Target Hook: void TARGET_EXPAND_DIVMOD_LIBFUNC (rtx LIBFUNC, 37451 machine_mode MODE, rtx OP0, rtx OP1, rtx *QUOT, rtx *REM) 37452 Define this hook for enabling divmod transform if the port does not 37453 have hardware divmod insn but defines target-specific divmod 37454 libfuncs. 37455 37456 37457File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros 37458 3745918.18 Dividing the Output into Sections (Texts, Data, ...) 37460========================================================== 37461 37462An object file is divided into sections containing different types of 37463data. In the most common case, there are three sections: the "text 37464section", which holds instructions and read-only data; the "data 37465section", which holds initialized writable data; and the "bss section", 37466which holds uninitialized data. Some systems have other kinds of 37467sections. 37468 37469 'varasm.c' provides several well-known sections, such as 37470'text_section', 'data_section' and 'bss_section'. The normal way of 37471controlling a 'FOO_section' variable is to define the associated 37472'FOO_SECTION_ASM_OP' macro, as described below. The macros are only 37473read once, when 'varasm.c' initializes itself, so their values must be 37474run-time constants. They may however depend on command-line flags. 37475 37476 _Note:_ Some run-time files, such 'crtstuff.c', also make use of the 37477'FOO_SECTION_ASM_OP' macros, and expect them to be string literals. 37478 37479 Some assemblers require a different string to be written every time a 37480section is selected. If your assembler falls into this category, you 37481should define the 'TARGET_ASM_INIT_SECTIONS' hook and use 37482'get_unnamed_section' to set up the sections. 37483 37484 You must always create a 'text_section', either by defining 37485'TEXT_SECTION_ASM_OP' or by initializing 'text_section' in 37486'TARGET_ASM_INIT_SECTIONS'. The same is true of 'data_section' and 37487'DATA_SECTION_ASM_OP'. If you do not create a distinct 37488'readonly_data_section', the default is to reuse 'text_section'. 37489 37490 All the other 'varasm.c' sections are optional, and are null if the 37491target does not provide them. 37492 37493 -- Macro: TEXT_SECTION_ASM_OP 37494 A C expression whose value is a string, including spacing, 37495 containing the assembler operation that should precede instructions 37496 and read-only data. Normally '"\t.text"' is right. 37497 37498 -- Macro: HOT_TEXT_SECTION_NAME 37499 If defined, a C string constant for the name of the section 37500 containing most frequently executed functions of the program. If 37501 not defined, GCC will provide a default definition if the target 37502 supports named sections. 37503 37504 -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME 37505 If defined, a C string constant for the name of the section 37506 containing unlikely executed functions in the program. 37507 37508 -- Macro: DATA_SECTION_ASM_OP 37509 A C expression whose value is a string, including spacing, 37510 containing the assembler operation to identify the following data 37511 as writable initialized data. Normally '"\t.data"' is right. 37512 37513 -- Macro: SDATA_SECTION_ASM_OP 37514 If defined, a C expression whose value is a string, including 37515 spacing, containing the assembler operation to identify the 37516 following data as initialized, writable small data. 37517 37518 -- Macro: READONLY_DATA_SECTION_ASM_OP 37519 A C expression whose value is a string, including spacing, 37520 containing the assembler operation to identify the following data 37521 as read-only initialized data. 37522 37523 -- Macro: BSS_SECTION_ASM_OP 37524 If defined, a C expression whose value is a string, including 37525 spacing, containing the assembler operation to identify the 37526 following data as uninitialized global data. If not defined, and 37527 'ASM_OUTPUT_ALIGNED_BSS' not defined, uninitialized global data 37528 will be output in the data section if '-fno-common' is passed, 37529 otherwise 'ASM_OUTPUT_COMMON' will be used. 37530 37531 -- Macro: SBSS_SECTION_ASM_OP 37532 If defined, a C expression whose value is a string, including 37533 spacing, containing the assembler operation to identify the 37534 following data as uninitialized, writable small data. 37535 37536 -- Macro: TLS_COMMON_ASM_OP 37537 If defined, a C expression whose value is a string containing the 37538 assembler operation to identify the following data as thread-local 37539 common data. The default is '".tls_common"'. 37540 37541 -- Macro: TLS_SECTION_ASM_FLAG 37542 If defined, a C expression whose value is a character constant 37543 containing the flag used to mark a section as a TLS section. The 37544 default is ''T''. 37545 37546 -- Macro: INIT_SECTION_ASM_OP 37547 If defined, a C expression whose value is a string, including 37548 spacing, containing the assembler operation to identify the 37549 following data as initialization code. If not defined, GCC will 37550 assume such a section does not exist. This section has no 37551 corresponding 'init_section' variable; it is used entirely in 37552 runtime code. 37553 37554 -- Macro: FINI_SECTION_ASM_OP 37555 If defined, a C expression whose value is a string, including 37556 spacing, containing the assembler operation to identify the 37557 following data as finalization code. If not defined, GCC will 37558 assume such a section does not exist. This section has no 37559 corresponding 'fini_section' variable; it is used entirely in 37560 runtime code. 37561 37562 -- Macro: INIT_ARRAY_SECTION_ASM_OP 37563 If defined, a C expression whose value is a string, including 37564 spacing, containing the assembler operation to identify the 37565 following data as part of the '.init_array' (or equivalent) 37566 section. If not defined, GCC will assume such a section does not 37567 exist. Do not define both this macro and 'INIT_SECTION_ASM_OP'. 37568 37569 -- Macro: FINI_ARRAY_SECTION_ASM_OP 37570 If defined, a C expression whose value is a string, including 37571 spacing, containing the assembler operation to identify the 37572 following data as part of the '.fini_array' (or equivalent) 37573 section. If not defined, GCC will assume such a section does not 37574 exist. Do not define both this macro and 'FINI_SECTION_ASM_OP'. 37575 37576 -- Macro: MACH_DEP_SECTION_ASM_FLAG 37577 If defined, a C expression whose value is a character constant 37578 containing the flag used to mark a machine-dependent section. This 37579 corresponds to the 'SECTION_MACH_DEP' section flag. 37580 37581 -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION) 37582 If defined, an ASM statement that switches to a different section 37583 via SECTION_OP, calls FUNCTION, and switches back to the text 37584 section. This is used in 'crtstuff.c' if 'INIT_SECTION_ASM_OP' or 37585 'FINI_SECTION_ASM_OP' to calls to initialization and finalization 37586 functions from the init and fini sections. By default, this macro 37587 uses a simple function call. Some ports need hand-crafted assembly 37588 code to avoid dependencies on registers initialized in the function 37589 prologue or to ensure that constant pools don't end up too far way 37590 in the text section. 37591 37592 -- Macro: TARGET_LIBGCC_SDATA_SECTION 37593 If defined, a string which names the section into which small 37594 variables defined in crtstuff and libgcc should go. This is useful 37595 when the target has options for optimizing access to small data, 37596 and you want the crtstuff and libgcc routines to be conservative in 37597 what they expect of your application yet liberal in what your 37598 application expects. For example, for targets with a '.sdata' 37599 section (like MIPS), you could compile crtstuff with '-G 0' so that 37600 it doesn't require small data support from your application, but 37601 use this macro to put small data into '.sdata' so that your 37602 application can access these variables whether it uses small data 37603 or not. 37604 37605 -- Macro: FORCE_CODE_SECTION_ALIGN 37606 If defined, an ASM statement that aligns a code section to some 37607 arbitrary boundary. This is used to force all fragments of the 37608 '.init' and '.fini' sections to have to same alignment and thus 37609 prevent the linker from having to add any padding. 37610 37611 -- Macro: JUMP_TABLES_IN_TEXT_SECTION 37612 Define this macro to be an expression with a nonzero value if jump 37613 tables (for 'tablejump' insns) should be output in the text 37614 section, along with the assembler instructions. Otherwise, the 37615 readonly data section is used. 37616 37617 This macro is irrelevant if there is no separate readonly data 37618 section. 37619 37620 -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void) 37621 Define this hook if you need to do something special to set up the 37622 'varasm.c' sections, or if your target has some special sections of 37623 its own that you need to create. 37624 37625 GCC calls this hook after processing the command line, but before 37626 writing any assembly code, and before calling any of the 37627 section-returning hooks described below. 37628 37629 -- Target Hook: int TARGET_ASM_RELOC_RW_MASK (void) 37630 Return a mask describing how relocations should be treated when 37631 selecting sections. Bit 1 should be set if global relocations 37632 should be placed in a read-write section; bit 0 should be set if 37633 local relocations should be placed in a read-write section. 37634 37635 The default version of this function returns 3 when '-fpic' is in 37636 effect, and 0 otherwise. The hook is typically redefined when the 37637 target cannot support (some kinds of) dynamic relocations in 37638 read-only sections even in executables. 37639 37640 -- Target Hook: bool TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC (void) 37641 Return true to generate ADDR_DIF_VEC table or false to generate 37642 ADDR_VEC table for jumps in case of -fPIC. 37643 37644 The default version of this function returns true if flag_pic 37645 equals true and false otherwise 37646 37647 -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int 37648 RELOC, unsigned HOST_WIDE_INT ALIGN) 37649 Return the section into which EXP should be placed. You can assume 37650 that EXP is either a 'VAR_DECL' node or a constant of some sort. 37651 RELOC indicates whether the initial value of EXP requires link-time 37652 relocations. Bit 0 is set when variable contains local relocations 37653 only, while bit 1 is set for global relocations. ALIGN is the 37654 constant alignment in bits. 37655 37656 The default version of this function takes care of putting 37657 read-only variables in 'readonly_data_section'. 37658 37659 See also USE_SELECT_SECTION_FOR_FUNCTIONS. 37660 37661 -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS 37662 Define this macro if you wish TARGET_ASM_SELECT_SECTION to be 37663 called for 'FUNCTION_DECL's as well as for variables and constants. 37664 37665 In the case of a 'FUNCTION_DECL', RELOC will be zero if the 37666 function has been determined to be likely to be called, and nonzero 37667 if it is unlikely to be called. 37668 37669 -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC) 37670 Build up a unique section name, expressed as a 'STRING_CST' node, 37671 and assign it to 'DECL_SECTION_NAME (DECL)'. As with 37672 'TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial 37673 value of EXP requires link-time relocations. 37674 37675 The default version of this function appends the symbol name to the 37676 ELF section name that would normally be used for the symbol. For 37677 example, the function 'foo' would be placed in '.text.foo'. 37678 Whatever the actual target object format, this is often good 37679 enough. 37680 37681 -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree 37682 DECL) 37683 Return the readonly data section associated with 'DECL_SECTION_NAME 37684 (DECL)'. The default version of this function selects 37685 '.gnu.linkonce.r.name' if the function's section is 37686 '.gnu.linkonce.t.name', '.rodata.name' if function is in 37687 '.text.name', and the normal readonly-data section otherwise. 37688 37689 -- Target Hook: const char * TARGET_ASM_MERGEABLE_RODATA_PREFIX 37690 Usually, the compiler uses the prefix '".rodata"' to construct 37691 section names for mergeable constant data. Define this macro to 37692 override the string if a different section name should be used. 37693 37694 -- Target Hook: section * TARGET_ASM_TM_CLONE_TABLE_SECTION (void) 37695 Return the section that should be used for transactional memory 37696 clone tables. 37697 37698 -- Target Hook: section * TARGET_ASM_SELECT_RTX_SECTION (machine_mode 37699 MODE, rtx X, unsigned HOST_WIDE_INT ALIGN) 37700 Return the section into which a constant X, of mode MODE, should be 37701 placed. You can assume that X is some kind of constant in RTL. 37702 The argument MODE is redundant except in the case of a 'const_int' 37703 rtx. ALIGN is the constant alignment in bits. 37704 37705 The default version of this function takes care of putting symbolic 37706 constants in 'flag_pic' mode in 'data_section' and everything else 37707 in 'readonly_data_section'. 37708 37709 -- Target Hook: tree TARGET_MANGLE_DECL_ASSEMBLER_NAME (tree DECL, tree 37710 ID) 37711 Define this hook if you need to postprocess the assembler name 37712 generated by target-independent code. The ID provided to this hook 37713 will be the computed name (e.g., the macro 'DECL_NAME' of the DECL 37714 in C, or the mangled name of the DECL in C++). The return value of 37715 the hook is an 'IDENTIFIER_NODE' for the appropriate mangled name 37716 on your target system. The default implementation of this hook 37717 just returns the ID provided. 37718 37719 -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL, 37720 int NEW_DECL_P) 37721 Define this hook if references to a symbol or a constant must be 37722 treated differently depending on something about the variable or 37723 function named by the symbol (such as what section it is in). 37724 37725 The hook is executed immediately after rtl has been created for 37726 DECL, which may be a variable or function declaration or an entry 37727 in the constant pool. In either case, RTL is the rtl in question. 37728 Do _not_ use 'DECL_RTL (DECL)' in this hook; that field may not 37729 have been initialized yet. 37730 37731 In the case of a constant, it is safe to assume that the rtl is a 37732 'mem' whose address is a 'symbol_ref'. Most decls will also have 37733 this form, but that is not guaranteed. Global register variables, 37734 for instance, will have a 'reg' for their rtl. (Normally the right 37735 thing to do with such unusual rtl is leave it alone.) 37736 37737 The NEW_DECL_P argument will be true if this is the first time that 37738 'TARGET_ENCODE_SECTION_INFO' has been invoked on this decl. It 37739 will be false for subsequent invocations, which will happen for 37740 duplicate declarations. Whether or not anything must be done for 37741 the duplicate declaration depends on whether the hook examines 37742 'DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is 37743 called for a constant. 37744 37745 The usual thing for this hook to do is to record flags in the 37746 'symbol_ref', using 'SYMBOL_REF_FLAG' or 'SYMBOL_REF_FLAGS'. 37747 Historically, the name string was modified if it was necessary to 37748 encode more than one bit of information, but this practice is now 37749 discouraged; use 'SYMBOL_REF_FLAGS'. 37750 37751 The default definition of this hook, 'default_encode_section_info' 37752 in 'varasm.c', sets a number of commonly-useful bits in 37753 'SYMBOL_REF_FLAGS'. Check whether the default does what you need 37754 before overriding it. 37755 37756 -- Target Hook: const char * TARGET_STRIP_NAME_ENCODING (const char 37757 *NAME) 37758 Decode NAME and return the real name part, sans the characters that 37759 'TARGET_ENCODE_SECTION_INFO' may have added. 37760 37761 -- Target Hook: bool TARGET_IN_SMALL_DATA_P (const_tree EXP) 37762 Returns true if EXP should be placed into a "small data" section. 37763 The default version of this hook always returns false. 37764 37765 -- Target Hook: bool TARGET_HAVE_SRODATA_SECTION 37766 Contains the value true if the target places read-only "small data" 37767 into a separate section. The default value is false. 37768 37769 -- Target Hook: bool TARGET_PROFILE_BEFORE_PROLOGUE (void) 37770 It returns true if target wants profile code emitted before 37771 prologue. 37772 37773 The default version of this hook use the target macro 37774 'PROFILE_BEFORE_PROLOGUE'. 37775 37776 -- Target Hook: bool TARGET_BINDS_LOCAL_P (const_tree EXP) 37777 Returns true if EXP names an object for which name resolution rules 37778 must resolve to the current "module" (dynamic shared library or 37779 executable image). 37780 37781 The default version of this hook implements the name resolution 37782 rules for ELF, which has a looser model of global name binding than 37783 other currently supported object file formats. 37784 37785 -- Target Hook: bool TARGET_HAVE_TLS 37786 Contains the value true if the target supports thread-local 37787 storage. The default value is false. 37788 37789 37790File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros 37791 3779218.19 Position Independent Code 37793=============================== 37794 37795This section describes macros that help implement generation of position 37796independent code. Simply defining these macros is not enough to 37797generate valid PIC; you must also add support to the hook 37798'TARGET_LEGITIMATE_ADDRESS_P' and to the macro 'PRINT_OPERAND_ADDRESS', 37799as well as 'LEGITIMIZE_ADDRESS'. You must modify the definition of 37800'movsi' to do something appropriate when the source operand contains a 37801symbolic address. You may also need to alter the handling of switch 37802statements so that they use relative addresses. 37803 37804 -- Macro: PIC_OFFSET_TABLE_REGNUM 37805 The register number of the register used to address a table of 37806 static data addresses in memory. In some cases this register is 37807 defined by a processor's "application binary interface" (ABI). 37808 When this macro is defined, RTL is generated for this register 37809 once, as with the stack pointer and frame pointer registers. If 37810 this macro is not defined, it is up to the machine-dependent files 37811 to allocate such a register (if necessary). Note that this 37812 register must be fixed when in use (e.g. when 'flag_pic' is true). 37813 37814 -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED 37815 A C expression that is nonzero if the register defined by 37816 'PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. If not defined, 37817 the default is zero. Do not define this macro if 37818 'PIC_OFFSET_TABLE_REGNUM' is not defined. 37819 37820 -- Macro: LEGITIMATE_PIC_OPERAND_P (X) 37821 A C expression that is nonzero if X is a legitimate immediate 37822 operand on the target machine when generating position independent 37823 code. You can assume that X satisfies 'CONSTANT_P', so you need 37824 not check this. You can also assume FLAG_PIC is true, so you need 37825 not check it either. You need not define this macro if all 37826 constants (including 'SYMBOL_REF') can be immediate operands when 37827 generating position independent code. 37828 37829 37830File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros 37831 3783218.20 Defining the Output Assembler Language 37833============================================ 37834 37835This section describes macros whose principal purpose is to describe how 37836to write instructions in assembler language--rather than what the 37837instructions do. 37838 37839* Menu: 37840 37841* File Framework:: Structural information for the assembler file. 37842* Data Output:: Output of constants (numbers, strings, addresses). 37843* Uninitialized Data:: Output of uninitialized variables. 37844* Label Output:: Output and generation of labels. 37845* Initialization:: General principles of initialization 37846 and termination routines. 37847* Macros for Initialization:: 37848 Specific macros that control the handling of 37849 initialization and termination routines. 37850* Instruction Output:: Output of actual instructions. 37851* Dispatch Tables:: Output of jump tables. 37852* Exception Region Output:: Output of exception region code. 37853* Alignment Output:: Pseudo ops for alignment and skipping data. 37854 37855 37856File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format 37857 3785818.20.1 The Overall Framework of an Assembler File 37859-------------------------------------------------- 37860 37861This describes the overall framework of an assembly file. 37862 37863 -- Target Hook: void TARGET_ASM_FILE_START (void) 37864 Output to 'asm_out_file' any text which the assembler expects to 37865 find at the beginning of a file. The default behavior is 37866 controlled by two flags, documented below. Unless your target's 37867 assembler is quite unusual, if you override the default, you should 37868 call 'default_file_start' at some point in your target hook. This 37869 lets other target files rely on these variables. 37870 37871 -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF 37872 If this flag is true, the text of the macro 'ASM_APP_OFF' will be 37873 printed as the very first line in the assembly file, unless 37874 '-fverbose-asm' is in effect. (If that macro has been defined to 37875 the empty string, this variable has no effect.) With the normal 37876 definition of 'ASM_APP_OFF', the effect is to notify the GNU 37877 assembler that it need not bother stripping comments or extra 37878 whitespace from its input. This allows it to work a bit faster. 37879 37880 The default is false. You should not set it to true unless you 37881 have verified that your port does not generate any extra whitespace 37882 or comments that will cause GAS to issue errors in NO_APP mode. 37883 37884 -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE 37885 If this flag is true, 'output_file_directive' will be called for 37886 the primary source file, immediately after printing 'ASM_APP_OFF' 37887 (if that is enabled). Most ELF assemblers expect this to be done. 37888 The default is false. 37889 37890 -- Target Hook: void TARGET_ASM_FILE_END (void) 37891 Output to 'asm_out_file' any text which the assembler expects to 37892 find at the end of a file. The default is to output nothing. 37893 37894 -- Function: void file_end_indicate_exec_stack () 37895 Some systems use a common convention, the '.note.GNU-stack' special 37896 section, to indicate whether or not an object file relies on the 37897 stack being executable. If your system uses this convention, you 37898 should define 'TARGET_ASM_FILE_END' to this function. If you need 37899 to do other things in that hook, have your hook function call this 37900 function. 37901 37902 -- Target Hook: void TARGET_ASM_LTO_START (void) 37903 Output to 'asm_out_file' any text which the assembler expects to 37904 find at the start of an LTO section. The default is to output 37905 nothing. 37906 37907 -- Target Hook: void TARGET_ASM_LTO_END (void) 37908 Output to 'asm_out_file' any text which the assembler expects to 37909 find at the end of an LTO section. The default is to output 37910 nothing. 37911 37912 -- Target Hook: void TARGET_ASM_CODE_END (void) 37913 Output to 'asm_out_file' any text which is needed before emitting 37914 unwind info and debug info at the end of a file. Some targets emit 37915 here PIC setup thunks that cannot be emitted at the end of file, 37916 because they couldn't have unwind info then. The default is to 37917 output nothing. 37918 37919 -- Macro: ASM_COMMENT_START 37920 A C string constant describing how to begin a comment in the target 37921 assembler language. The compiler assumes that the comment will end 37922 at the end of the line. 37923 37924 -- Macro: ASM_APP_ON 37925 A C string constant for text to be output before each 'asm' 37926 statement or group of consecutive ones. Normally this is '"#APP"', 37927 which is a comment that has no effect on most assemblers but tells 37928 the GNU assembler that it must check the lines that follow for all 37929 valid assembler constructs. 37930 37931 -- Macro: ASM_APP_OFF 37932 A C string constant for text to be output after each 'asm' 37933 statement or group of consecutive ones. Normally this is 37934 '"#NO_APP"', which tells the GNU assembler to resume making the 37935 time-saving assumptions that are valid for ordinary compiler 37936 output. 37937 37938 -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME) 37939 A C statement to output COFF information or DWARF debugging 37940 information which indicates that filename NAME is the current 37941 source file to the stdio stream STREAM. 37942 37943 This macro need not be defined if the standard form of output for 37944 the file format in use is appropriate. 37945 37946 -- Target Hook: void TARGET_ASM_OUTPUT_SOURCE_FILENAME (FILE *FILE, 37947 const char *NAME) 37948 Output DWARF debugging information which indicates that filename 37949 NAME is the current source file to the stdio stream FILE. 37950 37951 This target hook need not be defined if the standard form of output 37952 for the file format in use is appropriate. 37953 37954 -- Target Hook: void TARGET_ASM_OUTPUT_IDENT (const char *NAME) 37955 Output a string based on NAME, suitable for the '#ident' directive, 37956 or the equivalent directive or pragma in non-C-family languages. 37957 If this hook is not defined, nothing is output for the '#ident' 37958 directive. 37959 37960 -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING) 37961 A C statement to output the string STRING to the stdio stream 37962 STREAM. If you do not call the function 'output_quoted_string' in 37963 your config files, GCC will only call it to output filenames to the 37964 assembler source. So you can use it to canonicalize the format of 37965 the filename using this macro. 37966 37967 -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME, 37968 unsigned int FLAGS, tree DECL) 37969 Output assembly directives to switch to section NAME. The section 37970 should have attributes as specified by FLAGS, which is a bit mask 37971 of the 'SECTION_*' flags defined in 'output.h'. If DECL is 37972 non-NULL, it is the 'VAR_DECL' or 'FUNCTION_DECL' with which this 37973 section is associated. 37974 37975 -- Target Hook: bool TARGET_ASM_ELF_FLAGS_NUMERIC (unsigned int FLAGS, 37976 unsigned int *NUM) 37977 This hook can be used to encode ELF section flags for which no 37978 letter code has been defined in the assembler. It is called by 37979 'default_asm_named_section' whenever the section flags need to be 37980 emitted in the assembler output. If the hook returns true, then 37981 the numerical value for ELF section flags should be calculated from 37982 FLAGS and saved in *NUM; the value is printed out instead of the 37983 normal sequence of letter codes. If the hook is not defined, or if 37984 it returns false, then NUM is ignored and the traditional letter 37985 sequence is emitted. 37986 37987 -- Target Hook: section * TARGET_ASM_FUNCTION_SECTION (tree DECL, enum 37988 node_frequency FREQ, bool STARTUP, bool EXIT) 37989 Return preferred text (sub)section for function DECL. Main purpose 37990 of this function is to separate cold, normal and hot functions. 37991 STARTUP is true when function is known to be used only at startup 37992 (from static constructors or it is 'main()'). EXIT is true when 37993 function is known to be used only at exit (from static 37994 destructors). Return NULL if function should go to default text 37995 section. 37996 37997 -- Target Hook: void TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS (FILE 37998 *FILE, tree DECL, bool NEW_IS_COLD) 37999 Used by the target to emit any assembler directives or additional 38000 labels needed when a function is partitioned between different 38001 sections. Output should be written to FILE. The function decl is 38002 available as DECL and the new section is 'cold' if NEW_IS_COLD is 38003 'true'. 38004 38005 -- Common Target Hook: bool TARGET_HAVE_NAMED_SECTIONS 38006 This flag is true if the target supports 38007 'TARGET_ASM_NAMED_SECTION'. It must not be modified by 38008 command-line option processing. 38009 38010 -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS 38011 This flag is true if we can create zeroed data by switching to a 38012 BSS section and then using 'ASM_OUTPUT_SKIP' to allocate the space. 38013 This is true on most ELF targets. 38014 38015 -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL, 38016 const char *NAME, int RELOC) 38017 Choose a set of section attributes for use by 38018 'TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a 38019 section name, and whether or not the declaration's initializer may 38020 contain runtime relocations. DECL may be null, in which case 38021 read-write data should be assumed. 38022 38023 The default version of this function handles choosing code vs data, 38024 read-only vs read-write data, and 'flag_pic'. You should only need 38025 to override this if your target has special flags that might be set 38026 via '__attribute__'. 38027 38028 -- Target Hook: int TARGET_ASM_RECORD_GCC_SWITCHES (print_switch_type 38029 TYPE, const char *TEXT) 38030 Provides the target with the ability to record the gcc command line 38031 switches that have been passed to the compiler, and options that 38032 are enabled. The TYPE argument specifies what is being recorded. 38033 It can take the following values: 38034 38035 'SWITCH_TYPE_PASSED' 38036 TEXT is a command line switch that has been set by the user. 38037 38038 'SWITCH_TYPE_ENABLED' 38039 TEXT is an option which has been enabled. This might be as a 38040 direct result of a command line switch, or because it is 38041 enabled by default or because it has been enabled as a side 38042 effect of a different command line switch. For example, the 38043 '-O2' switch enables various different individual optimization 38044 passes. 38045 38046 'SWITCH_TYPE_DESCRIPTIVE' 38047 TEXT is either NULL or some descriptive text which should be 38048 ignored. If TEXT is NULL then it is being used to warn the 38049 target hook that either recording is starting or ending. The 38050 first time TYPE is SWITCH_TYPE_DESCRIPTIVE and TEXT is NULL, 38051 the warning is for start up and the second time the warning is 38052 for wind down. This feature is to allow the target hook to 38053 make any necessary preparations before it starts to record 38054 switches and to perform any necessary tidying up after it has 38055 finished recording switches. 38056 38057 'SWITCH_TYPE_LINE_START' 38058 This option can be ignored by this target hook. 38059 38060 'SWITCH_TYPE_LINE_END' 38061 This option can be ignored by this target hook. 38062 38063 The hook's return value must be zero. Other return values may be 38064 supported in the future. 38065 38066 By default this hook is set to NULL, but an example implementation 38067 is provided for ELF based targets. Called ELF_RECORD_GCC_SWITCHES, 38068 it records the switches as ASCII text inside a new, string 38069 mergeable section in the assembler output file. The name of the 38070 new section is provided by the 38071 'TARGET_ASM_RECORD_GCC_SWITCHES_SECTION' target hook. 38072 38073 -- Target Hook: const char * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION 38074 This is the name of the section that will be created by the example 38075 ELF implementation of the 'TARGET_ASM_RECORD_GCC_SWITCHES' target 38076 hook. 38077 38078 38079File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format 38080 3808118.20.2 Output of Data 38082---------------------- 38083 38084 -- Target Hook: const char * TARGET_ASM_BYTE_OP 38085 -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP 38086 -- Target Hook: const char * TARGET_ASM_ALIGNED_PSI_OP 38087 -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP 38088 -- Target Hook: const char * TARGET_ASM_ALIGNED_PDI_OP 38089 -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP 38090 -- Target Hook: const char * TARGET_ASM_ALIGNED_PTI_OP 38091 -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP 38092 -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP 38093 -- Target Hook: const char * TARGET_ASM_UNALIGNED_PSI_OP 38094 -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP 38095 -- Target Hook: const char * TARGET_ASM_UNALIGNED_PDI_OP 38096 -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP 38097 -- Target Hook: const char * TARGET_ASM_UNALIGNED_PTI_OP 38098 -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP 38099 These hooks specify assembly directives for creating certain kinds 38100 of integer object. The 'TARGET_ASM_BYTE_OP' directive creates a 38101 byte-sized object, the 'TARGET_ASM_ALIGNED_HI_OP' one creates an 38102 aligned two-byte object, and so on. Any of the hooks may be 38103 'NULL', indicating that no suitable directive is available. 38104 38105 The compiler will print these strings at the start of a new line, 38106 followed immediately by the object's initial value. In most cases, 38107 the string should contain a tab, a pseudo-op, and then another tab. 38108 38109 -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int 38110 ALIGNED_P) 38111 The 'assemble_integer' function uses this hook to output an integer 38112 object. X is the object's value, SIZE is its size in bytes and 38113 ALIGNED_P indicates whether it is aligned. The function should 38114 return 'true' if it was able to output the object. If it returns 38115 false, 'assemble_integer' will try to split the object into smaller 38116 parts. 38117 38118 The default implementation of this hook will use the 38119 'TARGET_ASM_BYTE_OP' family of strings, returning 'false' when the 38120 relevant string is 'NULL'. 38121 38122 -- Target Hook: void TARGET_ASM_DECL_END (void) 38123 Define this hook if the target assembler requires a special marker 38124 to terminate an initialized variable declaration. 38125 38126 -- Target Hook: bool TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA (FILE *FILE, 38127 rtx X) 38128 A target hook to recognize RTX patterns that 'output_addr_const' 38129 can't deal with, and output assembly code to FILE corresponding to 38130 the pattern X. This may be used to allow machine-dependent 38131 'UNSPEC's to appear within constants. 38132 38133 If target hook fails to recognize a pattern, it must return 38134 'false', so that a standard error message is printed. If it prints 38135 an error message itself, by calling, for example, 38136 'output_operand_lossage', it may just return 'true'. 38137 38138 -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN) 38139 A C statement to output to the stdio stream STREAM an assembler 38140 instruction to assemble a string constant containing the LEN bytes 38141 at PTR. PTR will be a C expression of type 'char *' and LEN a C 38142 expression of type 'int'. 38143 38144 If the assembler has a '.ascii' pseudo-op as found in the Berkeley 38145 Unix assembler, do not define the macro 'ASM_OUTPUT_ASCII'. 38146 38147 -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N) 38148 A C statement to output word N of a function descriptor for DECL. 38149 This must be defined if 'TARGET_VTABLE_USES_DESCRIPTORS' is 38150 defined, and is otherwise unused. 38151 38152 -- Macro: CONSTANT_POOL_BEFORE_FUNCTION 38153 You may define this macro as a C expression. You should define the 38154 expression to have a nonzero value if GCC should output the 38155 constant pool for a function before the code for the function, or a 38156 zero value if GCC should output the constant pool after the 38157 function. If you do not define this macro, the usual case, GCC 38158 will output the constant pool before the function. 38159 38160 -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE) 38161 A C statement to output assembler commands to define the start of 38162 the constant pool for a function. FUNNAME is a string giving the 38163 name of the function. Should the return type of the function be 38164 required, it can be obtained via FUNDECL. SIZE is the size, in 38165 bytes, of the constant pool that will be written immediately after 38166 this call. 38167 38168 If no constant-pool prefix is required, the usual case, this macro 38169 need not be defined. 38170 38171 -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, LABELNO, 38172 JUMPTO) 38173 A C statement (with or without semicolon) to output a constant in 38174 the constant pool, if it needs special treatment. (This macro need 38175 not do anything for RTL expressions that can be output normally.) 38176 38177 The argument FILE is the standard I/O stream to output the 38178 assembler code on. X is the RTL expression for the constant to 38179 output, and MODE is the machine mode (in case X is a 'const_int'). 38180 ALIGN is the required alignment for the value X; you should output 38181 an assembler directive to force this much alignment. 38182 38183 The argument LABELNO is a number to use in an internal label for 38184 the address of this pool entry. The definition of this macro is 38185 responsible for outputting the label definition at the proper 38186 place. Here is how to do this: 38187 38188 (*targetm.asm_out.internal_label) (FILE, "LC", LABELNO); 38189 38190 When you output a pool entry specially, you should end with a 38191 'goto' to the label JUMPTO. This will prevent the same pool entry 38192 from being output a second time in the usual manner. 38193 38194 You need not define this macro if it would do nothing. 38195 38196 -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE) 38197 A C statement to output assembler commands to at the end of the 38198 constant pool for a function. FUNNAME is a string giving the name 38199 of the function. Should the return type of the function be 38200 required, you can obtain it via FUNDECL. SIZE is the size, in 38201 bytes, of the constant pool that GCC wrote immediately before this 38202 call. 38203 38204 If no constant-pool epilogue is required, the usual case, you need 38205 not define this macro. 38206 38207 -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C, STR) 38208 Define this macro as a C expression which is nonzero if C is used 38209 as a logical line separator by the assembler. STR points to the 38210 position in the string where C was found; this can be used if a 38211 line separator uses multiple characters. 38212 38213 If you do not define this macro, the default is that only the 38214 character ';' is treated as a logical line separator. 38215 38216 -- Target Hook: const char * TARGET_ASM_OPEN_PAREN 38217 -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN 38218 These target hooks are C string constants, describing the syntax in 38219 the assembler for grouping arithmetic expressions. If not 38220 overridden, they default to normal parentheses, which is correct 38221 for most assemblers. 38222 38223 These macros are provided by 'real.h' for writing the definitions of 38224'ASM_OUTPUT_DOUBLE' and the like: 38225 38226 -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L) 38227 -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L) 38228 -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L) 38229 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L) 38230 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L) 38231 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L) 38232 These translate X, of type 'REAL_VALUE_TYPE', to the target's 38233 floating point representation, and store its bit pattern in the 38234 variable L. For 'REAL_VALUE_TO_TARGET_SINGLE' and 38235 'REAL_VALUE_TO_TARGET_DECIMAL32', this variable should be a simple 38236 'long int'. For the others, it should be an array of 'long int'. 38237 The number of elements in this array is determined by the size of 38238 the desired target floating point data type: 32 bits of it go in 38239 each 'long int' array element. Each array element holds 32 bits of 38240 the result, even if 'long int' is wider than 32 bits on the host 38241 machine. 38242 38243 The array element values are designed so that you can print them 38244 out using 'fprintf' in the order they should appear in the target 38245 machine's memory. 38246 38247 38248File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format 38249 3825018.20.3 Output of Uninitialized Variables 38251----------------------------------------- 38252 38253Each of the macros in this section is used to do the whole job of 38254outputting a single uninitialized variable. 38255 38256 -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED) 38257 A C statement (sans semicolon) to output to the stdio stream STREAM 38258 the assembler definition of a common-label named NAME whose size is 38259 SIZE bytes. The variable ROUNDED is the size rounded up to 38260 whatever alignment the caller wants. It is possible that SIZE may 38261 be zero, for instance if a struct with no other member than a 38262 zero-length array is defined. In this case, the backend must 38263 output a symbol definition that allocates at least one byte, both 38264 so that the address of the resulting object does not compare equal 38265 to any other, and because some object formats cannot even express 38266 the concept of a zero-sized common symbol, as that is how they 38267 represent an ordinary undefined external. 38268 38269 Use the expression 'assemble_name (STREAM, NAME)' to output the 38270 name itself; before and after that, output the additional assembler 38271 syntax for defining the name, and a newline. 38272 38273 This macro controls how the assembler definitions of uninitialized 38274 common global variables are output. 38275 38276 -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT) 38277 Like 'ASM_OUTPUT_COMMON' except takes the required alignment as a 38278 separate, explicit argument. If you define this macro, it is used 38279 in place of 'ASM_OUTPUT_COMMON', and gives you more flexibility in 38280 handling the required alignment of the variable. The alignment is 38281 specified as the number of bits. 38282 38283 -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE, 38284 ALIGNMENT) 38285 Like 'ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable 38286 to be output, if there is one, or 'NULL_TREE' if there is no 38287 corresponding variable. If you define this macro, GCC will use it 38288 in place of both 'ASM_OUTPUT_COMMON' and 38289 'ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to 38290 see the variable's decl in order to chose what to output. 38291 38292 -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT) 38293 A C statement (sans semicolon) to output to the stdio stream STREAM 38294 the assembler definition of uninitialized global DECL named NAME 38295 whose size is SIZE bytes. The variable ALIGNMENT is the alignment 38296 specified as the number of bits. 38297 38298 Try to use function 'asm_output_aligned_bss' defined in file 38299 'varasm.c' when defining this macro. If unable, use the expression 38300 'assemble_name (STREAM, NAME)' to output the name itself; before 38301 and after that, output the additional assembler syntax for defining 38302 the name, and a newline. 38303 38304 There are two ways of handling global BSS. One is to define this 38305 macro. The other is to have 'TARGET_ASM_SELECT_SECTION' return a 38306 switchable BSS section (*note 38307 TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::). You do not need to do 38308 both. 38309 38310 Some languages do not have 'common' data, and require a non-common 38311 form of global BSS in order to handle uninitialized globals 38312 efficiently. C++ is one example of this. However, if the target 38313 does not support global BSS, the front end may choose to make 38314 globals common in order to save space in the object file. 38315 38316 -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED) 38317 A C statement (sans semicolon) to output to the stdio stream STREAM 38318 the assembler definition of a local-common-label named NAME whose 38319 size is SIZE bytes. The variable ROUNDED is the size rounded up to 38320 whatever alignment the caller wants. 38321 38322 Use the expression 'assemble_name (STREAM, NAME)' to output the 38323 name itself; before and after that, output the additional assembler 38324 syntax for defining the name, and a newline. 38325 38326 This macro controls how the assembler definitions of uninitialized 38327 static variables are output. 38328 38329 -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT) 38330 Like 'ASM_OUTPUT_LOCAL' except takes the required alignment as a 38331 separate, explicit argument. If you define this macro, it is used 38332 in place of 'ASM_OUTPUT_LOCAL', and gives you more flexibility in 38333 handling the required alignment of the variable. The alignment is 38334 specified as the number of bits. 38335 38336 -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE, 38337 ALIGNMENT) 38338 Like 'ASM_OUTPUT_ALIGNED_LOCAL' except that DECL of the variable to 38339 be output, if there is one, or 'NULL_TREE' if there is no 38340 corresponding variable. If you define this macro, GCC will use it 38341 in place of both 'ASM_OUTPUT_LOCAL' and 'ASM_OUTPUT_ALIGNED_LOCAL'. 38342 Define this macro when you need to see the variable's decl in order 38343 to chose what to output. 38344 38345 38346File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format 38347 3834818.20.4 Output and Generation of Labels 38349--------------------------------------- 38350 38351This is about outputting labels. 38352 38353 -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME) 38354 A C statement (sans semicolon) to output to the stdio stream STREAM 38355 the assembler definition of a label named NAME. Use the expression 38356 'assemble_name (STREAM, NAME)' to output the name itself; before 38357 and after that, output the additional assembler syntax for defining 38358 the name, and a newline. A default definition of this macro is 38359 provided which is correct for most systems. 38360 38361 -- Macro: ASM_OUTPUT_FUNCTION_LABEL (STREAM, NAME, DECL) 38362 A C statement (sans semicolon) to output to the stdio stream STREAM 38363 the assembler definition of a label named NAME of a function. Use 38364 the expression 'assemble_name (STREAM, NAME)' to output the name 38365 itself; before and after that, output the additional assembler 38366 syntax for defining the name, and a newline. A default definition 38367 of this macro is provided which is correct for most systems. 38368 38369 If this macro is not defined, then the function name is defined in 38370 the usual manner as a label (by means of 'ASM_OUTPUT_LABEL'). 38371 38372 -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME) 38373 Identical to 'ASM_OUTPUT_LABEL', except that NAME is known to refer 38374 to a compiler-generated label. The default definition uses 38375 'assemble_name_raw', which is like 'assemble_name' except that it 38376 is more efficient. 38377 38378 -- Macro: SIZE_ASM_OP 38379 A C string containing the appropriate assembler directive to 38380 specify the size of a symbol, without any arguments. On systems 38381 that use ELF, the default (in 'config/elfos.h') is '"\t.size\t"'; 38382 on other systems, the default is not to define this macro. 38383 38384 Define this macro only if it is correct to use the default 38385 definitions of 'ASM_OUTPUT_SIZE_DIRECTIVE' and 38386 'ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own 38387 custom definitions of those macros, or if you do not need explicit 38388 symbol sizes at all, do not define this macro. 38389 38390 -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE) 38391 A C statement (sans semicolon) to output to the stdio stream STREAM 38392 a directive telling the assembler that the size of the symbol NAME 38393 is SIZE. SIZE is a 'HOST_WIDE_INT'. If you define 'SIZE_ASM_OP', 38394 a default definition of this macro is provided. 38395 38396 -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME) 38397 A C statement (sans semicolon) to output to the stdio stream STREAM 38398 a directive telling the assembler to calculate the size of the 38399 symbol NAME by subtracting its address from the current address. 38400 38401 If you define 'SIZE_ASM_OP', a default definition of this macro is 38402 provided. The default assumes that the assembler recognizes a 38403 special '.' symbol as referring to the current address, and can 38404 calculate the difference between this and another symbol. If your 38405 assembler does not recognize '.' or cannot do calculations with it, 38406 you will need to redefine 'ASM_OUTPUT_MEASURED_SIZE' to use some 38407 other technique. 38408 38409 -- Macro: NO_DOLLAR_IN_LABEL 38410 Define this macro if the assembler does not accept the character 38411 '$' in label names. By default constructors and destructors in G++ 38412 have '$' in the identifiers. If this macro is defined, '.' is used 38413 instead. 38414 38415 -- Macro: NO_DOT_IN_LABEL 38416 Define this macro if the assembler does not accept the character 38417 '.' in label names. By default constructors and destructors in G++ 38418 have names that use '.'. If this macro is defined, these names are 38419 rewritten to avoid '.'. 38420 38421 -- Macro: TYPE_ASM_OP 38422 A C string containing the appropriate assembler directive to 38423 specify the type of a symbol, without any arguments. On systems 38424 that use ELF, the default (in 'config/elfos.h') is '"\t.type\t"'; 38425 on other systems, the default is not to define this macro. 38426 38427 Define this macro only if it is correct to use the default 38428 definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 38429 need your own custom definition of this macro, or if you do not 38430 need explicit symbol types at all, do not define this macro. 38431 38432 -- Macro: TYPE_OPERAND_FMT 38433 A C string which specifies (using 'printf' syntax) the format of 38434 the second operand to 'TYPE_ASM_OP'. On systems that use ELF, the 38435 default (in 'config/elfos.h') is '"@%s"'; on other systems, the 38436 default is not to define this macro. 38437 38438 Define this macro only if it is correct to use the default 38439 definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 38440 need your own custom definition of this macro, or if you do not 38441 need explicit symbol types at all, do not define this macro. 38442 38443 -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE) 38444 A C statement (sans semicolon) to output to the stdio stream STREAM 38445 a directive telling the assembler that the type of the symbol NAME 38446 is TYPE. TYPE is a C string; currently, that string is always 38447 either '"function"' or '"object"', but you should not count on 38448 this. 38449 38450 If you define 'TYPE_ASM_OP' and 'TYPE_OPERAND_FMT', a default 38451 definition of this macro is provided. 38452 38453 -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL) 38454 A C statement (sans semicolon) to output to the stdio stream STREAM 38455 any text necessary for declaring the name NAME of a function which 38456 is being defined. This macro is responsible for outputting the 38457 label definition (perhaps using 'ASM_OUTPUT_FUNCTION_LABEL'). The 38458 argument DECL is the 'FUNCTION_DECL' tree node representing the 38459 function. 38460 38461 If this macro is not defined, then the function name is defined in 38462 the usual manner as a label (by means of 38463 'ASM_OUTPUT_FUNCTION_LABEL'). 38464 38465 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 38466 of this macro. 38467 38468 -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL) 38469 A C statement (sans semicolon) to output to the stdio stream STREAM 38470 any text necessary for declaring the size of a function which is 38471 being defined. The argument NAME is the name of the function. The 38472 argument DECL is the 'FUNCTION_DECL' tree node representing the 38473 function. 38474 38475 If this macro is not defined, then the function size is not 38476 defined. 38477 38478 You may wish to use 'ASM_OUTPUT_MEASURED_SIZE' in the definition of 38479 this macro. 38480 38481 -- Macro: ASM_DECLARE_COLD_FUNCTION_NAME (STREAM, NAME, DECL) 38482 A C statement (sans semicolon) to output to the stdio stream STREAM 38483 any text necessary for declaring the name NAME of a cold function 38484 partition which is being defined. This macro is responsible for 38485 outputting the label definition (perhaps using 38486 'ASM_OUTPUT_FUNCTION_LABEL'). The argument DECL is the 38487 'FUNCTION_DECL' tree node representing the function. 38488 38489 If this macro is not defined, then the cold partition name is 38490 defined in the usual manner as a label (by means of 38491 'ASM_OUTPUT_LABEL'). 38492 38493 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 38494 of this macro. 38495 38496 -- Macro: ASM_DECLARE_COLD_FUNCTION_SIZE (STREAM, NAME, DECL) 38497 A C statement (sans semicolon) to output to the stdio stream STREAM 38498 any text necessary for declaring the size of a cold function 38499 partition which is being defined. The argument NAME is the name of 38500 the cold partition of the function. The argument DECL is the 38501 'FUNCTION_DECL' tree node representing the function. 38502 38503 If this macro is not defined, then the partition size is not 38504 defined. 38505 38506 You may wish to use 'ASM_OUTPUT_MEASURED_SIZE' in the definition of 38507 this macro. 38508 38509 -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL) 38510 A C statement (sans semicolon) to output to the stdio stream STREAM 38511 any text necessary for declaring the name NAME of an initialized 38512 variable which is being defined. This macro must output the label 38513 definition (perhaps using 'ASM_OUTPUT_LABEL'). The argument DECL 38514 is the 'VAR_DECL' tree node representing the variable. 38515 38516 If this macro is not defined, then the variable name is defined in 38517 the usual manner as a label (by means of 'ASM_OUTPUT_LABEL'). 38518 38519 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' and/or 38520 'ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro. 38521 38522 -- Target Hook: void TARGET_ASM_DECLARE_CONSTANT_NAME (FILE *FILE, 38523 const char *NAME, const_tree EXPR, HOST_WIDE_INT SIZE) 38524 A target hook to output to the stdio stream FILE any text necessary 38525 for declaring the name NAME of a constant which is being defined. 38526 This target hook is responsible for outputting the label definition 38527 (perhaps using 'assemble_label'). The argument EXP is the value of 38528 the constant, and SIZE is the size of the constant in bytes. The 38529 NAME will be an internal label. 38530 38531 The default version of this target hook, define the NAME in the 38532 usual manner as a label (by means of 'assemble_label'). 38533 38534 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in this target 38535 hook. 38536 38537 -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME) 38538 A C statement (sans semicolon) to output to the stdio stream STREAM 38539 any text necessary for claiming a register REGNO for a global 38540 variable DECL with name NAME. 38541 38542 If you don't define this macro, that is equivalent to defining it 38543 to do nothing. 38544 38545 -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND) 38546 A C statement (sans semicolon) to finish up declaring a variable 38547 name once the compiler has processed its initializer fully and thus 38548 has had a chance to determine the size of an array when controlled 38549 by an initializer. This is used on systems where it's necessary to 38550 declare something about the size of the object. 38551 38552 If you don't define this macro, that is equivalent to defining it 38553 to do nothing. 38554 38555 You may wish to use 'ASM_OUTPUT_SIZE_DIRECTIVE' and/or 38556 'ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro. 38557 38558 -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const 38559 char *NAME) 38560 This target hook is a function to output to the stdio stream STREAM 38561 some commands that will make the label NAME global; that is, 38562 available for reference from other files. 38563 38564 The default implementation relies on a proper definition of 38565 'GLOBAL_ASM_OP'. 38566 38567 -- Target Hook: void TARGET_ASM_GLOBALIZE_DECL_NAME (FILE *STREAM, tree 38568 DECL) 38569 This target hook is a function to output to the stdio stream STREAM 38570 some commands that will make the name associated with DECL global; 38571 that is, available for reference from other files. 38572 38573 The default implementation uses the TARGET_ASM_GLOBALIZE_LABEL 38574 target hook. 38575 38576 -- Target Hook: void TARGET_ASM_ASSEMBLE_UNDEFINED_DECL (FILE *STREAM, 38577 const char *NAME, const_tree DECL) 38578 This target hook is a function to output to the stdio stream STREAM 38579 some commands that will declare the name associated with DECL which 38580 is not defined in the current translation unit. Most assemblers do 38581 not require anything to be output in this case. 38582 38583 -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME) 38584 A C statement (sans semicolon) to output to the stdio stream STREAM 38585 some commands that will make the label NAME weak; that is, 38586 available for reference from other files but only used if no other 38587 definition is available. Use the expression 'assemble_name 38588 (STREAM, NAME)' to output the name itself; before and after that, 38589 output the additional assembler syntax for making that name weak, 38590 and a newline. 38591 38592 If you don't define this macro or 'ASM_WEAKEN_DECL', GCC will not 38593 support weak symbols and you should not define the 'SUPPORTS_WEAK' 38594 macro. 38595 38596 -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE) 38597 Combines (and replaces) the function of 'ASM_WEAKEN_LABEL' and 38598 'ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function 38599 or variable decl. If VALUE is not 'NULL', this C statement should 38600 output to the stdio stream STREAM assembler code which defines 38601 (equates) the weak symbol NAME to have the value VALUE. If VALUE 38602 is 'NULL', it should output commands to make NAME weak. 38603 38604 -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE) 38605 Outputs a directive that enables NAME to be used to refer to symbol 38606 VALUE with weak-symbol semantics. 'decl' is the declaration of 38607 'name'. 38608 38609 -- Macro: SUPPORTS_WEAK 38610 A preprocessor constant expression which evaluates to true if the 38611 target supports weak symbols. 38612 38613 If you don't define this macro, 'defaults.h' provides a default 38614 definition. If either 'ASM_WEAKEN_LABEL' or 'ASM_WEAKEN_DECL' is 38615 defined, the default definition is '1'; otherwise, it is '0'. 38616 38617 -- Macro: TARGET_SUPPORTS_WEAK 38618 A C expression which evaluates to true if the target supports weak 38619 symbols. 38620 38621 If you don't define this macro, 'defaults.h' provides a default 38622 definition. The default definition is '(SUPPORTS_WEAK)'. Define 38623 this macro if you want to control weak symbol support with a 38624 compiler flag such as '-melf'. 38625 38626 -- Macro: MAKE_DECL_ONE_ONLY (DECL) 38627 A C statement (sans semicolon) to mark DECL to be emitted as a 38628 public symbol such that extra copies in multiple translation units 38629 will be discarded by the linker. Define this macro if your object 38630 file format provides support for this concept, such as the 'COMDAT' 38631 section flags in the Microsoft Windows PE/COFF format, and this 38632 support requires changes to DECL, such as putting it in a separate 38633 section. 38634 38635 -- Macro: SUPPORTS_ONE_ONLY 38636 A C expression which evaluates to true if the target supports 38637 one-only semantics. 38638 38639 If you don't define this macro, 'varasm.c' provides a default 38640 definition. If 'MAKE_DECL_ONE_ONLY' is defined, the default 38641 definition is '1'; otherwise, it is '0'. Define this macro if you 38642 want to control one-only symbol support with a compiler flag, or if 38643 setting the 'DECL_ONE_ONLY' flag is enough to mark a declaration to 38644 be emitted as one-only. 38645 38646 -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, int 38647 VISIBILITY) 38648 This target hook is a function to output to ASM_OUT_FILE some 38649 commands that will make the symbol(s) associated with DECL have 38650 hidden, protected or internal visibility as specified by 38651 VISIBILITY. 38652 38653 -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC 38654 A C expression that evaluates to true if the target's linker 38655 expects that weak symbols do not appear in a static archive's table 38656 of contents. The default is '0'. 38657 38658 Leaving weak symbols out of an archive's table of contents means 38659 that, if a symbol will only have a definition in one translation 38660 unit and will have undefined references from other translation 38661 units, that symbol should not be weak. Defining this macro to be 38662 nonzero will thus have the effect that certain symbols that would 38663 normally be weak (explicit template instantiations, and vtables for 38664 polymorphic classes with noninline key methods) will instead be 38665 nonweak. 38666 38667 The C++ ABI requires this macro to be zero. Define this macro for 38668 targets where full C++ ABI compliance is impossible and where 38669 linker restrictions require weak symbols to be left out of a static 38670 archive's table of contents. 38671 38672 -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME) 38673 A C statement (sans semicolon) to output to the stdio stream STREAM 38674 any text necessary for declaring the name of an external symbol 38675 named NAME which is referenced in this compilation but not defined. 38676 The value of DECL is the tree node for the declaration. 38677 38678 This macro need not be defined if it does not need to output 38679 anything. The GNU assembler and most Unix assemblers don't require 38680 anything. 38681 38682 -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF) 38683 This target hook is a function to output to ASM_OUT_FILE an 38684 assembler pseudo-op to declare a library function name external. 38685 The name of the library function is given by SYMREF, which is a 38686 'symbol_ref'. 38687 38688 -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (const char 38689 *SYMBOL) 38690 This target hook is a function to output to ASM_OUT_FILE an 38691 assembler directive to annotate SYMBOL as used. The Darwin target 38692 uses the .no_dead_code_strip directive. 38693 38694 -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME) 38695 A C statement (sans semicolon) to output to the stdio stream STREAM 38696 a reference in assembler syntax to a label named NAME. This should 38697 add '_' to the front of the name, if that is customary on your 38698 operating system, as it is in most Berkeley Unix systems. This 38699 macro is used in 'assemble_name'. 38700 38701 -- Target Hook: tree TARGET_MANGLE_ASSEMBLER_NAME (const char *NAME) 38702 Given a symbol NAME, perform same mangling as 'varasm.c''s 38703 'assemble_name', but in memory rather than to a file stream, 38704 returning result as an 'IDENTIFIER_NODE'. Required for correct LTO 38705 symtabs. The default implementation calls the 38706 'TARGET_STRIP_NAME_ENCODING' hook and then prepends the 38707 'USER_LABEL_PREFIX', if any. 38708 38709 -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM) 38710 A C statement (sans semicolon) to output a reference to 38711 'SYMBOL_REF' SYM. If not defined, 'assemble_name' will be used to 38712 output the name of the symbol. This macro may be used to modify 38713 the way a symbol is referenced depending on information encoded by 38714 'TARGET_ENCODE_SECTION_INFO'. 38715 38716 -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF) 38717 A C statement (sans semicolon) to output a reference to BUF, the 38718 result of 'ASM_GENERATE_INTERNAL_LABEL'. If not defined, 38719 'assemble_name' will be used to output the name of the symbol. 38720 This macro is not used by 'output_asm_label', or the '%l' specifier 38721 that calls it; the intention is that this macro should be set when 38722 it is necessary to output a label differently when its address is 38723 being taken. 38724 38725 -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const 38726 char *PREFIX, unsigned long LABELNO) 38727 A function to output to the stdio stream STREAM a label whose name 38728 is made from the string PREFIX and the number LABELNO. 38729 38730 It is absolutely essential that these labels be distinct from the 38731 labels used for user-level functions and variables. Otherwise, 38732 certain programs will have name conflicts with internal labels. 38733 38734 It is desirable to exclude internal labels from the symbol table of 38735 the object file. Most assemblers have a naming convention for 38736 labels that should be excluded; on many systems, the letter 'L' at 38737 the beginning of a label has this effect. You should find out what 38738 convention your system uses, and follow it. 38739 38740 The default version of this function utilizes 38741 'ASM_GENERATE_INTERNAL_LABEL'. 38742 38743 -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM) 38744 A C statement to output to the stdio stream STREAM a debug info 38745 label whose name is made from the string PREFIX and the number NUM. 38746 This is useful for VLIW targets, where debug info labels may need 38747 to be treated differently than branch target labels. On some 38748 systems, branch target labels must be at the beginning of 38749 instruction bundles, but debug info labels can occur in the middle 38750 of instruction bundles. 38751 38752 If this macro is not defined, then 38753 '(*targetm.asm_out.internal_label)' will be used. 38754 38755 -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM) 38756 A C statement to store into the string STRING a label whose name is 38757 made from the string PREFIX and the number NUM. 38758 38759 This string, when output subsequently by 'assemble_name', should 38760 produce the output that '(*targetm.asm_out.internal_label)' would 38761 produce with the same PREFIX and NUM. 38762 38763 If the string begins with '*', then 'assemble_name' will output the 38764 rest of the string unchanged. It is often convenient for 38765 'ASM_GENERATE_INTERNAL_LABEL' to use '*' in this way. If the 38766 string doesn't start with '*', then 'ASM_OUTPUT_LABELREF' gets to 38767 output the string, and may change it. (Of course, 38768 'ASM_OUTPUT_LABELREF' is also part of your machine description, so 38769 you should know what it does on your machine.) 38770 38771 -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER) 38772 A C expression to assign to OUTVAR (which is a variable of type 38773 'char *') a newly allocated string made from the string NAME and 38774 the number NUMBER, with some suitable punctuation added. Use 38775 'alloca' to get space for the string. 38776 38777 The string will be used as an argument to 'ASM_OUTPUT_LABELREF' to 38778 produce an assembler label for an internal static variable whose 38779 name is NAME. Therefore, the string must be such as to result in 38780 valid assembler code. The argument NUMBER is different each time 38781 this macro is executed; it prevents conflicts between 38782 similarly-named internal static variables in different scopes. 38783 38784 Ideally this string should not be a valid C identifier, to prevent 38785 any conflict with the user's own symbols. Most assemblers allow 38786 periods or percent signs in assembler symbols; putting at least one 38787 of these between the name and the number will suffice. 38788 38789 If this macro is not defined, a default definition will be provided 38790 which is correct for most systems. 38791 38792 -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE) 38793 A C statement to output to the stdio stream STREAM assembler code 38794 which defines (equates) the symbol NAME to have the value VALUE. 38795 38796 If 'SET_ASM_OP' is defined, a default definition is provided which 38797 is correct for most systems. 38798 38799 -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME, 38800 DECL_OF_VALUE) 38801 A C statement to output to the stdio stream STREAM assembler code 38802 which defines (equates) the symbol whose tree node is DECL_OF_NAME 38803 to have the value of the tree node DECL_OF_VALUE. This macro will 38804 be used in preference to 'ASM_OUTPUT_DEF' if it is defined and if 38805 the tree nodes are available. 38806 38807 If 'SET_ASM_OP' is defined, a default definition is provided which 38808 is correct for most systems. 38809 38810 -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE) 38811 A C statement that evaluates to true if the assembler code which 38812 defines (equates) the symbol whose tree node is DECL_OF_NAME to 38813 have the value of the tree node DECL_OF_VALUE should be emitted 38814 near the end of the current compilation unit. The default is to 38815 not defer output of defines. This macro affects defines output by 38816 'ASM_OUTPUT_DEF' and 'ASM_OUTPUT_DEF_FROM_DECLS'. 38817 38818 -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE) 38819 A C statement to output to the stdio stream STREAM assembler code 38820 which defines (equates) the weak symbol NAME to have the value 38821 VALUE. If VALUE is 'NULL', it defines NAME as an undefined weak 38822 symbol. 38823 38824 Define this macro if the target only supports weak aliases; define 38825 'ASM_OUTPUT_DEF' instead if possible. 38826 38827 -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME, 38828 SEL_NAME) 38829 Define this macro to override the default assembler names used for 38830 Objective-C methods. 38831 38832 The default name is a unique method number followed by the name of 38833 the class (e.g. '_1_Foo'). For methods in categories, the name of 38834 the category is also included in the assembler name (e.g. 38835 '_1_Foo_Bar'). 38836 38837 These names are safe on most systems, but make debugging difficult 38838 since the method's selector is not present in the name. Therefore, 38839 particular systems define other ways of computing names. 38840 38841 BUF is an expression of type 'char *' which gives you a buffer in 38842 which to store the name; its length is as long as CLASS_NAME, 38843 CAT_NAME and SEL_NAME put together, plus 50 characters extra. 38844 38845 The argument IS_INST specifies whether the method is an instance 38846 method or a class method; CLASS_NAME is the name of the class; 38847 CAT_NAME is the name of the category (or 'NULL' if the method is 38848 not in a category); and SEL_NAME is the name of the selector. 38849 38850 On systems where the assembler can handle quoted names, you can use 38851 this macro to provide more human-readable names. 38852 38853 38854File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format 38855 3885618.20.5 How Initialization Functions Are Handled 38857------------------------------------------------ 38858 38859The compiled code for certain languages includes "constructors" (also 38860called "initialization routines")--functions to initialize data in the 38861program when the program is started. These functions need to be called 38862before the program is "started"--that is to say, before 'main' is 38863called. 38864 38865 Compiling some languages generates "destructors" (also called 38866"termination routines") that should be called when the program 38867terminates. 38868 38869 To make the initialization and termination functions work, the compiler 38870must output something in the assembler code to cause those functions to 38871be called at the appropriate time. When you port the compiler to a new 38872system, you need to specify how to do this. 38873 38874 There are two major ways that GCC currently supports the execution of 38875initialization and termination functions. Each way has two variants. 38876Much of the structure is common to all four variations. 38877 38878 The linker must build two lists of these functions--a list of 38879initialization functions, called '__CTOR_LIST__', and a list of 38880termination functions, called '__DTOR_LIST__'. 38881 38882 Each list always begins with an ignored function pointer (which may 38883hold 0, -1, or a count of the function pointers after it, depending on 38884the environment). This is followed by a series of zero or more function 38885pointers to constructors (or destructors), followed by a function 38886pointer containing zero. 38887 38888 Depending on the operating system and its executable file format, 38889either 'crtstuff.c' or 'libgcc2.c' traverses these lists at startup time 38890and exit time. Constructors are called in reverse order of the list; 38891destructors in forward order. 38892 38893 The best way to handle static constructors works only for object file 38894formats which provide arbitrarily-named sections. A section is set 38895aside for a list of constructors, and another for a list of destructors. 38896Traditionally these are called '.ctors' and '.dtors'. Each object file 38897that defines an initialization function also puts a word in the 38898constructor section to point to that function. The linker accumulates 38899all these words into one contiguous '.ctors' section. Termination 38900functions are handled similarly. 38901 38902 This method will be chosen as the default by 'target-def.h' if 38903'TARGET_ASM_NAMED_SECTION' is defined. A target that does not support 38904arbitrary sections, but does support special designated constructor and 38905destructor sections may define 'CTORS_SECTION_ASM_OP' and 38906'DTORS_SECTION_ASM_OP' to achieve the same effect. 38907 38908 When arbitrary sections are available, there are two variants, 38909depending upon how the code in 'crtstuff.c' is called. On systems that 38910support a ".init" section which is executed at program startup, parts of 38911'crtstuff.c' are compiled into that section. The program is linked by 38912the 'gcc' driver like this: 38913 38914 ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o 38915 38916 The prologue of a function ('__init') appears in the '.init' section of 38917'crti.o'; the epilogue appears in 'crtn.o'. Likewise for the function 38918'__fini' in the ".fini" section. Normally these files are provided by 38919the operating system or by the GNU C library, but are provided by GCC 38920for a few targets. 38921 38922 The objects 'crtbegin.o' and 'crtend.o' are (for most targets) compiled 38923from 'crtstuff.c'. They contain, among other things, code fragments 38924within the '.init' and '.fini' sections that branch to routines in the 38925'.text' section. The linker will pull all parts of a section together, 38926which results in a complete '__init' function that invokes the routines 38927we need at startup. 38928 38929 To use this variant, you must define the 'INIT_SECTION_ASM_OP' macro 38930properly. 38931 38932 If no init section is available, when GCC compiles any function called 38933'main' (or more accurately, any function designated as a program entry 38934point by the language front end calling 'expand_main_function'), it 38935inserts a procedure call to '__main' as the first executable code after 38936the function prologue. The '__main' function is defined in 'libgcc2.c' 38937and runs the global constructors. 38938 38939 In file formats that don't support arbitrary sections, there are again 38940two variants. In the simplest variant, the GNU linker (GNU 'ld') and an 38941'a.out' format must be used. In this case, 'TARGET_ASM_CONSTRUCTOR' is 38942defined to produce a '.stabs' entry of type 'N_SETT', referencing the 38943name '__CTOR_LIST__', and with the address of the void function 38944containing the initialization code as its value. The GNU linker 38945recognizes this as a request to add the value to a "set"; the values are 38946accumulated, and are eventually placed in the executable as a vector in 38947the format described above, with a leading (ignored) count and a 38948trailing zero element. 'TARGET_ASM_DESTRUCTOR' is handled similarly. 38949Since no init section is available, the absence of 'INIT_SECTION_ASM_OP' 38950causes the compilation of 'main' to call '__main' as above, starting the 38951initialization process. 38952 38953 The last variant uses neither arbitrary sections nor the GNU linker. 38954This is preferable when you want to do dynamic linking and when using 38955file formats which the GNU linker does not support, such as 'ECOFF'. In 38956this case, 'TARGET_HAVE_CTORS_DTORS' is false, initialization and 38957termination functions are recognized simply by their names. This 38958requires an extra program in the linkage step, called 'collect2'. This 38959program pretends to be the linker, for use with GCC; it does its job by 38960running the ordinary linker, but also arranges to include the vectors of 38961initialization and termination functions. These functions are called 38962via '__main' as described above. In order to use this method, 38963'use_collect2' must be defined in the target in 'config.gcc'. 38964 38965 The following section describes the specific macros that control and 38966customize the handling of initialization and termination functions. 38967 38968 38969File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format 38970 3897118.20.6 Macros Controlling Initialization Routines 38972-------------------------------------------------- 38973 38974Here are the macros that control how the compiler handles initialization 38975and termination functions: 38976 38977 -- Macro: INIT_SECTION_ASM_OP 38978 If defined, a C string constant, including spacing, for the 38979 assembler operation to identify the following data as 38980 initialization code. If not defined, GCC will assume such a 38981 section does not exist. When you are using special sections for 38982 initialization and termination functions, this macro also controls 38983 how 'crtstuff.c' and 'libgcc2.c' arrange to run the initialization 38984 functions. 38985 38986 -- Macro: HAS_INIT_SECTION 38987 If defined, 'main' will not call '__main' as described above. This 38988 macro should be defined for systems that control start-up code on a 38989 symbol-by-symbol basis, such as OSF/1, and should not be defined 38990 explicitly for systems that support 'INIT_SECTION_ASM_OP'. 38991 38992 -- Macro: LD_INIT_SWITCH 38993 If defined, a C string constant for a switch that tells the linker 38994 that the following symbol is an initialization routine. 38995 38996 -- Macro: LD_FINI_SWITCH 38997 If defined, a C string constant for a switch that tells the linker 38998 that the following symbol is a finalization routine. 38999 39000 -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC) 39001 If defined, a C statement that will write a function that can be 39002 automatically called when a shared library is loaded. The function 39003 should call FUNC, which takes no arguments. If not defined, and 39004 the object format requires an explicit initialization function, 39005 then a function called '_GLOBAL__DI' will be generated. 39006 39007 This function and the following one are used by collect2 when 39008 linking a shared library that needs constructors or destructors, or 39009 has DWARF2 exception tables embedded in the code. 39010 39011 -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC) 39012 If defined, a C statement that will write a function that can be 39013 automatically called when a shared library is unloaded. The 39014 function should call FUNC, which takes no arguments. If not 39015 defined, and the object format requires an explicit finalization 39016 function, then a function called '_GLOBAL__DD' will be generated. 39017 39018 -- Macro: INVOKE__main 39019 If defined, 'main' will call '__main' despite the presence of 39020 'INIT_SECTION_ASM_OP'. This macro should be defined for systems 39021 where the init section is not actually run automatically, but is 39022 still useful for collecting the lists of constructors and 39023 destructors. 39024 39025 -- Macro: SUPPORTS_INIT_PRIORITY 39026 If nonzero, the C++ 'init_priority' attribute is supported and the 39027 compiler should emit instructions to control the order of 39028 initialization of objects. If zero, the compiler will issue an 39029 error message upon encountering an 'init_priority' attribute. 39030 39031 -- Target Hook: bool TARGET_HAVE_CTORS_DTORS 39032 This value is true if the target supports some "native" method of 39033 collecting constructors and destructors to be run at startup and 39034 exit. It is false if we must use 'collect2'. 39035 39036 -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY) 39037 If defined, a function that outputs assembler code to arrange to 39038 call the function referenced by SYMBOL at initialization time. 39039 39040 Assume that SYMBOL is a 'SYMBOL_REF' for a function taking no 39041 arguments and with no return value. If the target supports 39042 initialization priorities, PRIORITY is a value between 0 and 39043 'MAX_INIT_PRIORITY'; otherwise it must be 'DEFAULT_INIT_PRIORITY'. 39044 39045 If this macro is not defined by the target, a suitable default will 39046 be chosen if (1) the target supports arbitrary section names, (2) 39047 the target defines 'CTORS_SECTION_ASM_OP', or (3) 'USE_COLLECT2' is 39048 not defined. 39049 39050 -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY) 39051 This is like 'TARGET_ASM_CONSTRUCTOR' but used for termination 39052 functions rather than initialization functions. 39053 39054 If 'TARGET_HAVE_CTORS_DTORS' is true, the initialization routine 39055generated for the generated object file will have static linkage. 39056 39057 If your system uses 'collect2' as the means of processing constructors, 39058then that program normally uses 'nm' to scan an object file for 39059constructor functions to be called. 39060 39061 On certain kinds of systems, you can define this macro to make 39062'collect2' work faster (and, in some cases, make it work at all): 39063 39064 -- Macro: OBJECT_FORMAT_COFF 39065 Define this macro if the system uses COFF (Common Object File 39066 Format) object files, so that 'collect2' can assume this format and 39067 scan object files directly for dynamic constructor/destructor 39068 functions. 39069 39070 This macro is effective only in a native compiler; 'collect2' as 39071 part of a cross compiler always uses 'nm' for the target machine. 39072 39073 -- Macro: REAL_NM_FILE_NAME 39074 Define this macro as a C string constant containing the file name 39075 to use to execute 'nm'. The default is to search the path normally 39076 for 'nm'. 39077 39078 -- Macro: NM_FLAGS 39079 'collect2' calls 'nm' to scan object files for static constructors 39080 and destructors and LTO info. By default, '-n' is passed. Define 39081 'NM_FLAGS' to a C string constant if other options are needed to 39082 get the same output format as GNU 'nm -n' produces. 39083 39084 If your system supports shared libraries and has a program to list the 39085dynamic dependencies of a given library or executable, you can define 39086these macros to enable support for running initialization and 39087termination functions in shared libraries: 39088 39089 -- Macro: LDD_SUFFIX 39090 Define this macro to a C string constant containing the name of the 39091 program which lists dynamic dependencies, like 'ldd' under SunOS 4. 39092 39093 -- Macro: PARSE_LDD_OUTPUT (PTR) 39094 Define this macro to be C code that extracts filenames from the 39095 output of the program denoted by 'LDD_SUFFIX'. PTR is a variable 39096 of type 'char *' that points to the beginning of a line of output 39097 from 'LDD_SUFFIX'. If the line lists a dynamic dependency, the 39098 code must advance PTR to the beginning of the filename on that 39099 line. Otherwise, it must set PTR to 'NULL'. 39100 39101 -- Macro: SHLIB_SUFFIX 39102 Define this macro to a C string constant containing the default 39103 shared library extension of the target (e.g., '".so"'). 'collect2' 39104 strips version information after this suffix when generating global 39105 constructor and destructor names. This define is only needed on 39106 targets that use 'collect2' to process constructors and 39107 destructors. 39108 39109 39110File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format 39111 3911218.20.7 Output of Assembler Instructions 39113---------------------------------------- 39114 39115This describes assembler instruction output. 39116 39117 -- Macro: REGISTER_NAMES 39118 A C initializer containing the assembler's names for the machine 39119 registers, each one as a C string constant. This is what 39120 translates register numbers in the compiler into assembler 39121 language. 39122 39123 -- Macro: ADDITIONAL_REGISTER_NAMES 39124 If defined, a C initializer for an array of structures containing a 39125 name and a register number. This macro defines additional names 39126 for hard registers, thus allowing the 'asm' option in declarations 39127 to refer to registers using alternate names. 39128 39129 -- Macro: OVERLAPPING_REGISTER_NAMES 39130 If defined, a C initializer for an array of structures containing a 39131 name, a register number and a count of the number of consecutive 39132 machine registers the name overlaps. This macro defines additional 39133 names for hard registers, thus allowing the 'asm' option in 39134 declarations to refer to registers using alternate names. Unlike 39135 'ADDITIONAL_REGISTER_NAMES', this macro should be used when the 39136 register name implies multiple underlying registers. 39137 39138 This macro should be used when it is important that a clobber in an 39139 'asm' statement clobbers all the underlying values implied by the 39140 register name. For example, on ARM, clobbering the 39141 double-precision VFP register "d0" implies clobbering both 39142 single-precision registers "s0" and "s1". 39143 39144 -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR) 39145 Define this macro if you are using an unusual assembler that 39146 requires different names for the machine instructions. 39147 39148 The definition is a C statement or statements which output an 39149 assembler instruction opcode to the stdio stream STREAM. The 39150 macro-operand PTR is a variable of type 'char *' which points to 39151 the opcode name in its "internal" form--the form that is written in 39152 the machine description. The definition should output the opcode 39153 name to STREAM, performing any translation you desire, and 39154 increment the variable PTR to point at the end of the opcode so 39155 that it will not be output twice. 39156 39157 In fact, your macro definition may process less than the entire 39158 opcode name, or more than the opcode name; but if you want to 39159 process text that includes '%'-sequences to substitute operands, 39160 you must take care of the substitution yourself. Just be sure to 39161 increment PTR over whatever text should not be output normally. 39162 39163 If you need to look at the operand values, they can be found as the 39164 elements of 'recog_data.operand'. 39165 39166 If the macro definition does nothing, the instruction is output in 39167 the usual way. 39168 39169 -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS) 39170 If defined, a C statement to be executed just prior to the output 39171 of assembler code for INSN, to modify the extracted operands so 39172 they will be output differently. 39173 39174 Here the argument OPVEC is the vector containing the operands 39175 extracted from INSN, and NOPERANDS is the number of elements of the 39176 vector which contain meaningful data for this insn. The contents 39177 of this vector are what will be used to convert the insn template 39178 into assembler code, so you can change the assembler output by 39179 changing the contents of the vector. 39180 39181 This macro is useful when various assembler syntaxes share a single 39182 file of instruction patterns; by defining this macro differently, 39183 you can cause a large class of instructions to be output 39184 differently (such as with rearranged operands). Naturally, 39185 variations in assembler syntax affecting individual insn patterns 39186 ought to be handled by writing conditional output routines in those 39187 patterns. 39188 39189 If this macro is not defined, it is equivalent to a null statement. 39190 39191 -- Target Hook: void TARGET_ASM_FINAL_POSTSCAN_INSN (FILE *FILE, 39192 rtx_insn *INSN, rtx *OPVEC, int NOPERANDS) 39193 If defined, this target hook is a function which is executed just 39194 after the output of assembler code for INSN, to change the mode of 39195 the assembler if necessary. 39196 39197 Here the argument OPVEC is the vector containing the operands 39198 extracted from INSN, and NOPERANDS is the number of elements of the 39199 vector which contain meaningful data for this insn. The contents 39200 of this vector are what was used to convert the insn template into 39201 assembler code, so you can change the assembler mode by checking 39202 the contents of the vector. 39203 39204 -- Macro: PRINT_OPERAND (STREAM, X, CODE) 39205 A C compound statement to output to stdio stream STREAM the 39206 assembler syntax for an instruction operand X. X is an RTL 39207 expression. 39208 39209 CODE is a value that can be used to specify one of several ways of 39210 printing the operand. It is used when identical operands must be 39211 printed differently depending on the context. CODE comes from the 39212 '%' specification that was used to request printing of the operand. 39213 If the specification was just '%DIGIT' then CODE is 0; if the 39214 specification was '%LTR DIGIT' then CODE is the ASCII code for LTR. 39215 39216 If X is a register, this macro should print the register's name. 39217 The names can be found in an array 'reg_names' whose type is 'char 39218 *[]'. 'reg_names' is initialized from 'REGISTER_NAMES'. 39219 39220 When the machine description has a specification '%PUNCT' (a '%' 39221 followed by a punctuation character), this macro is called with a 39222 null pointer for X and the punctuation character for CODE. 39223 39224 -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE) 39225 A C expression which evaluates to true if CODE is a valid 39226 punctuation character for use in the 'PRINT_OPERAND' macro. If 39227 'PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no 39228 punctuation characters (except for the standard one, '%') are used 39229 in this way. 39230 39231 -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X) 39232 A C compound statement to output to stdio stream STREAM the 39233 assembler syntax for an instruction operand that is a memory 39234 reference whose address is X. X is an RTL expression. 39235 39236 On some machines, the syntax for a symbolic address depends on the 39237 section that the address refers to. On these machines, define the 39238 hook 'TARGET_ENCODE_SECTION_INFO' to store the information into the 39239 'symbol_ref', and then check for it here. *Note Assembler 39240 Format::. 39241 39242 -- Macro: DBR_OUTPUT_SEQEND (FILE) 39243 A C statement, to be executed after all slot-filler instructions 39244 have been output. If necessary, call 'dbr_sequence_length' to 39245 determine the number of slots filled in a sequence (zero if not 39246 currently outputting a sequence), to decide how many no-ops to 39247 output, or whatever. 39248 39249 Don't define this macro if it has nothing to do, but it is helpful 39250 in reading assembly output if the extent of the delay sequence is 39251 made explicit (e.g. with white space). 39252 39253 Note that output routines for instructions with delay slots must be 39254prepared to deal with not being output as part of a sequence (i.e. when 39255the scheduling pass is not run, or when no slot fillers could be found.) 39256The variable 'final_sequence' is null when not processing a sequence, 39257otherwise it contains the 'sequence' rtx being output. 39258 39259 -- Macro: REGISTER_PREFIX 39260 -- Macro: LOCAL_LABEL_PREFIX 39261 -- Macro: USER_LABEL_PREFIX 39262 -- Macro: IMMEDIATE_PREFIX 39263 If defined, C string expressions to be used for the '%R', '%L', 39264 '%U', and '%I' options of 'asm_fprintf' (see 'final.c'). These are 39265 useful when a single 'md' file must support multiple assembler 39266 formats. In that case, the various 'tm.h' files can define these 39267 macros differently. 39268 39269 -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT) 39270 If defined this macro should expand to a series of 'case' 39271 statements which will be parsed inside the 'switch' statement of 39272 the 'asm_fprintf' function. This allows targets to define extra 39273 printf formats which may useful when generating their assembler 39274 statements. Note that uppercase letters are reserved for future 39275 generic extensions to asm_fprintf, and so are not available to 39276 target specific code. The output file is given by the parameter 39277 FILE. The varargs input pointer is ARGPTR and the rest of the 39278 format string, starting the character after the one that is being 39279 switched upon, is pointed to by FORMAT. 39280 39281 -- Macro: ASSEMBLER_DIALECT 39282 If your target supports multiple dialects of assembler language 39283 (such as different opcodes), define this macro as a C expression 39284 that gives the numeric index of the assembler language dialect to 39285 use, with zero as the first variant. 39286 39287 If this macro is defined, you may use constructs of the form 39288 '{option0|option1|option2...}' 39289 in the output templates of patterns (*note Output Template::) or in 39290 the first argument of 'asm_fprintf'. This construct outputs 39291 'option0', 'option1', 'option2', etc., if the value of 39292 'ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters 39293 within these strings retain their usual meaning. If there are 39294 fewer alternatives within the braces than the value of 39295 'ASSEMBLER_DIALECT', the construct outputs nothing. If it's needed 39296 to print curly braces or '|' character in assembler output 39297 directly, '%{', '%}' and '%|' can be used. 39298 39299 If you do not define this macro, the characters '{', '|' and '}' do 39300 not have any special meaning when used in templates or operands to 39301 'asm_fprintf'. 39302 39303 Define the macros 'REGISTER_PREFIX', 'LOCAL_LABEL_PREFIX', 39304 'USER_LABEL_PREFIX' and 'IMMEDIATE_PREFIX' if you can express the 39305 variations in assembler language syntax with that mechanism. 39306 Define 'ASSEMBLER_DIALECT' and use the '{option0|option1}' syntax 39307 if the syntax variant are larger and involve such things as 39308 different opcodes or operand order. 39309 39310 -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO) 39311 A C expression to output to STREAM some assembler code which will 39312 push hard register number REGNO onto the stack. The code need not 39313 be optimal, since this macro is used only when profiling. 39314 39315 -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO) 39316 A C expression to output to STREAM some assembler code which will 39317 pop hard register number REGNO off of the stack. The code need not 39318 be optimal, since this macro is used only when profiling. 39319 39320 39321File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format 39322 3932318.20.8 Output of Dispatch Tables 39324--------------------------------- 39325 39326This concerns dispatch tables. 39327 39328 -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL) 39329 A C statement to output to the stdio stream STREAM an assembler 39330 pseudo-instruction to generate a difference between two labels. 39331 VALUE and REL are the numbers of two internal labels. The 39332 definitions of these labels are output using 39333 '(*targetm.asm_out.internal_label)', and they must be printed in 39334 the same way here. For example, 39335 39336 fprintf (STREAM, "\t.word L%d-L%d\n", 39337 VALUE, REL) 39338 39339 You must provide this macro on machines where the addresses in a 39340 dispatch table are relative to the table's own address. If 39341 defined, GCC will also use this macro on all machines when 39342 producing PIC. BODY is the body of the 'ADDR_DIFF_VEC'; it is 39343 provided so that the mode and flags can be read. 39344 39345 -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE) 39346 This macro should be provided on machines where the addresses in a 39347 dispatch table are absolute. 39348 39349 The definition should be a C statement to output to the stdio 39350 stream STREAM an assembler pseudo-instruction to generate a 39351 reference to a label. VALUE is the number of an internal label 39352 whose definition is output using 39353 '(*targetm.asm_out.internal_label)'. For example, 39354 39355 fprintf (STREAM, "\t.word L%d\n", VALUE) 39356 39357 -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE) 39358 Define this if the label before a jump-table needs to be output 39359 specially. The first three arguments are the same as for 39360 '(*targetm.asm_out.internal_label)'; the fourth argument is the 39361 jump-table which follows (a 'jump_table_data' containing an 39362 'addr_vec' or 'addr_diff_vec'). 39363 39364 This feature is used on system V to output a 'swbeg' statement for 39365 the table. 39366 39367 If this macro is not defined, these labels are output with 39368 '(*targetm.asm_out.internal_label)'. 39369 39370 -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE) 39371 Define this if something special must be output at the end of a 39372 jump-table. The definition should be a C statement to be executed 39373 after the assembler code for the table is written. It should write 39374 the appropriate code to stdio stream STREAM. The argument TABLE is 39375 the jump-table insn, and NUM is the label-number of the preceding 39376 label. 39377 39378 If this macro is not defined, nothing special is output at the end 39379 of the jump-table. 39380 39381 -- Target Hook: void TARGET_ASM_POST_CFI_STARTPROC (FILE *, TREE) 39382 This target hook is used to emit assembly strings required by the 39383 target after the .cfi_startproc directive. The first argument is 39384 the file stream to write the strings to and the second argument is 39385 the function's declaration. The expected use is to add more .cfi_* 39386 directives. 39387 39388 The default is to not output any assembly strings. 39389 39390 -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (FILE *STREAM, tree 39391 DECL, int FOR_EH, int EMPTY) 39392 This target hook emits a label at the beginning of each FDE. It 39393 should be defined on targets where FDEs need special labels, and it 39394 should write the appropriate label, for the FDE associated with the 39395 function declaration DECL, to the stdio stream STREAM. The third 39396 argument, FOR_EH, is a boolean: true if this is for an exception 39397 table. The fourth argument, EMPTY, is a boolean: true if this is a 39398 placeholder label for an omitted FDE. 39399 39400 The default is that FDEs are not given nonlocal labels. 39401 39402 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL (FILE *STREAM) 39403 This target hook emits a label at the beginning of the exception 39404 table. It should be defined on targets where it is desirable for 39405 the table to be broken up according to function. 39406 39407 The default is that no label is emitted. 39408 39409 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_PERSONALITY (rtx 39410 PERSONALITY) 39411 If the target implements 'TARGET_ASM_UNWIND_EMIT', this hook may be 39412 used to emit a directive to install a personality hook into the 39413 unwind info. This hook should not be used if dwarf2 unwind info is 39414 used. 39415 39416 -- Target Hook: void TARGET_ASM_UNWIND_EMIT (FILE *STREAM, rtx_insn 39417 *INSN) 39418 This target hook emits assembly directives required to unwind the 39419 given instruction. This is only used when 39420 'TARGET_EXCEPT_UNWIND_INFO' returns 'UI_TARGET'. 39421 39422 -- Target Hook: bool TARGET_ASM_UNWIND_EMIT_BEFORE_INSN 39423 True if the 'TARGET_ASM_UNWIND_EMIT' hook should be called before 39424 the assembly for INSN has been emitted, false if the hook should be 39425 called afterward. 39426 39427 -- Target Hook: bool TARGET_ASM_SHOULD_RESTORE_CFA_STATE (void) 39428 For DWARF-based unwind frames, two CFI instructions provide for 39429 save and restore of register state. GCC maintains the current 39430 frame address (CFA) separately from the register bank but the 39431 unwinder in libgcc preserves this state along with the registers 39432 (and this is expected by the code that writes the unwind frames). 39433 This hook allows the target to specify that the CFA data is not 39434 saved/restored along with the registers by the target unwinder so 39435 that suitable additional instructions should be emitted to restore 39436 it. 39437 39438 39439File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format 39440 3944118.20.9 Assembler Commands for Exception Regions 39442------------------------------------------------ 39443 39444This describes commands marking the start and the end of an exception 39445region. 39446 39447 -- Macro: EH_FRAME_SECTION_NAME 39448 If defined, a C string constant for the name of the section 39449 containing exception handling frame unwind information. If not 39450 defined, GCC will provide a default definition if the target 39451 supports named sections. 'crtstuff.c' uses this macro to switch to 39452 the appropriate section. 39453 39454 You should define this symbol if your target supports DWARF 2 frame 39455 unwind information and the default definition does not work. 39456 39457 -- Macro: EH_FRAME_THROUGH_COLLECT2 39458 If defined, DWARF 2 frame unwind information will identified by 39459 specially named labels. The collect2 process will locate these 39460 labels and generate code to register the frames. 39461 39462 This might be necessary, for instance, if the system linker will 39463 not place the eh_frames in-between the sentinals from 'crtstuff.c', 39464 or if the system linker does garbage collection and sections cannot 39465 be marked as not to be collected. 39466 39467 -- Macro: EH_TABLES_CAN_BE_READ_ONLY 39468 Define this macro to 1 if your target is such that no frame unwind 39469 information encoding used with non-PIC code will ever require a 39470 runtime relocation, but the linker may not support merging 39471 read-only and read-write sections into a single read-write section. 39472 39473 -- Macro: MASK_RETURN_ADDR 39474 An rtx used to mask the return address found via 'RETURN_ADDR_RTX', 39475 so that it does not contain any extraneous set bits in it. 39476 39477 -- Macro: DWARF2_UNWIND_INFO 39478 Define this macro to 0 if your target supports DWARF 2 frame unwind 39479 information, but it does not yet work with exception handling. 39480 Otherwise, if your target supports this information (if it defines 39481 'INCOMING_RETURN_ADDR_RTX' and 'OBJECT_FORMAT_ELF'), GCC will 39482 provide a default definition of 1. 39483 39484 -- Common Target Hook: enum unwind_info_type TARGET_EXCEPT_UNWIND_INFO 39485 (struct gcc_options *OPTS) 39486 This hook defines the mechanism that will be used for exception 39487 handling by the target. If the target has ABI specified unwind 39488 tables, the hook should return 'UI_TARGET'. If the target is to 39489 use the 'setjmp'/'longjmp'-based exception handling scheme, the 39490 hook should return 'UI_SJLJ'. If the target supports DWARF 2 frame 39491 unwind information, the hook should return 'UI_DWARF2'. 39492 39493 A target may, if exceptions are disabled, choose to return 39494 'UI_NONE'. This may end up simplifying other parts of 39495 target-specific code. The default implementation of this hook 39496 never returns 'UI_NONE'. 39497 39498 Note that the value returned by this hook should be constant. It 39499 should not depend on anything except the command-line switches 39500 described by OPTS. In particular, the setting 'UI_SJLJ' must be 39501 fixed at compiler start-up as C pre-processor macros and builtin 39502 functions related to exception handling are set up depending on 39503 this setting. 39504 39505 The default implementation of the hook first honors the 39506 '--enable-sjlj-exceptions' configure option, then 39507 'DWARF2_UNWIND_INFO', and finally defaults to 'UI_SJLJ'. If 39508 'DWARF2_UNWIND_INFO' depends on command-line options, the target 39509 must define this hook so that OPTS is used correctly. 39510 39511 -- Common Target Hook: bool TARGET_UNWIND_TABLES_DEFAULT 39512 This variable should be set to 'true' if the target ABI requires 39513 unwinding tables even when exceptions are not used. It must not be 39514 modified by command-line option processing. 39515 39516 -- Macro: DONT_USE_BUILTIN_SETJMP 39517 Define this macro to 1 if the 'setjmp'/'longjmp'-based scheme 39518 should use the 'setjmp'/'longjmp' functions from the C library 39519 instead of the '__builtin_setjmp'/'__builtin_longjmp' machinery. 39520 39521 -- Macro: JMP_BUF_SIZE 39522 This macro has no effect unless 'DONT_USE_BUILTIN_SETJMP' is also 39523 defined. Define this macro if the default size of 'jmp_buf' buffer 39524 for the 'setjmp'/'longjmp'-based exception handling mechanism is 39525 not large enough, or if it is much too large. The default size is 39526 'FIRST_PSEUDO_REGISTER * sizeof(void *)'. 39527 39528 -- Macro: DWARF_CIE_DATA_ALIGNMENT 39529 This macro need only be defined if the target might save registers 39530 in the function prologue at an offset to the stack pointer that is 39531 not aligned to 'UNITS_PER_WORD'. The definition should be the 39532 negative minimum alignment if 'STACK_GROWS_DOWNWARD' is true, and 39533 the positive minimum alignment otherwise. *Note DWARF::. Only 39534 applicable if the target supports DWARF 2 frame unwind information. 39535 39536 -- Target Hook: bool TARGET_TERMINATE_DW2_EH_FRAME_INFO 39537 Contains the value true if the target should add a zero word onto 39538 the end of a Dwarf-2 frame info section when used for exception 39539 handling. Default value is false if 'EH_FRAME_SECTION_NAME' is 39540 defined, and true otherwise. 39541 39542 -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG) 39543 Given a register, this hook should return a parallel of registers 39544 to represent where to find the register pieces. Define this hook 39545 if the register and its mode are represented in Dwarf in 39546 non-contiguous locations, or if the register should be represented 39547 in more than one register in Dwarf. Otherwise, this hook should 39548 return 'NULL_RTX'. If not defined, the default is to return 39549 'NULL_RTX'. 39550 39551 -- Target Hook: machine_mode TARGET_DWARF_FRAME_REG_MODE (int REGNO) 39552 Given a register, this hook should return the mode which the 39553 corresponding Dwarf frame register should have. This is normally 39554 used to return a smaller mode than the raw mode to prevent call 39555 clobbered parts of a register altering the frame register size 39556 39557 -- Target Hook: void TARGET_INIT_DWARF_REG_SIZES_EXTRA (tree ADDRESS) 39558 If some registers are represented in Dwarf-2 unwind information in 39559 multiple pieces, define this hook to fill in information about the 39560 sizes of those pieces in the table used by the unwinder at runtime. 39561 It will be called by 'expand_builtin_init_dwarf_reg_sizes' after 39562 filling in a single size corresponding to each hard register; 39563 ADDRESS is the address of the table. 39564 39565 -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM) 39566 This hook is used to output a reference from a frame unwinding 39567 table to the type_info object identified by SYM. It should return 39568 'true' if the reference was output. Returning 'false' will cause 39569 the reference to be output using the normal Dwarf2 routines. 39570 39571 -- Target Hook: bool TARGET_ARM_EABI_UNWINDER 39572 This flag should be set to 'true' on targets that use an ARM EABI 39573 based unwinding library, and 'false' on other targets. This 39574 effects the format of unwinding tables, and how the unwinder in 39575 entered after running a cleanup. The default is 'false'. 39576 39577 39578File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format 39579 3958018.20.10 Assembler Commands for Alignment 39581----------------------------------------- 39582 39583This describes commands for alignment. 39584 39585 -- Macro: JUMP_ALIGN (LABEL) 39586 The alignment (log base 2) to put in front of LABEL, which is a 39587 common destination of jumps and has no fallthru incoming edge. 39588 39589 This macro need not be defined if you don't want any special 39590 alignment to be done at such a time. Most machine descriptions do 39591 not currently define the macro. 39592 39593 Unless it's necessary to inspect the LABEL parameter, it is better 39594 to set the variable ALIGN_JUMPS in the target's 39595 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 39596 user's selection in ALIGN_JUMPS in a 'JUMP_ALIGN' implementation. 39597 39598 -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL) 39599 The alignment (log base 2) to put in front of LABEL, which follows 39600 a 'BARRIER'. 39601 39602 This macro need not be defined if you don't want any special 39603 alignment to be done at such a time. Most machine descriptions do 39604 not currently define the macro. 39605 39606 -- Macro: LOOP_ALIGN (LABEL) 39607 The alignment (log base 2) to put in front of LABEL that heads a 39608 frequently executed basic block (usually the header of a loop). 39609 39610 This macro need not be defined if you don't want any special 39611 alignment to be done at such a time. Most machine descriptions do 39612 not currently define the macro. 39613 39614 Unless it's necessary to inspect the LABEL parameter, it is better 39615 to set the variable 'align_loops' in the target's 39616 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 39617 user's selection in 'align_loops' in a 'LOOP_ALIGN' implementation. 39618 39619 -- Macro: LABEL_ALIGN (LABEL) 39620 The alignment (log base 2) to put in front of LABEL. If 39621 'LABEL_ALIGN_AFTER_BARRIER' / 'LOOP_ALIGN' specify a different 39622 alignment, the maximum of the specified values is used. 39623 39624 Unless it's necessary to inspect the LABEL parameter, it is better 39625 to set the variable 'align_labels' in the target's 39626 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 39627 user's selection in 'align_labels' in a 'LABEL_ALIGN' 39628 implementation. 39629 39630 -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES) 39631 A C statement to output to the stdio stream STREAM an assembler 39632 instruction to advance the location counter by NBYTES bytes. Those 39633 bytes should be zero when loaded. NBYTES will be a C expression of 39634 type 'unsigned HOST_WIDE_INT'. 39635 39636 -- Macro: ASM_NO_SKIP_IN_TEXT 39637 Define this macro if 'ASM_OUTPUT_SKIP' should not be used in the 39638 text section because it fails to put zeros in the bytes that are 39639 skipped. This is true on many Unix systems, where the pseudo-op to 39640 skip bytes produces no-op instructions rather than zeros when used 39641 in the text section. 39642 39643 -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER) 39644 A C statement to output to the stdio stream STREAM an assembler 39645 command to advance the location counter to a multiple of 2 to the 39646 POWER bytes. POWER will be a C expression of type 'int'. 39647 39648 -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER) 39649 Like 'ASM_OUTPUT_ALIGN', except that the "nop" instruction is used 39650 for padding, if necessary. 39651 39652 -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP) 39653 A C statement to output to the stdio stream STREAM an assembler 39654 command to advance the location counter to a multiple of 2 to the 39655 POWER bytes, but only if MAX_SKIP or fewer bytes are needed to 39656 satisfy the alignment request. POWER and MAX_SKIP will be a C 39657 expression of type 'int'. 39658 39659 39660File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros 39661 3966218.21 Controlling Debugging Information Format 39663============================================== 39664 39665This describes how to specify debugging information. 39666 39667* Menu: 39668 39669* All Debuggers:: Macros that affect all debugging formats uniformly. 39670* DBX Options:: Macros enabling specific options in DBX format. 39671* DBX Hooks:: Hook macros for varying DBX format. 39672* File Names and DBX:: Macros controlling output of file names in DBX format. 39673* DWARF:: Macros for DWARF format. 39674* VMS Debug:: Macros for VMS debug format. 39675 39676 39677File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info 39678 3967918.21.1 Macros Affecting All Debugging Formats 39680---------------------------------------------- 39681 39682These macros affect all debugging formats. 39683 39684 -- Macro: DBX_REGISTER_NUMBER (REGNO) 39685 A C expression that returns the DBX register number for the 39686 compiler register number REGNO. In the default macro provided, the 39687 value of this expression will be REGNO itself. But sometimes there 39688 are some registers that the compiler knows about and DBX does not, 39689 or vice versa. In such cases, some register may need to have one 39690 number in the compiler and another for DBX. 39691 39692 If two registers have consecutive numbers inside GCC, and they can 39693 be used as a pair to hold a multiword value, then they _must_ have 39694 consecutive numbers after renumbering with 'DBX_REGISTER_NUMBER'. 39695 Otherwise, debuggers will be unable to access such a pair, because 39696 they expect register pairs to be consecutive in their own numbering 39697 scheme. 39698 39699 If you find yourself defining 'DBX_REGISTER_NUMBER' in way that 39700 does not preserve register pairs, then what you must do instead is 39701 redefine the actual register numbering scheme. 39702 39703 -- Macro: DEBUGGER_AUTO_OFFSET (X) 39704 A C expression that returns the integer offset value for an 39705 automatic variable having address X (an RTL expression). The 39706 default computation assumes that X is based on the frame-pointer 39707 and gives the offset from the frame-pointer. This is required for 39708 targets that produce debugging output for DBX and allow the 39709 frame-pointer to be eliminated when the '-g' option is used. 39710 39711 -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X) 39712 A C expression that returns the integer offset value for an 39713 argument having address X (an RTL expression). The nominal offset 39714 is OFFSET. 39715 39716 -- Macro: PREFERRED_DEBUGGING_TYPE 39717 A C expression that returns the type of debugging output GCC should 39718 produce when the user specifies just '-g'. Define this if you have 39719 arranged for GCC to support more than one format of debugging 39720 output. Currently, the allowable values are 'DBX_DEBUG', 39721 'DWARF2_DEBUG', 'XCOFF_DEBUG', 'VMS_DEBUG', and 39722 'VMS_AND_DWARF2_DEBUG'. 39723 39724 When the user specifies '-ggdb', GCC normally also uses the value 39725 of this macro to select the debugging output format, but with two 39726 exceptions. If 'DWARF2_DEBUGGING_INFO' is defined, GCC uses the 39727 value 'DWARF2_DEBUG'. Otherwise, if 'DBX_DEBUGGING_INFO' is 39728 defined, GCC uses 'DBX_DEBUG'. 39729 39730 The value of this macro only affects the default debugging output; 39731 the user can always get a specific type of output by using 39732 '-gstabs', '-gdwarf-2', '-gxcoff', or '-gvms'. 39733 39734 39735File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info 39736 3973718.21.2 Specific Options for DBX Output 39738--------------------------------------- 39739 39740These are specific options for DBX output. 39741 39742 -- Macro: DBX_DEBUGGING_INFO 39743 Define this macro if GCC should produce debugging output for DBX in 39744 response to the '-g' option. 39745 39746 -- Macro: XCOFF_DEBUGGING_INFO 39747 Define this macro if GCC should produce XCOFF format debugging 39748 output in response to the '-g' option. This is a variant of DBX 39749 format. 39750 39751 -- Macro: DEFAULT_GDB_EXTENSIONS 39752 Define this macro to control whether GCC should by default generate 39753 GDB's extended version of DBX debugging information (assuming 39754 DBX-format debugging information is enabled at all). If you don't 39755 define the macro, the default is 1: always generate the extended 39756 information if there is any occasion to. 39757 39758 -- Macro: DEBUG_SYMS_TEXT 39759 Define this macro if all '.stabs' commands should be output while 39760 in the text section. 39761 39762 -- Macro: ASM_STABS_OP 39763 A C string constant, including spacing, naming the assembler pseudo 39764 op to use instead of '"\t.stabs\t"' to define an ordinary debugging 39765 symbol. If you don't define this macro, '"\t.stabs\t"' is used. 39766 This macro applies only to DBX debugging information format. 39767 39768 -- Macro: ASM_STABD_OP 39769 A C string constant, including spacing, naming the assembler pseudo 39770 op to use instead of '"\t.stabd\t"' to define a debugging symbol 39771 whose value is the current location. If you don't define this 39772 macro, '"\t.stabd\t"' is used. This macro applies only to DBX 39773 debugging information format. 39774 39775 -- Macro: ASM_STABN_OP 39776 A C string constant, including spacing, naming the assembler pseudo 39777 op to use instead of '"\t.stabn\t"' to define a debugging symbol 39778 with no name. If you don't define this macro, '"\t.stabn\t"' is 39779 used. This macro applies only to DBX debugging information format. 39780 39781 -- Macro: DBX_NO_XREFS 39782 Define this macro if DBX on your system does not support the 39783 construct 'xsTAGNAME'. On some systems, this construct is used to 39784 describe a forward reference to a structure named TAGNAME. On 39785 other systems, this construct is not supported at all. 39786 39787 -- Macro: DBX_CONTIN_LENGTH 39788 A symbol name in DBX-format debugging information is normally 39789 continued (split into two separate '.stabs' directives) when it 39790 exceeds a certain length (by default, 80 characters). On some 39791 operating systems, DBX requires this splitting; on others, 39792 splitting must not be done. You can inhibit splitting by defining 39793 this macro with the value zero. You can override the default 39794 splitting-length by defining this macro as an expression for the 39795 length you desire. 39796 39797 -- Macro: DBX_CONTIN_CHAR 39798 Normally continuation is indicated by adding a '\' character to the 39799 end of a '.stabs' string when a continuation follows. To use a 39800 different character instead, define this macro as a character 39801 constant for the character you want to use. Do not define this 39802 macro if backslash is correct for your system. 39803 39804 -- Macro: DBX_STATIC_STAB_DATA_SECTION 39805 Define this macro if it is necessary to go to the data section 39806 before outputting the '.stabs' pseudo-op for a non-global static 39807 variable. 39808 39809 -- Macro: DBX_TYPE_DECL_STABS_CODE 39810 The value to use in the "code" field of the '.stabs' directive for 39811 a typedef. The default is 'N_LSYM'. 39812 39813 -- Macro: DBX_STATIC_CONST_VAR_CODE 39814 The value to use in the "code" field of the '.stabs' directive for 39815 a static variable located in the text section. DBX format does not 39816 provide any "right" way to do this. The default is 'N_FUN'. 39817 39818 -- Macro: DBX_REGPARM_STABS_CODE 39819 The value to use in the "code" field of the '.stabs' directive for 39820 a parameter passed in registers. DBX format does not provide any 39821 "right" way to do this. The default is 'N_RSYM'. 39822 39823 -- Macro: DBX_REGPARM_STABS_LETTER 39824 The letter to use in DBX symbol data to identify a symbol as a 39825 parameter passed in registers. DBX format does not customarily 39826 provide any way to do this. The default is ''P''. 39827 39828 -- Macro: DBX_FUNCTION_FIRST 39829 Define this macro if the DBX information for a function and its 39830 arguments should precede the assembler code for the function. 39831 Normally, in DBX format, the debugging information entirely follows 39832 the assembler code. 39833 39834 -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE 39835 Define this macro, with value 1, if the value of a symbol 39836 describing the scope of a block ('N_LBRAC' or 'N_RBRAC') should be 39837 relative to the start of the enclosing function. Normally, GCC 39838 uses an absolute address. 39839 39840 -- Macro: DBX_LINES_FUNCTION_RELATIVE 39841 Define this macro, with value 1, if the value of a symbol 39842 indicating the current line number ('N_SLINE') should be relative 39843 to the start of the enclosing function. Normally, GCC uses an 39844 absolute address. 39845 39846 -- Macro: DBX_USE_BINCL 39847 Define this macro if GCC should generate 'N_BINCL' and 'N_EINCL' 39848 stabs for included header files, as on Sun systems. This macro 39849 also directs GCC to output a type number as a pair of a file number 39850 and a type number within the file. Normally, GCC does not generate 39851 'N_BINCL' or 'N_EINCL' stabs, and it outputs a single number for a 39852 type number. 39853 39854 39855File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info 39856 3985718.21.3 Open-Ended Hooks for DBX Format 39858--------------------------------------- 39859 39860These are hooks for DBX format. 39861 39862 -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER) 39863 A C statement to output DBX debugging information before code for 39864 line number LINE of the current source file to the stdio stream 39865 STREAM. COUNTER is the number of time the macro was invoked, 39866 including the current invocation; it is intended to generate unique 39867 labels in the assembly output. 39868 39869 This macro should not be defined if the default output is correct, 39870 or if it can be made correct by defining 39871 'DBX_LINES_FUNCTION_RELATIVE'. 39872 39873 -- Macro: NO_DBX_FUNCTION_END 39874 Some stabs encapsulation formats (in particular ECOFF), cannot 39875 handle the '.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx 39876 extension construct. On those machines, define this macro to turn 39877 this feature off without disturbing the rest of the gdb extensions. 39878 39879 -- Macro: NO_DBX_BNSYM_ENSYM 39880 Some assemblers cannot handle the '.stabd BNSYM/ENSYM,0,0' gdb dbx 39881 extension construct. On those machines, define this macro to turn 39882 this feature off without disturbing the rest of the gdb extensions. 39883 39884 39885File: gccint.info, Node: File Names and DBX, Next: DWARF, Prev: DBX Hooks, Up: Debugging Info 39886 3988718.21.4 File Names in DBX Format 39888-------------------------------- 39889 39890This describes file names in DBX format. 39891 39892 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME) 39893 A C statement to output DBX debugging information to the stdio 39894 stream STREAM, which indicates that file NAME is the main source 39895 file--the file specified as the input file for compilation. This 39896 macro is called only once, at the beginning of compilation. 39897 39898 This macro need not be defined if the standard form of output for 39899 DBX debugging information is appropriate. 39900 39901 It may be necessary to refer to a label equal to the beginning of 39902 the text section. You can use 'assemble_name (stream, 39903 ltext_label_name)' to do so. If you do this, you must also set the 39904 variable USED_LTEXT_LABEL_NAME to 'true'. 39905 39906 -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY 39907 Define this macro, with value 1, if GCC should not emit an 39908 indication of the current directory for compilation and current 39909 source language at the beginning of the file. 39910 39911 -- Macro: NO_DBX_GCC_MARKER 39912 Define this macro, with value 1, if GCC should not emit an 39913 indication that this object file was compiled by GCC. The default 39914 is to emit an 'N_OPT' stab at the beginning of every source file, 39915 with 'gcc2_compiled.' for the string and value 0. 39916 39917 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME) 39918 A C statement to output DBX debugging information at the end of 39919 compilation of the main source file NAME. Output should be written 39920 to the stdio stream STREAM. 39921 39922 If you don't define this macro, nothing special is output at the 39923 end of compilation, which is correct for most machines. 39924 39925 -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END 39926 Define this macro _instead of_ defining 39927 'DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at 39928 the end of compilation is an 'N_SO' stab with an empty string, 39929 whose value is the highest absolute text address in the file. 39930 39931 39932File: gccint.info, Node: DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info 39933 3993418.21.5 Macros for DWARF Output 39935------------------------------- 39936 39937Here are macros for DWARF output. 39938 39939 -- Macro: DWARF2_DEBUGGING_INFO 39940 Define this macro if GCC should produce dwarf version 2 format 39941 debugging output in response to the '-g' option. 39942 39943 -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (const_tree 39944 FUNCTION) 39945 Define this to enable the dwarf attribute 39946 'DW_AT_calling_convention' to be emitted for each function. 39947 Instead of an integer return the enum value for the 'DW_CC_' 39948 tag. 39949 39950 To support optional call frame debugging information, you must also 39951 define 'INCOMING_RETURN_ADDR_RTX' and either set 39952 'RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the 39953 prologue, or call 'dwarf2out_def_cfa' and 'dwarf2out_reg_save' as 39954 appropriate from 'TARGET_ASM_FUNCTION_PROLOGUE' if you don't. 39955 39956 -- Macro: DWARF2_FRAME_INFO 39957 Define this macro to a nonzero value if GCC should always output 39958 Dwarf 2 frame information. If 'TARGET_EXCEPT_UNWIND_INFO' (*note 39959 Exception Region Output::) returns 'UI_DWARF2', and exceptions are 39960 enabled, GCC will output this information not matter how you define 39961 'DWARF2_FRAME_INFO'. 39962 39963 -- Target Hook: enum unwind_info_type TARGET_DEBUG_UNWIND_INFO (void) 39964 This hook defines the mechanism that will be used for describing 39965 frame unwind information to the debugger. Normally the hook will 39966 return 'UI_DWARF2' if DWARF 2 debug information is enabled, and 39967 return 'UI_NONE' otherwise. 39968 39969 A target may return 'UI_DWARF2' even when DWARF 2 debug information 39970 is disabled in order to always output DWARF 2 frame information. 39971 39972 A target may return 'UI_TARGET' if it has ABI specified unwind 39973 tables. This will suppress generation of the normal debug frame 39974 unwind information. 39975 39976 -- Macro: DWARF2_ASM_LINE_DEBUG_INFO 39977 Define this macro to be a nonzero value if the assembler can 39978 generate Dwarf 2 line debug info sections. This will result in 39979 much more compact line number tables, and hence is desirable if it 39980 works. 39981 39982 -- Macro: DWARF2_ASM_VIEW_DEBUG_INFO 39983 Define this macro to be a nonzero value if the assembler supports 39984 view assignment and verification in '.loc'. If it does not, but 39985 the user enables location views, the compiler may have to fallback 39986 to internal line number tables. 39987 39988 -- Target Hook: int TARGET_RESET_LOCATION_VIEW (rtx_insn *) 39989 This hook, if defined, enables -ginternal-reset-location-views, and 39990 uses its result to override cases in which the estimated min insn 39991 length might be nonzero even when a PC advance (i.e., a view reset) 39992 cannot be taken for granted. 39993 39994 If the hook is defined, it must return a positive value to indicate 39995 the insn definitely advances the PC, and so the view number can be 39996 safely assumed to be reset; a negative value to mean the insn 39997 definitely does not advance the PC, and os the view number must not 39998 be reset; or zero to decide based on the estimated insn length. 39999 40000 If insn length is to be regarded as reliable, set the hook to 40001 'hook_int_rtx_insn_0'. 40002 40003 -- Target Hook: bool TARGET_WANT_DEBUG_PUB_SECTIONS 40004 True if the '.debug_pubtypes' and '.debug_pubnames' sections should 40005 be emitted. These sections are not used on most platforms, and in 40006 particular GDB does not use them. 40007 40008 -- Target Hook: bool TARGET_DELAY_SCHED2 40009 True if sched2 is not to be run at its normal place. This usually 40010 means it will be run as part of machine-specific reorg. 40011 40012 -- Target Hook: bool TARGET_DELAY_VARTRACK 40013 True if vartrack is not to be run at its normal place. This 40014 usually means it will be run as part of machine-specific reorg. 40015 40016 -- Target Hook: bool TARGET_NO_REGISTER_ALLOCATION 40017 True if register allocation and the passes following it should not 40018 be run. Usually true only for virtual assembler targets. 40019 40020 -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2) 40021 A C statement to issue assembly directives that create a difference 40022 LAB1 minus LAB2, using an integer of the given SIZE. 40023 40024 -- Macro: ASM_OUTPUT_DWARF_VMS_DELTA (STREAM, SIZE, LABEL1, LABEL2) 40025 A C statement to issue assembly directives that create a difference 40026 between the two given labels in system defined units, e.g. 40027 instruction slots on IA64 VMS, using an integer of the given size. 40028 40029 -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL, OFFSET, 40030 SECTION) 40031 A C statement to issue assembly directives that create a 40032 section-relative reference to the given LABEL plus OFFSET, using an 40033 integer of the given SIZE. The label is known to be defined in the 40034 given SECTION. 40035 40036 -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL) 40037 A C statement to issue assembly directives that create a 40038 self-relative reference to the given LABEL, using an integer of the 40039 given SIZE. 40040 40041 -- Macro: ASM_OUTPUT_DWARF_DATAREL (STREAM, SIZE, LABEL) 40042 A C statement to issue assembly directives that create a reference 40043 to the given LABEL relative to the dbase, using an integer of the 40044 given SIZE. 40045 40046 -- Macro: ASM_OUTPUT_DWARF_TABLE_REF (LABEL) 40047 A C statement to issue assembly directives that create a reference 40048 to the DWARF table identifier LABEL from the current section. This 40049 is used on some systems to avoid garbage collecting a DWARF table 40050 which is referenced by a function. 40051 40052 -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int 40053 SIZE, rtx X) 40054 If defined, this target hook is a function which outputs a 40055 DTP-relative reference to the given TLS symbol of the specified 40056 size. 40057 40058 40059File: gccint.info, Node: VMS Debug, Prev: DWARF, Up: Debugging Info 40060 4006118.21.6 Macros for VMS Debug Format 40062----------------------------------- 40063 40064Here are macros for VMS debug format. 40065 40066 -- Macro: VMS_DEBUGGING_INFO 40067 Define this macro if GCC should produce debugging output for VMS in 40068 response to the '-g' option. The default behavior for VMS is to 40069 generate minimal debug info for a traceback in the absence of '-g' 40070 unless explicitly overridden with '-g0'. This behavior is 40071 controlled by 'TARGET_OPTION_OPTIMIZATION' and 40072 'TARGET_OPTION_OVERRIDE'. 40073 40074 40075File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros 40076 4007718.22 Cross Compilation and Floating Point 40078========================================== 40079 40080While all modern machines use twos-complement representation for 40081integers, there are a variety of representations for floating point 40082numbers. This means that in a cross-compiler the representation of 40083floating point numbers in the compiled program may be different from 40084that used in the machine doing the compilation. 40085 40086 Because different representation systems may offer different amounts of 40087range and precision, all floating point constants must be represented in 40088the target machine's format. Therefore, the cross compiler cannot 40089safely use the host machine's floating point arithmetic; it must emulate 40090the target's arithmetic. To ensure consistency, GCC always uses 40091emulation to work with floating point values, even when the host and 40092target floating point formats are identical. 40093 40094 The following macros are provided by 'real.h' for the compiler to use. 40095All parts of the compiler which generate or optimize floating-point 40096calculations must use these macros. They may evaluate their operands 40097more than once, so operands must not have side effects. 40098 40099 -- Macro: REAL_VALUE_TYPE 40100 The C data type to be used to hold a floating point value in the 40101 target machine's format. Typically this is a 'struct' containing 40102 an array of 'HOST_WIDE_INT', but all code should treat it as an 40103 opaque quantity. 40104 40105 -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X) 40106 Truncates X to a signed integer, rounding toward zero. 40107 40108 -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX 40109 (REAL_VALUE_TYPE X) 40110 Truncates X to an unsigned integer, rounding toward zero. If X is 40111 negative, returns zero. 40112 40113 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, 40114 machine_mode MODE) 40115 Converts STRING into a floating point number in the target 40116 machine's representation for mode MODE. This routine can handle 40117 both decimal and hexadecimal floating point constants, using the 40118 syntax defined by the C language for both. 40119 40120 -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X) 40121 Returns 1 if X is negative (including negative zero), 0 otherwise. 40122 40123 -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X) 40124 Determines whether X represents infinity (positive or negative). 40125 40126 -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X) 40127 Determines whether X represents a "NaN" (not-a-number). 40128 40129 -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X) 40130 Returns the negative of the floating point value X. 40131 40132 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X) 40133 Returns the absolute value of X. 40134 40135 40136File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros 40137 4013818.23 Mode Switching Instructions 40139================================= 40140 40141The following macros control mode switching optimizations: 40142 40143 -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY) 40144 Define this macro if the port needs extra instructions inserted for 40145 mode switching in an optimizing compilation. 40146 40147 For an example, the SH4 can perform both single and double 40148 precision floating point operations, but to perform a single 40149 precision operation, the FPSCR PR bit has to be cleared, while for 40150 a double precision operation, this bit has to be set. Changing the 40151 PR bit requires a general purpose register as a scratch register, 40152 hence these FPSCR sets have to be inserted before reload, i.e. you 40153 cannot put this into instruction emitting or 40154 'TARGET_MACHINE_DEPENDENT_REORG'. 40155 40156 You can have multiple entities that are mode-switched, and select 40157 at run time which entities actually need it. 40158 'OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY that 40159 needs mode-switching. If you define this macro, you also have to 40160 define 'NUM_MODES_FOR_MODE_SWITCHING', 'TARGET_MODE_NEEDED', 40161 'TARGET_MODE_PRIORITY' and 'TARGET_MODE_EMIT'. 40162 'TARGET_MODE_AFTER', 'TARGET_MODE_ENTRY', and 'TARGET_MODE_EXIT' 40163 are optional. 40164 40165 -- Macro: NUM_MODES_FOR_MODE_SWITCHING 40166 If you define 'OPTIMIZE_MODE_SWITCHING', you have to define this as 40167 initializer for an array of integers. Each initializer element N 40168 refers to an entity that needs mode switching, and specifies the 40169 number of different modes that might need to be set for this 40170 entity. The position of the initializer in the 40171 initializer--starting counting at zero--determines the integer that 40172 is used to refer to the mode-switched entity in question. In 40173 macros that take mode arguments / yield a mode result, modes are 40174 represented as numbers 0 ... N - 1. N is used to specify that no 40175 mode switch is needed / supplied. 40176 40177 -- Target Hook: void TARGET_MODE_EMIT (int ENTITY, int MODE, int 40178 PREV_MODE, HARD_REG_SET REGS_LIVE) 40179 Generate one or more insns to set ENTITY to MODE. HARD_REG_LIVE is 40180 the set of hard registers live at the point where the insn(s) are 40181 to be inserted. PREV_MOXDE indicates the mode to switch from. 40182 Sets of a lower numbered entity will be emitted before sets of a 40183 higher numbered entity to a mode of the same or lower priority. 40184 40185 -- Target Hook: int TARGET_MODE_NEEDED (int ENTITY, rtx_insn *INSN) 40186 ENTITY is an integer specifying a mode-switched entity. If 40187 'OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to 40188 return an integer value not larger than the corresponding element 40189 in 'NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY 40190 must be switched into prior to the execution of INSN. 40191 40192 -- Target Hook: int TARGET_MODE_AFTER (int ENTITY, int MODE, rtx_insn 40193 *INSN) 40194 ENTITY is an integer specifying a mode-switched entity. If this 40195 macro is defined, it is evaluated for every INSN during mode 40196 switching. It determines the mode that an insn results in (if 40197 different from the incoming mode). 40198 40199 -- Target Hook: int TARGET_MODE_ENTRY (int ENTITY) 40200 If this macro is defined, it is evaluated for every ENTITY that 40201 needs mode switching. It should evaluate to an integer, which is a 40202 mode that ENTITY is assumed to be switched to at function entry. 40203 If 'TARGET_MODE_ENTRY' is defined then 'TARGET_MODE_EXIT' must be 40204 defined. 40205 40206 -- Target Hook: int TARGET_MODE_EXIT (int ENTITY) 40207 If this macro is defined, it is evaluated for every ENTITY that 40208 needs mode switching. It should evaluate to an integer, which is a 40209 mode that ENTITY is assumed to be switched to at function exit. If 40210 'TARGET_MODE_EXIT' is defined then 'TARGET_MODE_ENTRY' must be 40211 defined. 40212 40213 -- Target Hook: int TARGET_MODE_PRIORITY (int ENTITY, int N) 40214 This macro specifies the order in which modes for ENTITY are 40215 processed. 0 is the highest priority, 40216 'NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest. The value 40217 of the macro should be an integer designating a mode for ENTITY. 40218 For any fixed ENTITY, 'mode_priority' (ENTITY, N) shall be a 40219 bijection in 0 ... 'num_modes_for_mode_switching[ENTITY] - 1'. 40220 40221 40222File: gccint.info, Node: Target Attributes, Next: Emulated TLS, Prev: Mode Switching, Up: Target Macros 40223 4022418.24 Defining target-specific uses of '__attribute__' 40225====================================================== 40226 40227Target-specific attributes may be defined for functions, data and types. 40228These are described using the following target hooks; they also need to 40229be documented in 'extend.texi'. 40230 40231 -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE 40232 If defined, this target hook points to an array of 'struct 40233 attribute_spec' (defined in 'tree-core.h') specifying the machine 40234 specific attributes for this target and some of the restrictions on 40235 the entities to which these attributes are applied and the 40236 arguments they take. 40237 40238 -- Target Hook: bool TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P (const_tree 40239 NAME) 40240 If defined, this target hook is a function which returns true if 40241 the machine-specific attribute named NAME expects an identifier 40242 given as its first argument to be passed on as a plain identifier, 40243 not subjected to name lookup. If this is not defined, the default 40244 is false for all machine-specific attributes. 40245 40246 -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (const_tree TYPE1, 40247 const_tree TYPE2) 40248 If defined, this target hook is a function which returns zero if 40249 the attributes on TYPE1 and TYPE2 are incompatible, one if they are 40250 compatible, and two if they are nearly compatible (which causes a 40251 warning to be generated). If this is not defined, machine-specific 40252 attributes are supposed always to be compatible. 40253 40254 -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE) 40255 If defined, this target hook is a function which assigns default 40256 attributes to the newly defined TYPE. 40257 40258 -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree 40259 TYPE2) 40260 Define this target hook if the merging of type attributes needs 40261 special handling. If defined, the result is a list of the combined 40262 'TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that 40263 'comptypes' has already been called and returned 1. This function 40264 may call 'merge_attributes' to handle machine-independent merging. 40265 40266 -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree 40267 NEWDECL) 40268 Define this target hook if the merging of decl attributes needs 40269 special handling. If defined, the result is a list of the combined 40270 'DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate 40271 declaration of OLDDECL. Examples of when this is needed are when 40272 one attribute overrides another, or when an attribute is nullified 40273 by a subsequent definition. This function may call 40274 'merge_attributes' to handle machine-independent merging. 40275 40276 If the only target-specific handling you require is 'dllimport' for 40277 Microsoft Windows targets, you should define the macro 40278 'TARGET_DLLIMPORT_DECL_ATTRIBUTES' to '1'. The compiler will then 40279 define a function called 'merge_dllimport_decl_attributes' which 40280 can then be defined as the expansion of 40281 'TARGET_MERGE_DECL_ATTRIBUTES'. You can also add 40282 'handle_dll_attribute' in the attribute table for your port to 40283 perform initial processing of the 'dllimport' and 'dllexport' 40284 attributes. This is done in 'i386/cygwin.h' and 'i386/i386.c', for 40285 example. 40286 40287 -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (const_tree 40288 DECL) 40289 DECL is a variable or function with '__attribute__((dllimport))' 40290 specified. Use this hook if the target needs to add extra 40291 validation checks to 'handle_dll_attribute'. 40292 40293 -- Macro: TARGET_DECLSPEC 40294 Define this macro to a nonzero value if you want to treat 40295 '__declspec(X)' as equivalent to '__attribute((X))'. By default, 40296 this behavior is enabled only for targets that define 40297 'TARGET_DLLIMPORT_DECL_ATTRIBUTES'. The current implementation of 40298 '__declspec' is via a built-in macro, but you should not rely on 40299 this implementation detail. 40300 40301 -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree 40302 *ATTR_PTR) 40303 Define this target hook if you want to be able to add attributes to 40304 a decl when it is being created. This is normally useful for back 40305 ends which wish to implement a pragma by using the attributes which 40306 correspond to the pragma's effect. The NODE argument is the decl 40307 which is being created. The ATTR_PTR argument is a pointer to the 40308 attribute list for this decl. The list itself should not be 40309 modified, since it may be shared with other decls, but attributes 40310 may be chained on the head of the list and '*ATTR_PTR' modified to 40311 point to the new attributes, or a copy of the list may be made if 40312 further changes are needed. 40313 40314 -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (const_tree 40315 FNDECL) 40316 This target hook returns 'true' if it is OK to inline FNDECL into 40317 the current function, despite its having target-specific 40318 attributes, 'false' otherwise. By default, if a function has a 40319 target specific attribute attached to it, it will not be inlined. 40320 40321 -- Target Hook: bool TARGET_OPTION_VALID_ATTRIBUTE_P (tree FNDECL, tree 40322 NAME, tree ARGS, int FLAGS) 40323 This hook is called to parse 'attribute(target("..."))', which 40324 allows setting target-specific options on individual functions. 40325 These function-specific options may differ from the options 40326 specified on the command line. The hook should return 'true' if 40327 the options are valid. 40328 40329 The hook should set the 'DECL_FUNCTION_SPECIFIC_TARGET' field in 40330 the function declaration to hold a pointer to a target-specific 40331 'struct cl_target_option' structure. 40332 40333 -- Target Hook: void TARGET_OPTION_SAVE (struct cl_target_option *PTR, 40334 struct gcc_options *OPTS) 40335 This hook is called to save any additional target-specific 40336 information in the 'struct cl_target_option' structure for 40337 function-specific options from the 'struct gcc_options' structure. 40338 *Note Option file format::. 40339 40340 -- Target Hook: void TARGET_OPTION_RESTORE (struct gcc_options *OPTS, 40341 struct cl_target_option *PTR) 40342 This hook is called to restore any additional target-specific 40343 information in the 'struct cl_target_option' structure for 40344 function-specific options to the 'struct gcc_options' structure. 40345 40346 -- Target Hook: void TARGET_OPTION_POST_STREAM_IN (struct 40347 cl_target_option *PTR) 40348 This hook is called to update target-specific information in the 40349 'struct cl_target_option' structure after it is streamed in from 40350 LTO bytecode. 40351 40352 -- Target Hook: void TARGET_OPTION_PRINT (FILE *FILE, int INDENT, 40353 struct cl_target_option *PTR) 40354 This hook is called to print any additional target-specific 40355 information in the 'struct cl_target_option' structure for 40356 function-specific options. 40357 40358 -- Target Hook: bool TARGET_OPTION_PRAGMA_PARSE (tree ARGS, tree 40359 POP_TARGET) 40360 This target hook parses the options for '#pragma GCC target', which 40361 sets the target-specific options for functions that occur later in 40362 the input stream. The options accepted should be the same as those 40363 handled by the 'TARGET_OPTION_VALID_ATTRIBUTE_P' hook. 40364 40365 -- Target Hook: void TARGET_OPTION_OVERRIDE (void) 40366 Sometimes certain combinations of command options do not make sense 40367 on a particular target machine. You can override the hook 40368 'TARGET_OPTION_OVERRIDE' to take account of this. This hooks is 40369 called once just after all the command options have been parsed. 40370 40371 Don't use this hook to turn on various extra optimizations for 40372 '-O'. That is what 'TARGET_OPTION_OPTIMIZATION' is for. 40373 40374 If you need to do something whenever the optimization level is 40375 changed via the optimize attribute or pragma, see 40376 'TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE' 40377 40378 -- Target Hook: bool TARGET_OPTION_FUNCTION_VERSIONS (tree DECL1, tree 40379 DECL2) 40380 This target hook returns 'true' if DECL1 and DECL2 are versions of 40381 the same function. DECL1 and DECL2 are function versions if and 40382 only if they have the same function signature and different target 40383 specific attributes, that is, they are compiled for different 40384 target machines. 40385 40386 -- Target Hook: bool TARGET_CAN_INLINE_P (tree CALLER, tree CALLEE) 40387 This target hook returns 'false' if the CALLER function cannot 40388 inline CALLEE, based on target specific information. By default, 40389 inlining is not allowed if the callee function has function 40390 specific target options and the caller does not use the same 40391 options. 40392 40393 -- Target Hook: void TARGET_RELAYOUT_FUNCTION (tree FNDECL) 40394 This target hook fixes function FNDECL after attributes are 40395 processed. Default does nothing. On ARM, the default function's 40396 alignment is updated with the attribute target. 40397 40398 40399File: gccint.info, Node: Emulated TLS, Next: MIPS Coprocessors, Prev: Target Attributes, Up: Target Macros 40400 4040118.25 Emulating TLS 40402=================== 40403 40404For targets whose psABI does not provide Thread Local Storage via 40405specific relocations and instruction sequences, an emulation layer is 40406used. A set of target hooks allows this emulation layer to be 40407configured for the requirements of a particular target. For instance 40408the psABI may in fact specify TLS support in terms of an emulation 40409layer. 40410 40411 The emulation layer works by creating a control object for every TLS 40412object. To access the TLS object, a lookup function is provided which, 40413when given the address of the control object, will return the address of 40414the current thread's instance of the TLS object. 40415 40416 -- Target Hook: const char * TARGET_EMUTLS_GET_ADDRESS 40417 Contains the name of the helper function that uses a TLS control 40418 object to locate a TLS instance. The default causes libgcc's 40419 emulated TLS helper function to be used. 40420 40421 -- Target Hook: const char * TARGET_EMUTLS_REGISTER_COMMON 40422 Contains the name of the helper function that should be used at 40423 program startup to register TLS objects that are implicitly 40424 initialized to zero. If this is 'NULL', all TLS objects will have 40425 explicit initializers. The default causes libgcc's emulated TLS 40426 registration function to be used. 40427 40428 -- Target Hook: const char * TARGET_EMUTLS_VAR_SECTION 40429 Contains the name of the section in which TLS control variables 40430 should be placed. The default of 'NULL' allows these to be placed 40431 in any section. 40432 40433 -- Target Hook: const char * TARGET_EMUTLS_TMPL_SECTION 40434 Contains the name of the section in which TLS initializers should 40435 be placed. The default of 'NULL' allows these to be placed in any 40436 section. 40437 40438 -- Target Hook: const char * TARGET_EMUTLS_VAR_PREFIX 40439 Contains the prefix to be prepended to TLS control variable names. 40440 The default of 'NULL' uses a target-specific prefix. 40441 40442 -- Target Hook: const char * TARGET_EMUTLS_TMPL_PREFIX 40443 Contains the prefix to be prepended to TLS initializer objects. 40444 The default of 'NULL' uses a target-specific prefix. 40445 40446 -- Target Hook: tree TARGET_EMUTLS_VAR_FIELDS (tree TYPE, tree *NAME) 40447 Specifies a function that generates the FIELD_DECLs for a TLS 40448 control object type. TYPE is the RECORD_TYPE the fields are for 40449 and NAME should be filled with the structure tag, if the default of 40450 '__emutls_object' is unsuitable. The default creates a type 40451 suitable for libgcc's emulated TLS function. 40452 40453 -- Target Hook: tree TARGET_EMUTLS_VAR_INIT (tree VAR, tree DECL, tree 40454 TMPL_ADDR) 40455 Specifies a function that generates the CONSTRUCTOR to initialize a 40456 TLS control object. VAR is the TLS control object, DECL is the TLS 40457 object and TMPL_ADDR is the address of the initializer. The 40458 default initializes libgcc's emulated TLS control object. 40459 40460 -- Target Hook: bool TARGET_EMUTLS_VAR_ALIGN_FIXED 40461 Specifies whether the alignment of TLS control variable objects is 40462 fixed and should not be increased as some backends may do to 40463 optimize single objects. The default is false. 40464 40465 -- Target Hook: bool TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS 40466 Specifies whether a DWARF 'DW_OP_form_tls_address' location 40467 descriptor may be used to describe emulated TLS control objects. 40468 40469 40470File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Emulated TLS, Up: Target Macros 40471 4047218.26 Defining coprocessor specifics for MIPS targets. 40473====================================================== 40474 40475The MIPS specification allows MIPS implementations to have as many as 4 40476coprocessors, each with as many as 32 private registers. GCC supports 40477accessing these registers and transferring values between the registers 40478and memory using asm-ized variables. For example: 40479 40480 register unsigned int cp0count asm ("c0r1"); 40481 unsigned int d; 40482 40483 d = cp0count + 3; 40484 40485 ("c0r1" is the default name of register 1 in coprocessor 0; alternate 40486names may be added as described below, or the default names may be 40487overridden entirely in 'SUBTARGET_CONDITIONAL_REGISTER_USAGE'.) 40488 40489 Coprocessor registers are assumed to be epilogue-used; sets to them 40490will be preserved even if it does not appear that the register is used 40491again later in the function. 40492 40493 Another note: according to the MIPS spec, coprocessor 1 (if present) is 40494the FPU. One accesses COP1 registers through standard mips 40495floating-point support; they are not included in this mechanism. 40496 40497 40498File: gccint.info, Node: PCH Target, Next: C++ ABI, Prev: MIPS Coprocessors, Up: Target Macros 40499 4050018.27 Parameters for Precompiled Header Validity Checking 40501========================================================= 40502 40503 -- Target Hook: void * TARGET_GET_PCH_VALIDITY (size_t *SZ) 40504 This hook returns a pointer to the data needed by 40505 'TARGET_PCH_VALID_P' and sets '*SZ' to the size of the data in 40506 bytes. 40507 40508 -- Target Hook: const char * TARGET_PCH_VALID_P (const void *DATA, 40509 size_t SZ) 40510 This hook checks whether the options used to create a PCH file are 40511 compatible with the current settings. It returns 'NULL' if so and 40512 a suitable error message if not. Error messages will be presented 40513 to the user and must be localized using '_(MSG)'. 40514 40515 DATA is the data that was returned by 'TARGET_GET_PCH_VALIDITY' 40516 when the PCH file was created and SZ is the size of that data in 40517 bytes. It's safe to assume that the data was created by the same 40518 version of the compiler, so no format checking is needed. 40519 40520 The default definition of 'default_pch_valid_p' should be suitable 40521 for most targets. 40522 40523 -- Target Hook: const char * TARGET_CHECK_PCH_TARGET_FLAGS (int 40524 PCH_FLAGS) 40525 If this hook is nonnull, the default implementation of 40526 'TARGET_PCH_VALID_P' will use it to check for compatible values of 40527 'target_flags'. PCH_FLAGS specifies the value that 'target_flags' 40528 had when the PCH file was created. The return value is the same as 40529 for 'TARGET_PCH_VALID_P'. 40530 40531 -- Target Hook: void TARGET_PREPARE_PCH_SAVE (void) 40532 Called before writing out a PCH file. If the target has some 40533 garbage-collected data that needs to be in a particular state on 40534 PCH loads, it can use this hook to enforce that state. Very few 40535 targets need to do anything here. 40536 40537 40538File: gccint.info, Node: C++ ABI, Next: D Language and ABI, Prev: PCH Target, Up: Target Macros 40539 4054018.28 C++ ABI parameters 40541======================== 40542 40543 -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void) 40544 Define this hook to override the integer type used for guard 40545 variables. These are used to implement one-time construction of 40546 static objects. The default is long_long_integer_type_node. 40547 40548 -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void) 40549 This hook determines how guard variables are used. It should 40550 return 'false' (the default) if the first byte should be used. A 40551 return value of 'true' indicates that only the least significant 40552 bit should be used. 40553 40554 -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE) 40555 This hook returns the size of the cookie to use when allocating an 40556 array whose elements have the indicated TYPE. Assumes that it is 40557 already known that a cookie is needed. The default is 'max(sizeof 40558 (size_t), alignof(type))', as defined in section 2.7 of the 40559 IA64/Generic C++ ABI. 40560 40561 -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void) 40562 This hook should return 'true' if the element size should be stored 40563 in array cookies. The default is to return 'false'. 40564 40565 -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int 40566 IMPORT_EXPORT) 40567 If defined by a backend this hook allows the decision made to 40568 export class TYPE to be overruled. Upon entry IMPORT_EXPORT will 40569 contain 1 if the class is going to be exported, -1 if it is going 40570 to be imported and 0 otherwise. This function should return the 40571 modified value and perform any other actions necessary to support 40572 the backend's targeted operating system. 40573 40574 -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void) 40575 This hook should return 'true' if constructors and destructors 40576 return the address of the object created/destroyed. The default is 40577 to return 'false'. 40578 40579 -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void) 40580 This hook returns true if the key method for a class (i.e., the 40581 method which, if defined in the current translation unit, causes 40582 the virtual table to be emitted) may be an inline function. Under 40583 the standard Itanium C++ ABI the key method may be an inline 40584 function so long as the function is not declared inline in the 40585 class definition. Under some variants of the ABI, an inline 40586 function can never be the key method. The default is to return 40587 'true'. 40588 40589 -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree 40590 DECL) 40591 DECL is a virtual table, virtual table table, typeinfo object, or 40592 other similar implicit class data object that will be emitted with 40593 external linkage in this translation unit. No ELF visibility has 40594 been explicitly specified. If the target needs to specify a 40595 visibility other than that of the containing class, use this hook 40596 to set 'DECL_VISIBILITY' and 'DECL_VISIBILITY_SPECIFIED'. 40597 40598 -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void) 40599 This hook returns true (the default) if virtual tables and other 40600 similar implicit class data objects are always COMDAT if they have 40601 external linkage. If this hook returns false, then class data for 40602 classes whose virtual table will be emitted in only one translation 40603 unit will not be COMDAT. 40604 40605 -- Target Hook: bool TARGET_CXX_LIBRARY_RTTI_COMDAT (void) 40606 This hook returns true (the default) if the RTTI information for 40607 the basic types which is defined in the C++ runtime should always 40608 be COMDAT, false if it should not be COMDAT. 40609 40610 -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void) 40611 This hook returns true if '__aeabi_atexit' (as defined by the ARM 40612 EABI) should be used to register static destructors when 40613 '-fuse-cxa-atexit' is in effect. The default is to return false to 40614 use '__cxa_atexit'. 40615 40616 -- Target Hook: bool TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT (void) 40617 This hook returns true if the target 'atexit' function can be used 40618 in the same manner as '__cxa_atexit' to register C++ static 40619 destructors. This requires that 'atexit'-registered functions in 40620 shared libraries are run in the correct order when the libraries 40621 are unloaded. The default is to return false. 40622 40623 -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE) 40624 TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has just 40625 been defined. Use this hook to make adjustments to the class (eg, 40626 tweak visibility or perform any other required target 40627 modifications). 40628 40629 -- Target Hook: tree TARGET_CXX_DECL_MANGLING_CONTEXT (const_tree DECL) 40630 Return target-specific mangling context of DECL or 'NULL_TREE'. 40631 40632 40633File: gccint.info, Node: D Language and ABI, Next: Named Address Spaces, Prev: C++ ABI, Up: Target Macros 40634 4063518.29 D ABI parameters 40636====================== 40637 40638 -- D Target Hook: void TARGET_D_CPU_VERSIONS (void) 40639 Declare all environmental version identifiers relating to the 40640 target CPU using the function 'builtin_version', which takes a 40641 string representing the name of the version. Version identifiers 40642 predefined by this hook apply to all modules that are being 40643 compiled and imported. 40644 40645 -- D Target Hook: void TARGET_D_OS_VERSIONS (void) 40646 Similarly to 'TARGET_D_CPU_VERSIONS', but is used for versions 40647 relating to the target operating system. 40648 40649 -- D Target Hook: unsigned TARGET_D_CRITSEC_SIZE (void) 40650 Returns the size of the data structure used by the target operating 40651 system for critical sections and monitors. For example, on 40652 Microsoft Windows this would return the 'sizeof(CRITICAL_SECTION)', 40653 while other platforms that implement pthreads would return 40654 'sizeof(pthread_mutex_t)'. 40655 40656 40657File: gccint.info, Node: Named Address Spaces, Next: Misc, Prev: D Language and ABI, Up: Target Macros 40658 4065918.30 Adding support for named address spaces 40660============================================= 40661 40662The draft technical report of the ISO/IEC JTC1 S22 WG14 N1275 standards 40663committee, 'Programming Languages - C - Extensions to support embedded 40664processors', specifies a syntax for embedded processors to specify 40665alternate address spaces. You can configure a GCC port to support 40666section 5.1 of the draft report to add support for address spaces other 40667than the default address space. These address spaces are new keywords 40668that are similar to the 'volatile' and 'const' type attributes. 40669 40670 Pointers to named address spaces can have a different size than 40671pointers to the generic address space. 40672 40673 For example, the SPU port uses the '__ea' address space to refer to 40674memory in the host processor, rather than memory local to the SPU 40675processor. Access to memory in the '__ea' address space involves 40676issuing DMA operations to move data between the host processor and the 40677local processor memory address space. Pointers in the '__ea' address 40678space are either 32 bits or 64 bits based on the '-mea32' or '-mea64' 40679switches (native SPU pointers are always 32 bits). 40680 40681 Internally, address spaces are represented as a small integer in the 40682range 0 to 15 with address space 0 being reserved for the generic 40683address space. 40684 40685 To register a named address space qualifier keyword with the C front 40686end, the target may call the 'c_register_addr_space' routine. For 40687example, the SPU port uses the following to declare '__ea' as the 40688keyword for named address space #1: 40689 #define ADDR_SPACE_EA 1 40690 c_register_addr_space ("__ea", ADDR_SPACE_EA); 40691 40692 -- Target Hook: scalar_int_mode TARGET_ADDR_SPACE_POINTER_MODE 40693 (addr_space_t ADDRESS_SPACE) 40694 Define this to return the machine mode to use for pointers to 40695 ADDRESS_SPACE if the target supports named address spaces. The 40696 default version of this hook returns 'ptr_mode'. 40697 40698 -- Target Hook: scalar_int_mode TARGET_ADDR_SPACE_ADDRESS_MODE 40699 (addr_space_t ADDRESS_SPACE) 40700 Define this to return the machine mode to use for addresses in 40701 ADDRESS_SPACE if the target supports named address spaces. The 40702 default version of this hook returns 'Pmode'. 40703 40704 -- Target Hook: bool TARGET_ADDR_SPACE_VALID_POINTER_MODE 40705 (scalar_int_mode MODE, addr_space_t AS) 40706 Define this to return nonzero if the port can handle pointers with 40707 machine mode MODE to address space AS. This target hook is the 40708 same as the 'TARGET_VALID_POINTER_MODE' target hook, except that it 40709 includes explicit named address space support. The default version 40710 of this hook returns true for the modes returned by either the 40711 'TARGET_ADDR_SPACE_POINTER_MODE' or 40712 'TARGET_ADDR_SPACE_ADDRESS_MODE' target hooks for the given address 40713 space. 40714 40715 -- Target Hook: bool TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P 40716 (machine_mode MODE, rtx EXP, bool STRICT, addr_space_t AS) 40717 Define this to return true if EXP is a valid address for mode MODE 40718 in the named address space AS. The STRICT parameter says whether 40719 strict addressing is in effect after reload has finished. This 40720 target hook is the same as the 'TARGET_LEGITIMATE_ADDRESS_P' target 40721 hook, except that it includes explicit named address space support. 40722 40723 -- Target Hook: rtx TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS (rtx X, rtx 40724 OLDX, machine_mode MODE, addr_space_t AS) 40725 Define this to modify an invalid address X to be a valid address 40726 with mode MODE in the named address space AS. This target hook is 40727 the same as the 'TARGET_LEGITIMIZE_ADDRESS' target hook, except 40728 that it includes explicit named address space support. 40729 40730 -- Target Hook: bool TARGET_ADDR_SPACE_SUBSET_P (addr_space_t SUBSET, 40731 addr_space_t SUPERSET) 40732 Define this to return whether the SUBSET named address space is 40733 contained within the SUPERSET named address space. Pointers to a 40734 named address space that is a subset of another named address space 40735 will be converted automatically without a cast if used together in 40736 arithmetic operations. Pointers to a superset address space can be 40737 converted to pointers to a subset address space via explicit casts. 40738 40739 -- Target Hook: bool TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID (addr_space_t 40740 AS) 40741 Define this to modify the default handling of address 0 for the 40742 address space. Return true if 0 should be considered a valid 40743 address. 40744 40745 -- Target Hook: rtx TARGET_ADDR_SPACE_CONVERT (rtx OP, tree FROM_TYPE, 40746 tree TO_TYPE) 40747 Define this to convert the pointer expression represented by the 40748 RTL OP with type FROM_TYPE that points to a named address space to 40749 a new pointer expression with type TO_TYPE that points to a 40750 different named address space. When this hook it called, it is 40751 guaranteed that one of the two address spaces is a subset of the 40752 other, as determined by the 'TARGET_ADDR_SPACE_SUBSET_P' target 40753 hook. 40754 40755 -- Target Hook: int TARGET_ADDR_SPACE_DEBUG (addr_space_t AS) 40756 Define this to define how the address space is encoded in dwarf. 40757 The result is the value to be used with 'DW_AT_address_class'. 40758 40759 -- Target Hook: void TARGET_ADDR_SPACE_DIAGNOSE_USAGE (addr_space_t AS, 40760 location_t LOC) 40761 Define this hook if the availability of an address space depends on 40762 command line options and some diagnostics should be printed when 40763 the address space is used. This hook is called during parsing and 40764 allows to emit a better diagnostic compared to the case where the 40765 address space was not registered with 'c_register_addr_space'. AS 40766 is the address space as registered with 'c_register_addr_space'. 40767 LOC is the location of the address space qualifier token. The 40768 default implementation does nothing. 40769 40770 40771File: gccint.info, Node: Misc, Prev: Named Address Spaces, Up: Target Macros 40772 4077318.31 Miscellaneous Parameters 40774============================== 40775 40776Here are several miscellaneous parameters. 40777 40778 -- Macro: HAS_LONG_COND_BRANCH 40779 Define this boolean macro to indicate whether or not your 40780 architecture has conditional branches that can span all of memory. 40781 It is used in conjunction with an optimization that partitions hot 40782 and cold basic blocks into separate sections of the executable. If 40783 this macro is set to false, gcc will convert any conditional 40784 branches that attempt to cross between sections into unconditional 40785 branches or indirect jumps. 40786 40787 -- Macro: HAS_LONG_UNCOND_BRANCH 40788 Define this boolean macro to indicate whether or not your 40789 architecture has unconditional branches that can span all of 40790 memory. It is used in conjunction with an optimization that 40791 partitions hot and cold basic blocks into separate sections of the 40792 executable. If this macro is set to false, gcc will convert any 40793 unconditional branches that attempt to cross between sections into 40794 indirect jumps. 40795 40796 -- Macro: CASE_VECTOR_MODE 40797 An alias for a machine mode name. This is the machine mode that 40798 elements of a jump-table should have. 40799 40800 -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY) 40801 Optional: return the preferred mode for an 'addr_diff_vec' when the 40802 minimum and maximum offset are known. If you define this, it 40803 enables extra code in branch shortening to deal with 40804 'addr_diff_vec'. To make this work, you also have to define 40805 'INSN_ALIGN' and make the alignment for 'addr_diff_vec' explicit. 40806 The BODY argument is provided so that the offset_unsigned and scale 40807 flags can be updated. 40808 40809 -- Macro: CASE_VECTOR_PC_RELATIVE 40810 Define this macro to be a C expression to indicate when jump-tables 40811 should contain relative addresses. You need not define this macro 40812 if jump-tables never contain relative addresses, or jump-tables 40813 should contain relative addresses only when '-fPIC' or '-fPIC' is 40814 in effect. 40815 40816 -- Target Hook: unsigned int TARGET_CASE_VALUES_THRESHOLD (void) 40817 This function return the smallest number of different values for 40818 which it is best to use a jump-table instead of a tree of 40819 conditional branches. The default is four for machines with a 40820 'casesi' instruction and five otherwise. This is best for most 40821 machines. 40822 40823 -- Macro: WORD_REGISTER_OPERATIONS 40824 Define this macro to 1 if operations between registers with 40825 integral mode smaller than a word are always performed on the 40826 entire register. To be more explicit, if you start with a pair of 40827 'word_mode' registers with known values and you do a subword, for 40828 example 'QImode', addition on the low part of the registers, then 40829 the compiler may consider that the result has a known value in 40830 'word_mode' too if the macro is defined to 1. Most RISC machines 40831 have this property and most CISC machines do not. 40832 40833 -- Target Hook: unsigned int TARGET_MIN_ARITHMETIC_PRECISION (void) 40834 On some RISC architectures with 64-bit registers, the processor 40835 also maintains 32-bit condition codes that make it possible to do 40836 real 32-bit arithmetic, although the operations are performed on 40837 the full registers. 40838 40839 On such architectures, defining this hook to 32 tells the compiler 40840 to try using 32-bit arithmetical operations setting the condition 40841 codes instead of doing full 64-bit arithmetic. 40842 40843 More generally, define this hook on RISC architectures if you want 40844 the compiler to try using arithmetical operations setting the 40845 condition codes with a precision lower than the word precision. 40846 40847 You need not define this hook if 'WORD_REGISTER_OPERATIONS' is not 40848 defined to 1. 40849 40850 -- Macro: LOAD_EXTEND_OP (MEM_MODE) 40851 Define this macro to be a C expression indicating when insns that 40852 read memory in MEM_MODE, an integral mode narrower than a word, set 40853 the bits outside of MEM_MODE to be either the sign-extension or the 40854 zero-extension of the data read. Return 'SIGN_EXTEND' for values 40855 of MEM_MODE for which the insn sign-extends, 'ZERO_EXTEND' for 40856 which it zero-extends, and 'UNKNOWN' for other modes. 40857 40858 This macro is not called with MEM_MODE non-integral or with a width 40859 greater than or equal to 'BITS_PER_WORD', so you may return any 40860 value in this case. Do not define this macro if it would always 40861 return 'UNKNOWN'. On machines where this macro is defined, you 40862 will normally define it as the constant 'SIGN_EXTEND' or 40863 'ZERO_EXTEND'. 40864 40865 You may return a non-'UNKNOWN' value even if for some hard 40866 registers the sign extension is not performed, if for the 40867 'REGNO_REG_CLASS' of these hard registers 40868 'TARGET_CAN_CHANGE_MODE_CLASS' returns false when the FROM mode is 40869 MEM_MODE and the TO mode is any integral mode larger than this but 40870 not larger than 'word_mode'. 40871 40872 You must return 'UNKNOWN' if for some hard registers that allow 40873 this mode, 'TARGET_CAN_CHANGE_MODE_CLASS' says that they cannot 40874 change to 'word_mode', but that they can change to another integral 40875 mode that is larger then MEM_MODE but still smaller than 40876 'word_mode'. 40877 40878 -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND 40879 Define this macro to 1 if loading short immediate values into 40880 registers sign extends. 40881 40882 -- Target Hook: unsigned int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL 40883 (machine_mode MODE) 40884 When '-ffast-math' is in effect, GCC tries to optimize divisions by 40885 the same divisor, by turning them into multiplications by the 40886 reciprocal. This target hook specifies the minimum number of 40887 divisions that should be there for GCC to perform the optimization 40888 for a variable of mode MODE. The default implementation returns 3 40889 if the machine has an instruction for the division, and 2 if it 40890 does not. 40891 40892 -- Macro: MOVE_MAX 40893 The maximum number of bytes that a single instruction can move 40894 quickly between memory and registers or between two memory 40895 locations. 40896 40897 -- Macro: MAX_MOVE_MAX 40898 The maximum number of bytes that a single instruction can move 40899 quickly between memory and registers or between two memory 40900 locations. If this is undefined, the default is 'MOVE_MAX'. 40901 Otherwise, it is the constant value that is the largest value that 40902 'MOVE_MAX' can have at run-time. 40903 40904 -- Macro: SHIFT_COUNT_TRUNCATED 40905 A C expression that is nonzero if on this machine the number of 40906 bits actually used for the count of a shift operation is equal to 40907 the number of bits needed to represent the size of the object being 40908 shifted. When this macro is nonzero, the compiler will assume that 40909 it is safe to omit a sign-extend, zero-extend, and certain bitwise 40910 'and' instructions that truncates the count of a shift operation. 40911 On machines that have instructions that act on bit-fields at 40912 variable positions, which may include 'bit test' instructions, a 40913 nonzero 'SHIFT_COUNT_TRUNCATED' also enables deletion of 40914 truncations of the values that serve as arguments to bit-field 40915 instructions. 40916 40917 If both types of instructions truncate the count (for shifts) and 40918 position (for bit-field operations), or if no variable-position 40919 bit-field instructions exist, you should define this macro. 40920 40921 However, on some machines, such as the 80386 and the 680x0, 40922 truncation only applies to shift operations and not the (real or 40923 pretended) bit-field operations. Define 'SHIFT_COUNT_TRUNCATED' to 40924 be zero on such machines. Instead, add patterns to the 'md' file 40925 that include the implied truncation of the shift instructions. 40926 40927 You need not define this macro if it would always have the value of 40928 zero. 40929 40930 -- Target Hook: unsigned HOST_WIDE_INT TARGET_SHIFT_TRUNCATION_MASK 40931 (machine_mode MODE) 40932 This function describes how the standard shift patterns for MODE 40933 deal with shifts by negative amounts or by more than the width of 40934 the mode. *Note shift patterns::. 40935 40936 On many machines, the shift patterns will apply a mask M to the 40937 shift count, meaning that a fixed-width shift of X by Y is 40938 equivalent to an arbitrary-width shift of X by Y & M. If this is 40939 true for mode MODE, the function should return M, otherwise it 40940 should return 0. A return value of 0 indicates that no particular 40941 behavior is guaranteed. 40942 40943 Note that, unlike 'SHIFT_COUNT_TRUNCATED', this function does _not_ 40944 apply to general shift rtxes; it applies only to instructions that 40945 are generated by the named shift patterns. 40946 40947 The default implementation of this function returns 40948 'GET_MODE_BITSIZE (MODE) - 1' if 'SHIFT_COUNT_TRUNCATED' and 0 40949 otherwise. This definition is always safe, but if 40950 'SHIFT_COUNT_TRUNCATED' is false, and some shift patterns 40951 nevertheless truncate the shift count, you may get better code by 40952 overriding it. 40953 40954 -- Target Hook: bool TARGET_TRULY_NOOP_TRUNCATION (poly_uint64 OUTPREC, 40955 poly_uint64 INPREC) 40956 This hook returns true if it is safe to "convert" a value of INPREC 40957 bits to one of OUTPREC bits (where OUTPREC is smaller than INPREC) 40958 by merely operating on it as if it had only OUTPREC bits. The 40959 default returns true unconditionally, which is correct for most 40960 machines. 40961 40962 If 'TARGET_MODES_TIEABLE_P' returns false for a pair of modes, 40963 suboptimal code can result if this hook returns true for the 40964 corresponding mode sizes. Making this hook return false in such 40965 cases may improve things. 40966 40967 -- Target Hook: int TARGET_MODE_REP_EXTENDED (scalar_int_mode MODE, 40968 scalar_int_mode REP_MODE) 40969 The representation of an integral mode can be such that the values 40970 are always extended to a wider integral mode. Return 'SIGN_EXTEND' 40971 if values of MODE are represented in sign-extended form to 40972 REP_MODE. Return 'UNKNOWN' otherwise. (Currently, none of the 40973 targets use zero-extended representation this way so unlike 40974 'LOAD_EXTEND_OP', 'TARGET_MODE_REP_EXTENDED' is expected to return 40975 either 'SIGN_EXTEND' or 'UNKNOWN'. Also no target extends MODE to 40976 REP_MODE so that REP_MODE is not the next widest integral mode and 40977 currently we take advantage of this fact.) 40978 40979 Similarly to 'LOAD_EXTEND_OP' you may return a non-'UNKNOWN' value 40980 even if the extension is not performed on certain hard registers as 40981 long as for the 'REGNO_REG_CLASS' of these hard registers 40982 'TARGET_CAN_CHANGE_MODE_CLASS' returns false. 40983 40984 Note that 'TARGET_MODE_REP_EXTENDED' and 'LOAD_EXTEND_OP' describe 40985 two related properties. If you define 'TARGET_MODE_REP_EXTENDED 40986 (mode, word_mode)' you probably also want to define 'LOAD_EXTEND_OP 40987 (mode)' to return the same type of extension. 40988 40989 In order to enforce the representation of 'mode', 40990 'TARGET_TRULY_NOOP_TRUNCATION' should return false when truncating 40991 to 'mode'. 40992 40993 -- Target Hook: bool TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P (void) 40994 On some targets, it is assumed that the compiler will spill all 40995 pseudos that are live across a call to 'setjmp', while other 40996 targets treat 'setjmp' calls as normal function calls. 40997 40998 This hook returns false if 'setjmp' calls do not preserve all 40999 non-volatile registers so that gcc that must spill all pseudos that 41000 are live across 'setjmp' calls. Define this to return true if the 41001 target does not need to spill all pseudos live across 'setjmp' 41002 calls. The default implementation conservatively assumes all 41003 pseudos must be spilled across 'setjmp' calls. 41004 41005 -- Macro: STORE_FLAG_VALUE 41006 A C expression describing the value returned by a comparison 41007 operator with an integral mode and stored by a store-flag 41008 instruction ('cstoreMODE4') when the condition is true. This 41009 description must apply to _all_ the 'cstoreMODE4' patterns and all 41010 the comparison operators whose results have a 'MODE_INT' mode. 41011 41012 A value of 1 or -1 means that the instruction implementing the 41013 comparison operator returns exactly 1 or -1 when the comparison is 41014 true and 0 when the comparison is false. Otherwise, the value 41015 indicates which bits of the result are guaranteed to be 1 when the 41016 comparison is true. This value is interpreted in the mode of the 41017 comparison operation, which is given by the mode of the first 41018 operand in the 'cstoreMODE4' pattern. Either the low bit or the 41019 sign bit of 'STORE_FLAG_VALUE' be on. Presently, only those bits 41020 are used by the compiler. 41021 41022 If 'STORE_FLAG_VALUE' is neither 1 or -1, the compiler will 41023 generate code that depends only on the specified bits. It can also 41024 replace comparison operators with equivalent operations if they 41025 cause the required bits to be set, even if the remaining bits are 41026 undefined. For example, on a machine whose comparison operators 41027 return an 'SImode' value and where 'STORE_FLAG_VALUE' is defined as 41028 '0x80000000', saying that just the sign bit is relevant, the 41029 expression 41030 41031 (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0)) 41032 41033 can be converted to 41034 41035 (ashift:SI X (const_int N)) 41036 41037 where N is the appropriate shift count to move the bit being tested 41038 into the sign bit. 41039 41040 There is no way to describe a machine that always sets the 41041 low-order bit for a true value, but does not guarantee the value of 41042 any other bits, but we do not know of any machine that has such an 41043 instruction. If you are trying to port GCC to such a machine, 41044 include an instruction to perform a logical-and of the result with 41045 1 in the pattern for the comparison operators and let us know at 41046 <gcc@gcc.gnu.org>. 41047 41048 Often, a machine will have multiple instructions that obtain a 41049 value from a comparison (or the condition codes). Here are rules 41050 to guide the choice of value for 'STORE_FLAG_VALUE', and hence the 41051 instructions to be used: 41052 41053 * Use the shortest sequence that yields a valid definition for 41054 'STORE_FLAG_VALUE'. It is more efficient for the compiler to 41055 "normalize" the value (convert it to, e.g., 1 or 0) than for 41056 the comparison operators to do so because there may be 41057 opportunities to combine the normalization with other 41058 operations. 41059 41060 * For equal-length sequences, use a value of 1 or -1, with -1 41061 being slightly preferred on machines with expensive jumps and 41062 1 preferred on other machines. 41063 41064 * As a second choice, choose a value of '0x80000001' if 41065 instructions exist that set both the sign and low-order bits 41066 but do not define the others. 41067 41068 * Otherwise, use a value of '0x80000000'. 41069 41070 Many machines can produce both the value chosen for 41071 'STORE_FLAG_VALUE' and its negation in the same number of 41072 instructions. On those machines, you should also define a pattern 41073 for those cases, e.g., one matching 41074 41075 (set A (neg:M (ne:M B C))) 41076 41077 Some machines can also perform 'and' or 'plus' operations on 41078 condition code values with less instructions than the corresponding 41079 'cstoreMODE4' insn followed by 'and' or 'plus'. On those machines, 41080 define the appropriate patterns. Use the names 'incscc' and 41081 'decscc', respectively, for the patterns which perform 'plus' or 41082 'minus' operations on condition code values. See 'rs6000.md' for 41083 some examples. The GNU Superoptimizer can be used to find such 41084 instruction sequences on other machines. 41085 41086 If this macro is not defined, the default value, 1, is used. You 41087 need not define 'STORE_FLAG_VALUE' if the machine has no store-flag 41088 instructions, or if the value generated by these instructions is 1. 41089 41090 -- Macro: FLOAT_STORE_FLAG_VALUE (MODE) 41091 A C expression that gives a nonzero 'REAL_VALUE_TYPE' value that is 41092 returned when comparison operators with floating-point results are 41093 true. Define this macro on machines that have comparison 41094 operations that return floating-point values. If there are no such 41095 operations, do not define this macro. 41096 41097 -- Macro: VECTOR_STORE_FLAG_VALUE (MODE) 41098 A C expression that gives a rtx representing the nonzero true 41099 element for vector comparisons. The returned rtx should be valid 41100 for the inner mode of MODE which is guaranteed to be a vector mode. 41101 Define this macro on machines that have vector comparison 41102 operations that return a vector result. If there are no such 41103 operations, do not define this macro. Typically, this macro is 41104 defined as 'const1_rtx' or 'constm1_rtx'. This macro may return 41105 'NULL_RTX' to prevent the compiler optimizing such vector 41106 comparison operations for the given mode. 41107 41108 -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 41109 -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 41110 A C expression that indicates whether the architecture defines a 41111 value for 'clz' or 'ctz' with a zero operand. A result of '0' 41112 indicates the value is undefined. If the value is defined for only 41113 the RTL expression, the macro should evaluate to '1'; if the value 41114 applies also to the corresponding optab entry (which is normally 41115 the case if it expands directly into the corresponding RTL), then 41116 the macro should evaluate to '2'. In the cases where the value is 41117 defined, VALUE should be set to this value. 41118 41119 If this macro is not defined, the value of 'clz' or 'ctz' at zero 41120 is assumed to be undefined. 41121 41122 This macro must be defined if the target's expansion for 'ffs' 41123 relies on a particular value to get correct results. Otherwise it 41124 is not necessary, though it may be used to optimize some corner 41125 cases, and to provide a default expansion for the 'ffs' optab. 41126 41127 Note that regardless of this macro the "definedness" of 'clz' and 41128 'ctz' at zero do _not_ extend to the builtin functions visible to 41129 the user. Thus one may be free to adjust the value at will to 41130 match the target expansion of these operations without fear of 41131 breaking the API. 41132 41133 -- Macro: Pmode 41134 An alias for the machine mode for pointers. On most machines, 41135 define this to be the integer mode corresponding to the width of a 41136 hardware pointer; 'SImode' on 32-bit machine or 'DImode' on 64-bit 41137 machines. On some machines you must define this to be one of the 41138 partial integer modes, such as 'PSImode'. 41139 41140 The width of 'Pmode' must be at least as large as the value of 41141 'POINTER_SIZE'. If it is not equal, you must define the macro 41142 'POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to 41143 'Pmode'. 41144 41145 -- Macro: FUNCTION_MODE 41146 An alias for the machine mode used for memory references to 41147 functions being called, in 'call' RTL expressions. On most CISC 41148 machines, where an instruction can begin at any byte address, this 41149 should be 'QImode'. On most RISC machines, where all instructions 41150 have fixed size and alignment, this should be a mode with the same 41151 size and alignment as the machine instruction words - typically 41152 'SImode' or 'HImode'. 41153 41154 -- Macro: STDC_0_IN_SYSTEM_HEADERS 41155 In normal operation, the preprocessor expands '__STDC__' to the 41156 constant 1, to signify that GCC conforms to ISO Standard C. On 41157 some hosts, like Solaris, the system compiler uses a different 41158 convention, where '__STDC__' is normally 0, but is 1 if the user 41159 specifies strict conformance to the C Standard. 41160 41161 Defining 'STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host 41162 convention when processing system header files, but when processing 41163 user files '__STDC__' will always expand to 1. 41164 41165 -- C Target Hook: const char * TARGET_C_PREINCLUDE (void) 41166 Define this hook to return the name of a header file to be included 41167 at the start of all compilations, as if it had been included with 41168 '#include <FILE>'. If this hook returns 'NULL', or is not defined, 41169 or the header is not found, or if the user specifies 41170 '-ffreestanding' or '-nostdinc', no header is included. 41171 41172 This hook can be used together with a header provided by the system 41173 C library to implement ISO C requirements for certain macros to be 41174 predefined that describe properties of the whole implementation 41175 rather than just the compiler. 41176 41177 -- C Target Hook: bool TARGET_CXX_IMPLICIT_EXTERN_C (const char*) 41178 Define this hook to add target-specific C++ implicit extern C 41179 functions. If this function returns true for the name of a 41180 file-scope function, that function implicitly gets extern "C" 41181 linkage rather than whatever language linkage the declaration would 41182 normally have. An example of such function is WinMain on Win32 41183 targets. 41184 41185 -- Macro: SYSTEM_IMPLICIT_EXTERN_C 41186 Define this macro if the system header files do not support C++. 41187 This macro handles system header files by pretending that system 41188 header files are enclosed in 'extern "C" {...}'. 41189 41190 -- Macro: REGISTER_TARGET_PRAGMAS () 41191 Define this macro if you want to implement any target-specific 41192 pragmas. If defined, it is a C expression which makes a series of 41193 calls to 'c_register_pragma' or 'c_register_pragma_with_expansion' 41194 for each pragma. The macro may also do any setup required for the 41195 pragmas. 41196 41197 The primary reason to define this macro is to provide compatibility 41198 with other compilers for the same target. In general, we 41199 discourage definition of target-specific pragmas for GCC. 41200 41201 If the pragma can be implemented by attributes then you should 41202 consider defining the target hook 'TARGET_INSERT_ATTRIBUTES' as 41203 well. 41204 41205 Preprocessor macros that appear on pragma lines are not expanded. 41206 All '#pragma' directives that do not match any registered pragma 41207 are silently ignored, unless the user specifies 41208 '-Wunknown-pragmas'. 41209 41210 -- Function: void c_register_pragma (const char *SPACE, const char 41211 *NAME, void (*CALLBACK) (struct cpp_reader *)) 41212 -- Function: void c_register_pragma_with_expansion (const char *SPACE, 41213 const char *NAME, void (*CALLBACK) (struct cpp_reader *)) 41214 41215 Each call to 'c_register_pragma' or 41216 'c_register_pragma_with_expansion' establishes one pragma. The 41217 CALLBACK routine will be called when the preprocessor encounters a 41218 pragma of the form 41219 41220 #pragma [SPACE] NAME ... 41221 41222 SPACE is the case-sensitive namespace of the pragma, or 'NULL' to 41223 put the pragma in the global namespace. The callback routine 41224 receives PFILE as its first argument, which can be passed on to 41225 cpplib's functions if necessary. You can lex tokens after the NAME 41226 by calling 'pragma_lex'. Tokens that are not read by the callback 41227 will be silently ignored. The end of the line is indicated by a 41228 token of type 'CPP_EOF'. Macro expansion occurs on the arguments 41229 of pragmas registered with 'c_register_pragma_with_expansion' but 41230 not on the arguments of pragmas registered with 41231 'c_register_pragma'. 41232 41233 Note that the use of 'pragma_lex' is specific to the C and C++ 41234 compilers. It will not work in the Java or Fortran compilers, or 41235 any other language compilers for that matter. Thus if 'pragma_lex' 41236 is going to be called from target-specific code, it must only be 41237 done so when building the C and C++ compilers. This can be done by 41238 defining the variables 'c_target_objs' and 'cxx_target_objs' in the 41239 target entry in the 'config.gcc' file. These variables should name 41240 the target-specific, language-specific object file which contains 41241 the code that uses 'pragma_lex'. Note it will also be necessary to 41242 add a rule to the makefile fragment pointed to by 'tmake_file' that 41243 shows how to build this object file. 41244 41245 -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION 41246 Define this macro if macros should be expanded in the arguments of 41247 '#pragma pack'. 41248 41249 -- Macro: TARGET_DEFAULT_PACK_STRUCT 41250 If your target requires a structure packing default other than 0 41251 (meaning the machine default), define this macro to the necessary 41252 value (in bytes). This must be a value that would also be valid to 41253 use with '#pragma pack()' (that is, a small power of two). 41254 41255 -- Macro: DOLLARS_IN_IDENTIFIERS 41256 Define this macro to control use of the character '$' in identifier 41257 names for the C family of languages. 0 means '$' is not allowed by 41258 default; 1 means it is allowed. 1 is the default; there is no need 41259 to define this macro in that case. 41260 41261 -- Macro: INSN_SETS_ARE_DELAYED (INSN) 41262 Define this macro as a C expression that is nonzero if it is safe 41263 for the delay slot scheduler to place instructions in the delay 41264 slot of INSN, even if they appear to use a resource set or 41265 clobbered in INSN. INSN is always a 'jump_insn' or an 'insn'; GCC 41266 knows that every 'call_insn' has this behavior. On machines where 41267 some 'insn' or 'jump_insn' is really a function call and hence has 41268 this behavior, you should define this macro. 41269 41270 You need not define this macro if it would always return zero. 41271 41272 -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN) 41273 Define this macro as a C expression that is nonzero if it is safe 41274 for the delay slot scheduler to place instructions in the delay 41275 slot of INSN, even if they appear to set or clobber a resource 41276 referenced in INSN. INSN is always a 'jump_insn' or an 'insn'. On 41277 machines where some 'insn' or 'jump_insn' is really a function call 41278 and its operands are registers whose use is actually in the 41279 subroutine it calls, you should define this macro. Doing so allows 41280 the delay slot scheduler to move instructions which copy arguments 41281 into the argument registers into the delay slot of INSN. 41282 41283 You need not define this macro if it would always return zero. 41284 41285 -- Macro: MULTIPLE_SYMBOL_SPACES 41286 Define this macro as a C expression that is nonzero if, in some 41287 cases, global symbols from one translation unit may not be bound to 41288 undefined symbols in another translation unit without user 41289 intervention. For instance, under Microsoft Windows symbols must 41290 be explicitly imported from shared libraries (DLLs). 41291 41292 You need not define this macro if it would always evaluate to zero. 41293 41294 -- Target Hook: rtx_insn * TARGET_MD_ASM_ADJUST (vec<rtx>& OUTPUTS, 41295 vec<rtx>& INPUTS, vec<const char *>& CONSTRAINTS, vec<rtx>& 41296 CLOBBERS, HARD_REG_SET& CLOBBERED_REGS) 41297 This target hook may add "clobbers" to CLOBBERS and CLOBBERED_REGS 41298 for any hard regs the port wishes to automatically clobber for an 41299 asm. The OUTPUTS and INPUTS may be inspected to avoid clobbering a 41300 register that is already used by the asm. 41301 41302 It may modify the OUTPUTS, INPUTS, and CONSTRAINTS as necessary for 41303 other pre-processing. In this case the return value is a sequence 41304 of insns to emit after the asm. 41305 41306 -- Macro: MATH_LIBRARY 41307 Define this macro as a C string constant for the linker argument to 41308 link in the system math library, minus the initial '"-l"', or '""' 41309 if the target does not have a separate math library. 41310 41311 You need only define this macro if the default of '"m"' is wrong. 41312 41313 -- Macro: LIBRARY_PATH_ENV 41314 Define this macro as a C string constant for the environment 41315 variable that specifies where the linker should look for libraries. 41316 41317 You need only define this macro if the default of '"LIBRARY_PATH"' 41318 is wrong. 41319 41320 -- Macro: TARGET_POSIX_IO 41321 Define this macro if the target supports the following POSIX file 41322 functions, access, mkdir and file locking with fcntl / F_SETLKW. 41323 Defining 'TARGET_POSIX_IO' will enable the test coverage code to 41324 use file locking when exiting a program, which avoids race 41325 conditions if the program has forked. It will also create 41326 directories at run-time for cross-profiling. 41327 41328 -- Macro: MAX_CONDITIONAL_EXECUTE 41329 41330 A C expression for the maximum number of instructions to execute 41331 via conditional execution instructions instead of a branch. A 41332 value of 'BRANCH_COST'+1 is the default if the machine does not use 41333 cc0, and 1 if it does use cc0. 41334 41335 -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR) 41336 Used if the target needs to perform machine-dependent modifications 41337 on the conditionals used for turning basic blocks into 41338 conditionally executed code. CE_INFO points to a data structure, 41339 'struct ce_if_block', which contains information about the 41340 currently processed blocks. TRUE_EXPR and FALSE_EXPR are the tests 41341 that are used for converting the then-block and the else-block, 41342 respectively. Set either TRUE_EXPR or FALSE_EXPR to a null pointer 41343 if the tests cannot be converted. 41344 41345 -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR, 41346 FALSE_EXPR) 41347 Like 'IFCVT_MODIFY_TESTS', but used when converting more 41348 complicated if-statements into conditions combined by 'and' and 41349 'or' operations. BB contains the basic block that contains the 41350 test that is currently being processed and about to be turned into 41351 a condition. 41352 41353 -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN) 41354 A C expression to modify the PATTERN of an INSN that is to be 41355 converted to conditional execution format. CE_INFO points to a 41356 data structure, 'struct ce_if_block', which contains information 41357 about the currently processed blocks. 41358 41359 -- Macro: IFCVT_MODIFY_FINAL (CE_INFO) 41360 A C expression to perform any final machine dependent modifications 41361 in converting code to conditional execution. The involved basic 41362 blocks can be found in the 'struct ce_if_block' structure that is 41363 pointed to by CE_INFO. 41364 41365 -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO) 41366 A C expression to cancel any machine dependent modifications in 41367 converting code to conditional execution. The involved basic 41368 blocks can be found in the 'struct ce_if_block' structure that is 41369 pointed to by CE_INFO. 41370 41371 -- Macro: IFCVT_MACHDEP_INIT (CE_INFO) 41372 A C expression to initialize any machine specific data for 41373 if-conversion of the if-block in the 'struct ce_if_block' structure 41374 that is pointed to by CE_INFO. 41375 41376 -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG (void) 41377 If non-null, this hook performs a target-specific pass over the 41378 instruction stream. The compiler will run it at all optimization 41379 levels, just before the point at which it normally does 41380 delayed-branch scheduling. 41381 41382 The exact purpose of the hook varies from target to target. Some 41383 use it to do transformations that are necessary for correctness, 41384 such as laying out in-function constant pools or avoiding hardware 41385 hazards. Others use it as an opportunity to do some 41386 machine-dependent optimizations. 41387 41388 You need not implement the hook if it has nothing to do. The 41389 default definition is null. 41390 41391 -- Target Hook: void TARGET_INIT_BUILTINS (void) 41392 Define this hook if you have any machine-specific built-in 41393 functions that need to be defined. It should be a function that 41394 performs the necessary setup. 41395 41396 Machine specific built-in functions can be useful to expand special 41397 machine instructions that would otherwise not normally be generated 41398 because they have no equivalent in the source language (for 41399 example, SIMD vector instructions or prefetch instructions). 41400 41401 To create a built-in function, call the function 41402 'lang_hooks.builtin_function' which is defined by the language 41403 front end. You can use any type nodes set up by 41404 'build_common_tree_nodes'; only language front ends that use those 41405 two functions will call 'TARGET_INIT_BUILTINS'. 41406 41407 -- Target Hook: tree TARGET_BUILTIN_DECL (unsigned CODE, bool 41408 INITIALIZE_P) 41409 Define this hook if you have any machine-specific built-in 41410 functions that need to be defined. It should be a function that 41411 returns the builtin function declaration for the builtin function 41412 code CODE. If there is no such builtin and it cannot be 41413 initialized at this time if INITIALIZE_P is true the function 41414 should return 'NULL_TREE'. If CODE is out of range the function 41415 should return 'error_mark_node'. 41416 41417 -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx 41418 SUBTARGET, machine_mode MODE, int IGNORE) 41419 41420 Expand a call to a machine specific built-in function that was set 41421 up by 'TARGET_INIT_BUILTINS'. EXP is the expression for the 41422 function call; the result should go to TARGET if that is 41423 convenient, and have mode MODE if that is convenient. SUBTARGET 41424 may be used as the target for computing one of EXP's operands. 41425 IGNORE is nonzero if the value is to be ignored. This function 41426 should return the result of the call to the built-in function. 41427 41428 -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (unsigned int 41429 LOC, tree FNDECL, void *ARGLIST) 41430 Select a replacement for a machine specific built-in function that 41431 was set up by 'TARGET_INIT_BUILTINS'. This is done _before_ 41432 regular type checking, and so allows the target to implement a 41433 crude form of function overloading. FNDECL is the declaration of 41434 the built-in function. ARGLIST is the list of arguments passed to 41435 the built-in function. The result is a complete expression that 41436 implements the operation, usually another 'CALL_EXPR'. ARGLIST 41437 really has type 'VEC(tree,gc)*' 41438 41439 -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, int N_ARGS, tree 41440 *ARGP, bool IGNORE) 41441 Fold a call to a machine specific built-in function that was set up 41442 by 'TARGET_INIT_BUILTINS'. FNDECL is the declaration of the 41443 built-in function. N_ARGS is the number of arguments passed to the 41444 function; the arguments themselves are pointed to by ARGP. The 41445 result is another tree, valid for both GIMPLE and GENERIC, 41446 containing a simplified expression for the call's result. If 41447 IGNORE is true the value will be ignored. 41448 41449 -- Target Hook: bool TARGET_GIMPLE_FOLD_BUILTIN (gimple_stmt_iterator 41450 *GSI) 41451 Fold a call to a machine specific built-in function that was set up 41452 by 'TARGET_INIT_BUILTINS'. GSI points to the gimple statement 41453 holding the function call. Returns true if any change was made to 41454 the GIMPLE stream. 41455 41456 -- Target Hook: int TARGET_COMPARE_VERSION_PRIORITY (tree DECL1, tree 41457 DECL2) 41458 This hook is used to compare the target attributes in two functions 41459 to determine which function's features get higher priority. This 41460 is used during function multi-versioning to figure out the order in 41461 which two versions must be dispatched. A function version with a 41462 higher priority is checked for dispatching earlier. DECL1 and 41463 DECL2 are the two function decls that will be compared. 41464 41465 -- Target Hook: tree TARGET_GET_FUNCTION_VERSIONS_DISPATCHER (void 41466 *DECL) 41467 This hook is used to get the dispatcher function for a set of 41468 function versions. The dispatcher function is called to invoke the 41469 right function version at run-time. DECL is one version from a set 41470 of semantically identical versions. 41471 41472 -- Target Hook: tree TARGET_GENERATE_VERSION_DISPATCHER_BODY (void 41473 *ARG) 41474 This hook is used to generate the dispatcher logic to invoke the 41475 right function version at run-time for a given set of function 41476 versions. ARG points to the callgraph node of the dispatcher 41477 function whose body must be generated. 41478 41479 -- Target Hook: bool TARGET_CAN_USE_DOLOOP_P (const widest_int 41480 &ITERATIONS, const widest_int &ITERATIONS_MAX, unsigned int 41481 LOOP_DEPTH, bool ENTERED_AT_TOP) 41482 Return true if it is possible to use low-overhead loops 41483 ('doloop_end' and 'doloop_begin') for a particular loop. 41484 ITERATIONS gives the exact number of iterations, or 0 if not known. 41485 ITERATIONS_MAX gives the maximum number of iterations, or 0 if not 41486 known. LOOP_DEPTH is the nesting depth of the loop, with 1 for 41487 innermost loops, 2 for loops that contain innermost loops, and so 41488 on. ENTERED_AT_TOP is true if the loop is only entered from the 41489 top. 41490 41491 This hook is only used if 'doloop_end' is available. The default 41492 implementation returns true. You can use 41493 'can_use_doloop_if_innermost' if the loop must be the innermost, 41494 and if there are no other restrictions. 41495 41496 -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (const 41497 rtx_insn *INSN) 41498 41499 Take an instruction in INSN and return NULL if it is valid within a 41500 low-overhead loop, otherwise return a string explaining why doloop 41501 could not be applied. 41502 41503 Many targets use special registers for low-overhead looping. For 41504 any instruction that clobbers these this function should return a 41505 string indicating the reason why the doloop could not be applied. 41506 By default, the RTL loop optimizer does not use a present doloop 41507 pattern for loops containing function calls or branch on table 41508 instructions. 41509 41510 -- Target Hook: bool TARGET_LEGITIMATE_COMBINED_INSN (rtx_insn *INSN) 41511 Take an instruction in INSN and return 'false' if the instruction 41512 is not appropriate as a combination of two or more instructions. 41513 The default is to accept all instructions. 41514 41515 -- Target Hook: bool TARGET_CAN_FOLLOW_JUMP (const rtx_insn *FOLLOWER, 41516 const rtx_insn *FOLLOWEE) 41517 FOLLOWER and FOLLOWEE are JUMP_INSN instructions; return true if 41518 FOLLOWER may be modified to follow FOLLOWEE; false, if it can't. 41519 For example, on some targets, certain kinds of branches can't be 41520 made to follow through a hot/cold partitioning. 41521 41522 -- Target Hook: bool TARGET_COMMUTATIVE_P (const_rtx X, int OUTER_CODE) 41523 This target hook returns 'true' if X is considered to be 41524 commutative. Usually, this is just COMMUTATIVE_P (X), but the HP 41525 PA doesn't consider PLUS to be commutative inside a MEM. 41526 OUTER_CODE is the rtx code of the enclosing rtl, if known, 41527 otherwise it is UNKNOWN. 41528 41529 -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG) 41530 41531 When the initial value of a hard register has been copied in a 41532 pseudo register, it is often not necessary to actually allocate 41533 another register to this pseudo register, because the original hard 41534 register or a stack slot it has been saved into can be used. 41535 'TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register 41536 allocation once for each hard register that had its initial value 41537 copied by using 'get_func_hard_reg_initial_val' or 41538 'get_hard_reg_initial_val'. Possible values are 'NULL_RTX', if you 41539 don't want to do any special allocation, a 'REG' rtx--that would 41540 typically be the hard register itself, if it is known not to be 41541 clobbered--or a 'MEM'. If you are returning a 'MEM', this is only 41542 a hint for the allocator; it might decide to use another register 41543 anyways. You may use 'current_function_is_leaf' or 'REG_N_SETS' in 41544 the hook to determine if the hard register in question will not be 41545 clobbered. The default value of this hook is 'NULL', which 41546 disables any special allocation. 41547 41548 -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned 41549 FLAGS) 41550 This target hook returns nonzero if X, an 'unspec' or 41551 'unspec_volatile' operation, might cause a trap. Targets can use 41552 this hook to enhance precision of analysis for 'unspec' and 41553 'unspec_volatile' operations. You may call 'may_trap_p_1' to 41554 analyze inner elements of X in which case FLAGS should be passed 41555 along. 41556 41557 -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL) 41558 The compiler invokes this hook whenever it changes its current 41559 function context ('cfun'). You can define this function if the 41560 back end needs to perform any initialization or reset actions on a 41561 per-function basis. For example, it may be used to implement 41562 function attributes that affect register usage or code generation 41563 patterns. The argument DECL is the declaration for the new 41564 function context, and may be null to indicate that the compiler has 41565 left a function context and is returning to processing at the top 41566 level. The default hook function does nothing. 41567 41568 GCC sets 'cfun' to a dummy function context during initialization 41569 of some parts of the back end. The hook function is not invoked in 41570 this situation; you need not worry about the hook being invoked 41571 recursively, or when the back end is in a partially-initialized 41572 state. 'cfun' might be 'NULL' to indicate processing at top level, 41573 outside of any function scope. 41574 41575 -- Macro: TARGET_OBJECT_SUFFIX 41576 Define this macro to be a C string representing the suffix for 41577 object files on your target machine. If you do not define this 41578 macro, GCC will use '.o' as the suffix for object files. 41579 41580 -- Macro: TARGET_EXECUTABLE_SUFFIX 41581 Define this macro to be a C string representing the suffix to be 41582 automatically added to executable files on your target machine. If 41583 you do not define this macro, GCC will use the null string as the 41584 suffix for executable files. 41585 41586 -- Macro: COLLECT_EXPORT_LIST 41587 If defined, 'collect2' will scan the individual object files 41588 specified on its command line and create an export list for the 41589 linker. Define this macro for systems like AIX, where the linker 41590 discards object files that are not referenced from 'main' and uses 41591 export lists. 41592 41593 -- Macro: MODIFY_JNI_METHOD_CALL (MDECL) 41594 Define this macro to a C expression representing a variant of the 41595 method call MDECL, if Java Native Interface (JNI) methods must be 41596 invoked differently from other methods on your target. For 41597 example, on 32-bit Microsoft Windows, JNI methods must be invoked 41598 using the 'stdcall' calling convention and this macro is then 41599 defined as this expression: 41600 41601 build_type_attribute_variant (MDECL, 41602 build_tree_list 41603 (get_identifier ("stdcall"), 41604 NULL)) 41605 41606 -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void) 41607 This target hook returns 'true' past the point in which new jump 41608 instructions could be created. On machines that require a register 41609 for every jump such as the SHmedia ISA of SH5, this point would 41610 typically be reload, so this target hook should be defined to a 41611 function such as: 41612 41613 static bool 41614 cannot_modify_jumps_past_reload_p () 41615 { 41616 return (reload_completed || reload_in_progress); 41617 } 41618 41619 -- Target Hook: reg_class_t TARGET_BRANCH_TARGET_REGISTER_CLASS (void) 41620 This target hook returns a register class for which branch target 41621 register optimizations should be applied. All registers in this 41622 class should be usable interchangeably. After reload, registers in 41623 this class will be re-allocated and loads will be hoisted out of 41624 loops and be subjected to inter-block scheduling. 41625 41626 -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool 41627 AFTER_PROLOGUE_EPILOGUE_GEN) 41628 Branch target register optimization will by default exclude 41629 callee-saved registers that are not already live during the current 41630 function; if this target hook returns true, they will be included. 41631 The target code must than make sure that all target registers in 41632 the class returned by 'TARGET_BRANCH_TARGET_REGISTER_CLASS' that 41633 might need saving are saved. AFTER_PROLOGUE_EPILOGUE_GEN indicates 41634 if prologues and epilogues have already been generated. Note, even 41635 if you only return true when AFTER_PROLOGUE_EPILOGUE_GEN is false, 41636 you still are likely to have to make special provisions in 41637 'INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved 41638 target registers. 41639 41640 -- Target Hook: bool TARGET_HAVE_CONDITIONAL_EXECUTION (void) 41641 This target hook returns true if the target supports conditional 41642 execution. This target hook is required only when the target has 41643 several different modes and they have different conditional 41644 execution capability, such as ARM. 41645 41646 -- Target Hook: rtx TARGET_GEN_CCMP_FIRST (rtx_insn **PREP_SEQ, 41647 rtx_insn **GEN_SEQ, int CODE, tree OP0, tree OP1) 41648 This function prepares to emit a comparison insn for the first 41649 compare in a sequence of conditional comparisions. It returns an 41650 appropriate comparison with 'CC' for passing to 'gen_ccmp_next' or 41651 'cbranch_optab'. The insns to prepare the compare are saved in 41652 PREP_SEQ and the compare insns are saved in GEN_SEQ. They will be 41653 emitted when all the compares in the the conditional comparision 41654 are generated without error. CODE is the 'rtx_code' of the compare 41655 for OP0 and OP1. 41656 41657 -- Target Hook: rtx TARGET_GEN_CCMP_NEXT (rtx_insn **PREP_SEQ, rtx_insn 41658 **GEN_SEQ, rtx PREV, int CMP_CODE, tree OP0, tree OP1, int 41659 BIT_CODE) 41660 This function prepares to emit a conditional comparison within a 41661 sequence of conditional comparisons. It returns an appropriate 41662 comparison with 'CC' for passing to 'gen_ccmp_next' or 41663 'cbranch_optab'. The insns to prepare the compare are saved in 41664 PREP_SEQ and the compare insns are saved in GEN_SEQ. They will be 41665 emitted when all the compares in the conditional comparision are 41666 generated without error. The PREV expression is the result of a 41667 prior call to 'gen_ccmp_first' or 'gen_ccmp_next'. It may return 41668 'NULL' if the combination of PREV and this comparison is not 41669 supported, otherwise the result must be appropriate for passing to 41670 'gen_ccmp_next' or 'cbranch_optab'. CODE is the 'rtx_code' of the 41671 compare for OP0 and OP1. BIT_CODE is 'AND' or 'IOR', which is the 41672 op on the compares. 41673 41674 -- Target Hook: unsigned TARGET_LOOP_UNROLL_ADJUST (unsigned NUNROLL, 41675 struct loop *LOOP) 41676 This target hook returns a new value for the number of times LOOP 41677 should be unrolled. The parameter NUNROLL is the number of times 41678 the loop is to be unrolled. The parameter LOOP is a pointer to the 41679 loop, which is going to be checked for unrolling. This target hook 41680 is required only when the target has special constraints like 41681 maximum number of memory accesses. 41682 41683 -- Macro: POWI_MAX_MULTS 41684 If defined, this macro is interpreted as a signed integer C 41685 expression that specifies the maximum number of floating point 41686 multiplications that should be emitted when expanding 41687 exponentiation by an integer constant inline. When this value is 41688 defined, exponentiation requiring more than this number of 41689 multiplications is implemented by calling the system library's 41690 'pow', 'powf' or 'powl' routines. The default value places no 41691 upper bound on the multiplication count. 41692 41693 -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char 41694 *IPREFIX, int STDINC) 41695 This target hook should register any extra include files for the 41696 target. The parameter STDINC indicates if normal include files are 41697 present. The parameter SYSROOT is the system root directory. The 41698 parameter IPREFIX is the prefix for the gcc directory. 41699 41700 -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const 41701 char *IPREFIX, int STDINC) 41702 This target hook should register any extra include files for the 41703 target before any standard headers. The parameter STDINC indicates 41704 if normal include files are present. The parameter SYSROOT is the 41705 system root directory. The parameter IPREFIX is the prefix for the 41706 gcc directory. 41707 41708 -- Macro: void TARGET_OPTF (char *PATH) 41709 This target hook should register special include paths for the 41710 target. The parameter PATH is the include to register. On Darwin 41711 systems, this is used for Framework includes, which have semantics 41712 that are different from '-I'. 41713 41714 -- Macro: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL) 41715 This target macro returns 'true' if it is safe to use a local alias 41716 for a virtual function FNDECL when constructing thunks, 'false' 41717 otherwise. By default, the macro returns 'true' for all functions, 41718 if a target supports aliases (i.e. defines 'ASM_OUTPUT_DEF'), 41719 'false' otherwise, 41720 41721 -- Macro: TARGET_FORMAT_TYPES 41722 If defined, this macro is the name of a global variable containing 41723 target-specific format checking information for the '-Wformat' 41724 option. The default is to have no target-specific format checks. 41725 41726 -- Macro: TARGET_N_FORMAT_TYPES 41727 If defined, this macro is the number of entries in 41728 'TARGET_FORMAT_TYPES'. 41729 41730 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES 41731 If defined, this macro is the name of a global variable containing 41732 target-specific format overrides for the '-Wformat' option. The 41733 default is to have no target-specific format overrides. If 41734 defined, 'TARGET_FORMAT_TYPES' must be defined, too. 41735 41736 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT 41737 If defined, this macro specifies the number of entries in 41738 'TARGET_OVERRIDES_FORMAT_ATTRIBUTES'. 41739 41740 -- Macro: TARGET_OVERRIDES_FORMAT_INIT 41741 If defined, this macro specifies the optional initialization 41742 routine for target specific customizations of the system printf and 41743 scanf formatter settings. 41744 41745 -- Target Hook: const char * TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN 41746 (const_tree TYPELIST, const_tree FUNCDECL, const_tree VAL) 41747 If defined, this macro returns the diagnostic message when it is 41748 illegal to pass argument VAL to function FUNCDECL with prototype 41749 TYPELIST. 41750 41751 -- Target Hook: const char * TARGET_INVALID_CONVERSION (const_tree 41752 FROMTYPE, const_tree TOTYPE) 41753 If defined, this macro returns the diagnostic message when it is 41754 invalid to convert from FROMTYPE to TOTYPE, or 'NULL' if validity 41755 should be determined by the front end. 41756 41757 -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP, 41758 const_tree TYPE) 41759 If defined, this macro returns the diagnostic message when it is 41760 invalid to apply operation OP (where unary plus is denoted by 41761 'CONVERT_EXPR') to an operand of type TYPE, or 'NULL' if validity 41762 should be determined by the front end. 41763 41764 -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP, 41765 const_tree TYPE1, const_tree TYPE2) 41766 If defined, this macro returns the diagnostic message when it is 41767 invalid to apply operation OP to operands of types TYPE1 and TYPE2, 41768 or 'NULL' if validity should be determined by the front end. 41769 41770 -- Target Hook: tree TARGET_PROMOTED_TYPE (const_tree TYPE) 41771 If defined, this target hook returns the type to which values of 41772 TYPE should be promoted when they appear in expressions, analogous 41773 to the integer promotions, or 'NULL_TREE' to use the front end's 41774 normal promotion rules. This hook is useful when there are 41775 target-specific types with special promotion rules. This is 41776 currently used only by the C and C++ front ends. 41777 41778 -- Target Hook: tree TARGET_CONVERT_TO_TYPE (tree TYPE, tree EXPR) 41779 If defined, this hook returns the result of converting EXPR to 41780 TYPE. It should return the converted expression, or 'NULL_TREE' to 41781 apply the front end's normal conversion rules. This hook is useful 41782 when there are target-specific types with special conversion rules. 41783 This is currently used only by the C and C++ front ends. 41784 41785 -- Macro: OBJC_JBLEN 41786 This macro determines the size of the objective C jump buffer for 41787 the NeXT runtime. By default, OBJC_JBLEN is defined to an 41788 innocuous value. 41789 41790 -- Macro: LIBGCC2_UNWIND_ATTRIBUTE 41791 Define this macro if any target-specific attributes need to be 41792 attached to the functions in 'libgcc' that provide low-level 41793 support for call stack unwinding. It is used in declarations in 41794 'unwind-generic.h' and the associated definitions of those 41795 functions. 41796 41797 -- Target Hook: void TARGET_UPDATE_STACK_BOUNDARY (void) 41798 Define this macro to update the current function stack boundary if 41799 necessary. 41800 41801 -- Target Hook: rtx TARGET_GET_DRAP_RTX (void) 41802 This hook should return an rtx for Dynamic Realign Argument Pointer 41803 (DRAP) if a different argument pointer register is needed to access 41804 the function's argument list due to stack realignment. Return 41805 'NULL' if no DRAP is needed. 41806 41807 -- Target Hook: bool TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS (void) 41808 When optimization is disabled, this hook indicates whether or not 41809 arguments should be allocated to stack slots. Normally, GCC 41810 allocates stacks slots for arguments when not optimizing in order 41811 to make debugging easier. However, when a function is declared 41812 with '__attribute__((naked))', there is no stack frame, and the 41813 compiler cannot safely move arguments from the registers in which 41814 they are passed to the stack. Therefore, this hook should return 41815 true in general, but false for naked functions. The default 41816 implementation always returns true. 41817 41818 -- Target Hook: unsigned HOST_WIDE_INT TARGET_CONST_ANCHOR 41819 On some architectures it can take multiple instructions to 41820 synthesize a constant. If there is another constant already in a 41821 register that is close enough in value then it is preferable that 41822 the new constant is computed from this register using immediate 41823 addition or subtraction. We accomplish this through CSE. Besides 41824 the value of the constant we also add a lower and an upper constant 41825 anchor to the available expressions. These are then queried when 41826 encountering new constants. The anchors are computed by rounding 41827 the constant up and down to a multiple of the value of 41828 'TARGET_CONST_ANCHOR'. 'TARGET_CONST_ANCHOR' should be the maximum 41829 positive value accepted by immediate-add plus one. We currently 41830 assume that the value of 'TARGET_CONST_ANCHOR' is a power of 2. 41831 For example, on MIPS, where add-immediate takes a 16-bit signed 41832 value, 'TARGET_CONST_ANCHOR' is set to '0x8000'. The default value 41833 is zero, which disables this optimization. 41834 41835 -- Target Hook: unsigned HOST_WIDE_INT TARGET_ASAN_SHADOW_OFFSET (void) 41836 Return the offset bitwise ored into shifted address to get 41837 corresponding Address Sanitizer shadow memory address. NULL if 41838 Address Sanitizer is not supported by the target. 41839 41840 -- Target Hook: unsigned HOST_WIDE_INT TARGET_MEMMODEL_CHECK (unsigned 41841 HOST_WIDE_INT VAL) 41842 Validate target specific memory model mask bits. When NULL no 41843 target specific memory model bits are allowed. 41844 41845 -- Target Hook: unsigned char TARGET_ATOMIC_TEST_AND_SET_TRUEVAL 41846 This value should be set if the result written by 41847 'atomic_test_and_set' is not exactly 1, i.e. the 'bool' 'true'. 41848 41849 -- Target Hook: bool TARGET_HAS_IFUNC_P (void) 41850 It returns true if the target supports GNU indirect functions. The 41851 support includes the assembler, linker and dynamic linker. The 41852 default value of this hook is based on target's libc. 41853 41854 -- Target Hook: unsigned int TARGET_ATOMIC_ALIGN_FOR_MODE (machine_mode 41855 MODE) 41856 If defined, this function returns an appropriate alignment in bits 41857 for an atomic object of machine_mode MODE. If 0 is returned then 41858 the default alignment for the specified mode is used. 41859 41860 -- Target Hook: void TARGET_ATOMIC_ASSIGN_EXPAND_FENV (tree *HOLD, tree 41861 *CLEAR, tree *UPDATE) 41862 ISO C11 requires atomic compound assignments that may raise 41863 floating-point exceptions to raise exceptions corresponding to the 41864 arithmetic operation whose result was successfully stored in a 41865 compare-and-exchange sequence. This requires code equivalent to 41866 calls to 'feholdexcept', 'feclearexcept' and 'feupdateenv' to be 41867 generated at appropriate points in the compare-and-exchange 41868 sequence. This hook should set '*HOLD' to an expression equivalent 41869 to the call to 'feholdexcept', '*CLEAR' to an expression equivalent 41870 to the call to 'feclearexcept' and '*UPDATE' to an expression 41871 equivalent to the call to 'feupdateenv'. The three expressions are 41872 'NULL_TREE' on entry to the hook and may be left as 'NULL_TREE' if 41873 no code is required in a particular place. The default 41874 implementation leaves all three expressions as 'NULL_TREE'. The 41875 '__atomic_feraiseexcept' function from 'libatomic' may be of use as 41876 part of the code generated in '*UPDATE'. 41877 41878 -- Target Hook: void TARGET_RECORD_OFFLOAD_SYMBOL (tree) 41879 Used when offloaded functions are seen in the compilation unit and 41880 no named sections are available. It is called once for each symbol 41881 that must be recorded in the offload function and variable table. 41882 41883 -- Target Hook: char * TARGET_OFFLOAD_OPTIONS (void) 41884 Used when writing out the list of options into an LTO file. It 41885 should translate any relevant target-specific options (such as the 41886 ABI in use) into one of the '-foffload' options that exist as a 41887 common interface to express such options. It should return a 41888 string containing these options, separated by spaces, which the 41889 caller will free. 41890 41891 -- Macro: TARGET_SUPPORTS_WIDE_INT 41892 41893 On older ports, large integers are stored in 'CONST_DOUBLE' rtl 41894 objects. Newer ports define 'TARGET_SUPPORTS_WIDE_INT' to be 41895 nonzero to indicate that large integers are stored in 41896 'CONST_WIDE_INT' rtl objects. The 'CONST_WIDE_INT' allows very 41897 large integer constants to be represented. 'CONST_DOUBLE' is 41898 limited to twice the size of the host's 'HOST_WIDE_INT' 41899 representation. 41900 41901 Converting a port mostly requires looking for the places where 41902 'CONST_DOUBLE's are used with 'VOIDmode' and replacing that code 41903 with code that accesses 'CONST_WIDE_INT's. '"grep -i 41904 const_double"' at the port level gets you to 95% of the changes 41905 that need to be made. There are a few places that require a deeper 41906 look. 41907 41908 * There is no equivalent to 'hval' and 'lval' for 41909 'CONST_WIDE_INT's. This would be difficult to express in the 41910 md language since there are a variable number of elements. 41911 41912 Most ports only check that 'hval' is either 0 or -1 to see if 41913 the value is small. As mentioned above, this will no longer 41914 be necessary since small constants are always 'CONST_INT'. Of 41915 course there are still a few exceptions, the alpha's 41916 constraint used by the zap instruction certainly requires 41917 careful examination by C code. However, all the current code 41918 does is pass the hval and lval to C code, so evolving the c 41919 code to look at the 'CONST_WIDE_INT' is not really a large 41920 change. 41921 41922 * Because there is no standard template that ports use to 41923 materialize constants, there is likely to be some futzing that 41924 is unique to each port in this code. 41925 41926 * The rtx costs may have to be adjusted to properly account for 41927 larger constants that are represented as 'CONST_WIDE_INT'. 41928 41929 All and all it does not take long to convert ports that the 41930 maintainer is familiar with. 41931 41932 -- Target Hook: bool TARGET_HAVE_SPECULATION_SAFE_VALUE (bool ACTIVE) 41933 This hook is used to determine the level of target support for 41934 '__builtin_speculation_safe_value'. If called with an argument of 41935 false, it returns true if the target has been modified to support 41936 this builtin. If called with an argument of true, it returns true 41937 if the target requires active mitigation execution might be 41938 speculative. 41939 41940 The default implementation returns false if the target does not 41941 define a pattern named 'speculation_barrier'. Else it returns true 41942 for the first case and whether the pattern is enabled for the 41943 current compilation for the second case. 41944 41945 For targets that have no processors that can execute instructions 41946 speculatively an alternative implemenation of this hook is 41947 available: simply redefine this hook to 41948 'speculation_safe_value_not_needed' along with your other target 41949 hooks. 41950 41951 -- Target Hook: rtx TARGET_SPECULATION_SAFE_VALUE (machine_mode MODE, 41952 rtx RESULT, rtx VAL, rtx FAILVAL) 41953 This target hook can be used to generate a target-specific code 41954 sequence that implements the '__builtin_speculation_safe_value' 41955 built-in function. The function must always return VAL in RESULT 41956 in mode MODE when the cpu is not executing speculatively, but must 41957 never return that when speculating until it is known that the 41958 speculation will not be unwound. The hook supports two primary 41959 mechanisms for implementing the requirements. The first is to emit 41960 a speculation barrier which forces the processor to wait until all 41961 prior speculative operations have been resolved; the second is to 41962 use a target-specific mechanism that can track the speculation 41963 state and to return FAILVAL if it can determine that speculation 41964 must be unwound at a later time. 41965 41966 The default implementation simply copies VAL to RESULT and emits a 41967 'speculation_barrier' instruction if that is defined. 41968 41969 -- Target Hook: void TARGET_RUN_TARGET_SELFTESTS (void) 41970 If selftests are enabled, run any selftests for this target. 41971 41972 41973File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top 41974 4197519 Host Configuration 41976********************* 41977 41978Most details about the machine and system on which the compiler is 41979actually running are detected by the 'configure' script. Some things 41980are impossible for 'configure' to detect; these are described in two 41981ways, either by macros defined in a file named 'xm-MACHINE.h' or by hook 41982functions in the file specified by the OUT_HOST_HOOK_OBJ variable in 41983'config.gcc'. (The intention is that very few hosts will need a header 41984file but nearly every fully supported host will need to override some 41985hooks.) 41986 41987 If you need to define only a few macros, and they have simple 41988definitions, consider using the 'xm_defines' variable in your 41989'config.gcc' entry instead of creating a host configuration header. 41990*Note System Config::. 41991 41992* Menu: 41993 41994* Host Common:: Things every host probably needs implemented. 41995* Filesystem:: Your host cannot have the letter 'a' in filenames? 41996* Host Misc:: Rare configuration options for hosts. 41997 41998 41999File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config 42000 4200119.1 Host Common 42002================ 42003 42004Some things are just not portable, even between similar operating 42005systems, and are too difficult for autoconf to detect. They get 42006implemented using hook functions in the file specified by the 42007HOST_HOOK_OBJ variable in 'config.gcc'. 42008 42009 -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void) 42010 This host hook is used to set up handling for extra signals. The 42011 most common thing to do in this hook is to detect stack overflow. 42012 42013 -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int 42014 FD) 42015 This host hook returns the address of some space that is likely to 42016 be free in some subsequent invocation of the compiler. We intend 42017 to load the PCH data at this address such that the data need not be 42018 relocated. The area should be able to hold SIZE bytes. If the 42019 host uses 'mmap', FD is an open file descriptor that can be used 42020 for probing. 42021 42022 -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS, size_t 42023 SIZE, int FD, size_t OFFSET) 42024 This host hook is called when a PCH file is about to be loaded. We 42025 want to load SIZE bytes from FD at OFFSET into memory at ADDRESS. 42026 The given address will be the result of a previous invocation of 42027 'HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we couldn't allocate 42028 SIZE bytes at ADDRESS. Return 0 if the memory is allocated but the 42029 data is not loaded. Return 1 if the hook has performed everything. 42030 42031 If the implementation uses reserved address space, free any 42032 reserved space beyond SIZE, regardless of the return value. If no 42033 PCH will be loaded, this hook may be called with SIZE zero, in 42034 which case all reserved address space should be freed. 42035 42036 Do not try to handle values of ADDRESS that could not have been 42037 returned by this executable; just return -1. Such values usually 42038 indicate an out-of-date PCH file (built by some other GCC 42039 executable), and such a PCH file won't work. 42040 42041 -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void); 42042 This host hook returns the alignment required for allocating 42043 virtual memory. Usually this is the same as getpagesize, but on 42044 some hosts the alignment for reserving memory differs from the 42045 pagesize for committing memory. 42046 42047 42048File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config 42049 4205019.2 Host Filesystem 42051==================== 42052 42053GCC needs to know a number of things about the semantics of the host 42054machine's filesystem. Filesystems with Unix and MS-DOS semantics are 42055automatically detected. For other systems, you can define the following 42056macros in 'xm-MACHINE.h'. 42057 42058'HAVE_DOS_BASED_FILE_SYSTEM' 42059 This macro is automatically defined by 'system.h' if the host file 42060 system obeys the semantics defined by MS-DOS instead of Unix. DOS 42061 file systems are case insensitive, file specifications may begin 42062 with a drive letter, and both forward slash and backslash ('/' and 42063 '\') are directory separators. 42064 42065'DIR_SEPARATOR' 42066'DIR_SEPARATOR_2' 42067 If defined, these macros expand to character constants specifying 42068 separators for directory names within a file specification. 42069 'system.h' will automatically give them appropriate values on Unix 42070 and MS-DOS file systems. If your file system is neither of these, 42071 define one or both appropriately in 'xm-MACHINE.h'. 42072 42073 However, operating systems like VMS, where constructing a pathname 42074 is more complicated than just stringing together directory names 42075 separated by a special character, should not define either of these 42076 macros. 42077 42078'PATH_SEPARATOR' 42079 If defined, this macro should expand to a character constant 42080 specifying the separator for elements of search paths. The default 42081 value is a colon (':'). DOS-based systems usually, but not always, 42082 use semicolon (';'). 42083 42084'VMS' 42085 Define this macro if the host system is VMS. 42086 42087'HOST_OBJECT_SUFFIX' 42088 Define this macro to be a C string representing the suffix for 42089 object files on your host machine. If you do not define this 42090 macro, GCC will use '.o' as the suffix for object files. 42091 42092'HOST_EXECUTABLE_SUFFIX' 42093 Define this macro to be a C string representing the suffix for 42094 executable files on your host machine. If you do not define this 42095 macro, GCC will use the null string as the suffix for executable 42096 files. 42097 42098'HOST_BIT_BUCKET' 42099 A pathname defined by the host operating system, which can be 42100 opened as a file and written to, but all the information written is 42101 discarded. This is commonly known as a "bit bucket" or "null 42102 device". If you do not define this macro, GCC will use '/dev/null' 42103 as the bit bucket. If the host does not support a bit bucket, 42104 define this macro to an invalid filename. 42105 42106'UPDATE_PATH_HOST_CANONICALIZE (PATH)' 42107 If defined, a C statement (sans semicolon) that performs 42108 host-dependent canonicalization when a path used in a compilation 42109 driver or preprocessor is canonicalized. PATH is a malloc-ed path 42110 to be canonicalized. If the C statement does canonicalize PATH 42111 into a different buffer, the old path should be freed and the new 42112 buffer should have been allocated with malloc. 42113 42114'DUMPFILE_FORMAT' 42115 Define this macro to be a C string representing the format to use 42116 for constructing the index part of debugging dump file names. The 42117 resultant string must fit in fifteen bytes. The full filename will 42118 be the concatenation of: the prefix of the assembler file name, the 42119 string resulting from applying this format to an index number, and 42120 a string unique to each dump file kind, e.g. 'rtl'. 42121 42122 If you do not define this macro, GCC will use '.%02d.'. You should 42123 define this macro if using the default will create an invalid file 42124 name. 42125 42126'DELETE_IF_ORDINARY' 42127 Define this macro to be a C statement (sans semicolon) that 42128 performs host-dependent removal of ordinary temp files in the 42129 compilation driver. 42130 42131 If you do not define this macro, GCC will use the default version. 42132 You should define this macro if the default version does not 42133 reliably remove the temp file as, for example, on VMS which allows 42134 multiple versions of a file. 42135 42136'HOST_LACKS_INODE_NUMBERS' 42137 Define this macro if the host filesystem does not report meaningful 42138 inode numbers in struct stat. 42139 42140 42141File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config 42142 4214319.3 Host Misc 42144============== 42145 42146'FATAL_EXIT_CODE' 42147 A C expression for the status code to be returned when the compiler 42148 exits after serious errors. The default is the system-provided 42149 macro 'EXIT_FAILURE', or '1' if the system doesn't define that 42150 macro. Define this macro only if these defaults are incorrect. 42151 42152'SUCCESS_EXIT_CODE' 42153 A C expression for the status code to be returned when the compiler 42154 exits without serious errors. (Warnings are not serious errors.) 42155 The default is the system-provided macro 'EXIT_SUCCESS', or '0' if 42156 the system doesn't define that macro. Define this macro only if 42157 these defaults are incorrect. 42158 42159'USE_C_ALLOCA' 42160 Define this macro if GCC should use the C implementation of 42161 'alloca' provided by 'libiberty.a'. This only affects how some 42162 parts of the compiler itself allocate memory. It does not change 42163 code generation. 42164 42165 When GCC is built with a compiler other than itself, the C 'alloca' 42166 is always used. This is because most other implementations have 42167 serious bugs. You should define this macro only on a system where 42168 no stack-based 'alloca' can possibly work. For instance, if a 42169 system has a small limit on the size of the stack, GCC's builtin 42170 'alloca' will not work reliably. 42171 42172'COLLECT2_HOST_INITIALIZATION' 42173 If defined, a C statement (sans semicolon) that performs 42174 host-dependent initialization when 'collect2' is being initialized. 42175 42176'GCC_DRIVER_HOST_INITIALIZATION' 42177 If defined, a C statement (sans semicolon) that performs 42178 host-dependent initialization when a compilation driver is being 42179 initialized. 42180 42181'HOST_LONG_LONG_FORMAT' 42182 If defined, the string used to indicate an argument of type 'long 42183 long' to functions like 'printf'. The default value is '"ll"'. 42184 42185'HOST_LONG_FORMAT' 42186 If defined, the string used to indicate an argument of type 'long' 42187 to functions like 'printf'. The default value is '"l"'. 42188 42189'HOST_PTR_PRINTF' 42190 If defined, the string used to indicate an argument of type 'void 42191 *' to functions like 'printf'. The default value is '"%p"'. 42192 42193 In addition, if 'configure' generates an incorrect definition of any of 42194the macros in 'auto-host.h', you can override that definition in a host 42195configuration header. If you need to do this, first see if it is 42196possible to fix 'configure'. 42197 42198 42199File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top 42200 4220120 Makefile Fragments 42202********************* 42203 42204When you configure GCC using the 'configure' script, it will construct 42205the file 'Makefile' from the template file 'Makefile.in'. When it does 42206this, it can incorporate makefile fragments from the 'config' directory. 42207These are used to set Makefile parameters that are not amenable to being 42208calculated by autoconf. The list of fragments to incorporate is set by 42209'config.gcc' (and occasionally 'config.build' and 'config.host'); *Note 42210System Config::. 42211 42212 Fragments are named either 't-TARGET' or 'x-HOST', depending on whether 42213they are relevant to configuring GCC to produce code for a particular 42214target, or to configuring GCC to run on a particular host. Here TARGET 42215and HOST are mnemonics which usually have some relationship to the 42216canonical system name, but no formal connection. 42217 42218 If these files do not exist, it means nothing needs to be added for a 42219given target or host. Most targets need a few 't-TARGET' fragments, but 42220needing 'x-HOST' fragments is rare. 42221 42222* Menu: 42223 42224* Target Fragment:: Writing 't-TARGET' files. 42225* Host Fragment:: Writing 'x-HOST' files. 42226 42227 42228File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments 42229 4223020.1 Target Makefile Fragments 42231============================== 42232 42233Target makefile fragments can set these Makefile variables. 42234 42235'LIBGCC2_CFLAGS' 42236 Compiler flags to use when compiling 'libgcc2.c'. 42237 42238'LIB2FUNCS_EXTRA' 42239 A list of source file names to be compiled or assembled and 42240 inserted into 'libgcc.a'. 42241 42242'CRTSTUFF_T_CFLAGS' 42243 Special flags used when compiling 'crtstuff.c'. *Note 42244 Initialization::. 42245 42246'CRTSTUFF_T_CFLAGS_S' 42247 Special flags used when compiling 'crtstuff.c' for shared linking. 42248 Used if you use 'crtbeginS.o' and 'crtendS.o' in 'EXTRA-PARTS'. 42249 *Note Initialization::. 42250 42251'MULTILIB_OPTIONS' 42252 For some targets, invoking GCC in different ways produces objects 42253 that cannot be linked together. For example, for some targets GCC 42254 produces both big and little endian code. For these targets, you 42255 must arrange for multiple versions of 'libgcc.a' to be compiled, 42256 one for each set of incompatible options. When GCC invokes the 42257 linker, it arranges to link in the right version of 'libgcc.a', 42258 based on the command line options used. 42259 42260 The 'MULTILIB_OPTIONS' macro lists the set of options for which 42261 special versions of 'libgcc.a' must be built. Write options that 42262 are mutually incompatible side by side, separated by a slash. 42263 Write options that may be used together separated by a space. The 42264 build procedure will build all combinations of compatible options. 42265 42266 For example, if you set 'MULTILIB_OPTIONS' to 'm68000/m68020 42267 msoft-float', 'Makefile' will build special versions of 'libgcc.a' 42268 using the following sets of options: '-m68000', '-m68020', 42269 '-msoft-float', '-m68000 -msoft-float', and '-m68020 -msoft-float'. 42270 42271'MULTILIB_DIRNAMES' 42272 If 'MULTILIB_OPTIONS' is used, this variable specifies the 42273 directory names that should be used to hold the various libraries. 42274 Write one element in 'MULTILIB_DIRNAMES' for each element in 42275 'MULTILIB_OPTIONS'. If 'MULTILIB_DIRNAMES' is not used, the 42276 default value will be 'MULTILIB_OPTIONS', with all slashes treated 42277 as spaces. 42278 42279 'MULTILIB_DIRNAMES' describes the multilib directories using GCC 42280 conventions and is applied to directories that are part of the GCC 42281 installation. When multilib-enabled, the compiler will add a 42282 subdirectory of the form PREFIX/MULTILIB before each directory in 42283 the search path for libraries and crt files. 42284 42285 For example, if 'MULTILIB_OPTIONS' is set to 'm68000/m68020 42286 msoft-float', then the default value of 'MULTILIB_DIRNAMES' is 42287 'm68000 m68020 msoft-float'. You may specify a different value if 42288 you desire a different set of directory names. 42289 42290'MULTILIB_MATCHES' 42291 Sometimes the same option may be written in two different ways. If 42292 an option is listed in 'MULTILIB_OPTIONS', GCC needs to know about 42293 any synonyms. In that case, set 'MULTILIB_MATCHES' to a list of 42294 items of the form 'option=option' to describe all relevant 42295 synonyms. For example, 'm68000=mc68000 m68020=mc68020'. 42296 42297'MULTILIB_EXCEPTIONS' 42298 Sometimes when there are multiple sets of 'MULTILIB_OPTIONS' being 42299 specified, there are combinations that should not be built. In 42300 that case, set 'MULTILIB_EXCEPTIONS' to be all of the switch 42301 exceptions in shell case syntax that should not be built. 42302 42303 For example the ARM processor cannot execute both hardware floating 42304 point instructions and the reduced size THUMB instructions at the 42305 same time, so there is no need to build libraries with both of 42306 these options enabled. Therefore 'MULTILIB_EXCEPTIONS' is set to: 42307 *mthumb/*mhard-float* 42308 42309'MULTILIB_REQUIRED' 42310 Sometimes when there are only a few combinations are required, it 42311 would be a big effort to come up with a 'MULTILIB_EXCEPTIONS' list 42312 to cover all undesired ones. In such a case, just listing all the 42313 required combinations in 'MULTILIB_REQUIRED' would be more 42314 straightforward. 42315 42316 The way to specify the entries in 'MULTILIB_REQUIRED' is same with 42317 the way used for 'MULTILIB_EXCEPTIONS', only this time what are 42318 required will be specified. Suppose there are multiple sets of 42319 'MULTILIB_OPTIONS' and only two combinations are required, one for 42320 ARMv7-M and one for ARMv7-R with hard floating-point ABI and FPU, 42321 the 'MULTILIB_REQUIRED' can be set to: 42322 MULTILIB_REQUIRED = mthumb/march=armv7-m 42323 MULTILIB_REQUIRED += march=armv7-r/mfloat-abi=hard/mfpu=vfpv3-d16 42324 42325 The 'MULTILIB_REQUIRED' can be used together with 42326 'MULTILIB_EXCEPTIONS'. The option combinations generated from 42327 'MULTILIB_OPTIONS' will be filtered by 'MULTILIB_EXCEPTIONS' and 42328 then by 'MULTILIB_REQUIRED'. 42329 42330'MULTILIB_REUSE' 42331 Sometimes it is desirable to reuse one existing multilib for 42332 different sets of options. Such kind of reuse can minimize the 42333 number of multilib variants. And for some targets it is better to 42334 reuse an existing multilib than to fall back to default multilib 42335 when there is no corresponding multilib. This can be done by 42336 adding reuse rules to 'MULTILIB_REUSE'. 42337 42338 A reuse rule is comprised of two parts connected by equality sign. 42339 The left part is the option set used to build multilib and the 42340 right part is the option set that will reuse this multilib. Both 42341 parts should only use options specified in 'MULTILIB_OPTIONS' and 42342 the equality signs found in options name should be replaced with 42343 periods. An explicit period in the rule can be escaped by 42344 preceding it with a backslash. The order of options in the left 42345 part matters and should be same with those specified in 42346 'MULTILIB_REQUIRED' or aligned with the order in 42347 'MULTILIB_OPTIONS'. There is no such limitation for options in the 42348 right part as we don't build multilib from them. 42349 42350 'MULTILIB_REUSE' is different from 'MULTILIB_MATCHES' in that it 42351 sets up relations between two option sets rather than two options. 42352 Here is an example to demo how we reuse libraries built in Thumb 42353 mode for applications built in ARM mode: 42354 MULTILIB_REUSE = mthumb/march.armv7-r=marm/march.armv7-r 42355 42356 Before the advent of 'MULTILIB_REUSE', GCC select multilib by 42357 comparing command line options with options used to build multilib. 42358 The 'MULTILIB_REUSE' is complementary to that way. Only when the 42359 original comparison matches nothing it will work to see if it is OK 42360 to reuse some existing multilib. 42361 42362'MULTILIB_EXTRA_OPTS' 42363 Sometimes it is desirable that when building multiple versions of 42364 'libgcc.a' certain options should always be passed on to the 42365 compiler. In that case, set 'MULTILIB_EXTRA_OPTS' to be the list 42366 of options to be used for all builds. If you set this, you should 42367 probably set 'CRTSTUFF_T_CFLAGS' to a dash followed by it. 42368 42369'MULTILIB_OSDIRNAMES' 42370 If 'MULTILIB_OPTIONS' is used, this variable specifies a list of 42371 subdirectory names, that are used to modify the search path 42372 depending on the chosen multilib. Unlike 'MULTILIB_DIRNAMES', 42373 'MULTILIB_OSDIRNAMES' describes the multilib directories using 42374 operating systems conventions, and is applied to the directories 42375 such as 'lib' or those in the 'LIBRARY_PATH' environment variable. 42376 The format is either the same as of 'MULTILIB_DIRNAMES', or a set 42377 of mappings. When it is the same as 'MULTILIB_DIRNAMES', it 42378 describes the multilib directories using operating system 42379 conventions, rather than GCC conventions. When it is a set of 42380 mappings of the form GCCDIR=OSDIR, the left side gives the GCC 42381 convention and the right gives the equivalent OS defined location. 42382 If the OSDIR part begins with a '!', GCC will not search in the 42383 non-multilib directory and use exclusively the multilib directory. 42384 Otherwise, the compiler will examine the search path for libraries 42385 and crt files twice; the first time it will add MULTILIB to each 42386 directory in the search path, the second it will not. 42387 42388 For configurations that support both multilib and multiarch, 42389 'MULTILIB_OSDIRNAMES' also encodes the multiarch name, thus 42390 subsuming 'MULTIARCH_DIRNAME'. The multiarch name is appended to 42391 each directory name, separated by a colon (e.g. 42392 '../lib32:i386-linux-gnu'). 42393 42394 Each multiarch subdirectory will be searched before the 42395 corresponding OS multilib directory, for example 42396 '/lib/i386-linux-gnu' before '/lib/../lib32'. The multiarch name 42397 will also be used to modify the system header search path, as 42398 explained for 'MULTIARCH_DIRNAME'. 42399 42400'MULTIARCH_DIRNAME' 42401 This variable specifies the multiarch name for configurations that 42402 are multiarch-enabled but not multilibbed configurations. 42403 42404 The multiarch name is used to augment the search path for 42405 libraries, crt files and system header files with additional 42406 locations. The compiler will add a multiarch subdirectory of the 42407 form PREFIX/MULTIARCH before each directory in the library and crt 42408 search path. It will also add two directories 42409 'LOCAL_INCLUDE_DIR'/MULTIARCH and 42410 'NATIVE_SYSTEM_HEADER_DIR'/MULTIARCH) to the system header search 42411 path, respectively before 'LOCAL_INCLUDE_DIR' and 42412 'NATIVE_SYSTEM_HEADER_DIR'. 42413 42414 'MULTIARCH_DIRNAME' is not used for configurations that support 42415 both multilib and multiarch. In that case, multiarch names are 42416 encoded in 'MULTILIB_OSDIRNAMES' instead. 42417 42418 More documentation about multiarch can be found at 42419 <https://wiki.debian.org/Multiarch>. 42420 42421'SPECS' 42422 Unfortunately, setting 'MULTILIB_EXTRA_OPTS' is not enough, since 42423 it does not affect the build of target libraries, at least not the 42424 build of the default multilib. One possible work-around is to use 42425 'DRIVER_SELF_SPECS' to bring options from the 'specs' file as if 42426 they had been passed in the compiler driver command line. However, 42427 you don't want to be adding these options after the toolchain is 42428 installed, so you can instead tweak the 'specs' file that will be 42429 used during the toolchain build, while you still install the 42430 original, built-in 'specs'. The trick is to set 'SPECS' to some 42431 other filename (say 'specs.install'), that will then be created out 42432 of the built-in specs, and introduce a 'Makefile' rule to generate 42433 the 'specs' file that's going to be used at build time out of your 42434 'specs.install'. 42435 42436'T_CFLAGS' 42437 These are extra flags to pass to the C compiler. They are used 42438 both when building GCC, and when compiling things with the 42439 just-built GCC. This variable is deprecated and should not be 42440 used. 42441 42442 42443File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments 42444 4244520.2 Host Makefile Fragments 42446============================ 42447 42448The use of 'x-HOST' fragments is discouraged. You should only use it 42449for makefile dependencies. 42450 42451 42452File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top 42453 4245421 'collect2' 42455************* 42456 42457GCC uses a utility called 'collect2' on nearly all systems to arrange to 42458call various initialization functions at start time. 42459 42460 The program 'collect2' works by linking the program once and looking 42461through the linker output file for symbols with particular names 42462indicating they are constructor functions. If it finds any, it creates 42463a new temporary '.c' file containing a table of them, compiles it, and 42464links the program a second time including that file. 42465 42466 The actual calls to the constructors are carried out by a subroutine 42467called '__main', which is called (automatically) at the beginning of the 42468body of 'main' (provided 'main' was compiled with GNU CC). Calling 42469'__main' is necessary, even when compiling C code, to allow linking C 42470and C++ object code together. (If you use '-nostdlib', you get an 42471unresolved reference to '__main', since it's defined in the standard GCC 42472library. Include '-lgcc' at the end of your compiler command line to 42473resolve this reference.) 42474 42475 The program 'collect2' is installed as 'ld' in the directory where the 42476passes of the compiler are installed. When 'collect2' needs to find the 42477_real_ 'ld', it tries the following file names: 42478 42479 * a hard coded linker file name, if GCC was configured with the 42480 '--with-ld' option. 42481 42482 * 'real-ld' in the directories listed in the compiler's search 42483 directories. 42484 42485 * 'real-ld' in the directories listed in the environment variable 42486 'PATH'. 42487 42488 * The file specified in the 'REAL_LD_FILE_NAME' configuration macro, 42489 if specified. 42490 42491 * 'ld' in the compiler's search directories, except that 'collect2' 42492 will not execute itself recursively. 42493 42494 * 'ld' in 'PATH'. 42495 42496 "The compiler's search directories" means all the directories where 42497'gcc' searches for passes of the compiler. This includes directories 42498that you specify with '-B'. 42499 42500 Cross-compilers search a little differently: 42501 42502 * 'real-ld' in the compiler's search directories. 42503 42504 * 'TARGET-real-ld' in 'PATH'. 42505 42506 * The file specified in the 'REAL_LD_FILE_NAME' configuration macro, 42507 if specified. 42508 42509 * 'ld' in the compiler's search directories. 42510 42511 * 'TARGET-ld' in 'PATH'. 42512 42513 'collect2' explicitly avoids running 'ld' using the file name under 42514which 'collect2' itself was invoked. In fact, it remembers up a list of 42515such names--in case one copy of 'collect2' finds another copy (or 42516version) of 'collect2' installed as 'ld' in a second place in the search 42517path. 42518 42519 'collect2' searches for the utilities 'nm' and 'strip' using the same 42520algorithm as above for 'ld'. 42521 42522 42523File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top 42524 4252522 Standard Header File Directories 42526*********************************** 42527 42528'GCC_INCLUDE_DIR' means the same thing for native and cross. It is 42529where GCC stores its private include files, and also where GCC stores 42530the fixed include files. A cross compiled GCC runs 'fixincludes' on the 42531header files in '$(tooldir)/include'. (If the cross compilation header 42532files need to be fixed, they must be installed before GCC is built. If 42533the cross compilation header files are already suitable for GCC, nothing 42534special need be done). 42535 42536 'GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It 42537is where 'g++' looks first for header files. The C++ library installs 42538only target independent header files in that directory. 42539 42540 'LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't 42541install anything there. It is normally '/usr/local/include'. This is 42542where local additions to a packaged system should place header files. 42543 42544 'CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't 42545install anything there. 42546 42547 'TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is 42548the place for other packages to install header files that GCC will use. 42549For a cross-compiler, this is the equivalent of '/usr/include'. When 42550you build a cross-compiler, 'fixincludes' processes any header files in 42551this directory. 42552 42553 42554File: gccint.info, Node: Type Information, Next: Plugins, Prev: Header Dirs, Up: Top 42555 4255623 Memory Management and Type Information 42557***************************************** 42558 42559GCC uses some fairly sophisticated memory management techniques, which 42560involve determining information about GCC's data structures from GCC's 42561source code and using this information to perform garbage collection and 42562implement precompiled headers. 42563 42564 A full C++ parser would be too complicated for this task, so a limited 42565subset of C++ is interpreted and special markers are used to determine 42566what parts of the source to look at. All 'struct', 'union' and 42567'template' structure declarations that define data structures that are 42568allocated under control of the garbage collector must be marked. All 42569global variables that hold pointers to garbage-collected memory must 42570also be marked. Finally, all global variables that need to be saved and 42571restored by a precompiled header must be marked. (The precompiled 42572header mechanism can only save static variables if they're scalar. 42573Complex data structures must be allocated in garbage-collected memory to 42574be saved in a precompiled header.) 42575 42576 The full format of a marker is 42577 GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...)) 42578but in most cases no options are needed. The outer double parentheses 42579are still necessary, though: 'GTY(())'. Markers can appear: 42580 42581 * In a structure definition, before the open brace; 42582 * In a global variable declaration, after the keyword 'static' or 42583 'extern'; and 42584 * In a structure field definition, before the name of the field. 42585 42586 Here are some examples of marking simple data structures and globals. 42587 42588 struct GTY(()) TAG 42589 { 42590 FIELDS... 42591 }; 42592 42593 typedef struct GTY(()) TAG 42594 { 42595 FIELDS... 42596 } *TYPENAME; 42597 42598 static GTY(()) struct TAG *LIST; /* points to GC memory */ 42599 static GTY(()) int COUNTER; /* save counter in a PCH */ 42600 42601 The parser understands simple typedefs such as 'typedef struct TAG 42602*NAME;' and 'typedef int NAME;'. These don't need to be marked. 42603 42604 Since 'gengtype''s understanding of C++ is limited, there are several 42605constructs and declarations that are not supported inside 42606classes/structures marked for automatic GC code generation. The 42607following C++ constructs produce a 'gengtype' error on 42608structures/classes marked for automatic GC code generation: 42609 42610 * Type definitions inside classes/structures are not supported. 42611 * Enumerations inside classes/structures are not supported. 42612 42613 If you have a class or structure using any of the above constructs, you 42614need to mark that class as 'GTY ((user))' and provide your own marking 42615routines (see section *note User GC:: for details). 42616 42617 It is always valid to include function definitions inside classes. 42618Those are always ignored by 'gengtype', as it only cares about data 42619members. 42620 42621* Menu: 42622 42623* GTY Options:: What goes inside a 'GTY(())'. 42624* Inheritance and GTY:: Adding GTY to a class hierarchy. 42625* User GC:: Adding user-provided GC marking routines. 42626* GGC Roots:: Making global variables GGC roots. 42627* Files:: How the generated files work. 42628* Invoking the garbage collector:: How to invoke the garbage collector. 42629* Troubleshooting:: When something does not work as expected. 42630 42631 42632File: gccint.info, Node: GTY Options, Next: Inheritance and GTY, Up: Type Information 42633 4263423.1 The Inside of a 'GTY(())' 42635============================== 42636 42637Sometimes the C code is not enough to fully describe the type structure. 42638Extra information can be provided with 'GTY' options and additional 42639markers. Some options take a parameter, which may be either a string or 42640a type name, depending on the parameter. If an option takes no 42641parameter, it is acceptable either to omit the parameter entirely, or to 42642provide an empty string as a parameter. For example, 'GTY ((skip))' and 42643'GTY ((skip ("")))' are equivalent. 42644 42645 When the parameter is a string, often it is a fragment of C code. Four 42646special escapes may be used in these strings, to refer to pieces of the 42647data structure being marked: 42648 42649'%h' 42650 The current structure. 42651'%1' 42652 The structure that immediately contains the current structure. 42653'%0' 42654 The outermost structure that contains the current structure. 42655'%a' 42656 A partial expression of the form '[i1][i2]...' that indexes the 42657 array item currently being marked. 42658 42659 For instance, suppose that you have a structure of the form 42660 struct A { 42661 ... 42662 }; 42663 struct B { 42664 struct A foo[12]; 42665 }; 42666and 'b' is a variable of type 'struct B'. When marking 'b.foo[11]', 42667'%h' would expand to 'b.foo[11]', '%0' and '%1' would both expand to 42668'b', and '%a' would expand to '[11]'. 42669 42670 As in ordinary C, adjacent strings will be concatenated; this is 42671helpful when you have a complicated expression. 42672 GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE" 42673 " ? TYPE_NEXT_VARIANT (&%h.generic)" 42674 " : TREE_CHAIN (&%h.generic)"))) 42675 42676 The available options are: 42677 42678'length ("EXPRESSION")' 42679 42680 There are two places the type machinery will need to be explicitly 42681 told the length of an array of non-atomic objects. The first case 42682 is when a structure ends in a variable-length array, like this: 42683 struct GTY(()) rtvec_def { 42684 int num_elem; /* number of elements */ 42685 rtx GTY ((length ("%h.num_elem"))) elem[1]; 42686 }; 42687 42688 In this case, the 'length' option is used to override the specified 42689 array length (which should usually be '1'). The parameter of the 42690 option is a fragment of C code that calculates the length. 42691 42692 The second case is when a structure or a global variable contains a 42693 pointer to an array, like this: 42694 struct gimple_omp_for_iter * GTY((length ("%h.collapse"))) iter; 42695 In this case, 'iter' has been allocated by writing something like 42696 x->iter = ggc_alloc_cleared_vec_gimple_omp_for_iter (collapse); 42697 and the 'collapse' provides the length of the field. 42698 42699 This second use of 'length' also works on global variables, like: 42700 static GTY((length("reg_known_value_size"))) rtx *reg_known_value; 42701 42702 Note that the 'length' option is only meant for use with arrays of 42703 non-atomic objects, that is, objects that contain pointers pointing 42704 to other GTY-managed objects. For other GC-allocated arrays and 42705 strings you should use 'atomic'. 42706 42707'skip' 42708 42709 If 'skip' is applied to a field, the type machinery will ignore it. 42710 This is somewhat dangerous; the only safe use is in a union when 42711 one field really isn't ever used. 42712 42713'for_user' 42714 42715 Use this to mark types that need to be marked by user gc routines, 42716 but are not refered to in a template argument. So if you have some 42717 user gc type T1 and a non user gc type T2 you can give T2 the 42718 for_user option so that the marking functions for T1 can call non 42719 mangled functions to mark T2. 42720 42721'desc ("EXPRESSION")' 42722'tag ("CONSTANT")' 42723'default' 42724 42725 The type machinery needs to be told which field of a 'union' is 42726 currently active. This is done by giving each field a constant 42727 'tag' value, and then specifying a discriminator using 'desc'. The 42728 value of the expression given by 'desc' is compared against each 42729 'tag' value, each of which should be different. If no 'tag' is 42730 matched, the field marked with 'default' is used if there is one, 42731 otherwise no field in the union will be marked. 42732 42733 In the 'desc' option, the "current structure" is the union that it 42734 discriminates. Use '%1' to mean the structure containing it. 42735 There are no escapes available to the 'tag' option, since it is a 42736 constant. 42737 42738 For example, 42739 struct GTY(()) tree_binding 42740 { 42741 struct tree_common common; 42742 union tree_binding_u { 42743 tree GTY ((tag ("0"))) scope; 42744 struct cp_binding_level * GTY ((tag ("1"))) level; 42745 } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope; 42746 tree value; 42747 }; 42748 42749 In this example, the value of BINDING_HAS_LEVEL_P when applied to a 42750 'struct tree_binding *' is presumed to be 0 or 1. If 1, the type 42751 mechanism will treat the field 'level' as being present and if 0, 42752 will treat the field 'scope' as being present. 42753 42754 The 'desc' and 'tag' options can also be used for inheritance to 42755 denote which subclass an instance is. See *note Inheritance and 42756 GTY:: for more information. 42757 42758'cache' 42759 42760 When the 'cache' option is applied to a global variable 42761 gt_clear_cache is called on that variable between the mark and 42762 sweep phases of garbage collection. The gt_clear_cache function is 42763 free to mark blocks as used, or to clear pointers in the variable. 42764 42765'deletable' 42766 42767 'deletable', when applied to a global variable, indicates that when 42768 garbage collection runs, there's no need to mark anything pointed 42769 to by this variable, it can just be set to 'NULL' instead. This is 42770 used to keep a list of free structures around for re-use. 42771 42772'maybe_undef' 42773 42774 When applied to a field, 'maybe_undef' indicates that it's OK if 42775 the structure that this fields points to is never defined, so long 42776 as this field is always 'NULL'. This is used to avoid requiring 42777 backends to define certain optional structures. It doesn't work 42778 with language frontends. 42779 42780'nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")' 42781 42782 The type machinery expects all pointers to point to the start of an 42783 object. Sometimes for abstraction purposes it's convenient to have 42784 a pointer which points inside an object. So long as it's possible 42785 to convert the original object to and from the pointer, such 42786 pointers can still be used. TYPE is the type of the original 42787 object, the TO EXPRESSION returns the pointer given the original 42788 object, and the FROM EXPRESSION returns the original object given 42789 the pointer. The pointer will be available using the '%h' escape. 42790 42791'chain_next ("EXPRESSION")' 42792'chain_prev ("EXPRESSION")' 42793'chain_circular ("EXPRESSION")' 42794 42795 It's helpful for the type machinery to know if objects are often 42796 chained together in long lists; this lets it generate code that 42797 uses less stack space by iterating along the list instead of 42798 recursing down it. 'chain_next' is an expression for the next item 42799 in the list, 'chain_prev' is an expression for the previous item. 42800 For singly linked lists, use only 'chain_next'; for doubly linked 42801 lists, use both. The machinery requires that taking the next item 42802 of the previous item gives the original item. 'chain_circular' is 42803 similar to 'chain_next', but can be used for circular single linked 42804 lists. 42805 42806'reorder ("FUNCTION NAME")' 42807 42808 Some data structures depend on the relative ordering of pointers. 42809 If the precompiled header machinery needs to change that ordering, 42810 it will call the function referenced by the 'reorder' option, 42811 before changing the pointers in the object that's pointed to by the 42812 field the option applies to. The function must take four 42813 arguments, with the signature 42814 'void *, void *, gt_pointer_operator, void *'. The first parameter 42815 is a pointer to the structure that contains the object being 42816 updated, or the object itself if there is no containing structure. 42817 The second parameter is a cookie that should be ignored. The third 42818 parameter is a routine that, given a pointer, will update it to its 42819 correct new value. The fourth parameter is a cookie that must be 42820 passed to the second parameter. 42821 42822 PCH cannot handle data structures that depend on the absolute 42823 values of pointers. 'reorder' functions can be expensive. When 42824 possible, it is better to depend on properties of the data, like an 42825 ID number or the hash of a string instead. 42826 42827'atomic' 42828 42829 The 'atomic' option can only be used with pointers. It informs the 42830 GC machinery that the memory that the pointer points to does not 42831 contain any pointers, and hence it should be treated by the GC and 42832 PCH machinery as an "atomic" block of memory that does not need to 42833 be examined when scanning memory for pointers. In particular, the 42834 machinery will not scan that memory for pointers to mark them as 42835 reachable (when marking pointers for GC) or to relocate them (when 42836 writing a PCH file). 42837 42838 The 'atomic' option differs from the 'skip' option. 'atomic' keeps 42839 the memory under Garbage Collection, but makes the GC ignore the 42840 contents of the memory. 'skip' is more drastic in that it causes 42841 the pointer and the memory to be completely ignored by the Garbage 42842 Collector. So, memory marked as 'atomic' is automatically freed 42843 when no longer reachable, while memory marked as 'skip' is not. 42844 42845 The 'atomic' option must be used with great care, because all sorts 42846 of problem can occur if used incorrectly, that is, if the memory 42847 the pointer points to does actually contain a pointer. 42848 42849 Here is an example of how to use it: 42850 struct GTY(()) my_struct { 42851 int number_of_elements; 42852 unsigned int * GTY ((atomic)) elements; 42853 }; 42854 In this case, 'elements' is a pointer under GC, and the memory it 42855 points to needs to be allocated using the Garbage Collector, and 42856 will be freed automatically by the Garbage Collector when it is no 42857 longer referenced. But the memory that the pointer points to is an 42858 array of 'unsigned int' elements, and the GC must not try to scan 42859 it to find pointers to mark or relocate, which is why it is marked 42860 with the 'atomic' option. 42861 42862 Note that, currently, global variables cannot be marked with 42863 'atomic'; only fields of a struct can. This is a known limitation. 42864 It would be useful to be able to mark global pointers with 'atomic' 42865 to make the PCH machinery aware of them so that they are saved and 42866 restored correctly to PCH files. 42867 42868'special ("NAME")' 42869 42870 The 'special' option is used to mark types that have to be dealt 42871 with by special case machinery. The parameter is the name of the 42872 special case. See 'gengtype.c' for further details. Avoid adding 42873 new special cases unless there is no other alternative. 42874 42875'user' 42876 42877 The 'user' option indicates that the code to mark structure fields 42878 is completely handled by user-provided routines. See section *note 42879 User GC:: for details on what functions need to be provided. 42880 42881 42882File: gccint.info, Node: Inheritance and GTY, Next: User GC, Prev: GTY Options, Up: Type Information 42883 4288423.2 Support for inheritance 42885============================ 42886 42887gengtype has some support for simple class hierarchies. You can use 42888this to have gengtype autogenerate marking routines, provided: 42889 42890 * There must be a concrete base class, with a discriminator 42891 expression that can be used to identify which subclass an instance 42892 is. 42893 * Only single inheritance is used. 42894 * None of the classes within the hierarchy are templates. 42895 42896 If your class hierarchy does not fit in this pattern, you must use 42897*note User GC:: instead. 42898 42899 The base class and its discriminator must be identified using the 42900"desc" option. Each concrete subclass must use the "tag" option to 42901identify which value of the discriminator it corresponds to. 42902 42903 Every class in the hierarchy must have a 'GTY(())' marker, as gengtype 42904will only attempt to parse classes that have such a marker (1). 42905 42906 class GTY((desc("%h.kind"), tag("0"))) example_base 42907 { 42908 public: 42909 int kind; 42910 tree a; 42911 }; 42912 42913 class GTY((tag("1"))) some_subclass : public example_base 42914 { 42915 public: 42916 tree b; 42917 }; 42918 42919 class GTY((tag("2"))) some_other_subclass : public example_base 42920 { 42921 public: 42922 tree c; 42923 }; 42924 42925 The generated marking routines for the above will contain a "switch" on 42926"kind", visiting all appropriate fields. For example, if kind is 2, it 42927will cast to "some_other_subclass" and visit fields a, b, and c. 42928 42929 ---------- Footnotes ---------- 42930 42931 (1) Classes lacking such a marker will not be identified as being 42932part of the hierarchy, and so the marking routines will not handle them, 42933leading to a assertion failure within the marking routines due to an 42934unknown tag value (assuming that assertions are enabled). 42935 42936 42937File: gccint.info, Node: User GC, Next: GGC Roots, Prev: Inheritance and GTY, Up: Type Information 42938 4293923.3 Support for user-provided GC marking routines 42940================================================== 42941 42942The garbage collector supports types for which no automatic marking code 42943is generated. For these types, the user is required to provide three 42944functions: one to act as a marker for garbage collection, and two 42945functions to act as marker and pointer walker for pre-compiled headers. 42946 42947 Given a structure 'struct GTY((user)) my_struct', the following 42948functions should be defined to mark 'my_struct': 42949 42950 void gt_ggc_mx (my_struct *p) 42951 { 42952 /* This marks field 'fld'. */ 42953 gt_ggc_mx (p->fld); 42954 } 42955 42956 void gt_pch_nx (my_struct *p) 42957 { 42958 /* This marks field 'fld'. */ 42959 gt_pch_nx (tp->fld); 42960 } 42961 42962 void gt_pch_nx (my_struct *p, gt_pointer_operator op, void *cookie) 42963 { 42964 /* For every field 'fld', call the given pointer operator. */ 42965 op (&(tp->fld), cookie); 42966 } 42967 42968 In general, each marker 'M' should call 'M' for every pointer field in 42969the structure. Fields that are not allocated in GC or are not pointers 42970must be ignored. 42971 42972 For embedded lists (e.g., structures with a 'next' or 'prev' pointer), 42973the marker must follow the chain and mark every element in it. 42974 42975 Note that the rules for the pointer walker 'gt_pch_nx (my_struct *, 42976gt_pointer_operator, void *)' are slightly different. In this case, the 42977operation 'op' must be applied to the _address_ of every pointer field. 42978 4297923.3.1 User-provided marking routines for template types 42980-------------------------------------------------------- 42981 42982When a template type 'TP' is marked with 'GTY', all instances of that 42983type are considered user-provided types. This means that the individual 42984instances of 'TP' do not need to be marked with 'GTY'. The user needs 42985to provide template functions to mark all the fields of the type. 42986 42987 The following code snippets represent all the functions that need to be 42988provided. Note that type 'TP' may reference to more than one type. In 42989these snippets, there is only one type 'T', but there could be more. 42990 42991 template<typename T> 42992 void gt_ggc_mx (TP<T> *tp) 42993 { 42994 extern void gt_ggc_mx (T&); 42995 42996 /* This marks field 'fld' of type 'T'. */ 42997 gt_ggc_mx (tp->fld); 42998 } 42999 43000 template<typename T> 43001 void gt_pch_nx (TP<T> *tp) 43002 { 43003 extern void gt_pch_nx (T&); 43004 43005 /* This marks field 'fld' of type 'T'. */ 43006 gt_pch_nx (tp->fld); 43007 } 43008 43009 template<typename T> 43010 void gt_pch_nx (TP<T *> *tp, gt_pointer_operator op, void *cookie) 43011 { 43012 /* For every field 'fld' of 'tp' with type 'T *', call the given 43013 pointer operator. */ 43014 op (&(tp->fld), cookie); 43015 } 43016 43017 template<typename T> 43018 void gt_pch_nx (TP<T> *tp, gt_pointer_operator, void *cookie) 43019 { 43020 extern void gt_pch_nx (T *, gt_pointer_operator, void *); 43021 43022 /* For every field 'fld' of 'tp' with type 'T', call the pointer 43023 walker for all the fields of T. */ 43024 gt_pch_nx (&(tp->fld), op, cookie); 43025 } 43026 43027 Support for user-defined types is currently limited. The following 43028restrictions apply: 43029 43030 1. Type 'TP' and all the argument types 'T' must be marked with 'GTY'. 43031 43032 2. Type 'TP' can only have type names in its argument list. 43033 43034 3. The pointer walker functions are different for 'TP<T>' and 'TP<T 43035 *>'. In the case of 'TP<T>', references to 'T' must be handled by 43036 calling 'gt_pch_nx' (which will, in turn, walk all the pointers 43037 inside fields of 'T'). In the case of 'TP<T *>', references to 'T 43038 *' must be handled by calling the 'op' function on the address of 43039 the pointer (see the code snippets above). 43040 43041 43042File: gccint.info, Node: GGC Roots, Next: Files, Prev: User GC, Up: Type Information 43043 4304423.4 Marking Roots for the Garbage Collector 43045============================================ 43046 43047In addition to keeping track of types, the type machinery also locates 43048the global variables ("roots") that the garbage collector starts at. 43049Roots must be declared using one of the following syntaxes: 43050 43051 * 'extern GTY(([OPTIONS])) TYPE NAME;' 43052 * 'static GTY(([OPTIONS])) TYPE NAME;' 43053The syntax 43054 * 'GTY(([OPTIONS])) TYPE NAME;' 43055is _not_ accepted. There should be an 'extern' declaration of such a 43056variable in a header somewhere--mark that, not the definition. Or, if 43057the variable is only used in one file, make it 'static'. 43058 43059 43060File: gccint.info, Node: Files, Next: Invoking the garbage collector, Prev: GGC Roots, Up: Type Information 43061 4306223.5 Source Files Containing Type Information 43063============================================= 43064 43065Whenever you add 'GTY' markers to a source file that previously had 43066none, or create a new source file containing 'GTY' markers, there are 43067three things you need to do: 43068 43069 1. You need to add the file to the list of source files the type 43070 machinery scans. There are four cases: 43071 43072 a. For a back-end file, this is usually done automatically; if 43073 not, you should add it to 'target_gtfiles' in the appropriate 43074 port's entries in 'config.gcc'. 43075 43076 b. For files shared by all front ends, add the filename to the 43077 'GTFILES' variable in 'Makefile.in'. 43078 43079 c. For files that are part of one front end, add the filename to 43080 the 'gtfiles' variable defined in the appropriate 43081 'config-lang.in'. Headers should appear before non-headers in 43082 this list. 43083 43084 d. For files that are part of some but not all front ends, add 43085 the filename to the 'gtfiles' variable of _all_ the front ends 43086 that use it. 43087 43088 2. If the file was a header file, you'll need to check that it's 43089 included in the right place to be visible to the generated files. 43090 For a back-end header file, this should be done automatically. For 43091 a front-end header file, it needs to be included by the same file 43092 that includes 'gtype-LANG.h'. For other header files, it needs to 43093 be included in 'gtype-desc.c', which is a generated file, so add it 43094 to 'ifiles' in 'open_base_file' in 'gengtype.c'. 43095 43096 For source files that aren't header files, the machinery will 43097 generate a header file that should be included in the source file 43098 you just changed. The file will be called 'gt-PATH.h' where PATH 43099 is the pathname relative to the 'gcc' directory with slashes 43100 replaced by -, so for example the header file to be included in 43101 'cp/parser.c' is called 'gt-cp-parser.c'. The generated header 43102 file should be included after everything else in the source file. 43103 Don't forget to mention this file as a dependency in the 43104 'Makefile'! 43105 43106 For language frontends, there is another file that needs to be included 43107somewhere. It will be called 'gtype-LANG.h', where LANG is the name of 43108the subdirectory the language is contained in. 43109 43110 Plugins can add additional root tables. Run the 'gengtype' utility in 43111plugin mode as 'gengtype -P pluginout.h SOURCE-DIR FILE-LIST PLUGIN*.C' 43112with your plugin files PLUGIN*.C using 'GTY' to generate the PLUGINOUT.H 43113file. The GCC build tree is needed to be present in that mode. 43114 43115 43116File: gccint.info, Node: Invoking the garbage collector, Next: Troubleshooting, Prev: Files, Up: Type Information 43117 4311823.6 How to invoke the garbage collector 43119======================================== 43120 43121The GCC garbage collector GGC is only invoked explicitly. In contrast 43122with many other garbage collectors, it is not implicitly invoked by 43123allocation routines when a lot of memory has been consumed. So the only 43124way to have GGC reclaim storage is to call the 'ggc_collect' function 43125explicitly. This call is an expensive operation, as it may have to scan 43126the entire heap. Beware that local variables (on the GCC call stack) 43127are not followed by such an invocation (as many other garbage collectors 43128do): you should reference all your data from static or external 'GTY'-ed 43129variables, and it is advised to call 'ggc_collect' with a shallow call 43130stack. The GGC is an exact mark and sweep garbage collector (so it does 43131not scan the call stack for pointers). In practice GCC passes don't 43132often call 'ggc_collect' themselves, because it is called by the pass 43133manager between passes. 43134 43135 At the time of the 'ggc_collect' call all pointers in the GC-marked 43136structures must be valid or 'NULL'. In practice this means that there 43137should not be uninitialized pointer fields in the structures even if 43138your code never reads or writes those fields at a particular instance. 43139One way to ensure this is to use cleared versions of allocators unless 43140all the fields are initialized manually immediately after allocation. 43141 43142 43143File: gccint.info, Node: Troubleshooting, Prev: Invoking the garbage collector, Up: Type Information 43144 4314523.7 Troubleshooting the garbage collector 43146========================================== 43147 43148With the current garbage collector implementation, most issues should 43149show up as GCC compilation errors. Some of the most commonly 43150encountered issues are described below. 43151 43152 * Gengtype does not produce allocators for a 'GTY'-marked type. 43153 Gengtype checks if there is at least one possible path from GC 43154 roots to at least one instance of each type before outputting 43155 allocators. If there is no such path, the 'GTY' markers will be 43156 ignored and no allocators will be output. Solve this by making 43157 sure that there exists at least one such path. If creating it is 43158 unfeasible or raises a "code smell", consider if you really must 43159 use GC for allocating such type. 43160 43161 * Link-time errors about undefined 'gt_ggc_r_foo_bar' and 43162 similarly-named symbols. Check if your 'foo_bar' source file has 43163 '#include "gt-foo_bar.h"' as its very last line. 43164 43165 43166File: gccint.info, Node: Plugins, Next: LTO, Prev: Type Information, Up: Top 43167 4316824 Plugins 43169********** 43170 43171GCC plugins are loadable modules that provide extra features to the 43172compiler. Like GCC itself they can be distributed in source and binary 43173forms. 43174 43175 GCC plugins provide developers with a rich subset of the GCC API to 43176allow them to extend GCC as they see fit. Whether it is writing an 43177additional optimization pass, transforming code, or analyzing 43178information, plugins can be quite useful. 43179 43180* Menu: 43181 43182* Plugins loading:: How can we load plugins. 43183* Plugin API:: The APIs for plugins. 43184* Plugins pass:: How a plugin interact with the pass manager. 43185* Plugins GC:: How a plugin Interact with GCC Garbage Collector. 43186* Plugins description:: Giving information about a plugin itself. 43187* Plugins attr:: Registering custom attributes or pragmas. 43188* Plugins recording:: Recording information about pass execution. 43189* Plugins gate:: Controlling which passes are being run. 43190* Plugins tracking:: Keeping track of available passes. 43191* Plugins building:: How can we build a plugin. 43192 43193 43194File: gccint.info, Node: Plugins loading, Next: Plugin API, Up: Plugins 43195 4319624.1 Loading Plugins 43197==================== 43198 43199Plugins are supported on platforms that support '-ldl -rdynamic' as well 43200as Windows/MinGW. They are loaded by the compiler using 'dlopen' or 43201equivalent and invoked at pre-determined locations in the compilation 43202process. 43203 43204 Plugins are loaded with 43205 43206 '-fplugin=/path/to/NAME.EXT' '-fplugin-arg-NAME-KEY1[=VALUE1]' 43207 43208 Where NAME is the plugin name and EXT is the platform-specific dynamic 43209library extension. It should be 'dll' on Windows/MinGW, 'dylib' on 43210Darwin/Mac OS X, and 'so' on all other platforms. The plugin arguments 43211are parsed by GCC and passed to respective plugins as key-value pairs. 43212Multiple plugins can be invoked by specifying multiple '-fplugin' 43213arguments. 43214 43215 A plugin can be simply given by its short name (no dots or slashes). 43216When simply passing '-fplugin=NAME', the plugin is loaded from the 43217'plugin' directory, so '-fplugin=NAME' is the same as '-fplugin=`gcc 43218-print-file-name=plugin`/NAME.EXT', using backquote shell syntax to 43219query the 'plugin' directory. 43220 43221 43222File: gccint.info, Node: Plugin API, Next: Plugins pass, Prev: Plugins loading, Up: Plugins 43223 4322424.2 Plugin API 43225=============== 43226 43227Plugins are activated by the compiler at specific events as defined in 43228'gcc-plugin.h'. For each event of interest, the plugin should call 43229'register_callback' specifying the name of the event and address of the 43230callback function that will handle that event. 43231 43232 The header 'gcc-plugin.h' must be the first gcc header to be included. 43233 4323424.2.1 Plugin license check 43235--------------------------- 43236 43237Every plugin should define the global symbol 'plugin_is_GPL_compatible' 43238to assert that it has been licensed under a GPL-compatible license. If 43239this symbol does not exist, the compiler will emit a fatal error and 43240exit with the error message: 43241 43242 fatal error: plugin NAME is not licensed under a GPL-compatible license 43243 NAME: undefined symbol: plugin_is_GPL_compatible 43244 compilation terminated 43245 43246 The declared type of the symbol should be int, to match a forward 43247declaration in 'gcc-plugin.h' that suppresses C++ mangling. It does not 43248need to be in any allocated section, though. The compiler merely 43249asserts that the symbol exists in the global scope. Something like this 43250is enough: 43251 43252 int plugin_is_GPL_compatible; 43253 4325424.2.2 Plugin initialization 43255---------------------------- 43256 43257Every plugin should export a function called 'plugin_init' that is 43258called right after the plugin is loaded. This function is responsible 43259for registering all the callbacks required by the plugin and do any 43260other required initialization. 43261 43262 This function is called from 'compile_file' right before invoking the 43263parser. The arguments to 'plugin_init' are: 43264 43265 * 'plugin_info': Plugin invocation information. 43266 * 'version': GCC version. 43267 43268 The 'plugin_info' struct is defined as follows: 43269 43270 struct plugin_name_args 43271 { 43272 char *base_name; /* Short name of the plugin 43273 (filename without .so suffix). */ 43274 const char *full_name; /* Path to the plugin as specified with 43275 -fplugin=. */ 43276 int argc; /* Number of arguments specified with 43277 -fplugin-arg-.... */ 43278 struct plugin_argument *argv; /* Array of ARGC key-value pairs. */ 43279 const char *version; /* Version string provided by plugin. */ 43280 const char *help; /* Help string provided by plugin. */ 43281 } 43282 43283 If initialization fails, 'plugin_init' must return a non-zero value. 43284Otherwise, it should return 0. 43285 43286 The version of the GCC compiler loading the plugin is described by the 43287following structure: 43288 43289 struct plugin_gcc_version 43290 { 43291 const char *basever; 43292 const char *datestamp; 43293 const char *devphase; 43294 const char *revision; 43295 const char *configuration_arguments; 43296 }; 43297 43298 The function 'plugin_default_version_check' takes two pointers to such 43299structure and compare them field by field. It can be used by the 43300plugin's 'plugin_init' function. 43301 43302 The version of GCC used to compile the plugin can be found in the 43303symbol 'gcc_version' defined in the header 'plugin-version.h'. The 43304recommended version check to perform looks like 43305 43306 #include "plugin-version.h" 43307 ... 43308 43309 int 43310 plugin_init (struct plugin_name_args *plugin_info, 43311 struct plugin_gcc_version *version) 43312 { 43313 if (!plugin_default_version_check (version, &gcc_version)) 43314 return 1; 43315 43316 } 43317 43318 but you can also check the individual fields if you want a less strict 43319check. 43320 4332124.2.3 Plugin callbacks 43322----------------------- 43323 43324Callback functions have the following prototype: 43325 43326 /* The prototype for a plugin callback function. 43327 gcc_data - event-specific data provided by GCC 43328 user_data - plugin-specific data provided by the plug-in. */ 43329 typedef void (*plugin_callback_func)(void *gcc_data, void *user_data); 43330 43331 Callbacks can be invoked at the following pre-determined events: 43332 43333 enum plugin_event 43334 { 43335 PLUGIN_START_PARSE_FUNCTION, /* Called before parsing the body of a function. */ 43336 PLUGIN_FINISH_PARSE_FUNCTION, /* After finishing parsing a function. */ 43337 PLUGIN_PASS_MANAGER_SETUP, /* To hook into pass manager. */ 43338 PLUGIN_FINISH_TYPE, /* After finishing parsing a type. */ 43339 PLUGIN_FINISH_DECL, /* After finishing parsing a declaration. */ 43340 PLUGIN_FINISH_UNIT, /* Useful for summary processing. */ 43341 PLUGIN_PRE_GENERICIZE, /* Allows to see low level AST in C and C++ frontends. */ 43342 PLUGIN_FINISH, /* Called before GCC exits. */ 43343 PLUGIN_INFO, /* Information about the plugin. */ 43344 PLUGIN_GGC_START, /* Called at start of GCC Garbage Collection. */ 43345 PLUGIN_GGC_MARKING, /* Extend the GGC marking. */ 43346 PLUGIN_GGC_END, /* Called at end of GGC. */ 43347 PLUGIN_REGISTER_GGC_ROOTS, /* Register an extra GGC root table. */ 43348 PLUGIN_ATTRIBUTES, /* Called during attribute registration */ 43349 PLUGIN_START_UNIT, /* Called before processing a translation unit. */ 43350 PLUGIN_PRAGMAS, /* Called during pragma registration. */ 43351 /* Called before first pass from all_passes. */ 43352 PLUGIN_ALL_PASSES_START, 43353 /* Called after last pass from all_passes. */ 43354 PLUGIN_ALL_PASSES_END, 43355 /* Called before first ipa pass. */ 43356 PLUGIN_ALL_IPA_PASSES_START, 43357 /* Called after last ipa pass. */ 43358 PLUGIN_ALL_IPA_PASSES_END, 43359 /* Allows to override pass gate decision for current_pass. */ 43360 PLUGIN_OVERRIDE_GATE, 43361 /* Called before executing a pass. */ 43362 PLUGIN_PASS_EXECUTION, 43363 /* Called before executing subpasses of a GIMPLE_PASS in 43364 execute_ipa_pass_list. */ 43365 PLUGIN_EARLY_GIMPLE_PASSES_START, 43366 /* Called after executing subpasses of a GIMPLE_PASS in 43367 execute_ipa_pass_list. */ 43368 PLUGIN_EARLY_GIMPLE_PASSES_END, 43369 /* Called when a pass is first instantiated. */ 43370 PLUGIN_NEW_PASS, 43371 /* Called when a file is #include-d or given via the #line directive. 43372 This could happen many times. The event data is the included file path, 43373 as a const char* pointer. */ 43374 PLUGIN_INCLUDE_FILE, 43375 43376 PLUGIN_EVENT_FIRST_DYNAMIC /* Dummy event used for indexing callback 43377 array. */ 43378 }; 43379 43380 In addition, plugins can also look up the enumerator of a named event, 43381and / or generate new events dynamically, by calling the function 43382'get_named_event_id'. 43383 43384 To register a callback, the plugin calls 'register_callback' with the 43385arguments: 43386 43387 * 'char *name': Plugin name. 43388 * 'int event': The event code. 43389 * 'plugin_callback_func callback': The function that handles 'event'. 43390 * 'void *user_data': Pointer to plugin-specific data. 43391 43392 For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, and 43393PLUGIN_REGISTER_GGC_ROOTS pseudo-events the 'callback' should be null, 43394and the 'user_data' is specific. 43395 43396 When the PLUGIN_PRAGMAS event is triggered (with a null pointer as data 43397from GCC), plugins may register their own pragmas. Notice that pragmas 43398are not available from 'lto1', so plugins used with '-flto' option to 43399GCC during link-time optimization cannot use pragmas and do not even see 43400functions like 'c_register_pragma' or 'pragma_lex'. 43401 43402 The PLUGIN_INCLUDE_FILE event, with a 'const char*' file path as GCC 43403data, is triggered for processing of '#include' or '#line' directives. 43404 43405 The PLUGIN_FINISH event is the last time that plugins can call GCC 43406functions, notably emit diagnostics with 'warning', 'error' etc. 43407 43408 43409File: gccint.info, Node: Plugins pass, Next: Plugins GC, Prev: Plugin API, Up: Plugins 43410 4341124.3 Interacting with the pass manager 43412====================================== 43413 43414There needs to be a way to add/reorder/remove passes dynamically. This 43415is useful for both analysis plugins (plugging in after a certain pass 43416such as CFG or an IPA pass) and optimization plugins. 43417 43418 Basic support for inserting new passes or replacing existing passes is 43419provided. A plugin registers a new pass with GCC by calling 43420'register_callback' with the 'PLUGIN_PASS_MANAGER_SETUP' event and a 43421pointer to a 'struct register_pass_info' object defined as follows 43422 43423 enum pass_positioning_ops 43424 { 43425 PASS_POS_INSERT_AFTER, // Insert after the reference pass. 43426 PASS_POS_INSERT_BEFORE, // Insert before the reference pass. 43427 PASS_POS_REPLACE // Replace the reference pass. 43428 }; 43429 43430 struct register_pass_info 43431 { 43432 struct opt_pass *pass; /* New pass provided by the plugin. */ 43433 const char *reference_pass_name; /* Name of the reference pass for hooking 43434 up the new pass. */ 43435 int ref_pass_instance_number; /* Insert the pass at the specified 43436 instance number of the reference pass. */ 43437 /* Do it for every instance if it is 0. */ 43438 enum pass_positioning_ops pos_op; /* how to insert the new pass. */ 43439 }; 43440 43441 43442 /* Sample plugin code that registers a new pass. */ 43443 int 43444 plugin_init (struct plugin_name_args *plugin_info, 43445 struct plugin_gcc_version *version) 43446 { 43447 struct register_pass_info pass_info; 43448 43449 ... 43450 43451 /* Code to fill in the pass_info object with new pass information. */ 43452 43453 ... 43454 43455 /* Register the new pass. */ 43456 register_callback (plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &pass_info); 43457 43458 ... 43459 } 43460 43461 43462File: gccint.info, Node: Plugins GC, Next: Plugins description, Prev: Plugins pass, Up: Plugins 43463 4346424.4 Interacting with the GCC Garbage Collector 43465=============================================== 43466 43467Some plugins may want to be informed when GGC (the GCC Garbage 43468Collector) is running. They can register callbacks for the 43469'PLUGIN_GGC_START' and 'PLUGIN_GGC_END' events (for which the callback 43470is called with a null 'gcc_data') to be notified of the start or end of 43471the GCC garbage collection. 43472 43473 Some plugins may need to have GGC mark additional data. This can be 43474done by registering a callback (called with a null 'gcc_data') for the 43475'PLUGIN_GGC_MARKING' event. Such callbacks can call the 'ggc_set_mark' 43476routine, preferably through the 'ggc_mark' macro (and conversely, these 43477routines should usually not be used in plugins outside of the 43478'PLUGIN_GGC_MARKING' event). Plugins that wish to hold weak references 43479to gc data may also use this event to drop weak references when the 43480object is about to be collected. The 'ggc_marked_p' function can be 43481used to tell if an object is marked, or is about to be collected. The 43482'gt_clear_cache' overloads which some types define may also be of use in 43483managing weak references. 43484 43485 Some plugins may need to add extra GGC root tables, e.g. to handle 43486their own 'GTY'-ed data. This can be done with the 43487'PLUGIN_REGISTER_GGC_ROOTS' pseudo-event with a null callback and the 43488extra root table (of type 'struct ggc_root_tab*') as 'user_data'. 43489Running the 'gengtype -p SOURCE-DIR FILE-LIST PLUGIN*.C ...' utility 43490generates these extra root tables. 43491 43492 You should understand the details of memory management inside GCC 43493before using 'PLUGIN_GGC_MARKING' or 'PLUGIN_REGISTER_GGC_ROOTS'. 43494 43495 43496File: gccint.info, Node: Plugins description, Next: Plugins attr, Prev: Plugins GC, Up: Plugins 43497 4349824.5 Giving information about a plugin 43499====================================== 43500 43501A plugin should give some information to the user about itself. This 43502uses the following structure: 43503 43504 struct plugin_info 43505 { 43506 const char *version; 43507 const char *help; 43508 }; 43509 43510 Such a structure is passed as the 'user_data' by the plugin's init 43511routine using 'register_callback' with the 'PLUGIN_INFO' pseudo-event 43512and a null callback. 43513 43514 43515File: gccint.info, Node: Plugins attr, Next: Plugins recording, Prev: Plugins description, Up: Plugins 43516 4351724.6 Registering custom attributes or pragmas 43518============================================= 43519 43520For analysis (or other) purposes it is useful to be able to add custom 43521attributes or pragmas. 43522 43523 The 'PLUGIN_ATTRIBUTES' callback is called during attribute 43524registration. Use the 'register_attribute' function to register custom 43525attributes. 43526 43527 /* Attribute handler callback */ 43528 static tree 43529 handle_user_attribute (tree *node, tree name, tree args, 43530 int flags, bool *no_add_attrs) 43531 { 43532 return NULL_TREE; 43533 } 43534 43535 /* Attribute definition */ 43536 static struct attribute_spec user_attr = 43537 { "user", 1, 1, false, false, false, false, handle_user_attribute, NULL }; 43538 43539 /* Plugin callback called during attribute registration. 43540 Registered with register_callback (plugin_name, PLUGIN_ATTRIBUTES, register_attributes, NULL) 43541 */ 43542 static void 43543 register_attributes (void *event_data, void *data) 43544 { 43545 warning (0, G_("Callback to register attributes")); 43546 register_attribute (&user_attr); 43547 } 43548 43549 43550 The PLUGIN_PRAGMAS callback is called once during pragmas registration. 43551Use the 'c_register_pragma', 'c_register_pragma_with_data', 43552'c_register_pragma_with_expansion', 43553'c_register_pragma_with_expansion_and_data' functions to register custom 43554pragmas and their handlers (which often want to call 'pragma_lex') from 43555'c-family/c-pragma.h'. 43556 43557 /* Plugin callback called during pragmas registration. Registered with 43558 register_callback (plugin_name, PLUGIN_PRAGMAS, 43559 register_my_pragma, NULL); 43560 */ 43561 static void 43562 register_my_pragma (void *event_data, void *data) 43563 { 43564 warning (0, G_("Callback to register pragmas")); 43565 c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello); 43566 } 43567 43568 It is suggested to pass '"GCCPLUGIN"' (or a short name identifying your 43569plugin) as the "space" argument of your pragma. 43570 43571 Pragmas registered with 'c_register_pragma_with_expansion' or 43572'c_register_pragma_with_expansion_and_data' support preprocessor 43573expansions. For example: 43574 43575 #define NUMBER 10 43576 #pragma GCCPLUGIN foothreshold (NUMBER) 43577 43578 43579File: gccint.info, Node: Plugins recording, Next: Plugins gate, Prev: Plugins attr, Up: Plugins 43580 4358124.7 Recording information about pass execution 43582=============================================== 43583 43584The event PLUGIN_PASS_EXECUTION passes the pointer to the executed pass 43585(the same as current_pass) as 'gcc_data' to the callback. You can also 43586inspect cfun to find out about which function this pass is executed for. 43587Note that this event will only be invoked if the gate check (if 43588applicable, modified by PLUGIN_OVERRIDE_GATE) succeeds. You can use 43589other hooks, like 'PLUGIN_ALL_PASSES_START', 'PLUGIN_ALL_PASSES_END', 43590'PLUGIN_ALL_IPA_PASSES_START', 'PLUGIN_ALL_IPA_PASSES_END', 43591'PLUGIN_EARLY_GIMPLE_PASSES_START', and/or 43592'PLUGIN_EARLY_GIMPLE_PASSES_END' to manipulate global state in your 43593plugin(s) in order to get context for the pass execution. 43594 43595 43596File: gccint.info, Node: Plugins gate, Next: Plugins tracking, Prev: Plugins recording, Up: Plugins 43597 4359824.8 Controlling which passes are being run 43599=========================================== 43600 43601After the original gate function for a pass is called, its result - the 43602gate status - is stored as an integer. Then the event 43603'PLUGIN_OVERRIDE_GATE' is invoked, with a pointer to the gate status in 43604the 'gcc_data' parameter to the callback function. A nonzero value of 43605the gate status means that the pass is to be executed. You can both 43606read and write the gate status via the passed pointer. 43607 43608 43609File: gccint.info, Node: Plugins tracking, Next: Plugins building, Prev: Plugins gate, Up: Plugins 43610 4361124.9 Keeping track of available passes 43612====================================== 43613 43614When your plugin is loaded, you can inspect the various pass lists to 43615determine what passes are available. However, other plugins might add 43616new passes. Also, future changes to GCC might cause generic passes to 43617be added after plugin loading. When a pass is first added to one of the 43618pass lists, the event 'PLUGIN_NEW_PASS' is invoked, with the callback 43619parameter 'gcc_data' pointing to the new pass. 43620 43621 43622File: gccint.info, Node: Plugins building, Prev: Plugins tracking, Up: Plugins 43623 4362424.10 Building GCC plugins 43625========================== 43626 43627If plugins are enabled, GCC installs the headers needed to build a 43628plugin (somewhere in the installation tree, e.g. under '/usr/local'). 43629In particular a 'plugin/include' directory is installed, containing all 43630the header files needed to build plugins. 43631 43632 On most systems, you can query this 'plugin' directory by invoking 'gcc 43633-print-file-name=plugin' (replace if needed 'gcc' with the appropriate 43634program path). 43635 43636 Inside plugins, this 'plugin' directory name can be queried by calling 43637'default_plugin_dir_name ()'. 43638 43639 Plugins may know, when they are compiled, the GCC version for which 43640'plugin-version.h' is provided. The constant macros 43641'GCCPLUGIN_VERSION_MAJOR', 'GCCPLUGIN_VERSION_MINOR', 43642'GCCPLUGIN_VERSION_PATCHLEVEL', 'GCCPLUGIN_VERSION' are integer numbers, 43643so a plugin could ensure it is built for GCC 4.7 with 43644 #if GCCPLUGIN_VERSION != 4007 43645 #error this GCC plugin is for GCC 4.7 43646 #endif 43647 43648 The following GNU Makefile excerpt shows how to build a simple plugin: 43649 43650 HOST_GCC=g++ 43651 TARGET_GCC=gcc 43652 PLUGIN_SOURCE_FILES= plugin1.c plugin2.cc 43653 GCCPLUGINS_DIR:= $(shell $(TARGET_GCC) -print-file-name=plugin) 43654 CXXFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC -fno-rtti -O2 43655 43656 plugin.so: $(PLUGIN_SOURCE_FILES) 43657 $(HOST_GCC) -shared $(CXXFLAGS) $^ -o $@ 43658 43659 A single source file plugin may be built with 'g++ -I`gcc 43660-print-file-name=plugin`/include -fPIC -shared -fno-rtti -O2 plugin.c -o 43661plugin.so', using backquote shell syntax to query the 'plugin' 43662directory. 43663 43664 Plugin support on Windows/MinGW has a number of limitations and 43665additional requirements. When building a plugin on Windows we have to 43666link an import library for the corresponding backend executable, for 43667example, 'cc1.exe', 'cc1plus.exe', etc., in order to gain access to the 43668symbols provided by GCC. This means that on Windows a plugin is 43669language-specific, for example, for C, C++, etc. If you wish to use 43670your plugin with multiple languages, then you will need to build 43671multiple plugin libraries and either instruct your users on how to load 43672the correct version or provide a compiler wrapper that does this 43673automatically. 43674 43675 Additionally, on Windows the plugin library has to export the 43676'plugin_is_GPL_compatible' and 'plugin_init' symbols. If you do not 43677wish to modify the source code of your plugin, then you can use the 43678'-Wl,--export-all-symbols' option or provide a suitable DEF file. 43679Alternatively, you can export just these two symbols by decorating them 43680with '__declspec(dllexport)', for example: 43681 43682 #ifdef _WIN32 43683 __declspec(dllexport) 43684 #endif 43685 int plugin_is_GPL_compatible; 43686 43687 #ifdef _WIN32 43688 __declspec(dllexport) 43689 #endif 43690 int plugin_init (plugin_name_args *, plugin_gcc_version *) 43691 43692 The import libraries are installed into the 'plugin' directory and 43693their names are derived by appending the '.a' extension to the backend 43694executable names, for example, 'cc1.exe.a', 'cc1plus.exe.a', etc. The 43695following command line shows how to build the single source file plugin 43696on Windows to be used with the C++ compiler: 43697 43698 g++ -I`gcc -print-file-name=plugin`/include -shared -Wl,--export-all-symbols \ 43699 -o plugin.dll plugin.c `gcc -print-file-name=plugin`/cc1plus.exe.a 43700 43701 When a plugin needs to use 'gengtype', be sure that both 'gengtype' and 43702'gtype.state' have the same version as the GCC for which the plugin is 43703built. 43704 43705 43706File: gccint.info, Node: LTO, Next: Match and Simplify, Prev: Plugins, Up: Top 43707 4370825 Link Time Optimization 43709************************* 43710 43711Link Time Optimization (LTO) gives GCC the capability of dumping its 43712internal representation (GIMPLE) to disk, so that all the different 43713compilation units that make up a single executable can be optimized as a 43714single module. This expands the scope of inter-procedural optimizations 43715to encompass the whole program (or, rather, everything that is visible 43716at link time). 43717 43718* Menu: 43719 43720* LTO Overview:: Overview of LTO. 43721* LTO object file layout:: LTO file sections in ELF. 43722* IPA:: Using summary information in IPA passes. 43723* WHOPR:: Whole program assumptions, 43724 linker plugin and symbol visibilities. 43725* Internal flags:: Internal flags controlling 'lto1'. 43726 43727 43728File: gccint.info, Node: LTO Overview, Next: LTO object file layout, Up: LTO 43729 4373025.1 Design Overview 43731==================== 43732 43733Link time optimization is implemented as a GCC front end for a bytecode 43734representation of GIMPLE that is emitted in special sections of '.o' 43735files. Currently, LTO support is enabled in most ELF-based systems, as 43736well as darwin, cygwin and mingw systems. 43737 43738 Since GIMPLE bytecode is saved alongside final object code, object 43739files generated with LTO support are larger than regular object files. 43740This "fat" object format makes it easy to integrate LTO into existing 43741build systems, as one can, for instance, produce archives of the files. 43742Additionally, one might be able to ship one set of fat objects which 43743could be used both for development and the production of optimized 43744builds. A, perhaps surprising, side effect of this feature is that any 43745mistake in the toolchain leads to LTO information not being used (e.g. 43746an older 'libtool' calling 'ld' directly). This is both an advantage, 43747as the system is more robust, and a disadvantage, as the user is not 43748informed that the optimization has been disabled. 43749 43750 The current implementation only produces "fat" objects, effectively 43751doubling compilation time and increasing file sizes up to 5x the 43752original size. This hides the problem that some tools, such as 'ar' and 43753'nm', need to understand symbol tables of LTO sections. These tools 43754were extended to use the plugin infrastructure, and with these problems 43755solved, GCC will also support "slim" objects consisting of the 43756intermediate code alone. 43757 43758 At the highest level, LTO splits the compiler in two. The first half 43759(the "writer") produces a streaming representation of all the internal 43760data structures needed to optimize and generate code. This includes 43761declarations, types, the callgraph and the GIMPLE representation of 43762function bodies. 43763 43764 When '-flto' is given during compilation of a source file, the pass 43765manager executes all the passes in 'all_lto_gen_passes'. Currently, 43766this phase is composed of two IPA passes: 43767 43768 * 'pass_ipa_lto_gimple_out' This pass executes the function 43769 'lto_output' in 'lto-streamer-out.c', which traverses the call 43770 graph encoding every reachable declaration, type and function. 43771 This generates a memory representation of all the file sections 43772 described below. 43773 43774 * 'pass_ipa_lto_finish_out' This pass executes the function 43775 'produce_asm_for_decls' in 'lto-streamer-out.c', which takes the 43776 memory image built in the previous pass and encodes it in the 43777 corresponding ELF file sections. 43778 43779 The second half of LTO support is the "reader". This is implemented as 43780the GCC front end 'lto1' in 'lto/lto.c'. When 'collect2' detects a link 43781set of '.o'/'.a' files with LTO information and the '-flto' is enabled, 43782it invokes 'lto1' which reads the set of files and aggregates them into 43783a single translation unit for optimization. The main entry point for 43784the reader is 'lto/lto.c':'lto_main'. 43785 4378625.1.1 LTO modes of operation 43787----------------------------- 43788 43789One of the main goals of the GCC link-time infrastructure was to allow 43790effective compilation of large programs. For this reason GCC implements 43791two link-time compilation modes. 43792 43793 1. _LTO mode_, in which the whole program is read into the compiler at 43794 link-time and optimized in a similar way as if it were a single 43795 source-level compilation unit. 43796 43797 2. _WHOPR or partitioned mode_, designed to utilize multiple CPUs 43798 and/or a distributed compilation environment to quickly link large 43799 applications. WHOPR stands for WHOle Program optimizeR (not to be 43800 confused with the semantics of '-fwhole-program'). It partitions 43801 the aggregated callgraph from many different '.o' files and 43802 distributes the compilation of the sub-graphs to different CPUs. 43803 43804 Note that distributed compilation is not implemented yet, but since 43805 the parallelism is facilitated via generating a 'Makefile', it 43806 would be easy to implement. 43807 43808 WHOPR splits LTO into three main stages: 43809 1. Local generation (LGEN) This stage executes in parallel. Every 43810 file in the program is compiled into the intermediate language and 43811 packaged together with the local call-graph and summary 43812 information. This stage is the same for both the LTO and WHOPR 43813 compilation mode. 43814 43815 2. Whole Program Analysis (WPA) WPA is performed sequentially. The 43816 global call-graph is generated, and a global analysis procedure 43817 makes transformation decisions. The global call-graph is 43818 partitioned to facilitate parallel optimization during phase 3. 43819 The results of the WPA stage are stored into new object files which 43820 contain the partitions of program expressed in the intermediate 43821 language and the optimization decisions. 43822 43823 3. Local transformations (LTRANS) This stage executes in parallel. 43824 All the decisions made during phase 2 are implemented locally in 43825 each partitioned object file, and the final object code is 43826 generated. Optimizations which cannot be decided efficiently 43827 during the phase 2 may be performed on the local call-graph 43828 partitions. 43829 43830 WHOPR can be seen as an extension of the usual LTO mode of compilation. 43831In LTO, WPA and LTRANS are executed within a single execution of the 43832compiler, after the whole program has been read into memory. 43833 43834 When compiling in WHOPR mode, the callgraph is partitioned during the 43835WPA stage. The whole program is split into a given number of partitions 43836of roughly the same size. The compiler tries to minimize the number of 43837references which cross partition boundaries. The main advantage of 43838WHOPR is to allow the parallel execution of LTRANS stages, which are the 43839most time-consuming part of the compilation process. Additionally, it 43840avoids the need to load the whole program into memory. 43841 43842 43843File: gccint.info, Node: LTO object file layout, Next: IPA, Prev: LTO Overview, Up: LTO 43844 4384525.2 LTO file sections 43846====================== 43847 43848LTO information is stored in several ELF sections inside object files. 43849Data structures and enum codes for sections are defined in 43850'lto-streamer.h'. 43851 43852 These sections are emitted from 'lto-streamer-out.c' and mapped in all 43853at once from 'lto/lto.c':'lto_file_read'. The individual functions 43854dealing with the reading/writing of each section are described below. 43855 43856 * Command line options ('.gnu.lto_.opts') 43857 43858 This section contains the command line options used to generate the 43859 object files. This is used at link time to determine the 43860 optimization level and other settings when they are not explicitly 43861 specified at the linker command line. 43862 43863 Currently, GCC does not support combining LTO object files compiled 43864 with different set of the command line options into a single 43865 binary. At link time, the options given on the command line and 43866 the options saved on all the files in a link-time set are applied 43867 globally. No attempt is made at validating the combination of 43868 flags (other than the usual validation done by option processing). 43869 This is implemented in 'lto/lto.c':'lto_read_all_file_options'. 43870 43871 * Symbol table ('.gnu.lto_.symtab') 43872 43873 This table replaces the ELF symbol table for functions and 43874 variables represented in the LTO IL. Symbols used and exported by 43875 the optimized assembly code of "fat" objects might not match the 43876 ones used and exported by the intermediate code. This table is 43877 necessary because the intermediate code is less optimized and thus 43878 requires a separate symbol table. 43879 43880 Additionally, the binary code in the "fat" object will lack a call 43881 to a function, since the call was optimized out at compilation time 43882 after the intermediate language was streamed out. In some special 43883 cases, the same optimization may not happen during link-time 43884 optimization. This would lead to an undefined symbol if only one 43885 symbol table was used. 43886 43887 The symbol table is emitted in 43888 'lto-streamer-out.c':'produce_symtab'. 43889 43890 * Global declarations and types ('.gnu.lto_.decls') 43891 43892 This section contains an intermediate language dump of all 43893 declarations and types required to represent the callgraph, static 43894 variables and top-level debug info. 43895 43896 The contents of this section are emitted in 43897 'lto-streamer-out.c':'produce_asm_for_decls'. Types and symbols 43898 are emitted in a topological order that preserves the sharing of 43899 pointers when the file is read back in 43900 ('lto.c':'read_cgraph_and_symbols'). 43901 43902 * The callgraph ('.gnu.lto_.cgraph') 43903 43904 This section contains the basic data structure used by the GCC 43905 inter-procedural optimization infrastructure. This section stores 43906 an annotated multi-graph which represents the functions and call 43907 sites as well as the variables, aliases and top-level 'asm' 43908 statements. 43909 43910 This section is emitted in 'lto-streamer-out.c':'output_cgraph' and 43911 read in 'lto-cgraph.c':'input_cgraph'. 43912 43913 * IPA references ('.gnu.lto_.refs') 43914 43915 This section contains references between function and static 43916 variables. It is emitted by 'lto-cgraph.c':'output_refs' and read 43917 by 'lto-cgraph.c':'input_refs'. 43918 43919 * Function bodies ('.gnu.lto_.function_body.<name>') 43920 43921 This section contains function bodies in the intermediate language 43922 representation. Every function body is in a separate section to 43923 allow copying of the section independently to different object 43924 files or reading the function on demand. 43925 43926 Functions are emitted in 'lto-streamer-out.c':'output_function' and 43927 read in 'lto-streamer-in.c':'input_function'. 43928 43929 * Static variable initializers ('.gnu.lto_.vars') 43930 43931 This section contains all the symbols in the global variable pool. 43932 It is emitted by 'lto-cgraph.c':'output_varpool' and read in 43933 'lto-cgraph.c':'input_cgraph'. 43934 43935 * Summaries and optimization summaries used by IPA passes 43936 ('.gnu.lto_.<xxx>', where '<xxx>' is one of 'jmpfuncs', 'pureconst' 43937 or 'reference') 43938 43939 These sections are used by IPA passes that need to emit summary 43940 information during LTO generation to be read and aggregated at link 43941 time. Each pass is responsible for implementing two pass manager 43942 hooks: one for writing the summary and another for reading it in. 43943 The format of these sections is entirely up to each individual 43944 pass. The only requirement is that the writer and reader hooks 43945 agree on the format. 43946 43947 43948File: gccint.info, Node: IPA, Next: WHOPR, Prev: LTO object file layout, Up: LTO 43949 4395025.3 Using summary information in IPA passes 43951============================================ 43952 43953Programs are represented internally as a _callgraph_ (a multi-graph 43954where nodes are functions and edges are call sites) and a _varpool_ (a 43955list of static and external variables in the program). 43956 43957 The inter-procedural optimization is organized as a sequence of 43958individual passes, which operate on the callgraph and the varpool. To 43959make the implementation of WHOPR possible, every inter-procedural 43960optimization pass is split into several stages that are executed at 43961different times during WHOPR compilation: 43962 43963 * LGEN time 43964 1. _Generate summary_ ('generate_summary' in 'struct 43965 ipa_opt_pass_d'). This stage analyzes every function body and 43966 variable initializer is examined and stores relevant 43967 information into a pass-specific data structure. 43968 43969 2. _Write summary_ ('write_summary' in 'struct ipa_opt_pass_d'). 43970 This stage writes all the pass-specific information generated 43971 by 'generate_summary'. Summaries go into their own 43972 'LTO_section_*' sections that have to be declared in 43973 'lto-streamer.h':'enum lto_section_type'. A new section is 43974 created by calling 'create_output_block' and data can be 43975 written using the 'lto_output_*' routines. 43976 43977 * WPA time 43978 1. _Read summary_ ('read_summary' in 'struct ipa_opt_pass_d'). 43979 This stage reads all the pass-specific information in exactly 43980 the same order that it was written by 'write_summary'. 43981 43982 2. _Execute_ ('execute' in 'struct opt_pass'). This performs 43983 inter-procedural propagation. This must be done without 43984 actual access to the individual function bodies or variable 43985 initializers. Typically, this results in a transitive closure 43986 operation over the summary information of all the nodes in the 43987 callgraph. 43988 43989 3. _Write optimization summary_ ('write_optimization_summary' in 43990 'struct ipa_opt_pass_d'). This writes the result of the 43991 inter-procedural propagation into the object file. This can 43992 use the same data structures and helper routines used in 43993 'write_summary'. 43994 43995 * LTRANS time 43996 1. _Read optimization summary_ ('read_optimization_summary' in 43997 'struct ipa_opt_pass_d'). The counterpart to 43998 'write_optimization_summary'. This reads the interprocedural 43999 optimization decisions in exactly the same format emitted by 44000 'write_optimization_summary'. 44001 44002 2. _Transform_ ('function_transform' and 'variable_transform' in 44003 'struct ipa_opt_pass_d'). The actual function bodies and 44004 variable initializers are updated based on the information 44005 passed down from the _Execute_ stage. 44006 44007 The implementation of the inter-procedural passes are shared between 44008LTO, WHOPR and classic non-LTO compilation. 44009 44010 * During the traditional file-by-file mode every pass executes its 44011 own _Generate summary_, _Execute_, and _Transform_ stages within 44012 the single execution context of the compiler. 44013 44014 * In LTO compilation mode, every pass uses _Generate summary_ and 44015 _Write summary_ stages at compilation time, while the _Read 44016 summary_, _Execute_, and _Transform_ stages are executed at link 44017 time. 44018 44019 * In WHOPR mode all stages are used. 44020 44021 To simplify development, the GCC pass manager differentiates between 44022normal inter-procedural passes and small inter-procedural passes. A 44023_small inter-procedural pass_ ('SIMPLE_IPA_PASS') is a pass that does 44024everything at once and thus it cannot be executed during WPA in WHOPR 44025mode. It defines only the _Execute_ stage and during this stage it 44026accesses and modifies the function bodies. Such passes are useful for 44027optimization at LGEN or LTRANS time and are used, for example, to 44028implement early optimization before writing object files. The simple 44029inter-procedural passes can also be used for easier prototyping and 44030development of a new inter-procedural pass. 44031 4403225.3.1 Virtual clones 44033--------------------- 44034 44035One of the main challenges of introducing the WHOPR compilation mode was 44036addressing the interactions between optimization passes. In LTO 44037compilation mode, the passes are executed in a sequence, each of which 44038consists of analysis (or _Generate summary_), propagation (or _Execute_) 44039and _Transform_ stages. Once the work of one pass is finished, the next 44040pass sees the updated program representation and can execute. This 44041makes the individual passes dependent on each other. 44042 44043 In WHOPR mode all passes first execute their _Generate summary_ stage. 44044Then summary writing marks the end of the LGEN stage. At WPA time, the 44045summaries are read back into memory and all passes run the _Execute_ 44046stage. Optimization summaries are streamed and sent to LTRANS, where 44047all the passes execute the _Transform_ stage. 44048 44049 Most optimization passes split naturally into analysis, propagation and 44050transformation stages. But some do not. The main problem arises when 44051one pass performs changes and the following pass gets confused by seeing 44052different callgraphs between the _Transform_ stage and the _Generate 44053summary_ or _Execute_ stage. This means that the passes are required to 44054communicate their decisions with each other. 44055 44056 To facilitate this communication, the GCC callgraph infrastructure 44057implements _virtual clones_, a method of representing the changes 44058performed by the optimization passes in the callgraph without needing to 44059update function bodies. 44060 44061 A _virtual clone_ in the callgraph is a function that has no associated 44062body, just a description of how to create its body based on a different 44063function (which itself may be a virtual clone). 44064 44065 The description of function modifications includes adjustments to the 44066function's signature (which allows, for example, removing or adding 44067function arguments), substitutions to perform on the function body, and, 44068for inlined functions, a pointer to the function that it will be inlined 44069into. 44070 44071 It is also possible to redirect any edge of the callgraph from a 44072function to its virtual clone. This implies updating of the call site 44073to adjust for the new function signature. 44074 44075 Most of the transformations performed by inter-procedural optimizations 44076can be represented via virtual clones. For instance, a constant 44077propagation pass can produce a virtual clone of the function which 44078replaces one of its arguments by a constant. The inliner can represent 44079its decisions by producing a clone of a function whose body will be 44080later integrated into a given function. 44081 44082 Using _virtual clones_, the program can be easily updated during the 44083_Execute_ stage, solving most of pass interactions problems that would 44084otherwise occur during _Transform_. 44085 44086 Virtual clones are later materialized in the LTRANS stage and turned 44087into real functions. Passes executed after the virtual clone were 44088introduced also perform their _Transform_ stage on new functions, so for 44089a pass there is no significant difference between operating on a real 44090function or a virtual clone introduced before its _Execute_ stage. 44091 44092 Optimization passes then work on virtual clones introduced before their 44093_Execute_ stage as if they were real functions. The only difference is 44094that clones are not visible during the _Generate Summary_ stage. 44095 44096 To keep function summaries updated, the callgraph interface allows an 44097optimizer to register a callback that is called every time a new clone 44098is introduced as well as when the actual function or variable is 44099generated or when a function or variable is removed. These hooks are 44100registered in the _Generate summary_ stage and allow the pass to keep 44101its information intact until the _Execute_ stage. The same hooks can 44102also be registered during the _Execute_ stage to keep the optimization 44103summaries updated for the _Transform_ stage. 44104 4410525.3.2 IPA references 44106--------------------- 44107 44108GCC represents IPA references in the callgraph. For a function or 44109variable 'A', the _IPA reference_ is a list of all locations where the 44110address of 'A' is taken and, when 'A' is a variable, a list of all 44111direct stores and reads to/from 'A'. References represent an oriented 44112multi-graph on the union of nodes of the callgraph and the varpool. See 44113'ipa-reference.c':'ipa_reference_write_optimization_summary' and 44114'ipa-reference.c':'ipa_reference_read_optimization_summary' for details. 44115 4411625.3.3 Jump functions 44117--------------------- 44118 44119Suppose that an optimization pass sees a function 'A' and it knows the 44120values of (some of) its arguments. The _jump function_ describes the 44121value of a parameter of a given function call in function 'A' based on 44122this knowledge. 44123 44124 Jump functions are used by several optimizations, such as the 44125inter-procedural constant propagation pass and the devirtualization 44126pass. The inliner also uses jump functions to perform inlining of 44127callbacks. 44128 44129 44130File: gccint.info, Node: WHOPR, Next: Internal flags, Prev: IPA, Up: LTO 44131 4413225.4 Whole program assumptions, linker plugin and symbol visibilities 44133===================================================================== 44134 44135Link-time optimization gives relatively minor benefits when used alone. 44136The problem is that propagation of inter-procedural information does not 44137work well across functions and variables that are called or referenced 44138by other compilation units (such as from a dynamically linked library). 44139We say that such functions and variables are _externally visible_. 44140 44141 To make the situation even more difficult, many applications organize 44142themselves as a set of shared libraries, and the default ELF visibility 44143rules allow one to overwrite any externally visible symbol with a 44144different symbol at runtime. This basically disables any optimizations 44145across such functions and variables, because the compiler cannot be sure 44146that the function body it is seeing is the same function body that will 44147be used at runtime. Any function or variable not declared 'static' in 44148the sources degrades the quality of inter-procedural optimization. 44149 44150 To avoid this problem the compiler must assume that it sees the whole 44151program when doing link-time optimization. Strictly speaking, the whole 44152program is rarely visible even at link-time. Standard system libraries 44153are usually linked dynamically or not provided with the link-time 44154information. In GCC, the whole program option ('-fwhole-program') 44155asserts that every function and variable defined in the current 44156compilation unit is static, except for function 'main' (note: at link 44157time, the current unit is the union of all objects compiled with LTO). 44158Since some functions and variables need to be referenced externally, for 44159example by another DSO or from an assembler file, GCC also provides the 44160function and variable attribute 'externally_visible' which can be used 44161to disable the effect of '-fwhole-program' on a specific symbol. 44162 44163 The whole program mode assumptions are slightly more complex in C++, 44164where inline functions in headers are put into _COMDAT_ sections. 44165COMDAT function and variables can be defined by multiple object files 44166and their bodies are unified at link-time and dynamic link-time. COMDAT 44167functions are changed to local only when their address is not taken and 44168thus un-sharing them with a library is not harmful. COMDAT variables 44169always remain externally visible, however for readonly variables it is 44170assumed that their initializers cannot be overwritten by a different 44171value. 44172 44173 GCC provides the function and variable attribute 'visibility' that can 44174be used to specify the visibility of externally visible symbols (or 44175alternatively an '-fdefault-visibility' command line option). ELF 44176defines the 'default', 'protected', 'hidden' and 'internal' 44177visibilities. 44178 44179 The most commonly used is visibility is 'hidden'. It specifies that 44180the symbol cannot be referenced from outside of the current shared 44181library. Unfortunately, this information cannot be used directly by the 44182link-time optimization in the compiler since the whole shared library 44183also might contain non-LTO objects and those are not visible to the 44184compiler. 44185 44186 GCC solves this problem using linker plugins. A _linker plugin_ is an 44187interface to the linker that allows an external program to claim the 44188ownership of a given object file. The linker then performs the linking 44189procedure by querying the plugin about the symbol table of the claimed 44190objects and once the linking decisions are complete, the plugin is 44191allowed to provide the final object file before the actual linking is 44192made. The linker plugin obtains the symbol resolution information which 44193specifies which symbols provided by the claimed objects are bound from 44194the rest of a binary being linked. 44195 44196 GCC is designed to be independent of the rest of the toolchain and aims 44197to support linkers without plugin support. For this reason it does not 44198use the linker plugin by default. Instead, the object files are 44199examined by 'collect2' before being passed to the linker and objects 44200found to have LTO sections are passed to 'lto1' first. This mode does 44201not work for library archives. The decision on what object files from 44202the archive are needed depends on the actual linking and thus GCC would 44203have to implement the linker itself. The resolution information is 44204missing too and thus GCC needs to make an educated guess based on 44205'-fwhole-program'. Without the linker plugin GCC also assumes that 44206symbols are declared 'hidden' and not referred by non-LTO code by 44207default. 44208 44209 44210File: gccint.info, Node: Internal flags, Prev: WHOPR, Up: LTO 44211 4421225.5 Internal flags controlling 'lto1' 44213====================================== 44214 44215The following flags are passed into 'lto1' and are not meant to be used 44216directly from the command line. 44217 44218 * -fwpa This option runs the serial part of the link-time optimizer 44219 performing the inter-procedural propagation (WPA mode). The 44220 compiler reads in summary information from all inputs and performs 44221 an analysis based on summary information only. It generates object 44222 files for subsequent runs of the link-time optimizer where 44223 individual object files are optimized using both summary 44224 information from the WPA mode and the actual function bodies. It 44225 then drives the LTRANS phase. 44226 44227 * -fltrans This option runs the link-time optimizer in the 44228 local-transformation (LTRANS) mode, which reads in output from a 44229 previous run of the LTO in WPA mode. In the LTRANS mode, LTO 44230 optimizes an object and produces the final assembly. 44231 44232 * -fltrans-output-list=FILE This option specifies a file to which the 44233 names of LTRANS output files are written. This option is only 44234 meaningful in conjunction with '-fwpa'. 44235 44236 * -fresolution=FILE This option specifies the linker resolution file. 44237 This option is only meaningful in conjunction with '-fwpa' and as 44238 option to pass through to the LTO linker plugin. 44239 44240 44241File: gccint.info, Node: Match and Simplify, Next: User Experience Guidelines, Prev: LTO, Up: Top 44242 4424326 Match and Simplify 44244********************* 44245 44246The GIMPLE and GENERIC pattern matching project match-and-simplify tries 44247to address several issues. 44248 44249 1. unify expression simplifications currently spread and duplicated 44250 over separate files like fold-const.c, gimple-fold.c and builtins.c 44251 2. allow for a cheap way to implement building and simplifying 44252 non-trivial GIMPLE expressions, avoiding the need to go through 44253 building and simplifying GENERIC via fold_buildN and then 44254 gimplifying via force_gimple_operand 44255 44256 To address these the project introduces a simple domain specific 44257language to write expression simplifications from which code targeting 44258GIMPLE and GENERIC is auto-generated. The GENERIC variant follows the 44259fold_buildN API while for the GIMPLE variant and to address 2) new APIs 44260are introduced. 44261 44262* Menu: 44263 44264* GIMPLE API:: 44265* The Language:: 44266 44267 44268File: gccint.info, Node: GIMPLE API, Next: The Language, Up: Match and Simplify 44269 4427026.1 GIMPLE API 44271=============== 44272 44273 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 44274 gimple_seq *, tree (*)(tree)) 44275 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 44276 tree, gimple_seq *, tree (*)(tree)) 44277 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 44278 tree, tree, gimple_seq *, tree (*)(tree)) 44279 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 44280 tree, gimple_seq *, tree (*)(tree)) 44281 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 44282 tree, tree, gimple_seq *, tree (*)(tree)) 44283 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 44284 tree, tree, tree, gimple_seq *, tree (*)(tree)) 44285 The main GIMPLE API entry to the expression simplifications 44286 mimicing that of the GENERIC fold_{unary,binary,ternary} functions. 44287 44288 thus providing n-ary overloads for operation or function. The 44289additional arguments are a gimple_seq where built statements are 44290inserted on (if 'NULL' then simplifications requiring new statements are 44291not performed) and a valueization hook that can be used to tie 44292simplifications to a SSA lattice. 44293 44294 In addition to those APIs 'fold_stmt' is overloaded with a valueization 44295hook: 44296 44297 -- bool: fold_stmt (gimple_stmt_iterator *, tree (*)(tree)); 44298 44299 Ontop of these a 'fold_buildN'-like API for GIMPLE is introduced: 44300 44301 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 44302 tree_code, tree, tree, tree (*valueize) (tree) = NULL); 44303 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 44304 tree_code, tree, tree, tree, tree (*valueize) (tree) = NULL); 44305 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 44306 tree_code, tree, tree, tree, tree, tree (*valueize) (tree) = 44307 NULL); 44308 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 44309 built_in_function, tree, tree, tree (*valueize) (tree) = 44310 NULL); 44311 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 44312 built_in_function, tree, tree, tree, tree (*valueize) (tree) = 44313 NULL); 44314 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 44315 built_in_function, tree, tree, tree, tree, tree (*valueize) 44316 (tree) = NULL); 44317 -- GIMPLE function: tree gimple_convert (gimple_seq *, location_t, 44318 tree, tree); 44319 44320 which is supposed to replace 'force_gimple_operand (fold_buildN (...), 44321...)' and calls to 'fold_convert'. Overloads without the 'location_t' 44322argument exist. Built statements are inserted on the provided sequence 44323and simplification is performed using the optional valueization hook. 44324 44325 44326File: gccint.info, Node: The Language, Prev: GIMPLE API, Up: Match and Simplify 44327 4432826.2 The Language 44329================= 44330 44331The language to write expression simplifications in resembles other 44332domain-specific languages GCC uses. Thus it is lispy. Lets start with 44333an example from the match.pd file: 44334 44335 (simplify 44336 (bit_and @0 integer_all_onesp) 44337 @0) 44338 44339 This example contains all required parts of an expression 44340simplification. A simplification is wrapped inside a '(simplify ...)' 44341expression. That contains at least two operands - an expression that is 44342matched with the GIMPLE or GENERIC IL and a replacement expression that 44343is returned if the match was successful. 44344 44345 Expressions have an operator ID, 'bit_and' in this case. Expressions 44346can be lower-case tree codes with '_expr' stripped off or builtin 44347function code names in all-caps, like 'BUILT_IN_SQRT'. 44348 44349 '@n' denotes a so-called capture. It captures the operand and lets you 44350refer to it in other places of the match-and-simplify. In the above 44351example it is refered to in the replacement expression. Captures are 44352'@' followed by a number or an identifier. 44353 44354 (simplify 44355 (bit_xor @0 @0) 44356 { build_zero_cst (type); }) 44357 44358 In this example '@0' is mentioned twice which constrains the matched 44359expression to have two equal operands. Usually matches are constraint 44360to equal types. If operands may be constants and conversions are 44361involved matching by value might be preferred in which case use '@@0' to 44362denote a by value match and the specific operand you want to refer to in 44363the result part. This example also introduces operands written in C 44364code. These can be used in the expression replacements and are supposed 44365to evaluate to a tree node which has to be a valid GIMPLE operand (so 44366you cannot generate expressions in C code). 44367 44368 (simplify 44369 (trunc_mod integer_zerop@0 @1) 44370 (if (!integer_zerop (@1)) 44371 @0)) 44372 44373 Here '@0' captures the first operand of the trunc_mod expression which 44374is also predicated with 'integer_zerop'. Expression operands may be 44375either expressions, predicates or captures. Captures can be 44376unconstrained or capture expresions or predicates. 44377 44378 This example introduces an optional operand of simplify, the 44379if-expression. This condition is evaluated after the expression matched 44380in the IL and is required to evaluate to true to enable the replacement 44381expression in the second operand position. The expression operand of 44382the 'if' is a standard C expression which may contain references to 44383captures. The 'if' has an optional third operand which may contain the 44384replacement expression that is enabled when the condition evaluates to 44385false. 44386 44387 A 'if' expression can be used to specify a common condition for 44388multiple simplify patterns, avoiding the need to repeat that multiple 44389times: 44390 44391 (if (!TYPE_SATURATING (type) 44392 && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) 44393 (simplify 44394 (minus (plus @0 @1) @0) 44395 @1) 44396 (simplify 44397 (minus (minus @0 @1) @0) 44398 (negate @1))) 44399 44400 Note that 'if's in outer position do not have the optional else clause 44401but instead have multiple then clauses. 44402 44403 Ifs can be nested. 44404 44405 There exists a 'switch' expression which can be used to chain 44406conditions avoiding nesting 'if's too much: 44407 44408 (simplify 44409 (simple_comparison @0 REAL_CST@1) 44410 (switch 44411 /* a CMP (-0) -> a CMP 0 */ 44412 (if (REAL_VALUE_MINUS_ZERO (TREE_REAL_CST (@1))) 44413 (cmp @0 { build_real (TREE_TYPE (@1), dconst0); })) 44414 /* x != NaN is always true, other ops are always false. */ 44415 (if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1)) 44416 && ! HONOR_SNANS (@1)) 44417 { constant_boolean_node (cmp == NE_EXPR, type); }))) 44418 44419 Is equal to 44420 44421 (simplify 44422 (simple_comparison @0 REAL_CST@1) 44423 (switch 44424 /* a CMP (-0) -> a CMP 0 */ 44425 (if (REAL_VALUE_MINUS_ZERO (TREE_REAL_CST (@1))) 44426 (cmp @0 { build_real (TREE_TYPE (@1), dconst0); }) 44427 /* x != NaN is always true, other ops are always false. */ 44428 (if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1)) 44429 && ! HONOR_SNANS (@1)) 44430 { constant_boolean_node (cmp == NE_EXPR, type); })))) 44431 44432 which has the second 'if' in the else operand of the first. The 44433'switch' expression takes 'if' expressions as operands (which may not 44434have else clauses) and as a last operand a replacement expression which 44435should be enabled by default if no other condition evaluated to true. 44436 44437 Captures can also be used for capturing results of sub-expressions. 44438 44439 #if GIMPLE 44440 (simplify 44441 (pointer_plus (addr@2 @0) INTEGER_CST_P@1) 44442 (if (is_gimple_min_invariant (@2))) 44443 { 44444 poly_int64 off; 44445 tree base = get_addr_base_and_unit_offset (@0, &off); 44446 off += tree_to_uhwi (@1); 44447 /* Now with that we should be able to simply write 44448 (addr (mem_ref (addr @base) (plus @off @1))) */ 44449 build1 (ADDR_EXPR, type, 44450 build2 (MEM_REF, TREE_TYPE (TREE_TYPE (@2)), 44451 build_fold_addr_expr (base), 44452 build_int_cst (ptr_type_node, off))); 44453 }) 44454 #endif 44455 44456 In the above example, '@2' captures the result of the expression '(addr 44457@0)'. For outermost expression only its type can be captured, and the 44458keyword 'type' is reserved for this purpose. The above example also 44459gives a way to conditionalize patterns to only apply to 'GIMPLE' or 44460'GENERIC' by means of using the pre-defined preprocessor macros 'GIMPLE' 44461and 'GENERIC' and using preprocessor directives. 44462 44463 (simplify 44464 (bit_and:c integral_op_p@0 (bit_ior:c (bit_not @0) @1)) 44465 (bit_and @1 @0)) 44466 44467 Here we introduce flags on match expressions. The flag used above, 44468'c', denotes that the expression should be also matched commutated. 44469Thus the above match expression is really the following four match 44470expressions: 44471 44472 (bit_and integral_op_p@0 (bit_ior (bit_not @0) @1)) 44473 (bit_and (bit_ior (bit_not @0) @1) integral_op_p@0) 44474 (bit_and integral_op_p@0 (bit_ior @1 (bit_not @0))) 44475 (bit_and (bit_ior @1 (bit_not @0)) integral_op_p@0) 44476 44477 Usual canonicalizations you know from GENERIC expressions are applied 44478before matching, so for example constant operands always come second in 44479commutative expressions. 44480 44481 The second supported flag is 's' which tells the code generator to fail 44482the pattern if the expression marked with 's' does have more than one 44483use and the simplification results in an expression with more than one 44484operator. For example in 44485 44486 (simplify 44487 (pointer_plus (pointer_plus:s @0 @1) @3) 44488 (pointer_plus @0 (plus @1 @3))) 44489 44490 this avoids the association if '(pointer_plus @0 @1)' is used outside 44491of the matched expression and thus it would stay live and not trivially 44492removed by dead code elimination. Now consider '((x + 3) + -3)' with 44493the temporary holding '(x + 3)' used elsewhere. This simplifies down to 44494'x' which is desirable and thus flagging with 's' does not prevent the 44495transform. Now consider '((x + 3) + 1)' which simplifies to '(x + 4)'. 44496Despite being flagged with 's' the simplification will be performed. 44497The simplification of '((x + a) + 1)' to '(x + (a + 1))' will not 44498performed in this case though. 44499 44500 More features exist to avoid too much repetition. 44501 44502 (for op (plus pointer_plus minus bit_ior bit_xor) 44503 (simplify 44504 (op @0 integer_zerop) 44505 @0)) 44506 44507 A 'for' expression can be used to repeat a pattern for each operator 44508specified, substituting 'op'. 'for' can be nested and a 'for' can have 44509multiple operators to iterate. 44510 44511 (for opa (plus minus) 44512 opb (minus plus) 44513 (for opc (plus minus) 44514 (simplify... 44515 44516 In this example the pattern will be repeated four times with 'opa, opb, 44517opc' being 'plus, minus, plus', 'plus, minus, minus', 'minus, plus, 44518plus', 'minus, plus, minus'. 44519 44520 To avoid repeating operator lists in 'for' you can name them via 44521 44522 (define_operator_list pmm plus minus mult) 44523 44524 and use them in 'for' operator lists where they get expanded. 44525 44526 (for opa (pmm trunc_div) 44527 (simplify... 44528 44529 So this example iterates over 'plus', 'minus', 'mult' and 'trunc_div'. 44530 44531 Using operator lists can also remove the need to explicitely write a 44532'for'. All operator list uses that appear in a 'simplify' or 'match' 44533pattern in operator positions will implicitely be added to a new 'for'. 44534For example 44535 44536 (define_operator_list SQRT BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL) 44537 (define_operator_list POW BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL) 44538 (simplify 44539 (SQRT (POW @0 @1)) 44540 (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); }))) 44541 44542 is the same as 44543 44544 (for SQRT (BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL) 44545 POW (BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL) 44546 (simplify 44547 (SQRT (POW @0 @1)) 44548 (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); })))) 44549 44550 'for's and operator lists can include the special identifier 'null' 44551that matches nothing and can never be generated. This can be used to 44552pad an operator list so that it has a standard form, even if there isn't 44553a suitable operator for every form. 44554 44555 Another building block are 'with' expressions in the result expression 44556which nest the generated code in a new C block followed by its argument: 44557 44558 (simplify 44559 (convert (mult @0 @1)) 44560 (with { tree utype = unsigned_type_for (type); } 44561 (convert (mult (convert:utype @0) (convert:utype @1))))) 44562 44563 This allows code nested in the 'with' to refer to the declared 44564variables. In the above case we use the feature to specify the type of 44565a generated expression with the ':type' syntax where 'type' needs to be 44566an identifier that refers to the desired type. Usually the types of the 44567generated result expressions are determined from the context, but 44568sometimes like in the above case it is required that you specify them 44569explicitely. 44570 44571 As intermediate conversions are often optional there is a way to avoid 44572the need to repeat patterns both with and without such conversions. 44573Namely you can mark a conversion as being optional with a '?': 44574 44575 (simplify 44576 (eq (convert@0 @1) (convert? @2)) 44577 (eq @1 (convert @2))) 44578 44579 which will match both '(eq (convert @1) (convert @2))' and '(eq 44580(convert @1) @2)'. The optional converts are supposed to be all either 44581present or not, thus '(eq (convert? @1) (convert? @2))' will result in 44582two patterns only. If you want to match all four combinations you have 44583access to two additional conditional converts as in '(eq (convert1? @1) 44584(convert2? @2))'. 44585 44586 Predicates available from the GCC middle-end need to be made available 44587explicitely via 'define_predicates': 44588 44589 (define_predicates 44590 integer_onep integer_zerop integer_all_onesp) 44591 44592 You can also define predicates using the pattern matching language and 44593the 'match' form: 44594 44595 (match negate_expr_p 44596 INTEGER_CST 44597 (if (TYPE_OVERFLOW_WRAPS (type) 44598 || may_negate_without_overflow_p (t)))) 44599 (match negate_expr_p 44600 (negate @0)) 44601 44602 This shows that for 'match' expressions there is 't' available which 44603captures the outermost expression (something not possible in the 44604'simplify' context). As you can see 'match' has an identifier as first 44605operand which is how you refer to the predicate in patterns. Multiple 44606'match' for the same identifier add additional cases where the predicate 44607matches. 44608 44609 Predicates can also match an expression in which case you need to 44610provide a template specifying the identifier and where to get its 44611operands from: 44612 44613 (match (logical_inverted_value @0) 44614 (eq @0 integer_zerop)) 44615 (match (logical_inverted_value @0) 44616 (bit_not truth_valued_p@0)) 44617 44618 You can use the above predicate like 44619 44620 (simplify 44621 (bit_and @0 (logical_inverted_value @0)) 44622 { build_zero_cst (type); }) 44623 44624 Which will match a bitwise and of an operand with its logical inverted 44625value. 44626 44627 44628File: gccint.info, Node: User Experience Guidelines, Next: Funding, Prev: Match and Simplify, Up: Top 44629 4463027 User Experience Guidelines 44631***************************** 44632 44633To borrow a slogan from Elm 44634(https://elm-lang.org/blog/compilers-as-assistants), 44635 44636 *Compilers should be assistants, not adversaries.* A compiler 44637 should not just detect bugs, it should then help you understand why 44638 there is a bug. It should not berate you in a robot voice, it 44639 should give you specific hints that help you write better code. 44640 Ultimately, a compiler should make programming faster and more fun! 44641 -- _Evan Czaplicki_ 44642 44643 This chapter provides guidelines on how to implement diagnostics and 44644command-line options in ways that we hope achieve the above ideal. 44645 44646* Menu: 44647 44648* Guidelines for Diagnostics:: How to implement diagnostics. 44649* Guidelines for Options:: Guidelines for command-line options. 44650 44651 44652File: gccint.info, Node: Guidelines for Diagnostics, Next: Guidelines for Options, Up: User Experience Guidelines 44653 4465427.1 Guidelines for Diagnostics 44655=============================== 44656 4465727.1.1 Talk in terms of the user's code 44658--------------------------------------- 44659 44660Diagnostics should be worded in terms of the user's source code, and the 44661source language, rather than GCC's own implementation details. 44662 4466327.1.2 Diagnostics are actionable 44664--------------------------------- 44665 44666A good diagnostic is "actionable": it should assist the user in taking 44667action. 44668 44669 Consider what an end user will want to do when encountering a 44670diagnostic. 44671 44672 Given an error, an end user will think: "How do I fix this?" 44673 44674 Given a warning, an end user will think: 44675 44676 * "Is this a real problem?" 44677 * "Do I care?" 44678 * if they decide it's genuine: "How do I fix this?" 44679 44680 A good diagnostic provides pertinent information to allow the user to 44681easily answer the above questions. 44682 4468327.1.3 The user's attention is important 44684---------------------------------------- 44685 44686A perfect compiler would issue a warning on every aspect of the user's 44687source code that ought to be fixed, and issue no other warnings. 44688Naturally, this ideal is impossible to achieve. 44689 44690 Warnings should have a good "signal-to-noise ratio": we should have few 44691"false positives" (falsely issuing a warning when no warning is 44692warranted) and few "false negatives" (failing to issue a warning when 44693one _is_ justified). 44694 44695 Note that a false positive can mean, in practice, a warning that the 44696user doesn't agree with. Ideally a diagnostic should contain enough 44697information to allow the user to make an informed choice about whether 44698they should care (and how to fix it), but a balance must be drawn 44699against overloading the user with irrelevant data. 44700 4470127.1.4 Precision of Wording 44702--------------------------- 44703 44704Provide the user with details that allow them to identify what the 44705problem is. For example, the vaguely-worded message: 44706 44707 demo.c:1:1: warning: 'noinline' attribute ignored [-Wattributes] 44708 1 | int foo __attribute__((noinline)); 44709 | ^~~ 44710 44711doesn't tell the user why the attribute was ignored, or what kind of 44712entity the compiler thought the attribute was being applied to (the 44713source location for the diagnostic is also poor; *note discussion of 44714'input_location': input_location_example.). A better message would be: 44715 44716 demo.c:1:24: warning: attribute 'noinline' on variable 'foo' was 44717 ignored [-Wattributes] 44718 1 | int foo __attribute__((noinline)); 44719 | ~~~ ~~~~~~~~~~~~~~~^~~~~~~~~ 44720 demo.c:1:24: note: attribute 'noinline' is only applicable to functions 44721 44722which spells out the missing information (and fixes the location 44723information, as discussed below). 44724 44725 The above example uses a note to avoid a combinatorial explosion of 44726possible messages. 44727 4472827.1.5 Try the diagnostic on real-world code 44729-------------------------------------------- 44730 44731It's worth testing a new warning on many instances of real-world code, 44732written by different people, and seeing what it complains about, and 44733what it doesn't complain about. 44734 44735 This may suggest heuristics that silence common false positives. 44736 44737 It may also suggest ways to improve the precision of the message. 44738 4473927.1.6 Make mismatches clear 44740---------------------------- 44741 44742Many diagnostics relate to a mismatch between two different places in 44743the user's source code. Examples include: 44744 * a type mismatch, where the type at a usage site does not match the 44745 type at a declaration 44746 44747 * the argument count at a call site does not match the parameter 44748 count at the declaration 44749 44750 * something is erroneously duplicated (e.g. an error, due to breaking 44751 a uniqueness requirement, or a warning, if it's suggestive of a 44752 bug) 44753 44754 * an "opened" syntactic construct (such as an open-parenthesis) is 44755 not closed 44756 44757 In each case, the diagnostic should indicate *both* pertinent locations 44758(so that the user can easily see the problem and how to fix it). 44759 44760 The standard way to do this is with a note (via 'inform'). For 44761example: 44762 44763 auto_diagnostic_group d; 44764 if (warning_at (loc, OPT_Wduplicated_cond, 44765 "duplicated %<if%> condition")) 44766 inform (EXPR_LOCATION (t), "previously used here"); 44767 44768which leads to: 44769 44770 demo.c: In function 'test': 44771 demo.c:5:17: warning: duplicated 'if' condition [-Wduplicated-cond] 44772 5 | else if (flag > 3) 44773 | ~~~~~^~~ 44774 demo.c:3:12: note: previously used here 44775 3 | if (flag > 3) 44776 | ~~~~~^~~ 44777 44778The 'inform' call should be guarded by the return value from the 44779'warning_at' call so that the note isn't emitted when the warning is 44780suppressed. 44781 44782 For cases involving punctuation where the locations might be near each 44783other, they can be conditionally consolidated via 44784'gcc_rich_location::add_location_if_nearby': 44785 44786 auto_diagnostic_group d; 44787 gcc_rich_location richloc (primary_loc); 44788 bool added secondary = richloc.add_location_if_nearby (secondary_loc); 44789 error_at (&richloc, "main message"); 44790 if (!added secondary) 44791 inform (secondary_loc, "message for secondary"); 44792 44793This will emit either one diagnostic with two locations: 44794 demo.c:42:10: error: main message 44795 (foo) 44796 ~ ^ 44797 44798or two diagnostics: 44799 44800 demo.c:42:4: error: main message 44801 foo) 44802 ^ 44803 demo.c:40:2: note: message for secondary 44804 ( 44805 ^ 44806 4480727.1.7 Location Information 44808--------------------------- 44809 44810GCC's 'location_t' type can support both ordinary locations, and 44811locations relating to a macro expansion. 44812 44813 As of GCC 6, ordinary locations changed from supporting just a point in 44814the user's source code to supporting three points: the "caret" location, 44815plus a start and a finish: 44816 44817 a = foo && bar; 44818 ~~~~^~~~~~ 44819 | | | 44820 | | finish 44821 | caret 44822 start 44823 44824 Tokens coming out of libcpp have locations of the form 'caret == 44825start', such as for 'foo' here: 44826 44827 a = foo && bar; 44828 ^~~ 44829 | | 44830 | finish 44831 caret == start 44832 44833 Compound expressions should be reported using the location of the 44834expression as a whole, rather than just of one token within it. 44835 44836 For example, in '-Wformat', rather than underlining just the first 44837token of a bad argument: 44838 44839 printf("hello %i %s", (long)0, "world"); 44840 ~^ ~ 44841 %li 44842 44843the whole of the expression should be underlined, so that the user can 44844easily identify what is being referred to: 44845 44846 printf("hello %i %s", (long)0, "world"); 44847 ~^ ~~~~~~~ 44848 %li 44849 44850 Avoid using the 'input_location' global, and the diagnostic functions 44851that implicitly use it--use 'error_at' and 'warning_at' rather than 44852'error' and 'warning', and provide the most appropriate 'location_t' 44853value available at that phase of the compilation. It's possible to 44854supply secondary 'location_t' values via 'rich_location'. 44855 44856For example, in the example of imprecise wording above, generating the 44857diagnostic using 'warning': 44858 44859 // BAD: implicitly uses input_location 44860 warning (OPT_Wattributes, "%qE attribute ignored", name); 44861 44862leads to: 44863 44864 // BAD: uses input_location 44865 demo.c:1:1: warning: 'noinline' attribute ignored [-Wattributes] 44866 1 | int foo __attribute__((noinline)); 44867 | ^~~ 44868 44869which thus happened to use the location of the 'int' token, rather than 44870that of the attribute. Using 'warning_at' with the location of the 44871attribute, providing the location of the declaration in question as a 44872secondary location, and adding a note: 44873 44874 auto_diagnostic_group d; 44875 gcc_rich_location richloc (attrib_loc); 44876 richloc.add_range (decl_loc); 44877 if (warning_at (OPT_Wattributes, &richloc, 44878 "attribute %qE on variable %qE was ignored", name)) 44879 inform (attrib_loc, "attribute %qE is only applicable to functions"); 44880 44881would lead to: 44882 44883 // OK: use location of attribute, with a secondary location 44884 demo.c:1:24: warning: attribute 'noinline' on variable 'foo' was 44885 ignored [-Wattributes] 44886 1 | int foo __attribute__((noinline)); 44887 | ~~~ ~~~~~~~~~~~~~~~^~~~~~~~~ 44888 demo.c:1:24: note: attribute 'noinline' is only applicable to functions 44889 4489027.1.8 Coding Conventions 44891------------------------- 44892 44893See the diagnostics section 44894(https://gcc.gnu.org/codingconventions.html#Diagnostics) of the GCC 44895coding conventions. 44896 44897 In the C++ front end, when comparing two types in a message, use '%H' 44898and '%I' rather than '%T', as this allows the diagnostics subsystem to 44899highlight differences between template-based types. For example, rather 44900than using '%qT': 44901 44902 // BAD: a pair of %qT used in C++ front end for type comparison 44903 error_at (loc, "could not convert %qE from %qT to %qT", expr, 44904 TREE_TYPE (expr), type); 44905 44906which could lead to: 44907 44908 error: could not convert 'map<int, double>()' from 'map<int,double>' 44909 to 'map<int,int>' 44910 44911using '%H' and '%I' (via '%qH' and '%qI'): 44912 44913 // OK: compare types in C++ front end via %qH and %qI 44914 error_at (loc, "could not convert %qE from %qH to %qI", expr, 44915 TREE_TYPE (expr), type); 44916 44917allows the above output to be simplified to: 44918 44919 error: could not convert 'map<int, double>()' from 'map<[...],double>' 44920 to 'map<[...],int>' 44921 44922where the 'double' and 'int' are colorized to highlight them. 44923 4492427.1.9 Group logically-related diagnostics 44925------------------------------------------ 44926 44927Use 'auto_diagnostic_group' when issuing multiple related diagnostics 44928(seen in various examples on this page). This informs the diagnostic 44929subsystem that all diagnostics issued within the lifetime of the 44930'auto_diagnostic_group' are related. For example, 44931'-fdiagnostics-format=json' will treat the first diagnostic emitted 44932within the group as a top-level diagnostic, and all subsequent 44933diagnostics within the group as its children. 44934 4493527.1.10 Quoting 44936--------------- 44937 44938Text should be quoted by either using the 'q' modifier in a directive 44939such as '%qE', or by enclosing the quoted text in a pair of '%<' and 44940'%>' directives, and never by using explicit quote characters. The 44941directives handle the appropriate quote characters for each language and 44942apply the correct color or highlighting. 44943 44944 The following elements should be quoted in GCC diagnostics: 44945 44946 * Language keywords. 44947 * Tokens. 44948 * Boolean, numerical, character, and string constants that appear in 44949 the source code. 44950 * Identifiers, including function, macro, type, and variable names. 44951 44952 Other elements such as numbers that do not refer to numeric constants 44953that appear in the source code should not be quoted. For example, in 44954the message: 44955 44956 argument %d of %qE must be a pointer type 44957 44958since the argument number does not refer to a numerical constant in the 44959source code it should not be quoted. 44960 4496127.1.11 Spelling and Terminology 44962-------------------------------- 44963 44964See the terminology and markup 44965(https://gcc.gnu.org/codingconventions.html#Spelling Spelling) section 44966of the GCC coding conventions. 44967 4496827.1.12 Fix-it hints 44969-------------------- 44970 44971GCC's diagnostic subsystem can emit "fix-it hints": small suggested 44972edits to the user's source code. 44973 44974 They are printed by default underneath the code in question. They can 44975also be viewed via '-fdiagnostics-generate-patch' and 44976'-fdiagnostics-parseable-fixits'. With the latter, an IDE ought to be 44977able to offer to automatically apply the suggested fix. 44978 44979 Fix-it hints contain code fragments, and thus they should not be marked 44980for translation. 44981 44982 Fix-it hints can be added to a diagnostic by using a 'rich_location' 44983rather than a 'location_t' - the fix-it hints are added to the 44984'rich_location' using one of the various 'add_fixit' member functions of 44985'rich_location'. They are documented with 'rich_location' in 44986'libcpp/line-map.h'. It's easiest to use the 'gcc_rich_location' 44987subclass of 'rich_location' found in 'gcc-rich-location.h', as this 44988implicitly supplies the 'line_table' variable. 44989 44990 For example: 44991 44992 if (const char *suggestion = hint.suggestion ()) 44993 { 44994 gcc_rich_location richloc (location); 44995 richloc.add_fixit_replace (suggestion); 44996 error_at (&richloc, 44997 "%qE does not name a type; did you mean %qs?", 44998 id, suggestion); 44999 } 45000 45001which can lead to: 45002 45003 spellcheck-typenames.C:73:1: error: 'singed' does not name a type; did 45004 you mean 'signed'? 45005 73 | singed char ch; 45006 | ^~~~~~ 45007 | signed 45008 45009 Non-trivial edits can be built up by adding multiple fix-it hints to 45010one 'rich_location'. It's best to express the edits in terms of the 45011locations of individual tokens. Various handy functions for adding 45012fix-it hints for idiomatic C and C++ can be seen in 45013'gcc-rich-location.h'. 45014 4501527.1.12.1 Fix-it hints should work 45016.................................. 45017 45018When implementing a fix-it hint, please verify that the suggested edit 45019leads to fixed, compilable code. (Unfortunately, this currently must be 45020done by hand using '-fdiagnostics-generate-patch'. It would be good to 45021have an automated way of verifying that fix-it hints actually fix the 45022code). 45023 45024 For example, a "gotcha" here is to forget to add a space when adding a 45025missing reserved word. Consider a C++ fix-it hint that adds 'typename' 45026in front of a template declaration. A naive way to implement this might 45027be: 45028 45029 gcc_rich_location richloc (loc); 45030 // BAD: insertion is missing a trailing space 45031 richloc.add_fixit_insert_before ("typename"); 45032 error_at (&richloc, "need %<typename%> before %<%T::%E%> because " 45033 "%qT is a dependent scope", 45034 parser->scope, id, parser->scope); 45035 45036When applied to the code, this might lead to: 45037 45038 T::type x; 45039 45040being "corrected" to: 45041 45042 typenameT::type x; 45043 45044In this case, the correct thing to do is to add a trailing space after 45045'typename': 45046 45047 gcc_rich_location richloc (loc); 45048 // OK: note that here we have a trailing space 45049 richloc.add_fixit_insert_before ("typename "); 45050 error_at (&richloc, "need %<typename%> before %<%T::%E%> because " 45051 "%qT is a dependent scope", 45052 parser->scope, id, parser->scope); 45053 45054leading to this corrected code: 45055 45056 typename T::type x; 45057 4505827.1.12.2 Express deletion in terms of deletion, not replacement 45059................................................................ 45060 45061It's best to express deletion suggestions in terms of deletion fix-it 45062hints, rather than replacement fix-it hints. For example, consider 45063this: 45064 45065 auto_diagnostic_group d; 45066 gcc_rich_location richloc (location_of (retval)); 45067 tree name = DECL_NAME (arg); 45068 richloc.add_fixit_replace (IDENTIFIER_POINTER (name)); 45069 warning_at (&richloc, OPT_Wredundant_move, 45070 "redundant move in return statement"); 45071 45072which is intended to e.g. replace a 'std::move' with the underlying 45073value: 45074 45075 return std::move (retval); 45076 ~~~~~~~~~~^~~~~~~~ 45077 retval 45078 45079where the change has been expressed as replacement, replacing with the 45080name of the declaration. This works for simple cases, but consider this 45081case: 45082 45083 #ifdef SOME_CONFIG_FLAG 45084 # define CONFIGURY_GLOBAL global_a 45085 #else 45086 # define CONFIGURY_GLOBAL global_b 45087 #endif 45088 45089 int fn () 45090 { 45091 return std::move (CONFIGURY_GLOBAL /* some comment */); 45092 } 45093 45094The above implementation erroneously strips out the macro and the 45095comment in the fix-it hint: 45096 45097 return std::move (CONFIGURY_GLOBAL /* some comment */); 45098 ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 45099 global_a 45100 45101and thus this resulting code: 45102 45103 return global_a; 45104 45105It's better to do deletions in terms of deletions; deleting the 45106'std::move (' and the trailing close-paren, leading to this: 45107 45108 return std::move (CONFIGURY_GLOBAL /* some comment */); 45109 ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 45110 CONFIGURY_GLOBAL /* some comment */ 45111 45112and thus this result: 45113 45114 return CONFIGURY_GLOBAL /* some comment */; 45115 45116Unfortunately, the pertinent 'location_t' values are not always 45117available. 45118 4511927.1.12.3 Multiple suggestions 45120.............................. 45121 45122In the rare cases where you need to suggest more than one mutually 45123exclusive solution to a problem, this can be done by emitting multiple 45124notes and calling 'rich_location::fixits_cannot_be_auto_applied' on each 45125note's 'rich_location'. If this is called, then the fix-it hints in the 45126'rich_location' will be printed, but will not be added to generated 45127patches. 45128 45129 45130File: gccint.info, Node: Guidelines for Options, Prev: Guidelines for Diagnostics, Up: User Experience Guidelines 45131 4513227.2 Guidelines for Options 45133=========================== 45134 45135 45136File: gccint.info, Node: Funding, Next: GNU Project, Prev: User Experience Guidelines, Up: Top 45137 45138Funding Free Software 45139********************* 45140 45141If you want to have more free software a few years from now, it makes 45142sense for you to help encourage people to contribute funds for its 45143development. The most effective approach known is to encourage 45144commercial redistributors to donate. 45145 45146 Users of free software systems can boost the pace of development by 45147encouraging for-a-fee distributors to donate part of their selling price 45148to free software developers--the Free Software Foundation, and others. 45149 45150 The way to convince distributors to do this is to demand it and expect 45151it from them. So when you compare distributors, judge them partly by 45152how much they give to free software development. Show distributors they 45153must compete to be the one who gives the most. 45154 45155 To make this approach work, you must insist on numbers that you can 45156compare, such as, "We will donate ten dollars to the Frobnitz project 45157for each disk sold." Don't be satisfied with a vague promise, such as 45158"A portion of the profits are donated," since it doesn't give a basis 45159for comparison. 45160 45161 Even a precise fraction "of the profits from this disk" is not very 45162meaningful, since creative accounting and unrelated business decisions 45163can greatly alter what fraction of the sales price counts as profit. If 45164the price you pay is $50, ten percent of the profit is probably less 45165than a dollar; it might be a few cents, or nothing at all. 45166 45167 Some redistributors do development work themselves. This is useful 45168too; but to keep everyone honest, you need to inquire how much they do, 45169and what kind. Some kinds of development make much more long-term 45170difference than others. For example, maintaining a separate version of 45171a program contributes very little; maintaining the standard version of a 45172program for the whole community contributes much. Easy new ports 45173contribute little, since someone else would surely do them; difficult 45174ports such as adding a new CPU to the GNU Compiler Collection contribute 45175more; major new features or packages contribute the most. 45176 45177 By establishing the idea that supporting further development is "the 45178proper thing to do" when distributing free software for a fee, we can 45179assure a steady flow of resources into making more free software. 45180 45181 Copyright (C) 1994 Free Software Foundation, Inc. 45182 Verbatim copying and redistribution of this section is permitted 45183 without royalty; alteration is not permitted. 45184 45185 45186File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top 45187 45188The GNU Project and GNU/Linux 45189***************************** 45190 45191The GNU Project was launched in 1984 to develop a complete Unix-like 45192operating system which is free software: the GNU system. (GNU is a 45193recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".) 45194Variants of the GNU operating system, which use the kernel Linux, are 45195now widely used; though these systems are often referred to as "Linux", 45196they are more accurately called GNU/Linux systems. 45197 45198 For more information, see: 45199 <http://www.gnu.org/> 45200 <http://www.gnu.org/gnu/linux-and-gnu.html> 45201 45202 45203File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top 45204 45205GNU General Public License 45206************************** 45207 45208 Version 3, 29 June 2007 45209 45210 Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/> 45211 45212 Everyone is permitted to copy and distribute verbatim copies of this 45213 license document, but changing it is not allowed. 45214 45215Preamble 45216======== 45217 45218The GNU General Public License is a free, copyleft license for software 45219and other kinds of works. 45220 45221 The licenses for most software and other practical works are designed 45222to take away your freedom to share and change the works. By contrast, 45223the GNU General Public License is intended to guarantee your freedom to 45224share and change all versions of a program-to make sure it remains free 45225software for all its users. We, the Free Software Foundation, use the 45226GNU General Public License for most of our software; it applies also to 45227any other work released this way by its authors. You can apply it to 45228your programs, too. 45229 45230 When we speak of free software, we are referring to freedom, not price. 45231Our General Public Licenses are designed to make sure that you have the 45232freedom to distribute copies of free software (and charge for them if 45233you wish), that you receive source code or can get it if you want it, 45234that you can change the software or use pieces of it in new free 45235programs, and that you know you can do these things. 45236 45237 To protect your rights, we need to prevent others from denying you 45238these rights or asking you to surrender the rights. Therefore, you have 45239certain responsibilities if you distribute copies of the software, or if 45240you modify it: responsibilities to respect the freedom of others. 45241 45242 For example, if you distribute copies of such a program, whether gratis 45243or for a fee, you must pass on to the recipients the same freedoms that 45244you received. You must make sure that they, too, receive or can get the 45245source code. And you must show them these terms so they know their 45246rights. 45247 45248 Developers that use the GNU GPL protect your rights with two steps: (1) 45249assert copyright on the software, and (2) offer you this License giving 45250you legal permission to copy, distribute and/or modify it. 45251 45252 For the developers' and authors' protection, the GPL clearly explains 45253that there is no warranty for this free software. For both users' and 45254authors' sake, the GPL requires that modified versions be marked as 45255changed, so that their problems will not be attributed erroneously to 45256authors of previous versions. 45257 45258 Some devices are designed to deny users access to install or run 45259modified versions of the software inside them, although the manufacturer 45260can do so. This is fundamentally incompatible with the aim of 45261protecting users' freedom to change the software. The systematic 45262pattern of such abuse occurs in the area of products for individuals to 45263use, which is precisely where it is most unacceptable. Therefore, we 45264have designed this version of the GPL to prohibit the practice for those 45265products. If such problems arise substantially in other domains, we 45266stand ready to extend this provision to those domains in future versions 45267of the GPL, as needed to protect the freedom of users. 45268 45269 Finally, every program is threatened constantly by software patents. 45270States should not allow patents to restrict development and use of 45271software on general-purpose computers, but in those that do, we wish to 45272avoid the special danger that patents applied to a free program could 45273make it effectively proprietary. To prevent this, the GPL assures that 45274patents cannot be used to render the program non-free. 45275 45276 The precise terms and conditions for copying, distribution and 45277modification follow. 45278 45279TERMS AND CONDITIONS 45280==================== 45281 45282 0. Definitions. 45283 45284 "This License" refers to version 3 of the GNU General Public 45285 License. 45286 45287 "Copyright" also means copyright-like laws that apply to other 45288 kinds of works, such as semiconductor masks. 45289 45290 "The Program" refers to any copyrightable work licensed under this 45291 License. Each licensee is addressed as "you". "Licensees" and 45292 "recipients" may be individuals or organizations. 45293 45294 To "modify" a work means to copy from or adapt all or part of the 45295 work in a fashion requiring copyright permission, other than the 45296 making of an exact copy. The resulting work is called a "modified 45297 version" of the earlier work or a work "based on" the earlier work. 45298 45299 A "covered work" means either the unmodified Program or a work 45300 based on the Program. 45301 45302 To "propagate" a work means to do anything with it that, without 45303 permission, would make you directly or secondarily liable for 45304 infringement under applicable copyright law, except executing it on 45305 a computer or modifying a private copy. Propagation includes 45306 copying, distribution (with or without modification), making 45307 available to the public, and in some countries other activities as 45308 well. 45309 45310 To "convey" a work means any kind of propagation that enables other 45311 parties to make or receive copies. Mere interaction with a user 45312 through a computer network, with no transfer of a copy, is not 45313 conveying. 45314 45315 An interactive user interface displays "Appropriate Legal Notices" 45316 to the extent that it includes a convenient and prominently visible 45317 feature that (1) displays an appropriate copyright notice, and (2) 45318 tells the user that there is no warranty for the work (except to 45319 the extent that warranties are provided), that licensees may convey 45320 the work under this License, and how to view a copy of this 45321 License. If the interface presents a list of user commands or 45322 options, such as a menu, a prominent item in the list meets this 45323 criterion. 45324 45325 1. Source Code. 45326 45327 The "source code" for a work means the preferred form of the work 45328 for making modifications to it. "Object code" means any non-source 45329 form of a work. 45330 45331 A "Standard Interface" means an interface that either is an 45332 official standard defined by a recognized standards body, or, in 45333 the case of interfaces specified for a particular programming 45334 language, one that is widely used among developers working in that 45335 language. 45336 45337 The "System Libraries" of an executable work include anything, 45338 other than the work as a whole, that (a) is included in the normal 45339 form of packaging a Major Component, but which is not part of that 45340 Major Component, and (b) serves only to enable use of the work with 45341 that Major Component, or to implement a Standard Interface for 45342 which an implementation is available to the public in source code 45343 form. A "Major Component", in this context, means a major 45344 essential component (kernel, window system, and so on) of the 45345 specific operating system (if any) on which the executable work 45346 runs, or a compiler used to produce the work, or an object code 45347 interpreter used to run it. 45348 45349 The "Corresponding Source" for a work in object code form means all 45350 the source code needed to generate, install, and (for an executable 45351 work) run the object code and to modify the work, including scripts 45352 to control those activities. However, it does not include the 45353 work's System Libraries, or general-purpose tools or generally 45354 available free programs which are used unmodified in performing 45355 those activities but which are not part of the work. For example, 45356 Corresponding Source includes interface definition files associated 45357 with source files for the work, and the source code for shared 45358 libraries and dynamically linked subprograms that the work is 45359 specifically designed to require, such as by intimate data 45360 communication or control flow between those subprograms and other 45361 parts of the work. 45362 45363 The Corresponding Source need not include anything that users can 45364 regenerate automatically from other parts of the Corresponding 45365 Source. 45366 45367 The Corresponding Source for a work in source code form is that 45368 same work. 45369 45370 2. Basic Permissions. 45371 45372 All rights granted under this License are granted for the term of 45373 copyright on the Program, and are irrevocable provided the stated 45374 conditions are met. This License explicitly affirms your unlimited 45375 permission to run the unmodified Program. The output from running 45376 a covered work is covered by this License only if the output, given 45377 its content, constitutes a covered work. This License acknowledges 45378 your rights of fair use or other equivalent, as provided by 45379 copyright law. 45380 45381 You may make, run and propagate covered works that you do not 45382 convey, without conditions so long as your license otherwise 45383 remains in force. You may convey covered works to others for the 45384 sole purpose of having them make modifications exclusively for you, 45385 or provide you with facilities for running those works, provided 45386 that you comply with the terms of this License in conveying all 45387 material for which you do not control copyright. Those thus making 45388 or running the covered works for you must do so exclusively on your 45389 behalf, under your direction and control, on terms that prohibit 45390 them from making any copies of your copyrighted material outside 45391 their relationship with you. 45392 45393 Conveying under any other circumstances is permitted solely under 45394 the conditions stated below. Sublicensing is not allowed; section 45395 10 makes it unnecessary. 45396 45397 3. Protecting Users' Legal Rights From Anti-Circumvention Law. 45398 45399 No covered work shall be deemed part of an effective technological 45400 measure under any applicable law fulfilling obligations under 45401 article 11 of the WIPO copyright treaty adopted on 20 December 45402 1996, or similar laws prohibiting or restricting circumvention of 45403 such measures. 45404 45405 When you convey a covered work, you waive any legal power to forbid 45406 circumvention of technological measures to the extent such 45407 circumvention is effected by exercising rights under this License 45408 with respect to the covered work, and you disclaim any intention to 45409 limit operation or modification of the work as a means of 45410 enforcing, against the work's users, your or third parties' legal 45411 rights to forbid circumvention of technological measures. 45412 45413 4. Conveying Verbatim Copies. 45414 45415 You may convey verbatim copies of the Program's source code as you 45416 receive it, in any medium, provided that you conspicuously and 45417 appropriately publish on each copy an appropriate copyright notice; 45418 keep intact all notices stating that this License and any 45419 non-permissive terms added in accord with section 7 apply to the 45420 code; keep intact all notices of the absence of any warranty; and 45421 give all recipients a copy of this License along with the Program. 45422 45423 You may charge any price or no price for each copy that you convey, 45424 and you may offer support or warranty protection for a fee. 45425 45426 5. Conveying Modified Source Versions. 45427 45428 You may convey a work based on the Program, or the modifications to 45429 produce it from the Program, in the form of source code under the 45430 terms of section 4, provided that you also meet all of these 45431 conditions: 45432 45433 a. The work must carry prominent notices stating that you 45434 modified it, and giving a relevant date. 45435 45436 b. The work must carry prominent notices stating that it is 45437 released under this License and any conditions added under 45438 section 7. This requirement modifies the requirement in 45439 section 4 to "keep intact all notices". 45440 45441 c. You must license the entire work, as a whole, under this 45442 License to anyone who comes into possession of a copy. This 45443 License will therefore apply, along with any applicable 45444 section 7 additional terms, to the whole of the work, and all 45445 its parts, regardless of how they are packaged. This License 45446 gives no permission to license the work in any other way, but 45447 it does not invalidate such permission if you have separately 45448 received it. 45449 45450 d. If the work has interactive user interfaces, each must display 45451 Appropriate Legal Notices; however, if the Program has 45452 interactive interfaces that do not display Appropriate Legal 45453 Notices, your work need not make them do so. 45454 45455 A compilation of a covered work with other separate and independent 45456 works, which are not by their nature extensions of the covered 45457 work, and which are not combined with it such as to form a larger 45458 program, in or on a volume of a storage or distribution medium, is 45459 called an "aggregate" if the compilation and its resulting 45460 copyright are not used to limit the access or legal rights of the 45461 compilation's users beyond what the individual works permit. 45462 Inclusion of a covered work in an aggregate does not cause this 45463 License to apply to the other parts of the aggregate. 45464 45465 6. Conveying Non-Source Forms. 45466 45467 You may convey a covered work in object code form under the terms 45468 of sections 4 and 5, provided that you also convey the 45469 machine-readable Corresponding Source under the terms of this 45470 License, in one of these ways: 45471 45472 a. Convey the object code in, or embodied in, a physical product 45473 (including a physical distribution medium), accompanied by the 45474 Corresponding Source fixed on a durable physical medium 45475 customarily used for software interchange. 45476 45477 b. Convey the object code in, or embodied in, a physical product 45478 (including a physical distribution medium), accompanied by a 45479 written offer, valid for at least three years and valid for as 45480 long as you offer spare parts or customer support for that 45481 product model, to give anyone who possesses the object code 45482 either (1) a copy of the Corresponding Source for all the 45483 software in the product that is covered by this License, on a 45484 durable physical medium customarily used for software 45485 interchange, for a price no more than your reasonable cost of 45486 physically performing this conveying of source, or (2) access 45487 to copy the Corresponding Source from a network server at no 45488 charge. 45489 45490 c. Convey individual copies of the object code with a copy of the 45491 written offer to provide the Corresponding Source. This 45492 alternative is allowed only occasionally and noncommercially, 45493 and only if you received the object code with such an offer, 45494 in accord with subsection 6b. 45495 45496 d. Convey the object code by offering access from a designated 45497 place (gratis or for a charge), and offer equivalent access to 45498 the Corresponding Source in the same way through the same 45499 place at no further charge. You need not require recipients 45500 to copy the Corresponding Source along with the object code. 45501 If the place to copy the object code is a network server, the 45502 Corresponding Source may be on a different server (operated by 45503 you or a third party) that supports equivalent copying 45504 facilities, provided you maintain clear directions next to the 45505 object code saying where to find the Corresponding Source. 45506 Regardless of what server hosts the Corresponding Source, you 45507 remain obligated to ensure that it is available for as long as 45508 needed to satisfy these requirements. 45509 45510 e. Convey the object code using peer-to-peer transmission, 45511 provided you inform other peers where the object code and 45512 Corresponding Source of the work are being offered to the 45513 general public at no charge under subsection 6d. 45514 45515 A separable portion of the object code, whose source code is 45516 excluded from the Corresponding Source as a System Library, need 45517 not be included in conveying the object code work. 45518 45519 A "User Product" is either (1) a "consumer product", which means 45520 any tangible personal property which is normally used for personal, 45521 family, or household purposes, or (2) anything designed or sold for 45522 incorporation into a dwelling. In determining whether a product is 45523 a consumer product, doubtful cases shall be resolved in favor of 45524 coverage. For a particular product received by a particular user, 45525 "normally used" refers to a typical or common use of that class of 45526 product, regardless of the status of the particular user or of the 45527 way in which the particular user actually uses, or expects or is 45528 expected to use, the product. A product is a consumer product 45529 regardless of whether the product has substantial commercial, 45530 industrial or non-consumer uses, unless such uses represent the 45531 only significant mode of use of the product. 45532 45533 "Installation Information" for a User Product means any methods, 45534 procedures, authorization keys, or other information required to 45535 install and execute modified versions of a covered work in that 45536 User Product from a modified version of its Corresponding Source. 45537 The information must suffice to ensure that the continued 45538 functioning of the modified object code is in no case prevented or 45539 interfered with solely because modification has been made. 45540 45541 If you convey an object code work under this section in, or with, 45542 or specifically for use in, a User Product, and the conveying 45543 occurs as part of a transaction in which the right of possession 45544 and use of the User Product is transferred to the recipient in 45545 perpetuity or for a fixed term (regardless of how the transaction 45546 is characterized), the Corresponding Source conveyed under this 45547 section must be accompanied by the Installation Information. But 45548 this requirement does not apply if neither you nor any third party 45549 retains the ability to install modified object code on the User 45550 Product (for example, the work has been installed in ROM). 45551 45552 The requirement to provide Installation Information does not 45553 include a requirement to continue to provide support service, 45554 warranty, or updates for a work that has been modified or installed 45555 by the recipient, or for the User Product in which it has been 45556 modified or installed. Access to a network may be denied when the 45557 modification itself materially and adversely affects the operation 45558 of the network or violates the rules and protocols for 45559 communication across the network. 45560 45561 Corresponding Source conveyed, and Installation Information 45562 provided, in accord with this section must be in a format that is 45563 publicly documented (and with an implementation available to the 45564 public in source code form), and must require no special password 45565 or key for unpacking, reading or copying. 45566 45567 7. Additional Terms. 45568 45569 "Additional permissions" are terms that supplement the terms of 45570 this License by making exceptions from one or more of its 45571 conditions. Additional permissions that are applicable to the 45572 entire Program shall be treated as though they were included in 45573 this License, to the extent that they are valid under applicable 45574 law. If additional permissions apply only to part of the Program, 45575 that part may be used separately under those permissions, but the 45576 entire Program remains governed by this License without regard to 45577 the additional permissions. 45578 45579 When you convey a copy of a covered work, you may at your option 45580 remove any additional permissions from that copy, or from any part 45581 of it. (Additional permissions may be written to require their own 45582 removal in certain cases when you modify the work.) You may place 45583 additional permissions on material, added by you to a covered work, 45584 for which you have or can give appropriate copyright permission. 45585 45586 Notwithstanding any other provision of this License, for material 45587 you add to a covered work, you may (if authorized by the copyright 45588 holders of that material) supplement the terms of this License with 45589 terms: 45590 45591 a. Disclaiming warranty or limiting liability differently from 45592 the terms of sections 15 and 16 of this License; or 45593 45594 b. Requiring preservation of specified reasonable legal notices 45595 or author attributions in that material or in the Appropriate 45596 Legal Notices displayed by works containing it; or 45597 45598 c. Prohibiting misrepresentation of the origin of that material, 45599 or requiring that modified versions of such material be marked 45600 in reasonable ways as different from the original version; or 45601 45602 d. Limiting the use for publicity purposes of names of licensors 45603 or authors of the material; or 45604 45605 e. Declining to grant rights under trademark law for use of some 45606 trade names, trademarks, or service marks; or 45607 45608 f. Requiring indemnification of licensors and authors of that 45609 material by anyone who conveys the material (or modified 45610 versions of it) with contractual assumptions of liability to 45611 the recipient, for any liability that these contractual 45612 assumptions directly impose on those licensors and authors. 45613 45614 All other non-permissive additional terms are considered "further 45615 restrictions" within the meaning of section 10. If the Program as 45616 you received it, or any part of it, contains a notice stating that 45617 it is governed by this License along with a term that is a further 45618 restriction, you may remove that term. If a license document 45619 contains a further restriction but permits relicensing or conveying 45620 under this License, you may add to a covered work material governed 45621 by the terms of that license document, provided that the further 45622 restriction does not survive such relicensing or conveying. 45623 45624 If you add terms to a covered work in accord with this section, you 45625 must place, in the relevant source files, a statement of the 45626 additional terms that apply to those files, or a notice indicating 45627 where to find the applicable terms. 45628 45629 Additional terms, permissive or non-permissive, may be stated in 45630 the form of a separately written license, or stated as exceptions; 45631 the above requirements apply either way. 45632 45633 8. Termination. 45634 45635 You may not propagate or modify a covered work except as expressly 45636 provided under this License. Any attempt otherwise to propagate or 45637 modify it is void, and will automatically terminate your rights 45638 under this License (including any patent licenses granted under the 45639 third paragraph of section 11). 45640 45641 However, if you cease all violation of this License, then your 45642 license from a particular copyright holder is reinstated (a) 45643 provisionally, unless and until the copyright holder explicitly and 45644 finally terminates your license, and (b) permanently, if the 45645 copyright holder fails to notify you of the violation by some 45646 reasonable means prior to 60 days after the cessation. 45647 45648 Moreover, your license from a particular copyright holder is 45649 reinstated permanently if the copyright holder notifies you of the 45650 violation by some reasonable means, this is the first time you have 45651 received notice of violation of this License (for any work) from 45652 that copyright holder, and you cure the violation prior to 30 days 45653 after your receipt of the notice. 45654 45655 Termination of your rights under this section does not terminate 45656 the licenses of parties who have received copies or rights from you 45657 under this License. If your rights have been terminated and not 45658 permanently reinstated, you do not qualify to receive new licenses 45659 for the same material under section 10. 45660 45661 9. Acceptance Not Required for Having Copies. 45662 45663 You are not required to accept this License in order to receive or 45664 run a copy of the Program. Ancillary propagation of a covered work 45665 occurring solely as a consequence of using peer-to-peer 45666 transmission to receive a copy likewise does not require 45667 acceptance. However, nothing other than this License grants you 45668 permission to propagate or modify any covered work. These actions 45669 infringe copyright if you do not accept this License. Therefore, 45670 by modifying or propagating a covered work, you indicate your 45671 acceptance of this License to do so. 45672 45673 10. Automatic Licensing of Downstream Recipients. 45674 45675 Each time you convey a covered work, the recipient automatically 45676 receives a license from the original licensors, to run, modify and 45677 propagate that work, subject to this License. You are not 45678 responsible for enforcing compliance by third parties with this 45679 License. 45680 45681 An "entity transaction" is a transaction transferring control of an 45682 organization, or substantially all assets of one, or subdividing an 45683 organization, or merging organizations. If propagation of a 45684 covered work results from an entity transaction, each party to that 45685 transaction who receives a copy of the work also receives whatever 45686 licenses to the work the party's predecessor in interest had or 45687 could give under the previous paragraph, plus a right to possession 45688 of the Corresponding Source of the work from the predecessor in 45689 interest, if the predecessor has it or can get it with reasonable 45690 efforts. 45691 45692 You may not impose any further restrictions on the exercise of the 45693 rights granted or affirmed under this License. For example, you 45694 may not impose a license fee, royalty, or other charge for exercise 45695 of rights granted under this License, and you may not initiate 45696 litigation (including a cross-claim or counterclaim in a lawsuit) 45697 alleging that any patent claim is infringed by making, using, 45698 selling, offering for sale, or importing the Program or any portion 45699 of it. 45700 45701 11. Patents. 45702 45703 A "contributor" is a copyright holder who authorizes use under this 45704 License of the Program or a work on which the Program is based. 45705 The work thus licensed is called the contributor's "contributor 45706 version". 45707 45708 A contributor's "essential patent claims" are all patent claims 45709 owned or controlled by the contributor, whether already acquired or 45710 hereafter acquired, that would be infringed by some manner, 45711 permitted by this License, of making, using, or selling its 45712 contributor version, but do not include claims that would be 45713 infringed only as a consequence of further modification of the 45714 contributor version. For purposes of this definition, "control" 45715 includes the right to grant patent sublicenses in a manner 45716 consistent with the requirements of this License. 45717 45718 Each contributor grants you a non-exclusive, worldwide, 45719 royalty-free patent license under the contributor's essential 45720 patent claims, to make, use, sell, offer for sale, import and 45721 otherwise run, modify and propagate the contents of its contributor 45722 version. 45723 45724 In the following three paragraphs, a "patent license" is any 45725 express agreement or commitment, however denominated, not to 45726 enforce a patent (such as an express permission to practice a 45727 patent or covenant not to sue for patent infringement). To "grant" 45728 such a patent license to a party means to make such an agreement or 45729 commitment not to enforce a patent against the party. 45730 45731 If you convey a covered work, knowingly relying on a patent 45732 license, and the Corresponding Source of the work is not available 45733 for anyone to copy, free of charge and under the terms of this 45734 License, through a publicly available network server or other 45735 readily accessible means, then you must either (1) cause the 45736 Corresponding Source to be so available, or (2) arrange to deprive 45737 yourself of the benefit of the patent license for this particular 45738 work, or (3) arrange, in a manner consistent with the requirements 45739 of this License, to extend the patent license to downstream 45740 recipients. "Knowingly relying" means you have actual knowledge 45741 that, but for the patent license, your conveying the covered work 45742 in a country, or your recipient's use of the covered work in a 45743 country, would infringe one or more identifiable patents in that 45744 country that you have reason to believe are valid. 45745 45746 If, pursuant to or in connection with a single transaction or 45747 arrangement, you convey, or propagate by procuring conveyance of, a 45748 covered work, and grant a patent license to some of the parties 45749 receiving the covered work authorizing them to use, propagate, 45750 modify or convey a specific copy of the covered work, then the 45751 patent license you grant is automatically extended to all 45752 recipients of the covered work and works based on it. 45753 45754 A patent license is "discriminatory" if it does not include within 45755 the scope of its coverage, prohibits the exercise of, or is 45756 conditioned on the non-exercise of one or more of the rights that 45757 are specifically granted under this License. You may not convey a 45758 covered work if you are a party to an arrangement with a third 45759 party that is in the business of distributing software, under which 45760 you make payment to the third party based on the extent of your 45761 activity of conveying the work, and under which the third party 45762 grants, to any of the parties who would receive the covered work 45763 from you, a discriminatory patent license (a) in connection with 45764 copies of the covered work conveyed by you (or copies made from 45765 those copies), or (b) primarily for and in connection with specific 45766 products or compilations that contain the covered work, unless you 45767 entered into that arrangement, or that patent license was granted, 45768 prior to 28 March 2007. 45769 45770 Nothing in this License shall be construed as excluding or limiting 45771 any implied license or other defenses to infringement that may 45772 otherwise be available to you under applicable patent law. 45773 45774 12. No Surrender of Others' Freedom. 45775 45776 If conditions are imposed on you (whether by court order, agreement 45777 or otherwise) that contradict the conditions of this License, they 45778 do not excuse you from the conditions of this License. If you 45779 cannot convey a covered work so as to satisfy simultaneously your 45780 obligations under this License and any other pertinent obligations, 45781 then as a consequence you may not convey it at all. For example, 45782 if you agree to terms that obligate you to collect a royalty for 45783 further conveying from those to whom you convey the Program, the 45784 only way you could satisfy both those terms and this License would 45785 be to refrain entirely from conveying the Program. 45786 45787 13. Use with the GNU Affero General Public License. 45788 45789 Notwithstanding any other provision of this License, you have 45790 permission to link or combine any covered work with a work licensed 45791 under version 3 of the GNU Affero General Public License into a 45792 single combined work, and to convey the resulting work. The terms 45793 of this License will continue to apply to the part which is the 45794 covered work, but the special requirements of the GNU Affero 45795 General Public License, section 13, concerning interaction through 45796 a network will apply to the combination as such. 45797 45798 14. Revised Versions of this License. 45799 45800 The Free Software Foundation may publish revised and/or new 45801 versions of the GNU General Public License from time to time. Such 45802 new versions will be similar in spirit to the present version, but 45803 may differ in detail to address new problems or concerns. 45804 45805 Each version is given a distinguishing version number. If the 45806 Program specifies that a certain numbered version of the GNU 45807 General Public License "or any later version" applies to it, you 45808 have the option of following the terms and conditions either of 45809 that numbered version or of any later version published by the Free 45810 Software Foundation. If the Program does not specify a version 45811 number of the GNU General Public License, you may choose any 45812 version ever published by the Free Software Foundation. 45813 45814 If the Program specifies that a proxy can decide which future 45815 versions of the GNU General Public License can be used, that 45816 proxy's public statement of acceptance of a version permanently 45817 authorizes you to choose that version for the Program. 45818 45819 Later license versions may give you additional or different 45820 permissions. However, no additional obligations are imposed on any 45821 author or copyright holder as a result of your choosing to follow a 45822 later version. 45823 45824 15. Disclaimer of Warranty. 45825 45826 THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY 45827 APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE 45828 COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" 45829 WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, 45830 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 45831 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE 45832 RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. 45833 SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL 45834 NECESSARY SERVICING, REPAIR OR CORRECTION. 45835 45836 16. Limitation of Liability. 45837 45838 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN 45839 WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES 45840 AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR 45841 DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR 45842 CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE 45843 THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA 45844 BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD 45845 PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER 45846 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF 45847 THE POSSIBILITY OF SUCH DAMAGES. 45848 45849 17. Interpretation of Sections 15 and 16. 45850 45851 If the disclaimer of warranty and limitation of liability provided 45852 above cannot be given local legal effect according to their terms, 45853 reviewing courts shall apply local law that most closely 45854 approximates an absolute waiver of all civil liability in 45855 connection with the Program, unless a warranty or assumption of 45856 liability accompanies a copy of the Program in return for a fee. 45857 45858END OF TERMS AND CONDITIONS 45859=========================== 45860 45861How to Apply These Terms to Your New Programs 45862============================================= 45863 45864If you develop a new program, and you want it to be of the greatest 45865possible use to the public, the best way to achieve this is to make it 45866free software which everyone can redistribute and change under these 45867terms. 45868 45869 To do so, attach the following notices to the program. It is safest to 45870attach them to the start of each source file to most effectively state 45871the exclusion of warranty; and each file should have at least the 45872"copyright" line and a pointer to where the full notice is found. 45873 45874 ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES. 45875 Copyright (C) YEAR NAME OF AUTHOR 45876 45877 This program is free software: you can redistribute it and/or modify 45878 it under the terms of the GNU General Public License as published by 45879 the Free Software Foundation, either version 3 of the License, or (at 45880 your option) any later version. 45881 45882 This program is distributed in the hope that it will be useful, but 45883 WITHOUT ANY WARRANTY; without even the implied warranty of 45884 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU 45885 General Public License for more details. 45886 45887 You should have received a copy of the GNU General Public License 45888 along with this program. If not, see <http://www.gnu.org/licenses/>. 45889 45890 Also add information on how to contact you by electronic and paper 45891mail. 45892 45893 If the program does terminal interaction, make it output a short notice 45894like this when it starts in an interactive mode: 45895 45896 PROGRAM Copyright (C) YEAR NAME OF AUTHOR 45897 This program comes with ABSOLUTELY NO WARRANTY; for details type 'show w'. 45898 This is free software, and you are welcome to redistribute it 45899 under certain conditions; type 'show c' for details. 45900 45901 The hypothetical commands 'show w' and 'show c' should show the 45902appropriate parts of the General Public License. Of course, your 45903program's commands might be different; for a GUI interface, you would 45904use an "about box". 45905 45906 You should also get your employer (if you work as a programmer) or 45907school, if any, to sign a "copyright disclaimer" for the program, if 45908necessary. For more information on this, and how to apply and follow 45909the GNU GPL, see <http://www.gnu.org/licenses/>. 45910 45911 The GNU General Public License does not permit incorporating your 45912program into proprietary programs. If your program is a subroutine 45913library, you may consider it more useful to permit linking proprietary 45914applications with the library. If this is what you want to do, use the 45915GNU Lesser General Public License instead of this License. But first, 45916please read <http://www.gnu.org/philosophy/why-not-lgpl.html>. 45917 45918 45919File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top 45920 45921GNU Free Documentation License 45922****************************** 45923 45924 Version 1.3, 3 November 2008 45925 45926 Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. 45927 <http://fsf.org/> 45928 45929 Everyone is permitted to copy and distribute verbatim copies 45930 of this license document, but changing it is not allowed. 45931 45932 0. PREAMBLE 45933 45934 The purpose of this License is to make a manual, textbook, or other 45935 functional and useful document "free" in the sense of freedom: to 45936 assure everyone the effective freedom to copy and redistribute it, 45937 with or without modifying it, either commercially or 45938 noncommercially. Secondarily, this License preserves for the 45939 author and publisher a way to get credit for their work, while not 45940 being considered responsible for modifications made by others. 45941 45942 This License is a kind of "copyleft", which means that derivative 45943 works of the document must themselves be free in the same sense. 45944 It complements the GNU General Public License, which is a copyleft 45945 license designed for free software. 45946 45947 We have designed this License in order to use it for manuals for 45948 free software, because free software needs free documentation: a 45949 free program should come with manuals providing the same freedoms 45950 that the software does. But this License is not limited to 45951 software manuals; it can be used for any textual work, regardless 45952 of subject matter or whether it is published as a printed book. We 45953 recommend this License principally for works whose purpose is 45954 instruction or reference. 45955 45956 1. APPLICABILITY AND DEFINITIONS 45957 45958 This License applies to any manual or other work, in any medium, 45959 that contains a notice placed by the copyright holder saying it can 45960 be distributed under the terms of this License. Such a notice 45961 grants a world-wide, royalty-free license, unlimited in duration, 45962 to use that work under the conditions stated herein. The 45963 "Document", below, refers to any such manual or work. Any member 45964 of the public is a licensee, and is addressed as "you". You accept 45965 the license if you copy, modify or distribute the work in a way 45966 requiring permission under copyright law. 45967 45968 A "Modified Version" of the Document means any work containing the 45969 Document or a portion of it, either copied verbatim, or with 45970 modifications and/or translated into another language. 45971 45972 A "Secondary Section" is a named appendix or a front-matter section 45973 of the Document that deals exclusively with the relationship of the 45974 publishers or authors of the Document to the Document's overall 45975 subject (or to related matters) and contains nothing that could 45976 fall directly within that overall subject. (Thus, if the Document 45977 is in part a textbook of mathematics, a Secondary Section may not 45978 explain any mathematics.) The relationship could be a matter of 45979 historical connection with the subject or with related matters, or 45980 of legal, commercial, philosophical, ethical or political position 45981 regarding them. 45982 45983 The "Invariant Sections" are certain Secondary Sections whose 45984 titles are designated, as being those of Invariant Sections, in the 45985 notice that says that the Document is released under this License. 45986 If a section does not fit the above definition of Secondary then it 45987 is not allowed to be designated as Invariant. The Document may 45988 contain zero Invariant Sections. If the Document does not identify 45989 any Invariant Sections then there are none. 45990 45991 The "Cover Texts" are certain short passages of text that are 45992 listed, as Front-Cover Texts or Back-Cover Texts, in the notice 45993 that says that the Document is released under this License. A 45994 Front-Cover Text may be at most 5 words, and a Back-Cover Text may 45995 be at most 25 words. 45996 45997 A "Transparent" copy of the Document means a machine-readable copy, 45998 represented in a format whose specification is available to the 45999 general public, that is suitable for revising the document 46000 straightforwardly with generic text editors or (for images composed 46001 of pixels) generic paint programs or (for drawings) some widely 46002 available drawing editor, and that is suitable for input to text 46003 formatters or for automatic translation to a variety of formats 46004 suitable for input to text formatters. A copy made in an otherwise 46005 Transparent file format whose markup, or absence of markup, has 46006 been arranged to thwart or discourage subsequent modification by 46007 readers is not Transparent. An image format is not Transparent if 46008 used for any substantial amount of text. A copy that is not 46009 "Transparent" is called "Opaque". 46010 46011 Examples of suitable formats for Transparent copies include plain 46012 ASCII without markup, Texinfo input format, LaTeX input format, 46013 SGML or XML using a publicly available DTD, and standard-conforming 46014 simple HTML, PostScript or PDF designed for human modification. 46015 Examples of transparent image formats include PNG, XCF and JPG. 46016 Opaque formats include proprietary formats that can be read and 46017 edited only by proprietary word processors, SGML or XML for which 46018 the DTD and/or processing tools are not generally available, and 46019 the machine-generated HTML, PostScript or PDF produced by some word 46020 processors for output purposes only. 46021 46022 The "Title Page" means, for a printed book, the title page itself, 46023 plus such following pages as are needed to hold, legibly, the 46024 material this License requires to appear in the title page. For 46025 works in formats which do not have any title page as such, "Title 46026 Page" means the text near the most prominent appearance of the 46027 work's title, preceding the beginning of the body of the text. 46028 46029 The "publisher" means any person or entity that distributes copies 46030 of the Document to the public. 46031 46032 A section "Entitled XYZ" means a named subunit of the Document 46033 whose title either is precisely XYZ or contains XYZ in parentheses 46034 following text that translates XYZ in another language. (Here XYZ 46035 stands for a specific section name mentioned below, such as 46036 "Acknowledgements", "Dedications", "Endorsements", or "History".) 46037 To "Preserve the Title" of such a section when you modify the 46038 Document means that it remains a section "Entitled XYZ" according 46039 to this definition. 46040 46041 The Document may include Warranty Disclaimers next to the notice 46042 which states that this License applies to the Document. These 46043 Warranty Disclaimers are considered to be included by reference in 46044 this License, but only as regards disclaiming warranties: any other 46045 implication that these Warranty Disclaimers may have is void and 46046 has no effect on the meaning of this License. 46047 46048 2. VERBATIM COPYING 46049 46050 You may copy and distribute the Document in any medium, either 46051 commercially or noncommercially, provided that this License, the 46052 copyright notices, and the license notice saying this License 46053 applies to the Document are reproduced in all copies, and that you 46054 add no other conditions whatsoever to those of this License. You 46055 may not use technical measures to obstruct or control the reading 46056 or further copying of the copies you make or distribute. However, 46057 you may accept compensation in exchange for copies. If you 46058 distribute a large enough number of copies you must also follow the 46059 conditions in section 3. 46060 46061 You may also lend copies, under the same conditions stated above, 46062 and you may publicly display copies. 46063 46064 3. COPYING IN QUANTITY 46065 46066 If you publish printed copies (or copies in media that commonly 46067 have printed covers) of the Document, numbering more than 100, and 46068 the Document's license notice requires Cover Texts, you must 46069 enclose the copies in covers that carry, clearly and legibly, all 46070 these Cover Texts: Front-Cover Texts on the front cover, and 46071 Back-Cover Texts on the back cover. Both covers must also clearly 46072 and legibly identify you as the publisher of these copies. The 46073 front cover must present the full title with all words of the title 46074 equally prominent and visible. You may add other material on the 46075 covers in addition. Copying with changes limited to the covers, as 46076 long as they preserve the title of the Document and satisfy these 46077 conditions, can be treated as verbatim copying in other respects. 46078 46079 If the required texts for either cover are too voluminous to fit 46080 legibly, you should put the first ones listed (as many as fit 46081 reasonably) on the actual cover, and continue the rest onto 46082 adjacent pages. 46083 46084 If you publish or distribute Opaque copies of the Document 46085 numbering more than 100, you must either include a machine-readable 46086 Transparent copy along with each Opaque copy, or state in or with 46087 each Opaque copy a computer-network location from which the general 46088 network-using public has access to download using public-standard 46089 network protocols a complete Transparent copy of the Document, free 46090 of added material. If you use the latter option, you must take 46091 reasonably prudent steps, when you begin distribution of Opaque 46092 copies in quantity, to ensure that this Transparent copy will 46093 remain thus accessible at the stated location until at least one 46094 year after the last time you distribute an Opaque copy (directly or 46095 through your agents or retailers) of that edition to the public. 46096 46097 It is requested, but not required, that you contact the authors of 46098 the Document well before redistributing any large number of copies, 46099 to give them a chance to provide you with an updated version of the 46100 Document. 46101 46102 4. MODIFICATIONS 46103 46104 You may copy and distribute a Modified Version of the Document 46105 under the conditions of sections 2 and 3 above, provided that you 46106 release the Modified Version under precisely this License, with the 46107 Modified Version filling the role of the Document, thus licensing 46108 distribution and modification of the Modified Version to whoever 46109 possesses a copy of it. In addition, you must do these things in 46110 the Modified Version: 46111 46112 A. Use in the Title Page (and on the covers, if any) a title 46113 distinct from that of the Document, and from those of previous 46114 versions (which should, if there were any, be listed in the 46115 History section of the Document). You may use the same title 46116 as a previous version if the original publisher of that 46117 version gives permission. 46118 46119 B. List on the Title Page, as authors, one or more persons or 46120 entities responsible for authorship of the modifications in 46121 the Modified Version, together with at least five of the 46122 principal authors of the Document (all of its principal 46123 authors, if it has fewer than five), unless they release you 46124 from this requirement. 46125 46126 C. State on the Title page the name of the publisher of the 46127 Modified Version, as the publisher. 46128 46129 D. Preserve all the copyright notices of the Document. 46130 46131 E. Add an appropriate copyright notice for your modifications 46132 adjacent to the other copyright notices. 46133 46134 F. Include, immediately after the copyright notices, a license 46135 notice giving the public permission to use the Modified 46136 Version under the terms of this License, in the form shown in 46137 the Addendum below. 46138 46139 G. Preserve in that license notice the full lists of Invariant 46140 Sections and required Cover Texts given in the Document's 46141 license notice. 46142 46143 H. Include an unaltered copy of this License. 46144 46145 I. Preserve the section Entitled "History", Preserve its Title, 46146 and add to it an item stating at least the title, year, new 46147 authors, and publisher of the Modified Version as given on the 46148 Title Page. If there is no section Entitled "History" in the 46149 Document, create one stating the title, year, authors, and 46150 publisher of the Document as given on its Title Page, then add 46151 an item describing the Modified Version as stated in the 46152 previous sentence. 46153 46154 J. Preserve the network location, if any, given in the Document 46155 for public access to a Transparent copy of the Document, and 46156 likewise the network locations given in the Document for 46157 previous versions it was based on. These may be placed in the 46158 "History" section. You may omit a network location for a work 46159 that was published at least four years before the Document 46160 itself, or if the original publisher of the version it refers 46161 to gives permission. 46162 46163 K. For any section Entitled "Acknowledgements" or "Dedications", 46164 Preserve the Title of the section, and preserve in the section 46165 all the substance and tone of each of the contributor 46166 acknowledgements and/or dedications given therein. 46167 46168 L. Preserve all the Invariant Sections of the Document, unaltered 46169 in their text and in their titles. Section numbers or the 46170 equivalent are not considered part of the section titles. 46171 46172 M. Delete any section Entitled "Endorsements". Such a section 46173 may not be included in the Modified Version. 46174 46175 N. Do not retitle any existing section to be Entitled 46176 "Endorsements" or to conflict in title with any Invariant 46177 Section. 46178 46179 O. Preserve any Warranty Disclaimers. 46180 46181 If the Modified Version includes new front-matter sections or 46182 appendices that qualify as Secondary Sections and contain no 46183 material copied from the Document, you may at your option designate 46184 some or all of these sections as invariant. To do this, add their 46185 titles to the list of Invariant Sections in the Modified Version's 46186 license notice. These titles must be distinct from any other 46187 section titles. 46188 46189 You may add a section Entitled "Endorsements", provided it contains 46190 nothing but endorsements of your Modified Version by various 46191 parties--for example, statements of peer review or that the text 46192 has been approved by an organization as the authoritative 46193 definition of a standard. 46194 46195 You may add a passage of up to five words as a Front-Cover Text, 46196 and a passage of up to 25 words as a Back-Cover Text, to the end of 46197 the list of Cover Texts in the Modified Version. Only one passage 46198 of Front-Cover Text and one of Back-Cover Text may be added by (or 46199 through arrangements made by) any one entity. If the Document 46200 already includes a cover text for the same cover, previously added 46201 by you or by arrangement made by the same entity you are acting on 46202 behalf of, you may not add another; but you may replace the old 46203 one, on explicit permission from the previous publisher that added 46204 the old one. 46205 46206 The author(s) and publisher(s) of the Document do not by this 46207 License give permission to use their names for publicity for or to 46208 assert or imply endorsement of any Modified Version. 46209 46210 5. COMBINING DOCUMENTS 46211 46212 You may combine the Document with other documents released under 46213 this License, under the terms defined in section 4 above for 46214 modified versions, provided that you include in the combination all 46215 of the Invariant Sections of all of the original documents, 46216 unmodified, and list them all as Invariant Sections of your 46217 combined work in its license notice, and that you preserve all 46218 their Warranty Disclaimers. 46219 46220 The combined work need only contain one copy of this License, and 46221 multiple identical Invariant Sections may be replaced with a single 46222 copy. If there are multiple Invariant Sections with the same name 46223 but different contents, make the title of each such section unique 46224 by adding at the end of it, in parentheses, the name of the 46225 original author or publisher of that section if known, or else a 46226 unique number. Make the same adjustment to the section titles in 46227 the list of Invariant Sections in the license notice of the 46228 combined work. 46229 46230 In the combination, you must combine any sections Entitled 46231 "History" in the various original documents, forming one section 46232 Entitled "History"; likewise combine any sections Entitled 46233 "Acknowledgements", and any sections Entitled "Dedications". You 46234 must delete all sections Entitled "Endorsements." 46235 46236 6. COLLECTIONS OF DOCUMENTS 46237 46238 You may make a collection consisting of the Document and other 46239 documents released under this License, and replace the individual 46240 copies of this License in the various documents with a single copy 46241 that is included in the collection, provided that you follow the 46242 rules of this License for verbatim copying of each of the documents 46243 in all other respects. 46244 46245 You may extract a single document from such a collection, and 46246 distribute it individually under this License, provided you insert 46247 a copy of this License into the extracted document, and follow this 46248 License in all other respects regarding verbatim copying of that 46249 document. 46250 46251 7. AGGREGATION WITH INDEPENDENT WORKS 46252 46253 A compilation of the Document or its derivatives with other 46254 separate and independent documents or works, in or on a volume of a 46255 storage or distribution medium, is called an "aggregate" if the 46256 copyright resulting from the compilation is not used to limit the 46257 legal rights of the compilation's users beyond what the individual 46258 works permit. When the Document is included in an aggregate, this 46259 License does not apply to the other works in the aggregate which 46260 are not themselves derivative works of the Document. 46261 46262 If the Cover Text requirement of section 3 is applicable to these 46263 copies of the Document, then if the Document is less than one half 46264 of the entire aggregate, the Document's Cover Texts may be placed 46265 on covers that bracket the Document within the aggregate, or the 46266 electronic equivalent of covers if the Document is in electronic 46267 form. Otherwise they must appear on printed covers that bracket 46268 the whole aggregate. 46269 46270 8. TRANSLATION 46271 46272 Translation is considered a kind of modification, so you may 46273 distribute translations of the Document under the terms of section 46274 4. Replacing Invariant Sections with translations requires special 46275 permission from their copyright holders, but you may include 46276 translations of some or all Invariant Sections in addition to the 46277 original versions of these Invariant Sections. You may include a 46278 translation of this License, and all the license notices in the 46279 Document, and any Warranty Disclaimers, provided that you also 46280 include the original English version of this License and the 46281 original versions of those notices and disclaimers. In case of a 46282 disagreement between the translation and the original version of 46283 this License or a notice or disclaimer, the original version will 46284 prevail. 46285 46286 If a section in the Document is Entitled "Acknowledgements", 46287 "Dedications", or "History", the requirement (section 4) to 46288 Preserve its Title (section 1) will typically require changing the 46289 actual title. 46290 46291 9. TERMINATION 46292 46293 You may not copy, modify, sublicense, or distribute the Document 46294 except as expressly provided under this License. Any attempt 46295 otherwise to copy, modify, sublicense, or distribute it is void, 46296 and will automatically terminate your rights under this License. 46297 46298 However, if you cease all violation of this License, then your 46299 license from a particular copyright holder is reinstated (a) 46300 provisionally, unless and until the copyright holder explicitly and 46301 finally terminates your license, and (b) permanently, if the 46302 copyright holder fails to notify you of the violation by some 46303 reasonable means prior to 60 days after the cessation. 46304 46305 Moreover, your license from a particular copyright holder is 46306 reinstated permanently if the copyright holder notifies you of the 46307 violation by some reasonable means, this is the first time you have 46308 received notice of violation of this License (for any work) from 46309 that copyright holder, and you cure the violation prior to 30 days 46310 after your receipt of the notice. 46311 46312 Termination of your rights under this section does not terminate 46313 the licenses of parties who have received copies or rights from you 46314 under this License. If your rights have been terminated and not 46315 permanently reinstated, receipt of a copy of some or all of the 46316 same material does not give you any rights to use it. 46317 46318 10. FUTURE REVISIONS OF THIS LICENSE 46319 46320 The Free Software Foundation may publish new, revised versions of 46321 the GNU Free Documentation License from time to time. Such new 46322 versions will be similar in spirit to the present version, but may 46323 differ in detail to address new problems or concerns. See 46324 <http://www.gnu.org/copyleft/>. 46325 46326 Each version of the License is given a distinguishing version 46327 number. If the Document specifies that a particular numbered 46328 version of this License "or any later version" applies to it, you 46329 have the option of following the terms and conditions either of 46330 that specified version or of any later version that has been 46331 published (not as a draft) by the Free Software Foundation. If the 46332 Document does not specify a version number of this License, you may 46333 choose any version ever published (not as a draft) by the Free 46334 Software Foundation. If the Document specifies that a proxy can 46335 decide which future versions of this License can be used, that 46336 proxy's public statement of acceptance of a version permanently 46337 authorizes you to choose that version for the Document. 46338 46339 11. RELICENSING 46340 46341 "Massive Multiauthor Collaboration Site" (or "MMC Site") means any 46342 World Wide Web server that publishes copyrightable works and also 46343 provides prominent facilities for anybody to edit those works. A 46344 public wiki that anybody can edit is an example of such a server. 46345 A "Massive Multiauthor Collaboration" (or "MMC") contained in the 46346 site means any set of copyrightable works thus published on the MMC 46347 site. 46348 46349 "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 46350 license published by Creative Commons Corporation, a not-for-profit 46351 corporation with a principal place of business in San Francisco, 46352 California, as well as future copyleft versions of that license 46353 published by that same organization. 46354 46355 "Incorporate" means to publish or republish a Document, in whole or 46356 in part, as part of another Document. 46357 46358 An MMC is "eligible for relicensing" if it is licensed under this 46359 License, and if all works that were first published under this 46360 License somewhere other than this MMC, and subsequently 46361 incorporated in whole or in part into the MMC, (1) had no cover 46362 texts or invariant sections, and (2) were thus incorporated prior 46363 to November 1, 2008. 46364 46365 The operator of an MMC Site may republish an MMC contained in the 46366 site under CC-BY-SA on the same site at any time before August 1, 46367 2009, provided the MMC is eligible for relicensing. 46368 46369ADDENDUM: How to use this License for your documents 46370==================================================== 46371 46372To use this License in a document you have written, include a copy of 46373the License in the document and put the following copyright and license 46374notices just after the title page: 46375 46376 Copyright (C) YEAR YOUR NAME. 46377 Permission is granted to copy, distribute and/or modify this document 46378 under the terms of the GNU Free Documentation License, Version 1.3 46379 or any later version published by the Free Software Foundation; 46380 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover 46381 Texts. A copy of the license is included in the section entitled ``GNU 46382 Free Documentation License''. 46383 46384 If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, 46385replace the "with...Texts." line with this: 46386 46387 with the Invariant Sections being LIST THEIR TITLES, with 46388 the Front-Cover Texts being LIST, and with the Back-Cover Texts 46389 being LIST. 46390 46391 If you have Invariant Sections without Cover Texts, or some other 46392combination of the three, merge those two alternatives to suit the 46393situation. 46394 46395 If your document contains nontrivial examples of program code, we 46396recommend releasing these examples in parallel under your choice of free 46397software license, such as the GNU General Public License, to permit 46398their use in free software. 46399 46400 46401File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top 46402 46403Contributors to GCC 46404******************* 46405 46406The GCC project would like to thank its many contributors. Without them 46407the project would not have been nearly as successful as it has been. 46408Any omissions in this list are accidental. Feel free to contact 46409<law@redhat.com> or <gerald@pfeifer.com> if you have been left out or 46410some of your contributions are not listed. Please keep this list in 46411alphabetical order. 46412 46413 * Analog Devices helped implement the support for complex data types 46414 and iterators. 46415 46416 * John David Anglin for threading-related fixes and improvements to 46417 libstdc++-v3, and the HP-UX port. 46418 46419 * James van Artsdalen wrote the code that makes efficient use of the 46420 Intel 80387 register stack. 46421 46422 * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta 46423 Series port. 46424 46425 * Alasdair Baird for various bug fixes. 46426 46427 * Giovanni Bajo for analyzing lots of complicated C++ problem 46428 reports. 46429 46430 * Peter Barada for his work to improve code generation for new 46431 ColdFire cores. 46432 46433 * Gerald Baumgartner added the signature extension to the C++ front 46434 end. 46435 46436 * Godmar Back for his Java improvements and encouragement. 46437 46438 * Scott Bambrough for help porting the Java compiler. 46439 46440 * Wolfgang Bangerth for processing tons of bug reports. 46441 46442 * Jon Beniston for his Microsoft Windows port of Java and port to 46443 Lattice Mico32. 46444 46445 * Daniel Berlin for better DWARF 2 support, faster/better 46446 optimizations, improved alias analysis, plus migrating GCC to 46447 Bugzilla. 46448 46449 * Geoff Berry for his Java object serialization work and various 46450 patches. 46451 46452 * David Binderman tests weekly snapshots of GCC trunk against Fedora 46453 Rawhide for several architectures. 46454 46455 * Laurynas Biveinis for memory management work and DJGPP port fixes. 46456 46457 * Uros Bizjak for the implementation of x87 math built-in functions 46458 and for various middle end and i386 back end improvements and bug 46459 fixes. 46460 46461 * Eric Blake for helping to make GCJ and libgcj conform to the 46462 specifications. 46463 46464 * Janne Blomqvist for contributions to GNU Fortran. 46465 46466 * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and 46467 other Java work. 46468 46469 * Segher Boessenkool for helping maintain the PowerPC port and the 46470 instruction combiner plus various contributions to the middle end. 46471 46472 * Neil Booth for work on cpplib, lang hooks, debug hooks and other 46473 miscellaneous clean-ups. 46474 46475 * Steven Bosscher for integrating the GNU Fortran front end into GCC 46476 and for contributing to the tree-ssa branch. 46477 46478 * Eric Botcazou for fixing middle- and backend bugs left and right. 46479 46480 * Per Bothner for his direction via the steering committee and 46481 various improvements to the infrastructure for supporting new 46482 languages. Chill front end implementation. Initial 46483 implementations of cpplib, fix-header, config.guess, libio, and 46484 past C++ library (libg++) maintainer. Dreaming up, designing and 46485 implementing much of GCJ. 46486 46487 * Devon Bowen helped port GCC to the Tahoe. 46488 46489 * Don Bowman for mips-vxworks contributions. 46490 46491 * James Bowman for the FT32 port. 46492 46493 * Dave Brolley for work on cpplib and Chill. 46494 46495 * Paul Brook for work on the ARM architecture and maintaining GNU 46496 Fortran. 46497 46498 * Robert Brown implemented the support for Encore 32000 systems. 46499 46500 * Christian Bruel for improvements to local store elimination. 46501 46502 * Herman A.J. ten Brugge for various fixes. 46503 46504 * Joerg Brunsmann for Java compiler hacking and help with the GCJ 46505 FAQ. 46506 46507 * Joe Buck for his direction via the steering committee from its 46508 creation to 2013. 46509 46510 * Iain Buclaw for the D frontend. 46511 46512 * Craig Burley for leadership of the G77 Fortran effort. 46513 46514 * Tobias Burnus for contributions to GNU Fortran. 46515 46516 * Stephan Buys for contributing Doxygen notes for libstdc++. 46517 46518 * Paolo Carlini for libstdc++ work: lots of efficiency improvements 46519 to the C++ strings, streambufs and formatted I/O, hard detective 46520 work on the frustrating localization issues, and keeping up with 46521 the problem reports. 46522 46523 * John Carr for his alias work, SPARC hacking, infrastructure 46524 improvements, previous contributions to the steering committee, 46525 loop optimizations, etc. 46526 46527 * Stephane Carrez for 68HC11 and 68HC12 ports. 46528 46529 * Steve Chamberlain for support for the Renesas SH and H8 processors 46530 and the PicoJava processor, and for GCJ config fixes. 46531 46532 * Glenn Chambers for help with the GCJ FAQ. 46533 46534 * John-Marc Chandonia for various libgcj patches. 46535 46536 * Denis Chertykov for contributing and maintaining the AVR port, the 46537 first GCC port for an 8-bit architecture. 46538 46539 * Kito Cheng for his work on the RISC-V port, including bringing up 46540 the test suite and maintenance. 46541 46542 * Scott Christley for his Objective-C contributions. 46543 46544 * Eric Christopher for his Java porting help and clean-ups. 46545 46546 * Branko Cibej for more warning contributions. 46547 46548 * The GNU Classpath project for all of their merged runtime code. 46549 46550 * Nick Clifton for arm, mcore, fr30, v850, m32r, msp430 rx work, 46551 '--help', and other random hacking. 46552 46553 * Michael Cook for libstdc++ cleanup patches to reduce warnings. 46554 46555 * R. Kelley Cook for making GCC buildable from a read-only directory 46556 as well as other miscellaneous build process and documentation 46557 clean-ups. 46558 46559 * Ralf Corsepius for SH testing and minor bug fixing. 46560 46561 * Franc,ois-Xavier Coudert for contributions to GNU Fortran. 46562 46563 * Stan Cox for care and feeding of the x86 port and lots of behind 46564 the scenes hacking. 46565 46566 * Alex Crain provided changes for the 3b1. 46567 46568 * Ian Dall for major improvements to the NS32k port. 46569 46570 * Paul Dale for his work to add uClinux platform support to the m68k 46571 backend. 46572 46573 * Palmer Dabbelt for his work maintaining the RISC-V port. 46574 46575 * Dario Dariol contributed the four varieties of sample programs that 46576 print a copy of their source. 46577 46578 * Russell Davidson for fstream and stringstream fixes in libstdc++. 46579 46580 * Bud Davis for work on the G77 and GNU Fortran compilers. 46581 46582 * Mo DeJong for GCJ and libgcj bug fixes. 46583 46584 * Jerry DeLisle for contributions to GNU Fortran. 46585 46586 * DJ Delorie for the DJGPP port, build and libiberty maintenance, 46587 various bug fixes, and the M32C, MeP, MSP430, and RL78 ports. 46588 46589 * Arnaud Desitter for helping to debug GNU Fortran. 46590 46591 * Gabriel Dos Reis for contributions to G++, contributions and 46592 maintenance of GCC diagnostics infrastructure, libstdc++-v3, 46593 including 'valarray<>', 'complex<>', maintaining the numerics 46594 library (including that pesky '<limits>' :-) and keeping up-to-date 46595 anything to do with numbers. 46596 46597 * Ulrich Drepper for his work on glibc, testing of GCC using glibc, 46598 ISO C99 support, CFG dumping support, etc., plus support of the C++ 46599 runtime libraries including for all kinds of C interface issues, 46600 contributing and maintaining 'complex<>', sanity checking and 46601 disbursement, configuration architecture, libio maintenance, and 46602 early math work. 46603 46604 * Franc,ois Dumont for his work on libstdc++-v3, especially 46605 maintaining and improving 'debug-mode' and associative and 46606 unordered containers. 46607 46608 * Zdenek Dvorak for a new loop unroller and various fixes. 46609 46610 * Michael Eager for his work on the Xilinx MicroBlaze port. 46611 46612 * Richard Earnshaw for his ongoing work with the ARM. 46613 46614 * David Edelsohn for his direction via the steering committee, 46615 ongoing work with the RS6000/PowerPC port, help cleaning up Haifa 46616 loop changes, doing the entire AIX port of libstdc++ with his bare 46617 hands, and for ensuring GCC properly keeps working on AIX. 46618 46619 * Kevin Ediger for the floating point formatting of num_put::do_put 46620 in libstdc++. 46621 46622 * Phil Edwards for libstdc++ work including configuration hackery, 46623 documentation maintainer, chief breaker of the web pages, the 46624 occasional iostream bug fix, and work on shared library symbol 46625 versioning. 46626 46627 * Paul Eggert for random hacking all over GCC. 46628 46629 * Mark Elbrecht for various DJGPP improvements, and for libstdc++ 46630 configuration support for locales and fstream-related fixes. 46631 46632 * Vadim Egorov for libstdc++ fixes in strings, streambufs, and 46633 iostreams. 46634 46635 * Christian Ehrhardt for dealing with bug reports. 46636 46637 * Ben Elliston for his work to move the Objective-C runtime into its 46638 own subdirectory and for his work on autoconf. 46639 46640 * Revital Eres for work on the PowerPC 750CL port. 46641 46642 * Marc Espie for OpenBSD support. 46643 46644 * Doug Evans for much of the global optimization framework, arc, 46645 m32r, and SPARC work. 46646 46647 * Christopher Faylor for his work on the Cygwin port and for caring 46648 and feeding the gcc.gnu.org box and saving its users tons of spam. 46649 46650 * Fred Fish for BeOS support and Ada fixes. 46651 46652 * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ. 46653 46654 * Peter Gerwinski for various bug fixes and the Pascal front end. 46655 46656 * Kaveh R. Ghazi for his direction via the steering committee, 46657 amazing work to make '-W -Wall -W* -Werror' useful, and testing GCC 46658 on a plethora of platforms. Kaveh extends his gratitude to the 46659 CAIP Center at Rutgers University for providing him with computing 46660 resources to work on Free Software from the late 1980s to 2010. 46661 46662 * John Gilmore for a donation to the FSF earmarked improving GNU 46663 Java. 46664 46665 * Judy Goldberg for c++ contributions. 46666 46667 * Torbjorn Granlund for various fixes and the c-torture testsuite, 46668 multiply- and divide-by-constant optimization, improved long long 46669 support, improved leaf function register allocation, and his 46670 direction via the steering committee. 46671 46672 * Jonny Grant for improvements to 'collect2's' '--help' 46673 documentation. 46674 46675 * Anthony Green for his '-Os' contributions, the moxie port, and Java 46676 front end work. 46677 46678 * Stu Grossman for gdb hacking, allowing GCJ developers to debug Java 46679 code. 46680 46681 * Michael K. Gschwind contributed the port to the PDP-11. 46682 46683 * Richard Biener for his ongoing middle-end contributions and bug 46684 fixes and for release management. 46685 46686 * Ron Guilmette implemented the 'protoize' and 'unprotoize' tools, 46687 the support for DWARF 1 symbolic debugging information, and much of 46688 the support for System V Release 4. He has also worked heavily on 46689 the Intel 386 and 860 support. 46690 46691 * Sumanth Gundapaneni for contributing the CR16 port. 46692 46693 * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload 46694 GCSE. 46695 46696 * Bruno Haible for improvements in the runtime overhead for EH, new 46697 warnings and assorted bug fixes. 46698 46699 * Andrew Haley for his amazing Java compiler and library efforts. 46700 46701 * Chris Hanson assisted in making GCC work on HP-UX for the 9000 46702 series 300. 46703 46704 * Michael Hayes for various thankless work he's done trying to get 46705 the c30/c40 ports functional. Lots of loop and unroll improvements 46706 and fixes. 46707 46708 * Dara Hazeghi for wading through myriads of target-specific bug 46709 reports. 46710 46711 * Kate Hedstrom for staking the G77 folks with an initial testsuite. 46712 46713 * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64 46714 work, loop opts, and generally fixing lots of old problems we've 46715 ignored for years, flow rewrite and lots of further stuff, 46716 including reviewing tons of patches. 46717 46718 * Aldy Hernandez for working on the PowerPC port, SIMD support, and 46719 various fixes. 46720 46721 * Nobuyuki Hikichi of Software Research Associates, Tokyo, 46722 contributed the support for the Sony NEWS machine. 46723 46724 * Kazu Hirata for caring and feeding the Renesas H8/300 port and 46725 various fixes. 46726 46727 * Katherine Holcomb for work on GNU Fortran. 46728 46729 * Manfred Hollstein for his ongoing work to keep the m88k alive, lots 46730 of testing and bug fixing, particularly of GCC configury code. 46731 46732 * Steve Holmgren for MachTen patches. 46733 46734 * Mat Hostetter for work on the TILE-Gx and TILEPro ports. 46735 46736 * Jan Hubicka for his x86 port improvements. 46737 46738 * Falk Hueffner for working on C and optimization bug reports. 46739 46740 * Bernardo Innocenti for his m68k work, including merging of ColdFire 46741 improvements and uClinux support. 46742 46743 * Christian Iseli for various bug fixes. 46744 46745 * Kamil Iskra for general m68k hacking. 46746 46747 * Lee Iverson for random fixes and MIPS testing. 46748 46749 * Balaji V. Iyer for Cilk+ development and merging. 46750 46751 * Andreas Jaeger for testing and benchmarking of GCC and various bug 46752 fixes. 46753 46754 * Martin Jambor for his work on inter-procedural optimizations, the 46755 switch conversion pass, and scalar replacement of aggregates. 46756 46757 * Jakub Jelinek for his SPARC work and sibling call optimizations as 46758 well as lots of bug fixes and test cases, and for improving the 46759 Java build system. 46760 46761 * Janis Johnson for ia64 testing and fixes, her quality improvement 46762 sidetracks, and web page maintenance. 46763 46764 * Kean Johnston for SCO OpenServer support and various fixes. 46765 46766 * Tim Josling for the sample language treelang based originally on 46767 Richard Kenner's "toy" language. 46768 46769 * Nicolai Josuttis for additional libstdc++ documentation. 46770 46771 * Klaus Kaempf for his ongoing work to make alpha-vms a viable 46772 target. 46773 46774 * Steven G. Kargl for work on GNU Fortran. 46775 46776 * David Kashtan of SRI adapted GCC to VMS. 46777 46778 * Ryszard Kabatek for many, many libstdc++ bug fixes and 46779 optimizations of strings, especially member functions, and for 46780 auto_ptr fixes. 46781 46782 * Geoffrey Keating for his ongoing work to make the PPC work for 46783 GNU/Linux and his automatic regression tester. 46784 46785 * Brendan Kehoe for his ongoing work with G++ and for a lot of early 46786 work in just about every part of libstdc++. 46787 46788 * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the 46789 MIL-STD-1750A. 46790 46791 * Richard Kenner of the New York University Ultracomputer Research 46792 Laboratory wrote the machine descriptions for the AMD 29000, the 46793 DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the 46794 support for instruction attributes. He also made changes to better 46795 support RISC processors including changes to common subexpression 46796 elimination, strength reduction, function calling sequence 46797 handling, and condition code support, in addition to generalizing 46798 the code for frame pointer elimination and delay slot scheduling. 46799 Richard Kenner was also the head maintainer of GCC for several 46800 years. 46801 46802 * Mumit Khan for various contributions to the Cygwin and Mingw32 46803 ports and maintaining binary releases for Microsoft Windows hosts, 46804 and for massive libstdc++ porting work to Cygwin/Mingw32. 46805 46806 * Robin Kirkham for cpu32 support. 46807 46808 * Mark Klein for PA improvements. 46809 46810 * Thomas Koenig for various bug fixes. 46811 46812 * Bruce Korb for the new and improved fixincludes code. 46813 46814 * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3 46815 effort. 46816 46817 * Maxim Kuvyrkov for contributions to the instruction scheduler, the 46818 Android and m68k/Coldfire ports, and optimizations. 46819 46820 * Charles LaBrec contributed the support for the Integrated Solutions 46821 68020 system. 46822 46823 * Asher Langton and Mike Kumbera for contributing Cray pointer 46824 support to GNU Fortran, and for other GNU Fortran improvements. 46825 46826 * Jeff Law for his direction via the steering committee, coordinating 46827 the entire egcs project and GCC 2.95, rolling out snapshots and 46828 releases, handling merges from GCC2, reviewing tons of patches that 46829 might have fallen through the cracks else, and random but extensive 46830 hacking. 46831 46832 * Walter Lee for work on the TILE-Gx and TILEPro ports. 46833 46834 * Marc Lehmann for his direction via the steering committee and 46835 helping with analysis and improvements of x86 performance. 46836 46837 * Victor Leikehman for work on GNU Fortran. 46838 46839 * Ted Lemon wrote parts of the RTL reader and printer. 46840 46841 * Kriang Lerdsuwanakij for C++ improvements including template as 46842 template parameter support, and many C++ fixes. 46843 46844 * Warren Levy for tremendous work on libgcj (Java Runtime Library) 46845 and random work on the Java front end. 46846 46847 * Alain Lichnewsky ported GCC to the MIPS CPU. 46848 46849 * Oskar Liljeblad for hacking on AWT and his many Java bug reports 46850 and patches. 46851 46852 * Robert Lipe for OpenServer support, new testsuites, testing, etc. 46853 46854 * Chen Liqin for various S+core related fixes/improvement, and for 46855 maintaining the S+core port. 46856 46857 * Martin Liska for his work on identical code folding, the 46858 sanitizers, HSA, general bug fixing and for running automated 46859 regression testing of GCC and reporting numerous bugs. 46860 46861 * Weiwen Liu for testing and various bug fixes. 46862 46863 * Manuel Lo'pez-Iba'n~ez for improving '-Wconversion' and many other 46864 diagnostics fixes and improvements. 46865 46866 * Dave Love for his ongoing work with the Fortran front end and 46867 runtime libraries. 46868 46869 * Martin von Lo"wis for internal consistency checking infrastructure, 46870 various C++ improvements including namespace support, and tons of 46871 assistance with libstdc++/compiler merges. 46872 46873 * H.J. Lu for his previous contributions to the steering committee, 46874 many x86 bug reports, prototype patches, and keeping the GNU/Linux 46875 ports working. 46876 46877 * Greg McGary for random fixes and (someday) bounded pointers. 46878 46879 * Andrew MacLeod for his ongoing work in building a real EH system, 46880 various code generation improvements, work on the global optimizer, 46881 etc. 46882 46883 * Vladimir Makarov for hacking some ugly i960 problems, PowerPC 46884 hacking improvements to compile-time performance, overall knowledge 46885 and direction in the area of instruction scheduling, design and 46886 implementation of the automaton based instruction scheduler and 46887 design and implementation of the integrated and local register 46888 allocators. 46889 46890 * David Malcolm for his work on improving GCC diagnostics, JIT, 46891 self-tests and unit testing. 46892 46893 * Bob Manson for his behind the scenes work on dejagnu. 46894 46895 * John Marino for contributing the DragonFly BSD port. 46896 46897 * Philip Martin for lots of libstdc++ string and vector iterator 46898 fixes and improvements, and string clean up and testsuites. 46899 46900 * Michael Matz for his work on dominance tree discovery, the x86-64 46901 port, link-time optimization framework and general optimization 46902 improvements. 46903 46904 * All of the Mauve project contributors for Java test code. 46905 46906 * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements. 46907 46908 * Adam Megacz for his work on the Microsoft Windows port of GCJ. 46909 46910 * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS, 46911 powerpc, haifa, ECOFF debug support, and other assorted hacking. 46912 46913 * Jason Merrill for his direction via the steering committee and 46914 leading the G++ effort. 46915 46916 * Martin Michlmayr for testing GCC on several architectures using the 46917 entire Debian archive. 46918 46919 * David Miller for his direction via the steering committee, lots of 46920 SPARC work, improvements in jump.c and interfacing with the Linux 46921 kernel developers. 46922 46923 * Gary Miller ported GCC to Charles River Data Systems machines. 46924 46925 * Alfred Minarik for libstdc++ string and ios bug fixes, and turning 46926 the entire libstdc++ testsuite namespace-compatible. 46927 46928 * Mark Mitchell for his direction via the steering committee, 46929 mountains of C++ work, load/store hoisting out of loops, alias 46930 analysis improvements, ISO C 'restrict' support, and serving as 46931 release manager from 2000 to 2011. 46932 46933 * Alan Modra for various GNU/Linux bits and testing. 46934 46935 * Toon Moene for his direction via the steering committee, Fortran 46936 maintenance, and his ongoing work to make us make Fortran run fast. 46937 46938 * Jason Molenda for major help in the care and feeding of all the 46939 services on the gcc.gnu.org (formerly egcs.cygnus.com) 46940 machine--mail, web services, ftp services, etc etc. Doing all this 46941 work on scrap paper and the backs of envelopes would have been... 46942 difficult. 46943 46944 * Catherine Moore for fixing various ugly problems we have sent her 46945 way, including the haifa bug which was killing the Alpha & PowerPC 46946 Linux kernels. 46947 46948 * Mike Moreton for his various Java patches. 46949 46950 * David Mosberger-Tang for various Alpha improvements, and for the 46951 initial IA-64 port. 46952 46953 * Stephen Moshier contributed the floating point emulator that 46954 assists in cross-compilation and permits support for floating point 46955 numbers wider than 64 bits and for ISO C99 support. 46956 46957 * Bill Moyer for his behind the scenes work on various issues. 46958 46959 * Philippe De Muyter for his work on the m68k port. 46960 46961 * Joseph S. Myers for his work on the PDP-11 port, format checking 46962 and ISO C99 support, and continuous emphasis on (and contributions 46963 to) documentation. 46964 46965 * Nathan Myers for his work on libstdc++-v3: architecture and 46966 authorship through the first three snapshots, including 46967 implementation of locale infrastructure, string, shadow C headers, 46968 and the initial project documentation (DESIGN, CHECKLIST, and so 46969 forth). Later, more work on MT-safe string and shadow headers. 46970 46971 * Felix Natter for documentation on porting libstdc++. 46972 46973 * Nathanael Nerode for cleaning up the configuration/build process. 46974 46975 * NeXT, Inc. donated the front end that supports the Objective-C 46976 language. 46977 46978 * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to the 46979 search engine setup, various documentation fixes and other small 46980 fixes. 46981 46982 * Geoff Noer for his work on getting cygwin native builds working. 46983 46984 * Vegard Nossum for running automated regression testing of GCC and 46985 reporting numerous bugs. 46986 46987 * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance 46988 tracking web pages, GIMPLE tuples, and assorted fixes. 46989 46990 * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64, 46991 FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and related 46992 infrastructure improvements. 46993 46994 * Alexandre Oliva for various build infrastructure improvements, 46995 scripts and amazing testing work, including keeping libtool issues 46996 sane and happy. 46997 46998 * Stefan Olsson for work on mt_alloc. 46999 47000 * Melissa O'Neill for various NeXT fixes. 47001 47002 * Rainer Orth for random MIPS work, including improvements to GCC's 47003 o32 ABI support, improvements to dejagnu's MIPS support, Java 47004 configuration clean-ups and porting work, and maintaining the IRIX, 47005 Solaris 2, and Tru64 UNIX ports. 47006 47007 * Steven Pemberton for his contribution of 'enquire' which allowed 47008 GCC to determine various properties of the floating point unit and 47009 generate 'float.h' in older versions of GCC. 47010 47011 * Hartmut Penner for work on the s390 port. 47012 47013 * Paul Petersen wrote the machine description for the Alliant FX/8. 47014 47015 * Alexandre Petit-Bianco for implementing much of the Java compiler 47016 and continued Java maintainership. 47017 47018 * Matthias Pfaller for major improvements to the NS32k port. 47019 47020 * Gerald Pfeifer for his direction via the steering committee, 47021 pointing out lots of problems we need to solve, maintenance of the 47022 web pages, and taking care of documentation maintenance in general. 47023 47024 * Marek Polacek for his work on the C front end, the sanitizers and 47025 general bug fixing. 47026 47027 * Andrew Pinski for processing bug reports by the dozen. 47028 47029 * Ovidiu Predescu for his work on the Objective-C front end and 47030 runtime libraries. 47031 47032 * Jerry Quinn for major performance improvements in C++ formatted 47033 I/O. 47034 47035 * Ken Raeburn for various improvements to checker, MIPS ports and 47036 various cleanups in the compiler. 47037 47038 * Rolf W. Rasmussen for hacking on AWT. 47039 47040 * David Reese of Sun Microsystems contributed to the Solaris on 47041 PowerPC port. 47042 47043 * John Regehr for running automated regression testing of GCC and 47044 reporting numerous bugs. 47045 47046 * Volker Reichelt for running automated regression testing of GCC and 47047 reporting numerous bugs and for keeping up with the problem 47048 reports. 47049 47050 * Joern Rennecke for maintaining the sh port, loop, regmove & reload 47051 hacking and developing and maintaining the Epiphany port. 47052 47053 * Loren J. Rittle for improvements to libstdc++-v3 including the 47054 FreeBSD port, threading fixes, thread-related configury changes, 47055 critical threading documentation, and solutions to really tricky 47056 I/O problems, as well as keeping GCC properly working on FreeBSD 47057 and continuous testing. 47058 47059 * Craig Rodrigues for processing tons of bug reports. 47060 47061 * Ola Ro"nnerup for work on mt_alloc. 47062 47063 * Gavin Romig-Koch for lots of behind the scenes MIPS work. 47064 47065 * David Ronis inspired and encouraged Craig to rewrite the G77 47066 documentation in texinfo format by contributing a first pass at a 47067 translation of the old 'g77-0.5.16/f/DOC' file. 47068 47069 * Ken Rose for fixes to GCC's delay slot filling code. 47070 47071 * Ira Rosen for her contributions to the auto-vectorizer. 47072 47073 * Paul Rubin wrote most of the preprocessor. 47074 47075 * Pe'tur Runo'lfsson for major performance improvements in C++ 47076 formatted I/O and large file support in C++ filebuf. 47077 47078 * Chip Salzenberg for libstdc++ patches and improvements to locales, 47079 traits, Makefiles, libio, libtool hackery, and "long long" support. 47080 47081 * Juha Sarlin for improvements to the H8 code generator. 47082 47083 * Greg Satz assisted in making GCC work on HP-UX for the 9000 series 47084 300. 47085 47086 * Roger Sayle for improvements to constant folding and GCC's RTL 47087 optimizers as well as for fixing numerous bugs. 47088 47089 * Bradley Schatz for his work on the GCJ FAQ. 47090 47091 * Peter Schauer wrote the code to allow debugging to work on the 47092 Alpha. 47093 47094 * William Schelter did most of the work on the Intel 80386 support. 47095 47096 * Tobias Schlu"ter for work on GNU Fortran. 47097 47098 * Bernd Schmidt for various code generation improvements and major 47099 work in the reload pass, serving as release manager for GCC 2.95.3, 47100 and work on the Blackfin and C6X ports. 47101 47102 * Peter Schmid for constant testing of libstdc++--especially 47103 application testing, going above and beyond what was requested for 47104 the release criteria--and libstdc++ header file tweaks. 47105 47106 * Jason Schroeder for jcf-dump patches. 47107 47108 * Andreas Schwab for his work on the m68k port. 47109 47110 * Lars Segerlund for work on GNU Fortran. 47111 47112 * Dodji Seketeli for numerous C++ bug fixes and debug info 47113 improvements. 47114 47115 * Tim Shen for major work on '<regex>'. 47116 47117 * Joel Sherrill for his direction via the steering committee, RTEMS 47118 contributions and RTEMS testing. 47119 47120 * Nathan Sidwell for many C++ fixes/improvements. 47121 47122 * Jeffrey Siegal for helping RMS with the original design of GCC, 47123 some code which handles the parse tree and RTL data structures, 47124 constant folding and help with the original VAX & m68k ports. 47125 47126 * Kenny Simpson for prompting libstdc++ fixes due to defect reports 47127 from the LWG (thereby keeping GCC in line with updates from the 47128 ISO). 47129 47130 * Franz Sirl for his ongoing work with making the PPC port stable for 47131 GNU/Linux. 47132 47133 * Andrey Slepuhin for assorted AIX hacking. 47134 47135 * Trevor Smigiel for contributing the SPU port. 47136 47137 * Christopher Smith did the port for Convex machines. 47138 47139 * Danny Smith for his major efforts on the Mingw (and Cygwin) ports. 47140 Retired from GCC maintainership August 2010, having mentored two 47141 new maintainers into the role. 47142 47143 * Randy Smith finished the Sun FPA support. 47144 47145 * Ed Smith-Rowland for his continuous work on libstdc++-v3, special 47146 functions, '<random>', and various improvements to C++11 features. 47147 47148 * Scott Snyder for queue, iterator, istream, and string fixes and 47149 libstdc++ testsuite entries. Also for providing the patch to G77 47150 to add rudimentary support for 'INTEGER*1', 'INTEGER*2', and 47151 'LOGICAL*1'. 47152 47153 * Zdenek Sojka for running automated regression testing of GCC and 47154 reporting numerous bugs. 47155 47156 * Arseny Solokha for running automated regression testing of GCC and 47157 reporting numerous bugs. 47158 47159 * Jayant Sonar for contributing the CR16 port. 47160 47161 * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique. 47162 47163 * Richard Stallman, for writing the original GCC and launching the 47164 GNU project. 47165 47166 * Jan Stein of the Chalmers Computer Society provided support for 47167 Genix, as well as part of the 32000 machine description. 47168 47169 * Gerhard Steinmetz for running automated regression testing of GCC 47170 and reporting numerous bugs. 47171 47172 * Nigel Stephens for various mips16 related fixes/improvements. 47173 47174 * Jonathan Stone wrote the machine description for the Pyramid 47175 computer. 47176 47177 * Graham Stott for various infrastructure improvements. 47178 47179 * John Stracke for his Java HTTP protocol fixes. 47180 47181 * Mike Stump for his Elxsi port, G++ contributions over the years and 47182 more recently his vxworks contributions 47183 47184 * Jeff Sturm for Java porting help, bug fixes, and encouragement. 47185 47186 * Zhendong Su for running automated regression testing of GCC and 47187 reporting numerous bugs. 47188 47189 * Chengnian Sun for running automated regression testing of GCC and 47190 reporting numerous bugs. 47191 47192 * Shigeya Suzuki for this fixes for the bsdi platforms. 47193 47194 * Ian Lance Taylor for the Go frontend, the initial mips16 and mips64 47195 support, general configury hacking, fixincludes, etc. 47196 47197 * Holger Teutsch provided the support for the Clipper CPU. 47198 47199 * Gary Thomas for his ongoing work to make the PPC work for 47200 GNU/Linux. 47201 47202 * Paul Thomas for contributions to GNU Fortran. 47203 47204 * Philipp Thomas for random bug fixes throughout the compiler 47205 47206 * Jason Thorpe for thread support in libstdc++ on NetBSD. 47207 47208 * Kresten Krab Thorup wrote the run time support for the Objective-C 47209 language and the fantastic Java bytecode interpreter. 47210 47211 * Michael Tiemann for random bug fixes, the first instruction 47212 scheduler, initial C++ support, function integration, NS32k, SPARC 47213 and M88k machine description work, delay slot scheduling. 47214 47215 * Andreas Tobler for his work porting libgcj to Darwin. 47216 47217 * Teemu Torma for thread safe exception handling support. 47218 47219 * Leonard Tower wrote parts of the parser, RTL generator, and RTL 47220 definitions, and of the VAX machine description. 47221 47222 * Daniel Towner and Hariharan Sandanagobalane contributed and 47223 maintain the picoChip port. 47224 47225 * Tom Tromey for internationalization support and for his many Java 47226 contributions and libgcj maintainership. 47227 47228 * Lassi Tuura for improvements to config.guess to determine HP 47229 processor types. 47230 47231 * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes. 47232 47233 * Andy Vaught for the design and initial implementation of the GNU 47234 Fortran front end. 47235 47236 * Brent Verner for work with the libstdc++ cshadow files and their 47237 associated configure steps. 47238 47239 * Todd Vierling for contributions for NetBSD ports. 47240 47241 * Andrew Waterman for contributing the RISC-V port, as well as 47242 maintaining it. 47243 47244 * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML 47245 guidance and maintaining libstdc++. 47246 47247 * Dean Wakerley for converting the install documentation from HTML to 47248 texinfo in time for GCC 3.0. 47249 47250 * Krister Walfridsson for random bug fixes. 47251 47252 * Feng Wang for contributions to GNU Fortran. 47253 47254 * Stephen M. Webb for time and effort on making libstdc++ shadow 47255 files work with the tricky Solaris 8+ headers, and for pushing the 47256 build-time header tree. Also, for starting and driving the 47257 '<regex>' effort. 47258 47259 * John Wehle for various improvements for the x86 code generator, 47260 related infrastructure improvements to help x86 code generation, 47261 value range propagation and other work, WE32k port. 47262 47263 * Ulrich Weigand for work on the s390 port. 47264 47265 * Janus Weil for contributions to GNU Fortran. 47266 47267 * Zack Weinberg for major work on cpplib and various other bug fixes. 47268 47269 * Matt Welsh for help with Linux Threads support in GCJ. 47270 47271 * Urban Widmark for help fixing java.io. 47272 47273 * Mark Wielaard for new Java library code and his work integrating 47274 with Classpath. 47275 47276 * Dale Wiles helped port GCC to the Tahoe. 47277 47278 * Bob Wilson from Tensilica, Inc. for the Xtensa port. 47279 47280 * Jim Wilson for his direction via the steering committee, tackling 47281 hard problems in various places that nobody else wanted to work on, 47282 strength reduction and other loop optimizations. 47283 47284 * Paul Woegerer and Tal Agmon for the CRX port. 47285 47286 * Carlo Wood for various fixes. 47287 47288 * Tom Wood for work on the m88k port. 47289 47290 * Chung-Ju Wu for his work on the Andes NDS32 port. 47291 47292 * Canqun Yang for work on GNU Fortran. 47293 47294 * Masanobu Yuhara of Fujitsu Laboratories implemented the machine 47295 description for the Tron architecture (specifically, the Gmicro). 47296 47297 * Kevin Zachmann helped port GCC to the Tahoe. 47298 47299 * Ayal Zaks for Swing Modulo Scheduling (SMS). 47300 47301 * Qirun Zhang for running automated regression testing of GCC and 47302 reporting numerous bugs. 47303 47304 * Xiaoqiang Zhang for work on GNU Fortran. 47305 47306 * Gilles Zunino for help porting Java to Irix. 47307 47308 The following people are recognized for their contributions to GNAT, 47309the Ada front end of GCC: 47310 * Bernard Banner 47311 47312 * Romain Berrendonner 47313 47314 * Geert Bosch 47315 47316 * Emmanuel Briot 47317 47318 * Joel Brobecker 47319 47320 * Ben Brosgol 47321 47322 * Vincent Celier 47323 47324 * Arnaud Charlet 47325 47326 * Chien Chieng 47327 47328 * Cyrille Comar 47329 47330 * Cyrille Crozes 47331 47332 * Robert Dewar 47333 47334 * Gary Dismukes 47335 47336 * Robert Duff 47337 47338 * Ed Falis 47339 47340 * Ramon Fernandez 47341 47342 * Sam Figueroa 47343 47344 * Vasiliy Fofanov 47345 47346 * Michael Friess 47347 47348 * Franco Gasperoni 47349 47350 * Ted Giering 47351 47352 * Matthew Gingell 47353 47354 * Laurent Guerby 47355 47356 * Jerome Guitton 47357 47358 * Olivier Hainque 47359 47360 * Jerome Hugues 47361 47362 * Hristian Kirtchev 47363 47364 * Jerome Lambourg 47365 47366 * Bruno Leclerc 47367 47368 * Albert Lee 47369 47370 * Sean McNeil 47371 47372 * Javier Miranda 47373 47374 * Laurent Nana 47375 47376 * Pascal Obry 47377 47378 * Dong-Ik Oh 47379 47380 * Laurent Pautet 47381 47382 * Brett Porter 47383 47384 * Thomas Quinot 47385 47386 * Nicolas Roche 47387 47388 * Pat Rogers 47389 47390 * Jose Ruiz 47391 47392 * Douglas Rupp 47393 47394 * Sergey Rybin 47395 47396 * Gail Schenker 47397 47398 * Ed Schonberg 47399 47400 * Nicolas Setton 47401 47402 * Samuel Tardieu 47403 47404 The following people are recognized for their contributions of new 47405features, bug reports, testing and integration of classpath/libgcj for 47406GCC version 4.1: 47407 * Lillian Angel for 'JTree' implementation and lots Free Swing 47408 additions and bug fixes. 47409 47410 * Wolfgang Baer for 'GapContent' bug fixes. 47411 47412 * Anthony Balkissoon for 'JList', Free Swing 1.5 updates and mouse 47413 event fixes, lots of Free Swing work including 'JTable' editing. 47414 47415 * Stuart Ballard for RMI constant fixes. 47416 47417 * Goffredo Baroncelli for 'HTTPURLConnection' fixes. 47418 47419 * Gary Benson for 'MessageFormat' fixes. 47420 47421 * Daniel Bonniot for 'Serialization' fixes. 47422 47423 * Chris Burdess for lots of gnu.xml and http protocol fixes, 'StAX' 47424 and 'DOM xml:id' support. 47425 47426 * Ka-Hing Cheung for 'TreePath' and 'TreeSelection' fixes. 47427 47428 * Archie Cobbs for build fixes, VM interface updates, 47429 'URLClassLoader' updates. 47430 47431 * Kelley Cook for build fixes. 47432 47433 * Martin Cordova for Suggestions for better 'SocketTimeoutException'. 47434 47435 * David Daney for 'BitSet' bug fixes, 'HttpURLConnection' rewrite and 47436 improvements. 47437 47438 * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo 47439 2D support. Lots of imageio framework additions, lots of AWT and 47440 Free Swing bug fixes. 47441 47442 * Jeroen Frijters for 'ClassLoader' and nio cleanups, serialization 47443 fixes, better 'Proxy' support, bug fixes and IKVM integration. 47444 47445 * Santiago Gala for 'AccessControlContext' fixes. 47446 47447 * Nicolas Geoffray for 'VMClassLoader' and 'AccessController' 47448 improvements. 47449 47450 * David Gilbert for 'basic' and 'metal' icon and plaf support and 47451 lots of documenting, Lots of Free Swing and metal theme additions. 47452 'MetalIconFactory' implementation. 47453 47454 * Anthony Green for 'MIDI' framework, 'ALSA' and 'DSSI' providers. 47455 47456 * Andrew Haley for 'Serialization' and 'URLClassLoader' fixes, gcj 47457 build speedups. 47458 47459 * Kim Ho for 'JFileChooser' implementation. 47460 47461 * Andrew John Hughes for 'Locale' and net fixes, URI RFC2986 updates, 47462 'Serialization' fixes, 'Properties' XML support and generic branch 47463 work, VMIntegration guide update. 47464 47465 * Bastiaan Huisman for 'TimeZone' bug fixing. 47466 47467 * Andreas Jaeger for mprec updates. 47468 47469 * Paul Jenner for better '-Werror' support. 47470 47471 * Ito Kazumitsu for 'NetworkInterface' implementation and updates. 47472 47473 * Roman Kennke for 'BoxLayout', 'GrayFilter' and 'SplitPane', plus 47474 bug fixes all over. Lots of Free Swing work including styled text. 47475 47476 * Simon Kitching for 'String' cleanups and optimization suggestions. 47477 47478 * Michael Koch for configuration fixes, 'Locale' updates, bug and 47479 build fixes. 47480 47481 * Guilhem Lavaux for configuration, thread and channel fixes and 47482 Kaffe integration. JCL native 'Pointer' updates. Logger bug 47483 fixes. 47484 47485 * David Lichteblau for JCL support library global/local reference 47486 cleanups. 47487 47488 * Aaron Luchko for JDWP updates and documentation fixes. 47489 47490 * Ziga Mahkovec for 'Graphics2D' upgraded to Cairo 0.5 and new regex 47491 features. 47492 47493 * Sven de Marothy for BMP imageio support, CSS and 'TextLayout' 47494 fixes. 'GtkImage' rewrite, 2D, awt, free swing and date/time fixes 47495 and implementing the Qt4 peers. 47496 47497 * Casey Marshall for crypto algorithm fixes, 'FileChannel' lock, 47498 'SystemLogger' and 'FileHandler' rotate implementations, NIO 47499 'FileChannel.map' support, security and policy updates. 47500 47501 * Bryce McKinlay for RMI work. 47502 47503 * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus 47504 testing and documenting. 47505 47506 * Kalle Olavi Niemitalo for build fixes. 47507 47508 * Rainer Orth for build fixes. 47509 47510 * Andrew Overholt for 'File' locking fixes. 47511 47512 * Ingo Proetel for 'Image', 'Logger' and 'URLClassLoader' updates. 47513 47514 * Olga Rodimina for 'MenuSelectionManager' implementation. 47515 47516 * Jan Roehrich for 'BasicTreeUI' and 'JTree' fixes. 47517 47518 * Julian Scheid for documentation updates and gjdoc support. 47519 47520 * Christian Schlichtherle for zip fixes and cleanups. 47521 47522 * Robert Schuster for documentation updates and beans fixes, 47523 'TreeNode' enumerations and 'ActionCommand' and various fixes, XML 47524 and URL, AWT and Free Swing bug fixes. 47525 47526 * Keith Seitz for lots of JDWP work. 47527 47528 * Christian Thalinger for 64-bit cleanups, Configuration and VM 47529 interface fixes and 'CACAO' integration, 'fdlibm' updates. 47530 47531 * Gael Thomas for 'VMClassLoader' boot packages support suggestions. 47532 47533 * Andreas Tobler for Darwin and Solaris testing and fixing, 'Qt4' 47534 support for Darwin/OS X, 'Graphics2D' support, 'gtk+' updates. 47535 47536 * Dalibor Topic for better 'DEBUG' support, build cleanups and Kaffe 47537 integration. 'Qt4' build infrastructure, 'SHA1PRNG' and 47538 'GdkPixbugDecoder' updates. 47539 47540 * Tom Tromey for Eclipse integration, generics work, lots of bug 47541 fixes and gcj integration including coordinating The Big Merge. 47542 47543 * Mark Wielaard for bug fixes, packaging and release management, 47544 'Clipboard' implementation, system call interrupts and network 47545 timeouts and 'GdkPixpufDecoder' fixes. 47546 47547 In addition to the above, all of which also contributed time and energy 47548in testing GCC, we would like to thank the following for their 47549contributions to testing: 47550 47551 * Michael Abd-El-Malek 47552 47553 * Thomas Arend 47554 47555 * Bonzo Armstrong 47556 47557 * Steven Ashe 47558 47559 * Chris Baldwin 47560 47561 * David Billinghurst 47562 47563 * Jim Blandy 47564 47565 * Stephane Bortzmeyer 47566 47567 * Horst von Brand 47568 47569 * Frank Braun 47570 47571 * Rodney Brown 47572 47573 * Sidney Cadot 47574 47575 * Bradford Castalia 47576 47577 * Robert Clark 47578 47579 * Jonathan Corbet 47580 47581 * Ralph Doncaster 47582 47583 * Richard Emberson 47584 47585 * Levente Farkas 47586 47587 * Graham Fawcett 47588 47589 * Mark Fernyhough 47590 47591 * Robert A. French 47592 47593 * Jo"rgen Freyh 47594 47595 * Mark K. Gardner 47596 47597 * Charles-Antoine Gauthier 47598 47599 * Yung Shing Gene 47600 47601 * David Gilbert 47602 47603 * Simon Gornall 47604 47605 * Fred Gray 47606 47607 * John Griffin 47608 47609 * Patrik Hagglund 47610 47611 * Phil Hargett 47612 47613 * Amancio Hasty 47614 47615 * Takafumi Hayashi 47616 47617 * Bryan W. Headley 47618 47619 * Kevin B. Hendricks 47620 47621 * Joep Jansen 47622 47623 * Christian Joensson 47624 47625 * Michel Kern 47626 47627 * David Kidd 47628 47629 * Tobias Kuipers 47630 47631 * Anand Krishnaswamy 47632 47633 * A. O. V. Le Blanc 47634 47635 * llewelly 47636 47637 * Damon Love 47638 47639 * Brad Lucier 47640 47641 * Matthias Klose 47642 47643 * Martin Knoblauch 47644 47645 * Rick Lutowski 47646 47647 * Jesse Macnish 47648 47649 * Stefan Morrell 47650 47651 * Anon A. Mous 47652 47653 * Matthias Mueller 47654 47655 * Pekka Nikander 47656 47657 * Rick Niles 47658 47659 * Jon Olson 47660 47661 * Magnus Persson 47662 47663 * Chris Pollard 47664 47665 * Richard Polton 47666 47667 * Derk Reefman 47668 47669 * David Rees 47670 47671 * Paul Reilly 47672 47673 * Tom Reilly 47674 47675 * Torsten Rueger 47676 47677 * Danny Sadinoff 47678 47679 * Marc Schifer 47680 47681 * Erik Schnetter 47682 47683 * Wayne K. Schroll 47684 47685 * David Schuler 47686 47687 * Vin Shelton 47688 47689 * Tim Souder 47690 47691 * Adam Sulmicki 47692 47693 * Bill Thorson 47694 47695 * George Talbot 47696 47697 * Pedro A. M. Vazquez 47698 47699 * Gregory Warnes 47700 47701 * Ian Watson 47702 47703 * David E. Young 47704 47705 * And many others 47706 47707 And finally we'd like to thank everyone who uses the compiler, provides 47708feedback and generally reminds us why we're doing this work in the first 47709place. 47710 47711 47712File: gccint.info, Node: Option Index, Next: Concept Index, Prev: Contributors, Up: Top 47713 47714Option Index 47715************ 47716 47717GCC's command line options are indexed here without any initial '-' or 47718'--'. Where an option has both positive and negative forms (such as 47719'-fOPTION' and '-fno-OPTION'), relevant entries in the manual are 47720indexed under the most appropriate form; it may sometimes be useful to 47721look up both forms. 47722 47723�[index�] 47724* Menu: 47725 47726* fltrans: Internal flags. (line 18) 47727* fltrans-output-list: Internal flags. (line 23) 47728* fresolution: Internal flags. (line 27) 47729* fwpa: Internal flags. (line 9) 47730* msoft-float: Soft float library routines. 47731 (line 6) 47732 47733 47734File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top 47735 47736Concept Index 47737************* 47738 47739�[index�] 47740* Menu: 47741 47742* ! in constraint: Multi-Alternative. (line 48) 47743* # in constraint: Modifiers. (line 78) 47744* # in template: Output Template. (line 66) 47745* #pragma: Misc. (line 420) 47746* $ in constraint: Multi-Alternative. (line 57) 47747* % in constraint: Modifiers. (line 52) 47748* % in GTY option: GTY Options. (line 18) 47749* % in template: Output Template. (line 6) 47750* & in constraint: Modifiers. (line 25) 47751* (gimple: Logical Operators. (line 169) 47752* (gimple <1>: Logical Operators. (line 173) 47753* (gimple <2>: Logical Operators. (line 177) 47754* (gimple_stmt_iterator: GIMPLE API. (line 30) 47755* (nil): RTL Objects. (line 73) 47756* * in constraint: Modifiers. (line 83) 47757* * in template: Output Statement. (line 29) 47758* *gimple_build_asm_vec: GIMPLE_ASM. (line 6) 47759* *gimple_build_assign: GIMPLE_ASSIGN. (line 6) 47760* *gimple_build_assign <1>: GIMPLE_ASSIGN. (line 18) 47761* *gimple_build_assign <2>: GIMPLE_ASSIGN. (line 29) 47762* *gimple_build_assign <3>: GIMPLE_ASSIGN. (line 35) 47763* *gimple_build_bind: GIMPLE_BIND. (line 6) 47764* *gimple_build_call: GIMPLE_CALL. (line 6) 47765* *gimple_build_call_from_tree: GIMPLE_CALL. (line 15) 47766* *gimple_build_call_vec: GIMPLE_CALL. (line 25) 47767* *gimple_build_catch: GIMPLE_CATCH. (line 6) 47768* *gimple_build_cond: GIMPLE_COND. (line 6) 47769* *gimple_build_cond_from_tree: GIMPLE_COND. (line 14) 47770* *gimple_build_debug_bind: GIMPLE_DEBUG. (line 6) 47771* *gimple_build_eh_filter: GIMPLE_EH_FILTER. (line 6) 47772* *gimple_build_goto: GIMPLE_GOTO. (line 6) 47773* *gimple_build_label: GIMPLE_LABEL. (line 6) 47774* *gimple_build_omp_atomic_load: GIMPLE_OMP_ATOMIC_LOAD. 47775 (line 6) 47776* *gimple_build_omp_atomic_store: GIMPLE_OMP_ATOMIC_STORE. 47777 (line 6) 47778* *gimple_build_omp_continue: GIMPLE_OMP_CONTINUE. 47779 (line 6) 47780* *gimple_build_omp_critical: GIMPLE_OMP_CRITICAL. 47781 (line 6) 47782* *gimple_build_omp_for: GIMPLE_OMP_FOR. (line 6) 47783* *gimple_build_omp_parallel: GIMPLE_OMP_PARALLEL. 47784 (line 6) 47785* *gimple_build_omp_sections: GIMPLE_OMP_SECTIONS. 47786 (line 6) 47787* *gimple_build_omp_single: GIMPLE_OMP_SINGLE. (line 6) 47788* *gimple_build_resx: GIMPLE_RESX. (line 6) 47789* *gimple_build_return: GIMPLE_RETURN. (line 6) 47790* *gimple_build_switch: GIMPLE_SWITCH. (line 6) 47791* *gimple_build_try: GIMPLE_TRY. (line 6) 47792* + in constraint: Modifiers. (line 12) 47793* -fsection-anchors: Special Accessors. (line 117) 47794* -fsection-anchors <1>: Anchored Addresses. (line 6) 47795* /c in RTL dump: Flags. (line 230) 47796* /f in RTL dump: Flags. (line 238) 47797* /i in RTL dump: Flags. (line 283) 47798* /j in RTL dump: Flags. (line 295) 47799* /s in RTL dump: Flags. (line 254) 47800* /u in RTL dump: Flags. (line 307) 47801* /v in RTL dump: Flags. (line 339) 47802* 0 in constraint: Simple Constraints. (line 128) 47803* < in constraint: Simple Constraints. (line 47) 47804* = in constraint: Modifiers. (line 8) 47805* > in constraint: Simple Constraints. (line 59) 47806* ? in constraint: Multi-Alternative. (line 42) 47807* @ in instruction pattern names: Parameterized Names. 47808 (line 6) 47809* \: Output Template. (line 46) 47810* ^ in constraint: Multi-Alternative. (line 53) 47811* __absvdi2: Integer library routines. 47812 (line 106) 47813* __absvsi2: Integer library routines. 47814 (line 105) 47815* __addda3: Fixed-point fractional library routines. 47816 (line 52) 47817* __adddf3: Soft float library routines. 47818 (line 22) 47819* __adddq3: Fixed-point fractional library routines. 47820 (line 39) 47821* __addha3: Fixed-point fractional library routines. 47822 (line 49) 47823* __addhq3: Fixed-point fractional library routines. 47824 (line 37) 47825* __addqq3: Fixed-point fractional library routines. 47826 (line 35) 47827* __addsa3: Fixed-point fractional library routines. 47828 (line 51) 47829* __addsf3: Soft float library routines. 47830 (line 21) 47831* __addsq3: Fixed-point fractional library routines. 47832 (line 38) 47833* __addta3: Fixed-point fractional library routines. 47834 (line 53) 47835* __addtf3: Soft float library routines. 47836 (line 23) 47837* __adduda3: Fixed-point fractional library routines. 47838 (line 59) 47839* __addudq3: Fixed-point fractional library routines. 47840 (line 47) 47841* __adduha3: Fixed-point fractional library routines. 47842 (line 55) 47843* __adduhq3: Fixed-point fractional library routines. 47844 (line 43) 47845* __adduqq3: Fixed-point fractional library routines. 47846 (line 41) 47847* __addusa3: Fixed-point fractional library routines. 47848 (line 57) 47849* __addusq3: Fixed-point fractional library routines. 47850 (line 45) 47851* __adduta3: Fixed-point fractional library routines. 47852 (line 61) 47853* __addvdi3: Integer library routines. 47854 (line 110) 47855* __addvsi3: Integer library routines. 47856 (line 109) 47857* __addxf3: Soft float library routines. 47858 (line 25) 47859* __ashlda3: Fixed-point fractional library routines. 47860 (line 358) 47861* __ashldi3: Integer library routines. 47862 (line 13) 47863* __ashldq3: Fixed-point fractional library routines. 47864 (line 346) 47865* __ashlha3: Fixed-point fractional library routines. 47866 (line 356) 47867* __ashlhq3: Fixed-point fractional library routines. 47868 (line 344) 47869* __ashlqq3: Fixed-point fractional library routines. 47870 (line 343) 47871* __ashlsa3: Fixed-point fractional library routines. 47872 (line 357) 47873* __ashlsi3: Integer library routines. 47874 (line 12) 47875* __ashlsq3: Fixed-point fractional library routines. 47876 (line 345) 47877* __ashlta3: Fixed-point fractional library routines. 47878 (line 359) 47879* __ashlti3: Integer library routines. 47880 (line 14) 47881* __ashluda3: Fixed-point fractional library routines. 47882 (line 365) 47883* __ashludq3: Fixed-point fractional library routines. 47884 (line 354) 47885* __ashluha3: Fixed-point fractional library routines. 47886 (line 361) 47887* __ashluhq3: Fixed-point fractional library routines. 47888 (line 350) 47889* __ashluqq3: Fixed-point fractional library routines. 47890 (line 348) 47891* __ashlusa3: Fixed-point fractional library routines. 47892 (line 363) 47893* __ashlusq3: Fixed-point fractional library routines. 47894 (line 352) 47895* __ashluta3: Fixed-point fractional library routines. 47896 (line 367) 47897* __ashrda3: Fixed-point fractional library routines. 47898 (line 378) 47899* __ashrdi3: Integer library routines. 47900 (line 18) 47901* __ashrdq3: Fixed-point fractional library routines. 47902 (line 374) 47903* __ashrha3: Fixed-point fractional library routines. 47904 (line 376) 47905* __ashrhq3: Fixed-point fractional library routines. 47906 (line 372) 47907* __ashrqq3: Fixed-point fractional library routines. 47908 (line 371) 47909* __ashrsa3: Fixed-point fractional library routines. 47910 (line 377) 47911* __ashrsi3: Integer library routines. 47912 (line 17) 47913* __ashrsq3: Fixed-point fractional library routines. 47914 (line 373) 47915* __ashrta3: Fixed-point fractional library routines. 47916 (line 379) 47917* __ashrti3: Integer library routines. 47918 (line 19) 47919* __bid_adddd3: Decimal float library routines. 47920 (line 23) 47921* __bid_addsd3: Decimal float library routines. 47922 (line 19) 47923* __bid_addtd3: Decimal float library routines. 47924 (line 27) 47925* __bid_divdd3: Decimal float library routines. 47926 (line 66) 47927* __bid_divsd3: Decimal float library routines. 47928 (line 62) 47929* __bid_divtd3: Decimal float library routines. 47930 (line 70) 47931* __bid_eqdd2: Decimal float library routines. 47932 (line 258) 47933* __bid_eqsd2: Decimal float library routines. 47934 (line 256) 47935* __bid_eqtd2: Decimal float library routines. 47936 (line 260) 47937* __bid_extendddtd2: Decimal float library routines. 47938 (line 91) 47939* __bid_extendddtf: Decimal float library routines. 47940 (line 139) 47941* __bid_extendddxf: Decimal float library routines. 47942 (line 133) 47943* __bid_extenddfdd: Decimal float library routines. 47944 (line 146) 47945* __bid_extenddftd: Decimal float library routines. 47946 (line 106) 47947* __bid_extendsddd2: Decimal float library routines. 47948 (line 87) 47949* __bid_extendsddf: Decimal float library routines. 47950 (line 127) 47951* __bid_extendsdtd2: Decimal float library routines. 47952 (line 89) 47953* __bid_extendsdtf: Decimal float library routines. 47954 (line 137) 47955* __bid_extendsdxf: Decimal float library routines. 47956 (line 131) 47957* __bid_extendsfdd: Decimal float library routines. 47958 (line 102) 47959* __bid_extendsfsd: Decimal float library routines. 47960 (line 144) 47961* __bid_extendsftd: Decimal float library routines. 47962 (line 104) 47963* __bid_extendtftd: Decimal float library routines. 47964 (line 148) 47965* __bid_extendxftd: Decimal float library routines. 47966 (line 108) 47967* __bid_fixdddi: Decimal float library routines. 47968 (line 169) 47969* __bid_fixddsi: Decimal float library routines. 47970 (line 161) 47971* __bid_fixsddi: Decimal float library routines. 47972 (line 167) 47973* __bid_fixsdsi: Decimal float library routines. 47974 (line 159) 47975* __bid_fixtddi: Decimal float library routines. 47976 (line 171) 47977* __bid_fixtdsi: Decimal float library routines. 47978 (line 163) 47979* __bid_fixunsdddi: Decimal float library routines. 47980 (line 186) 47981* __bid_fixunsddsi: Decimal float library routines. 47982 (line 177) 47983* __bid_fixunssddi: Decimal float library routines. 47984 (line 184) 47985* __bid_fixunssdsi: Decimal float library routines. 47986 (line 175) 47987* __bid_fixunstddi: Decimal float library routines. 47988 (line 188) 47989* __bid_fixunstdsi: Decimal float library routines. 47990 (line 179) 47991* __bid_floatdidd: Decimal float library routines. 47992 (line 204) 47993* __bid_floatdisd: Decimal float library routines. 47994 (line 202) 47995* __bid_floatditd: Decimal float library routines. 47996 (line 206) 47997* __bid_floatsidd: Decimal float library routines. 47998 (line 195) 47999* __bid_floatsisd: Decimal float library routines. 48000 (line 193) 48001* __bid_floatsitd: Decimal float library routines. 48002 (line 197) 48003* __bid_floatunsdidd: Decimal float library routines. 48004 (line 222) 48005* __bid_floatunsdisd: Decimal float library routines. 48006 (line 220) 48007* __bid_floatunsditd: Decimal float library routines. 48008 (line 224) 48009* __bid_floatunssidd: Decimal float library routines. 48010 (line 213) 48011* __bid_floatunssisd: Decimal float library routines. 48012 (line 211) 48013* __bid_floatunssitd: Decimal float library routines. 48014 (line 215) 48015* __bid_gedd2: Decimal float library routines. 48016 (line 276) 48017* __bid_gesd2: Decimal float library routines. 48018 (line 274) 48019* __bid_getd2: Decimal float library routines. 48020 (line 278) 48021* __bid_gtdd2: Decimal float library routines. 48022 (line 303) 48023* __bid_gtsd2: Decimal float library routines. 48024 (line 301) 48025* __bid_gttd2: Decimal float library routines. 48026 (line 305) 48027* __bid_ledd2: Decimal float library routines. 48028 (line 294) 48029* __bid_lesd2: Decimal float library routines. 48030 (line 292) 48031* __bid_letd2: Decimal float library routines. 48032 (line 296) 48033* __bid_ltdd2: Decimal float library routines. 48034 (line 285) 48035* __bid_ltsd2: Decimal float library routines. 48036 (line 283) 48037* __bid_lttd2: Decimal float library routines. 48038 (line 287) 48039* __bid_muldd3: Decimal float library routines. 48040 (line 52) 48041* __bid_mulsd3: Decimal float library routines. 48042 (line 48) 48043* __bid_multd3: Decimal float library routines. 48044 (line 56) 48045* __bid_nedd2: Decimal float library routines. 48046 (line 267) 48047* __bid_negdd2: Decimal float library routines. 48048 (line 77) 48049* __bid_negsd2: Decimal float library routines. 48050 (line 75) 48051* __bid_negtd2: Decimal float library routines. 48052 (line 79) 48053* __bid_nesd2: Decimal float library routines. 48054 (line 265) 48055* __bid_netd2: Decimal float library routines. 48056 (line 269) 48057* __bid_subdd3: Decimal float library routines. 48058 (line 37) 48059* __bid_subsd3: Decimal float library routines. 48060 (line 33) 48061* __bid_subtd3: Decimal float library routines. 48062 (line 41) 48063* __bid_truncdddf: Decimal float library routines. 48064 (line 152) 48065* __bid_truncddsd2: Decimal float library routines. 48066 (line 93) 48067* __bid_truncddsf: Decimal float library routines. 48068 (line 123) 48069* __bid_truncdfsd: Decimal float library routines. 48070 (line 110) 48071* __bid_truncsdsf: Decimal float library routines. 48072 (line 150) 48073* __bid_trunctddd2: Decimal float library routines. 48074 (line 97) 48075* __bid_trunctddf: Decimal float library routines. 48076 (line 129) 48077* __bid_trunctdsd2: Decimal float library routines. 48078 (line 95) 48079* __bid_trunctdsf: Decimal float library routines. 48080 (line 125) 48081* __bid_trunctdtf: Decimal float library routines. 48082 (line 154) 48083* __bid_trunctdxf: Decimal float library routines. 48084 (line 135) 48085* __bid_trunctfdd: Decimal float library routines. 48086 (line 118) 48087* __bid_trunctfsd: Decimal float library routines. 48088 (line 114) 48089* __bid_truncxfdd: Decimal float library routines. 48090 (line 116) 48091* __bid_truncxfsd: Decimal float library routines. 48092 (line 112) 48093* __bid_unorddd2: Decimal float library routines. 48094 (line 234) 48095* __bid_unordsd2: Decimal float library routines. 48096 (line 232) 48097* __bid_unordtd2: Decimal float library routines. 48098 (line 236) 48099* __bswapdi2: Integer library routines. 48100 (line 161) 48101* __bswapsi2: Integer library routines. 48102 (line 160) 48103* __builtin_classify_type: Varargs. (line 48) 48104* __builtin_next_arg: Varargs. (line 39) 48105* __builtin_saveregs: Varargs. (line 22) 48106* __clear_cache: Miscellaneous routines. 48107 (line 9) 48108* __clzdi2: Integer library routines. 48109 (line 130) 48110* __clzsi2: Integer library routines. 48111 (line 129) 48112* __clzti2: Integer library routines. 48113 (line 131) 48114* __cmpda2: Fixed-point fractional library routines. 48115 (line 458) 48116* __cmpdf2: Soft float library routines. 48117 (line 163) 48118* __cmpdi2: Integer library routines. 48119 (line 86) 48120* __cmpdq2: Fixed-point fractional library routines. 48121 (line 447) 48122* __cmpha2: Fixed-point fractional library routines. 48123 (line 456) 48124* __cmphq2: Fixed-point fractional library routines. 48125 (line 445) 48126* __cmpqq2: Fixed-point fractional library routines. 48127 (line 444) 48128* __cmpsa2: Fixed-point fractional library routines. 48129 (line 457) 48130* __cmpsf2: Soft float library routines. 48131 (line 162) 48132* __cmpsq2: Fixed-point fractional library routines. 48133 (line 446) 48134* __cmpta2: Fixed-point fractional library routines. 48135 (line 459) 48136* __cmptf2: Soft float library routines. 48137 (line 164) 48138* __cmpti2: Integer library routines. 48139 (line 87) 48140* __cmpuda2: Fixed-point fractional library routines. 48141 (line 464) 48142* __cmpudq2: Fixed-point fractional library routines. 48143 (line 454) 48144* __cmpuha2: Fixed-point fractional library routines. 48145 (line 461) 48146* __cmpuhq2: Fixed-point fractional library routines. 48147 (line 451) 48148* __cmpuqq2: Fixed-point fractional library routines. 48149 (line 449) 48150* __cmpusa2: Fixed-point fractional library routines. 48151 (line 463) 48152* __cmpusq2: Fixed-point fractional library routines. 48153 (line 452) 48154* __cmputa2: Fixed-point fractional library routines. 48155 (line 466) 48156* __CTOR_LIST__: Initialization. (line 25) 48157* __ctzdi2: Integer library routines. 48158 (line 137) 48159* __ctzsi2: Integer library routines. 48160 (line 136) 48161* __ctzti2: Integer library routines. 48162 (line 138) 48163* __divda3: Fixed-point fractional library routines. 48164 (line 234) 48165* __divdc3: Soft float library routines. 48166 (line 250) 48167* __divdf3: Soft float library routines. 48168 (line 47) 48169* __divdi3: Integer library routines. 48170 (line 24) 48171* __divdq3: Fixed-point fractional library routines. 48172 (line 229) 48173* __divha3: Fixed-point fractional library routines. 48174 (line 231) 48175* __divhq3: Fixed-point fractional library routines. 48176 (line 227) 48177* __divqq3: Fixed-point fractional library routines. 48178 (line 225) 48179* __divsa3: Fixed-point fractional library routines. 48180 (line 233) 48181* __divsc3: Soft float library routines. 48182 (line 248) 48183* __divsf3: Soft float library routines. 48184 (line 46) 48185* __divsi3: Integer library routines. 48186 (line 23) 48187* __divsq3: Fixed-point fractional library routines. 48188 (line 228) 48189* __divta3: Fixed-point fractional library routines. 48190 (line 235) 48191* __divtc3: Soft float library routines. 48192 (line 252) 48193* __divtf3: Soft float library routines. 48194 (line 48) 48195* __divti3: Integer library routines. 48196 (line 25) 48197* __divxc3: Soft float library routines. 48198 (line 254) 48199* __divxf3: Soft float library routines. 48200 (line 50) 48201* __dpd_adddd3: Decimal float library routines. 48202 (line 21) 48203* __dpd_addsd3: Decimal float library routines. 48204 (line 17) 48205* __dpd_addtd3: Decimal float library routines. 48206 (line 25) 48207* __dpd_divdd3: Decimal float library routines. 48208 (line 64) 48209* __dpd_divsd3: Decimal float library routines. 48210 (line 60) 48211* __dpd_divtd3: Decimal float library routines. 48212 (line 68) 48213* __dpd_eqdd2: Decimal float library routines. 48214 (line 257) 48215* __dpd_eqsd2: Decimal float library routines. 48216 (line 255) 48217* __dpd_eqtd2: Decimal float library routines. 48218 (line 259) 48219* __dpd_extendddtd2: Decimal float library routines. 48220 (line 90) 48221* __dpd_extendddtf: Decimal float library routines. 48222 (line 138) 48223* __dpd_extendddxf: Decimal float library routines. 48224 (line 132) 48225* __dpd_extenddfdd: Decimal float library routines. 48226 (line 145) 48227* __dpd_extenddftd: Decimal float library routines. 48228 (line 105) 48229* __dpd_extendsddd2: Decimal float library routines. 48230 (line 86) 48231* __dpd_extendsddf: Decimal float library routines. 48232 (line 126) 48233* __dpd_extendsdtd2: Decimal float library routines. 48234 (line 88) 48235* __dpd_extendsdtf: Decimal float library routines. 48236 (line 136) 48237* __dpd_extendsdxf: Decimal float library routines. 48238 (line 130) 48239* __dpd_extendsfdd: Decimal float library routines. 48240 (line 101) 48241* __dpd_extendsfsd: Decimal float library routines. 48242 (line 143) 48243* __dpd_extendsftd: Decimal float library routines. 48244 (line 103) 48245* __dpd_extendtftd: Decimal float library routines. 48246 (line 147) 48247* __dpd_extendxftd: Decimal float library routines. 48248 (line 107) 48249* __dpd_fixdddi: Decimal float library routines. 48250 (line 168) 48251* __dpd_fixddsi: Decimal float library routines. 48252 (line 160) 48253* __dpd_fixsddi: Decimal float library routines. 48254 (line 166) 48255* __dpd_fixsdsi: Decimal float library routines. 48256 (line 158) 48257* __dpd_fixtddi: Decimal float library routines. 48258 (line 170) 48259* __dpd_fixtdsi: Decimal float library routines. 48260 (line 162) 48261* __dpd_fixunsdddi: Decimal float library routines. 48262 (line 185) 48263* __dpd_fixunsddsi: Decimal float library routines. 48264 (line 176) 48265* __dpd_fixunssddi: Decimal float library routines. 48266 (line 183) 48267* __dpd_fixunssdsi: Decimal float library routines. 48268 (line 174) 48269* __dpd_fixunstddi: Decimal float library routines. 48270 (line 187) 48271* __dpd_fixunstdsi: Decimal float library routines. 48272 (line 178) 48273* __dpd_floatdidd: Decimal float library routines. 48274 (line 203) 48275* __dpd_floatdisd: Decimal float library routines. 48276 (line 201) 48277* __dpd_floatditd: Decimal float library routines. 48278 (line 205) 48279* __dpd_floatsidd: Decimal float library routines. 48280 (line 194) 48281* __dpd_floatsisd: Decimal float library routines. 48282 (line 192) 48283* __dpd_floatsitd: Decimal float library routines. 48284 (line 196) 48285* __dpd_floatunsdidd: Decimal float library routines. 48286 (line 221) 48287* __dpd_floatunsdisd: Decimal float library routines. 48288 (line 219) 48289* __dpd_floatunsditd: Decimal float library routines. 48290 (line 223) 48291* __dpd_floatunssidd: Decimal float library routines. 48292 (line 212) 48293* __dpd_floatunssisd: Decimal float library routines. 48294 (line 210) 48295* __dpd_floatunssitd: Decimal float library routines. 48296 (line 214) 48297* __dpd_gedd2: Decimal float library routines. 48298 (line 275) 48299* __dpd_gesd2: Decimal float library routines. 48300 (line 273) 48301* __dpd_getd2: Decimal float library routines. 48302 (line 277) 48303* __dpd_gtdd2: Decimal float library routines. 48304 (line 302) 48305* __dpd_gtsd2: Decimal float library routines. 48306 (line 300) 48307* __dpd_gttd2: Decimal float library routines. 48308 (line 304) 48309* __dpd_ledd2: Decimal float library routines. 48310 (line 293) 48311* __dpd_lesd2: Decimal float library routines. 48312 (line 291) 48313* __dpd_letd2: Decimal float library routines. 48314 (line 295) 48315* __dpd_ltdd2: Decimal float library routines. 48316 (line 284) 48317* __dpd_ltsd2: Decimal float library routines. 48318 (line 282) 48319* __dpd_lttd2: Decimal float library routines. 48320 (line 286) 48321* __dpd_muldd3: Decimal float library routines. 48322 (line 50) 48323* __dpd_mulsd3: Decimal float library routines. 48324 (line 46) 48325* __dpd_multd3: Decimal float library routines. 48326 (line 54) 48327* __dpd_nedd2: Decimal float library routines. 48328 (line 266) 48329* __dpd_negdd2: Decimal float library routines. 48330 (line 76) 48331* __dpd_negsd2: Decimal float library routines. 48332 (line 74) 48333* __dpd_negtd2: Decimal float library routines. 48334 (line 78) 48335* __dpd_nesd2: Decimal float library routines. 48336 (line 264) 48337* __dpd_netd2: Decimal float library routines. 48338 (line 268) 48339* __dpd_subdd3: Decimal float library routines. 48340 (line 35) 48341* __dpd_subsd3: Decimal float library routines. 48342 (line 31) 48343* __dpd_subtd3: Decimal float library routines. 48344 (line 39) 48345* __dpd_truncdddf: Decimal float library routines. 48346 (line 151) 48347* __dpd_truncddsd2: Decimal float library routines. 48348 (line 92) 48349* __dpd_truncddsf: Decimal float library routines. 48350 (line 122) 48351* __dpd_truncdfsd: Decimal float library routines. 48352 (line 109) 48353* __dpd_truncsdsf: Decimal float library routines. 48354 (line 149) 48355* __dpd_trunctddd2: Decimal float library routines. 48356 (line 96) 48357* __dpd_trunctddf: Decimal float library routines. 48358 (line 128) 48359* __dpd_trunctdsd2: Decimal float library routines. 48360 (line 94) 48361* __dpd_trunctdsf: Decimal float library routines. 48362 (line 124) 48363* __dpd_trunctdtf: Decimal float library routines. 48364 (line 153) 48365* __dpd_trunctdxf: Decimal float library routines. 48366 (line 134) 48367* __dpd_trunctfdd: Decimal float library routines. 48368 (line 117) 48369* __dpd_trunctfsd: Decimal float library routines. 48370 (line 113) 48371* __dpd_truncxfdd: Decimal float library routines. 48372 (line 115) 48373* __dpd_truncxfsd: Decimal float library routines. 48374 (line 111) 48375* __dpd_unorddd2: Decimal float library routines. 48376 (line 233) 48377* __dpd_unordsd2: Decimal float library routines. 48378 (line 231) 48379* __dpd_unordtd2: Decimal float library routines. 48380 (line 235) 48381* __DTOR_LIST__: Initialization. (line 25) 48382* __eqdf2: Soft float library routines. 48383 (line 193) 48384* __eqsf2: Soft float library routines. 48385 (line 192) 48386* __eqtf2: Soft float library routines. 48387 (line 194) 48388* __extenddftf2: Soft float library routines. 48389 (line 67) 48390* __extenddfxf2: Soft float library routines. 48391 (line 68) 48392* __extendsfdf2: Soft float library routines. 48393 (line 64) 48394* __extendsftf2: Soft float library routines. 48395 (line 65) 48396* __extendsfxf2: Soft float library routines. 48397 (line 66) 48398* __ffsdi2: Integer library routines. 48399 (line 143) 48400* __ffsti2: Integer library routines. 48401 (line 144) 48402* __fixdfdi: Soft float library routines. 48403 (line 87) 48404* __fixdfsi: Soft float library routines. 48405 (line 80) 48406* __fixdfti: Soft float library routines. 48407 (line 93) 48408* __fixsfdi: Soft float library routines. 48409 (line 86) 48410* __fixsfsi: Soft float library routines. 48411 (line 79) 48412* __fixsfti: Soft float library routines. 48413 (line 92) 48414* __fixtfdi: Soft float library routines. 48415 (line 88) 48416* __fixtfsi: Soft float library routines. 48417 (line 81) 48418* __fixtfti: Soft float library routines. 48419 (line 94) 48420* __fixunsdfdi: Soft float library routines. 48421 (line 107) 48422* __fixunsdfsi: Soft float library routines. 48423 (line 100) 48424* __fixunsdfti: Soft float library routines. 48425 (line 114) 48426* __fixunssfdi: Soft float library routines. 48427 (line 106) 48428* __fixunssfsi: Soft float library routines. 48429 (line 99) 48430* __fixunssfti: Soft float library routines. 48431 (line 113) 48432* __fixunstfdi: Soft float library routines. 48433 (line 108) 48434* __fixunstfsi: Soft float library routines. 48435 (line 101) 48436* __fixunstfti: Soft float library routines. 48437 (line 115) 48438* __fixunsxfdi: Soft float library routines. 48439 (line 109) 48440* __fixunsxfsi: Soft float library routines. 48441 (line 102) 48442* __fixunsxfti: Soft float library routines. 48443 (line 116) 48444* __fixxfdi: Soft float library routines. 48445 (line 89) 48446* __fixxfsi: Soft float library routines. 48447 (line 82) 48448* __fixxfti: Soft float library routines. 48449 (line 95) 48450* __floatdidf: Soft float library routines. 48451 (line 127) 48452* __floatdisf: Soft float library routines. 48453 (line 126) 48454* __floatditf: Soft float library routines. 48455 (line 128) 48456* __floatdixf: Soft float library routines. 48457 (line 129) 48458* __floatsidf: Soft float library routines. 48459 (line 121) 48460* __floatsisf: Soft float library routines. 48461 (line 120) 48462* __floatsitf: Soft float library routines. 48463 (line 122) 48464* __floatsixf: Soft float library routines. 48465 (line 123) 48466* __floattidf: Soft float library routines. 48467 (line 133) 48468* __floattisf: Soft float library routines. 48469 (line 132) 48470* __floattitf: Soft float library routines. 48471 (line 134) 48472* __floattixf: Soft float library routines. 48473 (line 135) 48474* __floatundidf: Soft float library routines. 48475 (line 145) 48476* __floatundisf: Soft float library routines. 48477 (line 144) 48478* __floatunditf: Soft float library routines. 48479 (line 146) 48480* __floatundixf: Soft float library routines. 48481 (line 147) 48482* __floatunsidf: Soft float library routines. 48483 (line 139) 48484* __floatunsisf: Soft float library routines. 48485 (line 138) 48486* __floatunsitf: Soft float library routines. 48487 (line 140) 48488* __floatunsixf: Soft float library routines. 48489 (line 141) 48490* __floatuntidf: Soft float library routines. 48491 (line 151) 48492* __floatuntisf: Soft float library routines. 48493 (line 150) 48494* __floatuntitf: Soft float library routines. 48495 (line 152) 48496* __floatuntixf: Soft float library routines. 48497 (line 153) 48498* __fractdadf: Fixed-point fractional library routines. 48499 (line 643) 48500* __fractdadi: Fixed-point fractional library routines. 48501 (line 640) 48502* __fractdadq: Fixed-point fractional library routines. 48503 (line 623) 48504* __fractdaha2: Fixed-point fractional library routines. 48505 (line 624) 48506* __fractdahi: Fixed-point fractional library routines. 48507 (line 638) 48508* __fractdahq: Fixed-point fractional library routines. 48509 (line 621) 48510* __fractdaqi: Fixed-point fractional library routines. 48511 (line 637) 48512* __fractdaqq: Fixed-point fractional library routines. 48513 (line 620) 48514* __fractdasa2: Fixed-point fractional library routines. 48515 (line 625) 48516* __fractdasf: Fixed-point fractional library routines. 48517 (line 642) 48518* __fractdasi: Fixed-point fractional library routines. 48519 (line 639) 48520* __fractdasq: Fixed-point fractional library routines. 48521 (line 622) 48522* __fractdata2: Fixed-point fractional library routines. 48523 (line 626) 48524* __fractdati: Fixed-point fractional library routines. 48525 (line 641) 48526* __fractdauda: Fixed-point fractional library routines. 48527 (line 634) 48528* __fractdaudq: Fixed-point fractional library routines. 48529 (line 630) 48530* __fractdauha: Fixed-point fractional library routines. 48531 (line 632) 48532* __fractdauhq: Fixed-point fractional library routines. 48533 (line 628) 48534* __fractdauqq: Fixed-point fractional library routines. 48535 (line 627) 48536* __fractdausa: Fixed-point fractional library routines. 48537 (line 633) 48538* __fractdausq: Fixed-point fractional library routines. 48539 (line 629) 48540* __fractdauta: Fixed-point fractional library routines. 48541 (line 635) 48542* __fractdfda: Fixed-point fractional library routines. 48543 (line 1032) 48544* __fractdfdq: Fixed-point fractional library routines. 48545 (line 1029) 48546* __fractdfha: Fixed-point fractional library routines. 48547 (line 1030) 48548* __fractdfhq: Fixed-point fractional library routines. 48549 (line 1027) 48550* __fractdfqq: Fixed-point fractional library routines. 48551 (line 1026) 48552* __fractdfsa: Fixed-point fractional library routines. 48553 (line 1031) 48554* __fractdfsq: Fixed-point fractional library routines. 48555 (line 1028) 48556* __fractdfta: Fixed-point fractional library routines. 48557 (line 1033) 48558* __fractdfuda: Fixed-point fractional library routines. 48559 (line 1040) 48560* __fractdfudq: Fixed-point fractional library routines. 48561 (line 1037) 48562* __fractdfuha: Fixed-point fractional library routines. 48563 (line 1038) 48564* __fractdfuhq: Fixed-point fractional library routines. 48565 (line 1035) 48566* __fractdfuqq: Fixed-point fractional library routines. 48567 (line 1034) 48568* __fractdfusa: Fixed-point fractional library routines. 48569 (line 1039) 48570* __fractdfusq: Fixed-point fractional library routines. 48571 (line 1036) 48572* __fractdfuta: Fixed-point fractional library routines. 48573 (line 1041) 48574* __fractdida: Fixed-point fractional library routines. 48575 (line 982) 48576* __fractdidq: Fixed-point fractional library routines. 48577 (line 979) 48578* __fractdiha: Fixed-point fractional library routines. 48579 (line 980) 48580* __fractdihq: Fixed-point fractional library routines. 48581 (line 977) 48582* __fractdiqq: Fixed-point fractional library routines. 48583 (line 976) 48584* __fractdisa: Fixed-point fractional library routines. 48585 (line 981) 48586* __fractdisq: Fixed-point fractional library routines. 48587 (line 978) 48588* __fractdita: Fixed-point fractional library routines. 48589 (line 983) 48590* __fractdiuda: Fixed-point fractional library routines. 48591 (line 990) 48592* __fractdiudq: Fixed-point fractional library routines. 48593 (line 987) 48594* __fractdiuha: Fixed-point fractional library routines. 48595 (line 988) 48596* __fractdiuhq: Fixed-point fractional library routines. 48597 (line 985) 48598* __fractdiuqq: Fixed-point fractional library routines. 48599 (line 984) 48600* __fractdiusa: Fixed-point fractional library routines. 48601 (line 989) 48602* __fractdiusq: Fixed-point fractional library routines. 48603 (line 986) 48604* __fractdiuta: Fixed-point fractional library routines. 48605 (line 991) 48606* __fractdqda: Fixed-point fractional library routines. 48607 (line 551) 48608* __fractdqdf: Fixed-point fractional library routines. 48609 (line 573) 48610* __fractdqdi: Fixed-point fractional library routines. 48611 (line 570) 48612* __fractdqha: Fixed-point fractional library routines. 48613 (line 549) 48614* __fractdqhi: Fixed-point fractional library routines. 48615 (line 568) 48616* __fractdqhq2: Fixed-point fractional library routines. 48617 (line 547) 48618* __fractdqqi: Fixed-point fractional library routines. 48619 (line 567) 48620* __fractdqqq2: Fixed-point fractional library routines. 48621 (line 546) 48622* __fractdqsa: Fixed-point fractional library routines. 48623 (line 550) 48624* __fractdqsf: Fixed-point fractional library routines. 48625 (line 572) 48626* __fractdqsi: Fixed-point fractional library routines. 48627 (line 569) 48628* __fractdqsq2: Fixed-point fractional library routines. 48629 (line 548) 48630* __fractdqta: Fixed-point fractional library routines. 48631 (line 552) 48632* __fractdqti: Fixed-point fractional library routines. 48633 (line 571) 48634* __fractdquda: Fixed-point fractional library routines. 48635 (line 563) 48636* __fractdqudq: Fixed-point fractional library routines. 48637 (line 558) 48638* __fractdquha: Fixed-point fractional library routines. 48639 (line 560) 48640* __fractdquhq: Fixed-point fractional library routines. 48641 (line 555) 48642* __fractdquqq: Fixed-point fractional library routines. 48643 (line 553) 48644* __fractdqusa: Fixed-point fractional library routines. 48645 (line 562) 48646* __fractdqusq: Fixed-point fractional library routines. 48647 (line 556) 48648* __fractdquta: Fixed-point fractional library routines. 48649 (line 565) 48650* __fracthada2: Fixed-point fractional library routines. 48651 (line 579) 48652* __fracthadf: Fixed-point fractional library routines. 48653 (line 597) 48654* __fracthadi: Fixed-point fractional library routines. 48655 (line 594) 48656* __fracthadq: Fixed-point fractional library routines. 48657 (line 577) 48658* __fracthahi: Fixed-point fractional library routines. 48659 (line 592) 48660* __fracthahq: Fixed-point fractional library routines. 48661 (line 575) 48662* __fracthaqi: Fixed-point fractional library routines. 48663 (line 591) 48664* __fracthaqq: Fixed-point fractional library routines. 48665 (line 574) 48666* __fracthasa2: Fixed-point fractional library routines. 48667 (line 578) 48668* __fracthasf: Fixed-point fractional library routines. 48669 (line 596) 48670* __fracthasi: Fixed-point fractional library routines. 48671 (line 593) 48672* __fracthasq: Fixed-point fractional library routines. 48673 (line 576) 48674* __fracthata2: Fixed-point fractional library routines. 48675 (line 580) 48676* __fracthati: Fixed-point fractional library routines. 48677 (line 595) 48678* __fracthauda: Fixed-point fractional library routines. 48679 (line 588) 48680* __fracthaudq: Fixed-point fractional library routines. 48681 (line 584) 48682* __fracthauha: Fixed-point fractional library routines. 48683 (line 586) 48684* __fracthauhq: Fixed-point fractional library routines. 48685 (line 582) 48686* __fracthauqq: Fixed-point fractional library routines. 48687 (line 581) 48688* __fracthausa: Fixed-point fractional library routines. 48689 (line 587) 48690* __fracthausq: Fixed-point fractional library routines. 48691 (line 583) 48692* __fracthauta: Fixed-point fractional library routines. 48693 (line 589) 48694* __fracthida: Fixed-point fractional library routines. 48695 (line 950) 48696* __fracthidq: Fixed-point fractional library routines. 48697 (line 947) 48698* __fracthiha: Fixed-point fractional library routines. 48699 (line 948) 48700* __fracthihq: Fixed-point fractional library routines. 48701 (line 945) 48702* __fracthiqq: Fixed-point fractional library routines. 48703 (line 944) 48704* __fracthisa: Fixed-point fractional library routines. 48705 (line 949) 48706* __fracthisq: Fixed-point fractional library routines. 48707 (line 946) 48708* __fracthita: Fixed-point fractional library routines. 48709 (line 951) 48710* __fracthiuda: Fixed-point fractional library routines. 48711 (line 958) 48712* __fracthiudq: Fixed-point fractional library routines. 48713 (line 955) 48714* __fracthiuha: Fixed-point fractional library routines. 48715 (line 956) 48716* __fracthiuhq: Fixed-point fractional library routines. 48717 (line 953) 48718* __fracthiuqq: Fixed-point fractional library routines. 48719 (line 952) 48720* __fracthiusa: Fixed-point fractional library routines. 48721 (line 957) 48722* __fracthiusq: Fixed-point fractional library routines. 48723 (line 954) 48724* __fracthiuta: Fixed-point fractional library routines. 48725 (line 959) 48726* __fracthqda: Fixed-point fractional library routines. 48727 (line 505) 48728* __fracthqdf: Fixed-point fractional library routines. 48729 (line 521) 48730* __fracthqdi: Fixed-point fractional library routines. 48731 (line 518) 48732* __fracthqdq2: Fixed-point fractional library routines. 48733 (line 502) 48734* __fracthqha: Fixed-point fractional library routines. 48735 (line 503) 48736* __fracthqhi: Fixed-point fractional library routines. 48737 (line 516) 48738* __fracthqqi: Fixed-point fractional library routines. 48739 (line 515) 48740* __fracthqqq2: Fixed-point fractional library routines. 48741 (line 500) 48742* __fracthqsa: Fixed-point fractional library routines. 48743 (line 504) 48744* __fracthqsf: Fixed-point fractional library routines. 48745 (line 520) 48746* __fracthqsi: Fixed-point fractional library routines. 48747 (line 517) 48748* __fracthqsq2: Fixed-point fractional library routines. 48749 (line 501) 48750* __fracthqta: Fixed-point fractional library routines. 48751 (line 506) 48752* __fracthqti: Fixed-point fractional library routines. 48753 (line 519) 48754* __fracthquda: Fixed-point fractional library routines. 48755 (line 513) 48756* __fracthqudq: Fixed-point fractional library routines. 48757 (line 510) 48758* __fracthquha: Fixed-point fractional library routines. 48759 (line 511) 48760* __fracthquhq: Fixed-point fractional library routines. 48761 (line 508) 48762* __fracthquqq: Fixed-point fractional library routines. 48763 (line 507) 48764* __fracthqusa: Fixed-point fractional library routines. 48765 (line 512) 48766* __fracthqusq: Fixed-point fractional library routines. 48767 (line 509) 48768* __fracthquta: Fixed-point fractional library routines. 48769 (line 514) 48770* __fractqida: Fixed-point fractional library routines. 48771 (line 932) 48772* __fractqidq: Fixed-point fractional library routines. 48773 (line 929) 48774* __fractqiha: Fixed-point fractional library routines. 48775 (line 930) 48776* __fractqihq: Fixed-point fractional library routines. 48777 (line 927) 48778* __fractqiqq: Fixed-point fractional library routines. 48779 (line 926) 48780* __fractqisa: Fixed-point fractional library routines. 48781 (line 931) 48782* __fractqisq: Fixed-point fractional library routines. 48783 (line 928) 48784* __fractqita: Fixed-point fractional library routines. 48785 (line 933) 48786* __fractqiuda: Fixed-point fractional library routines. 48787 (line 941) 48788* __fractqiudq: Fixed-point fractional library routines. 48789 (line 937) 48790* __fractqiuha: Fixed-point fractional library routines. 48791 (line 939) 48792* __fractqiuhq: Fixed-point fractional library routines. 48793 (line 935) 48794* __fractqiuqq: Fixed-point fractional library routines. 48795 (line 934) 48796* __fractqiusa: Fixed-point fractional library routines. 48797 (line 940) 48798* __fractqiusq: Fixed-point fractional library routines. 48799 (line 936) 48800* __fractqiuta: Fixed-point fractional library routines. 48801 (line 942) 48802* __fractqqda: Fixed-point fractional library routines. 48803 (line 481) 48804* __fractqqdf: Fixed-point fractional library routines. 48805 (line 499) 48806* __fractqqdi: Fixed-point fractional library routines. 48807 (line 496) 48808* __fractqqdq2: Fixed-point fractional library routines. 48809 (line 478) 48810* __fractqqha: Fixed-point fractional library routines. 48811 (line 479) 48812* __fractqqhi: Fixed-point fractional library routines. 48813 (line 494) 48814* __fractqqhq2: Fixed-point fractional library routines. 48815 (line 476) 48816* __fractqqqi: Fixed-point fractional library routines. 48817 (line 493) 48818* __fractqqsa: Fixed-point fractional library routines. 48819 (line 480) 48820* __fractqqsf: Fixed-point fractional library routines. 48821 (line 498) 48822* __fractqqsi: Fixed-point fractional library routines. 48823 (line 495) 48824* __fractqqsq2: Fixed-point fractional library routines. 48825 (line 477) 48826* __fractqqta: Fixed-point fractional library routines. 48827 (line 482) 48828* __fractqqti: Fixed-point fractional library routines. 48829 (line 497) 48830* __fractqquda: Fixed-point fractional library routines. 48831 (line 490) 48832* __fractqqudq: Fixed-point fractional library routines. 48833 (line 486) 48834* __fractqquha: Fixed-point fractional library routines. 48835 (line 488) 48836* __fractqquhq: Fixed-point fractional library routines. 48837 (line 484) 48838* __fractqquqq: Fixed-point fractional library routines. 48839 (line 483) 48840* __fractqqusa: Fixed-point fractional library routines. 48841 (line 489) 48842* __fractqqusq: Fixed-point fractional library routines. 48843 (line 485) 48844* __fractqquta: Fixed-point fractional library routines. 48845 (line 491) 48846* __fractsada2: Fixed-point fractional library routines. 48847 (line 603) 48848* __fractsadf: Fixed-point fractional library routines. 48849 (line 619) 48850* __fractsadi: Fixed-point fractional library routines. 48851 (line 616) 48852* __fractsadq: Fixed-point fractional library routines. 48853 (line 601) 48854* __fractsaha2: Fixed-point fractional library routines. 48855 (line 602) 48856* __fractsahi: Fixed-point fractional library routines. 48857 (line 614) 48858* __fractsahq: Fixed-point fractional library routines. 48859 (line 599) 48860* __fractsaqi: Fixed-point fractional library routines. 48861 (line 613) 48862* __fractsaqq: Fixed-point fractional library routines. 48863 (line 598) 48864* __fractsasf: Fixed-point fractional library routines. 48865 (line 618) 48866* __fractsasi: Fixed-point fractional library routines. 48867 (line 615) 48868* __fractsasq: Fixed-point fractional library routines. 48869 (line 600) 48870* __fractsata2: Fixed-point fractional library routines. 48871 (line 604) 48872* __fractsati: Fixed-point fractional library routines. 48873 (line 617) 48874* __fractsauda: Fixed-point fractional library routines. 48875 (line 611) 48876* __fractsaudq: Fixed-point fractional library routines. 48877 (line 608) 48878* __fractsauha: Fixed-point fractional library routines. 48879 (line 609) 48880* __fractsauhq: Fixed-point fractional library routines. 48881 (line 606) 48882* __fractsauqq: Fixed-point fractional library routines. 48883 (line 605) 48884* __fractsausa: Fixed-point fractional library routines. 48885 (line 610) 48886* __fractsausq: Fixed-point fractional library routines. 48887 (line 607) 48888* __fractsauta: Fixed-point fractional library routines. 48889 (line 612) 48890* __fractsfda: Fixed-point fractional library routines. 48891 (line 1016) 48892* __fractsfdq: Fixed-point fractional library routines. 48893 (line 1013) 48894* __fractsfha: Fixed-point fractional library routines. 48895 (line 1014) 48896* __fractsfhq: Fixed-point fractional library routines. 48897 (line 1011) 48898* __fractsfqq: Fixed-point fractional library routines. 48899 (line 1010) 48900* __fractsfsa: Fixed-point fractional library routines. 48901 (line 1015) 48902* __fractsfsq: Fixed-point fractional library routines. 48903 (line 1012) 48904* __fractsfta: Fixed-point fractional library routines. 48905 (line 1017) 48906* __fractsfuda: Fixed-point fractional library routines. 48907 (line 1024) 48908* __fractsfudq: Fixed-point fractional library routines. 48909 (line 1021) 48910* __fractsfuha: Fixed-point fractional library routines. 48911 (line 1022) 48912* __fractsfuhq: Fixed-point fractional library routines. 48913 (line 1019) 48914* __fractsfuqq: Fixed-point fractional library routines. 48915 (line 1018) 48916* __fractsfusa: Fixed-point fractional library routines. 48917 (line 1023) 48918* __fractsfusq: Fixed-point fractional library routines. 48919 (line 1020) 48920* __fractsfuta: Fixed-point fractional library routines. 48921 (line 1025) 48922* __fractsida: Fixed-point fractional library routines. 48923 (line 966) 48924* __fractsidq: Fixed-point fractional library routines. 48925 (line 963) 48926* __fractsiha: Fixed-point fractional library routines. 48927 (line 964) 48928* __fractsihq: Fixed-point fractional library routines. 48929 (line 961) 48930* __fractsiqq: Fixed-point fractional library routines. 48931 (line 960) 48932* __fractsisa: Fixed-point fractional library routines. 48933 (line 965) 48934* __fractsisq: Fixed-point fractional library routines. 48935 (line 962) 48936* __fractsita: Fixed-point fractional library routines. 48937 (line 967) 48938* __fractsiuda: Fixed-point fractional library routines. 48939 (line 974) 48940* __fractsiudq: Fixed-point fractional library routines. 48941 (line 971) 48942* __fractsiuha: Fixed-point fractional library routines. 48943 (line 972) 48944* __fractsiuhq: Fixed-point fractional library routines. 48945 (line 969) 48946* __fractsiuqq: Fixed-point fractional library routines. 48947 (line 968) 48948* __fractsiusa: Fixed-point fractional library routines. 48949 (line 973) 48950* __fractsiusq: Fixed-point fractional library routines. 48951 (line 970) 48952* __fractsiuta: Fixed-point fractional library routines. 48953 (line 975) 48954* __fractsqda: Fixed-point fractional library routines. 48955 (line 527) 48956* __fractsqdf: Fixed-point fractional library routines. 48957 (line 545) 48958* __fractsqdi: Fixed-point fractional library routines. 48959 (line 542) 48960* __fractsqdq2: Fixed-point fractional library routines. 48961 (line 524) 48962* __fractsqha: Fixed-point fractional library routines. 48963 (line 525) 48964* __fractsqhi: Fixed-point fractional library routines. 48965 (line 540) 48966* __fractsqhq2: Fixed-point fractional library routines. 48967 (line 523) 48968* __fractsqqi: Fixed-point fractional library routines. 48969 (line 539) 48970* __fractsqqq2: Fixed-point fractional library routines. 48971 (line 522) 48972* __fractsqsa: Fixed-point fractional library routines. 48973 (line 526) 48974* __fractsqsf: Fixed-point fractional library routines. 48975 (line 544) 48976* __fractsqsi: Fixed-point fractional library routines. 48977 (line 541) 48978* __fractsqta: Fixed-point fractional library routines. 48979 (line 528) 48980* __fractsqti: Fixed-point fractional library routines. 48981 (line 543) 48982* __fractsquda: Fixed-point fractional library routines. 48983 (line 536) 48984* __fractsqudq: Fixed-point fractional library routines. 48985 (line 532) 48986* __fractsquha: Fixed-point fractional library routines. 48987 (line 534) 48988* __fractsquhq: Fixed-point fractional library routines. 48989 (line 530) 48990* __fractsquqq: Fixed-point fractional library routines. 48991 (line 529) 48992* __fractsqusa: Fixed-point fractional library routines. 48993 (line 535) 48994* __fractsqusq: Fixed-point fractional library routines. 48995 (line 531) 48996* __fractsquta: Fixed-point fractional library routines. 48997 (line 537) 48998* __fracttada2: Fixed-point fractional library routines. 48999 (line 650) 49000* __fracttadf: Fixed-point fractional library routines. 49001 (line 671) 49002* __fracttadi: Fixed-point fractional library routines. 49003 (line 668) 49004* __fracttadq: Fixed-point fractional library routines. 49005 (line 647) 49006* __fracttaha2: Fixed-point fractional library routines. 49007 (line 648) 49008* __fracttahi: Fixed-point fractional library routines. 49009 (line 666) 49010* __fracttahq: Fixed-point fractional library routines. 49011 (line 645) 49012* __fracttaqi: Fixed-point fractional library routines. 49013 (line 665) 49014* __fracttaqq: Fixed-point fractional library routines. 49015 (line 644) 49016* __fracttasa2: Fixed-point fractional library routines. 49017 (line 649) 49018* __fracttasf: Fixed-point fractional library routines. 49019 (line 670) 49020* __fracttasi: Fixed-point fractional library routines. 49021 (line 667) 49022* __fracttasq: Fixed-point fractional library routines. 49023 (line 646) 49024* __fracttati: Fixed-point fractional library routines. 49025 (line 669) 49026* __fracttauda: Fixed-point fractional library routines. 49027 (line 661) 49028* __fracttaudq: Fixed-point fractional library routines. 49029 (line 656) 49030* __fracttauha: Fixed-point fractional library routines. 49031 (line 658) 49032* __fracttauhq: Fixed-point fractional library routines. 49033 (line 653) 49034* __fracttauqq: Fixed-point fractional library routines. 49035 (line 651) 49036* __fracttausa: Fixed-point fractional library routines. 49037 (line 660) 49038* __fracttausq: Fixed-point fractional library routines. 49039 (line 654) 49040* __fracttauta: Fixed-point fractional library routines. 49041 (line 663) 49042* __fracttida: Fixed-point fractional library routines. 49043 (line 998) 49044* __fracttidq: Fixed-point fractional library routines. 49045 (line 995) 49046* __fracttiha: Fixed-point fractional library routines. 49047 (line 996) 49048* __fracttihq: Fixed-point fractional library routines. 49049 (line 993) 49050* __fracttiqq: Fixed-point fractional library routines. 49051 (line 992) 49052* __fracttisa: Fixed-point fractional library routines. 49053 (line 997) 49054* __fracttisq: Fixed-point fractional library routines. 49055 (line 994) 49056* __fracttita: Fixed-point fractional library routines. 49057 (line 999) 49058* __fracttiuda: Fixed-point fractional library routines. 49059 (line 1007) 49060* __fracttiudq: Fixed-point fractional library routines. 49061 (line 1003) 49062* __fracttiuha: Fixed-point fractional library routines. 49063 (line 1005) 49064* __fracttiuhq: Fixed-point fractional library routines. 49065 (line 1001) 49066* __fracttiuqq: Fixed-point fractional library routines. 49067 (line 1000) 49068* __fracttiusa: Fixed-point fractional library routines. 49069 (line 1006) 49070* __fracttiusq: Fixed-point fractional library routines. 49071 (line 1002) 49072* __fracttiuta: Fixed-point fractional library routines. 49073 (line 1008) 49074* __fractudada: Fixed-point fractional library routines. 49075 (line 865) 49076* __fractudadf: Fixed-point fractional library routines. 49077 (line 888) 49078* __fractudadi: Fixed-point fractional library routines. 49079 (line 885) 49080* __fractudadq: Fixed-point fractional library routines. 49081 (line 861) 49082* __fractudaha: Fixed-point fractional library routines. 49083 (line 863) 49084* __fractudahi: Fixed-point fractional library routines. 49085 (line 883) 49086* __fractudahq: Fixed-point fractional library routines. 49087 (line 859) 49088* __fractudaqi: Fixed-point fractional library routines. 49089 (line 882) 49090* __fractudaqq: Fixed-point fractional library routines. 49091 (line 858) 49092* __fractudasa: Fixed-point fractional library routines. 49093 (line 864) 49094* __fractudasf: Fixed-point fractional library routines. 49095 (line 887) 49096* __fractudasi: Fixed-point fractional library routines. 49097 (line 884) 49098* __fractudasq: Fixed-point fractional library routines. 49099 (line 860) 49100* __fractudata: Fixed-point fractional library routines. 49101 (line 866) 49102* __fractudati: Fixed-point fractional library routines. 49103 (line 886) 49104* __fractudaudq: Fixed-point fractional library routines. 49105 (line 874) 49106* __fractudauha2: Fixed-point fractional library routines. 49107 (line 876) 49108* __fractudauhq: Fixed-point fractional library routines. 49109 (line 870) 49110* __fractudauqq: Fixed-point fractional library routines. 49111 (line 868) 49112* __fractudausa2: Fixed-point fractional library routines. 49113 (line 878) 49114* __fractudausq: Fixed-point fractional library routines. 49115 (line 872) 49116* __fractudauta2: Fixed-point fractional library routines. 49117 (line 880) 49118* __fractudqda: Fixed-point fractional library routines. 49119 (line 772) 49120* __fractudqdf: Fixed-point fractional library routines. 49121 (line 798) 49122* __fractudqdi: Fixed-point fractional library routines. 49123 (line 794) 49124* __fractudqdq: Fixed-point fractional library routines. 49125 (line 767) 49126* __fractudqha: Fixed-point fractional library routines. 49127 (line 769) 49128* __fractudqhi: Fixed-point fractional library routines. 49129 (line 792) 49130* __fractudqhq: Fixed-point fractional library routines. 49131 (line 764) 49132* __fractudqqi: Fixed-point fractional library routines. 49133 (line 790) 49134* __fractudqqq: Fixed-point fractional library routines. 49135 (line 762) 49136* __fractudqsa: Fixed-point fractional library routines. 49137 (line 771) 49138* __fractudqsf: Fixed-point fractional library routines. 49139 (line 797) 49140* __fractudqsi: Fixed-point fractional library routines. 49141 (line 793) 49142* __fractudqsq: Fixed-point fractional library routines. 49143 (line 765) 49144* __fractudqta: Fixed-point fractional library routines. 49145 (line 774) 49146* __fractudqti: Fixed-point fractional library routines. 49147 (line 795) 49148* __fractudquda: Fixed-point fractional library routines. 49149 (line 786) 49150* __fractudquha: Fixed-point fractional library routines. 49151 (line 782) 49152* __fractudquhq2: Fixed-point fractional library routines. 49153 (line 778) 49154* __fractudquqq2: Fixed-point fractional library routines. 49155 (line 776) 49156* __fractudqusa: Fixed-point fractional library routines. 49157 (line 784) 49158* __fractudqusq2: Fixed-point fractional library routines. 49159 (line 780) 49160* __fractudquta: Fixed-point fractional library routines. 49161 (line 788) 49162* __fractuhada: Fixed-point fractional library routines. 49163 (line 806) 49164* __fractuhadf: Fixed-point fractional library routines. 49165 (line 829) 49166* __fractuhadi: Fixed-point fractional library routines. 49167 (line 826) 49168* __fractuhadq: Fixed-point fractional library routines. 49169 (line 802) 49170* __fractuhaha: Fixed-point fractional library routines. 49171 (line 804) 49172* __fractuhahi: Fixed-point fractional library routines. 49173 (line 824) 49174* __fractuhahq: Fixed-point fractional library routines. 49175 (line 800) 49176* __fractuhaqi: Fixed-point fractional library routines. 49177 (line 823) 49178* __fractuhaqq: Fixed-point fractional library routines. 49179 (line 799) 49180* __fractuhasa: Fixed-point fractional library routines. 49181 (line 805) 49182* __fractuhasf: Fixed-point fractional library routines. 49183 (line 828) 49184* __fractuhasi: Fixed-point fractional library routines. 49185 (line 825) 49186* __fractuhasq: Fixed-point fractional library routines. 49187 (line 801) 49188* __fractuhata: Fixed-point fractional library routines. 49189 (line 807) 49190* __fractuhati: Fixed-point fractional library routines. 49191 (line 827) 49192* __fractuhauda2: Fixed-point fractional library routines. 49193 (line 819) 49194* __fractuhaudq: Fixed-point fractional library routines. 49195 (line 815) 49196* __fractuhauhq: Fixed-point fractional library routines. 49197 (line 811) 49198* __fractuhauqq: Fixed-point fractional library routines. 49199 (line 809) 49200* __fractuhausa2: Fixed-point fractional library routines. 49201 (line 817) 49202* __fractuhausq: Fixed-point fractional library routines. 49203 (line 813) 49204* __fractuhauta2: Fixed-point fractional library routines. 49205 (line 821) 49206* __fractuhqda: Fixed-point fractional library routines. 49207 (line 709) 49208* __fractuhqdf: Fixed-point fractional library routines. 49209 (line 730) 49210* __fractuhqdi: Fixed-point fractional library routines. 49211 (line 727) 49212* __fractuhqdq: Fixed-point fractional library routines. 49213 (line 706) 49214* __fractuhqha: Fixed-point fractional library routines. 49215 (line 707) 49216* __fractuhqhi: Fixed-point fractional library routines. 49217 (line 725) 49218* __fractuhqhq: Fixed-point fractional library routines. 49219 (line 704) 49220* __fractuhqqi: Fixed-point fractional library routines. 49221 (line 724) 49222* __fractuhqqq: Fixed-point fractional library routines. 49223 (line 703) 49224* __fractuhqsa: Fixed-point fractional library routines. 49225 (line 708) 49226* __fractuhqsf: Fixed-point fractional library routines. 49227 (line 729) 49228* __fractuhqsi: Fixed-point fractional library routines. 49229 (line 726) 49230* __fractuhqsq: Fixed-point fractional library routines. 49231 (line 705) 49232* __fractuhqta: Fixed-point fractional library routines. 49233 (line 710) 49234* __fractuhqti: Fixed-point fractional library routines. 49235 (line 728) 49236* __fractuhquda: Fixed-point fractional library routines. 49237 (line 720) 49238* __fractuhqudq2: Fixed-point fractional library routines. 49239 (line 715) 49240* __fractuhquha: Fixed-point fractional library routines. 49241 (line 717) 49242* __fractuhquqq2: Fixed-point fractional library routines. 49243 (line 711) 49244* __fractuhqusa: Fixed-point fractional library routines. 49245 (line 719) 49246* __fractuhqusq2: Fixed-point fractional library routines. 49247 (line 713) 49248* __fractuhquta: Fixed-point fractional library routines. 49249 (line 722) 49250* __fractunsdadi: Fixed-point fractional library routines. 49251 (line 1562) 49252* __fractunsdahi: Fixed-point fractional library routines. 49253 (line 1560) 49254* __fractunsdaqi: Fixed-point fractional library routines. 49255 (line 1559) 49256* __fractunsdasi: Fixed-point fractional library routines. 49257 (line 1561) 49258* __fractunsdati: Fixed-point fractional library routines. 49259 (line 1563) 49260* __fractunsdida: Fixed-point fractional library routines. 49261 (line 1714) 49262* __fractunsdidq: Fixed-point fractional library routines. 49263 (line 1711) 49264* __fractunsdiha: Fixed-point fractional library routines. 49265 (line 1712) 49266* __fractunsdihq: Fixed-point fractional library routines. 49267 (line 1709) 49268* __fractunsdiqq: Fixed-point fractional library routines. 49269 (line 1708) 49270* __fractunsdisa: Fixed-point fractional library routines. 49271 (line 1713) 49272* __fractunsdisq: Fixed-point fractional library routines. 49273 (line 1710) 49274* __fractunsdita: Fixed-point fractional library routines. 49275 (line 1715) 49276* __fractunsdiuda: Fixed-point fractional library routines. 49277 (line 1726) 49278* __fractunsdiudq: Fixed-point fractional library routines. 49279 (line 1721) 49280* __fractunsdiuha: Fixed-point fractional library routines. 49281 (line 1723) 49282* __fractunsdiuhq: Fixed-point fractional library routines. 49283 (line 1718) 49284* __fractunsdiuqq: Fixed-point fractional library routines. 49285 (line 1716) 49286* __fractunsdiusa: Fixed-point fractional library routines. 49287 (line 1725) 49288* __fractunsdiusq: Fixed-point fractional library routines. 49289 (line 1719) 49290* __fractunsdiuta: Fixed-point fractional library routines. 49291 (line 1728) 49292* __fractunsdqdi: Fixed-point fractional library routines. 49293 (line 1546) 49294* __fractunsdqhi: Fixed-point fractional library routines. 49295 (line 1544) 49296* __fractunsdqqi: Fixed-point fractional library routines. 49297 (line 1543) 49298* __fractunsdqsi: Fixed-point fractional library routines. 49299 (line 1545) 49300* __fractunsdqti: Fixed-point fractional library routines. 49301 (line 1547) 49302* __fractunshadi: Fixed-point fractional library routines. 49303 (line 1552) 49304* __fractunshahi: Fixed-point fractional library routines. 49305 (line 1550) 49306* __fractunshaqi: Fixed-point fractional library routines. 49307 (line 1549) 49308* __fractunshasi: Fixed-point fractional library routines. 49309 (line 1551) 49310* __fractunshati: Fixed-point fractional library routines. 49311 (line 1553) 49312* __fractunshida: Fixed-point fractional library routines. 49313 (line 1670) 49314* __fractunshidq: Fixed-point fractional library routines. 49315 (line 1667) 49316* __fractunshiha: Fixed-point fractional library routines. 49317 (line 1668) 49318* __fractunshihq: Fixed-point fractional library routines. 49319 (line 1665) 49320* __fractunshiqq: Fixed-point fractional library routines. 49321 (line 1664) 49322* __fractunshisa: Fixed-point fractional library routines. 49323 (line 1669) 49324* __fractunshisq: Fixed-point fractional library routines. 49325 (line 1666) 49326* __fractunshita: Fixed-point fractional library routines. 49327 (line 1671) 49328* __fractunshiuda: Fixed-point fractional library routines. 49329 (line 1682) 49330* __fractunshiudq: Fixed-point fractional library routines. 49331 (line 1677) 49332* __fractunshiuha: Fixed-point fractional library routines. 49333 (line 1679) 49334* __fractunshiuhq: Fixed-point fractional library routines. 49335 (line 1674) 49336* __fractunshiuqq: Fixed-point fractional library routines. 49337 (line 1672) 49338* __fractunshiusa: Fixed-point fractional library routines. 49339 (line 1681) 49340* __fractunshiusq: Fixed-point fractional library routines. 49341 (line 1675) 49342* __fractunshiuta: Fixed-point fractional library routines. 49343 (line 1684) 49344* __fractunshqdi: Fixed-point fractional library routines. 49345 (line 1536) 49346* __fractunshqhi: Fixed-point fractional library routines. 49347 (line 1534) 49348* __fractunshqqi: Fixed-point fractional library routines. 49349 (line 1533) 49350* __fractunshqsi: Fixed-point fractional library routines. 49351 (line 1535) 49352* __fractunshqti: Fixed-point fractional library routines. 49353 (line 1537) 49354* __fractunsqida: Fixed-point fractional library routines. 49355 (line 1648) 49356* __fractunsqidq: Fixed-point fractional library routines. 49357 (line 1645) 49358* __fractunsqiha: Fixed-point fractional library routines. 49359 (line 1646) 49360* __fractunsqihq: Fixed-point fractional library routines. 49361 (line 1643) 49362* __fractunsqiqq: Fixed-point fractional library routines. 49363 (line 1642) 49364* __fractunsqisa: Fixed-point fractional library routines. 49365 (line 1647) 49366* __fractunsqisq: Fixed-point fractional library routines. 49367 (line 1644) 49368* __fractunsqita: Fixed-point fractional library routines. 49369 (line 1649) 49370* __fractunsqiuda: Fixed-point fractional library routines. 49371 (line 1660) 49372* __fractunsqiudq: Fixed-point fractional library routines. 49373 (line 1655) 49374* __fractunsqiuha: Fixed-point fractional library routines. 49375 (line 1657) 49376* __fractunsqiuhq: Fixed-point fractional library routines. 49377 (line 1652) 49378* __fractunsqiuqq: Fixed-point fractional library routines. 49379 (line 1650) 49380* __fractunsqiusa: Fixed-point fractional library routines. 49381 (line 1659) 49382* __fractunsqiusq: Fixed-point fractional library routines. 49383 (line 1653) 49384* __fractunsqiuta: Fixed-point fractional library routines. 49385 (line 1662) 49386* __fractunsqqdi: Fixed-point fractional library routines. 49387 (line 1531) 49388* __fractunsqqhi: Fixed-point fractional library routines. 49389 (line 1529) 49390* __fractunsqqqi: Fixed-point fractional library routines. 49391 (line 1528) 49392* __fractunsqqsi: Fixed-point fractional library routines. 49393 (line 1530) 49394* __fractunsqqti: Fixed-point fractional library routines. 49395 (line 1532) 49396* __fractunssadi: Fixed-point fractional library routines. 49397 (line 1557) 49398* __fractunssahi: Fixed-point fractional library routines. 49399 (line 1555) 49400* __fractunssaqi: Fixed-point fractional library routines. 49401 (line 1554) 49402* __fractunssasi: Fixed-point fractional library routines. 49403 (line 1556) 49404* __fractunssati: Fixed-point fractional library routines. 49405 (line 1558) 49406* __fractunssida: Fixed-point fractional library routines. 49407 (line 1692) 49408* __fractunssidq: Fixed-point fractional library routines. 49409 (line 1689) 49410* __fractunssiha: Fixed-point fractional library routines. 49411 (line 1690) 49412* __fractunssihq: Fixed-point fractional library routines. 49413 (line 1687) 49414* __fractunssiqq: Fixed-point fractional library routines. 49415 (line 1686) 49416* __fractunssisa: Fixed-point fractional library routines. 49417 (line 1691) 49418* __fractunssisq: Fixed-point fractional library routines. 49419 (line 1688) 49420* __fractunssita: Fixed-point fractional library routines. 49421 (line 1693) 49422* __fractunssiuda: Fixed-point fractional library routines. 49423 (line 1704) 49424* __fractunssiudq: Fixed-point fractional library routines. 49425 (line 1699) 49426* __fractunssiuha: Fixed-point fractional library routines. 49427 (line 1701) 49428* __fractunssiuhq: Fixed-point fractional library routines. 49429 (line 1696) 49430* __fractunssiuqq: Fixed-point fractional library routines. 49431 (line 1694) 49432* __fractunssiusa: Fixed-point fractional library routines. 49433 (line 1703) 49434* __fractunssiusq: Fixed-point fractional library routines. 49435 (line 1697) 49436* __fractunssiuta: Fixed-point fractional library routines. 49437 (line 1706) 49438* __fractunssqdi: Fixed-point fractional library routines. 49439 (line 1541) 49440* __fractunssqhi: Fixed-point fractional library routines. 49441 (line 1539) 49442* __fractunssqqi: Fixed-point fractional library routines. 49443 (line 1538) 49444* __fractunssqsi: Fixed-point fractional library routines. 49445 (line 1540) 49446* __fractunssqti: Fixed-point fractional library routines. 49447 (line 1542) 49448* __fractunstadi: Fixed-point fractional library routines. 49449 (line 1567) 49450* __fractunstahi: Fixed-point fractional library routines. 49451 (line 1565) 49452* __fractunstaqi: Fixed-point fractional library routines. 49453 (line 1564) 49454* __fractunstasi: Fixed-point fractional library routines. 49455 (line 1566) 49456* __fractunstati: Fixed-point fractional library routines. 49457 (line 1568) 49458* __fractunstida: Fixed-point fractional library routines. 49459 (line 1737) 49460* __fractunstidq: Fixed-point fractional library routines. 49461 (line 1733) 49462* __fractunstiha: Fixed-point fractional library routines. 49463 (line 1735) 49464* __fractunstihq: Fixed-point fractional library routines. 49465 (line 1731) 49466* __fractunstiqq: Fixed-point fractional library routines. 49467 (line 1730) 49468* __fractunstisa: Fixed-point fractional library routines. 49469 (line 1736) 49470* __fractunstisq: Fixed-point fractional library routines. 49471 (line 1732) 49472* __fractunstita: Fixed-point fractional library routines. 49473 (line 1738) 49474* __fractunstiuda: Fixed-point fractional library routines. 49475 (line 1752) 49476* __fractunstiudq: Fixed-point fractional library routines. 49477 (line 1746) 49478* __fractunstiuha: Fixed-point fractional library routines. 49479 (line 1748) 49480* __fractunstiuhq: Fixed-point fractional library routines. 49481 (line 1742) 49482* __fractunstiuqq: Fixed-point fractional library routines. 49483 (line 1740) 49484* __fractunstiusa: Fixed-point fractional library routines. 49485 (line 1750) 49486* __fractunstiusq: Fixed-point fractional library routines. 49487 (line 1744) 49488* __fractunstiuta: Fixed-point fractional library routines. 49489 (line 1754) 49490* __fractunsudadi: Fixed-point fractional library routines. 49491 (line 1628) 49492* __fractunsudahi: Fixed-point fractional library routines. 49493 (line 1624) 49494* __fractunsudaqi: Fixed-point fractional library routines. 49495 (line 1622) 49496* __fractunsudasi: Fixed-point fractional library routines. 49497 (line 1626) 49498* __fractunsudati: Fixed-point fractional library routines. 49499 (line 1630) 49500* __fractunsudqdi: Fixed-point fractional library routines. 49501 (line 1602) 49502* __fractunsudqhi: Fixed-point fractional library routines. 49503 (line 1598) 49504* __fractunsudqqi: Fixed-point fractional library routines. 49505 (line 1596) 49506* __fractunsudqsi: Fixed-point fractional library routines. 49507 (line 1600) 49508* __fractunsudqti: Fixed-point fractional library routines. 49509 (line 1604) 49510* __fractunsuhadi: Fixed-point fractional library routines. 49511 (line 1612) 49512* __fractunsuhahi: Fixed-point fractional library routines. 49513 (line 1608) 49514* __fractunsuhaqi: Fixed-point fractional library routines. 49515 (line 1606) 49516* __fractunsuhasi: Fixed-point fractional library routines. 49517 (line 1610) 49518* __fractunsuhati: Fixed-point fractional library routines. 49519 (line 1614) 49520* __fractunsuhqdi: Fixed-point fractional library routines. 49521 (line 1583) 49522* __fractunsuhqhi: Fixed-point fractional library routines. 49523 (line 1581) 49524* __fractunsuhqqi: Fixed-point fractional library routines. 49525 (line 1580) 49526* __fractunsuhqsi: Fixed-point fractional library routines. 49527 (line 1582) 49528* __fractunsuhqti: Fixed-point fractional library routines. 49529 (line 1584) 49530* __fractunsuqqdi: Fixed-point fractional library routines. 49531 (line 1576) 49532* __fractunsuqqhi: Fixed-point fractional library routines. 49533 (line 1572) 49534* __fractunsuqqqi: Fixed-point fractional library routines. 49535 (line 1570) 49536* __fractunsuqqsi: Fixed-point fractional library routines. 49537 (line 1574) 49538* __fractunsuqqti: Fixed-point fractional library routines. 49539 (line 1578) 49540* __fractunsusadi: Fixed-point fractional library routines. 49541 (line 1619) 49542* __fractunsusahi: Fixed-point fractional library routines. 49543 (line 1617) 49544* __fractunsusaqi: Fixed-point fractional library routines. 49545 (line 1616) 49546* __fractunsusasi: Fixed-point fractional library routines. 49547 (line 1618) 49548* __fractunsusati: Fixed-point fractional library routines. 49549 (line 1620) 49550* __fractunsusqdi: Fixed-point fractional library routines. 49551 (line 1592) 49552* __fractunsusqhi: Fixed-point fractional library routines. 49553 (line 1588) 49554* __fractunsusqqi: Fixed-point fractional library routines. 49555 (line 1586) 49556* __fractunsusqsi: Fixed-point fractional library routines. 49557 (line 1590) 49558* __fractunsusqti: Fixed-point fractional library routines. 49559 (line 1594) 49560* __fractunsutadi: Fixed-point fractional library routines. 49561 (line 1638) 49562* __fractunsutahi: Fixed-point fractional library routines. 49563 (line 1634) 49564* __fractunsutaqi: Fixed-point fractional library routines. 49565 (line 1632) 49566* __fractunsutasi: Fixed-point fractional library routines. 49567 (line 1636) 49568* __fractunsutati: Fixed-point fractional library routines. 49569 (line 1640) 49570* __fractuqqda: Fixed-point fractional library routines. 49571 (line 679) 49572* __fractuqqdf: Fixed-point fractional library routines. 49573 (line 702) 49574* __fractuqqdi: Fixed-point fractional library routines. 49575 (line 699) 49576* __fractuqqdq: Fixed-point fractional library routines. 49577 (line 675) 49578* __fractuqqha: Fixed-point fractional library routines. 49579 (line 677) 49580* __fractuqqhi: Fixed-point fractional library routines. 49581 (line 697) 49582* __fractuqqhq: Fixed-point fractional library routines. 49583 (line 673) 49584* __fractuqqqi: Fixed-point fractional library routines. 49585 (line 696) 49586* __fractuqqqq: Fixed-point fractional library routines. 49587 (line 672) 49588* __fractuqqsa: Fixed-point fractional library routines. 49589 (line 678) 49590* __fractuqqsf: Fixed-point fractional library routines. 49591 (line 701) 49592* __fractuqqsi: Fixed-point fractional library routines. 49593 (line 698) 49594* __fractuqqsq: Fixed-point fractional library routines. 49595 (line 674) 49596* __fractuqqta: Fixed-point fractional library routines. 49597 (line 680) 49598* __fractuqqti: Fixed-point fractional library routines. 49599 (line 700) 49600* __fractuqquda: Fixed-point fractional library routines. 49601 (line 692) 49602* __fractuqqudq2: Fixed-point fractional library routines. 49603 (line 686) 49604* __fractuqquha: Fixed-point fractional library routines. 49605 (line 688) 49606* __fractuqquhq2: Fixed-point fractional library routines. 49607 (line 682) 49608* __fractuqqusa: Fixed-point fractional library routines. 49609 (line 690) 49610* __fractuqqusq2: Fixed-point fractional library routines. 49611 (line 684) 49612* __fractuqquta: Fixed-point fractional library routines. 49613 (line 694) 49614* __fractusada: Fixed-point fractional library routines. 49615 (line 836) 49616* __fractusadf: Fixed-point fractional library routines. 49617 (line 857) 49618* __fractusadi: Fixed-point fractional library routines. 49619 (line 854) 49620* __fractusadq: Fixed-point fractional library routines. 49621 (line 833) 49622* __fractusaha: Fixed-point fractional library routines. 49623 (line 834) 49624* __fractusahi: Fixed-point fractional library routines. 49625 (line 852) 49626* __fractusahq: Fixed-point fractional library routines. 49627 (line 831) 49628* __fractusaqi: Fixed-point fractional library routines. 49629 (line 851) 49630* __fractusaqq: Fixed-point fractional library routines. 49631 (line 830) 49632* __fractusasa: Fixed-point fractional library routines. 49633 (line 835) 49634* __fractusasf: Fixed-point fractional library routines. 49635 (line 856) 49636* __fractusasi: Fixed-point fractional library routines. 49637 (line 853) 49638* __fractusasq: Fixed-point fractional library routines. 49639 (line 832) 49640* __fractusata: Fixed-point fractional library routines. 49641 (line 837) 49642* __fractusati: Fixed-point fractional library routines. 49643 (line 855) 49644* __fractusauda2: Fixed-point fractional library routines. 49645 (line 847) 49646* __fractusaudq: Fixed-point fractional library routines. 49647 (line 843) 49648* __fractusauha2: Fixed-point fractional library routines. 49649 (line 845) 49650* __fractusauhq: Fixed-point fractional library routines. 49651 (line 840) 49652* __fractusauqq: Fixed-point fractional library routines. 49653 (line 838) 49654* __fractusausq: Fixed-point fractional library routines. 49655 (line 841) 49656* __fractusauta2: Fixed-point fractional library routines. 49657 (line 849) 49658* __fractusqda: Fixed-point fractional library routines. 49659 (line 738) 49660* __fractusqdf: Fixed-point fractional library routines. 49661 (line 761) 49662* __fractusqdi: Fixed-point fractional library routines. 49663 (line 758) 49664* __fractusqdq: Fixed-point fractional library routines. 49665 (line 734) 49666* __fractusqha: Fixed-point fractional library routines. 49667 (line 736) 49668* __fractusqhi: Fixed-point fractional library routines. 49669 (line 756) 49670* __fractusqhq: Fixed-point fractional library routines. 49671 (line 732) 49672* __fractusqqi: Fixed-point fractional library routines. 49673 (line 755) 49674* __fractusqqq: Fixed-point fractional library routines. 49675 (line 731) 49676* __fractusqsa: Fixed-point fractional library routines. 49677 (line 737) 49678* __fractusqsf: Fixed-point fractional library routines. 49679 (line 760) 49680* __fractusqsi: Fixed-point fractional library routines. 49681 (line 757) 49682* __fractusqsq: Fixed-point fractional library routines. 49683 (line 733) 49684* __fractusqta: Fixed-point fractional library routines. 49685 (line 739) 49686* __fractusqti: Fixed-point fractional library routines. 49687 (line 759) 49688* __fractusquda: Fixed-point fractional library routines. 49689 (line 751) 49690* __fractusqudq2: Fixed-point fractional library routines. 49691 (line 745) 49692* __fractusquha: Fixed-point fractional library routines. 49693 (line 747) 49694* __fractusquhq2: Fixed-point fractional library routines. 49695 (line 743) 49696* __fractusquqq2: Fixed-point fractional library routines. 49697 (line 741) 49698* __fractusqusa: Fixed-point fractional library routines. 49699 (line 749) 49700* __fractusquta: Fixed-point fractional library routines. 49701 (line 753) 49702* __fractutada: Fixed-point fractional library routines. 49703 (line 899) 49704* __fractutadf: Fixed-point fractional library routines. 49705 (line 925) 49706* __fractutadi: Fixed-point fractional library routines. 49707 (line 921) 49708* __fractutadq: Fixed-point fractional library routines. 49709 (line 894) 49710* __fractutaha: Fixed-point fractional library routines. 49711 (line 896) 49712* __fractutahi: Fixed-point fractional library routines. 49713 (line 919) 49714* __fractutahq: Fixed-point fractional library routines. 49715 (line 891) 49716* __fractutaqi: Fixed-point fractional library routines. 49717 (line 917) 49718* __fractutaqq: Fixed-point fractional library routines. 49719 (line 889) 49720* __fractutasa: Fixed-point fractional library routines. 49721 (line 898) 49722* __fractutasf: Fixed-point fractional library routines. 49723 (line 924) 49724* __fractutasi: Fixed-point fractional library routines. 49725 (line 920) 49726* __fractutasq: Fixed-point fractional library routines. 49727 (line 892) 49728* __fractutata: Fixed-point fractional library routines. 49729 (line 901) 49730* __fractutati: Fixed-point fractional library routines. 49731 (line 922) 49732* __fractutauda2: Fixed-point fractional library routines. 49733 (line 915) 49734* __fractutaudq: Fixed-point fractional library routines. 49735 (line 909) 49736* __fractutauha2: Fixed-point fractional library routines. 49737 (line 911) 49738* __fractutauhq: Fixed-point fractional library routines. 49739 (line 905) 49740* __fractutauqq: Fixed-point fractional library routines. 49741 (line 903) 49742* __fractutausa2: Fixed-point fractional library routines. 49743 (line 913) 49744* __fractutausq: Fixed-point fractional library routines. 49745 (line 907) 49746* __gedf2: Soft float library routines. 49747 (line 205) 49748* __gesf2: Soft float library routines. 49749 (line 204) 49750* __getf2: Soft float library routines. 49751 (line 206) 49752* __gtdf2: Soft float library routines. 49753 (line 223) 49754* __gtsf2: Soft float library routines. 49755 (line 222) 49756* __gttf2: Soft float library routines. 49757 (line 224) 49758* __ledf2: Soft float library routines. 49759 (line 217) 49760* __lesf2: Soft float library routines. 49761 (line 216) 49762* __letf2: Soft float library routines. 49763 (line 218) 49764* __lshrdi3: Integer library routines. 49765 (line 30) 49766* __lshrsi3: Integer library routines. 49767 (line 29) 49768* __lshrti3: Integer library routines. 49769 (line 31) 49770* __lshruda3: Fixed-point fractional library routines. 49771 (line 396) 49772* __lshrudq3: Fixed-point fractional library routines. 49773 (line 390) 49774* __lshruha3: Fixed-point fractional library routines. 49775 (line 392) 49776* __lshruhq3: Fixed-point fractional library routines. 49777 (line 386) 49778* __lshruqq3: Fixed-point fractional library routines. 49779 (line 384) 49780* __lshrusa3: Fixed-point fractional library routines. 49781 (line 394) 49782* __lshrusq3: Fixed-point fractional library routines. 49783 (line 388) 49784* __lshruta3: Fixed-point fractional library routines. 49785 (line 398) 49786* __ltdf2: Soft float library routines. 49787 (line 211) 49788* __ltsf2: Soft float library routines. 49789 (line 210) 49790* __lttf2: Soft float library routines. 49791 (line 212) 49792* __main: Collect2. (line 15) 49793* __moddi3: Integer library routines. 49794 (line 36) 49795* __modsi3: Integer library routines. 49796 (line 35) 49797* __modti3: Integer library routines. 49798 (line 37) 49799* __morestack_current_segment: Miscellaneous routines. 49800 (line 45) 49801* __morestack_initial_sp: Miscellaneous routines. 49802 (line 46) 49803* __morestack_segments: Miscellaneous routines. 49804 (line 44) 49805* __mulda3: Fixed-point fractional library routines. 49806 (line 178) 49807* __muldc3: Soft float library routines. 49808 (line 239) 49809* __muldf3: Soft float library routines. 49810 (line 39) 49811* __muldi3: Integer library routines. 49812 (line 42) 49813* __muldq3: Fixed-point fractional library routines. 49814 (line 165) 49815* __mulha3: Fixed-point fractional library routines. 49816 (line 175) 49817* __mulhq3: Fixed-point fractional library routines. 49818 (line 163) 49819* __mulqq3: Fixed-point fractional library routines. 49820 (line 161) 49821* __mulsa3: Fixed-point fractional library routines. 49822 (line 177) 49823* __mulsc3: Soft float library routines. 49824 (line 237) 49825* __mulsf3: Soft float library routines. 49826 (line 38) 49827* __mulsi3: Integer library routines. 49828 (line 41) 49829* __mulsq3: Fixed-point fractional library routines. 49830 (line 164) 49831* __multa3: Fixed-point fractional library routines. 49832 (line 179) 49833* __multc3: Soft float library routines. 49834 (line 241) 49835* __multf3: Soft float library routines. 49836 (line 40) 49837* __multi3: Integer library routines. 49838 (line 43) 49839* __muluda3: Fixed-point fractional library routines. 49840 (line 185) 49841* __muludq3: Fixed-point fractional library routines. 49842 (line 173) 49843* __muluha3: Fixed-point fractional library routines. 49844 (line 181) 49845* __muluhq3: Fixed-point fractional library routines. 49846 (line 169) 49847* __muluqq3: Fixed-point fractional library routines. 49848 (line 167) 49849* __mulusa3: Fixed-point fractional library routines. 49850 (line 183) 49851* __mulusq3: Fixed-point fractional library routines. 49852 (line 171) 49853* __muluta3: Fixed-point fractional library routines. 49854 (line 187) 49855* __mulvdi3: Integer library routines. 49856 (line 114) 49857* __mulvsi3: Integer library routines. 49858 (line 113) 49859* __mulxc3: Soft float library routines. 49860 (line 243) 49861* __mulxf3: Soft float library routines. 49862 (line 42) 49863* __nedf2: Soft float library routines. 49864 (line 199) 49865* __negda2: Fixed-point fractional library routines. 49866 (line 306) 49867* __negdf2: Soft float library routines. 49868 (line 55) 49869* __negdi2: Integer library routines. 49870 (line 46) 49871* __negdq2: Fixed-point fractional library routines. 49872 (line 296) 49873* __negha2: Fixed-point fractional library routines. 49874 (line 304) 49875* __neghq2: Fixed-point fractional library routines. 49876 (line 294) 49877* __negqq2: Fixed-point fractional library routines. 49878 (line 293) 49879* __negsa2: Fixed-point fractional library routines. 49880 (line 305) 49881* __negsf2: Soft float library routines. 49882 (line 54) 49883* __negsq2: Fixed-point fractional library routines. 49884 (line 295) 49885* __negta2: Fixed-point fractional library routines. 49886 (line 307) 49887* __negtf2: Soft float library routines. 49888 (line 56) 49889* __negti2: Integer library routines. 49890 (line 47) 49891* __neguda2: Fixed-point fractional library routines. 49892 (line 311) 49893* __negudq2: Fixed-point fractional library routines. 49894 (line 302) 49895* __neguha2: Fixed-point fractional library routines. 49896 (line 308) 49897* __neguhq2: Fixed-point fractional library routines. 49898 (line 299) 49899* __neguqq2: Fixed-point fractional library routines. 49900 (line 297) 49901* __negusa2: Fixed-point fractional library routines. 49902 (line 310) 49903* __negusq2: Fixed-point fractional library routines. 49904 (line 300) 49905* __neguta2: Fixed-point fractional library routines. 49906 (line 313) 49907* __negvdi2: Integer library routines. 49908 (line 118) 49909* __negvsi2: Integer library routines. 49910 (line 117) 49911* __negxf2: Soft float library routines. 49912 (line 57) 49913* __nesf2: Soft float library routines. 49914 (line 198) 49915* __netf2: Soft float library routines. 49916 (line 200) 49917* __paritydi2: Integer library routines. 49918 (line 150) 49919* __paritysi2: Integer library routines. 49920 (line 149) 49921* __parityti2: Integer library routines. 49922 (line 151) 49923* __popcountdi2: Integer library routines. 49924 (line 156) 49925* __popcountsi2: Integer library routines. 49926 (line 155) 49927* __popcountti2: Integer library routines. 49928 (line 157) 49929* __powidf2: Soft float library routines. 49930 (line 232) 49931* __powisf2: Soft float library routines. 49932 (line 231) 49933* __powitf2: Soft float library routines. 49934 (line 233) 49935* __powixf2: Soft float library routines. 49936 (line 234) 49937* __satfractdadq: Fixed-point fractional library routines. 49938 (line 1160) 49939* __satfractdaha2: Fixed-point fractional library routines. 49940 (line 1161) 49941* __satfractdahq: Fixed-point fractional library routines. 49942 (line 1158) 49943* __satfractdaqq: Fixed-point fractional library routines. 49944 (line 1157) 49945* __satfractdasa2: Fixed-point fractional library routines. 49946 (line 1162) 49947* __satfractdasq: Fixed-point fractional library routines. 49948 (line 1159) 49949* __satfractdata2: Fixed-point fractional library routines. 49950 (line 1163) 49951* __satfractdauda: Fixed-point fractional library routines. 49952 (line 1173) 49953* __satfractdaudq: Fixed-point fractional library routines. 49954 (line 1168) 49955* __satfractdauha: Fixed-point fractional library routines. 49956 (line 1170) 49957* __satfractdauhq: Fixed-point fractional library routines. 49958 (line 1166) 49959* __satfractdauqq: Fixed-point fractional library routines. 49960 (line 1164) 49961* __satfractdausa: Fixed-point fractional library routines. 49962 (line 1172) 49963* __satfractdausq: Fixed-point fractional library routines. 49964 (line 1167) 49965* __satfractdauta: Fixed-point fractional library routines. 49966 (line 1174) 49967* __satfractdfda: Fixed-point fractional library routines. 49968 (line 1513) 49969* __satfractdfdq: Fixed-point fractional library routines. 49970 (line 1510) 49971* __satfractdfha: Fixed-point fractional library routines. 49972 (line 1511) 49973* __satfractdfhq: Fixed-point fractional library routines. 49974 (line 1508) 49975* __satfractdfqq: Fixed-point fractional library routines. 49976 (line 1507) 49977* __satfractdfsa: Fixed-point fractional library routines. 49978 (line 1512) 49979* __satfractdfsq: Fixed-point fractional library routines. 49980 (line 1509) 49981* __satfractdfta: Fixed-point fractional library routines. 49982 (line 1514) 49983* __satfractdfuda: Fixed-point fractional library routines. 49984 (line 1522) 49985* __satfractdfudq: Fixed-point fractional library routines. 49986 (line 1518) 49987* __satfractdfuha: Fixed-point fractional library routines. 49988 (line 1520) 49989* __satfractdfuhq: Fixed-point fractional library routines. 49990 (line 1516) 49991* __satfractdfuqq: Fixed-point fractional library routines. 49992 (line 1515) 49993* __satfractdfusa: Fixed-point fractional library routines. 49994 (line 1521) 49995* __satfractdfusq: Fixed-point fractional library routines. 49996 (line 1517) 49997* __satfractdfuta: Fixed-point fractional library routines. 49998 (line 1523) 49999* __satfractdida: Fixed-point fractional library routines. 50000 (line 1463) 50001* __satfractdidq: Fixed-point fractional library routines. 50002 (line 1460) 50003* __satfractdiha: Fixed-point fractional library routines. 50004 (line 1461) 50005* __satfractdihq: Fixed-point fractional library routines. 50006 (line 1458) 50007* __satfractdiqq: Fixed-point fractional library routines. 50008 (line 1457) 50009* __satfractdisa: Fixed-point fractional library routines. 50010 (line 1462) 50011* __satfractdisq: Fixed-point fractional library routines. 50012 (line 1459) 50013* __satfractdita: Fixed-point fractional library routines. 50014 (line 1464) 50015* __satfractdiuda: Fixed-point fractional library routines. 50016 (line 1471) 50017* __satfractdiudq: Fixed-point fractional library routines. 50018 (line 1468) 50019* __satfractdiuha: Fixed-point fractional library routines. 50020 (line 1469) 50021* __satfractdiuhq: Fixed-point fractional library routines. 50022 (line 1466) 50023* __satfractdiuqq: Fixed-point fractional library routines. 50024 (line 1465) 50025* __satfractdiusa: Fixed-point fractional library routines. 50026 (line 1470) 50027* __satfractdiusq: Fixed-point fractional library routines. 50028 (line 1467) 50029* __satfractdiuta: Fixed-point fractional library routines. 50030 (line 1472) 50031* __satfractdqda: Fixed-point fractional library routines. 50032 (line 1105) 50033* __satfractdqha: Fixed-point fractional library routines. 50034 (line 1103) 50035* __satfractdqhq2: Fixed-point fractional library routines. 50036 (line 1101) 50037* __satfractdqqq2: Fixed-point fractional library routines. 50038 (line 1100) 50039* __satfractdqsa: Fixed-point fractional library routines. 50040 (line 1104) 50041* __satfractdqsq2: Fixed-point fractional library routines. 50042 (line 1102) 50043* __satfractdqta: Fixed-point fractional library routines. 50044 (line 1106) 50045* __satfractdquda: Fixed-point fractional library routines. 50046 (line 1117) 50047* __satfractdqudq: Fixed-point fractional library routines. 50048 (line 1112) 50049* __satfractdquha: Fixed-point fractional library routines. 50050 (line 1114) 50051* __satfractdquhq: Fixed-point fractional library routines. 50052 (line 1109) 50053* __satfractdquqq: Fixed-point fractional library routines. 50054 (line 1107) 50055* __satfractdqusa: Fixed-point fractional library routines. 50056 (line 1116) 50057* __satfractdqusq: Fixed-point fractional library routines. 50058 (line 1110) 50059* __satfractdquta: Fixed-point fractional library routines. 50060 (line 1119) 50061* __satfracthada2: Fixed-point fractional library routines. 50062 (line 1126) 50063* __satfracthadq: Fixed-point fractional library routines. 50064 (line 1124) 50065* __satfracthahq: Fixed-point fractional library routines. 50066 (line 1122) 50067* __satfracthaqq: Fixed-point fractional library routines. 50068 (line 1121) 50069* __satfracthasa2: Fixed-point fractional library routines. 50070 (line 1125) 50071* __satfracthasq: Fixed-point fractional library routines. 50072 (line 1123) 50073* __satfracthata2: Fixed-point fractional library routines. 50074 (line 1127) 50075* __satfracthauda: Fixed-point fractional library routines. 50076 (line 1138) 50077* __satfracthaudq: Fixed-point fractional library routines. 50078 (line 1133) 50079* __satfracthauha: Fixed-point fractional library routines. 50080 (line 1135) 50081* __satfracthauhq: Fixed-point fractional library routines. 50082 (line 1130) 50083* __satfracthauqq: Fixed-point fractional library routines. 50084 (line 1128) 50085* __satfracthausa: Fixed-point fractional library routines. 50086 (line 1137) 50087* __satfracthausq: Fixed-point fractional library routines. 50088 (line 1131) 50089* __satfracthauta: Fixed-point fractional library routines. 50090 (line 1140) 50091* __satfracthida: Fixed-point fractional library routines. 50092 (line 1431) 50093* __satfracthidq: Fixed-point fractional library routines. 50094 (line 1428) 50095* __satfracthiha: Fixed-point fractional library routines. 50096 (line 1429) 50097* __satfracthihq: Fixed-point fractional library routines. 50098 (line 1426) 50099* __satfracthiqq: Fixed-point fractional library routines. 50100 (line 1425) 50101* __satfracthisa: Fixed-point fractional library routines. 50102 (line 1430) 50103* __satfracthisq: Fixed-point fractional library routines. 50104 (line 1427) 50105* __satfracthita: Fixed-point fractional library routines. 50106 (line 1432) 50107* __satfracthiuda: Fixed-point fractional library routines. 50108 (line 1439) 50109* __satfracthiudq: Fixed-point fractional library routines. 50110 (line 1436) 50111* __satfracthiuha: Fixed-point fractional library routines. 50112 (line 1437) 50113* __satfracthiuhq: Fixed-point fractional library routines. 50114 (line 1434) 50115* __satfracthiuqq: Fixed-point fractional library routines. 50116 (line 1433) 50117* __satfracthiusa: Fixed-point fractional library routines. 50118 (line 1438) 50119* __satfracthiusq: Fixed-point fractional library routines. 50120 (line 1435) 50121* __satfracthiuta: Fixed-point fractional library routines. 50122 (line 1440) 50123* __satfracthqda: Fixed-point fractional library routines. 50124 (line 1071) 50125* __satfracthqdq2: Fixed-point fractional library routines. 50126 (line 1068) 50127* __satfracthqha: Fixed-point fractional library routines. 50128 (line 1069) 50129* __satfracthqqq2: Fixed-point fractional library routines. 50130 (line 1066) 50131* __satfracthqsa: Fixed-point fractional library routines. 50132 (line 1070) 50133* __satfracthqsq2: Fixed-point fractional library routines. 50134 (line 1067) 50135* __satfracthqta: Fixed-point fractional library routines. 50136 (line 1072) 50137* __satfracthquda: Fixed-point fractional library routines. 50138 (line 1079) 50139* __satfracthqudq: Fixed-point fractional library routines. 50140 (line 1076) 50141* __satfracthquha: Fixed-point fractional library routines. 50142 (line 1077) 50143* __satfracthquhq: Fixed-point fractional library routines. 50144 (line 1074) 50145* __satfracthquqq: Fixed-point fractional library routines. 50146 (line 1073) 50147* __satfracthqusa: Fixed-point fractional library routines. 50148 (line 1078) 50149* __satfracthqusq: Fixed-point fractional library routines. 50150 (line 1075) 50151* __satfracthquta: Fixed-point fractional library routines. 50152 (line 1080) 50153* __satfractqida: Fixed-point fractional library routines. 50154 (line 1409) 50155* __satfractqidq: Fixed-point fractional library routines. 50156 (line 1406) 50157* __satfractqiha: Fixed-point fractional library routines. 50158 (line 1407) 50159* __satfractqihq: Fixed-point fractional library routines. 50160 (line 1404) 50161* __satfractqiqq: Fixed-point fractional library routines. 50162 (line 1403) 50163* __satfractqisa: Fixed-point fractional library routines. 50164 (line 1408) 50165* __satfractqisq: Fixed-point fractional library routines. 50166 (line 1405) 50167* __satfractqita: Fixed-point fractional library routines. 50168 (line 1410) 50169* __satfractqiuda: Fixed-point fractional library routines. 50170 (line 1421) 50171* __satfractqiudq: Fixed-point fractional library routines. 50172 (line 1416) 50173* __satfractqiuha: Fixed-point fractional library routines. 50174 (line 1418) 50175* __satfractqiuhq: Fixed-point fractional library routines. 50176 (line 1413) 50177* __satfractqiuqq: Fixed-point fractional library routines. 50178 (line 1411) 50179* __satfractqiusa: Fixed-point fractional library routines. 50180 (line 1420) 50181* __satfractqiusq: Fixed-point fractional library routines. 50182 (line 1414) 50183* __satfractqiuta: Fixed-point fractional library routines. 50184 (line 1423) 50185* __satfractqqda: Fixed-point fractional library routines. 50186 (line 1050) 50187* __satfractqqdq2: Fixed-point fractional library routines. 50188 (line 1047) 50189* __satfractqqha: Fixed-point fractional library routines. 50190 (line 1048) 50191* __satfractqqhq2: Fixed-point fractional library routines. 50192 (line 1045) 50193* __satfractqqsa: Fixed-point fractional library routines. 50194 (line 1049) 50195* __satfractqqsq2: Fixed-point fractional library routines. 50196 (line 1046) 50197* __satfractqqta: Fixed-point fractional library routines. 50198 (line 1051) 50199* __satfractqquda: Fixed-point fractional library routines. 50200 (line 1062) 50201* __satfractqqudq: Fixed-point fractional library routines. 50202 (line 1057) 50203* __satfractqquha: Fixed-point fractional library routines. 50204 (line 1059) 50205* __satfractqquhq: Fixed-point fractional library routines. 50206 (line 1054) 50207* __satfractqquqq: Fixed-point fractional library routines. 50208 (line 1052) 50209* __satfractqqusa: Fixed-point fractional library routines. 50210 (line 1061) 50211* __satfractqqusq: Fixed-point fractional library routines. 50212 (line 1055) 50213* __satfractqquta: Fixed-point fractional library routines. 50214 (line 1064) 50215* __satfractsada2: Fixed-point fractional library routines. 50216 (line 1147) 50217* __satfractsadq: Fixed-point fractional library routines. 50218 (line 1145) 50219* __satfractsaha2: Fixed-point fractional library routines. 50220 (line 1146) 50221* __satfractsahq: Fixed-point fractional library routines. 50222 (line 1143) 50223* __satfractsaqq: Fixed-point fractional library routines. 50224 (line 1142) 50225* __satfractsasq: Fixed-point fractional library routines. 50226 (line 1144) 50227* __satfractsata2: Fixed-point fractional library routines. 50228 (line 1148) 50229* __satfractsauda: Fixed-point fractional library routines. 50230 (line 1155) 50231* __satfractsaudq: Fixed-point fractional library routines. 50232 (line 1152) 50233* __satfractsauha: Fixed-point fractional library routines. 50234 (line 1153) 50235* __satfractsauhq: Fixed-point fractional library routines. 50236 (line 1150) 50237* __satfractsauqq: Fixed-point fractional library routines. 50238 (line 1149) 50239* __satfractsausa: Fixed-point fractional library routines. 50240 (line 1154) 50241* __satfractsausq: Fixed-point fractional library routines. 50242 (line 1151) 50243* __satfractsauta: Fixed-point fractional library routines. 50244 (line 1156) 50245* __satfractsfda: Fixed-point fractional library routines. 50246 (line 1497) 50247* __satfractsfdq: Fixed-point fractional library routines. 50248 (line 1494) 50249* __satfractsfha: Fixed-point fractional library routines. 50250 (line 1495) 50251* __satfractsfhq: Fixed-point fractional library routines. 50252 (line 1492) 50253* __satfractsfqq: Fixed-point fractional library routines. 50254 (line 1491) 50255* __satfractsfsa: Fixed-point fractional library routines. 50256 (line 1496) 50257* __satfractsfsq: Fixed-point fractional library routines. 50258 (line 1493) 50259* __satfractsfta: Fixed-point fractional library routines. 50260 (line 1498) 50261* __satfractsfuda: Fixed-point fractional library routines. 50262 (line 1505) 50263* __satfractsfudq: Fixed-point fractional library routines. 50264 (line 1502) 50265* __satfractsfuha: Fixed-point fractional library routines. 50266 (line 1503) 50267* __satfractsfuhq: Fixed-point fractional library routines. 50268 (line 1500) 50269* __satfractsfuqq: Fixed-point fractional library routines. 50270 (line 1499) 50271* __satfractsfusa: Fixed-point fractional library routines. 50272 (line 1504) 50273* __satfractsfusq: Fixed-point fractional library routines. 50274 (line 1501) 50275* __satfractsfuta: Fixed-point fractional library routines. 50276 (line 1506) 50277* __satfractsida: Fixed-point fractional library routines. 50278 (line 1447) 50279* __satfractsidq: Fixed-point fractional library routines. 50280 (line 1444) 50281* __satfractsiha: Fixed-point fractional library routines. 50282 (line 1445) 50283* __satfractsihq: Fixed-point fractional library routines. 50284 (line 1442) 50285* __satfractsiqq: Fixed-point fractional library routines. 50286 (line 1441) 50287* __satfractsisa: Fixed-point fractional library routines. 50288 (line 1446) 50289* __satfractsisq: Fixed-point fractional library routines. 50290 (line 1443) 50291* __satfractsita: Fixed-point fractional library routines. 50292 (line 1448) 50293* __satfractsiuda: Fixed-point fractional library routines. 50294 (line 1455) 50295* __satfractsiudq: Fixed-point fractional library routines. 50296 (line 1452) 50297* __satfractsiuha: Fixed-point fractional library routines. 50298 (line 1453) 50299* __satfractsiuhq: Fixed-point fractional library routines. 50300 (line 1450) 50301* __satfractsiuqq: Fixed-point fractional library routines. 50302 (line 1449) 50303* __satfractsiusa: Fixed-point fractional library routines. 50304 (line 1454) 50305* __satfractsiusq: Fixed-point fractional library routines. 50306 (line 1451) 50307* __satfractsiuta: Fixed-point fractional library routines. 50308 (line 1456) 50309* __satfractsqda: Fixed-point fractional library routines. 50310 (line 1086) 50311* __satfractsqdq2: Fixed-point fractional library routines. 50312 (line 1083) 50313* __satfractsqha: Fixed-point fractional library routines. 50314 (line 1084) 50315* __satfractsqhq2: Fixed-point fractional library routines. 50316 (line 1082) 50317* __satfractsqqq2: Fixed-point fractional library routines. 50318 (line 1081) 50319* __satfractsqsa: Fixed-point fractional library routines. 50320 (line 1085) 50321* __satfractsqta: Fixed-point fractional library routines. 50322 (line 1087) 50323* __satfractsquda: Fixed-point fractional library routines. 50324 (line 1097) 50325* __satfractsqudq: Fixed-point fractional library routines. 50326 (line 1092) 50327* __satfractsquha: Fixed-point fractional library routines. 50328 (line 1094) 50329* __satfractsquhq: Fixed-point fractional library routines. 50330 (line 1090) 50331* __satfractsquqq: Fixed-point fractional library routines. 50332 (line 1088) 50333* __satfractsqusa: Fixed-point fractional library routines. 50334 (line 1096) 50335* __satfractsqusq: Fixed-point fractional library routines. 50336 (line 1091) 50337* __satfractsquta: Fixed-point fractional library routines. 50338 (line 1098) 50339* __satfracttada2: Fixed-point fractional library routines. 50340 (line 1182) 50341* __satfracttadq: Fixed-point fractional library routines. 50342 (line 1179) 50343* __satfracttaha2: Fixed-point fractional library routines. 50344 (line 1180) 50345* __satfracttahq: Fixed-point fractional library routines. 50346 (line 1177) 50347* __satfracttaqq: Fixed-point fractional library routines. 50348 (line 1176) 50349* __satfracttasa2: Fixed-point fractional library routines. 50350 (line 1181) 50351* __satfracttasq: Fixed-point fractional library routines. 50352 (line 1178) 50353* __satfracttauda: Fixed-point fractional library routines. 50354 (line 1193) 50355* __satfracttaudq: Fixed-point fractional library routines. 50356 (line 1188) 50357* __satfracttauha: Fixed-point fractional library routines. 50358 (line 1190) 50359* __satfracttauhq: Fixed-point fractional library routines. 50360 (line 1185) 50361* __satfracttauqq: Fixed-point fractional library routines. 50362 (line 1183) 50363* __satfracttausa: Fixed-point fractional library routines. 50364 (line 1192) 50365* __satfracttausq: Fixed-point fractional library routines. 50366 (line 1186) 50367* __satfracttauta: Fixed-point fractional library routines. 50368 (line 1195) 50369* __satfracttida: Fixed-point fractional library routines. 50370 (line 1479) 50371* __satfracttidq: Fixed-point fractional library routines. 50372 (line 1476) 50373* __satfracttiha: Fixed-point fractional library routines. 50374 (line 1477) 50375* __satfracttihq: Fixed-point fractional library routines. 50376 (line 1474) 50377* __satfracttiqq: Fixed-point fractional library routines. 50378 (line 1473) 50379* __satfracttisa: Fixed-point fractional library routines. 50380 (line 1478) 50381* __satfracttisq: Fixed-point fractional library routines. 50382 (line 1475) 50383* __satfracttita: Fixed-point fractional library routines. 50384 (line 1480) 50385* __satfracttiuda: Fixed-point fractional library routines. 50386 (line 1488) 50387* __satfracttiudq: Fixed-point fractional library routines. 50388 (line 1484) 50389* __satfracttiuha: Fixed-point fractional library routines. 50390 (line 1486) 50391* __satfracttiuhq: Fixed-point fractional library routines. 50392 (line 1482) 50393* __satfracttiuqq: Fixed-point fractional library routines. 50394 (line 1481) 50395* __satfracttiusa: Fixed-point fractional library routines. 50396 (line 1487) 50397* __satfracttiusq: Fixed-point fractional library routines. 50398 (line 1483) 50399* __satfracttiuta: Fixed-point fractional library routines. 50400 (line 1489) 50401* __satfractudada: Fixed-point fractional library routines. 50402 (line 1358) 50403* __satfractudadq: Fixed-point fractional library routines. 50404 (line 1353) 50405* __satfractudaha: Fixed-point fractional library routines. 50406 (line 1355) 50407* __satfractudahq: Fixed-point fractional library routines. 50408 (line 1351) 50409* __satfractudaqq: Fixed-point fractional library routines. 50410 (line 1349) 50411* __satfractudasa: Fixed-point fractional library routines. 50412 (line 1357) 50413* __satfractudasq: Fixed-point fractional library routines. 50414 (line 1352) 50415* __satfractudata: Fixed-point fractional library routines. 50416 (line 1359) 50417* __satfractudaudq: Fixed-point fractional library routines. 50418 (line 1367) 50419* __satfractudauha2: Fixed-point fractional library routines. 50420 (line 1369) 50421* __satfractudauhq: Fixed-point fractional library routines. 50422 (line 1363) 50423* __satfractudauqq: Fixed-point fractional library routines. 50424 (line 1361) 50425* __satfractudausa2: Fixed-point fractional library routines. 50426 (line 1371) 50427* __satfractudausq: Fixed-point fractional library routines. 50428 (line 1365) 50429* __satfractudauta2: Fixed-point fractional library routines. 50430 (line 1373) 50431* __satfractudqda: Fixed-point fractional library routines. 50432 (line 1282) 50433* __satfractudqdq: Fixed-point fractional library routines. 50434 (line 1277) 50435* __satfractudqha: Fixed-point fractional library routines. 50436 (line 1279) 50437* __satfractudqhq: Fixed-point fractional library routines. 50438 (line 1274) 50439* __satfractudqqq: Fixed-point fractional library routines. 50440 (line 1272) 50441* __satfractudqsa: Fixed-point fractional library routines. 50442 (line 1281) 50443* __satfractudqsq: Fixed-point fractional library routines. 50444 (line 1275) 50445* __satfractudqta: Fixed-point fractional library routines. 50446 (line 1284) 50447* __satfractudquda: Fixed-point fractional library routines. 50448 (line 1296) 50449* __satfractudquha: Fixed-point fractional library routines. 50450 (line 1292) 50451* __satfractudquhq2: Fixed-point fractional library routines. 50452 (line 1288) 50453* __satfractudquqq2: Fixed-point fractional library routines. 50454 (line 1286) 50455* __satfractudqusa: Fixed-point fractional library routines. 50456 (line 1294) 50457* __satfractudqusq2: Fixed-point fractional library routines. 50458 (line 1290) 50459* __satfractudquta: Fixed-point fractional library routines. 50460 (line 1298) 50461* __satfractuhada: Fixed-point fractional library routines. 50462 (line 1310) 50463* __satfractuhadq: Fixed-point fractional library routines. 50464 (line 1305) 50465* __satfractuhaha: Fixed-point fractional library routines. 50466 (line 1307) 50467* __satfractuhahq: Fixed-point fractional library routines. 50468 (line 1302) 50469* __satfractuhaqq: Fixed-point fractional library routines. 50470 (line 1300) 50471* __satfractuhasa: Fixed-point fractional library routines. 50472 (line 1309) 50473* __satfractuhasq: Fixed-point fractional library routines. 50474 (line 1303) 50475* __satfractuhata: Fixed-point fractional library routines. 50476 (line 1312) 50477* __satfractuhauda2: Fixed-point fractional library routines. 50478 (line 1324) 50479* __satfractuhaudq: Fixed-point fractional library routines. 50480 (line 1320) 50481* __satfractuhauhq: Fixed-point fractional library routines. 50482 (line 1316) 50483* __satfractuhauqq: Fixed-point fractional library routines. 50484 (line 1314) 50485* __satfractuhausa2: Fixed-point fractional library routines. 50486 (line 1322) 50487* __satfractuhausq: Fixed-point fractional library routines. 50488 (line 1318) 50489* __satfractuhauta2: Fixed-point fractional library routines. 50490 (line 1326) 50491* __satfractuhqda: Fixed-point fractional library routines. 50492 (line 1231) 50493* __satfractuhqdq: Fixed-point fractional library routines. 50494 (line 1228) 50495* __satfractuhqha: Fixed-point fractional library routines. 50496 (line 1229) 50497* __satfractuhqhq: Fixed-point fractional library routines. 50498 (line 1226) 50499* __satfractuhqqq: Fixed-point fractional library routines. 50500 (line 1225) 50501* __satfractuhqsa: Fixed-point fractional library routines. 50502 (line 1230) 50503* __satfractuhqsq: Fixed-point fractional library routines. 50504 (line 1227) 50505* __satfractuhqta: Fixed-point fractional library routines. 50506 (line 1232) 50507* __satfractuhquda: Fixed-point fractional library routines. 50508 (line 1242) 50509* __satfractuhqudq2: Fixed-point fractional library routines. 50510 (line 1237) 50511* __satfractuhquha: Fixed-point fractional library routines. 50512 (line 1239) 50513* __satfractuhquqq2: Fixed-point fractional library routines. 50514 (line 1233) 50515* __satfractuhqusa: Fixed-point fractional library routines. 50516 (line 1241) 50517* __satfractuhqusq2: Fixed-point fractional library routines. 50518 (line 1235) 50519* __satfractuhquta: Fixed-point fractional library routines. 50520 (line 1244) 50521* __satfractunsdida: Fixed-point fractional library routines. 50522 (line 1841) 50523* __satfractunsdidq: Fixed-point fractional library routines. 50524 (line 1837) 50525* __satfractunsdiha: Fixed-point fractional library routines. 50526 (line 1839) 50527* __satfractunsdihq: Fixed-point fractional library routines. 50528 (line 1835) 50529* __satfractunsdiqq: Fixed-point fractional library routines. 50530 (line 1834) 50531* __satfractunsdisa: Fixed-point fractional library routines. 50532 (line 1840) 50533* __satfractunsdisq: Fixed-point fractional library routines. 50534 (line 1836) 50535* __satfractunsdita: Fixed-point fractional library routines. 50536 (line 1842) 50537* __satfractunsdiuda: Fixed-point fractional library routines. 50538 (line 1856) 50539* __satfractunsdiudq: Fixed-point fractional library routines. 50540 (line 1850) 50541* __satfractunsdiuha: Fixed-point fractional library routines. 50542 (line 1852) 50543* __satfractunsdiuhq: Fixed-point fractional library routines. 50544 (line 1846) 50545* __satfractunsdiuqq: Fixed-point fractional library routines. 50546 (line 1844) 50547* __satfractunsdiusa: Fixed-point fractional library routines. 50548 (line 1854) 50549* __satfractunsdiusq: Fixed-point fractional library routines. 50550 (line 1848) 50551* __satfractunsdiuta: Fixed-point fractional library routines. 50552 (line 1858) 50553* __satfractunshida: Fixed-point fractional library routines. 50554 (line 1793) 50555* __satfractunshidq: Fixed-point fractional library routines. 50556 (line 1789) 50557* __satfractunshiha: Fixed-point fractional library routines. 50558 (line 1791) 50559* __satfractunshihq: Fixed-point fractional library routines. 50560 (line 1787) 50561* __satfractunshiqq: Fixed-point fractional library routines. 50562 (line 1786) 50563* __satfractunshisa: Fixed-point fractional library routines. 50564 (line 1792) 50565* __satfractunshisq: Fixed-point fractional library routines. 50566 (line 1788) 50567* __satfractunshita: Fixed-point fractional library routines. 50568 (line 1794) 50569* __satfractunshiuda: Fixed-point fractional library routines. 50570 (line 1808) 50571* __satfractunshiudq: Fixed-point fractional library routines. 50572 (line 1802) 50573* __satfractunshiuha: Fixed-point fractional library routines. 50574 (line 1804) 50575* __satfractunshiuhq: Fixed-point fractional library routines. 50576 (line 1798) 50577* __satfractunshiuqq: Fixed-point fractional library routines. 50578 (line 1796) 50579* __satfractunshiusa: Fixed-point fractional library routines. 50580 (line 1806) 50581* __satfractunshiusq: Fixed-point fractional library routines. 50582 (line 1800) 50583* __satfractunshiuta: Fixed-point fractional library routines. 50584 (line 1810) 50585* __satfractunsqida: Fixed-point fractional library routines. 50586 (line 1767) 50587* __satfractunsqidq: Fixed-point fractional library routines. 50588 (line 1763) 50589* __satfractunsqiha: Fixed-point fractional library routines. 50590 (line 1765) 50591* __satfractunsqihq: Fixed-point fractional library routines. 50592 (line 1761) 50593* __satfractunsqiqq: Fixed-point fractional library routines. 50594 (line 1760) 50595* __satfractunsqisa: Fixed-point fractional library routines. 50596 (line 1766) 50597* __satfractunsqisq: Fixed-point fractional library routines. 50598 (line 1762) 50599* __satfractunsqita: Fixed-point fractional library routines. 50600 (line 1768) 50601* __satfractunsqiuda: Fixed-point fractional library routines. 50602 (line 1782) 50603* __satfractunsqiudq: Fixed-point fractional library routines. 50604 (line 1776) 50605* __satfractunsqiuha: Fixed-point fractional library routines. 50606 (line 1778) 50607* __satfractunsqiuhq: Fixed-point fractional library routines. 50608 (line 1772) 50609* __satfractunsqiuqq: Fixed-point fractional library routines. 50610 (line 1770) 50611* __satfractunsqiusa: Fixed-point fractional library routines. 50612 (line 1780) 50613* __satfractunsqiusq: Fixed-point fractional library routines. 50614 (line 1774) 50615* __satfractunsqiuta: Fixed-point fractional library routines. 50616 (line 1784) 50617* __satfractunssida: Fixed-point fractional library routines. 50618 (line 1818) 50619* __satfractunssidq: Fixed-point fractional library routines. 50620 (line 1815) 50621* __satfractunssiha: Fixed-point fractional library routines. 50622 (line 1816) 50623* __satfractunssihq: Fixed-point fractional library routines. 50624 (line 1813) 50625* __satfractunssiqq: Fixed-point fractional library routines. 50626 (line 1812) 50627* __satfractunssisa: Fixed-point fractional library routines. 50628 (line 1817) 50629* __satfractunssisq: Fixed-point fractional library routines. 50630 (line 1814) 50631* __satfractunssita: Fixed-point fractional library routines. 50632 (line 1819) 50633* __satfractunssiuda: Fixed-point fractional library routines. 50634 (line 1830) 50635* __satfractunssiudq: Fixed-point fractional library routines. 50636 (line 1825) 50637* __satfractunssiuha: Fixed-point fractional library routines. 50638 (line 1827) 50639* __satfractunssiuhq: Fixed-point fractional library routines. 50640 (line 1822) 50641* __satfractunssiuqq: Fixed-point fractional library routines. 50642 (line 1820) 50643* __satfractunssiusa: Fixed-point fractional library routines. 50644 (line 1829) 50645* __satfractunssiusq: Fixed-point fractional library routines. 50646 (line 1823) 50647* __satfractunssiuta: Fixed-point fractional library routines. 50648 (line 1832) 50649* __satfractunstida: Fixed-point fractional library routines. 50650 (line 1870) 50651* __satfractunstidq: Fixed-point fractional library routines. 50652 (line 1865) 50653* __satfractunstiha: Fixed-point fractional library routines. 50654 (line 1867) 50655* __satfractunstihq: Fixed-point fractional library routines. 50656 (line 1862) 50657* __satfractunstiqq: Fixed-point fractional library routines. 50658 (line 1860) 50659* __satfractunstisa: Fixed-point fractional library routines. 50660 (line 1869) 50661* __satfractunstisq: Fixed-point fractional library routines. 50662 (line 1863) 50663* __satfractunstita: Fixed-point fractional library routines. 50664 (line 1872) 50665* __satfractunstiuda: Fixed-point fractional library routines. 50666 (line 1886) 50667* __satfractunstiudq: Fixed-point fractional library routines. 50668 (line 1880) 50669* __satfractunstiuha: Fixed-point fractional library routines. 50670 (line 1882) 50671* __satfractunstiuhq: Fixed-point fractional library routines. 50672 (line 1876) 50673* __satfractunstiuqq: Fixed-point fractional library routines. 50674 (line 1874) 50675* __satfractunstiusa: Fixed-point fractional library routines. 50676 (line 1884) 50677* __satfractunstiusq: Fixed-point fractional library routines. 50678 (line 1878) 50679* __satfractunstiuta: Fixed-point fractional library routines. 50680 (line 1888) 50681* __satfractuqqda: Fixed-point fractional library routines. 50682 (line 1207) 50683* __satfractuqqdq: Fixed-point fractional library routines. 50684 (line 1202) 50685* __satfractuqqha: Fixed-point fractional library routines. 50686 (line 1204) 50687* __satfractuqqhq: Fixed-point fractional library routines. 50688 (line 1199) 50689* __satfractuqqqq: Fixed-point fractional library routines. 50690 (line 1197) 50691* __satfractuqqsa: Fixed-point fractional library routines. 50692 (line 1206) 50693* __satfractuqqsq: Fixed-point fractional library routines. 50694 (line 1200) 50695* __satfractuqqta: Fixed-point fractional library routines. 50696 (line 1209) 50697* __satfractuqquda: Fixed-point fractional library routines. 50698 (line 1221) 50699* __satfractuqqudq2: Fixed-point fractional library routines. 50700 (line 1215) 50701* __satfractuqquha: Fixed-point fractional library routines. 50702 (line 1217) 50703* __satfractuqquhq2: Fixed-point fractional library routines. 50704 (line 1211) 50705* __satfractuqqusa: Fixed-point fractional library routines. 50706 (line 1219) 50707* __satfractuqqusq2: Fixed-point fractional library routines. 50708 (line 1213) 50709* __satfractuqquta: Fixed-point fractional library routines. 50710 (line 1223) 50711* __satfractusada: Fixed-point fractional library routines. 50712 (line 1334) 50713* __satfractusadq: Fixed-point fractional library routines. 50714 (line 1331) 50715* __satfractusaha: Fixed-point fractional library routines. 50716 (line 1332) 50717* __satfractusahq: Fixed-point fractional library routines. 50718 (line 1329) 50719* __satfractusaqq: Fixed-point fractional library routines. 50720 (line 1328) 50721* __satfractusasa: Fixed-point fractional library routines. 50722 (line 1333) 50723* __satfractusasq: Fixed-point fractional library routines. 50724 (line 1330) 50725* __satfractusata: Fixed-point fractional library routines. 50726 (line 1335) 50727* __satfractusauda2: Fixed-point fractional library routines. 50728 (line 1345) 50729* __satfractusaudq: Fixed-point fractional library routines. 50730 (line 1341) 50731* __satfractusauha2: Fixed-point fractional library routines. 50732 (line 1343) 50733* __satfractusauhq: Fixed-point fractional library routines. 50734 (line 1338) 50735* __satfractusauqq: Fixed-point fractional library routines. 50736 (line 1336) 50737* __satfractusausq: Fixed-point fractional library routines. 50738 (line 1339) 50739* __satfractusauta2: Fixed-point fractional library routines. 50740 (line 1347) 50741* __satfractusqda: Fixed-point fractional library routines. 50742 (line 1255) 50743* __satfractusqdq: Fixed-point fractional library routines. 50744 (line 1250) 50745* __satfractusqha: Fixed-point fractional library routines. 50746 (line 1252) 50747* __satfractusqhq: Fixed-point fractional library routines. 50748 (line 1248) 50749* __satfractusqqq: Fixed-point fractional library routines. 50750 (line 1246) 50751* __satfractusqsa: Fixed-point fractional library routines. 50752 (line 1254) 50753* __satfractusqsq: Fixed-point fractional library routines. 50754 (line 1249) 50755* __satfractusqta: Fixed-point fractional library routines. 50756 (line 1256) 50757* __satfractusquda: Fixed-point fractional library routines. 50758 (line 1268) 50759* __satfractusqudq2: Fixed-point fractional library routines. 50760 (line 1262) 50761* __satfractusquha: Fixed-point fractional library routines. 50762 (line 1264) 50763* __satfractusquhq2: Fixed-point fractional library routines. 50764 (line 1260) 50765* __satfractusquqq2: Fixed-point fractional library routines. 50766 (line 1258) 50767* __satfractusqusa: Fixed-point fractional library routines. 50768 (line 1266) 50769* __satfractusquta: Fixed-point fractional library routines. 50770 (line 1270) 50771* __satfractutada: Fixed-point fractional library routines. 50772 (line 1385) 50773* __satfractutadq: Fixed-point fractional library routines. 50774 (line 1380) 50775* __satfractutaha: Fixed-point fractional library routines. 50776 (line 1382) 50777* __satfractutahq: Fixed-point fractional library routines. 50778 (line 1377) 50779* __satfractutaqq: Fixed-point fractional library routines. 50780 (line 1375) 50781* __satfractutasa: Fixed-point fractional library routines. 50782 (line 1384) 50783* __satfractutasq: Fixed-point fractional library routines. 50784 (line 1378) 50785* __satfractutata: Fixed-point fractional library routines. 50786 (line 1387) 50787* __satfractutauda2: Fixed-point fractional library routines. 50788 (line 1401) 50789* __satfractutaudq: Fixed-point fractional library routines. 50790 (line 1395) 50791* __satfractutauha2: Fixed-point fractional library routines. 50792 (line 1397) 50793* __satfractutauhq: Fixed-point fractional library routines. 50794 (line 1391) 50795* __satfractutauqq: Fixed-point fractional library routines. 50796 (line 1389) 50797* __satfractutausa2: Fixed-point fractional library routines. 50798 (line 1399) 50799* __satfractutausq: Fixed-point fractional library routines. 50800 (line 1393) 50801* __splitstack_find: Miscellaneous routines. 50802 (line 15) 50803* __ssaddda3: Fixed-point fractional library routines. 50804 (line 74) 50805* __ssadddq3: Fixed-point fractional library routines. 50806 (line 69) 50807* __ssaddha3: Fixed-point fractional library routines. 50808 (line 71) 50809* __ssaddhq3: Fixed-point fractional library routines. 50810 (line 67) 50811* __ssaddqq3: Fixed-point fractional library routines. 50812 (line 65) 50813* __ssaddsa3: Fixed-point fractional library routines. 50814 (line 73) 50815* __ssaddsq3: Fixed-point fractional library routines. 50816 (line 68) 50817* __ssaddta3: Fixed-point fractional library routines. 50818 (line 75) 50819* __ssashlda3: Fixed-point fractional library routines. 50820 (line 409) 50821* __ssashldq3: Fixed-point fractional library routines. 50822 (line 405) 50823* __ssashlha3: Fixed-point fractional library routines. 50824 (line 407) 50825* __ssashlhq3: Fixed-point fractional library routines. 50826 (line 403) 50827* __ssashlsa3: Fixed-point fractional library routines. 50828 (line 408) 50829* __ssashlsq3: Fixed-point fractional library routines. 50830 (line 404) 50831* __ssashlta3: Fixed-point fractional library routines. 50832 (line 410) 50833* __ssdivda3: Fixed-point fractional library routines. 50834 (line 268) 50835* __ssdivdq3: Fixed-point fractional library routines. 50836 (line 263) 50837* __ssdivha3: Fixed-point fractional library routines. 50838 (line 265) 50839* __ssdivhq3: Fixed-point fractional library routines. 50840 (line 261) 50841* __ssdivqq3: Fixed-point fractional library routines. 50842 (line 259) 50843* __ssdivsa3: Fixed-point fractional library routines. 50844 (line 267) 50845* __ssdivsq3: Fixed-point fractional library routines. 50846 (line 262) 50847* __ssdivta3: Fixed-point fractional library routines. 50848 (line 269) 50849* __ssmulda3: Fixed-point fractional library routines. 50850 (line 200) 50851* __ssmuldq3: Fixed-point fractional library routines. 50852 (line 195) 50853* __ssmulha3: Fixed-point fractional library routines. 50854 (line 197) 50855* __ssmulhq3: Fixed-point fractional library routines. 50856 (line 193) 50857* __ssmulqq3: Fixed-point fractional library routines. 50858 (line 191) 50859* __ssmulsa3: Fixed-point fractional library routines. 50860 (line 199) 50861* __ssmulsq3: Fixed-point fractional library routines. 50862 (line 194) 50863* __ssmulta3: Fixed-point fractional library routines. 50864 (line 201) 50865* __ssnegda2: Fixed-point fractional library routines. 50866 (line 323) 50867* __ssnegdq2: Fixed-point fractional library routines. 50868 (line 320) 50869* __ssnegha2: Fixed-point fractional library routines. 50870 (line 321) 50871* __ssneghq2: Fixed-point fractional library routines. 50872 (line 318) 50873* __ssnegqq2: Fixed-point fractional library routines. 50874 (line 317) 50875* __ssnegsa2: Fixed-point fractional library routines. 50876 (line 322) 50877* __ssnegsq2: Fixed-point fractional library routines. 50878 (line 319) 50879* __ssnegta2: Fixed-point fractional library routines. 50880 (line 324) 50881* __sssubda3: Fixed-point fractional library routines. 50882 (line 136) 50883* __sssubdq3: Fixed-point fractional library routines. 50884 (line 131) 50885* __sssubha3: Fixed-point fractional library routines. 50886 (line 133) 50887* __sssubhq3: Fixed-point fractional library routines. 50888 (line 129) 50889* __sssubqq3: Fixed-point fractional library routines. 50890 (line 127) 50891* __sssubsa3: Fixed-point fractional library routines. 50892 (line 135) 50893* __sssubsq3: Fixed-point fractional library routines. 50894 (line 130) 50895* __sssubta3: Fixed-point fractional library routines. 50896 (line 137) 50897* __subda3: Fixed-point fractional library routines. 50898 (line 114) 50899* __subdf3: Soft float library routines. 50900 (line 30) 50901* __subdq3: Fixed-point fractional library routines. 50902 (line 101) 50903* __subha3: Fixed-point fractional library routines. 50904 (line 111) 50905* __subhq3: Fixed-point fractional library routines. 50906 (line 99) 50907* __subqq3: Fixed-point fractional library routines. 50908 (line 97) 50909* __subsa3: Fixed-point fractional library routines. 50910 (line 113) 50911* __subsf3: Soft float library routines. 50912 (line 29) 50913* __subsq3: Fixed-point fractional library routines. 50914 (line 100) 50915* __subta3: Fixed-point fractional library routines. 50916 (line 115) 50917* __subtf3: Soft float library routines. 50918 (line 31) 50919* __subuda3: Fixed-point fractional library routines. 50920 (line 121) 50921* __subudq3: Fixed-point fractional library routines. 50922 (line 109) 50923* __subuha3: Fixed-point fractional library routines. 50924 (line 117) 50925* __subuhq3: Fixed-point fractional library routines. 50926 (line 105) 50927* __subuqq3: Fixed-point fractional library routines. 50928 (line 103) 50929* __subusa3: Fixed-point fractional library routines. 50930 (line 119) 50931* __subusq3: Fixed-point fractional library routines. 50932 (line 107) 50933* __subuta3: Fixed-point fractional library routines. 50934 (line 123) 50935* __subvdi3: Integer library routines. 50936 (line 122) 50937* __subvsi3: Integer library routines. 50938 (line 121) 50939* __subxf3: Soft float library routines. 50940 (line 33) 50941* __truncdfsf2: Soft float library routines. 50942 (line 75) 50943* __trunctfdf2: Soft float library routines. 50944 (line 72) 50945* __trunctfsf2: Soft float library routines. 50946 (line 74) 50947* __truncxfdf2: Soft float library routines. 50948 (line 71) 50949* __truncxfsf2: Soft float library routines. 50950 (line 73) 50951* __ucmpdi2: Integer library routines. 50952 (line 92) 50953* __ucmpti2: Integer library routines. 50954 (line 93) 50955* __udivdi3: Integer library routines. 50956 (line 52) 50957* __udivmoddi4: Integer library routines. 50958 (line 59) 50959* __udivmodti4: Integer library routines. 50960 (line 61) 50961* __udivsi3: Integer library routines. 50962 (line 50) 50963* __udivti3: Integer library routines. 50964 (line 54) 50965* __udivuda3: Fixed-point fractional library routines. 50966 (line 252) 50967* __udivudq3: Fixed-point fractional library routines. 50968 (line 246) 50969* __udivuha3: Fixed-point fractional library routines. 50970 (line 248) 50971* __udivuhq3: Fixed-point fractional library routines. 50972 (line 242) 50973* __udivuqq3: Fixed-point fractional library routines. 50974 (line 240) 50975* __udivusa3: Fixed-point fractional library routines. 50976 (line 250) 50977* __udivusq3: Fixed-point fractional library routines. 50978 (line 244) 50979* __udivuta3: Fixed-point fractional library routines. 50980 (line 254) 50981* __umoddi3: Integer library routines. 50982 (line 69) 50983* __umodsi3: Integer library routines. 50984 (line 67) 50985* __umodti3: Integer library routines. 50986 (line 71) 50987* __unorddf2: Soft float library routines. 50988 (line 172) 50989* __unordsf2: Soft float library routines. 50990 (line 171) 50991* __unordtf2: Soft float library routines. 50992 (line 173) 50993* __usadduda3: Fixed-point fractional library routines. 50994 (line 91) 50995* __usaddudq3: Fixed-point fractional library routines. 50996 (line 85) 50997* __usadduha3: Fixed-point fractional library routines. 50998 (line 87) 50999* __usadduhq3: Fixed-point fractional library routines. 51000 (line 81) 51001* __usadduqq3: Fixed-point fractional library routines. 51002 (line 79) 51003* __usaddusa3: Fixed-point fractional library routines. 51004 (line 89) 51005* __usaddusq3: Fixed-point fractional library routines. 51006 (line 83) 51007* __usadduta3: Fixed-point fractional library routines. 51008 (line 93) 51009* __usashluda3: Fixed-point fractional library routines. 51010 (line 427) 51011* __usashludq3: Fixed-point fractional library routines. 51012 (line 421) 51013* __usashluha3: Fixed-point fractional library routines. 51014 (line 423) 51015* __usashluhq3: Fixed-point fractional library routines. 51016 (line 417) 51017* __usashluqq3: Fixed-point fractional library routines. 51018 (line 415) 51019* __usashlusa3: Fixed-point fractional library routines. 51020 (line 425) 51021* __usashlusq3: Fixed-point fractional library routines. 51022 (line 419) 51023* __usashluta3: Fixed-point fractional library routines. 51024 (line 429) 51025* __usdivuda3: Fixed-point fractional library routines. 51026 (line 286) 51027* __usdivudq3: Fixed-point fractional library routines. 51028 (line 280) 51029* __usdivuha3: Fixed-point fractional library routines. 51030 (line 282) 51031* __usdivuhq3: Fixed-point fractional library routines. 51032 (line 276) 51033* __usdivuqq3: Fixed-point fractional library routines. 51034 (line 274) 51035* __usdivusa3: Fixed-point fractional library routines. 51036 (line 284) 51037* __usdivusq3: Fixed-point fractional library routines. 51038 (line 278) 51039* __usdivuta3: Fixed-point fractional library routines. 51040 (line 288) 51041* __usmuluda3: Fixed-point fractional library routines. 51042 (line 218) 51043* __usmuludq3: Fixed-point fractional library routines. 51044 (line 212) 51045* __usmuluha3: Fixed-point fractional library routines. 51046 (line 214) 51047* __usmuluhq3: Fixed-point fractional library routines. 51048 (line 208) 51049* __usmuluqq3: Fixed-point fractional library routines. 51050 (line 206) 51051* __usmulusa3: Fixed-point fractional library routines. 51052 (line 216) 51053* __usmulusq3: Fixed-point fractional library routines. 51054 (line 210) 51055* __usmuluta3: Fixed-point fractional library routines. 51056 (line 220) 51057* __usneguda2: Fixed-point fractional library routines. 51058 (line 337) 51059* __usnegudq2: Fixed-point fractional library routines. 51060 (line 332) 51061* __usneguha2: Fixed-point fractional library routines. 51062 (line 334) 51063* __usneguhq2: Fixed-point fractional library routines. 51064 (line 329) 51065* __usneguqq2: Fixed-point fractional library routines. 51066 (line 327) 51067* __usnegusa2: Fixed-point fractional library routines. 51068 (line 336) 51069* __usnegusq2: Fixed-point fractional library routines. 51070 (line 330) 51071* __usneguta2: Fixed-point fractional library routines. 51072 (line 339) 51073* __ussubuda3: Fixed-point fractional library routines. 51074 (line 154) 51075* __ussubudq3: Fixed-point fractional library routines. 51076 (line 148) 51077* __ussubuha3: Fixed-point fractional library routines. 51078 (line 150) 51079* __ussubuhq3: Fixed-point fractional library routines. 51080 (line 144) 51081* __ussubuqq3: Fixed-point fractional library routines. 51082 (line 142) 51083* __ussubusa3: Fixed-point fractional library routines. 51084 (line 152) 51085* __ussubusq3: Fixed-point fractional library routines. 51086 (line 146) 51087* __ussubuta3: Fixed-point fractional library routines. 51088 (line 156) 51089* abort: Portability. (line 20) 51090* abs: Arithmetic. (line 200) 51091* abs and attributes: Expressions. (line 83) 51092* absence_set: Processor pipeline description. 51093 (line 223) 51094* absM2 instruction pattern: Standard Names. (line 815) 51095* absolute value: Arithmetic. (line 200) 51096* ABSU_EXPR: Unary and Binary Expressions. 51097 (line 6) 51098* ABS_EXPR: Unary and Binary Expressions. 51099 (line 6) 51100* access to operands: Accessors. (line 6) 51101* access to special operands: Special Accessors. (line 6) 51102* accessors: Accessors. (line 6) 51103* ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 48) 51104* ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 140) 51105* ACCUM_TYPE_SIZE: Type Layout. (line 87) 51106* acosM2 instruction pattern: Standard Names. (line 902) 51107* ADA_LONG_TYPE_SIZE: Type Layout. (line 25) 51108* Adding a new GIMPLE statement code: Adding a new GIMPLE statement code. 51109 (line 6) 51110* ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 14) 51111* addM3 instruction pattern: Standard Names. (line 410) 51112* addMODEcc instruction pattern: Standard Names. (line 1487) 51113* addptrM3 instruction pattern: Standard Names. (line 443) 51114* address constraints: Simple Constraints. (line 162) 51115* addressing modes: Addressing Modes. (line 6) 51116* address_operand: Machine-Independent Predicates. 51117 (line 62) 51118* address_operand <1>: Simple Constraints. (line 166) 51119* addr_diff_vec: Side Effects. (line 326) 51120* addr_diff_vec, length of: Insn Lengths. (line 26) 51121* ADDR_EXPR: Storage References. (line 6) 51122* addr_vec: Side Effects. (line 321) 51123* addr_vec, length of: Insn Lengths. (line 26) 51124* addvM4 instruction pattern: Standard Names. (line 426) 51125* ADJUST_FIELD_ALIGN: Storage Layout. (line 212) 51126* ADJUST_INSN_LENGTH: Insn Lengths. (line 41) 51127* ADJUST_REG_ALLOC_ORDER: Allocation Order. (line 22) 51128* aggregates as return values: Aggregate Return. (line 6) 51129* alias: Alias analysis. (line 6) 51130* allocate_stack instruction pattern: Standard Names. (line 1854) 51131* ALL_REGS: Register Classes. (line 17) 51132* alternate entry points: Insns. (line 146) 51133* anchored addresses: Anchored Addresses. (line 6) 51134* and: Arithmetic. (line 158) 51135* and and attributes: Expressions. (line 50) 51136* and, canonicalization of: Insn Canonicalizations. 51137 (line 67) 51138* andM3 instruction pattern: Standard Names. (line 416) 51139* ANNOTATE_EXPR: Unary and Binary Expressions. 51140 (line 6) 51141* annotations: Annotations. (line 6) 51142* APPLY_RESULT_SIZE: Scalar Return. (line 112) 51143* ARGS_GROW_DOWNWARD: Frame Layout. (line 30) 51144* argument passing: Interface. (line 36) 51145* arguments in registers: Register Arguments. (line 6) 51146* arguments on stack: Stack Arguments. (line 6) 51147* ARG_POINTER_CFA_OFFSET: Frame Layout. (line 207) 51148* ARG_POINTER_REGNUM: Frame Registers. (line 40) 51149* ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65) 51150* arg_pointer_rtx: Frame Registers. (line 104) 51151* arithmetic library: Soft float library routines. 51152 (line 6) 51153* arithmetic shift: Arithmetic. (line 173) 51154* arithmetic shift with signed saturation: Arithmetic. (line 173) 51155* arithmetic shift with unsigned saturation: Arithmetic. (line 173) 51156* arithmetic, in RTL: Arithmetic. (line 6) 51157* ARITHMETIC_TYPE_P: Types for C++. (line 59) 51158* array: Types. (line 6) 51159* ARRAY_RANGE_REF: Storage References. (line 6) 51160* ARRAY_REF: Storage References. (line 6) 51161* ARRAY_TYPE: Types. (line 6) 51162* ashift: Arithmetic. (line 173) 51163* ashift and attributes: Expressions. (line 83) 51164* ashiftrt: Arithmetic. (line 190) 51165* ashiftrt and attributes: Expressions. (line 83) 51166* ashlM3 instruction pattern: Standard Names. (line 764) 51167* ashrM3 instruction pattern: Standard Names. (line 776) 51168* asinM2 instruction pattern: Standard Names. (line 896) 51169* ASM_APP_OFF: File Framework. (line 76) 51170* ASM_APP_ON: File Framework. (line 69) 51171* ASM_COMMENT_START: File Framework. (line 64) 51172* ASM_DECLARE_COLD_FUNCTION_NAME: Label Output. (line 136) 51173* ASM_DECLARE_COLD_FUNCTION_SIZE: Label Output. (line 151) 51174* ASM_DECLARE_FUNCTION_NAME: Label Output. (line 108) 51175* ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 123) 51176* ASM_DECLARE_OBJECT_NAME: Label Output. (line 164) 51177* ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 192) 51178* ASM_FINAL_SPEC: Driver. (line 81) 51179* ASM_FINISH_DECLARE_OBJECT: Label Output. (line 200) 51180* ASM_FORMAT_PRIVATE_NAME: Label Output. (line 426) 51181* asm_fprintf: Instruction Output. (line 150) 51182* ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 160) 51183* ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 410) 51184* asm_input: Side Effects. (line 308) 51185* asm_input and /v: Flags. (line 65) 51186* ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 80) 51187* asm_noperands: Insns. (line 327) 51188* ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 59) 51189* asm_operands and /v: Flags. (line 65) 51190* asm_operands, RTL sharing: Sharing. (line 48) 51191* asm_operands, usage: Assembler. (line 6) 51192* ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 8) 51193* ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 25) 51194* ASM_OUTPUT_ALIGN: Alignment Output. (line 66) 51195* ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 45) 51196* ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 29) 51197* ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 36) 51198* ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 89) 51199* ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 82) 51200* ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 71) 51201* ASM_OUTPUT_ASCII: Data Output. (line 60) 51202* ASM_OUTPUT_CASE_END: Dispatch Tables. (line 50) 51203* ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 37) 51204* ASM_OUTPUT_COMMON: Uninitialized Data. (line 9) 51205* ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 398) 51206* ASM_OUTPUT_DEF: Label Output. (line 447) 51207* ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 454) 51208* ASM_OUTPUT_DWARF_DATAREL: DWARF. (line 110) 51209* ASM_OUTPUT_DWARF_DELTA: DWARF. (line 89) 51210* ASM_OUTPUT_DWARF_OFFSET: DWARF. (line 98) 51211* ASM_OUTPUT_DWARF_PCREL: DWARF. (line 105) 51212* ASM_OUTPUT_DWARF_TABLE_REF: DWARF. (line 115) 51213* ASM_OUTPUT_DWARF_VMS_DELTA: DWARF. (line 93) 51214* ASM_OUTPUT_EXTERNAL: Label Output. (line 327) 51215* ASM_OUTPUT_FDESC: Data Output. (line 69) 51216* ASM_OUTPUT_FUNCTION_LABEL: Label Output. (line 16) 51217* ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 27) 51218* ASM_OUTPUT_LABEL: Label Output. (line 8) 51219* ASM_OUTPUT_LABELREF: Label Output. (line 349) 51220* ASM_OUTPUT_LABEL_REF: Label Output. (line 371) 51221* ASM_OUTPUT_LOCAL: Uninitialized Data. (line 69) 51222* ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 75) 51223* ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 51) 51224* ASM_OUTPUT_OPCODE: Instruction Output. (line 35) 51225* ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 118) 51226* ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 82) 51227* ASM_OUTPUT_REG_POP: Instruction Output. (line 206) 51228* ASM_OUTPUT_REG_PUSH: Instruction Output. (line 201) 51229* ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 45) 51230* ASM_OUTPUT_SKIP: Alignment Output. (line 53) 51231* ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 83) 51232* ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 93) 51233* ASM_OUTPUT_SYMBOL_REF: Label Output. (line 364) 51234* ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 98) 51235* ASM_OUTPUT_WEAKREF: Label Output. (line 259) 51236* ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 473) 51237* ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 66) 51238* ASM_SPEC: Driver. (line 73) 51239* ASM_STABD_OP: DBX Options. (line 34) 51240* ASM_STABN_OP: DBX Options. (line 41) 51241* ASM_STABS_OP: DBX Options. (line 28) 51242* ASM_WEAKEN_DECL: Label Output. (line 251) 51243* ASM_WEAKEN_LABEL: Label Output. (line 238) 51244* assembler format: File Framework. (line 6) 51245* assembler instructions in RTL: Assembler. (line 6) 51246* ASSEMBLER_DIALECT: Instruction Output. (line 172) 51247* assemble_name: Label Output. (line 8) 51248* assemble_name_raw: Label Output. (line 27) 51249* assigning attribute values to insns: Tagging Insns. (line 6) 51250* ASSUME_EXTENDED_UNWIND_CONTEXT: Frame Registers. (line 163) 51251* asterisk in template: Output Statement. (line 29) 51252* AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 88) 51253* atan2M3 instruction pattern: Standard Names. (line 997) 51254* atanM2 instruction pattern: Standard Names. (line 908) 51255* atomic: GTY Options. (line 197) 51256* atomic_addMODE instruction pattern: Standard Names. (line 2278) 51257* atomic_add_fetchMODE instruction pattern: Standard Names. (line 2307) 51258* atomic_andMODE instruction pattern: Standard Names. (line 2278) 51259* atomic_and_fetchMODE instruction pattern: Standard Names. (line 2307) 51260* atomic_bit_test_and_complementMODE instruction pattern: Standard Names. 51261 (line 2335) 51262* atomic_bit_test_and_resetMODE instruction pattern: Standard Names. 51263 (line 2335) 51264* atomic_bit_test_and_setMODE instruction pattern: Standard Names. 51265 (line 2335) 51266* atomic_compare_and_swapMODE instruction pattern: Standard Names. 51267 (line 2214) 51268* atomic_exchangeMODE instruction pattern: Standard Names. (line 2266) 51269* atomic_fetch_addMODE instruction pattern: Standard Names. (line 2292) 51270* atomic_fetch_andMODE instruction pattern: Standard Names. (line 2292) 51271* atomic_fetch_nandMODE instruction pattern: Standard Names. (line 2292) 51272* atomic_fetch_orMODE instruction pattern: Standard Names. (line 2292) 51273* atomic_fetch_subMODE instruction pattern: Standard Names. (line 2292) 51274* atomic_fetch_xorMODE instruction pattern: Standard Names. (line 2292) 51275* atomic_loadMODE instruction pattern: Standard Names. (line 2245) 51276* atomic_nandMODE instruction pattern: Standard Names. (line 2278) 51277* atomic_nand_fetchMODE instruction pattern: Standard Names. (line 2307) 51278* atomic_orMODE instruction pattern: Standard Names. (line 2278) 51279* atomic_or_fetchMODE instruction pattern: Standard Names. (line 2307) 51280* atomic_storeMODE instruction pattern: Standard Names. (line 2255) 51281* atomic_subMODE instruction pattern: Standard Names. (line 2278) 51282* atomic_sub_fetchMODE instruction pattern: Standard Names. (line 2307) 51283* atomic_test_and_set instruction pattern: Standard Names. (line 2324) 51284* atomic_xorMODE instruction pattern: Standard Names. (line 2278) 51285* atomic_xor_fetchMODE instruction pattern: Standard Names. (line 2307) 51286* attr: Expressions. (line 163) 51287* attr <1>: Tagging Insns. (line 54) 51288* attribute expressions: Expressions. (line 6) 51289* attribute specifications: Attr Example. (line 6) 51290* attribute specifications example: Attr Example. (line 6) 51291* attributes: Attributes. (line 6) 51292* attributes, defining: Defining Attributes. 51293 (line 6) 51294* attributes, target-specific: Target Attributes. (line 6) 51295* ATTRIBUTE_ALIGNED_VALUE: Storage Layout. (line 194) 51296* attr_flag: Expressions. (line 138) 51297* autoincrement addressing, availability: Portability. (line 20) 51298* autoincrement/decrement addressing: Simple Constraints. (line 30) 51299* automata_option: Processor pipeline description. 51300 (line 304) 51301* automaton based pipeline description: Processor pipeline description. 51302 (line 6) 51303* automaton based pipeline description <1>: Processor pipeline description. 51304 (line 49) 51305* automaton based scheduler: Processor pipeline description. 51306 (line 6) 51307* avgM3_ceil instruction pattern: Standard Names. (line 796) 51308* avgM3_floor instruction pattern: Standard Names. (line 784) 51309* AVOID_CCMODE_COPIES: Values in Registers. 51310 (line 148) 51311* backslash: Output Template. (line 46) 51312* barrier: Insns. (line 176) 51313* barrier and /f: Flags. (line 135) 51314* barrier and /v: Flags. (line 33) 51315* BASE_REG_CLASS: Register Classes. (line 111) 51316* basic block: Basic Blocks. (line 6) 51317* Basic Statements: Basic Statements. (line 6) 51318* basic-block.h: Control Flow. (line 6) 51319* basic_block: Basic Blocks. (line 6) 51320* BASIC_BLOCK: Basic Blocks. (line 14) 51321* BB_HEAD, BB_END: Maintaining the CFG. 51322 (line 76) 51323* bb_seq: GIMPLE sequences. (line 72) 51324* BIGGEST_ALIGNMENT: Storage Layout. (line 179) 51325* BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 205) 51326* BImode: Machine Modes. (line 22) 51327* BIND_EXPR: Unary and Binary Expressions. 51328 (line 6) 51329* BINFO_TYPE: Classes. (line 6) 51330* bit-fields: Bit-Fields. (line 6) 51331* BITFIELD_NBYTES_LIMITED: Storage Layout. (line 428) 51332* BITS_BIG_ENDIAN: Storage Layout. (line 11) 51333* BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8) 51334* BITS_PER_UNIT: Machine Modes. (line 440) 51335* BITS_PER_WORD: Storage Layout. (line 50) 51336* bitwise complement: Arithmetic. (line 154) 51337* bitwise exclusive-or: Arithmetic. (line 168) 51338* bitwise inclusive-or: Arithmetic. (line 163) 51339* bitwise logical-and: Arithmetic. (line 158) 51340* BIT_AND_EXPR: Unary and Binary Expressions. 51341 (line 6) 51342* BIT_IOR_EXPR: Unary and Binary Expressions. 51343 (line 6) 51344* BIT_NOT_EXPR: Unary and Binary Expressions. 51345 (line 6) 51346* BIT_XOR_EXPR: Unary and Binary Expressions. 51347 (line 6) 51348* BLKmode: Machine Modes. (line 185) 51349* BLKmode, and function return values: Calls. (line 23) 51350* blockage instruction pattern: Standard Names. (line 2054) 51351* Blocks: Blocks. (line 6) 51352* BLOCK_FOR_INSN, gimple_bb: Maintaining the CFG. 51353 (line 28) 51354* BLOCK_REG_PADDING: Register Arguments. (line 246) 51355* BND32mode: Machine Modes. (line 210) 51356* BND64mode: Machine Modes. (line 210) 51357* bool: Misc. (line 944) 51358* BOOLEAN_TYPE: Types. (line 6) 51359* BOOL_TYPE_SIZE: Type Layout. (line 43) 51360* branch prediction: Profile information. 51361 (line 24) 51362* BRANCH_COST: Costs. (line 104) 51363* break_out_memory_refs: Addressing Modes. (line 134) 51364* BREAK_STMT: Statements for C++. (line 6) 51365* BSS_SECTION_ASM_OP: Sections. (line 67) 51366* bswap: Arithmetic. (line 246) 51367* bswapM2 instruction pattern: Standard Names. (line 804) 51368* btruncM2 instruction pattern: Standard Names. (line 1014) 51369* build0: Macros and Functions. 51370 (line 16) 51371* build1: Macros and Functions. 51372 (line 17) 51373* build2: Macros and Functions. 51374 (line 18) 51375* build3: Macros and Functions. 51376 (line 19) 51377* build4: Macros and Functions. 51378 (line 20) 51379* build5: Macros and Functions. 51380 (line 21) 51381* build6: Macros and Functions. 51382 (line 22) 51383* builtin_longjmp instruction pattern: Standard Names. (line 1952) 51384* builtin_setjmp_receiver instruction pattern: Standard Names. 51385 (line 1942) 51386* builtin_setjmp_setup instruction pattern: Standard Names. (line 1931) 51387* BYTES_BIG_ENDIAN: Storage Layout. (line 23) 51388* BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 229) 51389* byte_mode: Machine Modes. (line 458) 51390* C statements for assembler output: Output Statement. (line 6) 51391* cache: GTY Options. (line 127) 51392* call: Flags. (line 230) 51393* call <1>: Side Effects. (line 92) 51394* call instruction pattern: Standard Names. (line 1607) 51395* call usage: Calls. (line 10) 51396* call, in call_insn: Flags. (line 129) 51397* call, in mem: Flags. (line 70) 51398* call-clobbered register: Register Basics. (line 35) 51399* call-clobbered register <1>: Register Basics. (line 46) 51400* call-clobbered register <2>: Register Basics. (line 52) 51401* call-saved register: Register Basics. (line 35) 51402* call-saved register <1>: Register Basics. (line 46) 51403* call-saved register <2>: Register Basics. (line 52) 51404* call-used register: Register Basics. (line 35) 51405* call-used register <1>: Register Basics. (line 46) 51406* call-used register <2>: Register Basics. (line 52) 51407* calling conventions: Stack and Calling. (line 6) 51408* calling functions in RTL: Calls. (line 6) 51409* CALL_EXPR: Unary and Binary Expressions. 51410 (line 6) 51411* call_insn: Insns. (line 95) 51412* call_insn and /c: Flags. (line 129) 51413* call_insn and /f: Flags. (line 135) 51414* call_insn and /i: Flags. (line 120) 51415* call_insn and /j: Flags. (line 175) 51416* call_insn and /s: Flags. (line 38) 51417* call_insn and /s <1>: Flags. (line 162) 51418* call_insn and /u: Flags. (line 28) 51419* call_insn and /u <1>: Flags. (line 115) 51420* call_insn and /u or /i: Flags. (line 125) 51421* call_insn and /v: Flags. (line 33) 51422* CALL_INSN_FUNCTION_USAGE: Insns. (line 101) 51423* call_pop instruction pattern: Standard Names. (line 1635) 51424* CALL_POPS_ARGS: Stack Arguments. (line 138) 51425* CALL_REALLY_USED_REGISTERS: Register Basics. (line 45) 51426* CALL_USED_REGISTERS: Register Basics. (line 34) 51427* call_used_regs: Register Basics. (line 93) 51428* call_value instruction pattern: Standard Names. (line 1627) 51429* call_value_pop instruction pattern: Standard Names. (line 1635) 51430* canadian: Configure Terms. (line 6) 51431* canonicalization of instructions: Insn Canonicalizations. 51432 (line 6) 51433* canonicalize_funcptr_for_compare instruction pattern: Standard Names. 51434 (line 1786) 51435* can_create_pseudo_p: Standard Names. (line 75) 51436* can_fallthru: Basic Blocks. (line 67) 51437* caret: Multi-Alternative. (line 53) 51438* caret <1>: Guidelines for Diagnostics. 51439 (line 159) 51440* casesi instruction pattern: Standard Names. (line 1728) 51441* CASE_VECTOR_MODE: Misc. (line 26) 51442* CASE_VECTOR_PC_RELATIVE: Misc. (line 39) 51443* CASE_VECTOR_SHORTEN_MODE: Misc. (line 30) 51444* cbranchMODE4 instruction pattern: Standard Names. (line 1596) 51445* cc0: Regs and Memory. (line 329) 51446* cc0 <1>: CC0 Condition Codes. 51447 (line 6) 51448* cc0, RTL sharing: Sharing. (line 30) 51449* cc0_rtx: Regs and Memory. (line 355) 51450* CC1PLUS_SPEC: Driver. (line 63) 51451* CC1_SPEC: Driver. (line 55) 51452* CCmode: Machine Modes. (line 178) 51453* CCmode <1>: MODE_CC Condition Codes. 51454 (line 6) 51455* cc_status: CC0 Condition Codes. 51456 (line 6) 51457* CC_STATUS_MDEP: CC0 Condition Codes. 51458 (line 16) 51459* CC_STATUS_MDEP_INIT: CC0 Condition Codes. 51460 (line 22) 51461* CDImode: Machine Modes. (line 204) 51462* ceilM2 instruction pattern: Standard Names. (line 1033) 51463* CEIL_DIV_EXPR: Unary and Binary Expressions. 51464 (line 6) 51465* CEIL_MOD_EXPR: Unary and Binary Expressions. 51466 (line 6) 51467* CFA_FRAME_BASE_OFFSET: Frame Layout. (line 239) 51468* CFG verification: Maintaining the CFG. 51469 (line 116) 51470* CFG, Control Flow Graph: Control Flow. (line 6) 51471* cfghooks.h: Maintaining the CFG. 51472 (line 6) 51473* cgraph_finalize_function: Parsing pass. (line 51) 51474* chain_circular: GTY Options. (line 160) 51475* chain_next: GTY Options. (line 160) 51476* chain_prev: GTY Options. (line 160) 51477* change_address: Standard Names. (line 47) 51478* CHAR_TYPE_SIZE: Type Layout. (line 38) 51479* check_stack instruction pattern: Standard Names. (line 1872) 51480* CHImode: Machine Modes. (line 204) 51481* class definitions, register: Register Classes. (line 6) 51482* class preference constraints: Class Preferences. (line 6) 51483* class, scope: Classes. (line 6) 51484* classes of RTX codes: RTL Classes. (line 6) 51485* CLASSTYPE_DECLARED_CLASS: Classes. (line 6) 51486* CLASSTYPE_HAS_MUTABLE: Classes. (line 82) 51487* CLASSTYPE_NON_POD_P: Classes. (line 87) 51488* CLASS_MAX_NREGS: Register Classes. (line 531) 51489* CLASS_TYPE_P: Types for C++. (line 63) 51490* Cleanups: Cleanups. (line 6) 51491* CLEANUP_DECL: Statements for C++. (line 6) 51492* CLEANUP_EXPR: Statements for C++. (line 6) 51493* CLEANUP_POINT_EXPR: Unary and Binary Expressions. 51494 (line 6) 51495* CLEANUP_STMT: Statements for C++. (line 6) 51496* clear_cache instruction pattern: Standard Names. (line 2441) 51497* CLEAR_INSN_CACHE: Trampolines. (line 151) 51498* CLEAR_RATIO: Costs. (line 225) 51499* clobber: Side Effects. (line 106) 51500* clobber_high: Side Effects. (line 168) 51501* clrsb: Arithmetic. (line 215) 51502* clrsbM2 instruction pattern: Standard Names. (line 1106) 51503* clz: Arithmetic. (line 222) 51504* clzM2 instruction pattern: Standard Names. (line 1122) 51505* CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 338) 51506* cmpmemM instruction pattern: Standard Names. (line 1287) 51507* cmpstrM instruction pattern: Standard Names. (line 1266) 51508* cmpstrnM instruction pattern: Standard Names. (line 1253) 51509* code generation RTL sequences: Expander Definitions. 51510 (line 6) 51511* code iterators in .md files: Code Iterators. (line 6) 51512* codes, RTL expression: RTL Objects. (line 47) 51513* code_label: Insns. (line 125) 51514* CODE_LABEL: Basic Blocks. (line 50) 51515* code_label and /i: Flags. (line 48) 51516* code_label and /v: Flags. (line 33) 51517* CODE_LABEL_NUMBER: Insns. (line 125) 51518* COImode: Machine Modes. (line 204) 51519* COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32) 51520* COLLECT_EXPORT_LIST: Misc. (line 816) 51521* COLLECT_SHARED_FINI_FUNC: Macros for Initialization. 51522 (line 43) 51523* COLLECT_SHARED_INIT_FUNC: Macros for Initialization. 51524 (line 32) 51525* command-line options, guidelines for: Guidelines for Options. 51526 (line 6) 51527* commit_edge_insertions: Maintaining the CFG. 51528 (line 104) 51529* compare: Arithmetic. (line 46) 51530* compare, canonicalization of: Insn Canonicalizations. 51531 (line 36) 51532* COMPARE_MAX_PIECES: Costs. (line 220) 51533* comparison_operator: Machine-Independent Predicates. 51534 (line 110) 51535* compiler passes and files: Passes. (line 6) 51536* complement, bitwise: Arithmetic. (line 154) 51537* COMPLEX_CST: Constant expressions. 51538 (line 6) 51539* COMPLEX_EXPR: Unary and Binary Expressions. 51540 (line 6) 51541* complex_mode: Machine Modes. (line 302) 51542* COMPLEX_TYPE: Types. (line 6) 51543* COMPONENT_REF: Storage References. (line 6) 51544* Compound Expressions: Compound Expressions. 51545 (line 6) 51546* Compound Lvalues: Compound Lvalues. (line 6) 51547* COMPOUND_EXPR: Unary and Binary Expressions. 51548 (line 6) 51549* COMPOUND_LITERAL_EXPR: Unary and Binary Expressions. 51550 (line 6) 51551* COMPOUND_LITERAL_EXPR_DECL: Unary and Binary Expressions. 51552 (line 392) 51553* COMPOUND_LITERAL_EXPR_DECL_EXPR: Unary and Binary Expressions. 51554 (line 392) 51555* computed jump: Edges. (line 127) 51556* computing the length of an insn: Insn Lengths. (line 6) 51557* concat: Regs and Memory. (line 407) 51558* concatn: Regs and Memory. (line 413) 51559* cond: Comparisons. (line 90) 51560* cond and attributes: Expressions. (line 37) 51561* condition code register: Regs and Memory. (line 329) 51562* condition code status: Condition Code. (line 6) 51563* condition codes: Comparisons. (line 20) 51564* conditional execution: Conditional Execution. 51565 (line 6) 51566* Conditional Expressions: Conditional Expressions. 51567 (line 6) 51568* conditions, in patterns: Patterns. (line 55) 51569* cond_addMODE instruction pattern: Standard Names. (line 1494) 51570* cond_andMODE instruction pattern: Standard Names. (line 1494) 51571* cond_divMODE instruction pattern: Standard Names. (line 1494) 51572* cond_exec: Side Effects. (line 266) 51573* COND_EXPR: Unary and Binary Expressions. 51574 (line 6) 51575* cond_fmaMODE instruction pattern: Standard Names. (line 1532) 51576* cond_fmsMODE instruction pattern: Standard Names. (line 1532) 51577* cond_fnmaMODE instruction pattern: Standard Names. (line 1532) 51578* cond_fnmsMODE instruction pattern: Standard Names. (line 1532) 51579* cond_iorMODE instruction pattern: Standard Names. (line 1494) 51580* cond_modMODE instruction pattern: Standard Names. (line 1494) 51581* cond_mulMODE instruction pattern: Standard Names. (line 1494) 51582* cond_smaxMODE instruction pattern: Standard Names. (line 1494) 51583* cond_sminMODE instruction pattern: Standard Names. (line 1494) 51584* cond_subMODE instruction pattern: Standard Names. (line 1494) 51585* cond_udivMODE instruction pattern: Standard Names. (line 1494) 51586* cond_umaxMODE instruction pattern: Standard Names. (line 1494) 51587* cond_uminMODE instruction pattern: Standard Names. (line 1494) 51588* cond_umodMODE instruction pattern: Standard Names. (line 1494) 51589* cond_xorMODE instruction pattern: Standard Names. (line 1494) 51590* configuration file: Filesystem. (line 6) 51591* configuration file <1>: Host Misc. (line 6) 51592* configure terms: Configure Terms. (line 6) 51593* CONJ_EXPR: Unary and Binary Expressions. 51594 (line 6) 51595* const: Constants. (line 212) 51596* const0_rtx: Constants. (line 21) 51597* CONST0_RTX: Constants. (line 230) 51598* const1_rtx: Constants. (line 21) 51599* CONST1_RTX: Constants. (line 230) 51600* const2_rtx: Constants. (line 21) 51601* CONST2_RTX: Constants. (line 230) 51602* constant attributes: Constant Attributes. 51603 (line 6) 51604* constant definitions: Constant Definitions. 51605 (line 6) 51606* constants in constraints: Simple Constraints. (line 68) 51607* CONSTANT_ADDRESS_P: Addressing Modes. (line 28) 51608* CONSTANT_P: Addressing Modes. (line 35) 51609* CONSTANT_POOL_ADDRESS_P: Flags. (line 19) 51610* CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 74) 51611* constm1_rtx: Constants. (line 21) 51612* constraint modifier characters: Modifiers. (line 6) 51613* constraint, matching: Simple Constraints. (line 140) 51614* constraints: Constraints. (line 6) 51615* constraints, defining: Define Constraints. (line 6) 51616* constraints, machine specific: Machine Constraints. 51617 (line 6) 51618* constraints, testing: C Constraint Interface. 51619 (line 6) 51620* constraint_num: C Constraint Interface. 51621 (line 30) 51622* constraint_satisfied_p: C Constraint Interface. 51623 (line 42) 51624* CONSTRUCTOR: Unary and Binary Expressions. 51625 (line 6) 51626* constructors, automatic calls: Collect2. (line 15) 51627* constructors, output of: Initialization. (line 6) 51628* CONST_DECL: Declarations. (line 6) 51629* const_double: Constants. (line 37) 51630* const_double, RTL sharing: Sharing. (line 32) 51631* CONST_DOUBLE_LOW: Constants. (line 54) 51632* const_double_operand: Machine-Independent Predicates. 51633 (line 20) 51634* const_fixed: Constants. (line 93) 51635* const_int: Constants. (line 8) 51636* const_int and attribute tests: Expressions. (line 47) 51637* const_int and attributes: Expressions. (line 10) 51638* const_int, RTL sharing: Sharing. (line 23) 51639* const_int_operand: Machine-Independent Predicates. 51640 (line 15) 51641* const_poly_int: Constants. (line 100) 51642* const_poly_int, RTL sharing: Sharing. (line 25) 51643* const_string: Constants. (line 184) 51644* const_string and attributes: Expressions. (line 20) 51645* const_true_rtx: Constants. (line 31) 51646* const_vector: Constants. (line 107) 51647* const_vector, RTL sharing: Sharing. (line 35) 51648* CONST_WIDE_INT: Constants. (line 67) 51649* CONST_WIDE_INT_ELT: Constants. (line 89) 51650* CONST_WIDE_INT_NUNITS: Constants. (line 84) 51651* CONST_WIDE_INT_VEC: Constants. (line 80) 51652* container: Containers. (line 6) 51653* CONTINUE_STMT: Statements for C++. (line 6) 51654* contributors: Contributors. (line 6) 51655* controlling register usage: Register Basics. (line 107) 51656* controlling the compilation driver: Driver. (line 6) 51657* conventions, run-time: Interface. (line 6) 51658* conversions: Conversions. (line 6) 51659* CONVERT_EXPR: Unary and Binary Expressions. 51660 (line 6) 51661* copysignM3 instruction pattern: Standard Names. (line 1078) 51662* copy_rtx: Addressing Modes. (line 189) 51663* copy_rtx_if_shared: Sharing. (line 67) 51664* cosM2 instruction pattern: Standard Names. (line 867) 51665* costs of instructions: Costs. (line 6) 51666* CPLUSPLUS_CPP_SPEC: Driver. (line 50) 51667* CPP_SPEC: Driver. (line 43) 51668* CPSImode: Machine Modes. (line 204) 51669* CP_INTEGRAL_TYPE: Types for C++. (line 55) 51670* cp_namespace_decls: Namespaces. (line 49) 51671* CP_TYPE_CONST_NON_VOLATILE_P: Types for C++. (line 33) 51672* CP_TYPE_CONST_P: Types for C++. (line 24) 51673* cp_type_quals: Types for C++. (line 6) 51674* cp_type_quals <1>: Types for C++. (line 16) 51675* CP_TYPE_RESTRICT_P: Types for C++. (line 30) 51676* CP_TYPE_VOLATILE_P: Types for C++. (line 27) 51677* CQImode: Machine Modes. (line 204) 51678* cross compilation and floating point: Floating Point. (line 6) 51679* CROSSING_JUMP_P: Flags. (line 10) 51680* crtl->args.pops_args: Function Entry. (line 111) 51681* crtl->args.pretend_args_size: Function Entry. (line 117) 51682* crtl->outgoing_args_size: Stack Arguments. (line 48) 51683* CRTSTUFF_T_CFLAGS: Target Fragment. (line 15) 51684* CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 19) 51685* CRT_CALL_STATIC_FUNCTION: Sections. (line 125) 51686* CSImode: Machine Modes. (line 204) 51687* cstoreMODE4 instruction pattern: Standard Names. (line 1557) 51688* CTImode: Machine Modes. (line 204) 51689* ctrapMM4 instruction pattern: Standard Names. (line 2023) 51690* ctz: Arithmetic. (line 230) 51691* ctzM2 instruction pattern: Standard Names. (line 1137) 51692* CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 339) 51693* CUMULATIVE_ARGS: Register Arguments. (line 144) 51694* current_function_is_leaf: Leaf Functions. (line 50) 51695* current_function_uses_only_leaf_regs: Leaf Functions. (line 50) 51696* current_insn_predicate: Conditional Execution. 51697 (line 27) 51698* C_COMMON_OVERRIDE_OPTIONS: Run-time Target. (line 136) 51699* c_register_pragma: Misc. (line 440) 51700* c_register_pragma_with_expansion: Misc. (line 442) 51701* DAmode: Machine Modes. (line 154) 51702* data bypass: Processor pipeline description. 51703 (line 105) 51704* data bypass <1>: Processor pipeline description. 51705 (line 196) 51706* data dependence delays: Processor pipeline description. 51707 (line 6) 51708* Data Dependency Analysis: Dependency analysis. 51709 (line 6) 51710* data structures: Per-Function Data. (line 6) 51711* DATA_ABI_ALIGNMENT: Storage Layout. (line 263) 51712* DATA_ALIGNMENT: Storage Layout. (line 250) 51713* DATA_SECTION_ASM_OP: Sections. (line 52) 51714* DBR_OUTPUT_SEQEND: Instruction Output. (line 133) 51715* dbr_sequence_length: Instruction Output. (line 133) 51716* DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 100) 51717* DBX_CONTIN_CHAR: DBX Options. (line 63) 51718* DBX_CONTIN_LENGTH: DBX Options. (line 53) 51719* DBX_DEBUGGING_INFO: DBX Options. (line 8) 51720* DBX_FUNCTION_FIRST: DBX Options. (line 94) 51721* DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 106) 51722* DBX_NO_XREFS: DBX Options. (line 47) 51723* DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 8) 51724* DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 33) 51725* DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX. 51726 (line 41) 51727* DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 8) 51728* DBX_REGISTER_NUMBER: All Debuggers. (line 8) 51729* DBX_REGPARM_STABS_CODE: DBX Options. (line 84) 51730* DBX_REGPARM_STABS_LETTER: DBX Options. (line 89) 51731* DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 79) 51732* DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 70) 51733* DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 75) 51734* DBX_USE_BINCL: DBX Options. (line 112) 51735* DCmode: Machine Modes. (line 199) 51736* DDmode: Machine Modes. (line 93) 51737* De Morgan's law: Insn Canonicalizations. 51738 (line 67) 51739* dead_or_set_p: define_peephole. (line 65) 51740* DEBUGGER_ARG_OFFSET: All Debuggers. (line 35) 51741* DEBUGGER_AUTO_OFFSET: All Debuggers. (line 27) 51742* debug_expr: Debug Information. (line 22) 51743* DEBUG_EXPR_DECL: Declarations. (line 6) 51744* debug_implicit_ptr: Debug Information. (line 27) 51745* debug_insn: Insns. (line 247) 51746* debug_marker: Debug Information. (line 37) 51747* debug_parameter_ref: Debug Information. (line 34) 51748* DEBUG_SYMS_TEXT: DBX Options. (line 24) 51749* decimal float library: Decimal float library routines. 51750 (line 6) 51751* declaration: Declarations. (line 6) 51752* declarations, RTL: RTL Declarations. (line 6) 51753* DECLARE_LIBRARY_RENAMES: Library Calls. (line 8) 51754* DECL_ALIGN: Declarations. (line 6) 51755* DECL_ANTICIPATED: Functions for C++. (line 42) 51756* DECL_ARGUMENTS: Function Basics. (line 36) 51757* DECL_ARRAY_DELETE_OPERATOR_P: Functions for C++. (line 158) 51758* DECL_ARTIFICIAL: Working with declarations. 51759 (line 24) 51760* DECL_ARTIFICIAL <1>: Function Basics. (line 6) 51761* DECL_ARTIFICIAL <2>: Function Properties. 51762 (line 47) 51763* DECL_ASSEMBLER_NAME: Function Basics. (line 6) 51764* DECL_ASSEMBLER_NAME <1>: Function Basics. (line 19) 51765* DECL_ATTRIBUTES: Attributes. (line 21) 51766* DECL_BASE_CONSTRUCTOR_P: Functions for C++. (line 88) 51767* DECL_COMPLETE_CONSTRUCTOR_P: Functions for C++. (line 84) 51768* DECL_COMPLETE_DESTRUCTOR_P: Functions for C++. (line 98) 51769* DECL_CONSTRUCTOR_P: Functions for C++. (line 77) 51770* DECL_CONST_MEMFUNC_P: Functions for C++. (line 71) 51771* DECL_CONTEXT: Namespaces. (line 31) 51772* DECL_CONV_FN_P: Functions for C++. (line 105) 51773* DECL_COPY_CONSTRUCTOR_P: Functions for C++. (line 92) 51774* DECL_DESTRUCTOR_P: Functions for C++. (line 95) 51775* DECL_EXTERNAL: Declarations. (line 6) 51776* DECL_EXTERNAL <1>: Function Properties. 51777 (line 25) 51778* DECL_EXTERN_C_FUNCTION_P: Functions for C++. (line 46) 51779* DECL_FUNCTION_MEMBER_P: Functions for C++. (line 61) 51780* DECL_FUNCTION_SPECIFIC_OPTIMIZATION: Function Basics. (line 6) 51781* DECL_FUNCTION_SPECIFIC_OPTIMIZATION <1>: Function Properties. 51782 (line 61) 51783* DECL_FUNCTION_SPECIFIC_TARGET: Function Basics. (line 6) 51784* DECL_FUNCTION_SPECIFIC_TARGET <1>: Function Properties. 51785 (line 55) 51786* DECL_GLOBAL_CTOR_P: Functions for C++. (line 108) 51787* DECL_GLOBAL_DTOR_P: Functions for C++. (line 112) 51788* DECL_INITIAL: Declarations. (line 6) 51789* DECL_INITIAL <1>: Function Basics. (line 51) 51790* DECL_LINKONCE_P: Functions for C++. (line 50) 51791* DECL_LOCAL_FUNCTION_P: Functions for C++. (line 38) 51792* DECL_MAIN_P: Functions for C++. (line 34) 51793* DECL_NAME: Working with declarations. 51794 (line 7) 51795* DECL_NAME <1>: Function Basics. (line 6) 51796* DECL_NAME <2>: Function Basics. (line 9) 51797* DECL_NAME <3>: Namespaces. (line 20) 51798* DECL_NAMESPACE_ALIAS: Namespaces. (line 35) 51799* DECL_NAMESPACE_STD_P: Namespaces. (line 45) 51800* DECL_NONCONVERTING_P: Functions for C++. (line 80) 51801* DECL_NONSTATIC_MEMBER_FUNCTION_P: Functions for C++. (line 68) 51802* DECL_NON_THUNK_FUNCTION_P: Functions for C++. (line 138) 51803* DECL_OVERLOADED_OPERATOR_P: Functions for C++. (line 102) 51804* DECL_PURE_P: Function Properties. 51805 (line 40) 51806* DECL_RESULT: Function Basics. (line 41) 51807* DECL_SAVED_TREE: Function Basics. (line 44) 51808* DECL_SIZE: Declarations. (line 6) 51809* DECL_STATIC_FUNCTION_P: Functions for C++. (line 65) 51810* DECL_STMT: Statements for C++. (line 6) 51811* DECL_STMT_DECL: Statements for C++. (line 6) 51812* DECL_THUNK_P: Functions for C++. (line 116) 51813* DECL_VIRTUAL_P: Function Properties. 51814 (line 44) 51815* DECL_VOLATILE_MEMFUNC_P: Functions for C++. (line 74) 51816* default: GTY Options. (line 90) 51817* default_file_start: File Framework. (line 8) 51818* DEFAULT_GDB_EXTENSIONS: DBX Options. (line 17) 51819* DEFAULT_INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 199) 51820* DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 34) 51821* DEFAULT_SIGNED_CHAR: Type Layout. (line 117) 51822* define_address_constraint: Define Constraints. (line 113) 51823* define_asm_attributes: Tagging Insns. (line 73) 51824* define_attr: Defining Attributes. 51825 (line 6) 51826* define_automaton: Processor pipeline description. 51827 (line 53) 51828* define_bypass: Processor pipeline description. 51829 (line 196) 51830* define_code_attr: Code Iterators. (line 6) 51831* define_code_iterator: Code Iterators. (line 6) 51832* define_cond_exec: Conditional Execution. 51833 (line 13) 51834* define_constants: Constant Definitions. 51835 (line 6) 51836* define_constraint: Define Constraints. (line 45) 51837* define_cpu_unit: Processor pipeline description. 51838 (line 68) 51839* define_c_enum: Constant Definitions. 51840 (line 49) 51841* define_delay: Delay Slots. (line 25) 51842* define_enum: Constant Definitions. 51843 (line 118) 51844* define_enum_attr: Defining Attributes. 51845 (line 83) 51846* define_enum_attr <1>: Constant Definitions. 51847 (line 136) 51848* define_expand: Expander Definitions. 51849 (line 11) 51850* define_insn: Patterns. (line 6) 51851* define_insn example: Example. (line 6) 51852* define_insn_and_split: Insn Splitting. (line 190) 51853* define_insn_reservation: Processor pipeline description. 51854 (line 105) 51855* define_int_attr: Int Iterators. (line 6) 51856* define_int_iterator: Int Iterators. (line 6) 51857* define_memory_constraint: Define Constraints. (line 80) 51858* define_mode_attr: Substitutions. (line 6) 51859* define_mode_iterator: Defining Mode Iterators. 51860 (line 6) 51861* define_peephole: define_peephole. (line 6) 51862* define_peephole2: define_peephole2. (line 6) 51863* define_predicate: Defining Predicates. 51864 (line 6) 51865* define_query_cpu_unit: Processor pipeline description. 51866 (line 90) 51867* define_register_constraint: Define Constraints. (line 26) 51868* define_reservation: Processor pipeline description. 51869 (line 185) 51870* define_special_memory_constraint: Define Constraints. (line 99) 51871* define_special_predicate: Defining Predicates. 51872 (line 6) 51873* define_split: Insn Splitting. (line 32) 51874* define_subst: Define Subst. (line 6) 51875* define_subst <1>: Define Subst Example. 51876 (line 6) 51877* define_subst <2>: Define Subst Pattern Matching. 51878 (line 6) 51879* define_subst <3>: Define Subst Output Template. 51880 (line 6) 51881* define_subst <4>: Define Subst. (line 14) 51882* define_subst <5>: Subst Iterators. (line 6) 51883* define_subst_attr: Subst Iterators. (line 6) 51884* define_subst_attr <1>: Subst Iterators. (line 26) 51885* defining attributes and their values: Defining Attributes. 51886 (line 6) 51887* defining constraints: Define Constraints. (line 6) 51888* defining jump instruction patterns: Jump Patterns. (line 6) 51889* defining looping instruction patterns: Looping Patterns. (line 6) 51890* defining peephole optimizers: Peephole Definitions. 51891 (line 6) 51892* defining predicates: Defining Predicates. 51893 (line 6) 51894* defining RTL sequences for code generation: Expander Definitions. 51895 (line 6) 51896* delay slots, defining: Delay Slots. (line 6) 51897* deletable: GTY Options. (line 134) 51898* DELETE_IF_ORDINARY: Filesystem. (line 79) 51899* Dependent Patterns: Dependent Patterns. (line 6) 51900* desc: GTY Options. (line 90) 51901* descriptors for nested functions: Trampolines. (line 6) 51902* destructors, output of: Initialization. (line 6) 51903* deterministic finite state automaton: Processor pipeline description. 51904 (line 6) 51905* deterministic finite state automaton <1>: Processor pipeline description. 51906 (line 304) 51907* DFmode: Machine Modes. (line 76) 51908* diagnostics guidelines, fix-it hints: Guidelines for Diagnostics. 51909 (line 320) 51910* diagnostics, actionable: Guidelines for Diagnostics. 51911 (line 15) 51912* diagnostics, false positive: Guidelines for Diagnostics. 51913 (line 39) 51914* diagnostics, guidelines for: Guidelines for Diagnostics. 51915 (line 5) 51916* diagnostics, locations: Guidelines for Diagnostics. 51917 (line 159) 51918* diagnostics, true positive: Guidelines for Diagnostics. 51919 (line 39) 51920* digits in constraint: Simple Constraints. (line 128) 51921* DImode: Machine Modes. (line 45) 51922* directory options .md: Including Patterns. (line 47) 51923* DIR_SEPARATOR: Filesystem. (line 18) 51924* DIR_SEPARATOR_2: Filesystem. (line 19) 51925* disabling certain registers: Register Basics. (line 107) 51926* dispatch table: Dispatch Tables. (line 8) 51927* div: Arithmetic. (line 116) 51928* div and attributes: Expressions. (line 83) 51929* division: Arithmetic. (line 116) 51930* division <1>: Arithmetic. (line 130) 51931* division <2>: Arithmetic. (line 136) 51932* divM3 instruction pattern: Standard Names. (line 416) 51933* divmodM4 instruction pattern: Standard Names. (line 744) 51934* dollar sign: Multi-Alternative. (line 57) 51935* DOLLARS_IN_IDENTIFIERS: Misc. (line 485) 51936* doloop_begin instruction pattern: Standard Names. (line 1777) 51937* doloop_end instruction pattern: Standard Names. (line 1765) 51938* DONE: Expander Definitions. 51939 (line 77) 51940* DONE <1>: Insn Splitting. (line 61) 51941* DONE <2>: define_peephole2. (line 76) 51942* DONT_USE_BUILTIN_SETJMP: Exception Region Output. 51943 (line 78) 51944* DOUBLE_TYPE_SIZE: Type Layout. (line 52) 51945* DO_BODY: Statements for C++. (line 6) 51946* DO_COND: Statements for C++. (line 6) 51947* DO_STMT: Statements for C++. (line 6) 51948* DQmode: Machine Modes. (line 118) 51949* driver: Driver. (line 6) 51950* DRIVER_SELF_SPECS: Driver. (line 8) 51951* dump examples: Dump examples. (line 6) 51952* dump setup: Dump setup. (line 6) 51953* dump types: Dump types. (line 6) 51954* dump verbosity: Dump output verbosity. 51955 (line 6) 51956* DUMPFILE_FORMAT: Filesystem. (line 67) 51957* dump_basic_block: Dump types. (line 29) 51958* dump_generic_expr: Dump types. (line 31) 51959* dump_gimple_stmt: Dump types. (line 33) 51960* dump_printf: Dump types. (line 6) 51961* DWARF2_ASM_LINE_DEBUG_INFO: DWARF. (line 45) 51962* DWARF2_ASM_VIEW_DEBUG_INFO: DWARF. (line 51) 51963* DWARF2_DEBUGGING_INFO: DWARF. (line 8) 51964* DWARF2_FRAME_INFO: DWARF. (line 25) 51965* DWARF2_FRAME_REG_OUT: Frame Registers. (line 149) 51966* DWARF2_UNWIND_INFO: Exception Region Output. 51967 (line 39) 51968* DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 146) 51969* DWARF_CIE_DATA_ALIGNMENT: Exception Region Output. 51970 (line 90) 51971* DWARF_FRAME_REGISTERS: Frame Registers. (line 109) 51972* DWARF_FRAME_REGNUM: Frame Registers. (line 141) 51973* DWARF_LAZY_REGISTER_VALUE: Frame Registers. (line 170) 51974* DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 134) 51975* DWARF_ZERO_REG: Frame Layout. (line 157) 51976* DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 84) 51977* E in constraint: Simple Constraints. (line 87) 51978* earlyclobber operand: Modifiers. (line 25) 51979* edge: Edges. (line 6) 51980* edge in the flow graph: Edges. (line 6) 51981* edge iterators: Edges. (line 15) 51982* edge splitting: Maintaining the CFG. 51983 (line 104) 51984* EDGE_ABNORMAL: Edges. (line 127) 51985* EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 171) 51986* EDGE_ABNORMAL, EDGE_EH: Edges. (line 95) 51987* EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 121) 51988* EDGE_FALLTHRU, force_nonfallthru: Edges. (line 85) 51989* EDOM, implicit usage: Library Calls. (line 59) 51990* EH_FRAME_SECTION_NAME: Exception Region Output. 51991 (line 9) 51992* EH_FRAME_THROUGH_COLLECT2: Exception Region Output. 51993 (line 19) 51994* eh_return instruction pattern: Standard Names. (line 1958) 51995* EH_RETURN_DATA_REGNO: Exception Handling. (line 6) 51996* EH_RETURN_HANDLER_RTX: Exception Handling. (line 38) 51997* EH_RETURN_STACKADJ_RTX: Exception Handling. (line 21) 51998* EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output. 51999 (line 29) 52000* EH_USES: Function Entry. (line 162) 52001* ei_edge: Edges. (line 43) 52002* ei_end_p: Edges. (line 27) 52003* ei_last: Edges. (line 23) 52004* ei_next: Edges. (line 35) 52005* ei_one_before_end_p: Edges. (line 31) 52006* ei_prev: Edges. (line 39) 52007* ei_safe_safe: Edges. (line 47) 52008* ei_start: Edges. (line 19) 52009* ELIMINABLE_REGS: Elimination. (line 34) 52010* ELSE_CLAUSE: Statements for C++. (line 6) 52011* Embedded C: Fixed-point fractional library routines. 52012 (line 6) 52013* Empty Statements: Empty Statements. (line 6) 52014* EMPTY_CLASS_EXPR: Statements for C++. (line 6) 52015* EMPTY_FIELD_BOUNDARY: Storage Layout. (line 341) 52016* Emulated TLS: Emulated TLS. (line 6) 52017* enabled: Disable Insn Alternatives. 52018 (line 6) 52019* ENDFILE_SPEC: Driver. (line 155) 52020* endianness: Portability. (line 20) 52021* ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 10) 52022* entry_value: Debug Information. (line 30) 52023* enum reg_class: Register Classes. (line 70) 52024* ENUMERAL_TYPE: Types. (line 6) 52025* enumerations: Constant Definitions. 52026 (line 49) 52027* epilogue: Function Entry. (line 6) 52028* epilogue instruction pattern: Standard Names. (line 1996) 52029* EPILOGUE_USES: Function Entry. (line 156) 52030* eq: Comparisons. (line 52) 52031* eq and attributes: Expressions. (line 83) 52032* equal: Comparisons. (line 52) 52033* eq_attr: Expressions. (line 104) 52034* EQ_EXPR: Unary and Binary Expressions. 52035 (line 6) 52036* errno, implicit usage: Library Calls. (line 71) 52037* EXACT_DIV_EXPR: Unary and Binary Expressions. 52038 (line 6) 52039* examining SSA_NAMEs: SSA. (line 182) 52040* exception handling: Edges. (line 95) 52041* exception handling <1>: Exception Handling. (line 6) 52042* exception_receiver instruction pattern: Standard Names. (line 1923) 52043* exclamation point: Multi-Alternative. (line 48) 52044* exclusion_set: Processor pipeline description. 52045 (line 223) 52046* exclusive-or, bitwise: Arithmetic. (line 168) 52047* EXIT_EXPR: Unary and Binary Expressions. 52048 (line 6) 52049* EXIT_IGNORE_STACK: Function Entry. (line 144) 52050* exp10M2 instruction pattern: Standard Names. (line 931) 52051* exp2M2 instruction pattern: Standard Names. (line 938) 52052* expander definitions: Expander Definitions. 52053 (line 6) 52054* expm1M2 instruction pattern: Standard Names. (line 921) 52055* expM2 instruction pattern: Standard Names. (line 914) 52056* expression: Expression trees. (line 6) 52057* expression codes: RTL Objects. (line 47) 52058* EXPR_FILENAME: Working with declarations. 52059 (line 14) 52060* EXPR_LINENO: Working with declarations. 52061 (line 20) 52062* expr_list: Insns. (line 568) 52063* EXPR_STMT: Statements for C++. (line 6) 52064* EXPR_STMT_EXPR: Statements for C++. (line 6) 52065* extendMN2 instruction pattern: Standard Names. (line 1345) 52066* extensible constraints: Simple Constraints. (line 171) 52067* extract_last_M instruction pattern: Standard Names. (line 517) 52068* EXTRA_SPECS: Driver. (line 182) 52069* extv instruction pattern: Standard Names. (line 1436) 52070* extvM instruction pattern: Standard Names. (line 1381) 52071* extvmisalignM instruction pattern: Standard Names. (line 1391) 52072* extzv instruction pattern: Standard Names. (line 1454) 52073* extzvM instruction pattern: Standard Names. (line 1405) 52074* extzvmisalignM instruction pattern: Standard Names. (line 1408) 52075* F in constraint: Simple Constraints. (line 92) 52076* FAIL: Expander Definitions. 52077 (line 83) 52078* FAIL <1>: Insn Splitting. (line 68) 52079* FAIL <2>: define_peephole2. (line 83) 52080* fall-thru: Edges. (line 68) 52081* false positive: Guidelines for Diagnostics. 52082 (line 39) 52083* FATAL_EXIT_CODE: Host Misc. (line 6) 52084* FDL, GNU Free Documentation License: GNU Free Documentation License. 52085 (line 6) 52086* features, optional, in system conventions: Run-time Target. 52087 (line 59) 52088* ffs: Arithmetic. (line 210) 52089* ffsM2 instruction pattern: Standard Names. (line 1093) 52090* FIELD_DECL: Declarations. (line 6) 52091* files and passes of the compiler: Passes. (line 6) 52092* files, generated: Files. (line 6) 52093* file_end_indicate_exec_stack: File Framework. (line 39) 52094* final_absence_set: Processor pipeline description. 52095 (line 223) 52096* FINAL_PRESCAN_INSN: Instruction Output. (line 60) 52097* final_presence_set: Processor pipeline description. 52098 (line 223) 52099* final_sequence: Instruction Output. (line 144) 52100* FIND_BASE_TERM: Addressing Modes. (line 117) 52101* finite state automaton minimization: Processor pipeline description. 52102 (line 304) 52103* FINI_ARRAY_SECTION_ASM_OP: Sections. (line 113) 52104* FINI_SECTION_ASM_OP: Sections. (line 98) 52105* FIRST_PARM_OFFSET: Frame Layout. (line 59) 52106* FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65) 52107* FIRST_PSEUDO_REGISTER: Register Basics. (line 8) 52108* FIRST_STACK_REG: Stack Registers. (line 26) 52109* FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 52110* fix: Conversions. (line 66) 52111* fix-it hints: Guidelines for Diagnostics. 52112 (line 320) 52113* fixed register: Register Basics. (line 15) 52114* fixed-point fractional library: Fixed-point fractional library routines. 52115 (line 6) 52116* FIXED_CONVERT_EXPR: Unary and Binary Expressions. 52117 (line 6) 52118* FIXED_CST: Constant expressions. 52119 (line 6) 52120* FIXED_POINT_TYPE: Types. (line 6) 52121* FIXED_REGISTERS: Register Basics. (line 14) 52122* fixed_regs: Register Basics. (line 93) 52123* fixed_size_mode: Machine Modes. (line 305) 52124* fixMN2 instruction pattern: Standard Names. (line 1312) 52125* fixunsMN2 instruction pattern: Standard Names. (line 1321) 52126* fixuns_truncMN2 instruction pattern: Standard Names. (line 1336) 52127* fix_truncMN2 instruction pattern: Standard Names. (line 1332) 52128* FIX_TRUNC_EXPR: Unary and Binary Expressions. 52129 (line 6) 52130* flags in RTL expression: Flags. (line 6) 52131* float: Conversions. (line 58) 52132* floating point and cross compilation: Floating Point. (line 6) 52133* floatMN2 instruction pattern: Standard Names. (line 1304) 52134* floatunsMN2 instruction pattern: Standard Names. (line 1308) 52135* FLOAT_EXPR: Unary and Binary Expressions. 52136 (line 6) 52137* float_extend: Conversions. (line 33) 52138* FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 32) 52139* FLOAT_STORE_FLAG_VALUE: Misc. (line 320) 52140* float_truncate: Conversions. (line 53) 52141* FLOAT_TYPE_SIZE: Type Layout. (line 48) 52142* FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 41) 52143* FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory. 52144 (line 234) 52145* floorM2 instruction pattern: Standard Names. (line 1005) 52146* FLOOR_DIV_EXPR: Unary and Binary Expressions. 52147 (line 6) 52148* FLOOR_MOD_EXPR: Unary and Binary Expressions. 52149 (line 6) 52150* flow-insensitive alias analysis: Alias analysis. (line 6) 52151* flow-sensitive alias analysis: Alias analysis. (line 6) 52152* fma: Arithmetic. (line 112) 52153* fmaM4 instruction pattern: Standard Names. (line 452) 52154* fmaxM3 instruction pattern: Standard Names. (line 483) 52155* fminM3 instruction pattern: Standard Names. (line 483) 52156* fmodM3 instruction pattern: Standard Names. (line 837) 52157* fmsM4 instruction pattern: Standard Names. (line 459) 52158* fnmaM4 instruction pattern: Standard Names. (line 465) 52159* fnmsM4 instruction pattern: Standard Names. (line 471) 52160* fold_extract_last_M instruction pattern: Standard Names. (line 524) 52161* fold_left_plus_M instruction pattern: Standard Names. (line 532) 52162* FORCE_CODE_SECTION_ALIGN: Sections. (line 149) 52163* force_reg: Standard Names. (line 36) 52164* FOR_BODY: Statements for C++. (line 6) 52165* FOR_COND: Statements for C++. (line 6) 52166* FOR_EXPR: Statements for C++. (line 6) 52167* FOR_INIT_STMT: Statements for C++. (line 6) 52168* FOR_STMT: Statements for C++. (line 6) 52169* for_user: GTY Options. (line 82) 52170* fractional types: Fixed-point fractional library routines. 52171 (line 6) 52172* fractMN2 instruction pattern: Standard Names. (line 1354) 52173* fractunsMN2 instruction pattern: Standard Names. (line 1369) 52174* fract_convert: Conversions. (line 82) 52175* FRACT_TYPE_SIZE: Type Layout. (line 67) 52176* frame layout: Frame Layout. (line 6) 52177* FRAME_ADDR_RTX: Frame Layout. (line 108) 52178* FRAME_GROWS_DOWNWARD: Frame Layout. (line 26) 52179* FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory. 52180 (line 69) 52181* FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 225) 52182* frame_pointer_needed: Function Entry. (line 42) 52183* FRAME_POINTER_REGNUM: Frame Registers. (line 13) 52184* FRAME_POINTER_REGNUM and virtual registers: Regs and Memory. 52185 (line 74) 52186* frame_pointer_rtx: Frame Registers. (line 104) 52187* frame_related: Flags. (line 238) 52188* frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags. 52189 (line 135) 52190* frame_related, in mem: Flags. (line 74) 52191* frame_related, in reg: Flags. (line 102) 52192* frame_related, in symbol_ref: Flags. (line 179) 52193* frequency, count, BB_FREQ_BASE: Profile information. 52194 (line 30) 52195* ftruncM2 instruction pattern: Standard Names. (line 1327) 52196* function: Functions. (line 6) 52197* function <1>: Functions for C++. (line 6) 52198* function call conventions: Interface. (line 6) 52199* function entry and exit: Function Entry. (line 6) 52200* function entry point, alternate function entry point: Edges. 52201 (line 180) 52202* function properties: Function Properties. 52203 (line 6) 52204* function-call insns: Calls. (line 6) 52205* functions, leaf: Leaf Functions. (line 6) 52206* FUNCTION_ARG_REGNO_P: Register Arguments. (line 269) 52207* FUNCTION_BOUNDARY: Storage Layout. (line 176) 52208* FUNCTION_DECL: Functions. (line 6) 52209* FUNCTION_DECL <1>: Functions for C++. (line 6) 52210* FUNCTION_MODE: Misc. (line 375) 52211* FUNCTION_PROFILER: Profiling. (line 8) 52212* FUNCTION_TYPE: Types. (line 6) 52213* FUNCTION_VALUE: Scalar Return. (line 52) 52214* FUNCTION_VALUE_REGNO_P: Scalar Return. (line 78) 52215* fundamental type: Types. (line 6) 52216* G in constraint: Simple Constraints. (line 96) 52217* g in constraint: Simple Constraints. (line 118) 52218* garbage collector, invocation: Invoking the garbage collector. 52219 (line 6) 52220* garbage collector, troubleshooting: Troubleshooting. (line 6) 52221* gather_loadM instruction pattern: Standard Names. (line 232) 52222* GCC and portability: Portability. (line 6) 52223* GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36) 52224* gcov_type: Profile information. 52225 (line 41) 52226* ge: Comparisons. (line 72) 52227* ge and attributes: Expressions. (line 83) 52228* gencodes: RTL passes. (line 18) 52229* general_operand: Machine-Independent Predicates. 52230 (line 104) 52231* GENERAL_REGS: Register Classes. (line 22) 52232* generated files: Files. (line 6) 52233* generating assembler output: Output Statement. (line 6) 52234* generating insns: RTL Template. (line 6) 52235* GENERIC: Parsing pass. (line 6) 52236* GENERIC <1>: GENERIC. (line 6) 52237* generic predicates: Machine-Independent Predicates. 52238 (line 6) 52239* genflags: RTL passes. (line 18) 52240* GEN_ERRNO_RTX: Library Calls. (line 71) 52241* get_attr: Expressions. (line 99) 52242* get_attr_length: Insn Lengths. (line 52) 52243* GET_CLASS_NARROWEST_MODE: Machine Modes. (line 430) 52244* GET_CODE: RTL Objects. (line 47) 52245* get_insns: Insns. (line 34) 52246* get_last_insn: Insns. (line 34) 52247* GET_MODE: Machine Modes. (line 377) 52248* GET_MODE_ALIGNMENT: Machine Modes. (line 417) 52249* GET_MODE_BITSIZE: Machine Modes. (line 401) 52250* GET_MODE_CLASS: Machine Modes. (line 391) 52251* GET_MODE_FBIT: Machine Modes. (line 408) 52252* GET_MODE_IBIT: Machine Modes. (line 404) 52253* GET_MODE_MASK: Machine Modes. (line 412) 52254* GET_MODE_NAME: Machine Modes. (line 388) 52255* GET_MODE_NUNITS: Machine Modes. (line 426) 52256* GET_MODE_SIZE: Machine Modes. (line 398) 52257* GET_MODE_UNIT_SIZE: Machine Modes. (line 420) 52258* GET_MODE_WIDER_MODE: Machine Modes. (line 394) 52259* GET_RTX_CLASS: RTL Classes. (line 6) 52260* GET_RTX_FORMAT: RTL Classes. (line 136) 52261* GET_RTX_LENGTH: RTL Classes. (line 133) 52262* get_thread_pointerMODE instruction pattern: Standard Names. 52263 (line 2375) 52264* geu: Comparisons. (line 72) 52265* geu and attributes: Expressions. (line 83) 52266* GE_EXPR: Unary and Binary Expressions. 52267 (line 6) 52268* GGC: Type Information. (line 6) 52269* ggc_collect: Invoking the garbage collector. 52270 (line 6) 52271* GIMPLE: Parsing pass. (line 13) 52272* GIMPLE <1>: Gimplification pass. 52273 (line 6) 52274* GIMPLE <2>: GIMPLE. (line 6) 52275* gimple: Tuple representation. 52276 (line 14) 52277* GIMPLE API: GIMPLE API. (line 6) 52278* GIMPLE class hierarchy: Class hierarchy of GIMPLE statements. 52279 (line 6) 52280* GIMPLE Exception Handling: GIMPLE Exception Handling. 52281 (line 6) 52282* GIMPLE instruction set: GIMPLE instruction set. 52283 (line 6) 52284* GIMPLE sequences: GIMPLE sequences. (line 6) 52285* GIMPLE statement iterators: Basic Blocks. (line 78) 52286* GIMPLE statement iterators <1>: Maintaining the CFG. 52287 (line 33) 52288* gimple_addresses_taken: Manipulating GIMPLE statements. 52289 (line 89) 52290* GIMPLE_ASM: GIMPLE_ASM. (line 6) 52291* gimple_asm_clobber_op: GIMPLE_ASM. (line 39) 52292* gimple_asm_input_op: GIMPLE_ASM. (line 23) 52293* gimple_asm_nclobbers: GIMPLE_ASM. (line 20) 52294* gimple_asm_ninputs: GIMPLE_ASM. (line 14) 52295* gimple_asm_noutputs: GIMPLE_ASM. (line 17) 52296* gimple_asm_output_op: GIMPLE_ASM. (line 31) 52297* gimple_asm_set_clobber_op: GIMPLE_ASM. (line 43) 52298* gimple_asm_set_input_op: GIMPLE_ASM. (line 27) 52299* gimple_asm_set_output_op: GIMPLE_ASM. (line 35) 52300* gimple_asm_set_volatile: GIMPLE_ASM. (line 54) 52301* gimple_asm_string: GIMPLE_ASM. (line 47) 52302* gimple_asm_volatile_p: GIMPLE_ASM. (line 51) 52303* GIMPLE_ASSIGN: GIMPLE_ASSIGN. (line 6) 52304* gimple_assign_cast_p: Logical Operators. (line 158) 52305* gimple_assign_cast_p <1>: GIMPLE_ASSIGN. (line 104) 52306* gimple_assign_lhs: GIMPLE_ASSIGN. (line 62) 52307* gimple_assign_lhs_ptr: GIMPLE_ASSIGN. (line 65) 52308* gimple_assign_rhs1: GIMPLE_ASSIGN. (line 68) 52309* gimple_assign_rhs1_ptr: GIMPLE_ASSIGN. (line 71) 52310* gimple_assign_rhs2: GIMPLE_ASSIGN. (line 75) 52311* gimple_assign_rhs2_ptr: GIMPLE_ASSIGN. (line 78) 52312* gimple_assign_rhs3: GIMPLE_ASSIGN. (line 82) 52313* gimple_assign_rhs3_ptr: GIMPLE_ASSIGN. (line 85) 52314* gimple_assign_rhs_class: GIMPLE_ASSIGN. (line 56) 52315* gimple_assign_rhs_code: GIMPLE_ASSIGN. (line 52) 52316* gimple_assign_set_lhs: GIMPLE_ASSIGN. (line 89) 52317* gimple_assign_set_rhs1: GIMPLE_ASSIGN. (line 92) 52318* gimple_assign_set_rhs2: GIMPLE_ASSIGN. (line 96) 52319* gimple_assign_set_rhs3: GIMPLE_ASSIGN. (line 100) 52320* gimple_bb: Manipulating GIMPLE statements. 52321 (line 17) 52322* GIMPLE_BIND: GIMPLE_BIND. (line 6) 52323* gimple_bind_add_seq: GIMPLE_BIND. (line 34) 52324* gimple_bind_add_stmt: GIMPLE_BIND. (line 31) 52325* gimple_bind_append_vars: GIMPLE_BIND. (line 18) 52326* gimple_bind_block: GIMPLE_BIND. (line 39) 52327* gimple_bind_body: GIMPLE_BIND. (line 22) 52328* gimple_bind_set_block: GIMPLE_BIND. (line 44) 52329* gimple_bind_set_body: GIMPLE_BIND. (line 26) 52330* gimple_bind_set_vars: GIMPLE_BIND. (line 14) 52331* gimple_bind_vars: GIMPLE_BIND. (line 11) 52332* gimple_block: Manipulating GIMPLE statements. 52333 (line 20) 52334* gimple_build: GIMPLE API. (line 34) 52335* gimple_build <1>: GIMPLE API. (line 36) 52336* gimple_build <2>: GIMPLE API. (line 38) 52337* gimple_build <3>: GIMPLE API. (line 41) 52338* gimple_build <4>: GIMPLE API. (line 44) 52339* gimple_build <5>: GIMPLE API. (line 47) 52340* gimple_build_debug_begin_stmt: GIMPLE_DEBUG. (line 72) 52341* gimple_build_debug_inline_entry: GIMPLE_DEBUG. (line 82) 52342* gimple_build_nop: GIMPLE_NOP. (line 6) 52343* gimple_build_omp_master: GIMPLE_OMP_MASTER. (line 6) 52344* gimple_build_omp_ordered: GIMPLE_OMP_ORDERED. (line 6) 52345* gimple_build_omp_return: GIMPLE_OMP_RETURN. (line 6) 52346* gimple_build_omp_section: GIMPLE_OMP_SECTION. (line 6) 52347* gimple_build_omp_sections_switch: GIMPLE_OMP_SECTIONS. 52348 (line 13) 52349* gimple_build_wce: GIMPLE_WITH_CLEANUP_EXPR. 52350 (line 6) 52351* GIMPLE_CALL: GIMPLE_CALL. (line 6) 52352* gimple_call_arg: GIMPLE_CALL. (line 67) 52353* gimple_call_arg_ptr: GIMPLE_CALL. (line 71) 52354* gimple_call_chain: GIMPLE_CALL. (line 58) 52355* gimple_call_copy_skip_args: GIMPLE_CALL. (line 92) 52356* gimple_call_fn: GIMPLE_CALL. (line 39) 52357* gimple_call_fndecl: GIMPLE_CALL. (line 47) 52358* gimple_call_lhs: GIMPLE_CALL. (line 30) 52359* gimple_call_lhs_ptr: GIMPLE_CALL. (line 33) 52360* gimple_call_noreturn_p: GIMPLE_CALL. (line 89) 52361* gimple_call_num_args: GIMPLE_CALL. (line 64) 52362* gimple_call_return_type: GIMPLE_CALL. (line 55) 52363* gimple_call_set_arg: GIMPLE_CALL. (line 76) 52364* gimple_call_set_chain: GIMPLE_CALL. (line 61) 52365* gimple_call_set_fn: GIMPLE_CALL. (line 43) 52366* gimple_call_set_fndecl: GIMPLE_CALL. (line 52) 52367* gimple_call_set_lhs: GIMPLE_CALL. (line 36) 52368* gimple_call_set_tail: GIMPLE_CALL. (line 81) 52369* gimple_call_tail_p: GIMPLE_CALL. (line 86) 52370* GIMPLE_CATCH: GIMPLE_CATCH. (line 6) 52371* gimple_catch_handler: GIMPLE_CATCH. (line 19) 52372* gimple_catch_set_handler: GIMPLE_CATCH. (line 26) 52373* gimple_catch_set_types: GIMPLE_CATCH. (line 23) 52374* gimple_catch_types: GIMPLE_CATCH. (line 12) 52375* gimple_catch_types_ptr: GIMPLE_CATCH. (line 15) 52376* gimple_code: Manipulating GIMPLE statements. 52377 (line 14) 52378* GIMPLE_COND: GIMPLE_COND. (line 6) 52379* gimple_cond_code: GIMPLE_COND. (line 20) 52380* gimple_cond_false_label: GIMPLE_COND. (line 59) 52381* gimple_cond_lhs: GIMPLE_COND. (line 29) 52382* gimple_cond_make_false: GIMPLE_COND. (line 63) 52383* gimple_cond_make_true: GIMPLE_COND. (line 66) 52384* gimple_cond_rhs: GIMPLE_COND. (line 37) 52385* gimple_cond_set_code: GIMPLE_COND. (line 24) 52386* gimple_cond_set_false_label: GIMPLE_COND. (line 54) 52387* gimple_cond_set_lhs: GIMPLE_COND. (line 33) 52388* gimple_cond_set_rhs: GIMPLE_COND. (line 41) 52389* gimple_cond_set_true_label: GIMPLE_COND. (line 49) 52390* gimple_cond_true_label: GIMPLE_COND. (line 45) 52391* gimple_convert: GIMPLE API. (line 50) 52392* gimple_copy: Manipulating GIMPLE statements. 52393 (line 146) 52394* GIMPLE_DEBUG: GIMPLE_DEBUG. (line 6) 52395* GIMPLE_DEBUG_BEGIN_STMT: GIMPLE_DEBUG. (line 6) 52396* GIMPLE_DEBUG_BIND: GIMPLE_DEBUG. (line 6) 52397* gimple_debug_bind_get_value: GIMPLE_DEBUG. (line 46) 52398* gimple_debug_bind_get_value_ptr: GIMPLE_DEBUG. (line 50) 52399* gimple_debug_bind_get_var: GIMPLE_DEBUG. (line 43) 52400* gimple_debug_bind_has_value_p: GIMPLE_DEBUG. (line 68) 52401* gimple_debug_bind_p: Logical Operators. (line 162) 52402* gimple_debug_bind_reset_value: GIMPLE_DEBUG. (line 64) 52403* gimple_debug_bind_set_value: GIMPLE_DEBUG. (line 59) 52404* gimple_debug_bind_set_var: GIMPLE_DEBUG. (line 55) 52405* GIMPLE_DEBUG_INLINE_ENTRY: GIMPLE_DEBUG. (line 6) 52406* gimple_def_ops: Manipulating GIMPLE statements. 52407 (line 93) 52408* GIMPLE_EH_FILTER: GIMPLE_EH_FILTER. (line 6) 52409* gimple_eh_filter_failure: GIMPLE_EH_FILTER. (line 18) 52410* gimple_eh_filter_set_failure: GIMPLE_EH_FILTER. (line 27) 52411* gimple_eh_filter_set_types: GIMPLE_EH_FILTER. (line 22) 52412* gimple_eh_filter_types: GIMPLE_EH_FILTER. (line 11) 52413* gimple_eh_filter_types_ptr: GIMPLE_EH_FILTER. (line 14) 52414* gimple_eh_must_not_throw_fndecl: GIMPLE_EH_FILTER. (line 32) 52415* gimple_eh_must_not_throw_set_fndecl: GIMPLE_EH_FILTER. (line 36) 52416* gimple_expr_code: Manipulating GIMPLE statements. 52417 (line 30) 52418* gimple_expr_type: Manipulating GIMPLE statements. 52419 (line 23) 52420* GIMPLE_GOTO: GIMPLE_GOTO. (line 6) 52421* gimple_goto_dest: GIMPLE_GOTO. (line 9) 52422* gimple_goto_set_dest: GIMPLE_GOTO. (line 12) 52423* gimple_has_mem_ops: Manipulating GIMPLE statements. 52424 (line 71) 52425* gimple_has_ops: Manipulating GIMPLE statements. 52426 (line 68) 52427* gimple_has_volatile_ops: Manipulating GIMPLE statements. 52428 (line 133) 52429* GIMPLE_LABEL: GIMPLE_LABEL. (line 6) 52430* gimple_label_label: GIMPLE_LABEL. (line 10) 52431* gimple_label_set_label: GIMPLE_LABEL. (line 13) 52432* gimple_loaded_syms: Manipulating GIMPLE statements. 52433 (line 121) 52434* gimple_locus: Manipulating GIMPLE statements. 52435 (line 41) 52436* gimple_locus_empty_p: Manipulating GIMPLE statements. 52437 (line 47) 52438* gimple_modified_p: Manipulating GIMPLE statements. 52439 (line 129) 52440* GIMPLE_NOP: GIMPLE_NOP. (line 6) 52441* gimple_nop_p: GIMPLE_NOP. (line 9) 52442* gimple_no_warning_p: Manipulating GIMPLE statements. 52443 (line 50) 52444* gimple_num_ops: Logical Operators. (line 76) 52445* gimple_num_ops <1>: Manipulating GIMPLE statements. 52446 (line 74) 52447* GIMPLE_OMP_ATOMIC_LOAD: GIMPLE_OMP_ATOMIC_LOAD. 52448 (line 6) 52449* gimple_omp_atomic_load_lhs: GIMPLE_OMP_ATOMIC_LOAD. 52450 (line 16) 52451* gimple_omp_atomic_load_rhs: GIMPLE_OMP_ATOMIC_LOAD. 52452 (line 24) 52453* gimple_omp_atomic_load_set_lhs: GIMPLE_OMP_ATOMIC_LOAD. 52454 (line 12) 52455* gimple_omp_atomic_load_set_rhs: GIMPLE_OMP_ATOMIC_LOAD. 52456 (line 20) 52457* GIMPLE_OMP_ATOMIC_STORE: GIMPLE_OMP_ATOMIC_STORE. 52458 (line 6) 52459* gimple_omp_atomic_store_set_val: GIMPLE_OMP_ATOMIC_STORE. 52460 (line 11) 52461* gimple_omp_atomic_store_val: GIMPLE_OMP_ATOMIC_STORE. 52462 (line 15) 52463* gimple_omp_body: GIMPLE_OMP_PARALLEL. 52464 (line 23) 52465* GIMPLE_OMP_CONTINUE: GIMPLE_OMP_CONTINUE. 52466 (line 6) 52467* gimple_omp_continue_control_def: GIMPLE_OMP_CONTINUE. 52468 (line 12) 52469* gimple_omp_continue_control_def_ptr: GIMPLE_OMP_CONTINUE. 52470 (line 17) 52471* gimple_omp_continue_control_use: GIMPLE_OMP_CONTINUE. 52472 (line 26) 52473* gimple_omp_continue_control_use_ptr: GIMPLE_OMP_CONTINUE. 52474 (line 31) 52475* gimple_omp_continue_set_control_def: GIMPLE_OMP_CONTINUE. 52476 (line 21) 52477* gimple_omp_continue_set_control_use: GIMPLE_OMP_CONTINUE. 52478 (line 35) 52479* GIMPLE_OMP_CRITICAL: GIMPLE_OMP_CRITICAL. 52480 (line 6) 52481* gimple_omp_critical_name: GIMPLE_OMP_CRITICAL. 52482 (line 12) 52483* gimple_omp_critical_name_ptr: GIMPLE_OMP_CRITICAL. 52484 (line 16) 52485* gimple_omp_critical_set_name: GIMPLE_OMP_CRITICAL. 52486 (line 21) 52487* GIMPLE_OMP_FOR: GIMPLE_OMP_FOR. (line 6) 52488* gimple_omp_for_clauses: GIMPLE_OMP_FOR. (line 17) 52489* gimple_omp_for_clauses_ptr: GIMPLE_OMP_FOR. (line 20) 52490* gimple_omp_for_cond: GIMPLE_OMP_FOR. (line 80) 52491* gimple_omp_for_final: GIMPLE_OMP_FOR. (line 48) 52492* gimple_omp_for_final_ptr: GIMPLE_OMP_FOR. (line 51) 52493* gimple_omp_for_incr: GIMPLE_OMP_FOR. (line 58) 52494* gimple_omp_for_incr_ptr: GIMPLE_OMP_FOR. (line 61) 52495* gimple_omp_for_index: GIMPLE_OMP_FOR. (line 28) 52496* gimple_omp_for_index_ptr: GIMPLE_OMP_FOR. (line 31) 52497* gimple_omp_for_initial: GIMPLE_OMP_FOR. (line 38) 52498* gimple_omp_for_initial_ptr: GIMPLE_OMP_FOR. (line 41) 52499* gimple_omp_for_pre_body: GIMPLE_OMP_FOR. (line 67) 52500* gimple_omp_for_set_clauses: GIMPLE_OMP_FOR. (line 23) 52501* gimple_omp_for_set_cond: GIMPLE_OMP_FOR. (line 76) 52502* gimple_omp_for_set_final: GIMPLE_OMP_FOR. (line 54) 52503* gimple_omp_for_set_incr: GIMPLE_OMP_FOR. (line 64) 52504* gimple_omp_for_set_index: GIMPLE_OMP_FOR. (line 34) 52505* gimple_omp_for_set_initial: GIMPLE_OMP_FOR. (line 44) 52506* gimple_omp_for_set_pre_body: GIMPLE_OMP_FOR. (line 71) 52507* GIMPLE_OMP_MASTER: GIMPLE_OMP_MASTER. (line 6) 52508* GIMPLE_OMP_ORDERED: GIMPLE_OMP_ORDERED. (line 6) 52509* GIMPLE_OMP_PARALLEL: GIMPLE_OMP_PARALLEL. 52510 (line 6) 52511* gimple_omp_parallel_child_fn: GIMPLE_OMP_PARALLEL. 52512 (line 42) 52513* gimple_omp_parallel_child_fn_ptr: GIMPLE_OMP_PARALLEL. 52514 (line 47) 52515* gimple_omp_parallel_clauses: GIMPLE_OMP_PARALLEL. 52516 (line 30) 52517* gimple_omp_parallel_clauses_ptr: GIMPLE_OMP_PARALLEL. 52518 (line 33) 52519* gimple_omp_parallel_combined_p: GIMPLE_OMP_PARALLEL. 52520 (line 15) 52521* gimple_omp_parallel_data_arg: GIMPLE_OMP_PARALLEL. 52522 (line 56) 52523* gimple_omp_parallel_data_arg_ptr: GIMPLE_OMP_PARALLEL. 52524 (line 61) 52525* gimple_omp_parallel_set_child_fn: GIMPLE_OMP_PARALLEL. 52526 (line 52) 52527* gimple_omp_parallel_set_clauses: GIMPLE_OMP_PARALLEL. 52528 (line 37) 52529* gimple_omp_parallel_set_combined_p: GIMPLE_OMP_PARALLEL. 52530 (line 19) 52531* gimple_omp_parallel_set_data_arg: GIMPLE_OMP_PARALLEL. 52532 (line 65) 52533* GIMPLE_OMP_RETURN: GIMPLE_OMP_RETURN. (line 6) 52534* gimple_omp_return_nowait_p: GIMPLE_OMP_RETURN. (line 13) 52535* gimple_omp_return_set_nowait: GIMPLE_OMP_RETURN. (line 10) 52536* GIMPLE_OMP_SECTION: GIMPLE_OMP_SECTION. (line 6) 52537* GIMPLE_OMP_SECTIONS: GIMPLE_OMP_SECTIONS. 52538 (line 6) 52539* gimple_omp_sections_clauses: GIMPLE_OMP_SECTIONS. 52540 (line 29) 52541* gimple_omp_sections_clauses_ptr: GIMPLE_OMP_SECTIONS. 52542 (line 32) 52543* gimple_omp_sections_control: GIMPLE_OMP_SECTIONS. 52544 (line 16) 52545* gimple_omp_sections_control_ptr: GIMPLE_OMP_SECTIONS. 52546 (line 20) 52547* gimple_omp_sections_set_clauses: GIMPLE_OMP_SECTIONS. 52548 (line 35) 52549* gimple_omp_sections_set_control: GIMPLE_OMP_SECTIONS. 52550 (line 24) 52551* gimple_omp_section_last_p: GIMPLE_OMP_SECTION. (line 11) 52552* gimple_omp_section_set_last: GIMPLE_OMP_SECTION. (line 15) 52553* gimple_omp_set_body: GIMPLE_OMP_PARALLEL. 52554 (line 26) 52555* GIMPLE_OMP_SINGLE: GIMPLE_OMP_SINGLE. (line 6) 52556* gimple_omp_single_clauses: GIMPLE_OMP_SINGLE. (line 13) 52557* gimple_omp_single_clauses_ptr: GIMPLE_OMP_SINGLE. (line 16) 52558* gimple_omp_single_set_clauses: GIMPLE_OMP_SINGLE. (line 19) 52559* gimple_op: Logical Operators. (line 79) 52560* gimple_op <1>: Manipulating GIMPLE statements. 52561 (line 80) 52562* gimple_ops: Logical Operators. (line 82) 52563* gimple_ops <1>: Manipulating GIMPLE statements. 52564 (line 77) 52565* gimple_op_ptr: Manipulating GIMPLE statements. 52566 (line 83) 52567* GIMPLE_PHI: GIMPLE_PHI. (line 6) 52568* gimple_phi_arg: GIMPLE_PHI. (line 24) 52569* gimple_phi_arg <1>: SSA. (line 62) 52570* gimple_phi_arg_def: SSA. (line 68) 52571* gimple_phi_arg_edge: SSA. (line 65) 52572* gimple_phi_capacity: GIMPLE_PHI. (line 6) 52573* gimple_phi_num_args: GIMPLE_PHI. (line 10) 52574* gimple_phi_num_args <1>: SSA. (line 58) 52575* gimple_phi_result: GIMPLE_PHI. (line 15) 52576* gimple_phi_result <1>: SSA. (line 55) 52577* gimple_phi_result_ptr: GIMPLE_PHI. (line 18) 52578* gimple_phi_set_arg: GIMPLE_PHI. (line 28) 52579* gimple_phi_set_result: GIMPLE_PHI. (line 21) 52580* gimple_plf: Manipulating GIMPLE statements. 52581 (line 64) 52582* GIMPLE_RESX: GIMPLE_RESX. (line 6) 52583* gimple_resx_region: GIMPLE_RESX. (line 12) 52584* gimple_resx_set_region: GIMPLE_RESX. (line 15) 52585* GIMPLE_RETURN: GIMPLE_RETURN. (line 6) 52586* gimple_return_retval: GIMPLE_RETURN. (line 9) 52587* gimple_return_set_retval: GIMPLE_RETURN. (line 12) 52588* gimple_seq_add_seq: GIMPLE sequences. (line 30) 52589* gimple_seq_add_stmt: GIMPLE sequences. (line 24) 52590* gimple_seq_alloc: GIMPLE sequences. (line 61) 52591* gimple_seq_copy: GIMPLE sequences. (line 65) 52592* gimple_seq_deep_copy: GIMPLE sequences. (line 36) 52593* gimple_seq_empty_p: GIMPLE sequences. (line 69) 52594* gimple_seq_first: GIMPLE sequences. (line 43) 52595* gimple_seq_init: GIMPLE sequences. (line 58) 52596* gimple_seq_last: GIMPLE sequences. (line 46) 52597* gimple_seq_reverse: GIMPLE sequences. (line 39) 52598* gimple_seq_set_first: GIMPLE sequences. (line 53) 52599* gimple_seq_set_last: GIMPLE sequences. (line 49) 52600* gimple_seq_singleton_p: GIMPLE sequences. (line 78) 52601* gimple_set_block: Manipulating GIMPLE statements. 52602 (line 38) 52603* gimple_set_def_ops: Manipulating GIMPLE statements. 52604 (line 96) 52605* gimple_set_has_volatile_ops: Manipulating GIMPLE statements. 52606 (line 136) 52607* gimple_set_locus: Manipulating GIMPLE statements. 52608 (line 44) 52609* gimple_set_op: Manipulating GIMPLE statements. 52610 (line 86) 52611* gimple_set_plf: Manipulating GIMPLE statements. 52612 (line 60) 52613* gimple_set_use_ops: Manipulating GIMPLE statements. 52614 (line 103) 52615* gimple_set_vdef_ops: Manipulating GIMPLE statements. 52616 (line 117) 52617* gimple_set_visited: Manipulating GIMPLE statements. 52618 (line 53) 52619* gimple_set_vuse_ops: Manipulating GIMPLE statements. 52620 (line 110) 52621* gimple_simplify: GIMPLE API. (line 6) 52622* gimple_simplify <1>: GIMPLE API. (line 8) 52623* gimple_simplify <2>: GIMPLE API. (line 10) 52624* gimple_simplify <3>: GIMPLE API. (line 12) 52625* gimple_simplify <4>: GIMPLE API. (line 14) 52626* gimple_simplify <5>: GIMPLE API. (line 16) 52627* gimple_statement_with_ops: Tuple representation. 52628 (line 96) 52629* gimple_stored_syms: Manipulating GIMPLE statements. 52630 (line 125) 52631* GIMPLE_SWITCH: GIMPLE_SWITCH. (line 6) 52632* gimple_switch_default_label: GIMPLE_SWITCH. (line 41) 52633* gimple_switch_index: GIMPLE_SWITCH. (line 24) 52634* gimple_switch_label: GIMPLE_SWITCH. (line 31) 52635* gimple_switch_num_labels: GIMPLE_SWITCH. (line 14) 52636* gimple_switch_set_default_label: GIMPLE_SWITCH. (line 45) 52637* gimple_switch_set_index: GIMPLE_SWITCH. (line 27) 52638* gimple_switch_set_label: GIMPLE_SWITCH. (line 36) 52639* gimple_switch_set_num_labels: GIMPLE_SWITCH. (line 19) 52640* GIMPLE_TRY: GIMPLE_TRY. (line 6) 52641* gimple_try_catch_is_cleanup: GIMPLE_TRY. (line 19) 52642* gimple_try_cleanup: GIMPLE_TRY. (line 26) 52643* gimple_try_eval: GIMPLE_TRY. (line 22) 52644* gimple_try_kind: GIMPLE_TRY. (line 15) 52645* gimple_try_set_catch_is_cleanup: GIMPLE_TRY. (line 30) 52646* gimple_try_set_cleanup: GIMPLE_TRY. (line 38) 52647* gimple_try_set_eval: GIMPLE_TRY. (line 34) 52648* gimple_use_ops: Manipulating GIMPLE statements. 52649 (line 100) 52650* gimple_vdef_ops: Manipulating GIMPLE statements. 52651 (line 114) 52652* gimple_visited_p: Manipulating GIMPLE statements. 52653 (line 57) 52654* gimple_vuse_ops: Manipulating GIMPLE statements. 52655 (line 107) 52656* gimple_wce_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 52657 (line 10) 52658* gimple_wce_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 52659 (line 17) 52660* gimple_wce_set_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 52661 (line 13) 52662* gimple_wce_set_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 52663 (line 20) 52664* GIMPLE_WITH_CLEANUP_EXPR: GIMPLE_WITH_CLEANUP_EXPR. 52665 (line 6) 52666* gimplification: Parsing pass. (line 13) 52667* gimplification <1>: Gimplification pass. 52668 (line 6) 52669* gimplifier: Parsing pass. (line 13) 52670* gimplify_assign: GIMPLE_ASSIGN. (line 41) 52671* gimplify_expr: Gimplification pass. 52672 (line 18) 52673* gimplify_function_tree: Gimplification pass. 52674 (line 18) 52675* GLOBAL_INIT_PRIORITY: Functions for C++. (line 141) 52676* global_regs: Register Basics. (line 93) 52677* GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 90) 52678* greater than: Comparisons. (line 60) 52679* greater than <1>: Comparisons. (line 64) 52680* greater than <2>: Comparisons. (line 72) 52681* gsi_after_labels: Sequence iterators. (line 74) 52682* gsi_bb: Sequence iterators. (line 82) 52683* gsi_commit_edge_inserts: Sequence iterators. (line 193) 52684* gsi_commit_edge_inserts <1>: Maintaining the CFG. 52685 (line 104) 52686* gsi_commit_one_edge_insert: Sequence iterators. (line 188) 52687* gsi_end_p: Sequence iterators. (line 59) 52688* gsi_end_p <1>: Maintaining the CFG. 52689 (line 48) 52690* gsi_for_stmt: Sequence iterators. (line 156) 52691* gsi_insert_after: Sequence iterators. (line 145) 52692* gsi_insert_after <1>: Maintaining the CFG. 52693 (line 60) 52694* gsi_insert_before: Sequence iterators. (line 134) 52695* gsi_insert_before <1>: Maintaining the CFG. 52696 (line 66) 52697* gsi_insert_on_edge: Sequence iterators. (line 173) 52698* gsi_insert_on_edge <1>: Maintaining the CFG. 52699 (line 104) 52700* gsi_insert_on_edge_immediate: Sequence iterators. (line 183) 52701* gsi_insert_seq_after: Sequence iterators. (line 152) 52702* gsi_insert_seq_before: Sequence iterators. (line 141) 52703* gsi_insert_seq_on_edge: Sequence iterators. (line 177) 52704* gsi_last: Sequence iterators. (line 49) 52705* gsi_last <1>: Maintaining the CFG. 52706 (line 44) 52707* gsi_last_bb: Sequence iterators. (line 55) 52708* gsi_link_after: Sequence iterators. (line 113) 52709* gsi_link_before: Sequence iterators. (line 103) 52710* gsi_link_seq_after: Sequence iterators. (line 108) 52711* gsi_link_seq_before: Sequence iterators. (line 97) 52712* gsi_move_after: Sequence iterators. (line 159) 52713* gsi_move_before: Sequence iterators. (line 164) 52714* gsi_move_to_bb_end: Sequence iterators. (line 169) 52715* gsi_next: Sequence iterators. (line 65) 52716* gsi_next <1>: Maintaining the CFG. 52717 (line 52) 52718* gsi_one_before_end_p: Sequence iterators. (line 62) 52719* gsi_prev: Sequence iterators. (line 68) 52720* gsi_prev <1>: Maintaining the CFG. 52721 (line 56) 52722* gsi_remove: Sequence iterators. (line 88) 52723* gsi_remove <1>: Maintaining the CFG. 52724 (line 72) 52725* gsi_replace: Sequence iterators. (line 128) 52726* gsi_seq: Sequence iterators. (line 85) 52727* gsi_split_seq_after: Sequence iterators. (line 118) 52728* gsi_split_seq_before: Sequence iterators. (line 123) 52729* gsi_start: Sequence iterators. (line 39) 52730* gsi_start <1>: Maintaining the CFG. 52731 (line 40) 52732* gsi_start_bb: Sequence iterators. (line 45) 52733* gsi_stmt: Sequence iterators. (line 71) 52734* gsi_stmt_ptr: Sequence iterators. (line 79) 52735* gt: Comparisons. (line 60) 52736* gt and attributes: Expressions. (line 83) 52737* gtu: Comparisons. (line 64) 52738* gtu and attributes: Expressions. (line 83) 52739* GTY: Type Information. (line 6) 52740* GT_EXPR: Unary and Binary Expressions. 52741 (line 6) 52742* guidelines for diagnostics: Guidelines for Diagnostics. 52743 (line 6) 52744* guidelines for options: Guidelines for Options. 52745 (line 6) 52746* guidelines, user experience: User Experience Guidelines. 52747 (line 6) 52748* H in constraint: Simple Constraints. (line 96) 52749* HAmode: Machine Modes. (line 146) 52750* HANDLER: Statements for C++. (line 6) 52751* HANDLER_BODY: Statements for C++. (line 6) 52752* HANDLER_PARMS: Statements for C++. (line 6) 52753* HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 475) 52754* hard registers: Regs and Memory. (line 9) 52755* HARD_FRAME_POINTER_IS_ARG_POINTER: Frame Registers. (line 57) 52756* HARD_FRAME_POINTER_IS_FRAME_POINTER: Frame Registers. (line 50) 52757* HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 19) 52758* HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 10) 52759* HARD_REGNO_NREGS_HAS_PADDING: Values in Registers. 52760 (line 21) 52761* HARD_REGNO_NREGS_WITH_PADDING: Values in Registers. 52762 (line 39) 52763* HARD_REGNO_RENAME_OK: Values in Registers. 52764 (line 113) 52765* HAS_INIT_SECTION: Macros for Initialization. 52766 (line 18) 52767* HAS_LONG_COND_BRANCH: Misc. (line 8) 52768* HAS_LONG_UNCOND_BRANCH: Misc. (line 17) 52769* HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11) 52770* HAVE_POST_DECREMENT: Addressing Modes. (line 11) 52771* HAVE_POST_INCREMENT: Addressing Modes. (line 10) 52772* HAVE_POST_MODIFY_DISP: Addressing Modes. (line 17) 52773* HAVE_POST_MODIFY_REG: Addressing Modes. (line 23) 52774* HAVE_PRE_DECREMENT: Addressing Modes. (line 9) 52775* HAVE_PRE_INCREMENT: Addressing Modes. (line 8) 52776* HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 16) 52777* HAVE_PRE_MODIFY_REG: Addressing Modes. (line 22) 52778* HCmode: Machine Modes. (line 199) 52779* HFmode: Machine Modes. (line 61) 52780* high: Constants. (line 220) 52781* HImode: Machine Modes. (line 29) 52782* HImode, in insn: Insns. (line 291) 52783* HONOR_REG_ALLOC_ORDER: Allocation Order. (line 36) 52784* host configuration: Host Config. (line 6) 52785* host functions: Host Common. (line 6) 52786* host hooks: Host Common. (line 6) 52787* host makefile fragment: Host Fragment. (line 6) 52788* HOST_BIT_BUCKET: Filesystem. (line 51) 52789* HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45) 52790* HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 11) 52791* HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 43) 52792* HOST_HOOKS_GT_PCH_GET_ADDRESS: Host Common. (line 15) 52793* HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 24) 52794* HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89) 52795* HOST_LONG_FORMAT: Host Misc. (line 45) 52796* HOST_LONG_LONG_FORMAT: Host Misc. (line 41) 52797* HOST_OBJECT_SUFFIX: Filesystem. (line 40) 52798* HOST_PTR_PRINTF: Host Misc. (line 49) 52799* HOT_TEXT_SECTION_NAME: Sections. (line 42) 52800* HQmode: Machine Modes. (line 110) 52801* i in constraint: Simple Constraints. (line 68) 52802* I in constraint: Simple Constraints. (line 79) 52803* identifier: Identifiers. (line 6) 52804* IDENTIFIER_LENGTH: Identifiers. (line 22) 52805* IDENTIFIER_NODE: Identifiers. (line 6) 52806* IDENTIFIER_OPNAME_P: Identifiers. (line 27) 52807* IDENTIFIER_POINTER: Identifiers. (line 17) 52808* IDENTIFIER_TYPENAME_P: Identifiers. (line 33) 52809* IEEE 754-2008: Decimal float library routines. 52810 (line 6) 52811* IFCVT_MACHDEP_INIT: Misc. (line 601) 52812* IFCVT_MODIFY_CANCEL: Misc. (line 595) 52813* IFCVT_MODIFY_FINAL: Misc. (line 589) 52814* IFCVT_MODIFY_INSN: Misc. (line 583) 52815* IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 575) 52816* IFCVT_MODIFY_TESTS: Misc. (line 565) 52817* IF_COND: Statements for C++. (line 6) 52818* IF_STMT: Statements for C++. (line 6) 52819* if_then_else: Comparisons. (line 80) 52820* if_then_else and attributes: Expressions. (line 32) 52821* if_then_else usage: Side Effects. (line 56) 52822* IMAGPART_EXPR: Unary and Binary Expressions. 52823 (line 6) 52824* Immediate Uses: SSA Operands. (line 258) 52825* immediate_operand: Machine-Independent Predicates. 52826 (line 10) 52827* IMMEDIATE_PREFIX: Instruction Output. (line 153) 52828* include: Including Patterns. (line 6) 52829* INCLUDE_DEFAULTS: Driver. (line 331) 52830* inclusive-or, bitwise: Arithmetic. (line 163) 52831* INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 188) 52832* INCOMING_REGNO: Register Basics. (line 120) 52833* INCOMING_REG_PARM_STACK_SPACE: Stack Arguments. (line 73) 52834* INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 133) 52835* INCOMING_STACK_BOUNDARY: Storage Layout. (line 171) 52836* INDEX_REG_CLASS: Register Classes. (line 140) 52837* indirect_jump instruction pattern: Standard Names. (line 1724) 52838* indirect_operand: Machine-Independent Predicates. 52839 (line 70) 52840* INDIRECT_REF: Storage References. (line 6) 52841* initialization routines: Initialization. (line 6) 52842* INITIAL_ELIMINATION_OFFSET: Elimination. (line 68) 52843* INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 75) 52844* INIT_ARRAY_SECTION_ASM_OP: Sections. (line 106) 52845* INIT_CUMULATIVE_ARGS: Register Arguments. (line 165) 52846* INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 193) 52847* INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 187) 52848* INIT_ENVIRONMENT: Driver. (line 309) 52849* INIT_EXPANDERS: Per-Function Data. (line 36) 52850* INIT_EXPR: Unary and Binary Expressions. 52851 (line 6) 52852* init_machine_status: Per-Function Data. (line 42) 52853* init_one_libfunc: Library Calls. (line 15) 52854* INIT_SECTION_ASM_OP: Sections. (line 90) 52855* INIT_SECTION_ASM_OP <1>: Macros for Initialization. 52856 (line 9) 52857* inlining: Target Attributes. (line 95) 52858* insert_insn_on_edge: Maintaining the CFG. 52859 (line 104) 52860* insn: Insns. (line 63) 52861* insn and /f: Flags. (line 135) 52862* insn and /j: Flags. (line 171) 52863* insn and /s: Flags. (line 38) 52864* insn and /s <1>: Flags. (line 162) 52865* insn and /u: Flags. (line 28) 52866* insn and /v: Flags. (line 33) 52867* insn attributes: Insn Attributes. (line 6) 52868* insn canonicalization: Insn Canonicalizations. 52869 (line 6) 52870* insn includes: Including Patterns. (line 6) 52871* insn lengths, computing: Insn Lengths. (line 6) 52872* insn notes, notes: Basic Blocks. (line 52) 52873* insn splitting: Insn Splitting. (line 6) 52874* insn-attr.h: Defining Attributes. 52875 (line 34) 52876* insns: Insns. (line 6) 52877* insns, generating: RTL Template. (line 6) 52878* insns, recognizing: RTL Template. (line 6) 52879* INSN_ANNULLED_BRANCH_P: Flags. (line 28) 52880* INSN_CODE: Insns. (line 318) 52881* INSN_DELETED_P: Flags. (line 33) 52882* INSN_FROM_TARGET_P: Flags. (line 38) 52883* insn_list: Insns. (line 568) 52884* INSN_REFERENCES_ARE_DELAYED: Misc. (line 502) 52885* INSN_SETS_ARE_DELAYED: Misc. (line 491) 52886* INSN_UID: Insns. (line 23) 52887* INSN_VAR_LOCATION: Insns. (line 247) 52888* instruction attributes: Insn Attributes. (line 6) 52889* instruction latency time: Processor pipeline description. 52890 (line 6) 52891* instruction latency time <1>: Processor pipeline description. 52892 (line 105) 52893* instruction latency time <2>: Processor pipeline description. 52894 (line 196) 52895* instruction patterns: Patterns. (line 6) 52896* instruction splitting: Insn Splitting. (line 6) 52897* insv instruction pattern: Standard Names. (line 1460) 52898* insvM instruction pattern: Standard Names. (line 1412) 52899* insvmisalignM instruction pattern: Standard Names. (line 1422) 52900* int iterators in .md files: Int Iterators. (line 6) 52901* INT16_TYPE: Type Layout. (line 210) 52902* INT32_TYPE: Type Layout. (line 211) 52903* INT64_TYPE: Type Layout. (line 212) 52904* INT8_TYPE: Type Layout. (line 209) 52905* INTEGER_CST: Constant expressions. 52906 (line 6) 52907* INTEGER_TYPE: Types. (line 6) 52908* Interdependence of Patterns: Dependent Patterns. (line 6) 52909* interfacing to GCC output: Interface. (line 6) 52910* interlock delays: Processor pipeline description. 52911 (line 6) 52912* intermediate representation lowering: Parsing pass. (line 13) 52913* INTMAX_TYPE: Type Layout. (line 186) 52914* INTPTR_TYPE: Type Layout. (line 233) 52915* introduction: Top. (line 6) 52916* INT_FAST16_TYPE: Type Layout. (line 226) 52917* INT_FAST32_TYPE: Type Layout. (line 227) 52918* INT_FAST64_TYPE: Type Layout. (line 228) 52919* INT_FAST8_TYPE: Type Layout. (line 225) 52920* INT_LEAST16_TYPE: Type Layout. (line 218) 52921* INT_LEAST32_TYPE: Type Layout. (line 219) 52922* INT_LEAST64_TYPE: Type Layout. (line 220) 52923* INT_LEAST8_TYPE: Type Layout. (line 217) 52924* INT_TYPE_SIZE: Type Layout. (line 11) 52925* INVOKE__main: Macros for Initialization. 52926 (line 50) 52927* in_struct: Flags. (line 254) 52928* in_struct, in code_label and note: Flags. (line 48) 52929* in_struct, in insn and jump_insn and call_insn: Flags. (line 38) 52930* in_struct, in insn, call_insn, jump_insn and jump_table_data: Flags. 52931 (line 162) 52932* in_struct, in subreg: Flags. (line 201) 52933* ior: Arithmetic. (line 163) 52934* ior and attributes: Expressions. (line 50) 52935* ior, canonicalization of: Insn Canonicalizations. 52936 (line 67) 52937* iorM3 instruction pattern: Standard Names. (line 416) 52938* IRA_HARD_REGNO_ADD_COST_MULTIPLIER: Allocation Order. (line 44) 52939* is_a: Machine Modes. (line 347) 52940* IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 129) 52941* is_gimple_addressable: Logical Operators. (line 113) 52942* is_gimple_asm_val: Logical Operators. (line 117) 52943* is_gimple_assign: Logical Operators. (line 149) 52944* is_gimple_call: Logical Operators. (line 152) 52945* is_gimple_call_addr: Logical Operators. (line 120) 52946* is_gimple_constant: Logical Operators. (line 128) 52947* is_gimple_debug: Logical Operators. (line 155) 52948* is_gimple_ip_invariant: Logical Operators. (line 137) 52949* is_gimple_ip_invariant_address: Logical Operators. (line 142) 52950* is_gimple_mem_ref_addr: Logical Operators. (line 124) 52951* is_gimple_min_invariant: Logical Operators. (line 131) 52952* is_gimple_omp: Logical Operators. (line 166) 52953* is_gimple_val: Logical Operators. (line 107) 52954* iterators in .md files: Iterators. (line 6) 52955* IV analysis on GIMPLE: Scalar evolutions. (line 6) 52956* IV analysis on RTL: loop-iv. (line 6) 52957* JMP_BUF_SIZE: Exception Region Output. 52958 (line 83) 52959* jump: Flags. (line 295) 52960* jump instruction pattern: Standard Names. (line 1602) 52961* jump instruction patterns: Jump Patterns. (line 6) 52962* jump instructions and set: Side Effects. (line 56) 52963* jump, in call_insn: Flags. (line 175) 52964* jump, in insn: Flags. (line 171) 52965* jump, in mem: Flags. (line 59) 52966* Jumps: Jumps. (line 6) 52967* JUMP_ALIGN: Alignment Output. (line 8) 52968* jump_insn: Insns. (line 73) 52969* jump_insn and /f: Flags. (line 135) 52970* jump_insn and /j: Flags. (line 10) 52971* jump_insn and /s: Flags. (line 38) 52972* jump_insn and /s <1>: Flags. (line 162) 52973* jump_insn and /u: Flags. (line 28) 52974* jump_insn and /v: Flags. (line 33) 52975* JUMP_LABEL: Insns. (line 80) 52976* JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 155) 52977* jump_table_data: Insns. (line 166) 52978* jump_table_data and /s: Flags. (line 162) 52979* jump_table_data and /v: Flags. (line 33) 52980* LABEL_ALIGN: Alignment Output. (line 42) 52981* LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 21) 52982* LABEL_ALTERNATE_NAME: Edges. (line 180) 52983* LABEL_ALT_ENTRY_P: Insns. (line 146) 52984* LABEL_DECL: Declarations. (line 6) 52985* LABEL_KIND: Insns. (line 146) 52986* LABEL_NUSES: Insns. (line 142) 52987* LABEL_PRESERVE_P: Flags. (line 48) 52988* label_ref: Constants. (line 199) 52989* label_ref and /v: Flags. (line 54) 52990* label_ref, RTL sharing: Sharing. (line 38) 52991* LABEL_REF_NONLOCAL_P: Flags. (line 54) 52992* language-dependent trees: Language-dependent trees. 52993 (line 6) 52994* language-independent intermediate representation: Parsing pass. 52995 (line 13) 52996* lang_hooks.gimplify_expr: Gimplification pass. 52997 (line 18) 52998* lang_hooks.parse_file: Parsing pass. (line 6) 52999* large return values: Aggregate Return. (line 6) 53000* LAST_STACK_REG: Stack Registers. (line 30) 53001* LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 53002* lceilMN2: Standard Names. (line 1073) 53003* LCSSA: LCSSA. (line 6) 53004* LDD_SUFFIX: Macros for Initialization. 53005 (line 121) 53006* ldexpM3 instruction pattern: Standard Names. (line 858) 53007* LD_FINI_SWITCH: Macros for Initialization. 53008 (line 28) 53009* LD_INIT_SWITCH: Macros for Initialization. 53010 (line 24) 53011* le: Comparisons. (line 76) 53012* le and attributes: Expressions. (line 83) 53013* leaf functions: Leaf Functions. (line 6) 53014* leaf_function_p: Standard Names. (line 1686) 53015* LEAF_REGISTERS: Leaf Functions. (line 23) 53016* LEAF_REG_REMAP: Leaf Functions. (line 37) 53017* left rotate: Arithmetic. (line 195) 53018* left shift: Arithmetic. (line 173) 53019* LEGITIMATE_PIC_OPERAND_P: PIC. (line 31) 53020* LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 150) 53021* length: GTY Options. (line 47) 53022* less than: Comparisons. (line 68) 53023* less than or equal: Comparisons. (line 76) 53024* leu: Comparisons. (line 76) 53025* leu and attributes: Expressions. (line 83) 53026* LE_EXPR: Unary and Binary Expressions. 53027 (line 6) 53028* lfloorMN2: Standard Names. (line 1068) 53029* LIB2FUNCS_EXTRA: Target Fragment. (line 11) 53030* LIBCALL_VALUE: Scalar Return. (line 56) 53031* libgcc.a: Library Calls. (line 6) 53032* LIBGCC2_CFLAGS: Target Fragment. (line 8) 53033* LIBGCC2_GNU_PREFIX: Type Layout. (line 102) 53034* LIBGCC2_UNWIND_ATTRIBUTE: Misc. (line 1020) 53035* LIBGCC_SPEC: Driver. (line 115) 53036* library subroutine names: Library Calls. (line 6) 53037* LIBRARY_PATH_ENV: Misc. (line 543) 53038* LIB_SPEC: Driver. (line 107) 53039* LIMIT_RELOAD_CLASS: Register Classes. (line 296) 53040* LINK_COMMAND_SPEC: Driver. (line 240) 53041* LINK_EH_SPEC: Driver. (line 142) 53042* LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 232) 53043* LINK_LIBGCC_SPECIAL_1: Driver. (line 227) 53044* LINK_SPEC: Driver. (line 100) 53045* list: Containers. (line 6) 53046* Liveness representation: Liveness information. 53047 (line 6) 53048* load address instruction: Simple Constraints. (line 162) 53049* LOAD_EXTEND_OP: Misc. (line 80) 53050* load_multiple instruction pattern: Standard Names. (line 136) 53051* Local Register Allocator (LRA): RTL passes. (line 187) 53052* LOCAL_ALIGNMENT: Storage Layout. (line 284) 53053* LOCAL_CLASS_P: Classes. (line 70) 53054* LOCAL_DECL_ALIGNMENT: Storage Layout. (line 321) 53055* LOCAL_INCLUDE_DIR: Driver. (line 316) 53056* LOCAL_LABEL_PREFIX: Instruction Output. (line 151) 53057* LOCAL_REGNO: Register Basics. (line 134) 53058* location information: Guidelines for Diagnostics. 53059 (line 159) 53060* log10M2 instruction pattern: Standard Names. (line 962) 53061* log1pM2 instruction pattern: Standard Names. (line 952) 53062* log2M2 instruction pattern: Standard Names. (line 969) 53063* logbM2 instruction pattern: Standard Names. (line 976) 53064* Logical Operators: Logical Operators. (line 6) 53065* logical-and, bitwise: Arithmetic. (line 158) 53066* LOGICAL_OP_NON_SHORT_CIRCUIT: Costs. (line 294) 53067* logM2 instruction pattern: Standard Names. (line 945) 53068* LOG_LINKS: Insns. (line 337) 53069* longjmp and automatic variables: Interface. (line 52) 53070* LONG_ACCUM_TYPE_SIZE: Type Layout. (line 92) 53071* LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 57) 53072* LONG_FRACT_TYPE_SIZE: Type Layout. (line 72) 53073* LONG_LONG_ACCUM_TYPE_SIZE: Type Layout. (line 97) 53074* LONG_LONG_FRACT_TYPE_SIZE: Type Layout. (line 77) 53075* LONG_LONG_TYPE_SIZE: Type Layout. (line 32) 53076* LONG_TYPE_SIZE: Type Layout. (line 21) 53077* Loop analysis: Loop representation. 53078 (line 6) 53079* Loop manipulation: Loop manipulation. (line 6) 53080* Loop querying: Loop querying. (line 6) 53081* Loop representation: Loop representation. 53082 (line 6) 53083* Loop-closed SSA form: LCSSA. (line 6) 53084* looping instruction patterns: Looping Patterns. (line 6) 53085* LOOP_ALIGN: Alignment Output. (line 29) 53086* LOOP_EXPR: Unary and Binary Expressions. 53087 (line 6) 53088* lowering, language-dependent intermediate representation: Parsing pass. 53089 (line 13) 53090* lo_sum: Arithmetic. (line 25) 53091* lrintMN2: Standard Names. (line 1058) 53092* lroundMN2: Standard Names. (line 1063) 53093* lshiftrt: Arithmetic. (line 190) 53094* lshiftrt and attributes: Expressions. (line 83) 53095* LSHIFT_EXPR: Unary and Binary Expressions. 53096 (line 6) 53097* lshrM3 instruction pattern: Standard Names. (line 776) 53098* lt: Comparisons. (line 68) 53099* lt and attributes: Expressions. (line 83) 53100* LTGT_EXPR: Unary and Binary Expressions. 53101 (line 6) 53102* lto: LTO. (line 6) 53103* ltrans: LTO. (line 6) 53104* ltu: Comparisons. (line 68) 53105* LT_EXPR: Unary and Binary Expressions. 53106 (line 6) 53107* m in constraint: Simple Constraints. (line 17) 53108* machine attributes: Target Attributes. (line 6) 53109* machine description macros: Target Macros. (line 6) 53110* machine descriptions: Machine Desc. (line 6) 53111* machine mode conversions: Conversions. (line 6) 53112* machine mode wrapper classes: Machine Modes. (line 286) 53113* machine modes: Machine Modes. (line 6) 53114* machine specific constraints: Machine Constraints. 53115 (line 6) 53116* machine-independent predicates: Machine-Independent Predicates. 53117 (line 6) 53118* machine_mode: Machine Modes. (line 6) 53119* MACH_DEP_SECTION_ASM_FLAG: Sections. (line 120) 53120* macros, target description: Target Macros. (line 6) 53121* maddMN4 instruction pattern: Standard Names. (line 697) 53122* makefile fragment: Fragments. (line 6) 53123* makefile targets: Makefile. (line 6) 53124* MAKE_DECL_ONE_ONLY: Label Output. (line 281) 53125* make_safe_from: Expander Definitions. 53126 (line 151) 53127* MALLOC_ABI_ALIGNMENT: Storage Layout. (line 190) 53128* Manipulating GIMPLE statements: Manipulating GIMPLE statements. 53129 (line 6) 53130* marking roots: GGC Roots. (line 6) 53131* maskloadMN instruction pattern: Standard Names. (line 370) 53132* maskstoreMN instruction pattern: Standard Names. (line 377) 53133* mask_gather_loadM instruction pattern: Standard Names. (line 248) 53134* MASK_RETURN_ADDR: Exception Region Output. 53135 (line 35) 53136* mask_scatter_storeM instruction pattern: Standard Names. (line 271) 53137* Match and Simplify: Match and Simplify. (line 6) 53138* matching constraint: Simple Constraints. (line 140) 53139* matching operands: Output Template. (line 49) 53140* match_dup: RTL Template. (line 73) 53141* match_dup <1>: define_peephole2. (line 28) 53142* match_dup and attributes: Insn Lengths. (line 16) 53143* match_operand: RTL Template. (line 16) 53144* match_operand and attributes: Expressions. (line 55) 53145* match_operator: RTL Template. (line 95) 53146* match_op_dup: RTL Template. (line 163) 53147* match_parallel: RTL Template. (line 172) 53148* match_par_dup: RTL Template. (line 219) 53149* match_scratch: RTL Template. (line 58) 53150* match_scratch <1>: define_peephole2. (line 28) 53151* match_test and attributes: Expressions. (line 64) 53152* math library: Soft float library routines. 53153 (line 6) 53154* math, in RTL: Arithmetic. (line 6) 53155* matherr: Library Calls. (line 59) 53156* MATH_LIBRARY: Misc. (line 536) 53157* maxM3 instruction pattern: Standard Names. (line 477) 53158* MAX_BITSIZE_MODE_ANY_INT: Machine Modes. (line 444) 53159* MAX_BITSIZE_MODE_ANY_MODE: Machine Modes. (line 450) 53160* MAX_BITS_PER_WORD: Storage Layout. (line 54) 53161* MAX_CONDITIONAL_EXECUTE: Misc. (line 558) 53162* MAX_FIXED_MODE_SIZE: Storage Layout. (line 466) 53163* MAX_MOVE_MAX: Misc. (line 127) 53164* MAX_OFILE_ALIGNMENT: Storage Layout. (line 228) 53165* MAX_REGS_PER_ADDRESS: Addressing Modes. (line 42) 53166* MAX_STACK_ALIGNMENT: Storage Layout. (line 222) 53167* maybe_undef: GTY Options. (line 141) 53168* may_trap_p, tree_could_trap_p: Edges. (line 114) 53169* mcount: Profiling. (line 12) 53170* MD_EXEC_PREFIX: Driver. (line 271) 53171* MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 93) 53172* MD_HANDLE_UNWABI: Exception Handling. (line 112) 53173* MD_STARTFILE_PREFIX: Driver. (line 299) 53174* MD_STARTFILE_PREFIX_1: Driver. (line 304) 53175* mem: Regs and Memory. (line 396) 53176* mem and /c: Flags. (line 70) 53177* mem and /f: Flags. (line 74) 53178* mem and /j: Flags. (line 59) 53179* mem and /u: Flags. (line 78) 53180* mem and /v: Flags. (line 65) 53181* mem, RTL sharing: Sharing. (line 43) 53182* memory model: Memory model. (line 6) 53183* memory reference, nonoffsettable: Simple Constraints. (line 254) 53184* memory references in constraints: Simple Constraints. (line 17) 53185* memory_barrier instruction pattern: Standard Names. (line 2070) 53186* memory_blockage instruction pattern: Standard Names. (line 2061) 53187* MEMORY_MOVE_COST: Costs. (line 53) 53188* memory_operand: Machine-Independent Predicates. 53189 (line 57) 53190* MEM_ADDR_SPACE: Special Accessors. (line 48) 53191* MEM_ALIAS_SET: Special Accessors. (line 9) 53192* MEM_ALIGN: Special Accessors. (line 45) 53193* MEM_EXPR: Special Accessors. (line 19) 53194* MEM_KEEP_ALIAS_SET_P: Flags. (line 59) 53195* MEM_NOTRAP_P: Flags. (line 70) 53196* MEM_OFFSET: Special Accessors. (line 31) 53197* MEM_OFFSET_KNOWN_P: Special Accessors. (line 27) 53198* MEM_POINTER: Flags. (line 74) 53199* MEM_READONLY_P: Flags. (line 78) 53200* MEM_REF: Storage References. (line 6) 53201* MEM_SIZE: Special Accessors. (line 39) 53202* MEM_SIZE_KNOWN_P: Special Accessors. (line 35) 53203* mem_thread_fence instruction pattern: Standard Names. (line 2360) 53204* MEM_VOLATILE_P: Flags. (line 65) 53205* METHOD_TYPE: Types. (line 6) 53206* MINIMUM_ALIGNMENT: Storage Layout. (line 334) 53207* MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 198) 53208* minM3 instruction pattern: Standard Names. (line 477) 53209* minus: Arithmetic. (line 38) 53210* minus and attributes: Expressions. (line 83) 53211* minus, canonicalization of: Insn Canonicalizations. 53212 (line 27) 53213* MINUS_EXPR: Unary and Binary Expressions. 53214 (line 6) 53215* MIN_UNITS_PER_WORD: Storage Layout. (line 64) 53216* MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6) 53217* miscellaneous register hooks: Miscellaneous Register Hooks. 53218 (line 6) 53219* mnemonic attribute: Mnemonic Attribute. (line 6) 53220* mod: Arithmetic. (line 136) 53221* mod and attributes: Expressions. (line 83) 53222* mode classes: Machine Modes. (line 226) 53223* mode iterators in .md files: Mode Iterators. (line 6) 53224* mode switching: Mode Switching. (line 6) 53225* MODE_ACCUM: Machine Modes. (line 256) 53226* MODE_BASE_REG_CLASS: Register Classes. (line 116) 53227* MODE_BASE_REG_REG_CLASS: Register Classes. (line 122) 53228* MODE_CC: Machine Modes. (line 271) 53229* MODE_CC <1>: MODE_CC Condition Codes. 53230 (line 6) 53231* MODE_CODE_BASE_REG_CLASS: Register Classes. (line 129) 53232* MODE_COMPLEX_FLOAT: Machine Modes. (line 267) 53233* MODE_COMPLEX_INT: Machine Modes. (line 264) 53234* MODE_DECIMAL_FLOAT: Machine Modes. (line 244) 53235* MODE_FLOAT: Machine Modes. (line 240) 53236* MODE_FRACT: Machine Modes. (line 248) 53237* MODE_INT: Machine Modes. (line 232) 53238* MODE_PARTIAL_INT: Machine Modes. (line 236) 53239* MODE_POINTER_BOUNDS: Machine Modes. (line 276) 53240* MODE_RANDOM: Machine Modes. (line 281) 53241* MODE_UACCUM: Machine Modes. (line 260) 53242* MODE_UFRACT: Machine Modes. (line 252) 53243* modifiers in constraints: Modifiers. (line 6) 53244* MODIFY_EXPR: Unary and Binary Expressions. 53245 (line 6) 53246* MODIFY_JNI_METHOD_CALL: Misc. (line 823) 53247* modM3 instruction pattern: Standard Names. (line 416) 53248* modulo scheduling: RTL passes. (line 123) 53249* MOVE_MAX: Misc. (line 122) 53250* MOVE_MAX_PIECES: Costs. (line 210) 53251* MOVE_RATIO: Costs. (line 149) 53252* movM instruction pattern: Standard Names. (line 11) 53253* movmemM instruction pattern: Standard Names. (line 1180) 53254* movmisalignM instruction pattern: Standard Names. (line 125) 53255* movMODEcc instruction pattern: Standard Names. (line 1474) 53256* movstr instruction pattern: Standard Names. (line 1215) 53257* movstrictM instruction pattern: Standard Names. (line 119) 53258* msubMN4 instruction pattern: Standard Names. (line 720) 53259* mulhisi3 instruction pattern: Standard Names. (line 673) 53260* mulM3 instruction pattern: Standard Names. (line 416) 53261* mulqihi3 instruction pattern: Standard Names. (line 677) 53262* mulsidi3 instruction pattern: Standard Names. (line 677) 53263* mult: Arithmetic. (line 93) 53264* mult and attributes: Expressions. (line 83) 53265* mult, canonicalization of: Insn Canonicalizations. 53266 (line 27) 53267* mult, canonicalization of <1>: Insn Canonicalizations. 53268 (line 107) 53269* MULTIARCH_DIRNAME: Target Fragment. (line 173) 53270* MULTILIB_DEFAULTS: Driver. (line 256) 53271* MULTILIB_DIRNAMES: Target Fragment. (line 44) 53272* MULTILIB_EXCEPTIONS: Target Fragment. (line 70) 53273* MULTILIB_EXTRA_OPTS: Target Fragment. (line 135) 53274* MULTILIB_MATCHES: Target Fragment. (line 63) 53275* MULTILIB_OPTIONS: Target Fragment. (line 24) 53276* MULTILIB_OSDIRNAMES: Target Fragment. (line 142) 53277* MULTILIB_REQUIRED: Target Fragment. (line 82) 53278* MULTILIB_REUSE: Target Fragment. (line 103) 53279* multiple alternative constraints: Multi-Alternative. (line 6) 53280* MULTIPLE_SYMBOL_SPACES: Misc. (line 515) 53281* multiplication: Arithmetic. (line 93) 53282* multiplication with signed saturation: Arithmetic. (line 93) 53283* multiplication with unsigned saturation: Arithmetic. (line 93) 53284* MULT_EXPR: Unary and Binary Expressions. 53285 (line 6) 53286* MULT_HIGHPART_EXPR: Unary and Binary Expressions. 53287 (line 6) 53288* mulvM4 instruction pattern: Standard Names. (line 432) 53289* n in constraint: Simple Constraints. (line 73) 53290* name: Identifiers. (line 6) 53291* named address spaces: Named Address Spaces. 53292 (line 6) 53293* named patterns and conditions: Patterns. (line 61) 53294* names, pattern: Standard Names. (line 6) 53295* namespace, scope: Namespaces. (line 6) 53296* NAMESPACE_DECL: Declarations. (line 6) 53297* NAMESPACE_DECL <1>: Namespaces. (line 6) 53298* NATIVE_SYSTEM_HEADER_COMPONENT: Driver. (line 326) 53299* ne: Comparisons. (line 56) 53300* ne and attributes: Expressions. (line 83) 53301* nearbyintM2 instruction pattern: Standard Names. (line 1042) 53302* neg: Arithmetic. (line 82) 53303* neg and attributes: Expressions. (line 83) 53304* neg, canonicalization of: Insn Canonicalizations. 53305 (line 27) 53306* NEGATE_EXPR: Unary and Binary Expressions. 53307 (line 6) 53308* negation: Arithmetic. (line 82) 53309* negation with signed saturation: Arithmetic. (line 82) 53310* negation with unsigned saturation: Arithmetic. (line 82) 53311* negM2 instruction pattern: Standard Names. (line 808) 53312* negMODEcc instruction pattern: Standard Names. (line 1543) 53313* negvM3 instruction pattern: Standard Names. (line 811) 53314* nested functions, support for: Trampolines. (line 6) 53315* nested_ptr: GTY Options. (line 149) 53316* next_bb, prev_bb, FOR_EACH_BB, FOR_ALL_BB: Basic Blocks. (line 25) 53317* NEXT_INSN: Insns. (line 30) 53318* NEXT_OBJC_RUNTIME: Library Calls. (line 82) 53319* NE_EXPR: Unary and Binary Expressions. 53320 (line 6) 53321* nil: RTL Objects. (line 73) 53322* NM_FLAGS: Macros for Initialization. 53323 (line 110) 53324* nondeterministic finite state automaton: Processor pipeline description. 53325 (line 304) 53326* nonimmediate_operand: Machine-Independent Predicates. 53327 (line 100) 53328* nonlocal goto handler: Edges. (line 171) 53329* nonlocal_goto instruction pattern: Standard Names. (line 1896) 53330* nonlocal_goto_receiver instruction pattern: Standard Names. 53331 (line 1913) 53332* nonmemory_operand: Machine-Independent Predicates. 53333 (line 96) 53334* nonoffsettable memory reference: Simple Constraints. (line 254) 53335* NON_LVALUE_EXPR: Unary and Binary Expressions. 53336 (line 6) 53337* nop instruction pattern: Standard Names. (line 1719) 53338* NOP_EXPR: Unary and Binary Expressions. 53339 (line 6) 53340* normal predicates: Predicates. (line 31) 53341* not: Arithmetic. (line 154) 53342* not and attributes: Expressions. (line 50) 53343* not equal: Comparisons. (line 56) 53344* not, canonicalization of: Insn Canonicalizations. 53345 (line 27) 53346* note: Insns. (line 183) 53347* note and /i: Flags. (line 48) 53348* note and /v: Flags. (line 33) 53349* NOTE_INSN_BASIC_BLOCK: Basic Blocks. (line 50) 53350* NOTE_INSN_BASIC_BLOCK <1>: Basic Blocks. (line 52) 53351* NOTE_INSN_BEGIN_STMT: Insns. (line 233) 53352* NOTE_INSN_BLOCK_BEG: Insns. (line 208) 53353* NOTE_INSN_BLOCK_END: Insns. (line 208) 53354* NOTE_INSN_DELETED: Insns. (line 198) 53355* NOTE_INSN_DELETED_LABEL: Insns. (line 203) 53356* NOTE_INSN_EH_REGION_BEG: Insns. (line 214) 53357* NOTE_INSN_EH_REGION_END: Insns. (line 214) 53358* NOTE_INSN_FUNCTION_BEG: Insns. (line 221) 53359* NOTE_INSN_INLINE_ENTRY: Insns. (line 238) 53360* NOTE_INSN_VAR_LOCATION: Insns. (line 225) 53361* NOTE_LINE_NUMBER: Insns. (line 183) 53362* NOTE_SOURCE_FILE: Insns. (line 183) 53363* NOTE_VAR_LOCATION: Insns. (line 225) 53364* NOTICE_UPDATE_CC: CC0 Condition Codes. 53365 (line 30) 53366* notMODEcc instruction pattern: Standard Names. (line 1550) 53367* NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 25) 53368* NO_DBX_FUNCTION_END: DBX Hooks. (line 19) 53369* NO_DBX_GCC_MARKER: File Names and DBX. (line 27) 53370* NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 22) 53371* NO_DOLLAR_IN_LABEL: Label Output. (line 64) 53372* NO_DOT_IN_LABEL: Label Output. (line 70) 53373* NO_FUNCTION_CSE: Costs. (line 289) 53374* NO_PROFILE_COUNTERS: Profiling. (line 27) 53375* NO_REGS: Register Classes. (line 17) 53376* Number of iterations analysis: Number of iterations. 53377 (line 6) 53378* NUM_MACHINE_MODES: Machine Modes. (line 383) 53379* NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30) 53380* NUM_POLY_INT_COEFFS: Overview of poly_int. 53381 (line 24) 53382* N_REG_CLASSES: Register Classes. (line 81) 53383* o in constraint: Simple Constraints. (line 23) 53384* OACC_CACHE: OpenACC. (line 6) 53385* OACC_DATA: OpenACC. (line 6) 53386* OACC_DECLARE: OpenACC. (line 6) 53387* OACC_ENTER_DATA: OpenACC. (line 6) 53388* OACC_EXIT_DATA: OpenACC. (line 6) 53389* OACC_HOST_DATA: OpenACC. (line 6) 53390* OACC_KERNELS: OpenACC. (line 6) 53391* OACC_LOOP: OpenACC. (line 6) 53392* OACC_PARALLEL: OpenACC. (line 6) 53393* OACC_UPDATE: OpenACC. (line 6) 53394* OBJC_GEN_METHOD_LABEL: Label Output. (line 482) 53395* OBJC_JBLEN: Misc. (line 1015) 53396* OBJECT_FORMAT_COFF: Macros for Initialization. 53397 (line 96) 53398* offsettable address: Simple Constraints. (line 23) 53399* OFFSET_TYPE: Types. (line 6) 53400* OImode: Machine Modes. (line 51) 53401* OMP_ATOMIC: OpenMP. (line 6) 53402* OMP_CLAUSE: OpenMP. (line 6) 53403* OMP_CONTINUE: OpenMP. (line 6) 53404* OMP_CRITICAL: OpenMP. (line 6) 53405* OMP_FOR: OpenMP. (line 6) 53406* OMP_MASTER: OpenMP. (line 6) 53407* OMP_ORDERED: OpenMP. (line 6) 53408* OMP_PARALLEL: OpenMP. (line 6) 53409* OMP_RETURN: OpenMP. (line 6) 53410* OMP_SECTION: OpenMP. (line 6) 53411* OMP_SECTIONS: OpenMP. (line 6) 53412* OMP_SINGLE: OpenMP. (line 6) 53413* one_cmplM2 instruction pattern: Standard Names. (line 1177) 53414* operand access: Accessors. (line 6) 53415* Operand Access Routines: SSA Operands. (line 116) 53416* operand constraints: Constraints. (line 6) 53417* Operand Iterators: SSA Operands. (line 116) 53418* operand predicates: Predicates. (line 6) 53419* operand substitution: Output Template. (line 6) 53420* Operands: Operands. (line 6) 53421* operands: SSA Operands. (line 6) 53422* operands <1>: Patterns. (line 67) 53423* operator predicates: Predicates. (line 6) 53424* optc-gen.awk: Options. (line 6) 53425* OPTGROUP_ALL: Optimization groups. 53426 (line 28) 53427* OPTGROUP_INLINE: Optimization groups. 53428 (line 15) 53429* OPTGROUP_IPA: Optimization groups. 53430 (line 9) 53431* OPTGROUP_LOOP: Optimization groups. 53432 (line 12) 53433* OPTGROUP_OMP: Optimization groups. 53434 (line 18) 53435* OPTGROUP_OTHER: Optimization groups. 53436 (line 24) 53437* OPTGROUP_VEC: Optimization groups. 53438 (line 21) 53439* optimization dumps: Optimization info. (line 6) 53440* optimization groups: Optimization groups. 53441 (line 6) 53442* optimization info file names: Dump files and streams. 53443 (line 6) 53444* Optimization infrastructure for GIMPLE: Tree SSA. (line 6) 53445* OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 8) 53446* option specification files: Options. (line 6) 53447* optional hardware or system features: Run-time Target. (line 59) 53448* options, directory search: Including Patterns. (line 47) 53449* options, guidelines for: Guidelines for Options. 53450 (line 6) 53451* OPTION_DEFAULT_SPECS: Driver. (line 25) 53452* opt_mode: Machine Modes. (line 322) 53453* order of register allocation: Allocation Order. (line 6) 53454* ordered_comparison_operator: Machine-Independent Predicates. 53455 (line 115) 53456* ORDERED_EXPR: Unary and Binary Expressions. 53457 (line 6) 53458* Ordering of Patterns: Pattern Ordering. (line 6) 53459* ORIGINAL_REGNO: Special Accessors. (line 53) 53460* other register constraints: Simple Constraints. (line 171) 53461* outgoing_args_size: Stack Arguments. (line 48) 53462* OUTGOING_REGNO: Register Basics. (line 127) 53463* OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 79) 53464* output of assembler code: File Framework. (line 6) 53465* output statements: Output Statement. (line 6) 53466* output templates: Output Template. (line 6) 53467* output_asm_insn: Output Statement. (line 52) 53468* OUTPUT_QUOTED_STRING: File Framework. (line 105) 53469* OVERLAPPING_REGISTER_NAMES: Instruction Output. (line 20) 53470* OVERLOAD: Functions for C++. (line 6) 53471* OVERRIDE_ABI_FORMAT: Register Arguments. (line 157) 53472* OVL_CURRENT: Functions for C++. (line 6) 53473* OVL_NEXT: Functions for C++. (line 6) 53474* p in constraint: Simple Constraints. (line 162) 53475* PAD_VARARGS_DOWN: Register Arguments. (line 238) 53476* parallel: Side Effects. (line 222) 53477* parameters, c++ abi: C++ ABI. (line 6) 53478* parameters, d abi: D Language and ABI. (line 6) 53479* parameters, miscellaneous: Misc. (line 6) 53480* parameters, precompiled headers: PCH Target. (line 6) 53481* parity: Arithmetic. (line 242) 53482* parityM2 instruction pattern: Standard Names. (line 1164) 53483* PARM_BOUNDARY: Storage Layout. (line 150) 53484* PARM_DECL: Declarations. (line 6) 53485* PARSE_LDD_OUTPUT: Macros for Initialization. 53486 (line 125) 53487* pass dumps: Passes. (line 6) 53488* passes and files of the compiler: Passes. (line 6) 53489* passing arguments: Interface. (line 36) 53490* pass_duplicate_computed_gotos: Edges. (line 161) 53491* PATH_SEPARATOR: Filesystem. (line 31) 53492* PATTERN: Insns. (line 307) 53493* pattern conditions: Patterns. (line 55) 53494* pattern names: Standard Names. (line 6) 53495* Pattern Ordering: Pattern Ordering. (line 6) 53496* patterns: Patterns. (line 6) 53497* pc: Regs and Memory. (line 383) 53498* pc and attributes: Insn Lengths. (line 20) 53499* pc, RTL sharing: Sharing. (line 28) 53500* PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 360) 53501* PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 64) 53502* PC_REGNUM: Register Basics. (line 141) 53503* pc_rtx: Regs and Memory. (line 388) 53504* PDImode: Machine Modes. (line 40) 53505* peephole optimization, RTL representation: Side Effects. (line 256) 53506* peephole optimizer definitions: Peephole Definitions. 53507 (line 6) 53508* per-function data: Per-Function Data. (line 6) 53509* percent sign: Output Template. (line 6) 53510* PHI nodes: SSA. (line 31) 53511* PIC: PIC. (line 6) 53512* PIC_OFFSET_TABLE_REGNUM: PIC. (line 15) 53513* PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 25) 53514* pipeline hazard recognizer: Processor pipeline description. 53515 (line 6) 53516* pipeline hazard recognizer <1>: Processor pipeline description. 53517 (line 53) 53518* Plugins: Plugins. (line 6) 53519* plus: Arithmetic. (line 14) 53520* plus and attributes: Expressions. (line 83) 53521* plus, canonicalization of: Insn Canonicalizations. 53522 (line 27) 53523* PLUS_EXPR: Unary and Binary Expressions. 53524 (line 6) 53525* Pmode: Misc. (line 363) 53526* pmode_register_operand: Machine-Independent Predicates. 53527 (line 34) 53528* pointer: Types. (line 6) 53529* POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 76) 53530* POINTER_DIFF_EXPR: Unary and Binary Expressions. 53531 (line 6) 53532* POINTER_PLUS_EXPR: Unary and Binary Expressions. 53533 (line 6) 53534* POINTER_SIZE: Storage Layout. (line 70) 53535* POINTER_TYPE: Types. (line 6) 53536* polynomial integers: poly_int. (line 6) 53537* poly_int: poly_int. (line 6) 53538* poly_int, invariant range: Overview of poly_int. 53539 (line 31) 53540* poly_int, main typedefs: Overview of poly_int. 53541 (line 46) 53542* poly_int, runtime value: Overview of poly_int. 53543 (line 6) 53544* poly_int, template parameters: Overview of poly_int. 53545 (line 24) 53546* poly_int, use in target-independent code: Consequences of using poly_int. 53547 (line 32) 53548* poly_int, use in target-specific code: Consequences of using poly_int. 53549 (line 40) 53550* POLY_INT_CST: Constant expressions. 53551 (line 6) 53552* popcount: Arithmetic. (line 238) 53553* popcountM2 instruction pattern: Standard Names. (line 1152) 53554* pops_args: Function Entry. (line 111) 53555* pop_operand: Machine-Independent Predicates. 53556 (line 87) 53557* portability: Portability. (line 6) 53558* position independent code: PIC. (line 6) 53559* POSTDECREMENT_EXPR: Unary and Binary Expressions. 53560 (line 6) 53561* POSTINCREMENT_EXPR: Unary and Binary Expressions. 53562 (line 6) 53563* post_dec: Incdec. (line 25) 53564* post_inc: Incdec. (line 30) 53565* POST_LINK_SPEC: Driver. (line 236) 53566* post_modify: Incdec. (line 33) 53567* post_order_compute, inverted_post_order_compute, walk_dominator_tree: Basic Blocks. 53568 (line 34) 53569* POWI_MAX_MULTS: Misc. (line 913) 53570* powM3 instruction pattern: Standard Names. (line 990) 53571* pragma: Misc. (line 420) 53572* PREDECREMENT_EXPR: Unary and Binary Expressions. 53573 (line 6) 53574* predefined macros: Run-time Target. (line 6) 53575* predicates: Predicates. (line 6) 53576* predicates and machine modes: Predicates. (line 31) 53577* predication: Conditional Execution. 53578 (line 6) 53579* predict.def: Profile information. 53580 (line 24) 53581* PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 40) 53582* PREFERRED_RELOAD_CLASS: Register Classes. (line 249) 53583* PREFERRED_STACK_BOUNDARY: Storage Layout. (line 164) 53584* prefetch: Side Effects. (line 336) 53585* prefetch and /v: Flags. (line 92) 53586* prefetch instruction pattern: Standard Names. (line 2038) 53587* PREFETCH_SCHEDULE_BARRIER_P: Flags. (line 92) 53588* PREINCREMENT_EXPR: Unary and Binary Expressions. 53589 (line 6) 53590* presence_set: Processor pipeline description. 53591 (line 223) 53592* preserving SSA form: SSA. (line 74) 53593* pretend_args_size: Function Entry. (line 117) 53594* prev_active_insn: define_peephole. (line 60) 53595* PREV_INSN: Insns. (line 26) 53596* pre_dec: Incdec. (line 8) 53597* PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 126) 53598* pre_inc: Incdec. (line 22) 53599* pre_modify: Incdec. (line 52) 53600* PRINT_OPERAND: Instruction Output. (line 95) 53601* PRINT_OPERAND_ADDRESS: Instruction Output. (line 122) 53602* PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 115) 53603* probe_stack instruction pattern: Standard Names. (line 1888) 53604* probe_stack_address instruction pattern: Standard Names. (line 1881) 53605* processor functional units: Processor pipeline description. 53606 (line 6) 53607* processor functional units <1>: Processor pipeline description. 53608 (line 68) 53609* processor pipeline description: Processor pipeline description. 53610 (line 6) 53611* product: Arithmetic. (line 93) 53612* profile feedback: Profile information. 53613 (line 14) 53614* profile representation: Profile information. 53615 (line 6) 53616* PROFILE_BEFORE_PROLOGUE: Profiling. (line 34) 53617* PROFILE_HOOK: Profiling. (line 22) 53618* profiling, code generation: Profiling. (line 6) 53619* program counter: Regs and Memory. (line 384) 53620* prologue: Function Entry. (line 6) 53621* prologue instruction pattern: Standard Names. (line 1977) 53622* PROMOTE_MODE: Storage Layout. (line 87) 53623* pseudo registers: Regs and Memory. (line 9) 53624* PSImode: Machine Modes. (line 32) 53625* PTRDIFF_TYPE: Type Layout. (line 157) 53626* purge_dead_edges: Edges. (line 103) 53627* purge_dead_edges <1>: Maintaining the CFG. 53628 (line 81) 53629* push address instruction: Simple Constraints. (line 162) 53630* pushM1 instruction pattern: Standard Names. (line 403) 53631* PUSH_ARGS: Stack Arguments. (line 17) 53632* PUSH_ARGS_REVERSED: Stack Arguments. (line 25) 53633* push_operand: Machine-Independent Predicates. 53634 (line 80) 53635* push_reload: Addressing Modes. (line 176) 53636* PUSH_ROUNDING: Stack Arguments. (line 31) 53637* PUT_CODE: RTL Objects. (line 47) 53638* PUT_MODE: Machine Modes. (line 380) 53639* PUT_REG_NOTE_KIND: Insns. (line 369) 53640* QCmode: Machine Modes. (line 199) 53641* QFmode: Machine Modes. (line 57) 53642* QImode: Machine Modes. (line 25) 53643* QImode, in insn: Insns. (line 291) 53644* QQmode: Machine Modes. (line 106) 53645* qualified type: Types. (line 6) 53646* qualified type <1>: Types for C++. (line 6) 53647* querying function unit reservations: Processor pipeline description. 53648 (line 90) 53649* question mark: Multi-Alternative. (line 42) 53650* quotient: Arithmetic. (line 116) 53651* r in constraint: Simple Constraints. (line 64) 53652* RDIV_EXPR: Unary and Binary Expressions. 53653 (line 6) 53654* READONLY_DATA_SECTION_ASM_OP: Sections. (line 62) 53655* real operands: SSA Operands. (line 6) 53656* REALPART_EXPR: Unary and Binary Expressions. 53657 (line 6) 53658* REAL_CST: Constant expressions. 53659 (line 6) 53660* REAL_LIBGCC_SPEC: Driver. (line 124) 53661* REAL_NM_FILE_NAME: Macros for Initialization. 53662 (line 105) 53663* REAL_TYPE: Types. (line 6) 53664* REAL_VALUE_ABS: Floating Point. (line 58) 53665* REAL_VALUE_ATOF: Floating Point. (line 39) 53666* REAL_VALUE_FIX: Floating Point. (line 31) 53667* REAL_VALUE_ISINF: Floating Point. (line 49) 53668* REAL_VALUE_ISNAN: Floating Point. (line 52) 53669* REAL_VALUE_NEGATE: Floating Point. (line 55) 53670* REAL_VALUE_NEGATIVE: Floating Point. (line 46) 53671* REAL_VALUE_TO_TARGET_DECIMAL128: Data Output. (line 153) 53672* REAL_VALUE_TO_TARGET_DECIMAL32: Data Output. (line 151) 53673* REAL_VALUE_TO_TARGET_DECIMAL64: Data Output. (line 152) 53674* REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 149) 53675* REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 150) 53676* REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 148) 53677* REAL_VALUE_TYPE: Floating Point. (line 25) 53678* REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 34) 53679* recognizing insns: RTL Template. (line 6) 53680* recog_data.operand: Instruction Output. (line 54) 53681* RECORD_TYPE: Types. (line 6) 53682* RECORD_TYPE <1>: Classes. (line 6) 53683* redirect_edge_and_branch: Profile information. 53684 (line 71) 53685* redirect_edge_and_branch, redirect_jump: Maintaining the CFG. 53686 (line 89) 53687* reduc_and_scal_M instruction pattern: Standard Names. (line 509) 53688* reduc_ior_scal_M instruction pattern: Standard Names. (line 510) 53689* reduc_plus_scal_M instruction pattern: Standard Names. (line 504) 53690* reduc_smax_scal_M instruction pattern: Standard Names. (line 494) 53691* reduc_smin_scal_M instruction pattern: Standard Names. (line 494) 53692* reduc_umax_scal_M instruction pattern: Standard Names. (line 499) 53693* reduc_umin_scal_M instruction pattern: Standard Names. (line 499) 53694* reduc_xor_scal_M instruction pattern: Standard Names. (line 511) 53695* reference: Types. (line 6) 53696* REFERENCE_TYPE: Types. (line 6) 53697* reg: Regs and Memory. (line 9) 53698* reg and /f: Flags. (line 102) 53699* reg and /i: Flags. (line 97) 53700* reg and /v: Flags. (line 106) 53701* reg, RTL sharing: Sharing. (line 17) 53702* register allocation order: Allocation Order. (line 6) 53703* register class definitions: Register Classes. (line 6) 53704* register class preference constraints: Class Preferences. (line 6) 53705* register pairs: Values in Registers. 53706 (line 65) 53707* Register Transfer Language (RTL): RTL. (line 6) 53708* register usage: Registers. (line 6) 53709* registers arguments: Register Arguments. (line 6) 53710* registers in constraints: Simple Constraints. (line 64) 53711* REGISTER_MOVE_COST: Costs. (line 9) 53712* REGISTER_NAMES: Instruction Output. (line 8) 53713* register_operand: Machine-Independent Predicates. 53714 (line 29) 53715* REGISTER_PREFIX: Instruction Output. (line 150) 53716* REGISTER_TARGET_PRAGMAS: Misc. (line 420) 53717* REGMODE_NATURAL_SIZE: Regs and Memory. (line 191) 53718* REGMODE_NATURAL_SIZE <1>: Regs and Memory. (line 268) 53719* REGMODE_NATURAL_SIZE <2>: Values in Registers. 53720 (line 46) 53721* REGNO_MODE_CODE_OK_FOR_BASE_P: Register Classes. (line 172) 53722* REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 150) 53723* REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 160) 53724* REGNO_OK_FOR_BASE_P: Register Classes. (line 146) 53725* REGNO_OK_FOR_INDEX_P: Register Classes. (line 186) 53726* REGNO_REG_CLASS: Register Classes. (line 105) 53727* regs_ever_live: Function Entry. (line 29) 53728* regular expressions: Processor pipeline description. 53729 (line 6) 53730* regular expressions <1>: Processor pipeline description. 53731 (line 105) 53732* REG_ALLOC_ORDER: Allocation Order. (line 8) 53733* REG_BR_PRED: Insns. (line 541) 53734* REG_BR_PROB: Insns. (line 533) 53735* REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information. 53736 (line 82) 53737* REG_BR_PROB_BASE, EDGE_FREQUENCY: Profile information. 53738 (line 52) 53739* REG_CALL_NOCF_CHECK: Insns. (line 557) 53740* REG_CC_SETTER: Insns. (line 505) 53741* REG_CC_USER: Insns. (line 505) 53742* reg_class_contents: Register Basics. (line 93) 53743* REG_CLASS_CONTENTS: Register Classes. (line 91) 53744* reg_class_for_constraint: C Constraint Interface. 53745 (line 48) 53746* REG_CLASS_NAMES: Register Classes. (line 86) 53747* REG_DEAD: Insns. (line 380) 53748* REG_DEAD, REG_UNUSED: Liveness information. 53749 (line 32) 53750* REG_DEP_ANTI: Insns. (line 527) 53751* REG_DEP_OUTPUT: Insns. (line 523) 53752* REG_DEP_TRUE: Insns. (line 520) 53753* REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 109) 53754* REG_EQUAL: Insns. (line 434) 53755* REG_EQUIV: Insns. (line 434) 53756* REG_EXPR: Special Accessors. (line 58) 53757* REG_FRAME_RELATED_EXPR: Insns. (line 547) 53758* REG_FUNCTION_VALUE_P: Flags. (line 97) 53759* REG_INC: Insns. (line 396) 53760* reg_label and /v: Flags. (line 54) 53761* REG_LABEL_OPERAND: Insns. (line 410) 53762* REG_LABEL_TARGET: Insns. (line 419) 53763* reg_names: Register Basics. (line 93) 53764* reg_names <1>: Instruction Output. (line 107) 53765* REG_NONNEG: Insns. (line 402) 53766* REG_NOTES: Insns. (line 344) 53767* REG_NOTE_KIND: Insns. (line 369) 53768* REG_OFFSET: Special Accessors. (line 62) 53769* REG_OK_STRICT: Addressing Modes. (line 99) 53770* REG_PARM_STACK_SPACE: Stack Arguments. (line 58) 53771* REG_PARM_STACK_SPACE, and TARGET_FUNCTION_ARG: Register Arguments. 53772 (line 56) 53773* REG_POINTER: Flags. (line 102) 53774* REG_SETJMP: Insns. (line 428) 53775* REG_UNUSED: Insns. (line 389) 53776* REG_USERVAR_P: Flags. (line 106) 53777* REG_VALUE_IN_UNWIND_CONTEXT: Frame Registers. (line 156) 53778* REG_WORDS_BIG_ENDIAN: Storage Layout. (line 35) 53779* relative costs: Costs. (line 6) 53780* RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 266) 53781* reloading: RTL passes. (line 170) 53782* reload_completed: Standard Names. (line 1686) 53783* reload_in instruction pattern: Standard Names. (line 98) 53784* reload_in_progress: Standard Names. (line 57) 53785* reload_out instruction pattern: Standard Names. (line 98) 53786* remainder: Arithmetic. (line 136) 53787* remainderM3 instruction pattern: Standard Names. (line 844) 53788* reorder: GTY Options. (line 175) 53789* representation of RTL: RTL. (line 6) 53790* reservation delays: Processor pipeline description. 53791 (line 6) 53792* restore_stack_block instruction pattern: Standard Names. (line 1802) 53793* restore_stack_function instruction pattern: Standard Names. 53794 (line 1802) 53795* restore_stack_nonlocal instruction pattern: Standard Names. 53796 (line 1802) 53797* rest_of_decl_compilation: Parsing pass. (line 51) 53798* rest_of_type_compilation: Parsing pass. (line 51) 53799* RESULT_DECL: Declarations. (line 6) 53800* return: Side Effects. (line 72) 53801* return instruction pattern: Standard Names. (line 1660) 53802* return values in registers: Scalar Return. (line 6) 53803* returning aggregate values: Aggregate Return. (line 6) 53804* returning structures and unions: Interface. (line 10) 53805* RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 64) 53806* RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 127) 53807* RETURN_ADDR_OFFSET: Exception Handling. (line 59) 53808* RETURN_ADDR_RTX: Frame Layout. (line 116) 53809* RETURN_EXPR: Statements for C++. (line 6) 53810* RETURN_STMT: Statements for C++. (line 6) 53811* return_val: Flags. (line 283) 53812* return_val, in call_insn: Flags. (line 120) 53813* return_val, in reg: Flags. (line 97) 53814* return_val, in symbol_ref: Flags. (line 216) 53815* reverse probability: Profile information. 53816 (line 66) 53817* REVERSE_CONDITION: MODE_CC Condition Codes. 53818 (line 92) 53819* REVERSIBLE_CC_MODE: MODE_CC Condition Codes. 53820 (line 77) 53821* right rotate: Arithmetic. (line 195) 53822* right shift: Arithmetic. (line 190) 53823* rintM2 instruction pattern: Standard Names. (line 1050) 53824* RISC: Processor pipeline description. 53825 (line 6) 53826* RISC <1>: Processor pipeline description. 53827 (line 223) 53828* roots, marking: GGC Roots. (line 6) 53829* rotate: Arithmetic. (line 195) 53830* rotate <1>: Arithmetic. (line 195) 53831* rotatert: Arithmetic. (line 195) 53832* rotlM3 instruction pattern: Standard Names. (line 776) 53833* rotrM3 instruction pattern: Standard Names. (line 776) 53834* roundM2 instruction pattern: Standard Names. (line 1023) 53835* ROUND_DIV_EXPR: Unary and Binary Expressions. 53836 (line 6) 53837* ROUND_MOD_EXPR: Unary and Binary Expressions. 53838 (line 6) 53839* ROUND_TYPE_ALIGN: Storage Layout. (line 457) 53840* RSHIFT_EXPR: Unary and Binary Expressions. 53841 (line 6) 53842* rsqrtM2 instruction pattern: Standard Names. (line 824) 53843* RTL addition: Arithmetic. (line 14) 53844* RTL addition with signed saturation: Arithmetic. (line 14) 53845* RTL addition with unsigned saturation: Arithmetic. (line 14) 53846* RTL classes: RTL Classes. (line 6) 53847* RTL comparison: Arithmetic. (line 46) 53848* RTL comparison operations: Comparisons. (line 6) 53849* RTL constant expression types: Constants. (line 6) 53850* RTL constants: Constants. (line 6) 53851* RTL declarations: RTL Declarations. (line 6) 53852* RTL difference: Arithmetic. (line 38) 53853* RTL expression: RTL Objects. (line 6) 53854* RTL expressions for arithmetic: Arithmetic. (line 6) 53855* RTL format: RTL Classes. (line 73) 53856* RTL format characters: RTL Classes. (line 78) 53857* RTL function-call insns: Calls. (line 6) 53858* RTL insn template: RTL Template. (line 6) 53859* RTL integers: RTL Objects. (line 6) 53860* RTL memory expressions: Regs and Memory. (line 6) 53861* RTL object types: RTL Objects. (line 6) 53862* RTL postdecrement: Incdec. (line 6) 53863* RTL postincrement: Incdec. (line 6) 53864* RTL predecrement: Incdec. (line 6) 53865* RTL preincrement: Incdec. (line 6) 53866* RTL register expressions: Regs and Memory. (line 6) 53867* RTL representation: RTL. (line 6) 53868* RTL side effect expressions: Side Effects. (line 6) 53869* RTL strings: RTL Objects. (line 6) 53870* RTL structure sharing assumptions: Sharing. (line 6) 53871* RTL subtraction: Arithmetic. (line 38) 53872* RTL subtraction with signed saturation: Arithmetic. (line 38) 53873* RTL subtraction with unsigned saturation: Arithmetic. (line 38) 53874* RTL sum: Arithmetic. (line 14) 53875* RTL vectors: RTL Objects. (line 6) 53876* RTL_CONST_CALL_P: Flags. (line 115) 53877* RTL_CONST_OR_PURE_CALL_P: Flags. (line 125) 53878* RTL_LOOPING_CONST_OR_PURE_CALL_P: Flags. (line 129) 53879* RTL_PURE_CALL_P: Flags. (line 120) 53880* RTX (See RTL): RTL Objects. (line 6) 53881* RTX codes, classes of: RTL Classes. (line 6) 53882* RTX_FRAME_RELATED_P: Flags. (line 135) 53883* run-time conventions: Interface. (line 6) 53884* run-time target specification: Run-time Target. (line 6) 53885* s in constraint: Simple Constraints. (line 100) 53886* SAD_EXPR: Vectors. (line 6) 53887* same_type_p: Types. (line 86) 53888* SAmode: Machine Modes. (line 150) 53889* satfractMN2 instruction pattern: Standard Names. (line 1362) 53890* satfractunsMN2 instruction pattern: Standard Names. (line 1375) 53891* satisfies_constraint_M: C Constraint Interface. 53892 (line 36) 53893* sat_fract: Conversions. (line 90) 53894* SAVE_EXPR: Unary and Binary Expressions. 53895 (line 6) 53896* save_stack_block instruction pattern: Standard Names. (line 1802) 53897* save_stack_function instruction pattern: Standard Names. (line 1802) 53898* save_stack_nonlocal instruction pattern: Standard Names. (line 1802) 53899* SBSS_SECTION_ASM_OP: Sections. (line 75) 53900* Scalar evolutions: Scalar evolutions. (line 6) 53901* scalars, returned as values: Scalar Return. (line 6) 53902* scalar_float_mode: Machine Modes. (line 293) 53903* scalar_int_mode: Machine Modes. (line 290) 53904* scalar_mode: Machine Modes. (line 296) 53905* scalbM3 instruction pattern: Standard Names. (line 851) 53906* scatter_storeM instruction pattern: Standard Names. (line 254) 53907* SCHED_GROUP_P: Flags. (line 162) 53908* SCmode: Machine Modes. (line 199) 53909* scratch: Regs and Memory. (line 320) 53910* scratch operands: Regs and Memory. (line 320) 53911* scratch, RTL sharing: Sharing. (line 38) 53912* scratch_operand: Machine-Independent Predicates. 53913 (line 49) 53914* SDATA_SECTION_ASM_OP: Sections. (line 57) 53915* SDmode: Machine Modes. (line 88) 53916* sdot_prodM instruction pattern: Standard Names. (line 538) 53917* search options: Including Patterns. (line 47) 53918* SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 391) 53919* SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 457) 53920* SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 392) 53921* SECONDARY_RELOAD_CLASS: Register Classes. (line 390) 53922* SELECT_CC_MODE: MODE_CC Condition Codes. 53923 (line 6) 53924* sequence: Side Effects. (line 271) 53925* Sequence iterators: Sequence iterators. (line 6) 53926* set: Side Effects. (line 15) 53927* set and /f: Flags. (line 135) 53928* setmemM instruction pattern: Standard Names. (line 1226) 53929* SETUP_FRAME_ADDRESSES: Frame Layout. (line 94) 53930* SET_ASM_OP: Label Output. (line 451) 53931* SET_ASM_OP <1>: Label Output. (line 462) 53932* set_attr: Tagging Insns. (line 31) 53933* set_attr_alternative: Tagging Insns. (line 49) 53934* set_bb_seq: GIMPLE sequences. (line 75) 53935* SET_DEST: Side Effects. (line 69) 53936* SET_IS_RETURN_P: Flags. (line 171) 53937* SET_LABEL_KIND: Insns. (line 146) 53938* set_optab_libfunc: Library Calls. (line 15) 53939* SET_RATIO: Costs. (line 237) 53940* SET_SRC: Side Effects. (line 69) 53941* set_thread_pointerMODE instruction pattern: Standard Names. 53942 (line 2375) 53943* SET_TYPE_STRUCTURAL_EQUALITY: Types. (line 6) 53944* SET_TYPE_STRUCTURAL_EQUALITY <1>: Types. (line 81) 53945* SFmode: Machine Modes. (line 69) 53946* sharing of RTL components: Sharing. (line 6) 53947* shift: Arithmetic. (line 173) 53948* SHIFT_COUNT_TRUNCATED: Misc. (line 134) 53949* SHLIB_SUFFIX: Macros for Initialization. 53950 (line 133) 53951* SHORT_ACCUM_TYPE_SIZE: Type Layout. (line 82) 53952* SHORT_FRACT_TYPE_SIZE: Type Layout. (line 62) 53953* SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 108) 53954* SHORT_TYPE_SIZE: Type Layout. (line 15) 53955* shrink-wrapping separate components: Shrink-wrapping separate components. 53956 (line 6) 53957* sibcall_epilogue instruction pattern: Standard Names. (line 2009) 53958* sibling call: Edges. (line 121) 53959* SIBLING_CALL_P: Flags. (line 175) 53960* signal-to-noise ratio (metaphorical usage for diagnostics): Guidelines for Diagnostics. 53961 (line 39) 53962* signed division: Arithmetic. (line 116) 53963* signed division with signed saturation: Arithmetic. (line 116) 53964* signed maximum: Arithmetic. (line 141) 53965* signed minimum: Arithmetic. (line 141) 53966* significandM2 instruction pattern: Standard Names. (line 983) 53967* sign_extend: Conversions. (line 23) 53968* sign_extract: Bit-Fields. (line 8) 53969* sign_extract, canonicalization of: Insn Canonicalizations. 53970 (line 103) 53971* SIG_ATOMIC_TYPE: Type Layout. (line 208) 53972* SImode: Machine Modes. (line 37) 53973* simple constraints: Simple Constraints. (line 6) 53974* simple_return: Side Effects. (line 86) 53975* simple_return instruction pattern: Standard Names. (line 1675) 53976* sincosM3 instruction pattern: Standard Names. (line 879) 53977* sinM2 instruction pattern: Standard Names. (line 873) 53978* SIZETYPE: Type Layout. (line 147) 53979* SIZE_ASM_OP: Label Output. (line 33) 53980* SIZE_TYPE: Type Layout. (line 131) 53981* skip: GTY Options. (line 76) 53982* SLOW_BYTE_ACCESS: Costs. (line 117) 53983* smax: Arithmetic. (line 141) 53984* smin: Arithmetic. (line 141) 53985* sms, swing, software pipelining: RTL passes. (line 123) 53986* smulM3_highpart instruction pattern: Standard Names. (line 689) 53987* soft float library: Soft float library routines. 53988 (line 6) 53989* source code, location information: Guidelines for Diagnostics. 53990 (line 159) 53991* special: GTY Options. (line 238) 53992* special predicates: Predicates. (line 31) 53993* SPECS: Target Fragment. (line 194) 53994* speculation_barrier instruction pattern: Standard Names. (line 2076) 53995* speed of instructions: Costs. (line 6) 53996* splitting instructions: Insn Splitting. (line 6) 53997* split_block: Maintaining the CFG. 53998 (line 96) 53999* SQmode: Machine Modes. (line 114) 54000* sqrt: Arithmetic. (line 206) 54001* sqrtM2 instruction pattern: Standard Names. (line 818) 54002* square root: Arithmetic. (line 206) 54003* SSA: SSA. (line 6) 54004* ssaddM3 instruction pattern: Standard Names. (line 416) 54005* ssadM instruction pattern: Standard Names. (line 547) 54006* ssashlM3 instruction pattern: Standard Names. (line 764) 54007* SSA_NAME_DEF_STMT: SSA. (line 184) 54008* SSA_NAME_VERSION: SSA. (line 189) 54009* ssdivM3 instruction pattern: Standard Names. (line 416) 54010* ssmaddMN4 instruction pattern: Standard Names. (line 712) 54011* ssmsubMN4 instruction pattern: Standard Names. (line 736) 54012* ssmulM3 instruction pattern: Standard Names. (line 416) 54013* ssnegM2 instruction pattern: Standard Names. (line 808) 54014* sssubM3 instruction pattern: Standard Names. (line 416) 54015* ss_abs: Arithmetic. (line 200) 54016* ss_ashift: Arithmetic. (line 173) 54017* ss_div: Arithmetic. (line 116) 54018* ss_minus: Arithmetic. (line 38) 54019* ss_mult: Arithmetic. (line 93) 54020* ss_neg: Arithmetic. (line 82) 54021* ss_plus: Arithmetic. (line 14) 54022* ss_truncate: Conversions. (line 43) 54023* stack arguments: Stack Arguments. (line 6) 54024* stack frame layout: Frame Layout. (line 6) 54025* stack smashing protection: Stack Smashing Protection. 54026 (line 6) 54027* STACK_ALIGNMENT_NEEDED: Frame Layout. (line 41) 54028* STACK_BOUNDARY: Storage Layout. (line 156) 54029* STACK_CHECK_BUILTIN: Stack Checking. (line 31) 54030* STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 83) 54031* STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 74) 54032* STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 90) 54033* STACK_CHECK_MOVING_SP: Stack Checking. (line 53) 54034* STACK_CHECK_PROBE_INTERVAL_EXP: Stack Checking. (line 45) 54035* STACK_CHECK_PROTECT: Stack Checking. (line 62) 54036* STACK_CHECK_STATIC_BUILTIN: Stack Checking. (line 38) 54037* STACK_DYNAMIC_OFFSET: Frame Layout. (line 67) 54038* STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory. 54039 (line 83) 54040* STACK_GROWS_DOWNWARD: Frame Layout. (line 8) 54041* STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 89) 54042* STACK_POINTER_OFFSET: Frame Layout. (line 51) 54043* STACK_POINTER_OFFSET and virtual registers: Regs and Memory. 54044 (line 93) 54045* STACK_POINTER_REGNUM: Frame Registers. (line 8) 54046* STACK_POINTER_REGNUM and virtual registers: Regs and Memory. 54047 (line 83) 54048* stack_pointer_rtx: Frame Registers. (line 104) 54049* stack_protect_combined_set instruction pattern: Standard Names. 54050 (line 2385) 54051* stack_protect_combined_test instruction pattern: Standard Names. 54052 (line 2415) 54053* stack_protect_set instruction pattern: Standard Names. (line 2401) 54054* stack_protect_test instruction pattern: Standard Names. (line 2432) 54055* STACK_PUSH_CODE: Frame Layout. (line 12) 54056* STACK_REGS: Stack Registers. (line 19) 54057* STACK_REG_COVER_CLASS: Stack Registers. (line 22) 54058* STACK_SAVEAREA_MODE: Storage Layout. (line 473) 54059* STACK_SIZE_MODE: Storage Layout. (line 484) 54060* STACK_SLOT_ALIGNMENT: Storage Layout. (line 305) 54061* standard pattern names: Standard Names. (line 6) 54062* STANDARD_STARTFILE_PREFIX: Driver. (line 278) 54063* STANDARD_STARTFILE_PREFIX_1: Driver. (line 285) 54064* STANDARD_STARTFILE_PREFIX_2: Driver. (line 292) 54065* STARTFILE_SPEC: Driver. (line 147) 54066* Statement and operand traversals: Statement and operand traversals. 54067 (line 6) 54068* Statement Sequences: Statement Sequences. 54069 (line 6) 54070* Statements: Statements. (line 6) 54071* statements: Function Properties. 54072 (line 6) 54073* statements <1>: Statements for C++. (line 6) 54074* Static profile estimation: Profile information. 54075 (line 24) 54076* static single assignment: SSA. (line 6) 54077* STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 77) 54078* STATIC_CHAIN_REGNUM: Frame Registers. (line 76) 54079* stdarg.h and register arguments: Register Arguments. (line 51) 54080* STDC_0_IN_SYSTEM_HEADERS: Misc. (line 384) 54081* STMT_EXPR: Unary and Binary Expressions. 54082 (line 6) 54083* STMT_IS_FULL_EXPR_P: Statements for C++. (line 22) 54084* storage layout: Storage Layout. (line 6) 54085* STORE_FLAG_VALUE: Misc. (line 235) 54086* STORE_MAX_PIECES: Costs. (line 215) 54087* store_multiple instruction pattern: Standard Names. (line 159) 54088* strcpy: Storage Layout. (line 258) 54089* STRICT_ALIGNMENT: Storage Layout. (line 355) 54090* strict_low_part: RTL Declarations. (line 9) 54091* strict_memory_address_p: Addressing Modes. (line 186) 54092* STRING_CST: Constant expressions. 54093 (line 6) 54094* STRING_POOL_ADDRESS_P: Flags. (line 179) 54095* strlenM instruction pattern: Standard Names. (line 1297) 54096* structure value address: Aggregate Return. (line 6) 54097* structures, returning: Interface. (line 10) 54098* STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 347) 54099* subM3 instruction pattern: Standard Names. (line 416) 54100* SUBOBJECT: Statements for C++. (line 6) 54101* SUBOBJECT_CLEANUP: Statements for C++. (line 6) 54102* subreg: Regs and Memory. (line 97) 54103* subreg and /s: Flags. (line 201) 54104* subreg and /u: Flags. (line 194) 54105* subreg and /u and /v: Flags. (line 184) 54106* subreg, in strict_low_part: RTL Declarations. (line 9) 54107* SUBREG_BYTE: Regs and Memory. (line 311) 54108* SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 184) 54109* SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 194) 54110* SUBREG_PROMOTED_VAR_P: Flags. (line 201) 54111* SUBREG_REG: Regs and Memory. (line 311) 54112* subst iterators in .md files: Subst Iterators. (line 6) 54113* subvM4 instruction pattern: Standard Names. (line 432) 54114* SUCCESS_EXIT_CODE: Host Misc. (line 12) 54115* support for nested functions: Trampolines. (line 6) 54116* SUPPORTS_INIT_PRIORITY: Macros for Initialization. 54117 (line 57) 54118* SUPPORTS_ONE_ONLY: Label Output. (line 290) 54119* SUPPORTS_WEAK: Label Output. (line 264) 54120* SWITCHABLE_TARGET: Run-time Target. (line 168) 54121* SWITCH_BODY: Statements for C++. (line 6) 54122* SWITCH_COND: Statements for C++. (line 6) 54123* SWITCH_STMT: Statements for C++. (line 6) 54124* symbolic label: Sharing. (line 20) 54125* SYMBOL_FLAG_ANCHOR: Special Accessors. (line 117) 54126* SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 99) 54127* SYMBOL_FLAG_FUNCTION: Special Accessors. (line 92) 54128* SYMBOL_FLAG_HAS_BLOCK_INFO: Special Accessors. (line 113) 54129* SYMBOL_FLAG_LOCAL: Special Accessors. (line 95) 54130* SYMBOL_FLAG_SMALL: Special Accessors. (line 104) 54131* SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 108) 54132* symbol_ref: Constants. (line 189) 54133* symbol_ref and /f: Flags. (line 179) 54134* symbol_ref and /i: Flags. (line 216) 54135* symbol_ref and /u: Flags. (line 19) 54136* symbol_ref and /v: Flags. (line 220) 54137* symbol_ref, RTL sharing: Sharing. (line 20) 54138* SYMBOL_REF_ANCHOR_P: Special Accessors. (line 117) 54139* SYMBOL_REF_BLOCK: Special Accessors. (line 130) 54140* SYMBOL_REF_BLOCK_OFFSET: Special Accessors. (line 135) 54141* SYMBOL_REF_CONSTANT: Special Accessors. (line 78) 54142* SYMBOL_REF_DATA: Special Accessors. (line 82) 54143* SYMBOL_REF_DECL: Special Accessors. (line 67) 54144* SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 99) 54145* SYMBOL_REF_FLAG: Flags. (line 220) 54146* SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 289) 54147* SYMBOL_REF_FLAGS: Special Accessors. (line 86) 54148* SYMBOL_REF_FUNCTION_P: Special Accessors. (line 92) 54149* SYMBOL_REF_HAS_BLOCK_INFO_P: Special Accessors. (line 113) 54150* SYMBOL_REF_LOCAL_P: Special Accessors. (line 95) 54151* SYMBOL_REF_SMALL_P: Special Accessors. (line 104) 54152* SYMBOL_REF_TLS_MODEL: Special Accessors. (line 108) 54153* SYMBOL_REF_USED: Flags. (line 211) 54154* SYMBOL_REF_WEAK: Flags. (line 216) 54155* sync_addMODE instruction pattern: Standard Names. (line 2130) 54156* sync_andMODE instruction pattern: Standard Names. (line 2130) 54157* sync_compare_and_swapMODE instruction pattern: Standard Names. 54158 (line 2090) 54159* sync_iorMODE instruction pattern: Standard Names. (line 2130) 54160* sync_lock_releaseMODE instruction pattern: Standard Names. (line 2195) 54161* sync_lock_test_and_setMODE instruction pattern: Standard Names. 54162 (line 2169) 54163* sync_nandMODE instruction pattern: Standard Names. (line 2130) 54164* sync_new_addMODE instruction pattern: Standard Names. (line 2162) 54165* sync_new_andMODE instruction pattern: Standard Names. (line 2162) 54166* sync_new_iorMODE instruction pattern: Standard Names. (line 2162) 54167* sync_new_nandMODE instruction pattern: Standard Names. (line 2162) 54168* sync_new_subMODE instruction pattern: Standard Names. (line 2162) 54169* sync_new_xorMODE instruction pattern: Standard Names. (line 2162) 54170* sync_old_addMODE instruction pattern: Standard Names. (line 2145) 54171* sync_old_andMODE instruction pattern: Standard Names. (line 2145) 54172* sync_old_iorMODE instruction pattern: Standard Names. (line 2145) 54173* sync_old_nandMODE instruction pattern: Standard Names. (line 2145) 54174* sync_old_subMODE instruction pattern: Standard Names. (line 2145) 54175* sync_old_xorMODE instruction pattern: Standard Names. (line 2145) 54176* sync_subMODE instruction pattern: Standard Names. (line 2130) 54177* sync_xorMODE instruction pattern: Standard Names. (line 2130) 54178* SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 176) 54179* SYSROOT_SUFFIX_SPEC: Driver. (line 171) 54180* SYSTEM_IMPLICIT_EXTERN_C: Misc. (line 415) 54181* t-TARGET: Target Fragment. (line 6) 54182* table jump: Basic Blocks. (line 67) 54183* tablejump instruction pattern: Standard Names. (line 1748) 54184* tag: GTY Options. (line 90) 54185* tagging insns: Tagging Insns. (line 6) 54186* tail calls: Tail Calls. (line 6) 54187* TAmode: Machine Modes. (line 158) 54188* tanM2 instruction pattern: Standard Names. (line 890) 54189* target attributes: Target Attributes. (line 6) 54190* target description macros: Target Macros. (line 6) 54191* target functions: Target Structure. (line 6) 54192* target hooks: Target Structure. (line 6) 54193* target makefile fragment: Target Fragment. (line 6) 54194* target specifications: Run-time Target. (line 6) 54195* targetm: Target Structure. (line 6) 54196* targets, makefile: Makefile. (line 6) 54197* TARGET_ABSOLUTE_BIGGEST_ALIGNMENT: Storage Layout. (line 185) 54198* TARGET_ADDITIONAL_ALLOCNO_CLASS_P: Register Classes. (line 639) 54199* TARGET_ADDRESS_COST: Costs. (line 344) 54200* TARGET_ADDR_SPACE_ADDRESS_MODE: Named Address Spaces. 54201 (line 42) 54202* TARGET_ADDR_SPACE_CONVERT: Named Address Spaces. 54203 (line 89) 54204* TARGET_ADDR_SPACE_DEBUG: Named Address Spaces. 54205 (line 99) 54206* TARGET_ADDR_SPACE_DIAGNOSE_USAGE: Named Address Spaces. 54207 (line 103) 54208* TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P: Named Address Spaces. 54209 (line 59) 54210* TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS: Named Address Spaces. 54211 (line 67) 54212* TARGET_ADDR_SPACE_POINTER_MODE: Named Address Spaces. 54213 (line 36) 54214* TARGET_ADDR_SPACE_SUBSET_P: Named Address Spaces. 54215 (line 74) 54216* TARGET_ADDR_SPACE_VALID_POINTER_MODE: Named Address Spaces. 54217 (line 48) 54218* TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID: Named Address Spaces. 54219 (line 83) 54220* TARGET_ALIGN_ANON_BITFIELD: Storage Layout. (line 432) 54221* TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 759) 54222* TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS: Misc. (line 1037) 54223* TARGET_ALWAYS_STRIP_DOTDOT: Driver. (line 250) 54224* TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 99) 54225* TARGET_ARM_EABI_UNWINDER: Exception Region Output. 54226 (line 133) 54227* TARGET_ARRAY_MODE: Register Arguments. (line 358) 54228* TARGET_ARRAY_MODE_SUPPORTED_P: Register Arguments. (line 373) 54229* TARGET_ASAN_SHADOW_OFFSET: Misc. (line 1065) 54230* TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 11) 54231* TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 7) 54232* TARGET_ASM_ALIGNED_PDI_OP: Data Output. (line 10) 54233* TARGET_ASM_ALIGNED_PSI_OP: Data Output. (line 8) 54234* TARGET_ASM_ALIGNED_PTI_OP: Data Output. (line 12) 54235* TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 9) 54236* TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 13) 54237* TARGET_ASM_ASSEMBLE_UNDEFINED_DECL: Label Output. (line 231) 54238* TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 301) 54239* TARGET_ASM_BYTE_OP: Data Output. (line 6) 54240* TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 209) 54241* TARGET_ASM_CLOSE_PAREN: Data Output. (line 139) 54242* TARGET_ASM_CODE_END: File Framework. (line 57) 54243* TARGET_ASM_CONSTRUCTOR: Macros for Initialization. 54244 (line 68) 54245* TARGET_ASM_DECLARE_CONSTANT_NAME: Label Output. (line 177) 54246* TARGET_ASM_DECL_END: Data Output. (line 44) 54247* TARGET_ASM_DESTRUCTOR: Macros for Initialization. 54248 (line 82) 54249* TARGET_ASM_ELF_FLAGS_NUMERIC: File Framework. (line 120) 54250* TARGET_ASM_EMIT_EXCEPT_PERSONALITY: Dispatch Tables. (line 89) 54251* TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL: Dispatch Tables. (line 82) 54252* TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 70) 54253* TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 337) 54254* TARGET_ASM_FILE_END: File Framework. (line 35) 54255* TARGET_ASM_FILE_START: File Framework. (line 8) 54256* TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 16) 54257* TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 29) 54258* TARGET_ASM_FINAL_POSTSCAN_INSN: Instruction Output. (line 82) 54259* TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 67) 54260* TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 61) 54261* TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 73) 54262* TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 18) 54263* TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 225) 54264* TARGET_ASM_FUNCTION_SECTION: File Framework. (line 132) 54265* TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS: File Framework. 54266 (line 142) 54267* TARGET_ASM_GENERATE_PIC_ADDR_DIFF_VEC: Sections. (line 184) 54268* TARGET_ASM_GLOBALIZE_DECL_NAME: Label Output. (line 222) 54269* TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 213) 54270* TARGET_ASM_INIT_SECTIONS: Sections. (line 164) 54271* TARGET_ASM_INTEGER: Data Output. (line 31) 54272* TARGET_ASM_INTERNAL_LABEL: Label Output. (line 380) 54273* TARGET_ASM_LTO_END: File Framework. (line 52) 54274* TARGET_ASM_LTO_START: File Framework. (line 47) 54275* TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 343) 54276* TARGET_ASM_MERGEABLE_RODATA_PREFIX: Sections. (line 233) 54277* TARGET_ASM_NAMED_SECTION: File Framework. (line 112) 54278* TARGET_ASM_OPEN_PAREN: Data Output. (line 138) 54279* TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 48) 54280* TARGET_ASM_OUTPUT_ANCHOR: Anchored Addresses. (line 42) 54281* TARGET_ASM_OUTPUT_DWARF_DTPREL: DWARF. (line 121) 54282* TARGET_ASM_OUTPUT_IDENT: File Framework. (line 99) 54283* TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 167) 54284* TARGET_ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 91) 54285* TARGET_ASM_POST_CFI_STARTPROC: Dispatch Tables. (line 61) 54286* TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY: Function Entry. (line 9) 54287* TARGET_ASM_RECORD_GCC_SWITCHES: File Framework. (line 173) 54288* TARGET_ASM_RECORD_GCC_SWITCHES_SECTION: File Framework. (line 218) 54289* TARGET_ASM_RELOC_RW_MASK: Sections. (line 173) 54290* TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 242) 54291* TARGET_ASM_SELECT_SECTION: Sections. (line 191) 54292* TARGET_ASM_SHOULD_RESTORE_CFA_STATE: Dispatch Tables. (line 107) 54293* TARGET_ASM_TM_CLONE_TABLE_SECTION: Sections. (line 238) 54294* TARGET_ASM_TRAMPOLINE_TEMPLATE: Trampolines. (line 81) 54295* TARGET_ASM_TTYPE: Exception Region Output. 54296 (line 127) 54297* TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 18) 54298* TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 14) 54299* TARGET_ASM_UNALIGNED_PDI_OP: Data Output. (line 17) 54300* TARGET_ASM_UNALIGNED_PSI_OP: Data Output. (line 15) 54301* TARGET_ASM_UNALIGNED_PTI_OP: Data Output. (line 19) 54302* TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 16) 54303* TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 20) 54304* TARGET_ASM_UNIQUE_SECTION: Sections. (line 213) 54305* TARGET_ASM_UNWIND_EMIT: Dispatch Tables. (line 96) 54306* TARGET_ASM_UNWIND_EMIT_BEFORE_INSN: Dispatch Tables. (line 102) 54307* TARGET_ATOMIC_ALIGN_FOR_MODE: Misc. (line 1084) 54308* TARGET_ATOMIC_ASSIGN_EXPAND_FENV: Misc. (line 1090) 54309* TARGET_ATOMIC_TEST_AND_SET_TRUEVAL: Misc. (line 1075) 54310* TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 10) 54311* TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P: Target Attributes. (line 17) 54312* TARGET_BINDS_LOCAL_P: Sections. (line 320) 54313* TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc. (line 856) 54314* TARGET_BRANCH_TARGET_REGISTER_CLASS: Misc. (line 849) 54315* TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 289) 54316* TARGET_BUILTIN_DECL: Misc. (line 637) 54317* TARGET_BUILTIN_RECIPROCAL: Addressing Modes. (line 261) 54318* TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 101) 54319* TARGET_CALLEE_COPIES: Register Arguments. (line 131) 54320* TARGET_CALL_ARGS: Varargs. (line 123) 54321* TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS: Miscellaneous Register Hooks. 54322 (line 6) 54323* TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 234) 54324* TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 836) 54325* TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P: Register Classes. (line 610) 54326* TARGET_CANONICALIZE_COMPARISON: MODE_CC Condition Codes. 54327 (line 55) 54328* TARGET_CANONICAL_VA_LIST_TYPE: Register Arguments. (line 310) 54329* TARGET_CAN_CHANGE_MODE_CLASS: Register Classes. (line 543) 54330* TARGET_CAN_CHANGE_MODE_CLASS and subreg semantics: Regs and Memory. 54331 (line 294) 54332* TARGET_CAN_ELIMINATE: Elimination. (line 58) 54333* TARGET_CAN_FOLLOW_JUMP: Misc. (line 745) 54334* TARGET_CAN_INLINE_P: Target Attributes. (line 165) 54335* TARGET_CAN_USE_DOLOOP_P: Misc. (line 709) 54336* TARGET_CASE_VALUES_THRESHOLD: Misc. (line 46) 54337* TARGET_CC_MODES_COMPATIBLE: MODE_CC Condition Codes. 54338 (line 120) 54339* TARGET_CHECK_PCH_TARGET_FLAGS: PCH Target. (line 26) 54340* TARGET_CHECK_STRING_OBJECT_FORMAT_ARG: Run-time Target. (line 119) 54341* TARGET_CLASS_LIKELY_SPILLED_P: Register Classes. (line 499) 54342* TARGET_CLASS_MAX_NREGS: Register Classes. (line 515) 54343* TARGET_COMMUTATIVE_P: Misc. (line 752) 54344* TARGET_COMPARE_BY_PIECES_BRANCH_RATIO: Costs. (line 200) 54345* TARGET_COMPARE_VERSION_PRIORITY: Misc. (line 686) 54346* TARGET_COMPUTE_FRAME_LAYOUT: Elimination. (line 74) 54347* TARGET_COMPUTE_PRESSURE_CLASSES: Register Classes. (line 655) 54348* TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 25) 54349* TARGET_CONDITIONAL_REGISTER_USAGE: Register Basics. (line 93) 54350* TARGET_CONSTANT_ALIGNMENT: Storage Layout. (line 271) 54351* TARGET_CONST_ANCHOR: Misc. (line 1048) 54352* TARGET_CONST_NOT_OK_FOR_DEBUG_P: Addressing Modes. (line 230) 54353* TARGET_CONVERT_TO_TYPE: Misc. (line 1008) 54354* TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 8) 54355* TARGET_CSTORE_MODE: Register Classes. (line 647) 54356* TARGET_CUSTOM_FUNCTION_DESCRIPTORS: Trampolines. (line 39) 54357* TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 86) 54358* TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 37) 54359* TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 61) 54360* TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 24) 54361* TARGET_CXX_DECL_MANGLING_CONTEXT: C++ ABI. (line 92) 54362* TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 52) 54363* TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 17) 54364* TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 11) 54365* TARGET_CXX_GUARD_TYPE: C++ ABI. (line 6) 54366* TARGET_CXX_IMPLICIT_EXTERN_C: Misc. (line 407) 54367* TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 28) 54368* TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 42) 54369* TARGET_CXX_LIBRARY_RTTI_COMDAT: C++ ABI. (line 68) 54370* TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 73) 54371* TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT: C++ ABI. (line 79) 54372* TARGET_C_EXCESS_PRECISION: Storage Layout. (line 109) 54373* TARGET_C_PREINCLUDE: Misc. (line 395) 54374* TARGET_DEBUG_UNWIND_INFO: DWARF. (line 32) 54375* TARGET_DECIMAL_FLOAT_SUPPORTED_P: Storage Layout. (line 537) 54376* TARGET_DECLSPEC: Target Attributes. (line 72) 54377* TARGET_DEFAULT_PACK_STRUCT: Misc. (line 479) 54378* TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 123) 54379* TARGET_DEFAULT_TARGET_FLAGS: Run-time Target. (line 55) 54380* TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 465) 54381* TARGET_DELAY_SCHED2: DWARF. (line 77) 54382* TARGET_DELAY_VARTRACK: DWARF. (line 81) 54383* TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 221) 54384* TARGET_DIFFERENT_ADDR_DISPLACEMENT_P: Register Classes. (line 603) 54385* TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 55) 54386* TARGET_DWARF_CALLING_CONVENTION: DWARF. (line 12) 54387* TARGET_DWARF_FRAME_REG_MODE: Exception Region Output. 54388 (line 113) 54389* TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 165) 54390* TARGET_DWARF_POLY_INDETERMINATE_VALUE: Frame Layout. (line 177) 54391* TARGET_DWARF_REGISTER_SPAN: Exception Region Output. 54392 (line 104) 54393* TARGET_D_CPU_VERSIONS: D Language and ABI. (line 6) 54394* TARGET_D_CRITSEC_SIZE: D Language and ABI. (line 17) 54395* TARGET_D_OS_VERSIONS: D Language and ABI. (line 13) 54396* TARGET_EDOM: Library Calls. (line 59) 54397* TARGET_EMPTY_RECORD_P: Aggregate Return. (line 86) 54398* TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS: Emulated TLS. (line 67) 54399* TARGET_EMUTLS_GET_ADDRESS: Emulated TLS. (line 18) 54400* TARGET_EMUTLS_REGISTER_COMMON: Emulated TLS. (line 23) 54401* TARGET_EMUTLS_TMPL_PREFIX: Emulated TLS. (line 44) 54402* TARGET_EMUTLS_TMPL_SECTION: Emulated TLS. (line 35) 54403* TARGET_EMUTLS_VAR_ALIGN_FIXED: Emulated TLS. (line 62) 54404* TARGET_EMUTLS_VAR_FIELDS: Emulated TLS. (line 48) 54405* TARGET_EMUTLS_VAR_INIT: Emulated TLS. (line 55) 54406* TARGET_EMUTLS_VAR_PREFIX: Emulated TLS. (line 40) 54407* TARGET_EMUTLS_VAR_SECTION: Emulated TLS. (line 30) 54408* TARGET_ENCODE_SECTION_INFO: Sections. (line 263) 54409* TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes. 54410 (line 82) 54411* TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 127) 54412* TARGET_END_CALL_ARGS: Varargs. (line 137) 54413* TARGET_ENUM_VA_LIST_P: Register Arguments. (line 293) 54414* TARGET_ESTIMATED_POLY_VALUE: Costs. (line 425) 54415* TARGET_EXCEPT_UNWIND_INFO: Exception Region Output. 54416 (line 46) 54417* TARGET_EXECUTABLE_SUFFIX: Misc. (line 810) 54418* TARGET_EXPAND_BUILTIN: Misc. (line 647) 54419* TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 64) 54420* TARGET_EXPAND_DIVMOD_LIBFUNC: Scheduling. (line 461) 54421* TARGET_EXPAND_TO_RTL_HOOK: Storage Layout. (line 543) 54422* TARGET_EXPR: Unary and Binary Expressions. 54423 (line 6) 54424* TARGET_EXTRA_INCLUDES: Misc. (line 923) 54425* TARGET_EXTRA_LIVE_ON_ENTRY: Tail Calls. (line 20) 54426* TARGET_EXTRA_PRE_INCLUDES: Misc. (line 930) 54427* TARGET_FIXED_CONDITION_CODE_REGS: MODE_CC Condition Codes. 54428 (line 105) 54429* TARGET_FIXED_POINT_SUPPORTED_P: Storage Layout. (line 540) 54430* target_flags: Run-time Target. (line 51) 54431* TARGET_FLAGS_REGNUM: MODE_CC Condition Codes. 54432 (line 133) 54433* TARGET_FLOATN_BUILTIN_P: Register Arguments. (line 423) 54434* TARGET_FLOATN_MODE: Register Arguments. (line 405) 54435* TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P: Run-time Target. 54436 (line 187) 54437* TARGET_FN_ABI_VA_LIST: Register Arguments. (line 305) 54438* TARGET_FOLD_BUILTIN: Misc. (line 669) 54439* TARGET_FORMAT_TYPES: Misc. (line 951) 54440* TARGET_FRAME_POINTER_REQUIRED: Elimination. (line 8) 54441* TARGET_FUNCTION_ARG: Register Arguments. (line 10) 54442* TARGET_FUNCTION_ARG_ADVANCE: Register Arguments. (line 202) 54443* TARGET_FUNCTION_ARG_BOUNDARY: Register Arguments. (line 256) 54444* TARGET_FUNCTION_ARG_OFFSET: Register Arguments. (line 214) 54445* TARGET_FUNCTION_ARG_PADDING: Register Arguments. (line 222) 54446* TARGET_FUNCTION_ARG_ROUND_BOUNDARY: Register Arguments. (line 262) 54447* TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 93) 54448* TARGET_FUNCTION_INCOMING_ARG: Register Arguments. (line 71) 54449* TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 6) 54450* TARGET_FUNCTION_VALUE: Scalar Return. (line 9) 54451* TARGET_FUNCTION_VALUE_REGNO_P: Scalar Return. (line 96) 54452* TARGET_GENERATE_VERSION_DISPATCHER_BODY: Misc. (line 702) 54453* TARGET_GEN_CCMP_FIRST: Misc. (line 876) 54454* TARGET_GEN_CCMP_NEXT: Misc. (line 887) 54455* TARGET_GET_DRAP_RTX: Misc. (line 1031) 54456* TARGET_GET_FUNCTION_VERSIONS_DISPATCHER: Misc. (line 695) 54457* TARGET_GET_MULTILIB_ABI_NAME: Register Basics. (line 90) 54458* TARGET_GET_PCH_VALIDITY: PCH Target. (line 6) 54459* TARGET_GET_RAW_ARG_MODE: Aggregate Return. (line 81) 54460* TARGET_GET_RAW_RESULT_MODE: Aggregate Return. (line 76) 54461* TARGET_GET_VALID_OPTION_VALUES: Stack Smashing Protection. 54462 (line 39) 54463* TARGET_GIMPLE_FOLD_BUILTIN: Misc. (line 679) 54464* TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 315) 54465* TARGET_GOACC_DIM_LIMIT: Addressing Modes. (line 499) 54466* TARGET_GOACC_FORK_JOIN: Addressing Modes. (line 503) 54467* TARGET_GOACC_REDUCTION: Addressing Modes. (line 514) 54468* TARGET_GOACC_VALIDATE_DIMS: Addressing Modes. (line 486) 54469* TARGET_HANDLE_C_OPTION: Run-time Target. (line 73) 54470* TARGET_HANDLE_OPTION: Run-time Target. (line 59) 54471* TARGET_HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 52) 54472* TARGET_HARD_REGNO_MODE_OK: Values in Registers. 54473 (line 54) 54474* TARGET_HARD_REGNO_NREGS: Values in Registers. 54475 (line 10) 54476* TARGET_HARD_REGNO_SCRATCH_OK: Values in Registers. 54477 (line 139) 54478* TARGET_HAS_IFUNC_P: Misc. (line 1079) 54479* TARGET_HAS_NO_HW_DIVIDE: Library Calls. (line 52) 54480* TARGET_HAVE_CONDITIONAL_EXECUTION: Misc. (line 870) 54481* TARGET_HAVE_CTORS_DTORS: Macros for Initialization. 54482 (line 63) 54483* TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 150) 54484* TARGET_HAVE_SPECULATION_SAFE_VALUE: Misc. (line 1162) 54485* TARGET_HAVE_SRODATA_SECTION: Sections. (line 309) 54486* TARGET_HAVE_SWITCHABLE_BSS_SECTIONS: File Framework. (line 155) 54487* TARGET_HAVE_TLS: Sections. (line 329) 54488* TARGET_INIT_BUILTINS: Misc. (line 621) 54489* TARGET_INIT_DWARF_REG_SIZES_EXTRA: Exception Region Output. 54490 (line 119) 54491* TARGET_INIT_LIBFUNCS: Library Calls. (line 15) 54492* TARGET_INIT_PIC_REG: Register Arguments. (line 95) 54493* TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 80) 54494* TARGET_INSN_COST: Costs. (line 380) 54495* TARGET_INSTANTIATE_DECLS: Storage Layout. (line 551) 54496* TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN: Misc. (line 975) 54497* TARGET_INVALID_BINARY_OP: Misc. (line 994) 54498* TARGET_INVALID_CONVERSION: Misc. (line 981) 54499* TARGET_INVALID_UNARY_OP: Misc. (line 987) 54500* TARGET_INVALID_WITHIN_DOLOOP: Misc. (line 726) 54501* TARGET_IN_SMALL_DATA_P: Sections. (line 305) 54502* TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS: Register Classes. (line 570) 54503* TARGET_KEEP_LEAF_WHEN_PROFILED: Profiling. (line 39) 54504* TARGET_LEGITIMATE_ADDRESS_P: Addressing Modes. (line 48) 54505* TARGET_LEGITIMATE_COMBINED_INSN: Misc. (line 740) 54506* TARGET_LEGITIMATE_CONSTANT_P: Addressing Modes. (line 213) 54507* TARGET_LEGITIMIZE_ADDRESS: Addressing Modes. (line 129) 54508* TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT: Register Classes. (line 618) 54509* TARGET_LIBCALL_VALUE: Scalar Return. (line 65) 54510* TARGET_LIBC_HAS_FUNCTION: Library Calls. (line 77) 54511* TARGET_LIBFUNC_GNU_PREFIX: Library Calls. (line 24) 54512* TARGET_LIBGCC_CMP_RETURN_MODE: Storage Layout. (line 493) 54513* TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P: Register Arguments. 54514 (line 397) 54515* TARGET_LIBGCC_SDATA_SECTION: Sections. (line 136) 54516* TARGET_LIBGCC_SHIFT_COUNT_MODE: Storage Layout. (line 499) 54517* TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 42) 54518* TARGET_LOAD_BOUNDS_FOR_ARG: Varargs. (line 153) 54519* TARGET_LOAD_RETURNED_BOUNDS: Varargs. (line 172) 54520* TARGET_LOOP_UNROLL_ADJUST: Misc. (line 904) 54521* TARGET_LRA_P: Register Classes. (line 577) 54522* TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 606) 54523* TARGET_MANGLE_ASSEMBLER_NAME: Label Output. (line 356) 54524* TARGET_MANGLE_DECL_ASSEMBLER_NAME: Sections. (line 253) 54525* TARGET_MANGLE_TYPE: Storage Layout. (line 555) 54526* TARGET_MAX_ANCHOR_OFFSET: Anchored Addresses. (line 38) 54527* TARGET_MAX_NOCE_IFCVT_SEQ_COST: Costs. (line 390) 54528* TARGET_MD_ASM_ADJUST: Misc. (line 524) 54529* TARGET_MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 445) 54530* TARGET_MEMMODEL_CHECK: Misc. (line 1070) 54531* TARGET_MEMORY_MOVE_COST: Costs. (line 79) 54532* TARGET_MEM_CONSTRAINT: Addressing Modes. (line 107) 54533* TARGET_MEM_REF: Storage References. (line 6) 54534* TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 45) 54535* TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 37) 54536* TARGET_MIN_ANCHOR_OFFSET: Anchored Addresses. (line 32) 54537* TARGET_MIN_ARITHMETIC_PRECISION: Misc. (line 63) 54538* TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 112) 54539* TARGET_MODES_TIEABLE_P: Values in Registers. 54540 (line 123) 54541* TARGET_MODE_AFTER: Mode Switching. (line 57) 54542* TARGET_MODE_DEPENDENT_ADDRESS_P: Addressing Modes. (line 196) 54543* TARGET_MODE_EMIT: Mode Switching. (line 42) 54544* TARGET_MODE_ENTRY: Mode Switching. (line 64) 54545* TARGET_MODE_EXIT: Mode Switching. (line 71) 54546* TARGET_MODE_NEEDED: Mode Switching. (line 50) 54547* TARGET_MODE_PRIORITY: Mode Switching. (line 78) 54548* TARGET_MODE_REP_EXTENDED: Misc. (line 197) 54549* TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 509) 54550* TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 64) 54551* TARGET_MUST_PASS_IN_STACK, and TARGET_FUNCTION_ARG: Register Arguments. 54552 (line 56) 54553* TARGET_NARROW_VOLATILE_BITFIELD: Storage Layout. (line 438) 54554* TARGET_NOCE_CONVERSION_PROFITABLE_P: Costs. (line 409) 54555* TARGET_NO_REGISTER_ALLOCATION: DWARF. (line 85) 54556* TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P: Costs. (line 415) 54557* TARGET_N_FORMAT_TYPES: Misc. (line 956) 54558* TARGET_OBJC_CONSTRUCT_STRING_OBJECT: Run-time Target. (line 88) 54559* TARGET_OBJC_DECLARE_CLASS_DEFINITION: Run-time Target. (line 109) 54560* TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE: Run-time Target. 54561 (line 104) 54562* TARGET_OBJECT_SUFFIX: Misc. (line 805) 54563* TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 45) 54564* TARGET_OFFLOAD_OPTIONS: Misc. (line 1113) 54565* TARGET_OMIT_STRUCT_RETURN_REG: Scalar Return. (line 117) 54566* TARGET_OPTAB_SUPPORTED_P: Costs. (line 299) 54567* TARGET_OPTF: Misc. (line 938) 54568* TARGET_OPTION_DEFAULT_PARAMS: Run-time Target. (line 160) 54569* TARGET_OPTION_FUNCTION_VERSIONS: Target Attributes. (line 157) 54570* TARGET_OPTION_INIT_STRUCT: Run-time Target. (line 156) 54571* TARGET_OPTION_OPTIMIZATION_TABLE: Run-time Target. (line 142) 54572* TARGET_OPTION_OVERRIDE: Target Attributes. (line 144) 54573* TARGET_OPTION_POST_STREAM_IN: Target Attributes. (line 125) 54574* TARGET_OPTION_PRAGMA_PARSE: Target Attributes. (line 137) 54575* TARGET_OPTION_PRINT: Target Attributes. (line 131) 54576* TARGET_OPTION_RESTORE: Target Attributes. (line 119) 54577* TARGET_OPTION_SAVE: Target Attributes. (line 112) 54578* TARGET_OPTION_VALIDATE_PARAM: Run-time Target. (line 164) 54579* TARGET_OPTION_VALID_ATTRIBUTE_P: Target Attributes. (line 100) 54580* TARGET_OS_CPP_BUILTINS: Run-time Target. (line 41) 54581* TARGET_OVERRIDES_FORMAT_ATTRIBUTES: Misc. (line 960) 54582* TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc. (line 966) 54583* TARGET_OVERRIDES_FORMAT_INIT: Misc. (line 970) 54584* TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE: Run-time Target. (line 126) 54585* TARGET_PASS_BY_REFERENCE: Register Arguments. (line 119) 54586* TARGET_PCH_VALID_P: PCH Target. (line 11) 54587* TARGET_POSIX_IO: Misc. (line 550) 54588* TARGET_PREFERRED_ELSE_VALUE: Addressing Modes. (line 522) 54589* TARGET_PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 284) 54590* TARGET_PREFERRED_RELOAD_CLASS: Register Classes. (line 213) 54591* TARGET_PREFERRED_RENAME_CLASS: Register Classes. (line 201) 54592* TARGET_PREPARE_PCH_SAVE: PCH Target. (line 34) 54593* TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 144) 54594* TARGET_PROFILE_BEFORE_PROLOGUE: Sections. (line 313) 54595* TARGET_PROMOTED_TYPE: Misc. (line 1000) 54596* TARGET_PROMOTE_FUNCTION_MODE: Storage Layout. (line 126) 54597* TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 10) 54598* TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 250) 54599* TARGET_RECORD_OFFLOAD_SYMBOL: Misc. (line 1108) 54600* TARGET_REF_MAY_ALIAS_ERRNO: Register Arguments. (line 326) 54601* TARGET_REGISTER_MOVE_COST: Costs. (line 31) 54602* TARGET_REGISTER_PRIORITY: Register Classes. (line 582) 54603* TARGET_REGISTER_USAGE_LEVELING_P: Register Classes. (line 593) 54604* TARGET_RELAYOUT_FUNCTION: Target Attributes. (line 172) 54605* TARGET_REMOVE_EXTRA_CALL_PRESERVED_REGS: Register Basics. (line 65) 54606* TARGET_RESET_LOCATION_VIEW: DWARF. (line 57) 54607* TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 658) 54608* TARGET_RETURN_CALL_WITH_MAX_CLOBBERS: Register Basics. (line 77) 54609* TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 15) 54610* TARGET_RETURN_IN_MSB: Scalar Return. (line 124) 54611* TARGET_RETURN_POPS_ARGS: Stack Arguments. (line 98) 54612* TARGET_RTX_COSTS: Costs. (line 313) 54613* TARGET_RUN_TARGET_SELFTESTS: Misc. (line 1199) 54614* TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 342) 54615* TARGET_SCHED_ADJUST_COST: Scheduling. (line 35) 54616* TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 50) 54617* TARGET_SCHED_ALLOC_SCHED_CONTEXT: Scheduling. (line 294) 54618* TARGET_SCHED_CAN_SPECULATE_INSN: Scheduling. (line 354) 54619* TARGET_SCHED_CLEAR_SCHED_CONTEXT: Scheduling. (line 309) 54620* TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 101) 54621* TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 255) 54622* TARGET_SCHED_DFA_POST_ADVANCE_CYCLE: Scheduling. (line 172) 54623* TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 156) 54624* TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE: Scheduling. (line 165) 54625* TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 144) 54626* TARGET_SCHED_DISPATCH: Scheduling. (line 370) 54627* TARGET_SCHED_DISPATCH_DO: Scheduling. (line 375) 54628* TARGET_SCHED_EXPOSED_PIPELINE: Scheduling. (line 379) 54629* TARGET_SCHED_FINISH: Scheduling. (line 122) 54630* TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 137) 54631* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK: Scheduling. (line 235) 54632* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN: Scheduling. (line 223) 54633* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling. 54634 (line 179) 54635* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling. 54636 (line 207) 54637* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END: Scheduling. (line 240) 54638* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI: Scheduling. (line 250) 54639* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT: Scheduling. (line 245) 54640* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE: Scheduling. (line 229) 54641* TARGET_SCHED_FREE_SCHED_CONTEXT: Scheduling. (line 313) 54642* TARGET_SCHED_FUSION_PRIORITY: Scheduling. (line 389) 54643* TARGET_SCHED_GEN_SPEC_CHECK: Scheduling. (line 335) 54644* TARGET_SCHED_H_I_D_EXTENDED: Scheduling. (line 289) 54645* TARGET_SCHED_INIT: Scheduling. (line 111) 54646* TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 161) 54647* TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 153) 54648* TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 129) 54649* TARGET_SCHED_INIT_SCHED_CONTEXT: Scheduling. (line 298) 54650* TARGET_SCHED_ISSUE_RATE: Scheduling. (line 11) 54651* TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 267) 54652* TARGET_SCHED_MACRO_FUSION_P: Scheduling. (line 87) 54653* TARGET_SCHED_MACRO_FUSION_PAIR_P: Scheduling. (line 91) 54654* TARGET_SCHED_NEEDS_BLOCK_P: Scheduling. (line 328) 54655* TARGET_SCHED_REASSOCIATION_WIDTH: Scheduling. (line 384) 54656* TARGET_SCHED_REORDER: Scheduling. (line 58) 54657* TARGET_SCHED_REORDER2: Scheduling. (line 75) 54658* TARGET_SCHED_SET_SCHED_CONTEXT: Scheduling. (line 305) 54659* TARGET_SCHED_SET_SCHED_FLAGS: Scheduling. (line 347) 54660* TARGET_SCHED_SMS_RES_MII: Scheduling. (line 361) 54661* TARGET_SCHED_SPECULATE_INSN: Scheduling. (line 316) 54662* TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 22) 54663* TARGET_SECONDARY_MEMORY_NEEDED: Register Classes. (line 447) 54664* TARGET_SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 466) 54665* TARGET_SECONDARY_RELOAD: Register Classes. (line 312) 54666* TARGET_SECTION_TYPE_FLAGS: File Framework. (line 160) 54667* TARGET_SELECT_EARLY_REMAT_MODES: Register Classes. (line 488) 54668* TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P: Misc. (line 223) 54669* TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 71) 54670* TARGET_SETUP_INCOMING_VARARG_BOUNDS: Varargs. (line 182) 54671* TARGET_SET_CURRENT_FUNCTION: Misc. (line 787) 54672* TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 33) 54673* TARGET_SET_UP_BY_PROLOGUE: Tail Calls. (line 29) 54674* TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 160) 54675* TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB: Shrink-wrapping separate components. 54676 (line 36) 54677* TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS: Shrink-wrapping separate components. 54678 (line 43) 54679* TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS: Shrink-wrapping separate components. 54680 (line 54) 54681* TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS: Shrink-wrapping separate components. 54682 (line 50) 54683* TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS: Shrink-wrapping separate components. 54684 (line 27) 54685* TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS: Shrink-wrapping separate components. 54686 (line 58) 54687* TARGET_SIMD_CLONE_ADJUST: Addressing Modes. (line 473) 54688* TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN: Addressing Modes. 54689 (line 465) 54690* TARGET_SIMD_CLONE_USABLE: Addressing Modes. (line 477) 54691* TARGET_SIMT_VF: Addressing Modes. (line 483) 54692* TARGET_SLOW_UNALIGNED_ACCESS: Costs. (line 132) 54693* TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P: Register Arguments. 54694 (line 433) 54695* TARGET_SPECULATION_SAFE_VALUE: Misc. (line 1181) 54696* TARGET_SPILL_CLASS: Register Classes. (line 632) 54697* TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 277) 54698* TARGET_STACK_CLASH_PROTECTION_ALLOCA_PROBE_RANGE: Stack Checking. 54699 (line 97) 54700* TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection. 54701 (line 16) 54702* TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection. 54703 (line 6) 54704* TARGET_STACK_PROTECT_RUNTIME_ENABLED_P: Stack Smashing Protection. 54705 (line 25) 54706* TARGET_STARTING_FRAME_OFFSET: Frame Layout. (line 34) 54707* TARGET_STARTING_FRAME_OFFSET and virtual registers: Regs and Memory. 54708 (line 74) 54709* TARGET_STATIC_CHAIN: Frame Registers. (line 90) 54710* TARGET_STATIC_RTX_ALIGNMENT: Storage Layout. (line 243) 54711* TARGET_STORE_BOUNDS_FOR_ARG: Varargs. (line 163) 54712* TARGET_STORE_RETURNED_BOUNDS: Varargs. (line 177) 54713* TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 107) 54714* TARGET_STRING_OBJECT_REF_TYPE_P: Run-time Target. (line 114) 54715* TARGET_STRIP_NAME_ENCODING: Sections. (line 300) 54716* TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 44) 54717* TARGET_SUPPORTS_SPLIT_STACK: Stack Smashing Protection. 54718 (line 30) 54719* TARGET_SUPPORTS_WEAK: Label Output. (line 272) 54720* TARGET_SUPPORTS_WIDE_INT: Misc. (line 1121) 54721* TARGET_TERMINATE_DW2_EH_FRAME_INFO: Exception Region Output. 54722 (line 98) 54723* TARGET_TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 127) 54724* TARGET_TRAMPOLINE_INIT: Trampolines. (line 107) 54725* TARGET_TRANSLATE_MODE_ATTRIBUTE: Register Arguments. (line 333) 54726* TARGET_TRULY_NOOP_TRUNCATION: Misc. (line 184) 54727* TARGET_UNSPEC_MAY_TRAP_P: Misc. (line 778) 54728* TARGET_UNWIND_TABLES_DEFAULT: Exception Region Output. 54729 (line 73) 54730* TARGET_UNWIND_WORD_MODE: Storage Layout. (line 505) 54731* TARGET_UPDATE_STACK_BOUNDARY: Misc. (line 1027) 54732* TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 123) 54733* TARGET_USE_ANCHORS_FOR_SYMBOL_P: Anchored Addresses. (line 53) 54734* TARGET_USE_BLOCKS_FOR_CONSTANT_P: Addressing Modes. (line 248) 54735* TARGET_USE_BLOCKS_FOR_DECL_P: Addressing Modes. (line 255) 54736* TARGET_USE_BY_PIECES_INFRASTRUCTURE_P: Costs. (line 165) 54737* TARGET_USE_PSEUDO_PIC_REG: Register Arguments. (line 91) 54738* TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 66) 54739* TARGET_VALID_POINTER_MODE: Register Arguments. (line 321) 54740* TARGET_VECTORIZE_ADD_STMT_COST: Addressing Modes. (line 428) 54741* TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES: Addressing Modes. 54742 (line 388) 54743* TARGET_VECTORIZE_BUILTIN_CONVERSION: Addressing Modes. (line 336) 54744* TARGET_VECTORIZE_BUILTIN_GATHER: Addressing Modes. (line 451) 54745* TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 266) 54746* TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION: Addressing Modes. 54747 (line 356) 54748* TARGET_VECTORIZE_BUILTIN_SCATTER: Addressing Modes. (line 458) 54749* TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST: Addressing Modes. 54750 (line 292) 54751* TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION: Addressing Modes. 54752 (line 348) 54753* TARGET_VECTORIZE_DESTROY_COST_DATA: Addressing Modes. (line 446) 54754* TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE: Addressing Modes. 54755 (line 412) 54756* TARGET_VECTORIZE_FINISH_COST: Addressing Modes. (line 439) 54757* TARGET_VECTORIZE_GET_MASK_MODE: Addressing Modes. (line 400) 54758* TARGET_VECTORIZE_INIT_COST: Addressing Modes. (line 419) 54759* TARGET_VECTORIZE_PREFERRED_SIMD_MODE: Addressing Modes. (line 373) 54760* TARGET_VECTORIZE_PREFERRED_VECTOR_ALIGNMENT: Addressing Modes. 54761 (line 298) 54762* TARGET_VECTORIZE_SPLIT_REDUCTION: Addressing Modes. (line 380) 54763* TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT: Addressing Modes. 54764 (line 363) 54765* TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE: Addressing Modes. 54766 (line 310) 54767* TARGET_VECTORIZE_VEC_PERM_CONST: Addressing Modes. (line 316) 54768* TARGET_VECTOR_ALIGNMENT: Storage Layout. (line 298) 54769* TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 353) 54770* TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 303) 54771* TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 297) 54772* TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 286) 54773* TARGET_WANT_DEBUG_PUB_SECTIONS: DWARF. (line 72) 54774* TARGET_WARN_FUNC_RETURN: Tail Calls. (line 35) 54775* TARGET_WARN_PARAMETER_PASSING_ABI: Aggregate Return. (line 90) 54776* TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 308) 54777* TCmode: Machine Modes. (line 199) 54778* TDmode: Machine Modes. (line 97) 54779* TEMPLATE_DECL: Declarations. (line 6) 54780* Temporaries: Temporaries. (line 6) 54781* termination routines: Initialization. (line 6) 54782* testing constraints: C Constraint Interface. 54783 (line 6) 54784* TEXT_SECTION_ASM_OP: Sections. (line 37) 54785* TFmode: Machine Modes. (line 101) 54786* The Language: The Language. (line 6) 54787* THEN_CLAUSE: Statements for C++. (line 6) 54788* THREAD_MODEL_SPEC: Driver. (line 162) 54789* THROW_EXPR: Unary and Binary Expressions. 54790 (line 6) 54791* THUNK_DECL: Declarations. (line 6) 54792* THUNK_DELTA: Declarations. (line 6) 54793* TImode: Machine Modes. (line 48) 54794* TImode, in insn: Insns. (line 291) 54795* TLS_COMMON_ASM_OP: Sections. (line 80) 54796* TLS_SECTION_ASM_FLAG: Sections. (line 85) 54797* tm.h macros: Target Macros. (line 6) 54798* TQFmode: Machine Modes. (line 65) 54799* TQmode: Machine Modes. (line 122) 54800* trampolines for nested functions: Trampolines. (line 6) 54801* TRAMPOLINE_ALIGNMENT: Trampolines. (line 101) 54802* TRAMPOLINE_SECTION: Trampolines. (line 92) 54803* TRAMPOLINE_SIZE: Trampolines. (line 97) 54804* TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 163) 54805* trap instruction pattern: Standard Names. (line 2019) 54806* tree: Tree overview. (line 6) 54807* tree <1>: Macros and Functions. 54808 (line 6) 54809* Tree SSA: Tree SSA. (line 6) 54810* TREE_CHAIN: Macros and Functions. 54811 (line 6) 54812* TREE_CODE: Tree overview. (line 6) 54813* tree_fits_shwi_p: Constant expressions. 54814 (line 6) 54815* tree_fits_uhwi_p: Constant expressions. 54816 (line 6) 54817* TREE_INT_CST_ELT: Constant expressions. 54818 (line 6) 54819* tree_int_cst_equal: Constant expressions. 54820 (line 6) 54821* TREE_INT_CST_LOW: Constant expressions. 54822 (line 6) 54823* tree_int_cst_lt: Constant expressions. 54824 (line 6) 54825* TREE_INT_CST_NUNITS: Constant expressions. 54826 (line 6) 54827* TREE_LIST: Containers. (line 6) 54828* TREE_OPERAND: Expression trees. (line 6) 54829* TREE_PUBLIC: Function Basics. (line 6) 54830* TREE_PUBLIC <1>: Function Properties. 54831 (line 28) 54832* TREE_PURPOSE: Containers. (line 6) 54833* TREE_READONLY: Function Properties. 54834 (line 37) 54835* tree_size: Macros and Functions. 54836 (line 13) 54837* TREE_STATIC: Function Properties. 54838 (line 31) 54839* TREE_STRING_LENGTH: Constant expressions. 54840 (line 6) 54841* TREE_STRING_POINTER: Constant expressions. 54842 (line 6) 54843* TREE_THIS_VOLATILE: Function Properties. 54844 (line 34) 54845* tree_to_shwi: Constant expressions. 54846 (line 6) 54847* tree_to_uhwi: Constant expressions. 54848 (line 6) 54849* TREE_TYPE: Macros and Functions. 54850 (line 6) 54851* TREE_TYPE <1>: Types. (line 6) 54852* TREE_TYPE <2>: Working with declarations. 54853 (line 11) 54854* TREE_TYPE <3>: Expression trees. (line 6) 54855* TREE_TYPE <4>: Expression trees. (line 17) 54856* TREE_TYPE <5>: Function Basics. (line 47) 54857* TREE_TYPE <6>: Types for C++. (line 6) 54858* TREE_VALUE: Containers. (line 6) 54859* TREE_VEC: Containers. (line 6) 54860* TREE_VEC_ELT: Containers. (line 6) 54861* TREE_VEC_LENGTH: Containers. (line 6) 54862* true positive: Guidelines for Diagnostics. 54863 (line 39) 54864* truncate: Conversions. (line 38) 54865* truncMN2 instruction pattern: Standard Names. (line 1340) 54866* TRUNC_DIV_EXPR: Unary and Binary Expressions. 54867 (line 6) 54868* TRUNC_MOD_EXPR: Unary and Binary Expressions. 54869 (line 6) 54870* TRUTH_ANDIF_EXPR: Unary and Binary Expressions. 54871 (line 6) 54872* TRUTH_AND_EXPR: Unary and Binary Expressions. 54873 (line 6) 54874* TRUTH_NOT_EXPR: Unary and Binary Expressions. 54875 (line 6) 54876* TRUTH_ORIF_EXPR: Unary and Binary Expressions. 54877 (line 6) 54878* TRUTH_OR_EXPR: Unary and Binary Expressions. 54879 (line 6) 54880* TRUTH_XOR_EXPR: Unary and Binary Expressions. 54881 (line 6) 54882* TRY_BLOCK: Statements for C++. (line 6) 54883* TRY_HANDLERS: Statements for C++. (line 6) 54884* TRY_STMTS: Statements for C++. (line 6) 54885* Tuple specific accessors: Tuple specific accessors. 54886 (line 6) 54887* tuples: Tuple representation. 54888 (line 6) 54889* type: Types. (line 6) 54890* type declaration: Declarations. (line 6) 54891* TYPENAME_TYPE: Types for C++. (line 6) 54892* TYPENAME_TYPE_FULLNAME: Types. (line 6) 54893* TYPENAME_TYPE_FULLNAME <1>: Types for C++. (line 6) 54894* TYPEOF_TYPE: Types for C++. (line 6) 54895* TYPE_ALIGN: Types. (line 6) 54896* TYPE_ALIGN <1>: Types. (line 30) 54897* TYPE_ALIGN <2>: Types for C++. (line 6) 54898* TYPE_ALIGN <3>: Types for C++. (line 44) 54899* TYPE_ARG_TYPES: Types. (line 6) 54900* TYPE_ARG_TYPES <1>: Types for C++. (line 6) 54901* TYPE_ASM_OP: Label Output. (line 76) 54902* TYPE_ATTRIBUTES: Attributes. (line 24) 54903* TYPE_BINFO: Classes. (line 6) 54904* TYPE_BUILT_IN: Types for C++. (line 66) 54905* TYPE_CANONICAL: Types. (line 6) 54906* TYPE_CANONICAL <1>: Types. (line 41) 54907* TYPE_CONTEXT: Types. (line 6) 54908* TYPE_CONTEXT <1>: Types for C++. (line 6) 54909* TYPE_DECL: Declarations. (line 6) 54910* TYPE_FIELDS: Types. (line 6) 54911* TYPE_FIELDS <1>: Types for C++. (line 6) 54912* TYPE_FIELDS <2>: Classes. (line 6) 54913* TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 93) 54914* TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 78) 54915* TYPE_HAS_MUTABLE_P: Classes. (line 83) 54916* TYPE_HAS_NEW_OPERATOR: Classes. (line 90) 54917* TYPE_MAIN_VARIANT: Types. (line 6) 54918* TYPE_MAIN_VARIANT <1>: Types. (line 19) 54919* TYPE_MAIN_VARIANT <2>: Types for C++. (line 6) 54920* TYPE_MAX_VALUE: Types. (line 6) 54921* TYPE_METHOD_BASETYPE: Types. (line 6) 54922* TYPE_METHOD_BASETYPE <1>: Types for C++. (line 6) 54923* TYPE_MIN_VALUE: Types. (line 6) 54924* TYPE_NAME: Types. (line 6) 54925* TYPE_NAME <1>: Types. (line 33) 54926* TYPE_NAME <2>: Types for C++. (line 6) 54927* TYPE_NAME <3>: Types for C++. (line 47) 54928* TYPE_NOTHROW_P: Functions for C++. (line 154) 54929* TYPE_OFFSET_BASETYPE: Types. (line 6) 54930* TYPE_OFFSET_BASETYPE <1>: Types for C++. (line 6) 54931* TYPE_OPERAND_FMT: Label Output. (line 87) 54932* TYPE_OVERLOADS_ARRAY_REF: Classes. (line 101) 54933* TYPE_OVERLOADS_ARROW: Classes. (line 104) 54934* TYPE_OVERLOADS_CALL_EXPR: Classes. (line 97) 54935* TYPE_POLYMORPHIC_P: Classes. (line 74) 54936* TYPE_PRECISION: Types. (line 6) 54937* TYPE_PRECISION <1>: Types for C++. (line 6) 54938* TYPE_PTRDATAMEM_P: Types for C++. (line 6) 54939* TYPE_PTRDATAMEM_P <1>: Types for C++. (line 69) 54940* TYPE_PTRFN_P: Types for C++. (line 76) 54941* TYPE_PTROBV_P: Types for C++. (line 6) 54942* TYPE_PTROB_P: Types for C++. (line 79) 54943* TYPE_PTR_P: Types for C++. (line 72) 54944* TYPE_QUAL_CONST: Types. (line 6) 54945* TYPE_QUAL_CONST <1>: Types for C++. (line 6) 54946* TYPE_QUAL_RESTRICT: Types. (line 6) 54947* TYPE_QUAL_RESTRICT <1>: Types for C++. (line 6) 54948* TYPE_QUAL_VOLATILE: Types. (line 6) 54949* TYPE_QUAL_VOLATILE <1>: Types for C++. (line 6) 54950* TYPE_RAISES_EXCEPTIONS: Functions for C++. (line 149) 54951* TYPE_SIZE: Types. (line 6) 54952* TYPE_SIZE <1>: Types. (line 25) 54953* TYPE_SIZE <2>: Types for C++. (line 6) 54954* TYPE_SIZE <3>: Types for C++. (line 39) 54955* TYPE_STRUCTURAL_EQUALITY_P: Types. (line 6) 54956* TYPE_STRUCTURAL_EQUALITY_P <1>: Types. (line 77) 54957* TYPE_UNQUALIFIED: Types. (line 6) 54958* TYPE_UNQUALIFIED <1>: Types for C++. (line 6) 54959* TYPE_VFIELD: Classes. (line 6) 54960* uaddvM4 instruction pattern: Standard Names. (line 435) 54961* uavgM3_ceil instruction pattern: Standard Names. (line 796) 54962* uavgM3_floor instruction pattern: Standard Names. (line 784) 54963* UDAmode: Machine Modes. (line 170) 54964* udiv: Arithmetic. (line 130) 54965* udivM3 instruction pattern: Standard Names. (line 416) 54966* udivmodM4 instruction pattern: Standard Names. (line 761) 54967* udot_prodM instruction pattern: Standard Names. (line 539) 54968* UDQmode: Machine Modes. (line 138) 54969* UHAmode: Machine Modes. (line 162) 54970* UHQmode: Machine Modes. (line 130) 54971* UINT16_TYPE: Type Layout. (line 214) 54972* UINT32_TYPE: Type Layout. (line 215) 54973* UINT64_TYPE: Type Layout. (line 216) 54974* UINT8_TYPE: Type Layout. (line 213) 54975* UINTMAX_TYPE: Type Layout. (line 197) 54976* UINTPTR_TYPE: Type Layout. (line 234) 54977* UINT_FAST16_TYPE: Type Layout. (line 230) 54978* UINT_FAST32_TYPE: Type Layout. (line 231) 54979* UINT_FAST64_TYPE: Type Layout. (line 232) 54980* UINT_FAST8_TYPE: Type Layout. (line 229) 54981* UINT_LEAST16_TYPE: Type Layout. (line 222) 54982* UINT_LEAST32_TYPE: Type Layout. (line 223) 54983* UINT_LEAST64_TYPE: Type Layout. (line 224) 54984* UINT_LEAST8_TYPE: Type Layout. (line 221) 54985* umaddMN4 instruction pattern: Standard Names. (line 708) 54986* umax: Arithmetic. (line 149) 54987* umaxM3 instruction pattern: Standard Names. (line 416) 54988* umin: Arithmetic. (line 149) 54989* uminM3 instruction pattern: Standard Names. (line 416) 54990* umod: Arithmetic. (line 136) 54991* umodM3 instruction pattern: Standard Names. (line 416) 54992* umsubMN4 instruction pattern: Standard Names. (line 732) 54993* umulhisi3 instruction pattern: Standard Names. (line 680) 54994* umulM3_highpart instruction pattern: Standard Names. (line 694) 54995* umulqihi3 instruction pattern: Standard Names. (line 680) 54996* umulsidi3 instruction pattern: Standard Names. (line 680) 54997* umulvM4 instruction pattern: Standard Names. (line 440) 54998* unchanging: Flags. (line 307) 54999* unchanging, in call_insn: Flags. (line 115) 55000* unchanging, in jump_insn, call_insn and insn: Flags. (line 28) 55001* unchanging, in mem: Flags. (line 78) 55002* unchanging, in subreg: Flags. (line 184) 55003* unchanging, in subreg <1>: Flags. (line 194) 55004* unchanging, in symbol_ref: Flags. (line 19) 55005* UNEQ_EXPR: Unary and Binary Expressions. 55006 (line 6) 55007* UNGE_EXPR: Unary and Binary Expressions. 55008 (line 6) 55009* UNGT_EXPR: Unary and Binary Expressions. 55010 (line 6) 55011* unions, returning: Interface. (line 10) 55012* UNION_TYPE: Types. (line 6) 55013* UNION_TYPE <1>: Classes. (line 6) 55014* UNITS_PER_WORD: Storage Layout. (line 60) 55015* UNKNOWN_TYPE: Types. (line 6) 55016* UNKNOWN_TYPE <1>: Types for C++. (line 6) 55017* UNLE_EXPR: Unary and Binary Expressions. 55018 (line 6) 55019* UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 48) 55020* UNLT_EXPR: Unary and Binary Expressions. 55021 (line 6) 55022* UNORDERED_EXPR: Unary and Binary Expressions. 55023 (line 6) 55024* unshare_all_rtl: Sharing. (line 61) 55025* unsigned division: Arithmetic. (line 130) 55026* unsigned division with unsigned saturation: Arithmetic. (line 130) 55027* unsigned greater than: Comparisons. (line 64) 55028* unsigned greater than <1>: Comparisons. (line 72) 55029* unsigned less than: Comparisons. (line 68) 55030* unsigned less than <1>: Comparisons. (line 76) 55031* unsigned minimum and maximum: Arithmetic. (line 149) 55032* unsigned_fix: Conversions. (line 77) 55033* unsigned_float: Conversions. (line 62) 55034* unsigned_fract_convert: Conversions. (line 97) 55035* unsigned_sat_fract: Conversions. (line 103) 55036* unspec: Side Effects. (line 311) 55037* unspec <1>: Constant Definitions. 55038 (line 111) 55039* unspec_volatile: Side Effects. (line 311) 55040* unspec_volatile <1>: Constant Definitions. 55041 (line 99) 55042* untyped_call instruction pattern: Standard Names. (line 1645) 55043* untyped_return instruction pattern: Standard Names. (line 1708) 55044* UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59) 55045* update_ssa: SSA. (line 74) 55046* update_stmt: Manipulating GIMPLE statements. 55047 (line 140) 55048* update_stmt <1>: SSA Operands. (line 6) 55049* update_stmt_if_modified: Manipulating GIMPLE statements. 55050 (line 143) 55051* UQQmode: Machine Modes. (line 126) 55052* usaddM3 instruction pattern: Standard Names. (line 416) 55053* usadM instruction pattern: Standard Names. (line 548) 55054* USAmode: Machine Modes. (line 166) 55055* usashlM3 instruction pattern: Standard Names. (line 764) 55056* usdivM3 instruction pattern: Standard Names. (line 416) 55057* use: Side Effects. (line 180) 55058* used: Flags. (line 325) 55059* used, in symbol_ref: Flags. (line 211) 55060* user: GTY Options. (line 245) 55061* user experience guidelines: User Experience Guidelines. 55062 (line 6) 55063* user gc: User GC. (line 6) 55064* USER_LABEL_PREFIX: Instruction Output. (line 152) 55065* USE_C_ALLOCA: Host Misc. (line 19) 55066* USE_LD_AS_NEEDED: Driver. (line 135) 55067* USE_LOAD_POST_DECREMENT: Costs. (line 254) 55068* USE_LOAD_POST_INCREMENT: Costs. (line 249) 55069* USE_LOAD_PRE_DECREMENT: Costs. (line 264) 55070* USE_LOAD_PRE_INCREMENT: Costs. (line 259) 55071* USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 205) 55072* USE_STORE_POST_DECREMENT: Costs. (line 274) 55073* USE_STORE_POST_INCREMENT: Costs. (line 269) 55074* USE_STORE_PRE_DECREMENT: Costs. (line 284) 55075* USE_STORE_PRE_INCREMENT: Costs. (line 279) 55076* USING_STMT: Statements for C++. (line 6) 55077* usmaddMN4 instruction pattern: Standard Names. (line 716) 55078* usmsubMN4 instruction pattern: Standard Names. (line 740) 55079* usmulhisi3 instruction pattern: Standard Names. (line 684) 55080* usmulM3 instruction pattern: Standard Names. (line 416) 55081* usmulqihi3 instruction pattern: Standard Names. (line 684) 55082* usmulsidi3 instruction pattern: Standard Names. (line 684) 55083* usnegM2 instruction pattern: Standard Names. (line 808) 55084* USQmode: Machine Modes. (line 134) 55085* ussubM3 instruction pattern: Standard Names. (line 416) 55086* usubvM4 instruction pattern: Standard Names. (line 440) 55087* us_ashift: Arithmetic. (line 173) 55088* us_minus: Arithmetic. (line 38) 55089* us_mult: Arithmetic. (line 93) 55090* us_neg: Arithmetic. (line 82) 55091* us_plus: Arithmetic. (line 14) 55092* us_truncate: Conversions. (line 48) 55093* UTAmode: Machine Modes. (line 174) 55094* UTQmode: Machine Modes. (line 142) 55095* V in constraint: Simple Constraints. (line 43) 55096* values, returned by functions: Scalar Return. (line 6) 55097* varargs implementation: Varargs. (line 6) 55098* variable: Declarations. (line 6) 55099* Variable Location Debug Information in RTL: Debug Information. 55100 (line 6) 55101* VAR_DECL: Declarations. (line 6) 55102* var_location: Debug Information. (line 14) 55103* vashlM3 instruction pattern: Standard Names. (line 780) 55104* vashrM3 instruction pattern: Standard Names. (line 780) 55105* VA_ARG_EXPR: Unary and Binary Expressions. 55106 (line 6) 55107* vcondeqMN instruction pattern: Standard Names. (line 359) 55108* vcondMN instruction pattern: Standard Names. (line 346) 55109* vconduMN instruction pattern: Standard Names. (line 356) 55110* vcond_mask_MN instruction pattern: Standard Names. (line 366) 55111* vector: Containers. (line 6) 55112* vector operations: Vector Operations. (line 6) 55113* VECTOR_CST: Constant expressions. 55114 (line 6) 55115* VECTOR_STORE_FLAG_VALUE: Misc. (line 327) 55116* vec_cmpeqMN instruction pattern: Standard Names. (line 339) 55117* vec_cmpMN instruction pattern: Standard Names. (line 329) 55118* vec_cmpuMN instruction pattern: Standard Names. (line 336) 55119* vec_concat: Vector Operations. (line 29) 55120* VEC_COND_EXPR: Vectors. (line 6) 55121* vec_duplicate: Vector Operations. (line 34) 55122* vec_duplicateM instruction pattern: Standard Names. (line 297) 55123* VEC_DUPLICATE_EXPR: Vectors. (line 6) 55124* vec_extractMN instruction pattern: Standard Names. (line 281) 55125* vec_initMN instruction pattern: Standard Names. (line 290) 55126* vec_load_lanesMN instruction pattern: Standard Names. (line 165) 55127* VEC_LSHIFT_EXPR: Vectors. (line 6) 55128* vec_mask_load_lanesMN instruction pattern: Standard Names. (line 189) 55129* vec_mask_store_lanesMN instruction pattern: Standard Names. 55130 (line 219) 55131* vec_merge: Vector Operations. (line 11) 55132* vec_packs_float_M instruction pattern: Standard Names. (line 606) 55133* vec_packu_float_M instruction pattern: Standard Names. (line 606) 55134* VEC_PACK_FIX_TRUNC_EXPR: Vectors. (line 6) 55135* VEC_PACK_FLOAT_EXPR: Vectors. (line 6) 55136* VEC_PACK_SAT_EXPR: Vectors. (line 6) 55137* vec_pack_sbool_trunc_M instruction pattern: Standard Names. 55138 (line 583) 55139* vec_pack_sfix_trunc_M instruction pattern: Standard Names. (line 599) 55140* vec_pack_ssat_M instruction pattern: Standard Names. (line 592) 55141* VEC_PACK_TRUNC_EXPR: Vectors. (line 6) 55142* vec_pack_trunc_M instruction pattern: Standard Names. (line 576) 55143* vec_pack_ufix_trunc_M instruction pattern: Standard Names. (line 599) 55144* vec_pack_usat_M instruction pattern: Standard Names. (line 592) 55145* vec_permM instruction pattern: Standard Names. (line 384) 55146* vec_permM instruction pattern <1>: Addressing Modes. (line 330) 55147* VEC_RSHIFT_EXPR: Vectors. (line 6) 55148* vec_select: Vector Operations. (line 19) 55149* vec_series: Vector Operations. (line 41) 55150* vec_seriesM instruction pattern: Standard Names. (line 307) 55151* VEC_SERIES_EXPR: Vectors. (line 6) 55152* vec_setM instruction pattern: Standard Names. (line 276) 55153* vec_shl_insert_M instruction pattern: Standard Names. (line 563) 55154* vec_shr_M instruction pattern: Standard Names. (line 570) 55155* vec_store_lanesMN instruction pattern: Standard Names. (line 206) 55156* vec_unpacks_float_hi_M instruction pattern: Standard Names. 55157 (line 636) 55158* vec_unpacks_float_lo_M instruction pattern: Standard Names. 55159 (line 636) 55160* vec_unpacks_hi_M instruction pattern: Standard Names. (line 613) 55161* vec_unpacks_lo_M instruction pattern: Standard Names. (line 613) 55162* vec_unpacks_sbool_hi_M instruction pattern: Standard Names. 55163 (line 627) 55164* vec_unpacks_sbool_lo_M instruction pattern: Standard Names. 55165 (line 627) 55166* vec_unpacku_float_hi_M instruction pattern: Standard Names. 55167 (line 636) 55168* vec_unpacku_float_lo_M instruction pattern: Standard Names. 55169 (line 636) 55170* vec_unpacku_hi_M instruction pattern: Standard Names. (line 620) 55171* vec_unpacku_lo_M instruction pattern: Standard Names. (line 620) 55172* VEC_UNPACK_FIX_TRUNC_HI_EXPR: Vectors. (line 6) 55173* VEC_UNPACK_FIX_TRUNC_LO_EXPR: Vectors. (line 6) 55174* VEC_UNPACK_FLOAT_HI_EXPR: Vectors. (line 6) 55175* VEC_UNPACK_FLOAT_LO_EXPR: Vectors. (line 6) 55176* VEC_UNPACK_HI_EXPR: Vectors. (line 6) 55177* VEC_UNPACK_LO_EXPR: Vectors. (line 6) 55178* vec_unpack_sfix_trunc_hi_M instruction pattern: Standard Names. 55179 (line 645) 55180* vec_unpack_sfix_trunc_lo_M instruction pattern: Standard Names. 55181 (line 645) 55182* vec_unpack_ufix_trunc_hi_M instruction pattern: Standard Names. 55183 (line 645) 55184* vec_unpack_ufix_trunc_lo_M instruction pattern: Standard Names. 55185 (line 645) 55186* VEC_WIDEN_MULT_HI_EXPR: Vectors. (line 6) 55187* VEC_WIDEN_MULT_LO_EXPR: Vectors. (line 6) 55188* vec_widen_smult_even_M instruction pattern: Standard Names. 55189 (line 655) 55190* vec_widen_smult_hi_M instruction pattern: Standard Names. (line 655) 55191* vec_widen_smult_lo_M instruction pattern: Standard Names. (line 655) 55192* vec_widen_smult_odd_M instruction pattern: Standard Names. (line 655) 55193* vec_widen_sshiftl_hi_M instruction pattern: Standard Names. 55194 (line 666) 55195* vec_widen_sshiftl_lo_M instruction pattern: Standard Names. 55196 (line 666) 55197* vec_widen_umult_even_M instruction pattern: Standard Names. 55198 (line 655) 55199* vec_widen_umult_hi_M instruction pattern: Standard Names. (line 655) 55200* vec_widen_umult_lo_M instruction pattern: Standard Names. (line 655) 55201* vec_widen_umult_odd_M instruction pattern: Standard Names. (line 655) 55202* vec_widen_ushiftl_hi_M instruction pattern: Standard Names. 55203 (line 666) 55204* vec_widen_ushiftl_lo_M instruction pattern: Standard Names. 55205 (line 666) 55206* verify_flow_info: Maintaining the CFG. 55207 (line 116) 55208* virtual operands: SSA Operands. (line 6) 55209* VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59) 55210* VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87) 55211* VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78) 55212* VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69) 55213* VLIW: Processor pipeline description. 55214 (line 6) 55215* VLIW <1>: Processor pipeline description. 55216 (line 223) 55217* vlshrM3 instruction pattern: Standard Names. (line 780) 55218* VMS: Filesystem. (line 37) 55219* VMS_DEBUGGING_INFO: VMS Debug. (line 8) 55220* VOIDmode: Machine Modes. (line 192) 55221* VOID_TYPE: Types. (line 6) 55222* volatil: Flags. (line 339) 55223* volatil, in insn, call_insn, jump_insn, code_label, jump_table_data, barrier, and note: Flags. 55224 (line 33) 55225* volatil, in label_ref and reg_label: Flags. (line 54) 55226* volatil, in mem, asm_operands, and asm_input: Flags. (line 65) 55227* volatil, in reg: Flags. (line 106) 55228* volatil, in subreg: Flags. (line 184) 55229* volatil, in subreg <1>: Flags. (line 194) 55230* volatil, in symbol_ref: Flags. (line 220) 55231* volatile memory references: Flags. (line 340) 55232* volatile, in prefetch: Flags. (line 92) 55233* voting between constraint alternatives: Class Preferences. (line 6) 55234* vrotlM3 instruction pattern: Standard Names. (line 780) 55235* vrotrM3 instruction pattern: Standard Names. (line 780) 55236* walk_dominator_tree: SSA. (line 195) 55237* walk_gimple_op: Statement and operand traversals. 55238 (line 30) 55239* walk_gimple_seq: Statement and operand traversals. 55240 (line 47) 55241* walk_gimple_stmt: Statement and operand traversals. 55242 (line 10) 55243* WCHAR_TYPE: Type Layout. (line 165) 55244* WCHAR_TYPE_SIZE: Type Layout. (line 173) 55245* which_alternative: Output Statement. (line 58) 55246* WHILE_BODY: Statements for C++. (line 6) 55247* WHILE_COND: Statements for C++. (line 6) 55248* WHILE_STMT: Statements for C++. (line 6) 55249* while_ultMN instruction pattern: Standard Names. (line 319) 55250* whopr: LTO. (line 6) 55251* widen_ssumM3 instruction pattern: Standard Names. (line 556) 55252* widen_usumM3 instruction pattern: Standard Names. (line 557) 55253* WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 110) 55254* window_save instruction pattern: Standard Names. (line 1990) 55255* WINT_TYPE: Type Layout. (line 178) 55256* WORDS_BIG_ENDIAN: Storage Layout. (line 28) 55257* WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 225) 55258* word_mode: Machine Modes. (line 458) 55259* WORD_REGISTER_OPERATIONS: Misc. (line 53) 55260* wpa: LTO. (line 6) 55261* X in constraint: Simple Constraints. (line 122) 55262* x-HOST: Host Fragment. (line 6) 55263* XCmode: Machine Modes. (line 199) 55264* XCOFF_DEBUGGING_INFO: DBX Options. (line 12) 55265* XEXP: Accessors. (line 6) 55266* XFmode: Machine Modes. (line 82) 55267* XImode: Machine Modes. (line 54) 55268* XINT: Accessors. (line 6) 55269* xm-MACHINE.h: Filesystem. (line 6) 55270* xm-MACHINE.h <1>: Host Misc. (line 6) 55271* xor: Arithmetic. (line 168) 55272* xor, canonicalization of: Insn Canonicalizations. 55273 (line 94) 55274* xorM3 instruction pattern: Standard Names. (line 416) 55275* xorsignM3 instruction pattern: Standard Names. (line 1085) 55276* XSTR: Accessors. (line 6) 55277* XVEC: Accessors. (line 38) 55278* XVECEXP: Accessors. (line 45) 55279* XVECLEN: Accessors. (line 41) 55280* XWINT: Accessors. (line 6) 55281* zero_extend: Conversions. (line 28) 55282* zero_extendMN2 instruction pattern: Standard Names. (line 1350) 55283* zero_extract: Bit-Fields. (line 30) 55284* zero_extract, canonicalization of: Insn Canonicalizations. 55285 (line 103) 55286 55287 55288 55289Tag Table: 55290Node: Top1789 55291Node: Contributing5108 55292Node: Portability5838 55293Node: Interface7626 55294Node: Libgcc10667 55295Node: Integer library routines12494 55296Node: Soft float library routines19462 55297Node: Decimal float library routines31400 55298Node: Fixed-point fractional library routines47158 55299Node: Exception handling routines147554 55300Node: Miscellaneous routines148661 55301Node: Languages150781 55302Node: Source Tree152328 55303Node: Configure Terms152910 55304Node: Top Level155866 55305Node: gcc Directory159451 55306Node: Subdirectories160403 55307Node: Configuration162571 55308Node: Config Fragments163291 55309Node: System Config164516 55310Node: Configuration Files165452 55311Node: Build168068 55312Node: Makefile168480 55313Ref: Makefile-Footnote-1175255 55314Ref: Makefile-Footnote-2175402 55315Node: Library Files175476 55316Node: Headers176038 55317Node: Documentation178121 55318Node: Texinfo Manuals178980 55319Node: Man Page Generation181309 55320Node: Miscellaneous Docs183222 55321Node: Front End184609 55322Node: Front End Directory188283 55323Node: Front End Config189599 55324Node: Front End Makefile192435 55325Node: Back End196203 55326Node: Testsuites201089 55327Node: Test Idioms202078 55328Node: Test Directives205476 55329Node: Directives206003 55330Node: Selectors217376 55331Node: Effective-Target Keywords218732 55332Ref: arm_fp_ok229975 55333Ref: arm_neon_ok231057 55334Ref: arm_neon_ok_no_float_abi231226 55335Ref: arm_neonv2_ok231393 55336Ref: arm_fp16_ok231560 55337Ref: arm_neon_fp16_ok231902 55338Ref: arm_vfp3_ok232778 55339Ref: arm_v8_1a_neon_ok233204 55340Ref: arm_v8_2a_fp16_scalar_ok233632 55341Ref: arm_v8_2a_fp16_neon_ok234083 55342Ref: arm_v8_2a_dotprod_neon_ok234558 55343Ref: arm_fp16fml_neon_ok234978 55344Ref: arm_coproc1_ok235820 55345Ref: arm_coproc2_ok235946 55346Ref: arm_coproc3_ok236174 55347Ref: stack_size_et247511 55348Node: Add Options249954 55349Ref: arm_fp16_ieee250972 55350Ref: arm_fp16_alternative251227 55351Ref: stack_size_ao253478 55352Node: Require Support253840 55353Node: Final Actions256669 55354Node: Ada Tests262408 55355Node: C Tests263571 55356Node: LTO Testing267943 55357Node: gcov Testing269586 55358Node: profopt Testing272556 55359Node: compat Testing274271 55360Node: Torture Tests278511 55361Node: GIMPLE Tests280145 55362Node: RTL Tests281387 55363Node: Options282693 55364Node: Option file format283134 55365Node: Option properties290123 55366Node: Passes306193 55367Node: Parsing pass307009 55368Node: Gimplification pass310537 55369Node: Pass manager312370 55370Node: Tree SSA passes314216 55371Node: RTL passes335758 55372Node: Optimization info348022 55373Node: Dump setup348841 55374Node: Optimization groups349970 55375Node: Dump files and streams350949 55376Node: Dump output verbosity352147 55377Node: Dump types353203 55378Node: Dump examples355545 55379Node: poly_int357026 55380Node: Overview of poly_int358506 55381Node: Consequences of using poly_int361110 55382Node: Comparisons involving poly_int362745 55383Node: Comparison functions for poly_int364383 55384Node: Properties of the poly_int comparisons365590 55385Node: Comparing potentially-unordered poly_ints368032 55386Node: Comparing ordered poly_ints368943 55387Node: Checking for a poly_int marker value370967 55388Node: Range checks on poly_ints371816 55389Node: Sorting poly_ints374470 55390Node: Arithmetic on poly_ints375243 55391Node: Using poly_int with C++ arithmetic operators376044 55392Node: wi arithmetic on poly_ints377575 55393Node: Division of poly_ints378427 55394Node: Other poly_int arithmetic379934 55395Node: Alignment of poly_ints381340 55396Node: Computing bounds on poly_ints384617 55397Node: Converting poly_ints385398 55398Node: Miscellaneous poly_int routines388945 55399Node: Guidelines for using poly_int389585 55400Node: GENERIC394517 55401Node: Deficiencies396395 55402Node: Tree overview396636 55403Node: Macros and Functions400760 55404Node: Identifiers401585 55405Node: Containers403194 55406Node: Types404351 55407Node: Declarations416425 55408Node: Working with declarations416920 55409Node: Internal structure422524 55410Node: Current structure hierarchy422908 55411Node: Adding new DECL node types425001 55412Node: Attributes429285 55413Node: Expression trees430529 55414Node: Constant expressions432283 55415Node: Storage References438375 55416Node: Unary and Binary Expressions441894 55417Node: Vectors462750 55418Node: Statements469654 55419Node: Basic Statements470186 55420Node: Blocks474813 55421Node: Statement Sequences476514 55422Node: Empty Statements476847 55423Node: Jumps477421 55424Node: Cleanups478074 55425Node: OpenMP479841 55426Node: OpenACC485686 55427Node: Functions486727 55428Node: Function Basics487198 55429Node: Function Properties490882 55430Node: Language-dependent trees493663 55431Node: C and C++ Trees494550 55432Node: Types for C++497454 55433Node: Namespaces502424 55434Node: Classes505530 55435Node: Functions for C++510438 55436Node: Statements for C++516689 55437Node: C++ Expressions524742 55438Node: Java Trees526247 55439Node: GIMPLE526360 55440Node: Tuple representation530025 55441Node: Class hierarchy of GIMPLE statements536985 55442Node: GIMPLE instruction set541973 55443Node: GIMPLE Exception Handling543605 55444Node: Temporaries545517 55445Ref: Temporaries-Footnote-1546835 55446Node: Operands546900 55447Node: Compound Expressions547661 55448Node: Compound Lvalues547895 55449Node: Conditional Expressions548657 55450Node: Logical Operators549316 55451Node: Manipulating GIMPLE statements556663 55452Node: Tuple specific accessors562599 55453Node: GIMPLE_ASM563378 55454Node: GIMPLE_ASSIGN565761 55455Node: GIMPLE_BIND570465 55456Node: GIMPLE_CALL572279 55457Node: GIMPLE_CATCH576422 55458Node: GIMPLE_COND577572 55459Node: GIMPLE_DEBUG580367 55460Node: GIMPLE_EH_FILTER584965 55461Node: GIMPLE_LABEL586528 55462Node: GIMPLE_GOTO587141 55463Node: GIMPLE_NOP587664 55464Node: GIMPLE_OMP_ATOMIC_LOAD588026 55465Node: GIMPLE_OMP_ATOMIC_STORE589022 55466Node: GIMPLE_OMP_CONTINUE589721 55467Node: GIMPLE_OMP_CRITICAL591200 55468Node: GIMPLE_OMP_FOR592194 55469Node: GIMPLE_OMP_MASTER595610 55470Node: GIMPLE_OMP_ORDERED595988 55471Node: GIMPLE_OMP_PARALLEL596382 55472Node: GIMPLE_OMP_RETURN599151 55473Node: GIMPLE_OMP_SECTION599796 55474Node: GIMPLE_OMP_SECTIONS600456 55475Node: GIMPLE_OMP_SINGLE602066 55476Node: GIMPLE_PHI603012 55477Node: GIMPLE_RESX604291 55478Node: GIMPLE_RETURN605010 55479Node: GIMPLE_SWITCH605584 55480Node: GIMPLE_TRY607459 55481Node: GIMPLE_WITH_CLEANUP_EXPR609231 55482Node: GIMPLE sequences610110 55483Node: Sequence iterators613316 55484Node: Adding a new GIMPLE statement code621773 55485Node: Statement and operand traversals623118 55486Node: Tree SSA625710 55487Node: Annotations627498 55488Node: SSA Operands627903 55489Node: SSA641978 55490Node: Alias analysis651684 55491Node: Memory model655458 55492Node: RTL656817 55493Node: RTL Objects659005 55494Node: RTL Classes662889 55495Node: Accessors668188 55496Node: Special Accessors670361 55497Node: Flags676148 55498Node: Machine Modes691411 55499Node: Constants708817 55500Node: Regs and Memory720206 55501Node: Arithmetic739458 55502Node: Comparisons749633 55503Node: Bit-Fields753925 55504Node: Vector Operations755476 55505Node: Conversions757580 55506Node: RTL Declarations762078 55507Node: Side Effects762922 55508Node: Incdec780529 55509Node: Assembler783865 55510Node: Debug Information785410 55511Node: Insns787337 55512Node: Calls815193 55513Node: Sharing817786 55514Node: Reading RTL820981 55515Node: Control Flow821972 55516Node: Basic Blocks823740 55517Node: Edges829194 55518Node: Profile information837813 55519Node: Maintaining the CFG842497 55520Node: Liveness information848265 55521Node: Loop Analysis and Representation850391 55522Node: Loop representation851427 55523Node: Loop querying858990 55524Node: Loop manipulation861811 55525Node: LCSSA864147 55526Node: Scalar evolutions866216 55527Node: loop-iv869460 55528Node: Number of iterations871382 55529Node: Dependency analysis875463 55530Node: Machine Desc881814 55531Node: Overview884377 55532Node: Patterns886417 55533Node: Example891384 55534Node: RTL Template892845 55535Node: Output Template903501 55536Node: Output Statement907682 55537Node: Predicates912021 55538Node: Machine-Independent Predicates914939 55539Node: Defining Predicates919883 55540Node: Constraints925846 55541Node: Simple Constraints927315 55542Node: Multi-Alternative940155 55543Node: Class Preferences943364 55544Node: Modifiers944256 55545Node: Machine Constraints948989 55546Node: Disable Insn Alternatives1015440 55547Node: Define Constraints1018932 55548Node: C Constraint Interface1026326 55549Node: Standard Names1029453 55550Ref: shift patterns1063322 55551Ref: prologue instruction pattern1116169 55552Ref: window_save instruction pattern1116662 55553Ref: epilogue instruction pattern1116939 55554Node: Pattern Ordering1138915 55555Node: Dependent Patterns1140151 55556Node: Jump Patterns1141771 55557Ref: Jump Patterns-Footnote-11143916 55558Node: Looping Patterns1143964 55559Node: Insn Canonicalizations1149603 55560Node: Expander Definitions1154810 55561Node: Insn Splitting1163024 55562Node: Including Patterns1173430 55563Node: Peephole Definitions1175214 55564Node: define_peephole1176467 55565Node: define_peephole21182797 55566Node: Insn Attributes1186886 55567Node: Defining Attributes1188068 55568Ref: define_enum_attr1191560 55569Node: Expressions1192596 55570Node: Tagging Insns1199346 55571Node: Attr Example1203699 55572Node: Insn Lengths1206072 55573Node: Constant Attributes1209480 55574Node: Mnemonic Attribute1210656 55575Node: Delay Slots1212175 55576Node: Processor pipeline description1215398 55577Ref: Processor pipeline description-Footnote-11234210 55578Node: Conditional Execution1234534 55579Node: Define Subst1238017 55580Node: Define Subst Example1240052 55581Node: Define Subst Pattern Matching1243046 55582Node: Define Subst Output Template1244272 55583Node: Constant Definitions1246595 55584Ref: define_enum1250377 55585Node: Iterators1250865 55586Node: Mode Iterators1251510 55587Node: Defining Mode Iterators1252488 55588Node: Substitutions1253982 55589Node: Examples1256224 55590Node: Code Iterators1257672 55591Node: Int Iterators1259951 55592Node: Subst Iterators1262397 55593Node: Parameterized Names1264117 55594Node: Target Macros1267645 55595Node: Target Structure1270708 55596Node: Driver1273200 55597Node: Run-time Target1292170 55598Node: Per-Function Data1302051 55599Node: Storage Layout1304815 55600Node: Type Layout1332314 55601Node: Registers1345655 55602Node: Register Basics1346629 55603Node: Allocation Order1353827 55604Node: Values in Registers1356311 55605Node: Leaf Functions1363787 55606Node: Stack Registers1366646 55607Node: Register Classes1367918 55608Node: Stack and Calling1402700 55609Node: Frame Layout1403306 55610Node: Exception Handling1415141 55611Node: Stack Checking1421351 55612Node: Frame Registers1426976 55613Node: Elimination1435527 55614Node: Stack Arguments1439383 55615Node: Register Arguments1446579 55616Node: Scalar Return1470833 55617Node: Aggregate Return1477289 55618Node: Caller Saves1481843 55619Node: Function Entry1482585 55620Node: Profiling1494137 55621Node: Tail Calls1496247 55622Node: Shrink-wrapping separate components1498157 55623Node: Stack Smashing Protection1501198 55624Node: Miscellaneous Register Hooks1503687 55625Node: Varargs1504552 55626Node: Trampolines1514345 55627Node: Library Calls1523168 55628Node: Addressing Modes1527852 55629Node: Anchored Addresses1554798 55630Node: Condition Code1557441 55631Node: CC0 Condition Codes1559768 55632Node: MODE_CC Condition Codes1563014 55633Node: Costs1569809 55634Node: Scheduling1591180 55635Node: Sections1615102 55636Node: PIC1631321 55637Node: Assembler Format1633380 55638Node: File Framework1634518 55639Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS1642117 55640Node: Data Output1645387 55641Node: Uninitialized Data1653675 55642Node: Label Output1658689 55643Node: Initialization1683300 55644Node: Macros for Initialization1689261 55645Node: Instruction Output1695980 55646Node: Dispatch Tables1706609 55647Node: Exception Region Output1712070 55648Node: Alignment Output1719152 55649Node: Debugging Info1722839 55650Node: All Debuggers1723493 55651Node: DBX Options1726265 55652Node: DBX Hooks1731703 55653Node: File Names and DBX1733012 55654Node: DWARF1735116 55655Node: VMS Debug1740931 55656Node: Floating Point1741510 55657Node: Mode Switching1744265 55658Node: Target Attributes1748702 55659Node: Emulated TLS1757668 55660Node: MIPS Coprocessors1761058 55661Node: PCH Target1762217 55662Node: C++ ABI1764059 55663Node: D Language and ABI1768851 55664Node: Named Address Spaces1769896 55665Node: Misc1775823 55666Ref: TARGET_SHIFT_TRUNCATION_MASK1783694 55667Node: Host Config1837530 55668Node: Host Common1838599 55669Node: Filesystem1840973 55670Node: Host Misc1845088 55671Node: Fragments1847537 55672Node: Target Fragment1848732 55673Node: Host Fragment1859544 55674Node: Collect21859784 55675Node: Header Dirs1862420 55676Node: Type Information1863843 55677Node: GTY Options1867119 55678Node: Inheritance and GTY1878377 55679Ref: Inheritance and GTY-Footnote-11879942 55680Node: User GC1880212 55681Node: GGC Roots1883951 55682Node: Files1884664 55683Node: Invoking the garbage collector1887371 55684Node: Troubleshooting1888876 55685Node: Plugins1889951 55686Node: Plugins loading1891080 55687Node: Plugin API1892179 55688Node: Plugins pass1899905 55689Node: Plugins GC1901876 55690Node: Plugins description1903593 55691Node: Plugins attr1904129 55692Node: Plugins recording1906409 55693Node: Plugins gate1907259 55694Node: Plugins tracking1907850 55695Node: Plugins building1908438 55696Node: LTO1911939 55697Node: LTO Overview1912811 55698Node: LTO object file layout1918638 55699Node: IPA1923268 55700Node: WHOPR1932232 55701Node: Internal flags1936792 55702Node: Match and Simplify1938203 55703Node: GIMPLE API1939176 55704Node: The Language1941971 55705Node: User Experience Guidelines1953828 55706Node: Guidelines for Diagnostics1954767 55707Ref: input_location_example1961828 55708Node: Guidelines for Options1971511 55709Node: Funding1971688 55710Node: GNU Project1974195 55711Node: Copying1974844 55712Node: GNU Free Documentation License2012356 55713Node: Contributors2037477 55714Node: Option Index2078453 55715Node: Concept Index2079330 55716 55717End Tag Table 55718