1This is gccint.info, produced by makeinfo version 6.7 from gccint.texi. 2 3Copyright (C) 1988-2018 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-2018 Free Software Foundation, Inc. 30 31 Permission is granted to copy, distribute and/or modify this document 32under the terms of the GNU Free Documentation License, Version 1.3 or 33any later version published by the Free Software Foundation; with the 34Invariant Sections being "Funding Free Software", the Front-Cover Texts 35being (a) (see below), and with the Back-Cover Texts being (b) (see 36below). A copy of the license is included in the section entitled "GNU 37Free Documentation License". 38 39 (a) The FSF's Front-Cover Text is: 40 41 A GNU Manual 42 43 (b) The FSF's Back-Cover Text is: 44 45 You have freedom to copy and modify this GNU Manual, like GNU software. 46Copies published by the Free Software Foundation raise funds for GNU 47development. 48 49 50File: gccint.info, Node: Top, Next: Contributing, Up: (dir) 51 52Introduction 53************ 54 55This manual documents the internals of the GNU compilers, including how 56to port them to new targets and some information about how to write 57front ends for new languages. It corresponds to the compilers (GCC) 58version 8.5.0. The use of the GNU compilers is documented in a separate 59manual. *Note Introduction: (gcc)Top. 60 61 This manual is mainly a reference manual rather than a tutorial. It 62discusses how to contribute to GCC (*note Contributing::), the 63characteristics of the machines supported by GCC as hosts and targets 64(*note Portability::), how GCC relates to the ABIs on such systems 65(*note Interface::), and the characteristics of the languages for which 66GCC front ends are written (*note Languages::). It then describes the 67GCC source tree structure and build system, some of the interfaces to 68GCC front ends, and how support for a target system is implemented in 69GCC. 70 71 Additional tutorial information is linked to from 72<http://gcc.gnu.org/readings.html>. 73 74* Menu: 75 76* Contributing:: How to contribute to testing and developing GCC. 77* Portability:: Goals of GCC's portability features. 78* Interface:: Function-call interface of GCC output. 79* Libgcc:: Low-level runtime library used by GCC. 80* Languages:: Languages for which GCC front ends are written. 81* Source Tree:: GCC source tree structure and build system. 82* Testsuites:: GCC testsuites. 83* Options:: Option specification files. 84* Passes:: Order of passes, what they do, and what each file is for. 85* 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* Funding:: How to help assure funding for free software. 104* GNU Project:: The GNU Project and GNU/Linux. 105 106* Copying:: GNU General Public License says 107 how you can copy and share GCC. 108* GNU Free Documentation License:: How you can copy and share this manual. 109* Contributors:: People who have contributed to GCC. 110 111* Option Index:: Index to command line options. 112* Concept Index:: Index of concepts and symbol names. 113 114 115File: gccint.info, Node: Contributing, Next: Portability, Up: Top 116 1171 Contributing to GCC Development 118********************************* 119 120If you would like to help pretest GCC releases to assure they work well, 121current development sources are available via Git (see 122<http://gcc.gnu.org/git.html>). Source and binary snapshots are also 123available for FTP; see <http://gcc.gnu.org/snapshots.html>. 124 125 If you would like to work on improvements to GCC, please read the 126advice at these URLs: 127 128 <http://gcc.gnu.org/contribute.html> 129 <http://gcc.gnu.org/contributewhy.html> 130 131for information on how to make useful contributions and avoid 132duplication of effort. Suggested projects are listed at 133<http://gcc.gnu.org/projects/>. 134 135 136File: gccint.info, Node: Portability, Next: Interface, Prev: Contributing, Up: Top 137 1382 GCC and Portability 139********************* 140 141GCC itself aims to be portable to any machine where 'int' is at least a 14232-bit type. It aims to target machines with a flat (non-segmented) 143byte addressed data address space (the code address space can be 144separate). Target ABIs may have 8, 16, 32 or 64-bit 'int' type. 'char' 145can be wider than 8 bits. 146 147 GCC gets most of the information about the target machine from a 148machine description which gives an algebraic formula for each of the 149machine's instructions. This is a very clean way to describe the 150target. But when the compiler needs information that is difficult to 151express in this fashion, ad-hoc parameters have been defined for machine 152descriptions. The purpose of portability is to reduce the total work 153needed on the compiler; it was not of interest for its own sake. 154 155 GCC does not contain machine dependent code, but it does contain code 156that depends on machine parameters such as endianness (whether the most 157significant byte has the highest or lowest address of the bytes in a 158word) and the availability of autoincrement addressing. In the 159RTL-generation pass, it is often necessary to have multiple strategies 160for generating code for a particular kind of syntax tree, strategies 161that are usable for different combinations of parameters. Often, not 162all possible cases have been addressed, but only the common ones or only 163the ones that have been encountered. As a result, a new target may 164require additional strategies. You will know if this happens because 165the compiler will call 'abort'. Fortunately, the new strategies can be 166added in a machine-independent fashion, and will affect only the target 167machines that need them. 168 169 170File: gccint.info, Node: Interface, Next: Libgcc, Prev: Portability, Up: Top 171 1723 Interfacing to GCC Output 173*************************** 174 175GCC is normally configured to use the same function calling convention 176normally in use on the target system. This is done with the 177machine-description macros described (*note Target Macros::). 178 179 However, returning of structure and union values is done differently on 180some target machines. As a result, functions compiled with PCC 181returning such types cannot be called from code compiled with GCC, and 182vice versa. This does not cause trouble often because few Unix library 183routines return structures or unions. 184 185 GCC code returns structures and unions that are 1, 2, 4 or 8 bytes long 186in the same registers used for 'int' or 'double' return values. (GCC 187typically allocates variables of such types in registers also.) 188Structures and unions of other sizes are returned by storing them into 189an address passed by the caller (usually in a register). The target 190hook 'TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address. 191 192 By contrast, PCC on most target machines returns structures and unions 193of any size by copying the data into an area of static storage, and then 194returning the address of that storage as if it were a pointer value. 195The caller must copy the data from that memory area to the place where 196the value is wanted. This is slower than the method used by GCC, and 197fails to be reentrant. 198 199 On some target machines, such as RISC machines and the 80386, the 200standard system convention is to pass to the subroutine the address of 201where to return the value. On these machines, GCC has been configured 202to be compatible with the standard compiler, when this method is used. 203It may not be compatible for structures of 1, 2, 4 or 8 bytes. 204 205 GCC uses the system's standard convention for passing arguments. On 206some machines, the first few arguments are passed in registers; in 207others, all are passed on the stack. It would be possible to use 208registers for argument passing on any machine, and this would probably 209result in a significant speedup. But the result would be complete 210incompatibility with code that follows the standard convention. So this 211change is practical only if you are switching to GCC as the sole C 212compiler for the system. We may implement register argument passing on 213certain machines once we have a complete GNU system so that we can 214compile the libraries with GCC. 215 216 On some machines (particularly the SPARC), certain types of arguments 217are passed "by invisible reference". This means that the value is 218stored in memory, and the address of the memory location is passed to 219the subroutine. 220 221 If you use 'longjmp', beware of automatic variables. ISO C says that 222automatic variables that are not declared 'volatile' have undefined 223values after a 'longjmp'. And this is all GCC promises to do, because 224it is very difficult to restore register variables correctly, and one of 225GCC's features is that it can put variables in registers without your 226asking it to. 227 228 229File: gccint.info, Node: Libgcc, Next: Languages, Prev: Interface, Up: Top 230 2314 The GCC low-level runtime library 232*********************************** 233 234GCC provides a low-level runtime library, 'libgcc.a' or 'libgcc_s.so.1' 235on some platforms. GCC generates calls to routines in this library 236automatically, whenever it needs to perform some operation that is too 237complicated to emit inline code for. 238 239 Most of the routines in 'libgcc' handle arithmetic operations that the 240target processor cannot perform directly. This includes integer 241multiply and divide on some machines, and all floating-point and 242fixed-point operations on other machines. 'libgcc' also includes 243routines for exception handling, and a handful of miscellaneous 244operations. 245 246 Some of these routines can be defined in mostly machine-independent C. 247Others must be hand-written in assembly language for each processor that 248needs them. 249 250 GCC will also generate calls to C library routines, such as 'memcpy' 251and 'memset', in some cases. The set of routines that GCC may possibly 252use is documented in *note (gcc)Other Builtins::. 253 254 These routines take arguments and return values of a specific machine 255mode, not a specific C type. *Note Machine Modes::, for an explanation 256of this concept. For illustrative purposes, in this chapter the 257floating point type 'float' is assumed to correspond to 'SFmode'; 258'double' to 'DFmode'; and 'long double' to both 'TFmode' and 'XFmode'. 259Similarly, the integer types 'int' and 'unsigned int' correspond to 260'SImode'; 'long' and 'unsigned long' to 'DImode'; and 'long long' and 261'unsigned long long' to 'TImode'. 262 263* Menu: 264 265* Integer library routines:: 266* Soft float library routines:: 267* Decimal float library routines:: 268* Fixed-point fractional library routines:: 269* Exception handling routines:: 270* Miscellaneous routines:: 271 272 273File: gccint.info, Node: Integer library routines, Next: Soft float library routines, Up: Libgcc 274 2754.1 Routines for integer arithmetic 276=================================== 277 278The integer arithmetic routines are used on platforms that don't provide 279hardware support for arithmetic operations on some modes. 280 2814.1.1 Arithmetic functions 282-------------------------- 283 284 -- Runtime Function: int __ashlsi3 (int A, int B) 285 -- Runtime Function: long __ashldi3 (long A, int B) 286 -- Runtime Function: long long __ashlti3 (long long A, int B) 287 These functions return the result of shifting A left by B bits. 288 289 -- Runtime Function: int __ashrsi3 (int A, int B) 290 -- Runtime Function: long __ashrdi3 (long A, int B) 291 -- Runtime Function: long long __ashrti3 (long long A, int B) 292 These functions return the result of arithmetically shifting A 293 right by B bits. 294 295 -- Runtime Function: int __divsi3 (int A, int B) 296 -- Runtime Function: long __divdi3 (long A, long B) 297 -- Runtime Function: long long __divti3 (long long A, long long B) 298 These functions return the quotient of the signed division of A and 299 B. 300 301 -- Runtime Function: int __lshrsi3 (int A, int B) 302 -- Runtime Function: long __lshrdi3 (long A, int B) 303 -- Runtime Function: long long __lshrti3 (long long A, int B) 304 These functions return the result of logically shifting A right by 305 B bits. 306 307 -- Runtime Function: int __modsi3 (int A, int B) 308 -- Runtime Function: long __moddi3 (long A, long B) 309 -- Runtime Function: long long __modti3 (long long A, long long B) 310 These functions return the remainder of the signed division of A 311 and B. 312 313 -- Runtime Function: int __mulsi3 (int A, int B) 314 -- Runtime Function: long __muldi3 (long A, long B) 315 -- Runtime Function: long long __multi3 (long long A, long long B) 316 These functions return the product of A and B. 317 318 -- Runtime Function: long __negdi2 (long A) 319 -- Runtime Function: long long __negti2 (long long A) 320 These functions return the negation of A. 321 322 -- Runtime Function: unsigned int __udivsi3 (unsigned int A, unsigned 323 int B) 324 -- Runtime Function: unsigned long __udivdi3 (unsigned long A, unsigned 325 long B) 326 -- Runtime Function: unsigned long long __udivti3 (unsigned long long 327 A, unsigned long long B) 328 These functions return the quotient of the unsigned division of A 329 and B. 330 331 -- Runtime Function: unsigned long __udivmoddi4 (unsigned long A, 332 unsigned long B, unsigned long *C) 333 -- Runtime Function: unsigned long long __udivmodti4 (unsigned long 334 long A, unsigned long long B, unsigned long long *C) 335 These functions calculate both the quotient and remainder of the 336 unsigned division of A and B. The return value is the quotient, 337 and the remainder is placed in variable pointed to by C. 338 339 -- Runtime Function: unsigned int __umodsi3 (unsigned int A, unsigned 340 int B) 341 -- Runtime Function: unsigned long __umoddi3 (unsigned long A, unsigned 342 long B) 343 -- Runtime Function: unsigned long long __umodti3 (unsigned long long 344 A, unsigned long long B) 345 These functions return the remainder of the unsigned division of A 346 and B. 347 3484.1.2 Comparison functions 349-------------------------- 350 351The following functions implement integral comparisons. These functions 352implement a low-level compare, upon which the higher level comparison 353operators (such as less than and greater than or equal to) can be 354constructed. The returned values lie in the range zero to two, to allow 355the high-level operators to be implemented by testing the returned 356result using either signed or unsigned comparison. 357 358 -- Runtime Function: int __cmpdi2 (long A, long B) 359 -- Runtime Function: int __cmpti2 (long long A, long long B) 360 These functions perform a signed comparison of A and B. If A is 361 less than B, they return 0; if A is greater than B, they return 2; 362 and if A and B are equal they return 1. 363 364 -- Runtime Function: int __ucmpdi2 (unsigned long A, unsigned long B) 365 -- Runtime Function: int __ucmpti2 (unsigned long long A, unsigned long 366 long B) 367 These functions perform an unsigned comparison of A and B. If A is 368 less than B, they return 0; if A is greater than B, they return 2; 369 and if A and B are equal they return 1. 370 3714.1.3 Trapping arithmetic functions 372----------------------------------- 373 374The following functions implement trapping arithmetic. These functions 375call the libc function 'abort' upon signed arithmetic overflow. 376 377 -- Runtime Function: int __absvsi2 (int A) 378 -- Runtime Function: long __absvdi2 (long A) 379 These functions return the absolute value of A. 380 381 -- Runtime Function: int __addvsi3 (int A, int B) 382 -- Runtime Function: long __addvdi3 (long A, long B) 383 These functions return the sum of A and B; that is 'A + B'. 384 385 -- Runtime Function: int __mulvsi3 (int A, int B) 386 -- Runtime Function: long __mulvdi3 (long A, long B) 387 The functions return the product of A and B; that is 'A * B'. 388 389 -- Runtime Function: int __negvsi2 (int A) 390 -- Runtime Function: long __negvdi2 (long A) 391 These functions return the negation of A; that is '-A'. 392 393 -- Runtime Function: int __subvsi3 (int A, int B) 394 -- Runtime Function: long __subvdi3 (long A, long B) 395 These functions return the difference between B and A; that is 'A - 396 B'. 397 3984.1.4 Bit operations 399-------------------- 400 401 -- Runtime Function: int __clzsi2 (unsigned int A) 402 -- Runtime Function: int __clzdi2 (unsigned long A) 403 -- Runtime Function: int __clzti2 (unsigned long long A) 404 These functions return the number of leading 0-bits in A, starting 405 at the most significant bit position. If A is zero, the result is 406 undefined. 407 408 -- Runtime Function: int __ctzsi2 (unsigned int A) 409 -- Runtime Function: int __ctzdi2 (unsigned long A) 410 -- Runtime Function: int __ctzti2 (unsigned long long A) 411 These functions return the number of trailing 0-bits in A, starting 412 at the least significant bit position. If A is zero, the result is 413 undefined. 414 415 -- Runtime Function: int __ffsdi2 (unsigned long A) 416 -- Runtime Function: int __ffsti2 (unsigned long long A) 417 These functions return the index of the least significant 1-bit in 418 A, or the value zero if A is zero. The least significant bit is 419 index one. 420 421 -- Runtime Function: int __paritysi2 (unsigned int A) 422 -- Runtime Function: int __paritydi2 (unsigned long A) 423 -- Runtime Function: int __parityti2 (unsigned long long A) 424 These functions return the value zero if the number of bits set in 425 A is even, and the value one otherwise. 426 427 -- Runtime Function: int __popcountsi2 (unsigned int A) 428 -- Runtime Function: int __popcountdi2 (unsigned long A) 429 -- Runtime Function: int __popcountti2 (unsigned long long A) 430 These functions return the number of bits set in A. 431 432 -- Runtime Function: int32_t __bswapsi2 (int32_t A) 433 -- Runtime Function: int64_t __bswapdi2 (int64_t A) 434 These functions return the A byteswapped. 435 436 437File: gccint.info, Node: Soft float library routines, Next: Decimal float library routines, Prev: Integer library routines, Up: Libgcc 438 4394.2 Routines for floating point emulation 440========================================= 441 442The software floating point library is used on machines which do not 443have hardware support for floating point. It is also used whenever 444'-msoft-float' is used to disable generation of floating point 445instructions. (Not all targets support this switch.) 446 447 For compatibility with other compilers, the floating point emulation 448routines can be renamed with the 'DECLARE_LIBRARY_RENAMES' macro (*note 449Library Calls::). In this section, the default names are used. 450 451 Presently the library does not support 'XFmode', which is used for 452'long double' on some architectures. 453 4544.2.1 Arithmetic functions 455-------------------------- 456 457 -- Runtime Function: float __addsf3 (float A, float B) 458 -- Runtime Function: double __adddf3 (double A, double B) 459 -- Runtime Function: long double __addtf3 (long double A, long double 460 B) 461 -- Runtime Function: long double __addxf3 (long double A, long double 462 B) 463 These functions return the sum of A and B. 464 465 -- Runtime Function: float __subsf3 (float A, float B) 466 -- Runtime Function: double __subdf3 (double A, double B) 467 -- Runtime Function: long double __subtf3 (long double A, long double 468 B) 469 -- Runtime Function: long double __subxf3 (long double A, long double 470 B) 471 These functions return the difference between B and A; that is, 472 A - B. 473 474 -- Runtime Function: float __mulsf3 (float A, float B) 475 -- Runtime Function: double __muldf3 (double A, double B) 476 -- Runtime Function: long double __multf3 (long double A, long double 477 B) 478 -- Runtime Function: long double __mulxf3 (long double A, long double 479 B) 480 These functions return the product of A and B. 481 482 -- Runtime Function: float __divsf3 (float A, float B) 483 -- Runtime Function: double __divdf3 (double A, double B) 484 -- Runtime Function: long double __divtf3 (long double A, long double 485 B) 486 -- Runtime Function: long double __divxf3 (long double A, long double 487 B) 488 These functions return the quotient of A and B; that is, A / B. 489 490 -- Runtime Function: float __negsf2 (float A) 491 -- Runtime Function: double __negdf2 (double A) 492 -- Runtime Function: long double __negtf2 (long double A) 493 -- Runtime Function: long double __negxf2 (long double A) 494 These functions return the negation of A. They simply flip the 495 sign bit, so they can produce negative zero and negative NaN. 496 4974.2.2 Conversion functions 498-------------------------- 499 500 -- Runtime Function: double __extendsfdf2 (float A) 501 -- Runtime Function: long double __extendsftf2 (float A) 502 -- Runtime Function: long double __extendsfxf2 (float A) 503 -- Runtime Function: long double __extenddftf2 (double A) 504 -- Runtime Function: long double __extenddfxf2 (double A) 505 These functions extend A to the wider mode of their return type. 506 507 -- Runtime Function: double __truncxfdf2 (long double A) 508 -- Runtime Function: double __trunctfdf2 (long double A) 509 -- Runtime Function: float __truncxfsf2 (long double A) 510 -- Runtime Function: float __trunctfsf2 (long double A) 511 -- Runtime Function: float __truncdfsf2 (double A) 512 These functions truncate A to the narrower mode of their return 513 type, rounding toward zero. 514 515 -- Runtime Function: int __fixsfsi (float A) 516 -- Runtime Function: int __fixdfsi (double A) 517 -- Runtime Function: int __fixtfsi (long double A) 518 -- Runtime Function: int __fixxfsi (long double A) 519 These functions convert A to a signed integer, rounding toward 520 zero. 521 522 -- Runtime Function: long __fixsfdi (float A) 523 -- Runtime Function: long __fixdfdi (double A) 524 -- Runtime Function: long __fixtfdi (long double A) 525 -- Runtime Function: long __fixxfdi (long double A) 526 These functions convert A to a signed long, rounding toward zero. 527 528 -- Runtime Function: long long __fixsfti (float A) 529 -- Runtime Function: long long __fixdfti (double A) 530 -- Runtime Function: long long __fixtfti (long double A) 531 -- Runtime Function: long long __fixxfti (long double A) 532 These functions convert A to a signed long long, rounding toward 533 zero. 534 535 -- Runtime Function: unsigned int __fixunssfsi (float A) 536 -- Runtime Function: unsigned int __fixunsdfsi (double A) 537 -- Runtime Function: unsigned int __fixunstfsi (long double A) 538 -- Runtime Function: unsigned int __fixunsxfsi (long double A) 539 These functions convert A to an unsigned integer, rounding toward 540 zero. Negative values all become zero. 541 542 -- Runtime Function: unsigned long __fixunssfdi (float A) 543 -- Runtime Function: unsigned long __fixunsdfdi (double A) 544 -- Runtime Function: unsigned long __fixunstfdi (long double A) 545 -- Runtime Function: unsigned long __fixunsxfdi (long double A) 546 These functions convert A to an unsigned long, rounding toward 547 zero. Negative values all become zero. 548 549 -- Runtime Function: unsigned long long __fixunssfti (float A) 550 -- Runtime Function: unsigned long long __fixunsdfti (double A) 551 -- Runtime Function: unsigned long long __fixunstfti (long double A) 552 -- Runtime Function: unsigned long long __fixunsxfti (long double A) 553 These functions convert A to an unsigned long long, rounding toward 554 zero. Negative values all become zero. 555 556 -- Runtime Function: float __floatsisf (int I) 557 -- Runtime Function: double __floatsidf (int I) 558 -- Runtime Function: long double __floatsitf (int I) 559 -- Runtime Function: long double __floatsixf (int I) 560 These functions convert I, a signed integer, to floating point. 561 562 -- Runtime Function: float __floatdisf (long I) 563 -- Runtime Function: double __floatdidf (long I) 564 -- Runtime Function: long double __floatditf (long I) 565 -- Runtime Function: long double __floatdixf (long I) 566 These functions convert I, a signed long, to floating point. 567 568 -- Runtime Function: float __floattisf (long long I) 569 -- Runtime Function: double __floattidf (long long I) 570 -- Runtime Function: long double __floattitf (long long I) 571 -- Runtime Function: long double __floattixf (long long I) 572 These functions convert I, a signed long long, to floating point. 573 574 -- Runtime Function: float __floatunsisf (unsigned int I) 575 -- Runtime Function: double __floatunsidf (unsigned int I) 576 -- Runtime Function: long double __floatunsitf (unsigned int I) 577 -- Runtime Function: long double __floatunsixf (unsigned int I) 578 These functions convert I, an unsigned integer, to floating point. 579 580 -- Runtime Function: float __floatundisf (unsigned long I) 581 -- Runtime Function: double __floatundidf (unsigned long I) 582 -- Runtime Function: long double __floatunditf (unsigned long I) 583 -- Runtime Function: long double __floatundixf (unsigned long I) 584 These functions convert I, an unsigned long, to floating point. 585 586 -- Runtime Function: float __floatuntisf (unsigned long long I) 587 -- Runtime Function: double __floatuntidf (unsigned long long I) 588 -- Runtime Function: long double __floatuntitf (unsigned long long I) 589 -- Runtime Function: long double __floatuntixf (unsigned long long I) 590 These functions convert I, an unsigned long long, to floating 591 point. 592 5934.2.3 Comparison functions 594-------------------------- 595 596There are two sets of basic comparison functions. 597 598 -- Runtime Function: int __cmpsf2 (float A, float B) 599 -- Runtime Function: int __cmpdf2 (double A, double B) 600 -- Runtime Function: int __cmptf2 (long double A, long double B) 601 These functions calculate a <=> b. That is, if A is less than B, 602 they return -1; if A is greater than B, they return 1; and if A and 603 B are equal they return 0. If either argument is NaN they return 604 1, but you should not rely on this; if NaN is a possibility, use 605 one of the higher-level comparison functions. 606 607 -- Runtime Function: int __unordsf2 (float A, float B) 608 -- Runtime Function: int __unorddf2 (double A, double B) 609 -- Runtime Function: int __unordtf2 (long double A, long double B) 610 These functions return a nonzero value if either argument is NaN, 611 otherwise 0. 612 613 There is also a complete group of higher level functions which 614correspond directly to comparison operators. They implement the ISO C 615semantics for floating-point comparisons, taking NaN into account. Pay 616careful attention to the return values defined for each set. Under the 617hood, all of these routines are implemented as 618 619 if (__unordXf2 (a, b)) 620 return E; 621 return __cmpXf2 (a, b); 622 623where E is a constant chosen to give the proper behavior for NaN. Thus, 624the meaning of the return value is different for each set. Do not rely 625on this implementation; only the semantics documented below are 626guaranteed. 627 628 -- Runtime Function: int __eqsf2 (float A, float B) 629 -- Runtime Function: int __eqdf2 (double A, double B) 630 -- Runtime Function: int __eqtf2 (long double A, long double B) 631 These functions return zero if neither argument is NaN, and A and B 632 are equal. 633 634 -- Runtime Function: int __nesf2 (float A, float B) 635 -- Runtime Function: int __nedf2 (double A, double B) 636 -- Runtime Function: int __netf2 (long double A, long double B) 637 These functions return a nonzero value if either argument is NaN, 638 or if A and B are unequal. 639 640 -- Runtime Function: int __gesf2 (float A, float B) 641 -- Runtime Function: int __gedf2 (double A, double B) 642 -- Runtime Function: int __getf2 (long double A, long double B) 643 These functions return a value greater than or equal to zero if 644 neither argument is NaN, and A is greater than or equal to B. 645 646 -- Runtime Function: int __ltsf2 (float A, float B) 647 -- Runtime Function: int __ltdf2 (double A, double B) 648 -- Runtime Function: int __lttf2 (long double A, long double B) 649 These functions return a value less than zero if neither argument 650 is NaN, and A is strictly less than B. 651 652 -- Runtime Function: int __lesf2 (float A, float B) 653 -- Runtime Function: int __ledf2 (double A, double B) 654 -- Runtime Function: int __letf2 (long double A, long double B) 655 These functions return a value less than or equal to zero if 656 neither argument is NaN, and A is less than or equal to B. 657 658 -- Runtime Function: int __gtsf2 (float A, float B) 659 -- Runtime Function: int __gtdf2 (double A, double B) 660 -- Runtime Function: int __gttf2 (long double A, long double B) 661 These functions return a value greater than zero if neither 662 argument is NaN, and A is strictly greater than B. 663 6644.2.4 Other floating-point functions 665------------------------------------ 666 667 -- Runtime Function: float __powisf2 (float A, int B) 668 -- Runtime Function: double __powidf2 (double A, int B) 669 -- Runtime Function: long double __powitf2 (long double A, int B) 670 -- Runtime Function: long double __powixf2 (long double A, int B) 671 These functions convert raise A to the power B. 672 673 -- Runtime Function: complex float __mulsc3 (float A, float B, float C, 674 float D) 675 -- Runtime Function: complex double __muldc3 (double A, double B, 676 double C, double D) 677 -- Runtime Function: complex long double __multc3 (long double A, long 678 double B, long double C, long double D) 679 -- Runtime Function: complex long double __mulxc3 (long double A, long 680 double B, long double C, long double D) 681 These functions return the product of A + iB and C + iD, following 682 the rules of C99 Annex G. 683 684 -- Runtime Function: complex float __divsc3 (float A, float B, float C, 685 float D) 686 -- Runtime Function: complex double __divdc3 (double A, double B, 687 double C, double D) 688 -- Runtime Function: complex long double __divtc3 (long double A, long 689 double B, long double C, long double D) 690 -- Runtime Function: complex long double __divxc3 (long double A, long 691 double B, long double C, long double D) 692 These functions return the quotient of A + iB and C + iD (i.e., (A 693 + iB) / (C + iD)), following the rules of C99 Annex G. 694 695 696File: gccint.info, Node: Decimal float library routines, Next: Fixed-point fractional library routines, Prev: Soft float library routines, Up: Libgcc 697 6984.3 Routines for decimal floating point emulation 699================================================= 700 701The software decimal floating point library implements IEEE 754-2008 702decimal floating point arithmetic and is only activated on selected 703targets. 704 705 The software decimal floating point library supports either DPD 706(Densely Packed Decimal) or BID (Binary Integer Decimal) encoding as 707selected at configure time. 708 7094.3.1 Arithmetic functions 710-------------------------- 711 712 -- Runtime Function: _Decimal32 __dpd_addsd3 (_Decimal32 A, _Decimal32 713 B) 714 -- Runtime Function: _Decimal32 __bid_addsd3 (_Decimal32 A, _Decimal32 715 B) 716 -- Runtime Function: _Decimal64 __dpd_adddd3 (_Decimal64 A, _Decimal64 717 B) 718 -- Runtime Function: _Decimal64 __bid_adddd3 (_Decimal64 A, _Decimal64 719 B) 720 -- Runtime Function: _Decimal128 __dpd_addtd3 (_Decimal128 A, 721 _Decimal128 B) 722 -- Runtime Function: _Decimal128 __bid_addtd3 (_Decimal128 A, 723 _Decimal128 B) 724 These functions return the sum of A and B. 725 726 -- Runtime Function: _Decimal32 __dpd_subsd3 (_Decimal32 A, _Decimal32 727 B) 728 -- Runtime Function: _Decimal32 __bid_subsd3 (_Decimal32 A, _Decimal32 729 B) 730 -- Runtime Function: _Decimal64 __dpd_subdd3 (_Decimal64 A, _Decimal64 731 B) 732 -- Runtime Function: _Decimal64 __bid_subdd3 (_Decimal64 A, _Decimal64 733 B) 734 -- Runtime Function: _Decimal128 __dpd_subtd3 (_Decimal128 A, 735 _Decimal128 B) 736 -- Runtime Function: _Decimal128 __bid_subtd3 (_Decimal128 A, 737 _Decimal128 B) 738 These functions return the difference between B and A; that is, 739 A - B. 740 741 -- Runtime Function: _Decimal32 __dpd_mulsd3 (_Decimal32 A, _Decimal32 742 B) 743 -- Runtime Function: _Decimal32 __bid_mulsd3 (_Decimal32 A, _Decimal32 744 B) 745 -- Runtime Function: _Decimal64 __dpd_muldd3 (_Decimal64 A, _Decimal64 746 B) 747 -- Runtime Function: _Decimal64 __bid_muldd3 (_Decimal64 A, _Decimal64 748 B) 749 -- Runtime Function: _Decimal128 __dpd_multd3 (_Decimal128 A, 750 _Decimal128 B) 751 -- Runtime Function: _Decimal128 __bid_multd3 (_Decimal128 A, 752 _Decimal128 B) 753 These functions return the product of A and B. 754 755 -- Runtime Function: _Decimal32 __dpd_divsd3 (_Decimal32 A, _Decimal32 756 B) 757 -- Runtime Function: _Decimal32 __bid_divsd3 (_Decimal32 A, _Decimal32 758 B) 759 -- Runtime Function: _Decimal64 __dpd_divdd3 (_Decimal64 A, _Decimal64 760 B) 761 -- Runtime Function: _Decimal64 __bid_divdd3 (_Decimal64 A, _Decimal64 762 B) 763 -- Runtime Function: _Decimal128 __dpd_divtd3 (_Decimal128 A, 764 _Decimal128 B) 765 -- Runtime Function: _Decimal128 __bid_divtd3 (_Decimal128 A, 766 _Decimal128 B) 767 These functions return the quotient of A and B; that is, A / B. 768 769 -- Runtime Function: _Decimal32 __dpd_negsd2 (_Decimal32 A) 770 -- Runtime Function: _Decimal32 __bid_negsd2 (_Decimal32 A) 771 -- Runtime Function: _Decimal64 __dpd_negdd2 (_Decimal64 A) 772 -- Runtime Function: _Decimal64 __bid_negdd2 (_Decimal64 A) 773 -- Runtime Function: _Decimal128 __dpd_negtd2 (_Decimal128 A) 774 -- Runtime Function: _Decimal128 __bid_negtd2 (_Decimal128 A) 775 These functions return the negation of A. They simply flip the 776 sign bit, so they can produce negative zero and negative NaN. 777 7784.3.2 Conversion functions 779-------------------------- 780 781 -- Runtime Function: _Decimal64 __dpd_extendsddd2 (_Decimal32 A) 782 -- Runtime Function: _Decimal64 __bid_extendsddd2 (_Decimal32 A) 783 -- Runtime Function: _Decimal128 __dpd_extendsdtd2 (_Decimal32 A) 784 -- Runtime Function: _Decimal128 __bid_extendsdtd2 (_Decimal32 A) 785 -- Runtime Function: _Decimal128 __dpd_extendddtd2 (_Decimal64 A) 786 -- Runtime Function: _Decimal128 __bid_extendddtd2 (_Decimal64 A) 787 -- Runtime Function: _Decimal32 __dpd_truncddsd2 (_Decimal64 A) 788 -- Runtime Function: _Decimal32 __bid_truncddsd2 (_Decimal64 A) 789 -- Runtime Function: _Decimal32 __dpd_trunctdsd2 (_Decimal128 A) 790 -- Runtime Function: _Decimal32 __bid_trunctdsd2 (_Decimal128 A) 791 -- Runtime Function: _Decimal64 __dpd_trunctddd2 (_Decimal128 A) 792 -- Runtime Function: _Decimal64 __bid_trunctddd2 (_Decimal128 A) 793 These functions convert the value A from one decimal floating type 794 to another. 795 796 -- Runtime Function: _Decimal64 __dpd_extendsfdd (float A) 797 -- Runtime Function: _Decimal64 __bid_extendsfdd (float A) 798 -- Runtime Function: _Decimal128 __dpd_extendsftd (float A) 799 -- Runtime Function: _Decimal128 __bid_extendsftd (float A) 800 -- Runtime Function: _Decimal128 __dpd_extenddftd (double A) 801 -- Runtime Function: _Decimal128 __bid_extenddftd (double A) 802 -- Runtime Function: _Decimal128 __dpd_extendxftd (long double A) 803 -- Runtime Function: _Decimal128 __bid_extendxftd (long double A) 804 -- Runtime Function: _Decimal32 __dpd_truncdfsd (double A) 805 -- Runtime Function: _Decimal32 __bid_truncdfsd (double A) 806 -- Runtime Function: _Decimal32 __dpd_truncxfsd (long double A) 807 -- Runtime Function: _Decimal32 __bid_truncxfsd (long double A) 808 -- Runtime Function: _Decimal32 __dpd_trunctfsd (long double A) 809 -- Runtime Function: _Decimal32 __bid_trunctfsd (long double A) 810 -- Runtime Function: _Decimal64 __dpd_truncxfdd (long double A) 811 -- Runtime Function: _Decimal64 __bid_truncxfdd (long double A) 812 -- Runtime Function: _Decimal64 __dpd_trunctfdd (long double A) 813 -- Runtime Function: _Decimal64 __bid_trunctfdd (long double A) 814 These functions convert the value of A from a binary floating type 815 to a decimal floating type of a different size. 816 817 -- Runtime Function: float __dpd_truncddsf (_Decimal64 A) 818 -- Runtime Function: float __bid_truncddsf (_Decimal64 A) 819 -- Runtime Function: float __dpd_trunctdsf (_Decimal128 A) 820 -- Runtime Function: float __bid_trunctdsf (_Decimal128 A) 821 -- Runtime Function: double __dpd_extendsddf (_Decimal32 A) 822 -- Runtime Function: double __bid_extendsddf (_Decimal32 A) 823 -- Runtime Function: double __dpd_trunctddf (_Decimal128 A) 824 -- Runtime Function: double __bid_trunctddf (_Decimal128 A) 825 -- Runtime Function: long double __dpd_extendsdxf (_Decimal32 A) 826 -- Runtime Function: long double __bid_extendsdxf (_Decimal32 A) 827 -- Runtime Function: long double __dpd_extendddxf (_Decimal64 A) 828 -- Runtime Function: long double __bid_extendddxf (_Decimal64 A) 829 -- Runtime Function: long double __dpd_trunctdxf (_Decimal128 A) 830 -- Runtime Function: long double __bid_trunctdxf (_Decimal128 A) 831 -- Runtime Function: long double __dpd_extendsdtf (_Decimal32 A) 832 -- Runtime Function: long double __bid_extendsdtf (_Decimal32 A) 833 -- Runtime Function: long double __dpd_extendddtf (_Decimal64 A) 834 -- Runtime Function: long double __bid_extendddtf (_Decimal64 A) 835 These functions convert the value of A from a decimal floating type 836 to a binary floating type of a different size. 837 838 -- Runtime Function: _Decimal32 __dpd_extendsfsd (float A) 839 -- Runtime Function: _Decimal32 __bid_extendsfsd (float A) 840 -- Runtime Function: _Decimal64 __dpd_extenddfdd (double A) 841 -- Runtime Function: _Decimal64 __bid_extenddfdd (double A) 842 -- Runtime Function: _Decimal128 __dpd_extendtftd (long double A) 843 -- Runtime Function: _Decimal128 __bid_extendtftd (long double A) 844 -- Runtime Function: float __dpd_truncsdsf (_Decimal32 A) 845 -- Runtime Function: float __bid_truncsdsf (_Decimal32 A) 846 -- Runtime Function: double __dpd_truncdddf (_Decimal64 A) 847 -- Runtime Function: double __bid_truncdddf (_Decimal64 A) 848 -- Runtime Function: long double __dpd_trunctdtf (_Decimal128 A) 849 -- Runtime Function: long double __bid_trunctdtf (_Decimal128 A) 850 These functions convert the value of A between decimal and binary 851 floating types of the same size. 852 853 -- Runtime Function: int __dpd_fixsdsi (_Decimal32 A) 854 -- Runtime Function: int __bid_fixsdsi (_Decimal32 A) 855 -- Runtime Function: int __dpd_fixddsi (_Decimal64 A) 856 -- Runtime Function: int __bid_fixddsi (_Decimal64 A) 857 -- Runtime Function: int __dpd_fixtdsi (_Decimal128 A) 858 -- Runtime Function: int __bid_fixtdsi (_Decimal128 A) 859 These functions convert A to a signed integer. 860 861 -- Runtime Function: long __dpd_fixsddi (_Decimal32 A) 862 -- Runtime Function: long __bid_fixsddi (_Decimal32 A) 863 -- Runtime Function: long __dpd_fixdddi (_Decimal64 A) 864 -- Runtime Function: long __bid_fixdddi (_Decimal64 A) 865 -- Runtime Function: long __dpd_fixtddi (_Decimal128 A) 866 -- Runtime Function: long __bid_fixtddi (_Decimal128 A) 867 These functions convert A to a signed long. 868 869 -- Runtime Function: unsigned int __dpd_fixunssdsi (_Decimal32 A) 870 -- Runtime Function: unsigned int __bid_fixunssdsi (_Decimal32 A) 871 -- Runtime Function: unsigned int __dpd_fixunsddsi (_Decimal64 A) 872 -- Runtime Function: unsigned int __bid_fixunsddsi (_Decimal64 A) 873 -- Runtime Function: unsigned int __dpd_fixunstdsi (_Decimal128 A) 874 -- Runtime Function: unsigned int __bid_fixunstdsi (_Decimal128 A) 875 These functions convert A to an unsigned integer. Negative values 876 all become zero. 877 878 -- Runtime Function: unsigned long __dpd_fixunssddi (_Decimal32 A) 879 -- Runtime Function: unsigned long __bid_fixunssddi (_Decimal32 A) 880 -- Runtime Function: unsigned long __dpd_fixunsdddi (_Decimal64 A) 881 -- Runtime Function: unsigned long __bid_fixunsdddi (_Decimal64 A) 882 -- Runtime Function: unsigned long __dpd_fixunstddi (_Decimal128 A) 883 -- Runtime Function: unsigned long __bid_fixunstddi (_Decimal128 A) 884 These functions convert A to an unsigned long. Negative values all 885 become zero. 886 887 -- Runtime Function: _Decimal32 __dpd_floatsisd (int I) 888 -- Runtime Function: _Decimal32 __bid_floatsisd (int I) 889 -- Runtime Function: _Decimal64 __dpd_floatsidd (int I) 890 -- Runtime Function: _Decimal64 __bid_floatsidd (int I) 891 -- Runtime Function: _Decimal128 __dpd_floatsitd (int I) 892 -- Runtime Function: _Decimal128 __bid_floatsitd (int I) 893 These functions convert I, a signed integer, to decimal floating 894 point. 895 896 -- Runtime Function: _Decimal32 __dpd_floatdisd (long I) 897 -- Runtime Function: _Decimal32 __bid_floatdisd (long I) 898 -- Runtime Function: _Decimal64 __dpd_floatdidd (long I) 899 -- Runtime Function: _Decimal64 __bid_floatdidd (long I) 900 -- Runtime Function: _Decimal128 __dpd_floatditd (long I) 901 -- Runtime Function: _Decimal128 __bid_floatditd (long I) 902 These functions convert I, a signed long, to decimal floating 903 point. 904 905 -- Runtime Function: _Decimal32 __dpd_floatunssisd (unsigned int I) 906 -- Runtime Function: _Decimal32 __bid_floatunssisd (unsigned int I) 907 -- Runtime Function: _Decimal64 __dpd_floatunssidd (unsigned int I) 908 -- Runtime Function: _Decimal64 __bid_floatunssidd (unsigned int I) 909 -- Runtime Function: _Decimal128 __dpd_floatunssitd (unsigned int I) 910 -- Runtime Function: _Decimal128 __bid_floatunssitd (unsigned int I) 911 These functions convert I, an unsigned integer, to decimal floating 912 point. 913 914 -- Runtime Function: _Decimal32 __dpd_floatunsdisd (unsigned long I) 915 -- Runtime Function: _Decimal32 __bid_floatunsdisd (unsigned long I) 916 -- Runtime Function: _Decimal64 __dpd_floatunsdidd (unsigned long I) 917 -- Runtime Function: _Decimal64 __bid_floatunsdidd (unsigned long I) 918 -- Runtime Function: _Decimal128 __dpd_floatunsditd (unsigned long I) 919 -- Runtime Function: _Decimal128 __bid_floatunsditd (unsigned long I) 920 These functions convert I, an unsigned long, to decimal floating 921 point. 922 9234.3.3 Comparison functions 924-------------------------- 925 926 -- Runtime Function: int __dpd_unordsd2 (_Decimal32 A, _Decimal32 B) 927 -- Runtime Function: int __bid_unordsd2 (_Decimal32 A, _Decimal32 B) 928 -- Runtime Function: int __dpd_unorddd2 (_Decimal64 A, _Decimal64 B) 929 -- Runtime Function: int __bid_unorddd2 (_Decimal64 A, _Decimal64 B) 930 -- Runtime Function: int __dpd_unordtd2 (_Decimal128 A, _Decimal128 B) 931 -- Runtime Function: int __bid_unordtd2 (_Decimal128 A, _Decimal128 B) 932 These functions return a nonzero value if either argument is NaN, 933 otherwise 0. 934 935 There is also a complete group of higher level functions which 936correspond directly to comparison operators. They implement the ISO C 937semantics for floating-point comparisons, taking NaN into account. Pay 938careful attention to the return values defined for each set. Under the 939hood, all of these routines are implemented as 940 941 if (__bid_unordXd2 (a, b)) 942 return E; 943 return __bid_cmpXd2 (a, b); 944 945where E is a constant chosen to give the proper behavior for NaN. Thus, 946the meaning of the return value is different for each set. Do not rely 947on this implementation; only the semantics documented below are 948guaranteed. 949 950 -- Runtime Function: int __dpd_eqsd2 (_Decimal32 A, _Decimal32 B) 951 -- Runtime Function: int __bid_eqsd2 (_Decimal32 A, _Decimal32 B) 952 -- Runtime Function: int __dpd_eqdd2 (_Decimal64 A, _Decimal64 B) 953 -- Runtime Function: int __bid_eqdd2 (_Decimal64 A, _Decimal64 B) 954 -- Runtime Function: int __dpd_eqtd2 (_Decimal128 A, _Decimal128 B) 955 -- Runtime Function: int __bid_eqtd2 (_Decimal128 A, _Decimal128 B) 956 These functions return zero if neither argument is NaN, and A and B 957 are equal. 958 959 -- Runtime Function: int __dpd_nesd2 (_Decimal32 A, _Decimal32 B) 960 -- Runtime Function: int __bid_nesd2 (_Decimal32 A, _Decimal32 B) 961 -- Runtime Function: int __dpd_nedd2 (_Decimal64 A, _Decimal64 B) 962 -- Runtime Function: int __bid_nedd2 (_Decimal64 A, _Decimal64 B) 963 -- Runtime Function: int __dpd_netd2 (_Decimal128 A, _Decimal128 B) 964 -- Runtime Function: int __bid_netd2 (_Decimal128 A, _Decimal128 B) 965 These functions return a nonzero value if either argument is NaN, 966 or if A and B are unequal. 967 968 -- Runtime Function: int __dpd_gesd2 (_Decimal32 A, _Decimal32 B) 969 -- Runtime Function: int __bid_gesd2 (_Decimal32 A, _Decimal32 B) 970 -- Runtime Function: int __dpd_gedd2 (_Decimal64 A, _Decimal64 B) 971 -- Runtime Function: int __bid_gedd2 (_Decimal64 A, _Decimal64 B) 972 -- Runtime Function: int __dpd_getd2 (_Decimal128 A, _Decimal128 B) 973 -- Runtime Function: int __bid_getd2 (_Decimal128 A, _Decimal128 B) 974 These functions return a value greater than or equal to zero if 975 neither argument is NaN, and A is greater than or equal to B. 976 977 -- Runtime Function: int __dpd_ltsd2 (_Decimal32 A, _Decimal32 B) 978 -- Runtime Function: int __bid_ltsd2 (_Decimal32 A, _Decimal32 B) 979 -- Runtime Function: int __dpd_ltdd2 (_Decimal64 A, _Decimal64 B) 980 -- Runtime Function: int __bid_ltdd2 (_Decimal64 A, _Decimal64 B) 981 -- Runtime Function: int __dpd_lttd2 (_Decimal128 A, _Decimal128 B) 982 -- Runtime Function: int __bid_lttd2 (_Decimal128 A, _Decimal128 B) 983 These functions return a value less than zero if neither argument 984 is NaN, and A is strictly less than B. 985 986 -- Runtime Function: int __dpd_lesd2 (_Decimal32 A, _Decimal32 B) 987 -- Runtime Function: int __bid_lesd2 (_Decimal32 A, _Decimal32 B) 988 -- Runtime Function: int __dpd_ledd2 (_Decimal64 A, _Decimal64 B) 989 -- Runtime Function: int __bid_ledd2 (_Decimal64 A, _Decimal64 B) 990 -- Runtime Function: int __dpd_letd2 (_Decimal128 A, _Decimal128 B) 991 -- Runtime Function: int __bid_letd2 (_Decimal128 A, _Decimal128 B) 992 These functions return a value less than or equal to zero if 993 neither argument is NaN, and A is less than or equal to B. 994 995 -- Runtime Function: int __dpd_gtsd2 (_Decimal32 A, _Decimal32 B) 996 -- Runtime Function: int __bid_gtsd2 (_Decimal32 A, _Decimal32 B) 997 -- Runtime Function: int __dpd_gtdd2 (_Decimal64 A, _Decimal64 B) 998 -- Runtime Function: int __bid_gtdd2 (_Decimal64 A, _Decimal64 B) 999 -- Runtime Function: int __dpd_gttd2 (_Decimal128 A, _Decimal128 B) 1000 -- Runtime Function: int __bid_gttd2 (_Decimal128 A, _Decimal128 B) 1001 These functions return a value greater than zero if neither 1002 argument is NaN, and A is strictly greater than B. 1003 1004 1005File: gccint.info, Node: Fixed-point fractional library routines, Next: Exception handling routines, Prev: Decimal float library routines, Up: Libgcc 1006 10074.4 Routines for fixed-point fractional emulation 1008================================================= 1009 1010The software fixed-point library implements fixed-point fractional 1011arithmetic, and is only activated on selected targets. 1012 1013 For ease of comprehension 'fract' is an alias for the '_Fract' type, 1014'accum' an alias for '_Accum', and 'sat' an alias for '_Sat'. 1015 1016 For illustrative purposes, in this section the fixed-point fractional 1017type 'short fract' is assumed to correspond to machine mode 'QQmode'; 1018'unsigned short fract' to 'UQQmode'; 'fract' to 'HQmode'; 1019'unsigned fract' to 'UHQmode'; 'long fract' to 'SQmode'; 1020'unsigned long fract' to 'USQmode'; 'long long fract' to 'DQmode'; and 1021'unsigned long long fract' to 'UDQmode'. Similarly the fixed-point 1022accumulator type 'short accum' corresponds to 'HAmode'; 1023'unsigned short accum' to 'UHAmode'; 'accum' to 'SAmode'; 1024'unsigned accum' to 'USAmode'; 'long accum' to 'DAmode'; 1025'unsigned long accum' to 'UDAmode'; 'long long accum' to 'TAmode'; and 1026'unsigned long long accum' to 'UTAmode'. 1027 10284.4.1 Arithmetic functions 1029-------------------------- 1030 1031 -- Runtime Function: short fract __addqq3 (short fract A, short fract 1032 B) 1033 -- Runtime Function: fract __addhq3 (fract A, fract B) 1034 -- Runtime Function: long fract __addsq3 (long fract A, long fract B) 1035 -- Runtime Function: long long fract __adddq3 (long long fract A, long 1036 long fract B) 1037 -- Runtime Function: unsigned short fract __adduqq3 (unsigned short 1038 fract A, unsigned short fract B) 1039 -- Runtime Function: unsigned fract __adduhq3 (unsigned fract A, 1040 unsigned fract B) 1041 -- Runtime Function: unsigned long fract __addusq3 (unsigned long fract 1042 A, unsigned long fract B) 1043 -- Runtime Function: unsigned long long fract __addudq3 (unsigned long 1044 long fract A, unsigned long long fract B) 1045 -- Runtime Function: short accum __addha3 (short accum A, short accum 1046 B) 1047 -- Runtime Function: accum __addsa3 (accum A, accum B) 1048 -- Runtime Function: long accum __addda3 (long accum A, long accum B) 1049 -- Runtime Function: long long accum __addta3 (long long accum A, long 1050 long accum B) 1051 -- Runtime Function: unsigned short accum __adduha3 (unsigned short 1052 accum A, unsigned short accum B) 1053 -- Runtime Function: unsigned accum __addusa3 (unsigned accum A, 1054 unsigned accum B) 1055 -- Runtime Function: unsigned long accum __adduda3 (unsigned long accum 1056 A, unsigned long accum B) 1057 -- Runtime Function: unsigned long long accum __adduta3 (unsigned long 1058 long accum A, unsigned long long accum B) 1059 These functions return the sum of A and B. 1060 1061 -- Runtime Function: short fract __ssaddqq3 (short fract A, short fract 1062 B) 1063 -- Runtime Function: fract __ssaddhq3 (fract A, fract B) 1064 -- Runtime Function: long fract __ssaddsq3 (long fract A, long fract B) 1065 -- Runtime Function: long long fract __ssadddq3 (long long fract A, 1066 long long fract B) 1067 -- Runtime Function: short accum __ssaddha3 (short accum A, short accum 1068 B) 1069 -- Runtime Function: accum __ssaddsa3 (accum A, accum B) 1070 -- Runtime Function: long accum __ssaddda3 (long accum A, long accum B) 1071 -- Runtime Function: long long accum __ssaddta3 (long long accum A, 1072 long long accum B) 1073 These functions return the sum of A and B with signed saturation. 1074 1075 -- Runtime Function: unsigned short fract __usadduqq3 (unsigned short 1076 fract A, unsigned short fract B) 1077 -- Runtime Function: unsigned fract __usadduhq3 (unsigned fract A, 1078 unsigned fract B) 1079 -- Runtime Function: unsigned long fract __usaddusq3 (unsigned long 1080 fract A, unsigned long fract B) 1081 -- Runtime Function: unsigned long long fract __usaddudq3 (unsigned 1082 long long fract A, unsigned long long fract B) 1083 -- Runtime Function: unsigned short accum __usadduha3 (unsigned short 1084 accum A, unsigned short accum B) 1085 -- Runtime Function: unsigned accum __usaddusa3 (unsigned accum A, 1086 unsigned accum B) 1087 -- Runtime Function: unsigned long accum __usadduda3 (unsigned long 1088 accum A, unsigned long accum B) 1089 -- Runtime Function: unsigned long long accum __usadduta3 (unsigned 1090 long long accum A, unsigned long long accum B) 1091 These functions return the sum of A and B with unsigned saturation. 1092 1093 -- Runtime Function: short fract __subqq3 (short fract A, short fract 1094 B) 1095 -- Runtime Function: fract __subhq3 (fract A, fract B) 1096 -- Runtime Function: long fract __subsq3 (long fract A, long fract B) 1097 -- Runtime Function: long long fract __subdq3 (long long fract A, long 1098 long fract B) 1099 -- Runtime Function: unsigned short fract __subuqq3 (unsigned short 1100 fract A, unsigned short fract B) 1101 -- Runtime Function: unsigned fract __subuhq3 (unsigned fract A, 1102 unsigned fract B) 1103 -- Runtime Function: unsigned long fract __subusq3 (unsigned long fract 1104 A, unsigned long fract B) 1105 -- Runtime Function: unsigned long long fract __subudq3 (unsigned long 1106 long fract A, unsigned long long fract B) 1107 -- Runtime Function: short accum __subha3 (short accum A, short accum 1108 B) 1109 -- Runtime Function: accum __subsa3 (accum A, accum B) 1110 -- Runtime Function: long accum __subda3 (long accum A, long accum B) 1111 -- Runtime Function: long long accum __subta3 (long long accum A, long 1112 long accum B) 1113 -- Runtime Function: unsigned short accum __subuha3 (unsigned short 1114 accum A, unsigned short accum B) 1115 -- Runtime Function: unsigned accum __subusa3 (unsigned accum A, 1116 unsigned accum B) 1117 -- Runtime Function: unsigned long accum __subuda3 (unsigned long accum 1118 A, unsigned long accum B) 1119 -- Runtime Function: unsigned long long accum __subuta3 (unsigned long 1120 long accum A, unsigned long long accum B) 1121 These functions return the difference of A and B; that is, 'A - B'. 1122 1123 -- Runtime Function: short fract __sssubqq3 (short fract A, short fract 1124 B) 1125 -- Runtime Function: fract __sssubhq3 (fract A, fract B) 1126 -- Runtime Function: long fract __sssubsq3 (long fract A, long fract B) 1127 -- Runtime Function: long long fract __sssubdq3 (long long fract A, 1128 long long fract B) 1129 -- Runtime Function: short accum __sssubha3 (short accum A, short accum 1130 B) 1131 -- Runtime Function: accum __sssubsa3 (accum A, accum B) 1132 -- Runtime Function: long accum __sssubda3 (long accum A, long accum B) 1133 -- Runtime Function: long long accum __sssubta3 (long long accum A, 1134 long long accum B) 1135 These functions return the difference of A and B with signed 1136 saturation; that is, 'A - B'. 1137 1138 -- Runtime Function: unsigned short fract __ussubuqq3 (unsigned short 1139 fract A, unsigned short fract B) 1140 -- Runtime Function: unsigned fract __ussubuhq3 (unsigned fract A, 1141 unsigned fract B) 1142 -- Runtime Function: unsigned long fract __ussubusq3 (unsigned long 1143 fract A, unsigned long fract B) 1144 -- Runtime Function: unsigned long long fract __ussubudq3 (unsigned 1145 long long fract A, unsigned long long fract B) 1146 -- Runtime Function: unsigned short accum __ussubuha3 (unsigned short 1147 accum A, unsigned short accum B) 1148 -- Runtime Function: unsigned accum __ussubusa3 (unsigned accum A, 1149 unsigned accum B) 1150 -- Runtime Function: unsigned long accum __ussubuda3 (unsigned long 1151 accum A, unsigned long accum B) 1152 -- Runtime Function: unsigned long long accum __ussubuta3 (unsigned 1153 long long accum A, unsigned long long accum B) 1154 These functions return the difference of A and B with unsigned 1155 saturation; that is, 'A - B'. 1156 1157 -- Runtime Function: short fract __mulqq3 (short fract A, short fract 1158 B) 1159 -- Runtime Function: fract __mulhq3 (fract A, fract B) 1160 -- Runtime Function: long fract __mulsq3 (long fract A, long fract B) 1161 -- Runtime Function: long long fract __muldq3 (long long fract A, long 1162 long fract B) 1163 -- Runtime Function: unsigned short fract __muluqq3 (unsigned short 1164 fract A, unsigned short fract B) 1165 -- Runtime Function: unsigned fract __muluhq3 (unsigned fract A, 1166 unsigned fract B) 1167 -- Runtime Function: unsigned long fract __mulusq3 (unsigned long fract 1168 A, unsigned long fract B) 1169 -- Runtime Function: unsigned long long fract __muludq3 (unsigned long 1170 long fract A, unsigned long long fract B) 1171 -- Runtime Function: short accum __mulha3 (short accum A, short accum 1172 B) 1173 -- Runtime Function: accum __mulsa3 (accum A, accum B) 1174 -- Runtime Function: long accum __mulda3 (long accum A, long accum B) 1175 -- Runtime Function: long long accum __multa3 (long long accum A, long 1176 long accum B) 1177 -- Runtime Function: unsigned short accum __muluha3 (unsigned short 1178 accum A, unsigned short accum B) 1179 -- Runtime Function: unsigned accum __mulusa3 (unsigned accum A, 1180 unsigned accum B) 1181 -- Runtime Function: unsigned long accum __muluda3 (unsigned long accum 1182 A, unsigned long accum B) 1183 -- Runtime Function: unsigned long long accum __muluta3 (unsigned long 1184 long accum A, unsigned long long accum B) 1185 These functions return the product of A and B. 1186 1187 -- Runtime Function: short fract __ssmulqq3 (short fract A, short fract 1188 B) 1189 -- Runtime Function: fract __ssmulhq3 (fract A, fract B) 1190 -- Runtime Function: long fract __ssmulsq3 (long fract A, long fract B) 1191 -- Runtime Function: long long fract __ssmuldq3 (long long fract A, 1192 long long fract B) 1193 -- Runtime Function: short accum __ssmulha3 (short accum A, short accum 1194 B) 1195 -- Runtime Function: accum __ssmulsa3 (accum A, accum B) 1196 -- Runtime Function: long accum __ssmulda3 (long accum A, long accum B) 1197 -- Runtime Function: long long accum __ssmulta3 (long long accum A, 1198 long long accum B) 1199 These functions return the product of A and B with signed 1200 saturation. 1201 1202 -- Runtime Function: unsigned short fract __usmuluqq3 (unsigned short 1203 fract A, unsigned short fract B) 1204 -- Runtime Function: unsigned fract __usmuluhq3 (unsigned fract A, 1205 unsigned fract B) 1206 -- Runtime Function: unsigned long fract __usmulusq3 (unsigned long 1207 fract A, unsigned long fract B) 1208 -- Runtime Function: unsigned long long fract __usmuludq3 (unsigned 1209 long long fract A, unsigned long long fract B) 1210 -- Runtime Function: unsigned short accum __usmuluha3 (unsigned short 1211 accum A, unsigned short accum B) 1212 -- Runtime Function: unsigned accum __usmulusa3 (unsigned accum A, 1213 unsigned accum B) 1214 -- Runtime Function: unsigned long accum __usmuluda3 (unsigned long 1215 accum A, unsigned long accum B) 1216 -- Runtime Function: unsigned long long accum __usmuluta3 (unsigned 1217 long long accum A, unsigned long long accum B) 1218 These functions return the product of A and B with unsigned 1219 saturation. 1220 1221 -- Runtime Function: short fract __divqq3 (short fract A, short fract 1222 B) 1223 -- Runtime Function: fract __divhq3 (fract A, fract B) 1224 -- Runtime Function: long fract __divsq3 (long fract A, long fract B) 1225 -- Runtime Function: long long fract __divdq3 (long long fract A, long 1226 long fract B) 1227 -- Runtime Function: short accum __divha3 (short accum A, short accum 1228 B) 1229 -- Runtime Function: accum __divsa3 (accum A, accum B) 1230 -- Runtime Function: long accum __divda3 (long accum A, long accum B) 1231 -- Runtime Function: long long accum __divta3 (long long accum A, long 1232 long accum B) 1233 These functions return the quotient of the signed division of A and 1234 B. 1235 1236 -- Runtime Function: unsigned short fract __udivuqq3 (unsigned short 1237 fract A, unsigned short fract B) 1238 -- Runtime Function: unsigned fract __udivuhq3 (unsigned fract A, 1239 unsigned fract B) 1240 -- Runtime Function: unsigned long fract __udivusq3 (unsigned long 1241 fract A, unsigned long fract B) 1242 -- Runtime Function: unsigned long long fract __udivudq3 (unsigned long 1243 long fract A, unsigned long long fract B) 1244 -- Runtime Function: unsigned short accum __udivuha3 (unsigned short 1245 accum A, unsigned short accum B) 1246 -- Runtime Function: unsigned accum __udivusa3 (unsigned accum A, 1247 unsigned accum B) 1248 -- Runtime Function: unsigned long accum __udivuda3 (unsigned long 1249 accum A, unsigned long accum B) 1250 -- Runtime Function: unsigned long long accum __udivuta3 (unsigned long 1251 long accum A, unsigned long long accum B) 1252 These functions return the quotient of the unsigned division of A 1253 and B. 1254 1255 -- Runtime Function: short fract __ssdivqq3 (short fract A, short fract 1256 B) 1257 -- Runtime Function: fract __ssdivhq3 (fract A, fract B) 1258 -- Runtime Function: long fract __ssdivsq3 (long fract A, long fract B) 1259 -- Runtime Function: long long fract __ssdivdq3 (long long fract A, 1260 long long fract B) 1261 -- Runtime Function: short accum __ssdivha3 (short accum A, short accum 1262 B) 1263 -- Runtime Function: accum __ssdivsa3 (accum A, accum B) 1264 -- Runtime Function: long accum __ssdivda3 (long accum A, long accum B) 1265 -- Runtime Function: long long accum __ssdivta3 (long long accum A, 1266 long long accum B) 1267 These functions return the quotient of the signed division of A and 1268 B with signed saturation. 1269 1270 -- Runtime Function: unsigned short fract __usdivuqq3 (unsigned short 1271 fract A, unsigned short fract B) 1272 -- Runtime Function: unsigned fract __usdivuhq3 (unsigned fract A, 1273 unsigned fract B) 1274 -- Runtime Function: unsigned long fract __usdivusq3 (unsigned long 1275 fract A, unsigned long fract B) 1276 -- Runtime Function: unsigned long long fract __usdivudq3 (unsigned 1277 long long fract A, unsigned long long fract B) 1278 -- Runtime Function: unsigned short accum __usdivuha3 (unsigned short 1279 accum A, unsigned short accum B) 1280 -- Runtime Function: unsigned accum __usdivusa3 (unsigned accum A, 1281 unsigned accum B) 1282 -- Runtime Function: unsigned long accum __usdivuda3 (unsigned long 1283 accum A, unsigned long accum B) 1284 -- Runtime Function: unsigned long long accum __usdivuta3 (unsigned 1285 long long accum A, unsigned long long accum B) 1286 These functions return the quotient of the unsigned division of A 1287 and B with unsigned saturation. 1288 1289 -- Runtime Function: short fract __negqq2 (short fract A) 1290 -- Runtime Function: fract __neghq2 (fract A) 1291 -- Runtime Function: long fract __negsq2 (long fract A) 1292 -- Runtime Function: long long fract __negdq2 (long long fract A) 1293 -- Runtime Function: unsigned short fract __neguqq2 (unsigned short 1294 fract A) 1295 -- Runtime Function: unsigned fract __neguhq2 (unsigned fract A) 1296 -- Runtime Function: unsigned long fract __negusq2 (unsigned long fract 1297 A) 1298 -- Runtime Function: unsigned long long fract __negudq2 (unsigned long 1299 long fract A) 1300 -- Runtime Function: short accum __negha2 (short accum A) 1301 -- Runtime Function: accum __negsa2 (accum A) 1302 -- Runtime Function: long accum __negda2 (long accum A) 1303 -- Runtime Function: long long accum __negta2 (long long accum A) 1304 -- Runtime Function: unsigned short accum __neguha2 (unsigned short 1305 accum A) 1306 -- Runtime Function: unsigned accum __negusa2 (unsigned accum A) 1307 -- Runtime Function: unsigned long accum __neguda2 (unsigned long accum 1308 A) 1309 -- Runtime Function: unsigned long long accum __neguta2 (unsigned long 1310 long accum A) 1311 These functions return the negation of A. 1312 1313 -- Runtime Function: short fract __ssnegqq2 (short fract A) 1314 -- Runtime Function: fract __ssneghq2 (fract A) 1315 -- Runtime Function: long fract __ssnegsq2 (long fract A) 1316 -- Runtime Function: long long fract __ssnegdq2 (long long fract A) 1317 -- Runtime Function: short accum __ssnegha2 (short accum A) 1318 -- Runtime Function: accum __ssnegsa2 (accum A) 1319 -- Runtime Function: long accum __ssnegda2 (long accum A) 1320 -- Runtime Function: long long accum __ssnegta2 (long long accum A) 1321 These functions return the negation of A with signed saturation. 1322 1323 -- Runtime Function: unsigned short fract __usneguqq2 (unsigned short 1324 fract A) 1325 -- Runtime Function: unsigned fract __usneguhq2 (unsigned fract A) 1326 -- Runtime Function: unsigned long fract __usnegusq2 (unsigned long 1327 fract A) 1328 -- Runtime Function: unsigned long long fract __usnegudq2 (unsigned 1329 long long fract A) 1330 -- Runtime Function: unsigned short accum __usneguha2 (unsigned short 1331 accum A) 1332 -- Runtime Function: unsigned accum __usnegusa2 (unsigned accum A) 1333 -- Runtime Function: unsigned long accum __usneguda2 (unsigned long 1334 accum A) 1335 -- Runtime Function: unsigned long long accum __usneguta2 (unsigned 1336 long long accum A) 1337 These functions return the negation of A with unsigned saturation. 1338 1339 -- Runtime Function: short fract __ashlqq3 (short fract A, int B) 1340 -- Runtime Function: fract __ashlhq3 (fract A, int B) 1341 -- Runtime Function: long fract __ashlsq3 (long fract A, int B) 1342 -- Runtime Function: long long fract __ashldq3 (long long fract A, int 1343 B) 1344 -- Runtime Function: unsigned short fract __ashluqq3 (unsigned short 1345 fract A, int B) 1346 -- Runtime Function: unsigned fract __ashluhq3 (unsigned fract A, int 1347 B) 1348 -- Runtime Function: unsigned long fract __ashlusq3 (unsigned long 1349 fract A, int B) 1350 -- Runtime Function: unsigned long long fract __ashludq3 (unsigned long 1351 long fract A, int B) 1352 -- Runtime Function: short accum __ashlha3 (short accum A, int B) 1353 -- Runtime Function: accum __ashlsa3 (accum A, int B) 1354 -- Runtime Function: long accum __ashlda3 (long accum A, int B) 1355 -- Runtime Function: long long accum __ashlta3 (long long accum A, int 1356 B) 1357 -- Runtime Function: unsigned short accum __ashluha3 (unsigned short 1358 accum A, int B) 1359 -- Runtime Function: unsigned accum __ashlusa3 (unsigned accum A, int 1360 B) 1361 -- Runtime Function: unsigned long accum __ashluda3 (unsigned long 1362 accum A, int B) 1363 -- Runtime Function: unsigned long long accum __ashluta3 (unsigned long 1364 long accum A, int B) 1365 These functions return the result of shifting A left by B bits. 1366 1367 -- Runtime Function: short fract __ashrqq3 (short fract A, int B) 1368 -- Runtime Function: fract __ashrhq3 (fract A, int B) 1369 -- Runtime Function: long fract __ashrsq3 (long fract A, int B) 1370 -- Runtime Function: long long fract __ashrdq3 (long long fract A, int 1371 B) 1372 -- Runtime Function: short accum __ashrha3 (short accum A, int B) 1373 -- Runtime Function: accum __ashrsa3 (accum A, int B) 1374 -- Runtime Function: long accum __ashrda3 (long accum A, int B) 1375 -- Runtime Function: long long accum __ashrta3 (long long accum A, int 1376 B) 1377 These functions return the result of arithmetically shifting A 1378 right by B bits. 1379 1380 -- Runtime Function: unsigned short fract __lshruqq3 (unsigned short 1381 fract A, int B) 1382 -- Runtime Function: unsigned fract __lshruhq3 (unsigned fract A, int 1383 B) 1384 -- Runtime Function: unsigned long fract __lshrusq3 (unsigned long 1385 fract A, int B) 1386 -- Runtime Function: unsigned long long fract __lshrudq3 (unsigned long 1387 long fract A, int B) 1388 -- Runtime Function: unsigned short accum __lshruha3 (unsigned short 1389 accum A, int B) 1390 -- Runtime Function: unsigned accum __lshrusa3 (unsigned accum A, int 1391 B) 1392 -- Runtime Function: unsigned long accum __lshruda3 (unsigned long 1393 accum A, int B) 1394 -- Runtime Function: unsigned long long accum __lshruta3 (unsigned long 1395 long accum A, int B) 1396 These functions return the result of logically shifting A right by 1397 B bits. 1398 1399 -- Runtime Function: fract __ssashlhq3 (fract A, int B) 1400 -- Runtime Function: long fract __ssashlsq3 (long fract A, int B) 1401 -- Runtime Function: long long fract __ssashldq3 (long long fract A, 1402 int B) 1403 -- Runtime Function: short accum __ssashlha3 (short accum A, int B) 1404 -- Runtime Function: accum __ssashlsa3 (accum A, int B) 1405 -- Runtime Function: long accum __ssashlda3 (long accum A, int B) 1406 -- Runtime Function: long long accum __ssashlta3 (long long accum A, 1407 int B) 1408 These functions return the result of shifting A left by B bits with 1409 signed saturation. 1410 1411 -- Runtime Function: unsigned short fract __usashluqq3 (unsigned short 1412 fract A, int B) 1413 -- Runtime Function: unsigned fract __usashluhq3 (unsigned fract A, int 1414 B) 1415 -- Runtime Function: unsigned long fract __usashlusq3 (unsigned long 1416 fract A, int B) 1417 -- Runtime Function: unsigned long long fract __usashludq3 (unsigned 1418 long long fract A, int B) 1419 -- Runtime Function: unsigned short accum __usashluha3 (unsigned short 1420 accum A, int B) 1421 -- Runtime Function: unsigned accum __usashlusa3 (unsigned accum A, int 1422 B) 1423 -- Runtime Function: unsigned long accum __usashluda3 (unsigned long 1424 accum A, int B) 1425 -- Runtime Function: unsigned long long accum __usashluta3 (unsigned 1426 long long accum A, int B) 1427 These functions return the result of shifting A left by B bits with 1428 unsigned saturation. 1429 14304.4.2 Comparison functions 1431-------------------------- 1432 1433The following functions implement fixed-point comparisons. These 1434functions implement a low-level compare, upon which the higher level 1435comparison operators (such as less than and greater than or equal to) 1436can be constructed. The returned values lie in the range zero to two, 1437to allow the high-level operators to be implemented by testing the 1438returned result using either signed or unsigned comparison. 1439 1440 -- Runtime Function: int __cmpqq2 (short fract A, short fract B) 1441 -- Runtime Function: int __cmphq2 (fract A, fract B) 1442 -- Runtime Function: int __cmpsq2 (long fract A, long fract B) 1443 -- Runtime Function: int __cmpdq2 (long long fract A, long long fract 1444 B) 1445 -- Runtime Function: int __cmpuqq2 (unsigned short fract A, unsigned 1446 short fract B) 1447 -- Runtime Function: int __cmpuhq2 (unsigned fract A, unsigned fract B) 1448 -- Runtime Function: int __cmpusq2 (unsigned long fract A, unsigned 1449 long fract B) 1450 -- Runtime Function: int __cmpudq2 (unsigned long long fract A, 1451 unsigned long long fract B) 1452 -- Runtime Function: int __cmpha2 (short accum A, short accum B) 1453 -- Runtime Function: int __cmpsa2 (accum A, accum B) 1454 -- Runtime Function: int __cmpda2 (long accum A, long accum B) 1455 -- Runtime Function: int __cmpta2 (long long accum A, long long accum 1456 B) 1457 -- Runtime Function: int __cmpuha2 (unsigned short accum A, unsigned 1458 short accum B) 1459 -- Runtime Function: int __cmpusa2 (unsigned accum A, unsigned accum B) 1460 -- Runtime Function: int __cmpuda2 (unsigned long accum A, unsigned 1461 long accum B) 1462 -- Runtime Function: int __cmputa2 (unsigned long long accum A, 1463 unsigned long long accum B) 1464 These functions perform a signed or unsigned comparison of A and B 1465 (depending on the selected machine mode). If A is less than B, 1466 they return 0; if A is greater than B, they return 2; and if A and 1467 B are equal they return 1. 1468 14694.4.3 Conversion functions 1470-------------------------- 1471 1472 -- Runtime Function: fract __fractqqhq2 (short fract A) 1473 -- Runtime Function: long fract __fractqqsq2 (short fract A) 1474 -- Runtime Function: long long fract __fractqqdq2 (short fract A) 1475 -- Runtime Function: short accum __fractqqha (short fract A) 1476 -- Runtime Function: accum __fractqqsa (short fract A) 1477 -- Runtime Function: long accum __fractqqda (short fract A) 1478 -- Runtime Function: long long accum __fractqqta (short fract A) 1479 -- Runtime Function: unsigned short fract __fractqquqq (short fract A) 1480 -- Runtime Function: unsigned fract __fractqquhq (short fract A) 1481 -- Runtime Function: unsigned long fract __fractqqusq (short fract A) 1482 -- Runtime Function: unsigned long long fract __fractqqudq (short fract 1483 A) 1484 -- Runtime Function: unsigned short accum __fractqquha (short fract A) 1485 -- Runtime Function: unsigned accum __fractqqusa (short fract A) 1486 -- Runtime Function: unsigned long accum __fractqquda (short fract A) 1487 -- Runtime Function: unsigned long long accum __fractqquta (short fract 1488 A) 1489 -- Runtime Function: signed char __fractqqqi (short fract A) 1490 -- Runtime Function: short __fractqqhi (short fract A) 1491 -- Runtime Function: int __fractqqsi (short fract A) 1492 -- Runtime Function: long __fractqqdi (short fract A) 1493 -- Runtime Function: long long __fractqqti (short fract A) 1494 -- Runtime Function: float __fractqqsf (short fract A) 1495 -- Runtime Function: double __fractqqdf (short fract A) 1496 -- Runtime Function: short fract __fracthqqq2 (fract A) 1497 -- Runtime Function: long fract __fracthqsq2 (fract A) 1498 -- Runtime Function: long long fract __fracthqdq2 (fract A) 1499 -- Runtime Function: short accum __fracthqha (fract A) 1500 -- Runtime Function: accum __fracthqsa (fract A) 1501 -- Runtime Function: long accum __fracthqda (fract A) 1502 -- Runtime Function: long long accum __fracthqta (fract A) 1503 -- Runtime Function: unsigned short fract __fracthquqq (fract A) 1504 -- Runtime Function: unsigned fract __fracthquhq (fract A) 1505 -- Runtime Function: unsigned long fract __fracthqusq (fract A) 1506 -- Runtime Function: unsigned long long fract __fracthqudq (fract A) 1507 -- Runtime Function: unsigned short accum __fracthquha (fract A) 1508 -- Runtime Function: unsigned accum __fracthqusa (fract A) 1509 -- Runtime Function: unsigned long accum __fracthquda (fract A) 1510 -- Runtime Function: unsigned long long accum __fracthquta (fract A) 1511 -- Runtime Function: signed char __fracthqqi (fract A) 1512 -- Runtime Function: short __fracthqhi (fract A) 1513 -- Runtime Function: int __fracthqsi (fract A) 1514 -- Runtime Function: long __fracthqdi (fract A) 1515 -- Runtime Function: long long __fracthqti (fract A) 1516 -- Runtime Function: float __fracthqsf (fract A) 1517 -- Runtime Function: double __fracthqdf (fract A) 1518 -- Runtime Function: short fract __fractsqqq2 (long fract A) 1519 -- Runtime Function: fract __fractsqhq2 (long fract A) 1520 -- Runtime Function: long long fract __fractsqdq2 (long fract A) 1521 -- Runtime Function: short accum __fractsqha (long fract A) 1522 -- Runtime Function: accum __fractsqsa (long fract A) 1523 -- Runtime Function: long accum __fractsqda (long fract A) 1524 -- Runtime Function: long long accum __fractsqta (long fract A) 1525 -- Runtime Function: unsigned short fract __fractsquqq (long fract A) 1526 -- Runtime Function: unsigned fract __fractsquhq (long fract A) 1527 -- Runtime Function: unsigned long fract __fractsqusq (long fract A) 1528 -- Runtime Function: unsigned long long fract __fractsqudq (long fract 1529 A) 1530 -- Runtime Function: unsigned short accum __fractsquha (long fract A) 1531 -- Runtime Function: unsigned accum __fractsqusa (long fract A) 1532 -- Runtime Function: unsigned long accum __fractsquda (long fract A) 1533 -- Runtime Function: unsigned long long accum __fractsquta (long fract 1534 A) 1535 -- Runtime Function: signed char __fractsqqi (long fract A) 1536 -- Runtime Function: short __fractsqhi (long fract A) 1537 -- Runtime Function: int __fractsqsi (long fract A) 1538 -- Runtime Function: long __fractsqdi (long fract A) 1539 -- Runtime Function: long long __fractsqti (long fract A) 1540 -- Runtime Function: float __fractsqsf (long fract A) 1541 -- Runtime Function: double __fractsqdf (long fract A) 1542 -- Runtime Function: short fract __fractdqqq2 (long long fract A) 1543 -- Runtime Function: fract __fractdqhq2 (long long fract A) 1544 -- Runtime Function: long fract __fractdqsq2 (long long fract A) 1545 -- Runtime Function: short accum __fractdqha (long long fract A) 1546 -- Runtime Function: accum __fractdqsa (long long fract A) 1547 -- Runtime Function: long accum __fractdqda (long long fract A) 1548 -- Runtime Function: long long accum __fractdqta (long long fract A) 1549 -- Runtime Function: unsigned short fract __fractdquqq (long long fract 1550 A) 1551 -- Runtime Function: unsigned fract __fractdquhq (long long fract A) 1552 -- Runtime Function: unsigned long fract __fractdqusq (long long fract 1553 A) 1554 -- Runtime Function: unsigned long long fract __fractdqudq (long long 1555 fract A) 1556 -- Runtime Function: unsigned short accum __fractdquha (long long fract 1557 A) 1558 -- Runtime Function: unsigned accum __fractdqusa (long long fract A) 1559 -- Runtime Function: unsigned long accum __fractdquda (long long fract 1560 A) 1561 -- Runtime Function: unsigned long long accum __fractdquta (long long 1562 fract A) 1563 -- Runtime Function: signed char __fractdqqi (long long fract A) 1564 -- Runtime Function: short __fractdqhi (long long fract A) 1565 -- Runtime Function: int __fractdqsi (long long fract A) 1566 -- Runtime Function: long __fractdqdi (long long fract A) 1567 -- Runtime Function: long long __fractdqti (long long fract A) 1568 -- Runtime Function: float __fractdqsf (long long fract A) 1569 -- Runtime Function: double __fractdqdf (long long fract A) 1570 -- Runtime Function: short fract __fracthaqq (short accum A) 1571 -- Runtime Function: fract __fracthahq (short accum A) 1572 -- Runtime Function: long fract __fracthasq (short accum A) 1573 -- Runtime Function: long long fract __fracthadq (short accum A) 1574 -- Runtime Function: accum __fracthasa2 (short accum A) 1575 -- Runtime Function: long accum __fracthada2 (short accum A) 1576 -- Runtime Function: long long accum __fracthata2 (short accum A) 1577 -- Runtime Function: unsigned short fract __fracthauqq (short accum A) 1578 -- Runtime Function: unsigned fract __fracthauhq (short accum A) 1579 -- Runtime Function: unsigned long fract __fracthausq (short accum A) 1580 -- Runtime Function: unsigned long long fract __fracthaudq (short accum 1581 A) 1582 -- Runtime Function: unsigned short accum __fracthauha (short accum A) 1583 -- Runtime Function: unsigned accum __fracthausa (short accum A) 1584 -- Runtime Function: unsigned long accum __fracthauda (short accum A) 1585 -- Runtime Function: unsigned long long accum __fracthauta (short accum 1586 A) 1587 -- Runtime Function: signed char __fracthaqi (short accum A) 1588 -- Runtime Function: short __fracthahi (short accum A) 1589 -- Runtime Function: int __fracthasi (short accum A) 1590 -- Runtime Function: long __fracthadi (short accum A) 1591 -- Runtime Function: long long __fracthati (short accum A) 1592 -- Runtime Function: float __fracthasf (short accum A) 1593 -- Runtime Function: double __fracthadf (short accum A) 1594 -- Runtime Function: short fract __fractsaqq (accum A) 1595 -- Runtime Function: fract __fractsahq (accum A) 1596 -- Runtime Function: long fract __fractsasq (accum A) 1597 -- Runtime Function: long long fract __fractsadq (accum A) 1598 -- Runtime Function: short accum __fractsaha2 (accum A) 1599 -- Runtime Function: long accum __fractsada2 (accum A) 1600 -- Runtime Function: long long accum __fractsata2 (accum A) 1601 -- Runtime Function: unsigned short fract __fractsauqq (accum A) 1602 -- Runtime Function: unsigned fract __fractsauhq (accum A) 1603 -- Runtime Function: unsigned long fract __fractsausq (accum A) 1604 -- Runtime Function: unsigned long long fract __fractsaudq (accum A) 1605 -- Runtime Function: unsigned short accum __fractsauha (accum A) 1606 -- Runtime Function: unsigned accum __fractsausa (accum A) 1607 -- Runtime Function: unsigned long accum __fractsauda (accum A) 1608 -- Runtime Function: unsigned long long accum __fractsauta (accum A) 1609 -- Runtime Function: signed char __fractsaqi (accum A) 1610 -- Runtime Function: short __fractsahi (accum A) 1611 -- Runtime Function: int __fractsasi (accum A) 1612 -- Runtime Function: long __fractsadi (accum A) 1613 -- Runtime Function: long long __fractsati (accum A) 1614 -- Runtime Function: float __fractsasf (accum A) 1615 -- Runtime Function: double __fractsadf (accum A) 1616 -- Runtime Function: short fract __fractdaqq (long accum A) 1617 -- Runtime Function: fract __fractdahq (long accum A) 1618 -- Runtime Function: long fract __fractdasq (long accum A) 1619 -- Runtime Function: long long fract __fractdadq (long accum A) 1620 -- Runtime Function: short accum __fractdaha2 (long accum A) 1621 -- Runtime Function: accum __fractdasa2 (long accum A) 1622 -- Runtime Function: long long accum __fractdata2 (long accum A) 1623 -- Runtime Function: unsigned short fract __fractdauqq (long accum A) 1624 -- Runtime Function: unsigned fract __fractdauhq (long accum A) 1625 -- Runtime Function: unsigned long fract __fractdausq (long accum A) 1626 -- Runtime Function: unsigned long long fract __fractdaudq (long accum 1627 A) 1628 -- Runtime Function: unsigned short accum __fractdauha (long accum A) 1629 -- Runtime Function: unsigned accum __fractdausa (long accum A) 1630 -- Runtime Function: unsigned long accum __fractdauda (long accum A) 1631 -- Runtime Function: unsigned long long accum __fractdauta (long accum 1632 A) 1633 -- Runtime Function: signed char __fractdaqi (long accum A) 1634 -- Runtime Function: short __fractdahi (long accum A) 1635 -- Runtime Function: int __fractdasi (long accum A) 1636 -- Runtime Function: long __fractdadi (long accum A) 1637 -- Runtime Function: long long __fractdati (long accum A) 1638 -- Runtime Function: float __fractdasf (long accum A) 1639 -- Runtime Function: double __fractdadf (long accum A) 1640 -- Runtime Function: short fract __fracttaqq (long long accum A) 1641 -- Runtime Function: fract __fracttahq (long long accum A) 1642 -- Runtime Function: long fract __fracttasq (long long accum A) 1643 -- Runtime Function: long long fract __fracttadq (long long accum A) 1644 -- Runtime Function: short accum __fracttaha2 (long long accum A) 1645 -- Runtime Function: accum __fracttasa2 (long long accum A) 1646 -- Runtime Function: long accum __fracttada2 (long long accum A) 1647 -- Runtime Function: unsigned short fract __fracttauqq (long long accum 1648 A) 1649 -- Runtime Function: unsigned fract __fracttauhq (long long accum A) 1650 -- Runtime Function: unsigned long fract __fracttausq (long long accum 1651 A) 1652 -- Runtime Function: unsigned long long fract __fracttaudq (long long 1653 accum A) 1654 -- Runtime Function: unsigned short accum __fracttauha (long long accum 1655 A) 1656 -- Runtime Function: unsigned accum __fracttausa (long long accum A) 1657 -- Runtime Function: unsigned long accum __fracttauda (long long accum 1658 A) 1659 -- Runtime Function: unsigned long long accum __fracttauta (long long 1660 accum A) 1661 -- Runtime Function: signed char __fracttaqi (long long accum A) 1662 -- Runtime Function: short __fracttahi (long long accum A) 1663 -- Runtime Function: int __fracttasi (long long accum A) 1664 -- Runtime Function: long __fracttadi (long long accum A) 1665 -- Runtime Function: long long __fracttati (long long accum A) 1666 -- Runtime Function: float __fracttasf (long long accum A) 1667 -- Runtime Function: double __fracttadf (long long accum A) 1668 -- Runtime Function: short fract __fractuqqqq (unsigned short fract A) 1669 -- Runtime Function: fract __fractuqqhq (unsigned short fract A) 1670 -- Runtime Function: long fract __fractuqqsq (unsigned short fract A) 1671 -- Runtime Function: long long fract __fractuqqdq (unsigned short fract 1672 A) 1673 -- Runtime Function: short accum __fractuqqha (unsigned short fract A) 1674 -- Runtime Function: accum __fractuqqsa (unsigned short fract A) 1675 -- Runtime Function: long accum __fractuqqda (unsigned short fract A) 1676 -- Runtime Function: long long accum __fractuqqta (unsigned short fract 1677 A) 1678 -- Runtime Function: unsigned fract __fractuqquhq2 (unsigned short 1679 fract A) 1680 -- Runtime Function: unsigned long fract __fractuqqusq2 (unsigned short 1681 fract A) 1682 -- Runtime Function: unsigned long long fract __fractuqqudq2 (unsigned 1683 short fract A) 1684 -- Runtime Function: unsigned short accum __fractuqquha (unsigned short 1685 fract A) 1686 -- Runtime Function: unsigned accum __fractuqqusa (unsigned short fract 1687 A) 1688 -- Runtime Function: unsigned long accum __fractuqquda (unsigned short 1689 fract A) 1690 -- Runtime Function: unsigned long long accum __fractuqquta (unsigned 1691 short fract A) 1692 -- Runtime Function: signed char __fractuqqqi (unsigned short fract A) 1693 -- Runtime Function: short __fractuqqhi (unsigned short fract A) 1694 -- Runtime Function: int __fractuqqsi (unsigned short fract A) 1695 -- Runtime Function: long __fractuqqdi (unsigned short fract A) 1696 -- Runtime Function: long long __fractuqqti (unsigned short fract A) 1697 -- Runtime Function: float __fractuqqsf (unsigned short fract A) 1698 -- Runtime Function: double __fractuqqdf (unsigned short fract A) 1699 -- Runtime Function: short fract __fractuhqqq (unsigned fract A) 1700 -- Runtime Function: fract __fractuhqhq (unsigned fract A) 1701 -- Runtime Function: long fract __fractuhqsq (unsigned fract A) 1702 -- Runtime Function: long long fract __fractuhqdq (unsigned fract A) 1703 -- Runtime Function: short accum __fractuhqha (unsigned fract A) 1704 -- Runtime Function: accum __fractuhqsa (unsigned fract A) 1705 -- Runtime Function: long accum __fractuhqda (unsigned fract A) 1706 -- Runtime Function: long long accum __fractuhqta (unsigned fract A) 1707 -- Runtime Function: unsigned short fract __fractuhquqq2 (unsigned 1708 fract A) 1709 -- Runtime Function: unsigned long fract __fractuhqusq2 (unsigned fract 1710 A) 1711 -- Runtime Function: unsigned long long fract __fractuhqudq2 (unsigned 1712 fract A) 1713 -- Runtime Function: unsigned short accum __fractuhquha (unsigned fract 1714 A) 1715 -- Runtime Function: unsigned accum __fractuhqusa (unsigned fract A) 1716 -- Runtime Function: unsigned long accum __fractuhquda (unsigned fract 1717 A) 1718 -- Runtime Function: unsigned long long accum __fractuhquta (unsigned 1719 fract A) 1720 -- Runtime Function: signed char __fractuhqqi (unsigned fract A) 1721 -- Runtime Function: short __fractuhqhi (unsigned fract A) 1722 -- Runtime Function: int __fractuhqsi (unsigned fract A) 1723 -- Runtime Function: long __fractuhqdi (unsigned fract A) 1724 -- Runtime Function: long long __fractuhqti (unsigned fract A) 1725 -- Runtime Function: float __fractuhqsf (unsigned fract A) 1726 -- Runtime Function: double __fractuhqdf (unsigned fract A) 1727 -- Runtime Function: short fract __fractusqqq (unsigned long fract A) 1728 -- Runtime Function: fract __fractusqhq (unsigned long fract A) 1729 -- Runtime Function: long fract __fractusqsq (unsigned long fract A) 1730 -- Runtime Function: long long fract __fractusqdq (unsigned long fract 1731 A) 1732 -- Runtime Function: short accum __fractusqha (unsigned long fract A) 1733 -- Runtime Function: accum __fractusqsa (unsigned long fract A) 1734 -- Runtime Function: long accum __fractusqda (unsigned long fract A) 1735 -- Runtime Function: long long accum __fractusqta (unsigned long fract 1736 A) 1737 -- Runtime Function: unsigned short fract __fractusquqq2 (unsigned long 1738 fract A) 1739 -- Runtime Function: unsigned fract __fractusquhq2 (unsigned long fract 1740 A) 1741 -- Runtime Function: unsigned long long fract __fractusqudq2 (unsigned 1742 long fract A) 1743 -- Runtime Function: unsigned short accum __fractusquha (unsigned long 1744 fract A) 1745 -- Runtime Function: unsigned accum __fractusqusa (unsigned long fract 1746 A) 1747 -- Runtime Function: unsigned long accum __fractusquda (unsigned long 1748 fract A) 1749 -- Runtime Function: unsigned long long accum __fractusquta (unsigned 1750 long fract A) 1751 -- Runtime Function: signed char __fractusqqi (unsigned long fract A) 1752 -- Runtime Function: short __fractusqhi (unsigned long fract A) 1753 -- Runtime Function: int __fractusqsi (unsigned long fract A) 1754 -- Runtime Function: long __fractusqdi (unsigned long fract A) 1755 -- Runtime Function: long long __fractusqti (unsigned long fract A) 1756 -- Runtime Function: float __fractusqsf (unsigned long fract A) 1757 -- Runtime Function: double __fractusqdf (unsigned long fract A) 1758 -- Runtime Function: short fract __fractudqqq (unsigned long long fract 1759 A) 1760 -- Runtime Function: fract __fractudqhq (unsigned long long fract A) 1761 -- Runtime Function: long fract __fractudqsq (unsigned long long fract 1762 A) 1763 -- Runtime Function: long long fract __fractudqdq (unsigned long long 1764 fract A) 1765 -- Runtime Function: short accum __fractudqha (unsigned long long fract 1766 A) 1767 -- Runtime Function: accum __fractudqsa (unsigned long long fract A) 1768 -- Runtime Function: long accum __fractudqda (unsigned long long fract 1769 A) 1770 -- Runtime Function: long long accum __fractudqta (unsigned long long 1771 fract A) 1772 -- Runtime Function: unsigned short fract __fractudquqq2 (unsigned long 1773 long fract A) 1774 -- Runtime Function: unsigned fract __fractudquhq2 (unsigned long long 1775 fract A) 1776 -- Runtime Function: unsigned long fract __fractudqusq2 (unsigned long 1777 long fract A) 1778 -- Runtime Function: unsigned short accum __fractudquha (unsigned long 1779 long fract A) 1780 -- Runtime Function: unsigned accum __fractudqusa (unsigned long long 1781 fract A) 1782 -- Runtime Function: unsigned long accum __fractudquda (unsigned long 1783 long fract A) 1784 -- Runtime Function: unsigned long long accum __fractudquta (unsigned 1785 long long fract A) 1786 -- Runtime Function: signed char __fractudqqi (unsigned long long fract 1787 A) 1788 -- Runtime Function: short __fractudqhi (unsigned long long fract A) 1789 -- Runtime Function: int __fractudqsi (unsigned long long fract A) 1790 -- Runtime Function: long __fractudqdi (unsigned long long fract A) 1791 -- Runtime Function: long long __fractudqti (unsigned long long fract 1792 A) 1793 -- Runtime Function: float __fractudqsf (unsigned long long fract A) 1794 -- Runtime Function: double __fractudqdf (unsigned long long fract A) 1795 -- Runtime Function: short fract __fractuhaqq (unsigned short accum A) 1796 -- Runtime Function: fract __fractuhahq (unsigned short accum A) 1797 -- Runtime Function: long fract __fractuhasq (unsigned short accum A) 1798 -- Runtime Function: long long fract __fractuhadq (unsigned short accum 1799 A) 1800 -- Runtime Function: short accum __fractuhaha (unsigned short accum A) 1801 -- Runtime Function: accum __fractuhasa (unsigned short accum A) 1802 -- Runtime Function: long accum __fractuhada (unsigned short accum A) 1803 -- Runtime Function: long long accum __fractuhata (unsigned short accum 1804 A) 1805 -- Runtime Function: unsigned short fract __fractuhauqq (unsigned short 1806 accum A) 1807 -- Runtime Function: unsigned fract __fractuhauhq (unsigned short accum 1808 A) 1809 -- Runtime Function: unsigned long fract __fractuhausq (unsigned short 1810 accum A) 1811 -- Runtime Function: unsigned long long fract __fractuhaudq (unsigned 1812 short accum A) 1813 -- Runtime Function: unsigned accum __fractuhausa2 (unsigned short 1814 accum A) 1815 -- Runtime Function: unsigned long accum __fractuhauda2 (unsigned short 1816 accum A) 1817 -- Runtime Function: unsigned long long accum __fractuhauta2 (unsigned 1818 short accum A) 1819 -- Runtime Function: signed char __fractuhaqi (unsigned short accum A) 1820 -- Runtime Function: short __fractuhahi (unsigned short accum A) 1821 -- Runtime Function: int __fractuhasi (unsigned short accum A) 1822 -- Runtime Function: long __fractuhadi (unsigned short accum A) 1823 -- Runtime Function: long long __fractuhati (unsigned short accum A) 1824 -- Runtime Function: float __fractuhasf (unsigned short accum A) 1825 -- Runtime Function: double __fractuhadf (unsigned short accum A) 1826 -- Runtime Function: short fract __fractusaqq (unsigned accum A) 1827 -- Runtime Function: fract __fractusahq (unsigned accum A) 1828 -- Runtime Function: long fract __fractusasq (unsigned accum A) 1829 -- Runtime Function: long long fract __fractusadq (unsigned accum A) 1830 -- Runtime Function: short accum __fractusaha (unsigned accum A) 1831 -- Runtime Function: accum __fractusasa (unsigned accum A) 1832 -- Runtime Function: long accum __fractusada (unsigned accum A) 1833 -- Runtime Function: long long accum __fractusata (unsigned accum A) 1834 -- Runtime Function: unsigned short fract __fractusauqq (unsigned accum 1835 A) 1836 -- Runtime Function: unsigned fract __fractusauhq (unsigned accum A) 1837 -- Runtime Function: unsigned long fract __fractusausq (unsigned accum 1838 A) 1839 -- Runtime Function: unsigned long long fract __fractusaudq (unsigned 1840 accum A) 1841 -- Runtime Function: unsigned short accum __fractusauha2 (unsigned 1842 accum A) 1843 -- Runtime Function: unsigned long accum __fractusauda2 (unsigned accum 1844 A) 1845 -- Runtime Function: unsigned long long accum __fractusauta2 (unsigned 1846 accum A) 1847 -- Runtime Function: signed char __fractusaqi (unsigned accum A) 1848 -- Runtime Function: short __fractusahi (unsigned accum A) 1849 -- Runtime Function: int __fractusasi (unsigned accum A) 1850 -- Runtime Function: long __fractusadi (unsigned accum A) 1851 -- Runtime Function: long long __fractusati (unsigned accum A) 1852 -- Runtime Function: float __fractusasf (unsigned accum A) 1853 -- Runtime Function: double __fractusadf (unsigned accum A) 1854 -- Runtime Function: short fract __fractudaqq (unsigned long accum A) 1855 -- Runtime Function: fract __fractudahq (unsigned long accum A) 1856 -- Runtime Function: long fract __fractudasq (unsigned long accum A) 1857 -- Runtime Function: long long fract __fractudadq (unsigned long accum 1858 A) 1859 -- Runtime Function: short accum __fractudaha (unsigned long accum A) 1860 -- Runtime Function: accum __fractudasa (unsigned long accum A) 1861 -- Runtime Function: long accum __fractudada (unsigned long accum A) 1862 -- Runtime Function: long long accum __fractudata (unsigned long accum 1863 A) 1864 -- Runtime Function: unsigned short fract __fractudauqq (unsigned long 1865 accum A) 1866 -- Runtime Function: unsigned fract __fractudauhq (unsigned long accum 1867 A) 1868 -- Runtime Function: unsigned long fract __fractudausq (unsigned long 1869 accum A) 1870 -- Runtime Function: unsigned long long fract __fractudaudq (unsigned 1871 long accum A) 1872 -- Runtime Function: unsigned short accum __fractudauha2 (unsigned long 1873 accum A) 1874 -- Runtime Function: unsigned accum __fractudausa2 (unsigned long accum 1875 A) 1876 -- Runtime Function: unsigned long long accum __fractudauta2 (unsigned 1877 long accum A) 1878 -- Runtime Function: signed char __fractudaqi (unsigned long accum A) 1879 -- Runtime Function: short __fractudahi (unsigned long accum A) 1880 -- Runtime Function: int __fractudasi (unsigned long accum A) 1881 -- Runtime Function: long __fractudadi (unsigned long accum A) 1882 -- Runtime Function: long long __fractudati (unsigned long accum A) 1883 -- Runtime Function: float __fractudasf (unsigned long accum A) 1884 -- Runtime Function: double __fractudadf (unsigned long accum A) 1885 -- Runtime Function: short fract __fractutaqq (unsigned long long accum 1886 A) 1887 -- Runtime Function: fract __fractutahq (unsigned long long accum A) 1888 -- Runtime Function: long fract __fractutasq (unsigned long long accum 1889 A) 1890 -- Runtime Function: long long fract __fractutadq (unsigned long long 1891 accum A) 1892 -- Runtime Function: short accum __fractutaha (unsigned long long accum 1893 A) 1894 -- Runtime Function: accum __fractutasa (unsigned long long accum A) 1895 -- Runtime Function: long accum __fractutada (unsigned long long accum 1896 A) 1897 -- Runtime Function: long long accum __fractutata (unsigned long long 1898 accum A) 1899 -- Runtime Function: unsigned short fract __fractutauqq (unsigned long 1900 long accum A) 1901 -- Runtime Function: unsigned fract __fractutauhq (unsigned long long 1902 accum A) 1903 -- Runtime Function: unsigned long fract __fractutausq (unsigned long 1904 long accum A) 1905 -- Runtime Function: unsigned long long fract __fractutaudq (unsigned 1906 long long accum A) 1907 -- Runtime Function: unsigned short accum __fractutauha2 (unsigned long 1908 long accum A) 1909 -- Runtime Function: unsigned accum __fractutausa2 (unsigned long long 1910 accum A) 1911 -- Runtime Function: unsigned long accum __fractutauda2 (unsigned long 1912 long accum A) 1913 -- Runtime Function: signed char __fractutaqi (unsigned long long accum 1914 A) 1915 -- Runtime Function: short __fractutahi (unsigned long long accum A) 1916 -- Runtime Function: int __fractutasi (unsigned long long accum A) 1917 -- Runtime Function: long __fractutadi (unsigned long long accum A) 1918 -- Runtime Function: long long __fractutati (unsigned long long accum 1919 A) 1920 -- Runtime Function: float __fractutasf (unsigned long long accum A) 1921 -- Runtime Function: double __fractutadf (unsigned long long accum A) 1922 -- Runtime Function: short fract __fractqiqq (signed char A) 1923 -- Runtime Function: fract __fractqihq (signed char A) 1924 -- Runtime Function: long fract __fractqisq (signed char A) 1925 -- Runtime Function: long long fract __fractqidq (signed char A) 1926 -- Runtime Function: short accum __fractqiha (signed char A) 1927 -- Runtime Function: accum __fractqisa (signed char A) 1928 -- Runtime Function: long accum __fractqida (signed char A) 1929 -- Runtime Function: long long accum __fractqita (signed char A) 1930 -- Runtime Function: unsigned short fract __fractqiuqq (signed char A) 1931 -- Runtime Function: unsigned fract __fractqiuhq (signed char A) 1932 -- Runtime Function: unsigned long fract __fractqiusq (signed char A) 1933 -- Runtime Function: unsigned long long fract __fractqiudq (signed char 1934 A) 1935 -- Runtime Function: unsigned short accum __fractqiuha (signed char A) 1936 -- Runtime Function: unsigned accum __fractqiusa (signed char A) 1937 -- Runtime Function: unsigned long accum __fractqiuda (signed char A) 1938 -- Runtime Function: unsigned long long accum __fractqiuta (signed char 1939 A) 1940 -- Runtime Function: short fract __fracthiqq (short A) 1941 -- Runtime Function: fract __fracthihq (short A) 1942 -- Runtime Function: long fract __fracthisq (short A) 1943 -- Runtime Function: long long fract __fracthidq (short A) 1944 -- Runtime Function: short accum __fracthiha (short A) 1945 -- Runtime Function: accum __fracthisa (short A) 1946 -- Runtime Function: long accum __fracthida (short A) 1947 -- Runtime Function: long long accum __fracthita (short A) 1948 -- Runtime Function: unsigned short fract __fracthiuqq (short A) 1949 -- Runtime Function: unsigned fract __fracthiuhq (short A) 1950 -- Runtime Function: unsigned long fract __fracthiusq (short A) 1951 -- Runtime Function: unsigned long long fract __fracthiudq (short A) 1952 -- Runtime Function: unsigned short accum __fracthiuha (short A) 1953 -- Runtime Function: unsigned accum __fracthiusa (short A) 1954 -- Runtime Function: unsigned long accum __fracthiuda (short A) 1955 -- Runtime Function: unsigned long long accum __fracthiuta (short A) 1956 -- Runtime Function: short fract __fractsiqq (int A) 1957 -- Runtime Function: fract __fractsihq (int A) 1958 -- Runtime Function: long fract __fractsisq (int A) 1959 -- Runtime Function: long long fract __fractsidq (int A) 1960 -- Runtime Function: short accum __fractsiha (int A) 1961 -- Runtime Function: accum __fractsisa (int A) 1962 -- Runtime Function: long accum __fractsida (int A) 1963 -- Runtime Function: long long accum __fractsita (int A) 1964 -- Runtime Function: unsigned short fract __fractsiuqq (int A) 1965 -- Runtime Function: unsigned fract __fractsiuhq (int A) 1966 -- Runtime Function: unsigned long fract __fractsiusq (int A) 1967 -- Runtime Function: unsigned long long fract __fractsiudq (int A) 1968 -- Runtime Function: unsigned short accum __fractsiuha (int A) 1969 -- Runtime Function: unsigned accum __fractsiusa (int A) 1970 -- Runtime Function: unsigned long accum __fractsiuda (int A) 1971 -- Runtime Function: unsigned long long accum __fractsiuta (int A) 1972 -- Runtime Function: short fract __fractdiqq (long A) 1973 -- Runtime Function: fract __fractdihq (long A) 1974 -- Runtime Function: long fract __fractdisq (long A) 1975 -- Runtime Function: long long fract __fractdidq (long A) 1976 -- Runtime Function: short accum __fractdiha (long A) 1977 -- Runtime Function: accum __fractdisa (long A) 1978 -- Runtime Function: long accum __fractdida (long A) 1979 -- Runtime Function: long long accum __fractdita (long A) 1980 -- Runtime Function: unsigned short fract __fractdiuqq (long A) 1981 -- Runtime Function: unsigned fract __fractdiuhq (long A) 1982 -- Runtime Function: unsigned long fract __fractdiusq (long A) 1983 -- Runtime Function: unsigned long long fract __fractdiudq (long A) 1984 -- Runtime Function: unsigned short accum __fractdiuha (long A) 1985 -- Runtime Function: unsigned accum __fractdiusa (long A) 1986 -- Runtime Function: unsigned long accum __fractdiuda (long A) 1987 -- Runtime Function: unsigned long long accum __fractdiuta (long A) 1988 -- Runtime Function: short fract __fracttiqq (long long A) 1989 -- Runtime Function: fract __fracttihq (long long A) 1990 -- Runtime Function: long fract __fracttisq (long long A) 1991 -- Runtime Function: long long fract __fracttidq (long long A) 1992 -- Runtime Function: short accum __fracttiha (long long A) 1993 -- Runtime Function: accum __fracttisa (long long A) 1994 -- Runtime Function: long accum __fracttida (long long A) 1995 -- Runtime Function: long long accum __fracttita (long long A) 1996 -- Runtime Function: unsigned short fract __fracttiuqq (long long A) 1997 -- Runtime Function: unsigned fract __fracttiuhq (long long A) 1998 -- Runtime Function: unsigned long fract __fracttiusq (long long A) 1999 -- Runtime Function: unsigned long long fract __fracttiudq (long long 2000 A) 2001 -- Runtime Function: unsigned short accum __fracttiuha (long long A) 2002 -- Runtime Function: unsigned accum __fracttiusa (long long A) 2003 -- Runtime Function: unsigned long accum __fracttiuda (long long A) 2004 -- Runtime Function: unsigned long long accum __fracttiuta (long long 2005 A) 2006 -- Runtime Function: short fract __fractsfqq (float A) 2007 -- Runtime Function: fract __fractsfhq (float A) 2008 -- Runtime Function: long fract __fractsfsq (float A) 2009 -- Runtime Function: long long fract __fractsfdq (float A) 2010 -- Runtime Function: short accum __fractsfha (float A) 2011 -- Runtime Function: accum __fractsfsa (float A) 2012 -- Runtime Function: long accum __fractsfda (float A) 2013 -- Runtime Function: long long accum __fractsfta (float A) 2014 -- Runtime Function: unsigned short fract __fractsfuqq (float A) 2015 -- Runtime Function: unsigned fract __fractsfuhq (float A) 2016 -- Runtime Function: unsigned long fract __fractsfusq (float A) 2017 -- Runtime Function: unsigned long long fract __fractsfudq (float A) 2018 -- Runtime Function: unsigned short accum __fractsfuha (float A) 2019 -- Runtime Function: unsigned accum __fractsfusa (float A) 2020 -- Runtime Function: unsigned long accum __fractsfuda (float A) 2021 -- Runtime Function: unsigned long long accum __fractsfuta (float A) 2022 -- Runtime Function: short fract __fractdfqq (double A) 2023 -- Runtime Function: fract __fractdfhq (double A) 2024 -- Runtime Function: long fract __fractdfsq (double A) 2025 -- Runtime Function: long long fract __fractdfdq (double A) 2026 -- Runtime Function: short accum __fractdfha (double A) 2027 -- Runtime Function: accum __fractdfsa (double A) 2028 -- Runtime Function: long accum __fractdfda (double A) 2029 -- Runtime Function: long long accum __fractdfta (double A) 2030 -- Runtime Function: unsigned short fract __fractdfuqq (double A) 2031 -- Runtime Function: unsigned fract __fractdfuhq (double A) 2032 -- Runtime Function: unsigned long fract __fractdfusq (double A) 2033 -- Runtime Function: unsigned long long fract __fractdfudq (double A) 2034 -- Runtime Function: unsigned short accum __fractdfuha (double A) 2035 -- Runtime Function: unsigned accum __fractdfusa (double A) 2036 -- Runtime Function: unsigned long accum __fractdfuda (double A) 2037 -- Runtime Function: unsigned long long accum __fractdfuta (double A) 2038 These functions convert from fractional and signed non-fractionals 2039 to fractionals and signed non-fractionals, without saturation. 2040 2041 -- Runtime Function: fract __satfractqqhq2 (short fract A) 2042 -- Runtime Function: long fract __satfractqqsq2 (short fract A) 2043 -- Runtime Function: long long fract __satfractqqdq2 (short fract A) 2044 -- Runtime Function: short accum __satfractqqha (short fract A) 2045 -- Runtime Function: accum __satfractqqsa (short fract A) 2046 -- Runtime Function: long accum __satfractqqda (short fract A) 2047 -- Runtime Function: long long accum __satfractqqta (short fract A) 2048 -- Runtime Function: unsigned short fract __satfractqquqq (short fract 2049 A) 2050 -- Runtime Function: unsigned fract __satfractqquhq (short fract A) 2051 -- Runtime Function: unsigned long fract __satfractqqusq (short fract 2052 A) 2053 -- Runtime Function: unsigned long long fract __satfractqqudq (short 2054 fract A) 2055 -- Runtime Function: unsigned short accum __satfractqquha (short fract 2056 A) 2057 -- Runtime Function: unsigned accum __satfractqqusa (short fract A) 2058 -- Runtime Function: unsigned long accum __satfractqquda (short fract 2059 A) 2060 -- Runtime Function: unsigned long long accum __satfractqquta (short 2061 fract A) 2062 -- Runtime Function: short fract __satfracthqqq2 (fract A) 2063 -- Runtime Function: long fract __satfracthqsq2 (fract A) 2064 -- Runtime Function: long long fract __satfracthqdq2 (fract A) 2065 -- Runtime Function: short accum __satfracthqha (fract A) 2066 -- Runtime Function: accum __satfracthqsa (fract A) 2067 -- Runtime Function: long accum __satfracthqda (fract A) 2068 -- Runtime Function: long long accum __satfracthqta (fract A) 2069 -- Runtime Function: unsigned short fract __satfracthquqq (fract A) 2070 -- Runtime Function: unsigned fract __satfracthquhq (fract A) 2071 -- Runtime Function: unsigned long fract __satfracthqusq (fract A) 2072 -- Runtime Function: unsigned long long fract __satfracthqudq (fract A) 2073 -- Runtime Function: unsigned short accum __satfracthquha (fract A) 2074 -- Runtime Function: unsigned accum __satfracthqusa (fract A) 2075 -- Runtime Function: unsigned long accum __satfracthquda (fract A) 2076 -- Runtime Function: unsigned long long accum __satfracthquta (fract A) 2077 -- Runtime Function: short fract __satfractsqqq2 (long fract A) 2078 -- Runtime Function: fract __satfractsqhq2 (long fract A) 2079 -- Runtime Function: long long fract __satfractsqdq2 (long fract A) 2080 -- Runtime Function: short accum __satfractsqha (long fract A) 2081 -- Runtime Function: accum __satfractsqsa (long fract A) 2082 -- Runtime Function: long accum __satfractsqda (long fract A) 2083 -- Runtime Function: long long accum __satfractsqta (long fract A) 2084 -- Runtime Function: unsigned short fract __satfractsquqq (long fract 2085 A) 2086 -- Runtime Function: unsigned fract __satfractsquhq (long fract A) 2087 -- Runtime Function: unsigned long fract __satfractsqusq (long fract A) 2088 -- Runtime Function: unsigned long long fract __satfractsqudq (long 2089 fract A) 2090 -- Runtime Function: unsigned short accum __satfractsquha (long fract 2091 A) 2092 -- Runtime Function: unsigned accum __satfractsqusa (long fract A) 2093 -- Runtime Function: unsigned long accum __satfractsquda (long fract A) 2094 -- Runtime Function: unsigned long long accum __satfractsquta (long 2095 fract A) 2096 -- Runtime Function: short fract __satfractdqqq2 (long long fract A) 2097 -- Runtime Function: fract __satfractdqhq2 (long long fract A) 2098 -- Runtime Function: long fract __satfractdqsq2 (long long fract A) 2099 -- Runtime Function: short accum __satfractdqha (long long fract A) 2100 -- Runtime Function: accum __satfractdqsa (long long fract A) 2101 -- Runtime Function: long accum __satfractdqda (long long fract A) 2102 -- Runtime Function: long long accum __satfractdqta (long long fract A) 2103 -- Runtime Function: unsigned short fract __satfractdquqq (long long 2104 fract A) 2105 -- Runtime Function: unsigned fract __satfractdquhq (long long fract A) 2106 -- Runtime Function: unsigned long fract __satfractdqusq (long long 2107 fract A) 2108 -- Runtime Function: unsigned long long fract __satfractdqudq (long 2109 long fract A) 2110 -- Runtime Function: unsigned short accum __satfractdquha (long long 2111 fract A) 2112 -- Runtime Function: unsigned accum __satfractdqusa (long long fract A) 2113 -- Runtime Function: unsigned long accum __satfractdquda (long long 2114 fract A) 2115 -- Runtime Function: unsigned long long accum __satfractdquta (long 2116 long fract A) 2117 -- Runtime Function: short fract __satfracthaqq (short accum A) 2118 -- Runtime Function: fract __satfracthahq (short accum A) 2119 -- Runtime Function: long fract __satfracthasq (short accum A) 2120 -- Runtime Function: long long fract __satfracthadq (short accum A) 2121 -- Runtime Function: accum __satfracthasa2 (short accum A) 2122 -- Runtime Function: long accum __satfracthada2 (short accum A) 2123 -- Runtime Function: long long accum __satfracthata2 (short accum A) 2124 -- Runtime Function: unsigned short fract __satfracthauqq (short accum 2125 A) 2126 -- Runtime Function: unsigned fract __satfracthauhq (short accum A) 2127 -- Runtime Function: unsigned long fract __satfracthausq (short accum 2128 A) 2129 -- Runtime Function: unsigned long long fract __satfracthaudq (short 2130 accum A) 2131 -- Runtime Function: unsigned short accum __satfracthauha (short accum 2132 A) 2133 -- Runtime Function: unsigned accum __satfracthausa (short accum A) 2134 -- Runtime Function: unsigned long accum __satfracthauda (short accum 2135 A) 2136 -- Runtime Function: unsigned long long accum __satfracthauta (short 2137 accum A) 2138 -- Runtime Function: short fract __satfractsaqq (accum A) 2139 -- Runtime Function: fract __satfractsahq (accum A) 2140 -- Runtime Function: long fract __satfractsasq (accum A) 2141 -- Runtime Function: long long fract __satfractsadq (accum A) 2142 -- Runtime Function: short accum __satfractsaha2 (accum A) 2143 -- Runtime Function: long accum __satfractsada2 (accum A) 2144 -- Runtime Function: long long accum __satfractsata2 (accum A) 2145 -- Runtime Function: unsigned short fract __satfractsauqq (accum A) 2146 -- Runtime Function: unsigned fract __satfractsauhq (accum A) 2147 -- Runtime Function: unsigned long fract __satfractsausq (accum A) 2148 -- Runtime Function: unsigned long long fract __satfractsaudq (accum A) 2149 -- Runtime Function: unsigned short accum __satfractsauha (accum A) 2150 -- Runtime Function: unsigned accum __satfractsausa (accum A) 2151 -- Runtime Function: unsigned long accum __satfractsauda (accum A) 2152 -- Runtime Function: unsigned long long accum __satfractsauta (accum A) 2153 -- Runtime Function: short fract __satfractdaqq (long accum A) 2154 -- Runtime Function: fract __satfractdahq (long accum A) 2155 -- Runtime Function: long fract __satfractdasq (long accum A) 2156 -- Runtime Function: long long fract __satfractdadq (long accum A) 2157 -- Runtime Function: short accum __satfractdaha2 (long accum A) 2158 -- Runtime Function: accum __satfractdasa2 (long accum A) 2159 -- Runtime Function: long long accum __satfractdata2 (long accum A) 2160 -- Runtime Function: unsigned short fract __satfractdauqq (long accum 2161 A) 2162 -- Runtime Function: unsigned fract __satfractdauhq (long accum A) 2163 -- Runtime Function: unsigned long fract __satfractdausq (long accum A) 2164 -- Runtime Function: unsigned long long fract __satfractdaudq (long 2165 accum A) 2166 -- Runtime Function: unsigned short accum __satfractdauha (long accum 2167 A) 2168 -- Runtime Function: unsigned accum __satfractdausa (long accum A) 2169 -- Runtime Function: unsigned long accum __satfractdauda (long accum A) 2170 -- Runtime Function: unsigned long long accum __satfractdauta (long 2171 accum A) 2172 -- Runtime Function: short fract __satfracttaqq (long long accum A) 2173 -- Runtime Function: fract __satfracttahq (long long accum A) 2174 -- Runtime Function: long fract __satfracttasq (long long accum A) 2175 -- Runtime Function: long long fract __satfracttadq (long long accum A) 2176 -- Runtime Function: short accum __satfracttaha2 (long long accum A) 2177 -- Runtime Function: accum __satfracttasa2 (long long accum A) 2178 -- Runtime Function: long accum __satfracttada2 (long long accum A) 2179 -- Runtime Function: unsigned short fract __satfracttauqq (long long 2180 accum A) 2181 -- Runtime Function: unsigned fract __satfracttauhq (long long accum A) 2182 -- Runtime Function: unsigned long fract __satfracttausq (long long 2183 accum A) 2184 -- Runtime Function: unsigned long long fract __satfracttaudq (long 2185 long accum A) 2186 -- Runtime Function: unsigned short accum __satfracttauha (long long 2187 accum A) 2188 -- Runtime Function: unsigned accum __satfracttausa (long long accum A) 2189 -- Runtime Function: unsigned long accum __satfracttauda (long long 2190 accum A) 2191 -- Runtime Function: unsigned long long accum __satfracttauta (long 2192 long accum A) 2193 -- Runtime Function: short fract __satfractuqqqq (unsigned short fract 2194 A) 2195 -- Runtime Function: fract __satfractuqqhq (unsigned short fract A) 2196 -- Runtime Function: long fract __satfractuqqsq (unsigned short fract 2197 A) 2198 -- Runtime Function: long long fract __satfractuqqdq (unsigned short 2199 fract A) 2200 -- Runtime Function: short accum __satfractuqqha (unsigned short fract 2201 A) 2202 -- Runtime Function: accum __satfractuqqsa (unsigned short fract A) 2203 -- Runtime Function: long accum __satfractuqqda (unsigned short fract 2204 A) 2205 -- Runtime Function: long long accum __satfractuqqta (unsigned short 2206 fract A) 2207 -- Runtime Function: unsigned fract __satfractuqquhq2 (unsigned short 2208 fract A) 2209 -- Runtime Function: unsigned long fract __satfractuqqusq2 (unsigned 2210 short fract A) 2211 -- Runtime Function: unsigned long long fract __satfractuqqudq2 2212 (unsigned short fract A) 2213 -- Runtime Function: unsigned short accum __satfractuqquha (unsigned 2214 short fract A) 2215 -- Runtime Function: unsigned accum __satfractuqqusa (unsigned short 2216 fract A) 2217 -- Runtime Function: unsigned long accum __satfractuqquda (unsigned 2218 short fract A) 2219 -- Runtime Function: unsigned long long accum __satfractuqquta 2220 (unsigned short fract A) 2221 -- Runtime Function: short fract __satfractuhqqq (unsigned fract A) 2222 -- Runtime Function: fract __satfractuhqhq (unsigned fract A) 2223 -- Runtime Function: long fract __satfractuhqsq (unsigned fract A) 2224 -- Runtime Function: long long fract __satfractuhqdq (unsigned fract A) 2225 -- Runtime Function: short accum __satfractuhqha (unsigned fract A) 2226 -- Runtime Function: accum __satfractuhqsa (unsigned fract A) 2227 -- Runtime Function: long accum __satfractuhqda (unsigned fract A) 2228 -- Runtime Function: long long accum __satfractuhqta (unsigned fract A) 2229 -- Runtime Function: unsigned short fract __satfractuhquqq2 (unsigned 2230 fract A) 2231 -- Runtime Function: unsigned long fract __satfractuhqusq2 (unsigned 2232 fract A) 2233 -- Runtime Function: unsigned long long fract __satfractuhqudq2 2234 (unsigned fract A) 2235 -- Runtime Function: unsigned short accum __satfractuhquha (unsigned 2236 fract A) 2237 -- Runtime Function: unsigned accum __satfractuhqusa (unsigned fract A) 2238 -- Runtime Function: unsigned long accum __satfractuhquda (unsigned 2239 fract A) 2240 -- Runtime Function: unsigned long long accum __satfractuhquta 2241 (unsigned fract A) 2242 -- Runtime Function: short fract __satfractusqqq (unsigned long fract 2243 A) 2244 -- Runtime Function: fract __satfractusqhq (unsigned long fract A) 2245 -- Runtime Function: long fract __satfractusqsq (unsigned long fract A) 2246 -- Runtime Function: long long fract __satfractusqdq (unsigned long 2247 fract A) 2248 -- Runtime Function: short accum __satfractusqha (unsigned long fract 2249 A) 2250 -- Runtime Function: accum __satfractusqsa (unsigned long fract A) 2251 -- Runtime Function: long accum __satfractusqda (unsigned long fract A) 2252 -- Runtime Function: long long accum __satfractusqta (unsigned long 2253 fract A) 2254 -- Runtime Function: unsigned short fract __satfractusquqq2 (unsigned 2255 long fract A) 2256 -- Runtime Function: unsigned fract __satfractusquhq2 (unsigned long 2257 fract A) 2258 -- Runtime Function: unsigned long long fract __satfractusqudq2 2259 (unsigned long fract A) 2260 -- Runtime Function: unsigned short accum __satfractusquha (unsigned 2261 long fract A) 2262 -- Runtime Function: unsigned accum __satfractusqusa (unsigned long 2263 fract A) 2264 -- Runtime Function: unsigned long accum __satfractusquda (unsigned 2265 long fract A) 2266 -- Runtime Function: unsigned long long accum __satfractusquta 2267 (unsigned long fract A) 2268 -- Runtime Function: short fract __satfractudqqq (unsigned long long 2269 fract A) 2270 -- Runtime Function: fract __satfractudqhq (unsigned long long fract A) 2271 -- Runtime Function: long fract __satfractudqsq (unsigned long long 2272 fract A) 2273 -- Runtime Function: long long fract __satfractudqdq (unsigned long 2274 long fract A) 2275 -- Runtime Function: short accum __satfractudqha (unsigned long long 2276 fract A) 2277 -- Runtime Function: accum __satfractudqsa (unsigned long long fract A) 2278 -- Runtime Function: long accum __satfractudqda (unsigned long long 2279 fract A) 2280 -- Runtime Function: long long accum __satfractudqta (unsigned long 2281 long fract A) 2282 -- Runtime Function: unsigned short fract __satfractudquqq2 (unsigned 2283 long long fract A) 2284 -- Runtime Function: unsigned fract __satfractudquhq2 (unsigned long 2285 long fract A) 2286 -- Runtime Function: unsigned long fract __satfractudqusq2 (unsigned 2287 long long fract A) 2288 -- Runtime Function: unsigned short accum __satfractudquha (unsigned 2289 long long fract A) 2290 -- Runtime Function: unsigned accum __satfractudqusa (unsigned long 2291 long fract A) 2292 -- Runtime Function: unsigned long accum __satfractudquda (unsigned 2293 long long fract A) 2294 -- Runtime Function: unsigned long long accum __satfractudquta 2295 (unsigned long long fract A) 2296 -- Runtime Function: short fract __satfractuhaqq (unsigned short accum 2297 A) 2298 -- Runtime Function: fract __satfractuhahq (unsigned short accum A) 2299 -- Runtime Function: long fract __satfractuhasq (unsigned short accum 2300 A) 2301 -- Runtime Function: long long fract __satfractuhadq (unsigned short 2302 accum A) 2303 -- Runtime Function: short accum __satfractuhaha (unsigned short accum 2304 A) 2305 -- Runtime Function: accum __satfractuhasa (unsigned short accum A) 2306 -- Runtime Function: long accum __satfractuhada (unsigned short accum 2307 A) 2308 -- Runtime Function: long long accum __satfractuhata (unsigned short 2309 accum A) 2310 -- Runtime Function: unsigned short fract __satfractuhauqq (unsigned 2311 short accum A) 2312 -- Runtime Function: unsigned fract __satfractuhauhq (unsigned short 2313 accum A) 2314 -- Runtime Function: unsigned long fract __satfractuhausq (unsigned 2315 short accum A) 2316 -- Runtime Function: unsigned long long fract __satfractuhaudq 2317 (unsigned short accum A) 2318 -- Runtime Function: unsigned accum __satfractuhausa2 (unsigned short 2319 accum A) 2320 -- Runtime Function: unsigned long accum __satfractuhauda2 (unsigned 2321 short accum A) 2322 -- Runtime Function: unsigned long long accum __satfractuhauta2 2323 (unsigned short accum A) 2324 -- Runtime Function: short fract __satfractusaqq (unsigned accum A) 2325 -- Runtime Function: fract __satfractusahq (unsigned accum A) 2326 -- Runtime Function: long fract __satfractusasq (unsigned accum A) 2327 -- Runtime Function: long long fract __satfractusadq (unsigned accum A) 2328 -- Runtime Function: short accum __satfractusaha (unsigned accum A) 2329 -- Runtime Function: accum __satfractusasa (unsigned accum A) 2330 -- Runtime Function: long accum __satfractusada (unsigned accum A) 2331 -- Runtime Function: long long accum __satfractusata (unsigned accum A) 2332 -- Runtime Function: unsigned short fract __satfractusauqq (unsigned 2333 accum A) 2334 -- Runtime Function: unsigned fract __satfractusauhq (unsigned accum A) 2335 -- Runtime Function: unsigned long fract __satfractusausq (unsigned 2336 accum A) 2337 -- Runtime Function: unsigned long long fract __satfractusaudq 2338 (unsigned accum A) 2339 -- Runtime Function: unsigned short accum __satfractusauha2 (unsigned 2340 accum A) 2341 -- Runtime Function: unsigned long accum __satfractusauda2 (unsigned 2342 accum A) 2343 -- Runtime Function: unsigned long long accum __satfractusauta2 2344 (unsigned accum A) 2345 -- Runtime Function: short fract __satfractudaqq (unsigned long accum 2346 A) 2347 -- Runtime Function: fract __satfractudahq (unsigned long accum A) 2348 -- Runtime Function: long fract __satfractudasq (unsigned long accum A) 2349 -- Runtime Function: long long fract __satfractudadq (unsigned long 2350 accum A) 2351 -- Runtime Function: short accum __satfractudaha (unsigned long accum 2352 A) 2353 -- Runtime Function: accum __satfractudasa (unsigned long accum A) 2354 -- Runtime Function: long accum __satfractudada (unsigned long accum A) 2355 -- Runtime Function: long long accum __satfractudata (unsigned long 2356 accum A) 2357 -- Runtime Function: unsigned short fract __satfractudauqq (unsigned 2358 long accum A) 2359 -- Runtime Function: unsigned fract __satfractudauhq (unsigned long 2360 accum A) 2361 -- Runtime Function: unsigned long fract __satfractudausq (unsigned 2362 long accum A) 2363 -- Runtime Function: unsigned long long fract __satfractudaudq 2364 (unsigned long accum A) 2365 -- Runtime Function: unsigned short accum __satfractudauha2 (unsigned 2366 long accum A) 2367 -- Runtime Function: unsigned accum __satfractudausa2 (unsigned long 2368 accum A) 2369 -- Runtime Function: unsigned long long accum __satfractudauta2 2370 (unsigned long accum A) 2371 -- Runtime Function: short fract __satfractutaqq (unsigned long long 2372 accum A) 2373 -- Runtime Function: fract __satfractutahq (unsigned long long accum A) 2374 -- Runtime Function: long fract __satfractutasq (unsigned long long 2375 accum A) 2376 -- Runtime Function: long long fract __satfractutadq (unsigned long 2377 long accum A) 2378 -- Runtime Function: short accum __satfractutaha (unsigned long long 2379 accum A) 2380 -- Runtime Function: accum __satfractutasa (unsigned long long accum A) 2381 -- Runtime Function: long accum __satfractutada (unsigned long long 2382 accum A) 2383 -- Runtime Function: long long accum __satfractutata (unsigned long 2384 long accum A) 2385 -- Runtime Function: unsigned short fract __satfractutauqq (unsigned 2386 long long accum A) 2387 -- Runtime Function: unsigned fract __satfractutauhq (unsigned long 2388 long accum A) 2389 -- Runtime Function: unsigned long fract __satfractutausq (unsigned 2390 long long accum A) 2391 -- Runtime Function: unsigned long long fract __satfractutaudq 2392 (unsigned long long accum A) 2393 -- Runtime Function: unsigned short accum __satfractutauha2 (unsigned 2394 long long accum A) 2395 -- Runtime Function: unsigned accum __satfractutausa2 (unsigned long 2396 long accum A) 2397 -- Runtime Function: unsigned long accum __satfractutauda2 (unsigned 2398 long long accum A) 2399 -- Runtime Function: short fract __satfractqiqq (signed char A) 2400 -- Runtime Function: fract __satfractqihq (signed char A) 2401 -- Runtime Function: long fract __satfractqisq (signed char A) 2402 -- Runtime Function: long long fract __satfractqidq (signed char A) 2403 -- Runtime Function: short accum __satfractqiha (signed char A) 2404 -- Runtime Function: accum __satfractqisa (signed char A) 2405 -- Runtime Function: long accum __satfractqida (signed char A) 2406 -- Runtime Function: long long accum __satfractqita (signed char A) 2407 -- Runtime Function: unsigned short fract __satfractqiuqq (signed char 2408 A) 2409 -- Runtime Function: unsigned fract __satfractqiuhq (signed char A) 2410 -- Runtime Function: unsigned long fract __satfractqiusq (signed char 2411 A) 2412 -- Runtime Function: unsigned long long fract __satfractqiudq (signed 2413 char A) 2414 -- Runtime Function: unsigned short accum __satfractqiuha (signed char 2415 A) 2416 -- Runtime Function: unsigned accum __satfractqiusa (signed char A) 2417 -- Runtime Function: unsigned long accum __satfractqiuda (signed char 2418 A) 2419 -- Runtime Function: unsigned long long accum __satfractqiuta (signed 2420 char A) 2421 -- Runtime Function: short fract __satfracthiqq (short A) 2422 -- Runtime Function: fract __satfracthihq (short A) 2423 -- Runtime Function: long fract __satfracthisq (short A) 2424 -- Runtime Function: long long fract __satfracthidq (short A) 2425 -- Runtime Function: short accum __satfracthiha (short A) 2426 -- Runtime Function: accum __satfracthisa (short A) 2427 -- Runtime Function: long accum __satfracthida (short A) 2428 -- Runtime Function: long long accum __satfracthita (short A) 2429 -- Runtime Function: unsigned short fract __satfracthiuqq (short A) 2430 -- Runtime Function: unsigned fract __satfracthiuhq (short A) 2431 -- Runtime Function: unsigned long fract __satfracthiusq (short A) 2432 -- Runtime Function: unsigned long long fract __satfracthiudq (short A) 2433 -- Runtime Function: unsigned short accum __satfracthiuha (short A) 2434 -- Runtime Function: unsigned accum __satfracthiusa (short A) 2435 -- Runtime Function: unsigned long accum __satfracthiuda (short A) 2436 -- Runtime Function: unsigned long long accum __satfracthiuta (short A) 2437 -- Runtime Function: short fract __satfractsiqq (int A) 2438 -- Runtime Function: fract __satfractsihq (int A) 2439 -- Runtime Function: long fract __satfractsisq (int A) 2440 -- Runtime Function: long long fract __satfractsidq (int A) 2441 -- Runtime Function: short accum __satfractsiha (int A) 2442 -- Runtime Function: accum __satfractsisa (int A) 2443 -- Runtime Function: long accum __satfractsida (int A) 2444 -- Runtime Function: long long accum __satfractsita (int A) 2445 -- Runtime Function: unsigned short fract __satfractsiuqq (int A) 2446 -- Runtime Function: unsigned fract __satfractsiuhq (int A) 2447 -- Runtime Function: unsigned long fract __satfractsiusq (int A) 2448 -- Runtime Function: unsigned long long fract __satfractsiudq (int A) 2449 -- Runtime Function: unsigned short accum __satfractsiuha (int A) 2450 -- Runtime Function: unsigned accum __satfractsiusa (int A) 2451 -- Runtime Function: unsigned long accum __satfractsiuda (int A) 2452 -- Runtime Function: unsigned long long accum __satfractsiuta (int A) 2453 -- Runtime Function: short fract __satfractdiqq (long A) 2454 -- Runtime Function: fract __satfractdihq (long A) 2455 -- Runtime Function: long fract __satfractdisq (long A) 2456 -- Runtime Function: long long fract __satfractdidq (long A) 2457 -- Runtime Function: short accum __satfractdiha (long A) 2458 -- Runtime Function: accum __satfractdisa (long A) 2459 -- Runtime Function: long accum __satfractdida (long A) 2460 -- Runtime Function: long long accum __satfractdita (long A) 2461 -- Runtime Function: unsigned short fract __satfractdiuqq (long A) 2462 -- Runtime Function: unsigned fract __satfractdiuhq (long A) 2463 -- Runtime Function: unsigned long fract __satfractdiusq (long A) 2464 -- Runtime Function: unsigned long long fract __satfractdiudq (long A) 2465 -- Runtime Function: unsigned short accum __satfractdiuha (long A) 2466 -- Runtime Function: unsigned accum __satfractdiusa (long A) 2467 -- Runtime Function: unsigned long accum __satfractdiuda (long A) 2468 -- Runtime Function: unsigned long long accum __satfractdiuta (long A) 2469 -- Runtime Function: short fract __satfracttiqq (long long A) 2470 -- Runtime Function: fract __satfracttihq (long long A) 2471 -- Runtime Function: long fract __satfracttisq (long long A) 2472 -- Runtime Function: long long fract __satfracttidq (long long A) 2473 -- Runtime Function: short accum __satfracttiha (long long A) 2474 -- Runtime Function: accum __satfracttisa (long long A) 2475 -- Runtime Function: long accum __satfracttida (long long A) 2476 -- Runtime Function: long long accum __satfracttita (long long A) 2477 -- Runtime Function: unsigned short fract __satfracttiuqq (long long A) 2478 -- Runtime Function: unsigned fract __satfracttiuhq (long long A) 2479 -- Runtime Function: unsigned long fract __satfracttiusq (long long A) 2480 -- Runtime Function: unsigned long long fract __satfracttiudq (long 2481 long A) 2482 -- Runtime Function: unsigned short accum __satfracttiuha (long long A) 2483 -- Runtime Function: unsigned accum __satfracttiusa (long long A) 2484 -- Runtime Function: unsigned long accum __satfracttiuda (long long A) 2485 -- Runtime Function: unsigned long long accum __satfracttiuta (long 2486 long A) 2487 -- Runtime Function: short fract __satfractsfqq (float A) 2488 -- Runtime Function: fract __satfractsfhq (float A) 2489 -- Runtime Function: long fract __satfractsfsq (float A) 2490 -- Runtime Function: long long fract __satfractsfdq (float A) 2491 -- Runtime Function: short accum __satfractsfha (float A) 2492 -- Runtime Function: accum __satfractsfsa (float A) 2493 -- Runtime Function: long accum __satfractsfda (float A) 2494 -- Runtime Function: long long accum __satfractsfta (float A) 2495 -- Runtime Function: unsigned short fract __satfractsfuqq (float A) 2496 -- Runtime Function: unsigned fract __satfractsfuhq (float A) 2497 -- Runtime Function: unsigned long fract __satfractsfusq (float A) 2498 -- Runtime Function: unsigned long long fract __satfractsfudq (float A) 2499 -- Runtime Function: unsigned short accum __satfractsfuha (float A) 2500 -- Runtime Function: unsigned accum __satfractsfusa (float A) 2501 -- Runtime Function: unsigned long accum __satfractsfuda (float A) 2502 -- Runtime Function: unsigned long long accum __satfractsfuta (float A) 2503 -- Runtime Function: short fract __satfractdfqq (double A) 2504 -- Runtime Function: fract __satfractdfhq (double A) 2505 -- Runtime Function: long fract __satfractdfsq (double A) 2506 -- Runtime Function: long long fract __satfractdfdq (double A) 2507 -- Runtime Function: short accum __satfractdfha (double A) 2508 -- Runtime Function: accum __satfractdfsa (double A) 2509 -- Runtime Function: long accum __satfractdfda (double A) 2510 -- Runtime Function: long long accum __satfractdfta (double A) 2511 -- Runtime Function: unsigned short fract __satfractdfuqq (double A) 2512 -- Runtime Function: unsigned fract __satfractdfuhq (double A) 2513 -- Runtime Function: unsigned long fract __satfractdfusq (double A) 2514 -- Runtime Function: unsigned long long fract __satfractdfudq (double 2515 A) 2516 -- Runtime Function: unsigned short accum __satfractdfuha (double A) 2517 -- Runtime Function: unsigned accum __satfractdfusa (double A) 2518 -- Runtime Function: unsigned long accum __satfractdfuda (double A) 2519 -- Runtime Function: unsigned long long accum __satfractdfuta (double 2520 A) 2521 The functions convert from fractional and signed non-fractionals to 2522 fractionals, with saturation. 2523 2524 -- Runtime Function: unsigned char __fractunsqqqi (short fract A) 2525 -- Runtime Function: unsigned short __fractunsqqhi (short fract A) 2526 -- Runtime Function: unsigned int __fractunsqqsi (short fract A) 2527 -- Runtime Function: unsigned long __fractunsqqdi (short fract A) 2528 -- Runtime Function: unsigned long long __fractunsqqti (short fract A) 2529 -- Runtime Function: unsigned char __fractunshqqi (fract A) 2530 -- Runtime Function: unsigned short __fractunshqhi (fract A) 2531 -- Runtime Function: unsigned int __fractunshqsi (fract A) 2532 -- Runtime Function: unsigned long __fractunshqdi (fract A) 2533 -- Runtime Function: unsigned long long __fractunshqti (fract A) 2534 -- Runtime Function: unsigned char __fractunssqqi (long fract A) 2535 -- Runtime Function: unsigned short __fractunssqhi (long fract A) 2536 -- Runtime Function: unsigned int __fractunssqsi (long fract A) 2537 -- Runtime Function: unsigned long __fractunssqdi (long fract A) 2538 -- Runtime Function: unsigned long long __fractunssqti (long fract A) 2539 -- Runtime Function: unsigned char __fractunsdqqi (long long fract A) 2540 -- Runtime Function: unsigned short __fractunsdqhi (long long fract A) 2541 -- Runtime Function: unsigned int __fractunsdqsi (long long fract A) 2542 -- Runtime Function: unsigned long __fractunsdqdi (long long fract A) 2543 -- Runtime Function: unsigned long long __fractunsdqti (long long fract 2544 A) 2545 -- Runtime Function: unsigned char __fractunshaqi (short accum A) 2546 -- Runtime Function: unsigned short __fractunshahi (short accum A) 2547 -- Runtime Function: unsigned int __fractunshasi (short accum A) 2548 -- Runtime Function: unsigned long __fractunshadi (short accum A) 2549 -- Runtime Function: unsigned long long __fractunshati (short accum A) 2550 -- Runtime Function: unsigned char __fractunssaqi (accum A) 2551 -- Runtime Function: unsigned short __fractunssahi (accum A) 2552 -- Runtime Function: unsigned int __fractunssasi (accum A) 2553 -- Runtime Function: unsigned long __fractunssadi (accum A) 2554 -- Runtime Function: unsigned long long __fractunssati (accum A) 2555 -- Runtime Function: unsigned char __fractunsdaqi (long accum A) 2556 -- Runtime Function: unsigned short __fractunsdahi (long accum A) 2557 -- Runtime Function: unsigned int __fractunsdasi (long accum A) 2558 -- Runtime Function: unsigned long __fractunsdadi (long accum A) 2559 -- Runtime Function: unsigned long long __fractunsdati (long accum A) 2560 -- Runtime Function: unsigned char __fractunstaqi (long long accum A) 2561 -- Runtime Function: unsigned short __fractunstahi (long long accum A) 2562 -- Runtime Function: unsigned int __fractunstasi (long long accum A) 2563 -- Runtime Function: unsigned long __fractunstadi (long long accum A) 2564 -- Runtime Function: unsigned long long __fractunstati (long long accum 2565 A) 2566 -- Runtime Function: unsigned char __fractunsuqqqi (unsigned short 2567 fract A) 2568 -- Runtime Function: unsigned short __fractunsuqqhi (unsigned short 2569 fract A) 2570 -- Runtime Function: unsigned int __fractunsuqqsi (unsigned short fract 2571 A) 2572 -- Runtime Function: unsigned long __fractunsuqqdi (unsigned short 2573 fract A) 2574 -- Runtime Function: unsigned long long __fractunsuqqti (unsigned short 2575 fract A) 2576 -- Runtime Function: unsigned char __fractunsuhqqi (unsigned fract A) 2577 -- Runtime Function: unsigned short __fractunsuhqhi (unsigned fract A) 2578 -- Runtime Function: unsigned int __fractunsuhqsi (unsigned fract A) 2579 -- Runtime Function: unsigned long __fractunsuhqdi (unsigned fract A) 2580 -- Runtime Function: unsigned long long __fractunsuhqti (unsigned fract 2581 A) 2582 -- Runtime Function: unsigned char __fractunsusqqi (unsigned long fract 2583 A) 2584 -- Runtime Function: unsigned short __fractunsusqhi (unsigned long 2585 fract A) 2586 -- Runtime Function: unsigned int __fractunsusqsi (unsigned long fract 2587 A) 2588 -- Runtime Function: unsigned long __fractunsusqdi (unsigned long fract 2589 A) 2590 -- Runtime Function: unsigned long long __fractunsusqti (unsigned long 2591 fract A) 2592 -- Runtime Function: unsigned char __fractunsudqqi (unsigned long long 2593 fract A) 2594 -- Runtime Function: unsigned short __fractunsudqhi (unsigned long long 2595 fract A) 2596 -- Runtime Function: unsigned int __fractunsudqsi (unsigned long long 2597 fract A) 2598 -- Runtime Function: unsigned long __fractunsudqdi (unsigned long long 2599 fract A) 2600 -- Runtime Function: unsigned long long __fractunsudqti (unsigned long 2601 long fract A) 2602 -- Runtime Function: unsigned char __fractunsuhaqi (unsigned short 2603 accum A) 2604 -- Runtime Function: unsigned short __fractunsuhahi (unsigned short 2605 accum A) 2606 -- Runtime Function: unsigned int __fractunsuhasi (unsigned short accum 2607 A) 2608 -- Runtime Function: unsigned long __fractunsuhadi (unsigned short 2609 accum A) 2610 -- Runtime Function: unsigned long long __fractunsuhati (unsigned short 2611 accum A) 2612 -- Runtime Function: unsigned char __fractunsusaqi (unsigned accum A) 2613 -- Runtime Function: unsigned short __fractunsusahi (unsigned accum A) 2614 -- Runtime Function: unsigned int __fractunsusasi (unsigned accum A) 2615 -- Runtime Function: unsigned long __fractunsusadi (unsigned accum A) 2616 -- Runtime Function: unsigned long long __fractunsusati (unsigned accum 2617 A) 2618 -- Runtime Function: unsigned char __fractunsudaqi (unsigned long accum 2619 A) 2620 -- Runtime Function: unsigned short __fractunsudahi (unsigned long 2621 accum A) 2622 -- Runtime Function: unsigned int __fractunsudasi (unsigned long accum 2623 A) 2624 -- Runtime Function: unsigned long __fractunsudadi (unsigned long accum 2625 A) 2626 -- Runtime Function: unsigned long long __fractunsudati (unsigned long 2627 accum A) 2628 -- Runtime Function: unsigned char __fractunsutaqi (unsigned long long 2629 accum A) 2630 -- Runtime Function: unsigned short __fractunsutahi (unsigned long long 2631 accum A) 2632 -- Runtime Function: unsigned int __fractunsutasi (unsigned long long 2633 accum A) 2634 -- Runtime Function: unsigned long __fractunsutadi (unsigned long long 2635 accum A) 2636 -- Runtime Function: unsigned long long __fractunsutati (unsigned long 2637 long accum A) 2638 -- Runtime Function: short fract __fractunsqiqq (unsigned char A) 2639 -- Runtime Function: fract __fractunsqihq (unsigned char A) 2640 -- Runtime Function: long fract __fractunsqisq (unsigned char A) 2641 -- Runtime Function: long long fract __fractunsqidq (unsigned char A) 2642 -- Runtime Function: short accum __fractunsqiha (unsigned char A) 2643 -- Runtime Function: accum __fractunsqisa (unsigned char A) 2644 -- Runtime Function: long accum __fractunsqida (unsigned char A) 2645 -- Runtime Function: long long accum __fractunsqita (unsigned char A) 2646 -- Runtime Function: unsigned short fract __fractunsqiuqq (unsigned 2647 char A) 2648 -- Runtime Function: unsigned fract __fractunsqiuhq (unsigned char A) 2649 -- Runtime Function: unsigned long fract __fractunsqiusq (unsigned char 2650 A) 2651 -- Runtime Function: unsigned long long fract __fractunsqiudq (unsigned 2652 char A) 2653 -- Runtime Function: unsigned short accum __fractunsqiuha (unsigned 2654 char A) 2655 -- Runtime Function: unsigned accum __fractunsqiusa (unsigned char A) 2656 -- Runtime Function: unsigned long accum __fractunsqiuda (unsigned char 2657 A) 2658 -- Runtime Function: unsigned long long accum __fractunsqiuta (unsigned 2659 char A) 2660 -- Runtime Function: short fract __fractunshiqq (unsigned short A) 2661 -- Runtime Function: fract __fractunshihq (unsigned short A) 2662 -- Runtime Function: long fract __fractunshisq (unsigned short A) 2663 -- Runtime Function: long long fract __fractunshidq (unsigned short A) 2664 -- Runtime Function: short accum __fractunshiha (unsigned short A) 2665 -- Runtime Function: accum __fractunshisa (unsigned short A) 2666 -- Runtime Function: long accum __fractunshida (unsigned short A) 2667 -- Runtime Function: long long accum __fractunshita (unsigned short A) 2668 -- Runtime Function: unsigned short fract __fractunshiuqq (unsigned 2669 short A) 2670 -- Runtime Function: unsigned fract __fractunshiuhq (unsigned short A) 2671 -- Runtime Function: unsigned long fract __fractunshiusq (unsigned 2672 short A) 2673 -- Runtime Function: unsigned long long fract __fractunshiudq (unsigned 2674 short A) 2675 -- Runtime Function: unsigned short accum __fractunshiuha (unsigned 2676 short A) 2677 -- Runtime Function: unsigned accum __fractunshiusa (unsigned short A) 2678 -- Runtime Function: unsigned long accum __fractunshiuda (unsigned 2679 short A) 2680 -- Runtime Function: unsigned long long accum __fractunshiuta (unsigned 2681 short A) 2682 -- Runtime Function: short fract __fractunssiqq (unsigned int A) 2683 -- Runtime Function: fract __fractunssihq (unsigned int A) 2684 -- Runtime Function: long fract __fractunssisq (unsigned int A) 2685 -- Runtime Function: long long fract __fractunssidq (unsigned int A) 2686 -- Runtime Function: short accum __fractunssiha (unsigned int A) 2687 -- Runtime Function: accum __fractunssisa (unsigned int A) 2688 -- Runtime Function: long accum __fractunssida (unsigned int A) 2689 -- Runtime Function: long long accum __fractunssita (unsigned int A) 2690 -- Runtime Function: unsigned short fract __fractunssiuqq (unsigned int 2691 A) 2692 -- Runtime Function: unsigned fract __fractunssiuhq (unsigned int A) 2693 -- Runtime Function: unsigned long fract __fractunssiusq (unsigned int 2694 A) 2695 -- Runtime Function: unsigned long long fract __fractunssiudq (unsigned 2696 int A) 2697 -- Runtime Function: unsigned short accum __fractunssiuha (unsigned int 2698 A) 2699 -- Runtime Function: unsigned accum __fractunssiusa (unsigned int A) 2700 -- Runtime Function: unsigned long accum __fractunssiuda (unsigned int 2701 A) 2702 -- Runtime Function: unsigned long long accum __fractunssiuta (unsigned 2703 int A) 2704 -- Runtime Function: short fract __fractunsdiqq (unsigned long A) 2705 -- Runtime Function: fract __fractunsdihq (unsigned long A) 2706 -- Runtime Function: long fract __fractunsdisq (unsigned long A) 2707 -- Runtime Function: long long fract __fractunsdidq (unsigned long A) 2708 -- Runtime Function: short accum __fractunsdiha (unsigned long A) 2709 -- Runtime Function: accum __fractunsdisa (unsigned long A) 2710 -- Runtime Function: long accum __fractunsdida (unsigned long A) 2711 -- Runtime Function: long long accum __fractunsdita (unsigned long A) 2712 -- Runtime Function: unsigned short fract __fractunsdiuqq (unsigned 2713 long A) 2714 -- Runtime Function: unsigned fract __fractunsdiuhq (unsigned long A) 2715 -- Runtime Function: unsigned long fract __fractunsdiusq (unsigned long 2716 A) 2717 -- Runtime Function: unsigned long long fract __fractunsdiudq (unsigned 2718 long A) 2719 -- Runtime Function: unsigned short accum __fractunsdiuha (unsigned 2720 long A) 2721 -- Runtime Function: unsigned accum __fractunsdiusa (unsigned long A) 2722 -- Runtime Function: unsigned long accum __fractunsdiuda (unsigned long 2723 A) 2724 -- Runtime Function: unsigned long long accum __fractunsdiuta (unsigned 2725 long A) 2726 -- Runtime Function: short fract __fractunstiqq (unsigned long long A) 2727 -- Runtime Function: fract __fractunstihq (unsigned long long A) 2728 -- Runtime Function: long fract __fractunstisq (unsigned long long A) 2729 -- Runtime Function: long long fract __fractunstidq (unsigned long long 2730 A) 2731 -- Runtime Function: short accum __fractunstiha (unsigned long long A) 2732 -- Runtime Function: accum __fractunstisa (unsigned long long A) 2733 -- Runtime Function: long accum __fractunstida (unsigned long long A) 2734 -- Runtime Function: long long accum __fractunstita (unsigned long long 2735 A) 2736 -- Runtime Function: unsigned short fract __fractunstiuqq (unsigned 2737 long long A) 2738 -- Runtime Function: unsigned fract __fractunstiuhq (unsigned long long 2739 A) 2740 -- Runtime Function: unsigned long fract __fractunstiusq (unsigned long 2741 long A) 2742 -- Runtime Function: unsigned long long fract __fractunstiudq (unsigned 2743 long long A) 2744 -- Runtime Function: unsigned short accum __fractunstiuha (unsigned 2745 long long A) 2746 -- Runtime Function: unsigned accum __fractunstiusa (unsigned long long 2747 A) 2748 -- Runtime Function: unsigned long accum __fractunstiuda (unsigned long 2749 long A) 2750 -- Runtime Function: unsigned long long accum __fractunstiuta (unsigned 2751 long long A) 2752 These functions convert from fractionals to unsigned 2753 non-fractionals; and from unsigned non-fractionals to fractionals, 2754 without saturation. 2755 2756 -- Runtime Function: short fract __satfractunsqiqq (unsigned char A) 2757 -- Runtime Function: fract __satfractunsqihq (unsigned char A) 2758 -- Runtime Function: long fract __satfractunsqisq (unsigned char A) 2759 -- Runtime Function: long long fract __satfractunsqidq (unsigned char 2760 A) 2761 -- Runtime Function: short accum __satfractunsqiha (unsigned char A) 2762 -- Runtime Function: accum __satfractunsqisa (unsigned char A) 2763 -- Runtime Function: long accum __satfractunsqida (unsigned char A) 2764 -- Runtime Function: long long accum __satfractunsqita (unsigned char 2765 A) 2766 -- Runtime Function: unsigned short fract __satfractunsqiuqq (unsigned 2767 char A) 2768 -- Runtime Function: unsigned fract __satfractunsqiuhq (unsigned char 2769 A) 2770 -- Runtime Function: unsigned long fract __satfractunsqiusq (unsigned 2771 char A) 2772 -- Runtime Function: unsigned long long fract __satfractunsqiudq 2773 (unsigned char A) 2774 -- Runtime Function: unsigned short accum __satfractunsqiuha (unsigned 2775 char A) 2776 -- Runtime Function: unsigned accum __satfractunsqiusa (unsigned char 2777 A) 2778 -- Runtime Function: unsigned long accum __satfractunsqiuda (unsigned 2779 char A) 2780 -- Runtime Function: unsigned long long accum __satfractunsqiuta 2781 (unsigned char A) 2782 -- Runtime Function: short fract __satfractunshiqq (unsigned short A) 2783 -- Runtime Function: fract __satfractunshihq (unsigned short A) 2784 -- Runtime Function: long fract __satfractunshisq (unsigned short A) 2785 -- Runtime Function: long long fract __satfractunshidq (unsigned short 2786 A) 2787 -- Runtime Function: short accum __satfractunshiha (unsigned short A) 2788 -- Runtime Function: accum __satfractunshisa (unsigned short A) 2789 -- Runtime Function: long accum __satfractunshida (unsigned short A) 2790 -- Runtime Function: long long accum __satfractunshita (unsigned short 2791 A) 2792 -- Runtime Function: unsigned short fract __satfractunshiuqq (unsigned 2793 short A) 2794 -- Runtime Function: unsigned fract __satfractunshiuhq (unsigned short 2795 A) 2796 -- Runtime Function: unsigned long fract __satfractunshiusq (unsigned 2797 short A) 2798 -- Runtime Function: unsigned long long fract __satfractunshiudq 2799 (unsigned short A) 2800 -- Runtime Function: unsigned short accum __satfractunshiuha (unsigned 2801 short A) 2802 -- Runtime Function: unsigned accum __satfractunshiusa (unsigned short 2803 A) 2804 -- Runtime Function: unsigned long accum __satfractunshiuda (unsigned 2805 short A) 2806 -- Runtime Function: unsigned long long accum __satfractunshiuta 2807 (unsigned short A) 2808 -- Runtime Function: short fract __satfractunssiqq (unsigned int A) 2809 -- Runtime Function: fract __satfractunssihq (unsigned int A) 2810 -- Runtime Function: long fract __satfractunssisq (unsigned int A) 2811 -- Runtime Function: long long fract __satfractunssidq (unsigned int A) 2812 -- Runtime Function: short accum __satfractunssiha (unsigned int A) 2813 -- Runtime Function: accum __satfractunssisa (unsigned int A) 2814 -- Runtime Function: long accum __satfractunssida (unsigned int A) 2815 -- Runtime Function: long long accum __satfractunssita (unsigned int A) 2816 -- Runtime Function: unsigned short fract __satfractunssiuqq (unsigned 2817 int A) 2818 -- Runtime Function: unsigned fract __satfractunssiuhq (unsigned int A) 2819 -- Runtime Function: unsigned long fract __satfractunssiusq (unsigned 2820 int A) 2821 -- Runtime Function: unsigned long long fract __satfractunssiudq 2822 (unsigned int A) 2823 -- Runtime Function: unsigned short accum __satfractunssiuha (unsigned 2824 int A) 2825 -- Runtime Function: unsigned accum __satfractunssiusa (unsigned int A) 2826 -- Runtime Function: unsigned long accum __satfractunssiuda (unsigned 2827 int A) 2828 -- Runtime Function: unsigned long long accum __satfractunssiuta 2829 (unsigned int A) 2830 -- Runtime Function: short fract __satfractunsdiqq (unsigned long A) 2831 -- Runtime Function: fract __satfractunsdihq (unsigned long A) 2832 -- Runtime Function: long fract __satfractunsdisq (unsigned long A) 2833 -- Runtime Function: long long fract __satfractunsdidq (unsigned long 2834 A) 2835 -- Runtime Function: short accum __satfractunsdiha (unsigned long A) 2836 -- Runtime Function: accum __satfractunsdisa (unsigned long A) 2837 -- Runtime Function: long accum __satfractunsdida (unsigned long A) 2838 -- Runtime Function: long long accum __satfractunsdita (unsigned long 2839 A) 2840 -- Runtime Function: unsigned short fract __satfractunsdiuqq (unsigned 2841 long A) 2842 -- Runtime Function: unsigned fract __satfractunsdiuhq (unsigned long 2843 A) 2844 -- Runtime Function: unsigned long fract __satfractunsdiusq (unsigned 2845 long A) 2846 -- Runtime Function: unsigned long long fract __satfractunsdiudq 2847 (unsigned long A) 2848 -- Runtime Function: unsigned short accum __satfractunsdiuha (unsigned 2849 long A) 2850 -- Runtime Function: unsigned accum __satfractunsdiusa (unsigned long 2851 A) 2852 -- Runtime Function: unsigned long accum __satfractunsdiuda (unsigned 2853 long A) 2854 -- Runtime Function: unsigned long long accum __satfractunsdiuta 2855 (unsigned long A) 2856 -- Runtime Function: short fract __satfractunstiqq (unsigned long long 2857 A) 2858 -- Runtime Function: fract __satfractunstihq (unsigned long long A) 2859 -- Runtime Function: long fract __satfractunstisq (unsigned long long 2860 A) 2861 -- Runtime Function: long long fract __satfractunstidq (unsigned long 2862 long A) 2863 -- Runtime Function: short accum __satfractunstiha (unsigned long long 2864 A) 2865 -- Runtime Function: accum __satfractunstisa (unsigned long long A) 2866 -- Runtime Function: long accum __satfractunstida (unsigned long long 2867 A) 2868 -- Runtime Function: long long accum __satfractunstita (unsigned long 2869 long A) 2870 -- Runtime Function: unsigned short fract __satfractunstiuqq (unsigned 2871 long long A) 2872 -- Runtime Function: unsigned fract __satfractunstiuhq (unsigned long 2873 long A) 2874 -- Runtime Function: unsigned long fract __satfractunstiusq (unsigned 2875 long long A) 2876 -- Runtime Function: unsigned long long fract __satfractunstiudq 2877 (unsigned long long A) 2878 -- Runtime Function: unsigned short accum __satfractunstiuha (unsigned 2879 long long A) 2880 -- Runtime Function: unsigned accum __satfractunstiusa (unsigned long 2881 long A) 2882 -- Runtime Function: unsigned long accum __satfractunstiuda (unsigned 2883 long long A) 2884 -- Runtime Function: unsigned long long accum __satfractunstiuta 2885 (unsigned long long A) 2886 These functions convert from unsigned non-fractionals to 2887 fractionals, with saturation. 2888 2889 2890File: gccint.info, Node: Exception handling routines, Next: Miscellaneous routines, Prev: Fixed-point fractional library routines, Up: Libgcc 2891 28924.5 Language-independent routines for exception handling 2893======================================================== 2894 2895document me! 2896 2897 _Unwind_DeleteException 2898 _Unwind_Find_FDE 2899 _Unwind_ForcedUnwind 2900 _Unwind_GetGR 2901 _Unwind_GetIP 2902 _Unwind_GetLanguageSpecificData 2903 _Unwind_GetRegionStart 2904 _Unwind_GetTextRelBase 2905 _Unwind_GetDataRelBase 2906 _Unwind_RaiseException 2907 _Unwind_Resume 2908 _Unwind_SetGR 2909 _Unwind_SetIP 2910 _Unwind_FindEnclosingFunction 2911 _Unwind_SjLj_Register 2912 _Unwind_SjLj_Unregister 2913 _Unwind_SjLj_RaiseException 2914 _Unwind_SjLj_ForcedUnwind 2915 _Unwind_SjLj_Resume 2916 __deregister_frame 2917 __deregister_frame_info 2918 __deregister_frame_info_bases 2919 __register_frame 2920 __register_frame_info 2921 __register_frame_info_bases 2922 __register_frame_info_table 2923 __register_frame_info_table_bases 2924 __register_frame_table 2925 2926 2927File: gccint.info, Node: Miscellaneous routines, Prev: Exception handling routines, Up: Libgcc 2928 29294.6 Miscellaneous runtime library routines 2930========================================== 2931 29324.6.1 Cache control functions 2933----------------------------- 2934 2935 -- Runtime Function: void __clear_cache (char *BEG, char *END) 2936 This function clears the instruction cache between BEG and END. 2937 29384.6.2 Split stack functions and variables 2939----------------------------------------- 2940 2941 -- Runtime Function: void * __splitstack_find (void *SEGMENT_ARG, void 2942 *SP, size_t LEN, void **NEXT_SEGMENT, void **NEXT_SP, void 2943 **INITIAL_SP) 2944 When using '-fsplit-stack', this call may be used to iterate over 2945 the stack segments. It may be called like this: 2946 void *next_segment = NULL; 2947 void *next_sp = NULL; 2948 void *initial_sp = NULL; 2949 void *stack; 2950 size_t stack_size; 2951 while ((stack = __splitstack_find (next_segment, next_sp, 2952 &stack_size, &next_segment, 2953 &next_sp, &initial_sp)) 2954 != NULL) 2955 { 2956 /* Stack segment starts at stack and is 2957 stack_size bytes long. */ 2958 } 2959 2960 There is no way to iterate over the stack segments of a different 2961 thread. However, what is permitted is for one thread to call this 2962 with the SEGMENT_ARG and SP arguments NULL, to pass NEXT_SEGMENT, 2963 NEXT_SP, and INITIAL_SP to a different thread, and then to suspend 2964 one way or another. A different thread may run the subsequent 2965 '__splitstack_find' iterations. Of course, this will only work if 2966 the first thread is suspended while the second thread is calling 2967 '__splitstack_find'. If not, the second thread could be looking at 2968 the stack while it is changing, and anything could happen. 2969 2970 -- Variable: __morestack_segments 2971 -- Variable: __morestack_current_segment 2972 -- Variable: __morestack_initial_sp 2973 Internal variables used by the '-fsplit-stack' implementation. 2974 2975 2976File: gccint.info, Node: Languages, Next: Source Tree, Prev: Libgcc, Up: Top 2977 29785 Language Front Ends in GCC 2979**************************** 2980 2981The interface to front ends for languages in GCC, and in particular the 2982'tree' structure (*note GENERIC::), was initially designed for C, and 2983many aspects of it are still somewhat biased towards C and C-like 2984languages. It is, however, reasonably well suited to other procedural 2985languages, and front ends for many such languages have been written for 2986GCC. 2987 2988 Writing a compiler as a front end for GCC, rather than compiling 2989directly to assembler or generating C code which is then compiled by 2990GCC, has several advantages: 2991 2992 * GCC front ends benefit from the support for many different target 2993 machines already present in GCC. 2994 * GCC front ends benefit from all the optimizations in GCC. Some of 2995 these, such as alias analysis, may work better when GCC is 2996 compiling directly from source code then when it is compiling from 2997 generated C code. 2998 * Better debugging information is generated when compiling directly 2999 from source code than when going via intermediate generated C code. 3000 3001 Because of the advantages of writing a compiler as a GCC front end, GCC 3002front ends have also been created for languages very different from 3003those for which GCC was designed, such as the declarative 3004logic/functional language Mercury. For these reasons, it may also be 3005useful to implement compilers created for specialized purposes (for 3006example, as part of a research project) as GCC front ends. 3007 3008 3009File: gccint.info, Node: Source Tree, Next: Testsuites, Prev: Languages, Up: Top 3010 30116 Source Tree Structure and Build System 3012**************************************** 3013 3014This chapter describes the structure of the GCC source tree, and how GCC 3015is built. The user documentation for building and installing GCC is in 3016a separate manual (<http://gcc.gnu.org/install/>), with which it is 3017presumed that you are familiar. 3018 3019* Menu: 3020 3021* Configure Terms:: Configuration terminology and history. 3022* Top Level:: The top level source directory. 3023* gcc Directory:: The 'gcc' subdirectory. 3024 3025 3026File: gccint.info, Node: Configure Terms, Next: Top Level, Up: Source Tree 3027 30286.1 Configure Terms and History 3029=============================== 3030 3031The configure and build process has a long and colorful history, and can 3032be confusing to anyone who doesn't know why things are the way they are. 3033While there are other documents which describe the configuration process 3034in detail, here are a few things that everyone working on GCC should 3035know. 3036 3037 There are three system names that the build knows about: the machine 3038you are building on ("build"), the machine that you are building for 3039("host"), and the machine that GCC will produce code for ("target"). 3040When you configure GCC, you specify these with '--build=', '--host=', 3041and '--target='. 3042 3043 Specifying the host without specifying the build should be avoided, as 3044'configure' may (and once did) assume that the host you specify is also 3045the build, which may not be true. 3046 3047 If build, host, and target are all the same, this is called a "native". 3048If build and host are the same but target is different, this is called a 3049"cross". If build, host, and target are all different this is called a 3050"canadian" (for obscure reasons dealing with Canada's political party 3051and the background of the person working on the build at that time). If 3052host and target are the same, but build is different, you are using a 3053cross-compiler to build a native for a different system. Some people 3054call this a "host-x-host", "crossed native", or "cross-built native". 3055If build and target are the same, but host is different, you are using a 3056cross compiler to build a cross compiler that produces code for the 3057machine you're building on. This is rare, so there is no common way of 3058describing it. There is a proposal to call this a "crossback". 3059 3060 If build and host are the same, the GCC you are building will also be 3061used to build the target libraries (like 'libstdc++'). If build and 3062host are different, you must have already built and installed a cross 3063compiler that will be used to build the target libraries (if you 3064configured with '--target=foo-bar', this compiler will be called 3065'foo-bar-gcc'). 3066 3067 In the case of target libraries, the machine you're building for is the 3068machine you specified with '--target'. So, build is the machine you're 3069building on (no change there), host is the machine you're building for 3070(the target libraries are built for the target, so host is the target 3071you specified), and target doesn't apply (because you're not building a 3072compiler, you're building libraries). The configure/make process will 3073adjust these variables as needed. It also sets '$with_cross_host' to 3074the original '--host' value in case you need it. 3075 3076 The 'libiberty' support library is built up to three times: once for 3077the host, once for the target (even if they are the same), and once for 3078the build if build and host are different. This allows it to be used by 3079all programs which are generated in the course of the build process. 3080 3081 3082File: gccint.info, Node: Top Level, Next: gcc Directory, Prev: Configure Terms, Up: Source Tree 3083 30846.2 Top Level Source Directory 3085============================== 3086 3087The top level source directory in a GCC distribution contains several 3088files and directories that are shared with other software distributions 3089such as that of GNU Binutils. It also contains several subdirectories 3090that contain parts of GCC and its runtime libraries: 3091 3092'boehm-gc' 3093 The Boehm conservative garbage collector, optionally used as part 3094 of the ObjC runtime library when configured with 3095 '--enable-objc-gc'. 3096 3097'config' 3098 Autoconf macros and Makefile fragments used throughout the tree. 3099 3100'contrib' 3101 Contributed scripts that may be found useful in conjunction with 3102 GCC. One of these, 'contrib/texi2pod.pl', is used to generate man 3103 pages from Texinfo manuals as part of the GCC build process. 3104 3105'fixincludes' 3106 The support for fixing system headers to work with GCC. See 3107 'fixincludes/README' for more information. The headers fixed by 3108 this mechanism are installed in 'LIBSUBDIR/include-fixed'. Along 3109 with those headers, 'README-fixinc' is also installed, as 3110 'LIBSUBDIR/include-fixed/README'. 3111 3112'gcc' 3113 The main sources of GCC itself (except for runtime libraries), 3114 including optimizers, support for different target architectures, 3115 language front ends, and testsuites. *Note The 'gcc' Subdirectory: 3116 gcc Directory, for details. 3117 3118'gnattools' 3119 Support tools for GNAT. 3120 3121'include' 3122 Headers for the 'libiberty' library. 3123 3124'intl' 3125 GNU 'libintl', from GNU 'gettext', for systems which do not include 3126 it in 'libc'. 3127 3128'libada' 3129 The Ada runtime library. 3130 3131'libatomic' 3132 The runtime support library for atomic operations (e.g. for 3133 '__sync' and '__atomic'). 3134 3135'libcpp' 3136 The C preprocessor library. 3137 3138'libdecnumber' 3139 The Decimal Float support library. 3140 3141'libffi' 3142 The 'libffi' library, used as part of the Go runtime library. 3143 3144'libgcc' 3145 The GCC runtime library. 3146 3147'libgfortran' 3148 The Fortran runtime library. 3149 3150'libgo' 3151 The Go runtime library. The bulk of this library is mirrored from 3152 the master Go repository (https://github.com/golang/go). 3153 3154'libgomp' 3155 The GNU Offloading and Multi Processing Runtime Library. 3156 3157'libiberty' 3158 The 'libiberty' library, used for portability and for some 3159 generally useful data structures and algorithms. *Note 3160 Introduction: (libiberty)Top, for more information about this 3161 library. 3162 3163'libitm' 3164 The runtime support library for transactional memory. 3165 3166'libobjc' 3167 The Objective-C and Objective-C++ runtime library. 3168 3169'libquadmath' 3170 The runtime support library for quad-precision math operations. 3171 3172'libssp' 3173 The Stack protector runtime library. 3174 3175'libstdc++-v3' 3176 The C++ runtime library. 3177 3178'lto-plugin' 3179 Plugin used by the linker if link-time optimizations are enabled. 3180 3181'maintainer-scripts' 3182 Scripts used by the 'gccadmin' account on 'gcc.gnu.org'. 3183 3184'zlib' 3185 The 'zlib' compression library, used for compressing and 3186 uncompressing GCC's intermediate language in LTO object files. 3187 3188 The build system in the top level directory, including how recursion 3189into subdirectories works and how building runtime libraries for 3190multilibs is handled, is documented in a separate manual, included with 3191GNU Binutils. *Note GNU configure and build system: (configure)Top, for 3192details. 3193 3194 3195File: gccint.info, Node: gcc Directory, Prev: Top Level, Up: Source Tree 3196 31976.3 The 'gcc' Subdirectory 3198========================== 3199 3200The 'gcc' directory contains many files that are part of the C sources 3201of GCC, other files used as part of the configuration and build process, 3202and subdirectories including documentation and a testsuite. The files 3203that are sources of GCC are documented in a separate chapter. *Note 3204Passes and Files of the Compiler: Passes. 3205 3206* Menu: 3207 3208* Subdirectories:: Subdirectories of 'gcc'. 3209* Configuration:: The configuration process, and the files it uses. 3210* Build:: The build system in the 'gcc' directory. 3211* Makefile:: Targets in 'gcc/Makefile'. 3212* Library Files:: Library source files and headers under 'gcc/'. 3213* Headers:: Headers installed by GCC. 3214* Documentation:: Building documentation in GCC. 3215* Front End:: Anatomy of a language front end. 3216* Back End:: Anatomy of a target back end. 3217 3218 3219File: gccint.info, Node: Subdirectories, Next: Configuration, Up: gcc Directory 3220 32216.3.1 Subdirectories of 'gcc' 3222----------------------------- 3223 3224The 'gcc' directory contains the following subdirectories: 3225 3226'LANGUAGE' 3227 Subdirectories for various languages. Directories containing a 3228 file 'config-lang.in' are language subdirectories. The contents of 3229 the subdirectories 'c' (for C), 'cp' (for C++), 'objc' (for 3230 Objective-C), 'objcp' (for Objective-C++), and 'lto' (for LTO) are 3231 documented in this manual (*note Passes and Files of the Compiler: 3232 Passes.); those for other languages are not. *Note Anatomy of a 3233 Language Front End: Front End, for details of the files in these 3234 directories. 3235 3236'common' 3237 Source files shared between the compiler drivers (such as 'gcc') 3238 and the compilers proper (such as 'cc1'). If an architecture 3239 defines target hooks shared between those places, it also has a 3240 subdirectory in 'common/config'. *Note Target Structure::. 3241 3242'config' 3243 Configuration files for supported architectures and operating 3244 systems. *Note Anatomy of a Target Back End: Back End, for details 3245 of the files in this directory. 3246 3247'doc' 3248 Texinfo documentation for GCC, together with automatically 3249 generated man pages and support for converting the installation 3250 manual to HTML. *Note Documentation::. 3251 3252'ginclude' 3253 System headers installed by GCC, mainly those required by the C 3254 standard of freestanding implementations. *Note Headers Installed 3255 by GCC: Headers, for details of when these and other headers are 3256 installed. 3257 3258'po' 3259 Message catalogs with translations of messages produced by GCC into 3260 various languages, 'LANGUAGE.po'. This directory also contains 3261 'gcc.pot', the template for these message catalogues, 'exgettext', 3262 a wrapper around 'gettext' to extract the messages from the GCC 3263 sources and create 'gcc.pot', which is run by 'make gcc.pot', and 3264 'EXCLUDES', a list of files from which messages should not be 3265 extracted. 3266 3267'testsuite' 3268 The GCC testsuites (except for those for runtime libraries). *Note 3269 Testsuites::. 3270 3271 3272File: gccint.info, Node: Configuration, Next: Build, Prev: Subdirectories, Up: gcc Directory 3273 32746.3.2 Configuration in the 'gcc' Directory 3275------------------------------------------ 3276 3277The 'gcc' directory is configured with an Autoconf-generated script 3278'configure'. The 'configure' script is generated from 'configure.ac' 3279and 'aclocal.m4'. From the files 'configure.ac' and 'acconfig.h', 3280Autoheader generates the file 'config.in'. The file 'cstamp-h.in' is 3281used as a timestamp. 3282 3283* Menu: 3284 3285* Config Fragments:: Scripts used by 'configure'. 3286* System Config:: The 'config.build', 'config.host', and 3287 'config.gcc' files. 3288* Configuration Files:: Files created by running 'configure'. 3289 3290 3291File: gccint.info, Node: Config Fragments, Next: System Config, Up: Configuration 3292 32936.3.2.1 Scripts Used by 'configure' 3294................................... 3295 3296'configure' uses some other scripts to help in its work: 3297 3298 * The standard GNU 'config.sub' and 'config.guess' files, kept in the 3299 top level directory, are used. 3300 3301 * The file 'config.gcc' is used to handle configuration specific to 3302 the particular target machine. The file 'config.build' is used to 3303 handle configuration specific to the particular build machine. The 3304 file 'config.host' is used to handle configuration specific to the 3305 particular host machine. (In general, these should only be used 3306 for features that cannot reasonably be tested in Autoconf feature 3307 tests.) *Note The 'config.build'; 'config.host'; and 'config.gcc' 3308 Files: System Config, for details of the contents of these files. 3309 3310 * Each language subdirectory has a file 'LANGUAGE/config-lang.in' 3311 that is used for front-end-specific configuration. *Note The Front 3312 End 'config-lang.in' File: Front End Config, for details of this 3313 file. 3314 3315 * A helper script 'configure.frag' is used as part of creating the 3316 output of 'configure'. 3317 3318 3319File: gccint.info, Node: System Config, Next: Configuration Files, Prev: Config Fragments, Up: Configuration 3320 33216.3.2.2 The 'config.build'; 'config.host'; and 'config.gcc' Files 3322................................................................. 3323 3324The 'config.build' file contains specific rules for particular systems 3325which GCC is built on. This should be used as rarely as possible, as 3326the behavior of the build system can always be detected by autoconf. 3327 3328 The 'config.host' file contains specific rules for particular systems 3329which GCC will run on. This is rarely needed. 3330 3331 The 'config.gcc' file contains specific rules for particular systems 3332which GCC will generate code for. This is usually needed. 3333 3334 Each file has a list of the shell variables it sets, with descriptions, 3335at the top of the file. 3336 3337 FIXME: document the contents of these files, and what variables should 3338be set to control build, host and target configuration. 3339 3340 3341File: gccint.info, Node: Configuration Files, Prev: System Config, Up: Configuration 3342 33436.3.2.3 Files Created by 'configure' 3344.................................... 3345 3346Here we spell out what files will be set up by 'configure' in the 'gcc' 3347directory. Some other files are created as temporary files in the 3348configuration process, and are not used in the subsequent build; these 3349are not documented. 3350 3351 * 'Makefile' is constructed from 'Makefile.in', together with the 3352 host and target fragments (*note Makefile Fragments: Fragments.) 3353 't-TARGET' and 'x-HOST' from 'config', if any, and language 3354 Makefile fragments 'LANGUAGE/Make-lang.in'. 3355 * 'auto-host.h' contains information about the host machine 3356 determined by 'configure'. If the host machine is different from 3357 the build machine, then 'auto-build.h' is also created, containing 3358 such information about the build machine. 3359 * 'config.status' is a script that may be run to recreate the current 3360 configuration. 3361 * 'configargs.h' is a header containing details of the arguments 3362 passed to 'configure' to configure GCC, and of the thread model 3363 used. 3364 * 'cstamp-h' is used as a timestamp. 3365 * If a language 'config-lang.in' file (*note The Front End 3366 'config-lang.in' File: Front End Config.) sets 'outputs', then the 3367 files listed in 'outputs' there are also generated. 3368 3369 The following configuration headers are created from the Makefile, 3370using 'mkconfig.sh', rather than directly by 'configure'. 'config.h', 3371'bconfig.h' and 'tconfig.h' all contain the 'xm-MACHINE.h' header, if 3372any, appropriate to the host, build and target machines respectively, 3373the configuration headers for the target, and some definitions; for the 3374host and build machines, these include the autoconfigured headers 3375generated by 'configure'. The other configuration headers are 3376determined by 'config.gcc'. They also contain the typedefs for 'rtx', 3377'rtvec' and 'tree'. 3378 3379 * 'config.h', for use in programs that run on the host machine. 3380 * 'bconfig.h', for use in programs that run on the build machine. 3381 * 'tconfig.h', for use in programs and libraries for the target 3382 machine. 3383 * 'tm_p.h', which includes the header 'MACHINE-protos.h' that 3384 contains prototypes for functions in the target 'MACHINE.c' file. 3385 The 'MACHINE-protos.h' header is included after the 'rtl.h' and/or 3386 'tree.h' would have been included. The 'tm_p.h' also includes the 3387 header 'tm-preds.h' which is generated by 'genpreds' program during 3388 the build to define the declarations and inline functions for the 3389 predicate functions. 3390 3391 3392File: gccint.info, Node: Build, Next: Makefile, Prev: Configuration, Up: gcc Directory 3393 33946.3.3 Build System in the 'gcc' Directory 3395----------------------------------------- 3396 3397FIXME: describe the build system, including what is built in what 3398stages. Also list the various source files that are used in the build 3399process but aren't source files of GCC itself and so aren't documented 3400below (*note Passes::). 3401 3402 3403File: gccint.info, Node: Makefile, Next: Library Files, Prev: Build, Up: gcc Directory 3404 34056.3.4 Makefile Targets 3406---------------------- 3407 3408These targets are available from the 'gcc' directory: 3409 3410'all' 3411 This is the default target. Depending on what your 3412 build/host/target configuration is, it coordinates all the things 3413 that need to be built. 3414 3415'doc' 3416 Produce info-formatted documentation and man pages. Essentially it 3417 calls 'make man' and 'make info'. 3418 3419'dvi' 3420 Produce DVI-formatted documentation. 3421 3422'pdf' 3423 Produce PDF-formatted documentation. 3424 3425'html' 3426 Produce HTML-formatted documentation. 3427 3428'man' 3429 Generate man pages. 3430 3431'info' 3432 Generate info-formatted pages. 3433 3434'mostlyclean' 3435 Delete the files made while building the compiler. 3436 3437'clean' 3438 That, and all the other files built by 'make all'. 3439 3440'distclean' 3441 That, and all the files created by 'configure'. 3442 3443'maintainer-clean' 3444 Distclean plus any file that can be generated from other files. 3445 Note that additional tools may be required beyond what is normally 3446 needed to build GCC. 3447 3448'srcextra' 3449 Generates files in the source directory that are not 3450 version-controlled but should go into a release tarball. 3451 3452'srcinfo' 3453'srcman' 3454 Copies the info-formatted and manpage documentation into the source 3455 directory usually for the purpose of generating a release tarball. 3456 3457'install' 3458 Installs GCC. 3459 3460'uninstall' 3461 Deletes installed files, though this is not supported. 3462 3463'check' 3464 Run the testsuite. This creates a 'testsuite' subdirectory that 3465 has various '.sum' and '.log' files containing the results of the 3466 testing. You can run subsets with, for example, 'make check-gcc'. 3467 You can specify specific tests by setting 'RUNTESTFLAGS' to be the 3468 name of the '.exp' file, optionally followed by (for some tests) an 3469 equals and a file wildcard, like: 3470 3471 make check-gcc RUNTESTFLAGS="execute.exp=19980413-*" 3472 3473 Note that running the testsuite may require additional tools be 3474 installed, such as Tcl or DejaGnu. 3475 3476 The toplevel tree from which you start GCC compilation is not the GCC 3477directory, but rather a complex Makefile that coordinates the various 3478steps of the build, including bootstrapping the compiler and using the 3479new compiler to build target libraries. 3480 3481 When GCC is configured for a native configuration, the default action 3482for 'make' is to do a full three-stage bootstrap. This means that GCC 3483is built three times--once with the native compiler, once with the 3484native-built compiler it just built, and once with the compiler it built 3485the second time. In theory, the last two should produce the same 3486results, which 'make compare' can check. Each stage is configured 3487separately and compiled into a separate directory, to minimize problems 3488due to ABI incompatibilities between the native compiler and GCC. 3489 3490 If you do a change, rebuilding will also start from the first stage and 3491"bubble" up the change through the three stages. Each stage is taken 3492from its build directory (if it had been built previously), rebuilt, and 3493copied to its subdirectory. This will allow you to, for example, 3494continue a bootstrap after fixing a bug which causes the stage2 build to 3495crash. It does not provide as good coverage of the compiler as 3496bootstrapping from scratch, but it ensures that the new code is 3497syntactically correct (e.g., that you did not use GCC extensions by 3498mistake), and avoids spurious bootstrap comparison failures(1). 3499 3500 Other targets available from the top level include: 3501 3502'bootstrap-lean' 3503 Like 'bootstrap', except that the various stages are removed once 3504 they're no longer needed. This saves disk space. 3505 3506'bootstrap2' 3507'bootstrap2-lean' 3508 Performs only the first two stages of bootstrap. Unlike a 3509 three-stage bootstrap, this does not perform a comparison to test 3510 that the compiler is running properly. Note that the disk space 3511 required by a "lean" bootstrap is approximately independent of the 3512 number of stages. 3513 3514'stageN-bubble (N = 1...4, profile, feedback)' 3515 Rebuild all the stages up to N, with the appropriate flags, 3516 "bubbling" the changes as described above. 3517 3518'all-stageN (N = 1...4, profile, feedback)' 3519 Assuming that stage N has already been built, rebuild it with the 3520 appropriate flags. This is rarely needed. 3521 3522'cleanstrap' 3523 Remove everything ('make clean') and rebuilds ('make bootstrap'). 3524 3525'compare' 3526 Compares the results of stages 2 and 3. This ensures that the 3527 compiler is running properly, since it should produce the same 3528 object files regardless of how it itself was compiled. 3529 3530'profiledbootstrap' 3531 Builds a compiler with profiling feedback information. In this 3532 case, the second and third stages are named 'profile' and 3533 'feedback', respectively. For more information, see the 3534 installation instructions. 3535 3536'restrap' 3537 Restart a bootstrap, so that everything that was not built with the 3538 system compiler is rebuilt. 3539 3540'stageN-start (N = 1...4, profile, feedback)' 3541 For each package that is bootstrapped, rename directories so that, 3542 for example, 'gcc' points to the stageN GCC, compiled with the 3543 stageN-1 GCC(2). 3544 3545 You will invoke this target if you need to test or debug the stageN 3546 GCC. If you only need to execute GCC (but you need not run 'make' 3547 either to rebuild it or to run test suites), you should be able to 3548 work directly in the 'stageN-gcc' directory. This makes it easier 3549 to debug multiple stages in parallel. 3550 3551'stage' 3552 For each package that is bootstrapped, relocate its build directory 3553 to indicate its stage. For example, if the 'gcc' directory points 3554 to the stage2 GCC, after invoking this target it will be renamed to 3555 'stage2-gcc'. 3556 3557 If you wish to use non-default GCC flags when compiling the stage2 and 3558stage3 compilers, set 'BOOT_CFLAGS' on the command line when doing 3559'make'. 3560 3561 Usually, the first stage only builds the languages that the compiler is 3562written in: typically, C and maybe Ada. If you are debugging a 3563miscompilation of a different stage2 front-end (for example, of the 3564Fortran front-end), you may want to have front-ends for other languages 3565in the first stage as well. To do so, set 'STAGE1_LANGUAGES' on the 3566command line when doing 'make'. 3567 3568 For example, in the aforementioned scenario of debugging a Fortran 3569front-end miscompilation caused by the stage1 compiler, you may need a 3570command like 3571 3572 make stage2-bubble STAGE1_LANGUAGES=c,fortran 3573 3574 Alternatively, you can use per-language targets to build and test 3575languages that are not enabled by default in stage1. For example, 'make 3576f951' will build a Fortran compiler even in the stage1 build directory. 3577 3578 ---------- Footnotes ---------- 3579 3580 (1) Except if the compiler was buggy and miscompiled some of the 3581files that were not modified. In this case, it's best to use 'make 3582restrap'. 3583 3584 (2) Customarily, the system compiler is also termed the 'stage0' GCC. 3585 3586 3587File: gccint.info, Node: Library Files, Next: Headers, Prev: Makefile, Up: gcc Directory 3588 35896.3.5 Library Source Files and Headers under the 'gcc' Directory 3590---------------------------------------------------------------- 3591 3592FIXME: list here, with explanation, all the C source files and headers 3593under the 'gcc' directory that aren't built into the GCC executable but 3594rather are part of runtime libraries and object files, such as 3595'crtstuff.c' and 'unwind-dw2.c'. *Note Headers Installed by GCC: 3596Headers, for more information about the 'ginclude' directory. 3597 3598 3599File: gccint.info, Node: Headers, Next: Documentation, Prev: Library Files, Up: gcc Directory 3600 36016.3.6 Headers Installed by GCC 3602------------------------------ 3603 3604In general, GCC expects the system C library to provide most of the 3605headers to be used with it. However, GCC will fix those headers if 3606necessary to make them work with GCC, and will install some headers 3607required of freestanding implementations. These headers are installed 3608in 'LIBSUBDIR/include'. Headers for non-C runtime libraries are also 3609installed by GCC; these are not documented here. (FIXME: document them 3610somewhere.) 3611 3612 Several of the headers GCC installs are in the 'ginclude' directory. 3613These headers, 'iso646.h', 'stdarg.h', 'stdbool.h', and 'stddef.h', are 3614installed in 'LIBSUBDIR/include', unless the target Makefile fragment 3615(*note Target Fragment::) overrides this by setting 'USER_H'. 3616 3617 In addition to these headers and those generated by fixing system 3618headers to work with GCC, some other headers may also be installed in 3619'LIBSUBDIR/include'. 'config.gcc' may set 'extra_headers'; this 3620specifies additional headers under 'config' to be installed on some 3621systems. 3622 3623 GCC installs its own version of '<float.h>', from 'ginclude/float.h'. 3624This is done to cope with command-line options that change the 3625representation of floating point numbers. 3626 3627 GCC also installs its own version of '<limits.h>'; this is generated 3628from 'glimits.h', together with 'limitx.h' and 'limity.h' if the system 3629also has its own version of '<limits.h>'. (GCC provides its own header 3630because it is required of ISO C freestanding implementations, but needs 3631to include the system header from its own header as well because other 3632standards such as POSIX specify additional values to be defined in 3633'<limits.h>'.) The system's '<limits.h>' header is used via 3634'LIBSUBDIR/include/syslimits.h', which is copied from 'gsyslimits.h' if 3635it does not need fixing to work with GCC; if it needs fixing, 3636'syslimits.h' is the fixed copy. 3637 3638 GCC can also install '<tgmath.h>'. It will do this when 'config.gcc' 3639sets 'use_gcc_tgmath' to 'yes'. 3640 3641 3642File: gccint.info, Node: Documentation, Next: Front End, Prev: Headers, Up: gcc Directory 3643 36446.3.7 Building Documentation 3645---------------------------- 3646 3647The main GCC documentation is in the form of manuals in Texinfo format. 3648These are installed in Info format; DVI versions may be generated by 3649'make dvi', PDF versions by 'make pdf', and HTML versions by 'make 3650html'. In addition, some man pages are generated from the Texinfo 3651manuals, there are some other text files with miscellaneous 3652documentation, and runtime libraries have their own documentation 3653outside the 'gcc' directory. FIXME: document the documentation for 3654runtime libraries somewhere. 3655 3656* Menu: 3657 3658* Texinfo Manuals:: GCC manuals in Texinfo format. 3659* Man Page Generation:: Generating man pages from Texinfo manuals. 3660* Miscellaneous Docs:: Miscellaneous text files with documentation. 3661 3662 3663File: gccint.info, Node: Texinfo Manuals, Next: Man Page Generation, Up: Documentation 3664 36656.3.7.1 Texinfo Manuals 3666....................... 3667 3668The manuals for GCC as a whole, and the C and C++ front ends, are in 3669files 'doc/*.texi'. Other front ends have their own manuals in files 3670'LANGUAGE/*.texi'. Common files 'doc/include/*.texi' are provided which 3671may be included in multiple manuals; the following files are in 3672'doc/include': 3673 3674'fdl.texi' 3675 The GNU Free Documentation License. 3676'funding.texi' 3677 The section "Funding Free Software". 3678'gcc-common.texi' 3679 Common definitions for manuals. 3680'gpl_v3.texi' 3681 The GNU General Public License. 3682'texinfo.tex' 3683 A copy of 'texinfo.tex' known to work with the GCC manuals. 3684 3685 DVI-formatted manuals are generated by 'make dvi', which uses 3686'texi2dvi' (via the Makefile macro '$(TEXI2DVI)'). PDF-formatted 3687manuals are generated by 'make pdf', which uses 'texi2pdf' (via the 3688Makefile macro '$(TEXI2PDF)'). HTML formatted manuals are generated by 3689'make html'. Info manuals are generated by 'make info' (which is run as 3690part of a bootstrap); this generates the manuals in the source 3691directory, using 'makeinfo' via the Makefile macro '$(MAKEINFO)', and 3692they are included in release distributions. 3693 3694 Manuals are also provided on the GCC web site, in both HTML and 3695PostScript forms. This is done via the script 3696'maintainer-scripts/update_web_docs_svn'. Each manual to be provided 3697online must be listed in the definition of 'MANUALS' in that file; a 3698file 'NAME.texi' must only appear once in the source tree, and the 3699output manual must have the same name as the source file. (However, 3700other Texinfo files, included in manuals but not themselves the root 3701files of manuals, may have names that appear more than once in the 3702source tree.) The manual file 'NAME.texi' should only include other 3703files in its own directory or in 'doc/include'. HTML manuals will be 3704generated by 'makeinfo --html', PostScript manuals by 'texi2dvi' and 3705'dvips', and PDF manuals by 'texi2pdf'. All Texinfo files that are 3706parts of manuals must be version-controlled, even if they are generated 3707files, for the generation of online manuals to work. 3708 3709 The installation manual, 'doc/install.texi', is also provided on the 3710GCC web site. The HTML version is generated by the script 3711'doc/install.texi2html'. 3712 3713 3714File: gccint.info, Node: Man Page Generation, Next: Miscellaneous Docs, Prev: Texinfo Manuals, Up: Documentation 3715 37166.3.7.2 Man Page Generation 3717........................... 3718 3719Because of user demand, in addition to full Texinfo manuals, man pages 3720are provided which contain extracts from those manuals. These man pages 3721are generated from the Texinfo manuals using 'contrib/texi2pod.pl' and 3722'pod2man'. (The man page for 'g++', 'cp/g++.1', just contains a '.so' 3723reference to 'gcc.1', but all the other man pages are generated from 3724Texinfo manuals.) 3725 3726 Because many systems may not have the necessary tools installed to 3727generate the man pages, they are only generated if the 'configure' 3728script detects that recent enough tools are installed, and the Makefiles 3729allow generating man pages to fail without aborting the build. Man 3730pages are also included in release distributions. They are generated in 3731the source directory. 3732 3733 Magic comments in Texinfo files starting '@c man' control what parts of 3734a Texinfo file go into a man page. Only a subset of Texinfo is 3735supported by 'texi2pod.pl', and it may be necessary to add support for 3736more Texinfo features to this script when generating new man pages. To 3737improve the man page output, some special Texinfo macros are provided in 3738'doc/include/gcc-common.texi' which 'texi2pod.pl' understands: 3739 3740'@gcctabopt' 3741 Use in the form '@table @gcctabopt' for tables of options, where 3742 for printed output the effect of '@code' is better than that of 3743 '@option' but for man page output a different effect is wanted. 3744'@gccoptlist' 3745 Use for summary lists of options in manuals. 3746'@gol' 3747 Use at the end of each line inside '@gccoptlist'. This is 3748 necessary to avoid problems with differences in how the 3749 '@gccoptlist' macro is handled by different Texinfo formatters. 3750 3751 FIXME: describe the 'texi2pod.pl' input language and magic comments in 3752more detail. 3753 3754 3755File: gccint.info, Node: Miscellaneous Docs, Prev: Man Page Generation, Up: Documentation 3756 37576.3.7.3 Miscellaneous Documentation 3758................................... 3759 3760In addition to the formal documentation that is installed by GCC, there 3761are several other text files in the 'gcc' subdirectory with 3762miscellaneous documentation: 3763 3764'ABOUT-GCC-NLS' 3765 Notes on GCC's Native Language Support. FIXME: this should be part 3766 of this manual rather than a separate file. 3767'ABOUT-NLS' 3768 Notes on the Free Translation Project. 3769'COPYING' 3770'COPYING3' 3771 The GNU General Public License, Versions 2 and 3. 3772'COPYING.LIB' 3773'COPYING3.LIB' 3774 The GNU Lesser General Public License, Versions 2.1 and 3. 3775'*ChangeLog*' 3776'*/ChangeLog*' 3777 Change log files for various parts of GCC. 3778'LANGUAGES' 3779 Details of a few changes to the GCC front-end interface. FIXME: 3780 the information in this file should be part of general 3781 documentation of the front-end interface in this manual. 3782'ONEWS' 3783 Information about new features in old versions of GCC. (For recent 3784 versions, the information is on the GCC web site.) 3785'README.Portability' 3786 Information about portability issues when writing code in GCC. 3787 FIXME: why isn't this part of this manual or of the GCC Coding 3788 Conventions? 3789 3790 FIXME: document such files in subdirectories, at least 'config', 'c', 3791'cp', 'objc', 'testsuite'. 3792 3793 3794File: gccint.info, Node: Front End, Next: Back End, Prev: Documentation, Up: gcc Directory 3795 37966.3.8 Anatomy of a Language Front End 3797------------------------------------- 3798 3799A front end for a language in GCC has the following parts: 3800 3801 * A directory 'LANGUAGE' under 'gcc' containing source files for that 3802 front end. *Note The Front End 'LANGUAGE' Directory: Front End 3803 Directory, for details. 3804 * A mention of the language in the list of supported languages in 3805 'gcc/doc/install.texi'. 3806 * A mention of the name under which the language's runtime library is 3807 recognized by '--enable-shared=PACKAGE' in the documentation of 3808 that option in 'gcc/doc/install.texi'. 3809 * A mention of any special prerequisites for building the front end 3810 in the documentation of prerequisites in 'gcc/doc/install.texi'. 3811 * Details of contributors to that front end in 3812 'gcc/doc/contrib.texi'. If the details are in that front end's own 3813 manual then there should be a link to that manual's list in 3814 'contrib.texi'. 3815 * Information about support for that language in 3816 'gcc/doc/frontends.texi'. 3817 * Information about standards for that language, and the front end's 3818 support for them, in 'gcc/doc/standards.texi'. This may be a link 3819 to such information in the front end's own manual. 3820 * Details of source file suffixes for that language and '-x LANG' 3821 options supported, in 'gcc/doc/invoke.texi'. 3822 * Entries in 'default_compilers' in 'gcc.c' for source file suffixes 3823 for that language. 3824 * Preferably testsuites, which may be under 'gcc/testsuite' or 3825 runtime library directories. FIXME: document somewhere how to 3826 write testsuite harnesses. 3827 * Probably a runtime library for the language, outside the 'gcc' 3828 directory. FIXME: document this further. 3829 * Details of the directories of any runtime libraries in 3830 'gcc/doc/sourcebuild.texi'. 3831 * Check targets in 'Makefile.def' for the top-level 'Makefile' to 3832 check just the compiler or the compiler and runtime library for the 3833 language. 3834 3835 If the front end is added to the official GCC source repository, the 3836following are also necessary: 3837 3838 * At least one Bugzilla component for bugs in that front end and 3839 runtime libraries. This category needs to be added to the Bugzilla 3840 database. 3841 * Normally, one or more maintainers of that front end listed in 3842 'MAINTAINERS'. 3843 * Mentions on the GCC web site in 'index.html' and 'frontends.html', 3844 with any relevant links on 'readings.html'. (Front ends that are 3845 not an official part of GCC may also be listed on 'frontends.html', 3846 with relevant links.) 3847 * A news item on 'index.html', and possibly an announcement on the 3848 <gcc-announce@gcc.gnu.org> mailing list. 3849 * The front end's manuals should be mentioned in 3850 'maintainer-scripts/update_web_docs_svn' (*note Texinfo Manuals::) 3851 and the online manuals should be linked to from 3852 'onlinedocs/index.html'. 3853 * Any old releases or CVS repositories of the front end, before its 3854 inclusion in GCC, should be made available on the GCC FTP site 3855 <ftp://gcc.gnu.org/pub/gcc/old-releases/>. 3856 * The release and snapshot script 'maintainer-scripts/gcc_release' 3857 should be updated to generate appropriate tarballs for this front 3858 end. 3859 * If this front end includes its own version files that include the 3860 current date, 'maintainer-scripts/update_version' should be updated 3861 accordingly. 3862 3863* Menu: 3864 3865* Front End Directory:: The front end 'LANGUAGE' directory. 3866* Front End Config:: The front end 'config-lang.in' file. 3867* Front End Makefile:: The front end 'Make-lang.in' file. 3868 3869 3870File: gccint.info, Node: Front End Directory, Next: Front End Config, Up: Front End 3871 38726.3.8.1 The Front End 'LANGUAGE' Directory 3873.......................................... 3874 3875A front end 'LANGUAGE' directory contains the source files of that front 3876end (but not of any runtime libraries, which should be outside the 'gcc' 3877directory). This includes documentation, and possibly some subsidiary 3878programs built alongside the front end. Certain files are special and 3879other parts of the compiler depend on their names: 3880 3881'config-lang.in' 3882 This file is required in all language subdirectories. *Note The 3883 Front End 'config-lang.in' File: Front End Config, for details of 3884 its contents 3885'Make-lang.in' 3886 This file is required in all language subdirectories. *Note The 3887 Front End 'Make-lang.in' File: Front End Makefile, for details of 3888 its contents. 3889'lang.opt' 3890 This file registers the set of switches that the front end accepts 3891 on the command line, and their '--help' text. *Note Options::. 3892'lang-specs.h' 3893 This file provides entries for 'default_compilers' in 'gcc.c' which 3894 override the default of giving an error that a compiler for that 3895 language is not installed. 3896'LANGUAGE-tree.def' 3897 This file, which need not exist, defines any language-specific tree 3898 codes. 3899 3900 3901File: gccint.info, Node: Front End Config, Next: Front End Makefile, Prev: Front End Directory, Up: Front End 3902 39036.3.8.2 The Front End 'config-lang.in' File 3904........................................... 3905 3906Each language subdirectory contains a 'config-lang.in' file. This file 3907is a shell script that may define some variables describing the 3908language: 3909 3910'language' 3911 This definition must be present, and gives the name of the language 3912 for some purposes such as arguments to '--enable-languages'. 3913'lang_requires' 3914 If defined, this variable lists (space-separated) language front 3915 ends other than C that this front end requires to be enabled (with 3916 the names given being their 'language' settings). For example, the 3917 Obj-C++ front end depends on the C++ and ObjC front ends, so sets 3918 'lang_requires="objc c++"'. 3919'subdir_requires' 3920 If defined, this variable lists (space-separated) front end 3921 directories other than C that this front end requires to be 3922 present. For example, the Objective-C++ front end uses source 3923 files from the C++ and Objective-C front ends, so sets 3924 'subdir_requires="cp objc"'. 3925'target_libs' 3926 If defined, this variable lists (space-separated) targets in the 3927 top level 'Makefile' to build the runtime libraries for this 3928 language, such as 'target-libobjc'. 3929'lang_dirs' 3930 If defined, this variable lists (space-separated) top level 3931 directories (parallel to 'gcc'), apart from the runtime libraries, 3932 that should not be configured if this front end is not built. 3933'build_by_default' 3934 If defined to 'no', this language front end is not built unless 3935 enabled in a '--enable-languages' argument. Otherwise, front ends 3936 are built by default, subject to any special logic in 3937 'configure.ac' (as is present to disable the Ada front end if the 3938 Ada compiler is not already installed). 3939'boot_language' 3940 If defined to 'yes', this front end is built in stage1 of the 3941 bootstrap. This is only relevant to front ends written in their 3942 own languages. 3943'compilers' 3944 If defined, a space-separated list of compiler executables that 3945 will be run by the driver. The names here will each end with 3946 '\$(exeext)'. 3947'outputs' 3948 If defined, a space-separated list of files that should be 3949 generated by 'configure' substituting values in them. This 3950 mechanism can be used to create a file 'LANGUAGE/Makefile' from 3951 'LANGUAGE/Makefile.in', but this is deprecated, building everything 3952 from the single 'gcc/Makefile' is preferred. 3953'gtfiles' 3954 If defined, a space-separated list of files that should be scanned 3955 by 'gengtype.c' to generate the garbage collection tables and 3956 routines for this language. This excludes the files that are 3957 common to all front ends. *Note Type Information::. 3958 3959 3960File: gccint.info, Node: Front End Makefile, Prev: Front End Config, Up: Front End 3961 39626.3.8.3 The Front End 'Make-lang.in' File 3963......................................... 3964 3965Each language subdirectory contains a 'Make-lang.in' file. It contains 3966targets 'LANG.HOOK' (where 'LANG' is the setting of 'language' in 3967'config-lang.in') for the following values of 'HOOK', and any other 3968Makefile rules required to build those targets (which may if necessary 3969use other Makefiles specified in 'outputs' in 'config-lang.in', although 3970this is deprecated). It also adds any testsuite targets that can use 3971the standard rule in 'gcc/Makefile.in' to the variable 'lang_checks'. 3972 3973'all.cross' 3974'start.encap' 3975'rest.encap' 3976 FIXME: exactly what goes in each of these targets? 3977'tags' 3978 Build an 'etags' 'TAGS' file in the language subdirectory in the 3979 source tree. 3980'info' 3981 Build info documentation for the front end, in the build directory. 3982 This target is only called by 'make bootstrap' if a suitable 3983 version of 'makeinfo' is available, so does not need to check for 3984 this, and should fail if an error occurs. 3985'dvi' 3986 Build DVI documentation for the front end, in the build directory. 3987 This should be done using '$(TEXI2DVI)', with appropriate '-I' 3988 arguments pointing to directories of included files. 3989'pdf' 3990 Build PDF documentation for the front end, in the build directory. 3991 This should be done using '$(TEXI2PDF)', with appropriate '-I' 3992 arguments pointing to directories of included files. 3993'html' 3994 Build HTML documentation for the front end, in the build directory. 3995'man' 3996 Build generated man pages for the front end from Texinfo manuals 3997 (*note Man Page Generation::), in the build directory. This target 3998 is only called if the necessary tools are available, but should 3999 ignore errors so as not to stop the build if errors occur; man 4000 pages are optional and the tools involved may be installed in a 4001 broken way. 4002'install-common' 4003 Install everything that is part of the front end, apart from the 4004 compiler executables listed in 'compilers' in 'config-lang.in'. 4005'install-info' 4006 Install info documentation for the front end, if it is present in 4007 the source directory. This target should have dependencies on info 4008 files that should be installed. 4009'install-man' 4010 Install man pages for the front end. This target should ignore 4011 errors. 4012'install-plugin' 4013 Install headers needed for plugins. 4014'srcextra' 4015 Copies its dependencies into the source directory. This generally 4016 should be used for generated files such as Bison output files which 4017 are not version-controlled, but should be included in any release 4018 tarballs. This target will be executed during a bootstrap if 4019 '--enable-generated-files-in-srcdir' was specified as a 'configure' 4020 option. 4021'srcinfo' 4022'srcman' 4023 Copies its dependencies into the source directory. These targets 4024 will be executed during a bootstrap if 4025 '--enable-generated-files-in-srcdir' was specified as a 'configure' 4026 option. 4027'uninstall' 4028 Uninstall files installed by installing the compiler. This is 4029 currently documented not to be supported, so the hook need not do 4030 anything. 4031'mostlyclean' 4032'clean' 4033'distclean' 4034'maintainer-clean' 4035 The language parts of the standard GNU '*clean' targets. *Note 4036 Standard Targets for Users: (standards)Standard Targets, for 4037 details of the standard targets. For GCC, 'maintainer-clean' 4038 should delete all generated files in the source directory that are 4039 not version-controlled, but should not delete anything that is. 4040 4041 'Make-lang.in' must also define a variable 'LANG_OBJS' to a list of 4042host object files that are used by that language. 4043 4044 4045File: gccint.info, Node: Back End, Prev: Front End, Up: gcc Directory 4046 40476.3.9 Anatomy of a Target Back End 4048---------------------------------- 4049 4050A back end for a target architecture in GCC has the following parts: 4051 4052 * A directory 'MACHINE' under 'gcc/config', containing a machine 4053 description 'MACHINE.md' file (*note Machine Descriptions: Machine 4054 Desc.), header files 'MACHINE.h' and 'MACHINE-protos.h' and a 4055 source file 'MACHINE.c' (*note Target Description Macros and 4056 Functions: Target Macros.), possibly a target Makefile fragment 4057 't-MACHINE' (*note The Target Makefile Fragment: Target Fragment.), 4058 and maybe some other files. The names of these files may be 4059 changed from the defaults given by explicit specifications in 4060 'config.gcc'. 4061 * If necessary, a file 'MACHINE-modes.def' in the 'MACHINE' 4062 directory, containing additional machine modes to represent 4063 condition codes. *Note Condition Code::, for further details. 4064 * An optional 'MACHINE.opt' file in the 'MACHINE' directory, 4065 containing a list of target-specific options. You can also add 4066 other option files using the 'extra_options' variable in 4067 'config.gcc'. *Note Options::. 4068 * Entries in 'config.gcc' (*note The 'config.gcc' File: System 4069 Config.) for the systems with this target architecture. 4070 * Documentation in 'gcc/doc/invoke.texi' for any command-line options 4071 supported by this target (*note Run-time Target Specification: 4072 Run-time Target.). This means both entries in the summary table of 4073 options and details of the individual options. 4074 * Documentation in 'gcc/doc/extend.texi' for any target-specific 4075 attributes supported (*note Defining target-specific uses of 4076 '__attribute__': Target Attributes.), including where the same 4077 attribute is already supported on some targets, which are 4078 enumerated in the manual. 4079 * Documentation in 'gcc/doc/extend.texi' for any target-specific 4080 pragmas supported. 4081 * Documentation in 'gcc/doc/extend.texi' of any target-specific 4082 built-in functions supported. 4083 * Documentation in 'gcc/doc/extend.texi' of any target-specific 4084 format checking styles supported. 4085 * Documentation in 'gcc/doc/md.texi' of any target-specific 4086 constraint letters (*note Constraints for Particular Machines: 4087 Machine Constraints.). 4088 * A note in 'gcc/doc/contrib.texi' under the person or people who 4089 contributed the target support. 4090 * Entries in 'gcc/doc/install.texi' for all target triplets supported 4091 with this target architecture, giving details of any special notes 4092 about installation for this target, or saying that there are no 4093 special notes if there are none. 4094 * Possibly other support outside the 'gcc' directory for runtime 4095 libraries. FIXME: reference docs for this. The 'libstdc++' 4096 porting manual needs to be installed as info for this to work, or 4097 to be a chapter of this manual. 4098 4099 The 'MACHINE.h' header is included very early in GCC's standard 4100sequence of header files, while 'MACHINE-protos.h' is included late in 4101the sequence. Thus 'MACHINE-protos.h' can include declarations 4102referencing types that are not defined when 'MACHINE.h' is included, 4103specifically including those from 'rtl.h' and 'tree.h'. Since both RTL 4104and tree types may not be available in every context where 4105'MACHINE-protos.h' is included, in this file you should guard 4106declarations using these types inside appropriate '#ifdef RTX_CODE' or 4107'#ifdef TREE_CODE' conditional code segments. 4108 4109 If the backend uses shared data structures that require 'GTY' markers 4110for garbage collection (*note Type Information::), you must declare 4111those in 'MACHINE.h' rather than 'MACHINE-protos.h'. Any definitions 4112required for building libgcc must also go in 'MACHINE.h'. 4113 4114 GCC uses the macro 'IN_TARGET_CODE' to distinguish between 4115machine-specific '.c' and '.cc' files and machine-independent '.c' and 4116'.cc' files. Machine-specific files should use the directive: 4117 4118 #define IN_TARGET_CODE 1 4119 4120 before including 'config.h'. 4121 4122 If the back end is added to the official GCC source repository, the 4123following are also necessary: 4124 4125 * An entry for the target architecture in 'readings.html' on the GCC 4126 web site, with any relevant links. 4127 * Details of the properties of the back end and target architecture 4128 in 'backends.html' on the GCC web site. 4129 * A news item about the contribution of support for that target 4130 architecture, in 'index.html' on the GCC web site. 4131 * Normally, one or more maintainers of that target listed in 4132 'MAINTAINERS'. Some existing architectures may be unmaintained, 4133 but it would be unusual to add support for a target that does not 4134 have a maintainer when support is added. 4135 * Target triplets covering all 'config.gcc' stanzas for the target, 4136 in the list in 'contrib/config-list.mk'. 4137 4138 4139File: gccint.info, Node: Testsuites, Next: Options, Prev: Source Tree, Up: Top 4140 41417 Testsuites 4142************ 4143 4144GCC contains several testsuites to help maintain compiler quality. Most 4145of the runtime libraries and language front ends in GCC have testsuites. 4146Currently only the C language testsuites are documented here; FIXME: 4147document the others. 4148 4149* Menu: 4150 4151* Test Idioms:: Idioms used in testsuite code. 4152* Test Directives:: Directives used within DejaGnu tests. 4153* Ada Tests:: The Ada language testsuites. 4154* C Tests:: The C language testsuites. 4155* LTO Testing:: Support for testing link-time optimizations. 4156* gcov Testing:: Support for testing gcov. 4157* profopt Testing:: Support for testing profile-directed optimizations. 4158* compat Testing:: Support for testing binary compatibility. 4159* Torture Tests:: Support for torture testing using multiple options. 4160* GIMPLE Tests:: Support for testing GIMPLE passes. 4161* RTL Tests:: Support for testing RTL passes. 4162 4163 4164File: gccint.info, Node: Test Idioms, Next: Test Directives, Up: Testsuites 4165 41667.1 Idioms Used in Testsuite Code 4167================================= 4168 4169In general, C testcases have a trailing '-N.c', starting with '-1.c', in 4170case other testcases with similar names are added later. If the test is 4171a test of some well-defined feature, it should have a name referring to 4172that feature such as 'FEATURE-1.c'. If it does not test a well-defined 4173feature but just happens to exercise a bug somewhere in the compiler, 4174and a bug report has been filed for this bug in the GCC bug database, 4175'prBUG-NUMBER-1.c' is the appropriate form of name. Otherwise (for 4176miscellaneous bugs not filed in the GCC bug database), and previously 4177more generally, test cases are named after the date on which they were 4178added. This allows people to tell at a glance whether a test failure is 4179because of a recently found bug that has not yet been fixed, or whether 4180it may be a regression, but does not give any other information about 4181the bug or where discussion of it may be found. Some other language 4182testsuites follow similar conventions. 4183 4184 In the 'gcc.dg' testsuite, it is often necessary to test that an error 4185is indeed a hard error and not just a warning--for example, where it is 4186a constraint violation in the C standard, which must become an error 4187with '-pedantic-errors'. The following idiom, where the first line 4188shown is line LINE of the file and the line that generates the error, is 4189used for this: 4190 4191 /* { dg-bogus "warning" "warning in place of error" } */ 4192 /* { dg-error "REGEXP" "MESSAGE" { target *-*-* } LINE } */ 4193 4194 It may be necessary to check that an expression is an integer constant 4195expression and has a certain value. To check that 'E' has value 'V', an 4196idiom similar to the following is used: 4197 4198 char x[((E) == (V) ? 1 : -1)]; 4199 4200 In 'gcc.dg' tests, '__typeof__' is sometimes used to make assertions 4201about the types of expressions. See, for example, 4202'gcc.dg/c99-condexpr-1.c'. The more subtle uses depend on the exact 4203rules for the types of conditional expressions in the C standard; see, 4204for example, 'gcc.dg/c99-intconst-1.c'. 4205 4206 It is useful to be able to test that optimizations are being made 4207properly. This cannot be done in all cases, but it can be done where 4208the optimization will lead to code being optimized away (for example, 4209where flow analysis or alias analysis should show that certain code 4210cannot be called) or to functions not being called because they have 4211been expanded as built-in functions. Such tests go in 4212'gcc.c-torture/execute'. Where code should be optimized away, a call to 4213a nonexistent function such as 'link_failure ()' may be inserted; a 4214definition 4215 4216 #ifndef __OPTIMIZE__ 4217 void 4218 link_failure (void) 4219 { 4220 abort (); 4221 } 4222 #endif 4223 4224will also be needed so that linking still succeeds when the test is run 4225without optimization. When all calls to a built-in function should have 4226been optimized and no calls to the non-built-in version of the function 4227should remain, that function may be defined as 'static' to call 'abort 4228()' (although redeclaring a function as static may not work on all 4229targets). 4230 4231 All testcases must be portable. Target-specific testcases must have 4232appropriate code to avoid causing failures on unsupported systems; 4233unfortunately, the mechanisms for this differ by directory. 4234 4235 FIXME: discuss non-C testsuites here. 4236 4237 4238File: gccint.info, Node: Test Directives, Next: Ada Tests, Prev: Test Idioms, Up: Testsuites 4239 42407.2 Directives used within DejaGnu tests 4241======================================== 4242 4243* Menu: 4244 4245* Directives:: Syntax and descriptions of test directives. 4246* Selectors:: Selecting targets to which a test applies. 4247* Effective-Target Keywords:: Keywords describing target attributes. 4248* Add Options:: Features for 'dg-add-options' 4249* Require Support:: Variants of 'dg-require-SUPPORT' 4250* Final Actions:: Commands for use in 'dg-final' 4251 4252 4253File: gccint.info, Node: Directives, Next: Selectors, Up: Test Directives 4254 42557.2.1 Syntax and Descriptions of test directives 4256------------------------------------------------ 4257 4258Test directives appear within comments in a test source file and begin 4259with 'dg-'. Some of these are defined within DejaGnu and others are 4260local to the GCC testsuite. 4261 4262 The order in which test directives appear in a test can be important: 4263directives local to GCC sometimes override information used by the 4264DejaGnu directives, which know nothing about the GCC directives, so the 4265DejaGnu directives must precede GCC directives. 4266 4267 Several test directives include selectors (*note Selectors::) which are 4268usually preceded by the keyword 'target' or 'xfail'. 4269 42707.2.1.1 Specify how to build the test 4271..................................... 4272 4273'{ dg-do DO-WHAT-KEYWORD [{ target/xfail SELECTOR }] }' 4274 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 4275 is executed. It is one of: 4276 4277 'preprocess' 4278 Compile with '-E' to run only the preprocessor. 4279 'compile' 4280 Compile with '-S' to produce an assembly code file. 4281 'assemble' 4282 Compile with '-c' to produce a relocatable object file. 4283 'link' 4284 Compile, assemble, and link to produce an executable file. 4285 'run' 4286 Produce and run an executable file, which is expected to 4287 return an exit code of 0. 4288 4289 The default is 'compile'. That can be overridden for a set of 4290 tests by redefining 'dg-do-what-default' within the '.exp' file for 4291 those tests. 4292 4293 If the directive includes the optional '{ target SELECTOR }' then 4294 the test is skipped unless the target system matches the SELECTOR. 4295 4296 If DO-WHAT-KEYWORD is 'run' and the directive includes the optional 4297 '{ xfail SELECTOR }' and the selector is met then the test is 4298 expected to fail. The 'xfail' clause is ignored for other values 4299 of DO-WHAT-KEYWORD; those tests can use directive 'dg-xfail-if'. 4300 43017.2.1.2 Specify additional compiler options 4302........................................... 4303 4304'{ dg-options OPTIONS [{ target SELECTOR }] }' 4305 This DejaGnu directive provides a list of compiler options, to be 4306 used if the target system matches SELECTOR, that replace the 4307 default options used for this set of tests. 4308 4309'{ dg-add-options FEATURE ... }' 4310 Add any compiler options that are needed to access certain 4311 features. This directive does nothing on targets that enable the 4312 features by default, or that don't provide them at all. It must 4313 come after all 'dg-options' directives. For supported values of 4314 FEATURE see *note Add Options::. 4315 4316'{ dg-additional-options OPTIONS [{ target SELECTOR }] }' 4317 This directive provides a list of compiler options, to be used if 4318 the target system matches SELECTOR, that are added to the default 4319 options used for this set of tests. 4320 43217.2.1.3 Modify the test timeout value 4322..................................... 4323 4324The normal timeout limit, in seconds, is found by searching the 4325following in order: 4326 4327 * the value defined by an earlier 'dg-timeout' directive in the test 4328 4329 * variable TOOL_TIMEOUT defined by the set of tests 4330 4331 * GCC,TIMEOUT set in the target board 4332 4333 * 300 4334 4335'{ dg-timeout N [{target SELECTOR }] }' 4336 Set the time limit for the compilation and for the execution of the 4337 test to the specified number of seconds. 4338 4339'{ dg-timeout-factor X [{ target SELECTOR }] }' 4340 Multiply the normal time limit for compilation and execution of the 4341 test by the specified floating-point factor. 4342 43437.2.1.4 Skip a test for some targets 4344.................................... 4345 4346'{ dg-skip-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4347 Arguments INCLUDE-OPTS and EXCLUDE-OPTS are lists in which each 4348 element is a string of zero or more GCC options. Skip the test if 4349 all of the following conditions are met: 4350 * the test system is included in SELECTOR 4351 4352 * for at least one of the option strings in INCLUDE-OPTS, every 4353 option from that string is in the set of options with which 4354 the test would be compiled; use '"*"' for an INCLUDE-OPTS list 4355 that matches any options; that is the default if INCLUDE-OPTS 4356 is not specified 4357 4358 * for each of the option strings in EXCLUDE-OPTS, at least one 4359 option from that string is not in the set of options with 4360 which the test would be compiled; use '""' for an empty 4361 EXCLUDE-OPTS list; that is the default if EXCLUDE-OPTS is not 4362 specified 4363 4364 For example, to skip a test if option '-Os' is present: 4365 4366 /* { dg-skip-if "" { *-*-* } { "-Os" } { "" } } */ 4367 4368 To skip a test if both options '-O2' and '-g' are present: 4369 4370 /* { dg-skip-if "" { *-*-* } { "-O2 -g" } { "" } } */ 4371 4372 To skip a test if either '-O2' or '-O3' is present: 4373 4374 /* { dg-skip-if "" { *-*-* } { "-O2" "-O3" } { "" } } */ 4375 4376 To skip a test unless option '-Os' is present: 4377 4378 /* { dg-skip-if "" { *-*-* } { "*" } { "-Os" } } */ 4379 4380 To skip a test if either '-O2' or '-O3' is used with '-g' but not 4381 if '-fpic' is also present: 4382 4383 /* { dg-skip-if "" { *-*-* } { "-O2 -g" "-O3 -g" } { "-fpic" } } */ 4384 4385'{ dg-require-effective-target KEYWORD [{ SELECTOR }] }' 4386 Skip the test if the test target, including current multilib flags, 4387 is not covered by the effective-target keyword. If the directive 4388 includes the optional '{ SELECTOR }' then the effective-target test 4389 is only performed if the target system matches the SELECTOR. This 4390 directive must appear after any 'dg-do' directive in the test and 4391 before any 'dg-additional-sources' directive. *Note 4392 Effective-Target Keywords::. 4393 4394'{ dg-require-SUPPORT args }' 4395 Skip the test if the target does not provide the required support. 4396 These directives must appear after any 'dg-do' directive in the 4397 test and before any 'dg-additional-sources' directive. They 4398 require at least one argument, which can be an empty string if the 4399 specific procedure does not examine the argument. *Note Require 4400 Support::, for a complete list of these directives. 4401 44027.2.1.5 Expect a test to fail for some targets 4403.............................................. 4404 4405'{ dg-xfail-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4406 Expect the test to fail if the conditions (which are the same as 4407 for 'dg-skip-if') are met. This does not affect the execute step. 4408 4409'{ dg-xfail-run-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4410 Expect the execute step of a test to fail if the conditions (which 4411 are the same as for 'dg-skip-if') are met. 4412 44137.2.1.6 Expect the test executable to fail 4414.......................................... 4415 4416'{ dg-shouldfail COMMENT [{ SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]]] }' 4417 Expect the test executable to return a nonzero exit status if the 4418 conditions (which are the same as for 'dg-skip-if') are met. 4419 44207.2.1.7 Verify compiler messages 4421................................ 4422 4423'{ dg-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }' 4424 This DejaGnu directive appears on a source line that is expected to 4425 get an error message, or else specifies the source line associated 4426 with the message. If there is no message for that line or if the 4427 text of that message is not matched by REGEXP then the check fails 4428 and COMMENT is included in the 'FAIL' message. The check does not 4429 look for the string 'error' unless it is part of REGEXP. 4430 4431'{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }' 4432 This DejaGnu directive appears on a source line that is expected to 4433 get a warning 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 'warning' unless it is part of REGEXP. 4438 4439'{ dg-message REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }' 4440 The line is expected to get a message other than an error or 4441 warning. If there is no message for that line or if the text of 4442 that message is not matched by REGEXP then the check fails and 4443 COMMENT is included in the 'FAIL' message. 4444 4445'{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }' 4446 This DejaGnu directive appears on a source line that should not get 4447 a message matching REGEXP, or else specifies the source line 4448 associated with the bogus message. It is usually used with 'xfail' 4449 to indicate that the message is a known problem for a particular 4450 set of targets. 4451 4452'{ dg-line LINENUMVAR }' 4453 This DejaGnu directive sets the variable LINENUMVAR to the line 4454 number of the source line. The variable LINENUMVAR can then be 4455 used in subsequent 'dg-error', 'dg-warning', 'dg-message' and 4456 'dg-bogus' directives. For example: 4457 4458 int a; /* { dg-line first_def_a } */ 4459 float a; /* { dg-error "conflicting types of" } */ 4460 /* { dg-message "previous declaration of" "" { target *-*-* } first_def_a } */ 4461 4462'{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }' 4463 This DejaGnu directive indicates that the test is expected to fail 4464 due to compiler messages that are not handled by 'dg-error', 4465 'dg-warning' or 'dg-bogus'. For this directive 'xfail' has the 4466 same effect as 'target'. 4467 4468'{ dg-prune-output REGEXP }' 4469 Prune messages matching REGEXP from the test output. 4470 44717.2.1.8 Verify output of the test executable 4472............................................ 4473 4474'{ dg-output REGEXP [{ target/xfail SELECTOR }] }' 4475 This DejaGnu directive compares REGEXP to the combined output that 4476 the test executable writes to 'stdout' and 'stderr'. 4477 44787.2.1.9 Specify environment variables for a test 4479................................................ 4480 4481'{ dg-set-compiler-env-var VAR_NAME "VAR_VALUE" }' 4482 Specify that the environment variable VAR_NAME needs to be set to 4483 VAR_VALUE before invoking the compiler on the test file. 4484 4485'{ dg-set-target-env-var VAR_NAME "VAR_VALUE" }' 4486 Specify that the environment variable VAR_NAME needs to be set to 4487 VAR_VALUE before execution of the program created by the test. 4488 44897.2.1.10 Specify additional files for a test 4490............................................ 4491 4492'{ dg-additional-files "FILELIST" }' 4493 Specify additional files, other than source files, that must be 4494 copied to the system where the compiler runs. 4495 4496'{ dg-additional-sources "FILELIST" }' 4497 Specify additional source files to appear in the compile line 4498 following the main test file. 4499 45007.2.1.11 Add checks at the end of a test 4501........................................ 4502 4503'{ dg-final { LOCAL-DIRECTIVE } }' 4504 This DejaGnu directive is placed within a comment anywhere in the 4505 source file and is processed after the test has been compiled and 4506 run. Multiple 'dg-final' commands are processed in the order in 4507 which they appear in the source file. *Note Final Actions::, for a 4508 list of directives that can be used within 'dg-final'. 4509 4510 4511File: gccint.info, Node: Selectors, Next: Effective-Target Keywords, Prev: Directives, Up: Test Directives 4512 45137.2.2 Selecting targets to which a test applies 4514----------------------------------------------- 4515 4516Several test directives include SELECTORs to limit the targets for which 4517a test is run or to declare that a test is expected to fail on 4518particular targets. 4519 4520 A selector is: 4521 * one or more target triplets, possibly including wildcard 4522 characters; use '*-*-*' to match any target 4523 * a single effective-target keyword (*note Effective-Target 4524 Keywords::) 4525 * a logical expression 4526 4527 Depending on the context, the selector specifies whether a test is 4528skipped and reported as unsupported or is expected to fail. A context 4529that allows either 'target' or 'xfail' also allows '{ target SELECTOR1 4530xfail SELECTOR2 }' to skip the test for targets that don't match 4531SELECTOR1 and the test to fail for targets that match SELECTOR2. 4532 4533 A selector expression appears within curly braces and uses a single 4534logical operator: one of '!', '&&', or '||'. An operand is another 4535selector expression, an effective-target keyword, a single target 4536triplet, or a list of target triplets within quotes or curly braces. 4537For example: 4538 4539 { target { ! "hppa*-*-* ia64*-*-*" } } 4540 { target { powerpc*-*-* && lp64 } } 4541 { xfail { lp64 || vect_no_align } } 4542 4543 4544File: gccint.info, Node: Effective-Target Keywords, Next: Add Options, Prev: Selectors, Up: Test Directives 4545 45467.2.3 Keywords describing target attributes 4547------------------------------------------- 4548 4549Effective-target keywords identify sets of targets that support 4550particular functionality. They are used to limit tests to be run only 4551for particular targets, or to specify that particular sets of targets 4552are expected to fail some tests. 4553 4554 Effective-target keywords are defined in 'lib/target-supports.exp' in 4555the GCC testsuite, with the exception of those that are documented as 4556being local to a particular test directory. 4557 4558 The 'effective target' takes into account all of the compiler options 4559with which the test will be compiled, including the multilib options. 4560By convention, keywords ending in '_nocache' can also include options 4561specified for the particular test in an earlier 'dg-options' or 4562'dg-add-options' directive. 4563 45647.2.3.1 Endianness 4565.................. 4566 4567'be' 4568 Target uses big-endian memory order for multi-byte and multi-word 4569 data. 4570 4571'le' 4572 Target uses little-endian memory order for multi-byte and 4573 multi-word data. 4574 45757.2.3.2 Data type sizes 4576....................... 4577 4578'ilp32' 4579 Target has 32-bit 'int', 'long', and pointers. 4580 4581'lp64' 4582 Target has 32-bit 'int', 64-bit 'long' and pointers. 4583 4584'llp64' 4585 Target has 32-bit 'int' and 'long', 64-bit 'long long' and 4586 pointers. 4587 4588'double64' 4589 Target has 64-bit 'double'. 4590 4591'double64plus' 4592 Target has 'double' that is 64 bits or longer. 4593 4594'longdouble128' 4595 Target has 128-bit 'long double'. 4596 4597'int32plus' 4598 Target has 'int' that is at 32 bits or longer. 4599 4600'int16' 4601 Target has 'int' that is 16 bits or shorter. 4602 4603'long_neq_int' 4604 Target has 'int' and 'long' with different sizes. 4605 4606'large_double' 4607 Target supports 'double' that is longer than 'float'. 4608 4609'large_long_double' 4610 Target supports 'long double' that is longer than 'double'. 4611 4612'ptr32plus' 4613 Target has pointers that are 32 bits or longer. 4614 4615'size32plus' 4616 Target supports array and structure sizes that are 32 bits or 4617 longer. 4618 4619'4byte_wchar_t' 4620 Target has 'wchar_t' that is at least 4 bytes. 4621 4622'floatN' 4623 Target has the '_FloatN' type. 4624 4625'floatNx' 4626 Target has the '_FloatNx' type. 4627 4628'floatN_runtime' 4629 Target has the '_FloatN' type, including runtime support for any 4630 options added with 'dg-add-options'. 4631 4632'floatNx_runtime' 4633 Target has the '_FloatNx' type, including runtime support for any 4634 options added with 'dg-add-options'. 4635 4636'floatn_nx_runtime' 4637 Target has runtime support for any options added with 4638 'dg-add-options' for any '_FloatN' or '_FloatNx' type. 4639 46407.2.3.3 Fortran-specific attributes 4641................................... 4642 4643'fortran_integer_16' 4644 Target supports Fortran 'integer' that is 16 bytes or longer. 4645 4646'fortran_real_10' 4647 Target supports Fortran 'real' that is 10 bytes or longer. 4648 4649'fortran_real_16' 4650 Target supports Fortran 'real' that is 16 bytes or longer. 4651 4652'fortran_large_int' 4653 Target supports Fortran 'integer' kinds larger than 'integer(8)'. 4654 4655'fortran_large_real' 4656 Target supports Fortran 'real' kinds larger than 'real(8)'. 4657 46587.2.3.4 Vector-specific attributes 4659.................................. 4660 4661'vect_align_stack_vars' 4662 The target's ABI allows stack variables to be aligned to the 4663 preferred vector alignment. 4664 4665'vect_condition' 4666 Target supports vector conditional operations. 4667 4668'vect_cond_mixed' 4669 Target supports vector conditional operations where comparison 4670 operands have different type from the value operands. 4671 4672'vect_double' 4673 Target supports hardware vectors of 'double'. 4674 4675'vect_element_align_preferred' 4676 The target's preferred vector alignment is the same as the element 4677 alignment. 4678 4679'vect_float' 4680 Target supports hardware vectors of 'float' when 4681 '-funsafe-math-optimizations' is in effect. 4682 4683'vect_float_strict' 4684 Target supports hardware vectors of 'float' when 4685 '-funsafe-math-optimizations' is not in effect. This implies 4686 'vect_float'. 4687 4688'vect_int' 4689 Target supports hardware vectors of 'int'. 4690 4691'vect_long' 4692 Target supports hardware vectors of 'long'. 4693 4694'vect_long_long' 4695 Target supports hardware vectors of 'long long'. 4696 4697'vect_fully_masked' 4698 Target supports fully-masked (also known as fully-predicated) 4699 loops, so that vector loops can handle partial as well as full 4700 vectors. 4701 4702'vect_masked_store' 4703 Target supports vector masked stores. 4704 4705'vect_scatter_store' 4706 Target supports vector scatter stores. 4707 4708'vect_aligned_arrays' 4709 Target aligns arrays to vector alignment boundary. 4710 4711'vect_hw_misalign' 4712 Target supports a vector misalign access. 4713 4714'vect_no_align' 4715 Target does not support a vector alignment mechanism. 4716 4717'vect_peeling_profitable' 4718 Target might require to peel loops for alignment purposes. 4719 4720'vect_no_int_min_max' 4721 Target does not support a vector min and max instruction on 'int'. 4722 4723'vect_no_int_add' 4724 Target does not support a vector add instruction on 'int'. 4725 4726'vect_no_bitwise' 4727 Target does not support vector bitwise instructions. 4728 4729'vect_char_mult' 4730 Target supports 'vector char' multiplication. 4731 4732'vect_short_mult' 4733 Target supports 'vector short' multiplication. 4734 4735'vect_int_mult' 4736 Target supports 'vector int' multiplication. 4737 4738'vect_long_mult' 4739 Target supports 64 bit 'vector long' multiplication. 4740 4741'vect_extract_even_odd' 4742 Target supports vector even/odd element extraction. 4743 4744'vect_extract_even_odd_wide' 4745 Target supports vector even/odd element extraction of vectors with 4746 elements 'SImode' or larger. 4747 4748'vect_interleave' 4749 Target supports vector interleaving. 4750 4751'vect_strided' 4752 Target supports vector interleaving and extract even/odd. 4753 4754'vect_strided_wide' 4755 Target supports vector interleaving and extract even/odd for wide 4756 element types. 4757 4758'vect_perm' 4759 Target supports vector permutation. 4760 4761'vect_perm_byte' 4762 Target supports permutation of vectors with 8-bit elements. 4763 4764'vect_perm_short' 4765 Target supports permutation of vectors with 16-bit elements. 4766 4767'vect_perm3_byte' 4768 Target supports permutation of vectors with 8-bit elements, and for 4769 the default vector length it is possible to permute: 4770 { a0, a1, a2, b0, b1, b2, ... } 4771 to: 4772 { a0, a0, a0, b0, b0, b0, ... } 4773 { a1, a1, a1, b1, b1, b1, ... } 4774 { a2, a2, a2, b2, b2, b2, ... } 4775 using only two-vector permutes, regardless of how long the sequence 4776 is. 4777 4778'vect_perm3_int' 4779 Like 'vect_perm3_byte', but for 32-bit elements. 4780 4781'vect_perm3_short' 4782 Like 'vect_perm3_byte', but for 16-bit elements. 4783 4784'vect_shift' 4785 Target supports a hardware vector shift operation. 4786 4787'vect_unaligned_possible' 4788 Target prefers vectors to have an alignment greater than element 4789 alignment, but also allows unaligned vector accesses in some 4790 circumstances. 4791 4792'vect_variable_length' 4793 Target has variable-length vectors. 4794 4795'vect_widen_sum_hi_to_si' 4796 Target supports a vector widening summation of 'short' operands 4797 into 'int' results, or can promote (unpack) from 'short' to 'int'. 4798 4799'vect_widen_sum_qi_to_hi' 4800 Target supports a vector widening summation of 'char' operands into 4801 'short' results, or can promote (unpack) from 'char' to 'short'. 4802 4803'vect_widen_sum_qi_to_si' 4804 Target supports a vector widening summation of 'char' operands into 4805 'int' results. 4806 4807'vect_widen_mult_qi_to_hi' 4808 Target supports a vector widening multiplication of 'char' operands 4809 into 'short' results, or can promote (unpack) from 'char' to 4810 'short' and perform non-widening multiplication of 'short'. 4811 4812'vect_widen_mult_hi_to_si' 4813 Target supports a vector widening multiplication of 'short' 4814 operands into 'int' results, or can promote (unpack) from 'short' 4815 to 'int' and perform non-widening multiplication of 'int'. 4816 4817'vect_widen_mult_si_to_di_pattern' 4818 Target supports a vector widening multiplication of 'int' operands 4819 into 'long' results. 4820 4821'vect_sdot_qi' 4822 Target supports a vector dot-product of 'signed char'. 4823 4824'vect_udot_qi' 4825 Target supports a vector dot-product of 'unsigned char'. 4826 4827'vect_sdot_hi' 4828 Target supports a vector dot-product of 'signed short'. 4829 4830'vect_udot_hi' 4831 Target supports a vector dot-product of 'unsigned short'. 4832 4833'vect_pack_trunc' 4834 Target supports a vector demotion (packing) of 'short' to 'char' 4835 and from 'int' to 'short' using modulo arithmetic. 4836 4837'vect_unpack' 4838 Target supports a vector promotion (unpacking) of 'char' to 'short' 4839 and from 'char' to 'int'. 4840 4841'vect_intfloat_cvt' 4842 Target supports conversion from 'signed int' to 'float'. 4843 4844'vect_uintfloat_cvt' 4845 Target supports conversion from 'unsigned int' to 'float'. 4846 4847'vect_floatint_cvt' 4848 Target supports conversion from 'float' to 'signed int'. 4849 4850'vect_floatuint_cvt' 4851 Target supports conversion from 'float' to 'unsigned int'. 4852 4853'vect_intdouble_cvt' 4854 Target supports conversion from 'signed int' to 'double'. 4855 4856'vect_doubleint_cvt' 4857 Target supports conversion from 'double' to 'signed int'. 4858 4859'vect_max_reduc' 4860 Target supports max reduction for vectors. 4861 4862'vect_sizes_16B_8B' 4863 Target supports 16- and 8-bytes vectors. 4864 4865'vect_sizes_32B_16B' 4866 Target supports 32- and 16-bytes vectors. 4867 4868'vect_logical_reduc' 4869 Target supports AND, IOR and XOR reduction on vectors. 4870 4871'vect_fold_extract_last' 4872 Target supports the 'fold_extract_last' optab. 4873 48747.2.3.5 Thread Local Storage attributes 4875....................................... 4876 4877'tls' 4878 Target supports thread-local storage. 4879 4880'tls_native' 4881 Target supports native (rather than emulated) thread-local storage. 4882 4883'tls_runtime' 4884 Test system supports executing TLS executables. 4885 48867.2.3.6 Decimal floating point attributes 4887......................................... 4888 4889'dfp' 4890 Targets supports compiling decimal floating point extension to C. 4891 4892'dfp_nocache' 4893 Including the options used to compile this particular test, the 4894 target supports compiling decimal floating point extension to C. 4895 4896'dfprt' 4897 Test system can execute decimal floating point tests. 4898 4899'dfprt_nocache' 4900 Including the options used to compile this particular test, the 4901 test system can execute decimal floating point tests. 4902 4903'hard_dfp' 4904 Target generates decimal floating point instructions with current 4905 options. 4906 49077.2.3.7 ARM-specific attributes 4908............................... 4909 4910'arm32' 4911 ARM target generates 32-bit code. 4912 4913'arm_eabi' 4914 ARM target adheres to the ABI for the ARM Architecture. 4915 4916'arm_fp_ok' 4917 ARM target defines '__ARM_FP' using '-mfloat-abi=softfp' or 4918 equivalent options. Some multilibs may be incompatible with these 4919 options. 4920 4921'arm_hf_eabi' 4922 ARM target adheres to the VFP and Advanced SIMD Register Arguments 4923 variant of the ABI for the ARM Architecture (as selected with 4924 '-mfloat-abi=hard'). 4925 4926'arm_softfloat' 4927 ARM target uses the soft-float ABI with no floating-point 4928 instructions used whatsoever (as selected with '-mfloat-abi=soft'). 4929 4930'arm_hard_vfp_ok' 4931 ARM target supports '-mfpu=vfp -mfloat-abi=hard'. Some multilibs 4932 may be incompatible with these options. 4933 4934'arm_iwmmxt_ok' 4935 ARM target supports '-mcpu=iwmmxt'. Some multilibs may be 4936 incompatible with this option. 4937 4938'arm_neon' 4939 ARM target supports generating NEON instructions. 4940 4941'arm_tune_string_ops_prefer_neon' 4942 Test CPU tune supports inlining string operations with NEON 4943 instructions. 4944 4945'arm_neon_hw' 4946 Test system supports executing NEON instructions. 4947 4948'arm_neonv2_hw' 4949 Test system supports executing NEON v2 instructions. 4950 4951'arm_neon_ok' 4952 ARM Target supports '-mfpu=neon -mfloat-abi=softfp' or compatible 4953 options. Some multilibs may be incompatible with these options. 4954 4955'arm_neon_ok_no_float_abi' 4956 ARM Target supports NEON with '-mfpu=neon', but without any 4957 -mfloat-abi= option. Some multilibs may be incompatible with this 4958 option. 4959 4960'arm_neonv2_ok' 4961 ARM Target supports '-mfpu=neon-vfpv4 -mfloat-abi=softfp' or 4962 compatible options. Some multilibs may be incompatible with these 4963 options. 4964 4965'arm_fp16_ok' 4966 Target supports options to generate VFP half-precision 4967 floating-point instructions. Some multilibs may be incompatible 4968 with these options. This test is valid for ARM only. 4969 4970'arm_fp16_hw' 4971 Target supports executing VFP half-precision floating-point 4972 instructions. This test is valid for ARM only. 4973 4974'arm_neon_fp16_ok' 4975 ARM Target supports '-mfpu=neon-fp16 -mfloat-abi=softfp' or 4976 compatible options, including '-mfp16-format=ieee' if necessary to 4977 obtain the '__fp16' type. Some multilibs may be incompatible with 4978 these options. 4979 4980'arm_neon_fp16_hw' 4981 Test system supports executing Neon half-precision float 4982 instructions. (Implies previous.) 4983 4984'arm_fp16_alternative_ok' 4985 ARM target supports the ARM FP16 alternative format. Some 4986 multilibs may be incompatible with the options needed. 4987 4988'arm_fp16_none_ok' 4989 ARM target supports specifying none as the ARM FP16 format. 4990 4991'arm_thumb1_ok' 4992 ARM target generates Thumb-1 code for '-mthumb'. 4993 4994'arm_thumb2_ok' 4995 ARM target generates Thumb-2 code for '-mthumb'. 4996 4997'arm_vfp_ok' 4998 ARM target supports '-mfpu=vfp -mfloat-abi=softfp'. Some multilibs 4999 may be incompatible with these options. 5000 5001'arm_vfp3_ok' 5002 ARM target supports '-mfpu=vfp3 -mfloat-abi=softfp'. Some 5003 multilibs may be incompatible with these options. 5004 5005'arm_v8_vfp_ok' 5006 ARM target supports '-mfpu=fp-armv8 -mfloat-abi=softfp'. Some 5007 multilibs may be incompatible with these options. 5008 5009'arm_v8_neon_ok' 5010 ARM target supports '-mfpu=neon-fp-armv8 -mfloat-abi=softfp'. Some 5011 multilibs may be incompatible with these options. 5012 5013'arm_v8_1a_neon_ok' 5014 ARM target supports options to generate ARMv8.1-A Adv.SIMD 5015 instructions. Some multilibs may be incompatible with these 5016 options. 5017 5018'arm_v8_1a_neon_hw' 5019 ARM target supports executing ARMv8.1-A Adv.SIMD instructions. 5020 Some multilibs may be incompatible with the options needed. 5021 Implies arm_v8_1a_neon_ok. 5022 5023'arm_acq_rel' 5024 ARM target supports acquire-release instructions. 5025 5026'arm_v8_2a_fp16_scalar_ok' 5027 ARM target supports options to generate instructions for ARMv8.2-A 5028 and scalar instructions from the FP16 extension. Some multilibs 5029 may be incompatible with these options. 5030 5031'arm_v8_2a_fp16_scalar_hw' 5032 ARM target supports executing instructions for ARMv8.2-A and scalar 5033 instructions from the FP16 extension. Some multilibs may be 5034 incompatible with these options. Implies arm_v8_2a_fp16_neon_ok. 5035 5036'arm_v8_2a_fp16_neon_ok' 5037 ARM target supports options to generate instructions from ARMv8.2-A 5038 with the FP16 extension. Some multilibs may be incompatible with 5039 these options. Implies arm_v8_2a_fp16_scalar_ok. 5040 5041'arm_v8_2a_fp16_neon_hw' 5042 ARM target supports executing instructions from ARMv8.2-A with the 5043 FP16 extension. Some multilibs may be incompatible with these 5044 options. Implies arm_v8_2a_fp16_neon_ok and 5045 arm_v8_2a_fp16_scalar_hw. 5046 5047'arm_v8_2a_dotprod_neon_ok' 5048 ARM target supports options to generate instructions from ARMv8.2-A 5049 with the Dot Product extension. Some multilibs may be incompatible 5050 with these options. 5051 5052'arm_v8_2a_dotprod_neon_hw' 5053 ARM target supports executing instructions from ARMv8.2-A with the 5054 Dot Product extension. Some multilibs may be incompatible with 5055 these options. Implies arm_v8_2a_dotprod_neon_ok. 5056 5057'arm_fp16fml_neon_ok' 5058 ARM target supports extensions to generate the 'VFMAL' and 'VFMLS' 5059 half-precision floating-point instructions available from ARMv8.2-A 5060 and onwards. Some multilibs may be incompatible with these 5061 options. 5062 5063'arm_prefer_ldrd_strd' 5064 ARM target prefers 'LDRD' and 'STRD' instructions over 'LDM' and 5065 'STM' instructions. 5066 5067'arm_thumb1_movt_ok' 5068 ARM target generates Thumb-1 code for '-mthumb' with 'MOVW' and 5069 'MOVT' instructions available. 5070 5071'arm_thumb1_cbz_ok' 5072 ARM target generates Thumb-1 code for '-mthumb' with 'CBZ' and 5073 'CBNZ' instructions available. 5074 5075'arm_divmod_simode' 5076 ARM target for which divmod transform is disabled, if it supports 5077 hardware div instruction. 5078 5079'arm_cmse_ok' 5080 ARM target supports ARMv8-M Security Extensions, enabled by the 5081 '-mcmse' option. 5082 5083'arm_coproc1_ok' 5084 ARM target supports the following coprocessor instructions: 'CDP', 5085 'LDC', 'STC', 'MCR' and 'MRC'. 5086 5087'arm_coproc2_ok' 5088 ARM target supports all the coprocessor instructions also listed as 5089 supported in *note arm_coproc1_ok:: in addition to the following: 5090 'CDP2', 'LDC2', 'LDC2l', 'STC2', 'STC2l', 'MCR2' and 'MRC2'. 5091 5092'arm_coproc3_ok' 5093 ARM target supports all the coprocessor instructions also listed as 5094 supported in *note arm_coproc2_ok:: in addition the following: 5095 'MCRR' and 'MRRC'. 5096 5097'arm_coproc4_ok' 5098 ARM target supports all the coprocessor instructions also listed as 5099 supported in *note arm_coproc3_ok:: in addition the following: 5100 'MCRR2' and 'MRRC2'. 5101 51027.2.3.8 AArch64-specific attributes 5103................................... 5104 5105'aarch64_asm_<ext>_ok' 5106 AArch64 assembler supports the architecture extension 'ext' via the 5107 '.arch_extension' pseudo-op. 5108'aarch64_tiny' 5109 AArch64 target which generates instruction sequences for tiny 5110 memory model. 5111'aarch64_small' 5112 AArch64 target which generates instruction sequences for small 5113 memory model. 5114'aarch64_large' 5115 AArch64 target which generates instruction sequences for large 5116 memory model. 5117'aarch64_little_endian' 5118 AArch64 target which generates instruction sequences for little 5119 endian. 5120'aarch64_big_endian' 5121 AArch64 target which generates instruction sequences for big 5122 endian. 5123'aarch64_small_fpic' 5124 Binutils installed on test system supports relocation types 5125 required by -fpic for AArch64 small memory model. 5126 5127'aarch64_fjcvtzs_hw' 5128 AArch64 target that is able to generate and execute armv8.3-a 5129 FJCVTZS instruction. 5130 51317.2.3.9 MIPS-specific attributes 5132................................ 5133 5134'mips64' 5135 MIPS target supports 64-bit instructions. 5136 5137'nomips16' 5138 MIPS target does not produce MIPS16 code. 5139 5140'mips16_attribute' 5141 MIPS target can generate MIPS16 code. 5142 5143'mips_loongson' 5144 MIPS target is a Loongson-2E or -2F target using an ABI that 5145 supports the Loongson vector modes. 5146 5147'mips_msa' 5148 MIPS target supports '-mmsa', MIPS SIMD Architecture (MSA). 5149 5150'mips_newabi_large_long_double' 5151 MIPS target supports 'long double' larger than 'double' when using 5152 the new ABI. 5153 5154'mpaired_single' 5155 MIPS target supports '-mpaired-single'. 5156 51577.2.3.10 PowerPC-specific attributes 5158.................................... 5159 5160'dfp_hw' 5161 PowerPC target supports executing hardware DFP instructions. 5162 5163'p8vector_hw' 5164 PowerPC target supports executing VSX instructions (ISA 2.07). 5165 5166'powerpc64' 5167 Test system supports executing 64-bit instructions. 5168 5169'powerpc_altivec' 5170 PowerPC target supports AltiVec. 5171 5172'powerpc_altivec_ok' 5173 PowerPC target supports '-maltivec'. 5174 5175'powerpc_eabi_ok' 5176 PowerPC target supports '-meabi'. 5177 5178'powerpc_elfv2' 5179 PowerPC target supports '-mabi=elfv2'. 5180 5181'powerpc_fprs' 5182 PowerPC target supports floating-point registers. 5183 5184'powerpc_hard_double' 5185 PowerPC target supports hardware double-precision floating-point. 5186 5187'powerpc_htm_ok' 5188 PowerPC target supports '-mhtm' 5189 5190'powerpc_p8vector_ok' 5191 PowerPC target supports '-mpower8-vector' 5192 5193'powerpc_popcntb_ok' 5194 PowerPC target supports the 'popcntb' instruction, indicating that 5195 this target supports '-mcpu=power5'. 5196 5197'powerpc_ppu_ok' 5198 PowerPC target supports '-mcpu=cell'. 5199 5200'powerpc_spe' 5201 PowerPC target supports PowerPC SPE. 5202 5203'powerpc_spe_nocache' 5204 Including the options used to compile this particular test, the 5205 PowerPC target supports PowerPC SPE. 5206 5207'powerpc_spu' 5208 PowerPC target supports PowerPC SPU. 5209 5210'powerpc_vsx_ok' 5211 PowerPC target supports '-mvsx'. 5212 5213'powerpc_405_nocache' 5214 Including the options used to compile this particular test, the 5215 PowerPC target supports PowerPC 405. 5216 5217'ppc_recip_hw' 5218 PowerPC target supports executing reciprocal estimate instructions. 5219 5220'spu_auto_overlay' 5221 SPU target has toolchain that supports automatic overlay 5222 generation. 5223 5224'vmx_hw' 5225 PowerPC target supports executing AltiVec instructions. 5226 5227'vsx_hw' 5228 PowerPC target supports executing VSX instructions (ISA 2.06). 5229 52307.2.3.11 Other hardware attributes 5231.................................. 5232 5233'autoincdec' 5234 Target supports autoincrement/decrement addressing. 5235 5236'avx' 5237 Target supports compiling 'avx' instructions. 5238 5239'avx_runtime' 5240 Target supports the execution of 'avx' instructions. 5241 5242'avx2' 5243 Target supports compiling 'avx2' instructions. 5244 5245'avx2_runtime' 5246 Target supports the execution of 'avx2' instructions. 5247 5248'avx512f' 5249 Target supports compiling 'avx512f' instructions. 5250 5251'avx512f_runtime' 5252 Target supports the execution of 'avx512f' instructions. 5253 5254'cell_hw' 5255 Test system can execute AltiVec and Cell PPU instructions. 5256 5257'coldfire_fpu' 5258 Target uses a ColdFire FPU. 5259 5260'divmod' 5261 Target supporting hardware divmod insn or divmod libcall. 5262 5263'divmod_simode' 5264 Target supporting hardware divmod insn or divmod libcall for 5265 SImode. 5266 5267'hard_float' 5268 Target supports FPU instructions. 5269 5270'non_strict_align' 5271 Target does not require strict alignment. 5272 5273'pie_copyreloc' 5274 The x86-64 target linker supports PIE with copy reloc. 5275 5276'rdrand' 5277 Target supports x86 'rdrand' instruction. 5278 5279'sqrt_insn' 5280 Target has a square root instruction that the compiler can 5281 generate. 5282 5283'sse' 5284 Target supports compiling 'sse' instructions. 5285 5286'sse_runtime' 5287 Target supports the execution of 'sse' instructions. 5288 5289'sse2' 5290 Target supports compiling 'sse2' instructions. 5291 5292'sse2_runtime' 5293 Target supports the execution of 'sse2' instructions. 5294 5295'sync_char_short' 5296 Target supports atomic operations on 'char' and 'short'. 5297 5298'sync_int_long' 5299 Target supports atomic operations on 'int' and 'long'. 5300 5301'ultrasparc_hw' 5302 Test environment appears to run executables on a simulator that 5303 accepts only 'EM_SPARC' executables and chokes on 'EM_SPARC32PLUS' 5304 or 'EM_SPARCV9' executables. 5305 5306'vect_cmdline_needed' 5307 Target requires a command line argument to enable a SIMD 5308 instruction set. 5309 5310'xorsign' 5311 Target supports the xorsign optab expansion. 5312 53137.2.3.12 Environment attributes 5314............................... 5315 5316'c' 5317 The language for the compiler under test is C. 5318 5319'c++' 5320 The language for the compiler under test is C++. 5321 5322'c99_runtime' 5323 Target provides a full C99 runtime. 5324 5325'correct_iso_cpp_string_wchar_protos' 5326 Target 'string.h' and 'wchar.h' headers provide C++ required 5327 overloads for 'strchr' etc. functions. 5328 5329'dummy_wcsftime' 5330 Target uses a dummy 'wcsftime' function that always returns zero. 5331 5332'fd_truncate' 5333 Target can truncate a file from a file descriptor, as used by 5334 'libgfortran/io/unix.c:fd_truncate'; i.e. 'ftruncate' or 'chsize'. 5335 5336'freestanding' 5337 Target is 'freestanding' as defined in section 4 of the C99 5338 standard. Effectively, it is a target which supports no extra 5339 headers or libraries other than what is considered essential. 5340 5341'gettimeofday' 5342 Target supports 'gettimeofday'. 5343 5344'init_priority' 5345 Target supports constructors with initialization priority 5346 arguments. 5347 5348'inttypes_types' 5349 Target has the basic signed and unsigned types in 'inttypes.h'. 5350 This is for tests that GCC's notions of these types agree with 5351 those in the header, as some systems have only 'inttypes.h'. 5352 5353'lax_strtofp' 5354 Target might have errors of a few ULP in string to floating-point 5355 conversion functions and overflow is not always detected correctly 5356 by those functions. 5357 5358'mempcpy' 5359 Target provides 'mempcpy' function. 5360 5361'mmap' 5362 Target supports 'mmap'. 5363 5364'newlib' 5365 Target supports Newlib. 5366 5367'pow10' 5368 Target provides 'pow10' function. 5369 5370'pthread' 5371 Target can compile using 'pthread.h' with no errors or warnings. 5372 5373'pthread_h' 5374 Target has 'pthread.h'. 5375 5376'run_expensive_tests' 5377 Expensive testcases (usually those that consume excessive amounts 5378 of CPU time) should be run on this target. This can be enabled by 5379 setting the 'GCC_TEST_RUN_EXPENSIVE' environment variable to a 5380 non-empty string. 5381 5382'simulator' 5383 Test system runs executables on a simulator (i.e. slowly) rather 5384 than hardware (i.e. fast). 5385 5386'signal' 5387 Target has 'signal.h'. 5388 5389'stabs' 5390 Target supports the stabs debugging format. 5391 5392'stdint_types' 5393 Target has the basic signed and unsigned C types in 'stdint.h'. 5394 This will be obsolete when GCC ensures a working 'stdint.h' for all 5395 targets. 5396 5397'stpcpy' 5398 Target provides 'stpcpy' function. 5399 5400'trampolines' 5401 Target supports trampolines. 5402 5403'uclibc' 5404 Target supports uClibc. 5405 5406'unwrapped' 5407 Target does not use a status wrapper. 5408 5409'vxworks_kernel' 5410 Target is a VxWorks kernel. 5411 5412'vxworks_rtp' 5413 Target is a VxWorks RTP. 5414 5415'wchar' 5416 Target supports wide characters. 5417 54187.2.3.13 Other attributes 5419......................... 5420 5421'automatic_stack_alignment' 5422 Target supports automatic stack alignment. 5423 5424'branch_cost' 5425 Target supports '-branch-cost=N'. 5426 5427'cxa_atexit' 5428 Target uses '__cxa_atexit'. 5429 5430'default_packed' 5431 Target has packed layout of structure members by default. 5432 5433'fgraphite' 5434 Target supports Graphite optimizations. 5435 5436'fixed_point' 5437 Target supports fixed-point extension to C. 5438 5439'fopenacc' 5440 Target supports OpenACC via '-fopenacc'. 5441 5442'fopenmp' 5443 Target supports OpenMP via '-fopenmp'. 5444 5445'fpic' 5446 Target supports '-fpic' and '-fPIC'. 5447 5448'freorder' 5449 Target supports '-freorder-blocks-and-partition'. 5450 5451'fstack_protector' 5452 Target supports '-fstack-protector'. 5453 5454'gas' 5455 Target uses GNU 'as'. 5456 5457'gc_sections' 5458 Target supports '--gc-sections'. 5459 5460'gld' 5461 Target uses GNU 'ld'. 5462 5463'keeps_null_pointer_checks' 5464 Target keeps null pointer checks, either due to the use of 5465 '-fno-delete-null-pointer-checks' or hardwired into the target. 5466 5467'lto' 5468 Compiler has been configured to support link-time optimization 5469 (LTO). 5470 5471'naked_functions' 5472 Target supports the 'naked' function attribute. 5473 5474'named_sections' 5475 Target supports named sections. 5476 5477'natural_alignment_32' 5478 Target uses natural alignment (aligned to type size) for types of 5479 32 bits or less. 5480 5481'target_natural_alignment_64' 5482 Target uses natural alignment (aligned to type size) for types of 5483 64 bits or less. 5484 5485'nonpic' 5486 Target does not generate PIC by default. 5487 5488'pie_enabled' 5489 Target generates PIE by default. 5490 5491'pcc_bitfield_type_matters' 5492 Target defines 'PCC_BITFIELD_TYPE_MATTERS'. 5493 5494'pe_aligned_commons' 5495 Target supports '-mpe-aligned-commons'. 5496 5497'pie' 5498 Target supports '-pie', '-fpie' and '-fPIE'. 5499 5500'rdynamic' 5501 Target supports '-rdynamic'. 5502 5503'section_anchors' 5504 Target supports section anchors. 5505 5506'short_enums' 5507 Target defaults to short enums. 5508 5509'stack_size' 5510 Target has limited stack size. The stack size limit can be 5511 obtained using the STACK_SIZE macro defined by *note 5512 'dg-add-options' feature 'stack_size': stack_size_ao. 5513 5514'static' 5515 Target supports '-static'. 5516 5517'static_libgfortran' 5518 Target supports statically linking 'libgfortran'. 5519 5520'string_merging' 5521 Target supports merging string constants at link time. 5522 5523'ucn' 5524 Target supports compiling and assembling UCN. 5525 5526'ucn_nocache' 5527 Including the options used to compile this particular test, the 5528 target supports compiling and assembling UCN. 5529 5530'unaligned_stack' 5531 Target does not guarantee that its 'STACK_BOUNDARY' is greater than 5532 or equal to the required vector alignment. 5533 5534'vector_alignment_reachable' 5535 Vector alignment is reachable for types of 32 bits or less. 5536 5537'vector_alignment_reachable_for_64bit' 5538 Vector alignment is reachable for types of 64 bits or less. 5539 5540'wchar_t_char16_t_compatible' 5541 Target supports 'wchar_t' that is compatible with 'char16_t'. 5542 5543'wchar_t_char32_t_compatible' 5544 Target supports 'wchar_t' that is compatible with 'char32_t'. 5545 5546'comdat_group' 5547 Target uses comdat groups. 5548 55497.2.3.14 Local to tests in 'gcc.target/i386' 5550............................................ 5551 5552'3dnow' 5553 Target supports compiling '3dnow' instructions. 5554 5555'aes' 5556 Target supports compiling 'aes' instructions. 5557 5558'fma4' 5559 Target supports compiling 'fma4' instructions. 5560 5561'ms_hook_prologue' 5562 Target supports attribute 'ms_hook_prologue'. 5563 5564'pclmul' 5565 Target supports compiling 'pclmul' instructions. 5566 5567'sse3' 5568 Target supports compiling 'sse3' instructions. 5569 5570'sse4' 5571 Target supports compiling 'sse4' instructions. 5572 5573'sse4a' 5574 Target supports compiling 'sse4a' instructions. 5575 5576'ssse3' 5577 Target supports compiling 'ssse3' instructions. 5578 5579'vaes' 5580 Target supports compiling 'vaes' instructions. 5581 5582'vpclmul' 5583 Target supports compiling 'vpclmul' instructions. 5584 5585'xop' 5586 Target supports compiling 'xop' instructions. 5587 55887.2.3.15 Local to tests in 'gcc.target/spu/ea' 5589.............................................. 5590 5591'ealib' 5592 Target '__ea' library functions are available. 5593 55947.2.3.16 Local to tests in 'gcc.test-framework' 5595............................................... 5596 5597'no' 5598 Always returns 0. 5599 5600'yes' 5601 Always returns 1. 5602 5603 5604File: gccint.info, Node: Add Options, Next: Require Support, Prev: Effective-Target Keywords, Up: Test Directives 5605 56067.2.4 Features for 'dg-add-options' 5607----------------------------------- 5608 5609The supported values of FEATURE for directive 'dg-add-options' are: 5610 5611'arm_fp' 5612 '__ARM_FP' definition. Only ARM targets support this feature, and 5613 only then in certain modes; see the *note arm_fp_ok effective 5614 target keyword: arm_fp_ok. 5615 5616'arm_neon' 5617 NEON support. Only ARM targets support this feature, and only then 5618 in certain modes; see the *note arm_neon_ok effective target 5619 keyword: arm_neon_ok. 5620 5621'arm_fp16' 5622 VFP half-precision floating point support. This does not select 5623 the FP16 format; for that, use *note arm_fp16_ieee: arm_fp16_ieee. 5624 or *note arm_fp16_alternative: arm_fp16_alternative. instead. This 5625 feature is only supported by ARM targets and then only in certain 5626 modes; see the *note arm_fp16_ok effective target keyword: 5627 arm_fp16_ok. 5628 5629'arm_fp16_ieee' 5630 ARM IEEE 754-2008 format VFP half-precision floating point support. 5631 This feature is only supported by ARM targets and then only in 5632 certain modes; see the *note arm_fp16_ok effective target keyword: 5633 arm_fp16_ok. 5634 5635'arm_fp16_alternative' 5636 ARM Alternative format VFP half-precision floating point support. 5637 This feature is only supported by ARM targets and then only in 5638 certain modes; see the *note arm_fp16_ok effective target keyword: 5639 arm_fp16_ok. 5640 5641'arm_neon_fp16' 5642 NEON and half-precision floating point support. Only ARM targets 5643 support this feature, and only then in certain modes; see the *note 5644 arm_neon_fp16_ok effective target keyword: arm_neon_fp16_ok. 5645 5646'arm_vfp3' 5647 arm vfp3 floating point support; see the *note arm_vfp3_ok 5648 effective target keyword: arm_vfp3_ok. 5649 5650'arm_v8_1a_neon' 5651 Add options for ARMv8.1-A with Adv.SIMD support, if this is 5652 supported by the target; see the *note arm_v8_1a_neon_ok: 5653 arm_v8_1a_neon_ok. effective target keyword. 5654 5655'arm_v8_2a_fp16_scalar' 5656 Add options for ARMv8.2-A with scalar FP16 support, if this is 5657 supported by the target; see the *note arm_v8_2a_fp16_scalar_ok: 5658 arm_v8_2a_fp16_scalar_ok. effective target keyword. 5659 5660'arm_v8_2a_fp16_neon' 5661 Add options for ARMv8.2-A with Adv.SIMD FP16 support, if this is 5662 supported by the target; see the *note arm_v8_2a_fp16_neon_ok: 5663 arm_v8_2a_fp16_neon_ok. effective target keyword. 5664 5665'arm_v8_2a_dotprod_neon' 5666 Add options for ARMv8.2-A with Adv.SIMD Dot Product support, if 5667 this is supported by the target; see the *note 5668 arm_v8_2a_dotprod_neon_ok:: effective target keyword. 5669 5670'arm_fp16fml_neon' 5671 Add options to enable generation of the 'VFMAL' and 'VFMSL' 5672 instructions, if this is supported by the target; see the *note 5673 arm_fp16fml_neon_ok:: effective target keyword. 5674 5675'bind_pic_locally' 5676 Add the target-specific flags needed to enable functions to bind 5677 locally when using pic/PIC passes in the testsuite. 5678 5679'c99_runtime' 5680 Add the target-specific flags needed to access the C99 runtime. 5681 5682'floatN' 5683 Add the target-specific flags needed to use the '_FloatN' type. 5684 5685'floatNx' 5686 Add the target-specific flags needed to use the '_FloatNx' type. 5687 5688'ieee' 5689 Add the target-specific flags needed to enable full IEEE compliance 5690 mode. 5691 5692'mips16_attribute' 5693 'mips16' function attributes. Only MIPS targets support this 5694 feature, and only then in certain modes. 5695 5696'stack_size' 5697 Add the flags needed to define macro STACK_SIZE and set it to the 5698 stack size limit associated with the *note 'stack_size' effective 5699 target: stack_size_et. 5700 5701'tls' 5702 Add the target-specific flags needed to use thread-local storage. 5703 5704 5705File: gccint.info, Node: Require Support, Next: Final Actions, Prev: Add Options, Up: Test Directives 5706 57077.2.5 Variants of 'dg-require-SUPPORT' 5708-------------------------------------- 5709 5710A few of the 'dg-require' directives take arguments. 5711 5712'dg-require-iconv CODESET' 5713 Skip the test if the target does not support iconv. CODESET is the 5714 codeset to convert to. 5715 5716'dg-require-profiling PROFOPT' 5717 Skip the test if the target does not support profiling with option 5718 PROFOPT. 5719 5720'dg-require-stack-check CHECK' 5721 Skip the test if the target does not support the '-fstack-check' 5722 option. If CHECK is '""', support for '-fstack-check' is checked, 5723 for '-fstack-check=("CHECK")' otherwise. 5724 5725'dg-require-stack-size SIZE' 5726 Skip the test if the target does not support a stack size of SIZE. 5727 5728'dg-require-visibility VIS' 5729 Skip the test if the target does not support the 'visibility' 5730 attribute. If VIS is '""', support for 'visibility("hidden")' is 5731 checked, for 'visibility("VIS")' otherwise. 5732 5733 The original 'dg-require' directives were defined before there was 5734support for effective-target keywords. The directives that do not take 5735arguments could be replaced with effective-target keywords. 5736 5737'dg-require-alias ""' 5738 Skip the test if the target does not support the 'alias' attribute. 5739 5740'dg-require-ascii-locale ""' 5741 Skip the test if the host does not support an ASCII locale. 5742 5743'dg-require-compat-dfp ""' 5744 Skip this test unless both compilers in a 'compat' testsuite 5745 support decimal floating point. 5746 5747'dg-require-cxa-atexit ""' 5748 Skip the test if the target does not support '__cxa_atexit'. This 5749 is equivalent to 'dg-require-effective-target cxa_atexit'. 5750 5751'dg-require-dll ""' 5752 Skip the test if the target does not support DLL attributes. 5753 5754'dg-require-fork ""' 5755 Skip the test if the target does not support 'fork'. 5756 5757'dg-require-gc-sections ""' 5758 Skip the test if the target's linker does not support the 5759 '--gc-sections' flags. This is equivalent to 5760 'dg-require-effective-target gc-sections'. 5761 5762'dg-require-host-local ""' 5763 Skip the test if the host is remote, rather than the same as the 5764 build system. Some tests are incompatible with DejaGnu's handling 5765 of remote hosts, which involves copying the source file to the host 5766 and compiling it with a relative path and "'-o a.out'". 5767 5768'dg-require-mkfifo ""' 5769 Skip the test if the target does not support 'mkfifo'. 5770 5771'dg-require-named-sections ""' 5772 Skip the test is the target does not support named sections. This 5773 is equivalent to 'dg-require-effective-target named_sections'. 5774 5775'dg-require-weak ""' 5776 Skip the test if the target does not support weak symbols. 5777 5778'dg-require-weak-override ""' 5779 Skip the test if the target does not support overriding weak 5780 symbols. 5781 5782 5783File: gccint.info, Node: Final Actions, Prev: Require Support, Up: Test Directives 5784 57857.2.6 Commands for use in 'dg-final' 5786------------------------------------ 5787 5788The GCC testsuite defines the following directives to be used within 5789'dg-final'. 5790 57917.2.6.1 Scan a particular file 5792.............................. 5793 5794'scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]' 5795 Passes if REGEXP matches text in FILENAME. 5796'scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]' 5797 Passes if REGEXP does not match text in FILENAME. 5798'scan-module MODULE REGEXP [{ target/xfail SELECTOR }]' 5799 Passes if REGEXP matches in Fortran module MODULE. 5800 58017.2.6.2 Scan the assembly output 5802................................ 5803 5804'scan-assembler REGEX [{ target/xfail SELECTOR }]' 5805 Passes if REGEX matches text in the test's assembler output. 5806 5807'scan-assembler-not REGEX [{ target/xfail SELECTOR }]' 5808 Passes if REGEX does not match text in the test's assembler output. 5809 5810'scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]' 5811 Passes if REGEX is matched exactly NUM times in the test's 5812 assembler output. 5813 5814'scan-assembler-dem REGEX [{ target/xfail SELECTOR }]' 5815 Passes if REGEX matches text in the test's demangled assembler 5816 output. 5817 5818'scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]' 5819 Passes if REGEX does not match text in the test's demangled 5820 assembler output. 5821 5822'scan-hidden SYMBOL [{ target/xfail SELECTOR }]' 5823 Passes if SYMBOL is defined as a hidden symbol in the test's 5824 assembly output. 5825 5826'scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]' 5827 Passes if SYMBOL is not defined as a hidden symbol in the test's 5828 assembly output. 5829 58307.2.6.3 Scan optimization dump files 5831.................................... 5832 5833These commands are available for KIND of 'tree', 'rtl', and 'ipa'. 5834 5835'scan-KIND-dump REGEX SUFFIX [{ target/xfail SELECTOR }]' 5836 Passes if REGEX matches text in the dump file with suffix SUFFIX. 5837 5838'scan-KIND-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5839 Passes if REGEX does not match text in the dump file with suffix 5840 SUFFIX. 5841 5842'scan-KIND-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]' 5843 Passes if REGEX is found exactly NUM times in the dump file with 5844 suffix SUFFIX. 5845 5846'scan-KIND-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]' 5847 Passes if REGEX matches demangled text in the dump file with suffix 5848 SUFFIX. 5849 5850'scan-KIND-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5851 Passes if REGEX does not match demangled text in the dump file with 5852 suffix SUFFIX. 5853 58547.2.6.4 Verify that an output files exists or not 5855................................................. 5856 5857'output-exists [{ target/xfail SELECTOR }]' 5858 Passes if compiler output file exists. 5859 5860'output-exists-not [{ target/xfail SELECTOR }]' 5861 Passes if compiler output file does not exist. 5862 58637.2.6.5 Check for LTO tests 5864........................... 5865 5866'scan-symbol REGEXP [{ target/xfail SELECTOR }]' 5867 Passes if the pattern is present in the final executable. 5868 58697.2.6.6 Checks for 'gcov' tests 5870............................... 5871 5872'run-gcov SOURCEFILE' 5873 Check line counts in 'gcov' tests. 5874 5875'run-gcov [branches] [calls] { OPTS SOURCEFILE }' 5876 Check branch and/or call counts, in addition to line counts, in 5877 'gcov' tests. 5878 58797.2.6.7 Clean up generated test files 5880..................................... 5881 5882Usually the test-framework removes files that were generated during 5883testing. If a testcase, for example, uses any dumping mechanism to 5884inspect a passes dump file, the testsuite recognized the dump option 5885passed to the tool and schedules a final cleanup to remove these files. 5886 5887 There are, however, following additional cleanup directives that can be 5888used to annotate a testcase "manually". 5889'cleanup-coverage-files' 5890 Removes coverage data files generated for this test. 5891 5892'cleanup-modules "LIST-OF-EXTRA-MODULES"' 5893 Removes Fortran module files generated for this test, excluding the 5894 module names listed in keep-modules. Cleaning up module files is 5895 usually done automatically by the testsuite by looking at the 5896 source files and removing the modules after the test has been 5897 executed. 5898 module MoD1 5899 end module MoD1 5900 module Mod2 5901 end module Mod2 5902 module moD3 5903 end module moD3 5904 module mod4 5905 end module mod4 5906 ! { dg-final { cleanup-modules "mod1 mod2" } } ! redundant 5907 ! { dg-final { keep-modules "mod3 mod4" } } 5908 5909'keep-modules "LIST-OF-MODULES-NOT-TO-DELETE"' 5910 Whitespace separated list of module names that should not be 5911 deleted by cleanup-modules. If the list of modules is empty, all 5912 modules defined in this file are kept. 5913 module maybe_unneeded 5914 end module maybe_unneeded 5915 module keep1 5916 end module keep1 5917 module keep2 5918 end module keep2 5919 ! { dg-final { keep-modules "keep1 keep2" } } ! just keep these two 5920 ! { dg-final { keep-modules "" } } ! keep all 5921 5922'dg-keep-saved-temps "LIST-OF-SUFFIXES-NOT-TO-DELETE"' 5923 Whitespace separated list of suffixes that should not be deleted 5924 automatically in a testcase that uses '-save-temps'. 5925 // { dg-options "-save-temps -fpch-preprocess -I." } 5926 int main() { return 0; } 5927 // { dg-keep-saved-temps ".s" } ! just keep assembler file 5928 // { dg-keep-saved-temps ".s" ".i" } ! ... and .i 5929 // { dg-keep-saved-temps ".ii" ".o" } ! or just .ii and .o 5930 5931'cleanup-profile-file' 5932 Removes profiling files generated for this test. 5933 5934'cleanup-repo-files' 5935 Removes files generated for this test for '-frepo'. 5936 5937 5938File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites 5939 59407.3 Ada Language Testsuites 5941=========================== 5942 5943The Ada testsuite includes executable tests from the ACATS testsuite, 5944publicly available at <http://www.ada-auth.org/acats.html>. 5945 5946 These tests are integrated in the GCC testsuite in the 'ada/acats' 5947directory, and enabled automatically when running 'make check', assuming 5948the Ada language has been enabled when configuring GCC. 5949 5950 You can also run the Ada testsuite independently, using 'make 5951check-ada', or run a subset of the tests by specifying which chapter to 5952run, e.g.: 5953 5954 $ make check-ada CHAPTERS="c3 c9" 5955 5956 The tests are organized by directory, each directory corresponding to a 5957chapter of the Ada Reference Manual. So for example, 'c9' corresponds 5958to chapter 9, which deals with tasking features of the language. 5959 5960 The tests are run using two 'sh' scripts: 'run_acats' and 'run_all.sh'. 5961To run the tests using a simulator or a cross target, see the small 5962customization section at the top of 'run_all.sh'. 5963 5964 These tests are run using the build tree: they can be run without doing 5965a 'make install'. 5966 5967 5968File: gccint.info, Node: C Tests, Next: LTO Testing, Prev: Ada Tests, Up: Testsuites 5969 59707.4 C Language Testsuites 5971========================= 5972 5973GCC contains the following C language testsuites, in the 'gcc/testsuite' 5974directory: 5975 5976'gcc.dg' 5977 This contains tests of particular features of the C compiler, using 5978 the more modern 'dg' harness. Correctness tests for various 5979 compiler features should go here if possible. 5980 5981 Magic comments determine whether the file is preprocessed, 5982 compiled, linked or run. In these tests, error and warning message 5983 texts are compared against expected texts or regular expressions 5984 given in comments. These tests are run with the options '-ansi 5985 -pedantic' unless other options are given in the test. Except as 5986 noted below they are not run with multiple optimization options. 5987'gcc.dg/compat' 5988 This subdirectory contains tests for binary compatibility using 5989 'lib/compat.exp', which in turn uses the language-independent 5990 support (*note Support for testing binary compatibility: compat 5991 Testing.). 5992'gcc.dg/cpp' 5993 This subdirectory contains tests of the preprocessor. 5994'gcc.dg/debug' 5995 This subdirectory contains tests for debug formats. Tests in this 5996 subdirectory are run for each debug format that the compiler 5997 supports. 5998'gcc.dg/format' 5999 This subdirectory contains tests of the '-Wformat' format checking. 6000 Tests in this directory are run with and without '-DWIDE'. 6001'gcc.dg/noncompile' 6002 This subdirectory contains tests of code that should not compile 6003 and does not need any special compilation options. They are run 6004 with multiple optimization options, since sometimes invalid code 6005 crashes the compiler with optimization. 6006'gcc.dg/special' 6007 FIXME: describe this. 6008 6009'gcc.c-torture' 6010 This contains particular code fragments which have historically 6011 broken easily. These tests are run with multiple optimization 6012 options, so tests for features which only break at some 6013 optimization levels belong here. This also contains tests to check 6014 that certain optimizations occur. It might be worthwhile to 6015 separate the correctness tests cleanly from the code quality tests, 6016 but it hasn't been done yet. 6017 6018'gcc.c-torture/compat' 6019 FIXME: describe this. 6020 6021 This directory should probably not be used for new tests. 6022'gcc.c-torture/compile' 6023 This testsuite contains test cases that should compile, but do not 6024 need to link or run. These test cases are compiled with several 6025 different combinations of optimization options. All warnings are 6026 disabled for these test cases, so this directory is not suitable if 6027 you wish to test for the presence or absence of compiler warnings. 6028 While special options can be set, and tests disabled on specific 6029 platforms, by the use of '.x' files, mostly these test cases should 6030 not contain platform dependencies. FIXME: discuss how defines such 6031 as 'STACK_SIZE' are used. 6032'gcc.c-torture/execute' 6033 This testsuite contains test cases that should compile, link and 6034 run; otherwise the same comments as for 'gcc.c-torture/compile' 6035 apply. 6036'gcc.c-torture/execute/ieee' 6037 This contains tests which are specific to IEEE floating point. 6038'gcc.c-torture/unsorted' 6039 FIXME: describe this. 6040 6041 This directory should probably not be used for new tests. 6042'gcc.misc-tests' 6043 This directory contains C tests that require special handling. 6044 Some of these tests have individual expect files, and others share 6045 special-purpose expect files: 6046 6047 'bprob*.c' 6048 Test '-fbranch-probabilities' using 6049 'gcc.misc-tests/bprob.exp', which in turn uses the generic, 6050 language-independent framework (*note Support for testing 6051 profile-directed optimizations: profopt Testing.). 6052 6053 'gcov*.c' 6054 Test 'gcov' output using 'gcov.exp', which in turn uses the 6055 language-independent support (*note Support for testing gcov: 6056 gcov Testing.). 6057 6058 'i386-pf-*.c' 6059 Test i386-specific support for data prefetch using 6060 'i386-prefetch.exp'. 6061 6062'gcc.test-framework' 6063 'dg-*.c' 6064 Test the testsuite itself using 6065 'gcc.test-framework/test-framework.exp'. 6066 6067 FIXME: merge in 'testsuite/README.gcc' and discuss the format of test 6068cases and magic comments more. 6069 6070 6071File: gccint.info, Node: LTO Testing, Next: gcov Testing, Prev: C Tests, Up: Testsuites 6072 60737.5 Support for testing link-time optimizations 6074=============================================== 6075 6076Tests for link-time optimizations usually require multiple source files 6077that are compiled separately, perhaps with different sets of options. 6078There are several special-purpose test directives used for these tests. 6079 6080'{ dg-lto-do DO-WHAT-KEYWORD }' 6081 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 6082 is executed. It is one of: 6083 6084 'assemble' 6085 Compile with '-c' to produce a relocatable object file. 6086 'link' 6087 Compile, assemble, and link to produce an executable file. 6088 'run' 6089 Produce and run an executable file, which is expected to 6090 return an exit code of 0. 6091 6092 The default is 'assemble'. That can be overridden for a set of 6093 tests by redefining 'dg-do-what-default' within the '.exp' file for 6094 those tests. 6095 6096 Unlike 'dg-do', 'dg-lto-do' does not support an optional 'target' 6097 or 'xfail' list. Use 'dg-skip-if', 'dg-xfail-if', or 6098 'dg-xfail-run-if'. 6099 6100'{ dg-lto-options { { OPTIONS } [{ OPTIONS }] } [{ target SELECTOR }]}' 6101 This directive provides a list of one or more sets of compiler 6102 options to override LTO_OPTIONS. Each test will be compiled and 6103 run with each of these sets of options. 6104 6105'{ dg-extra-ld-options OPTIONS [{ target SELECTOR }]}' 6106 This directive adds OPTIONS to the linker options used. 6107 6108'{ dg-suppress-ld-options OPTIONS [{ target SELECTOR }]}' 6109 This directive removes OPTIONS from the set of linker options used. 6110 6111 6112File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: LTO Testing, Up: Testsuites 6113 61147.6 Support for testing 'gcov' 6115============================== 6116 6117Language-independent support for testing 'gcov', and for checking that 6118branch profiling produces expected values, is provided by the expect 6119file 'lib/gcov.exp'. 'gcov' tests also rely on procedures in 6120'lib/gcc-dg.exp' to compile and run the test program. A typical 'gcov' 6121test contains the following DejaGnu commands within comments: 6122 6123 { dg-options "-fprofile-arcs -ftest-coverage" } 6124 { dg-do run { target native } } 6125 { dg-final { run-gcov sourcefile } } 6126 6127 Checks of 'gcov' output can include line counts, branch percentages, 6128and call return percentages. All of these checks are requested via 6129commands that appear in comments in the test's source file. Commands to 6130check line counts are processed by default. Commands to check branch 6131percentages and call return percentages are processed if the 'run-gcov' 6132command has arguments 'branches' or 'calls', respectively. For example, 6133the following specifies checking both, as well as passing '-b' to 6134'gcov': 6135 6136 { dg-final { run-gcov branches calls { -b sourcefile } } } 6137 6138 A line count command appears within a comment on the source line that 6139is expected to get the specified count and has the form 'count(CNT)'. A 6140test should only check line counts for lines that will get the same 6141count for any architecture. 6142 6143 Commands to check branch percentages ('branch') and call return 6144percentages ('returns') are very similar to each other. A beginning 6145command appears on or before the first of a range of lines that will 6146report the percentage, and the ending command follows that range of 6147lines. The beginning command can include a list of percentages, all of 6148which are expected to be found within the range. A range is terminated 6149by the next command of the same kind. A command 'branch(end)' or 6150'returns(end)' marks the end of a range without starting a new one. For 6151example: 6152 6153 if (i > 10 && j > i && j < 20) /* branch(27 50 75) */ 6154 /* branch(end) */ 6155 foo (i, j); 6156 6157 For a call return percentage, the value specified is the percentage of 6158calls reported to return. For a branch percentage, the value is either 6159the expected percentage or 100 minus that value, since the direction of 6160a branch can differ depending on the target or the optimization level. 6161 6162 Not all branches and calls need to be checked. A test should not check 6163for branches that might be optimized away or replaced with predicated 6164instructions. Don't check for calls inserted by the compiler or ones 6165that might be inlined or optimized away. 6166 6167 A single test can check for combinations of line counts, branch 6168percentages, and call return percentages. The command to check a line 6169count must appear on the line that will report that count, but commands 6170to check branch percentages and call return percentages can bracket the 6171lines that report them. 6172 6173 6174File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites 6175 61767.7 Support for testing profile-directed optimizations 6177====================================================== 6178 6179The file 'profopt.exp' provides language-independent support for 6180checking correct execution of a test built with profile-directed 6181optimization. This testing requires that a test program be built and 6182executed twice. The first time it is compiled to generate profile data, 6183and the second time it is compiled to use the data that was generated 6184during the first execution. The second execution is to verify that the 6185test produces the expected results. 6186 6187 To check that the optimization actually generated better code, a test 6188can be built and run a third time with normal optimizations to verify 6189that the performance is better with the profile-directed optimizations. 6190'profopt.exp' has the beginnings of this kind of support. 6191 6192 'profopt.exp' provides generic support for profile-directed 6193optimizations. Each set of tests that uses it provides information 6194about a specific optimization: 6195 6196'tool' 6197 tool being tested, e.g., 'gcc' 6198 6199'profile_option' 6200 options used to generate profile data 6201 6202'feedback_option' 6203 options used to optimize using that profile data 6204 6205'prof_ext' 6206 suffix of profile data files 6207 6208'PROFOPT_OPTIONS' 6209 list of options with which to run each test, similar to the lists 6210 for torture tests 6211 6212'{ dg-final-generate { LOCAL-DIRECTIVE } }' 6213 This directive is similar to 'dg-final', but the LOCAL-DIRECTIVE is 6214 run after the generation of profile data. 6215 6216'{ dg-final-use { LOCAL-DIRECTIVE } }' 6217 The LOCAL-DIRECTIVE is run after the profile data have been used. 6218 6219 6220File: gccint.info, Node: compat Testing, Next: Torture Tests, Prev: profopt Testing, Up: Testsuites 6221 62227.8 Support for testing binary compatibility 6223============================================ 6224 6225The file 'compat.exp' provides language-independent support for binary 6226compatibility testing. It supports testing interoperability of two 6227compilers that follow the same ABI, or of multiple sets of compiler 6228options that should not affect binary compatibility. It is intended to 6229be used for testsuites that complement ABI testsuites. 6230 6231 A test supported by this framework has three parts, each in a separate 6232source file: a main program and two pieces that interact with each other 6233to split up the functionality being tested. 6234 6235'TESTNAME_main.SUFFIX' 6236 Contains the main program, which calls a function in file 6237 'TESTNAME_x.SUFFIX'. 6238 6239'TESTNAME_x.SUFFIX' 6240 Contains at least one call to a function in 'TESTNAME_y.SUFFIX'. 6241 6242'TESTNAME_y.SUFFIX' 6243 Shares data with, or gets arguments from, 'TESTNAME_x.SUFFIX'. 6244 6245 Within each test, the main program and one functional piece are 6246compiled by the GCC under test. The other piece can be compiled by an 6247alternate compiler. If no alternate compiler is specified, then all 6248three source files are all compiled by the GCC under test. You can 6249specify pairs of sets of compiler options. The first element of such a 6250pair specifies options used with the GCC under test, and the second 6251element of the pair specifies options used with the alternate compiler. 6252Each test is compiled with each pair of options. 6253 6254 'compat.exp' defines default pairs of compiler options. These can be 6255overridden by defining the environment variable 'COMPAT_OPTIONS' as: 6256 6257 COMPAT_OPTIONS="[list [list {TST1} {ALT1}] 6258 ...[list {TSTN} {ALTN}]]" 6259 6260 where TSTI and ALTI are lists of options, with TSTI used by the 6261compiler under test and ALTI used by the alternate compiler. For 6262example, with '[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]', 6263the test is first built with '-g -O0' by the compiler under test and 6264with '-O3' by the alternate compiler. The test is built a second time 6265using '-fpic' by the compiler under test and '-fPIC -O2' by the 6266alternate compiler. 6267 6268 An alternate compiler is specified by defining an environment variable 6269to be the full pathname of an installed compiler; for C define 6270'ALT_CC_UNDER_TEST', and for C++ define 'ALT_CXX_UNDER_TEST'. These 6271will be written to the 'site.exp' file used by DejaGnu. The default is 6272to build each test with the compiler under test using the first of each 6273pair of compiler options from 'COMPAT_OPTIONS'. When 6274'ALT_CC_UNDER_TEST' or 'ALT_CXX_UNDER_TEST' is 'same', each test is 6275built using the compiler under test but with combinations of the options 6276from 'COMPAT_OPTIONS'. 6277 6278 To run only the C++ compatibility suite using the compiler under test 6279and another version of GCC using specific compiler options, do the 6280following from 'OBJDIR/gcc': 6281 6282 rm site.exp 6283 make -k \ 6284 ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \ 6285 COMPAT_OPTIONS="LISTS AS SHOWN ABOVE" \ 6286 check-c++ \ 6287 RUNTESTFLAGS="compat.exp" 6288 6289 A test that fails when the source files are compiled with different 6290compilers, but passes when the files are compiled with the same 6291compiler, demonstrates incompatibility of the generated code or runtime 6292support. A test that fails for the alternate compiler but passes for 6293the compiler under test probably tests for a bug that was fixed in the 6294compiler under test but is present in the alternate compiler. 6295 6296 The binary compatibility tests support a small number of test framework 6297commands that appear within comments in a test file. 6298 6299'dg-require-*' 6300 These commands can be used in 'TESTNAME_main.SUFFIX' to skip the 6301 test if specific support is not available on the target. 6302 6303'dg-options' 6304 The specified options are used for compiling this particular source 6305 file, appended to the options from 'COMPAT_OPTIONS'. When this 6306 command appears in 'TESTNAME_main.SUFFIX' the options are also used 6307 to link the test program. 6308 6309'dg-xfail-if' 6310 This command can be used in a secondary source file to specify that 6311 compilation is expected to fail for particular options on 6312 particular targets. 6313 6314 6315File: gccint.info, Node: Torture Tests, Next: GIMPLE Tests, Prev: compat Testing, Up: Testsuites 6316 63177.9 Support for torture testing using multiple options 6318====================================================== 6319 6320Throughout the compiler testsuite there are several directories whose 6321tests are run multiple times, each with a different set of options. 6322These are known as torture tests. 'lib/torture-options.exp' defines 6323procedures to set up these lists: 6324 6325'torture-init' 6326 Initialize use of torture lists. 6327'set-torture-options' 6328 Set lists of torture options to use for tests with and without 6329 loops. Optionally combine a set of torture options with a set of 6330 other options, as is done with Objective-C runtime options. 6331'torture-finish' 6332 Finalize use of torture lists. 6333 6334 The '.exp' file for a set of tests that use torture options must 6335include calls to these three procedures if: 6336 6337 * It calls 'gcc-dg-runtest' and overrides DG_TORTURE_OPTIONS. 6338 6339 * It calls ${TOOL}'-torture' or ${TOOL}'-torture-execute', where TOOL 6340 is 'c', 'fortran', or 'objc'. 6341 6342 * It calls 'dg-pch'. 6343 6344 It is not necessary for a '.exp' file that calls 'gcc-dg-runtest' to 6345call the torture procedures if the tests should use the list in 6346DG_TORTURE_OPTIONS defined in 'gcc-dg.exp'. 6347 6348 Most uses of torture options can override the default lists by defining 6349TORTURE_OPTIONS or add to the default list by defining 6350ADDITIONAL_TORTURE_OPTIONS. Define these in a '.dejagnurc' file or add 6351them to the 'site.exp' file; for example 6352 6353 set ADDITIONAL_TORTURE_OPTIONS [list \ 6354 { -O2 -ftree-loop-linear } \ 6355 { -O2 -fpeel-loops } ] 6356 6357 6358File: gccint.info, Node: GIMPLE Tests, Next: RTL Tests, Prev: Torture Tests, Up: Testsuites 6359 63607.10 Support for testing GIMPLE passes 6361====================================== 6362 6363As of gcc 7, C functions can be tagged with '__GIMPLE' to indicate that 6364the function body will be GIMPLE, rather than C. The compiler requires 6365the option '-fgimple' to enable this functionality. For example: 6366 6367 /* { dg-do compile } */ 6368 /* { dg-options "-O -fgimple" } */ 6369 6370 void __GIMPLE (startwith ("dse2")) foo () 6371 { 6372 int a; 6373 6374 bb_2: 6375 if (a > 4) 6376 goto bb_3; 6377 else 6378 goto bb_4; 6379 6380 bb_3: 6381 a_2 = 10; 6382 goto bb_5; 6383 6384 bb_4: 6385 a_3 = 20; 6386 6387 bb_5: 6388 a_1 = __PHI (bb_3: a_2, bb_4: a_3); 6389 a_4 = a_1 + 4; 6390 6391 return; 6392 } 6393 6394 The 'startwith' argument indicates at which pass to begin. 6395 6396 Use the dump modifier '-gimple' (e.g. '-fdump-tree-all-gimple') to 6397make tree dumps more closely follow the format accepted by the GIMPLE 6398parser. 6399 6400 Example DejaGnu tests of GIMPLE can be seen in the source tree at 6401'gcc/testsuite/gcc.dg/gimplefe-*.c'. 6402 6403 The '__GIMPLE' parser is integrated with the C tokenizer and 6404preprocessor, so it should be possible to use macros to build out test 6405coverage. 6406 6407 6408File: gccint.info, Node: RTL Tests, Prev: GIMPLE Tests, Up: Testsuites 6409 64107.11 Support for testing RTL passes 6411=================================== 6412 6413As of gcc 7, C functions can be tagged with '__RTL' to indicate that the 6414function body will be RTL, rather than C. For example: 6415 6416 double __RTL (startwith ("ira")) test (struct foo *f, const struct bar *b) 6417 { 6418 (function "test" 6419 [...snip; various directives go in here...] 6420 ) ;; function "test" 6421 } 6422 6423 The 'startwith' argument indicates at which pass to begin. 6424 6425 The parser expects the RTL body to be in the format emitted by this 6426dumping function: 6427 6428 DEBUG_FUNCTION void 6429 print_rtx_function (FILE *outfile, function *fn, bool compact); 6430 6431 when "compact" is true. So you can capture RTL in the correct format 6432from the debugger using: 6433 6434 (gdb) print_rtx_function (stderr, cfun, true); 6435 6436 and copy and paste the output into the body of the C function. 6437 6438 Example DejaGnu tests of RTL can be seen in the source tree under 6439'gcc/testsuite/gcc.dg/rtl'. 6440 6441 The '__RTL' parser is not integrated with the C tokenizer or 6442preprocessor, and works simply by reading the relevant lines within the 6443braces. In particular, the RTL body must be on separate lines from the 6444enclosing braces, and the preprocessor is not usable within it. 6445 6446 6447File: gccint.info, Node: Options, Next: Passes, Prev: Testsuites, Up: Top 6448 64498 Option specification files 6450**************************** 6451 6452Most GCC command-line options are described by special option definition 6453files, the names of which conventionally end in '.opt'. This chapter 6454describes the format of these files. 6455 6456* Menu: 6457 6458* Option file format:: The general layout of the files 6459* Option properties:: Supported option properties 6460 6461 6462File: gccint.info, Node: Option file format, Next: Option properties, Up: Options 6463 64648.1 Option file format 6465====================== 6466 6467Option files are a simple list of records in which each field occupies 6468its own line and in which the records themselves are separated by blank 6469lines. Comments may appear on their own line anywhere within the file 6470and are preceded by semicolons. Whitespace is allowed before the 6471semicolon. 6472 6473 The files can contain the following types of record: 6474 6475 * A language definition record. These records have two fields: the 6476 string 'Language' and the name of the language. Once a language 6477 has been declared in this way, it can be used as an option 6478 property. *Note Option properties::. 6479 6480 * A target specific save record to save additional information. 6481 These records have two fields: the string 'TargetSave', and a 6482 declaration type to go in the 'cl_target_option' structure. 6483 6484 * A variable record to define a variable used to store option 6485 information. These records have two fields: the string 'Variable', 6486 and a declaration of the type and name of the variable, optionally 6487 with an initializer (but without any trailing ';'). These records 6488 may be used for variables used for many options where declaring the 6489 initializer in a single option definition record, or duplicating it 6490 in many records, would be inappropriate, or for variables set in 6491 option handlers rather than referenced by 'Var' properties. 6492 6493 * A variable record to define a variable used to store option 6494 information. These records have two fields: the string 6495 'TargetVariable', and a declaration of the type and name of the 6496 variable, optionally with an initializer (but without any trailing 6497 ';'). 'TargetVariable' is a combination of 'Variable' and 6498 'TargetSave' records in that the variable is defined in the 6499 'gcc_options' structure, but these variables are also stored in the 6500 'cl_target_option' structure. The variables are saved in the 6501 target save code and restored in the target restore code. 6502 6503 * A variable record to record any additional files that the 6504 'options.h' file should include. This is useful to provide 6505 enumeration or structure definitions needed for target variables. 6506 These records have two fields: the string 'HeaderInclude' and the 6507 name of the include file. 6508 6509 * A variable record to record any additional files that the 6510 'options.c' or 'options-save.c' file should include. This is 6511 useful to provide inline functions needed for target variables 6512 and/or '#ifdef' sequences to properly set up the initialization. 6513 These records have two fields: the string 'SourceInclude' and the 6514 name of the include file. 6515 6516 * An enumeration record to define a set of strings that may be used 6517 as arguments to an option or options. These records have three 6518 fields: the string 'Enum', a space-separated list of properties and 6519 help text used to describe the set of strings in '--help' output. 6520 Properties use the same format as option properties; the following 6521 are valid: 6522 'Name(NAME)' 6523 This property is required; NAME must be a name (suitable for 6524 use in C identifiers) used to identify the set of strings in 6525 'Enum' option properties. 6526 6527 'Type(TYPE)' 6528 This property is required; TYPE is the C type for variables 6529 set by options using this enumeration together with 'Var'. 6530 6531 'UnknownError(MESSAGE)' 6532 The message MESSAGE will be used as an error message if the 6533 argument is invalid; for enumerations without 'UnknownError', 6534 a generic error message is used. MESSAGE should contain a 6535 single '%qs' format, which will be used to format the invalid 6536 argument. 6537 6538 * An enumeration value record to define one of the strings in a set 6539 given in an 'Enum' record. These records have two fields: the 6540 string 'EnumValue' and a space-separated list of properties. 6541 Properties use the same format as option properties; the following 6542 are valid: 6543 'Enum(NAME)' 6544 This property is required; NAME says which 'Enum' record this 6545 'EnumValue' record corresponds to. 6546 6547 'String(STRING)' 6548 This property is required; STRING is the string option 6549 argument being described by this record. 6550 6551 'Value(VALUE)' 6552 This property is required; it says what value (representable 6553 as 'int') should be used for the given string. 6554 6555 'Canonical' 6556 This property is optional. If present, it says the present 6557 string is the canonical one among all those with the given 6558 value. Other strings yielding that value will be mapped to 6559 this one so specs do not need to handle them. 6560 6561 'DriverOnly' 6562 This property is optional. If present, the present string 6563 will only be accepted by the driver. This is used for cases 6564 such as '-march=native' that are processed by the driver so 6565 that 'gcc -v' shows how the options chosen depended on the 6566 system on which the compiler was run. 6567 6568 * An option definition record. These records have the following 6569 fields: 6570 1. the name of the option, with the leading "-" removed 6571 2. a space-separated list of option properties (*note Option 6572 properties::) 6573 3. the help text to use for '--help' (omitted if the second field 6574 contains the 'Undocumented' property). 6575 6576 By default, all options beginning with "f", "W" or "m" are 6577 implicitly assumed to take a "no-" form. This form should not be 6578 listed separately. If an option beginning with one of these 6579 letters does not have a "no-" form, you can use the 6580 'RejectNegative' property to reject it. 6581 6582 The help text is automatically line-wrapped before being displayed. 6583 Normally the name of the option is printed on the left-hand side of 6584 the output and the help text is printed on the right. However, if 6585 the help text contains a tab character, the text to the left of the 6586 tab is used instead of the option's name and the text to the right 6587 of the tab forms the help text. This allows you to elaborate on 6588 what type of argument the option takes. 6589 6590 * A target mask record. These records have one field of the form 6591 'Mask(X)'. The options-processing script will automatically 6592 allocate a bit in 'target_flags' (*note Run-time Target::) for each 6593 mask name X and set the macro 'MASK_X' to the appropriate bitmask. 6594 It will also declare a 'TARGET_X' macro that has the value 1 when 6595 bit 'MASK_X' is set and 0 otherwise. 6596 6597 They are primarily intended to declare target masks that are not 6598 associated with user options, either because these masks represent 6599 internal switches or because the options are not available on all 6600 configurations and yet the masks always need to be defined. 6601 6602 6603File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options 6604 66058.2 Option properties 6606===================== 6607 6608The second field of an option record can specify any of the following 6609properties. When an option takes an argument, it is enclosed in 6610parentheses following the option property name. The parser that handles 6611option files is quite simplistic, and will be tricked by any nested 6612parentheses within the argument text itself; in this case, the entire 6613option argument can be wrapped in curly braces within the parentheses to 6614demarcate it, e.g.: 6615 6616 Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)}) 6617 6618'Common' 6619 The option is available for all languages and targets. 6620 6621'Target' 6622 The option is available for all languages but is target-specific. 6623 6624'Driver' 6625 The option is handled by the compiler driver using code not shared 6626 with the compilers proper ('cc1' etc.). 6627 6628'LANGUAGE' 6629 The option is available when compiling for the given language. 6630 6631 It is possible to specify several different languages for the same 6632 option. Each LANGUAGE must have been declared by an earlier 6633 'Language' record. *Note Option file format::. 6634 6635'RejectDriver' 6636 The option is only handled by the compilers proper ('cc1' etc.) and 6637 should not be accepted by the driver. 6638 6639'RejectNegative' 6640 The option does not have a "no-" form. All options beginning with 6641 "f", "W" or "m" are assumed to have a "no-" form unless this 6642 property is used. 6643 6644'Negative(OTHERNAME)' 6645 The option will turn off another option OTHERNAME, which is the 6646 option name with the leading "-" removed. This chain action will 6647 propagate through the 'Negative' property of the option to be 6648 turned off. 6649 6650 As a consequence, if you have a group of mutually-exclusive 6651 options, their 'Negative' properties should form a circular chain. 6652 For example, if options '-A', '-B' and '-C' are mutually exclusive, 6653 their respective 'Negative' properties should be 'Negative(B)', 6654 'Negative(C)' and 'Negative(A)'. 6655 6656'Joined' 6657'Separate' 6658 The option takes a mandatory argument. 'Joined' indicates that the 6659 option and argument can be included in the same 'argv' entry (as 6660 with '-mflush-func=NAME', for example). 'Separate' indicates that 6661 the option and argument can be separate 'argv' entries (as with 6662 '-o'). An option is allowed to have both of these properties. 6663 6664'JoinedOrMissing' 6665 The option takes an optional argument. If the argument is given, 6666 it will be part of the same 'argv' entry as the option itself. 6667 6668 This property cannot be used alongside 'Joined' or 'Separate'. 6669 6670'MissingArgError(MESSAGE)' 6671 For an option marked 'Joined' or 'Separate', the message MESSAGE 6672 will be used as an error message if the mandatory argument is 6673 missing; for options without 'MissingArgError', a generic error 6674 message is used. MESSAGE should contain a single '%qs' format, 6675 which will be used to format the name of the option passed. 6676 6677'Args(N)' 6678 For an option marked 'Separate', indicate that it takes N 6679 arguments. The default is 1. 6680 6681'UInteger' 6682 The option's argument is a non-negative integer. The option parser 6683 will check and convert the argument before passing it to the 6684 relevant option handler. 'UInteger' should also be used on options 6685 like '-falign-loops' where both '-falign-loops' and 6686 '-falign-loops'=N are supported to make sure the saved options are 6687 given a full integer. 6688 6689'ToLower' 6690 The option's argument should be converted to lowercase as part of 6691 putting it in canonical form, and before comparing with the strings 6692 indicated by any 'Enum' property. 6693 6694'NoDriverArg' 6695 For an option marked 'Separate', the option only takes an argument 6696 in the compiler proper, not in the driver. This is for 6697 compatibility with existing options that are used both directly and 6698 via '-Wp,'; new options should not have this property. 6699 6700'Var(VAR)' 6701 The state of this option should be stored in variable VAR (actually 6702 a macro for 'global_options.x_VAR'). The way that the state is 6703 stored depends on the type of option: 6704 6705 * If the option uses the 'Mask' or 'InverseMask' properties, VAR 6706 is the integer variable that contains the mask. 6707 6708 * If the option is a normal on/off switch, VAR is an integer 6709 variable that is nonzero when the option is enabled. The 6710 options parser will set the variable to 1 when the positive 6711 form of the option is used and 0 when the "no-" form is used. 6712 6713 * If the option takes an argument and has the 'UInteger' 6714 property, VAR is an integer variable that stores the value of 6715 the argument. 6716 6717 * If the option takes an argument and has the 'Enum' property, 6718 VAR is a variable (type given in the 'Type' property of the 6719 'Enum' record whose 'Name' property has the same argument as 6720 the 'Enum' property of this option) that stores the value of 6721 the argument. 6722 6723 * If the option has the 'Defer' property, VAR is a pointer to a 6724 'VEC(cl_deferred_option,heap)' that stores the option for 6725 later processing. (VAR is declared with type 'void *' and 6726 needs to be cast to 'VEC(cl_deferred_option,heap)' before 6727 use.) 6728 6729 * Otherwise, if the option takes an argument, VAR is a pointer 6730 to the argument string. The pointer will be null if the 6731 argument is optional and wasn't given. 6732 6733 The option-processing script will usually zero-initialize VAR. You 6734 can modify this behavior using 'Init'. 6735 6736'Var(VAR, SET)' 6737 The option controls an integer variable VAR and is active when VAR 6738 equals SET. The option parser will set VAR to SET when the 6739 positive form of the option is used and '!SET' when the "no-" form 6740 is used. 6741 6742 VAR is declared in the same way as for the single-argument form 6743 described above. 6744 6745'Init(VALUE)' 6746 The variable specified by the 'Var' property should be statically 6747 initialized to VALUE. If more than one option using the same 6748 variable specifies 'Init', all must specify the same initializer. 6749 6750'Mask(NAME)' 6751 The option is associated with a bit in the 'target_flags' variable 6752 (*note Run-time Target::) and is active when that bit is set. You 6753 may also specify 'Var' to select a variable other than 6754 'target_flags'. 6755 6756 The options-processing script will automatically allocate a unique 6757 bit for the option. If the option is attached to 'target_flags', 6758 the script will set the macro 'MASK_NAME' to the appropriate 6759 bitmask. It will also declare a 'TARGET_NAME' macro that has the 6760 value 1 when the option is active and 0 otherwise. If you use 6761 'Var' to attach the option to a different variable, the bitmask 6762 macro with be called 'OPTION_MASK_NAME'. 6763 6764'InverseMask(OTHERNAME)' 6765'InverseMask(OTHERNAME, THISNAME)' 6766 The option is the inverse of another option that has the 6767 'Mask(OTHERNAME)' property. If THISNAME is given, the 6768 options-processing script will declare a 'TARGET_THISNAME' macro 6769 that is 1 when the option is active and 0 otherwise. 6770 6771'Enum(NAME)' 6772 The option's argument is a string from the set of strings 6773 associated with the corresponding 'Enum' record. The string is 6774 checked and converted to the integer specified in the corresponding 6775 'EnumValue' record before being passed to option handlers. 6776 6777'Defer' 6778 The option should be stored in a vector, specified with 'Var', for 6779 later processing. 6780 6781'Alias(OPT)' 6782'Alias(OPT, ARG)' 6783'Alias(OPT, POSARG, NEGARG)' 6784 The option is an alias for '-OPT' (or the negative form of that 6785 option, depending on 'NegativeAlias'). In the first form, any 6786 argument passed to the alias is considered to be passed to '-OPT', 6787 and '-OPT' is considered to be negated if the alias is used in 6788 negated form. In the second form, the alias may not be negated or 6789 have an argument, and POSARG is considered to be passed as an 6790 argument to '-OPT'. In the third form, the alias may not have an 6791 argument, if the alias is used in the positive form then POSARG is 6792 considered to be passed to '-OPT', and if the alias is used in the 6793 negative form then NEGARG is considered to be passed to '-OPT'. 6794 6795 Aliases should not specify 'Var' or 'Mask' or 'UInteger'. Aliases 6796 should normally specify the same languages as the target of the 6797 alias; the flags on the target will be used to determine any 6798 diagnostic for use of an option for the wrong language, while those 6799 on the alias will be used to identify what command-line text is the 6800 option and what text is any argument to that option. 6801 6802 When an 'Alias' definition is used for an option, driver specs do 6803 not need to handle it and no 'OPT_' enumeration value is defined 6804 for it; only the canonical form of the option will be seen in those 6805 places. 6806 6807'NegativeAlias' 6808 For an option marked with 'Alias(OPT)', the option is considered to 6809 be an alias for the positive form of '-OPT' if negated and for the 6810 negative form of '-OPT' if not negated. 'NegativeAlias' may not be 6811 used with the forms of 'Alias' taking more than one argument. 6812 6813'Ignore' 6814 This option is ignored apart from printing any warning specified 6815 using 'Warn'. The option will not be seen by specs and no 'OPT_' 6816 enumeration value is defined for it. 6817 6818'SeparateAlias' 6819 For an option marked with 'Joined', 'Separate' and 'Alias', the 6820 option only acts as an alias when passed a separate argument; with 6821 a joined argument it acts as a normal option, with an 'OPT_' 6822 enumeration value. This is for compatibility with the Java '-d' 6823 option and should not be used for new options. 6824 6825'Warn(MESSAGE)' 6826 If this option is used, output the warning MESSAGE. MESSAGE is a 6827 format string, either taking a single operand with a '%qs' format 6828 which is the option name, or not taking any operands, which is 6829 passed to the 'warning' function. If an alias is marked 'Warn', 6830 the target of the alias must not also be marked 'Warn'. 6831 6832'Report' 6833 The state of the option should be printed by '-fverbose-asm'. 6834 6835'Warning' 6836 This is a warning option and should be shown as such in '--help' 6837 output. This flag does not currently affect anything other than 6838 '--help'. 6839 6840'Optimization' 6841 This is an optimization option. It should be shown as such in 6842 '--help' output, and any associated variable named using 'Var' 6843 should be saved and restored when the optimization level is changed 6844 with 'optimize' attributes. 6845 6846'PerFunction' 6847 This is an option that can be overridden on a per-function basis. 6848 'Optimization' implies 'PerFunction', but options that do not 6849 affect executable code generation may use this flag instead, so 6850 that the option is not taken into account in ways that might affect 6851 executable code generation. 6852 6853'Undocumented' 6854 The option is deliberately missing documentation and should not be 6855 included in the '--help' output. 6856 6857'Condition(COND)' 6858 The option should only be accepted if preprocessor condition COND 6859 is true. Note that any C declarations associated with the option 6860 will be present even if COND is false; COND simply controls whether 6861 the option is accepted and whether it is printed in the '--help' 6862 output. 6863 6864'Save' 6865 Build the 'cl_target_option' structure to hold a copy of the 6866 option, add the functions 'cl_target_option_save' and 6867 'cl_target_option_restore' to save and restore the options. 6868 6869'SetByCombined' 6870 The option may also be set by a combined option such as 6871 '-ffast-math'. This causes the 'gcc_options' struct to have a 6872 field 'frontend_set_NAME', where 'NAME' is the name of the field 6873 holding the value of this option (without the leading 'x_'). This 6874 gives the front end a way to indicate that the value has been set 6875 explicitly and should not be changed by the combined option. For 6876 example, some front ends use this to prevent '-ffast-math' and 6877 '-fno-fast-math' from changing the value of '-fmath-errno' for 6878 languages that do not use 'errno'. 6879 6880'EnabledBy(OPT)' 6881'EnabledBy(OPT || OPT2)' 6882'EnabledBy(OPT && OPT2)' 6883 If not explicitly set, the option is set to the value of '-OPT'; 6884 multiple options can be given, separated by '||'. The third form 6885 using '&&' specifies that the option is only set if both OPT and 6886 OPT2 are set. The options OPT and OPT2 must have the 'Common' 6887 property; otherwise, use 'LangEnabledBy'. 6888 6889'LangEnabledBy(LANGUAGE, OPT)' 6890'LangEnabledBy(LANGUAGE, OPT, POSARG, NEGARG)' 6891 When compiling for the given language, the option is set to the 6892 value of '-OPT', if not explicitly set. OPT can be also a list of 6893 '||' separated options. In the second form, if OPT is used in the 6894 positive form then POSARG is considered to be passed to the option, 6895 and if OPT is used in the negative form then NEGARG is considered 6896 to be passed to the option. It is possible to specify several 6897 different languages. Each LANGUAGE must have been declared by an 6898 earlier 'Language' record. *Note Option file format::. 6899 6900'NoDWARFRecord' 6901 The option is omitted from the producer string written by 6902 '-grecord-gcc-switches'. 6903 6904'PchIgnore' 6905 Even if this is a target option, this option will not be recorded / 6906 compared to determine if a precompiled header file matches. 6907 6908'CPP(VAR)' 6909 The state of this option should be kept in sync with the 6910 preprocessor option VAR. If this property is set, then properties 6911 'Var' and 'Init' must be set as well. 6912 6913'CppReason(CPP_W_ENUM)' 6914 This warning option corresponds to 'cpplib.h' warning reason code 6915 CPP_W_ENUM. This should only be used for warning options of the 6916 C-family front-ends. 6917 6918 6919File: gccint.info, Node: Passes, Next: poly_int, Prev: Options, Up: Top 6920 69219 Passes and Files of the Compiler 6922********************************** 6923 6924This chapter is dedicated to giving an overview of the optimization and 6925code generation passes of the compiler. In the process, it describes 6926some of the language front end interface, though this description is no 6927where near complete. 6928 6929* Menu: 6930 6931* Parsing pass:: The language front end turns text into bits. 6932* Gimplification pass:: The bits are turned into something we can optimize. 6933* Pass manager:: Sequencing the optimization passes. 6934* Tree SSA passes:: Optimizations on a high-level representation. 6935* RTL passes:: Optimizations on a low-level representation. 6936* Optimization info:: Dumping optimization information from passes. 6937 6938 6939File: gccint.info, Node: Parsing pass, Next: Gimplification pass, Up: Passes 6940 69419.1 Parsing pass 6942================ 6943 6944The language front end is invoked only once, via 6945'lang_hooks.parse_file', to parse the entire input. The language front 6946end may use any intermediate language representation deemed appropriate. 6947The C front end uses GENERIC trees (*note GENERIC::), plus a double 6948handful of language specific tree codes defined in 'c-common.def'. The 6949Fortran front end uses a completely different private representation. 6950 6951 At some point the front end must translate the representation used in 6952the front end to a representation understood by the language-independent 6953portions of the compiler. Current practice takes one of two forms. The 6954C front end manually invokes the gimplifier (*note GIMPLE::) on each 6955function, and uses the gimplifier callbacks to convert the 6956language-specific tree nodes directly to GIMPLE before passing the 6957function off to be compiled. The Fortran front end converts from a 6958private representation to GENERIC, which is later lowered to GIMPLE when 6959the function is compiled. Which route to choose probably depends on how 6960well GENERIC (plus extensions) can be made to match up with the source 6961language and necessary parsing data structures. 6962 6963 BUG: Gimplification must occur before nested function lowering, and 6964nested function lowering must be done by the front end before passing 6965the data off to cgraph. 6966 6967 TODO: Cgraph should control nested function lowering. It would only be 6968invoked when it is certain that the outer-most function is used. 6969 6970 TODO: Cgraph needs a gimplify_function callback. It should be invoked 6971when (1) it is certain that the function is used, (2) warning flags 6972specified by the user require some amount of compilation in order to 6973honor, (3) the language indicates that semantic analysis is not complete 6974until gimplification occurs. Hum... this sounds overly complicated. 6975Perhaps we should just have the front end gimplify always; in most cases 6976it's only one function call. 6977 6978 The front end needs to pass all function definitions and top level 6979declarations off to the middle-end so that they can be compiled and 6980emitted to the object file. For a simple procedural language, it is 6981usually most convenient to do this as each top level declaration or 6982definition is seen. There is also a distinction to be made between 6983generating functional code and generating complete debug information. 6984The only thing that is absolutely required for functional code is that 6985function and data _definitions_ be passed to the middle-end. For 6986complete debug information, function, data and type declarations should 6987all be passed as well. 6988 6989 In any case, the front end needs each complete top-level function or 6990data declaration, and each data definition should be passed to 6991'rest_of_decl_compilation'. Each complete type definition should be 6992passed to 'rest_of_type_compilation'. Each function definition should 6993be passed to 'cgraph_finalize_function'. 6994 6995 TODO: I know rest_of_compilation currently has all sorts of RTL 6996generation semantics. I plan to move all code generation bits (both 6997Tree and RTL) to compile_function. Should we hide cgraph from the front 6998ends and move back to rest_of_compilation as the official interface? 6999Possibly we should rename all three interfaces such that the names match 7000in some meaningful way and that is more descriptive than "rest_of". 7001 7002 The middle-end will, at its option, emit the function and data 7003definitions immediately or queue them for later processing. 7004 7005 7006File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Parsing pass, Up: Passes 7007 70089.2 Gimplification pass 7009======================= 7010 7011"Gimplification" is a whimsical term for the process of converting the 7012intermediate representation of a function into the GIMPLE language 7013(*note GIMPLE::). The term stuck, and so words like "gimplification", 7014"gimplify", "gimplifier" and the like are sprinkled throughout this 7015section of code. 7016 7017 While a front end may certainly choose to generate GIMPLE directly if 7018it chooses, this can be a moderately complex process unless the 7019intermediate language used by the front end is already fairly simple. 7020Usually it is easier to generate GENERIC trees plus extensions and let 7021the language-independent gimplifier do most of the work. 7022 7023 The main entry point to this pass is 'gimplify_function_tree' located 7024in 'gimplify.c'. From here we process the entire function gimplifying 7025each statement in turn. The main workhorse for this pass is 7026'gimplify_expr'. Approximately everything passes through here at least 7027once, and it is from here that we invoke the 'lang_hooks.gimplify_expr' 7028callback. 7029 7030 The callback should examine the expression in question and return 7031'GS_UNHANDLED' if the expression is not a language specific construct 7032that requires attention. Otherwise it should alter the expression in 7033some way to such that forward progress is made toward producing valid 7034GIMPLE. If the callback is certain that the transformation is complete 7035and the expression is valid GIMPLE, it should return 'GS_ALL_DONE'. 7036Otherwise it should return 'GS_OK', which will cause the expression to 7037be processed again. If the callback encounters an error during the 7038transformation (because the front end is relying on the gimplification 7039process to finish semantic checks), it should return 'GS_ERROR'. 7040 7041 7042File: gccint.info, Node: Pass manager, Next: Tree SSA passes, Prev: Gimplification pass, Up: Passes 7043 70449.3 Pass manager 7045================ 7046 7047The pass manager is located in 'passes.c', 'tree-optimize.c' and 7048'tree-pass.h'. It processes passes as described in 'passes.def'. Its 7049job is to run all of the individual passes in the correct order, and 7050take care of standard bookkeeping that applies to every pass. 7051 7052 The theory of operation is that each pass defines a structure that 7053represents everything we need to know about that pass--when it should be 7054run, how it should be run, what intermediate language form or 7055on-the-side data structures it needs. We register the pass to be run in 7056some particular order, and the pass manager arranges for everything to 7057happen in the correct order. 7058 7059 The actuality doesn't completely live up to the theory at present. 7060Command-line switches and 'timevar_id_t' enumerations must still be 7061defined elsewhere. The pass manager validates constraints but does not 7062attempt to (re-)generate data structures or lower intermediate language 7063form based on the requirements of the next pass. Nevertheless, what is 7064present is useful, and a far sight better than nothing at all. 7065 7066 Each pass should have a unique name. Each pass may have its own dump 7067file (for GCC debugging purposes). Passes with a name starting with a 7068star do not dump anything. Sometimes passes are supposed to share a 7069dump file / option name. To still give these unique names, you can use 7070a prefix that is delimited by a space from the part that is used for the 7071dump file / option name. E.g. When the pass name is "ud dce", the name 7072used for dump file/options is "dce". 7073 7074 TODO: describe the global variables set up by the pass manager, and a 7075brief description of how a new pass should use it. I need to look at 7076what info RTL passes use first... 7077 7078 7079File: gccint.info, Node: Tree SSA passes, Next: RTL passes, Prev: Pass manager, Up: Passes 7080 70819.4 Tree SSA passes 7082=================== 7083 7084The following briefly describes the Tree optimization passes that are 7085run after gimplification and what source files they are located in. 7086 7087 * Remove useless statements 7088 7089 This pass is an extremely simple sweep across the gimple code in 7090 which we identify obviously dead code and remove it. Here we do 7091 things like simplify 'if' statements with constant conditions, 7092 remove exception handling constructs surrounding code that 7093 obviously cannot throw, remove lexical bindings that contain no 7094 variables, and other assorted simplistic cleanups. The idea is to 7095 get rid of the obvious stuff quickly rather than wait until later 7096 when it's more work to get rid of it. This pass is located in 7097 'tree-cfg.c' and described by 'pass_remove_useless_stmts'. 7098 7099 * OpenMP lowering 7100 7101 If OpenMP generation ('-fopenmp') is enabled, this pass lowers 7102 OpenMP constructs into GIMPLE. 7103 7104 Lowering of OpenMP constructs involves creating replacement 7105 expressions for local variables that have been mapped using data 7106 sharing clauses, exposing the control flow of most synchronization 7107 directives and adding region markers to facilitate the creation of 7108 the control flow graph. The pass is located in 'omp-low.c' and is 7109 described by 'pass_lower_omp'. 7110 7111 * OpenMP expansion 7112 7113 If OpenMP generation ('-fopenmp') is enabled, this pass expands 7114 parallel regions into their own functions to be invoked by the 7115 thread library. The pass is located in 'omp-low.c' and is 7116 described by 'pass_expand_omp'. 7117 7118 * Lower control flow 7119 7120 This pass flattens 'if' statements ('COND_EXPR') and moves lexical 7121 bindings ('BIND_EXPR') out of line. After this pass, all 'if' 7122 statements will have exactly two 'goto' statements in its 'then' 7123 and 'else' arms. Lexical binding information for each statement 7124 will be found in 'TREE_BLOCK' rather than being inferred from its 7125 position under a 'BIND_EXPR'. This pass is found in 'gimple-low.c' 7126 and is described by 'pass_lower_cf'. 7127 7128 * Lower exception handling control flow 7129 7130 This pass decomposes high-level exception handling constructs 7131 ('TRY_FINALLY_EXPR' and 'TRY_CATCH_EXPR') into a form that 7132 explicitly represents the control flow involved. After this pass, 7133 'lookup_stmt_eh_region' will return a non-negative number for any 7134 statement that may have EH control flow semantics; examine 7135 'tree_can_throw_internal' or 'tree_can_throw_external' for exact 7136 semantics. Exact control flow may be extracted from 7137 'foreach_reachable_handler'. The EH region nesting tree is defined 7138 in 'except.h' and built in 'except.c'. The lowering pass itself is 7139 in 'tree-eh.c' and is described by 'pass_lower_eh'. 7140 7141 * Build the control flow graph 7142 7143 This pass decomposes a function into basic blocks and creates all 7144 of the edges that connect them. It is located in 'tree-cfg.c' and 7145 is described by 'pass_build_cfg'. 7146 7147 * Find all referenced variables 7148 7149 This pass walks the entire function and collects an array of all 7150 variables referenced in the function, 'referenced_vars'. The index 7151 at which a variable is found in the array is used as a UID for the 7152 variable within this function. This data is needed by the SSA 7153 rewriting routines. The pass is located in 'tree-dfa.c' and is 7154 described by 'pass_referenced_vars'. 7155 7156 * Enter static single assignment form 7157 7158 This pass rewrites the function such that it is in SSA form. After 7159 this pass, all 'is_gimple_reg' variables will be referenced by 7160 'SSA_NAME', and all occurrences of other variables will be 7161 annotated with 'VDEFS' and 'VUSES'; PHI nodes will have been 7162 inserted as necessary for each basic block. This pass is located 7163 in 'tree-ssa.c' and is described by 'pass_build_ssa'. 7164 7165 * Warn for uninitialized variables 7166 7167 This pass scans the function for uses of 'SSA_NAME's that are fed 7168 by default definition. For non-parameter variables, such uses are 7169 uninitialized. The pass is run twice, before and after 7170 optimization (if turned on). In the first pass we only warn for 7171 uses that are positively uninitialized; in the second pass we warn 7172 for uses that are possibly uninitialized. The pass is located in 7173 'tree-ssa.c' and is defined by 'pass_early_warn_uninitialized' and 7174 'pass_late_warn_uninitialized'. 7175 7176 * Dead code elimination 7177 7178 This pass scans the function for statements without side effects 7179 whose result is unused. It does not do memory life analysis, so 7180 any value that is stored in memory is considered used. The pass is 7181 run multiple times throughout the optimization process. It is 7182 located in 'tree-ssa-dce.c' and is described by 'pass_dce'. 7183 7184 * Dominator optimizations 7185 7186 This pass performs trivial dominator-based copy and constant 7187 propagation, expression simplification, and jump threading. It is 7188 run multiple times throughout the optimization process. It is 7189 located in 'tree-ssa-dom.c' and is described by 'pass_dominator'. 7190 7191 * Forward propagation of single-use variables 7192 7193 This pass attempts to remove redundant computation by substituting 7194 variables that are used once into the expression that uses them and 7195 seeing if the result can be simplified. It is located in 7196 'tree-ssa-forwprop.c' and is described by 'pass_forwprop'. 7197 7198 * Copy Renaming 7199 7200 This pass attempts to change the name of compiler temporaries 7201 involved in copy operations such that SSA->normal can coalesce the 7202 copy away. When compiler temporaries are copies of user variables, 7203 it also renames the compiler temporary to the user variable 7204 resulting in better use of user symbols. It is located in 7205 'tree-ssa-copyrename.c' and is described by 'pass_copyrename'. 7206 7207 * PHI node optimizations 7208 7209 This pass recognizes forms of PHI inputs that can be represented as 7210 conditional expressions and rewrites them into straight line code. 7211 It is located in 'tree-ssa-phiopt.c' and is described by 7212 'pass_phiopt'. 7213 7214 * May-alias optimization 7215 7216 This pass performs a flow sensitive SSA-based points-to analysis. 7217 The resulting may-alias, must-alias, and escape analysis 7218 information is used to promote variables from in-memory addressable 7219 objects to non-aliased variables that can be renamed into SSA form. 7220 We also update the 'VDEF'/'VUSE' memory tags for non-renameable 7221 aggregates so that we get fewer false kills. The pass is located 7222 in 'tree-ssa-alias.c' and is described by 'pass_may_alias'. 7223 7224 Interprocedural points-to information is located in 7225 'tree-ssa-structalias.c' and described by 'pass_ipa_pta'. 7226 7227 * Profiling 7228 7229 This pass instruments the function in order to collect runtime 7230 block and value profiling data. Such data may be fed back into the 7231 compiler on a subsequent run so as to allow optimization based on 7232 expected execution frequencies. The pass is located in 7233 'tree-profile.c' and is described by 'pass_ipa_tree_profile'. 7234 7235 * Static profile estimation 7236 7237 This pass implements series of heuristics to guess propababilities 7238 of branches. The resulting predictions are turned into edge 7239 profile by propagating branches across the control flow graphs. 7240 The pass is located in 'tree-profile.c' and is described by 7241 'pass_profile'. 7242 7243 * Lower complex arithmetic 7244 7245 This pass rewrites complex arithmetic operations into their 7246 component scalar arithmetic operations. The pass is located in 7247 'tree-complex.c' and is described by 'pass_lower_complex'. 7248 7249 * Scalar replacement of aggregates 7250 7251 This pass rewrites suitable non-aliased local aggregate variables 7252 into a set of scalar variables. The resulting scalar variables are 7253 rewritten into SSA form, which allows subsequent optimization 7254 passes to do a significantly better job with them. The pass is 7255 located in 'tree-sra.c' and is described by 'pass_sra'. 7256 7257 * Dead store elimination 7258 7259 This pass eliminates stores to memory that are subsequently 7260 overwritten by another store, without any intervening loads. The 7261 pass is located in 'tree-ssa-dse.c' and is described by 'pass_dse'. 7262 7263 * Tail recursion elimination 7264 7265 This pass transforms tail recursion into a loop. It is located in 7266 'tree-tailcall.c' and is described by 'pass_tail_recursion'. 7267 7268 * Forward store motion 7269 7270 This pass sinks stores and assignments down the flowgraph closer to 7271 their use point. The pass is located in 'tree-ssa-sink.c' and is 7272 described by 'pass_sink_code'. 7273 7274 * Partial redundancy elimination 7275 7276 This pass eliminates partially redundant computations, as well as 7277 performing load motion. The pass is located in 'tree-ssa-pre.c' 7278 and is described by 'pass_pre'. 7279 7280 Just before partial redundancy elimination, if 7281 '-funsafe-math-optimizations' is on, GCC tries to convert divisions 7282 to multiplications by the reciprocal. The pass is located in 7283 'tree-ssa-math-opts.c' and is described by 'pass_cse_reciprocal'. 7284 7285 * Full redundancy elimination 7286 7287 This is a simpler form of PRE that only eliminates redundancies 7288 that occur on all paths. It is located in 'tree-ssa-pre.c' and 7289 described by 'pass_fre'. 7290 7291 * Loop optimization 7292 7293 The main driver of the pass is placed in 'tree-ssa-loop.c' and 7294 described by 'pass_loop'. 7295 7296 The optimizations performed by this pass are: 7297 7298 Loop invariant motion. This pass moves only invariants that would 7299 be hard to handle on RTL level (function calls, operations that 7300 expand to nontrivial sequences of insns). With '-funswitch-loops' 7301 it also moves operands of conditions that are invariant out of the 7302 loop, so that we can use just trivial invariantness analysis in 7303 loop unswitching. The pass also includes store motion. The pass 7304 is implemented in 'tree-ssa-loop-im.c'. 7305 7306 Canonical induction variable creation. This pass creates a simple 7307 counter for number of iterations of the loop and replaces the exit 7308 condition of the loop using it, in case when a complicated analysis 7309 is necessary to determine the number of iterations. Later 7310 optimizations then may determine the number easily. The pass is 7311 implemented in 'tree-ssa-loop-ivcanon.c'. 7312 7313 Induction variable optimizations. This pass performs standard 7314 induction variable optimizations, including strength reduction, 7315 induction variable merging and induction variable elimination. The 7316 pass is implemented in 'tree-ssa-loop-ivopts.c'. 7317 7318 Loop unswitching. This pass moves the conditional jumps that are 7319 invariant out of the loops. To achieve this, a duplicate of the 7320 loop is created for each possible outcome of conditional jump(s). 7321 The pass is implemented in 'tree-ssa-loop-unswitch.c'. 7322 7323 Loop splitting. If a loop contains a conditional statement that is 7324 always true for one part of the iteration space and false for the 7325 other this pass splits the loop into two, one dealing with one side 7326 the other only with the other, thereby removing one inner-loop 7327 conditional. The pass is implemented in 'tree-ssa-loop-split.c'. 7328 7329 The optimizations also use various utility functions contained in 7330 'tree-ssa-loop-manip.c', 'cfgloop.c', 'cfgloopanal.c' and 7331 'cfgloopmanip.c'. 7332 7333 Vectorization. This pass transforms loops to operate on vector 7334 types instead of scalar types. Data parallelism across loop 7335 iterations is exploited to group data elements from consecutive 7336 iterations into a vector and operate on them in parallel. 7337 Depending on available target support the loop is conceptually 7338 unrolled by a factor 'VF' (vectorization factor), which is the 7339 number of elements operated upon in parallel in each iteration, and 7340 the 'VF' copies of each scalar operation are fused to form a vector 7341 operation. Additional loop transformations such as peeling and 7342 versioning may take place to align the number of iterations, and to 7343 align the memory accesses in the loop. The pass is implemented in 7344 'tree-vectorizer.c' (the main driver), 'tree-vect-loop.c' and 7345 'tree-vect-loop-manip.c' (loop specific parts and general loop 7346 utilities), 'tree-vect-slp' (loop-aware SLP functionality), 7347 'tree-vect-stmts.c' and 'tree-vect-data-refs.c'. Analysis of data 7348 references is in 'tree-data-ref.c'. 7349 7350 SLP Vectorization. This pass performs vectorization of 7351 straight-line code. The pass is implemented in 'tree-vectorizer.c' 7352 (the main driver), 'tree-vect-slp.c', 'tree-vect-stmts.c' and 7353 'tree-vect-data-refs.c'. 7354 7355 Autoparallelization. This pass splits the loop iteration space to 7356 run into several threads. The pass is implemented in 7357 'tree-parloops.c'. 7358 7359 Graphite is a loop transformation framework based on the polyhedral 7360 model. Graphite stands for Gimple Represented as Polyhedra. The 7361 internals of this infrastructure are documented in 7362 <http://gcc.gnu.org/wiki/Graphite>. The passes working on this 7363 representation are implemented in the various 'graphite-*' files. 7364 7365 * Tree level if-conversion for vectorizer 7366 7367 This pass applies if-conversion to simple loops to help vectorizer. 7368 We identify if convertible loops, if-convert statements and merge 7369 basic blocks in one big block. The idea is to present loop in such 7370 form so that vectorizer can have one to one mapping between 7371 statements and available vector operations. This pass is located 7372 in 'tree-if-conv.c' and is described by 'pass_if_conversion'. 7373 7374 * Conditional constant propagation 7375 7376 This pass relaxes a lattice of values in order to identify those 7377 that must be constant even in the presence of conditional branches. 7378 The pass is located in 'tree-ssa-ccp.c' and is described by 7379 'pass_ccp'. 7380 7381 A related pass that works on memory loads and stores, and not just 7382 register values, is located in 'tree-ssa-ccp.c' and described by 7383 'pass_store_ccp'. 7384 7385 * Conditional copy propagation 7386 7387 This is similar to constant propagation but the lattice of values 7388 is the "copy-of" relation. It eliminates redundant copies from the 7389 code. The pass is located in 'tree-ssa-copy.c' and described by 7390 'pass_copy_prop'. 7391 7392 A related pass that works on memory copies, and not just register 7393 copies, is located in 'tree-ssa-copy.c' and described by 7394 'pass_store_copy_prop'. 7395 7396 * Value range propagation 7397 7398 This transformation is similar to constant propagation but instead 7399 of propagating single constant values, it propagates known value 7400 ranges. The implementation is based on Patterson's range 7401 propagation algorithm (Accurate Static Branch Prediction by Value 7402 Range Propagation, J. R. C. Patterson, PLDI '95). In contrast to 7403 Patterson's algorithm, this implementation does not propagate 7404 branch probabilities nor it uses more than a single range per SSA 7405 name. This means that the current implementation cannot be used 7406 for branch prediction (though adapting it would not be difficult). 7407 The pass is located in 'tree-vrp.c' and is described by 'pass_vrp'. 7408 7409 * Folding built-in functions 7410 7411 This pass simplifies built-in functions, as applicable, with 7412 constant arguments or with inferable string lengths. It is located 7413 in 'tree-ssa-ccp.c' and is described by 'pass_fold_builtins'. 7414 7415 * Split critical edges 7416 7417 This pass identifies critical edges and inserts empty basic blocks 7418 such that the edge is no longer critical. The pass is located in 7419 'tree-cfg.c' and is described by 'pass_split_crit_edges'. 7420 7421 * Control dependence dead code elimination 7422 7423 This pass is a stronger form of dead code elimination that can 7424 eliminate unnecessary control flow statements. It is located in 7425 'tree-ssa-dce.c' and is described by 'pass_cd_dce'. 7426 7427 * Tail call elimination 7428 7429 This pass identifies function calls that may be rewritten into 7430 jumps. No code transformation is actually applied here, but the 7431 data and control flow problem is solved. The code transformation 7432 requires target support, and so is delayed until RTL. In the 7433 meantime 'CALL_EXPR_TAILCALL' is set indicating the possibility. 7434 The pass is located in 'tree-tailcall.c' and is described by 7435 'pass_tail_calls'. The RTL transformation is handled by 7436 'fixup_tail_calls' in 'calls.c'. 7437 7438 * Warn for function return without value 7439 7440 For non-void functions, this pass locates return statements that do 7441 not specify a value and issues a warning. Such a statement may 7442 have been injected by falling off the end of the function. This 7443 pass is run last so that we have as much time as possible to prove 7444 that the statement is not reachable. It is located in 'tree-cfg.c' 7445 and is described by 'pass_warn_function_return'. 7446 7447 * Leave static single assignment form 7448 7449 This pass rewrites the function such that it is in normal form. At 7450 the same time, we eliminate as many single-use temporaries as 7451 possible, so the intermediate language is no longer GIMPLE, but 7452 GENERIC. The pass is located in 'tree-outof-ssa.c' and is 7453 described by 'pass_del_ssa'. 7454 7455 * Merge PHI nodes that feed into one another 7456 7457 This is part of the CFG cleanup passes. It attempts to join PHI 7458 nodes from a forwarder CFG block into another block with PHI nodes. 7459 The pass is located in 'tree-cfgcleanup.c' and is described by 7460 'pass_merge_phi'. 7461 7462 * Return value optimization 7463 7464 If a function always returns the same local variable, and that 7465 local variable is an aggregate type, then the variable is replaced 7466 with the return value for the function (i.e., the function's 7467 DECL_RESULT). This is equivalent to the C++ named return value 7468 optimization applied to GIMPLE. The pass is located in 7469 'tree-nrv.c' and is described by 'pass_nrv'. 7470 7471 * Return slot optimization 7472 7473 If a function returns a memory object and is called as 'var = 7474 foo()', this pass tries to change the call so that the address of 7475 'var' is sent to the caller to avoid an extra memory copy. This 7476 pass is located in 'tree-nrv.c' and is described by 7477 'pass_return_slot'. 7478 7479 * Optimize calls to '__builtin_object_size' 7480 7481 This is a propagation pass similar to CCP that tries to remove 7482 calls to '__builtin_object_size' when the size of the object can be 7483 computed at compile-time. This pass is located in 7484 'tree-object-size.c' and is described by 'pass_object_sizes'. 7485 7486 * Loop invariant motion 7487 7488 This pass removes expensive loop-invariant computations out of 7489 loops. The pass is located in 'tree-ssa-loop.c' and described by 7490 'pass_lim'. 7491 7492 * Loop nest optimizations 7493 7494 This is a family of loop transformations that works on loop nests. 7495 It includes loop interchange, scaling, skewing and reversal and 7496 they are all geared to the optimization of data locality in array 7497 traversals and the removal of dependencies that hamper 7498 optimizations such as loop parallelization and vectorization. The 7499 pass is located in 'tree-loop-linear.c' and described by 7500 'pass_linear_transform'. 7501 7502 * Removal of empty loops 7503 7504 This pass removes loops with no code in them. The pass is located 7505 in 'tree-ssa-loop-ivcanon.c' and described by 'pass_empty_loop'. 7506 7507 * Unrolling of small loops 7508 7509 This pass completely unrolls loops with few iterations. The pass 7510 is located in 'tree-ssa-loop-ivcanon.c' and described by 7511 'pass_complete_unroll'. 7512 7513 * Predictive commoning 7514 7515 This pass makes the code reuse the computations from the previous 7516 iterations of the loops, especially loads and stores to memory. It 7517 does so by storing the values of these computations to a bank of 7518 temporary variables that are rotated at the end of loop. To avoid 7519 the need for this rotation, the loop is then unrolled and the 7520 copies of the loop body are rewritten to use the appropriate 7521 version of the temporary variable. This pass is located in 7522 'tree-predcom.c' and described by 'pass_predcom'. 7523 7524 * Array prefetching 7525 7526 This pass issues prefetch instructions for array references inside 7527 loops. The pass is located in 'tree-ssa-loop-prefetch.c' and 7528 described by 'pass_loop_prefetch'. 7529 7530 * Reassociation 7531 7532 This pass rewrites arithmetic expressions to enable optimizations 7533 that operate on them, like redundancy elimination and 7534 vectorization. The pass is located in 'tree-ssa-reassoc.c' and 7535 described by 'pass_reassoc'. 7536 7537 * Optimization of 'stdarg' functions 7538 7539 This pass tries to avoid the saving of register arguments into the 7540 stack on entry to 'stdarg' functions. If the function doesn't use 7541 any 'va_start' macros, no registers need to be saved. If 7542 'va_start' macros are used, the 'va_list' variables don't escape 7543 the function, it is only necessary to save registers that will be 7544 used in 'va_arg' macros. For instance, if 'va_arg' is only used 7545 with integral types in the function, floating point registers don't 7546 need to be saved. This pass is located in 'tree-stdarg.c' and 7547 described by 'pass_stdarg'. 7548 7549 7550File: gccint.info, Node: RTL passes, Next: Optimization info, Prev: Tree SSA passes, Up: Passes 7551 75529.5 RTL passes 7553============== 7554 7555The following briefly describes the RTL generation and optimization 7556passes that are run after the Tree optimization passes. 7557 7558 * RTL generation 7559 7560 The source files for RTL generation include 'stmt.c', 'calls.c', 7561 'expr.c', 'explow.c', 'expmed.c', 'function.c', 'optabs.c' and 7562 'emit-rtl.c'. Also, the file 'insn-emit.c', generated from the 7563 machine description by the program 'genemit', is used in this pass. 7564 The header file 'expr.h' is used for communication within this 7565 pass. 7566 7567 The header files 'insn-flags.h' and 'insn-codes.h', generated from 7568 the machine description by the programs 'genflags' and 'gencodes', 7569 tell this pass which standard names are available for use and which 7570 patterns correspond to them. 7571 7572 * Generation of exception landing pads 7573 7574 This pass generates the glue that handles communication between the 7575 exception handling library routines and the exception handlers 7576 within the function. Entry points in the function that are invoked 7577 by the exception handling library are called "landing pads". The 7578 code for this pass is located in 'except.c'. 7579 7580 * Control flow graph cleanup 7581 7582 This pass removes unreachable code, simplifies jumps to next, jumps 7583 to jump, jumps across jumps, etc. The pass is run multiple times. 7584 For historical reasons, it is occasionally referred to as the "jump 7585 optimization pass". The bulk of the code for this pass is in 7586 'cfgcleanup.c', and there are support routines in 'cfgrtl.c' and 7587 'jump.c'. 7588 7589 * Forward propagation of single-def values 7590 7591 This pass attempts to remove redundant computation by substituting 7592 variables that come from a single definition, and seeing if the 7593 result can be simplified. It performs copy propagation and 7594 addressing mode selection. The pass is run twice, with values 7595 being propagated into loops only on the second run. The code is 7596 located in 'fwprop.c'. 7597 7598 * Common subexpression elimination 7599 7600 This pass removes redundant computation within basic blocks, and 7601 optimizes addressing modes based on cost. The pass is run twice. 7602 The code for this pass is located in 'cse.c'. 7603 7604 * Global common subexpression elimination 7605 7606 This pass performs two different types of GCSE depending on whether 7607 you are optimizing for size or not (LCM based GCSE tends to 7608 increase code size for a gain in speed, while Morel-Renvoise based 7609 GCSE does not). When optimizing for size, GCSE is done using 7610 Morel-Renvoise Partial Redundancy Elimination, with the exception 7611 that it does not try to move invariants out of loops--that is left 7612 to the loop optimization pass. If MR PRE GCSE is done, code 7613 hoisting (aka unification) is also done, as well as load motion. 7614 If you are optimizing for speed, LCM (lazy code motion) based GCSE 7615 is done. LCM is based on the work of Knoop, Ruthing, and Steffen. 7616 LCM based GCSE also does loop invariant code motion. We also 7617 perform load and store motion when optimizing for speed. 7618 Regardless of which type of GCSE is used, the GCSE pass also 7619 performs global constant and copy propagation. The source file for 7620 this pass is 'gcse.c', and the LCM routines are in 'lcm.c'. 7621 7622 * Loop optimization 7623 7624 This pass performs several loop related optimizations. The source 7625 files 'cfgloopanal.c' and 'cfgloopmanip.c' contain generic loop 7626 analysis and manipulation code. Initialization and finalization of 7627 loop structures is handled by 'loop-init.c'. A loop invariant 7628 motion pass is implemented in 'loop-invariant.c'. Basic block 7629 level optimizations--unrolling, and peeling loops-- are implemented 7630 in 'loop-unroll.c'. Replacing of the exit condition of loops by 7631 special machine-dependent instructions is handled by 7632 'loop-doloop.c'. 7633 7634 * Jump bypassing 7635 7636 This pass is an aggressive form of GCSE that transforms the control 7637 flow graph of a function by propagating constants into conditional 7638 branch instructions. The source file for this pass is 'gcse.c'. 7639 7640 * If conversion 7641 7642 This pass attempts to replace conditional branches and surrounding 7643 assignments with arithmetic, boolean value producing comparison 7644 instructions, and conditional move instructions. In the very last 7645 invocation after reload/LRA, it will generate predicated 7646 instructions when supported by the target. The code is located in 7647 'ifcvt.c'. 7648 7649 * Web construction 7650 7651 This pass splits independent uses of each pseudo-register. This 7652 can improve effect of the other transformation, such as CSE or 7653 register allocation. The code for this pass is located in 'web.c'. 7654 7655 * Instruction combination 7656 7657 This pass attempts to combine groups of two or three instructions 7658 that are related by data flow into single instructions. It 7659 combines the RTL expressions for the instructions by substitution, 7660 simplifies the result using algebra, and then attempts to match the 7661 result against the machine description. The code is located in 7662 'combine.c'. 7663 7664 * Mode switching optimization 7665 7666 This pass looks for instructions that require the processor to be 7667 in a specific "mode" and minimizes the number of mode changes 7668 required to satisfy all users. What these modes are, and what they 7669 apply to are completely target-specific. The code for this pass is 7670 located in 'mode-switching.c'. 7671 7672 * Modulo scheduling 7673 7674 This pass looks at innermost loops and reorders their instructions 7675 by overlapping different iterations. Modulo scheduling is 7676 performed immediately before instruction scheduling. The code for 7677 this pass is located in 'modulo-sched.c'. 7678 7679 * Instruction scheduling 7680 7681 This pass looks for instructions whose output will not be available 7682 by the time that it is used in subsequent instructions. Memory 7683 loads and floating point instructions often have this behavior on 7684 RISC machines. It re-orders instructions within a basic block to 7685 try to separate the definition and use of items that otherwise 7686 would cause pipeline stalls. This pass is performed twice, before 7687 and after register allocation. The code for this pass is located 7688 in 'haifa-sched.c', 'sched-deps.c', 'sched-ebb.c', 'sched-rgn.c' 7689 and 'sched-vis.c'. 7690 7691 * Register allocation 7692 7693 These passes make sure that all occurrences of pseudo registers are 7694 eliminated, either by allocating them to a hard register, replacing 7695 them by an equivalent expression (e.g. a constant) or by placing 7696 them on the stack. This is done in several subpasses: 7697 7698 * The integrated register allocator (IRA). It is called 7699 integrated because coalescing, register live range splitting, 7700 and hard register preferencing are done on-the-fly during 7701 coloring. It also has better integration with the reload/LRA 7702 pass. Pseudo-registers spilled by the allocator or the 7703 reload/LRA have still a chance to get hard-registers if the 7704 reload/LRA evicts some pseudo-registers from hard-registers. 7705 The allocator helps to choose better pseudos for spilling 7706 based on their live ranges and to coalesce stack slots 7707 allocated for the spilled pseudo-registers. IRA is a regional 7708 register allocator which is transformed into Chaitin-Briggs 7709 allocator if there is one region. By default, IRA chooses 7710 regions using register pressure but the user can force it to 7711 use one region or regions corresponding to all loops. 7712 7713 Source files of the allocator are 'ira.c', 'ira-build.c', 7714 'ira-costs.c', 'ira-conflicts.c', 'ira-color.c', 'ira-emit.c', 7715 'ira-lives', plus header files 'ira.h' and 'ira-int.h' used 7716 for the communication between the allocator and the rest of 7717 the compiler and between the IRA files. 7718 7719 * Reloading. This pass renumbers pseudo registers with the 7720 hardware registers numbers they were allocated. Pseudo 7721 registers that did not get hard registers are replaced with 7722 stack slots. Then it finds instructions that are invalid 7723 because a value has failed to end up in a register, or has 7724 ended up in a register of the wrong kind. It fixes up these 7725 instructions by reloading the problematical values temporarily 7726 into registers. Additional instructions are generated to do 7727 the copying. 7728 7729 The reload pass also optionally eliminates the frame pointer 7730 and inserts instructions to save and restore call-clobbered 7731 registers around calls. 7732 7733 Source files are 'reload.c' and 'reload1.c', plus the header 7734 'reload.h' used for communication between them. 7735 7736 * This pass is a modern replacement of the reload pass. Source 7737 files are 'lra.c', 'lra-assign.c', 'lra-coalesce.c', 7738 'lra-constraints.c', 'lra-eliminations.c', 'lra-lives.c', 7739 'lra-remat.c', 'lra-spills.c', the header 'lra-int.h' used for 7740 communication between them, and the header 'lra.h' used for 7741 communication between LRA and the rest of compiler. 7742 7743 Unlike the reload pass, intermediate LRA decisions are 7744 reflected in RTL as much as possible. This reduces the number 7745 of target-dependent macros and hooks, leaving instruction 7746 constraints as the primary source of control. 7747 7748 LRA is run on targets for which TARGET_LRA_P returns true. 7749 7750 * Basic block reordering 7751 7752 This pass implements profile guided code positioning. If profile 7753 information is not available, various types of static analysis are 7754 performed to make the predictions normally coming from the profile 7755 feedback (IE execution frequency, branch probability, etc). It is 7756 implemented in the file 'bb-reorder.c', and the various prediction 7757 routines are in 'predict.c'. 7758 7759 * Variable tracking 7760 7761 This pass computes where the variables are stored at each position 7762 in code and generates notes describing the variable locations to 7763 RTL code. The location lists are then generated according to these 7764 notes to debug information if the debugging information format 7765 supports location lists. The code is located in 'var-tracking.c'. 7766 7767 * Delayed branch scheduling 7768 7769 This optional pass attempts to find instructions that can go into 7770 the delay slots of other instructions, usually jumps and calls. 7771 The code for this pass is located in 'reorg.c'. 7772 7773 * Branch shortening 7774 7775 On many RISC machines, branch instructions have a limited range. 7776 Thus, longer sequences of instructions must be used for long 7777 branches. In this pass, the compiler figures out what how far each 7778 instruction will be from each other instruction, and therefore 7779 whether the usual instructions, or the longer sequences, must be 7780 used for each branch. The code for this pass is located in 7781 'final.c'. 7782 7783 * Register-to-stack conversion 7784 7785 Conversion from usage of some hard registers to usage of a register 7786 stack may be done at this point. Currently, this is supported only 7787 for the floating-point registers of the Intel 80387 coprocessor. 7788 The code for this pass is located in 'reg-stack.c'. 7789 7790 * Final 7791 7792 This pass outputs the assembler code for the function. The source 7793 files are 'final.c' plus 'insn-output.c'; the latter is generated 7794 automatically from the machine description by the tool 'genoutput'. 7795 The header file 'conditions.h' is used for communication between 7796 these files. 7797 7798 * Debugging information output 7799 7800 This is run after final because it must output the stack slot 7801 offsets for pseudo registers that did not get hard registers. 7802 Source files are 'dbxout.c' for DBX symbol table format, 7803 'dwarfout.c' for DWARF symbol table format, files 'dwarf2out.c' and 7804 'dwarf2asm.c' for DWARF2 symbol table format, and 'vmsdbgout.c' for 7805 VMS debug symbol table format. 7806 7807 7808File: gccint.info, Node: Optimization info, Prev: RTL passes, Up: Passes 7809 78109.6 Optimization info 7811===================== 7812 7813This section is describes dump infrastructure which is common to both 7814pass dumps as well as optimization dumps. The goal for this 7815infrastructure is to provide both gcc developers and users detailed 7816information about various compiler transformations and optimizations. 7817 7818* Menu: 7819 7820* Dump setup:: Setup of optimization dumps. 7821* Optimization groups:: Groups made up of optimization passes. 7822* Dump files and streams:: Dump output file names and streams. 7823* Dump output verbosity:: How much information to dump. 7824* Dump types:: Various types of dump functions. 7825* Dump examples:: Sample usage. 7826 7827 7828File: gccint.info, Node: Dump setup, Next: Optimization groups, Up: Optimization info 7829 78309.6.1 Dump setup 7831---------------- 7832 7833A dump_manager class is defined in 'dumpfile.h'. Various passes 7834register dumping pass-specific information via 'dump_register' in 7835'passes.c'. During the registration, an optimization pass can select 7836its optimization group (*note Optimization groups::). After that 7837optimization information corresponding to the entire group (presumably 7838from multiple passes) can be output via command-line switches. Note 7839that if a pass does not fit into any of the pre-defined groups, it can 7840select 'OPTGROUP_NONE'. 7841 7842 Note that in general, a pass need not know its dump output file name, 7843whether certain flags are enabled, etc. However, for legacy reasons, 7844passes could also call 'dump_begin' which returns a stream in case the 7845particular pass has optimization dumps enabled. A pass could call 7846'dump_end' when the dump has ended. These methods should go away once 7847all the passes are converted to use the new dump infrastructure. 7848 7849 The recommended way to setup the dump output is via 'dump_start' and 7850'dump_end'. 7851 7852 7853File: gccint.info, Node: Optimization groups, Next: Dump files and streams, Prev: Dump setup, Up: Optimization info 7854 78559.6.2 Optimization groups 7856------------------------- 7857 7858The optimization passes are grouped into several categories. Currently 7859defined categories in 'dumpfile.h' are 7860 7861'OPTGROUP_IPA' 7862 IPA optimization passes. Enabled by '-ipa' 7863 7864'OPTGROUP_LOOP' 7865 Loop optimization passes. Enabled by '-loop'. 7866 7867'OPTGROUP_INLINE' 7868 Inlining passes. Enabled by '-inline'. 7869 7870'OPTGROUP_OMP' 7871 OMP (Offloading and Multi Processing) passes. Enabled by '-omp'. 7872 7873'OPTGROUP_VEC' 7874 Vectorization passes. Enabled by '-vec'. 7875 7876'OPTGROUP_OTHER' 7877 All other optimization passes which do not fall into one of the 7878 above. 7879 7880'OPTGROUP_ALL' 7881 All optimization passes. Enabled by '-optall'. 7882 7883 By using groups a user could selectively enable optimization 7884information only for a group of passes. By default, the optimization 7885information for all the passes is dumped. 7886 7887 7888File: gccint.info, Node: Dump files and streams, Next: Dump output verbosity, Prev: Optimization groups, Up: Optimization info 7889 78909.6.3 Dump files and streams 7891---------------------------- 7892 7893There are two separate output streams available for outputting 7894optimization information from passes. Note that both these streams 7895accept 'stderr' and 'stdout' as valid streams and thus it is possible to 7896dump output to standard output or error. This is specially handy for 7897outputting all available information in a single file by redirecting 7898'stderr'. 7899 7900'pstream' 7901 This stream is for pass-specific dump output. For example, 7902 '-fdump-tree-vect=foo.v' dumps tree vectorization pass output into 7903 the given file name 'foo.v'. If the file name is not provided, the 7904 default file name is based on the source file and pass number. 7905 Note that one could also use special file names 'stdout' and 7906 'stderr' for dumping to standard output and standard error 7907 respectively. 7908 7909'alt_stream' 7910 This steam is used for printing optimization specific output in 7911 response to the '-fopt-info'. Again a file name can be given. If 7912 the file name is not given, it defaults to 'stderr'. 7913 7914 7915File: gccint.info, Node: Dump output verbosity, Next: Dump types, Prev: Dump files and streams, Up: Optimization info 7916 79179.6.4 Dump output verbosity 7918--------------------------- 7919 7920The dump verbosity has the following options 7921 7922'optimized' 7923 Print information when an optimization is successfully applied. It 7924 is up to a pass to decide which information is relevant. For 7925 example, the vectorizer passes print the source location of loops 7926 which got successfully vectorized. 7927 7928'missed' 7929 Print information about missed optimizations. Individual passes 7930 control which information to include in the output. For example, 7931 7932 gcc -O2 -ftree-vectorize -fopt-info-vec-missed 7933 7934 will print information about missed optimization opportunities from 7935 vectorization passes on stderr. 7936 7937'note' 7938 Print verbose information about optimizations, such as certain 7939 transformations, more detailed messages about decisions etc. 7940 7941'all' 7942 Print detailed optimization information. This includes OPTIMIZED, 7943 MISSED, and NOTE. 7944 7945 7946File: gccint.info, Node: Dump types, Next: Dump examples, Prev: Dump output verbosity, Up: Optimization info 7947 79489.6.5 Dump types 7949---------------- 7950 7951'dump_printf' 7952 7953 This is a generic method for doing formatted output. It takes an 7954 additional argument 'dump_kind' which signifies the type of dump. 7955 This method outputs information only when the dumps are enabled for 7956 this particular 'dump_kind'. Note that the caller doesn't need to 7957 know if the particular dump is enabled or not, or even the file 7958 name. The caller only needs to decide which dump output 7959 information is relevant, and under what conditions. This 7960 determines the associated flags. 7961 7962 Consider the following example from 'loop-unroll.c' where an 7963 informative message about a loop (along with its location) is 7964 printed when any of the following flags is enabled 7965 7966 - optimization messages 7967 - RTL dumps 7968 - detailed dumps 7969 7970 int report_flags = MSG_OPTIMIZED_LOCATIONS | TDF_RTL | TDF_DETAILS; 7971 dump_printf_loc (report_flags, locus, 7972 "loop turned into non-loop; it never loops.\n"); 7973 7974'dump_basic_block' 7975 Output basic block. 7976'dump_generic_expr' 7977 Output generic expression. 7978'dump_gimple_stmt' 7979 Output gimple statement. 7980 7981 Note that the above methods also have variants prefixed with 7982 '_loc', such as 'dump_printf_loc', which are similar except they 7983 also output the source location information. 7984 7985 7986File: gccint.info, Node: Dump examples, Prev: Dump types, Up: Optimization info 7987 79889.6.6 Dump examples 7989------------------- 7990 7991 gcc -O3 -fopt-info-missed=missed.all 7992 7993 outputs missed optimization report from all the passes into 7994'missed.all'. 7995 7996 As another example, 7997 gcc -O3 -fopt-info-inline-optimized-missed=inline.txt 7998 7999 will output information about missed optimizations as well as optimized 8000locations from all the inlining passes into 'inline.txt'. 8001 8002 If the FILENAME is provided, then the dumps from all the applicable 8003optimizations are concatenated into the 'filename'. Otherwise the dump 8004is output onto 'stderr'. If OPTIONS is omitted, it defaults to 8005'optimized-optall', which means dump all information about successful 8006optimizations from all the passes. In the following example, the 8007optimization information is output on to 'stderr'. 8008 8009 gcc -O3 -fopt-info 8010 8011 Note that '-fopt-info-vec-missed' behaves the same as 8012'-fopt-info-missed-vec'. The order of the optimization group names and 8013message types listed after '-fopt-info' does not matter. 8014 8015 As another example, consider 8016 8017 gcc -fopt-info-vec-missed=vec.miss -fopt-info-loop-optimized=loop.opt 8018 8019 Here the two output file names 'vec.miss' and 'loop.opt' are in 8020conflict since only one output file is allowed. In this case, only the 8021first option takes effect and the subsequent options are ignored. Thus 8022only the 'vec.miss' is produced which containts dumps from the 8023vectorizer about missed opportunities. 8024 8025 8026File: gccint.info, Node: poly_int, Next: GENERIC, Prev: Passes, Up: Top 8027 802810 Sizes and offsets as runtime invariants 8029****************************************** 8030 8031GCC allows the size of a hardware register to be a runtime invariant 8032rather than a compile-time constant. This in turn means that various 8033sizes and offsets must also be runtime invariants rather than 8034compile-time constants, such as: 8035 8036 * the size of a general 'machine_mode' (*note Machine Modes::); 8037 8038 * the size of a spill slot; 8039 8040 * the offset of something within a stack frame; 8041 8042 * the number of elements in a vector; 8043 8044 * the size and offset of a 'mem' rtx (*note Regs and Memory::); and 8045 8046 * the byte offset in a 'subreg' rtx (*note Regs and Memory::). 8047 8048 The motivating example is the Arm SVE ISA, whose vector registers can 8049be any multiple of 128 bits between 128 and 2048 inclusive. The 8050compiler normally produces code that works for all SVE register sizes, 8051with the actual size only being known at runtime. 8052 8053 GCC's main representation of such runtime invariants is the 'poly_int' 8054class. This chapter describes what 'poly_int' does, lists the available 8055operations, and gives some general usage guidelines. 8056 8057* Menu: 8058 8059* Overview of poly_int:: 8060* Consequences of using poly_int:: 8061* Comparisons involving poly_int:: 8062* Arithmetic on poly_ints:: 8063* Alignment of poly_ints:: 8064* Computing bounds on poly_ints:: 8065* Converting poly_ints:: 8066* Miscellaneous poly_int routines:: 8067* Guidelines for using poly_int:: 8068 8069 8070File: gccint.info, Node: Overview of poly_int, Next: Consequences of using poly_int, Up: poly_int 8071 807210.1 Overview of 'poly_int' 8073=========================== 8074 8075We define indeterminates X1, ..., XN whose values are only known at 8076runtime and use polynomials of the form: 8077 8078 C0 + C1 * X1 + ... + CN * XN 8079 8080 to represent a size or offset whose value might depend on some of these 8081indeterminates. The coefficients C0, ..., CN are always known at 8082compile time, with the C0 term being the "constant" part that does not 8083depend on any runtime value. 8084 8085 GCC uses the 'poly_int' class to represent these coefficients. The 8086class has two template parameters: the first specifies the number of 8087coefficients (N + 1) and the second specifies the type of the 8088coefficients. For example, 'poly_int<2, unsigned short>' represents a 8089polynomial with two coefficients (and thus one indeterminate), with each 8090coefficient having type 'unsigned short'. When N is 0, the class 8091degenerates to a single compile-time constant C0. 8092 8093 The number of coefficients needed for compilation is a fixed property 8094of each target and is specified by the configuration macro 8095'NUM_POLY_INT_COEFFS'. The default value is 1, since most targets do 8096not have such runtime invariants. Targets that need a different value 8097should '#define' the macro in their 'CPU-modes.def' file. *Note Back 8098End::. 8099 8100 'poly_int' makes the simplifying requirement that each indeterminate 8101must be a nonnegative integer. An indeterminate value of 0 should 8102usually represent the minimum possible runtime value, with C0 specifying 8103the value in that case. 8104 8105 For example, when targetting the Arm SVE ISA, the single indeterminate 8106represents the number of 128-bit blocks in a vector _beyond the minimum 8107length of 128 bits_. Thus the number of 64-bit doublewords in a vector 8108is 2 + 2 * X1. If an aggregate has a single SVE vector and 16 8109additional bytes, its total size is 32 + 16 * X1 bytes. 8110 8111 The header file 'poly-int-types.h' provides typedefs for the most 8112common forms of 'poly_int', all having 'NUM_POLY_INT_COEFFS' 8113coefficients: 8114 8115'poly_uint16' 8116 a 'poly_int' with 'unsigned short' coefficients. 8117 8118'poly_int64' 8119 a 'poly_int' with 'HOST_WIDE_INT' coefficients. 8120 8121'poly_uint64' 8122 a 'poly_int' with 'unsigned HOST_WIDE_INT' coefficients. 8123 8124'poly_offset_int' 8125 a 'poly_int' with 'offset_int' coefficients. 8126 8127'poly_wide_int' 8128 a 'poly_int' with 'wide_int' coefficients. 8129 8130'poly_widest_int' 8131 a 'poly_int' with 'widest_int' coefficients. 8132 8133 Since the main purpose of 'poly_int' is to represent sizes and offsets, 8134the last two typedefs are only rarely used. 8135 8136 8137File: gccint.info, Node: Consequences of using poly_int, Next: Comparisons involving poly_int, Prev: Overview of poly_int, Up: poly_int 8138 813910.2 Consequences of using 'poly_int' 8140===================================== 8141 8142The two main consequences of using polynomial sizes and offsets are 8143that: 8144 8145 * there is no total ordering between the values at compile time, and 8146 8147 * some operations might yield results that cannot be expressed as a 8148 'poly_int'. 8149 8150 For example, if X is a runtime invariant, we cannot tell at compile 8151time whether: 8152 8153 3 + 4X <= 1 + 5X 8154 8155 since the condition is false when X <= 1 and true when X >= 2. 8156 8157 Similarly, 'poly_int' cannot represent the result of: 8158 8159 (3 + 4X) * (1 + 5X) 8160 8161 since it cannot (and in practice does not need to) store powers greater 8162than one. It also cannot represent the result of: 8163 8164 (3 + 4X) / (1 + 5X) 8165 8166 The following sections describe how we deal with these restrictions. 8167 8168 As described earlier, a 'poly_int<1, T>' has no indeterminates and so 8169degenerates to a compile-time constant of type T. It would be possible 8170in that case to do all normal arithmetic on the T, and to compare the T 8171using the normal C++ operators. We deliberately prevent 8172target-independent code from doing this, since the compiler needs to 8173support other 'poly_int<N, T>' as well, regardless of the current 8174target's 'NUM_POLY_INT_COEFFS'. 8175 8176 However, it would be very artificial to force target-specific code to 8177follow these restrictions if the target has no runtime indeterminates. 8178There is therefore an implicit conversion from 'poly_int<1, T>' to T 8179when compiling target-specific translation units. 8180 8181 8182File: gccint.info, Node: Comparisons involving poly_int, Next: Arithmetic on poly_ints, Prev: Consequences of using poly_int, Up: poly_int 8183 818410.3 Comparisons involving 'poly_int' 8185===================================== 8186 8187In general we need to compare sizes and offsets in two situations: those 8188in which the values need to be ordered, and those in which the values 8189can be unordered. More loosely, the distinction is often between values 8190that have a definite link (usually because they refer to the same 8191underlying register or memory location) and values that have no definite 8192link. An example of the former is the relationship between the inner 8193and outer sizes of a subreg, where we must know at compile time whether 8194the subreg is paradoxical, partial, or complete. An example of the 8195latter is alias analysis: we might want to check whether two arbitrary 8196memory references overlap. 8197 8198 Referring back to the examples in the previous section, it makes sense 8199to ask whether a memory reference of size '3 + 4X' overlaps one of size 8200'1 + 5X', but it does not make sense to have a subreg in which the outer 8201mode has '3 + 4X' bytes and the inner mode has '1 + 5X' bytes (or vice 8202versa). Such subregs are always invalid and should trigger an internal 8203compiler error if formed. 8204 8205 The underlying operators are the same in both cases, but the 8206distinction affects how they are used. 8207 8208* Menu: 8209 8210* Comparison functions for poly_int:: 8211* Properties of the poly_int comparisons:: 8212* Comparing potentially-unordered poly_ints:: 8213* Comparing ordered poly_ints:: 8214* Checking for a poly_int marker value:: 8215* Range checks on poly_ints:: 8216* Sorting poly_ints:: 8217 8218 8219File: gccint.info, Node: Comparison functions for poly_int, Next: Properties of the poly_int comparisons, Up: Comparisons involving poly_int 8220 822110.3.1 Comparison functions for 'poly_int' 8222------------------------------------------ 8223 8224'poly_int' provides the following routines for checking whether a 8225particular condition "may be" (might be) true: 8226 8227 maybe_lt maybe_le maybe_eq maybe_ge maybe_gt 8228 maybe_ne 8229 8230 The functions have their natural meaning: 8231 8232'maybe_lt(A, B)' 8233 Return true if A might be less than B. 8234 8235'maybe_le(A, B)' 8236 Return true if A might be less than or equal to B. 8237 8238'maybe_eq(A, B)' 8239 Return true if A might be equal to B. 8240 8241'maybe_ne(A, B)' 8242 Return true if A might not be equal to B. 8243 8244'maybe_ge(A, B)' 8245 Return true if A might be greater than or equal to B. 8246 8247'maybe_gt(A, B)' 8248 Return true if A might be greater than B. 8249 8250 For readability, 'poly_int' also provides "known" inverses of these 8251functions: 8252 8253 known_lt (A, B) == !maybe_ge (A, B) 8254 known_le (A, B) == !maybe_gt (A, B) 8255 known_eq (A, B) == !maybe_ne (A, B) 8256 known_ge (A, B) == !maybe_lt (A, B) 8257 known_gt (A, B) == !maybe_le (A, B) 8258 known_ne (A, B) == !maybe_eq (A, B) 8259 8260 8261File: 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 8262 826310.3.2 Properties of the 'poly_int' comparisons 8264----------------------------------------------- 8265 8266All "maybe" relations except 'maybe_ne' are transitive, so for example: 8267 8268 maybe_lt (A, B) && maybe_lt (B, C) implies maybe_lt (A, C) 8269 8270 for all A, B and C. 'maybe_lt', 'maybe_gt' and 'maybe_ne' are 8271irreflexive, so for example: 8272 8273 !maybe_lt (A, A) 8274 8275 is true for all A. 'maybe_le', 'maybe_eq' and 'maybe_ge' are 8276reflexive, so for example: 8277 8278 maybe_le (A, A) 8279 8280 is true for all A. 'maybe_eq' and 'maybe_ne' are symmetric, so: 8281 8282 maybe_eq (A, B) == maybe_eq (B, A) 8283 maybe_ne (A, B) == maybe_ne (B, A) 8284 8285 for all A and B. In addition: 8286 8287 maybe_le (A, B) == maybe_lt (A, B) || maybe_eq (A, B) 8288 maybe_ge (A, B) == maybe_gt (A, B) || maybe_eq (A, B) 8289 maybe_lt (A, B) == maybe_gt (B, A) 8290 maybe_le (A, B) == maybe_ge (B, A) 8291 8292 However: 8293 8294 maybe_le (A, B) && maybe_le (B, A) does not imply !maybe_ne (A, B) [== known_eq (A, B)] 8295 maybe_ge (A, B) && maybe_ge (B, A) does not imply !maybe_ne (A, B) [== known_eq (A, B)] 8296 8297 One example is again 'A == 3 + 4X' and 'B == 1 + 5X', where 'maybe_le 8298(A, B)', 'maybe_ge (A, B)' and 'maybe_ne (A, B)' all hold. 'maybe_le' 8299and 'maybe_ge' are therefore not antisymetric and do not form a partial 8300order. 8301 8302 From the above, it follows that: 8303 8304 * All "known" relations except 'known_ne' are transitive. 8305 8306 * 'known_lt', 'known_ne' and 'known_gt' are irreflexive. 8307 8308 * 'known_le', 'known_eq' and 'known_ge' are reflexive. 8309 8310 Also: 8311 8312 known_lt (A, B) == known_gt (B, A) 8313 known_le (A, B) == known_ge (B, A) 8314 known_lt (A, B) implies !known_lt (B, A) [asymmetry] 8315 known_gt (A, B) implies !known_gt (B, A) 8316 known_le (A, B) && known_le (B, A) == known_eq (A, B) [== !maybe_ne (A, B)] 8317 known_ge (A, B) && known_ge (B, A) == known_eq (A, B) [== !maybe_ne (A, B)] 8318 8319 'known_le' and 'known_ge' are therefore antisymmetric and are partial 8320orders. However: 8321 8322 known_le (A, B) does not imply known_lt (A, B) || known_eq (A, B) 8323 known_ge (A, B) does not imply known_gt (A, B) || known_eq (A, B) 8324 8325 For example, 'known_le (4, 4 + 4X)' holds because the runtime 8326indeterminate X is a nonnegative integer, but neither 'known_lt (4, 4 + 83274X)' nor 'known_eq (4, 4 + 4X)' hold. 8328 8329 8330File: 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 8331 833210.3.3 Comparing potentially-unordered 'poly_int's 8333-------------------------------------------------- 8334 8335In cases where there is no definite link between two 'poly_int's, we can 8336usually make a conservatively-correct assumption. For example, the 8337conservative assumption for alias analysis is that two references 8338_might_ alias. 8339 8340 One way of checking whether [BEGIN1, END1) might overlap [BEGIN2, END2) 8341using the 'poly_int' comparisons is: 8342 8343 maybe_gt (END1, BEGIN2) && maybe_gt (END2, BEGIN1) 8344 8345 and another (equivalent) way is: 8346 8347 !(known_le (END1, BEGIN2) || known_le (END2, BEGIN1)) 8348 8349 However, in this particular example, it is better to use the range 8350helper functions instead. *Note Range checks on poly_ints::. 8351 8352 8353File: 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 8354 835510.3.4 Comparing ordered 'poly_int's 8356------------------------------------ 8357 8358In cases where there is a definite link between two 'poly_int's, such as 8359the outer and inner sizes of subregs, we usually require the sizes to be 8360ordered by the 'known_le' partial order. 'poly_int' provides the 8361following utility functions for ordered values: 8362 8363'ordered_p (A, B)' 8364 Return true if A and B are ordered by the 'known_le' partial order. 8365 8366'ordered_min (A, B)' 8367 Assert that A and B are ordered by 'known_le' and return the 8368 minimum of the two. When using this function, please add a comment 8369 explaining why the values are known to be ordered. 8370 8371'ordered_max (A, B)' 8372 Assert that A and B are ordered by 'known_le' and return the 8373 maximum of the two. When using this function, please add a comment 8374 explaining why the values are known to be ordered. 8375 8376 For example, if a subreg has an outer mode of size OUTER and an inner 8377mode of size INNER: 8378 8379 * the subreg is complete if known_eq (INNER, OUTER) 8380 8381 * otherwise, the subreg is paradoxical if known_le (INNER, OUTER) 8382 8383 * otherwise, the subreg is partial if known_le (OUTER, INNER) 8384 8385 * otherwise, the subreg is ill-formed 8386 8387 Thus the subreg is only valid if 'ordered_p (OUTER, INNER)' is true. 8388If this condition is already known to be true then: 8389 8390 * the subreg is complete if known_eq (INNER, OUTER) 8391 8392 * the subreg is paradoxical if maybe_lt (INNER, OUTER) 8393 8394 * the subreg is partial if maybe_lt (OUTER, INNER) 8395 8396 with the three conditions being mutually exclusive. 8397 8398 Code that checks whether a subreg is valid would therefore generally 8399check whether 'ordered_p' holds (in addition to whatever other checks 8400are required for subreg validity). Code that is dealing with existing 8401subregs can assert that 'ordered_p' holds and use either of the 8402classifications above. 8403 8404 8405File: 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 8406 840710.3.5 Checking for a 'poly_int' marker value 8408--------------------------------------------- 8409 8410It is sometimes useful to have a special "marker value" that is not 8411meant to be taken literally. For example, some code uses a size of -1 8412to represent an unknown size, rather than having to carry around a 8413separate boolean to say whether the size is known. 8414 8415 The best way of checking whether something is a marker value is 8416'known_eq'. Conversely the best way of checking whether something is 8417_not_ a marker value is 'maybe_ne'. 8418 8419 Thus in the size example just mentioned, 'known_eq (size, -1)' would 8420check for an unknown size and 'maybe_ne (size, -1)' would check for a 8421known size. 8422 8423 8424File: 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 8425 842610.3.6 Range checks on 'poly_int's 8427---------------------------------- 8428 8429As well as the core comparisons (*note Comparison functions for 8430poly_int::), 'poly_int' provides utilities for various kinds of range 8431check. In each case the range is represented by a start position and a 8432size rather than a start position and an end position; this is because 8433the former is used much more often than the latter in GCC. Also, the 8434sizes can be -1 (or all ones for unsigned sizes) to indicate a range 8435with a known start position but an unknown size. All other sizes must 8436be nonnegative. A range of size 0 does not contain anything or overlap 8437anything. 8438 8439'known_size_p (SIZE)' 8440 Return true if SIZE represents a known range size, false if it is 8441 -1 or all ones (for signed and unsigned types respectively). 8442 8443'ranges_maybe_overlap_p (POS1, SIZE1, POS2, SIZE2)' 8444 Return true if the range described by POS1 and SIZE1 _might_ 8445 overlap the range described by POS2 and SIZE2 (in other words, 8446 return true if we cannot prove that the ranges are disjoint). 8447 8448'ranges_known_overlap_p (POS1, SIZE1, POS2, SIZE2)' 8449 Return true if the range described by POS1 and SIZE1 is known to 8450 overlap the range described by POS2 and SIZE2. 8451 8452'known_subrange_p (POS1, SIZE1, POS2, SIZE2)' 8453 Return true if the range described by POS1 and SIZE1 is known to be 8454 contained in the range described by POS2 and SIZE2. 8455 8456'maybe_in_range_p (VALUE, POS, SIZE)' 8457 Return true if VALUE _might_ be in the range described by POS and 8458 SIZE (in other words, return true if we cannot prove that VALUE is 8459 outside that range). 8460 8461'known_in_range_p (VALUE, POS, SIZE)' 8462 Return true if VALUE is known to be in the range described by POS 8463 and SIZE. 8464 8465'endpoint_representable_p (POS, SIZE)' 8466 Return true if the range described by POS and SIZE is open-ended or 8467 if the endpoint (POS + SIZE) is representable in the same type as 8468 POS and SIZE. The function returns false if adding SIZE to POS 8469 makes conceptual sense but could overflow. 8470 8471 There is also a 'poly_int' version of the 'IN_RANGE_P' macro: 8472 8473'coeffs_in_range_p (X, LOWER, UPPER)' 8474 Return true if every coefficient of X is in the inclusive range 8475 [LOWER, UPPER]. This function can be useful when testing whether 8476 an operation would cause the values of coefficients to overflow. 8477 8478 Note that the function does not indicate whether X itself is in the 8479 given range. X can be either a constant or a 'poly_int'. 8480 8481 8482File: gccint.info, Node: Sorting poly_ints, Prev: Range checks on poly_ints, Up: Comparisons involving poly_int 8483 848410.3.7 Sorting 'poly_int's 8485-------------------------- 8486 8487'poly_int' provides the following routine for sorting: 8488 8489'compare_sizes_for_sort (A, B)' 8490 Compare A and B in reverse lexicographical order (that is, compare 8491 the highest-indexed coefficients first). This can be useful when 8492 sorting data structures, since it has the effect of separating 8493 constant and non-constant values. If all values are nonnegative, 8494 the constant values come first. 8495 8496 Note that the values do not necessarily end up in numerical order. 8497 For example, '1 + 1X' would come after '100' in the sort order, but 8498 may well be less than '100' at run time. 8499 8500 8501File: gccint.info, Node: Arithmetic on poly_ints, Next: Alignment of poly_ints, Prev: Comparisons involving poly_int, Up: poly_int 8502 850310.4 Arithmetic on 'poly_int's 8504============================== 8505 8506Addition, subtraction, negation and bit inversion all work normally for 8507'poly_int's. Multiplication by a constant multiplier and left shifting 8508by a constant shift amount also work normally. General multiplication 8509of two 'poly_int's is not supported and is not useful in practice. 8510 8511 Other operations are only conditionally supported: the operation might 8512succeed or might fail, depending on the inputs. 8513 8514 This section describes both types of operation. 8515 8516* Menu: 8517 8518* Using poly_int with C++ arithmetic operators:: 8519* wi arithmetic on poly_ints:: 8520* Division of poly_ints:: 8521* Other poly_int arithmetic:: 8522 8523 8524File: gccint.info, Node: Using poly_int with C++ arithmetic operators, Next: wi arithmetic on poly_ints, Up: Arithmetic on poly_ints 8525 852610.4.1 Using 'poly_int' with C++ arithmetic operators 8527----------------------------------------------------- 8528 8529The following C++ expressions are supported, where P1 and P2 are 8530'poly_int's and where C1 and C2 are scalars: 8531 8532 -P1 8533 ~P1 8534 8535 P1 + P2 8536 P1 + C2 8537 C1 + P2 8538 8539 P1 - P2 8540 P1 - C2 8541 C1 - P2 8542 8543 C1 * P2 8544 P1 * C2 8545 8546 P1 << C2 8547 8548 P1 += P2 8549 P1 += C2 8550 8551 P1 -= P2 8552 P1 -= C2 8553 8554 P1 *= C2 8555 P1 <<= C2 8556 8557 These arithmetic operations handle integer ranks in a similar way to 8558C++. The main difference is that every coefficient narrower than 8559'HOST_WIDE_INT' promotes to 'HOST_WIDE_INT', whereas in C++ everything 8560narrower than 'int' promotes to 'int'. For example: 8561 8562 poly_uint16 + int -> poly_int64 8563 unsigned int + poly_uint16 -> poly_int64 8564 poly_int64 + int -> poly_int64 8565 poly_int32 + poly_uint64 -> poly_uint64 8566 uint64 + poly_int64 -> poly_uint64 8567 poly_offset_int + int32 -> poly_offset_int 8568 offset_int + poly_uint16 -> poly_offset_int 8569 8570 In the first two examples, both coefficients are narrower than 8571'HOST_WIDE_INT', so the result has coefficients of type 'HOST_WIDE_INT'. 8572In the other examples, the coefficient with the highest rank "wins". 8573 8574 If one of the operands is 'wide_int' or 'poly_wide_int', the rules are 8575the same as for 'wide_int' arithmetic. 8576 8577 8578File: 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 8579 858010.4.2 'wi' arithmetic on 'poly_int's 8581------------------------------------- 8582 8583As well as the C++ operators, 'poly_int' supports the following 'wi' 8584routines: 8585 8586 wi::neg (P1, &OVERFLOW) 8587 8588 wi::add (P1, P2) 8589 wi::add (P1, C2) 8590 wi::add (C1, P1) 8591 wi::add (P1, P2, SIGN, &OVERFLOW) 8592 8593 wi::sub (P1, P2) 8594 wi::sub (P1, C2) 8595 wi::sub (C1, P1) 8596 wi::sub (P1, P2, SIGN, &OVERFLOW) 8597 8598 wi::mul (P1, C2) 8599 wi::mul (C1, P1) 8600 wi::mul (P1, C2, SIGN, &OVERFLOW) 8601 8602 wi::lshift (P1, C2) 8603 8604 These routines just check whether overflow occurs on any individual 8605coefficient; it is not possible to know at compile time whether the 8606final runtime value would overflow. 8607 8608 8609File: gccint.info, Node: Division of poly_ints, Next: Other poly_int arithmetic, Prev: wi arithmetic on poly_ints, Up: Arithmetic on poly_ints 8610 861110.4.3 Division of 'poly_int's 8612------------------------------ 8613 8614Division of 'poly_int's is possible for certain inputs. The functions 8615for division return true if the operation is possible and in most cases 8616return the results by pointer. The routines are: 8617 8618'multiple_p (A, B)' 8619'multiple_p (A, B, "IENT)' 8620 Return true if A is an exact multiple of B, storing the result in 8621 QUOTIENT if so. There are overloads for various combinations of 8622 polynomial and constant A, B and QUOTIENT. 8623 8624'constant_multiple_p (A, B)' 8625'constant_multiple_p (A, B, "IENT)' 8626 Like 'multiple_p', but also test whether the multiple is a 8627 compile-time constant. 8628 8629'can_div_trunc_p (A, B, "IENT)' 8630'can_div_trunc_p (A, B, "IENT, &REMAINDER)' 8631 Return true if we can calculate 'trunc (A / B)' at compile time, 8632 storing the result in QUOTIENT and REMAINDER if so. 8633 8634'can_div_away_from_zero_p (A, B, "IENT)' 8635 Return true if we can calculate 'A / B' at compile time, rounding 8636 away from zero. Store the result in QUOTIENT if so. 8637 8638 Note that this is true if and only if 'can_div_trunc_p' is true. 8639 The only difference is in the rounding of the result. 8640 8641 There is also an asserting form of division: 8642 8643'exact_div (A, B)' 8644 Assert that A is a multiple of B and return 'A / B'. The result is 8645 a 'poly_int' if A is a 'poly_int'. 8646 8647 8648File: gccint.info, Node: Other poly_int arithmetic, Prev: Division of poly_ints, Up: Arithmetic on poly_ints 8649 865010.4.4 Other 'poly_int' arithmetic 8651---------------------------------- 8652 8653There are tentative routines for other operations besides division: 8654 8655'can_ior_p (A, B, &RESULT)' 8656 Return true if we can calculate 'A | B' at compile time, storing 8657 the result in RESULT if so. 8658 8659 Also, ANDs with a value '(1 << Y) - 1' or its inverse can be treated as 8660alignment operations. *Note Alignment of poly_ints::. 8661 8662 In addition, the following miscellaneous routines are available: 8663 8664'coeff_gcd (A)' 8665 Return the greatest common divisor of all nonzero coefficients in 8666 A, or zero if A is known to be zero. 8667 8668'common_multiple (A, B)' 8669 Return a value that is a multiple of both A and B, where one value 8670 is a 'poly_int' and the other is a scalar. The result will be the 8671 least common multiple for some indeterminate values but not 8672 necessarily for all. 8673 8674'force_common_multiple (A, B)' 8675 Return a value that is a multiple of both 'poly_int' A and 8676 'poly_int' B, asserting that such a value exists. The result will 8677 be the least common multiple for some indeterminate values but not 8678 necessarily for all. 8679 8680 When using this routine, please add a comment explaining why the 8681 assertion is known to hold. 8682 8683 Please add any other operations that you find to be useful. 8684 8685 8686File: gccint.info, Node: Alignment of poly_ints, Next: Computing bounds on poly_ints, Prev: Arithmetic on poly_ints, Up: poly_int 8687 868810.5 Alignment of 'poly_int's 8689============================= 8690 8691'poly_int' provides various routines for aligning values and for 8692querying misalignments. In each case the alignment must be a power of 86932. 8694 8695'can_align_p (VALUE, ALIGN)' 8696 Return true if we can align VALUE up or down to the nearest 8697 multiple of ALIGN at compile time. The answer is the same for both 8698 directions. 8699 8700'can_align_down (VALUE, ALIGN, &ALIGNED)' 8701 Return true if 'can_align_p'; if so, set ALIGNED to the greatest 8702 aligned value that is less than or equal to VALUE. 8703 8704'can_align_up (VALUE, ALIGN, &ALIGNED)' 8705 Return true if 'can_align_p'; if so, set ALIGNED to the lowest 8706 aligned value that is greater than or equal to VALUE. 8707 8708'known_equal_after_align_down (A, B, ALIGN)' 8709 Return true if we can align A and B down to the nearest ALIGN 8710 boundary at compile time and if the two results are equal. 8711 8712'known_equal_after_align_up (A, B, ALIGN)' 8713 Return true if we can align A and B up to the nearest ALIGN 8714 boundary at compile time and if the two results are equal. 8715 8716'aligned_lower_bound (VALUE, ALIGN)' 8717 Return a result that is no greater than VALUE and that is aligned 8718 to ALIGN. The result will the closest aligned value for some 8719 indeterminate values but not necessarily for all. 8720 8721 For example, suppose we are allocating an object of SIZE bytes in a 8722 downward-growing stack whose current limit is given by LIMIT. If 8723 the object requires ALIGN bytes of alignment, the new stack limit 8724 is given by: 8725 8726 aligned_lower_bound (LIMIT - SIZE, ALIGN) 8727 8728'aligned_upper_bound (VALUE, ALIGN)' 8729 Likewise return a result that is no less than VALUE and that is 8730 aligned to ALIGN. This is the routine that would be used for 8731 upward-growing stacks in the scenario just described. 8732 8733'known_misalignment (VALUE, ALIGN, &MISALIGN)' 8734 Return true if we can calculate the misalignment of VALUE with 8735 respect to ALIGN at compile time, storing the result in MISALIGN if 8736 so. 8737 8738'known_alignment (VALUE)' 8739 Return the minimum alignment that VALUE is known to have (in other 8740 words, the largest alignment that can be guaranteed whatever the 8741 values of the indeterminates turn out to be). Return 0 if VALUE is 8742 known to be 0. 8743 8744'force_align_down (VALUE, ALIGN)' 8745 Assert that VALUE can be aligned down to ALIGN at compile time and 8746 return the result. When using this routine, please add a comment 8747 explaining why the assertion is known to hold. 8748 8749'force_align_up (VALUE, ALIGN)' 8750 Likewise, but aligning up. 8751 8752'force_align_down_and_div (VALUE, ALIGN)' 8753 Divide the result of 'force_align_down' by ALIGN. Again, please 8754 add a comment explaining why the assertion in 'force_align_down' is 8755 known to hold. 8756 8757'force_align_up_and_div (VALUE, ALIGN)' 8758 Likewise for 'force_align_up'. 8759 8760'force_get_misalignment (VALUE, ALIGN)' 8761 Assert that we can calculate the misalignment of VALUE with respect 8762 to ALIGN at compile time and return the misalignment. When using 8763 this function, please add a comment explaining why the assertion is 8764 known to hold. 8765 8766 8767File: gccint.info, Node: Computing bounds on poly_ints, Next: Converting poly_ints, Prev: Alignment of poly_ints, Up: poly_int 8768 876910.6 Computing bounds on 'poly_int's 8770==================================== 8771 8772'poly_int' also provides routines for calculating lower and upper 8773bounds: 8774 8775'constant_lower_bound (A)' 8776 Assert that A is nonnegative and return the smallest value it can 8777 have. 8778 8779'lower_bound (A, B)' 8780 Return a value that is always less than or equal to both A and B. 8781 It will be the greatest such value for some indeterminate values 8782 but necessarily for all. 8783 8784'upper_bound (A, B)' 8785 Return a value that is always greater than or equal to both A and 8786 B. It will be the least such value for some indeterminate values 8787 but necessarily for all. 8788 8789 8790File: gccint.info, Node: Converting poly_ints, Next: Miscellaneous poly_int routines, Prev: Computing bounds on poly_ints, Up: poly_int 8791 879210.7 Converting 'poly_int's 8793=========================== 8794 8795A 'poly_int<N, T>' can be constructed from up to N individual T 8796coefficients, with the remaining coefficients being implicitly zero. In 8797particular, this means that every 'poly_int<N, T>' can be constructed 8798from a single scalar T, or something compatible with T. 8799 8800 Also, a 'poly_int<N, T>' can be constructed from a 'poly_int<N, U>' if 8801T can be constructed from U. 8802 8803 The following functions provide other forms of conversion, or test 8804whether such a conversion would succeed. 8805 8806'VALUE.is_constant ()' 8807 Return true if 'poly_int' VALUE is a compile-time constant. 8808 8809'VALUE.is_constant (&C1)' 8810 Return true if 'poly_int' VALUE is a compile-time constant, storing 8811 it in C1 if so. C1 must be able to hold all constant values of 8812 VALUE without loss of precision. 8813 8814'VALUE.to_constant ()' 8815 Assert that VALUE is a compile-time constant and return its value. 8816 When using this function, please add a comment explaining why the 8817 condition is known to hold (for example, because an earlier phase 8818 of analysis rejected non-constants). 8819 8820'VALUE.to_shwi (&P2)' 8821 Return true if 'poly_int<N, T>' VALUE can be represented without 8822 loss of precision as a 'poly_int<N, 'HOST_WIDE_INT'>', storing it 8823 in that form in P2 if so. 8824 8825'VALUE.to_uhwi (&P2)' 8826 Return true if 'poly_int<N, T>' VALUE can be represented without 8827 loss of precision as a 'poly_int<N, 'unsigned HOST_WIDE_INT'>', 8828 storing it in that form in P2 if so. 8829 8830'VALUE.force_shwi ()' 8831 Forcibly convert each coefficient of 'poly_int<N, T>' VALUE to 8832 'HOST_WIDE_INT', truncating any that are out of range. Return the 8833 result as a 'poly_int<N, 'HOST_WIDE_INT'>'. 8834 8835'VALUE.force_uhwi ()' 8836 Forcibly convert each coefficient of 'poly_int<N, T>' VALUE to 8837 'unsigned HOST_WIDE_INT', truncating any that are out of range. 8838 Return the result as a 'poly_int<N, 'unsigned HOST_WIDE_INT'>'. 8839 8840'wi::shwi (VALUE, PRECISION)' 8841 Return a 'poly_int' with the same value as VALUE, but with the 8842 coefficients converted from 'HOST_WIDE_INT' to 'wide_int'. 8843 PRECISION specifies the precision of the 'wide_int' cofficients; if 8844 this is wider than a 'HOST_WIDE_INT', the coefficients of VALUE 8845 will be sign-extended to fit. 8846 8847'wi::uhwi (VALUE, PRECISION)' 8848 Like 'wi::shwi', except that VALUE has coefficients of type 8849 'unsigned HOST_WIDE_INT'. If PRECISION is wider than a 8850 'HOST_WIDE_INT', the coefficients of VALUE will be zero-extended to 8851 fit. 8852 8853'wi::sext (VALUE, PRECISION)' 8854 Return a 'poly_int' of the same type as VALUE, sign-extending every 8855 coefficient from the low PRECISION bits. This in effect applies 8856 'wi::sext' to each coefficient individually. 8857 8858'wi::zext (VALUE, PRECISION)' 8859 Like 'wi::sext', but for zero extension. 8860 8861'poly_wide_int::from (VALUE, PRECISION, SIGN)' 8862 Convert VALUE to a 'poly_wide_int' in which each coefficient has 8863 PRECISION bits. Extend the coefficients according to SIGN if the 8864 coefficients have fewer bits. 8865 8866'poly_offset_int::from (VALUE, SIGN)' 8867 Convert VALUE to a 'poly_offset_int', extending its coefficients 8868 according to SIGN if they have fewer bits than 'offset_int'. 8869 8870'poly_widest_int::from (VALUE, SIGN)' 8871 Convert VALUE to a 'poly_widest_int', extending its coefficients 8872 according to SIGN if they have fewer bits than 'widest_int'. 8873 8874 8875File: gccint.info, Node: Miscellaneous poly_int routines, Next: Guidelines for using poly_int, Prev: Converting poly_ints, Up: poly_int 8876 887710.8 Miscellaneous 'poly_int' routines 8878====================================== 8879 8880'print_dec (VALUE, FILE, SIGN)' 8881'print_dec (VALUE, FILE)' 8882 Print VALUE to FILE as a decimal value, interpreting the 8883 coefficients according to SIGN. The final argument is optional if 8884 VALUE has an inherent sign; for example, 'poly_int64' values print 8885 as signed by default and 'poly_uint64' values print as unsigned by 8886 default. 8887 8888 This is a simply a 'poly_int' version of a wide-int routine. 8889 8890 8891File: gccint.info, Node: Guidelines for using poly_int, Prev: Miscellaneous poly_int routines, Up: poly_int 8892 889310.9 Guidelines for using 'poly_int' 8894==================================== 8895 8896One of the main design goals of 'poly_int' was to make it easy to write 8897target-independent code that handles variable-sized registers even when 8898the current target has fixed-sized registers. There are two aspects to 8899this: 8900 8901 * The set of 'poly_int' operations should be complete enough that the 8902 question in most cases becomes "Can we do this operation on these 8903 particular 'poly_int' values? If not, bail out" rather than "Are 8904 these 'poly_int' values constant? If so, do the operation, 8905 otherwise bail out". 8906 8907 * If target-independent code compiles and runs correctly on a target 8908 with one value of 'NUM_POLY_INT_COEFFS', and if the code does not 8909 use asserting functions like 'to_constant', it is reasonable to 8910 assume that the code also works on targets with other values of 8911 'NUM_POLY_INT_COEFFS'. There is no need to check this during 8912 everyday development. 8913 8914 So the general principle is: if target-independent code is dealing with 8915a 'poly_int' value, it is better to operate on it as a 'poly_int' if at 8916all possible, choosing conservatively-correct behavior if a particular 8917operation fails. For example, the following code handles an index 'pos' 8918into a sequence of vectors that each have 'nunits' elements: 8919 8920 /* Calculate which vector contains the result, and which lane of 8921 that vector we need. */ 8922 if (!can_div_trunc_p (pos, nunits, &vec_entry, &vec_index)) 8923 { 8924 if (dump_enabled_p ()) 8925 dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location, 8926 "Cannot determine which vector holds the" 8927 " final result.\n"); 8928 return false; 8929 } 8930 8931 However, there are some contexts in which operating on a 'poly_int' is 8932not possible or does not make sense. One example is when handling 8933static initializers, since no current target supports the concept of a 8934variable-length static initializer. In these situations, a reasonable 8935fallback is: 8936 8937 if (POLY_VALUE.is_constant (&CONST_VALUE)) 8938 { 8939 ... 8940 /* Operate on CONST_VALUE. */ 8941 ... 8942 } 8943 else 8944 { 8945 ... 8946 /* Conservatively correct fallback. */ 8947 ... 8948 } 8949 8950 'poly_int' also provides some asserting functions like 'to_constant'. 8951Please only use these functions if there is a good theoretical reason to 8952believe that the assertion cannot fire. For example, if some work is 8953divided into an analysis phase and an implementation phase, the analysis 8954phase might reject inputs that are not 'is_constant', in which case the 8955implementation phase can reasonably use 'to_constant' on the remaining 8956inputs. The assertions should not be used to discover whether a 8957condition ever occurs "in the field"; in other words, they should not be 8958used to restrict code to constants at first, with the intention of only 8959implementing a 'poly_int' version if a user hits the assertion. 8960 8961 If a particular asserting function like 'to_constant' is needed more 8962than once for the same reason, it is probably worth adding a helper 8963function or macro for that situation, so that the justification only 8964needs to be given once. For example: 8965 8966 /* Return the size of an element in a vector of size SIZE, given that 8967 the vector has NELTS elements. The return value is in the same units 8968 as SIZE (either bits or bytes). 8969 8970 to_constant () is safe in this situation because vector elements are 8971 always constant-sized scalars. */ 8972 #define vector_element_size(SIZE, NELTS) \ 8973 (exact_div (SIZE, NELTS).to_constant ()) 8974 8975 Target-specific code in 'config/CPU' only needs to handle non-constant 8976'poly_int's if 'NUM_POLY_INT_COEFFS' is greater than one. For other 8977targets, 'poly_int' degenerates to a compile-time constant and is often 8978interchangable with a normal scalar integer. There are two main 8979exceptions: 8980 8981 * Sometimes an explicit cast to an integer type might be needed, such 8982 as to resolve ambiguities in a '?:' expression, or when passing 8983 values through '...' to things like print functions. 8984 8985 * Target macros are included in target-independent code and so do not 8986 have access to the implicit conversion to a scalar integer. If 8987 this becomes a problem for a particular target macro, the possible 8988 solutions, in order of preference, are: 8989 8990 * Convert the target macro to a target hook (for all targets). 8991 8992 * Put the target's implementation of the target macro in its 8993 'CPU.c' file and call it from the target macro in the 'CPU.h' 8994 file. 8995 8996 * Add 'to_constant ()' calls where necessary. The previous 8997 option is preferable because it will help with any future 8998 conversion of the macro to a hook. 8999 9000 9001File: gccint.info, Node: GENERIC, Next: GIMPLE, Prev: poly_int, Up: Top 9002 900311 GENERIC 9004********** 9005 9006The purpose of GENERIC is simply to provide a language-independent way 9007of representing an entire function in trees. To this end, it was 9008necessary to add a few new tree codes to the back end, but almost 9009everything was already there. If you can express it with the codes in 9010'gcc/tree.def', it's GENERIC. 9011 9012 Early on, there was a great deal of debate about how to think about 9013statements in a tree IL. In GENERIC, a statement is defined as any 9014expression whose value, if any, is ignored. A statement will always 9015have 'TREE_SIDE_EFFECTS' set (or it will be discarded), but a 9016non-statement expression may also have side effects. A 'CALL_EXPR', for 9017instance. 9018 9019 It would be possible for some local optimizations to work on the 9020GENERIC form of a function; indeed, the adapted tree inliner works fine 9021on GENERIC, but the current compiler performs inlining after lowering to 9022GIMPLE (a restricted form described in the next section). Indeed, 9023currently the frontends perform this lowering before handing off to 9024'tree_rest_of_compilation', but this seems inelegant. 9025 9026* Menu: 9027 9028* Deficiencies:: Topics net yet covered in this document. 9029* Tree overview:: All about 'tree's. 9030* Types:: Fundamental and aggregate types. 9031* Declarations:: Type declarations and variables. 9032* Attributes:: Declaration and type attributes. 9033* Expressions: Expression trees. Operating on data. 9034* Statements:: Control flow and related trees. 9035* Functions:: Function bodies, linkage, and other aspects. 9036* Language-dependent trees:: Topics and trees specific to language front ends. 9037* C and C++ Trees:: Trees specific to C and C++. 9038* Java Trees:: Trees specific to Java. 9039 9040 9041File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: GENERIC 9042 904311.1 Deficiencies 9044================= 9045 9046There are many places in which this document is incomplet and incorrekt. 9047It is, as of yet, only _preliminary_ documentation. 9048 9049 9050File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: GENERIC 9051 905211.2 Overview 9053============= 9054 9055The central data structure used by the internal representation is the 9056'tree'. These nodes, while all of the C type 'tree', are of many 9057varieties. A 'tree' is a pointer type, but the object to which it 9058points may be of a variety of types. From this point forward, we will 9059refer to trees in ordinary type, rather than in 'this font', except when 9060talking about the actual C type 'tree'. 9061 9062 You can tell what kind of node a particular tree is by using the 9063'TREE_CODE' macro. Many, many macros take trees as input and return 9064trees as output. However, most macros require a certain kind of tree 9065node as input. In other words, there is a type-system for trees, but it 9066is not reflected in the C type-system. 9067 9068 For safety, it is useful to configure GCC with '--enable-checking'. 9069Although this results in a significant performance penalty (since all 9070tree types are checked at run-time), and is therefore inappropriate in a 9071release version, it is extremely helpful during the development process. 9072 9073 Many macros behave as predicates. Many, although not all, of these 9074predicates end in '_P'. Do not rely on the result type of these macros 9075being of any particular type. You may, however, rely on the fact that 9076the type can be compared to '0', so that statements like 9077 if (TEST_P (t) && !TEST_P (y)) 9078 x = 1; 9079and 9080 int i = (TEST_P (t) != 0); 9081are legal. Macros that return 'int' values now may be changed to return 9082'tree' values, or other pointers in the future. Even those that 9083continue to return 'int' may return multiple nonzero codes where 9084previously they returned only zero and one. Therefore, you should not 9085write code like 9086 if (TEST_P (t) == 1) 9087as this code is not guaranteed to work correctly in the future. 9088 9089 You should not take the address of values returned by the macros or 9090functions described here. In particular, no guarantee is given that the 9091values are lvalues. 9092 9093 In general, the names of macros are all in uppercase, while the names 9094of functions are entirely in lowercase. There are rare exceptions to 9095this rule. You should assume that any macro or function whose name is 9096made up entirely of uppercase letters may evaluate its arguments more 9097than once. You may assume that a macro or function whose name is made 9098up entirely of lowercase letters will evaluate its arguments only once. 9099 9100 The 'error_mark_node' is a special tree. Its tree code is 9101'ERROR_MARK', but since there is only ever one node with that code, the 9102usual practice is to compare the tree against 'error_mark_node'. (This 9103test is just a test for pointer equality.) If an error has occurred 9104during front-end processing the flag 'errorcount' will be set. If the 9105front end has encountered code it cannot handle, it will issue a message 9106to the user and set 'sorrycount'. When these flags are set, any macro 9107or function which normally returns a tree of a particular kind may 9108instead return the 'error_mark_node'. Thus, if you intend to do any 9109processing of erroneous code, you must be prepared to deal with the 9110'error_mark_node'. 9111 9112 Occasionally, a particular tree slot (like an operand to an expression, 9113or a particular field in a declaration) will be referred to as "reserved 9114for the back end". These slots are used to store RTL when the tree is 9115converted to RTL for use by the GCC back end. However, if that process 9116is not taking place (e.g., if the front end is being hooked up to an 9117intelligent editor), then those slots may be used by the back end 9118presently in use. 9119 9120 If you encounter situations that do not match this documentation, such 9121as tree nodes of types not mentioned here, or macros documented to 9122return entities of a particular kind that instead return entities of 9123some different kind, you have found a bug, either in the front end or in 9124the documentation. Please report these bugs as you would any other bug. 9125 9126* Menu: 9127 9128* Macros and Functions::Macros and functions that can be used with all trees. 9129* Identifiers:: The names of things. 9130* Containers:: Lists and vectors. 9131 9132 9133File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview 9134 913511.2.1 Trees 9136------------ 9137 9138All GENERIC trees have two fields in common. First, 'TREE_CHAIN' is a 9139pointer that can be used as a singly-linked list to other trees. The 9140other is 'TREE_TYPE'. Many trees store the type of an expression or 9141declaration in this field. 9142 9143 These are some other functions for handling trees: 9144 9145'tree_size' 9146 Return the number of bytes a tree takes. 9147 9148'build0' 9149'build1' 9150'build2' 9151'build3' 9152'build4' 9153'build5' 9154'build6' 9155 9156 These functions build a tree and supply values to put in each 9157 parameter. The basic signature is 'code, type, [operands]'. 9158 'code' is the 'TREE_CODE', and 'type' is a tree representing the 9159 'TREE_TYPE'. These are followed by the operands, each of which is 9160 also a tree. 9161 9162 9163File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview 9164 916511.2.2 Identifiers 9166------------------ 9167 9168An 'IDENTIFIER_NODE' represents a slightly more general concept than the 9169standard C or C++ concept of identifier. In particular, an 9170'IDENTIFIER_NODE' may contain a '$', or other extraordinary characters. 9171 9172 There are never two distinct 'IDENTIFIER_NODE's representing the same 9173identifier. Therefore, you may use pointer equality to compare 9174'IDENTIFIER_NODE's, rather than using a routine like 'strcmp'. Use 9175'get_identifier' to obtain the unique 'IDENTIFIER_NODE' for a supplied 9176string. 9177 9178 You can use the following macros to access identifiers: 9179'IDENTIFIER_POINTER' 9180 The string represented by the identifier, represented as a 'char*'. 9181 This string is always 'NUL'-terminated, and contains no embedded 9182 'NUL' characters. 9183 9184'IDENTIFIER_LENGTH' 9185 The length of the string returned by 'IDENTIFIER_POINTER', not 9186 including the trailing 'NUL'. This value of 'IDENTIFIER_LENGTH 9187 (x)' is always the same as 'strlen (IDENTIFIER_POINTER (x))'. 9188 9189'IDENTIFIER_OPNAME_P' 9190 This predicate holds if the identifier represents the name of an 9191 overloaded operator. In this case, you should not depend on the 9192 contents of either the 'IDENTIFIER_POINTER' or the 9193 'IDENTIFIER_LENGTH'. 9194 9195'IDENTIFIER_TYPENAME_P' 9196 This predicate holds if the identifier represents the name of a 9197 user-defined conversion operator. In this case, the 'TREE_TYPE' of 9198 the 'IDENTIFIER_NODE' holds the type to which the conversion 9199 operator converts. 9200 9201 9202File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview 9203 920411.2.3 Containers 9205----------------- 9206 9207Two common container data structures can be represented directly with 9208tree nodes. A 'TREE_LIST' is a singly linked list containing two trees 9209per node. These are the 'TREE_PURPOSE' and 'TREE_VALUE' of each node. 9210(Often, the 'TREE_PURPOSE' contains some kind of tag, or additional 9211information, while the 'TREE_VALUE' contains the majority of the 9212payload. In other cases, the 'TREE_PURPOSE' is simply 'NULL_TREE', 9213while in still others both the 'TREE_PURPOSE' and 'TREE_VALUE' are of 9214equal stature.) Given one 'TREE_LIST' node, the next node is found by 9215following the 'TREE_CHAIN'. If the 'TREE_CHAIN' is 'NULL_TREE', then 9216you have reached the end of the list. 9217 9218 A 'TREE_VEC' is a simple vector. The 'TREE_VEC_LENGTH' is an integer 9219(not a tree) giving the number of nodes in the vector. The nodes 9220themselves are accessed using the 'TREE_VEC_ELT' macro, which takes two 9221arguments. The first is the 'TREE_VEC' in question; the second is an 9222integer indicating which element in the vector is desired. The elements 9223are indexed from zero. 9224 9225 9226File: gccint.info, Node: Types, Next: Declarations, Prev: Tree overview, Up: GENERIC 9227 922811.3 Types 9229========== 9230 9231All types have corresponding tree nodes. However, you should not assume 9232that there is exactly one tree node corresponding to each type. There 9233are often multiple nodes corresponding to the same type. 9234 9235 For the most part, different kinds of types have different tree codes. 9236(For example, pointer types use a 'POINTER_TYPE' code while arrays use 9237an 'ARRAY_TYPE' code.) However, pointers to member functions use the 9238'RECORD_TYPE' code. Therefore, when writing a 'switch' statement that 9239depends on the code associated with a particular type, you should take 9240care to handle pointers to member functions under the 'RECORD_TYPE' case 9241label. 9242 9243 The following functions and macros deal with cv-qualification of types: 9244'TYPE_MAIN_VARIANT' 9245 This macro returns the unqualified version of a type. It may be 9246 applied to an unqualified type, but it is not always the identity 9247 function in that case. 9248 9249 A few other macros and functions are usable with all types: 9250'TYPE_SIZE' 9251 The number of bits required to represent the type, represented as 9252 an 'INTEGER_CST'. For an incomplete type, 'TYPE_SIZE' will be 9253 'NULL_TREE'. 9254 9255'TYPE_ALIGN' 9256 The alignment of the type, in bits, represented as an 'int'. 9257 9258'TYPE_NAME' 9259 This macro returns a declaration (in the form of a 'TYPE_DECL') for 9260 the type. (Note this macro does _not_ return an 'IDENTIFIER_NODE', 9261 as you might expect, given its name!) You can look at the 9262 'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the 9263 type. The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a 9264 built-in type, the result of a typedef, or a named class type. 9265 9266'TYPE_CANONICAL' 9267 This macro returns the "canonical" type for the given type node. 9268 Canonical types are used to improve performance in the C++ and 9269 Objective-C++ front ends by allowing efficient comparison between 9270 two type nodes in 'same_type_p': if the 'TYPE_CANONICAL' values of 9271 the types are equal, the types are equivalent; otherwise, the types 9272 are not equivalent. The notion of equivalence for canonical types 9273 is the same as the notion of type equivalence in the language 9274 itself. For instance, 9275 9276 When 'TYPE_CANONICAL' is 'NULL_TREE', there is no canonical type 9277 for the given type node. In this case, comparison between this 9278 type and any other type requires the compiler to perform a deep, 9279 "structural" comparison to see if the two type nodes have the same 9280 form and properties. 9281 9282 The canonical type for a node is always the most fundamental type 9283 in the equivalence class of types. For instance, 'int' is its own 9284 canonical type. A typedef 'I' of 'int' will have 'int' as its 9285 canonical type. Similarly, 'I*' and a typedef 'IP' (defined to 9286 'I*') will has 'int*' as their canonical type. When building a new 9287 type node, be sure to set 'TYPE_CANONICAL' to the appropriate 9288 canonical type. If the new type is a compound type (built from 9289 other types), and any of those other types require structural 9290 equality, use 'SET_TYPE_STRUCTURAL_EQUALITY' to ensure that the new 9291 type also requires structural equality. Finally, if for some 9292 reason you cannot guarantee that 'TYPE_CANONICAL' will point to the 9293 canonical type, use 'SET_TYPE_STRUCTURAL_EQUALITY' to make sure 9294 that the new type-and any type constructed based on it-requires 9295 structural equality. If you suspect that the canonical type system 9296 is miscomparing types, pass '--param verify-canonical-types=1' to 9297 the compiler or configure with '--enable-checking' to force the 9298 compiler to verify its canonical-type comparisons against the 9299 structural comparisons; the compiler will then print any warnings 9300 if the canonical types miscompare. 9301 9302'TYPE_STRUCTURAL_EQUALITY_P' 9303 This predicate holds when the node requires structural equality 9304 checks, e.g., when 'TYPE_CANONICAL' is 'NULL_TREE'. 9305 9306'SET_TYPE_STRUCTURAL_EQUALITY' 9307 This macro states that the type node it is given requires 9308 structural equality checks, e.g., it sets 'TYPE_CANONICAL' to 9309 'NULL_TREE'. 9310 9311'same_type_p' 9312 This predicate takes two types as input, and holds if they are the 9313 same type. For example, if one type is a 'typedef' for the other, 9314 or both are 'typedef's for the same type. This predicate also 9315 holds if the two trees given as input are simply copies of one 9316 another; i.e., there is no difference between them at the source 9317 level, but, for whatever reason, a duplicate has been made in the 9318 representation. You should never use '==' (pointer equality) to 9319 compare types; always use 'same_type_p' instead. 9320 9321 Detailed below are the various kinds of types, and the macros that can 9322be used to access them. Although other kinds of types are used 9323elsewhere in G++, the types described here are the only ones that you 9324will encounter while examining the intermediate representation. 9325 9326'VOID_TYPE' 9327 Used to represent the 'void' type. 9328 9329'INTEGER_TYPE' 9330 Used to represent the various integral types, including 'char', 9331 'short', 'int', 'long', and 'long long'. This code is not used for 9332 enumeration types, nor for the 'bool' type. The 'TYPE_PRECISION' 9333 is the number of bits used in the representation, represented as an 9334 'unsigned int'. (Note that in the general case this is not the 9335 same value as 'TYPE_SIZE'; suppose that there were a 24-bit integer 9336 type, but that alignment requirements for the ABI required 32-bit 9337 alignment. Then, 'TYPE_SIZE' would be an 'INTEGER_CST' for 32, 9338 while 'TYPE_PRECISION' would be 24.) The integer type is unsigned 9339 if 'TYPE_UNSIGNED' holds; otherwise, it is signed. 9340 9341 The 'TYPE_MIN_VALUE' is an 'INTEGER_CST' for the smallest integer 9342 that may be represented by this type. Similarly, the 9343 'TYPE_MAX_VALUE' is an 'INTEGER_CST' for the largest integer that 9344 may be represented by this type. 9345 9346'REAL_TYPE' 9347 Used to represent the 'float', 'double', and 'long double' types. 9348 The number of bits in the floating-point representation is given by 9349 'TYPE_PRECISION', as in the 'INTEGER_TYPE' case. 9350 9351'FIXED_POINT_TYPE' 9352 Used to represent the 'short _Fract', '_Fract', 'long _Fract', 9353 'long long _Fract', 'short _Accum', '_Accum', 'long _Accum', and 9354 'long long _Accum' types. The number of bits in the fixed-point 9355 representation is given by 'TYPE_PRECISION', as in the 9356 'INTEGER_TYPE' case. There may be padding bits, fractional bits 9357 and integral bits. The number of fractional bits is given by 9358 'TYPE_FBIT', and the number of integral bits is given by 9359 'TYPE_IBIT'. The fixed-point type is unsigned if 'TYPE_UNSIGNED' 9360 holds; otherwise, it is signed. The fixed-point type is saturating 9361 if 'TYPE_SATURATING' holds; otherwise, it is not saturating. 9362 9363'COMPLEX_TYPE' 9364 Used to represent GCC built-in '__complex__' data types. The 9365 'TREE_TYPE' is the type of the real and imaginary parts. 9366 9367'ENUMERAL_TYPE' 9368 Used to represent an enumeration type. The 'TYPE_PRECISION' gives 9369 (as an 'int'), the number of bits used to represent the type. If 9370 there are no negative enumeration constants, 'TYPE_UNSIGNED' will 9371 hold. The minimum and maximum enumeration constants may be 9372 obtained with 'TYPE_MIN_VALUE' and 'TYPE_MAX_VALUE', respectively; 9373 each of these macros returns an 'INTEGER_CST'. 9374 9375 The actual enumeration constants themselves may be obtained by 9376 looking at the 'TYPE_VALUES'. This macro will return a 9377 'TREE_LIST', containing the constants. The 'TREE_PURPOSE' of each 9378 node will be an 'IDENTIFIER_NODE' giving the name of the constant; 9379 the 'TREE_VALUE' will be an 'INTEGER_CST' giving the value assigned 9380 to that constant. These constants will appear in the order in 9381 which they were declared. The 'TREE_TYPE' of each of these 9382 constants will be the type of enumeration type itself. 9383 9384'BOOLEAN_TYPE' 9385 Used to represent the 'bool' type. 9386 9387'POINTER_TYPE' 9388 Used to represent pointer types, and pointer to data member types. 9389 The 'TREE_TYPE' gives the type to which this type points. 9390 9391'REFERENCE_TYPE' 9392 Used to represent reference types. The 'TREE_TYPE' gives the type 9393 to which this type refers. 9394 9395'FUNCTION_TYPE' 9396 Used to represent the type of non-member functions and of static 9397 member functions. The 'TREE_TYPE' gives the return type of the 9398 function. The 'TYPE_ARG_TYPES' are a 'TREE_LIST' of the argument 9399 types. The 'TREE_VALUE' of each node in this list is the type of 9400 the corresponding argument; the 'TREE_PURPOSE' is an expression for 9401 the default argument value, if any. If the last node in the list 9402 is 'void_list_node' (a 'TREE_LIST' node whose 'TREE_VALUE' is the 9403 'void_type_node'), then functions of this type do not take variable 9404 arguments. Otherwise, they do take a variable number of arguments. 9405 9406 Note that in C (but not in C++) a function declared like 'void f()' 9407 is an unprototyped function taking a variable number of arguments; 9408 the 'TYPE_ARG_TYPES' of such a function will be 'NULL'. 9409 9410'METHOD_TYPE' 9411 Used to represent the type of a non-static member function. Like a 9412 'FUNCTION_TYPE', the return type is given by the 'TREE_TYPE'. The 9413 type of '*this', i.e., the class of which functions of this type 9414 are a member, is given by the 'TYPE_METHOD_BASETYPE'. The 9415 'TYPE_ARG_TYPES' is the parameter list, as for a 'FUNCTION_TYPE', 9416 and includes the 'this' argument. 9417 9418'ARRAY_TYPE' 9419 Used to represent array types. The 'TREE_TYPE' gives the type of 9420 the elements in the array. If the array-bound is present in the 9421 type, the 'TYPE_DOMAIN' is an 'INTEGER_TYPE' whose 'TYPE_MIN_VALUE' 9422 and 'TYPE_MAX_VALUE' will be the lower and upper bounds of the 9423 array, respectively. The 'TYPE_MIN_VALUE' will always be an 9424 'INTEGER_CST' for zero, while the 'TYPE_MAX_VALUE' will be one less 9425 than the number of elements in the array, i.e., the highest value 9426 which may be used to index an element in the array. 9427 9428'RECORD_TYPE' 9429 Used to represent 'struct' and 'class' types, as well as pointers 9430 to member functions and similar constructs in other languages. 9431 'TYPE_FIELDS' contains the items contained in this type, each of 9432 which can be a 'FIELD_DECL', 'VAR_DECL', 'CONST_DECL', or 9433 'TYPE_DECL'. You may not make any assumptions about the ordering 9434 of the fields in the type or whether one or more of them overlap. 9435 9436'UNION_TYPE' 9437 Used to represent 'union' types. Similar to 'RECORD_TYPE' except 9438 that all 'FIELD_DECL' nodes in 'TYPE_FIELD' start at bit position 9439 zero. 9440 9441'QUAL_UNION_TYPE' 9442 Used to represent part of a variant record in Ada. Similar to 9443 'UNION_TYPE' except that each 'FIELD_DECL' has a 'DECL_QUALIFIER' 9444 field, which contains a boolean expression that indicates whether 9445 the field is present in the object. The type will only have one 9446 field, so each field's 'DECL_QUALIFIER' is only evaluated if none 9447 of the expressions in the previous fields in 'TYPE_FIELDS' are 9448 nonzero. Normally these expressions will reference a field in the 9449 outer object using a 'PLACEHOLDER_EXPR'. 9450 9451'LANG_TYPE' 9452 This node is used to represent a language-specific type. The front 9453 end must handle it. 9454 9455'OFFSET_TYPE' 9456 This node is used to represent a pointer-to-data member. For a 9457 data member 'X::m' the 'TYPE_OFFSET_BASETYPE' is 'X' and the 9458 'TREE_TYPE' is the type of 'm'. 9459 9460 There are variables whose values represent some of the basic types. 9461These include: 9462'void_type_node' 9463 A node for 'void'. 9464 9465'integer_type_node' 9466 A node for 'int'. 9467 9468'unsigned_type_node.' 9469 A node for 'unsigned int'. 9470 9471'char_type_node.' 9472 A node for 'char'. 9473It may sometimes be useful to compare one of these variables with a type 9474in hand, using 'same_type_p'. 9475 9476 9477File: gccint.info, Node: Declarations, Next: Attributes, Prev: Types, Up: GENERIC 9478 947911.4 Declarations 9480================= 9481 9482This section covers the various kinds of declarations that appear in the 9483internal representation, except for declarations of functions 9484(represented by 'FUNCTION_DECL' nodes), which are described in *note 9485Functions::. 9486 9487* Menu: 9488 9489* Working with declarations:: Macros and functions that work on 9490declarations. 9491* Internal structure:: How declaration nodes are represented. 9492 9493 9494File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations 9495 949611.4.1 Working with declarations 9497-------------------------------- 9498 9499Some macros can be used with any kind of declaration. These include: 9500'DECL_NAME' 9501 This macro returns an 'IDENTIFIER_NODE' giving the name of the 9502 entity. 9503 9504'TREE_TYPE' 9505 This macro returns the type of the entity declared. 9506 9507'EXPR_FILENAME' 9508 This macro returns the name of the file in which the entity was 9509 declared, as a 'char*'. For an entity declared implicitly by the 9510 compiler (like '__builtin_memcpy'), this will be the string 9511 '"<internal>"'. 9512 9513'EXPR_LINENO' 9514 This macro returns the line number at which the entity was 9515 declared, as an 'int'. 9516 9517'DECL_ARTIFICIAL' 9518 This predicate holds if the declaration was implicitly generated by 9519 the compiler. For example, this predicate will hold of an 9520 implicitly declared member function, or of the 'TYPE_DECL' 9521 implicitly generated for a class type. Recall that in C++ code 9522 like: 9523 struct S {}; 9524 is roughly equivalent to C code like: 9525 struct S {}; 9526 typedef struct S S; 9527 The implicitly generated 'typedef' declaration is represented by a 9528 'TYPE_DECL' for which 'DECL_ARTIFICIAL' holds. 9529 9530 The various kinds of declarations include: 9531'LABEL_DECL' 9532 These nodes are used to represent labels in function bodies. For 9533 more information, see *note Functions::. These nodes only appear 9534 in block scopes. 9535 9536'CONST_DECL' 9537 These nodes are used to represent enumeration constants. The value 9538 of the constant is given by 'DECL_INITIAL' which will be an 9539 'INTEGER_CST' with the same type as the 'TREE_TYPE' of the 9540 'CONST_DECL', i.e., an 'ENUMERAL_TYPE'. 9541 9542'RESULT_DECL' 9543 These nodes represent the value returned by a function. When a 9544 value is assigned to a 'RESULT_DECL', that indicates that the value 9545 should be returned, via bitwise copy, by the function. You can use 9546 'DECL_SIZE' and 'DECL_ALIGN' on a 'RESULT_DECL', just as with a 9547 'VAR_DECL'. 9548 9549'TYPE_DECL' 9550 These nodes represent 'typedef' declarations. The 'TREE_TYPE' is 9551 the type declared to have the name given by 'DECL_NAME'. In some 9552 cases, there is no associated name. 9553 9554'VAR_DECL' 9555 These nodes represent variables with namespace or block scope, as 9556 well as static data members. The 'DECL_SIZE' and 'DECL_ALIGN' are 9557 analogous to 'TYPE_SIZE' and 'TYPE_ALIGN'. For a declaration, you 9558 should always use the 'DECL_SIZE' and 'DECL_ALIGN' rather than the 9559 'TYPE_SIZE' and 'TYPE_ALIGN' given by the 'TREE_TYPE', since 9560 special attributes may have been applied to the variable to give it 9561 a particular size and alignment. You may use the predicates 9562 'DECL_THIS_STATIC' or 'DECL_THIS_EXTERN' to test whether the 9563 storage class specifiers 'static' or 'extern' were used to declare 9564 a variable. 9565 9566 If this variable is initialized (but does not require a 9567 constructor), the 'DECL_INITIAL' will be an expression for the 9568 initializer. The initializer should be evaluated, and a bitwise 9569 copy into the variable performed. If the 'DECL_INITIAL' is the 9570 'error_mark_node', there is an initializer, but it is given by an 9571 explicit statement later in the code; no bitwise copy is required. 9572 9573 GCC provides an extension that allows either automatic variables, 9574 or global variables, to be placed in particular registers. This 9575 extension is being used for a particular 'VAR_DECL' if 9576 'DECL_REGISTER' holds for the 'VAR_DECL', and if 9577 'DECL_ASSEMBLER_NAME' is not equal to 'DECL_NAME'. In that case, 9578 'DECL_ASSEMBLER_NAME' is the name of the register into which the 9579 variable will be placed. 9580 9581'PARM_DECL' 9582 Used to represent a parameter to a function. Treat these nodes 9583 similarly to 'VAR_DECL' nodes. These nodes only appear in the 9584 'DECL_ARGUMENTS' for a 'FUNCTION_DECL'. 9585 9586 The 'DECL_ARG_TYPE' for a 'PARM_DECL' is the type that will 9587 actually be used when a value is passed to this function. It may 9588 be a wider type than the 'TREE_TYPE' of the parameter; for example, 9589 the ordinary type might be 'short' while the 'DECL_ARG_TYPE' is 9590 'int'. 9591 9592'DEBUG_EXPR_DECL' 9593 Used to represent an anonymous debug-information temporary created 9594 to hold an expression as it is optimized away, so that its value 9595 can be referenced in debug bind statements. 9596 9597'FIELD_DECL' 9598 These nodes represent non-static data members. The 'DECL_SIZE' and 9599 'DECL_ALIGN' behave as for 'VAR_DECL' nodes. The position of the 9600 field within the parent record is specified by a combination of 9601 three attributes. 'DECL_FIELD_OFFSET' is the position, counting in 9602 bytes, of the 'DECL_OFFSET_ALIGN'-bit sized word containing the bit 9603 of the field closest to the beginning of the structure. 9604 'DECL_FIELD_BIT_OFFSET' is the bit offset of the first bit of the 9605 field within this word; this may be nonzero even for fields that 9606 are not bit-fields, since 'DECL_OFFSET_ALIGN' may be greater than 9607 the natural alignment of the field's type. 9608 9609 If 'DECL_C_BIT_FIELD' holds, this field is a bit-field. In a 9610 bit-field, 'DECL_BIT_FIELD_TYPE' also contains the type that was 9611 originally specified for it, while DECL_TYPE may be a modified type 9612 with lesser precision, according to the size of the bit field. 9613 9614'NAMESPACE_DECL' 9615 Namespaces provide a name hierarchy for other declarations. They 9616 appear in the 'DECL_CONTEXT' of other '_DECL' nodes. 9617 9618 9619File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations 9620 962111.4.2 Internal structure 9622------------------------- 9623 9624'DECL' nodes are represented internally as a hierarchy of structures. 9625 9626* Menu: 9627 9628* Current structure hierarchy:: The current DECL node structure 9629hierarchy. 9630* Adding new DECL node types:: How to add a new DECL node to a 9631frontend. 9632 9633 9634File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure 9635 963611.4.2.1 Current structure hierarchy 9637.................................... 9638 9639'struct tree_decl_minimal' 9640 This is the minimal structure to inherit from in order for common 9641 'DECL' macros to work. The fields it contains are a unique ID, 9642 source location, context, and name. 9643 9644'struct tree_decl_common' 9645 This structure inherits from 'struct tree_decl_minimal'. It 9646 contains fields that most 'DECL' nodes need, such as a field to 9647 store alignment, machine mode, size, and attributes. 9648 9649'struct tree_field_decl' 9650 This structure inherits from 'struct tree_decl_common'. It is used 9651 to represent 'FIELD_DECL'. 9652 9653'struct tree_label_decl' 9654 This structure inherits from 'struct tree_decl_common'. It is used 9655 to represent 'LABEL_DECL'. 9656 9657'struct tree_translation_unit_decl' 9658 This structure inherits from 'struct tree_decl_common'. It is used 9659 to represent 'TRANSLATION_UNIT_DECL'. 9660 9661'struct tree_decl_with_rtl' 9662 This structure inherits from 'struct tree_decl_common'. It 9663 contains a field to store the low-level RTL associated with a 9664 'DECL' node. 9665 9666'struct tree_result_decl' 9667 This structure inherits from 'struct tree_decl_with_rtl'. It is 9668 used to represent 'RESULT_DECL'. 9669 9670'struct tree_const_decl' 9671 This structure inherits from 'struct tree_decl_with_rtl'. It is 9672 used to represent 'CONST_DECL'. 9673 9674'struct tree_parm_decl' 9675 This structure inherits from 'struct tree_decl_with_rtl'. It is 9676 used to represent 'PARM_DECL'. 9677 9678'struct tree_decl_with_vis' 9679 This structure inherits from 'struct tree_decl_with_rtl'. It 9680 contains fields necessary to store visibility information, as well 9681 as a section name and assembler name. 9682 9683'struct tree_var_decl' 9684 This structure inherits from 'struct tree_decl_with_vis'. It is 9685 used to represent 'VAR_DECL'. 9686 9687'struct tree_function_decl' 9688 This structure inherits from 'struct tree_decl_with_vis'. It is 9689 used to represent 'FUNCTION_DECL'. 9690 9691 9692File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure 9693 969411.4.2.2 Adding new DECL node types 9695................................... 9696 9697Adding a new 'DECL' tree consists of the following steps 9698 9699Add a new tree code for the 'DECL' node 9700 For language specific 'DECL' nodes, there is a '.def' file in each 9701 frontend directory where the tree code should be added. For 'DECL' 9702 nodes that are part of the middle-end, the code should be added to 9703 'tree.def'. 9704 9705Create a new structure type for the 'DECL' node 9706 These structures should inherit from one of the existing structures 9707 in the language hierarchy by using that structure as the first 9708 member. 9709 9710 struct tree_foo_decl 9711 { 9712 struct tree_decl_with_vis common; 9713 } 9714 9715 Would create a structure name 'tree_foo_decl' that inherits from 9716 'struct tree_decl_with_vis'. 9717 9718 For language specific 'DECL' nodes, this new structure type should 9719 go in the appropriate '.h' file. For 'DECL' nodes that are part of 9720 the middle-end, the structure type should go in 'tree.h'. 9721 9722Add a member to the tree structure enumerator for the node 9723 For garbage collection and dynamic checking purposes, each 'DECL' 9724 node structure type is required to have a unique enumerator value 9725 specified with it. For language specific 'DECL' nodes, this new 9726 enumerator value should go in the appropriate '.def' file. For 9727 'DECL' nodes that are part of the middle-end, the enumerator values 9728 are specified in 'treestruct.def'. 9729 9730Update 'union tree_node' 9731 In order to make your new structure type usable, it must be added 9732 to 'union tree_node'. For language specific 'DECL' nodes, a new 9733 entry should be added to the appropriate '.h' file of the form 9734 struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl; 9735 For 'DECL' nodes that are part of the middle-end, the additional 9736 member goes directly into 'union tree_node' in 'tree.h'. 9737 9738Update dynamic checking info 9739 In order to be able to check whether accessing a named portion of 9740 'union tree_node' is legal, and whether a certain 'DECL' node 9741 contains one of the enumerated 'DECL' node structures in the 9742 hierarchy, a simple lookup table is used. This lookup table needs 9743 to be kept up to date with the tree structure hierarchy, or else 9744 checking and containment macros will fail inappropriately. 9745 9746 For language specific 'DECL' nodes, their is an 'init_ts' function 9747 in an appropriate '.c' file, which initializes the lookup table. 9748 Code setting up the table for new 'DECL' nodes should be added 9749 there. For each 'DECL' tree code and enumerator value representing 9750 a member of the inheritance hierarchy, the table should contain 1 9751 if that tree code inherits (directly or indirectly) from that 9752 member. Thus, a 'FOO_DECL' node derived from 'struct 9753 decl_with_rtl', and enumerator value 'TS_FOO_DECL', would be set up 9754 as follows 9755 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1; 9756 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1; 9757 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1; 9758 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1; 9759 9760 For 'DECL' nodes that are part of the middle-end, the setup code 9761 goes into 'tree.c'. 9762 9763Add macros to access any new fields and flags 9764 9765 Each added field or flag should have a macro that is used to access 9766 it, that performs appropriate checking to ensure only the right 9767 type of 'DECL' nodes access the field. 9768 9769 These macros generally take the following form 9770 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname 9771 However, if the structure is simply a base class for further 9772 structures, something like the following should be used 9773 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT) 9774 #define BASE_STRUCT_FIELDNAME(NODE) \ 9775 (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname 9776 9777 Reading them from the generated 'all-tree.def' file (which in turn 9778 includes all the 'tree.def' files), 'gencheck.c' is used during 9779 GCC's build to generate the '*_CHECK' macros for all tree codes. 9780 9781 9782File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: GENERIC 9783 978411.5 Attributes in trees 9785======================== 9786 9787Attributes, as specified using the '__attribute__' keyword, are 9788represented internally as a 'TREE_LIST'. The 'TREE_PURPOSE' is the name 9789of the attribute, as an 'IDENTIFIER_NODE'. The 'TREE_VALUE' is a 9790'TREE_LIST' of the arguments of the attribute, if any, or 'NULL_TREE' if 9791there are no arguments; the arguments are stored as the 'TREE_VALUE' of 9792successive entries in the list, and may be identifiers or expressions. 9793The 'TREE_CHAIN' of the attribute is the next attribute in a list of 9794attributes applying to the same declaration or type, or 'NULL_TREE' if 9795there are no further attributes in the list. 9796 9797 Attributes may be attached to declarations and to types; these 9798attributes may be accessed with the following macros. All attributes 9799are stored in this way, and many also cause other changes to the 9800declaration or type or to other internal compiler data structures. 9801 9802 -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL) 9803 This macro returns the attributes on the declaration DECL. 9804 9805 -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE) 9806 This macro returns the attributes on the type TYPE. 9807 9808 9809File: gccint.info, Node: Expression trees, Next: Statements, Prev: Attributes, Up: GENERIC 9810 981111.6 Expressions 9812================ 9813 9814The internal representation for expressions is for the most part quite 9815straightforward. However, there are a few facts that one must bear in 9816mind. In particular, the expression "tree" is actually a directed 9817acyclic graph. (For example there may be many references to the integer 9818constant zero throughout the source program; many of these will be 9819represented by the same expression node.) You should not rely on 9820certain kinds of node being shared, nor should you rely on certain kinds 9821of nodes being unshared. 9822 9823 The following macros can be used with all expression nodes: 9824 9825'TREE_TYPE' 9826 Returns the type of the expression. This value may not be 9827 precisely the same type that would be given the expression in the 9828 original program. 9829 9830 In what follows, some nodes that one might expect to always have type 9831'bool' are documented to have either integral or boolean type. At some 9832point in the future, the C front end may also make use of this same 9833intermediate representation, and at this point these nodes will 9834certainly have integral type. The previous sentence is not meant to 9835imply that the C++ front end does not or will not give these nodes 9836integral type. 9837 9838 Below, we list the various kinds of expression nodes. Except where 9839noted otherwise, the operands to an expression are accessed using the 9840'TREE_OPERAND' macro. For example, to access the first operand to a 9841binary plus expression 'expr', use: 9842 9843 TREE_OPERAND (expr, 0) 9844 9845 As this example indicates, the operands are zero-indexed. 9846 9847* Menu: 9848 9849* Constants: Constant expressions. 9850* Storage References:: 9851* Unary and Binary Expressions:: 9852* Vectors:: 9853 9854 9855File: gccint.info, Node: Constant expressions, Next: Storage References, Up: Expression trees 9856 985711.6.1 Constant expressions 9858--------------------------- 9859 9860The table below begins with constants, moves on to unary expressions, 9861then proceeds to binary expressions, and concludes with various other 9862kinds of expressions: 9863 9864'INTEGER_CST' 9865 These nodes represent integer constants. Note that the type of 9866 these constants is obtained with 'TREE_TYPE'; they are not always 9867 of type 'int'. In particular, 'char' constants are represented 9868 with 'INTEGER_CST' nodes. The value of the integer constant 'e' is 9869 represented in an array of HOST_WIDE_INT. There are enough elements 9870 in the array to represent the value without taking extra elements 9871 for redundant 0s or -1. The number of elements used to represent 9872 'e' is available via 'TREE_INT_CST_NUNITS'. Element 'i' can be 9873 extracted by using 'TREE_INT_CST_ELT (e, i)'. 'TREE_INT_CST_LOW' 9874 is a shorthand for 'TREE_INT_CST_ELT (e, 0)'. 9875 9876 The functions 'tree_fits_shwi_p' and 'tree_fits_uhwi_p' can be used 9877 to tell if the value is small enough to fit in a signed 9878 HOST_WIDE_INT or an unsigned HOST_WIDE_INT respectively. The value 9879 can then be extracted using 'tree_to_shwi' and 'tree_to_uhwi'. 9880 9881'REAL_CST' 9882 9883 FIXME: Talk about how to obtain representations of this constant, 9884 do comparisons, and so forth. 9885 9886'FIXED_CST' 9887 9888 These nodes represent fixed-point constants. The type of these 9889 constants is obtained with 'TREE_TYPE'. 'TREE_FIXED_CST_PTR' 9890 points to a 'struct fixed_value'; 'TREE_FIXED_CST' returns the 9891 structure itself. 'struct fixed_value' contains 'data' with the 9892 size of two 'HOST_BITS_PER_WIDE_INT' and 'mode' as the associated 9893 fixed-point machine mode for 'data'. 9894 9895'COMPLEX_CST' 9896 These nodes are used to represent complex number constants, that is 9897 a '__complex__' whose parts are constant nodes. The 9898 'TREE_REALPART' and 'TREE_IMAGPART' return the real and the 9899 imaginary parts respectively. 9900 9901'VECTOR_CST' 9902 These nodes are used to represent vector constants. Each vector 9903 constant V is treated as a specific instance of an arbitrary-length 9904 sequence that itself contains 'VECTOR_CST_NPATTERNS (V)' 9905 interleaved patterns. Each pattern has the form: 9906 9907 { BASE0, BASE1, BASE1 + STEP, BASE1 + STEP * 2, ... } 9908 9909 The first three elements in each pattern are enough to determine 9910 the values of the other elements. However, if all STEPs are zero, 9911 only the first two elements are needed. If in addition each BASE1 9912 is equal to the corresponding BASE0, only the first element in each 9913 pattern is needed. The number of encoded elements per pattern is 9914 given by 'VECTOR_CST_NELTS_PER_PATTERN (V)'. 9915 9916 For example, the constant: 9917 9918 { 0, 1, 2, 6, 3, 8, 4, 10, 5, 12, 6, 14, 7, 16, 8, 18 } 9919 9920 is interpreted as an interleaving of the sequences: 9921 9922 { 0, 2, 3, 4, 5, 6, 7, 8 } 9923 { 1, 6, 8, 10, 12, 14, 16, 18 } 9924 9925 where the sequences are represented by the following patterns: 9926 9927 BASE0 == 0, BASE1 == 2, STEP == 1 9928 BASE0 == 1, BASE1 == 6, STEP == 2 9929 9930 In this case: 9931 9932 VECTOR_CST_NPATTERNS (V) == 2 9933 VECTOR_CST_NELTS_PER_PATTERN (V) == 3 9934 9935 The vector is therefore encoded using the first 6 elements ('{ 0, 9936 1, 2, 6, 3, 8 }'), with the remaining 10 elements being implicit 9937 extensions of them. 9938 9939 Sometimes this scheme can create two possible encodings of the same 9940 vector. For example { 0, 1 } could be seen as two patterns with 9941 one element each or one pattern with two elements (BASE0 and 9942 BASE1). The canonical encoding is always the one with the fewest 9943 patterns or (if both encodings have the same number of petterns) 9944 the one with the fewest encoded elements. 9945 9946 'vector_cst_encoding_nelts (V)' gives the total number of encoded 9947 elements in V, which is 6 in the example above. 9948 'VECTOR_CST_ENCODED_ELTS (V)' gives a pointer to the elements 9949 encoded in V and 'VECTOR_CST_ENCODED_ELT (V, I)' accesses the value 9950 of encoded element I. 9951 9952 'VECTOR_CST_DUPLICATE_P (V)' is true if V simply contains repeated 9953 instances of 'VECTOR_CST_NPATTERNS (V)' values. This is a 9954 shorthand for testing 'VECTOR_CST_NELTS_PER_PATTERN (V) == 1'. 9955 9956 'VECTOR_CST_STEPPED_P (V)' is true if at least one pattern in V has 9957 a nonzero step. This is a shorthand for testing 9958 'VECTOR_CST_NELTS_PER_PATTERN (V) == 3'. 9959 9960 The utility function 'vector_cst_elt' gives the value of an 9961 arbitrary index as a 'tree'. 'vector_cst_int_elt' gives the same 9962 value as a 'wide_int'. 9963 9964'STRING_CST' 9965 These nodes represent string-constants. The 'TREE_STRING_LENGTH' 9966 returns the length of the string, as an 'int'. The 9967 'TREE_STRING_POINTER' is a 'char*' containing the string itself. 9968 The string may not be 'NUL'-terminated, and it may contain embedded 9969 'NUL' characters. Therefore, the 'TREE_STRING_LENGTH' includes the 9970 trailing 'NUL' if it is present. 9971 9972 For wide string constants, the 'TREE_STRING_LENGTH' is the number 9973 of bytes in the string, and the 'TREE_STRING_POINTER' points to an 9974 array of the bytes of the string, as represented on the target 9975 system (that is, as integers in the target endianness). Wide and 9976 non-wide string constants are distinguished only by the 'TREE_TYPE' 9977 of the 'STRING_CST'. 9978 9979 FIXME: The formats of string constants are not well-defined when 9980 the target system bytes are not the same width as host system 9981 bytes. 9982 9983'POLY_INT_CST' 9984 These nodes represent invariants that depend on some 9985 target-specific runtime parameters. They consist of 9986 'NUM_POLY_INT_COEFFS' coefficients, with the first coefficient 9987 being the constant term and the others being multipliers that are 9988 applied to the runtime parameters. 9989 9990 'POLY_INT_CST_ELT (X, I)' references coefficient number I of 9991 'POLY_INT_CST' node X. Each coefficient is an 'INTEGER_CST'. 9992 9993 9994File: gccint.info, Node: Storage References, Next: Unary and Binary Expressions, Prev: Constant expressions, Up: Expression trees 9995 999611.6.2 References to storage 9997---------------------------- 9998 9999'ARRAY_REF' 10000 These nodes represent array accesses. The first operand is the 10001 array; the second is the index. To calculate the address of the 10002 memory accessed, you must scale the index by the size of the type 10003 of the array elements. The type of these expressions must be the 10004 type of a component of the array. The third and fourth operands 10005 are used after gimplification to represent the lower bound and 10006 component size but should not be used directly; call 10007 'array_ref_low_bound' and 'array_ref_element_size' instead. 10008 10009'ARRAY_RANGE_REF' 10010 These nodes represent access to a range (or "slice") of an array. 10011 The operands are the same as that for 'ARRAY_REF' and have the same 10012 meanings. The type of these expressions must be an array whose 10013 component type is the same as that of the first operand. The range 10014 of that array type determines the amount of data these expressions 10015 access. 10016 10017'TARGET_MEM_REF' 10018 These nodes represent memory accesses whose address directly map to 10019 an addressing mode of the target architecture. The first argument 10020 is 'TMR_SYMBOL' and must be a 'VAR_DECL' of an object with a fixed 10021 address. The second argument is 'TMR_BASE' and the third one is 10022 'TMR_INDEX'. The fourth argument is 'TMR_STEP' and must be an 10023 'INTEGER_CST'. The fifth argument is 'TMR_OFFSET' and must be an 10024 'INTEGER_CST'. Any of the arguments may be NULL if the appropriate 10025 component does not appear in the address. Address of the 10026 'TARGET_MEM_REF' is determined in the following way. 10027 10028 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET 10029 10030 The sixth argument is the reference to the original memory access, 10031 which is preserved for the purposes of the RTL alias analysis. The 10032 seventh argument is a tag representing the results of tree level 10033 alias analysis. 10034 10035'ADDR_EXPR' 10036 These nodes are used to represent the address of an object. (These 10037 expressions will always have pointer or reference type.) The 10038 operand may be another expression, or it may be a declaration. 10039 10040 As an extension, GCC allows users to take the address of a label. 10041 In this case, the operand of the 'ADDR_EXPR' will be a 10042 'LABEL_DECL'. The type of such an expression is 'void*'. 10043 10044 If the object addressed is not an lvalue, a temporary is created, 10045 and the address of the temporary is used. 10046 10047'INDIRECT_REF' 10048 These nodes are used to represent the object pointed to by a 10049 pointer. The operand is the pointer being dereferenced; it will 10050 always have pointer or reference type. 10051 10052'MEM_REF' 10053 These nodes are used to represent the object pointed to by a 10054 pointer offset by a constant. The first operand is the pointer 10055 being dereferenced; it will always have pointer or reference type. 10056 The second operand is a pointer constant. Its type is specifying 10057 the type to be used for type-based alias analysis. 10058 10059'COMPONENT_REF' 10060 These nodes represent non-static data member accesses. The first 10061 operand is the object (rather than a pointer to it); the second 10062 operand is the 'FIELD_DECL' for the data member. The third operand 10063 represents the byte offset of the field, but should not be used 10064 directly; call 'component_ref_field_offset' instead. 10065 10066 10067File: gccint.info, Node: Unary and Binary Expressions, Next: Vectors, Prev: Storage References, Up: Expression trees 10068 1006911.6.3 Unary and Binary Expressions 10070----------------------------------- 10071 10072'NEGATE_EXPR' 10073 These nodes represent unary negation of the single operand, for 10074 both integer and floating-point types. The type of negation can be 10075 determined by looking at the type of the expression. 10076 10077 The behavior of this operation on signed arithmetic overflow is 10078 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 10079 10080'ABS_EXPR' 10081 These nodes represent the absolute value of the single operand, for 10082 both integer and floating-point types. This is typically used to 10083 implement the 'abs', 'labs' and 'llabs' builtins for integer types, 10084 and the 'fabs', 'fabsf' and 'fabsl' builtins for floating point 10085 types. The type of abs operation can be determined by looking at 10086 the type of the expression. 10087 10088 This node is not used for complex types. To represent the modulus 10089 or complex abs of a complex value, use the 'BUILT_IN_CABS', 10090 'BUILT_IN_CABSF' or 'BUILT_IN_CABSL' builtins, as used to implement 10091 the C99 'cabs', 'cabsf' and 'cabsl' built-in functions. 10092 10093'BIT_NOT_EXPR' 10094 These nodes represent bitwise complement, and will always have 10095 integral type. The only operand is the value to be complemented. 10096 10097'TRUTH_NOT_EXPR' 10098 These nodes represent logical negation, and will always have 10099 integral (or boolean) type. The operand is the value being 10100 negated. The type of the operand and that of the result are always 10101 of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'. 10102 10103'PREDECREMENT_EXPR' 10104'PREINCREMENT_EXPR' 10105'POSTDECREMENT_EXPR' 10106'POSTINCREMENT_EXPR' 10107 These nodes represent increment and decrement expressions. The 10108 value of the single operand is computed, and the operand 10109 incremented or decremented. In the case of 'PREDECREMENT_EXPR' and 10110 'PREINCREMENT_EXPR', the value of the expression is the value 10111 resulting after the increment or decrement; in the case of 10112 'POSTDECREMENT_EXPR' and 'POSTINCREMENT_EXPR' is the value before 10113 the increment or decrement occurs. The type of the operand, like 10114 that of the result, will be either integral, boolean, or 10115 floating-point. 10116 10117'FIX_TRUNC_EXPR' 10118 These nodes represent conversion of a floating-point value to an 10119 integer. The single operand will have a floating-point type, while 10120 the complete expression will have an integral (or boolean) type. 10121 The operand is rounded towards zero. 10122 10123'FLOAT_EXPR' 10124 These nodes represent conversion of an integral (or boolean) value 10125 to a floating-point value. The single operand will have integral 10126 type, while the complete expression will have a floating-point 10127 type. 10128 10129 FIXME: How is the operand supposed to be rounded? Is this 10130 dependent on '-mieee'? 10131 10132'COMPLEX_EXPR' 10133 These nodes are used to represent complex numbers constructed from 10134 two expressions of the same (integer or real) type. The first 10135 operand is the real part and the second operand is the imaginary 10136 part. 10137 10138'CONJ_EXPR' 10139 These nodes represent the conjugate of their operand. 10140 10141'REALPART_EXPR' 10142'IMAGPART_EXPR' 10143 These nodes represent respectively the real and the imaginary parts 10144 of complex numbers (their sole argument). 10145 10146'NON_LVALUE_EXPR' 10147 These nodes indicate that their one and only operand is not an 10148 lvalue. A back end can treat these identically to the single 10149 operand. 10150 10151'NOP_EXPR' 10152 These nodes are used to represent conversions that do not require 10153 any code-generation. For example, conversion of a 'char*' to an 10154 'int*' does not require any code be generated; such a conversion is 10155 represented by a 'NOP_EXPR'. The single operand is the expression 10156 to be converted. The conversion from a pointer to a reference is 10157 also represented with a 'NOP_EXPR'. 10158 10159'CONVERT_EXPR' 10160 These nodes are similar to 'NOP_EXPR's, but are used in those 10161 situations where code may need to be generated. For example, if an 10162 'int*' is converted to an 'int' code may need to be generated on 10163 some platforms. These nodes are never used for C++-specific 10164 conversions, like conversions between pointers to different classes 10165 in an inheritance hierarchy. Any adjustments that need to be made 10166 in such cases are always indicated explicitly. Similarly, a 10167 user-defined conversion is never represented by a 'CONVERT_EXPR'; 10168 instead, the function calls are made explicit. 10169 10170'FIXED_CONVERT_EXPR' 10171 These nodes are used to represent conversions that involve 10172 fixed-point values. For example, from a fixed-point value to 10173 another fixed-point value, from an integer to a fixed-point value, 10174 from a fixed-point value to an integer, from a floating-point value 10175 to a fixed-point value, or from a fixed-point value to a 10176 floating-point value. 10177 10178'LSHIFT_EXPR' 10179'RSHIFT_EXPR' 10180 These nodes represent left and right shifts, respectively. The 10181 first operand is the value to shift; it will always be of integral 10182 type. The second operand is an expression for the number of bits 10183 by which to shift. Right shift should be treated as arithmetic, 10184 i.e., the high-order bits should be zero-filled when the expression 10185 has unsigned type and filled with the sign bit when the expression 10186 has signed type. Note that the result is undefined if the second 10187 operand is larger than or equal to the first operand's type size. 10188 Unlike most nodes, these can have a vector as first operand and a 10189 scalar as second operand. 10190 10191'BIT_IOR_EXPR' 10192'BIT_XOR_EXPR' 10193'BIT_AND_EXPR' 10194 These nodes represent bitwise inclusive or, bitwise exclusive or, 10195 and bitwise and, respectively. Both operands will always have 10196 integral type. 10197 10198'TRUTH_ANDIF_EXPR' 10199'TRUTH_ORIF_EXPR' 10200 These nodes represent logical "and" and logical "or", respectively. 10201 These operators are not strict; i.e., the second operand is 10202 evaluated only if the value of the expression is not determined by 10203 evaluation of the first operand. The type of the operands and that 10204 of the result are always of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'. 10205 10206'TRUTH_AND_EXPR' 10207'TRUTH_OR_EXPR' 10208'TRUTH_XOR_EXPR' 10209 These nodes represent logical and, logical or, and logical 10210 exclusive or. They are strict; both arguments are always 10211 evaluated. There are no corresponding operators in C or C++, but 10212 the front end will sometimes generate these expressions anyhow, if 10213 it can tell that strictness does not matter. The type of the 10214 operands and that of the result are always of 'BOOLEAN_TYPE' or 10215 'INTEGER_TYPE'. 10216 10217'POINTER_PLUS_EXPR' 10218 This node represents pointer arithmetic. The first operand is 10219 always a pointer/reference type. The second operand is always an 10220 unsigned integer type compatible with sizetype. This and 10221 POINTER_DIFF_EXPR are the only binary arithmetic operators that can 10222 operate on pointer types. 10223 10224'POINTER_DIFF_EXPR' 10225 This node represents pointer subtraction. The two operands always 10226 have pointer/reference type. It returns a signed integer of the 10227 same precision as the pointers. The behavior is undefined if the 10228 difference of the two pointers, seen as infinite precision 10229 non-negative integers, does not fit in the result type. The result 10230 does not depend on the pointer type, it is not divided by the size 10231 of the pointed-to type. 10232 10233'PLUS_EXPR' 10234'MINUS_EXPR' 10235'MULT_EXPR' 10236 These nodes represent various binary arithmetic operations. 10237 Respectively, these operations are addition, subtraction (of the 10238 second operand from the first) and multiplication. Their operands 10239 may have either integral or floating type, but there will never be 10240 case in which one operand is of floating type and the other is of 10241 integral type. 10242 10243 The behavior of these operations on signed arithmetic overflow is 10244 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 10245 10246'MULT_HIGHPART_EXPR' 10247 This node represents the "high-part" of a widening multiplication. 10248 For an integral type with B bits of precision, the result is the 10249 most significant B bits of the full 2B product. 10250 10251'RDIV_EXPR' 10252 This node represents a floating point division operation. 10253 10254'TRUNC_DIV_EXPR' 10255'FLOOR_DIV_EXPR' 10256'CEIL_DIV_EXPR' 10257'ROUND_DIV_EXPR' 10258 These nodes represent integer division operations that return an 10259 integer result. 'TRUNC_DIV_EXPR' rounds towards zero, 10260 'FLOOR_DIV_EXPR' rounds towards negative infinity, 'CEIL_DIV_EXPR' 10261 rounds towards positive infinity and 'ROUND_DIV_EXPR' rounds to the 10262 closest integer. Integer division in C and C++ is truncating, i.e. 10263 'TRUNC_DIV_EXPR'. 10264 10265 The behavior of these operations on signed arithmetic overflow, 10266 when dividing the minimum signed integer by minus one, is 10267 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 10268 10269'TRUNC_MOD_EXPR' 10270'FLOOR_MOD_EXPR' 10271'CEIL_MOD_EXPR' 10272'ROUND_MOD_EXPR' 10273 These nodes represent the integer remainder or modulus operation. 10274 The integer modulus of two operands 'a' and 'b' is defined as 'a - 10275 (a/b)*b' where the division calculated using the corresponding 10276 division operator. Hence for 'TRUNC_MOD_EXPR' this definition 10277 assumes division using truncation towards zero, i.e. 10278 'TRUNC_DIV_EXPR'. Integer remainder in C and C++ uses truncating 10279 division, i.e. 'TRUNC_MOD_EXPR'. 10280 10281'EXACT_DIV_EXPR' 10282 The 'EXACT_DIV_EXPR' code is used to represent integer divisions 10283 where the numerator is known to be an exact multiple of the 10284 denominator. This allows the backend to choose between the faster 10285 of 'TRUNC_DIV_EXPR', 'CEIL_DIV_EXPR' and 'FLOOR_DIV_EXPR' for the 10286 current target. 10287 10288'LT_EXPR' 10289'LE_EXPR' 10290'GT_EXPR' 10291'GE_EXPR' 10292'EQ_EXPR' 10293'NE_EXPR' 10294 These nodes represent the less than, less than or equal to, greater 10295 than, greater than or equal to, equal, and not equal comparison 10296 operators. The first and second operands will either be both of 10297 integral type, both of floating type or both of vector type. The 10298 result type of these expressions will always be of integral, 10299 boolean or signed integral vector type. These operations return 10300 the result type's zero value for false, the result type's one value 10301 for true, and a vector whose elements are zero (false) or minus one 10302 (true) for vectors. 10303 10304 For floating point comparisons, if we honor IEEE NaNs and either 10305 operand is NaN, then 'NE_EXPR' always returns true and the 10306 remaining operators always return false. On some targets, 10307 comparisons against an IEEE NaN, other than equality and 10308 inequality, may generate a floating point exception. 10309 10310'ORDERED_EXPR' 10311'UNORDERED_EXPR' 10312 These nodes represent non-trapping ordered and unordered comparison 10313 operators. These operations take two floating point operands and 10314 determine whether they are ordered or unordered relative to each 10315 other. If either operand is an IEEE NaN, their comparison is 10316 defined to be unordered, otherwise the comparison is defined to be 10317 ordered. The result type of these expressions will always be of 10318 integral or boolean type. These operations return the result 10319 type's zero value for false, and the result type's one value for 10320 true. 10321 10322'UNLT_EXPR' 10323'UNLE_EXPR' 10324'UNGT_EXPR' 10325'UNGE_EXPR' 10326'UNEQ_EXPR' 10327'LTGT_EXPR' 10328 These nodes represent the unordered comparison operators. These 10329 operations take two floating point operands and determine whether 10330 the operands are unordered or are less than, less than or equal to, 10331 greater than, greater than or equal to, or equal respectively. For 10332 example, 'UNLT_EXPR' returns true if either operand is an IEEE NaN 10333 or the first operand is less than the second. With the possible 10334 exception of 'LTGT_EXPR', all of these operations are guaranteed 10335 not to generate a floating point exception. The result type of 10336 these expressions will always be of integral or boolean type. 10337 These operations return the result type's zero value for false, and 10338 the result type's one value for true. 10339 10340'MODIFY_EXPR' 10341 These nodes represent assignment. The left-hand side is the first 10342 operand; the right-hand side is the second operand. The left-hand 10343 side will be a 'VAR_DECL', 'INDIRECT_REF', 'COMPONENT_REF', or 10344 other lvalue. 10345 10346 These nodes are used to represent not only assignment with '=' but 10347 also compound assignments (like '+='), by reduction to '=' 10348 assignment. In other words, the representation for 'i += 3' looks 10349 just like that for 'i = i + 3'. 10350 10351'INIT_EXPR' 10352 These nodes are just like 'MODIFY_EXPR', but are used only when a 10353 variable is initialized, rather than assigned to subsequently. 10354 This means that we can assume that the target of the initialization 10355 is not used in computing its own value; any reference to the lhs in 10356 computing the rhs is undefined. 10357 10358'COMPOUND_EXPR' 10359 These nodes represent comma-expressions. The first operand is an 10360 expression whose value is computed and thrown away prior to the 10361 evaluation of the second operand. The value of the entire 10362 expression is the value of the second operand. 10363 10364'COND_EXPR' 10365 These nodes represent '?:' expressions. The first operand is of 10366 boolean or integral type. If it evaluates to a nonzero value, the 10367 second operand should be evaluated, and returned as the value of 10368 the expression. Otherwise, the third operand is evaluated, and 10369 returned as the value of the expression. 10370 10371 The second operand must have the same type as the entire 10372 expression, unless it unconditionally throws an exception or calls 10373 a noreturn function, in which case it should have void type. The 10374 same constraints apply to the third operand. This allows array 10375 bounds checks to be represented conveniently as '(i >= 0 && i < 10) 10376 ? i : abort()'. 10377 10378 As a GNU extension, the C language front-ends allow the second 10379 operand of the '?:' operator may be omitted in the source. For 10380 example, 'x ? : 3' is equivalent to 'x ? x : 3', assuming that 'x' 10381 is an expression without side effects. In the tree representation, 10382 however, the second operand is always present, possibly protected 10383 by 'SAVE_EXPR' if the first argument does cause side effects. 10384 10385'CALL_EXPR' 10386 These nodes are used to represent calls to functions, including 10387 non-static member functions. 'CALL_EXPR's are implemented as 10388 expression nodes with a variable number of operands. Rather than 10389 using 'TREE_OPERAND' to extract them, it is preferable to use the 10390 specialized accessor macros and functions that operate specifically 10391 on 'CALL_EXPR' nodes. 10392 10393 'CALL_EXPR_FN' returns a pointer to the function to call; it is 10394 always an expression whose type is a 'POINTER_TYPE'. 10395 10396 The number of arguments to the call is returned by 10397 'call_expr_nargs', while the arguments themselves can be accessed 10398 with the 'CALL_EXPR_ARG' macro. The arguments are zero-indexed and 10399 numbered left-to-right. You can iterate over the arguments using 10400 'FOR_EACH_CALL_EXPR_ARG', as in: 10401 10402 tree call, arg; 10403 call_expr_arg_iterator iter; 10404 FOR_EACH_CALL_EXPR_ARG (arg, iter, call) 10405 /* arg is bound to successive arguments of call. */ 10406 ...; 10407 10408 For non-static member functions, there will be an operand 10409 corresponding to the 'this' pointer. There will always be 10410 expressions corresponding to all of the arguments, even if the 10411 function is declared with default arguments and some arguments are 10412 not explicitly provided at the call sites. 10413 10414 'CALL_EXPR's also have a 'CALL_EXPR_STATIC_CHAIN' operand that is 10415 used to implement nested functions. This operand is otherwise 10416 null. 10417 10418'CLEANUP_POINT_EXPR' 10419 These nodes represent full-expressions. The single operand is an 10420 expression to evaluate. Any destructor calls engendered by the 10421 creation of temporaries during the evaluation of that expression 10422 should be performed immediately after the expression is evaluated. 10423 10424'CONSTRUCTOR' 10425 These nodes represent the brace-enclosed initializers for a 10426 structure or an array. They contain a sequence of component values 10427 made out of a vector of constructor_elt, which is a ('INDEX', 10428 'VALUE') pair. 10429 10430 If the 'TREE_TYPE' of the 'CONSTRUCTOR' is a 'RECORD_TYPE', 10431 'UNION_TYPE' or 'QUAL_UNION_TYPE' then the 'INDEX' of each node in 10432 the sequence will be a 'FIELD_DECL' and the 'VALUE' will be the 10433 expression used to initialize that field. 10434 10435 If the 'TREE_TYPE' of the 'CONSTRUCTOR' is an 'ARRAY_TYPE', then 10436 the 'INDEX' of each node in the sequence will be an 'INTEGER_CST' 10437 or a 'RANGE_EXPR' of two 'INTEGER_CST's. A single 'INTEGER_CST' 10438 indicates which element of the array is being assigned to. A 10439 'RANGE_EXPR' indicates an inclusive range of elements to 10440 initialize. In both cases the 'VALUE' is the corresponding 10441 initializer. It is re-evaluated for each element of a 10442 'RANGE_EXPR'. If the 'INDEX' is 'NULL_TREE', then the initializer 10443 is for the next available array element. 10444 10445 In the front end, you should not depend on the fields appearing in 10446 any particular order. However, in the middle end, fields must 10447 appear in declaration order. You should not assume that all fields 10448 will be represented. Unrepresented fields will be cleared 10449 (zeroed), unless the CONSTRUCTOR_NO_CLEARING flag is set, in which 10450 case their value becomes undefined. 10451 10452'COMPOUND_LITERAL_EXPR' 10453 These nodes represent ISO C99 compound literals. The 10454 'COMPOUND_LITERAL_EXPR_DECL_EXPR' is a 'DECL_EXPR' containing an 10455 anonymous 'VAR_DECL' for the unnamed object represented by the 10456 compound literal; the 'DECL_INITIAL' of that 'VAR_DECL' is a 10457 'CONSTRUCTOR' representing the brace-enclosed list of initializers 10458 in the compound literal. That anonymous 'VAR_DECL' can also be 10459 accessed directly by the 'COMPOUND_LITERAL_EXPR_DECL' macro. 10460 10461'SAVE_EXPR' 10462 10463 A 'SAVE_EXPR' represents an expression (possibly involving side 10464 effects) that is used more than once. The side effects should 10465 occur only the first time the expression is evaluated. Subsequent 10466 uses should just reuse the computed value. The first operand to 10467 the 'SAVE_EXPR' is the expression to evaluate. The side effects 10468 should be executed where the 'SAVE_EXPR' is first encountered in a 10469 depth-first preorder traversal of the expression tree. 10470 10471'TARGET_EXPR' 10472 A 'TARGET_EXPR' represents a temporary object. The first operand 10473 is a 'VAR_DECL' for the temporary variable. The second operand is 10474 the initializer for the temporary. The initializer is evaluated 10475 and, if non-void, copied (bitwise) into the temporary. If the 10476 initializer is void, that means that it will perform the 10477 initialization itself. 10478 10479 Often, a 'TARGET_EXPR' occurs on the right-hand side of an 10480 assignment, or as the second operand to a comma-expression which is 10481 itself the right-hand side of an assignment, etc. In this case, we 10482 say that the 'TARGET_EXPR' is "normal"; otherwise, we say it is 10483 "orphaned". For a normal 'TARGET_EXPR' the temporary variable 10484 should be treated as an alias for the left-hand side of the 10485 assignment, rather than as a new temporary variable. 10486 10487 The third operand to the 'TARGET_EXPR', if present, is a 10488 cleanup-expression (i.e., destructor call) for the temporary. If 10489 this expression is orphaned, then this expression must be executed 10490 when the statement containing this expression is complete. These 10491 cleanups must always be executed in the order opposite to that in 10492 which they were encountered. Note that if a temporary is created 10493 on one branch of a conditional operator (i.e., in the second or 10494 third operand to a 'COND_EXPR'), the cleanup must be run only if 10495 that branch is actually executed. 10496 10497'VA_ARG_EXPR' 10498 This node is used to implement support for the C/C++ variable 10499 argument-list mechanism. It represents expressions like 'va_arg 10500 (ap, type)'. Its 'TREE_TYPE' yields the tree representation for 10501 'type' and its sole argument yields the representation for 'ap'. 10502 10503'ANNOTATE_EXPR' 10504 This node is used to attach markers to an expression. The first 10505 operand is the annotated expression, the second is an 'INTEGER_CST' 10506 with a value from 'enum annot_expr_kind', the third is an 10507 'INTEGER_CST'. 10508 10509 10510File: gccint.info, Node: Vectors, Prev: Unary and Binary Expressions, Up: Expression trees 10511 1051211.6.4 Vectors 10513-------------- 10514 10515'VEC_DUPLICATE_EXPR' 10516 This node has a single operand and represents a vector in which 10517 every element is equal to that operand. 10518 10519'VEC_SERIES_EXPR' 10520 This node represents a vector formed from a scalar base and step, 10521 given as the first and second operands respectively. Element I of 10522 the result is equal to 'BASE + I*STEP'. 10523 10524 This node is restricted to integral types, in order to avoid 10525 specifying the rounding behavior for floating-point types. 10526 10527'VEC_LSHIFT_EXPR' 10528'VEC_RSHIFT_EXPR' 10529 These nodes represent whole vector left and right shifts, 10530 respectively. The first operand is the vector to shift; it will 10531 always be of vector type. The second operand is an expression for 10532 the number of bits by which to shift. Note that the result is 10533 undefined if the second operand is larger than or equal to the 10534 first operand's type size. 10535 10536'VEC_WIDEN_MULT_HI_EXPR' 10537'VEC_WIDEN_MULT_LO_EXPR' 10538 These nodes represent widening vector multiplication of the high 10539 and low parts of the two input vectors, respectively. Their 10540 operands are vectors that contain the same number of elements ('N') 10541 of the same integral type. The result is a vector that contains 10542 half as many elements, of an integral type whose size is twice as 10543 wide. In the case of 'VEC_WIDEN_MULT_HI_EXPR' the high 'N/2' 10544 elements of the two vector are multiplied to produce the vector of 10545 'N/2' products. In the case of 'VEC_WIDEN_MULT_LO_EXPR' the low 10546 'N/2' elements of the two vector are multiplied to produce the 10547 vector of 'N/2' products. 10548 10549'VEC_UNPACK_HI_EXPR' 10550'VEC_UNPACK_LO_EXPR' 10551 These nodes represent unpacking of the high and low parts of the 10552 input vector, respectively. The single operand is a vector that 10553 contains 'N' elements of the same integral or floating point type. 10554 The result is a vector that contains half as many elements, of an 10555 integral or floating point type whose size is twice as wide. In 10556 the case of 'VEC_UNPACK_HI_EXPR' the high 'N/2' elements of the 10557 vector are extracted and widened (promoted). In the case of 10558 'VEC_UNPACK_LO_EXPR' the low 'N/2' elements of the vector are 10559 extracted and widened (promoted). 10560 10561'VEC_UNPACK_FLOAT_HI_EXPR' 10562'VEC_UNPACK_FLOAT_LO_EXPR' 10563 These nodes represent unpacking of the high and low parts of the 10564 input vector, where the values are converted from fixed point to 10565 floating point. The single operand is a vector that contains 'N' 10566 elements of the same integral type. The result is a vector that 10567 contains half as many elements of a floating point type whose size 10568 is twice as wide. In the case of 'VEC_UNPACK_HI_EXPR' the high 10569 'N/2' elements of the vector are extracted, converted and widened. 10570 In the case of 'VEC_UNPACK_LO_EXPR' the low 'N/2' elements of the 10571 vector are extracted, converted and widened. 10572 10573'VEC_PACK_TRUNC_EXPR' 10574 This node represents packing of truncated elements of the two input 10575 vectors into the output vector. Input operands are vectors that 10576 contain the same number of elements of the same integral or 10577 floating point type. The result is a vector that contains twice as 10578 many elements of an integral or floating point type whose size is 10579 half as wide. The elements of the two vectors are demoted and 10580 merged (concatenated) to form the output vector. 10581 10582'VEC_PACK_SAT_EXPR' 10583 This node represents packing of elements of the two input vectors 10584 into the output vector using saturation. Input operands are 10585 vectors that contain the same number of elements of the same 10586 integral type. The result is a vector that contains twice as many 10587 elements of an integral type whose size is half as wide. The 10588 elements of the two vectors are demoted and merged (concatenated) 10589 to form the output vector. 10590 10591'VEC_PACK_FIX_TRUNC_EXPR' 10592 This node represents packing of elements of the two input vectors 10593 into the output vector, where the values are converted from 10594 floating point to fixed point. Input operands are vectors that 10595 contain the same number of elements of a floating point type. The 10596 result is a vector that contains twice as many elements of an 10597 integral type whose size is half as wide. The elements of the two 10598 vectors are merged (concatenated) to form the output vector. 10599 10600'VEC_COND_EXPR' 10601 These nodes represent '?:' expressions. The three operands must be 10602 vectors of the same size and number of elements. The second and 10603 third operands must have the same type as the entire expression. 10604 The first operand is of signed integral vector type. If an element 10605 of the first operand evaluates to a zero value, the corresponding 10606 element of the result is taken from the third operand. If it 10607 evaluates to a minus one value, it is taken from the second 10608 operand. It should never evaluate to any other value currently, 10609 but optimizations should not rely on that property. In contrast 10610 with a 'COND_EXPR', all operands are always evaluated. 10611 10612'SAD_EXPR' 10613 This node represents the Sum of Absolute Differences operation. 10614 The three operands must be vectors of integral types. The first 10615 and second operand must have the same type. The size of the vector 10616 element of the third operand must be at lease twice of the size of 10617 the vector element of the first and second one. The SAD is 10618 calculated between the first and second operands, added to the 10619 third operand, and returned. 10620 10621 10622File: gccint.info, Node: Statements, Next: Functions, Prev: Expression trees, Up: GENERIC 10623 1062411.7 Statements 10625=============== 10626 10627Most statements in GIMPLE are assignment statements, represented by 10628'GIMPLE_ASSIGN'. No other C expressions can appear at statement level; 10629a reference to a volatile object is converted into a 'GIMPLE_ASSIGN'. 10630 10631 There are also several varieties of complex statements. 10632 10633* Menu: 10634 10635* Basic Statements:: 10636* Blocks:: 10637* Statement Sequences:: 10638* Empty Statements:: 10639* Jumps:: 10640* Cleanups:: 10641* OpenMP:: 10642* OpenACC:: 10643 10644 10645File: gccint.info, Node: Basic Statements, Next: Blocks, Up: Statements 10646 1064711.7.1 Basic Statements 10648----------------------- 10649 10650'ASM_EXPR' 10651 10652 Used to represent an inline assembly statement. For an inline 10653 assembly statement like: 10654 asm ("mov x, y"); 10655 The 'ASM_STRING' macro will return a 'STRING_CST' node for '"mov x, 10656 y"'. If the original statement made use of the extended-assembly 10657 syntax, then 'ASM_OUTPUTS', 'ASM_INPUTS', and 'ASM_CLOBBERS' will 10658 be the outputs, inputs, and clobbers for the statement, represented 10659 as 'STRING_CST' nodes. The extended-assembly syntax looks like: 10660 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); 10661 The first string is the 'ASM_STRING', containing the instruction 10662 template. The next two strings are the output and inputs, 10663 respectively; this statement has no clobbers. As this example 10664 indicates, "plain" assembly statements are merely a special case of 10665 extended assembly statements; they have no cv-qualifiers, outputs, 10666 inputs, or clobbers. All of the strings will be 'NUL'-terminated, 10667 and will contain no embedded 'NUL'-characters. 10668 10669 If the assembly statement is declared 'volatile', or if the 10670 statement was not an extended assembly statement, and is therefore 10671 implicitly volatile, then the predicate 'ASM_VOLATILE_P' will hold 10672 of the 'ASM_EXPR'. 10673 10674'DECL_EXPR' 10675 10676 Used to represent a local declaration. The 'DECL_EXPR_DECL' macro 10677 can be used to obtain the entity declared. This declaration may be 10678 a 'LABEL_DECL', indicating that the label declared is a local 10679 label. (As an extension, GCC allows the declaration of labels with 10680 scope.) In C, this declaration may be a 'FUNCTION_DECL', 10681 indicating the use of the GCC nested function extension. For more 10682 information, *note Functions::. 10683 10684'LABEL_EXPR' 10685 10686 Used to represent a label. The 'LABEL_DECL' declared by this 10687 statement can be obtained with the 'LABEL_EXPR_LABEL' macro. The 10688 'IDENTIFIER_NODE' giving the name of the label can be obtained from 10689 the 'LABEL_DECL' with 'DECL_NAME'. 10690 10691'GOTO_EXPR' 10692 10693 Used to represent a 'goto' statement. The 'GOTO_DESTINATION' will 10694 usually be a 'LABEL_DECL'. However, if the "computed goto" 10695 extension has been used, the 'GOTO_DESTINATION' will be an 10696 arbitrary expression indicating the destination. This expression 10697 will always have pointer type. 10698 10699'RETURN_EXPR' 10700 10701 Used to represent a 'return' statement. Operand 0 represents the 10702 value to return. It should either be the 'RESULT_DECL' for the 10703 containing function, or a 'MODIFY_EXPR' or 'INIT_EXPR' setting the 10704 function's 'RESULT_DECL'. It will be 'NULL_TREE' if the statement 10705 was just 10706 return; 10707 10708'LOOP_EXPR' 10709 These nodes represent "infinite" loops. The 'LOOP_EXPR_BODY' 10710 represents the body of the loop. It should be executed forever, 10711 unless an 'EXIT_EXPR' is encountered. 10712 10713'EXIT_EXPR' 10714 These nodes represent conditional exits from the nearest enclosing 10715 'LOOP_EXPR'. The single operand is the condition; if it is 10716 nonzero, then the loop should be exited. An 'EXIT_EXPR' will only 10717 appear within a 'LOOP_EXPR'. 10718 10719'SWITCH_STMT' 10720 10721 Used to represent a 'switch' statement. The 'SWITCH_STMT_COND' is 10722 the expression on which the switch is occurring. See the 10723 documentation for an 'IF_STMT' for more information on the 10724 representation used for the condition. The 'SWITCH_STMT_BODY' is 10725 the body of the switch statement. The 'SWITCH_STMT_TYPE' is the 10726 original type of switch expression as given in the source, before 10727 any compiler conversions. 10728 10729'CASE_LABEL_EXPR' 10730 10731 Use to represent a 'case' label, range of 'case' labels, or a 10732 'default' label. If 'CASE_LOW' is 'NULL_TREE', then this is a 10733 'default' label. Otherwise, if 'CASE_HIGH' is 'NULL_TREE', then 10734 this is an ordinary 'case' label. In this case, 'CASE_LOW' is an 10735 expression giving the value of the label. Both 'CASE_LOW' and 10736 'CASE_HIGH' are 'INTEGER_CST' nodes. These values will have the 10737 same type as the condition expression in the switch statement. 10738 10739 Otherwise, if both 'CASE_LOW' and 'CASE_HIGH' are defined, the 10740 statement is a range of case labels. Such statements originate 10741 with the extension that allows users to write things of the form: 10742 case 2 ... 5: 10743 The first value will be 'CASE_LOW', while the second will be 10744 'CASE_HIGH'. 10745 10746'DEBUG_BEGIN_STMT' 10747 10748 Marks the beginning of a source statement, for purposes of debug 10749 information generation. 10750 10751 10752File: gccint.info, Node: Blocks, Next: Statement Sequences, Prev: Basic Statements, Up: Statements 10753 1075411.7.2 Blocks 10755------------- 10756 10757Block scopes and the variables they declare in GENERIC are expressed 10758using the 'BIND_EXPR' code, which in previous versions of GCC was 10759primarily used for the C statement-expression extension. 10760 10761 Variables in a block are collected into 'BIND_EXPR_VARS' in declaration 10762order through their 'TREE_CHAIN' field. Any runtime initialization is 10763moved out of 'DECL_INITIAL' and into a statement in the controlled 10764block. When gimplifying from C or C++, this initialization replaces the 10765'DECL_STMT'. These variables will never require cleanups. The scope of 10766these variables is just the body 10767 10768 Variable-length arrays (VLAs) complicate this process, as their size 10769often refers to variables initialized earlier in the block and their 10770initialization involves an explicit stack allocation. To handle this, 10771we add an indirection and replace them with a pointer to stack space 10772allocated by means of 'alloca'. In most cases, we also arrange for this 10773space to be reclaimed when the enclosing 'BIND_EXPR' is exited, the 10774exception to this being when there is an explicit call to 'alloca' in 10775the source code, in which case the stack is left depressed on exit of 10776the 'BIND_EXPR'. 10777 10778 A C++ program will usually contain more 'BIND_EXPR's than there are 10779syntactic blocks in the source code, since several C++ constructs have 10780implicit scopes associated with them. On the other hand, although the 10781C++ front end uses pseudo-scopes to handle cleanups for objects with 10782destructors, these don't translate into the GIMPLE form; multiple 10783declarations at the same level use the same 'BIND_EXPR'. 10784 10785 10786File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements 10787 1078811.7.3 Statement Sequences 10789-------------------------- 10790 10791Multiple statements at the same nesting level are collected into a 10792'STATEMENT_LIST'. Statement lists are modified and traversed using the 10793interface in 'tree-iterator.h'. 10794 10795 10796File: gccint.info, Node: Empty Statements, Next: Jumps, Prev: Statement Sequences, Up: Statements 10797 1079811.7.4 Empty Statements 10799----------------------- 10800 10801Whenever possible, statements with no effect are discarded. But if they 10802are nested within another construct which cannot be discarded for some 10803reason, they are instead replaced with an empty statement, generated by 10804'build_empty_stmt'. Initially, all empty statements were shared, after 10805the pattern of the Java front end, but this caused a lot of trouble in 10806practice. 10807 10808 An empty statement is represented as '(void)0'. 10809 10810 10811File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Empty Statements, Up: Statements 10812 1081311.7.5 Jumps 10814------------ 10815 10816Other jumps are expressed by either 'GOTO_EXPR' or 'RETURN_EXPR'. 10817 10818 The operand of a 'GOTO_EXPR' must be either a label or a variable 10819containing the address to jump to. 10820 10821 The operand of a 'RETURN_EXPR' is either 'NULL_TREE', 'RESULT_DECL', or 10822a 'MODIFY_EXPR' which sets the return value. It would be nice to move 10823the 'MODIFY_EXPR' into a separate statement, but the special return 10824semantics in 'expand_return' make that difficult. It may still happen 10825in the future, perhaps by moving most of that logic into 10826'expand_assignment'. 10827 10828 10829File: gccint.info, Node: Cleanups, Next: OpenMP, Prev: Jumps, Up: Statements 10830 1083111.7.6 Cleanups 10832--------------- 10833 10834Destructors for local C++ objects and similar dynamic cleanups are 10835represented in GIMPLE by a 'TRY_FINALLY_EXPR'. 'TRY_FINALLY_EXPR' has 10836two operands, both of which are a sequence of statements to execute. 10837The first sequence is executed. When it completes the second sequence 10838is executed. 10839 10840 The first sequence may complete in the following ways: 10841 10842 1. Execute the last statement in the sequence and fall off the end. 10843 10844 2. Execute a goto statement ('GOTO_EXPR') to an ordinary label outside 10845 the sequence. 10846 10847 3. Execute a return statement ('RETURN_EXPR'). 10848 10849 4. Throw an exception. This is currently not explicitly represented 10850 in GIMPLE. 10851 10852 The second sequence is not executed if the first sequence completes by 10853calling 'setjmp' or 'exit' or any other function that does not return. 10854The second sequence is also not executed if the first sequence completes 10855via a non-local goto or a computed goto (in general the compiler does 10856not know whether such a goto statement exits the first sequence or not, 10857so we assume that it doesn't). 10858 10859 After the second sequence is executed, if it completes normally by 10860falling off the end, execution continues wherever the first sequence 10861would have continued, by falling off the end, or doing a goto, etc. 10862 10863 'TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs 10864to appear on every edge out of the controlled block; this reduces the 10865freedom to move code across these edges. Therefore, the EH lowering 10866pass which runs before most of the optimization passes eliminates these 10867expressions by explicitly adding the cleanup to each edge. Rethrowing 10868the exception is represented using 'RESX_EXPR'. 10869 10870 10871File: gccint.info, Node: OpenMP, Next: OpenACC, Prev: Cleanups, Up: Statements 10872 1087311.7.7 OpenMP 10874------------- 10875 10876All the statements starting with 'OMP_' represent directives and clauses 10877used by the OpenMP API <http://www.openmp.org/>. 10878 10879'OMP_PARALLEL' 10880 10881 Represents '#pragma omp parallel [clause1 ... clauseN]'. It has 10882 four operands: 10883 10884 Operand 'OMP_PARALLEL_BODY' is valid while in GENERIC and High 10885 GIMPLE forms. It contains the body of code to be executed by all 10886 the threads. During GIMPLE lowering, this operand becomes 'NULL' 10887 and the body is emitted linearly after 'OMP_PARALLEL'. 10888 10889 Operand 'OMP_PARALLEL_CLAUSES' is the list of clauses associated 10890 with the directive. 10891 10892 Operand 'OMP_PARALLEL_FN' is created by 'pass_lower_omp', it 10893 contains the 'FUNCTION_DECL' for the function that will contain the 10894 body of the parallel region. 10895 10896 Operand 'OMP_PARALLEL_DATA_ARG' is also created by 10897 'pass_lower_omp'. If there are shared variables to be communicated 10898 to the children threads, this operand will contain the 'VAR_DECL' 10899 that contains all the shared values and variables. 10900 10901'OMP_FOR' 10902 10903 Represents '#pragma omp for [clause1 ... clauseN]'. It has six 10904 operands: 10905 10906 Operand 'OMP_FOR_BODY' contains the loop body. 10907 10908 Operand 'OMP_FOR_CLAUSES' is the list of clauses associated with 10909 the directive. 10910 10911 Operand 'OMP_FOR_INIT' is the loop initialization code of the form 10912 'VAR = N1'. 10913 10914 Operand 'OMP_FOR_COND' is the loop conditional expression of the 10915 form 'VAR {<,>,<=,>=} N2'. 10916 10917 Operand 'OMP_FOR_INCR' is the loop index increment of the form 'VAR 10918 {+=,-=} INCR'. 10919 10920 Operand 'OMP_FOR_PRE_BODY' contains side effect code from operands 10921 'OMP_FOR_INIT', 'OMP_FOR_COND' and 'OMP_FOR_INC'. These side 10922 effects are part of the 'OMP_FOR' block but must be evaluated 10923 before the start of loop body. 10924 10925 The loop index variable 'VAR' must be a signed integer variable, 10926 which is implicitly private to each thread. Bounds 'N1' and 'N2' 10927 and the increment expression 'INCR' are required to be loop 10928 invariant integer expressions that are evaluated without any 10929 synchronization. The evaluation order, frequency of evaluation and 10930 side effects are unspecified by the standard. 10931 10932'OMP_SECTIONS' 10933 10934 Represents '#pragma omp sections [clause1 ... clauseN]'. 10935 10936 Operand 'OMP_SECTIONS_BODY' contains the sections body, which in 10937 turn contains a set of 'OMP_SECTION' nodes for each of the 10938 concurrent sections delimited by '#pragma omp section'. 10939 10940 Operand 'OMP_SECTIONS_CLAUSES' is the list of clauses associated 10941 with the directive. 10942 10943'OMP_SECTION' 10944 10945 Section delimiter for 'OMP_SECTIONS'. 10946 10947'OMP_SINGLE' 10948 10949 Represents '#pragma omp single'. 10950 10951 Operand 'OMP_SINGLE_BODY' contains the body of code to be executed 10952 by a single thread. 10953 10954 Operand 'OMP_SINGLE_CLAUSES' is the list of clauses associated with 10955 the directive. 10956 10957'OMP_MASTER' 10958 10959 Represents '#pragma omp master'. 10960 10961 Operand 'OMP_MASTER_BODY' contains the body of code to be executed 10962 by the master thread. 10963 10964'OMP_ORDERED' 10965 10966 Represents '#pragma omp ordered'. 10967 10968 Operand 'OMP_ORDERED_BODY' contains the body of code to be executed 10969 in the sequential order dictated by the loop index variable. 10970 10971'OMP_CRITICAL' 10972 10973 Represents '#pragma omp critical [name]'. 10974 10975 Operand 'OMP_CRITICAL_BODY' is the critical section. 10976 10977 Operand 'OMP_CRITICAL_NAME' is an optional identifier to label the 10978 critical section. 10979 10980'OMP_RETURN' 10981 10982 This does not represent any OpenMP directive, it is an artificial 10983 marker to indicate the end of the body of an OpenMP. It is used by 10984 the flow graph ('tree-cfg.c') and OpenMP region building code 10985 ('omp-low.c'). 10986 10987'OMP_CONTINUE' 10988 10989 Similarly, this instruction does not represent an OpenMP directive, 10990 it is used by 'OMP_FOR' (and similar codes) as well as 10991 'OMP_SECTIONS' to mark the place where the code needs to loop to 10992 the next iteration, or the next section, respectively. 10993 10994 In some cases, 'OMP_CONTINUE' is placed right before 'OMP_RETURN'. 10995 But if there are cleanups that need to occur right after the 10996 looping body, it will be emitted between 'OMP_CONTINUE' and 10997 'OMP_RETURN'. 10998 10999'OMP_ATOMIC' 11000 11001 Represents '#pragma omp atomic'. 11002 11003 Operand 0 is the address at which the atomic operation is to be 11004 performed. 11005 11006 Operand 1 is the expression to evaluate. The gimplifier tries 11007 three alternative code generation strategies. Whenever possible, 11008 an atomic update built-in is used. If that fails, a 11009 compare-and-swap loop is attempted. If that also fails, a regular 11010 critical section around the expression is used. 11011 11012'OMP_CLAUSE' 11013 11014 Represents clauses associated with one of the 'OMP_' directives. 11015 Clauses are represented by separate subcodes defined in 'tree.h'. 11016 Clauses codes can be one of: 'OMP_CLAUSE_PRIVATE', 11017 'OMP_CLAUSE_SHARED', 'OMP_CLAUSE_FIRSTPRIVATE', 11018 'OMP_CLAUSE_LASTPRIVATE', 'OMP_CLAUSE_COPYIN', 11019 'OMP_CLAUSE_COPYPRIVATE', 'OMP_CLAUSE_IF', 11020 'OMP_CLAUSE_NUM_THREADS', 'OMP_CLAUSE_SCHEDULE', 11021 'OMP_CLAUSE_NOWAIT', 'OMP_CLAUSE_ORDERED', 'OMP_CLAUSE_DEFAULT', 11022 'OMP_CLAUSE_REDUCTION', 'OMP_CLAUSE_COLLAPSE', 'OMP_CLAUSE_UNTIED', 11023 'OMP_CLAUSE_FINAL', and 'OMP_CLAUSE_MERGEABLE'. Each code 11024 represents the corresponding OpenMP clause. 11025 11026 Clauses associated with the same directive are chained together via 11027 'OMP_CLAUSE_CHAIN'. Those clauses that accept a list of variables 11028 are restricted to exactly one, accessed with 'OMP_CLAUSE_VAR'. 11029 Therefore, multiple variables under the same clause 'C' need to be 11030 represented as multiple 'C' clauses chained together. This 11031 facilitates adding new clauses during compilation. 11032 11033 11034File: gccint.info, Node: OpenACC, Prev: OpenMP, Up: Statements 11035 1103611.7.8 OpenACC 11037-------------- 11038 11039All the statements starting with 'OACC_' represent directives and 11040clauses used by the OpenACC API <https://www.openacc.org>. 11041 11042'OACC_CACHE' 11043 11044 Represents '#pragma acc cache (var ...)'. 11045 11046'OACC_DATA' 11047 11048 Represents '#pragma acc data [clause1 ... clauseN]'. 11049 11050'OACC_DECLARE' 11051 11052 Represents '#pragma acc declare [clause1 ... clauseN]'. 11053 11054'OACC_ENTER_DATA' 11055 11056 Represents '#pragma acc enter data [clause1 ... clauseN]'. 11057 11058'OACC_EXIT_DATA' 11059 11060 Represents '#pragma acc exit data [clause1 ... clauseN]'. 11061 11062'OACC_HOST_DATA' 11063 11064 Represents '#pragma acc host_data [clause1 ... clauseN]'. 11065 11066'OACC_KERNELS' 11067 11068 Represents '#pragma acc kernels [clause1 ... clauseN]'. 11069 11070'OACC_LOOP' 11071 11072 Represents '#pragma acc loop [clause1 ... clauseN]'. 11073 11074 See the description of the 'OMP_FOR' code. 11075 11076'OACC_PARALLEL' 11077 11078 Represents '#pragma acc parallel [clause1 ... clauseN]'. 11079 11080'OACC_UPDATE' 11081 11082 Represents '#pragma acc update [clause1 ... clauseN]'. 11083 11084 11085File: gccint.info, Node: Functions, Next: Language-dependent trees, Prev: Statements, Up: GENERIC 11086 1108711.8 Functions 11088============== 11089 11090A function is represented by a 'FUNCTION_DECL' node. It stores the 11091basic pieces of the function such as body, parameters, and return type 11092as well as information on the surrounding context, visibility, and 11093linkage. 11094 11095* Menu: 11096 11097* Function Basics:: Function names, body, and parameters. 11098* Function Properties:: Context, linkage, etc. 11099 11100 11101File: gccint.info, Node: Function Basics, Next: Function Properties, Up: Functions 11102 1110311.8.1 Function Basics 11104---------------------- 11105 11106A function has four core parts: the name, the parameters, the result, 11107and the body. The following macros and functions access these parts of 11108a 'FUNCTION_DECL' as well as other basic features: 11109'DECL_NAME' 11110 This macro returns the unqualified name of the function, as an 11111 'IDENTIFIER_NODE'. For an instantiation of a function template, 11112 the 'DECL_NAME' is the unqualified name of the template, not 11113 something like 'f<int>'. The value of 'DECL_NAME' is undefined 11114 when used on a constructor, destructor, overloaded operator, or 11115 type-conversion operator, or any function that is implicitly 11116 generated by the compiler. See below for macros that can be used 11117 to distinguish these cases. 11118 11119'DECL_ASSEMBLER_NAME' 11120 This macro returns the mangled name of the function, also an 11121 'IDENTIFIER_NODE'. This name does not contain leading underscores 11122 on systems that prefix all identifiers with underscores. The 11123 mangled name is computed in the same way on all platforms; if 11124 special processing is required to deal with the object file format 11125 used on a particular platform, it is the responsibility of the back 11126 end to perform those modifications. (Of course, the back end 11127 should not modify 'DECL_ASSEMBLER_NAME' itself.) 11128 11129 Using 'DECL_ASSEMBLER_NAME' will cause additional memory to be 11130 allocated (for the mangled name of the entity) so it should be used 11131 only when emitting assembly code. It should not be used within the 11132 optimizers to determine whether or not two declarations are the 11133 same, even though some of the existing optimizers do use it in that 11134 way. These uses will be removed over time. 11135 11136'DECL_ARGUMENTS' 11137 This macro returns the 'PARM_DECL' for the first argument to the 11138 function. Subsequent 'PARM_DECL' nodes can be obtained by 11139 following the 'TREE_CHAIN' links. 11140 11141'DECL_RESULT' 11142 This macro returns the 'RESULT_DECL' for the function. 11143 11144'DECL_SAVED_TREE' 11145 This macro returns the complete body of the function. 11146 11147'TREE_TYPE' 11148 This macro returns the 'FUNCTION_TYPE' or 'METHOD_TYPE' for the 11149 function. 11150 11151'DECL_INITIAL' 11152 A function that has a definition in the current translation unit 11153 will have a non-'NULL' 'DECL_INITIAL'. However, back ends should 11154 not make use of the particular value given by 'DECL_INITIAL'. 11155 11156 It should contain a tree of 'BLOCK' nodes that mirrors the scopes 11157 that variables are bound in the function. Each block contains a 11158 list of decls declared in a basic block, a pointer to a chain of 11159 blocks at the next lower scope level, then a pointer to the next 11160 block at the same level and a backpointer to the parent 'BLOCK' or 11161 'FUNCTION_DECL'. So given a function as follows: 11162 11163 void foo() 11164 { 11165 int a; 11166 { 11167 int b; 11168 } 11169 int c; 11170 } 11171 11172 you would get the following: 11173 11174 tree foo = FUNCTION_DECL; 11175 tree decl_a = VAR_DECL; 11176 tree decl_b = VAR_DECL; 11177 tree decl_c = VAR_DECL; 11178 tree block_a = BLOCK; 11179 tree block_b = BLOCK; 11180 tree block_c = BLOCK; 11181 BLOCK_VARS(block_a) = decl_a; 11182 BLOCK_SUBBLOCKS(block_a) = block_b; 11183 BLOCK_CHAIN(block_a) = block_c; 11184 BLOCK_SUPERCONTEXT(block_a) = foo; 11185 BLOCK_VARS(block_b) = decl_b; 11186 BLOCK_SUPERCONTEXT(block_b) = block_a; 11187 BLOCK_VARS(block_c) = decl_c; 11188 BLOCK_SUPERCONTEXT(block_c) = foo; 11189 DECL_INITIAL(foo) = block_a; 11190 11191 11192File: gccint.info, Node: Function Properties, Prev: Function Basics, Up: Functions 11193 1119411.8.2 Function Properties 11195-------------------------- 11196 11197To determine the scope of a function, you can use the 'DECL_CONTEXT' 11198macro. This macro will return the class (either a 'RECORD_TYPE' or a 11199'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is 11200a member. For a virtual function, this macro returns the class in which 11201the function was actually defined, not the base class in which the 11202virtual declaration occurred. 11203 11204 In C, the 'DECL_CONTEXT' for a function maybe another function. This 11205representation indicates that the GNU nested function extension is in 11206use. For details on the semantics of nested functions, see the GCC 11207Manual. The nested function can refer to local variables in its 11208containing function. Such references are not explicitly marked in the 11209tree structure; back ends must look at the 'DECL_CONTEXT' for the 11210referenced 'VAR_DECL'. If the 'DECL_CONTEXT' for the referenced 11211'VAR_DECL' is not the same as the function currently being processed, 11212and neither 'DECL_EXTERNAL' nor 'TREE_STATIC' hold, then the reference 11213is to a local variable in a containing function, and the back end must 11214take appropriate action. 11215 11216'DECL_EXTERNAL' 11217 This predicate holds if the function is undefined. 11218 11219'TREE_PUBLIC' 11220 This predicate holds if the function has external linkage. 11221 11222'TREE_STATIC' 11223 This predicate holds if the function has been defined. 11224 11225'TREE_THIS_VOLATILE' 11226 This predicate holds if the function does not return normally. 11227 11228'TREE_READONLY' 11229 This predicate holds if the function can only read its arguments. 11230 11231'DECL_PURE_P' 11232 This predicate holds if the function can only read its arguments, 11233 but may also read global memory. 11234 11235'DECL_VIRTUAL_P' 11236 This predicate holds if the function is virtual. 11237 11238'DECL_ARTIFICIAL' 11239 This macro holds if the function was implicitly generated by the 11240 compiler, rather than explicitly declared. In addition to 11241 implicitly generated class member functions, this macro holds for 11242 the special functions created to implement static initialization 11243 and destruction, to compute run-time type information, and so 11244 forth. 11245 11246'DECL_FUNCTION_SPECIFIC_TARGET' 11247 This macro returns a tree node that holds the target options that 11248 are to be used to compile this particular function or 'NULL_TREE' 11249 if the function is to be compiled with the target options specified 11250 on the command line. 11251 11252'DECL_FUNCTION_SPECIFIC_OPTIMIZATION' 11253 This macro returns a tree node that holds the optimization options 11254 that are to be used to compile this particular function or 11255 'NULL_TREE' if the function is to be compiled with the optimization 11256 options specified on the command line. 11257 11258 11259File: gccint.info, Node: Language-dependent trees, Next: C and C++ Trees, Prev: Functions, Up: GENERIC 11260 1126111.9 Language-dependent trees 11262============================= 11263 11264Front ends may wish to keep some state associated with various GENERIC 11265trees while parsing. To support this, trees provide a set of flags that 11266may be used by the front end. They are accessed using 11267'TREE_LANG_FLAG_n' where 'n' is currently 0 through 6. 11268 11269 If necessary, a front end can use some language-dependent tree codes in 11270its GENERIC representation, so long as it provides a hook for converting 11271them to GIMPLE and doesn't expect them to work with any (hypothetical) 11272optimizers that run before the conversion to GIMPLE. The intermediate 11273representation used while parsing C and C++ looks very little like 11274GENERIC, but the C and C++ gimplifier hooks are perfectly happy to take 11275it as input and spit out GIMPLE. 11276 11277 11278File: gccint.info, Node: C and C++ Trees, Next: Java Trees, Prev: Language-dependent trees, Up: GENERIC 11279 1128011.10 C and C++ Trees 11281===================== 11282 11283This section documents the internal representation used by GCC to 11284represent C and C++ source programs. When presented with a C or C++ 11285source program, GCC parses the program, performs semantic analysis 11286(including the generation of error messages), and then produces the 11287internal representation described here. This representation contains a 11288complete representation for the entire translation unit provided as 11289input to the front end. This representation is then typically processed 11290by a code-generator in order to produce machine code, but could also be 11291used in the creation of source browsers, intelligent editors, automatic 11292documentation generators, interpreters, and any other programs needing 11293the ability to process C or C++ code. 11294 11295 This section explains the internal representation. In particular, it 11296documents the internal representation for C and C++ source constructs, 11297and the macros, functions, and variables that can be used to access 11298these constructs. The C++ representation is largely a superset of the 11299representation used in the C front end. There is only one construct 11300used in C that does not appear in the C++ front end and that is the GNU 11301"nested function" extension. Many of the macros documented here do not 11302apply in C because the corresponding language constructs do not appear 11303in C. 11304 11305 The C and C++ front ends generate a mix of GENERIC trees and ones 11306specific to C and C++. These language-specific trees are higher-level 11307constructs than the ones in GENERIC to make the parser's job easier. 11308This section describes those trees that aren't part of GENERIC as well 11309as aspects of GENERIC trees that are treated in a language-specific 11310manner. 11311 11312 If you are developing a "back end", be it is a code-generator or some 11313other tool, that uses this representation, you may occasionally find 11314that you need to ask questions not easily answered by the functions and 11315macros available here. If that situation occurs, it is quite likely 11316that GCC already supports the functionality you desire, but that the 11317interface is simply not documented here. In that case, you should ask 11318the GCC maintainers (via mail to <gcc@gcc.gnu.org>) about documenting 11319the functionality you require. Similarly, if you find yourself writing 11320functions that do not deal directly with your back end, but instead 11321might be useful to other people using the GCC front end, you should 11322submit your patches for inclusion in GCC. 11323 11324* Menu: 11325 11326* Types for C++:: Fundamental and aggregate types. 11327* Namespaces:: Namespaces. 11328* Classes:: Classes. 11329* Functions for C++:: Overloading and accessors for C++. 11330* Statements for C++:: Statements specific to C and C++. 11331* C++ Expressions:: From 'typeid' to 'throw'. 11332 11333 11334File: gccint.info, Node: Types for C++, Next: Namespaces, Up: C and C++ Trees 11335 1133611.10.1 Types for C++ 11337--------------------- 11338 11339In C++, an array type is not qualified; rather the type of the array 11340elements is qualified. This situation is reflected in the intermediate 11341representation. The macros described here will always examine the 11342qualification of the underlying element type when applied to an array 11343type. (If the element type is itself an array, then the recursion 11344continues until a non-array type is found, and the qualification of this 11345type is examined.) So, for example, 'CP_TYPE_CONST_P' will hold of the 11346type 'const int ()[7]', denoting an array of seven 'int's. 11347 11348 The following functions and macros deal with cv-qualification of types: 11349'cp_type_quals' 11350 This function returns the set of type qualifiers applied to this 11351 type. This value is 'TYPE_UNQUALIFIED' if no qualifiers have been 11352 applied. The 'TYPE_QUAL_CONST' bit is set if the type is 11353 'const'-qualified. The 'TYPE_QUAL_VOLATILE' bit is set if the type 11354 is 'volatile'-qualified. The 'TYPE_QUAL_RESTRICT' bit is set if 11355 the type is 'restrict'-qualified. 11356 11357'CP_TYPE_CONST_P' 11358 This macro holds if the type is 'const'-qualified. 11359 11360'CP_TYPE_VOLATILE_P' 11361 This macro holds if the type is 'volatile'-qualified. 11362 11363'CP_TYPE_RESTRICT_P' 11364 This macro holds if the type is 'restrict'-qualified. 11365 11366'CP_TYPE_CONST_NON_VOLATILE_P' 11367 This predicate holds for a type that is 'const'-qualified, but 11368 _not_ 'volatile'-qualified; other cv-qualifiers are ignored as 11369 well: only the 'const'-ness is tested. 11370 11371 A few other macros and functions are usable with all types: 11372'TYPE_SIZE' 11373 The number of bits required to represent the type, represented as 11374 an 'INTEGER_CST'. For an incomplete type, 'TYPE_SIZE' will be 11375 'NULL_TREE'. 11376 11377'TYPE_ALIGN' 11378 The alignment of the type, in bits, represented as an 'int'. 11379 11380'TYPE_NAME' 11381 This macro returns a declaration (in the form of a 'TYPE_DECL') for 11382 the type. (Note this macro does _not_ return an 'IDENTIFIER_NODE', 11383 as you might expect, given its name!) You can look at the 11384 'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the 11385 type. The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a 11386 built-in type, the result of a typedef, or a named class type. 11387 11388'CP_INTEGRAL_TYPE' 11389 This predicate holds if the type is an integral type. Notice that 11390 in C++, enumerations are _not_ integral types. 11391 11392'ARITHMETIC_TYPE_P' 11393 This predicate holds if the type is an integral type (in the C++ 11394 sense) or a floating point type. 11395 11396'CLASS_TYPE_P' 11397 This predicate holds for a class-type. 11398 11399'TYPE_BUILT_IN' 11400 This predicate holds for a built-in type. 11401 11402'TYPE_PTRDATAMEM_P' 11403 This predicate holds if the type is a pointer to data member. 11404 11405'TYPE_PTR_P' 11406 This predicate holds if the type is a pointer type, and the pointee 11407 is not a data member. 11408 11409'TYPE_PTRFN_P' 11410 This predicate holds for a pointer to function type. 11411 11412'TYPE_PTROB_P' 11413 This predicate holds for a pointer to object type. Note however 11414 that it does not hold for the generic pointer to object type 'void 11415 *'. You may use 'TYPE_PTROBV_P' to test for a pointer to object 11416 type as well as 'void *'. 11417 11418 The table below describes types specific to C and C++ as well as 11419language-dependent info about GENERIC types. 11420 11421'POINTER_TYPE' 11422 Used to represent pointer types, and pointer to data member types. 11423 If 'TREE_TYPE' is a pointer to data member type, then 11424 'TYPE_PTRDATAMEM_P' will hold. For a pointer to data member type 11425 of the form 'T X::*', 'TYPE_PTRMEM_CLASS_TYPE' will be the type 11426 'X', while 'TYPE_PTRMEM_POINTED_TO_TYPE' will be the type 'T'. 11427 11428'RECORD_TYPE' 11429 Used to represent 'struct' and 'class' types in C and C++. If 11430 'TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member 11431 type. In that case, the 'TYPE_PTRMEMFUNC_FN_TYPE' is a 11432 'POINTER_TYPE' pointing to a 'METHOD_TYPE'. The 'METHOD_TYPE' is 11433 the type of a function pointed to by the pointer-to-member 11434 function. If 'TYPE_PTRMEMFUNC_P' does not hold, this type is a 11435 class type. For more information, *note Classes::. 11436 11437'UNKNOWN_TYPE' 11438 This node is used to represent a type the knowledge of which is 11439 insufficient for a sound processing. 11440 11441'TYPENAME_TYPE' 11442 Used to represent a construct of the form 'typename T::A'. The 11443 'TYPE_CONTEXT' is 'T'; the 'TYPE_NAME' is an 'IDENTIFIER_NODE' for 11444 'A'. If the type is specified via a template-id, then 11445 'TYPENAME_TYPE_FULLNAME' yields a 'TEMPLATE_ID_EXPR'. The 11446 'TREE_TYPE' is non-'NULL' if the node is implicitly generated in 11447 support for the implicit typename extension; in which case the 11448 'TREE_TYPE' is a type node for the base-class. 11449 11450'TYPEOF_TYPE' 11451 Used to represent the '__typeof__' extension. The 'TYPE_FIELDS' is 11452 the expression the type of which is being represented. 11453 11454 11455File: gccint.info, Node: Namespaces, Next: Classes, Prev: Types for C++, Up: C and C++ Trees 11456 1145711.10.2 Namespaces 11458------------------ 11459 11460The root of the entire intermediate representation is the variable 11461'global_namespace'. This is the namespace specified with '::' in C++ 11462source code. All other namespaces, types, variables, functions, and so 11463forth can be found starting with this namespace. 11464 11465 However, except for the fact that it is distinguished as the root of 11466the representation, the global namespace is no different from any other 11467namespace. Thus, in what follows, we describe namespaces generally, 11468rather than the global namespace in particular. 11469 11470 A namespace is represented by a 'NAMESPACE_DECL' node. 11471 11472 The following macros and functions can be used on a 'NAMESPACE_DECL': 11473 11474'DECL_NAME' 11475 This macro is used to obtain the 'IDENTIFIER_NODE' corresponding to 11476 the unqualified name of the name of the namespace (*note 11477 Identifiers::). The name of the global namespace is '::', even 11478 though in C++ the global namespace is unnamed. However, you should 11479 use comparison with 'global_namespace', rather than 'DECL_NAME' to 11480 determine whether or not a namespace is the global one. An unnamed 11481 namespace will have a 'DECL_NAME' equal to 11482 'anonymous_namespace_name'. Within a single translation unit, all 11483 unnamed namespaces will have the same name. 11484 11485'DECL_CONTEXT' 11486 This macro returns the enclosing namespace. The 'DECL_CONTEXT' for 11487 the 'global_namespace' is 'NULL_TREE'. 11488 11489'DECL_NAMESPACE_ALIAS' 11490 If this declaration is for a namespace alias, then 11491 'DECL_NAMESPACE_ALIAS' is the namespace for which this one is an 11492 alias. 11493 11494 Do not attempt to use 'cp_namespace_decls' for a namespace which is 11495 an alias. Instead, follow 'DECL_NAMESPACE_ALIAS' links until you 11496 reach an ordinary, non-alias, namespace, and call 11497 'cp_namespace_decls' there. 11498 11499'DECL_NAMESPACE_STD_P' 11500 This predicate holds if the namespace is the special '::std' 11501 namespace. 11502 11503'cp_namespace_decls' 11504 This function will return the declarations contained in the 11505 namespace, including types, overloaded functions, other namespaces, 11506 and so forth. If there are no declarations, this function will 11507 return 'NULL_TREE'. The declarations are connected through their 11508 'TREE_CHAIN' fields. 11509 11510 Although most entries on this list will be declarations, 11511 'TREE_LIST' nodes may also appear. In this case, the 'TREE_VALUE' 11512 will be an 'OVERLOAD'. The value of the 'TREE_PURPOSE' is 11513 unspecified; back ends should ignore this value. As with the other 11514 kinds of declarations returned by 'cp_namespace_decls', the 11515 'TREE_CHAIN' will point to the next declaration in this list. 11516 11517 For more information on the kinds of declarations that can occur on 11518 this list, *Note Declarations::. Some declarations will not appear 11519 on this list. In particular, no 'FIELD_DECL', 'LABEL_DECL', or 11520 'PARM_DECL' nodes will appear here. 11521 11522 This function cannot be used with namespaces that have 11523 'DECL_NAMESPACE_ALIAS' set. 11524 11525 11526File: gccint.info, Node: Classes, Next: Functions for C++, Prev: Namespaces, Up: C and C++ Trees 11527 1152811.10.3 Classes 11529--------------- 11530 11531Besides namespaces, the other high-level scoping construct in C++ is the 11532class. (Throughout this manual the term "class" is used to mean the 11533types referred to in the ANSI/ISO C++ Standard as classes; these include 11534types defined with the 'class', 'struct', and 'union' keywords.) 11535 11536 A class type is represented by either a 'RECORD_TYPE' or a 11537'UNION_TYPE'. A class declared with the 'union' tag is represented by a 11538'UNION_TYPE', while classes declared with either the 'struct' or the 11539'class' tag are represented by 'RECORD_TYPE's. You can use the 11540'CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular 11541type is a 'class' as opposed to a 'struct'. This macro will be true 11542only for classes declared with the 'class' tag. 11543 11544 Almost all members are available on the 'TYPE_FIELDS' list. Given one 11545member, the next can be found by following the 'TREE_CHAIN'. You should 11546not depend in any way on the order in which fields appear on this list. 11547All nodes on this list will be 'DECL' nodes. A 'FIELD_DECL' is used to 11548represent a non-static data member, a 'VAR_DECL' is used to represent a 11549static data member, and a 'TYPE_DECL' is used to represent a type. Note 11550that the 'CONST_DECL' for an enumeration constant will appear on this 11551list, if the enumeration type was declared in the class. (Of course, 11552the 'TYPE_DECL' for the enumeration type will appear here as well.) 11553There are no entries for base classes on this list. In particular, 11554there is no 'FIELD_DECL' for the "base-class portion" of an object. If 11555a function member is overloaded, each of the overloaded functions 11556appears; no 'OVERLOAD' nodes appear on the 'TYPE_FIELDS' list. 11557Implicitly declared functions (including default constructors, copy 11558constructors, assignment operators, and destructors) will appear on this 11559list as well. 11560 11561 The 'TYPE_VFIELD' is a compiler-generated field used to point to 11562virtual function tables. It may or may not appear on the 'TYPE_FIELDS' 11563list. However, back ends should handle the 'TYPE_VFIELD' just like all 11564the entries on the 'TYPE_FIELDS' list. 11565 11566 Every class has an associated "binfo", which can be obtained with 11567'TYPE_BINFO'. Binfos are used to represent base-classes. The binfo 11568given by 'TYPE_BINFO' is the degenerate case, whereby every class is 11569considered to be its own base-class. The base binfos for a particular 11570binfo are held in a vector, whose length is obtained with 11571'BINFO_N_BASE_BINFOS'. The base binfos themselves are obtained with 11572'BINFO_BASE_BINFO' and 'BINFO_BASE_ITERATE'. To add a new binfo, use 11573'BINFO_BASE_APPEND'. The vector of base binfos can be obtained with 11574'BINFO_BASE_BINFOS', but normally you do not need to use that. The 11575class type associated with a binfo is given by 'BINFO_TYPE'. It is not 11576always the case that 'BINFO_TYPE (TYPE_BINFO (x))', because of typedefs 11577and qualified types. Neither is it the case that 'TYPE_BINFO 11578(BINFO_TYPE (y))' is the same binfo as 'y'. The reason is that if 'y' 11579is a binfo representing a base-class 'B' of a derived class 'D', then 11580'BINFO_TYPE (y)' will be 'B', and 'TYPE_BINFO (BINFO_TYPE (y))' will be 11581'B' as its own base-class, rather than as a base-class of 'D'. 11582 11583 The access to a base type can be found with 'BINFO_BASE_ACCESS'. This 11584will produce 'access_public_node', 'access_private_node' or 11585'access_protected_node'. If bases are always public, 11586'BINFO_BASE_ACCESSES' may be 'NULL'. 11587 11588 'BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited 11589virtually or not. The other flags, 'BINFO_FLAG_0' to 'BINFO_FLAG_6', 11590can be used for language specific use. 11591 11592 The following macros can be used on a tree node representing a 11593class-type. 11594 11595'LOCAL_CLASS_P' 11596 This predicate holds if the class is local class _i.e._ declared 11597 inside a function body. 11598 11599'TYPE_POLYMORPHIC_P' 11600 This predicate holds if the class has at least one virtual function 11601 (declared or inherited). 11602 11603'TYPE_HAS_DEFAULT_CONSTRUCTOR' 11604 This predicate holds whenever its argument represents a class-type 11605 with default constructor. 11606 11607'CLASSTYPE_HAS_MUTABLE' 11608'TYPE_HAS_MUTABLE_P' 11609 These predicates hold for a class-type having a mutable data 11610 member. 11611 11612'CLASSTYPE_NON_POD_P' 11613 This predicate holds only for class-types that are not PODs. 11614 11615'TYPE_HAS_NEW_OPERATOR' 11616 This predicate holds for a class-type that defines 'operator new'. 11617 11618'TYPE_HAS_ARRAY_NEW_OPERATOR' 11619 This predicate holds for a class-type for which 'operator new[]' is 11620 defined. 11621 11622'TYPE_OVERLOADS_CALL_EXPR' 11623 This predicate holds for class-type for which the function call 11624 'operator()' is overloaded. 11625 11626'TYPE_OVERLOADS_ARRAY_REF' 11627 This predicate holds for a class-type that overloads 'operator[]' 11628 11629'TYPE_OVERLOADS_ARROW' 11630 This predicate holds for a class-type for which 'operator->' is 11631 overloaded. 11632 11633 11634File: gccint.info, Node: Functions for C++, Next: Statements for C++, Prev: Classes, Up: C and C++ Trees 11635 1163611.10.4 Functions for C++ 11637------------------------- 11638 11639A function is represented by a 'FUNCTION_DECL' node. A set of 11640overloaded functions is sometimes represented by an 'OVERLOAD' node. 11641 11642 An 'OVERLOAD' node is not a declaration, so none of the 'DECL_' macros 11643should be used on an 'OVERLOAD'. An 'OVERLOAD' node is similar to a 11644'TREE_LIST'. Use 'OVL_CURRENT' to get the function associated with an 11645'OVERLOAD' node; use 'OVL_NEXT' to get the next 'OVERLOAD' node in the 11646list of overloaded functions. The macros 'OVL_CURRENT' and 'OVL_NEXT' 11647are actually polymorphic; you can use them to work with 'FUNCTION_DECL' 11648nodes as well as with overloads. In the case of a 'FUNCTION_DECL', 11649'OVL_CURRENT' will always return the function itself, and 'OVL_NEXT' 11650will always be 'NULL_TREE'. 11651 11652 To determine the scope of a function, you can use the 'DECL_CONTEXT' 11653macro. This macro will return the class (either a 'RECORD_TYPE' or a 11654'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is 11655a member. For a virtual function, this macro returns the class in which 11656the function was actually defined, not the base class in which the 11657virtual declaration occurred. 11658 11659 If a friend function is defined in a class scope, the 11660'DECL_FRIEND_CONTEXT' macro can be used to determine the class in which 11661it was defined. For example, in 11662 class C { friend void f() {} }; 11663the 'DECL_CONTEXT' for 'f' will be the 'global_namespace', but the 11664'DECL_FRIEND_CONTEXT' will be the 'RECORD_TYPE' for 'C'. 11665 11666 The following macros and functions can be used on a 'FUNCTION_DECL': 11667'DECL_MAIN_P' 11668 This predicate holds for a function that is the program entry point 11669 '::code'. 11670 11671'DECL_LOCAL_FUNCTION_P' 11672 This predicate holds if the function was declared at block scope, 11673 even though it has a global scope. 11674 11675'DECL_ANTICIPATED' 11676 This predicate holds if the function is a built-in function but its 11677 prototype is not yet explicitly declared. 11678 11679'DECL_EXTERN_C_FUNCTION_P' 11680 This predicate holds if the function is declared as an ''extern 11681 "C"'' function. 11682 11683'DECL_LINKONCE_P' 11684 This macro holds if multiple copies of this function may be emitted 11685 in various translation units. It is the responsibility of the 11686 linker to merge the various copies. Template instantiations are 11687 the most common example of functions for which 'DECL_LINKONCE_P' 11688 holds; G++ instantiates needed templates in all translation units 11689 which require them, and then relies on the linker to remove 11690 duplicate instantiations. 11691 11692 FIXME: This macro is not yet implemented. 11693 11694'DECL_FUNCTION_MEMBER_P' 11695 This macro holds if the function is a member of a class, rather 11696 than a member of a namespace. 11697 11698'DECL_STATIC_FUNCTION_P' 11699 This predicate holds if the function a static member function. 11700 11701'DECL_NONSTATIC_MEMBER_FUNCTION_P' 11702 This macro holds for a non-static member function. 11703 11704'DECL_CONST_MEMFUNC_P' 11705 This predicate holds for a 'const'-member function. 11706 11707'DECL_VOLATILE_MEMFUNC_P' 11708 This predicate holds for a 'volatile'-member function. 11709 11710'DECL_CONSTRUCTOR_P' 11711 This macro holds if the function is a constructor. 11712 11713'DECL_NONCONVERTING_P' 11714 This predicate holds if the constructor is a non-converting 11715 constructor. 11716 11717'DECL_COMPLETE_CONSTRUCTOR_P' 11718 This predicate holds for a function which is a constructor for an 11719 object of a complete type. 11720 11721'DECL_BASE_CONSTRUCTOR_P' 11722 This predicate holds for a function which is a constructor for a 11723 base class sub-object. 11724 11725'DECL_COPY_CONSTRUCTOR_P' 11726 This predicate holds for a function which is a copy-constructor. 11727 11728'DECL_DESTRUCTOR_P' 11729 This macro holds if the function is a destructor. 11730 11731'DECL_COMPLETE_DESTRUCTOR_P' 11732 This predicate holds if the function is the destructor for an 11733 object a complete type. 11734 11735'DECL_OVERLOADED_OPERATOR_P' 11736 This macro holds if the function is an overloaded operator. 11737 11738'DECL_CONV_FN_P' 11739 This macro holds if the function is a type-conversion operator. 11740 11741'DECL_GLOBAL_CTOR_P' 11742 This predicate holds if the function is a file-scope initialization 11743 function. 11744 11745'DECL_GLOBAL_DTOR_P' 11746 This predicate holds if the function is a file-scope finalization 11747 function. 11748 11749'DECL_THUNK_P' 11750 This predicate holds if the function is a thunk. 11751 11752 These functions represent stub code that adjusts the 'this' pointer 11753 and then jumps to another function. When the jumped-to function 11754 returns, control is transferred directly to the caller, without 11755 returning to the thunk. The first parameter to the thunk is always 11756 the 'this' pointer; the thunk should add 'THUNK_DELTA' to this 11757 value. (The 'THUNK_DELTA' is an 'int', not an 'INTEGER_CST'.) 11758 11759 Then, if 'THUNK_VCALL_OFFSET' (an 'INTEGER_CST') is nonzero the 11760 adjusted 'this' pointer must be adjusted again. The complete 11761 calculation is given by the following pseudo-code: 11762 11763 this += THUNK_DELTA 11764 if (THUNK_VCALL_OFFSET) 11765 this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET] 11766 11767 Finally, the thunk should jump to the location given by 11768 'DECL_INITIAL'; this will always be an expression for the address 11769 of a function. 11770 11771'DECL_NON_THUNK_FUNCTION_P' 11772 This predicate holds if the function is _not_ a thunk function. 11773 11774'GLOBAL_INIT_PRIORITY' 11775 If either 'DECL_GLOBAL_CTOR_P' or 'DECL_GLOBAL_DTOR_P' holds, then 11776 this gives the initialization priority for the function. The 11777 linker will arrange that all functions for which 11778 'DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority 11779 before 'main' is called. When the program exits, all functions for 11780 which 'DECL_GLOBAL_DTOR_P' holds are run in the reverse order. 11781 11782'TYPE_RAISES_EXCEPTIONS' 11783 This macro returns the list of exceptions that a (member-)function 11784 can raise. The returned list, if non 'NULL', is comprised of nodes 11785 whose 'TREE_VALUE' represents a type. 11786 11787'TYPE_NOTHROW_P' 11788 This predicate holds when the exception-specification of its 11789 arguments is of the form ''()''. 11790 11791'DECL_ARRAY_DELETE_OPERATOR_P' 11792 This predicate holds if the function an overloaded 'operator 11793 delete[]'. 11794 11795 11796File: gccint.info, Node: Statements for C++, Next: C++ Expressions, Prev: Functions for C++, Up: C and C++ Trees 11797 1179811.10.5 Statements for C++ 11799-------------------------- 11800 11801A function that has a definition in the current translation unit will 11802have a non-'NULL' 'DECL_INITIAL'. However, back ends should not make 11803use of the particular value given by 'DECL_INITIAL'. 11804 11805 The 'DECL_SAVED_TREE' macro will give the complete body of the 11806function. 11807 1180811.10.5.1 Statements 11809.................... 11810 11811There are tree nodes corresponding to all of the source-level statement 11812constructs, used within the C and C++ frontends. These are enumerated 11813here, together with a list of the various macros that can be used to 11814obtain information about them. There are a few macros that can be used 11815with all statements: 11816 11817'STMT_IS_FULL_EXPR_P' 11818 In C++, statements normally constitute "full expressions"; 11819 temporaries created during a statement are destroyed when the 11820 statement is complete. However, G++ sometimes represents 11821 expressions by statements; these statements will not have 11822 'STMT_IS_FULL_EXPR_P' set. Temporaries created during such 11823 statements should be destroyed when the innermost enclosing 11824 statement with 'STMT_IS_FULL_EXPR_P' set is exited. 11825 11826 Here is the list of the various statement nodes, and the macros used to 11827access them. This documentation describes the use of these nodes in 11828non-template functions (including instantiations of template functions). 11829In template functions, the same nodes are used, but sometimes in 11830slightly different ways. 11831 11832 Many of the statements have substatements. For example, a 'while' loop 11833will have a body, which is itself a statement. If the substatement is 11834'NULL_TREE', it is considered equivalent to a statement consisting of a 11835single ';', i.e., an expression statement in which the expression has 11836been omitted. A substatement may in fact be a list of statements, 11837connected via their 'TREE_CHAIN's. So, you should always process the 11838statement tree by looping over substatements, like this: 11839 void process_stmt (stmt) 11840 tree stmt; 11841 { 11842 while (stmt) 11843 { 11844 switch (TREE_CODE (stmt)) 11845 { 11846 case IF_STMT: 11847 process_stmt (THEN_CLAUSE (stmt)); 11848 /* More processing here. */ 11849 break; 11850 11851 ... 11852 } 11853 11854 stmt = TREE_CHAIN (stmt); 11855 } 11856 } 11857 In other words, while the 'then' clause of an 'if' statement in C++ can 11858be only one statement (although that one statement may be a compound 11859statement), the intermediate representation will sometimes use several 11860statements chained together. 11861 11862'BREAK_STMT' 11863 11864 Used to represent a 'break' statement. There are no additional 11865 fields. 11866 11867'CLEANUP_STMT' 11868 11869 Used to represent an action that should take place upon exit from 11870 the enclosing scope. Typically, these actions are calls to 11871 destructors for local objects, but back ends cannot rely on this 11872 fact. If these nodes are in fact representing such destructors, 11873 'CLEANUP_DECL' will be the 'VAR_DECL' destroyed. Otherwise, 11874 'CLEANUP_DECL' will be 'NULL_TREE'. In any case, the 11875 'CLEANUP_EXPR' is the expression to execute. The cleanups executed 11876 on exit from a scope should be run in the reverse order of the 11877 order in which the associated 'CLEANUP_STMT's were encountered. 11878 11879'CONTINUE_STMT' 11880 11881 Used to represent a 'continue' statement. There are no additional 11882 fields. 11883 11884'CTOR_STMT' 11885 11886 Used to mark the beginning (if 'CTOR_BEGIN_P' holds) or end (if 11887 'CTOR_END_P' holds of the main body of a constructor. See also 11888 'SUBOBJECT' for more information on how to use these nodes. 11889 11890'DO_STMT' 11891 11892 Used to represent a 'do' loop. The body of the loop is given by 11893 'DO_BODY' while the termination condition for the loop is given by 11894 'DO_COND'. The condition for a 'do'-statement is always an 11895 expression. 11896 11897'EMPTY_CLASS_EXPR' 11898 11899 Used to represent a temporary object of a class with no data whose 11900 address is never taken. (All such objects are interchangeable.) 11901 The 'TREE_TYPE' represents the type of the object. 11902 11903'EXPR_STMT' 11904 11905 Used to represent an expression statement. Use 'EXPR_STMT_EXPR' to 11906 obtain the expression. 11907 11908'FOR_STMT' 11909 11910 Used to represent a 'for' statement. The 'FOR_INIT_STMT' is the 11911 initialization statement for the loop. The 'FOR_COND' is the 11912 termination condition. The 'FOR_EXPR' is the expression executed 11913 right before the 'FOR_COND' on each loop iteration; often, this 11914 expression increments a counter. The body of the loop is given by 11915 'FOR_BODY'. Note that 'FOR_INIT_STMT' and 'FOR_BODY' return 11916 statements, while 'FOR_COND' and 'FOR_EXPR' return expressions. 11917 11918'HANDLER' 11919 11920 Used to represent a C++ 'catch' block. The 'HANDLER_TYPE' is the 11921 type of exception that will be caught by this handler; it is equal 11922 (by pointer equality) to 'NULL' if this handler is for all types. 11923 'HANDLER_PARMS' is the 'DECL_STMT' for the catch parameter, and 11924 'HANDLER_BODY' is the code for the block itself. 11925 11926'IF_STMT' 11927 11928 Used to represent an 'if' statement. The 'IF_COND' is the 11929 expression. 11930 11931 If the condition is a 'TREE_LIST', then the 'TREE_PURPOSE' is a 11932 statement (usually a 'DECL_STMT'). Each time the condition is 11933 evaluated, the statement should be executed. Then, the 11934 'TREE_VALUE' should be used as the conditional expression itself. 11935 This representation is used to handle C++ code like this: 11936 11937 C++ distinguishes between this and 'COND_EXPR' for handling 11938 templates. 11939 11940 if (int i = 7) ... 11941 11942 where there is a new local variable (or variables) declared within 11943 the condition. 11944 11945 The 'THEN_CLAUSE' represents the statement given by the 'then' 11946 condition, while the 'ELSE_CLAUSE' represents the statement given 11947 by the 'else' condition. 11948 11949'SUBOBJECT' 11950 11951 In a constructor, these nodes are used to mark the point at which a 11952 subobject of 'this' is fully constructed. If, after this point, an 11953 exception is thrown before a 'CTOR_STMT' with 'CTOR_END_P' set is 11954 encountered, the 'SUBOBJECT_CLEANUP' must be executed. The 11955 cleanups must be executed in the reverse order in which they 11956 appear. 11957 11958'SWITCH_STMT' 11959 11960 Used to represent a 'switch' statement. The 'SWITCH_STMT_COND' is 11961 the expression on which the switch is occurring. See the 11962 documentation for an 'IF_STMT' for more information on the 11963 representation used for the condition. The 'SWITCH_STMT_BODY' is 11964 the body of the switch statement. The 'SWITCH_STMT_TYPE' is the 11965 original type of switch expression as given in the source, before 11966 any compiler conversions. 11967 11968'TRY_BLOCK' 11969 Used to represent a 'try' block. The body of the try block is 11970 given by 'TRY_STMTS'. Each of the catch blocks is a 'HANDLER' 11971 node. The first handler is given by 'TRY_HANDLERS'. Subsequent 11972 handlers are obtained by following the 'TREE_CHAIN' link from one 11973 handler to the next. The body of the handler is given by 11974 'HANDLER_BODY'. 11975 11976 If 'CLEANUP_P' holds of the 'TRY_BLOCK', then the 'TRY_HANDLERS' 11977 will not be a 'HANDLER' node. Instead, it will be an expression 11978 that should be executed if an exception is thrown in the try block. 11979 It must rethrow the exception after executing that code. And, if 11980 an exception is thrown while the expression is executing, 11981 'terminate' must be called. 11982 11983'USING_STMT' 11984 Used to represent a 'using' directive. The namespace is given by 11985 'USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node 11986 is needed inside template functions, to implement using directives 11987 during instantiation. 11988 11989'WHILE_STMT' 11990 11991 Used to represent a 'while' loop. The 'WHILE_COND' is the 11992 termination condition for the loop. See the documentation for an 11993 'IF_STMT' for more information on the representation used for the 11994 condition. 11995 11996 The 'WHILE_BODY' is the body of the loop. 11997 11998 11999File: gccint.info, Node: C++ Expressions, Prev: Statements for C++, Up: C and C++ Trees 12000 1200111.10.6 C++ Expressions 12002----------------------- 12003 12004This section describes expressions specific to the C and C++ front ends. 12005 12006'TYPEID_EXPR' 12007 12008 Used to represent a 'typeid' expression. 12009 12010'NEW_EXPR' 12011'VEC_NEW_EXPR' 12012 12013 Used to represent a call to 'new' and 'new[]' respectively. 12014 12015'DELETE_EXPR' 12016'VEC_DELETE_EXPR' 12017 12018 Used to represent a call to 'delete' and 'delete[]' respectively. 12019 12020'MEMBER_REF' 12021 12022 Represents a reference to a member of a class. 12023 12024'THROW_EXPR' 12025 12026 Represents an instance of 'throw' in the program. Operand 0, which 12027 is the expression to throw, may be 'NULL_TREE'. 12028 12029'AGGR_INIT_EXPR' 12030 An 'AGGR_INIT_EXPR' represents the initialization as the return 12031 value of a function call, or as the result of a constructor. An 12032 'AGGR_INIT_EXPR' will only appear as a full-expression, or as the 12033 second operand of a 'TARGET_EXPR'. 'AGGR_INIT_EXPR's have a 12034 representation similar to that of 'CALL_EXPR's. You can use the 12035 'AGGR_INIT_EXPR_FN' and 'AGGR_INIT_EXPR_ARG' macros to access the 12036 function to call and the arguments to pass. 12037 12038 If 'AGGR_INIT_VIA_CTOR_P' holds of the 'AGGR_INIT_EXPR', then the 12039 initialization is via a constructor call. The address of the 12040 'AGGR_INIT_EXPR_SLOT' operand, which is always a 'VAR_DECL', is 12041 taken, and this value replaces the first argument in the argument 12042 list. 12043 12044 In either case, the expression is void. 12045 12046 12047File: gccint.info, Node: Java Trees, Prev: C and C++ Trees, Up: GENERIC 12048 1204911.11 Java Trees 12050================ 12051 12052 12053File: gccint.info, Node: GIMPLE, Next: Tree SSA, Prev: GENERIC, Up: Top 12054 1205512 GIMPLE 12056********* 12057 12058GIMPLE is a three-address representation derived from GENERIC by 12059breaking down GENERIC expressions into tuples of no more than 3 operands 12060(with some exceptions like function calls). GIMPLE was heavily 12061influenced by the SIMPLE IL used by the McCAT compiler project at McGill 12062University, though we have made some different choices. For one thing, 12063SIMPLE doesn't support 'goto'. 12064 12065 Temporaries are introduced to hold intermediate values needed to 12066compute complex expressions. Additionally, all the control structures 12067used in GENERIC are lowered into conditional jumps, lexical scopes are 12068removed and exception regions are converted into an on the side 12069exception region tree. 12070 12071 The compiler pass which converts GENERIC into GIMPLE is referred to as 12072the 'gimplifier'. The gimplifier works recursively, generating GIMPLE 12073tuples out of the original GENERIC expressions. 12074 12075 One of the early implementation strategies used for the GIMPLE 12076representation was to use the same internal data structures used by 12077front ends to represent parse trees. This simplified implementation 12078because we could leverage existing functionality and interfaces. 12079However, GIMPLE is a much more restrictive representation than abstract 12080syntax trees (AST), therefore it does not require the full structural 12081complexity provided by the main tree data structure. 12082 12083 The GENERIC representation of a function is stored in the 12084'DECL_SAVED_TREE' field of the associated 'FUNCTION_DECL' tree node. It 12085is converted to GIMPLE by a call to 'gimplify_function_tree'. 12086 12087 If a front end wants to include language-specific tree codes in the 12088tree representation which it provides to the back end, it must provide a 12089definition of 'LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the 12090front end trees to GIMPLE. Usually such a hook will involve much of the 12091same code for expanding front end trees to RTL. This function can 12092return fully lowered GIMPLE, or it can return GENERIC trees and let the 12093main gimplifier lower them the rest of the way; this is often simpler. 12094GIMPLE that is not fully lowered is known as "High GIMPLE" and consists 12095of the IL before the pass 'pass_lower_cf'. High GIMPLE contains some 12096container statements like lexical scopes (represented by 'GIMPLE_BIND') 12097and nested expressions (e.g., 'GIMPLE_TRY'), while "Low GIMPLE" exposes 12098all of the implicit jumps for control and exception expressions directly 12099in the IL and EH region trees. 12100 12101 The C and C++ front ends currently convert directly from front end 12102trees to GIMPLE, and hand that off to the back end rather than first 12103converting to GENERIC. Their gimplifier hooks know about all the 12104'_STMT' nodes and how to convert them to GENERIC forms. There was some 12105work done on a genericization pass which would run first, but the 12106existence of 'STMT_EXPR' meant that in order to convert all of the C 12107statements into GENERIC equivalents would involve walking the entire 12108tree anyway, so it was simpler to lower all the way. This might change 12109in the future if someone writes an optimization pass which would work 12110better with higher-level trees, but currently the optimizers all expect 12111GIMPLE. 12112 12113 You can request to dump a C-like representation of the GIMPLE form with 12114the flag '-fdump-tree-gimple'. 12115 12116* Menu: 12117 12118* Tuple representation:: 12119* Class hierarchy of GIMPLE statements:: 12120* GIMPLE instruction set:: 12121* GIMPLE Exception Handling:: 12122* Temporaries:: 12123* Operands:: 12124* Manipulating GIMPLE statements:: 12125* Tuple specific accessors:: 12126* GIMPLE sequences:: 12127* Sequence iterators:: 12128* Adding a new GIMPLE statement code:: 12129* Statement and operand traversals:: 12130 12131 12132File: gccint.info, Node: Tuple representation, Next: Class hierarchy of GIMPLE statements, Up: GIMPLE 12133 1213412.1 Tuple representation 12135========================= 12136 12137GIMPLE instructions are tuples of variable size divided in two groups: a 12138header describing the instruction and its locations, and a variable 12139length body with all the operands. Tuples are organized into a 12140hierarchy with 3 main classes of tuples. 12141 1214212.1.1 'gimple' (gsbase) 12143------------------------ 12144 12145This is the root of the hierarchy, it holds basic information needed by 12146most GIMPLE statements. There are some fields that may not be relevant 12147to every GIMPLE statement, but those were moved into the base structure 12148to take advantage of holes left by other fields (thus making the 12149structure more compact). The structure takes 4 words (32 bytes) on 64 12150bit hosts: 12151 12152Field Size (bits) 12153'code' 8 12154'subcode' 16 12155'no_warning' 1 12156'visited' 1 12157'nontemporal_move' 1 12158'plf' 2 12159'modified' 1 12160'has_volatile_ops' 1 12161'references_memory_p' 1 12162'uid' 32 12163'location' 32 12164'num_ops' 32 12165'bb' 64 12166'block' 63 12167Total size 32 bytes 12168 12169 * 'code' Main identifier for a GIMPLE instruction. 12170 12171 * 'subcode' Used to distinguish different variants of the same basic 12172 instruction or provide flags applicable to a given code. The 12173 'subcode' flags field has different uses depending on the code of 12174 the instruction, but mostly it distinguishes instructions of the 12175 same family. The most prominent use of this field is in 12176 assignments, where subcode indicates the operation done on the RHS 12177 of the assignment. For example, a = b + c is encoded as 12178 'GIMPLE_ASSIGN <PLUS_EXPR, a, b, c>'. 12179 12180 * 'no_warning' Bitflag to indicate whether a warning has already been 12181 issued on this statement. 12182 12183 * 'visited' General purpose "visited" marker. Set and cleared by 12184 each pass when needed. 12185 12186 * 'nontemporal_move' Bitflag used in assignments that represent 12187 non-temporal moves. Although this bitflag is only used in 12188 assignments, it was moved into the base to take advantage of the 12189 bit holes left by the previous fields. 12190 12191 * 'plf' Pass Local Flags. This 2-bit mask can be used as general 12192 purpose markers by any pass. Passes are responsible for clearing 12193 and setting these two flags accordingly. 12194 12195 * 'modified' Bitflag to indicate whether the statement has been 12196 modified. Used mainly by the operand scanner to determine when to 12197 re-scan a statement for operands. 12198 12199 * 'has_volatile_ops' Bitflag to indicate whether this statement 12200 contains operands that have been marked volatile. 12201 12202 * 'references_memory_p' Bitflag to indicate whether this statement 12203 contains memory references (i.e., its operands are either global 12204 variables, or pointer dereferences or anything that must reside in 12205 memory). 12206 12207 * 'uid' This is an unsigned integer used by passes that want to 12208 assign IDs to every statement. These IDs must be assigned and used 12209 by each pass. 12210 12211 * 'location' This is a 'location_t' identifier to specify source code 12212 location for this statement. It is inherited from the front end. 12213 12214 * 'num_ops' Number of operands that this statement has. This 12215 specifies the size of the operand vector embedded in the tuple. 12216 Only used in some tuples, but it is declared in the base tuple to 12217 take advantage of the 32-bit hole left by the previous fields. 12218 12219 * 'bb' Basic block holding the instruction. 12220 12221 * 'block' Lexical block holding this statement. Also used for debug 12222 information generation. 12223 1222412.1.2 'gimple_statement_with_ops' 12225---------------------------------- 12226 12227This tuple is actually split in two: 'gimple_statement_with_ops_base' 12228and 'gimple_statement_with_ops'. This is needed to accommodate the way 12229the operand vector is allocated. The operand vector is defined to be an 12230array of 1 element. So, to allocate a dynamic number of operands, the 12231memory allocator ('gimple_alloc') simply allocates enough memory to hold 12232the structure itself plus 'N - 1' operands which run "off the end" of 12233the structure. For example, to allocate space for a tuple with 3 12234operands, 'gimple_alloc' reserves 'sizeof (struct 12235gimple_statement_with_ops) + 2 * sizeof (tree)' bytes. 12236 12237 On the other hand, several fields in this tuple need to be shared with 12238the 'gimple_statement_with_memory_ops' tuple. So, these common fields 12239are placed in 'gimple_statement_with_ops_base' which is then inherited 12240from the other two tuples. 12241 12242'gsbase' 256 12243'def_ops' 64 12244'use_ops' 64 12245'op' 'num_ops' * 64 12246Total 48 + 8 * 'num_ops' bytes 12247size 12248 12249 * 'gsbase' Inherited from 'struct gimple'. 12250 12251 * 'def_ops' Array of pointers into the operand array indicating all 12252 the slots that contain a variable written-to by the statement. 12253 This array is also used for immediate use chaining. Note that it 12254 would be possible to not rely on this array, but the changes 12255 required to implement this are pretty invasive. 12256 12257 * 'use_ops' Similar to 'def_ops' but for variables read by the 12258 statement. 12259 12260 * 'op' Array of trees with 'num_ops' slots. 12261 1226212.1.3 'gimple_statement_with_memory_ops' 12263----------------------------------------- 12264 12265This tuple is essentially identical to 'gimple_statement_with_ops', 12266except that it contains 4 additional fields to hold vectors related 12267memory stores and loads. Similar to the previous case, the structure is 12268split in two to accommodate for the operand vector 12269('gimple_statement_with_memory_ops_base' and 12270'gimple_statement_with_memory_ops'). 12271 12272Field Size (bits) 12273'gsbase' 256 12274'def_ops' 64 12275'use_ops' 64 12276'vdef_ops' 64 12277'vuse_ops' 64 12278'stores' 64 12279'loads' 64 12280'op' 'num_ops' * 64 12281Total size 80 + 8 * 'num_ops' bytes 12282 12283 * 'vdef_ops' Similar to 'def_ops' but for 'VDEF' operators. There is 12284 one entry per memory symbol written by this statement. This is 12285 used to maintain the memory SSA use-def and def-def chains. 12286 12287 * 'vuse_ops' Similar to 'use_ops' but for 'VUSE' operators. There is 12288 one entry per memory symbol loaded by this statement. This is used 12289 to maintain the memory SSA use-def chains. 12290 12291 * 'stores' Bitset with all the UIDs for the symbols written-to by the 12292 statement. This is different than 'vdef_ops' in that all the 12293 affected symbols are mentioned in this set. If memory partitioning 12294 is enabled, the 'vdef_ops' vector will refer to memory partitions. 12295 Furthermore, no SSA information is stored in this set. 12296 12297 * 'loads' Similar to 'stores', but for memory loads. (Note that 12298 there is some amount of redundancy here, it should be possible to 12299 reduce memory utilization further by removing these sets). 12300 12301 All the other tuples are defined in terms of these three basic ones. 12302Each tuple will add some fields. 12303 12304 12305File: gccint.info, Node: Class hierarchy of GIMPLE statements, Next: GIMPLE instruction set, Prev: Tuple representation, Up: GIMPLE 12306 1230712.2 Class hierarchy of GIMPLE statements 12308========================================= 12309 12310The following diagram shows the C++ inheritance hierarchy of statement 12311kinds, along with their relationships to 'GSS_' values (layouts) and 12312'GIMPLE_' values (codes): 12313 12314 gimple 12315 | layout: GSS_BASE 12316 | used for 4 codes: GIMPLE_ERROR_MARK 12317 | GIMPLE_NOP 12318 | GIMPLE_OMP_SECTIONS_SWITCH 12319 | GIMPLE_PREDICT 12320 | 12321 + gimple_statement_with_ops_base 12322 | | (no GSS layout) 12323 | | 12324 | + gimple_statement_with_ops 12325 | | | layout: GSS_WITH_OPS 12326 | | | 12327 | | + gcond 12328 | | | code: GIMPLE_COND 12329 | | | 12330 | | + gdebug 12331 | | | code: GIMPLE_DEBUG 12332 | | | 12333 | | + ggoto 12334 | | | code: GIMPLE_GOTO 12335 | | | 12336 | | + glabel 12337 | | | code: GIMPLE_LABEL 12338 | | | 12339 | | + gswitch 12340 | | code: GIMPLE_SWITCH 12341 | | 12342 | + gimple_statement_with_memory_ops_base 12343 | | layout: GSS_WITH_MEM_OPS_BASE 12344 | | 12345 | + gimple_statement_with_memory_ops 12346 | | | layout: GSS_WITH_MEM_OPS 12347 | | | 12348 | | + gassign 12349 | | | code GIMPLE_ASSIGN 12350 | | | 12351 | | + greturn 12352 | | code GIMPLE_RETURN 12353 | | 12354 | + gcall 12355 | | layout: GSS_CALL, code: GIMPLE_CALL 12356 | | 12357 | + gasm 12358 | | layout: GSS_ASM, code: GIMPLE_ASM 12359 | | 12360 | + gtransaction 12361 | layout: GSS_TRANSACTION, code: GIMPLE_TRANSACTION 12362 | 12363 + gimple_statement_omp 12364 | | layout: GSS_OMP. Used for code GIMPLE_OMP_SECTION 12365 | | 12366 | + gomp_critical 12367 | | layout: GSS_OMP_CRITICAL, code: GIMPLE_OMP_CRITICAL 12368 | | 12369 | + gomp_for 12370 | | layout: GSS_OMP_FOR, code: GIMPLE_OMP_FOR 12371 | | 12372 | + gomp_parallel_layout 12373 | | | layout: GSS_OMP_PARALLEL_LAYOUT 12374 | | | 12375 | | + gimple_statement_omp_taskreg 12376 | | | | 12377 | | | + gomp_parallel 12378 | | | | code: GIMPLE_OMP_PARALLEL 12379 | | | | 12380 | | | + gomp_task 12381 | | | code: GIMPLE_OMP_TASK 12382 | | | 12383 | | + gimple_statement_omp_target 12384 | | code: GIMPLE_OMP_TARGET 12385 | | 12386 | + gomp_sections 12387 | | layout: GSS_OMP_SECTIONS, code: GIMPLE_OMP_SECTIONS 12388 | | 12389 | + gimple_statement_omp_single_layout 12390 | | layout: GSS_OMP_SINGLE_LAYOUT 12391 | | 12392 | + gomp_single 12393 | | code: GIMPLE_OMP_SINGLE 12394 | | 12395 | + gomp_teams 12396 | code: GIMPLE_OMP_TEAMS 12397 | 12398 + gbind 12399 | layout: GSS_BIND, code: GIMPLE_BIND 12400 | 12401 + gcatch 12402 | layout: GSS_CATCH, code: GIMPLE_CATCH 12403 | 12404 + geh_filter 12405 | layout: GSS_EH_FILTER, code: GIMPLE_EH_FILTER 12406 | 12407 + geh_else 12408 | layout: GSS_EH_ELSE, code: GIMPLE_EH_ELSE 12409 | 12410 + geh_mnt 12411 | layout: GSS_EH_MNT, code: GIMPLE_EH_MUST_NOT_THROW 12412 | 12413 + gphi 12414 | layout: GSS_PHI, code: GIMPLE_PHI 12415 | 12416 + gimple_statement_eh_ctrl 12417 | | layout: GSS_EH_CTRL 12418 | | 12419 | + gresx 12420 | | code: GIMPLE_RESX 12421 | | 12422 | + geh_dispatch 12423 | code: GIMPLE_EH_DISPATCH 12424 | 12425 + gtry 12426 | layout: GSS_TRY, code: GIMPLE_TRY 12427 | 12428 + gimple_statement_wce 12429 | layout: GSS_WCE, code: GIMPLE_WITH_CLEANUP_EXPR 12430 | 12431 + gomp_continue 12432 | layout: GSS_OMP_CONTINUE, code: GIMPLE_OMP_CONTINUE 12433 | 12434 + gomp_atomic_load 12435 | layout: GSS_OMP_ATOMIC_LOAD, code: GIMPLE_OMP_ATOMIC_LOAD 12436 | 12437 + gimple_statement_omp_atomic_store_layout 12438 | layout: GSS_OMP_ATOMIC_STORE_LAYOUT, 12439 | code: GIMPLE_OMP_ATOMIC_STORE 12440 | 12441 + gomp_atomic_store 12442 | code: GIMPLE_OMP_ATOMIC_STORE 12443 | 12444 + gomp_return 12445 code: GIMPLE_OMP_RETURN 12446 12447 12448File: gccint.info, Node: GIMPLE instruction set, Next: GIMPLE Exception Handling, Prev: Class hierarchy of GIMPLE statements, Up: GIMPLE 12449 1245012.3 GIMPLE instruction set 12451=========================== 12452 12453The following table briefly describes the GIMPLE instruction set. 12454 12455Instruction High GIMPLE Low GIMPLE 12456'GIMPLE_ASM' x x 12457'GIMPLE_ASSIGN' x x 12458'GIMPLE_BIND' x 12459'GIMPLE_CALL' x x 12460'GIMPLE_CATCH' x 12461'GIMPLE_COND' x x 12462'GIMPLE_DEBUG' x x 12463'GIMPLE_EH_FILTER' x 12464'GIMPLE_GOTO' x x 12465'GIMPLE_LABEL' x x 12466'GIMPLE_NOP' x x 12467'GIMPLE_OMP_ATOMIC_LOAD' x x 12468'GIMPLE_OMP_ATOMIC_STORE' x x 12469'GIMPLE_OMP_CONTINUE' x x 12470'GIMPLE_OMP_CRITICAL' x x 12471'GIMPLE_OMP_FOR' x x 12472'GIMPLE_OMP_MASTER' x x 12473'GIMPLE_OMP_ORDERED' x x 12474'GIMPLE_OMP_PARALLEL' x x 12475'GIMPLE_OMP_RETURN' x x 12476'GIMPLE_OMP_SECTION' x x 12477'GIMPLE_OMP_SECTIONS' x x 12478'GIMPLE_OMP_SECTIONS_SWITCH' x x 12479'GIMPLE_OMP_SINGLE' x x 12480'GIMPLE_PHI' x 12481'GIMPLE_RESX' x 12482'GIMPLE_RETURN' x x 12483'GIMPLE_SWITCH' x x 12484'GIMPLE_TRY' x 12485 12486 12487File: gccint.info, Node: GIMPLE Exception Handling, Next: Temporaries, Prev: GIMPLE instruction set, Up: GIMPLE 12488 1248912.4 Exception Handling 12490======================= 12491 12492Other exception handling constructs are represented using 12493'GIMPLE_TRY_CATCH'. 'GIMPLE_TRY_CATCH' has two operands. The first 12494operand is a sequence of statements to execute. If executing these 12495statements does not throw an exception, then the second operand is 12496ignored. Otherwise, if an exception is thrown, then the second operand 12497of the 'GIMPLE_TRY_CATCH' is checked. The second operand may have the 12498following forms: 12499 12500 1. A sequence of statements to execute. When an exception occurs, 12501 these statements are executed, and then the exception is rethrown. 12502 12503 2. A sequence of 'GIMPLE_CATCH' statements. Each 'GIMPLE_CATCH' has a 12504 list of applicable exception types and handler code. If the thrown 12505 exception matches one of the caught types, the associated handler 12506 code is executed. If the handler code falls off the bottom, 12507 execution continues after the original 'GIMPLE_TRY_CATCH'. 12508 12509 3. A 'GIMPLE_EH_FILTER' statement. This has a list of permitted 12510 exception types, and code to handle a match failure. If the thrown 12511 exception does not match one of the allowed types, the associated 12512 match failure code is executed. If the thrown exception does 12513 match, it continues unwinding the stack looking for the next 12514 handler. 12515 12516 Currently throwing an exception is not directly represented in GIMPLE, 12517since it is implemented by calling a function. At some point in the 12518future we will want to add some way to express that the call will throw 12519an exception of a known type. 12520 12521 Just before running the optimizers, the compiler lowers the high-level 12522EH constructs above into a set of 'goto's, magic labels, and EH regions. 12523Continuing to unwind at the end of a cleanup is represented with a 12524'GIMPLE_RESX'. 12525 12526 12527File: gccint.info, Node: Temporaries, Next: Operands, Prev: GIMPLE Exception Handling, Up: GIMPLE 12528 1252912.5 Temporaries 12530================ 12531 12532When gimplification encounters a subexpression that is too complex, it 12533creates a new temporary variable to hold the value of the subexpression, 12534and adds a new statement to initialize it before the current statement. 12535These special temporaries are known as 'expression temporaries', and are 12536allocated using 'get_formal_tmp_var'. The compiler tries to always 12537evaluate identical expressions into the same temporary, to simplify 12538elimination of redundant calculations. 12539 12540 We can only use expression temporaries when we know that it will not be 12541reevaluated before its value is used, and that it will not be otherwise 12542modified(1). Other temporaries can be allocated using 12543'get_initialized_tmp_var' or 'create_tmp_var'. 12544 12545 Currently, an expression like 'a = b + 5' is not reduced any further. 12546We tried converting it to something like 12547 T1 = b + 5; 12548 a = T1; 12549 but this bloated the representation for minimal benefit. However, a 12550variable which must live in memory cannot appear in an expression; its 12551value is explicitly loaded into a temporary first. Similarly, storing 12552the value of an expression to a memory variable goes through a 12553temporary. 12554 12555 ---------- Footnotes ---------- 12556 12557 (1) These restrictions are derived from those in Morgan 4.8. 12558 12559 12560File: gccint.info, Node: Operands, Next: Manipulating GIMPLE statements, Prev: Temporaries, Up: GIMPLE 12561 1256212.6 Operands 12563============= 12564 12565In general, expressions in GIMPLE consist of an operation and the 12566appropriate number of simple operands; these operands must either be a 12567GIMPLE rvalue ('is_gimple_val'), i.e. a constant or a register variable. 12568More complex operands are factored out into temporaries, so that 12569 a = b + c + d 12570 becomes 12571 T1 = b + c; 12572 a = T1 + d; 12573 12574 The same rule holds for arguments to a 'GIMPLE_CALL'. 12575 12576 The target of an assignment is usually a variable, but can also be a 12577'MEM_REF' or a compound lvalue as described below. 12578 12579* Menu: 12580 12581* Compound Expressions:: 12582* Compound Lvalues:: 12583* Conditional Expressions:: 12584* Logical Operators:: 12585 12586 12587File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: Operands 12588 1258912.6.1 Compound Expressions 12590--------------------------- 12591 12592The left-hand side of a C comma expression is simply moved into a 12593separate statement. 12594 12595 12596File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: Operands 12597 1259812.6.2 Compound Lvalues 12599----------------------- 12600 12601Currently compound lvalues involving array and structure field 12602references are not broken down; an expression like 'a.b[2] = 42' is not 12603reduced any further (though complex array subscripts are). This 12604restriction is a workaround for limitations in later optimizers; if we 12605were to convert this to 12606 12607 T1 = &a.b; 12608 T1[2] = 42; 12609 12610 alias analysis would not remember that the reference to 'T1[2]' came by 12611way of 'a.b', so it would think that the assignment could alias another 12612member of 'a'; this broke 'struct-alias-1.c'. Future optimizer 12613improvements may make this limitation unnecessary. 12614 12615 12616File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: Operands 12617 1261812.6.3 Conditional Expressions 12619------------------------------ 12620 12621A C '?:' expression is converted into an 'if' statement with each branch 12622assigning to the same temporary. So, 12623 12624 a = b ? c : d; 12625 becomes 12626 if (b == 1) 12627 T1 = c; 12628 else 12629 T1 = d; 12630 a = T1; 12631 12632 The GIMPLE level if-conversion pass re-introduces '?:' expression, if 12633appropriate. It is used to vectorize loops with conditions using vector 12634conditional operations. 12635 12636 Note that in GIMPLE, 'if' statements are represented using 12637'GIMPLE_COND', as described below. 12638 12639 12640File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: Operands 12641 1264212.6.4 Logical Operators 12643------------------------ 12644 12645Except when they appear in the condition operand of a 'GIMPLE_COND', 12646logical 'and' and 'or' operators are simplified as follows: 'a = b && c' 12647becomes 12648 12649 T1 = (bool)b; 12650 if (T1 == true) 12651 T1 = (bool)c; 12652 a = T1; 12653 12654 Note that 'T1' in this example cannot be an expression temporary, 12655because it has two different assignments. 12656 1265712.6.5 Manipulating operands 12658---------------------------- 12659 12660All gimple operands are of type 'tree'. But only certain types of trees 12661are allowed to be used as operand tuples. Basic validation is 12662controlled by the function 'get_gimple_rhs_class', which given a tree 12663code, returns an 'enum' with the following values of type 'enum 12664gimple_rhs_class' 12665 12666 * 'GIMPLE_INVALID_RHS' The tree cannot be used as a GIMPLE operand. 12667 12668 * 'GIMPLE_TERNARY_RHS' The tree is a valid GIMPLE ternary operation. 12669 12670 * 'GIMPLE_BINARY_RHS' The tree is a valid GIMPLE binary operation. 12671 12672 * 'GIMPLE_UNARY_RHS' The tree is a valid GIMPLE unary operation. 12673 12674 * 'GIMPLE_SINGLE_RHS' The tree is a single object, that cannot be 12675 split into simpler operands (for instance, 'SSA_NAME', 'VAR_DECL', 12676 'COMPONENT_REF', etc). 12677 12678 This operand class also acts as an escape hatch for tree nodes that 12679 may be flattened out into the operand vector, but would need more 12680 than two slots on the RHS. For instance, a 'COND_EXPR' expression 12681 of the form '(a op b) ? x : y' could be flattened out on the 12682 operand vector using 4 slots, but it would also require additional 12683 processing to distinguish 'c = a op b' from 'c = a op b ? x : y'. 12684 Something similar occurs with 'ASSERT_EXPR'. In time, these 12685 special case tree expressions should be flattened into the operand 12686 vector. 12687 12688 For tree nodes in the categories 'GIMPLE_TERNARY_RHS', 12689'GIMPLE_BINARY_RHS' and 'GIMPLE_UNARY_RHS', they cannot be stored inside 12690tuples directly. They first need to be flattened and separated into 12691individual components. For instance, given the GENERIC expression 12692 12693 a = b + c 12694 12695 its tree representation is: 12696 12697 MODIFY_EXPR <VAR_DECL <a>, PLUS_EXPR <VAR_DECL <b>, VAR_DECL <c>>> 12698 12699 In this case, the GIMPLE form for this statement is logically identical 12700to its GENERIC form but in GIMPLE, the 'PLUS_EXPR' on the RHS of the 12701assignment is not represented as a tree, instead the two operands are 12702taken out of the 'PLUS_EXPR' sub-tree and flattened into the GIMPLE 12703tuple as follows: 12704 12705 GIMPLE_ASSIGN <PLUS_EXPR, VAR_DECL <a>, VAR_DECL <b>, VAR_DECL <c>> 12706 1270712.6.6 Operand vector allocation 12708-------------------------------- 12709 12710The operand vector is stored at the bottom of the three tuple structures 12711that accept operands. This means, that depending on the code of a given 12712statement, its operand vector will be at different offsets from the base 12713of the structure. To access tuple operands use the following accessors 12714 12715 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 12716 Returns the number of operands in statement G. 12717 12718 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 12719 Returns operand 'I' from statement 'G'. 12720 12721 -- GIMPLE function: tree * gimple_ops (gimple g) 12722 Returns a pointer into the operand vector for statement 'G'. This 12723 is computed using an internal table called 'gimple_ops_offset_'[]. 12724 This table is indexed by the gimple code of 'G'. 12725 12726 When the compiler is built, this table is filled-in using the sizes 12727 of the structures used by each statement code defined in 12728 gimple.def. Since the operand vector is at the bottom of the 12729 structure, for a gimple code 'C' the offset is computed as sizeof 12730 (struct-of 'C') - sizeof (tree). 12731 12732 This mechanism adds one memory indirection to every access when 12733 using 'gimple_op'(), if this becomes a bottleneck, a pass can 12734 choose to memoize the result from 'gimple_ops'() and use that to 12735 access the operands. 12736 1273712.6.7 Operand validation 12738------------------------- 12739 12740When adding a new operand to a gimple statement, the operand will be 12741validated according to what each tuple accepts in its operand vector. 12742These predicates are called by the 'gimple_NAME_set_...()'. Each tuple 12743will use one of the following predicates (Note, this list is not 12744exhaustive): 12745 12746 -- GIMPLE function: bool is_gimple_val (tree t) 12747 Returns true if t is a "GIMPLE value", which are all the 12748 non-addressable stack variables (variables for which 12749 'is_gimple_reg' returns true) and constants (expressions for which 12750 'is_gimple_min_invariant' returns true). 12751 12752 -- GIMPLE function: bool is_gimple_addressable (tree t) 12753 Returns true if t is a symbol or memory reference whose address can 12754 be taken. 12755 12756 -- GIMPLE function: bool is_gimple_asm_val (tree t) 12757 Similar to 'is_gimple_val' but it also accepts hard registers. 12758 12759 -- GIMPLE function: bool is_gimple_call_addr (tree t) 12760 Return true if t is a valid expression to use as the function 12761 called by a 'GIMPLE_CALL'. 12762 12763 -- GIMPLE function: bool is_gimple_mem_ref_addr (tree t) 12764 Return true if t is a valid expression to use as first operand of a 12765 'MEM_REF' expression. 12766 12767 -- GIMPLE function: bool is_gimple_constant (tree t) 12768 Return true if t is a valid gimple constant. 12769 12770 -- GIMPLE function: bool is_gimple_min_invariant (tree t) 12771 Return true if t is a valid minimal invariant. This is different 12772 from constants, in that the specific value of t may not be known at 12773 compile time, but it is known that it doesn't change (e.g., the 12774 address of a function local variable). 12775 12776 -- GIMPLE function: bool is_gimple_ip_invariant (tree t) 12777 Return true if t is an interprocedural invariant. This means that 12778 t is a valid invariant in all functions (e.g. it can be an address 12779 of a global variable but not of a local one). 12780 12781 -- GIMPLE function: bool is_gimple_ip_invariant_address (tree t) 12782 Return true if t is an 'ADDR_EXPR' that does not change once the 12783 program is running (and which is valid in all functions). 12784 1278512.6.8 Statement validation 12786--------------------------- 12787 12788 -- GIMPLE function: bool is_gimple_assign (gimple g) 12789 Return true if the code of g is 'GIMPLE_ASSIGN'. 12790 12791 -- GIMPLE function: bool is_gimple_call (gimple g) 12792 Return true if the code of g is 'GIMPLE_CALL'. 12793 12794 -- GIMPLE function: bool is_gimple_debug (gimple g) 12795 Return true if the code of g is 'GIMPLE_DEBUG'. 12796 12797 -- GIMPLE function: bool gimple_assign_cast_p (const_gimple g) 12798 Return true if g is a 'GIMPLE_ASSIGN' that performs a type cast 12799 operation. 12800 12801 -- GIMPLE function: bool gimple_debug_bind_p (gimple g) 12802 Return true if g is a 'GIMPLE_DEBUG' that binds the value of an 12803 expression to a variable. 12804 12805 -- GIMPLE function: bool is_gimple_omp (gimple g) 12806 Return true if g is any of the OpenMP codes. 12807 12808 -- GIMPLE function: gimple_debug_begin_stmt_p (gimple g) 12809 Return true if g is a 'GIMPLE_DEBUG' that marks the beginning of a 12810 source statement. 12811 12812 -- GIMPLE function: gimple_debug_inline_entry_p (gimple g) 12813 Return true if g is a 'GIMPLE_DEBUG' that marks the entry point of 12814 an inlined function. 12815 12816 -- GIMPLE function: gimple_debug_nonbind_marker_p (gimple g) 12817 Return true if g is a 'GIMPLE_DEBUG' that marks a program location, 12818 without any variable binding. 12819 12820 12821File: gccint.info, Node: Manipulating GIMPLE statements, Next: Tuple specific accessors, Prev: Operands, Up: GIMPLE 12822 1282312.7 Manipulating GIMPLE statements 12824=================================== 12825 12826This section documents all the functions available to handle each of the 12827GIMPLE instructions. 12828 1282912.7.1 Common accessors 12830----------------------- 12831 12832The following are common accessors for gimple statements. 12833 12834 -- GIMPLE function: enum gimple_code gimple_code (gimple g) 12835 Return the code for statement 'G'. 12836 12837 -- GIMPLE function: basic_block gimple_bb (gimple g) 12838 Return the basic block to which statement 'G' belongs to. 12839 12840 -- GIMPLE function: tree gimple_block (gimple g) 12841 Return the lexical scope block holding statement 'G'. 12842 12843 -- GIMPLE function: tree gimple_expr_type (gimple stmt) 12844 Return the type of the main expression computed by 'STMT'. Return 12845 'void_type_node' if 'STMT' computes nothing. This will only return 12846 something meaningful for 'GIMPLE_ASSIGN', 'GIMPLE_COND' and 12847 'GIMPLE_CALL'. For all other tuple codes, it will return 12848 'void_type_node'. 12849 12850 -- GIMPLE function: enum tree_code gimple_expr_code (gimple stmt) 12851 Return the tree code for the expression computed by 'STMT'. This 12852 is only meaningful for 'GIMPLE_CALL', 'GIMPLE_ASSIGN' and 12853 'GIMPLE_COND'. If 'STMT' is 'GIMPLE_CALL', it will return 12854 'CALL_EXPR'. For 'GIMPLE_COND', it returns the code of the 12855 comparison predicate. For 'GIMPLE_ASSIGN' it returns the code of 12856 the operation performed by the 'RHS' of the assignment. 12857 12858 -- GIMPLE function: void gimple_set_block (gimple g, tree block) 12859 Set the lexical scope block of 'G' to 'BLOCK'. 12860 12861 -- GIMPLE function: location_t gimple_locus (gimple g) 12862 Return locus information for statement 'G'. 12863 12864 -- GIMPLE function: void gimple_set_locus (gimple g, location_t locus) 12865 Set locus information for statement 'G'. 12866 12867 -- GIMPLE function: bool gimple_locus_empty_p (gimple g) 12868 Return true if 'G' does not have locus information. 12869 12870 -- GIMPLE function: bool gimple_no_warning_p (gimple stmt) 12871 Return true if no warnings should be emitted for statement 'STMT'. 12872 12873 -- GIMPLE function: void gimple_set_visited (gimple stmt, bool 12874 visited_p) 12875 Set the visited status on statement 'STMT' to 'VISITED_P'. 12876 12877 -- GIMPLE function: bool gimple_visited_p (gimple stmt) 12878 Return the visited status on statement 'STMT'. 12879 12880 -- GIMPLE function: void gimple_set_plf (gimple stmt, enum plf_mask 12881 plf, bool val_p) 12882 Set pass local flag 'PLF' on statement 'STMT' to 'VAL_P'. 12883 12884 -- GIMPLE function: unsigned int gimple_plf (gimple stmt, enum plf_mask 12885 plf) 12886 Return the value of pass local flag 'PLF' on statement 'STMT'. 12887 12888 -- GIMPLE function: bool gimple_has_ops (gimple g) 12889 Return true if statement 'G' has register or memory operands. 12890 12891 -- GIMPLE function: bool gimple_has_mem_ops (gimple g) 12892 Return true if statement 'G' has memory operands. 12893 12894 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 12895 Return the number of operands for statement 'G'. 12896 12897 -- GIMPLE function: tree * gimple_ops (gimple g) 12898 Return the array of operands for statement 'G'. 12899 12900 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 12901 Return operand 'I' for statement 'G'. 12902 12903 -- GIMPLE function: tree * gimple_op_ptr (gimple g, unsigned i) 12904 Return a pointer to operand 'I' for statement 'G'. 12905 12906 -- GIMPLE function: void gimple_set_op (gimple g, unsigned i, tree op) 12907 Set operand 'I' of statement 'G' to 'OP'. 12908 12909 -- GIMPLE function: bitmap gimple_addresses_taken (gimple stmt) 12910 Return the set of symbols that have had their address taken by 12911 'STMT'. 12912 12913 -- GIMPLE function: struct def_optype_d * gimple_def_ops (gimple g) 12914 Return the set of 'DEF' operands for statement 'G'. 12915 12916 -- GIMPLE function: void gimple_set_def_ops (gimple g, struct 12917 def_optype_d *def) 12918 Set 'DEF' to be the set of 'DEF' operands for statement 'G'. 12919 12920 -- GIMPLE function: struct use_optype_d * gimple_use_ops (gimple g) 12921 Return the set of 'USE' operands for statement 'G'. 12922 12923 -- GIMPLE function: void gimple_set_use_ops (gimple g, struct 12924 use_optype_d *use) 12925 Set 'USE' to be the set of 'USE' operands for statement 'G'. 12926 12927 -- GIMPLE function: struct voptype_d * gimple_vuse_ops (gimple g) 12928 Return the set of 'VUSE' operands for statement 'G'. 12929 12930 -- GIMPLE function: void gimple_set_vuse_ops (gimple g, struct 12931 voptype_d *ops) 12932 Set 'OPS' to be the set of 'VUSE' operands for statement 'G'. 12933 12934 -- GIMPLE function: struct voptype_d * gimple_vdef_ops (gimple g) 12935 Return the set of 'VDEF' operands for statement 'G'. 12936 12937 -- GIMPLE function: void gimple_set_vdef_ops (gimple g, struct 12938 voptype_d *ops) 12939 Set 'OPS' to be the set of 'VDEF' operands for statement 'G'. 12940 12941 -- GIMPLE function: bitmap gimple_loaded_syms (gimple g) 12942 Return the set of symbols loaded by statement 'G'. Each element of 12943 the set is the 'DECL_UID' of the corresponding symbol. 12944 12945 -- GIMPLE function: bitmap gimple_stored_syms (gimple g) 12946 Return the set of symbols stored by statement 'G'. Each element of 12947 the set is the 'DECL_UID' of the corresponding symbol. 12948 12949 -- GIMPLE function: bool gimple_modified_p (gimple g) 12950 Return true if statement 'G' has operands and the modified field 12951 has been set. 12952 12953 -- GIMPLE function: bool gimple_has_volatile_ops (gimple stmt) 12954 Return true if statement 'STMT' contains volatile operands. 12955 12956 -- GIMPLE function: void gimple_set_has_volatile_ops (gimple stmt, bool 12957 volatilep) 12958 Return true if statement 'STMT' contains volatile operands. 12959 12960 -- GIMPLE function: void update_stmt (gimple s) 12961 Mark statement 'S' as modified, and update it. 12962 12963 -- GIMPLE function: void update_stmt_if_modified (gimple s) 12964 Update statement 'S' if it has been marked modified. 12965 12966 -- GIMPLE function: gimple gimple_copy (gimple stmt) 12967 Return a deep copy of statement 'STMT'. 12968 12969 12970File: gccint.info, Node: Tuple specific accessors, Next: GIMPLE sequences, Prev: Manipulating GIMPLE statements, Up: GIMPLE 12971 1297212.8 Tuple specific accessors 12973============================= 12974 12975* Menu: 12976 12977* GIMPLE_ASM:: 12978* GIMPLE_ASSIGN:: 12979* GIMPLE_BIND:: 12980* GIMPLE_CALL:: 12981* GIMPLE_CATCH:: 12982* GIMPLE_COND:: 12983* GIMPLE_DEBUG:: 12984* GIMPLE_EH_FILTER:: 12985* GIMPLE_LABEL:: 12986* GIMPLE_GOTO:: 12987* GIMPLE_NOP:: 12988* GIMPLE_OMP_ATOMIC_LOAD:: 12989* GIMPLE_OMP_ATOMIC_STORE:: 12990* GIMPLE_OMP_CONTINUE:: 12991* GIMPLE_OMP_CRITICAL:: 12992* GIMPLE_OMP_FOR:: 12993* GIMPLE_OMP_MASTER:: 12994* GIMPLE_OMP_ORDERED:: 12995* GIMPLE_OMP_PARALLEL:: 12996* GIMPLE_OMP_RETURN:: 12997* GIMPLE_OMP_SECTION:: 12998* GIMPLE_OMP_SECTIONS:: 12999* GIMPLE_OMP_SINGLE:: 13000* GIMPLE_PHI:: 13001* GIMPLE_RESX:: 13002* GIMPLE_RETURN:: 13003* GIMPLE_SWITCH:: 13004* GIMPLE_TRY:: 13005* GIMPLE_WITH_CLEANUP_EXPR:: 13006 13007 13008File: gccint.info, Node: GIMPLE_ASM, Next: GIMPLE_ASSIGN, Up: Tuple specific accessors 13009 1301012.8.1 'GIMPLE_ASM' 13011------------------- 13012 13013 -- GIMPLE function: gasm *gimple_build_asm_vec ( const char *string, 13014 vec<tree, va_gc> *inputs, vec<tree, va_gc> *outputs, vec<tree, 13015 va_gc> *clobbers, vec<tree, va_gc> *labels) 13016 Build a 'GIMPLE_ASM' statement. This statement is used for 13017 building in-line assembly constructs. 'STRING' is the assembly 13018 code. 'INPUTS', 'OUTPUTS', 'CLOBBERS' and 'LABELS' are the inputs, 13019 outputs, clobbered registers and labels. 13020 13021 -- GIMPLE function: unsigned gimple_asm_ninputs (const gasm *g) 13022 Return the number of input operands for 'GIMPLE_ASM' 'G'. 13023 13024 -- GIMPLE function: unsigned gimple_asm_noutputs (const gasm *g) 13025 Return the number of output operands for 'GIMPLE_ASM' 'G'. 13026 13027 -- GIMPLE function: unsigned gimple_asm_nclobbers (const gasm *g) 13028 Return the number of clobber operands for 'GIMPLE_ASM' 'G'. 13029 13030 -- GIMPLE function: tree gimple_asm_input_op (const gasm *g, unsigned 13031 index) 13032 Return input operand 'INDEX' of 'GIMPLE_ASM' 'G'. 13033 13034 -- GIMPLE function: void gimple_asm_set_input_op (gasm *g, unsigned 13035 index, tree in_op) 13036 Set 'IN_OP' to be input operand 'INDEX' in 'GIMPLE_ASM' 'G'. 13037 13038 -- GIMPLE function: tree gimple_asm_output_op (const gasm *g, unsigned 13039 index) 13040 Return output operand 'INDEX' of 'GIMPLE_ASM' 'G'. 13041 13042 -- GIMPLE function: void gimple_asm_set_output_op (gasm *g, unsigned 13043 index, tree out_op) 13044 Set 'OUT_OP' to be output operand 'INDEX' in 'GIMPLE_ASM' 'G'. 13045 13046 -- GIMPLE function: tree gimple_asm_clobber_op (const gasm *g, unsigned 13047 index) 13048 Return clobber operand 'INDEX' of 'GIMPLE_ASM' 'G'. 13049 13050 -- GIMPLE function: void gimple_asm_set_clobber_op (gasm *g, unsigned 13051 index, tree clobber_op) 13052 Set 'CLOBBER_OP' to be clobber operand 'INDEX' in 'GIMPLE_ASM' 'G'. 13053 13054 -- GIMPLE function: const char * gimple_asm_string (const gasm *g) 13055 Return the string representing the assembly instruction in 13056 'GIMPLE_ASM' 'G'. 13057 13058 -- GIMPLE function: bool gimple_asm_volatile_p (const gasm *g) 13059 Return true if 'G' is an asm statement marked volatile. 13060 13061 -- GIMPLE function: void gimple_asm_set_volatile (gasm *g, bool 13062 volatile_p) 13063 Mark asm statement 'G' as volatile or non-volatile based on 13064 'VOLATILE_P'. 13065 13066 13067File: gccint.info, Node: GIMPLE_ASSIGN, Next: GIMPLE_BIND, Prev: GIMPLE_ASM, Up: Tuple specific accessors 13068 1306912.8.2 'GIMPLE_ASSIGN' 13070---------------------- 13071 13072 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, tree rhs) 13073 Build a 'GIMPLE_ASSIGN' statement. The left-hand side is an lvalue 13074 passed in lhs. The right-hand side can be either a unary or binary 13075 tree expression. The expression tree rhs will be flattened and its 13076 operands assigned to the corresponding operand slots in the new 13077 statement. This function is useful when you already have a tree 13078 expression that you want to convert into a tuple. However, try to 13079 avoid building expression trees for the sole purpose of calling 13080 this function. If you already have the operands in separate trees, 13081 it is better to use 'gimple_build_assign' with 'enum tree_code' 13082 argument and separate arguments for each operand. 13083 13084 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 13085 tree_code subcode, tree op1, tree op2, tree op3) 13086 This function is similar to two operand 'gimple_build_assign', but 13087 is used to build a 'GIMPLE_ASSIGN' statement when the operands of 13088 the right-hand side of the assignment are already split into 13089 different operands. 13090 13091 The left-hand side is an lvalue passed in lhs. Subcode is the 13092 'tree_code' for the right-hand side of the assignment. Op1, op2 13093 and op3 are the operands. 13094 13095 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 13096 tree_code subcode, tree op1, tree op2) 13097 Like the above 5 operand 'gimple_build_assign', but with the last 13098 argument 'NULL' - this overload should not be used for 13099 'GIMPLE_TERNARY_RHS' assignments. 13100 13101 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 13102 tree_code subcode, tree op1) 13103 Like the above 4 operand 'gimple_build_assign', but with the last 13104 argument 'NULL' - this overload should be used only for 13105 'GIMPLE_UNARY_RHS' and 'GIMPLE_SINGLE_RHS' assignments. 13106 13107 -- GIMPLE function: gimple gimplify_assign (tree dst, tree src, 13108 gimple_seq *seq_p) 13109 Build a new 'GIMPLE_ASSIGN' tuple and append it to the end of 13110 '*SEQ_P'. 13111 13112 'DST'/'SRC' are the destination and source respectively. You can pass 13113ungimplified trees in 'DST' or 'SRC', in which case they will be 13114converted to a gimple operand if necessary. 13115 13116 This function returns the newly created 'GIMPLE_ASSIGN' tuple. 13117 13118 -- GIMPLE function: enum tree_code gimple_assign_rhs_code (gimple g) 13119 Return the code of the expression computed on the 'RHS' of 13120 assignment statement 'G'. 13121 13122 -- GIMPLE function: enum gimple_rhs_class gimple_assign_rhs_class 13123 (gimple g) 13124 Return the gimple rhs class of the code for the expression computed 13125 on the rhs of assignment statement 'G'. This will never return 13126 'GIMPLE_INVALID_RHS'. 13127 13128 -- GIMPLE function: tree gimple_assign_lhs (gimple g) 13129 Return the 'LHS' of assignment statement 'G'. 13130 13131 -- GIMPLE function: tree * gimple_assign_lhs_ptr (gimple g) 13132 Return a pointer to the 'LHS' of assignment statement 'G'. 13133 13134 -- GIMPLE function: tree gimple_assign_rhs1 (gimple g) 13135 Return the first operand on the 'RHS' of assignment statement 'G'. 13136 13137 -- GIMPLE function: tree * gimple_assign_rhs1_ptr (gimple g) 13138 Return the address of the first operand on the 'RHS' of assignment 13139 statement 'G'. 13140 13141 -- GIMPLE function: tree gimple_assign_rhs2 (gimple g) 13142 Return the second operand on the 'RHS' of assignment statement 'G'. 13143 13144 -- GIMPLE function: tree * gimple_assign_rhs2_ptr (gimple g) 13145 Return the address of the second operand on the 'RHS' of assignment 13146 statement 'G'. 13147 13148 -- GIMPLE function: tree gimple_assign_rhs3 (gimple g) 13149 Return the third operand on the 'RHS' of assignment statement 'G'. 13150 13151 -- GIMPLE function: tree * gimple_assign_rhs3_ptr (gimple g) 13152 Return the address of the third operand on the 'RHS' of assignment 13153 statement 'G'. 13154 13155 -- GIMPLE function: void gimple_assign_set_lhs (gimple g, tree lhs) 13156 Set 'LHS' to be the 'LHS' operand of assignment statement 'G'. 13157 13158 -- GIMPLE function: void gimple_assign_set_rhs1 (gimple g, tree rhs) 13159 Set 'RHS' to be the first operand on the 'RHS' of assignment 13160 statement 'G'. 13161 13162 -- GIMPLE function: void gimple_assign_set_rhs2 (gimple g, tree rhs) 13163 Set 'RHS' to be the second operand on the 'RHS' of assignment 13164 statement 'G'. 13165 13166 -- GIMPLE function: void gimple_assign_set_rhs3 (gimple g, tree rhs) 13167 Set 'RHS' to be the third operand on the 'RHS' of assignment 13168 statement 'G'. 13169 13170 -- GIMPLE function: bool gimple_assign_cast_p (const_gimple s) 13171 Return true if 'S' is a type-cast assignment. 13172 13173 13174File: gccint.info, Node: GIMPLE_BIND, Next: GIMPLE_CALL, Prev: GIMPLE_ASSIGN, Up: Tuple specific accessors 13175 1317612.8.3 'GIMPLE_BIND' 13177-------------------- 13178 13179 -- GIMPLE function: gbind *gimple_build_bind (tree vars, gimple_seq 13180 body) 13181 Build a 'GIMPLE_BIND' statement with a list of variables in 'VARS' 13182 and a body of statements in sequence 'BODY'. 13183 13184 -- GIMPLE function: tree gimple_bind_vars (const gbind *g) 13185 Return the variables declared in the 'GIMPLE_BIND' statement 'G'. 13186 13187 -- GIMPLE function: void gimple_bind_set_vars (gbind *g, tree vars) 13188 Set 'VARS' to be the set of variables declared in the 'GIMPLE_BIND' 13189 statement 'G'. 13190 13191 -- GIMPLE function: void gimple_bind_append_vars (gbind *g, tree vars) 13192 Append 'VARS' to the set of variables declared in the 'GIMPLE_BIND' 13193 statement 'G'. 13194 13195 -- GIMPLE function: gimple_seq gimple_bind_body (gbind *g) 13196 Return the GIMPLE sequence contained in the 'GIMPLE_BIND' statement 13197 'G'. 13198 13199 -- GIMPLE function: void gimple_bind_set_body (gbind *g, gimple_seq 13200 seq) 13201 Set 'SEQ' to be sequence contained in the 'GIMPLE_BIND' statement 13202 'G'. 13203 13204 -- GIMPLE function: void gimple_bind_add_stmt (gbind *gs, gimple stmt) 13205 Append a statement to the end of a 'GIMPLE_BIND''s body. 13206 13207 -- GIMPLE function: void gimple_bind_add_seq (gbind *gs, gimple_seq 13208 seq) 13209 Append a sequence of statements to the end of a 'GIMPLE_BIND''s 13210 body. 13211 13212 -- GIMPLE function: tree gimple_bind_block (const gbind *g) 13213 Return the 'TREE_BLOCK' node associated with 'GIMPLE_BIND' 13214 statement 'G'. This is analogous to the 'BIND_EXPR_BLOCK' field in 13215 trees. 13216 13217 -- GIMPLE function: void gimple_bind_set_block (gbind *g, tree block) 13218 Set 'BLOCK' to be the 'TREE_BLOCK' node associated with 13219 'GIMPLE_BIND' statement 'G'. 13220 13221 13222File: gccint.info, Node: GIMPLE_CALL, Next: GIMPLE_CATCH, Prev: GIMPLE_BIND, Up: Tuple specific accessors 13223 1322412.8.4 'GIMPLE_CALL' 13225-------------------- 13226 13227 -- GIMPLE function: gcall *gimple_build_call (tree fn, unsigned nargs, 13228 ...) 13229 Build a 'GIMPLE_CALL' statement to function 'FN'. The argument 13230 'FN' must be either a 'FUNCTION_DECL' or a gimple call address as 13231 determined by 'is_gimple_call_addr'. 'NARGS' are the number of 13232 arguments. The rest of the arguments follow the argument 'NARGS', 13233 and must be trees that are valid as rvalues in gimple (i.e., each 13234 operand is validated with 'is_gimple_operand'). 13235 13236 -- GIMPLE function: gcall *gimple_build_call_from_tree (tree call_expr, 13237 tree fnptrtype) 13238 Build a 'GIMPLE_CALL' from a 'CALL_EXPR' node. The arguments and 13239 the function are taken from the expression directly. The type of 13240 the 'GIMPLE_CALL' is set from the second parameter passed by a 13241 caller. This routine assumes that 'call_expr' is already in GIMPLE 13242 form. That is, its operands are GIMPLE values and the function 13243 call needs no further simplification. All the call flags in 13244 'call_expr' are copied over to the new 'GIMPLE_CALL'. 13245 13246 -- GIMPLE function: gcall *gimple_build_call_vec (tree fn, 'vec<tree>' 13247 args) 13248 Identical to 'gimple_build_call' but the arguments are stored in a 13249 'vec<tree>'. 13250 13251 -- GIMPLE function: tree gimple_call_lhs (gimple g) 13252 Return the 'LHS' of call statement 'G'. 13253 13254 -- GIMPLE function: tree * gimple_call_lhs_ptr (gimple g) 13255 Return a pointer to the 'LHS' of call statement 'G'. 13256 13257 -- GIMPLE function: void gimple_call_set_lhs (gimple g, tree lhs) 13258 Set 'LHS' to be the 'LHS' operand of call statement 'G'. 13259 13260 -- GIMPLE function: tree gimple_call_fn (gimple g) 13261 Return the tree node representing the function called by call 13262 statement 'G'. 13263 13264 -- GIMPLE function: void gimple_call_set_fn (gcall *g, tree fn) 13265 Set 'FN' to be the function called by call statement 'G'. This has 13266 to be a gimple value specifying the address of the called function. 13267 13268 -- GIMPLE function: tree gimple_call_fndecl (gimple g) 13269 If a given 'GIMPLE_CALL''s callee is a 'FUNCTION_DECL', return it. 13270 Otherwise return 'NULL'. This function is analogous to 13271 'get_callee_fndecl' in 'GENERIC'. 13272 13273 -- GIMPLE function: tree gimple_call_set_fndecl (gimple g, tree fndecl) 13274 Set the called function to 'FNDECL'. 13275 13276 -- GIMPLE function: tree gimple_call_return_type (const gcall *g) 13277 Return the type returned by call statement 'G'. 13278 13279 -- GIMPLE function: tree gimple_call_chain (gimple g) 13280 Return the static chain for call statement 'G'. 13281 13282 -- GIMPLE function: void gimple_call_set_chain (gcall *g, tree chain) 13283 Set 'CHAIN' to be the static chain for call statement 'G'. 13284 13285 -- GIMPLE function: unsigned gimple_call_num_args (gimple g) 13286 Return the number of arguments used by call statement 'G'. 13287 13288 -- GIMPLE function: tree gimple_call_arg (gimple g, unsigned index) 13289 Return the argument at position 'INDEX' for call statement 'G'. 13290 The first argument is 0. 13291 13292 -- GIMPLE function: tree * gimple_call_arg_ptr (gimple g, unsigned 13293 index) 13294 Return a pointer to the argument at position 'INDEX' for call 13295 statement 'G'. 13296 13297 -- GIMPLE function: void gimple_call_set_arg (gimple g, unsigned index, 13298 tree arg) 13299 Set 'ARG' to be the argument at position 'INDEX' for call statement 13300 'G'. 13301 13302 -- GIMPLE function: void gimple_call_set_tail (gcall *s) 13303 Mark call statement 'S' as being a tail call (i.e., a call just 13304 before the exit of a function). These calls are candidate for tail 13305 call optimization. 13306 13307 -- GIMPLE function: bool gimple_call_tail_p (gcall *s) 13308 Return true if 'GIMPLE_CALL' 'S' is marked as a tail call. 13309 13310 -- GIMPLE function: bool gimple_call_noreturn_p (gimple s) 13311 Return true if 'S' is a noreturn call. 13312 13313 -- GIMPLE function: gimple gimple_call_copy_skip_args (gcall *stmt, 13314 bitmap args_to_skip) 13315 Build a 'GIMPLE_CALL' identical to 'STMT' but skipping the 13316 arguments in the positions marked by the set 'ARGS_TO_SKIP'. 13317 13318 13319File: gccint.info, Node: GIMPLE_CATCH, Next: GIMPLE_COND, Prev: GIMPLE_CALL, Up: Tuple specific accessors 13320 1332112.8.5 'GIMPLE_CATCH' 13322--------------------- 13323 13324 -- GIMPLE function: gcatch *gimple_build_catch (tree types, gimple_seq 13325 handler) 13326 Build a 'GIMPLE_CATCH' statement. 'TYPES' are the tree types this 13327 catch handles. 'HANDLER' is a sequence of statements with the code 13328 for the handler. 13329 13330 -- GIMPLE function: tree gimple_catch_types (const gcatch *g) 13331 Return the types handled by 'GIMPLE_CATCH' statement 'G'. 13332 13333 -- GIMPLE function: tree * gimple_catch_types_ptr (gcatch *g) 13334 Return a pointer to the types handled by 'GIMPLE_CATCH' statement 13335 'G'. 13336 13337 -- GIMPLE function: gimple_seq gimple_catch_handler (gcatch *g) 13338 Return the GIMPLE sequence representing the body of the handler of 13339 'GIMPLE_CATCH' statement 'G'. 13340 13341 -- GIMPLE function: void gimple_catch_set_types (gcatch *g, tree t) 13342 Set 'T' to be the set of types handled by 'GIMPLE_CATCH' 'G'. 13343 13344 -- GIMPLE function: void gimple_catch_set_handler (gcatch *g, 13345 gimple_seq handler) 13346 Set 'HANDLER' to be the body of 'GIMPLE_CATCH' 'G'. 13347 13348 13349File: gccint.info, Node: GIMPLE_COND, Next: GIMPLE_DEBUG, Prev: GIMPLE_CATCH, Up: Tuple specific accessors 13350 1335112.8.6 'GIMPLE_COND' 13352-------------------- 13353 13354 -- GIMPLE function: gcond *gimple_build_cond ( enum tree_code 13355 pred_code, tree lhs, tree rhs, tree t_label, tree f_label) 13356 Build a 'GIMPLE_COND' statement. 'A' 'GIMPLE_COND' statement 13357 compares 'LHS' and 'RHS' and if the condition in 'PRED_CODE' is 13358 true, jump to the label in 't_label', otherwise jump to the label 13359 in 'f_label'. 'PRED_CODE' are relational operator tree codes like 13360 'EQ_EXPR', 'LT_EXPR', 'LE_EXPR', 'NE_EXPR', etc. 13361 13362 -- GIMPLE function: gcond *gimple_build_cond_from_tree (tree cond, tree 13363 t_label, tree f_label) 13364 Build a 'GIMPLE_COND' statement from the conditional expression 13365 tree 'COND'. 'T_LABEL' and 'F_LABEL' are as in 13366 'gimple_build_cond'. 13367 13368 -- GIMPLE function: enum tree_code gimple_cond_code (gimple g) 13369 Return the code of the predicate computed by conditional statement 13370 'G'. 13371 13372 -- GIMPLE function: void gimple_cond_set_code (gcond *g, enum tree_code 13373 code) 13374 Set 'CODE' to be the predicate code for the conditional statement 13375 'G'. 13376 13377 -- GIMPLE function: tree gimple_cond_lhs (gimple g) 13378 Return the 'LHS' of the predicate computed by conditional statement 13379 'G'. 13380 13381 -- GIMPLE function: void gimple_cond_set_lhs (gcond *g, tree lhs) 13382 Set 'LHS' to be the 'LHS' operand of the predicate computed by 13383 conditional statement 'G'. 13384 13385 -- GIMPLE function: tree gimple_cond_rhs (gimple g) 13386 Return the 'RHS' operand of the predicate computed by conditional 13387 'G'. 13388 13389 -- GIMPLE function: void gimple_cond_set_rhs (gcond *g, tree rhs) 13390 Set 'RHS' to be the 'RHS' operand of the predicate computed by 13391 conditional statement 'G'. 13392 13393 -- GIMPLE function: tree gimple_cond_true_label (const gcond *g) 13394 Return the label used by conditional statement 'G' when its 13395 predicate evaluates to true. 13396 13397 -- GIMPLE function: void gimple_cond_set_true_label (gcond *g, tree 13398 label) 13399 Set 'LABEL' to be the label used by conditional statement 'G' when 13400 its predicate evaluates to true. 13401 13402 -- GIMPLE function: void gimple_cond_set_false_label (gcond *g, tree 13403 label) 13404 Set 'LABEL' to be the label used by conditional statement 'G' when 13405 its predicate evaluates to false. 13406 13407 -- GIMPLE function: tree gimple_cond_false_label (const gcond *g) 13408 Return the label used by conditional statement 'G' when its 13409 predicate evaluates to false. 13410 13411 -- GIMPLE function: void gimple_cond_make_false (gcond *g) 13412 Set the conditional 'COND_STMT' to be of the form 'if (1 == 0)'. 13413 13414 -- GIMPLE function: void gimple_cond_make_true (gcond *g) 13415 Set the conditional 'COND_STMT' to be of the form 'if (1 == 1)'. 13416 13417 13418File: gccint.info, Node: GIMPLE_DEBUG, Next: GIMPLE_EH_FILTER, Prev: GIMPLE_COND, Up: Tuple specific accessors 13419 1342012.8.7 'GIMPLE_DEBUG' 13421--------------------- 13422 13423 -- GIMPLE function: gdebug *gimple_build_debug_bind (tree var, tree 13424 value, gimple stmt) 13425 Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_BIND' 13426 'subcode'. The effect of this statement is to tell debug 13427 information generation machinery that the value of user variable 13428 'var' is given by 'value' at that point, and to remain with that 13429 value until 'var' runs out of scope, a dynamically-subsequent debug 13430 bind statement overrides the binding, or conflicting values reach a 13431 control flow merge point. Even if components of the 'value' 13432 expression change afterwards, the variable is supposed to retain 13433 the same value, though not necessarily the same location. 13434 13435 It is expected that 'var' be most often a tree for automatic user 13436 variables ('VAR_DECL' or 'PARM_DECL') that satisfy the requirements 13437 for gimple registers, but it may also be a tree for a scalarized 13438 component of a user variable ('ARRAY_REF', 'COMPONENT_REF'), or a 13439 debug temporary ('DEBUG_EXPR_DECL'). 13440 13441 As for 'value', it can be an arbitrary tree expression, but it is 13442 recommended that it be in a suitable form for a gimple assignment 13443 'RHS'. It is not expected that user variables that could appear as 13444 'var' ever appear in 'value', because in the latter we'd have their 13445 'SSA_NAME's instead, but even if they were not in SSA form, user 13446 variables appearing in 'value' are to be regarded as part of the 13447 executable code space, whereas those in 'var' are to be regarded as 13448 part of the source code space. There is no way to refer to the 13449 value bound to a user variable within a 'value' expression. 13450 13451 If 'value' is 'GIMPLE_DEBUG_BIND_NOVALUE', debug information 13452 generation machinery is informed that the variable 'var' is 13453 unbound, i.e., that its value is indeterminate, which sometimes 13454 means it is really unavailable, and other times that the compiler 13455 could not keep track of it. 13456 13457 Block and location information for the newly-created stmt are taken 13458 from 'stmt', if given. 13459 13460 -- GIMPLE function: tree gimple_debug_bind_get_var (gimple stmt) 13461 Return the user variable VAR that is bound at 'stmt'. 13462 13463 -- GIMPLE function: tree gimple_debug_bind_get_value (gimple stmt) 13464 Return the value expression that is bound to a user variable at 13465 'stmt'. 13466 13467 -- GIMPLE function: tree * gimple_debug_bind_get_value_ptr (gimple 13468 stmt) 13469 Return a pointer to the value expression that is bound to a user 13470 variable at 'stmt'. 13471 13472 -- GIMPLE function: void gimple_debug_bind_set_var (gimple stmt, tree 13473 var) 13474 Modify the user variable bound at 'stmt' to VAR. 13475 13476 -- GIMPLE function: void gimple_debug_bind_set_value (gimple stmt, tree 13477 var) 13478 Modify the value bound to the user variable bound at 'stmt' to 13479 VALUE. 13480 13481 -- GIMPLE function: void gimple_debug_bind_reset_value (gimple stmt) 13482 Modify the value bound to the user variable bound at 'stmt' so that 13483 the variable becomes unbound. 13484 13485 -- GIMPLE function: bool gimple_debug_bind_has_value_p (gimple stmt) 13486 Return 'TRUE' if 'stmt' binds a user variable to a value, and 13487 'FALSE' if it unbinds the variable. 13488 13489 -- GIMPLE function: gimple gimple_build_debug_begin_stmt (tree block, 13490 location_t location) 13491 Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_BEGIN_STMT' 13492 'subcode'. The effect of this statement is to tell debug 13493 information generation machinery that the user statement at the 13494 given 'location' and 'block' starts at the point at which the 13495 statement is inserted. The intent is that side effects (e.g. 13496 variable bindings) of all prior user statements are observable, and 13497 that none of the side effects of subsequent user statements are. 13498 13499 -- GIMPLE function: gimple gimple_build_debug_inline_entry (tree block, 13500 location_t location) 13501 Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_INLINE_ENTRY' 13502 'subcode'. The effect of this statement is to tell debug 13503 information generation machinery that a function call at 'location' 13504 underwent inline substitution, that 'block' is the enclosing 13505 lexical block created for the substitution, and that at the point 13506 of the program in which the stmt is inserted, all parameters for 13507 the inlined function are bound to the respective arguments, and 13508 none of the side effects of its stmts are observable. 13509 13510 13511File: gccint.info, Node: GIMPLE_EH_FILTER, Next: GIMPLE_LABEL, Prev: GIMPLE_DEBUG, Up: Tuple specific accessors 13512 1351312.8.8 'GIMPLE_EH_FILTER' 13514------------------------- 13515 13516 -- GIMPLE function: geh_filter *gimple_build_eh_filter (tree types, 13517 gimple_seq failure) 13518 Build a 'GIMPLE_EH_FILTER' statement. 'TYPES' are the filter's 13519 types. 'FAILURE' is a sequence with the filter's failure action. 13520 13521 -- GIMPLE function: tree gimple_eh_filter_types (gimple g) 13522 Return the types handled by 'GIMPLE_EH_FILTER' statement 'G'. 13523 13524 -- GIMPLE function: tree * gimple_eh_filter_types_ptr (gimple g) 13525 Return a pointer to the types handled by 'GIMPLE_EH_FILTER' 13526 statement 'G'. 13527 13528 -- GIMPLE function: gimple_seq gimple_eh_filter_failure (gimple g) 13529 Return the sequence of statement to execute when 'GIMPLE_EH_FILTER' 13530 statement fails. 13531 13532 -- GIMPLE function: void gimple_eh_filter_set_types (geh_filter *g, 13533 tree types) 13534 Set 'TYPES' to be the set of types handled by 'GIMPLE_EH_FILTER' 13535 'G'. 13536 13537 -- GIMPLE function: void gimple_eh_filter_set_failure (geh_filter *g, 13538 gimple_seq failure) 13539 Set 'FAILURE' to be the sequence of statements to execute on 13540 failure for 'GIMPLE_EH_FILTER' 'G'. 13541 13542 -- GIMPLE function: tree gimple_eh_must_not_throw_fndecl ( geh_mnt 13543 *eh_mnt_stmt) 13544 Get the function decl to be called by the MUST_NOT_THROW region. 13545 13546 -- GIMPLE function: void gimple_eh_must_not_throw_set_fndecl ( geh_mnt 13547 *eh_mnt_stmt, tree decl) 13548 Set the function decl to be called by GS to DECL. 13549 13550 13551File: gccint.info, Node: GIMPLE_LABEL, Next: GIMPLE_GOTO, Prev: GIMPLE_EH_FILTER, Up: Tuple specific accessors 13552 1355312.8.9 'GIMPLE_LABEL' 13554--------------------- 13555 13556 -- GIMPLE function: glabel *gimple_build_label (tree label) 13557 Build a 'GIMPLE_LABEL' statement with corresponding to the tree 13558 label, 'LABEL'. 13559 13560 -- GIMPLE function: tree gimple_label_label (const glabel *g) 13561 Return the 'LABEL_DECL' node used by 'GIMPLE_LABEL' statement 'G'. 13562 13563 -- GIMPLE function: void gimple_label_set_label (glabel *g, tree label) 13564 Set 'LABEL' to be the 'LABEL_DECL' node used by 'GIMPLE_LABEL' 13565 statement 'G'. 13566 13567 13568File: gccint.info, Node: GIMPLE_GOTO, Next: GIMPLE_NOP, Prev: GIMPLE_LABEL, Up: Tuple specific accessors 13569 1357012.8.10 'GIMPLE_GOTO' 13571--------------------- 13572 13573 -- GIMPLE function: ggoto *gimple_build_goto (tree dest) 13574 Build a 'GIMPLE_GOTO' statement to label 'DEST'. 13575 13576 -- GIMPLE function: tree gimple_goto_dest (gimple g) 13577 Return the destination of the unconditional jump 'G'. 13578 13579 -- GIMPLE function: void gimple_goto_set_dest (ggoto *g, tree dest) 13580 Set 'DEST' to be the destination of the unconditional jump 'G'. 13581 13582 13583File: gccint.info, Node: GIMPLE_NOP, Next: GIMPLE_OMP_ATOMIC_LOAD, Prev: GIMPLE_GOTO, Up: Tuple specific accessors 13584 1358512.8.11 'GIMPLE_NOP' 13586-------------------- 13587 13588 -- GIMPLE function: gimple gimple_build_nop (void) 13589 Build a 'GIMPLE_NOP' statement. 13590 13591 -- GIMPLE function: bool gimple_nop_p (gimple g) 13592 Returns 'TRUE' if statement 'G' is a 'GIMPLE_NOP'. 13593 13594 13595File: gccint.info, Node: GIMPLE_OMP_ATOMIC_LOAD, Next: GIMPLE_OMP_ATOMIC_STORE, Prev: GIMPLE_NOP, Up: Tuple specific accessors 13596 1359712.8.12 'GIMPLE_OMP_ATOMIC_LOAD' 13598-------------------------------- 13599 13600 -- GIMPLE function: gomp_atomic_load *gimple_build_omp_atomic_load ( 13601 tree lhs, tree rhs) 13602 Build a 'GIMPLE_OMP_ATOMIC_LOAD' statement. 'LHS' is the left-hand 13603 side of the assignment. 'RHS' is the right-hand side of the 13604 assignment. 13605 13606 -- GIMPLE function: void gimple_omp_atomic_load_set_lhs ( 13607 gomp_atomic_load *g, tree lhs) 13608 Set the 'LHS' of an atomic load. 13609 13610 -- GIMPLE function: tree gimple_omp_atomic_load_lhs ( const 13611 gomp_atomic_load *g) 13612 Get the 'LHS' of an atomic load. 13613 13614 -- GIMPLE function: void gimple_omp_atomic_load_set_rhs ( 13615 gomp_atomic_load *g, tree rhs) 13616 Set the 'RHS' of an atomic set. 13617 13618 -- GIMPLE function: tree gimple_omp_atomic_load_rhs ( const 13619 gomp_atomic_load *g) 13620 Get the 'RHS' of an atomic set. 13621 13622 13623File: gccint.info, Node: GIMPLE_OMP_ATOMIC_STORE, Next: GIMPLE_OMP_CONTINUE, Prev: GIMPLE_OMP_ATOMIC_LOAD, Up: Tuple specific accessors 13624 1362512.8.13 'GIMPLE_OMP_ATOMIC_STORE' 13626--------------------------------- 13627 13628 -- GIMPLE function: gomp_atomic_store *gimple_build_omp_atomic_store ( 13629 tree val) 13630 Build a 'GIMPLE_OMP_ATOMIC_STORE' statement. 'VAL' is the value to 13631 be stored. 13632 13633 -- GIMPLE function: void gimple_omp_atomic_store_set_val ( 13634 gomp_atomic_store *g, tree val) 13635 Set the value being stored in an atomic store. 13636 13637 -- GIMPLE function: tree gimple_omp_atomic_store_val ( const 13638 gomp_atomic_store *g) 13639 Return the value being stored in an atomic store. 13640 13641 13642File: gccint.info, Node: GIMPLE_OMP_CONTINUE, Next: GIMPLE_OMP_CRITICAL, Prev: GIMPLE_OMP_ATOMIC_STORE, Up: Tuple specific accessors 13643 1364412.8.14 'GIMPLE_OMP_CONTINUE' 13645----------------------------- 13646 13647 -- GIMPLE function: gomp_continue *gimple_build_omp_continue ( tree 13648 control_def, tree control_use) 13649 Build a 'GIMPLE_OMP_CONTINUE' statement. 'CONTROL_DEF' is the 13650 definition of the control variable. 'CONTROL_USE' is the use of 13651 the control variable. 13652 13653 -- GIMPLE function: tree gimple_omp_continue_control_def ( const 13654 gomp_continue *s) 13655 Return the definition of the control variable on a 13656 'GIMPLE_OMP_CONTINUE' in 'S'. 13657 13658 -- GIMPLE function: tree gimple_omp_continue_control_def_ptr ( 13659 gomp_continue *s) 13660 Same as above, but return the pointer. 13661 13662 -- GIMPLE function: tree gimple_omp_continue_set_control_def ( 13663 gomp_continue *s) 13664 Set the control variable definition for a 'GIMPLE_OMP_CONTINUE' 13665 statement in 'S'. 13666 13667 -- GIMPLE function: tree gimple_omp_continue_control_use ( const 13668 gomp_continue *s) 13669 Return the use of the control variable on a 'GIMPLE_OMP_CONTINUE' 13670 in 'S'. 13671 13672 -- GIMPLE function: tree gimple_omp_continue_control_use_ptr ( 13673 gomp_continue *s) 13674 Same as above, but return the pointer. 13675 13676 -- GIMPLE function: tree gimple_omp_continue_set_control_use ( 13677 gomp_continue *s) 13678 Set the control variable use for a 'GIMPLE_OMP_CONTINUE' statement 13679 in 'S'. 13680 13681 13682File: gccint.info, Node: GIMPLE_OMP_CRITICAL, Next: GIMPLE_OMP_FOR, Prev: GIMPLE_OMP_CONTINUE, Up: Tuple specific accessors 13683 1368412.8.15 'GIMPLE_OMP_CRITICAL' 13685----------------------------- 13686 13687 -- GIMPLE function: gomp_critical *gimple_build_omp_critical ( 13688 gimple_seq body, tree name) 13689 Build a 'GIMPLE_OMP_CRITICAL' statement. 'BODY' is the sequence of 13690 statements for which only one thread can execute. 'NAME' is an 13691 optional identifier for this critical block. 13692 13693 -- GIMPLE function: tree gimple_omp_critical_name ( const gomp_critical 13694 *g) 13695 Return the name associated with 'OMP_CRITICAL' statement 'G'. 13696 13697 -- GIMPLE function: tree * gimple_omp_critical_name_ptr ( gomp_critical 13698 *g) 13699 Return a pointer to the name associated with 'OMP' critical 13700 statement 'G'. 13701 13702 -- GIMPLE function: void gimple_omp_critical_set_name ( gomp_critical 13703 *g, tree name) 13704 Set 'NAME' to be the name associated with 'OMP' critical statement 13705 'G'. 13706 13707 13708File: gccint.info, Node: GIMPLE_OMP_FOR, Next: GIMPLE_OMP_MASTER, Prev: GIMPLE_OMP_CRITICAL, Up: Tuple specific accessors 13709 1371012.8.16 'GIMPLE_OMP_FOR' 13711------------------------ 13712 13713 -- GIMPLE function: gomp_for *gimple_build_omp_for (gimple_seq body, 13714 tree clauses, tree index, tree initial, tree final, tree incr, 13715 gimple_seq pre_body, enum tree_code omp_for_cond) 13716 Build a 'GIMPLE_OMP_FOR' statement. 'BODY' is sequence of 13717 statements inside the for loop. 'CLAUSES', are any of the loop 13718 construct's clauses. 'PRE_BODY' is the sequence of statements that 13719 are loop invariant. 'INDEX' is the index variable. 'INITIAL' is 13720 the initial value of 'INDEX'. 'FINAL' is final value of 'INDEX'. 13721 OMP_FOR_COND is the predicate used to compare 'INDEX' and 'FINAL'. 13722 'INCR' is the increment expression. 13723 13724 -- GIMPLE function: tree gimple_omp_for_clauses (gimple g) 13725 Return the clauses associated with 'OMP_FOR' 'G'. 13726 13727 -- GIMPLE function: tree * gimple_omp_for_clauses_ptr (gimple g) 13728 Return a pointer to the 'OMP_FOR' 'G'. 13729 13730 -- GIMPLE function: void gimple_omp_for_set_clauses (gimple g, tree 13731 clauses) 13732 Set 'CLAUSES' to be the list of clauses associated with 'OMP_FOR' 13733 'G'. 13734 13735 -- GIMPLE function: tree gimple_omp_for_index (gimple g) 13736 Return the index variable for 'OMP_FOR' 'G'. 13737 13738 -- GIMPLE function: tree * gimple_omp_for_index_ptr (gimple g) 13739 Return a pointer to the index variable for 'OMP_FOR' 'G'. 13740 13741 -- GIMPLE function: void gimple_omp_for_set_index (gimple g, tree 13742 index) 13743 Set 'INDEX' to be the index variable for 'OMP_FOR' 'G'. 13744 13745 -- GIMPLE function: tree gimple_omp_for_initial (gimple g) 13746 Return the initial value for 'OMP_FOR' 'G'. 13747 13748 -- GIMPLE function: tree * gimple_omp_for_initial_ptr (gimple g) 13749 Return a pointer to the initial value for 'OMP_FOR' 'G'. 13750 13751 -- GIMPLE function: void gimple_omp_for_set_initial (gimple g, tree 13752 initial) 13753 Set 'INITIAL' to be the initial value for 'OMP_FOR' 'G'. 13754 13755 -- GIMPLE function: tree gimple_omp_for_final (gimple g) 13756 Return the final value for 'OMP_FOR' 'G'. 13757 13758 -- GIMPLE function: tree * gimple_omp_for_final_ptr (gimple g) 13759 turn a pointer to the final value for 'OMP_FOR' 'G'. 13760 13761 -- GIMPLE function: void gimple_omp_for_set_final (gimple g, tree 13762 final) 13763 Set 'FINAL' to be the final value for 'OMP_FOR' 'G'. 13764 13765 -- GIMPLE function: tree gimple_omp_for_incr (gimple g) 13766 Return the increment value for 'OMP_FOR' 'G'. 13767 13768 -- GIMPLE function: tree * gimple_omp_for_incr_ptr (gimple g) 13769 Return a pointer to the increment value for 'OMP_FOR' 'G'. 13770 13771 -- GIMPLE function: void gimple_omp_for_set_incr (gimple g, tree incr) 13772 Set 'INCR' to be the increment value for 'OMP_FOR' 'G'. 13773 13774 -- GIMPLE function: gimple_seq gimple_omp_for_pre_body (gimple g) 13775 Return the sequence of statements to execute before the 'OMP_FOR' 13776 statement 'G' starts. 13777 13778 -- GIMPLE function: void gimple_omp_for_set_pre_body (gimple g, 13779 gimple_seq pre_body) 13780 Set 'PRE_BODY' to be the sequence of statements to execute before 13781 the 'OMP_FOR' statement 'G' starts. 13782 13783 -- GIMPLE function: void gimple_omp_for_set_cond (gimple g, enum 13784 tree_code cond) 13785 Set 'COND' to be the condition code for 'OMP_FOR' 'G'. 13786 13787 -- GIMPLE function: enum tree_code gimple_omp_for_cond (gimple g) 13788 Return the condition code associated with 'OMP_FOR' 'G'. 13789 13790 13791File: gccint.info, Node: GIMPLE_OMP_MASTER, Next: GIMPLE_OMP_ORDERED, Prev: GIMPLE_OMP_FOR, Up: Tuple specific accessors 13792 1379312.8.17 'GIMPLE_OMP_MASTER' 13794--------------------------- 13795 13796 -- GIMPLE function: gimple gimple_build_omp_master (gimple_seq body) 13797 Build a 'GIMPLE_OMP_MASTER' statement. 'BODY' is the sequence of 13798 statements to be executed by just the master. 13799 13800 13801File: gccint.info, Node: GIMPLE_OMP_ORDERED, Next: GIMPLE_OMP_PARALLEL, Prev: GIMPLE_OMP_MASTER, Up: Tuple specific accessors 13802 1380312.8.18 'GIMPLE_OMP_ORDERED' 13804---------------------------- 13805 13806 -- GIMPLE function: gimple gimple_build_omp_ordered (gimple_seq body) 13807 Build a 'GIMPLE_OMP_ORDERED' statement. 13808 13809 'BODY' is the sequence of statements inside a loop that will executed 13810in sequence. 13811 13812 13813File: gccint.info, Node: GIMPLE_OMP_PARALLEL, Next: GIMPLE_OMP_RETURN, Prev: GIMPLE_OMP_ORDERED, Up: Tuple specific accessors 13814 1381512.8.19 'GIMPLE_OMP_PARALLEL' 13816----------------------------- 13817 13818 -- GIMPLE function: gomp_parallel *gimple_build_omp_parallel 13819 (gimple_seq body, tree clauses, tree child_fn, tree data_arg) 13820 Build a 'GIMPLE_OMP_PARALLEL' statement. 13821 13822 'BODY' is sequence of statements which are executed in parallel. 13823'CLAUSES', are the 'OMP' parallel construct's clauses. 'CHILD_FN' is 13824the function created for the parallel threads to execute. 'DATA_ARG' 13825are the shared data argument(s). 13826 13827 -- GIMPLE function: bool gimple_omp_parallel_combined_p (gimple g) 13828 Return true if 'OMP' parallel statement 'G' has the 13829 'GF_OMP_PARALLEL_COMBINED' flag set. 13830 13831 -- GIMPLE function: void gimple_omp_parallel_set_combined_p (gimple g) 13832 Set the 'GF_OMP_PARALLEL_COMBINED' field in 'OMP' parallel 13833 statement 'G'. 13834 13835 -- GIMPLE function: gimple_seq gimple_omp_body (gimple g) 13836 Return the body for the 'OMP' statement 'G'. 13837 13838 -- GIMPLE function: void gimple_omp_set_body (gimple g, gimple_seq 13839 body) 13840 Set 'BODY' to be the body for the 'OMP' statement 'G'. 13841 13842 -- GIMPLE function: tree gimple_omp_parallel_clauses (gimple g) 13843 Return the clauses associated with 'OMP_PARALLEL' 'G'. 13844 13845 -- GIMPLE function: tree * gimple_omp_parallel_clauses_ptr ( 13846 gomp_parallel *g) 13847 Return a pointer to the clauses associated with 'OMP_PARALLEL' 'G'. 13848 13849 -- GIMPLE function: void gimple_omp_parallel_set_clauses ( 13850 gomp_parallel *g, tree clauses) 13851 Set 'CLAUSES' to be the list of clauses associated with 13852 'OMP_PARALLEL' 'G'. 13853 13854 -- GIMPLE function: tree gimple_omp_parallel_child_fn ( const 13855 gomp_parallel *g) 13856 Return the child function used to hold the body of 'OMP_PARALLEL' 13857 'G'. 13858 13859 -- GIMPLE function: tree * gimple_omp_parallel_child_fn_ptr ( 13860 gomp_parallel *g) 13861 Return a pointer to the child function used to hold the body of 13862 'OMP_PARALLEL' 'G'. 13863 13864 -- GIMPLE function: void gimple_omp_parallel_set_child_fn ( 13865 gomp_parallel *g, tree child_fn) 13866 Set 'CHILD_FN' to be the child function for 'OMP_PARALLEL' 'G'. 13867 13868 -- GIMPLE function: tree gimple_omp_parallel_data_arg ( const 13869 gomp_parallel *g) 13870 Return the artificial argument used to send variables and values 13871 from the parent to the children threads in 'OMP_PARALLEL' 'G'. 13872 13873 -- GIMPLE function: tree * gimple_omp_parallel_data_arg_ptr ( 13874 gomp_parallel *g) 13875 Return a pointer to the data argument for 'OMP_PARALLEL' 'G'. 13876 13877 -- GIMPLE function: void gimple_omp_parallel_set_data_arg ( 13878 gomp_parallel *g, tree data_arg) 13879 Set 'DATA_ARG' to be the data argument for 'OMP_PARALLEL' 'G'. 13880 13881 13882File: gccint.info, Node: GIMPLE_OMP_RETURN, Next: GIMPLE_OMP_SECTION, Prev: GIMPLE_OMP_PARALLEL, Up: Tuple specific accessors 13883 1388412.8.20 'GIMPLE_OMP_RETURN' 13885--------------------------- 13886 13887 -- GIMPLE function: gimple gimple_build_omp_return (bool wait_p) 13888 Build a 'GIMPLE_OMP_RETURN' statement. 'WAIT_P' is true if this is 13889 a non-waiting return. 13890 13891 -- GIMPLE function: void gimple_omp_return_set_nowait (gimple s) 13892 Set the nowait flag on 'GIMPLE_OMP_RETURN' statement 'S'. 13893 13894 -- GIMPLE function: bool gimple_omp_return_nowait_p (gimple g) 13895 Return true if 'OMP' return statement 'G' has the 13896 'GF_OMP_RETURN_NOWAIT' flag set. 13897 13898 13899File: gccint.info, Node: GIMPLE_OMP_SECTION, Next: GIMPLE_OMP_SECTIONS, Prev: GIMPLE_OMP_RETURN, Up: Tuple specific accessors 13900 1390112.8.21 'GIMPLE_OMP_SECTION' 13902---------------------------- 13903 13904 -- GIMPLE function: gimple gimple_build_omp_section (gimple_seq body) 13905 Build a 'GIMPLE_OMP_SECTION' statement for a sections statement. 13906 13907 'BODY' is the sequence of statements in the section. 13908 13909 -- GIMPLE function: bool gimple_omp_section_last_p (gimple g) 13910 Return true if 'OMP' section statement 'G' has the 13911 'GF_OMP_SECTION_LAST' flag set. 13912 13913 -- GIMPLE function: void gimple_omp_section_set_last (gimple g) 13914 Set the 'GF_OMP_SECTION_LAST' flag on 'G'. 13915 13916 13917File: gccint.info, Node: GIMPLE_OMP_SECTIONS, Next: GIMPLE_OMP_SINGLE, Prev: GIMPLE_OMP_SECTION, Up: Tuple specific accessors 13918 1391912.8.22 'GIMPLE_OMP_SECTIONS' 13920----------------------------- 13921 13922 -- GIMPLE function: gomp_sections *gimple_build_omp_sections ( 13923 gimple_seq body, tree clauses) 13924 Build a 'GIMPLE_OMP_SECTIONS' statement. 'BODY' is a sequence of 13925 section statements. 'CLAUSES' are any of the 'OMP' sections 13926 construct's clauses: private, firstprivate, lastprivate, reduction, 13927 and nowait. 13928 13929 -- GIMPLE function: gimple gimple_build_omp_sections_switch (void) 13930 Build a 'GIMPLE_OMP_SECTIONS_SWITCH' statement. 13931 13932 -- GIMPLE function: tree gimple_omp_sections_control (gimple g) 13933 Return the control variable associated with the 13934 'GIMPLE_OMP_SECTIONS' in 'G'. 13935 13936 -- GIMPLE function: tree * gimple_omp_sections_control_ptr (gimple g) 13937 Return a pointer to the clauses associated with the 13938 'GIMPLE_OMP_SECTIONS' in 'G'. 13939 13940 -- GIMPLE function: void gimple_omp_sections_set_control (gimple g, 13941 tree control) 13942 Set 'CONTROL' to be the set of clauses associated with the 13943 'GIMPLE_OMP_SECTIONS' in 'G'. 13944 13945 -- GIMPLE function: tree gimple_omp_sections_clauses (gimple g) 13946 Return the clauses associated with 'OMP_SECTIONS' 'G'. 13947 13948 -- GIMPLE function: tree * gimple_omp_sections_clauses_ptr (gimple g) 13949 Return a pointer to the clauses associated with 'OMP_SECTIONS' 'G'. 13950 13951 -- GIMPLE function: void gimple_omp_sections_set_clauses (gimple g, 13952 tree clauses) 13953 Set 'CLAUSES' to be the set of clauses associated with 13954 'OMP_SECTIONS' 'G'. 13955 13956 13957File: gccint.info, Node: GIMPLE_OMP_SINGLE, Next: GIMPLE_PHI, Prev: GIMPLE_OMP_SECTIONS, Up: Tuple specific accessors 13958 1395912.8.23 'GIMPLE_OMP_SINGLE' 13960--------------------------- 13961 13962 -- GIMPLE function: gomp_single *gimple_build_omp_single ( gimple_seq 13963 body, tree clauses) 13964 Build a 'GIMPLE_OMP_SINGLE' statement. 'BODY' is the sequence of 13965 statements that will be executed once. 'CLAUSES' are any of the 13966 'OMP' single construct's clauses: private, firstprivate, 13967 copyprivate, nowait. 13968 13969 -- GIMPLE function: tree gimple_omp_single_clauses (gimple g) 13970 Return the clauses associated with 'OMP_SINGLE' 'G'. 13971 13972 -- GIMPLE function: tree * gimple_omp_single_clauses_ptr (gimple g) 13973 Return a pointer to the clauses associated with 'OMP_SINGLE' 'G'. 13974 13975 -- GIMPLE function: void gimple_omp_single_set_clauses ( gomp_single 13976 *g, tree clauses) 13977 Set 'CLAUSES' to be the clauses associated with 'OMP_SINGLE' 'G'. 13978 13979 13980File: gccint.info, Node: GIMPLE_PHI, Next: GIMPLE_RESX, Prev: GIMPLE_OMP_SINGLE, Up: Tuple specific accessors 13981 1398212.8.24 'GIMPLE_PHI' 13983-------------------- 13984 13985 -- GIMPLE function: unsigned gimple_phi_capacity (gimple g) 13986 Return the maximum number of arguments supported by 'GIMPLE_PHI' 13987 'G'. 13988 13989 -- GIMPLE function: unsigned gimple_phi_num_args (gimple g) 13990 Return the number of arguments in 'GIMPLE_PHI' 'G'. This must 13991 always be exactly the number of incoming edges for the basic block 13992 holding 'G'. 13993 13994 -- GIMPLE function: tree gimple_phi_result (gimple g) 13995 Return the 'SSA' name created by 'GIMPLE_PHI' 'G'. 13996 13997 -- GIMPLE function: tree * gimple_phi_result_ptr (gimple g) 13998 Return a pointer to the 'SSA' name created by 'GIMPLE_PHI' 'G'. 13999 14000 -- GIMPLE function: void gimple_phi_set_result (gphi *g, tree result) 14001 Set 'RESULT' to be the 'SSA' name created by 'GIMPLE_PHI' 'G'. 14002 14003 -- GIMPLE function: struct phi_arg_d * gimple_phi_arg (gimple g, index) 14004 Return the 'PHI' argument corresponding to incoming edge 'INDEX' 14005 for 'GIMPLE_PHI' 'G'. 14006 14007 -- GIMPLE function: void gimple_phi_set_arg (gphi *g, index, struct 14008 phi_arg_d * phiarg) 14009 Set 'PHIARG' to be the argument corresponding to incoming edge 14010 'INDEX' for 'GIMPLE_PHI' 'G'. 14011 14012 14013File: gccint.info, Node: GIMPLE_RESX, Next: GIMPLE_RETURN, Prev: GIMPLE_PHI, Up: Tuple specific accessors 14014 1401512.8.25 'GIMPLE_RESX' 14016--------------------- 14017 14018 -- GIMPLE function: gresx *gimple_build_resx (int region) 14019 Build a 'GIMPLE_RESX' statement which is a statement. This 14020 statement is a placeholder for _Unwind_Resume before we know if a 14021 function call or a branch is needed. 'REGION' is the exception 14022 region from which control is flowing. 14023 14024 -- GIMPLE function: int gimple_resx_region (const gresx *g) 14025 Return the region number for 'GIMPLE_RESX' 'G'. 14026 14027 -- GIMPLE function: void gimple_resx_set_region (gresx *g, int region) 14028 Set 'REGION' to be the region number for 'GIMPLE_RESX' 'G'. 14029 14030 14031File: gccint.info, Node: GIMPLE_RETURN, Next: GIMPLE_SWITCH, Prev: GIMPLE_RESX, Up: Tuple specific accessors 14032 1403312.8.26 'GIMPLE_RETURN' 14034----------------------- 14035 14036 -- GIMPLE function: greturn *gimple_build_return (tree retval) 14037 Build a 'GIMPLE_RETURN' statement whose return value is retval. 14038 14039 -- GIMPLE function: tree gimple_return_retval (const greturn *g) 14040 Return the return value for 'GIMPLE_RETURN' 'G'. 14041 14042 -- GIMPLE function: void gimple_return_set_retval (greturn *g, tree 14043 retval) 14044 Set 'RETVAL' to be the return value for 'GIMPLE_RETURN' 'G'. 14045 14046 14047File: gccint.info, Node: GIMPLE_SWITCH, Next: GIMPLE_TRY, Prev: GIMPLE_RETURN, Up: Tuple specific accessors 14048 1404912.8.27 'GIMPLE_SWITCH' 14050----------------------- 14051 14052 -- GIMPLE function: gswitch *gimple_build_switch (tree index, tree 14053 default_label, 'vec'<tree> *args) 14054 Build a 'GIMPLE_SWITCH' statement. 'INDEX' is the index variable 14055 to switch on, and 'DEFAULT_LABEL' represents the default label. 14056 'ARGS' is a vector of 'CASE_LABEL_EXPR' trees that contain the 14057 non-default case labels. Each label is a tree of code 14058 'CASE_LABEL_EXPR'. 14059 14060 -- GIMPLE function: unsigned gimple_switch_num_labels ( const gswitch 14061 *g) 14062 Return the number of labels associated with the switch statement 14063 'G'. 14064 14065 -- GIMPLE function: void gimple_switch_set_num_labels (gswitch *g, 14066 unsigned nlabels) 14067 Set 'NLABELS' to be the number of labels for the switch statement 14068 'G'. 14069 14070 -- GIMPLE function: tree gimple_switch_index (const gswitch *g) 14071 Return the index variable used by the switch statement 'G'. 14072 14073 -- GIMPLE function: void gimple_switch_set_index (gswitch *g, tree 14074 index) 14075 Set 'INDEX' to be the index variable for switch statement 'G'. 14076 14077 -- GIMPLE function: tree gimple_switch_label (const gswitch *g, 14078 unsigned index) 14079 Return the label numbered 'INDEX'. The default label is 0, 14080 followed by any labels in a switch statement. 14081 14082 -- GIMPLE function: void gimple_switch_set_label (gswitch *g, unsigned 14083 index, tree label) 14084 Set the label number 'INDEX' to 'LABEL'. 0 is always the default 14085 label. 14086 14087 -- GIMPLE function: tree gimple_switch_default_label ( const gswitch 14088 *g) 14089 Return the default label for a switch statement. 14090 14091 -- GIMPLE function: void gimple_switch_set_default_label (gswitch *g, 14092 tree label) 14093 Set the default label for a switch statement. 14094 14095 14096File: gccint.info, Node: GIMPLE_TRY, Next: GIMPLE_WITH_CLEANUP_EXPR, Prev: GIMPLE_SWITCH, Up: Tuple specific accessors 14097 1409812.8.28 'GIMPLE_TRY' 14099-------------------- 14100 14101 -- GIMPLE function: gtry *gimple_build_try (gimple_seq eval, gimple_seq 14102 cleanup, unsigned int kind) 14103 Build a 'GIMPLE_TRY' statement. 'EVAL' is a sequence with the 14104 expression to evaluate. 'CLEANUP' is a sequence of statements to 14105 run at clean-up time. 'KIND' is the enumeration value 14106 'GIMPLE_TRY_CATCH' if this statement denotes a try/catch construct 14107 or 'GIMPLE_TRY_FINALLY' if this statement denotes a try/finally 14108 construct. 14109 14110 -- GIMPLE function: enum gimple_try_flags gimple_try_kind (gimple g) 14111 Return the kind of try block represented by 'GIMPLE_TRY' 'G'. This 14112 is either 'GIMPLE_TRY_CATCH' or 'GIMPLE_TRY_FINALLY'. 14113 14114 -- GIMPLE function: bool gimple_try_catch_is_cleanup (gimple g) 14115 Return the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 14116 14117 -- GIMPLE function: gimple_seq gimple_try_eval (gimple g) 14118 Return the sequence of statements used as the body for 'GIMPLE_TRY' 14119 'G'. 14120 14121 -- GIMPLE function: gimple_seq gimple_try_cleanup (gimple g) 14122 Return the sequence of statements used as the cleanup body for 14123 'GIMPLE_TRY' 'G'. 14124 14125 -- GIMPLE function: void gimple_try_set_catch_is_cleanup (gimple g, 14126 bool catch_is_cleanup) 14127 Set the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 14128 14129 -- GIMPLE function: void gimple_try_set_eval (gtry *g, gimple_seq eval) 14130 Set 'EVAL' to be the sequence of statements to use as the body for 14131 'GIMPLE_TRY' 'G'. 14132 14133 -- GIMPLE function: void gimple_try_set_cleanup (gtry *g, gimple_seq 14134 cleanup) 14135 Set 'CLEANUP' to be the sequence of statements to use as the 14136 cleanup body for 'GIMPLE_TRY' 'G'. 14137 14138 14139File: gccint.info, Node: GIMPLE_WITH_CLEANUP_EXPR, Prev: GIMPLE_TRY, Up: Tuple specific accessors 14140 1414112.8.29 'GIMPLE_WITH_CLEANUP_EXPR' 14142---------------------------------- 14143 14144 -- GIMPLE function: gimple gimple_build_wce (gimple_seq cleanup) 14145 Build a 'GIMPLE_WITH_CLEANUP_EXPR' statement. 'CLEANUP' is the 14146 clean-up expression. 14147 14148 -- GIMPLE function: gimple_seq gimple_wce_cleanup (gimple g) 14149 Return the cleanup sequence for cleanup statement 'G'. 14150 14151 -- GIMPLE function: void gimple_wce_set_cleanup (gimple g, gimple_seq 14152 cleanup) 14153 Set 'CLEANUP' to be the cleanup sequence for 'G'. 14154 14155 -- GIMPLE function: bool gimple_wce_cleanup_eh_only (gimple g) 14156 Return the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple. 14157 14158 -- GIMPLE function: void gimple_wce_set_cleanup_eh_only (gimple g, bool 14159 eh_only_p) 14160 Set the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple. 14161 14162 14163File: gccint.info, Node: GIMPLE sequences, Next: Sequence iterators, Prev: Tuple specific accessors, Up: GIMPLE 14164 1416512.9 GIMPLE sequences 14166===================== 14167 14168GIMPLE sequences are the tuple equivalent of 'STATEMENT_LIST''s used in 14169'GENERIC'. They are used to chain statements together, and when used in 14170conjunction with sequence iterators, provide a framework for iterating 14171through statements. 14172 14173 GIMPLE sequences are of type struct 'gimple_sequence', but are more 14174commonly passed by reference to functions dealing with sequences. The 14175type for a sequence pointer is 'gimple_seq' which is the same as struct 14176'gimple_sequence' *. When declaring a local sequence, you can define a 14177local variable of type struct 'gimple_sequence'. When declaring a 14178sequence allocated on the garbage collected heap, use the function 14179'gimple_seq_alloc' documented below. 14180 14181 There are convenience functions for iterating through sequences in the 14182section entitled Sequence Iterators. 14183 14184 Below is a list of functions to manipulate and query sequences. 14185 14186 -- GIMPLE function: void gimple_seq_add_stmt (gimple_seq *seq, gimple 14187 g) 14188 Link a gimple statement to the end of the sequence *'SEQ' if 'G' is 14189 not 'NULL'. If *'SEQ' is 'NULL', allocate a sequence before 14190 linking. 14191 14192 -- GIMPLE function: void gimple_seq_add_seq (gimple_seq *dest, 14193 gimple_seq src) 14194 Append sequence 'SRC' to the end of sequence *'DEST' if 'SRC' is 14195 not 'NULL'. If *'DEST' is 'NULL', allocate a new sequence before 14196 appending. 14197 14198 -- GIMPLE function: gimple_seq gimple_seq_deep_copy (gimple_seq src) 14199 Perform a deep copy of sequence 'SRC' and return the result. 14200 14201 -- GIMPLE function: gimple_seq gimple_seq_reverse (gimple_seq seq) 14202 Reverse the order of the statements in the sequence 'SEQ'. Return 14203 'SEQ'. 14204 14205 -- GIMPLE function: gimple gimple_seq_first (gimple_seq s) 14206 Return the first statement in sequence 'S'. 14207 14208 -- GIMPLE function: gimple gimple_seq_last (gimple_seq s) 14209 Return the last statement in sequence 'S'. 14210 14211 -- GIMPLE function: void gimple_seq_set_last (gimple_seq s, gimple 14212 last) 14213 Set the last statement in sequence 'S' to the statement in 'LAST'. 14214 14215 -- GIMPLE function: void gimple_seq_set_first (gimple_seq s, gimple 14216 first) 14217 Set the first statement in sequence 'S' to the statement in 14218 'FIRST'. 14219 14220 -- GIMPLE function: void gimple_seq_init (gimple_seq s) 14221 Initialize sequence 'S' to an empty sequence. 14222 14223 -- GIMPLE function: gimple_seq gimple_seq_alloc (void) 14224 Allocate a new sequence in the garbage collected store and return 14225 it. 14226 14227 -- GIMPLE function: void gimple_seq_copy (gimple_seq dest, gimple_seq 14228 src) 14229 Copy the sequence 'SRC' into the sequence 'DEST'. 14230 14231 -- GIMPLE function: bool gimple_seq_empty_p (gimple_seq s) 14232 Return true if the sequence 'S' is empty. 14233 14234 -- GIMPLE function: gimple_seq bb_seq (basic_block bb) 14235 Returns the sequence of statements in 'BB'. 14236 14237 -- GIMPLE function: void set_bb_seq (basic_block bb, gimple_seq seq) 14238 Sets the sequence of statements in 'BB' to 'SEQ'. 14239 14240 -- GIMPLE function: bool gimple_seq_singleton_p (gimple_seq seq) 14241 Determine whether 'SEQ' contains exactly one statement. 14242 14243 14244File: gccint.info, Node: Sequence iterators, Next: Adding a new GIMPLE statement code, Prev: GIMPLE sequences, Up: GIMPLE 14245 1424612.10 Sequence iterators 14247======================== 14248 14249Sequence iterators are convenience constructs for iterating through 14250statements in a sequence. Given a sequence 'SEQ', here is a typical use 14251of gimple sequence iterators: 14252 14253 gimple_stmt_iterator gsi; 14254 14255 for (gsi = gsi_start (seq); !gsi_end_p (gsi); gsi_next (&gsi)) 14256 { 14257 gimple g = gsi_stmt (gsi); 14258 /* Do something with gimple statement G. */ 14259 } 14260 14261 Backward iterations are possible: 14262 14263 for (gsi = gsi_last (seq); !gsi_end_p (gsi); gsi_prev (&gsi)) 14264 14265 Forward and backward iterations on basic blocks are possible with 14266'gsi_start_bb' and 'gsi_last_bb'. 14267 14268 In the documentation below we sometimes refer to enum 14269'gsi_iterator_update'. The valid options for this enumeration are: 14270 14271 * 'GSI_NEW_STMT' Only valid when a single statement is added. Move 14272 the iterator to it. 14273 14274 * 'GSI_SAME_STMT' Leave the iterator at the same statement. 14275 14276 * 'GSI_CONTINUE_LINKING' Move iterator to whatever position is 14277 suitable for linking other statements in the same direction. 14278 14279 Below is a list of the functions used to manipulate and use statement 14280iterators. 14281 14282 -- GIMPLE function: gimple_stmt_iterator gsi_start (gimple_seq seq) 14283 Return a new iterator pointing to the sequence 'SEQ''s first 14284 statement. If 'SEQ' is empty, the iterator's basic block is 14285 'NULL'. Use 'gsi_start_bb' instead when the iterator needs to 14286 always have the correct basic block set. 14287 14288 -- GIMPLE function: gimple_stmt_iterator gsi_start_bb (basic_block bb) 14289 Return a new iterator pointing to the first statement in basic 14290 block 'BB'. 14291 14292 -- GIMPLE function: gimple_stmt_iterator gsi_last (gimple_seq seq) 14293 Return a new iterator initially pointing to the last statement of 14294 sequence 'SEQ'. If 'SEQ' is empty, the iterator's basic block is 14295 'NULL'. Use 'gsi_last_bb' instead when the iterator needs to 14296 always have the correct basic block set. 14297 14298 -- GIMPLE function: gimple_stmt_iterator gsi_last_bb (basic_block bb) 14299 Return a new iterator pointing to the last statement in basic block 14300 'BB'. 14301 14302 -- GIMPLE function: bool gsi_end_p (gimple_stmt_iterator i) 14303 Return 'TRUE' if at the end of 'I'. 14304 14305 -- GIMPLE function: bool gsi_one_before_end_p (gimple_stmt_iterator i) 14306 Return 'TRUE' if we're one statement before the end of 'I'. 14307 14308 -- GIMPLE function: void gsi_next (gimple_stmt_iterator *i) 14309 Advance the iterator to the next gimple statement. 14310 14311 -- GIMPLE function: void gsi_prev (gimple_stmt_iterator *i) 14312 Advance the iterator to the previous gimple statement. 14313 14314 -- GIMPLE function: gimple gsi_stmt (gimple_stmt_iterator i) 14315 Return the current stmt. 14316 14317 -- GIMPLE function: gimple_stmt_iterator gsi_after_labels (basic_block 14318 bb) 14319 Return a block statement iterator that points to the first 14320 non-label statement in block 'BB'. 14321 14322 -- GIMPLE function: gimple * gsi_stmt_ptr (gimple_stmt_iterator *i) 14323 Return a pointer to the current stmt. 14324 14325 -- GIMPLE function: basic_block gsi_bb (gimple_stmt_iterator i) 14326 Return the basic block associated with this iterator. 14327 14328 -- GIMPLE function: gimple_seq gsi_seq (gimple_stmt_iterator i) 14329 Return the sequence associated with this iterator. 14330 14331 -- GIMPLE function: void gsi_remove (gimple_stmt_iterator *i, bool 14332 remove_eh_info) 14333 Remove the current stmt from the sequence. The iterator is updated 14334 to point to the next statement. When 'REMOVE_EH_INFO' is true we 14335 remove the statement pointed to by iterator 'I' from the 'EH' 14336 tables. Otherwise we do not modify the 'EH' tables. Generally, 14337 'REMOVE_EH_INFO' should be true when the statement is going to be 14338 removed from the 'IL' and not reinserted elsewhere. 14339 14340 -- GIMPLE function: void gsi_link_seq_before (gimple_stmt_iterator *i, 14341 gimple_seq seq, enum gsi_iterator_update mode) 14342 Links the sequence of statements 'SEQ' before the statement pointed 14343 by iterator 'I'. 'MODE' indicates what to do with the iterator 14344 after insertion (see 'enum gsi_iterator_update' above). 14345 14346 -- GIMPLE function: void gsi_link_before (gimple_stmt_iterator *i, 14347 gimple g, enum gsi_iterator_update mode) 14348 Links statement 'G' before the statement pointed-to by iterator 14349 'I'. Updates iterator 'I' according to 'MODE'. 14350 14351 -- GIMPLE function: void gsi_link_seq_after (gimple_stmt_iterator *i, 14352 gimple_seq seq, enum gsi_iterator_update mode) 14353 Links sequence 'SEQ' after the statement pointed-to by iterator 14354 'I'. 'MODE' is as in 'gsi_insert_after'. 14355 14356 -- GIMPLE function: void gsi_link_after (gimple_stmt_iterator *i, 14357 gimple g, enum gsi_iterator_update mode) 14358 Links statement 'G' after the statement pointed-to by iterator 'I'. 14359 'MODE' is as in 'gsi_insert_after'. 14360 14361 -- GIMPLE function: gimple_seq gsi_split_seq_after 14362 (gimple_stmt_iterator i) 14363 Move all statements in the sequence after 'I' to a new sequence. 14364 Return this new sequence. 14365 14366 -- GIMPLE function: gimple_seq gsi_split_seq_before 14367 (gimple_stmt_iterator *i) 14368 Move all statements in the sequence before 'I' to a new sequence. 14369 Return this new sequence. 14370 14371 -- GIMPLE function: void gsi_replace (gimple_stmt_iterator *i, gimple 14372 stmt, bool update_eh_info) 14373 Replace the statement pointed-to by 'I' to 'STMT'. If 14374 'UPDATE_EH_INFO' is true, the exception handling information of the 14375 original statement is moved to the new statement. 14376 14377 -- GIMPLE function: void gsi_insert_before (gimple_stmt_iterator *i, 14378 gimple stmt, enum gsi_iterator_update mode) 14379 Insert statement 'STMT' before the statement pointed-to by iterator 14380 'I', update 'STMT''s basic block and scan it for new operands. 14381 'MODE' specifies how to update iterator 'I' after insertion (see 14382 enum 'gsi_iterator_update'). 14383 14384 -- GIMPLE function: void gsi_insert_seq_before (gimple_stmt_iterator 14385 *i, gimple_seq seq, enum gsi_iterator_update mode) 14386 Like 'gsi_insert_before', but for all the statements in 'SEQ'. 14387 14388 -- GIMPLE function: void gsi_insert_after (gimple_stmt_iterator *i, 14389 gimple stmt, enum gsi_iterator_update mode) 14390 Insert statement 'STMT' after the statement pointed-to by iterator 14391 'I', update 'STMT''s basic block and scan it for new operands. 14392 'MODE' specifies how to update iterator 'I' after insertion (see 14393 enum 'gsi_iterator_update'). 14394 14395 -- GIMPLE function: void gsi_insert_seq_after (gimple_stmt_iterator *i, 14396 gimple_seq seq, enum gsi_iterator_update mode) 14397 Like 'gsi_insert_after', but for all the statements in 'SEQ'. 14398 14399 -- GIMPLE function: gimple_stmt_iterator gsi_for_stmt (gimple stmt) 14400 Finds iterator for 'STMT'. 14401 14402 -- GIMPLE function: void gsi_move_after (gimple_stmt_iterator *from, 14403 gimple_stmt_iterator *to) 14404 Move the statement at 'FROM' so it comes right after the statement 14405 at 'TO'. 14406 14407 -- GIMPLE function: void gsi_move_before (gimple_stmt_iterator *from, 14408 gimple_stmt_iterator *to) 14409 Move the statement at 'FROM' so it comes right before the statement 14410 at 'TO'. 14411 14412 -- GIMPLE function: void gsi_move_to_bb_end (gimple_stmt_iterator 14413 *from, basic_block bb) 14414 Move the statement at 'FROM' to the end of basic block 'BB'. 14415 14416 -- GIMPLE function: void gsi_insert_on_edge (edge e, gimple stmt) 14417 Add 'STMT' to the pending list of edge 'E'. No actual insertion is 14418 made until a call to 'gsi_commit_edge_inserts'() is made. 14419 14420 -- GIMPLE function: void gsi_insert_seq_on_edge (edge e, gimple_seq 14421 seq) 14422 Add the sequence of statements in 'SEQ' to the pending list of edge 14423 'E'. No actual insertion is made until a call to 14424 'gsi_commit_edge_inserts'() is made. 14425 14426 -- GIMPLE function: basic_block gsi_insert_on_edge_immediate (edge e, 14427 gimple stmt) 14428 Similar to 'gsi_insert_on_edge'+'gsi_commit_edge_inserts'. If a 14429 new block has to be created, it is returned. 14430 14431 -- GIMPLE function: void gsi_commit_one_edge_insert (edge e, 14432 basic_block *new_bb) 14433 Commit insertions pending at edge 'E'. If a new block is created, 14434 set 'NEW_BB' to this block, otherwise set it to 'NULL'. 14435 14436 -- GIMPLE function: void gsi_commit_edge_inserts (void) 14437 This routine will commit all pending edge insertions, creating any 14438 new basic blocks which are necessary. 14439 14440 14441File: gccint.info, Node: Adding a new GIMPLE statement code, Next: Statement and operand traversals, Prev: Sequence iterators, Up: GIMPLE 14442 1444312.11 Adding a new GIMPLE statement code 14444======================================== 14445 14446The first step in adding a new GIMPLE statement code, is modifying the 14447file 'gimple.def', which contains all the GIMPLE codes. Then you must 14448add a corresponding gimple subclass located in 'gimple.h'. This in 14449turn, will require you to add a corresponding 'GTY' tag in 14450'gsstruct.def', and code to handle this tag in 'gss_for_code' which is 14451located in 'gimple.c'. 14452 14453 In order for the garbage collector to know the size of the structure 14454you created in 'gimple.h', you need to add a case to handle your new 14455GIMPLE statement in 'gimple_size' which is located in 'gimple.c'. 14456 14457 You will probably want to create a function to build the new gimple 14458statement in 'gimple.c'. The function should be called 14459'gimple_build_NEW-TUPLE-NAME', and should return the new tuple as a 14460pointer to the appropriate gimple subclass. 14461 14462 If your new statement requires accessors for any members or operands it 14463may have, put simple inline accessors in 'gimple.h' and any non-trivial 14464accessors in 'gimple.c' with a corresponding prototype in 'gimple.h'. 14465 14466 You should add the new statement subclass to the class hierarchy 14467diagram in 'gimple.texi'. 14468 14469 14470File: gccint.info, Node: Statement and operand traversals, Prev: Adding a new GIMPLE statement code, Up: GIMPLE 14471 1447212.12 Statement and operand traversals 14473====================================== 14474 14475There are two functions available for walking statements and sequences: 14476'walk_gimple_stmt' and 'walk_gimple_seq', accordingly, and a third 14477function for walking the operands in a statement: 'walk_gimple_op'. 14478 14479 -- GIMPLE function: tree walk_gimple_stmt (gimple_stmt_iterator *gsi, 14480 walk_stmt_fn callback_stmt, walk_tree_fn callback_op, struct 14481 walk_stmt_info *wi) 14482 This function is used to walk the current statement in 'GSI', 14483 optionally using traversal state stored in 'WI'. If 'WI' is 14484 'NULL', no state is kept during the traversal. 14485 14486 The callback 'CALLBACK_STMT' is called. If 'CALLBACK_STMT' returns 14487 true, it means that the callback function has handled all the 14488 operands of the statement and it is not necessary to walk its 14489 operands. 14490 14491 If 'CALLBACK_STMT' is 'NULL' or it returns false, 'CALLBACK_OP' is 14492 called on each operand of the statement via 'walk_gimple_op'. If 14493 'walk_gimple_op' returns non-'NULL' for any operand, the remaining 14494 operands are not scanned. 14495 14496 The return value is that returned by the last call to 14497 'walk_gimple_op', or 'NULL_TREE' if no 'CALLBACK_OP' is specified. 14498 14499 -- GIMPLE function: tree walk_gimple_op (gimple stmt, walk_tree_fn 14500 callback_op, struct walk_stmt_info *wi) 14501 Use this function to walk the operands of statement 'STMT'. Every 14502 operand is walked via 'walk_tree' with optional state information 14503 in 'WI'. 14504 14505 'CALLBACK_OP' is called on each operand of 'STMT' via 'walk_tree'. 14506 Additional parameters to 'walk_tree' must be stored in 'WI'. For 14507 each operand 'OP', 'walk_tree' is called as: 14508 14509 walk_tree (&OP, CALLBACK_OP, WI, PSET) 14510 14511 If 'CALLBACK_OP' returns non-'NULL' for an operand, the remaining 14512 operands are not scanned. The return value is that returned by the 14513 last call to 'walk_tree', or 'NULL_TREE' if no 'CALLBACK_OP' is 14514 specified. 14515 14516 -- GIMPLE function: tree walk_gimple_seq (gimple_seq seq, walk_stmt_fn 14517 callback_stmt, walk_tree_fn callback_op, struct walk_stmt_info 14518 *wi) 14519 This function walks all the statements in the sequence 'SEQ' 14520 calling 'walk_gimple_stmt' on each one. 'WI' is as in 14521 'walk_gimple_stmt'. If 'walk_gimple_stmt' returns non-'NULL', the 14522 walk is stopped and the value returned. Otherwise, all the 14523 statements are walked and 'NULL_TREE' returned. 14524 14525 14526File: gccint.info, Node: Tree SSA, Next: RTL, Prev: GIMPLE, Up: Top 14527 1452813 Analysis and Optimization of GIMPLE tuples 14529********************************************* 14530 14531GCC uses three main intermediate languages to represent the program 14532during compilation: GENERIC, GIMPLE and RTL. GENERIC is a 14533language-independent representation generated by each front end. It is 14534used to serve as an interface between the parser and optimizer. GENERIC 14535is a common representation that is able to represent programs written in 14536all the languages supported by GCC. 14537 14538 GIMPLE and RTL are used to optimize the program. GIMPLE is used for 14539target and language independent optimizations (e.g., inlining, constant 14540propagation, tail call elimination, redundancy elimination, etc). Much 14541like GENERIC, GIMPLE is a language independent, tree based 14542representation. However, it differs from GENERIC in that the GIMPLE 14543grammar is more restrictive: expressions contain no more than 3 operands 14544(except function calls), it has no control flow structures and 14545expressions with side effects are only allowed on the right hand side of 14546assignments. See the chapter describing GENERIC and GIMPLE for more 14547details. 14548 14549 This chapter describes the data structures and functions used in the 14550GIMPLE optimizers (also known as "tree optimizers" or "middle end"). In 14551particular, it focuses on all the macros, data structures, functions and 14552programming constructs needed to implement optimization passes for 14553GIMPLE. 14554 14555* Menu: 14556 14557* Annotations:: Attributes for variables. 14558* SSA Operands:: SSA names referenced by GIMPLE statements. 14559* SSA:: Static Single Assignment representation. 14560* Alias analysis:: Representing aliased loads and stores. 14561* Memory model:: Memory model used by the middle-end. 14562 14563 14564File: gccint.info, Node: Annotations, Next: SSA Operands, Up: Tree SSA 14565 1456613.1 Annotations 14567================ 14568 14569The optimizers need to associate attributes with variables during the 14570optimization process. For instance, we need to know whether a variable 14571has aliases. All these attributes are stored in data structures called 14572annotations which are then linked to the field 'ann' in 'struct 14573tree_common'. 14574 14575 14576File: gccint.info, Node: SSA Operands, Next: SSA, Prev: Annotations, Up: Tree SSA 14577 1457813.2 SSA Operands 14579================= 14580 14581Almost every GIMPLE statement will contain a reference to a variable or 14582memory location. Since statements come in different shapes and sizes, 14583their operands are going to be located at various spots inside the 14584statement's tree. To facilitate access to the statement's operands, 14585they are organized into lists associated inside each statement's 14586annotation. Each element in an operand list is a pointer to a 14587'VAR_DECL', 'PARM_DECL' or 'SSA_NAME' tree node. This provides a very 14588convenient way of examining and replacing operands. 14589 14590 Data flow analysis and optimization is done on all tree nodes 14591representing variables. Any node for which 'SSA_VAR_P' returns nonzero 14592is considered when scanning statement operands. However, not all 14593'SSA_VAR_P' variables are processed in the same way. For the purposes 14594of optimization, we need to distinguish between references to local 14595scalar variables and references to globals, statics, structures, arrays, 14596aliased variables, etc. The reason is simple, the compiler can gather 14597complete data flow information for a local scalar. On the other hand, a 14598global variable may be modified by a function call, it may not be 14599possible to keep track of all the elements of an array or the fields of 14600a structure, etc. 14601 14602 The operand scanner gathers two kinds of operands: "real" and 14603"virtual". An operand for which 'is_gimple_reg' returns true is 14604considered real, otherwise it is a virtual operand. We also distinguish 14605between uses and definitions. An operand is used if its value is loaded 14606by the statement (e.g., the operand at the RHS of an assignment). If 14607the statement assigns a new value to the operand, the operand is 14608considered a definition (e.g., the operand at the LHS of an assignment). 14609 14610 Virtual and real operands also have very different data flow 14611properties. Real operands are unambiguous references to the full object 14612that they represent. For instance, given 14613 14614 { 14615 int a, b; 14616 a = b 14617 } 14618 14619 Since 'a' and 'b' are non-aliased locals, the statement 'a = b' will 14620have one real definition and one real use because variable 'a' is 14621completely modified with the contents of variable 'b'. Real definition 14622are also known as "killing definitions". Similarly, the use of 'b' 14623reads all its bits. 14624 14625 In contrast, virtual operands are used with variables that can have a 14626partial or ambiguous reference. This includes structures, arrays, 14627globals, and aliased variables. In these cases, we have two types of 14628definitions. For globals, structures, and arrays, we can determine from 14629a statement whether a variable of these types has a killing definition. 14630If the variable does, then the statement is marked as having a "must 14631definition" of that variable. However, if a statement is only defining 14632a part of the variable (i.e. a field in a structure), or if we know that 14633a statement might define the variable but we cannot say for sure, then 14634we mark that statement as having a "may definition". For instance, 14635given 14636 14637 { 14638 int a, b, *p; 14639 14640 if (...) 14641 p = &a; 14642 else 14643 p = &b; 14644 *p = 5; 14645 return *p; 14646 } 14647 14648 The assignment '*p = 5' may be a definition of 'a' or 'b'. If we 14649cannot determine statically where 'p' is pointing to at the time of the 14650store operation, we create virtual definitions to mark that statement as 14651a potential definition site for 'a' and 'b'. Memory loads are similarly 14652marked with virtual use operands. Virtual operands are shown in tree 14653dumps right before the statement that contains them. To request a tree 14654dump with virtual operands, use the '-vops' option to '-fdump-tree': 14655 14656 { 14657 int a, b, *p; 14658 14659 if (...) 14660 p = &a; 14661 else 14662 p = &b; 14663 # a = VDEF <a> 14664 # b = VDEF <b> 14665 *p = 5; 14666 14667 # VUSE <a> 14668 # VUSE <b> 14669 return *p; 14670 } 14671 14672 Notice that 'VDEF' operands have two copies of the referenced variable. 14673This indicates that this is not a killing definition of that variable. 14674In this case we refer to it as a "may definition" or "aliased store". 14675The presence of the second copy of the variable in the 'VDEF' operand 14676will become important when the function is converted into SSA form. 14677This will be used to link all the non-killing definitions to prevent 14678optimizations from making incorrect assumptions about them. 14679 14680 Operands are updated as soon as the statement is finished via a call to 14681'update_stmt'. If statement elements are changed via 'SET_USE' or 14682'SET_DEF', then no further action is required (i.e., those macros take 14683care of updating the statement). If changes are made by manipulating 14684the statement's tree directly, then a call must be made to 'update_stmt' 14685when complete. Calling one of the 'bsi_insert' routines or 14686'bsi_replace' performs an implicit call to 'update_stmt'. 14687 1468813.2.1 Operand Iterators And Access Routines 14689-------------------------------------------- 14690 14691Operands are collected by 'tree-ssa-operands.c'. They are stored inside 14692each statement's annotation and can be accessed through either the 14693operand iterators or an access routine. 14694 14695 The following access routines are available for examining operands: 14696 14697 1. 'SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return 14698 NULL unless there is exactly one operand matching the specified 14699 flags. If there is exactly one operand, the operand is returned as 14700 either a 'tree', 'def_operand_p', or 'use_operand_p'. 14701 14702 tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags); 14703 use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES); 14704 def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS); 14705 14706 2. 'ZERO_SSA_OPERANDS': This macro returns true if there are no 14707 operands matching the specified flags. 14708 14709 if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS)) 14710 return; 14711 14712 3. 'NUM_SSA_OPERANDS': This macro Returns the number of operands 14713 matching 'flags'. This actually executes a loop to perform the 14714 count, so only use this if it is really needed. 14715 14716 int count = NUM_SSA_OPERANDS (stmt, flags) 14717 14718 If you wish to iterate over some or all operands, use the 14719'FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator. For example, to print 14720all the operands for a statement: 14721 14722 void 14723 print_ops (tree stmt) 14724 { 14725 ssa_op_iter; 14726 tree var; 14727 14728 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS) 14729 print_generic_expr (stderr, var, TDF_SLIM); 14730 } 14731 14732 How to choose the appropriate iterator: 14733 14734 1. Determine whether you are need to see the operand pointers, or just 14735 the trees, and choose the appropriate macro: 14736 14737 Need Macro: 14738 ---- ------- 14739 use_operand_p FOR_EACH_SSA_USE_OPERAND 14740 def_operand_p FOR_EACH_SSA_DEF_OPERAND 14741 tree FOR_EACH_SSA_TREE_OPERAND 14742 14743 2. You need to declare a variable of the type you are interested in, 14744 and an ssa_op_iter structure which serves as the loop controlling 14745 variable. 14746 14747 3. Determine which operands you wish to use, and specify the flags of 14748 those you are interested in. They are documented in 14749 'tree-ssa-operands.h': 14750 14751 #define SSA_OP_USE 0x01 /* Real USE operands. */ 14752 #define SSA_OP_DEF 0x02 /* Real DEF operands. */ 14753 #define SSA_OP_VUSE 0x04 /* VUSE operands. */ 14754 #define SSA_OP_VDEF 0x08 /* VDEF operands. */ 14755 14756 /* These are commonly grouped operand flags. */ 14757 #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE) 14758 #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VDEF) 14759 #define SSA_OP_ALL_VIRTUALS (SSA_OP_VIRTUAL_USES | SSA_OP_VIRTUAL_DEFS) 14760 #define SSA_OP_ALL_USES (SSA_OP_VIRTUAL_USES | SSA_OP_USE) 14761 #define SSA_OP_ALL_DEFS (SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF) 14762 #define SSA_OP_ALL_OPERANDS (SSA_OP_ALL_USES | SSA_OP_ALL_DEFS) 14763 14764 So if you want to look at the use pointers for all the 'USE' and 'VUSE' 14765operands, you would do something like: 14766 14767 use_operand_p use_p; 14768 ssa_op_iter iter; 14769 14770 FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE)) 14771 { 14772 process_use_ptr (use_p); 14773 } 14774 14775 The 'TREE' macro is basically the same as the 'USE' and 'DEF' macros, 14776only with the use or def dereferenced via 'USE_FROM_PTR (use_p)' and 14777'DEF_FROM_PTR (def_p)'. Since we aren't using operand pointers, use and 14778defs flags can be mixed. 14779 14780 tree var; 14781 ssa_op_iter iter; 14782 14783 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE) 14784 { 14785 print_generic_expr (stderr, var, TDF_SLIM); 14786 } 14787 14788 'VDEF's are broken into two flags, one for the 'DEF' portion 14789('SSA_OP_VDEF') and one for the USE portion ('SSA_OP_VUSE'). 14790 14791 There are many examples in the code, in addition to the documentation 14792in 'tree-ssa-operands.h' and 'ssa-iterators.h'. 14793 14794 There are also a couple of variants on the stmt iterators regarding PHI 14795nodes. 14796 14797 'FOR_EACH_PHI_ARG' Works exactly like 'FOR_EACH_SSA_USE_OPERAND', 14798except it works over 'PHI' arguments instead of statement operands. 14799 14800 /* Look at every virtual PHI use. */ 14801 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES) 14802 { 14803 my_code; 14804 } 14805 14806 /* Look at every real PHI use. */ 14807 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES) 14808 my_code; 14809 14810 /* Look at every PHI use. */ 14811 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES) 14812 my_code; 14813 14814 'FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like 14815'FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a 14816statement or a 'PHI' node. These should be used when it is appropriate 14817but they are not quite as efficient as the individual 'FOR_EACH_PHI' and 14818'FOR_EACH_SSA' routines. 14819 14820 FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags) 14821 { 14822 my_code; 14823 } 14824 14825 FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags) 14826 { 14827 my_code; 14828 } 14829 1483013.2.2 Immediate Uses 14831--------------------- 14832 14833Immediate use information is now always available. Using the immediate 14834use iterators, you may examine every use of any 'SSA_NAME'. For 14835instance, to change each use of 'ssa_var' to 'ssa_var2' and call 14836fold_stmt on each stmt after that is done: 14837 14838 use_operand_p imm_use_p; 14839 imm_use_iterator iterator; 14840 tree ssa_var, stmt; 14841 14842 14843 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 14844 { 14845 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 14846 SET_USE (imm_use_p, ssa_var_2); 14847 fold_stmt (stmt); 14848 } 14849 14850 There are 2 iterators which can be used. 'FOR_EACH_IMM_USE_FAST' is 14851used when the immediate uses are not changed, i.e., you are looking at 14852the uses, but not setting them. 14853 14854 If they do get changed, then care must be taken that things are not 14855changed under the iterators, so use the 'FOR_EACH_IMM_USE_STMT' and 14856'FOR_EACH_IMM_USE_ON_STMT' iterators. They attempt to preserve the 14857sanity of the use list by moving all the uses for a statement into a 14858controlled position, and then iterating over those uses. Then the 14859optimization can manipulate the stmt when all the uses have been 14860processed. This is a little slower than the FAST version since it adds 14861a placeholder element and must sort through the list a bit for each 14862statement. This placeholder element must be also be removed if the loop 14863is terminated early. The macro 'BREAK_FROM_IMM_USE_SAFE' is provided to 14864do this : 14865 14866 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 14867 { 14868 if (stmt == last_stmt) 14869 BREAK_FROM_SAFE_IMM_USE (iter); 14870 14871 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 14872 SET_USE (imm_use_p, ssa_var_2); 14873 fold_stmt (stmt); 14874 } 14875 14876 There are checks in 'verify_ssa' which verify that the immediate use 14877list is up to date, as well as checking that an optimization didn't 14878break from the loop without using this macro. It is safe to simply 14879'break'; from a 'FOR_EACH_IMM_USE_FAST' traverse. 14880 14881 Some useful functions and macros: 14882 1. 'has_zero_uses (ssa_var)' : Returns true if there are no uses of 14883 'ssa_var'. 14884 2. 'has_single_use (ssa_var)' : Returns true if there is only a single 14885 use of 'ssa_var'. 14886 3. 'single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' : 14887 Returns true if there is only a single use of 'ssa_var', and also 14888 returns the use pointer and statement it occurs in, in the second 14889 and third parameters. 14890 4. 'num_imm_uses (ssa_var)' : Returns the number of immediate uses of 14891 'ssa_var'. It is better not to use this if possible since it 14892 simply utilizes a loop to count the uses. 14893 5. 'PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a 'PHI' node, 14894 return the index number for the use. An assert is triggered if the 14895 use isn't located in a 'PHI' node. 14896 6. 'USE_STMT (use_p)' : Return the statement a use occurs in. 14897 14898 Note that uses are not put into an immediate use list until their 14899statement is actually inserted into the instruction stream via a 'bsi_*' 14900routine. 14901 14902 It is also still possible to utilize lazy updating of statements, but 14903this should be used only when absolutely required. Both alias analysis 14904and the dominator optimizations currently do this. 14905 14906 When lazy updating is being used, the immediate use information is out 14907of date and cannot be used reliably. Lazy updating is achieved by 14908simply marking statements modified via calls to 'gimple_set_modified' 14909instead of 'update_stmt'. When lazy updating is no longer required, all 14910the modified statements must have 'update_stmt' called in order to bring 14911them up to date. This must be done before the optimization is finished, 14912or 'verify_ssa' will trigger an abort. 14913 14914 This is done with a simple loop over the instruction stream: 14915 block_stmt_iterator bsi; 14916 basic_block bb; 14917 FOR_EACH_BB (bb) 14918 { 14919 for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi)) 14920 update_stmt_if_modified (bsi_stmt (bsi)); 14921 } 14922 14923 14924File: gccint.info, Node: SSA, Next: Alias analysis, Prev: SSA Operands, Up: Tree SSA 14925 1492613.3 Static Single Assignment 14927============================= 14928 14929Most of the tree optimizers rely on the data flow information provided 14930by the Static Single Assignment (SSA) form. We implement the SSA form 14931as described in 'R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K. 14932Zadeck. Efficiently Computing Static Single Assignment Form and the 14933Control Dependence Graph. ACM Transactions on Programming Languages and 14934Systems, 13(4):451-490, October 1991'. 14935 14936 The SSA form is based on the premise that program variables are 14937assigned in exactly one location in the program. Multiple assignments 14938to the same variable create new versions of that variable. Naturally, 14939actual programs are seldom in SSA form initially because variables tend 14940to be assigned multiple times. The compiler modifies the program 14941representation so that every time a variable is assigned in the code, a 14942new version of the variable is created. Different versions of the same 14943variable are distinguished by subscripting the variable name with its 14944version number. Variables used in the right-hand side of expressions 14945are renamed so that their version number matches that of the most recent 14946assignment. 14947 14948 We represent variable versions using 'SSA_NAME' nodes. The renaming 14949process in 'tree-ssa.c' wraps every real and virtual operand with an 14950'SSA_NAME' node which contains the version number and the statement that 14951created the 'SSA_NAME'. Only definitions and virtual definitions may 14952create new 'SSA_NAME' nodes. 14953 14954 Sometimes, flow of control makes it impossible to determine the most 14955recent version of a variable. In these cases, the compiler inserts an 14956artificial definition for that variable called "PHI function" or "PHI 14957node". This new definition merges all the incoming versions of the 14958variable to create a new name for it. For instance, 14959 14960 if (...) 14961 a_1 = 5; 14962 else if (...) 14963 a_2 = 2; 14964 else 14965 a_3 = 13; 14966 14967 # a_4 = PHI <a_1, a_2, a_3> 14968 return a_4; 14969 14970 Since it is not possible to determine which of the three branches will 14971be taken at runtime, we don't know which of 'a_1', 'a_2' or 'a_3' to use 14972at the return statement. So, the SSA renamer creates a new version 14973'a_4' which is assigned the result of "merging" 'a_1', 'a_2' and 'a_3'. 14974Hence, PHI nodes mean "one of these operands. I don't know which". 14975 14976 The following functions can be used to examine PHI nodes 14977 14978 -- Function: gimple_phi_result (PHI) 14979 Returns the 'SSA_NAME' created by PHI node PHI (i.e., PHI's LHS). 14980 14981 -- Function: gimple_phi_num_args (PHI) 14982 Returns the number of arguments in PHI. This number is exactly the 14983 number of incoming edges to the basic block holding PHI. 14984 14985 -- Function: gimple_phi_arg (PHI, I) 14986 Returns Ith argument of PHI. 14987 14988 -- Function: gimple_phi_arg_edge (PHI, I) 14989 Returns the incoming edge for the Ith argument of PHI. 14990 14991 -- Function: gimple_phi_arg_def (PHI, I) 14992 Returns the 'SSA_NAME' for the Ith argument of PHI. 14993 1499413.3.1 Preserving the SSA form 14995------------------------------ 14996 14997Some optimization passes make changes to the function that invalidate 14998the SSA property. This can happen when a pass has added new symbols or 14999changed the program so that variables that were previously aliased 15000aren't anymore. Whenever something like this happens, the affected 15001symbols must be renamed into SSA form again. Transformations that emit 15002new code or replicate existing statements will also need to update the 15003SSA form. 15004 15005 Since GCC implements two different SSA forms for register and virtual 15006variables, keeping the SSA form up to date depends on whether you are 15007updating register or virtual names. In both cases, the general idea 15008behind incremental SSA updates is similar: when new SSA names are 15009created, they typically are meant to replace other existing names in the 15010program. 15011 15012 For instance, given the following code: 15013 15014 1 L0: 15015 2 x_1 = PHI (0, x_5) 15016 3 if (x_1 < 10) 15017 4 if (x_1 > 7) 15018 5 y_2 = 0 15019 6 else 15020 7 y_3 = x_1 + x_7 15021 8 endif 15022 9 x_5 = x_1 + 1 15023 10 goto L0; 15024 11 endif 15025 15026 Suppose that we insert new names 'x_10' and 'x_11' (lines '4' and '8'). 15027 15028 1 L0: 15029 2 x_1 = PHI (0, x_5) 15030 3 if (x_1 < 10) 15031 4 x_10 = ... 15032 5 if (x_1 > 7) 15033 6 y_2 = 0 15034 7 else 15035 8 x_11 = ... 15036 9 y_3 = x_1 + x_7 15037 10 endif 15038 11 x_5 = x_1 + 1 15039 12 goto L0; 15040 13 endif 15041 15042 We want to replace all the uses of 'x_1' with the new definitions of 15043'x_10' and 'x_11'. Note that the only uses that should be replaced are 15044those at lines '5', '9' and '11'. Also, the use of 'x_7' at line '9' 15045should _not_ be replaced (this is why we cannot just mark symbol 'x' for 15046renaming). 15047 15048 Additionally, we may need to insert a PHI node at line '11' because 15049that is a merge point for 'x_10' and 'x_11'. So the use of 'x_1' at 15050line '11' will be replaced with the new PHI node. The insertion of PHI 15051nodes is optional. They are not strictly necessary to preserve the SSA 15052form, and depending on what the caller inserted, they may not even be 15053useful for the optimizers. 15054 15055 Updating the SSA form is a two step process. First, the pass has to 15056identify which names need to be updated and/or which symbols need to be 15057renamed into SSA form for the first time. When new names are introduced 15058to replace existing names in the program, the mapping between the old 15059and the new names are registered by calling 'register_new_name_mapping' 15060(note that if your pass creates new code by duplicating basic blocks, 15061the call to 'tree_duplicate_bb' will set up the necessary mappings 15062automatically). 15063 15064 After the replacement mappings have been registered and new symbols 15065marked for renaming, a call to 'update_ssa' makes the registered 15066changes. This can be done with an explicit call or by creating 'TODO' 15067flags in the 'tree_opt_pass' structure for your pass. There are several 15068'TODO' flags that control the behavior of 'update_ssa': 15069 15070 * 'TODO_update_ssa'. Update the SSA form inserting PHI nodes for 15071 newly exposed symbols and virtual names marked for updating. When 15072 updating real names, only insert PHI nodes for a real name 'O_j' in 15073 blocks reached by all the new and old definitions for 'O_j'. If 15074 the iterated dominance frontier for 'O_j' is not pruned, we may end 15075 up inserting PHI nodes in blocks that have one or more edges with 15076 no incoming definition for 'O_j'. This would lead to uninitialized 15077 warnings for 'O_j''s symbol. 15078 15079 * 'TODO_update_ssa_no_phi'. Update the SSA form without inserting 15080 any new PHI nodes at all. This is used by passes that have either 15081 inserted all the PHI nodes themselves or passes that need only to 15082 patch use-def and def-def chains for virtuals (e.g., DCE). 15083 15084 * 'TODO_update_ssa_full_phi'. Insert PHI nodes everywhere they are 15085 needed. No pruning of the IDF is done. This is used by passes 15086 that need the PHI nodes for 'O_j' even if it means that some 15087 arguments will come from the default definition of 'O_j''s symbol 15088 (e.g., 'pass_linear_transform'). 15089 15090 WARNING: If you need to use this flag, chances are that your pass 15091 may be doing something wrong. Inserting PHI nodes for an old name 15092 where not all edges carry a new replacement may lead to silent 15093 codegen errors or spurious uninitialized warnings. 15094 15095 * 'TODO_update_ssa_only_virtuals'. Passes that update the SSA form 15096 on their own may want to delegate the updating of virtual names to 15097 the generic updater. Since FUD chains are easier to maintain, this 15098 simplifies the work they need to do. NOTE: If this flag is used, 15099 any OLD->NEW mappings for real names are explicitly destroyed and 15100 only the symbols marked for renaming are processed. 15101 1510213.3.2 Examining 'SSA_NAME' nodes 15103--------------------------------- 15104 15105The following macros can be used to examine 'SSA_NAME' nodes 15106 15107 -- Macro: SSA_NAME_DEF_STMT (VAR) 15108 Returns the statement S that creates the 'SSA_NAME' VAR. If S is 15109 an empty statement (i.e., 'IS_EMPTY_STMT (S)' returns 'true'), it 15110 means that the first reference to this variable is a USE or a VUSE. 15111 15112 -- Macro: SSA_NAME_VERSION (VAR) 15113 Returns the version number of the 'SSA_NAME' object VAR. 15114 1511513.3.3 Walking the dominator tree 15116--------------------------------- 15117 15118 -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB) 15119 15120 This function walks the dominator tree for the current CFG calling 15121 a set of callback functions defined in STRUCT DOM_WALK_DATA in 15122 'domwalk.h'. The call back functions you need to define give you 15123 hooks to execute custom code at various points during traversal: 15124 15125 1. Once to initialize any local data needed while processing BB 15126 and its children. This local data is pushed into an internal 15127 stack which is automatically pushed and popped as the walker 15128 traverses the dominator tree. 15129 15130 2. Once before traversing all the statements in the BB. 15131 15132 3. Once for every statement inside BB. 15133 15134 4. Once after traversing all the statements and before recursing 15135 into BB's dominator children. 15136 15137 5. It then recurses into all the dominator children of BB. 15138 15139 6. After recursing into all the dominator children of BB it can, 15140 optionally, traverse every statement in BB again (i.e., 15141 repeating steps 2 and 3). 15142 15143 7. Once after walking the statements in BB and BB's dominator 15144 children. At this stage, the block local data stack is 15145 popped. 15146 15147 15148File: gccint.info, Node: Alias analysis, Next: Memory model, Prev: SSA, Up: Tree SSA 15149 1515013.4 Alias analysis 15151=================== 15152 15153Alias analysis in GIMPLE SSA form consists of two pieces. First the 15154virtual SSA web ties conflicting memory accesses and provides a SSA 15155use-def chain and SSA immediate-use chains for walking possibly 15156dependent memory accesses. Second an alias-oracle can be queried to 15157disambiguate explicit and implicit memory references. 15158 15159 1. Memory SSA form. 15160 15161 All statements that may use memory have exactly one accompanied use 15162 of a virtual SSA name that represents the state of memory at the 15163 given point in the IL. 15164 15165 All statements that may define memory have exactly one accompanied 15166 definition of a virtual SSA name using the previous state of memory 15167 and defining the new state of memory after the given point in the 15168 IL. 15169 15170 int i; 15171 int foo (void) 15172 { 15173 # .MEM_3 = VDEF <.MEM_2(D)> 15174 i = 1; 15175 # VUSE <.MEM_3> 15176 return i; 15177 } 15178 15179 The virtual SSA names in this case are '.MEM_2(D)' and '.MEM_3'. 15180 The store to the global variable 'i' defines '.MEM_3' invalidating 15181 '.MEM_2(D)'. The load from 'i' uses that new state '.MEM_3'. 15182 15183 The virtual SSA web serves as constraints to SSA optimizers 15184 preventing illegitimate code-motion and optimization. It also 15185 provides a way to walk related memory statements. 15186 15187 2. Points-to and escape analysis. 15188 15189 Points-to analysis builds a set of constraints from the GIMPLE SSA 15190 IL representing all pointer operations and facts we do or do not 15191 know about pointers. Solving this set of constraints yields a 15192 conservatively correct solution for each pointer variable in the 15193 program (though we are only interested in SSA name pointers) as to 15194 what it may possibly point to. 15195 15196 This points-to solution for a given SSA name pointer is stored in 15197 the 'pt_solution' sub-structure of the 'SSA_NAME_PTR_INFO' record. 15198 The following accessor functions are available: 15199 15200 * 'pt_solution_includes' 15201 * 'pt_solutions_intersect' 15202 15203 Points-to analysis also computes the solution for two special set 15204 of pointers, 'ESCAPED' and 'CALLUSED'. Those represent all memory 15205 that has escaped the scope of analysis or that is used by pure or 15206 nested const calls. 15207 15208 3. Type-based alias analysis 15209 15210 Type-based alias analysis is frontend dependent though generic 15211 support is provided by the middle-end in 'alias.c'. TBAA code is 15212 used by both tree optimizers and RTL optimizers. 15213 15214 Every language that wishes to perform language-specific alias 15215 analysis should define a function that computes, given a 'tree' 15216 node, an alias set for the node. Nodes in different alias sets are 15217 not allowed to alias. For an example, see the C front-end function 15218 'c_get_alias_set'. 15219 15220 4. Tree alias-oracle 15221 15222 The tree alias-oracle provides means to disambiguate two memory 15223 references and memory references against statements. The following 15224 queries are available: 15225 15226 * 'refs_may_alias_p' 15227 * 'ref_maybe_used_by_stmt_p' 15228 * 'stmt_may_clobber_ref_p' 15229 15230 In addition to those two kind of statement walkers are available 15231 walking statements related to a reference ref. 15232 'walk_non_aliased_vuses' walks over dominating memory defining 15233 statements and calls back if the statement does not clobber ref 15234 providing the non-aliased VUSE. The walk stops at the first 15235 clobbering statement or if asked to. 'walk_aliased_vdefs' walks 15236 over dominating memory defining statements and calls back on each 15237 statement clobbering ref providing its aliasing VDEF. The walk 15238 stops if asked to. 15239 15240 15241File: gccint.info, Node: Memory model, Prev: Alias analysis, Up: Tree SSA 15242 1524313.5 Memory model 15244================= 15245 15246The memory model used by the middle-end models that of the C/C++ 15247languages. The middle-end has the notion of an effective type of a 15248memory region which is used for type-based alias analysis. 15249 15250 The following is a refinement of ISO C99 6.5/6, clarifying the block 15251copy case to follow common sense and extending the concept of a dynamic 15252effective type to objects with a declared type as required for C++. 15253 15254 The effective type of an object for an access to its stored value is 15255 the declared type of the object or the effective type determined by 15256 a previous store to it. If a value is stored into an object through 15257 an lvalue having a type that is not a character type, then the 15258 type of the lvalue becomes the effective type of the object for that 15259 access and for subsequent accesses that do not modify the stored value. 15260 If a value is copied into an object using memcpy or memmove, 15261 or is copied as an array of character type, then the effective type 15262 of the modified object for that access and for subsequent accesses that 15263 do not modify the value is undetermined. For all other accesses to an 15264 object, the effective type of the object is simply the type of the 15265 lvalue used for the access. 15266 15267 15268File: gccint.info, Node: RTL, Next: Control Flow, Prev: Tree SSA, Up: Top 15269 1527014 RTL Representation 15271********************* 15272 15273The last part of the compiler work is done on a low-level intermediate 15274representation called Register Transfer Language. In this language, the 15275instructions to be output are described, pretty much one by one, in an 15276algebraic form that describes what the instruction does. 15277 15278 RTL is inspired by Lisp lists. It has both an internal form, made up 15279of structures that point at other structures, and a textual form that is 15280used in the machine description and in printed debugging dumps. The 15281textual form uses nested parentheses to indicate the pointers in the 15282internal form. 15283 15284* Menu: 15285 15286* RTL Objects:: Expressions vs vectors vs strings vs integers. 15287* RTL Classes:: Categories of RTL expression objects, and their structure. 15288* Accessors:: Macros to access expression operands or vector elts. 15289* Special Accessors:: Macros to access specific annotations on RTL. 15290* Flags:: Other flags in an RTL expression. 15291* Machine Modes:: Describing the size and format of a datum. 15292* Constants:: Expressions with constant values. 15293* Regs and Memory:: Expressions representing register contents or memory. 15294* Arithmetic:: Expressions representing arithmetic on other expressions. 15295* Comparisons:: Expressions representing comparison of expressions. 15296* Bit-Fields:: Expressions representing bit-fields in memory or reg. 15297* Vector Operations:: Expressions involving vector datatypes. 15298* Conversions:: Extending, truncating, floating or fixing. 15299* RTL Declarations:: Declaring volatility, constancy, etc. 15300* Side Effects:: Expressions for storing in registers, etc. 15301* Incdec:: Embedded side-effects for autoincrement addressing. 15302* Assembler:: Representing 'asm' with operands. 15303* Debug Information:: Expressions representing debugging information. 15304* Insns:: Expression types for entire insns. 15305* Calls:: RTL representation of function call insns. 15306* Sharing:: Some expressions are unique; others *must* be copied. 15307* Reading RTL:: Reading textual RTL from a file. 15308 15309 15310File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL 15311 1531214.1 RTL Object Types 15313===================== 15314 15315RTL uses five kinds of objects: expressions, integers, wide integers, 15316strings and vectors. Expressions are the most important ones. An RTL 15317expression ("RTX", for short) is a C structure, but it is usually 15318referred to with a pointer; a type that is given the typedef name 'rtx'. 15319 15320 An integer is simply an 'int'; their written form uses decimal digits. 15321A wide integer is an integral object whose type is 'HOST_WIDE_INT'; 15322their written form uses decimal digits. 15323 15324 A string is a sequence of characters. In core it is represented as a 15325'char *' in usual C fashion, and it is written in C syntax as well. 15326However, strings in RTL may never be null. If you write an empty string 15327in a machine description, it is represented in core as a null pointer 15328rather than as a pointer to a null character. In certain contexts, 15329these null pointers instead of strings are valid. Within RTL code, 15330strings are most commonly found inside 'symbol_ref' expressions, but 15331they appear in other contexts in the RTL expressions that make up 15332machine descriptions. 15333 15334 In a machine description, strings are normally written with double 15335quotes, as you would in C. However, strings in machine descriptions may 15336extend over many lines, which is invalid C, and adjacent string 15337constants are not concatenated as they are in C. Any string constant 15338may be surrounded with a single set of parentheses. Sometimes this 15339makes the machine description easier to read. 15340 15341 There is also a special syntax for strings, which can be useful when C 15342code is embedded in a machine description. Wherever a string can 15343appear, it is also valid to write a C-style brace block. The entire 15344brace block, including the outermost pair of braces, is considered to be 15345the string constant. Double quote characters inside the braces are not 15346special. Therefore, if you write string constants in the C code, you 15347need not escape each quote character with a backslash. 15348 15349 A vector contains an arbitrary number of pointers to expressions. The 15350number of elements in the vector is explicitly present in the vector. 15351The written form of a vector consists of square brackets ('[...]') 15352surrounding the elements, in sequence and with whitespace separating 15353them. Vectors of length zero are not created; null pointers are used 15354instead. 15355 15356 Expressions are classified by "expression codes" (also called RTX 15357codes). The expression code is a name defined in 'rtl.def', which is 15358also (in uppercase) a C enumeration constant. The possible expression 15359codes and their meanings are machine-independent. The code of an RTX 15360can be extracted with the macro 'GET_CODE (X)' and altered with 15361'PUT_CODE (X, NEWCODE)'. 15362 15363 The expression code determines how many operands the expression 15364contains, and what kinds of objects they are. In RTL, unlike Lisp, you 15365cannot tell by looking at an operand what kind of object it is. 15366Instead, you must know from its context--from the expression code of the 15367containing expression. For example, in an expression of code 'subreg', 15368the first operand is to be regarded as an expression and the second 15369operand as a polynomial integer. In an expression of code 'plus', there 15370are two operands, both of which are to be regarded as expressions. In a 15371'symbol_ref' expression, there is one operand, which is to be regarded 15372as a string. 15373 15374 Expressions are written as parentheses containing the name of the 15375expression type, its flags and machine mode if any, and then the 15376operands of the expression (separated by spaces). 15377 15378 Expression code names in the 'md' file are written in lowercase, but 15379when they appear in C code they are written in uppercase. In this 15380manual, they are shown as follows: 'const_int'. 15381 15382 In a few contexts a null pointer is valid where an expression is 15383normally wanted. The written form of this is '(nil)'. 15384 15385 15386File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL 15387 1538814.2 RTL Classes and Formats 15389============================ 15390 15391The various expression codes are divided into several "classes", which 15392are represented by single characters. You can determine the class of an 15393RTX code with the macro 'GET_RTX_CLASS (CODE)'. Currently, 'rtl.def' 15394defines these classes: 15395 15396'RTX_OBJ' 15397 An RTX code that represents an actual object, such as a register 15398 ('REG') or a memory location ('MEM', 'SYMBOL_REF'). 'LO_SUM') is 15399 also included; instead, 'SUBREG' and 'STRICT_LOW_PART' are not in 15400 this class, but in class 'x'. 15401 15402'RTX_CONST_OBJ' 15403 An RTX code that represents a constant object. 'HIGH' is also 15404 included in this class. 15405 15406'RTX_COMPARE' 15407 An RTX code for a non-symmetric comparison, such as 'GEU' or 'LT'. 15408 15409'RTX_COMM_COMPARE' 15410 An RTX code for a symmetric (commutative) comparison, such as 'EQ' 15411 or 'ORDERED'. 15412 15413'RTX_UNARY' 15414 An RTX code for a unary arithmetic operation, such as 'NEG', 'NOT', 15415 or 'ABS'. This category also includes value extension (sign or 15416 zero) and conversions between integer and floating point. 15417 15418'RTX_COMM_ARITH' 15419 An RTX code for a commutative binary operation, such as 'PLUS' or 15420 'AND'. 'NE' and 'EQ' are comparisons, so they have class '<'. 15421 15422'RTX_BIN_ARITH' 15423 An RTX code for a non-commutative binary operation, such as 15424 'MINUS', 'DIV', or 'ASHIFTRT'. 15425 15426'RTX_BITFIELD_OPS' 15427 An RTX code for a bit-field operation. Currently only 15428 'ZERO_EXTRACT' and 'SIGN_EXTRACT'. These have three inputs and are 15429 lvalues (so they can be used for insertion as well). *Note 15430 Bit-Fields::. 15431 15432'RTX_TERNARY' 15433 An RTX code for other three input operations. Currently only 15434 'IF_THEN_ELSE', 'VEC_MERGE', 'SIGN_EXTRACT', 'ZERO_EXTRACT', and 15435 'FMA'. 15436 15437'RTX_INSN' 15438 An RTX code for an entire instruction: 'INSN', 'JUMP_INSN', and 15439 'CALL_INSN'. *Note Insns::. 15440 15441'RTX_MATCH' 15442 An RTX code for something that matches in insns, such as 15443 'MATCH_DUP'. These only occur in machine descriptions. 15444 15445'RTX_AUTOINC' 15446 An RTX code for an auto-increment addressing mode, such as 15447 'POST_INC'. 'XEXP (X, 0)' gives the auto-modified register. 15448 15449'RTX_EXTRA' 15450 All other RTX codes. This category includes the remaining codes 15451 used only in machine descriptions ('DEFINE_*', etc.). It also 15452 includes all the codes describing side effects ('SET', 'USE', 15453 'CLOBBER', etc.) and the non-insns that may appear on an insn 15454 chain, such as 'NOTE', 'BARRIER', and 'CODE_LABEL'. 'SUBREG' is 15455 also part of this class. 15456 15457 For each expression code, 'rtl.def' specifies the number of contained 15458objects and their kinds using a sequence of characters called the 15459"format" of the expression code. For example, the format of 'subreg' is 15460'ep'. 15461 15462 These are the most commonly used format characters: 15463 15464'e' 15465 An expression (actually a pointer to an expression). 15466 15467'i' 15468 An integer. 15469 15470'w' 15471 A wide integer. 15472 15473's' 15474 A string. 15475 15476'E' 15477 A vector of expressions. 15478 15479 A few other format characters are used occasionally: 15480 15481'u' 15482 'u' is equivalent to 'e' except that it is printed differently in 15483 debugging dumps. It is used for pointers to insns. 15484 15485'n' 15486 'n' is equivalent to 'i' except that it is printed differently in 15487 debugging dumps. It is used for the line number or code number of 15488 a 'note' insn. 15489 15490'S' 15491 'S' indicates a string which is optional. In the RTL objects in 15492 core, 'S' is equivalent to 's', but when the object is read, from 15493 an 'md' file, the string value of this operand may be omitted. An 15494 omitted string is taken to be the null string. 15495 15496'V' 15497 'V' indicates a vector which is optional. In the RTL objects in 15498 core, 'V' is equivalent to 'E', but when the object is read from an 15499 'md' file, the vector value of this operand may be omitted. An 15500 omitted vector is effectively the same as a vector of no elements. 15501 15502'B' 15503 'B' indicates a pointer to basic block structure. 15504 15505'p' 15506 A polynomial integer. At present this is used only for 15507 'SUBREG_BYTE'. 15508 15509'0' 15510 '0' means a slot whose contents do not fit any normal category. 15511 '0' slots are not printed at all in dumps, and are often used in 15512 special ways by small parts of the compiler. 15513 15514 There are macros to get the number of operands and the format of an 15515expression code: 15516 15517'GET_RTX_LENGTH (CODE)' 15518 Number of operands of an RTX of code CODE. 15519 15520'GET_RTX_FORMAT (CODE)' 15521 The format of an RTX of code CODE, as a C string. 15522 15523 Some classes of RTX codes always have the same format. For example, it 15524is safe to assume that all comparison operations have format 'ee'. 15525 15526'1' 15527 All codes of this class have format 'e'. 15528 15529'<' 15530'c' 15531'2' 15532 All codes of these classes have format 'ee'. 15533 15534'b' 15535'3' 15536 All codes of these classes have format 'eee'. 15537 15538'i' 15539 All codes of this class have formats that begin with 'iuueiee'. 15540 *Note Insns::. Note that not all RTL objects linked onto an insn 15541 chain are of class 'i'. 15542 15543'o' 15544'm' 15545'x' 15546 You can make no assumptions about the format of these codes. 15547 15548 15549File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL 15550 1555114.3 Access to Operands 15552======================= 15553 15554Operands of expressions are accessed using the macros 'XEXP', 'XINT', 15555'XWINT' and 'XSTR'. Each of these macros takes two arguments: an 15556expression-pointer (RTX) and an operand number (counting from zero). 15557Thus, 15558 15559 XEXP (X, 2) 15560 15561accesses operand 2 of expression X, as an expression. 15562 15563 XINT (X, 2) 15564 15565accesses the same operand as an integer. 'XSTR', used in the same 15566fashion, would access it as a string. 15567 15568 Any operand can be accessed as an integer, as an expression or as a 15569string. You must choose the correct method of access for the kind of 15570value actually stored in the operand. You would do this based on the 15571expression code of the containing expression. That is also how you 15572would know how many operands there are. 15573 15574 For example, if X is an 'int_list' expression, you know that it has two 15575operands which can be correctly accessed as 'XINT (X, 0)' and 'XEXP (X, 155761)'. Incorrect accesses like 'XEXP (X, 0)' and 'XINT (X, 1)' would 15577compile, but would trigger an internal compiler error when rtl checking 15578is enabled. Nothing stops you from writing 'XEXP (X, 28)' either, but 15579this will access memory past the end of the expression with 15580unpredictable results. 15581 15582 Access to operands which are vectors is more complicated. You can use 15583the macro 'XVEC' to get the vector-pointer itself, or the macros 15584'XVECEXP' and 'XVECLEN' to access the elements and length of a vector. 15585 15586'XVEC (EXP, IDX)' 15587 Access the vector-pointer which is operand number IDX in EXP. 15588 15589'XVECLEN (EXP, IDX)' 15590 Access the length (number of elements) in the vector which is in 15591 operand number IDX in EXP. This value is an 'int'. 15592 15593'XVECEXP (EXP, IDX, ELTNUM)' 15594 Access element number ELTNUM in the vector which is in operand 15595 number IDX in EXP. This value is an RTX. 15596 15597 It is up to you to make sure that ELTNUM is not negative and is 15598 less than 'XVECLEN (EXP, IDX)'. 15599 15600 All the macros defined in this section expand into lvalues and 15601therefore can be used to assign the operands, lengths and vector 15602elements as well as to access them. 15603 15604 15605File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL 15606 1560714.4 Access to Special Operands 15608=============================== 15609 15610Some RTL nodes have special annotations associated with them. 15611 15612'MEM' 15613 'MEM_ALIAS_SET (X)' 15614 If 0, X is not in any alias set, and may alias anything. 15615 Otherwise, X can only alias 'MEM's in a conflicting alias set. 15616 This value is set in a language-dependent manner in the 15617 front-end, and should not be altered in the back-end. In some 15618 front-ends, these numbers may correspond in some way to types, 15619 or other language-level entities, but they need not, and the 15620 back-end makes no such assumptions. These set numbers are 15621 tested with 'alias_sets_conflict_p'. 15622 15623 'MEM_EXPR (X)' 15624 If this register is known to hold the value of some user-level 15625 declaration, this is that tree node. It may also be a 15626 'COMPONENT_REF', in which case this is some field reference, 15627 and 'TREE_OPERAND (X, 0)' contains the declaration, or another 15628 'COMPONENT_REF', or null if there is no compile-time object 15629 associated with the reference. 15630 15631 'MEM_OFFSET_KNOWN_P (X)' 15632 True if the offset of the memory reference from 'MEM_EXPR' is 15633 known. 'MEM_OFFSET (X)' provides the offset if so. 15634 15635 'MEM_OFFSET (X)' 15636 The offset from the start of 'MEM_EXPR'. The value is only 15637 valid if 'MEM_OFFSET_KNOWN_P (X)' is true. 15638 15639 'MEM_SIZE_KNOWN_P (X)' 15640 True if the size of the memory reference is known. 'MEM_SIZE 15641 (X)' provides its size if so. 15642 15643 'MEM_SIZE (X)' 15644 The size in bytes of the memory reference. This is mostly 15645 relevant for 'BLKmode' references as otherwise the size is 15646 implied by the mode. The value is only valid if 15647 'MEM_SIZE_KNOWN_P (X)' is true. 15648 15649 'MEM_ALIGN (X)' 15650 The known alignment in bits of the memory reference. 15651 15652 'MEM_ADDR_SPACE (X)' 15653 The address space of the memory reference. This will commonly 15654 be zero for the generic address space. 15655 15656'REG' 15657 'ORIGINAL_REGNO (X)' 15658 This field holds the number the register "originally" had; for 15659 a pseudo register turned into a hard reg this will hold the 15660 old pseudo register number. 15661 15662 'REG_EXPR (X)' 15663 If this register is known to hold the value of some user-level 15664 declaration, this is that tree node. 15665 15666 'REG_OFFSET (X)' 15667 If this register is known to hold the value of some user-level 15668 declaration, this is the offset into that logical storage. 15669 15670'SYMBOL_REF' 15671 'SYMBOL_REF_DECL (X)' 15672 If the 'symbol_ref' X was created for a 'VAR_DECL' or a 15673 'FUNCTION_DECL', that tree is recorded here. If this value is 15674 null, then X was created by back end code generation routines, 15675 and there is no associated front end symbol table entry. 15676 15677 'SYMBOL_REF_DECL' may also point to a tree of class ''c'', 15678 that is, some sort of constant. In this case, the 15679 'symbol_ref' is an entry in the per-file constant pool; again, 15680 there is no associated front end symbol table entry. 15681 15682 'SYMBOL_REF_CONSTANT (X)' 15683 If 'CONSTANT_POOL_ADDRESS_P (X)' is true, this is the constant 15684 pool entry for X. It is null otherwise. 15685 15686 'SYMBOL_REF_DATA (X)' 15687 A field of opaque type used to store 'SYMBOL_REF_DECL' or 15688 'SYMBOL_REF_CONSTANT'. 15689 15690 'SYMBOL_REF_FLAGS (X)' 15691 In a 'symbol_ref', this is used to communicate various 15692 predicates about the symbol. Some of these are common enough 15693 to be computed by common code, some are specific to the 15694 target. The common bits are: 15695 15696 'SYMBOL_FLAG_FUNCTION' 15697 Set if the symbol refers to a function. 15698 15699 'SYMBOL_FLAG_LOCAL' 15700 Set if the symbol is local to this "module". See 15701 'TARGET_BINDS_LOCAL_P'. 15702 15703 'SYMBOL_FLAG_EXTERNAL' 15704 Set if this symbol is not defined in this translation 15705 unit. Note that this is not the inverse of 15706 'SYMBOL_FLAG_LOCAL'. 15707 15708 'SYMBOL_FLAG_SMALL' 15709 Set if the symbol is located in the small data section. 15710 See 'TARGET_IN_SMALL_DATA_P'. 15711 15712 'SYMBOL_REF_TLS_MODEL (X)' 15713 This is a multi-bit field accessor that returns the 15714 'tls_model' to be used for a thread-local storage symbol. 15715 It returns zero for non-thread-local symbols. 15716 15717 'SYMBOL_FLAG_HAS_BLOCK_INFO' 15718 Set if the symbol has 'SYMBOL_REF_BLOCK' and 15719 'SYMBOL_REF_BLOCK_OFFSET' fields. 15720 15721 'SYMBOL_FLAG_ANCHOR' 15722 Set if the symbol is used as a section anchor. "Section 15723 anchors" are symbols that have a known position within an 15724 'object_block' and that can be used to access nearby 15725 members of that block. They are used to implement 15726 '-fsection-anchors'. 15727 15728 If this flag is set, then 'SYMBOL_FLAG_HAS_BLOCK_INFO' 15729 will be too. 15730 15731 Bits beginning with 'SYMBOL_FLAG_MACH_DEP' are available for 15732 the target's use. 15733 15734'SYMBOL_REF_BLOCK (X)' 15735 If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the 'object_block' 15736 structure to which the symbol belongs, or 'NULL' if it has not been 15737 assigned a block. 15738 15739'SYMBOL_REF_BLOCK_OFFSET (X)' 15740 If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the offset of X from 15741 the first object in 'SYMBOL_REF_BLOCK (X)'. The value is negative 15742 if X has not yet been assigned to a block, or it has not been given 15743 an offset within that block. 15744 15745 15746File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL 15747 1574814.5 Flags in an RTL Expression 15749=============================== 15750 15751RTL expressions contain several flags (one-bit bit-fields) that are used 15752in certain types of expression. Most often they are accessed with the 15753following macros, which expand into lvalues. 15754 15755'CROSSING_JUMP_P (X)' 15756 Nonzero in a 'jump_insn' if it crosses between hot and cold 15757 sections, which could potentially be very far apart in the 15758 executable. The presence of this flag indicates to other 15759 optimizations that this branching instruction should not be 15760 "collapsed" into a simpler branching construct. It is used when 15761 the optimization to partition basic blocks into hot and cold 15762 sections is turned on. 15763 15764'CONSTANT_POOL_ADDRESS_P (X)' 15765 Nonzero in a 'symbol_ref' if it refers to part of the current 15766 function's constant pool. For most targets these addresses are in 15767 a '.rodata' section entirely separate from the function, but for 15768 some targets the addresses are close to the beginning of the 15769 function. In either case GCC assumes these addresses can be 15770 addressed directly, perhaps with the help of base registers. 15771 Stored in the 'unchanging' field and printed as '/u'. 15772 15773'INSN_ANNULLED_BRANCH_P (X)' 15774 In a 'jump_insn', 'call_insn', or 'insn' indicates that the branch 15775 is an annulling one. See the discussion under 'sequence' below. 15776 Stored in the 'unchanging' field and printed as '/u'. 15777 15778'INSN_DELETED_P (X)' 15779 In an 'insn', 'call_insn', 'jump_insn', 'code_label', 15780 'jump_table_data', 'barrier', or 'note', nonzero if the insn has 15781 been deleted. Stored in the 'volatil' field and printed as '/v'. 15782 15783'INSN_FROM_TARGET_P (X)' 15784 In an 'insn' or 'jump_insn' or 'call_insn' in a delay slot of a 15785 branch, indicates that the insn is from the target of the branch. 15786 If the branch insn has 'INSN_ANNULLED_BRANCH_P' set, this insn will 15787 only be executed if the branch is taken. For annulled branches 15788 with 'INSN_FROM_TARGET_P' clear, the insn will be executed only if 15789 the branch is not taken. When 'INSN_ANNULLED_BRANCH_P' is not set, 15790 this insn will always be executed. Stored in the 'in_struct' field 15791 and printed as '/s'. 15792 15793'LABEL_PRESERVE_P (X)' 15794 In a 'code_label' or 'note', indicates that the label is referenced 15795 by code or data not visible to the RTL of a given function. Labels 15796 referenced by a non-local goto will have this bit set. Stored in 15797 the 'in_struct' field and printed as '/s'. 15798 15799'LABEL_REF_NONLOCAL_P (X)' 15800 In 'label_ref' and 'reg_label' expressions, nonzero if this is a 15801 reference to a non-local label. Stored in the 'volatil' field and 15802 printed as '/v'. 15803 15804'MEM_KEEP_ALIAS_SET_P (X)' 15805 In 'mem' expressions, 1 if we should keep the alias set for this 15806 mem unchanged when we access a component. Set to 1, for example, 15807 when we are already in a non-addressable component of an aggregate. 15808 Stored in the 'jump' field and printed as '/j'. 15809 15810'MEM_VOLATILE_P (X)' 15811 In 'mem', 'asm_operands', and 'asm_input' expressions, nonzero for 15812 volatile memory references. Stored in the 'volatil' field and 15813 printed as '/v'. 15814 15815'MEM_NOTRAP_P (X)' 15816 In 'mem', nonzero for memory references that will not trap. Stored 15817 in the 'call' field and printed as '/c'. 15818 15819'MEM_POINTER (X)' 15820 Nonzero in a 'mem' if the memory reference holds a pointer. Stored 15821 in the 'frame_related' field and printed as '/f'. 15822 15823'MEM_READONLY_P (X)' 15824 Nonzero in a 'mem', if the memory is statically allocated and 15825 read-only. 15826 15827 Read-only in this context means never modified during the lifetime 15828 of the program, not necessarily in ROM or in write-disabled pages. 15829 A common example of the later is a shared library's global offset 15830 table. This table is initialized by the runtime loader, so the 15831 memory is technically writable, but after control is transferred 15832 from the runtime loader to the application, this memory will never 15833 be subsequently modified. 15834 15835 Stored in the 'unchanging' field and printed as '/u'. 15836 15837'PREFETCH_SCHEDULE_BARRIER_P (X)' 15838 In a 'prefetch', indicates that the prefetch is a scheduling 15839 barrier. No other INSNs will be moved over it. Stored in the 15840 'volatil' field and printed as '/v'. 15841 15842'REG_FUNCTION_VALUE_P (X)' 15843 Nonzero in a 'reg' if it is the place in which this function's 15844 value is going to be returned. (This happens only in a hard 15845 register.) Stored in the 'return_val' field and printed as '/i'. 15846 15847'REG_POINTER (X)' 15848 Nonzero in a 'reg' if the register holds a pointer. Stored in the 15849 'frame_related' field and printed as '/f'. 15850 15851'REG_USERVAR_P (X)' 15852 In a 'reg', nonzero if it corresponds to a variable present in the 15853 user's source code. Zero for temporaries generated internally by 15854 the compiler. Stored in the 'volatil' field and printed as '/v'. 15855 15856 The same hard register may be used also for collecting the values 15857 of functions called by this one, but 'REG_FUNCTION_VALUE_P' is zero 15858 in this kind of use. 15859 15860'RTL_CONST_CALL_P (X)' 15861 In a 'call_insn' indicates that the insn represents a call to a 15862 const function. Stored in the 'unchanging' field and printed as 15863 '/u'. 15864 15865'RTL_PURE_CALL_P (X)' 15866 In a 'call_insn' indicates that the insn represents a call to a 15867 pure function. Stored in the 'return_val' field and printed as 15868 '/i'. 15869 15870'RTL_CONST_OR_PURE_CALL_P (X)' 15871 In a 'call_insn', true if 'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P' 15872 is true. 15873 15874'RTL_LOOPING_CONST_OR_PURE_CALL_P (X)' 15875 In a 'call_insn' indicates that the insn represents a possibly 15876 infinite looping call to a const or pure function. Stored in the 15877 'call' field and printed as '/c'. Only true if one of 15878 'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P' is true. 15879 15880'RTX_FRAME_RELATED_P (X)' 15881 Nonzero in an 'insn', 'call_insn', 'jump_insn', 'barrier', or 'set' 15882 which is part of a function prologue and sets the stack pointer, 15883 sets the frame pointer, or saves a register. This flag should also 15884 be set on an instruction that sets up a temporary register to use 15885 in place of the frame pointer. Stored in the 'frame_related' field 15886 and printed as '/f'. 15887 15888 In particular, on RISC targets where there are limits on the sizes 15889 of immediate constants, it is sometimes impossible to reach the 15890 register save area directly from the stack pointer. In that case, 15891 a temporary register is used that is near enough to the register 15892 save area, and the Canonical Frame Address, i.e., DWARF2's logical 15893 frame pointer, register must (temporarily) be changed to be this 15894 temporary register. So, the instruction that sets this temporary 15895 register must be marked as 'RTX_FRAME_RELATED_P'. 15896 15897 If the marked instruction is overly complex (defined in terms of 15898 what 'dwarf2out_frame_debug_expr' can handle), you will also have 15899 to create a 'REG_FRAME_RELATED_EXPR' note and attach it to the 15900 instruction. This note should contain a simple expression of the 15901 computation performed by this instruction, i.e., one that 15902 'dwarf2out_frame_debug_expr' can handle. 15903 15904 This flag is required for exception handling support on targets 15905 with RTL prologues. 15906 15907'SCHED_GROUP_P (X)' 15908 During instruction scheduling, in an 'insn', 'call_insn', 15909 'jump_insn' or 'jump_table_data', indicates that the previous insn 15910 must be scheduled together with this insn. This is used to ensure 15911 that certain groups of instructions will not be split up by the 15912 instruction scheduling pass, for example, 'use' insns before a 15913 'call_insn' may not be separated from the 'call_insn'. Stored in 15914 the 'in_struct' field and printed as '/s'. 15915 15916'SET_IS_RETURN_P (X)' 15917 For a 'set', nonzero if it is for a return. Stored in the 'jump' 15918 field and printed as '/j'. 15919 15920'SIBLING_CALL_P (X)' 15921 For a 'call_insn', nonzero if the insn is a sibling call. Stored 15922 in the 'jump' field and printed as '/j'. 15923 15924'STRING_POOL_ADDRESS_P (X)' 15925 For a 'symbol_ref' expression, nonzero if it addresses this 15926 function's string constant pool. Stored in the 'frame_related' 15927 field and printed as '/f'. 15928 15929'SUBREG_PROMOTED_UNSIGNED_P (X)' 15930 Returns a value greater then zero for a 'subreg' that has 15931 'SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is 15932 kept zero-extended, zero if it is kept sign-extended, and less then 15933 zero if it is extended some other way via the 'ptr_extend' 15934 instruction. Stored in the 'unchanging' field and 'volatil' field, 15935 printed as '/u' and '/v'. This macro may only be used to get the 15936 value it may not be used to change the value. Use 15937 'SUBREG_PROMOTED_UNSIGNED_SET' to change the value. 15938 15939'SUBREG_PROMOTED_UNSIGNED_SET (X)' 15940 Set the 'unchanging' and 'volatil' fields in a 'subreg' to reflect 15941 zero, sign, or other extension. If 'volatil' is zero, then 15942 'unchanging' as nonzero means zero extension and as zero means sign 15943 extension. If 'volatil' is nonzero then some other type of 15944 extension was done via the 'ptr_extend' instruction. 15945 15946'SUBREG_PROMOTED_VAR_P (X)' 15947 Nonzero in a 'subreg' if it was made when accessing an object that 15948 was promoted to a wider mode in accord with the 'PROMOTED_MODE' 15949 machine description macro (*note Storage Layout::). In this case, 15950 the mode of the 'subreg' is the declared mode of the object and the 15951 mode of 'SUBREG_REG' is the mode of the register that holds the 15952 object. Promoted variables are always either sign- or 15953 zero-extended to the wider mode on every assignment. Stored in the 15954 'in_struct' field and printed as '/s'. 15955 15956'SYMBOL_REF_USED (X)' 15957 In a 'symbol_ref', indicates that X has been used. This is 15958 normally only used to ensure that X is only declared external once. 15959 Stored in the 'used' field. 15960 15961'SYMBOL_REF_WEAK (X)' 15962 In a 'symbol_ref', indicates that X has been declared weak. Stored 15963 in the 'return_val' field and printed as '/i'. 15964 15965'SYMBOL_REF_FLAG (X)' 15966 In a 'symbol_ref', this is used as a flag for machine-specific 15967 purposes. Stored in the 'volatil' field and printed as '/v'. 15968 15969 Most uses of 'SYMBOL_REF_FLAG' are historic and may be subsumed by 15970 'SYMBOL_REF_FLAGS'. Certainly use of 'SYMBOL_REF_FLAGS' is 15971 mandatory if the target requires more than one bit of storage. 15972 15973 These are the fields to which the above macros refer: 15974 15975'call' 15976 In a 'mem', 1 means that the memory reference will not trap. 15977 15978 In a 'call', 1 means that this pure or const call may possibly 15979 infinite loop. 15980 15981 In an RTL dump, this flag is represented as '/c'. 15982 15983'frame_related' 15984 In an 'insn' or 'set' expression, 1 means that it is part of a 15985 function prologue and sets the stack pointer, sets the frame 15986 pointer, saves a register, or sets up a temporary register to use 15987 in place of the frame pointer. 15988 15989 In 'reg' expressions, 1 means that the register holds a pointer. 15990 15991 In 'mem' expressions, 1 means that the memory reference holds a 15992 pointer. 15993 15994 In 'symbol_ref' expressions, 1 means that the reference addresses 15995 this function's string constant pool. 15996 15997 In an RTL dump, this flag is represented as '/f'. 15998 15999'in_struct' 16000 In 'reg' expressions, it is 1 if the register has its entire life 16001 contained within the test expression of some loop. 16002 16003 In 'subreg' expressions, 1 means that the 'subreg' is accessing an 16004 object that has had its mode promoted from a wider mode. 16005 16006 In 'label_ref' expressions, 1 means that the referenced label is 16007 outside the innermost loop containing the insn in which the 16008 'label_ref' was found. 16009 16010 In 'code_label' expressions, it is 1 if the label may never be 16011 deleted. This is used for labels which are the target of non-local 16012 gotos. Such a label that would have been deleted is replaced with 16013 a 'note' of type 'NOTE_INSN_DELETED_LABEL'. 16014 16015 In an 'insn' during dead-code elimination, 1 means that the insn is 16016 dead code. 16017 16018 In an 'insn' or 'jump_insn' during reorg for an insn in the delay 16019 slot of a branch, 1 means that this insn is from the target of the 16020 branch. 16021 16022 In an 'insn' during instruction scheduling, 1 means that this insn 16023 must be scheduled as part of a group together with the previous 16024 insn. 16025 16026 In an RTL dump, this flag is represented as '/s'. 16027 16028'return_val' 16029 In 'reg' expressions, 1 means the register contains the value to be 16030 returned by the current function. On machines that pass parameters 16031 in registers, the same register number may be used for parameters 16032 as well, but this flag is not set on such uses. 16033 16034 In 'symbol_ref' expressions, 1 means the referenced symbol is weak. 16035 16036 In 'call' expressions, 1 means the call is pure. 16037 16038 In an RTL dump, this flag is represented as '/i'. 16039 16040'jump' 16041 In a 'mem' expression, 1 means we should keep the alias set for 16042 this mem unchanged when we access a component. 16043 16044 In a 'set', 1 means it is for a return. 16045 16046 In a 'call_insn', 1 means it is a sibling call. 16047 16048 In a 'jump_insn', 1 means it is a crossing jump. 16049 16050 In an RTL dump, this flag is represented as '/j'. 16051 16052'unchanging' 16053 In 'reg' and 'mem' expressions, 1 means that the value of the 16054 expression never changes. 16055 16056 In 'subreg' expressions, it is 1 if the 'subreg' references an 16057 unsigned object whose mode has been promoted to a wider mode. 16058 16059 In an 'insn' or 'jump_insn' in the delay slot of a branch 16060 instruction, 1 means an annulling branch should be used. 16061 16062 In a 'symbol_ref' expression, 1 means that this symbol addresses 16063 something in the per-function constant pool. 16064 16065 In a 'call_insn' 1 means that this instruction is a call to a const 16066 function. 16067 16068 In an RTL dump, this flag is represented as '/u'. 16069 16070'used' 16071 This flag is used directly (without an access macro) at the end of 16072 RTL generation for a function, to count the number of times an 16073 expression appears in insns. Expressions that appear more than 16074 once are copied, according to the rules for shared structure (*note 16075 Sharing::). 16076 16077 For a 'reg', it is used directly (without an access macro) by the 16078 leaf register renumbering code to ensure that each register is only 16079 renumbered once. 16080 16081 In a 'symbol_ref', it indicates that an external declaration for 16082 the symbol has already been written. 16083 16084'volatil' 16085 In a 'mem', 'asm_operands', or 'asm_input' expression, it is 1 if 16086 the memory reference is volatile. Volatile memory references may 16087 not be deleted, reordered or combined. 16088 16089 In a 'symbol_ref' expression, it is used for machine-specific 16090 purposes. 16091 16092 In a 'reg' expression, it is 1 if the value is a user-level 16093 variable. 0 indicates an internal compiler temporary. 16094 16095 In an 'insn', 1 means the insn has been deleted. 16096 16097 In 'label_ref' and 'reg_label' expressions, 1 means a reference to 16098 a non-local label. 16099 16100 In 'prefetch' expressions, 1 means that the containing insn is a 16101 scheduling barrier. 16102 16103 In an RTL dump, this flag is represented as '/v'. 16104 16105 16106File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 16107 1610814.6 Machine Modes 16109================== 16110 16111A machine mode describes a size of data object and the representation 16112used for it. In the C code, machine modes are represented by an 16113enumeration type, 'machine_mode', defined in 'machmode.def'. Each RTL 16114expression has room for a machine mode and so do certain kinds of tree 16115expressions (declarations and types, to be precise). 16116 16117 In debugging dumps and machine descriptions, the machine mode of an RTL 16118expression is written after the expression code with a colon to separate 16119them. The letters 'mode' which appear at the end of each machine mode 16120name are omitted. For example, '(reg:SI 38)' is a 'reg' expression with 16121machine mode 'SImode'. If the mode is 'VOIDmode', it is not written at 16122all. 16123 16124 Here is a table of machine modes. The term "byte" below refers to an 16125object of 'BITS_PER_UNIT' bits (*note Storage Layout::). 16126 16127'BImode' 16128 "Bit" mode represents a single bit, for predicate registers. 16129 16130'QImode' 16131 "Quarter-Integer" mode represents a single byte treated as an 16132 integer. 16133 16134'HImode' 16135 "Half-Integer" mode represents a two-byte integer. 16136 16137'PSImode' 16138 "Partial Single Integer" mode represents an integer which occupies 16139 four bytes but which doesn't really use all four. On some 16140 machines, this is the right mode to use for pointers. 16141 16142'SImode' 16143 "Single Integer" mode represents a four-byte integer. 16144 16145'PDImode' 16146 "Partial Double Integer" mode represents an integer which occupies 16147 eight bytes but which doesn't really use all eight. On some 16148 machines, this is the right mode to use for certain pointers. 16149 16150'DImode' 16151 "Double Integer" mode represents an eight-byte integer. 16152 16153'TImode' 16154 "Tetra Integer" (?) mode represents a sixteen-byte integer. 16155 16156'OImode' 16157 "Octa Integer" (?) mode represents a thirty-two-byte integer. 16158 16159'XImode' 16160 "Hexadeca Integer" (?) mode represents a sixty-four-byte integer. 16161 16162'QFmode' 16163 "Quarter-Floating" mode represents a quarter-precision (single 16164 byte) floating point number. 16165 16166'HFmode' 16167 "Half-Floating" mode represents a half-precision (two byte) 16168 floating point number. 16169 16170'TQFmode' 16171 "Three-Quarter-Floating" (?) mode represents a 16172 three-quarter-precision (three byte) floating point number. 16173 16174'SFmode' 16175 "Single Floating" mode represents a four byte floating point 16176 number. In the common case, of a processor with IEEE arithmetic 16177 and 8-bit bytes, this is a single-precision IEEE floating point 16178 number; it can also be used for double-precision (on processors 16179 with 16-bit bytes) and single-precision VAX and IBM types. 16180 16181'DFmode' 16182 "Double Floating" mode represents an eight byte floating point 16183 number. In the common case, of a processor with IEEE arithmetic 16184 and 8-bit bytes, this is a double-precision IEEE floating point 16185 number. 16186 16187'XFmode' 16188 "Extended Floating" mode represents an IEEE extended floating point 16189 number. This mode only has 80 meaningful bits (ten bytes). Some 16190 processors require such numbers to be padded to twelve bytes, 16191 others to sixteen; this mode is used for either. 16192 16193'SDmode' 16194 "Single Decimal Floating" mode represents a four byte decimal 16195 floating point number (as distinct from conventional binary 16196 floating point). 16197 16198'DDmode' 16199 "Double Decimal Floating" mode represents an eight byte decimal 16200 floating point number. 16201 16202'TDmode' 16203 "Tetra Decimal Floating" mode represents a sixteen byte decimal 16204 floating point number all 128 of whose bits are meaningful. 16205 16206'TFmode' 16207 "Tetra Floating" mode represents a sixteen byte floating point 16208 number all 128 of whose bits are meaningful. One common use is the 16209 IEEE quad-precision format. 16210 16211'QQmode' 16212 "Quarter-Fractional" mode represents a single byte treated as a 16213 signed fractional number. The default format is "s.7". 16214 16215'HQmode' 16216 "Half-Fractional" mode represents a two-byte signed fractional 16217 number. The default format is "s.15". 16218 16219'SQmode' 16220 "Single Fractional" mode represents a four-byte signed fractional 16221 number. The default format is "s.31". 16222 16223'DQmode' 16224 "Double Fractional" mode represents an eight-byte signed fractional 16225 number. The default format is "s.63". 16226 16227'TQmode' 16228 "Tetra Fractional" mode represents a sixteen-byte signed fractional 16229 number. The default format is "s.127". 16230 16231'UQQmode' 16232 "Unsigned Quarter-Fractional" mode represents a single byte treated 16233 as an unsigned fractional number. The default format is ".8". 16234 16235'UHQmode' 16236 "Unsigned Half-Fractional" mode represents a two-byte unsigned 16237 fractional number. The default format is ".16". 16238 16239'USQmode' 16240 "Unsigned Single Fractional" mode represents a four-byte unsigned 16241 fractional number. The default format is ".32". 16242 16243'UDQmode' 16244 "Unsigned Double Fractional" mode represents an eight-byte unsigned 16245 fractional number. The default format is ".64". 16246 16247'UTQmode' 16248 "Unsigned Tetra Fractional" mode represents a sixteen-byte unsigned 16249 fractional number. The default format is ".128". 16250 16251'HAmode' 16252 "Half-Accumulator" mode represents a two-byte signed accumulator. 16253 The default format is "s8.7". 16254 16255'SAmode' 16256 "Single Accumulator" mode represents a four-byte signed 16257 accumulator. The default format is "s16.15". 16258 16259'DAmode' 16260 "Double Accumulator" mode represents an eight-byte signed 16261 accumulator. The default format is "s32.31". 16262 16263'TAmode' 16264 "Tetra Accumulator" mode represents a sixteen-byte signed 16265 accumulator. The default format is "s64.63". 16266 16267'UHAmode' 16268 "Unsigned Half-Accumulator" mode represents a two-byte unsigned 16269 accumulator. The default format is "8.8". 16270 16271'USAmode' 16272 "Unsigned Single Accumulator" mode represents a four-byte unsigned 16273 accumulator. The default format is "16.16". 16274 16275'UDAmode' 16276 "Unsigned Double Accumulator" mode represents an eight-byte 16277 unsigned accumulator. The default format is "32.32". 16278 16279'UTAmode' 16280 "Unsigned Tetra Accumulator" mode represents a sixteen-byte 16281 unsigned accumulator. The default format is "64.64". 16282 16283'CCmode' 16284 "Condition Code" mode represents the value of a condition code, 16285 which is a machine-specific set of bits used to represent the 16286 result of a comparison operation. Other machine-specific modes may 16287 also be used for the condition code. These modes are not used on 16288 machines that use 'cc0' (*note Condition Code::). 16289 16290'BLKmode' 16291 "Block" mode represents values that are aggregates to which none of 16292 the other modes apply. In RTL, only memory references can have 16293 this mode, and only if they appear in string-move or vector 16294 instructions. On machines which have no such instructions, 16295 'BLKmode' will not appear in RTL. 16296 16297'VOIDmode' 16298 Void mode means the absence of a mode or an unspecified mode. For 16299 example, RTL expressions of code 'const_int' have mode 'VOIDmode' 16300 because they can be taken to have whatever mode the context 16301 requires. In debugging dumps of RTL, 'VOIDmode' is expressed by 16302 the absence of any mode. 16303 16304'QCmode, HCmode, SCmode, DCmode, XCmode, TCmode' 16305 These modes stand for a complex number represented as a pair of 16306 floating point values. The floating point values are in 'QFmode', 16307 'HFmode', 'SFmode', 'DFmode', 'XFmode', and 'TFmode', respectively. 16308 16309'CQImode, CHImode, CSImode, CDImode, CTImode, COImode, CPSImode' 16310 These modes stand for a complex number represented as a pair of 16311 integer values. The integer values are in 'QImode', 'HImode', 16312 'SImode', 'DImode', 'TImode', 'OImode', and 'PSImode', 16313 respectively. 16314 16315'BND32mode BND64mode' 16316 These modes stand for bounds for pointer of 32 and 64 bit size 16317 respectively. Mode size is double pointer mode size. 16318 16319 The machine description defines 'Pmode' as a C macro which expands into 16320the machine mode used for addresses. Normally this is the mode whose 16321size is 'BITS_PER_WORD', 'SImode' on 32-bit machines. 16322 16323 The only modes which a machine description must support are 'QImode', 16324and the modes corresponding to 'BITS_PER_WORD', 'FLOAT_TYPE_SIZE' and 16325'DOUBLE_TYPE_SIZE'. The compiler will attempt to use 'DImode' for 163268-byte structures and unions, but this can be prevented by overriding 16327the definition of 'MAX_FIXED_MODE_SIZE'. Alternatively, you can have 16328the compiler use 'TImode' for 16-byte structures and unions. Likewise, 16329you can arrange for the C type 'short int' to avoid using 'HImode'. 16330 16331 Very few explicit references to machine modes remain in the compiler 16332and these few references will soon be removed. Instead, the machine 16333modes are divided into mode classes. These are represented by the 16334enumeration type 'enum mode_class' defined in 'machmode.h'. The 16335possible mode classes are: 16336 16337'MODE_INT' 16338 Integer modes. By default these are 'BImode', 'QImode', 'HImode', 16339 'SImode', 'DImode', 'TImode', and 'OImode'. 16340 16341'MODE_PARTIAL_INT' 16342 The "partial integer" modes, 'PQImode', 'PHImode', 'PSImode' and 16343 'PDImode'. 16344 16345'MODE_FLOAT' 16346 Floating point modes. By default these are 'QFmode', 'HFmode', 16347 'TQFmode', 'SFmode', 'DFmode', 'XFmode' and 'TFmode'. 16348 16349'MODE_DECIMAL_FLOAT' 16350 Decimal floating point modes. By default these are 'SDmode', 16351 'DDmode' and 'TDmode'. 16352 16353'MODE_FRACT' 16354 Signed fractional modes. By default these are 'QQmode', 'HQmode', 16355 'SQmode', 'DQmode' and 'TQmode'. 16356 16357'MODE_UFRACT' 16358 Unsigned fractional modes. By default these are 'UQQmode', 16359 'UHQmode', 'USQmode', 'UDQmode' and 'UTQmode'. 16360 16361'MODE_ACCUM' 16362 Signed accumulator modes. By default these are 'HAmode', 'SAmode', 16363 'DAmode' and 'TAmode'. 16364 16365'MODE_UACCUM' 16366 Unsigned accumulator modes. By default these are 'UHAmode', 16367 'USAmode', 'UDAmode' and 'UTAmode'. 16368 16369'MODE_COMPLEX_INT' 16370 Complex integer modes. (These are not currently implemented). 16371 16372'MODE_COMPLEX_FLOAT' 16373 Complex floating point modes. By default these are 'QCmode', 16374 'HCmode', 'SCmode', 'DCmode', 'XCmode', and 'TCmode'. 16375 16376'MODE_FUNCTION' 16377 Algol or Pascal function variables including a static chain. 16378 (These are not currently implemented). 16379 16380'MODE_CC' 16381 Modes representing condition code values. These are 'CCmode' plus 16382 any 'CC_MODE' modes listed in the 'MACHINE-modes.def'. *Note Jump 16383 Patterns::, also see *note Condition Code::. 16384 16385'MODE_POINTER_BOUNDS' 16386 Pointer bounds modes. Used to represent values of pointer bounds 16387 type. Operations in these modes may be executed as NOPs depending 16388 on hardware features and environment setup. 16389 16390'MODE_RANDOM' 16391 This is a catchall mode class for modes which don't fit into the 16392 above classes. Currently 'VOIDmode' and 'BLKmode' are in 16393 'MODE_RANDOM'. 16394 16395 'machmode.h' also defines various wrapper classes that combine a 16396'machine_mode' with a static assertion that a particular condition 16397holds. The classes are: 16398 16399'scalar_int_mode' 16400 A mode that has class 'MODE_INT' or 'MODE_PARTIAL_INT'. 16401 16402'scalar_float_mode' 16403 A mode that has class 'MODE_FLOAT' or 'MODE_DECIMAL_FLOAT'. 16404 16405'scalar_mode' 16406 A mode that holds a single numerical value. In practice this means 16407 that the mode is a 'scalar_int_mode', is a 'scalar_float_mode', or 16408 has class 'MODE_FRACT', 'MODE_UFRACT', 'MODE_ACCUM', 'MODE_UACCUM' 16409 or 'MODE_POINTER_BOUNDS'. 16410 16411'complex_mode' 16412 A mode that has class 'MODE_COMPLEX_INT' or 'MODE_COMPLEX_FLOAT'. 16413 16414'fixed_size_mode' 16415 A mode whose size is known at compile time. 16416 16417 Named modes use the most constrained of the available wrapper classes, 16418if one exists, otherwise they use 'machine_mode'. For example, 'QImode' 16419is a 'scalar_int_mode', 'SFmode' is a 'scalar_float_mode' and 'BLKmode' 16420is a plain 'machine_mode'. It is possible to refer to any mode as a raw 16421'machine_mode' by adding the 'E_' prefix, where 'E' stands for 16422"enumeration". For example, the raw 'machine_mode' names of the modes 16423just mentioned are 'E_QImode', 'E_SFmode' and 'E_BLKmode' respectively. 16424 16425 The wrapper classes implicitly convert to 'machine_mode' and to any 16426wrapper class that represents a more general condition; for example 16427'scalar_int_mode' and 'scalar_float_mode' both convert to 'scalar_mode' 16428and all three convert to 'fixed_size_mode'. The classes act like 16429'machine_mode's that accept only certain named modes. 16430 16431 'machmode.h' also defines a template class 'opt_mode<T>' that holds a 16432'T' or nothing, where 'T' can be either 'machine_mode' or one of the 16433wrapper classes above. The main operations on an 'opt_mode<T>' X are as 16434follows: 16435 16436'X.exists ()' 16437 Return true if X holds a mode rather than nothing. 16438 16439'X.exists (&Y)' 16440 Return true if X holds a mode rather than nothing, storing the mode 16441 in Y if so. Y must be assignment-compatible with T. 16442 16443'X.require ()' 16444 Assert that X holds a mode rather than nothing and return that 16445 mode. 16446 16447'X = Y' 16448 Set X to Y, where Y is a T or implicitly converts to a T. 16449 16450 The default constructor sets an 'opt_mode<T>' to nothing. There is 16451also a constructor that takes an initial value of type T. 16452 16453 It is possible to use the 'is-a.h' accessors on a 'machine_mode' or 16454machine mode wrapper X: 16455 16456'is_a <T> (X)' 16457 Return true if X meets the conditions for wrapper class T. 16458 16459'is_a <T> (X, &Y)' 16460 Return true if X meets the conditions for wrapper class T, storing 16461 it in Y if so. Y must be assignment-compatible with T. 16462 16463'as_a <T> (X)' 16464 Assert that X meets the conditions for wrapper class T and return 16465 it as a T. 16466 16467'dyn_cast <T> (X)' 16468 Return an 'opt_mode<T>' that holds X if X meets the conditions for 16469 wrapper class T and that holds nothing otherwise. 16470 16471 The purpose of these wrapper classes is to give stronger static type 16472checking. For example, if a function takes a 'scalar_int_mode', a 16473caller that has a general 'machine_mode' must either check or assert 16474that the code is indeed a scalar integer first, using one of the 16475functions above. 16476 16477 The wrapper classes are normal C++ classes, with user-defined 16478constructors. Sometimes it is useful to have a POD version of the same 16479type, particularly if the type appears in a 'union'. The template class 16480'pod_mode<T>' provides a POD version of wrapper class T. It is 16481assignment-compatible with T and implicitly converts to both 16482'machine_mode' and T. 16483 16484 Here are some C macros that relate to machine modes: 16485 16486'GET_MODE (X)' 16487 Returns the machine mode of the RTX X. 16488 16489'PUT_MODE (X, NEWMODE)' 16490 Alters the machine mode of the RTX X to be NEWMODE. 16491 16492'NUM_MACHINE_MODES' 16493 Stands for the number of machine modes available on the target 16494 machine. This is one greater than the largest numeric value of any 16495 machine mode. 16496 16497'GET_MODE_NAME (M)' 16498 Returns the name of mode M as a string. 16499 16500'GET_MODE_CLASS (M)' 16501 Returns the mode class of mode M. 16502 16503'GET_MODE_WIDER_MODE (M)' 16504 Returns the next wider natural mode. For example, the expression 16505 'GET_MODE_WIDER_MODE (QImode)' returns 'HImode'. 16506 16507'GET_MODE_SIZE (M)' 16508 Returns the size in bytes of a datum of mode M. 16509 16510'GET_MODE_BITSIZE (M)' 16511 Returns the size in bits of a datum of mode M. 16512 16513'GET_MODE_IBIT (M)' 16514 Returns the number of integral bits of a datum of fixed-point mode 16515 M. 16516 16517'GET_MODE_FBIT (M)' 16518 Returns the number of fractional bits of a datum of fixed-point 16519 mode M. 16520 16521'GET_MODE_MASK (M)' 16522 Returns a bitmask containing 1 for all bits in a word that fit 16523 within mode M. This macro can only be used for modes whose bitsize 16524 is less than or equal to 'HOST_BITS_PER_INT'. 16525 16526'GET_MODE_ALIGNMENT (M)' 16527 Return the required alignment, in bits, for an object of mode M. 16528 16529'GET_MODE_UNIT_SIZE (M)' 16530 Returns the size in bytes of the subunits of a datum of mode M. 16531 This is the same as 'GET_MODE_SIZE' except in the case of complex 16532 modes. For them, the unit size is the size of the real or 16533 imaginary part. 16534 16535'GET_MODE_NUNITS (M)' 16536 Returns the number of units contained in a mode, i.e., 16537 'GET_MODE_SIZE' divided by 'GET_MODE_UNIT_SIZE'. 16538 16539'GET_CLASS_NARROWEST_MODE (C)' 16540 Returns the narrowest mode in mode class C. 16541 16542 The following 3 variables are defined on every target. They can be 16543used to allocate buffers that are guaranteed to be large enough to hold 16544any value that can be represented on the target. The first two can be 16545overridden by defining them in the target's mode.def file, however, the 16546value must be a constant that can determined very early in the 16547compilation process. The third symbol cannot be overridden. 16548 16549'BITS_PER_UNIT' 16550 The number of bits in an addressable storage unit (byte). If you 16551 do not define this, the default is 8. 16552 16553'MAX_BITSIZE_MODE_ANY_INT' 16554 The maximum bitsize of any mode that is used in integer math. This 16555 should be overridden by the target if it uses large integers as 16556 containers for larger vectors but otherwise never uses the contents 16557 to compute integer values. 16558 16559'MAX_BITSIZE_MODE_ANY_MODE' 16560 The bitsize of the largest mode on the target. The default value 16561 is the largest mode size given in the mode definition file, which 16562 is always correct for targets whose modes have a fixed size. 16563 Targets that might increase the size of a mode beyond this default 16564 should define 'MAX_BITSIZE_MODE_ANY_MODE' to the actual upper limit 16565 in 'MACHINE-modes.def'. 16566 16567 The global variables 'byte_mode' and 'word_mode' contain modes whose 16568classes are 'MODE_INT' and whose bitsizes are either 'BITS_PER_UNIT' or 16569'BITS_PER_WORD', respectively. On 32-bit machines, these are 'QImode' 16570and 'SImode', respectively. 16571 16572 16573File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL 16574 1657514.7 Constant Expression Types 16576============================== 16577 16578The simplest RTL expressions are those that represent constant values. 16579 16580'(const_int I)' 16581 This type of expression represents the integer value I. I is 16582 customarily accessed with the macro 'INTVAL' as in 'INTVAL (EXP)', 16583 which is equivalent to 'XWINT (EXP, 0)'. 16584 16585 Constants generated for modes with fewer bits than in 16586 'HOST_WIDE_INT' must be sign extended to full width (e.g., with 16587 'gen_int_mode'). For constants for modes with more bits than in 16588 'HOST_WIDE_INT' the implied high order bits of that constant are 16589 copies of the top bit. Note however that values are neither 16590 inherently signed nor inherently unsigned; where necessary, 16591 signedness is determined by the rtl operation instead. 16592 16593 There is only one expression object for the integer value zero; it 16594 is the value of the variable 'const0_rtx'. Likewise, the only 16595 expression for integer value one is found in 'const1_rtx', the only 16596 expression for integer value two is found in 'const2_rtx', and the 16597 only expression for integer value negative one is found in 16598 'constm1_rtx'. Any attempt to create an expression of code 16599 'const_int' and value zero, one, two or negative one will return 16600 'const0_rtx', 'const1_rtx', 'const2_rtx' or 'constm1_rtx' as 16601 appropriate. 16602 16603 Similarly, there is only one object for the integer whose value is 16604 'STORE_FLAG_VALUE'. It is found in 'const_true_rtx'. If 16605 'STORE_FLAG_VALUE' is one, 'const_true_rtx' and 'const1_rtx' will 16606 point to the same object. If 'STORE_FLAG_VALUE' is -1, 16607 'const_true_rtx' and 'constm1_rtx' will point to the same object. 16608 16609'(const_double:M I0 I1 ...)' 16610 This represents either a floating-point constant of mode M or (on 16611 older ports that do not define 'TARGET_SUPPORTS_WIDE_INT') an 16612 integer constant too large to fit into 'HOST_BITS_PER_WIDE_INT' 16613 bits but small enough to fit within twice that number of bits. In 16614 the latter case, M will be 'VOIDmode'. For integral values 16615 constants for modes with more bits than twice the number in 16616 'HOST_WIDE_INT' the implied high order bits of that constant are 16617 copies of the top bit of 'CONST_DOUBLE_HIGH'. Note however that 16618 integral values are neither inherently signed nor inherently 16619 unsigned; where necessary, signedness is determined by the rtl 16620 operation instead. 16621 16622 On more modern ports, 'CONST_DOUBLE' only represents floating point 16623 values. New ports define 'TARGET_SUPPORTS_WIDE_INT' to make this 16624 designation. 16625 16626 If M is 'VOIDmode', the bits of the value are stored in I0 and I1. 16627 I0 is customarily accessed with the macro 'CONST_DOUBLE_LOW' and I1 16628 with 'CONST_DOUBLE_HIGH'. 16629 16630 If the constant is floating point (regardless of its precision), 16631 then the number of integers used to store the value depends on the 16632 size of 'REAL_VALUE_TYPE' (*note Floating Point::). The integers 16633 represent a floating point number, but not precisely in the target 16634 machine's or host machine's floating point format. To convert them 16635 to the precise bit pattern used by the target machine, use the 16636 macro 'REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data 16637 Output::). 16638 16639'(const_wide_int:M NUNITS ELT0 ...)' 16640 This contains an array of 'HOST_WIDE_INT's that is large enough to 16641 hold any constant that can be represented on the target. This form 16642 of rtl is only used on targets that define 16643 'TARGET_SUPPORTS_WIDE_INT' to be nonzero and then 'CONST_DOUBLE's 16644 are only used to hold floating-point values. If the target leaves 16645 'TARGET_SUPPORTS_WIDE_INT' defined as 0, 'CONST_WIDE_INT's are not 16646 used and 'CONST_DOUBLE's are as they were before. 16647 16648 The values are stored in a compressed format. The higher-order 0s 16649 or -1s are not represented if they are just the logical sign 16650 extension of the number that is represented. 16651 16652'CONST_WIDE_INT_VEC (CODE)' 16653 Returns the entire array of 'HOST_WIDE_INT's that are used to store 16654 the value. This macro should be rarely used. 16655 16656'CONST_WIDE_INT_NUNITS (CODE)' 16657 The number of 'HOST_WIDE_INT's used to represent the number. Note 16658 that this generally is smaller than the number of 'HOST_WIDE_INT's 16659 implied by the mode size. 16660 16661'CONST_WIDE_INT_NUNITS (CODE,I)' 16662 Returns the 'i'th element of the array. Element 0 is contains the 16663 low order bits of the constant. 16664 16665'(const_fixed:M ...)' 16666 Represents a fixed-point constant of mode M. The operand is a data 16667 structure of type 'struct fixed_value' and is accessed with the 16668 macro 'CONST_FIXED_VALUE'. The high part of data is accessed with 16669 'CONST_FIXED_VALUE_HIGH'; the low part is accessed with 16670 'CONST_FIXED_VALUE_LOW'. 16671 16672'(const_poly_int:M [C0 C1 ...])' 16673 Represents a 'poly_int'-style polynomial integer with coefficients 16674 C0, C1, .... The coefficients are 'wide_int'-based integers rather 16675 than rtxes. 'CONST_POLY_INT_COEFFS' gives the values of individual 16676 coefficients (which is mostly only useful in low-level routines) 16677 and 'const_poly_int_value' gives the full 'poly_int' value. 16678 16679'(const_vector:M [X0 X1 ...])' 16680 Represents a vector constant. The values in square brackets are 16681 elements of the vector, which are always 'const_int', 16682 'const_wide_int', 'const_double' or 'const_fixed' expressions. 16683 16684 Each vector constant V is treated as a specific instance of an 16685 arbitrary-length sequence that itself contains 16686 'CONST_VECTOR_NPATTERNS (V)' interleaved patterns. Each pattern 16687 has the form: 16688 16689 { BASE0, BASE1, BASE1 + STEP, BASE1 + STEP * 2, ... } 16690 16691 The first three elements in each pattern are enough to determine 16692 the values of the other elements. However, if all STEPs are zero, 16693 only the first two elements are needed. If in addition each BASE1 16694 is equal to the corresponding BASE0, only the first element in each 16695 pattern is needed. The number of determining elements per pattern 16696 is given by 'CONST_VECTOR_NELTS_PER_PATTERN (V)'. 16697 16698 For example, the constant: 16699 16700 { 0, 1, 2, 6, 3, 8, 4, 10, 5, 12, 6, 14, 7, 16, 8, 18 } 16701 16702 is interpreted as an interleaving of the sequences: 16703 16704 { 0, 2, 3, 4, 5, 6, 7, 8 } 16705 { 1, 6, 8, 10, 12, 14, 16, 18 } 16706 16707 where the sequences are represented by the following patterns: 16708 16709 BASE0 == 0, BASE1 == 2, STEP == 1 16710 BASE0 == 1, BASE1 == 6, STEP == 2 16711 16712 In this case: 16713 16714 CONST_VECTOR_NPATTERNS (V) == 2 16715 CONST_VECTOR_NELTS_PER_PATTERN (V) == 3 16716 16717 Thus the first 6 elements ('{ 0, 1, 2, 6, 3, 8 }') are enough to 16718 determine the whole sequence; we refer to them as the "encoded" 16719 elements. They are the only elements present in the square 16720 brackets for variable-length 'const_vector's (i.e. for 16721 'const_vector's whose mode M has a variable number of elements). 16722 However, as a convenience to code that needs to handle both 16723 'const_vector's and 'parallel's, all elements are present in the 16724 square brackets for fixed-length 'const_vector's; the encoding 16725 scheme simply reduces the amount of work involved in processing 16726 constants that follow a regular pattern. 16727 16728 Sometimes this scheme can create two possible encodings of the same 16729 vector. For example { 0, 1 } could be seen as two patterns with 16730 one element each or one pattern with two elements (BASE0 and 16731 BASE1). The canonical encoding is always the one with the fewest 16732 patterns or (if both encodings have the same number of petterns) 16733 the one with the fewest encoded elements. 16734 16735 'const_vector_encoding_nelts (V)' gives the total number of encoded 16736 elements in V, which is 6 in the example above. 16737 'CONST_VECTOR_ENCODED_ELT (V, I)' accesses the value of encoded 16738 element I. 16739 16740 'CONST_VECTOR_DUPLICATE_P (V)' is true if V simply contains 16741 repeated instances of 'CONST_VECTOR_NPATTERNS (V)' values. This is 16742 a shorthand for testing 'CONST_VECTOR_NELTS_PER_PATTERN (V) == 1'. 16743 16744 'CONST_VECTOR_STEPPED_P (V)' is true if at least one pattern in V 16745 has a nonzero step. This is a shorthand for testing 16746 'CONST_VECTOR_NELTS_PER_PATTERN (V) == 3'. 16747 16748 'CONST_VECTOR_NUNITS (V)' gives the total number of elements in V; 16749 it is a shorthand for getting the number of units in 'GET_MODE 16750 (V)'. 16751 16752 The utility function 'const_vector_elt' gives the value of an 16753 arbitrary element as an 'rtx'. 'const_vector_int_elt' gives the 16754 same value as a 'wide_int'. 16755 16756'(const_string STR)' 16757 Represents a constant string with value STR. Currently this is 16758 used only for insn attributes (*note Insn Attributes::) since 16759 constant strings in C are placed in memory. 16760 16761'(symbol_ref:MODE SYMBOL)' 16762 Represents the value of an assembler label for data. SYMBOL is a 16763 string that describes the name of the assembler label. If it 16764 starts with a '*', the label is the rest of SYMBOL not including 16765 the '*'. Otherwise, the label is SYMBOL, usually prefixed with 16766 '_'. 16767 16768 The 'symbol_ref' contains a mode, which is usually 'Pmode'. 16769 Usually that is the only mode for which a symbol is directly valid. 16770 16771'(label_ref:MODE LABEL)' 16772 Represents the value of an assembler label for code. It contains 16773 one operand, an expression, which must be a 'code_label' or a 16774 'note' of type 'NOTE_INSN_DELETED_LABEL' that appears in the 16775 instruction sequence to identify the place where the label should 16776 go. 16777 16778 The reason for using a distinct expression type for code label 16779 references is so that jump optimization can distinguish them. 16780 16781 The 'label_ref' contains a mode, which is usually 'Pmode'. Usually 16782 that is the only mode for which a label is directly valid. 16783 16784'(const:M EXP)' 16785 Represents a constant that is the result of an assembly-time 16786 arithmetic computation. The operand, EXP, contains only 16787 'const_int', 'symbol_ref', 'label_ref' or 'unspec' expressions, 16788 combined with 'plus' and 'minus'. Any such 'unspec's are 16789 target-specific and typically represent some form of relocation 16790 operator. M should be a valid address mode. 16791 16792'(high:M EXP)' 16793 Represents the high-order bits of EXP, usually a 'symbol_ref'. The 16794 number of bits is machine-dependent and is normally the number of 16795 bits specified in an instruction that initializes the high order 16796 bits of a register. It is used with 'lo_sum' to represent the 16797 typical two-instruction sequence used in RISC machines to reference 16798 a global memory location. 16799 16800 M should be 'Pmode'. 16801 16802 The macro 'CONST0_RTX (MODE)' refers to an expression with value 0 in 16803mode MODE. If mode MODE is of mode class 'MODE_INT', it returns 16804'const0_rtx'. If mode MODE is of mode class 'MODE_FLOAT', it returns a 16805'CONST_DOUBLE' expression in mode MODE. Otherwise, it returns a 16806'CONST_VECTOR' expression in mode MODE. Similarly, the macro 16807'CONST1_RTX (MODE)' refers to an expression with value 1 in mode MODE 16808and similarly for 'CONST2_RTX'. The 'CONST1_RTX' and 'CONST2_RTX' 16809macros are undefined for vector modes. 16810 16811 16812File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL 16813 1681414.8 Registers and Memory 16815========================= 16816 16817Here are the RTL expression types for describing access to machine 16818registers and to main memory. 16819 16820'(reg:M N)' 16821 For small values of the integer N (those that are less than 16822 'FIRST_PSEUDO_REGISTER'), this stands for a reference to machine 16823 register number N: a "hard register". For larger values of N, it 16824 stands for a temporary value or "pseudo register". The compiler's 16825 strategy is to generate code assuming an unlimited number of such 16826 pseudo registers, and later convert them into hard registers or 16827 into memory references. 16828 16829 M is the machine mode of the reference. It is necessary because 16830 machines can generally refer to each register in more than one 16831 mode. For example, a register may contain a full word but there 16832 may be instructions to refer to it as a half word or as a single 16833 byte, as well as instructions to refer to it as a floating point 16834 number of various precisions. 16835 16836 Even for a register that the machine can access in only one mode, 16837 the mode must always be specified. 16838 16839 The symbol 'FIRST_PSEUDO_REGISTER' is defined by the machine 16840 description, since the number of hard registers on the machine is 16841 an invariant characteristic of the machine. Note, however, that 16842 not all of the machine registers must be general registers. All 16843 the machine registers that can be used for storage of data are 16844 given hard register numbers, even those that can be used only in 16845 certain instructions or can hold only certain types of data. 16846 16847 A hard register may be accessed in various modes throughout one 16848 function, but each pseudo register is given a natural mode and is 16849 accessed only in that mode. When it is necessary to describe an 16850 access to a pseudo register using a nonnatural mode, a 'subreg' 16851 expression is used. 16852 16853 A 'reg' expression with a machine mode that specifies more than one 16854 word of data may actually stand for several consecutive registers. 16855 If in addition the register number specifies a hardware register, 16856 then it actually represents several consecutive hardware registers 16857 starting with the specified one. 16858 16859 Each pseudo register number used in a function's RTL code is 16860 represented by a unique 'reg' expression. 16861 16862 Some pseudo register numbers, those within the range of 16863 'FIRST_VIRTUAL_REGISTER' to 'LAST_VIRTUAL_REGISTER' only appear 16864 during the RTL generation phase and are eliminated before the 16865 optimization phases. These represent locations in the stack frame 16866 that cannot be determined until RTL generation for the function has 16867 been completed. The following virtual register numbers are 16868 defined: 16869 16870 'VIRTUAL_INCOMING_ARGS_REGNUM' 16871 This points to the first word of the incoming arguments passed 16872 on the stack. Normally these arguments are placed there by 16873 the caller, but the callee may have pushed some arguments that 16874 were previously passed in registers. 16875 16876 When RTL generation is complete, this virtual register is 16877 replaced by the sum of the register given by 16878 'ARG_POINTER_REGNUM' and the value of 'FIRST_PARM_OFFSET'. 16879 16880 'VIRTUAL_STACK_VARS_REGNUM' 16881 If 'FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this 16882 points to immediately above the first variable on the stack. 16883 Otherwise, it points to the first variable on the stack. 16884 16885 'VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the 16886 register given by 'FRAME_POINTER_REGNUM' and the value 16887 'TARGET_STARTING_FRAME_OFFSET'. 16888 16889 'VIRTUAL_STACK_DYNAMIC_REGNUM' 16890 This points to the location of dynamically allocated memory on 16891 the stack immediately after the stack pointer has been 16892 adjusted by the amount of memory desired. 16893 16894 This virtual register is replaced by the sum of the register 16895 given by 'STACK_POINTER_REGNUM' and the value 16896 'STACK_DYNAMIC_OFFSET'. 16897 16898 'VIRTUAL_OUTGOING_ARGS_REGNUM' 16899 This points to the location in the stack at which outgoing 16900 arguments should be written when the stack is pre-pushed 16901 (arguments pushed using push insns should always use 16902 'STACK_POINTER_REGNUM'). 16903 16904 This virtual register is replaced by the sum of the register 16905 given by 'STACK_POINTER_REGNUM' and the value 16906 'STACK_POINTER_OFFSET'. 16907 16908'(subreg:M1 REG:M2 BYTENUM)' 16909 16910 'subreg' expressions are used to refer to a register in a machine 16911 mode other than its natural one, or to refer to one register of a 16912 multi-part 'reg' that actually refers to several registers. 16913 16914 Each pseudo register has a natural mode. If it is necessary to 16915 operate on it in a different mode, the register must be enclosed in 16916 a 'subreg'. 16917 16918 There are currently three supported types for the first operand of 16919 a 'subreg': 16920 * pseudo registers This is the most common case. Most 'subreg's 16921 have pseudo 'reg's as their first operand. 16922 16923 * mem 'subreg's of 'mem' were common in earlier versions of GCC 16924 and are still supported. During the reload pass these are 16925 replaced by plain 'mem's. On machines that do not do 16926 instruction scheduling, use of 'subreg's of 'mem' are still 16927 used, but this is no longer recommended. Such 'subreg's are 16928 considered to be 'register_operand's rather than 16929 'memory_operand's before and during reload. Because of this, 16930 the scheduling passes cannot properly schedule instructions 16931 with 'subreg's of 'mem', so for machines that do scheduling, 16932 'subreg's of 'mem' should never be used. To support this, the 16933 combine and recog passes have explicit code to inhibit the 16934 creation of 'subreg's of 'mem' when 'INSN_SCHEDULING' is 16935 defined. 16936 16937 The use of 'subreg's of 'mem' after the reload pass is an area 16938 that is not well understood and should be avoided. There is 16939 still some code in the compiler to support this, but this code 16940 has possibly rotted. This use of 'subreg's is discouraged and 16941 will most likely not be supported in the future. 16942 16943 * hard registers It is seldom necessary to wrap hard registers 16944 in 'subreg's; such registers would normally reduce to a single 16945 'reg' rtx. This use of 'subreg's is discouraged and may not 16946 be supported in the future. 16947 16948 'subreg's of 'subreg's are not supported. Using 16949 'simplify_gen_subreg' is the recommended way to avoid this problem. 16950 16951 'subreg's come in two distinct flavors, each having its own usage 16952 and rules: 16953 16954 Paradoxical subregs 16955 When M1 is strictly wider than M2, the 'subreg' expression is 16956 called "paradoxical". The canonical test for this class of 16957 'subreg' is: 16958 16959 paradoxical_subreg_p (M1, M2) 16960 16961 Paradoxical 'subreg's can be used as both lvalues and rvalues. 16962 When used as an lvalue, the low-order bits of the source value 16963 are stored in REG and the high-order bits are discarded. When 16964 used as an rvalue, the low-order bits of the 'subreg' are 16965 taken from REG while the high-order bits may or may not be 16966 defined. 16967 16968 The high-order bits of rvalues are defined in the following 16969 circumstances: 16970 16971 * 'subreg's of 'mem' When M2 is smaller than a word, the 16972 macro 'LOAD_EXTEND_OP', can control how the high-order 16973 bits are defined. 16974 16975 * 'subreg' of 'reg's The upper bits are defined when 16976 'SUBREG_PROMOTED_VAR_P' is true. 16977 'SUBREG_PROMOTED_UNSIGNED_P' describes what the upper 16978 bits hold. Such subregs usually represent local 16979 variables, register variables and parameter pseudo 16980 variables that have been promoted to a wider mode. 16981 16982 BYTENUM is always zero for a paradoxical 'subreg', even on 16983 big-endian targets. 16984 16985 For example, the paradoxical 'subreg': 16986 16987 (set (subreg:SI (reg:HI X) 0) Y) 16988 16989 stores the lower 2 bytes of Y in X and discards the upper 2 16990 bytes. A subsequent: 16991 16992 (set Z (subreg:SI (reg:HI X) 0)) 16993 16994 would set the lower two bytes of Z to Y and set the upper two 16995 bytes to an unknown value assuming 'SUBREG_PROMOTED_VAR_P' is 16996 false. 16997 16998 Normal subregs 16999 When M1 is at least as narrow as M2 the 'subreg' expression is 17000 called "normal". 17001 17002 Normal 'subreg's restrict consideration to certain bits of 17003 REG. For this purpose, REG is divided into 17004 individually-addressable blocks in which each block has: 17005 17006 REGMODE_NATURAL_SIZE (M2) 17007 17008 bytes. Usually the value is 'UNITS_PER_WORD'; that is, most 17009 targets usually treat each word of a register as being 17010 independently addressable. 17011 17012 There are two types of normal 'subreg'. If M1 is known to be 17013 no bigger than a block, the 'subreg' refers to the 17014 least-significant part (or "lowpart") of one block of REG. If 17015 M1 is known to be larger than a block, the 'subreg' refers to 17016 two or more complete blocks. 17017 17018 When used as an lvalue, 'subreg' is a block-based accessor. 17019 Storing to a 'subreg' modifies all the blocks of REG that 17020 overlap the 'subreg', but it leaves the other blocks of REG 17021 alone. 17022 17023 When storing to a normal 'subreg' that is smaller than a 17024 block, the other bits of the referenced block are usually left 17025 in an undefined state. This laxity makes it easier to 17026 generate efficient code for such instructions. To represent 17027 an instruction that preserves all the bits outside of those in 17028 the 'subreg', use 'strict_low_part' or 'zero_extract' around 17029 the 'subreg'. 17030 17031 BYTENUM must identify the offset of the first byte of the 17032 'subreg' from the start of REG, assuming that REG is laid out 17033 in memory order. The memory order of bytes is defined by two 17034 target macros, 'WORDS_BIG_ENDIAN' and 'BYTES_BIG_ENDIAN': 17035 17036 * 'WORDS_BIG_ENDIAN', if set to 1, says that byte number 17037 zero is part of the most significant word; otherwise, it 17038 is part of the least significant word. 17039 17040 * 'BYTES_BIG_ENDIAN', if set to 1, says that byte number 17041 zero is the most significant byte within a word; 17042 otherwise, it is the least significant byte within a 17043 word. 17044 17045 On a few targets, 'FLOAT_WORDS_BIG_ENDIAN' disagrees with 17046 'WORDS_BIG_ENDIAN'. However, most parts of the compiler treat 17047 floating point values as if they had the same endianness as 17048 integer values. This works because they handle them solely as 17049 a collection of integer values, with no particular numerical 17050 value. Only real.c and the runtime libraries care about 17051 'FLOAT_WORDS_BIG_ENDIAN'. 17052 17053 Thus, 17054 17055 (subreg:HI (reg:SI X) 2) 17056 17057 on a 'BYTES_BIG_ENDIAN', 'UNITS_PER_WORD == 4' target is the 17058 same as 17059 17060 (subreg:HI (reg:SI X) 0) 17061 17062 on a little-endian, 'UNITS_PER_WORD == 4' target. Both 17063 'subreg's access the lower two bytes of register X. 17064 17065 Note that the byte offset is a polynomial integer; it may not 17066 be a compile-time constant on targets with variable-sized 17067 modes. However, the restrictions above mean that there are 17068 only a certain set of acceptable offsets for a given 17069 combination of M1 and M2. The compiler can always tell which 17070 blocks a valid subreg occupies, and whether the subreg is a 17071 lowpart of a block. 17072 17073 A 'MODE_PARTIAL_INT' mode behaves as if it were as wide as the 17074 corresponding 'MODE_INT' mode, except that it has an unknown number 17075 of undefined bits. For example: 17076 17077 (subreg:PSI (reg:SI 0) 0) 17078 17079 accesses the whole of '(reg:SI 0)', but the exact relationship 17080 between the 'PSImode' value and the 'SImode' value is not defined. 17081 If we assume 'REGMODE_NATURAL_SIZE (DImode) <= 4', then the 17082 following two 'subreg's: 17083 17084 (subreg:PSI (reg:DI 0) 0) 17085 (subreg:PSI (reg:DI 0) 4) 17086 17087 represent independent 4-byte accesses to the two halves of '(reg:DI 17088 0)'. Both 'subreg's have an unknown number of undefined bits. 17089 17090 If 'REGMODE_NATURAL_SIZE (PSImode) <= 2' then these two 'subreg's: 17091 17092 (subreg:HI (reg:PSI 0) 0) 17093 (subreg:HI (reg:PSI 0) 2) 17094 17095 represent independent 2-byte accesses that together span the whole 17096 of '(reg:PSI 0)'. Storing to the first 'subreg' does not affect 17097 the value of the second, and vice versa. '(reg:PSI 0)' has an 17098 unknown number of undefined bits, so the assignment: 17099 17100 (set (subreg:HI (reg:PSI 0) 0) (reg:HI 4)) 17101 17102 does not guarantee that '(subreg:HI (reg:PSI 0) 0)' has the value 17103 '(reg:HI 4)'. 17104 17105 The rules above apply to both pseudo REGs and hard REGs. If the 17106 semantics are not correct for particular combinations of M1, M2 and 17107 hard REG, the target-specific code must ensure that those 17108 combinations are never used. For example: 17109 17110 TARGET_CAN_CHANGE_MODE_CLASS (M2, M1, CLASS) 17111 17112 must be false for every class CLASS that includes REG. 17113 17114 GCC must be able to determine at compile time whether a subreg is 17115 paradoxical, whether it occupies a whole number of blocks, or 17116 whether it is a lowpart of a block. This means that certain 17117 combinations of variable-sized mode are not permitted. For 17118 example, if M2 holds N 'SI' values, where N is greater than zero, 17119 it is not possible to form a 'DI' 'subreg' of it; such a 'subreg' 17120 would be paradoxical when N is 1 but not when N is greater than 1. 17121 17122 The first operand of a 'subreg' expression is customarily accessed 17123 with the 'SUBREG_REG' macro and the second operand is customarily 17124 accessed with the 'SUBREG_BYTE' macro. 17125 17126 It has been several years since a platform in which 17127 'BYTES_BIG_ENDIAN' not equal to 'WORDS_BIG_ENDIAN' has been tested. 17128 Anyone wishing to support such a platform in the future may be 17129 confronted with code rot. 17130 17131'(scratch:M)' 17132 This represents a scratch register that will be required for the 17133 execution of a single instruction and not used subsequently. It is 17134 converted into a 'reg' by either the local register allocator or 17135 the reload pass. 17136 17137 'scratch' is usually present inside a 'clobber' operation (*note 17138 Side Effects::). 17139 17140'(cc0)' 17141 This refers to the machine's condition code register. It has no 17142 operands and may not have a machine mode. There are two ways to 17143 use it: 17144 17145 * To stand for a complete set of condition code flags. This is 17146 best on most machines, where each comparison sets the entire 17147 series of flags. 17148 17149 With this technique, '(cc0)' may be validly used in only two 17150 contexts: as the destination of an assignment (in test and 17151 compare instructions) and in comparison operators comparing 17152 against zero ('const_int' with value zero; that is to say, 17153 'const0_rtx'). 17154 17155 * To stand for a single flag that is the result of a single 17156 condition. This is useful on machines that have only a single 17157 flag bit, and in which comparison instructions must specify 17158 the condition to test. 17159 17160 With this technique, '(cc0)' may be validly used in only two 17161 contexts: as the destination of an assignment (in test and 17162 compare instructions) where the source is a comparison 17163 operator, and as the first operand of 'if_then_else' (in a 17164 conditional branch). 17165 17166 There is only one expression object of code 'cc0'; it is the value 17167 of the variable 'cc0_rtx'. Any attempt to create an expression of 17168 code 'cc0' will return 'cc0_rtx'. 17169 17170 Instructions can set the condition code implicitly. On many 17171 machines, nearly all instructions set the condition code based on 17172 the value that they compute or store. It is not necessary to 17173 record these actions explicitly in the RTL because the machine 17174 description includes a prescription for recognizing the 17175 instructions that do so (by means of the macro 'NOTICE_UPDATE_CC'). 17176 *Note Condition Code::. Only instructions whose sole purpose is to 17177 set the condition code, and instructions that use the condition 17178 code, need mention '(cc0)'. 17179 17180 On some machines, the condition code register is given a register 17181 number and a 'reg' is used instead of '(cc0)'. This is usually the 17182 preferable approach if only a small subset of instructions modify 17183 the condition code. Other machines store condition codes in 17184 general registers; in such cases a pseudo register should be used. 17185 17186 Some machines, such as the SPARC and RS/6000, have two sets of 17187 arithmetic instructions, one that sets and one that does not set 17188 the condition code. This is best handled by normally generating 17189 the instruction that does not set the condition code, and making a 17190 pattern that both performs the arithmetic and sets the condition 17191 code register (which would not be '(cc0)' in this case). For 17192 examples, search for 'addcc' and 'andcc' in 'sparc.md'. 17193 17194'(pc)' 17195 This represents the machine's program counter. It has no operands 17196 and may not have a machine mode. '(pc)' may be validly used only 17197 in certain specific contexts in jump instructions. 17198 17199 There is only one expression object of code 'pc'; it is the value 17200 of the variable 'pc_rtx'. Any attempt to create an expression of 17201 code 'pc' will return 'pc_rtx'. 17202 17203 All instructions that do not jump alter the program counter 17204 implicitly by incrementing it, but there is no need to mention this 17205 in the RTL. 17206 17207'(mem:M ADDR ALIAS)' 17208 This RTX represents a reference to main memory at an address 17209 represented by the expression ADDR. M specifies how large a unit 17210 of memory is accessed. ALIAS specifies an alias set for the 17211 reference. In general two items are in different alias sets if 17212 they cannot reference the same memory address. 17213 17214 The construct '(mem:BLK (scratch))' is considered to alias all 17215 other memories. Thus it may be used as a memory barrier in 17216 epilogue stack deallocation patterns. 17217 17218'(concatM RTX RTX)' 17219 This RTX represents the concatenation of two other RTXs. This is 17220 used for complex values. It should only appear in the RTL attached 17221 to declarations and during RTL generation. It should not appear in 17222 the ordinary insn chain. 17223 17224'(concatnM [RTX ...])' 17225 This RTX represents the concatenation of all the RTX to make a 17226 single value. Like 'concat', this should only appear in 17227 declarations, and not in the insn chain. 17228 17229 17230File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL 17231 1723214.9 RTL Expressions for Arithmetic 17233=================================== 17234 17235Unless otherwise specified, all the operands of arithmetic expressions 17236must be valid for mode M. An operand is valid for mode M if it has mode 17237M, or if it is a 'const_int' or 'const_double' and M is a mode of class 17238'MODE_INT'. 17239 17240 For commutative binary operations, constants should be placed in the 17241second operand. 17242 17243'(plus:M X Y)' 17244'(ss_plus:M X Y)' 17245'(us_plus:M X Y)' 17246 17247 These three expressions all represent the sum of the values 17248 represented by X and Y carried out in machine mode M. They differ 17249 in their behavior on overflow of integer modes. 'plus' wraps round 17250 modulo the width of M; 'ss_plus' saturates at the maximum signed 17251 value representable in M; 'us_plus' saturates at the maximum 17252 unsigned value. 17253 17254'(lo_sum:M X Y)' 17255 17256 This expression represents the sum of X and the low-order bits of 17257 Y. It is used with 'high' (*note Constants::) to represent the 17258 typical two-instruction sequence used in RISC machines to reference 17259 a global memory location. 17260 17261 The number of low order bits is machine-dependent but is normally 17262 the number of bits in a 'Pmode' item minus the number of bits set 17263 by 'high'. 17264 17265 M should be 'Pmode'. 17266 17267'(minus:M X Y)' 17268'(ss_minus:M X Y)' 17269'(us_minus:M X Y)' 17270 17271 These three expressions represent the result of subtracting Y from 17272 X, carried out in mode M. Behavior on overflow is the same as for 17273 the three variants of 'plus' (see above). 17274 17275'(compare:M X Y)' 17276 Represents the result of subtracting Y from X for purposes of 17277 comparison. The result is computed without overflow, as if with 17278 infinite precision. 17279 17280 Of course, machines cannot really subtract with infinite precision. 17281 However, they can pretend to do so when only the sign of the result 17282 will be used, which is the case when the result is stored in the 17283 condition code. And that is the _only_ way this kind of expression 17284 may validly be used: as a value to be stored in the condition 17285 codes, either '(cc0)' or a register. *Note Comparisons::. 17286 17287 The mode M is not related to the modes of X and Y, but instead is 17288 the mode of the condition code value. If '(cc0)' is used, it is 17289 'VOIDmode'. Otherwise it is some mode in class 'MODE_CC', often 17290 'CCmode'. *Note Condition Code::. If M is 'VOIDmode' or 'CCmode', 17291 the operation returns sufficient information (in an unspecified 17292 format) so that any comparison operator can be applied to the 17293 result of the 'COMPARE' operation. For other modes in class 17294 'MODE_CC', the operation only returns a subset of this information. 17295 17296 Normally, X and Y must have the same mode. Otherwise, 'compare' is 17297 valid only if the mode of X is in class 'MODE_INT' and Y is a 17298 'const_int' or 'const_double' with mode 'VOIDmode'. The mode of X 17299 determines what mode the comparison is to be done in; thus it must 17300 not be 'VOIDmode'. 17301 17302 If one of the operands is a constant, it should be placed in the 17303 second operand and the comparison code adjusted as appropriate. 17304 17305 A 'compare' specifying two 'VOIDmode' constants is not valid since 17306 there is no way to know in what mode the comparison is to be 17307 performed; the comparison must either be folded during the 17308 compilation or the first operand must be loaded into a register 17309 while its mode is still known. 17310 17311'(neg:M X)' 17312'(ss_neg:M X)' 17313'(us_neg:M X)' 17314 These two expressions represent the negation (subtraction from 17315 zero) of the value represented by X, carried out in mode M. They 17316 differ in the behavior on overflow of integer modes. In the case 17317 of 'neg', the negation of the operand may be a number not 17318 representable in mode M, in which case it is truncated to M. 17319 'ss_neg' and 'us_neg' ensure that an out-of-bounds result saturates 17320 to the maximum or minimum signed or unsigned value. 17321 17322'(mult:M X Y)' 17323'(ss_mult:M X Y)' 17324'(us_mult:M X Y)' 17325 Represents the signed product of the values represented by X and Y 17326 carried out in machine mode M. 'ss_mult' and 'us_mult' ensure that 17327 an out-of-bounds result saturates to the maximum or minimum signed 17328 or unsigned value. 17329 17330 Some machines support a multiplication that generates a product 17331 wider than the operands. Write the pattern for this as 17332 17333 (mult:M (sign_extend:M X) (sign_extend:M Y)) 17334 17335 where M is wider than the modes of X and Y, which need not be the 17336 same. 17337 17338 For unsigned widening multiplication, use the same idiom, but with 17339 'zero_extend' instead of 'sign_extend'. 17340 17341'(fma:M X Y Z)' 17342 Represents the 'fma', 'fmaf', and 'fmal' builtin functions, which 17343 compute 'X * Y + Z' without doing an intermediate rounding step. 17344 17345'(div:M X Y)' 17346'(ss_div:M X Y)' 17347 Represents the quotient in signed division of X by Y, carried out 17348 in machine mode M. If M is a floating point mode, it represents 17349 the exact quotient; otherwise, the integerized quotient. 'ss_div' 17350 ensures that an out-of-bounds result saturates to the maximum or 17351 minimum signed value. 17352 17353 Some machines have division instructions in which the operands and 17354 quotient widths are not all the same; you should represent such 17355 instructions using 'truncate' and 'sign_extend' as in, 17356 17357 (truncate:M1 (div:M2 X (sign_extend:M2 Y))) 17358 17359'(udiv:M X Y)' 17360'(us_div:M X Y)' 17361 Like 'div' but represents unsigned division. 'us_div' ensures that 17362 an out-of-bounds result saturates to the maximum or minimum 17363 unsigned value. 17364 17365'(mod:M X Y)' 17366'(umod:M X Y)' 17367 Like 'div' and 'udiv' but represent the remainder instead of the 17368 quotient. 17369 17370'(smin:M X Y)' 17371'(smax:M X Y)' 17372 Represents the smaller (for 'smin') or larger (for 'smax') of X and 17373 Y, interpreted as signed values in mode M. When used with floating 17374 point, if both operands are zeros, or if either operand is 'NaN', 17375 then it is unspecified which of the two operands is returned as the 17376 result. 17377 17378'(umin:M X Y)' 17379'(umax:M X Y)' 17380 Like 'smin' and 'smax', but the values are interpreted as unsigned 17381 integers. 17382 17383'(not:M X)' 17384 Represents the bitwise complement of the value represented by X, 17385 carried out in mode M, which must be a fixed-point machine mode. 17386 17387'(and:M X Y)' 17388 Represents the bitwise logical-and of the values represented by X 17389 and Y, carried out in machine mode M, which must be a fixed-point 17390 machine mode. 17391 17392'(ior:M X Y)' 17393 Represents the bitwise inclusive-or of the values represented by X 17394 and Y, carried out in machine mode M, which must be a fixed-point 17395 mode. 17396 17397'(xor:M X Y)' 17398 Represents the bitwise exclusive-or of the values represented by X 17399 and Y, carried out in machine mode M, which must be a fixed-point 17400 mode. 17401 17402'(ashift:M X C)' 17403'(ss_ashift:M X C)' 17404'(us_ashift:M X C)' 17405 These three expressions represent the result of arithmetically 17406 shifting X left by C places. They differ in their behavior on 17407 overflow of integer modes. An 'ashift' operation is a plain shift 17408 with no special behavior in case of a change in the sign bit; 17409 'ss_ashift' and 'us_ashift' saturates to the minimum or maximum 17410 representable value if any of the bits shifted out differs from the 17411 final sign bit. 17412 17413 X have mode M, a fixed-point machine mode. C be a fixed-point mode 17414 or be a constant with mode 'VOIDmode'; which mode is determined by 17415 the mode called for in the machine description entry for the 17416 left-shift instruction. For example, on the VAX, the mode of C is 17417 'QImode' regardless of M. 17418 17419'(lshiftrt:M X C)' 17420'(ashiftrt:M X C)' 17421 Like 'ashift' but for right shift. Unlike the case for left shift, 17422 these two operations are distinct. 17423 17424'(rotate:M X C)' 17425'(rotatert:M X C)' 17426 Similar but represent left and right rotate. If C is a constant, 17427 use 'rotate'. 17428 17429'(abs:M X)' 17430'(ss_abs:M X)' 17431 Represents the absolute value of X, computed in mode M. 'ss_abs' 17432 ensures that an out-of-bounds result saturates to the maximum 17433 signed value. 17434 17435'(sqrt:M X)' 17436 Represents the square root of X, computed in mode M. Most often M 17437 will be a floating point mode. 17438 17439'(ffs:M X)' 17440 Represents one plus the index of the least significant 1-bit in X, 17441 represented as an integer of mode M. (The value is zero if X is 17442 zero.) The mode of X must be M or 'VOIDmode'. 17443 17444'(clrsb:M X)' 17445 Represents the number of redundant leading sign bits in X, 17446 represented as an integer of mode M, starting at the most 17447 significant bit position. This is one less than the number of 17448 leading sign bits (either 0 or 1), with no special cases. The mode 17449 of X must be M or 'VOIDmode'. 17450 17451'(clz:M X)' 17452 Represents the number of leading 0-bits in X, represented as an 17453 integer of mode M, starting at the most significant bit position. 17454 If X is zero, the value is determined by 17455 'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Note that this is one 17456 of the few expressions that is not invariant under widening. The 17457 mode of X must be M or 'VOIDmode'. 17458 17459'(ctz:M X)' 17460 Represents the number of trailing 0-bits in X, represented as an 17461 integer of mode M, starting at the least significant bit position. 17462 If X is zero, the value is determined by 17463 'CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Except for this case, 17464 'ctz(x)' is equivalent to 'ffs(X) - 1'. The mode of X must be M or 17465 'VOIDmode'. 17466 17467'(popcount:M X)' 17468 Represents the number of 1-bits in X, represented as an integer of 17469 mode M. The mode of X must be M or 'VOIDmode'. 17470 17471'(parity:M X)' 17472 Represents the number of 1-bits modulo 2 in X, represented as an 17473 integer of mode M. The mode of X must be M or 'VOIDmode'. 17474 17475'(bswap:M X)' 17476 Represents the value X with the order of bytes reversed, carried 17477 out in mode M, which must be a fixed-point machine mode. The mode 17478 of X must be M or 'VOIDmode'. 17479 17480 17481File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL 17482 1748314.10 Comparison Operations 17484=========================== 17485 17486Comparison operators test a relation on two operands and are considered 17487to represent a machine-dependent nonzero value described by, but not 17488necessarily equal to, 'STORE_FLAG_VALUE' (*note Misc::) if the relation 17489holds, or zero if it does not, for comparison operators whose results 17490have a 'MODE_INT' mode, 'FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the 17491relation holds, or zero if it does not, for comparison operators that 17492return floating-point values, and a vector of either 17493'VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of 17494zeros if it does not, for comparison operators that return vector 17495results. The mode of the comparison operation is independent of the 17496mode of the data being compared. If the comparison operation is being 17497tested (e.g., the first operand of an 'if_then_else'), the mode must be 17498'VOIDmode'. 17499 17500 There are two ways that comparison operations may be used. The 17501comparison operators may be used to compare the condition codes '(cc0)' 17502against zero, as in '(eq (cc0) (const_int 0))'. Such a construct 17503actually refers to the result of the preceding instruction in which the 17504condition codes were set. The instruction setting the condition code 17505must be adjacent to the instruction using the condition code; only 17506'note' insns may separate them. 17507 17508 Alternatively, a comparison operation may directly compare two data 17509objects. The mode of the comparison is determined by the operands; they 17510must both be valid for a common machine mode. A comparison with both 17511operands constant would be invalid as the machine mode could not be 17512deduced from it, but such a comparison should never exist in RTL due to 17513constant folding. 17514 17515 In the example above, if '(cc0)' were last set to '(compare X Y)', the 17516comparison operation is identical to '(eq X Y)'. Usually only one style 17517of comparisons is supported on a particular machine, but the combine 17518pass will try to merge the operations to produce the 'eq' shown in case 17519it exists in the context of the particular insn involved. 17520 17521 Inequality comparisons come in two flavors, signed and unsigned. Thus, 17522there are distinct expression codes 'gt' and 'gtu' for signed and 17523unsigned greater-than. These can produce different results for the same 17524pair of integer values: for example, 1 is signed greater-than -1 but not 17525unsigned greater-than, because -1 when regarded as unsigned is actually 17526'0xffffffff' which is greater than 1. 17527 17528 The signed comparisons are also used for floating point values. 17529Floating point comparisons are distinguished by the machine modes of the 17530operands. 17531 17532'(eq:M X Y)' 17533 'STORE_FLAG_VALUE' if the values represented by X and Y are equal, 17534 otherwise 0. 17535 17536'(ne:M X Y)' 17537 'STORE_FLAG_VALUE' if the values represented by X and Y are not 17538 equal, otherwise 0. 17539 17540'(gt:M X Y)' 17541 'STORE_FLAG_VALUE' if the X is greater than Y. If they are 17542 fixed-point, the comparison is done in a signed sense. 17543 17544'(gtu:M X Y)' 17545 Like 'gt' but does unsigned comparison, on fixed-point numbers 17546 only. 17547 17548'(lt:M X Y)' 17549'(ltu:M X Y)' 17550 Like 'gt' and 'gtu' but test for "less than". 17551 17552'(ge:M X Y)' 17553'(geu:M X Y)' 17554 Like 'gt' and 'gtu' but test for "greater than or equal". 17555 17556'(le:M X Y)' 17557'(leu:M X Y)' 17558 Like 'gt' and 'gtu' but test for "less than or equal". 17559 17560'(if_then_else COND THEN ELSE)' 17561 This is not a comparison operation but is listed here because it is 17562 always used in conjunction with a comparison operation. To be 17563 precise, COND is a comparison expression. This expression 17564 represents a choice, according to COND, between the value 17565 represented by THEN and the one represented by ELSE. 17566 17567 On most machines, 'if_then_else' expressions are valid only to 17568 express conditional jumps. 17569 17570'(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' 17571 Similar to 'if_then_else', but more general. Each of TEST1, TEST2, 17572 ... is performed in turn. The result of this expression is the 17573 VALUE corresponding to the first nonzero test, or DEFAULT if none 17574 of the tests are nonzero expressions. 17575 17576 This is currently not valid for instruction patterns and is 17577 supported only for insn attributes. *Note Insn Attributes::. 17578 17579 17580File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL 17581 1758214.11 Bit-Fields 17583================ 17584 17585Special expression codes exist to represent bit-field instructions. 17586 17587'(sign_extract:M LOC SIZE POS)' 17588 This represents a reference to a sign-extended bit-field contained 17589 or starting in LOC (a memory or register reference). The bit-field 17590 is SIZE bits wide and starts at bit POS. The compilation option 17591 'BITS_BIG_ENDIAN' says which end of the memory unit POS counts 17592 from. 17593 17594 If LOC is in memory, its mode must be a single-byte integer mode. 17595 If LOC is in a register, the mode to use is specified by the 17596 operand of the 'insv' or 'extv' pattern (*note Standard Names::) 17597 and is usually a full-word integer mode, which is the default if 17598 none is specified. 17599 17600 The mode of POS is machine-specific and is also specified in the 17601 'insv' or 'extv' pattern. 17602 17603 The mode M is the same as the mode that would be used for LOC if it 17604 were a register. 17605 17606 A 'sign_extract' can not appear as an lvalue, or part thereof, in 17607 RTL. 17608 17609'(zero_extract:M LOC SIZE POS)' 17610 Like 'sign_extract' but refers to an unsigned or zero-extended 17611 bit-field. The same sequence of bits are extracted, but they are 17612 filled to an entire word with zeros instead of by sign-extension. 17613 17614 Unlike 'sign_extract', this type of expressions can be lvalues in 17615 RTL; they may appear on the left side of an assignment, indicating 17616 insertion of a value into the specified bit-field. 17617 17618 17619File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL 17620 1762114.12 Vector Operations 17622======================= 17623 17624All normal RTL expressions can be used with vector modes; they are 17625interpreted as operating on each part of the vector independently. 17626Additionally, there are a few new expressions to describe specific 17627vector operations. 17628 17629'(vec_merge:M VEC1 VEC2 ITEMS)' 17630 This describes a merge operation between two vectors. The result 17631 is a vector of mode M; its elements are selected from either VEC1 17632 or VEC2. Which elements are selected is described by ITEMS, which 17633 is a bit mask represented by a 'const_int'; a zero bit indicates 17634 the corresponding element in the result vector is taken from VEC2 17635 while a set bit indicates it is taken from VEC1. 17636 17637'(vec_select:M VEC1 SELECTION)' 17638 This describes an operation that selects parts of a vector. VEC1 17639 is the source vector, and SELECTION is a 'parallel' that contains a 17640 'const_int' for each of the subparts of the result vector, giving 17641 the number of the source subpart that should be stored into it. 17642 The result mode M is either the submode for a single element of 17643 VEC1 (if only one subpart is selected), or another vector mode with 17644 that element submode (if multiple subparts are selected). 17645 17646'(vec_concat:M X1 X2)' 17647 Describes a vector concat operation. The result is a concatenation 17648 of the vectors or scalars X1 and X2; its length is the sum of the 17649 lengths of the two inputs. 17650 17651'(vec_duplicate:M X)' 17652 This operation converts a scalar into a vector or a small vector 17653 into a larger one by duplicating the input values. The output 17654 vector mode must have the same submodes as the input vector mode or 17655 the scalar modes, and the number of output parts must be an integer 17656 multiple of the number of input parts. 17657 17658'(vec_series:M BASE STEP)' 17659 This operation creates a vector in which element I is equal to 17660 'BASE + I*STEP'. M must be a vector integer mode. 17661 17662 17663File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL 17664 1766514.13 Conversions 17666================= 17667 17668All conversions between machine modes must be represented by explicit 17669conversion operations. For example, an expression which is the sum of a 17670byte and a full word cannot be written as '(plus:SI (reg:QI 34) (reg:SI 1767180))' because the 'plus' operation requires two operands of the same 17672machine mode. Therefore, the byte-sized operand is enclosed in a 17673conversion operation, as in 17674 17675 (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) 17676 17677 The conversion operation is not a mere placeholder, because there may 17678be more than one way of converting from a given starting mode to the 17679desired final mode. The conversion operation code says how to do it. 17680 17681 For all conversion operations, X must not be 'VOIDmode' because the 17682mode in which to do the conversion would not be known. The conversion 17683must either be done at compile-time or X must be placed into a register. 17684 17685'(sign_extend:M X)' 17686 Represents the result of sign-extending the value X to machine mode 17687 M. M must be a fixed-point mode and X a fixed-point value of a 17688 mode narrower than M. 17689 17690'(zero_extend:M X)' 17691 Represents the result of zero-extending the value X to machine mode 17692 M. M must be a fixed-point mode and X a fixed-point value of a 17693 mode narrower than M. 17694 17695'(float_extend:M X)' 17696 Represents the result of extending the value X to machine mode M. 17697 M must be a floating point mode and X a floating point value of a 17698 mode narrower than M. 17699 17700'(truncate:M X)' 17701 Represents the result of truncating the value X to machine mode M. 17702 M must be a fixed-point mode and X a fixed-point value of a mode 17703 wider than M. 17704 17705'(ss_truncate:M X)' 17706 Represents the result of truncating the value X to machine mode M, 17707 using signed saturation in the case of overflow. Both M and the 17708 mode of X must be fixed-point modes. 17709 17710'(us_truncate:M X)' 17711 Represents the result of truncating the value X to machine mode M, 17712 using unsigned saturation in the case of overflow. Both M and the 17713 mode of X must be fixed-point modes. 17714 17715'(float_truncate:M X)' 17716 Represents the result of truncating the value X to machine mode M. 17717 M must be a floating point mode and X a floating point value of a 17718 mode wider than M. 17719 17720'(float:M X)' 17721 Represents the result of converting fixed point value X, regarded 17722 as signed, to floating point mode M. 17723 17724'(unsigned_float:M X)' 17725 Represents the result of converting fixed point value X, regarded 17726 as unsigned, to floating point mode M. 17727 17728'(fix:M X)' 17729 When M is a floating-point mode, represents the result of 17730 converting floating point value X (valid for mode M) to an integer, 17731 still represented in floating point mode M, by rounding towards 17732 zero. 17733 17734 When M is a fixed-point mode, represents the result of converting 17735 floating point value X to mode M, regarded as signed. How rounding 17736 is done is not specified, so this operation may be used validly in 17737 compiling C code only for integer-valued operands. 17738 17739'(unsigned_fix:M X)' 17740 Represents the result of converting floating point value X to fixed 17741 point mode M, regarded as unsigned. How rounding is done is not 17742 specified. 17743 17744'(fract_convert:M X)' 17745 Represents the result of converting fixed-point value X to 17746 fixed-point mode M, signed integer value X to fixed-point mode M, 17747 floating-point value X to fixed-point mode M, fixed-point value X 17748 to integer mode M regarded as signed, or fixed-point value X to 17749 floating-point mode M. When overflows or underflows happen, the 17750 results are undefined. 17751 17752'(sat_fract:M X)' 17753 Represents the result of converting fixed-point value X to 17754 fixed-point mode M, signed integer value X to fixed-point mode M, 17755 or floating-point value X to fixed-point mode M. When overflows or 17756 underflows happen, the results are saturated to the maximum or the 17757 minimum. 17758 17759'(unsigned_fract_convert:M X)' 17760 Represents the result of converting fixed-point value X to integer 17761 mode M regarded as unsigned, or unsigned integer value X to 17762 fixed-point mode M. When overflows or underflows happen, the 17763 results are undefined. 17764 17765'(unsigned_sat_fract:M X)' 17766 Represents the result of converting unsigned integer value X to 17767 fixed-point mode M. When overflows or underflows happen, the 17768 results are saturated to the maximum or the minimum. 17769 17770 17771File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL 17772 1777314.14 Declarations 17774================== 17775 17776Declaration expression codes do not represent arithmetic operations but 17777rather state assertions about their operands. 17778 17779'(strict_low_part (subreg:M (reg:N R) 0))' 17780 This expression code is used in only one context: as the 17781 destination operand of a 'set' expression. In addition, the 17782 operand of this expression must be a non-paradoxical 'subreg' 17783 expression. 17784 17785 The presence of 'strict_low_part' says that the part of the 17786 register which is meaningful in mode N, but is not part of mode M, 17787 is not to be altered. Normally, an assignment to such a subreg is 17788 allowed to have undefined effects on the rest of the register when 17789 M is smaller than 'REGMODE_NATURAL_SIZE (N)'. 17790 17791 17792File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL 17793 1779414.15 Side Effect Expressions 17795============================= 17796 17797The expression codes described so far represent values, not actions. 17798But machine instructions never produce values; they are meaningful only 17799for their side effects on the state of the machine. Special expression 17800codes are used to represent side effects. 17801 17802 The body of an instruction is always one of these side effect codes; 17803the codes described above, which represent values, appear only as the 17804operands of these. 17805 17806'(set LVAL X)' 17807 Represents the action of storing the value of X into the place 17808 represented by LVAL. LVAL must be an expression representing a 17809 place that can be stored in: 'reg' (or 'subreg', 'strict_low_part' 17810 or 'zero_extract'), 'mem', 'pc', 'parallel', or 'cc0'. 17811 17812 If LVAL is a 'reg', 'subreg' or 'mem', it has a machine mode; then 17813 X must be valid for that mode. 17814 17815 If LVAL is a 'reg' whose machine mode is less than the full width 17816 of the register, then it means that the part of the register 17817 specified by the machine mode is given the specified value and the 17818 rest of the register receives an undefined value. Likewise, if 17819 LVAL is a 'subreg' whose machine mode is narrower than the mode of 17820 the register, the rest of the register can be changed in an 17821 undefined way. 17822 17823 If LVAL is a 'strict_low_part' of a subreg, then the part of the 17824 register specified by the machine mode of the 'subreg' is given the 17825 value X and the rest of the register is not changed. 17826 17827 If LVAL is a 'zero_extract', then the referenced part of the 17828 bit-field (a memory or register reference) specified by the 17829 'zero_extract' is given the value X and the rest of the bit-field 17830 is not changed. Note that 'sign_extract' can not appear in LVAL. 17831 17832 If LVAL is '(cc0)', it has no machine mode, and X may be either a 17833 'compare' expression or a value that may have any mode. The latter 17834 case represents a "test" instruction. The expression '(set (cc0) 17835 (reg:M N))' is equivalent to '(set (cc0) (compare (reg:M N) 17836 (const_int 0)))'. Use the former expression to save space during 17837 the compilation. 17838 17839 If LVAL is a 'parallel', it is used to represent the case of a 17840 function returning a structure in multiple registers. Each element 17841 of the 'parallel' is an 'expr_list' whose first operand is a 'reg' 17842 and whose second operand is a 'const_int' representing the offset 17843 (in bytes) into the structure at which the data in that register 17844 corresponds. The first element may be null to indicate that the 17845 structure is also passed partly in memory. 17846 17847 If LVAL is '(pc)', we have a jump instruction, and the 17848 possibilities for X are very limited. It may be a 'label_ref' 17849 expression (unconditional jump). It may be an 'if_then_else' 17850 (conditional jump), in which case either the second or the third 17851 operand must be '(pc)' (for the case which does not jump) and the 17852 other of the two must be a 'label_ref' (for the case which does 17853 jump). X may also be a 'mem' or '(plus:SI (pc) Y)', where Y may be 17854 a 'reg' or a 'mem'; these unusual patterns are used to represent 17855 jumps through branch tables. 17856 17857 If LVAL is neither '(cc0)' nor '(pc)', the mode of LVAL must not be 17858 'VOIDmode' and the mode of X must be valid for the mode of LVAL. 17859 17860 LVAL is customarily accessed with the 'SET_DEST' macro and X with 17861 the 'SET_SRC' macro. 17862 17863'(return)' 17864 As the sole expression in a pattern, represents a return from the 17865 current function, on machines where this can be done with one 17866 instruction, such as VAXen. On machines where a multi-instruction 17867 "epilogue" must be executed in order to return from the function, 17868 returning is done by jumping to a label which precedes the 17869 epilogue, and the 'return' expression code is never used. 17870 17871 Inside an 'if_then_else' expression, represents the value to be 17872 placed in 'pc' to return to the caller. 17873 17874 Note that an insn pattern of '(return)' is logically equivalent to 17875 '(set (pc) (return))', but the latter form is never used. 17876 17877'(simple_return)' 17878 Like '(return)', but truly represents only a function return, while 17879 '(return)' may represent an insn that also performs other functions 17880 of the function epilogue. Like '(return)', this may also occur in 17881 conditional jumps. 17882 17883'(call FUNCTION NARGS)' 17884 Represents a function call. FUNCTION is a 'mem' expression whose 17885 address is the address of the function to be called. NARGS is an 17886 expression which can be used for two purposes: on some machines it 17887 represents the number of bytes of stack argument; on others, it 17888 represents the number of argument registers. 17889 17890 Each machine has a standard machine mode which FUNCTION must have. 17891 The machine description defines macro 'FUNCTION_MODE' to expand 17892 into the requisite mode name. The purpose of this mode is to 17893 specify what kind of addressing is allowed, on machines where the 17894 allowed kinds of addressing depend on the machine mode being 17895 addressed. 17896 17897'(clobber X)' 17898 Represents the storing or possible storing of an unpredictable, 17899 undescribed value into X, which must be a 'reg', 'scratch', 17900 'parallel' or 'mem' expression. 17901 17902 One place this is used is in string instructions that store 17903 standard values into particular hard registers. It may not be 17904 worth the trouble to describe the values that are stored, but it is 17905 essential to inform the compiler that the registers will be 17906 altered, lest it attempt to keep data in them across the string 17907 instruction. 17908 17909 If X is '(mem:BLK (const_int 0))' or '(mem:BLK (scratch))', it 17910 means that all memory locations must be presumed clobbered. If X 17911 is a 'parallel', it has the same meaning as a 'parallel' in a 'set' 17912 expression. 17913 17914 Note that the machine description classifies certain hard registers 17915 as "call-clobbered". All function call instructions are assumed by 17916 default to clobber these registers, so there is no need to use 17917 'clobber' expressions to indicate this fact. Also, each function 17918 call is assumed to have the potential to alter any memory location, 17919 unless the function is declared 'const'. 17920 17921 If the last group of expressions in a 'parallel' are each a 17922 'clobber' expression whose arguments are 'reg' or 'match_scratch' 17923 (*note RTL Template::) expressions, the combiner phase can add the 17924 appropriate 'clobber' expressions to an insn it has constructed 17925 when doing so will cause a pattern to be matched. 17926 17927 This feature can be used, for example, on a machine that whose 17928 multiply and add instructions don't use an MQ register but which 17929 has an add-accumulate instruction that does clobber the MQ 17930 register. Similarly, a combined instruction might require a 17931 temporary register while the constituent instructions might not. 17932 17933 When a 'clobber' expression for a register appears inside a 17934 'parallel' with other side effects, the register allocator 17935 guarantees that the register is unoccupied both before and after 17936 that insn if it is a hard register clobber. For pseudo-register 17937 clobber, the register allocator and the reload pass do not assign 17938 the same hard register to the clobber and the input operands if 17939 there is an insn alternative containing the '&' constraint (*note 17940 Modifiers::) for the clobber and the hard register is in register 17941 classes of the clobber in the alternative. You can clobber either 17942 a specific hard register, a pseudo register, or a 'scratch' 17943 expression; in the latter two cases, GCC will allocate a hard 17944 register that is available there for use as a temporary. 17945 17946 For instructions that require a temporary register, you should use 17947 'scratch' instead of a pseudo-register because this will allow the 17948 combiner phase to add the 'clobber' when required. You do this by 17949 coding ('clobber' ('match_scratch' ...)). If you do clobber a 17950 pseudo register, use one which appears nowhere else--generate a new 17951 one each time. Otherwise, you may confuse CSE. 17952 17953 There is one other known use for clobbering a pseudo register in a 17954 'parallel': when one of the input operands of the insn is also 17955 clobbered by the insn. In this case, using the same pseudo 17956 register in the clobber and elsewhere in the insn produces the 17957 expected results. 17958 17959'(use X)' 17960 Represents the use of the value of X. It indicates that the value 17961 in X at this point in the program is needed, even though it may not 17962 be apparent why this is so. Therefore, the compiler will not 17963 attempt to delete previous instructions whose only effect is to 17964 store a value in X. X must be a 'reg' expression. 17965 17966 In some situations, it may be tempting to add a 'use' of a register 17967 in a 'parallel' to describe a situation where the value of a 17968 special register will modify the behavior of the instruction. A 17969 hypothetical example might be a pattern for an addition that can 17970 either wrap around or use saturating addition depending on the 17971 value of a special control register: 17972 17973 (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3) 17974 (reg:SI 4)] 0)) 17975 (use (reg:SI 1))]) 17976 17977 17978 This will not work, several of the optimizers only look at 17979 expressions locally; it is very likely that if you have multiple 17980 insns with identical inputs to the 'unspec', they will be optimized 17981 away even if register 1 changes in between. 17982 17983 This means that 'use' can _only_ be used to describe that the 17984 register is live. You should think twice before adding 'use' 17985 statements, more often you will want to use 'unspec' instead. The 17986 'use' RTX is most commonly useful to describe that a fixed register 17987 is implicitly used in an insn. It is also safe to use in patterns 17988 where the compiler knows for other reasons that the result of the 17989 whole pattern is variable, such as 'movmemM' or 'call' patterns. 17990 17991 During the reload phase, an insn that has a 'use' as pattern can 17992 carry a reg_equal note. These 'use' insns will be deleted before 17993 the reload phase exits. 17994 17995 During the delayed branch scheduling phase, X may be an insn. This 17996 indicates that X previously was located at this place in the code 17997 and its data dependencies need to be taken into account. These 17998 'use' insns will be deleted before the delayed branch scheduling 17999 phase exits. 18000 18001'(parallel [X0 X1 ...])' 18002 Represents several side effects performed in parallel. The square 18003 brackets stand for a vector; the operand of 'parallel' is a vector 18004 of expressions. X0, X1 and so on are individual side effect 18005 expressions--expressions of code 'set', 'call', 'return', 18006 'simple_return', 'clobber' or 'use'. 18007 18008 "In parallel" means that first all the values used in the 18009 individual side-effects are computed, and second all the actual 18010 side-effects are performed. For example, 18011 18012 (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) 18013 (set (mem:SI (reg:SI 1)) (reg:SI 1))]) 18014 18015 says unambiguously that the values of hard register 1 and the 18016 memory location addressed by it are interchanged. In both places 18017 where '(reg:SI 1)' appears as a memory address it refers to the 18018 value in register 1 _before_ the execution of the insn. 18019 18020 It follows that it is _incorrect_ to use 'parallel' and expect the 18021 result of one 'set' to be available for the next one. For example, 18022 people sometimes attempt to represent a jump-if-zero instruction 18023 this way: 18024 18025 (parallel [(set (cc0) (reg:SI 34)) 18026 (set (pc) (if_then_else 18027 (eq (cc0) (const_int 0)) 18028 (label_ref ...) 18029 (pc)))]) 18030 18031 But this is incorrect, because it says that the jump condition 18032 depends on the condition code value _before_ this instruction, not 18033 on the new value that is set by this instruction. 18034 18035 Peephole optimization, which takes place together with final 18036 assembly code output, can produce insns whose patterns consist of a 18037 'parallel' whose elements are the operands needed to output the 18038 resulting assembler code--often 'reg', 'mem' or constant 18039 expressions. This would not be well-formed RTL at any other stage 18040 in compilation, but it is OK then because no further optimization 18041 remains to be done. However, the definition of the macro 18042 'NOTICE_UPDATE_CC', if any, must deal with such insns if you define 18043 any peephole optimizations. 18044 18045'(cond_exec [COND EXPR])' 18046 Represents a conditionally executed expression. The EXPR is 18047 executed only if the COND is nonzero. The COND expression must not 18048 have side-effects, but the EXPR may very well have side-effects. 18049 18050'(sequence [INSNS ...])' 18051 Represents a sequence of insns. If a 'sequence' appears in the 18052 chain of insns, then each of the INSNS that appears in the sequence 18053 must be suitable for appearing in the chain of insns, i.e. must 18054 satisfy the 'INSN_P' predicate. 18055 18056 After delay-slot scheduling is completed, an insn and all the insns 18057 that reside in its delay slots are grouped together into a 18058 'sequence'. The insn requiring the delay slot is the first insn in 18059 the vector; subsequent insns are to be placed in the delay slot. 18060 18061 'INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to 18062 indicate that a branch insn should be used that will conditionally 18063 annul the effect of the insns in the delay slots. In such a case, 18064 'INSN_FROM_TARGET_P' indicates that the insn is from the target of 18065 the branch and should be executed only if the branch is taken; 18066 otherwise the insn should be executed only if the branch is not 18067 taken. *Note Delay Slots::. 18068 18069 Some back ends also use 'sequence' objects for purposes other than 18070 delay-slot groups. This is not supported in the common parts of 18071 the compiler, which treat such sequences as delay-slot groups. 18072 18073 DWARF2 Call Frame Address (CFA) adjustments are sometimes also 18074 expressed using 'sequence' objects as the value of a 18075 'RTX_FRAME_RELATED_P' note. This only happens if the CFA 18076 adjustments cannot be easily derived from the pattern of the 18077 instruction to which the note is attached. In such cases, the 18078 value of the note is used instead of best-guesing the semantics of 18079 the instruction. The back end can attach notes containing a 18080 'sequence' of 'set' patterns that express the effect of the parent 18081 instruction. 18082 18083 These expression codes appear in place of a side effect, as the body of 18084an insn, though strictly speaking they do not always describe side 18085effects as such: 18086 18087'(asm_input S)' 18088 Represents literal assembler code as described by the string S. 18089 18090'(unspec [OPERANDS ...] INDEX)' 18091'(unspec_volatile [OPERANDS ...] INDEX)' 18092 Represents a machine-specific operation on OPERANDS. INDEX selects 18093 between multiple machine-specific operations. 'unspec_volatile' is 18094 used for volatile operations and operations that may trap; 'unspec' 18095 is used for other operations. 18096 18097 These codes may appear inside a 'pattern' of an insn, inside a 18098 'parallel', or inside an expression. 18099 18100'(addr_vec:M [LR0 LR1 ...])' 18101 Represents a table of jump addresses. The vector elements LR0, 18102 etc., are 'label_ref' expressions. The mode M specifies how much 18103 space is given to each address; normally M would be 'Pmode'. 18104 18105'(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)' 18106 Represents a table of jump addresses expressed as offsets from 18107 BASE. The vector elements LR0, etc., are 'label_ref' expressions 18108 and so is BASE. The mode M specifies how much space is given to 18109 each address-difference. MIN and MAX are set up by branch 18110 shortening and hold a label with a minimum and a maximum address, 18111 respectively. FLAGS indicates the relative position of BASE, MIN 18112 and MAX to the containing insn and of MIN and MAX to BASE. See 18113 rtl.def for details. 18114 18115'(prefetch:M ADDR RW LOCALITY)' 18116 Represents prefetch of memory at address ADDR. Operand RW is 1 if 18117 the prefetch is for data to be written, 0 otherwise; targets that 18118 do not support write prefetches should treat this as a normal 18119 prefetch. Operand LOCALITY specifies the amount of temporal 18120 locality; 0 if there is none or 1, 2, or 3 for increasing levels of 18121 temporal locality; targets that do not support locality hints 18122 should ignore this. 18123 18124 This insn is used to minimize cache-miss latency by moving data 18125 into a cache before it is accessed. It should use only 18126 non-faulting data prefetch instructions. 18127 18128 18129File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL 18130 1813114.16 Embedded Side-Effects on Addresses 18132======================================== 18133 18134Six special side-effect expression codes appear as memory addresses. 18135 18136'(pre_dec:M X)' 18137 Represents the side effect of decrementing X by a standard amount 18138 and represents also the value that X has after being decremented. 18139 X must be a 'reg' or 'mem', but most machines allow only a 'reg'. 18140 M must be the machine mode for pointers on the machine in use. The 18141 amount X is decremented by is the length in bytes of the machine 18142 mode of the containing memory reference of which this expression 18143 serves as the address. Here is an example of its use: 18144 18145 (mem:DF (pre_dec:SI (reg:SI 39))) 18146 18147 This says to decrement pseudo register 39 by the length of a 18148 'DFmode' value and use the result to address a 'DFmode' value. 18149 18150'(pre_inc:M X)' 18151 Similar, but specifies incrementing X instead of decrementing it. 18152 18153'(post_dec:M X)' 18154 Represents the same side effect as 'pre_dec' but a different value. 18155 The value represented here is the value X has before being 18156 decremented. 18157 18158'(post_inc:M X)' 18159 Similar, but specifies incrementing X instead of decrementing it. 18160 18161'(post_modify:M X Y)' 18162 18163 Represents the side effect of setting X to Y and represents X 18164 before X is modified. X must be a 'reg' or 'mem', but most 18165 machines allow only a 'reg'. M must be the machine mode for 18166 pointers on the machine in use. 18167 18168 The expression Y must be one of three forms: '(plus:M X Z)', 18169 '(minus:M X Z)', or '(plus:M X I)', where Z is an index register 18170 and I is a constant. 18171 18172 Here is an example of its use: 18173 18174 (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42) 18175 (reg:SI 48)))) 18176 18177 This says to modify pseudo register 42 by adding the contents of 18178 pseudo register 48 to it, after the use of what ever 42 points to. 18179 18180'(pre_modify:M X EXPR)' 18181 Similar except side effects happen before the use. 18182 18183 These embedded side effect expressions must be used with care. 18184Instruction patterns may not use them. Until the 'flow' pass of the 18185compiler, they may occur only to represent pushes onto the stack. The 18186'flow' pass finds cases where registers are incremented or decremented 18187in one instruction and used as an address shortly before or after; these 18188cases are then transformed to use pre- or post-increment or -decrement. 18189 18190 If a register used as the operand of these expressions is used in 18191another address in an insn, the original value of the register is used. 18192Uses of the register outside of an address are not permitted within the 18193same insn as a use in an embedded side effect expression because such 18194insns behave differently on different machines and hence must be treated 18195as ambiguous and disallowed. 18196 18197 An instruction that can be represented with an embedded side effect 18198could also be represented using 'parallel' containing an additional 18199'set' to describe how the address register is altered. This is not done 18200because machines that allow these operations at all typically allow them 18201wherever a memory address is called for. Describing them as additional 18202parallel stores would require doubling the number of entries in the 18203machine description. 18204 18205 18206File: gccint.info, Node: Assembler, Next: Debug Information, Prev: Incdec, Up: RTL 18207 1820814.17 Assembler Instructions as Expressions 18209=========================================== 18210 18211The RTX code 'asm_operands' represents a value produced by a 18212user-specified assembler instruction. It is used to represent an 'asm' 18213statement with arguments. An 'asm' statement with a single output 18214operand, like this: 18215 18216 asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); 18217 18218is represented using a single 'asm_operands' RTX which represents the 18219value that is stored in 'outputvar': 18220 18221 (set RTX-FOR-OUTPUTVAR 18222 (asm_operands "foo %1,%2,%0" "a" 0 18223 [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] 18224 [(asm_input:M1 "g") 18225 (asm_input:M2 "di")])) 18226 18227Here the operands of the 'asm_operands' RTX are the assembler template 18228string, the output-operand's constraint, the index-number of the output 18229operand among the output operands specified, a vector of input operand 18230RTX's, and a vector of input-operand modes and constraints. The mode M1 18231is the mode of the sum 'x+y'; M2 is that of '*z'. 18232 18233 When an 'asm' statement has multiple output values, its insn has 18234several such 'set' RTX's inside of a 'parallel'. Each 'set' contains an 18235'asm_operands'; all of these share the same assembler template and 18236vectors, but each contains the constraint for the respective output 18237operand. They are also distinguished by the output-operand index 18238number, which is 0, 1, ... for successive output operands. 18239 18240 18241File: gccint.info, Node: Debug Information, Next: Insns, Prev: Assembler, Up: RTL 18242 1824314.18 Variable Location Debug Information in RTL 18244================================================ 18245 18246Variable tracking relies on 'MEM_EXPR' and 'REG_EXPR' annotations to 18247determine what user variables memory and register references refer to. 18248 18249 Variable tracking at assignments uses these notes only when they refer 18250to variables that live at fixed locations (e.g., addressable variables, 18251global non-automatic variables). For variables whose location may vary, 18252it relies on the following types of notes. 18253 18254'(var_location:MODE VAR EXP STAT)' 18255 Binds variable 'var', a tree, to value EXP, an RTL expression. It 18256 appears only in 'NOTE_INSN_VAR_LOCATION' and 'DEBUG_INSN's, with 18257 slightly different meanings. MODE, if present, represents the mode 18258 of EXP, which is useful if it is a modeless expression. STAT is 18259 only meaningful in notes, indicating whether the variable is known 18260 to be initialized or uninitialized. 18261 18262'(debug_expr:MODE DECL)' 18263 Stands for the value bound to the 'DEBUG_EXPR_DECL' DECL, that 18264 points back to it, within value expressions in 'VAR_LOCATION' 18265 nodes. 18266 18267'(debug_implicit_ptr:MODE DECL)' 18268 Stands for the location of a DECL that is no longer addressable. 18269 18270'(entry_value:MODE DECL)' 18271 Stands for the value a DECL had at the entry point of the 18272 containing function. 18273 18274'(debug_parameter_ref:MODE DECL)' 18275 Refers to a parameter that was completely optimized out. 18276 18277'(debug_marker:MODE)' 18278 Marks a program location. With 'VOIDmode', it stands for the 18279 beginning of a statement, a recommended inspection point logically 18280 after all prior side effects, and before any subsequent side 18281 effects. With 'BLKmode', it indicates an inline entry point: the 18282 lexical block encoded in the 'INSN_LOCATION' is the enclosing block 18283 that encloses the inlined function. 18284 18285 18286File: gccint.info, Node: Insns, Next: Calls, Prev: Debug Information, Up: RTL 18287 1828814.19 Insns 18289=========== 18290 18291The RTL representation of the code for a function is a doubly-linked 18292chain of objects called "insns". Insns are expressions with special 18293codes that are used for no other purpose. Some insns are actual 18294instructions; others represent dispatch tables for 'switch' statements; 18295others represent labels to jump to or various sorts of declarative 18296information. 18297 18298 In addition to its own specific data, each insn must have a unique 18299id-number that distinguishes it from all other insns in the current 18300function (after delayed branch scheduling, copies of an insn with the 18301same id-number may be present in multiple places in a function, but 18302these copies will always be identical and will only appear inside a 18303'sequence'), and chain pointers to the preceding and following insns. 18304These three fields occupy the same position in every insn, independent 18305of the expression code of the insn. They could be accessed with 'XEXP' 18306and 'XINT', but instead three special macros are always used: 18307 18308'INSN_UID (I)' 18309 Accesses the unique id of insn I. 18310 18311'PREV_INSN (I)' 18312 Accesses the chain pointer to the insn preceding I. If I is the 18313 first insn, this is a null pointer. 18314 18315'NEXT_INSN (I)' 18316 Accesses the chain pointer to the insn following I. If I is the 18317 last insn, this is a null pointer. 18318 18319 The first insn in the chain is obtained by calling 'get_insns'; the 18320last insn is the result of calling 'get_last_insn'. Within the chain 18321delimited by these insns, the 'NEXT_INSN' and 'PREV_INSN' pointers must 18322always correspond: if INSN is not the first insn, 18323 18324 NEXT_INSN (PREV_INSN (INSN)) == INSN 18325 18326is always true and if INSN is not the last insn, 18327 18328 PREV_INSN (NEXT_INSN (INSN)) == INSN 18329 18330is always true. 18331 18332 After delay slot scheduling, some of the insns in the chain might be 18333'sequence' expressions, which contain a vector of insns. The value of 18334'NEXT_INSN' in all but the last of these insns is the next insn in the 18335vector; the value of 'NEXT_INSN' of the last insn in the vector is the 18336same as the value of 'NEXT_INSN' for the 'sequence' in which it is 18337contained. Similar rules apply for 'PREV_INSN'. 18338 18339 This means that the above invariants are not necessarily true for insns 18340inside 'sequence' expressions. Specifically, if INSN is the first insn 18341in a 'sequence', 'NEXT_INSN (PREV_INSN (INSN))' is the insn containing 18342the 'sequence' expression, as is the value of 'PREV_INSN (NEXT_INSN 18343(INSN))' if INSN is the last insn in the 'sequence' expression. You can 18344use these expressions to find the containing 'sequence' expression. 18345 18346 Every insn has one of the following expression codes: 18347 18348'insn' 18349 The expression code 'insn' is used for instructions that do not 18350 jump and do not do function calls. 'sequence' expressions are 18351 always contained in insns with code 'insn' even if one of those 18352 insns should jump or do function calls. 18353 18354 Insns with code 'insn' have four additional fields beyond the three 18355 mandatory ones listed above. These four are described in a table 18356 below. 18357 18358'jump_insn' 18359 The expression code 'jump_insn' is used for instructions that may 18360 jump (or, more generally, may contain 'label_ref' expressions to 18361 which 'pc' can be set in that instruction). If there is an 18362 instruction to return from the current function, it is recorded as 18363 a 'jump_insn'. 18364 18365 'jump_insn' insns have the same extra fields as 'insn' insns, 18366 accessed in the same way and in addition contain a field 18367 'JUMP_LABEL' which is defined once jump optimization has completed. 18368 18369 For simple conditional and unconditional jumps, this field contains 18370 the 'code_label' to which this insn will (possibly conditionally) 18371 branch. In a more complex jump, 'JUMP_LABEL' records one of the 18372 labels that the insn refers to; other jump target labels are 18373 recorded as 'REG_LABEL_TARGET' notes. The exception is 'addr_vec' 18374 and 'addr_diff_vec', where 'JUMP_LABEL' is 'NULL_RTX' and the only 18375 way to find the labels is to scan the entire body of the insn. 18376 18377 Return insns count as jumps, but their 'JUMP_LABEL' is 'RETURN' or 18378 'SIMPLE_RETURN'. 18379 18380'call_insn' 18381 The expression code 'call_insn' is used for instructions that may 18382 do function calls. It is important to distinguish these 18383 instructions because they imply that certain registers and memory 18384 locations may be altered unpredictably. 18385 18386 'call_insn' insns have the same extra fields as 'insn' insns, 18387 accessed in the same way and in addition contain a field 18388 'CALL_INSN_FUNCTION_USAGE', which contains a list (chain of 18389 'expr_list' expressions) containing 'use', 'clobber' and sometimes 18390 'set' expressions that denote hard registers and 'mem's used or 18391 clobbered by the called function. 18392 18393 A 'mem' generally points to a stack slot in which arguments passed 18394 to the libcall by reference (*note TARGET_PASS_BY_REFERENCE: 18395 Register Arguments.) are stored. If the argument is caller-copied 18396 (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot 18397 will be mentioned in 'clobber' and 'use' entries; if it's 18398 callee-copied, only a 'use' will appear, and the 'mem' may point to 18399 addresses that are not stack slots. 18400 18401 Registers occurring inside a 'clobber' in this list augment 18402 registers specified in 'CALL_USED_REGISTERS' (*note Register 18403 Basics::). 18404 18405 If the list contains a 'set' involving two registers, it indicates 18406 that the function returns one of its arguments. Such a 'set' may 18407 look like a no-op if the same register holds the argument and the 18408 return value. 18409 18410'code_label' 18411 A 'code_label' insn represents a label that a jump insn can jump 18412 to. It contains two special fields of data in addition to the 18413 three standard ones. 'CODE_LABEL_NUMBER' is used to hold the 18414 "label number", a number that identifies this label uniquely among 18415 all the labels in the compilation (not just in the current 18416 function). Ultimately, the label is represented in the assembler 18417 output as an assembler label, usually of the form 'LN' where N is 18418 the label number. 18419 18420 When a 'code_label' appears in an RTL expression, it normally 18421 appears within a 'label_ref' which represents the address of the 18422 label, as a number. 18423 18424 Besides as a 'code_label', a label can also be represented as a 18425 'note' of type 'NOTE_INSN_DELETED_LABEL'. 18426 18427 The field 'LABEL_NUSES' is only defined once the jump optimization 18428 phase is completed. It contains the number of times this label is 18429 referenced in the current function. 18430 18431 The field 'LABEL_KIND' differentiates four different types of 18432 labels: 'LABEL_NORMAL', 'LABEL_STATIC_ENTRY', 'LABEL_GLOBAL_ENTRY', 18433 and 'LABEL_WEAK_ENTRY'. The only labels that do not have type 18434 'LABEL_NORMAL' are "alternate entry points" to the current 18435 function. These may be static (visible only in the containing 18436 translation unit), global (exposed to all translation units), or 18437 weak (global, but can be overridden by another symbol with the same 18438 name). 18439 18440 Much of the compiler treats all four kinds of label identically. 18441 Some of it needs to know whether or not a label is an alternate 18442 entry point; for this purpose, the macro 'LABEL_ALT_ENTRY_P' is 18443 provided. It is equivalent to testing whether 'LABEL_KIND (label) 18444 == LABEL_NORMAL'. The only place that cares about the distinction 18445 between static, global, and weak alternate entry points, besides 18446 the front-end code that creates them, is the function 18447 'output_alternate_entry_point', in 'final.c'. 18448 18449 To set the kind of a label, use the 'SET_LABEL_KIND' macro. 18450 18451'jump_table_data' 18452 A 'jump_table_data' insn is a placeholder for the jump-table data 18453 of a 'casesi' or 'tablejump' insn. They are placed after a 18454 'tablejump_p' insn. A 'jump_table_data' insn is not part o a basic 18455 blockm but it is associated with the basic block that ends with the 18456 'tablejump_p' insn. The 'PATTERN' of a 'jump_table_data' is always 18457 either an 'addr_vec' or an 'addr_diff_vec', and a 'jump_table_data' 18458 insn is always preceded by a 'code_label'. The 'tablejump_p' insn 18459 refers to that 'code_label' via its 'JUMP_LABEL'. 18460 18461'barrier' 18462 Barriers are placed in the instruction stream when control cannot 18463 flow past them. They are placed after unconditional jump 18464 instructions to indicate that the jumps are unconditional and after 18465 calls to 'volatile' functions, which do not return (e.g., 'exit'). 18466 They contain no information beyond the three standard fields. 18467 18468'note' 18469 'note' insns are used to represent additional debugging and 18470 declarative information. They contain two nonstandard fields, an 18471 integer which is accessed with the macro 'NOTE_LINE_NUMBER' and a 18472 string accessed with 'NOTE_SOURCE_FILE'. 18473 18474 If 'NOTE_LINE_NUMBER' is positive, the note represents the position 18475 of a source line and 'NOTE_SOURCE_FILE' is the source file name 18476 that the line came from. These notes control generation of line 18477 number data in the assembler output. 18478 18479 Otherwise, 'NOTE_LINE_NUMBER' is not really a line number but a 18480 code with one of the following values (and 'NOTE_SOURCE_FILE' must 18481 contain a null pointer): 18482 18483 'NOTE_INSN_DELETED' 18484 Such a note is completely ignorable. Some passes of the 18485 compiler delete insns by altering them into notes of this 18486 kind. 18487 18488 'NOTE_INSN_DELETED_LABEL' 18489 This marks what used to be a 'code_label', but was not used 18490 for other purposes than taking its address and was transformed 18491 to mark that no code jumps to it. 18492 18493 'NOTE_INSN_BLOCK_BEG' 18494 'NOTE_INSN_BLOCK_END' 18495 These types of notes indicate the position of the beginning 18496 and end of a level of scoping of variable names. They control 18497 the output of debugging information. 18498 18499 'NOTE_INSN_EH_REGION_BEG' 18500 'NOTE_INSN_EH_REGION_END' 18501 These types of notes indicate the position of the beginning 18502 and end of a level of scoping for exception handling. 18503 'NOTE_EH_HANDLER' identifies which region is associated with 18504 these notes. 18505 18506 'NOTE_INSN_FUNCTION_BEG' 18507 Appears at the start of the function body, after the function 18508 prologue. 18509 18510 'NOTE_INSN_VAR_LOCATION' 18511 This note is used to generate variable location debugging 18512 information. It indicates that the user variable in its 18513 'VAR_LOCATION' operand is at the location given in the RTL 18514 expression, or holds a value that can be computed by 18515 evaluating the RTL expression from that static point in the 18516 program up to the next such note for the same user variable. 18517 18518 'NOTE_INSN_BEGIN_STMT' 18519 This note is used to generate 'is_stmt' markers in line number 18520 debuggign information. It indicates the beginning of a user 18521 statement. 18522 18523 'NOTE_INSN_INLINE_ENTRY' 18524 This note is used to generate 'entry_pc' for inlined 18525 subroutines in debugging information. It indicates an 18526 inspection point at which all arguments for the inlined 18527 function have been bound, and before its first statement. 18528 18529 These codes are printed symbolically when they appear in debugging 18530 dumps. 18531 18532'debug_insn' 18533 The expression code 'debug_insn' is used for pseudo-instructions 18534 that hold debugging information for variable tracking at 18535 assignments (see '-fvar-tracking-assignments' option). They are 18536 the RTL representation of 'GIMPLE_DEBUG' statements (*note 18537 GIMPLE_DEBUG::), with a 'VAR_LOCATION' operand that binds a user 18538 variable tree to an RTL representation of the 'value' in the 18539 corresponding statement. A 'DEBUG_EXPR' in it stands for the value 18540 bound to the corresponding 'DEBUG_EXPR_DECL'. 18541 18542 'GIMPLE_DEBUG_BEGIN_STMT' and 'GIMPLE_DEBUG_INLINE_ENTRY' are 18543 expanded to RTL as a 'DEBUG_INSN' with a 'DEBUG_MARKER' 'PATTERN'; 18544 the difference is the RTL mode: the former's 'DEBUG_MARKER' is 18545 'VOIDmode', whereas the latter is 'BLKmode'; information about the 18546 inlined function can be taken from the lexical block encoded in the 18547 'INSN_LOCATION'. These 'DEBUG_INSN's, that do not carry 18548 'VAR_LOCATION' information, just 'DEBUG_MARKER's, can be detected 18549 by testing 'DEBUG_MARKER_INSN_P', whereas those that do can be 18550 recognized as 'DEBUG_BIND_INSN_P'. 18551 18552 Throughout optimization passes, 'DEBUG_INSN's are not reordered 18553 with respect to each other, particularly during scheduling. 18554 Binding information is kept in pseudo-instruction form, so that, 18555 unlike notes, it gets the same treatment and adjustments that 18556 regular instructions would. It is the variable tracking pass that 18557 turns these pseudo-instructions into 'NOTE_INSN_VAR_LOCATION', 18558 'NOTE_INSN_BEGIN_STMT' and 'NOTE_INSN_INLINE_ENTRY' notes, 18559 analyzing control flow, value equivalences and changes to registers 18560 and memory referenced in value expressions, propagating the values 18561 of debug temporaries and determining expressions that can be used 18562 to compute the value of each user variable at as many points 18563 (ranges, actually) in the program as possible. 18564 18565 Unlike 'NOTE_INSN_VAR_LOCATION', the value expression in an 18566 'INSN_VAR_LOCATION' denotes a value at that specific point in the 18567 program, rather than an expression that can be evaluated at any 18568 later point before an overriding 'VAR_LOCATION' is encountered. 18569 E.g., if a user variable is bound to a 'REG' and then a subsequent 18570 insn modifies the 'REG', the note location would keep mapping the 18571 user variable to the register across the insn, whereas the insn 18572 location would keep the variable bound to the value, so that the 18573 variable tracking pass would emit another location note for the 18574 variable at the point in which the register is modified. 18575 18576 The machine mode of an insn is normally 'VOIDmode', but some phases use 18577the mode for various purposes. 18578 18579 The common subexpression elimination pass sets the mode of an insn to 18580'QImode' when it is the first insn in a block that has already been 18581processed. 18582 18583 The second Haifa scheduling pass, for targets that can multiple issue, 18584sets the mode of an insn to 'TImode' when it is believed that the 18585instruction begins an issue group. That is, when the instruction cannot 18586issue simultaneously with the previous. This may be relied on by later 18587passes, in particular machine-dependent reorg. 18588 18589 Here is a table of the extra fields of 'insn', 'jump_insn' and 18590'call_insn' insns: 18591 18592'PATTERN (I)' 18593 An expression for the side effect performed by this insn. This 18594 must be one of the following codes: 'set', 'call', 'use', 18595 'clobber', 'return', 'simple_return', 'asm_input', 'asm_output', 18596 'addr_vec', 'addr_diff_vec', 'trap_if', 'unspec', 18597 'unspec_volatile', 'parallel', 'cond_exec', or 'sequence'. If it 18598 is a 'parallel', each element of the 'parallel' must be one these 18599 codes, except that 'parallel' expressions cannot be nested and 18600 'addr_vec' and 'addr_diff_vec' are not permitted inside a 18601 'parallel' expression. 18602 18603'INSN_CODE (I)' 18604 An integer that says which pattern in the machine description 18605 matches this insn, or -1 if the matching has not yet been 18606 attempted. 18607 18608 Such matching is never attempted and this field remains -1 on an 18609 insn whose pattern consists of a single 'use', 'clobber', 18610 'asm_input', 'addr_vec' or 'addr_diff_vec' expression. 18611 18612 Matching is also never attempted on insns that result from an 'asm' 18613 statement. These contain at least one 'asm_operands' expression. 18614 The function 'asm_noperands' returns a non-negative value for such 18615 insns. 18616 18617 In the debugging output, this field is printed as a number followed 18618 by a symbolic representation that locates the pattern in the 'md' 18619 file as some small positive or negative offset from a named 18620 pattern. 18621 18622'LOG_LINKS (I)' 18623 A list (chain of 'insn_list' expressions) giving information about 18624 dependencies between instructions within a basic block. Neither a 18625 jump nor a label may come between the related insns. These are 18626 only used by the schedulers and by combine. This is a deprecated 18627 data structure. Def-use and use-def chains are now preferred. 18628 18629'REG_NOTES (I)' 18630 A list (chain of 'expr_list', 'insn_list' and 'int_list' 18631 expressions) giving miscellaneous information about the insn. It 18632 is often information pertaining to the registers used in this insn. 18633 18634 The 'LOG_LINKS' field of an insn is a chain of 'insn_list' expressions. 18635Each of these has two operands: the first is an insn, and the second is 18636another 'insn_list' expression (the next one in the chain). The last 18637'insn_list' in the chain has a null pointer as second operand. The 18638significant thing about the chain is which insns appear in it (as first 18639operands of 'insn_list' expressions). Their order is not significant. 18640 18641 This list is originally set up by the flow analysis pass; it is a null 18642pointer until then. Flow only adds links for those data dependencies 18643which can be used for instruction combination. For each insn, the flow 18644analysis pass adds a link to insns which store into registers values 18645that are used for the first time in this insn. 18646 18647 The 'REG_NOTES' field of an insn is a chain similar to the 'LOG_LINKS' 18648field but it includes 'expr_list' and 'int_list' expressions in addition 18649to 'insn_list' expressions. There are several kinds of register notes, 18650which are distinguished by the machine mode, which in a register note is 18651really understood as being an 'enum reg_note'. The first operand OP of 18652the note is data whose meaning depends on the kind of note. 18653 18654 The macro 'REG_NOTE_KIND (X)' returns the kind of register note. Its 18655counterpart, the macro 'PUT_REG_NOTE_KIND (X, NEWKIND)' sets the 18656register note type of X to be NEWKIND. 18657 18658 Register notes are of three classes: They may say something about an 18659input to an insn, they may say something about an output of an insn, or 18660they may create a linkage between two insns. There are also a set of 18661values that are only used in 'LOG_LINKS'. 18662 18663 These register notes annotate inputs to an insn: 18664 18665'REG_DEAD' 18666 The value in OP dies in this insn; that is to say, altering the 18667 value immediately after this insn would not affect the future 18668 behavior of the program. 18669 18670 It does not follow that the register OP has no useful value after 18671 this insn since OP is not necessarily modified by this insn. 18672 Rather, no subsequent instruction uses the contents of OP. 18673 18674'REG_UNUSED' 18675 The register OP being set by this insn will not be used in a 18676 subsequent insn. This differs from a 'REG_DEAD' note, which 18677 indicates that the value in an input will not be used subsequently. 18678 These two notes are independent; both may be present for the same 18679 register. 18680 18681'REG_INC' 18682 The register OP is incremented (or decremented; at this level there 18683 is no distinction) by an embedded side effect inside this insn. 18684 This means it appears in a 'post_inc', 'pre_inc', 'post_dec' or 18685 'pre_dec' expression. 18686 18687'REG_NONNEG' 18688 The register OP is known to have a nonnegative value when this insn 18689 is reached. This is used so that decrement and branch until zero 18690 instructions, such as the m68k dbra, can be matched. 18691 18692 The 'REG_NONNEG' note is added to insns only if the machine 18693 description has a 'decrement_and_branch_until_zero' pattern. 18694 18695'REG_LABEL_OPERAND' 18696 This insn uses OP, a 'code_label' or a 'note' of type 18697 'NOTE_INSN_DELETED_LABEL', but is not a 'jump_insn', or it is a 18698 'jump_insn' that refers to the operand as an ordinary operand. The 18699 label may still eventually be a jump target, but if so in an 18700 indirect jump in a subsequent insn. The presence of this note 18701 allows jump optimization to be aware that OP is, in fact, being 18702 used, and flow optimization to build an accurate flow graph. 18703 18704'REG_LABEL_TARGET' 18705 This insn is a 'jump_insn' but not an 'addr_vec' or 18706 'addr_diff_vec'. It uses OP, a 'code_label' as a direct or 18707 indirect jump target. Its purpose is similar to that of 18708 'REG_LABEL_OPERAND'. This note is only present if the insn has 18709 multiple targets; the last label in the insn (in the highest 18710 numbered insn-field) goes into the 'JUMP_LABEL' field and does not 18711 have a 'REG_LABEL_TARGET' note. *Note JUMP_LABEL: Insns. 18712 18713'REG_SETJMP' 18714 Appears attached to each 'CALL_INSN' to 'setjmp' or a related 18715 function. 18716 18717 The following notes describe attributes of outputs of an insn: 18718 18719'REG_EQUIV' 18720'REG_EQUAL' 18721 This note is only valid on an insn that sets only one register and 18722 indicates that that register will be equal to OP at run time; the 18723 scope of this equivalence differs between the two types of notes. 18724 The value which the insn explicitly copies into the register may 18725 look different from OP, but they will be equal at run time. If the 18726 output of the single 'set' is a 'strict_low_part' or 'zero_extract' 18727 expression, the note refers to the register that is contained in 18728 its first operand. 18729 18730 For 'REG_EQUIV', the register is equivalent to OP throughout the 18731 entire function, and could validly be replaced in all its 18732 occurrences by OP. ("Validly" here refers to the data flow of the 18733 program; simple replacement may make some insns invalid.) For 18734 example, when a constant is loaded into a register that is never 18735 assigned any other value, this kind of note is used. 18736 18737 When a parameter is copied into a pseudo-register at entry to a 18738 function, a note of this kind records that the register is 18739 equivalent to the stack slot where the parameter was passed. 18740 Although in this case the register may be set by other insns, it is 18741 still valid to replace the register by the stack slot throughout 18742 the function. 18743 18744 A 'REG_EQUIV' note is also used on an instruction which copies a 18745 register parameter into a pseudo-register at entry to a function, 18746 if there is a stack slot where that parameter could be stored. 18747 Although other insns may set the pseudo-register, it is valid for 18748 the compiler to replace the pseudo-register by stack slot 18749 throughout the function, provided the compiler ensures that the 18750 stack slot is properly initialized by making the replacement in the 18751 initial copy instruction as well. This is used on machines for 18752 which the calling convention allocates stack space for register 18753 parameters. See 'REG_PARM_STACK_SPACE' in *note Stack Arguments::. 18754 18755 In the case of 'REG_EQUAL', the register that is set by this insn 18756 will be equal to OP at run time at the end of this insn but not 18757 necessarily elsewhere in the function. In this case, OP is 18758 typically an arithmetic expression. For example, when a sequence 18759 of insns such as a library call is used to perform an arithmetic 18760 operation, this kind of note is attached to the insn that produces 18761 or copies the final value. 18762 18763 These two notes are used in different ways by the compiler passes. 18764 'REG_EQUAL' is used by passes prior to register allocation (such as 18765 common subexpression elimination and loop optimization) to tell 18766 them how to think of that value. 'REG_EQUIV' notes are used by 18767 register allocation to indicate that there is an available 18768 substitute expression (either a constant or a 'mem' expression for 18769 the location of a parameter on the stack) that may be used in place 18770 of a register if insufficient registers are available. 18771 18772 Except for stack homes for parameters, which are indicated by a 18773 'REG_EQUIV' note and are not useful to the early optimization 18774 passes and pseudo registers that are equivalent to a memory 18775 location throughout their entire life, which is not detected until 18776 later in the compilation, all equivalences are initially indicated 18777 by an attached 'REG_EQUAL' note. In the early stages of register 18778 allocation, a 'REG_EQUAL' note is changed into a 'REG_EQUIV' note 18779 if OP is a constant and the insn represents the only set of its 18780 destination register. 18781 18782 Thus, compiler passes prior to register allocation need only check 18783 for 'REG_EQUAL' notes and passes subsequent to register allocation 18784 need only check for 'REG_EQUIV' notes. 18785 18786 These notes describe linkages between insns. They occur in pairs: one 18787insn has one of a pair of notes that points to a second insn, which has 18788the inverse note pointing back to the first insn. 18789 18790'REG_CC_SETTER' 18791'REG_CC_USER' 18792 On machines that use 'cc0', the insns which set and use 'cc0' set 18793 and use 'cc0' are adjacent. However, when branch delay slot 18794 filling is done, this may no longer be true. In this case a 18795 'REG_CC_USER' note will be placed on the insn setting 'cc0' to 18796 point to the insn using 'cc0' and a 'REG_CC_SETTER' note will be 18797 placed on the insn using 'cc0' to point to the insn setting 'cc0'. 18798 18799 These values are only used in the 'LOG_LINKS' field, and indicate the 18800type of dependency that each link represents. Links which indicate a 18801data dependence (a read after write dependence) do not use any code, 18802they simply have mode 'VOIDmode', and are printed without any 18803descriptive text. 18804 18805'REG_DEP_TRUE' 18806 This indicates a true dependence (a read after write dependence). 18807 18808'REG_DEP_OUTPUT' 18809 This indicates an output dependence (a write after write 18810 dependence). 18811 18812'REG_DEP_ANTI' 18813 This indicates an anti dependence (a write after read dependence). 18814 18815 These notes describe information gathered from gcov profile data. They 18816are stored in the 'REG_NOTES' field of an insn. 18817 18818'REG_BR_PROB' 18819 This is used to specify the ratio of branches to non-branches of a 18820 branch insn according to the profile data. The note is represented 18821 as an 'int_list' expression whose integer value is an encoding of 18822 'profile_probability' type. 'profile_probability' provide member 18823 function 'from_reg_br_prob_note' and 'to_reg_br_prob_note' to 18824 extract and store the probability into the RTL encoding. 18825 18826'REG_BR_PRED' 18827 These notes are found in JUMP insns after delayed branch scheduling 18828 has taken place. They indicate both the direction and the 18829 likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_* 18830 values. 18831 18832'REG_FRAME_RELATED_EXPR' 18833 This is used on an RTX_FRAME_RELATED_P insn wherein the attached 18834 expression is used in place of the actual insn pattern. This is 18835 done in cases where the pattern is either complex or misleading. 18836 18837 The note 'REG_CALL_NOCF_CHECK' is used in conjunction with the 18838'-fcf-protection=branch' option. The note is set if a 'nocf_check' 18839attribute is specified for a function type or a pointer to function 18840type. The note is stored in the 'REG_NOTES' field of an insn. 18841 18842'REG_CALL_NOCF_CHECK' 18843 Users have control through the 'nocf_check' attribute to identify 18844 which calls to a function should be skipped from control-flow 18845 instrumentation when the option '-fcf-protection=branch' is 18846 specified. The compiler puts a 'REG_CALL_NOCF_CHECK' note on each 18847 'CALL_INSN' instruction that has a function type marked with a 18848 'nocf_check' attribute. 18849 18850 For convenience, the machine mode in an 'insn_list' or 'expr_list' is 18851printed using these symbolic codes in debugging dumps. 18852 18853 The only difference between the expression codes 'insn_list' and 18854'expr_list' is that the first operand of an 'insn_list' is assumed to be 18855an insn and is printed in debugging dumps as the insn's unique id; the 18856first operand of an 'expr_list' is printed in the ordinary way as an 18857expression. 18858 18859 18860File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL 18861 1886214.20 RTL Representation of Function-Call Insns 18863=============================================== 18864 18865Insns that call subroutines have the RTL expression code 'call_insn'. 18866These insns must satisfy special rules, and their bodies must use a 18867special RTL expression code, 'call'. 18868 18869 A 'call' expression has two operands, as follows: 18870 18871 (call (mem:FM ADDR) NBYTES) 18872 18873Here NBYTES is an operand that represents the number of bytes of 18874argument data being passed to the subroutine, FM is a machine mode 18875(which must equal as the definition of the 'FUNCTION_MODE' macro in the 18876machine description) and ADDR represents the address of the subroutine. 18877 18878 For a subroutine that returns no value, the 'call' expression as shown 18879above is the entire body of the insn, except that the insn might also 18880contain 'use' or 'clobber' expressions. 18881 18882 For a subroutine that returns a value whose mode is not 'BLKmode', the 18883value is returned in a hard register. If this register's number is R, 18884then the body of the call insn looks like this: 18885 18886 (set (reg:M R) 18887 (call (mem:FM ADDR) NBYTES)) 18888 18889This RTL expression makes it clear (to the optimizer passes) that the 18890appropriate register receives a useful value in this insn. 18891 18892 When a subroutine returns a 'BLKmode' value, it is handled by passing 18893to the subroutine the address of a place to store the value. So the 18894call insn itself does not "return" any value, and it has the same RTL 18895form as a call that returns nothing. 18896 18897 On some machines, the call instruction itself clobbers some register, 18898for example to contain the return address. 'call_insn' insns on these 18899machines should have a body which is a 'parallel' that contains both the 18900'call' expression and 'clobber' expressions that indicate which 18901registers are destroyed. Similarly, if the call instruction requires 18902some register other than the stack pointer that is not explicitly 18903mentioned in its RTL, a 'use' subexpression should mention that 18904register. 18905 18906 Functions that are called are assumed to modify all registers listed in 18907the configuration macro 'CALL_USED_REGISTERS' (*note Register Basics::) 18908and, with the exception of 'const' functions and library calls, to 18909modify all of memory. 18910 18911 Insns containing just 'use' expressions directly precede the 18912'call_insn' insn to indicate which registers contain inputs to the 18913function. Similarly, if registers other than those in 18914'CALL_USED_REGISTERS' are clobbered by the called function, insns 18915containing a single 'clobber' follow immediately after the call to 18916indicate which registers. 18917 18918 18919File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL 18920 1892114.21 Structure Sharing Assumptions 18922=================================== 18923 18924The compiler assumes that certain kinds of RTL expressions are unique; 18925there do not exist two distinct objects representing the same value. In 18926other cases, it makes an opposite assumption: that no RTL expression 18927object of a certain kind appears in more than one place in the 18928containing structure. 18929 18930 These assumptions refer to a single function; except for the RTL 18931objects that describe global variables and external functions, and a few 18932standard objects such as small integer constants, no RTL objects are 18933common to two functions. 18934 18935 * Each pseudo-register has only a single 'reg' object to represent 18936 it, and therefore only a single machine mode. 18937 18938 * For any symbolic label, there is only one 'symbol_ref' object 18939 referring to it. 18940 18941 * All 'const_int' expressions with equal values are shared. 18942 18943 * All 'const_poly_int' expressions with equal modes and values are 18944 shared. 18945 18946 * There is only one 'pc' expression. 18947 18948 * There is only one 'cc0' expression. 18949 18950 * There is only one 'const_double' expression with value 0 for each 18951 floating point mode. Likewise for values 1 and 2. 18952 18953 * There is only one 'const_vector' expression with value 0 for each 18954 vector mode, be it an integer or a double constant vector. 18955 18956 * No 'label_ref' or 'scratch' appears in more than one place in the 18957 RTL structure; in other words, it is safe to do a tree-walk of all 18958 the insns in the function and assume that each time a 'label_ref' 18959 or 'scratch' is seen it is distinct from all others that are seen. 18960 18961 * Only one 'mem' object is normally created for each static variable 18962 or stack slot, so these objects are frequently shared in all the 18963 places they appear. However, separate but equal objects for these 18964 variables are occasionally made. 18965 18966 * When a single 'asm' statement has multiple output operands, a 18967 distinct 'asm_operands' expression is made for each output operand. 18968 However, these all share the vector which contains the sequence of 18969 input operands. This sharing is used later on to test whether two 18970 'asm_operands' expressions come from the same statement, so all 18971 optimizations must carefully preserve the sharing if they copy the 18972 vector at all. 18973 18974 * No RTL object appears in more than one place in the RTL structure 18975 except as described above. Many passes of the compiler rely on 18976 this by assuming that they can modify RTL objects in place without 18977 unwanted side-effects on other insns. 18978 18979 * During initial RTL generation, shared structure is freely 18980 introduced. After all the RTL for a function has been generated, 18981 all shared structure is copied by 'unshare_all_rtl' in 18982 'emit-rtl.c', after which the above rules are guaranteed to be 18983 followed. 18984 18985 * During the combiner pass, shared structure within an insn can exist 18986 temporarily. However, the shared structure is copied before the 18987 combiner is finished with the insn. This is done by calling 18988 'copy_rtx_if_shared', which is a subroutine of 'unshare_all_rtl'. 18989 18990 18991File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL 18992 1899314.22 Reading RTL 18994================= 18995 18996To read an RTL object from a file, call 'read_rtx'. It takes one 18997argument, a stdio stream, and returns a single RTL object. This routine 18998is defined in 'read-rtl.c'. It is not available in the compiler itself, 18999only the various programs that generate the compiler back end from the 19000machine description. 19001 19002 People frequently have the idea of using RTL stored as text in a file 19003as an interface between a language front end and the bulk of GCC. This 19004idea is not feasible. 19005 19006 GCC was designed to use RTL internally only. Correct RTL for a given 19007program is very dependent on the particular target machine. And the RTL 19008does not contain all the information about the program. 19009 19010 The proper way to interface GCC to a new language front end is with the 19011"tree" data structure, described in the files 'tree.h' and 'tree.def'. 19012The documentation for this structure (*note GENERIC::) is incomplete. 19013 19014 19015File: gccint.info, Node: Control Flow, Next: Loop Analysis and Representation, Prev: RTL, Up: Top 19016 1901715 Control Flow Graph 19018********************* 19019 19020A control flow graph (CFG) is a data structure built on top of the 19021intermediate code representation (the RTL or 'GIMPLE' instruction 19022stream) abstracting the control flow behavior of a function that is 19023being compiled. The CFG is a directed graph where the vertices 19024represent basic blocks and edges represent possible transfer of control 19025flow from one basic block to another. The data structures used to 19026represent the control flow graph are defined in 'basic-block.h'. 19027 19028 In GCC, the representation of control flow is maintained throughout the 19029compilation process, from constructing the CFG early in 'pass_build_cfg' 19030to 'pass_free_cfg' (see 'passes.def'). The CFG takes various different 19031modes and may undergo extensive manipulations, but the graph is always 19032valid between its construction and its release. This way, transfer of 19033information such as data flow, a measured profile, or the loop tree, can 19034be propagated through the passes pipeline, and even from 'GIMPLE' to 19035'RTL'. 19036 19037 Often the CFG may be better viewed as integral part of instruction 19038chain, than structure built on the top of it. Updating the compiler's 19039intermediate representation for instructions can not be easily done 19040without proper maintenance of the CFG simultaneously. 19041 19042* Menu: 19043 19044* Basic Blocks:: The definition and representation of basic blocks. 19045* Edges:: Types of edges and their representation. 19046* Profile information:: Representation of frequencies and probabilities. 19047* Maintaining the CFG:: Keeping the control flow graph and up to date. 19048* Liveness information:: Using and maintaining liveness information. 19049 19050 19051File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow 19052 1905315.1 Basic Blocks 19054================= 19055 19056A basic block is a straight-line sequence of code with only one entry 19057point and only one exit. In GCC, basic blocks are represented using the 19058'basic_block' data type. 19059 19060 Special basic blocks represent possible entry and exit points of a 19061function. These blocks are called 'ENTRY_BLOCK_PTR' and 19062'EXIT_BLOCK_PTR'. These blocks do not contain any code. 19063 19064 The 'BASIC_BLOCK' array contains all basic blocks in an unspecified 19065order. Each 'basic_block' structure has a field that holds a unique 19066integer identifier 'index' that is the index of the block in the 19067'BASIC_BLOCK' array. The total number of basic blocks in the function 19068is 'n_basic_blocks'. Both the basic block indices and the total number 19069of basic blocks may vary during the compilation process, as passes 19070reorder, create, duplicate, and destroy basic blocks. The index for any 19071block should never be greater than 'last_basic_block'. The indices 0 19072and 1 are special codes reserved for 'ENTRY_BLOCK' and 'EXIT_BLOCK', the 19073indices of 'ENTRY_BLOCK_PTR' and 'EXIT_BLOCK_PTR'. 19074 19075 Two pointer members of the 'basic_block' structure are the pointers 19076'next_bb' and 'prev_bb'. These are used to keep doubly linked chain of 19077basic blocks in the same order as the underlying instruction stream. 19078The chain of basic blocks is updated transparently by the provided API 19079for manipulating the CFG. The macro 'FOR_EACH_BB' can be used to visit 19080all the basic blocks in lexicographical order, except 'ENTRY_BLOCK' and 19081'EXIT_BLOCK'. The macro 'FOR_ALL_BB' also visits all basic blocks in 19082lexicographical order, including 'ENTRY_BLOCK' and 'EXIT_BLOCK'. 19083 19084 The functions 'post_order_compute' and 'inverted_post_order_compute' 19085can be used to compute topological orders of the CFG. The orders are 19086stored as vectors of basic block indices. The 'BASIC_BLOCK' array can 19087be used to iterate each basic block by index. Dominator traversals are 19088also possible using 'walk_dominator_tree'. Given two basic blocks A and 19089B, block A dominates block B if A is _always_ executed before B. 19090 19091 Each 'basic_block' also contains pointers to the first instruction (the 19092"head") and the last instruction (the "tail") or "end" of the 19093instruction stream contained in a basic block. In fact, since the 19094'basic_block' data type is used to represent blocks in both major 19095intermediate representations of GCC ('GIMPLE' and RTL), there are 19096pointers to the head and end of a basic block for both representations, 19097stored in intermediate representation specific data in the 'il' field of 19098'struct basic_block_def'. 19099 19100 For RTL, these pointers are 'BB_HEAD' and 'BB_END'. 19101 19102 In the RTL representation of a function, the instruction stream 19103contains not only the "real" instructions, but also "notes" or "insn 19104notes" (to distinguish them from "reg notes"). Any function that moves 19105or duplicates the basic blocks needs to take care of updating of these 19106notes. Many of these notes expect that the instruction stream consists 19107of linear regions, so updating can sometimes be tedious. All types of 19108insn notes are defined in 'insn-notes.def'. 19109 19110 In the RTL function representation, the instructions contained in a 19111basic block always follow a 'NOTE_INSN_BASIC_BLOCK', but zero or more 19112'CODE_LABEL' nodes can precede the block note. A basic block ends with 19113a control flow instruction or with the last instruction before the next 19114'CODE_LABEL' or 'NOTE_INSN_BASIC_BLOCK'. By definition, a 'CODE_LABEL' 19115cannot appear in the middle of the instruction stream of a basic block. 19116 19117 In addition to notes, the jump table vectors are also represented as 19118"pseudo-instructions" inside the insn stream. These vectors never 19119appear in the basic block and should always be placed just after the 19120table jump instructions referencing them. After removing the table-jump 19121it is often difficult to eliminate the code computing the address and 19122referencing the vector, so cleaning up these vectors is postponed until 19123after liveness analysis. Thus the jump table vectors may appear in the 19124insn stream unreferenced and without any purpose. Before any edge is 19125made "fall-thru", the existence of such construct in the way needs to be 19126checked by calling 'can_fallthru' function. 19127 19128 For the 'GIMPLE' representation, the PHI nodes and statements contained 19129in a basic block are in a 'gimple_seq' pointed to by the basic block 19130intermediate language specific pointers. Abstract containers and 19131iterators are used to access the PHI nodes and statements in a basic 19132blocks. These iterators are called "GIMPLE statement iterators" (GSIs). 19133Grep for '^gsi' in the various 'gimple-*' and 'tree-*' files. There is 19134a 'gimple_stmt_iterator' type for iterating over all kinds of statement, 19135and a 'gphi_iterator' subclass for iterating over PHI nodes. The 19136following snippet will pretty-print all PHI nodes the statements of the 19137current function in the GIMPLE representation. 19138 19139 basic_block bb; 19140 19141 FOR_EACH_BB (bb) 19142 { 19143 gphi_iterator pi; 19144 gimple_stmt_iterator si; 19145 19146 for (pi = gsi_start_phis (bb); !gsi_end_p (pi); gsi_next (&pi)) 19147 { 19148 gphi *phi = pi.phi (); 19149 print_gimple_stmt (dump_file, phi, 0, TDF_SLIM); 19150 } 19151 for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si)) 19152 { 19153 gimple stmt = gsi_stmt (si); 19154 print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM); 19155 } 19156 } 19157 19158 19159File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow 19160 1916115.2 Edges 19162========== 19163 19164Edges represent possible control flow transfers from the end of some 19165basic block A to the head of another basic block B. We say that A is a 19166predecessor of B, and B is a successor of A. Edges are represented in 19167GCC with the 'edge' data type. Each 'edge' acts as a link between two 19168basic blocks: The 'src' member of an edge points to the predecessor 19169basic block of the 'dest' basic block. The members 'preds' and 'succs' 19170of the 'basic_block' data type point to type-safe vectors of edges to 19171the predecessors and successors of the block. 19172 19173 When walking the edges in an edge vector, "edge iterators" should be 19174used. Edge iterators are constructed using the 'edge_iterator' data 19175structure and several methods are available to operate on them: 19176 19177'ei_start' 19178 This function initializes an 'edge_iterator' that points to the 19179 first edge in a vector of edges. 19180 19181'ei_last' 19182 This function initializes an 'edge_iterator' that points to the 19183 last edge in a vector of edges. 19184 19185'ei_end_p' 19186 This predicate is 'true' if an 'edge_iterator' represents the last 19187 edge in an edge vector. 19188 19189'ei_one_before_end_p' 19190 This predicate is 'true' if an 'edge_iterator' represents the 19191 second last edge in an edge vector. 19192 19193'ei_next' 19194 This function takes a pointer to an 'edge_iterator' and makes it 19195 point to the next edge in the sequence. 19196 19197'ei_prev' 19198 This function takes a pointer to an 'edge_iterator' and makes it 19199 point to the previous edge in the sequence. 19200 19201'ei_edge' 19202 This function returns the 'edge' currently pointed to by an 19203 'edge_iterator'. 19204 19205'ei_safe_safe' 19206 This function returns the 'edge' currently pointed to by an 19207 'edge_iterator', but returns 'NULL' if the iterator is pointing at 19208 the end of the sequence. This function has been provided for 19209 existing code makes the assumption that a 'NULL' edge indicates the 19210 end of the sequence. 19211 19212 The convenience macro 'FOR_EACH_EDGE' can be used to visit all of the 19213edges in a sequence of predecessor or successor edges. It must not be 19214used when an element might be removed during the traversal, otherwise 19215elements will be missed. Here is an example of how to use the macro: 19216 19217 edge e; 19218 edge_iterator ei; 19219 19220 FOR_EACH_EDGE (e, ei, bb->succs) 19221 { 19222 if (e->flags & EDGE_FALLTHRU) 19223 break; 19224 } 19225 19226 There are various reasons why control flow may transfer from one block 19227to another. One possibility is that some instruction, for example a 19228'CODE_LABEL', in a linearized instruction stream just always starts a 19229new basic block. In this case a "fall-thru" edge links the basic block 19230to the first following basic block. But there are several other reasons 19231why edges may be created. The 'flags' field of the 'edge' data type is 19232used to store information about the type of edge we are dealing with. 19233Each edge is of one of the following types: 19234 19235_jump_ 19236 No type flags are set for edges corresponding to jump instructions. 19237 These edges are used for unconditional or conditional jumps and in 19238 RTL also for table jumps. They are the easiest to manipulate as 19239 they may be freely redirected when the flow graph is not in SSA 19240 form. 19241 19242_fall-thru_ 19243 Fall-thru edges are present in case where the basic block may 19244 continue execution to the following one without branching. These 19245 edges have the 'EDGE_FALLTHRU' flag set. Unlike other types of 19246 edges, these edges must come into the basic block immediately 19247 following in the instruction stream. The function 19248 'force_nonfallthru' is available to insert an unconditional jump in 19249 the case that redirection is needed. Note that this may require 19250 creation of a new basic block. 19251 19252_exception handling_ 19253 Exception handling edges represent possible control transfers from 19254 a trapping instruction to an exception handler. The definition of 19255 "trapping" varies. In C++, only function calls can throw, but for 19256 Ada exceptions like division by zero or segmentation fault are 19257 defined and thus each instruction possibly throwing this kind of 19258 exception needs to be handled as control flow instruction. 19259 Exception edges have the 'EDGE_ABNORMAL' and 'EDGE_EH' flags set. 19260 19261 When updating the instruction stream it is easy to change possibly 19262 trapping instruction to non-trapping, by simply removing the 19263 exception edge. The opposite conversion is difficult, but should 19264 not happen anyway. The edges can be eliminated via 19265 'purge_dead_edges' call. 19266 19267 In the RTL representation, the destination of an exception edge is 19268 specified by 'REG_EH_REGION' note attached to the insn. In case of 19269 a trapping call the 'EDGE_ABNORMAL_CALL' flag is set too. In the 19270 'GIMPLE' representation, this extra flag is not set. 19271 19272 In the RTL representation, the predicate 'may_trap_p' may be used 19273 to check whether instruction still may trap or not. For the tree 19274 representation, the 'tree_could_trap_p' predicate is available, but 19275 this predicate only checks for possible memory traps, as in 19276 dereferencing an invalid pointer location. 19277 19278_sibling calls_ 19279 Sibling calls or tail calls terminate the function in a 19280 non-standard way and thus an edge to the exit must be present. 19281 'EDGE_SIBCALL' and 'EDGE_ABNORMAL' are set in such case. These 19282 edges only exist in the RTL representation. 19283 19284_computed jumps_ 19285 Computed jumps contain edges to all labels in the function 19286 referenced from the code. All those edges have 'EDGE_ABNORMAL' 19287 flag set. The edges used to represent computed jumps often cause 19288 compile time performance problems, since functions consisting of 19289 many taken labels and many computed jumps may have _very_ dense 19290 flow graphs, so these edges need to be handled with special care. 19291 During the earlier stages of the compilation process, GCC tries to 19292 avoid such dense flow graphs by factoring computed jumps. For 19293 example, given the following series of jumps, 19294 19295 goto *x; 19296 [ ... ] 19297 19298 goto *x; 19299 [ ... ] 19300 19301 goto *x; 19302 [ ... ] 19303 19304 factoring the computed jumps results in the following code sequence 19305 which has a much simpler flow graph: 19306 19307 goto y; 19308 [ ... ] 19309 19310 goto y; 19311 [ ... ] 19312 19313 goto y; 19314 [ ... ] 19315 19316 y: 19317 goto *x; 19318 19319 However, the classic problem with this transformation is that it 19320 has a runtime cost in there resulting code: An extra jump. 19321 Therefore, the computed jumps are un-factored in the later passes 19322 of the compiler (in the pass called 19323 'pass_duplicate_computed_gotos'). Be aware of that when you work 19324 on passes in that area. There have been numerous examples already 19325 where the compile time for code with unfactored computed jumps 19326 caused some serious headaches. 19327 19328_nonlocal goto handlers_ 19329 GCC allows nested functions to return into caller using a 'goto' to 19330 a label passed to as an argument to the callee. The labels passed 19331 to nested functions contain special code to cleanup after function 19332 call. Such sections of code are referred to as "nonlocal goto 19333 receivers". If a function contains such nonlocal goto receivers, 19334 an edge from the call to the label is created with the 19335 'EDGE_ABNORMAL' and 'EDGE_ABNORMAL_CALL' flags set. 19336 19337_function entry points_ 19338 By definition, execution of function starts at basic block 0, so 19339 there is always an edge from the 'ENTRY_BLOCK_PTR' to basic block 19340 0. There is no 'GIMPLE' representation for alternate entry points 19341 at this moment. In RTL, alternate entry points are specified by 19342 'CODE_LABEL' with 'LABEL_ALTERNATE_NAME' defined. This feature is 19343 currently used for multiple entry point prologues and is limited to 19344 post-reload passes only. This can be used by back-ends to emit 19345 alternate prologues for functions called from different contexts. 19346 In future full support for multiple entry functions defined by 19347 Fortran 90 needs to be implemented. 19348 19349_function exits_ 19350 In the pre-reload representation a function terminates after the 19351 last instruction in the insn chain and no explicit return 19352 instructions are used. This corresponds to the fall-thru edge into 19353 exit block. After reload, optimal RTL epilogues are used that use 19354 explicit (conditional) return instructions that are represented by 19355 edges with no flags set. 19356 19357 19358File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow 19359 1936015.3 Profile information 19361======================== 19362 19363In many cases a compiler must make a choice whether to trade speed in 19364one part of code for speed in another, or to trade code size for code 19365speed. In such cases it is useful to know information about how often 19366some given block will be executed. That is the purpose for maintaining 19367profile within the flow graph. GCC can handle profile information 19368obtained through "profile feedback", but it can also estimate branch 19369probabilities based on statics and heuristics. 19370 19371 The feedback based profile is produced by compiling the program with 19372instrumentation, executing it on a train run and reading the numbers of 19373executions of basic blocks and edges back to the compiler while 19374re-compiling the program to produce the final executable. This method 19375provides very accurate information about where a program spends most of 19376its time on the train run. Whether it matches the average run of course 19377depends on the choice of train data set, but several studies have shown 19378that the behavior of a program usually changes just marginally over 19379different data sets. 19380 19381 When profile feedback is not available, the compiler may be asked to 19382attempt to predict the behavior of each branch in the program using a 19383set of heuristics (see 'predict.def' for details) and compute estimated 19384frequencies of each basic block by propagating the probabilities over 19385the graph. 19386 19387 Each 'basic_block' contains two integer fields to represent profile 19388information: 'frequency' and 'count'. The 'frequency' is an estimation 19389how often is basic block executed within a function. It is represented 19390as an integer scaled in the range from 0 to 'BB_FREQ_BASE'. The most 19391frequently executed basic block in function is initially set to 19392'BB_FREQ_BASE' and the rest of frequencies are scaled accordingly. 19393During optimization, the frequency of the most frequent basic block can 19394both decrease (for instance by loop unrolling) or grow (for instance by 19395cross-jumping optimization), so scaling sometimes has to be performed 19396multiple times. 19397 19398 The 'count' contains hard-counted numbers of execution measured during 19399training runs and is nonzero only when profile feedback is available. 19400This value is represented as the host's widest integer (typically a 64 19401bit integer) of the special type 'gcov_type'. 19402 19403 Most optimization passes can use only the frequency information of a 19404basic block, but a few passes may want to know hard execution counts. 19405The frequencies should always match the counts after scaling, however 19406during updating of the profile information numerical error may 19407accumulate into quite large errors. 19408 19409 Each edge also contains a branch probability field: an integer in the 19410range from 0 to 'REG_BR_PROB_BASE'. It represents probability of 19411passing control from the end of the 'src' basic block to the 'dest' 19412basic block, i.e. the probability that control will flow along this 19413edge. The 'EDGE_FREQUENCY' macro is available to compute how frequently 19414a given edge is taken. There is a 'count' field for each edge as well, 19415representing same information as for a basic block. 19416 19417 The basic block frequencies are not represented in the instruction 19418stream, but in the RTL representation the edge frequencies are 19419represented for conditional jumps (via the 'REG_BR_PROB' macro) since 19420they are used when instructions are output to the assembly file and the 19421flow graph is no longer maintained. 19422 19423 The probability that control flow arrives via a given edge to its 19424destination basic block is called "reverse probability" and is not 19425directly represented, but it may be easily computed from frequencies of 19426basic blocks. 19427 19428 Updating profile information is a delicate task that can unfortunately 19429not be easily integrated with the CFG manipulation API. Many of the 19430functions and hooks to modify the CFG, such as 19431'redirect_edge_and_branch', do not have enough information to easily 19432update the profile, so updating it is in the majority of cases left up 19433to the caller. It is difficult to uncover bugs in the profile updating 19434code, because they manifest themselves only by producing worse code, and 19435checking profile consistency is not possible because of numeric error 19436accumulation. Hence special attention needs to be given to this issue 19437in each pass that modifies the CFG. 19438 19439 It is important to point out that 'REG_BR_PROB_BASE' and 'BB_FREQ_BASE' 19440are both set low enough to be possible to compute second power of any 19441frequency or probability in the flow graph, it is not possible to even 19442square the 'count' field, as modern CPUs are fast enough to execute 19443$2^32$ operations quickly. 19444 19445 19446File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow 19447 1944815.4 Maintaining the CFG 19449======================== 19450 19451An important task of each compiler pass is to keep both the control flow 19452graph and all profile information up-to-date. Reconstruction of the 19453control flow graph after each pass is not an option, since it may be 19454very expensive and lost profile information cannot be reconstructed at 19455all. 19456 19457 GCC has two major intermediate representations, and both use the 19458'basic_block' and 'edge' data types to represent control flow. Both 19459representations share as much of the CFG maintenance code as possible. 19460For each representation, a set of "hooks" is defined so that each 19461representation can provide its own implementation of CFG manipulation 19462routines when necessary. These hooks are defined in 'cfghooks.h'. 19463There are hooks for almost all common CFG manipulations, including block 19464splitting and merging, edge redirection and creating and deleting basic 19465blocks. These hooks should provide everything you need to maintain and 19466manipulate the CFG in both the RTL and 'GIMPLE' representation. 19467 19468 At the moment, the basic block boundaries are maintained transparently 19469when modifying instructions, so there rarely is a need to move them 19470manually (such as in case someone wants to output instruction outside 19471basic block explicitly). 19472 19473 In the RTL representation, each instruction has a 'BLOCK_FOR_INSN' 19474value that represents pointer to the basic block that contains the 19475instruction. In the 'GIMPLE' representation, the function 'gimple_bb' 19476returns a pointer to the basic block containing the queried statement. 19477 19478 When changes need to be applied to a function in its 'GIMPLE' 19479representation, "GIMPLE statement iterators" should be used. These 19480iterators provide an integrated abstraction of the flow graph and the 19481instruction stream. Block statement iterators are constructed using the 19482'gimple_stmt_iterator' data structure and several modifiers are 19483available, including the following: 19484 19485'gsi_start' 19486 This function initializes a 'gimple_stmt_iterator' that points to 19487 the first non-empty statement in a basic block. 19488 19489'gsi_last' 19490 This function initializes a 'gimple_stmt_iterator' that points to 19491 the last statement in a basic block. 19492 19493'gsi_end_p' 19494 This predicate is 'true' if a 'gimple_stmt_iterator' represents the 19495 end of a basic block. 19496 19497'gsi_next' 19498 This function takes a 'gimple_stmt_iterator' and makes it point to 19499 its successor. 19500 19501'gsi_prev' 19502 This function takes a 'gimple_stmt_iterator' and makes it point to 19503 its predecessor. 19504 19505'gsi_insert_after' 19506 This function inserts a statement after the 'gimple_stmt_iterator' 19507 passed in. The final parameter determines whether the statement 19508 iterator is updated to point to the newly inserted statement, or 19509 left pointing to the original statement. 19510 19511'gsi_insert_before' 19512 This function inserts a statement before the 'gimple_stmt_iterator' 19513 passed in. The final parameter determines whether the statement 19514 iterator is updated to point to the newly inserted statement, or 19515 left pointing to the original statement. 19516 19517'gsi_remove' 19518 This function removes the 'gimple_stmt_iterator' passed in and 19519 rechains the remaining statements in a basic block, if any. 19520 19521 In the RTL representation, the macros 'BB_HEAD' and 'BB_END' may be 19522used to get the head and end 'rtx' of a basic block. No abstract 19523iterators are defined for traversing the insn chain, but you can just 19524use 'NEXT_INSN' and 'PREV_INSN' instead. *Note Insns::. 19525 19526 Usually a code manipulating pass simplifies the instruction stream and 19527the flow of control, possibly eliminating some edges. This may for 19528example happen when a conditional jump is replaced with an unconditional 19529jump. Updating of edges is not transparent and each optimization pass 19530is required to do so manually. However only few cases occur in 19531practice. The pass may call 'purge_dead_edges' on a given basic block 19532to remove superfluous edges, if any. 19533 19534 Another common scenario is redirection of branch instructions, but this 19535is best modeled as redirection of edges in the control flow graph and 19536thus use of 'redirect_edge_and_branch' is preferred over more low level 19537functions, such as 'redirect_jump' that operate on RTL chain only. The 19538CFG hooks defined in 'cfghooks.h' should provide the complete API 19539required for manipulating and maintaining the CFG. 19540 19541 It is also possible that a pass has to insert control flow instruction 19542into the middle of a basic block, thus creating an entry point in the 19543middle of the basic block, which is impossible by definition: The block 19544must be split to make sure it only has one entry point, i.e. the head of 19545the basic block. The CFG hook 'split_block' may be used when an 19546instruction in the middle of a basic block has to become the target of a 19547jump or branch instruction. 19548 19549 For a global optimizer, a common operation is to split edges in the 19550flow graph and insert instructions on them. In the RTL representation, 19551this can be easily done using the 'insert_insn_on_edge' function that 19552emits an instruction "on the edge", caching it for a later 19553'commit_edge_insertions' call that will take care of moving the inserted 19554instructions off the edge into the instruction stream contained in a 19555basic block. This includes the creation of new basic blocks where 19556needed. In the 'GIMPLE' representation, the equivalent functions are 19557'gsi_insert_on_edge' which inserts a block statement iterator on an 19558edge, and 'gsi_commit_edge_inserts' which flushes the instruction to 19559actual instruction stream. 19560 19561 While debugging the optimization pass, the 'verify_flow_info' function 19562may be useful to find bugs in the control flow graph updating code. 19563 19564 19565File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow 19566 1956715.5 Liveness information 19568========================= 19569 19570Liveness information is useful to determine whether some register is 19571"live" at given point of program, i.e. that it contains a value that may 19572be used at a later point in the program. This information is used, for 19573instance, during register allocation, as the pseudo registers only need 19574to be assigned to a unique hard register or to a stack slot if they are 19575live. The hard registers and stack slots may be freely reused for other 19576values when a register is dead. 19577 19578 Liveness information is available in the back end starting with 19579'pass_df_initialize' and ending with 'pass_df_finish'. Three flavors of 19580live analysis are available: With 'LR', it is possible to determine at 19581any point 'P' in the function if the register may be used on some path 19582from 'P' to the end of the function. With 'UR', it is possible to 19583determine if there is a path from the beginning of the function to 'P' 19584that defines the variable. 'LIVE' is the intersection of the 'LR' and 19585'UR' and a variable is live at 'P' if there is both an assignment that 19586reaches it from the beginning of the function and a use that can be 19587reached on some path from 'P' to the end of the function. 19588 19589 In general 'LIVE' is the most useful of the three. The macros 19590'DF_[LR,UR,LIVE]_[IN,OUT]' can be used to access this information. The 19591macros take a basic block number and return a bitmap that is indexed by 19592the register number. This information is only guaranteed to be up to 19593date after calls are made to 'df_analyze'. See the file 'df-core.c' for 19594details on using the dataflow. 19595 19596 The liveness information is stored partly in the RTL instruction stream 19597and partly in the flow graph. Local information is stored in the 19598instruction stream: Each instruction may contain 'REG_DEAD' notes 19599representing that the value of a given register is no longer needed, or 19600'REG_UNUSED' notes representing that the value computed by the 19601instruction is never used. The second is useful for instructions 19602computing multiple values at once. 19603 19604 19605File: gccint.info, Node: Loop Analysis and Representation, Next: Machine Desc, Prev: Control Flow, Up: Top 19606 1960716 Analysis and Representation of Loops 19608*************************************** 19609 19610GCC provides extensive infrastructure for work with natural loops, i.e., 19611strongly connected components of CFG with only one entry block. This 19612chapter describes representation of loops in GCC, both on GIMPLE and in 19613RTL, as well as the interfaces to loop-related analyses (induction 19614variable analysis and number of iterations analysis). 19615 19616* Menu: 19617 19618* Loop representation:: Representation and analysis of loops. 19619* Loop querying:: Getting information about loops. 19620* Loop manipulation:: Loop manipulation functions. 19621* LCSSA:: Loop-closed SSA form. 19622* Scalar evolutions:: Induction variables on GIMPLE. 19623* loop-iv:: Induction variables on RTL. 19624* Number of iterations:: Number of iterations analysis. 19625* Dependency analysis:: Data dependency analysis. 19626 19627 19628File: gccint.info, Node: Loop representation, Next: Loop querying, Up: Loop Analysis and Representation 19629 1963016.1 Loop representation 19631======================== 19632 19633This chapter describes the representation of loops in GCC, and functions 19634that can be used to build, modify and analyze this representation. Most 19635of the interfaces and data structures are declared in 'cfgloop.h'. Loop 19636structures are analyzed and this information disposed or updated at the 19637discretion of individual passes. Still most of the generic CFG 19638manipulation routines are aware of loop structures and try to keep them 19639up-to-date. By this means an increasing part of the compilation 19640pipeline is setup to maintain loop structure across passes to allow 19641attaching meta information to individual loops for consumption by later 19642passes. 19643 19644 In general, a natural loop has one entry block (header) and possibly 19645several back edges (latches) leading to the header from the inside of 19646the loop. Loops with several latches may appear if several loops share 19647a single header, or if there is a branching in the middle of the loop. 19648The representation of loops in GCC however allows only loops with a 19649single latch. During loop analysis, headers of such loops are split and 19650forwarder blocks are created in order to disambiguate their structures. 19651Heuristic based on profile information and structure of the induction 19652variables in the loops is used to determine whether the latches 19653correspond to sub-loops or to control flow in a single loop. This means 19654that the analysis sometimes changes the CFG, and if you run it in the 19655middle of an optimization pass, you must be able to deal with the new 19656blocks. You may avoid CFG changes by passing 19657'LOOPS_MAY_HAVE_MULTIPLE_LATCHES' flag to the loop discovery, note 19658however that most other loop manipulation functions will not work 19659correctly for loops with multiple latch edges (the functions that only 19660query membership of blocks to loops and subloop relationships, or 19661enumerate and test loop exits, can be expected to work). 19662 19663 Body of the loop is the set of blocks that are dominated by its header, 19664and reachable from its latch against the direction of edges in CFG. The 19665loops are organized in a containment hierarchy (tree) such that all the 19666loops immediately contained inside loop L are the children of L in the 19667tree. This tree is represented by the 'struct loops' structure. The 19668root of this tree is a fake loop that contains all blocks in the 19669function. Each of the loops is represented in a 'struct loop' 19670structure. Each loop is assigned an index ('num' field of the 'struct 19671loop' structure), and the pointer to the loop is stored in the 19672corresponding field of the 'larray' vector in the loops structure. The 19673indices do not have to be continuous, there may be empty ('NULL') 19674entries in the 'larray' created by deleting loops. Also, there is no 19675guarantee on the relative order of a loop and its subloops in the 19676numbering. The index of a loop never changes. 19677 19678 The entries of the 'larray' field should not be accessed directly. The 19679function 'get_loop' returns the loop description for a loop with the 19680given index. 'number_of_loops' function returns number of loops in the 19681function. To traverse all loops, use 'FOR_EACH_LOOP' macro. The 19682'flags' argument of the macro is used to determine the direction of 19683traversal and the set of loops visited. Each loop is guaranteed to be 19684visited exactly once, regardless of the changes to the loop tree, and 19685the loops may be removed during the traversal. The newly created loops 19686are never traversed, if they need to be visited, this must be done 19687separately after their creation. The 'FOR_EACH_LOOP' macro allocates 19688temporary variables. If the 'FOR_EACH_LOOP' loop were ended using break 19689or goto, they would not be released; 'FOR_EACH_LOOP_BREAK' macro must be 19690used instead. 19691 19692 Each basic block contains the reference to the innermost loop it 19693belongs to ('loop_father'). For this reason, it is only possible to 19694have one 'struct loops' structure initialized at the same time for each 19695CFG. The global variable 'current_loops' contains the 'struct loops' 19696structure. Many of the loop manipulation functions assume that 19697dominance information is up-to-date. 19698 19699 The loops are analyzed through 'loop_optimizer_init' function. The 19700argument of this function is a set of flags represented in an integer 19701bitmask. These flags specify what other properties of the loop 19702structures should be calculated/enforced and preserved later: 19703 19704 * 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES': If this flag is set, no changes 19705 to CFG will be performed in the loop analysis, in particular, loops 19706 with multiple latch edges will not be disambiguated. If a loop has 19707 multiple latches, its latch block is set to NULL. Most of the loop 19708 manipulation functions will not work for loops in this shape. No 19709 other flags that require CFG changes can be passed to 19710 loop_optimizer_init. 19711 * 'LOOPS_HAVE_PREHEADERS': Forwarder blocks are created in such a way 19712 that each loop has only one entry edge, and additionally, the 19713 source block of this entry edge has only one successor. This 19714 creates a natural place where the code can be moved out of the 19715 loop, and ensures that the entry edge of the loop leads from its 19716 immediate super-loop. 19717 * 'LOOPS_HAVE_SIMPLE_LATCHES': Forwarder blocks are created to force 19718 the latch block of each loop to have only one successor. This 19719 ensures that the latch of the loop does not belong to any of its 19720 sub-loops, and makes manipulation with the loops significantly 19721 easier. Most of the loop manipulation functions assume that the 19722 loops are in this shape. Note that with this flag, the "normal" 19723 loop without any control flow inside and with one exit consists of 19724 two basic blocks. 19725 * 'LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS': Basic blocks and edges in 19726 the strongly connected components that are not natural loops (have 19727 more than one entry block) are marked with 'BB_IRREDUCIBLE_LOOP' 19728 and 'EDGE_IRREDUCIBLE_LOOP' flags. The flag is not set for blocks 19729 and edges that belong to natural loops that are in such an 19730 irreducible region (but it is set for the entry and exit edges of 19731 such a loop, if they lead to/from this region). 19732 * 'LOOPS_HAVE_RECORDED_EXITS': The lists of exits are recorded and 19733 updated for each loop. This makes some functions (e.g., 19734 'get_loop_exit_edges') more efficient. Some functions (e.g., 19735 'single_exit') can be used only if the lists of exits are recorded. 19736 19737 These properties may also be computed/enforced later, using functions 19738'create_preheaders', 'force_single_succ_latches', 19739'mark_irreducible_loops' and 'record_loop_exits'. The properties can be 19740queried using 'loops_state_satisfies_p'. 19741 19742 The memory occupied by the loops structures should be freed with 19743'loop_optimizer_finalize' function. When loop structures are setup to 19744be preserved across passes this function reduces the information to be 19745kept up-to-date to a minimum (only 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES' 19746set). 19747 19748 The CFG manipulation functions in general do not update loop 19749structures. Specialized versions that additionally do so are provided 19750for the most common tasks. On GIMPLE, 'cleanup_tree_cfg_loop' function 19751can be used to cleanup CFG while updating the loops structures if 19752'current_loops' is set. 19753 19754 At the moment loop structure is preserved from the start of GIMPLE loop 19755optimizations until the end of RTL loop optimizations. During this time 19756a loop can be tracked by its 'struct loop' and number. 19757 19758 19759File: gccint.info, Node: Loop querying, Next: Loop manipulation, Prev: Loop representation, Up: Loop Analysis and Representation 19760 1976116.2 Loop querying 19762================== 19763 19764The functions to query the information about loops are declared in 19765'cfgloop.h'. Some of the information can be taken directly from the 19766structures. 'loop_father' field of each basic block contains the 19767innermost loop to that the block belongs. The most useful fields of 19768loop structure (that are kept up-to-date at all times) are: 19769 19770 * 'header', 'latch': Header and latch basic blocks of the loop. 19771 * 'num_nodes': Number of basic blocks in the loop (including the 19772 basic blocks of the sub-loops). 19773 * 'outer', 'inner', 'next': The super-loop, the first sub-loop, and 19774 the sibling of the loop in the loops tree. 19775 19776 There are other fields in the loop structures, many of them used only 19777by some of the passes, or not updated during CFG changes; in general, 19778they should not be accessed directly. 19779 19780 The most important functions to query loop structures are: 19781 19782 * 'loop_depth': The depth of the loop in the loops tree, i.e., the 19783 number of super-loops of the loop. 19784 * 'flow_loops_dump': Dumps the information about loops to a file. 19785 * 'verify_loop_structure': Checks consistency of the loop structures. 19786 * 'loop_latch_edge': Returns the latch edge of a loop. 19787 * 'loop_preheader_edge': If loops have preheaders, returns the 19788 preheader edge of a loop. 19789 * 'flow_loop_nested_p': Tests whether loop is a sub-loop of another 19790 loop. 19791 * 'flow_bb_inside_loop_p': Tests whether a basic block belongs to a 19792 loop (including its sub-loops). 19793 * 'find_common_loop': Finds the common super-loop of two loops. 19794 * 'superloop_at_depth': Returns the super-loop of a loop with the 19795 given depth. 19796 * 'tree_num_loop_insns', 'num_loop_insns': Estimates the number of 19797 insns in the loop, on GIMPLE and on RTL. 19798 * 'loop_exit_edge_p': Tests whether edge is an exit from a loop. 19799 * 'mark_loop_exit_edges': Marks all exit edges of all loops with 19800 'EDGE_LOOP_EXIT' flag. 19801 * 'get_loop_body', 'get_loop_body_in_dom_order', 19802 'get_loop_body_in_bfs_order': Enumerates the basic blocks in the 19803 loop in depth-first search order in reversed CFG, ordered by 19804 dominance relation, and breath-first search order, respectively. 19805 * 'single_exit': Returns the single exit edge of the loop, or 'NULL' 19806 if the loop has more than one exit. You can only use this function 19807 if LOOPS_HAVE_MARKED_SINGLE_EXITS property is used. 19808 * 'get_loop_exit_edges': Enumerates the exit edges of a loop. 19809 * 'just_once_each_iteration_p': Returns true if the basic block is 19810 executed exactly once during each iteration of a loop (that is, it 19811 does not belong to a sub-loop, and it dominates the latch of the 19812 loop). 19813 19814 19815File: gccint.info, Node: Loop manipulation, Next: LCSSA, Prev: Loop querying, Up: Loop Analysis and Representation 19816 1981716.3 Loop manipulation 19818====================== 19819 19820The loops tree can be manipulated using the following functions: 19821 19822 * 'flow_loop_tree_node_add': Adds a node to the tree. 19823 * 'flow_loop_tree_node_remove': Removes a node from the tree. 19824 * 'add_bb_to_loop': Adds a basic block to a loop. 19825 * 'remove_bb_from_loops': Removes a basic block from loops. 19826 19827 Most low-level CFG functions update loops automatically. The following 19828functions handle some more complicated cases of CFG manipulations: 19829 19830 * 'remove_path': Removes an edge and all blocks it dominates. 19831 * 'split_loop_exit_edge': Splits exit edge of the loop, ensuring that 19832 PHI node arguments remain in the loop (this ensures that 19833 loop-closed SSA form is preserved). Only useful on GIMPLE. 19834 19835 Finally, there are some higher-level loop transformations implemented. 19836While some of them are written so that they should work on non-innermost 19837loops, they are mostly untested in that case, and at the moment, they 19838are only reliable for the innermost loops: 19839 19840 * 'create_iv': Creates a new induction variable. Only works on 19841 GIMPLE. 'standard_iv_increment_position' can be used to find a 19842 suitable place for the iv increment. 19843 * 'duplicate_loop_to_header_edge', 19844 'tree_duplicate_loop_to_header_edge': These functions (on RTL and 19845 on GIMPLE) duplicate the body of the loop prescribed number of 19846 times on one of the edges entering loop header, thus performing 19847 either loop unrolling or loop peeling. 'can_duplicate_loop_p' 19848 ('can_unroll_loop_p' on GIMPLE) must be true for the duplicated 19849 loop. 19850 * 'loop_version': This function creates a copy of a loop, and a 19851 branch before them that selects one of them depending on the 19852 prescribed condition. This is useful for optimizations that need 19853 to verify some assumptions in runtime (one of the copies of the 19854 loop is usually left unchanged, while the other one is transformed 19855 in some way). 19856 * 'tree_unroll_loop': Unrolls the loop, including peeling the extra 19857 iterations to make the number of iterations divisible by unroll 19858 factor, updating the exit condition, and removing the exits that 19859 now cannot be taken. Works only on GIMPLE. 19860 19861 19862File: gccint.info, Node: LCSSA, Next: Scalar evolutions, Prev: Loop manipulation, Up: Loop Analysis and Representation 19863 1986416.4 Loop-closed SSA form 19865========================= 19866 19867Throughout the loop optimizations on tree level, one extra condition is 19868enforced on the SSA form: No SSA name is used outside of the loop in 19869that it is defined. The SSA form satisfying this condition is called 19870"loop-closed SSA form" - LCSSA. To enforce LCSSA, PHI nodes must be 19871created at the exits of the loops for the SSA names that are used 19872outside of them. Only the real operands (not virtual SSA names) are 19873held in LCSSA, in order to save memory. 19874 19875 There are various benefits of LCSSA: 19876 19877 * Many optimizations (value range analysis, final value replacement) 19878 are interested in the values that are defined in the loop and used 19879 outside of it, i.e., exactly those for that we create new PHI 19880 nodes. 19881 * In induction variable analysis, it is not necessary to specify the 19882 loop in that the analysis should be performed - the scalar 19883 evolution analysis always returns the results with respect to the 19884 loop in that the SSA name is defined. 19885 * It makes updating of SSA form during loop transformations simpler. 19886 Without LCSSA, operations like loop unrolling may force creation of 19887 PHI nodes arbitrarily far from the loop, while in LCSSA, the SSA 19888 form can be updated locally. However, since we only keep real 19889 operands in LCSSA, we cannot use this advantage (we could have 19890 local updating of real operands, but it is not much more efficient 19891 than to use generic SSA form updating for it as well; the amount of 19892 changes to SSA is the same). 19893 19894 However, it also means LCSSA must be updated. This is usually 19895straightforward, unless you create a new value in loop and use it 19896outside, or unless you manipulate loop exit edges (functions are 19897provided to make these manipulations simple). 19898'rewrite_into_loop_closed_ssa' is used to rewrite SSA form to LCSSA, and 19899'verify_loop_closed_ssa' to check that the invariant of LCSSA is 19900preserved. 19901 19902 19903File: gccint.info, Node: Scalar evolutions, Next: loop-iv, Prev: LCSSA, Up: Loop Analysis and Representation 19904 1990516.5 Scalar evolutions 19906====================== 19907 19908Scalar evolutions (SCEV) are used to represent results of induction 19909variable analysis on GIMPLE. They enable us to represent variables with 19910complicated behavior in a simple and consistent way (we only use it to 19911express values of polynomial induction variables, but it is possible to 19912extend it). The interfaces to SCEV analysis are declared in 19913'tree-scalar-evolution.h'. To use scalar evolutions analysis, 19914'scev_initialize' must be used. To stop using SCEV, 'scev_finalize' 19915should be used. SCEV analysis caches results in order to save time and 19916memory. This cache however is made invalid by most of the loop 19917transformations, including removal of code. If such a transformation is 19918performed, 'scev_reset' must be called to clean the caches. 19919 19920 Given an SSA name, its behavior in loops can be analyzed using the 19921'analyze_scalar_evolution' function. The returned SCEV however does not 19922have to be fully analyzed and it may contain references to other SSA 19923names defined in the loop. To resolve these (potentially recursive) 19924references, 'instantiate_parameters' or 'resolve_mixers' functions must 19925be used. 'instantiate_parameters' is useful when you use the results of 19926SCEV only for some analysis, and when you work with whole nest of loops 19927at once. It will try replacing all SSA names by their SCEV in all 19928loops, including the super-loops of the current loop, thus providing a 19929complete information about the behavior of the variable in the loop 19930nest. 'resolve_mixers' is useful if you work with only one loop at a 19931time, and if you possibly need to create code based on the value of the 19932induction variable. It will only resolve the SSA names defined in the 19933current loop, leaving the SSA names defined outside unchanged, even if 19934their evolution in the outer loops is known. 19935 19936 The SCEV is a normal tree expression, except for the fact that it may 19937contain several special tree nodes. One of them is 'SCEV_NOT_KNOWN', 19938used for SSA names whose value cannot be expressed. The other one is 19939'POLYNOMIAL_CHREC'. Polynomial chrec has three arguments - base, step 19940and loop (both base and step may contain further polynomial chrecs). 19941Type of the expression and of base and step must be the same. A 19942variable has evolution 'POLYNOMIAL_CHREC(base, step, loop)' if it is (in 19943the specified loop) equivalent to 'x_1' in the following example 19944 19945 while (...) 19946 { 19947 x_1 = phi (base, x_2); 19948 x_2 = x_1 + step; 19949 } 19950 19951 Note that this includes the language restrictions on the operations. 19952For example, if we compile C code and 'x' has signed type, then the 19953overflow in addition would cause undefined behavior, and we may assume 19954that this does not happen. Hence, the value with this SCEV cannot 19955overflow (which restricts the number of iterations of such a loop). 19956 19957 In many cases, one wants to restrict the attention just to affine 19958induction variables. In this case, the extra expressive power of SCEV 19959is not useful, and may complicate the optimizations. In this case, 19960'simple_iv' function may be used to analyze a value - the result is a 19961loop-invariant base and step. 19962 19963 19964File: gccint.info, Node: loop-iv, Next: Number of iterations, Prev: Scalar evolutions, Up: Loop Analysis and Representation 19965 1996616.6 IV analysis on RTL 19967======================= 19968 19969The induction variable on RTL is simple and only allows analysis of 19970affine induction variables, and only in one loop at once. The interface 19971is declared in 'cfgloop.h'. Before analyzing induction variables in a 19972loop L, 'iv_analysis_loop_init' function must be called on L. After the 19973analysis (possibly calling 'iv_analysis_loop_init' for several loops) is 19974finished, 'iv_analysis_done' should be called. The following functions 19975can be used to access the results of the analysis: 19976 19977 * 'iv_analyze': Analyzes a single register used in the given insn. 19978 If no use of the register in this insn is found, the following 19979 insns are scanned, so that this function can be called on the insn 19980 returned by get_condition. 19981 * 'iv_analyze_result': Analyzes result of the assignment in the given 19982 insn. 19983 * 'iv_analyze_expr': Analyzes a more complicated expression. All its 19984 operands are analyzed by 'iv_analyze', and hence they must be used 19985 in the specified insn or one of the following insns. 19986 19987 The description of the induction variable is provided in 'struct 19988rtx_iv'. In order to handle subregs, the representation is a bit 19989complicated; if the value of the 'extend' field is not 'UNKNOWN', the 19990value of the induction variable in the i-th iteration is 19991 19992 delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)), 19993 19994 with the following exception: if 'first_special' is true, then the 19995value in the first iteration (when 'i' is zero) is 'delta + mult * 19996base'. However, if 'extend' is equal to 'UNKNOWN', then 'first_special' 19997must be false, 'delta' 0, 'mult' 1 and the value in the i-th iteration 19998is 19999 20000 subreg_{mode} (base + i * step) 20001 20002 The function 'get_iv_value' can be used to perform these calculations. 20003 20004 20005File: gccint.info, Node: Number of iterations, Next: Dependency analysis, Prev: loop-iv, Up: Loop Analysis and Representation 20006 2000716.7 Number of iterations analysis 20008================================== 20009 20010Both on GIMPLE and on RTL, there are functions available to determine 20011the number of iterations of a loop, with a similar interface. The 20012number of iterations of a loop in GCC is defined as the number of 20013executions of the loop latch. In many cases, it is not possible to 20014determine the number of iterations unconditionally - the determined 20015number is correct only if some assumptions are satisfied. The analysis 20016tries to verify these conditions using the information contained in the 20017program; if it fails, the conditions are returned together with the 20018result. The following information and conditions are provided by the 20019analysis: 20020 20021 * 'assumptions': If this condition is false, the rest of the 20022 information is invalid. 20023 * 'noloop_assumptions' on RTL, 'may_be_zero' on GIMPLE: If this 20024 condition is true, the loop exits in the first iteration. 20025 * 'infinite': If this condition is true, the loop is infinite. This 20026 condition is only available on RTL. On GIMPLE, conditions for 20027 finiteness of the loop are included in 'assumptions'. 20028 * 'niter_expr' on RTL, 'niter' on GIMPLE: The expression that gives 20029 number of iterations. The number of iterations is defined as the 20030 number of executions of the loop latch. 20031 20032 Both on GIMPLE and on RTL, it necessary for the induction variable 20033analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL). 20034On GIMPLE, the results are stored to 'struct tree_niter_desc' structure. 20035Number of iterations before the loop is exited through a given exit can 20036be determined using 'number_of_iterations_exit' function. On RTL, the 20037results are returned in 'struct niter_desc' structure. The 20038corresponding function is named 'check_simple_exit'. There are also 20039functions that pass through all the exits of a loop and try to find one 20040with easy to determine number of iterations - 'find_loop_niter' on 20041GIMPLE and 'find_simple_exit' on RTL. Finally, there are functions that 20042provide the same information, but additionally cache it, so that 20043repeated calls to number of iterations are not so costly - 20044'number_of_latch_executions' on GIMPLE and 'get_simple_loop_desc' on 20045RTL. 20046 20047 Note that some of these functions may behave slightly differently than 20048others - some of them return only the expression for the number of 20049iterations, and fail if there are some assumptions. The function 20050'number_of_latch_executions' works only for single-exit loops. The 20051function 'number_of_cond_exit_executions' can be used to determine 20052number of executions of the exit condition of a single-exit loop (i.e., 20053the 'number_of_latch_executions' increased by one). 20054 20055 On GIMPLE, below constraint flags affect semantics of some APIs of 20056number of iterations analyzer: 20057 20058 * 'LOOP_C_INFINITE': If this constraint flag is set, the loop is 20059 known to be infinite. APIs like 'number_of_iterations_exit' can 20060 return false directly without doing any analysis. 20061 * 'LOOP_C_FINITE': If this constraint flag is set, the loop is known 20062 to be finite, in other words, loop's number of iterations can be 20063 computed with 'assumptions' be true. 20064 20065 Generally, the constraint flags are set/cleared by consumers which are 20066loop optimizers. It's also the consumers' responsibility to set/clear 20067constraints correctly. Failing to do that might result in hard to track 20068down bugs in scev/niter consumers. One typical use case is vectorizer: 20069it drives number of iterations analyzer by setting 'LOOP_C_FINITE' and 20070vectorizes possibly infinite loop by versioning loop with analysis 20071result. In return, constraints set by consumers can also help number of 20072iterations analyzer in following optimizers. For example, 'niter' of a 20073loop versioned under 'assumptions' is valid unconditionally. 20074 20075 Other constraints may be added in the future, for example, a constraint 20076indicating that loops' latch must roll thus 'may_be_zero' would be false 20077unconditionally. 20078 20079 20080File: gccint.info, Node: Dependency analysis, Prev: Number of iterations, Up: Loop Analysis and Representation 20081 2008216.8 Data Dependency Analysis 20083============================= 20084 20085The code for the data dependence analysis can be found in 20086'tree-data-ref.c' and its interface and data structures are described in 20087'tree-data-ref.h'. The function that computes the data dependences for 20088all the array and pointer references for a given loop is 20089'compute_data_dependences_for_loop'. This function is currently used by 20090the linear loop transform and the vectorization passes. Before calling 20091this function, one has to allocate two vectors: a first vector will 20092contain the set of data references that are contained in the analyzed 20093loop body, and the second vector will contain the dependence relations 20094between the data references. Thus if the vector of data references is 20095of size 'n', the vector containing the dependence relations will contain 20096'n*n' elements. However if the analyzed loop contains side effects, 20097such as calls that potentially can interfere with the data references in 20098the current analyzed loop, the analysis stops while scanning the loop 20099body for data references, and inserts a single 'chrec_dont_know' in the 20100dependence relation array. 20101 20102 The data references are discovered in a particular order during the 20103scanning of the loop body: the loop body is analyzed in execution order, 20104and the data references of each statement are pushed at the end of the 20105data reference array. Two data references syntactically occur in the 20106program in the same order as in the array of data references. This 20107syntactic order is important in some classical data dependence tests, 20108and mapping this order to the elements of this array avoids costly 20109queries to the loop body representation. 20110 20111 Three types of data references are currently handled: ARRAY_REF, 20112INDIRECT_REF and COMPONENT_REF. The data structure for the data 20113reference is 'data_reference', where 'data_reference_p' is a name of a 20114pointer to the data reference structure. The structure contains the 20115following elements: 20116 20117 * 'base_object_info': Provides information about the base object of 20118 the data reference and its access functions. These access 20119 functions represent the evolution of the data reference in the loop 20120 relative to its base, in keeping with the classical meaning of the 20121 data reference access function for the support of arrays. For 20122 example, for a reference 'a.b[i][j]', the base object is 'a.b' and 20123 the access functions, one for each array subscript, are: '{i_init, 20124 + i_step}_1, {j_init, +, j_step}_2'. 20125 20126 * 'first_location_in_loop': Provides information about the first 20127 location accessed by the data reference in the loop and about the 20128 access function used to represent evolution relative to this 20129 location. This data is used to support pointers, and is not used 20130 for arrays (for which we have base objects). Pointer accesses are 20131 represented as a one-dimensional access that starts from the first 20132 location accessed in the loop. For example: 20133 20134 for1 i 20135 for2 j 20136 *((int *)p + i + j) = a[i][j]; 20137 20138 The access function of the pointer access is '{0, + 4B}_for2' 20139 relative to 'p + i'. The access functions of the array are 20140 '{i_init, + i_step}_for1' and '{j_init, +, j_step}_for2' relative 20141 to 'a'. 20142 20143 Usually, the object the pointer refers to is either unknown, or we 20144 cannot prove that the access is confined to the boundaries of a 20145 certain object. 20146 20147 Two data references can be compared only if at least one of these 20148 two representations has all its fields filled for both data 20149 references. 20150 20151 The current strategy for data dependence tests is as follows: If 20152 both 'a' and 'b' are represented as arrays, compare 'a.base_object' 20153 and 'b.base_object'; if they are equal, apply dependence tests (use 20154 access functions based on base_objects). Else if both 'a' and 'b' 20155 are represented as pointers, compare 'a.first_location' and 20156 'b.first_location'; if they are equal, apply dependence tests (use 20157 access functions based on first location). However, if 'a' and 'b' 20158 are represented differently, only try to prove that the bases are 20159 definitely different. 20160 20161 * Aliasing information. 20162 * Alignment information. 20163 20164 The structure describing the relation between two data references is 20165'data_dependence_relation' and the shorter name for a pointer to such a 20166structure is 'ddr_p'. This structure contains: 20167 20168 * a pointer to each data reference, 20169 * a tree node 'are_dependent' that is set to 'chrec_known' if the 20170 analysis has proved that there is no dependence between these two 20171 data references, 'chrec_dont_know' if the analysis was not able to 20172 determine any useful result and potentially there could exist a 20173 dependence between these data references, and 'are_dependent' is 20174 set to 'NULL_TREE' if there exist a dependence relation between the 20175 data references, and the description of this dependence relation is 20176 given in the 'subscripts', 'dir_vects', and 'dist_vects' arrays, 20177 * a boolean that determines whether the dependence relation can be 20178 represented by a classical distance vector, 20179 * an array 'subscripts' that contains a description of each subscript 20180 of the data references. Given two array accesses a subscript is 20181 the tuple composed of the access functions for a given dimension. 20182 For example, given 'A[f1][f2][f3]' and 'B[g1][g2][g3]', there are 20183 three subscripts: '(f1, g1), (f2, g2), (f3, g3)'. 20184 * two arrays 'dir_vects' and 'dist_vects' that contain classical 20185 representations of the data dependences under the form of direction 20186 and distance dependence vectors, 20187 * an array of loops 'loop_nest' that contains the loops to which the 20188 distance and direction vectors refer to. 20189 20190 Several functions for pretty printing the information extracted by the 20191data dependence analysis are available: 'dump_ddrs' prints with a 20192maximum verbosity the details of a data dependence relations array, 20193'dump_dist_dir_vectors' prints only the classical distance and direction 20194vectors for a data dependence relations array, and 20195'dump_data_references' prints the details of the data references 20196contained in a data reference array. 20197 20198 20199File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: Loop Analysis and Representation, Up: Top 20200 2020117 Machine Descriptions 20202*********************** 20203 20204A machine description has two parts: a file of instruction patterns 20205('.md' file) and a C header file of macro definitions. 20206 20207 The '.md' file for a target machine contains a pattern for each 20208instruction that the target machine supports (or at least each 20209instruction that is worth telling the compiler about). It may also 20210contain comments. A semicolon causes the rest of the line to be a 20211comment, unless the semicolon is inside a quoted string. 20212 20213 See the next chapter for information on the C header file. 20214 20215* Menu: 20216 20217* Overview:: How the machine description is used. 20218* Patterns:: How to write instruction patterns. 20219* Example:: An explained example of a 'define_insn' pattern. 20220* RTL Template:: The RTL template defines what insns match a pattern. 20221* Output Template:: The output template says how to make assembler code 20222 from such an insn. 20223* Output Statement:: For more generality, write C code to output 20224 the assembler code. 20225* Predicates:: Controlling what kinds of operands can be used 20226 for an insn. 20227* Constraints:: Fine-tuning operand selection. 20228* Standard Names:: Names mark patterns to use for code generation. 20229* Pattern Ordering:: When the order of patterns makes a difference. 20230* Dependent Patterns:: Having one pattern may make you need another. 20231* Jump Patterns:: Special considerations for patterns for jump insns. 20232* Looping Patterns:: How to define patterns for special looping insns. 20233* Insn Canonicalizations::Canonicalization of Instructions 20234* Expander Definitions::Generating a sequence of several RTL insns 20235 for a standard operation. 20236* Insn Splitting:: Splitting Instructions into Multiple Instructions. 20237* Including Patterns:: Including Patterns in Machine Descriptions. 20238* Peephole Definitions::Defining machine-specific peephole optimizations. 20239* Insn Attributes:: Specifying the value of attributes for generated insns. 20240* Conditional Execution::Generating 'define_insn' patterns for 20241 predication. 20242* Define Subst:: Generating 'define_insn' and 'define_expand' 20243 patterns from other patterns. 20244* Constant Definitions::Defining symbolic constants that can be used in the 20245 md file. 20246* Iterators:: Using iterators to generate patterns from a template. 20247 20248 20249File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc 20250 2025117.1 Overview of How the Machine Description is Used 20252==================================================== 20253 20254There are three main conversions that happen in the compiler: 20255 20256 1. The front end reads the source code and builds a parse tree. 20257 20258 2. The parse tree is used to generate an RTL insn list based on named 20259 instruction patterns. 20260 20261 3. The insn list is matched against the RTL templates to produce 20262 assembler code. 20263 20264 For the generate pass, only the names of the insns matter, from either 20265a named 'define_insn' or a 'define_expand'. The compiler will choose 20266the pattern with the right name and apply the operands according to the 20267documentation later in this chapter, without regard for the RTL template 20268or operand constraints. Note that the names the compiler looks for are 20269hard-coded in the compiler--it will ignore unnamed patterns and patterns 20270with names it doesn't know about, but if you don't provide a named 20271pattern it needs, it will abort. 20272 20273 If a 'define_insn' is used, the template given is inserted into the 20274insn list. If a 'define_expand' is used, one of three things happens, 20275based on the condition logic. The condition logic may manually create 20276new insns for the insn list, say via 'emit_insn()', and invoke 'DONE'. 20277For certain named patterns, it may invoke 'FAIL' to tell the compiler to 20278use an alternate way of performing that task. If it invokes neither 20279'DONE' nor 'FAIL', the template given in the pattern is inserted, as if 20280the 'define_expand' were a 'define_insn'. 20281 20282 Once the insn list is generated, various optimization passes convert, 20283replace, and rearrange the insns in the insn list. This is where the 20284'define_split' and 'define_peephole' patterns get used, for example. 20285 20286 Finally, the insn list's RTL is matched up with the RTL templates in 20287the 'define_insn' patterns, and those patterns are used to emit the 20288final assembly code. For this purpose, each named 'define_insn' acts 20289like it's unnamed, since the names are ignored. 20290 20291 20292File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc 20293 2029417.2 Everything about Instruction Patterns 20295========================================== 20296 20297A 'define_insn' expression is used to define instruction patterns to 20298which insns may be matched. A 'define_insn' expression contains an 20299incomplete RTL expression, with pieces to be filled in later, operand 20300constraints that restrict how the pieces can be filled in, and an output 20301template or C code to generate the assembler output. 20302 20303 A 'define_insn' is an RTL expression containing four or five operands: 20304 20305 1. An optional name. The presence of a name indicates that this 20306 instruction pattern can perform a certain standard job for the 20307 RTL-generation pass of the compiler. This pass knows certain names 20308 and will use the instruction patterns with those names, if the 20309 names are defined in the machine description. 20310 20311 The absence of a name is indicated by writing an empty string where 20312 the name should go. Nameless instruction patterns are never used 20313 for generating RTL code, but they may permit several simpler insns 20314 to be combined later on. 20315 20316 Names that are not thus known and used in RTL-generation have no 20317 effect; they are equivalent to no name at all. 20318 20319 For the purpose of debugging the compiler, you may also specify a 20320 name beginning with the '*' character. Such a name is used only 20321 for identifying the instruction in RTL dumps; it is equivalent to 20322 having a nameless pattern for all other purposes. Names beginning 20323 with the '*' character are not required to be unique. 20324 20325 2. The "RTL template": This is a vector of incomplete RTL expressions 20326 which describe the semantics of the instruction (*note RTL 20327 Template::). It is incomplete because it may contain 20328 'match_operand', 'match_operator', and 'match_dup' expressions that 20329 stand for operands of the instruction. 20330 20331 If the vector has multiple elements, the RTL template is treated as 20332 a 'parallel' expression. 20333 20334 3. The condition: This is a string which contains a C expression. 20335 When the compiler attempts to match RTL against a pattern, the 20336 condition is evaluated. If the condition evaluates to 'true', the 20337 match is permitted. The condition may be an empty string, which is 20338 treated as always 'true'. 20339 20340 For a named pattern, the condition may not depend on the data in 20341 the insn being matched, but only the target-machine-type flags. 20342 The compiler needs to test these conditions during initialization 20343 in order to learn exactly which named instructions are available in 20344 a particular run. 20345 20346 For nameless patterns, the condition is applied only when matching 20347 an individual insn, and only after the insn has matched the 20348 pattern's recognition template. The insn's operands may be found 20349 in the vector 'operands'. 20350 20351 An instruction condition cannot become more restrictive as 20352 compilation progresses. If the condition accepts a particular RTL 20353 instruction at one stage of compilation, it must continue to accept 20354 that instruction until the final pass. For example, 20355 '!reload_completed' and 'can_create_pseudo_p ()' are both invalid 20356 instruction conditions, because they are true during the earlier 20357 RTL passes and false during the later ones. For the same reason, 20358 if a condition accepts an instruction before register allocation, 20359 it cannot later try to control register allocation by excluding 20360 certain register or value combinations. 20361 20362 Although a condition cannot become more restrictive as compilation 20363 progresses, the condition for a nameless pattern _can_ become more 20364 permissive. For example, a nameless instruction can require 20365 'reload_completed' to be true, in which case it only matches after 20366 register allocation. 20367 20368 4. The "output template" or "output statement": This is either a 20369 string, or a fragment of C code which returns a string. 20370 20371 When simple substitution isn't general enough, you can specify a 20372 piece of C code to compute the output. *Note Output Statement::. 20373 20374 5. The "insn attributes": This is an optional vector containing the 20375 values of attributes for insns matching this pattern (*note Insn 20376 Attributes::). 20377 20378 20379File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc 20380 2038117.3 Example of 'define_insn' 20382============================= 20383 20384Here is an example of an instruction pattern, taken from the machine 20385description for the 68000/68020. 20386 20387 (define_insn "tstsi" 20388 [(set (cc0) 20389 (match_operand:SI 0 "general_operand" "rm"))] 20390 "" 20391 "* 20392 { 20393 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 20394 return \"tstl %0\"; 20395 return \"cmpl #0,%0\"; 20396 }") 20397 20398This can also be written using braced strings: 20399 20400 (define_insn "tstsi" 20401 [(set (cc0) 20402 (match_operand:SI 0 "general_operand" "rm"))] 20403 "" 20404 { 20405 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 20406 return "tstl %0"; 20407 return "cmpl #0,%0"; 20408 }) 20409 20410 This describes an instruction which sets the condition codes based on 20411the value of a general operand. It has no condition, so any insn with 20412an RTL description of the form shown may be matched to this pattern. 20413The name 'tstsi' means "test a 'SImode' value" and tells the RTL 20414generation pass that, when it is necessary to test such a value, an insn 20415to do so can be constructed using this pattern. 20416 20417 The output control string is a piece of C code which chooses which 20418output template to return based on the kind of operand and the specific 20419type of CPU for which code is being generated. 20420 20421 '"rm"' is an operand constraint. Its meaning is explained below. 20422 20423 20424File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc 20425 2042617.4 RTL Template 20427================= 20428 20429The RTL template is used to define which insns match the particular 20430pattern and how to find their operands. For named patterns, the RTL 20431template also says how to construct an insn from specified operands. 20432 20433 Construction involves substituting specified operands into a copy of 20434the template. Matching involves determining the values that serve as 20435the operands in the insn being matched. Both of these activities are 20436controlled by special expression types that direct matching and 20437substitution of the operands. 20438 20439'(match_operand:M N PREDICATE CONSTRAINT)' 20440 This expression is a placeholder for operand number N of the insn. 20441 When constructing an insn, operand number N will be substituted at 20442 this point. When matching an insn, whatever appears at this 20443 position in the insn will be taken as operand number N; but it must 20444 satisfy PREDICATE or this instruction pattern will not match at 20445 all. 20446 20447 Operand numbers must be chosen consecutively counting from zero in 20448 each instruction pattern. There may be only one 'match_operand' 20449 expression in the pattern for each operand number. Usually 20450 operands are numbered in the order of appearance in 'match_operand' 20451 expressions. In the case of a 'define_expand', any operand numbers 20452 used only in 'match_dup' expressions have higher values than all 20453 other operand numbers. 20454 20455 PREDICATE is a string that is the name of a function that accepts 20456 two arguments, an expression and a machine mode. *Note 20457 Predicates::. During matching, the function will be called with 20458 the putative operand as the expression and M as the mode argument 20459 (if M is not specified, 'VOIDmode' will be used, which normally 20460 causes PREDICATE to accept any mode). If it returns zero, this 20461 instruction pattern fails to match. PREDICATE may be an empty 20462 string; then it means no test is to be done on the operand, so 20463 anything which occurs in this position is valid. 20464 20465 Most of the time, PREDICATE will reject modes other than M--but not 20466 always. For example, the predicate 'address_operand' uses M as the 20467 mode of memory ref that the address should be valid for. Many 20468 predicates accept 'const_int' nodes even though their mode is 20469 'VOIDmode'. 20470 20471 CONSTRAINT controls reloading and the choice of the best register 20472 class to use for a value, as explained later (*note Constraints::). 20473 If the constraint would be an empty string, it can be omitted. 20474 20475 People are often unclear on the difference between the constraint 20476 and the predicate. The predicate helps decide whether a given insn 20477 matches the pattern. The constraint plays no role in this 20478 decision; instead, it controls various decisions in the case of an 20479 insn which does match. 20480 20481'(match_scratch:M N CONSTRAINT)' 20482 This expression is also a placeholder for operand number N and 20483 indicates that operand must be a 'scratch' or 'reg' expression. 20484 20485 When matching patterns, this is equivalent to 20486 20487 (match_operand:M N "scratch_operand" CONSTRAINT) 20488 20489 but, when generating RTL, it produces a ('scratch':M) expression. 20490 20491 If the last few expressions in a 'parallel' are 'clobber' 20492 expressions whose operands are either a hard register or 20493 'match_scratch', the combiner can add or delete them when 20494 necessary. *Note Side Effects::. 20495 20496'(match_dup N)' 20497 This expression is also a placeholder for operand number N. It is 20498 used when the operand needs to appear more than once in the insn. 20499 20500 In construction, 'match_dup' acts just like 'match_operand': the 20501 operand is substituted into the insn being constructed. But in 20502 matching, 'match_dup' behaves differently. It assumes that operand 20503 number N has already been determined by a 'match_operand' appearing 20504 earlier in the recognition template, and it matches only an 20505 identical-looking expression. 20506 20507 Note that 'match_dup' should not be used to tell the compiler that 20508 a particular register is being used for two operands (example: 20509 'add' that adds one register to another; the second register is 20510 both an input operand and the output operand). Use a matching 20511 constraint (*note Simple Constraints::) for those. 'match_dup' is 20512 for the cases where one operand is used in two places in the 20513 template, such as an instruction that computes both a quotient and 20514 a remainder, where the opcode takes two input operands but the RTL 20515 template has to refer to each of those twice; once for the quotient 20516 pattern and once for the remainder pattern. 20517 20518'(match_operator:M N PREDICATE [OPERANDS...])' 20519 This pattern is a kind of placeholder for a variable RTL expression 20520 code. 20521 20522 When constructing an insn, it stands for an RTL expression whose 20523 expression code is taken from that of operand N, and whose operands 20524 are constructed from the patterns OPERANDS. 20525 20526 When matching an expression, it matches an expression if the 20527 function PREDICATE returns nonzero on that expression _and_ the 20528 patterns OPERANDS match the operands of the expression. 20529 20530 Suppose that the function 'commutative_operator' is defined as 20531 follows, to match any expression whose operator is one of the 20532 commutative arithmetic operators of RTL and whose mode is MODE: 20533 20534 int 20535 commutative_integer_operator (x, mode) 20536 rtx x; 20537 machine_mode mode; 20538 { 20539 enum rtx_code code = GET_CODE (x); 20540 if (GET_MODE (x) != mode) 20541 return 0; 20542 return (GET_RTX_CLASS (code) == RTX_COMM_ARITH 20543 || code == EQ || code == NE); 20544 } 20545 20546 Then the following pattern will match any RTL expression consisting 20547 of a commutative operator applied to two general operands: 20548 20549 (match_operator:SI 3 "commutative_operator" 20550 [(match_operand:SI 1 "general_operand" "g") 20551 (match_operand:SI 2 "general_operand" "g")]) 20552 20553 Here the vector '[OPERANDS...]' contains two patterns because the 20554 expressions to be matched all contain two operands. 20555 20556 When this pattern does match, the two operands of the commutative 20557 operator are recorded as operands 1 and 2 of the insn. (This is 20558 done by the two instances of 'match_operand'.) Operand 3 of the 20559 insn will be the entire commutative expression: use 'GET_CODE 20560 (operands[3])' to see which commutative operator was used. 20561 20562 The machine mode M of 'match_operator' works like that of 20563 'match_operand': it is passed as the second argument to the 20564 predicate function, and that function is solely responsible for 20565 deciding whether the expression to be matched "has" that mode. 20566 20567 When constructing an insn, argument 3 of the gen-function will 20568 specify the operation (i.e. the expression code) for the expression 20569 to be made. It should be an RTL expression, whose expression code 20570 is copied into a new expression whose operands are arguments 1 and 20571 2 of the gen-function. The subexpressions of argument 3 are not 20572 used; only its expression code matters. 20573 20574 When 'match_operator' is used in a pattern for matching an insn, it 20575 usually best if the operand number of the 'match_operator' is 20576 higher than that of the actual operands of the insn. This improves 20577 register allocation because the register allocator often looks at 20578 operands 1 and 2 of insns to see if it can do register tying. 20579 20580 There is no way to specify constraints in 'match_operator'. The 20581 operand of the insn which corresponds to the 'match_operator' never 20582 has any constraints because it is never reloaded as a whole. 20583 However, if parts of its OPERANDS are matched by 'match_operand' 20584 patterns, those parts may have constraints of their own. 20585 20586'(match_op_dup:M N[OPERANDS...])' 20587 Like 'match_dup', except that it applies to operators instead of 20588 operands. When constructing an insn, operand number N will be 20589 substituted at this point. But in matching, 'match_op_dup' behaves 20590 differently. It assumes that operand number N has already been 20591 determined by a 'match_operator' appearing earlier in the 20592 recognition template, and it matches only an identical-looking 20593 expression. 20594 20595'(match_parallel N PREDICATE [SUBPAT...])' 20596 This pattern is a placeholder for an insn that consists of a 20597 'parallel' expression with a variable number of elements. This 20598 expression should only appear at the top level of an insn pattern. 20599 20600 When constructing an insn, operand number N will be substituted at 20601 this point. When matching an insn, it matches if the body of the 20602 insn is a 'parallel' expression with at least as many elements as 20603 the vector of SUBPAT expressions in the 'match_parallel', if each 20604 SUBPAT matches the corresponding element of the 'parallel', _and_ 20605 the function PREDICATE returns nonzero on the 'parallel' that is 20606 the body of the insn. It is the responsibility of the predicate to 20607 validate elements of the 'parallel' beyond those listed in the 20608 'match_parallel'. 20609 20610 A typical use of 'match_parallel' is to match load and store 20611 multiple expressions, which can contain a variable number of 20612 elements in a 'parallel'. For example, 20613 20614 (define_insn "" 20615 [(match_parallel 0 "load_multiple_operation" 20616 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 20617 (match_operand:SI 2 "memory_operand" "m")) 20618 (use (reg:SI 179)) 20619 (clobber (reg:SI 179))])] 20620 "" 20621 "loadm 0,0,%1,%2") 20622 20623 This example comes from 'a29k.md'. The function 20624 'load_multiple_operation' is defined in 'a29k.c' and checks that 20625 subsequent elements in the 'parallel' are the same as the 'set' in 20626 the pattern, except that they are referencing subsequent registers 20627 and memory locations. 20628 20629 An insn that matches this pattern might look like: 20630 20631 (parallel 20632 [(set (reg:SI 20) (mem:SI (reg:SI 100))) 20633 (use (reg:SI 179)) 20634 (clobber (reg:SI 179)) 20635 (set (reg:SI 21) 20636 (mem:SI (plus:SI (reg:SI 100) 20637 (const_int 4)))) 20638 (set (reg:SI 22) 20639 (mem:SI (plus:SI (reg:SI 100) 20640 (const_int 8))))]) 20641 20642'(match_par_dup N [SUBPAT...])' 20643 Like 'match_op_dup', but for 'match_parallel' instead of 20644 'match_operator'. 20645 20646 20647File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc 20648 2064917.5 Output Templates and Operand Substitution 20650============================================== 20651 20652The "output template" is a string which specifies how to output the 20653assembler code for an instruction pattern. Most of the template is a 20654fixed string which is output literally. The character '%' is used to 20655specify where to substitute an operand; it can also be used to identify 20656places where different variants of the assembler require different 20657syntax. 20658 20659 In the simplest case, a '%' followed by a digit N says to output 20660operand N at that point in the string. 20661 20662 '%' followed by a letter and a digit says to output an operand in an 20663alternate fashion. Four letters have standard, built-in meanings 20664described below. The machine description macro 'PRINT_OPERAND' can 20665define additional letters with nonstandard meanings. 20666 20667 '%cDIGIT' can be used to substitute an operand that is a constant value 20668without the syntax that normally indicates an immediate operand. 20669 20670 '%nDIGIT' is like '%cDIGIT' except that the value of the constant is 20671negated before printing. 20672 20673 '%aDIGIT' can be used to substitute an operand as if it were a memory 20674reference, with the actual operand treated as the address. This may be 20675useful when outputting a "load address" instruction, because often the 20676assembler syntax for such an instruction requires you to write the 20677operand as if it were a memory reference. 20678 20679 '%lDIGIT' is used to substitute a 'label_ref' into a jump instruction. 20680 20681 '%=' outputs a number which is unique to each instruction in the entire 20682compilation. This is useful for making local labels to be referred to 20683more than once in a single template that generates multiple assembler 20684instructions. 20685 20686 '%' followed by a punctuation character specifies a substitution that 20687does not use an operand. Only one case is standard: '%%' outputs a '%' 20688into the assembler code. Other nonstandard cases can be defined in the 20689'PRINT_OPERAND' macro. You must also define which punctuation 20690characters are valid with the 'PRINT_OPERAND_PUNCT_VALID_P' macro. 20691 20692 The template may generate multiple assembler instructions. Write the 20693text for the instructions, with '\;' between them. 20694 20695 When the RTL contains two operands which are required by constraint to 20696match each other, the output template must refer only to the 20697lower-numbered operand. Matching operands are not always identical, and 20698the rest of the compiler arranges to put the proper RTL expression for 20699printing into the lower-numbered operand. 20700 20701 One use of nonstandard letters or punctuation following '%' is to 20702distinguish between different assembler languages for the same machine; 20703for example, Motorola syntax versus MIT syntax for the 68000. Motorola 20704syntax requires periods in most opcode names, while MIT syntax does not. 20705For example, the opcode 'movel' in MIT syntax is 'move.l' in Motorola 20706syntax. The same file of patterns is used for both kinds of output 20707syntax, but the character sequence '%.' is used in each place where 20708Motorola syntax wants a period. The 'PRINT_OPERAND' macro for Motorola 20709syntax defines the sequence to output a period; the macro for MIT syntax 20710defines it to do nothing. 20711 20712 As a special case, a template consisting of the single character '#' 20713instructs the compiler to first split the insn, and then output the 20714resulting instructions separately. This helps eliminate redundancy in 20715the output templates. If you have a 'define_insn' that needs to emit 20716multiple assembler instructions, and there is a matching 'define_split' 20717already defined, then you can simply use '#' as the output template 20718instead of writing an output template that emits the multiple assembler 20719instructions. 20720 20721 Note that '#' only has an effect while generating assembly code; it 20722does not affect whether a split occurs earlier. An associated 20723'define_split' must exist and it must be suitable for use after register 20724allocation. 20725 20726 If the macro 'ASSEMBLER_DIALECT' is defined, you can use construct of 20727the form '{option0|option1|option2}' in the templates. These describe 20728multiple variants of assembler language syntax. *Note Instruction 20729Output::. 20730 20731 20732File: gccint.info, Node: Output Statement, Next: Predicates, Prev: Output Template, Up: Machine Desc 20733 2073417.6 C Statements for Assembler Output 20735====================================== 20736 20737Often a single fixed template string cannot produce correct and 20738efficient assembler code for all the cases that are recognized by a 20739single instruction pattern. For example, the opcodes may depend on the 20740kinds of operands; or some unfortunate combinations of operands may 20741require extra machine instructions. 20742 20743 If the output control string starts with a '@', then it is actually a 20744series of templates, each on a separate line. (Blank lines and leading 20745spaces and tabs are ignored.) The templates correspond to the pattern's 20746constraint alternatives (*note Multi-Alternative::). For example, if a 20747target machine has a two-address add instruction 'addr' to add into a 20748register and another 'addm' to add a register to memory, you might write 20749this pattern: 20750 20751 (define_insn "addsi3" 20752 [(set (match_operand:SI 0 "general_operand" "=r,m") 20753 (plus:SI (match_operand:SI 1 "general_operand" "0,0") 20754 (match_operand:SI 2 "general_operand" "g,r")))] 20755 "" 20756 "@ 20757 addr %2,%0 20758 addm %2,%0") 20759 20760 If the output control string starts with a '*', then it is not an 20761output template but rather a piece of C program that should compute a 20762template. It should execute a 'return' statement to return the 20763template-string you want. Most such templates use C string literals, 20764which require doublequote characters to delimit them. To include these 20765doublequote characters in the string, prefix each one with '\'. 20766 20767 If the output control string is written as a brace block instead of a 20768double-quoted string, it is automatically assumed to be C code. In that 20769case, it is not necessary to put in a leading asterisk, or to escape the 20770doublequotes surrounding C string literals. 20771 20772 The operands may be found in the array 'operands', whose C data type is 20773'rtx []'. 20774 20775 It is very common to select different ways of generating assembler code 20776based on whether an immediate operand is within a certain range. Be 20777careful when doing this, because the result of 'INTVAL' is an integer on 20778the host machine. If the host machine has more bits in an 'int' than 20779the target machine has in the mode in which the constant will be used, 20780then some of the bits you get from 'INTVAL' will be superfluous. For 20781proper results, you must carefully disregard the values of those bits. 20782 20783 It is possible to output an assembler instruction and then go on to 20784output or compute more of them, using the subroutine 'output_asm_insn'. 20785This receives two arguments: a template-string and a vector of operands. 20786The vector may be 'operands', or it may be another array of 'rtx' that 20787you declare locally and initialize yourself. 20788 20789 When an insn pattern has multiple alternatives in its constraints, 20790often the appearance of the assembler code is determined mostly by which 20791alternative was matched. When this is so, the C code can test the 20792variable 'which_alternative', which is the ordinal number of the 20793alternative that was actually satisfied (0 for the first, 1 for the 20794second alternative, etc.). 20795 20796 For example, suppose there are two opcodes for storing zero, 'clrreg' 20797for registers and 'clrmem' for memory locations. Here is how a pattern 20798could use 'which_alternative' to choose between them: 20799 20800 (define_insn "" 20801 [(set (match_operand:SI 0 "general_operand" "=r,m") 20802 (const_int 0))] 20803 "" 20804 { 20805 return (which_alternative == 0 20806 ? "clrreg %0" : "clrmem %0"); 20807 }) 20808 20809 The example above, where the assembler code to generate was _solely_ 20810determined by the alternative, could also have been specified as 20811follows, having the output control string start with a '@': 20812 20813 (define_insn "" 20814 [(set (match_operand:SI 0 "general_operand" "=r,m") 20815 (const_int 0))] 20816 "" 20817 "@ 20818 clrreg %0 20819 clrmem %0") 20820 20821 If you just need a little bit of C code in one (or a few) alternatives, 20822you can use '*' inside of a '@' multi-alternative template: 20823 20824 (define_insn "" 20825 [(set (match_operand:SI 0 "general_operand" "=r,<,m") 20826 (const_int 0))] 20827 "" 20828 "@ 20829 clrreg %0 20830 * return stack_mem_p (operands[0]) ? \"push 0\" : \"clrmem %0\"; 20831 clrmem %0") 20832 20833 20834File: gccint.info, Node: Predicates, Next: Constraints, Prev: Output Statement, Up: Machine Desc 20835 2083617.7 Predicates 20837=============== 20838 20839A predicate determines whether a 'match_operand' or 'match_operator' 20840expression matches, and therefore whether the surrounding instruction 20841pattern will be used for that combination of operands. GCC has a number 20842of machine-independent predicates, and you can define machine-specific 20843predicates as needed. By convention, predicates used with 20844'match_operand' have names that end in '_operand', and those used with 20845'match_operator' have names that end in '_operator'. 20846 20847 All predicates are boolean functions (in the mathematical sense) of two 20848arguments: the RTL expression that is being considered at that position 20849in the instruction pattern, and the machine mode that the 20850'match_operand' or 'match_operator' specifies. In this section, the 20851first argument is called OP and the second argument MODE. Predicates 20852can be called from C as ordinary two-argument functions; this can be 20853useful in output templates or other machine-specific code. 20854 20855 Operand predicates can allow operands that are not actually acceptable 20856to the hardware, as long as the constraints give reload the ability to 20857fix them up (*note Constraints::). However, GCC will usually generate 20858better code if the predicates specify the requirements of the machine 20859instructions as closely as possible. Reload cannot fix up operands that 20860must be constants ("immediate operands"); you must use a predicate that 20861allows only constants, or else enforce the requirement in the extra 20862condition. 20863 20864 Most predicates handle their MODE argument in a uniform manner. If 20865MODE is 'VOIDmode' (unspecified), then OP can have any mode. If MODE is 20866anything else, then OP must have the same mode, unless OP is a 20867'CONST_INT' or integer 'CONST_DOUBLE'. These RTL expressions always 20868have 'VOIDmode', so it would be counterproductive to check that their 20869mode matches. Instead, predicates that accept 'CONST_INT' and/or 20870integer 'CONST_DOUBLE' check that the value stored in the constant will 20871fit in the requested mode. 20872 20873 Predicates with this behavior are called "normal". 'genrecog' can 20874optimize the instruction recognizer based on knowledge of how normal 20875predicates treat modes. It can also diagnose certain kinds of common 20876errors in the use of normal predicates; for instance, it is almost 20877always an error to use a normal predicate without specifying a mode. 20878 20879 Predicates that do something different with their MODE argument are 20880called "special". The generic predicates 'address_operand' and 20881'pmode_register_operand' are special predicates. 'genrecog' does not do 20882any optimizations or diagnosis when special predicates are used. 20883 20884* Menu: 20885 20886* Machine-Independent Predicates:: Predicates available to all back ends. 20887* Defining Predicates:: How to write machine-specific predicate 20888 functions. 20889 20890 20891File: gccint.info, Node: Machine-Independent Predicates, Next: Defining Predicates, Up: Predicates 20892 2089317.7.1 Machine-Independent Predicates 20894------------------------------------- 20895 20896These are the generic predicates available to all back ends. They are 20897defined in 'recog.c'. The first category of predicates allow only 20898constant, or "immediate", operands. 20899 20900 -- Function: immediate_operand 20901 This predicate allows any sort of constant that fits in MODE. It 20902 is an appropriate choice for instructions that take operands that 20903 must be constant. 20904 20905 -- Function: const_int_operand 20906 This predicate allows any 'CONST_INT' expression that fits in MODE. 20907 It is an appropriate choice for an immediate operand that does not 20908 allow a symbol or label. 20909 20910 -- Function: const_double_operand 20911 This predicate accepts any 'CONST_DOUBLE' expression that has 20912 exactly MODE. If MODE is 'VOIDmode', it will also accept 20913 'CONST_INT'. It is intended for immediate floating point 20914 constants. 20915 20916The second category of predicates allow only some kind of machine 20917register. 20918 20919 -- Function: register_operand 20920 This predicate allows any 'REG' or 'SUBREG' expression that is 20921 valid for MODE. It is often suitable for arithmetic instruction 20922 operands on a RISC machine. 20923 20924 -- Function: pmode_register_operand 20925 This is a slight variant on 'register_operand' which works around a 20926 limitation in the machine-description reader. 20927 20928 (match_operand N "pmode_register_operand" CONSTRAINT) 20929 20930 means exactly what 20931 20932 (match_operand:P N "register_operand" CONSTRAINT) 20933 20934 would mean, if the machine-description reader accepted ':P' mode 20935 suffixes. Unfortunately, it cannot, because 'Pmode' is an alias 20936 for some other mode, and might vary with machine-specific options. 20937 *Note Misc::. 20938 20939 -- Function: scratch_operand 20940 This predicate allows hard registers and 'SCRATCH' expressions, but 20941 not pseudo-registers. It is used internally by 'match_scratch'; it 20942 should not be used directly. 20943 20944The third category of predicates allow only some kind of memory 20945reference. 20946 20947 -- Function: memory_operand 20948 This predicate allows any valid reference to a quantity of mode 20949 MODE in memory, as determined by the weak form of 20950 'GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::). 20951 20952 -- Function: address_operand 20953 This predicate is a little unusual; it allows any operand that is a 20954 valid expression for the _address_ of a quantity of mode MODE, 20955 again determined by the weak form of 'GO_IF_LEGITIMATE_ADDRESS'. 20956 To first order, if '(mem:MODE (EXP))' is acceptable to 20957 'memory_operand', then EXP is acceptable to 'address_operand'. 20958 Note that EXP does not necessarily have the mode MODE. 20959 20960 -- Function: indirect_operand 20961 This is a stricter form of 'memory_operand' which allows only 20962 memory references with a 'general_operand' as the address 20963 expression. New uses of this predicate are discouraged, because 20964 'general_operand' is very permissive, so it's hard to tell what an 20965 'indirect_operand' does or does not allow. If a target has 20966 different requirements for memory operands for different 20967 instructions, it is better to define target-specific predicates 20968 which enforce the hardware's requirements explicitly. 20969 20970 -- Function: push_operand 20971 This predicate allows a memory reference suitable for pushing a 20972 value onto the stack. This will be a 'MEM' which refers to 20973 'stack_pointer_rtx', with a side effect in its address expression 20974 (*note Incdec::); which one is determined by the 'STACK_PUSH_CODE' 20975 macro (*note Frame Layout::). 20976 20977 -- Function: pop_operand 20978 This predicate allows a memory reference suitable for popping a 20979 value off the stack. Again, this will be a 'MEM' referring to 20980 'stack_pointer_rtx', with a side effect in its address expression. 20981 However, this time 'STACK_POP_CODE' is expected. 20982 20983The fourth category of predicates allow some combination of the above 20984operands. 20985 20986 -- Function: nonmemory_operand 20987 This predicate allows any immediate or register operand valid for 20988 MODE. 20989 20990 -- Function: nonimmediate_operand 20991 This predicate allows any register or memory operand valid for 20992 MODE. 20993 20994 -- Function: general_operand 20995 This predicate allows any immediate, register, or memory operand 20996 valid for MODE. 20997 20998Finally, there are two generic operator predicates. 20999 21000 -- Function: comparison_operator 21001 This predicate matches any expression which performs an arithmetic 21002 comparison in MODE; that is, 'COMPARISON_P' is true for the 21003 expression code. 21004 21005 -- Function: ordered_comparison_operator 21006 This predicate matches any expression which performs an arithmetic 21007 comparison in MODE and whose expression code is valid for integer 21008 modes; that is, the expression code will be one of 'eq', 'ne', 21009 'lt', 'ltu', 'le', 'leu', 'gt', 'gtu', 'ge', 'geu'. 21010 21011 21012File: gccint.info, Node: Defining Predicates, Prev: Machine-Independent Predicates, Up: Predicates 21013 2101417.7.2 Defining Machine-Specific Predicates 21015------------------------------------------- 21016 21017Many machines have requirements for their operands that cannot be 21018expressed precisely using the generic predicates. You can define 21019additional predicates using 'define_predicate' and 21020'define_special_predicate' expressions. These expressions have three 21021operands: 21022 21023 * The name of the predicate, as it will be referred to in 21024 'match_operand' or 'match_operator' expressions. 21025 21026 * An RTL expression which evaluates to true if the predicate allows 21027 the operand OP, false if it does not. This expression can only use 21028 the following RTL codes: 21029 21030 'MATCH_OPERAND' 21031 When written inside a predicate expression, a 'MATCH_OPERAND' 21032 expression evaluates to true if the predicate it names would 21033 allow OP. The operand number and constraint are ignored. Due 21034 to limitations in 'genrecog', you can only refer to generic 21035 predicates and predicates that have already been defined. 21036 21037 'MATCH_CODE' 21038 This expression evaluates to true if OP or a specified 21039 subexpression of OP has one of a given list of RTX codes. 21040 21041 The first operand of this expression is a string constant 21042 containing a comma-separated list of RTX code names (in lower 21043 case). These are the codes for which the 'MATCH_CODE' will be 21044 true. 21045 21046 The second operand is a string constant which indicates what 21047 subexpression of OP to examine. If it is absent or the empty 21048 string, OP itself is examined. Otherwise, the string constant 21049 must be a sequence of digits and/or lowercase letters. Each 21050 character indicates a subexpression to extract from the 21051 current expression; for the first character this is OP, for 21052 the second and subsequent characters it is the result of the 21053 previous character. A digit N extracts 'XEXP (E, N)'; a 21054 letter L extracts 'XVECEXP (E, 0, N)' where N is the 21055 alphabetic ordinal of L (0 for 'a', 1 for 'b', and so on). 21056 The 'MATCH_CODE' then examines the RTX code of the 21057 subexpression extracted by the complete string. It is not 21058 possible to extract components of an 'rtvec' that is not at 21059 position 0 within its RTX object. 21060 21061 'MATCH_TEST' 21062 This expression has one operand, a string constant containing 21063 a C expression. The predicate's arguments, OP and MODE, are 21064 available with those names in the C expression. The 21065 'MATCH_TEST' evaluates to true if the C expression evaluates 21066 to a nonzero value. 'MATCH_TEST' expressions must not have 21067 side effects. 21068 21069 'AND' 21070 'IOR' 21071 'NOT' 21072 'IF_THEN_ELSE' 21073 The basic 'MATCH_' expressions can be combined using these 21074 logical operators, which have the semantics of the C operators 21075 '&&', '||', '!', and '? :' respectively. As in Common Lisp, 21076 you may give an 'AND' or 'IOR' expression an arbitrary number 21077 of arguments; this has exactly the same effect as writing a 21078 chain of two-argument 'AND' or 'IOR' expressions. 21079 21080 * An optional block of C code, which should execute 'return true' if 21081 the predicate is found to match and 'return false' if it does not. 21082 It must not have any side effects. The predicate arguments, OP and 21083 MODE, are available with those names. 21084 21085 If a code block is present in a predicate definition, then the RTL 21086 expression must evaluate to true _and_ the code block must execute 21087 'return true' for the predicate to allow the operand. The RTL 21088 expression is evaluated first; do not re-check anything in the code 21089 block that was checked in the RTL expression. 21090 21091 The program 'genrecog' scans 'define_predicate' and 21092'define_special_predicate' expressions to determine which RTX codes are 21093possibly allowed. You should always make this explicit in the RTL 21094predicate expression, using 'MATCH_OPERAND' and 'MATCH_CODE'. 21095 21096 Here is an example of a simple predicate definition, from the IA64 21097machine description: 21098 21099 ;; True if OP is a 'SYMBOL_REF' which refers to the sdata section. 21100 (define_predicate "small_addr_symbolic_operand" 21101 (and (match_code "symbol_ref") 21102 (match_test "SYMBOL_REF_SMALL_ADDR_P (op)"))) 21103 21104And here is another, showing the use of the C block. 21105 21106 ;; True if OP is a register operand that is (or could be) a GR reg. 21107 (define_predicate "gr_register_operand" 21108 (match_operand 0 "register_operand") 21109 { 21110 unsigned int regno; 21111 if (GET_CODE (op) == SUBREG) 21112 op = SUBREG_REG (op); 21113 21114 regno = REGNO (op); 21115 return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno)); 21116 }) 21117 21118 Predicates written with 'define_predicate' automatically include a test 21119that MODE is 'VOIDmode', or OP has the same mode as MODE, or OP is a 21120'CONST_INT' or 'CONST_DOUBLE'. They do _not_ check specifically for 21121integer 'CONST_DOUBLE', nor do they test that the value of either kind 21122of constant fits in the requested mode. This is because target-specific 21123predicates that take constants usually have to do more stringent value 21124checks anyway. If you need the exact same treatment of 'CONST_INT' or 21125'CONST_DOUBLE' that the generic predicates provide, use a 21126'MATCH_OPERAND' subexpression to call 'const_int_operand', 21127'const_double_operand', or 'immediate_operand'. 21128 21129 Predicates written with 'define_special_predicate' do not get any 21130automatic mode checks, and are treated as having special mode handling 21131by 'genrecog'. 21132 21133 The program 'genpreds' is responsible for generating code to test 21134predicates. It also writes a header file containing function 21135declarations for all machine-specific predicates. It is not necessary 21136to declare these predicates in 'CPU-protos.h'. 21137 21138 21139File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Predicates, Up: Machine Desc 21140 2114117.8 Operand Constraints 21142======================== 21143 21144Each 'match_operand' in an instruction pattern can specify constraints 21145for the operands allowed. The constraints allow you to fine-tune 21146matching within the set of operands allowed by the predicate. 21147 21148 Constraints can say whether an operand may be in a register, and which 21149kinds of register; whether the operand can be a memory reference, and 21150which kinds of address; whether the operand may be an immediate 21151constant, and which possible values it may have. Constraints can also 21152require two operands to match. Side-effects aren't allowed in operands 21153of inline 'asm', unless '<' or '>' constraints are used, because there 21154is no guarantee that the side effects will happen exactly once in an 21155instruction that can update the addressing register. 21156 21157* Menu: 21158 21159* Simple Constraints:: Basic use of constraints. 21160* Multi-Alternative:: When an insn has two alternative constraint-patterns. 21161* Class Preferences:: Constraints guide which hard register to put things in. 21162* Modifiers:: More precise control over effects of constraints. 21163* Machine Constraints:: Existing constraints for some particular machines. 21164* Disable Insn Alternatives:: Disable insn alternatives using attributes. 21165* Define Constraints:: How to define machine-specific constraints. 21166* C Constraint Interface:: How to test constraints from C code. 21167 21168 21169File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints 21170 2117117.8.1 Simple Constraints 21172------------------------- 21173 21174The simplest kind of constraint is a string full of letters, each of 21175which describes one kind of operand that is permitted. Here are the 21176letters that are allowed: 21177 21178whitespace 21179 Whitespace characters are ignored and can be inserted at any 21180 position except the first. This enables each alternative for 21181 different operands to be visually aligned in the machine 21182 description even if they have different number of constraints and 21183 modifiers. 21184 21185'm' 21186 A memory operand is allowed, with any kind of address that the 21187 machine supports in general. Note that the letter used for the 21188 general memory constraint can be re-defined by a back end using the 21189 'TARGET_MEM_CONSTRAINT' macro. 21190 21191'o' 21192 A memory operand is allowed, but only if the address is 21193 "offsettable". This means that adding a small integer (actually, 21194 the width in bytes of the operand, as determined by its machine 21195 mode) may be added to the address and the result is also a valid 21196 memory address. 21197 21198 For example, an address which is constant is offsettable; so is an 21199 address that is the sum of a register and a constant (as long as a 21200 slightly larger constant is also within the range of 21201 address-offsets supported by the machine); but an autoincrement or 21202 autodecrement address is not offsettable. More complicated 21203 indirect/indexed addresses may or may not be offsettable depending 21204 on the other addressing modes that the machine supports. 21205 21206 Note that in an output operand which can be matched by another 21207 operand, the constraint letter 'o' is valid only when accompanied 21208 by both '<' (if the target machine has predecrement addressing) and 21209 '>' (if the target machine has preincrement addressing). 21210 21211'V' 21212 A memory operand that is not offsettable. In other words, anything 21213 that would fit the 'm' constraint but not the 'o' constraint. 21214 21215'<' 21216 A memory operand with autodecrement addressing (either predecrement 21217 or postdecrement) is allowed. In inline 'asm' this constraint is 21218 only allowed if the operand is used exactly once in an instruction 21219 that can handle the side effects. Not using an operand with '<' in 21220 constraint string in the inline 'asm' pattern at all or using it in 21221 multiple instructions isn't valid, because the side effects 21222 wouldn't be performed or would be performed more than once. 21223 Furthermore, on some targets the operand with '<' in constraint 21224 string must be accompanied by special instruction suffixes like 21225 '%U0' instruction suffix on PowerPC or '%P0' on IA-64. 21226 21227'>' 21228 A memory operand with autoincrement addressing (either preincrement 21229 or postincrement) is allowed. In inline 'asm' the same 21230 restrictions as for '<' apply. 21231 21232'r' 21233 A register operand is allowed provided that it is in a general 21234 register. 21235 21236'i' 21237 An immediate integer operand (one with constant value) is allowed. 21238 This includes symbolic constants whose values will be known only at 21239 assembly time or later. 21240 21241'n' 21242 An immediate integer operand with a known numeric value is allowed. 21243 Many systems cannot support assembly-time constants for operands 21244 less than a word wide. Constraints for these operands should use 21245 'n' rather than 'i'. 21246 21247'I', 'J', 'K', ... 'P' 21248 Other letters in the range 'I' through 'P' may be defined in a 21249 machine-dependent fashion to permit immediate integer operands with 21250 explicit integer values in specified ranges. For example, on the 21251 68000, 'I' is defined to stand for the range of values 1 to 8. 21252 This is the range permitted as a shift count in the shift 21253 instructions. 21254 21255'E' 21256 An immediate floating operand (expression code 'const_double') is 21257 allowed, but only if the target floating point format is the same 21258 as that of the host machine (on which the compiler is running). 21259 21260'F' 21261 An immediate floating operand (expression code 'const_double' or 21262 'const_vector') is allowed. 21263 21264'G', 'H' 21265 'G' and 'H' may be defined in a machine-dependent fashion to permit 21266 immediate floating operands in particular ranges of values. 21267 21268's' 21269 An immediate integer operand whose value is not an explicit integer 21270 is allowed. 21271 21272 This might appear strange; if an insn allows a constant operand 21273 with a value not known at compile time, it certainly must allow any 21274 known value. So why use 's' instead of 'i'? Sometimes it allows 21275 better code to be generated. 21276 21277 For example, on the 68000 in a fullword instruction it is possible 21278 to use an immediate operand; but if the immediate value is between 21279 -128 and 127, better code results from loading the value into a 21280 register and using the register. This is because the load into the 21281 register can be done with a 'moveq' instruction. We arrange for 21282 this to happen by defining the letter 'K' to mean "any integer 21283 outside the range -128 to 127", and then specifying 'Ks' in the 21284 operand constraints. 21285 21286'g' 21287 Any register, memory or immediate integer operand is allowed, 21288 except for registers that are not general registers. 21289 21290'X' 21291 Any operand whatsoever is allowed, even if it does not satisfy 21292 'general_operand'. This is normally used in the constraint of a 21293 'match_scratch' when certain alternatives will not actually require 21294 a scratch register. 21295 21296'0', '1', '2', ... '9' 21297 An operand that matches the specified operand number is allowed. 21298 If a digit is used together with letters within the same 21299 alternative, the digit should come last. 21300 21301 This number is allowed to be more than a single digit. If multiple 21302 digits are encountered consecutively, they are interpreted as a 21303 single decimal integer. There is scant chance for ambiguity, since 21304 to-date it has never been desirable that '10' be interpreted as 21305 matching either operand 1 _or_ operand 0. Should this be desired, 21306 one can use multiple alternatives instead. 21307 21308 This is called a "matching constraint" and what it really means is 21309 that the assembler has only a single operand that fills two roles 21310 considered separate in the RTL insn. For example, an add insn has 21311 two input operands and one output operand in the RTL, but on most 21312 CISC machines an add instruction really has only two operands, one 21313 of them an input-output operand: 21314 21315 addl #35,r12 21316 21317 Matching constraints are used in these circumstances. More 21318 precisely, the two operands that match must include one input-only 21319 operand and one output-only operand. Moreover, the digit must be a 21320 smaller number than the number of the operand that uses it in the 21321 constraint. 21322 21323 For operands to match in a particular case usually means that they 21324 are identical-looking RTL expressions. But in a few special cases 21325 specific kinds of dissimilarity are allowed. For example, '*x' as 21326 an input operand will match '*x++' as an output operand. For 21327 proper results in such cases, the output template should always use 21328 the output-operand's number when printing the operand. 21329 21330'p' 21331 An operand that is a valid memory address is allowed. This is for 21332 "load address" and "push address" instructions. 21333 21334 'p' in the constraint must be accompanied by 'address_operand' as 21335 the predicate in the 'match_operand'. This predicate interprets 21336 the mode specified in the 'match_operand' as the mode of the memory 21337 reference for which the address would be valid. 21338 21339OTHER-LETTERS 21340 Other letters can be defined in machine-dependent fashion to stand 21341 for particular classes of registers or other arbitrary operand 21342 types. 'd', 'a' and 'f' are defined on the 68000/68020 to stand 21343 for data, address and floating point registers. 21344 21345 In order to have valid assembler code, each operand must satisfy its 21346constraint. But a failure to do so does not prevent the pattern from 21347applying to an insn. Instead, it directs the compiler to modify the 21348code so that the constraint will be satisfied. Usually this is done by 21349copying an operand into a register. 21350 21351 Contrast, therefore, the two instruction patterns that follow: 21352 21353 (define_insn "" 21354 [(set (match_operand:SI 0 "general_operand" "=r") 21355 (plus:SI (match_dup 0) 21356 (match_operand:SI 1 "general_operand" "r")))] 21357 "" 21358 "...") 21359 21360which has two operands, one of which must appear in two places, and 21361 21362 (define_insn "" 21363 [(set (match_operand:SI 0 "general_operand" "=r") 21364 (plus:SI (match_operand:SI 1 "general_operand" "0") 21365 (match_operand:SI 2 "general_operand" "r")))] 21366 "" 21367 "...") 21368 21369which has three operands, two of which are required by a constraint to 21370be identical. If we are considering an insn of the form 21371 21372 (insn N PREV NEXT 21373 (set (reg:SI 3) 21374 (plus:SI (reg:SI 6) (reg:SI 109))) 21375 ...) 21376 21377the first pattern would not apply at all, because this insn does not 21378contain two identical subexpressions in the right place. The pattern 21379would say, "That does not look like an add instruction; try other 21380patterns". The second pattern would say, "Yes, that's an add 21381instruction, but there is something wrong with it". It would direct the 21382reload pass of the compiler to generate additional insns to make the 21383constraint true. The results might look like this: 21384 21385 (insn N2 PREV N 21386 (set (reg:SI 3) (reg:SI 6)) 21387 ...) 21388 21389 (insn N N2 NEXT 21390 (set (reg:SI 3) 21391 (plus:SI (reg:SI 3) (reg:SI 109))) 21392 ...) 21393 21394 It is up to you to make sure that each operand, in each pattern, has 21395constraints that can handle any RTL expression that could be present for 21396that operand. (When multiple alternatives are in use, each pattern 21397must, for each possible combination of operand expressions, have at 21398least one alternative which can handle that combination of operands.) 21399The constraints don't need to _allow_ any possible operand--when this is 21400the case, they do not constrain--but they must at least point the way to 21401reloading any possible operand so that it will fit. 21402 21403 * If the constraint accepts whatever operands the predicate permits, 21404 there is no problem: reloading is never necessary for this operand. 21405 21406 For example, an operand whose constraints permit everything except 21407 registers is safe provided its predicate rejects registers. 21408 21409 An operand whose predicate accepts only constant values is safe 21410 provided its constraints include the letter 'i'. If any possible 21411 constant value is accepted, then nothing less than 'i' will do; if 21412 the predicate is more selective, then the constraints may also be 21413 more selective. 21414 21415 * Any operand expression can be reloaded by copying it into a 21416 register. So if an operand's constraints allow some kind of 21417 register, it is certain to be safe. It need not permit all classes 21418 of registers; the compiler knows how to copy a register into 21419 another register of the proper class in order to make an 21420 instruction valid. 21421 21422 * A nonoffsettable memory reference can be reloaded by copying the 21423 address into a register. So if the constraint uses the letter 'o', 21424 all memory references are taken care of. 21425 21426 * A constant operand can be reloaded by allocating space in memory to 21427 hold it as preinitialized data. Then the memory reference can be 21428 used in place of the constant. So if the constraint uses the 21429 letters 'o' or 'm', constant operands are not a problem. 21430 21431 * If the constraint permits a constant and a pseudo register used in 21432 an insn was not allocated to a hard register and is equivalent to a 21433 constant, the register will be replaced with the constant. If the 21434 predicate does not permit a constant and the insn is re-recognized 21435 for some reason, the compiler will crash. Thus the predicate must 21436 always recognize any objects allowed by the constraint. 21437 21438 If the operand's predicate can recognize registers, but the constraint 21439does not permit them, it can make the compiler crash. When this operand 21440happens to be a register, the reload pass will be stymied, because it 21441does not know how to copy a register temporarily into memory. 21442 21443 If the predicate accepts a unary operator, the constraint applies to 21444the operand. For example, the MIPS processor at ISA level 3 supports an 21445instruction which adds two registers in 'SImode' to produce a 'DImode' 21446result, but only if the registers are correctly sign extended. This 21447predicate for the input operands accepts a 'sign_extend' of an 'SImode' 21448register. Write the constraint to indicate the type of register that is 21449required for the operand of the 'sign_extend'. 21450 21451 21452File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints 21453 2145417.8.2 Multiple Alternative Constraints 21455--------------------------------------- 21456 21457Sometimes a single instruction has multiple alternative sets of possible 21458operands. For example, on the 68000, a logical-or instruction can 21459combine register or an immediate value into memory, or it can combine 21460any kind of operand into a register; but it cannot combine one memory 21461location into another. 21462 21463 These constraints are represented as multiple alternatives. An 21464alternative can be described by a series of letters for each operand. 21465The overall constraint for an operand is made from the letters for this 21466operand from the first alternative, a comma, the letters for this 21467operand from the second alternative, a comma, and so on until the last 21468alternative. All operands for a single instruction must have the same 21469number of alternatives. Here is how it is done for fullword logical-or 21470on the 68000: 21471 21472 (define_insn "iorsi3" 21473 [(set (match_operand:SI 0 "general_operand" "=m,d") 21474 (ior:SI (match_operand:SI 1 "general_operand" "%0,0") 21475 (match_operand:SI 2 "general_operand" "dKs,dmKs")))] 21476 ...) 21477 21478 The first alternative has 'm' (memory) for operand 0, '0' for operand 1 21479(meaning it must match operand 0), and 'dKs' for operand 2. The second 21480alternative has 'd' (data register) for operand 0, '0' for operand 1, 21481and 'dmKs' for operand 2. The '=' and '%' in the constraints apply to 21482all the alternatives; their meaning is explained in the next section 21483(*note Class Preferences::). 21484 21485 If all the operands fit any one alternative, the instruction is valid. 21486Otherwise, for each alternative, the compiler counts how many 21487instructions must be added to copy the operands so that that alternative 21488applies. The alternative requiring the least copying is chosen. If two 21489alternatives need the same amount of copying, the one that comes first 21490is chosen. These choices can be altered with the '?' and '!' 21491characters: 21492 21493'?' 21494 Disparage slightly the alternative that the '?' appears in, as a 21495 choice when no alternative applies exactly. The compiler regards 21496 this alternative as one unit more costly for each '?' that appears 21497 in it. 21498 21499'!' 21500 Disparage severely the alternative that the '!' appears in. This 21501 alternative can still be used if it fits without reloading, but if 21502 reloading is needed, some other alternative will be used. 21503 21504'^' 21505 This constraint is analogous to '?' but it disparages slightly the 21506 alternative only if the operand with the '^' needs a reload. 21507 21508'$' 21509 This constraint is analogous to '!' but it disparages severely the 21510 alternative only if the operand with the '$' needs a reload. 21511 21512 When an insn pattern has multiple alternatives in its constraints, 21513often the appearance of the assembler code is determined mostly by which 21514alternative was matched. When this is so, the C code for writing the 21515assembler code can use the variable 'which_alternative', which is the 21516ordinal number of the alternative that was actually satisfied (0 for the 21517first, 1 for the second alternative, etc.). *Note Output Statement::. 21518 21519 21520File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints 21521 2152217.8.3 Register Class Preferences 21523--------------------------------- 21524 21525The operand constraints have another function: they enable the compiler 21526to decide which kind of hardware register a pseudo register is best 21527allocated to. The compiler examines the constraints that apply to the 21528insns that use the pseudo register, looking for the machine-dependent 21529letters such as 'd' and 'a' that specify classes of registers. The 21530pseudo register is put in whichever class gets the most "votes". The 21531constraint letters 'g' and 'r' also vote: they vote in favor of a 21532general register. The machine description says which registers are 21533considered general. 21534 21535 Of course, on some machines all registers are equivalent, and no 21536register classes are defined. Then none of this complexity is relevant. 21537 21538 21539File: gccint.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints 21540 2154117.8.4 Constraint Modifier Characters 21542------------------------------------- 21543 21544Here are constraint modifier characters. 21545 21546'=' 21547 Means that this operand is written to by this instruction: the 21548 previous value is discarded and replaced by new data. 21549 21550'+' 21551 Means that this operand is both read and written by the 21552 instruction. 21553 21554 When the compiler fixes up the operands to satisfy the constraints, 21555 it needs to know which operands are read by the instruction and 21556 which are written by it. '=' identifies an operand which is only 21557 written; '+' identifies an operand that is both read and written; 21558 all other operands are assumed to only be read. 21559 21560 If you specify '=' or '+' in a constraint, you put it in the first 21561 character of the constraint string. 21562 21563'&' 21564 Means (in a particular alternative) that this operand is an 21565 "earlyclobber" operand, which is written before the instruction is 21566 finished using the input operands. Therefore, this operand may not 21567 lie in a register that is read by the instruction or as part of any 21568 memory address. 21569 21570 '&' applies only to the alternative in which it is written. In 21571 constraints with multiple alternatives, sometimes one alternative 21572 requires '&' while others do not. See, for example, the 'movdf' 21573 insn of the 68000. 21574 21575 A operand which is read by the instruction can be tied to an 21576 earlyclobber operand if its only use as an input occurs before the 21577 early result is written. Adding alternatives of this form often 21578 allows GCC to produce better code when only some of the read 21579 operands can be affected by the earlyclobber. See, for example, 21580 the 'mulsi3' insn of the ARM. 21581 21582 Furthermore, if the "earlyclobber" operand is also a read/write 21583 operand, then that operand is written only after it's used. 21584 21585 '&' does not obviate the need to write '=' or '+'. As 21586 "earlyclobber" operands are always written, a read-only 21587 "earlyclobber" operand is ill-formed and will be rejected by the 21588 compiler. 21589 21590'%' 21591 Declares the instruction to be commutative for this operand and the 21592 following operand. This means that the compiler may interchange 21593 the two operands if that is the cheapest way to make all operands 21594 fit the constraints. '%' applies to all alternatives and must 21595 appear as the first character in the constraint. Only read-only 21596 operands can use '%'. 21597 21598 This is often used in patterns for addition instructions that 21599 really have only two operands: the result must go in one of the 21600 arguments. Here for example, is how the 68000 halfword-add 21601 instruction is defined: 21602 21603 (define_insn "addhi3" 21604 [(set (match_operand:HI 0 "general_operand" "=m,r") 21605 (plus:HI (match_operand:HI 1 "general_operand" "%0,0") 21606 (match_operand:HI 2 "general_operand" "di,g")))] 21607 ...) 21608 GCC can only handle one commutative pair in an asm; if you use 21609 more, the compiler may fail. Note that you need not use the 21610 modifier if the two alternatives are strictly identical; this would 21611 only waste time in the reload pass. The modifier is not 21612 operational after register allocation, so the result of 21613 'define_peephole2' and 'define_split's performed after reload 21614 cannot rely on '%' to make the intended insn match. 21615 21616'#' 21617 Says that all following characters, up to the next comma, are to be 21618 ignored as a constraint. They are significant only for choosing 21619 register preferences. 21620 21621'*' 21622 Says that the following character should be ignored when choosing 21623 register preferences. '*' has no effect on the meaning of the 21624 constraint as a constraint, and no effect on reloading. For LRA 21625 '*' additionally disparages slightly the alternative if the 21626 following character matches the operand. 21627 21628 Here is an example: the 68000 has an instruction to sign-extend a 21629 halfword in a data register, and can also sign-extend a value by 21630 copying it into an address register. While either kind of register 21631 is acceptable, the constraints on an address-register destination 21632 are less strict, so it is best if register allocation makes an 21633 address register its goal. Therefore, '*' is used so that the 'd' 21634 constraint letter (for data register) is ignored when computing 21635 register preferences. 21636 21637 (define_insn "extendhisi2" 21638 [(set (match_operand:SI 0 "general_operand" "=*d,a") 21639 (sign_extend:SI 21640 (match_operand:HI 1 "general_operand" "0,g")))] 21641 ...) 21642 21643 21644File: gccint.info, Node: Machine Constraints, Next: Disable Insn Alternatives, Prev: Modifiers, Up: Constraints 21645 2164617.8.5 Constraints for Particular Machines 21647------------------------------------------ 21648 21649Whenever possible, you should use the general-purpose constraint letters 21650in 'asm' arguments, since they will convey meaning more readily to 21651people reading your code. Failing that, use the constraint letters that 21652usually have very similar meanings across architectures. The most 21653commonly used constraints are 'm' and 'r' (for memory and 21654general-purpose registers respectively; *note Simple Constraints::), and 21655'I', usually the letter indicating the most common immediate-constant 21656format. 21657 21658 Each architecture defines additional constraints. These constraints 21659are used by the compiler itself for instruction generation, as well as 21660for 'asm' statements; therefore, some of the constraints are not 21661particularly useful for 'asm'. Here is a summary of some of the 21662machine-dependent constraints available on some particular machines; it 21663includes both constraints that are useful for 'asm' and constraints that 21664aren't. The compiler source file mentioned in the table heading for 21665each architecture is the definitive reference for the meanings of that 21666architecture's constraints. 21667 21668_AArch64 family--'config/aarch64/constraints.md'_ 21669 'k' 21670 The stack pointer register ('SP') 21671 21672 'w' 21673 Floating point register, Advanced SIMD vector register or SVE 21674 vector register 21675 21676 'Upl' 21677 One of the low eight SVE predicate registers ('P0' to 'P7') 21678 21679 'Upa' 21680 Any of the SVE predicate registers ('P0' to 'P15') 21681 21682 'I' 21683 Integer constant that is valid as an immediate operand in an 21684 'ADD' instruction 21685 21686 'J' 21687 Integer constant that is valid as an immediate operand in a 21688 'SUB' instruction (once negated) 21689 21690 'K' 21691 Integer constant that can be used with a 32-bit logical 21692 instruction 21693 21694 'L' 21695 Integer constant that can be used with a 64-bit logical 21696 instruction 21697 21698 'M' 21699 Integer constant that is valid as an immediate operand in a 21700 32-bit 'MOV' pseudo instruction. The 'MOV' may be assembled 21701 to one of several different machine instructions depending on 21702 the value 21703 21704 'N' 21705 Integer constant that is valid as an immediate operand in a 21706 64-bit 'MOV' pseudo instruction 21707 21708 'S' 21709 An absolute symbolic address or a label reference 21710 21711 'Y' 21712 Floating point constant zero 21713 21714 'Z' 21715 Integer constant zero 21716 21717 'Ush' 21718 The high part (bits 12 and upwards) of the pc-relative address 21719 of a symbol within 4GB of the instruction 21720 21721 'Q' 21722 A memory address which uses a single base register with no 21723 offset 21724 21725 'Ump' 21726 A memory address suitable for a load/store pair instruction in 21727 SI, DI, SF and DF modes 21728 21729_ARC --'config/arc/constraints.md'_ 21730 'q' 21731 Registers usable in ARCompact 16-bit instructions: 'r0'-'r3', 21732 'r12'-'r15'. This constraint can only match when the '-mq' 21733 option is in effect. 21734 21735 'e' 21736 Registers usable as base-regs of memory addresses in ARCompact 21737 16-bit memory instructions: 'r0'-'r3', 'r12'-'r15', 'sp'. 21738 This constraint can only match when the '-mq' option is in 21739 effect. 21740 'D' 21741 ARC FPX (dpfp) 64-bit registers. 'D0', 'D1'. 21742 21743 'I' 21744 A signed 12-bit integer constant. 21745 21746 'Cal' 21747 constant for arithmetic/logical operations. This might be any 21748 constant that can be put into a long immediate by the assmbler 21749 or linker without involving a PIC relocation. 21750 21751 'K' 21752 A 3-bit unsigned integer constant. 21753 21754 'L' 21755 A 6-bit unsigned integer constant. 21756 21757 'CnL' 21758 One's complement of a 6-bit unsigned integer constant. 21759 21760 'CmL' 21761 Two's complement of a 6-bit unsigned integer constant. 21762 21763 'M' 21764 A 5-bit unsigned integer constant. 21765 21766 'O' 21767 A 7-bit unsigned integer constant. 21768 21769 'P' 21770 A 8-bit unsigned integer constant. 21771 21772 'H' 21773 Any const_double value. 21774 21775_ARM family--'config/arm/constraints.md'_ 21776 21777 'h' 21778 In Thumb state, the core registers 'r8'-'r15'. 21779 21780 'k' 21781 The stack pointer register. 21782 21783 'l' 21784 In Thumb State the core registers 'r0'-'r7'. In ARM state 21785 this is an alias for the 'r' constraint. 21786 21787 't' 21788 VFP floating-point registers 's0'-'s31'. Used for 32 bit 21789 values. 21790 21791 'w' 21792 VFP floating-point registers 'd0'-'d31' and the appropriate 21793 subset 'd0'-'d15' based on command line options. Used for 64 21794 bit values only. Not valid for Thumb1. 21795 21796 'y' 21797 The iWMMX co-processor registers. 21798 21799 'z' 21800 The iWMMX GR registers. 21801 21802 'G' 21803 The floating-point constant 0.0 21804 21805 'I' 21806 Integer that is valid as an immediate operand in a data 21807 processing instruction. That is, an integer in the range 0 to 21808 255 rotated by a multiple of 2 21809 21810 'J' 21811 Integer in the range -4095 to 4095 21812 21813 'K' 21814 Integer that satisfies constraint 'I' when inverted (ones 21815 complement) 21816 21817 'L' 21818 Integer that satisfies constraint 'I' when negated (twos 21819 complement) 21820 21821 'M' 21822 Integer in the range 0 to 32 21823 21824 'Q' 21825 A memory reference where the exact address is in a single 21826 register (''m'' is preferable for 'asm' statements) 21827 21828 'R' 21829 An item in the constant pool 21830 21831 'S' 21832 A symbol in the text segment of the current file 21833 21834 'Uv' 21835 A memory reference suitable for VFP load/store insns 21836 (reg+constant offset) 21837 21838 'Uy' 21839 A memory reference suitable for iWMMXt load/store 21840 instructions. 21841 21842 'Uq' 21843 A memory reference suitable for the ARMv4 ldrsb instruction. 21844 21845_AVR family--'config/avr/constraints.md'_ 21846 'l' 21847 Registers from r0 to r15 21848 21849 'a' 21850 Registers from r16 to r23 21851 21852 'd' 21853 Registers from r16 to r31 21854 21855 'w' 21856 Registers from r24 to r31. These registers can be used in 21857 'adiw' command 21858 21859 'e' 21860 Pointer register (r26-r31) 21861 21862 'b' 21863 Base pointer register (r28-r31) 21864 21865 'q' 21866 Stack pointer register (SPH:SPL) 21867 21868 't' 21869 Temporary register r0 21870 21871 'x' 21872 Register pair X (r27:r26) 21873 21874 'y' 21875 Register pair Y (r29:r28) 21876 21877 'z' 21878 Register pair Z (r31:r30) 21879 21880 'I' 21881 Constant greater than -1, less than 64 21882 21883 'J' 21884 Constant greater than -64, less than 1 21885 21886 'K' 21887 Constant integer 2 21888 21889 'L' 21890 Constant integer 0 21891 21892 'M' 21893 Constant that fits in 8 bits 21894 21895 'N' 21896 Constant integer -1 21897 21898 'O' 21899 Constant integer 8, 16, or 24 21900 21901 'P' 21902 Constant integer 1 21903 21904 'G' 21905 A floating point constant 0.0 21906 21907 'Q' 21908 A memory address based on Y or Z pointer with displacement. 21909 21910_Blackfin family--'config/bfin/constraints.md'_ 21911 'a' 21912 P register 21913 21914 'd' 21915 D register 21916 21917 'z' 21918 A call clobbered P register. 21919 21920 'qN' 21921 A single register. If N is in the range 0 to 7, the 21922 corresponding D register. If it is 'A', then the register P0. 21923 21924 'D' 21925 Even-numbered D register 21926 21927 'W' 21928 Odd-numbered D register 21929 21930 'e' 21931 Accumulator register. 21932 21933 'A' 21934 Even-numbered accumulator register. 21935 21936 'B' 21937 Odd-numbered accumulator register. 21938 21939 'b' 21940 I register 21941 21942 'v' 21943 B register 21944 21945 'f' 21946 M register 21947 21948 'c' 21949 Registers used for circular buffering, i.e. I, B, or L 21950 registers. 21951 21952 'C' 21953 The CC register. 21954 21955 't' 21956 LT0 or LT1. 21957 21958 'k' 21959 LC0 or LC1. 21960 21961 'u' 21962 LB0 or LB1. 21963 21964 'x' 21965 Any D, P, B, M, I or L register. 21966 21967 'y' 21968 Additional registers typically used only in prologues and 21969 epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and 21970 USP. 21971 21972 'w' 21973 Any register except accumulators or CC. 21974 21975 'Ksh' 21976 Signed 16 bit integer (in the range -32768 to 32767) 21977 21978 'Kuh' 21979 Unsigned 16 bit integer (in the range 0 to 65535) 21980 21981 'Ks7' 21982 Signed 7 bit integer (in the range -64 to 63) 21983 21984 'Ku7' 21985 Unsigned 7 bit integer (in the range 0 to 127) 21986 21987 'Ku5' 21988 Unsigned 5 bit integer (in the range 0 to 31) 21989 21990 'Ks4' 21991 Signed 4 bit integer (in the range -8 to 7) 21992 21993 'Ks3' 21994 Signed 3 bit integer (in the range -3 to 4) 21995 21996 'Ku3' 21997 Unsigned 3 bit integer (in the range 0 to 7) 21998 21999 'PN' 22000 Constant N, where N is a single-digit constant in the range 0 22001 to 4. 22002 22003 'PA' 22004 An integer equal to one of the MACFLAG_XXX constants that is 22005 suitable for use with either accumulator. 22006 22007 'PB' 22008 An integer equal to one of the MACFLAG_XXX constants that is 22009 suitable for use only with accumulator A1. 22010 22011 'M1' 22012 Constant 255. 22013 22014 'M2' 22015 Constant 65535. 22016 22017 'J' 22018 An integer constant with exactly a single bit set. 22019 22020 'L' 22021 An integer constant with all bits set except exactly one. 22022 22023 'H' 22024 22025 'Q' 22026 Any SYMBOL_REF. 22027 22028_CR16 Architecture--'config/cr16/cr16.h'_ 22029 22030 'b' 22031 Registers from r0 to r14 (registers without stack pointer) 22032 22033 't' 22034 Register from r0 to r11 (all 16-bit registers) 22035 22036 'p' 22037 Register from r12 to r15 (all 32-bit registers) 22038 22039 'I' 22040 Signed constant that fits in 4 bits 22041 22042 'J' 22043 Signed constant that fits in 5 bits 22044 22045 'K' 22046 Signed constant that fits in 6 bits 22047 22048 'L' 22049 Unsigned constant that fits in 4 bits 22050 22051 'M' 22052 Signed constant that fits in 32 bits 22053 22054 'N' 22055 Check for 64 bits wide constants for add/sub instructions 22056 22057 'G' 22058 Floating point constant that is legal for store immediate 22059 22060_Epiphany--'config/epiphany/constraints.md'_ 22061 'U16' 22062 An unsigned 16-bit constant. 22063 22064 'K' 22065 An unsigned 5-bit constant. 22066 22067 'L' 22068 A signed 11-bit constant. 22069 22070 'Cm1' 22071 A signed 11-bit constant added to -1. Can only match when the 22072 '-m1reg-REG' option is active. 22073 22074 'Cl1' 22075 Left-shift of -1, i.e., a bit mask with a block of leading 22076 ones, the rest being a block of trailing zeroes. Can only 22077 match when the '-m1reg-REG' option is active. 22078 22079 'Cr1' 22080 Right-shift of -1, i.e., a bit mask with a trailing block of 22081 ones, the rest being zeroes. Or to put it another way, one 22082 less than a power of two. Can only match when the 22083 '-m1reg-REG' option is active. 22084 22085 'Cal' 22086 Constant for arithmetic/logical operations. This is like 'i', 22087 except that for position independent code, no symbols / 22088 expressions needing relocations are allowed. 22089 22090 'Csy' 22091 Symbolic constant for call/jump instruction. 22092 22093 'Rcs' 22094 The register class usable in short insns. This is a register 22095 class constraint, and can thus drive register allocation. 22096 This constraint won't match unless '-mprefer-short-insn-regs' 22097 is in effect. 22098 22099 'Rsc' 22100 The the register class of registers that can be used to hold a 22101 sibcall call address. I.e., a caller-saved register. 22102 22103 'Rct' 22104 Core control register class. 22105 22106 'Rgs' 22107 The register group usable in short insns. This constraint 22108 does not use a register class, so that it only passively 22109 matches suitable registers, and doesn't drive register 22110 allocation. 22111 22112 'Car' 22113 Constant suitable for the addsi3_r pattern. This is a valid 22114 offset For byte, halfword, or word addressing. 22115 22116 'Rra' 22117 Matches the return address if it can be replaced with the link 22118 register. 22119 22120 'Rcc' 22121 Matches the integer condition code register. 22122 22123 'Sra' 22124 Matches the return address if it is in a stack slot. 22125 22126 'Cfm' 22127 Matches control register values to switch fp mode, which are 22128 encapsulated in 'UNSPEC_FP_MODE'. 22129 22130_FRV--'config/frv/frv.h'_ 22131 'a' 22132 Register in the class 'ACC_REGS' ('acc0' to 'acc7'). 22133 22134 'b' 22135 Register in the class 'EVEN_ACC_REGS' ('acc0' to 'acc7'). 22136 22137 'c' 22138 Register in the class 'CC_REGS' ('fcc0' to 'fcc3' and 'icc0' 22139 to 'icc3'). 22140 22141 'd' 22142 Register in the class 'GPR_REGS' ('gr0' to 'gr63'). 22143 22144 'e' 22145 Register in the class 'EVEN_REGS' ('gr0' to 'gr63'). Odd 22146 registers are excluded not in the class but through the use of 22147 a machine mode larger than 4 bytes. 22148 22149 'f' 22150 Register in the class 'FPR_REGS' ('fr0' to 'fr63'). 22151 22152 'h' 22153 Register in the class 'FEVEN_REGS' ('fr0' to 'fr63'). Odd 22154 registers are excluded not in the class but through the use of 22155 a machine mode larger than 4 bytes. 22156 22157 'l' 22158 Register in the class 'LR_REG' (the 'lr' register). 22159 22160 'q' 22161 Register in the class 'QUAD_REGS' ('gr2' to 'gr63'). Register 22162 numbers not divisible by 4 are excluded not in the class but 22163 through the use of a machine mode larger than 8 bytes. 22164 22165 't' 22166 Register in the class 'ICC_REGS' ('icc0' to 'icc3'). 22167 22168 'u' 22169 Register in the class 'FCC_REGS' ('fcc0' to 'fcc3'). 22170 22171 'v' 22172 Register in the class 'ICR_REGS' ('cc4' to 'cc7'). 22173 22174 'w' 22175 Register in the class 'FCR_REGS' ('cc0' to 'cc3'). 22176 22177 'x' 22178 Register in the class 'QUAD_FPR_REGS' ('fr0' to 'fr63'). 22179 Register numbers not divisible by 4 are excluded not in the 22180 class but through the use of a machine mode larger than 8 22181 bytes. 22182 22183 'z' 22184 Register in the class 'SPR_REGS' ('lcr' and 'lr'). 22185 22186 'A' 22187 Register in the class 'QUAD_ACC_REGS' ('acc0' to 'acc7'). 22188 22189 'B' 22190 Register in the class 'ACCG_REGS' ('accg0' to 'accg7'). 22191 22192 'C' 22193 Register in the class 'CR_REGS' ('cc0' to 'cc7'). 22194 22195 'G' 22196 Floating point constant zero 22197 22198 'I' 22199 6-bit signed integer constant 22200 22201 'J' 22202 10-bit signed integer constant 22203 22204 'L' 22205 16-bit signed integer constant 22206 22207 'M' 22208 16-bit unsigned integer constant 22209 22210 'N' 22211 12-bit signed integer constant that is negative--i.e. in the 22212 range of -2048 to -1 22213 22214 'O' 22215 Constant zero 22216 22217 'P' 22218 12-bit signed integer constant that is greater than zero--i.e. 22219 in the range of 1 to 2047. 22220 22221_FT32--'config/ft32/constraints.md'_ 22222 'A' 22223 An absolute address 22224 22225 'B' 22226 An offset address 22227 22228 'W' 22229 A register indirect memory operand 22230 22231 'e' 22232 An offset address. 22233 22234 'f' 22235 An offset address. 22236 22237 'O' 22238 The constant zero or one 22239 22240 'I' 22241 A 16-bit signed constant (-32768 ... 32767) 22242 22243 'w' 22244 A bitfield mask suitable for bext or bins 22245 22246 'x' 22247 An inverted bitfield mask suitable for bext or bins 22248 22249 'L' 22250 A 16-bit unsigned constant, multiple of 4 (0 ... 65532) 22251 22252 'S' 22253 A 20-bit signed constant (-524288 ... 524287) 22254 22255 'b' 22256 A constant for a bitfield width (1 ... 16) 22257 22258 'KA' 22259 A 10-bit signed constant (-512 ... 511) 22260 22261_Hewlett-Packard PA-RISC--'config/pa/pa.h'_ 22262 'a' 22263 General register 1 22264 22265 'f' 22266 Floating point register 22267 22268 'q' 22269 Shift amount register 22270 22271 'x' 22272 Floating point register (deprecated) 22273 22274 'y' 22275 Upper floating point register (32-bit), floating point 22276 register (64-bit) 22277 22278 'Z' 22279 Any register 22280 22281 'I' 22282 Signed 11-bit integer constant 22283 22284 'J' 22285 Signed 14-bit integer constant 22286 22287 'K' 22288 Integer constant that can be deposited with a 'zdepi' 22289 instruction 22290 22291 'L' 22292 Signed 5-bit integer constant 22293 22294 'M' 22295 Integer constant 0 22296 22297 'N' 22298 Integer constant that can be loaded with a 'ldil' instruction 22299 22300 'O' 22301 Integer constant whose value plus one is a power of 2 22302 22303 'P' 22304 Integer constant that can be used for 'and' operations in 22305 'depi' and 'extru' instructions 22306 22307 'S' 22308 Integer constant 31 22309 22310 'U' 22311 Integer constant 63 22312 22313 'G' 22314 Floating-point constant 0.0 22315 22316 'A' 22317 A 'lo_sum' data-linkage-table memory operand 22318 22319 'Q' 22320 A memory operand that can be used as the destination operand 22321 of an integer store instruction 22322 22323 'R' 22324 A scaled or unscaled indexed memory operand 22325 22326 'T' 22327 A memory operand for floating-point loads and stores 22328 22329 'W' 22330 A register indirect memory operand 22331 22332_Intel IA-64--'config/ia64/ia64.h'_ 22333 'a' 22334 General register 'r0' to 'r3' for 'addl' instruction 22335 22336 'b' 22337 Branch register 22338 22339 'c' 22340 Predicate register ('c' as in "conditional") 22341 22342 'd' 22343 Application register residing in M-unit 22344 22345 'e' 22346 Application register residing in I-unit 22347 22348 'f' 22349 Floating-point register 22350 22351 'm' 22352 Memory operand. If used together with '<' or '>', the operand 22353 can have postincrement and postdecrement which require 22354 printing with '%Pn' on IA-64. 22355 22356 'G' 22357 Floating-point constant 0.0 or 1.0 22358 22359 'I' 22360 14-bit signed integer constant 22361 22362 'J' 22363 22-bit signed integer constant 22364 22365 'K' 22366 8-bit signed integer constant for logical instructions 22367 22368 'L' 22369 8-bit adjusted signed integer constant for compare pseudo-ops 22370 22371 'M' 22372 6-bit unsigned integer constant for shift counts 22373 22374 'N' 22375 9-bit signed integer constant for load and store 22376 postincrements 22377 22378 'O' 22379 The constant zero 22380 22381 'P' 22382 0 or -1 for 'dep' instruction 22383 22384 'Q' 22385 Non-volatile memory for floating-point loads and stores 22386 22387 'R' 22388 Integer constant in the range 1 to 4 for 'shladd' instruction 22389 22390 'S' 22391 Memory operand except postincrement and postdecrement. This 22392 is now roughly the same as 'm' when not used together with '<' 22393 or '>'. 22394 22395_M32C--'config/m32c/m32c.c'_ 22396 'Rsp' 22397 'Rfb' 22398 'Rsb' 22399 '$sp', '$fb', '$sb'. 22400 22401 'Rcr' 22402 Any control register, when they're 16 bits wide (nothing if 22403 control registers are 24 bits wide) 22404 22405 'Rcl' 22406 Any control register, when they're 24 bits wide. 22407 22408 'R0w' 22409 'R1w' 22410 'R2w' 22411 'R3w' 22412 $r0, $r1, $r2, $r3. 22413 22414 'R02' 22415 $r0 or $r2, or $r2r0 for 32 bit values. 22416 22417 'R13' 22418 $r1 or $r3, or $r3r1 for 32 bit values. 22419 22420 'Rdi' 22421 A register that can hold a 64 bit value. 22422 22423 'Rhl' 22424 $r0 or $r1 (registers with addressable high/low bytes) 22425 22426 'R23' 22427 $r2 or $r3 22428 22429 'Raa' 22430 Address registers 22431 22432 'Raw' 22433 Address registers when they're 16 bits wide. 22434 22435 'Ral' 22436 Address registers when they're 24 bits wide. 22437 22438 'Rqi' 22439 Registers that can hold QI values. 22440 22441 'Rad' 22442 Registers that can be used with displacements ($a0, $a1, $sb). 22443 22444 'Rsi' 22445 Registers that can hold 32 bit values. 22446 22447 'Rhi' 22448 Registers that can hold 16 bit values. 22449 22450 'Rhc' 22451 Registers chat can hold 16 bit values, including all control 22452 registers. 22453 22454 'Rra' 22455 $r0 through R1, plus $a0 and $a1. 22456 22457 'Rfl' 22458 The flags register. 22459 22460 'Rmm' 22461 The memory-based pseudo-registers $mem0 through $mem15. 22462 22463 'Rpi' 22464 Registers that can hold pointers (16 bit registers for r8c, 22465 m16c; 24 bit registers for m32cm, m32c). 22466 22467 'Rpa' 22468 Matches multiple registers in a PARALLEL to form a larger 22469 register. Used to match function return values. 22470 22471 'Is3' 22472 -8 ... 7 22473 22474 'IS1' 22475 -128 ... 127 22476 22477 'IS2' 22478 -32768 ... 32767 22479 22480 'IU2' 22481 0 ... 65535 22482 22483 'In4' 22484 -8 ... -1 or 1 ... 8 22485 22486 'In5' 22487 -16 ... -1 or 1 ... 16 22488 22489 'In6' 22490 -32 ... -1 or 1 ... 32 22491 22492 'IM2' 22493 -65536 ... -1 22494 22495 'Ilb' 22496 An 8 bit value with exactly one bit set. 22497 22498 'Ilw' 22499 A 16 bit value with exactly one bit set. 22500 22501 'Sd' 22502 The common src/dest memory addressing modes. 22503 22504 'Sa' 22505 Memory addressed using $a0 or $a1. 22506 22507 'Si' 22508 Memory addressed with immediate addresses. 22509 22510 'Ss' 22511 Memory addressed using the stack pointer ($sp). 22512 22513 'Sf' 22514 Memory addressed using the frame base register ($fb). 22515 22516 'Ss' 22517 Memory addressed using the small base register ($sb). 22518 22519 'S1' 22520 $r1h 22521 22522_MicroBlaze--'config/microblaze/constraints.md'_ 22523 'd' 22524 A general register ('r0' to 'r31'). 22525 22526 'z' 22527 A status register ('rmsr', '$fcc1' to '$fcc7'). 22528 22529_MIPS--'config/mips/constraints.md'_ 22530 'd' 22531 A general-purpose register. This is equivalent to 'r' unless 22532 generating MIPS16 code, in which case the MIPS16 register set 22533 is used. 22534 22535 'f' 22536 A floating-point register (if available). 22537 22538 'h' 22539 Formerly the 'hi' register. This constraint is no longer 22540 supported. 22541 22542 'l' 22543 The 'lo' register. Use this register to store values that are 22544 no bigger than a word. 22545 22546 'x' 22547 The concatenated 'hi' and 'lo' registers. Use this register 22548 to store doubleword values. 22549 22550 'c' 22551 A register suitable for use in an indirect jump. This will 22552 always be '$25' for '-mabicalls'. 22553 22554 'v' 22555 Register '$3'. Do not use this constraint in new code; it is 22556 retained only for compatibility with glibc. 22557 22558 'y' 22559 Equivalent to 'r'; retained for backwards compatibility. 22560 22561 'z' 22562 A floating-point condition code register. 22563 22564 'I' 22565 A signed 16-bit constant (for arithmetic instructions). 22566 22567 'J' 22568 Integer zero. 22569 22570 'K' 22571 An unsigned 16-bit constant (for logic instructions). 22572 22573 'L' 22574 A signed 32-bit constant in which the lower 16 bits are zero. 22575 Such constants can be loaded using 'lui'. 22576 22577 'M' 22578 A constant that cannot be loaded using 'lui', 'addiu' or 22579 'ori'. 22580 22581 'N' 22582 A constant in the range -65535 to -1 (inclusive). 22583 22584 'O' 22585 A signed 15-bit constant. 22586 22587 'P' 22588 A constant in the range 1 to 65535 (inclusive). 22589 22590 'G' 22591 Floating-point zero. 22592 22593 'R' 22594 An address that can be used in a non-macro load or store. 22595 22596 'ZC' 22597 A memory operand whose address is formed by a base register 22598 and offset that is suitable for use in instructions with the 22599 same addressing mode as 'll' and 'sc'. 22600 22601 'ZD' 22602 An address suitable for a 'prefetch' instruction, or for any 22603 other instruction with the same addressing mode as 'prefetch'. 22604 22605_Motorola 680x0--'config/m68k/constraints.md'_ 22606 'a' 22607 Address register 22608 22609 'd' 22610 Data register 22611 22612 'f' 22613 68881 floating-point register, if available 22614 22615 'I' 22616 Integer in the range 1 to 8 22617 22618 'J' 22619 16-bit signed number 22620 22621 'K' 22622 Signed number whose magnitude is greater than 0x80 22623 22624 'L' 22625 Integer in the range -8 to -1 22626 22627 'M' 22628 Signed number whose magnitude is greater than 0x100 22629 22630 'N' 22631 Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate 22632 22633 'O' 22634 16 (for rotate using swap) 22635 22636 'P' 22637 Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate 22638 22639 'R' 22640 Numbers that mov3q can handle 22641 22642 'G' 22643 Floating point constant that is not a 68881 constant 22644 22645 'S' 22646 Operands that satisfy 'm' when -mpcrel is in effect 22647 22648 'T' 22649 Operands that satisfy 's' when -mpcrel is not in effect 22650 22651 'Q' 22652 Address register indirect addressing mode 22653 22654 'U' 22655 Register offset addressing 22656 22657 'W' 22658 const_call_operand 22659 22660 'Cs' 22661 symbol_ref or const 22662 22663 'Ci' 22664 const_int 22665 22666 'C0' 22667 const_int 0 22668 22669 'Cj' 22670 Range of signed numbers that don't fit in 16 bits 22671 22672 'Cmvq' 22673 Integers valid for mvq 22674 22675 'Capsw' 22676 Integers valid for a moveq followed by a swap 22677 22678 'Cmvz' 22679 Integers valid for mvz 22680 22681 'Cmvs' 22682 Integers valid for mvs 22683 22684 'Ap' 22685 push_operand 22686 22687 'Ac' 22688 Non-register operands allowed in clr 22689 22690_Moxie--'config/moxie/constraints.md'_ 22691 'A' 22692 An absolute address 22693 22694 'B' 22695 An offset address 22696 22697 'W' 22698 A register indirect memory operand 22699 22700 'I' 22701 A constant in the range of 0 to 255. 22702 22703 'N' 22704 A constant in the range of 0 to -255. 22705 22706_MSP430-'config/msp430/constraints.md'_ 22707 22708 'R12' 22709 Register R12. 22710 22711 'R13' 22712 Register R13. 22713 22714 'K' 22715 Integer constant 1. 22716 22717 'L' 22718 Integer constant -1^20..1^19. 22719 22720 'M' 22721 Integer constant 1-4. 22722 22723 'Ya' 22724 Memory references which do not require an extended MOVX 22725 instruction. 22726 22727 'Yl' 22728 Memory reference, labels only. 22729 22730 'Ys' 22731 Memory reference, stack only. 22732 22733_NDS32--'config/nds32/constraints.md'_ 22734 'w' 22735 LOW register class $r0 to $r7 constraint for V3/V3M ISA. 22736 'l' 22737 LOW register class $r0 to $r7. 22738 'd' 22739 MIDDLE register class $r0 to $r11, $r16 to $r19. 22740 'h' 22741 HIGH register class $r12 to $r14, $r20 to $r31. 22742 't' 22743 Temporary assist register $ta (i.e. $r15). 22744 'k' 22745 Stack register $sp. 22746 'Iu03' 22747 Unsigned immediate 3-bit value. 22748 'In03' 22749 Negative immediate 3-bit value in the range of -7-0. 22750 'Iu04' 22751 Unsigned immediate 4-bit value. 22752 'Is05' 22753 Signed immediate 5-bit value. 22754 'Iu05' 22755 Unsigned immediate 5-bit value. 22756 'In05' 22757 Negative immediate 5-bit value in the range of -31-0. 22758 'Ip05' 22759 Unsigned immediate 5-bit value for movpi45 instruction with 22760 range 16-47. 22761 'Iu06' 22762 Unsigned immediate 6-bit value constraint for addri36.sp 22763 instruction. 22764 'Iu08' 22765 Unsigned immediate 8-bit value. 22766 'Iu09' 22767 Unsigned immediate 9-bit value. 22768 'Is10' 22769 Signed immediate 10-bit value. 22770 'Is11' 22771 Signed immediate 11-bit value. 22772 'Is15' 22773 Signed immediate 15-bit value. 22774 'Iu15' 22775 Unsigned immediate 15-bit value. 22776 'Ic15' 22777 A constant which is not in the range of imm15u but ok for bclr 22778 instruction. 22779 'Ie15' 22780 A constant which is not in the range of imm15u but ok for bset 22781 instruction. 22782 'It15' 22783 A constant which is not in the range of imm15u but ok for btgl 22784 instruction. 22785 'Ii15' 22786 A constant whose compliment value is in the range of imm15u 22787 and ok for bitci instruction. 22788 'Is16' 22789 Signed immediate 16-bit value. 22790 'Is17' 22791 Signed immediate 17-bit value. 22792 'Is19' 22793 Signed immediate 19-bit value. 22794 'Is20' 22795 Signed immediate 20-bit value. 22796 'Ihig' 22797 The immediate value that can be simply set high 20-bit. 22798 'Izeb' 22799 The immediate value 0xff. 22800 'Izeh' 22801 The immediate value 0xffff. 22802 'Ixls' 22803 The immediate value 0x01. 22804 'Ix11' 22805 The immediate value 0x7ff. 22806 'Ibms' 22807 The immediate value with power of 2. 22808 'Ifex' 22809 The immediate value with power of 2 minus 1. 22810 'U33' 22811 Memory constraint for 333 format. 22812 'U45' 22813 Memory constraint for 45 format. 22814 'U37' 22815 Memory constraint for 37 format. 22816 22817_Nios II family--'config/nios2/constraints.md'_ 22818 22819 'I' 22820 Integer that is valid as an immediate operand in an 22821 instruction taking a signed 16-bit number. Range -32768 to 22822 32767. 22823 22824 'J' 22825 Integer that is valid as an immediate operand in an 22826 instruction taking an unsigned 16-bit number. Range 0 to 22827 65535. 22828 22829 'K' 22830 Integer that is valid as an immediate operand in an 22831 instruction taking only the upper 16-bits of a 32-bit number. 22832 Range 32-bit numbers with the lower 16-bits being 0. 22833 22834 'L' 22835 Integer that is valid as an immediate operand for a shift 22836 instruction. Range 0 to 31. 22837 22838 'M' 22839 Integer that is valid as an immediate operand for only the 22840 value 0. Can be used in conjunction with the format modifier 22841 'z' to use 'r0' instead of '0' in the assembly output. 22842 22843 'N' 22844 Integer that is valid as an immediate operand for a custom 22845 instruction opcode. Range 0 to 255. 22846 22847 'P' 22848 An immediate operand for R2 andchi/andci instructions. 22849 22850 'S' 22851 Matches immediates which are addresses in the small data 22852 section and therefore can be added to 'gp' as a 16-bit 22853 immediate to re-create their 32-bit value. 22854 22855 'U' 22856 Matches constants suitable as an operand for the rdprs and 22857 cache instructions. 22858 22859 'v' 22860 A memory operand suitable for Nios II R2 load/store exclusive 22861 instructions. 22862 22863 'w' 22864 A memory operand suitable for load/store IO and cache 22865 instructions. 22866 22867 'T' 22868 A 'const' wrapped 'UNSPEC' expression, representing a 22869 supported PIC or TLS relocation. 22870 22871_PDP-11--'config/pdp11/constraints.md'_ 22872 'a' 22873 Floating point registers AC0 through AC3. These can be loaded 22874 from/to memory with a single instruction. 22875 22876 'd' 22877 Odd numbered general registers (R1, R3, R5). These are used 22878 for 16-bit multiply operations. 22879 22880 'f' 22881 Any of the floating point registers (AC0 through AC5). 22882 22883 'G' 22884 Floating point constant 0. 22885 22886 'I' 22887 An integer constant that fits in 16 bits. 22888 22889 'J' 22890 An integer constant whose low order 16 bits are zero. 22891 22892 'K' 22893 An integer constant that does not meet the constraints for 22894 codes 'I' or 'J'. 22895 22896 'L' 22897 The integer constant 1. 22898 22899 'M' 22900 The integer constant -1. 22901 22902 'N' 22903 The integer constant 0. 22904 22905 'O' 22906 Integer constants -4 through -1 and 1 through 4; shifts by 22907 these amounts are handled as multiple single-bit shifts rather 22908 than a single variable-length shift. 22909 22910 'Q' 22911 A memory reference which requires an additional word (address 22912 or offset) after the opcode. 22913 22914 'R' 22915 A memory reference that is encoded within the opcode. 22916 22917_PowerPC and IBM RS6000--'config/rs6000/constraints.md'_ 22918 'b' 22919 Address base register 22920 22921 'd' 22922 Floating point register (containing 64-bit value) 22923 22924 'f' 22925 Floating point register (containing 32-bit value) 22926 22927 'v' 22928 Altivec vector register 22929 22930 'wa' 22931 Any VSX register if the '-mvsx' option was used or NO_REGS. 22932 22933 When using any of the register constraints ('wa', 'wd', 'wf', 22934 'wg', 'wh', 'wi', 'wj', 'wk', 'wl', 'wm', 'wo', 'wp', 'wq', 22935 'ws', 'wt', 'wu', 'wv', 'ww', or 'wy') that take VSX 22936 registers, you must use '%x<n>' in the template so that the 22937 correct register is used. Otherwise the register number 22938 output in the assembly file will be incorrect if an Altivec 22939 register is an operand of a VSX instruction that expects VSX 22940 register numbering. 22941 22942 asm ("xvadddp %x0,%x1,%x2" 22943 : "=wa" (v1) 22944 : "wa" (v2), "wa" (v3)); 22945 22946 is correct, but: 22947 22948 asm ("xvadddp %0,%1,%2" 22949 : "=wa" (v1) 22950 : "wa" (v2), "wa" (v3)); 22951 22952 is not correct. 22953 22954 If an instruction only takes Altivec registers, you do not 22955 want to use '%x<n>'. 22956 22957 asm ("xsaddqp %0,%1,%2" 22958 : "=v" (v1) 22959 : "v" (v2), "v" (v3)); 22960 22961 is correct because the 'xsaddqp' instruction only takes 22962 Altivec registers, while: 22963 22964 asm ("xsaddqp %x0,%x1,%x2" 22965 : "=v" (v1) 22966 : "v" (v2), "v" (v3)); 22967 22968 is incorrect. 22969 22970 'wb' 22971 Altivec register if '-mcpu=power9' is used or NO_REGS. 22972 22973 'wd' 22974 VSX vector register to hold vector double data or NO_REGS. 22975 22976 'we' 22977 VSX register if the '-mcpu=power9' and '-m64' options were 22978 used or NO_REGS. 22979 22980 'wf' 22981 VSX vector register to hold vector float data or NO_REGS. 22982 22983 'wg' 22984 If '-mmfpgpr' was used, a floating point register or NO_REGS. 22985 22986 'wh' 22987 Floating point register if direct moves are available, or 22988 NO_REGS. 22989 22990 'wi' 22991 FP or VSX register to hold 64-bit integers for VSX insns or 22992 NO_REGS. 22993 22994 'wj' 22995 FP or VSX register to hold 64-bit integers for direct moves or 22996 NO_REGS. 22997 22998 'wk' 22999 FP or VSX register to hold 64-bit doubles for direct moves or 23000 NO_REGS. 23001 23002 'wl' 23003 Floating point register if the LFIWAX instruction is enabled 23004 or NO_REGS. 23005 23006 'wm' 23007 VSX register if direct move instructions are enabled, or 23008 NO_REGS. 23009 23010 'wn' 23011 No register (NO_REGS). 23012 23013 'wo' 23014 VSX register to use for ISA 3.0 vector instructions, or 23015 NO_REGS. 23016 23017 'wp' 23018 VSX register to use for IEEE 128-bit floating point TFmode, or 23019 NO_REGS. 23020 23021 'wq' 23022 VSX register to use for IEEE 128-bit floating point, or 23023 NO_REGS. 23024 23025 'wr' 23026 General purpose register if 64-bit instructions are enabled or 23027 NO_REGS. 23028 23029 'ws' 23030 VSX vector register to hold scalar double values or NO_REGS. 23031 23032 'wt' 23033 VSX vector register to hold 128 bit integer or NO_REGS. 23034 23035 'wu' 23036 Altivec register to use for float/32-bit int loads/stores or 23037 NO_REGS. 23038 23039 'wv' 23040 Altivec register to use for double loads/stores or NO_REGS. 23041 23042 'ww' 23043 FP or VSX register to perform float operations under '-mvsx' 23044 or NO_REGS. 23045 23046 'wx' 23047 Floating point register if the STFIWX instruction is enabled 23048 or NO_REGS. 23049 23050 'wy' 23051 FP or VSX register to perform ISA 2.07 float ops or NO_REGS. 23052 23053 'wz' 23054 Floating point register if the LFIWZX instruction is enabled 23055 or NO_REGS. 23056 23057 'wA' 23058 Address base register if 64-bit instructions are enabled or 23059 NO_REGS. 23060 23061 'wB' 23062 Signed 5-bit constant integer that can be loaded into an 23063 altivec register. 23064 23065 'wD' 23066 Int constant that is the element number of the 64-bit scalar 23067 in a vector. 23068 23069 'wE' 23070 Vector constant that can be loaded with the XXSPLTIB 23071 instruction. 23072 23073 'wF' 23074 Memory operand suitable for power9 fusion load/stores. 23075 23076 'wG' 23077 Memory operand suitable for TOC fusion memory references. 23078 23079 'wH' 23080 Altivec register if '-mvsx-small-integer'. 23081 23082 'wI' 23083 Floating point register if '-mvsx-small-integer'. 23084 23085 'wJ' 23086 FP register if '-mvsx-small-integer' and '-mpower9-vector'. 23087 23088 'wK' 23089 Altivec register if '-mvsx-small-integer' and 23090 '-mpower9-vector'. 23091 23092 'wL' 23093 Int constant that is the element number that the MFVSRLD 23094 instruction. targets. 23095 23096 'wM' 23097 Match vector constant with all 1's if the XXLORC instruction 23098 is available. 23099 23100 'wO' 23101 A memory operand suitable for the ISA 3.0 vector d-form 23102 instructions. 23103 23104 'wQ' 23105 A memory address that will work with the 'lq' and 'stq' 23106 instructions. 23107 23108 'wS' 23109 Vector constant that can be loaded with XXSPLTIB & sign 23110 extension. 23111 23112 'h' 23113 'MQ', 'CTR', or 'LINK' register 23114 23115 'c' 23116 'CTR' register 23117 23118 'l' 23119 'LINK' register 23120 23121 'x' 23122 'CR' register (condition register) number 0 23123 23124 'y' 23125 'CR' register (condition register) 23126 23127 'z' 23128 'XER[CA]' carry bit (part of the XER register) 23129 23130 'I' 23131 Signed 16-bit constant 23132 23133 'J' 23134 Unsigned 16-bit constant shifted left 16 bits (use 'L' instead 23135 for 'SImode' constants) 23136 23137 'K' 23138 Unsigned 16-bit constant 23139 23140 'L' 23141 Signed 16-bit constant shifted left 16 bits 23142 23143 'M' 23144 Constant larger than 31 23145 23146 'N' 23147 Exact power of 2 23148 23149 'O' 23150 Zero 23151 23152 'P' 23153 Constant whose negation is a signed 16-bit constant 23154 23155 'G' 23156 Floating point constant that can be loaded into a register 23157 with one instruction per word 23158 23159 'H' 23160 Integer/Floating point constant that can be loaded into a 23161 register using three instructions 23162 23163 'm' 23164 Memory operand. Normally, 'm' does not allow addresses that 23165 update the base register. If '<' or '>' constraint is also 23166 used, they are allowed and therefore on PowerPC targets in 23167 that case it is only safe to use 'm<>' in an 'asm' statement 23168 if that 'asm' statement accesses the operand exactly once. 23169 The 'asm' statement must also use '%U<OPNO>' as a placeholder 23170 for the "update" flag in the corresponding load or store 23171 instruction. For example: 23172 23173 asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val)); 23174 23175 is correct but: 23176 23177 asm ("st %1,%0" : "=m<>" (mem) : "r" (val)); 23178 23179 is not. 23180 23181 'es' 23182 A "stable" memory operand; that is, one which does not include 23183 any automodification of the base register. This used to be 23184 useful when 'm' allowed automodification of the base register, 23185 but as those are now only allowed when '<' or '>' is used, 23186 'es' is basically the same as 'm' without '<' and '>'. 23187 23188 'Q' 23189 Memory operand that is an offset from a register (it is 23190 usually better to use 'm' or 'es' in 'asm' statements) 23191 23192 'Z' 23193 Memory operand that is an indexed or indirect from a register 23194 (it is usually better to use 'm' or 'es' in 'asm' statements) 23195 23196 'R' 23197 AIX TOC entry 23198 23199 'a' 23200 Address operand that is an indexed or indirect from a register 23201 ('p' is preferable for 'asm' statements) 23202 23203 'U' 23204 System V Release 4 small data area reference 23205 23206 'W' 23207 Vector constant that does not require memory 23208 23209 'j' 23210 Vector constant that is all zeros. 23211 23212_RL78--'config/rl78/constraints.md'_ 23213 23214 'Int3' 23215 An integer constant in the range 1 ... 7. 23216 'Int8' 23217 An integer constant in the range 0 ... 255. 23218 'J' 23219 An integer constant in the range -255 ... 0 23220 'K' 23221 The integer constant 1. 23222 'L' 23223 The integer constant -1. 23224 'M' 23225 The integer constant 0. 23226 'N' 23227 The integer constant 2. 23228 'O' 23229 The integer constant -2. 23230 'P' 23231 An integer constant in the range 1 ... 15. 23232 'Qbi' 23233 The built-in compare types-eq, ne, gtu, ltu, geu, and leu. 23234 'Qsc' 23235 The synthetic compare types-gt, lt, ge, and le. 23236 'Wab' 23237 A memory reference with an absolute address. 23238 'Wbc' 23239 A memory reference using 'BC' as a base register, with an 23240 optional offset. 23241 'Wca' 23242 A memory reference using 'AX', 'BC', 'DE', or 'HL' for the 23243 address, for calls. 23244 'Wcv' 23245 A memory reference using any 16-bit register pair for the 23246 address, for calls. 23247 'Wd2' 23248 A memory reference using 'DE' as a base register, with an 23249 optional offset. 23250 'Wde' 23251 A memory reference using 'DE' as a base register, without any 23252 offset. 23253 'Wfr' 23254 Any memory reference to an address in the far address space. 23255 'Wh1' 23256 A memory reference using 'HL' as a base register, with an 23257 optional one-byte offset. 23258 'Whb' 23259 A memory reference using 'HL' as a base register, with 'B' or 23260 'C' as the index register. 23261 'Whl' 23262 A memory reference using 'HL' as a base register, without any 23263 offset. 23264 'Ws1' 23265 A memory reference using 'SP' as a base register, with an 23266 optional one-byte offset. 23267 'Y' 23268 Any memory reference to an address in the near address space. 23269 'A' 23270 The 'AX' register. 23271 'B' 23272 The 'BC' register. 23273 'D' 23274 The 'DE' register. 23275 'R' 23276 'A' through 'L' registers. 23277 'S' 23278 The 'SP' register. 23279 'T' 23280 The 'HL' register. 23281 'Z08W' 23282 The 16-bit 'R8' register. 23283 'Z10W' 23284 The 16-bit 'R10' register. 23285 'Zint' 23286 The registers reserved for interrupts ('R24' to 'R31'). 23287 'a' 23288 The 'A' register. 23289 'b' 23290 The 'B' register. 23291 'c' 23292 The 'C' register. 23293 'd' 23294 The 'D' register. 23295 'e' 23296 The 'E' register. 23297 'h' 23298 The 'H' register. 23299 'l' 23300 The 'L' register. 23301 'v' 23302 The virtual registers. 23303 'w' 23304 The 'PSW' register. 23305 'x' 23306 The 'X' register. 23307 23308_RISC-V--'config/riscv/constraints.md'_ 23309 23310 'f' 23311 A floating-point register (if available). 23312 23313 'I' 23314 An I-type 12-bit signed immediate. 23315 23316 'J' 23317 Integer zero. 23318 23319 'K' 23320 A 5-bit unsigned immediate for CSR access instructions. 23321 23322 'A' 23323 An address that is held in a general-purpose register. 23324 23325_RX--'config/rx/constraints.md'_ 23326 'Q' 23327 An address which does not involve register indirect addressing 23328 or pre/post increment/decrement addressing. 23329 23330 'Symbol' 23331 A symbol reference. 23332 23333 'Int08' 23334 A constant in the range -256 to 255, inclusive. 23335 23336 'Sint08' 23337 A constant in the range -128 to 127, inclusive. 23338 23339 'Sint16' 23340 A constant in the range -32768 to 32767, inclusive. 23341 23342 'Sint24' 23343 A constant in the range -8388608 to 8388607, inclusive. 23344 23345 'Uint04' 23346 A constant in the range 0 to 15, inclusive. 23347 23348_S/390 and zSeries--'config/s390/s390.h'_ 23349 'a' 23350 Address register (general purpose register except r0) 23351 23352 'c' 23353 Condition code register 23354 23355 'd' 23356 Data register (arbitrary general purpose register) 23357 23358 'f' 23359 Floating-point register 23360 23361 'I' 23362 Unsigned 8-bit constant (0-255) 23363 23364 'J' 23365 Unsigned 12-bit constant (0-4095) 23366 23367 'K' 23368 Signed 16-bit constant (-32768-32767) 23369 23370 'L' 23371 Value appropriate as displacement. 23372 '(0..4095)' 23373 for short displacement 23374 '(-524288..524287)' 23375 for long displacement 23376 23377 'M' 23378 Constant integer with a value of 0x7fffffff. 23379 23380 'N' 23381 Multiple letter constraint followed by 4 parameter letters. 23382 '0..9:' 23383 number of the part counting from most to least 23384 significant 23385 'H,Q:' 23386 mode of the part 23387 'D,S,H:' 23388 mode of the containing operand 23389 '0,F:' 23390 value of the other parts (F--all bits set) 23391 The constraint matches if the specified part of a constant has 23392 a value different from its other parts. 23393 23394 'Q' 23395 Memory reference without index register and with short 23396 displacement. 23397 23398 'R' 23399 Memory reference with index register and short displacement. 23400 23401 'S' 23402 Memory reference without index register but with long 23403 displacement. 23404 23405 'T' 23406 Memory reference with index register and long displacement. 23407 23408 'U' 23409 Pointer with short displacement. 23410 23411 'W' 23412 Pointer with long displacement. 23413 23414 'Y' 23415 Shift count operand. 23416 23417_SPARC--'config/sparc/sparc.h'_ 23418 'f' 23419 Floating-point register on the SPARC-V8 architecture and lower 23420 floating-point register on the SPARC-V9 architecture. 23421 23422 'e' 23423 Floating-point register. It is equivalent to 'f' on the 23424 SPARC-V8 architecture and contains both lower and upper 23425 floating-point registers on the SPARC-V9 architecture. 23426 23427 'c' 23428 Floating-point condition code register. 23429 23430 'd' 23431 Lower floating-point register. It is only valid on the 23432 SPARC-V9 architecture when the Visual Instruction Set is 23433 available. 23434 23435 'b' 23436 Floating-point register. It is only valid on the SPARC-V9 23437 architecture when the Visual Instruction Set is available. 23438 23439 'h' 23440 64-bit global or out register for the SPARC-V8+ architecture. 23441 23442 'C' 23443 The constant all-ones, for floating-point. 23444 23445 'A' 23446 Signed 5-bit constant 23447 23448 'D' 23449 A vector constant 23450 23451 'I' 23452 Signed 13-bit constant 23453 23454 'J' 23455 Zero 23456 23457 'K' 23458 32-bit constant with the low 12 bits clear (a constant that 23459 can be loaded with the 'sethi' instruction) 23460 23461 'L' 23462 A constant in the range supported by 'movcc' instructions 23463 (11-bit signed immediate) 23464 23465 'M' 23466 A constant in the range supported by 'movrcc' instructions 23467 (10-bit signed immediate) 23468 23469 'N' 23470 Same as 'K', except that it verifies that bits that are not in 23471 the lower 32-bit range are all zero. Must be used instead of 23472 'K' for modes wider than 'SImode' 23473 23474 'O' 23475 The constant 4096 23476 23477 'G' 23478 Floating-point zero 23479 23480 'H' 23481 Signed 13-bit constant, sign-extended to 32 or 64 bits 23482 23483 'P' 23484 The constant -1 23485 23486 'Q' 23487 Floating-point constant whose integral representation can be 23488 moved into an integer register using a single sethi 23489 instruction 23490 23491 'R' 23492 Floating-point constant whose integral representation can be 23493 moved into an integer register using a single mov instruction 23494 23495 'S' 23496 Floating-point constant whose integral representation can be 23497 moved into an integer register using a high/lo_sum instruction 23498 sequence 23499 23500 'T' 23501 Memory address aligned to an 8-byte boundary 23502 23503 'U' 23504 Even register 23505 23506 'W' 23507 Memory address for 'e' constraint registers 23508 23509 'w' 23510 Memory address with only a base register 23511 23512 'Y' 23513 Vector zero 23514 23515_SPU--'config/spu/spu.h'_ 23516 'a' 23517 An immediate which can be loaded with the il/ila/ilh/ilhu 23518 instructions. const_int is treated as a 64 bit value. 23519 23520 'c' 23521 An immediate for and/xor/or instructions. const_int is 23522 treated as a 64 bit value. 23523 23524 'd' 23525 An immediate for the 'iohl' instruction. const_int is treated 23526 as a 64 bit value. 23527 23528 'f' 23529 An immediate which can be loaded with 'fsmbi'. 23530 23531 'A' 23532 An immediate which can be loaded with the il/ila/ilh/ilhu 23533 instructions. const_int is treated as a 32 bit value. 23534 23535 'B' 23536 An immediate for most arithmetic instructions. const_int is 23537 treated as a 32 bit value. 23538 23539 'C' 23540 An immediate for and/xor/or instructions. const_int is 23541 treated as a 32 bit value. 23542 23543 'D' 23544 An immediate for the 'iohl' instruction. const_int is treated 23545 as a 32 bit value. 23546 23547 'I' 23548 A constant in the range [-64, 63] for shift/rotate 23549 instructions. 23550 23551 'J' 23552 An unsigned 7-bit constant for conversion/nop/channel 23553 instructions. 23554 23555 'K' 23556 A signed 10-bit constant for most arithmetic instructions. 23557 23558 'M' 23559 A signed 16 bit immediate for 'stop'. 23560 23561 'N' 23562 An unsigned 16-bit constant for 'iohl' and 'fsmbi'. 23563 23564 'O' 23565 An unsigned 7-bit constant whose 3 least significant bits are 23566 0. 23567 23568 'P' 23569 An unsigned 3-bit constant for 16-byte rotates and shifts 23570 23571 'R' 23572 Call operand, reg, for indirect calls 23573 23574 'S' 23575 Call operand, symbol, for relative calls. 23576 23577 'T' 23578 Call operand, const_int, for absolute calls. 23579 23580 'U' 23581 An immediate which can be loaded with the il/ila/ilh/ilhu 23582 instructions. const_int is sign extended to 128 bit. 23583 23584 'W' 23585 An immediate for shift and rotate instructions. const_int is 23586 treated as a 32 bit value. 23587 23588 'Y' 23589 An immediate for and/xor/or instructions. const_int is sign 23590 extended as a 128 bit. 23591 23592 'Z' 23593 An immediate for the 'iohl' instruction. const_int is sign 23594 extended to 128 bit. 23595 23596_TI C6X family--'config/c6x/constraints.md'_ 23597 'a' 23598 Register file A (A0-A31). 23599 23600 'b' 23601 Register file B (B0-B31). 23602 23603 'A' 23604 Predicate registers in register file A (A0-A2 on C64X and 23605 higher, A1 and A2 otherwise). 23606 23607 'B' 23608 Predicate registers in register file B (B0-B2). 23609 23610 'C' 23611 A call-used register in register file B (B0-B9, B16-B31). 23612 23613 'Da' 23614 Register file A, excluding predicate registers (A3-A31, plus 23615 A0 if not C64X or higher). 23616 23617 'Db' 23618 Register file B, excluding predicate registers (B3-B31). 23619 23620 'Iu4' 23621 Integer constant in the range 0 ... 15. 23622 23623 'Iu5' 23624 Integer constant in the range 0 ... 31. 23625 23626 'In5' 23627 Integer constant in the range -31 ... 0. 23628 23629 'Is5' 23630 Integer constant in the range -16 ... 15. 23631 23632 'I5x' 23633 Integer constant that can be the operand of an ADDA or a SUBA 23634 insn. 23635 23636 'IuB' 23637 Integer constant in the range 0 ... 65535. 23638 23639 'IsB' 23640 Integer constant in the range -32768 ... 32767. 23641 23642 'IsC' 23643 Integer constant in the range -2^{20} ... 2^{20} - 1. 23644 23645 'Jc' 23646 Integer constant that is a valid mask for the clr instruction. 23647 23648 'Js' 23649 Integer constant that is a valid mask for the set instruction. 23650 23651 'Q' 23652 Memory location with A base register. 23653 23654 'R' 23655 Memory location with B base register. 23656 23657 'S0' 23658 On C64x+ targets, a GP-relative small data reference. 23659 23660 'S1' 23661 Any kind of 'SYMBOL_REF', for use in a call address. 23662 23663 'Si' 23664 Any kind of immediate operand, unless it matches the S0 23665 constraint. 23666 23667 'T' 23668 Memory location with B base register, but not using a long 23669 offset. 23670 23671 'W' 23672 A memory operand with an address that cannot be used in an 23673 unaligned access. 23674 23675 'Z' 23676 Register B14 (aka DP). 23677 23678_TILE-Gx--'config/tilegx/constraints.md'_ 23679 'R00' 23680 'R01' 23681 'R02' 23682 'R03' 23683 'R04' 23684 'R05' 23685 'R06' 23686 'R07' 23687 'R08' 23688 'R09' 23689 'R10' 23690 Each of these represents a register constraint for an 23691 individual register, from r0 to r10. 23692 23693 'I' 23694 Signed 8-bit integer constant. 23695 23696 'J' 23697 Signed 16-bit integer constant. 23698 23699 'K' 23700 Unsigned 16-bit integer constant. 23701 23702 'L' 23703 Integer constant that fits in one signed byte when incremented 23704 by one (-129 ... 126). 23705 23706 'm' 23707 Memory operand. If used together with '<' or '>', the operand 23708 can have postincrement which requires printing with '%In' and 23709 '%in' on TILE-Gx. For example: 23710 23711 asm ("st_add %I0,%1,%i0" : "=m<>" (*mem) : "r" (val)); 23712 23713 'M' 23714 A bit mask suitable for the BFINS instruction. 23715 23716 'N' 23717 Integer constant that is a byte tiled out eight times. 23718 23719 'O' 23720 The integer zero constant. 23721 23722 'P' 23723 Integer constant that is a sign-extended byte tiled out as 23724 four shorts. 23725 23726 'Q' 23727 Integer constant that fits in one signed byte when incremented 23728 (-129 ... 126), but excluding -1. 23729 23730 'S' 23731 Integer constant that has all 1 bits consecutive and starting 23732 at bit 0. 23733 23734 'T' 23735 A 16-bit fragment of a got, tls, or pc-relative reference. 23736 23737 'U' 23738 Memory operand except postincrement. This is roughly the same 23739 as 'm' when not used together with '<' or '>'. 23740 23741 'W' 23742 An 8-element vector constant with identical elements. 23743 23744 'Y' 23745 A 4-element vector constant with identical elements. 23746 23747 'Z0' 23748 The integer constant 0xffffffff. 23749 23750 'Z1' 23751 The integer constant 0xffffffff00000000. 23752 23753_TILEPro--'config/tilepro/constraints.md'_ 23754 'R00' 23755 'R01' 23756 'R02' 23757 'R03' 23758 'R04' 23759 'R05' 23760 'R06' 23761 'R07' 23762 'R08' 23763 'R09' 23764 'R10' 23765 Each of these represents a register constraint for an 23766 individual register, from r0 to r10. 23767 23768 'I' 23769 Signed 8-bit integer constant. 23770 23771 'J' 23772 Signed 16-bit integer constant. 23773 23774 'K' 23775 Nonzero integer constant with low 16 bits zero. 23776 23777 'L' 23778 Integer constant that fits in one signed byte when incremented 23779 by one (-129 ... 126). 23780 23781 'm' 23782 Memory operand. If used together with '<' or '>', the operand 23783 can have postincrement which requires printing with '%In' and 23784 '%in' on TILEPro. For example: 23785 23786 asm ("swadd %I0,%1,%i0" : "=m<>" (mem) : "r" (val)); 23787 23788 'M' 23789 A bit mask suitable for the MM instruction. 23790 23791 'N' 23792 Integer constant that is a byte tiled out four times. 23793 23794 'O' 23795 The integer zero constant. 23796 23797 'P' 23798 Integer constant that is a sign-extended byte tiled out as two 23799 shorts. 23800 23801 'Q' 23802 Integer constant that fits in one signed byte when incremented 23803 (-129 ... 126), but excluding -1. 23804 23805 'T' 23806 A symbolic operand, or a 16-bit fragment of a got, tls, or 23807 pc-relative reference. 23808 23809 'U' 23810 Memory operand except postincrement. This is roughly the same 23811 as 'm' when not used together with '<' or '>'. 23812 23813 'W' 23814 A 4-element vector constant with identical elements. 23815 23816 'Y' 23817 A 2-element vector constant with identical elements. 23818 23819_Visium--'config/visium/constraints.md'_ 23820 'b' 23821 EAM register 'mdb' 23822 23823 'c' 23824 EAM register 'mdc' 23825 23826 'f' 23827 Floating point register 23828 23829 'k' 23830 Register for sibcall optimization 23831 23832 'l' 23833 General register, but not 'r29', 'r30' and 'r31' 23834 23835 't' 23836 Register 'r1' 23837 23838 'u' 23839 Register 'r2' 23840 23841 'v' 23842 Register 'r3' 23843 23844 'G' 23845 Floating-point constant 0.0 23846 23847 'J' 23848 Integer constant in the range 0 .. 65535 (16-bit immediate) 23849 23850 'K' 23851 Integer constant in the range 1 .. 31 (5-bit immediate) 23852 23853 'L' 23854 Integer constant in the range -65535 .. -1 (16-bit negative 23855 immediate) 23856 23857 'M' 23858 Integer constant -1 23859 23860 'O' 23861 Integer constant 0 23862 23863 'P' 23864 Integer constant 32 23865 23866_x86 family--'config/i386/constraints.md'_ 23867 'R' 23868 Legacy register--the eight integer registers available on all 23869 i386 processors ('a', 'b', 'c', 'd', 'si', 'di', 'bp', 'sp'). 23870 23871 'q' 23872 Any register accessible as 'Rl'. In 32-bit mode, 'a', 'b', 23873 'c', and 'd'; in 64-bit mode, any integer register. 23874 23875 'Q' 23876 Any register accessible as 'Rh': 'a', 'b', 'c', and 'd'. 23877 23878 'l' 23879 Any register that can be used as the index in a base+index 23880 memory access: that is, any general register except the stack 23881 pointer. 23882 23883 'a' 23884 The 'a' register. 23885 23886 'b' 23887 The 'b' register. 23888 23889 'c' 23890 The 'c' register. 23891 23892 'd' 23893 The 'd' register. 23894 23895 'S' 23896 The 'si' register. 23897 23898 'D' 23899 The 'di' register. 23900 23901 'A' 23902 The 'a' and 'd' registers. This class is used for 23903 instructions that return double word results in the 'ax:dx' 23904 register pair. Single word values will be allocated either in 23905 'ax' or 'dx'. For example on i386 the following implements 23906 'rdtsc': 23907 23908 unsigned long long rdtsc (void) 23909 { 23910 unsigned long long tick; 23911 __asm__ __volatile__("rdtsc":"=A"(tick)); 23912 return tick; 23913 } 23914 23915 This is not correct on x86-64 as it would allocate tick in 23916 either 'ax' or 'dx'. You have to use the following variant 23917 instead: 23918 23919 unsigned long long rdtsc (void) 23920 { 23921 unsigned int tickl, tickh; 23922 __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh)); 23923 return ((unsigned long long)tickh << 32)|tickl; 23924 } 23925 23926 'U' 23927 The call-clobbered integer registers. 23928 23929 'f' 23930 Any 80387 floating-point (stack) register. 23931 23932 't' 23933 Top of 80387 floating-point stack ('%st(0)'). 23934 23935 'u' 23936 Second from top of 80387 floating-point stack ('%st(1)'). 23937 23938 'Yk' 23939 Any mask register that can be used as a predicate, i.e. 23940 'k1-k7'. 23941 23942 'k' 23943 Any mask register. 23944 23945 'y' 23946 Any MMX register. 23947 23948 'x' 23949 Any SSE register. 23950 23951 'v' 23952 Any EVEX encodable SSE register ('%xmm0-%xmm31'). 23953 23954 'w' 23955 Any bound register. 23956 23957 'Yz' 23958 First SSE register ('%xmm0'). 23959 23960 'Yi' 23961 Any SSE register, when SSE2 and inter-unit moves are enabled. 23962 23963 'Yj' 23964 Any SSE register, when SSE2 and inter-unit moves from vector 23965 registers are enabled. 23966 23967 'Ym' 23968 Any MMX register, when inter-unit moves are enabled. 23969 23970 'Yn' 23971 Any MMX register, when inter-unit moves from vector registers 23972 are enabled. 23973 23974 'Yp' 23975 Any integer register when 'TARGET_PARTIAL_REG_STALL' is 23976 disabled. 23977 23978 'Ya' 23979 Any integer register when zero extensions with 'AND' are 23980 disabled. 23981 23982 'Yb' 23983 Any register that can be used as the GOT base when calling 23984 '___tls_get_addr': that is, any general register except 'a' 23985 and 'sp' registers, for '-fno-plt' if linker supports it. 23986 Otherwise, 'b' register. 23987 23988 'Yf' 23989 Any x87 register when 80387 floating-point arithmetic is 23990 enabled. 23991 23992 'Yr' 23993 Lower SSE register when avoiding REX prefix and all SSE 23994 registers otherwise. 23995 23996 'Yv' 23997 For AVX512VL, any EVEX-encodable SSE register 23998 ('%xmm0-%xmm31'), otherwise any SSE register. 23999 24000 'Yh' 24001 Any EVEX-encodable SSE register, that has number factor of 24002 four. 24003 24004 'Bf' 24005 Flags register operand. 24006 24007 'Bg' 24008 GOT memory operand. 24009 24010 'Bm' 24011 Vector memory operand. 24012 24013 'Bc' 24014 Constant memory operand. 24015 24016 'Bn' 24017 Memory operand without REX prefix. 24018 24019 'Bs' 24020 Sibcall memory operand. 24021 24022 'Bw' 24023 Call memory operand. 24024 24025 'Bz' 24026 Constant call address operand. 24027 24028 'BC' 24029 SSE constant -1 operand. 24030 24031 'I' 24032 Integer constant in the range 0 ... 31, for 32-bit shifts. 24033 24034 'J' 24035 Integer constant in the range 0 ... 63, for 64-bit shifts. 24036 24037 'K' 24038 Signed 8-bit integer constant. 24039 24040 'L' 24041 '0xFF' or '0xFFFF', for andsi as a zero-extending move. 24042 24043 'M' 24044 0, 1, 2, or 3 (shifts for the 'lea' instruction). 24045 24046 'N' 24047 Unsigned 8-bit integer constant (for 'in' and 'out' 24048 instructions). 24049 24050 'O' 24051 Integer constant in the range 0 ... 127, for 128-bit shifts. 24052 24053 'G' 24054 Standard 80387 floating point constant. 24055 24056 'C' 24057 SSE constant zero operand. 24058 24059 'e' 24060 32-bit signed integer constant, or a symbolic reference known 24061 to fit that range (for immediate operands in sign-extending 24062 x86-64 instructions). 24063 24064 'We' 24065 32-bit signed integer constant, or a symbolic reference known 24066 to fit that range (for sign-extending conversion operations 24067 that require non-'VOIDmode' immediate operands). 24068 24069 'Wz' 24070 32-bit unsigned integer constant, or a symbolic reference 24071 known to fit that range (for zero-extending conversion 24072 operations that require non-'VOIDmode' immediate operands). 24073 24074 'Wd' 24075 128-bit integer constant where both the high and low 64-bit 24076 word satisfy the 'e' constraint. 24077 24078 'Z' 24079 32-bit unsigned integer constant, or a symbolic reference 24080 known to fit that range (for immediate operands in 24081 zero-extending x86-64 instructions). 24082 24083 'Tv' 24084 VSIB address operand. 24085 24086 'Ts' 24087 Address operand without segment register. 24088 24089 'Ti' 24090 MPX address operand without index. 24091 24092 'Tb' 24093 MPX address operand without base. 24094 24095_Xstormy16--'config/stormy16/stormy16.h'_ 24096 'a' 24097 Register r0. 24098 24099 'b' 24100 Register r1. 24101 24102 'c' 24103 Register r2. 24104 24105 'd' 24106 Register r8. 24107 24108 'e' 24109 Registers r0 through r7. 24110 24111 't' 24112 Registers r0 and r1. 24113 24114 'y' 24115 The carry register. 24116 24117 'z' 24118 Registers r8 and r9. 24119 24120 'I' 24121 A constant between 0 and 3 inclusive. 24122 24123 'J' 24124 A constant that has exactly one bit set. 24125 24126 'K' 24127 A constant that has exactly one bit clear. 24128 24129 'L' 24130 A constant between 0 and 255 inclusive. 24131 24132 'M' 24133 A constant between -255 and 0 inclusive. 24134 24135 'N' 24136 A constant between -3 and 0 inclusive. 24137 24138 'O' 24139 A constant between 1 and 4 inclusive. 24140 24141 'P' 24142 A constant between -4 and -1 inclusive. 24143 24144 'Q' 24145 A memory reference that is a stack push. 24146 24147 'R' 24148 A memory reference that is a stack pop. 24149 24150 'S' 24151 A memory reference that refers to a constant address of known 24152 value. 24153 24154 'T' 24155 The register indicated by Rx (not implemented yet). 24156 24157 'U' 24158 A constant that is not between 2 and 15 inclusive. 24159 24160 'Z' 24161 The constant 0. 24162 24163_Xtensa--'config/xtensa/constraints.md'_ 24164 'a' 24165 General-purpose 32-bit register 24166 24167 'b' 24168 One-bit boolean register 24169 24170 'A' 24171 MAC16 40-bit accumulator register 24172 24173 'I' 24174 Signed 12-bit integer constant, for use in MOVI instructions 24175 24176 'J' 24177 Signed 8-bit integer constant, for use in ADDI instructions 24178 24179 'K' 24180 Integer constant valid for BccI instructions 24181 24182 'L' 24183 Unsigned constant valid for BccUI instructions 24184 24185 24186File: gccint.info, Node: Disable Insn Alternatives, Next: Define Constraints, Prev: Machine Constraints, Up: Constraints 24187 2418817.8.6 Disable insn alternatives using the 'enabled' attribute 24189-------------------------------------------------------------- 24190 24191There are three insn attributes that may be used to selectively disable 24192instruction alternatives: 24193 24194'enabled' 24195 Says whether an alternative is available on the current subtarget. 24196 24197'preferred_for_size' 24198 Says whether an enabled alternative should be used in code that is 24199 optimized for size. 24200 24201'preferred_for_speed' 24202 Says whether an enabled alternative should be used in code that is 24203 optimized for speed. 24204 24205 All these attributes should use '(const_int 1)' to allow an alternative 24206or '(const_int 0)' to disallow it. The attributes must be a static 24207property of the subtarget; they cannot for example depend on the current 24208operands, on the current optimization level, on the location of the insn 24209within the body of a loop, on whether register allocation has finished, 24210or on the current compiler pass. 24211 24212 The 'enabled' attribute is a correctness property. It tells GCC to act 24213as though the disabled alternatives were never defined in the first 24214place. This is useful when adding new instructions to an existing 24215pattern in cases where the new instructions are only available for 24216certain cpu architecture levels (typically mapped to the '-march=' 24217command-line option). 24218 24219 In contrast, the 'preferred_for_size' and 'preferred_for_speed' 24220attributes are strong optimization hints rather than correctness 24221properties. 'preferred_for_size' tells GCC which alternatives to 24222consider when adding or modifying an instruction that GCC wants to 24223optimize for size. 'preferred_for_speed' does the same thing for speed. 24224Note that things like code motion can lead to cases where code optimized 24225for size uses alternatives that are not preferred for size, and 24226similarly for speed. 24227 24228 Although 'define_insn's can in principle specify the 'enabled' 24229attribute directly, it is often clearer to have subsiduary attributes 24230for each architectural feature of interest. The 'define_insn's can then 24231use these subsiduary attributes to say which alternatives require which 24232features. The example below does this for 'cpu_facility'. 24233 24234 E.g. the following two patterns could easily be merged using the 24235'enabled' attribute: 24236 24237 24238 (define_insn "*movdi_old" 24239 [(set (match_operand:DI 0 "register_operand" "=d") 24240 (match_operand:DI 1 "register_operand" " d"))] 24241 "!TARGET_NEW" 24242 "lgr %0,%1") 24243 24244 (define_insn "*movdi_new" 24245 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 24246 (match_operand:DI 1 "register_operand" " d,d,f"))] 24247 "TARGET_NEW" 24248 "@ 24249 lgr %0,%1 24250 ldgr %0,%1 24251 lgdr %0,%1") 24252 24253 24254 to: 24255 24256 24257 (define_insn "*movdi_combined" 24258 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 24259 (match_operand:DI 1 "register_operand" " d,d,f"))] 24260 "" 24261 "@ 24262 lgr %0,%1 24263 ldgr %0,%1 24264 lgdr %0,%1" 24265 [(set_attr "cpu_facility" "*,new,new")]) 24266 24267 24268 with the 'enabled' attribute defined like this: 24269 24270 24271 (define_attr "cpu_facility" "standard,new" (const_string "standard")) 24272 24273 (define_attr "enabled" "" 24274 (cond [(eq_attr "cpu_facility" "standard") (const_int 1) 24275 (and (eq_attr "cpu_facility" "new") 24276 (ne (symbol_ref "TARGET_NEW") (const_int 0))) 24277 (const_int 1)] 24278 (const_int 0))) 24279 24280 24281 24282File: gccint.info, Node: Define Constraints, Next: C Constraint Interface, Prev: Disable Insn Alternatives, Up: Constraints 24283 2428417.8.7 Defining Machine-Specific Constraints 24285-------------------------------------------- 24286 24287Machine-specific constraints fall into two categories: register and 24288non-register constraints. Within the latter category, constraints which 24289allow subsets of all possible memory or address operands should be 24290specially marked, to give 'reload' more information. 24291 24292 Machine-specific constraints can be given names of arbitrary length, 24293but they must be entirely composed of letters, digits, underscores 24294('_'), and angle brackets ('< >'). Like C identifiers, they must begin 24295with a letter or underscore. 24296 24297 In order to avoid ambiguity in operand constraint strings, no 24298constraint can have a name that begins with any other constraint's name. 24299For example, if 'x' is defined as a constraint name, 'xy' may not be, 24300and vice versa. As a consequence of this rule, no constraint may begin 24301with one of the generic constraint letters: 'E F V X g i m n o p r s'. 24302 24303 Register constraints correspond directly to register classes. *Note 24304Register Classes::. There is thus not much flexibility in their 24305definitions. 24306 24307 -- MD Expression: define_register_constraint name regclass docstring 24308 All three arguments are string constants. NAME is the name of the 24309 constraint, as it will appear in 'match_operand' expressions. If 24310 NAME is a multi-letter constraint its length shall be the same for 24311 all constraints starting with the same letter. REGCLASS can be 24312 either the name of the corresponding register class (*note Register 24313 Classes::), or a C expression which evaluates to the appropriate 24314 register class. If it is an expression, it must have no side 24315 effects, and it cannot look at the operand. The usual use of 24316 expressions is to map some register constraints to 'NO_REGS' when 24317 the register class is not available on a given subarchitecture. 24318 24319 DOCSTRING is a sentence documenting the meaning of the constraint. 24320 Docstrings are explained further below. 24321 24322 Non-register constraints are more like predicates: the constraint 24323definition gives a boolean expression which indicates whether the 24324constraint matches. 24325 24326 -- MD Expression: define_constraint name docstring exp 24327 The NAME and DOCSTRING arguments are the same as for 24328 'define_register_constraint', but note that the docstring comes 24329 immediately after the name for these expressions. EXP is an RTL 24330 expression, obeying the same rules as the RTL expressions in 24331 predicate definitions. *Note Defining Predicates::, for details. 24332 If it evaluates true, the constraint matches; if it evaluates 24333 false, it doesn't. Constraint expressions should indicate which 24334 RTL codes they might match, just like predicate expressions. 24335 24336 'match_test' C expressions have access to the following variables: 24337 24338 OP 24339 The RTL object defining the operand. 24340 MODE 24341 The machine mode of OP. 24342 IVAL 24343 'INTVAL (OP)', if OP is a 'const_int'. 24344 HVAL 24345 'CONST_DOUBLE_HIGH (OP)', if OP is an integer 'const_double'. 24346 LVAL 24347 'CONST_DOUBLE_LOW (OP)', if OP is an integer 'const_double'. 24348 RVAL 24349 'CONST_DOUBLE_REAL_VALUE (OP)', if OP is a floating-point 24350 'const_double'. 24351 24352 The *VAL variables should only be used once another piece of the 24353 expression has verified that OP is the appropriate kind of RTL 24354 object. 24355 24356 Most non-register constraints should be defined with 24357'define_constraint'. The remaining two definition expressions are only 24358appropriate for constraints that should be handled specially by 'reload' 24359if they fail to match. 24360 24361 -- MD Expression: define_memory_constraint name docstring exp 24362 Use this expression for constraints that match a subset of all 24363 memory operands: that is, 'reload' can make them match by 24364 converting the operand to the form '(mem (reg X))', where X is a 24365 base register (from the register class specified by 24366 'BASE_REG_CLASS', *note Register Classes::). 24367 24368 For example, on the S/390, some instructions do not accept 24369 arbitrary memory references, but only those that do not make use of 24370 an index register. The constraint letter 'Q' is defined to 24371 represent a memory address of this type. If 'Q' is defined with 24372 'define_memory_constraint', a 'Q' constraint can handle any memory 24373 operand, because 'reload' knows it can simply copy the memory 24374 address into a base register if required. This is analogous to the 24375 way an 'o' constraint can handle any memory operand. 24376 24377 The syntax and semantics are otherwise identical to 24378 'define_constraint'. 24379 24380 -- MD Expression: define_special_memory_constraint name docstring exp 24381 Use this expression for constraints that match a subset of all 24382 memory operands: that is, 'reload' can not make them match by 24383 reloading the address as it is described for 24384 'define_memory_constraint' or such address reload is undesirable 24385 with the performance point of view. 24386 24387 For example, 'define_special_memory_constraint' can be useful if 24388 specifically aligned memory is necessary or desirable for some insn 24389 operand. 24390 24391 The syntax and semantics are otherwise identical to 24392 'define_constraint'. 24393 24394 -- MD Expression: define_address_constraint name docstring exp 24395 Use this expression for constraints that match a subset of all 24396 address operands: that is, 'reload' can make the constraint match 24397 by converting the operand to the form '(reg X)', again with X a 24398 base register. 24399 24400 Constraints defined with 'define_address_constraint' can only be 24401 used with the 'address_operand' predicate, or machine-specific 24402 predicates that work the same way. They are treated analogously to 24403 the generic 'p' constraint. 24404 24405 The syntax and semantics are otherwise identical to 24406 'define_constraint'. 24407 24408 For historical reasons, names beginning with the letters 'G H' are 24409reserved for constraints that match only 'const_double's, and names 24410beginning with the letters 'I J K L M N O P' are reserved for 24411constraints that match only 'const_int's. This may change in the 24412future. For the time being, constraints with these names must be 24413written in a stylized form, so that 'genpreds' can tell you did it 24414correctly: 24415 24416 (define_constraint "[GHIJKLMNOP]..." 24417 "DOC..." 24418 (and (match_code "const_int") ; 'const_double' for G/H 24419 CONDITION...)) ; usually a 'match_test' 24420 24421 It is fine to use names beginning with other letters for constraints 24422that match 'const_double's or 'const_int's. 24423 24424 Each docstring in a constraint definition should be one or more 24425complete sentences, marked up in Texinfo format. _They are currently 24426unused._ In the future they will be copied into the GCC manual, in 24427*note Machine Constraints::, replacing the hand-maintained tables 24428currently found in that section. Also, in the future the compiler may 24429use this to give more helpful diagnostics when poor choice of 'asm' 24430constraints causes a reload failure. 24431 24432 If you put the pseudo-Texinfo directive '@internal' at the beginning of 24433a docstring, then (in the future) it will appear only in the internals 24434manual's version of the machine-specific constraint tables. Use this 24435for constraints that should not appear in 'asm' statements. 24436 24437 24438File: gccint.info, Node: C Constraint Interface, Prev: Define Constraints, Up: Constraints 24439 2444017.8.8 Testing constraints from C 24441--------------------------------- 24442 24443It is occasionally useful to test a constraint from C code rather than 24444implicitly via the constraint string in a 'match_operand'. The 24445generated file 'tm_p.h' declares a few interfaces for working with 24446constraints. At present these are defined for all constraints except 24447'g' (which is equivalent to 'general_operand'). 24448 24449 Some valid constraint names are not valid C identifiers, so there is a 24450mangling scheme for referring to them from C. Constraint names that do 24451not contain angle brackets or underscores are left unchanged. 24452Underscores are doubled, each '<' is replaced with '_l', and each '>' 24453with '_g'. Here are some examples: 24454 24455 *Original* *Mangled* 24456 x x 24457 P42x P42x 24458 P4_x P4__x 24459 P4>x P4_gx 24460 P4>> P4_g_g 24461 P4_g> P4__g_g 24462 24463 Throughout this section, the variable C is either a constraint in the 24464abstract sense, or a constant from 'enum constraint_num'; the variable M 24465is a mangled constraint name (usually as part of a larger identifier). 24466 24467 -- Enum: constraint_num 24468 For each constraint except 'g', there is a corresponding 24469 enumeration constant: 'CONSTRAINT_' plus the mangled name of the 24470 constraint. Functions that take an 'enum constraint_num' as an 24471 argument expect one of these constants. 24472 24473 -- Function: inline bool satisfies_constraint_M (rtx EXP) 24474 For each non-register constraint M except 'g', there is one of 24475 these functions; it returns 'true' if EXP satisfies the constraint. 24476 These functions are only visible if 'rtl.h' was included before 24477 'tm_p.h'. 24478 24479 -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num 24480 C) 24481 Like the 'satisfies_constraint_M' functions, but the constraint to 24482 test is given as an argument, C. If C specifies a register 24483 constraint, this function will always return 'false'. 24484 24485 -- Function: enum reg_class reg_class_for_constraint (enum 24486 constraint_num C) 24487 Returns the register class associated with C. If C is not a 24488 register constraint, or those registers are not available for the 24489 currently selected subtarget, returns 'NO_REGS'. 24490 24491 Here is an example use of 'satisfies_constraint_M'. In peephole 24492optimizations (*note Peephole Definitions::), operand constraint strings 24493are ignored, so if there are relevant constraints, they must be tested 24494in the C condition. In the example, the optimization is applied if 24495operand 2 does _not_ satisfy the 'K' constraint. (This is a simplified 24496version of a peephole definition from the i386 machine description.) 24497 24498 (define_peephole2 24499 [(match_scratch:SI 3 "r") 24500 (set (match_operand:SI 0 "register_operand" "") 24501 (mult:SI (match_operand:SI 1 "memory_operand" "") 24502 (match_operand:SI 2 "immediate_operand" "")))] 24503 24504 "!satisfies_constraint_K (operands[2])" 24505 24506 [(set (match_dup 3) (match_dup 1)) 24507 (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))] 24508 24509 "") 24510 24511 24512File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc 24513 2451417.9 Standard Pattern Names For Generation 24515========================================== 24516 24517Here is a table of the instruction names that are meaningful in the RTL 24518generation pass of the compiler. Giving one of these names to an 24519instruction pattern tells the RTL generation pass that it can use the 24520pattern to accomplish a certain task. 24521 24522'movM' 24523 Here M stands for a two-letter machine mode name, in lowercase. 24524 This instruction pattern moves data with that machine mode from 24525 operand 1 to operand 0. For example, 'movsi' moves full-word data. 24526 24527 If operand 0 is a 'subreg' with mode M of a register whose own mode 24528 is wider than M, the effect of this instruction is to store the 24529 specified value in the part of the register that corresponds to 24530 mode M. Bits outside of M, but which are within the same target 24531 word as the 'subreg' are undefined. Bits which are outside the 24532 target word are left unchanged. 24533 24534 This class of patterns is special in several ways. First of all, 24535 each of these names up to and including full word size _must_ be 24536 defined, because there is no other way to copy a datum from one 24537 place to another. If there are patterns accepting operands in 24538 larger modes, 'movM' must be defined for integer modes of those 24539 sizes. 24540 24541 Second, these patterns are not used solely in the RTL generation 24542 pass. Even the reload pass can generate move insns to copy values 24543 from stack slots into temporary registers. When it does so, one of 24544 the operands is a hard register and the other is an operand that 24545 can need to be reloaded into a register. 24546 24547 Therefore, when given such a pair of operands, the pattern must 24548 generate RTL which needs no reloading and needs no temporary 24549 registers--no registers other than the operands. For example, if 24550 you support the pattern with a 'define_expand', then in such a case 24551 the 'define_expand' mustn't call 'force_reg' or any other such 24552 function which might generate new pseudo registers. 24553 24554 This requirement exists even for subword modes on a RISC machine 24555 where fetching those modes from memory normally requires several 24556 insns and some temporary registers. 24557 24558 During reload a memory reference with an invalid address may be 24559 passed as an operand. Such an address will be replaced with a 24560 valid address later in the reload pass. In this case, nothing may 24561 be done with the address except to use it as it stands. If it is 24562 copied, it will not be replaced with a valid address. No attempt 24563 should be made to make such an address into a valid address and no 24564 routine (such as 'change_address') that will do so may be called. 24565 Note that 'general_operand' will fail when applied to such an 24566 address. 24567 24568 The global variable 'reload_in_progress' (which must be explicitly 24569 declared if required) can be used to determine whether such special 24570 handling is required. 24571 24572 The variety of operands that have reloads depends on the rest of 24573 the machine description, but typically on a RISC machine these can 24574 only be pseudo registers that did not get hard registers, while on 24575 other machines explicit memory references will get optional 24576 reloads. 24577 24578 If a scratch register is required to move an object to or from 24579 memory, it can be allocated using 'gen_reg_rtx' prior to life 24580 analysis. 24581 24582 If there are cases which need scratch registers during or after 24583 reload, you must provide an appropriate secondary_reload target 24584 hook. 24585 24586 The macro 'can_create_pseudo_p' can be used to determine if it is 24587 unsafe to create new pseudo registers. If this variable is 24588 nonzero, then it is unsafe to call 'gen_reg_rtx' to allocate a new 24589 pseudo. 24590 24591 The constraints on a 'movM' must permit moving any hard register to 24592 any other hard register provided that 'TARGET_HARD_REGNO_MODE_OK' 24593 permits mode M in both registers and 'TARGET_REGISTER_MOVE_COST' 24594 applied to their classes returns a value of 2. 24595 24596 It is obligatory to support floating point 'movM' instructions into 24597 and out of any registers that can hold fixed point values, because 24598 unions and structures (which have modes 'SImode' or 'DImode') can 24599 be in those registers and they may have floating point members. 24600 24601 There may also be a need to support fixed point 'movM' instructions 24602 in and out of floating point registers. Unfortunately, I have 24603 forgotten why this was so, and I don't know whether it is still 24604 true. If 'TARGET_HARD_REGNO_MODE_OK' rejects fixed point values in 24605 floating point registers, then the constraints of the fixed point 24606 'movM' instructions must be designed to avoid ever trying to reload 24607 into a floating point register. 24608 24609'reload_inM' 24610'reload_outM' 24611 These named patterns have been obsoleted by the target hook 24612 'secondary_reload'. 24613 24614 Like 'movM', but used when a scratch register is required to move 24615 between operand 0 and operand 1. Operand 2 describes the scratch 24616 register. See the discussion of the 'SECONDARY_RELOAD_CLASS' macro 24617 in *note Register Classes::. 24618 24619 There are special restrictions on the form of the 'match_operand's 24620 used in these patterns. First, only the predicate for the reload 24621 operand is examined, i.e., 'reload_in' examines operand 1, but not 24622 the predicates for operand 0 or 2. Second, there may be only one 24623 alternative in the constraints. Third, only a single register 24624 class letter may be used for the constraint; subsequent constraint 24625 letters are ignored. As a special exception, an empty constraint 24626 string matches the 'ALL_REGS' register class. This may relieve 24627 ports of the burden of defining an 'ALL_REGS' constraint letter 24628 just for these patterns. 24629 24630'movstrictM' 24631 Like 'movM' except that if operand 0 is a 'subreg' with mode M of a 24632 register whose natural mode is wider, the 'movstrictM' instruction 24633 is guaranteed not to alter any of the register except the part 24634 which belongs to mode M. 24635 24636'movmisalignM' 24637 This variant of a move pattern is designed to load or store a value 24638 from a memory address that is not naturally aligned for its mode. 24639 For a store, the memory will be in operand 0; for a load, the 24640 memory will be in operand 1. The other operand is guaranteed not 24641 to be a memory, so that it's easy to tell whether this is a load or 24642 store. 24643 24644 This pattern is used by the autovectorizer, and when expanding a 24645 'MISALIGNED_INDIRECT_REF' expression. 24646 24647'load_multiple' 24648 Load several consecutive memory locations into consecutive 24649 registers. Operand 0 is the first of the consecutive registers, 24650 operand 1 is the first memory location, and operand 2 is a 24651 constant: the number of consecutive registers. 24652 24653 Define this only if the target machine really has such an 24654 instruction; do not define this if the most efficient way of 24655 loading consecutive registers from memory is to do them one at a 24656 time. 24657 24658 On some machines, there are restrictions as to which consecutive 24659 registers can be stored into memory, such as particular starting or 24660 ending register numbers or only a range of valid counts. For those 24661 machines, use a 'define_expand' (*note Expander Definitions::) and 24662 make the pattern fail if the restrictions are not met. 24663 24664 Write the generated insn as a 'parallel' with elements being a 24665 'set' of one register from the appropriate memory location (you may 24666 also need 'use' or 'clobber' elements). Use a 'match_parallel' 24667 (*note RTL Template::) to recognize the insn. See 'rs6000.md' for 24668 examples of the use of this insn pattern. 24669 24670'store_multiple' 24671 Similar to 'load_multiple', but store several consecutive registers 24672 into consecutive memory locations. Operand 0 is the first of the 24673 consecutive memory locations, operand 1 is the first register, and 24674 operand 2 is a constant: the number of consecutive registers. 24675 24676'vec_load_lanesMN' 24677 Perform an interleaved load of several vectors from memory operand 24678 1 into register operand 0. Both operands have mode M. The 24679 register operand is viewed as holding consecutive vectors of mode 24680 N, while the memory operand is a flat array that contains the same 24681 number of elements. The operation is equivalent to: 24682 24683 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 24684 for (j = 0; j < GET_MODE_NUNITS (N); j++) 24685 for (i = 0; i < c; i++) 24686 operand0[i][j] = operand1[j * c + i]; 24687 24688 For example, 'vec_load_lanestiv4hi' loads 8 16-bit values from 24689 memory into a register of mode 'TI'. The register contains two 24690 consecutive vectors of mode 'V4HI'. 24691 24692 This pattern can only be used if: 24693 TARGET_ARRAY_MODE_SUPPORTED_P (N, C) 24694 is true. GCC assumes that, if a target supports this kind of 24695 instruction for some mode N, it also supports unaligned loads for 24696 vectors of mode N. 24697 24698 This pattern is not allowed to 'FAIL'. 24699 24700'vec_mask_load_lanesMN' 24701 Like 'vec_load_lanesMN', but takes an additional mask operand 24702 (operand 2) that specifies which elements of the destination 24703 vectors should be loaded. Other elements of the destination 24704 vectors are set to zero. The operation is equivalent to: 24705 24706 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 24707 for (j = 0; j < GET_MODE_NUNITS (N); j++) 24708 if (operand2[j]) 24709 for (i = 0; i < c; i++) 24710 operand0[i][j] = operand1[j * c + i]; 24711 else 24712 for (i = 0; i < c; i++) 24713 operand0[i][j] = 0; 24714 24715 This pattern is not allowed to 'FAIL'. 24716 24717'vec_store_lanesMN' 24718 Equivalent to 'vec_load_lanesMN', with the memory and register 24719 operands reversed. That is, the instruction is equivalent to: 24720 24721 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 24722 for (j = 0; j < GET_MODE_NUNITS (N); j++) 24723 for (i = 0; i < c; i++) 24724 operand0[j * c + i] = operand1[i][j]; 24725 24726 for a memory operand 0 and register operand 1. 24727 24728 This pattern is not allowed to 'FAIL'. 24729 24730'vec_mask_store_lanesMN' 24731 Like 'vec_store_lanesMN', but takes an additional mask operand 24732 (operand 2) that specifies which elements of the source vectors 24733 should be stored. The operation is equivalent to: 24734 24735 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 24736 for (j = 0; j < GET_MODE_NUNITS (N); j++) 24737 if (operand2[j]) 24738 for (i = 0; i < c; i++) 24739 operand0[j * c + i] = operand1[i][j]; 24740 24741 This pattern is not allowed to 'FAIL'. 24742 24743'gather_loadM' 24744 Load several separate memory locations into a vector of mode M. 24745 Operand 1 is a scalar base address and operand 2 is a vector of 24746 offsets from that base. Operand 0 is a destination vector with the 24747 same number of elements as the offset. For each element index I: 24748 24749 * extend the offset element I to address width, using zero 24750 extension if operand 3 is 1 and sign extension if operand 3 is 24751 zero; 24752 * multiply the extended offset by operand 4; 24753 * add the result to the base; and 24754 * load the value at that address into element I of operand 0. 24755 24756 The value of operand 3 does not matter if the offsets are already 24757 address width. 24758 24759'mask_gather_loadM' 24760 Like 'gather_loadM', but takes an extra mask operand as operand 5. 24761 Bit I of the mask is set if element I of the result should be 24762 loaded from memory and clear if element I of the result should be 24763 set to zero. 24764 24765'scatter_storeM' 24766 Store a vector of mode M into several distinct memory locations. 24767 Operand 0 is a scalar base address and operand 1 is a vector of 24768 offsets from that base. Operand 4 is the vector of values that 24769 should be stored, which has the same number of elements as the 24770 offset. For each element index I: 24771 24772 * extend the offset element I to address width, using zero 24773 extension if operand 2 is 1 and sign extension if operand 2 is 24774 zero; 24775 * multiply the extended offset by operand 3; 24776 * add the result to the base; and 24777 * store element I of operand 4 to that address. 24778 24779 The value of operand 2 does not matter if the offsets are already 24780 address width. 24781 24782'mask_scatter_storeM' 24783 Like 'scatter_storeM', but takes an extra mask operand as operand 24784 5. Bit I of the mask is set if element I of the result should be 24785 stored to memory. 24786 24787'vec_setM' 24788 Set given field in the vector value. Operand 0 is the vector to 24789 modify, operand 1 is new value of field and operand 2 specify the 24790 field index. 24791 24792'vec_extractMN' 24793 Extract given field from the vector value. Operand 1 is the 24794 vector, operand 2 specify field index and operand 0 place to store 24795 value into. The N mode is the mode of the field or vector of 24796 fields that should be extracted, should be either element mode of 24797 the vector mode M, or a vector mode with the same element mode and 24798 smaller number of elements. If N is a vector mode, the index is 24799 counted in units of that mode. 24800 24801'vec_initMN' 24802 Initialize the vector to given values. Operand 0 is the vector to 24803 initialize and operand 1 is parallel containing values for 24804 individual fields. The N mode is the mode of the elements, should 24805 be either element mode of the vector mode M, or a vector mode with 24806 the same element mode and smaller number of elements. 24807 24808'vec_duplicateM' 24809 Initialize vector output operand 0 so that each element has the 24810 value given by scalar input operand 1. The vector has mode M and 24811 the scalar has the mode appropriate for one element of M. 24812 24813 This pattern only handles duplicates of non-constant inputs. 24814 Constant vectors go through the 'movM' pattern instead. 24815 24816 This pattern is not allowed to 'FAIL'. 24817 24818'vec_seriesM' 24819 Initialize vector output operand 0 so that element I is equal to 24820 operand 1 plus I times operand 2. In other words, create a linear 24821 series whose base value is operand 1 and whose step is operand 2. 24822 24823 The vector output has mode M and the scalar inputs have the mode 24824 appropriate for one element of M. This pattern is not used for 24825 floating-point vectors, in order to avoid having to specify the 24826 rounding behavior for I > 1. 24827 24828 This pattern is not allowed to 'FAIL'. 24829 24830'while_ultMN' 24831 Set operand 0 to a mask that is true while incrementing operand 1 24832 gives a value that is less than operand 2. Operand 0 has mode N 24833 and operands 1 and 2 are scalar integers of mode M. The operation 24834 is equivalent to: 24835 24836 operand0[0] = operand1 < operand2; 24837 for (i = 1; i < GET_MODE_NUNITS (N); i++) 24838 operand0[i] = operand0[i - 1] && (operand1 + i < operand2); 24839 24840'vec_cmpMN' 24841 Output a vector comparison. Operand 0 of mode N is the destination 24842 for predicate in operand 1 which is a signed vector comparison with 24843 operands of mode M in operands 2 and 3. Predicate is computed by 24844 element-wise evaluation of the vector comparison with a truth value 24845 of all-ones and a false value of all-zeros. 24846 24847'vec_cmpuMN' 24848 Similar to 'vec_cmpMN' but perform unsigned vector comparison. 24849 24850'vec_cmpeqMN' 24851 Similar to 'vec_cmpMN' but perform equality or non-equality vector 24852 comparison only. If 'vec_cmpMN' or 'vec_cmpuMN' instruction 24853 pattern is supported, it will be preferred over 'vec_cmpeqMN', so 24854 there is no need to define this instruction pattern if the others 24855 are supported. 24856 24857'vcondMN' 24858 Output a conditional vector move. Operand 0 is the destination to 24859 receive a combination of operand 1 and operand 2, which are of mode 24860 M, dependent on the outcome of the predicate in operand 3 which is 24861 a signed vector comparison with operands of mode N in operands 4 24862 and 5. The modes M and N should have the same size. Operand 0 24863 will be set to the value OP1 & MSK | OP2 & ~MSK where MSK is 24864 computed by element-wise evaluation of the vector comparison with a 24865 truth value of all-ones and a false value of all-zeros. 24866 24867'vconduMN' 24868 Similar to 'vcondMN' but performs unsigned vector comparison. 24869 24870'vcondeqMN' 24871 Similar to 'vcondMN' but performs equality or non-equality vector 24872 comparison only. If 'vcondMN' or 'vconduMN' instruction pattern is 24873 supported, it will be preferred over 'vcondeqMN', so there is no 24874 need to define this instruction pattern if the others are 24875 supported. 24876 24877'vcond_mask_MN' 24878 Similar to 'vcondMN' but operand 3 holds a pre-computed result of 24879 vector comparison. 24880 24881'maskloadMN' 24882 Perform a masked load of vector from memory operand 1 of mode M 24883 into register operand 0. Mask is provided in register operand 2 of 24884 mode N. 24885 24886 This pattern is not allowed to 'FAIL'. 24887 24888'maskstoreMN' 24889 Perform a masked store of vector from register operand 1 of mode M 24890 into memory operand 0. Mask is provided in register operand 2 of 24891 mode N. 24892 24893 This pattern is not allowed to 'FAIL'. 24894 24895'vec_permM' 24896 Output a (variable) vector permutation. Operand 0 is the 24897 destination to receive elements from operand 1 and operand 2, which 24898 are of mode M. Operand 3 is the "selector". It is an integral 24899 mode vector of the same width and number of elements as mode M. 24900 24901 The input elements are numbered from 0 in operand 1 through 2*N-1 24902 in operand 2. The elements of the selector must be computed modulo 24903 2*N. Note that if 'rtx_equal_p(operand1, operand2)', this can be 24904 implemented with just operand 1 and selector elements modulo N. 24905 24906 In order to make things easy for a number of targets, if there is 24907 no 'vec_perm' pattern for mode M, but there is for mode Q where Q 24908 is a vector of 'QImode' of the same width as M, the middle-end will 24909 lower the mode M 'VEC_PERM_EXPR' to mode Q. 24910 24911 See also 'TARGET_VECTORIZER_VEC_PERM_CONST', which performs the 24912 analogous operation for constant selectors. 24913 24914'pushM1' 24915 Output a push instruction. Operand 0 is value to push. Used only 24916 when 'PUSH_ROUNDING' is defined. For historical reason, this 24917 pattern may be missing and in such case an 'mov' expander is used 24918 instead, with a 'MEM' expression forming the push operation. The 24919 'mov' expander method is deprecated. 24920 24921'addM3' 24922 Add operand 2 and operand 1, storing the result in operand 0. All 24923 operands must have mode M. This can be used even on two-address 24924 machines, by means of constraints requiring operands 1 and 0 to be 24925 the same location. 24926 24927'ssaddM3', 'usaddM3' 24928'subM3', 'sssubM3', 'ussubM3' 24929'mulM3', 'ssmulM3', 'usmulM3' 24930'divM3', 'ssdivM3' 24931'udivM3', 'usdivM3' 24932'modM3', 'umodM3' 24933'uminM3', 'umaxM3' 24934'andM3', 'iorM3', 'xorM3' 24935 Similar, for other arithmetic operations. 24936 24937'addvM4' 24938 Like 'addM3' but takes a 'code_label' as operand 3 and emits code 24939 to jump to it if signed overflow occurs during the addition. This 24940 pattern is used to implement the built-in functions performing 24941 signed integer addition with overflow checking. 24942 24943'subvM4', 'mulvM4' 24944 Similar, for other signed arithmetic operations. 24945 24946'uaddvM4' 24947 Like 'addvM4' but for unsigned addition. That is to say, the 24948 operation is the same as signed addition but the jump is taken only 24949 on unsigned overflow. 24950 24951'usubvM4', 'umulvM4' 24952 Similar, for other unsigned arithmetic operations. 24953 24954'addptrM3' 24955 Like 'addM3' but is guaranteed to only be used for address 24956 calculations. The expanded code is not allowed to clobber the 24957 condition code. It only needs to be defined if 'addM3' sets the 24958 condition code. If adds used for address calculations and normal 24959 adds are not compatible it is required to expand a distinct pattern 24960 (e.g. using an unspec). The pattern is used by LRA to emit 24961 address calculations. 'addM3' is used if 'addptrM3' is not 24962 defined. 24963 24964'fmaM4' 24965 Multiply operand 2 and operand 1, then add operand 3, storing the 24966 result in operand 0 without doing an intermediate rounding step. 24967 All operands must have mode M. This pattern is used to implement 24968 the 'fma', 'fmaf', and 'fmal' builtin functions from the ISO C99 24969 standard. 24970 24971'fmsM4' 24972 Like 'fmaM4', except operand 3 subtracted from the product instead 24973 of added to the product. This is represented in the rtl as 24974 24975 (fma:M OP1 OP2 (neg:M OP3)) 24976 24977'fnmaM4' 24978 Like 'fmaM4' except that the intermediate product is negated before 24979 being added to operand 3. This is represented in the rtl as 24980 24981 (fma:M (neg:M OP1) OP2 OP3) 24982 24983'fnmsM4' 24984 Like 'fmsM4' except that the intermediate product is negated before 24985 subtracting operand 3. This is represented in the rtl as 24986 24987 (fma:M (neg:M OP1) OP2 (neg:M OP3)) 24988 24989'sminM3', 'smaxM3' 24990 Signed minimum and maximum operations. When used with floating 24991 point, if both operands are zeros, or if either operand is 'NaN', 24992 then it is unspecified which of the two operands is returned as the 24993 result. 24994 24995'fminM3', 'fmaxM3' 24996 IEEE-conformant minimum and maximum operations. If one operand is 24997 a quiet 'NaN', then the other operand is returned. If both 24998 operands are quiet 'NaN', then a quiet 'NaN' is returned. In the 24999 case when gcc supports signaling 'NaN' (-fsignaling-nans) an 25000 invalid floating point exception is raised and a quiet 'NaN' is 25001 returned. 25002 25003 All operands have mode M, which is a scalar or vector 25004 floating-point mode. These patterns are not allowed to 'FAIL'. 25005 25006'reduc_smin_scal_M', 'reduc_smax_scal_M' 25007 Find the signed minimum/maximum of the elements of a vector. The 25008 vector is operand 1, and operand 0 is the scalar result, with mode 25009 equal to the mode of the elements of the input vector. 25010 25011'reduc_umin_scal_M', 'reduc_umax_scal_M' 25012 Find the unsigned minimum/maximum of the elements of a vector. The 25013 vector is operand 1, and operand 0 is the scalar result, with mode 25014 equal to the mode of the elements of the input vector. 25015 25016'reduc_plus_scal_M' 25017 Compute the sum of the elements of a vector. The vector is operand 25018 1, and operand 0 is the scalar result, with mode equal to the mode 25019 of the elements of the input vector. 25020 25021'reduc_and_scal_M' 25022'reduc_ior_scal_M' 25023'reduc_xor_scal_M' 25024 Compute the bitwise 'AND'/'IOR'/'XOR' reduction of the elements of 25025 a vector of mode M. Operand 1 is the vector input and operand 0 is 25026 the scalar result. The mode of the scalar result is the same as 25027 one element of M. 25028 25029'extract_last_M' 25030 Find the last set bit in mask operand 1 and extract the associated 25031 element of vector operand 2. Store the result in scalar operand 0. 25032 Operand 2 has vector mode M while operand 0 has the mode 25033 appropriate for one element of M. Operand 1 has the usual mask 25034 mode for vectors of mode M; see 'TARGET_VECTORIZE_GET_MASK_MODE'. 25035 25036'fold_extract_last_M' 25037 If any bits of mask operand 2 are set, find the last set bit, 25038 extract the associated element from vector operand 3, and store the 25039 result in operand 0. Store operand 1 in operand 0 otherwise. 25040 Operand 3 has mode M and operands 0 and 1 have the mode appropriate 25041 for one element of M. Operand 2 has the usual mask mode for 25042 vectors of mode M; see 'TARGET_VECTORIZE_GET_MASK_MODE'. 25043 25044'fold_left_plus_M' 25045 Take scalar operand 1 and successively add each element from vector 25046 operand 2. Store the result in scalar operand 0. The vector has 25047 mode M and the scalars have the mode appropriate for one element of 25048 M. The operation is strictly in-order: there is no reassociation. 25049 25050'sdot_prodM' 25051'udot_prodM' 25052 Compute the sum of the products of two signed/unsigned elements. 25053 Operand 1 and operand 2 are of the same mode. Their product, which 25054 is of a wider mode, is computed and added to operand 3. Operand 3 25055 is of a mode equal or wider than the mode of the product. The 25056 result is placed in operand 0, which is of the same mode as operand 25057 3. 25058 25059'ssadM' 25060'usadM' 25061 Compute the sum of absolute differences of two signed/unsigned 25062 elements. Operand 1 and operand 2 are of the same mode. Their 25063 absolute difference, which is of a wider mode, is computed and 25064 added to operand 3. Operand 3 is of a mode equal or wider than the 25065 mode of the absolute difference. The result is placed in operand 25066 0, which is of the same mode as operand 3. 25067 25068'widen_ssumM3' 25069'widen_usumM3' 25070 Operands 0 and 2 are of the same mode, which is wider than the mode 25071 of operand 1. Add operand 1 to operand 2 and place the widened 25072 result in operand 0. (This is used express accumulation of 25073 elements into an accumulator of a wider mode.) 25074 25075'vec_shl_insert_M' 25076 Shift the elements in vector input operand 1 left one element (i.e. 25077 away from element 0) and fill the vacated element 0 with the scalar 25078 in operand 2. Store the result in vector output operand 0. 25079 Operands 0 and 1 have mode M and operand 2 has the mode appropriate 25080 for one element of M. 25081 25082'vec_shr_M' 25083 Whole vector right shift in bits, i.e. towards element 0. Operand 25084 1 is a vector to be shifted. Operand 2 is an integer shift amount 25085 in bits. Operand 0 is where the resulting shifted vector is 25086 stored. The output and input vectors should have the same modes. 25087 25088'vec_pack_trunc_M' 25089 Narrow (demote) and merge the elements of two vectors. Operands 1 25090 and 2 are vectors of the same mode having N integral or floating 25091 point elements of size S. Operand 0 is the resulting vector in 25092 which 2*N elements of size N/2 are concatenated after narrowing 25093 them down using truncation. 25094 25095'vec_pack_ssat_M', 'vec_pack_usat_M' 25096 Narrow (demote) and merge the elements of two vectors. Operands 1 25097 and 2 are vectors of the same mode having N integral elements of 25098 size S. Operand 0 is the resulting vector in which the elements of 25099 the two input vectors are concatenated after narrowing them down 25100 using signed/unsigned saturating arithmetic. 25101 25102'vec_pack_sfix_trunc_M', 'vec_pack_ufix_trunc_M' 25103 Narrow, convert to signed/unsigned integral type and merge the 25104 elements of two vectors. Operands 1 and 2 are vectors of the same 25105 mode having N floating point elements of size S. Operand 0 is the 25106 resulting vector in which 2*N elements of size N/2 are 25107 concatenated. 25108 25109'vec_unpacks_hi_M', 'vec_unpacks_lo_M' 25110 Extract and widen (promote) the high/low part of a vector of signed 25111 integral or floating point elements. The input vector (operand 1) 25112 has N elements of size S. Widen (promote) the high/low elements of 25113 the vector using signed or floating point extension and place the 25114 resulting N/2 values of size 2*S in the output vector (operand 0). 25115 25116'vec_unpacku_hi_M', 'vec_unpacku_lo_M' 25117 Extract and widen (promote) the high/low part of a vector of 25118 unsigned integral elements. The input vector (operand 1) has N 25119 elements of size S. Widen (promote) the high/low elements of the 25120 vector using zero extension and place the resulting N/2 values of 25121 size 2*S in the output vector (operand 0). 25122 25123'vec_unpacks_float_hi_M', 'vec_unpacks_float_lo_M' 25124'vec_unpacku_float_hi_M', 'vec_unpacku_float_lo_M' 25125 Extract, convert to floating point type and widen the high/low part 25126 of a vector of signed/unsigned integral elements. The input vector 25127 (operand 1) has N elements of size S. Convert the high/low 25128 elements of the vector using floating point conversion and place 25129 the resulting N/2 values of size 2*S in the output vector (operand 25130 0). 25131 25132'vec_widen_umult_hi_M', 'vec_widen_umult_lo_M' 25133'vec_widen_smult_hi_M', 'vec_widen_smult_lo_M' 25134'vec_widen_umult_even_M', 'vec_widen_umult_odd_M' 25135'vec_widen_smult_even_M', 'vec_widen_smult_odd_M' 25136 Signed/Unsigned widening multiplication. The two inputs (operands 25137 1 and 2) are vectors with N signed/unsigned elements of size S. 25138 Multiply the high/low or even/odd elements of the two vectors, and 25139 put the N/2 products of size 2*S in the output vector (operand 0). 25140 A target shouldn't implement even/odd pattern pair if it is less 25141 efficient than lo/hi one. 25142 25143'vec_widen_ushiftl_hi_M', 'vec_widen_ushiftl_lo_M' 25144'vec_widen_sshiftl_hi_M', 'vec_widen_sshiftl_lo_M' 25145 Signed/Unsigned widening shift left. The first input (operand 1) 25146 is a vector with N signed/unsigned elements of size S. Operand 2 25147 is a constant. Shift the high/low elements of operand 1, and put 25148 the N/2 results of size 2*S in the output vector (operand 0). 25149 25150'mulhisi3' 25151 Multiply operands 1 and 2, which have mode 'HImode', and store a 25152 'SImode' product in operand 0. 25153 25154'mulqihi3', 'mulsidi3' 25155 Similar widening-multiplication instructions of other widths. 25156 25157'umulqihi3', 'umulhisi3', 'umulsidi3' 25158 Similar widening-multiplication instructions that do unsigned 25159 multiplication. 25160 25161'usmulqihi3', 'usmulhisi3', 'usmulsidi3' 25162 Similar widening-multiplication instructions that interpret the 25163 first operand as unsigned and the second operand as signed, then do 25164 a signed multiplication. 25165 25166'smulM3_highpart' 25167 Perform a signed multiplication of operands 1 and 2, which have 25168 mode M, and store the most significant half of the product in 25169 operand 0. The least significant half of the product is discarded. 25170 25171'umulM3_highpart' 25172 Similar, but the multiplication is unsigned. 25173 25174'maddMN4' 25175 Multiply operands 1 and 2, sign-extend them to mode N, add operand 25176 3, and store the result in operand 0. Operands 1 and 2 have mode M 25177 and operands 0 and 3 have mode N. Both modes must be integer or 25178 fixed-point modes and N must be twice the size of M. 25179 25180 In other words, 'maddMN4' is like 'mulMN3' except that it also adds 25181 operand 3. 25182 25183 These instructions are not allowed to 'FAIL'. 25184 25185'umaddMN4' 25186 Like 'maddMN4', but zero-extend the multiplication operands instead 25187 of sign-extending them. 25188 25189'ssmaddMN4' 25190 Like 'maddMN4', but all involved operations must be 25191 signed-saturating. 25192 25193'usmaddMN4' 25194 Like 'umaddMN4', but all involved operations must be 25195 unsigned-saturating. 25196 25197'msubMN4' 25198 Multiply operands 1 and 2, sign-extend them to mode N, subtract the 25199 result from operand 3, and store the result in operand 0. Operands 25200 1 and 2 have mode M and operands 0 and 3 have mode N. Both modes 25201 must be integer or fixed-point modes and N must be twice the size 25202 of M. 25203 25204 In other words, 'msubMN4' is like 'mulMN3' except that it also 25205 subtracts the result from operand 3. 25206 25207 These instructions are not allowed to 'FAIL'. 25208 25209'umsubMN4' 25210 Like 'msubMN4', but zero-extend the multiplication operands instead 25211 of sign-extending them. 25212 25213'ssmsubMN4' 25214 Like 'msubMN4', but all involved operations must be 25215 signed-saturating. 25216 25217'usmsubMN4' 25218 Like 'umsubMN4', but all involved operations must be 25219 unsigned-saturating. 25220 25221'divmodM4' 25222 Signed division that produces both a quotient and a remainder. 25223 Operand 1 is divided by operand 2 to produce a quotient stored in 25224 operand 0 and a remainder stored in operand 3. 25225 25226 For machines with an instruction that produces both a quotient and 25227 a remainder, provide a pattern for 'divmodM4' but do not provide 25228 patterns for 'divM3' and 'modM3'. This allows optimization in the 25229 relatively common case when both the quotient and remainder are 25230 computed. 25231 25232 If an instruction that just produces a quotient or just a remainder 25233 exists and is more efficient than the instruction that produces 25234 both, write the output routine of 'divmodM4' to call 25235 'find_reg_note' and look for a 'REG_UNUSED' note on the quotient or 25236 remainder and generate the appropriate instruction. 25237 25238'udivmodM4' 25239 Similar, but does unsigned division. 25240 25241'ashlM3', 'ssashlM3', 'usashlM3' 25242 Arithmetic-shift operand 1 left by a number of bits specified by 25243 operand 2, and store the result in operand 0. Here M is the mode 25244 of operand 0 and operand 1; operand 2's mode is specified by the 25245 instruction pattern, and the compiler will convert the operand to 25246 that mode before generating the instruction. The shift or rotate 25247 expander or instruction pattern should explicitly specify the mode 25248 of the operand 2, it should never be 'VOIDmode'. The meaning of 25249 out-of-range shift counts can optionally be specified by 25250 'TARGET_SHIFT_TRUNCATION_MASK'. *Note 25251 TARGET_SHIFT_TRUNCATION_MASK::. Operand 2 is always a scalar type. 25252 25253'ashrM3', 'lshrM3', 'rotlM3', 'rotrM3' 25254 Other shift and rotate instructions, analogous to the 'ashlM3' 25255 instructions. Operand 2 is always a scalar type. 25256 25257'vashlM3', 'vashrM3', 'vlshrM3', 'vrotlM3', 'vrotrM3' 25258 Vector shift and rotate instructions that take vectors as operand 2 25259 instead of a scalar type. 25260 25261'bswapM2' 25262 Reverse the order of bytes of operand 1 and store the result in 25263 operand 0. 25264 25265'negM2', 'ssnegM2', 'usnegM2' 25266 Negate operand 1 and store the result in operand 0. 25267 25268'negvM3' 25269 Like 'negM2' but takes a 'code_label' as operand 2 and emits code 25270 to jump to it if signed overflow occurs during the negation. 25271 25272'absM2' 25273 Store the absolute value of operand 1 into operand 0. 25274 25275'sqrtM2' 25276 Store the square root of operand 1 into operand 0. Both operands 25277 have mode M, which is a scalar or vector floating-point mode. 25278 25279 This pattern is not allowed to 'FAIL'. 25280 25281'rsqrtM2' 25282 Store the reciprocal of the square root of operand 1 into operand 25283 0. Both operands have mode M, which is a scalar or vector 25284 floating-point mode. 25285 25286 On most architectures this pattern is only approximate, so either 25287 its C condition or the 'TARGET_OPTAB_SUPPORTED_P' hook should check 25288 for the appropriate math flags. (Using the C condition is more 25289 direct, but using 'TARGET_OPTAB_SUPPORTED_P' can be useful if a 25290 target-specific built-in also uses the 'rsqrtM2' pattern.) 25291 25292 This pattern is not allowed to 'FAIL'. 25293 25294'fmodM3' 25295 Store the remainder of dividing operand 1 by operand 2 into operand 25296 0, rounded towards zero to an integer. All operands have mode M, 25297 which is a scalar or vector floating-point mode. 25298 25299 This pattern is not allowed to 'FAIL'. 25300 25301'remainderM3' 25302 Store the remainder of dividing operand 1 by operand 2 into operand 25303 0, rounded to the nearest integer. All operands have mode M, which 25304 is a scalar or vector floating-point mode. 25305 25306 This pattern is not allowed to 'FAIL'. 25307 25308'scalbM3' 25309 Raise 'FLT_RADIX' to the power of operand 2, multiply it by operand 25310 1, and store the result in operand 0. All operands have mode M, 25311 which is a scalar or vector floating-point mode. 25312 25313 This pattern is not allowed to 'FAIL'. 25314 25315'ldexpM3' 25316 Raise 2 to the power of operand 2, multiply it by operand 1, and 25317 store the result in operand 0. Operands 0 and 1 have mode M, which 25318 is a scalar or vector floating-point mode. Operand 2's mode has 25319 the same number of elements as M and each element is wide enough to 25320 store an 'int'. The integers are signed. 25321 25322 This pattern is not allowed to 'FAIL'. 25323 25324'cosM2' 25325 Store the cosine of operand 1 into operand 0. Both operands have 25326 mode M, which is a scalar or vector floating-point mode. 25327 25328 This pattern is not allowed to 'FAIL'. 25329 25330'sinM2' 25331 Store the sine of operand 1 into operand 0. Both operands have 25332 mode M, which is a scalar or vector floating-point mode. 25333 25334 This pattern is not allowed to 'FAIL'. 25335 25336'sincosM3' 25337 Store the cosine of operand 2 into operand 0 and the sine of 25338 operand 2 into operand 1. All operands have mode M, which is a 25339 scalar or vector floating-point mode. 25340 25341 Targets that can calculate the sine and cosine simultaneously can 25342 implement this pattern as opposed to implementing individual 25343 'sinM2' and 'cosM2' patterns. The 'sin' and 'cos' built-in 25344 functions will then be expanded to the 'sincosM3' pattern, with one 25345 of the output values left unused. 25346 25347'tanM2' 25348 Store the tangent of operand 1 into operand 0. Both operands have 25349 mode M, which is a scalar or vector floating-point mode. 25350 25351 This pattern is not allowed to 'FAIL'. 25352 25353'asinM2' 25354 Store the arc sine of operand 1 into operand 0. Both operands have 25355 mode M, which is a scalar or vector floating-point mode. 25356 25357 This pattern is not allowed to 'FAIL'. 25358 25359'acosM2' 25360 Store the arc cosine of operand 1 into operand 0. Both operands 25361 have mode M, which is a scalar or vector floating-point mode. 25362 25363 This pattern is not allowed to 'FAIL'. 25364 25365'atanM2' 25366 Store the arc tangent of operand 1 into operand 0. Both operands 25367 have mode M, which is a scalar or vector floating-point mode. 25368 25369 This pattern is not allowed to 'FAIL'. 25370 25371'expM2' 25372 Raise e (the base of natural logarithms) to the power of operand 1 25373 and store the result in operand 0. Both operands have mode M, 25374 which is a scalar or vector floating-point mode. 25375 25376 This pattern is not allowed to 'FAIL'. 25377 25378'expm1M2' 25379 Raise e (the base of natural logarithms) to the power of operand 1, 25380 subtract 1, and store the result in operand 0. Both operands have 25381 mode M, which is a scalar or vector floating-point mode. 25382 25383 For inputs close to zero, the pattern is expected to be more 25384 accurate than a separate 'expM2' and 'subM3' would be. 25385 25386 This pattern is not allowed to 'FAIL'. 25387 25388'exp10M2' 25389 Raise 10 to the power of operand 1 and store the result in operand 25390 0. Both operands have mode M, which is a scalar or vector 25391 floating-point mode. 25392 25393 This pattern is not allowed to 'FAIL'. 25394 25395'exp2M2' 25396 Raise 2 to the power of operand 1 and store the result in operand 25397 0. Both operands have mode M, which is a scalar or vector 25398 floating-point mode. 25399 25400 This pattern is not allowed to 'FAIL'. 25401 25402'logM2' 25403 Store the natural logarithm of operand 1 into operand 0. Both 25404 operands have mode M, which is a scalar or vector floating-point 25405 mode. 25406 25407 This pattern is not allowed to 'FAIL'. 25408 25409'log1pM2' 25410 Add 1 to operand 1, compute the natural logarithm, and store the 25411 result in operand 0. Both operands have mode M, which is a scalar 25412 or vector floating-point mode. 25413 25414 For inputs close to zero, the pattern is expected to be more 25415 accurate than a separate 'addM3' and 'logM2' would be. 25416 25417 This pattern is not allowed to 'FAIL'. 25418 25419'log10M2' 25420 Store the base-10 logarithm of operand 1 into operand 0. Both 25421 operands have mode M, which is a scalar or vector floating-point 25422 mode. 25423 25424 This pattern is not allowed to 'FAIL'. 25425 25426'log2M2' 25427 Store the base-2 logarithm of operand 1 into operand 0. Both 25428 operands have mode M, which is a scalar or vector floating-point 25429 mode. 25430 25431 This pattern is not allowed to 'FAIL'. 25432 25433'logbM2' 25434 Store the base-'FLT_RADIX' logarithm of operand 1 into operand 0. 25435 Both operands have mode M, which is a scalar or vector 25436 floating-point mode. 25437 25438 This pattern is not allowed to 'FAIL'. 25439 25440'significandM2' 25441 Store the significand of floating-point operand 1 in operand 0. 25442 Both operands have mode M, which is a scalar or vector 25443 floating-point mode. 25444 25445 This pattern is not allowed to 'FAIL'. 25446 25447'powM3' 25448 Store the value of operand 1 raised to the exponent operand 2 into 25449 operand 0. All operands have mode M, which is a scalar or vector 25450 floating-point mode. 25451 25452 This pattern is not allowed to 'FAIL'. 25453 25454'atan2M3' 25455 Store the arc tangent (inverse tangent) of operand 1 divided by 25456 operand 2 into operand 0, using the signs of both arguments to 25457 determine the quadrant of the result. All operands have mode M, 25458 which is a scalar or vector floating-point mode. 25459 25460 This pattern is not allowed to 'FAIL'. 25461 25462'floorM2' 25463 Store the largest integral value not greater than operand 1 in 25464 operand 0. Both operands have mode M, which is a scalar or vector 25465 floating-point mode. If '-ffp-int-builtin-inexact' is in effect, 25466 the "inexact" exception may be raised for noninteger operands; 25467 otherwise, it may not. 25468 25469 This pattern is not allowed to 'FAIL'. 25470 25471'btruncM2' 25472 Round operand 1 to an integer, towards zero, and store the result 25473 in operand 0. Both operands have mode M, which is a scalar or 25474 vector floating-point mode. If '-ffp-int-builtin-inexact' is in 25475 effect, the "inexact" exception may be raised for noninteger 25476 operands; otherwise, it may not. 25477 25478 This pattern is not allowed to 'FAIL'. 25479 25480'roundM2' 25481 Round operand 1 to the nearest integer, rounding away from zero in 25482 the event of a tie, and store the result in operand 0. Both 25483 operands have mode M, which is a scalar or vector floating-point 25484 mode. If '-ffp-int-builtin-inexact' is in effect, the "inexact" 25485 exception may be raised for noninteger operands; otherwise, it may 25486 not. 25487 25488 This pattern is not allowed to 'FAIL'. 25489 25490'ceilM2' 25491 Store the smallest integral value not less than operand 1 in 25492 operand 0. Both operands have mode M, which is a scalar or vector 25493 floating-point mode. If '-ffp-int-builtin-inexact' is in effect, 25494 the "inexact" exception may be raised for noninteger operands; 25495 otherwise, it may not. 25496 25497 This pattern is not allowed to 'FAIL'. 25498 25499'nearbyintM2' 25500 Round operand 1 to an integer, using the current rounding mode, and 25501 store the result in operand 0. Do not raise an inexact condition 25502 when the result is different from the argument. Both operands have 25503 mode M, which is a scalar or vector floating-point mode. 25504 25505 This pattern is not allowed to 'FAIL'. 25506 25507'rintM2' 25508 Round operand 1 to an integer, using the current rounding mode, and 25509 store the result in operand 0. Raise an inexact condition when the 25510 result is different from the argument. Both operands have mode M, 25511 which is a scalar or vector floating-point mode. 25512 25513 This pattern is not allowed to 'FAIL'. 25514 25515'lrintMN2' 25516 Convert operand 1 (valid for floating point mode M) to fixed point 25517 mode N as a signed number according to the current rounding mode 25518 and store in operand 0 (which has mode N). 25519 25520'lroundMN2' 25521 Convert operand 1 (valid for floating point mode M) to fixed point 25522 mode N as a signed number rounding to nearest and away from zero 25523 and store in operand 0 (which has mode N). 25524 25525'lfloorMN2' 25526 Convert operand 1 (valid for floating point mode M) to fixed point 25527 mode N as a signed number rounding down and store in operand 0 25528 (which has mode N). 25529 25530'lceilMN2' 25531 Convert operand 1 (valid for floating point mode M) to fixed point 25532 mode N as a signed number rounding up and store in operand 0 (which 25533 has mode N). 25534 25535'copysignM3' 25536 Store a value with the magnitude of operand 1 and the sign of 25537 operand 2 into operand 0. All operands have mode M, which is a 25538 scalar or vector floating-point mode. 25539 25540 This pattern is not allowed to 'FAIL'. 25541 25542'ffsM2' 25543 Store into operand 0 one plus the index of the least significant 25544 1-bit of operand 1. If operand 1 is zero, store zero. 25545 25546 M is either a scalar or vector integer mode. When it is a scalar, 25547 operand 1 has mode M but operand 0 can have whatever scalar integer 25548 mode is suitable for the target. The compiler will insert 25549 conversion instructions as necessary (typically to convert the 25550 result to the same width as 'int'). When M is a vector, both 25551 operands must have mode M. 25552 25553 This pattern is not allowed to 'FAIL'. 25554 25555'clrsbM2' 25556 Count leading redundant sign bits. Store into operand 0 the number 25557 of redundant sign bits in operand 1, starting at the most 25558 significant bit position. A redundant sign bit is defined as any 25559 sign bit after the first. As such, this count will be one less 25560 than the count of leading sign bits. 25561 25562 M is either a scalar or vector integer mode. When it is a scalar, 25563 operand 1 has mode M but operand 0 can have whatever scalar integer 25564 mode is suitable for the target. The compiler will insert 25565 conversion instructions as necessary (typically to convert the 25566 result to the same width as 'int'). When M is a vector, both 25567 operands must have mode M. 25568 25569 This pattern is not allowed to 'FAIL'. 25570 25571'clzM2' 25572 Store into operand 0 the number of leading 0-bits in operand 1, 25573 starting at the most significant bit position. If operand 1 is 0, 25574 the 'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 25575 result is undefined or has a useful value. 25576 25577 M is either a scalar or vector integer mode. When it is a scalar, 25578 operand 1 has mode M but operand 0 can have whatever scalar integer 25579 mode is suitable for the target. The compiler will insert 25580 conversion instructions as necessary (typically to convert the 25581 result to the same width as 'int'). When M is a vector, both 25582 operands must have mode M. 25583 25584 This pattern is not allowed to 'FAIL'. 25585 25586'ctzM2' 25587 Store into operand 0 the number of trailing 0-bits in operand 1, 25588 starting at the least significant bit position. If operand 1 is 0, 25589 the 'CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 25590 result is undefined or has a useful value. 25591 25592 M is either a scalar or vector integer mode. When it is a scalar, 25593 operand 1 has mode M but operand 0 can have whatever scalar integer 25594 mode is suitable for the target. The compiler will insert 25595 conversion instructions as necessary (typically to convert the 25596 result to the same width as 'int'). When M is a vector, both 25597 operands must have mode M. 25598 25599 This pattern is not allowed to 'FAIL'. 25600 25601'popcountM2' 25602 Store into operand 0 the number of 1-bits in operand 1. 25603 25604 M is either a scalar or vector integer mode. When it is a scalar, 25605 operand 1 has mode M but operand 0 can have whatever scalar integer 25606 mode is suitable for the target. The compiler will insert 25607 conversion instructions as necessary (typically to convert the 25608 result to the same width as 'int'). When M is a vector, both 25609 operands must have mode M. 25610 25611 This pattern is not allowed to 'FAIL'. 25612 25613'parityM2' 25614 Store into operand 0 the parity of operand 1, i.e. the number of 25615 1-bits in operand 1 modulo 2. 25616 25617 M is either a scalar or vector integer mode. When it is a scalar, 25618 operand 1 has mode M but operand 0 can have whatever scalar integer 25619 mode is suitable for the target. The compiler will insert 25620 conversion instructions as necessary (typically to convert the 25621 result to the same width as 'int'). When M is a vector, both 25622 operands must have mode M. 25623 25624 This pattern is not allowed to 'FAIL'. 25625 25626'one_cmplM2' 25627 Store the bitwise-complement of operand 1 into operand 0. 25628 25629'movmemM' 25630 Block move instruction. The destination and source blocks of 25631 memory are the first two operands, and both are 'mem:BLK's with an 25632 address in mode 'Pmode'. 25633 25634 The number of bytes to move is the third operand, in mode M. 25635 Usually, you specify 'Pmode' for M. However, if you can generate 25636 better code knowing the range of valid lengths is smaller than 25637 those representable in a full Pmode pointer, you should provide a 25638 pattern with a mode corresponding to the range of values you can 25639 handle efficiently (e.g., 'QImode' for values in the range 0-127; 25640 note we avoid numbers that appear negative) and also a pattern with 25641 'Pmode'. 25642 25643 The fourth operand is the known shared alignment of the source and 25644 destination, in the form of a 'const_int' rtx. Thus, if the 25645 compiler knows that both source and destination are word-aligned, 25646 it may provide the value 4 for this operand. 25647 25648 Optional operands 5 and 6 specify expected alignment and size of 25649 block respectively. The expected alignment differs from alignment 25650 in operand 4 in a way that the blocks are not required to be 25651 aligned according to it in all cases. This expected alignment is 25652 also in bytes, just like operand 4. Expected size, when unknown, 25653 is set to '(const_int -1)'. 25654 25655 Descriptions of multiple 'movmemM' patterns can only be beneficial 25656 if the patterns for smaller modes have fewer restrictions on their 25657 first, second and fourth operands. Note that the mode M in 25658 'movmemM' does not impose any restriction on the mode of 25659 individually moved data units in the block. 25660 25661 These patterns need not give special consideration to the 25662 possibility that the source and destination strings might overlap. 25663 25664'movstr' 25665 String copy instruction, with 'stpcpy' semantics. Operand 0 is an 25666 output operand in mode 'Pmode'. The addresses of the destination 25667 and source strings are operands 1 and 2, and both are 'mem:BLK's 25668 with addresses in mode 'Pmode'. The execution of the expansion of 25669 this pattern should store in operand 0 the address in which the 25670 'NUL' terminator was stored in the destination string. 25671 25672 This patern has also several optional operands that are same as in 25673 'setmem'. 25674 25675'setmemM' 25676 Block set instruction. The destination string is the first 25677 operand, given as a 'mem:BLK' whose address is in mode 'Pmode'. 25678 The number of bytes to set is the second operand, in mode M. The 25679 value to initialize the memory with is the third operand. Targets 25680 that only support the clearing of memory should reject any value 25681 that is not the constant 0. See 'movmemM' for a discussion of the 25682 choice of mode. 25683 25684 The fourth operand is the known alignment of the destination, in 25685 the form of a 'const_int' rtx. Thus, if the compiler knows that 25686 the destination is word-aligned, it may provide the value 4 for 25687 this operand. 25688 25689 Optional operands 5 and 6 specify expected alignment and size of 25690 block respectively. The expected alignment differs from alignment 25691 in operand 4 in a way that the blocks are not required to be 25692 aligned according to it in all cases. This expected alignment is 25693 also in bytes, just like operand 4. Expected size, when unknown, 25694 is set to '(const_int -1)'. Operand 7 is the minimal size of the 25695 block and operand 8 is the maximal size of the block (NULL if it 25696 can not be represented as CONST_INT). Operand 9 is the probable 25697 maximal size (i.e. we can not rely on it for correctness, but it 25698 can be used for choosing proper code sequence for a given size). 25699 25700 The use for multiple 'setmemM' is as for 'movmemM'. 25701 25702'cmpstrnM' 25703 String compare instruction, with five operands. Operand 0 is the 25704 output; it has mode M. The remaining four operands are like the 25705 operands of 'movmemM'. The two memory blocks specified are 25706 compared byte by byte in lexicographic order starting at the 25707 beginning of each string. The instruction is not allowed to 25708 prefetch more than one byte at a time since either string may end 25709 in the first byte and reading past that may access an invalid page 25710 or segment and cause a fault. The comparison terminates early if 25711 the fetched bytes are different or if they are equal to zero. The 25712 effect of the instruction is to store a value in operand 0 whose 25713 sign indicates the result of the comparison. 25714 25715'cmpstrM' 25716 String compare instruction, without known maximum length. Operand 25717 0 is the output; it has mode M. The second and third operand are 25718 the blocks of memory to be compared; both are 'mem:BLK' with an 25719 address in mode 'Pmode'. 25720 25721 The fourth operand is the known shared alignment of the source and 25722 destination, in the form of a 'const_int' rtx. Thus, if the 25723 compiler knows that both source and destination are word-aligned, 25724 it may provide the value 4 for this operand. 25725 25726 The two memory blocks specified are compared byte by byte in 25727 lexicographic order starting at the beginning of each string. The 25728 instruction is not allowed to prefetch more than one byte at a time 25729 since either string may end in the first byte and reading past that 25730 may access an invalid page or segment and cause a fault. The 25731 comparison will terminate when the fetched bytes are different or 25732 if they are equal to zero. The effect of the instruction is to 25733 store a value in operand 0 whose sign indicates the result of the 25734 comparison. 25735 25736'cmpmemM' 25737 Block compare instruction, with five operands like the operands of 25738 'cmpstrM'. The two memory blocks specified are compared byte by 25739 byte in lexicographic order starting at the beginning of each 25740 block. Unlike 'cmpstrM' the instruction can prefetch any bytes in 25741 the two memory blocks. Also unlike 'cmpstrM' the comparison will 25742 not stop if both bytes are zero. The effect of the instruction is 25743 to store a value in operand 0 whose sign indicates the result of 25744 the comparison. 25745 25746'strlenM' 25747 Compute the length of a string, with three operands. Operand 0 is 25748 the result (of mode M), operand 1 is a 'mem' referring to the first 25749 character of the string, operand 2 is the character to search for 25750 (normally zero), and operand 3 is a constant describing the known 25751 alignment of the beginning of the string. 25752 25753'floatMN2' 25754 Convert signed integer operand 1 (valid for fixed point mode M) to 25755 floating point mode N and store in operand 0 (which has mode N). 25756 25757'floatunsMN2' 25758 Convert unsigned integer operand 1 (valid for fixed point mode M) 25759 to floating point mode N and store in operand 0 (which has mode N). 25760 25761'fixMN2' 25762 Convert operand 1 (valid for floating point mode M) to fixed point 25763 mode N as a signed number and store in operand 0 (which has mode 25764 N). This instruction's result is defined only when the value of 25765 operand 1 is an integer. 25766 25767 If the machine description defines this pattern, it also needs to 25768 define the 'ftrunc' pattern. 25769 25770'fixunsMN2' 25771 Convert operand 1 (valid for floating point mode M) to fixed point 25772 mode N as an unsigned number and store in operand 0 (which has mode 25773 N). This instruction's result is defined only when the value of 25774 operand 1 is an integer. 25775 25776'ftruncM2' 25777 Convert operand 1 (valid for floating point mode M) to an integer 25778 value, still represented in floating point mode M, and store it in 25779 operand 0 (valid for floating point mode M). 25780 25781'fix_truncMN2' 25782 Like 'fixMN2' but works for any floating point value of mode M by 25783 converting the value to an integer. 25784 25785'fixuns_truncMN2' 25786 Like 'fixunsMN2' but works for any floating point value of mode M 25787 by converting the value to an integer. 25788 25789'truncMN2' 25790 Truncate operand 1 (valid for mode M) to mode N and store in 25791 operand 0 (which has mode N). Both modes must be fixed point or 25792 both floating point. 25793 25794'extendMN2' 25795 Sign-extend operand 1 (valid for mode M) to mode N and store in 25796 operand 0 (which has mode N). Both modes must be fixed point or 25797 both floating point. 25798 25799'zero_extendMN2' 25800 Zero-extend operand 1 (valid for mode M) to mode N and store in 25801 operand 0 (which has mode N). Both modes must be fixed point. 25802 25803'fractMN2' 25804 Convert operand 1 of mode M to mode N and store in operand 0 (which 25805 has mode N). Mode M and mode N could be fixed-point to 25806 fixed-point, signed integer to fixed-point, fixed-point to signed 25807 integer, floating-point to fixed-point, or fixed-point to 25808 floating-point. When overflows or underflows happen, the results 25809 are undefined. 25810 25811'satfractMN2' 25812 Convert operand 1 of mode M to mode N and store in operand 0 (which 25813 has mode N). Mode M and mode N could be fixed-point to 25814 fixed-point, signed integer to fixed-point, or floating-point to 25815 fixed-point. When overflows or underflows happen, the instruction 25816 saturates the results to the maximum or the minimum. 25817 25818'fractunsMN2' 25819 Convert operand 1 of mode M to mode N and store in operand 0 (which 25820 has mode N). Mode M and mode N could be unsigned integer to 25821 fixed-point, or fixed-point to unsigned integer. When overflows or 25822 underflows happen, the results are undefined. 25823 25824'satfractunsMN2' 25825 Convert unsigned integer operand 1 of mode M to fixed-point mode N 25826 and store in operand 0 (which has mode N). When overflows or 25827 underflows happen, the instruction saturates the results to the 25828 maximum or the minimum. 25829 25830'extvM' 25831 Extract a bit-field from register operand 1, sign-extend it, and 25832 store it in operand 0. Operand 2 specifies the width of the field 25833 in bits and operand 3 the starting bit, which counts from the most 25834 significant bit if 'BITS_BIG_ENDIAN' is true and from the least 25835 significant bit otherwise. 25836 25837 Operands 0 and 1 both have mode M. Operands 2 and 3 have a 25838 target-specific mode. 25839 25840'extvmisalignM' 25841 Extract a bit-field from memory operand 1, sign extend it, and 25842 store it in operand 0. Operand 2 specifies the width in bits and 25843 operand 3 the starting bit. The starting bit is always somewhere 25844 in the first byte of operand 1; it counts from the most significant 25845 bit if 'BITS_BIG_ENDIAN' is true and from the least significant bit 25846 otherwise. 25847 25848 Operand 0 has mode M while operand 1 has 'BLK' mode. Operands 2 25849 and 3 have a target-specific mode. 25850 25851 The instruction must not read beyond the last byte of the 25852 bit-field. 25853 25854'extzvM' 25855 Like 'extvM' except that the bit-field value is zero-extended. 25856 25857'extzvmisalignM' 25858 Like 'extvmisalignM' except that the bit-field value is 25859 zero-extended. 25860 25861'insvM' 25862 Insert operand 3 into a bit-field of register operand 0. Operand 1 25863 specifies the width of the field in bits and operand 2 the starting 25864 bit, which counts from the most significant bit if 25865 'BITS_BIG_ENDIAN' is true and from the least significant bit 25866 otherwise. 25867 25868 Operands 0 and 3 both have mode M. Operands 1 and 2 have a 25869 target-specific mode. 25870 25871'insvmisalignM' 25872 Insert operand 3 into a bit-field of memory operand 0. Operand 1 25873 specifies the width of the field in bits and operand 2 the starting 25874 bit. The starting bit is always somewhere in the first byte of 25875 operand 0; it counts from the most significant bit if 25876 'BITS_BIG_ENDIAN' is true and from the least significant bit 25877 otherwise. 25878 25879 Operand 3 has mode M while operand 0 has 'BLK' mode. Operands 1 25880 and 2 have a target-specific mode. 25881 25882 The instruction must not read or write beyond the last byte of the 25883 bit-field. 25884 25885'extv' 25886 Extract a bit-field from operand 1 (a register or memory operand), 25887 where operand 2 specifies the width in bits and operand 3 the 25888 starting bit, and store it in operand 0. Operand 0 must have mode 25889 'word_mode'. Operand 1 may have mode 'byte_mode' or 'word_mode'; 25890 often 'word_mode' is allowed only for registers. Operands 2 and 3 25891 must be valid for 'word_mode'. 25892 25893 The RTL generation pass generates this instruction only with 25894 constants for operands 2 and 3 and the constant is never zero for 25895 operand 2. 25896 25897 The bit-field value is sign-extended to a full word integer before 25898 it is stored in operand 0. 25899 25900 This pattern is deprecated; please use 'extvM' and 'extvmisalignM' 25901 instead. 25902 25903'extzv' 25904 Like 'extv' except that the bit-field value is zero-extended. 25905 25906 This pattern is deprecated; please use 'extzvM' and 25907 'extzvmisalignM' instead. 25908 25909'insv' 25910 Store operand 3 (which must be valid for 'word_mode') into a 25911 bit-field in operand 0, where operand 1 specifies the width in bits 25912 and operand 2 the starting bit. Operand 0 may have mode 25913 'byte_mode' or 'word_mode'; often 'word_mode' is allowed only for 25914 registers. Operands 1 and 2 must be valid for 'word_mode'. 25915 25916 The RTL generation pass generates this instruction only with 25917 constants for operands 1 and 2 and the constant is never zero for 25918 operand 1. 25919 25920 This pattern is deprecated; please use 'insvM' and 'insvmisalignM' 25921 instead. 25922 25923'movMODEcc' 25924 Conditionally move operand 2 or operand 3 into operand 0 according 25925 to the comparison in operand 1. If the comparison is true, operand 25926 2 is moved into operand 0, otherwise operand 3 is moved. 25927 25928 The mode of the operands being compared need not be the same as the 25929 operands being moved. Some machines, sparc64 for example, have 25930 instructions that conditionally move an integer value based on the 25931 floating point condition codes and vice versa. 25932 25933 If the machine does not have conditional move instructions, do not 25934 define these patterns. 25935 25936'addMODEcc' 25937 Similar to 'movMODEcc' but for conditional addition. Conditionally 25938 move operand 2 or (operands 2 + operand 3) into operand 0 according 25939 to the comparison in operand 1. If the comparison is false, 25940 operand 2 is moved into operand 0, otherwise (operand 2 + operand 25941 3) is moved. 25942 25943'cond_addMODE' 25944'cond_subMODE' 25945'cond_andMODE' 25946'cond_iorMODE' 25947'cond_xorMODE' 25948'cond_sminMODE' 25949'cond_smaxMODE' 25950'cond_uminMODE' 25951'cond_umaxMODE' 25952 Perform an elementwise operation on vector operands 2 and 3, under 25953 the control of the vector mask in operand 1, and store the result 25954 in operand 0. This is equivalent to: 25955 25956 for (i = 0; i < GET_MODE_NUNITS (N); i++) 25957 op0[i] = op1[i] ? op2[i] OP op3[i] : op2[i]; 25958 25959 where, for example, OP is '+' for 'cond_addMODE'. 25960 25961 When defined for floating-point modes, the contents of 'op3[i]' are 25962 not interpreted if OP1[I] is false, just like they would not be in 25963 a normal C '?:' condition. 25964 25965 Operands 0, 2 and 3 all have mode M, while operand 1 has the mode 25966 returned by 'TARGET_VECTORIZE_GET_MASK_MODE'. 25967 25968'negMODEcc' 25969 Similar to 'movMODEcc' but for conditional negation. Conditionally 25970 move the negation of operand 2 or the unchanged operand 3 into 25971 operand 0 according to the comparison in operand 1. If the 25972 comparison is true, the negation of operand 2 is moved into operand 25973 0, otherwise operand 3 is moved. 25974 25975'notMODEcc' 25976 Similar to 'negMODEcc' but for conditional complement. 25977 Conditionally move the bitwise complement of operand 2 or the 25978 unchanged operand 3 into operand 0 according to the comparison in 25979 operand 1. If the comparison is true, the complement of operand 2 25980 is moved into operand 0, otherwise operand 3 is moved. 25981 25982'cstoreMODE4' 25983 Store zero or nonzero in operand 0 according to whether a 25984 comparison is true. Operand 1 is a comparison operator. Operand 2 25985 and operand 3 are the first and second operand of the comparison, 25986 respectively. You specify the mode that operand 0 must have when 25987 you write the 'match_operand' expression. The compiler 25988 automatically sees which mode you have used and supplies an operand 25989 of that mode. 25990 25991 The value stored for a true condition must have 1 as its low bit, 25992 or else must be negative. Otherwise the instruction is not 25993 suitable and you should omit it from the machine description. You 25994 describe to the compiler exactly which value is stored by defining 25995 the macro 'STORE_FLAG_VALUE' (*note Misc::). If a description 25996 cannot be found that can be used for all the possible comparison 25997 operators, you should pick one and use a 'define_expand' to map all 25998 results onto the one you chose. 25999 26000 These operations may 'FAIL', but should do so only in relatively 26001 uncommon cases; if they would 'FAIL' for common cases involving 26002 integer comparisons, it is best to restrict the predicates to not 26003 allow these operands. Likewise if a given comparison operator will 26004 always fail, independent of the operands (for floating-point modes, 26005 the 'ordered_comparison_operator' predicate is often useful in this 26006 case). 26007 26008 If this pattern is omitted, the compiler will generate a 26009 conditional branch--for example, it may copy a constant one to the 26010 target and branching around an assignment of zero to the target--or 26011 a libcall. If the predicate for operand 1 only rejects some 26012 operators, it will also try reordering the operands and/or 26013 inverting the result value (e.g. by an exclusive OR). These 26014 possibilities could be cheaper or equivalent to the instructions 26015 used for the 'cstoreMODE4' pattern followed by those required to 26016 convert a positive result from 'STORE_FLAG_VALUE' to 1; in this 26017 case, you can and should make operand 1's predicate reject some 26018 operators in the 'cstoreMODE4' pattern, or remove the pattern 26019 altogether from the machine description. 26020 26021'cbranchMODE4' 26022 Conditional branch instruction combined with a compare instruction. 26023 Operand 0 is a comparison operator. Operand 1 and operand 2 are 26024 the first and second operands of the comparison, respectively. 26025 Operand 3 is the 'code_label' to jump to. 26026 26027'jump' 26028 A jump inside a function; an unconditional branch. Operand 0 is 26029 the 'code_label' to jump to. This pattern name is mandatory on all 26030 machines. 26031 26032'call' 26033 Subroutine call instruction returning no value. Operand 0 is the 26034 function to call; operand 1 is the number of bytes of arguments 26035 pushed as a 'const_int'; operand 2 is the number of registers used 26036 as operands. 26037 26038 On most machines, operand 2 is not actually stored into the RTL 26039 pattern. It is supplied for the sake of some RISC machines which 26040 need to put this information into the assembler code; they can put 26041 it in the RTL instead of operand 1. 26042 26043 Operand 0 should be a 'mem' RTX whose address is the address of the 26044 function. Note, however, that this address can be a 'symbol_ref' 26045 expression even if it would not be a legitimate memory address on 26046 the target machine. If it is also not a valid argument for a call 26047 instruction, the pattern for this operation should be a 26048 'define_expand' (*note Expander Definitions::) that places the 26049 address into a register and uses that register in the call 26050 instruction. 26051 26052'call_value' 26053 Subroutine call instruction returning a value. Operand 0 is the 26054 hard register in which the value is returned. There are three more 26055 operands, the same as the three operands of the 'call' instruction 26056 (but with numbers increased by one). 26057 26058 Subroutines that return 'BLKmode' objects use the 'call' insn. 26059 26060'call_pop', 'call_value_pop' 26061 Similar to 'call' and 'call_value', except used if defined and if 26062 'RETURN_POPS_ARGS' is nonzero. They should emit a 'parallel' that 26063 contains both the function call and a 'set' to indicate the 26064 adjustment made to the frame pointer. 26065 26066 For machines where 'RETURN_POPS_ARGS' can be nonzero, the use of 26067 these patterns increases the number of functions for which the 26068 frame pointer can be eliminated, if desired. 26069 26070'untyped_call' 26071 Subroutine call instruction returning a value of any type. Operand 26072 0 is the function to call; operand 1 is a memory location where the 26073 result of calling the function is to be stored; operand 2 is a 26074 'parallel' expression where each element is a 'set' expression that 26075 indicates the saving of a function return value into the result 26076 block. 26077 26078 This instruction pattern should be defined to support 26079 '__builtin_apply' on machines where special instructions are needed 26080 to call a subroutine with arbitrary arguments or to save the value 26081 returned. This instruction pattern is required on machines that 26082 have multiple registers that can hold a return value (i.e. 26083 'FUNCTION_VALUE_REGNO_P' is true for more than one register). 26084 26085'return' 26086 Subroutine return instruction. This instruction pattern name 26087 should be defined only if a single instruction can do all the work 26088 of returning from a function. 26089 26090 Like the 'movM' patterns, this pattern is also used after the RTL 26091 generation phase. In this case it is to support machines where 26092 multiple instructions are usually needed to return from a function, 26093 but some class of functions only requires one instruction to 26094 implement a return. Normally, the applicable functions are those 26095 which do not need to save any registers or allocate stack space. 26096 26097 It is valid for this pattern to expand to an instruction using 26098 'simple_return' if no epilogue is required. 26099 26100'simple_return' 26101 Subroutine return instruction. This instruction pattern name 26102 should be defined only if a single instruction can do all the work 26103 of returning from a function on a path where no epilogue is 26104 required. This pattern is very similar to the 'return' instruction 26105 pattern, but it is emitted only by the shrink-wrapping optimization 26106 on paths where the function prologue has not been executed, and a 26107 function return should occur without any of the effects of the 26108 epilogue. Additional uses may be introduced on paths where both 26109 the prologue and the epilogue have executed. 26110 26111 For such machines, the condition specified in this pattern should 26112 only be true when 'reload_completed' is nonzero and the function's 26113 epilogue would only be a single instruction. For machines with 26114 register windows, the routine 'leaf_function_p' may be used to 26115 determine if a register window push is required. 26116 26117 Machines that have conditional return instructions should define 26118 patterns such as 26119 26120 (define_insn "" 26121 [(set (pc) 26122 (if_then_else (match_operator 26123 0 "comparison_operator" 26124 [(cc0) (const_int 0)]) 26125 (return) 26126 (pc)))] 26127 "CONDITION" 26128 "...") 26129 26130 where CONDITION would normally be the same condition specified on 26131 the named 'return' pattern. 26132 26133'untyped_return' 26134 Untyped subroutine return instruction. This instruction pattern 26135 should be defined to support '__builtin_return' on machines where 26136 special instructions are needed to return a value of any type. 26137 26138 Operand 0 is a memory location where the result of calling a 26139 function with '__builtin_apply' is stored; operand 1 is a 26140 'parallel' expression where each element is a 'set' expression that 26141 indicates the restoring of a function return value from the result 26142 block. 26143 26144'nop' 26145 No-op instruction. This instruction pattern name should always be 26146 defined to output a no-op in assembler code. '(const_int 0)' will 26147 do as an RTL pattern. 26148 26149'indirect_jump' 26150 An instruction to jump to an address which is operand zero. This 26151 pattern name is mandatory on all machines. 26152 26153'casesi' 26154 Instruction to jump through a dispatch table, including bounds 26155 checking. This instruction takes five operands: 26156 26157 1. The index to dispatch on, which has mode 'SImode'. 26158 26159 2. The lower bound for indices in the table, an integer constant. 26160 26161 3. The total range of indices in the table--the largest index 26162 minus the smallest one (both inclusive). 26163 26164 4. A label that precedes the table itself. 26165 26166 5. A label to jump to if the index has a value outside the 26167 bounds. 26168 26169 The table is an 'addr_vec' or 'addr_diff_vec' inside of a 26170 'jump_table_data'. The number of elements in the table is one plus 26171 the difference between the upper bound and the lower bound. 26172 26173'tablejump' 26174 Instruction to jump to a variable address. This is a low-level 26175 capability which can be used to implement a dispatch table when 26176 there is no 'casesi' pattern. 26177 26178 This pattern requires two operands: the address or offset, and a 26179 label which should immediately precede the jump table. If the 26180 macro 'CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then 26181 the first operand is an offset which counts from the address of the 26182 table; otherwise, it is an absolute address to jump to. In either 26183 case, the first operand has mode 'Pmode'. 26184 26185 The 'tablejump' insn is always the last insn before the jump table 26186 it uses. Its assembler code normally has no need to use the second 26187 operand, but you should incorporate it in the RTL pattern so that 26188 the jump optimizer will not delete the table as unreachable code. 26189 26190'decrement_and_branch_until_zero' 26191 Conditional branch instruction that decrements a register and jumps 26192 if the register is nonzero. Operand 0 is the register to decrement 26193 and test; operand 1 is the label to jump to if the register is 26194 nonzero. *Note Looping Patterns::. 26195 26196 This optional instruction pattern is only used by the combiner, 26197 typically for loops reversed by the loop optimizer when strength 26198 reduction is enabled. 26199 26200'doloop_end' 26201 Conditional branch instruction that decrements a register and jumps 26202 if the register is nonzero. Operand 0 is the register to decrement 26203 and test; operand 1 is the label to jump to if the register is 26204 nonzero. *Note Looping Patterns::. 26205 26206 This optional instruction pattern should be defined for machines 26207 with low-overhead looping instructions as the loop optimizer will 26208 try to modify suitable loops to utilize it. The target hook 26209 'TARGET_CAN_USE_DOLOOP_P' controls the conditions under which 26210 low-overhead loops can be used. 26211 26212'doloop_begin' 26213 Companion instruction to 'doloop_end' required for machines that 26214 need to perform some initialization, such as loading a special 26215 counter register. Operand 1 is the associated 'doloop_end' pattern 26216 and operand 0 is the register that it decrements. 26217 26218 If initialization insns do not always need to be emitted, use a 26219 'define_expand' (*note Expander Definitions::) and make it fail. 26220 26221'canonicalize_funcptr_for_compare' 26222 Canonicalize the function pointer in operand 1 and store the result 26223 into operand 0. 26224 26225 Operand 0 is always a 'reg' and has mode 'Pmode'; operand 1 may be 26226 a 'reg', 'mem', 'symbol_ref', 'const_int', etc and also has mode 26227 'Pmode'. 26228 26229 Canonicalization of a function pointer usually involves computing 26230 the address of the function which would be called if the function 26231 pointer were used in an indirect call. 26232 26233 Only define this pattern if function pointers on the target machine 26234 can have different values but still call the same function when 26235 used in an indirect call. 26236 26237'save_stack_block' 26238'save_stack_function' 26239'save_stack_nonlocal' 26240'restore_stack_block' 26241'restore_stack_function' 26242'restore_stack_nonlocal' 26243 Most machines save and restore the stack pointer by copying it to 26244 or from an object of mode 'Pmode'. Do not define these patterns on 26245 such machines. 26246 26247 Some machines require special handling for stack pointer saves and 26248 restores. On those machines, define the patterns corresponding to 26249 the non-standard cases by using a 'define_expand' (*note Expander 26250 Definitions::) that produces the required insns. The three types 26251 of saves and restores are: 26252 26253 1. 'save_stack_block' saves the stack pointer at the start of a 26254 block that allocates a variable-sized object, and 26255 'restore_stack_block' restores the stack pointer when the 26256 block is exited. 26257 26258 2. 'save_stack_function' and 'restore_stack_function' do a 26259 similar job for the outermost block of a function and are used 26260 when the function allocates variable-sized objects or calls 26261 'alloca'. Only the epilogue uses the restored stack pointer, 26262 allowing a simpler save or restore sequence on some machines. 26263 26264 3. 'save_stack_nonlocal' is used in functions that contain labels 26265 branched to by nested functions. It saves the stack pointer 26266 in such a way that the inner function can use 26267 'restore_stack_nonlocal' to restore the stack pointer. The 26268 compiler generates code to restore the frame and argument 26269 pointer registers, but some machines require saving and 26270 restoring additional data such as register window information 26271 or stack backchains. Place insns in these patterns to save 26272 and restore any such required data. 26273 26274 When saving the stack pointer, operand 0 is the save area and 26275 operand 1 is the stack pointer. The mode used to allocate the save 26276 area defaults to 'Pmode' but you can override that choice by 26277 defining the 'STACK_SAVEAREA_MODE' macro (*note Storage Layout::). 26278 You must specify an integral mode, or 'VOIDmode' if no save area is 26279 needed for a particular type of save (either because no save is 26280 needed or because a machine-specific save area can be used). 26281 Operand 0 is the stack pointer and operand 1 is the save area for 26282 restore operations. If 'save_stack_block' is defined, operand 0 26283 must not be 'VOIDmode' since these saves can be arbitrarily nested. 26284 26285 A save area is a 'mem' that is at a constant offset from 26286 'virtual_stack_vars_rtx' when the stack pointer is saved for use by 26287 nonlocal gotos and a 'reg' in the other two cases. 26288 26289'allocate_stack' 26290 Subtract (or add if 'STACK_GROWS_DOWNWARD' is undefined) operand 1 26291 from the stack pointer to create space for dynamically allocated 26292 data. 26293 26294 Store the resultant pointer to this space into operand 0. If you 26295 are allocating space from the main stack, do this by emitting a 26296 move insn to copy 'virtual_stack_dynamic_rtx' to operand 0. If you 26297 are allocating the space elsewhere, generate code to copy the 26298 location of the space to operand 0. In the latter case, you must 26299 ensure this space gets freed when the corresponding space on the 26300 main stack is free. 26301 26302 Do not define this pattern if all that must be done is the 26303 subtraction. Some machines require other operations such as stack 26304 probes or maintaining the back chain. Define this pattern to emit 26305 those operations in addition to updating the stack pointer. 26306 26307'check_stack' 26308 If stack checking (*note Stack Checking::) cannot be done on your 26309 system by probing the stack, define this pattern to perform the 26310 needed check and signal an error if the stack has overflowed. The 26311 single operand is the address in the stack farthest from the 26312 current stack pointer that you need to validate. Normally, on 26313 platforms where this pattern is needed, you would obtain the stack 26314 limit from a global or thread-specific variable or register. 26315 26316'probe_stack_address' 26317 If stack checking (*note Stack Checking::) can be done on your 26318 system by probing the stack but without the need to actually access 26319 it, define this pattern and signal an error if the stack has 26320 overflowed. The single operand is the memory address in the stack 26321 that needs to be probed. 26322 26323'probe_stack' 26324 If stack checking (*note Stack Checking::) can be done on your 26325 system by probing the stack but doing it with a "store zero" 26326 instruction is not valid or optimal, define this pattern to do the 26327 probing differently and signal an error if the stack has 26328 overflowed. The single operand is the memory reference in the 26329 stack that needs to be probed. 26330 26331'nonlocal_goto' 26332 Emit code to generate a non-local goto, e.g., a jump from one 26333 function to a label in an outer function. This pattern has four 26334 arguments, each representing a value to be used in the jump. The 26335 first argument is to be loaded into the frame pointer, the second 26336 is the address to branch to (code to dispatch to the actual label), 26337 the third is the address of a location where the stack is saved, 26338 and the last is the address of the label, to be placed in the 26339 location for the incoming static chain. 26340 26341 On most machines you need not define this pattern, since GCC will 26342 already generate the correct code, which is to load the frame 26343 pointer and static chain, restore the stack (using the 26344 'restore_stack_nonlocal' pattern, if defined), and jump indirectly 26345 to the dispatcher. You need only define this pattern if this code 26346 will not work on your machine. 26347 26348'nonlocal_goto_receiver' 26349 This pattern, if defined, contains code needed at the target of a 26350 nonlocal goto after the code already generated by GCC. You will 26351 not normally need to define this pattern. A typical reason why you 26352 might need this pattern is if some value, such as a pointer to a 26353 global table, must be restored when the frame pointer is restored. 26354 Note that a nonlocal goto only occurs within a unit-of-translation, 26355 so a global table pointer that is shared by all functions of a 26356 given module need not be restored. There are no arguments. 26357 26358'exception_receiver' 26359 This pattern, if defined, contains code needed at the site of an 26360 exception handler that isn't needed at the site of a nonlocal goto. 26361 You will not normally need to define this pattern. A typical 26362 reason why you might need this pattern is if some value, such as a 26363 pointer to a global table, must be restored after control flow is 26364 branched to the handler of an exception. There are no arguments. 26365 26366'builtin_setjmp_setup' 26367 This pattern, if defined, contains additional code needed to 26368 initialize the 'jmp_buf'. You will not normally need to define 26369 this pattern. A typical reason why you might need this pattern is 26370 if some value, such as a pointer to a global table, must be 26371 restored. Though it is preferred that the pointer value be 26372 recalculated if possible (given the address of a label for 26373 instance). The single argument is a pointer to the 'jmp_buf'. 26374 Note that the buffer is five words long and that the first three 26375 are normally used by the generic mechanism. 26376 26377'builtin_setjmp_receiver' 26378 This pattern, if defined, contains code needed at the site of a 26379 built-in setjmp that isn't needed at the site of a nonlocal goto. 26380 You will not normally need to define this pattern. A typical 26381 reason why you might need this pattern is if some value, such as a 26382 pointer to a global table, must be restored. It takes one 26383 argument, which is the label to which builtin_longjmp transferred 26384 control; this pattern may be emitted at a small offset from that 26385 label. 26386 26387'builtin_longjmp' 26388 This pattern, if defined, performs the entire action of the 26389 longjmp. You will not normally need to define this pattern unless 26390 you also define 'builtin_setjmp_setup'. The single argument is a 26391 pointer to the 'jmp_buf'. 26392 26393'eh_return' 26394 This pattern, if defined, affects the way '__builtin_eh_return', 26395 and thence the call frame exception handling library routines, are 26396 built. It is intended to handle non-trivial actions needed along 26397 the abnormal return path. 26398 26399 The address of the exception handler to which the function should 26400 return is passed as operand to this pattern. It will normally need 26401 to copied by the pattern to some special register or memory 26402 location. If the pattern needs to determine the location of the 26403 target call frame in order to do so, it may use 26404 'EH_RETURN_STACKADJ_RTX', if defined; it will have already been 26405 assigned. 26406 26407 If this pattern is not defined, the default action will be to 26408 simply copy the return address to 'EH_RETURN_HANDLER_RTX'. Either 26409 that macro or this pattern needs to be defined if call frame 26410 exception handling is to be used. 26411 26412'prologue' 26413 This pattern, if defined, emits RTL for entry to a function. The 26414 function entry is responsible for setting up the stack frame, 26415 initializing the frame pointer register, saving callee saved 26416 registers, etc. 26417 26418 Using a prologue pattern is generally preferred over defining 26419 'TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the 26420 prologue. 26421 26422 The 'prologue' pattern is particularly useful for targets which 26423 perform instruction scheduling. 26424 26425'window_save' 26426 This pattern, if defined, emits RTL for a register window save. It 26427 should be defined if the target machine has register windows but 26428 the window events are decoupled from calls to subroutines. The 26429 canonical example is the SPARC architecture. 26430 26431'epilogue' 26432 This pattern emits RTL for exit from a function. The function exit 26433 is responsible for deallocating the stack frame, restoring callee 26434 saved registers and emitting the return instruction. 26435 26436 Using an epilogue pattern is generally preferred over defining 26437 'TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the 26438 epilogue. 26439 26440 The 'epilogue' pattern is particularly useful for targets which 26441 perform instruction scheduling or which have delay slots for their 26442 return instruction. 26443 26444'sibcall_epilogue' 26445 This pattern, if defined, emits RTL for exit from a function 26446 without the final branch back to the calling function. This 26447 pattern will be emitted before any sibling call (aka tail call) 26448 sites. 26449 26450 The 'sibcall_epilogue' pattern must not clobber any arguments used 26451 for parameter passing or any stack slots for arguments passed to 26452 the current function. 26453 26454'trap' 26455 This pattern, if defined, signals an error, typically by causing 26456 some kind of signal to be raised. 26457 26458'ctrapMM4' 26459 Conditional trap instruction. Operand 0 is a piece of RTL which 26460 performs a comparison, and operands 1 and 2 are the arms of the 26461 comparison. Operand 3 is the trap code, an integer. 26462 26463 A typical 'ctrap' pattern looks like 26464 26465 (define_insn "ctrapsi4" 26466 [(trap_if (match_operator 0 "trap_operator" 26467 [(match_operand 1 "register_operand") 26468 (match_operand 2 "immediate_operand")]) 26469 (match_operand 3 "const_int_operand" "i"))] 26470 "" 26471 "...") 26472 26473'prefetch' 26474 This pattern, if defined, emits code for a non-faulting data 26475 prefetch instruction. Operand 0 is the address of the memory to 26476 prefetch. Operand 1 is a constant 1 if the prefetch is preparing 26477 for a write to the memory address, or a constant 0 otherwise. 26478 Operand 2 is the expected degree of temporal locality of the data 26479 and is a value between 0 and 3, inclusive; 0 means that the data 26480 has no temporal locality, so it need not be left in the cache after 26481 the access; 3 means that the data has a high degree of temporal 26482 locality and should be left in all levels of cache possible; 1 and 26483 2 mean, respectively, a low or moderate degree of temporal 26484 locality. 26485 26486 Targets that do not support write prefetches or locality hints can 26487 ignore the values of operands 1 and 2. 26488 26489'blockage' 26490 This pattern defines a pseudo insn that prevents the instruction 26491 scheduler and other passes from moving instructions and using 26492 register equivalences across the boundary defined by the blockage 26493 insn. This needs to be an UNSPEC_VOLATILE pattern or a volatile 26494 ASM. 26495 26496'memory_blockage' 26497 This pattern, if defined, represents a compiler memory barrier, and 26498 will be placed at points across which RTL passes may not propagate 26499 memory accesses. This instruction needs to read and write volatile 26500 BLKmode memory. It does not need to generate any machine 26501 instruction. If this pattern is not defined, the compiler falls 26502 back to emitting an instruction corresponding to 'asm volatile ("" 26503 ::: "memory")'. 26504 26505'memory_barrier' 26506 If the target memory model is not fully synchronous, then this 26507 pattern should be defined to an instruction that orders both loads 26508 and stores before the instruction with respect to loads and stores 26509 after the instruction. This pattern has no operands. 26510 26511'sync_compare_and_swapMODE' 26512 This pattern, if defined, emits code for an atomic compare-and-swap 26513 operation. Operand 1 is the memory on which the atomic operation 26514 is performed. Operand 2 is the "old" value to be compared against 26515 the current contents of the memory location. Operand 3 is the 26516 "new" value to store in the memory if the compare succeeds. 26517 Operand 0 is the result of the operation; it should contain the 26518 contents of the memory before the operation. If the compare 26519 succeeds, this should obviously be a copy of operand 2. 26520 26521 This pattern must show that both operand 0 and operand 1 are 26522 modified. 26523 26524 This pattern must issue any memory barrier instructions such that 26525 all memory operations before the atomic operation occur before the 26526 atomic operation and all memory operations after the atomic 26527 operation occur after the atomic operation. 26528 26529 For targets where the success or failure of the compare-and-swap 26530 operation is available via the status flags, it is possible to 26531 avoid a separate compare operation and issue the subsequent branch 26532 or store-flag operation immediately after the compare-and-swap. To 26533 this end, GCC will look for a 'MODE_CC' set in the output of 26534 'sync_compare_and_swapMODE'; if the machine description includes 26535 such a set, the target should also define special 'cbranchcc4' 26536 and/or 'cstorecc4' instructions. GCC will then be able to take the 26537 destination of the 'MODE_CC' set and pass it to the 'cbranchcc4' or 26538 'cstorecc4' pattern as the first operand of the comparison (the 26539 second will be '(const_int 0)'). 26540 26541 For targets where the operating system may provide support for this 26542 operation via library calls, the 'sync_compare_and_swap_optab' may 26543 be initialized to a function with the same interface as the 26544 '__sync_val_compare_and_swap_N' built-in. If the entire set of 26545 __SYNC builtins are supported via library calls, the target can 26546 initialize all of the optabs at once with 'init_sync_libfuncs'. 26547 For the purposes of C++11 'std::atomic::is_lock_free', it is 26548 assumed that these library calls do _not_ use any kind of 26549 interruptable locking. 26550 26551'sync_addMODE', 'sync_subMODE' 26552'sync_iorMODE', 'sync_andMODE' 26553'sync_xorMODE', 'sync_nandMODE' 26554 These patterns emit code for an atomic operation on memory. 26555 Operand 0 is the memory on which the atomic operation is performed. 26556 Operand 1 is the second operand to the binary operator. 26557 26558 This pattern must issue any memory barrier instructions such that 26559 all memory operations before the atomic operation occur before the 26560 atomic operation and all memory operations after the atomic 26561 operation occur after the atomic operation. 26562 26563 If these patterns are not defined, the operation will be 26564 constructed from a compare-and-swap operation, if defined. 26565 26566'sync_old_addMODE', 'sync_old_subMODE' 26567'sync_old_iorMODE', 'sync_old_andMODE' 26568'sync_old_xorMODE', 'sync_old_nandMODE' 26569 These patterns emit code for an atomic operation on memory, and 26570 return the value that the memory contained before the operation. 26571 Operand 0 is the result value, operand 1 is the memory on which the 26572 atomic operation is performed, and operand 2 is the second operand 26573 to the binary operator. 26574 26575 This pattern must issue any memory barrier instructions such that 26576 all memory operations before the atomic operation occur before the 26577 atomic operation and all memory operations after the atomic 26578 operation occur after the atomic operation. 26579 26580 If these patterns are not defined, the operation will be 26581 constructed from a compare-and-swap operation, if defined. 26582 26583'sync_new_addMODE', 'sync_new_subMODE' 26584'sync_new_iorMODE', 'sync_new_andMODE' 26585'sync_new_xorMODE', 'sync_new_nandMODE' 26586 These patterns are like their 'sync_old_OP' counterparts, except 26587 that they return the value that exists in the memory location after 26588 the operation, rather than before the operation. 26589 26590'sync_lock_test_and_setMODE' 26591 This pattern takes two forms, based on the capabilities of the 26592 target. In either case, operand 0 is the result of the operand, 26593 operand 1 is the memory on which the atomic operation is performed, 26594 and operand 2 is the value to set in the lock. 26595 26596 In the ideal case, this operation is an atomic exchange operation, 26597 in which the previous value in memory operand is copied into the 26598 result operand, and the value operand is stored in the memory 26599 operand. 26600 26601 For less capable targets, any value operand that is not the 26602 constant 1 should be rejected with 'FAIL'. In this case the target 26603 may use an atomic test-and-set bit operation. The result operand 26604 should contain 1 if the bit was previously set and 0 if the bit was 26605 previously clear. The true contents of the memory operand are 26606 implementation defined. 26607 26608 This pattern must issue any memory barrier instructions such that 26609 the pattern as a whole acts as an acquire barrier, that is all 26610 memory operations after the pattern do not occur until the lock is 26611 acquired. 26612 26613 If this pattern is not defined, the operation will be constructed 26614 from a compare-and-swap operation, if defined. 26615 26616'sync_lock_releaseMODE' 26617 This pattern, if defined, releases a lock set by 26618 'sync_lock_test_and_setMODE'. Operand 0 is the memory that 26619 contains the lock; operand 1 is the value to store in the lock. 26620 26621 If the target doesn't implement full semantics for 26622 'sync_lock_test_and_setMODE', any value operand which is not the 26623 constant 0 should be rejected with 'FAIL', and the true contents of 26624 the memory operand are implementation defined. 26625 26626 This pattern must issue any memory barrier instructions such that 26627 the pattern as a whole acts as a release barrier, that is the lock 26628 is released only after all previous memory operations have 26629 completed. 26630 26631 If this pattern is not defined, then a 'memory_barrier' pattern 26632 will be emitted, followed by a store of the value to the memory 26633 operand. 26634 26635'atomic_compare_and_swapMODE' 26636 This pattern, if defined, emits code for an atomic compare-and-swap 26637 operation with memory model semantics. Operand 2 is the memory on 26638 which the atomic operation is performed. Operand 0 is an output 26639 operand which is set to true or false based on whether the 26640 operation succeeded. Operand 1 is an output operand which is set 26641 to the contents of the memory before the operation was attempted. 26642 Operand 3 is the value that is expected to be in memory. Operand 4 26643 is the value to put in memory if the expected value is found there. 26644 Operand 5 is set to 1 if this compare and swap is to be treated as 26645 a weak operation. Operand 6 is the memory model to be used if the 26646 operation is a success. Operand 7 is the memory model to be used 26647 if the operation fails. 26648 26649 If memory referred to in operand 2 contains the value in operand 3, 26650 then operand 4 is stored in memory pointed to by operand 2 and 26651 fencing based on the memory model in operand 6 is issued. 26652 26653 If memory referred to in operand 2 does not contain the value in 26654 operand 3, then fencing based on the memory model in operand 7 is 26655 issued. 26656 26657 If a target does not support weak compare-and-swap operations, or 26658 the port elects not to implement weak operations, the argument in 26659 operand 5 can be ignored. Note a strong implementation must be 26660 provided. 26661 26662 If this pattern is not provided, the '__atomic_compare_exchange' 26663 built-in functions will utilize the legacy 'sync_compare_and_swap' 26664 pattern with an '__ATOMIC_SEQ_CST' memory model. 26665 26666'atomic_loadMODE' 26667 This pattern implements an atomic load operation with memory model 26668 semantics. Operand 1 is the memory address being loaded from. 26669 Operand 0 is the result of the load. Operand 2 is the memory model 26670 to be used for the load operation. 26671 26672 If not present, the '__atomic_load' built-in function will either 26673 resort to a normal load with memory barriers, or a compare-and-swap 26674 operation if a normal load would not be atomic. 26675 26676'atomic_storeMODE' 26677 This pattern implements an atomic store operation with memory model 26678 semantics. Operand 0 is the memory address being stored to. 26679 Operand 1 is the value to be written. Operand 2 is the memory 26680 model to be used for the operation. 26681 26682 If not present, the '__atomic_store' built-in function will attempt 26683 to perform a normal store and surround it with any required memory 26684 fences. If the store would not be atomic, then an 26685 '__atomic_exchange' is attempted with the result being ignored. 26686 26687'atomic_exchangeMODE' 26688 This pattern implements an atomic exchange operation with memory 26689 model semantics. Operand 1 is the memory location the operation is 26690 performed on. Operand 0 is an output operand which is set to the 26691 original value contained in the memory pointed to by operand 1. 26692 Operand 2 is the value to be stored. Operand 3 is the memory model 26693 to be used. 26694 26695 If this pattern is not present, the built-in function 26696 '__atomic_exchange' will attempt to preform the operation with a 26697 compare and swap loop. 26698 26699'atomic_addMODE', 'atomic_subMODE' 26700'atomic_orMODE', 'atomic_andMODE' 26701'atomic_xorMODE', 'atomic_nandMODE' 26702 These patterns emit code for an atomic operation on memory with 26703 memory model semantics. Operand 0 is the memory on which the 26704 atomic operation is performed. Operand 1 is the second operand to 26705 the binary operator. Operand 2 is the memory model to be used by 26706 the operation. 26707 26708 If these patterns are not defined, attempts will be made to use 26709 legacy 'sync' patterns, or equivalent patterns which return a 26710 result. If none of these are available a compare-and-swap loop 26711 will be used. 26712 26713'atomic_fetch_addMODE', 'atomic_fetch_subMODE' 26714'atomic_fetch_orMODE', 'atomic_fetch_andMODE' 26715'atomic_fetch_xorMODE', 'atomic_fetch_nandMODE' 26716 These patterns emit code for an atomic operation on memory with 26717 memory model semantics, and return the original value. Operand 0 26718 is an output operand which contains the value of the memory 26719 location before the operation was performed. Operand 1 is the 26720 memory on which the atomic operation is performed. Operand 2 is 26721 the second operand to the binary operator. Operand 3 is the memory 26722 model to be used by the operation. 26723 26724 If these patterns are not defined, attempts will be made to use 26725 legacy 'sync' patterns. If none of these are available a 26726 compare-and-swap loop will be used. 26727 26728'atomic_add_fetchMODE', 'atomic_sub_fetchMODE' 26729'atomic_or_fetchMODE', 'atomic_and_fetchMODE' 26730'atomic_xor_fetchMODE', 'atomic_nand_fetchMODE' 26731 These patterns emit code for an atomic operation on memory with 26732 memory model semantics and return the result after the operation is 26733 performed. Operand 0 is an output operand which contains the value 26734 after the operation. Operand 1 is the memory on which the atomic 26735 operation is performed. Operand 2 is the second operand to the 26736 binary operator. Operand 3 is the memory model to be used by the 26737 operation. 26738 26739 If these patterns are not defined, attempts will be made to use 26740 legacy 'sync' patterns, or equivalent patterns which return the 26741 result before the operation followed by the arithmetic operation 26742 required to produce the result. If none of these are available a 26743 compare-and-swap loop will be used. 26744 26745'atomic_test_and_set' 26746 This pattern emits code for '__builtin_atomic_test_and_set'. 26747 Operand 0 is an output operand which is set to true if the previous 26748 previous contents of the byte was "set", and false otherwise. 26749 Operand 1 is the 'QImode' memory to be modified. Operand 2 is the 26750 memory model to be used. 26751 26752 The specific value that defines "set" is implementation defined, 26753 and is normally based on what is performed by the native atomic 26754 test and set instruction. 26755 26756'atomic_bit_test_and_setMODE' 26757'atomic_bit_test_and_complementMODE' 26758'atomic_bit_test_and_resetMODE' 26759 These patterns emit code for an atomic bitwise operation on memory 26760 with memory model semantics, and return the original value of the 26761 specified bit. Operand 0 is an output operand which contains the 26762 value of the specified bit from the memory location before the 26763 operation was performed. Operand 1 is the memory on which the 26764 atomic operation is performed. Operand 2 is the bit within the 26765 operand, starting with least significant bit. Operand 3 is the 26766 memory model to be used by the operation. Operand 4 is a flag - it 26767 is 'const1_rtx' if operand 0 should contain the original value of 26768 the specified bit in the least significant bit of the operand, and 26769 'const0_rtx' if the bit should be in its original position in the 26770 operand. 'atomic_bit_test_and_setMODE' atomically sets the 26771 specified bit after remembering its original value, 26772 'atomic_bit_test_and_complementMODE' inverts the specified bit and 26773 'atomic_bit_test_and_resetMODE' clears the specified bit. 26774 26775 If these patterns are not defined, attempts will be made to use 26776 'atomic_fetch_orMODE', 'atomic_fetch_xorMODE' or 26777 'atomic_fetch_andMODE' instruction patterns, or their 'sync' 26778 counterparts. If none of these are available a compare-and-swap 26779 loop will be used. 26780 26781'mem_thread_fence' 26782 This pattern emits code required to implement a thread fence with 26783 memory model semantics. Operand 0 is the memory model to be used. 26784 26785 For the '__ATOMIC_RELAXED' model no instructions need to be issued 26786 and this expansion is not invoked. 26787 26788 The compiler always emits a compiler memory barrier regardless of 26789 what expanding this pattern produced. 26790 26791 If this pattern is not defined, the compiler falls back to 26792 expanding the 'memory_barrier' pattern, then to emitting 26793 '__sync_synchronize' library call, and finally to just placing a 26794 compiler memory barrier. 26795 26796'get_thread_pointerMODE' 26797'set_thread_pointerMODE' 26798 These patterns emit code that reads/sets the TLS thread pointer. 26799 Currently, these are only needed if the target needs to support the 26800 '__builtin_thread_pointer' and '__builtin_set_thread_pointer' 26801 builtins. 26802 26803 The get/set patterns have a single output/input operand 26804 respectively, with MODE intended to be 'Pmode'. 26805 26806'stack_protect_set' 26807 This pattern, if defined, moves a 'ptr_mode' value from the memory 26808 in operand 1 to the memory in operand 0 without leaving the value 26809 in a register afterward. This is to avoid leaking the value some 26810 place that an attacker might use to rewrite the stack guard slot 26811 after having clobbered it. 26812 26813 If this pattern is not defined, then a plain move pattern is 26814 generated. 26815 26816'stack_protect_test' 26817 This pattern, if defined, compares a 'ptr_mode' value from the 26818 memory in operand 1 with the memory in operand 0 without leaving 26819 the value in a register afterward and branches to operand 2 if the 26820 values were equal. 26821 26822 If this pattern is not defined, then a plain compare pattern and 26823 conditional branch pattern is used. 26824 26825'clear_cache' 26826 This pattern, if defined, flushes the instruction cache for a 26827 region of memory. The region is bounded to by the Pmode pointers 26828 in operand 0 inclusive and operand 1 exclusive. 26829 26830 If this pattern is not defined, a call to the library function 26831 '__clear_cache' is used. 26832 26833 26834File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc 26835 2683617.10 When the Order of Patterns Matters 26837======================================== 26838 26839Sometimes an insn can match more than one instruction pattern. Then the 26840pattern that appears first in the machine description is the one used. 26841Therefore, more specific patterns (patterns that will match fewer 26842things) and faster instructions (those that will produce better code 26843when they do match) should usually go first in the description. 26844 26845 In some cases the effect of ordering the patterns can be used to hide a 26846pattern when it is not valid. For example, the 68000 has an instruction 26847for converting a fullword to floating point and another for converting a 26848byte to floating point. An instruction converting an integer to 26849floating point could match either one. We put the pattern to convert 26850the fullword first to make sure that one will be used rather than the 26851other. (Otherwise a large integer might be generated as a single-byte 26852immediate quantity, which would not work.) Instead of using this 26853pattern ordering it would be possible to make the pattern for 26854convert-a-byte smart enough to deal properly with any constant value. 26855 26856 26857File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc 26858 2685917.11 Interdependence of Patterns 26860================================= 26861 26862In some cases machines support instructions identical except for the 26863machine mode of one or more operands. For example, there may be 26864"sign-extend halfword" and "sign-extend byte" instructions whose 26865patterns are 26866 26867 (set (match_operand:SI 0 ...) 26868 (extend:SI (match_operand:HI 1 ...))) 26869 26870 (set (match_operand:SI 0 ...) 26871 (extend:SI (match_operand:QI 1 ...))) 26872 26873Constant integers do not specify a machine mode, so an instruction to 26874extend a constant value could match either pattern. The pattern it 26875actually will match is the one that appears first in the file. For 26876correct results, this must be the one for the widest possible mode 26877('HImode', here). If the pattern matches the 'QImode' instruction, the 26878results will be incorrect if the constant value does not actually fit 26879that mode. 26880 26881 Such instructions to extend constants are rarely generated because they 26882are optimized away, but they do occasionally happen in nonoptimized 26883compilations. 26884 26885 If a constraint in a pattern allows a constant, the reload pass may 26886replace a register with a constant permitted by the constraint in some 26887cases. Similarly for memory references. Because of this substitution, 26888you should not provide separate patterns for increment and decrement 26889instructions. Instead, they should be generated from the same pattern 26890that supports register-register add insns by examining the operands and 26891generating the appropriate machine instruction. 26892 26893 26894File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc 26895 2689617.12 Defining Jump Instruction Patterns 26897======================================== 26898 26899GCC does not assume anything about how the machine realizes jumps. The 26900machine description should define a single pattern, usually a 26901'define_expand', which expands to all the required insns. 26902 26903 Usually, this would be a comparison insn to set the condition code and 26904a separate branch insn testing the condition code and branching or not 26905according to its value. For many machines, however, separating compares 26906and branches is limiting, which is why the more flexible approach with 26907one 'define_expand' is used in GCC. The machine description becomes 26908clearer for architectures that have compare-and-branch instructions but 26909no condition code. It also works better when different sets of 26910comparison operators are supported by different kinds of conditional 26911branches (e.g. integer vs. floating-point), or by conditional branches 26912with respect to conditional stores. 26913 26914 Two separate insns are always used if the machine description 26915represents a condition code register using the legacy RTL expression 26916'(cc0)', and on most machines that use a separate condition code 26917register (*note Condition Code::). For machines that use '(cc0)', in 26918fact, the set and use of the condition code must be separate and 26919adjacent(1), thus allowing flags in 'cc_status' to be used (*note 26920Condition Code::) and so that the comparison and branch insns could be 26921located from each other by using the functions 'prev_cc0_setter' and 26922'next_cc0_user'. 26923 26924 Even in this case having a single entry point for conditional branches 26925is advantageous, because it handles equally well the case where a single 26926comparison instruction records the results of both signed and unsigned 26927comparison of the given operands (with the branch insns coming in 26928distinct signed and unsigned flavors) as in the x86 or SPARC, and the 26929case where there are distinct signed and unsigned compare instructions 26930and only one set of conditional branch instructions as in the PowerPC. 26931 26932 ---------- Footnotes ---------- 26933 26934 (1) 'note' insns can separate them, though. 26935 26936 26937File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc 26938 2693917.13 Defining Looping Instruction Patterns 26940=========================================== 26941 26942Some machines have special jump instructions that can be utilized to 26943make loops more efficient. A common example is the 68000 'dbra' 26944instruction which performs a decrement of a register and a branch if the 26945result was greater than zero. Other machines, in particular digital 26946signal processors (DSPs), have special block repeat instructions to 26947provide low-overhead loop support. For example, the TI TMS320C3x/C4x 26948DSPs have a block repeat instruction that loads special registers to 26949mark the top and end of a loop and to count the number of loop 26950iterations. This avoids the need for fetching and executing a 26951'dbra'-like instruction and avoids pipeline stalls associated with the 26952jump. 26953 26954 GCC has three special named patterns to support low overhead looping. 26955They are 'decrement_and_branch_until_zero', 'doloop_begin', and 26956'doloop_end'. The first pattern, 'decrement_and_branch_until_zero', is 26957not emitted during RTL generation but may be emitted during the 26958instruction combination phase. This requires the assistance of the loop 26959optimizer, using information collected during strength reduction, to 26960reverse a loop to count down to zero. Some targets also require the 26961loop optimizer to add a 'REG_NONNEG' note to indicate that the iteration 26962count is always positive. This is needed if the target performs a 26963signed loop termination test. For example, the 68000 uses a pattern 26964similar to the following for its 'dbra' instruction: 26965 26966 (define_insn "decrement_and_branch_until_zero" 26967 [(set (pc) 26968 (if_then_else 26969 (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am") 26970 (const_int -1)) 26971 (const_int 0)) 26972 (label_ref (match_operand 1 "" "")) 26973 (pc))) 26974 (set (match_dup 0) 26975 (plus:SI (match_dup 0) 26976 (const_int -1)))] 26977 "find_reg_note (insn, REG_NONNEG, 0)" 26978 "...") 26979 26980 Note that since the insn is both a jump insn and has an output, it must 26981deal with its own reloads, hence the 'm' constraints. Also note that 26982since this insn is generated by the instruction combination phase 26983combining two sequential insns together into an implicit parallel insn, 26984the iteration counter needs to be biased by the same amount as the 26985decrement operation, in this case -1. Note that the following similar 26986pattern will not be matched by the combiner. 26987 26988 (define_insn "decrement_and_branch_until_zero" 26989 [(set (pc) 26990 (if_then_else 26991 (ge (match_operand:SI 0 "general_operand" "+d*am") 26992 (const_int 1)) 26993 (label_ref (match_operand 1 "" "")) 26994 (pc))) 26995 (set (match_dup 0) 26996 (plus:SI (match_dup 0) 26997 (const_int -1)))] 26998 "find_reg_note (insn, REG_NONNEG, 0)" 26999 "...") 27000 27001 The other two special looping patterns, 'doloop_begin' and 27002'doloop_end', are emitted by the loop optimizer for certain well-behaved 27003loops with a finite number of loop iterations using information 27004collected during strength reduction. 27005 27006 The 'doloop_end' pattern describes the actual looping instruction (or 27007the implicit looping operation) and the 'doloop_begin' pattern is an 27008optional companion pattern that can be used for initialization needed 27009for some low-overhead looping instructions. 27010 27011 Note that some machines require the actual looping instruction to be 27012emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting 27013the true RTL for a looping instruction at the top of the loop can cause 27014problems with flow analysis. So instead, a dummy 'doloop' insn is 27015emitted at the end of the loop. The machine dependent reorg pass checks 27016for the presence of this 'doloop' insn and then searches back to the top 27017of the loop, where it inserts the true looping insn (provided there are 27018no instructions in the loop which would cause problems). Any additional 27019labels can be emitted at this point. In addition, if the desired 27020special iteration counter register was not allocated, this machine 27021dependent reorg pass could emit a traditional compare and jump 27022instruction pair. 27023 27024 The essential difference between the 'decrement_and_branch_until_zero' 27025and the 'doloop_end' patterns is that the loop optimizer allocates an 27026additional pseudo register for the latter as an iteration counter. This 27027pseudo register cannot be used within the loop (i.e., general induction 27028variables cannot be derived from it), however, in many cases the loop 27029induction variable may become redundant and removed by the flow pass. 27030 27031 27032File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc 27033 2703417.14 Canonicalization of Instructions 27035====================================== 27036 27037There are often cases where multiple RTL expressions could represent an 27038operation performed by a single machine instruction. This situation is 27039most commonly encountered with logical, branch, and multiply-accumulate 27040instructions. In such cases, the compiler attempts to convert these 27041multiple RTL expressions into a single canonical form to reduce the 27042number of insn patterns required. 27043 27044 In addition to algebraic simplifications, following canonicalizations 27045are performed: 27046 27047 * For commutative and comparison operators, a constant is always made 27048 the second operand. If a machine only supports a constant as the 27049 second operand, only patterns that match a constant in the second 27050 operand need be supplied. 27051 27052 * For associative operators, a sequence of operators will always 27053 chain to the left; for instance, only the left operand of an 27054 integer 'plus' can itself be a 'plus'. 'and', 'ior', 'xor', 27055 'plus', 'mult', 'smin', 'smax', 'umin', and 'umax' are associative 27056 when applied to integers, and sometimes to floating-point. 27057 27058 * For these operators, if only one operand is a 'neg', 'not', 'mult', 27059 'plus', or 'minus' expression, it will be the first operand. 27060 27061 * In combinations of 'neg', 'mult', 'plus', and 'minus', the 'neg' 27062 operations (if any) will be moved inside the operations as far as 27063 possible. For instance, '(neg (mult A B))' is canonicalized as 27064 '(mult (neg A) B)', but '(plus (mult (neg B) C) A)' is 27065 canonicalized as '(minus A (mult B C))'. 27066 27067 * For the 'compare' operator, a constant is always the second operand 27068 if the first argument is a condition code register or '(cc0)'. 27069 27070 * For instructions that inherently set a condition code register, the 27071 'compare' operator is always written as the first RTL expression of 27072 the 'parallel' instruction pattern. For example, 27073 27074 (define_insn "" 27075 [(set (reg:CCZ FLAGS_REG) 27076 (compare:CCZ 27077 (plus:SI 27078 (match_operand:SI 1 "register_operand" "%r") 27079 (match_operand:SI 2 "register_operand" "r")) 27080 (const_int 0))) 27081 (set (match_operand:SI 0 "register_operand" "=r") 27082 (plus:SI (match_dup 1) (match_dup 2)))] 27083 "" 27084 "addl %0, %1, %2") 27085 27086 * An operand of 'neg', 'not', 'mult', 'plus', or 'minus' is made the 27087 first operand under the same conditions as above. 27088 27089 * '(ltu (plus A B) B)' is converted to '(ltu (plus A B) A)'. 27090 Likewise with 'geu' instead of 'ltu'. 27091 27092 * '(minus X (const_int N))' is converted to '(plus X (const_int 27093 -N))'. 27094 27095 * Within address computations (i.e., inside 'mem'), a left shift is 27096 converted into the appropriate multiplication by a power of two. 27097 27098 * De Morgan's Law is used to move bitwise negation inside a bitwise 27099 logical-and or logical-or operation. If this results in only one 27100 operand being a 'not' expression, it will be the first one. 27101 27102 A machine that has an instruction that performs a bitwise 27103 logical-and of one operand with the bitwise negation of the other 27104 should specify the pattern for that instruction as 27105 27106 (define_insn "" 27107 [(set (match_operand:M 0 ...) 27108 (and:M (not:M (match_operand:M 1 ...)) 27109 (match_operand:M 2 ...)))] 27110 "..." 27111 "...") 27112 27113 Similarly, a pattern for a "NAND" instruction should be written 27114 27115 (define_insn "" 27116 [(set (match_operand:M 0 ...) 27117 (ior:M (not:M (match_operand:M 1 ...)) 27118 (not:M (match_operand:M 2 ...))))] 27119 "..." 27120 "...") 27121 27122 In both cases, it is not necessary to include patterns for the many 27123 logically equivalent RTL expressions. 27124 27125 * The only possible RTL expressions involving both bitwise 27126 exclusive-or and bitwise negation are '(xor:M X Y)' and '(not:M 27127 (xor:M X Y))'. 27128 27129 * The sum of three items, one of which is a constant, will only 27130 appear in the form 27131 27132 (plus:M (plus:M X Y) CONSTANT) 27133 27134 * Equality comparisons of a group of bits (usually a single bit) with 27135 zero will be written using 'zero_extract' rather than the 27136 equivalent 'and' or 'sign_extract' operations. 27137 27138 * '(sign_extend:M1 (mult:M2 (sign_extend:M2 X) (sign_extend:M2 Y)))' 27139 is converted to '(mult:M1 (sign_extend:M1 X) (sign_extend:M1 Y))', 27140 and likewise for 'zero_extend'. 27141 27142 * '(sign_extend:M1 (mult:M2 (ashiftrt:M2 X S) (sign_extend:M2 Y)))' 27143 is converted to '(mult:M1 (sign_extend:M1 (ashiftrt:M2 X S)) 27144 (sign_extend:M1 Y))', and likewise for patterns using 'zero_extend' 27145 and 'lshiftrt'. If the second operand of 'mult' is also a shift, 27146 then that is extended also. This transformation is only applied 27147 when it can be proven that the original operation had sufficient 27148 precision to prevent overflow. 27149 27150 Further canonicalization rules are defined in the function 27151'commutative_operand_precedence' in 'gcc/rtlanal.c'. 27152 27153 27154File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc 27155 2715617.15 Defining RTL Sequences for Code Generation 27157================================================ 27158 27159On some target machines, some standard pattern names for RTL generation 27160cannot be handled with single insn, but a sequence of RTL insns can 27161represent them. For these target machines, you can write a 27162'define_expand' to specify how to generate the sequence of RTL. 27163 27164 A 'define_expand' is an RTL expression that looks almost like a 27165'define_insn'; but, unlike the latter, a 'define_expand' is used only 27166for RTL generation and it can produce more than one RTL insn. 27167 27168 A 'define_expand' RTX has four operands: 27169 27170 * The name. Each 'define_expand' must have a name, since the only 27171 use for it is to refer to it by name. 27172 27173 * The RTL template. This is a vector of RTL expressions representing 27174 a sequence of separate instructions. Unlike 'define_insn', there 27175 is no implicit surrounding 'PARALLEL'. 27176 27177 * The condition, a string containing a C expression. This expression 27178 is used to express how the availability of this pattern depends on 27179 subclasses of target machine, selected by command-line options when 27180 GCC is run. This is just like the condition of a 'define_insn' 27181 that has a standard name. Therefore, the condition (if present) 27182 may not depend on the data in the insn being matched, but only the 27183 target-machine-type flags. The compiler needs to test these 27184 conditions during initialization in order to learn exactly which 27185 named instructions are available in a particular run. 27186 27187 * The preparation statements, a string containing zero or more C 27188 statements which are to be executed before RTL code is generated 27189 from the RTL template. 27190 27191 Usually these statements prepare temporary registers for use as 27192 internal operands in the RTL template, but they can also generate 27193 RTL insns directly by calling routines such as 'emit_insn', etc. 27194 Any such insns precede the ones that come from the RTL template. 27195 27196 * Optionally, a vector containing the values of attributes. *Note 27197 Insn Attributes::. 27198 27199 Every RTL insn emitted by a 'define_expand' must match some 27200'define_insn' in the machine description. Otherwise, the compiler will 27201crash when trying to generate code for the insn or trying to optimize 27202it. 27203 27204 The RTL template, in addition to controlling generation of RTL insns, 27205also describes the operands that need to be specified when this pattern 27206is used. In particular, it gives a predicate for each operand. 27207 27208 A true operand, which needs to be specified in order to generate RTL 27209from the pattern, should be described with a 'match_operand' in its 27210first occurrence in the RTL template. This enters information on the 27211operand's predicate into the tables that record such things. GCC uses 27212the information to preload the operand into a register if that is 27213required for valid RTL code. If the operand is referred to more than 27214once, subsequent references should use 'match_dup'. 27215 27216 The RTL template may also refer to internal "operands" which are 27217temporary registers or labels used only within the sequence made by the 27218'define_expand'. Internal operands are substituted into the RTL 27219template with 'match_dup', never with 'match_operand'. The values of 27220the internal operands are not passed in as arguments by the compiler 27221when it requests use of this pattern. Instead, they are computed within 27222the pattern, in the preparation statements. These statements compute 27223the values and store them into the appropriate elements of 'operands' so 27224that 'match_dup' can find them. 27225 27226 There are two special macros defined for use in the preparation 27227statements: 'DONE' and 'FAIL'. Use them with a following semicolon, as 27228a statement. 27229 27230'DONE' 27231 Use the 'DONE' macro to end RTL generation for the pattern. The 27232 only RTL insns resulting from the pattern on this occasion will be 27233 those already emitted by explicit calls to 'emit_insn' within the 27234 preparation statements; the RTL template will not be generated. 27235 27236'FAIL' 27237 Make the pattern fail on this occasion. When a pattern fails, it 27238 means that the pattern was not truly available. The calling 27239 routines in the compiler will try other strategies for code 27240 generation using other patterns. 27241 27242 Failure is currently supported only for binary (addition, 27243 multiplication, shifting, etc.) and bit-field ('extv', 'extzv', 27244 and 'insv') operations. 27245 27246 If the preparation falls through (invokes neither 'DONE' nor 'FAIL'), 27247then the 'define_expand' acts like a 'define_insn' in that the RTL 27248template is used to generate the insn. 27249 27250 The RTL template is not used for matching, only for generating the 27251initial insn list. If the preparation statement always invokes 'DONE' 27252or 'FAIL', the RTL template may be reduced to a simple list of operands, 27253such as this example: 27254 27255 (define_expand "addsi3" 27256 [(match_operand:SI 0 "register_operand" "") 27257 (match_operand:SI 1 "register_operand" "") 27258 (match_operand:SI 2 "register_operand" "")] 27259 "" 27260 " 27261 { 27262 handle_add (operands[0], operands[1], operands[2]); 27263 DONE; 27264 }") 27265 27266 Here is an example, the definition of left-shift for the SPUR chip: 27267 27268 (define_expand "ashlsi3" 27269 [(set (match_operand:SI 0 "register_operand" "") 27270 (ashift:SI 27271 (match_operand:SI 1 "register_operand" "") 27272 (match_operand:SI 2 "nonmemory_operand" "")))] 27273 "" 27274 " 27275 27276 { 27277 if (GET_CODE (operands[2]) != CONST_INT 27278 || (unsigned) INTVAL (operands[2]) > 3) 27279 FAIL; 27280 }") 27281 27282This example uses 'define_expand' so that it can generate an RTL insn 27283for shifting when the shift-count is in the supported range of 0 to 3 27284but fail in other cases where machine insns aren't available. When it 27285fails, the compiler tries another strategy using different patterns 27286(such as, a library call). 27287 27288 If the compiler were able to handle nontrivial condition-strings in 27289patterns with names, then it would be possible to use a 'define_insn' in 27290that case. Here is another case (zero-extension on the 68000) which 27291makes more use of the power of 'define_expand': 27292 27293 (define_expand "zero_extendhisi2" 27294 [(set (match_operand:SI 0 "general_operand" "") 27295 (const_int 0)) 27296 (set (strict_low_part 27297 (subreg:HI 27298 (match_dup 0) 27299 0)) 27300 (match_operand:HI 1 "general_operand" ""))] 27301 "" 27302 "operands[1] = make_safe_from (operands[1], operands[0]);") 27303 27304Here two RTL insns are generated, one to clear the entire output operand 27305and the other to copy the input operand into its low half. This 27306sequence is incorrect if the input operand refers to [the old value of] 27307the output operand, so the preparation statement makes sure this isn't 27308so. The function 'make_safe_from' copies the 'operands[1]' into a 27309temporary register if it refers to 'operands[0]'. It does this by 27310emitting another RTL insn. 27311 27312 Finally, a third example shows the use of an internal operand. 27313Zero-extension on the SPUR chip is done by 'and'-ing the result against 27314a halfword mask. But this mask cannot be represented by a 'const_int' 27315because the constant value is too large to be legitimate on this 27316machine. So it must be copied into a register with 'force_reg' and then 27317the register used in the 'and'. 27318 27319 (define_expand "zero_extendhisi2" 27320 [(set (match_operand:SI 0 "register_operand" "") 27321 (and:SI (subreg:SI 27322 (match_operand:HI 1 "register_operand" "") 27323 0) 27324 (match_dup 2)))] 27325 "" 27326 "operands[2] 27327 = force_reg (SImode, GEN_INT (65535)); ") 27328 27329 _Note:_ If the 'define_expand' is used to serve a standard binary or 27330unary arithmetic operation or a bit-field operation, then the last insn 27331it generates must not be a 'code_label', 'barrier' or 'note'. It must 27332be an 'insn', 'jump_insn' or 'call_insn'. If you don't need a real insn 27333at the end, emit an insn to copy the result of the operation into 27334itself. Such an insn will generate no code, but it can avoid problems 27335in the compiler. 27336 27337 27338File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc 27339 2734017.16 Defining How to Split Instructions 27341======================================== 27342 27343There are two cases where you should specify how to split a pattern into 27344multiple insns. On machines that have instructions requiring delay 27345slots (*note Delay Slots::) or that have instructions whose output is 27346not available for multiple cycles (*note Processor pipeline 27347description::), the compiler phases that optimize these cases need to be 27348able to move insns into one-instruction delay slots. However, some 27349insns may generate more than one machine instruction. These insns 27350cannot be placed into a delay slot. 27351 27352 Often you can rewrite the single insn as a list of individual insns, 27353each corresponding to one machine instruction. The disadvantage of 27354doing so is that it will cause the compilation to be slower and require 27355more space. If the resulting insns are too complex, it may also 27356suppress some optimizations. The compiler splits the insn if there is a 27357reason to believe that it might improve instruction or delay slot 27358scheduling. 27359 27360 The insn combiner phase also splits putative insns. If three insns are 27361merged into one insn with a complex expression that cannot be matched by 27362some 'define_insn' pattern, the combiner phase attempts to split the 27363complex pattern into two insns that are recognized. Usually it can 27364break the complex pattern into two patterns by splitting out some 27365subexpression. However, in some other cases, such as performing an 27366addition of a large constant in two insns on a RISC machine, the way to 27367split the addition into two insns is machine-dependent. 27368 27369 The 'define_split' definition tells the compiler how to split a complex 27370insn into several simpler insns. It looks like this: 27371 27372 (define_split 27373 [INSN-PATTERN] 27374 "CONDITION" 27375 [NEW-INSN-PATTERN-1 27376 NEW-INSN-PATTERN-2 27377 ...] 27378 "PREPARATION-STATEMENTS") 27379 27380 INSN-PATTERN is a pattern that needs to be split and CONDITION is the 27381final condition to be tested, as in a 'define_insn'. When an insn 27382matching INSN-PATTERN and satisfying CONDITION is found, it is replaced 27383in the insn list with the insns given by NEW-INSN-PATTERN-1, 27384NEW-INSN-PATTERN-2, etc. 27385 27386 The PREPARATION-STATEMENTS are similar to those statements that are 27387specified for 'define_expand' (*note Expander Definitions::) and are 27388executed before the new RTL is generated to prepare for the generated 27389code or emit some insns whose pattern is not fixed. Unlike those in 27390'define_expand', however, these statements must not generate any new 27391pseudo-registers. Once reload has completed, they also must not 27392allocate any space in the stack frame. 27393 27394 Patterns are matched against INSN-PATTERN in two different 27395circumstances. If an insn needs to be split for delay slot scheduling 27396or insn scheduling, the insn is already known to be valid, which means 27397that it must have been matched by some 'define_insn' and, if 27398'reload_completed' is nonzero, is known to satisfy the constraints of 27399that 'define_insn'. In that case, the new insn patterns must also be 27400insns that are matched by some 'define_insn' and, if 'reload_completed' 27401is nonzero, must also satisfy the constraints of those definitions. 27402 27403 As an example of this usage of 'define_split', consider the following 27404example from 'a29k.md', which splits a 'sign_extend' from 'HImode' to 27405'SImode' into a pair of shift insns: 27406 27407 (define_split 27408 [(set (match_operand:SI 0 "gen_reg_operand" "") 27409 (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] 27410 "" 27411 [(set (match_dup 0) 27412 (ashift:SI (match_dup 1) 27413 (const_int 16))) 27414 (set (match_dup 0) 27415 (ashiftrt:SI (match_dup 0) 27416 (const_int 16)))] 27417 " 27418 { operands[1] = gen_lowpart (SImode, operands[1]); }") 27419 27420 When the combiner phase tries to split an insn pattern, it is always 27421the case that the pattern is _not_ matched by any 'define_insn'. The 27422combiner pass first tries to split a single 'set' expression and then 27423the same 'set' expression inside a 'parallel', but followed by a 27424'clobber' of a pseudo-reg to use as a scratch register. In these cases, 27425the combiner expects exactly two new insn patterns to be generated. It 27426will verify that these patterns match some 'define_insn' definitions, so 27427you need not do this test in the 'define_split' (of course, there is no 27428point in writing a 'define_split' that will never produce insns that 27429match). 27430 27431 Here is an example of this use of 'define_split', taken from 27432'rs6000.md': 27433 27434 (define_split 27435 [(set (match_operand:SI 0 "gen_reg_operand" "") 27436 (plus:SI (match_operand:SI 1 "gen_reg_operand" "") 27437 (match_operand:SI 2 "non_add_cint_operand" "")))] 27438 "" 27439 [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) 27440 (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] 27441 " 27442 { 27443 int low = INTVAL (operands[2]) & 0xffff; 27444 int high = (unsigned) INTVAL (operands[2]) >> 16; 27445 27446 if (low & 0x8000) 27447 high++, low |= 0xffff0000; 27448 27449 operands[3] = GEN_INT (high << 16); 27450 operands[4] = GEN_INT (low); 27451 }") 27452 27453 Here the predicate 'non_add_cint_operand' matches any 'const_int' that 27454is _not_ a valid operand of a single add insn. The add with the smaller 27455displacement is written so that it can be substituted into the address 27456of a subsequent operation. 27457 27458 An example that uses a scratch register, from the same file, generates 27459an equality comparison of a register and a large constant: 27460 27461 (define_split 27462 [(set (match_operand:CC 0 "cc_reg_operand" "") 27463 (compare:CC (match_operand:SI 1 "gen_reg_operand" "") 27464 (match_operand:SI 2 "non_short_cint_operand" ""))) 27465 (clobber (match_operand:SI 3 "gen_reg_operand" ""))] 27466 "find_single_use (operands[0], insn, 0) 27467 && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ 27468 || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" 27469 [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) 27470 (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] 27471 " 27472 { 27473 /* Get the constant we are comparing against, C, and see what it 27474 looks like sign-extended to 16 bits. Then see what constant 27475 could be XOR'ed with C to get the sign-extended value. */ 27476 27477 int c = INTVAL (operands[2]); 27478 int sextc = (c << 16) >> 16; 27479 int xorv = c ^ sextc; 27480 27481 operands[4] = GEN_INT (xorv); 27482 operands[5] = GEN_INT (sextc); 27483 }") 27484 27485 To avoid confusion, don't write a single 'define_split' that accepts 27486some insns that match some 'define_insn' as well as some insns that 27487don't. Instead, write two separate 'define_split' definitions, one for 27488the insns that are valid and one for the insns that are not valid. 27489 27490 The splitter is allowed to split jump instructions into sequence of 27491jumps or create new jumps in while splitting non-jump instructions. As 27492the control flow graph and branch prediction information needs to be 27493updated, several restriction apply. 27494 27495 Splitting of jump instruction into sequence that over by another jump 27496instruction is always valid, as compiler expect identical behavior of 27497new jump. When new sequence contains multiple jump instructions or new 27498labels, more assistance is needed. Splitter is required to create only 27499unconditional jumps, or simple conditional jump instructions. 27500Additionally it must attach a 'REG_BR_PROB' note to each conditional 27501jump. A global variable 'split_branch_probability' holds the 27502probability of the original branch in case it was a simple conditional 27503jump, -1 otherwise. To simplify recomputing of edge frequencies, the 27504new sequence is required to have only forward jumps to the newly created 27505labels. 27506 27507 For the common case where the pattern of a define_split exactly matches 27508the pattern of a define_insn, use 'define_insn_and_split'. It looks 27509like this: 27510 27511 (define_insn_and_split 27512 [INSN-PATTERN] 27513 "CONDITION" 27514 "OUTPUT-TEMPLATE" 27515 "SPLIT-CONDITION" 27516 [NEW-INSN-PATTERN-1 27517 NEW-INSN-PATTERN-2 27518 ...] 27519 "PREPARATION-STATEMENTS" 27520 [INSN-ATTRIBUTES]) 27521 27522 27523 INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used 27524as in 'define_insn'. The NEW-INSN-PATTERN vector and the 27525PREPARATION-STATEMENTS are used as in a 'define_split'. The 27526SPLIT-CONDITION is also used as in 'define_split', with the additional 27527behavior that if the condition starts with '&&', the condition used for 27528the split will be the constructed as a logical "and" of the split 27529condition with the insn condition. For example, from i386.md: 27530 27531 (define_insn_and_split "zero_extendhisi2_and" 27532 [(set (match_operand:SI 0 "register_operand" "=r") 27533 (zero_extend:SI (match_operand:HI 1 "register_operand" "0"))) 27534 (clobber (reg:CC 17))] 27535 "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size" 27536 "#" 27537 "&& reload_completed" 27538 [(parallel [(set (match_dup 0) 27539 (and:SI (match_dup 0) (const_int 65535))) 27540 (clobber (reg:CC 17))])] 27541 "" 27542 [(set_attr "type" "alu1")]) 27543 27544 27545 In this case, the actual split condition will be 27546'TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'. 27547 27548 The 'define_insn_and_split' construction provides exactly the same 27549functionality as two separate 'define_insn' and 'define_split' patterns. 27550It exists for compactness, and as a maintenance tool to prevent having 27551to ensure the two patterns' templates match. 27552 27553 27554File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc 27555 2755617.17 Including Patterns in Machine Descriptions. 27557================================================= 27558 27559The 'include' pattern tells the compiler tools where to look for 27560patterns that are in files other than in the file '.md'. This is used 27561only at build time and there is no preprocessing allowed. 27562 27563 It looks like: 27564 27565 27566 (include 27567 PATHNAME) 27568 27569 For example: 27570 27571 27572 (include "filestuff") 27573 27574 27575 Where PATHNAME is a string that specifies the location of the file, 27576specifies the include file to be in 'gcc/config/target/filestuff'. The 27577directory 'gcc/config/target' is regarded as the default directory. 27578 27579 Machine descriptions may be split up into smaller more manageable 27580subsections and placed into subdirectories. 27581 27582 By specifying: 27583 27584 27585 (include "BOGUS/filestuff") 27586 27587 27588 the include file is specified to be in 27589'gcc/config/TARGET/BOGUS/filestuff'. 27590 27591 Specifying an absolute path for the include file such as; 27592 27593 (include "/u2/BOGUS/filestuff") 27594 27595 is permitted but is not encouraged. 27596 2759717.17.1 RTL Generation Tool Options for Directory Search 27598-------------------------------------------------------- 27599 27600The '-IDIR' option specifies directories to search for machine 27601descriptions. For example: 27602 27603 27604 genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md 27605 27606 27607 Add the directory DIR to the head of the list of directories to be 27608searched for header files. This can be used to override a system 27609machine definition file, substituting your own version, since these 27610directories are searched before the default machine description file 27611directories. If you use more than one '-I' option, the directories are 27612scanned in left-to-right order; the standard default directory come 27613after. 27614 27615 27616File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc 27617 2761817.18 Machine-Specific Peephole Optimizers 27619========================================== 27620 27621In addition to instruction patterns the 'md' file may contain 27622definitions of machine-specific peephole optimizations. 27623 27624 The combiner does not notice certain peephole optimizations when the 27625data flow in the program does not suggest that it should try them. For 27626example, sometimes two consecutive insns related in purpose can be 27627combined even though the second one does not appear to use a register 27628computed in the first one. A machine-specific peephole optimizer can 27629detect such opportunities. 27630 27631 There are two forms of peephole definitions that may be used. The 27632original 'define_peephole' is run at assembly output time to match insns 27633and substitute assembly text. Use of 'define_peephole' is deprecated. 27634 27635 A newer 'define_peephole2' matches insns and substitutes new insns. 27636The 'peephole2' pass is run after register allocation but before 27637scheduling, which may result in much better code for targets that do 27638scheduling. 27639 27640* Menu: 27641 27642* define_peephole:: RTL to Text Peephole Optimizers 27643* define_peephole2:: RTL to RTL Peephole Optimizers 27644 27645 27646File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions 27647 2764817.18.1 RTL to Text Peephole Optimizers 27649--------------------------------------- 27650 27651A definition looks like this: 27652 27653 (define_peephole 27654 [INSN-PATTERN-1 27655 INSN-PATTERN-2 27656 ...] 27657 "CONDITION" 27658 "TEMPLATE" 27659 "OPTIONAL-INSN-ATTRIBUTES") 27660 27661The last string operand may be omitted if you are not using any 27662machine-specific information in this machine description. If present, 27663it must obey the same rules as in a 'define_insn'. 27664 27665 In this skeleton, INSN-PATTERN-1 and so on are patterns to match 27666consecutive insns. The optimization applies to a sequence of insns when 27667INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next, 27668and so on. 27669 27670 Each of the insns matched by a peephole must also match a 27671'define_insn'. Peepholes are checked only at the last stage just before 27672code generation, and only optionally. Therefore, any insn which would 27673match a peephole but no 'define_insn' will cause a crash in code 27674generation in an unoptimized compilation, or at various optimization 27675stages. 27676 27677 The operands of the insns are matched with 'match_operands', 27678'match_operator', and 'match_dup', as usual. What is not usual is that 27679the operand numbers apply to all the insn patterns in the definition. 27680So, you can check for identical operands in two insns by using 27681'match_operand' in one insn and 'match_dup' in the other. 27682 27683 The operand constraints used in 'match_operand' patterns do not have 27684any direct effect on the applicability of the peephole, but they will be 27685validated afterward, so make sure your constraints are general enough to 27686apply whenever the peephole matches. If the peephole matches but the 27687constraints are not satisfied, the compiler will crash. 27688 27689 It is safe to omit constraints in all the operands of the peephole; or 27690you can write constraints which serve as a double-check on the criteria 27691previously tested. 27692 27693 Once a sequence of insns matches the patterns, the CONDITION is 27694checked. This is a C expression which makes the final decision whether 27695to perform the optimization (we do so if the expression is nonzero). If 27696CONDITION is omitted (in other words, the string is empty) then the 27697optimization is applied to every sequence of insns that matches the 27698patterns. 27699 27700 The defined peephole optimizations are applied after register 27701allocation is complete. Therefore, the peephole definition can check 27702which operands have ended up in which kinds of registers, just by 27703looking at the operands. 27704 27705 The way to refer to the operands in CONDITION is to write 'operands[I]' 27706for operand number I (as matched by '(match_operand I ...)'). Use the 27707variable 'insn' to refer to the last of the insns being matched; use 27708'prev_active_insn' to find the preceding insns. 27709 27710 When optimizing computations with intermediate results, you can use 27711CONDITION to match only when the intermediate results are not used 27712elsewhere. Use the C expression 'dead_or_set_p (INSN, OP)', where INSN 27713is the insn in which you expect the value to be used for the last time 27714(from the value of 'insn', together with use of 'prev_nonnote_insn'), 27715and OP is the intermediate value (from 'operands[I]'). 27716 27717 Applying the optimization means replacing the sequence of insns with 27718one new insn. The TEMPLATE controls ultimate output of assembler code 27719for this combined insn. It works exactly like the template of a 27720'define_insn'. Operand numbers in this template are the same ones used 27721in matching the original sequence of insns. 27722 27723 The result of a defined peephole optimizer does not need to match any 27724of the insn patterns in the machine description; it does not even have 27725an opportunity to match them. The peephole optimizer definition itself 27726serves as the insn pattern to control how the insn is output. 27727 27728 Defined peephole optimizers are run as assembler code is being output, 27729so the insns they produce are never combined or rearranged in any way. 27730 27731 Here is an example, taken from the 68000 machine description: 27732 27733 (define_peephole 27734 [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) 27735 (set (match_operand:DF 0 "register_operand" "=f") 27736 (match_operand:DF 1 "register_operand" "ad"))] 27737 "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" 27738 { 27739 rtx xoperands[2]; 27740 xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1); 27741 #ifdef MOTOROLA 27742 output_asm_insn ("move.l %1,(sp)", xoperands); 27743 output_asm_insn ("move.l %1,-(sp)", operands); 27744 return "fmove.d (sp)+,%0"; 27745 #else 27746 output_asm_insn ("movel %1,sp@", xoperands); 27747 output_asm_insn ("movel %1,sp@-", operands); 27748 return "fmoved sp@+,%0"; 27749 #endif 27750 }) 27751 27752 The effect of this optimization is to change 27753 27754 jbsr _foobar 27755 addql #4,sp 27756 movel d1,sp@- 27757 movel d0,sp@- 27758 fmoved sp@+,fp0 27759 27760into 27761 27762 jbsr _foobar 27763 movel d1,sp@ 27764 movel d0,sp@- 27765 fmoved sp@+,fp0 27766 27767 INSN-PATTERN-1 and so on look _almost_ like the second operand of 27768'define_insn'. There is one important difference: the second operand of 27769'define_insn' consists of one or more RTX's enclosed in square brackets. 27770Usually, there is only one: then the same action can be written as an 27771element of a 'define_peephole'. But when there are multiple actions in 27772a 'define_insn', they are implicitly enclosed in a 'parallel'. Then you 27773must explicitly write the 'parallel', and the square brackets within it, 27774in the 'define_peephole'. Thus, if an insn pattern looks like this, 27775 27776 (define_insn "divmodsi4" 27777 [(set (match_operand:SI 0 "general_operand" "=d") 27778 (div:SI (match_operand:SI 1 "general_operand" "0") 27779 (match_operand:SI 2 "general_operand" "dmsK"))) 27780 (set (match_operand:SI 3 "general_operand" "=d") 27781 (mod:SI (match_dup 1) (match_dup 2)))] 27782 "TARGET_68020" 27783 "divsl%.l %2,%3:%0") 27784 27785then the way to mention this insn in a peephole is as follows: 27786 27787 (define_peephole 27788 [... 27789 (parallel 27790 [(set (match_operand:SI 0 "general_operand" "=d") 27791 (div:SI (match_operand:SI 1 "general_operand" "0") 27792 (match_operand:SI 2 "general_operand" "dmsK"))) 27793 (set (match_operand:SI 3 "general_operand" "=d") 27794 (mod:SI (match_dup 1) (match_dup 2)))]) 27795 ...] 27796 ...) 27797 27798 27799File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions 27800 2780117.18.2 RTL to RTL Peephole Optimizers 27802-------------------------------------- 27803 27804The 'define_peephole2' definition tells the compiler how to substitute 27805one sequence of instructions for another sequence, what additional 27806scratch registers may be needed and what their lifetimes must be. 27807 27808 (define_peephole2 27809 [INSN-PATTERN-1 27810 INSN-PATTERN-2 27811 ...] 27812 "CONDITION" 27813 [NEW-INSN-PATTERN-1 27814 NEW-INSN-PATTERN-2 27815 ...] 27816 "PREPARATION-STATEMENTS") 27817 27818 The definition is almost identical to 'define_split' (*note Insn 27819Splitting::) except that the pattern to match is not a single 27820instruction, but a sequence of instructions. 27821 27822 It is possible to request additional scratch registers for use in the 27823output template. If appropriate registers are not free, the pattern 27824will simply not match. 27825 27826 Scratch registers are requested with a 'match_scratch' pattern at the 27827top level of the input pattern. The allocated register (initially) will 27828be dead at the point requested within the original sequence. If the 27829scratch is used at more than a single point, a 'match_dup' pattern at 27830the top level of the input pattern marks the last position in the input 27831sequence at which the register must be available. 27832 27833 Here is an example from the IA-32 machine description: 27834 27835 (define_peephole2 27836 [(match_scratch:SI 2 "r") 27837 (parallel [(set (match_operand:SI 0 "register_operand" "") 27838 (match_operator:SI 3 "arith_or_logical_operator" 27839 [(match_dup 0) 27840 (match_operand:SI 1 "memory_operand" "")])) 27841 (clobber (reg:CC 17))])] 27842 "! optimize_size && ! TARGET_READ_MODIFY" 27843 [(set (match_dup 2) (match_dup 1)) 27844 (parallel [(set (match_dup 0) 27845 (match_op_dup 3 [(match_dup 0) (match_dup 2)])) 27846 (clobber (reg:CC 17))])] 27847 "") 27848 27849This pattern tries to split a load from its use in the hopes that we'll 27850be able to schedule around the memory load latency. It allocates a 27851single 'SImode' register of class 'GENERAL_REGS' ('"r"') that needs to 27852be live only at the point just before the arithmetic. 27853 27854 A real example requiring extended scratch lifetimes is harder to come 27855by, so here's a silly made-up example: 27856 27857 (define_peephole2 27858 [(match_scratch:SI 4 "r") 27859 (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" "")) 27860 (set (match_operand:SI 2 "" "") (match_dup 1)) 27861 (match_dup 4) 27862 (set (match_operand:SI 3 "" "") (match_dup 1))] 27863 "/* determine 1 does not overlap 0 and 2 */" 27864 [(set (match_dup 4) (match_dup 1)) 27865 (set (match_dup 0) (match_dup 4)) 27866 (set (match_dup 2) (match_dup 4)) 27867 (set (match_dup 3) (match_dup 4))] 27868 "") 27869 27870If we had not added the '(match_dup 4)' in the middle of the input 27871sequence, it might have been the case that the register we chose at the 27872beginning of the sequence is killed by the first or second 'set'. 27873 27874 27875File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc 27876 2787717.19 Instruction Attributes 27878============================ 27879 27880In addition to describing the instruction supported by the target 27881machine, the 'md' file also defines a group of "attributes" and a set of 27882values for each. Every generated insn is assigned a value for each 27883attribute. One possible attribute would be the effect that the insn has 27884on the machine's condition code. This attribute can then be used by 27885'NOTICE_UPDATE_CC' to track the condition codes. 27886 27887* Menu: 27888 27889* Defining Attributes:: Specifying attributes and their values. 27890* Expressions:: Valid expressions for attribute values. 27891* Tagging Insns:: Assigning attribute values to insns. 27892* Attr Example:: An example of assigning attributes. 27893* Insn Lengths:: Computing the length of insns. 27894* Constant Attributes:: Defining attributes that are constant. 27895* Mnemonic Attribute:: Obtain the instruction mnemonic as attribute value. 27896* Delay Slots:: Defining delay slots required for a machine. 27897* Processor pipeline description:: Specifying information for insn scheduling. 27898 27899 27900File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes 27901 2790217.19.1 Defining Attributes and their Values 27903-------------------------------------------- 27904 27905The 'define_attr' expression is used to define each attribute required 27906by the target machine. It looks like: 27907 27908 (define_attr NAME LIST-OF-VALUES DEFAULT) 27909 27910 NAME is a string specifying the name of the attribute being defined. 27911Some attributes are used in a special way by the rest of the compiler. 27912The 'enabled' attribute can be used to conditionally enable or disable 27913insn alternatives (*note Disable Insn Alternatives::). The 'predicable' 27914attribute, together with a suitable 'define_cond_exec' (*note 27915Conditional Execution::), can be used to automatically generate 27916conditional variants of instruction patterns. The 'mnemonic' attribute 27917can be used to check for the instruction mnemonic (*note Mnemonic 27918Attribute::). The compiler internally uses the names 'ce_enabled' and 27919'nonce_enabled', so they should not be used elsewhere as alternative 27920names. 27921 27922 LIST-OF-VALUES is either a string that specifies a comma-separated list 27923of values that can be assigned to the attribute, or a null string to 27924indicate that the attribute takes numeric values. 27925 27926 DEFAULT is an attribute expression that gives the value of this 27927attribute for insns that match patterns whose definition does not 27928include an explicit value for this attribute. *Note Attr Example::, for 27929more information on the handling of defaults. *Note Constant 27930Attributes::, for information on attributes that do not depend on any 27931particular insn. 27932 27933 For each defined attribute, a number of definitions are written to the 27934'insn-attr.h' file. For cases where an explicit set of values is 27935specified for an attribute, the following are defined: 27936 27937 * A '#define' is written for the symbol 'HAVE_ATTR_NAME'. 27938 27939 * An enumerated class is defined for 'attr_NAME' with elements of the 27940 form 'UPPER-NAME_UPPER-VALUE' where the attribute name and value 27941 are first converted to uppercase. 27942 27943 * A function 'get_attr_NAME' is defined that is passed an insn and 27944 returns the attribute value for that insn. 27945 27946 For example, if the following is present in the 'md' file: 27947 27948 (define_attr "type" "branch,fp,load,store,arith" ...) 27949 27950the following lines will be written to the file 'insn-attr.h'. 27951 27952 #define HAVE_ATTR_type 1 27953 enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, 27954 TYPE_STORE, TYPE_ARITH}; 27955 extern enum attr_type get_attr_type (); 27956 27957 If the attribute takes numeric values, no 'enum' type will be defined 27958and the function to obtain the attribute's value will return 'int'. 27959 27960 There are attributes which are tied to a specific meaning. These 27961attributes are not free to use for other purposes: 27962 27963'length' 27964 The 'length' attribute is used to calculate the length of emitted 27965 code chunks. This is especially important when verifying branch 27966 distances. *Note Insn Lengths::. 27967 27968'enabled' 27969 The 'enabled' attribute can be defined to prevent certain 27970 alternatives of an insn definition from being used during code 27971 generation. *Note Disable Insn Alternatives::. 27972 27973'mnemonic' 27974 The 'mnemonic' attribute can be defined to implement instruction 27975 specific checks in e.g. the pipeline description. *Note Mnemonic 27976 Attribute::. 27977 27978 For each of these special attributes, the corresponding 27979'HAVE_ATTR_NAME' '#define' is also written when the attribute is not 27980defined; in that case, it is defined as '0'. 27981 27982 Another way of defining an attribute is to use: 27983 27984 (define_enum_attr "ATTR" "ENUM" DEFAULT) 27985 27986 This works in just the same way as 'define_attr', except that the list 27987of values is taken from a separate enumeration called ENUM (*note 27988define_enum::). This form allows you to use the same list of values for 27989several attributes without having to repeat the list each time. For 27990example: 27991 27992 (define_enum "processor" [ 27993 model_a 27994 model_b 27995 ... 27996 ]) 27997 (define_enum_attr "arch" "processor" 27998 (const (symbol_ref "target_arch"))) 27999 (define_enum_attr "tune" "processor" 28000 (const (symbol_ref "target_tune"))) 28001 28002 defines the same attributes as: 28003 28004 (define_attr "arch" "model_a,model_b,..." 28005 (const (symbol_ref "target_arch"))) 28006 (define_attr "tune" "model_a,model_b,..." 28007 (const (symbol_ref "target_tune"))) 28008 28009 but without duplicating the processor list. The second example defines 28010two separate C enums ('attr_arch' and 'attr_tune') whereas the first 28011defines a single C enum ('processor'). 28012 28013 28014File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes 28015 2801617.19.2 Attribute Expressions 28017----------------------------- 28018 28019RTL expressions used to define attributes use the codes described above 28020plus a few specific to attribute definitions, to be discussed below. 28021Attribute value expressions must have one of the following forms: 28022 28023'(const_int I)' 28024 The integer I specifies the value of a numeric attribute. I must 28025 be non-negative. 28026 28027 The value of a numeric attribute can be specified either with a 28028 'const_int', or as an integer represented as a string in 28029 'const_string', 'eq_attr' (see below), 'attr', 'symbol_ref', simple 28030 arithmetic expressions, and 'set_attr' overrides on specific 28031 instructions (*note Tagging Insns::). 28032 28033'(const_string VALUE)' 28034 The string VALUE specifies a constant attribute value. If VALUE is 28035 specified as '"*"', it means that the default value of the 28036 attribute is to be used for the insn containing this expression. 28037 '"*"' obviously cannot be used in the DEFAULT expression of a 28038 'define_attr'. 28039 28040 If the attribute whose value is being specified is numeric, VALUE 28041 must be a string containing a non-negative integer (normally 28042 'const_int' would be used in this case). Otherwise, it must 28043 contain one of the valid values for the attribute. 28044 28045'(if_then_else TEST TRUE-VALUE FALSE-VALUE)' 28046 TEST specifies an attribute test, whose format is defined below. 28047 The value of this expression is TRUE-VALUE if TEST is true, 28048 otherwise it is FALSE-VALUE. 28049 28050'(cond [TEST1 VALUE1 ...] DEFAULT)' 28051 The first operand of this expression is a vector containing an even 28052 number of expressions and consisting of pairs of TEST and VALUE 28053 expressions. The value of the 'cond' expression is that of the 28054 VALUE corresponding to the first true TEST expression. If none of 28055 the TEST expressions are true, the value of the 'cond' expression 28056 is that of the DEFAULT expression. 28057 28058 TEST expressions can have one of the following forms: 28059 28060'(const_int I)' 28061 This test is true if I is nonzero and false otherwise. 28062 28063'(not TEST)' 28064'(ior TEST1 TEST2)' 28065'(and TEST1 TEST2)' 28066 These tests are true if the indicated logical function is true. 28067 28068'(match_operand:M N PRED CONSTRAINTS)' 28069 This test is true if operand N of the insn whose attribute value is 28070 being determined has mode M (this part of the test is ignored if M 28071 is 'VOIDmode') and the function specified by the string PRED 28072 returns a nonzero value when passed operand N and mode M (this part 28073 of the test is ignored if PRED is the null string). 28074 28075 The CONSTRAINTS operand is ignored and should be the null string. 28076 28077'(match_test C-EXPR)' 28078 The test is true if C expression C-EXPR is true. In non-constant 28079 attributes, C-EXPR has access to the following variables: 28080 28081 INSN 28082 The rtl instruction under test. 28083 WHICH_ALTERNATIVE 28084 The 'define_insn' alternative that INSN matches. *Note Output 28085 Statement::. 28086 OPERANDS 28087 An array of INSN's rtl operands. 28088 28089 C-EXPR behaves like the condition in a C 'if' statement, so there 28090 is no need to explicitly convert the expression into a boolean 0 or 28091 1 value. For example, the following two tests are equivalent: 28092 28093 (match_test "x & 2") 28094 (match_test "(x & 2) != 0") 28095 28096'(le ARITH1 ARITH2)' 28097'(leu ARITH1 ARITH2)' 28098'(lt ARITH1 ARITH2)' 28099'(ltu ARITH1 ARITH2)' 28100'(gt ARITH1 ARITH2)' 28101'(gtu ARITH1 ARITH2)' 28102'(ge ARITH1 ARITH2)' 28103'(geu ARITH1 ARITH2)' 28104'(ne ARITH1 ARITH2)' 28105'(eq ARITH1 ARITH2)' 28106 These tests are true if the indicated comparison of the two 28107 arithmetic expressions is true. Arithmetic expressions are formed 28108 with 'plus', 'minus', 'mult', 'div', 'mod', 'abs', 'neg', 'and', 28109 'ior', 'xor', 'not', 'ashift', 'lshiftrt', and 'ashiftrt' 28110 expressions. 28111 28112 'const_int' and 'symbol_ref' are always valid terms (*note Insn 28113 Lengths::,for additional forms). 'symbol_ref' is a string denoting 28114 a C expression that yields an 'int' when evaluated by the 28115 'get_attr_...' routine. It should normally be a global variable. 28116 28117'(eq_attr NAME VALUE)' 28118 NAME is a string specifying the name of an attribute. 28119 28120 VALUE is a string that is either a valid value for attribute NAME, 28121 a comma-separated list of values, or '!' followed by a value or 28122 list. If VALUE does not begin with a '!', this test is true if the 28123 value of the NAME attribute of the current insn is in the list 28124 specified by VALUE. If VALUE begins with a '!', this test is true 28125 if the attribute's value is _not_ in the specified list. 28126 28127 For example, 28128 28129 (eq_attr "type" "load,store") 28130 28131 is equivalent to 28132 28133 (ior (eq_attr "type" "load") (eq_attr "type" "store")) 28134 28135 If NAME specifies an attribute of 'alternative', it refers to the 28136 value of the compiler variable 'which_alternative' (*note Output 28137 Statement::) and the values must be small integers. For example, 28138 28139 (eq_attr "alternative" "2,3") 28140 28141 is equivalent to 28142 28143 (ior (eq (symbol_ref "which_alternative") (const_int 2)) 28144 (eq (symbol_ref "which_alternative") (const_int 3))) 28145 28146 Note that, for most attributes, an 'eq_attr' test is simplified in 28147 cases where the value of the attribute being tested is known for 28148 all insns matching a particular pattern. This is by far the most 28149 common case. 28150 28151'(attr_flag NAME)' 28152 The value of an 'attr_flag' expression is true if the flag 28153 specified by NAME is true for the 'insn' currently being scheduled. 28154 28155 NAME is a string specifying one of a fixed set of flags to test. 28156 Test the flags 'forward' and 'backward' to determine the direction 28157 of a conditional branch. 28158 28159 This example describes a conditional branch delay slot which can be 28160 nullified for forward branches that are taken (annul-true) or for 28161 backward branches which are not taken (annul-false). 28162 28163 (define_delay (eq_attr "type" "cbranch") 28164 [(eq_attr "in_branch_delay" "true") 28165 (and (eq_attr "in_branch_delay" "true") 28166 (attr_flag "forward")) 28167 (and (eq_attr "in_branch_delay" "true") 28168 (attr_flag "backward"))]) 28169 28170 The 'forward' and 'backward' flags are false if the current 'insn' 28171 being scheduled is not a conditional branch. 28172 28173 'attr_flag' is only used during delay slot scheduling and has no 28174 meaning to other passes of the compiler. 28175 28176'(attr NAME)' 28177 The value of another attribute is returned. This is most useful 28178 for numeric attributes, as 'eq_attr' and 'attr_flag' produce more 28179 efficient code for non-numeric attributes. 28180 28181 28182File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes 28183 2818417.19.3 Assigning Attribute Values to Insns 28185------------------------------------------- 28186 28187The value assigned to an attribute of an insn is primarily determined by 28188which pattern is matched by that insn (or which 'define_peephole' 28189generated it). Every 'define_insn' and 'define_peephole' can have an 28190optional last argument to specify the values of attributes for matching 28191insns. The value of any attribute not specified in a particular insn is 28192set to the default value for that attribute, as specified in its 28193'define_attr'. Extensive use of default values for attributes permits 28194the specification of the values for only one or two attributes in the 28195definition of most insn patterns, as seen in the example in the next 28196section. 28197 28198 The optional last argument of 'define_insn' and 'define_peephole' is a 28199vector of expressions, each of which defines the value for a single 28200attribute. The most general way of assigning an attribute's value is to 28201use a 'set' expression whose first operand is an 'attr' expression 28202giving the name of the attribute being set. The second operand of the 28203'set' is an attribute expression (*note Expressions::) giving the value 28204of the attribute. 28205 28206 When the attribute value depends on the 'alternative' attribute (i.e., 28207which is the applicable alternative in the constraint of the insn), the 28208'set_attr_alternative' expression can be used. It allows the 28209specification of a vector of attribute expressions, one for each 28210alternative. 28211 28212 When the generality of arbitrary attribute expressions is not required, 28213the simpler 'set_attr' expression can be used, which allows specifying a 28214string giving either a single attribute value or a list of attribute 28215values, one for each alternative. 28216 28217 The form of each of the above specifications is shown below. In each 28218case, NAME is a string specifying the attribute to be set. 28219 28220'(set_attr NAME VALUE-STRING)' 28221 VALUE-STRING is either a string giving the desired attribute value, 28222 or a string containing a comma-separated list giving the values for 28223 succeeding alternatives. The number of elements must match the 28224 number of alternatives in the constraint of the insn pattern. 28225 28226 Note that it may be useful to specify '*' for some alternative, in 28227 which case the attribute will assume its default value for insns 28228 matching that alternative. 28229 28230'(set_attr_alternative NAME [VALUE1 VALUE2 ...])' 28231 Depending on the alternative of the insn, the value will be one of 28232 the specified values. This is a shorthand for using a 'cond' with 28233 tests on the 'alternative' attribute. 28234 28235'(set (attr NAME) VALUE)' 28236 The first operand of this 'set' must be the special RTL expression 28237 'attr', whose sole operand is a string giving the name of the 28238 attribute being set. VALUE is the value of the attribute. 28239 28240 The following shows three different ways of representing the same 28241attribute value specification: 28242 28243 (set_attr "type" "load,store,arith") 28244 28245 (set_attr_alternative "type" 28246 [(const_string "load") (const_string "store") 28247 (const_string "arith")]) 28248 28249 (set (attr "type") 28250 (cond [(eq_attr "alternative" "1") (const_string "load") 28251 (eq_attr "alternative" "2") (const_string "store")] 28252 (const_string "arith"))) 28253 28254 The 'define_asm_attributes' expression provides a mechanism to specify 28255the attributes assigned to insns produced from an 'asm' statement. It 28256has the form: 28257 28258 (define_asm_attributes [ATTR-SETS]) 28259 28260where ATTR-SETS is specified the same as for both the 'define_insn' and 28261the 'define_peephole' expressions. 28262 28263 These values will typically be the "worst case" attribute values. For 28264example, they might indicate that the condition code will be clobbered. 28265 28266 A specification for a 'length' attribute is handled specially. The way 28267to compute the length of an 'asm' insn is to multiply the length 28268specified in the expression 'define_asm_attributes' by the number of 28269machine instructions specified in the 'asm' statement, determined by 28270counting the number of semicolons and newlines in the string. 28271Therefore, the value of the 'length' attribute specified in a 28272'define_asm_attributes' should be the maximum possible length of a 28273single machine instruction. 28274 28275 28276File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes 28277 2827817.19.4 Example of Attribute Specifications 28279------------------------------------------- 28280 28281The judicious use of defaulting is important in the efficient use of 28282insn attributes. Typically, insns are divided into "types" and an 28283attribute, customarily called 'type', is used to represent this value. 28284This attribute is normally used only to define the default value for 28285other attributes. An example will clarify this usage. 28286 28287 Assume we have a RISC machine with a condition code and in which only 28288full-word operations are performed in registers. Let us assume that we 28289can divide all insns into loads, stores, (integer) arithmetic 28290operations, floating point operations, and branches. 28291 28292 Here we will concern ourselves with determining the effect of an insn 28293on the condition code and will limit ourselves to the following possible 28294effects: The condition code can be set unpredictably (clobbered), not be 28295changed, be set to agree with the results of the operation, or only 28296changed if the item previously set into the condition code has been 28297modified. 28298 28299 Here is part of a sample 'md' file for such a machine: 28300 28301 (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) 28302 28303 (define_attr "cc" "clobber,unchanged,set,change0" 28304 (cond [(eq_attr "type" "load") 28305 (const_string "change0") 28306 (eq_attr "type" "store,branch") 28307 (const_string "unchanged") 28308 (eq_attr "type" "arith") 28309 (if_then_else (match_operand:SI 0 "" "") 28310 (const_string "set") 28311 (const_string "clobber"))] 28312 (const_string "clobber"))) 28313 28314 (define_insn "" 28315 [(set (match_operand:SI 0 "general_operand" "=r,r,m") 28316 (match_operand:SI 1 "general_operand" "r,m,r"))] 28317 "" 28318 "@ 28319 move %0,%1 28320 load %0,%1 28321 store %0,%1" 28322 [(set_attr "type" "arith,load,store")]) 28323 28324 Note that we assume in the above example that arithmetic operations 28325performed on quantities smaller than a machine word clobber the 28326condition code since they will set the condition code to a value 28327corresponding to the full-word result. 28328 28329 28330File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes 28331 2833217.19.5 Computing the Length of an Insn 28333--------------------------------------- 28334 28335For many machines, multiple types of branch instructions are provided, 28336each for different length branch displacements. In most cases, the 28337assembler will choose the correct instruction to use. However, when the 28338assembler cannot do so, GCC can when a special attribute, the 'length' 28339attribute, is defined. This attribute must be defined to have numeric 28340values by specifying a null string in its 'define_attr'. 28341 28342 In the case of the 'length' attribute, two additional forms of 28343arithmetic terms are allowed in test expressions: 28344 28345'(match_dup N)' 28346 This refers to the address of operand N of the current insn, which 28347 must be a 'label_ref'. 28348 28349'(pc)' 28350 For non-branch instructions and backward branch instructions, this 28351 refers to the address of the current insn. But for forward branch 28352 instructions, this refers to the address of the next insn, because 28353 the length of the current insn is to be computed. 28354 28355 For normal insns, the length will be determined by value of the 28356'length' attribute. In the case of 'addr_vec' and 'addr_diff_vec' insn 28357patterns, the length is computed as the number of vectors multiplied by 28358the size of each vector. 28359 28360 Lengths are measured in addressable storage units (bytes). 28361 28362 Note that it is possible to call functions via the 'symbol_ref' 28363mechanism to compute the length of an insn. However, if you use this 28364mechanism you must provide dummy clauses to express the maximum length 28365without using the function call. You can an example of this in the 'pa' 28366machine description for the 'call_symref' pattern. 28367 28368 The following macros can be used to refine the length computation: 28369 28370'ADJUST_INSN_LENGTH (INSN, LENGTH)' 28371 If defined, modifies the length assigned to instruction INSN as a 28372 function of the context in which it is used. LENGTH is an lvalue 28373 that contains the initially computed length of the insn and should 28374 be updated with the correct length of the insn. 28375 28376 This macro will normally not be required. A case in which it is 28377 required is the ROMP. On this machine, the size of an 'addr_vec' 28378 insn must be increased by two to compensate for the fact that 28379 alignment may be required. 28380 28381 The routine that returns 'get_attr_length' (the value of the 'length' 28382attribute) can be used by the output routine to determine the form of 28383the branch instruction to be written, as the example below illustrates. 28384 28385 As an example of the specification of variable-length branches, 28386consider the IBM 360. If we adopt the convention that a register will 28387be set to the starting address of a function, we can jump to labels 28388within 4k of the start using a four-byte instruction. Otherwise, we 28389need a six-byte sequence to load the address from memory and then branch 28390to it. 28391 28392 On such a machine, a pattern for a branch instruction might be 28393specified as follows: 28394 28395 (define_insn "jump" 28396 [(set (pc) 28397 (label_ref (match_operand 0 "" "")))] 28398 "" 28399 { 28400 return (get_attr_length (insn) == 4 28401 ? "b %l0" : "l r15,=a(%l0); br r15"); 28402 } 28403 [(set (attr "length") 28404 (if_then_else (lt (match_dup 0) (const_int 4096)) 28405 (const_int 4) 28406 (const_int 6)))]) 28407 28408 28409File: gccint.info, Node: Constant Attributes, Next: Mnemonic Attribute, Prev: Insn Lengths, Up: Insn Attributes 28410 2841117.19.6 Constant Attributes 28412--------------------------- 28413 28414A special form of 'define_attr', where the expression for the default 28415value is a 'const' expression, indicates an attribute that is constant 28416for a given run of the compiler. Constant attributes may be used to 28417specify which variety of processor is used. For example, 28418 28419 (define_attr "cpu" "m88100,m88110,m88000" 28420 (const 28421 (cond [(symbol_ref "TARGET_88100") (const_string "m88100") 28422 (symbol_ref "TARGET_88110") (const_string "m88110")] 28423 (const_string "m88000")))) 28424 28425 (define_attr "memory" "fast,slow" 28426 (const 28427 (if_then_else (symbol_ref "TARGET_FAST_MEM") 28428 (const_string "fast") 28429 (const_string "slow")))) 28430 28431 The routine generated for constant attributes has no parameters as it 28432does not depend on any particular insn. RTL expressions used to define 28433the value of a constant attribute may use the 'symbol_ref' form, but may 28434not use either the 'match_operand' form or 'eq_attr' forms involving 28435insn attributes. 28436 28437 28438File: gccint.info, Node: Mnemonic Attribute, Next: Delay Slots, Prev: Constant Attributes, Up: Insn Attributes 28439 2844017.19.7 Mnemonic Attribute 28441-------------------------- 28442 28443The 'mnemonic' attribute is a string type attribute holding the 28444instruction mnemonic for an insn alternative. The attribute values will 28445automatically be generated by the machine description parser if there is 28446an attribute definition in the md file: 28447 28448 (define_attr "mnemonic" "unknown" (const_string "unknown")) 28449 28450 The default value can be freely chosen as long as it does not collide 28451with any of the instruction mnemonics. This value will be used whenever 28452the machine description parser is not able to determine the mnemonic 28453string. This might be the case for output templates containing more 28454than a single instruction as in '"mvcle\t%0,%1,0\;jo\t.-4"'. 28455 28456 The 'mnemonic' attribute set is not generated automatically if the 28457instruction string is generated via C code. 28458 28459 An existing 'mnemonic' attribute set in an insn definition will not be 28460overriden by the md file parser. That way it is possible to manually 28461set the instruction mnemonics for the cases where the md file parser 28462fails to determine it automatically. 28463 28464 The 'mnemonic' attribute is useful for dealing with instruction 28465specific properties in the pipeline description without defining 28466additional insn attributes. 28467 28468 (define_attr "ooo_expanded" "" 28469 (cond [(eq_attr "mnemonic" "dlr,dsgr,d,dsgf,stam,dsgfr,dlgr") 28470 (const_int 1)] 28471 (const_int 0))) 28472 28473 28474File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Mnemonic Attribute, Up: Insn Attributes 28475 2847617.19.8 Delay Slot Scheduling 28477----------------------------- 28478 28479The insn attribute mechanism can be used to specify the requirements for 28480delay slots, if any, on a target machine. An instruction is said to 28481require a "delay slot" if some instructions that are physically after 28482the instruction are executed as if they were located before it. Classic 28483examples are branch and call instructions, which often execute the 28484following instruction before the branch or call is performed. 28485 28486 On some machines, conditional branch instructions can optionally 28487"annul" instructions in the delay slot. This means that the instruction 28488will not be executed for certain branch outcomes. Both instructions 28489that annul if the branch is true and instructions that annul if the 28490branch is false are supported. 28491 28492 Delay slot scheduling differs from instruction scheduling in that 28493determining whether an instruction needs a delay slot is dependent only 28494on the type of instruction being generated, not on data flow between the 28495instructions. See the next section for a discussion of data-dependent 28496instruction scheduling. 28497 28498 The requirement of an insn needing one or more delay slots is indicated 28499via the 'define_delay' expression. It has the following form: 28500 28501 (define_delay TEST 28502 [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 28503 DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 28504 ...]) 28505 28506 TEST is an attribute test that indicates whether this 'define_delay' 28507applies to a particular insn. If so, the number of required delay slots 28508is determined by the length of the vector specified as the second 28509argument. An insn placed in delay slot N must satisfy attribute test 28510DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns 28511may be annulled if the branch is true. Similarly, ANNUL-FALSE-N 28512specifies which insns in the delay slot may be annulled if the branch is 28513false. If annulling is not supported for that delay slot, '(nil)' 28514should be coded. 28515 28516 For example, in the common case where branch and call insns require a 28517single delay slot, which may contain any insn other than a branch or 28518call, the following would be placed in the 'md' file: 28519 28520 (define_delay (eq_attr "type" "branch,call") 28521 [(eq_attr "type" "!branch,call") (nil) (nil)]) 28522 28523 Multiple 'define_delay' expressions may be specified. In this case, 28524each such expression specifies different delay slot requirements and 28525there must be no insn for which tests in two 'define_delay' expressions 28526are both true. 28527 28528 For example, if we have a machine that requires one delay slot for 28529branches but two for calls, no delay slot can contain a branch or call 28530insn, and any valid insn in the delay slot for the branch can be 28531annulled if the branch is true, we might represent this as follows: 28532 28533 (define_delay (eq_attr "type" "branch") 28534 [(eq_attr "type" "!branch,call") 28535 (eq_attr "type" "!branch,call") 28536 (nil)]) 28537 28538 (define_delay (eq_attr "type" "call") 28539 [(eq_attr "type" "!branch,call") (nil) (nil) 28540 (eq_attr "type" "!branch,call") (nil) (nil)]) 28541 28542 28543File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes 28544 2854517.19.9 Specifying processor pipeline description 28546------------------------------------------------- 28547 28548To achieve better performance, most modern processors (super-pipelined, 28549superscalar RISC, and VLIW processors) have many "functional units" on 28550which several instructions can be executed simultaneously. An 28551instruction starts execution if its issue conditions are satisfied. If 28552not, the instruction is stalled until its conditions are satisfied. 28553Such "interlock (pipeline) delay" causes interruption of the fetching of 28554successor instructions (or demands nop instructions, e.g. for some MIPS 28555processors). 28556 28557 There are two major kinds of interlock delays in modern processors. 28558The first one is a data dependence delay determining "instruction 28559latency time". The instruction execution is not started until all 28560source data have been evaluated by prior instructions (there are more 28561complex cases when the instruction execution starts even when the data 28562are not available but will be ready in given time after the instruction 28563execution start). Taking the data dependence delays into account is 28564simple. The data dependence (true, output, and anti-dependence) delay 28565between two instructions is given by a constant. In most cases this 28566approach is adequate. The second kind of interlock delays is a 28567reservation delay. The reservation delay means that two instructions 28568under execution will be in need of shared processors resources, i.e. 28569buses, internal registers, and/or functional units, which are reserved 28570for some time. Taking this kind of delay into account is complex 28571especially for modern RISC processors. 28572 28573 The task of exploiting more processor parallelism is solved by an 28574instruction scheduler. For a better solution to this problem, the 28575instruction scheduler has to have an adequate description of the 28576processor parallelism (or "pipeline description"). GCC machine 28577descriptions describe processor parallelism and functional unit 28578reservations for groups of instructions with the aid of "regular 28579expressions". 28580 28581 The GCC instruction scheduler uses a "pipeline hazard recognizer" to 28582figure out the possibility of the instruction issue by the processor on 28583a given simulated processor cycle. The pipeline hazard recognizer is 28584automatically generated from the processor pipeline description. The 28585pipeline hazard recognizer generated from the machine description is 28586based on a deterministic finite state automaton (DFA): the instruction 28587issue is possible if there is a transition from one automaton state to 28588another one. This algorithm is very fast, and furthermore, its speed is 28589not dependent on processor complexity(1). 28590 28591 The rest of this section describes the directives that constitute an 28592automaton-based processor pipeline description. The order of these 28593constructions within the machine description file is not important. 28594 28595 The following optional construction describes names of automata 28596generated and used for the pipeline hazards recognition. Sometimes the 28597generated finite state automaton used by the pipeline hazard recognizer 28598is large. If we use more than one automaton and bind functional units 28599to the automata, the total size of the automata is usually less than the 28600size of the single automaton. If there is no one such construction, 28601only one finite state automaton is generated. 28602 28603 (define_automaton AUTOMATA-NAMES) 28604 28605 AUTOMATA-NAMES is a string giving names of the automata. The names are 28606separated by commas. All the automata should have unique names. The 28607automaton name is used in the constructions 'define_cpu_unit' and 28608'define_query_cpu_unit'. 28609 28610 Each processor functional unit used in the description of instruction 28611reservations should be described by the following construction. 28612 28613 (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 28614 28615 UNIT-NAMES is a string giving the names of the functional units 28616separated by commas. Don't use name 'nothing', it is reserved for other 28617goals. 28618 28619 AUTOMATON-NAME is a string giving the name of the automaton with which 28620the unit is bound. The automaton should be described in construction 28621'define_automaton'. You should give "automaton-name", if there is a 28622defined automaton. 28623 28624 The assignment of units to automata are constrained by the uses of the 28625units in insn reservations. The most important constraint is: if a unit 28626reservation is present on a particular cycle of an alternative for an 28627insn reservation, then some unit from the same automaton must be present 28628on the same cycle for the other alternatives of the insn reservation. 28629The rest of the constraints are mentioned in the description of the 28630subsequent constructions. 28631 28632 The following construction describes CPU functional units analogously 28633to 'define_cpu_unit'. The reservation of such units can be queried for 28634an automaton state. The instruction scheduler never queries reservation 28635of functional units for given automaton state. So as a rule, you don't 28636need this construction. This construction could be used for future code 28637generation goals (e.g. to generate VLIW insn templates). 28638 28639 (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 28640 28641 UNIT-NAMES is a string giving names of the functional units separated 28642by commas. 28643 28644 AUTOMATON-NAME is a string giving the name of the automaton with which 28645the unit is bound. 28646 28647 The following construction is the major one to describe pipeline 28648characteristics of an instruction. 28649 28650 (define_insn_reservation INSN-NAME DEFAULT_LATENCY 28651 CONDITION REGEXP) 28652 28653 DEFAULT_LATENCY is a number giving latency time of the instruction. 28654There is an important difference between the old description and the 28655automaton based pipeline description. The latency time is used for all 28656dependencies when we use the old description. In the automaton based 28657pipeline description, the given latency time is only used for true 28658dependencies. The cost of anti-dependencies is always zero and the cost 28659of output dependencies is the difference between latency times of the 28660producing and consuming insns (if the difference is negative, the cost 28661is considered to be zero). You can always change the default costs for 28662any description by using the target hook 'TARGET_SCHED_ADJUST_COST' 28663(*note Scheduling::). 28664 28665 INSN-NAME is a string giving the internal name of the insn. The 28666internal names are used in constructions 'define_bypass' and in the 28667automaton description file generated for debugging. The internal name 28668has nothing in common with the names in 'define_insn'. It is a good 28669practice to use insn classes described in the processor manual. 28670 28671 CONDITION defines what RTL insns are described by this construction. 28672You should remember that you will be in trouble if CONDITION for two or 28673more different 'define_insn_reservation' constructions is TRUE for an 28674insn. In this case what reservation will be used for the insn is not 28675defined. Such cases are not checked during generation of the pipeline 28676hazards recognizer because in general recognizing that two conditions 28677may have the same value is quite difficult (especially if the conditions 28678contain 'symbol_ref'). It is also not checked during the pipeline 28679hazard recognizer work because it would slow down the recognizer 28680considerably. 28681 28682 REGEXP is a string describing the reservation of the cpu's functional 28683units by the instruction. The reservations are described by a regular 28684expression according to the following syntax: 28685 28686 regexp = regexp "," oneof 28687 | oneof 28688 28689 oneof = oneof "|" allof 28690 | allof 28691 28692 allof = allof "+" repeat 28693 | repeat 28694 28695 repeat = element "*" number 28696 | element 28697 28698 element = cpu_function_unit_name 28699 | reservation_name 28700 | result_name 28701 | "nothing" 28702 | "(" regexp ")" 28703 28704 * ',' is used for describing the start of the next cycle in the 28705 reservation. 28706 28707 * '|' is used for describing a reservation described by the first 28708 regular expression *or* a reservation described by the second 28709 regular expression *or* etc. 28710 28711 * '+' is used for describing a reservation described by the first 28712 regular expression *and* a reservation described by the second 28713 regular expression *and* etc. 28714 28715 * '*' is used for convenience and simply means a sequence in which 28716 the regular expression are repeated NUMBER times with cycle 28717 advancing (see ','). 28718 28719 * 'cpu_function_unit_name' denotes reservation of the named 28720 functional unit. 28721 28722 * 'reservation_name' -- see description of construction 28723 'define_reservation'. 28724 28725 * 'nothing' denotes no unit reservations. 28726 28727 Sometimes unit reservations for different insns contain common parts. 28728In such case, you can simplify the pipeline description by describing 28729the common part by the following construction 28730 28731 (define_reservation RESERVATION-NAME REGEXP) 28732 28733 RESERVATION-NAME is a string giving name of REGEXP. Functional unit 28734names and reservation names are in the same name space. So the 28735reservation names should be different from the functional unit names and 28736can not be the reserved name 'nothing'. 28737 28738 The following construction is used to describe exceptions in the 28739latency time for given instruction pair. This is so called bypasses. 28740 28741 (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES 28742 [GUARD]) 28743 28744 NUMBER defines when the result generated by the instructions given in 28745string OUT_INSN_NAMES will be ready for the instructions given in string 28746IN_INSN_NAMES. Each of these strings is a comma-separated list of 28747filename-style globs and they refer to the names of 28748'define_insn_reservation's. For example: 28749 (define_bypass 1 "cpu1_load_*, cpu1_store_*" "cpu1_load_*") 28750 defines a bypass between instructions that start with 'cpu1_load_' or 28751'cpu1_store_' and those that start with 'cpu1_load_'. 28752 28753 GUARD is an optional string giving the name of a C function which 28754defines an additional guard for the bypass. The function will get the 28755two insns as parameters. If the function returns zero the bypass will 28756be ignored for this case. The additional guard is necessary to 28757recognize complicated bypasses, e.g. when the consumer is only an 28758address of insn 'store' (not a stored value). 28759 28760 If there are more one bypass with the same output and input insns, the 28761chosen bypass is the first bypass with a guard in description whose 28762guard function returns nonzero. If there is no such bypass, then bypass 28763without the guard function is chosen. 28764 28765 The following five constructions are usually used to describe VLIW 28766processors, or more precisely, to describe a placement of small 28767instructions into VLIW instruction slots. They can be used for RISC 28768processors, too. 28769 28770 (exclusion_set UNIT-NAMES UNIT-NAMES) 28771 (presence_set UNIT-NAMES PATTERNS) 28772 (final_presence_set UNIT-NAMES PATTERNS) 28773 (absence_set UNIT-NAMES PATTERNS) 28774 (final_absence_set UNIT-NAMES PATTERNS) 28775 28776 UNIT-NAMES is a string giving names of functional units separated by 28777commas. 28778 28779 PATTERNS is a string giving patterns of functional units separated by 28780comma. Currently pattern is one unit or units separated by 28781white-spaces. 28782 28783 The first construction ('exclusion_set') means that each functional 28784unit in the first string can not be reserved simultaneously with a unit 28785whose name is in the second string and vice versa. For example, the 28786construction is useful for describing processors (e.g. some SPARC 28787processors) with a fully pipelined floating point functional unit which 28788can execute simultaneously only single floating point insns or only 28789double floating point insns. 28790 28791 The second construction ('presence_set') means that each functional 28792unit in the first string can not be reserved unless at least one of 28793pattern of units whose names are in the second string is reserved. This 28794is an asymmetric relation. For example, it is useful for description 28795that VLIW 'slot1' is reserved after 'slot0' reservation. We could 28796describe it by the following construction 28797 28798 (presence_set "slot1" "slot0") 28799 28800 Or 'slot1' is reserved only after 'slot0' and unit 'b0' reservation. 28801In this case we could write 28802 28803 (presence_set "slot1" "slot0 b0") 28804 28805 The third construction ('final_presence_set') is analogous to 28806'presence_set'. The difference between them is when checking is done. 28807When an instruction is issued in given automaton state reflecting all 28808current and planned unit reservations, the automaton state is changed. 28809The first state is a source state, the second one is a result state. 28810Checking for 'presence_set' is done on the source state reservation, 28811checking for 'final_presence_set' is done on the result reservation. 28812This construction is useful to describe a reservation which is actually 28813two subsequent reservations. For example, if we use 28814 28815 (presence_set "slot1" "slot0") 28816 28817 the following insn will be never issued (because 'slot1' requires 28818'slot0' which is absent in the source state). 28819 28820 (define_reservation "insn_and_nop" "slot0 + slot1") 28821 28822 but it can be issued if we use analogous 'final_presence_set'. 28823 28824 The forth construction ('absence_set') means that each functional unit 28825in the first string can be reserved only if each pattern of units whose 28826names are in the second string is not reserved. This is an asymmetric 28827relation (actually 'exclusion_set' is analogous to this one but it is 28828symmetric). For example it might be useful in a VLIW description to say 28829that 'slot0' cannot be reserved after either 'slot1' or 'slot2' have 28830been reserved. This can be described as: 28831 28832 (absence_set "slot0" "slot1, slot2") 28833 28834 Or 'slot2' can not be reserved if 'slot0' and unit 'b0' are reserved or 28835'slot1' and unit 'b1' are reserved. In this case we could write 28836 28837 (absence_set "slot2" "slot0 b0, slot1 b1") 28838 28839 All functional units mentioned in a set should belong to the same 28840automaton. 28841 28842 The last construction ('final_absence_set') is analogous to 28843'absence_set' but checking is done on the result (state) reservation. 28844See comments for 'final_presence_set'. 28845 28846 You can control the generator of the pipeline hazard recognizer with 28847the following construction. 28848 28849 (automata_option OPTIONS) 28850 28851 OPTIONS is a string giving options which affect the generated code. 28852Currently there are the following options: 28853 28854 * "no-minimization" makes no minimization of the automaton. This is 28855 only worth to do when we are debugging the description and need to 28856 look more accurately at reservations of states. 28857 28858 * "time" means printing time statistics about the generation of 28859 automata. 28860 28861 * "stats" means printing statistics about the generated automata such 28862 as the number of DFA states, NDFA states and arcs. 28863 28864 * "v" means a generation of the file describing the result automata. 28865 The file has suffix '.dfa' and can be used for the description 28866 verification and debugging. 28867 28868 * "w" means a generation of warning instead of error for non-critical 28869 errors. 28870 28871 * "no-comb-vect" prevents the automaton generator from generating two 28872 data structures and comparing them for space efficiency. Using a 28873 comb vector to represent transitions may be better, but it can be 28874 very expensive to construct. This option is useful if the build 28875 process spends an unacceptably long time in genautomata. 28876 28877 * "ndfa" makes nondeterministic finite state automata. This affects 28878 the treatment of operator '|' in the regular expressions. The 28879 usual treatment of the operator is to try the first alternative 28880 and, if the reservation is not possible, the second alternative. 28881 The nondeterministic treatment means trying all alternatives, some 28882 of them may be rejected by reservations in the subsequent insns. 28883 28884 * "collapse-ndfa" modifies the behavior of the generator when 28885 producing an automaton. An additional state transition to collapse 28886 a nondeterministic NDFA state to a deterministic DFA state is 28887 generated. It can be triggered by passing 'const0_rtx' to 28888 state_transition. In such an automaton, cycle advance transitions 28889 are available only for these collapsed states. This option is 28890 useful for ports that want to use the 'ndfa' option, but also want 28891 to use 'define_query_cpu_unit' to assign units to insns issued in a 28892 cycle. 28893 28894 * "progress" means output of a progress bar showing how many states 28895 were generated so far for automaton being processed. This is 28896 useful during debugging a DFA description. If you see too many 28897 generated states, you could interrupt the generator of the pipeline 28898 hazard recognizer and try to figure out a reason for generation of 28899 the huge automaton. 28900 28901 As an example, consider a superscalar RISC machine which can issue 28902three insns (two integer insns and one floating point insn) on the cycle 28903but can finish only two insns. To describe this, we define the 28904following functional units. 28905 28906 (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline") 28907 (define_cpu_unit "port0, port1") 28908 28909 All simple integer insns can be executed in any integer pipeline and 28910their result is ready in two cycles. The simple integer insns are 28911issued into the first pipeline unless it is reserved, otherwise they are 28912issued into the second pipeline. Integer division and multiplication 28913insns can be executed only in the second integer pipeline and their 28914results are ready correspondingly in 9 and 4 cycles. The integer 28915division is not pipelined, i.e. the subsequent integer division insn can 28916not be issued until the current division insn finished. Floating point 28917insns are fully pipelined and their results are ready in 3 cycles. 28918Where the result of a floating point insn is used by an integer insn, an 28919additional delay of one cycle is incurred. To describe all of this we 28920could specify 28921 28922 (define_cpu_unit "div") 28923 28924 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 28925 "(i0_pipeline | i1_pipeline), (port0 | port1)") 28926 28927 (define_insn_reservation "mult" 4 (eq_attr "type" "mult") 28928 "i1_pipeline, nothing*2, (port0 | port1)") 28929 28930 (define_insn_reservation "div" 9 (eq_attr "type" "div") 28931 "i1_pipeline, div*7, div + (port0 | port1)") 28932 28933 (define_insn_reservation "float" 3 (eq_attr "type" "float") 28934 "f_pipeline, nothing, (port0 | port1)) 28935 28936 (define_bypass 4 "float" "simple,mult,div") 28937 28938 To simplify the description we could describe the following reservation 28939 28940 (define_reservation "finish" "port0|port1") 28941 28942 and use it in all 'define_insn_reservation' as in the following 28943construction 28944 28945 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 28946 "(i0_pipeline | i1_pipeline), finish") 28947 28948 ---------- Footnotes ---------- 28949 28950 (1) However, the size of the automaton depends on processor 28951complexity. To limit this effect, machine descriptions can split 28952orthogonal parts of the machine description among several automata: but 28953then, since each of these must be stepped independently, this does cause 28954a small decrease in the algorithm's performance. 28955 28956 28957File: gccint.info, Node: Conditional Execution, Next: Define Subst, Prev: Insn Attributes, Up: Machine Desc 28958 2895917.20 Conditional Execution 28960=========================== 28961 28962A number of architectures provide for some form of conditional 28963execution, or predication. The hallmark of this feature is the ability 28964to nullify most of the instructions in the instruction set. When the 28965instruction set is large and not entirely symmetric, it can be quite 28966tedious to describe these forms directly in the '.md' file. An 28967alternative is the 'define_cond_exec' template. 28968 28969 (define_cond_exec 28970 [PREDICATE-PATTERN] 28971 "CONDITION" 28972 "OUTPUT-TEMPLATE" 28973 "OPTIONAL-INSN-ATTRIBUES") 28974 28975 PREDICATE-PATTERN is the condition that must be true for the insn to be 28976executed at runtime and should match a relational operator. One can use 28977'match_operator' to match several relational operators at once. Any 28978'match_operand' operands must have no more than one alternative. 28979 28980 CONDITION is a C expression that must be true for the generated pattern 28981to match. 28982 28983 OUTPUT-TEMPLATE is a string similar to the 'define_insn' output 28984template (*note Output Template::), except that the '*' and '@' special 28985cases do not apply. This is only useful if the assembly text for the 28986predicate is a simple prefix to the main insn. In order to handle the 28987general case, there is a global variable 'current_insn_predicate' that 28988will contain the entire predicate if the current insn is predicated, and 28989will otherwise be 'NULL'. 28990 28991 OPTIONAL-INSN-ATTRIBUTES is an optional vector of attributes that gets 28992appended to the insn attributes of the produced cond_exec rtx. It can 28993be used to add some distinguishing attribute to cond_exec rtxs produced 28994that way. An example usage would be to use this attribute in 28995conjunction with attributes on the main pattern to disable particular 28996alternatives under certain conditions. 28997 28998 When 'define_cond_exec' is used, an implicit reference to the 28999'predicable' instruction attribute is made. *Note Insn Attributes::. 29000This attribute must be a boolean (i.e. have exactly two elements in its 29001LIST-OF-VALUES), with the possible values being 'no' and 'yes'. The 29002default and all uses in the insns must be a simple constant, not a 29003complex expressions. It may, however, depend on the alternative, by 29004using a comma-separated list of values. If that is the case, the port 29005should also define an 'enabled' attribute (*note Disable Insn 29006Alternatives::), which should also allow only 'no' and 'yes' as its 29007values. 29008 29009 For each 'define_insn' for which the 'predicable' attribute is true, a 29010new 'define_insn' pattern will be generated that matches a predicated 29011version of the instruction. For example, 29012 29013 (define_insn "addsi" 29014 [(set (match_operand:SI 0 "register_operand" "r") 29015 (plus:SI (match_operand:SI 1 "register_operand" "r") 29016 (match_operand:SI 2 "register_operand" "r")))] 29017 "TEST1" 29018 "add %2,%1,%0") 29019 29020 (define_cond_exec 29021 [(ne (match_operand:CC 0 "register_operand" "c") 29022 (const_int 0))] 29023 "TEST2" 29024 "(%0)") 29025 29026generates a new pattern 29027 29028 (define_insn "" 29029 [(cond_exec 29030 (ne (match_operand:CC 3 "register_operand" "c") (const_int 0)) 29031 (set (match_operand:SI 0 "register_operand" "r") 29032 (plus:SI (match_operand:SI 1 "register_operand" "r") 29033 (match_operand:SI 2 "register_operand" "r"))))] 29034 "(TEST2) && (TEST1)" 29035 "(%3) add %2,%1,%0") 29036 29037 29038File: gccint.info, Node: Define Subst, Next: Constant Definitions, Prev: Conditional Execution, Up: Machine Desc 29039 2904017.21 RTL Templates Transformations 29041=================================== 29042 29043For some hardware architectures there are common cases when the RTL 29044templates for the instructions can be derived from the other RTL 29045templates using simple transformations. E.g., 'i386.md' contains an RTL 29046template for the ordinary 'sub' instruction-- '*subsi_1', and for the 29047'sub' instruction with subsequent zero-extension--'*subsi_1_zext'. Such 29048cases can be easily implemented by a single meta-template capable of 29049generating a modified case based on the initial one: 29050 29051 (define_subst "NAME" 29052 [INPUT-TEMPLATE] 29053 "CONDITION" 29054 [OUTPUT-TEMPLATE]) 29055 INPUT-TEMPLATE is a pattern describing the source RTL template, which 29056will be transformed. 29057 29058 CONDITION is a C expression that is conjunct with the condition from 29059the input-template to generate a condition to be used in the 29060output-template. 29061 29062 OUTPUT-TEMPLATE is a pattern that will be used in the resulting 29063template. 29064 29065 'define_subst' mechanism is tightly coupled with the notion of the 29066subst attribute (*note Subst Iterators::). The use of 'define_subst' is 29067triggered by a reference to a subst attribute in the transforming RTL 29068template. This reference initiates duplication of the source RTL 29069template and substitution of the attributes with their values. The 29070source RTL template is left unchanged, while the copy is transformed by 29071'define_subst'. This transformation can fail in the case when the 29072source RTL template is not matched against the input-template of the 29073'define_subst'. In such case the copy is deleted. 29074 29075 'define_subst' can be used only in 'define_insn' and 'define_expand', 29076it cannot be used in other expressions (e.g. in 29077'define_insn_and_split'). 29078 29079* Menu: 29080 29081* Define Subst Example:: Example of 'define_subst' work. 29082* Define Subst Pattern Matching:: Process of template comparison. 29083* Define Subst Output Template:: Generation of output template. 29084 29085 29086File: gccint.info, Node: Define Subst Example, Next: Define Subst Pattern Matching, Up: Define Subst 29087 2908817.21.1 'define_subst' Example 29089------------------------------ 29090 29091To illustrate how 'define_subst' works, let us examine a simple template 29092transformation. 29093 29094 Suppose there are two kinds of instructions: one that touches flags and 29095the other that does not. The instructions of the second type could be 29096generated with the following 'define_subst': 29097 29098 (define_subst "add_clobber_subst" 29099 [(set (match_operand:SI 0 "" "") 29100 (match_operand:SI 1 "" ""))] 29101 "" 29102 [(set (match_dup 0) 29103 (match_dup 1)) 29104 (clobber (reg:CC FLAGS_REG))] 29105 29106 This 'define_subst' can be applied to any RTL pattern containing 'set' 29107of mode SI and generates a copy with clobber when it is applied. 29108 29109 Assume there is an RTL template for a 'max' instruction to be used in 29110'define_subst' mentioned above: 29111 29112 (define_insn "maxsi" 29113 [(set (match_operand:SI 0 "register_operand" "=r") 29114 (max:SI 29115 (match_operand:SI 1 "register_operand" "r") 29116 (match_operand:SI 2 "register_operand" "r")))] 29117 "" 29118 "max\t{%2, %1, %0|%0, %1, %2}" 29119 [...]) 29120 29121 To mark the RTL template for 'define_subst' application, 29122subst-attributes are used. They should be declared in advance: 29123 29124 (define_subst_attr "add_clobber_name" "add_clobber_subst" "_noclobber" "_clobber") 29125 29126 Here 'add_clobber_name' is the attribute name, 'add_clobber_subst' is 29127the name of the corresponding 'define_subst', the third argument 29128('_noclobber') is the attribute value that would be substituted into the 29129unchanged version of the source RTL template, and the last argument 29130('_clobber') is the value that would be substituted into the second, 29131transformed, version of the RTL template. 29132 29133 Once the subst-attribute has been defined, it should be used in RTL 29134templates which need to be processed by the 'define_subst'. So, the 29135original RTL template should be changed: 29136 29137 (define_insn "maxsi<add_clobber_name>" 29138 [(set (match_operand:SI 0 "register_operand" "=r") 29139 (max:SI 29140 (match_operand:SI 1 "register_operand" "r") 29141 (match_operand:SI 2 "register_operand" "r")))] 29142 "" 29143 "max\t{%2, %1, %0|%0, %1, %2}" 29144 [...]) 29145 29146 The result of the 'define_subst' usage would look like the following: 29147 29148 (define_insn "maxsi_noclobber" 29149 [(set (match_operand:SI 0 "register_operand" "=r") 29150 (max:SI 29151 (match_operand:SI 1 "register_operand" "r") 29152 (match_operand:SI 2 "register_operand" "r")))] 29153 "" 29154 "max\t{%2, %1, %0|%0, %1, %2}" 29155 [...]) 29156 (define_insn "maxsi_clobber" 29157 [(set (match_operand:SI 0 "register_operand" "=r") 29158 (max:SI 29159 (match_operand:SI 1 "register_operand" "r") 29160 (match_operand:SI 2 "register_operand" "r"))) 29161 (clobber (reg:CC FLAGS_REG))] 29162 "" 29163 "max\t{%2, %1, %0|%0, %1, %2}" 29164 [...]) 29165 29166 29167File: gccint.info, Node: Define Subst Pattern Matching, Next: Define Subst Output Template, Prev: Define Subst Example, Up: Define Subst 29168 2916917.21.2 Pattern Matching in 'define_subst' 29170------------------------------------------ 29171 29172All expressions, allowed in 'define_insn' or 'define_expand', are 29173allowed in the input-template of 'define_subst', except 'match_par_dup', 29174'match_scratch', 'match_parallel'. The meanings of expressions in the 29175input-template were changed: 29176 29177 'match_operand' matches any expression (possibly, a subtree in 29178RTL-template), if modes of the 'match_operand' and this expression are 29179the same, or mode of the 'match_operand' is 'VOIDmode', or this 29180expression is 'match_dup', 'match_op_dup'. If the expression is 29181'match_operand' too, and predicate of 'match_operand' from the input 29182pattern is not empty, then the predicates are compared. That can be 29183used for more accurate filtering of accepted RTL-templates. 29184 29185 'match_operator' matches common operators (like 'plus', 'minus'), 29186'unspec', 'unspec_volatile' operators and 'match_operator's from the 29187original pattern if the modes match and 'match_operator' from the input 29188pattern has the same number of operands as the operator from the 29189original pattern. 29190 29191 29192File: gccint.info, Node: Define Subst Output Template, Prev: Define Subst Pattern Matching, Up: Define Subst 29193 2919417.21.3 Generation of output template in 'define_subst' 29195------------------------------------------------------- 29196 29197If all necessary checks for 'define_subst' application pass, a new 29198RTL-pattern, based on the output-template, is created to replace the old 29199template. Like in input-patterns, meanings of some RTL expressions are 29200changed when they are used in output-patterns of a 'define_subst'. 29201Thus, 'match_dup' is used for copying the whole expression from the 29202original pattern, which matched corresponding 'match_operand' from the 29203input pattern. 29204 29205 'match_dup N' is used in the output template to be replaced with the 29206expression from the original pattern, which matched 'match_operand N' 29207from the input pattern. As a consequence, 'match_dup' cannot be used to 29208point to 'match_operand's from the output pattern, it should always 29209refer to a 'match_operand' from the input pattern. 29210 29211 In the output template one can refer to the expressions from the 29212original pattern and create new ones. For instance, some operands could 29213be added by means of standard 'match_operand'. 29214 29215 After replacing 'match_dup' with some RTL-subtree from the original 29216pattern, it could happen that several 'match_operand's in the output 29217pattern have the same indexes. It is unknown, how many and what indexes 29218would be used in the expression which would replace 'match_dup', so such 29219conflicts in indexes are inevitable. To overcome this issue, 29220'match_operands' and 'match_operators', which were introduced into the 29221output pattern, are renumerated when all 'match_dup's are replaced. 29222 29223 Number of alternatives in 'match_operand's introduced into the output 29224template 'M' could differ from the number of alternatives in the 29225original pattern 'N', so in the resultant pattern there would be 'N*M' 29226alternatives. Thus, constraints from the original pattern would be 29227duplicated 'N' times, constraints from the output pattern would be 29228duplicated 'M' times, producing all possible combinations. 29229 29230 29231File: gccint.info, Node: Constant Definitions, Next: Iterators, Prev: Define Subst, Up: Machine Desc 29232 2923317.22 Constant Definitions 29234========================== 29235 29236Using literal constants inside instruction patterns reduces legibility 29237and can be a maintenance problem. 29238 29239 To overcome this problem, you may use the 'define_constants' 29240expression. It contains a vector of name-value pairs. From that point 29241on, wherever any of the names appears in the MD file, it is as if the 29242corresponding value had been written instead. You may use 29243'define_constants' multiple times; each appearance adds more constants 29244to the table. It is an error to redefine a constant with a different 29245value. 29246 29247 To come back to the a29k load multiple example, instead of 29248 29249 (define_insn "" 29250 [(match_parallel 0 "load_multiple_operation" 29251 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 29252 (match_operand:SI 2 "memory_operand" "m")) 29253 (use (reg:SI 179)) 29254 (clobber (reg:SI 179))])] 29255 "" 29256 "loadm 0,0,%1,%2") 29257 29258 You could write: 29259 29260 (define_constants [ 29261 (R_BP 177) 29262 (R_FC 178) 29263 (R_CR 179) 29264 (R_Q 180) 29265 ]) 29266 29267 (define_insn "" 29268 [(match_parallel 0 "load_multiple_operation" 29269 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 29270 (match_operand:SI 2 "memory_operand" "m")) 29271 (use (reg:SI R_CR)) 29272 (clobber (reg:SI R_CR))])] 29273 "" 29274 "loadm 0,0,%1,%2") 29275 29276 The constants that are defined with a define_constant are also output 29277in the insn-codes.h header file as #defines. 29278 29279 You can also use the machine description file to define enumerations. 29280Like the constants defined by 'define_constant', these enumerations are 29281visible to both the machine description file and the main C code. 29282 29283 The syntax is as follows: 29284 29285 (define_c_enum "NAME" [ 29286 VALUE0 29287 VALUE1 29288 ... 29289 VALUEN 29290 ]) 29291 29292 This definition causes the equivalent of the following C code to appear 29293in 'insn-constants.h': 29294 29295 enum NAME { 29296 VALUE0 = 0, 29297 VALUE1 = 1, 29298 ... 29299 VALUEN = N 29300 }; 29301 #define NUM_CNAME_VALUES (N + 1) 29302 29303 where CNAME is the capitalized form of NAME. It also makes each VALUEI 29304available in the machine description file, just as if it had been 29305declared with: 29306 29307 (define_constants [(VALUEI I)]) 29308 29309 Each VALUEI is usually an upper-case identifier and usually begins with 29310CNAME. 29311 29312 You can split the enumeration definition into as many statements as you 29313like. The above example is directly equivalent to: 29314 29315 (define_c_enum "NAME" [VALUE0]) 29316 (define_c_enum "NAME" [VALUE1]) 29317 ... 29318 (define_c_enum "NAME" [VALUEN]) 29319 29320 Splitting the enumeration helps to improve the modularity of each 29321individual '.md' file. For example, if a port defines its 29322synchronization instructions in a separate 'sync.md' file, it is 29323convenient to define all synchronization-specific enumeration values in 29324'sync.md' rather than in the main '.md' file. 29325 29326 Some enumeration names have special significance to GCC: 29327 29328'unspecv' 29329 If an enumeration called 'unspecv' is defined, GCC will use it when 29330 printing out 'unspec_volatile' expressions. For example: 29331 29332 (define_c_enum "unspecv" [ 29333 UNSPECV_BLOCKAGE 29334 ]) 29335 29336 causes GCC to print '(unspec_volatile ... 0)' as: 29337 29338 (unspec_volatile ... UNSPECV_BLOCKAGE) 29339 29340'unspec' 29341 If an enumeration called 'unspec' is defined, GCC will use it when 29342 printing out 'unspec' expressions. GCC will also use it when 29343 printing out 'unspec_volatile' expressions unless an 'unspecv' 29344 enumeration is also defined. You can therefore decide whether to 29345 keep separate enumerations for volatile and non-volatile 29346 expressions or whether to use the same enumeration for both. 29347 29348 Another way of defining an enumeration is to use 'define_enum': 29349 29350 (define_enum "NAME" [ 29351 VALUE0 29352 VALUE1 29353 ... 29354 VALUEN 29355 ]) 29356 29357 This directive implies: 29358 29359 (define_c_enum "NAME" [ 29360 CNAME_CVALUE0 29361 CNAME_CVALUE1 29362 ... 29363 CNAME_CVALUEN 29364 ]) 29365 29366 where CVALUEI is the capitalized form of VALUEI. However, unlike 29367'define_c_enum', the enumerations defined by 'define_enum' can be used 29368in attribute specifications (*note define_enum_attr::). 29369 29370 29371File: gccint.info, Node: Iterators, Prev: Constant Definitions, Up: Machine Desc 29372 2937317.23 Iterators 29374=============== 29375 29376Ports often need to define similar patterns for more than one machine 29377mode or for more than one rtx code. GCC provides some simple iterator 29378facilities to make this process easier. 29379 29380* Menu: 29381 29382* Mode Iterators:: Generating variations of patterns for different modes. 29383* Code Iterators:: Doing the same for codes. 29384* Int Iterators:: Doing the same for integers. 29385* Subst Iterators:: Generating variations of patterns for define_subst. 29386 29387 29388File: gccint.info, Node: Mode Iterators, Next: Code Iterators, Up: Iterators 29389 2939017.23.1 Mode Iterators 29391---------------------- 29392 29393Ports often need to define similar patterns for two or more different 29394modes. For example: 29395 29396 * If a processor has hardware support for both single and double 29397 floating-point arithmetic, the 'SFmode' patterns tend to be very 29398 similar to the 'DFmode' ones. 29399 29400 * If a port uses 'SImode' pointers in one configuration and 'DImode' 29401 pointers in another, it will usually have very similar 'SImode' and 29402 'DImode' patterns for manipulating pointers. 29403 29404 Mode iterators allow several patterns to be instantiated from one '.md' 29405file template. They can be used with any type of rtx-based construct, 29406such as a 'define_insn', 'define_split', or 'define_peephole2'. 29407 29408* Menu: 29409 29410* Defining Mode Iterators:: Defining a new mode iterator. 29411* Substitutions:: Combining mode iterators with substitutions 29412* Examples:: Examples 29413 29414 29415File: gccint.info, Node: Defining Mode Iterators, Next: Substitutions, Up: Mode Iterators 29416 2941717.23.1.1 Defining Mode Iterators 29418................................. 29419 29420The syntax for defining a mode iterator is: 29421 29422 (define_mode_iterator NAME [(MODE1 "COND1") ... (MODEN "CONDN")]) 29423 29424 This allows subsequent '.md' file constructs to use the mode suffix 29425':NAME'. Every construct that does so will be expanded N times, once 29426with every use of ':NAME' replaced by ':MODE1', once with every use 29427replaced by ':MODE2', and so on. In the expansion for a particular 29428MODEI, every C condition will also require that CONDI be true. 29429 29430 For example: 29431 29432 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 29433 29434 defines a new mode suffix ':P'. Every construct that uses ':P' will be 29435expanded twice, once with every ':P' replaced by ':SI' and once with 29436every ':P' replaced by ':DI'. The ':SI' version will only apply if 29437'Pmode == SImode' and the ':DI' version will only apply if 'Pmode == 29438DImode'. 29439 29440 As with other '.md' conditions, an empty string is treated as "always 29441true". '(MODE "")' can also be abbreviated to 'MODE'. For example: 29442 29443 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 29444 29445 means that the ':DI' expansion only applies if 'TARGET_64BIT' but that 29446the ':SI' expansion has no such constraint. 29447 29448 Iterators are applied in the order they are defined. This can be 29449significant if two iterators are used in a construct that requires 29450substitutions. *Note Substitutions::. 29451 29452 29453File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Iterators, Up: Mode Iterators 29454 2945517.23.1.2 Substitution in Mode Iterators 29456........................................ 29457 29458If an '.md' file construct uses mode iterators, each version of the 29459construct will often need slightly different strings or modes. For 29460example: 29461 29462 * When a 'define_expand' defines several 'addM3' patterns (*note 29463 Standard Names::), each expander will need to use the appropriate 29464 mode name for M. 29465 29466 * When a 'define_insn' defines several instruction patterns, each 29467 instruction will often use a different assembler mnemonic. 29468 29469 * When a 'define_insn' requires operands with different modes, using 29470 an iterator for one of the operand modes usually requires a 29471 specific mode for the other operand(s). 29472 29473 GCC supports such variations through a system of "mode attributes". 29474There are two standard attributes: 'mode', which is the name of the mode 29475in lower case, and 'MODE', which is the same thing in upper case. You 29476can define other attributes using: 29477 29478 (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")]) 29479 29480 where NAME is the name of the attribute and VALUEI is the value 29481associated with MODEI. 29482 29483 When GCC replaces some :ITERATOR with :MODE, it will scan each string 29484and mode in the pattern for sequences of the form '<ITERATOR:ATTR>', 29485where ATTR is the name of a mode attribute. If the attribute is defined 29486for MODE, the whole '<...>' sequence will be replaced by the appropriate 29487attribute value. 29488 29489 For example, suppose an '.md' file has: 29490 29491 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 29492 (define_mode_attr load [(SI "lw") (DI "ld")]) 29493 29494 If one of the patterns that uses ':P' contains the string 29495'"<P:load>\t%0,%1"', the 'SI' version of that pattern will use 29496'"lw\t%0,%1"' and the 'DI' version will use '"ld\t%0,%1"'. 29497 29498 Here is an example of using an attribute for a mode: 29499 29500 (define_mode_iterator LONG [SI DI]) 29501 (define_mode_attr SHORT [(SI "HI") (DI "SI")]) 29502 (define_insn ... 29503 (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...) 29504 29505 The 'ITERATOR:' prefix may be omitted, in which case the substitution 29506will be attempted for every iterator expansion. 29507 29508 29509File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Iterators 29510 2951117.23.1.3 Mode Iterator Examples 29512................................ 29513 29514Here is an example from the MIPS port. It defines the following modes 29515and attributes (among others): 29516 29517 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 29518 (define_mode_attr d [(SI "") (DI "d")]) 29519 29520 and uses the following template to define both 'subsi3' and 'subdi3': 29521 29522 (define_insn "sub<mode>3" 29523 [(set (match_operand:GPR 0 "register_operand" "=d") 29524 (minus:GPR (match_operand:GPR 1 "register_operand" "d") 29525 (match_operand:GPR 2 "register_operand" "d")))] 29526 "" 29527 "<d>subu\t%0,%1,%2" 29528 [(set_attr "type" "arith") 29529 (set_attr "mode" "<MODE>")]) 29530 29531 This is exactly equivalent to: 29532 29533 (define_insn "subsi3" 29534 [(set (match_operand:SI 0 "register_operand" "=d") 29535 (minus:SI (match_operand:SI 1 "register_operand" "d") 29536 (match_operand:SI 2 "register_operand" "d")))] 29537 "" 29538 "subu\t%0,%1,%2" 29539 [(set_attr "type" "arith") 29540 (set_attr "mode" "SI")]) 29541 29542 (define_insn "subdi3" 29543 [(set (match_operand:DI 0 "register_operand" "=d") 29544 (minus:DI (match_operand:DI 1 "register_operand" "d") 29545 (match_operand:DI 2 "register_operand" "d")))] 29546 "" 29547 "dsubu\t%0,%1,%2" 29548 [(set_attr "type" "arith") 29549 (set_attr "mode" "DI")]) 29550 29551 29552File: gccint.info, Node: Code Iterators, Next: Int Iterators, Prev: Mode Iterators, Up: Iterators 29553 2955417.23.2 Code Iterators 29555---------------------- 29556 29557Code iterators operate in a similar way to mode iterators. *Note Mode 29558Iterators::. 29559 29560 The construct: 29561 29562 (define_code_iterator NAME [(CODE1 "COND1") ... (CODEN "CONDN")]) 29563 29564 defines a pseudo rtx code NAME that can be instantiated as CODEI if 29565condition CONDI is true. Each CODEI must have the same rtx format. 29566*Note RTL Classes::. 29567 29568 As with mode iterators, each pattern that uses NAME will be expanded N 29569times, once with all uses of NAME replaced by CODE1, once with all uses 29570replaced by CODE2, and so on. *Note Defining Mode Iterators::. 29571 29572 It is possible to define attributes for codes as well as for modes. 29573There are two standard code attributes: 'code', the name of the code in 29574lower case, and 'CODE', the name of the code in upper case. Other 29575attributes are defined using: 29576 29577 (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")]) 29578 29579 Here's an example of code iterators in action, taken from the MIPS 29580port: 29581 29582 (define_code_iterator any_cond [unordered ordered unlt unge uneq ltgt unle ungt 29583 eq ne gt ge lt le gtu geu ltu leu]) 29584 29585 (define_expand "b<code>" 29586 [(set (pc) 29587 (if_then_else (any_cond:CC (cc0) 29588 (const_int 0)) 29589 (label_ref (match_operand 0 "")) 29590 (pc)))] 29591 "" 29592 { 29593 gen_conditional_branch (operands, <CODE>); 29594 DONE; 29595 }) 29596 29597 This is equivalent to: 29598 29599 (define_expand "bunordered" 29600 [(set (pc) 29601 (if_then_else (unordered:CC (cc0) 29602 (const_int 0)) 29603 (label_ref (match_operand 0 "")) 29604 (pc)))] 29605 "" 29606 { 29607 gen_conditional_branch (operands, UNORDERED); 29608 DONE; 29609 }) 29610 29611 (define_expand "bordered" 29612 [(set (pc) 29613 (if_then_else (ordered:CC (cc0) 29614 (const_int 0)) 29615 (label_ref (match_operand 0 "")) 29616 (pc)))] 29617 "" 29618 { 29619 gen_conditional_branch (operands, ORDERED); 29620 DONE; 29621 }) 29622 29623 ... 29624 29625 29626File: gccint.info, Node: Int Iterators, Next: Subst Iterators, Prev: Code Iterators, Up: Iterators 29627 2962817.23.3 Int Iterators 29629--------------------- 29630 29631Int iterators operate in a similar way to code iterators. *Note Code 29632Iterators::. 29633 29634 The construct: 29635 29636 (define_int_iterator NAME [(INT1 "COND1") ... (INTN "CONDN")]) 29637 29638 defines a pseudo integer constant NAME that can be instantiated as INTI 29639if condition CONDI is true. Each INT must have the same rtx format. 29640*Note RTL Classes::. Int iterators can appear in only those rtx fields 29641that have 'i' as the specifier. This means that each INT has to be a 29642constant defined using define_constant or define_c_enum. 29643 29644 As with mode and code iterators, each pattern that uses NAME will be 29645expanded N times, once with all uses of NAME replaced by INT1, once with 29646all uses replaced by INT2, and so on. *Note Defining Mode Iterators::. 29647 29648 It is possible to define attributes for ints as well as for codes and 29649modes. Attributes are defined using: 29650 29651 (define_int_attr NAME [(INT1 "VALUE1") ... (INTN "VALUEN")]) 29652 29653 Here's an example of int iterators in action, taken from the ARM port: 29654 29655 (define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG]) 29656 29657 (define_int_attr absneg [(UNSPEC_VQABS "abs") (UNSPEC_VQNEG "neg")]) 29658 29659 (define_insn "neon_vq<absneg><mode>" 29660 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 29661 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 29662 (match_operand:SI 2 "immediate_operand" "i")] 29663 QABSNEG))] 29664 "TARGET_NEON" 29665 "vq<absneg>.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 29666 [(set_attr "type" "neon_vqneg_vqabs")] 29667 ) 29668 29669 29670 This is equivalent to: 29671 29672 (define_insn "neon_vqabs<mode>" 29673 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 29674 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 29675 (match_operand:SI 2 "immediate_operand" "i")] 29676 UNSPEC_VQABS))] 29677 "TARGET_NEON" 29678 "vqabs.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 29679 [(set_attr "type" "neon_vqneg_vqabs")] 29680 ) 29681 29682 (define_insn "neon_vqneg<mode>" 29683 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 29684 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 29685 (match_operand:SI 2 "immediate_operand" "i")] 29686 UNSPEC_VQNEG))] 29687 "TARGET_NEON" 29688 "vqneg.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 29689 [(set_attr "type" "neon_vqneg_vqabs")] 29690 ) 29691 29692 29693 29694File: gccint.info, Node: Subst Iterators, Prev: Int Iterators, Up: Iterators 29695 2969617.23.4 Subst Iterators 29697----------------------- 29698 29699Subst iterators are special type of iterators with the following 29700restrictions: they could not be declared explicitly, they always have 29701only two values, and they do not have explicit dedicated name. 29702Subst-iterators are triggered only when corresponding subst-attribute is 29703used in RTL-pattern. 29704 29705 Subst iterators transform templates in the following way: the templates 29706are duplicated, the subst-attributes in these templates are replaced 29707with the corresponding values, and a new attribute is implicitly added 29708to the given 'define_insn'/'define_expand'. The name of the added 29709attribute matches the name of 'define_subst'. Such attributes are 29710declared implicitly, and it is not allowed to have a 'define_attr' named 29711as a 'define_subst'. 29712 29713 Each subst iterator is linked to a 'define_subst'. It is declared 29714implicitly by the first appearance of the corresponding 29715'define_subst_attr', and it is not allowed to define it explicitly. 29716 29717 Declarations of subst-attributes have the following syntax: 29718 29719 (define_subst_attr "NAME" 29720 "SUBST-NAME" 29721 "NO-SUBST-VALUE" 29722 "SUBST-APPLIED-VALUE") 29723 29724 NAME is a string with which the given subst-attribute could be referred 29725to. 29726 29727 SUBST-NAME shows which 'define_subst' should be applied to an 29728RTL-template if the given subst-attribute is present in the 29729RTL-template. 29730 29731 NO-SUBST-VALUE is a value with which subst-attribute would be replaced 29732in the first copy of the original RTL-template. 29733 29734 SUBST-APPLIED-VALUE is a value with which subst-attribute would be 29735replaced in the second copy of the original RTL-template. 29736 29737 29738File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top 29739 2974018 Target Description Macros and Functions 29741****************************************** 29742 29743In addition to the file 'MACHINE.md', a machine description includes a C 29744header file conventionally given the name 'MACHINE.h' and a C source 29745file named 'MACHINE.c'. The header file defines numerous macros that 29746convey the information about the target machine that does not fit into 29747the scheme of the '.md' file. The file 'tm.h' should be a link to 29748'MACHINE.h'. The header file 'config.h' includes 'tm.h' and most 29749compiler source files include 'config.h'. The source file defines a 29750variable 'targetm', which is a structure containing pointers to 29751functions and data relating to the target machine. 'MACHINE.c' should 29752also contain their definitions, if they are not defined elsewhere in 29753GCC, and other functions called through the macros defined in the '.h' 29754file. 29755 29756* Menu: 29757 29758* Target Structure:: The 'targetm' variable. 29759* Driver:: Controlling how the driver runs the compilation passes. 29760* Run-time Target:: Defining '-m' options like '-m68000' and '-m68020'. 29761* Per-Function Data:: Defining data structures for per-function information. 29762* Storage Layout:: Defining sizes and alignments of data. 29763* Type Layout:: Defining sizes and properties of basic user data types. 29764* Registers:: Naming and describing the hardware registers. 29765* Register Classes:: Defining the classes of hardware registers. 29766* Stack and Calling:: Defining which way the stack grows and by how much. 29767* Varargs:: Defining the varargs macros. 29768* Trampolines:: Code set up at run time to enter a nested function. 29769* Library Calls:: Controlling how library routines are implicitly called. 29770* Addressing Modes:: Defining addressing modes valid for memory operands. 29771* Anchored Addresses:: Defining how '-fsection-anchors' should work. 29772* Condition Code:: Defining how insns update the condition code. 29773* Costs:: Defining relative costs of different operations. 29774* Scheduling:: Adjusting the behavior of the instruction scheduler. 29775* Sections:: Dividing storage into text, data, and other sections. 29776* PIC:: Macros for position independent code. 29777* Assembler Format:: Defining how to write insns and pseudo-ops to output. 29778* Debugging Info:: Defining the format of debugging output. 29779* Floating Point:: Handling floating point for cross-compilers. 29780* Mode Switching:: Insertion of mode-switching instructions. 29781* Target Attributes:: Defining target-specific uses of '__attribute__'. 29782* Emulated TLS:: Emulated TLS support. 29783* MIPS Coprocessors:: MIPS coprocessor support and how to customize it. 29784* PCH Target:: Validity checking for precompiled headers. 29785* C++ ABI:: Controlling C++ ABI changes. 29786* Named Address Spaces:: Adding support for named address spaces 29787* Misc:: Everything else. 29788 29789 29790File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros 29791 2979218.1 The Global 'targetm' Variable 29793================================== 29794 29795 -- Variable: struct gcc_target targetm 29796 The target '.c' file must define the global 'targetm' variable 29797 which contains pointers to functions and data relating to the 29798 target machine. The variable is declared in 'target.h'; 29799 'target-def.h' defines the macro 'TARGET_INITIALIZER' which is used 29800 to initialize the variable, and macros for the default initializers 29801 for elements of the structure. The '.c' file should override those 29802 macros for which the default definition is inappropriate. For 29803 example: 29804 #include "target.h" 29805 #include "target-def.h" 29806 29807 /* Initialize the GCC target structure. */ 29808 29809 #undef TARGET_COMP_TYPE_ATTRIBUTES 29810 #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes 29811 29812 struct gcc_target targetm = TARGET_INITIALIZER; 29813 29814 Where a macro should be defined in the '.c' file in this manner to form 29815part of the 'targetm' structure, it is documented below as a "Target 29816Hook" with a prototype. Many macros will change in future from being 29817defined in the '.h' file to being part of the 'targetm' structure. 29818 29819 Similarly, there is a 'targetcm' variable for hooks that are specific 29820to front ends for C-family languages, documented as "C Target Hook". 29821This is declared in 'c-family/c-target.h', the initializer 29822'TARGETCM_INITIALIZER' in 'c-family/c-target-def.h'. If targets 29823initialize 'targetcm' themselves, they should set 29824'target_has_targetcm=yes' in 'config.gcc'; otherwise a default 29825definition is used. 29826 29827 Similarly, there is a 'targetm_common' variable for hooks that are 29828shared between the compiler driver and the compilers proper, documented 29829as "Common Target Hook". This is declared in 'common/common-target.h', 29830the initializer 'TARGETM_COMMON_INITIALIZER' in 29831'common/common-target-def.h'. If targets initialize 'targetm_common' 29832themselves, they should set 'target_has_targetm_common=yes' in 29833'config.gcc'; otherwise a default definition is used. 29834 29835 29836File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros 29837 2983818.2 Controlling the Compilation Driver, 'gcc' 29839============================================== 29840 29841You can control the compilation driver. 29842 29843 -- Macro: DRIVER_SELF_SPECS 29844 A list of specs for the driver itself. It should be a suitable 29845 initializer for an array of strings, with no surrounding braces. 29846 29847 The driver applies these specs to its own command line between 29848 loading default 'specs' files (but not command-line specified ones) 29849 and choosing the multilib directory or running any subcommands. It 29850 applies them in the order given, so each spec can depend on the 29851 options added by earlier ones. It is also possible to remove 29852 options using '%<OPTION' in the usual way. 29853 29854 This macro can be useful when a port has several interdependent 29855 target options. It provides a way of standardizing the command 29856 line so that the other specs are easier to write. 29857 29858 Do not define this macro if it does not need to do anything. 29859 29860 -- Macro: OPTION_DEFAULT_SPECS 29861 A list of specs used to support configure-time default options 29862 (i.e. '--with' options) in the driver. It should be a suitable 29863 initializer for an array of structures, each containing two 29864 strings, without the outermost pair of surrounding braces. 29865 29866 The first item in the pair is the name of the default. This must 29867 match the code in 'config.gcc' for the target. The second item is 29868 a spec to apply if a default with this name was specified. The 29869 string '%(VALUE)' in the spec will be replaced by the value of the 29870 default everywhere it occurs. 29871 29872 The driver will apply these specs to its own command line between 29873 loading default 'specs' files and processing 'DRIVER_SELF_SPECS', 29874 using the same mechanism as 'DRIVER_SELF_SPECS'. 29875 29876 Do not define this macro if it does not need to do anything. 29877 29878 -- Macro: CPP_SPEC 29879 A C string constant that tells the GCC driver program options to 29880 pass to CPP. It can also specify how to translate options you give 29881 to GCC into options for GCC to pass to the CPP. 29882 29883 Do not define this macro if it does not need to do anything. 29884 29885 -- Macro: CPLUSPLUS_CPP_SPEC 29886 This macro is just like 'CPP_SPEC', but is used for C++, rather 29887 than C. If you do not define this macro, then the value of 29888 'CPP_SPEC' (if any) will be used instead. 29889 29890 -- Macro: CC1_SPEC 29891 A C string constant that tells the GCC driver program options to 29892 pass to 'cc1', 'cc1plus', 'f771', and the other language front 29893 ends. It can also specify how to translate options you give to GCC 29894 into options for GCC to pass to front ends. 29895 29896 Do not define this macro if it does not need to do anything. 29897 29898 -- Macro: CC1PLUS_SPEC 29899 A C string constant that tells the GCC driver program options to 29900 pass to 'cc1plus'. It can also specify how to translate options 29901 you give to GCC into options for GCC to pass to the 'cc1plus'. 29902 29903 Do not define this macro if it does not need to do anything. Note 29904 that everything defined in CC1_SPEC is already passed to 'cc1plus' 29905 so there is no need to duplicate the contents of CC1_SPEC in 29906 CC1PLUS_SPEC. 29907 29908 -- Macro: ASM_SPEC 29909 A C string constant that tells the GCC driver program options to 29910 pass to the assembler. It can also specify how to translate 29911 options you give to GCC into options for GCC to pass to the 29912 assembler. See the file 'sun3.h' for an example of this. 29913 29914 Do not define this macro if it does not need to do anything. 29915 29916 -- Macro: ASM_FINAL_SPEC 29917 A C string constant that tells the GCC driver program how to run 29918 any programs which cleanup after the normal assembler. Normally, 29919 this is not needed. See the file 'mips.h' for an example of this. 29920 29921 Do not define this macro if it does not need to do anything. 29922 29923 -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT 29924 Define this macro, with no value, if the driver should give the 29925 assembler an argument consisting of a single dash, '-', to instruct 29926 it to read from its standard input (which will be a pipe connected 29927 to the output of the compiler proper). This argument is given 29928 after any '-o' option specifying the name of the output file. 29929 29930 If you do not define this macro, the assembler is assumed to read 29931 its standard input if given no non-option arguments. If your 29932 assembler cannot read standard input at all, use a '%{pipe:%e}' 29933 construct; see 'mips.h' for instance. 29934 29935 -- Macro: LINK_SPEC 29936 A C string constant that tells the GCC driver program options to 29937 pass to the linker. It can also specify how to translate options 29938 you give to GCC into options for GCC to pass to the linker. 29939 29940 Do not define this macro if it does not need to do anything. 29941 29942 -- Macro: LIB_SPEC 29943 Another C string constant used much like 'LINK_SPEC'. The 29944 difference between the two is that 'LIB_SPEC' is used at the end of 29945 the command given to the linker. 29946 29947 If this macro is not defined, a default is provided that loads the 29948 standard C library from the usual place. See 'gcc.c'. 29949 29950 -- Macro: LIBGCC_SPEC 29951 Another C string constant that tells the GCC driver program how and 29952 when to place a reference to 'libgcc.a' into the linker command 29953 line. This constant is placed both before and after the value of 29954 'LIB_SPEC'. 29955 29956 If this macro is not defined, the GCC driver provides a default 29957 that passes the string '-lgcc' to the linker. 29958 29959 -- Macro: REAL_LIBGCC_SPEC 29960 By default, if 'ENABLE_SHARED_LIBGCC' is defined, the 'LIBGCC_SPEC' 29961 is not directly used by the driver program but is instead modified 29962 to refer to different versions of 'libgcc.a' depending on the 29963 values of the command line flags '-static', '-shared', 29964 '-static-libgcc', and '-shared-libgcc'. On targets where these 29965 modifications are inappropriate, define 'REAL_LIBGCC_SPEC' instead. 29966 'REAL_LIBGCC_SPEC' tells the driver how to place a reference to 29967 'libgcc' on the link command line, but, unlike 'LIBGCC_SPEC', it is 29968 used unmodified. 29969 29970 -- Macro: USE_LD_AS_NEEDED 29971 A macro that controls the modifications to 'LIBGCC_SPEC' mentioned 29972 in 'REAL_LIBGCC_SPEC'. If nonzero, a spec will be generated that 29973 uses '--as-needed' or equivalent options and the shared 'libgcc' in 29974 place of the static exception handler library, when linking without 29975 any of '-static', '-static-libgcc', or '-shared-libgcc'. 29976 29977 -- Macro: LINK_EH_SPEC 29978 If defined, this C string constant is added to 'LINK_SPEC'. When 29979 'USE_LD_AS_NEEDED' is zero or undefined, it also affects the 29980 modifications to 'LIBGCC_SPEC' mentioned in 'REAL_LIBGCC_SPEC'. 29981 29982 -- Macro: STARTFILE_SPEC 29983 Another C string constant used much like 'LINK_SPEC'. The 29984 difference between the two is that 'STARTFILE_SPEC' is used at the 29985 very beginning of the command given to the linker. 29986 29987 If this macro is not defined, a default is provided that loads the 29988 standard C startup file from the usual place. See 'gcc.c'. 29989 29990 -- Macro: ENDFILE_SPEC 29991 Another C string constant used much like 'LINK_SPEC'. The 29992 difference between the two is that 'ENDFILE_SPEC' is used at the 29993 very end of the command given to the linker. 29994 29995 Do not define this macro if it does not need to do anything. 29996 29997 -- Macro: THREAD_MODEL_SPEC 29998 GCC '-v' will print the thread model GCC was configured to use. 29999 However, this doesn't work on platforms that are multilibbed on 30000 thread models, such as AIX 4.3. On such platforms, define 30001 'THREAD_MODEL_SPEC' such that it evaluates to a string without 30002 blanks that names one of the recognized thread models. '%*', the 30003 default value of this macro, will expand to the value of 30004 'thread_file' set in 'config.gcc'. 30005 30006 -- Macro: SYSROOT_SUFFIX_SPEC 30007 Define this macro to add a suffix to the target sysroot when GCC is 30008 configured with a sysroot. This will cause GCC to search for 30009 usr/lib, et al, within sysroot+suffix. 30010 30011 -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC 30012 Define this macro to add a headers_suffix to the target sysroot 30013 when GCC is configured with a sysroot. This will cause GCC to pass 30014 the updated sysroot+headers_suffix to CPP, causing it to search for 30015 usr/include, et al, within sysroot+headers_suffix. 30016 30017 -- Macro: EXTRA_SPECS 30018 Define this macro to provide additional specifications to put in 30019 the 'specs' file that can be used in various specifications like 30020 'CC1_SPEC'. 30021 30022 The definition should be an initializer for an array of structures, 30023 containing a string constant, that defines the specification name, 30024 and a string constant that provides the specification. 30025 30026 Do not define this macro if it does not need to do anything. 30027 30028 'EXTRA_SPECS' is useful when an architecture contains several 30029 related targets, which have various '..._SPECS' which are similar 30030 to each other, and the maintainer would like one central place to 30031 keep these definitions. 30032 30033 For example, the PowerPC System V.4 targets use 'EXTRA_SPECS' to 30034 define either '_CALL_SYSV' when the System V calling sequence is 30035 used or '_CALL_AIX' when the older AIX-based calling sequence is 30036 used. 30037 30038 The 'config/rs6000/rs6000.h' target file defines: 30039 30040 #define EXTRA_SPECS \ 30041 { "cpp_sysv_default", CPP_SYSV_DEFAULT }, 30042 30043 #define CPP_SYS_DEFAULT "" 30044 30045 The 'config/rs6000/sysv.h' target file defines: 30046 #undef CPP_SPEC 30047 #define CPP_SPEC \ 30048 "%{posix: -D_POSIX_SOURCE } \ 30049 %{mcall-sysv: -D_CALL_SYSV } \ 30050 %{!mcall-sysv: %(cpp_sysv_default) } \ 30051 %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}" 30052 30053 #undef CPP_SYSV_DEFAULT 30054 #define CPP_SYSV_DEFAULT "-D_CALL_SYSV" 30055 30056 while the 'config/rs6000/eabiaix.h' target file defines 30057 'CPP_SYSV_DEFAULT' as: 30058 30059 #undef CPP_SYSV_DEFAULT 30060 #define CPP_SYSV_DEFAULT "-D_CALL_AIX" 30061 30062 -- Macro: LINK_LIBGCC_SPECIAL_1 30063 Define this macro if the driver program should find the library 30064 'libgcc.a'. If you do not define this macro, the driver program 30065 will pass the argument '-lgcc' to tell the linker to do the search. 30066 30067 -- Macro: LINK_GCC_C_SEQUENCE_SPEC 30068 The sequence in which libgcc and libc are specified to the linker. 30069 By default this is '%G %L %G'. 30070 30071 -- Macro: POST_LINK_SPEC 30072 Define this macro to add additional steps to be executed after 30073 linker. The default value of this macro is empty string. 30074 30075 -- Macro: LINK_COMMAND_SPEC 30076 A C string constant giving the complete command line need to 30077 execute the linker. When you do this, you will need to update your 30078 port each time a change is made to the link command line within 30079 'gcc.c'. Therefore, define this macro only if you need to 30080 completely redefine the command line for invoking the linker and 30081 there is no other way to accomplish the effect you need. 30082 Overriding this macro may be avoidable by overriding 30083 'LINK_GCC_C_SEQUENCE_SPEC' instead. 30084 30085 -- Common Target Hook: bool TARGET_ALWAYS_STRIP_DOTDOT 30086 True if '..' components should always be removed from directory 30087 names computed relative to GCC's internal directories, false 30088 (default) if such components should be preserved and directory 30089 names containing them passed to other tools such as the linker. 30090 30091 -- Macro: MULTILIB_DEFAULTS 30092 Define this macro as a C expression for the initializer of an array 30093 of string to tell the driver program which options are defaults for 30094 this target and thus do not need to be handled specially when using 30095 'MULTILIB_OPTIONS'. 30096 30097 Do not define this macro if 'MULTILIB_OPTIONS' is not defined in 30098 the target makefile fragment or if none of the options listed in 30099 'MULTILIB_OPTIONS' are set by default. *Note Target Fragment::. 30100 30101 -- Macro: RELATIVE_PREFIX_NOT_LINKDIR 30102 Define this macro to tell 'gcc' that it should only translate a 30103 '-B' prefix into a '-L' linker option if the prefix indicates an 30104 absolute file name. 30105 30106 -- Macro: MD_EXEC_PREFIX 30107 If defined, this macro is an additional prefix to try after 30108 'STANDARD_EXEC_PREFIX'. 'MD_EXEC_PREFIX' is not searched when the 30109 compiler is built as a cross compiler. If you define 30110 'MD_EXEC_PREFIX', then be sure to add it to the list of directories 30111 used to find the assembler in 'configure.ac'. 30112 30113 -- Macro: STANDARD_STARTFILE_PREFIX 30114 Define this macro as a C string constant if you wish to override 30115 the standard choice of 'libdir' as the default prefix to try when 30116 searching for startup files such as 'crt0.o'. 30117 'STANDARD_STARTFILE_PREFIX' is not searched when the compiler is 30118 built as a cross compiler. 30119 30120 -- Macro: STANDARD_STARTFILE_PREFIX_1 30121 Define this macro as a C string constant if you wish to override 30122 the standard choice of '/lib' as a prefix to try after the default 30123 prefix when searching for startup files such as 'crt0.o'. 30124 'STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is 30125 built as a cross compiler. 30126 30127 -- Macro: STANDARD_STARTFILE_PREFIX_2 30128 Define this macro as a C string constant if you wish to override 30129 the standard choice of '/lib' as yet another prefix to try after 30130 the default prefix when searching for startup files such as 30131 'crt0.o'. 'STANDARD_STARTFILE_PREFIX_2' is not searched when the 30132 compiler is built as a cross compiler. 30133 30134 -- Macro: MD_STARTFILE_PREFIX 30135 If defined, this macro supplies an additional prefix to try after 30136 the standard prefixes. 'MD_EXEC_PREFIX' is not searched when the 30137 compiler is built as a cross compiler. 30138 30139 -- Macro: MD_STARTFILE_PREFIX_1 30140 If defined, this macro supplies yet another prefix to try after the 30141 standard prefixes. It is not searched when the compiler is built 30142 as a cross compiler. 30143 30144 -- Macro: INIT_ENVIRONMENT 30145 Define this macro as a C string constant if you wish to set 30146 environment variables for programs called by the driver, such as 30147 the assembler and loader. The driver passes the value of this 30148 macro to 'putenv' to initialize the necessary environment 30149 variables. 30150 30151 -- Macro: LOCAL_INCLUDE_DIR 30152 Define this macro as a C string constant if you wish to override 30153 the standard choice of '/usr/local/include' as the default prefix 30154 to try when searching for local header files. 'LOCAL_INCLUDE_DIR' 30155 comes before 'NATIVE_SYSTEM_HEADER_DIR' (set in 'config.gcc', 30156 normally '/usr/include') in the search order. 30157 30158 Cross compilers do not search either '/usr/local/include' or its 30159 replacement. 30160 30161 -- Macro: NATIVE_SYSTEM_HEADER_COMPONENT 30162 The "component" corresponding to 'NATIVE_SYSTEM_HEADER_DIR'. See 30163 'INCLUDE_DEFAULTS', below, for the description of components. If 30164 you do not define this macro, no component is used. 30165 30166 -- Macro: INCLUDE_DEFAULTS 30167 Define this macro if you wish to override the entire default search 30168 path for include files. For a native compiler, the default search 30169 path usually consists of 'GCC_INCLUDE_DIR', 'LOCAL_INCLUDE_DIR', 30170 'GPLUSPLUS_INCLUDE_DIR', and 'NATIVE_SYSTEM_HEADER_DIR'. In 30171 addition, 'GPLUSPLUS_INCLUDE_DIR' and 'GCC_INCLUDE_DIR' are defined 30172 automatically by 'Makefile', and specify private search areas for 30173 GCC. The directory 'GPLUSPLUS_INCLUDE_DIR' is used only for C++ 30174 programs. 30175 30176 The definition should be an initializer for an array of structures. 30177 Each array element should have four elements: the directory name (a 30178 string constant), the component name (also a string constant), a 30179 flag for C++-only directories, and a flag showing that the includes 30180 in the directory don't need to be wrapped in 'extern 'C'' when 30181 compiling C++. Mark the end of the array with a null element. 30182 30183 The component name denotes what GNU package the include file is 30184 part of, if any, in all uppercase letters. For example, it might 30185 be 'GCC' or 'BINUTILS'. If the package is part of a 30186 vendor-supplied operating system, code the component name as '0'. 30187 30188 For example, here is the definition used for VAX/VMS: 30189 30190 #define INCLUDE_DEFAULTS \ 30191 { \ 30192 { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \ 30193 { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \ 30194 { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \ 30195 { ".", 0, 0, 0}, \ 30196 { 0, 0, 0, 0} \ 30197 } 30198 30199 Here is the order of prefixes tried for exec files: 30200 30201 1. Any prefixes specified by the user with '-B'. 30202 30203 2. The environment variable 'GCC_EXEC_PREFIX' or, if 'GCC_EXEC_PREFIX' 30204 is not set and the compiler has not been installed in the 30205 configure-time PREFIX, the location in which the compiler has 30206 actually been installed. 30207 30208 3. The directories specified by the environment variable 30209 'COMPILER_PATH'. 30210 30211 4. The macro 'STANDARD_EXEC_PREFIX', if the compiler has been 30212 installed in the configured-time PREFIX. 30213 30214 5. The location '/usr/libexec/gcc/', but only if this is a native 30215 compiler. 30216 30217 6. The location '/usr/lib/gcc/', but only if this is a native 30218 compiler. 30219 30220 7. The macro 'MD_EXEC_PREFIX', if defined, but only if this is a 30221 native compiler. 30222 30223 Here is the order of prefixes tried for startfiles: 30224 30225 1. Any prefixes specified by the user with '-B'. 30226 30227 2. The environment variable 'GCC_EXEC_PREFIX' or its automatically 30228 determined value based on the installed toolchain location. 30229 30230 3. The directories specified by the environment variable 30231 'LIBRARY_PATH' (or port-specific name; native only, cross compilers 30232 do not use this). 30233 30234 4. The macro 'STANDARD_EXEC_PREFIX', but only if the toolchain is 30235 installed in the configured PREFIX or this is a native compiler. 30236 30237 5. The location '/usr/lib/gcc/', but only if this is a native 30238 compiler. 30239 30240 6. The macro 'MD_EXEC_PREFIX', if defined, but only if this is a 30241 native compiler. 30242 30243 7. The macro 'MD_STARTFILE_PREFIX', if defined, but only if this is a 30244 native compiler, or we have a target system root. 30245 30246 8. The macro 'MD_STARTFILE_PREFIX_1', if defined, but only if this is 30247 a native compiler, or we have a target system root. 30248 30249 9. The macro 'STANDARD_STARTFILE_PREFIX', with any sysroot 30250 modifications. If this path is relative it will be prefixed by 30251 'GCC_EXEC_PREFIX' and the machine suffix or 'STANDARD_EXEC_PREFIX' 30252 and the machine suffix. 30253 30254 10. The macro 'STANDARD_STARTFILE_PREFIX_1', but only if this is a 30255 native compiler, or we have a target system root. The default for 30256 this macro is '/lib/'. 30257 30258 11. The macro 'STANDARD_STARTFILE_PREFIX_2', but only if this is a 30259 native compiler, or we have a target system root. The default for 30260 this macro is '/usr/lib/'. 30261 30262 30263File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros 30264 3026518.3 Run-time Target Specification 30266================================== 30267 30268Here are run-time target specifications. 30269 30270 -- Macro: TARGET_CPU_CPP_BUILTINS () 30271 This function-like macro expands to a block of code that defines 30272 built-in preprocessor macros and assertions for the target CPU, 30273 using the functions 'builtin_define', 'builtin_define_std' and 30274 'builtin_assert'. When the front end calls this macro it provides 30275 a trailing semicolon, and since it has finished command line option 30276 processing your code can use those results freely. 30277 30278 'builtin_assert' takes a string in the form you pass to the 30279 command-line option '-A', such as 'cpu=mips', and creates the 30280 assertion. 'builtin_define' takes a string in the form accepted by 30281 option '-D' and unconditionally defines the macro. 30282 30283 'builtin_define_std' takes a string representing the name of an 30284 object-like macro. If it doesn't lie in the user's namespace, 30285 'builtin_define_std' defines it unconditionally. Otherwise, it 30286 defines a version with two leading underscores, and another version 30287 with two leading and trailing underscores, and defines the original 30288 only if an ISO standard was not requested on the command line. For 30289 example, passing 'unix' defines '__unix', '__unix__' and possibly 30290 'unix'; passing '_mips' defines '__mips', '__mips__' and possibly 30291 '_mips', and passing '_ABI64' defines only '_ABI64'. 30292 30293 You can also test for the C dialect being compiled. The variable 30294 'c_language' is set to one of 'clk_c', 'clk_cplusplus' or 30295 'clk_objective_c'. Note that if we are preprocessing assembler, 30296 this variable will be 'clk_c' but the function-like macro 30297 'preprocessing_asm_p()' will return true, so you might want to 30298 check for that first. If you need to check for strict ANSI, the 30299 variable 'flag_iso' can be used. The function-like macro 30300 'preprocessing_trad_p()' can be used to check for traditional 30301 preprocessing. 30302 30303 -- Macro: TARGET_OS_CPP_BUILTINS () 30304 Similarly to 'TARGET_CPU_CPP_BUILTINS' but this macro is optional 30305 and is used for the target operating system instead. 30306 30307 -- Macro: TARGET_OBJFMT_CPP_BUILTINS () 30308 Similarly to 'TARGET_CPU_CPP_BUILTINS' but this macro is optional 30309 and is used for the target object format. 'elfos.h' uses this 30310 macro to define '__ELF__', so you probably do not need to define it 30311 yourself. 30312 30313 -- Variable: extern int target_flags 30314 This variable is declared in 'options.h', which is included before 30315 any target-specific headers. 30316 30317 -- Common Target Hook: int TARGET_DEFAULT_TARGET_FLAGS 30318 This variable specifies the initial value of 'target_flags'. Its 30319 default setting is 0. 30320 30321 -- Common Target Hook: bool TARGET_HANDLE_OPTION (struct gcc_options 30322 *OPTS, struct gcc_options *OPTS_SET, const struct 30323 cl_decoded_option *DECODED, location_t LOC) 30324 This hook is called whenever the user specifies one of the 30325 target-specific options described by the '.opt' definition files 30326 (*note Options::). It has the opportunity to do some 30327 option-specific processing and should return true if the option is 30328 valid. The default definition does nothing but return true. 30329 30330 DECODED specifies the option and its arguments. OPTS and OPTS_SET 30331 are the 'gcc_options' structures to be used for storing option 30332 state, and LOC is the location at which the option was passed 30333 ('UNKNOWN_LOCATION' except for options passed via attributes). 30334 30335 -- C Target Hook: bool TARGET_HANDLE_C_OPTION (size_t CODE, const char 30336 *ARG, int VALUE) 30337 This target hook is called whenever the user specifies one of the 30338 target-specific C language family options described by the '.opt' 30339 definition files(*note Options::). It has the opportunity to do 30340 some option-specific processing and should return true if the 30341 option is valid. The arguments are like for 30342 'TARGET_HANDLE_OPTION'. The default definition does nothing but 30343 return false. 30344 30345 In general, you should use 'TARGET_HANDLE_OPTION' to handle 30346 options. However, if processing an option requires routines that 30347 are only available in the C (and related language) front ends, then 30348 you should use 'TARGET_HANDLE_C_OPTION' instead. 30349 30350 -- C Target Hook: tree TARGET_OBJC_CONSTRUCT_STRING_OBJECT (tree 30351 STRING) 30352 Targets may provide a string object type that can be used within 30353 and between C, C++ and their respective Objective-C dialects. A 30354 string object might, for example, embed encoding and length 30355 information. These objects are considered opaque to the compiler 30356 and handled as references. An ideal implementation makes the 30357 composition of the string object match that of the Objective-C 30358 'NSString' ('NXString' for GNUStep), allowing efficient 30359 interworking between C-only and Objective-C code. If a target 30360 implements string objects then this hook should return a reference 30361 to such an object constructed from the normal 'C' string 30362 representation provided in STRING. At present, the hook is used by 30363 Objective-C only, to obtain a common-format string object when the 30364 target provides one. 30365 30366 -- C Target Hook: void TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE 30367 (const char *CLASSNAME) 30368 Declare that Objective C class CLASSNAME is referenced by the 30369 current TU. 30370 30371 -- C Target Hook: void TARGET_OBJC_DECLARE_CLASS_DEFINITION (const char 30372 *CLASSNAME) 30373 Declare that Objective C class CLASSNAME is defined by the current 30374 TU. 30375 30376 -- C Target Hook: bool TARGET_STRING_OBJECT_REF_TYPE_P (const_tree 30377 STRINGREF) 30378 If a target implements string objects then this hook should return 30379 'true' if STRINGREF is a valid reference to such an object. 30380 30381 -- C Target Hook: void TARGET_CHECK_STRING_OBJECT_FORMAT_ARG (tree 30382 FORMAT_ARG, tree ARGS_LIST) 30383 If a target implements string objects then this hook should should 30384 provide a facility to check the function arguments in ARGS_LIST 30385 against the format specifiers in FORMAT_ARG where the type of 30386 FORMAT_ARG is one recognized as a valid string reference type. 30387 30388 -- Target Hook: void TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE (void) 30389 This target function is similar to the hook 30390 'TARGET_OPTION_OVERRIDE' but is called when the optimize level is 30391 changed via an attribute or pragma or when it is reset at the end 30392 of the code affected by the attribute or pragma. It is not called 30393 at the beginning of compilation when 'TARGET_OPTION_OVERRIDE' is 30394 called so if you want to perform these actions then, you should 30395 have 'TARGET_OPTION_OVERRIDE' call 30396 'TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE'. 30397 30398 -- Macro: C_COMMON_OVERRIDE_OPTIONS 30399 This is similar to the 'TARGET_OPTION_OVERRIDE' hook but is only 30400 used in the C language frontends (C, Objective-C, C++, 30401 Objective-C++) and so can be used to alter option flag variables 30402 which only exist in those frontends. 30403 30404 -- Common Target Hook: const struct default_options * 30405 TARGET_OPTION_OPTIMIZATION_TABLE 30406 Some machines may desire to change what optimizations are performed 30407 for various optimization levels. This variable, if defined, 30408 describes options to enable at particular sets of optimization 30409 levels. These options are processed once just after the 30410 optimization level is determined and before the remainder of the 30411 command options have been parsed, so may be overridden by other 30412 options passed explicitly. 30413 30414 This processing is run once at program startup and when the 30415 optimization options are changed via '#pragma GCC optimize' or by 30416 using the 'optimize' attribute. 30417 30418 -- Common Target Hook: void TARGET_OPTION_INIT_STRUCT (struct 30419 gcc_options *OPTS) 30420 Set target-dependent initial values of fields in OPTS. 30421 30422 -- Common Target Hook: void TARGET_OPTION_DEFAULT_PARAMS (void) 30423 Set target-dependent default values for '--param' settings, using 30424 calls to 'set_default_param_value'. 30425 30426 -- Macro: SWITCHABLE_TARGET 30427 Some targets need to switch between substantially different 30428 subtargets during compilation. For example, the MIPS target has 30429 one subtarget for the traditional MIPS architecture and another for 30430 MIPS16. Source code can switch between these two subarchitectures 30431 using the 'mips16' and 'nomips16' attributes. 30432 30433 Such subtargets can differ in things like the set of available 30434 registers, the set of available instructions, the costs of various 30435 operations, and so on. GCC caches a lot of this type of 30436 information in global variables, and recomputing them for each 30437 subtarget takes a significant amount of time. The compiler 30438 therefore provides a facility for maintaining several versions of 30439 the global variables and quickly switching between them; see 30440 'target-globals.h' for details. 30441 30442 Define this macro to 1 if your target needs this facility. The 30443 default is 0. 30444 30445 -- Target Hook: bool TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P 30446 (void) 30447 Returns true if the target supports IEEE 754 floating-point 30448 exceptions and rounding modes, false otherwise. This is intended 30449 to relate to the 'float' and 'double' types, but not necessarily 30450 'long double'. By default, returns true if the 'adddf3' 30451 instruction pattern is available and false otherwise, on the 30452 assumption that hardware floating point supports exceptions and 30453 rounding modes but software floating point does not. 30454 30455 30456File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros 30457 3045818.4 Defining data structures for per-function information. 30459=========================================================== 30460 30461If the target needs to store information on a per-function basis, GCC 30462provides a macro and a couple of variables to allow this. Note, just 30463using statics to store the information is a bad idea, since GCC supports 30464nested functions, so you can be halfway through encoding one function 30465when another one comes along. 30466 30467 GCC defines a data structure called 'struct function' which contains 30468all of the data specific to an individual function. This structure 30469contains a field called 'machine' whose type is 'struct machine_function 30470*', which can be used by targets to point to their own specific data. 30471 30472 If a target needs per-function specific data it should define the type 30473'struct machine_function' and also the macro 'INIT_EXPANDERS'. This 30474macro should be used to initialize the function pointer 30475'init_machine_status'. This pointer is explained below. 30476 30477 One typical use of per-function, target specific data is to create an 30478RTX to hold the register containing the function's return address. This 30479RTX can then be used to implement the '__builtin_return_address' 30480function, for level 0. 30481 30482 Note--earlier implementations of GCC used a single data area to hold 30483all of the per-function information. Thus when processing of a nested 30484function began the old per-function data had to be pushed onto a stack, 30485and when the processing was finished, it had to be popped off the stack. 30486GCC used to provide function pointers called 'save_machine_status' and 30487'restore_machine_status' to handle the saving and restoring of the 30488target specific information. Since the single data area approach is no 30489longer used, these pointers are no longer supported. 30490 30491 -- Macro: INIT_EXPANDERS 30492 Macro called to initialize any target specific information. This 30493 macro is called once per function, before generation of any RTL has 30494 begun. The intention of this macro is to allow the initialization 30495 of the function pointer 'init_machine_status'. 30496 30497 -- Variable: void (*)(struct function *) init_machine_status 30498 If this function pointer is non-'NULL' it will be called once per 30499 function, before function compilation starts, in order to allow the 30500 target to perform any target specific initialization of the 'struct 30501 function' structure. It is intended that this would be used to 30502 initialize the 'machine' of that structure. 30503 30504 'struct machine_function' structures are expected to be freed by 30505 GC. Generally, any memory that they reference must be allocated by 30506 using GC allocation, including the structure itself. 30507 30508 30509File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros 30510 3051118.5 Storage Layout 30512=================== 30513 30514Note that the definitions of the macros in this table which are sizes or 30515alignments measured in bits do not need to be constant. They can be C 30516expressions that refer to static variables, such as the 'target_flags'. 30517*Note Run-time Target::. 30518 30519 -- Macro: BITS_BIG_ENDIAN 30520 Define this macro to have the value 1 if the most significant bit 30521 in a byte has the lowest number; otherwise define it to have the 30522 value zero. This means that bit-field instructions count from the 30523 most significant bit. If the machine has no bit-field 30524 instructions, then this must still be defined, but it doesn't 30525 matter which value it is defined to. This macro need not be a 30526 constant. 30527 30528 This macro does not affect the way structure fields are packed into 30529 bytes or words; that is controlled by 'BYTES_BIG_ENDIAN'. 30530 30531 -- Macro: BYTES_BIG_ENDIAN 30532 Define this macro to have the value 1 if the most significant byte 30533 in a word has the lowest number. This macro need not be a 30534 constant. 30535 30536 -- Macro: WORDS_BIG_ENDIAN 30537 Define this macro to have the value 1 if, in a multiword object, 30538 the most significant word has the lowest number. This applies to 30539 both memory locations and registers; see 'REG_WORDS_BIG_ENDIAN' if 30540 the order of words in memory is not the same as the order in 30541 registers. This macro need not be a constant. 30542 30543 -- Macro: REG_WORDS_BIG_ENDIAN 30544 On some machines, the order of words in a multiword object differs 30545 between registers in memory. In such a situation, define this 30546 macro to describe the order of words in a register. The macro 30547 'WORDS_BIG_ENDIAN' controls the order of words in memory. 30548 30549 -- Macro: FLOAT_WORDS_BIG_ENDIAN 30550 Define this macro to have the value 1 if 'DFmode', 'XFmode' or 30551 'TFmode' floating point numbers are stored in memory with the word 30552 containing the sign bit at the lowest address; otherwise define it 30553 to have the value 0. This macro need not be a constant. 30554 30555 You need not define this macro if the ordering is the same as for 30556 multi-word integers. 30557 30558 -- Macro: BITS_PER_WORD 30559 Number of bits in a word. If you do not define this macro, the 30560 default is 'BITS_PER_UNIT * UNITS_PER_WORD'. 30561 30562 -- Macro: MAX_BITS_PER_WORD 30563 Maximum number of bits in a word. If this is undefined, the 30564 default is 'BITS_PER_WORD'. Otherwise, it is the constant value 30565 that is the largest value that 'BITS_PER_WORD' can have at 30566 run-time. 30567 30568 -- Macro: UNITS_PER_WORD 30569 Number of storage units in a word; normally the size of a 30570 general-purpose register, a power of two from 1 or 8. 30571 30572 -- Macro: MIN_UNITS_PER_WORD 30573 Minimum number of units in a word. If this is undefined, the 30574 default is 'UNITS_PER_WORD'. Otherwise, it is the constant value 30575 that is the smallest value that 'UNITS_PER_WORD' can have at 30576 run-time. 30577 30578 -- Macro: POINTER_SIZE 30579 Width of a pointer, in bits. You must specify a value no wider 30580 than the width of 'Pmode'. If it is not equal to the width of 30581 'Pmode', you must define 'POINTERS_EXTEND_UNSIGNED'. If you do not 30582 specify a value the default is 'BITS_PER_WORD'. 30583 30584 -- Macro: POINTERS_EXTEND_UNSIGNED 30585 A C expression that determines how pointers should be extended from 30586 'ptr_mode' to either 'Pmode' or 'word_mode'. It is greater than 30587 zero if pointers should be zero-extended, zero if they should be 30588 sign-extended, and negative if some other sort of conversion is 30589 needed. In the last case, the extension is done by the target's 30590 'ptr_extend' instruction. 30591 30592 You need not define this macro if the 'ptr_mode', 'Pmode' and 30593 'word_mode' are all the same width. 30594 30595 -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE) 30596 A macro to update M and UNSIGNEDP when an object whose type is TYPE 30597 and which has the specified mode and signedness is to be stored in 30598 a register. This macro is only called when TYPE is a scalar type. 30599 30600 On most RISC machines, which only have operations that operate on a 30601 full register, define this macro to set M to 'word_mode' if M is an 30602 integer mode narrower than 'BITS_PER_WORD'. In most cases, only 30603 integer modes should be widened because wider-precision 30604 floating-point operations are usually more expensive than their 30605 narrower counterparts. 30606 30607 For most machines, the macro definition does not change UNSIGNEDP. 30608 However, some machines, have instructions that preferentially 30609 handle either signed or unsigned quantities of certain modes. For 30610 example, on the DEC Alpha, 32-bit loads from memory and 32-bit add 30611 instructions sign-extend the result to 64 bits. On such machines, 30612 set UNSIGNEDP according to which kind of extension is more 30613 efficient. 30614 30615 Do not define this macro if it would never modify M. 30616 30617 -- Target Hook: enum flt_eval_method TARGET_C_EXCESS_PRECISION (enum 30618 excess_precision_type TYPE) 30619 Return a value, with the same meaning as the C99 macro 30620 'FLT_EVAL_METHOD' that describes which excess precision should be 30621 applied. TYPE is either 'EXCESS_PRECISION_TYPE_IMPLICIT', 30622 'EXCESS_PRECISION_TYPE_FAST', or 'EXCESS_PRECISION_TYPE_STANDARD'. 30623 For 'EXCESS_PRECISION_TYPE_IMPLICIT', the target should return 30624 which precision and range operations will be implictly evaluated in 30625 regardless of the excess precision explicitly added. For 30626 'EXCESS_PRECISION_TYPE_STANDARD' and 'EXCESS_PRECISION_TYPE_FAST', 30627 the target should return the explicit excess precision that should 30628 be added depending on the value set for 30629 '-fexcess-precision=[standard|fast]'. Note that unpredictable 30630 explicit excess precision does not make sense, so a target should 30631 never return 'FLT_EVAL_METHOD_UNPREDICTABLE' when TYPE is 30632 'EXCESS_PRECISION_TYPE_STANDARD' or 'EXCESS_PRECISION_TYPE_FAST'. 30633 30634 -- Target Hook: machine_mode TARGET_PROMOTE_FUNCTION_MODE (const_tree 30635 TYPE, machine_mode MODE, int *PUNSIGNEDP, const_tree FUNTYPE, 30636 int FOR_RETURN) 30637 Like 'PROMOTE_MODE', but it is applied to outgoing function 30638 arguments or function return values. The target hook should return 30639 the new mode and possibly change '*PUNSIGNEDP' if the promotion 30640 should change signedness. This function is called only for scalar 30641 _or pointer_ types. 30642 30643 FOR_RETURN allows to distinguish the promotion of arguments and 30644 return values. If it is '1', a return value is being promoted and 30645 'TARGET_FUNCTION_VALUE' must perform the same promotions done here. 30646 If it is '2', the returned mode should be that of the register in 30647 which an incoming parameter is copied, or the outgoing result is 30648 computed; then the hook should return the same mode as 30649 'promote_mode', though the signedness may be different. 30650 30651 TYPE can be NULL when promoting function arguments of libcalls. 30652 30653 The default is to not promote arguments and return values. You can 30654 also define the hook to 30655 'default_promote_function_mode_always_promote' if you would like to 30656 apply the same rules given by 'PROMOTE_MODE'. 30657 30658 -- Macro: PARM_BOUNDARY 30659 Normal alignment required for function parameters on the stack, in 30660 bits. All stack parameters receive at least this much alignment 30661 regardless of data type. On most machines, this is the same as the 30662 size of an integer. 30663 30664 -- Macro: STACK_BOUNDARY 30665 Define this macro to the minimum alignment enforced by hardware for 30666 the stack pointer on this machine. The definition is a C 30667 expression for the desired alignment (measured in bits). This 30668 value is used as a default if 'PREFERRED_STACK_BOUNDARY' is not 30669 defined. On most machines, this should be the same as 30670 'PARM_BOUNDARY'. 30671 30672 -- Macro: PREFERRED_STACK_BOUNDARY 30673 Define this macro if you wish to preserve a certain alignment for 30674 the stack pointer, greater than what the hardware enforces. The 30675 definition is a C expression for the desired alignment (measured in 30676 bits). This macro must evaluate to a value equal to or larger than 30677 'STACK_BOUNDARY'. 30678 30679 -- Macro: INCOMING_STACK_BOUNDARY 30680 Define this macro if the incoming stack boundary may be different 30681 from 'PREFERRED_STACK_BOUNDARY'. This macro must evaluate to a 30682 value equal to or larger than 'STACK_BOUNDARY'. 30683 30684 -- Macro: FUNCTION_BOUNDARY 30685 Alignment required for a function entry point, in bits. 30686 30687 -- Macro: BIGGEST_ALIGNMENT 30688 Biggest alignment that any data type can require on this machine, 30689 in bits. Note that this is not the biggest alignment that is 30690 supported, just the biggest alignment that, when violated, may 30691 cause a fault. 30692 30693 -- Target Hook: HOST_WIDE_INT TARGET_ABSOLUTE_BIGGEST_ALIGNMENT 30694 If defined, this target hook specifies the absolute biggest 30695 alignment that a type or variable can have on this machine, 30696 otherwise, 'BIGGEST_ALIGNMENT' is used. 30697 30698 -- Macro: MALLOC_ABI_ALIGNMENT 30699 Alignment, in bits, a C conformant malloc implementation has to 30700 provide. If not defined, the default value is 'BITS_PER_WORD'. 30701 30702 -- Macro: ATTRIBUTE_ALIGNED_VALUE 30703 Alignment used by the '__attribute__ ((aligned))' construct. If 30704 not defined, the default value is 'BIGGEST_ALIGNMENT'. 30705 30706 -- Macro: MINIMUM_ATOMIC_ALIGNMENT 30707 If defined, the smallest alignment, in bits, that can be given to 30708 an object that can be referenced in one operation, without 30709 disturbing any nearby object. Normally, this is 'BITS_PER_UNIT', 30710 but may be larger on machines that don't have byte or half-word 30711 store operations. 30712 30713 -- Macro: BIGGEST_FIELD_ALIGNMENT 30714 Biggest alignment that any structure or union field can require on 30715 this machine, in bits. If defined, this overrides 30716 'BIGGEST_ALIGNMENT' for structure and union fields only, unless the 30717 field alignment has been set by the '__attribute__ ((aligned (N)))' 30718 construct. 30719 30720 -- Macro: ADJUST_FIELD_ALIGN (FIELD, TYPE, COMPUTED) 30721 An expression for the alignment of a structure field FIELD of type 30722 TYPE if the alignment computed in the usual way (including applying 30723 of 'BIGGEST_ALIGNMENT' and 'BIGGEST_FIELD_ALIGNMENT' to the 30724 alignment) is COMPUTED. It overrides alignment only if the field 30725 alignment has not been set by the '__attribute__ ((aligned (N)))' 30726 construct. Note that FIELD may be 'NULL_TREE' in case we just 30727 query for the minimum alignment of a field of type TYPE in 30728 structure context. 30729 30730 -- Macro: MAX_STACK_ALIGNMENT 30731 Biggest stack alignment guaranteed by the backend. Use this macro 30732 to specify the maximum alignment of a variable on stack. 30733 30734 If not defined, the default value is 'STACK_BOUNDARY'. 30735 30736 -- Macro: MAX_OFILE_ALIGNMENT 30737 Biggest alignment supported by the object file format of this 30738 machine. Use this macro to limit the alignment which can be 30739 specified using the '__attribute__ ((aligned (N)))' construct. If 30740 not defined, the default value is 'BIGGEST_ALIGNMENT'. 30741 30742 On systems that use ELF, the default (in 'config/elfos.h') is the 30743 largest supported 32-bit ELF section alignment representable on a 30744 32-bit host e.g. '(((uint64_t) 1 << 28) * 8)'. On 32-bit ELF the 30745 largest supported section alignment in bits is '(0x80000000 * 8)', 30746 but this is not representable on 32-bit hosts. 30747 30748 -- Target Hook: HOST_WIDE_INT TARGET_STATIC_RTX_ALIGNMENT (machine_mode 30749 MODE) 30750 This hook returns the preferred alignment in bits for a 30751 statically-allocated rtx, such as a constant pool entry. MODE is 30752 the mode of the rtx. The default implementation returns 30753 'GET_MODE_ALIGNMENT (MODE)'. 30754 30755 -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN) 30756 If defined, a C expression to compute the alignment for a variable 30757 in the static store. TYPE is the data type, and BASIC-ALIGN is the 30758 alignment that the object would ordinarily have. The value of this 30759 macro is used instead of that alignment to align the object. 30760 30761 If this macro is not defined, then BASIC-ALIGN is used. 30762 30763 One use of this macro is to increase alignment of medium-size data 30764 to make it all fit in fewer cache lines. Another is to cause 30765 character arrays to be word-aligned so that 'strcpy' calls that 30766 copy constants to character arrays can be done inline. 30767 30768 -- Macro: DATA_ABI_ALIGNMENT (TYPE, BASIC-ALIGN) 30769 Similar to 'DATA_ALIGNMENT', but for the cases where the ABI 30770 mandates some alignment increase, instead of optimization only 30771 purposes. E.g. AMD x86-64 psABI says that variables with array 30772 type larger than 15 bytes must be aligned to 16 byte boundaries. 30773 30774 If this macro is not defined, then BASIC-ALIGN is used. 30775 30776 -- Target Hook: HOST_WIDE_INT TARGET_CONSTANT_ALIGNMENT (const_tree 30777 CONSTANT, HOST_WIDE_INT BASIC_ALIGN) 30778 This hook returns the alignment in bits of a constant that is being 30779 placed in memory. CONSTANT is the constant and BASIC_ALIGN is the 30780 alignment that the object would ordinarily have. 30781 30782 The default definition just returns BASIC_ALIGN. 30783 30784 The typical use of this hook is to increase alignment for string 30785 constants to be word aligned so that 'strcpy' calls that copy 30786 constants can be done inline. The function 30787 'constant_alignment_word_strings' provides such a definition. 30788 30789 -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN) 30790 If defined, a C expression to compute the alignment for a variable 30791 in the local store. TYPE is the data type, and BASIC-ALIGN is the 30792 alignment that the object would ordinarily have. The value of this 30793 macro is used instead of that alignment to align the object. 30794 30795 If this macro is not defined, then BASIC-ALIGN is used. 30796 30797 One use of this macro is to increase alignment of medium-size data 30798 to make it all fit in fewer cache lines. 30799 30800 If the value of this macro has a type, it should be an unsigned 30801 type. 30802 30803 -- Target Hook: HOST_WIDE_INT TARGET_VECTOR_ALIGNMENT (const_tree TYPE) 30804 This hook can be used to define the alignment for a vector of type 30805 TYPE, in order to comply with a platform ABI. The default is to 30806 require natural alignment for vector types. The alignment returned 30807 by this hook must be a power-of-two multiple of the default 30808 alignment of the vector element type. 30809 30810 -- Macro: STACK_SLOT_ALIGNMENT (TYPE, MODE, BASIC-ALIGN) 30811 If defined, a C expression to compute the alignment for stack slot. 30812 TYPE is the data type, MODE is the widest mode available, and 30813 BASIC-ALIGN is the alignment that the slot would ordinarily have. 30814 The value of this macro is used instead of that alignment to align 30815 the slot. 30816 30817 If this macro is not defined, then BASIC-ALIGN is used when TYPE is 30818 'NULL'. Otherwise, 'LOCAL_ALIGNMENT' will be used. 30819 30820 This macro is to set alignment of stack slot to the maximum 30821 alignment of all possible modes which the slot may have. 30822 30823 If the value of this macro has a type, it should be an unsigned 30824 type. 30825 30826 -- Macro: LOCAL_DECL_ALIGNMENT (DECL) 30827 If defined, a C expression to compute the alignment for a local 30828 variable DECL. 30829 30830 If this macro is not defined, then 'LOCAL_ALIGNMENT (TREE_TYPE 30831 (DECL), DECL_ALIGN (DECL))' is used. 30832 30833 One use of this macro is to increase alignment of medium-size data 30834 to make it all fit in fewer cache lines. 30835 30836 If the value of this macro has a type, it should be an unsigned 30837 type. 30838 30839 -- Macro: MINIMUM_ALIGNMENT (EXP, MODE, ALIGN) 30840 If defined, a C expression to compute the minimum required 30841 alignment for dynamic stack realignment purposes for EXP (a type or 30842 decl), MODE, assuming normal alignment ALIGN. 30843 30844 If this macro is not defined, then ALIGN will be used. 30845 30846 -- Macro: EMPTY_FIELD_BOUNDARY 30847 Alignment in bits to be given to a structure bit-field that follows 30848 an empty field such as 'int : 0;'. 30849 30850 If 'PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro. 30851 30852 -- Macro: STRUCTURE_SIZE_BOUNDARY 30853 Number of bits which any structure or union's size must be a 30854 multiple of. Each structure or union's size is rounded up to a 30855 multiple of this. 30856 30857 If you do not define this macro, the default is the same as 30858 'BITS_PER_UNIT'. 30859 30860 -- Macro: STRICT_ALIGNMENT 30861 Define this macro to be the value 1 if instructions will fail to 30862 work if given data not on the nominal alignment. If instructions 30863 will merely go slower in that case, define this macro as 0. 30864 30865 -- Macro: PCC_BITFIELD_TYPE_MATTERS 30866 Define this if you wish to imitate the way many other C compilers 30867 handle alignment of bit-fields and the structures that contain 30868 them. 30869 30870 The behavior is that the type written for a named bit-field ('int', 30871 'short', or other integer type) imposes an alignment for the entire 30872 structure, as if the structure really did contain an ordinary field 30873 of that type. In addition, the bit-field is placed within the 30874 structure so that it would fit within such a field, not crossing a 30875 boundary for it. 30876 30877 Thus, on most machines, a named bit-field whose type is written as 30878 'int' would not cross a four-byte boundary, and would force 30879 four-byte alignment for the whole structure. (The alignment used 30880 may not be four bytes; it is controlled by the other alignment 30881 parameters.) 30882 30883 An unnamed bit-field will not affect the alignment of the 30884 containing structure. 30885 30886 If the macro is defined, its definition should be a C expression; a 30887 nonzero value for the expression enables this behavior. 30888 30889 Note that if this macro is not defined, or its value is zero, some 30890 bit-fields may cross more than one alignment boundary. The 30891 compiler can support such references if there are 'insv', 'extv', 30892 and 'extzv' insns that can directly reference memory. 30893 30894 The other known way of making bit-fields work is to define 30895 'STRUCTURE_SIZE_BOUNDARY' as large as 'BIGGEST_ALIGNMENT'. Then 30896 every structure can be accessed with fullwords. 30897 30898 Unless the machine has bit-field instructions or you define 30899 'STRUCTURE_SIZE_BOUNDARY' that way, you must define 30900 'PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value. 30901 30902 If your aim is to make GCC use the same conventions for laying out 30903 bit-fields as are used by another compiler, here is how to 30904 investigate what the other compiler does. Compile and run this 30905 program: 30906 30907 struct foo1 30908 { 30909 char x; 30910 char :0; 30911 char y; 30912 }; 30913 30914 struct foo2 30915 { 30916 char x; 30917 int :0; 30918 char y; 30919 }; 30920 30921 main () 30922 { 30923 printf ("Size of foo1 is %d\n", 30924 sizeof (struct foo1)); 30925 printf ("Size of foo2 is %d\n", 30926 sizeof (struct foo2)); 30927 exit (0); 30928 } 30929 30930 If this prints 2 and 5, then the compiler's behavior is what you 30931 would get from 'PCC_BITFIELD_TYPE_MATTERS'. 30932 30933 -- Macro: BITFIELD_NBYTES_LIMITED 30934 Like 'PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited 30935 to aligning a bit-field within the structure. 30936 30937 -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELD (void) 30938 When 'PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine 30939 whether unnamed bitfields affect the alignment of the containing 30940 structure. The hook should return true if the structure should 30941 inherit the alignment requirements of an unnamed bitfield's type. 30942 30943 -- Target Hook: bool TARGET_NARROW_VOLATILE_BITFIELD (void) 30944 This target hook should return 'true' if accesses to volatile 30945 bitfields should use the narrowest mode possible. It should return 30946 'false' if these accesses should use the bitfield container type. 30947 30948 The default is 'false'. 30949 30950 -- Target Hook: bool TARGET_MEMBER_TYPE_FORCES_BLK (const_tree FIELD, 30951 machine_mode MODE) 30952 Return true if a structure, union or array containing FIELD should 30953 be accessed using 'BLKMODE'. 30954 30955 If FIELD is the only field in the structure, MODE is its mode, 30956 otherwise MODE is VOIDmode. MODE is provided in the case where 30957 structures of one field would require the structure's mode to 30958 retain the field's mode. 30959 30960 Normally, this is not needed. 30961 30962 -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED) 30963 Define this macro as an expression for the alignment of a type 30964 (given by TYPE as a tree node) if the alignment computed in the 30965 usual way is COMPUTED and the alignment explicitly specified was 30966 SPECIFIED. 30967 30968 The default is to use SPECIFIED if it is larger; otherwise, use the 30969 smaller of COMPUTED and 'BIGGEST_ALIGNMENT' 30970 30971 -- Macro: MAX_FIXED_MODE_SIZE 30972 An integer expression for the size in bits of the largest integer 30973 machine mode that should actually be used. All integer machine 30974 modes of this size or smaller can be used for structures and unions 30975 with the appropriate sizes. If this macro is undefined, 30976 'GET_MODE_BITSIZE (DImode)' is assumed. 30977 30978 -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL) 30979 If defined, an expression of type 'machine_mode' that specifies the 30980 mode of the save area operand of a 'save_stack_LEVEL' named pattern 30981 (*note Standard Names::). SAVE_LEVEL is one of 'SAVE_BLOCK', 30982 'SAVE_FUNCTION', or 'SAVE_NONLOCAL' and selects which of the three 30983 named patterns is having its mode specified. 30984 30985 You need not define this macro if it always returns 'Pmode'. You 30986 would most commonly define this macro if the 'save_stack_LEVEL' 30987 patterns need to support both a 32- and a 64-bit mode. 30988 30989 -- Macro: STACK_SIZE_MODE 30990 If defined, an expression of type 'machine_mode' that specifies the 30991 mode of the size increment operand of an 'allocate_stack' named 30992 pattern (*note Standard Names::). 30993 30994 You need not define this macro if it always returns 'word_mode'. 30995 You would most commonly define this macro if the 'allocate_stack' 30996 pattern needs to support both a 32- and a 64-bit mode. 30997 30998 -- Target Hook: scalar_int_mode TARGET_LIBGCC_CMP_RETURN_MODE (void) 30999 This target hook should return the mode to be used for the return 31000 value of compare instructions expanded to libgcc calls. If not 31001 defined 'word_mode' is returned which is the right choice for a 31002 majority of targets. 31003 31004 -- Target Hook: scalar_int_mode TARGET_LIBGCC_SHIFT_COUNT_MODE (void) 31005 This target hook should return the mode to be used for the shift 31006 count operand of shift instructions expanded to libgcc calls. If 31007 not defined 'word_mode' is returned which is the right choice for a 31008 majority of targets. 31009 31010 -- Target Hook: scalar_int_mode TARGET_UNWIND_WORD_MODE (void) 31011 Return machine mode to be used for '_Unwind_Word' type. The 31012 default is to use 'word_mode'. 31013 31014 -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (const_tree 31015 RECORD_TYPE) 31016 This target hook returns 'true' if bit-fields in the given 31017 RECORD_TYPE are to be laid out following the rules of Microsoft 31018 Visual C/C++, namely: (i) a bit-field won't share the same storage 31019 unit with the previous bit-field if their underlying types have 31020 different sizes, and the bit-field will be aligned to the highest 31021 alignment of the underlying types of itself and of the previous 31022 bit-field; (ii) a zero-sized bit-field will affect the alignment of 31023 the whole enclosing structure, even if it is unnamed; except that 31024 (iii) a zero-sized bit-field will be disregarded unless it follows 31025 another bit-field of nonzero size. If this hook returns 'true', 31026 other macros that control bit-field layout are ignored. 31027 31028 When a bit-field is inserted into a packed record, the whole size 31029 of the underlying type is used by one or more same-size adjacent 31030 bit-fields (that is, if its long:3, 32 bits is used in the record, 31031 and any additional adjacent long bit-fields are packed into the 31032 same chunk of 32 bits. However, if the size changes, a new field 31033 of that size is allocated). In an unpacked record, this is the 31034 same as using alignment, but not equivalent when packing. 31035 31036 If both MS bit-fields and '__attribute__((packed))' are used, the 31037 latter will take precedence. If '__attribute__((packed))' is used 31038 on a single field when MS bit-fields are in use, it will take 31039 precedence for that field, but the alignment of the rest of the 31040 structure may affect its placement. 31041 31042 -- Target Hook: bool TARGET_DECIMAL_FLOAT_SUPPORTED_P (void) 31043 Returns true if the target supports decimal floating point. 31044 31045 -- Target Hook: bool TARGET_FIXED_POINT_SUPPORTED_P (void) 31046 Returns true if the target supports fixed-point arithmetic. 31047 31048 -- Target Hook: void TARGET_EXPAND_TO_RTL_HOOK (void) 31049 This hook is called just before expansion into rtl, allowing the 31050 target to perform additional initializations or analysis before the 31051 expansion. For example, the rs6000 port uses it to allocate a 31052 scratch stack slot for use in copying SDmode values between memory 31053 and floating point registers whenever the function being expanded 31054 has any SDmode usage. 31055 31056 -- Target Hook: void TARGET_INSTANTIATE_DECLS (void) 31057 This hook allows the backend to perform additional instantiations 31058 on rtl that are not actually in any insns yet, but will be later. 31059 31060 -- Target Hook: const char * TARGET_MANGLE_TYPE (const_tree TYPE) 31061 If your target defines any fundamental types, or any types your 31062 target uses should be mangled differently from the default, define 31063 this hook to return the appropriate encoding for these types as 31064 part of a C++ mangled name. The TYPE argument is the tree 31065 structure representing the type to be mangled. The hook may be 31066 applied to trees which are not target-specific fundamental types; 31067 it should return 'NULL' for all such types, as well as arguments it 31068 does not recognize. If the return value is not 'NULL', it must 31069 point to a statically-allocated string constant. 31070 31071 Target-specific fundamental types might be new fundamental types or 31072 qualified versions of ordinary fundamental types. Encode new 31073 fundamental types as 'u N NAME', where NAME is the name used for 31074 the type in source code, and N is the length of NAME in decimal. 31075 Encode qualified versions of ordinary types as 'U N NAME CODE', 31076 where NAME is the name used for the type qualifier in source code, 31077 N is the length of NAME as above, and CODE is the code used to 31078 represent the unqualified version of this type. (See 31079 'write_builtin_type' in 'cp/mangle.c' for the list of codes.) In 31080 both cases the spaces are for clarity; do not include any spaces in 31081 your string. 31082 31083 This hook is applied to types prior to typedef resolution. If the 31084 mangled name for a particular type depends only on that type's main 31085 variant, you can perform typedef resolution yourself using 31086 'TYPE_MAIN_VARIANT' before mangling. 31087 31088 The default version of this hook always returns 'NULL', which is 31089 appropriate for a target that does not define any new fundamental 31090 types. 31091 31092 31093File: gccint.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros 31094 3109518.6 Layout of Source Language Data Types 31096========================================= 31097 31098These macros define the sizes and other characteristics of the standard 31099basic data types used in programs being compiled. Unlike the macros in 31100the previous section, these apply to specific features of C and related 31101languages, rather than to fundamental aspects of storage layout. 31102 31103 -- Macro: INT_TYPE_SIZE 31104 A C expression for the size in bits of the type 'int' on the target 31105 machine. If you don't define this, the default is one word. 31106 31107 -- Macro: SHORT_TYPE_SIZE 31108 A C expression for the size in bits of the type 'short' on the 31109 target machine. If you don't define this, the default is half a 31110 word. (If this would be less than one storage unit, it is rounded 31111 up to one unit.) 31112 31113 -- Macro: LONG_TYPE_SIZE 31114 A C expression for the size in bits of the type 'long' on the 31115 target machine. If you don't define this, the default is one word. 31116 31117 -- Macro: ADA_LONG_TYPE_SIZE 31118 On some machines, the size used for the Ada equivalent of the type 31119 'long' by a native Ada compiler differs from that used by C. In 31120 that situation, define this macro to be a C expression to be used 31121 for the size of that type. If you don't define this, the default 31122 is the value of 'LONG_TYPE_SIZE'. 31123 31124 -- Macro: LONG_LONG_TYPE_SIZE 31125 A C expression for the size in bits of the type 'long long' on the 31126 target machine. If you don't define this, the default is two 31127 words. If you want to support GNU Ada on your machine, the value 31128 of this macro must be at least 64. 31129 31130 -- Macro: CHAR_TYPE_SIZE 31131 A C expression for the size in bits of the type 'char' on the 31132 target machine. If you don't define this, the default is 31133 'BITS_PER_UNIT'. 31134 31135 -- Macro: BOOL_TYPE_SIZE 31136 A C expression for the size in bits of the C++ type 'bool' and C99 31137 type '_Bool' on the target machine. If you don't define this, and 31138 you probably shouldn't, the default is 'CHAR_TYPE_SIZE'. 31139 31140 -- Macro: FLOAT_TYPE_SIZE 31141 A C expression for the size in bits of the type 'float' on the 31142 target machine. If you don't define this, the default is one word. 31143 31144 -- Macro: DOUBLE_TYPE_SIZE 31145 A C expression for the size in bits of the type 'double' on the 31146 target machine. If you don't define this, the default is two 31147 words. 31148 31149 -- Macro: LONG_DOUBLE_TYPE_SIZE 31150 A C expression for the size in bits of the type 'long double' on 31151 the target machine. If you don't define this, the default is two 31152 words. 31153 31154 -- Macro: SHORT_FRACT_TYPE_SIZE 31155 A C expression for the size in bits of the type 'short _Fract' on 31156 the target machine. If you don't define this, the default is 31157 'BITS_PER_UNIT'. 31158 31159 -- Macro: FRACT_TYPE_SIZE 31160 A C expression for the size in bits of the type '_Fract' on the 31161 target machine. If you don't define this, the default is 31162 'BITS_PER_UNIT * 2'. 31163 31164 -- Macro: LONG_FRACT_TYPE_SIZE 31165 A C expression for the size in bits of the type 'long _Fract' on 31166 the target machine. If you don't define this, the default is 31167 'BITS_PER_UNIT * 4'. 31168 31169 -- Macro: LONG_LONG_FRACT_TYPE_SIZE 31170 A C expression for the size in bits of the type 'long long _Fract' 31171 on the target machine. If you don't define this, the default is 31172 'BITS_PER_UNIT * 8'. 31173 31174 -- Macro: SHORT_ACCUM_TYPE_SIZE 31175 A C expression for the size in bits of the type 'short _Accum' on 31176 the target machine. If you don't define this, the default is 31177 'BITS_PER_UNIT * 2'. 31178 31179 -- Macro: ACCUM_TYPE_SIZE 31180 A C expression for the size in bits of the type '_Accum' on the 31181 target machine. If you don't define this, the default is 31182 'BITS_PER_UNIT * 4'. 31183 31184 -- Macro: LONG_ACCUM_TYPE_SIZE 31185 A C expression for the size in bits of the type 'long _Accum' on 31186 the target machine. If you don't define this, the default is 31187 'BITS_PER_UNIT * 8'. 31188 31189 -- Macro: LONG_LONG_ACCUM_TYPE_SIZE 31190 A C expression for the size in bits of the type 'long long _Accum' 31191 on the target machine. If you don't define this, the default is 31192 'BITS_PER_UNIT * 16'. 31193 31194 -- Macro: LIBGCC2_GNU_PREFIX 31195 This macro corresponds to the 'TARGET_LIBFUNC_GNU_PREFIX' target 31196 hook and should be defined if that hook is overriden to be true. 31197 It causes function names in libgcc to be changed to use a '__gnu_' 31198 prefix for their name rather than the default '__'. A port which 31199 uses this macro should also arrange to use 't-gnu-prefix' in the 31200 libgcc 'config.host'. 31201 31202 -- Macro: WIDEST_HARDWARE_FP_SIZE 31203 A C expression for the size in bits of the widest floating-point 31204 format supported by the hardware. If you define this macro, you 31205 must specify a value less than or equal to the value of 31206 'LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the 31207 value of 'LONG_DOUBLE_TYPE_SIZE' is the default. 31208 31209 -- Macro: DEFAULT_SIGNED_CHAR 31210 An expression whose value is 1 or 0, according to whether the type 31211 'char' should be signed or unsigned by default. The user can 31212 always override this default with the options '-fsigned-char' and 31213 '-funsigned-char'. 31214 31215 -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void) 31216 This target hook should return true if the compiler should give an 31217 'enum' type only as many bytes as it takes to represent the range 31218 of possible values of that type. It should return false if all 31219 'enum' types should be allocated like 'int'. 31220 31221 The default is to return false. 31222 31223 -- Macro: SIZE_TYPE 31224 A C expression for a string describing the name of the data type to 31225 use for size values. The typedef name 'size_t' is defined using 31226 the contents of the string. 31227 31228 The string can contain more than one keyword. If so, separate them 31229 with spaces, and write first any length keyword, then 'unsigned' if 31230 appropriate, and finally 'int'. The string must exactly match one 31231 of the data type names defined in the function 31232 'c_common_nodes_and_builtins' in the file 'c-family/c-common.c'. 31233 You may not omit 'int' or change the order--that would cause the 31234 compiler to crash on startup. 31235 31236 If you don't define this macro, the default is '"long unsigned 31237 int"'. 31238 31239 -- Macro: SIZETYPE 31240 GCC defines internal types ('sizetype', 'ssizetype', 'bitsizetype' 31241 and 'sbitsizetype') for expressions dealing with size. This macro 31242 is a C expression for a string describing the name of the data type 31243 from which the precision of 'sizetype' is extracted. 31244 31245 The string has the same restrictions as 'SIZE_TYPE' string. 31246 31247 If you don't define this macro, the default is 'SIZE_TYPE'. 31248 31249 -- Macro: PTRDIFF_TYPE 31250 A C expression for a string describing the name of the data type to 31251 use for the result of subtracting two pointers. The typedef name 31252 'ptrdiff_t' is defined using the contents of the string. See 31253 'SIZE_TYPE' above for more information. 31254 31255 If you don't define this macro, the default is '"long int"'. 31256 31257 -- Macro: WCHAR_TYPE 31258 A C expression for a string describing the name of the data type to 31259 use for wide characters. The typedef name 'wchar_t' is defined 31260 using the contents of the string. See 'SIZE_TYPE' above for more 31261 information. 31262 31263 If you don't define this macro, the default is '"int"'. 31264 31265 -- Macro: WCHAR_TYPE_SIZE 31266 A C expression for the size in bits of the data type for wide 31267 characters. This is used in 'cpp', which cannot make use of 31268 'WCHAR_TYPE'. 31269 31270 -- Macro: WINT_TYPE 31271 A C expression for a string describing the name of the data type to 31272 use for wide characters passed to 'printf' and returned from 31273 'getwc'. The typedef name 'wint_t' is defined using the contents 31274 of the string. See 'SIZE_TYPE' above for more information. 31275 31276 If you don't define this macro, the default is '"unsigned int"'. 31277 31278 -- Macro: INTMAX_TYPE 31279 A C expression for a string describing the name of the data type 31280 that can represent any value of any standard or extended signed 31281 integer type. The typedef name 'intmax_t' is defined using the 31282 contents of the string. See 'SIZE_TYPE' above for more 31283 information. 31284 31285 If you don't define this macro, the default is the first of 31286 '"int"', '"long int"', or '"long long int"' that has as much 31287 precision as 'long long int'. 31288 31289 -- Macro: UINTMAX_TYPE 31290 A C expression for a string describing the name of the data type 31291 that can represent any value of any standard or extended unsigned 31292 integer type. The typedef name 'uintmax_t' is defined using the 31293 contents of the string. See 'SIZE_TYPE' above for more 31294 information. 31295 31296 If you don't define this macro, the default is the first of 31297 '"unsigned int"', '"long unsigned int"', or '"long long unsigned 31298 int"' that has as much precision as 'long long unsigned int'. 31299 31300 -- Macro: SIG_ATOMIC_TYPE 31301 -- Macro: INT8_TYPE 31302 -- Macro: INT16_TYPE 31303 -- Macro: INT32_TYPE 31304 -- Macro: INT64_TYPE 31305 -- Macro: UINT8_TYPE 31306 -- Macro: UINT16_TYPE 31307 -- Macro: UINT32_TYPE 31308 -- Macro: UINT64_TYPE 31309 -- Macro: INT_LEAST8_TYPE 31310 -- Macro: INT_LEAST16_TYPE 31311 -- Macro: INT_LEAST32_TYPE 31312 -- Macro: INT_LEAST64_TYPE 31313 -- Macro: UINT_LEAST8_TYPE 31314 -- Macro: UINT_LEAST16_TYPE 31315 -- Macro: UINT_LEAST32_TYPE 31316 -- Macro: UINT_LEAST64_TYPE 31317 -- Macro: INT_FAST8_TYPE 31318 -- Macro: INT_FAST16_TYPE 31319 -- Macro: INT_FAST32_TYPE 31320 -- Macro: INT_FAST64_TYPE 31321 -- Macro: UINT_FAST8_TYPE 31322 -- Macro: UINT_FAST16_TYPE 31323 -- Macro: UINT_FAST32_TYPE 31324 -- Macro: UINT_FAST64_TYPE 31325 -- Macro: INTPTR_TYPE 31326 -- Macro: UINTPTR_TYPE 31327 C expressions for the standard types 'sig_atomic_t', 'int8_t', 31328 'int16_t', 'int32_t', 'int64_t', 'uint8_t', 'uint16_t', 'uint32_t', 31329 'uint64_t', 'int_least8_t', 'int_least16_t', 'int_least32_t', 31330 'int_least64_t', 'uint_least8_t', 'uint_least16_t', 31331 'uint_least32_t', 'uint_least64_t', 'int_fast8_t', 'int_fast16_t', 31332 'int_fast32_t', 'int_fast64_t', 'uint_fast8_t', 'uint_fast16_t', 31333 'uint_fast32_t', 'uint_fast64_t', 'intptr_t', and 'uintptr_t'. See 31334 'SIZE_TYPE' above for more information. 31335 31336 If any of these macros evaluates to a null pointer, the 31337 corresponding type is not supported; if GCC is configured to 31338 provide '<stdint.h>' in such a case, the header provided may not 31339 conform to C99, depending on the type in question. The defaults 31340 for all of these macros are null pointers. 31341 31342 -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION 31343 The C++ compiler represents a pointer-to-member-function with a 31344 struct that looks like: 31345 31346 struct { 31347 union { 31348 void (*fn)(); 31349 ptrdiff_t vtable_index; 31350 }; 31351 ptrdiff_t delta; 31352 }; 31353 31354 The C++ compiler must use one bit to indicate whether the function 31355 that will be called through a pointer-to-member-function is 31356 virtual. Normally, we assume that the low-order bit of a function 31357 pointer must always be zero. Then, by ensuring that the 31358 vtable_index is odd, we can distinguish which variant of the union 31359 is in use. But, on some platforms function pointers can be odd, 31360 and so this doesn't work. In that case, we use the low-order bit 31361 of the 'delta' field, and shift the remainder of the 'delta' field 31362 to the left. 31363 31364 GCC will automatically make the right selection about where to 31365 store this bit using the 'FUNCTION_BOUNDARY' setting for your 31366 platform. However, some platforms such as ARM/Thumb have 31367 'FUNCTION_BOUNDARY' set such that functions always start at even 31368 addresses, but the lowest bit of pointers to functions indicate 31369 whether the function at that address is in ARM or Thumb mode. If 31370 this is the case of your architecture, you should define this macro 31371 to 'ptrmemfunc_vbit_in_delta'. 31372 31373 In general, you should not have to define this macro. On 31374 architectures in which function addresses are always even, 31375 according to 'FUNCTION_BOUNDARY', GCC will automatically define 31376 this macro to 'ptrmemfunc_vbit_in_pfn'. 31377 31378 -- Macro: TARGET_VTABLE_USES_DESCRIPTORS 31379 Normally, the C++ compiler uses function pointers in vtables. This 31380 macro allows the target to change to use "function descriptors" 31381 instead. Function descriptors are found on targets for whom a 31382 function pointer is actually a small data structure. Normally the 31383 data structure consists of the actual code address plus a data 31384 pointer to which the function's data is relative. 31385 31386 If vtables are used, the value of this macro should be the number 31387 of words that the function descriptor occupies. 31388 31389 -- Macro: TARGET_VTABLE_ENTRY_ALIGN 31390 By default, the vtable entries are void pointers, the so the 31391 alignment is the same as pointer alignment. The value of this 31392 macro specifies the alignment of the vtable entry in bits. It 31393 should be defined only when special alignment is necessary. */ 31394 31395 -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE 31396 There are a few non-descriptor entries in the vtable at offsets 31397 below zero. If these entries must be padded (say, to preserve the 31398 alignment specified by 'TARGET_VTABLE_ENTRY_ALIGN'), set this to 31399 the number of words in each data entry. 31400 31401 31402File: gccint.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros 31403 3140418.7 Register Usage 31405=================== 31406 31407This section explains how to describe what registers the target machine 31408has, and how (in general) they can be used. 31409 31410 The description of which registers a specific instruction can use is 31411done with register classes; see *note Register Classes::. For 31412information on using registers to access a stack frame, see *note Frame 31413Registers::. For passing values in registers, see *note Register 31414Arguments::. For returning values in registers, see *note Scalar 31415Return::. 31416 31417* Menu: 31418 31419* Register Basics:: Number and kinds of registers. 31420* Allocation Order:: Order in which registers are allocated. 31421* Values in Registers:: What kinds of values each reg can hold. 31422* Leaf Functions:: Renumbering registers for leaf functions. 31423* Stack Registers:: Handling a register stack such as 80387. 31424 31425 31426File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers 31427 3142818.7.1 Basic Characteristics of Registers 31429----------------------------------------- 31430 31431Registers have various characteristics. 31432 31433 -- Macro: FIRST_PSEUDO_REGISTER 31434 Number of hardware registers known to the compiler. They receive 31435 numbers 0 through 'FIRST_PSEUDO_REGISTER-1'; thus, the first pseudo 31436 register's number really is assigned the number 31437 'FIRST_PSEUDO_REGISTER'. 31438 31439 -- Macro: FIXED_REGISTERS 31440 An initializer that says which registers are used for fixed 31441 purposes all throughout the compiled code and are therefore not 31442 available for general allocation. These would include the stack 31443 pointer, the frame pointer (except on machines where that can be 31444 used as a general register when no frame pointer is needed), the 31445 program counter on machines where that is considered one of the 31446 addressable registers, and any other numbered register with a 31447 standard use. 31448 31449 This information is expressed as a sequence of numbers, separated 31450 by commas and surrounded by braces. The Nth number is 1 if 31451 register N is fixed, 0 otherwise. 31452 31453 The table initialized from this macro, and the table initialized by 31454 the following one, may be overridden at run time either 31455 automatically, by the actions of the macro 31456 'CONDITIONAL_REGISTER_USAGE', or by the user with the command 31457 options '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG'. 31458 31459 -- Macro: CALL_USED_REGISTERS 31460 Like 'FIXED_REGISTERS' but has 1 for each register that is 31461 clobbered (in general) by function calls as well as for fixed 31462 registers. This macro therefore identifies the registers that are 31463 not available for general allocation of values that must live 31464 across function calls. 31465 31466 If a register has 0 in 'CALL_USED_REGISTERS', the compiler 31467 automatically saves it on function entry and restores it on 31468 function exit, if the register is used within the function. 31469 31470 -- Macro: CALL_REALLY_USED_REGISTERS 31471 Like 'CALL_USED_REGISTERS' except this macro doesn't require that 31472 the entire set of 'FIXED_REGISTERS' be included. 31473 ('CALL_USED_REGISTERS' must be a superset of 'FIXED_REGISTERS'). 31474 This macro is optional. If not specified, it defaults to the value 31475 of 'CALL_USED_REGISTERS'. 31476 31477 -- Target Hook: bool TARGET_HARD_REGNO_CALL_PART_CLOBBERED (unsigned 31478 int REGNO, machine_mode MODE) 31479 This hook should return true if REGNO is partly call-saved and 31480 partly call-clobbered, and if a value of mode MODE would be partly 31481 clobbered by a call. For example, if the low 32 bits of REGNO are 31482 preserved across a call but higher bits are clobbered, this hook 31483 should return true for a 64-bit mode but false for a 32-bit mode. 31484 31485 The default implementation returns false, which is correct for 31486 targets that don't have partly call-clobbered registers. 31487 31488 -- Target Hook: void TARGET_CONDITIONAL_REGISTER_USAGE (void) 31489 This hook may conditionally modify five variables 'fixed_regs', 31490 'call_used_regs', 'global_regs', 'reg_names', and 31491 'reg_class_contents', to take into account any dependence of these 31492 register sets on target flags. The first three of these are of 31493 type 'char []' (interpreted as boolean vectors). 'global_regs' is 31494 a 'const char *[]', and 'reg_class_contents' is a 'HARD_REG_SET'. 31495 Before the macro is called, 'fixed_regs', 'call_used_regs', 31496 'reg_class_contents', and 'reg_names' have been initialized from 31497 'FIXED_REGISTERS', 'CALL_USED_REGISTERS', 'REG_CLASS_CONTENTS', and 31498 'REGISTER_NAMES', respectively. 'global_regs' has been cleared, 31499 and any '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG' 31500 command options have been applied. 31501 31502 If the usage of an entire class of registers depends on the target 31503 flags, you may indicate this to GCC by using this macro to modify 31504 'fixed_regs' and 'call_used_regs' to 1 for each of the registers in 31505 the classes which should not be used by GCC. Also make 31506 'define_register_constraint's return 'NO_REGS' for constraints that 31507 shouldn't be used. 31508 31509 (However, if this class is not included in 'GENERAL_REGS' and all 31510 of the insn patterns whose constraints permit this class are 31511 controlled by target switches, then GCC will automatically avoid 31512 using these registers when the target switches are opposed to 31513 them.) 31514 31515 -- Macro: INCOMING_REGNO (OUT) 31516 Define this macro if the target machine has register windows. This 31517 C expression returns the register number as seen by the called 31518 function corresponding to the register number OUT as seen by the 31519 calling function. Return OUT if register number OUT is not an 31520 outbound register. 31521 31522 -- Macro: OUTGOING_REGNO (IN) 31523 Define this macro if the target machine has register windows. This 31524 C expression returns the register number as seen by the calling 31525 function corresponding to the register number IN as seen by the 31526 called function. Return IN if register number IN is not an inbound 31527 register. 31528 31529 -- Macro: LOCAL_REGNO (REGNO) 31530 Define this macro if the target machine has register windows. This 31531 C expression returns true if the register is call-saved but is in 31532 the register window. Unlike most call-saved registers, such 31533 registers need not be explicitly restored on function exit or 31534 during non-local gotos. 31535 31536 -- Macro: PC_REGNUM 31537 If the program counter has a register number, define this as that 31538 register number. Otherwise, do not define it. 31539 31540 31541File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers 31542 3154318.7.2 Order of Allocation of Registers 31544--------------------------------------- 31545 31546Registers are allocated in order. 31547 31548 -- Macro: REG_ALLOC_ORDER 31549 If defined, an initializer for a vector of integers, containing the 31550 numbers of hard registers in the order in which GCC should prefer 31551 to use them (from most preferred to least). 31552 31553 If this macro is not defined, registers are used lowest numbered 31554 first (all else being equal). 31555 31556 One use of this macro is on machines where the highest numbered 31557 registers must always be saved and the save-multiple-registers 31558 instruction supports only sequences of consecutive registers. On 31559 such machines, define 'REG_ALLOC_ORDER' to be an initializer that 31560 lists the highest numbered allocable register first. 31561 31562 -- Macro: ADJUST_REG_ALLOC_ORDER 31563 A C statement (sans semicolon) to choose the order in which to 31564 allocate hard registers for pseudo-registers local to a basic 31565 block. 31566 31567 Store the desired register order in the array 'reg_alloc_order'. 31568 Element 0 should be the register to allocate first; element 1, the 31569 next register; and so on. 31570 31571 The macro body should not assume anything about the contents of 31572 'reg_alloc_order' before execution of the macro. 31573 31574 On most machines, it is not necessary to define this macro. 31575 31576 -- Macro: HONOR_REG_ALLOC_ORDER 31577 Normally, IRA tries to estimate the costs for saving a register in 31578 the prologue and restoring it in the epilogue. This discourages it 31579 from using call-saved registers. If a machine wants to ensure that 31580 IRA allocates registers in the order given by REG_ALLOC_ORDER even 31581 if some call-saved registers appear earlier than call-used ones, 31582 then define this macro as a C expression to nonzero. Default is 0. 31583 31584 -- Macro: IRA_HARD_REGNO_ADD_COST_MULTIPLIER (REGNO) 31585 In some case register allocation order is not enough for the 31586 Integrated Register Allocator (IRA) to generate a good code. If 31587 this macro is defined, it should return a floating point value 31588 based on REGNO. The cost of using REGNO for a pseudo will be 31589 increased by approximately the pseudo's usage frequency times the 31590 value returned by this macro. Not defining this macro is 31591 equivalent to having it always return '0.0'. 31592 31593 On most machines, it is not necessary to define this macro. 31594 31595 31596File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers 31597 3159818.7.3 How Values Fit in Registers 31599---------------------------------- 31600 31601This section discusses the macros that describe which kinds of values 31602(specifically, which machine modes) each register can hold, and how many 31603consecutive registers are needed for a given mode. 31604 31605 -- Target Hook: unsigned int TARGET_HARD_REGNO_NREGS (unsigned int 31606 REGNO, machine_mode MODE) 31607 This hook returns the number of consecutive hard registers, 31608 starting at register number REGNO, required to hold a value of mode 31609 MODE. This hook must never return zero, even if a register cannot 31610 hold the requested mode - indicate that with 31611 'TARGET_HARD_REGNO_MODE_OK' and/or 'TARGET_CAN_CHANGE_MODE_CLASS' 31612 instead. 31613 31614 The default definition returns the number of words in MODE. 31615 31616 -- Macro: HARD_REGNO_NREGS_HAS_PADDING (REGNO, MODE) 31617 A C expression that is nonzero if a value of mode MODE, stored in 31618 memory, ends with padding that causes it to take up more space than 31619 in registers starting at register number REGNO (as determined by 31620 multiplying GCC's notion of the size of the register when 31621 containing this mode by the number of registers returned by 31622 'TARGET_HARD_REGNO_NREGS'). By default this is zero. 31623 31624 For example, if a floating-point value is stored in three 32-bit 31625 registers but takes up 128 bits in memory, then this would be 31626 nonzero. 31627 31628 This macros only needs to be defined if there are cases where 31629 'subreg_get_info' would otherwise wrongly determine that a 'subreg' 31630 can be represented by an offset to the register number, when in 31631 fact such a 'subreg' would contain some of the padding not stored 31632 in registers and so not be representable. 31633 31634 -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE) 31635 For values of REGNO and MODE for which 31636 'HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression 31637 returning the greater number of registers required to hold the 31638 value including any padding. In the example above, the value would 31639 be four. 31640 31641 -- Macro: REGMODE_NATURAL_SIZE (MODE) 31642 Define this macro if the natural size of registers that hold values 31643 of mode MODE is not the word size. It is a C expression that 31644 should give the natural size in bytes for the specified mode. It 31645 is used by the register allocator to try to optimize its results. 31646 This happens for example on SPARC 64-bit where the natural size of 31647 floating-point registers is still 32-bit. 31648 31649 -- Target Hook: bool TARGET_HARD_REGNO_MODE_OK (unsigned int REGNO, 31650 machine_mode MODE) 31651 This hook returns true if it is permissible to store a value of 31652 mode MODE in hard register number REGNO (or in several registers 31653 starting with that one). The default definition returns true 31654 unconditionally. 31655 31656 You need not include code to check for the numbers of fixed 31657 registers, because the allocation mechanism considers them to be 31658 always occupied. 31659 31660 On some machines, double-precision values must be kept in even/odd 31661 register pairs. You can implement that by defining this hook to 31662 reject odd register numbers for such modes. 31663 31664 The minimum requirement for a mode to be OK in a register is that 31665 the 'movMODE' instruction pattern support moves between the 31666 register and other hard register in the same class and that moving 31667 a value into the register and back out not alter it. 31668 31669 Since the same instruction used to move 'word_mode' will work for 31670 all narrower integer modes, it is not necessary on any machine for 31671 this hook to distinguish between these modes, provided you define 31672 patterns 'movhi', etc., to take advantage of this. This is useful 31673 because of the interaction between 'TARGET_HARD_REGNO_MODE_OK' and 31674 'TARGET_MODES_TIEABLE_P'; it is very desirable for all integer 31675 modes to be tieable. 31676 31677 Many machines have special registers for floating point arithmetic. 31678 Often people assume that floating point machine modes are allowed 31679 only in floating point registers. This is not true. Any registers 31680 that can hold integers can safely _hold_ a floating point machine 31681 mode, whether or not floating arithmetic can be done on it in those 31682 registers. Integer move instructions can be used to move the 31683 values. 31684 31685 On some machines, though, the converse is true: fixed-point machine 31686 modes may not go in floating registers. This is true if the 31687 floating registers normalize any value stored in them, because 31688 storing a non-floating value there would garble it. In this case, 31689 'TARGET_HARD_REGNO_MODE_OK' should reject fixed-point machine modes 31690 in floating registers. But if the floating registers do not 31691 automatically normalize, if you can store any bit pattern in one 31692 and retrieve it unchanged without a trap, then any machine mode may 31693 go in a floating register, so you can define this hook to say so. 31694 31695 The primary significance of special floating registers is rather 31696 that they are the registers acceptable in floating point arithmetic 31697 instructions. However, this is of no concern to 31698 'TARGET_HARD_REGNO_MODE_OK'. You handle it by writing the proper 31699 constraints for those instructions. 31700 31701 On some machines, the floating registers are especially slow to 31702 access, so that it is better to store a value in a stack frame than 31703 in such a register if floating point arithmetic is not being done. 31704 As long as the floating registers are not in class 'GENERAL_REGS', 31705 they will not be used unless some pattern's constraint asks for 31706 one. 31707 31708 -- Macro: HARD_REGNO_RENAME_OK (FROM, TO) 31709 A C expression that is nonzero if it is OK to rename a hard 31710 register FROM to another hard register TO. 31711 31712 One common use of this macro is to prevent renaming of a register 31713 to another register that is not saved by a prologue in an interrupt 31714 handler. 31715 31716 The default is always nonzero. 31717 31718 -- Target Hook: bool TARGET_MODES_TIEABLE_P (machine_mode MODE1, 31719 machine_mode MODE2) 31720 This hook returns true if a value of mode MODE1 is accessible in 31721 mode MODE2 without copying. 31722 31723 If 'TARGET_HARD_REGNO_MODE_OK (R, MODE1)' and 31724 'TARGET_HARD_REGNO_MODE_OK (R, MODE2)' are always the same for any 31725 R, then 'TARGET_MODES_TIEABLE_P (MODE1, MODE2)' should be true. If 31726 they differ for any R, you should define this hook to return false 31727 unless some other mechanism ensures the accessibility of the value 31728 in a narrower mode. 31729 31730 You should define this hook to return true in as many cases as 31731 possible since doing so will allow GCC to perform better register 31732 allocation. The default definition returns true unconditionally. 31733 31734 -- Target Hook: bool TARGET_HARD_REGNO_SCRATCH_OK (unsigned int REGNO) 31735 This target hook should return 'true' if it is OK to use a hard 31736 register REGNO as scratch reg in peephole2. 31737 31738 One common use of this macro is to prevent using of a register that 31739 is not saved by a prologue in an interrupt handler. 31740 31741 The default version of this hook always returns 'true'. 31742 31743 -- Macro: AVOID_CCMODE_COPIES 31744 Define this macro if the compiler should avoid copies to/from 31745 'CCmode' registers. You should only define this macro if support 31746 for copying to/from 'CCmode' is incomplete. 31747 31748 31749File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers 31750 3175118.7.4 Handling Leaf Functions 31752------------------------------ 31753 31754On some machines, a leaf function (i.e., one which makes no calls) can 31755run more efficiently if it does not make its own register window. Often 31756this means it is required to receive its arguments in the registers 31757where they are passed by the caller, instead of the registers where they 31758would normally arrive. 31759 31760 The special treatment for leaf functions generally applies only when 31761other conditions are met; for example, often they may use only those 31762registers for its own variables and temporaries. We use the term "leaf 31763function" to mean a function that is suitable for this special handling, 31764so that functions with no calls are not necessarily "leaf functions". 31765 31766 GCC assigns register numbers before it knows whether the function is 31767suitable for leaf function treatment. So it needs to renumber the 31768registers in order to output a leaf function. The following macros 31769accomplish this. 31770 31771 -- Macro: LEAF_REGISTERS 31772 Name of a char vector, indexed by hard register number, which 31773 contains 1 for a register that is allowable in a candidate for leaf 31774 function treatment. 31775 31776 If leaf function treatment involves renumbering the registers, then 31777 the registers marked here should be the ones before 31778 renumbering--those that GCC would ordinarily allocate. The 31779 registers which will actually be used in the assembler code, after 31780 renumbering, should not be marked with 1 in this vector. 31781 31782 Define this macro only if the target machine offers a way to 31783 optimize the treatment of leaf functions. 31784 31785 -- Macro: LEAF_REG_REMAP (REGNO) 31786 A C expression whose value is the register number to which REGNO 31787 should be renumbered, when a function is treated as a leaf 31788 function. 31789 31790 If REGNO is a register number which should not appear in a leaf 31791 function before renumbering, then the expression should yield -1, 31792 which will cause the compiler to abort. 31793 31794 Define this macro only if the target machine offers a way to 31795 optimize the treatment of leaf functions, and registers need to be 31796 renumbered to do this. 31797 31798 'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE' must 31799usually treat leaf functions specially. They can test the C variable 31800'current_function_is_leaf' which is nonzero for leaf functions. 31801'current_function_is_leaf' is set prior to local register allocation and 31802is valid for the remaining compiler passes. They can also test the C 31803variable 'current_function_uses_only_leaf_regs' which is nonzero for 31804leaf functions which only use leaf registers. 31805'current_function_uses_only_leaf_regs' is valid after all passes that 31806modify the instructions have been run and is only useful if 31807'LEAF_REGISTERS' is defined. 31808 31809 31810File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers 31811 3181218.7.5 Registers That Form a Stack 31813---------------------------------- 31814 31815There are special features to handle computers where some of the 31816"registers" form a stack. Stack registers are normally written by 31817pushing onto the stack, and are numbered relative to the top of the 31818stack. 31819 31820 Currently, GCC can only handle one group of stack-like registers, and 31821they must be consecutively numbered. Furthermore, the existing support 31822for stack-like registers is specific to the 80387 floating point 31823coprocessor. If you have a new architecture that uses stack-like 31824registers, you will need to do substantial work on 'reg-stack.c' and 31825write your machine description to cooperate with it, as well as defining 31826these macros. 31827 31828 -- Macro: STACK_REGS 31829 Define this if the machine has any stack-like registers. 31830 31831 -- Macro: STACK_REG_COVER_CLASS 31832 This is a cover class containing the stack registers. Define this 31833 if the machine has any stack-like registers. 31834 31835 -- Macro: FIRST_STACK_REG 31836 The number of the first stack-like register. This one is the top 31837 of the stack. 31838 31839 -- Macro: LAST_STACK_REG 31840 The number of the last stack-like register. This one is the bottom 31841 of the stack. 31842 31843 31844File: gccint.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros 31845 3184618.8 Register Classes 31847===================== 31848 31849On many machines, the numbered registers are not all equivalent. For 31850example, certain registers may not be allowed for indexed addressing; 31851certain registers may not be allowed in some instructions. These 31852machine restrictions are described to the compiler using "register 31853classes". 31854 31855 You define a number of register classes, giving each one a name and 31856saying which of the registers belong to it. Then you can specify 31857register classes that are allowed as operands to particular instruction 31858patterns. 31859 31860 In general, each register will belong to several classes. In fact, one 31861class must be named 'ALL_REGS' and contain all the registers. Another 31862class must be named 'NO_REGS' and contain no registers. Often the union 31863of two classes will be another class; however, this is not required. 31864 31865 One of the classes must be named 'GENERAL_REGS'. There is nothing 31866terribly special about the name, but the operand constraint letters 'r' 31867and 'g' specify this class. If 'GENERAL_REGS' is the same as 31868'ALL_REGS', just define it as a macro which expands to 'ALL_REGS'. 31869 31870 Order the classes so that if class X is contained in class Y then X has 31871a lower class number than Y. 31872 31873 The way classes other than 'GENERAL_REGS' are specified in operand 31874constraints is through machine-dependent operand constraint letters. 31875You can define such letters to correspond to various classes, then use 31876them in operand constraints. 31877 31878 You must define the narrowest register classes for allocatable 31879registers, so that each class either has no subclasses, or that for some 31880mode, the move cost between registers within the class is cheaper than 31881moving a register in the class to or from memory (*note Costs::). 31882 31883 You should define a class for the union of two classes whenever some 31884instruction allows both classes. For example, if an instruction allows 31885either a floating point (coprocessor) register or a general register for 31886a certain operand, you should define a class 'FLOAT_OR_GENERAL_REGS' 31887which includes both of them. Otherwise you will get suboptimal code, or 31888even internal compiler errors when reload cannot find a register in the 31889class computed via 'reg_class_subunion'. 31890 31891 You must also specify certain redundant information about the register 31892classes: for each class, which classes contain it and which ones are 31893contained in it; for each pair of classes, the largest class contained 31894in their union. 31895 31896 When a value occupying several consecutive registers is expected in a 31897certain class, all the registers used must belong to that class. 31898Therefore, register classes cannot be used to enforce a requirement for 31899a register pair to start with an even-numbered register. The way to 31900specify this requirement is with 'TARGET_HARD_REGNO_MODE_OK'. 31901 31902 Register classes used for input-operands of bitwise-and or shift 31903instructions have a special requirement: each such class must have, for 31904each fixed-point machine mode, a subclass whose registers can transfer 31905that mode to or from memory. For example, on some machines, the 31906operations for single-byte values ('QImode') are limited to certain 31907registers. When this is so, each register class that is used in a 31908bitwise-and or shift instruction must have a subclass consisting of 31909registers from which single-byte values can be loaded or stored. This 31910is so that 'PREFERRED_RELOAD_CLASS' can always have a possible value to 31911return. 31912 31913 -- Data type: enum reg_class 31914 An enumerated type that must be defined with all the register class 31915 names as enumerated values. 'NO_REGS' must be first. 'ALL_REGS' 31916 must be the last register class, followed by one more enumerated 31917 value, 'LIM_REG_CLASSES', which is not a register class but rather 31918 tells how many classes there are. 31919 31920 Each register class has a number, which is the value of casting the 31921 class name to type 'int'. The number serves as an index in many of 31922 the tables described below. 31923 31924 -- Macro: N_REG_CLASSES 31925 The number of distinct register classes, defined as follows: 31926 31927 #define N_REG_CLASSES (int) LIM_REG_CLASSES 31928 31929 -- Macro: REG_CLASS_NAMES 31930 An initializer containing the names of the register classes as C 31931 string constants. These names are used in writing some of the 31932 debugging dumps. 31933 31934 -- Macro: REG_CLASS_CONTENTS 31935 An initializer containing the contents of the register classes, as 31936 integers which are bit masks. The Nth integer specifies the 31937 contents of class N. The way the integer MASK is interpreted is 31938 that register R is in the class if 'MASK & (1 << R)' is 1. 31939 31940 When the machine has more than 32 registers, an integer does not 31941 suffice. Then the integers are replaced by sub-initializers, 31942 braced groupings containing several integers. Each sub-initializer 31943 must be suitable as an initializer for the type 'HARD_REG_SET' 31944 which is defined in 'hard-reg-set.h'. In this situation, the first 31945 integer in each sub-initializer corresponds to registers 0 through 31946 31, the second integer to registers 32 through 63, and so on. 31947 31948 -- Macro: REGNO_REG_CLASS (REGNO) 31949 A C expression whose value is a register class containing hard 31950 register REGNO. In general there is more than one such class; 31951 choose a class which is "minimal", meaning that no smaller class 31952 also contains the register. 31953 31954 -- Macro: BASE_REG_CLASS 31955 A macro whose definition is the name of the class to which a valid 31956 base register must belong. A base register is one used in an 31957 address which is the register value plus a displacement. 31958 31959 -- Macro: MODE_BASE_REG_CLASS (MODE) 31960 This is a variation of the 'BASE_REG_CLASS' macro which allows the 31961 selection of a base register in a mode dependent manner. If MODE 31962 is VOIDmode then it should return the same value as 31963 'BASE_REG_CLASS'. 31964 31965 -- Macro: MODE_BASE_REG_REG_CLASS (MODE) 31966 A C expression whose value is the register class to which a valid 31967 base register must belong in order to be used in a base plus index 31968 register address. You should define this macro if base plus index 31969 addresses have different requirements than other base register 31970 uses. 31971 31972 -- Macro: MODE_CODE_BASE_REG_CLASS (MODE, ADDRESS_SPACE, OUTER_CODE, 31973 INDEX_CODE) 31974 A C expression whose value is the register class to which a valid 31975 base register for a memory reference in mode MODE to address space 31976 ADDRESS_SPACE must belong. OUTER_CODE and INDEX_CODE define the 31977 context in which the base register occurs. OUTER_CODE is the code 31978 of the immediately enclosing expression ('MEM' for the top level of 31979 an address, 'ADDRESS' for something that occurs in an 31980 'address_operand'). INDEX_CODE is the code of the corresponding 31981 index expression if OUTER_CODE is 'PLUS'; 'SCRATCH' otherwise. 31982 31983 -- Macro: INDEX_REG_CLASS 31984 A macro whose definition is the name of the class to which a valid 31985 index register must belong. An index register is one used in an 31986 address where its value is either multiplied by a scale factor or 31987 added to another register (as well as added to a displacement). 31988 31989 -- Macro: REGNO_OK_FOR_BASE_P (NUM) 31990 A C expression which is nonzero if register number NUM is suitable 31991 for use as a base register in operand addresses. 31992 31993 -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE) 31994 A C expression that is just like 'REGNO_OK_FOR_BASE_P', except that 31995 that expression may examine the mode of the memory reference in 31996 MODE. You should define this macro if the mode of the memory 31997 reference affects whether a register may be used as a base 31998 register. If you define this macro, the compiler will use it 31999 instead of 'REGNO_OK_FOR_BASE_P'. The mode may be 'VOIDmode' for 32000 addresses that appear outside a 'MEM', i.e., as an 32001 'address_operand'. 32002 32003 -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE) 32004 A C expression which is nonzero if register number NUM is suitable 32005 for use as a base register in base plus index operand addresses, 32006 accessing memory in mode MODE. It may be either a suitable hard 32007 register or a pseudo register that has been allocated such a hard 32008 register. You should define this macro if base plus index 32009 addresses have different requirements than other base register 32010 uses. 32011 32012 Use of this macro is deprecated; please use the more general 32013 'REGNO_MODE_CODE_OK_FOR_BASE_P'. 32014 32015 -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, ADDRESS_SPACE, 32016 OUTER_CODE, INDEX_CODE) 32017 A C expression which is nonzero if register number NUM is suitable 32018 for use as a base register in operand addresses, accessing memory 32019 in mode MODE in address space ADDRESS_SPACE. This is similar to 32020 'REGNO_MODE_OK_FOR_BASE_P', except that that expression may examine 32021 the context in which the register appears in the memory reference. 32022 OUTER_CODE is the code of the immediately enclosing expression 32023 ('MEM' if at the top level of the address, 'ADDRESS' for something 32024 that occurs in an 'address_operand'). INDEX_CODE is the code of 32025 the corresponding index expression if OUTER_CODE is 'PLUS'; 32026 'SCRATCH' otherwise. The mode may be 'VOIDmode' for addresses that 32027 appear outside a 'MEM', i.e., as an 'address_operand'. 32028 32029 -- Macro: REGNO_OK_FOR_INDEX_P (NUM) 32030 A C expression which is nonzero if register number NUM is suitable 32031 for use as an index register in operand addresses. It may be 32032 either a suitable hard register or a pseudo register that has been 32033 allocated such a hard register. 32034 32035 The difference between an index register and a base register is 32036 that the index register may be scaled. If an address involves the 32037 sum of two registers, neither one of them scaled, then either one 32038 may be labeled the "base" and the other the "index"; but whichever 32039 labeling is used must fit the machine's constraints of which 32040 registers may serve in each capacity. The compiler will try both 32041 labelings, looking for one that is valid, and will reload one or 32042 both registers only if neither labeling works. 32043 32044 -- Target Hook: reg_class_t TARGET_PREFERRED_RENAME_CLASS (reg_class_t 32045 RCLASS) 32046 A target hook that places additional preference on the register 32047 class to use when it is necessary to rename a register in class 32048 RCLASS to another class, or perhaps NO_REGS, if no preferred 32049 register class is found or hook 'preferred_rename_class' is not 32050 implemented. Sometimes returning a more restrictive class makes 32051 better code. For example, on ARM, thumb-2 instructions using 32052 'LO_REGS' may be smaller than instructions using 'GENERIC_REGS'. 32053 By returning 'LO_REGS' from 'preferred_rename_class', code size can 32054 be reduced. 32055 32056 -- Target Hook: reg_class_t TARGET_PREFERRED_RELOAD_CLASS (rtx X, 32057 reg_class_t RCLASS) 32058 A target hook that places additional restrictions on the register 32059 class to use when it is necessary to copy value X into a register 32060 in class RCLASS. The value is a register class; perhaps RCLASS, or 32061 perhaps another, smaller class. 32062 32063 The default version of this hook always returns value of 'rclass' 32064 argument. 32065 32066 Sometimes returning a more restrictive class makes better code. 32067 For example, on the 68000, when X is an integer constant that is in 32068 range for a 'moveq' instruction, the value of this macro is always 32069 'DATA_REGS' as long as RCLASS includes the data registers. 32070 Requiring a data register guarantees that a 'moveq' will be used. 32071 32072 One case where 'TARGET_PREFERRED_RELOAD_CLASS' must not return 32073 RCLASS is if X is a legitimate constant which cannot be loaded into 32074 some register class. By returning 'NO_REGS' you can force X into a 32075 memory location. For example, rs6000 can load immediate values 32076 into general-purpose registers, but does not have an instruction 32077 for loading an immediate value into a floating-point register, so 32078 'TARGET_PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a 32079 floating-point constant. If the constant can't be loaded into any 32080 kind of register, code generation will be better if 32081 'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 32082 instead of using 'TARGET_PREFERRED_RELOAD_CLASS'. 32083 32084 If an insn has pseudos in it after register allocation, reload will 32085 go through the alternatives and call repeatedly 32086 'TARGET_PREFERRED_RELOAD_CLASS' to find the best one. Returning 32087 'NO_REGS', in this case, makes reload add a '!' in front of the 32088 constraint: the x86 back-end uses this feature to discourage usage 32089 of 387 registers when math is done in the SSE registers (and vice 32090 versa). 32091 32092 -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS) 32093 A C expression that places additional restrictions on the register 32094 class to use when it is necessary to copy value X into a register 32095 in class CLASS. The value is a register class; perhaps CLASS, or 32096 perhaps another, smaller class. On many machines, the following 32097 definition is safe: 32098 32099 #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS 32100 32101 Sometimes returning a more restrictive class makes better code. 32102 For example, on the 68000, when X is an integer constant that is in 32103 range for a 'moveq' instruction, the value of this macro is always 32104 'DATA_REGS' as long as CLASS includes the data registers. 32105 Requiring a data register guarantees that a 'moveq' will be used. 32106 32107 One case where 'PREFERRED_RELOAD_CLASS' must not return CLASS is if 32108 X is a legitimate constant which cannot be loaded into some 32109 register class. By returning 'NO_REGS' you can force X into a 32110 memory location. For example, rs6000 can load immediate values 32111 into general-purpose registers, but does not have an instruction 32112 for loading an immediate value into a floating-point register, so 32113 'PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a 32114 floating-point constant. If the constant cannot be loaded into any 32115 kind of register, code generation will be better if 32116 'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 32117 instead of using 'TARGET_PREFERRED_RELOAD_CLASS'. 32118 32119 If an insn has pseudos in it after register allocation, reload will 32120 go through the alternatives and call repeatedly 32121 'PREFERRED_RELOAD_CLASS' to find the best one. Returning 32122 'NO_REGS', in this case, makes reload add a '!' in front of the 32123 constraint: the x86 back-end uses this feature to discourage usage 32124 of 387 registers when math is done in the SSE registers (and vice 32125 versa). 32126 32127 -- Target Hook: reg_class_t TARGET_PREFERRED_OUTPUT_RELOAD_CLASS (rtx 32128 X, reg_class_t RCLASS) 32129 Like 'TARGET_PREFERRED_RELOAD_CLASS', but for output reloads 32130 instead of input reloads. 32131 32132 The default version of this hook always returns value of 'rclass' 32133 argument. 32134 32135 You can also use 'TARGET_PREFERRED_OUTPUT_RELOAD_CLASS' to 32136 discourage reload from using some alternatives, like 32137 'TARGET_PREFERRED_RELOAD_CLASS'. 32138 32139 -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS) 32140 A C expression that places additional restrictions on the register 32141 class to use when it is necessary to be able to hold a value of 32142 mode MODE in a reload register for which class CLASS would 32143 ordinarily be used. 32144 32145 Unlike 'PREFERRED_RELOAD_CLASS', this macro should be used when 32146 there are certain modes that simply cannot go in certain reload 32147 classes. 32148 32149 The value is a register class; perhaps CLASS, or perhaps another, 32150 smaller class. 32151 32152 Don't define this macro unless the target machine has limitations 32153 which require the macro to do something nontrivial. 32154 32155 -- Target Hook: reg_class_t TARGET_SECONDARY_RELOAD (bool IN_P, rtx X, 32156 reg_class_t RELOAD_CLASS, machine_mode RELOAD_MODE, 32157 secondary_reload_info *SRI) 32158 Many machines have some registers that cannot be copied directly to 32159 or from memory or even from other types of registers. An example 32160 is the 'MQ' register, which on most machines, can only be copied to 32161 or from general registers, but not memory. Below, we shall be 32162 using the term 'intermediate register' when a move operation cannot 32163 be performed directly, but has to be done by copying the source 32164 into the intermediate register first, and then copying the 32165 intermediate register to the destination. An intermediate register 32166 always has the same mode as source and destination. Since it holds 32167 the actual value being copied, reload might apply optimizations to 32168 re-use an intermediate register and eliding the copy from the 32169 source when it can determine that the intermediate register still 32170 holds the required value. 32171 32172 Another kind of secondary reload is required on some machines which 32173 allow copying all registers to and from memory, but require a 32174 scratch register for stores to some memory locations (e.g., those 32175 with symbolic address on the RT, and those with certain symbolic 32176 address on the SPARC when compiling PIC). Scratch registers need 32177 not have the same mode as the value being copied, and usually hold 32178 a different value than that being copied. Special patterns in the 32179 md file are needed to describe how the copy is performed with the 32180 help of the scratch register; these patterns also describe the 32181 number, register class(es) and mode(s) of the scratch register(s). 32182 32183 In some cases, both an intermediate and a scratch register are 32184 required. 32185 32186 For input reloads, this target hook is called with nonzero IN_P, 32187 and X is an rtx that needs to be copied to a register of class 32188 RELOAD_CLASS in RELOAD_MODE. For output reloads, this target hook 32189 is called with zero IN_P, and a register of class RELOAD_CLASS 32190 needs to be copied to rtx X in RELOAD_MODE. 32191 32192 If copying a register of RELOAD_CLASS from/to X requires an 32193 intermediate register, the hook 'secondary_reload' should return 32194 the register class required for this intermediate register. If no 32195 intermediate register is required, it should return NO_REGS. If 32196 more than one intermediate register is required, describe the one 32197 that is closest in the copy chain to the reload register. 32198 32199 If scratch registers are needed, you also have to describe how to 32200 perform the copy from/to the reload register to/from this closest 32201 intermediate register. Or if no intermediate register is required, 32202 but still a scratch register is needed, describe the copy from/to 32203 the reload register to/from the reload operand X. 32204 32205 You do this by setting 'sri->icode' to the instruction code of a 32206 pattern in the md file which performs the move. Operands 0 and 1 32207 are the output and input of this copy, respectively. Operands from 32208 operand 2 onward are for scratch operands. These scratch operands 32209 must have a mode, and a single-register-class output constraint. 32210 32211 When an intermediate register is used, the 'secondary_reload' hook 32212 will be called again to determine how to copy the intermediate 32213 register to/from the reload operand X, so your hook must also have 32214 code to handle the register class of the intermediate operand. 32215 32216 X might be a pseudo-register or a 'subreg' of a pseudo-register, 32217 which could either be in a hard register or in memory. Use 32218 'true_regnum' to find out; it will return -1 if the pseudo is in 32219 memory and the hard register number if it is in a register. 32220 32221 Scratch operands in memory (constraint '"=m"' / '"=&m"') are 32222 currently not supported. For the time being, you will have to 32223 continue to use 'TARGET_SECONDARY_MEMORY_NEEDED' for that purpose. 32224 32225 'copy_cost' also uses this target hook to find out how values are 32226 copied. If you want it to include some extra cost for the need to 32227 allocate (a) scratch register(s), set 'sri->extra_cost' to the 32228 additional cost. Or if two dependent moves are supposed to have a 32229 lower cost than the sum of the individual moves due to expected 32230 fortuitous scheduling and/or special forwarding logic, you can set 32231 'sri->extra_cost' to a negative amount. 32232 32233 -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X) 32234 -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X) 32235 -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X) 32236 These macros are obsolete, new ports should use the target hook 32237 'TARGET_SECONDARY_RELOAD' instead. 32238 32239 These are obsolete macros, replaced by the 32240 'TARGET_SECONDARY_RELOAD' target hook. Older ports still define 32241 these macros to indicate to the reload phase that it may need to 32242 allocate at least one register for a reload in addition to the 32243 register to contain the data. Specifically, if copying X to a 32244 register CLASS in MODE requires an intermediate register, you were 32245 supposed to define 'SECONDARY_INPUT_RELOAD_CLASS' to return the 32246 largest register class all of whose registers can be used as 32247 intermediate registers or scratch registers. 32248 32249 If copying a register CLASS in MODE to X requires an intermediate 32250 or scratch register, 'SECONDARY_OUTPUT_RELOAD_CLASS' was supposed 32251 to be defined be defined to return the largest register class 32252 required. If the requirements for input and output reloads were 32253 the same, the macro 'SECONDARY_RELOAD_CLASS' should have been used 32254 instead of defining both macros identically. 32255 32256 The values returned by these macros are often 'GENERAL_REGS'. 32257 Return 'NO_REGS' if no spare register is needed; i.e., if X can be 32258 directly copied to or from a register of CLASS in MODE without 32259 requiring a scratch register. Do not define this macro if it would 32260 always return 'NO_REGS'. 32261 32262 If a scratch register is required (either with or without an 32263 intermediate register), you were supposed to define patterns for 32264 'reload_inM' or 'reload_outM', as required (*note Standard Names::. 32265 These patterns, which were normally implemented with a 32266 'define_expand', should be similar to the 'movM' patterns, except 32267 that operand 2 is the scratch register. 32268 32269 These patterns need constraints for the reload register and scratch 32270 register that contain a single register class. If the original 32271 reload register (whose class is CLASS) can meet the constraint 32272 given in the pattern, the value returned by these macros is used 32273 for the class of the scratch register. Otherwise, two additional 32274 reload registers are required. Their classes are obtained from the 32275 constraints in the insn pattern. 32276 32277 X might be a pseudo-register or a 'subreg' of a pseudo-register, 32278 which could either be in a hard register or in memory. Use 32279 'true_regnum' to find out; it will return -1 if the pseudo is in 32280 memory and the hard register number if it is in a register. 32281 32282 These macros should not be used in the case where a particular 32283 class of registers can only be copied to memory and not to another 32284 class of registers. In that case, secondary reload registers are 32285 not needed and would not be helpful. Instead, a stack location 32286 must be used to perform the copy and the 'movM' pattern should use 32287 memory as an intermediate storage. This case often occurs between 32288 floating-point and general registers. 32289 32290 -- Target Hook: bool TARGET_SECONDARY_MEMORY_NEEDED (machine_mode MODE, 32291 reg_class_t CLASS1, reg_class_t CLASS2) 32292 Certain machines have the property that some registers cannot be 32293 copied to some other registers without using memory. Define this 32294 hook on those machines to return true if objects of mode M in 32295 registers of CLASS1 can only be copied to registers of class CLASS2 32296 by storing a register of CLASS1 into memory and loading that memory 32297 location into a register of CLASS2. The default definition returns 32298 false for all inputs. 32299 32300 -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE) 32301 Normally when 'TARGET_SECONDARY_MEMORY_NEEDED' is defined, the 32302 compiler allocates a stack slot for a memory location needed for 32303 register copies. If this macro is defined, the compiler instead 32304 uses the memory location defined by this macro. 32305 32306 Do not define this macro if you do not define 32307 'TARGET_SECONDARY_MEMORY_NEEDED'. 32308 32309 -- Target Hook: machine_mode TARGET_SECONDARY_MEMORY_NEEDED_MODE 32310 (machine_mode MODE) 32311 If 'TARGET_SECONDARY_MEMORY_NEEDED' tells the compiler to use 32312 memory when moving between two particular registers of mode MODE, 32313 this hook specifies the mode that the memory should have. 32314 32315 The default depends on 'TARGET_LRA_P'. Without LRA, the default is 32316 to use a word-sized mode for integral modes that are smaller than a 32317 a word. This is right thing to do on most machines because it 32318 ensures that all bits of the register are copied and prevents 32319 accesses to the registers in a narrower mode, which some machines 32320 prohibit for floating-point registers. 32321 32322 However, this default behavior is not correct on some machines, 32323 such as the DEC Alpha, that store short integers in floating-point 32324 registers differently than in integer registers. On those 32325 machines, the default widening will not work correctly and you must 32326 define this hook to suppress that widening in some cases. See the 32327 file 'alpha.c' for details. 32328 32329 With LRA, the default is to use MODE unmodified. 32330 32331 -- Target Hook: void TARGET_SELECT_EARLY_REMAT_MODES (sbitmap MODES) 32332 On some targets, certain modes cannot be held in registers around a 32333 standard ABI call and are relatively expensive to spill to the 32334 stack. The early rematerialization pass can help in such cases by 32335 aggressively recomputing values after calls, so that they don't 32336 need to be spilled. 32337 32338 This hook returns the set of such modes by setting the associated 32339 bits in MODES. The default implementation selects no modes, which 32340 has the effect of disabling the early rematerialization pass. 32341 32342 -- Target Hook: bool TARGET_CLASS_LIKELY_SPILLED_P (reg_class_t RCLASS) 32343 A target hook which returns 'true' if pseudos that have been 32344 assigned to registers of class RCLASS would likely be spilled 32345 because registers of RCLASS are needed for spill registers. 32346 32347 The default version of this target hook returns 'true' if RCLASS 32348 has exactly one register and 'false' otherwise. On most machines, 32349 this default should be used. For generally register-starved 32350 machines, such as i386, or machines with right register 32351 constraints, such as SH, this hook can be used to avoid excessive 32352 spilling. 32353 32354 This hook is also used by some of the global intra-procedural code 32355 transformations to throtle code motion, to avoid increasing 32356 register pressure. 32357 32358 -- Target Hook: unsigned char TARGET_CLASS_MAX_NREGS (reg_class_t 32359 RCLASS, machine_mode MODE) 32360 A target hook returns the maximum number of consecutive registers 32361 of class RCLASS needed to hold a value of mode MODE. 32362 32363 This is closely related to the macro 'TARGET_HARD_REGNO_NREGS'. In 32364 fact, the value returned by 'TARGET_CLASS_MAX_NREGS (RCLASS, MODE)' 32365 target hook should be the maximum value of 'TARGET_HARD_REGNO_NREGS 32366 (REGNO, MODE)' for all REGNO values in the class RCLASS. 32367 32368 This target hook helps control the handling of multiple-word values 32369 in the reload pass. 32370 32371 The default version of this target hook returns the size of MODE in 32372 words. 32373 32374 -- Macro: CLASS_MAX_NREGS (CLASS, MODE) 32375 A C expression for the maximum number of consecutive registers of 32376 class CLASS needed to hold a value of mode MODE. 32377 32378 This is closely related to the macro 'TARGET_HARD_REGNO_NREGS'. In 32379 fact, the value of the macro 'CLASS_MAX_NREGS (CLASS, MODE)' should 32380 be the maximum value of 'TARGET_HARD_REGNO_NREGS (REGNO, MODE)' for 32381 all REGNO values in the class CLASS. 32382 32383 This macro helps control the handling of multiple-word values in 32384 the reload pass. 32385 32386 -- Target Hook: bool TARGET_CAN_CHANGE_MODE_CLASS (machine_mode FROM, 32387 machine_mode TO, reg_class_t RCLASS) 32388 This hook returns true if it is possible to bitcast values held in 32389 registers of class RCLASS from mode FROM to mode TO and if doing so 32390 preserves the low-order bits that are common to both modes. The 32391 result is only meaningful if RCLASS has registers that can hold 32392 both 'from' and 'to'. The default implementation returns true. 32393 32394 As an example of when such bitcasting is invalid, loading 32-bit 32395 integer or floating-point objects into floating-point registers on 32396 Alpha extends them to 64 bits. Therefore loading a 64-bit object 32397 and then storing it as a 32-bit object does not store the low-order 32398 32 bits, as would be the case for a normal register. Therefore, 32399 'alpha.h' defines 'TARGET_CAN_CHANGE_MODE_CLASS' to return: 32400 32401 (GET_MODE_SIZE (from) == GET_MODE_SIZE (to) 32402 || !reg_classes_intersect_p (FLOAT_REGS, rclass)) 32403 32404 Even if storing from a register in mode TO would be valid, if both 32405 FROM and 'raw_reg_mode' for RCLASS are wider than 'word_mode', then 32406 we must prevent TO narrowing the mode. This happens when the 32407 middle-end assumes that it can load or store pieces of an N-word 32408 pseudo, and that the pseudo will eventually be allocated to N 32409 'word_mode' hard registers. Failure to prevent this kind of mode 32410 change will result in the entire 'raw_reg_mode' being modified 32411 instead of the partial value that the middle-end intended. 32412 32413 -- Target Hook: reg_class_t TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS 32414 (int, REG_CLASS_T, REG_CLASS_T) 32415 A target hook which can change allocno class for given pseudo from 32416 allocno and best class calculated by IRA. 32417 32418 The default version of this target hook always returns given class. 32419 32420 -- Target Hook: bool TARGET_LRA_P (void) 32421 A target hook which returns true if we use LRA instead of reload 32422 pass. The default version of this target hook returns true. New 32423 ports should use LRA, and existing ports are encouraged to convert. 32424 32425 -- Target Hook: int TARGET_REGISTER_PRIORITY (int) 32426 A target hook which returns the register priority number to which 32427 the register HARD_REGNO belongs to. The bigger the number, the 32428 more preferable the hard register usage (when all other conditions 32429 are the same). This hook can be used to prefer some hard register 32430 over others in LRA. For example, some x86-64 register usage needs 32431 additional prefix which makes instructions longer. The hook can 32432 return lower priority number for such registers make them less 32433 favorable and as result making the generated code smaller. The 32434 default version of this target hook returns always zero. 32435 32436 -- Target Hook: bool TARGET_REGISTER_USAGE_LEVELING_P (void) 32437 A target hook which returns true if we need register usage 32438 leveling. That means if a few hard registers are equally good for 32439 the assignment, we choose the least used hard register. The 32440 register usage leveling may be profitable for some targets. Don't 32441 use the usage leveling for targets with conditional execution or 32442 targets with big register files as it hurts if-conversion and 32443 cross-jumping optimizations. The default version of this target 32444 hook returns always false. 32445 32446 -- Target Hook: bool TARGET_DIFFERENT_ADDR_DISPLACEMENT_P (void) 32447 A target hook which returns true if an address with the same 32448 structure can have different maximal legitimate displacement. For 32449 example, the displacement can depend on memory mode or on operand 32450 combinations in the insn. The default version of this target hook 32451 returns always false. 32452 32453 -- Target Hook: bool TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P (rtx SUBST) 32454 A target hook which returns 'true' if SUBST can't substitute safely 32455 pseudos with equivalent memory values during register allocation. 32456 The default version of this target hook returns 'false'. On most 32457 machines, this default should be used. For generally machines with 32458 non orthogonal register usage for addressing, such as SH, this hook 32459 can be used to avoid excessive spilling. 32460 32461 -- Target Hook: bool TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT (rtx 32462 *OFFSET1, rtx *OFFSET2, poly_int64 ORIG_OFFSET, machine_mode 32463 MODE) 32464 This hook tries to split address offset ORIG_OFFSET into two parts: 32465 one that should be added to the base address to create a local 32466 anchor point, and an additional offset that can be applied to the 32467 anchor to address a value of mode MODE. The idea is that the local 32468 anchor could be shared by other accesses to nearby locations. 32469 32470 The hook returns true if it succeeds, storing the offset of the 32471 anchor from the base in OFFSET1 and the offset of the final address 32472 from the anchor in OFFSET2. The default implementation returns 32473 false. 32474 32475 -- Target Hook: reg_class_t TARGET_SPILL_CLASS (reg_class_t, 32476 MACHINE_MODE) 32477 This hook defines a class of registers which could be used for 32478 spilling pseudos of the given mode and class, or 'NO_REGS' if only 32479 memory should be used. Not defining this hook is equivalent to 32480 returning 'NO_REGS' for all inputs. 32481 32482 -- Target Hook: bool TARGET_ADDITIONAL_ALLOCNO_CLASS_P (reg_class_t) 32483 This hook should return 'true' if given class of registers should 32484 be an allocno class in any way. Usually RA uses only one register 32485 class from all classes containing the same register set. In some 32486 complicated cases, you need to have two or more such classes as 32487 allocno ones for RA correct work. Not defining this hook is 32488 equivalent to returning 'false' for all inputs. 32489 32490 -- Target Hook: scalar_int_mode TARGET_CSTORE_MODE (enum insn_code 32491 ICODE) 32492 This hook defines the machine mode to use for the boolean result of 32493 conditional store patterns. The ICODE argument is the instruction 32494 code for the cstore being performed. Not definiting this hook is 32495 the same as accepting the mode encoded into operand 0 of the cstore 32496 expander patterns. 32497 32498 -- Target Hook: int TARGET_COMPUTE_PRESSURE_CLASSES (enum reg_class 32499 *PRESSURE_CLASSES) 32500 A target hook which lets a backend compute the set of pressure 32501 classes to be used by those optimization passes which take register 32502 pressure into account, as opposed to letting IRA compute them. It 32503 returns the number of register classes stored in the array 32504 PRESSURE_CLASSES. 32505 32506 32507File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros 32508 3250918.9 Stack Layout and Calling Conventions 32510========================================= 32511 32512This describes the stack layout and calling conventions. 32513 32514* Menu: 32515 32516* Frame Layout:: 32517* Exception Handling:: 32518* Stack Checking:: 32519* Frame Registers:: 32520* Elimination:: 32521* Stack Arguments:: 32522* Register Arguments:: 32523* Scalar Return:: 32524* Aggregate Return:: 32525* Caller Saves:: 32526* Function Entry:: 32527* Profiling:: 32528* Tail Calls:: 32529* Shrink-wrapping separate components:: 32530* Stack Smashing Protection:: 32531* Miscellaneous Register Hooks:: 32532 32533 32534File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling 32535 3253618.9.1 Basic Stack Layout 32537------------------------- 32538 32539Here is the basic stack layout. 32540 32541 -- Macro: STACK_GROWS_DOWNWARD 32542 Define this macro to be true if pushing a word onto the stack moves 32543 the stack pointer to a smaller address, and false otherwise. 32544 32545 -- Macro: STACK_PUSH_CODE 32546 This macro defines the operation used when something is pushed on 32547 the stack. In RTL, a push operation will be '(set (mem 32548 (STACK_PUSH_CODE (reg sp))) ...)' 32549 32550 The choices are 'PRE_DEC', 'POST_DEC', 'PRE_INC', and 'POST_INC'. 32551 Which of these is correct depends on the stack direction and on 32552 whether the stack pointer points to the last item on the stack or 32553 whether it points to the space for the next item on the stack. 32554 32555 The default is 'PRE_DEC' when 'STACK_GROWS_DOWNWARD' is true, which 32556 is almost always right, and 'PRE_INC' otherwise, which is often 32557 wrong. 32558 32559 -- Macro: FRAME_GROWS_DOWNWARD 32560 Define this macro to nonzero value if the addresses of local 32561 variable slots are at negative offsets from the frame pointer. 32562 32563 -- Macro: ARGS_GROW_DOWNWARD 32564 Define this macro if successive arguments to a function occupy 32565 decreasing addresses on the stack. 32566 32567 -- Target Hook: HOST_WIDE_INT TARGET_STARTING_FRAME_OFFSET (void) 32568 This hook returns the offset from the frame pointer to the first 32569 local variable slot to be allocated. If 'FRAME_GROWS_DOWNWARD', it 32570 is the offset to _end_ of the first slot allocated, otherwise it is 32571 the offset to _beginning_ of the first slot allocated. The default 32572 implementation returns 0. 32573 32574 -- Macro: STACK_ALIGNMENT_NEEDED 32575 Define to zero to disable final alignment of the stack during 32576 reload. The nonzero default for this macro is suitable for most 32577 ports. 32578 32579 On ports where 'TARGET_STARTING_FRAME_OFFSET' is nonzero or where 32580 there is a register save block following the local block that 32581 doesn't require alignment to 'STACK_BOUNDARY', it may be beneficial 32582 to disable stack alignment and do it in the backend. 32583 32584 -- Macro: STACK_POINTER_OFFSET 32585 Offset from the stack pointer register to the first location at 32586 which outgoing arguments are placed. If not specified, the default 32587 value of zero is used. This is the proper value for most machines. 32588 32589 If 'ARGS_GROW_DOWNWARD', this is the offset to the location above 32590 the first location at which outgoing arguments are placed. 32591 32592 -- Macro: FIRST_PARM_OFFSET (FUNDECL) 32593 Offset from the argument pointer register to the first argument's 32594 address. On some machines it may depend on the data type of the 32595 function. 32596 32597 If 'ARGS_GROW_DOWNWARD', this is the offset to the location above 32598 the first argument's address. 32599 32600 -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL) 32601 Offset from the stack pointer register to an item dynamically 32602 allocated on the stack, e.g., by 'alloca'. 32603 32604 The default value for this macro is 'STACK_POINTER_OFFSET' plus the 32605 length of the outgoing arguments. The default is correct for most 32606 machines. See 'function.c' for details. 32607 32608 -- Macro: INITIAL_FRAME_ADDRESS_RTX 32609 A C expression whose value is RTL representing the address of the 32610 initial stack frame. This address is passed to 'RETURN_ADDR_RTX' 32611 and 'DYNAMIC_CHAIN_ADDRESS'. If you don't define this macro, a 32612 reasonable default value will be used. Define this macro in order 32613 to make frame pointer elimination work in the presence of 32614 '__builtin_frame_address (count)' and '__builtin_return_address 32615 (count)' for 'count' not equal to zero. 32616 32617 -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR) 32618 A C expression whose value is RTL representing the address in a 32619 stack frame where the pointer to the caller's frame is stored. 32620 Assume that FRAMEADDR is an RTL expression for the address of the 32621 stack frame itself. 32622 32623 If you don't define this macro, the default is to return the value 32624 of FRAMEADDR--that is, the stack frame address is also the address 32625 of the stack word that points to the previous frame. 32626 32627 -- Macro: SETUP_FRAME_ADDRESSES 32628 A C expression that produces the machine-specific code to setup the 32629 stack so that arbitrary frames can be accessed. For example, on 32630 the SPARC, we must flush all of the register windows to the stack 32631 before we can access arbitrary stack frames. You will seldom need 32632 to define this macro. The default is to do nothing. 32633 32634 -- Target Hook: rtx TARGET_BUILTIN_SETJMP_FRAME_VALUE (void) 32635 This target hook should return an rtx that is used to store the 32636 address of the current frame into the built in 'setjmp' buffer. 32637 The default value, 'virtual_stack_vars_rtx', is correct for most 32638 machines. One reason you may need to define this target hook is if 32639 'hard_frame_pointer_rtx' is the appropriate value on your machine. 32640 32641 -- Macro: FRAME_ADDR_RTX (FRAMEADDR) 32642 A C expression whose value is RTL representing the value of the 32643 frame address for the current frame. FRAMEADDR is the frame 32644 pointer of the current frame. This is used for 32645 __builtin_frame_address. You need only define this macro if the 32646 frame address is not the same as the frame pointer. Most machines 32647 do not need to define it. 32648 32649 -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR) 32650 A C expression whose value is RTL representing the value of the 32651 return address for the frame COUNT steps up from the current frame, 32652 after the prologue. FRAMEADDR is the frame pointer of the COUNT 32653 frame, or the frame pointer of the COUNT - 1 frame if 32654 'RETURN_ADDR_IN_PREVIOUS_FRAME' is nonzero. 32655 32656 The value of the expression must always be the correct address when 32657 COUNT is zero, but may be 'NULL_RTX' if there is no way to 32658 determine the return address of other frames. 32659 32660 -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME 32661 Define this macro to nonzero value if the return address of a 32662 particular stack frame is accessed from the frame pointer of the 32663 previous stack frame. The zero default for this macro is suitable 32664 for most ports. 32665 32666 -- Macro: INCOMING_RETURN_ADDR_RTX 32667 A C expression whose value is RTL representing the location of the 32668 incoming return address at the beginning of any function, before 32669 the prologue. This RTL is either a 'REG', indicating that the 32670 return value is saved in 'REG', or a 'MEM' representing a location 32671 in the stack. 32672 32673 You only need to define this macro if you want to support call 32674 frame debugging information like that provided by DWARF 2. 32675 32676 If this RTL is a 'REG', you should also define 32677 'DWARF_FRAME_RETURN_COLUMN' to 'DWARF_FRAME_REGNUM (REGNO)'. 32678 32679 -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN 32680 A C expression whose value is an integer giving a DWARF 2 column 32681 number that may be used as an alternative return column. The 32682 column must not correspond to any gcc hard register (that is, it 32683 must not be in the range of 'DWARF_FRAME_REGNUM'). 32684 32685 This macro can be useful if 'DWARF_FRAME_RETURN_COLUMN' is set to a 32686 general register, but an alternative column needs to be used for 32687 signal frames. Some targets have also used different frame return 32688 columns over time. 32689 32690 -- Macro: DWARF_ZERO_REG 32691 A C expression whose value is an integer giving a DWARF 2 register 32692 number that is considered to always have the value zero. This 32693 should only be defined if the target has an architected zero 32694 register, and someone decided it was a good idea to use that 32695 register number to terminate the stack backtrace. New ports should 32696 avoid this. 32697 32698 -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char 32699 *LABEL, rtx PATTERN, int INDEX) 32700 This target hook allows the backend to emit frame-related insns 32701 that contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame 32702 debugging info engine will invoke it on insns of the form 32703 (set (reg) (unspec [...] UNSPEC_INDEX)) 32704 and 32705 (set (reg) (unspec_volatile [...] UNSPECV_INDEX)). 32706 to let the backend emit the call frame instructions. LABEL is the 32707 CFI label attached to the insn, PATTERN is the pattern of the insn 32708 and INDEX is 'UNSPEC_INDEX' or 'UNSPECV_INDEX'. 32709 32710 -- Target Hook: unsigned int TARGET_DWARF_POLY_INDETERMINATE_VALUE 32711 (unsigned int I, unsigned int *FACTOR, int *OFFSET) 32712 Express the value of 'poly_int' indeterminate I as a DWARF 32713 expression, with I counting from 1. Return the number of a DWARF 32714 register R and set '*FACTOR' and '*OFFSET' such that the value of 32715 the indeterminate is: 32716 value_of(R) / FACTOR - OFFSET 32717 32718 A target only needs to define this hook if it sets 32719 'NUM_POLY_INT_COEFFS' to a value greater than 1. 32720 32721 -- Macro: INCOMING_FRAME_SP_OFFSET 32722 A C expression whose value is an integer giving the offset, in 32723 bytes, from the value of the stack pointer register to the top of 32724 the stack frame at the beginning of any function, before the 32725 prologue. The top of the frame is defined to be the value of the 32726 stack pointer in the previous frame, just before the call 32727 instruction. 32728 32729 You only need to define this macro if you want to support call 32730 frame debugging information like that provided by DWARF 2. 32731 32732 -- Macro: DEFAULT_INCOMING_FRAME_SP_OFFSET 32733 Like 'INCOMING_FRAME_SP_OFFSET', but must be the same for all 32734 functions of the same ABI, and when using GAS '.cfi_*' directives 32735 must also agree with the default CFI GAS emits. Define this macro 32736 only if 'INCOMING_FRAME_SP_OFFSET' can have different values 32737 between different functions of the same ABI or when 32738 'INCOMING_FRAME_SP_OFFSET' does not agree with GAS default CFI. 32739 32740 -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL) 32741 A C expression whose value is an integer giving the offset, in 32742 bytes, from the argument pointer to the canonical frame address 32743 (cfa). The final value should coincide with that calculated by 32744 'INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable 32745 during virtual register instantiation. 32746 32747 The default value for this macro is 'FIRST_PARM_OFFSET (fundecl) + 32748 crtl->args.pretend_args_size', which is correct for most machines; 32749 in general, the arguments are found immediately before the stack 32750 frame. Note that this is not the case on some targets that save 32751 registers into the caller's frame, such as SPARC and rs6000, and so 32752 such targets need to define this macro. 32753 32754 You only need to define this macro if the default is incorrect, and 32755 you want to support call frame debugging information like that 32756 provided by DWARF 2. 32757 32758 -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL) 32759 If defined, a C expression whose value is an integer giving the 32760 offset in bytes from the frame pointer to the canonical frame 32761 address (cfa). The final value should coincide with that 32762 calculated by 'INCOMING_FRAME_SP_OFFSET'. 32763 32764 Normally the CFA is calculated as an offset from the argument 32765 pointer, via 'ARG_POINTER_CFA_OFFSET', but if the argument pointer 32766 is variable due to the ABI, this may not be possible. If this 32767 macro is defined, it implies that the virtual register 32768 instantiation should be based on the frame pointer instead of the 32769 argument pointer. Only one of 'FRAME_POINTER_CFA_OFFSET' and 32770 'ARG_POINTER_CFA_OFFSET' should be defined. 32771 32772 -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL) 32773 If defined, a C expression whose value is an integer giving the 32774 offset in bytes from the canonical frame address (cfa) to the frame 32775 base used in DWARF 2 debug information. The default is zero. A 32776 different value may reduce the size of debug information on some 32777 ports. 32778 32779 32780File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling 32781 3278218.9.2 Exception Handling Support 32783--------------------------------- 32784 32785 -- Macro: EH_RETURN_DATA_REGNO (N) 32786 A C expression whose value is the Nth register number used for data 32787 by exception handlers, or 'INVALID_REGNUM' if fewer than N 32788 registers are usable. 32789 32790 The exception handling library routines communicate with the 32791 exception handlers via a set of agreed upon registers. Ideally 32792 these registers should be call-clobbered; it is possible to use 32793 call-saved registers, but may negatively impact code size. The 32794 target must support at least 2 data registers, but should define 4 32795 if there are enough free registers. 32796 32797 You must define this macro if you want to support call frame 32798 exception handling like that provided by DWARF 2. 32799 32800 -- Macro: EH_RETURN_STACKADJ_RTX 32801 A C expression whose value is RTL representing a location in which 32802 to store a stack adjustment to be applied before function return. 32803 This is used to unwind the stack to an exception handler's call 32804 frame. It will be assigned zero on code paths that return 32805 normally. 32806 32807 Typically this is a call-clobbered hard register that is otherwise 32808 untouched by the epilogue, but could also be a stack slot. 32809 32810 Do not define this macro if the stack pointer is saved and restored 32811 by the regular prolog and epilog code in the call frame itself; in 32812 this case, the exception handling library routines will update the 32813 stack location to be restored in place. Otherwise, you must define 32814 this macro if you want to support call frame exception handling 32815 like that provided by DWARF 2. 32816 32817 -- Macro: EH_RETURN_HANDLER_RTX 32818 A C expression whose value is RTL representing a location in which 32819 to store the address of an exception handler to which we should 32820 return. It will not be assigned on code paths that return 32821 normally. 32822 32823 Typically this is the location in the call frame at which the 32824 normal return address is stored. For targets that return by 32825 popping an address off the stack, this might be a memory address 32826 just below the _target_ call frame rather than inside the current 32827 call frame. If defined, 'EH_RETURN_STACKADJ_RTX' will have already 32828 been assigned, so it may be used to calculate the location of the 32829 target call frame. 32830 32831 Some targets have more complex requirements than storing to an 32832 address calculable during initial code generation. In that case 32833 the 'eh_return' instruction pattern should be used instead. 32834 32835 If you want to support call frame exception handling, you must 32836 define either this macro or the 'eh_return' instruction pattern. 32837 32838 -- Macro: RETURN_ADDR_OFFSET 32839 If defined, an integer-valued C expression for which rtl will be 32840 generated to add it to the exception handler address before it is 32841 searched in the exception handling tables, and to subtract it again 32842 from the address before using it to return to the exception 32843 handler. 32844 32845 -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL) 32846 This macro chooses the encoding of pointers embedded in the 32847 exception handling sections. If at all possible, this should be 32848 defined such that the exception handling section will not require 32849 dynamic relocations, and so may be read-only. 32850 32851 CODE is 0 for data, 1 for code labels, 2 for function pointers. 32852 GLOBAL is true if the symbol may be affected by dynamic 32853 relocations. The macro should return a combination of the 32854 'DW_EH_PE_*' defines as found in 'dwarf2.h'. 32855 32856 If this macro is not defined, pointers will not be encoded but 32857 represented directly. 32858 32859 -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE, 32860 ADDR, DONE) 32861 This macro allows the target to emit whatever special magic is 32862 required to represent the encoding chosen by 32863 'ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of 32864 pc-relative and indirect encodings; this must be defined if the 32865 target uses text-relative or data-relative encodings. 32866 32867 This is a C statement that branches to DONE if the format was 32868 handled. ENCODING is the format chosen, SIZE is the number of 32869 bytes that the format occupies, ADDR is the 'SYMBOL_REF' to be 32870 emitted. 32871 32872 -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS) 32873 This macro allows the target to add CPU and operating system 32874 specific code to the call-frame unwinder for use when there is no 32875 unwind data available. The most common reason to implement this 32876 macro is to unwind through signal frames. 32877 32878 This macro is called from 'uw_frame_state_for' in 'unwind-dw2.c', 32879 'unwind-dw2-xtensa.c' and 'unwind-ia64.c'. CONTEXT is an 32880 '_Unwind_Context'; FS is an '_Unwind_FrameState'. Examine 32881 'context->ra' for the address of the code being executed and 32882 'context->cfa' for the stack pointer value. If the frame can be 32883 decoded, the register save addresses should be updated in FS and 32884 the macro should evaluate to '_URC_NO_REASON'. If the frame cannot 32885 be decoded, the macro should evaluate to '_URC_END_OF_STACK'. 32886 32887 For proper signal handling in Java this macro is accompanied by 32888 'MAKE_THROW_FRAME', defined in 'libjava/include/*-signal.h' 32889 headers. 32890 32891 -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS) 32892 This macro allows the target to add operating system specific code 32893 to the call-frame unwinder to handle the IA-64 '.unwabi' unwinding 32894 directive, usually used for signal or interrupt frames. 32895 32896 This macro is called from 'uw_update_context' in libgcc's 32897 'unwind-ia64.c'. CONTEXT is an '_Unwind_Context'; FS is an 32898 '_Unwind_FrameState'. Examine 'fs->unwabi' for the abi and context 32899 in the '.unwabi' directive. If the '.unwabi' directive can be 32900 handled, the register save addresses should be updated in FS. 32901 32902 -- Macro: TARGET_USES_WEAK_UNWIND_INFO 32903 A C expression that evaluates to true if the target requires unwind 32904 info to be given comdat linkage. Define it to be '1' if comdat 32905 linkage is necessary. The default is '0'. 32906 32907 32908File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling 32909 3291018.9.3 Specifying How Stack Checking is Done 32911-------------------------------------------- 32912 32913GCC will check that stack references are within the boundaries of the 32914stack, if the option '-fstack-check' is specified, in one of three ways: 32915 32916 1. If the value of the 'STACK_CHECK_BUILTIN' macro is nonzero, GCC 32917 will assume that you have arranged for full stack checking to be 32918 done at appropriate places in the configuration files. GCC will 32919 not do other special processing. 32920 32921 2. If 'STACK_CHECK_BUILTIN' is zero and the value of the 32922 'STACK_CHECK_STATIC_BUILTIN' macro is nonzero, GCC will assume that 32923 you have arranged for static stack checking (checking of the static 32924 stack frame of functions) to be done at appropriate places in the 32925 configuration files. GCC will only emit code to do dynamic stack 32926 checking (checking on dynamic stack allocations) using the third 32927 approach below. 32928 32929 3. If neither of the above are true, GCC will generate code to 32930 periodically "probe" the stack pointer using the values of the 32931 macros defined below. 32932 32933 If neither STACK_CHECK_BUILTIN nor STACK_CHECK_STATIC_BUILTIN is 32934defined, GCC will change its allocation strategy for large objects if 32935the option '-fstack-check' is specified: they will always be allocated 32936dynamically if their size exceeds 'STACK_CHECK_MAX_VAR_SIZE' bytes. 32937 32938 -- Macro: STACK_CHECK_BUILTIN 32939 A nonzero value if stack checking is done by the configuration 32940 files in a machine-dependent manner. You should define this macro 32941 if stack checking is required by the ABI of your machine or if you 32942 would like to do stack checking in some more efficient way than the 32943 generic approach. The default value of this macro is zero. 32944 32945 -- Macro: STACK_CHECK_STATIC_BUILTIN 32946 A nonzero value if static stack checking is done by the 32947 configuration files in a machine-dependent manner. You should 32948 define this macro if you would like to do static stack checking in 32949 some more efficient way than the generic approach. The default 32950 value of this macro is zero. 32951 32952 -- Macro: STACK_CHECK_PROBE_INTERVAL_EXP 32953 An integer specifying the interval at which GCC must generate stack 32954 probe instructions, defined as 2 raised to this integer. You will 32955 normally define this macro so that the interval be no larger than 32956 the size of the "guard pages" at the end of a stack area. The 32957 default value of 12 (4096-byte interval) is suitable for most 32958 systems. 32959 32960 -- Macro: STACK_CHECK_MOVING_SP 32961 An integer which is nonzero if GCC should move the stack pointer 32962 page by page when doing probes. This can be necessary on systems 32963 where the stack pointer contains the bottom address of the memory 32964 area accessible to the executing thread at any point in time. In 32965 this situation an alternate signal stack is required in order to be 32966 able to recover from a stack overflow. The default value of this 32967 macro is zero. 32968 32969 -- Macro: STACK_CHECK_PROTECT 32970 The number of bytes of stack needed to recover from a stack 32971 overflow, for languages where such a recovery is supported. The 32972 default value of 4KB/8KB with the 'setjmp'/'longjmp'-based 32973 exception handling mechanism and 8KB/12KB with other exception 32974 handling mechanisms should be adequate for most architectures and 32975 operating systems. 32976 32977 The following macros are relevant only if neither STACK_CHECK_BUILTIN 32978nor STACK_CHECK_STATIC_BUILTIN is defined; you can omit them altogether 32979in the opposite case. 32980 32981 -- Macro: STACK_CHECK_MAX_FRAME_SIZE 32982 The maximum size of a stack frame, in bytes. GCC will generate 32983 probe instructions in non-leaf functions to ensure at least this 32984 many bytes of stack are available. If a stack frame is larger than 32985 this size, stack checking will not be reliable and GCC will issue a 32986 warning. The default is chosen so that GCC only generates one 32987 instruction on most systems. You should normally not change the 32988 default value of this macro. 32989 32990 -- Macro: STACK_CHECK_FIXED_FRAME_SIZE 32991 GCC uses this value to generate the above warning message. It 32992 represents the amount of fixed frame used by a function, not 32993 including space for any callee-saved registers, temporaries and 32994 user variables. You need only specify an upper bound for this 32995 amount and will normally use the default of four words. 32996 32997 -- Macro: STACK_CHECK_MAX_VAR_SIZE 32998 The maximum size, in bytes, of an object that GCC will place in the 32999 fixed area of the stack frame when the user specifies 33000 '-fstack-check'. GCC computed the default from the values of the 33001 above macros and you will normally not need to override that 33002 default. 33003 33004 -- Target Hook: bool TARGET_STACK_CLASH_PROTECTION_FINAL_DYNAMIC_PROBE 33005 (rtx RESIDUAL) 33006 Some targets make optimistic assumptions about the state of stack 33007 probing when they emit their prologues. On such targets a probe 33008 into the end of any dynamically allocated space is likely required 33009 for safety against stack clash style attacks. Define this variable 33010 to return nonzero if such a probe is required or zero otherwise. 33011 You need not define this macro if it would always have the value 33012 zero. 33013 33014 33015File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling 33016 3301718.9.4 Registers That Address the Stack Frame 33018--------------------------------------------- 33019 33020This discusses registers that address the stack frame. 33021 33022 -- Macro: STACK_POINTER_REGNUM 33023 The register number of the stack pointer register, which must also 33024 be a fixed register according to 'FIXED_REGISTERS'. On most 33025 machines, the hardware determines which register this is. 33026 33027 -- Macro: FRAME_POINTER_REGNUM 33028 The register number of the frame pointer register, which is used to 33029 access automatic variables in the stack frame. On some machines, 33030 the hardware determines which register this is. On other machines, 33031 you can choose any register you wish for this purpose. 33032 33033 -- Macro: HARD_FRAME_POINTER_REGNUM 33034 On some machines the offset between the frame pointer and starting 33035 offset of the automatic variables is not known until after register 33036 allocation has been done (for example, because the saved registers 33037 are between these two locations). On those machines, define 33038 'FRAME_POINTER_REGNUM' the number of a special, fixed register to 33039 be used internally until the offset is known, and define 33040 'HARD_FRAME_POINTER_REGNUM' to be the actual hard register number 33041 used for the frame pointer. 33042 33043 You should define this macro only in the very rare circumstances 33044 when it is not possible to calculate the offset between the frame 33045 pointer and the automatic variables until after register allocation 33046 has been completed. When this macro is defined, you must also 33047 indicate in your definition of 'ELIMINABLE_REGS' how to eliminate 33048 'FRAME_POINTER_REGNUM' into either 'HARD_FRAME_POINTER_REGNUM' or 33049 'STACK_POINTER_REGNUM'. 33050 33051 Do not define this macro if it would be the same as 33052 'FRAME_POINTER_REGNUM'. 33053 33054 -- Macro: ARG_POINTER_REGNUM 33055 The register number of the arg pointer register, which is used to 33056 access the function's argument list. On some machines, this is the 33057 same as the frame pointer register. On some machines, the hardware 33058 determines which register this is. On other machines, you can 33059 choose any register you wish for this purpose. If this is not the 33060 same register as the frame pointer register, then you must mark it 33061 as a fixed register according to 'FIXED_REGISTERS', or arrange to 33062 be able to eliminate it (*note Elimination::). 33063 33064 -- Macro: HARD_FRAME_POINTER_IS_FRAME_POINTER 33065 Define this to a preprocessor constant that is nonzero if 33066 'hard_frame_pointer_rtx' and 'frame_pointer_rtx' should be the 33067 same. The default definition is '(HARD_FRAME_POINTER_REGNUM == 33068 FRAME_POINTER_REGNUM)'; you only need to define this macro if that 33069 definition is not suitable for use in preprocessor conditionals. 33070 33071 -- Macro: HARD_FRAME_POINTER_IS_ARG_POINTER 33072 Define this to a preprocessor constant that is nonzero if 33073 'hard_frame_pointer_rtx' and 'arg_pointer_rtx' should be the same. 33074 The default definition is '(HARD_FRAME_POINTER_REGNUM == 33075 ARG_POINTER_REGNUM)'; you only need to define this macro if that 33076 definition is not suitable for use in preprocessor conditionals. 33077 33078 -- Macro: RETURN_ADDRESS_POINTER_REGNUM 33079 The register number of the return address pointer register, which 33080 is used to access the current function's return address from the 33081 stack. On some machines, the return address is not at a fixed 33082 offset from the frame pointer or stack pointer or argument pointer. 33083 This register can be defined to point to the return address on the 33084 stack, and then be converted by 'ELIMINABLE_REGS' into either the 33085 frame pointer or stack pointer. 33086 33087 Do not define this macro unless there is no other way to get the 33088 return address from the stack. 33089 33090 -- Macro: STATIC_CHAIN_REGNUM 33091 -- Macro: STATIC_CHAIN_INCOMING_REGNUM 33092 Register numbers used for passing a function's static chain 33093 pointer. If register windows are used, the register number as seen 33094 by the called function is 'STATIC_CHAIN_INCOMING_REGNUM', while the 33095 register number as seen by the calling function is 33096 'STATIC_CHAIN_REGNUM'. If these registers are the same, 33097 'STATIC_CHAIN_INCOMING_REGNUM' need not be defined. 33098 33099 The static chain register need not be a fixed register. 33100 33101 If the static chain is passed in memory, these macros should not be 33102 defined; instead, the 'TARGET_STATIC_CHAIN' hook should be used. 33103 33104 -- Target Hook: rtx TARGET_STATIC_CHAIN (const_tree FNDECL_OR_TYPE, 33105 bool INCOMING_P) 33106 This hook replaces the use of 'STATIC_CHAIN_REGNUM' et al for 33107 targets that may use different static chain locations for different 33108 nested functions. This may be required if the target has function 33109 attributes that affect the calling conventions of the function and 33110 those calling conventions use different static chain locations. 33111 33112 The default version of this hook uses 'STATIC_CHAIN_REGNUM' et al. 33113 33114 If the static chain is passed in memory, this hook should be used 33115 to provide rtx giving 'mem' expressions that denote where they are 33116 stored. Often the 'mem' expression as seen by the caller will be 33117 at an offset from the stack pointer and the 'mem' expression as 33118 seen by the callee will be at an offset from the frame pointer. 33119 The variables 'stack_pointer_rtx', 'frame_pointer_rtx', and 33120 'arg_pointer_rtx' will have been initialized and should be used to 33121 refer to those items. 33122 33123 -- Macro: DWARF_FRAME_REGISTERS 33124 This macro specifies the maximum number of hard registers that can 33125 be saved in a call frame. This is used to size data structures 33126 used in DWARF2 exception handling. 33127 33128 Prior to GCC 3.0, this macro was needed in order to establish a 33129 stable exception handling ABI in the face of adding new hard 33130 registers for ISA extensions. In GCC 3.0 and later, the EH ABI is 33131 insulated from changes in the number of hard registers. 33132 Nevertheless, this macro can still be used to reduce the runtime 33133 memory requirements of the exception handling routines, which can 33134 be substantial if the ISA contains a lot of registers that are not 33135 call-saved. 33136 33137 If this macro is not defined, it defaults to 33138 'FIRST_PSEUDO_REGISTER'. 33139 33140 -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS 33141 33142 This macro is similar to 'DWARF_FRAME_REGISTERS', but is provided 33143 for backward compatibility in pre GCC 3.0 compiled code. 33144 33145 If this macro is not defined, it defaults to 33146 'DWARF_FRAME_REGISTERS'. 33147 33148 -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO) 33149 33150 Define this macro if the target's representation for dwarf 33151 registers is different than the internal representation for unwind 33152 column. Given a dwarf register, this macro should return the 33153 internal unwind column number to use instead. 33154 33155 -- Macro: DWARF_FRAME_REGNUM (REGNO) 33156 33157 Define this macro if the target's representation for dwarf 33158 registers used in .eh_frame or .debug_frame is different from that 33159 used in other debug info sections. Given a GCC hard register 33160 number, this macro should return the .eh_frame register number. 33161 The default is 'DBX_REGISTER_NUMBER (REGNO)'. 33162 33163 -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH) 33164 33165 Define this macro to map register numbers held in the call frame 33166 info that GCC has collected using 'DWARF_FRAME_REGNUM' to those 33167 that should be output in .debug_frame ('FOR_EH' is zero) and 33168 .eh_frame ('FOR_EH' is nonzero). The default is to return 'REGNO'. 33169 33170 -- Macro: REG_VALUE_IN_UNWIND_CONTEXT 33171 33172 Define this macro if the target stores register values as 33173 '_Unwind_Word' type in unwind context. It should be defined if 33174 target register size is larger than the size of 'void *'. The 33175 default is to store register values as 'void *' type. 33176 33177 -- Macro: ASSUME_EXTENDED_UNWIND_CONTEXT 33178 33179 Define this macro to be 1 if the target always uses extended unwind 33180 context with version, args_size and by_value fields. If it is 33181 undefined, it will be defined to 1 when 33182 'REG_VALUE_IN_UNWIND_CONTEXT' is defined and 0 otherwise. 33183 33184 -- Macro: DWARF_LAZY_REGISTER_VALUE (REGNO, VALUE) 33185 Define this macro if the target has pseudo DWARF registers whose 33186 values need to be computed lazily on demand by the unwinder (such 33187 as when referenced in a CFA expression). The macro returns true if 33188 REGNO is such a register and stores its value in '*VALUE' if so. 33189 33190 33191File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling 33192 3319318.9.5 Eliminating Frame Pointer and Arg Pointer 33194------------------------------------------------ 33195 33196This is about eliminating the frame pointer and arg pointer. 33197 33198 -- Target Hook: bool TARGET_FRAME_POINTER_REQUIRED (void) 33199 This target hook should return 'true' if a function must have and 33200 use a frame pointer. This target hook is called in the reload 33201 pass. If its return value is 'true' the function will have a frame 33202 pointer. 33203 33204 This target hook can in principle examine the current function and 33205 decide according to the facts, but on most machines the constant 33206 'false' or the constant 'true' suffices. Use 'false' when the 33207 machine allows code to be generated with no frame pointer, and 33208 doing so saves some time or space. Use 'true' when there is no 33209 possible advantage to avoiding a frame pointer. 33210 33211 In certain cases, the compiler does not know how to produce valid 33212 code without a frame pointer. The compiler recognizes those cases 33213 and automatically gives the function a frame pointer regardless of 33214 what 'targetm.frame_pointer_required' returns. You don't need to 33215 worry about them. 33216 33217 In a function that does not require a frame pointer, the frame 33218 pointer register can be allocated for ordinary usage, unless you 33219 mark it as a fixed register. See 'FIXED_REGISTERS' for more 33220 information. 33221 33222 Default return value is 'false'. 33223 33224 -- Macro: ELIMINABLE_REGS 33225 This macro specifies a table of register pairs used to eliminate 33226 unneeded registers that point into the stack frame. 33227 33228 The definition of this macro is a list of structure 33229 initializations, each of which specifies an original and 33230 replacement register. 33231 33232 On some machines, the position of the argument pointer is not known 33233 until the compilation is completed. In such a case, a separate 33234 hard register must be used for the argument pointer. This register 33235 can be eliminated by replacing it with either the frame pointer or 33236 the argument pointer, depending on whether or not the frame pointer 33237 has been eliminated. 33238 33239 In this case, you might specify: 33240 #define ELIMINABLE_REGS \ 33241 {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ 33242 {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ 33243 {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} 33244 33245 Note that the elimination of the argument pointer with the stack 33246 pointer is specified first since that is the preferred elimination. 33247 33248 -- Target Hook: bool TARGET_CAN_ELIMINATE (const int FROM_REG, const 33249 int TO_REG) 33250 This target hook should return 'true' if the compiler is allowed to 33251 try to replace register number FROM_REG with register number 33252 TO_REG. This target hook will usually be 'true', since most of the 33253 cases preventing register elimination are things that the compiler 33254 already knows about. 33255 33256 Default return value is 'true'. 33257 33258 -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR) 33259 This macro returns the initial difference between the specified 33260 pair of registers. The value would be computed from information 33261 such as the result of 'get_frame_size ()' and the tables of 33262 registers 'df_regs_ever_live_p' and 'call_used_regs'. 33263 33264 -- Target Hook: void TARGET_COMPUTE_FRAME_LAYOUT (void) 33265 This target hook is called once each time the frame layout needs to 33266 be recalculated. The calculations can be cached by the target and 33267 can then be used by 'INITIAL_ELIMINATION_OFFSET' instead of 33268 re-computing the layout on every invocation of that hook. This is 33269 particularly useful for targets that have an expensive frame layout 33270 function. Implementing this callback is optional. 33271 33272 33273File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling 33274 3327518.9.6 Passing Function Arguments on the Stack 33276---------------------------------------------- 33277 33278The macros in this section control how arguments are passed on the 33279stack. See the following section for other macros that control passing 33280certain arguments in registers. 33281 33282 -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (const_tree FNTYPE) 33283 This target hook returns 'true' if an argument declared in a 33284 prototype as an integral type smaller than 'int' should actually be 33285 passed as an 'int'. In addition to avoiding errors in certain 33286 cases of mismatch, it also makes for better code on certain 33287 machines. The default is to not promote prototypes. 33288 33289 -- Macro: PUSH_ARGS 33290 A C expression. If nonzero, push insns will be used to pass 33291 outgoing arguments. If the target machine does not have a push 33292 instruction, set it to zero. That directs GCC to use an alternate 33293 strategy: to allocate the entire argument block and then store the 33294 arguments into it. When 'PUSH_ARGS' is nonzero, 'PUSH_ROUNDING' 33295 must be defined too. 33296 33297 -- Macro: PUSH_ARGS_REVERSED 33298 A C expression. If nonzero, function arguments will be evaluated 33299 from last to first, rather than from first to last. If this macro 33300 is not defined, it defaults to 'PUSH_ARGS' on targets where the 33301 stack and args grow in opposite directions, and 0 otherwise. 33302 33303 -- Macro: PUSH_ROUNDING (NPUSHED) 33304 A C expression that is the number of bytes actually pushed onto the 33305 stack when an instruction attempts to push NPUSHED bytes. 33306 33307 On some machines, the definition 33308 33309 #define PUSH_ROUNDING(BYTES) (BYTES) 33310 33311 will suffice. But on other machines, instructions that appear to 33312 push one byte actually push two bytes in an attempt to maintain 33313 alignment. Then the definition should be 33314 33315 #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) 33316 33317 If the value of this macro has a type, it should be an unsigned 33318 type. 33319 33320 -- Macro: ACCUMULATE_OUTGOING_ARGS 33321 A C expression. If nonzero, the maximum amount of space required 33322 for outgoing arguments will be computed and placed into 33323 'crtl->outgoing_args_size'. No space will be pushed onto the stack 33324 for each call; instead, the function prologue should increase the 33325 stack frame size by this amount. 33326 33327 Setting both 'PUSH_ARGS' and 'ACCUMULATE_OUTGOING_ARGS' is not 33328 proper. 33329 33330 -- Macro: REG_PARM_STACK_SPACE (FNDECL) 33331 Define this macro if functions should assume that stack space has 33332 been allocated for arguments even when their values are passed in 33333 registers. 33334 33335 The value of this macro is the size, in bytes, of the area reserved 33336 for arguments passed in registers for the function represented by 33337 FNDECL, which can be zero if GCC is calling a library function. 33338 The argument FNDECL can be the FUNCTION_DECL, or the type itself of 33339 the function. 33340 33341 This space can be allocated by the caller, or be a part of the 33342 machine-dependent stack frame: 'OUTGOING_REG_PARM_STACK_SPACE' says 33343 which. 33344 33345 -- Macro: INCOMING_REG_PARM_STACK_SPACE (FNDECL) 33346 Like 'REG_PARM_STACK_SPACE', but for incoming register arguments. 33347 Define this macro if space guaranteed when compiling a function 33348 body is different to space required when making a call, a situation 33349 that can arise with K&R style function definitions. 33350 33351 -- Macro: OUTGOING_REG_PARM_STACK_SPACE (FNTYPE) 33352 Define this to a nonzero value if it is the responsibility of the 33353 caller to allocate the area reserved for arguments passed in 33354 registers when calling a function of FNTYPE. FNTYPE may be NULL if 33355 the function called is a library function. 33356 33357 If 'ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls 33358 whether the space for these arguments counts in the value of 33359 'crtl->outgoing_args_size'. 33360 33361 -- Macro: STACK_PARMS_IN_REG_PARM_AREA 33362 Define this macro if 'REG_PARM_STACK_SPACE' is defined, but the 33363 stack parameters don't skip the area specified by it. 33364 33365 Normally, when a parameter is not passed in registers, it is placed 33366 on the stack beyond the 'REG_PARM_STACK_SPACE' area. Defining this 33367 macro suppresses this behavior and causes the parameter to be 33368 passed on the stack in its natural location. 33369 33370 -- Target Hook: poly_int64 TARGET_RETURN_POPS_ARGS (tree FUNDECL, tree 33371 FUNTYPE, poly_int64 SIZE) 33372 This target hook returns the number of bytes of its own arguments 33373 that a function pops on returning, or 0 if the function pops no 33374 arguments and the caller must therefore pop them all after the 33375 function returns. 33376 33377 FUNDECL is a C variable whose value is a tree node that describes 33378 the function in question. Normally it is a node of type 33379 'FUNCTION_DECL' that describes the declaration of the function. 33380 From this you can obtain the 'DECL_ATTRIBUTES' of the function. 33381 33382 FUNTYPE is a C variable whose value is a tree node that describes 33383 the function in question. Normally it is a node of type 33384 'FUNCTION_TYPE' that describes the data type of the function. From 33385 this it is possible to obtain the data types of the value and 33386 arguments (if known). 33387 33388 When a call to a library function is being considered, FUNDECL will 33389 contain an identifier node for the library function. Thus, if you 33390 need to distinguish among various library functions, you can do so 33391 by their names. Note that "library function" in this context means 33392 a function used to perform arithmetic, whose name is known 33393 specially in the compiler and was not mentioned in the C code being 33394 compiled. 33395 33396 SIZE is the number of bytes of arguments passed on the stack. If a 33397 variable number of bytes is passed, it is zero, and argument 33398 popping will always be the responsibility of the calling function. 33399 33400 On the VAX, all functions always pop their arguments, so the 33401 definition of this macro is SIZE. On the 68000, using the standard 33402 calling convention, no functions pop their arguments, so the value 33403 of the macro is always 0 in this case. But an alternative calling 33404 convention is available in which functions that take a fixed number 33405 of arguments pop them but other functions (such as 'printf') pop 33406 nothing (the caller pops all). When this convention is in use, 33407 FUNTYPE is examined to determine whether a function takes a fixed 33408 number of arguments. 33409 33410 -- Macro: CALL_POPS_ARGS (CUM) 33411 A C expression that should indicate the number of bytes a call 33412 sequence pops off the stack. It is added to the value of 33413 'RETURN_POPS_ARGS' when compiling a function call. 33414 33415 CUM is the variable in which all arguments to the called function 33416 have been accumulated. 33417 33418 On certain architectures, such as the SH5, a call trampoline is 33419 used that pops certain registers off the stack, depending on the 33420 arguments that have been passed to the function. Since this is a 33421 property of the call site, not of the called function, 33422 'RETURN_POPS_ARGS' is not appropriate. 33423 33424 33425File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling 33426 3342718.9.7 Passing Arguments in Registers 33428------------------------------------- 33429 33430This section describes the macros which let you control how various 33431types of arguments are passed in registers or how they are arranged in 33432the stack. 33433 33434 -- Target Hook: rtx TARGET_FUNCTION_ARG (cumulative_args_t CA, 33435 machine_mode MODE, const_tree TYPE, bool NAMED) 33436 Return an RTX indicating whether a function argument is passed in a 33437 register and if so, which register. 33438 33439 The arguments are CA, which summarizes all the previous arguments; 33440 MODE, the machine mode of the argument; TYPE, the data type of the 33441 argument as a tree node or 0 if that is not known (which happens 33442 for C support library functions); and NAMED, which is 'true' for an 33443 ordinary argument and 'false' for nameless arguments that 33444 correspond to '...' in the called function's prototype. TYPE can 33445 be an incomplete type if a syntax error has previously occurred. 33446 33447 The return value is usually either a 'reg' RTX for the hard 33448 register in which to pass the argument, or zero to pass the 33449 argument on the stack. 33450 33451 The return value can be a 'const_int' which means argument is 33452 passed in a target specific slot with specified number. Target 33453 hooks should be used to store or load argument in such case. See 33454 'TARGET_STORE_BOUNDS_FOR_ARG' and 'TARGET_LOAD_BOUNDS_FOR_ARG' for 33455 more information. 33456 33457 The value of the expression can also be a 'parallel' RTX. This is 33458 used when an argument is passed in multiple locations. The mode of 33459 the 'parallel' should be the mode of the entire argument. The 33460 'parallel' holds any number of 'expr_list' pairs; each one 33461 describes where part of the argument is passed. In each 33462 'expr_list' the first operand must be a 'reg' RTX for the hard 33463 register in which to pass this part of the argument, and the mode 33464 of the register RTX indicates how large this part of the argument 33465 is. The second operand of the 'expr_list' is a 'const_int' which 33466 gives the offset in bytes into the entire argument of where this 33467 part starts. As a special exception the first 'expr_list' in the 33468 'parallel' RTX may have a first operand of zero. This indicates 33469 that the entire argument is also stored on the stack. 33470 33471 The last time this hook is called, it is called with 'MODE == 33472 VOIDmode', and its result is passed to the 'call' or 'call_value' 33473 pattern as operands 2 and 3 respectively. 33474 33475 The usual way to make the ISO library 'stdarg.h' work on a machine 33476 where some arguments are usually passed in registers, is to cause 33477 nameless arguments to be passed on the stack instead. This is done 33478 by making 'TARGET_FUNCTION_ARG' return 0 whenever NAMED is 'false'. 33479 33480 You may use the hook 'targetm.calls.must_pass_in_stack' in the 33481 definition of this macro to determine if this argument is of a type 33482 that must be passed in the stack. If 'REG_PARM_STACK_SPACE' is not 33483 defined and 'TARGET_FUNCTION_ARG' returns nonzero for such an 33484 argument, the compiler will abort. If 'REG_PARM_STACK_SPACE' is 33485 defined, the argument will be computed in the stack and then loaded 33486 into a register. 33487 33488 -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (machine_mode MODE, 33489 const_tree TYPE) 33490 This target hook should return 'true' if we should not pass TYPE 33491 solely in registers. The file 'expr.h' defines a definition that 33492 is usually appropriate, refer to 'expr.h' for additional 33493 documentation. 33494 33495 -- Target Hook: rtx TARGET_FUNCTION_INCOMING_ARG (cumulative_args_t CA, 33496 machine_mode MODE, const_tree TYPE, bool NAMED) 33497 Define this hook if the caller and callee on the target have 33498 different views of where arguments are passed. Also define this 33499 hook if there are functions that are never directly called, but are 33500 invoked by the hardware and which have nonstandard calling 33501 conventions. 33502 33503 In this case 'TARGET_FUNCTION_ARG' computes the register in which 33504 the caller passes the value, and 'TARGET_FUNCTION_INCOMING_ARG' 33505 should be defined in a similar fashion to tell the function being 33506 called where the arguments will arrive. 33507 33508 'TARGET_FUNCTION_INCOMING_ARG' can also return arbitrary address 33509 computation using hard register, which can be forced into a 33510 register, so that it can be used to pass special arguments. 33511 33512 If 'TARGET_FUNCTION_INCOMING_ARG' is not defined, 33513 'TARGET_FUNCTION_ARG' serves both purposes. 33514 33515 -- Target Hook: bool TARGET_USE_PSEUDO_PIC_REG (void) 33516 This hook should return 1 in case pseudo register should be created 33517 for pic_offset_table_rtx during function expand. 33518 33519 -- Target Hook: void TARGET_INIT_PIC_REG (void) 33520 Perform a target dependent initialization of pic_offset_table_rtx. 33521 This hook is called at the start of register allocation. 33522 33523 -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (cumulative_args_t CUM, 33524 machine_mode MODE, tree TYPE, bool NAMED) 33525 This target hook returns the number of bytes at the beginning of an 33526 argument that must be put in registers. The value must be zero for 33527 arguments that are passed entirely in registers or that are 33528 entirely pushed on the stack. 33529 33530 On some machines, certain arguments must be passed partially in 33531 registers and partially in memory. On these machines, typically 33532 the first few words of arguments are passed in registers, and the 33533 rest on the stack. If a multi-word argument (a 'double' or a 33534 structure) crosses that boundary, its first few words must be 33535 passed in registers and the rest must be pushed. This macro tells 33536 the compiler when this occurs, and how many bytes should go in 33537 registers. 33538 33539 'TARGET_FUNCTION_ARG' for these arguments should return the first 33540 register to be used by the caller for this argument; likewise 33541 'TARGET_FUNCTION_INCOMING_ARG', for the called function. 33542 33543 -- Target Hook: bool TARGET_PASS_BY_REFERENCE (cumulative_args_t CUM, 33544 machine_mode MODE, const_tree TYPE, bool NAMED) 33545 This target hook should return 'true' if an argument at the 33546 position indicated by CUM should be passed by reference. This 33547 predicate is queried after target independent reasons for being 33548 passed by reference, such as 'TREE_ADDRESSABLE (type)'. 33549 33550 If the hook returns true, a copy of that argument is made in memory 33551 and a pointer to the argument is passed instead of the argument 33552 itself. The pointer is passed in whatever way is appropriate for 33553 passing a pointer to that type. 33554 33555 -- Target Hook: bool TARGET_CALLEE_COPIES (cumulative_args_t CUM, 33556 machine_mode MODE, const_tree TYPE, bool NAMED) 33557 The function argument described by the parameters to this hook is 33558 known to be passed by reference. The hook should return true if 33559 the function argument should be copied by the callee instead of 33560 copied by the caller. 33561 33562 For any argument for which the hook returns true, if it can be 33563 determined that the argument is not modified, then a copy need not 33564 be generated. 33565 33566 The default version of this hook always returns false. 33567 33568 -- Macro: CUMULATIVE_ARGS 33569 A C type for declaring a variable that is used as the first 33570 argument of 'TARGET_FUNCTION_ARG' and other related values. For 33571 some target machines, the type 'int' suffices and can hold the 33572 number of bytes of argument so far. 33573 33574 There is no need to record in 'CUMULATIVE_ARGS' anything about the 33575 arguments that have been passed on the stack. The compiler has 33576 other variables to keep track of that. For target machines on 33577 which all arguments are passed on the stack, there is no need to 33578 store anything in 'CUMULATIVE_ARGS'; however, the data structure 33579 must exist and should not be empty, so use 'int'. 33580 33581 -- Macro: OVERRIDE_ABI_FORMAT (FNDECL) 33582 If defined, this macro is called before generating any code for a 33583 function, but after the CFUN descriptor for the function has been 33584 created. The back end may use this macro to update CFUN to reflect 33585 an ABI other than that which would normally be used by default. If 33586 the compiler is generating code for a compiler-generated function, 33587 FNDECL may be 'NULL'. 33588 33589 -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL, 33590 N_NAMED_ARGS) 33591 A C statement (sans semicolon) for initializing the variable CUM 33592 for the state at the beginning of the argument list. The variable 33593 has type 'CUMULATIVE_ARGS'. The value of FNTYPE is the tree node 33594 for the data type of the function which will receive the args, or 0 33595 if the args are to a compiler support library function. For direct 33596 calls that are not libcalls, FNDECL contain the declaration node of 33597 the function. FNDECL is also set when 'INIT_CUMULATIVE_ARGS' is 33598 used to find arguments for the function being compiled. 33599 N_NAMED_ARGS is set to the number of named arguments, including a 33600 structure return address if it is passed as a parameter, when 33601 making a call. When processing incoming arguments, N_NAMED_ARGS is 33602 set to -1. 33603 33604 When processing a call to a compiler support library function, 33605 LIBNAME identifies which one. It is a 'symbol_ref' rtx which 33606 contains the name of the function, as a string. LIBNAME is 0 when 33607 an ordinary C function call is being processed. Thus, each time 33608 this macro is called, either LIBNAME or FNTYPE is nonzero, but 33609 never both of them at once. 33610 33611 -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME) 33612 Like 'INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls, it 33613 gets a 'MODE' argument instead of FNTYPE, that would be 'NULL'. 33614 INDIRECT would always be zero, too. If this macro is not defined, 33615 'INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is used instead. 33616 33617 -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME) 33618 Like 'INIT_CUMULATIVE_ARGS' but overrides it for the purposes of 33619 finding the arguments for the function being compiled. If this 33620 macro is undefined, 'INIT_CUMULATIVE_ARGS' is used instead. 33621 33622 The value passed for LIBNAME is always 0, since library routines 33623 with special calling conventions are never compiled with GCC. The 33624 argument LIBNAME exists for symmetry with 'INIT_CUMULATIVE_ARGS'. 33625 33626 -- Target Hook: void TARGET_FUNCTION_ARG_ADVANCE (cumulative_args_t CA, 33627 machine_mode MODE, const_tree TYPE, bool NAMED) 33628 This hook updates the summarizer variable pointed to by CA to 33629 advance past an argument in the argument list. The values MODE, 33630 TYPE and NAMED describe that argument. Once this is done, the 33631 variable CUM is suitable for analyzing the _following_ argument 33632 with 'TARGET_FUNCTION_ARG', etc. 33633 33634 This hook need not do anything if the argument in question was 33635 passed on the stack. The compiler knows how to track the amount of 33636 stack space used for arguments without any special help. 33637 33638 -- Target Hook: HOST_WIDE_INT TARGET_FUNCTION_ARG_OFFSET (machine_mode 33639 MODE, const_tree TYPE) 33640 This hook returns the number of bytes to add to the offset of an 33641 argument of type TYPE and mode MODE when passed in memory. This is 33642 needed for the SPU, which passes 'char' and 'short' arguments in 33643 the preferred slot that is in the middle of the quad word instead 33644 of starting at the top. The default implementation returns 0. 33645 33646 -- Target Hook: pad_direction TARGET_FUNCTION_ARG_PADDING (machine_mode 33647 MODE, const_tree TYPE) 33648 This hook determines whether, and in which direction, to pad out an 33649 argument of mode MODE and type TYPE. It returns 'PAD_UPWARD' to 33650 insert padding above the argument, 'PAD_DOWNWARD' to insert padding 33651 below the argument, or 'PAD_NONE' to inhibit padding. 33652 33653 The _amount_ of padding is not controlled by this hook, but by 33654 'TARGET_FUNCTION_ARG_ROUND_BOUNDARY'. It is always just enough to 33655 reach the next multiple of that boundary. 33656 33657 This hook has a default definition that is right for most systems. 33658 For little-endian machines, the default is to pad upward. For 33659 big-endian machines, the default is to pad downward for an argument 33660 of constant size shorter than an 'int', and upward otherwise. 33661 33662 -- Macro: PAD_VARARGS_DOWN 33663 If defined, a C expression which determines whether the default 33664 implementation of va_arg will attempt to pad down before reading 33665 the next argument, if that argument is smaller than its aligned 33666 space as controlled by 'PARM_BOUNDARY'. If this macro is not 33667 defined, all such arguments are padded down if 'BYTES_BIG_ENDIAN' 33668 is true. 33669 33670 -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST) 33671 Specify padding for the last element of a block move between 33672 registers and memory. FIRST is nonzero if this is the only 33673 element. Defining this macro allows better control of register 33674 function parameters on big-endian machines, without using 33675 'PARALLEL' rtl. In particular, 'MUST_PASS_IN_STACK' need not test 33676 padding and mode of types in registers, as there is no longer a 33677 "wrong" part of a register; For example, a three byte aggregate may 33678 be passed in the high part of a register if so required. 33679 33680 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_BOUNDARY (machine_mode 33681 MODE, const_tree TYPE) 33682 This hook returns the alignment boundary, in bits, of an argument 33683 with the specified mode and type. The default hook returns 33684 'PARM_BOUNDARY' for all arguments. 33685 33686 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_ROUND_BOUNDARY 33687 (machine_mode MODE, const_tree TYPE) 33688 Normally, the size of an argument is rounded up to 'PARM_BOUNDARY', 33689 which is the default value for this hook. You can define this hook 33690 to return a different value if an argument size must be rounded to 33691 a larger value. 33692 33693 -- Macro: FUNCTION_ARG_REGNO_P (REGNO) 33694 A C expression that is nonzero if REGNO is the number of a hard 33695 register in which function arguments are sometimes passed. This 33696 does _not_ include implicit arguments such as the static chain and 33697 the structure-value address. On many machines, no registers can be 33698 used for this purpose since all function arguments are pushed on 33699 the stack. 33700 33701 -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (const_tree TYPE) 33702 This hook should return true if parameter of type TYPE are passed 33703 as two scalar parameters. By default, GCC will attempt to pack 33704 complex arguments into the target's word size. Some ABIs require 33705 complex arguments to be split and treated as their individual 33706 components. For example, on AIX64, complex floats should be passed 33707 in a pair of floating point registers, even though a complex float 33708 would fit in one 64-bit floating point register. 33709 33710 The default value of this hook is 'NULL', which is treated as 33711 always false. 33712 33713 -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void) 33714 This hook returns a type node for 'va_list' for the target. The 33715 default version of the hook returns 'void*'. 33716 33717 -- Target Hook: int TARGET_ENUM_VA_LIST_P (int IDX, const char **PNAME, 33718 tree *PTREE) 33719 This target hook is used in function 'c_common_nodes_and_builtins' 33720 to iterate through the target specific builtin types for va_list. 33721 The variable IDX is used as iterator. PNAME has to be a pointer to 33722 a 'const char *' and PTREE a pointer to a 'tree' typed variable. 33723 The arguments PNAME and PTREE are used to store the result of this 33724 macro and are set to the name of the va_list builtin type and its 33725 internal type. If the return value of this macro is zero, then 33726 there is no more element. Otherwise the IDX should be increased 33727 for the next call of this macro to iterate through all types. 33728 33729 -- Target Hook: tree TARGET_FN_ABI_VA_LIST (tree FNDECL) 33730 This hook returns the va_list type of the calling convention 33731 specified by FNDECL. The default version of this hook returns 33732 'va_list_type_node'. 33733 33734 -- Target Hook: tree TARGET_CANONICAL_VA_LIST_TYPE (tree TYPE) 33735 This hook returns the va_list type of the calling convention 33736 specified by the type of TYPE. If TYPE is not a valid va_list 33737 type, it returns 'NULL_TREE'. 33738 33739 -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree 33740 TYPE, gimple_seq *PRE_P, gimple_seq *POST_P) 33741 This hook performs target-specific gimplification of 'VA_ARG_EXPR'. 33742 The first two parameters correspond to the arguments to 'va_arg'; 33743 the latter two are as in 'gimplify.c:gimplify_expr'. 33744 33745 -- Target Hook: bool TARGET_VALID_POINTER_MODE (scalar_int_mode MODE) 33746 Define this to return nonzero if the port can handle pointers with 33747 machine mode MODE. The default version of this hook returns true 33748 for both 'ptr_mode' and 'Pmode'. 33749 33750 -- Target Hook: bool TARGET_REF_MAY_ALIAS_ERRNO (struct ao_ref *REF) 33751 Define this to return nonzero if the memory reference REF may alias 33752 with the system C library errno location. The default version of 33753 this hook assumes the system C library errno location is either a 33754 declaration of type int or accessed by dereferencing a pointer to 33755 int. 33756 33757 -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (scalar_mode MODE) 33758 Define this to return nonzero if the port is prepared to handle 33759 insns involving scalar mode MODE. For a scalar mode to be 33760 considered supported, all the basic arithmetic and comparisons must 33761 work. 33762 33763 The default version of this hook returns true for any mode required 33764 to handle the basic C types (as defined by the port). Included 33765 here are the double-word arithmetic supported by the code in 33766 'optabs.c'. 33767 33768 -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (machine_mode MODE) 33769 Define this to return nonzero if the port is prepared to handle 33770 insns involving vector mode MODE. At the very least, it must have 33771 move patterns for this mode. 33772 33773 -- Target Hook: opt_machine_mode TARGET_ARRAY_MODE (machine_mode MODE, 33774 unsigned HOST_WIDE_INT NELEMS) 33775 Return the mode that GCC should use for an array that has NELEMS 33776 elements, with each element having mode MODE. Return no mode if 33777 the target has no special requirements. In the latter case, GCC 33778 looks for an integer mode of the appropriate size if available and 33779 uses BLKmode otherwise. Usually the search for the integer mode is 33780 limited to 'MAX_FIXED_MODE_SIZE', but the 33781 'TARGET_ARRAY_MODE_SUPPORTED_P' hook allows a larger mode to be 33782 used in specific cases. 33783 33784 The main use of this hook is to specify that an array of vectors 33785 should also have a vector mode. The default implementation returns 33786 no mode. 33787 33788 -- Target Hook: bool TARGET_ARRAY_MODE_SUPPORTED_P (machine_mode MODE, 33789 unsigned HOST_WIDE_INT NELEMS) 33790 Return true if GCC should try to use a scalar mode to store an 33791 array of NELEMS elements, given that each element has mode MODE. 33792 Returning true here overrides the usual 'MAX_FIXED_MODE' limit and 33793 allows GCC to use any defined integer mode. 33794 33795 One use of this hook is to support vector load and store operations 33796 that operate on several homogeneous vectors. For example, ARM NEON 33797 has operations like: 33798 33799 int8x8x3_t vld3_s8 (const int8_t *) 33800 33801 where the return type is defined as: 33802 33803 typedef struct int8x8x3_t 33804 { 33805 int8x8_t val[3]; 33806 } int8x8x3_t; 33807 33808 If this hook allows 'val' to have a scalar mode, then 'int8x8x3_t' 33809 can have the same mode. GCC can then store 'int8x8x3_t's in 33810 registers rather than forcing them onto the stack. 33811 33812 -- Target Hook: bool TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P 33813 (scalar_float_mode MODE) 33814 Define this to return nonzero if libgcc provides support for the 33815 floating-point mode MODE, which is known to pass 33816 'TARGET_SCALAR_MODE_SUPPORTED_P'. The default version of this hook 33817 returns true for all of 'SFmode', 'DFmode', 'XFmode' and 'TFmode', 33818 if such modes exist. 33819 33820 -- Target Hook: opt_scalar_float_mode TARGET_FLOATN_MODE (int N, bool 33821 EXTENDED) 33822 Define this to return the machine mode to use for the type 33823 '_FloatN', if EXTENDED is false, or the type '_FloatNx', if 33824 EXTENDED is true. If such a type is not supported, return 33825 'opt_scalar_float_mode ()'. The default version of this hook 33826 returns 'SFmode' for '_Float32', 'DFmode' for '_Float64' and 33827 '_Float32x' and 'TFmode' for '_Float128', if those modes exist and 33828 satisfy the requirements for those types and pass 33829 'TARGET_SCALAR_MODE_SUPPORTED_P' and 33830 'TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P'; for '_Float64x', it 33831 returns the first of 'XFmode' and 'TFmode' that exists and 33832 satisfies the same requirements; for other types, it returns 33833 'opt_scalar_float_mode ()'. The hook is only called for values of 33834 N and EXTENDED that are valid according to ISO/IEC TS 18661-3:2015; 33835 that is, N is one of 32, 64, 128, or, if EXTENDED is false, 16 or 33836 greater than 128 and a multiple of 32. 33837 33838 -- Target Hook: bool TARGET_FLOATN_BUILTIN_P (int FUNC) 33839 Define this to return true if the '_FloatN' and '_FloatNx' built-in 33840 functions should implicitly enable the built-in function without 33841 the '__builtin_' prefix in addition to the normal built-in function 33842 with the '__builtin_' prefix. The default is to only enable 33843 built-in functions without the '__builtin_' prefix for the GNU C 33844 langauge. In strict ANSI/ISO mode, the built-in function without 33845 the '__builtin_' prefix is not enabled. The argument 'FUNC' is the 33846 'enum built_in_function' id of the function to be enabled. 33847 33848 -- Target Hook: bool TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P 33849 (machine_mode MODE) 33850 Define this to return nonzero for machine modes for which the port 33851 has small register classes. If this target hook returns nonzero 33852 for a given MODE, the compiler will try to minimize the lifetime of 33853 registers in MODE. The hook may be called with 'VOIDmode' as 33854 argument. In this case, the hook is expected to return nonzero if 33855 it returns nonzero for any mode. 33856 33857 On some machines, it is risky to let hard registers live across 33858 arbitrary insns. Typically, these machines have instructions that 33859 require values to be in specific registers (like an accumulator), 33860 and reload will fail if the required hard register is used for 33861 another purpose across such an insn. 33862 33863 Passes before reload do not know which hard registers will be used 33864 in an instruction, but the machine modes of the registers set or 33865 used in the instruction are already known. And for some machines, 33866 register classes are small for, say, integer registers but not for 33867 floating point registers. For example, the AMD x86-64 architecture 33868 requires specific registers for the legacy x86 integer 33869 instructions, but there are many SSE registers for floating point 33870 operations. On such targets, a good strategy may be to return 33871 nonzero from this hook for 'INTEGRAL_MODE_P' machine modes but zero 33872 for the SSE register classes. 33873 33874 The default version of this hook returns false for any mode. It is 33875 always safe to redefine this hook to return with a nonzero value. 33876 But if you unnecessarily define it, you will reduce the amount of 33877 optimizations that can be performed in some cases. If you do not 33878 define this hook to return a nonzero value when it is required, the 33879 compiler will run out of spill registers and print a fatal error 33880 message. 33881 33882 33883File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling 33884 3388518.9.8 How Scalar Function Values Are Returned 33886---------------------------------------------- 33887 33888This section discusses the macros that control returning scalars as 33889values--values that can fit in registers. 33890 33891 -- Target Hook: rtx TARGET_FUNCTION_VALUE (const_tree RET_TYPE, 33892 const_tree FN_DECL_OR_TYPE, bool OUTGOING) 33893 33894 Define this to return an RTX representing the place where a 33895 function returns or receives a value of data type RET_TYPE, a tree 33896 node representing a data type. FN_DECL_OR_TYPE is a tree node 33897 representing 'FUNCTION_DECL' or 'FUNCTION_TYPE' of a function being 33898 called. If OUTGOING is false, the hook should compute the register 33899 in which the caller will see the return value. Otherwise, the hook 33900 should return an RTX representing the place where a function 33901 returns a value. 33902 33903 On many machines, only 'TYPE_MODE (RET_TYPE)' is relevant. 33904 (Actually, on most machines, scalar values are returned in the same 33905 place regardless of mode.) The value of the expression is usually 33906 a 'reg' RTX for the hard register where the return value is stored. 33907 The value can also be a 'parallel' RTX, if the return value is in 33908 multiple places. See 'TARGET_FUNCTION_ARG' for an explanation of 33909 the 'parallel' form. Note that the callee will populate every 33910 location specified in the 'parallel', but if the first element of 33911 the 'parallel' contains the whole return value, callers will use 33912 that element as the canonical location and ignore the others. The 33913 m68k port uses this type of 'parallel' to return pointers in both 33914 '%a0' (the canonical location) and '%d0'. 33915 33916 If 'TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply 33917 the same promotion rules specified in 'PROMOTE_MODE' if VALTYPE is 33918 a scalar type. 33919 33920 If the precise function being called is known, FUNC is a tree node 33921 ('FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This 33922 makes it possible to use a different value-returning convention for 33923 specific functions when all their calls are known. 33924 33925 Some target machines have "register windows" so that the register 33926 in which a function returns its value is not the same as the one in 33927 which the caller sees the value. For such machines, you should 33928 return different RTX depending on OUTGOING. 33929 33930 'TARGET_FUNCTION_VALUE' is not used for return values with 33931 aggregate data types, because these are returned in another way. 33932 See 'TARGET_STRUCT_VALUE_RTX' and related macros, below. 33933 33934 -- Macro: FUNCTION_VALUE (VALTYPE, FUNC) 33935 This macro has been deprecated. Use 'TARGET_FUNCTION_VALUE' for a 33936 new target instead. 33937 33938 -- Macro: LIBCALL_VALUE (MODE) 33939 A C expression to create an RTX representing the place where a 33940 library function returns a value of mode MODE. 33941 33942 Note that "library function" in this context means a compiler 33943 support routine, used to perform arithmetic, whose name is known 33944 specially by the compiler and was not mentioned in the C code being 33945 compiled. 33946 33947 -- Target Hook: rtx TARGET_LIBCALL_VALUE (machine_mode MODE, const_rtx 33948 FUN) 33949 Define this hook if the back-end needs to know the name of the 33950 libcall function in order to determine where the result should be 33951 returned. 33952 33953 The mode of the result is given by MODE and the name of the called 33954 library function is given by FUN. The hook should return an RTX 33955 representing the place where the library function result will be 33956 returned. 33957 33958 If this hook is not defined, then LIBCALL_VALUE will be used. 33959 33960 -- Macro: FUNCTION_VALUE_REGNO_P (REGNO) 33961 A C expression that is nonzero if REGNO is the number of a hard 33962 register in which the values of called function may come back. 33963 33964 A register whose use for returning values is limited to serving as 33965 the second of a pair (for a value of type 'double', say) need not 33966 be recognized by this macro. So for most machines, this definition 33967 suffices: 33968 33969 #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) 33970 33971 If the machine has register windows, so that the caller and the 33972 called function use different registers for the return value, this 33973 macro should recognize only the caller's register numbers. 33974 33975 This macro has been deprecated. Use 33976 'TARGET_FUNCTION_VALUE_REGNO_P' for a new target instead. 33977 33978 -- Target Hook: bool TARGET_FUNCTION_VALUE_REGNO_P (const unsigned int 33979 REGNO) 33980 A target hook that return 'true' if REGNO is the number of a hard 33981 register in which the values of called function may come back. 33982 33983 A register whose use for returning values is limited to serving as 33984 the second of a pair (for a value of type 'double', say) need not 33985 be recognized by this target hook. 33986 33987 If the machine has register windows, so that the caller and the 33988 called function use different registers for the return value, this 33989 target hook should recognize only the caller's register numbers. 33990 33991 If this hook is not defined, then FUNCTION_VALUE_REGNO_P will be 33992 used. 33993 33994 -- Macro: APPLY_RESULT_SIZE 33995 Define this macro if 'untyped_call' and 'untyped_return' need more 33996 space than is implied by 'FUNCTION_VALUE_REGNO_P' for saving and 33997 restoring an arbitrary return value. 33998 33999 -- Target Hook: bool TARGET_OMIT_STRUCT_RETURN_REG 34000 Normally, when a function returns a structure by memory, the 34001 address is passed as an invisible pointer argument, but the 34002 compiler also arranges to return the address from the function like 34003 it would a normal pointer return value. Define this to true if 34004 that behavior is undesirable on your target. 34005 34006 -- Target Hook: bool TARGET_RETURN_IN_MSB (const_tree TYPE) 34007 This hook should return true if values of type TYPE are returned at 34008 the most significant end of a register (in other words, if they are 34009 padded at the least significant end). You can assume that TYPE is 34010 returned in a register; the caller is required to check this. 34011 34012 Note that the register provided by 'TARGET_FUNCTION_VALUE' must be 34013 able to hold the complete return value. For example, if a 1-, 2- 34014 or 3-byte structure is returned at the most significant end of a 34015 4-byte register, 'TARGET_FUNCTION_VALUE' should provide an 'SImode' 34016 rtx. 34017 34018 34019File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling 34020 3402118.9.9 How Large Values Are Returned 34022------------------------------------ 34023 34024When a function value's mode is 'BLKmode' (and in some other cases), the 34025value is not returned according to 'TARGET_FUNCTION_VALUE' (*note Scalar 34026Return::). Instead, the caller passes the address of a block of memory 34027in which the value should be stored. This address is called the 34028"structure value address". 34029 34030 This section describes how to control returning structure values in 34031memory. 34032 34033 -- Target Hook: bool TARGET_RETURN_IN_MEMORY (const_tree TYPE, 34034 const_tree FNTYPE) 34035 This target hook should return a nonzero value to say to return the 34036 function value in memory, just as large structures are always 34037 returned. Here TYPE will be the data type of the value, and FNTYPE 34038 will be the type of the function doing the returning, or 'NULL' for 34039 libcalls. 34040 34041 Note that values of mode 'BLKmode' must be explicitly handled by 34042 this function. Also, the option '-fpcc-struct-return' takes effect 34043 regardless of this macro. On most systems, it is possible to leave 34044 the hook undefined; this causes a default definition to be used, 34045 whose value is the constant 1 for 'BLKmode' values, and 0 34046 otherwise. 34047 34048 Do not use this hook to indicate that structures and unions should 34049 always be returned in memory. You should instead use 34050 'DEFAULT_PCC_STRUCT_RETURN' to indicate this. 34051 34052 -- Macro: DEFAULT_PCC_STRUCT_RETURN 34053 Define this macro to be 1 if all structure and union return values 34054 must be in memory. Since this results in slower code, this should 34055 be defined only if needed for compatibility with other compilers or 34056 with an ABI. If you define this macro to be 0, then the 34057 conventions used for structure and union return values are decided 34058 by the 'TARGET_RETURN_IN_MEMORY' target hook. 34059 34060 If not defined, this defaults to the value 1. 34061 34062 -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING) 34063 This target hook should return the location of the structure value 34064 address (normally a 'mem' or 'reg'), or 0 if the address is passed 34065 as an "invisible" first argument. Note that FNDECL may be 'NULL', 34066 for libcalls. You do not need to define this target hook if the 34067 address is always passed as an "invisible" first argument. 34068 34069 On some architectures the place where the structure value address 34070 is found by the called function is not the same place that the 34071 caller put it. This can be due to register windows, or it could be 34072 because the function prologue moves it to a different place. 34073 INCOMING is '1' or '2' when the location is needed in the context 34074 of the called function, and '0' in the context of the caller. 34075 34076 If INCOMING is nonzero and the address is to be found on the stack, 34077 return a 'mem' which refers to the frame pointer. If INCOMING is 34078 '2', the result is being used to fetch the structure value address 34079 at the beginning of a function. If you need to emit adjusting 34080 code, you should do it at this point. 34081 34082 -- Macro: PCC_STATIC_STRUCT_RETURN 34083 Define this macro if the usual system convention on the target 34084 machine for returning structures and unions is for the called 34085 function to return the address of a static variable containing the 34086 value. 34087 34088 Do not define this if the usual system convention is for the caller 34089 to pass an address to the subroutine. 34090 34091 This macro has effect in '-fpcc-struct-return' mode, but it does 34092 nothing when you use '-freg-struct-return' mode. 34093 34094 -- Target Hook: fixed_size_mode TARGET_GET_RAW_RESULT_MODE (int REGNO) 34095 This target hook returns the mode to be used when accessing raw 34096 return registers in '__builtin_return'. Define this macro if the 34097 value in REG_RAW_MODE is not correct. 34098 34099 -- Target Hook: fixed_size_mode TARGET_GET_RAW_ARG_MODE (int REGNO) 34100 This target hook returns the mode to be used when accessing raw 34101 argument registers in '__builtin_apply_args'. Define this macro if 34102 the value in REG_RAW_MODE is not correct. 34103 34104 -- Target Hook: bool TARGET_EMPTY_RECORD_P (const_tree TYPE) 34105 This target hook returns true if the type is an empty record. The 34106 default is to return 'false'. 34107 34108 -- Target Hook: void TARGET_WARN_PARAMETER_PASSING_ABI 34109 (cumulative_args_t CA, tree TYPE) 34110 This target hook warns about the change in empty class parameter 34111 passing ABI. 34112 34113 34114File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling 34115 3411618.9.10 Caller-Saves Register Allocation 34117---------------------------------------- 34118 34119If you enable it, GCC can save registers around function calls. This 34120makes it possible to use call-clobbered registers to hold variables that 34121must live across calls. 34122 34123 -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS) 34124 A C expression specifying which mode is required for saving NREGS 34125 of a pseudo-register in call-clobbered hard register REGNO. If 34126 REGNO is unsuitable for caller save, 'VOIDmode' should be returned. 34127 For most machines this macro need not be defined since GCC will 34128 select the smallest suitable mode. 34129 34130 34131File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling 34132 3413318.9.11 Function Entry and Exit 34134------------------------------- 34135 34136This section describes the macros that output function entry 34137("prologue") and exit ("epilogue") code. 34138 34139 -- Target Hook: void TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY (FILE 34140 *FILE, unsigned HOST_WIDE_INT PATCH_AREA_SIZE, bool RECORD_P) 34141 Generate a patchable area at the function start, consisting of 34142 PATCH_AREA_SIZE NOP instructions. If the target supports named 34143 sections and if RECORD_P is true, insert a pointer to the current 34144 location in the table of patchable functions. The default 34145 implementation of the hook places the table of pointers in the 34146 special section named '__patchable_function_entries'. 34147 34148 -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE) 34149 If defined, a function that outputs the assembler code for entry to 34150 a function. The prologue is responsible for setting up the stack 34151 frame, initializing the frame pointer register, saving registers 34152 that must be saved, and allocating SIZE additional bytes of storage 34153 for the local variables. FILE is a stdio stream to which the 34154 assembler code should be output. 34155 34156 The label for the beginning of the function need not be output by 34157 this macro. That has already been done when the macro is run. 34158 34159 To determine which registers to save, the macro can refer to the 34160 array 'regs_ever_live': element R is nonzero if hard register R is 34161 used anywhere within the function. This implies the function 34162 prologue should save register R, provided it is not one of the 34163 call-used registers. ('TARGET_ASM_FUNCTION_EPILOGUE' must likewise 34164 use 'regs_ever_live'.) 34165 34166 On machines that have "register windows", the function entry code 34167 does not save on the stack the registers that are in the windows, 34168 even if they are supposed to be preserved by function calls; 34169 instead it takes appropriate steps to "push" the register stack, if 34170 any non-call-used registers are used in the function. 34171 34172 On machines where functions may or may not have frame-pointers, the 34173 function entry code must vary accordingly; it must set up the frame 34174 pointer if one is wanted, and not otherwise. To determine whether 34175 a frame pointer is in wanted, the macro can refer to the variable 34176 'frame_pointer_needed'. The variable's value will be 1 at run time 34177 in a function that needs a frame pointer. *Note Elimination::. 34178 34179 The function entry code is responsible for allocating any stack 34180 space required for the function. This stack space consists of the 34181 regions listed below. In most cases, these regions are allocated 34182 in the order listed, with the last listed region closest to the top 34183 of the stack (the lowest address if 'STACK_GROWS_DOWNWARD' is 34184 defined, and the highest address if it is not defined). You can 34185 use a different order for a machine if doing so is more convenient 34186 or required for compatibility reasons. Except in cases where 34187 required by standard or by a debugger, there is no reason why the 34188 stack layout used by GCC need agree with that used by other 34189 compilers for a machine. 34190 34191 -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE) 34192 If defined, a function that outputs assembler code at the end of a 34193 prologue. This should be used when the function prologue is being 34194 emitted as RTL, and you have some extra assembler that needs to be 34195 emitted. *Note prologue instruction pattern::. 34196 34197 -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE) 34198 If defined, a function that outputs assembler code at the start of 34199 an epilogue. This should be used when the function epilogue is 34200 being emitted as RTL, and you have some extra assembler that needs 34201 to be emitted. *Note epilogue instruction pattern::. 34202 34203 -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE) 34204 If defined, a function that outputs the assembler code for exit 34205 from a function. The epilogue is responsible for restoring the 34206 saved registers and stack pointer to their values when the function 34207 was called, and returning control to the caller. This macro takes 34208 the same argument as the macro 'TARGET_ASM_FUNCTION_PROLOGUE', and 34209 the registers to restore are determined from 'regs_ever_live' and 34210 'CALL_USED_REGISTERS' in the same way. 34211 34212 On some machines, there is a single instruction that does all the 34213 work of returning from the function. On these machines, give that 34214 instruction the name 'return' and do not define the macro 34215 'TARGET_ASM_FUNCTION_EPILOGUE' at all. 34216 34217 Do not define a pattern named 'return' if you want the 34218 'TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target 34219 switches to control whether return instructions or epilogues are 34220 used, define a 'return' pattern with a validity condition that 34221 tests the target switches appropriately. If the 'return' pattern's 34222 validity condition is false, epilogues will be used. 34223 34224 On machines where functions may or may not have frame-pointers, the 34225 function exit code must vary accordingly. Sometimes the code for 34226 these two cases is completely different. To determine whether a 34227 frame pointer is wanted, the macro can refer to the variable 34228 'frame_pointer_needed'. The variable's value will be 1 when 34229 compiling a function that needs a frame pointer. 34230 34231 Normally, 'TARGET_ASM_FUNCTION_PROLOGUE' and 34232 'TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially. 34233 The C variable 'current_function_is_leaf' is nonzero for such a 34234 function. *Note Leaf Functions::. 34235 34236 On some machines, some functions pop their arguments on exit while 34237 others leave that for the caller to do. For example, the 68020 34238 when given '-mrtd' pops arguments in functions that take a fixed 34239 number of arguments. 34240 34241 Your definition of the macro 'RETURN_POPS_ARGS' decides which 34242 functions pop their own arguments. 'TARGET_ASM_FUNCTION_EPILOGUE' 34243 needs to know what was decided. The number of bytes of the current 34244 function's arguments that this function should pop is available in 34245 'crtl->args.pops_args'. *Note Scalar Return::. 34246 34247 * A region of 'crtl->args.pretend_args_size' bytes of uninitialized 34248 space just underneath the first argument arriving on the stack. 34249 (This may not be at the very start of the allocated stack region if 34250 the calling sequence has pushed anything else since pushing the 34251 stack arguments. But usually, on such machines, nothing else has 34252 been pushed yet, because the function prologue itself does all the 34253 pushing.) This region is used on machines where an argument may be 34254 passed partly in registers and partly in memory, and, in some cases 34255 to support the features in '<stdarg.h>'. 34256 34257 * An area of memory used to save certain registers used by the 34258 function. The size of this area, which may also include space for 34259 such things as the return address and pointers to previous stack 34260 frames, is machine-specific and usually depends on which registers 34261 have been used in the function. Machines with register windows 34262 often do not require a save area. 34263 34264 * A region of at least SIZE bytes, possibly rounded up to an 34265 allocation boundary, to contain the local variables of the 34266 function. On some machines, this region and the save area may 34267 occur in the opposite order, with the save area closer to the top 34268 of the stack. 34269 34270 * Optionally, when 'ACCUMULATE_OUTGOING_ARGS' is defined, a region of 34271 'crtl->outgoing_args_size' bytes to be used for outgoing argument 34272 lists of the function. *Note Stack Arguments::. 34273 34274 -- Macro: EXIT_IGNORE_STACK 34275 Define this macro as a C expression that is nonzero if the return 34276 instruction or the function epilogue ignores the value of the stack 34277 pointer; in other words, if it is safe to delete an instruction to 34278 adjust the stack pointer before a return from the function. The 34279 default is 0. 34280 34281 Note that this macro's value is relevant only for functions for 34282 which frame pointers are maintained. It is never safe to delete a 34283 final stack adjustment in a function that has no frame pointer, and 34284 the compiler knows this regardless of 'EXIT_IGNORE_STACK'. 34285 34286 -- Macro: EPILOGUE_USES (REGNO) 34287 Define this macro as a C expression that is nonzero for registers 34288 that are used by the epilogue or the 'return' pattern. The stack 34289 and frame pointer registers are already assumed to be used as 34290 needed. 34291 34292 -- Macro: EH_USES (REGNO) 34293 Define this macro as a C expression that is nonzero for registers 34294 that are used by the exception handling mechanism, and so should be 34295 considered live on entry to an exception edge. 34296 34297 -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree 34298 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT VCALL_OFFSET, 34299 tree FUNCTION) 34300 A function that outputs the assembler code for a thunk function, 34301 used to implement C++ virtual function calls with multiple 34302 inheritance. The thunk acts as a wrapper around a virtual 34303 function, adjusting the implicit object parameter before handing 34304 control off to the real function. 34305 34306 First, emit code to add the integer DELTA to the location that 34307 contains the incoming first argument. Assume that this argument 34308 contains a pointer, and is the one used to pass the 'this' pointer 34309 in C++. This is the incoming argument _before_ the function 34310 prologue, e.g. '%o0' on a sparc. The addition must preserve the 34311 values of all other incoming arguments. 34312 34313 Then, if VCALL_OFFSET is nonzero, an additional adjustment should 34314 be made after adding 'delta'. In particular, if P is the adjusted 34315 pointer, the following adjustment should be made: 34316 34317 p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)] 34318 34319 After the additions, emit code to jump to FUNCTION, which is a 34320 'FUNCTION_DECL'. This is a direct pure jump, not a call, and does 34321 not touch the return address. Hence returning from FUNCTION will 34322 return to whoever called the current 'thunk'. 34323 34324 The effect must be as if FUNCTION had been called directly with the 34325 adjusted first argument. This macro is responsible for emitting 34326 all of the code for a thunk function; 34327 'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE' 34328 are not invoked. 34329 34330 The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already 34331 been extracted from it.) It might possibly be useful on some 34332 targets, but probably not. 34333 34334 If you do not define this macro, the target-independent code in the 34335 C++ front end will generate a less efficient heavyweight thunk that 34336 calls FUNCTION instead of jumping to it. The generic approach does 34337 not support varargs. 34338 34339 -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (const_tree 34340 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT VCALL_OFFSET, 34341 const_tree FUNCTION) 34342 A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would be 34343 able to output the assembler code for the thunk function specified 34344 by the arguments it is passed, and false otherwise. In the latter 34345 case, the generic approach will be used by the C++ front end, with 34346 the limitations previously exposed. 34347 34348 34349File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling 34350 3435118.9.12 Generating Code for Profiling 34352------------------------------------- 34353 34354These macros will help you generate code for profiling. 34355 34356 -- Macro: FUNCTION_PROFILER (FILE, LABELNO) 34357 A C statement or compound statement to output to FILE some 34358 assembler code to call the profiling subroutine 'mcount'. 34359 34360 The details of how 'mcount' expects to be called are determined by 34361 your operating system environment, not by GCC. To figure them out, 34362 compile a small program for profiling using the system's installed 34363 C compiler and look at the assembler code that results. 34364 34365 Older implementations of 'mcount' expect the address of a counter 34366 variable to be loaded into some register. The name of this 34367 variable is 'LP' followed by the number LABELNO, so you would 34368 generate the name using 'LP%d' in a 'fprintf'. 34369 34370 -- Macro: PROFILE_HOOK 34371 A C statement or compound statement to output to FILE some assembly 34372 code to call the profiling subroutine 'mcount' even the target does 34373 not support profiling. 34374 34375 -- Macro: NO_PROFILE_COUNTERS 34376 Define this macro to be an expression with a nonzero value if the 34377 'mcount' subroutine on your system does not need a counter variable 34378 allocated for each function. This is true for almost all modern 34379 implementations. If you define this macro, you must not use the 34380 LABELNO argument to 'FUNCTION_PROFILER'. 34381 34382 -- Macro: PROFILE_BEFORE_PROLOGUE 34383 Define this macro if the code for function profiling should come 34384 before the function prologue. Normally, the profiling code comes 34385 after. 34386 34387 -- Target Hook: bool TARGET_KEEP_LEAF_WHEN_PROFILED (void) 34388 This target hook returns true if the target wants the leaf flag for 34389 the current function to stay true even if it calls mcount. This 34390 might make sense for targets using the leaf flag only to determine 34391 whether a stack frame needs to be generated or not and for which 34392 the call to mcount is generated before the function prologue. 34393 34394 34395File: gccint.info, Node: Tail Calls, Next: Shrink-wrapping separate components, Prev: Profiling, Up: Stack and Calling 34396 3439718.9.13 Permitting tail calls 34398----------------------------- 34399 34400 -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree 34401 EXP) 34402 True if it is OK to do sibling call optimization for the specified 34403 call expression EXP. DECL will be the called function, or 'NULL' 34404 if this is an indirect call. 34405 34406 It is not uncommon for limitations of calling conventions to 34407 prevent tail calls to functions outside the current unit of 34408 translation, or during PIC compilation. The hook is used to 34409 enforce these restrictions, as the 'sibcall' md pattern can not 34410 fail, or fall over to a "normal" call. The criteria for successful 34411 sibling call optimization may vary greatly between different 34412 architectures. 34413 34414 -- Target Hook: void TARGET_EXTRA_LIVE_ON_ENTRY (bitmap REGS) 34415 Add any hard registers to REGS that are live on entry to the 34416 function. This hook only needs to be defined to provide registers 34417 that cannot be found by examination of FUNCTION_ARG_REGNO_P, the 34418 callee saved registers, STATIC_CHAIN_INCOMING_REGNUM, 34419 STATIC_CHAIN_REGNUM, TARGET_STRUCT_VALUE_RTX, FRAME_POINTER_REGNUM, 34420 EH_USES, FRAME_POINTER_REGNUM, ARG_POINTER_REGNUM, and the 34421 PIC_OFFSET_TABLE_REGNUM. 34422 34423 -- Target Hook: void TARGET_SET_UP_BY_PROLOGUE (struct 34424 hard_reg_set_container *) 34425 This hook should add additional registers that are computed by the 34426 prologue to the hard regset for shrink-wrapping optimization 34427 purposes. 34428 34429 -- Target Hook: bool TARGET_WARN_FUNC_RETURN (tree) 34430 True if a function's return statements should be checked for 34431 matching the function's return type. This includes checking for 34432 falling off the end of a non-void function. Return false if no 34433 such check should be made. 34434 34435 34436File: gccint.info, Node: Shrink-wrapping separate components, Next: Stack Smashing Protection, Prev: Tail Calls, Up: Stack and Calling 34437 3443818.9.14 Shrink-wrapping separate components 34439------------------------------------------- 34440 34441The prologue may perform a variety of target dependent tasks such as 34442saving callee-saved registers, saving the return address, aligning the 34443stack, creating a stack frame, initializing the PIC register, setting up 34444the static chain, etc. 34445 34446 On some targets some of these tasks may be independent of others and 34447thus may be shrink-wrapped separately. These independent tasks are 34448referred to as components and are handled generically by the target 34449independent parts of GCC. 34450 34451 Using the following hooks those prologue or epilogue components can be 34452shrink-wrapped separately, so that the initialization (and possibly 34453teardown) those components do is not done as frequently on execution 34454paths where this would unnecessary. 34455 34456 What exactly those components are is up to the target code; the generic 34457code treats them abstractly, as a bit in an 'sbitmap'. These 'sbitmap's 34458are allocated by the 'shrink_wrap.get_separate_components' and 34459'shrink_wrap.components_for_bb' hooks, and deallocated by the generic 34460code. 34461 34462 -- Target Hook: sbitmap TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS 34463 (void) 34464 This hook should return an 'sbitmap' with the bits set for those 34465 components that can be separately shrink-wrapped in the current 34466 function. Return 'NULL' if the current function should not get any 34467 separate shrink-wrapping. Don't define this hook if it would 34468 always return 'NULL'. If it is defined, the other hooks in this 34469 group have to be defined as well. 34470 34471 -- Target Hook: sbitmap TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB 34472 (basic_block) 34473 This hook should return an 'sbitmap' with the bits set for those 34474 components where either the prologue component has to be executed 34475 before the 'basic_block', or the epilogue component after it, or 34476 both. 34477 34478 -- Target Hook: void TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS (sbitmap 34479 COMPONENTS, edge E, sbitmap EDGE_COMPONENTS, bool IS_PROLOGUE) 34480 This hook should clear the bits in the COMPONENTS bitmap for those 34481 components in EDGE_COMPONENTS that the target cannot handle on edge 34482 E, where IS_PROLOGUE says if this is for a prologue or an epilogue 34483 instead. 34484 34485 -- Target Hook: void TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS 34486 (sbitmap) 34487 Emit prologue insns for the components indicated by the parameter. 34488 34489 -- Target Hook: void TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS 34490 (sbitmap) 34491 Emit epilogue insns for the components indicated by the parameter. 34492 34493 -- Target Hook: void TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS 34494 (sbitmap) 34495 Mark the components in the parameter as handled, so that the 34496 'prologue' and 'epilogue' named patterns know to ignore those 34497 components. The target code should not hang on to the 'sbitmap', 34498 it will be deleted after this call. 34499 34500 34501File: gccint.info, Node: Stack Smashing Protection, Next: Miscellaneous Register Hooks, Prev: Shrink-wrapping separate components, Up: Stack and Calling 34502 3450318.9.15 Stack smashing protection 34504--------------------------------- 34505 34506 -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void) 34507 This hook returns a 'DECL' node for the external variable to use 34508 for the stack protection guard. This variable is initialized by 34509 the runtime to some random value and is used to initialize the 34510 guard value that is placed at the top of the local stack frame. 34511 The type of this variable must be 'ptr_type_node'. 34512 34513 The default version of this hook creates a variable called 34514 '__stack_chk_guard', which is normally defined in 'libgcc2.c'. 34515 34516 -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void) 34517 This hook returns a 'CALL_EXPR' that alerts the runtime that the 34518 stack protect guard variable has been modified. This expression 34519 should involve a call to a 'noreturn' function. 34520 34521 The default version of this hook invokes a function called 34522 '__stack_chk_fail', taking no arguments. This function is normally 34523 defined in 'libgcc2.c'. 34524 34525 -- Target Hook: bool TARGET_STACK_PROTECT_RUNTIME_ENABLED_P (void) 34526 Returns true if the target wants GCC's default stack protect 34527 runtime support, otherwise return false. The default 34528 implementation always returns true. 34529 34530 -- Common Target Hook: bool TARGET_SUPPORTS_SPLIT_STACK (bool REPORT, 34531 struct gcc_options *OPTS) 34532 Whether this target supports splitting the stack when the options 34533 described in OPTS have been passed. This is called after options 34534 have been parsed, so the target may reject splitting the stack in 34535 some configurations. The default version of this hook returns 34536 false. If REPORT is true, this function may issue a warning or 34537 error; if REPORT is false, it must simply return a value 34538 34539 34540File: gccint.info, Node: Miscellaneous Register Hooks, Prev: Stack Smashing Protection, Up: Stack and Calling 34541 3454218.9.16 Miscellaneous register hooks 34543------------------------------------ 34544 34545 -- Target Hook: bool TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS 34546 Set to true if each call that binds to a local definition 34547 explicitly clobbers or sets all non-fixed registers modified by 34548 performing the call. That is, by the call pattern itself, or by 34549 code that might be inserted by the linker (e.g. stubs, veneers, 34550 branch islands), but not including those modifiable by the callee. 34551 The affected registers may be mentioned explicitly in the call 34552 pattern, or included as clobbers in CALL_INSN_FUNCTION_USAGE. The 34553 default version of this hook is set to false. The purpose of this 34554 hook is to enable the fipa-ra optimization. 34555 34556 34557File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros 34558 3455918.10 Implementing the Varargs Macros 34560===================================== 34561 34562GCC comes with an implementation of '<varargs.h>' and '<stdarg.h>' that 34563work without change on machines that pass arguments on the stack. Other 34564machines require their own implementations of varargs, and the two 34565machine independent header files must have conditionals to include it. 34566 34567 ISO '<stdarg.h>' differs from traditional '<varargs.h>' mainly in the 34568calling convention for 'va_start'. The traditional implementation takes 34569just one argument, which is the variable in which to store the argument 34570pointer. The ISO implementation of 'va_start' takes an additional 34571second argument. The user is supposed to write the last named argument 34572of the function here. 34573 34574 However, 'va_start' should not use this argument. The way to find the 34575end of the named arguments is with the built-in functions described 34576below. 34577 34578 -- Macro: __builtin_saveregs () 34579 Use this built-in function to save the argument registers in memory 34580 so that the varargs mechanism can access them. Both ISO and 34581 traditional versions of 'va_start' must use '__builtin_saveregs', 34582 unless you use 'TARGET_SETUP_INCOMING_VARARGS' (see below) instead. 34583 34584 On some machines, '__builtin_saveregs' is open-coded under the 34585 control of the target hook 'TARGET_EXPAND_BUILTIN_SAVEREGS'. On 34586 other machines, it calls a routine written in assembler language, 34587 found in 'libgcc2.c'. 34588 34589 Code generated for the call to '__builtin_saveregs' appears at the 34590 beginning of the function, as opposed to where the call to 34591 '__builtin_saveregs' is written, regardless of what the code is. 34592 This is because the registers must be saved before the function 34593 starts to use them for its own purposes. 34594 34595 -- Macro: __builtin_next_arg (LASTARG) 34596 This builtin returns the address of the first anonymous stack 34597 argument, as type 'void *'. If 'ARGS_GROW_DOWNWARD', it returns 34598 the address of the location above the first anonymous stack 34599 argument. Use it in 'va_start' to initialize the pointer for 34600 fetching arguments from the stack. Also use it in 'va_start' to 34601 verify that the second parameter LASTARG is the last named argument 34602 of the current function. 34603 34604 -- Macro: __builtin_classify_type (OBJECT) 34605 Since each machine has its own conventions for which data types are 34606 passed in which kind of register, your implementation of 'va_arg' 34607 has to embody these conventions. The easiest way to categorize the 34608 specified data type is to use '__builtin_classify_type' together 34609 with 'sizeof' and '__alignof__'. 34610 34611 '__builtin_classify_type' ignores the value of OBJECT, considering 34612 only its data type. It returns an integer describing what kind of 34613 type that is--integer, floating, pointer, structure, and so on. 34614 34615 The file 'typeclass.h' defines an enumeration that you can use to 34616 interpret the values of '__builtin_classify_type'. 34617 34618 These machine description macros help implement varargs: 34619 34620 -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void) 34621 If defined, this hook produces the machine-specific code for a call 34622 to '__builtin_saveregs'. This code will be moved to the very 34623 beginning of the function, before any parameter access are made. 34624 The return value of this function should be an RTX that contains 34625 the value to use as the return of '__builtin_saveregs'. 34626 34627 -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (cumulative_args_t 34628 ARGS_SO_FAR, machine_mode MODE, tree TYPE, int 34629 *PRETEND_ARGS_SIZE, int SECOND_TIME) 34630 This target hook offers an alternative to using 34631 '__builtin_saveregs' and defining the hook 34632 'TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous 34633 register arguments into the stack so that all the arguments appear 34634 to have been passed consecutively on the stack. Once this is done, 34635 you can use the standard implementation of varargs that works for 34636 machines that pass all their arguments on the stack. 34637 34638 The argument ARGS_SO_FAR points to the 'CUMULATIVE_ARGS' data 34639 structure, containing the values that are obtained after processing 34640 the named arguments. The arguments MODE and TYPE describe the last 34641 named argument--its machine mode and its data type as a tree node. 34642 34643 The target hook should do two things: first, push onto the stack 34644 all the argument registers _not_ used for the named arguments, and 34645 second, store the size of the data thus pushed into the 34646 'int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value 34647 that you store here will serve as additional offset for setting up 34648 the stack frame. 34649 34650 Because you must generate code to push the anonymous arguments at 34651 compile time without knowing their data types, 34652 'TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that 34653 have just a single category of argument register and use it 34654 uniformly for all data types. 34655 34656 If the argument SECOND_TIME is nonzero, it means that the arguments 34657 of the function are being analyzed for the second time. This 34658 happens for an inline function, which is not actually compiled 34659 until the end of the source file. The hook 34660 'TARGET_SETUP_INCOMING_VARARGS' should not generate any 34661 instructions in this case. 34662 34663 -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (cumulative_args_t 34664 CA) 34665 Define this hook to return 'true' if the location where a function 34666 argument is passed depends on whether or not it is a named 34667 argument. 34668 34669 This hook controls how the NAMED argument to 'TARGET_FUNCTION_ARG' 34670 is set for varargs and stdarg functions. If this hook returns 34671 'true', the NAMED argument is always true for named arguments, and 34672 false for unnamed arguments. If it returns 'false', but 34673 'TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns 'true', then all 34674 arguments are treated as named. Otherwise, all named arguments 34675 except the last are treated as named. 34676 34677 You need not define this hook if it always returns 'false'. 34678 34679 -- Target Hook: void TARGET_CALL_ARGS (rtx, TREE) 34680 While generating RTL for a function call, this target hook is 34681 invoked once for each argument passed to the function, either a 34682 register returned by 'TARGET_FUNCTION_ARG' or a memory location. 34683 It is called just before the point where argument registers are 34684 stored. The type of the function to be called is also passed as 34685 the second argument; it is 'NULL_TREE' for libcalls. The 34686 'TARGET_END_CALL_ARGS' hook is invoked just after the code to copy 34687 the return reg has been emitted. This functionality can be used to 34688 perform special setup of call argument registers if a target needs 34689 it. For functions without arguments, the hook is called once with 34690 'pc_rtx' passed instead of an argument register. Most ports do not 34691 need to implement anything for this hook. 34692 34693 -- Target Hook: void TARGET_END_CALL_ARGS (void) 34694 This target hook is invoked while generating RTL for a function 34695 call, just after the point where the return reg is copied into a 34696 pseudo. It signals that all the call argument and return registers 34697 for the just emitted call are now no longer in use. Most ports do 34698 not need to implement anything for this hook. 34699 34700 -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED 34701 (cumulative_args_t CA) 34702 If you need to conditionally change ABIs so that one works with 34703 'TARGET_SETUP_INCOMING_VARARGS', but the other works like neither 34704 'TARGET_SETUP_INCOMING_VARARGS' nor 'TARGET_STRICT_ARGUMENT_NAMING' 34705 was defined, then define this hook to return 'true' if 34706 'TARGET_SETUP_INCOMING_VARARGS' is used, 'false' otherwise. 34707 Otherwise, you should not define this hook. 34708 34709 -- Target Hook: rtx TARGET_LOAD_BOUNDS_FOR_ARG (rtx SLOT, rtx ARG, rtx 34710 SLOT_NO) 34711 This hook is used by expand pass to emit insn to load bounds of ARG 34712 passed in SLOT. Expand pass uses this hook in case bounds of ARG 34713 are not passed in register. If SLOT is a memory, then bounds are 34714 loaded as for regular pointer loaded from memory. If SLOT is not a 34715 memory then SLOT_NO is an integer constant holding number of the 34716 target dependent special slot which should be used to obtain 34717 bounds. Hook returns RTX holding loaded bounds. 34718 34719 -- Target Hook: void TARGET_STORE_BOUNDS_FOR_ARG (rtx ARG, rtx SLOT, 34720 rtx BOUNDS, rtx SLOT_NO) 34721 This hook is used by expand pass to emit insns to store BOUNDS of 34722 ARG passed in SLOT. Expand pass uses this hook in case BOUNDS of 34723 ARG are not passed in register. If SLOT is a memory, then BOUNDS 34724 are stored as for regular pointer stored in memory. If SLOT is not 34725 a memory then SLOT_NO is an integer constant holding number of the 34726 target dependent special slot which should be used to store BOUNDS. 34727 34728 -- Target Hook: rtx TARGET_LOAD_RETURNED_BOUNDS (rtx SLOT) 34729 This hook is used by expand pass to emit insn to load bounds 34730 returned by function call in SLOT. Hook returns RTX holding loaded 34731 bounds. 34732 34733 -- Target Hook: void TARGET_STORE_RETURNED_BOUNDS (rtx SLOT, rtx 34734 BOUNDS) 34735 This hook is used by expand pass to emit insn to store BOUNDS 34736 returned by function call into SLOT. 34737 34738 -- Target Hook: rtx TARGET_CHKP_FUNCTION_VALUE_BOUNDS (const_tree 34739 RET_TYPE, const_tree FN_DECL_OR_TYPE, bool OUTGOING) 34740 Define this to return an RTX representing the place where a 34741 function returns bounds for returned pointers. Arguments meaning 34742 is similar to 'TARGET_FUNCTION_VALUE'. 34743 34744 -- Target Hook: void TARGET_SETUP_INCOMING_VARARG_BOUNDS 34745 (cumulative_args_t ARGS_SO_FAR, machine_mode MODE, tree TYPE, 34746 int *PRETEND_ARGS_SIZE, int SECOND_TIME) 34747 Use it to store bounds for anonymous register arguments stored into 34748 the stack. Arguments meaning is similar to 34749 'TARGET_SETUP_INCOMING_VARARGS'. 34750 34751 34752File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros 34753 3475418.11 Trampolines for Nested Functions 34755====================================== 34756 34757A "trampoline" is a small piece of code that is created at run time when 34758the address of a nested function is taken. It normally resides on the 34759stack, in the stack frame of the containing function. These macros tell 34760GCC how to generate code to allocate and initialize a trampoline. 34761 34762 The instructions in the trampoline must do two things: load a constant 34763address into the static chain register, and jump to the real address of 34764the nested function. On CISC machines such as the m68k, this requires 34765two instructions, a move immediate and a jump. Then the two addresses 34766exist in the trampoline as word-long immediate operands. On RISC 34767machines, it is often necessary to load each address into a register in 34768two parts. Then pieces of each address form separate immediate 34769operands. 34770 34771 The code generated to initialize the trampoline must store the variable 34772parts--the static chain value and the function address--into the 34773immediate operands of the instructions. On a CISC machine, this is 34774simply a matter of copying each address to a memory reference at the 34775proper offset from the start of the trampoline. On a RISC machine, it 34776may be necessary to take out pieces of the address and store them 34777separately. 34778 34779 -- Target Hook: void TARGET_ASM_TRAMPOLINE_TEMPLATE (FILE *F) 34780 This hook is called by 'assemble_trampoline_template' to output, on 34781 the stream F, assembler code for a block of data that contains the 34782 constant parts of a trampoline. This code should not include a 34783 label--the label is taken care of automatically. 34784 34785 If you do not define this hook, it means no template is needed for 34786 the target. Do not define this hook on systems where the block 34787 move code to copy the trampoline into place would be larger than 34788 the code to generate it on the spot. 34789 34790 -- Macro: TRAMPOLINE_SECTION 34791 Return the section into which the trampoline template is to be 34792 placed (*note Sections::). The default value is 34793 'readonly_data_section'. 34794 34795 -- Macro: TRAMPOLINE_SIZE 34796 A C expression for the size in bytes of the trampoline, as an 34797 integer. 34798 34799 -- Macro: TRAMPOLINE_ALIGNMENT 34800 Alignment required for trampolines, in bits. 34801 34802 If you don't define this macro, the value of 'FUNCTION_ALIGNMENT' 34803 is used for aligning trampolines. 34804 34805 -- Target Hook: void TARGET_TRAMPOLINE_INIT (rtx M_TRAMP, tree FNDECL, 34806 rtx STATIC_CHAIN) 34807 This hook is called to initialize a trampoline. M_TRAMP is an RTX 34808 for the memory block for the trampoline; FNDECL is the 34809 'FUNCTION_DECL' for the nested function; STATIC_CHAIN is an RTX for 34810 the static chain value that should be passed to the function when 34811 it is called. 34812 34813 If the target defines 'TARGET_ASM_TRAMPOLINE_TEMPLATE', then the 34814 first thing this hook should do is emit a block move into M_TRAMP 34815 from the memory block returned by 'assemble_trampoline_template'. 34816 Note that the block move need only cover the constant parts of the 34817 trampoline. If the target isolates the variable parts of the 34818 trampoline to the end, not all 'TRAMPOLINE_SIZE' bytes need be 34819 copied. 34820 34821 If the target requires any other actions, such as flushing caches 34822 or enabling stack execution, these actions should be performed 34823 after initializing the trampoline proper. 34824 34825 -- Target Hook: rtx TARGET_TRAMPOLINE_ADJUST_ADDRESS (rtx ADDR) 34826 This hook should perform any machine-specific adjustment in the 34827 address of the trampoline. Its argument contains the address of 34828 the memory block that was passed to 'TARGET_TRAMPOLINE_INIT'. In 34829 case the address to be used for a function call should be different 34830 from the address at which the template was stored, the different 34831 address should be returned; otherwise ADDR should be returned 34832 unchanged. If this hook is not defined, ADDR will be used for 34833 function calls. 34834 34835 -- Target Hook: int TARGET_CUSTOM_FUNCTION_DESCRIPTORS 34836 This hook should be defined to a power of 2 if the target will 34837 benefit from the use of custom descriptors for nested functions 34838 instead of the standard trampolines. Such descriptors are created 34839 at run time on the stack and made up of data only, but they are 34840 non-standard so the generated code must be prepared to deal with 34841 them. This hook should be defined to 0 if the target uses function 34842 descriptors for its standard calling sequence, like for example 34843 HP-PA or IA-64. Using descriptors for nested functions eliminates 34844 the need for trampolines that reside on the stack and require it to 34845 be made executable. 34846 34847 The value of the macro is used to parameterize the run-time 34848 identification scheme implemented to distinguish descriptors from 34849 function addresses: it gives the number of bytes by which their 34850 address is misaligned compared with function addresses. The value 34851 of 1 will generally work, unless it is already reserved by the 34852 target for another purpose, like for example on ARM. 34853 34854 Implementing trampolines is difficult on many machines because they 34855have separate instruction and data caches. Writing into a stack 34856location fails to clear the memory in the instruction cache, so when the 34857program jumps to that location, it executes the old contents. 34858 34859 Here are two possible solutions. One is to clear the relevant parts of 34860the instruction cache whenever a trampoline is set up. The other is to 34861make all trampolines identical, by having them jump to a standard 34862subroutine. The former technique makes trampoline execution faster; the 34863latter makes initialization faster. 34864 34865 To clear the instruction cache when a trampoline is initialized, define 34866the following macro. 34867 34868 -- Macro: CLEAR_INSN_CACHE (BEG, END) 34869 If defined, expands to a C expression clearing the _instruction 34870 cache_ in the specified interval. The definition of this macro 34871 would typically be a series of 'asm' statements. Both BEG and END 34872 are both pointer expressions. 34873 34874 To use a standard subroutine, define the following macro. In addition, 34875you must make sure that the instructions in a trampoline fill an entire 34876cache line with identical instructions, or else ensure that the 34877beginning of the trampoline code is always aligned at the same point in 34878its cache line. Look in 'm68k.h' as a guide. 34879 34880 -- Macro: TRANSFER_FROM_TRAMPOLINE 34881 Define this macro if trampolines need a special subroutine to do 34882 their work. The macro should expand to a series of 'asm' 34883 statements which will be compiled with GCC. They go in a library 34884 function named '__transfer_from_trampoline'. 34885 34886 If you need to avoid executing the ordinary prologue code of a 34887 compiled C function when you jump to the subroutine, you can do so 34888 by placing a special label of your own in the assembler code. Use 34889 one 'asm' statement to generate an assembler label, and another to 34890 make the label global. Then trampolines can use that label to jump 34891 directly to your special assembler code. 34892 34893 34894File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros 34895 3489618.12 Implicit Calls to Library Routines 34897======================================== 34898 34899Here is an explanation of implicit calls to library routines. 34900 34901 -- Macro: DECLARE_LIBRARY_RENAMES 34902 This macro, if defined, should expand to a piece of C code that 34903 will get expanded when compiling functions for libgcc.a. It can be 34904 used to provide alternate names for GCC's internal library 34905 functions if there are ABI-mandated names that the compiler should 34906 provide. 34907 34908 -- Target Hook: void TARGET_INIT_LIBFUNCS (void) 34909 This hook should declare additional library routines or rename 34910 existing ones, using the functions 'set_optab_libfunc' and 34911 'init_one_libfunc' defined in 'optabs.c'. 'init_optabs' calls this 34912 macro after initializing all the normal library routines. 34913 34914 The default is to do nothing. Most ports don't need to define this 34915 hook. 34916 34917 -- Target Hook: bool TARGET_LIBFUNC_GNU_PREFIX 34918 If false (the default), internal library routines start with two 34919 underscores. If set to true, these routines start with '__gnu_' 34920 instead. E.g., '__muldi3' changes to '__gnu_muldi3'. This 34921 currently only affects functions defined in 'libgcc2.c'. If this 34922 is set to true, the 'tm.h' file must also '#define 34923 LIBGCC2_GNU_PREFIX'. 34924 34925 -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON) 34926 This macro should return 'true' if the library routine that 34927 implements the floating point comparison operator COMPARISON in 34928 mode MODE will return a boolean, and FALSE if it will return a 34929 tristate. 34930 34931 GCC's own floating point libraries return tristates from the 34932 comparison operators, so the default returns false always. Most 34933 ports don't need to define this macro. 34934 34935 -- Macro: TARGET_LIB_INT_CMP_BIASED 34936 This macro should evaluate to 'true' if the integer comparison 34937 functions (like '__cmpdi2') return 0 to indicate that the first 34938 operand is smaller than the second, 1 to indicate that they are 34939 equal, and 2 to indicate that the first operand is greater than the 34940 second. If this macro evaluates to 'false' the comparison 34941 functions return -1, 0, and 1 instead of 0, 1, and 2. If the 34942 target uses the routines in 'libgcc.a', you do not need to define 34943 this macro. 34944 34945 -- Macro: TARGET_HAS_NO_HW_DIVIDE 34946 This macro should be defined if the target has no hardware divide 34947 instructions. If this macro is defined, GCC will use an algorithm 34948 which make use of simple logical and arithmetic operations for 34949 64-bit division. If the macro is not defined, GCC will use an 34950 algorithm which make use of a 64-bit by 32-bit divide primitive. 34951 34952 -- Macro: TARGET_EDOM 34953 The value of 'EDOM' on the target machine, as a C integer constant 34954 expression. If you don't define this macro, GCC does not attempt 34955 to deposit the value of 'EDOM' into 'errno' directly. Look in 34956 '/usr/include/errno.h' to find the value of 'EDOM' on your system. 34957 34958 If you do not define 'TARGET_EDOM', then compiled code reports 34959 domain errors by calling the library function and letting it report 34960 the error. If mathematical functions on your system use 'matherr' 34961 when there is an error, then you should leave 'TARGET_EDOM' 34962 undefined so that 'matherr' is used normally. 34963 34964 -- Macro: GEN_ERRNO_RTX 34965 Define this macro as a C expression to create an rtl expression 34966 that refers to the global "variable" 'errno'. (On certain systems, 34967 'errno' may not actually be a variable.) If you don't define this 34968 macro, a reasonable default is used. 34969 34970 -- Target Hook: bool TARGET_LIBC_HAS_FUNCTION (enum function_class 34971 FN_CLASS) 34972 This hook determines whether a function from a class of functions 34973 FN_CLASS is present at the runtime. 34974 34975 -- Macro: NEXT_OBJC_RUNTIME 34976 Set this macro to 1 to use the "NeXT" Objective-C message sending 34977 conventions by default. This calling convention involves passing 34978 the object, the selector and the method arguments all at once to 34979 the method-lookup library function. This is the usual setting when 34980 targeting Darwin/Mac OS X systems, which have the NeXT runtime 34981 installed. 34982 34983 If the macro is set to 0, the "GNU" Objective-C message sending 34984 convention will be used by default. This convention passes just 34985 the object and the selector to the method-lookup function, which 34986 returns a pointer to the method. 34987 34988 In either case, it remains possible to select code-generation for 34989 the alternate scheme, by means of compiler command line switches. 34990 34991 34992File: gccint.info, Node: Addressing Modes, Next: Anchored Addresses, Prev: Library Calls, Up: Target Macros 34993 3499418.13 Addressing Modes 34995====================== 34996 34997This is about addressing modes. 34998 34999 -- Macro: HAVE_PRE_INCREMENT 35000 -- Macro: HAVE_PRE_DECREMENT 35001 -- Macro: HAVE_POST_INCREMENT 35002 -- Macro: HAVE_POST_DECREMENT 35003 A C expression that is nonzero if the machine supports 35004 pre-increment, pre-decrement, post-increment, or post-decrement 35005 addressing respectively. 35006 35007 -- Macro: HAVE_PRE_MODIFY_DISP 35008 -- Macro: HAVE_POST_MODIFY_DISP 35009 A C expression that is nonzero if the machine supports pre- or 35010 post-address side-effect generation involving constants other than 35011 the size of the memory operand. 35012 35013 -- Macro: HAVE_PRE_MODIFY_REG 35014 -- Macro: HAVE_POST_MODIFY_REG 35015 A C expression that is nonzero if the machine supports pre- or 35016 post-address side-effect generation involving a register 35017 displacement. 35018 35019 -- Macro: CONSTANT_ADDRESS_P (X) 35020 A C expression that is 1 if the RTX X is a constant which is a 35021 valid address. On most machines the default definition of 35022 '(CONSTANT_P (X) && GET_CODE (X) != CONST_DOUBLE)' is acceptable, 35023 but a few machines are more restrictive as to which constant 35024 addresses are supported. 35025 35026 -- Macro: CONSTANT_P (X) 35027 'CONSTANT_P', which is defined by target-independent code, accepts 35028 integer-values expressions whose values are not explicitly known, 35029 such as 'symbol_ref', 'label_ref', and 'high' expressions and 35030 'const' arithmetic expressions, in addition to 'const_int' and 35031 'const_double' expressions. 35032 35033 -- Macro: MAX_REGS_PER_ADDRESS 35034 A number, the maximum number of registers that can appear in a 35035 valid memory address. Note that it is up to you to specify a value 35036 equal to the maximum number that 'TARGET_LEGITIMATE_ADDRESS_P' 35037 would ever accept. 35038 35039 -- Target Hook: bool TARGET_LEGITIMATE_ADDRESS_P (machine_mode MODE, 35040 rtx X, bool STRICT) 35041 A function that returns whether X (an RTX) is a legitimate memory 35042 address on the target machine for a memory operand of mode MODE. 35043 35044 Legitimate addresses are defined in two variants: a strict variant 35045 and a non-strict one. The STRICT parameter chooses which variant 35046 is desired by the caller. 35047 35048 The strict variant is used in the reload pass. It must be defined 35049 so that any pseudo-register that has not been allocated a hard 35050 register is considered a memory reference. This is because in 35051 contexts where some kind of register is required, a pseudo-register 35052 with no hard register must be rejected. For non-hard registers, 35053 the strict variant should look up the 'reg_renumber' array; it 35054 should then proceed using the hard register number in the array, or 35055 treat the pseudo as a memory reference if the array holds '-1'. 35056 35057 The non-strict variant is used in other passes. It must be defined 35058 to accept all pseudo-registers in every context where some kind of 35059 register is required. 35060 35061 Normally, constant addresses which are the sum of a 'symbol_ref' 35062 and an integer are stored inside a 'const' RTX to mark them as 35063 constant. Therefore, there is no need to recognize such sums 35064 specifically as legitimate addresses. Normally you would simply 35065 recognize any 'const' as legitimate. 35066 35067 Usually 'PRINT_OPERAND_ADDRESS' is not prepared to handle constant 35068 sums that are not marked with 'const'. It assumes that a naked 35069 'plus' indicates indexing. If so, then you _must_ reject such 35070 naked constant sums as illegitimate addresses, so that none of them 35071 will be given to 'PRINT_OPERAND_ADDRESS'. 35072 35073 On some machines, whether a symbolic address is legitimate depends 35074 on the section that the address refers to. On these machines, 35075 define the target hook 'TARGET_ENCODE_SECTION_INFO' to store the 35076 information into the 'symbol_ref', and then check for it here. 35077 When you see a 'const', you will have to look inside it to find the 35078 'symbol_ref' in order to determine the section. *Note Assembler 35079 Format::. 35080 35081 Some ports are still using a deprecated legacy substitute for this 35082 hook, the 'GO_IF_LEGITIMATE_ADDRESS' macro. This macro has this 35083 syntax: 35084 35085 #define GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL) 35086 35087 and should 'goto LABEL' if the address X is a valid address on the 35088 target machine for a memory operand of mode MODE. 35089 35090 Compiler source files that want to use the strict variant of this 35091 macro define the macro 'REG_OK_STRICT'. You should use an '#ifdef 35092 REG_OK_STRICT' conditional to define the strict variant in that 35093 case and the non-strict variant otherwise. 35094 35095 Using the hook is usually simpler because it limits the number of 35096 files that are recompiled when changes are made. 35097 35098 -- Macro: TARGET_MEM_CONSTRAINT 35099 A single character to be used instead of the default ''m'' 35100 character for general memory addresses. This defines the 35101 constraint letter which matches the memory addresses accepted by 35102 'TARGET_LEGITIMATE_ADDRESS_P'. Define this macro if you want to 35103 support new address formats in your back end without changing the 35104 semantics of the ''m'' constraint. This is necessary in order to 35105 preserve functionality of inline assembly constructs using the 35106 ''m'' constraint. 35107 35108 -- Macro: FIND_BASE_TERM (X) 35109 A C expression to determine the base term of address X, or to 35110 provide a simplified version of X from which 'alias.c' can easily 35111 find the base term. This macro is used in only two places: 35112 'find_base_value' and 'find_base_term' in 'alias.c'. 35113 35114 It is always safe for this macro to not be defined. It exists so 35115 that alias analysis can understand machine-dependent addresses. 35116 35117 The typical use of this macro is to handle addresses containing a 35118 label_ref or symbol_ref within an UNSPEC. 35119 35120 -- Target Hook: rtx TARGET_LEGITIMIZE_ADDRESS (rtx X, rtx OLDX, 35121 machine_mode MODE) 35122 This hook is given an invalid memory address X for an operand of 35123 mode MODE and should try to return a valid memory address. 35124 35125 X will always be the result of a call to 'break_out_memory_refs', 35126 and OLDX will be the operand that was given to that function to 35127 produce X. 35128 35129 The code of the hook should not alter the substructure of X. If it 35130 transforms X into a more legitimate form, it should return the new 35131 X. 35132 35133 It is not necessary for this hook to come up with a legitimate 35134 address, with the exception of native TLS addresses (*note Emulated 35135 TLS::). The compiler has standard ways of doing so in all cases. 35136 In fact, if the target supports only emulated TLS, it is safe to 35137 omit this hook or make it return X if it cannot find a valid way to 35138 legitimize the address. But often a machine-dependent strategy can 35139 generate better code. 35140 35141 -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, 35142 WIN) 35143 A C compound statement that attempts to replace X, which is an 35144 address that needs reloading, with a valid memory address for an 35145 operand of mode MODE. WIN will be a C statement label elsewhere in 35146 the code. It is not necessary to define this macro, but it might 35147 be useful for performance reasons. 35148 35149 For example, on the i386, it is sometimes possible to use a single 35150 reload register instead of two by reloading a sum of two pseudo 35151 registers into a register. On the other hand, for number of RISC 35152 processors offsets are limited so that often an intermediate 35153 address needs to be generated in order to address a stack slot. By 35154 defining 'LEGITIMIZE_RELOAD_ADDRESS' appropriately, the 35155 intermediate addresses generated for adjacent some stack slots can 35156 be made identical, and thus be shared. 35157 35158 _Note_: This macro should be used with caution. It is necessary to 35159 know something of how reload works in order to effectively use 35160 this, and it is quite easy to produce macros that build in too much 35161 knowledge of reload internals. 35162 35163 _Note_: This macro must be able to reload an address created by a 35164 previous invocation of this macro. If it fails to handle such 35165 addresses then the compiler may generate incorrect code or abort. 35166 35167 The macro definition should use 'push_reload' to indicate parts 35168 that need reloading; OPNUM, TYPE and IND_LEVELS are usually 35169 suitable to be passed unaltered to 'push_reload'. 35170 35171 The code generated by this macro must not alter the substructure of 35172 X. If it transforms X into a more legitimate form, it should 35173 assign X (which will always be a C variable) a new value. This 35174 also applies to parts that you change indirectly by calling 35175 'push_reload'. 35176 35177 The macro definition may use 'strict_memory_address_p' to test if 35178 the address has become legitimate. 35179 35180 If you want to change only a part of X, one standard way of doing 35181 this is to use 'copy_rtx'. Note, however, that it unshares only a 35182 single level of rtl. Thus, if the part to be changed is not at the 35183 top level, you'll need to replace first the top level. It is not 35184 necessary for this macro to come up with a legitimate address; but 35185 often a machine-dependent strategy can generate better code. 35186 35187 -- Target Hook: bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx ADDR, 35188 addr_space_t ADDRSPACE) 35189 This hook returns 'true' if memory address ADDR in address space 35190 ADDRSPACE can have different meanings depending on the machine mode 35191 of the memory reference it is used for or if the address is valid 35192 for some modes but not others. 35193 35194 Autoincrement and autodecrement addresses typically have 35195 mode-dependent effects because the amount of the increment or 35196 decrement is the size of the operand being addressed. Some 35197 machines have other mode-dependent addresses. Many RISC machines 35198 have no mode-dependent addresses. 35199 35200 You may assume that ADDR is a valid address for the machine. 35201 35202 The default version of this hook returns 'false'. 35203 35204 -- Target Hook: bool TARGET_LEGITIMATE_CONSTANT_P (machine_mode MODE, 35205 rtx X) 35206 This hook returns true if X is a legitimate constant for a 35207 MODE-mode immediate operand on the target machine. You can assume 35208 that X satisfies 'CONSTANT_P', so you need not check this. 35209 35210 The default definition returns true. 35211 35212 -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X) 35213 This hook is used to undo the possibly obfuscating effects of the 35214 'LEGITIMIZE_ADDRESS' and 'LEGITIMIZE_RELOAD_ADDRESS' target macros. 35215 Some backend implementations of these macros wrap symbol references 35216 inside an 'UNSPEC' rtx to represent PIC or similar addressing 35217 modes. This target hook allows GCC's optimizers to understand the 35218 semantics of these opaque 'UNSPEC's by converting them back into 35219 their original form. 35220 35221 -- Target Hook: bool TARGET_CONST_NOT_OK_FOR_DEBUG_P (rtx X) 35222 This hook should return true if X should not be emitted into debug 35223 sections. 35224 35225 -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (machine_mode MODE, 35226 rtx X) 35227 This hook should return true if X is of a form that cannot (or 35228 should not) be spilled to the constant pool. MODE is the mode of 35229 X. 35230 35231 The default version of this hook returns false. 35232 35233 The primary reason to define this hook is to prevent reload from 35234 deciding that a non-legitimate constant would be better reloaded 35235 from the constant pool instead of spilling and reloading a register 35236 holding the constant. This restriction is often true of addresses 35237 of TLS symbols for various targets. 35238 35239 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (machine_mode 35240 MODE, const_rtx X) 35241 This hook should return true if pool entries for constant X can be 35242 placed in an 'object_block' structure. MODE is the mode of X. 35243 35244 The default version returns false for all constants. 35245 35246 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_DECL_P (const_tree DECL) 35247 This hook should return true if pool entries for DECL should be 35248 placed in an 'object_block' structure. 35249 35250 The default version returns true for all decls. 35251 35252 -- Target Hook: tree TARGET_BUILTIN_RECIPROCAL (tree FNDECL) 35253 This hook should return the DECL of a function that implements the 35254 reciprocal of the machine-specific builtin function FNDECL, or 35255 'NULL_TREE' if such a function is not available. 35256 35257 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void) 35258 This hook should return the DECL of a function F that given an 35259 address ADDR as an argument returns a mask M that can be used to 35260 extract from two vectors the relevant data that resides in ADDR in 35261 case ADDR is not properly aligned. 35262 35263 The autovectorizer, when vectorizing a load operation from an 35264 address ADDR that may be unaligned, will generate two vector loads 35265 from the two aligned addresses around ADDR. It then generates a 35266 'REALIGN_LOAD' operation to extract the relevant data from the two 35267 loaded vectors. The first two arguments to 'REALIGN_LOAD', V1 and 35268 V2, are the two vectors, each of size VS, and the third argument, 35269 OFF, defines how the data will be extracted from these two vectors: 35270 if OFF is 0, then the returned vector is V2; otherwise, the 35271 returned vector is composed from the last VS-OFF elements of V1 35272 concatenated to the first OFF elements of V2. 35273 35274 If this hook is defined, the autovectorizer will generate a call to 35275 F (using the DECL tree that this hook returns) and will use the 35276 return value of F as the argument OFF to 'REALIGN_LOAD'. 35277 Therefore, the mask M returned by F should comply with the 35278 semantics expected by 'REALIGN_LOAD' described above. If this hook 35279 is not defined, then ADDR will be used as the argument OFF to 35280 'REALIGN_LOAD', in which case the low log2(VS) - 1 bits of ADDR 35281 will be considered. 35282 35283 -- Target Hook: int TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST (enum 35284 vect_cost_for_stmt TYPE_OF_COST, tree VECTYPE, int MISALIGN) 35285 Returns cost of different scalar or vector statements for 35286 vectorization cost model. For vector memory operations the cost 35287 may depend on type (VECTYPE) and misalignment value (MISALIGN). 35288 35289 -- Target Hook: HOST_WIDE_INT 35290 TARGET_VECTORIZE_PREFERRED_VECTOR_ALIGNMENT (const_tree TYPE) 35291 This hook returns the preferred alignment in bits for accesses to 35292 vectors of type TYPE in vectorized code. This might be less than 35293 or greater than the ABI-defined value returned by 35294 'TARGET_VECTOR_ALIGNMENT'. It can be equal to the alignment of a 35295 single element, in which case the vectorizer will not try to 35296 optimize for alignment. 35297 35298 The default hook returns 'TYPE_ALIGN (TYPE)', which is correct for 35299 most targets. 35300 35301 -- Target Hook: bool TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE 35302 (const_tree TYPE, bool IS_PACKED) 35303 Return true if vector alignment is reachable (by peeling N 35304 iterations) for the given scalar type TYPE. IS_PACKED is false if 35305 the scalar access using TYPE is known to be naturally aligned. 35306 35307 -- Target Hook: bool TARGET_VECTORIZE_VEC_PERM_CONST (machine_mode 35308 MODE, rtx OUTPUT, rtx IN0, rtx IN1, const vec_perm_indices 35309 &SEL) 35310 This hook is used to test whether the target can permute up to two 35311 vectors of mode MODE using the permutation vector 'sel', and also 35312 to emit such a permutation. In the former case IN0, IN1 and OUT 35313 are all null. In the latter case IN0 and IN1 are the source 35314 vectors and OUT is the destination vector; all three are registers 35315 of mode MODE. IN1 is the same as IN0 if SEL describes a 35316 permutation on one vector instead of two. 35317 35318 Return true if the operation is possible, emitting instructions for 35319 it if rtxes are provided. 35320 35321 If the hook returns false for a mode with multibyte elements, GCC 35322 will try the equivalent byte operation. If that also fails, it 35323 will try forcing the selector into a register and using the 35324 VEC_PERMMODE instruction pattern. There is no need for the hook to 35325 handle these two implementation approaches itself. 35326 35327 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_CONVERSION (unsigned 35328 CODE, tree DEST_TYPE, tree SRC_TYPE) 35329 This hook should return the DECL of a function that implements 35330 conversion of the input vector of type SRC_TYPE to type DEST_TYPE. 35331 The value of CODE is one of the enumerators in 'enum tree_code' and 35332 specifies how the conversion is to be applied (truncation, 35333 rounding, etc.). 35334 35335 If this hook is defined, the autovectorizer will use the 35336 'TARGET_VECTORIZE_BUILTIN_CONVERSION' target hook when vectorizing 35337 conversion. Otherwise, it will return 'NULL_TREE'. 35338 35339 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION 35340 (unsigned CODE, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 35341 This hook should return the decl of a function that implements the 35342 vectorized variant of the function with the 'combined_fn' code CODE 35343 or 'NULL_TREE' if such a function is not available. The return 35344 type of the vectorized function shall be of vector type 35345 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 35346 35347 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION 35348 (tree FNDECL, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 35349 This hook should return the decl of a function that implements the 35350 vectorized variant of target built-in function 'fndecl'. The 35351 return type of the vectorized function shall be of vector type 35352 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 35353 35354 -- Target Hook: bool TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT 35355 (machine_mode MODE, const_tree TYPE, int MISALIGNMENT, bool 35356 IS_PACKED) 35357 This hook should return true if the target supports misaligned 35358 vector store/load of a specific factor denoted in the MISALIGNMENT 35359 parameter. The vector store/load should be of machine mode MODE 35360 and the elements in the vectors should be of type TYPE. IS_PACKED 35361 parameter is true if the memory access is defined in a packed 35362 struct. 35363 35364 -- Target Hook: machine_mode TARGET_VECTORIZE_PREFERRED_SIMD_MODE 35365 (scalar_mode MODE) 35366 This hook should return the preferred mode for vectorizing scalar 35367 mode MODE. The default is equal to 'word_mode', because the 35368 vectorizer can do some transformations even in absence of 35369 specialized SIMD hardware. 35370 35371 -- Target Hook: machine_mode TARGET_VECTORIZE_SPLIT_REDUCTION 35372 (machine_mode) 35373 This hook should return the preferred mode to split the final 35374 reduction step on MODE to. The reduction is then carried out 35375 reducing upper against lower halves of vectors recursively until 35376 the specified mode is reached. The default is MODE which means no 35377 splitting. 35378 35379 -- Target Hook: void TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES 35380 (vector_sizes *SIZES) 35381 If the mode returned by 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE' is 35382 not the only one that is worth considering, this hook should add 35383 all suitable vector sizes to SIZES, in order of decreasing 35384 preference. The first one should be the size of 35385 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE'. 35386 35387 The hook does not need to do anything if the vector returned by 35388 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE' is the only one relevant for 35389 autovectorization. The default implementation does nothing. 35390 35391 -- Target Hook: opt_machine_mode TARGET_VECTORIZE_GET_MASK_MODE 35392 (poly_uint64 NUNITS, poly_uint64 LENGTH) 35393 A vector mask is a value that holds one boolean result for every 35394 element in a vector. This hook returns the machine mode that 35395 should be used to represent such a mask when the vector in question 35396 is LENGTH bytes long and contains NUNITS elements. The hook 35397 returns an empty 'opt_machine_mode' if no such mode exists. 35398 35399 The default implementation returns the mode of an integer vector 35400 that is LENGTH bytes long and that contains NUNITS elements, if 35401 such a mode exists. 35402 35403 -- Target Hook: bool TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE (unsigned 35404 IFN) 35405 This hook returns true if masked internal function IFN (really of 35406 type 'internal_fn') should be considered expensive when the mask is 35407 all zeros. GCC can then try to branch around the instruction 35408 instead. 35409 35410 -- Target Hook: void * TARGET_VECTORIZE_INIT_COST (struct loop 35411 *LOOP_INFO) 35412 This hook should initialize target-specific data structures in 35413 preparation for modeling the costs of vectorizing a loop or basic 35414 block. The default allocates three unsigned integers for 35415 accumulating costs for the prologue, body, and epilogue of the loop 35416 or basic block. If LOOP_INFO is non-NULL, it identifies the loop 35417 being vectorized; otherwise a single block is being vectorized. 35418 35419 -- Target Hook: unsigned TARGET_VECTORIZE_ADD_STMT_COST (void *DATA, 35420 int COUNT, enum vect_cost_for_stmt KIND, struct _stmt_vec_info 35421 *STMT_INFO, int MISALIGN, enum vect_cost_model_location WHERE) 35422 This hook should update the target-specific DATA in response to 35423 adding COUNT copies of the given KIND of statement to a loop or 35424 basic block. The default adds the builtin vectorizer cost for the 35425 copies of the statement to the accumulator specified by WHERE, (the 35426 prologue, body, or epilogue) and returns the amount added. The 35427 return value should be viewed as a tentative cost that may later be 35428 revised. 35429 35430 -- Target Hook: void TARGET_VECTORIZE_FINISH_COST (void *DATA, unsigned 35431 *PROLOGUE_COST, unsigned *BODY_COST, unsigned *EPILOGUE_COST) 35432 This hook should complete calculations of the cost of vectorizing a 35433 loop or basic block based on DATA, and return the prologue, body, 35434 and epilogue costs as unsigned integers. The default returns the 35435 value of the three accumulators. 35436 35437 -- Target Hook: void TARGET_VECTORIZE_DESTROY_COST_DATA (void *DATA) 35438 This hook should release DATA and any related data structures 35439 allocated by TARGET_VECTORIZE_INIT_COST. The default releases the 35440 accumulator. 35441 35442 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_GATHER (const_tree 35443 MEM_VECTYPE, const_tree INDEX_TYPE, int SCALE) 35444 Target builtin that implements vector gather operation. 35445 MEM_VECTYPE is the vector type of the load and INDEX_TYPE is scalar 35446 type of the index, scaled by SCALE. The default is 'NULL_TREE' 35447 which means to not vectorize gather loads. 35448 35449 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_SCATTER (const_tree 35450 VECTYPE, const_tree INDEX_TYPE, int SCALE) 35451 Target builtin that implements vector scatter operation. VECTYPE 35452 is the vector type of the store and INDEX_TYPE is scalar type of 35453 the index, scaled by SCALE. The default is 'NULL_TREE' which means 35454 to not vectorize scatter stores. 35455 35456 -- Target Hook: int TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN 35457 (struct cgraph_node *, struct cgraph_simd_clone *, TREE, INT) 35458 This hook should set VECSIZE_MANGLE, VECSIZE_INT, VECSIZE_FLOAT 35459 fields in SIMD_CLONE structure pointed by CLONE_INFO argument and 35460 also SIMDLEN field if it was previously 0. The hook should return 35461 0 if SIMD clones shouldn't be emitted, or number of VECSIZE_MANGLE 35462 variants that should be emitted. 35463 35464 -- Target Hook: void TARGET_SIMD_CLONE_ADJUST (struct cgraph_node *) 35465 This hook should add implicit 'attribute(target("..."))' attribute 35466 to SIMD clone NODE if needed. 35467 35468 -- Target Hook: int TARGET_SIMD_CLONE_USABLE (struct cgraph_node *) 35469 This hook should return -1 if SIMD clone NODE shouldn't be used in 35470 vectorized loops in current function, or non-negative number if it 35471 is usable. In that case, the smaller the number is, the more 35472 desirable it is to use it. 35473 35474 -- Target Hook: int TARGET_SIMT_VF (void) 35475 Return number of threads in SIMT thread group on the target. 35476 35477 -- Target Hook: bool TARGET_GOACC_VALIDATE_DIMS (tree DECL, int *DIMS, 35478 int FN_LEVEL) 35479 This hook should check the launch dimensions provided for an 35480 OpenACC compute region, or routine. Defaulted values are 35481 represented as -1 and non-constant values as 0. The FN_LEVEL is 35482 negative for the function corresponding to the compute region. For 35483 a routine is is the outermost level at which partitioned execution 35484 may be spawned. The hook should verify non-default values. If 35485 DECL is NULL, global defaults are being validated and unspecified 35486 defaults should be filled in. Diagnostics should be issued as 35487 appropriate. Return true, if changes have been made. You must 35488 override this hook to provide dimensions larger than 1. 35489 35490 -- Target Hook: int TARGET_GOACC_DIM_LIMIT (int AXIS) 35491 This hook should return the maximum size of a particular dimension, 35492 or zero if unbounded. 35493 35494 -- Target Hook: bool TARGET_GOACC_FORK_JOIN (gcall *CALL, const int 35495 *DIMS, bool IS_FORK) 35496 This hook can be used to convert IFN_GOACC_FORK and IFN_GOACC_JOIN 35497 function calls to target-specific gimple, or indicate whether they 35498 should be retained. It is executed during the oacc_device_lower 35499 pass. It should return true, if the call should be retained. It 35500 should return false, if it is to be deleted (either because 35501 target-specific gimple has been inserted before it, or there is no 35502 need for it). The default hook returns false, if there are no RTL 35503 expanders for them. 35504 35505 -- Target Hook: void TARGET_GOACC_REDUCTION (gcall *CALL) 35506 This hook is used by the oacc_transform pass to expand calls to the 35507 GOACC_REDUCTION internal function, into a sequence of gimple 35508 instructions. CALL is gimple statement containing the call to the 35509 function. This hook removes statement CALL after the expanded 35510 sequence has been inserted. This hook is also responsible for 35511 allocating any storage for reductions when necessary. 35512 35513 35514File: gccint.info, Node: Anchored Addresses, Next: Condition Code, Prev: Addressing Modes, Up: Target Macros 35515 3551618.14 Anchored Addresses 35517======================== 35518 35519GCC usually addresses every static object as a separate entity. For 35520example, if we have: 35521 35522 static int a, b, c; 35523 int foo (void) { return a + b + c; } 35524 35525 the code for 'foo' will usually calculate three separate symbolic 35526addresses: those of 'a', 'b' and 'c'. On some targets, it would be 35527better to calculate just one symbolic address and access the three 35528variables relative to it. The equivalent pseudocode would be something 35529like: 35530 35531 int foo (void) 35532 { 35533 register int *xr = &x; 35534 return xr[&a - &x] + xr[&b - &x] + xr[&c - &x]; 35535 } 35536 35537 (which isn't valid C). We refer to shared addresses like 'x' as 35538"section anchors". Their use is controlled by '-fsection-anchors'. 35539 35540 The hooks below describe the target properties that GCC needs to know 35541in order to make effective use of section anchors. It won't use section 35542anchors at all unless either 'TARGET_MIN_ANCHOR_OFFSET' or 35543'TARGET_MAX_ANCHOR_OFFSET' is set to a nonzero value. 35544 35545 -- Target Hook: HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET 35546 The minimum offset that should be applied to a section anchor. On 35547 most targets, it should be the smallest offset that can be applied 35548 to a base register while still giving a legitimate address for 35549 every mode. The default value is 0. 35550 35551 -- Target Hook: HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET 35552 Like 'TARGET_MIN_ANCHOR_OFFSET', but the maximum (inclusive) offset 35553 that should be applied to section anchors. The default value is 0. 35554 35555 -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X) 35556 Write the assembly code to define section anchor X, which is a 35557 'SYMBOL_REF' for which 'SYMBOL_REF_ANCHOR_P (X)' is true. The hook 35558 is called with the assembly output position set to the beginning of 35559 'SYMBOL_REF_BLOCK (X)'. 35560 35561 If 'ASM_OUTPUT_DEF' is available, the hook's default definition 35562 uses it to define the symbol as '. + SYMBOL_REF_BLOCK_OFFSET (X)'. 35563 If 'ASM_OUTPUT_DEF' is not available, the hook's default definition 35564 is 'NULL', which disables the use of section anchors altogether. 35565 35566 -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (const_rtx X) 35567 Return true if GCC should attempt to use anchors to access 35568 'SYMBOL_REF' X. You can assume 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)' 35569 and '!SYMBOL_REF_ANCHOR_P (X)'. 35570 35571 The default version is correct for most targets, but you might need 35572 to intercept this hook to handle things like target-specific 35573 attributes or target-specific sections. 35574 35575 35576File: gccint.info, Node: Condition Code, Next: Costs, Prev: Anchored Addresses, Up: Target Macros 35577 3557818.15 Condition Code Status 35579=========================== 35580 35581The macros in this section can be split in two families, according to 35582the two ways of representing condition codes in GCC. 35583 35584 The first representation is the so called '(cc0)' representation (*note 35585Jump Patterns::), where all instructions can have an implicit clobber of 35586the condition codes. The second is the condition code register 35587representation, which provides better schedulability for architectures 35588that do have a condition code register, but on which most instructions 35589do not affect it. The latter category includes most RISC machines. 35590 35591 The implicit clobbering poses a strong restriction on the placement of 35592the definition and use of the condition code. In the past the 35593definition and use were always adjacent. However, recent changes to 35594support trapping arithmatic may result in the definition and user being 35595in different blocks. Thus, there may be a 'NOTE_INSN_BASIC_BLOCK' 35596between them. Additionally, the definition may be the source of 35597exception handling edges. 35598 35599 These restrictions can prevent important optimizations on some 35600machines. For example, on the IBM RS/6000, there is a delay for taken 35601branches unless the condition code register is set three instructions 35602earlier than the conditional branch. The instruction scheduler cannot 35603perform this optimization if it is not permitted to separate the 35604definition and use of the condition code register. 35605 35606 For this reason, it is possible and suggested to use a register to 35607represent the condition code for new ports. If there is a specific 35608condition code register in the machine, use a hard register. If the 35609condition code or comparison result can be placed in any general 35610register, or if there are multiple condition registers, use a pseudo 35611register. Registers used to store the condition code value will usually 35612have a mode that is in class 'MODE_CC'. 35613 35614 Alternatively, you can use 'BImode' if the comparison operator is 35615specified already in the compare instruction. In this case, you are not 35616interested in most macros in this section. 35617 35618* Menu: 35619 35620* CC0 Condition Codes:: Old style representation of condition codes. 35621* MODE_CC Condition Codes:: Modern representation of condition codes. 35622 35623 35624File: gccint.info, Node: CC0 Condition Codes, Next: MODE_CC Condition Codes, Up: Condition Code 35625 3562618.15.1 Representation of condition codes using '(cc0)' 35627------------------------------------------------------- 35628 35629The file 'conditions.h' defines a variable 'cc_status' to describe how 35630the condition code was computed (in case the interpretation of the 35631condition code depends on the instruction that it was set by). This 35632variable contains the RTL expressions on which the condition code is 35633currently based, and several standard flags. 35634 35635 Sometimes additional machine-specific flags must be defined in the 35636machine description header file. It can also add additional 35637machine-specific information by defining 'CC_STATUS_MDEP'. 35638 35639 -- Macro: CC_STATUS_MDEP 35640 C code for a data type which is used for declaring the 'mdep' 35641 component of 'cc_status'. It defaults to 'int'. 35642 35643 This macro is not used on machines that do not use 'cc0'. 35644 35645 -- Macro: CC_STATUS_MDEP_INIT 35646 A C expression to initialize the 'mdep' field to "empty". The 35647 default definition does nothing, since most machines don't use the 35648 field anyway. If you want to use the field, you should probably 35649 define this macro to initialize it. 35650 35651 This macro is not used on machines that do not use 'cc0'. 35652 35653 -- Macro: NOTICE_UPDATE_CC (EXP, INSN) 35654 A C compound statement to set the components of 'cc_status' 35655 appropriately for an insn INSN whose body is EXP. It is this 35656 macro's responsibility to recognize insns that set the condition 35657 code as a byproduct of other activity as well as those that 35658 explicitly set '(cc0)'. 35659 35660 This macro is not used on machines that do not use 'cc0'. 35661 35662 If there are insns that do not set the condition code but do alter 35663 other machine registers, this macro must check to see whether they 35664 invalidate the expressions that the condition code is recorded as 35665 reflecting. For example, on the 68000, insns that store in address 35666 registers do not set the condition code, which means that usually 35667 'NOTICE_UPDATE_CC' can leave 'cc_status' unaltered for such insns. 35668 But suppose that the previous insn set the condition code based on 35669 location 'a4@(102)' and the current insn stores a new value in 35670 'a4'. Although the condition code is not changed by this, it will 35671 no longer be true that it reflects the contents of 'a4@(102)'. 35672 Therefore, 'NOTICE_UPDATE_CC' must alter 'cc_status' in this case 35673 to say that nothing is known about the condition code value. 35674 35675 The definition of 'NOTICE_UPDATE_CC' must be prepared to deal with 35676 the results of peephole optimization: insns whose patterns are 35677 'parallel' RTXs containing various 'reg', 'mem' or constants which 35678 are just the operands. The RTL structure of these insns is not 35679 sufficient to indicate what the insns actually do. What 35680 'NOTICE_UPDATE_CC' should do when it sees one is just to run 35681 'CC_STATUS_INIT'. 35682 35683 A possible definition of 'NOTICE_UPDATE_CC' is to call a function 35684 that looks at an attribute (*note Insn Attributes::) named, for 35685 example, 'cc'. This avoids having detailed information about 35686 patterns in two places, the 'md' file and in 'NOTICE_UPDATE_CC'. 35687 35688 35689File: gccint.info, Node: MODE_CC Condition Codes, Prev: CC0 Condition Codes, Up: Condition Code 35690 3569118.15.2 Representation of condition codes using registers 35692--------------------------------------------------------- 35693 35694 -- Macro: SELECT_CC_MODE (OP, X, Y) 35695 On many machines, the condition code may be produced by other 35696 instructions than compares, for example the branch can use directly 35697 the condition code set by a subtract instruction. However, on some 35698 machines when the condition code is set this way some bits (such as 35699 the overflow bit) are not set in the same way as a test 35700 instruction, so that a different branch instruction must be used 35701 for some conditional branches. When this happens, use the machine 35702 mode of the condition code register to record different formats of 35703 the condition code register. Modes can also be used to record 35704 which compare instruction (e.g. a signed or an unsigned 35705 comparison) produced the condition codes. 35706 35707 If other modes than 'CCmode' are required, add them to 35708 'MACHINE-modes.def' and define 'SELECT_CC_MODE' to choose a mode 35709 given an operand of a compare. This is needed because the modes 35710 have to be chosen not only during RTL generation but also, for 35711 example, by instruction combination. The result of 35712 'SELECT_CC_MODE' should be consistent with the mode used in the 35713 patterns; for example to support the case of the add on the SPARC 35714 discussed above, we have the pattern 35715 35716 (define_insn "" 35717 [(set (reg:CCNZ 0) 35718 (compare:CCNZ 35719 (plus:SI (match_operand:SI 0 "register_operand" "%r") 35720 (match_operand:SI 1 "arith_operand" "rI")) 35721 (const_int 0)))] 35722 "" 35723 "...") 35724 35725 together with a 'SELECT_CC_MODE' that returns 'CCNZmode' for 35726 comparisons whose argument is a 'plus': 35727 35728 #define SELECT_CC_MODE(OP,X,Y) \ 35729 (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ 35730 ? ((OP == LT || OP == LE || OP == GT || OP == GE) \ 35731 ? CCFPEmode : CCFPmode) \ 35732 : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ 35733 || GET_CODE (X) == NEG || GET_CODE (x) == ASHIFT) \ 35734 ? CCNZmode : CCmode)) 35735 35736 Another reason to use modes is to retain information on which 35737 operands were used by the comparison; see 'REVERSIBLE_CC_MODE' 35738 later in this section. 35739 35740 You should define this macro if and only if you define extra CC 35741 modes in 'MACHINE-modes.def'. 35742 35743 -- Target Hook: void TARGET_CANONICALIZE_COMPARISON (int *CODE, rtx 35744 *OP0, rtx *OP1, bool OP0_PRESERVE_VALUE) 35745 On some machines not all possible comparisons are defined, but you 35746 can convert an invalid comparison into a valid one. For example, 35747 the Alpha does not have a 'GT' comparison, but you can use an 'LT' 35748 comparison instead and swap the order of the operands. 35749 35750 On such machines, implement this hook to do any required 35751 conversions. CODE is the initial comparison code and OP0 and OP1 35752 are the left and right operands of the comparison, respectively. 35753 If OP0_PRESERVE_VALUE is 'true' the implementation is not allowed 35754 to change the value of OP0 since the value might be used in RTXs 35755 which aren't comparisons. E.g. the implementation is not allowed 35756 to swap operands in that case. 35757 35758 GCC will not assume that the comparison resulting from this macro 35759 is valid but will see if the resulting insn matches a pattern in 35760 the 'md' file. 35761 35762 You need not to implement this hook if it would never change the 35763 comparison code or operands. 35764 35765 -- Macro: REVERSIBLE_CC_MODE (MODE) 35766 A C expression whose value is one if it is always safe to reverse a 35767 comparison whose mode is MODE. If 'SELECT_CC_MODE' can ever return 35768 MODE for a floating-point inequality comparison, then 35769 'REVERSIBLE_CC_MODE (MODE)' must be zero. 35770 35771 You need not define this macro if it would always returns zero or 35772 if the floating-point format is anything other than 35773 'IEEE_FLOAT_FORMAT'. For example, here is the definition used on 35774 the SPARC, where floating-point inequality comparisons are given 35775 either 'CCFPEmode' or 'CCFPmode': 35776 35777 #define REVERSIBLE_CC_MODE(MODE) \ 35778 ((MODE) != CCFPEmode && (MODE) != CCFPmode) 35779 35780 -- Macro: REVERSE_CONDITION (CODE, MODE) 35781 A C expression whose value is reversed condition code of the CODE 35782 for comparison done in CC_MODE MODE. The macro is used only in 35783 case 'REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in 35784 case machine has some non-standard way how to reverse certain 35785 conditionals. For instance in case all floating point conditions 35786 are non-trapping, compiler may freely convert unordered compares to 35787 ordered ones. Then definition may look like: 35788 35789 #define REVERSE_CONDITION(CODE, MODE) \ 35790 ((MODE) != CCFPmode ? reverse_condition (CODE) \ 35791 : reverse_condition_maybe_unordered (CODE)) 35792 35793 -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int 35794 *P1, unsigned int *P2) 35795 On targets which do not use '(cc0)', and which use a hard register 35796 rather than a pseudo-register to hold condition codes, the regular 35797 CSE passes are often not able to identify cases in which the hard 35798 register is set to a common value. Use this hook to enable a small 35799 pass which optimizes such cases. This hook should return true to 35800 enable this pass, and it should set the integers to which its 35801 arguments point to the hard register numbers used for condition 35802 codes. When there is only one such register, as is true on most 35803 systems, the integer pointed to by P2 should be set to 35804 'INVALID_REGNUM'. 35805 35806 The default version of this hook returns false. 35807 35808 -- Target Hook: machine_mode TARGET_CC_MODES_COMPATIBLE (machine_mode 35809 M1, machine_mode M2) 35810 On targets which use multiple condition code modes in class 35811 'MODE_CC', it is sometimes the case that a comparison can be 35812 validly done in more than one mode. On such a system, define this 35813 target hook to take two mode arguments and to return a mode in 35814 which both comparisons may be validly done. If there is no such 35815 mode, return 'VOIDmode'. 35816 35817 The default version of this hook checks whether the modes are the 35818 same. If they are, it returns that mode. If they are different, 35819 it returns 'VOIDmode'. 35820 35821 -- Target Hook: unsigned int TARGET_FLAGS_REGNUM 35822 If the target has a dedicated flags register, and it needs to use 35823 the post-reload comparison elimination pass, then this value should 35824 be set appropriately. 35825 35826 35827File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros 35828 3582918.16 Describing Relative Costs of Operations 35830============================================= 35831 35832These macros let you describe the relative speed of various operations 35833on the target machine. 35834 35835 -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO) 35836 A C expression for the cost of moving data of mode MODE from a 35837 register in class FROM to one in class TO. The classes are 35838 expressed using the enumeration values such as 'GENERAL_REGS'. A 35839 value of 2 is the default; other values are interpreted relative to 35840 that. 35841 35842 It is not required that the cost always equal 2 when FROM is the 35843 same as TO; on some machines it is expensive to move between 35844 registers if they are not general registers. 35845 35846 If reload sees an insn consisting of a single 'set' between two 35847 hard registers, and if 'REGISTER_MOVE_COST' applied to their 35848 classes returns a value of 2, reload does not check to ensure that 35849 the constraints of the insn are met. Setting a cost of other than 35850 2 will allow reload to verify that the constraints are met. You 35851 should do this if the 'movM' pattern's constraints do not allow 35852 such copying. 35853 35854 These macros are obsolete, new ports should use the target hook 35855 'TARGET_REGISTER_MOVE_COST' instead. 35856 35857 -- Target Hook: int TARGET_REGISTER_MOVE_COST (machine_mode MODE, 35858 reg_class_t FROM, reg_class_t TO) 35859 This target hook should return the cost of moving data of mode MODE 35860 from a register in class FROM to one in class TO. The classes are 35861 expressed using the enumeration values such as 'GENERAL_REGS'. A 35862 value of 2 is the default; other values are interpreted relative to 35863 that. 35864 35865 It is not required that the cost always equal 2 when FROM is the 35866 same as TO; on some machines it is expensive to move between 35867 registers if they are not general registers. 35868 35869 If reload sees an insn consisting of a single 'set' between two 35870 hard registers, and if 'TARGET_REGISTER_MOVE_COST' applied to their 35871 classes returns a value of 2, reload does not check to ensure that 35872 the constraints of the insn are met. Setting a cost of other than 35873 2 will allow reload to verify that the constraints are met. You 35874 should do this if the 'movM' pattern's constraints do not allow 35875 such copying. 35876 35877 The default version of this function returns 2. 35878 35879 -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN) 35880 A C expression for the cost of moving data of mode MODE between a 35881 register of class CLASS and memory; IN is zero if the value is to 35882 be written to memory, nonzero if it is to be read in. This cost is 35883 relative to those in 'REGISTER_MOVE_COST'. If moving between 35884 registers and memory is more expensive than between two registers, 35885 you should define this macro to express the relative cost. 35886 35887 If you do not define this macro, GCC uses a default cost of 4 plus 35888 the cost of copying via a secondary reload register, if one is 35889 needed. If your machine requires a secondary reload register to 35890 copy between memory and a register of CLASS but the reload 35891 mechanism is more complex than copying via an intermediate, define 35892 this macro to reflect the actual cost of the move. 35893 35894 GCC defines the function 'memory_move_secondary_cost' if secondary 35895 reloads are needed. It computes the costs due to copying via a 35896 secondary register. If your machine copies from memory using a 35897 secondary register in the conventional way but the default base 35898 value of 4 is not correct for your machine, define this macro to 35899 add some other value to the result of that function. The arguments 35900 to that function are the same as to this macro. 35901 35902 These macros are obsolete, new ports should use the target hook 35903 'TARGET_MEMORY_MOVE_COST' instead. 35904 35905 -- Target Hook: int TARGET_MEMORY_MOVE_COST (machine_mode MODE, 35906 reg_class_t RCLASS, bool IN) 35907 This target hook should return the cost of moving data of mode MODE 35908 between a register of class RCLASS and memory; IN is 'false' if the 35909 value is to be written to memory, 'true' if it is to be read in. 35910 This cost is relative to those in 'TARGET_REGISTER_MOVE_COST'. If 35911 moving between registers and memory is more expensive than between 35912 two registers, you should add this target hook to express the 35913 relative cost. 35914 35915 If you do not add this target hook, GCC uses a default cost of 4 35916 plus the cost of copying via a secondary reload register, if one is 35917 needed. If your machine requires a secondary reload register to 35918 copy between memory and a register of RCLASS but the reload 35919 mechanism is more complex than copying via an intermediate, use 35920 this target hook to reflect the actual cost of the move. 35921 35922 GCC defines the function 'memory_move_secondary_cost' if secondary 35923 reloads are needed. It computes the costs due to copying via a 35924 secondary register. If your machine copies from memory using a 35925 secondary register in the conventional way but the default base 35926 value of 4 is not correct for your machine, use this target hook to 35927 add some other value to the result of that function. The arguments 35928 to that function are the same as to this target hook. 35929 35930 -- Macro: BRANCH_COST (SPEED_P, PREDICTABLE_P) 35931 A C expression for the cost of a branch instruction. A value of 1 35932 is the default; other values are interpreted relative to that. 35933 Parameter SPEED_P is true when the branch in question should be 35934 optimized for speed. When it is false, 'BRANCH_COST' should return 35935 a value optimal for code size rather than performance. 35936 PREDICTABLE_P is true for well-predicted branches. On many 35937 architectures the 'BRANCH_COST' can be reduced then. 35938 35939 Here are additional macros which do not specify precise relative costs, 35940but only that certain actions are more expensive than GCC would 35941ordinarily expect. 35942 35943 -- Macro: SLOW_BYTE_ACCESS 35944 Define this macro as a C expression which is nonzero if accessing 35945 less than a word of memory (i.e. a 'char' or a 'short') is no 35946 faster than accessing a word of memory, i.e., if such access 35947 require more than one instruction or if there is no difference in 35948 cost between byte and (aligned) word loads. 35949 35950 When this macro is not defined, the compiler will access a field by 35951 finding the smallest containing object; when it is defined, a 35952 fullword load will be used if alignment permits. Unless bytes 35953 accesses are faster than word accesses, using word accesses is 35954 preferable since it may eliminate subsequent memory access if 35955 subsequent accesses occur to other fields in the same word of the 35956 structure, but to different bytes. 35957 35958 -- Target Hook: bool TARGET_SLOW_UNALIGNED_ACCESS (machine_mode MODE, 35959 unsigned int ALIGN) 35960 This hook returns true if memory accesses described by the MODE and 35961 ALIGNMENT parameters have a cost many times greater than aligned 35962 accesses, for example if they are emulated in a trap handler. This 35963 hook is invoked only for unaligned accesses, i.e. when 'ALIGNMENT 35964 < GET_MODE_ALIGNMENT (MODE)'. 35965 35966 When this hook returns true, the compiler will act as if 35967 'STRICT_ALIGNMENT' were true when generating code for block moves. 35968 This can cause significantly more instructions to be produced. 35969 Therefore, do not make this hook return true if unaligned accesses 35970 only add a cycle or two to the time for a memory access. 35971 35972 The hook must return true whenever 'STRICT_ALIGNMENT' is true. The 35973 default implementation returns 'STRICT_ALIGNMENT'. 35974 35975 -- Macro: MOVE_RATIO (SPEED) 35976 The threshold of number of scalar memory-to-memory move insns, 35977 _below_ which a sequence of insns should be generated instead of a 35978 string move insn or a library call. Increasing the value will 35979 always make code faster, but eventually incurs high cost in 35980 increased code size. 35981 35982 Note that on machines where the corresponding move insn is a 35983 'define_expand' that emits a sequence of insns, this macro counts 35984 the number of such sequences. 35985 35986 The parameter SPEED is true if the code is currently being 35987 optimized for speed rather than size. 35988 35989 If you don't define this, a reasonable default is used. 35990 35991 -- Target Hook: bool TARGET_USE_BY_PIECES_INFRASTRUCTURE_P (unsigned 35992 HOST_WIDE_INT SIZE, unsigned int ALIGNMENT, enum 35993 by_pieces_operation OP, bool SPEED_P) 35994 GCC will attempt several strategies when asked to copy between two 35995 areas of memory, or to set, clear or store to memory, for example 35996 when copying a 'struct'. The 'by_pieces' infrastructure implements 35997 such memory operations as a sequence of load, store or move insns. 35998 Alternate strategies are to expand the 'movmem' or 'setmem' optabs, 35999 to emit a library call, or to emit unit-by-unit, loop-based 36000 operations. 36001 36002 This target hook should return true if, for a memory operation with 36003 a given SIZE and ALIGNMENT, using the 'by_pieces' infrastructure is 36004 expected to result in better code generation. Both SIZE and 36005 ALIGNMENT are measured in terms of storage units. 36006 36007 The parameter OP is one of: 'CLEAR_BY_PIECES', 'MOVE_BY_PIECES', 36008 'SET_BY_PIECES', 'STORE_BY_PIECES' or 'COMPARE_BY_PIECES'. These 36009 describe the type of memory operation under consideration. 36010 36011 The parameter SPEED_P is true if the code is currently being 36012 optimized for speed rather than size. 36013 36014 Returning true for higher values of SIZE can improve code 36015 generation for speed if the target does not provide an 36016 implementation of the 'movmem' or 'setmem' standard names, if the 36017 'movmem' or 'setmem' implementation would be more expensive than a 36018 sequence of insns, or if the overhead of a library call would 36019 dominate that of the body of the memory operation. 36020 36021 Returning true for higher values of 'size' may also cause an 36022 increase in code size, for example where the number of insns 36023 emitted to perform a move would be greater than that of a library 36024 call. 36025 36026 -- Target Hook: int TARGET_COMPARE_BY_PIECES_BRANCH_RATIO (machine_mode 36027 MODE) 36028 When expanding a block comparison in MODE, gcc can try to reduce 36029 the number of branches at the expense of more memory operations. 36030 This hook allows the target to override the default choice. It 36031 should return the factor by which branches should be reduced over 36032 the plain expansion with one comparison per MODE-sized piece. A 36033 port can also prevent a particular mode from being used for block 36034 comparisons by returning a negative number from this hook. 36035 36036 -- Macro: MOVE_MAX_PIECES 36037 A C expression used by 'move_by_pieces' to determine the largest 36038 unit a load or store used to copy memory is. Defaults to 36039 'MOVE_MAX'. 36040 36041 -- Macro: STORE_MAX_PIECES 36042 A C expression used by 'store_by_pieces' to determine the largest 36043 unit a store used to memory is. Defaults to 'MOVE_MAX_PIECES', or 36044 two times the size of 'HOST_WIDE_INT', whichever is smaller. 36045 36046 -- Macro: COMPARE_MAX_PIECES 36047 A C expression used by 'compare_by_pieces' to determine the largest 36048 unit a load or store used to compare memory is. Defaults to 36049 'MOVE_MAX_PIECES'. 36050 36051 -- Macro: CLEAR_RATIO (SPEED) 36052 The threshold of number of scalar move insns, _below_ which a 36053 sequence of insns should be generated to clear memory instead of a 36054 string clear insn or a library call. Increasing the value will 36055 always make code faster, but eventually incurs high cost in 36056 increased code size. 36057 36058 The parameter SPEED is true if the code is currently being 36059 optimized for speed rather than size. 36060 36061 If you don't define this, a reasonable default is used. 36062 36063 -- Macro: SET_RATIO (SPEED) 36064 The threshold of number of scalar move insns, _below_ which a 36065 sequence of insns should be generated to set memory to a constant 36066 value, instead of a block set insn or a library call. Increasing 36067 the value will always make code faster, but eventually incurs high 36068 cost in increased code size. 36069 36070 The parameter SPEED is true if the code is currently being 36071 optimized for speed rather than size. 36072 36073 If you don't define this, it defaults to the value of 'MOVE_RATIO'. 36074 36075 -- Macro: USE_LOAD_POST_INCREMENT (MODE) 36076 A C expression used to determine whether a load postincrement is a 36077 good thing to use for a given mode. Defaults to the value of 36078 'HAVE_POST_INCREMENT'. 36079 36080 -- Macro: USE_LOAD_POST_DECREMENT (MODE) 36081 A C expression used to determine whether a load postdecrement is a 36082 good thing to use for a given mode. Defaults to the value of 36083 'HAVE_POST_DECREMENT'. 36084 36085 -- Macro: USE_LOAD_PRE_INCREMENT (MODE) 36086 A C expression used to determine whether a load preincrement is a 36087 good thing to use for a given mode. Defaults to the value of 36088 'HAVE_PRE_INCREMENT'. 36089 36090 -- Macro: USE_LOAD_PRE_DECREMENT (MODE) 36091 A C expression used to determine whether a load predecrement is a 36092 good thing to use for a given mode. Defaults to the value of 36093 'HAVE_PRE_DECREMENT'. 36094 36095 -- Macro: USE_STORE_POST_INCREMENT (MODE) 36096 A C expression used to determine whether a store postincrement is a 36097 good thing to use for a given mode. Defaults to the value of 36098 'HAVE_POST_INCREMENT'. 36099 36100 -- Macro: USE_STORE_POST_DECREMENT (MODE) 36101 A C expression used to determine whether a store postdecrement is a 36102 good thing to use for a given mode. Defaults to the value of 36103 'HAVE_POST_DECREMENT'. 36104 36105 -- Macro: USE_STORE_PRE_INCREMENT (MODE) 36106 This macro is used to determine whether a store preincrement is a 36107 good thing to use for a given mode. Defaults to the value of 36108 'HAVE_PRE_INCREMENT'. 36109 36110 -- Macro: USE_STORE_PRE_DECREMENT (MODE) 36111 This macro is used to determine whether a store predecrement is a 36112 good thing to use for a given mode. Defaults to the value of 36113 'HAVE_PRE_DECREMENT'. 36114 36115 -- Macro: NO_FUNCTION_CSE 36116 Define this macro to be true if it is as good or better to call a 36117 constant function address than to call an address kept in a 36118 register. 36119 36120 -- Macro: LOGICAL_OP_NON_SHORT_CIRCUIT 36121 Define this macro if a non-short-circuit operation produced by 36122 'fold_range_test ()' is optimal. This macro defaults to true if 36123 'BRANCH_COST' is greater than or equal to the value 2. 36124 36125 -- Target Hook: bool TARGET_OPTAB_SUPPORTED_P (int OP, machine_mode 36126 MODE1, machine_mode MODE2, optimization_type OPT_TYPE) 36127 Return true if the optimizers should use optab OP with modes MODE1 36128 and MODE2 for optimization type OPT_TYPE. The optab is known to 36129 have an associated '.md' instruction whose C condition is true. 36130 MODE2 is only meaningful for conversion optabs; for direct optabs 36131 it is a copy of MODE1. 36132 36133 For example, when called with OP equal to 'rint_optab' and MODE1 36134 equal to 'DFmode', the hook should say whether the optimizers 36135 should use optab 'rintdf2'. 36136 36137 The default hook returns true for all inputs. 36138 36139 -- Target Hook: bool TARGET_RTX_COSTS (rtx X, machine_mode MODE, int 36140 OUTER_CODE, int OPNO, int *TOTAL, bool SPEED) 36141 This target hook describes the relative costs of RTL expressions. 36142 36143 The cost may depend on the precise form of the expression, which is 36144 available for examination in X, and the fact that X appears as 36145 operand OPNO of an expression with rtx code OUTER_CODE. That is, 36146 the hook can assume that there is some rtx Y such that 'GET_CODE 36147 (Y) == OUTER_CODE' and such that either (a) 'XEXP (Y, OPNO) == X' 36148 or (b) 'XVEC (Y, OPNO)' contains X. 36149 36150 MODE is X's machine mode, or for cases like 'const_int' that do not 36151 have a mode, the mode in which X is used. 36152 36153 In implementing this hook, you can use the construct 'COSTS_N_INSNS 36154 (N)' to specify a cost equal to N fast instructions. 36155 36156 On entry to the hook, '*TOTAL' contains a default estimate for the 36157 cost of the expression. The hook should modify this value as 36158 necessary. Traditionally, the default costs are 'COSTS_N_INSNS 36159 (5)' for multiplications, 'COSTS_N_INSNS (7)' for division and 36160 modulus operations, and 'COSTS_N_INSNS (1)' for all other 36161 operations. 36162 36163 When optimizing for code size, i.e. when 'speed' is false, this 36164 target hook should be used to estimate the relative size cost of an 36165 expression, again relative to 'COSTS_N_INSNS'. 36166 36167 The hook returns true when all subexpressions of X have been 36168 processed, and false when 'rtx_cost' should recurse. 36169 36170 -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS, machine_mode 36171 MODE, addr_space_t AS, bool SPEED) 36172 This hook computes the cost of an addressing mode that contains 36173 ADDRESS. If not defined, the cost is computed from the ADDRESS 36174 expression and the 'TARGET_RTX_COST' hook. 36175 36176 For most CISC machines, the default cost is a good approximation of 36177 the true cost of the addressing mode. However, on RISC machines, 36178 all instructions normally have the same length and execution time. 36179 Hence all addresses will have equal costs. 36180 36181 In cases where more than one form of an address is known, the form 36182 with the lowest cost will be used. If multiple forms have the 36183 same, lowest, cost, the one that is the most complex will be used. 36184 36185 For example, suppose an address that is equal to the sum of a 36186 register and a constant is used twice in the same basic block. 36187 When this macro is not defined, the address will be computed in a 36188 register and memory references will be indirect through that 36189 register. On machines where the cost of the addressing mode 36190 containing the sum is no higher than that of a simple indirect 36191 reference, this will produce an additional instruction and possibly 36192 require an additional register. Proper specification of this macro 36193 eliminates this overhead for such machines. 36194 36195 This hook is never called with an invalid address. 36196 36197 On machines where an address involving more than one register is as 36198 cheap as an address computation involving only one register, 36199 defining 'TARGET_ADDRESS_COST' to reflect this can cause two 36200 registers to be live over a region of code where only one would 36201 have been if 'TARGET_ADDRESS_COST' were not defined in that manner. 36202 This effect should be considered in the definition of this macro. 36203 Equivalent costs should probably only be given to addresses with 36204 different numbers of registers on machines with lots of registers. 36205 36206 -- Target Hook: int TARGET_INSN_COST (rtx_insn *INSN, bool SPEED) 36207 This target hook describes the relative costs of RTL instructions. 36208 36209 In implementing this hook, you can use the construct 'COSTS_N_INSNS 36210 (N)' to specify a cost equal to N fast instructions. 36211 36212 When optimizing for code size, i.e. when 'speed' is false, this 36213 target hook should be used to estimate the relative size cost of an 36214 expression, again relative to 'COSTS_N_INSNS'. 36215 36216 -- Target Hook: unsigned int TARGET_MAX_NOCE_IFCVT_SEQ_COST (edge E) 36217 This hook returns a value in the same units as 'TARGET_RTX_COSTS', 36218 giving the maximum acceptable cost for a sequence generated by the 36219 RTL if-conversion pass when conditional execution is not available. 36220 The RTL if-conversion pass attempts to convert conditional 36221 operations that would require a branch to a series of unconditional 36222 operations and 'movMODEcc' insns. This hook returns the maximum 36223 cost of the unconditional instructions and the 'movMODEcc' insns. 36224 RTL if-conversion is cancelled if the cost of the converted 36225 sequence is greater than the value returned by this hook. 36226 36227 'e' is the edge between the basic block containing the conditional 36228 branch to the basic block which would be executed if the condition 36229 were true. 36230 36231 The default implementation of this hook uses the 36232 'max-rtl-if-conversion-[un]predictable' parameters if they are set, 36233 and uses a multiple of 'BRANCH_COST' otherwise. 36234 36235 -- Target Hook: bool TARGET_NOCE_CONVERSION_PROFITABLE_P (rtx_insn 36236 *SEQ, struct noce_if_info *IF_INFO) 36237 This hook returns true if the instruction sequence 'seq' is a good 36238 candidate as a replacement for the if-convertible sequence 36239 described in 'if_info'. 36240 36241 -- Target Hook: bool TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P (void) 36242 This predicate controls the use of the eager delay slot filler to 36243 disallow speculatively executed instructions being placed in delay 36244 slots. Targets such as certain MIPS architectures possess both 36245 branches with and without delay slots. As the eager delay slot 36246 filler can decrease performance, disabling it is beneficial when 36247 ordinary branches are available. Use of delay slot branches filled 36248 using the basic filler is often still desirable as the delay slot 36249 can hide a pipeline bubble. 36250 36251 -- Target Hook: HOST_WIDE_INT TARGET_ESTIMATED_POLY_VALUE (poly_int64 36252 VAL) 36253 Return an estimate of the runtime value of VAL, for use in things 36254 like cost calculations or profiling frequencies. The default 36255 implementation returns the lowest possible value of VAL. 36256 36257 36258File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros 36259 3626018.17 Adjusting the Instruction Scheduler 36261========================================= 36262 36263The instruction scheduler may need a fair amount of machine-specific 36264adjustment in order to produce good code. GCC provides several target 36265hooks for this purpose. It is usually enough to define just a few of 36266them: try the first ones in this list first. 36267 36268 -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void) 36269 This hook returns the maximum number of instructions that can ever 36270 issue at the same time on the target machine. The default is one. 36271 Although the insn scheduler can define itself the possibility of 36272 issue an insn on the same cycle, the value can serve as an 36273 additional constraint to issue insns on the same simulated 36274 processor cycle (see hooks 'TARGET_SCHED_REORDER' and 36275 'TARGET_SCHED_REORDER2'). This value must be constant over the 36276 entire compilation. If you need it to vary depending on what the 36277 instructions are, you must use 'TARGET_SCHED_VARIABLE_ISSUE'. 36278 36279 -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int 36280 VERBOSE, rtx_insn *INSN, int MORE) 36281 This hook is executed by the scheduler after it has scheduled an 36282 insn from the ready list. It should return the number of insns 36283 which can still be issued in the current cycle. The default is 36284 'MORE - 1' for insns other than 'CLOBBER' and 'USE', which normally 36285 are not counted against the issue rate. You should define this 36286 hook if some insns take more machine resources than others, so that 36287 fewer insns can follow them in the same cycle. FILE is either a 36288 null pointer, or a stdio stream to write any debug output to. 36289 VERBOSE is the verbose level provided by '-fsched-verbose-N'. INSN 36290 is the instruction that was scheduled. 36291 36292 -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx_insn *INSN, int 36293 DEP_TYPE1, rtx_insn *DEP_INSN, int COST, unsigned int DW) 36294 This function corrects the value of COST based on the relationship 36295 between INSN and DEP_INSN through a dependence of type dep_type, 36296 and strength DW. It should return the new value. The default is 36297 to make no adjustment to COST. This can be used for example to 36298 specify to the scheduler using the traditional pipeline description 36299 that an output- or anti-dependence does not incur the same cost as 36300 a data-dependence. If the scheduler using the automaton based 36301 pipeline description, the cost of anti-dependence is zero and the 36302 cost of output-dependence is maximum of one and the difference of 36303 latency times of the first and the second insns. If these values 36304 are not acceptable, you could use the hook to modify them too. See 36305 also *note Processor pipeline description::. 36306 36307 -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx_insn *INSN, int 36308 PRIORITY) 36309 This hook adjusts the integer scheduling priority PRIORITY of INSN. 36310 It should return the new priority. Increase the priority to 36311 execute INSN earlier, reduce the priority to execute INSN later. 36312 Do not define this hook if you do not need to adjust the scheduling 36313 priorities of insns. 36314 36315 -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, 36316 rtx_insn **READY, int *N_READYP, int CLOCK) 36317 This hook is executed by the scheduler after it has scheduled the 36318 ready list, to allow the machine description to reorder it (for 36319 example to combine two small instructions together on 'VLIW' 36320 machines). FILE is either a null pointer, or a stdio stream to 36321 write any debug output to. VERBOSE is the verbose level provided 36322 by '-fsched-verbose-N'. READY is a pointer to the ready list of 36323 instructions that are ready to be scheduled. N_READYP is a pointer 36324 to the number of elements in the ready list. The scheduler reads 36325 the ready list in reverse order, starting with READY[*N_READYP - 1] 36326 and going to READY[0]. CLOCK is the timer tick of the scheduler. 36327 You may modify the ready list and the number of ready insns. The 36328 return value is the number of insns that can issue this cycle; 36329 normally this is just 'issue_rate'. See also 36330 'TARGET_SCHED_REORDER2'. 36331 36332 -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE, 36333 rtx_insn **READY, int *N_READYP, int CLOCK) 36334 Like 'TARGET_SCHED_REORDER', but called at a different time. That 36335 function is called whenever the scheduler starts a new cycle. This 36336 one is called once per iteration over a cycle, immediately after 36337 'TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list and 36338 return the number of insns to be scheduled in the same cycle. 36339 Defining this hook can be useful if there are frequent situations 36340 where scheduling one insn causes other insns to become ready in the 36341 same cycle. These other insns can then be taken into account 36342 properly. 36343 36344 -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_P (void) 36345 This hook is used to check whether target platform supports macro 36346 fusion. 36347 36348 -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_PAIR_P (rtx_insn *PREV, 36349 rtx_insn *CURR) 36350 This hook is used to check whether two insns should be macro fused 36351 for a target microarchitecture. If this hook returns true for the 36352 given insn pair (PREV and CURR), the scheduler will put them into a 36353 sched group, and they will not be scheduled apart. The two insns 36354 will be either two SET insns or a compare and a conditional jump 36355 and this hook should validate any dependencies needed to fuse the 36356 two insns together. 36357 36358 -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK 36359 (rtx_insn *HEAD, rtx_insn *TAIL) 36360 This hook is called after evaluation forward dependencies of insns 36361 in chain given by two parameter values (HEAD and TAIL 36362 correspondingly) but before insns scheduling of the insn chain. 36363 For example, it can be used for better insn classification if it 36364 requires analysis of dependencies. This hook can use backward and 36365 forward dependencies of the insn scheduler because they are already 36366 calculated. 36367 36368 -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int 36369 MAX_READY) 36370 This hook is executed by the scheduler at the beginning of each 36371 block of instructions that are to be scheduled. FILE is either a 36372 null pointer, or a stdio stream to write any debug output to. 36373 VERBOSE is the verbose level provided by '-fsched-verbose-N'. 36374 MAX_READY is the maximum number of insns in the current scheduling 36375 region that can be live at the same time. This can be used to 36376 allocate scratch space if it is needed, e.g. by 36377 'TARGET_SCHED_REORDER'. 36378 36379 -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE) 36380 This hook is executed by the scheduler at the end of each block of 36381 instructions that are to be scheduled. It can be used to perform 36382 cleanup of any actions done by the other scheduling hooks. FILE is 36383 either a null pointer, or a stdio stream to write any debug output 36384 to. VERBOSE is the verbose level provided by '-fsched-verbose-N'. 36385 36386 -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int VERBOSE, 36387 int OLD_MAX_UID) 36388 This hook is executed by the scheduler after function level 36389 initializations. FILE is either a null pointer, or a stdio stream 36390 to write any debug output to. VERBOSE is the verbose level 36391 provided by '-fsched-verbose-N'. OLD_MAX_UID is the maximum insn 36392 uid when scheduling begins. 36393 36394 -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int 36395 VERBOSE) 36396 This is the cleanup hook corresponding to 36397 'TARGET_SCHED_INIT_GLOBAL'. FILE is either a null pointer, or a 36398 stdio stream to write any debug output to. VERBOSE is the verbose 36399 level provided by '-fsched-verbose-N'. 36400 36401 -- Target Hook: rtx TARGET_SCHED_DFA_PRE_CYCLE_INSN (void) 36402 The hook returns an RTL insn. The automaton state used in the 36403 pipeline hazard recognizer is changed as if the insn were scheduled 36404 when the new simulated processor cycle starts. Usage of the hook 36405 may simplify the automaton pipeline description for some VLIW 36406 processors. If the hook is defined, it is used only for the 36407 automaton based pipeline description. The default is not to change 36408 the state when the new simulated processor cycle starts. 36409 36410 -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void) 36411 The hook can be used to initialize data used by the previous hook. 36412 36413 -- Target Hook: rtx_insn * TARGET_SCHED_DFA_POST_CYCLE_INSN (void) 36414 The hook is analogous to 'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used 36415 to changed the state as if the insn were scheduled when the new 36416 simulated processor cycle finishes. 36417 36418 -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void) 36419 The hook is analogous to 'TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but 36420 used to initialize data used by the previous hook. 36421 36422 -- Target Hook: void TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE (void) 36423 The hook to notify target that the current simulated cycle is about 36424 to finish. The hook is analogous to 36425 'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used to change the state in 36426 more complicated situations - e.g., when advancing state on a 36427 single insn is not enough. 36428 36429 -- Target Hook: void TARGET_SCHED_DFA_POST_ADVANCE_CYCLE (void) 36430 The hook to notify target that new simulated cycle has just 36431 started. The hook is analogous to 36432 'TARGET_SCHED_DFA_POST_CYCLE_INSN' but used to change the state in 36433 more complicated situations - e.g., when advancing state on a 36434 single insn is not enough. 36435 36436 -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 36437 (void) 36438 This hook controls better choosing an insn from the ready insn 36439 queue for the DFA-based insn scheduler. Usually the scheduler 36440 chooses the first insn from the queue. If the hook returns a 36441 positive value, an additional scheduler code tries all permutations 36442 of 'TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD ()' subsequent 36443 ready insns to choose an insn whose issue will result in maximal 36444 number of issued insns on the same cycle. For the VLIW processor, 36445 the code could actually solve the problem of packing simple insns 36446 into the VLIW insn. Of course, if the rules of VLIW packing are 36447 described in the automaton. 36448 36449 This code also could be used for superscalar RISC processors. Let 36450 us consider a superscalar RISC processor with 3 pipelines. Some 36451 insns can be executed in pipelines A or B, some insns can be 36452 executed only in pipelines B or C, and one insn can be executed in 36453 pipeline B. The processor may issue the 1st insn into A and the 36454 2nd one into B. In this case, the 3rd insn will wait for freeing B 36455 until the next cycle. If the scheduler issues the 3rd insn the 36456 first, the processor could issue all 3 insns per cycle. 36457 36458 Actually this code demonstrates advantages of the automaton based 36459 pipeline hazard recognizer. We try quickly and easy many insn 36460 schedules to choose the best one. 36461 36462 The default is no multipass scheduling. 36463 36464 -- Target Hook: int 36465 TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD 36466 (rtx_insn *INSN, int READY_INDEX) 36467 36468 This hook controls what insns from the ready insn queue will be 36469 considered for the multipass insn scheduling. If the hook returns 36470 zero for INSN, the insn will be considered in multipass scheduling. 36471 Positive return values will remove INSN from consideration on the 36472 current round of multipass scheduling. Negative return values will 36473 remove INSN from consideration for given number of cycles. 36474 Backends should be careful about returning non-zero for highest 36475 priority instruction at position 0 in the ready list. READY_INDEX 36476 is passed to allow backends make correct judgements. 36477 36478 The default is that any ready insns can be chosen to be issued. 36479 36480 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN (void 36481 *DATA, signed char *READY_TRY, int N_READY, bool 36482 FIRST_CYCLE_INSN_P) 36483 This hook prepares the target backend for a new round of multipass 36484 scheduling. 36485 36486 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE (void 36487 *DATA, signed char *READY_TRY, int N_READY, rtx_insn *INSN, 36488 const void *PREV_DATA) 36489 This hook is called when multipass scheduling evaluates instruction 36490 INSN. 36491 36492 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK 36493 (const void *DATA, signed char *READY_TRY, int N_READY) 36494 This is called when multipass scheduling backtracks from evaluation 36495 of an instruction. 36496 36497 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END (const void 36498 *DATA) 36499 This hook notifies the target about the result of the concluded 36500 current round of multipass scheduling. 36501 36502 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT (void 36503 *DATA) 36504 This hook initializes target-specific data used in multipass 36505 scheduling. 36506 36507 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI (void 36508 *DATA) 36509 This hook finalizes target-specific data used in multipass 36510 scheduling. 36511 36512 -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *DUMP, int 36513 VERBOSE, rtx_insn *INSN, int LAST_CLOCK, int CLOCK, int 36514 *SORT_P) 36515 This hook is called by the insn scheduler before issuing INSN on 36516 cycle CLOCK. If the hook returns nonzero, INSN is not issued on 36517 this processor cycle. Instead, the processor cycle is advanced. 36518 If *SORT_P is zero, the insn ready queue is not sorted on the new 36519 cycle start as usually. DUMP and VERBOSE specify the file and 36520 verbosity level to use for debugging output. LAST_CLOCK and CLOCK 36521 are, respectively, the processor cycle on which the previous insn 36522 has been issued, and the current processor cycle. 36523 36524 -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (struct _dep 36525 *_DEP, int COST, int DISTANCE) 36526 This hook is used to define which dependences are considered costly 36527 by the target, so costly that it is not advisable to schedule the 36528 insns that are involved in the dependence too close to one another. 36529 The parameters to this hook are as follows: The first parameter 36530 _DEP is the dependence being evaluated. The second parameter COST 36531 is the cost of the dependence as estimated by the scheduler, and 36532 the third parameter DISTANCE is the distance in cycles between the 36533 two insns. The hook returns 'true' if considering the distance 36534 between the two insns the dependence between them is considered 36535 costly by the target, and 'false' otherwise. 36536 36537 Defining this hook can be useful in multiple-issue out-of-order 36538 machines, where (a) it's practically hopeless to predict the actual 36539 data/resource delays, however: (b) there's a better chance to 36540 predict the actual grouping that will be formed, and (c) correctly 36541 emulating the grouping can be very important. In such targets one 36542 may want to allow issuing dependent insns closer to one 36543 another--i.e., closer than the dependence distance; however, not in 36544 cases of "costly dependences", which this hooks allows to define. 36545 36546 -- Target Hook: void TARGET_SCHED_H_I_D_EXTENDED (void) 36547 This hook is called by the insn scheduler after emitting a new 36548 instruction to the instruction stream. The hook notifies a target 36549 backend to extend its per instruction data structures. 36550 36551 -- Target Hook: void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void) 36552 Return a pointer to a store large enough to hold target scheduling 36553 context. 36554 36555 -- Target Hook: void TARGET_SCHED_INIT_SCHED_CONTEXT (void *TC, bool 36556 CLEAN_P) 36557 Initialize store pointed to by TC to hold target scheduling 36558 context. It CLEAN_P is true then initialize TC as if scheduler is 36559 at the beginning of the block. Otherwise, copy the current context 36560 into TC. 36561 36562 -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC) 36563 Copy target scheduling context pointed to by TC to the current 36564 context. 36565 36566 -- Target Hook: void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *TC) 36567 Deallocate internal data in target scheduling context pointed to by 36568 TC. 36569 36570 -- Target Hook: void TARGET_SCHED_FREE_SCHED_CONTEXT (void *TC) 36571 Deallocate a store for target scheduling context pointed to by TC. 36572 36573 -- Target Hook: int TARGET_SCHED_SPECULATE_INSN (rtx_insn *INSN, 36574 unsigned int DEP_STATUS, rtx *NEW_PAT) 36575 This hook is called by the insn scheduler when INSN has only 36576 speculative dependencies and therefore can be scheduled 36577 speculatively. The hook is used to check if the pattern of INSN 36578 has a speculative version and, in case of successful check, to 36579 generate that speculative pattern. The hook should return 1, if 36580 the instruction has a speculative form, or -1, if it doesn't. 36581 REQUEST describes the type of requested speculation. If the return 36582 value equals 1 then NEW_PAT is assigned the generated speculative 36583 pattern. 36584 36585 -- Target Hook: bool TARGET_SCHED_NEEDS_BLOCK_P (unsigned int 36586 DEP_STATUS) 36587 This hook is called by the insn scheduler during generation of 36588 recovery code for INSN. It should return 'true', if the 36589 corresponding check instruction should branch to recovery code, or 36590 'false' otherwise. 36591 36592 -- Target Hook: rtx TARGET_SCHED_GEN_SPEC_CHECK (rtx_insn *INSN, 36593 rtx_insn *LABEL, unsigned int DS) 36594 This hook is called by the insn scheduler to generate a pattern for 36595 recovery check instruction. If MUTATE_P is zero, then INSN is a 36596 speculative instruction for which the check should be generated. 36597 LABEL is either a label of a basic block, where recovery code 36598 should be emitted, or a null pointer, when requested check doesn't 36599 branch to recovery code (a simple check). If MUTATE_P is nonzero, 36600 then a pattern for a branchy check corresponding to a simple check 36601 denoted by INSN should be generated. In this case LABEL can't be 36602 null. 36603 36604 -- Target Hook: void TARGET_SCHED_SET_SCHED_FLAGS (struct spec_info_def 36605 *SPEC_INFO) 36606 This hook is used by the insn scheduler to find out what features 36607 should be enabled/used. The structure *SPEC_INFO should be filled 36608 in by the target. The structure describes speculation types that 36609 can be used in the scheduler. 36610 36611 -- Target Hook: bool TARGET_SCHED_CAN_SPECULATE_INSN (rtx_insn *INSN) 36612 Some instructions should never be speculated by the schedulers, 36613 usually because the instruction is too expensive to get this wrong. 36614 Often such instructions have long latency, and often they are not 36615 fully modeled in the pipeline descriptions. This hook should 36616 return 'false' if INSN should not be speculated. 36617 36618 -- Target Hook: int TARGET_SCHED_SMS_RES_MII (struct ddg *G) 36619 This hook is called by the swing modulo scheduler to calculate a 36620 resource-based lower bound which is based on the resources 36621 available in the machine and the resources required by each 36622 instruction. The target backend can use G to calculate such bound. 36623 A very simple lower bound will be used in case this hook is not 36624 implemented: the total number of instructions divided by the issue 36625 rate. 36626 36627 -- Target Hook: bool TARGET_SCHED_DISPATCH (rtx_insn *INSN, int X) 36628 This hook is called by Haifa Scheduler. It returns true if 36629 dispatch scheduling is supported in hardware and the condition 36630 specified in the parameter is true. 36631 36632 -- Target Hook: void TARGET_SCHED_DISPATCH_DO (rtx_insn *INSN, int X) 36633 This hook is called by Haifa Scheduler. It performs the operation 36634 specified in its second parameter. 36635 36636 -- Target Hook: bool TARGET_SCHED_EXPOSED_PIPELINE 36637 True if the processor has an exposed pipeline, which means that not 36638 just the order of instructions is important for correctness when 36639 scheduling, but also the latencies of operations. 36640 36641 -- Target Hook: int TARGET_SCHED_REASSOCIATION_WIDTH (unsigned int OPC, 36642 machine_mode MODE) 36643 This hook is called by tree reassociator to determine a level of 36644 parallelism required in output calculations chain. 36645 36646 -- Target Hook: void TARGET_SCHED_FUSION_PRIORITY (rtx_insn *INSN, int 36647 MAX_PRI, int *FUSION_PRI, int *PRI) 36648 This hook is called by scheduling fusion pass. It calculates 36649 fusion priorities for each instruction passed in by parameter. The 36650 priorities are returned via pointer parameters. 36651 36652 INSN is the instruction whose priorities need to be calculated. 36653 MAX_PRI is the maximum priority can be returned in any cases. 36654 FUSION_PRI is the pointer parameter through which INSN's fusion 36655 priority should be calculated and returned. PRI is the pointer 36656 parameter through which INSN's priority should be calculated and 36657 returned. 36658 36659 Same FUSION_PRI should be returned for instructions which should be 36660 scheduled together. Different PRI should be returned for 36661 instructions with same FUSION_PRI. FUSION_PRI is the major sort 36662 key, PRI is the minor sort key. All instructions will be scheduled 36663 according to the two priorities. All priorities calculated should 36664 be between 0 (exclusive) and MAX_PRI (inclusive). To avoid false 36665 dependencies, FUSION_PRI of instructions which need to be scheduled 36666 together should be smaller than FUSION_PRI of irrelevant 36667 instructions. 36668 36669 Given below example: 36670 36671 ldr r10, [r1, 4] 36672 add r4, r4, r10 36673 ldr r15, [r2, 8] 36674 sub r5, r5, r15 36675 ldr r11, [r1, 0] 36676 add r4, r4, r11 36677 ldr r16, [r2, 12] 36678 sub r5, r5, r16 36679 36680 On targets like ARM/AArch64, the two pairs of consecutive loads 36681 should be merged. Since peephole2 pass can't help in this case 36682 unless consecutive loads are actually next to each other in 36683 instruction flow. That's where this scheduling fusion pass works. 36684 This hook calculates priority for each instruction based on its 36685 fustion type, like: 36686 36687 ldr r10, [r1, 4] ; fusion_pri=99, pri=96 36688 add r4, r4, r10 ; fusion_pri=100, pri=100 36689 ldr r15, [r2, 8] ; fusion_pri=98, pri=92 36690 sub r5, r5, r15 ; fusion_pri=100, pri=100 36691 ldr r11, [r1, 0] ; fusion_pri=99, pri=100 36692 add r4, r4, r11 ; fusion_pri=100, pri=100 36693 ldr r16, [r2, 12] ; fusion_pri=98, pri=88 36694 sub r5, r5, r16 ; fusion_pri=100, pri=100 36695 36696 Scheduling fusion pass then sorts all ready to issue instructions 36697 according to the priorities. As a result, instructions of same 36698 fusion type will be pushed together in instruction flow, like: 36699 36700 ldr r11, [r1, 0] 36701 ldr r10, [r1, 4] 36702 ldr r15, [r2, 8] 36703 ldr r16, [r2, 12] 36704 add r4, r4, r10 36705 sub r5, r5, r15 36706 add r4, r4, r11 36707 sub r5, r5, r16 36708 36709 Now peephole2 pass can simply merge the two pairs of loads. 36710 36711 Since scheduling fusion pass relies on peephole2 to do real fusion 36712 work, it is only enabled by default when peephole2 is in effect. 36713 36714 This is firstly introduced on ARM/AArch64 targets, please refer to 36715 the hook implementation for how different fusion types are 36716 supported. 36717 36718 -- Target Hook: void TARGET_EXPAND_DIVMOD_LIBFUNC (rtx LIBFUNC, 36719 machine_mode MODE, rtx OP0, rtx OP1, rtx *QUOT, rtx *REM) 36720 Define this hook for enabling divmod transform if the port does not 36721 have hardware divmod insn but defines target-specific divmod 36722 libfuncs. 36723 36724 36725File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros 36726 3672718.18 Dividing the Output into Sections (Texts, Data, ...) 36728========================================================== 36729 36730An object file is divided into sections containing different types of 36731data. In the most common case, there are three sections: the "text 36732section", which holds instructions and read-only data; the "data 36733section", which holds initialized writable data; and the "bss section", 36734which holds uninitialized data. Some systems have other kinds of 36735sections. 36736 36737 'varasm.c' provides several well-known sections, such as 36738'text_section', 'data_section' and 'bss_section'. The normal way of 36739controlling a 'FOO_section' variable is to define the associated 36740'FOO_SECTION_ASM_OP' macro, as described below. The macros are only 36741read once, when 'varasm.c' initializes itself, so their values must be 36742run-time constants. They may however depend on command-line flags. 36743 36744 _Note:_ Some run-time files, such 'crtstuff.c', also make use of the 36745'FOO_SECTION_ASM_OP' macros, and expect them to be string literals. 36746 36747 Some assemblers require a different string to be written every time a 36748section is selected. If your assembler falls into this category, you 36749should define the 'TARGET_ASM_INIT_SECTIONS' hook and use 36750'get_unnamed_section' to set up the sections. 36751 36752 You must always create a 'text_section', either by defining 36753'TEXT_SECTION_ASM_OP' or by initializing 'text_section' in 36754'TARGET_ASM_INIT_SECTIONS'. The same is true of 'data_section' and 36755'DATA_SECTION_ASM_OP'. If you do not create a distinct 36756'readonly_data_section', the default is to reuse 'text_section'. 36757 36758 All the other 'varasm.c' sections are optional, and are null if the 36759target does not provide them. 36760 36761 -- Macro: TEXT_SECTION_ASM_OP 36762 A C expression whose value is a string, including spacing, 36763 containing the assembler operation that should precede instructions 36764 and read-only data. Normally '"\t.text"' is right. 36765 36766 -- Macro: HOT_TEXT_SECTION_NAME 36767 If defined, a C string constant for the name of the section 36768 containing most frequently executed functions of the program. If 36769 not defined, GCC will provide a default definition if the target 36770 supports named sections. 36771 36772 -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME 36773 If defined, a C string constant for the name of the section 36774 containing unlikely executed functions in the program. 36775 36776 -- Macro: DATA_SECTION_ASM_OP 36777 A C expression whose value is a string, including spacing, 36778 containing the assembler operation to identify the following data 36779 as writable initialized data. Normally '"\t.data"' is right. 36780 36781 -- Macro: SDATA_SECTION_ASM_OP 36782 If defined, a C expression whose value is a string, including 36783 spacing, containing the assembler operation to identify the 36784 following data as initialized, writable small data. 36785 36786 -- Macro: READONLY_DATA_SECTION_ASM_OP 36787 A C expression whose value is a string, including spacing, 36788 containing the assembler operation to identify the following data 36789 as read-only initialized data. 36790 36791 -- Macro: BSS_SECTION_ASM_OP 36792 If defined, a C expression whose value is a string, including 36793 spacing, containing the assembler operation to identify the 36794 following data as uninitialized global data. If not defined, and 36795 'ASM_OUTPUT_ALIGNED_BSS' not defined, uninitialized global data 36796 will be output in the data section if '-fno-common' is passed, 36797 otherwise 'ASM_OUTPUT_COMMON' will be used. 36798 36799 -- Macro: SBSS_SECTION_ASM_OP 36800 If defined, a C expression whose value is a string, including 36801 spacing, containing the assembler operation to identify the 36802 following data as uninitialized, writable small data. 36803 36804 -- Macro: TLS_COMMON_ASM_OP 36805 If defined, a C expression whose value is a string containing the 36806 assembler operation to identify the following data as thread-local 36807 common data. The default is '".tls_common"'. 36808 36809 -- Macro: TLS_SECTION_ASM_FLAG 36810 If defined, a C expression whose value is a character constant 36811 containing the flag used to mark a section as a TLS section. The 36812 default is ''T''. 36813 36814 -- Macro: INIT_SECTION_ASM_OP 36815 If defined, a C expression whose value is a string, including 36816 spacing, containing the assembler operation to identify the 36817 following data as initialization code. If not defined, GCC will 36818 assume such a section does not exist. This section has no 36819 corresponding 'init_section' variable; it is used entirely in 36820 runtime code. 36821 36822 -- Macro: FINI_SECTION_ASM_OP 36823 If defined, a C expression whose value is a string, including 36824 spacing, containing the assembler operation to identify the 36825 following data as finalization code. If not defined, GCC will 36826 assume such a section does not exist. This section has no 36827 corresponding 'fini_section' variable; it is used entirely in 36828 runtime code. 36829 36830 -- Macro: INIT_ARRAY_SECTION_ASM_OP 36831 If defined, a C expression whose value is a string, including 36832 spacing, containing the assembler operation to identify the 36833 following data as part of the '.init_array' (or equivalent) 36834 section. If not defined, GCC will assume such a section does not 36835 exist. Do not define both this macro and 'INIT_SECTION_ASM_OP'. 36836 36837 -- Macro: FINI_ARRAY_SECTION_ASM_OP 36838 If defined, a C expression whose value is a string, including 36839 spacing, containing the assembler operation to identify the 36840 following data as part of the '.fini_array' (or equivalent) 36841 section. If not defined, GCC will assume such a section does not 36842 exist. Do not define both this macro and 'FINI_SECTION_ASM_OP'. 36843 36844 -- Macro: MACH_DEP_SECTION_ASM_FLAG 36845 If defined, a C expression whose value is a character constant 36846 containing the flag used to mark a machine-dependent section. This 36847 corresponds to the 'SECTION_MACH_DEP' section flag. 36848 36849 -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION) 36850 If defined, an ASM statement that switches to a different section 36851 via SECTION_OP, calls FUNCTION, and switches back to the text 36852 section. This is used in 'crtstuff.c' if 'INIT_SECTION_ASM_OP' or 36853 'FINI_SECTION_ASM_OP' to calls to initialization and finalization 36854 functions from the init and fini sections. By default, this macro 36855 uses a simple function call. Some ports need hand-crafted assembly 36856 code to avoid dependencies on registers initialized in the function 36857 prologue or to ensure that constant pools don't end up too far way 36858 in the text section. 36859 36860 -- Macro: TARGET_LIBGCC_SDATA_SECTION 36861 If defined, a string which names the section into which small 36862 variables defined in crtstuff and libgcc should go. This is useful 36863 when the target has options for optimizing access to small data, 36864 and you want the crtstuff and libgcc routines to be conservative in 36865 what they expect of your application yet liberal in what your 36866 application expects. For example, for targets with a '.sdata' 36867 section (like MIPS), you could compile crtstuff with '-G 0' so that 36868 it doesn't require small data support from your application, but 36869 use this macro to put small data into '.sdata' so that your 36870 application can access these variables whether it uses small data 36871 or not. 36872 36873 -- Macro: FORCE_CODE_SECTION_ALIGN 36874 If defined, an ASM statement that aligns a code section to some 36875 arbitrary boundary. This is used to force all fragments of the 36876 '.init' and '.fini' sections to have to same alignment and thus 36877 prevent the linker from having to add any padding. 36878 36879 -- Macro: JUMP_TABLES_IN_TEXT_SECTION 36880 Define this macro to be an expression with a nonzero value if jump 36881 tables (for 'tablejump' insns) should be output in the text 36882 section, along with the assembler instructions. Otherwise, the 36883 readonly data section is used. 36884 36885 This macro is irrelevant if there is no separate readonly data 36886 section. 36887 36888 -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void) 36889 Define this hook if you need to do something special to set up the 36890 'varasm.c' sections, or if your target has some special sections of 36891 its own that you need to create. 36892 36893 GCC calls this hook after processing the command line, but before 36894 writing any assembly code, and before calling any of the 36895 section-returning hooks described below. 36896 36897 -- Target Hook: int TARGET_ASM_RELOC_RW_MASK (void) 36898 Return a mask describing how relocations should be treated when 36899 selecting sections. Bit 1 should be set if global relocations 36900 should be placed in a read-write section; bit 0 should be set if 36901 local relocations should be placed in a read-write section. 36902 36903 The default version of this function returns 3 when '-fpic' is in 36904 effect, and 0 otherwise. The hook is typically redefined when the 36905 target cannot support (some kinds of) dynamic relocations in 36906 read-only sections even in executables. 36907 36908 -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int 36909 RELOC, unsigned HOST_WIDE_INT ALIGN) 36910 Return the section into which EXP should be placed. You can assume 36911 that EXP is either a 'VAR_DECL' node or a constant of some sort. 36912 RELOC indicates whether the initial value of EXP requires link-time 36913 relocations. Bit 0 is set when variable contains local relocations 36914 only, while bit 1 is set for global relocations. ALIGN is the 36915 constant alignment in bits. 36916 36917 The default version of this function takes care of putting 36918 read-only variables in 'readonly_data_section'. 36919 36920 See also USE_SELECT_SECTION_FOR_FUNCTIONS. 36921 36922 -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS 36923 Define this macro if you wish TARGET_ASM_SELECT_SECTION to be 36924 called for 'FUNCTION_DECL's as well as for variables and constants. 36925 36926 In the case of a 'FUNCTION_DECL', RELOC will be zero if the 36927 function has been determined to be likely to be called, and nonzero 36928 if it is unlikely to be called. 36929 36930 -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC) 36931 Build up a unique section name, expressed as a 'STRING_CST' node, 36932 and assign it to 'DECL_SECTION_NAME (DECL)'. As with 36933 'TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial 36934 value of EXP requires link-time relocations. 36935 36936 The default version of this function appends the symbol name to the 36937 ELF section name that would normally be used for the symbol. For 36938 example, the function 'foo' would be placed in '.text.foo'. 36939 Whatever the actual target object format, this is often good 36940 enough. 36941 36942 -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree 36943 DECL) 36944 Return the readonly data section associated with 'DECL_SECTION_NAME 36945 (DECL)'. The default version of this function selects 36946 '.gnu.linkonce.r.name' if the function's section is 36947 '.gnu.linkonce.t.name', '.rodata.name' if function is in 36948 '.text.name', and the normal readonly-data section otherwise. 36949 36950 -- Target Hook: const char * TARGET_ASM_MERGEABLE_RODATA_PREFIX 36951 Usually, the compiler uses the prefix '".rodata"' to construct 36952 section names for mergeable constant data. Define this macro to 36953 override the string if a different section name should be used. 36954 36955 -- Target Hook: section * TARGET_ASM_TM_CLONE_TABLE_SECTION (void) 36956 Return the section that should be used for transactional memory 36957 clone tables. 36958 36959 -- Target Hook: section * TARGET_ASM_SELECT_RTX_SECTION (machine_mode 36960 MODE, rtx X, unsigned HOST_WIDE_INT ALIGN) 36961 Return the section into which a constant X, of mode MODE, should be 36962 placed. You can assume that X is some kind of constant in RTL. 36963 The argument MODE is redundant except in the case of a 'const_int' 36964 rtx. ALIGN is the constant alignment in bits. 36965 36966 The default version of this function takes care of putting symbolic 36967 constants in 'flag_pic' mode in 'data_section' and everything else 36968 in 'readonly_data_section'. 36969 36970 -- Target Hook: tree TARGET_MANGLE_DECL_ASSEMBLER_NAME (tree DECL, tree 36971 ID) 36972 Define this hook if you need to postprocess the assembler name 36973 generated by target-independent code. The ID provided to this hook 36974 will be the computed name (e.g., the macro 'DECL_NAME' of the DECL 36975 in C, or the mangled name of the DECL in C++). The return value of 36976 the hook is an 'IDENTIFIER_NODE' for the appropriate mangled name 36977 on your target system. The default implementation of this hook 36978 just returns the ID provided. 36979 36980 -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL, 36981 int NEW_DECL_P) 36982 Define this hook if references to a symbol or a constant must be 36983 treated differently depending on something about the variable or 36984 function named by the symbol (such as what section it is in). 36985 36986 The hook is executed immediately after rtl has been created for 36987 DECL, which may be a variable or function declaration or an entry 36988 in the constant pool. In either case, RTL is the rtl in question. 36989 Do _not_ use 'DECL_RTL (DECL)' in this hook; that field may not 36990 have been initialized yet. 36991 36992 In the case of a constant, it is safe to assume that the rtl is a 36993 'mem' whose address is a 'symbol_ref'. Most decls will also have 36994 this form, but that is not guaranteed. Global register variables, 36995 for instance, will have a 'reg' for their rtl. (Normally the right 36996 thing to do with such unusual rtl is leave it alone.) 36997 36998 The NEW_DECL_P argument will be true if this is the first time that 36999 'TARGET_ENCODE_SECTION_INFO' has been invoked on this decl. It 37000 will be false for subsequent invocations, which will happen for 37001 duplicate declarations. Whether or not anything must be done for 37002 the duplicate declaration depends on whether the hook examines 37003 'DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is 37004 called for a constant. 37005 37006 The usual thing for this hook to do is to record flags in the 37007 'symbol_ref', using 'SYMBOL_REF_FLAG' or 'SYMBOL_REF_FLAGS'. 37008 Historically, the name string was modified if it was necessary to 37009 encode more than one bit of information, but this practice is now 37010 discouraged; use 'SYMBOL_REF_FLAGS'. 37011 37012 The default definition of this hook, 'default_encode_section_info' 37013 in 'varasm.c', sets a number of commonly-useful bits in 37014 'SYMBOL_REF_FLAGS'. Check whether the default does what you need 37015 before overriding it. 37016 37017 -- Target Hook: const char * TARGET_STRIP_NAME_ENCODING (const char 37018 *NAME) 37019 Decode NAME and return the real name part, sans the characters that 37020 'TARGET_ENCODE_SECTION_INFO' may have added. 37021 37022 -- Target Hook: bool TARGET_IN_SMALL_DATA_P (const_tree EXP) 37023 Returns true if EXP should be placed into a "small data" section. 37024 The default version of this hook always returns false. 37025 37026 -- Target Hook: bool TARGET_HAVE_SRODATA_SECTION 37027 Contains the value true if the target places read-only "small data" 37028 into a separate section. The default value is false. 37029 37030 -- Target Hook: bool TARGET_PROFILE_BEFORE_PROLOGUE (void) 37031 It returns true if target wants profile code emitted before 37032 prologue. 37033 37034 The default version of this hook use the target macro 37035 'PROFILE_BEFORE_PROLOGUE'. 37036 37037 -- Target Hook: bool TARGET_BINDS_LOCAL_P (const_tree EXP) 37038 Returns true if EXP names an object for which name resolution rules 37039 must resolve to the current "module" (dynamic shared library or 37040 executable image). 37041 37042 The default version of this hook implements the name resolution 37043 rules for ELF, which has a looser model of global name binding than 37044 other currently supported object file formats. 37045 37046 -- Target Hook: bool TARGET_HAVE_TLS 37047 Contains the value true if the target supports thread-local 37048 storage. The default value is false. 37049 37050 37051File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros 37052 3705318.19 Position Independent Code 37054=============================== 37055 37056This section describes macros that help implement generation of position 37057independent code. Simply defining these macros is not enough to 37058generate valid PIC; you must also add support to the hook 37059'TARGET_LEGITIMATE_ADDRESS_P' and to the macro 'PRINT_OPERAND_ADDRESS', 37060as well as 'LEGITIMIZE_ADDRESS'. You must modify the definition of 37061'movsi' to do something appropriate when the source operand contains a 37062symbolic address. You may also need to alter the handling of switch 37063statements so that they use relative addresses. 37064 37065 -- Macro: PIC_OFFSET_TABLE_REGNUM 37066 The register number of the register used to address a table of 37067 static data addresses in memory. In some cases this register is 37068 defined by a processor's "application binary interface" (ABI). 37069 When this macro is defined, RTL is generated for this register 37070 once, as with the stack pointer and frame pointer registers. If 37071 this macro is not defined, it is up to the machine-dependent files 37072 to allocate such a register (if necessary). Note that this 37073 register must be fixed when in use (e.g. when 'flag_pic' is true). 37074 37075 -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED 37076 A C expression that is nonzero if the register defined by 37077 'PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. If not defined, 37078 the default is zero. Do not define this macro if 37079 'PIC_OFFSET_TABLE_REGNUM' is not defined. 37080 37081 -- Macro: LEGITIMATE_PIC_OPERAND_P (X) 37082 A C expression that is nonzero if X is a legitimate immediate 37083 operand on the target machine when generating position independent 37084 code. You can assume that X satisfies 'CONSTANT_P', so you need 37085 not check this. You can also assume FLAG_PIC is true, so you need 37086 not check it either. You need not define this macro if all 37087 constants (including 'SYMBOL_REF') can be immediate operands when 37088 generating position independent code. 37089 37090 37091File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros 37092 3709318.20 Defining the Output Assembler Language 37094============================================ 37095 37096This section describes macros whose principal purpose is to describe how 37097to write instructions in assembler language--rather than what the 37098instructions do. 37099 37100* Menu: 37101 37102* File Framework:: Structural information for the assembler file. 37103* Data Output:: Output of constants (numbers, strings, addresses). 37104* Uninitialized Data:: Output of uninitialized variables. 37105* Label Output:: Output and generation of labels. 37106* Initialization:: General principles of initialization 37107 and termination routines. 37108* Macros for Initialization:: 37109 Specific macros that control the handling of 37110 initialization and termination routines. 37111* Instruction Output:: Output of actual instructions. 37112* Dispatch Tables:: Output of jump tables. 37113* Exception Region Output:: Output of exception region code. 37114* Alignment Output:: Pseudo ops for alignment and skipping data. 37115 37116 37117File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format 37118 3711918.20.1 The Overall Framework of an Assembler File 37120-------------------------------------------------- 37121 37122This describes the overall framework of an assembly file. 37123 37124 -- Target Hook: void TARGET_ASM_FILE_START (void) 37125 Output to 'asm_out_file' any text which the assembler expects to 37126 find at the beginning of a file. The default behavior is 37127 controlled by two flags, documented below. Unless your target's 37128 assembler is quite unusual, if you override the default, you should 37129 call 'default_file_start' at some point in your target hook. This 37130 lets other target files rely on these variables. 37131 37132 -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF 37133 If this flag is true, the text of the macro 'ASM_APP_OFF' will be 37134 printed as the very first line in the assembly file, unless 37135 '-fverbose-asm' is in effect. (If that macro has been defined to 37136 the empty string, this variable has no effect.) With the normal 37137 definition of 'ASM_APP_OFF', the effect is to notify the GNU 37138 assembler that it need not bother stripping comments or extra 37139 whitespace from its input. This allows it to work a bit faster. 37140 37141 The default is false. You should not set it to true unless you 37142 have verified that your port does not generate any extra whitespace 37143 or comments that will cause GAS to issue errors in NO_APP mode. 37144 37145 -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE 37146 If this flag is true, 'output_file_directive' will be called for 37147 the primary source file, immediately after printing 'ASM_APP_OFF' 37148 (if that is enabled). Most ELF assemblers expect this to be done. 37149 The default is false. 37150 37151 -- Target Hook: void TARGET_ASM_FILE_END (void) 37152 Output to 'asm_out_file' any text which the assembler expects to 37153 find at the end of a file. The default is to output nothing. 37154 37155 -- Function: void file_end_indicate_exec_stack () 37156 Some systems use a common convention, the '.note.GNU-stack' special 37157 section, to indicate whether or not an object file relies on the 37158 stack being executable. If your system uses this convention, you 37159 should define 'TARGET_ASM_FILE_END' to this function. If you need 37160 to do other things in that hook, have your hook function call this 37161 function. 37162 37163 -- Target Hook: void TARGET_ASM_LTO_START (void) 37164 Output to 'asm_out_file' any text which the assembler expects to 37165 find at the start of an LTO section. The default is to output 37166 nothing. 37167 37168 -- Target Hook: void TARGET_ASM_LTO_END (void) 37169 Output to 'asm_out_file' any text which the assembler expects to 37170 find at the end of an LTO section. The default is to output 37171 nothing. 37172 37173 -- Target Hook: void TARGET_ASM_CODE_END (void) 37174 Output to 'asm_out_file' any text which is needed before emitting 37175 unwind info and debug info at the end of a file. Some targets emit 37176 here PIC setup thunks that cannot be emitted at the end of file, 37177 because they couldn't have unwind info then. The default is to 37178 output nothing. 37179 37180 -- Macro: ASM_COMMENT_START 37181 A C string constant describing how to begin a comment in the target 37182 assembler language. The compiler assumes that the comment will end 37183 at the end of the line. 37184 37185 -- Macro: ASM_APP_ON 37186 A C string constant for text to be output before each 'asm' 37187 statement or group of consecutive ones. Normally this is '"#APP"', 37188 which is a comment that has no effect on most assemblers but tells 37189 the GNU assembler that it must check the lines that follow for all 37190 valid assembler constructs. 37191 37192 -- Macro: ASM_APP_OFF 37193 A C string constant for text to be output after each 'asm' 37194 statement or group of consecutive ones. Normally this is 37195 '"#NO_APP"', which tells the GNU assembler to resume making the 37196 time-saving assumptions that are valid for ordinary compiler 37197 output. 37198 37199 -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME) 37200 A C statement to output COFF information or DWARF debugging 37201 information which indicates that filename NAME is the current 37202 source file to the stdio stream STREAM. 37203 37204 This macro need not be defined if the standard form of output for 37205 the file format in use is appropriate. 37206 37207 -- Target Hook: void TARGET_ASM_OUTPUT_SOURCE_FILENAME (FILE *FILE, 37208 const char *NAME) 37209 Output DWARF debugging information which indicates that filename 37210 NAME is the current source file to the stdio stream FILE. 37211 37212 This target hook need not be defined if the standard form of output 37213 for the file format in use is appropriate. 37214 37215 -- Target Hook: void TARGET_ASM_OUTPUT_IDENT (const char *NAME) 37216 Output a string based on NAME, suitable for the '#ident' directive, 37217 or the equivalent directive or pragma in non-C-family languages. 37218 If this hook is not defined, nothing is output for the '#ident' 37219 directive. 37220 37221 -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING) 37222 A C statement to output the string STRING to the stdio stream 37223 STREAM. If you do not call the function 'output_quoted_string' in 37224 your config files, GCC will only call it to output filenames to the 37225 assembler source. So you can use it to canonicalize the format of 37226 the filename using this macro. 37227 37228 -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME, 37229 unsigned int FLAGS, tree DECL) 37230 Output assembly directives to switch to section NAME. The section 37231 should have attributes as specified by FLAGS, which is a bit mask 37232 of the 'SECTION_*' flags defined in 'output.h'. If DECL is 37233 non-NULL, it is the 'VAR_DECL' or 'FUNCTION_DECL' with which this 37234 section is associated. 37235 37236 -- Target Hook: bool TARGET_ASM_ELF_FLAGS_NUMERIC (unsigned int FLAGS, 37237 unsigned int *NUM) 37238 This hook can be used to encode ELF section flags for which no 37239 letter code has been defined in the assembler. It is called by 37240 'default_asm_named_section' whenever the section flags need to be 37241 emitted in the assembler output. If the hook returns true, then 37242 the numerical value for ELF section flags should be calculated from 37243 FLAGS and saved in *NUM; the value is printed out instead of the 37244 normal sequence of letter codes. If the hook is not defined, or if 37245 it returns false, then NUM is ignored and the traditional letter 37246 sequence is emitted. 37247 37248 -- Target Hook: section * TARGET_ASM_FUNCTION_SECTION (tree DECL, enum 37249 node_frequency FREQ, bool STARTUP, bool EXIT) 37250 Return preferred text (sub)section for function DECL. Main purpose 37251 of this function is to separate cold, normal and hot functions. 37252 STARTUP is true when function is known to be used only at startup 37253 (from static constructors or it is 'main()'). EXIT is true when 37254 function is known to be used only at exit (from static 37255 destructors). Return NULL if function should go to default text 37256 section. 37257 37258 -- Target Hook: void TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS (FILE 37259 *FILE, tree DECL, bool NEW_IS_COLD) 37260 Used by the target to emit any assembler directives or additional 37261 labels needed when a function is partitioned between different 37262 sections. Output should be written to FILE. The function decl is 37263 available as DECL and the new section is 'cold' if NEW_IS_COLD is 37264 'true'. 37265 37266 -- Common Target Hook: bool TARGET_HAVE_NAMED_SECTIONS 37267 This flag is true if the target supports 37268 'TARGET_ASM_NAMED_SECTION'. It must not be modified by 37269 command-line option processing. 37270 37271 -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS 37272 This flag is true if we can create zeroed data by switching to a 37273 BSS section and then using 'ASM_OUTPUT_SKIP' to allocate the space. 37274 This is true on most ELF targets. 37275 37276 -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL, 37277 const char *NAME, int RELOC) 37278 Choose a set of section attributes for use by 37279 'TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a 37280 section name, and whether or not the declaration's initializer may 37281 contain runtime relocations. DECL may be null, in which case 37282 read-write data should be assumed. 37283 37284 The default version of this function handles choosing code vs data, 37285 read-only vs read-write data, and 'flag_pic'. You should only need 37286 to override this if your target has special flags that might be set 37287 via '__attribute__'. 37288 37289 -- Target Hook: int TARGET_ASM_RECORD_GCC_SWITCHES (print_switch_type 37290 TYPE, const char *TEXT) 37291 Provides the target with the ability to record the gcc command line 37292 switches that have been passed to the compiler, and options that 37293 are enabled. The TYPE argument specifies what is being recorded. 37294 It can take the following values: 37295 37296 'SWITCH_TYPE_PASSED' 37297 TEXT is a command line switch that has been set by the user. 37298 37299 'SWITCH_TYPE_ENABLED' 37300 TEXT is an option which has been enabled. This might be as a 37301 direct result of a command line switch, or because it is 37302 enabled by default or because it has been enabled as a side 37303 effect of a different command line switch. For example, the 37304 '-O2' switch enables various different individual optimization 37305 passes. 37306 37307 'SWITCH_TYPE_DESCRIPTIVE' 37308 TEXT is either NULL or some descriptive text which should be 37309 ignored. If TEXT is NULL then it is being used to warn the 37310 target hook that either recording is starting or ending. The 37311 first time TYPE is SWITCH_TYPE_DESCRIPTIVE and TEXT is NULL, 37312 the warning is for start up and the second time the warning is 37313 for wind down. This feature is to allow the target hook to 37314 make any necessary preparations before it starts to record 37315 switches and to perform any necessary tidying up after it has 37316 finished recording switches. 37317 37318 'SWITCH_TYPE_LINE_START' 37319 This option can be ignored by this target hook. 37320 37321 'SWITCH_TYPE_LINE_END' 37322 This option can be ignored by this target hook. 37323 37324 The hook's return value must be zero. Other return values may be 37325 supported in the future. 37326 37327 By default this hook is set to NULL, but an example implementation 37328 is provided for ELF based targets. Called ELF_RECORD_GCC_SWITCHES, 37329 it records the switches as ASCII text inside a new, string 37330 mergeable section in the assembler output file. The name of the 37331 new section is provided by the 37332 'TARGET_ASM_RECORD_GCC_SWITCHES_SECTION' target hook. 37333 37334 -- Target Hook: const char * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION 37335 This is the name of the section that will be created by the example 37336 ELF implementation of the 'TARGET_ASM_RECORD_GCC_SWITCHES' target 37337 hook. 37338 37339 37340File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format 37341 3734218.20.2 Output of Data 37343---------------------- 37344 37345 -- Target Hook: const char * TARGET_ASM_BYTE_OP 37346 -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP 37347 -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP 37348 -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP 37349 -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP 37350 -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP 37351 -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP 37352 -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP 37353 -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP 37354 These hooks specify assembly directives for creating certain kinds 37355 of integer object. The 'TARGET_ASM_BYTE_OP' directive creates a 37356 byte-sized object, the 'TARGET_ASM_ALIGNED_HI_OP' one creates an 37357 aligned two-byte object, and so on. Any of the hooks may be 37358 'NULL', indicating that no suitable directive is available. 37359 37360 The compiler will print these strings at the start of a new line, 37361 followed immediately by the object's initial value. In most cases, 37362 the string should contain a tab, a pseudo-op, and then another tab. 37363 37364 -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int 37365 ALIGNED_P) 37366 The 'assemble_integer' function uses this hook to output an integer 37367 object. X is the object's value, SIZE is its size in bytes and 37368 ALIGNED_P indicates whether it is aligned. The function should 37369 return 'true' if it was able to output the object. If it returns 37370 false, 'assemble_integer' will try to split the object into smaller 37371 parts. 37372 37373 The default implementation of this hook will use the 37374 'TARGET_ASM_BYTE_OP' family of strings, returning 'false' when the 37375 relevant string is 'NULL'. 37376 37377 -- Target Hook: void TARGET_ASM_DECL_END (void) 37378 Define this hook if the target assembler requires a special marker 37379 to terminate an initialized variable declaration. 37380 37381 -- Target Hook: bool TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA (FILE *FILE, 37382 rtx X) 37383 A target hook to recognize RTX patterns that 'output_addr_const' 37384 can't deal with, and output assembly code to FILE corresponding to 37385 the pattern X. This may be used to allow machine-dependent 37386 'UNSPEC's to appear within constants. 37387 37388 If target hook fails to recognize a pattern, it must return 37389 'false', so that a standard error message is printed. If it prints 37390 an error message itself, by calling, for example, 37391 'output_operand_lossage', it may just return 'true'. 37392 37393 -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN) 37394 A C statement to output to the stdio stream STREAM an assembler 37395 instruction to assemble a string constant containing the LEN bytes 37396 at PTR. PTR will be a C expression of type 'char *' and LEN a C 37397 expression of type 'int'. 37398 37399 If the assembler has a '.ascii' pseudo-op as found in the Berkeley 37400 Unix assembler, do not define the macro 'ASM_OUTPUT_ASCII'. 37401 37402 -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N) 37403 A C statement to output word N of a function descriptor for DECL. 37404 This must be defined if 'TARGET_VTABLE_USES_DESCRIPTORS' is 37405 defined, and is otherwise unused. 37406 37407 -- Macro: CONSTANT_POOL_BEFORE_FUNCTION 37408 You may define this macro as a C expression. You should define the 37409 expression to have a nonzero value if GCC should output the 37410 constant pool for a function before the code for the function, or a 37411 zero value if GCC should output the constant pool after the 37412 function. If you do not define this macro, the usual case, GCC 37413 will output the constant pool before the function. 37414 37415 -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE) 37416 A C statement to output assembler commands to define the start of 37417 the constant pool for a function. FUNNAME is a string giving the 37418 name of the function. Should the return type of the function be 37419 required, it can be obtained via FUNDECL. SIZE is the size, in 37420 bytes, of the constant pool that will be written immediately after 37421 this call. 37422 37423 If no constant-pool prefix is required, the usual case, this macro 37424 need not be defined. 37425 37426 -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, LABELNO, 37427 JUMPTO) 37428 A C statement (with or without semicolon) to output a constant in 37429 the constant pool, if it needs special treatment. (This macro need 37430 not do anything for RTL expressions that can be output normally.) 37431 37432 The argument FILE is the standard I/O stream to output the 37433 assembler code on. X is the RTL expression for the constant to 37434 output, and MODE is the machine mode (in case X is a 'const_int'). 37435 ALIGN is the required alignment for the value X; you should output 37436 an assembler directive to force this much alignment. 37437 37438 The argument LABELNO is a number to use in an internal label for 37439 the address of this pool entry. The definition of this macro is 37440 responsible for outputting the label definition at the proper 37441 place. Here is how to do this: 37442 37443 (*targetm.asm_out.internal_label) (FILE, "LC", LABELNO); 37444 37445 When you output a pool entry specially, you should end with a 37446 'goto' to the label JUMPTO. This will prevent the same pool entry 37447 from being output a second time in the usual manner. 37448 37449 You need not define this macro if it would do nothing. 37450 37451 -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE) 37452 A C statement to output assembler commands to at the end of the 37453 constant pool for a function. FUNNAME is a string giving the name 37454 of the function. Should the return type of the function be 37455 required, you can obtain it via FUNDECL. SIZE is the size, in 37456 bytes, of the constant pool that GCC wrote immediately before this 37457 call. 37458 37459 If no constant-pool epilogue is required, the usual case, you need 37460 not define this macro. 37461 37462 -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C, STR) 37463 Define this macro as a C expression which is nonzero if C is used 37464 as a logical line separator by the assembler. STR points to the 37465 position in the string where C was found; this can be used if a 37466 line separator uses multiple characters. 37467 37468 If you do not define this macro, the default is that only the 37469 character ';' is treated as a logical line separator. 37470 37471 -- Target Hook: const char * TARGET_ASM_OPEN_PAREN 37472 -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN 37473 These target hooks are C string constants, describing the syntax in 37474 the assembler for grouping arithmetic expressions. If not 37475 overridden, they default to normal parentheses, which is correct 37476 for most assemblers. 37477 37478 These macros are provided by 'real.h' for writing the definitions of 37479'ASM_OUTPUT_DOUBLE' and the like: 37480 37481 -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L) 37482 -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L) 37483 -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L) 37484 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L) 37485 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L) 37486 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L) 37487 These translate X, of type 'REAL_VALUE_TYPE', to the target's 37488 floating point representation, and store its bit pattern in the 37489 variable L. For 'REAL_VALUE_TO_TARGET_SINGLE' and 37490 'REAL_VALUE_TO_TARGET_DECIMAL32', this variable should be a simple 37491 'long int'. For the others, it should be an array of 'long int'. 37492 The number of elements in this array is determined by the size of 37493 the desired target floating point data type: 32 bits of it go in 37494 each 'long int' array element. Each array element holds 32 bits of 37495 the result, even if 'long int' is wider than 32 bits on the host 37496 machine. 37497 37498 The array element values are designed so that you can print them 37499 out using 'fprintf' in the order they should appear in the target 37500 machine's memory. 37501 37502 37503File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format 37504 3750518.20.3 Output of Uninitialized Variables 37506----------------------------------------- 37507 37508Each of the macros in this section is used to do the whole job of 37509outputting a single uninitialized variable. 37510 37511 -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED) 37512 A C statement (sans semicolon) to output to the stdio stream STREAM 37513 the assembler definition of a common-label named NAME whose size is 37514 SIZE bytes. The variable ROUNDED is the size rounded up to 37515 whatever alignment the caller wants. It is possible that SIZE may 37516 be zero, for instance if a struct with no other member than a 37517 zero-length array is defined. In this case, the backend must 37518 output a symbol definition that allocates at least one byte, both 37519 so that the address of the resulting object does not compare equal 37520 to any other, and because some object formats cannot even express 37521 the concept of a zero-sized common symbol, as that is how they 37522 represent an ordinary undefined external. 37523 37524 Use the expression 'assemble_name (STREAM, NAME)' to output the 37525 name itself; before and after that, output the additional assembler 37526 syntax for defining the name, and a newline. 37527 37528 This macro controls how the assembler definitions of uninitialized 37529 common global variables are output. 37530 37531 -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT) 37532 Like 'ASM_OUTPUT_COMMON' except takes the required alignment as a 37533 separate, explicit argument. If you define this macro, it is used 37534 in place of 'ASM_OUTPUT_COMMON', and gives you more flexibility in 37535 handling the required alignment of the variable. The alignment is 37536 specified as the number of bits. 37537 37538 -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE, 37539 ALIGNMENT) 37540 Like 'ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable 37541 to be output, if there is one, or 'NULL_TREE' if there is no 37542 corresponding variable. If you define this macro, GCC will use it 37543 in place of both 'ASM_OUTPUT_COMMON' and 37544 'ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to 37545 see the variable's decl in order to chose what to output. 37546 37547 -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT) 37548 A C statement (sans semicolon) to output to the stdio stream STREAM 37549 the assembler definition of uninitialized global DECL named NAME 37550 whose size is SIZE bytes. The variable ALIGNMENT is the alignment 37551 specified as the number of bits. 37552 37553 Try to use function 'asm_output_aligned_bss' defined in file 37554 'varasm.c' when defining this macro. If unable, use the expression 37555 'assemble_name (STREAM, NAME)' to output the name itself; before 37556 and after that, output the additional assembler syntax for defining 37557 the name, and a newline. 37558 37559 There are two ways of handling global BSS. One is to define this 37560 macro. The other is to have 'TARGET_ASM_SELECT_SECTION' return a 37561 switchable BSS section (*note 37562 TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::). You do not need to do 37563 both. 37564 37565 Some languages do not have 'common' data, and require a non-common 37566 form of global BSS in order to handle uninitialized globals 37567 efficiently. C++ is one example of this. However, if the target 37568 does not support global BSS, the front end may choose to make 37569 globals common in order to save space in the object file. 37570 37571 -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED) 37572 A C statement (sans semicolon) to output to the stdio stream STREAM 37573 the assembler definition of a local-common-label named NAME whose 37574 size is SIZE bytes. The variable ROUNDED is the size rounded up to 37575 whatever alignment the caller wants. 37576 37577 Use the expression 'assemble_name (STREAM, NAME)' to output the 37578 name itself; before and after that, output the additional assembler 37579 syntax for defining the name, and a newline. 37580 37581 This macro controls how the assembler definitions of uninitialized 37582 static variables are output. 37583 37584 -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT) 37585 Like 'ASM_OUTPUT_LOCAL' except takes the required alignment as a 37586 separate, explicit argument. If you define this macro, it is used 37587 in place of 'ASM_OUTPUT_LOCAL', and gives you more flexibility in 37588 handling the required alignment of the variable. The alignment is 37589 specified as the number of bits. 37590 37591 -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE, 37592 ALIGNMENT) 37593 Like 'ASM_OUTPUT_ALIGNED_LOCAL' except that DECL of the variable to 37594 be output, if there is one, or 'NULL_TREE' if there is no 37595 corresponding variable. If you define this macro, GCC will use it 37596 in place of both 'ASM_OUTPUT_LOCAL' and 'ASM_OUTPUT_ALIGNED_LOCAL'. 37597 Define this macro when you need to see the variable's decl in order 37598 to chose what to output. 37599 37600 37601File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format 37602 3760318.20.4 Output and Generation of Labels 37604--------------------------------------- 37605 37606This is about outputting labels. 37607 37608 -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME) 37609 A C statement (sans semicolon) to output to the stdio stream STREAM 37610 the assembler definition of a label named NAME. Use the expression 37611 'assemble_name (STREAM, NAME)' to output the name itself; before 37612 and after that, output the additional assembler syntax for defining 37613 the name, and a newline. A default definition of this macro is 37614 provided which is correct for most systems. 37615 37616 -- Macro: ASM_OUTPUT_FUNCTION_LABEL (STREAM, NAME, DECL) 37617 A C statement (sans semicolon) to output to the stdio stream STREAM 37618 the assembler definition of a label named NAME of a function. Use 37619 the expression 'assemble_name (STREAM, NAME)' to output the name 37620 itself; before and after that, output the additional assembler 37621 syntax for defining the name, and a newline. A default definition 37622 of this macro is provided which is correct for most systems. 37623 37624 If this macro is not defined, then the function name is defined in 37625 the usual manner as a label (by means of 'ASM_OUTPUT_LABEL'). 37626 37627 -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME) 37628 Identical to 'ASM_OUTPUT_LABEL', except that NAME is known to refer 37629 to a compiler-generated label. The default definition uses 37630 'assemble_name_raw', which is like 'assemble_name' except that it 37631 is more efficient. 37632 37633 -- Macro: SIZE_ASM_OP 37634 A C string containing the appropriate assembler directive to 37635 specify the size of a symbol, without any arguments. On systems 37636 that use ELF, the default (in 'config/elfos.h') is '"\t.size\t"'; 37637 on other systems, the default is not to define this macro. 37638 37639 Define this macro only if it is correct to use the default 37640 definitions of 'ASM_OUTPUT_SIZE_DIRECTIVE' and 37641 'ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own 37642 custom definitions of those macros, or if you do not need explicit 37643 symbol sizes at all, do not define this macro. 37644 37645 -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE) 37646 A C statement (sans semicolon) to output to the stdio stream STREAM 37647 a directive telling the assembler that the size of the symbol NAME 37648 is SIZE. SIZE is a 'HOST_WIDE_INT'. If you define 'SIZE_ASM_OP', 37649 a default definition of this macro is provided. 37650 37651 -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME) 37652 A C statement (sans semicolon) to output to the stdio stream STREAM 37653 a directive telling the assembler to calculate the size of the 37654 symbol NAME by subtracting its address from the current address. 37655 37656 If you define 'SIZE_ASM_OP', a default definition of this macro is 37657 provided. The default assumes that the assembler recognizes a 37658 special '.' symbol as referring to the current address, and can 37659 calculate the difference between this and another symbol. If your 37660 assembler does not recognize '.' or cannot do calculations with it, 37661 you will need to redefine 'ASM_OUTPUT_MEASURED_SIZE' to use some 37662 other technique. 37663 37664 -- Macro: NO_DOLLAR_IN_LABEL 37665 Define this macro if the assembler does not accept the character 37666 '$' in label names. By default constructors and destructors in G++ 37667 have '$' in the identifiers. If this macro is defined, '.' is used 37668 instead. 37669 37670 -- Macro: NO_DOT_IN_LABEL 37671 Define this macro if the assembler does not accept the character 37672 '.' in label names. By default constructors and destructors in G++ 37673 have names that use '.'. If this macro is defined, these names are 37674 rewritten to avoid '.'. 37675 37676 -- Macro: TYPE_ASM_OP 37677 A C string containing the appropriate assembler directive to 37678 specify the type of a symbol, without any arguments. On systems 37679 that use ELF, the default (in 'config/elfos.h') is '"\t.type\t"'; 37680 on other systems, the default is not to define this macro. 37681 37682 Define this macro only if it is correct to use the default 37683 definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 37684 need your own custom definition of this macro, or if you do not 37685 need explicit symbol types at all, do not define this macro. 37686 37687 -- Macro: TYPE_OPERAND_FMT 37688 A C string which specifies (using 'printf' syntax) the format of 37689 the second operand to 'TYPE_ASM_OP'. On systems that use ELF, the 37690 default (in 'config/elfos.h') is '"@%s"'; on other systems, the 37691 default is not to define this macro. 37692 37693 Define this macro only if it is correct to use the default 37694 definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 37695 need your own custom definition of this macro, or if you do not 37696 need explicit symbol types at all, do not define this macro. 37697 37698 -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE) 37699 A C statement (sans semicolon) to output to the stdio stream STREAM 37700 a directive telling the assembler that the type of the symbol NAME 37701 is TYPE. TYPE is a C string; currently, that string is always 37702 either '"function"' or '"object"', but you should not count on 37703 this. 37704 37705 If you define 'TYPE_ASM_OP' and 'TYPE_OPERAND_FMT', a default 37706 definition of this macro is provided. 37707 37708 -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL) 37709 A C statement (sans semicolon) to output to the stdio stream STREAM 37710 any text necessary for declaring the name NAME of a function which 37711 is being defined. This macro is responsible for outputting the 37712 label definition (perhaps using 'ASM_OUTPUT_FUNCTION_LABEL'). The 37713 argument DECL is the 'FUNCTION_DECL' tree node representing the 37714 function. 37715 37716 If this macro is not defined, then the function name is defined in 37717 the usual manner as a label (by means of 37718 'ASM_OUTPUT_FUNCTION_LABEL'). 37719 37720 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 37721 of this macro. 37722 37723 -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL) 37724 A C statement (sans semicolon) to output to the stdio stream STREAM 37725 any text necessary for declaring the size of a function which is 37726 being defined. The argument NAME is the name of the function. The 37727 argument DECL is the 'FUNCTION_DECL' tree node representing the 37728 function. 37729 37730 If this macro is not defined, then the function size is not 37731 defined. 37732 37733 You may wish to use 'ASM_OUTPUT_MEASURED_SIZE' in the definition of 37734 this macro. 37735 37736 -- Macro: ASM_DECLARE_COLD_FUNCTION_NAME (STREAM, NAME, DECL) 37737 A C statement (sans semicolon) to output to the stdio stream STREAM 37738 any text necessary for declaring the name NAME of a cold function 37739 partition which is being defined. This macro is responsible for 37740 outputting the label definition (perhaps using 37741 'ASM_OUTPUT_FUNCTION_LABEL'). The argument DECL is the 37742 'FUNCTION_DECL' tree node representing the function. 37743 37744 If this macro is not defined, then the cold partition name is 37745 defined in the usual manner as a label (by means of 37746 'ASM_OUTPUT_LABEL'). 37747 37748 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 37749 of this macro. 37750 37751 -- Macro: ASM_DECLARE_COLD_FUNCTION_SIZE (STREAM, NAME, DECL) 37752 A C statement (sans semicolon) to output to the stdio stream STREAM 37753 any text necessary for declaring the size of a cold function 37754 partition which is being defined. The argument NAME is the name of 37755 the cold partition of the function. The argument DECL is the 37756 'FUNCTION_DECL' tree node representing the function. 37757 37758 If this macro is not defined, then the partition size is not 37759 defined. 37760 37761 You may wish to use 'ASM_OUTPUT_MEASURED_SIZE' in the definition of 37762 this macro. 37763 37764 -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL) 37765 A C statement (sans semicolon) to output to the stdio stream STREAM 37766 any text necessary for declaring the name NAME of an initialized 37767 variable which is being defined. This macro must output the label 37768 definition (perhaps using 'ASM_OUTPUT_LABEL'). The argument DECL 37769 is the 'VAR_DECL' tree node representing the variable. 37770 37771 If this macro is not defined, then the variable name is defined in 37772 the usual manner as a label (by means of 'ASM_OUTPUT_LABEL'). 37773 37774 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' and/or 37775 'ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro. 37776 37777 -- Target Hook: void TARGET_ASM_DECLARE_CONSTANT_NAME (FILE *FILE, 37778 const char *NAME, const_tree EXPR, HOST_WIDE_INT SIZE) 37779 A target hook to output to the stdio stream FILE any text necessary 37780 for declaring the name NAME of a constant which is being defined. 37781 This target hook is responsible for outputting the label definition 37782 (perhaps using 'assemble_label'). The argument EXP is the value of 37783 the constant, and SIZE is the size of the constant in bytes. The 37784 NAME will be an internal label. 37785 37786 The default version of this target hook, define the NAME in the 37787 usual manner as a label (by means of 'assemble_label'). 37788 37789 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in this target 37790 hook. 37791 37792 -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME) 37793 A C statement (sans semicolon) to output to the stdio stream STREAM 37794 any text necessary for claiming a register REGNO for a global 37795 variable DECL with name NAME. 37796 37797 If you don't define this macro, that is equivalent to defining it 37798 to do nothing. 37799 37800 -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND) 37801 A C statement (sans semicolon) to finish up declaring a variable 37802 name once the compiler has processed its initializer fully and thus 37803 has had a chance to determine the size of an array when controlled 37804 by an initializer. This is used on systems where it's necessary to 37805 declare something about the size of the object. 37806 37807 If you don't define this macro, that is equivalent to defining it 37808 to do nothing. 37809 37810 You may wish to use 'ASM_OUTPUT_SIZE_DIRECTIVE' and/or 37811 'ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro. 37812 37813 -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const 37814 char *NAME) 37815 This target hook is a function to output to the stdio stream STREAM 37816 some commands that will make the label NAME global; that is, 37817 available for reference from other files. 37818 37819 The default implementation relies on a proper definition of 37820 'GLOBAL_ASM_OP'. 37821 37822 -- Target Hook: void TARGET_ASM_GLOBALIZE_DECL_NAME (FILE *STREAM, tree 37823 DECL) 37824 This target hook is a function to output to the stdio stream STREAM 37825 some commands that will make the name associated with DECL global; 37826 that is, available for reference from other files. 37827 37828 The default implementation uses the TARGET_ASM_GLOBALIZE_LABEL 37829 target hook. 37830 37831 -- Target Hook: void TARGET_ASM_ASSEMBLE_UNDEFINED_DECL (FILE *STREAM, 37832 const char *NAME, const_tree DECL) 37833 This target hook is a function to output to the stdio stream STREAM 37834 some commands that will declare the name associated with DECL which 37835 is not defined in the current translation unit. Most assemblers do 37836 not require anything to be output in this case. 37837 37838 -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME) 37839 A C statement (sans semicolon) to output to the stdio stream STREAM 37840 some commands that will make the label NAME weak; that is, 37841 available for reference from other files but only used if no other 37842 definition is available. Use the expression 'assemble_name 37843 (STREAM, NAME)' to output the name itself; before and after that, 37844 output the additional assembler syntax for making that name weak, 37845 and a newline. 37846 37847 If you don't define this macro or 'ASM_WEAKEN_DECL', GCC will not 37848 support weak symbols and you should not define the 'SUPPORTS_WEAK' 37849 macro. 37850 37851 -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE) 37852 Combines (and replaces) the function of 'ASM_WEAKEN_LABEL' and 37853 'ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function 37854 or variable decl. If VALUE is not 'NULL', this C statement should 37855 output to the stdio stream STREAM assembler code which defines 37856 (equates) the weak symbol NAME to have the value VALUE. If VALUE 37857 is 'NULL', it should output commands to make NAME weak. 37858 37859 -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE) 37860 Outputs a directive that enables NAME to be used to refer to symbol 37861 VALUE with weak-symbol semantics. 'decl' is the declaration of 37862 'name'. 37863 37864 -- Macro: SUPPORTS_WEAK 37865 A preprocessor constant expression which evaluates to true if the 37866 target supports weak symbols. 37867 37868 If you don't define this macro, 'defaults.h' provides a default 37869 definition. If either 'ASM_WEAKEN_LABEL' or 'ASM_WEAKEN_DECL' is 37870 defined, the default definition is '1'; otherwise, it is '0'. 37871 37872 -- Macro: TARGET_SUPPORTS_WEAK 37873 A C expression which evaluates to true if the target supports weak 37874 symbols. 37875 37876 If you don't define this macro, 'defaults.h' provides a default 37877 definition. The default definition is '(SUPPORTS_WEAK)'. Define 37878 this macro if you want to control weak symbol support with a 37879 compiler flag such as '-melf'. 37880 37881 -- Macro: MAKE_DECL_ONE_ONLY (DECL) 37882 A C statement (sans semicolon) to mark DECL to be emitted as a 37883 public symbol such that extra copies in multiple translation units 37884 will be discarded by the linker. Define this macro if your object 37885 file format provides support for this concept, such as the 'COMDAT' 37886 section flags in the Microsoft Windows PE/COFF format, and this 37887 support requires changes to DECL, such as putting it in a separate 37888 section. 37889 37890 -- Macro: SUPPORTS_ONE_ONLY 37891 A C expression which evaluates to true if the target supports 37892 one-only semantics. 37893 37894 If you don't define this macro, 'varasm.c' provides a default 37895 definition. If 'MAKE_DECL_ONE_ONLY' is defined, the default 37896 definition is '1'; otherwise, it is '0'. Define this macro if you 37897 want to control one-only symbol support with a compiler flag, or if 37898 setting the 'DECL_ONE_ONLY' flag is enough to mark a declaration to 37899 be emitted as one-only. 37900 37901 -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, int 37902 VISIBILITY) 37903 This target hook is a function to output to ASM_OUT_FILE some 37904 commands that will make the symbol(s) associated with DECL have 37905 hidden, protected or internal visibility as specified by 37906 VISIBILITY. 37907 37908 -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC 37909 A C expression that evaluates to true if the target's linker 37910 expects that weak symbols do not appear in a static archive's table 37911 of contents. The default is '0'. 37912 37913 Leaving weak symbols out of an archive's table of contents means 37914 that, if a symbol will only have a definition in one translation 37915 unit and will have undefined references from other translation 37916 units, that symbol should not be weak. Defining this macro to be 37917 nonzero will thus have the effect that certain symbols that would 37918 normally be weak (explicit template instantiations, and vtables for 37919 polymorphic classes with noninline key methods) will instead be 37920 nonweak. 37921 37922 The C++ ABI requires this macro to be zero. Define this macro for 37923 targets where full C++ ABI compliance is impossible and where 37924 linker restrictions require weak symbols to be left out of a static 37925 archive's table of contents. 37926 37927 -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME) 37928 A C statement (sans semicolon) to output to the stdio stream STREAM 37929 any text necessary for declaring the name of an external symbol 37930 named NAME which is referenced in this compilation but not defined. 37931 The value of DECL is the tree node for the declaration. 37932 37933 This macro need not be defined if it does not need to output 37934 anything. The GNU assembler and most Unix assemblers don't require 37935 anything. 37936 37937 -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF) 37938 This target hook is a function to output to ASM_OUT_FILE an 37939 assembler pseudo-op to declare a library function name external. 37940 The name of the library function is given by SYMREF, which is a 37941 'symbol_ref'. 37942 37943 -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (const char 37944 *SYMBOL) 37945 This target hook is a function to output to ASM_OUT_FILE an 37946 assembler directive to annotate SYMBOL as used. The Darwin target 37947 uses the .no_dead_code_strip directive. 37948 37949 -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME) 37950 A C statement (sans semicolon) to output to the stdio stream STREAM 37951 a reference in assembler syntax to a label named NAME. This should 37952 add '_' to the front of the name, if that is customary on your 37953 operating system, as it is in most Berkeley Unix systems. This 37954 macro is used in 'assemble_name'. 37955 37956 -- Target Hook: tree TARGET_MANGLE_ASSEMBLER_NAME (const char *NAME) 37957 Given a symbol NAME, perform same mangling as 'varasm.c''s 37958 'assemble_name', but in memory rather than to a file stream, 37959 returning result as an 'IDENTIFIER_NODE'. Required for correct LTO 37960 symtabs. The default implementation calls the 37961 'TARGET_STRIP_NAME_ENCODING' hook and then prepends the 37962 'USER_LABEL_PREFIX', if any. 37963 37964 -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM) 37965 A C statement (sans semicolon) to output a reference to 37966 'SYMBOL_REF' SYM. If not defined, 'assemble_name' will be used to 37967 output the name of the symbol. This macro may be used to modify 37968 the way a symbol is referenced depending on information encoded by 37969 'TARGET_ENCODE_SECTION_INFO'. 37970 37971 -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF) 37972 A C statement (sans semicolon) to output a reference to BUF, the 37973 result of 'ASM_GENERATE_INTERNAL_LABEL'. If not defined, 37974 'assemble_name' will be used to output the name of the symbol. 37975 This macro is not used by 'output_asm_label', or the '%l' specifier 37976 that calls it; the intention is that this macro should be set when 37977 it is necessary to output a label differently when its address is 37978 being taken. 37979 37980 -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const 37981 char *PREFIX, unsigned long LABELNO) 37982 A function to output to the stdio stream STREAM a label whose name 37983 is made from the string PREFIX and the number LABELNO. 37984 37985 It is absolutely essential that these labels be distinct from the 37986 labels used for user-level functions and variables. Otherwise, 37987 certain programs will have name conflicts with internal labels. 37988 37989 It is desirable to exclude internal labels from the symbol table of 37990 the object file. Most assemblers have a naming convention for 37991 labels that should be excluded; on many systems, the letter 'L' at 37992 the beginning of a label has this effect. You should find out what 37993 convention your system uses, and follow it. 37994 37995 The default version of this function utilizes 37996 'ASM_GENERATE_INTERNAL_LABEL'. 37997 37998 -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM) 37999 A C statement to output to the stdio stream STREAM a debug info 38000 label whose name is made from the string PREFIX and the number NUM. 38001 This is useful for VLIW targets, where debug info labels may need 38002 to be treated differently than branch target labels. On some 38003 systems, branch target labels must be at the beginning of 38004 instruction bundles, but debug info labels can occur in the middle 38005 of instruction bundles. 38006 38007 If this macro is not defined, then 38008 '(*targetm.asm_out.internal_label)' will be used. 38009 38010 -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM) 38011 A C statement to store into the string STRING a label whose name is 38012 made from the string PREFIX and the number NUM. 38013 38014 This string, when output subsequently by 'assemble_name', should 38015 produce the output that '(*targetm.asm_out.internal_label)' would 38016 produce with the same PREFIX and NUM. 38017 38018 If the string begins with '*', then 'assemble_name' will output the 38019 rest of the string unchanged. It is often convenient for 38020 'ASM_GENERATE_INTERNAL_LABEL' to use '*' in this way. If the 38021 string doesn't start with '*', then 'ASM_OUTPUT_LABELREF' gets to 38022 output the string, and may change it. (Of course, 38023 'ASM_OUTPUT_LABELREF' is also part of your machine description, so 38024 you should know what it does on your machine.) 38025 38026 -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER) 38027 A C expression to assign to OUTVAR (which is a variable of type 38028 'char *') a newly allocated string made from the string NAME and 38029 the number NUMBER, with some suitable punctuation added. Use 38030 'alloca' to get space for the string. 38031 38032 The string will be used as an argument to 'ASM_OUTPUT_LABELREF' to 38033 produce an assembler label for an internal static variable whose 38034 name is NAME. Therefore, the string must be such as to result in 38035 valid assembler code. The argument NUMBER is different each time 38036 this macro is executed; it prevents conflicts between 38037 similarly-named internal static variables in different scopes. 38038 38039 Ideally this string should not be a valid C identifier, to prevent 38040 any conflict with the user's own symbols. Most assemblers allow 38041 periods or percent signs in assembler symbols; putting at least one 38042 of these between the name and the number will suffice. 38043 38044 If this macro is not defined, a default definition will be provided 38045 which is correct for most systems. 38046 38047 -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE) 38048 A C statement to output to the stdio stream STREAM assembler code 38049 which defines (equates) the symbol NAME to have the value VALUE. 38050 38051 If 'SET_ASM_OP' is defined, a default definition is provided which 38052 is correct for most systems. 38053 38054 -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME, 38055 DECL_OF_VALUE) 38056 A C statement to output to the stdio stream STREAM assembler code 38057 which defines (equates) the symbol whose tree node is DECL_OF_NAME 38058 to have the value of the tree node DECL_OF_VALUE. This macro will 38059 be used in preference to 'ASM_OUTPUT_DEF' if it is defined and if 38060 the tree nodes are available. 38061 38062 If 'SET_ASM_OP' is defined, a default definition is provided which 38063 is correct for most systems. 38064 38065 -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE) 38066 A C statement that evaluates to true if the assembler code which 38067 defines (equates) the symbol whose tree node is DECL_OF_NAME to 38068 have the value of the tree node DECL_OF_VALUE should be emitted 38069 near the end of the current compilation unit. The default is to 38070 not defer output of defines. This macro affects defines output by 38071 'ASM_OUTPUT_DEF' and 'ASM_OUTPUT_DEF_FROM_DECLS'. 38072 38073 -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE) 38074 A C statement to output to the stdio stream STREAM assembler code 38075 which defines (equates) the weak symbol NAME to have the value 38076 VALUE. If VALUE is 'NULL', it defines NAME as an undefined weak 38077 symbol. 38078 38079 Define this macro if the target only supports weak aliases; define 38080 'ASM_OUTPUT_DEF' instead if possible. 38081 38082 -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME, 38083 SEL_NAME) 38084 Define this macro to override the default assembler names used for 38085 Objective-C methods. 38086 38087 The default name is a unique method number followed by the name of 38088 the class (e.g. '_1_Foo'). For methods in categories, the name of 38089 the category is also included in the assembler name (e.g. 38090 '_1_Foo_Bar'). 38091 38092 These names are safe on most systems, but make debugging difficult 38093 since the method's selector is not present in the name. Therefore, 38094 particular systems define other ways of computing names. 38095 38096 BUF is an expression of type 'char *' which gives you a buffer in 38097 which to store the name; its length is as long as CLASS_NAME, 38098 CAT_NAME and SEL_NAME put together, plus 50 characters extra. 38099 38100 The argument IS_INST specifies whether the method is an instance 38101 method or a class method; CLASS_NAME is the name of the class; 38102 CAT_NAME is the name of the category (or 'NULL' if the method is 38103 not in a category); and SEL_NAME is the name of the selector. 38104 38105 On systems where the assembler can handle quoted names, you can use 38106 this macro to provide more human-readable names. 38107 38108 38109File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format 38110 3811118.20.5 How Initialization Functions Are Handled 38112------------------------------------------------ 38113 38114The compiled code for certain languages includes "constructors" (also 38115called "initialization routines")--functions to initialize data in the 38116program when the program is started. These functions need to be called 38117before the program is "started"--that is to say, before 'main' is 38118called. 38119 38120 Compiling some languages generates "destructors" (also called 38121"termination routines") that should be called when the program 38122terminates. 38123 38124 To make the initialization and termination functions work, the compiler 38125must output something in the assembler code to cause those functions to 38126be called at the appropriate time. When you port the compiler to a new 38127system, you need to specify how to do this. 38128 38129 There are two major ways that GCC currently supports the execution of 38130initialization and termination functions. Each way has two variants. 38131Much of the structure is common to all four variations. 38132 38133 The linker must build two lists of these functions--a list of 38134initialization functions, called '__CTOR_LIST__', and a list of 38135termination functions, called '__DTOR_LIST__'. 38136 38137 Each list always begins with an ignored function pointer (which may 38138hold 0, -1, or a count of the function pointers after it, depending on 38139the environment). This is followed by a series of zero or more function 38140pointers to constructors (or destructors), followed by a function 38141pointer containing zero. 38142 38143 Depending on the operating system and its executable file format, 38144either 'crtstuff.c' or 'libgcc2.c' traverses these lists at startup time 38145and exit time. Constructors are called in reverse order of the list; 38146destructors in forward order. 38147 38148 The best way to handle static constructors works only for object file 38149formats which provide arbitrarily-named sections. A section is set 38150aside for a list of constructors, and another for a list of destructors. 38151Traditionally these are called '.ctors' and '.dtors'. Each object file 38152that defines an initialization function also puts a word in the 38153constructor section to point to that function. The linker accumulates 38154all these words into one contiguous '.ctors' section. Termination 38155functions are handled similarly. 38156 38157 This method will be chosen as the default by 'target-def.h' if 38158'TARGET_ASM_NAMED_SECTION' is defined. A target that does not support 38159arbitrary sections, but does support special designated constructor and 38160destructor sections may define 'CTORS_SECTION_ASM_OP' and 38161'DTORS_SECTION_ASM_OP' to achieve the same effect. 38162 38163 When arbitrary sections are available, there are two variants, 38164depending upon how the code in 'crtstuff.c' is called. On systems that 38165support a ".init" section which is executed at program startup, parts of 38166'crtstuff.c' are compiled into that section. The program is linked by 38167the 'gcc' driver like this: 38168 38169 ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o 38170 38171 The prologue of a function ('__init') appears in the '.init' section of 38172'crti.o'; the epilogue appears in 'crtn.o'. Likewise for the function 38173'__fini' in the ".fini" section. Normally these files are provided by 38174the operating system or by the GNU C library, but are provided by GCC 38175for a few targets. 38176 38177 The objects 'crtbegin.o' and 'crtend.o' are (for most targets) compiled 38178from 'crtstuff.c'. They contain, among other things, code fragments 38179within the '.init' and '.fini' sections that branch to routines in the 38180'.text' section. The linker will pull all parts of a section together, 38181which results in a complete '__init' function that invokes the routines 38182we need at startup. 38183 38184 To use this variant, you must define the 'INIT_SECTION_ASM_OP' macro 38185properly. 38186 38187 If no init section is available, when GCC compiles any function called 38188'main' (or more accurately, any function designated as a program entry 38189point by the language front end calling 'expand_main_function'), it 38190inserts a procedure call to '__main' as the first executable code after 38191the function prologue. The '__main' function is defined in 'libgcc2.c' 38192and runs the global constructors. 38193 38194 In file formats that don't support arbitrary sections, there are again 38195two variants. In the simplest variant, the GNU linker (GNU 'ld') and an 38196'a.out' format must be used. In this case, 'TARGET_ASM_CONSTRUCTOR' is 38197defined to produce a '.stabs' entry of type 'N_SETT', referencing the 38198name '__CTOR_LIST__', and with the address of the void function 38199containing the initialization code as its value. The GNU linker 38200recognizes this as a request to add the value to a "set"; the values are 38201accumulated, and are eventually placed in the executable as a vector in 38202the format described above, with a leading (ignored) count and a 38203trailing zero element. 'TARGET_ASM_DESTRUCTOR' is handled similarly. 38204Since no init section is available, the absence of 'INIT_SECTION_ASM_OP' 38205causes the compilation of 'main' to call '__main' as above, starting the 38206initialization process. 38207 38208 The last variant uses neither arbitrary sections nor the GNU linker. 38209This is preferable when you want to do dynamic linking and when using 38210file formats which the GNU linker does not support, such as 'ECOFF'. In 38211this case, 'TARGET_HAVE_CTORS_DTORS' is false, initialization and 38212termination functions are recognized simply by their names. This 38213requires an extra program in the linkage step, called 'collect2'. This 38214program pretends to be the linker, for use with GCC; it does its job by 38215running the ordinary linker, but also arranges to include the vectors of 38216initialization and termination functions. These functions are called 38217via '__main' as described above. In order to use this method, 38218'use_collect2' must be defined in the target in 'config.gcc'. 38219 38220 The following section describes the specific macros that control and 38221customize the handling of initialization and termination functions. 38222 38223 38224File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format 38225 3822618.20.6 Macros Controlling Initialization Routines 38227-------------------------------------------------- 38228 38229Here are the macros that control how the compiler handles initialization 38230and termination functions: 38231 38232 -- Macro: INIT_SECTION_ASM_OP 38233 If defined, a C string constant, including spacing, for the 38234 assembler operation to identify the following data as 38235 initialization code. If not defined, GCC will assume such a 38236 section does not exist. When you are using special sections for 38237 initialization and termination functions, this macro also controls 38238 how 'crtstuff.c' and 'libgcc2.c' arrange to run the initialization 38239 functions. 38240 38241 -- Macro: HAS_INIT_SECTION 38242 If defined, 'main' will not call '__main' as described above. This 38243 macro should be defined for systems that control start-up code on a 38244 symbol-by-symbol basis, such as OSF/1, and should not be defined 38245 explicitly for systems that support 'INIT_SECTION_ASM_OP'. 38246 38247 -- Macro: LD_INIT_SWITCH 38248 If defined, a C string constant for a switch that tells the linker 38249 that the following symbol is an initialization routine. 38250 38251 -- Macro: LD_FINI_SWITCH 38252 If defined, a C string constant for a switch that tells the linker 38253 that the following symbol is a finalization routine. 38254 38255 -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC) 38256 If defined, a C statement that will write a function that can be 38257 automatically called when a shared library is loaded. The function 38258 should call FUNC, which takes no arguments. If not defined, and 38259 the object format requires an explicit initialization function, 38260 then a function called '_GLOBAL__DI' will be generated. 38261 38262 This function and the following one are used by collect2 when 38263 linking a shared library that needs constructors or destructors, or 38264 has DWARF2 exception tables embedded in the code. 38265 38266 -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC) 38267 If defined, a C statement that will write a function that can be 38268 automatically called when a shared library is unloaded. The 38269 function should call FUNC, which takes no arguments. If not 38270 defined, and the object format requires an explicit finalization 38271 function, then a function called '_GLOBAL__DD' will be generated. 38272 38273 -- Macro: INVOKE__main 38274 If defined, 'main' will call '__main' despite the presence of 38275 'INIT_SECTION_ASM_OP'. This macro should be defined for systems 38276 where the init section is not actually run automatically, but is 38277 still useful for collecting the lists of constructors and 38278 destructors. 38279 38280 -- Macro: SUPPORTS_INIT_PRIORITY 38281 If nonzero, the C++ 'init_priority' attribute is supported and the 38282 compiler should emit instructions to control the order of 38283 initialization of objects. If zero, the compiler will issue an 38284 error message upon encountering an 'init_priority' attribute. 38285 38286 -- Target Hook: bool TARGET_HAVE_CTORS_DTORS 38287 This value is true if the target supports some "native" method of 38288 collecting constructors and destructors to be run at startup and 38289 exit. It is false if we must use 'collect2'. 38290 38291 -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY) 38292 If defined, a function that outputs assembler code to arrange to 38293 call the function referenced by SYMBOL at initialization time. 38294 38295 Assume that SYMBOL is a 'SYMBOL_REF' for a function taking no 38296 arguments and with no return value. If the target supports 38297 initialization priorities, PRIORITY is a value between 0 and 38298 'MAX_INIT_PRIORITY'; otherwise it must be 'DEFAULT_INIT_PRIORITY'. 38299 38300 If this macro is not defined by the target, a suitable default will 38301 be chosen if (1) the target supports arbitrary section names, (2) 38302 the target defines 'CTORS_SECTION_ASM_OP', or (3) 'USE_COLLECT2' is 38303 not defined. 38304 38305 -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY) 38306 This is like 'TARGET_ASM_CONSTRUCTOR' but used for termination 38307 functions rather than initialization functions. 38308 38309 If 'TARGET_HAVE_CTORS_DTORS' is true, the initialization routine 38310generated for the generated object file will have static linkage. 38311 38312 If your system uses 'collect2' as the means of processing constructors, 38313then that program normally uses 'nm' to scan an object file for 38314constructor functions to be called. 38315 38316 On certain kinds of systems, you can define this macro to make 38317'collect2' work faster (and, in some cases, make it work at all): 38318 38319 -- Macro: OBJECT_FORMAT_COFF 38320 Define this macro if the system uses COFF (Common Object File 38321 Format) object files, so that 'collect2' can assume this format and 38322 scan object files directly for dynamic constructor/destructor 38323 functions. 38324 38325 This macro is effective only in a native compiler; 'collect2' as 38326 part of a cross compiler always uses 'nm' for the target machine. 38327 38328 -- Macro: REAL_NM_FILE_NAME 38329 Define this macro as a C string constant containing the file name 38330 to use to execute 'nm'. The default is to search the path normally 38331 for 'nm'. 38332 38333 -- Macro: NM_FLAGS 38334 'collect2' calls 'nm' to scan object files for static constructors 38335 and destructors and LTO info. By default, '-n' is passed. Define 38336 'NM_FLAGS' to a C string constant if other options are needed to 38337 get the same output format as GNU 'nm -n' produces. 38338 38339 If your system supports shared libraries and has a program to list the 38340dynamic dependencies of a given library or executable, you can define 38341these macros to enable support for running initialization and 38342termination functions in shared libraries: 38343 38344 -- Macro: LDD_SUFFIX 38345 Define this macro to a C string constant containing the name of the 38346 program which lists dynamic dependencies, like 'ldd' under SunOS 4. 38347 38348 -- Macro: PARSE_LDD_OUTPUT (PTR) 38349 Define this macro to be C code that extracts filenames from the 38350 output of the program denoted by 'LDD_SUFFIX'. PTR is a variable 38351 of type 'char *' that points to the beginning of a line of output 38352 from 'LDD_SUFFIX'. If the line lists a dynamic dependency, the 38353 code must advance PTR to the beginning of the filename on that 38354 line. Otherwise, it must set PTR to 'NULL'. 38355 38356 -- Macro: SHLIB_SUFFIX 38357 Define this macro to a C string constant containing the default 38358 shared library extension of the target (e.g., '".so"'). 'collect2' 38359 strips version information after this suffix when generating global 38360 constructor and destructor names. This define is only needed on 38361 targets that use 'collect2' to process constructors and 38362 destructors. 38363 38364 38365File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format 38366 3836718.20.7 Output of Assembler Instructions 38368---------------------------------------- 38369 38370This describes assembler instruction output. 38371 38372 -- Macro: REGISTER_NAMES 38373 A C initializer containing the assembler's names for the machine 38374 registers, each one as a C string constant. This is what 38375 translates register numbers in the compiler into assembler 38376 language. 38377 38378 -- Macro: ADDITIONAL_REGISTER_NAMES 38379 If defined, a C initializer for an array of structures containing a 38380 name and a register number. This macro defines additional names 38381 for hard registers, thus allowing the 'asm' option in declarations 38382 to refer to registers using alternate names. 38383 38384 -- Macro: OVERLAPPING_REGISTER_NAMES 38385 If defined, a C initializer for an array of structures containing a 38386 name, a register number and a count of the number of consecutive 38387 machine registers the name overlaps. This macro defines additional 38388 names for hard registers, thus allowing the 'asm' option in 38389 declarations to refer to registers using alternate names. Unlike 38390 'ADDITIONAL_REGISTER_NAMES', this macro should be used when the 38391 register name implies multiple underlying registers. 38392 38393 This macro should be used when it is important that a clobber in an 38394 'asm' statement clobbers all the underlying values implied by the 38395 register name. For example, on ARM, clobbering the 38396 double-precision VFP register "d0" implies clobbering both 38397 single-precision registers "s0" and "s1". 38398 38399 -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR) 38400 Define this macro if you are using an unusual assembler that 38401 requires different names for the machine instructions. 38402 38403 The definition is a C statement or statements which output an 38404 assembler instruction opcode to the stdio stream STREAM. The 38405 macro-operand PTR is a variable of type 'char *' which points to 38406 the opcode name in its "internal" form--the form that is written in 38407 the machine description. The definition should output the opcode 38408 name to STREAM, performing any translation you desire, and 38409 increment the variable PTR to point at the end of the opcode so 38410 that it will not be output twice. 38411 38412 In fact, your macro definition may process less than the entire 38413 opcode name, or more than the opcode name; but if you want to 38414 process text that includes '%'-sequences to substitute operands, 38415 you must take care of the substitution yourself. Just be sure to 38416 increment PTR over whatever text should not be output normally. 38417 38418 If you need to look at the operand values, they can be found as the 38419 elements of 'recog_data.operand'. 38420 38421 If the macro definition does nothing, the instruction is output in 38422 the usual way. 38423 38424 -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS) 38425 If defined, a C statement to be executed just prior to the output 38426 of assembler code for INSN, to modify the extracted operands so 38427 they will be output differently. 38428 38429 Here the argument OPVEC is the vector containing the operands 38430 extracted from INSN, and NOPERANDS is the number of elements of the 38431 vector which contain meaningful data for this insn. The contents 38432 of this vector are what will be used to convert the insn template 38433 into assembler code, so you can change the assembler output by 38434 changing the contents of the vector. 38435 38436 This macro is useful when various assembler syntaxes share a single 38437 file of instruction patterns; by defining this macro differently, 38438 you can cause a large class of instructions to be output 38439 differently (such as with rearranged operands). Naturally, 38440 variations in assembler syntax affecting individual insn patterns 38441 ought to be handled by writing conditional output routines in those 38442 patterns. 38443 38444 If this macro is not defined, it is equivalent to a null statement. 38445 38446 -- Target Hook: void TARGET_ASM_FINAL_POSTSCAN_INSN (FILE *FILE, 38447 rtx_insn *INSN, rtx *OPVEC, int NOPERANDS) 38448 If defined, this target hook is a function which is executed just 38449 after the output of assembler code for INSN, to change the mode of 38450 the assembler if necessary. 38451 38452 Here the argument OPVEC is the vector containing the operands 38453 extracted from INSN, and NOPERANDS is the number of elements of the 38454 vector which contain meaningful data for this insn. The contents 38455 of this vector are what was used to convert the insn template into 38456 assembler code, so you can change the assembler mode by checking 38457 the contents of the vector. 38458 38459 -- Macro: PRINT_OPERAND (STREAM, X, CODE) 38460 A C compound statement to output to stdio stream STREAM the 38461 assembler syntax for an instruction operand X. X is an RTL 38462 expression. 38463 38464 CODE is a value that can be used to specify one of several ways of 38465 printing the operand. It is used when identical operands must be 38466 printed differently depending on the context. CODE comes from the 38467 '%' specification that was used to request printing of the operand. 38468 If the specification was just '%DIGIT' then CODE is 0; if the 38469 specification was '%LTR DIGIT' then CODE is the ASCII code for LTR. 38470 38471 If X is a register, this macro should print the register's name. 38472 The names can be found in an array 'reg_names' whose type is 'char 38473 *[]'. 'reg_names' is initialized from 'REGISTER_NAMES'. 38474 38475 When the machine description has a specification '%PUNCT' (a '%' 38476 followed by a punctuation character), this macro is called with a 38477 null pointer for X and the punctuation character for CODE. 38478 38479 -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE) 38480 A C expression which evaluates to true if CODE is a valid 38481 punctuation character for use in the 'PRINT_OPERAND' macro. If 38482 'PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no 38483 punctuation characters (except for the standard one, '%') are used 38484 in this way. 38485 38486 -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X) 38487 A C compound statement to output to stdio stream STREAM the 38488 assembler syntax for an instruction operand that is a memory 38489 reference whose address is X. X is an RTL expression. 38490 38491 On some machines, the syntax for a symbolic address depends on the 38492 section that the address refers to. On these machines, define the 38493 hook 'TARGET_ENCODE_SECTION_INFO' to store the information into the 38494 'symbol_ref', and then check for it here. *Note Assembler 38495 Format::. 38496 38497 -- Macro: DBR_OUTPUT_SEQEND (FILE) 38498 A C statement, to be executed after all slot-filler instructions 38499 have been output. If necessary, call 'dbr_sequence_length' to 38500 determine the number of slots filled in a sequence (zero if not 38501 currently outputting a sequence), to decide how many no-ops to 38502 output, or whatever. 38503 38504 Don't define this macro if it has nothing to do, but it is helpful 38505 in reading assembly output if the extent of the delay sequence is 38506 made explicit (e.g. with white space). 38507 38508 Note that output routines for instructions with delay slots must be 38509prepared to deal with not being output as part of a sequence (i.e. when 38510the scheduling pass is not run, or when no slot fillers could be found.) 38511The variable 'final_sequence' is null when not processing a sequence, 38512otherwise it contains the 'sequence' rtx being output. 38513 38514 -- Macro: REGISTER_PREFIX 38515 -- Macro: LOCAL_LABEL_PREFIX 38516 -- Macro: USER_LABEL_PREFIX 38517 -- Macro: IMMEDIATE_PREFIX 38518 If defined, C string expressions to be used for the '%R', '%L', 38519 '%U', and '%I' options of 'asm_fprintf' (see 'final.c'). These are 38520 useful when a single 'md' file must support multiple assembler 38521 formats. In that case, the various 'tm.h' files can define these 38522 macros differently. 38523 38524 -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT) 38525 If defined this macro should expand to a series of 'case' 38526 statements which will be parsed inside the 'switch' statement of 38527 the 'asm_fprintf' function. This allows targets to define extra 38528 printf formats which may useful when generating their assembler 38529 statements. Note that uppercase letters are reserved for future 38530 generic extensions to asm_fprintf, and so are not available to 38531 target specific code. The output file is given by the parameter 38532 FILE. The varargs input pointer is ARGPTR and the rest of the 38533 format string, starting the character after the one that is being 38534 switched upon, is pointed to by FORMAT. 38535 38536 -- Macro: ASSEMBLER_DIALECT 38537 If your target supports multiple dialects of assembler language 38538 (such as different opcodes), define this macro as a C expression 38539 that gives the numeric index of the assembler language dialect to 38540 use, with zero as the first variant. 38541 38542 If this macro is defined, you may use constructs of the form 38543 '{option0|option1|option2...}' 38544 in the output templates of patterns (*note Output Template::) or in 38545 the first argument of 'asm_fprintf'. This construct outputs 38546 'option0', 'option1', 'option2', etc., if the value of 38547 'ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters 38548 within these strings retain their usual meaning. If there are 38549 fewer alternatives within the braces than the value of 38550 'ASSEMBLER_DIALECT', the construct outputs nothing. If it's needed 38551 to print curly braces or '|' character in assembler output 38552 directly, '%{', '%}' and '%|' can be used. 38553 38554 If you do not define this macro, the characters '{', '|' and '}' do 38555 not have any special meaning when used in templates or operands to 38556 'asm_fprintf'. 38557 38558 Define the macros 'REGISTER_PREFIX', 'LOCAL_LABEL_PREFIX', 38559 'USER_LABEL_PREFIX' and 'IMMEDIATE_PREFIX' if you can express the 38560 variations in assembler language syntax with that mechanism. 38561 Define 'ASSEMBLER_DIALECT' and use the '{option0|option1}' syntax 38562 if the syntax variant are larger and involve such things as 38563 different opcodes or operand order. 38564 38565 -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO) 38566 A C expression to output to STREAM some assembler code which will 38567 push hard register number REGNO onto the stack. The code need not 38568 be optimal, since this macro is used only when profiling. 38569 38570 -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO) 38571 A C expression to output to STREAM some assembler code which will 38572 pop hard register number REGNO off of the stack. The code need not 38573 be optimal, since this macro is used only when profiling. 38574 38575 38576File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format 38577 3857818.20.8 Output of Dispatch Tables 38579--------------------------------- 38580 38581This concerns dispatch tables. 38582 38583 -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL) 38584 A C statement to output to the stdio stream STREAM an assembler 38585 pseudo-instruction to generate a difference between two labels. 38586 VALUE and REL are the numbers of two internal labels. The 38587 definitions of these labels are output using 38588 '(*targetm.asm_out.internal_label)', and they must be printed in 38589 the same way here. For example, 38590 38591 fprintf (STREAM, "\t.word L%d-L%d\n", 38592 VALUE, REL) 38593 38594 You must provide this macro on machines where the addresses in a 38595 dispatch table are relative to the table's own address. If 38596 defined, GCC will also use this macro on all machines when 38597 producing PIC. BODY is the body of the 'ADDR_DIFF_VEC'; it is 38598 provided so that the mode and flags can be read. 38599 38600 -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE) 38601 This macro should be provided on machines where the addresses in a 38602 dispatch table are absolute. 38603 38604 The definition should be a C statement to output to the stdio 38605 stream STREAM an assembler pseudo-instruction to generate a 38606 reference to a label. VALUE is the number of an internal label 38607 whose definition is output using 38608 '(*targetm.asm_out.internal_label)'. For example, 38609 38610 fprintf (STREAM, "\t.word L%d\n", VALUE) 38611 38612 -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE) 38613 Define this if the label before a jump-table needs to be output 38614 specially. The first three arguments are the same as for 38615 '(*targetm.asm_out.internal_label)'; the fourth argument is the 38616 jump-table which follows (a 'jump_table_data' containing an 38617 'addr_vec' or 'addr_diff_vec'). 38618 38619 This feature is used on system V to output a 'swbeg' statement for 38620 the table. 38621 38622 If this macro is not defined, these labels are output with 38623 '(*targetm.asm_out.internal_label)'. 38624 38625 -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE) 38626 Define this if something special must be output at the end of a 38627 jump-table. The definition should be a C statement to be executed 38628 after the assembler code for the table is written. It should write 38629 the appropriate code to stdio stream STREAM. The argument TABLE is 38630 the jump-table insn, and NUM is the label-number of the preceding 38631 label. 38632 38633 If this macro is not defined, nothing special is output at the end 38634 of the jump-table. 38635 38636 -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (FILE *STREAM, tree 38637 DECL, int FOR_EH, int EMPTY) 38638 This target hook emits a label at the beginning of each FDE. It 38639 should be defined on targets where FDEs need special labels, and it 38640 should write the appropriate label, for the FDE associated with the 38641 function declaration DECL, to the stdio stream STREAM. The third 38642 argument, FOR_EH, is a boolean: true if this is for an exception 38643 table. The fourth argument, EMPTY, is a boolean: true if this is a 38644 placeholder label for an omitted FDE. 38645 38646 The default is that FDEs are not given nonlocal labels. 38647 38648 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL (FILE *STREAM) 38649 This target hook emits a label at the beginning of the exception 38650 table. It should be defined on targets where it is desirable for 38651 the table to be broken up according to function. 38652 38653 The default is that no label is emitted. 38654 38655 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_PERSONALITY (rtx 38656 PERSONALITY) 38657 If the target implements 'TARGET_ASM_UNWIND_EMIT', this hook may be 38658 used to emit a directive to install a personality hook into the 38659 unwind info. This hook should not be used if dwarf2 unwind info is 38660 used. 38661 38662 -- Target Hook: void TARGET_ASM_UNWIND_EMIT (FILE *STREAM, rtx_insn 38663 *INSN) 38664 This target hook emits assembly directives required to unwind the 38665 given instruction. This is only used when 38666 'TARGET_EXCEPT_UNWIND_INFO' returns 'UI_TARGET'. 38667 38668 -- Target Hook: bool TARGET_ASM_UNWIND_EMIT_BEFORE_INSN 38669 True if the 'TARGET_ASM_UNWIND_EMIT' hook should be called before 38670 the assembly for INSN has been emitted, false if the hook should be 38671 called afterward. 38672 38673 38674File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format 38675 3867618.20.9 Assembler Commands for Exception Regions 38677------------------------------------------------ 38678 38679This describes commands marking the start and the end of an exception 38680region. 38681 38682 -- Macro: EH_FRAME_SECTION_NAME 38683 If defined, a C string constant for the name of the section 38684 containing exception handling frame unwind information. If not 38685 defined, GCC will provide a default definition if the target 38686 supports named sections. 'crtstuff.c' uses this macro to switch to 38687 the appropriate section. 38688 38689 You should define this symbol if your target supports DWARF 2 frame 38690 unwind information and the default definition does not work. 38691 38692 -- Macro: EH_FRAME_THROUGH_COLLECT2 38693 If defined, DWARF 2 frame unwind information will identified by 38694 specially named labels. The collect2 process will locate these 38695 labels and generate code to register the frames. 38696 38697 This might be necessary, for instance, if the system linker will 38698 not place the eh_frames in-between the sentinals from 'crtstuff.c', 38699 or if the system linker does garbage collection and sections cannot 38700 be marked as not to be collected. 38701 38702 -- Macro: EH_TABLES_CAN_BE_READ_ONLY 38703 Define this macro to 1 if your target is such that no frame unwind 38704 information encoding used with non-PIC code will ever require a 38705 runtime relocation, but the linker may not support merging 38706 read-only and read-write sections into a single read-write section. 38707 38708 -- Macro: MASK_RETURN_ADDR 38709 An rtx used to mask the return address found via 'RETURN_ADDR_RTX', 38710 so that it does not contain any extraneous set bits in it. 38711 38712 -- Macro: DWARF2_UNWIND_INFO 38713 Define this macro to 0 if your target supports DWARF 2 frame unwind 38714 information, but it does not yet work with exception handling. 38715 Otherwise, if your target supports this information (if it defines 38716 'INCOMING_RETURN_ADDR_RTX' and 'OBJECT_FORMAT_ELF'), GCC will 38717 provide a default definition of 1. 38718 38719 -- Common Target Hook: enum unwind_info_type TARGET_EXCEPT_UNWIND_INFO 38720 (struct gcc_options *OPTS) 38721 This hook defines the mechanism that will be used for exception 38722 handling by the target. If the target has ABI specified unwind 38723 tables, the hook should return 'UI_TARGET'. If the target is to 38724 use the 'setjmp'/'longjmp'-based exception handling scheme, the 38725 hook should return 'UI_SJLJ'. If the target supports DWARF 2 frame 38726 unwind information, the hook should return 'UI_DWARF2'. 38727 38728 A target may, if exceptions are disabled, choose to return 38729 'UI_NONE'. This may end up simplifying other parts of 38730 target-specific code. The default implementation of this hook 38731 never returns 'UI_NONE'. 38732 38733 Note that the value returned by this hook should be constant. It 38734 should not depend on anything except the command-line switches 38735 described by OPTS. In particular, the setting 'UI_SJLJ' must be 38736 fixed at compiler start-up as C pre-processor macros and builtin 38737 functions related to exception handling are set up depending on 38738 this setting. 38739 38740 The default implementation of the hook first honors the 38741 '--enable-sjlj-exceptions' configure option, then 38742 'DWARF2_UNWIND_INFO', and finally defaults to 'UI_SJLJ'. If 38743 'DWARF2_UNWIND_INFO' depends on command-line options, the target 38744 must define this hook so that OPTS is used correctly. 38745 38746 -- Common Target Hook: bool TARGET_UNWIND_TABLES_DEFAULT 38747 This variable should be set to 'true' if the target ABI requires 38748 unwinding tables even when exceptions are not used. It must not be 38749 modified by command-line option processing. 38750 38751 -- Macro: DONT_USE_BUILTIN_SETJMP 38752 Define this macro to 1 if the 'setjmp'/'longjmp'-based scheme 38753 should use the 'setjmp'/'longjmp' functions from the C library 38754 instead of the '__builtin_setjmp'/'__builtin_longjmp' machinery. 38755 38756 -- Macro: JMP_BUF_SIZE 38757 This macro has no effect unless 'DONT_USE_BUILTIN_SETJMP' is also 38758 defined. Define this macro if the default size of 'jmp_buf' buffer 38759 for the 'setjmp'/'longjmp'-based exception handling mechanism is 38760 not large enough, or if it is much too large. The default size is 38761 'FIRST_PSEUDO_REGISTER * sizeof(void *)'. 38762 38763 -- Macro: DWARF_CIE_DATA_ALIGNMENT 38764 This macro need only be defined if the target might save registers 38765 in the function prologue at an offset to the stack pointer that is 38766 not aligned to 'UNITS_PER_WORD'. The definition should be the 38767 negative minimum alignment if 'STACK_GROWS_DOWNWARD' is true, and 38768 the positive minimum alignment otherwise. *Note DWARF::. Only 38769 applicable if the target supports DWARF 2 frame unwind information. 38770 38771 -- Target Hook: bool TARGET_TERMINATE_DW2_EH_FRAME_INFO 38772 Contains the value true if the target should add a zero word onto 38773 the end of a Dwarf-2 frame info section when used for exception 38774 handling. Default value is false if 'EH_FRAME_SECTION_NAME' is 38775 defined, and true otherwise. 38776 38777 -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG) 38778 Given a register, this hook should return a parallel of registers 38779 to represent where to find the register pieces. Define this hook 38780 if the register and its mode are represented in Dwarf in 38781 non-contiguous locations, or if the register should be represented 38782 in more than one register in Dwarf. Otherwise, this hook should 38783 return 'NULL_RTX'. If not defined, the default is to return 38784 'NULL_RTX'. 38785 38786 -- Target Hook: machine_mode TARGET_DWARF_FRAME_REG_MODE (int REGNO) 38787 Given a register, this hook should return the mode which the 38788 corresponding Dwarf frame register should have. This is normally 38789 used to return a smaller mode than the raw mode to prevent call 38790 clobbered parts of a register altering the frame register size 38791 38792 -- Target Hook: void TARGET_INIT_DWARF_REG_SIZES_EXTRA (tree ADDRESS) 38793 If some registers are represented in Dwarf-2 unwind information in 38794 multiple pieces, define this hook to fill in information about the 38795 sizes of those pieces in the table used by the unwinder at runtime. 38796 It will be called by 'expand_builtin_init_dwarf_reg_sizes' after 38797 filling in a single size corresponding to each hard register; 38798 ADDRESS is the address of the table. 38799 38800 -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM) 38801 This hook is used to output a reference from a frame unwinding 38802 table to the type_info object identified by SYM. It should return 38803 'true' if the reference was output. Returning 'false' will cause 38804 the reference to be output using the normal Dwarf2 routines. 38805 38806 -- Target Hook: bool TARGET_ARM_EABI_UNWINDER 38807 This flag should be set to 'true' on targets that use an ARM EABI 38808 based unwinding library, and 'false' on other targets. This 38809 effects the format of unwinding tables, and how the unwinder in 38810 entered after running a cleanup. The default is 'false'. 38811 38812 38813File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format 38814 3881518.20.10 Assembler Commands for Alignment 38816----------------------------------------- 38817 38818This describes commands for alignment. 38819 38820 -- Macro: JUMP_ALIGN (LABEL) 38821 The alignment (log base 2) to put in front of LABEL, which is a 38822 common destination of jumps and has no fallthru incoming edge. 38823 38824 This macro need not be defined if you don't want any special 38825 alignment to be done at such a time. Most machine descriptions do 38826 not currently define the macro. 38827 38828 Unless it's necessary to inspect the LABEL parameter, it is better 38829 to set the variable ALIGN_JUMPS in the target's 38830 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 38831 user's selection in ALIGN_JUMPS in a 'JUMP_ALIGN' implementation. 38832 38833 -- Target Hook: int TARGET_ASM_JUMP_ALIGN_MAX_SKIP (rtx_insn *LABEL) 38834 The maximum number of bytes to skip before LABEL when applying 38835 'JUMP_ALIGN'. This works only if 'ASM_OUTPUT_MAX_SKIP_ALIGN' is 38836 defined. 38837 38838 -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL) 38839 The alignment (log base 2) to put in front of LABEL, which follows 38840 a 'BARRIER'. 38841 38842 This macro need not be defined if you don't want any special 38843 alignment to be done at such a time. Most machine descriptions do 38844 not currently define the macro. 38845 38846 -- Target Hook: int TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP 38847 (rtx_insn *LABEL) 38848 The maximum number of bytes to skip before LABEL when applying 38849 'LABEL_ALIGN_AFTER_BARRIER'. This works only if 38850 'ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 38851 38852 -- Macro: LOOP_ALIGN (LABEL) 38853 The alignment (log base 2) to put in front of LABEL that heads a 38854 frequently executed basic block (usually the header of a loop). 38855 38856 This macro need not be defined if you don't want any special 38857 alignment to be done at such a time. Most machine descriptions do 38858 not currently define the macro. 38859 38860 Unless it's necessary to inspect the LABEL parameter, it is better 38861 to set the variable 'align_loops' in the target's 38862 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 38863 user's selection in 'align_loops' in a 'LOOP_ALIGN' implementation. 38864 38865 -- Target Hook: int TARGET_ASM_LOOP_ALIGN_MAX_SKIP (rtx_insn *LABEL) 38866 The maximum number of bytes to skip when applying 'LOOP_ALIGN' to 38867 LABEL. This works only if 'ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 38868 38869 -- Macro: LABEL_ALIGN (LABEL) 38870 The alignment (log base 2) to put in front of LABEL. If 38871 'LABEL_ALIGN_AFTER_BARRIER' / 'LOOP_ALIGN' specify a different 38872 alignment, the maximum of the specified values is used. 38873 38874 Unless it's necessary to inspect the LABEL parameter, it is better 38875 to set the variable 'align_labels' in the target's 38876 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 38877 user's selection in 'align_labels' in a 'LABEL_ALIGN' 38878 implementation. 38879 38880 -- Target Hook: int TARGET_ASM_LABEL_ALIGN_MAX_SKIP (rtx_insn *LABEL) 38881 The maximum number of bytes to skip when applying 'LABEL_ALIGN' to 38882 LABEL. This works only if 'ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 38883 38884 -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES) 38885 A C statement to output to the stdio stream STREAM an assembler 38886 instruction to advance the location counter by NBYTES bytes. Those 38887 bytes should be zero when loaded. NBYTES will be a C expression of 38888 type 'unsigned HOST_WIDE_INT'. 38889 38890 -- Macro: ASM_NO_SKIP_IN_TEXT 38891 Define this macro if 'ASM_OUTPUT_SKIP' should not be used in the 38892 text section because it fails to put zeros in the bytes that are 38893 skipped. This is true on many Unix systems, where the pseudo-op to 38894 skip bytes produces no-op instructions rather than zeros when used 38895 in the text section. 38896 38897 -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER) 38898 A C statement to output to the stdio stream STREAM an assembler 38899 command to advance the location counter to a multiple of 2 to the 38900 POWER bytes. POWER will be a C expression of type 'int'. 38901 38902 -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER) 38903 Like 'ASM_OUTPUT_ALIGN', except that the "nop" instruction is used 38904 for padding, if necessary. 38905 38906 -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP) 38907 A C statement to output to the stdio stream STREAM an assembler 38908 command to advance the location counter to a multiple of 2 to the 38909 POWER bytes, but only if MAX_SKIP or fewer bytes are needed to 38910 satisfy the alignment request. POWER and MAX_SKIP will be a C 38911 expression of type 'int'. 38912 38913 38914File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros 38915 3891618.21 Controlling Debugging Information Format 38917============================================== 38918 38919This describes how to specify debugging information. 38920 38921* Menu: 38922 38923* All Debuggers:: Macros that affect all debugging formats uniformly. 38924* DBX Options:: Macros enabling specific options in DBX format. 38925* DBX Hooks:: Hook macros for varying DBX format. 38926* File Names and DBX:: Macros controlling output of file names in DBX format. 38927* DWARF:: Macros for DWARF format. 38928* VMS Debug:: Macros for VMS debug format. 38929 38930 38931File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info 38932 3893318.21.1 Macros Affecting All Debugging Formats 38934---------------------------------------------- 38935 38936These macros affect all debugging formats. 38937 38938 -- Macro: DBX_REGISTER_NUMBER (REGNO) 38939 A C expression that returns the DBX register number for the 38940 compiler register number REGNO. In the default macro provided, the 38941 value of this expression will be REGNO itself. But sometimes there 38942 are some registers that the compiler knows about and DBX does not, 38943 or vice versa. In such cases, some register may need to have one 38944 number in the compiler and another for DBX. 38945 38946 If two registers have consecutive numbers inside GCC, and they can 38947 be used as a pair to hold a multiword value, then they _must_ have 38948 consecutive numbers after renumbering with 'DBX_REGISTER_NUMBER'. 38949 Otherwise, debuggers will be unable to access such a pair, because 38950 they expect register pairs to be consecutive in their own numbering 38951 scheme. 38952 38953 If you find yourself defining 'DBX_REGISTER_NUMBER' in way that 38954 does not preserve register pairs, then what you must do instead is 38955 redefine the actual register numbering scheme. 38956 38957 -- Macro: DEBUGGER_AUTO_OFFSET (X) 38958 A C expression that returns the integer offset value for an 38959 automatic variable having address X (an RTL expression). The 38960 default computation assumes that X is based on the frame-pointer 38961 and gives the offset from the frame-pointer. This is required for 38962 targets that produce debugging output for DBX and allow the 38963 frame-pointer to be eliminated when the '-g' option is used. 38964 38965 -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X) 38966 A C expression that returns the integer offset value for an 38967 argument having address X (an RTL expression). The nominal offset 38968 is OFFSET. 38969 38970 -- Macro: PREFERRED_DEBUGGING_TYPE 38971 A C expression that returns the type of debugging output GCC should 38972 produce when the user specifies just '-g'. Define this if you have 38973 arranged for GCC to support more than one format of debugging 38974 output. Currently, the allowable values are 'DBX_DEBUG', 38975 'DWARF2_DEBUG', 'XCOFF_DEBUG', 'VMS_DEBUG', and 38976 'VMS_AND_DWARF2_DEBUG'. 38977 38978 When the user specifies '-ggdb', GCC normally also uses the value 38979 of this macro to select the debugging output format, but with two 38980 exceptions. If 'DWARF2_DEBUGGING_INFO' is defined, GCC uses the 38981 value 'DWARF2_DEBUG'. Otherwise, if 'DBX_DEBUGGING_INFO' is 38982 defined, GCC uses 'DBX_DEBUG'. 38983 38984 The value of this macro only affects the default debugging output; 38985 the user can always get a specific type of output by using 38986 '-gstabs', '-gdwarf-2', '-gxcoff', or '-gvms'. 38987 38988 38989File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info 38990 3899118.21.2 Specific Options for DBX Output 38992--------------------------------------- 38993 38994These are specific options for DBX output. 38995 38996 -- Macro: DBX_DEBUGGING_INFO 38997 Define this macro if GCC should produce debugging output for DBX in 38998 response to the '-g' option. 38999 39000 -- Macro: XCOFF_DEBUGGING_INFO 39001 Define this macro if GCC should produce XCOFF format debugging 39002 output in response to the '-g' option. This is a variant of DBX 39003 format. 39004 39005 -- Macro: DEFAULT_GDB_EXTENSIONS 39006 Define this macro to control whether GCC should by default generate 39007 GDB's extended version of DBX debugging information (assuming 39008 DBX-format debugging information is enabled at all). If you don't 39009 define the macro, the default is 1: always generate the extended 39010 information if there is any occasion to. 39011 39012 -- Macro: DEBUG_SYMS_TEXT 39013 Define this macro if all '.stabs' commands should be output while 39014 in the text section. 39015 39016 -- Macro: ASM_STABS_OP 39017 A C string constant, including spacing, naming the assembler pseudo 39018 op to use instead of '"\t.stabs\t"' to define an ordinary debugging 39019 symbol. If you don't define this macro, '"\t.stabs\t"' is used. 39020 This macro applies only to DBX debugging information format. 39021 39022 -- Macro: ASM_STABD_OP 39023 A C string constant, including spacing, naming the assembler pseudo 39024 op to use instead of '"\t.stabd\t"' to define a debugging symbol 39025 whose value is the current location. If you don't define this 39026 macro, '"\t.stabd\t"' is used. This macro applies only to DBX 39027 debugging information format. 39028 39029 -- Macro: ASM_STABN_OP 39030 A C string constant, including spacing, naming the assembler pseudo 39031 op to use instead of '"\t.stabn\t"' to define a debugging symbol 39032 with no name. If you don't define this macro, '"\t.stabn\t"' is 39033 used. This macro applies only to DBX debugging information format. 39034 39035 -- Macro: DBX_NO_XREFS 39036 Define this macro if DBX on your system does not support the 39037 construct 'xsTAGNAME'. On some systems, this construct is used to 39038 describe a forward reference to a structure named TAGNAME. On 39039 other systems, this construct is not supported at all. 39040 39041 -- Macro: DBX_CONTIN_LENGTH 39042 A symbol name in DBX-format debugging information is normally 39043 continued (split into two separate '.stabs' directives) when it 39044 exceeds a certain length (by default, 80 characters). On some 39045 operating systems, DBX requires this splitting; on others, 39046 splitting must not be done. You can inhibit splitting by defining 39047 this macro with the value zero. You can override the default 39048 splitting-length by defining this macro as an expression for the 39049 length you desire. 39050 39051 -- Macro: DBX_CONTIN_CHAR 39052 Normally continuation is indicated by adding a '\' character to the 39053 end of a '.stabs' string when a continuation follows. To use a 39054 different character instead, define this macro as a character 39055 constant for the character you want to use. Do not define this 39056 macro if backslash is correct for your system. 39057 39058 -- Macro: DBX_STATIC_STAB_DATA_SECTION 39059 Define this macro if it is necessary to go to the data section 39060 before outputting the '.stabs' pseudo-op for a non-global static 39061 variable. 39062 39063 -- Macro: DBX_TYPE_DECL_STABS_CODE 39064 The value to use in the "code" field of the '.stabs' directive for 39065 a typedef. The default is 'N_LSYM'. 39066 39067 -- Macro: DBX_STATIC_CONST_VAR_CODE 39068 The value to use in the "code" field of the '.stabs' directive for 39069 a static variable located in the text section. DBX format does not 39070 provide any "right" way to do this. The default is 'N_FUN'. 39071 39072 -- Macro: DBX_REGPARM_STABS_CODE 39073 The value to use in the "code" field of the '.stabs' directive for 39074 a parameter passed in registers. DBX format does not provide any 39075 "right" way to do this. The default is 'N_RSYM'. 39076 39077 -- Macro: DBX_REGPARM_STABS_LETTER 39078 The letter to use in DBX symbol data to identify a symbol as a 39079 parameter passed in registers. DBX format does not customarily 39080 provide any way to do this. The default is ''P''. 39081 39082 -- Macro: DBX_FUNCTION_FIRST 39083 Define this macro if the DBX information for a function and its 39084 arguments should precede the assembler code for the function. 39085 Normally, in DBX format, the debugging information entirely follows 39086 the assembler code. 39087 39088 -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE 39089 Define this macro, with value 1, if the value of a symbol 39090 describing the scope of a block ('N_LBRAC' or 'N_RBRAC') should be 39091 relative to the start of the enclosing function. Normally, GCC 39092 uses an absolute address. 39093 39094 -- Macro: DBX_LINES_FUNCTION_RELATIVE 39095 Define this macro, with value 1, if the value of a symbol 39096 indicating the current line number ('N_SLINE') should be relative 39097 to the start of the enclosing function. Normally, GCC uses an 39098 absolute address. 39099 39100 -- Macro: DBX_USE_BINCL 39101 Define this macro if GCC should generate 'N_BINCL' and 'N_EINCL' 39102 stabs for included header files, as on Sun systems. This macro 39103 also directs GCC to output a type number as a pair of a file number 39104 and a type number within the file. Normally, GCC does not generate 39105 'N_BINCL' or 'N_EINCL' stabs, and it outputs a single number for a 39106 type number. 39107 39108 39109File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info 39110 3911118.21.3 Open-Ended Hooks for DBX Format 39112--------------------------------------- 39113 39114These are hooks for DBX format. 39115 39116 -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER) 39117 A C statement to output DBX debugging information before code for 39118 line number LINE of the current source file to the stdio stream 39119 STREAM. COUNTER is the number of time the macro was invoked, 39120 including the current invocation; it is intended to generate unique 39121 labels in the assembly output. 39122 39123 This macro should not be defined if the default output is correct, 39124 or if it can be made correct by defining 39125 'DBX_LINES_FUNCTION_RELATIVE'. 39126 39127 -- Macro: NO_DBX_FUNCTION_END 39128 Some stabs encapsulation formats (in particular ECOFF), cannot 39129 handle the '.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx 39130 extension construct. On those machines, define this macro to turn 39131 this feature off without disturbing the rest of the gdb extensions. 39132 39133 -- Macro: NO_DBX_BNSYM_ENSYM 39134 Some assemblers cannot handle the '.stabd BNSYM/ENSYM,0,0' gdb dbx 39135 extension construct. On those machines, define this macro to turn 39136 this feature off without disturbing the rest of the gdb extensions. 39137 39138 39139File: gccint.info, Node: File Names and DBX, Next: DWARF, Prev: DBX Hooks, Up: Debugging Info 39140 3914118.21.4 File Names in DBX Format 39142-------------------------------- 39143 39144This describes file names in DBX format. 39145 39146 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME) 39147 A C statement to output DBX debugging information to the stdio 39148 stream STREAM, which indicates that file NAME is the main source 39149 file--the file specified as the input file for compilation. This 39150 macro is called only once, at the beginning of compilation. 39151 39152 This macro need not be defined if the standard form of output for 39153 DBX debugging information is appropriate. 39154 39155 It may be necessary to refer to a label equal to the beginning of 39156 the text section. You can use 'assemble_name (stream, 39157 ltext_label_name)' to do so. If you do this, you must also set the 39158 variable USED_LTEXT_LABEL_NAME to 'true'. 39159 39160 -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY 39161 Define this macro, with value 1, if GCC should not emit an 39162 indication of the current directory for compilation and current 39163 source language at the beginning of the file. 39164 39165 -- Macro: NO_DBX_GCC_MARKER 39166 Define this macro, with value 1, if GCC should not emit an 39167 indication that this object file was compiled by GCC. The default 39168 is to emit an 'N_OPT' stab at the beginning of every source file, 39169 with 'gcc2_compiled.' for the string and value 0. 39170 39171 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME) 39172 A C statement to output DBX debugging information at the end of 39173 compilation of the main source file NAME. Output should be written 39174 to the stdio stream STREAM. 39175 39176 If you don't define this macro, nothing special is output at the 39177 end of compilation, which is correct for most machines. 39178 39179 -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END 39180 Define this macro _instead of_ defining 39181 'DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at 39182 the end of compilation is an 'N_SO' stab with an empty string, 39183 whose value is the highest absolute text address in the file. 39184 39185 39186File: gccint.info, Node: DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info 39187 3918818.21.5 Macros for DWARF Output 39189------------------------------- 39190 39191Here are macros for DWARF output. 39192 39193 -- Macro: DWARF2_DEBUGGING_INFO 39194 Define this macro if GCC should produce dwarf version 2 format 39195 debugging output in response to the '-g' option. 39196 39197 -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (const_tree 39198 FUNCTION) 39199 Define this to enable the dwarf attribute 39200 'DW_AT_calling_convention' to be emitted for each function. 39201 Instead of an integer return the enum value for the 'DW_CC_' 39202 tag. 39203 39204 To support optional call frame debugging information, you must also 39205 define 'INCOMING_RETURN_ADDR_RTX' and either set 39206 'RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the 39207 prologue, or call 'dwarf2out_def_cfa' and 'dwarf2out_reg_save' as 39208 appropriate from 'TARGET_ASM_FUNCTION_PROLOGUE' if you don't. 39209 39210 -- Macro: DWARF2_FRAME_INFO 39211 Define this macro to a nonzero value if GCC should always output 39212 Dwarf 2 frame information. If 'TARGET_EXCEPT_UNWIND_INFO' (*note 39213 Exception Region Output::) returns 'UI_DWARF2', and exceptions are 39214 enabled, GCC will output this information not matter how you define 39215 'DWARF2_FRAME_INFO'. 39216 39217 -- Target Hook: enum unwind_info_type TARGET_DEBUG_UNWIND_INFO (void) 39218 This hook defines the mechanism that will be used for describing 39219 frame unwind information to the debugger. Normally the hook will 39220 return 'UI_DWARF2' if DWARF 2 debug information is enabled, and 39221 return 'UI_NONE' otherwise. 39222 39223 A target may return 'UI_DWARF2' even when DWARF 2 debug information 39224 is disabled in order to always output DWARF 2 frame information. 39225 39226 A target may return 'UI_TARGET' if it has ABI specified unwind 39227 tables. This will suppress generation of the normal debug frame 39228 unwind information. 39229 39230 -- Macro: DWARF2_ASM_LINE_DEBUG_INFO 39231 Define this macro to be a nonzero value if the assembler can 39232 generate Dwarf 2 line debug info sections. This will result in 39233 much more compact line number tables, and hence is desirable if it 39234 works. 39235 39236 -- Macro: DWARF2_ASM_VIEW_DEBUG_INFO 39237 Define this macro to be a nonzero value if the assembler supports 39238 view assignment and verification in '.loc'. If it does not, but 39239 the user enables location views, the compiler may have to fallback 39240 to internal line number tables. 39241 39242 -- Target Hook: int TARGET_RESET_LOCATION_VIEW (rtx_insn *) 39243 This hook, if defined, enables -ginternal-reset-location-views, and 39244 uses its result to override cases in which the estimated min insn 39245 length might be nonzero even when a PC advance (i.e., a view reset) 39246 cannot be taken for granted. 39247 39248 If the hook is defined, it must return a positive value to indicate 39249 the insn definitely advances the PC, and so the view number can be 39250 safely assumed to be reset; a negative value to mean the insn 39251 definitely does not advance the PC, and os the view number must not 39252 be reset; or zero to decide based on the estimated insn length. 39253 39254 If insn length is to be regarded as reliable, set the hook to 39255 'hook_int_rtx_insn_0'. 39256 39257 -- Target Hook: bool TARGET_WANT_DEBUG_PUB_SECTIONS 39258 True if the '.debug_pubtypes' and '.debug_pubnames' sections should 39259 be emitted. These sections are not used on most platforms, and in 39260 particular GDB does not use them. 39261 39262 -- Target Hook: bool TARGET_DELAY_SCHED2 39263 True if sched2 is not to be run at its normal place. This usually 39264 means it will be run as part of machine-specific reorg. 39265 39266 -- Target Hook: bool TARGET_DELAY_VARTRACK 39267 True if vartrack is not to be run at its normal place. This 39268 usually means it will be run as part of machine-specific reorg. 39269 39270 -- Target Hook: bool TARGET_NO_REGISTER_ALLOCATION 39271 True if register allocation and the passes following it should not 39272 be run. Usually true only for virtual assembler targets. 39273 39274 -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2) 39275 A C statement to issue assembly directives that create a difference 39276 LAB1 minus LAB2, using an integer of the given SIZE. 39277 39278 -- Macro: ASM_OUTPUT_DWARF_VMS_DELTA (STREAM, SIZE, LABEL1, LABEL2) 39279 A C statement to issue assembly directives that create a difference 39280 between the two given labels in system defined units, e.g. 39281 instruction slots on IA64 VMS, using an integer of the given size. 39282 39283 -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL, OFFSET, 39284 SECTION) 39285 A C statement to issue assembly directives that create a 39286 section-relative reference to the given LABEL plus OFFSET, using an 39287 integer of the given SIZE. The label is known to be defined in the 39288 given SECTION. 39289 39290 -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL) 39291 A C statement to issue assembly directives that create a 39292 self-relative reference to the given LABEL, using an integer of the 39293 given SIZE. 39294 39295 -- Macro: ASM_OUTPUT_DWARF_DATAREL (STREAM, SIZE, LABEL) 39296 A C statement to issue assembly directives that create a reference 39297 to the given LABEL relative to the dbase, using an integer of the 39298 given SIZE. 39299 39300 -- Macro: ASM_OUTPUT_DWARF_TABLE_REF (LABEL) 39301 A C statement to issue assembly directives that create a reference 39302 to the DWARF table identifier LABEL from the current section. This 39303 is used on some systems to avoid garbage collecting a DWARF table 39304 which is referenced by a function. 39305 39306 -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int 39307 SIZE, rtx X) 39308 If defined, this target hook is a function which outputs a 39309 DTP-relative reference to the given TLS symbol of the specified 39310 size. 39311 39312 39313File: gccint.info, Node: VMS Debug, Prev: DWARF, Up: Debugging Info 39314 3931518.21.6 Macros for VMS Debug Format 39316----------------------------------- 39317 39318Here are macros for VMS debug format. 39319 39320 -- Macro: VMS_DEBUGGING_INFO 39321 Define this macro if GCC should produce debugging output for VMS in 39322 response to the '-g' option. The default behavior for VMS is to 39323 generate minimal debug info for a traceback in the absence of '-g' 39324 unless explicitly overridden with '-g0'. This behavior is 39325 controlled by 'TARGET_OPTION_OPTIMIZATION' and 39326 'TARGET_OPTION_OVERRIDE'. 39327 39328 39329File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros 39330 3933118.22 Cross Compilation and Floating Point 39332========================================== 39333 39334While all modern machines use twos-complement representation for 39335integers, there are a variety of representations for floating point 39336numbers. This means that in a cross-compiler the representation of 39337floating point numbers in the compiled program may be different from 39338that used in the machine doing the compilation. 39339 39340 Because different representation systems may offer different amounts of 39341range and precision, all floating point constants must be represented in 39342the target machine's format. Therefore, the cross compiler cannot 39343safely use the host machine's floating point arithmetic; it must emulate 39344the target's arithmetic. To ensure consistency, GCC always uses 39345emulation to work with floating point values, even when the host and 39346target floating point formats are identical. 39347 39348 The following macros are provided by 'real.h' for the compiler to use. 39349All parts of the compiler which generate or optimize floating-point 39350calculations must use these macros. They may evaluate their operands 39351more than once, so operands must not have side effects. 39352 39353 -- Macro: REAL_VALUE_TYPE 39354 The C data type to be used to hold a floating point value in the 39355 target machine's format. Typically this is a 'struct' containing 39356 an array of 'HOST_WIDE_INT', but all code should treat it as an 39357 opaque quantity. 39358 39359 -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X) 39360 Truncates X to a signed integer, rounding toward zero. 39361 39362 -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX 39363 (REAL_VALUE_TYPE X) 39364 Truncates X to an unsigned integer, rounding toward zero. If X is 39365 negative, returns zero. 39366 39367 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, 39368 machine_mode MODE) 39369 Converts STRING into a floating point number in the target 39370 machine's representation for mode MODE. This routine can handle 39371 both decimal and hexadecimal floating point constants, using the 39372 syntax defined by the C language for both. 39373 39374 -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X) 39375 Returns 1 if X is negative (including negative zero), 0 otherwise. 39376 39377 -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X) 39378 Determines whether X represents infinity (positive or negative). 39379 39380 -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X) 39381 Determines whether X represents a "NaN" (not-a-number). 39382 39383 -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X) 39384 Returns the negative of the floating point value X. 39385 39386 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X) 39387 Returns the absolute value of X. 39388 39389 39390File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros 39391 3939218.23 Mode Switching Instructions 39393================================= 39394 39395The following macros control mode switching optimizations: 39396 39397 -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY) 39398 Define this macro if the port needs extra instructions inserted for 39399 mode switching in an optimizing compilation. 39400 39401 For an example, the SH4 can perform both single and double 39402 precision floating point operations, but to perform a single 39403 precision operation, the FPSCR PR bit has to be cleared, while for 39404 a double precision operation, this bit has to be set. Changing the 39405 PR bit requires a general purpose register as a scratch register, 39406 hence these FPSCR sets have to be inserted before reload, i.e. you 39407 cannot put this into instruction emitting or 39408 'TARGET_MACHINE_DEPENDENT_REORG'. 39409 39410 You can have multiple entities that are mode-switched, and select 39411 at run time which entities actually need it. 39412 'OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY that 39413 needs mode-switching. If you define this macro, you also have to 39414 define 'NUM_MODES_FOR_MODE_SWITCHING', 'TARGET_MODE_NEEDED', 39415 'TARGET_MODE_PRIORITY' and 'TARGET_MODE_EMIT'. 39416 'TARGET_MODE_AFTER', 'TARGET_MODE_ENTRY', and 'TARGET_MODE_EXIT' 39417 are optional. 39418 39419 -- Macro: NUM_MODES_FOR_MODE_SWITCHING 39420 If you define 'OPTIMIZE_MODE_SWITCHING', you have to define this as 39421 initializer for an array of integers. Each initializer element N 39422 refers to an entity that needs mode switching, and specifies the 39423 number of different modes that might need to be set for this 39424 entity. The position of the initializer in the 39425 initializer--starting counting at zero--determines the integer that 39426 is used to refer to the mode-switched entity in question. In 39427 macros that take mode arguments / yield a mode result, modes are 39428 represented as numbers 0 ... N - 1. N is used to specify that no 39429 mode switch is needed / supplied. 39430 39431 -- Target Hook: void TARGET_MODE_EMIT (int ENTITY, int MODE, int 39432 PREV_MODE, HARD_REG_SET REGS_LIVE) 39433 Generate one or more insns to set ENTITY to MODE. HARD_REG_LIVE is 39434 the set of hard registers live at the point where the insn(s) are 39435 to be inserted. PREV_MOXDE indicates the mode to switch from. 39436 Sets of a lower numbered entity will be emitted before sets of a 39437 higher numbered entity to a mode of the same or lower priority. 39438 39439 -- Target Hook: int TARGET_MODE_NEEDED (int ENTITY, rtx_insn *INSN) 39440 ENTITY is an integer specifying a mode-switched entity. If 39441 'OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to 39442 return an integer value not larger than the corresponding element 39443 in 'NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY 39444 must be switched into prior to the execution of INSN. 39445 39446 -- Target Hook: int TARGET_MODE_AFTER (int ENTITY, int MODE, rtx_insn 39447 *INSN) 39448 ENTITY is an integer specifying a mode-switched entity. If this 39449 macro is defined, it is evaluated for every INSN during mode 39450 switching. It determines the mode that an insn results in (if 39451 different from the incoming mode). 39452 39453 -- Target Hook: int TARGET_MODE_ENTRY (int ENTITY) 39454 If this macro is defined, it is evaluated for every ENTITY that 39455 needs mode switching. It should evaluate to an integer, which is a 39456 mode that ENTITY is assumed to be switched to at function entry. 39457 If 'TARGET_MODE_ENTRY' is defined then 'TARGET_MODE_EXIT' must be 39458 defined. 39459 39460 -- Target Hook: int TARGET_MODE_EXIT (int ENTITY) 39461 If this macro is defined, it is evaluated for every ENTITY that 39462 needs mode switching. It should evaluate to an integer, which is a 39463 mode that ENTITY is assumed to be switched to at function exit. If 39464 'TARGET_MODE_EXIT' is defined then 'TARGET_MODE_ENTRY' must be 39465 defined. 39466 39467 -- Target Hook: int TARGET_MODE_PRIORITY (int ENTITY, int N) 39468 This macro specifies the order in which modes for ENTITY are 39469 processed. 0 is the highest priority, 39470 'NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest. The value 39471 of the macro should be an integer designating a mode for ENTITY. 39472 For any fixed ENTITY, 'mode_priority' (ENTITY, N) shall be a 39473 bijection in 0 ... 'num_modes_for_mode_switching[ENTITY] - 1'. 39474 39475 39476File: gccint.info, Node: Target Attributes, Next: Emulated TLS, Prev: Mode Switching, Up: Target Macros 39477 3947818.24 Defining target-specific uses of '__attribute__' 39479====================================================== 39480 39481Target-specific attributes may be defined for functions, data and types. 39482These are described using the following target hooks; they also need to 39483be documented in 'extend.texi'. 39484 39485 -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE 39486 If defined, this target hook points to an array of 'struct 39487 attribute_spec' (defined in 'tree-core.h') specifying the machine 39488 specific attributes for this target and some of the restrictions on 39489 the entities to which these attributes are applied and the 39490 arguments they take. 39491 39492 -- Target Hook: bool TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P (const_tree 39493 NAME) 39494 If defined, this target hook is a function which returns true if 39495 the machine-specific attribute named NAME expects an identifier 39496 given as its first argument to be passed on as a plain identifier, 39497 not subjected to name lookup. If this is not defined, the default 39498 is false for all machine-specific attributes. 39499 39500 -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (const_tree TYPE1, 39501 const_tree TYPE2) 39502 If defined, this target hook is a function which returns zero if 39503 the attributes on TYPE1 and TYPE2 are incompatible, one if they are 39504 compatible, and two if they are nearly compatible (which causes a 39505 warning to be generated). If this is not defined, machine-specific 39506 attributes are supposed always to be compatible. 39507 39508 -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE) 39509 If defined, this target hook is a function which assigns default 39510 attributes to the newly defined TYPE. 39511 39512 -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree 39513 TYPE2) 39514 Define this target hook if the merging of type attributes needs 39515 special handling. If defined, the result is a list of the combined 39516 'TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that 39517 'comptypes' has already been called and returned 1. This function 39518 may call 'merge_attributes' to handle machine-independent merging. 39519 39520 -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree 39521 NEWDECL) 39522 Define this target hook if the merging of decl attributes needs 39523 special handling. If defined, the result is a list of the combined 39524 'DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate 39525 declaration of OLDDECL. Examples of when this is needed are when 39526 one attribute overrides another, or when an attribute is nullified 39527 by a subsequent definition. This function may call 39528 'merge_attributes' to handle machine-independent merging. 39529 39530 If the only target-specific handling you require is 'dllimport' for 39531 Microsoft Windows targets, you should define the macro 39532 'TARGET_DLLIMPORT_DECL_ATTRIBUTES' to '1'. The compiler will then 39533 define a function called 'merge_dllimport_decl_attributes' which 39534 can then be defined as the expansion of 39535 'TARGET_MERGE_DECL_ATTRIBUTES'. You can also add 39536 'handle_dll_attribute' in the attribute table for your port to 39537 perform initial processing of the 'dllimport' and 'dllexport' 39538 attributes. This is done in 'i386/cygwin.h' and 'i386/i386.c', for 39539 example. 39540 39541 -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (const_tree 39542 DECL) 39543 DECL is a variable or function with '__attribute__((dllimport))' 39544 specified. Use this hook if the target needs to add extra 39545 validation checks to 'handle_dll_attribute'. 39546 39547 -- Macro: TARGET_DECLSPEC 39548 Define this macro to a nonzero value if you want to treat 39549 '__declspec(X)' as equivalent to '__attribute((X))'. By default, 39550 this behavior is enabled only for targets that define 39551 'TARGET_DLLIMPORT_DECL_ATTRIBUTES'. The current implementation of 39552 '__declspec' is via a built-in macro, but you should not rely on 39553 this implementation detail. 39554 39555 -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree 39556 *ATTR_PTR) 39557 Define this target hook if you want to be able to add attributes to 39558 a decl when it is being created. This is normally useful for back 39559 ends which wish to implement a pragma by using the attributes which 39560 correspond to the pragma's effect. The NODE argument is the decl 39561 which is being created. The ATTR_PTR argument is a pointer to the 39562 attribute list for this decl. The list itself should not be 39563 modified, since it may be shared with other decls, but attributes 39564 may be chained on the head of the list and '*ATTR_PTR' modified to 39565 point to the new attributes, or a copy of the list may be made if 39566 further changes are needed. 39567 39568 -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (const_tree 39569 FNDECL) 39570 This target hook returns 'true' if it is OK to inline FNDECL into 39571 the current function, despite its having target-specific 39572 attributes, 'false' otherwise. By default, if a function has a 39573 target specific attribute attached to it, it will not be inlined. 39574 39575 -- Target Hook: bool TARGET_OPTION_VALID_ATTRIBUTE_P (tree FNDECL, tree 39576 NAME, tree ARGS, int FLAGS) 39577 This hook is called to parse 'attribute(target("..."))', which 39578 allows setting target-specific options on individual functions. 39579 These function-specific options may differ from the options 39580 specified on the command line. The hook should return 'true' if 39581 the options are valid. 39582 39583 The hook should set the 'DECL_FUNCTION_SPECIFIC_TARGET' field in 39584 the function declaration to hold a pointer to a target-specific 39585 'struct cl_target_option' structure. 39586 39587 -- Target Hook: void TARGET_OPTION_SAVE (struct cl_target_option *PTR, 39588 struct gcc_options *OPTS) 39589 This hook is called to save any additional target-specific 39590 information in the 'struct cl_target_option' structure for 39591 function-specific options from the 'struct gcc_options' structure. 39592 *Note Option file format::. 39593 39594 -- Target Hook: void TARGET_OPTION_RESTORE (struct gcc_options *OPTS, 39595 struct cl_target_option *PTR) 39596 This hook is called to restore any additional target-specific 39597 information in the 'struct cl_target_option' structure for 39598 function-specific options to the 'struct gcc_options' structure. 39599 39600 -- Target Hook: void TARGET_OPTION_POST_STREAM_IN (struct 39601 cl_target_option *PTR) 39602 This hook is called to update target-specific information in the 39603 'struct cl_target_option' structure after it is streamed in from 39604 LTO bytecode. 39605 39606 -- Target Hook: void TARGET_OPTION_PRINT (FILE *FILE, int INDENT, 39607 struct cl_target_option *PTR) 39608 This hook is called to print any additional target-specific 39609 information in the 'struct cl_target_option' structure for 39610 function-specific options. 39611 39612 -- Target Hook: bool TARGET_OPTION_PRAGMA_PARSE (tree ARGS, tree 39613 POP_TARGET) 39614 This target hook parses the options for '#pragma GCC target', which 39615 sets the target-specific options for functions that occur later in 39616 the input stream. The options accepted should be the same as those 39617 handled by the 'TARGET_OPTION_VALID_ATTRIBUTE_P' hook. 39618 39619 -- Target Hook: void TARGET_OPTION_OVERRIDE (void) 39620 Sometimes certain combinations of command options do not make sense 39621 on a particular target machine. You can override the hook 39622 'TARGET_OPTION_OVERRIDE' to take account of this. This hooks is 39623 called once just after all the command options have been parsed. 39624 39625 Don't use this hook to turn on various extra optimizations for 39626 '-O'. That is what 'TARGET_OPTION_OPTIMIZATION' is for. 39627 39628 If you need to do something whenever the optimization level is 39629 changed via the optimize attribute or pragma, see 39630 'TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE' 39631 39632 -- Target Hook: bool TARGET_OPTION_FUNCTION_VERSIONS (tree DECL1, tree 39633 DECL2) 39634 This target hook returns 'true' if DECL1 and DECL2 are versions of 39635 the same function. DECL1 and DECL2 are function versions if and 39636 only if they have the same function signature and different target 39637 specific attributes, that is, they are compiled for different 39638 target machines. 39639 39640 -- Target Hook: bool TARGET_CAN_INLINE_P (tree CALLER, tree CALLEE) 39641 This target hook returns 'false' if the CALLER function cannot 39642 inline CALLEE, based on target specific information. By default, 39643 inlining is not allowed if the callee function has function 39644 specific target options and the caller does not use the same 39645 options. 39646 39647 -- Target Hook: void TARGET_RELAYOUT_FUNCTION (tree FNDECL) 39648 This target hook fixes function FNDECL after attributes are 39649 processed. Default does nothing. On ARM, the default function's 39650 alignment is updated with the attribute target. 39651 39652 39653File: gccint.info, Node: Emulated TLS, Next: MIPS Coprocessors, Prev: Target Attributes, Up: Target Macros 39654 3965518.25 Emulating TLS 39656=================== 39657 39658For targets whose psABI does not provide Thread Local Storage via 39659specific relocations and instruction sequences, an emulation layer is 39660used. A set of target hooks allows this emulation layer to be 39661configured for the requirements of a particular target. For instance 39662the psABI may in fact specify TLS support in terms of an emulation 39663layer. 39664 39665 The emulation layer works by creating a control object for every TLS 39666object. To access the TLS object, a lookup function is provided which, 39667when given the address of the control object, will return the address of 39668the current thread's instance of the TLS object. 39669 39670 -- Target Hook: const char * TARGET_EMUTLS_GET_ADDRESS 39671 Contains the name of the helper function that uses a TLS control 39672 object to locate a TLS instance. The default causes libgcc's 39673 emulated TLS helper function to be used. 39674 39675 -- Target Hook: const char * TARGET_EMUTLS_REGISTER_COMMON 39676 Contains the name of the helper function that should be used at 39677 program startup to register TLS objects that are implicitly 39678 initialized to zero. If this is 'NULL', all TLS objects will have 39679 explicit initializers. The default causes libgcc's emulated TLS 39680 registration function to be used. 39681 39682 -- Target Hook: const char * TARGET_EMUTLS_VAR_SECTION 39683 Contains the name of the section in which TLS control variables 39684 should be placed. The default of 'NULL' allows these to be placed 39685 in any section. 39686 39687 -- Target Hook: const char * TARGET_EMUTLS_TMPL_SECTION 39688 Contains the name of the section in which TLS initializers should 39689 be placed. The default of 'NULL' allows these to be placed in any 39690 section. 39691 39692 -- Target Hook: const char * TARGET_EMUTLS_VAR_PREFIX 39693 Contains the prefix to be prepended to TLS control variable names. 39694 The default of 'NULL' uses a target-specific prefix. 39695 39696 -- Target Hook: const char * TARGET_EMUTLS_TMPL_PREFIX 39697 Contains the prefix to be prepended to TLS initializer objects. 39698 The default of 'NULL' uses a target-specific prefix. 39699 39700 -- Target Hook: tree TARGET_EMUTLS_VAR_FIELDS (tree TYPE, tree *NAME) 39701 Specifies a function that generates the FIELD_DECLs for a TLS 39702 control object type. TYPE is the RECORD_TYPE the fields are for 39703 and NAME should be filled with the structure tag, if the default of 39704 '__emutls_object' is unsuitable. The default creates a type 39705 suitable for libgcc's emulated TLS function. 39706 39707 -- Target Hook: tree TARGET_EMUTLS_VAR_INIT (tree VAR, tree DECL, tree 39708 TMPL_ADDR) 39709 Specifies a function that generates the CONSTRUCTOR to initialize a 39710 TLS control object. VAR is the TLS control object, DECL is the TLS 39711 object and TMPL_ADDR is the address of the initializer. The 39712 default initializes libgcc's emulated TLS control object. 39713 39714 -- Target Hook: bool TARGET_EMUTLS_VAR_ALIGN_FIXED 39715 Specifies whether the alignment of TLS control variable objects is 39716 fixed and should not be increased as some backends may do to 39717 optimize single objects. The default is false. 39718 39719 -- Target Hook: bool TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS 39720 Specifies whether a DWARF 'DW_OP_form_tls_address' location 39721 descriptor may be used to describe emulated TLS control objects. 39722 39723 39724File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Emulated TLS, Up: Target Macros 39725 3972618.26 Defining coprocessor specifics for MIPS targets. 39727====================================================== 39728 39729The MIPS specification allows MIPS implementations to have as many as 4 39730coprocessors, each with as many as 32 private registers. GCC supports 39731accessing these registers and transferring values between the registers 39732and memory using asm-ized variables. For example: 39733 39734 register unsigned int cp0count asm ("c0r1"); 39735 unsigned int d; 39736 39737 d = cp0count + 3; 39738 39739 ("c0r1" is the default name of register 1 in coprocessor 0; alternate 39740names may be added as described below, or the default names may be 39741overridden entirely in 'SUBTARGET_CONDITIONAL_REGISTER_USAGE'.) 39742 39743 Coprocessor registers are assumed to be epilogue-used; sets to them 39744will be preserved even if it does not appear that the register is used 39745again later in the function. 39746 39747 Another note: according to the MIPS spec, coprocessor 1 (if present) is 39748the FPU. One accesses COP1 registers through standard mips 39749floating-point support; they are not included in this mechanism. 39750 39751 39752File: gccint.info, Node: PCH Target, Next: C++ ABI, Prev: MIPS Coprocessors, Up: Target Macros 39753 3975418.27 Parameters for Precompiled Header Validity Checking 39755========================================================= 39756 39757 -- Target Hook: void * TARGET_GET_PCH_VALIDITY (size_t *SZ) 39758 This hook returns a pointer to the data needed by 39759 'TARGET_PCH_VALID_P' and sets '*SZ' to the size of the data in 39760 bytes. 39761 39762 -- Target Hook: const char * TARGET_PCH_VALID_P (const void *DATA, 39763 size_t SZ) 39764 This hook checks whether the options used to create a PCH file are 39765 compatible with the current settings. It returns 'NULL' if so and 39766 a suitable error message if not. Error messages will be presented 39767 to the user and must be localized using '_(MSG)'. 39768 39769 DATA is the data that was returned by 'TARGET_GET_PCH_VALIDITY' 39770 when the PCH file was created and SZ is the size of that data in 39771 bytes. It's safe to assume that the data was created by the same 39772 version of the compiler, so no format checking is needed. 39773 39774 The default definition of 'default_pch_valid_p' should be suitable 39775 for most targets. 39776 39777 -- Target Hook: const char * TARGET_CHECK_PCH_TARGET_FLAGS (int 39778 PCH_FLAGS) 39779 If this hook is nonnull, the default implementation of 39780 'TARGET_PCH_VALID_P' will use it to check for compatible values of 39781 'target_flags'. PCH_FLAGS specifies the value that 'target_flags' 39782 had when the PCH file was created. The return value is the same as 39783 for 'TARGET_PCH_VALID_P'. 39784 39785 -- Target Hook: void TARGET_PREPARE_PCH_SAVE (void) 39786 Called before writing out a PCH file. If the target has some 39787 garbage-collected data that needs to be in a particular state on 39788 PCH loads, it can use this hook to enforce that state. Very few 39789 targets need to do anything here. 39790 39791 39792File: gccint.info, Node: C++ ABI, Next: Named Address Spaces, Prev: PCH Target, Up: Target Macros 39793 3979418.28 C++ ABI parameters 39795======================== 39796 39797 -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void) 39798 Define this hook to override the integer type used for guard 39799 variables. These are used to implement one-time construction of 39800 static objects. The default is long_long_integer_type_node. 39801 39802 -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void) 39803 This hook determines how guard variables are used. It should 39804 return 'false' (the default) if the first byte should be used. A 39805 return value of 'true' indicates that only the least significant 39806 bit should be used. 39807 39808 -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE) 39809 This hook returns the size of the cookie to use when allocating an 39810 array whose elements have the indicated TYPE. Assumes that it is 39811 already known that a cookie is needed. The default is 'max(sizeof 39812 (size_t), alignof(type))', as defined in section 2.7 of the 39813 IA64/Generic C++ ABI. 39814 39815 -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void) 39816 This hook should return 'true' if the element size should be stored 39817 in array cookies. The default is to return 'false'. 39818 39819 -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int 39820 IMPORT_EXPORT) 39821 If defined by a backend this hook allows the decision made to 39822 export class TYPE to be overruled. Upon entry IMPORT_EXPORT will 39823 contain 1 if the class is going to be exported, -1 if it is going 39824 to be imported and 0 otherwise. This function should return the 39825 modified value and perform any other actions necessary to support 39826 the backend's targeted operating system. 39827 39828 -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void) 39829 This hook should return 'true' if constructors and destructors 39830 return the address of the object created/destroyed. The default is 39831 to return 'false'. 39832 39833 -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void) 39834 This hook returns true if the key method for a class (i.e., the 39835 method which, if defined in the current translation unit, causes 39836 the virtual table to be emitted) may be an inline function. Under 39837 the standard Itanium C++ ABI the key method may be an inline 39838 function so long as the function is not declared inline in the 39839 class definition. Under some variants of the ABI, an inline 39840 function can never be the key method. The default is to return 39841 'true'. 39842 39843 -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree 39844 DECL) 39845 DECL is a virtual table, virtual table table, typeinfo object, or 39846 other similar implicit class data object that will be emitted with 39847 external linkage in this translation unit. No ELF visibility has 39848 been explicitly specified. If the target needs to specify a 39849 visibility other than that of the containing class, use this hook 39850 to set 'DECL_VISIBILITY' and 'DECL_VISIBILITY_SPECIFIED'. 39851 39852 -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void) 39853 This hook returns true (the default) if virtual tables and other 39854 similar implicit class data objects are always COMDAT if they have 39855 external linkage. If this hook returns false, then class data for 39856 classes whose virtual table will be emitted in only one translation 39857 unit will not be COMDAT. 39858 39859 -- Target Hook: bool TARGET_CXX_LIBRARY_RTTI_COMDAT (void) 39860 This hook returns true (the default) if the RTTI information for 39861 the basic types which is defined in the C++ runtime should always 39862 be COMDAT, false if it should not be COMDAT. 39863 39864 -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void) 39865 This hook returns true if '__aeabi_atexit' (as defined by the ARM 39866 EABI) should be used to register static destructors when 39867 '-fuse-cxa-atexit' is in effect. The default is to return false to 39868 use '__cxa_atexit'. 39869 39870 -- Target Hook: bool TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT (void) 39871 This hook returns true if the target 'atexit' function can be used 39872 in the same manner as '__cxa_atexit' to register C++ static 39873 destructors. This requires that 'atexit'-registered functions in 39874 shared libraries are run in the correct order when the libraries 39875 are unloaded. The default is to return false. 39876 39877 -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE) 39878 TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has just 39879 been defined. Use this hook to make adjustments to the class (eg, 39880 tweak visibility or perform any other required target 39881 modifications). 39882 39883 -- Target Hook: tree TARGET_CXX_DECL_MANGLING_CONTEXT (const_tree DECL) 39884 Return target-specific mangling context of DECL or 'NULL_TREE'. 39885 39886 39887File: gccint.info, Node: Named Address Spaces, Next: Misc, Prev: C++ ABI, Up: Target Macros 39888 3988918.29 Adding support for named address spaces 39890============================================= 39891 39892The draft technical report of the ISO/IEC JTC1 S22 WG14 N1275 standards 39893committee, 'Programming Languages - C - Extensions to support embedded 39894processors', specifies a syntax for embedded processors to specify 39895alternate address spaces. You can configure a GCC port to support 39896section 5.1 of the draft report to add support for address spaces other 39897than the default address space. These address spaces are new keywords 39898that are similar to the 'volatile' and 'const' type attributes. 39899 39900 Pointers to named address spaces can have a different size than 39901pointers to the generic address space. 39902 39903 For example, the SPU port uses the '__ea' address space to refer to 39904memory in the host processor, rather than memory local to the SPU 39905processor. Access to memory in the '__ea' address space involves 39906issuing DMA operations to move data between the host processor and the 39907local processor memory address space. Pointers in the '__ea' address 39908space are either 32 bits or 64 bits based on the '-mea32' or '-mea64' 39909switches (native SPU pointers are always 32 bits). 39910 39911 Internally, address spaces are represented as a small integer in the 39912range 0 to 15 with address space 0 being reserved for the generic 39913address space. 39914 39915 To register a named address space qualifier keyword with the C front 39916end, the target may call the 'c_register_addr_space' routine. For 39917example, the SPU port uses the following to declare '__ea' as the 39918keyword for named address space #1: 39919 #define ADDR_SPACE_EA 1 39920 c_register_addr_space ("__ea", ADDR_SPACE_EA); 39921 39922 -- Target Hook: scalar_int_mode TARGET_ADDR_SPACE_POINTER_MODE 39923 (addr_space_t ADDRESS_SPACE) 39924 Define this to return the machine mode to use for pointers to 39925 ADDRESS_SPACE if the target supports named address spaces. The 39926 default version of this hook returns 'ptr_mode'. 39927 39928 -- Target Hook: scalar_int_mode TARGET_ADDR_SPACE_ADDRESS_MODE 39929 (addr_space_t ADDRESS_SPACE) 39930 Define this to return the machine mode to use for addresses in 39931 ADDRESS_SPACE if the target supports named address spaces. The 39932 default version of this hook returns 'Pmode'. 39933 39934 -- Target Hook: bool TARGET_ADDR_SPACE_VALID_POINTER_MODE 39935 (scalar_int_mode MODE, addr_space_t AS) 39936 Define this to return nonzero if the port can handle pointers with 39937 machine mode MODE to address space AS. This target hook is the 39938 same as the 'TARGET_VALID_POINTER_MODE' target hook, except that it 39939 includes explicit named address space support. The default version 39940 of this hook returns true for the modes returned by either the 39941 'TARGET_ADDR_SPACE_POINTER_MODE' or 39942 'TARGET_ADDR_SPACE_ADDRESS_MODE' target hooks for the given address 39943 space. 39944 39945 -- Target Hook: bool TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P 39946 (machine_mode MODE, rtx EXP, bool STRICT, addr_space_t AS) 39947 Define this to return true if EXP is a valid address for mode MODE 39948 in the named address space AS. The STRICT parameter says whether 39949 strict addressing is in effect after reload has finished. This 39950 target hook is the same as the 'TARGET_LEGITIMATE_ADDRESS_P' target 39951 hook, except that it includes explicit named address space support. 39952 39953 -- Target Hook: rtx TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS (rtx X, rtx 39954 OLDX, machine_mode MODE, addr_space_t AS) 39955 Define this to modify an invalid address X to be a valid address 39956 with mode MODE in the named address space AS. This target hook is 39957 the same as the 'TARGET_LEGITIMIZE_ADDRESS' target hook, except 39958 that it includes explicit named address space support. 39959 39960 -- Target Hook: bool TARGET_ADDR_SPACE_SUBSET_P (addr_space_t SUBSET, 39961 addr_space_t SUPERSET) 39962 Define this to return whether the SUBSET named address space is 39963 contained within the SUPERSET named address space. Pointers to a 39964 named address space that is a subset of another named address space 39965 will be converted automatically without a cast if used together in 39966 arithmetic operations. Pointers to a superset address space can be 39967 converted to pointers to a subset address space via explicit casts. 39968 39969 -- Target Hook: bool TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID (addr_space_t 39970 AS) 39971 Define this to modify the default handling of address 0 for the 39972 address space. Return true if 0 should be considered a valid 39973 address. 39974 39975 -- Target Hook: rtx TARGET_ADDR_SPACE_CONVERT (rtx OP, tree FROM_TYPE, 39976 tree TO_TYPE) 39977 Define this to convert the pointer expression represented by the 39978 RTL OP with type FROM_TYPE that points to a named address space to 39979 a new pointer expression with type TO_TYPE that points to a 39980 different named address space. When this hook it called, it is 39981 guaranteed that one of the two address spaces is a subset of the 39982 other, as determined by the 'TARGET_ADDR_SPACE_SUBSET_P' target 39983 hook. 39984 39985 -- Target Hook: int TARGET_ADDR_SPACE_DEBUG (addr_space_t AS) 39986 Define this to define how the address space is encoded in dwarf. 39987 The result is the value to be used with 'DW_AT_address_class'. 39988 39989 -- Target Hook: void TARGET_ADDR_SPACE_DIAGNOSE_USAGE (addr_space_t AS, 39990 location_t LOC) 39991 Define this hook if the availability of an address space depends on 39992 command line options and some diagnostics should be printed when 39993 the address space is used. This hook is called during parsing and 39994 allows to emit a better diagnostic compared to the case where the 39995 address space was not registered with 'c_register_addr_space'. AS 39996 is the address space as registered with 'c_register_addr_space'. 39997 LOC is the location of the address space qualifier token. The 39998 default implementation does nothing. 39999 40000 40001File: gccint.info, Node: Misc, Prev: Named Address Spaces, Up: Target Macros 40002 4000318.30 Miscellaneous Parameters 40004============================== 40005 40006Here are several miscellaneous parameters. 40007 40008 -- Macro: HAS_LONG_COND_BRANCH 40009 Define this boolean macro to indicate whether or not your 40010 architecture has conditional branches that can span all of memory. 40011 It is used in conjunction with an optimization that partitions hot 40012 and cold basic blocks into separate sections of the executable. If 40013 this macro is set to false, gcc will convert any conditional 40014 branches that attempt to cross between sections into unconditional 40015 branches or indirect jumps. 40016 40017 -- Macro: HAS_LONG_UNCOND_BRANCH 40018 Define this boolean macro to indicate whether or not your 40019 architecture has unconditional branches that can span all of 40020 memory. It is used in conjunction with an optimization that 40021 partitions hot and cold basic blocks into separate sections of the 40022 executable. If this macro is set to false, gcc will convert any 40023 unconditional branches that attempt to cross between sections into 40024 indirect jumps. 40025 40026 -- Macro: CASE_VECTOR_MODE 40027 An alias for a machine mode name. This is the machine mode that 40028 elements of a jump-table should have. 40029 40030 -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY) 40031 Optional: return the preferred mode for an 'addr_diff_vec' when the 40032 minimum and maximum offset are known. If you define this, it 40033 enables extra code in branch shortening to deal with 40034 'addr_diff_vec'. To make this work, you also have to define 40035 'INSN_ALIGN' and make the alignment for 'addr_diff_vec' explicit. 40036 The BODY argument is provided so that the offset_unsigned and scale 40037 flags can be updated. 40038 40039 -- Macro: CASE_VECTOR_PC_RELATIVE 40040 Define this macro to be a C expression to indicate when jump-tables 40041 should contain relative addresses. You need not define this macro 40042 if jump-tables never contain relative addresses, or jump-tables 40043 should contain relative addresses only when '-fPIC' or '-fPIC' is 40044 in effect. 40045 40046 -- Target Hook: unsigned int TARGET_CASE_VALUES_THRESHOLD (void) 40047 This function return the smallest number of different values for 40048 which it is best to use a jump-table instead of a tree of 40049 conditional branches. The default is four for machines with a 40050 'casesi' instruction and five otherwise. This is best for most 40051 machines. 40052 40053 -- Macro: WORD_REGISTER_OPERATIONS 40054 Define this macro to 1 if operations between registers with 40055 integral mode smaller than a word are always performed on the 40056 entire register. To be more explicit, if you start with a pair of 40057 'word_mode' registers with known values and you do a subword, for 40058 example 'QImode', addition on the low part of the registers, then 40059 the compiler may consider that the result has a known value in 40060 'word_mode' too if the macro is defined to 1. Most RISC machines 40061 have this property and most CISC machines do not. 40062 40063 -- Target Hook: unsigned int TARGET_MIN_ARITHMETIC_PRECISION (void) 40064 On some RISC architectures with 64-bit registers, the processor 40065 also maintains 32-bit condition codes that make it possible to do 40066 real 32-bit arithmetic, although the operations are performed on 40067 the full registers. 40068 40069 On such architectures, defining this hook to 32 tells the compiler 40070 to try using 32-bit arithmetical operations setting the condition 40071 codes instead of doing full 64-bit arithmetic. 40072 40073 More generally, define this hook on RISC architectures if you want 40074 the compiler to try using arithmetical operations setting the 40075 condition codes with a precision lower than the word precision. 40076 40077 You need not define this hook if 'WORD_REGISTER_OPERATIONS' is not 40078 defined to 1. 40079 40080 -- Macro: LOAD_EXTEND_OP (MEM_MODE) 40081 Define this macro to be a C expression indicating when insns that 40082 read memory in MEM_MODE, an integral mode narrower than a word, set 40083 the bits outside of MEM_MODE to be either the sign-extension or the 40084 zero-extension of the data read. Return 'SIGN_EXTEND' for values 40085 of MEM_MODE for which the insn sign-extends, 'ZERO_EXTEND' for 40086 which it zero-extends, and 'UNKNOWN' for other modes. 40087 40088 This macro is not called with MEM_MODE non-integral or with a width 40089 greater than or equal to 'BITS_PER_WORD', so you may return any 40090 value in this case. Do not define this macro if it would always 40091 return 'UNKNOWN'. On machines where this macro is defined, you 40092 will normally define it as the constant 'SIGN_EXTEND' or 40093 'ZERO_EXTEND'. 40094 40095 You may return a non-'UNKNOWN' value even if for some hard 40096 registers the sign extension is not performed, if for the 40097 'REGNO_REG_CLASS' of these hard registers 40098 'TARGET_CAN_CHANGE_MODE_CLASS' returns false when the FROM mode is 40099 MEM_MODE and the TO mode is any integral mode larger than this but 40100 not larger than 'word_mode'. 40101 40102 You must return 'UNKNOWN' if for some hard registers that allow 40103 this mode, 'TARGET_CAN_CHANGE_MODE_CLASS' says that they cannot 40104 change to 'word_mode', but that they can change to another integral 40105 mode that is larger then MEM_MODE but still smaller than 40106 'word_mode'. 40107 40108 -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND 40109 Define this macro to 1 if loading short immediate values into 40110 registers sign extends. 40111 40112 -- Target Hook: unsigned int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL 40113 (machine_mode MODE) 40114 When '-ffast-math' is in effect, GCC tries to optimize divisions by 40115 the same divisor, by turning them into multiplications by the 40116 reciprocal. This target hook specifies the minimum number of 40117 divisions that should be there for GCC to perform the optimization 40118 for a variable of mode MODE. The default implementation returns 3 40119 if the machine has an instruction for the division, and 2 if it 40120 does not. 40121 40122 -- Macro: MOVE_MAX 40123 The maximum number of bytes that a single instruction can move 40124 quickly between memory and registers or between two memory 40125 locations. 40126 40127 -- Macro: MAX_MOVE_MAX 40128 The maximum number of bytes that a single instruction can move 40129 quickly between memory and registers or between two memory 40130 locations. If this is undefined, the default is 'MOVE_MAX'. 40131 Otherwise, it is the constant value that is the largest value that 40132 'MOVE_MAX' can have at run-time. 40133 40134 -- Macro: SHIFT_COUNT_TRUNCATED 40135 A C expression that is nonzero if on this machine the number of 40136 bits actually used for the count of a shift operation is equal to 40137 the number of bits needed to represent the size of the object being 40138 shifted. When this macro is nonzero, the compiler will assume that 40139 it is safe to omit a sign-extend, zero-extend, and certain bitwise 40140 'and' instructions that truncates the count of a shift operation. 40141 On machines that have instructions that act on bit-fields at 40142 variable positions, which may include 'bit test' instructions, a 40143 nonzero 'SHIFT_COUNT_TRUNCATED' also enables deletion of 40144 truncations of the values that serve as arguments to bit-field 40145 instructions. 40146 40147 If both types of instructions truncate the count (for shifts) and 40148 position (for bit-field operations), or if no variable-position 40149 bit-field instructions exist, you should define this macro. 40150 40151 However, on some machines, such as the 80386 and the 680x0, 40152 truncation only applies to shift operations and not the (real or 40153 pretended) bit-field operations. Define 'SHIFT_COUNT_TRUNCATED' to 40154 be zero on such machines. Instead, add patterns to the 'md' file 40155 that include the implied truncation of the shift instructions. 40156 40157 You need not define this macro if it would always have the value of 40158 zero. 40159 40160 -- Target Hook: unsigned HOST_WIDE_INT TARGET_SHIFT_TRUNCATION_MASK 40161 (machine_mode MODE) 40162 This function describes how the standard shift patterns for MODE 40163 deal with shifts by negative amounts or by more than the width of 40164 the mode. *Note shift patterns::. 40165 40166 On many machines, the shift patterns will apply a mask M to the 40167 shift count, meaning that a fixed-width shift of X by Y is 40168 equivalent to an arbitrary-width shift of X by Y & M. If this is 40169 true for mode MODE, the function should return M, otherwise it 40170 should return 0. A return value of 0 indicates that no particular 40171 behavior is guaranteed. 40172 40173 Note that, unlike 'SHIFT_COUNT_TRUNCATED', this function does _not_ 40174 apply to general shift rtxes; it applies only to instructions that 40175 are generated by the named shift patterns. 40176 40177 The default implementation of this function returns 40178 'GET_MODE_BITSIZE (MODE) - 1' if 'SHIFT_COUNT_TRUNCATED' and 0 40179 otherwise. This definition is always safe, but if 40180 'SHIFT_COUNT_TRUNCATED' is false, and some shift patterns 40181 nevertheless truncate the shift count, you may get better code by 40182 overriding it. 40183 40184 -- Target Hook: bool TARGET_TRULY_NOOP_TRUNCATION (poly_uint64 OUTPREC, 40185 poly_uint64 INPREC) 40186 This hook returns true if it is safe to "convert" a value of INPREC 40187 bits to one of OUTPREC bits (where OUTPREC is smaller than INPREC) 40188 by merely operating on it as if it had only OUTPREC bits. The 40189 default returns true unconditionally, which is correct for most 40190 machines. 40191 40192 If 'TARGET_MODES_TIEABLE_P' returns false for a pair of modes, 40193 suboptimal code can result if this hook returns true for the 40194 corresponding mode sizes. Making this hook return false in such 40195 cases may improve things. 40196 40197 -- Target Hook: int TARGET_MODE_REP_EXTENDED (scalar_int_mode MODE, 40198 scalar_int_mode REP_MODE) 40199 The representation of an integral mode can be such that the values 40200 are always extended to a wider integral mode. Return 'SIGN_EXTEND' 40201 if values of MODE are represented in sign-extended form to 40202 REP_MODE. Return 'UNKNOWN' otherwise. (Currently, none of the 40203 targets use zero-extended representation this way so unlike 40204 'LOAD_EXTEND_OP', 'TARGET_MODE_REP_EXTENDED' is expected to return 40205 either 'SIGN_EXTEND' or 'UNKNOWN'. Also no target extends MODE to 40206 REP_MODE so that REP_MODE is not the next widest integral mode and 40207 currently we take advantage of this fact.) 40208 40209 Similarly to 'LOAD_EXTEND_OP' you may return a non-'UNKNOWN' value 40210 even if the extension is not performed on certain hard registers as 40211 long as for the 'REGNO_REG_CLASS' of these hard registers 40212 'TARGET_CAN_CHANGE_MODE_CLASS' returns false. 40213 40214 Note that 'TARGET_MODE_REP_EXTENDED' and 'LOAD_EXTEND_OP' describe 40215 two related properties. If you define 'TARGET_MODE_REP_EXTENDED 40216 (mode, word_mode)' you probably also want to define 'LOAD_EXTEND_OP 40217 (mode)' to return the same type of extension. 40218 40219 In order to enforce the representation of 'mode', 40220 'TARGET_TRULY_NOOP_TRUNCATION' should return false when truncating 40221 to 'mode'. 40222 40223 -- Macro: STORE_FLAG_VALUE 40224 A C expression describing the value returned by a comparison 40225 operator with an integral mode and stored by a store-flag 40226 instruction ('cstoreMODE4') when the condition is true. This 40227 description must apply to _all_ the 'cstoreMODE4' patterns and all 40228 the comparison operators whose results have a 'MODE_INT' mode. 40229 40230 A value of 1 or -1 means that the instruction implementing the 40231 comparison operator returns exactly 1 or -1 when the comparison is 40232 true and 0 when the comparison is false. Otherwise, the value 40233 indicates which bits of the result are guaranteed to be 1 when the 40234 comparison is true. This value is interpreted in the mode of the 40235 comparison operation, which is given by the mode of the first 40236 operand in the 'cstoreMODE4' pattern. Either the low bit or the 40237 sign bit of 'STORE_FLAG_VALUE' be on. Presently, only those bits 40238 are used by the compiler. 40239 40240 If 'STORE_FLAG_VALUE' is neither 1 or -1, the compiler will 40241 generate code that depends only on the specified bits. It can also 40242 replace comparison operators with equivalent operations if they 40243 cause the required bits to be set, even if the remaining bits are 40244 undefined. For example, on a machine whose comparison operators 40245 return an 'SImode' value and where 'STORE_FLAG_VALUE' is defined as 40246 '0x80000000', saying that just the sign bit is relevant, the 40247 expression 40248 40249 (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0)) 40250 40251 can be converted to 40252 40253 (ashift:SI X (const_int N)) 40254 40255 where N is the appropriate shift count to move the bit being tested 40256 into the sign bit. 40257 40258 There is no way to describe a machine that always sets the 40259 low-order bit for a true value, but does not guarantee the value of 40260 any other bits, but we do not know of any machine that has such an 40261 instruction. If you are trying to port GCC to such a machine, 40262 include an instruction to perform a logical-and of the result with 40263 1 in the pattern for the comparison operators and let us know at 40264 <gcc@gcc.gnu.org>. 40265 40266 Often, a machine will have multiple instructions that obtain a 40267 value from a comparison (or the condition codes). Here are rules 40268 to guide the choice of value for 'STORE_FLAG_VALUE', and hence the 40269 instructions to be used: 40270 40271 * Use the shortest sequence that yields a valid definition for 40272 'STORE_FLAG_VALUE'. It is more efficient for the compiler to 40273 "normalize" the value (convert it to, e.g., 1 or 0) than for 40274 the comparison operators to do so because there may be 40275 opportunities to combine the normalization with other 40276 operations. 40277 40278 * For equal-length sequences, use a value of 1 or -1, with -1 40279 being slightly preferred on machines with expensive jumps and 40280 1 preferred on other machines. 40281 40282 * As a second choice, choose a value of '0x80000001' if 40283 instructions exist that set both the sign and low-order bits 40284 but do not define the others. 40285 40286 * Otherwise, use a value of '0x80000000'. 40287 40288 Many machines can produce both the value chosen for 40289 'STORE_FLAG_VALUE' and its negation in the same number of 40290 instructions. On those machines, you should also define a pattern 40291 for those cases, e.g., one matching 40292 40293 (set A (neg:M (ne:M B C))) 40294 40295 Some machines can also perform 'and' or 'plus' operations on 40296 condition code values with less instructions than the corresponding 40297 'cstoreMODE4' insn followed by 'and' or 'plus'. On those machines, 40298 define the appropriate patterns. Use the names 'incscc' and 40299 'decscc', respectively, for the patterns which perform 'plus' or 40300 'minus' operations on condition code values. See 'rs6000.md' for 40301 some examples. The GNU Superoptimizer can be used to find such 40302 instruction sequences on other machines. 40303 40304 If this macro is not defined, the default value, 1, is used. You 40305 need not define 'STORE_FLAG_VALUE' if the machine has no store-flag 40306 instructions, or if the value generated by these instructions is 1. 40307 40308 -- Macro: FLOAT_STORE_FLAG_VALUE (MODE) 40309 A C expression that gives a nonzero 'REAL_VALUE_TYPE' value that is 40310 returned when comparison operators with floating-point results are 40311 true. Define this macro on machines that have comparison 40312 operations that return floating-point values. If there are no such 40313 operations, do not define this macro. 40314 40315 -- Macro: VECTOR_STORE_FLAG_VALUE (MODE) 40316 A C expression that gives a rtx representing the nonzero true 40317 element for vector comparisons. The returned rtx should be valid 40318 for the inner mode of MODE which is guaranteed to be a vector mode. 40319 Define this macro on machines that have vector comparison 40320 operations that return a vector result. If there are no such 40321 operations, do not define this macro. Typically, this macro is 40322 defined as 'const1_rtx' or 'constm1_rtx'. This macro may return 40323 'NULL_RTX' to prevent the compiler optimizing such vector 40324 comparison operations for the given mode. 40325 40326 -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 40327 -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 40328 A C expression that indicates whether the architecture defines a 40329 value for 'clz' or 'ctz' with a zero operand. A result of '0' 40330 indicates the value is undefined. If the value is defined for only 40331 the RTL expression, the macro should evaluate to '1'; if the value 40332 applies also to the corresponding optab entry (which is normally 40333 the case if it expands directly into the corresponding RTL), then 40334 the macro should evaluate to '2'. In the cases where the value is 40335 defined, VALUE should be set to this value. 40336 40337 If this macro is not defined, the value of 'clz' or 'ctz' at zero 40338 is assumed to be undefined. 40339 40340 This macro must be defined if the target's expansion for 'ffs' 40341 relies on a particular value to get correct results. Otherwise it 40342 is not necessary, though it may be used to optimize some corner 40343 cases, and to provide a default expansion for the 'ffs' optab. 40344 40345 Note that regardless of this macro the "definedness" of 'clz' and 40346 'ctz' at zero do _not_ extend to the builtin functions visible to 40347 the user. Thus one may be free to adjust the value at will to 40348 match the target expansion of these operations without fear of 40349 breaking the API. 40350 40351 -- Macro: Pmode 40352 An alias for the machine mode for pointers. On most machines, 40353 define this to be the integer mode corresponding to the width of a 40354 hardware pointer; 'SImode' on 32-bit machine or 'DImode' on 64-bit 40355 machines. On some machines you must define this to be one of the 40356 partial integer modes, such as 'PSImode'. 40357 40358 The width of 'Pmode' must be at least as large as the value of 40359 'POINTER_SIZE'. If it is not equal, you must define the macro 40360 'POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to 40361 'Pmode'. 40362 40363 -- Macro: FUNCTION_MODE 40364 An alias for the machine mode used for memory references to 40365 functions being called, in 'call' RTL expressions. On most CISC 40366 machines, where an instruction can begin at any byte address, this 40367 should be 'QImode'. On most RISC machines, where all instructions 40368 have fixed size and alignment, this should be a mode with the same 40369 size and alignment as the machine instruction words - typically 40370 'SImode' or 'HImode'. 40371 40372 -- Macro: STDC_0_IN_SYSTEM_HEADERS 40373 In normal operation, the preprocessor expands '__STDC__' to the 40374 constant 1, to signify that GCC conforms to ISO Standard C. On 40375 some hosts, like Solaris, the system compiler uses a different 40376 convention, where '__STDC__' is normally 0, but is 1 if the user 40377 specifies strict conformance to the C Standard. 40378 40379 Defining 'STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host 40380 convention when processing system header files, but when processing 40381 user files '__STDC__' will always expand to 1. 40382 40383 -- C Target Hook: const char * TARGET_C_PREINCLUDE (void) 40384 Define this hook to return the name of a header file to be included 40385 at the start of all compilations, as if it had been included with 40386 '#include <FILE>'. If this hook returns 'NULL', or is not defined, 40387 or the header is not found, or if the user specifies 40388 '-ffreestanding' or '-nostdinc', no header is included. 40389 40390 This hook can be used together with a header provided by the system 40391 C library to implement ISO C requirements for certain macros to be 40392 predefined that describe properties of the whole implementation 40393 rather than just the compiler. 40394 40395 -- C Target Hook: bool TARGET_CXX_IMPLICIT_EXTERN_C (const char*) 40396 Define this hook to add target-specific C++ implicit extern C 40397 functions. If this function returns true for the name of a 40398 file-scope function, that function implicitly gets extern "C" 40399 linkage rather than whatever language linkage the declaration would 40400 normally have. An example of such function is WinMain on Win32 40401 targets. 40402 40403 -- Macro: NO_IMPLICIT_EXTERN_C 40404 Define this macro if the system header files support C++ as well as 40405 C. This macro inhibits the usual method of using system header 40406 files in C++, which is to pretend that the file's contents are 40407 enclosed in 'extern "C" {...}'. 40408 40409 -- Macro: REGISTER_TARGET_PRAGMAS () 40410 Define this macro if you want to implement any target-specific 40411 pragmas. If defined, it is a C expression which makes a series of 40412 calls to 'c_register_pragma' or 'c_register_pragma_with_expansion' 40413 for each pragma. The macro may also do any setup required for the 40414 pragmas. 40415 40416 The primary reason to define this macro is to provide compatibility 40417 with other compilers for the same target. In general, we 40418 discourage definition of target-specific pragmas for GCC. 40419 40420 If the pragma can be implemented by attributes then you should 40421 consider defining the target hook 'TARGET_INSERT_ATTRIBUTES' as 40422 well. 40423 40424 Preprocessor macros that appear on pragma lines are not expanded. 40425 All '#pragma' directives that do not match any registered pragma 40426 are silently ignored, unless the user specifies 40427 '-Wunknown-pragmas'. 40428 40429 -- Function: void c_register_pragma (const char *SPACE, const char 40430 *NAME, void (*CALLBACK) (struct cpp_reader *)) 40431 -- Function: void c_register_pragma_with_expansion (const char *SPACE, 40432 const char *NAME, void (*CALLBACK) (struct cpp_reader *)) 40433 40434 Each call to 'c_register_pragma' or 40435 'c_register_pragma_with_expansion' establishes one pragma. The 40436 CALLBACK routine will be called when the preprocessor encounters a 40437 pragma of the form 40438 40439 #pragma [SPACE] NAME ... 40440 40441 SPACE is the case-sensitive namespace of the pragma, or 'NULL' to 40442 put the pragma in the global namespace. The callback routine 40443 receives PFILE as its first argument, which can be passed on to 40444 cpplib's functions if necessary. You can lex tokens after the NAME 40445 by calling 'pragma_lex'. Tokens that are not read by the callback 40446 will be silently ignored. The end of the line is indicated by a 40447 token of type 'CPP_EOF'. Macro expansion occurs on the arguments 40448 of pragmas registered with 'c_register_pragma_with_expansion' but 40449 not on the arguments of pragmas registered with 40450 'c_register_pragma'. 40451 40452 Note that the use of 'pragma_lex' is specific to the C and C++ 40453 compilers. It will not work in the Java or Fortran compilers, or 40454 any other language compilers for that matter. Thus if 'pragma_lex' 40455 is going to be called from target-specific code, it must only be 40456 done so when building the C and C++ compilers. This can be done by 40457 defining the variables 'c_target_objs' and 'cxx_target_objs' in the 40458 target entry in the 'config.gcc' file. These variables should name 40459 the target-specific, language-specific object file which contains 40460 the code that uses 'pragma_lex'. Note it will also be necessary to 40461 add a rule to the makefile fragment pointed to by 'tmake_file' that 40462 shows how to build this object file. 40463 40464 -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION 40465 Define this macro if macros should be expanded in the arguments of 40466 '#pragma pack'. 40467 40468 -- Macro: TARGET_DEFAULT_PACK_STRUCT 40469 If your target requires a structure packing default other than 0 40470 (meaning the machine default), define this macro to the necessary 40471 value (in bytes). This must be a value that would also be valid to 40472 use with '#pragma pack()' (that is, a small power of two). 40473 40474 -- Macro: DOLLARS_IN_IDENTIFIERS 40475 Define this macro to control use of the character '$' in identifier 40476 names for the C family of languages. 0 means '$' is not allowed by 40477 default; 1 means it is allowed. 1 is the default; there is no need 40478 to define this macro in that case. 40479 40480 -- Macro: INSN_SETS_ARE_DELAYED (INSN) 40481 Define this macro as a C expression that is nonzero if it is safe 40482 for the delay slot scheduler to place instructions in the delay 40483 slot of INSN, even if they appear to use a resource set or 40484 clobbered in INSN. INSN is always a 'jump_insn' or an 'insn'; GCC 40485 knows that every 'call_insn' has this behavior. On machines where 40486 some 'insn' or 'jump_insn' is really a function call and hence has 40487 this behavior, you should define this macro. 40488 40489 You need not define this macro if it would always return zero. 40490 40491 -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN) 40492 Define this macro as a C expression that is nonzero if it is safe 40493 for the delay slot scheduler to place instructions in the delay 40494 slot of INSN, even if they appear to set or clobber a resource 40495 referenced in INSN. INSN is always a 'jump_insn' or an 'insn'. On 40496 machines where some 'insn' or 'jump_insn' is really a function call 40497 and its operands are registers whose use is actually in the 40498 subroutine it calls, you should define this macro. Doing so allows 40499 the delay slot scheduler to move instructions which copy arguments 40500 into the argument registers into the delay slot of INSN. 40501 40502 You need not define this macro if it would always return zero. 40503 40504 -- Macro: MULTIPLE_SYMBOL_SPACES 40505 Define this macro as a C expression that is nonzero if, in some 40506 cases, global symbols from one translation unit may not be bound to 40507 undefined symbols in another translation unit without user 40508 intervention. For instance, under Microsoft Windows symbols must 40509 be explicitly imported from shared libraries (DLLs). 40510 40511 You need not define this macro if it would always evaluate to zero. 40512 40513 -- Target Hook: rtx_insn * TARGET_MD_ASM_ADJUST (vec<rtx>& OUTPUTS, 40514 vec<rtx>& INPUTS, vec<const char *>& CONSTRAINTS, vec<rtx>& 40515 CLOBBERS, HARD_REG_SET& CLOBBERED_REGS) 40516 This target hook may add "clobbers" to CLOBBERS and CLOBBERED_REGS 40517 for any hard regs the port wishes to automatically clobber for an 40518 asm. The OUTPUTS and INPUTS may be inspected to avoid clobbering a 40519 register that is already used by the asm. 40520 40521 It may modify the OUTPUTS, INPUTS, and CONSTRAINTS as necessary for 40522 other pre-processing. In this case the return value is a sequence 40523 of insns to emit after the asm. 40524 40525 -- Macro: MATH_LIBRARY 40526 Define this macro as a C string constant for the linker argument to 40527 link in the system math library, minus the initial '"-l"', or '""' 40528 if the target does not have a separate math library. 40529 40530 You need only define this macro if the default of '"m"' is wrong. 40531 40532 -- Macro: LIBRARY_PATH_ENV 40533 Define this macro as a C string constant for the environment 40534 variable that specifies where the linker should look for libraries. 40535 40536 You need only define this macro if the default of '"LIBRARY_PATH"' 40537 is wrong. 40538 40539 -- Macro: TARGET_POSIX_IO 40540 Define this macro if the target supports the following POSIX file 40541 functions, access, mkdir and file locking with fcntl / F_SETLKW. 40542 Defining 'TARGET_POSIX_IO' will enable the test coverage code to 40543 use file locking when exiting a program, which avoids race 40544 conditions if the program has forked. It will also create 40545 directories at run-time for cross-profiling. 40546 40547 -- Macro: MAX_CONDITIONAL_EXECUTE 40548 40549 A C expression for the maximum number of instructions to execute 40550 via conditional execution instructions instead of a branch. A 40551 value of 'BRANCH_COST'+1 is the default if the machine does not use 40552 cc0, and 1 if it does use cc0. 40553 40554 -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR) 40555 Used if the target needs to perform machine-dependent modifications 40556 on the conditionals used for turning basic blocks into 40557 conditionally executed code. CE_INFO points to a data structure, 40558 'struct ce_if_block', which contains information about the 40559 currently processed blocks. TRUE_EXPR and FALSE_EXPR are the tests 40560 that are used for converting the then-block and the else-block, 40561 respectively. Set either TRUE_EXPR or FALSE_EXPR to a null pointer 40562 if the tests cannot be converted. 40563 40564 -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR, 40565 FALSE_EXPR) 40566 Like 'IFCVT_MODIFY_TESTS', but used when converting more 40567 complicated if-statements into conditions combined by 'and' and 40568 'or' operations. BB contains the basic block that contains the 40569 test that is currently being processed and about to be turned into 40570 a condition. 40571 40572 -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN) 40573 A C expression to modify the PATTERN of an INSN that is to be 40574 converted to conditional execution format. CE_INFO points to a 40575 data structure, 'struct ce_if_block', which contains information 40576 about the currently processed blocks. 40577 40578 -- Macro: IFCVT_MODIFY_FINAL (CE_INFO) 40579 A C expression to perform any final machine dependent modifications 40580 in converting code to conditional execution. The involved basic 40581 blocks can be found in the 'struct ce_if_block' structure that is 40582 pointed to by CE_INFO. 40583 40584 -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO) 40585 A C expression to cancel any machine dependent modifications in 40586 converting code to conditional execution. The involved basic 40587 blocks can be found in the 'struct ce_if_block' structure that is 40588 pointed to by CE_INFO. 40589 40590 -- Macro: IFCVT_MACHDEP_INIT (CE_INFO) 40591 A C expression to initialize any machine specific data for 40592 if-conversion of the if-block in the 'struct ce_if_block' structure 40593 that is pointed to by CE_INFO. 40594 40595 -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG (void) 40596 If non-null, this hook performs a target-specific pass over the 40597 instruction stream. The compiler will run it at all optimization 40598 levels, just before the point at which it normally does 40599 delayed-branch scheduling. 40600 40601 The exact purpose of the hook varies from target to target. Some 40602 use it to do transformations that are necessary for correctness, 40603 such as laying out in-function constant pools or avoiding hardware 40604 hazards. Others use it as an opportunity to do some 40605 machine-dependent optimizations. 40606 40607 You need not implement the hook if it has nothing to do. The 40608 default definition is null. 40609 40610 -- Target Hook: void TARGET_INIT_BUILTINS (void) 40611 Define this hook if you have any machine-specific built-in 40612 functions that need to be defined. It should be a function that 40613 performs the necessary setup. 40614 40615 Machine specific built-in functions can be useful to expand special 40616 machine instructions that would otherwise not normally be generated 40617 because they have no equivalent in the source language (for 40618 example, SIMD vector instructions or prefetch instructions). 40619 40620 To create a built-in function, call the function 40621 'lang_hooks.builtin_function' which is defined by the language 40622 front end. You can use any type nodes set up by 40623 'build_common_tree_nodes'; only language front ends that use those 40624 two functions will call 'TARGET_INIT_BUILTINS'. 40625 40626 -- Target Hook: tree TARGET_BUILTIN_DECL (unsigned CODE, bool 40627 INITIALIZE_P) 40628 Define this hook if you have any machine-specific built-in 40629 functions that need to be defined. It should be a function that 40630 returns the builtin function declaration for the builtin function 40631 code CODE. If there is no such builtin and it cannot be 40632 initialized at this time if INITIALIZE_P is true the function 40633 should return 'NULL_TREE'. If CODE is out of range the function 40634 should return 'error_mark_node'. 40635 40636 -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx 40637 SUBTARGET, machine_mode MODE, int IGNORE) 40638 40639 Expand a call to a machine specific built-in function that was set 40640 up by 'TARGET_INIT_BUILTINS'. EXP is the expression for the 40641 function call; the result should go to TARGET if that is 40642 convenient, and have mode MODE if that is convenient. SUBTARGET 40643 may be used as the target for computing one of EXP's operands. 40644 IGNORE is nonzero if the value is to be ignored. This function 40645 should return the result of the call to the built-in function. 40646 40647 -- Target Hook: tree TARGET_BUILTIN_CHKP_FUNCTION (unsigned FCODE) 40648 This hook allows target to redefine built-in functions used by 40649 Pointer Bounds Checker for code instrumentation. Hook should 40650 return fndecl of function implementing generic builtin whose code 40651 is passed in FCODE. Currently following built-in functions are 40652 obtained using this hook: 40653 -- Built-in Function: __bounds_type __chkp_bndmk (const void *LB, 40654 size_t SIZE) 40655 Function code - BUILT_IN_CHKP_BNDMK. This built-in function is 40656 used by Pointer Bounds Checker to create bound values. LB 40657 holds low bound of the resulting bounds. SIZE holds size of 40658 created bounds. 40659 40660 -- Built-in Function: void __chkp_bndstx (const void *PTR, 40661 __bounds_type B, const void **LOC) 40662 Function code - 'BUILT_IN_CHKP_BNDSTX'. This built-in 40663 function is used by Pointer Bounds Checker to store bounds B 40664 for pointer PTR when PTR is stored by address LOC. 40665 40666 -- Built-in Function: __bounds_type __chkp_bndldx (const void 40667 **LOC, const void *PTR) 40668 Function code - 'BUILT_IN_CHKP_BNDLDX'. This built-in 40669 function is used by Pointer Bounds Checker to get bounds of 40670 pointer PTR loaded by address LOC. 40671 40672 -- Built-in Function: void __chkp_bndcl (const void *PTR, 40673 __bounds_type B) 40674 Function code - 'BUILT_IN_CHKP_BNDCL'. This built-in function 40675 is used by Pointer Bounds Checker to perform check for pointer 40676 PTR against lower bound of bounds B. 40677 40678 -- Built-in Function: void __chkp_bndcu (const void *PTR, 40679 __bounds_type B) 40680 Function code - 'BUILT_IN_CHKP_BNDCU'. This built-in function 40681 is used by Pointer Bounds Checker to perform check for pointer 40682 PTR against upper bound of bounds B. 40683 40684 -- Built-in Function: __bounds_type __chkp_bndret (void *PTR) 40685 Function code - 'BUILT_IN_CHKP_BNDRET'. This built-in 40686 function is used by Pointer Bounds Checker to obtain bounds 40687 returned by a call statement. PTR passed to built-in is 40688 'SSA_NAME' returned by the call. 40689 40690 -- Built-in Function: __bounds_type __chkp_intersect 40691 (__bounds_type B1, __bounds_type B2) 40692 Function code - 'BUILT_IN_CHKP_INTERSECT'. This built-in 40693 function returns intersection of bounds B1 and B2. 40694 40695 -- Built-in Function: __bounds_type __chkp_narrow (const void 40696 *PTR, __bounds_type B, size_t S) 40697 Function code - 'BUILT_IN_CHKP_NARROW'. This built-in 40698 function returns intersection of bounds B and [PTR, PTR + S - 40699 '1']. 40700 40701 -- Built-in Function: size_t __chkp_sizeof (const void *PTR) 40702 Function code - 'BUILT_IN_CHKP_SIZEOF'. This built-in 40703 function returns size of object referenced by PTR. PTR is 40704 always 'ADDR_EXPR' of 'VAR_DECL'. This built-in is used by 40705 Pointer Bounds Checker when bounds of object cannot be 40706 computed statically (e.g. object has incomplete type). 40707 40708 -- Built-in Function: const void *__chkp_extract_lower 40709 (__bounds_type B) 40710 Function code - 'BUILT_IN_CHKP_EXTRACT_LOWER'. This built-in 40711 function returns lower bound of bounds B. 40712 40713 -- Built-in Function: const void *__chkp_extract_upper 40714 (__bounds_type B) 40715 Function code - 'BUILT_IN_CHKP_EXTRACT_UPPER'. This built-in 40716 function returns upper bound of bounds B. 40717 -- Target Hook: tree TARGET_CHKP_BOUND_TYPE (void) 40718 Return type to be used for bounds 40719 -- Target Hook: machine_mode TARGET_CHKP_BOUND_MODE (void) 40720 Return mode to be used for bounds. 40721 -- Target Hook: tree TARGET_CHKP_MAKE_BOUNDS_CONSTANT (HOST_WIDE_INT 40722 LB, HOST_WIDE_INT UB) 40723 Return constant used to statically initialize constant bounds with 40724 specified lower bound LB and upper bounds UB. 40725 -- Target Hook: int TARGET_CHKP_INITIALIZE_BOUNDS (tree VAR, tree LB, 40726 tree UB, tree *STMTS) 40727 Generate a list of statements STMTS to initialize pointer bounds 40728 variable VAR with bounds LB and UB. Return the number of generated 40729 statements. 40730 40731 -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (unsigned int 40732 LOC, tree FNDECL, void *ARGLIST) 40733 Select a replacement for a machine specific built-in function that 40734 was set up by 'TARGET_INIT_BUILTINS'. This is done _before_ 40735 regular type checking, and so allows the target to implement a 40736 crude form of function overloading. FNDECL is the declaration of 40737 the built-in function. ARGLIST is the list of arguments passed to 40738 the built-in function. The result is a complete expression that 40739 implements the operation, usually another 'CALL_EXPR'. ARGLIST 40740 really has type 'VEC(tree,gc)*' 40741 40742 -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, int N_ARGS, tree 40743 *ARGP, bool IGNORE) 40744 Fold a call to a machine specific built-in function that was set up 40745 by 'TARGET_INIT_BUILTINS'. FNDECL is the declaration of the 40746 built-in function. N_ARGS is the number of arguments passed to the 40747 function; the arguments themselves are pointed to by ARGP. The 40748 result is another tree, valid for both GIMPLE and GENERIC, 40749 containing a simplified expression for the call's result. If 40750 IGNORE is true the value will be ignored. 40751 40752 -- Target Hook: bool TARGET_GIMPLE_FOLD_BUILTIN (gimple_stmt_iterator 40753 *GSI) 40754 Fold a call to a machine specific built-in function that was set up 40755 by 'TARGET_INIT_BUILTINS'. GSI points to the gimple statement 40756 holding the function call. Returns true if any change was made to 40757 the GIMPLE stream. 40758 40759 -- Target Hook: int TARGET_COMPARE_VERSION_PRIORITY (tree DECL1, tree 40760 DECL2) 40761 This hook is used to compare the target attributes in two functions 40762 to determine which function's features get higher priority. This 40763 is used during function multi-versioning to figure out the order in 40764 which two versions must be dispatched. A function version with a 40765 higher priority is checked for dispatching earlier. DECL1 and 40766 DECL2 are the two function decls that will be compared. 40767 40768 -- Target Hook: tree TARGET_GET_FUNCTION_VERSIONS_DISPATCHER (void 40769 *DECL) 40770 This hook is used to get the dispatcher function for a set of 40771 function versions. The dispatcher function is called to invoke the 40772 right function version at run-time. DECL is one version from a set 40773 of semantically identical versions. 40774 40775 -- Target Hook: tree TARGET_GENERATE_VERSION_DISPATCHER_BODY (void 40776 *ARG) 40777 This hook is used to generate the dispatcher logic to invoke the 40778 right function version at run-time for a given set of function 40779 versions. ARG points to the callgraph node of the dispatcher 40780 function whose body must be generated. 40781 40782 -- Target Hook: bool TARGET_CAN_USE_DOLOOP_P (const widest_int 40783 &ITERATIONS, const widest_int &ITERATIONS_MAX, unsigned int 40784 LOOP_DEPTH, bool ENTERED_AT_TOP) 40785 Return true if it is possible to use low-overhead loops 40786 ('doloop_end' and 'doloop_begin') for a particular loop. 40787 ITERATIONS gives the exact number of iterations, or 0 if not known. 40788 ITERATIONS_MAX gives the maximum number of iterations, or 0 if not 40789 known. LOOP_DEPTH is the nesting depth of the loop, with 1 for 40790 innermost loops, 2 for loops that contain innermost loops, and so 40791 on. ENTERED_AT_TOP is true if the loop is only entered from the 40792 top. 40793 40794 This hook is only used if 'doloop_end' is available. The default 40795 implementation returns true. You can use 40796 'can_use_doloop_if_innermost' if the loop must be the innermost, 40797 and if there are no other restrictions. 40798 40799 -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (const 40800 rtx_insn *INSN) 40801 40802 Take an instruction in INSN and return NULL if it is valid within a 40803 low-overhead loop, otherwise return a string explaining why doloop 40804 could not be applied. 40805 40806 Many targets use special registers for low-overhead looping. For 40807 any instruction that clobbers these this function should return a 40808 string indicating the reason why the doloop could not be applied. 40809 By default, the RTL loop optimizer does not use a present doloop 40810 pattern for loops containing function calls or branch on table 40811 instructions. 40812 40813 -- Target Hook: bool TARGET_LEGITIMATE_COMBINED_INSN (rtx_insn *INSN) 40814 Take an instruction in INSN and return 'false' if the instruction 40815 is not appropriate as a combination of two or more instructions. 40816 The default is to accept all instructions. 40817 40818 -- Target Hook: bool TARGET_CAN_FOLLOW_JUMP (const rtx_insn *FOLLOWER, 40819 const rtx_insn *FOLLOWEE) 40820 FOLLOWER and FOLLOWEE are JUMP_INSN instructions; return true if 40821 FOLLOWER may be modified to follow FOLLOWEE; false, if it can't. 40822 For example, on some targets, certain kinds of branches can't be 40823 made to follow through a hot/cold partitioning. 40824 40825 -- Target Hook: bool TARGET_COMMUTATIVE_P (const_rtx X, int OUTER_CODE) 40826 This target hook returns 'true' if X is considered to be 40827 commutative. Usually, this is just COMMUTATIVE_P (X), but the HP 40828 PA doesn't consider PLUS to be commutative inside a MEM. 40829 OUTER_CODE is the rtx code of the enclosing rtl, if known, 40830 otherwise it is UNKNOWN. 40831 40832 -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG) 40833 40834 When the initial value of a hard register has been copied in a 40835 pseudo register, it is often not necessary to actually allocate 40836 another register to this pseudo register, because the original hard 40837 register or a stack slot it has been saved into can be used. 40838 'TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register 40839 allocation once for each hard register that had its initial value 40840 copied by using 'get_func_hard_reg_initial_val' or 40841 'get_hard_reg_initial_val'. Possible values are 'NULL_RTX', if you 40842 don't want to do any special allocation, a 'REG' rtx--that would 40843 typically be the hard register itself, if it is known not to be 40844 clobbered--or a 'MEM'. If you are returning a 'MEM', this is only 40845 a hint for the allocator; it might decide to use another register 40846 anyways. You may use 'current_function_is_leaf' or 'REG_N_SETS' in 40847 the hook to determine if the hard register in question will not be 40848 clobbered. The default value of this hook is 'NULL', which 40849 disables any special allocation. 40850 40851 -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned 40852 FLAGS) 40853 This target hook returns nonzero if X, an 'unspec' or 40854 'unspec_volatile' operation, might cause a trap. Targets can use 40855 this hook to enhance precision of analysis for 'unspec' and 40856 'unspec_volatile' operations. You may call 'may_trap_p_1' to 40857 analyze inner elements of X in which case FLAGS should be passed 40858 along. 40859 40860 -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL) 40861 The compiler invokes this hook whenever it changes its current 40862 function context ('cfun'). You can define this function if the 40863 back end needs to perform any initialization or reset actions on a 40864 per-function basis. For example, it may be used to implement 40865 function attributes that affect register usage or code generation 40866 patterns. The argument DECL is the declaration for the new 40867 function context, and may be null to indicate that the compiler has 40868 left a function context and is returning to processing at the top 40869 level. The default hook function does nothing. 40870 40871 GCC sets 'cfun' to a dummy function context during initialization 40872 of some parts of the back end. The hook function is not invoked in 40873 this situation; you need not worry about the hook being invoked 40874 recursively, or when the back end is in a partially-initialized 40875 state. 'cfun' might be 'NULL' to indicate processing at top level, 40876 outside of any function scope. 40877 40878 -- Macro: TARGET_OBJECT_SUFFIX 40879 Define this macro to be a C string representing the suffix for 40880 object files on your target machine. If you do not define this 40881 macro, GCC will use '.o' as the suffix for object files. 40882 40883 -- Macro: TARGET_EXECUTABLE_SUFFIX 40884 Define this macro to be a C string representing the suffix to be 40885 automatically added to executable files on your target machine. If 40886 you do not define this macro, GCC will use the null string as the 40887 suffix for executable files. 40888 40889 -- Macro: COLLECT_EXPORT_LIST 40890 If defined, 'collect2' will scan the individual object files 40891 specified on its command line and create an export list for the 40892 linker. Define this macro for systems like AIX, where the linker 40893 discards object files that are not referenced from 'main' and uses 40894 export lists. 40895 40896 -- Macro: MODIFY_JNI_METHOD_CALL (MDECL) 40897 Define this macro to a C expression representing a variant of the 40898 method call MDECL, if Java Native Interface (JNI) methods must be 40899 invoked differently from other methods on your target. For 40900 example, on 32-bit Microsoft Windows, JNI methods must be invoked 40901 using the 'stdcall' calling convention and this macro is then 40902 defined as this expression: 40903 40904 build_type_attribute_variant (MDECL, 40905 build_tree_list 40906 (get_identifier ("stdcall"), 40907 NULL)) 40908 40909 -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void) 40910 This target hook returns 'true' past the point in which new jump 40911 instructions could be created. On machines that require a register 40912 for every jump such as the SHmedia ISA of SH5, this point would 40913 typically be reload, so this target hook should be defined to a 40914 function such as: 40915 40916 static bool 40917 cannot_modify_jumps_past_reload_p () 40918 { 40919 return (reload_completed || reload_in_progress); 40920 } 40921 40922 -- Target Hook: reg_class_t TARGET_BRANCH_TARGET_REGISTER_CLASS (void) 40923 This target hook returns a register class for which branch target 40924 register optimizations should be applied. All registers in this 40925 class should be usable interchangeably. After reload, registers in 40926 this class will be re-allocated and loads will be hoisted out of 40927 loops and be subjected to inter-block scheduling. 40928 40929 -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool 40930 AFTER_PROLOGUE_EPILOGUE_GEN) 40931 Branch target register optimization will by default exclude 40932 callee-saved registers that are not already live during the current 40933 function; if this target hook returns true, they will be included. 40934 The target code must than make sure that all target registers in 40935 the class returned by 'TARGET_BRANCH_TARGET_REGISTER_CLASS' that 40936 might need saving are saved. AFTER_PROLOGUE_EPILOGUE_GEN indicates 40937 if prologues and epilogues have already been generated. Note, even 40938 if you only return true when AFTER_PROLOGUE_EPILOGUE_GEN is false, 40939 you still are likely to have to make special provisions in 40940 'INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved 40941 target registers. 40942 40943 -- Target Hook: bool TARGET_HAVE_CONDITIONAL_EXECUTION (void) 40944 This target hook returns true if the target supports conditional 40945 execution. This target hook is required only when the target has 40946 several different modes and they have different conditional 40947 execution capability, such as ARM. 40948 40949 -- Target Hook: rtx TARGET_GEN_CCMP_FIRST (rtx_insn **PREP_SEQ, 40950 rtx_insn **GEN_SEQ, int CODE, tree OP0, tree OP1) 40951 This function prepares to emit a comparison insn for the first 40952 compare in a sequence of conditional comparisions. It returns an 40953 appropriate comparison with 'CC' for passing to 'gen_ccmp_next' or 40954 'cbranch_optab'. The insns to prepare the compare are saved in 40955 PREP_SEQ and the compare insns are saved in GEN_SEQ. They will be 40956 emitted when all the compares in the the conditional comparision 40957 are generated without error. CODE is the 'rtx_code' of the compare 40958 for OP0 and OP1. 40959 40960 -- Target Hook: rtx TARGET_GEN_CCMP_NEXT (rtx_insn **PREP_SEQ, rtx_insn 40961 **GEN_SEQ, rtx PREV, int CMP_CODE, tree OP0, tree OP1, int 40962 BIT_CODE) 40963 This function prepares to emit a conditional comparison within a 40964 sequence of conditional comparisons. It returns an appropriate 40965 comparison with 'CC' for passing to 'gen_ccmp_next' or 40966 'cbranch_optab'. The insns to prepare the compare are saved in 40967 PREP_SEQ and the compare insns are saved in GEN_SEQ. They will be 40968 emitted when all the compares in the conditional comparision are 40969 generated without error. The PREV expression is the result of a 40970 prior call to 'gen_ccmp_first' or 'gen_ccmp_next'. It may return 40971 'NULL' if the combination of PREV and this comparison is not 40972 supported, otherwise the result must be appropriate for passing to 40973 'gen_ccmp_next' or 'cbranch_optab'. CODE is the 'rtx_code' of the 40974 compare for OP0 and OP1. BIT_CODE is 'AND' or 'IOR', which is the 40975 op on the compares. 40976 40977 -- Target Hook: unsigned TARGET_LOOP_UNROLL_ADJUST (unsigned NUNROLL, 40978 struct loop *LOOP) 40979 This target hook returns a new value for the number of times LOOP 40980 should be unrolled. The parameter NUNROLL is the number of times 40981 the loop is to be unrolled. The parameter LOOP is a pointer to the 40982 loop, which is going to be checked for unrolling. This target hook 40983 is required only when the target has special constraints like 40984 maximum number of memory accesses. 40985 40986 -- Macro: POWI_MAX_MULTS 40987 If defined, this macro is interpreted as a signed integer C 40988 expression that specifies the maximum number of floating point 40989 multiplications that should be emitted when expanding 40990 exponentiation by an integer constant inline. When this value is 40991 defined, exponentiation requiring more than this number of 40992 multiplications is implemented by calling the system library's 40993 'pow', 'powf' or 'powl' routines. The default value places no 40994 upper bound on the multiplication count. 40995 40996 -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char 40997 *IPREFIX, int STDINC) 40998 This target hook should register any extra include files for the 40999 target. The parameter STDINC indicates if normal include files are 41000 present. The parameter SYSROOT is the system root directory. The 41001 parameter IPREFIX is the prefix for the gcc directory. 41002 41003 -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const 41004 char *IPREFIX, int STDINC) 41005 This target hook should register any extra include files for the 41006 target before any standard headers. The parameter STDINC indicates 41007 if normal include files are present. The parameter SYSROOT is the 41008 system root directory. The parameter IPREFIX is the prefix for the 41009 gcc directory. 41010 41011 -- Macro: void TARGET_OPTF (char *PATH) 41012 This target hook should register special include paths for the 41013 target. The parameter PATH is the include to register. On Darwin 41014 systems, this is used for Framework includes, which have semantics 41015 that are different from '-I'. 41016 41017 -- Macro: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL) 41018 This target macro returns 'true' if it is safe to use a local alias 41019 for a virtual function FNDECL when constructing thunks, 'false' 41020 otherwise. By default, the macro returns 'true' for all functions, 41021 if a target supports aliases (i.e. defines 'ASM_OUTPUT_DEF'), 41022 'false' otherwise, 41023 41024 -- Macro: TARGET_FORMAT_TYPES 41025 If defined, this macro is the name of a global variable containing 41026 target-specific format checking information for the '-Wformat' 41027 option. The default is to have no target-specific format checks. 41028 41029 -- Macro: TARGET_N_FORMAT_TYPES 41030 If defined, this macro is the number of entries in 41031 'TARGET_FORMAT_TYPES'. 41032 41033 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES 41034 If defined, this macro is the name of a global variable containing 41035 target-specific format overrides for the '-Wformat' option. The 41036 default is to have no target-specific format overrides. If 41037 defined, 'TARGET_FORMAT_TYPES' must be defined, too. 41038 41039 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT 41040 If defined, this macro specifies the number of entries in 41041 'TARGET_OVERRIDES_FORMAT_ATTRIBUTES'. 41042 41043 -- Macro: TARGET_OVERRIDES_FORMAT_INIT 41044 If defined, this macro specifies the optional initialization 41045 routine for target specific customizations of the system printf and 41046 scanf formatter settings. 41047 41048 -- Target Hook: const char * TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN 41049 (const_tree TYPELIST, const_tree FUNCDECL, const_tree VAL) 41050 If defined, this macro returns the diagnostic message when it is 41051 illegal to pass argument VAL to function FUNCDECL with prototype 41052 TYPELIST. 41053 41054 -- Target Hook: const char * TARGET_INVALID_CONVERSION (const_tree 41055 FROMTYPE, const_tree TOTYPE) 41056 If defined, this macro returns the diagnostic message when it is 41057 invalid to convert from FROMTYPE to TOTYPE, or 'NULL' if validity 41058 should be determined by the front end. 41059 41060 -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP, 41061 const_tree TYPE) 41062 If defined, this macro returns the diagnostic message when it is 41063 invalid to apply operation OP (where unary plus is denoted by 41064 'CONVERT_EXPR') to an operand of type TYPE, or 'NULL' if validity 41065 should be determined by the front end. 41066 41067 -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP, 41068 const_tree TYPE1, const_tree TYPE2) 41069 If defined, this macro returns the diagnostic message when it is 41070 invalid to apply operation OP to operands of types TYPE1 and TYPE2, 41071 or 'NULL' if validity should be determined by the front end. 41072 41073 -- Target Hook: tree TARGET_PROMOTED_TYPE (const_tree TYPE) 41074 If defined, this target hook returns the type to which values of 41075 TYPE should be promoted when they appear in expressions, analogous 41076 to the integer promotions, or 'NULL_TREE' to use the front end's 41077 normal promotion rules. This hook is useful when there are 41078 target-specific types with special promotion rules. This is 41079 currently used only by the C and C++ front ends. 41080 41081 -- Target Hook: tree TARGET_CONVERT_TO_TYPE (tree TYPE, tree EXPR) 41082 If defined, this hook returns the result of converting EXPR to 41083 TYPE. It should return the converted expression, or 'NULL_TREE' to 41084 apply the front end's normal conversion rules. This hook is useful 41085 when there are target-specific types with special conversion rules. 41086 This is currently used only by the C and C++ front ends. 41087 41088 -- Macro: OBJC_JBLEN 41089 This macro determines the size of the objective C jump buffer for 41090 the NeXT runtime. By default, OBJC_JBLEN is defined to an 41091 innocuous value. 41092 41093 -- Macro: LIBGCC2_UNWIND_ATTRIBUTE 41094 Define this macro if any target-specific attributes need to be 41095 attached to the functions in 'libgcc' that provide low-level 41096 support for call stack unwinding. It is used in declarations in 41097 'unwind-generic.h' and the associated definitions of those 41098 functions. 41099 41100 -- Target Hook: void TARGET_UPDATE_STACK_BOUNDARY (void) 41101 Define this macro to update the current function stack boundary if 41102 necessary. 41103 41104 -- Target Hook: rtx TARGET_GET_DRAP_RTX (void) 41105 This hook should return an rtx for Dynamic Realign Argument Pointer 41106 (DRAP) if a different argument pointer register is needed to access 41107 the function's argument list due to stack realignment. Return 41108 'NULL' if no DRAP is needed. 41109 41110 -- Target Hook: bool TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS (void) 41111 When optimization is disabled, this hook indicates whether or not 41112 arguments should be allocated to stack slots. Normally, GCC 41113 allocates stacks slots for arguments when not optimizing in order 41114 to make debugging easier. However, when a function is declared 41115 with '__attribute__((naked))', there is no stack frame, and the 41116 compiler cannot safely move arguments from the registers in which 41117 they are passed to the stack. Therefore, this hook should return 41118 true in general, but false for naked functions. The default 41119 implementation always returns true. 41120 41121 -- Target Hook: unsigned HOST_WIDE_INT TARGET_CONST_ANCHOR 41122 On some architectures it can take multiple instructions to 41123 synthesize a constant. If there is another constant already in a 41124 register that is close enough in value then it is preferable that 41125 the new constant is computed from this register using immediate 41126 addition or subtraction. We accomplish this through CSE. Besides 41127 the value of the constant we also add a lower and an upper constant 41128 anchor to the available expressions. These are then queried when 41129 encountering new constants. The anchors are computed by rounding 41130 the constant up and down to a multiple of the value of 41131 'TARGET_CONST_ANCHOR'. 'TARGET_CONST_ANCHOR' should be the maximum 41132 positive value accepted by immediate-add plus one. We currently 41133 assume that the value of 'TARGET_CONST_ANCHOR' is a power of 2. 41134 For example, on MIPS, where add-immediate takes a 16-bit signed 41135 value, 'TARGET_CONST_ANCHOR' is set to '0x8000'. The default value 41136 is zero, which disables this optimization. 41137 41138 -- Target Hook: unsigned HOST_WIDE_INT TARGET_ASAN_SHADOW_OFFSET (void) 41139 Return the offset bitwise ored into shifted address to get 41140 corresponding Address Sanitizer shadow memory address. NULL if 41141 Address Sanitizer is not supported by the target. 41142 41143 -- Target Hook: unsigned HOST_WIDE_INT TARGET_MEMMODEL_CHECK (unsigned 41144 HOST_WIDE_INT VAL) 41145 Validate target specific memory model mask bits. When NULL no 41146 target specific memory model bits are allowed. 41147 41148 -- Target Hook: unsigned char TARGET_ATOMIC_TEST_AND_SET_TRUEVAL 41149 This value should be set if the result written by 41150 'atomic_test_and_set' is not exactly 1, i.e. the 'bool' 'true'. 41151 41152 -- Target Hook: bool TARGET_HAS_IFUNC_P (void) 41153 It returns true if the target supports GNU indirect functions. The 41154 support includes the assembler, linker and dynamic linker. The 41155 default value of this hook is based on target's libc. 41156 41157 -- Target Hook: unsigned int TARGET_ATOMIC_ALIGN_FOR_MODE (machine_mode 41158 MODE) 41159 If defined, this function returns an appropriate alignment in bits 41160 for an atomic object of machine_mode MODE. If 0 is returned then 41161 the default alignment for the specified mode is used. 41162 41163 -- Target Hook: void TARGET_ATOMIC_ASSIGN_EXPAND_FENV (tree *HOLD, tree 41164 *CLEAR, tree *UPDATE) 41165 ISO C11 requires atomic compound assignments that may raise 41166 floating-point exceptions to raise exceptions corresponding to the 41167 arithmetic operation whose result was successfully stored in a 41168 compare-and-exchange sequence. This requires code equivalent to 41169 calls to 'feholdexcept', 'feclearexcept' and 'feupdateenv' to be 41170 generated at appropriate points in the compare-and-exchange 41171 sequence. This hook should set '*HOLD' to an expression equivalent 41172 to the call to 'feholdexcept', '*CLEAR' to an expression equivalent 41173 to the call to 'feclearexcept' and '*UPDATE' to an expression 41174 equivalent to the call to 'feupdateenv'. The three expressions are 41175 'NULL_TREE' on entry to the hook and may be left as 'NULL_TREE' if 41176 no code is required in a particular place. The default 41177 implementation leaves all three expressions as 'NULL_TREE'. The 41178 '__atomic_feraiseexcept' function from 'libatomic' may be of use as 41179 part of the code generated in '*UPDATE'. 41180 41181 -- Target Hook: void TARGET_RECORD_OFFLOAD_SYMBOL (tree) 41182 Used when offloaded functions are seen in the compilation unit and 41183 no named sections are available. It is called once for each symbol 41184 that must be recorded in the offload function and variable table. 41185 41186 -- Target Hook: char * TARGET_OFFLOAD_OPTIONS (void) 41187 Used when writing out the list of options into an LTO file. It 41188 should translate any relevant target-specific options (such as the 41189 ABI in use) into one of the '-foffload' options that exist as a 41190 common interface to express such options. It should return a 41191 string containing these options, separated by spaces, which the 41192 caller will free. 41193 41194 -- Macro: TARGET_SUPPORTS_WIDE_INT 41195 41196 On older ports, large integers are stored in 'CONST_DOUBLE' rtl 41197 objects. Newer ports define 'TARGET_SUPPORTS_WIDE_INT' to be 41198 nonzero to indicate that large integers are stored in 41199 'CONST_WIDE_INT' rtl objects. The 'CONST_WIDE_INT' allows very 41200 large integer constants to be represented. 'CONST_DOUBLE' is 41201 limited to twice the size of the host's 'HOST_WIDE_INT' 41202 representation. 41203 41204 Converting a port mostly requires looking for the places where 41205 'CONST_DOUBLE's are used with 'VOIDmode' and replacing that code 41206 with code that accesses 'CONST_WIDE_INT's. '"grep -i 41207 const_double"' at the port level gets you to 95% of the changes 41208 that need to be made. There are a few places that require a deeper 41209 look. 41210 41211 * There is no equivalent to 'hval' and 'lval' for 41212 'CONST_WIDE_INT's. This would be difficult to express in the 41213 md language since there are a variable number of elements. 41214 41215 Most ports only check that 'hval' is either 0 or -1 to see if 41216 the value is small. As mentioned above, this will no longer 41217 be necessary since small constants are always 'CONST_INT'. Of 41218 course there are still a few exceptions, the alpha's 41219 constraint used by the zap instruction certainly requires 41220 careful examination by C code. However, all the current code 41221 does is pass the hval and lval to C code, so evolving the c 41222 code to look at the 'CONST_WIDE_INT' is not really a large 41223 change. 41224 41225 * Because there is no standard template that ports use to 41226 materialize constants, there is likely to be some futzing that 41227 is unique to each port in this code. 41228 41229 * The rtx costs may have to be adjusted to properly account for 41230 larger constants that are represented as 'CONST_WIDE_INT'. 41231 41232 All and all it does not take long to convert ports that the 41233 maintainer is familiar with. 41234 41235 -- Target Hook: void TARGET_RUN_TARGET_SELFTESTS (void) 41236 If selftests are enabled, run any selftests for this target. 41237 41238 41239File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top 41240 4124119 Host Configuration 41242********************* 41243 41244Most details about the machine and system on which the compiler is 41245actually running are detected by the 'configure' script. Some things 41246are impossible for 'configure' to detect; these are described in two 41247ways, either by macros defined in a file named 'xm-MACHINE.h' or by hook 41248functions in the file specified by the OUT_HOST_HOOK_OBJ variable in 41249'config.gcc'. (The intention is that very few hosts will need a header 41250file but nearly every fully supported host will need to override some 41251hooks.) 41252 41253 If you need to define only a few macros, and they have simple 41254definitions, consider using the 'xm_defines' variable in your 41255'config.gcc' entry instead of creating a host configuration header. 41256*Note System Config::. 41257 41258* Menu: 41259 41260* Host Common:: Things every host probably needs implemented. 41261* Filesystem:: Your host cannot have the letter 'a' in filenames? 41262* Host Misc:: Rare configuration options for hosts. 41263 41264 41265File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config 41266 4126719.1 Host Common 41268================ 41269 41270Some things are just not portable, even between similar operating 41271systems, and are too difficult for autoconf to detect. They get 41272implemented using hook functions in the file specified by the 41273HOST_HOOK_OBJ variable in 'config.gcc'. 41274 41275 -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void) 41276 This host hook is used to set up handling for extra signals. The 41277 most common thing to do in this hook is to detect stack overflow. 41278 41279 -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int 41280 FD) 41281 This host hook returns the address of some space that is likely to 41282 be free in some subsequent invocation of the compiler. We intend 41283 to load the PCH data at this address such that the data need not be 41284 relocated. The area should be able to hold SIZE bytes. If the 41285 host uses 'mmap', FD is an open file descriptor that can be used 41286 for probing. 41287 41288 -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS, size_t 41289 SIZE, int FD, size_t OFFSET) 41290 This host hook is called when a PCH file is about to be loaded. We 41291 want to load SIZE bytes from FD at OFFSET into memory at ADDRESS. 41292 The given address will be the result of a previous invocation of 41293 'HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we couldn't allocate 41294 SIZE bytes at ADDRESS. Return 0 if the memory is allocated but the 41295 data is not loaded. Return 1 if the hook has performed everything. 41296 41297 If the implementation uses reserved address space, free any 41298 reserved space beyond SIZE, regardless of the return value. If no 41299 PCH will be loaded, this hook may be called with SIZE zero, in 41300 which case all reserved address space should be freed. 41301 41302 Do not try to handle values of ADDRESS that could not have been 41303 returned by this executable; just return -1. Such values usually 41304 indicate an out-of-date PCH file (built by some other GCC 41305 executable), and such a PCH file won't work. 41306 41307 -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void); 41308 This host hook returns the alignment required for allocating 41309 virtual memory. Usually this is the same as getpagesize, but on 41310 some hosts the alignment for reserving memory differs from the 41311 pagesize for committing memory. 41312 41313 41314File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config 41315 4131619.2 Host Filesystem 41317==================== 41318 41319GCC needs to know a number of things about the semantics of the host 41320machine's filesystem. Filesystems with Unix and MS-DOS semantics are 41321automatically detected. For other systems, you can define the following 41322macros in 'xm-MACHINE.h'. 41323 41324'HAVE_DOS_BASED_FILE_SYSTEM' 41325 This macro is automatically defined by 'system.h' if the host file 41326 system obeys the semantics defined by MS-DOS instead of Unix. DOS 41327 file systems are case insensitive, file specifications may begin 41328 with a drive letter, and both forward slash and backslash ('/' and 41329 '\') are directory separators. 41330 41331'DIR_SEPARATOR' 41332'DIR_SEPARATOR_2' 41333 If defined, these macros expand to character constants specifying 41334 separators for directory names within a file specification. 41335 'system.h' will automatically give them appropriate values on Unix 41336 and MS-DOS file systems. If your file system is neither of these, 41337 define one or both appropriately in 'xm-MACHINE.h'. 41338 41339 However, operating systems like VMS, where constructing a pathname 41340 is more complicated than just stringing together directory names 41341 separated by a special character, should not define either of these 41342 macros. 41343 41344'PATH_SEPARATOR' 41345 If defined, this macro should expand to a character constant 41346 specifying the separator for elements of search paths. The default 41347 value is a colon (':'). DOS-based systems usually, but not always, 41348 use semicolon (';'). 41349 41350'VMS' 41351 Define this macro if the host system is VMS. 41352 41353'HOST_OBJECT_SUFFIX' 41354 Define this macro to be a C string representing the suffix for 41355 object files on your host machine. If you do not define this 41356 macro, GCC will use '.o' as the suffix for object files. 41357 41358'HOST_EXECUTABLE_SUFFIX' 41359 Define this macro to be a C string representing the suffix for 41360 executable files on your host machine. If you do not define this 41361 macro, GCC will use the null string as the suffix for executable 41362 files. 41363 41364'HOST_BIT_BUCKET' 41365 A pathname defined by the host operating system, which can be 41366 opened as a file and written to, but all the information written is 41367 discarded. This is commonly known as a "bit bucket" or "null 41368 device". If you do not define this macro, GCC will use '/dev/null' 41369 as the bit bucket. If the host does not support a bit bucket, 41370 define this macro to an invalid filename. 41371 41372'UPDATE_PATH_HOST_CANONICALIZE (PATH)' 41373 If defined, a C statement (sans semicolon) that performs 41374 host-dependent canonicalization when a path used in a compilation 41375 driver or preprocessor is canonicalized. PATH is a malloc-ed path 41376 to be canonicalized. If the C statement does canonicalize PATH 41377 into a different buffer, the old path should be freed and the new 41378 buffer should have been allocated with malloc. 41379 41380'DUMPFILE_FORMAT' 41381 Define this macro to be a C string representing the format to use 41382 for constructing the index part of debugging dump file names. The 41383 resultant string must fit in fifteen bytes. The full filename will 41384 be the concatenation of: the prefix of the assembler file name, the 41385 string resulting from applying this format to an index number, and 41386 a string unique to each dump file kind, e.g. 'rtl'. 41387 41388 If you do not define this macro, GCC will use '.%02d.'. You should 41389 define this macro if using the default will create an invalid file 41390 name. 41391 41392'DELETE_IF_ORDINARY' 41393 Define this macro to be a C statement (sans semicolon) that 41394 performs host-dependent removal of ordinary temp files in the 41395 compilation driver. 41396 41397 If you do not define this macro, GCC will use the default version. 41398 You should define this macro if the default version does not 41399 reliably remove the temp file as, for example, on VMS which allows 41400 multiple versions of a file. 41401 41402'HOST_LACKS_INODE_NUMBERS' 41403 Define this macro if the host filesystem does not report meaningful 41404 inode numbers in struct stat. 41405 41406 41407File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config 41408 4140919.3 Host Misc 41410============== 41411 41412'FATAL_EXIT_CODE' 41413 A C expression for the status code to be returned when the compiler 41414 exits after serious errors. The default is the system-provided 41415 macro 'EXIT_FAILURE', or '1' if the system doesn't define that 41416 macro. Define this macro only if these defaults are incorrect. 41417 41418'SUCCESS_EXIT_CODE' 41419 A C expression for the status code to be returned when the compiler 41420 exits without serious errors. (Warnings are not serious errors.) 41421 The default is the system-provided macro 'EXIT_SUCCESS', or '0' if 41422 the system doesn't define that macro. Define this macro only if 41423 these defaults are incorrect. 41424 41425'USE_C_ALLOCA' 41426 Define this macro if GCC should use the C implementation of 41427 'alloca' provided by 'libiberty.a'. This only affects how some 41428 parts of the compiler itself allocate memory. It does not change 41429 code generation. 41430 41431 When GCC is built with a compiler other than itself, the C 'alloca' 41432 is always used. This is because most other implementations have 41433 serious bugs. You should define this macro only on a system where 41434 no stack-based 'alloca' can possibly work. For instance, if a 41435 system has a small limit on the size of the stack, GCC's builtin 41436 'alloca' will not work reliably. 41437 41438'COLLECT2_HOST_INITIALIZATION' 41439 If defined, a C statement (sans semicolon) that performs 41440 host-dependent initialization when 'collect2' is being initialized. 41441 41442'GCC_DRIVER_HOST_INITIALIZATION' 41443 If defined, a C statement (sans semicolon) that performs 41444 host-dependent initialization when a compilation driver is being 41445 initialized. 41446 41447'HOST_LONG_LONG_FORMAT' 41448 If defined, the string used to indicate an argument of type 'long 41449 long' to functions like 'printf'. The default value is '"ll"'. 41450 41451'HOST_LONG_FORMAT' 41452 If defined, the string used to indicate an argument of type 'long' 41453 to functions like 'printf'. The default value is '"l"'. 41454 41455'HOST_PTR_PRINTF' 41456 If defined, the string used to indicate an argument of type 'void 41457 *' to functions like 'printf'. The default value is '"%p"'. 41458 41459 In addition, if 'configure' generates an incorrect definition of any of 41460the macros in 'auto-host.h', you can override that definition in a host 41461configuration header. If you need to do this, first see if it is 41462possible to fix 'configure'. 41463 41464 41465File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top 41466 4146720 Makefile Fragments 41468********************* 41469 41470When you configure GCC using the 'configure' script, it will construct 41471the file 'Makefile' from the template file 'Makefile.in'. When it does 41472this, it can incorporate makefile fragments from the 'config' directory. 41473These are used to set Makefile parameters that are not amenable to being 41474calculated by autoconf. The list of fragments to incorporate is set by 41475'config.gcc' (and occasionally 'config.build' and 'config.host'); *Note 41476System Config::. 41477 41478 Fragments are named either 't-TARGET' or 'x-HOST', depending on whether 41479they are relevant to configuring GCC to produce code for a particular 41480target, or to configuring GCC to run on a particular host. Here TARGET 41481and HOST are mnemonics which usually have some relationship to the 41482canonical system name, but no formal connection. 41483 41484 If these files do not exist, it means nothing needs to be added for a 41485given target or host. Most targets need a few 't-TARGET' fragments, but 41486needing 'x-HOST' fragments is rare. 41487 41488* Menu: 41489 41490* Target Fragment:: Writing 't-TARGET' files. 41491* Host Fragment:: Writing 'x-HOST' files. 41492 41493 41494File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments 41495 4149620.1 Target Makefile Fragments 41497============================== 41498 41499Target makefile fragments can set these Makefile variables. 41500 41501'LIBGCC2_CFLAGS' 41502 Compiler flags to use when compiling 'libgcc2.c'. 41503 41504'LIB2FUNCS_EXTRA' 41505 A list of source file names to be compiled or assembled and 41506 inserted into 'libgcc.a'. 41507 41508'CRTSTUFF_T_CFLAGS' 41509 Special flags used when compiling 'crtstuff.c'. *Note 41510 Initialization::. 41511 41512'CRTSTUFF_T_CFLAGS_S' 41513 Special flags used when compiling 'crtstuff.c' for shared linking. 41514 Used if you use 'crtbeginS.o' and 'crtendS.o' in 'EXTRA-PARTS'. 41515 *Note Initialization::. 41516 41517'MULTILIB_OPTIONS' 41518 For some targets, invoking GCC in different ways produces objects 41519 that can not be linked together. For example, for some targets GCC 41520 produces both big and little endian code. For these targets, you 41521 must arrange for multiple versions of 'libgcc.a' to be compiled, 41522 one for each set of incompatible options. When GCC invokes the 41523 linker, it arranges to link in the right version of 'libgcc.a', 41524 based on the command line options used. 41525 41526 The 'MULTILIB_OPTIONS' macro lists the set of options for which 41527 special versions of 'libgcc.a' must be built. Write options that 41528 are mutually incompatible side by side, separated by a slash. 41529 Write options that may be used together separated by a space. The 41530 build procedure will build all combinations of compatible options. 41531 41532 For example, if you set 'MULTILIB_OPTIONS' to 'm68000/m68020 41533 msoft-float', 'Makefile' will build special versions of 'libgcc.a' 41534 using the following sets of options: '-m68000', '-m68020', 41535 '-msoft-float', '-m68000 -msoft-float', and '-m68020 -msoft-float'. 41536 41537'MULTILIB_DIRNAMES' 41538 If 'MULTILIB_OPTIONS' is used, this variable specifies the 41539 directory names that should be used to hold the various libraries. 41540 Write one element in 'MULTILIB_DIRNAMES' for each element in 41541 'MULTILIB_OPTIONS'. If 'MULTILIB_DIRNAMES' is not used, the 41542 default value will be 'MULTILIB_OPTIONS', with all slashes treated 41543 as spaces. 41544 41545 'MULTILIB_DIRNAMES' describes the multilib directories using GCC 41546 conventions and is applied to directories that are part of the GCC 41547 installation. When multilib-enabled, the compiler will add a 41548 subdirectory of the form PREFIX/MULTILIB before each directory in 41549 the search path for libraries and crt files. 41550 41551 For example, if 'MULTILIB_OPTIONS' is set to 'm68000/m68020 41552 msoft-float', then the default value of 'MULTILIB_DIRNAMES' is 41553 'm68000 m68020 msoft-float'. You may specify a different value if 41554 you desire a different set of directory names. 41555 41556'MULTILIB_MATCHES' 41557 Sometimes the same option may be written in two different ways. If 41558 an option is listed in 'MULTILIB_OPTIONS', GCC needs to know about 41559 any synonyms. In that case, set 'MULTILIB_MATCHES' to a list of 41560 items of the form 'option=option' to describe all relevant 41561 synonyms. For example, 'm68000=mc68000 m68020=mc68020'. 41562 41563'MULTILIB_EXCEPTIONS' 41564 Sometimes when there are multiple sets of 'MULTILIB_OPTIONS' being 41565 specified, there are combinations that should not be built. In 41566 that case, set 'MULTILIB_EXCEPTIONS' to be all of the switch 41567 exceptions in shell case syntax that should not be built. 41568 41569 For example the ARM processor cannot execute both hardware floating 41570 point instructions and the reduced size THUMB instructions at the 41571 same time, so there is no need to build libraries with both of 41572 these options enabled. Therefore 'MULTILIB_EXCEPTIONS' is set to: 41573 *mthumb/*mhard-float* 41574 41575'MULTILIB_REQUIRED' 41576 Sometimes when there are only a few combinations are required, it 41577 would be a big effort to come up with a 'MULTILIB_EXCEPTIONS' list 41578 to cover all undesired ones. In such a case, just listing all the 41579 required combinations in 'MULTILIB_REQUIRED' would be more 41580 straightforward. 41581 41582 The way to specify the entries in 'MULTILIB_REQUIRED' is same with 41583 the way used for 'MULTILIB_EXCEPTIONS', only this time what are 41584 required will be specified. Suppose there are multiple sets of 41585 'MULTILIB_OPTIONS' and only two combinations are required, one for 41586 ARMv7-M and one for ARMv7-R with hard floating-point ABI and FPU, 41587 the 'MULTILIB_REQUIRED' can be set to: 41588 MULTILIB_REQUIRED = mthumb/march=armv7-m 41589 MULTILIB_REQUIRED += march=armv7-r/mfloat-abi=hard/mfpu=vfpv3-d16 41590 41591 The 'MULTILIB_REQUIRED' can be used together with 41592 'MULTILIB_EXCEPTIONS'. The option combinations generated from 41593 'MULTILIB_OPTIONS' will be filtered by 'MULTILIB_EXCEPTIONS' and 41594 then by 'MULTILIB_REQUIRED'. 41595 41596'MULTILIB_REUSE' 41597 Sometimes it is desirable to reuse one existing multilib for 41598 different sets of options. Such kind of reuse can minimize the 41599 number of multilib variants. And for some targets it is better to 41600 reuse an existing multilib than to fall back to default multilib 41601 when there is no corresponding multilib. This can be done by 41602 adding reuse rules to 'MULTILIB_REUSE'. 41603 41604 A reuse rule is comprised of two parts connected by equality sign. 41605 The left part is the option set used to build multilib and the 41606 right part is the option set that will reuse this multilib. Both 41607 parts should only use options specified in 'MULTILIB_OPTIONS' and 41608 the equality signs found in options name should be replaced with 41609 periods. An explicit period in the rule can be escaped by 41610 preceding it with a backslash. The order of options in the left 41611 part matters and should be same with those specified in 41612 'MULTILIB_REQUIRED' or aligned with the order in 41613 'MULTILIB_OPTIONS'. There is no such limitation for options in the 41614 right part as we don't build multilib from them. 41615 41616 'MULTILIB_REUSE' is different from 'MULTILIB_MATCHES' in that it 41617 sets up relations between two option sets rather than two options. 41618 Here is an example to demo how we reuse libraries built in Thumb 41619 mode for applications built in ARM mode: 41620 MULTILIB_REUSE = mthumb/march.armv7-r=marm/march.armv7-r 41621 41622 Before the advent of 'MULTILIB_REUSE', GCC select multilib by 41623 comparing command line options with options used to build multilib. 41624 The 'MULTILIB_REUSE' is complementary to that way. Only when the 41625 original comparison matches nothing it will work to see if it is OK 41626 to reuse some existing multilib. 41627 41628'MULTILIB_EXTRA_OPTS' 41629 Sometimes it is desirable that when building multiple versions of 41630 'libgcc.a' certain options should always be passed on to the 41631 compiler. In that case, set 'MULTILIB_EXTRA_OPTS' to be the list 41632 of options to be used for all builds. If you set this, you should 41633 probably set 'CRTSTUFF_T_CFLAGS' to a dash followed by it. 41634 41635'MULTILIB_OSDIRNAMES' 41636 If 'MULTILIB_OPTIONS' is used, this variable specifies a list of 41637 subdirectory names, that are used to modify the search path 41638 depending on the chosen multilib. Unlike 'MULTILIB_DIRNAMES', 41639 'MULTILIB_OSDIRNAMES' describes the multilib directories using 41640 operating systems conventions, and is applied to the directories 41641 such as 'lib' or those in the 'LIBRARY_PATH' environment variable. 41642 The format is either the same as of 'MULTILIB_DIRNAMES', or a set 41643 of mappings. When it is the same as 'MULTILIB_DIRNAMES', it 41644 describes the multilib directories using operating system 41645 conventions, rather than GCC conventions. When it is a set of 41646 mappings of the form GCCDIR=OSDIR, the left side gives the GCC 41647 convention and the right gives the equivalent OS defined location. 41648 If the OSDIR part begins with a '!', GCC will not search in the 41649 non-multilib directory and use exclusively the multilib directory. 41650 Otherwise, the compiler will examine the search path for libraries 41651 and crt files twice; the first time it will add MULTILIB to each 41652 directory in the search path, the second it will not. 41653 41654 For configurations that support both multilib and multiarch, 41655 'MULTILIB_OSDIRNAMES' also encodes the multiarch name, thus 41656 subsuming 'MULTIARCH_DIRNAME'. The multiarch name is appended to 41657 each directory name, separated by a colon (e.g. 41658 '../lib32:i386-linux-gnu'). 41659 41660 Each multiarch subdirectory will be searched before the 41661 corresponding OS multilib directory, for example 41662 '/lib/i386-linux-gnu' before '/lib/../lib32'. The multiarch name 41663 will also be used to modify the system header search path, as 41664 explained for 'MULTIARCH_DIRNAME'. 41665 41666'MULTIARCH_DIRNAME' 41667 This variable specifies the multiarch name for configurations that 41668 are multiarch-enabled but not multilibbed configurations. 41669 41670 The multiarch name is used to augment the search path for 41671 libraries, crt files and system header files with additional 41672 locations. The compiler will add a multiarch subdirectory of the 41673 form PREFIX/MULTIARCH before each directory in the library and crt 41674 search path. It will also add two directories 41675 'LOCAL_INCLUDE_DIR'/MULTIARCH and 41676 'NATIVE_SYSTEM_HEADER_DIR'/MULTIARCH) to the system header search 41677 path, respectively before 'LOCAL_INCLUDE_DIR' and 41678 'NATIVE_SYSTEM_HEADER_DIR'. 41679 41680 'MULTIARCH_DIRNAME' is not used for configurations that support 41681 both multilib and multiarch. In that case, multiarch names are 41682 encoded in 'MULTILIB_OSDIRNAMES' instead. 41683 41684 More documentation about multiarch can be found at 41685 <https://wiki.debian.org/Multiarch>. 41686 41687'SPECS' 41688 Unfortunately, setting 'MULTILIB_EXTRA_OPTS' is not enough, since 41689 it does not affect the build of target libraries, at least not the 41690 build of the default multilib. One possible work-around is to use 41691 'DRIVER_SELF_SPECS' to bring options from the 'specs' file as if 41692 they had been passed in the compiler driver command line. However, 41693 you don't want to be adding these options after the toolchain is 41694 installed, so you can instead tweak the 'specs' file that will be 41695 used during the toolchain build, while you still install the 41696 original, built-in 'specs'. The trick is to set 'SPECS' to some 41697 other filename (say 'specs.install'), that will then be created out 41698 of the built-in specs, and introduce a 'Makefile' rule to generate 41699 the 'specs' file that's going to be used at build time out of your 41700 'specs.install'. 41701 41702'T_CFLAGS' 41703 These are extra flags to pass to the C compiler. They are used 41704 both when building GCC, and when compiling things with the 41705 just-built GCC. This variable is deprecated and should not be 41706 used. 41707 41708 41709File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments 41710 4171120.2 Host Makefile Fragments 41712============================ 41713 41714The use of 'x-HOST' fragments is discouraged. You should only use it 41715for makefile dependencies. 41716 41717 41718File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top 41719 4172021 'collect2' 41721************* 41722 41723GCC uses a utility called 'collect2' on nearly all systems to arrange to 41724call various initialization functions at start time. 41725 41726 The program 'collect2' works by linking the program once and looking 41727through the linker output file for symbols with particular names 41728indicating they are constructor functions. If it finds any, it creates 41729a new temporary '.c' file containing a table of them, compiles it, and 41730links the program a second time including that file. 41731 41732 The actual calls to the constructors are carried out by a subroutine 41733called '__main', which is called (automatically) at the beginning of the 41734body of 'main' (provided 'main' was compiled with GNU CC). Calling 41735'__main' is necessary, even when compiling C code, to allow linking C 41736and C++ object code together. (If you use '-nostdlib', you get an 41737unresolved reference to '__main', since it's defined in the standard GCC 41738library. Include '-lgcc' at the end of your compiler command line to 41739resolve this reference.) 41740 41741 The program 'collect2' is installed as 'ld' in the directory where the 41742passes of the compiler are installed. When 'collect2' needs to find the 41743_real_ 'ld', it tries the following file names: 41744 41745 * a hard coded linker file name, if GCC was configured with the 41746 '--with-ld' option. 41747 41748 * 'real-ld' in the directories listed in the compiler's search 41749 directories. 41750 41751 * 'real-ld' in the directories listed in the environment variable 41752 'PATH'. 41753 41754 * The file specified in the 'REAL_LD_FILE_NAME' configuration macro, 41755 if specified. 41756 41757 * 'ld' in the compiler's search directories, except that 'collect2' 41758 will not execute itself recursively. 41759 41760 * 'ld' in 'PATH'. 41761 41762 "The compiler's search directories" means all the directories where 41763'gcc' searches for passes of the compiler. This includes directories 41764that you specify with '-B'. 41765 41766 Cross-compilers search a little differently: 41767 41768 * 'real-ld' in the compiler's search directories. 41769 41770 * 'TARGET-real-ld' in 'PATH'. 41771 41772 * The file specified in the 'REAL_LD_FILE_NAME' configuration macro, 41773 if specified. 41774 41775 * 'ld' in the compiler's search directories. 41776 41777 * 'TARGET-ld' in 'PATH'. 41778 41779 'collect2' explicitly avoids running 'ld' using the file name under 41780which 'collect2' itself was invoked. In fact, it remembers up a list of 41781such names--in case one copy of 'collect2' finds another copy (or 41782version) of 'collect2' installed as 'ld' in a second place in the search 41783path. 41784 41785 'collect2' searches for the utilities 'nm' and 'strip' using the same 41786algorithm as above for 'ld'. 41787 41788 41789File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top 41790 4179122 Standard Header File Directories 41792*********************************** 41793 41794'GCC_INCLUDE_DIR' means the same thing for native and cross. It is 41795where GCC stores its private include files, and also where GCC stores 41796the fixed include files. A cross compiled GCC runs 'fixincludes' on the 41797header files in '$(tooldir)/include'. (If the cross compilation header 41798files need to be fixed, they must be installed before GCC is built. If 41799the cross compilation header files are already suitable for GCC, nothing 41800special need be done). 41801 41802 'GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It 41803is where 'g++' looks first for header files. The C++ library installs 41804only target independent header files in that directory. 41805 41806 'LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't 41807install anything there. It is normally '/usr/local/include'. This is 41808where local additions to a packaged system should place header files. 41809 41810 'CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't 41811install anything there. 41812 41813 'TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is 41814the place for other packages to install header files that GCC will use. 41815For a cross-compiler, this is the equivalent of '/usr/include'. When 41816you build a cross-compiler, 'fixincludes' processes any header files in 41817this directory. 41818 41819 41820File: gccint.info, Node: Type Information, Next: Plugins, Prev: Header Dirs, Up: Top 41821 4182223 Memory Management and Type Information 41823***************************************** 41824 41825GCC uses some fairly sophisticated memory management techniques, which 41826involve determining information about GCC's data structures from GCC's 41827source code and using this information to perform garbage collection and 41828implement precompiled headers. 41829 41830 A full C++ parser would be too complicated for this task, so a limited 41831subset of C++ is interpreted and special markers are used to determine 41832what parts of the source to look at. All 'struct', 'union' and 41833'template' structure declarations that define data structures that are 41834allocated under control of the garbage collector must be marked. All 41835global variables that hold pointers to garbage-collected memory must 41836also be marked. Finally, all global variables that need to be saved and 41837restored by a precompiled header must be marked. (The precompiled 41838header mechanism can only save static variables if they're scalar. 41839Complex data structures must be allocated in garbage-collected memory to 41840be saved in a precompiled header.) 41841 41842 The full format of a marker is 41843 GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...)) 41844but in most cases no options are needed. The outer double parentheses 41845are still necessary, though: 'GTY(())'. Markers can appear: 41846 41847 * In a structure definition, before the open brace; 41848 * In a global variable declaration, after the keyword 'static' or 41849 'extern'; and 41850 * In a structure field definition, before the name of the field. 41851 41852 Here are some examples of marking simple data structures and globals. 41853 41854 struct GTY(()) TAG 41855 { 41856 FIELDS... 41857 }; 41858 41859 typedef struct GTY(()) TAG 41860 { 41861 FIELDS... 41862 } *TYPENAME; 41863 41864 static GTY(()) struct TAG *LIST; /* points to GC memory */ 41865 static GTY(()) int COUNTER; /* save counter in a PCH */ 41866 41867 The parser understands simple typedefs such as 'typedef struct TAG 41868*NAME;' and 'typedef int NAME;'. These don't need to be marked. 41869 41870 Since 'gengtype''s understanding of C++ is limited, there are several 41871constructs and declarations that are not supported inside 41872classes/structures marked for automatic GC code generation. The 41873following C++ constructs produce a 'gengtype' error on 41874structures/classes marked for automatic GC code generation: 41875 41876 * Type definitions inside classes/structures are not supported. 41877 * Enumerations inside classes/structures are not supported. 41878 41879 If you have a class or structure using any of the above constructs, you 41880need to mark that class as 'GTY ((user))' and provide your own marking 41881routines (see section *note User GC:: for details). 41882 41883 It is always valid to include function definitions inside classes. 41884Those are always ignored by 'gengtype', as it only cares about data 41885members. 41886 41887* Menu: 41888 41889* GTY Options:: What goes inside a 'GTY(())'. 41890* Inheritance and GTY:: Adding GTY to a class hierarchy. 41891* User GC:: Adding user-provided GC marking routines. 41892* GGC Roots:: Making global variables GGC roots. 41893* Files:: How the generated files work. 41894* Invoking the garbage collector:: How to invoke the garbage collector. 41895* Troubleshooting:: When something does not work as expected. 41896 41897 41898File: gccint.info, Node: GTY Options, Next: Inheritance and GTY, Up: Type Information 41899 4190023.1 The Inside of a 'GTY(())' 41901============================== 41902 41903Sometimes the C code is not enough to fully describe the type structure. 41904Extra information can be provided with 'GTY' options and additional 41905markers. Some options take a parameter, which may be either a string or 41906a type name, depending on the parameter. If an option takes no 41907parameter, it is acceptable either to omit the parameter entirely, or to 41908provide an empty string as a parameter. For example, 'GTY ((skip))' and 41909'GTY ((skip ("")))' are equivalent. 41910 41911 When the parameter is a string, often it is a fragment of C code. Four 41912special escapes may be used in these strings, to refer to pieces of the 41913data structure being marked: 41914 41915'%h' 41916 The current structure. 41917'%1' 41918 The structure that immediately contains the current structure. 41919'%0' 41920 The outermost structure that contains the current structure. 41921'%a' 41922 A partial expression of the form '[i1][i2]...' that indexes the 41923 array item currently being marked. 41924 41925 For instance, suppose that you have a structure of the form 41926 struct A { 41927 ... 41928 }; 41929 struct B { 41930 struct A foo[12]; 41931 }; 41932and 'b' is a variable of type 'struct B'. When marking 'b.foo[11]', 41933'%h' would expand to 'b.foo[11]', '%0' and '%1' would both expand to 41934'b', and '%a' would expand to '[11]'. 41935 41936 As in ordinary C, adjacent strings will be concatenated; this is 41937helpful when you have a complicated expression. 41938 GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE" 41939 " ? TYPE_NEXT_VARIANT (&%h.generic)" 41940 " : TREE_CHAIN (&%h.generic)"))) 41941 41942 The available options are: 41943 41944'length ("EXPRESSION")' 41945 41946 There are two places the type machinery will need to be explicitly 41947 told the length of an array of non-atomic objects. The first case 41948 is when a structure ends in a variable-length array, like this: 41949 struct GTY(()) rtvec_def { 41950 int num_elem; /* number of elements */ 41951 rtx GTY ((length ("%h.num_elem"))) elem[1]; 41952 }; 41953 41954 In this case, the 'length' option is used to override the specified 41955 array length (which should usually be '1'). The parameter of the 41956 option is a fragment of C code that calculates the length. 41957 41958 The second case is when a structure or a global variable contains a 41959 pointer to an array, like this: 41960 struct gimple_omp_for_iter * GTY((length ("%h.collapse"))) iter; 41961 In this case, 'iter' has been allocated by writing something like 41962 x->iter = ggc_alloc_cleared_vec_gimple_omp_for_iter (collapse); 41963 and the 'collapse' provides the length of the field. 41964 41965 This second use of 'length' also works on global variables, like: 41966 static GTY((length("reg_known_value_size"))) rtx *reg_known_value; 41967 41968 Note that the 'length' option is only meant for use with arrays of 41969 non-atomic objects, that is, objects that contain pointers pointing 41970 to other GTY-managed objects. For other GC-allocated arrays and 41971 strings you should use 'atomic'. 41972 41973'skip' 41974 41975 If 'skip' is applied to a field, the type machinery will ignore it. 41976 This is somewhat dangerous; the only safe use is in a union when 41977 one field really isn't ever used. 41978 41979'for_user' 41980 41981 Use this to mark types that need to be marked by user gc routines, 41982 but are not refered to in a template argument. So if you have some 41983 user gc type T1 and a non user gc type T2 you can give T2 the 41984 for_user option so that the marking functions for T1 can call non 41985 mangled functions to mark T2. 41986 41987'desc ("EXPRESSION")' 41988'tag ("CONSTANT")' 41989'default' 41990 41991 The type machinery needs to be told which field of a 'union' is 41992 currently active. This is done by giving each field a constant 41993 'tag' value, and then specifying a discriminator using 'desc'. The 41994 value of the expression given by 'desc' is compared against each 41995 'tag' value, each of which should be different. If no 'tag' is 41996 matched, the field marked with 'default' is used if there is one, 41997 otherwise no field in the union will be marked. 41998 41999 In the 'desc' option, the "current structure" is the union that it 42000 discriminates. Use '%1' to mean the structure containing it. 42001 There are no escapes available to the 'tag' option, since it is a 42002 constant. 42003 42004 For example, 42005 struct GTY(()) tree_binding 42006 { 42007 struct tree_common common; 42008 union tree_binding_u { 42009 tree GTY ((tag ("0"))) scope; 42010 struct cp_binding_level * GTY ((tag ("1"))) level; 42011 } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope; 42012 tree value; 42013 }; 42014 42015 In this example, the value of BINDING_HAS_LEVEL_P when applied to a 42016 'struct tree_binding *' is presumed to be 0 or 1. If 1, the type 42017 mechanism will treat the field 'level' as being present and if 0, 42018 will treat the field 'scope' as being present. 42019 42020 The 'desc' and 'tag' options can also be used for inheritance to 42021 denote which subclass an instance is. See *note Inheritance and 42022 GTY:: for more information. 42023 42024'cache' 42025 42026 When the 'cache' option is applied to a global variable 42027 gt_clear_cache is called on that variable between the mark and 42028 sweep phases of garbage collection. The gt_clear_cache function is 42029 free to mark blocks as used, or to clear pointers in the variable. 42030 42031'deletable' 42032 42033 'deletable', when applied to a global variable, indicates that when 42034 garbage collection runs, there's no need to mark anything pointed 42035 to by this variable, it can just be set to 'NULL' instead. This is 42036 used to keep a list of free structures around for re-use. 42037 42038'maybe_undef' 42039 42040 When applied to a field, 'maybe_undef' indicates that it's OK if 42041 the structure that this fields points to is never defined, so long 42042 as this field is always 'NULL'. This is used to avoid requiring 42043 backends to define certain optional structures. It doesn't work 42044 with language frontends. 42045 42046'nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")' 42047 42048 The type machinery expects all pointers to point to the start of an 42049 object. Sometimes for abstraction purposes it's convenient to have 42050 a pointer which points inside an object. So long as it's possible 42051 to convert the original object to and from the pointer, such 42052 pointers can still be used. TYPE is the type of the original 42053 object, the TO EXPRESSION returns the pointer given the original 42054 object, and the FROM EXPRESSION returns the original object given 42055 the pointer. The pointer will be available using the '%h' escape. 42056 42057'chain_next ("EXPRESSION")' 42058'chain_prev ("EXPRESSION")' 42059'chain_circular ("EXPRESSION")' 42060 42061 It's helpful for the type machinery to know if objects are often 42062 chained together in long lists; this lets it generate code that 42063 uses less stack space by iterating along the list instead of 42064 recursing down it. 'chain_next' is an expression for the next item 42065 in the list, 'chain_prev' is an expression for the previous item. 42066 For singly linked lists, use only 'chain_next'; for doubly linked 42067 lists, use both. The machinery requires that taking the next item 42068 of the previous item gives the original item. 'chain_circular' is 42069 similar to 'chain_next', but can be used for circular single linked 42070 lists. 42071 42072'reorder ("FUNCTION NAME")' 42073 42074 Some data structures depend on the relative ordering of pointers. 42075 If the precompiled header machinery needs to change that ordering, 42076 it will call the function referenced by the 'reorder' option, 42077 before changing the pointers in the object that's pointed to by the 42078 field the option applies to. The function must take four 42079 arguments, with the signature 42080 'void *, void *, gt_pointer_operator, void *'. The first parameter 42081 is a pointer to the structure that contains the object being 42082 updated, or the object itself if there is no containing structure. 42083 The second parameter is a cookie that should be ignored. The third 42084 parameter is a routine that, given a pointer, will update it to its 42085 correct new value. The fourth parameter is a cookie that must be 42086 passed to the second parameter. 42087 42088 PCH cannot handle data structures that depend on the absolute 42089 values of pointers. 'reorder' functions can be expensive. When 42090 possible, it is better to depend on properties of the data, like an 42091 ID number or the hash of a string instead. 42092 42093'atomic' 42094 42095 The 'atomic' option can only be used with pointers. It informs the 42096 GC machinery that the memory that the pointer points to does not 42097 contain any pointers, and hence it should be treated by the GC and 42098 PCH machinery as an "atomic" block of memory that does not need to 42099 be examined when scanning memory for pointers. In particular, the 42100 machinery will not scan that memory for pointers to mark them as 42101 reachable (when marking pointers for GC) or to relocate them (when 42102 writing a PCH file). 42103 42104 The 'atomic' option differs from the 'skip' option. 'atomic' keeps 42105 the memory under Garbage Collection, but makes the GC ignore the 42106 contents of the memory. 'skip' is more drastic in that it causes 42107 the pointer and the memory to be completely ignored by the Garbage 42108 Collector. So, memory marked as 'atomic' is automatically freed 42109 when no longer reachable, while memory marked as 'skip' is not. 42110 42111 The 'atomic' option must be used with great care, because all sorts 42112 of problem can occur if used incorrectly, that is, if the memory 42113 the pointer points to does actually contain a pointer. 42114 42115 Here is an example of how to use it: 42116 struct GTY(()) my_struct { 42117 int number_of_elements; 42118 unsigned int * GTY ((atomic)) elements; 42119 }; 42120 In this case, 'elements' is a pointer under GC, and the memory it 42121 points to needs to be allocated using the Garbage Collector, and 42122 will be freed automatically by the Garbage Collector when it is no 42123 longer referenced. But the memory that the pointer points to is an 42124 array of 'unsigned int' elements, and the GC must not try to scan 42125 it to find pointers to mark or relocate, which is why it is marked 42126 with the 'atomic' option. 42127 42128 Note that, currently, global variables can not be marked with 42129 'atomic'; only fields of a struct can. This is a known limitation. 42130 It would be useful to be able to mark global pointers with 'atomic' 42131 to make the PCH machinery aware of them so that they are saved and 42132 restored correctly to PCH files. 42133 42134'special ("NAME")' 42135 42136 The 'special' option is used to mark types that have to be dealt 42137 with by special case machinery. The parameter is the name of the 42138 special case. See 'gengtype.c' for further details. Avoid adding 42139 new special cases unless there is no other alternative. 42140 42141'user' 42142 42143 The 'user' option indicates that the code to mark structure fields 42144 is completely handled by user-provided routines. See section *note 42145 User GC:: for details on what functions need to be provided. 42146 42147 42148File: gccint.info, Node: Inheritance and GTY, Next: User GC, Prev: GTY Options, Up: Type Information 42149 4215023.2 Support for inheritance 42151============================ 42152 42153gengtype has some support for simple class hierarchies. You can use 42154this to have gengtype autogenerate marking routines, provided: 42155 42156 * There must be a concrete base class, with a discriminator 42157 expression that can be used to identify which subclass an instance 42158 is. 42159 * Only single inheritance is used. 42160 * None of the classes within the hierarchy are templates. 42161 42162 If your class hierarchy does not fit in this pattern, you must use 42163*note User GC:: instead. 42164 42165 The base class and its discriminator must be identified using the 42166"desc" option. Each concrete subclass must use the "tag" option to 42167identify which value of the discriminator it corresponds to. 42168 42169 Every class in the hierarchy must have a 'GTY(())' marker, as gengtype 42170will only attempt to parse classes that have such a marker (1). 42171 42172 class GTY((desc("%h.kind"), tag("0"))) example_base 42173 { 42174 public: 42175 int kind; 42176 tree a; 42177 }; 42178 42179 class GTY((tag("1"))) some_subclass : public example_base 42180 { 42181 public: 42182 tree b; 42183 }; 42184 42185 class GTY((tag("2"))) some_other_subclass : public example_base 42186 { 42187 public: 42188 tree c; 42189 }; 42190 42191 The generated marking routines for the above will contain a "switch" on 42192"kind", visiting all appropriate fields. For example, if kind is 2, it 42193will cast to "some_other_subclass" and visit fields a, b, and c. 42194 42195 ---------- Footnotes ---------- 42196 42197 (1) Classes lacking such a marker will not be identified as being 42198part of the hierarchy, and so the marking routines will not handle them, 42199leading to a assertion failure within the marking routines due to an 42200unknown tag value (assuming that assertions are enabled). 42201 42202 42203File: gccint.info, Node: User GC, Next: GGC Roots, Prev: Inheritance and GTY, Up: Type Information 42204 4220523.3 Support for user-provided GC marking routines 42206================================================== 42207 42208The garbage collector supports types for which no automatic marking code 42209is generated. For these types, the user is required to provide three 42210functions: one to act as a marker for garbage collection, and two 42211functions to act as marker and pointer walker for pre-compiled headers. 42212 42213 Given a structure 'struct GTY((user)) my_struct', the following 42214functions should be defined to mark 'my_struct': 42215 42216 void gt_ggc_mx (my_struct *p) 42217 { 42218 /* This marks field 'fld'. */ 42219 gt_ggc_mx (p->fld); 42220 } 42221 42222 void gt_pch_nx (my_struct *p) 42223 { 42224 /* This marks field 'fld'. */ 42225 gt_pch_nx (tp->fld); 42226 } 42227 42228 void gt_pch_nx (my_struct *p, gt_pointer_operator op, void *cookie) 42229 { 42230 /* For every field 'fld', call the given pointer operator. */ 42231 op (&(tp->fld), cookie); 42232 } 42233 42234 In general, each marker 'M' should call 'M' for every pointer field in 42235the structure. Fields that are not allocated in GC or are not pointers 42236must be ignored. 42237 42238 For embedded lists (e.g., structures with a 'next' or 'prev' pointer), 42239the marker must follow the chain and mark every element in it. 42240 42241 Note that the rules for the pointer walker 'gt_pch_nx (my_struct *, 42242gt_pointer_operator, void *)' are slightly different. In this case, the 42243operation 'op' must be applied to the _address_ of every pointer field. 42244 4224523.3.1 User-provided marking routines for template types 42246-------------------------------------------------------- 42247 42248When a template type 'TP' is marked with 'GTY', all instances of that 42249type are considered user-provided types. This means that the individual 42250instances of 'TP' do not need to be marked with 'GTY'. The user needs 42251to provide template functions to mark all the fields of the type. 42252 42253 The following code snippets represent all the functions that need to be 42254provided. Note that type 'TP' may reference to more than one type. In 42255these snippets, there is only one type 'T', but there could be more. 42256 42257 template<typename T> 42258 void gt_ggc_mx (TP<T> *tp) 42259 { 42260 extern void gt_ggc_mx (T&); 42261 42262 /* This marks field 'fld' of type 'T'. */ 42263 gt_ggc_mx (tp->fld); 42264 } 42265 42266 template<typename T> 42267 void gt_pch_nx (TP<T> *tp) 42268 { 42269 extern void gt_pch_nx (T&); 42270 42271 /* This marks field 'fld' of type 'T'. */ 42272 gt_pch_nx (tp->fld); 42273 } 42274 42275 template<typename T> 42276 void gt_pch_nx (TP<T *> *tp, gt_pointer_operator op, void *cookie) 42277 { 42278 /* For every field 'fld' of 'tp' with type 'T *', call the given 42279 pointer operator. */ 42280 op (&(tp->fld), cookie); 42281 } 42282 42283 template<typename T> 42284 void gt_pch_nx (TP<T> *tp, gt_pointer_operator, void *cookie) 42285 { 42286 extern void gt_pch_nx (T *, gt_pointer_operator, void *); 42287 42288 /* For every field 'fld' of 'tp' with type 'T', call the pointer 42289 walker for all the fields of T. */ 42290 gt_pch_nx (&(tp->fld), op, cookie); 42291 } 42292 42293 Support for user-defined types is currently limited. The following 42294restrictions apply: 42295 42296 1. Type 'TP' and all the argument types 'T' must be marked with 'GTY'. 42297 42298 2. Type 'TP' can only have type names in its argument list. 42299 42300 3. The pointer walker functions are different for 'TP<T>' and 'TP<T 42301 *>'. In the case of 'TP<T>', references to 'T' must be handled by 42302 calling 'gt_pch_nx' (which will, in turn, walk all the pointers 42303 inside fields of 'T'). In the case of 'TP<T *>', references to 'T 42304 *' must be handled by calling the 'op' function on the address of 42305 the pointer (see the code snippets above). 42306 42307 42308File: gccint.info, Node: GGC Roots, Next: Files, Prev: User GC, Up: Type Information 42309 4231023.4 Marking Roots for the Garbage Collector 42311============================================ 42312 42313In addition to keeping track of types, the type machinery also locates 42314the global variables ("roots") that the garbage collector starts at. 42315Roots must be declared using one of the following syntaxes: 42316 42317 * 'extern GTY(([OPTIONS])) TYPE NAME;' 42318 * 'static GTY(([OPTIONS])) TYPE NAME;' 42319The syntax 42320 * 'GTY(([OPTIONS])) TYPE NAME;' 42321is _not_ accepted. There should be an 'extern' declaration of such a 42322variable in a header somewhere--mark that, not the definition. Or, if 42323the variable is only used in one file, make it 'static'. 42324 42325 42326File: gccint.info, Node: Files, Next: Invoking the garbage collector, Prev: GGC Roots, Up: Type Information 42327 4232823.5 Source Files Containing Type Information 42329============================================= 42330 42331Whenever you add 'GTY' markers to a source file that previously had 42332none, or create a new source file containing 'GTY' markers, there are 42333three things you need to do: 42334 42335 1. You need to add the file to the list of source files the type 42336 machinery scans. There are four cases: 42337 42338 a. For a back-end file, this is usually done automatically; if 42339 not, you should add it to 'target_gtfiles' in the appropriate 42340 port's entries in 'config.gcc'. 42341 42342 b. For files shared by all front ends, add the filename to the 42343 'GTFILES' variable in 'Makefile.in'. 42344 42345 c. For files that are part of one front end, add the filename to 42346 the 'gtfiles' variable defined in the appropriate 42347 'config-lang.in'. Headers should appear before non-headers in 42348 this list. 42349 42350 d. For files that are part of some but not all front ends, add 42351 the filename to the 'gtfiles' variable of _all_ the front ends 42352 that use it. 42353 42354 2. If the file was a header file, you'll need to check that it's 42355 included in the right place to be visible to the generated files. 42356 For a back-end header file, this should be done automatically. For 42357 a front-end header file, it needs to be included by the same file 42358 that includes 'gtype-LANG.h'. For other header files, it needs to 42359 be included in 'gtype-desc.c', which is a generated file, so add it 42360 to 'ifiles' in 'open_base_file' in 'gengtype.c'. 42361 42362 For source files that aren't header files, the machinery will 42363 generate a header file that should be included in the source file 42364 you just changed. The file will be called 'gt-PATH.h' where PATH 42365 is the pathname relative to the 'gcc' directory with slashes 42366 replaced by -, so for example the header file to be included in 42367 'cp/parser.c' is called 'gt-cp-parser.c'. The generated header 42368 file should be included after everything else in the source file. 42369 Don't forget to mention this file as a dependency in the 42370 'Makefile'! 42371 42372 For language frontends, there is another file that needs to be included 42373somewhere. It will be called 'gtype-LANG.h', where LANG is the name of 42374the subdirectory the language is contained in. 42375 42376 Plugins can add additional root tables. Run the 'gengtype' utility in 42377plugin mode as 'gengtype -P pluginout.h SOURCE-DIR FILE-LIST PLUGIN*.C' 42378with your plugin files PLUGIN*.C using 'GTY' to generate the PLUGINOUT.H 42379file. The GCC build tree is needed to be present in that mode. 42380 42381 42382File: gccint.info, Node: Invoking the garbage collector, Next: Troubleshooting, Prev: Files, Up: Type Information 42383 4238423.6 How to invoke the garbage collector 42385======================================== 42386 42387The GCC garbage collector GGC is only invoked explicitly. In contrast 42388with many other garbage collectors, it is not implicitly invoked by 42389allocation routines when a lot of memory has been consumed. So the only 42390way to have GGC reclaim storage is to call the 'ggc_collect' function 42391explicitly. This call is an expensive operation, as it may have to scan 42392the entire heap. Beware that local variables (on the GCC call stack) 42393are not followed by such an invocation (as many other garbage collectors 42394do): you should reference all your data from static or external 'GTY'-ed 42395variables, and it is advised to call 'ggc_collect' with a shallow call 42396stack. The GGC is an exact mark and sweep garbage collector (so it does 42397not scan the call stack for pointers). In practice GCC passes don't 42398often call 'ggc_collect' themselves, because it is called by the pass 42399manager between passes. 42400 42401 At the time of the 'ggc_collect' call all pointers in the GC-marked 42402structures must be valid or 'NULL'. In practice this means that there 42403should not be uninitialized pointer fields in the structures even if 42404your code never reads or writes those fields at a particular instance. 42405One way to ensure this is to use cleared versions of allocators unless 42406all the fields are initialized manually immediately after allocation. 42407 42408 42409File: gccint.info, Node: Troubleshooting, Prev: Invoking the garbage collector, Up: Type Information 42410 4241123.7 Troubleshooting the garbage collector 42412========================================== 42413 42414With the current garbage collector implementation, most issues should 42415show up as GCC compilation errors. Some of the most commonly 42416encountered issues are described below. 42417 42418 * Gengtype does not produce allocators for a 'GTY'-marked type. 42419 Gengtype checks if there is at least one possible path from GC 42420 roots to at least one instance of each type before outputting 42421 allocators. If there is no such path, the 'GTY' markers will be 42422 ignored and no allocators will be output. Solve this by making 42423 sure that there exists at least one such path. If creating it is 42424 unfeasible or raises a "code smell", consider if you really must 42425 use GC for allocating such type. 42426 42427 * Link-time errors about undefined 'gt_ggc_r_foo_bar' and 42428 similarly-named symbols. Check if your 'foo_bar' source file has 42429 '#include "gt-foo_bar.h"' as its very last line. 42430 42431 42432File: gccint.info, Node: Plugins, Next: LTO, Prev: Type Information, Up: Top 42433 4243424 Plugins 42435********** 42436 42437GCC plugins are loadable modules that provide extra features to the 42438compiler. Like GCC itself they can be distributed in source and binary 42439forms. 42440 42441 GCC plugins provide developers with a rich subset of the GCC API to 42442allow them to extend GCC as they see fit. Whether it is writing an 42443additional optimization pass, transforming code, or analyzing 42444information, plugins can be quite useful. 42445 42446* Menu: 42447 42448* Plugins loading:: How can we load plugins. 42449* Plugin API:: The APIs for plugins. 42450* Plugins pass:: How a plugin interact with the pass manager. 42451* Plugins GC:: How a plugin Interact with GCC Garbage Collector. 42452* Plugins description:: Giving information about a plugin itself. 42453* Plugins attr:: Registering custom attributes or pragmas. 42454* Plugins recording:: Recording information about pass execution. 42455* Plugins gate:: Controlling which passes are being run. 42456* Plugins tracking:: Keeping track of available passes. 42457* Plugins building:: How can we build a plugin. 42458 42459 42460File: gccint.info, Node: Plugins loading, Next: Plugin API, Up: Plugins 42461 4246224.1 Loading Plugins 42463==================== 42464 42465Plugins are supported on platforms that support '-ldl -rdynamic' as well 42466as Windows/MinGW. They are loaded by the compiler using 'dlopen' or 42467equivalent and invoked at pre-determined locations in the compilation 42468process. 42469 42470 Plugins are loaded with 42471 42472 '-fplugin=/path/to/NAME.EXT' '-fplugin-arg-NAME-KEY1[=VALUE1]' 42473 42474 Where NAME is the plugin name and EXT is the platform-specific dynamic 42475library extension. It should be 'dll' on Windows/MinGW, 'dylib' on 42476Darwin/Mac OS X, and 'so' on all other platforms. The plugin arguments 42477are parsed by GCC and passed to respective plugins as key-value pairs. 42478Multiple plugins can be invoked by specifying multiple '-fplugin' 42479arguments. 42480 42481 A plugin can be simply given by its short name (no dots or slashes). 42482When simply passing '-fplugin=NAME', the plugin is loaded from the 42483'plugin' directory, so '-fplugin=NAME' is the same as '-fplugin=`gcc 42484-print-file-name=plugin`/NAME.EXT', using backquote shell syntax to 42485query the 'plugin' directory. 42486 42487 42488File: gccint.info, Node: Plugin API, Next: Plugins pass, Prev: Plugins loading, Up: Plugins 42489 4249024.2 Plugin API 42491=============== 42492 42493Plugins are activated by the compiler at specific events as defined in 42494'gcc-plugin.h'. For each event of interest, the plugin should call 42495'register_callback' specifying the name of the event and address of the 42496callback function that will handle that event. 42497 42498 The header 'gcc-plugin.h' must be the first gcc header to be included. 42499 4250024.2.1 Plugin license check 42501--------------------------- 42502 42503Every plugin should define the global symbol 'plugin_is_GPL_compatible' 42504to assert that it has been licensed under a GPL-compatible license. If 42505this symbol does not exist, the compiler will emit a fatal error and 42506exit with the error message: 42507 42508 fatal error: plugin NAME is not licensed under a GPL-compatible license 42509 NAME: undefined symbol: plugin_is_GPL_compatible 42510 compilation terminated 42511 42512 The declared type of the symbol should be int, to match a forward 42513declaration in 'gcc-plugin.h' that suppresses C++ mangling. It does not 42514need to be in any allocated section, though. The compiler merely 42515asserts that the symbol exists in the global scope. Something like this 42516is enough: 42517 42518 int plugin_is_GPL_compatible; 42519 4252024.2.2 Plugin initialization 42521---------------------------- 42522 42523Every plugin should export a function called 'plugin_init' that is 42524called right after the plugin is loaded. This function is responsible 42525for registering all the callbacks required by the plugin and do any 42526other required initialization. 42527 42528 This function is called from 'compile_file' right before invoking the 42529parser. The arguments to 'plugin_init' are: 42530 42531 * 'plugin_info': Plugin invocation information. 42532 * 'version': GCC version. 42533 42534 The 'plugin_info' struct is defined as follows: 42535 42536 struct plugin_name_args 42537 { 42538 char *base_name; /* Short name of the plugin 42539 (filename without .so suffix). */ 42540 const char *full_name; /* Path to the plugin as specified with 42541 -fplugin=. */ 42542 int argc; /* Number of arguments specified with 42543 -fplugin-arg-.... */ 42544 struct plugin_argument *argv; /* Array of ARGC key-value pairs. */ 42545 const char *version; /* Version string provided by plugin. */ 42546 const char *help; /* Help string provided by plugin. */ 42547 } 42548 42549 If initialization fails, 'plugin_init' must return a non-zero value. 42550Otherwise, it should return 0. 42551 42552 The version of the GCC compiler loading the plugin is described by the 42553following structure: 42554 42555 struct plugin_gcc_version 42556 { 42557 const char *basever; 42558 const char *datestamp; 42559 const char *devphase; 42560 const char *revision; 42561 const char *configuration_arguments; 42562 }; 42563 42564 The function 'plugin_default_version_check' takes two pointers to such 42565structure and compare them field by field. It can be used by the 42566plugin's 'plugin_init' function. 42567 42568 The version of GCC used to compile the plugin can be found in the 42569symbol 'gcc_version' defined in the header 'plugin-version.h'. The 42570recommended version check to perform looks like 42571 42572 #include "plugin-version.h" 42573 ... 42574 42575 int 42576 plugin_init (struct plugin_name_args *plugin_info, 42577 struct plugin_gcc_version *version) 42578 { 42579 if (!plugin_default_version_check (version, &gcc_version)) 42580 return 1; 42581 42582 } 42583 42584 but you can also check the individual fields if you want a less strict 42585check. 42586 4258724.2.3 Plugin callbacks 42588----------------------- 42589 42590Callback functions have the following prototype: 42591 42592 /* The prototype for a plugin callback function. 42593 gcc_data - event-specific data provided by GCC 42594 user_data - plugin-specific data provided by the plug-in. */ 42595 typedef void (*plugin_callback_func)(void *gcc_data, void *user_data); 42596 42597 Callbacks can be invoked at the following pre-determined events: 42598 42599 enum plugin_event 42600 { 42601 PLUGIN_START_PARSE_FUNCTION, /* Called before parsing the body of a function. */ 42602 PLUGIN_FINISH_PARSE_FUNCTION, /* After finishing parsing a function. */ 42603 PLUGIN_PASS_MANAGER_SETUP, /* To hook into pass manager. */ 42604 PLUGIN_FINISH_TYPE, /* After finishing parsing a type. */ 42605 PLUGIN_FINISH_DECL, /* After finishing parsing a declaration. */ 42606 PLUGIN_FINISH_UNIT, /* Useful for summary processing. */ 42607 PLUGIN_PRE_GENERICIZE, /* Allows to see low level AST in C and C++ frontends. */ 42608 PLUGIN_FINISH, /* Called before GCC exits. */ 42609 PLUGIN_INFO, /* Information about the plugin. */ 42610 PLUGIN_GGC_START, /* Called at start of GCC Garbage Collection. */ 42611 PLUGIN_GGC_MARKING, /* Extend the GGC marking. */ 42612 PLUGIN_GGC_END, /* Called at end of GGC. */ 42613 PLUGIN_REGISTER_GGC_ROOTS, /* Register an extra GGC root table. */ 42614 PLUGIN_ATTRIBUTES, /* Called during attribute registration */ 42615 PLUGIN_START_UNIT, /* Called before processing a translation unit. */ 42616 PLUGIN_PRAGMAS, /* Called during pragma registration. */ 42617 /* Called before first pass from all_passes. */ 42618 PLUGIN_ALL_PASSES_START, 42619 /* Called after last pass from all_passes. */ 42620 PLUGIN_ALL_PASSES_END, 42621 /* Called before first ipa pass. */ 42622 PLUGIN_ALL_IPA_PASSES_START, 42623 /* Called after last ipa pass. */ 42624 PLUGIN_ALL_IPA_PASSES_END, 42625 /* Allows to override pass gate decision for current_pass. */ 42626 PLUGIN_OVERRIDE_GATE, 42627 /* Called before executing a pass. */ 42628 PLUGIN_PASS_EXECUTION, 42629 /* Called before executing subpasses of a GIMPLE_PASS in 42630 execute_ipa_pass_list. */ 42631 PLUGIN_EARLY_GIMPLE_PASSES_START, 42632 /* Called after executing subpasses of a GIMPLE_PASS in 42633 execute_ipa_pass_list. */ 42634 PLUGIN_EARLY_GIMPLE_PASSES_END, 42635 /* Called when a pass is first instantiated. */ 42636 PLUGIN_NEW_PASS, 42637 /* Called when a file is #include-d or given via the #line directive. 42638 This could happen many times. The event data is the included file path, 42639 as a const char* pointer. */ 42640 PLUGIN_INCLUDE_FILE, 42641 42642 PLUGIN_EVENT_FIRST_DYNAMIC /* Dummy event used for indexing callback 42643 array. */ 42644 }; 42645 42646 In addition, plugins can also look up the enumerator of a named event, 42647and / or generate new events dynamically, by calling the function 42648'get_named_event_id'. 42649 42650 To register a callback, the plugin calls 'register_callback' with the 42651arguments: 42652 42653 * 'char *name': Plugin name. 42654 * 'int event': The event code. 42655 * 'plugin_callback_func callback': The function that handles 'event'. 42656 * 'void *user_data': Pointer to plugin-specific data. 42657 42658 For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, and 42659PLUGIN_REGISTER_GGC_ROOTS pseudo-events the 'callback' should be null, 42660and the 'user_data' is specific. 42661 42662 When the PLUGIN_PRAGMAS event is triggered (with a null pointer as data 42663from GCC), plugins may register their own pragmas. Notice that pragmas 42664are not available from 'lto1', so plugins used with '-flto' option to 42665GCC during link-time optimization cannot use pragmas and do not even see 42666functions like 'c_register_pragma' or 'pragma_lex'. 42667 42668 The PLUGIN_INCLUDE_FILE event, with a 'const char*' file path as GCC 42669data, is triggered for processing of '#include' or '#line' directives. 42670 42671 The PLUGIN_FINISH event is the last time that plugins can call GCC 42672functions, notably emit diagnostics with 'warning', 'error' etc. 42673 42674 42675File: gccint.info, Node: Plugins pass, Next: Plugins GC, Prev: Plugin API, Up: Plugins 42676 4267724.3 Interacting with the pass manager 42678====================================== 42679 42680There needs to be a way to add/reorder/remove passes dynamically. This 42681is useful for both analysis plugins (plugging in after a certain pass 42682such as CFG or an IPA pass) and optimization plugins. 42683 42684 Basic support for inserting new passes or replacing existing passes is 42685provided. A plugin registers a new pass with GCC by calling 42686'register_callback' with the 'PLUGIN_PASS_MANAGER_SETUP' event and a 42687pointer to a 'struct register_pass_info' object defined as follows 42688 42689 enum pass_positioning_ops 42690 { 42691 PASS_POS_INSERT_AFTER, // Insert after the reference pass. 42692 PASS_POS_INSERT_BEFORE, // Insert before the reference pass. 42693 PASS_POS_REPLACE // Replace the reference pass. 42694 }; 42695 42696 struct register_pass_info 42697 { 42698 struct opt_pass *pass; /* New pass provided by the plugin. */ 42699 const char *reference_pass_name; /* Name of the reference pass for hooking 42700 up the new pass. */ 42701 int ref_pass_instance_number; /* Insert the pass at the specified 42702 instance number of the reference pass. */ 42703 /* Do it for every instance if it is 0. */ 42704 enum pass_positioning_ops pos_op; /* how to insert the new pass. */ 42705 }; 42706 42707 42708 /* Sample plugin code that registers a new pass. */ 42709 int 42710 plugin_init (struct plugin_name_args *plugin_info, 42711 struct plugin_gcc_version *version) 42712 { 42713 struct register_pass_info pass_info; 42714 42715 ... 42716 42717 /* Code to fill in the pass_info object with new pass information. */ 42718 42719 ... 42720 42721 /* Register the new pass. */ 42722 register_callback (plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &pass_info); 42723 42724 ... 42725 } 42726 42727 42728File: gccint.info, Node: Plugins GC, Next: Plugins description, Prev: Plugins pass, Up: Plugins 42729 4273024.4 Interacting with the GCC Garbage Collector 42731=============================================== 42732 42733Some plugins may want to be informed when GGC (the GCC Garbage 42734Collector) is running. They can register callbacks for the 42735'PLUGIN_GGC_START' and 'PLUGIN_GGC_END' events (for which the callback 42736is called with a null 'gcc_data') to be notified of the start or end of 42737the GCC garbage collection. 42738 42739 Some plugins may need to have GGC mark additional data. This can be 42740done by registering a callback (called with a null 'gcc_data') for the 42741'PLUGIN_GGC_MARKING' event. Such callbacks can call the 'ggc_set_mark' 42742routine, preferably through the 'ggc_mark' macro (and conversely, these 42743routines should usually not be used in plugins outside of the 42744'PLUGIN_GGC_MARKING' event). Plugins that wish to hold weak references 42745to gc data may also use this event to drop weak references when the 42746object is about to be collected. The 'ggc_marked_p' function can be 42747used to tell if an object is marked, or is about to be collected. The 42748'gt_clear_cache' overloads which some types define may also be of use in 42749managing weak references. 42750 42751 Some plugins may need to add extra GGC root tables, e.g. to handle 42752their own 'GTY'-ed data. This can be done with the 42753'PLUGIN_REGISTER_GGC_ROOTS' pseudo-event with a null callback and the 42754extra root table (of type 'struct ggc_root_tab*') as 'user_data'. 42755Running the 'gengtype -p SOURCE-DIR FILE-LIST PLUGIN*.C ...' utility 42756generates these extra root tables. 42757 42758 You should understand the details of memory management inside GCC 42759before using 'PLUGIN_GGC_MARKING' or 'PLUGIN_REGISTER_GGC_ROOTS'. 42760 42761 42762File: gccint.info, Node: Plugins description, Next: Plugins attr, Prev: Plugins GC, Up: Plugins 42763 4276424.5 Giving information about a plugin 42765====================================== 42766 42767A plugin should give some information to the user about itself. This 42768uses the following structure: 42769 42770 struct plugin_info 42771 { 42772 const char *version; 42773 const char *help; 42774 }; 42775 42776 Such a structure is passed as the 'user_data' by the plugin's init 42777routine using 'register_callback' with the 'PLUGIN_INFO' pseudo-event 42778and a null callback. 42779 42780 42781File: gccint.info, Node: Plugins attr, Next: Plugins recording, Prev: Plugins description, Up: Plugins 42782 4278324.6 Registering custom attributes or pragmas 42784============================================= 42785 42786For analysis (or other) purposes it is useful to be able to add custom 42787attributes or pragmas. 42788 42789 The 'PLUGIN_ATTRIBUTES' callback is called during attribute 42790registration. Use the 'register_attribute' function to register custom 42791attributes. 42792 42793 /* Attribute handler callback */ 42794 static tree 42795 handle_user_attribute (tree *node, tree name, tree args, 42796 int flags, bool *no_add_attrs) 42797 { 42798 return NULL_TREE; 42799 } 42800 42801 /* Attribute definition */ 42802 static struct attribute_spec user_attr = 42803 { "user", 1, 1, false, false, false, false, handle_user_attribute, NULL }; 42804 42805 /* Plugin callback called during attribute registration. 42806 Registered with register_callback (plugin_name, PLUGIN_ATTRIBUTES, register_attributes, NULL) 42807 */ 42808 static void 42809 register_attributes (void *event_data, void *data) 42810 { 42811 warning (0, G_("Callback to register attributes")); 42812 register_attribute (&user_attr); 42813 } 42814 42815 42816 The PLUGIN_PRAGMAS callback is called once during pragmas registration. 42817Use the 'c_register_pragma', 'c_register_pragma_with_data', 42818'c_register_pragma_with_expansion', 42819'c_register_pragma_with_expansion_and_data' functions to register custom 42820pragmas and their handlers (which often want to call 'pragma_lex') from 42821'c-family/c-pragma.h'. 42822 42823 /* Plugin callback called during pragmas registration. Registered with 42824 register_callback (plugin_name, PLUGIN_PRAGMAS, 42825 register_my_pragma, NULL); 42826 */ 42827 static void 42828 register_my_pragma (void *event_data, void *data) 42829 { 42830 warning (0, G_("Callback to register pragmas")); 42831 c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello); 42832 } 42833 42834 It is suggested to pass '"GCCPLUGIN"' (or a short name identifying your 42835plugin) as the "space" argument of your pragma. 42836 42837 Pragmas registered with 'c_register_pragma_with_expansion' or 42838'c_register_pragma_with_expansion_and_data' support preprocessor 42839expansions. For example: 42840 42841 #define NUMBER 10 42842 #pragma GCCPLUGIN foothreshold (NUMBER) 42843 42844 42845File: gccint.info, Node: Plugins recording, Next: Plugins gate, Prev: Plugins attr, Up: Plugins 42846 4284724.7 Recording information about pass execution 42848=============================================== 42849 42850The event PLUGIN_PASS_EXECUTION passes the pointer to the executed pass 42851(the same as current_pass) as 'gcc_data' to the callback. You can also 42852inspect cfun to find out about which function this pass is executed for. 42853Note that this event will only be invoked if the gate check (if 42854applicable, modified by PLUGIN_OVERRIDE_GATE) succeeds. You can use 42855other hooks, like 'PLUGIN_ALL_PASSES_START', 'PLUGIN_ALL_PASSES_END', 42856'PLUGIN_ALL_IPA_PASSES_START', 'PLUGIN_ALL_IPA_PASSES_END', 42857'PLUGIN_EARLY_GIMPLE_PASSES_START', and/or 42858'PLUGIN_EARLY_GIMPLE_PASSES_END' to manipulate global state in your 42859plugin(s) in order to get context for the pass execution. 42860 42861 42862File: gccint.info, Node: Plugins gate, Next: Plugins tracking, Prev: Plugins recording, Up: Plugins 42863 4286424.8 Controlling which passes are being run 42865=========================================== 42866 42867After the original gate function for a pass is called, its result - the 42868gate status - is stored as an integer. Then the event 42869'PLUGIN_OVERRIDE_GATE' is invoked, with a pointer to the gate status in 42870the 'gcc_data' parameter to the callback function. A nonzero value of 42871the gate status means that the pass is to be executed. You can both 42872read and write the gate status via the passed pointer. 42873 42874 42875File: gccint.info, Node: Plugins tracking, Next: Plugins building, Prev: Plugins gate, Up: Plugins 42876 4287724.9 Keeping track of available passes 42878====================================== 42879 42880When your plugin is loaded, you can inspect the various pass lists to 42881determine what passes are available. However, other plugins might add 42882new passes. Also, future changes to GCC might cause generic passes to 42883be added after plugin loading. When a pass is first added to one of the 42884pass lists, the event 'PLUGIN_NEW_PASS' is invoked, with the callback 42885parameter 'gcc_data' pointing to the new pass. 42886 42887 42888File: gccint.info, Node: Plugins building, Prev: Plugins tracking, Up: Plugins 42889 4289024.10 Building GCC plugins 42891========================== 42892 42893If plugins are enabled, GCC installs the headers needed to build a 42894plugin (somewhere in the installation tree, e.g. under '/usr/local'). 42895In particular a 'plugin/include' directory is installed, containing all 42896the header files needed to build plugins. 42897 42898 On most systems, you can query this 'plugin' directory by invoking 'gcc 42899-print-file-name=plugin' (replace if needed 'gcc' with the appropriate 42900program path). 42901 42902 Inside plugins, this 'plugin' directory name can be queried by calling 42903'default_plugin_dir_name ()'. 42904 42905 Plugins may know, when they are compiled, the GCC version for which 42906'plugin-version.h' is provided. The constant macros 42907'GCCPLUGIN_VERSION_MAJOR', 'GCCPLUGIN_VERSION_MINOR', 42908'GCCPLUGIN_VERSION_PATCHLEVEL', 'GCCPLUGIN_VERSION' are integer numbers, 42909so a plugin could ensure it is built for GCC 4.7 with 42910 #if GCCPLUGIN_VERSION != 4007 42911 #error this GCC plugin is for GCC 4.7 42912 #endif 42913 42914 The following GNU Makefile excerpt shows how to build a simple plugin: 42915 42916 HOST_GCC=g++ 42917 TARGET_GCC=gcc 42918 PLUGIN_SOURCE_FILES= plugin1.c plugin2.cc 42919 GCCPLUGINS_DIR:= $(shell $(TARGET_GCC) -print-file-name=plugin) 42920 CXXFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC -fno-rtti -O2 42921 42922 plugin.so: $(PLUGIN_SOURCE_FILES) 42923 $(HOST_GCC) -shared $(CXXFLAGS) $^ -o $@ 42924 42925 A single source file plugin may be built with 'g++ -I`gcc 42926-print-file-name=plugin`/include -fPIC -shared -fno-rtti -O2 plugin.c -o 42927plugin.so', using backquote shell syntax to query the 'plugin' 42928directory. 42929 42930 Plugin support on Windows/MinGW has a number of limitations and 42931additional requirements. When building a plugin on Windows we have to 42932link an import library for the corresponding backend executable, for 42933example, 'cc1.exe', 'cc1plus.exe', etc., in order to gain access to the 42934symbols provided by GCC. This means that on Windows a plugin is 42935language-specific, for example, for C, C++, etc. If you wish to use 42936your plugin with multiple languages, then you will need to build 42937multiple plugin libraries and either instruct your users on how to load 42938the correct version or provide a compiler wrapper that does this 42939automatically. 42940 42941 Additionally, on Windows the plugin library has to export the 42942'plugin_is_GPL_compatible' and 'plugin_init' symbols. If you do not 42943wish to modify the source code of your plugin, then you can use the 42944'-Wl,--export-all-symbols' option or provide a suitable DEF file. 42945Alternatively, you can export just these two symbols by decorating them 42946with '__declspec(dllexport)', for example: 42947 42948 #ifdef _WIN32 42949 __declspec(dllexport) 42950 #endif 42951 int plugin_is_GPL_compatible; 42952 42953 #ifdef _WIN32 42954 __declspec(dllexport) 42955 #endif 42956 int plugin_init (plugin_name_args *, plugin_gcc_version *) 42957 42958 The import libraries are installed into the 'plugin' directory and 42959their names are derived by appending the '.a' extension to the backend 42960executable names, for example, 'cc1.exe.a', 'cc1plus.exe.a', etc. The 42961following command line shows how to build the single source file plugin 42962on Windows to be used with the C++ compiler: 42963 42964 g++ -I`gcc -print-file-name=plugin`/include -shared -Wl,--export-all-symbols \ 42965 -o plugin.dll plugin.c `gcc -print-file-name=plugin`/cc1plus.exe.a 42966 42967 When a plugin needs to use 'gengtype', be sure that both 'gengtype' and 42968'gtype.state' have the same version as the GCC for which the plugin is 42969built. 42970 42971 42972File: gccint.info, Node: LTO, Next: Match and Simplify, Prev: Plugins, Up: Top 42973 4297425 Link Time Optimization 42975************************* 42976 42977Link Time Optimization (LTO) gives GCC the capability of dumping its 42978internal representation (GIMPLE) to disk, so that all the different 42979compilation units that make up a single executable can be optimized as a 42980single module. This expands the scope of inter-procedural optimizations 42981to encompass the whole program (or, rather, everything that is visible 42982at link time). 42983 42984* Menu: 42985 42986* LTO Overview:: Overview of LTO. 42987* LTO object file layout:: LTO file sections in ELF. 42988* IPA:: Using summary information in IPA passes. 42989* WHOPR:: Whole program assumptions, 42990 linker plugin and symbol visibilities. 42991* Internal flags:: Internal flags controlling 'lto1'. 42992 42993 42994File: gccint.info, Node: LTO Overview, Next: LTO object file layout, Up: LTO 42995 4299625.1 Design Overview 42997==================== 42998 42999Link time optimization is implemented as a GCC front end for a bytecode 43000representation of GIMPLE that is emitted in special sections of '.o' 43001files. Currently, LTO support is enabled in most ELF-based systems, as 43002well as darwin, cygwin and mingw systems. 43003 43004 Since GIMPLE bytecode is saved alongside final object code, object 43005files generated with LTO support are larger than regular object files. 43006This "fat" object format makes it easy to integrate LTO into existing 43007build systems, as one can, for instance, produce archives of the files. 43008Additionally, one might be able to ship one set of fat objects which 43009could be used both for development and the production of optimized 43010builds. A, perhaps surprising, side effect of this feature is that any 43011mistake in the toolchain leads to LTO information not being used (e.g. 43012an older 'libtool' calling 'ld' directly). This is both an advantage, 43013as the system is more robust, and a disadvantage, as the user is not 43014informed that the optimization has been disabled. 43015 43016 The current implementation only produces "fat" objects, effectively 43017doubling compilation time and increasing file sizes up to 5x the 43018original size. This hides the problem that some tools, such as 'ar' and 43019'nm', need to understand symbol tables of LTO sections. These tools 43020were extended to use the plugin infrastructure, and with these problems 43021solved, GCC will also support "slim" objects consisting of the 43022intermediate code alone. 43023 43024 At the highest level, LTO splits the compiler in two. The first half 43025(the "writer") produces a streaming representation of all the internal 43026data structures needed to optimize and generate code. This includes 43027declarations, types, the callgraph and the GIMPLE representation of 43028function bodies. 43029 43030 When '-flto' is given during compilation of a source file, the pass 43031manager executes all the passes in 'all_lto_gen_passes'. Currently, 43032this phase is composed of two IPA passes: 43033 43034 * 'pass_ipa_lto_gimple_out' This pass executes the function 43035 'lto_output' in 'lto-streamer-out.c', which traverses the call 43036 graph encoding every reachable declaration, type and function. 43037 This generates a memory representation of all the file sections 43038 described below. 43039 43040 * 'pass_ipa_lto_finish_out' This pass executes the function 43041 'produce_asm_for_decls' in 'lto-streamer-out.c', which takes the 43042 memory image built in the previous pass and encodes it in the 43043 corresponding ELF file sections. 43044 43045 The second half of LTO support is the "reader". This is implemented as 43046the GCC front end 'lto1' in 'lto/lto.c'. When 'collect2' detects a link 43047set of '.o'/'.a' files with LTO information and the '-flto' is enabled, 43048it invokes 'lto1' which reads the set of files and aggregates them into 43049a single translation unit for optimization. The main entry point for 43050the reader is 'lto/lto.c':'lto_main'. 43051 4305225.1.1 LTO modes of operation 43053----------------------------- 43054 43055One of the main goals of the GCC link-time infrastructure was to allow 43056effective compilation of large programs. For this reason GCC implements 43057two link-time compilation modes. 43058 43059 1. _LTO mode_, in which the whole program is read into the compiler at 43060 link-time and optimized in a similar way as if it were a single 43061 source-level compilation unit. 43062 43063 2. _WHOPR or partitioned mode_, designed to utilize multiple CPUs 43064 and/or a distributed compilation environment to quickly link large 43065 applications. WHOPR stands for WHOle Program optimizeR (not to be 43066 confused with the semantics of '-fwhole-program'). It partitions 43067 the aggregated callgraph from many different '.o' files and 43068 distributes the compilation of the sub-graphs to different CPUs. 43069 43070 Note that distributed compilation is not implemented yet, but since 43071 the parallelism is facilitated via generating a 'Makefile', it 43072 would be easy to implement. 43073 43074 WHOPR splits LTO into three main stages: 43075 1. Local generation (LGEN) This stage executes in parallel. Every 43076 file in the program is compiled into the intermediate language and 43077 packaged together with the local call-graph and summary 43078 information. This stage is the same for both the LTO and WHOPR 43079 compilation mode. 43080 43081 2. Whole Program Analysis (WPA) WPA is performed sequentially. The 43082 global call-graph is generated, and a global analysis procedure 43083 makes transformation decisions. The global call-graph is 43084 partitioned to facilitate parallel optimization during phase 3. 43085 The results of the WPA stage are stored into new object files which 43086 contain the partitions of program expressed in the intermediate 43087 language and the optimization decisions. 43088 43089 3. Local transformations (LTRANS) This stage executes in parallel. 43090 All the decisions made during phase 2 are implemented locally in 43091 each partitioned object file, and the final object code is 43092 generated. Optimizations which cannot be decided efficiently 43093 during the phase 2 may be performed on the local call-graph 43094 partitions. 43095 43096 WHOPR can be seen as an extension of the usual LTO mode of compilation. 43097In LTO, WPA and LTRANS are executed within a single execution of the 43098compiler, after the whole program has been read into memory. 43099 43100 When compiling in WHOPR mode, the callgraph is partitioned during the 43101WPA stage. The whole program is split into a given number of partitions 43102of roughly the same size. The compiler tries to minimize the number of 43103references which cross partition boundaries. The main advantage of 43104WHOPR is to allow the parallel execution of LTRANS stages, which are the 43105most time-consuming part of the compilation process. Additionally, it 43106avoids the need to load the whole program into memory. 43107 43108 43109File: gccint.info, Node: LTO object file layout, Next: IPA, Prev: LTO Overview, Up: LTO 43110 4311125.2 LTO file sections 43112====================== 43113 43114LTO information is stored in several ELF sections inside object files. 43115Data structures and enum codes for sections are defined in 43116'lto-streamer.h'. 43117 43118 These sections are emitted from 'lto-streamer-out.c' and mapped in all 43119at once from 'lto/lto.c':'lto_file_read'. The individual functions 43120dealing with the reading/writing of each section are described below. 43121 43122 * Command line options ('.gnu.lto_.opts') 43123 43124 This section contains the command line options used to generate the 43125 object files. This is used at link time to determine the 43126 optimization level and other settings when they are not explicitly 43127 specified at the linker command line. 43128 43129 Currently, GCC does not support combining LTO object files compiled 43130 with different set of the command line options into a single 43131 binary. At link time, the options given on the command line and 43132 the options saved on all the files in a link-time set are applied 43133 globally. No attempt is made at validating the combination of 43134 flags (other than the usual validation done by option processing). 43135 This is implemented in 'lto/lto.c':'lto_read_all_file_options'. 43136 43137 * Symbol table ('.gnu.lto_.symtab') 43138 43139 This table replaces the ELF symbol table for functions and 43140 variables represented in the LTO IL. Symbols used and exported by 43141 the optimized assembly code of "fat" objects might not match the 43142 ones used and exported by the intermediate code. This table is 43143 necessary because the intermediate code is less optimized and thus 43144 requires a separate symbol table. 43145 43146 Additionally, the binary code in the "fat" object will lack a call 43147 to a function, since the call was optimized out at compilation time 43148 after the intermediate language was streamed out. In some special 43149 cases, the same optimization may not happen during link-time 43150 optimization. This would lead to an undefined symbol if only one 43151 symbol table was used. 43152 43153 The symbol table is emitted in 43154 'lto-streamer-out.c':'produce_symtab'. 43155 43156 * Global declarations and types ('.gnu.lto_.decls') 43157 43158 This section contains an intermediate language dump of all 43159 declarations and types required to represent the callgraph, static 43160 variables and top-level debug info. 43161 43162 The contents of this section are emitted in 43163 'lto-streamer-out.c':'produce_asm_for_decls'. Types and symbols 43164 are emitted in a topological order that preserves the sharing of 43165 pointers when the file is read back in 43166 ('lto.c':'read_cgraph_and_symbols'). 43167 43168 * The callgraph ('.gnu.lto_.cgraph') 43169 43170 This section contains the basic data structure used by the GCC 43171 inter-procedural optimization infrastructure. This section stores 43172 an annotated multi-graph which represents the functions and call 43173 sites as well as the variables, aliases and top-level 'asm' 43174 statements. 43175 43176 This section is emitted in 'lto-streamer-out.c':'output_cgraph' and 43177 read in 'lto-cgraph.c':'input_cgraph'. 43178 43179 * IPA references ('.gnu.lto_.refs') 43180 43181 This section contains references between function and static 43182 variables. It is emitted by 'lto-cgraph.c':'output_refs' and read 43183 by 'lto-cgraph.c':'input_refs'. 43184 43185 * Function bodies ('.gnu.lto_.function_body.<name>') 43186 43187 This section contains function bodies in the intermediate language 43188 representation. Every function body is in a separate section to 43189 allow copying of the section independently to different object 43190 files or reading the function on demand. 43191 43192 Functions are emitted in 'lto-streamer-out.c':'output_function' and 43193 read in 'lto-streamer-in.c':'input_function'. 43194 43195 * Static variable initializers ('.gnu.lto_.vars') 43196 43197 This section contains all the symbols in the global variable pool. 43198 It is emitted by 'lto-cgraph.c':'output_varpool' and read in 43199 'lto-cgraph.c':'input_cgraph'. 43200 43201 * Summaries and optimization summaries used by IPA passes 43202 ('.gnu.lto_.<xxx>', where '<xxx>' is one of 'jmpfuncs', 'pureconst' 43203 or 'reference') 43204 43205 These sections are used by IPA passes that need to emit summary 43206 information during LTO generation to be read and aggregated at link 43207 time. Each pass is responsible for implementing two pass manager 43208 hooks: one for writing the summary and another for reading it in. 43209 The format of these sections is entirely up to each individual 43210 pass. The only requirement is that the writer and reader hooks 43211 agree on the format. 43212 43213 43214File: gccint.info, Node: IPA, Next: WHOPR, Prev: LTO object file layout, Up: LTO 43215 4321625.3 Using summary information in IPA passes 43217============================================ 43218 43219Programs are represented internally as a _callgraph_ (a multi-graph 43220where nodes are functions and edges are call sites) and a _varpool_ (a 43221list of static and external variables in the program). 43222 43223 The inter-procedural optimization is organized as a sequence of 43224individual passes, which operate on the callgraph and the varpool. To 43225make the implementation of WHOPR possible, every inter-procedural 43226optimization pass is split into several stages that are executed at 43227different times during WHOPR compilation: 43228 43229 * LGEN time 43230 1. _Generate summary_ ('generate_summary' in 'struct 43231 ipa_opt_pass_d'). This stage analyzes every function body and 43232 variable initializer is examined and stores relevant 43233 information into a pass-specific data structure. 43234 43235 2. _Write summary_ ('write_summary' in 'struct ipa_opt_pass_d'). 43236 This stage writes all the pass-specific information generated 43237 by 'generate_summary'. Summaries go into their own 43238 'LTO_section_*' sections that have to be declared in 43239 'lto-streamer.h':'enum lto_section_type'. A new section is 43240 created by calling 'create_output_block' and data can be 43241 written using the 'lto_output_*' routines. 43242 43243 * WPA time 43244 1. _Read summary_ ('read_summary' in 'struct ipa_opt_pass_d'). 43245 This stage reads all the pass-specific information in exactly 43246 the same order that it was written by 'write_summary'. 43247 43248 2. _Execute_ ('execute' in 'struct opt_pass'). This performs 43249 inter-procedural propagation. This must be done without 43250 actual access to the individual function bodies or variable 43251 initializers. Typically, this results in a transitive closure 43252 operation over the summary information of all the nodes in the 43253 callgraph. 43254 43255 3. _Write optimization summary_ ('write_optimization_summary' in 43256 'struct ipa_opt_pass_d'). This writes the result of the 43257 inter-procedural propagation into the object file. This can 43258 use the same data structures and helper routines used in 43259 'write_summary'. 43260 43261 * LTRANS time 43262 1. _Read optimization summary_ ('read_optimization_summary' in 43263 'struct ipa_opt_pass_d'). The counterpart to 43264 'write_optimization_summary'. This reads the interprocedural 43265 optimization decisions in exactly the same format emitted by 43266 'write_optimization_summary'. 43267 43268 2. _Transform_ ('function_transform' and 'variable_transform' in 43269 'struct ipa_opt_pass_d'). The actual function bodies and 43270 variable initializers are updated based on the information 43271 passed down from the _Execute_ stage. 43272 43273 The implementation of the inter-procedural passes are shared between 43274LTO, WHOPR and classic non-LTO compilation. 43275 43276 * During the traditional file-by-file mode every pass executes its 43277 own _Generate summary_, _Execute_, and _Transform_ stages within 43278 the single execution context of the compiler. 43279 43280 * In LTO compilation mode, every pass uses _Generate summary_ and 43281 _Write summary_ stages at compilation time, while the _Read 43282 summary_, _Execute_, and _Transform_ stages are executed at link 43283 time. 43284 43285 * In WHOPR mode all stages are used. 43286 43287 To simplify development, the GCC pass manager differentiates between 43288normal inter-procedural passes and small inter-procedural passes. A 43289_small inter-procedural pass_ ('SIMPLE_IPA_PASS') is a pass that does 43290everything at once and thus it can not be executed during WPA in WHOPR 43291mode. It defines only the _Execute_ stage and during this stage it 43292accesses and modifies the function bodies. Such passes are useful for 43293optimization at LGEN or LTRANS time and are used, for example, to 43294implement early optimization before writing object files. The simple 43295inter-procedural passes can also be used for easier prototyping and 43296development of a new inter-procedural pass. 43297 4329825.3.1 Virtual clones 43299--------------------- 43300 43301One of the main challenges of introducing the WHOPR compilation mode was 43302addressing the interactions between optimization passes. In LTO 43303compilation mode, the passes are executed in a sequence, each of which 43304consists of analysis (or _Generate summary_), propagation (or _Execute_) 43305and _Transform_ stages. Once the work of one pass is finished, the next 43306pass sees the updated program representation and can execute. This 43307makes the individual passes dependent on each other. 43308 43309 In WHOPR mode all passes first execute their _Generate summary_ stage. 43310Then summary writing marks the end of the LGEN stage. At WPA time, the 43311summaries are read back into memory and all passes run the _Execute_ 43312stage. Optimization summaries are streamed and sent to LTRANS, where 43313all the passes execute the _Transform_ stage. 43314 43315 Most optimization passes split naturally into analysis, propagation and 43316transformation stages. But some do not. The main problem arises when 43317one pass performs changes and the following pass gets confused by seeing 43318different callgraphs between the _Transform_ stage and the _Generate 43319summary_ or _Execute_ stage. This means that the passes are required to 43320communicate their decisions with each other. 43321 43322 To facilitate this communication, the GCC callgraph infrastructure 43323implements _virtual clones_, a method of representing the changes 43324performed by the optimization passes in the callgraph without needing to 43325update function bodies. 43326 43327 A _virtual clone_ in the callgraph is a function that has no associated 43328body, just a description of how to create its body based on a different 43329function (which itself may be a virtual clone). 43330 43331 The description of function modifications includes adjustments to the 43332function's signature (which allows, for example, removing or adding 43333function arguments), substitutions to perform on the function body, and, 43334for inlined functions, a pointer to the function that it will be inlined 43335into. 43336 43337 It is also possible to redirect any edge of the callgraph from a 43338function to its virtual clone. This implies updating of the call site 43339to adjust for the new function signature. 43340 43341 Most of the transformations performed by inter-procedural optimizations 43342can be represented via virtual clones. For instance, a constant 43343propagation pass can produce a virtual clone of the function which 43344replaces one of its arguments by a constant. The inliner can represent 43345its decisions by producing a clone of a function whose body will be 43346later integrated into a given function. 43347 43348 Using _virtual clones_, the program can be easily updated during the 43349_Execute_ stage, solving most of pass interactions problems that would 43350otherwise occur during _Transform_. 43351 43352 Virtual clones are later materialized in the LTRANS stage and turned 43353into real functions. Passes executed after the virtual clone were 43354introduced also perform their _Transform_ stage on new functions, so for 43355a pass there is no significant difference between operating on a real 43356function or a virtual clone introduced before its _Execute_ stage. 43357 43358 Optimization passes then work on virtual clones introduced before their 43359_Execute_ stage as if they were real functions. The only difference is 43360that clones are not visible during the _Generate Summary_ stage. 43361 43362 To keep function summaries updated, the callgraph interface allows an 43363optimizer to register a callback that is called every time a new clone 43364is introduced as well as when the actual function or variable is 43365generated or when a function or variable is removed. These hooks are 43366registered in the _Generate summary_ stage and allow the pass to keep 43367its information intact until the _Execute_ stage. The same hooks can 43368also be registered during the _Execute_ stage to keep the optimization 43369summaries updated for the _Transform_ stage. 43370 4337125.3.2 IPA references 43372--------------------- 43373 43374GCC represents IPA references in the callgraph. For a function or 43375variable 'A', the _IPA reference_ is a list of all locations where the 43376address of 'A' is taken and, when 'A' is a variable, a list of all 43377direct stores and reads to/from 'A'. References represent an oriented 43378multi-graph on the union of nodes of the callgraph and the varpool. See 43379'ipa-reference.c':'ipa_reference_write_optimization_summary' and 43380'ipa-reference.c':'ipa_reference_read_optimization_summary' for details. 43381 4338225.3.3 Jump functions 43383--------------------- 43384 43385Suppose that an optimization pass sees a function 'A' and it knows the 43386values of (some of) its arguments. The _jump function_ describes the 43387value of a parameter of a given function call in function 'A' based on 43388this knowledge. 43389 43390 Jump functions are used by several optimizations, such as the 43391inter-procedural constant propagation pass and the devirtualization 43392pass. The inliner also uses jump functions to perform inlining of 43393callbacks. 43394 43395 43396File: gccint.info, Node: WHOPR, Next: Internal flags, Prev: IPA, Up: LTO 43397 4339825.4 Whole program assumptions, linker plugin and symbol visibilities 43399===================================================================== 43400 43401Link-time optimization gives relatively minor benefits when used alone. 43402The problem is that propagation of inter-procedural information does not 43403work well across functions and variables that are called or referenced 43404by other compilation units (such as from a dynamically linked library). 43405We say that such functions and variables are _externally visible_. 43406 43407 To make the situation even more difficult, many applications organize 43408themselves as a set of shared libraries, and the default ELF visibility 43409rules allow one to overwrite any externally visible symbol with a 43410different symbol at runtime. This basically disables any optimizations 43411across such functions and variables, because the compiler cannot be sure 43412that the function body it is seeing is the same function body that will 43413be used at runtime. Any function or variable not declared 'static' in 43414the sources degrades the quality of inter-procedural optimization. 43415 43416 To avoid this problem the compiler must assume that it sees the whole 43417program when doing link-time optimization. Strictly speaking, the whole 43418program is rarely visible even at link-time. Standard system libraries 43419are usually linked dynamically or not provided with the link-time 43420information. In GCC, the whole program option ('-fwhole-program') 43421asserts that every function and variable defined in the current 43422compilation unit is static, except for function 'main' (note: at link 43423time, the current unit is the union of all objects compiled with LTO). 43424Since some functions and variables need to be referenced externally, for 43425example by another DSO or from an assembler file, GCC also provides the 43426function and variable attribute 'externally_visible' which can be used 43427to disable the effect of '-fwhole-program' on a specific symbol. 43428 43429 The whole program mode assumptions are slightly more complex in C++, 43430where inline functions in headers are put into _COMDAT_ sections. 43431COMDAT function and variables can be defined by multiple object files 43432and their bodies are unified at link-time and dynamic link-time. COMDAT 43433functions are changed to local only when their address is not taken and 43434thus un-sharing them with a library is not harmful. COMDAT variables 43435always remain externally visible, however for readonly variables it is 43436assumed that their initializers cannot be overwritten by a different 43437value. 43438 43439 GCC provides the function and variable attribute 'visibility' that can 43440be used to specify the visibility of externally visible symbols (or 43441alternatively an '-fdefault-visibility' command line option). ELF 43442defines the 'default', 'protected', 'hidden' and 'internal' 43443visibilities. 43444 43445 The most commonly used is visibility is 'hidden'. It specifies that 43446the symbol cannot be referenced from outside of the current shared 43447library. Unfortunately, this information cannot be used directly by the 43448link-time optimization in the compiler since the whole shared library 43449also might contain non-LTO objects and those are not visible to the 43450compiler. 43451 43452 GCC solves this problem using linker plugins. A _linker plugin_ is an 43453interface to the linker that allows an external program to claim the 43454ownership of a given object file. The linker then performs the linking 43455procedure by querying the plugin about the symbol table of the claimed 43456objects and once the linking decisions are complete, the plugin is 43457allowed to provide the final object file before the actual linking is 43458made. The linker plugin obtains the symbol resolution information which 43459specifies which symbols provided by the claimed objects are bound from 43460the rest of a binary being linked. 43461 43462 GCC is designed to be independent of the rest of the toolchain and aims 43463to support linkers without plugin support. For this reason it does not 43464use the linker plugin by default. Instead, the object files are 43465examined by 'collect2' before being passed to the linker and objects 43466found to have LTO sections are passed to 'lto1' first. This mode does 43467not work for library archives. The decision on what object files from 43468the archive are needed depends on the actual linking and thus GCC would 43469have to implement the linker itself. The resolution information is 43470missing too and thus GCC needs to make an educated guess based on 43471'-fwhole-program'. Without the linker plugin GCC also assumes that 43472symbols are declared 'hidden' and not referred by non-LTO code by 43473default. 43474 43475 43476File: gccint.info, Node: Internal flags, Prev: WHOPR, Up: LTO 43477 4347825.5 Internal flags controlling 'lto1' 43479====================================== 43480 43481The following flags are passed into 'lto1' and are not meant to be used 43482directly from the command line. 43483 43484 * -fwpa This option runs the serial part of the link-time optimizer 43485 performing the inter-procedural propagation (WPA mode). The 43486 compiler reads in summary information from all inputs and performs 43487 an analysis based on summary information only. It generates object 43488 files for subsequent runs of the link-time optimizer where 43489 individual object files are optimized using both summary 43490 information from the WPA mode and the actual function bodies. It 43491 then drives the LTRANS phase. 43492 43493 * -fltrans This option runs the link-time optimizer in the 43494 local-transformation (LTRANS) mode, which reads in output from a 43495 previous run of the LTO in WPA mode. In the LTRANS mode, LTO 43496 optimizes an object and produces the final assembly. 43497 43498 * -fltrans-output-list=FILE This option specifies a file to which the 43499 names of LTRANS output files are written. This option is only 43500 meaningful in conjunction with '-fwpa'. 43501 43502 * -fresolution=FILE This option specifies the linker resolution file. 43503 This option is only meaningful in conjunction with '-fwpa' and as 43504 option to pass through to the LTO linker plugin. 43505 43506 43507File: gccint.info, Node: Match and Simplify, Next: Funding, Prev: LTO, Up: Top 43508 4350926 Match and Simplify 43510********************* 43511 43512The GIMPLE and GENERIC pattern matching project match-and-simplify tries 43513to address several issues. 43514 43515 1. unify expression simplifications currently spread and duplicated 43516 over separate files like fold-const.c, gimple-fold.c and builtins.c 43517 2. allow for a cheap way to implement building and simplifying 43518 non-trivial GIMPLE expressions, avoiding the need to go through 43519 building and simplifying GENERIC via fold_buildN and then 43520 gimplifying via force_gimple_operand 43521 43522 To address these the project introduces a simple domain specific 43523language to write expression simplifications from which code targeting 43524GIMPLE and GENERIC is auto-generated. The GENERIC variant follows the 43525fold_buildN API while for the GIMPLE variant and to address 2) new APIs 43526are introduced. 43527 43528* Menu: 43529 43530* GIMPLE API:: 43531* The Language:: 43532 43533 43534File: gccint.info, Node: GIMPLE API, Next: The Language, Up: Match and Simplify 43535 4353626.1 GIMPLE API 43537=============== 43538 43539 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 43540 gimple_seq *, tree (*)(tree)) 43541 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 43542 tree, gimple_seq *, tree (*)(tree)) 43543 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 43544 tree, tree, gimple_seq *, tree (*)(tree)) 43545 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 43546 tree, gimple_seq *, tree (*)(tree)) 43547 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 43548 tree, tree, gimple_seq *, tree (*)(tree)) 43549 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 43550 tree, tree, tree, gimple_seq *, tree (*)(tree)) 43551 The main GIMPLE API entry to the expression simplifications 43552 mimicing that of the GENERIC fold_{unary,binary,ternary} functions. 43553 43554 thus providing n-ary overloads for operation or function. The 43555additional arguments are a gimple_seq where built statements are 43556inserted on (if 'NULL' then simplifications requiring new statements are 43557not performed) and a valueization hook that can be used to tie 43558simplifications to a SSA lattice. 43559 43560 In addition to those APIs 'fold_stmt' is overloaded with a valueization 43561hook: 43562 43563 -- bool: fold_stmt (gimple_stmt_iterator *, tree (*)(tree)); 43564 43565 Ontop of these a 'fold_buildN'-like API for GIMPLE is introduced: 43566 43567 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 43568 tree_code, tree, tree, tree (*valueize) (tree) = NULL); 43569 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 43570 tree_code, tree, tree, tree, tree (*valueize) (tree) = NULL); 43571 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 43572 tree_code, tree, tree, tree, tree, tree (*valueize) (tree) = 43573 NULL); 43574 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 43575 built_in_function, tree, tree, tree (*valueize) (tree) = 43576 NULL); 43577 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 43578 built_in_function, tree, tree, tree, tree (*valueize) (tree) = 43579 NULL); 43580 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 43581 built_in_function, tree, tree, tree, tree, tree (*valueize) 43582 (tree) = NULL); 43583 -- GIMPLE function: tree gimple_convert (gimple_seq *, location_t, 43584 tree, tree); 43585 43586 which is supposed to replace 'force_gimple_operand (fold_buildN (...), 43587...)' and calls to 'fold_convert'. Overloads without the 'location_t' 43588argument exist. Built statements are inserted on the provided sequence 43589and simplification is performed using the optional valueization hook. 43590 43591 43592File: gccint.info, Node: The Language, Prev: GIMPLE API, Up: Match and Simplify 43593 4359426.2 The Language 43595================= 43596 43597The language to write expression simplifications in resembles other 43598domain-specific languages GCC uses. Thus it is lispy. Lets start with 43599an example from the match.pd file: 43600 43601 (simplify 43602 (bit_and @0 integer_all_onesp) 43603 @0) 43604 43605 This example contains all required parts of an expression 43606simplification. A simplification is wrapped inside a '(simplify ...)' 43607expression. That contains at least two operands - an expression that is 43608matched with the GIMPLE or GENERIC IL and a replacement expression that 43609is returned if the match was successful. 43610 43611 Expressions have an operator ID, 'bit_and' in this case. Expressions 43612can be lower-case tree codes with '_expr' stripped off or builtin 43613function code names in all-caps, like 'BUILT_IN_SQRT'. 43614 43615 '@n' denotes a so-called capture. It captures the operand and lets you 43616refer to it in other places of the match-and-simplify. In the above 43617example it is refered to in the replacement expression. Captures are 43618'@' followed by a number or an identifier. 43619 43620 (simplify 43621 (bit_xor @0 @0) 43622 { build_zero_cst (type); }) 43623 43624 In this example '@0' is mentioned twice which constrains the matched 43625expression to have two equal operands. Usually matches are constraint 43626to equal types. If operands may be constants and conversions are 43627involved matching by value might be preferred in which case use '@@0' to 43628denote a by value match and the specific operand you want to refer to in 43629the result part. This example also introduces operands written in C 43630code. These can be used in the expression replacements and are supposed 43631to evaluate to a tree node which has to be a valid GIMPLE operand (so 43632you cannot generate expressions in C code). 43633 43634 (simplify 43635 (trunc_mod integer_zerop@0 @1) 43636 (if (!integer_zerop (@1)) 43637 @0)) 43638 43639 Here '@0' captures the first operand of the trunc_mod expression which 43640is also predicated with 'integer_zerop'. Expression operands may be 43641either expressions, predicates or captures. Captures can be 43642unconstrained or capture expresions or predicates. 43643 43644 This example introduces an optional operand of simplify, the 43645if-expression. This condition is evaluated after the expression matched 43646in the IL and is required to evaluate to true to enable the replacement 43647expression in the second operand position. The expression operand of 43648the 'if' is a standard C expression which may contain references to 43649captures. The 'if' has an optional third operand which may contain the 43650replacement expression that is enabled when the condition evaluates to 43651false. 43652 43653 A 'if' expression can be used to specify a common condition for 43654multiple simplify patterns, avoiding the need to repeat that multiple 43655times: 43656 43657 (if (!TYPE_SATURATING (type) 43658 && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) 43659 (simplify 43660 (minus (plus @0 @1) @0) 43661 @1) 43662 (simplify 43663 (minus (minus @0 @1) @0) 43664 (negate @1))) 43665 43666 Note that 'if's in outer position do not have the optional else clause 43667but instead have multiple then clauses. 43668 43669 Ifs can be nested. 43670 43671 There exists a 'switch' expression which can be used to chain 43672conditions avoiding nesting 'if's too much: 43673 43674 (simplify 43675 (simple_comparison @0 REAL_CST@1) 43676 (switch 43677 /* a CMP (-0) -> a CMP 0 */ 43678 (if (REAL_VALUE_MINUS_ZERO (TREE_REAL_CST (@1))) 43679 (cmp @0 { build_real (TREE_TYPE (@1), dconst0); })) 43680 /* x != NaN is always true, other ops are always false. */ 43681 (if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1)) 43682 && ! HONOR_SNANS (@1)) 43683 { constant_boolean_node (cmp == NE_EXPR, type); }))) 43684 43685 Is equal to 43686 43687 (simplify 43688 (simple_comparison @0 REAL_CST@1) 43689 (switch 43690 /* a CMP (-0) -> a CMP 0 */ 43691 (if (REAL_VALUE_MINUS_ZERO (TREE_REAL_CST (@1))) 43692 (cmp @0 { build_real (TREE_TYPE (@1), dconst0); }) 43693 /* x != NaN is always true, other ops are always false. */ 43694 (if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1)) 43695 && ! HONOR_SNANS (@1)) 43696 { constant_boolean_node (cmp == NE_EXPR, type); })))) 43697 43698 which has the second 'if' in the else operand of the first. The 43699'switch' expression takes 'if' expressions as operands (which may not 43700have else clauses) and as a last operand a replacement expression which 43701should be enabled by default if no other condition evaluated to true. 43702 43703 Captures can also be used for capturing results of sub-expressions. 43704 43705 #if GIMPLE 43706 (simplify 43707 (pointer_plus (addr@2 @0) INTEGER_CST_P@1) 43708 (if (is_gimple_min_invariant (@2))) 43709 { 43710 poly_int64 off; 43711 tree base = get_addr_base_and_unit_offset (@0, &off); 43712 off += tree_to_uhwi (@1); 43713 /* Now with that we should be able to simply write 43714 (addr (mem_ref (addr @base) (plus @off @1))) */ 43715 build1 (ADDR_EXPR, type, 43716 build2 (MEM_REF, TREE_TYPE (TREE_TYPE (@2)), 43717 build_fold_addr_expr (base), 43718 build_int_cst (ptr_type_node, off))); 43719 }) 43720 #endif 43721 43722 In the above example, '@2' captures the result of the expression '(addr 43723@0)'. For outermost expression only its type can be captured, and the 43724keyword 'type' is reserved for this purpose. The above example also 43725gives a way to conditionalize patterns to only apply to 'GIMPLE' or 43726'GENERIC' by means of using the pre-defined preprocessor macros 'GIMPLE' 43727and 'GENERIC' and using preprocessor directives. 43728 43729 (simplify 43730 (bit_and:c integral_op_p@0 (bit_ior:c (bit_not @0) @1)) 43731 (bit_and @1 @0)) 43732 43733 Here we introduce flags on match expressions. The flag used above, 43734'c', denotes that the expression should be also matched commutated. 43735Thus the above match expression is really the following four match 43736expressions: 43737 43738 (bit_and integral_op_p@0 (bit_ior (bit_not @0) @1)) 43739 (bit_and (bit_ior (bit_not @0) @1) integral_op_p@0) 43740 (bit_and integral_op_p@0 (bit_ior @1 (bit_not @0))) 43741 (bit_and (bit_ior @1 (bit_not @0)) integral_op_p@0) 43742 43743 Usual canonicalizations you know from GENERIC expressions are applied 43744before matching, so for example constant operands always come second in 43745commutative expressions. 43746 43747 The second supported flag is 's' which tells the code generator to fail 43748the pattern if the expression marked with 's' does have more than one 43749use. For example in 43750 43751 (simplify 43752 (pointer_plus (pointer_plus:s @0 @1) @3) 43753 (pointer_plus @0 (plus @1 @3))) 43754 43755 this avoids the association if '(pointer_plus @0 @1)' is used outside 43756of the matched expression and thus it would stay live and not trivially 43757removed by dead code elimination. 43758 43759 More features exist to avoid too much repetition. 43760 43761 (for op (plus pointer_plus minus bit_ior bit_xor) 43762 (simplify 43763 (op @0 integer_zerop) 43764 @0)) 43765 43766 A 'for' expression can be used to repeat a pattern for each operator 43767specified, substituting 'op'. 'for' can be nested and a 'for' can have 43768multiple operators to iterate. 43769 43770 (for opa (plus minus) 43771 opb (minus plus) 43772 (for opc (plus minus) 43773 (simplify... 43774 43775 In this example the pattern will be repeated four times with 'opa, opb, 43776opc' being 'plus, minus, plus', 'plus, minus, minus', 'minus, plus, 43777plus', 'minus, plus, minus'. 43778 43779 To avoid repeating operator lists in 'for' you can name them via 43780 43781 (define_operator_list pmm plus minus mult) 43782 43783 and use them in 'for' operator lists where they get expanded. 43784 43785 (for opa (pmm trunc_div) 43786 (simplify... 43787 43788 So this example iterates over 'plus', 'minus', 'mult' and 'trunc_div'. 43789 43790 Using operator lists can also remove the need to explicitely write a 43791'for'. All operator list uses that appear in a 'simplify' or 'match' 43792pattern in operator positions will implicitely be added to a new 'for'. 43793For example 43794 43795 (define_operator_list SQRT BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL) 43796 (define_operator_list POW BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL) 43797 (simplify 43798 (SQRT (POW @0 @1)) 43799 (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); }))) 43800 43801 is the same as 43802 43803 (for SQRT (BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL) 43804 POW (BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL) 43805 (simplify 43806 (SQRT (POW @0 @1)) 43807 (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); })))) 43808 43809 'for's and operator lists can include the special identifier 'null' 43810that matches nothing and can never be generated. This can be used to 43811pad an operator list so that it has a standard form, even if there isn't 43812a suitable operator for every form. 43813 43814 Another building block are 'with' expressions in the result expression 43815which nest the generated code in a new C block followed by its argument: 43816 43817 (simplify 43818 (convert (mult @0 @1)) 43819 (with { tree utype = unsigned_type_for (type); } 43820 (convert (mult (convert:utype @0) (convert:utype @1))))) 43821 43822 This allows code nested in the 'with' to refer to the declared 43823variables. In the above case we use the feature to specify the type of 43824a generated expression with the ':type' syntax where 'type' needs to be 43825an identifier that refers to the desired type. Usually the types of the 43826generated result expressions are determined from the context, but 43827sometimes like in the above case it is required that you specify them 43828explicitely. 43829 43830 As intermediate conversions are often optional there is a way to avoid 43831the need to repeat patterns both with and without such conversions. 43832Namely you can mark a conversion as being optional with a '?': 43833 43834 (simplify 43835 (eq (convert@0 @1) (convert? @2)) 43836 (eq @1 (convert @2))) 43837 43838 which will match both '(eq (convert @1) (convert @2))' and '(eq 43839(convert @1) @2)'. The optional converts are supposed to be all either 43840present or not, thus '(eq (convert? @1) (convert? @2))' will result in 43841two patterns only. If you want to match all four combinations you have 43842access to two additional conditional converts as in '(eq (convert1? @1) 43843(convert2? @2))'. 43844 43845 Predicates available from the GCC middle-end need to be made available 43846explicitely via 'define_predicates': 43847 43848 (define_predicates 43849 integer_onep integer_zerop integer_all_onesp) 43850 43851 You can also define predicates using the pattern matching language and 43852the 'match' form: 43853 43854 (match negate_expr_p 43855 INTEGER_CST 43856 (if (TYPE_OVERFLOW_WRAPS (type) 43857 || may_negate_without_overflow_p (t)))) 43858 (match negate_expr_p 43859 (negate @0)) 43860 43861 This shows that for 'match' expressions there is 't' available which 43862captures the outermost expression (something not possible in the 43863'simplify' context). As you can see 'match' has an identifier as first 43864operand which is how you refer to the predicate in patterns. Multiple 43865'match' for the same identifier add additional cases where the predicate 43866matches. 43867 43868 Predicates can also match an expression in which case you need to 43869provide a template specifying the identifier and where to get its 43870operands from: 43871 43872 (match (logical_inverted_value @0) 43873 (eq @0 integer_zerop)) 43874 (match (logical_inverted_value @0) 43875 (bit_not truth_valued_p@0)) 43876 43877 You can use the above predicate like 43878 43879 (simplify 43880 (bit_and @0 (logical_inverted_value @0)) 43881 { build_zero_cst (type); }) 43882 43883 Which will match a bitwise and of an operand with its logical inverted 43884value. 43885 43886 43887File: gccint.info, Node: Funding, Next: GNU Project, Prev: Match and Simplify, Up: Top 43888 43889Funding Free Software 43890********************* 43891 43892If you want to have more free software a few years from now, it makes 43893sense for you to help encourage people to contribute funds for its 43894development. The most effective approach known is to encourage 43895commercial redistributors to donate. 43896 43897 Users of free software systems can boost the pace of development by 43898encouraging for-a-fee distributors to donate part of their selling price 43899to free software developers--the Free Software Foundation, and others. 43900 43901 The way to convince distributors to do this is to demand it and expect 43902it from them. So when you compare distributors, judge them partly by 43903how much they give to free software development. Show distributors they 43904must compete to be the one who gives the most. 43905 43906 To make this approach work, you must insist on numbers that you can 43907compare, such as, "We will donate ten dollars to the Frobnitz project 43908for each disk sold." Don't be satisfied with a vague promise, such as 43909"A portion of the profits are donated," since it doesn't give a basis 43910for comparison. 43911 43912 Even a precise fraction "of the profits from this disk" is not very 43913meaningful, since creative accounting and unrelated business decisions 43914can greatly alter what fraction of the sales price counts as profit. If 43915the price you pay is $50, ten percent of the profit is probably less 43916than a dollar; it might be a few cents, or nothing at all. 43917 43918 Some redistributors do development work themselves. This is useful 43919too; but to keep everyone honest, you need to inquire how much they do, 43920and what kind. Some kinds of development make much more long-term 43921difference than others. For example, maintaining a separate version of 43922a program contributes very little; maintaining the standard version of a 43923program for the whole community contributes much. Easy new ports 43924contribute little, since someone else would surely do them; difficult 43925ports such as adding a new CPU to the GNU Compiler Collection contribute 43926more; major new features or packages contribute the most. 43927 43928 By establishing the idea that supporting further development is "the 43929proper thing to do" when distributing free software for a fee, we can 43930assure a steady flow of resources into making more free software. 43931 43932 Copyright (C) 1994 Free Software Foundation, Inc. 43933 Verbatim copying and redistribution of this section is permitted 43934 without royalty; alteration is not permitted. 43935 43936 43937File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top 43938 43939The GNU Project and GNU/Linux 43940***************************** 43941 43942The GNU Project was launched in 1984 to develop a complete Unix-like 43943operating system which is free software: the GNU system. (GNU is a 43944recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".) 43945Variants of the GNU operating system, which use the kernel Linux, are 43946now widely used; though these systems are often referred to as "Linux", 43947they are more accurately called GNU/Linux systems. 43948 43949 For more information, see: 43950 <http://www.gnu.org/> 43951 <http://www.gnu.org/gnu/linux-and-gnu.html> 43952 43953 43954File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top 43955 43956GNU General Public License 43957************************** 43958 43959 Version 3, 29 June 2007 43960 43961 Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/> 43962 43963 Everyone is permitted to copy and distribute verbatim copies of this 43964 license document, but changing it is not allowed. 43965 43966Preamble 43967======== 43968 43969The GNU General Public License is a free, copyleft license for software 43970and other kinds of works. 43971 43972 The licenses for most software and other practical works are designed 43973to take away your freedom to share and change the works. By contrast, 43974the GNU General Public License is intended to guarantee your freedom to 43975share and change all versions of a program-to make sure it remains free 43976software for all its users. We, the Free Software Foundation, use the 43977GNU General Public License for most of our software; it applies also to 43978any other work released this way by its authors. You can apply it to 43979your programs, too. 43980 43981 When we speak of free software, we are referring to freedom, not price. 43982Our General Public Licenses are designed to make sure that you have the 43983freedom to distribute copies of free software (and charge for them if 43984you wish), that you receive source code or can get it if you want it, 43985that you can change the software or use pieces of it in new free 43986programs, and that you know you can do these things. 43987 43988 To protect your rights, we need to prevent others from denying you 43989these rights or asking you to surrender the rights. Therefore, you have 43990certain responsibilities if you distribute copies of the software, or if 43991you modify it: responsibilities to respect the freedom of others. 43992 43993 For example, if you distribute copies of such a program, whether gratis 43994or for a fee, you must pass on to the recipients the same freedoms that 43995you received. You must make sure that they, too, receive or can get the 43996source code. And you must show them these terms so they know their 43997rights. 43998 43999 Developers that use the GNU GPL protect your rights with two steps: (1) 44000assert copyright on the software, and (2) offer you this License giving 44001you legal permission to copy, distribute and/or modify it. 44002 44003 For the developers' and authors' protection, the GPL clearly explains 44004that there is no warranty for this free software. For both users' and 44005authors' sake, the GPL requires that modified versions be marked as 44006changed, so that their problems will not be attributed erroneously to 44007authors of previous versions. 44008 44009 Some devices are designed to deny users access to install or run 44010modified versions of the software inside them, although the manufacturer 44011can do so. This is fundamentally incompatible with the aim of 44012protecting users' freedom to change the software. The systematic 44013pattern of such abuse occurs in the area of products for individuals to 44014use, which is precisely where it is most unacceptable. Therefore, we 44015have designed this version of the GPL to prohibit the practice for those 44016products. If such problems arise substantially in other domains, we 44017stand ready to extend this provision to those domains in future versions 44018of the GPL, as needed to protect the freedom of users. 44019 44020 Finally, every program is threatened constantly by software patents. 44021States should not allow patents to restrict development and use of 44022software on general-purpose computers, but in those that do, we wish to 44023avoid the special danger that patents applied to a free program could 44024make it effectively proprietary. To prevent this, the GPL assures that 44025patents cannot be used to render the program non-free. 44026 44027 The precise terms and conditions for copying, distribution and 44028modification follow. 44029 44030TERMS AND CONDITIONS 44031==================== 44032 44033 0. Definitions. 44034 44035 "This License" refers to version 3 of the GNU General Public 44036 License. 44037 44038 "Copyright" also means copyright-like laws that apply to other 44039 kinds of works, such as semiconductor masks. 44040 44041 "The Program" refers to any copyrightable work licensed under this 44042 License. Each licensee is addressed as "you". "Licensees" and 44043 "recipients" may be individuals or organizations. 44044 44045 To "modify" a work means to copy from or adapt all or part of the 44046 work in a fashion requiring copyright permission, other than the 44047 making of an exact copy. The resulting work is called a "modified 44048 version" of the earlier work or a work "based on" the earlier work. 44049 44050 A "covered work" means either the unmodified Program or a work 44051 based on the Program. 44052 44053 To "propagate" a work means to do anything with it that, without 44054 permission, would make you directly or secondarily liable for 44055 infringement under applicable copyright law, except executing it on 44056 a computer or modifying a private copy. Propagation includes 44057 copying, distribution (with or without modification), making 44058 available to the public, and in some countries other activities as 44059 well. 44060 44061 To "convey" a work means any kind of propagation that enables other 44062 parties to make or receive copies. Mere interaction with a user 44063 through a computer network, with no transfer of a copy, is not 44064 conveying. 44065 44066 An interactive user interface displays "Appropriate Legal Notices" 44067 to the extent that it includes a convenient and prominently visible 44068 feature that (1) displays an appropriate copyright notice, and (2) 44069 tells the user that there is no warranty for the work (except to 44070 the extent that warranties are provided), that licensees may convey 44071 the work under this License, and how to view a copy of this 44072 License. If the interface presents a list of user commands or 44073 options, such as a menu, a prominent item in the list meets this 44074 criterion. 44075 44076 1. Source Code. 44077 44078 The "source code" for a work means the preferred form of the work 44079 for making modifications to it. "Object code" means any non-source 44080 form of a work. 44081 44082 A "Standard Interface" means an interface that either is an 44083 official standard defined by a recognized standards body, or, in 44084 the case of interfaces specified for a particular programming 44085 language, one that is widely used among developers working in that 44086 language. 44087 44088 The "System Libraries" of an executable work include anything, 44089 other than the work as a whole, that (a) is included in the normal 44090 form of packaging a Major Component, but which is not part of that 44091 Major Component, and (b) serves only to enable use of the work with 44092 that Major Component, or to implement a Standard Interface for 44093 which an implementation is available to the public in source code 44094 form. A "Major Component", in this context, means a major 44095 essential component (kernel, window system, and so on) of the 44096 specific operating system (if any) on which the executable work 44097 runs, or a compiler used to produce the work, or an object code 44098 interpreter used to run it. 44099 44100 The "Corresponding Source" for a work in object code form means all 44101 the source code needed to generate, install, and (for an executable 44102 work) run the object code and to modify the work, including scripts 44103 to control those activities. However, it does not include the 44104 work's System Libraries, or general-purpose tools or generally 44105 available free programs which are used unmodified in performing 44106 those activities but which are not part of the work. For example, 44107 Corresponding Source includes interface definition files associated 44108 with source files for the work, and the source code for shared 44109 libraries and dynamically linked subprograms that the work is 44110 specifically designed to require, such as by intimate data 44111 communication or control flow between those subprograms and other 44112 parts of the work. 44113 44114 The Corresponding Source need not include anything that users can 44115 regenerate automatically from other parts of the Corresponding 44116 Source. 44117 44118 The Corresponding Source for a work in source code form is that 44119 same work. 44120 44121 2. Basic Permissions. 44122 44123 All rights granted under this License are granted for the term of 44124 copyright on the Program, and are irrevocable provided the stated 44125 conditions are met. This License explicitly affirms your unlimited 44126 permission to run the unmodified Program. The output from running 44127 a covered work is covered by this License only if the output, given 44128 its content, constitutes a covered work. This License acknowledges 44129 your rights of fair use or other equivalent, as provided by 44130 copyright law. 44131 44132 You may make, run and propagate covered works that you do not 44133 convey, without conditions so long as your license otherwise 44134 remains in force. You may convey covered works to others for the 44135 sole purpose of having them make modifications exclusively for you, 44136 or provide you with facilities for running those works, provided 44137 that you comply with the terms of this License in conveying all 44138 material for which you do not control copyright. Those thus making 44139 or running the covered works for you must do so exclusively on your 44140 behalf, under your direction and control, on terms that prohibit 44141 them from making any copies of your copyrighted material outside 44142 their relationship with you. 44143 44144 Conveying under any other circumstances is permitted solely under 44145 the conditions stated below. Sublicensing is not allowed; section 44146 10 makes it unnecessary. 44147 44148 3. Protecting Users' Legal Rights From Anti-Circumvention Law. 44149 44150 No covered work shall be deemed part of an effective technological 44151 measure under any applicable law fulfilling obligations under 44152 article 11 of the WIPO copyright treaty adopted on 20 December 44153 1996, or similar laws prohibiting or restricting circumvention of 44154 such measures. 44155 44156 When you convey a covered work, you waive any legal power to forbid 44157 circumvention of technological measures to the extent such 44158 circumvention is effected by exercising rights under this License 44159 with respect to the covered work, and you disclaim any intention to 44160 limit operation or modification of the work as a means of 44161 enforcing, against the work's users, your or third parties' legal 44162 rights to forbid circumvention of technological measures. 44163 44164 4. Conveying Verbatim Copies. 44165 44166 You may convey verbatim copies of the Program's source code as you 44167 receive it, in any medium, provided that you conspicuously and 44168 appropriately publish on each copy an appropriate copyright notice; 44169 keep intact all notices stating that this License and any 44170 non-permissive terms added in accord with section 7 apply to the 44171 code; keep intact all notices of the absence of any warranty; and 44172 give all recipients a copy of this License along with the Program. 44173 44174 You may charge any price or no price for each copy that you convey, 44175 and you may offer support or warranty protection for a fee. 44176 44177 5. Conveying Modified Source Versions. 44178 44179 You may convey a work based on the Program, or the modifications to 44180 produce it from the Program, in the form of source code under the 44181 terms of section 4, provided that you also meet all of these 44182 conditions: 44183 44184 a. The work must carry prominent notices stating that you 44185 modified it, and giving a relevant date. 44186 44187 b. The work must carry prominent notices stating that it is 44188 released under this License and any conditions added under 44189 section 7. This requirement modifies the requirement in 44190 section 4 to "keep intact all notices". 44191 44192 c. You must license the entire work, as a whole, under this 44193 License to anyone who comes into possession of a copy. This 44194 License will therefore apply, along with any applicable 44195 section 7 additional terms, to the whole of the work, and all 44196 its parts, regardless of how they are packaged. This License 44197 gives no permission to license the work in any other way, but 44198 it does not invalidate such permission if you have separately 44199 received it. 44200 44201 d. If the work has interactive user interfaces, each must display 44202 Appropriate Legal Notices; however, if the Program has 44203 interactive interfaces that do not display Appropriate Legal 44204 Notices, your work need not make them do so. 44205 44206 A compilation of a covered work with other separate and independent 44207 works, which are not by their nature extensions of the covered 44208 work, and which are not combined with it such as to form a larger 44209 program, in or on a volume of a storage or distribution medium, is 44210 called an "aggregate" if the compilation and its resulting 44211 copyright are not used to limit the access or legal rights of the 44212 compilation's users beyond what the individual works permit. 44213 Inclusion of a covered work in an aggregate does not cause this 44214 License to apply to the other parts of the aggregate. 44215 44216 6. Conveying Non-Source Forms. 44217 44218 You may convey a covered work in object code form under the terms 44219 of sections 4 and 5, provided that you also convey the 44220 machine-readable Corresponding Source under the terms of this 44221 License, in one of these ways: 44222 44223 a. Convey the object code in, or embodied in, a physical product 44224 (including a physical distribution medium), accompanied by the 44225 Corresponding Source fixed on a durable physical medium 44226 customarily used for software interchange. 44227 44228 b. Convey the object code in, or embodied in, a physical product 44229 (including a physical distribution medium), accompanied by a 44230 written offer, valid for at least three years and valid for as 44231 long as you offer spare parts or customer support for that 44232 product model, to give anyone who possesses the object code 44233 either (1) a copy of the Corresponding Source for all the 44234 software in the product that is covered by this License, on a 44235 durable physical medium customarily used for software 44236 interchange, for a price no more than your reasonable cost of 44237 physically performing this conveying of source, or (2) access 44238 to copy the Corresponding Source from a network server at no 44239 charge. 44240 44241 c. Convey individual copies of the object code with a copy of the 44242 written offer to provide the Corresponding Source. This 44243 alternative is allowed only occasionally and noncommercially, 44244 and only if you received the object code with such an offer, 44245 in accord with subsection 6b. 44246 44247 d. Convey the object code by offering access from a designated 44248 place (gratis or for a charge), and offer equivalent access to 44249 the Corresponding Source in the same way through the same 44250 place at no further charge. You need not require recipients 44251 to copy the Corresponding Source along with the object code. 44252 If the place to copy the object code is a network server, the 44253 Corresponding Source may be on a different server (operated by 44254 you or a third party) that supports equivalent copying 44255 facilities, provided you maintain clear directions next to the 44256 object code saying where to find the Corresponding Source. 44257 Regardless of what server hosts the Corresponding Source, you 44258 remain obligated to ensure that it is available for as long as 44259 needed to satisfy these requirements. 44260 44261 e. Convey the object code using peer-to-peer transmission, 44262 provided you inform other peers where the object code and 44263 Corresponding Source of the work are being offered to the 44264 general public at no charge under subsection 6d. 44265 44266 A separable portion of the object code, whose source code is 44267 excluded from the Corresponding Source as a System Library, need 44268 not be included in conveying the object code work. 44269 44270 A "User Product" is either (1) a "consumer product", which means 44271 any tangible personal property which is normally used for personal, 44272 family, or household purposes, or (2) anything designed or sold for 44273 incorporation into a dwelling. In determining whether a product is 44274 a consumer product, doubtful cases shall be resolved in favor of 44275 coverage. For a particular product received by a particular user, 44276 "normally used" refers to a typical or common use of that class of 44277 product, regardless of the status of the particular user or of the 44278 way in which the particular user actually uses, or expects or is 44279 expected to use, the product. A product is a consumer product 44280 regardless of whether the product has substantial commercial, 44281 industrial or non-consumer uses, unless such uses represent the 44282 only significant mode of use of the product. 44283 44284 "Installation Information" for a User Product means any methods, 44285 procedures, authorization keys, or other information required to 44286 install and execute modified versions of a covered work in that 44287 User Product from a modified version of its Corresponding Source. 44288 The information must suffice to ensure that the continued 44289 functioning of the modified object code is in no case prevented or 44290 interfered with solely because modification has been made. 44291 44292 If you convey an object code work under this section in, or with, 44293 or specifically for use in, a User Product, and the conveying 44294 occurs as part of a transaction in which the right of possession 44295 and use of the User Product is transferred to the recipient in 44296 perpetuity or for a fixed term (regardless of how the transaction 44297 is characterized), the Corresponding Source conveyed under this 44298 section must be accompanied by the Installation Information. But 44299 this requirement does not apply if neither you nor any third party 44300 retains the ability to install modified object code on the User 44301 Product (for example, the work has been installed in ROM). 44302 44303 The requirement to provide Installation Information does not 44304 include a requirement to continue to provide support service, 44305 warranty, or updates for a work that has been modified or installed 44306 by the recipient, or for the User Product in which it has been 44307 modified or installed. Access to a network may be denied when the 44308 modification itself materially and adversely affects the operation 44309 of the network or violates the rules and protocols for 44310 communication across the network. 44311 44312 Corresponding Source conveyed, and Installation Information 44313 provided, in accord with this section must be in a format that is 44314 publicly documented (and with an implementation available to the 44315 public in source code form), and must require no special password 44316 or key for unpacking, reading or copying. 44317 44318 7. Additional Terms. 44319 44320 "Additional permissions" are terms that supplement the terms of 44321 this License by making exceptions from one or more of its 44322 conditions. Additional permissions that are applicable to the 44323 entire Program shall be treated as though they were included in 44324 this License, to the extent that they are valid under applicable 44325 law. If additional permissions apply only to part of the Program, 44326 that part may be used separately under those permissions, but the 44327 entire Program remains governed by this License without regard to 44328 the additional permissions. 44329 44330 When you convey a copy of a covered work, you may at your option 44331 remove any additional permissions from that copy, or from any part 44332 of it. (Additional permissions may be written to require their own 44333 removal in certain cases when you modify the work.) You may place 44334 additional permissions on material, added by you to a covered work, 44335 for which you have or can give appropriate copyright permission. 44336 44337 Notwithstanding any other provision of this License, for material 44338 you add to a covered work, you may (if authorized by the copyright 44339 holders of that material) supplement the terms of this License with 44340 terms: 44341 44342 a. Disclaiming warranty or limiting liability differently from 44343 the terms of sections 15 and 16 of this License; or 44344 44345 b. Requiring preservation of specified reasonable legal notices 44346 or author attributions in that material or in the Appropriate 44347 Legal Notices displayed by works containing it; or 44348 44349 c. Prohibiting misrepresentation of the origin of that material, 44350 or requiring that modified versions of such material be marked 44351 in reasonable ways as different from the original version; or 44352 44353 d. Limiting the use for publicity purposes of names of licensors 44354 or authors of the material; or 44355 44356 e. Declining to grant rights under trademark law for use of some 44357 trade names, trademarks, or service marks; or 44358 44359 f. Requiring indemnification of licensors and authors of that 44360 material by anyone who conveys the material (or modified 44361 versions of it) with contractual assumptions of liability to 44362 the recipient, for any liability that these contractual 44363 assumptions directly impose on those licensors and authors. 44364 44365 All other non-permissive additional terms are considered "further 44366 restrictions" within the meaning of section 10. If the Program as 44367 you received it, or any part of it, contains a notice stating that 44368 it is governed by this License along with a term that is a further 44369 restriction, you may remove that term. If a license document 44370 contains a further restriction but permits relicensing or conveying 44371 under this License, you may add to a covered work material governed 44372 by the terms of that license document, provided that the further 44373 restriction does not survive such relicensing or conveying. 44374 44375 If you add terms to a covered work in accord with this section, you 44376 must place, in the relevant source files, a statement of the 44377 additional terms that apply to those files, or a notice indicating 44378 where to find the applicable terms. 44379 44380 Additional terms, permissive or non-permissive, may be stated in 44381 the form of a separately written license, or stated as exceptions; 44382 the above requirements apply either way. 44383 44384 8. Termination. 44385 44386 You may not propagate or modify a covered work except as expressly 44387 provided under this License. Any attempt otherwise to propagate or 44388 modify it is void, and will automatically terminate your rights 44389 under this License (including any patent licenses granted under the 44390 third paragraph of section 11). 44391 44392 However, if you cease all violation of this License, then your 44393 license from a particular copyright holder is reinstated (a) 44394 provisionally, unless and until the copyright holder explicitly and 44395 finally terminates your license, and (b) permanently, if the 44396 copyright holder fails to notify you of the violation by some 44397 reasonable means prior to 60 days after the cessation. 44398 44399 Moreover, your license from a particular copyright holder is 44400 reinstated permanently if the copyright holder notifies you of the 44401 violation by some reasonable means, this is the first time you have 44402 received notice of violation of this License (for any work) from 44403 that copyright holder, and you cure the violation prior to 30 days 44404 after your receipt of the notice. 44405 44406 Termination of your rights under this section does not terminate 44407 the licenses of parties who have received copies or rights from you 44408 under this License. If your rights have been terminated and not 44409 permanently reinstated, you do not qualify to receive new licenses 44410 for the same material under section 10. 44411 44412 9. Acceptance Not Required for Having Copies. 44413 44414 You are not required to accept this License in order to receive or 44415 run a copy of the Program. Ancillary propagation of a covered work 44416 occurring solely as a consequence of using peer-to-peer 44417 transmission to receive a copy likewise does not require 44418 acceptance. However, nothing other than this License grants you 44419 permission to propagate or modify any covered work. These actions 44420 infringe copyright if you do not accept this License. Therefore, 44421 by modifying or propagating a covered work, you indicate your 44422 acceptance of this License to do so. 44423 44424 10. Automatic Licensing of Downstream Recipients. 44425 44426 Each time you convey a covered work, the recipient automatically 44427 receives a license from the original licensors, to run, modify and 44428 propagate that work, subject to this License. You are not 44429 responsible for enforcing compliance by third parties with this 44430 License. 44431 44432 An "entity transaction" is a transaction transferring control of an 44433 organization, or substantially all assets of one, or subdividing an 44434 organization, or merging organizations. If propagation of a 44435 covered work results from an entity transaction, each party to that 44436 transaction who receives a copy of the work also receives whatever 44437 licenses to the work the party's predecessor in interest had or 44438 could give under the previous paragraph, plus a right to possession 44439 of the Corresponding Source of the work from the predecessor in 44440 interest, if the predecessor has it or can get it with reasonable 44441 efforts. 44442 44443 You may not impose any further restrictions on the exercise of the 44444 rights granted or affirmed under this License. For example, you 44445 may not impose a license fee, royalty, or other charge for exercise 44446 of rights granted under this License, and you may not initiate 44447 litigation (including a cross-claim or counterclaim in a lawsuit) 44448 alleging that any patent claim is infringed by making, using, 44449 selling, offering for sale, or importing the Program or any portion 44450 of it. 44451 44452 11. Patents. 44453 44454 A "contributor" is a copyright holder who authorizes use under this 44455 License of the Program or a work on which the Program is based. 44456 The work thus licensed is called the contributor's "contributor 44457 version". 44458 44459 A contributor's "essential patent claims" are all patent claims 44460 owned or controlled by the contributor, whether already acquired or 44461 hereafter acquired, that would be infringed by some manner, 44462 permitted by this License, of making, using, or selling its 44463 contributor version, but do not include claims that would be 44464 infringed only as a consequence of further modification of the 44465 contributor version. For purposes of this definition, "control" 44466 includes the right to grant patent sublicenses in a manner 44467 consistent with the requirements of this License. 44468 44469 Each contributor grants you a non-exclusive, worldwide, 44470 royalty-free patent license under the contributor's essential 44471 patent claims, to make, use, sell, offer for sale, import and 44472 otherwise run, modify and propagate the contents of its contributor 44473 version. 44474 44475 In the following three paragraphs, a "patent license" is any 44476 express agreement or commitment, however denominated, not to 44477 enforce a patent (such as an express permission to practice a 44478 patent or covenant not to sue for patent infringement). To "grant" 44479 such a patent license to a party means to make such an agreement or 44480 commitment not to enforce a patent against the party. 44481 44482 If you convey a covered work, knowingly relying on a patent 44483 license, and the Corresponding Source of the work is not available 44484 for anyone to copy, free of charge and under the terms of this 44485 License, through a publicly available network server or other 44486 readily accessible means, then you must either (1) cause the 44487 Corresponding Source to be so available, or (2) arrange to deprive 44488 yourself of the benefit of the patent license for this particular 44489 work, or (3) arrange, in a manner consistent with the requirements 44490 of this License, to extend the patent license to downstream 44491 recipients. "Knowingly relying" means you have actual knowledge 44492 that, but for the patent license, your conveying the covered work 44493 in a country, or your recipient's use of the covered work in a 44494 country, would infringe one or more identifiable patents in that 44495 country that you have reason to believe are valid. 44496 44497 If, pursuant to or in connection with a single transaction or 44498 arrangement, you convey, or propagate by procuring conveyance of, a 44499 covered work, and grant a patent license to some of the parties 44500 receiving the covered work authorizing them to use, propagate, 44501 modify or convey a specific copy of the covered work, then the 44502 patent license you grant is automatically extended to all 44503 recipients of the covered work and works based on it. 44504 44505 A patent license is "discriminatory" if it does not include within 44506 the scope of its coverage, prohibits the exercise of, or is 44507 conditioned on the non-exercise of one or more of the rights that 44508 are specifically granted under this License. You may not convey a 44509 covered work if you are a party to an arrangement with a third 44510 party that is in the business of distributing software, under which 44511 you make payment to the third party based on the extent of your 44512 activity of conveying the work, and under which the third party 44513 grants, to any of the parties who would receive the covered work 44514 from you, a discriminatory patent license (a) in connection with 44515 copies of the covered work conveyed by you (or copies made from 44516 those copies), or (b) primarily for and in connection with specific 44517 products or compilations that contain the covered work, unless you 44518 entered into that arrangement, or that patent license was granted, 44519 prior to 28 March 2007. 44520 44521 Nothing in this License shall be construed as excluding or limiting 44522 any implied license or other defenses to infringement that may 44523 otherwise be available to you under applicable patent law. 44524 44525 12. No Surrender of Others' Freedom. 44526 44527 If conditions are imposed on you (whether by court order, agreement 44528 or otherwise) that contradict the conditions of this License, they 44529 do not excuse you from the conditions of this License. If you 44530 cannot convey a covered work so as to satisfy simultaneously your 44531 obligations under this License and any other pertinent obligations, 44532 then as a consequence you may not convey it at all. For example, 44533 if you agree to terms that obligate you to collect a royalty for 44534 further conveying from those to whom you convey the Program, the 44535 only way you could satisfy both those terms and this License would 44536 be to refrain entirely from conveying the Program. 44537 44538 13. Use with the GNU Affero General Public License. 44539 44540 Notwithstanding any other provision of this License, you have 44541 permission to link or combine any covered work with a work licensed 44542 under version 3 of the GNU Affero General Public License into a 44543 single combined work, and to convey the resulting work. The terms 44544 of this License will continue to apply to the part which is the 44545 covered work, but the special requirements of the GNU Affero 44546 General Public License, section 13, concerning interaction through 44547 a network will apply to the combination as such. 44548 44549 14. Revised Versions of this License. 44550 44551 The Free Software Foundation may publish revised and/or new 44552 versions of the GNU General Public License from time to time. Such 44553 new versions will be similar in spirit to the present version, but 44554 may differ in detail to address new problems or concerns. 44555 44556 Each version is given a distinguishing version number. If the 44557 Program specifies that a certain numbered version of the GNU 44558 General Public License "or any later version" applies to it, you 44559 have the option of following the terms and conditions either of 44560 that numbered version or of any later version published by the Free 44561 Software Foundation. If the Program does not specify a version 44562 number of the GNU General Public License, you may choose any 44563 version ever published by the Free Software Foundation. 44564 44565 If the Program specifies that a proxy can decide which future 44566 versions of the GNU General Public License can be used, that 44567 proxy's public statement of acceptance of a version permanently 44568 authorizes you to choose that version for the Program. 44569 44570 Later license versions may give you additional or different 44571 permissions. However, no additional obligations are imposed on any 44572 author or copyright holder as a result of your choosing to follow a 44573 later version. 44574 44575 15. Disclaimer of Warranty. 44576 44577 THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY 44578 APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE 44579 COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" 44580 WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, 44581 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 44582 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE 44583 RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. 44584 SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL 44585 NECESSARY SERVICING, REPAIR OR CORRECTION. 44586 44587 16. Limitation of Liability. 44588 44589 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN 44590 WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES 44591 AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR 44592 DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR 44593 CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE 44594 THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA 44595 BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD 44596 PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER 44597 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF 44598 THE POSSIBILITY OF SUCH DAMAGES. 44599 44600 17. Interpretation of Sections 15 and 16. 44601 44602 If the disclaimer of warranty and limitation of liability provided 44603 above cannot be given local legal effect according to their terms, 44604 reviewing courts shall apply local law that most closely 44605 approximates an absolute waiver of all civil liability in 44606 connection with the Program, unless a warranty or assumption of 44607 liability accompanies a copy of the Program in return for a fee. 44608 44609END OF TERMS AND CONDITIONS 44610=========================== 44611 44612How to Apply These Terms to Your New Programs 44613============================================= 44614 44615If you develop a new program, and you want it to be of the greatest 44616possible use to the public, the best way to achieve this is to make it 44617free software which everyone can redistribute and change under these 44618terms. 44619 44620 To do so, attach the following notices to the program. It is safest to 44621attach them to the start of each source file to most effectively state 44622the exclusion of warranty; and each file should have at least the 44623"copyright" line and a pointer to where the full notice is found. 44624 44625 ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES. 44626 Copyright (C) YEAR NAME OF AUTHOR 44627 44628 This program is free software: you can redistribute it and/or modify 44629 it under the terms of the GNU General Public License as published by 44630 the Free Software Foundation, either version 3 of the License, or (at 44631 your option) any later version. 44632 44633 This program is distributed in the hope that it will be useful, but 44634 WITHOUT ANY WARRANTY; without even the implied warranty of 44635 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU 44636 General Public License for more details. 44637 44638 You should have received a copy of the GNU General Public License 44639 along with this program. If not, see <http://www.gnu.org/licenses/>. 44640 44641 Also add information on how to contact you by electronic and paper 44642mail. 44643 44644 If the program does terminal interaction, make it output a short notice 44645like this when it starts in an interactive mode: 44646 44647 PROGRAM Copyright (C) YEAR NAME OF AUTHOR 44648 This program comes with ABSOLUTELY NO WARRANTY; for details type 'show w'. 44649 This is free software, and you are welcome to redistribute it 44650 under certain conditions; type 'show c' for details. 44651 44652 The hypothetical commands 'show w' and 'show c' should show the 44653appropriate parts of the General Public License. Of course, your 44654program's commands might be different; for a GUI interface, you would 44655use an "about box". 44656 44657 You should also get your employer (if you work as a programmer) or 44658school, if any, to sign a "copyright disclaimer" for the program, if 44659necessary. For more information on this, and how to apply and follow 44660the GNU GPL, see <http://www.gnu.org/licenses/>. 44661 44662 The GNU General Public License does not permit incorporating your 44663program into proprietary programs. If your program is a subroutine 44664library, you may consider it more useful to permit linking proprietary 44665applications with the library. If this is what you want to do, use the 44666GNU Lesser General Public License instead of this License. But first, 44667please read <http://www.gnu.org/philosophy/why-not-lgpl.html>. 44668 44669 44670File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top 44671 44672GNU Free Documentation License 44673****************************** 44674 44675 Version 1.3, 3 November 2008 44676 44677 Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. 44678 <http://fsf.org/> 44679 44680 Everyone is permitted to copy and distribute verbatim copies 44681 of this license document, but changing it is not allowed. 44682 44683 0. PREAMBLE 44684 44685 The purpose of this License is to make a manual, textbook, or other 44686 functional and useful document "free" in the sense of freedom: to 44687 assure everyone the effective freedom to copy and redistribute it, 44688 with or without modifying it, either commercially or 44689 noncommercially. Secondarily, this License preserves for the 44690 author and publisher a way to get credit for their work, while not 44691 being considered responsible for modifications made by others. 44692 44693 This License is a kind of "copyleft", which means that derivative 44694 works of the document must themselves be free in the same sense. 44695 It complements the GNU General Public License, which is a copyleft 44696 license designed for free software. 44697 44698 We have designed this License in order to use it for manuals for 44699 free software, because free software needs free documentation: a 44700 free program should come with manuals providing the same freedoms 44701 that the software does. But this License is not limited to 44702 software manuals; it can be used for any textual work, regardless 44703 of subject matter or whether it is published as a printed book. We 44704 recommend this License principally for works whose purpose is 44705 instruction or reference. 44706 44707 1. APPLICABILITY AND DEFINITIONS 44708 44709 This License applies to any manual or other work, in any medium, 44710 that contains a notice placed by the copyright holder saying it can 44711 be distributed under the terms of this License. Such a notice 44712 grants a world-wide, royalty-free license, unlimited in duration, 44713 to use that work under the conditions stated herein. The 44714 "Document", below, refers to any such manual or work. Any member 44715 of the public is a licensee, and is addressed as "you". You accept 44716 the license if you copy, modify or distribute the work in a way 44717 requiring permission under copyright law. 44718 44719 A "Modified Version" of the Document means any work containing the 44720 Document or a portion of it, either copied verbatim, or with 44721 modifications and/or translated into another language. 44722 44723 A "Secondary Section" is a named appendix or a front-matter section 44724 of the Document that deals exclusively with the relationship of the 44725 publishers or authors of the Document to the Document's overall 44726 subject (or to related matters) and contains nothing that could 44727 fall directly within that overall subject. (Thus, if the Document 44728 is in part a textbook of mathematics, a Secondary Section may not 44729 explain any mathematics.) The relationship could be a matter of 44730 historical connection with the subject or with related matters, or 44731 of legal, commercial, philosophical, ethical or political position 44732 regarding them. 44733 44734 The "Invariant Sections" are certain Secondary Sections whose 44735 titles are designated, as being those of Invariant Sections, in the 44736 notice that says that the Document is released under this License. 44737 If a section does not fit the above definition of Secondary then it 44738 is not allowed to be designated as Invariant. The Document may 44739 contain zero Invariant Sections. If the Document does not identify 44740 any Invariant Sections then there are none. 44741 44742 The "Cover Texts" are certain short passages of text that are 44743 listed, as Front-Cover Texts or Back-Cover Texts, in the notice 44744 that says that the Document is released under this License. A 44745 Front-Cover Text may be at most 5 words, and a Back-Cover Text may 44746 be at most 25 words. 44747 44748 A "Transparent" copy of the Document means a machine-readable copy, 44749 represented in a format whose specification is available to the 44750 general public, that is suitable for revising the document 44751 straightforwardly with generic text editors or (for images composed 44752 of pixels) generic paint programs or (for drawings) some widely 44753 available drawing editor, and that is suitable for input to text 44754 formatters or for automatic translation to a variety of formats 44755 suitable for input to text formatters. A copy made in an otherwise 44756 Transparent file format whose markup, or absence of markup, has 44757 been arranged to thwart or discourage subsequent modification by 44758 readers is not Transparent. An image format is not Transparent if 44759 used for any substantial amount of text. A copy that is not 44760 "Transparent" is called "Opaque". 44761 44762 Examples of suitable formats for Transparent copies include plain 44763 ASCII without markup, Texinfo input format, LaTeX input format, 44764 SGML or XML using a publicly available DTD, and standard-conforming 44765 simple HTML, PostScript or PDF designed for human modification. 44766 Examples of transparent image formats include PNG, XCF and JPG. 44767 Opaque formats include proprietary formats that can be read and 44768 edited only by proprietary word processors, SGML or XML for which 44769 the DTD and/or processing tools are not generally available, and 44770 the machine-generated HTML, PostScript or PDF produced by some word 44771 processors for output purposes only. 44772 44773 The "Title Page" means, for a printed book, the title page itself, 44774 plus such following pages as are needed to hold, legibly, the 44775 material this License requires to appear in the title page. For 44776 works in formats which do not have any title page as such, "Title 44777 Page" means the text near the most prominent appearance of the 44778 work's title, preceding the beginning of the body of the text. 44779 44780 The "publisher" means any person or entity that distributes copies 44781 of the Document to the public. 44782 44783 A section "Entitled XYZ" means a named subunit of the Document 44784 whose title either is precisely XYZ or contains XYZ in parentheses 44785 following text that translates XYZ in another language. (Here XYZ 44786 stands for a specific section name mentioned below, such as 44787 "Acknowledgements", "Dedications", "Endorsements", or "History".) 44788 To "Preserve the Title" of such a section when you modify the 44789 Document means that it remains a section "Entitled XYZ" according 44790 to this definition. 44791 44792 The Document may include Warranty Disclaimers next to the notice 44793 which states that this License applies to the Document. These 44794 Warranty Disclaimers are considered to be included by reference in 44795 this License, but only as regards disclaiming warranties: any other 44796 implication that these Warranty Disclaimers may have is void and 44797 has no effect on the meaning of this License. 44798 44799 2. VERBATIM COPYING 44800 44801 You may copy and distribute the Document in any medium, either 44802 commercially or noncommercially, provided that this License, the 44803 copyright notices, and the license notice saying this License 44804 applies to the Document are reproduced in all copies, and that you 44805 add no other conditions whatsoever to those of this License. You 44806 may not use technical measures to obstruct or control the reading 44807 or further copying of the copies you make or distribute. However, 44808 you may accept compensation in exchange for copies. If you 44809 distribute a large enough number of copies you must also follow the 44810 conditions in section 3. 44811 44812 You may also lend copies, under the same conditions stated above, 44813 and you may publicly display copies. 44814 44815 3. COPYING IN QUANTITY 44816 44817 If you publish printed copies (or copies in media that commonly 44818 have printed covers) of the Document, numbering more than 100, and 44819 the Document's license notice requires Cover Texts, you must 44820 enclose the copies in covers that carry, clearly and legibly, all 44821 these Cover Texts: Front-Cover Texts on the front cover, and 44822 Back-Cover Texts on the back cover. Both covers must also clearly 44823 and legibly identify you as the publisher of these copies. The 44824 front cover must present the full title with all words of the title 44825 equally prominent and visible. You may add other material on the 44826 covers in addition. Copying with changes limited to the covers, as 44827 long as they preserve the title of the Document and satisfy these 44828 conditions, can be treated as verbatim copying in other respects. 44829 44830 If the required texts for either cover are too voluminous to fit 44831 legibly, you should put the first ones listed (as many as fit 44832 reasonably) on the actual cover, and continue the rest onto 44833 adjacent pages. 44834 44835 If you publish or distribute Opaque copies of the Document 44836 numbering more than 100, you must either include a machine-readable 44837 Transparent copy along with each Opaque copy, or state in or with 44838 each Opaque copy a computer-network location from which the general 44839 network-using public has access to download using public-standard 44840 network protocols a complete Transparent copy of the Document, free 44841 of added material. If you use the latter option, you must take 44842 reasonably prudent steps, when you begin distribution of Opaque 44843 copies in quantity, to ensure that this Transparent copy will 44844 remain thus accessible at the stated location until at least one 44845 year after the last time you distribute an Opaque copy (directly or 44846 through your agents or retailers) of that edition to the public. 44847 44848 It is requested, but not required, that you contact the authors of 44849 the Document well before redistributing any large number of copies, 44850 to give them a chance to provide you with an updated version of the 44851 Document. 44852 44853 4. MODIFICATIONS 44854 44855 You may copy and distribute a Modified Version of the Document 44856 under the conditions of sections 2 and 3 above, provided that you 44857 release the Modified Version under precisely this License, with the 44858 Modified Version filling the role of the Document, thus licensing 44859 distribution and modification of the Modified Version to whoever 44860 possesses a copy of it. In addition, you must do these things in 44861 the Modified Version: 44862 44863 A. Use in the Title Page (and on the covers, if any) a title 44864 distinct from that of the Document, and from those of previous 44865 versions (which should, if there were any, be listed in the 44866 History section of the Document). You may use the same title 44867 as a previous version if the original publisher of that 44868 version gives permission. 44869 44870 B. List on the Title Page, as authors, one or more persons or 44871 entities responsible for authorship of the modifications in 44872 the Modified Version, together with at least five of the 44873 principal authors of the Document (all of its principal 44874 authors, if it has fewer than five), unless they release you 44875 from this requirement. 44876 44877 C. State on the Title page the name of the publisher of the 44878 Modified Version, as the publisher. 44879 44880 D. Preserve all the copyright notices of the Document. 44881 44882 E. Add an appropriate copyright notice for your modifications 44883 adjacent to the other copyright notices. 44884 44885 F. Include, immediately after the copyright notices, a license 44886 notice giving the public permission to use the Modified 44887 Version under the terms of this License, in the form shown in 44888 the Addendum below. 44889 44890 G. Preserve in that license notice the full lists of Invariant 44891 Sections and required Cover Texts given in the Document's 44892 license notice. 44893 44894 H. Include an unaltered copy of this License. 44895 44896 I. Preserve the section Entitled "History", Preserve its Title, 44897 and add to it an item stating at least the title, year, new 44898 authors, and publisher of the Modified Version as given on the 44899 Title Page. If there is no section Entitled "History" in the 44900 Document, create one stating the title, year, authors, and 44901 publisher of the Document as given on its Title Page, then add 44902 an item describing the Modified Version as stated in the 44903 previous sentence. 44904 44905 J. Preserve the network location, if any, given in the Document 44906 for public access to a Transparent copy of the Document, and 44907 likewise the network locations given in the Document for 44908 previous versions it was based on. These may be placed in the 44909 "History" section. You may omit a network location for a work 44910 that was published at least four years before the Document 44911 itself, or if the original publisher of the version it refers 44912 to gives permission. 44913 44914 K. For any section Entitled "Acknowledgements" or "Dedications", 44915 Preserve the Title of the section, and preserve in the section 44916 all the substance and tone of each of the contributor 44917 acknowledgements and/or dedications given therein. 44918 44919 L. Preserve all the Invariant Sections of the Document, unaltered 44920 in their text and in their titles. Section numbers or the 44921 equivalent are not considered part of the section titles. 44922 44923 M. Delete any section Entitled "Endorsements". Such a section 44924 may not be included in the Modified Version. 44925 44926 N. Do not retitle any existing section to be Entitled 44927 "Endorsements" or to conflict in title with any Invariant 44928 Section. 44929 44930 O. Preserve any Warranty Disclaimers. 44931 44932 If the Modified Version includes new front-matter sections or 44933 appendices that qualify as Secondary Sections and contain no 44934 material copied from the Document, you may at your option designate 44935 some or all of these sections as invariant. To do this, add their 44936 titles to the list of Invariant Sections in the Modified Version's 44937 license notice. These titles must be distinct from any other 44938 section titles. 44939 44940 You may add a section Entitled "Endorsements", provided it contains 44941 nothing but endorsements of your Modified Version by various 44942 parties--for example, statements of peer review or that the text 44943 has been approved by an organization as the authoritative 44944 definition of a standard. 44945 44946 You may add a passage of up to five words as a Front-Cover Text, 44947 and a passage of up to 25 words as a Back-Cover Text, to the end of 44948 the list of Cover Texts in the Modified Version. Only one passage 44949 of Front-Cover Text and one of Back-Cover Text may be added by (or 44950 through arrangements made by) any one entity. If the Document 44951 already includes a cover text for the same cover, previously added 44952 by you or by arrangement made by the same entity you are acting on 44953 behalf of, you may not add another; but you may replace the old 44954 one, on explicit permission from the previous publisher that added 44955 the old one. 44956 44957 The author(s) and publisher(s) of the Document do not by this 44958 License give permission to use their names for publicity for or to 44959 assert or imply endorsement of any Modified Version. 44960 44961 5. COMBINING DOCUMENTS 44962 44963 You may combine the Document with other documents released under 44964 this License, under the terms defined in section 4 above for 44965 modified versions, provided that you include in the combination all 44966 of the Invariant Sections of all of the original documents, 44967 unmodified, and list them all as Invariant Sections of your 44968 combined work in its license notice, and that you preserve all 44969 their Warranty Disclaimers. 44970 44971 The combined work need only contain one copy of this License, and 44972 multiple identical Invariant Sections may be replaced with a single 44973 copy. If there are multiple Invariant Sections with the same name 44974 but different contents, make the title of each such section unique 44975 by adding at the end of it, in parentheses, the name of the 44976 original author or publisher of that section if known, or else a 44977 unique number. Make the same adjustment to the section titles in 44978 the list of Invariant Sections in the license notice of the 44979 combined work. 44980 44981 In the combination, you must combine any sections Entitled 44982 "History" in the various original documents, forming one section 44983 Entitled "History"; likewise combine any sections Entitled 44984 "Acknowledgements", and any sections Entitled "Dedications". You 44985 must delete all sections Entitled "Endorsements." 44986 44987 6. COLLECTIONS OF DOCUMENTS 44988 44989 You may make a collection consisting of the Document and other 44990 documents released under this License, and replace the individual 44991 copies of this License in the various documents with a single copy 44992 that is included in the collection, provided that you follow the 44993 rules of this License for verbatim copying of each of the documents 44994 in all other respects. 44995 44996 You may extract a single document from such a collection, and 44997 distribute it individually under this License, provided you insert 44998 a copy of this License into the extracted document, and follow this 44999 License in all other respects regarding verbatim copying of that 45000 document. 45001 45002 7. AGGREGATION WITH INDEPENDENT WORKS 45003 45004 A compilation of the Document or its derivatives with other 45005 separate and independent documents or works, in or on a volume of a 45006 storage or distribution medium, is called an "aggregate" if the 45007 copyright resulting from the compilation is not used to limit the 45008 legal rights of the compilation's users beyond what the individual 45009 works permit. When the Document is included in an aggregate, this 45010 License does not apply to the other works in the aggregate which 45011 are not themselves derivative works of the Document. 45012 45013 If the Cover Text requirement of section 3 is applicable to these 45014 copies of the Document, then if the Document is less than one half 45015 of the entire aggregate, the Document's Cover Texts may be placed 45016 on covers that bracket the Document within the aggregate, or the 45017 electronic equivalent of covers if the Document is in electronic 45018 form. Otherwise they must appear on printed covers that bracket 45019 the whole aggregate. 45020 45021 8. TRANSLATION 45022 45023 Translation is considered a kind of modification, so you may 45024 distribute translations of the Document under the terms of section 45025 4. Replacing Invariant Sections with translations requires special 45026 permission from their copyright holders, but you may include 45027 translations of some or all Invariant Sections in addition to the 45028 original versions of these Invariant Sections. You may include a 45029 translation of this License, and all the license notices in the 45030 Document, and any Warranty Disclaimers, provided that you also 45031 include the original English version of this License and the 45032 original versions of those notices and disclaimers. In case of a 45033 disagreement between the translation and the original version of 45034 this License or a notice or disclaimer, the original version will 45035 prevail. 45036 45037 If a section in the Document is Entitled "Acknowledgements", 45038 "Dedications", or "History", the requirement (section 4) to 45039 Preserve its Title (section 1) will typically require changing the 45040 actual title. 45041 45042 9. TERMINATION 45043 45044 You may not copy, modify, sublicense, or distribute the Document 45045 except as expressly provided under this License. Any attempt 45046 otherwise to copy, modify, sublicense, or distribute it is void, 45047 and will automatically terminate your rights under this License. 45048 45049 However, if you cease all violation of this License, then your 45050 license from a particular copyright holder is reinstated (a) 45051 provisionally, unless and until the copyright holder explicitly and 45052 finally terminates your license, and (b) permanently, if the 45053 copyright holder fails to notify you of the violation by some 45054 reasonable means prior to 60 days after the cessation. 45055 45056 Moreover, your license from a particular copyright holder is 45057 reinstated permanently if the copyright holder notifies you of the 45058 violation by some reasonable means, this is the first time you have 45059 received notice of violation of this License (for any work) from 45060 that copyright holder, and you cure the violation prior to 30 days 45061 after your receipt of the notice. 45062 45063 Termination of your rights under this section does not terminate 45064 the licenses of parties who have received copies or rights from you 45065 under this License. If your rights have been terminated and not 45066 permanently reinstated, receipt of a copy of some or all of the 45067 same material does not give you any rights to use it. 45068 45069 10. FUTURE REVISIONS OF THIS LICENSE 45070 45071 The Free Software Foundation may publish new, revised versions of 45072 the GNU Free Documentation License from time to time. Such new 45073 versions will be similar in spirit to the present version, but may 45074 differ in detail to address new problems or concerns. See 45075 <http://www.gnu.org/copyleft/>. 45076 45077 Each version of the License is given a distinguishing version 45078 number. If the Document specifies that a particular numbered 45079 version of this License "or any later version" applies to it, you 45080 have the option of following the terms and conditions either of 45081 that specified version or of any later version that has been 45082 published (not as a draft) by the Free Software Foundation. If the 45083 Document does not specify a version number of this License, you may 45084 choose any version ever published (not as a draft) by the Free 45085 Software Foundation. If the Document specifies that a proxy can 45086 decide which future versions of this License can be used, that 45087 proxy's public statement of acceptance of a version permanently 45088 authorizes you to choose that version for the Document. 45089 45090 11. RELICENSING 45091 45092 "Massive Multiauthor Collaboration Site" (or "MMC Site") means any 45093 World Wide Web server that publishes copyrightable works and also 45094 provides prominent facilities for anybody to edit those works. A 45095 public wiki that anybody can edit is an example of such a server. 45096 A "Massive Multiauthor Collaboration" (or "MMC") contained in the 45097 site means any set of copyrightable works thus published on the MMC 45098 site. 45099 45100 "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 45101 license published by Creative Commons Corporation, a not-for-profit 45102 corporation with a principal place of business in San Francisco, 45103 California, as well as future copyleft versions of that license 45104 published by that same organization. 45105 45106 "Incorporate" means to publish or republish a Document, in whole or 45107 in part, as part of another Document. 45108 45109 An MMC is "eligible for relicensing" if it is licensed under this 45110 License, and if all works that were first published under this 45111 License somewhere other than this MMC, and subsequently 45112 incorporated in whole or in part into the MMC, (1) had no cover 45113 texts or invariant sections, and (2) were thus incorporated prior 45114 to November 1, 2008. 45115 45116 The operator of an MMC Site may republish an MMC contained in the 45117 site under CC-BY-SA on the same site at any time before August 1, 45118 2009, provided the MMC is eligible for relicensing. 45119 45120ADDENDUM: How to use this License for your documents 45121==================================================== 45122 45123To use this License in a document you have written, include a copy of 45124the License in the document and put the following copyright and license 45125notices just after the title page: 45126 45127 Copyright (C) YEAR YOUR NAME. 45128 Permission is granted to copy, distribute and/or modify this document 45129 under the terms of the GNU Free Documentation License, Version 1.3 45130 or any later version published by the Free Software Foundation; 45131 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover 45132 Texts. A copy of the license is included in the section entitled ``GNU 45133 Free Documentation License''. 45134 45135 If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, 45136replace the "with...Texts." line with this: 45137 45138 with the Invariant Sections being LIST THEIR TITLES, with 45139 the Front-Cover Texts being LIST, and with the Back-Cover Texts 45140 being LIST. 45141 45142 If you have Invariant Sections without Cover Texts, or some other 45143combination of the three, merge those two alternatives to suit the 45144situation. 45145 45146 If your document contains nontrivial examples of program code, we 45147recommend releasing these examples in parallel under your choice of free 45148software license, such as the GNU General Public License, to permit 45149their use in free software. 45150 45151 45152File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top 45153 45154Contributors to GCC 45155******************* 45156 45157The GCC project would like to thank its many contributors. Without them 45158the project would not have been nearly as successful as it has been. 45159Any omissions in this list are accidental. Feel free to contact 45160<law@redhat.com> or <gerald@pfeifer.com> if you have been left out or 45161some of your contributions are not listed. Please keep this list in 45162alphabetical order. 45163 45164 * Analog Devices helped implement the support for complex data types 45165 and iterators. 45166 45167 * John David Anglin for threading-related fixes and improvements to 45168 libstdc++-v3, and the HP-UX port. 45169 45170 * James van Artsdalen wrote the code that makes efficient use of the 45171 Intel 80387 register stack. 45172 45173 * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta 45174 Series port. 45175 45176 * Alasdair Baird for various bug fixes. 45177 45178 * Giovanni Bajo for analyzing lots of complicated C++ problem 45179 reports. 45180 45181 * Peter Barada for his work to improve code generation for new 45182 ColdFire cores. 45183 45184 * Gerald Baumgartner added the signature extension to the C++ front 45185 end. 45186 45187 * Godmar Back for his Java improvements and encouragement. 45188 45189 * Scott Bambrough for help porting the Java compiler. 45190 45191 * Wolfgang Bangerth for processing tons of bug reports. 45192 45193 * Jon Beniston for his Microsoft Windows port of Java and port to 45194 Lattice Mico32. 45195 45196 * Daniel Berlin for better DWARF 2 support, faster/better 45197 optimizations, improved alias analysis, plus migrating GCC to 45198 Bugzilla. 45199 45200 * Geoff Berry for his Java object serialization work and various 45201 patches. 45202 45203 * David Binderman tests weekly snapshots of GCC trunk against Fedora 45204 Rawhide for several architectures. 45205 45206 * Laurynas Biveinis for memory management work and DJGPP port fixes. 45207 45208 * Uros Bizjak for the implementation of x87 math built-in functions 45209 and for various middle end and i386 back end improvements and bug 45210 fixes. 45211 45212 * Eric Blake for helping to make GCJ and libgcj conform to the 45213 specifications. 45214 45215 * Janne Blomqvist for contributions to GNU Fortran. 45216 45217 * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and 45218 other Java work. 45219 45220 * Segher Boessenkool for helping maintain the PowerPC port and the 45221 instruction combiner plus various contributions to the middle end. 45222 45223 * Neil Booth for work on cpplib, lang hooks, debug hooks and other 45224 miscellaneous clean-ups. 45225 45226 * Steven Bosscher for integrating the GNU Fortran front end into GCC 45227 and for contributing to the tree-ssa branch. 45228 45229 * Eric Botcazou for fixing middle- and backend bugs left and right. 45230 45231 * Per Bothner for his direction via the steering committee and 45232 various improvements to the infrastructure for supporting new 45233 languages. Chill front end implementation. Initial 45234 implementations of cpplib, fix-header, config.guess, libio, and 45235 past C++ library (libg++) maintainer. Dreaming up, designing and 45236 implementing much of GCJ. 45237 45238 * Devon Bowen helped port GCC to the Tahoe. 45239 45240 * Don Bowman for mips-vxworks contributions. 45241 45242 * James Bowman for the FT32 port. 45243 45244 * Dave Brolley for work on cpplib and Chill. 45245 45246 * Paul Brook for work on the ARM architecture and maintaining GNU 45247 Fortran. 45248 45249 * Robert Brown implemented the support for Encore 32000 systems. 45250 45251 * Christian Bruel for improvements to local store elimination. 45252 45253 * Herman A.J. ten Brugge for various fixes. 45254 45255 * Joerg Brunsmann for Java compiler hacking and help with the GCJ 45256 FAQ. 45257 45258 * Joe Buck for his direction via the steering committee from its 45259 creation to 2013. 45260 45261 * Craig Burley for leadership of the G77 Fortran effort. 45262 45263 * Tobias Burnus for contributions to GNU Fortran. 45264 45265 * Stephan Buys for contributing Doxygen notes for libstdc++. 45266 45267 * Paolo Carlini for libstdc++ work: lots of efficiency improvements 45268 to the C++ strings, streambufs and formatted I/O, hard detective 45269 work on the frustrating localization issues, and keeping up with 45270 the problem reports. 45271 45272 * John Carr for his alias work, SPARC hacking, infrastructure 45273 improvements, previous contributions to the steering committee, 45274 loop optimizations, etc. 45275 45276 * Stephane Carrez for 68HC11 and 68HC12 ports. 45277 45278 * Steve Chamberlain for support for the Renesas SH and H8 processors 45279 and the PicoJava processor, and for GCJ config fixes. 45280 45281 * Glenn Chambers for help with the GCJ FAQ. 45282 45283 * John-Marc Chandonia for various libgcj patches. 45284 45285 * Denis Chertykov for contributing and maintaining the AVR port, the 45286 first GCC port for an 8-bit architecture. 45287 45288 * Kito Cheng for his work on the RISC-V port, including bringing up 45289 the test suite and maintenance. 45290 45291 * Scott Christley for his Objective-C contributions. 45292 45293 * Eric Christopher for his Java porting help and clean-ups. 45294 45295 * Branko Cibej for more warning contributions. 45296 45297 * The GNU Classpath project for all of their merged runtime code. 45298 45299 * Nick Clifton for arm, mcore, fr30, v850, m32r, msp430 rx work, 45300 '--help', and other random hacking. 45301 45302 * Michael Cook for libstdc++ cleanup patches to reduce warnings. 45303 45304 * R. Kelley Cook for making GCC buildable from a read-only directory 45305 as well as other miscellaneous build process and documentation 45306 clean-ups. 45307 45308 * Ralf Corsepius for SH testing and minor bug fixing. 45309 45310 * François-Xavier Coudert for contributions to GNU Fortran. 45311 45312 * Stan Cox for care and feeding of the x86 port and lots of behind 45313 the scenes hacking. 45314 45315 * Alex Crain provided changes for the 3b1. 45316 45317 * Ian Dall for major improvements to the NS32k port. 45318 45319 * Paul Dale for his work to add uClinux platform support to the m68k 45320 backend. 45321 45322 * Palmer Dabbelt for his work maintaining the RISC-V port. 45323 45324 * Dario Dariol contributed the four varieties of sample programs that 45325 print a copy of their source. 45326 45327 * Russell Davidson for fstream and stringstream fixes in libstdc++. 45328 45329 * Bud Davis for work on the G77 and GNU Fortran compilers. 45330 45331 * Mo DeJong for GCJ and libgcj bug fixes. 45332 45333 * Jerry DeLisle for contributions to GNU Fortran. 45334 45335 * DJ Delorie for the DJGPP port, build and libiberty maintenance, 45336 various bug fixes, and the M32C, MeP, MSP430, and RL78 ports. 45337 45338 * Arnaud Desitter for helping to debug GNU Fortran. 45339 45340 * Gabriel Dos Reis for contributions to G++, contributions and 45341 maintenance of GCC diagnostics infrastructure, libstdc++-v3, 45342 including 'valarray<>', 'complex<>', maintaining the numerics 45343 library (including that pesky '<limits>' :-) and keeping up-to-date 45344 anything to do with numbers. 45345 45346 * Ulrich Drepper for his work on glibc, testing of GCC using glibc, 45347 ISO C99 support, CFG dumping support, etc., plus support of the C++ 45348 runtime libraries including for all kinds of C interface issues, 45349 contributing and maintaining 'complex<>', sanity checking and 45350 disbursement, configuration architecture, libio maintenance, and 45351 early math work. 45352 45353 * François Dumont for his work on libstdc++-v3, especially 45354 maintaining and improving 'debug-mode' and associative and 45355 unordered containers. 45356 45357 * Zdenek Dvorak for a new loop unroller and various fixes. 45358 45359 * Michael Eager for his work on the Xilinx MicroBlaze port. 45360 45361 * Richard Earnshaw for his ongoing work with the ARM. 45362 45363 * David Edelsohn for his direction via the steering committee, 45364 ongoing work with the RS6000/PowerPC port, help cleaning up Haifa 45365 loop changes, doing the entire AIX port of libstdc++ with his bare 45366 hands, and for ensuring GCC properly keeps working on AIX. 45367 45368 * Kevin Ediger for the floating point formatting of num_put::do_put 45369 in libstdc++. 45370 45371 * Phil Edwards for libstdc++ work including configuration hackery, 45372 documentation maintainer, chief breaker of the web pages, the 45373 occasional iostream bug fix, and work on shared library symbol 45374 versioning. 45375 45376 * Paul Eggert for random hacking all over GCC. 45377 45378 * Mark Elbrecht for various DJGPP improvements, and for libstdc++ 45379 configuration support for locales and fstream-related fixes. 45380 45381 * Vadim Egorov for libstdc++ fixes in strings, streambufs, and 45382 iostreams. 45383 45384 * Christian Ehrhardt for dealing with bug reports. 45385 45386 * Ben Elliston for his work to move the Objective-C runtime into its 45387 own subdirectory and for his work on autoconf. 45388 45389 * Revital Eres for work on the PowerPC 750CL port. 45390 45391 * Marc Espie for OpenBSD support. 45392 45393 * Doug Evans for much of the global optimization framework, arc, 45394 m32r, and SPARC work. 45395 45396 * Christopher Faylor for his work on the Cygwin port and for caring 45397 and feeding the gcc.gnu.org box and saving its users tons of spam. 45398 45399 * Fred Fish for BeOS support and Ada fixes. 45400 45401 * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ. 45402 45403 * Peter Gerwinski for various bug fixes and the Pascal front end. 45404 45405 * Kaveh R. Ghazi for his direction via the steering committee, 45406 amazing work to make '-W -Wall -W* -Werror' useful, and testing GCC 45407 on a plethora of platforms. Kaveh extends his gratitude to the 45408 CAIP Center at Rutgers University for providing him with computing 45409 resources to work on Free Software from the late 1980s to 2010. 45410 45411 * John Gilmore for a donation to the FSF earmarked improving GNU 45412 Java. 45413 45414 * Judy Goldberg for c++ contributions. 45415 45416 * Torbjorn Granlund for various fixes and the c-torture testsuite, 45417 multiply- and divide-by-constant optimization, improved long long 45418 support, improved leaf function register allocation, and his 45419 direction via the steering committee. 45420 45421 * Jonny Grant for improvements to 'collect2's' '--help' 45422 documentation. 45423 45424 * Anthony Green for his '-Os' contributions, the moxie port, and Java 45425 front end work. 45426 45427 * Stu Grossman for gdb hacking, allowing GCJ developers to debug Java 45428 code. 45429 45430 * Michael K. Gschwind contributed the port to the PDP-11. 45431 45432 * Richard Biener for his ongoing middle-end contributions and bug 45433 fixes and for release management. 45434 45435 * Ron Guilmette implemented the 'protoize' and 'unprotoize' tools, 45436 the support for DWARF 1 symbolic debugging information, and much of 45437 the support for System V Release 4. He has also worked heavily on 45438 the Intel 386 and 860 support. 45439 45440 * Sumanth Gundapaneni for contributing the CR16 port. 45441 45442 * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload 45443 GCSE. 45444 45445 * Bruno Haible for improvements in the runtime overhead for EH, new 45446 warnings and assorted bug fixes. 45447 45448 * Andrew Haley for his amazing Java compiler and library efforts. 45449 45450 * Chris Hanson assisted in making GCC work on HP-UX for the 9000 45451 series 300. 45452 45453 * Michael Hayes for various thankless work he's done trying to get 45454 the c30/c40 ports functional. Lots of loop and unroll improvements 45455 and fixes. 45456 45457 * Dara Hazeghi for wading through myriads of target-specific bug 45458 reports. 45459 45460 * Kate Hedstrom for staking the G77 folks with an initial testsuite. 45461 45462 * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64 45463 work, loop opts, and generally fixing lots of old problems we've 45464 ignored for years, flow rewrite and lots of further stuff, 45465 including reviewing tons of patches. 45466 45467 * Aldy Hernandez for working on the PowerPC port, SIMD support, and 45468 various fixes. 45469 45470 * Nobuyuki Hikichi of Software Research Associates, Tokyo, 45471 contributed the support for the Sony NEWS machine. 45472 45473 * Kazu Hirata for caring and feeding the Renesas H8/300 port and 45474 various fixes. 45475 45476 * Katherine Holcomb for work on GNU Fortran. 45477 45478 * Manfred Hollstein for his ongoing work to keep the m88k alive, lots 45479 of testing and bug fixing, particularly of GCC configury code. 45480 45481 * Steve Holmgren for MachTen patches. 45482 45483 * Mat Hostetter for work on the TILE-Gx and TILEPro ports. 45484 45485 * Jan Hubicka for his x86 port improvements. 45486 45487 * Falk Hueffner for working on C and optimization bug reports. 45488 45489 * Bernardo Innocenti for his m68k work, including merging of ColdFire 45490 improvements and uClinux support. 45491 45492 * Christian Iseli for various bug fixes. 45493 45494 * Kamil Iskra for general m68k hacking. 45495 45496 * Lee Iverson for random fixes and MIPS testing. 45497 45498 * Balaji V. Iyer for Cilk+ development and merging. 45499 45500 * Andreas Jaeger for testing and benchmarking of GCC and various bug 45501 fixes. 45502 45503 * Martin Jambor for his work on inter-procedural optimizations, the 45504 switch conversion pass, and scalar replacement of aggregates. 45505 45506 * Jakub Jelinek for his SPARC work and sibling call optimizations as 45507 well as lots of bug fixes and test cases, and for improving the 45508 Java build system. 45509 45510 * Janis Johnson for ia64 testing and fixes, her quality improvement 45511 sidetracks, and web page maintenance. 45512 45513 * Kean Johnston for SCO OpenServer support and various fixes. 45514 45515 * Tim Josling for the sample language treelang based originally on 45516 Richard Kenner's "toy" language. 45517 45518 * Nicolai Josuttis for additional libstdc++ documentation. 45519 45520 * Klaus Kaempf for his ongoing work to make alpha-vms a viable 45521 target. 45522 45523 * Steven G. Kargl for work on GNU Fortran. 45524 45525 * David Kashtan of SRI adapted GCC to VMS. 45526 45527 * Ryszard Kabatek for many, many libstdc++ bug fixes and 45528 optimizations of strings, especially member functions, and for 45529 auto_ptr fixes. 45530 45531 * Geoffrey Keating for his ongoing work to make the PPC work for 45532 GNU/Linux and his automatic regression tester. 45533 45534 * Brendan Kehoe for his ongoing work with G++ and for a lot of early 45535 work in just about every part of libstdc++. 45536 45537 * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the 45538 MIL-STD-1750A. 45539 45540 * Richard Kenner of the New York University Ultracomputer Research 45541 Laboratory wrote the machine descriptions for the AMD 29000, the 45542 DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the 45543 support for instruction attributes. He also made changes to better 45544 support RISC processors including changes to common subexpression 45545 elimination, strength reduction, function calling sequence 45546 handling, and condition code support, in addition to generalizing 45547 the code for frame pointer elimination and delay slot scheduling. 45548 Richard Kenner was also the head maintainer of GCC for several 45549 years. 45550 45551 * Mumit Khan for various contributions to the Cygwin and Mingw32 45552 ports and maintaining binary releases for Microsoft Windows hosts, 45553 and for massive libstdc++ porting work to Cygwin/Mingw32. 45554 45555 * Robin Kirkham for cpu32 support. 45556 45557 * Mark Klein for PA improvements. 45558 45559 * Thomas Koenig for various bug fixes. 45560 45561 * Bruce Korb for the new and improved fixincludes code. 45562 45563 * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3 45564 effort. 45565 45566 * Maxim Kuvyrkov for contributions to the instruction scheduler, the 45567 Android and m68k/Coldfire ports, and optimizations. 45568 45569 * Charles LaBrec contributed the support for the Integrated Solutions 45570 68020 system. 45571 45572 * Asher Langton and Mike Kumbera for contributing Cray pointer 45573 support to GNU Fortran, and for other GNU Fortran improvements. 45574 45575 * Jeff Law for his direction via the steering committee, coordinating 45576 the entire egcs project and GCC 2.95, rolling out snapshots and 45577 releases, handling merges from GCC2, reviewing tons of patches that 45578 might have fallen through the cracks else, and random but extensive 45579 hacking. 45580 45581 * Walter Lee for work on the TILE-Gx and TILEPro ports. 45582 45583 * Marc Lehmann for his direction via the steering committee and 45584 helping with analysis and improvements of x86 performance. 45585 45586 * Victor Leikehman for work on GNU Fortran. 45587 45588 * Ted Lemon wrote parts of the RTL reader and printer. 45589 45590 * Kriang Lerdsuwanakij for C++ improvements including template as 45591 template parameter support, and many C++ fixes. 45592 45593 * Warren Levy for tremendous work on libgcj (Java Runtime Library) 45594 and random work on the Java front end. 45595 45596 * Alain Lichnewsky ported GCC to the MIPS CPU. 45597 45598 * Oskar Liljeblad for hacking on AWT and his many Java bug reports 45599 and patches. 45600 45601 * Robert Lipe for OpenServer support, new testsuites, testing, etc. 45602 45603 * Chen Liqin for various S+core related fixes/improvement, and for 45604 maintaining the S+core port. 45605 45606 * Martin Liska for his work on identical code folding, the 45607 sanitizers, HSA, general bug fixing and for running automated 45608 regression testing of GCC and reporting numerous bugs. 45609 45610 * Weiwen Liu for testing and various bug fixes. 45611 45612 * Manuel López-Ibáñez for improving '-Wconversion' and many other 45613 diagnostics fixes and improvements. 45614 45615 * Dave Love for his ongoing work with the Fortran front end and 45616 runtime libraries. 45617 45618 * Martin von Löwis for internal consistency checking infrastructure, 45619 various C++ improvements including namespace support, and tons of 45620 assistance with libstdc++/compiler merges. 45621 45622 * H.J. Lu for his previous contributions to the steering committee, 45623 many x86 bug reports, prototype patches, and keeping the GNU/Linux 45624 ports working. 45625 45626 * Greg McGary for random fixes and (someday) bounded pointers. 45627 45628 * Andrew MacLeod for his ongoing work in building a real EH system, 45629 various code generation improvements, work on the global optimizer, 45630 etc. 45631 45632 * Vladimir Makarov for hacking some ugly i960 problems, PowerPC 45633 hacking improvements to compile-time performance, overall knowledge 45634 and direction in the area of instruction scheduling, design and 45635 implementation of the automaton based instruction scheduler and 45636 design and implementation of the integrated and local register 45637 allocators. 45638 45639 * David Malcolm for his work on improving GCC diagnostics, JIT, 45640 self-tests and unit testing. 45641 45642 * Bob Manson for his behind the scenes work on dejagnu. 45643 45644 * John Marino for contributing the DragonFly BSD port. 45645 45646 * Philip Martin for lots of libstdc++ string and vector iterator 45647 fixes and improvements, and string clean up and testsuites. 45648 45649 * Michael Matz for his work on dominance tree discovery, the x86-64 45650 port, link-time optimization framework and general optimization 45651 improvements. 45652 45653 * All of the Mauve project contributors for Java test code. 45654 45655 * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements. 45656 45657 * Adam Megacz for his work on the Microsoft Windows port of GCJ. 45658 45659 * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS, 45660 powerpc, haifa, ECOFF debug support, and other assorted hacking. 45661 45662 * Jason Merrill for his direction via the steering committee and 45663 leading the G++ effort. 45664 45665 * Martin Michlmayr for testing GCC on several architectures using the 45666 entire Debian archive. 45667 45668 * David Miller for his direction via the steering committee, lots of 45669 SPARC work, improvements in jump.c and interfacing with the Linux 45670 kernel developers. 45671 45672 * Gary Miller ported GCC to Charles River Data Systems machines. 45673 45674 * Alfred Minarik for libstdc++ string and ios bug fixes, and turning 45675 the entire libstdc++ testsuite namespace-compatible. 45676 45677 * Mark Mitchell for his direction via the steering committee, 45678 mountains of C++ work, load/store hoisting out of loops, alias 45679 analysis improvements, ISO C 'restrict' support, and serving as 45680 release manager from 2000 to 2011. 45681 45682 * Alan Modra for various GNU/Linux bits and testing. 45683 45684 * Toon Moene for his direction via the steering committee, Fortran 45685 maintenance, and his ongoing work to make us make Fortran run fast. 45686 45687 * Jason Molenda for major help in the care and feeding of all the 45688 services on the gcc.gnu.org (formerly egcs.cygnus.com) 45689 machine--mail, web services, ftp services, etc etc. Doing all this 45690 work on scrap paper and the backs of envelopes would have been... 45691 difficult. 45692 45693 * Catherine Moore for fixing various ugly problems we have sent her 45694 way, including the haifa bug which was killing the Alpha & PowerPC 45695 Linux kernels. 45696 45697 * Mike Moreton for his various Java patches. 45698 45699 * David Mosberger-Tang for various Alpha improvements, and for the 45700 initial IA-64 port. 45701 45702 * Stephen Moshier contributed the floating point emulator that 45703 assists in cross-compilation and permits support for floating point 45704 numbers wider than 64 bits and for ISO C99 support. 45705 45706 * Bill Moyer for his behind the scenes work on various issues. 45707 45708 * Philippe De Muyter for his work on the m68k port. 45709 45710 * Joseph S. Myers for his work on the PDP-11 port, format checking 45711 and ISO C99 support, and continuous emphasis on (and contributions 45712 to) documentation. 45713 45714 * Nathan Myers for his work on libstdc++-v3: architecture and 45715 authorship through the first three snapshots, including 45716 implementation of locale infrastructure, string, shadow C headers, 45717 and the initial project documentation (DESIGN, CHECKLIST, and so 45718 forth). Later, more work on MT-safe string and shadow headers. 45719 45720 * Felix Natter for documentation on porting libstdc++. 45721 45722 * Nathanael Nerode for cleaning up the configuration/build process. 45723 45724 * NeXT, Inc. donated the front end that supports the Objective-C 45725 language. 45726 45727 * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to the 45728 search engine setup, various documentation fixes and other small 45729 fixes. 45730 45731 * Geoff Noer for his work on getting cygwin native builds working. 45732 45733 * Vegard Nossum for running automated regression testing of GCC and 45734 reporting numerous bugs. 45735 45736 * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance 45737 tracking web pages, GIMPLE tuples, and assorted fixes. 45738 45739 * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64, 45740 FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and related 45741 infrastructure improvements. 45742 45743 * Alexandre Oliva for various build infrastructure improvements, 45744 scripts and amazing testing work, including keeping libtool issues 45745 sane and happy. 45746 45747 * Stefan Olsson for work on mt_alloc. 45748 45749 * Melissa O'Neill for various NeXT fixes. 45750 45751 * Rainer Orth for random MIPS work, including improvements to GCC's 45752 o32 ABI support, improvements to dejagnu's MIPS support, Java 45753 configuration clean-ups and porting work, and maintaining the IRIX, 45754 Solaris 2, and Tru64 UNIX ports. 45755 45756 * Steven Pemberton for his contribution of 'enquire' which allowed 45757 GCC to determine various properties of the floating point unit and 45758 generate 'float.h' in older versions of GCC. 45759 45760 * Hartmut Penner for work on the s390 port. 45761 45762 * Paul Petersen wrote the machine description for the Alliant FX/8. 45763 45764 * Alexandre Petit-Bianco for implementing much of the Java compiler 45765 and continued Java maintainership. 45766 45767 * Matthias Pfaller for major improvements to the NS32k port. 45768 45769 * Gerald Pfeifer for his direction via the steering committee, 45770 pointing out lots of problems we need to solve, maintenance of the 45771 web pages, and taking care of documentation maintenance in general. 45772 45773 * Marek Polacek for his work on the C front end, the sanitizers and 45774 general bug fixing. 45775 45776 * Andrew Pinski for processing bug reports by the dozen. 45777 45778 * Ovidiu Predescu for his work on the Objective-C front end and 45779 runtime libraries. 45780 45781 * Jerry Quinn for major performance improvements in C++ formatted 45782 I/O. 45783 45784 * Ken Raeburn for various improvements to checker, MIPS ports and 45785 various cleanups in the compiler. 45786 45787 * Rolf W. Rasmussen for hacking on AWT. 45788 45789 * David Reese of Sun Microsystems contributed to the Solaris on 45790 PowerPC port. 45791 45792 * John Regehr for running automated regression testing of GCC and 45793 reporting numerous bugs. 45794 45795 * Volker Reichelt for running automated regression testing of GCC and 45796 reporting numerous bugs and for keeping up with the problem 45797 reports. 45798 45799 * Joern Rennecke for maintaining the sh port, loop, regmove & reload 45800 hacking and developing and maintaining the Epiphany port. 45801 45802 * Loren J. Rittle for improvements to libstdc++-v3 including the 45803 FreeBSD port, threading fixes, thread-related configury changes, 45804 critical threading documentation, and solutions to really tricky 45805 I/O problems, as well as keeping GCC properly working on FreeBSD 45806 and continuous testing. 45807 45808 * Craig Rodrigues for processing tons of bug reports. 45809 45810 * Ola Rönnerup for work on mt_alloc. 45811 45812 * Gavin Romig-Koch for lots of behind the scenes MIPS work. 45813 45814 * David Ronis inspired and encouraged Craig to rewrite the G77 45815 documentation in texinfo format by contributing a first pass at a 45816 translation of the old 'g77-0.5.16/f/DOC' file. 45817 45818 * Ken Rose for fixes to GCC's delay slot filling code. 45819 45820 * Ira Rosen for her contributions to the auto-vectorizer. 45821 45822 * Paul Rubin wrote most of the preprocessor. 45823 45824 * Pétur Runólfsson for major performance improvements in C++ 45825 formatted I/O and large file support in C++ filebuf. 45826 45827 * Chip Salzenberg for libstdc++ patches and improvements to locales, 45828 traits, Makefiles, libio, libtool hackery, and "long long" support. 45829 45830 * Juha Sarlin for improvements to the H8 code generator. 45831 45832 * Greg Satz assisted in making GCC work on HP-UX for the 9000 series 45833 300. 45834 45835 * Roger Sayle for improvements to constant folding and GCC's RTL 45836 optimizers as well as for fixing numerous bugs. 45837 45838 * Bradley Schatz for his work on the GCJ FAQ. 45839 45840 * Peter Schauer wrote the code to allow debugging to work on the 45841 Alpha. 45842 45843 * William Schelter did most of the work on the Intel 80386 support. 45844 45845 * Tobias Schlüter for work on GNU Fortran. 45846 45847 * Bernd Schmidt for various code generation improvements and major 45848 work in the reload pass, serving as release manager for GCC 2.95.3, 45849 and work on the Blackfin and C6X ports. 45850 45851 * Peter Schmid for constant testing of libstdc++--especially 45852 application testing, going above and beyond what was requested for 45853 the release criteria--and libstdc++ header file tweaks. 45854 45855 * Jason Schroeder for jcf-dump patches. 45856 45857 * Andreas Schwab for his work on the m68k port. 45858 45859 * Lars Segerlund for work on GNU Fortran. 45860 45861 * Dodji Seketeli for numerous C++ bug fixes and debug info 45862 improvements. 45863 45864 * Tim Shen for major work on '<regex>'. 45865 45866 * Joel Sherrill for his direction via the steering committee, RTEMS 45867 contributions and RTEMS testing. 45868 45869 * Nathan Sidwell for many C++ fixes/improvements. 45870 45871 * Jeffrey Siegal for helping RMS with the original design of GCC, 45872 some code which handles the parse tree and RTL data structures, 45873 constant folding and help with the original VAX & m68k ports. 45874 45875 * Kenny Simpson for prompting libstdc++ fixes due to defect reports 45876 from the LWG (thereby keeping GCC in line with updates from the 45877 ISO). 45878 45879 * Franz Sirl for his ongoing work with making the PPC port stable for 45880 GNU/Linux. 45881 45882 * Andrey Slepuhin for assorted AIX hacking. 45883 45884 * Trevor Smigiel for contributing the SPU port. 45885 45886 * Christopher Smith did the port for Convex machines. 45887 45888 * Danny Smith for his major efforts on the Mingw (and Cygwin) ports. 45889 Retired from GCC maintainership August 2010, having mentored two 45890 new maintainers into the role. 45891 45892 * Randy Smith finished the Sun FPA support. 45893 45894 * Ed Smith-Rowland for his continuous work on libstdc++-v3, special 45895 functions, '<random>', and various improvements to C++11 features. 45896 45897 * Scott Snyder for queue, iterator, istream, and string fixes and 45898 libstdc++ testsuite entries. Also for providing the patch to G77 45899 to add rudimentary support for 'INTEGER*1', 'INTEGER*2', and 45900 'LOGICAL*1'. 45901 45902 * Zdenek Sojka for running automated regression testing of GCC and 45903 reporting numerous bugs. 45904 45905 * Arseny Solokha for running automated regression testing of GCC and 45906 reporting numerous bugs. 45907 45908 * Jayant Sonar for contributing the CR16 port. 45909 45910 * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique. 45911 45912 * Richard Stallman, for writing the original GCC and launching the 45913 GNU project. 45914 45915 * Jan Stein of the Chalmers Computer Society provided support for 45916 Genix, as well as part of the 32000 machine description. 45917 45918 * Gerhard Steinmetz for running automated regression testing of GCC 45919 and reporting numerous bugs. 45920 45921 * Nigel Stephens for various mips16 related fixes/improvements. 45922 45923 * Jonathan Stone wrote the machine description for the Pyramid 45924 computer. 45925 45926 * Graham Stott for various infrastructure improvements. 45927 45928 * John Stracke for his Java HTTP protocol fixes. 45929 45930 * Mike Stump for his Elxsi port, G++ contributions over the years and 45931 more recently his vxworks contributions 45932 45933 * Jeff Sturm for Java porting help, bug fixes, and encouragement. 45934 45935 * Zhendong Su for running automated regression testing of GCC and 45936 reporting numerous bugs. 45937 45938 * Chengnian Sun for running automated regression testing of GCC and 45939 reporting numerous bugs. 45940 45941 * Shigeya Suzuki for this fixes for the bsdi platforms. 45942 45943 * Ian Lance Taylor for the Go frontend, the initial mips16 and mips64 45944 support, general configury hacking, fixincludes, etc. 45945 45946 * Holger Teutsch provided the support for the Clipper CPU. 45947 45948 * Gary Thomas for his ongoing work to make the PPC work for 45949 GNU/Linux. 45950 45951 * Paul Thomas for contributions to GNU Fortran. 45952 45953 * Philipp Thomas for random bug fixes throughout the compiler 45954 45955 * Jason Thorpe for thread support in libstdc++ on NetBSD. 45956 45957 * Kresten Krab Thorup wrote the run time support for the Objective-C 45958 language and the fantastic Java bytecode interpreter. 45959 45960 * Michael Tiemann for random bug fixes, the first instruction 45961 scheduler, initial C++ support, function integration, NS32k, SPARC 45962 and M88k machine description work, delay slot scheduling. 45963 45964 * Andreas Tobler for his work porting libgcj to Darwin. 45965 45966 * Teemu Torma for thread safe exception handling support. 45967 45968 * Leonard Tower wrote parts of the parser, RTL generator, and RTL 45969 definitions, and of the VAX machine description. 45970 45971 * Daniel Towner and Hariharan Sandanagobalane contributed and 45972 maintain the picoChip port. 45973 45974 * Tom Tromey for internationalization support and for his many Java 45975 contributions and libgcj maintainership. 45976 45977 * Lassi Tuura for improvements to config.guess to determine HP 45978 processor types. 45979 45980 * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes. 45981 45982 * Andy Vaught for the design and initial implementation of the GNU 45983 Fortran front end. 45984 45985 * Brent Verner for work with the libstdc++ cshadow files and their 45986 associated configure steps. 45987 45988 * Todd Vierling for contributions for NetBSD ports. 45989 45990 * Andrew Waterman for contributing the RISC-V port, as well as 45991 maintaining it. 45992 45993 * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML 45994 guidance and maintaining libstdc++. 45995 45996 * Dean Wakerley for converting the install documentation from HTML to 45997 texinfo in time for GCC 3.0. 45998 45999 * Krister Walfridsson for random bug fixes. 46000 46001 * Feng Wang for contributions to GNU Fortran. 46002 46003 * Stephen M. Webb for time and effort on making libstdc++ shadow 46004 files work with the tricky Solaris 8+ headers, and for pushing the 46005 build-time header tree. Also, for starting and driving the 46006 '<regex>' effort. 46007 46008 * John Wehle for various improvements for the x86 code generator, 46009 related infrastructure improvements to help x86 code generation, 46010 value range propagation and other work, WE32k port. 46011 46012 * Ulrich Weigand for work on the s390 port. 46013 46014 * Janus Weil for contributions to GNU Fortran. 46015 46016 * Zack Weinberg for major work on cpplib and various other bug fixes. 46017 46018 * Matt Welsh for help with Linux Threads support in GCJ. 46019 46020 * Urban Widmark for help fixing java.io. 46021 46022 * Mark Wielaard for new Java library code and his work integrating 46023 with Classpath. 46024 46025 * Dale Wiles helped port GCC to the Tahoe. 46026 46027 * Bob Wilson from Tensilica, Inc. for the Xtensa port. 46028 46029 * Jim Wilson for his direction via the steering committee, tackling 46030 hard problems in various places that nobody else wanted to work on, 46031 strength reduction and other loop optimizations. 46032 46033 * Paul Woegerer and Tal Agmon for the CRX port. 46034 46035 * Carlo Wood for various fixes. 46036 46037 * Tom Wood for work on the m88k port. 46038 46039 * Chung-Ju Wu for his work on the Andes NDS32 port. 46040 46041 * Canqun Yang for work on GNU Fortran. 46042 46043 * Masanobu Yuhara of Fujitsu Laboratories implemented the machine 46044 description for the Tron architecture (specifically, the Gmicro). 46045 46046 * Kevin Zachmann helped port GCC to the Tahoe. 46047 46048 * Ayal Zaks for Swing Modulo Scheduling (SMS). 46049 46050 * Qirun Zhang for running automated regression testing of GCC and 46051 reporting numerous bugs. 46052 46053 * Xiaoqiang Zhang for work on GNU Fortran. 46054 46055 * Gilles Zunino for help porting Java to Irix. 46056 46057 The following people are recognized for their contributions to GNAT, 46058the Ada front end of GCC: 46059 * Bernard Banner 46060 46061 * Romain Berrendonner 46062 46063 * Geert Bosch 46064 46065 * Emmanuel Briot 46066 46067 * Joel Brobecker 46068 46069 * Ben Brosgol 46070 46071 * Vincent Celier 46072 46073 * Arnaud Charlet 46074 46075 * Chien Chieng 46076 46077 * Cyrille Comar 46078 46079 * Cyrille Crozes 46080 46081 * Robert Dewar 46082 46083 * Gary Dismukes 46084 46085 * Robert Duff 46086 46087 * Ed Falis 46088 46089 * Ramon Fernandez 46090 46091 * Sam Figueroa 46092 46093 * Vasiliy Fofanov 46094 46095 * Michael Friess 46096 46097 * Franco Gasperoni 46098 46099 * Ted Giering 46100 46101 * Matthew Gingell 46102 46103 * Laurent Guerby 46104 46105 * Jerome Guitton 46106 46107 * Olivier Hainque 46108 46109 * Jerome Hugues 46110 46111 * Hristian Kirtchev 46112 46113 * Jerome Lambourg 46114 46115 * Bruno Leclerc 46116 46117 * Albert Lee 46118 46119 * Sean McNeil 46120 46121 * Javier Miranda 46122 46123 * Laurent Nana 46124 46125 * Pascal Obry 46126 46127 * Dong-Ik Oh 46128 46129 * Laurent Pautet 46130 46131 * Brett Porter 46132 46133 * Thomas Quinot 46134 46135 * Nicolas Roche 46136 46137 * Pat Rogers 46138 46139 * Jose Ruiz 46140 46141 * Douglas Rupp 46142 46143 * Sergey Rybin 46144 46145 * Gail Schenker 46146 46147 * Ed Schonberg 46148 46149 * Nicolas Setton 46150 46151 * Samuel Tardieu 46152 46153 The following people are recognized for their contributions of new 46154features, bug reports, testing and integration of classpath/libgcj for 46155GCC version 4.1: 46156 * Lillian Angel for 'JTree' implementation and lots Free Swing 46157 additions and bug fixes. 46158 46159 * Wolfgang Baer for 'GapContent' bug fixes. 46160 46161 * Anthony Balkissoon for 'JList', Free Swing 1.5 updates and mouse 46162 event fixes, lots of Free Swing work including 'JTable' editing. 46163 46164 * Stuart Ballard for RMI constant fixes. 46165 46166 * Goffredo Baroncelli for 'HTTPURLConnection' fixes. 46167 46168 * Gary Benson for 'MessageFormat' fixes. 46169 46170 * Daniel Bonniot for 'Serialization' fixes. 46171 46172 * Chris Burdess for lots of gnu.xml and http protocol fixes, 'StAX' 46173 and 'DOM xml:id' support. 46174 46175 * Ka-Hing Cheung for 'TreePath' and 'TreeSelection' fixes. 46176 46177 * Archie Cobbs for build fixes, VM interface updates, 46178 'URLClassLoader' updates. 46179 46180 * Kelley Cook for build fixes. 46181 46182 * Martin Cordova for Suggestions for better 'SocketTimeoutException'. 46183 46184 * David Daney for 'BitSet' bug fixes, 'HttpURLConnection' rewrite and 46185 improvements. 46186 46187 * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo 46188 2D support. Lots of imageio framework additions, lots of AWT and 46189 Free Swing bug fixes. 46190 46191 * Jeroen Frijters for 'ClassLoader' and nio cleanups, serialization 46192 fixes, better 'Proxy' support, bug fixes and IKVM integration. 46193 46194 * Santiago Gala for 'AccessControlContext' fixes. 46195 46196 * Nicolas Geoffray for 'VMClassLoader' and 'AccessController' 46197 improvements. 46198 46199 * David Gilbert for 'basic' and 'metal' icon and plaf support and 46200 lots of documenting, Lots of Free Swing and metal theme additions. 46201 'MetalIconFactory' implementation. 46202 46203 * Anthony Green for 'MIDI' framework, 'ALSA' and 'DSSI' providers. 46204 46205 * Andrew Haley for 'Serialization' and 'URLClassLoader' fixes, gcj 46206 build speedups. 46207 46208 * Kim Ho for 'JFileChooser' implementation. 46209 46210 * Andrew John Hughes for 'Locale' and net fixes, URI RFC2986 updates, 46211 'Serialization' fixes, 'Properties' XML support and generic branch 46212 work, VMIntegration guide update. 46213 46214 * Bastiaan Huisman for 'TimeZone' bug fixing. 46215 46216 * Andreas Jaeger for mprec updates. 46217 46218 * Paul Jenner for better '-Werror' support. 46219 46220 * Ito Kazumitsu for 'NetworkInterface' implementation and updates. 46221 46222 * Roman Kennke for 'BoxLayout', 'GrayFilter' and 'SplitPane', plus 46223 bug fixes all over. Lots of Free Swing work including styled text. 46224 46225 * Simon Kitching for 'String' cleanups and optimization suggestions. 46226 46227 * Michael Koch for configuration fixes, 'Locale' updates, bug and 46228 build fixes. 46229 46230 * Guilhem Lavaux for configuration, thread and channel fixes and 46231 Kaffe integration. JCL native 'Pointer' updates. Logger bug 46232 fixes. 46233 46234 * David Lichteblau for JCL support library global/local reference 46235 cleanups. 46236 46237 * Aaron Luchko for JDWP updates and documentation fixes. 46238 46239 * Ziga Mahkovec for 'Graphics2D' upgraded to Cairo 0.5 and new regex 46240 features. 46241 46242 * Sven de Marothy for BMP imageio support, CSS and 'TextLayout' 46243 fixes. 'GtkImage' rewrite, 2D, awt, free swing and date/time fixes 46244 and implementing the Qt4 peers. 46245 46246 * Casey Marshall for crypto algorithm fixes, 'FileChannel' lock, 46247 'SystemLogger' and 'FileHandler' rotate implementations, NIO 46248 'FileChannel.map' support, security and policy updates. 46249 46250 * Bryce McKinlay for RMI work. 46251 46252 * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus 46253 testing and documenting. 46254 46255 * Kalle Olavi Niemitalo for build fixes. 46256 46257 * Rainer Orth for build fixes. 46258 46259 * Andrew Overholt for 'File' locking fixes. 46260 46261 * Ingo Proetel for 'Image', 'Logger' and 'URLClassLoader' updates. 46262 46263 * Olga Rodimina for 'MenuSelectionManager' implementation. 46264 46265 * Jan Roehrich for 'BasicTreeUI' and 'JTree' fixes. 46266 46267 * Julian Scheid for documentation updates and gjdoc support. 46268 46269 * Christian Schlichtherle for zip fixes and cleanups. 46270 46271 * Robert Schuster for documentation updates and beans fixes, 46272 'TreeNode' enumerations and 'ActionCommand' and various fixes, XML 46273 and URL, AWT and Free Swing bug fixes. 46274 46275 * Keith Seitz for lots of JDWP work. 46276 46277 * Christian Thalinger for 64-bit cleanups, Configuration and VM 46278 interface fixes and 'CACAO' integration, 'fdlibm' updates. 46279 46280 * Gael Thomas for 'VMClassLoader' boot packages support suggestions. 46281 46282 * Andreas Tobler for Darwin and Solaris testing and fixing, 'Qt4' 46283 support for Darwin/OS X, 'Graphics2D' support, 'gtk+' updates. 46284 46285 * Dalibor Topic for better 'DEBUG' support, build cleanups and Kaffe 46286 integration. 'Qt4' build infrastructure, 'SHA1PRNG' and 46287 'GdkPixbugDecoder' updates. 46288 46289 * Tom Tromey for Eclipse integration, generics work, lots of bug 46290 fixes and gcj integration including coordinating The Big Merge. 46291 46292 * Mark Wielaard for bug fixes, packaging and release management, 46293 'Clipboard' implementation, system call interrupts and network 46294 timeouts and 'GdkPixpufDecoder' fixes. 46295 46296 In addition to the above, all of which also contributed time and energy 46297in testing GCC, we would like to thank the following for their 46298contributions to testing: 46299 46300 * Michael Abd-El-Malek 46301 46302 * Thomas Arend 46303 46304 * Bonzo Armstrong 46305 46306 * Steven Ashe 46307 46308 * Chris Baldwin 46309 46310 * David Billinghurst 46311 46312 * Jim Blandy 46313 46314 * Stephane Bortzmeyer 46315 46316 * Horst von Brand 46317 46318 * Frank Braun 46319 46320 * Rodney Brown 46321 46322 * Sidney Cadot 46323 46324 * Bradford Castalia 46325 46326 * Robert Clark 46327 46328 * Jonathan Corbet 46329 46330 * Ralph Doncaster 46331 46332 * Richard Emberson 46333 46334 * Levente Farkas 46335 46336 * Graham Fawcett 46337 46338 * Mark Fernyhough 46339 46340 * Robert A. French 46341 46342 * Jörgen Freyh 46343 46344 * Mark K. Gardner 46345 46346 * Charles-Antoine Gauthier 46347 46348 * Yung Shing Gene 46349 46350 * David Gilbert 46351 46352 * Simon Gornall 46353 46354 * Fred Gray 46355 46356 * John Griffin 46357 46358 * Patrik Hagglund 46359 46360 * Phil Hargett 46361 46362 * Amancio Hasty 46363 46364 * Takafumi Hayashi 46365 46366 * Bryan W. Headley 46367 46368 * Kevin B. Hendricks 46369 46370 * Joep Jansen 46371 46372 * Christian Joensson 46373 46374 * Michel Kern 46375 46376 * David Kidd 46377 46378 * Tobias Kuipers 46379 46380 * Anand Krishnaswamy 46381 46382 * A. O. V. Le Blanc 46383 46384 * llewelly 46385 46386 * Damon Love 46387 46388 * Brad Lucier 46389 46390 * Matthias Klose 46391 46392 * Martin Knoblauch 46393 46394 * Rick Lutowski 46395 46396 * Jesse Macnish 46397 46398 * Stefan Morrell 46399 46400 * Anon A. Mous 46401 46402 * Matthias Mueller 46403 46404 * Pekka Nikander 46405 46406 * Rick Niles 46407 46408 * Jon Olson 46409 46410 * Magnus Persson 46411 46412 * Chris Pollard 46413 46414 * Richard Polton 46415 46416 * Derk Reefman 46417 46418 * David Rees 46419 46420 * Paul Reilly 46421 46422 * Tom Reilly 46423 46424 * Torsten Rueger 46425 46426 * Danny Sadinoff 46427 46428 * Marc Schifer 46429 46430 * Erik Schnetter 46431 46432 * Wayne K. Schroll 46433 46434 * David Schuler 46435 46436 * Vin Shelton 46437 46438 * Tim Souder 46439 46440 * Adam Sulmicki 46441 46442 * Bill Thorson 46443 46444 * George Talbot 46445 46446 * Pedro A. M. Vazquez 46447 46448 * Gregory Warnes 46449 46450 * Ian Watson 46451 46452 * David E. Young 46453 46454 * And many others 46455 46456 And finally we'd like to thank everyone who uses the compiler, provides 46457feedback and generally reminds us why we're doing this work in the first 46458place. 46459 46460 46461File: gccint.info, Node: Option Index, Next: Concept Index, Prev: Contributors, Up: Top 46462 46463Option Index 46464************ 46465 46466GCC's command line options are indexed here without any initial '-' or 46467'--'. Where an option has both positive and negative forms (such as 46468'-fOPTION' and '-fno-OPTION'), relevant entries in the manual are 46469indexed under the most appropriate form; it may sometimes be useful to 46470look up both forms. 46471 46472�[index�] 46473* Menu: 46474 46475* fltrans: Internal flags. (line 18) 46476* fltrans-output-list: Internal flags. (line 23) 46477* fresolution: Internal flags. (line 27) 46478* fwpa: Internal flags. (line 9) 46479* msoft-float: Soft float library routines. 46480 (line 6) 46481 46482 46483File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top 46484 46485Concept Index 46486************* 46487 46488�[index�] 46489* Menu: 46490 46491* ! in constraint: Multi-Alternative. (line 48) 46492* # in constraint: Modifiers. (line 78) 46493* # in template: Output Template. (line 66) 46494* #pragma: Misc. (line 409) 46495* $ in constraint: Multi-Alternative. (line 57) 46496* % in constraint: Modifiers. (line 52) 46497* % in GTY option: GTY Options. (line 18) 46498* % in template: Output Template. (line 6) 46499* & in constraint: Modifiers. (line 25) 46500* (gimple: Logical Operators. (line 169) 46501* (gimple <1>: Logical Operators. (line 173) 46502* (gimple <2>: Logical Operators. (line 177) 46503* (gimple_stmt_iterator: GIMPLE API. (line 30) 46504* (nil): RTL Objects. (line 73) 46505* * in constraint: Modifiers. (line 83) 46506* * in template: Output Statement. (line 29) 46507* *gimple_build_asm_vec: GIMPLE_ASM. (line 6) 46508* *gimple_build_assign: GIMPLE_ASSIGN. (line 6) 46509* *gimple_build_assign <1>: GIMPLE_ASSIGN. (line 18) 46510* *gimple_build_assign <2>: GIMPLE_ASSIGN. (line 29) 46511* *gimple_build_assign <3>: GIMPLE_ASSIGN. (line 35) 46512* *gimple_build_bind: GIMPLE_BIND. (line 6) 46513* *gimple_build_call: GIMPLE_CALL. (line 6) 46514* *gimple_build_call_from_tree: GIMPLE_CALL. (line 15) 46515* *gimple_build_call_vec: GIMPLE_CALL. (line 25) 46516* *gimple_build_catch: GIMPLE_CATCH. (line 6) 46517* *gimple_build_cond: GIMPLE_COND. (line 6) 46518* *gimple_build_cond_from_tree: GIMPLE_COND. (line 14) 46519* *gimple_build_debug_bind: GIMPLE_DEBUG. (line 6) 46520* *gimple_build_eh_filter: GIMPLE_EH_FILTER. (line 6) 46521* *gimple_build_goto: GIMPLE_GOTO. (line 6) 46522* *gimple_build_label: GIMPLE_LABEL. (line 6) 46523* *gimple_build_omp_atomic_load: GIMPLE_OMP_ATOMIC_LOAD. 46524 (line 6) 46525* *gimple_build_omp_atomic_store: GIMPLE_OMP_ATOMIC_STORE. 46526 (line 6) 46527* *gimple_build_omp_continue: GIMPLE_OMP_CONTINUE. 46528 (line 6) 46529* *gimple_build_omp_critical: GIMPLE_OMP_CRITICAL. 46530 (line 6) 46531* *gimple_build_omp_for: GIMPLE_OMP_FOR. (line 6) 46532* *gimple_build_omp_parallel: GIMPLE_OMP_PARALLEL. 46533 (line 6) 46534* *gimple_build_omp_sections: GIMPLE_OMP_SECTIONS. 46535 (line 6) 46536* *gimple_build_omp_single: GIMPLE_OMP_SINGLE. (line 6) 46537* *gimple_build_resx: GIMPLE_RESX. (line 6) 46538* *gimple_build_return: GIMPLE_RETURN. (line 6) 46539* *gimple_build_switch: GIMPLE_SWITCH. (line 6) 46540* *gimple_build_try: GIMPLE_TRY. (line 6) 46541* + in constraint: Modifiers. (line 12) 46542* -fsection-anchors: Special Accessors. (line 117) 46543* -fsection-anchors <1>: Anchored Addresses. (line 6) 46544* /c in RTL dump: Flags. (line 230) 46545* /f in RTL dump: Flags. (line 238) 46546* /i in RTL dump: Flags. (line 283) 46547* /j in RTL dump: Flags. (line 295) 46548* /s in RTL dump: Flags. (line 254) 46549* /u in RTL dump: Flags. (line 307) 46550* /v in RTL dump: Flags. (line 339) 46551* 0 in constraint: Simple Constraints. (line 128) 46552* < in constraint: Simple Constraints. (line 47) 46553* = in constraint: Modifiers. (line 8) 46554* > in constraint: Simple Constraints. (line 59) 46555* ? in constraint: Multi-Alternative. (line 42) 46556* \: Output Template. (line 46) 46557* ^ in constraint: Multi-Alternative. (line 53) 46558* __absvdi2: Integer library routines. 46559 (line 106) 46560* __absvsi2: Integer library routines. 46561 (line 105) 46562* __addda3: Fixed-point fractional library routines. 46563 (line 52) 46564* __adddf3: Soft float library routines. 46565 (line 22) 46566* __adddq3: Fixed-point fractional library routines. 46567 (line 39) 46568* __addha3: Fixed-point fractional library routines. 46569 (line 49) 46570* __addhq3: Fixed-point fractional library routines. 46571 (line 37) 46572* __addqq3: Fixed-point fractional library routines. 46573 (line 35) 46574* __addsa3: Fixed-point fractional library routines. 46575 (line 51) 46576* __addsf3: Soft float library routines. 46577 (line 21) 46578* __addsq3: Fixed-point fractional library routines. 46579 (line 38) 46580* __addta3: Fixed-point fractional library routines. 46581 (line 53) 46582* __addtf3: Soft float library routines. 46583 (line 23) 46584* __adduda3: Fixed-point fractional library routines. 46585 (line 59) 46586* __addudq3: Fixed-point fractional library routines. 46587 (line 47) 46588* __adduha3: Fixed-point fractional library routines. 46589 (line 55) 46590* __adduhq3: Fixed-point fractional library routines. 46591 (line 43) 46592* __adduqq3: Fixed-point fractional library routines. 46593 (line 41) 46594* __addusa3: Fixed-point fractional library routines. 46595 (line 57) 46596* __addusq3: Fixed-point fractional library routines. 46597 (line 45) 46598* __adduta3: Fixed-point fractional library routines. 46599 (line 61) 46600* __addvdi3: Integer library routines. 46601 (line 110) 46602* __addvsi3: Integer library routines. 46603 (line 109) 46604* __addxf3: Soft float library routines. 46605 (line 25) 46606* __ashlda3: Fixed-point fractional library routines. 46607 (line 358) 46608* __ashldi3: Integer library routines. 46609 (line 13) 46610* __ashldq3: Fixed-point fractional library routines. 46611 (line 346) 46612* __ashlha3: Fixed-point fractional library routines. 46613 (line 356) 46614* __ashlhq3: Fixed-point fractional library routines. 46615 (line 344) 46616* __ashlqq3: Fixed-point fractional library routines. 46617 (line 343) 46618* __ashlsa3: Fixed-point fractional library routines. 46619 (line 357) 46620* __ashlsi3: Integer library routines. 46621 (line 12) 46622* __ashlsq3: Fixed-point fractional library routines. 46623 (line 345) 46624* __ashlta3: Fixed-point fractional library routines. 46625 (line 359) 46626* __ashlti3: Integer library routines. 46627 (line 14) 46628* __ashluda3: Fixed-point fractional library routines. 46629 (line 365) 46630* __ashludq3: Fixed-point fractional library routines. 46631 (line 354) 46632* __ashluha3: Fixed-point fractional library routines. 46633 (line 361) 46634* __ashluhq3: Fixed-point fractional library routines. 46635 (line 350) 46636* __ashluqq3: Fixed-point fractional library routines. 46637 (line 348) 46638* __ashlusa3: Fixed-point fractional library routines. 46639 (line 363) 46640* __ashlusq3: Fixed-point fractional library routines. 46641 (line 352) 46642* __ashluta3: Fixed-point fractional library routines. 46643 (line 367) 46644* __ashrda3: Fixed-point fractional library routines. 46645 (line 378) 46646* __ashrdi3: Integer library routines. 46647 (line 18) 46648* __ashrdq3: Fixed-point fractional library routines. 46649 (line 374) 46650* __ashrha3: Fixed-point fractional library routines. 46651 (line 376) 46652* __ashrhq3: Fixed-point fractional library routines. 46653 (line 372) 46654* __ashrqq3: Fixed-point fractional library routines. 46655 (line 371) 46656* __ashrsa3: Fixed-point fractional library routines. 46657 (line 377) 46658* __ashrsi3: Integer library routines. 46659 (line 17) 46660* __ashrsq3: Fixed-point fractional library routines. 46661 (line 373) 46662* __ashrta3: Fixed-point fractional library routines. 46663 (line 379) 46664* __ashrti3: Integer library routines. 46665 (line 19) 46666* __bid_adddd3: Decimal float library routines. 46667 (line 23) 46668* __bid_addsd3: Decimal float library routines. 46669 (line 19) 46670* __bid_addtd3: Decimal float library routines. 46671 (line 27) 46672* __bid_divdd3: Decimal float library routines. 46673 (line 66) 46674* __bid_divsd3: Decimal float library routines. 46675 (line 62) 46676* __bid_divtd3: Decimal float library routines. 46677 (line 70) 46678* __bid_eqdd2: Decimal float library routines. 46679 (line 258) 46680* __bid_eqsd2: Decimal float library routines. 46681 (line 256) 46682* __bid_eqtd2: Decimal float library routines. 46683 (line 260) 46684* __bid_extendddtd2: Decimal float library routines. 46685 (line 91) 46686* __bid_extendddtf: Decimal float library routines. 46687 (line 139) 46688* __bid_extendddxf: Decimal float library routines. 46689 (line 133) 46690* __bid_extenddfdd: Decimal float library routines. 46691 (line 146) 46692* __bid_extenddftd: Decimal float library routines. 46693 (line 106) 46694* __bid_extendsddd2: Decimal float library routines. 46695 (line 87) 46696* __bid_extendsddf: Decimal float library routines. 46697 (line 127) 46698* __bid_extendsdtd2: Decimal float library routines. 46699 (line 89) 46700* __bid_extendsdtf: Decimal float library routines. 46701 (line 137) 46702* __bid_extendsdxf: Decimal float library routines. 46703 (line 131) 46704* __bid_extendsfdd: Decimal float library routines. 46705 (line 102) 46706* __bid_extendsfsd: Decimal float library routines. 46707 (line 144) 46708* __bid_extendsftd: Decimal float library routines. 46709 (line 104) 46710* __bid_extendtftd: Decimal float library routines. 46711 (line 148) 46712* __bid_extendxftd: Decimal float library routines. 46713 (line 108) 46714* __bid_fixdddi: Decimal float library routines. 46715 (line 169) 46716* __bid_fixddsi: Decimal float library routines. 46717 (line 161) 46718* __bid_fixsddi: Decimal float library routines. 46719 (line 167) 46720* __bid_fixsdsi: Decimal float library routines. 46721 (line 159) 46722* __bid_fixtddi: Decimal float library routines. 46723 (line 171) 46724* __bid_fixtdsi: Decimal float library routines. 46725 (line 163) 46726* __bid_fixunsdddi: Decimal float library routines. 46727 (line 186) 46728* __bid_fixunsddsi: Decimal float library routines. 46729 (line 177) 46730* __bid_fixunssddi: Decimal float library routines. 46731 (line 184) 46732* __bid_fixunssdsi: Decimal float library routines. 46733 (line 175) 46734* __bid_fixunstddi: Decimal float library routines. 46735 (line 188) 46736* __bid_fixunstdsi: Decimal float library routines. 46737 (line 179) 46738* __bid_floatdidd: Decimal float library routines. 46739 (line 204) 46740* __bid_floatdisd: Decimal float library routines. 46741 (line 202) 46742* __bid_floatditd: Decimal float library routines. 46743 (line 206) 46744* __bid_floatsidd: Decimal float library routines. 46745 (line 195) 46746* __bid_floatsisd: Decimal float library routines. 46747 (line 193) 46748* __bid_floatsitd: Decimal float library routines. 46749 (line 197) 46750* __bid_floatunsdidd: Decimal float library routines. 46751 (line 222) 46752* __bid_floatunsdisd: Decimal float library routines. 46753 (line 220) 46754* __bid_floatunsditd: Decimal float library routines. 46755 (line 224) 46756* __bid_floatunssidd: Decimal float library routines. 46757 (line 213) 46758* __bid_floatunssisd: Decimal float library routines. 46759 (line 211) 46760* __bid_floatunssitd: Decimal float library routines. 46761 (line 215) 46762* __bid_gedd2: Decimal float library routines. 46763 (line 276) 46764* __bid_gesd2: Decimal float library routines. 46765 (line 274) 46766* __bid_getd2: Decimal float library routines. 46767 (line 278) 46768* __bid_gtdd2: Decimal float library routines. 46769 (line 303) 46770* __bid_gtsd2: Decimal float library routines. 46771 (line 301) 46772* __bid_gttd2: Decimal float library routines. 46773 (line 305) 46774* __bid_ledd2: Decimal float library routines. 46775 (line 294) 46776* __bid_lesd2: Decimal float library routines. 46777 (line 292) 46778* __bid_letd2: Decimal float library routines. 46779 (line 296) 46780* __bid_ltdd2: Decimal float library routines. 46781 (line 285) 46782* __bid_ltsd2: Decimal float library routines. 46783 (line 283) 46784* __bid_lttd2: Decimal float library routines. 46785 (line 287) 46786* __bid_muldd3: Decimal float library routines. 46787 (line 52) 46788* __bid_mulsd3: Decimal float library routines. 46789 (line 48) 46790* __bid_multd3: Decimal float library routines. 46791 (line 56) 46792* __bid_nedd2: Decimal float library routines. 46793 (line 267) 46794* __bid_negdd2: Decimal float library routines. 46795 (line 77) 46796* __bid_negsd2: Decimal float library routines. 46797 (line 75) 46798* __bid_negtd2: Decimal float library routines. 46799 (line 79) 46800* __bid_nesd2: Decimal float library routines. 46801 (line 265) 46802* __bid_netd2: Decimal float library routines. 46803 (line 269) 46804* __bid_subdd3: Decimal float library routines. 46805 (line 37) 46806* __bid_subsd3: Decimal float library routines. 46807 (line 33) 46808* __bid_subtd3: Decimal float library routines. 46809 (line 41) 46810* __bid_truncdddf: Decimal float library routines. 46811 (line 152) 46812* __bid_truncddsd2: Decimal float library routines. 46813 (line 93) 46814* __bid_truncddsf: Decimal float library routines. 46815 (line 123) 46816* __bid_truncdfsd: Decimal float library routines. 46817 (line 110) 46818* __bid_truncsdsf: Decimal float library routines. 46819 (line 150) 46820* __bid_trunctddd2: Decimal float library routines. 46821 (line 97) 46822* __bid_trunctddf: Decimal float library routines. 46823 (line 129) 46824* __bid_trunctdsd2: Decimal float library routines. 46825 (line 95) 46826* __bid_trunctdsf: Decimal float library routines. 46827 (line 125) 46828* __bid_trunctdtf: Decimal float library routines. 46829 (line 154) 46830* __bid_trunctdxf: Decimal float library routines. 46831 (line 135) 46832* __bid_trunctfdd: Decimal float library routines. 46833 (line 118) 46834* __bid_trunctfsd: Decimal float library routines. 46835 (line 114) 46836* __bid_truncxfdd: Decimal float library routines. 46837 (line 116) 46838* __bid_truncxfsd: Decimal float library routines. 46839 (line 112) 46840* __bid_unorddd2: Decimal float library routines. 46841 (line 234) 46842* __bid_unordsd2: Decimal float library routines. 46843 (line 232) 46844* __bid_unordtd2: Decimal float library routines. 46845 (line 236) 46846* __bswapdi2: Integer library routines. 46847 (line 161) 46848* __bswapsi2: Integer library routines. 46849 (line 160) 46850* __builtin_classify_type: Varargs. (line 48) 46851* __builtin_next_arg: Varargs. (line 39) 46852* __builtin_saveregs: Varargs. (line 22) 46853* __chkp_bndcl: Misc. (line 672) 46854* __chkp_bndcu: Misc. (line 678) 46855* __chkp_bndldx: Misc. (line 666) 46856* __chkp_bndmk: Misc. (line 653) 46857* __chkp_bndret: Misc. (line 684) 46858* __chkp_bndstx: Misc. (line 660) 46859* __chkp_intersect: Misc. (line 690) 46860* __chkp_narrow: Misc. (line 695) 46861* __chkp_sizeof: Misc. (line 701) 46862* __clear_cache: Miscellaneous routines. 46863 (line 9) 46864* __clzdi2: Integer library routines. 46865 (line 130) 46866* __clzsi2: Integer library routines. 46867 (line 129) 46868* __clzti2: Integer library routines. 46869 (line 131) 46870* __cmpda2: Fixed-point fractional library routines. 46871 (line 458) 46872* __cmpdf2: Soft float library routines. 46873 (line 163) 46874* __cmpdi2: Integer library routines. 46875 (line 86) 46876* __cmpdq2: Fixed-point fractional library routines. 46877 (line 447) 46878* __cmpha2: Fixed-point fractional library routines. 46879 (line 456) 46880* __cmphq2: Fixed-point fractional library routines. 46881 (line 445) 46882* __cmpqq2: Fixed-point fractional library routines. 46883 (line 444) 46884* __cmpsa2: Fixed-point fractional library routines. 46885 (line 457) 46886* __cmpsf2: Soft float library routines. 46887 (line 162) 46888* __cmpsq2: Fixed-point fractional library routines. 46889 (line 446) 46890* __cmpta2: Fixed-point fractional library routines. 46891 (line 459) 46892* __cmptf2: Soft float library routines. 46893 (line 164) 46894* __cmpti2: Integer library routines. 46895 (line 87) 46896* __cmpuda2: Fixed-point fractional library routines. 46897 (line 464) 46898* __cmpudq2: Fixed-point fractional library routines. 46899 (line 454) 46900* __cmpuha2: Fixed-point fractional library routines. 46901 (line 461) 46902* __cmpuhq2: Fixed-point fractional library routines. 46903 (line 451) 46904* __cmpuqq2: Fixed-point fractional library routines. 46905 (line 449) 46906* __cmpusa2: Fixed-point fractional library routines. 46907 (line 463) 46908* __cmpusq2: Fixed-point fractional library routines. 46909 (line 452) 46910* __cmputa2: Fixed-point fractional library routines. 46911 (line 466) 46912* __CTOR_LIST__: Initialization. (line 25) 46913* __ctzdi2: Integer library routines. 46914 (line 137) 46915* __ctzsi2: Integer library routines. 46916 (line 136) 46917* __ctzti2: Integer library routines. 46918 (line 138) 46919* __divda3: Fixed-point fractional library routines. 46920 (line 234) 46921* __divdc3: Soft float library routines. 46922 (line 250) 46923* __divdf3: Soft float library routines. 46924 (line 47) 46925* __divdi3: Integer library routines. 46926 (line 24) 46927* __divdq3: Fixed-point fractional library routines. 46928 (line 229) 46929* __divha3: Fixed-point fractional library routines. 46930 (line 231) 46931* __divhq3: Fixed-point fractional library routines. 46932 (line 227) 46933* __divqq3: Fixed-point fractional library routines. 46934 (line 225) 46935* __divsa3: Fixed-point fractional library routines. 46936 (line 233) 46937* __divsc3: Soft float library routines. 46938 (line 248) 46939* __divsf3: Soft float library routines. 46940 (line 46) 46941* __divsi3: Integer library routines. 46942 (line 23) 46943* __divsq3: Fixed-point fractional library routines. 46944 (line 228) 46945* __divta3: Fixed-point fractional library routines. 46946 (line 235) 46947* __divtc3: Soft float library routines. 46948 (line 252) 46949* __divtf3: Soft float library routines. 46950 (line 48) 46951* __divti3: Integer library routines. 46952 (line 25) 46953* __divxc3: Soft float library routines. 46954 (line 254) 46955* __divxf3: Soft float library routines. 46956 (line 50) 46957* __dpd_adddd3: Decimal float library routines. 46958 (line 21) 46959* __dpd_addsd3: Decimal float library routines. 46960 (line 17) 46961* __dpd_addtd3: Decimal float library routines. 46962 (line 25) 46963* __dpd_divdd3: Decimal float library routines. 46964 (line 64) 46965* __dpd_divsd3: Decimal float library routines. 46966 (line 60) 46967* __dpd_divtd3: Decimal float library routines. 46968 (line 68) 46969* __dpd_eqdd2: Decimal float library routines. 46970 (line 257) 46971* __dpd_eqsd2: Decimal float library routines. 46972 (line 255) 46973* __dpd_eqtd2: Decimal float library routines. 46974 (line 259) 46975* __dpd_extendddtd2: Decimal float library routines. 46976 (line 90) 46977* __dpd_extendddtf: Decimal float library routines. 46978 (line 138) 46979* __dpd_extendddxf: Decimal float library routines. 46980 (line 132) 46981* __dpd_extenddfdd: Decimal float library routines. 46982 (line 145) 46983* __dpd_extenddftd: Decimal float library routines. 46984 (line 105) 46985* __dpd_extendsddd2: Decimal float library routines. 46986 (line 86) 46987* __dpd_extendsddf: Decimal float library routines. 46988 (line 126) 46989* __dpd_extendsdtd2: Decimal float library routines. 46990 (line 88) 46991* __dpd_extendsdtf: Decimal float library routines. 46992 (line 136) 46993* __dpd_extendsdxf: Decimal float library routines. 46994 (line 130) 46995* __dpd_extendsfdd: Decimal float library routines. 46996 (line 101) 46997* __dpd_extendsfsd: Decimal float library routines. 46998 (line 143) 46999* __dpd_extendsftd: Decimal float library routines. 47000 (line 103) 47001* __dpd_extendtftd: Decimal float library routines. 47002 (line 147) 47003* __dpd_extendxftd: Decimal float library routines. 47004 (line 107) 47005* __dpd_fixdddi: Decimal float library routines. 47006 (line 168) 47007* __dpd_fixddsi: Decimal float library routines. 47008 (line 160) 47009* __dpd_fixsddi: Decimal float library routines. 47010 (line 166) 47011* __dpd_fixsdsi: Decimal float library routines. 47012 (line 158) 47013* __dpd_fixtddi: Decimal float library routines. 47014 (line 170) 47015* __dpd_fixtdsi: Decimal float library routines. 47016 (line 162) 47017* __dpd_fixunsdddi: Decimal float library routines. 47018 (line 185) 47019* __dpd_fixunsddsi: Decimal float library routines. 47020 (line 176) 47021* __dpd_fixunssddi: Decimal float library routines. 47022 (line 183) 47023* __dpd_fixunssdsi: Decimal float library routines. 47024 (line 174) 47025* __dpd_fixunstddi: Decimal float library routines. 47026 (line 187) 47027* __dpd_fixunstdsi: Decimal float library routines. 47028 (line 178) 47029* __dpd_floatdidd: Decimal float library routines. 47030 (line 203) 47031* __dpd_floatdisd: Decimal float library routines. 47032 (line 201) 47033* __dpd_floatditd: Decimal float library routines. 47034 (line 205) 47035* __dpd_floatsidd: Decimal float library routines. 47036 (line 194) 47037* __dpd_floatsisd: Decimal float library routines. 47038 (line 192) 47039* __dpd_floatsitd: Decimal float library routines. 47040 (line 196) 47041* __dpd_floatunsdidd: Decimal float library routines. 47042 (line 221) 47043* __dpd_floatunsdisd: Decimal float library routines. 47044 (line 219) 47045* __dpd_floatunsditd: Decimal float library routines. 47046 (line 223) 47047* __dpd_floatunssidd: Decimal float library routines. 47048 (line 212) 47049* __dpd_floatunssisd: Decimal float library routines. 47050 (line 210) 47051* __dpd_floatunssitd: Decimal float library routines. 47052 (line 214) 47053* __dpd_gedd2: Decimal float library routines. 47054 (line 275) 47055* __dpd_gesd2: Decimal float library routines. 47056 (line 273) 47057* __dpd_getd2: Decimal float library routines. 47058 (line 277) 47059* __dpd_gtdd2: Decimal float library routines. 47060 (line 302) 47061* __dpd_gtsd2: Decimal float library routines. 47062 (line 300) 47063* __dpd_gttd2: Decimal float library routines. 47064 (line 304) 47065* __dpd_ledd2: Decimal float library routines. 47066 (line 293) 47067* __dpd_lesd2: Decimal float library routines. 47068 (line 291) 47069* __dpd_letd2: Decimal float library routines. 47070 (line 295) 47071* __dpd_ltdd2: Decimal float library routines. 47072 (line 284) 47073* __dpd_ltsd2: Decimal float library routines. 47074 (line 282) 47075* __dpd_lttd2: Decimal float library routines. 47076 (line 286) 47077* __dpd_muldd3: Decimal float library routines. 47078 (line 50) 47079* __dpd_mulsd3: Decimal float library routines. 47080 (line 46) 47081* __dpd_multd3: Decimal float library routines. 47082 (line 54) 47083* __dpd_nedd2: Decimal float library routines. 47084 (line 266) 47085* __dpd_negdd2: Decimal float library routines. 47086 (line 76) 47087* __dpd_negsd2: Decimal float library routines. 47088 (line 74) 47089* __dpd_negtd2: Decimal float library routines. 47090 (line 78) 47091* __dpd_nesd2: Decimal float library routines. 47092 (line 264) 47093* __dpd_netd2: Decimal float library routines. 47094 (line 268) 47095* __dpd_subdd3: Decimal float library routines. 47096 (line 35) 47097* __dpd_subsd3: Decimal float library routines. 47098 (line 31) 47099* __dpd_subtd3: Decimal float library routines. 47100 (line 39) 47101* __dpd_truncdddf: Decimal float library routines. 47102 (line 151) 47103* __dpd_truncddsd2: Decimal float library routines. 47104 (line 92) 47105* __dpd_truncddsf: Decimal float library routines. 47106 (line 122) 47107* __dpd_truncdfsd: Decimal float library routines. 47108 (line 109) 47109* __dpd_truncsdsf: Decimal float library routines. 47110 (line 149) 47111* __dpd_trunctddd2: Decimal float library routines. 47112 (line 96) 47113* __dpd_trunctddf: Decimal float library routines. 47114 (line 128) 47115* __dpd_trunctdsd2: Decimal float library routines. 47116 (line 94) 47117* __dpd_trunctdsf: Decimal float library routines. 47118 (line 124) 47119* __dpd_trunctdtf: Decimal float library routines. 47120 (line 153) 47121* __dpd_trunctdxf: Decimal float library routines. 47122 (line 134) 47123* __dpd_trunctfdd: Decimal float library routines. 47124 (line 117) 47125* __dpd_trunctfsd: Decimal float library routines. 47126 (line 113) 47127* __dpd_truncxfdd: Decimal float library routines. 47128 (line 115) 47129* __dpd_truncxfsd: Decimal float library routines. 47130 (line 111) 47131* __dpd_unorddd2: Decimal float library routines. 47132 (line 233) 47133* __dpd_unordsd2: Decimal float library routines. 47134 (line 231) 47135* __dpd_unordtd2: Decimal float library routines. 47136 (line 235) 47137* __DTOR_LIST__: Initialization. (line 25) 47138* __eqdf2: Soft float library routines. 47139 (line 193) 47140* __eqsf2: Soft float library routines. 47141 (line 192) 47142* __eqtf2: Soft float library routines. 47143 (line 194) 47144* __extenddftf2: Soft float library routines. 47145 (line 67) 47146* __extenddfxf2: Soft float library routines. 47147 (line 68) 47148* __extendsfdf2: Soft float library routines. 47149 (line 64) 47150* __extendsftf2: Soft float library routines. 47151 (line 65) 47152* __extendsfxf2: Soft float library routines. 47153 (line 66) 47154* __ffsdi2: Integer library routines. 47155 (line 143) 47156* __ffsti2: Integer library routines. 47157 (line 144) 47158* __fixdfdi: Soft float library routines. 47159 (line 87) 47160* __fixdfsi: Soft float library routines. 47161 (line 80) 47162* __fixdfti: Soft float library routines. 47163 (line 93) 47164* __fixsfdi: Soft float library routines. 47165 (line 86) 47166* __fixsfsi: Soft float library routines. 47167 (line 79) 47168* __fixsfti: Soft float library routines. 47169 (line 92) 47170* __fixtfdi: Soft float library routines. 47171 (line 88) 47172* __fixtfsi: Soft float library routines. 47173 (line 81) 47174* __fixtfti: Soft float library routines. 47175 (line 94) 47176* __fixunsdfdi: Soft float library routines. 47177 (line 107) 47178* __fixunsdfsi: Soft float library routines. 47179 (line 100) 47180* __fixunsdfti: Soft float library routines. 47181 (line 114) 47182* __fixunssfdi: Soft float library routines. 47183 (line 106) 47184* __fixunssfsi: Soft float library routines. 47185 (line 99) 47186* __fixunssfti: Soft float library routines. 47187 (line 113) 47188* __fixunstfdi: Soft float library routines. 47189 (line 108) 47190* __fixunstfsi: Soft float library routines. 47191 (line 101) 47192* __fixunstfti: Soft float library routines. 47193 (line 115) 47194* __fixunsxfdi: Soft float library routines. 47195 (line 109) 47196* __fixunsxfsi: Soft float library routines. 47197 (line 102) 47198* __fixunsxfti: Soft float library routines. 47199 (line 116) 47200* __fixxfdi: Soft float library routines. 47201 (line 89) 47202* __fixxfsi: Soft float library routines. 47203 (line 82) 47204* __fixxfti: Soft float library routines. 47205 (line 95) 47206* __floatdidf: Soft float library routines. 47207 (line 127) 47208* __floatdisf: Soft float library routines. 47209 (line 126) 47210* __floatditf: Soft float library routines. 47211 (line 128) 47212* __floatdixf: Soft float library routines. 47213 (line 129) 47214* __floatsidf: Soft float library routines. 47215 (line 121) 47216* __floatsisf: Soft float library routines. 47217 (line 120) 47218* __floatsitf: Soft float library routines. 47219 (line 122) 47220* __floatsixf: Soft float library routines. 47221 (line 123) 47222* __floattidf: Soft float library routines. 47223 (line 133) 47224* __floattisf: Soft float library routines. 47225 (line 132) 47226* __floattitf: Soft float library routines. 47227 (line 134) 47228* __floattixf: Soft float library routines. 47229 (line 135) 47230* __floatundidf: Soft float library routines. 47231 (line 145) 47232* __floatundisf: Soft float library routines. 47233 (line 144) 47234* __floatunditf: Soft float library routines. 47235 (line 146) 47236* __floatundixf: Soft float library routines. 47237 (line 147) 47238* __floatunsidf: Soft float library routines. 47239 (line 139) 47240* __floatunsisf: Soft float library routines. 47241 (line 138) 47242* __floatunsitf: Soft float library routines. 47243 (line 140) 47244* __floatunsixf: Soft float library routines. 47245 (line 141) 47246* __floatuntidf: Soft float library routines. 47247 (line 151) 47248* __floatuntisf: Soft float library routines. 47249 (line 150) 47250* __floatuntitf: Soft float library routines. 47251 (line 152) 47252* __floatuntixf: Soft float library routines. 47253 (line 153) 47254* __fractdadf: Fixed-point fractional library routines. 47255 (line 643) 47256* __fractdadi: Fixed-point fractional library routines. 47257 (line 640) 47258* __fractdadq: Fixed-point fractional library routines. 47259 (line 623) 47260* __fractdaha2: Fixed-point fractional library routines. 47261 (line 624) 47262* __fractdahi: Fixed-point fractional library routines. 47263 (line 638) 47264* __fractdahq: Fixed-point fractional library routines. 47265 (line 621) 47266* __fractdaqi: Fixed-point fractional library routines. 47267 (line 637) 47268* __fractdaqq: Fixed-point fractional library routines. 47269 (line 620) 47270* __fractdasa2: Fixed-point fractional library routines. 47271 (line 625) 47272* __fractdasf: Fixed-point fractional library routines. 47273 (line 642) 47274* __fractdasi: Fixed-point fractional library routines. 47275 (line 639) 47276* __fractdasq: Fixed-point fractional library routines. 47277 (line 622) 47278* __fractdata2: Fixed-point fractional library routines. 47279 (line 626) 47280* __fractdati: Fixed-point fractional library routines. 47281 (line 641) 47282* __fractdauda: Fixed-point fractional library routines. 47283 (line 634) 47284* __fractdaudq: Fixed-point fractional library routines. 47285 (line 630) 47286* __fractdauha: Fixed-point fractional library routines. 47287 (line 632) 47288* __fractdauhq: Fixed-point fractional library routines. 47289 (line 628) 47290* __fractdauqq: Fixed-point fractional library routines. 47291 (line 627) 47292* __fractdausa: Fixed-point fractional library routines. 47293 (line 633) 47294* __fractdausq: Fixed-point fractional library routines. 47295 (line 629) 47296* __fractdauta: Fixed-point fractional library routines. 47297 (line 635) 47298* __fractdfda: Fixed-point fractional library routines. 47299 (line 1032) 47300* __fractdfdq: Fixed-point fractional library routines. 47301 (line 1029) 47302* __fractdfha: Fixed-point fractional library routines. 47303 (line 1030) 47304* __fractdfhq: Fixed-point fractional library routines. 47305 (line 1027) 47306* __fractdfqq: Fixed-point fractional library routines. 47307 (line 1026) 47308* __fractdfsa: Fixed-point fractional library routines. 47309 (line 1031) 47310* __fractdfsq: Fixed-point fractional library routines. 47311 (line 1028) 47312* __fractdfta: Fixed-point fractional library routines. 47313 (line 1033) 47314* __fractdfuda: Fixed-point fractional library routines. 47315 (line 1040) 47316* __fractdfudq: Fixed-point fractional library routines. 47317 (line 1037) 47318* __fractdfuha: Fixed-point fractional library routines. 47319 (line 1038) 47320* __fractdfuhq: Fixed-point fractional library routines. 47321 (line 1035) 47322* __fractdfuqq: Fixed-point fractional library routines. 47323 (line 1034) 47324* __fractdfusa: Fixed-point fractional library routines. 47325 (line 1039) 47326* __fractdfusq: Fixed-point fractional library routines. 47327 (line 1036) 47328* __fractdfuta: Fixed-point fractional library routines. 47329 (line 1041) 47330* __fractdida: Fixed-point fractional library routines. 47331 (line 982) 47332* __fractdidq: Fixed-point fractional library routines. 47333 (line 979) 47334* __fractdiha: Fixed-point fractional library routines. 47335 (line 980) 47336* __fractdihq: Fixed-point fractional library routines. 47337 (line 977) 47338* __fractdiqq: Fixed-point fractional library routines. 47339 (line 976) 47340* __fractdisa: Fixed-point fractional library routines. 47341 (line 981) 47342* __fractdisq: Fixed-point fractional library routines. 47343 (line 978) 47344* __fractdita: Fixed-point fractional library routines. 47345 (line 983) 47346* __fractdiuda: Fixed-point fractional library routines. 47347 (line 990) 47348* __fractdiudq: Fixed-point fractional library routines. 47349 (line 987) 47350* __fractdiuha: Fixed-point fractional library routines. 47351 (line 988) 47352* __fractdiuhq: Fixed-point fractional library routines. 47353 (line 985) 47354* __fractdiuqq: Fixed-point fractional library routines. 47355 (line 984) 47356* __fractdiusa: Fixed-point fractional library routines. 47357 (line 989) 47358* __fractdiusq: Fixed-point fractional library routines. 47359 (line 986) 47360* __fractdiuta: Fixed-point fractional library routines. 47361 (line 991) 47362* __fractdqda: Fixed-point fractional library routines. 47363 (line 551) 47364* __fractdqdf: Fixed-point fractional library routines. 47365 (line 573) 47366* __fractdqdi: Fixed-point fractional library routines. 47367 (line 570) 47368* __fractdqha: Fixed-point fractional library routines. 47369 (line 549) 47370* __fractdqhi: Fixed-point fractional library routines. 47371 (line 568) 47372* __fractdqhq2: Fixed-point fractional library routines. 47373 (line 547) 47374* __fractdqqi: Fixed-point fractional library routines. 47375 (line 567) 47376* __fractdqqq2: Fixed-point fractional library routines. 47377 (line 546) 47378* __fractdqsa: Fixed-point fractional library routines. 47379 (line 550) 47380* __fractdqsf: Fixed-point fractional library routines. 47381 (line 572) 47382* __fractdqsi: Fixed-point fractional library routines. 47383 (line 569) 47384* __fractdqsq2: Fixed-point fractional library routines. 47385 (line 548) 47386* __fractdqta: Fixed-point fractional library routines. 47387 (line 552) 47388* __fractdqti: Fixed-point fractional library routines. 47389 (line 571) 47390* __fractdquda: Fixed-point fractional library routines. 47391 (line 563) 47392* __fractdqudq: Fixed-point fractional library routines. 47393 (line 558) 47394* __fractdquha: Fixed-point fractional library routines. 47395 (line 560) 47396* __fractdquhq: Fixed-point fractional library routines. 47397 (line 555) 47398* __fractdquqq: Fixed-point fractional library routines. 47399 (line 553) 47400* __fractdqusa: Fixed-point fractional library routines. 47401 (line 562) 47402* __fractdqusq: Fixed-point fractional library routines. 47403 (line 556) 47404* __fractdquta: Fixed-point fractional library routines. 47405 (line 565) 47406* __fracthada2: Fixed-point fractional library routines. 47407 (line 579) 47408* __fracthadf: Fixed-point fractional library routines. 47409 (line 597) 47410* __fracthadi: Fixed-point fractional library routines. 47411 (line 594) 47412* __fracthadq: Fixed-point fractional library routines. 47413 (line 577) 47414* __fracthahi: Fixed-point fractional library routines. 47415 (line 592) 47416* __fracthahq: Fixed-point fractional library routines. 47417 (line 575) 47418* __fracthaqi: Fixed-point fractional library routines. 47419 (line 591) 47420* __fracthaqq: Fixed-point fractional library routines. 47421 (line 574) 47422* __fracthasa2: Fixed-point fractional library routines. 47423 (line 578) 47424* __fracthasf: Fixed-point fractional library routines. 47425 (line 596) 47426* __fracthasi: Fixed-point fractional library routines. 47427 (line 593) 47428* __fracthasq: Fixed-point fractional library routines. 47429 (line 576) 47430* __fracthata2: Fixed-point fractional library routines. 47431 (line 580) 47432* __fracthati: Fixed-point fractional library routines. 47433 (line 595) 47434* __fracthauda: Fixed-point fractional library routines. 47435 (line 588) 47436* __fracthaudq: Fixed-point fractional library routines. 47437 (line 584) 47438* __fracthauha: Fixed-point fractional library routines. 47439 (line 586) 47440* __fracthauhq: Fixed-point fractional library routines. 47441 (line 582) 47442* __fracthauqq: Fixed-point fractional library routines. 47443 (line 581) 47444* __fracthausa: Fixed-point fractional library routines. 47445 (line 587) 47446* __fracthausq: Fixed-point fractional library routines. 47447 (line 583) 47448* __fracthauta: Fixed-point fractional library routines. 47449 (line 589) 47450* __fracthida: Fixed-point fractional library routines. 47451 (line 950) 47452* __fracthidq: Fixed-point fractional library routines. 47453 (line 947) 47454* __fracthiha: Fixed-point fractional library routines. 47455 (line 948) 47456* __fracthihq: Fixed-point fractional library routines. 47457 (line 945) 47458* __fracthiqq: Fixed-point fractional library routines. 47459 (line 944) 47460* __fracthisa: Fixed-point fractional library routines. 47461 (line 949) 47462* __fracthisq: Fixed-point fractional library routines. 47463 (line 946) 47464* __fracthita: Fixed-point fractional library routines. 47465 (line 951) 47466* __fracthiuda: Fixed-point fractional library routines. 47467 (line 958) 47468* __fracthiudq: Fixed-point fractional library routines. 47469 (line 955) 47470* __fracthiuha: Fixed-point fractional library routines. 47471 (line 956) 47472* __fracthiuhq: Fixed-point fractional library routines. 47473 (line 953) 47474* __fracthiuqq: Fixed-point fractional library routines. 47475 (line 952) 47476* __fracthiusa: Fixed-point fractional library routines. 47477 (line 957) 47478* __fracthiusq: Fixed-point fractional library routines. 47479 (line 954) 47480* __fracthiuta: Fixed-point fractional library routines. 47481 (line 959) 47482* __fracthqda: Fixed-point fractional library routines. 47483 (line 505) 47484* __fracthqdf: Fixed-point fractional library routines. 47485 (line 521) 47486* __fracthqdi: Fixed-point fractional library routines. 47487 (line 518) 47488* __fracthqdq2: Fixed-point fractional library routines. 47489 (line 502) 47490* __fracthqha: Fixed-point fractional library routines. 47491 (line 503) 47492* __fracthqhi: Fixed-point fractional library routines. 47493 (line 516) 47494* __fracthqqi: Fixed-point fractional library routines. 47495 (line 515) 47496* __fracthqqq2: Fixed-point fractional library routines. 47497 (line 500) 47498* __fracthqsa: Fixed-point fractional library routines. 47499 (line 504) 47500* __fracthqsf: Fixed-point fractional library routines. 47501 (line 520) 47502* __fracthqsi: Fixed-point fractional library routines. 47503 (line 517) 47504* __fracthqsq2: Fixed-point fractional library routines. 47505 (line 501) 47506* __fracthqta: Fixed-point fractional library routines. 47507 (line 506) 47508* __fracthqti: Fixed-point fractional library routines. 47509 (line 519) 47510* __fracthquda: Fixed-point fractional library routines. 47511 (line 513) 47512* __fracthqudq: Fixed-point fractional library routines. 47513 (line 510) 47514* __fracthquha: Fixed-point fractional library routines. 47515 (line 511) 47516* __fracthquhq: Fixed-point fractional library routines. 47517 (line 508) 47518* __fracthquqq: Fixed-point fractional library routines. 47519 (line 507) 47520* __fracthqusa: Fixed-point fractional library routines. 47521 (line 512) 47522* __fracthqusq: Fixed-point fractional library routines. 47523 (line 509) 47524* __fracthquta: Fixed-point fractional library routines. 47525 (line 514) 47526* __fractqida: Fixed-point fractional library routines. 47527 (line 932) 47528* __fractqidq: Fixed-point fractional library routines. 47529 (line 929) 47530* __fractqiha: Fixed-point fractional library routines. 47531 (line 930) 47532* __fractqihq: Fixed-point fractional library routines. 47533 (line 927) 47534* __fractqiqq: Fixed-point fractional library routines. 47535 (line 926) 47536* __fractqisa: Fixed-point fractional library routines. 47537 (line 931) 47538* __fractqisq: Fixed-point fractional library routines. 47539 (line 928) 47540* __fractqita: Fixed-point fractional library routines. 47541 (line 933) 47542* __fractqiuda: Fixed-point fractional library routines. 47543 (line 941) 47544* __fractqiudq: Fixed-point fractional library routines. 47545 (line 937) 47546* __fractqiuha: Fixed-point fractional library routines. 47547 (line 939) 47548* __fractqiuhq: Fixed-point fractional library routines. 47549 (line 935) 47550* __fractqiuqq: Fixed-point fractional library routines. 47551 (line 934) 47552* __fractqiusa: Fixed-point fractional library routines. 47553 (line 940) 47554* __fractqiusq: Fixed-point fractional library routines. 47555 (line 936) 47556* __fractqiuta: Fixed-point fractional library routines. 47557 (line 942) 47558* __fractqqda: Fixed-point fractional library routines. 47559 (line 481) 47560* __fractqqdf: Fixed-point fractional library routines. 47561 (line 499) 47562* __fractqqdi: Fixed-point fractional library routines. 47563 (line 496) 47564* __fractqqdq2: Fixed-point fractional library routines. 47565 (line 478) 47566* __fractqqha: Fixed-point fractional library routines. 47567 (line 479) 47568* __fractqqhi: Fixed-point fractional library routines. 47569 (line 494) 47570* __fractqqhq2: Fixed-point fractional library routines. 47571 (line 476) 47572* __fractqqqi: Fixed-point fractional library routines. 47573 (line 493) 47574* __fractqqsa: Fixed-point fractional library routines. 47575 (line 480) 47576* __fractqqsf: Fixed-point fractional library routines. 47577 (line 498) 47578* __fractqqsi: Fixed-point fractional library routines. 47579 (line 495) 47580* __fractqqsq2: Fixed-point fractional library routines. 47581 (line 477) 47582* __fractqqta: Fixed-point fractional library routines. 47583 (line 482) 47584* __fractqqti: Fixed-point fractional library routines. 47585 (line 497) 47586* __fractqquda: Fixed-point fractional library routines. 47587 (line 490) 47588* __fractqqudq: Fixed-point fractional library routines. 47589 (line 486) 47590* __fractqquha: Fixed-point fractional library routines. 47591 (line 488) 47592* __fractqquhq: Fixed-point fractional library routines. 47593 (line 484) 47594* __fractqquqq: Fixed-point fractional library routines. 47595 (line 483) 47596* __fractqqusa: Fixed-point fractional library routines. 47597 (line 489) 47598* __fractqqusq: Fixed-point fractional library routines. 47599 (line 485) 47600* __fractqquta: Fixed-point fractional library routines. 47601 (line 491) 47602* __fractsada2: Fixed-point fractional library routines. 47603 (line 603) 47604* __fractsadf: Fixed-point fractional library routines. 47605 (line 619) 47606* __fractsadi: Fixed-point fractional library routines. 47607 (line 616) 47608* __fractsadq: Fixed-point fractional library routines. 47609 (line 601) 47610* __fractsaha2: Fixed-point fractional library routines. 47611 (line 602) 47612* __fractsahi: Fixed-point fractional library routines. 47613 (line 614) 47614* __fractsahq: Fixed-point fractional library routines. 47615 (line 599) 47616* __fractsaqi: Fixed-point fractional library routines. 47617 (line 613) 47618* __fractsaqq: Fixed-point fractional library routines. 47619 (line 598) 47620* __fractsasf: Fixed-point fractional library routines. 47621 (line 618) 47622* __fractsasi: Fixed-point fractional library routines. 47623 (line 615) 47624* __fractsasq: Fixed-point fractional library routines. 47625 (line 600) 47626* __fractsata2: Fixed-point fractional library routines. 47627 (line 604) 47628* __fractsati: Fixed-point fractional library routines. 47629 (line 617) 47630* __fractsauda: Fixed-point fractional library routines. 47631 (line 611) 47632* __fractsaudq: Fixed-point fractional library routines. 47633 (line 608) 47634* __fractsauha: Fixed-point fractional library routines. 47635 (line 609) 47636* __fractsauhq: Fixed-point fractional library routines. 47637 (line 606) 47638* __fractsauqq: Fixed-point fractional library routines. 47639 (line 605) 47640* __fractsausa: Fixed-point fractional library routines. 47641 (line 610) 47642* __fractsausq: Fixed-point fractional library routines. 47643 (line 607) 47644* __fractsauta: Fixed-point fractional library routines. 47645 (line 612) 47646* __fractsfda: Fixed-point fractional library routines. 47647 (line 1016) 47648* __fractsfdq: Fixed-point fractional library routines. 47649 (line 1013) 47650* __fractsfha: Fixed-point fractional library routines. 47651 (line 1014) 47652* __fractsfhq: Fixed-point fractional library routines. 47653 (line 1011) 47654* __fractsfqq: Fixed-point fractional library routines. 47655 (line 1010) 47656* __fractsfsa: Fixed-point fractional library routines. 47657 (line 1015) 47658* __fractsfsq: Fixed-point fractional library routines. 47659 (line 1012) 47660* __fractsfta: Fixed-point fractional library routines. 47661 (line 1017) 47662* __fractsfuda: Fixed-point fractional library routines. 47663 (line 1024) 47664* __fractsfudq: Fixed-point fractional library routines. 47665 (line 1021) 47666* __fractsfuha: Fixed-point fractional library routines. 47667 (line 1022) 47668* __fractsfuhq: Fixed-point fractional library routines. 47669 (line 1019) 47670* __fractsfuqq: Fixed-point fractional library routines. 47671 (line 1018) 47672* __fractsfusa: Fixed-point fractional library routines. 47673 (line 1023) 47674* __fractsfusq: Fixed-point fractional library routines. 47675 (line 1020) 47676* __fractsfuta: Fixed-point fractional library routines. 47677 (line 1025) 47678* __fractsida: Fixed-point fractional library routines. 47679 (line 966) 47680* __fractsidq: Fixed-point fractional library routines. 47681 (line 963) 47682* __fractsiha: Fixed-point fractional library routines. 47683 (line 964) 47684* __fractsihq: Fixed-point fractional library routines. 47685 (line 961) 47686* __fractsiqq: Fixed-point fractional library routines. 47687 (line 960) 47688* __fractsisa: Fixed-point fractional library routines. 47689 (line 965) 47690* __fractsisq: Fixed-point fractional library routines. 47691 (line 962) 47692* __fractsita: Fixed-point fractional library routines. 47693 (line 967) 47694* __fractsiuda: Fixed-point fractional library routines. 47695 (line 974) 47696* __fractsiudq: Fixed-point fractional library routines. 47697 (line 971) 47698* __fractsiuha: Fixed-point fractional library routines. 47699 (line 972) 47700* __fractsiuhq: Fixed-point fractional library routines. 47701 (line 969) 47702* __fractsiuqq: Fixed-point fractional library routines. 47703 (line 968) 47704* __fractsiusa: Fixed-point fractional library routines. 47705 (line 973) 47706* __fractsiusq: Fixed-point fractional library routines. 47707 (line 970) 47708* __fractsiuta: Fixed-point fractional library routines. 47709 (line 975) 47710* __fractsqda: Fixed-point fractional library routines. 47711 (line 527) 47712* __fractsqdf: Fixed-point fractional library routines. 47713 (line 545) 47714* __fractsqdi: Fixed-point fractional library routines. 47715 (line 542) 47716* __fractsqdq2: Fixed-point fractional library routines. 47717 (line 524) 47718* __fractsqha: Fixed-point fractional library routines. 47719 (line 525) 47720* __fractsqhi: Fixed-point fractional library routines. 47721 (line 540) 47722* __fractsqhq2: Fixed-point fractional library routines. 47723 (line 523) 47724* __fractsqqi: Fixed-point fractional library routines. 47725 (line 539) 47726* __fractsqqq2: Fixed-point fractional library routines. 47727 (line 522) 47728* __fractsqsa: Fixed-point fractional library routines. 47729 (line 526) 47730* __fractsqsf: Fixed-point fractional library routines. 47731 (line 544) 47732* __fractsqsi: Fixed-point fractional library routines. 47733 (line 541) 47734* __fractsqta: Fixed-point fractional library routines. 47735 (line 528) 47736* __fractsqti: Fixed-point fractional library routines. 47737 (line 543) 47738* __fractsquda: Fixed-point fractional library routines. 47739 (line 536) 47740* __fractsqudq: Fixed-point fractional library routines. 47741 (line 532) 47742* __fractsquha: Fixed-point fractional library routines. 47743 (line 534) 47744* __fractsquhq: Fixed-point fractional library routines. 47745 (line 530) 47746* __fractsquqq: Fixed-point fractional library routines. 47747 (line 529) 47748* __fractsqusa: Fixed-point fractional library routines. 47749 (line 535) 47750* __fractsqusq: Fixed-point fractional library routines. 47751 (line 531) 47752* __fractsquta: Fixed-point fractional library routines. 47753 (line 537) 47754* __fracttada2: Fixed-point fractional library routines. 47755 (line 650) 47756* __fracttadf: Fixed-point fractional library routines. 47757 (line 671) 47758* __fracttadi: Fixed-point fractional library routines. 47759 (line 668) 47760* __fracttadq: Fixed-point fractional library routines. 47761 (line 647) 47762* __fracttaha2: Fixed-point fractional library routines. 47763 (line 648) 47764* __fracttahi: Fixed-point fractional library routines. 47765 (line 666) 47766* __fracttahq: Fixed-point fractional library routines. 47767 (line 645) 47768* __fracttaqi: Fixed-point fractional library routines. 47769 (line 665) 47770* __fracttaqq: Fixed-point fractional library routines. 47771 (line 644) 47772* __fracttasa2: Fixed-point fractional library routines. 47773 (line 649) 47774* __fracttasf: Fixed-point fractional library routines. 47775 (line 670) 47776* __fracttasi: Fixed-point fractional library routines. 47777 (line 667) 47778* __fracttasq: Fixed-point fractional library routines. 47779 (line 646) 47780* __fracttati: Fixed-point fractional library routines. 47781 (line 669) 47782* __fracttauda: Fixed-point fractional library routines. 47783 (line 661) 47784* __fracttaudq: Fixed-point fractional library routines. 47785 (line 656) 47786* __fracttauha: Fixed-point fractional library routines. 47787 (line 658) 47788* __fracttauhq: Fixed-point fractional library routines. 47789 (line 653) 47790* __fracttauqq: Fixed-point fractional library routines. 47791 (line 651) 47792* __fracttausa: Fixed-point fractional library routines. 47793 (line 660) 47794* __fracttausq: Fixed-point fractional library routines. 47795 (line 654) 47796* __fracttauta: Fixed-point fractional library routines. 47797 (line 663) 47798* __fracttida: Fixed-point fractional library routines. 47799 (line 998) 47800* __fracttidq: Fixed-point fractional library routines. 47801 (line 995) 47802* __fracttiha: Fixed-point fractional library routines. 47803 (line 996) 47804* __fracttihq: Fixed-point fractional library routines. 47805 (line 993) 47806* __fracttiqq: Fixed-point fractional library routines. 47807 (line 992) 47808* __fracttisa: Fixed-point fractional library routines. 47809 (line 997) 47810* __fracttisq: Fixed-point fractional library routines. 47811 (line 994) 47812* __fracttita: Fixed-point fractional library routines. 47813 (line 999) 47814* __fracttiuda: Fixed-point fractional library routines. 47815 (line 1007) 47816* __fracttiudq: Fixed-point fractional library routines. 47817 (line 1003) 47818* __fracttiuha: Fixed-point fractional library routines. 47819 (line 1005) 47820* __fracttiuhq: Fixed-point fractional library routines. 47821 (line 1001) 47822* __fracttiuqq: Fixed-point fractional library routines. 47823 (line 1000) 47824* __fracttiusa: Fixed-point fractional library routines. 47825 (line 1006) 47826* __fracttiusq: Fixed-point fractional library routines. 47827 (line 1002) 47828* __fracttiuta: Fixed-point fractional library routines. 47829 (line 1008) 47830* __fractudada: Fixed-point fractional library routines. 47831 (line 865) 47832* __fractudadf: Fixed-point fractional library routines. 47833 (line 888) 47834* __fractudadi: Fixed-point fractional library routines. 47835 (line 885) 47836* __fractudadq: Fixed-point fractional library routines. 47837 (line 861) 47838* __fractudaha: Fixed-point fractional library routines. 47839 (line 863) 47840* __fractudahi: Fixed-point fractional library routines. 47841 (line 883) 47842* __fractudahq: Fixed-point fractional library routines. 47843 (line 859) 47844* __fractudaqi: Fixed-point fractional library routines. 47845 (line 882) 47846* __fractudaqq: Fixed-point fractional library routines. 47847 (line 858) 47848* __fractudasa: Fixed-point fractional library routines. 47849 (line 864) 47850* __fractudasf: Fixed-point fractional library routines. 47851 (line 887) 47852* __fractudasi: Fixed-point fractional library routines. 47853 (line 884) 47854* __fractudasq: Fixed-point fractional library routines. 47855 (line 860) 47856* __fractudata: Fixed-point fractional library routines. 47857 (line 866) 47858* __fractudati: Fixed-point fractional library routines. 47859 (line 886) 47860* __fractudaudq: Fixed-point fractional library routines. 47861 (line 874) 47862* __fractudauha2: Fixed-point fractional library routines. 47863 (line 876) 47864* __fractudauhq: Fixed-point fractional library routines. 47865 (line 870) 47866* __fractudauqq: Fixed-point fractional library routines. 47867 (line 868) 47868* __fractudausa2: Fixed-point fractional library routines. 47869 (line 878) 47870* __fractudausq: Fixed-point fractional library routines. 47871 (line 872) 47872* __fractudauta2: Fixed-point fractional library routines. 47873 (line 880) 47874* __fractudqda: Fixed-point fractional library routines. 47875 (line 772) 47876* __fractudqdf: Fixed-point fractional library routines. 47877 (line 798) 47878* __fractudqdi: Fixed-point fractional library routines. 47879 (line 794) 47880* __fractudqdq: Fixed-point fractional library routines. 47881 (line 767) 47882* __fractudqha: Fixed-point fractional library routines. 47883 (line 769) 47884* __fractudqhi: Fixed-point fractional library routines. 47885 (line 792) 47886* __fractudqhq: Fixed-point fractional library routines. 47887 (line 764) 47888* __fractudqqi: Fixed-point fractional library routines. 47889 (line 790) 47890* __fractudqqq: Fixed-point fractional library routines. 47891 (line 762) 47892* __fractudqsa: Fixed-point fractional library routines. 47893 (line 771) 47894* __fractudqsf: Fixed-point fractional library routines. 47895 (line 797) 47896* __fractudqsi: Fixed-point fractional library routines. 47897 (line 793) 47898* __fractudqsq: Fixed-point fractional library routines. 47899 (line 765) 47900* __fractudqta: Fixed-point fractional library routines. 47901 (line 774) 47902* __fractudqti: Fixed-point fractional library routines. 47903 (line 795) 47904* __fractudquda: Fixed-point fractional library routines. 47905 (line 786) 47906* __fractudquha: Fixed-point fractional library routines. 47907 (line 782) 47908* __fractudquhq2: Fixed-point fractional library routines. 47909 (line 778) 47910* __fractudquqq2: Fixed-point fractional library routines. 47911 (line 776) 47912* __fractudqusa: Fixed-point fractional library routines. 47913 (line 784) 47914* __fractudqusq2: Fixed-point fractional library routines. 47915 (line 780) 47916* __fractudquta: Fixed-point fractional library routines. 47917 (line 788) 47918* __fractuhada: Fixed-point fractional library routines. 47919 (line 806) 47920* __fractuhadf: Fixed-point fractional library routines. 47921 (line 829) 47922* __fractuhadi: Fixed-point fractional library routines. 47923 (line 826) 47924* __fractuhadq: Fixed-point fractional library routines. 47925 (line 802) 47926* __fractuhaha: Fixed-point fractional library routines. 47927 (line 804) 47928* __fractuhahi: Fixed-point fractional library routines. 47929 (line 824) 47930* __fractuhahq: Fixed-point fractional library routines. 47931 (line 800) 47932* __fractuhaqi: Fixed-point fractional library routines. 47933 (line 823) 47934* __fractuhaqq: Fixed-point fractional library routines. 47935 (line 799) 47936* __fractuhasa: Fixed-point fractional library routines. 47937 (line 805) 47938* __fractuhasf: Fixed-point fractional library routines. 47939 (line 828) 47940* __fractuhasi: Fixed-point fractional library routines. 47941 (line 825) 47942* __fractuhasq: Fixed-point fractional library routines. 47943 (line 801) 47944* __fractuhata: Fixed-point fractional library routines. 47945 (line 807) 47946* __fractuhati: Fixed-point fractional library routines. 47947 (line 827) 47948* __fractuhauda2: Fixed-point fractional library routines. 47949 (line 819) 47950* __fractuhaudq: Fixed-point fractional library routines. 47951 (line 815) 47952* __fractuhauhq: Fixed-point fractional library routines. 47953 (line 811) 47954* __fractuhauqq: Fixed-point fractional library routines. 47955 (line 809) 47956* __fractuhausa2: Fixed-point fractional library routines. 47957 (line 817) 47958* __fractuhausq: Fixed-point fractional library routines. 47959 (line 813) 47960* __fractuhauta2: Fixed-point fractional library routines. 47961 (line 821) 47962* __fractuhqda: Fixed-point fractional library routines. 47963 (line 709) 47964* __fractuhqdf: Fixed-point fractional library routines. 47965 (line 730) 47966* __fractuhqdi: Fixed-point fractional library routines. 47967 (line 727) 47968* __fractuhqdq: Fixed-point fractional library routines. 47969 (line 706) 47970* __fractuhqha: Fixed-point fractional library routines. 47971 (line 707) 47972* __fractuhqhi: Fixed-point fractional library routines. 47973 (line 725) 47974* __fractuhqhq: Fixed-point fractional library routines. 47975 (line 704) 47976* __fractuhqqi: Fixed-point fractional library routines. 47977 (line 724) 47978* __fractuhqqq: Fixed-point fractional library routines. 47979 (line 703) 47980* __fractuhqsa: Fixed-point fractional library routines. 47981 (line 708) 47982* __fractuhqsf: Fixed-point fractional library routines. 47983 (line 729) 47984* __fractuhqsi: Fixed-point fractional library routines. 47985 (line 726) 47986* __fractuhqsq: Fixed-point fractional library routines. 47987 (line 705) 47988* __fractuhqta: Fixed-point fractional library routines. 47989 (line 710) 47990* __fractuhqti: Fixed-point fractional library routines. 47991 (line 728) 47992* __fractuhquda: Fixed-point fractional library routines. 47993 (line 720) 47994* __fractuhqudq2: Fixed-point fractional library routines. 47995 (line 715) 47996* __fractuhquha: Fixed-point fractional library routines. 47997 (line 717) 47998* __fractuhquqq2: Fixed-point fractional library routines. 47999 (line 711) 48000* __fractuhqusa: Fixed-point fractional library routines. 48001 (line 719) 48002* __fractuhqusq2: Fixed-point fractional library routines. 48003 (line 713) 48004* __fractuhquta: Fixed-point fractional library routines. 48005 (line 722) 48006* __fractunsdadi: Fixed-point fractional library routines. 48007 (line 1562) 48008* __fractunsdahi: Fixed-point fractional library routines. 48009 (line 1560) 48010* __fractunsdaqi: Fixed-point fractional library routines. 48011 (line 1559) 48012* __fractunsdasi: Fixed-point fractional library routines. 48013 (line 1561) 48014* __fractunsdati: Fixed-point fractional library routines. 48015 (line 1563) 48016* __fractunsdida: Fixed-point fractional library routines. 48017 (line 1714) 48018* __fractunsdidq: Fixed-point fractional library routines. 48019 (line 1711) 48020* __fractunsdiha: Fixed-point fractional library routines. 48021 (line 1712) 48022* __fractunsdihq: Fixed-point fractional library routines. 48023 (line 1709) 48024* __fractunsdiqq: Fixed-point fractional library routines. 48025 (line 1708) 48026* __fractunsdisa: Fixed-point fractional library routines. 48027 (line 1713) 48028* __fractunsdisq: Fixed-point fractional library routines. 48029 (line 1710) 48030* __fractunsdita: Fixed-point fractional library routines. 48031 (line 1715) 48032* __fractunsdiuda: Fixed-point fractional library routines. 48033 (line 1726) 48034* __fractunsdiudq: Fixed-point fractional library routines. 48035 (line 1721) 48036* __fractunsdiuha: Fixed-point fractional library routines. 48037 (line 1723) 48038* __fractunsdiuhq: Fixed-point fractional library routines. 48039 (line 1718) 48040* __fractunsdiuqq: Fixed-point fractional library routines. 48041 (line 1716) 48042* __fractunsdiusa: Fixed-point fractional library routines. 48043 (line 1725) 48044* __fractunsdiusq: Fixed-point fractional library routines. 48045 (line 1719) 48046* __fractunsdiuta: Fixed-point fractional library routines. 48047 (line 1728) 48048* __fractunsdqdi: Fixed-point fractional library routines. 48049 (line 1546) 48050* __fractunsdqhi: Fixed-point fractional library routines. 48051 (line 1544) 48052* __fractunsdqqi: Fixed-point fractional library routines. 48053 (line 1543) 48054* __fractunsdqsi: Fixed-point fractional library routines. 48055 (line 1545) 48056* __fractunsdqti: Fixed-point fractional library routines. 48057 (line 1547) 48058* __fractunshadi: Fixed-point fractional library routines. 48059 (line 1552) 48060* __fractunshahi: Fixed-point fractional library routines. 48061 (line 1550) 48062* __fractunshaqi: Fixed-point fractional library routines. 48063 (line 1549) 48064* __fractunshasi: Fixed-point fractional library routines. 48065 (line 1551) 48066* __fractunshati: Fixed-point fractional library routines. 48067 (line 1553) 48068* __fractunshida: Fixed-point fractional library routines. 48069 (line 1670) 48070* __fractunshidq: Fixed-point fractional library routines. 48071 (line 1667) 48072* __fractunshiha: Fixed-point fractional library routines. 48073 (line 1668) 48074* __fractunshihq: Fixed-point fractional library routines. 48075 (line 1665) 48076* __fractunshiqq: Fixed-point fractional library routines. 48077 (line 1664) 48078* __fractunshisa: Fixed-point fractional library routines. 48079 (line 1669) 48080* __fractunshisq: Fixed-point fractional library routines. 48081 (line 1666) 48082* __fractunshita: Fixed-point fractional library routines. 48083 (line 1671) 48084* __fractunshiuda: Fixed-point fractional library routines. 48085 (line 1682) 48086* __fractunshiudq: Fixed-point fractional library routines. 48087 (line 1677) 48088* __fractunshiuha: Fixed-point fractional library routines. 48089 (line 1679) 48090* __fractunshiuhq: Fixed-point fractional library routines. 48091 (line 1674) 48092* __fractunshiuqq: Fixed-point fractional library routines. 48093 (line 1672) 48094* __fractunshiusa: Fixed-point fractional library routines. 48095 (line 1681) 48096* __fractunshiusq: Fixed-point fractional library routines. 48097 (line 1675) 48098* __fractunshiuta: Fixed-point fractional library routines. 48099 (line 1684) 48100* __fractunshqdi: Fixed-point fractional library routines. 48101 (line 1536) 48102* __fractunshqhi: Fixed-point fractional library routines. 48103 (line 1534) 48104* __fractunshqqi: Fixed-point fractional library routines. 48105 (line 1533) 48106* __fractunshqsi: Fixed-point fractional library routines. 48107 (line 1535) 48108* __fractunshqti: Fixed-point fractional library routines. 48109 (line 1537) 48110* __fractunsqida: Fixed-point fractional library routines. 48111 (line 1648) 48112* __fractunsqidq: Fixed-point fractional library routines. 48113 (line 1645) 48114* __fractunsqiha: Fixed-point fractional library routines. 48115 (line 1646) 48116* __fractunsqihq: Fixed-point fractional library routines. 48117 (line 1643) 48118* __fractunsqiqq: Fixed-point fractional library routines. 48119 (line 1642) 48120* __fractunsqisa: Fixed-point fractional library routines. 48121 (line 1647) 48122* __fractunsqisq: Fixed-point fractional library routines. 48123 (line 1644) 48124* __fractunsqita: Fixed-point fractional library routines. 48125 (line 1649) 48126* __fractunsqiuda: Fixed-point fractional library routines. 48127 (line 1660) 48128* __fractunsqiudq: Fixed-point fractional library routines. 48129 (line 1655) 48130* __fractunsqiuha: Fixed-point fractional library routines. 48131 (line 1657) 48132* __fractunsqiuhq: Fixed-point fractional library routines. 48133 (line 1652) 48134* __fractunsqiuqq: Fixed-point fractional library routines. 48135 (line 1650) 48136* __fractunsqiusa: Fixed-point fractional library routines. 48137 (line 1659) 48138* __fractunsqiusq: Fixed-point fractional library routines. 48139 (line 1653) 48140* __fractunsqiuta: Fixed-point fractional library routines. 48141 (line 1662) 48142* __fractunsqqdi: Fixed-point fractional library routines. 48143 (line 1531) 48144* __fractunsqqhi: Fixed-point fractional library routines. 48145 (line 1529) 48146* __fractunsqqqi: Fixed-point fractional library routines. 48147 (line 1528) 48148* __fractunsqqsi: Fixed-point fractional library routines. 48149 (line 1530) 48150* __fractunsqqti: Fixed-point fractional library routines. 48151 (line 1532) 48152* __fractunssadi: Fixed-point fractional library routines. 48153 (line 1557) 48154* __fractunssahi: Fixed-point fractional library routines. 48155 (line 1555) 48156* __fractunssaqi: Fixed-point fractional library routines. 48157 (line 1554) 48158* __fractunssasi: Fixed-point fractional library routines. 48159 (line 1556) 48160* __fractunssati: Fixed-point fractional library routines. 48161 (line 1558) 48162* __fractunssida: Fixed-point fractional library routines. 48163 (line 1692) 48164* __fractunssidq: Fixed-point fractional library routines. 48165 (line 1689) 48166* __fractunssiha: Fixed-point fractional library routines. 48167 (line 1690) 48168* __fractunssihq: Fixed-point fractional library routines. 48169 (line 1687) 48170* __fractunssiqq: Fixed-point fractional library routines. 48171 (line 1686) 48172* __fractunssisa: Fixed-point fractional library routines. 48173 (line 1691) 48174* __fractunssisq: Fixed-point fractional library routines. 48175 (line 1688) 48176* __fractunssita: Fixed-point fractional library routines. 48177 (line 1693) 48178* __fractunssiuda: Fixed-point fractional library routines. 48179 (line 1704) 48180* __fractunssiudq: Fixed-point fractional library routines. 48181 (line 1699) 48182* __fractunssiuha: Fixed-point fractional library routines. 48183 (line 1701) 48184* __fractunssiuhq: Fixed-point fractional library routines. 48185 (line 1696) 48186* __fractunssiuqq: Fixed-point fractional library routines. 48187 (line 1694) 48188* __fractunssiusa: Fixed-point fractional library routines. 48189 (line 1703) 48190* __fractunssiusq: Fixed-point fractional library routines. 48191 (line 1697) 48192* __fractunssiuta: Fixed-point fractional library routines. 48193 (line 1706) 48194* __fractunssqdi: Fixed-point fractional library routines. 48195 (line 1541) 48196* __fractunssqhi: Fixed-point fractional library routines. 48197 (line 1539) 48198* __fractunssqqi: Fixed-point fractional library routines. 48199 (line 1538) 48200* __fractunssqsi: Fixed-point fractional library routines. 48201 (line 1540) 48202* __fractunssqti: Fixed-point fractional library routines. 48203 (line 1542) 48204* __fractunstadi: Fixed-point fractional library routines. 48205 (line 1567) 48206* __fractunstahi: Fixed-point fractional library routines. 48207 (line 1565) 48208* __fractunstaqi: Fixed-point fractional library routines. 48209 (line 1564) 48210* __fractunstasi: Fixed-point fractional library routines. 48211 (line 1566) 48212* __fractunstati: Fixed-point fractional library routines. 48213 (line 1568) 48214* __fractunstida: Fixed-point fractional library routines. 48215 (line 1737) 48216* __fractunstidq: Fixed-point fractional library routines. 48217 (line 1733) 48218* __fractunstiha: Fixed-point fractional library routines. 48219 (line 1735) 48220* __fractunstihq: Fixed-point fractional library routines. 48221 (line 1731) 48222* __fractunstiqq: Fixed-point fractional library routines. 48223 (line 1730) 48224* __fractunstisa: Fixed-point fractional library routines. 48225 (line 1736) 48226* __fractunstisq: Fixed-point fractional library routines. 48227 (line 1732) 48228* __fractunstita: Fixed-point fractional library routines. 48229 (line 1738) 48230* __fractunstiuda: Fixed-point fractional library routines. 48231 (line 1752) 48232* __fractunstiudq: Fixed-point fractional library routines. 48233 (line 1746) 48234* __fractunstiuha: Fixed-point fractional library routines. 48235 (line 1748) 48236* __fractunstiuhq: Fixed-point fractional library routines. 48237 (line 1742) 48238* __fractunstiuqq: Fixed-point fractional library routines. 48239 (line 1740) 48240* __fractunstiusa: Fixed-point fractional library routines. 48241 (line 1750) 48242* __fractunstiusq: Fixed-point fractional library routines. 48243 (line 1744) 48244* __fractunstiuta: Fixed-point fractional library routines. 48245 (line 1754) 48246* __fractunsudadi: Fixed-point fractional library routines. 48247 (line 1628) 48248* __fractunsudahi: Fixed-point fractional library routines. 48249 (line 1624) 48250* __fractunsudaqi: Fixed-point fractional library routines. 48251 (line 1622) 48252* __fractunsudasi: Fixed-point fractional library routines. 48253 (line 1626) 48254* __fractunsudati: Fixed-point fractional library routines. 48255 (line 1630) 48256* __fractunsudqdi: Fixed-point fractional library routines. 48257 (line 1602) 48258* __fractunsudqhi: Fixed-point fractional library routines. 48259 (line 1598) 48260* __fractunsudqqi: Fixed-point fractional library routines. 48261 (line 1596) 48262* __fractunsudqsi: Fixed-point fractional library routines. 48263 (line 1600) 48264* __fractunsudqti: Fixed-point fractional library routines. 48265 (line 1604) 48266* __fractunsuhadi: Fixed-point fractional library routines. 48267 (line 1612) 48268* __fractunsuhahi: Fixed-point fractional library routines. 48269 (line 1608) 48270* __fractunsuhaqi: Fixed-point fractional library routines. 48271 (line 1606) 48272* __fractunsuhasi: Fixed-point fractional library routines. 48273 (line 1610) 48274* __fractunsuhati: Fixed-point fractional library routines. 48275 (line 1614) 48276* __fractunsuhqdi: Fixed-point fractional library routines. 48277 (line 1583) 48278* __fractunsuhqhi: Fixed-point fractional library routines. 48279 (line 1581) 48280* __fractunsuhqqi: Fixed-point fractional library routines. 48281 (line 1580) 48282* __fractunsuhqsi: Fixed-point fractional library routines. 48283 (line 1582) 48284* __fractunsuhqti: Fixed-point fractional library routines. 48285 (line 1584) 48286* __fractunsuqqdi: Fixed-point fractional library routines. 48287 (line 1576) 48288* __fractunsuqqhi: Fixed-point fractional library routines. 48289 (line 1572) 48290* __fractunsuqqqi: Fixed-point fractional library routines. 48291 (line 1570) 48292* __fractunsuqqsi: Fixed-point fractional library routines. 48293 (line 1574) 48294* __fractunsuqqti: Fixed-point fractional library routines. 48295 (line 1578) 48296* __fractunsusadi: Fixed-point fractional library routines. 48297 (line 1619) 48298* __fractunsusahi: Fixed-point fractional library routines. 48299 (line 1617) 48300* __fractunsusaqi: Fixed-point fractional library routines. 48301 (line 1616) 48302* __fractunsusasi: Fixed-point fractional library routines. 48303 (line 1618) 48304* __fractunsusati: Fixed-point fractional library routines. 48305 (line 1620) 48306* __fractunsusqdi: Fixed-point fractional library routines. 48307 (line 1592) 48308* __fractunsusqhi: Fixed-point fractional library routines. 48309 (line 1588) 48310* __fractunsusqqi: Fixed-point fractional library routines. 48311 (line 1586) 48312* __fractunsusqsi: Fixed-point fractional library routines. 48313 (line 1590) 48314* __fractunsusqti: Fixed-point fractional library routines. 48315 (line 1594) 48316* __fractunsutadi: Fixed-point fractional library routines. 48317 (line 1638) 48318* __fractunsutahi: Fixed-point fractional library routines. 48319 (line 1634) 48320* __fractunsutaqi: Fixed-point fractional library routines. 48321 (line 1632) 48322* __fractunsutasi: Fixed-point fractional library routines. 48323 (line 1636) 48324* __fractunsutati: Fixed-point fractional library routines. 48325 (line 1640) 48326* __fractuqqda: Fixed-point fractional library routines. 48327 (line 679) 48328* __fractuqqdf: Fixed-point fractional library routines. 48329 (line 702) 48330* __fractuqqdi: Fixed-point fractional library routines. 48331 (line 699) 48332* __fractuqqdq: Fixed-point fractional library routines. 48333 (line 675) 48334* __fractuqqha: Fixed-point fractional library routines. 48335 (line 677) 48336* __fractuqqhi: Fixed-point fractional library routines. 48337 (line 697) 48338* __fractuqqhq: Fixed-point fractional library routines. 48339 (line 673) 48340* __fractuqqqi: Fixed-point fractional library routines. 48341 (line 696) 48342* __fractuqqqq: Fixed-point fractional library routines. 48343 (line 672) 48344* __fractuqqsa: Fixed-point fractional library routines. 48345 (line 678) 48346* __fractuqqsf: Fixed-point fractional library routines. 48347 (line 701) 48348* __fractuqqsi: Fixed-point fractional library routines. 48349 (line 698) 48350* __fractuqqsq: Fixed-point fractional library routines. 48351 (line 674) 48352* __fractuqqta: Fixed-point fractional library routines. 48353 (line 680) 48354* __fractuqqti: Fixed-point fractional library routines. 48355 (line 700) 48356* __fractuqquda: Fixed-point fractional library routines. 48357 (line 692) 48358* __fractuqqudq2: Fixed-point fractional library routines. 48359 (line 686) 48360* __fractuqquha: Fixed-point fractional library routines. 48361 (line 688) 48362* __fractuqquhq2: Fixed-point fractional library routines. 48363 (line 682) 48364* __fractuqqusa: Fixed-point fractional library routines. 48365 (line 690) 48366* __fractuqqusq2: Fixed-point fractional library routines. 48367 (line 684) 48368* __fractuqquta: Fixed-point fractional library routines. 48369 (line 694) 48370* __fractusada: Fixed-point fractional library routines. 48371 (line 836) 48372* __fractusadf: Fixed-point fractional library routines. 48373 (line 857) 48374* __fractusadi: Fixed-point fractional library routines. 48375 (line 854) 48376* __fractusadq: Fixed-point fractional library routines. 48377 (line 833) 48378* __fractusaha: Fixed-point fractional library routines. 48379 (line 834) 48380* __fractusahi: Fixed-point fractional library routines. 48381 (line 852) 48382* __fractusahq: Fixed-point fractional library routines. 48383 (line 831) 48384* __fractusaqi: Fixed-point fractional library routines. 48385 (line 851) 48386* __fractusaqq: Fixed-point fractional library routines. 48387 (line 830) 48388* __fractusasa: Fixed-point fractional library routines. 48389 (line 835) 48390* __fractusasf: Fixed-point fractional library routines. 48391 (line 856) 48392* __fractusasi: Fixed-point fractional library routines. 48393 (line 853) 48394* __fractusasq: Fixed-point fractional library routines. 48395 (line 832) 48396* __fractusata: Fixed-point fractional library routines. 48397 (line 837) 48398* __fractusati: Fixed-point fractional library routines. 48399 (line 855) 48400* __fractusauda2: Fixed-point fractional library routines. 48401 (line 847) 48402* __fractusaudq: Fixed-point fractional library routines. 48403 (line 843) 48404* __fractusauha2: Fixed-point fractional library routines. 48405 (line 845) 48406* __fractusauhq: Fixed-point fractional library routines. 48407 (line 840) 48408* __fractusauqq: Fixed-point fractional library routines. 48409 (line 838) 48410* __fractusausq: Fixed-point fractional library routines. 48411 (line 841) 48412* __fractusauta2: Fixed-point fractional library routines. 48413 (line 849) 48414* __fractusqda: Fixed-point fractional library routines. 48415 (line 738) 48416* __fractusqdf: Fixed-point fractional library routines. 48417 (line 761) 48418* __fractusqdi: Fixed-point fractional library routines. 48419 (line 758) 48420* __fractusqdq: Fixed-point fractional library routines. 48421 (line 734) 48422* __fractusqha: Fixed-point fractional library routines. 48423 (line 736) 48424* __fractusqhi: Fixed-point fractional library routines. 48425 (line 756) 48426* __fractusqhq: Fixed-point fractional library routines. 48427 (line 732) 48428* __fractusqqi: Fixed-point fractional library routines. 48429 (line 755) 48430* __fractusqqq: Fixed-point fractional library routines. 48431 (line 731) 48432* __fractusqsa: Fixed-point fractional library routines. 48433 (line 737) 48434* __fractusqsf: Fixed-point fractional library routines. 48435 (line 760) 48436* __fractusqsi: Fixed-point fractional library routines. 48437 (line 757) 48438* __fractusqsq: Fixed-point fractional library routines. 48439 (line 733) 48440* __fractusqta: Fixed-point fractional library routines. 48441 (line 739) 48442* __fractusqti: Fixed-point fractional library routines. 48443 (line 759) 48444* __fractusquda: Fixed-point fractional library routines. 48445 (line 751) 48446* __fractusqudq2: Fixed-point fractional library routines. 48447 (line 745) 48448* __fractusquha: Fixed-point fractional library routines. 48449 (line 747) 48450* __fractusquhq2: Fixed-point fractional library routines. 48451 (line 743) 48452* __fractusquqq2: Fixed-point fractional library routines. 48453 (line 741) 48454* __fractusqusa: Fixed-point fractional library routines. 48455 (line 749) 48456* __fractusquta: Fixed-point fractional library routines. 48457 (line 753) 48458* __fractutada: Fixed-point fractional library routines. 48459 (line 899) 48460* __fractutadf: Fixed-point fractional library routines. 48461 (line 925) 48462* __fractutadi: Fixed-point fractional library routines. 48463 (line 921) 48464* __fractutadq: Fixed-point fractional library routines. 48465 (line 894) 48466* __fractutaha: Fixed-point fractional library routines. 48467 (line 896) 48468* __fractutahi: Fixed-point fractional library routines. 48469 (line 919) 48470* __fractutahq: Fixed-point fractional library routines. 48471 (line 891) 48472* __fractutaqi: Fixed-point fractional library routines. 48473 (line 917) 48474* __fractutaqq: Fixed-point fractional library routines. 48475 (line 889) 48476* __fractutasa: Fixed-point fractional library routines. 48477 (line 898) 48478* __fractutasf: Fixed-point fractional library routines. 48479 (line 924) 48480* __fractutasi: Fixed-point fractional library routines. 48481 (line 920) 48482* __fractutasq: Fixed-point fractional library routines. 48483 (line 892) 48484* __fractutata: Fixed-point fractional library routines. 48485 (line 901) 48486* __fractutati: Fixed-point fractional library routines. 48487 (line 922) 48488* __fractutauda2: Fixed-point fractional library routines. 48489 (line 915) 48490* __fractutaudq: Fixed-point fractional library routines. 48491 (line 909) 48492* __fractutauha2: Fixed-point fractional library routines. 48493 (line 911) 48494* __fractutauhq: Fixed-point fractional library routines. 48495 (line 905) 48496* __fractutauqq: Fixed-point fractional library routines. 48497 (line 903) 48498* __fractutausa2: Fixed-point fractional library routines. 48499 (line 913) 48500* __fractutausq: Fixed-point fractional library routines. 48501 (line 907) 48502* __gedf2: Soft float library routines. 48503 (line 205) 48504* __gesf2: Soft float library routines. 48505 (line 204) 48506* __getf2: Soft float library routines. 48507 (line 206) 48508* __gtdf2: Soft float library routines. 48509 (line 223) 48510* __gtsf2: Soft float library routines. 48511 (line 222) 48512* __gttf2: Soft float library routines. 48513 (line 224) 48514* __ledf2: Soft float library routines. 48515 (line 217) 48516* __lesf2: Soft float library routines. 48517 (line 216) 48518* __letf2: Soft float library routines. 48519 (line 218) 48520* __lshrdi3: Integer library routines. 48521 (line 30) 48522* __lshrsi3: Integer library routines. 48523 (line 29) 48524* __lshrti3: Integer library routines. 48525 (line 31) 48526* __lshruda3: Fixed-point fractional library routines. 48527 (line 396) 48528* __lshrudq3: Fixed-point fractional library routines. 48529 (line 390) 48530* __lshruha3: Fixed-point fractional library routines. 48531 (line 392) 48532* __lshruhq3: Fixed-point fractional library routines. 48533 (line 386) 48534* __lshruqq3: Fixed-point fractional library routines. 48535 (line 384) 48536* __lshrusa3: Fixed-point fractional library routines. 48537 (line 394) 48538* __lshrusq3: Fixed-point fractional library routines. 48539 (line 388) 48540* __lshruta3: Fixed-point fractional library routines. 48541 (line 398) 48542* __ltdf2: Soft float library routines. 48543 (line 211) 48544* __ltsf2: Soft float library routines. 48545 (line 210) 48546* __lttf2: Soft float library routines. 48547 (line 212) 48548* __main: Collect2. (line 15) 48549* __moddi3: Integer library routines. 48550 (line 36) 48551* __modsi3: Integer library routines. 48552 (line 35) 48553* __modti3: Integer library routines. 48554 (line 37) 48555* __morestack_current_segment: Miscellaneous routines. 48556 (line 45) 48557* __morestack_initial_sp: Miscellaneous routines. 48558 (line 46) 48559* __morestack_segments: Miscellaneous routines. 48560 (line 44) 48561* __mulda3: Fixed-point fractional library routines. 48562 (line 178) 48563* __muldc3: Soft float library routines. 48564 (line 239) 48565* __muldf3: Soft float library routines. 48566 (line 39) 48567* __muldi3: Integer library routines. 48568 (line 42) 48569* __muldq3: Fixed-point fractional library routines. 48570 (line 165) 48571* __mulha3: Fixed-point fractional library routines. 48572 (line 175) 48573* __mulhq3: Fixed-point fractional library routines. 48574 (line 163) 48575* __mulqq3: Fixed-point fractional library routines. 48576 (line 161) 48577* __mulsa3: Fixed-point fractional library routines. 48578 (line 177) 48579* __mulsc3: Soft float library routines. 48580 (line 237) 48581* __mulsf3: Soft float library routines. 48582 (line 38) 48583* __mulsi3: Integer library routines. 48584 (line 41) 48585* __mulsq3: Fixed-point fractional library routines. 48586 (line 164) 48587* __multa3: Fixed-point fractional library routines. 48588 (line 179) 48589* __multc3: Soft float library routines. 48590 (line 241) 48591* __multf3: Soft float library routines. 48592 (line 40) 48593* __multi3: Integer library routines. 48594 (line 43) 48595* __muluda3: Fixed-point fractional library routines. 48596 (line 185) 48597* __muludq3: Fixed-point fractional library routines. 48598 (line 173) 48599* __muluha3: Fixed-point fractional library routines. 48600 (line 181) 48601* __muluhq3: Fixed-point fractional library routines. 48602 (line 169) 48603* __muluqq3: Fixed-point fractional library routines. 48604 (line 167) 48605* __mulusa3: Fixed-point fractional library routines. 48606 (line 183) 48607* __mulusq3: Fixed-point fractional library routines. 48608 (line 171) 48609* __muluta3: Fixed-point fractional library routines. 48610 (line 187) 48611* __mulvdi3: Integer library routines. 48612 (line 114) 48613* __mulvsi3: Integer library routines. 48614 (line 113) 48615* __mulxc3: Soft float library routines. 48616 (line 243) 48617* __mulxf3: Soft float library routines. 48618 (line 42) 48619* __nedf2: Soft float library routines. 48620 (line 199) 48621* __negda2: Fixed-point fractional library routines. 48622 (line 306) 48623* __negdf2: Soft float library routines. 48624 (line 55) 48625* __negdi2: Integer library routines. 48626 (line 46) 48627* __negdq2: Fixed-point fractional library routines. 48628 (line 296) 48629* __negha2: Fixed-point fractional library routines. 48630 (line 304) 48631* __neghq2: Fixed-point fractional library routines. 48632 (line 294) 48633* __negqq2: Fixed-point fractional library routines. 48634 (line 293) 48635* __negsa2: Fixed-point fractional library routines. 48636 (line 305) 48637* __negsf2: Soft float library routines. 48638 (line 54) 48639* __negsq2: Fixed-point fractional library routines. 48640 (line 295) 48641* __negta2: Fixed-point fractional library routines. 48642 (line 307) 48643* __negtf2: Soft float library routines. 48644 (line 56) 48645* __negti2: Integer library routines. 48646 (line 47) 48647* __neguda2: Fixed-point fractional library routines. 48648 (line 311) 48649* __negudq2: Fixed-point fractional library routines. 48650 (line 302) 48651* __neguha2: Fixed-point fractional library routines. 48652 (line 308) 48653* __neguhq2: Fixed-point fractional library routines. 48654 (line 299) 48655* __neguqq2: Fixed-point fractional library routines. 48656 (line 297) 48657* __negusa2: Fixed-point fractional library routines. 48658 (line 310) 48659* __negusq2: Fixed-point fractional library routines. 48660 (line 300) 48661* __neguta2: Fixed-point fractional library routines. 48662 (line 313) 48663* __negvdi2: Integer library routines. 48664 (line 118) 48665* __negvsi2: Integer library routines. 48666 (line 117) 48667* __negxf2: Soft float library routines. 48668 (line 57) 48669* __nesf2: Soft float library routines. 48670 (line 198) 48671* __netf2: Soft float library routines. 48672 (line 200) 48673* __paritydi2: Integer library routines. 48674 (line 150) 48675* __paritysi2: Integer library routines. 48676 (line 149) 48677* __parityti2: Integer library routines. 48678 (line 151) 48679* __popcountdi2: Integer library routines. 48680 (line 156) 48681* __popcountsi2: Integer library routines. 48682 (line 155) 48683* __popcountti2: Integer library routines. 48684 (line 157) 48685* __powidf2: Soft float library routines. 48686 (line 232) 48687* __powisf2: Soft float library routines. 48688 (line 231) 48689* __powitf2: Soft float library routines. 48690 (line 233) 48691* __powixf2: Soft float library routines. 48692 (line 234) 48693* __satfractdadq: Fixed-point fractional library routines. 48694 (line 1160) 48695* __satfractdaha2: Fixed-point fractional library routines. 48696 (line 1161) 48697* __satfractdahq: Fixed-point fractional library routines. 48698 (line 1158) 48699* __satfractdaqq: Fixed-point fractional library routines. 48700 (line 1157) 48701* __satfractdasa2: Fixed-point fractional library routines. 48702 (line 1162) 48703* __satfractdasq: Fixed-point fractional library routines. 48704 (line 1159) 48705* __satfractdata2: Fixed-point fractional library routines. 48706 (line 1163) 48707* __satfractdauda: Fixed-point fractional library routines. 48708 (line 1173) 48709* __satfractdaudq: Fixed-point fractional library routines. 48710 (line 1168) 48711* __satfractdauha: Fixed-point fractional library routines. 48712 (line 1170) 48713* __satfractdauhq: Fixed-point fractional library routines. 48714 (line 1166) 48715* __satfractdauqq: Fixed-point fractional library routines. 48716 (line 1164) 48717* __satfractdausa: Fixed-point fractional library routines. 48718 (line 1172) 48719* __satfractdausq: Fixed-point fractional library routines. 48720 (line 1167) 48721* __satfractdauta: Fixed-point fractional library routines. 48722 (line 1174) 48723* __satfractdfda: Fixed-point fractional library routines. 48724 (line 1513) 48725* __satfractdfdq: Fixed-point fractional library routines. 48726 (line 1510) 48727* __satfractdfha: Fixed-point fractional library routines. 48728 (line 1511) 48729* __satfractdfhq: Fixed-point fractional library routines. 48730 (line 1508) 48731* __satfractdfqq: Fixed-point fractional library routines. 48732 (line 1507) 48733* __satfractdfsa: Fixed-point fractional library routines. 48734 (line 1512) 48735* __satfractdfsq: Fixed-point fractional library routines. 48736 (line 1509) 48737* __satfractdfta: Fixed-point fractional library routines. 48738 (line 1514) 48739* __satfractdfuda: Fixed-point fractional library routines. 48740 (line 1522) 48741* __satfractdfudq: Fixed-point fractional library routines. 48742 (line 1518) 48743* __satfractdfuha: Fixed-point fractional library routines. 48744 (line 1520) 48745* __satfractdfuhq: Fixed-point fractional library routines. 48746 (line 1516) 48747* __satfractdfuqq: Fixed-point fractional library routines. 48748 (line 1515) 48749* __satfractdfusa: Fixed-point fractional library routines. 48750 (line 1521) 48751* __satfractdfusq: Fixed-point fractional library routines. 48752 (line 1517) 48753* __satfractdfuta: Fixed-point fractional library routines. 48754 (line 1523) 48755* __satfractdida: Fixed-point fractional library routines. 48756 (line 1463) 48757* __satfractdidq: Fixed-point fractional library routines. 48758 (line 1460) 48759* __satfractdiha: Fixed-point fractional library routines. 48760 (line 1461) 48761* __satfractdihq: Fixed-point fractional library routines. 48762 (line 1458) 48763* __satfractdiqq: Fixed-point fractional library routines. 48764 (line 1457) 48765* __satfractdisa: Fixed-point fractional library routines. 48766 (line 1462) 48767* __satfractdisq: Fixed-point fractional library routines. 48768 (line 1459) 48769* __satfractdita: Fixed-point fractional library routines. 48770 (line 1464) 48771* __satfractdiuda: Fixed-point fractional library routines. 48772 (line 1471) 48773* __satfractdiudq: Fixed-point fractional library routines. 48774 (line 1468) 48775* __satfractdiuha: Fixed-point fractional library routines. 48776 (line 1469) 48777* __satfractdiuhq: Fixed-point fractional library routines. 48778 (line 1466) 48779* __satfractdiuqq: Fixed-point fractional library routines. 48780 (line 1465) 48781* __satfractdiusa: Fixed-point fractional library routines. 48782 (line 1470) 48783* __satfractdiusq: Fixed-point fractional library routines. 48784 (line 1467) 48785* __satfractdiuta: Fixed-point fractional library routines. 48786 (line 1472) 48787* __satfractdqda: Fixed-point fractional library routines. 48788 (line 1105) 48789* __satfractdqha: Fixed-point fractional library routines. 48790 (line 1103) 48791* __satfractdqhq2: Fixed-point fractional library routines. 48792 (line 1101) 48793* __satfractdqqq2: Fixed-point fractional library routines. 48794 (line 1100) 48795* __satfractdqsa: Fixed-point fractional library routines. 48796 (line 1104) 48797* __satfractdqsq2: Fixed-point fractional library routines. 48798 (line 1102) 48799* __satfractdqta: Fixed-point fractional library routines. 48800 (line 1106) 48801* __satfractdquda: Fixed-point fractional library routines. 48802 (line 1117) 48803* __satfractdqudq: Fixed-point fractional library routines. 48804 (line 1112) 48805* __satfractdquha: Fixed-point fractional library routines. 48806 (line 1114) 48807* __satfractdquhq: Fixed-point fractional library routines. 48808 (line 1109) 48809* __satfractdquqq: Fixed-point fractional library routines. 48810 (line 1107) 48811* __satfractdqusa: Fixed-point fractional library routines. 48812 (line 1116) 48813* __satfractdqusq: Fixed-point fractional library routines. 48814 (line 1110) 48815* __satfractdquta: Fixed-point fractional library routines. 48816 (line 1119) 48817* __satfracthada2: Fixed-point fractional library routines. 48818 (line 1126) 48819* __satfracthadq: Fixed-point fractional library routines. 48820 (line 1124) 48821* __satfracthahq: Fixed-point fractional library routines. 48822 (line 1122) 48823* __satfracthaqq: Fixed-point fractional library routines. 48824 (line 1121) 48825* __satfracthasa2: Fixed-point fractional library routines. 48826 (line 1125) 48827* __satfracthasq: Fixed-point fractional library routines. 48828 (line 1123) 48829* __satfracthata2: Fixed-point fractional library routines. 48830 (line 1127) 48831* __satfracthauda: Fixed-point fractional library routines. 48832 (line 1138) 48833* __satfracthaudq: Fixed-point fractional library routines. 48834 (line 1133) 48835* __satfracthauha: Fixed-point fractional library routines. 48836 (line 1135) 48837* __satfracthauhq: Fixed-point fractional library routines. 48838 (line 1130) 48839* __satfracthauqq: Fixed-point fractional library routines. 48840 (line 1128) 48841* __satfracthausa: Fixed-point fractional library routines. 48842 (line 1137) 48843* __satfracthausq: Fixed-point fractional library routines. 48844 (line 1131) 48845* __satfracthauta: Fixed-point fractional library routines. 48846 (line 1140) 48847* __satfracthida: Fixed-point fractional library routines. 48848 (line 1431) 48849* __satfracthidq: Fixed-point fractional library routines. 48850 (line 1428) 48851* __satfracthiha: Fixed-point fractional library routines. 48852 (line 1429) 48853* __satfracthihq: Fixed-point fractional library routines. 48854 (line 1426) 48855* __satfracthiqq: Fixed-point fractional library routines. 48856 (line 1425) 48857* __satfracthisa: Fixed-point fractional library routines. 48858 (line 1430) 48859* __satfracthisq: Fixed-point fractional library routines. 48860 (line 1427) 48861* __satfracthita: Fixed-point fractional library routines. 48862 (line 1432) 48863* __satfracthiuda: Fixed-point fractional library routines. 48864 (line 1439) 48865* __satfracthiudq: Fixed-point fractional library routines. 48866 (line 1436) 48867* __satfracthiuha: Fixed-point fractional library routines. 48868 (line 1437) 48869* __satfracthiuhq: Fixed-point fractional library routines. 48870 (line 1434) 48871* __satfracthiuqq: Fixed-point fractional library routines. 48872 (line 1433) 48873* __satfracthiusa: Fixed-point fractional library routines. 48874 (line 1438) 48875* __satfracthiusq: Fixed-point fractional library routines. 48876 (line 1435) 48877* __satfracthiuta: Fixed-point fractional library routines. 48878 (line 1440) 48879* __satfracthqda: Fixed-point fractional library routines. 48880 (line 1071) 48881* __satfracthqdq2: Fixed-point fractional library routines. 48882 (line 1068) 48883* __satfracthqha: Fixed-point fractional library routines. 48884 (line 1069) 48885* __satfracthqqq2: Fixed-point fractional library routines. 48886 (line 1066) 48887* __satfracthqsa: Fixed-point fractional library routines. 48888 (line 1070) 48889* __satfracthqsq2: Fixed-point fractional library routines. 48890 (line 1067) 48891* __satfracthqta: Fixed-point fractional library routines. 48892 (line 1072) 48893* __satfracthquda: Fixed-point fractional library routines. 48894 (line 1079) 48895* __satfracthqudq: Fixed-point fractional library routines. 48896 (line 1076) 48897* __satfracthquha: Fixed-point fractional library routines. 48898 (line 1077) 48899* __satfracthquhq: Fixed-point fractional library routines. 48900 (line 1074) 48901* __satfracthquqq: Fixed-point fractional library routines. 48902 (line 1073) 48903* __satfracthqusa: Fixed-point fractional library routines. 48904 (line 1078) 48905* __satfracthqusq: Fixed-point fractional library routines. 48906 (line 1075) 48907* __satfracthquta: Fixed-point fractional library routines. 48908 (line 1080) 48909* __satfractqida: Fixed-point fractional library routines. 48910 (line 1409) 48911* __satfractqidq: Fixed-point fractional library routines. 48912 (line 1406) 48913* __satfractqiha: Fixed-point fractional library routines. 48914 (line 1407) 48915* __satfractqihq: Fixed-point fractional library routines. 48916 (line 1404) 48917* __satfractqiqq: Fixed-point fractional library routines. 48918 (line 1403) 48919* __satfractqisa: Fixed-point fractional library routines. 48920 (line 1408) 48921* __satfractqisq: Fixed-point fractional library routines. 48922 (line 1405) 48923* __satfractqita: Fixed-point fractional library routines. 48924 (line 1410) 48925* __satfractqiuda: Fixed-point fractional library routines. 48926 (line 1421) 48927* __satfractqiudq: Fixed-point fractional library routines. 48928 (line 1416) 48929* __satfractqiuha: Fixed-point fractional library routines. 48930 (line 1418) 48931* __satfractqiuhq: Fixed-point fractional library routines. 48932 (line 1413) 48933* __satfractqiuqq: Fixed-point fractional library routines. 48934 (line 1411) 48935* __satfractqiusa: Fixed-point fractional library routines. 48936 (line 1420) 48937* __satfractqiusq: Fixed-point fractional library routines. 48938 (line 1414) 48939* __satfractqiuta: Fixed-point fractional library routines. 48940 (line 1423) 48941* __satfractqqda: Fixed-point fractional library routines. 48942 (line 1050) 48943* __satfractqqdq2: Fixed-point fractional library routines. 48944 (line 1047) 48945* __satfractqqha: Fixed-point fractional library routines. 48946 (line 1048) 48947* __satfractqqhq2: Fixed-point fractional library routines. 48948 (line 1045) 48949* __satfractqqsa: Fixed-point fractional library routines. 48950 (line 1049) 48951* __satfractqqsq2: Fixed-point fractional library routines. 48952 (line 1046) 48953* __satfractqqta: Fixed-point fractional library routines. 48954 (line 1051) 48955* __satfractqquda: Fixed-point fractional library routines. 48956 (line 1062) 48957* __satfractqqudq: Fixed-point fractional library routines. 48958 (line 1057) 48959* __satfractqquha: Fixed-point fractional library routines. 48960 (line 1059) 48961* __satfractqquhq: Fixed-point fractional library routines. 48962 (line 1054) 48963* __satfractqquqq: Fixed-point fractional library routines. 48964 (line 1052) 48965* __satfractqqusa: Fixed-point fractional library routines. 48966 (line 1061) 48967* __satfractqqusq: Fixed-point fractional library routines. 48968 (line 1055) 48969* __satfractqquta: Fixed-point fractional library routines. 48970 (line 1064) 48971* __satfractsada2: Fixed-point fractional library routines. 48972 (line 1147) 48973* __satfractsadq: Fixed-point fractional library routines. 48974 (line 1145) 48975* __satfractsaha2: Fixed-point fractional library routines. 48976 (line 1146) 48977* __satfractsahq: Fixed-point fractional library routines. 48978 (line 1143) 48979* __satfractsaqq: Fixed-point fractional library routines. 48980 (line 1142) 48981* __satfractsasq: Fixed-point fractional library routines. 48982 (line 1144) 48983* __satfractsata2: Fixed-point fractional library routines. 48984 (line 1148) 48985* __satfractsauda: Fixed-point fractional library routines. 48986 (line 1155) 48987* __satfractsaudq: Fixed-point fractional library routines. 48988 (line 1152) 48989* __satfractsauha: Fixed-point fractional library routines. 48990 (line 1153) 48991* __satfractsauhq: Fixed-point fractional library routines. 48992 (line 1150) 48993* __satfractsauqq: Fixed-point fractional library routines. 48994 (line 1149) 48995* __satfractsausa: Fixed-point fractional library routines. 48996 (line 1154) 48997* __satfractsausq: Fixed-point fractional library routines. 48998 (line 1151) 48999* __satfractsauta: Fixed-point fractional library routines. 49000 (line 1156) 49001* __satfractsfda: Fixed-point fractional library routines. 49002 (line 1497) 49003* __satfractsfdq: Fixed-point fractional library routines. 49004 (line 1494) 49005* __satfractsfha: Fixed-point fractional library routines. 49006 (line 1495) 49007* __satfractsfhq: Fixed-point fractional library routines. 49008 (line 1492) 49009* __satfractsfqq: Fixed-point fractional library routines. 49010 (line 1491) 49011* __satfractsfsa: Fixed-point fractional library routines. 49012 (line 1496) 49013* __satfractsfsq: Fixed-point fractional library routines. 49014 (line 1493) 49015* __satfractsfta: Fixed-point fractional library routines. 49016 (line 1498) 49017* __satfractsfuda: Fixed-point fractional library routines. 49018 (line 1505) 49019* __satfractsfudq: Fixed-point fractional library routines. 49020 (line 1502) 49021* __satfractsfuha: Fixed-point fractional library routines. 49022 (line 1503) 49023* __satfractsfuhq: Fixed-point fractional library routines. 49024 (line 1500) 49025* __satfractsfuqq: Fixed-point fractional library routines. 49026 (line 1499) 49027* __satfractsfusa: Fixed-point fractional library routines. 49028 (line 1504) 49029* __satfractsfusq: Fixed-point fractional library routines. 49030 (line 1501) 49031* __satfractsfuta: Fixed-point fractional library routines. 49032 (line 1506) 49033* __satfractsida: Fixed-point fractional library routines. 49034 (line 1447) 49035* __satfractsidq: Fixed-point fractional library routines. 49036 (line 1444) 49037* __satfractsiha: Fixed-point fractional library routines. 49038 (line 1445) 49039* __satfractsihq: Fixed-point fractional library routines. 49040 (line 1442) 49041* __satfractsiqq: Fixed-point fractional library routines. 49042 (line 1441) 49043* __satfractsisa: Fixed-point fractional library routines. 49044 (line 1446) 49045* __satfractsisq: Fixed-point fractional library routines. 49046 (line 1443) 49047* __satfractsita: Fixed-point fractional library routines. 49048 (line 1448) 49049* __satfractsiuda: Fixed-point fractional library routines. 49050 (line 1455) 49051* __satfractsiudq: Fixed-point fractional library routines. 49052 (line 1452) 49053* __satfractsiuha: Fixed-point fractional library routines. 49054 (line 1453) 49055* __satfractsiuhq: Fixed-point fractional library routines. 49056 (line 1450) 49057* __satfractsiuqq: Fixed-point fractional library routines. 49058 (line 1449) 49059* __satfractsiusa: Fixed-point fractional library routines. 49060 (line 1454) 49061* __satfractsiusq: Fixed-point fractional library routines. 49062 (line 1451) 49063* __satfractsiuta: Fixed-point fractional library routines. 49064 (line 1456) 49065* __satfractsqda: Fixed-point fractional library routines. 49066 (line 1086) 49067* __satfractsqdq2: Fixed-point fractional library routines. 49068 (line 1083) 49069* __satfractsqha: Fixed-point fractional library routines. 49070 (line 1084) 49071* __satfractsqhq2: Fixed-point fractional library routines. 49072 (line 1082) 49073* __satfractsqqq2: Fixed-point fractional library routines. 49074 (line 1081) 49075* __satfractsqsa: Fixed-point fractional library routines. 49076 (line 1085) 49077* __satfractsqta: Fixed-point fractional library routines. 49078 (line 1087) 49079* __satfractsquda: Fixed-point fractional library routines. 49080 (line 1097) 49081* __satfractsqudq: Fixed-point fractional library routines. 49082 (line 1092) 49083* __satfractsquha: Fixed-point fractional library routines. 49084 (line 1094) 49085* __satfractsquhq: Fixed-point fractional library routines. 49086 (line 1090) 49087* __satfractsquqq: Fixed-point fractional library routines. 49088 (line 1088) 49089* __satfractsqusa: Fixed-point fractional library routines. 49090 (line 1096) 49091* __satfractsqusq: Fixed-point fractional library routines. 49092 (line 1091) 49093* __satfractsquta: Fixed-point fractional library routines. 49094 (line 1098) 49095* __satfracttada2: Fixed-point fractional library routines. 49096 (line 1182) 49097* __satfracttadq: Fixed-point fractional library routines. 49098 (line 1179) 49099* __satfracttaha2: Fixed-point fractional library routines. 49100 (line 1180) 49101* __satfracttahq: Fixed-point fractional library routines. 49102 (line 1177) 49103* __satfracttaqq: Fixed-point fractional library routines. 49104 (line 1176) 49105* __satfracttasa2: Fixed-point fractional library routines. 49106 (line 1181) 49107* __satfracttasq: Fixed-point fractional library routines. 49108 (line 1178) 49109* __satfracttauda: Fixed-point fractional library routines. 49110 (line 1193) 49111* __satfracttaudq: Fixed-point fractional library routines. 49112 (line 1188) 49113* __satfracttauha: Fixed-point fractional library routines. 49114 (line 1190) 49115* __satfracttauhq: Fixed-point fractional library routines. 49116 (line 1185) 49117* __satfracttauqq: Fixed-point fractional library routines. 49118 (line 1183) 49119* __satfracttausa: Fixed-point fractional library routines. 49120 (line 1192) 49121* __satfracttausq: Fixed-point fractional library routines. 49122 (line 1186) 49123* __satfracttauta: Fixed-point fractional library routines. 49124 (line 1195) 49125* __satfracttida: Fixed-point fractional library routines. 49126 (line 1479) 49127* __satfracttidq: Fixed-point fractional library routines. 49128 (line 1476) 49129* __satfracttiha: Fixed-point fractional library routines. 49130 (line 1477) 49131* __satfracttihq: Fixed-point fractional library routines. 49132 (line 1474) 49133* __satfracttiqq: Fixed-point fractional library routines. 49134 (line 1473) 49135* __satfracttisa: Fixed-point fractional library routines. 49136 (line 1478) 49137* __satfracttisq: Fixed-point fractional library routines. 49138 (line 1475) 49139* __satfracttita: Fixed-point fractional library routines. 49140 (line 1480) 49141* __satfracttiuda: Fixed-point fractional library routines. 49142 (line 1488) 49143* __satfracttiudq: Fixed-point fractional library routines. 49144 (line 1484) 49145* __satfracttiuha: Fixed-point fractional library routines. 49146 (line 1486) 49147* __satfracttiuhq: Fixed-point fractional library routines. 49148 (line 1482) 49149* __satfracttiuqq: Fixed-point fractional library routines. 49150 (line 1481) 49151* __satfracttiusa: Fixed-point fractional library routines. 49152 (line 1487) 49153* __satfracttiusq: Fixed-point fractional library routines. 49154 (line 1483) 49155* __satfracttiuta: Fixed-point fractional library routines. 49156 (line 1489) 49157* __satfractudada: Fixed-point fractional library routines. 49158 (line 1358) 49159* __satfractudadq: Fixed-point fractional library routines. 49160 (line 1353) 49161* __satfractudaha: Fixed-point fractional library routines. 49162 (line 1355) 49163* __satfractudahq: Fixed-point fractional library routines. 49164 (line 1351) 49165* __satfractudaqq: Fixed-point fractional library routines. 49166 (line 1349) 49167* __satfractudasa: Fixed-point fractional library routines. 49168 (line 1357) 49169* __satfractudasq: Fixed-point fractional library routines. 49170 (line 1352) 49171* __satfractudata: Fixed-point fractional library routines. 49172 (line 1359) 49173* __satfractudaudq: Fixed-point fractional library routines. 49174 (line 1367) 49175* __satfractudauha2: Fixed-point fractional library routines. 49176 (line 1369) 49177* __satfractudauhq: Fixed-point fractional library routines. 49178 (line 1363) 49179* __satfractudauqq: Fixed-point fractional library routines. 49180 (line 1361) 49181* __satfractudausa2: Fixed-point fractional library routines. 49182 (line 1371) 49183* __satfractudausq: Fixed-point fractional library routines. 49184 (line 1365) 49185* __satfractudauta2: Fixed-point fractional library routines. 49186 (line 1373) 49187* __satfractudqda: Fixed-point fractional library routines. 49188 (line 1282) 49189* __satfractudqdq: Fixed-point fractional library routines. 49190 (line 1277) 49191* __satfractudqha: Fixed-point fractional library routines. 49192 (line 1279) 49193* __satfractudqhq: Fixed-point fractional library routines. 49194 (line 1274) 49195* __satfractudqqq: Fixed-point fractional library routines. 49196 (line 1272) 49197* __satfractudqsa: Fixed-point fractional library routines. 49198 (line 1281) 49199* __satfractudqsq: Fixed-point fractional library routines. 49200 (line 1275) 49201* __satfractudqta: Fixed-point fractional library routines. 49202 (line 1284) 49203* __satfractudquda: Fixed-point fractional library routines. 49204 (line 1296) 49205* __satfractudquha: Fixed-point fractional library routines. 49206 (line 1292) 49207* __satfractudquhq2: Fixed-point fractional library routines. 49208 (line 1288) 49209* __satfractudquqq2: Fixed-point fractional library routines. 49210 (line 1286) 49211* __satfractudqusa: Fixed-point fractional library routines. 49212 (line 1294) 49213* __satfractudqusq2: Fixed-point fractional library routines. 49214 (line 1290) 49215* __satfractudquta: Fixed-point fractional library routines. 49216 (line 1298) 49217* __satfractuhada: Fixed-point fractional library routines. 49218 (line 1310) 49219* __satfractuhadq: Fixed-point fractional library routines. 49220 (line 1305) 49221* __satfractuhaha: Fixed-point fractional library routines. 49222 (line 1307) 49223* __satfractuhahq: Fixed-point fractional library routines. 49224 (line 1302) 49225* __satfractuhaqq: Fixed-point fractional library routines. 49226 (line 1300) 49227* __satfractuhasa: Fixed-point fractional library routines. 49228 (line 1309) 49229* __satfractuhasq: Fixed-point fractional library routines. 49230 (line 1303) 49231* __satfractuhata: Fixed-point fractional library routines. 49232 (line 1312) 49233* __satfractuhauda2: Fixed-point fractional library routines. 49234 (line 1324) 49235* __satfractuhaudq: Fixed-point fractional library routines. 49236 (line 1320) 49237* __satfractuhauhq: Fixed-point fractional library routines. 49238 (line 1316) 49239* __satfractuhauqq: Fixed-point fractional library routines. 49240 (line 1314) 49241* __satfractuhausa2: Fixed-point fractional library routines. 49242 (line 1322) 49243* __satfractuhausq: Fixed-point fractional library routines. 49244 (line 1318) 49245* __satfractuhauta2: Fixed-point fractional library routines. 49246 (line 1326) 49247* __satfractuhqda: Fixed-point fractional library routines. 49248 (line 1231) 49249* __satfractuhqdq: Fixed-point fractional library routines. 49250 (line 1228) 49251* __satfractuhqha: Fixed-point fractional library routines. 49252 (line 1229) 49253* __satfractuhqhq: Fixed-point fractional library routines. 49254 (line 1226) 49255* __satfractuhqqq: Fixed-point fractional library routines. 49256 (line 1225) 49257* __satfractuhqsa: Fixed-point fractional library routines. 49258 (line 1230) 49259* __satfractuhqsq: Fixed-point fractional library routines. 49260 (line 1227) 49261* __satfractuhqta: Fixed-point fractional library routines. 49262 (line 1232) 49263* __satfractuhquda: Fixed-point fractional library routines. 49264 (line 1242) 49265* __satfractuhqudq2: Fixed-point fractional library routines. 49266 (line 1237) 49267* __satfractuhquha: Fixed-point fractional library routines. 49268 (line 1239) 49269* __satfractuhquqq2: Fixed-point fractional library routines. 49270 (line 1233) 49271* __satfractuhqusa: Fixed-point fractional library routines. 49272 (line 1241) 49273* __satfractuhqusq2: Fixed-point fractional library routines. 49274 (line 1235) 49275* __satfractuhquta: Fixed-point fractional library routines. 49276 (line 1244) 49277* __satfractunsdida: Fixed-point fractional library routines. 49278 (line 1841) 49279* __satfractunsdidq: Fixed-point fractional library routines. 49280 (line 1837) 49281* __satfractunsdiha: Fixed-point fractional library routines. 49282 (line 1839) 49283* __satfractunsdihq: Fixed-point fractional library routines. 49284 (line 1835) 49285* __satfractunsdiqq: Fixed-point fractional library routines. 49286 (line 1834) 49287* __satfractunsdisa: Fixed-point fractional library routines. 49288 (line 1840) 49289* __satfractunsdisq: Fixed-point fractional library routines. 49290 (line 1836) 49291* __satfractunsdita: Fixed-point fractional library routines. 49292 (line 1842) 49293* __satfractunsdiuda: Fixed-point fractional library routines. 49294 (line 1856) 49295* __satfractunsdiudq: Fixed-point fractional library routines. 49296 (line 1850) 49297* __satfractunsdiuha: Fixed-point fractional library routines. 49298 (line 1852) 49299* __satfractunsdiuhq: Fixed-point fractional library routines. 49300 (line 1846) 49301* __satfractunsdiuqq: Fixed-point fractional library routines. 49302 (line 1844) 49303* __satfractunsdiusa: Fixed-point fractional library routines. 49304 (line 1854) 49305* __satfractunsdiusq: Fixed-point fractional library routines. 49306 (line 1848) 49307* __satfractunsdiuta: Fixed-point fractional library routines. 49308 (line 1858) 49309* __satfractunshida: Fixed-point fractional library routines. 49310 (line 1793) 49311* __satfractunshidq: Fixed-point fractional library routines. 49312 (line 1789) 49313* __satfractunshiha: Fixed-point fractional library routines. 49314 (line 1791) 49315* __satfractunshihq: Fixed-point fractional library routines. 49316 (line 1787) 49317* __satfractunshiqq: Fixed-point fractional library routines. 49318 (line 1786) 49319* __satfractunshisa: Fixed-point fractional library routines. 49320 (line 1792) 49321* __satfractunshisq: Fixed-point fractional library routines. 49322 (line 1788) 49323* __satfractunshita: Fixed-point fractional library routines. 49324 (line 1794) 49325* __satfractunshiuda: Fixed-point fractional library routines. 49326 (line 1808) 49327* __satfractunshiudq: Fixed-point fractional library routines. 49328 (line 1802) 49329* __satfractunshiuha: Fixed-point fractional library routines. 49330 (line 1804) 49331* __satfractunshiuhq: Fixed-point fractional library routines. 49332 (line 1798) 49333* __satfractunshiuqq: Fixed-point fractional library routines. 49334 (line 1796) 49335* __satfractunshiusa: Fixed-point fractional library routines. 49336 (line 1806) 49337* __satfractunshiusq: Fixed-point fractional library routines. 49338 (line 1800) 49339* __satfractunshiuta: Fixed-point fractional library routines. 49340 (line 1810) 49341* __satfractunsqida: Fixed-point fractional library routines. 49342 (line 1767) 49343* __satfractunsqidq: Fixed-point fractional library routines. 49344 (line 1763) 49345* __satfractunsqiha: Fixed-point fractional library routines. 49346 (line 1765) 49347* __satfractunsqihq: Fixed-point fractional library routines. 49348 (line 1761) 49349* __satfractunsqiqq: Fixed-point fractional library routines. 49350 (line 1760) 49351* __satfractunsqisa: Fixed-point fractional library routines. 49352 (line 1766) 49353* __satfractunsqisq: Fixed-point fractional library routines. 49354 (line 1762) 49355* __satfractunsqita: Fixed-point fractional library routines. 49356 (line 1768) 49357* __satfractunsqiuda: Fixed-point fractional library routines. 49358 (line 1782) 49359* __satfractunsqiudq: Fixed-point fractional library routines. 49360 (line 1776) 49361* __satfractunsqiuha: Fixed-point fractional library routines. 49362 (line 1778) 49363* __satfractunsqiuhq: Fixed-point fractional library routines. 49364 (line 1772) 49365* __satfractunsqiuqq: Fixed-point fractional library routines. 49366 (line 1770) 49367* __satfractunsqiusa: Fixed-point fractional library routines. 49368 (line 1780) 49369* __satfractunsqiusq: Fixed-point fractional library routines. 49370 (line 1774) 49371* __satfractunsqiuta: Fixed-point fractional library routines. 49372 (line 1784) 49373* __satfractunssida: Fixed-point fractional library routines. 49374 (line 1818) 49375* __satfractunssidq: Fixed-point fractional library routines. 49376 (line 1815) 49377* __satfractunssiha: Fixed-point fractional library routines. 49378 (line 1816) 49379* __satfractunssihq: Fixed-point fractional library routines. 49380 (line 1813) 49381* __satfractunssiqq: Fixed-point fractional library routines. 49382 (line 1812) 49383* __satfractunssisa: Fixed-point fractional library routines. 49384 (line 1817) 49385* __satfractunssisq: Fixed-point fractional library routines. 49386 (line 1814) 49387* __satfractunssita: Fixed-point fractional library routines. 49388 (line 1819) 49389* __satfractunssiuda: Fixed-point fractional library routines. 49390 (line 1830) 49391* __satfractunssiudq: Fixed-point fractional library routines. 49392 (line 1825) 49393* __satfractunssiuha: Fixed-point fractional library routines. 49394 (line 1827) 49395* __satfractunssiuhq: Fixed-point fractional library routines. 49396 (line 1822) 49397* __satfractunssiuqq: Fixed-point fractional library routines. 49398 (line 1820) 49399* __satfractunssiusa: Fixed-point fractional library routines. 49400 (line 1829) 49401* __satfractunssiusq: Fixed-point fractional library routines. 49402 (line 1823) 49403* __satfractunssiuta: Fixed-point fractional library routines. 49404 (line 1832) 49405* __satfractunstida: Fixed-point fractional library routines. 49406 (line 1870) 49407* __satfractunstidq: Fixed-point fractional library routines. 49408 (line 1865) 49409* __satfractunstiha: Fixed-point fractional library routines. 49410 (line 1867) 49411* __satfractunstihq: Fixed-point fractional library routines. 49412 (line 1862) 49413* __satfractunstiqq: Fixed-point fractional library routines. 49414 (line 1860) 49415* __satfractunstisa: Fixed-point fractional library routines. 49416 (line 1869) 49417* __satfractunstisq: Fixed-point fractional library routines. 49418 (line 1863) 49419* __satfractunstita: Fixed-point fractional library routines. 49420 (line 1872) 49421* __satfractunstiuda: Fixed-point fractional library routines. 49422 (line 1886) 49423* __satfractunstiudq: Fixed-point fractional library routines. 49424 (line 1880) 49425* __satfractunstiuha: Fixed-point fractional library routines. 49426 (line 1882) 49427* __satfractunstiuhq: Fixed-point fractional library routines. 49428 (line 1876) 49429* __satfractunstiuqq: Fixed-point fractional library routines. 49430 (line 1874) 49431* __satfractunstiusa: Fixed-point fractional library routines. 49432 (line 1884) 49433* __satfractunstiusq: Fixed-point fractional library routines. 49434 (line 1878) 49435* __satfractunstiuta: Fixed-point fractional library routines. 49436 (line 1888) 49437* __satfractuqqda: Fixed-point fractional library routines. 49438 (line 1207) 49439* __satfractuqqdq: Fixed-point fractional library routines. 49440 (line 1202) 49441* __satfractuqqha: Fixed-point fractional library routines. 49442 (line 1204) 49443* __satfractuqqhq: Fixed-point fractional library routines. 49444 (line 1199) 49445* __satfractuqqqq: Fixed-point fractional library routines. 49446 (line 1197) 49447* __satfractuqqsa: Fixed-point fractional library routines. 49448 (line 1206) 49449* __satfractuqqsq: Fixed-point fractional library routines. 49450 (line 1200) 49451* __satfractuqqta: Fixed-point fractional library routines. 49452 (line 1209) 49453* __satfractuqquda: Fixed-point fractional library routines. 49454 (line 1221) 49455* __satfractuqqudq2: Fixed-point fractional library routines. 49456 (line 1215) 49457* __satfractuqquha: Fixed-point fractional library routines. 49458 (line 1217) 49459* __satfractuqquhq2: Fixed-point fractional library routines. 49460 (line 1211) 49461* __satfractuqqusa: Fixed-point fractional library routines. 49462 (line 1219) 49463* __satfractuqqusq2: Fixed-point fractional library routines. 49464 (line 1213) 49465* __satfractuqquta: Fixed-point fractional library routines. 49466 (line 1223) 49467* __satfractusada: Fixed-point fractional library routines. 49468 (line 1334) 49469* __satfractusadq: Fixed-point fractional library routines. 49470 (line 1331) 49471* __satfractusaha: Fixed-point fractional library routines. 49472 (line 1332) 49473* __satfractusahq: Fixed-point fractional library routines. 49474 (line 1329) 49475* __satfractusaqq: Fixed-point fractional library routines. 49476 (line 1328) 49477* __satfractusasa: Fixed-point fractional library routines. 49478 (line 1333) 49479* __satfractusasq: Fixed-point fractional library routines. 49480 (line 1330) 49481* __satfractusata: Fixed-point fractional library routines. 49482 (line 1335) 49483* __satfractusauda2: Fixed-point fractional library routines. 49484 (line 1345) 49485* __satfractusaudq: Fixed-point fractional library routines. 49486 (line 1341) 49487* __satfractusauha2: Fixed-point fractional library routines. 49488 (line 1343) 49489* __satfractusauhq: Fixed-point fractional library routines. 49490 (line 1338) 49491* __satfractusauqq: Fixed-point fractional library routines. 49492 (line 1336) 49493* __satfractusausq: Fixed-point fractional library routines. 49494 (line 1339) 49495* __satfractusauta2: Fixed-point fractional library routines. 49496 (line 1347) 49497* __satfractusqda: Fixed-point fractional library routines. 49498 (line 1255) 49499* __satfractusqdq: Fixed-point fractional library routines. 49500 (line 1250) 49501* __satfractusqha: Fixed-point fractional library routines. 49502 (line 1252) 49503* __satfractusqhq: Fixed-point fractional library routines. 49504 (line 1248) 49505* __satfractusqqq: Fixed-point fractional library routines. 49506 (line 1246) 49507* __satfractusqsa: Fixed-point fractional library routines. 49508 (line 1254) 49509* __satfractusqsq: Fixed-point fractional library routines. 49510 (line 1249) 49511* __satfractusqta: Fixed-point fractional library routines. 49512 (line 1256) 49513* __satfractusquda: Fixed-point fractional library routines. 49514 (line 1268) 49515* __satfractusqudq2: Fixed-point fractional library routines. 49516 (line 1262) 49517* __satfractusquha: Fixed-point fractional library routines. 49518 (line 1264) 49519* __satfractusquhq2: Fixed-point fractional library routines. 49520 (line 1260) 49521* __satfractusquqq2: Fixed-point fractional library routines. 49522 (line 1258) 49523* __satfractusqusa: Fixed-point fractional library routines. 49524 (line 1266) 49525* __satfractusquta: Fixed-point fractional library routines. 49526 (line 1270) 49527* __satfractutada: Fixed-point fractional library routines. 49528 (line 1385) 49529* __satfractutadq: Fixed-point fractional library routines. 49530 (line 1380) 49531* __satfractutaha: Fixed-point fractional library routines. 49532 (line 1382) 49533* __satfractutahq: Fixed-point fractional library routines. 49534 (line 1377) 49535* __satfractutaqq: Fixed-point fractional library routines. 49536 (line 1375) 49537* __satfractutasa: Fixed-point fractional library routines. 49538 (line 1384) 49539* __satfractutasq: Fixed-point fractional library routines. 49540 (line 1378) 49541* __satfractutata: Fixed-point fractional library routines. 49542 (line 1387) 49543* __satfractutauda2: Fixed-point fractional library routines. 49544 (line 1401) 49545* __satfractutaudq: Fixed-point fractional library routines. 49546 (line 1395) 49547* __satfractutauha2: Fixed-point fractional library routines. 49548 (line 1397) 49549* __satfractutauhq: Fixed-point fractional library routines. 49550 (line 1391) 49551* __satfractutauqq: Fixed-point fractional library routines. 49552 (line 1389) 49553* __satfractutausa2: Fixed-point fractional library routines. 49554 (line 1399) 49555* __satfractutausq: Fixed-point fractional library routines. 49556 (line 1393) 49557* __splitstack_find: Miscellaneous routines. 49558 (line 15) 49559* __ssaddda3: Fixed-point fractional library routines. 49560 (line 74) 49561* __ssadddq3: Fixed-point fractional library routines. 49562 (line 69) 49563* __ssaddha3: Fixed-point fractional library routines. 49564 (line 71) 49565* __ssaddhq3: Fixed-point fractional library routines. 49566 (line 67) 49567* __ssaddqq3: Fixed-point fractional library routines. 49568 (line 65) 49569* __ssaddsa3: Fixed-point fractional library routines. 49570 (line 73) 49571* __ssaddsq3: Fixed-point fractional library routines. 49572 (line 68) 49573* __ssaddta3: Fixed-point fractional library routines. 49574 (line 75) 49575* __ssashlda3: Fixed-point fractional library routines. 49576 (line 409) 49577* __ssashldq3: Fixed-point fractional library routines. 49578 (line 405) 49579* __ssashlha3: Fixed-point fractional library routines. 49580 (line 407) 49581* __ssashlhq3: Fixed-point fractional library routines. 49582 (line 403) 49583* __ssashlsa3: Fixed-point fractional library routines. 49584 (line 408) 49585* __ssashlsq3: Fixed-point fractional library routines. 49586 (line 404) 49587* __ssashlta3: Fixed-point fractional library routines. 49588 (line 410) 49589* __ssdivda3: Fixed-point fractional library routines. 49590 (line 268) 49591* __ssdivdq3: Fixed-point fractional library routines. 49592 (line 263) 49593* __ssdivha3: Fixed-point fractional library routines. 49594 (line 265) 49595* __ssdivhq3: Fixed-point fractional library routines. 49596 (line 261) 49597* __ssdivqq3: Fixed-point fractional library routines. 49598 (line 259) 49599* __ssdivsa3: Fixed-point fractional library routines. 49600 (line 267) 49601* __ssdivsq3: Fixed-point fractional library routines. 49602 (line 262) 49603* __ssdivta3: Fixed-point fractional library routines. 49604 (line 269) 49605* __ssmulda3: Fixed-point fractional library routines. 49606 (line 200) 49607* __ssmuldq3: Fixed-point fractional library routines. 49608 (line 195) 49609* __ssmulha3: Fixed-point fractional library routines. 49610 (line 197) 49611* __ssmulhq3: Fixed-point fractional library routines. 49612 (line 193) 49613* __ssmulqq3: Fixed-point fractional library routines. 49614 (line 191) 49615* __ssmulsa3: Fixed-point fractional library routines. 49616 (line 199) 49617* __ssmulsq3: Fixed-point fractional library routines. 49618 (line 194) 49619* __ssmulta3: Fixed-point fractional library routines. 49620 (line 201) 49621* __ssnegda2: Fixed-point fractional library routines. 49622 (line 323) 49623* __ssnegdq2: Fixed-point fractional library routines. 49624 (line 320) 49625* __ssnegha2: Fixed-point fractional library routines. 49626 (line 321) 49627* __ssneghq2: Fixed-point fractional library routines. 49628 (line 318) 49629* __ssnegqq2: Fixed-point fractional library routines. 49630 (line 317) 49631* __ssnegsa2: Fixed-point fractional library routines. 49632 (line 322) 49633* __ssnegsq2: Fixed-point fractional library routines. 49634 (line 319) 49635* __ssnegta2: Fixed-point fractional library routines. 49636 (line 324) 49637* __sssubda3: Fixed-point fractional library routines. 49638 (line 136) 49639* __sssubdq3: Fixed-point fractional library routines. 49640 (line 131) 49641* __sssubha3: Fixed-point fractional library routines. 49642 (line 133) 49643* __sssubhq3: Fixed-point fractional library routines. 49644 (line 129) 49645* __sssubqq3: Fixed-point fractional library routines. 49646 (line 127) 49647* __sssubsa3: Fixed-point fractional library routines. 49648 (line 135) 49649* __sssubsq3: Fixed-point fractional library routines. 49650 (line 130) 49651* __sssubta3: Fixed-point fractional library routines. 49652 (line 137) 49653* __subda3: Fixed-point fractional library routines. 49654 (line 114) 49655* __subdf3: Soft float library routines. 49656 (line 30) 49657* __subdq3: Fixed-point fractional library routines. 49658 (line 101) 49659* __subha3: Fixed-point fractional library routines. 49660 (line 111) 49661* __subhq3: Fixed-point fractional library routines. 49662 (line 99) 49663* __subqq3: Fixed-point fractional library routines. 49664 (line 97) 49665* __subsa3: Fixed-point fractional library routines. 49666 (line 113) 49667* __subsf3: Soft float library routines. 49668 (line 29) 49669* __subsq3: Fixed-point fractional library routines. 49670 (line 100) 49671* __subta3: Fixed-point fractional library routines. 49672 (line 115) 49673* __subtf3: Soft float library routines. 49674 (line 31) 49675* __subuda3: Fixed-point fractional library routines. 49676 (line 121) 49677* __subudq3: Fixed-point fractional library routines. 49678 (line 109) 49679* __subuha3: Fixed-point fractional library routines. 49680 (line 117) 49681* __subuhq3: Fixed-point fractional library routines. 49682 (line 105) 49683* __subuqq3: Fixed-point fractional library routines. 49684 (line 103) 49685* __subusa3: Fixed-point fractional library routines. 49686 (line 119) 49687* __subusq3: Fixed-point fractional library routines. 49688 (line 107) 49689* __subuta3: Fixed-point fractional library routines. 49690 (line 123) 49691* __subvdi3: Integer library routines. 49692 (line 122) 49693* __subvsi3: Integer library routines. 49694 (line 121) 49695* __subxf3: Soft float library routines. 49696 (line 33) 49697* __truncdfsf2: Soft float library routines. 49698 (line 75) 49699* __trunctfdf2: Soft float library routines. 49700 (line 72) 49701* __trunctfsf2: Soft float library routines. 49702 (line 74) 49703* __truncxfdf2: Soft float library routines. 49704 (line 71) 49705* __truncxfsf2: Soft float library routines. 49706 (line 73) 49707* __ucmpdi2: Integer library routines. 49708 (line 92) 49709* __ucmpti2: Integer library routines. 49710 (line 93) 49711* __udivdi3: Integer library routines. 49712 (line 52) 49713* __udivmoddi4: Integer library routines. 49714 (line 59) 49715* __udivmodti4: Integer library routines. 49716 (line 61) 49717* __udivsi3: Integer library routines. 49718 (line 50) 49719* __udivti3: Integer library routines. 49720 (line 54) 49721* __udivuda3: Fixed-point fractional library routines. 49722 (line 252) 49723* __udivudq3: Fixed-point fractional library routines. 49724 (line 246) 49725* __udivuha3: Fixed-point fractional library routines. 49726 (line 248) 49727* __udivuhq3: Fixed-point fractional library routines. 49728 (line 242) 49729* __udivuqq3: Fixed-point fractional library routines. 49730 (line 240) 49731* __udivusa3: Fixed-point fractional library routines. 49732 (line 250) 49733* __udivusq3: Fixed-point fractional library routines. 49734 (line 244) 49735* __udivuta3: Fixed-point fractional library routines. 49736 (line 254) 49737* __umoddi3: Integer library routines. 49738 (line 69) 49739* __umodsi3: Integer library routines. 49740 (line 67) 49741* __umodti3: Integer library routines. 49742 (line 71) 49743* __unorddf2: Soft float library routines. 49744 (line 172) 49745* __unordsf2: Soft float library routines. 49746 (line 171) 49747* __unordtf2: Soft float library routines. 49748 (line 173) 49749* __usadduda3: Fixed-point fractional library routines. 49750 (line 91) 49751* __usaddudq3: Fixed-point fractional library routines. 49752 (line 85) 49753* __usadduha3: Fixed-point fractional library routines. 49754 (line 87) 49755* __usadduhq3: Fixed-point fractional library routines. 49756 (line 81) 49757* __usadduqq3: Fixed-point fractional library routines. 49758 (line 79) 49759* __usaddusa3: Fixed-point fractional library routines. 49760 (line 89) 49761* __usaddusq3: Fixed-point fractional library routines. 49762 (line 83) 49763* __usadduta3: Fixed-point fractional library routines. 49764 (line 93) 49765* __usashluda3: Fixed-point fractional library routines. 49766 (line 427) 49767* __usashludq3: Fixed-point fractional library routines. 49768 (line 421) 49769* __usashluha3: Fixed-point fractional library routines. 49770 (line 423) 49771* __usashluhq3: Fixed-point fractional library routines. 49772 (line 417) 49773* __usashluqq3: Fixed-point fractional library routines. 49774 (line 415) 49775* __usashlusa3: Fixed-point fractional library routines. 49776 (line 425) 49777* __usashlusq3: Fixed-point fractional library routines. 49778 (line 419) 49779* __usashluta3: Fixed-point fractional library routines. 49780 (line 429) 49781* __usdivuda3: Fixed-point fractional library routines. 49782 (line 286) 49783* __usdivudq3: Fixed-point fractional library routines. 49784 (line 280) 49785* __usdivuha3: Fixed-point fractional library routines. 49786 (line 282) 49787* __usdivuhq3: Fixed-point fractional library routines. 49788 (line 276) 49789* __usdivuqq3: Fixed-point fractional library routines. 49790 (line 274) 49791* __usdivusa3: Fixed-point fractional library routines. 49792 (line 284) 49793* __usdivusq3: Fixed-point fractional library routines. 49794 (line 278) 49795* __usdivuta3: Fixed-point fractional library routines. 49796 (line 288) 49797* __usmuluda3: Fixed-point fractional library routines. 49798 (line 218) 49799* __usmuludq3: Fixed-point fractional library routines. 49800 (line 212) 49801* __usmuluha3: Fixed-point fractional library routines. 49802 (line 214) 49803* __usmuluhq3: Fixed-point fractional library routines. 49804 (line 208) 49805* __usmuluqq3: Fixed-point fractional library routines. 49806 (line 206) 49807* __usmulusa3: Fixed-point fractional library routines. 49808 (line 216) 49809* __usmulusq3: Fixed-point fractional library routines. 49810 (line 210) 49811* __usmuluta3: Fixed-point fractional library routines. 49812 (line 220) 49813* __usneguda2: Fixed-point fractional library routines. 49814 (line 337) 49815* __usnegudq2: Fixed-point fractional library routines. 49816 (line 332) 49817* __usneguha2: Fixed-point fractional library routines. 49818 (line 334) 49819* __usneguhq2: Fixed-point fractional library routines. 49820 (line 329) 49821* __usneguqq2: Fixed-point fractional library routines. 49822 (line 327) 49823* __usnegusa2: Fixed-point fractional library routines. 49824 (line 336) 49825* __usnegusq2: Fixed-point fractional library routines. 49826 (line 330) 49827* __usneguta2: Fixed-point fractional library routines. 49828 (line 339) 49829* __ussubuda3: Fixed-point fractional library routines. 49830 (line 154) 49831* __ussubudq3: Fixed-point fractional library routines. 49832 (line 148) 49833* __ussubuha3: Fixed-point fractional library routines. 49834 (line 150) 49835* __ussubuhq3: Fixed-point fractional library routines. 49836 (line 144) 49837* __ussubuqq3: Fixed-point fractional library routines. 49838 (line 142) 49839* __ussubusa3: Fixed-point fractional library routines. 49840 (line 152) 49841* __ussubusq3: Fixed-point fractional library routines. 49842 (line 146) 49843* __ussubuta3: Fixed-point fractional library routines. 49844 (line 156) 49845* abort: Portability. (line 20) 49846* abs: Arithmetic. (line 200) 49847* abs and attributes: Expressions. (line 83) 49848* absence_set: Processor pipeline description. 49849 (line 223) 49850* absM2 instruction pattern: Standard Names. (line 761) 49851* absolute value: Arithmetic. (line 200) 49852* ABS_EXPR: Unary and Binary Expressions. 49853 (line 6) 49854* access to operands: Accessors. (line 6) 49855* access to special operands: Special Accessors. (line 6) 49856* accessors: Accessors. (line 6) 49857* ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 48) 49858* ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 140) 49859* ACCUM_TYPE_SIZE: Type Layout. (line 87) 49860* acosM2 instruction pattern: Standard Names. (line 848) 49861* ADA_LONG_TYPE_SIZE: Type Layout. (line 25) 49862* Adding a new GIMPLE statement code: Adding a new GIMPLE statement code. 49863 (line 6) 49864* ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 14) 49865* addM3 instruction pattern: Standard Names. (line 410) 49866* addMODEcc instruction pattern: Standard Names. (line 1425) 49867* addptrM3 instruction pattern: Standard Names. (line 443) 49868* address constraints: Simple Constraints. (line 162) 49869* addressing modes: Addressing Modes. (line 6) 49870* address_operand: Machine-Independent Predicates. 49871 (line 62) 49872* address_operand <1>: Simple Constraints. (line 166) 49873* addr_diff_vec: Side Effects. (line 314) 49874* addr_diff_vec, length of: Insn Lengths. (line 26) 49875* ADDR_EXPR: Storage References. (line 6) 49876* addr_vec: Side Effects. (line 309) 49877* addr_vec, length of: Insn Lengths. (line 26) 49878* addvM4 instruction pattern: Standard Names. (line 426) 49879* ADJUST_FIELD_ALIGN: Storage Layout. (line 212) 49880* ADJUST_INSN_LENGTH: Insn Lengths. (line 41) 49881* ADJUST_REG_ALLOC_ORDER: Allocation Order. (line 22) 49882* aggregates as return values: Aggregate Return. (line 6) 49883* alias: Alias analysis. (line 6) 49884* allocate_stack instruction pattern: Standard Names. (line 1778) 49885* ALL_REGS: Register Classes. (line 17) 49886* alternate entry points: Insns. (line 146) 49887* anchored addresses: Anchored Addresses. (line 6) 49888* and: Arithmetic. (line 158) 49889* and and attributes: Expressions. (line 50) 49890* and, canonicalization of: Insn Canonicalizations. 49891 (line 67) 49892* andM3 instruction pattern: Standard Names. (line 416) 49893* ANNOTATE_EXPR: Unary and Binary Expressions. 49894 (line 6) 49895* annotations: Annotations. (line 6) 49896* APPLY_RESULT_SIZE: Scalar Return. (line 112) 49897* ARGS_GROW_DOWNWARD: Frame Layout. (line 30) 49898* argument passing: Interface. (line 36) 49899* arguments in registers: Register Arguments. (line 6) 49900* arguments on stack: Stack Arguments. (line 6) 49901* ARG_POINTER_CFA_OFFSET: Frame Layout. (line 207) 49902* ARG_POINTER_REGNUM: Frame Registers. (line 40) 49903* ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65) 49904* arg_pointer_rtx: Frame Registers. (line 104) 49905* arithmetic library: Soft float library routines. 49906 (line 6) 49907* arithmetic shift: Arithmetic. (line 173) 49908* arithmetic shift with signed saturation: Arithmetic. (line 173) 49909* arithmetic shift with unsigned saturation: Arithmetic. (line 173) 49910* arithmetic, in RTL: Arithmetic. (line 6) 49911* ARITHMETIC_TYPE_P: Types for C++. (line 59) 49912* array: Types. (line 6) 49913* ARRAY_RANGE_REF: Storage References. (line 6) 49914* ARRAY_REF: Storage References. (line 6) 49915* ARRAY_TYPE: Types. (line 6) 49916* ashift: Arithmetic. (line 173) 49917* ashift and attributes: Expressions. (line 83) 49918* ashiftrt: Arithmetic. (line 190) 49919* ashiftrt and attributes: Expressions. (line 83) 49920* ashlM3 instruction pattern: Standard Names. (line 730) 49921* ashrM3 instruction pattern: Standard Names. (line 742) 49922* asinM2 instruction pattern: Standard Names. (line 842) 49923* ASM_APP_OFF: File Framework. (line 76) 49924* ASM_APP_ON: File Framework. (line 69) 49925* ASM_COMMENT_START: File Framework. (line 64) 49926* ASM_DECLARE_COLD_FUNCTION_NAME: Label Output. (line 136) 49927* ASM_DECLARE_COLD_FUNCTION_SIZE: Label Output. (line 151) 49928* ASM_DECLARE_FUNCTION_NAME: Label Output. (line 108) 49929* ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 123) 49930* ASM_DECLARE_OBJECT_NAME: Label Output. (line 164) 49931* ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 192) 49932* ASM_FINAL_SPEC: Driver. (line 81) 49933* ASM_FINISH_DECLARE_OBJECT: Label Output. (line 200) 49934* ASM_FORMAT_PRIVATE_NAME: Label Output. (line 426) 49935* asm_fprintf: Instruction Output. (line 150) 49936* ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 160) 49937* ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 410) 49938* asm_input: Side Effects. (line 296) 49939* asm_input and /v: Flags. (line 65) 49940* ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 80) 49941* asm_noperands: Insns. (line 327) 49942* ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 78) 49943* asm_operands and /v: Flags. (line 65) 49944* asm_operands, RTL sharing: Sharing. (line 48) 49945* asm_operands, usage: Assembler. (line 6) 49946* ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 8) 49947* ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 25) 49948* ASM_OUTPUT_ALIGN: Alignment Output. (line 85) 49949* ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 45) 49950* ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 29) 49951* ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 36) 49952* ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 89) 49953* ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 82) 49954* ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 90) 49955* ASM_OUTPUT_ASCII: Data Output. (line 54) 49956* ASM_OUTPUT_CASE_END: Dispatch Tables. (line 50) 49957* ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 37) 49958* ASM_OUTPUT_COMMON: Uninitialized Data. (line 9) 49959* ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 398) 49960* ASM_OUTPUT_DEF: Label Output. (line 447) 49961* ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 454) 49962* ASM_OUTPUT_DWARF_DATAREL: DWARF. (line 110) 49963* ASM_OUTPUT_DWARF_DELTA: DWARF. (line 89) 49964* ASM_OUTPUT_DWARF_OFFSET: DWARF. (line 98) 49965* ASM_OUTPUT_DWARF_PCREL: DWARF. (line 105) 49966* ASM_OUTPUT_DWARF_TABLE_REF: DWARF. (line 115) 49967* ASM_OUTPUT_DWARF_VMS_DELTA: DWARF. (line 93) 49968* ASM_OUTPUT_EXTERNAL: Label Output. (line 327) 49969* ASM_OUTPUT_FDESC: Data Output. (line 63) 49970* ASM_OUTPUT_FUNCTION_LABEL: Label Output. (line 16) 49971* ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 27) 49972* ASM_OUTPUT_LABEL: Label Output. (line 8) 49973* ASM_OUTPUT_LABELREF: Label Output. (line 349) 49974* ASM_OUTPUT_LABEL_REF: Label Output. (line 371) 49975* ASM_OUTPUT_LOCAL: Uninitialized Data. (line 69) 49976* ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 94) 49977* ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 51) 49978* ASM_OUTPUT_OPCODE: Instruction Output. (line 35) 49979* ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 112) 49980* ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 76) 49981* ASM_OUTPUT_REG_POP: Instruction Output. (line 206) 49982* ASM_OUTPUT_REG_PUSH: Instruction Output. (line 201) 49983* ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 45) 49984* ASM_OUTPUT_SKIP: Alignment Output. (line 72) 49985* ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 83) 49986* ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 87) 49987* ASM_OUTPUT_SYMBOL_REF: Label Output. (line 364) 49988* ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 98) 49989* ASM_OUTPUT_WEAKREF: Label Output. (line 259) 49990* ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 473) 49991* ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 66) 49992* ASM_SPEC: Driver. (line 73) 49993* ASM_STABD_OP: DBX Options. (line 34) 49994* ASM_STABN_OP: DBX Options. (line 41) 49995* ASM_STABS_OP: DBX Options. (line 28) 49996* ASM_WEAKEN_DECL: Label Output. (line 251) 49997* ASM_WEAKEN_LABEL: Label Output. (line 238) 49998* assembler format: File Framework. (line 6) 49999* assembler instructions in RTL: Assembler. (line 6) 50000* ASSEMBLER_DIALECT: Instruction Output. (line 172) 50001* assemble_name: Label Output. (line 8) 50002* assemble_name_raw: Label Output. (line 27) 50003* assigning attribute values to insns: Tagging Insns. (line 6) 50004* ASSUME_EXTENDED_UNWIND_CONTEXT: Frame Registers. (line 163) 50005* asterisk in template: Output Statement. (line 29) 50006* AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 88) 50007* atan2M3 instruction pattern: Standard Names. (line 943) 50008* atanM2 instruction pattern: Standard Names. (line 854) 50009* atomic: GTY Options. (line 197) 50010* atomic_addMODE instruction pattern: Standard Names. (line 2188) 50011* atomic_add_fetchMODE instruction pattern: Standard Names. (line 2217) 50012* atomic_andMODE instruction pattern: Standard Names. (line 2188) 50013* atomic_and_fetchMODE instruction pattern: Standard Names. (line 2217) 50014* atomic_bit_test_and_complementMODE instruction pattern: Standard Names. 50015 (line 2245) 50016* atomic_bit_test_and_resetMODE instruction pattern: Standard Names. 50017 (line 2245) 50018* atomic_bit_test_and_setMODE instruction pattern: Standard Names. 50019 (line 2245) 50020* atomic_compare_and_swapMODE instruction pattern: Standard Names. 50021 (line 2124) 50022* atomic_exchangeMODE instruction pattern: Standard Names. (line 2176) 50023* atomic_fetch_addMODE instruction pattern: Standard Names. (line 2202) 50024* atomic_fetch_andMODE instruction pattern: Standard Names. (line 2202) 50025* atomic_fetch_nandMODE instruction pattern: Standard Names. (line 2202) 50026* atomic_fetch_orMODE instruction pattern: Standard Names. (line 2202) 50027* atomic_fetch_subMODE instruction pattern: Standard Names. (line 2202) 50028* atomic_fetch_xorMODE instruction pattern: Standard Names. (line 2202) 50029* atomic_loadMODE instruction pattern: Standard Names. (line 2155) 50030* atomic_nandMODE instruction pattern: Standard Names. (line 2188) 50031* atomic_nand_fetchMODE instruction pattern: Standard Names. (line 2217) 50032* atomic_orMODE instruction pattern: Standard Names. (line 2188) 50033* atomic_or_fetchMODE instruction pattern: Standard Names. (line 2217) 50034* atomic_storeMODE instruction pattern: Standard Names. (line 2165) 50035* atomic_subMODE instruction pattern: Standard Names. (line 2188) 50036* atomic_sub_fetchMODE instruction pattern: Standard Names. (line 2217) 50037* atomic_test_and_set instruction pattern: Standard Names. (line 2234) 50038* atomic_xorMODE instruction pattern: Standard Names. (line 2188) 50039* atomic_xor_fetchMODE instruction pattern: Standard Names. (line 2217) 50040* attr: Expressions. (line 163) 50041* attr <1>: Tagging Insns. (line 54) 50042* attribute expressions: Expressions. (line 6) 50043* attribute specifications: Attr Example. (line 6) 50044* attribute specifications example: Attr Example. (line 6) 50045* attributes: Attributes. (line 6) 50046* attributes, defining: Defining Attributes. 50047 (line 6) 50048* attributes, target-specific: Target Attributes. (line 6) 50049* ATTRIBUTE_ALIGNED_VALUE: Storage Layout. (line 194) 50050* attr_flag: Expressions. (line 138) 50051* autoincrement addressing, availability: Portability. (line 20) 50052* autoincrement/decrement addressing: Simple Constraints. (line 30) 50053* automata_option: Processor pipeline description. 50054 (line 304) 50055* automaton based pipeline description: Processor pipeline description. 50056 (line 6) 50057* automaton based pipeline description <1>: Processor pipeline description. 50058 (line 49) 50059* automaton based scheduler: Processor pipeline description. 50060 (line 6) 50061* AVOID_CCMODE_COPIES: Values in Registers. 50062 (line 148) 50063* backslash: Output Template. (line 46) 50064* barrier: Insns. (line 176) 50065* barrier and /f: Flags. (line 135) 50066* barrier and /v: Flags. (line 33) 50067* BASE_REG_CLASS: Register Classes. (line 111) 50068* basic block: Basic Blocks. (line 6) 50069* Basic Statements: Basic Statements. (line 6) 50070* basic-block.h: Control Flow. (line 6) 50071* basic_block: Basic Blocks. (line 6) 50072* BASIC_BLOCK: Basic Blocks. (line 14) 50073* BB_HEAD, BB_END: Maintaining the CFG. 50074 (line 76) 50075* bb_seq: GIMPLE sequences. (line 72) 50076* BIGGEST_ALIGNMENT: Storage Layout. (line 179) 50077* BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 205) 50078* BImode: Machine Modes. (line 22) 50079* BIND_EXPR: Unary and Binary Expressions. 50080 (line 6) 50081* BINFO_TYPE: Classes. (line 6) 50082* bit-fields: Bit-Fields. (line 6) 50083* BITFIELD_NBYTES_LIMITED: Storage Layout. (line 425) 50084* BITS_BIG_ENDIAN: Storage Layout. (line 11) 50085* BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8) 50086* BITS_PER_UNIT: Machine Modes. (line 444) 50087* BITS_PER_WORD: Storage Layout. (line 50) 50088* bitwise complement: Arithmetic. (line 154) 50089* bitwise exclusive-or: Arithmetic. (line 168) 50090* bitwise inclusive-or: Arithmetic. (line 163) 50091* bitwise logical-and: Arithmetic. (line 158) 50092* BIT_AND_EXPR: Unary and Binary Expressions. 50093 (line 6) 50094* BIT_IOR_EXPR: Unary and Binary Expressions. 50095 (line 6) 50096* BIT_NOT_EXPR: Unary and Binary Expressions. 50097 (line 6) 50098* BIT_XOR_EXPR: Unary and Binary Expressions. 50099 (line 6) 50100* BLKmode: Machine Modes. (line 185) 50101* BLKmode, and function return values: Calls. (line 23) 50102* blockage instruction pattern: Standard Names. (line 1978) 50103* Blocks: Blocks. (line 6) 50104* BLOCK_FOR_INSN, gimple_bb: Maintaining the CFG. 50105 (line 28) 50106* BLOCK_REG_PADDING: Register Arguments. (line 246) 50107* BND32mode: Machine Modes. (line 210) 50108* BND64mode: Machine Modes. (line 210) 50109* bool: Misc. (line 1017) 50110* BOOLEAN_TYPE: Types. (line 6) 50111* BOOL_TYPE_SIZE: Type Layout. (line 43) 50112* branch prediction: Profile information. 50113 (line 24) 50114* BRANCH_COST: Costs. (line 104) 50115* break_out_memory_refs: Addressing Modes. (line 134) 50116* BREAK_STMT: Statements for C++. (line 6) 50117* BSS_SECTION_ASM_OP: Sections. (line 67) 50118* bswap: Arithmetic. (line 246) 50119* bswapM2 instruction pattern: Standard Names. (line 750) 50120* btruncM2 instruction pattern: Standard Names. (line 960) 50121* build0: Macros and Functions. 50122 (line 16) 50123* build1: Macros and Functions. 50124 (line 17) 50125* build2: Macros and Functions. 50126 (line 18) 50127* build3: Macros and Functions. 50128 (line 19) 50129* build4: Macros and Functions. 50130 (line 20) 50131* build5: Macros and Functions. 50132 (line 21) 50133* build6: Macros and Functions. 50134 (line 22) 50135* builtin_longjmp instruction pattern: Standard Names. (line 1876) 50136* builtin_setjmp_receiver instruction pattern: Standard Names. 50137 (line 1866) 50138* builtin_setjmp_setup instruction pattern: Standard Names. (line 1855) 50139* BYTES_BIG_ENDIAN: Storage Layout. (line 23) 50140* BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 229) 50141* byte_mode: Machine Modes. (line 462) 50142* C statements for assembler output: Output Statement. (line 6) 50143* cache: GTY Options. (line 127) 50144* call: Flags. (line 230) 50145* call <1>: Side Effects. (line 92) 50146* call instruction pattern: Standard Names. (line 1521) 50147* call usage: Calls. (line 10) 50148* call, in call_insn: Flags. (line 129) 50149* call, in mem: Flags. (line 70) 50150* call-clobbered register: Register Basics. (line 35) 50151* call-clobbered register <1>: Register Basics. (line 46) 50152* call-clobbered register <2>: Register Basics. (line 52) 50153* call-saved register: Register Basics. (line 35) 50154* call-saved register <1>: Register Basics. (line 46) 50155* call-saved register <2>: Register Basics. (line 52) 50156* call-used register: Register Basics. (line 35) 50157* call-used register <1>: Register Basics. (line 46) 50158* call-used register <2>: Register Basics. (line 52) 50159* calling conventions: Stack and Calling. (line 6) 50160* calling functions in RTL: Calls. (line 6) 50161* CALL_EXPR: Unary and Binary Expressions. 50162 (line 6) 50163* call_insn: Insns. (line 95) 50164* call_insn and /c: Flags. (line 129) 50165* call_insn and /f: Flags. (line 135) 50166* call_insn and /i: Flags. (line 120) 50167* call_insn and /j: Flags. (line 175) 50168* call_insn and /s: Flags. (line 38) 50169* call_insn and /s <1>: Flags. (line 162) 50170* call_insn and /u: Flags. (line 28) 50171* call_insn and /u <1>: Flags. (line 115) 50172* call_insn and /u or /i: Flags. (line 125) 50173* call_insn and /v: Flags. (line 33) 50174* CALL_INSN_FUNCTION_USAGE: Insns. (line 101) 50175* call_pop instruction pattern: Standard Names. (line 1549) 50176* CALL_POPS_ARGS: Stack Arguments. (line 138) 50177* CALL_REALLY_USED_REGISTERS: Register Basics. (line 45) 50178* CALL_USED_REGISTERS: Register Basics. (line 34) 50179* call_used_regs: Register Basics. (line 63) 50180* call_value instruction pattern: Standard Names. (line 1541) 50181* call_value_pop instruction pattern: Standard Names. (line 1549) 50182* canadian: Configure Terms. (line 6) 50183* canonicalization of instructions: Insn Canonicalizations. 50184 (line 6) 50185* canonicalize_funcptr_for_compare instruction pattern: Standard Names. 50186 (line 1710) 50187* can_create_pseudo_p: Standard Names. (line 75) 50188* can_fallthru: Basic Blocks. (line 67) 50189* caret: Multi-Alternative. (line 53) 50190* casesi instruction pattern: Standard Names. (line 1642) 50191* CASE_VECTOR_MODE: Misc. (line 26) 50192* CASE_VECTOR_PC_RELATIVE: Misc. (line 39) 50193* CASE_VECTOR_SHORTEN_MODE: Misc. (line 30) 50194* cbranchMODE4 instruction pattern: Standard Names. (line 1510) 50195* cc0: Regs and Memory. (line 329) 50196* cc0 <1>: CC0 Condition Codes. 50197 (line 6) 50198* cc0, RTL sharing: Sharing. (line 30) 50199* cc0_rtx: Regs and Memory. (line 355) 50200* CC1PLUS_SPEC: Driver. (line 63) 50201* CC1_SPEC: Driver. (line 55) 50202* CCmode: Machine Modes. (line 178) 50203* CCmode <1>: MODE_CC Condition Codes. 50204 (line 6) 50205* cc_status: CC0 Condition Codes. 50206 (line 6) 50207* CC_STATUS_MDEP: CC0 Condition Codes. 50208 (line 16) 50209* CC_STATUS_MDEP_INIT: CC0 Condition Codes. 50210 (line 22) 50211* CDImode: Machine Modes. (line 204) 50212* ceilM2 instruction pattern: Standard Names. (line 979) 50213* CEIL_DIV_EXPR: Unary and Binary Expressions. 50214 (line 6) 50215* CEIL_MOD_EXPR: Unary and Binary Expressions. 50216 (line 6) 50217* CFA_FRAME_BASE_OFFSET: Frame Layout. (line 239) 50218* CFG verification: Maintaining the CFG. 50219 (line 116) 50220* CFG, Control Flow Graph: Control Flow. (line 6) 50221* cfghooks.h: Maintaining the CFG. 50222 (line 6) 50223* cgraph_finalize_function: Parsing pass. (line 51) 50224* chain_circular: GTY Options. (line 160) 50225* chain_next: GTY Options. (line 160) 50226* chain_prev: GTY Options. (line 160) 50227* change_address: Standard Names. (line 47) 50228* CHAR_TYPE_SIZE: Type Layout. (line 38) 50229* check_stack instruction pattern: Standard Names. (line 1796) 50230* CHImode: Machine Modes. (line 204) 50231* class definitions, register: Register Classes. (line 6) 50232* class preference constraints: Class Preferences. (line 6) 50233* class, scope: Classes. (line 6) 50234* classes of RTX codes: RTL Classes. (line 6) 50235* CLASSTYPE_DECLARED_CLASS: Classes. (line 6) 50236* CLASSTYPE_HAS_MUTABLE: Classes. (line 82) 50237* CLASSTYPE_NON_POD_P: Classes. (line 87) 50238* CLASS_MAX_NREGS: Register Classes. (line 531) 50239* CLASS_TYPE_P: Types for C++. (line 63) 50240* Cleanups: Cleanups. (line 6) 50241* CLEANUP_DECL: Statements for C++. (line 6) 50242* CLEANUP_EXPR: Statements for C++. (line 6) 50243* CLEANUP_POINT_EXPR: Unary and Binary Expressions. 50244 (line 6) 50245* CLEANUP_STMT: Statements for C++. (line 6) 50246* clear_cache instruction pattern: Standard Names. (line 2314) 50247* CLEAR_INSN_CACHE: Trampolines. (line 117) 50248* CLEAR_RATIO: Costs. (line 225) 50249* clobber: Side Effects. (line 106) 50250* clrsb: Arithmetic. (line 215) 50251* clrsbM2 instruction pattern: Standard Names. (line 1044) 50252* clz: Arithmetic. (line 222) 50253* clzM2 instruction pattern: Standard Names. (line 1060) 50254* CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 326) 50255* cmpmemM instruction pattern: Standard Names. (line 1225) 50256* cmpstrM instruction pattern: Standard Names. (line 1204) 50257* cmpstrnM instruction pattern: Standard Names. (line 1191) 50258* code generation RTL sequences: Expander Definitions. 50259 (line 6) 50260* code iterators in .md files: Code Iterators. (line 6) 50261* codes, RTL expression: RTL Objects. (line 47) 50262* code_label: Insns. (line 125) 50263* CODE_LABEL: Basic Blocks. (line 50) 50264* code_label and /i: Flags. (line 48) 50265* code_label and /v: Flags. (line 33) 50266* CODE_LABEL_NUMBER: Insns. (line 125) 50267* COImode: Machine Modes. (line 204) 50268* COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32) 50269* COLLECT_EXPORT_LIST: Misc. (line 889) 50270* COLLECT_SHARED_FINI_FUNC: Macros for Initialization. 50271 (line 43) 50272* COLLECT_SHARED_INIT_FUNC: Macros for Initialization. 50273 (line 32) 50274* commit_edge_insertions: Maintaining the CFG. 50275 (line 104) 50276* compare: Arithmetic. (line 46) 50277* compare, canonicalization of: Insn Canonicalizations. 50278 (line 36) 50279* COMPARE_MAX_PIECES: Costs. (line 220) 50280* comparison_operator: Machine-Independent Predicates. 50281 (line 110) 50282* compiler passes and files: Passes. (line 6) 50283* complement, bitwise: Arithmetic. (line 154) 50284* COMPLEX_CST: Constant expressions. 50285 (line 6) 50286* COMPLEX_EXPR: Unary and Binary Expressions. 50287 (line 6) 50288* complex_mode: Machine Modes. (line 306) 50289* COMPLEX_TYPE: Types. (line 6) 50290* COMPONENT_REF: Storage References. (line 6) 50291* Compound Expressions: Compound Expressions. 50292 (line 6) 50293* Compound Lvalues: Compound Lvalues. (line 6) 50294* COMPOUND_EXPR: Unary and Binary Expressions. 50295 (line 6) 50296* COMPOUND_LITERAL_EXPR: Unary and Binary Expressions. 50297 (line 6) 50298* COMPOUND_LITERAL_EXPR_DECL: Unary and Binary Expressions. 50299 (line 387) 50300* COMPOUND_LITERAL_EXPR_DECL_EXPR: Unary and Binary Expressions. 50301 (line 387) 50302* computed jump: Edges. (line 127) 50303* computing the length of an insn: Insn Lengths. (line 6) 50304* concat: Regs and Memory. (line 407) 50305* concatn: Regs and Memory. (line 413) 50306* cond: Comparisons. (line 90) 50307* cond and attributes: Expressions. (line 37) 50308* condition code register: Regs and Memory. (line 329) 50309* condition code status: Condition Code. (line 6) 50310* condition codes: Comparisons. (line 20) 50311* conditional execution: Conditional Execution. 50312 (line 6) 50313* Conditional Expressions: Conditional Expressions. 50314 (line 6) 50315* conditions, in patterns: Patterns. (line 43) 50316* cond_addMODE instruction pattern: Standard Names. (line 1432) 50317* cond_andMODE instruction pattern: Standard Names. (line 1432) 50318* cond_exec: Side Effects. (line 254) 50319* COND_EXPR: Unary and Binary Expressions. 50320 (line 6) 50321* cond_iorMODE instruction pattern: Standard Names. (line 1432) 50322* cond_smaxMODE instruction pattern: Standard Names. (line 1432) 50323* cond_sminMODE instruction pattern: Standard Names. (line 1432) 50324* cond_subMODE instruction pattern: Standard Names. (line 1432) 50325* cond_umaxMODE instruction pattern: Standard Names. (line 1432) 50326* cond_uminMODE instruction pattern: Standard Names. (line 1432) 50327* cond_xorMODE instruction pattern: Standard Names. (line 1432) 50328* configuration file: Filesystem. (line 6) 50329* configuration file <1>: Host Misc. (line 6) 50330* configure terms: Configure Terms. (line 6) 50331* CONJ_EXPR: Unary and Binary Expressions. 50332 (line 6) 50333* const: Constants. (line 212) 50334* const0_rtx: Constants. (line 21) 50335* CONST0_RTX: Constants. (line 230) 50336* const1_rtx: Constants. (line 21) 50337* CONST1_RTX: Constants. (line 230) 50338* const2_rtx: Constants. (line 21) 50339* CONST2_RTX: Constants. (line 230) 50340* constant attributes: Constant Attributes. 50341 (line 6) 50342* constant definitions: Constant Definitions. 50343 (line 6) 50344* constants in constraints: Simple Constraints. (line 68) 50345* CONSTANT_ADDRESS_P: Addressing Modes. (line 28) 50346* CONSTANT_P: Addressing Modes. (line 35) 50347* CONSTANT_POOL_ADDRESS_P: Flags. (line 19) 50348* CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 68) 50349* constm1_rtx: Constants. (line 21) 50350* constraint modifier characters: Modifiers. (line 6) 50351* constraint, matching: Simple Constraints. (line 140) 50352* constraints: Constraints. (line 6) 50353* constraints, defining: Define Constraints. (line 6) 50354* constraints, machine specific: Machine Constraints. 50355 (line 6) 50356* constraints, testing: C Constraint Interface. 50357 (line 6) 50358* constraint_num: C Constraint Interface. 50359 (line 30) 50360* constraint_satisfied_p: C Constraint Interface. 50361 (line 42) 50362* CONSTRUCTOR: Unary and Binary Expressions. 50363 (line 6) 50364* constructors, automatic calls: Collect2. (line 15) 50365* constructors, output of: Initialization. (line 6) 50366* CONST_DECL: Declarations. (line 6) 50367* const_double: Constants. (line 37) 50368* const_double, RTL sharing: Sharing. (line 32) 50369* CONST_DOUBLE_LOW: Constants. (line 54) 50370* const_double_operand: Machine-Independent Predicates. 50371 (line 20) 50372* const_fixed: Constants. (line 93) 50373* const_int: Constants. (line 8) 50374* const_int and attribute tests: Expressions. (line 47) 50375* const_int and attributes: Expressions. (line 10) 50376* const_int, RTL sharing: Sharing. (line 23) 50377* const_int_operand: Machine-Independent Predicates. 50378 (line 15) 50379* const_poly_int: Constants. (line 100) 50380* const_poly_int, RTL sharing: Sharing. (line 25) 50381* const_string: Constants. (line 184) 50382* const_string and attributes: Expressions. (line 20) 50383* const_true_rtx: Constants. (line 31) 50384* const_vector: Constants. (line 107) 50385* const_vector, RTL sharing: Sharing. (line 35) 50386* CONST_WIDE_INT: Constants. (line 67) 50387* CONST_WIDE_INT_ELT: Constants. (line 89) 50388* CONST_WIDE_INT_NUNITS: Constants. (line 84) 50389* CONST_WIDE_INT_VEC: Constants. (line 80) 50390* container: Containers. (line 6) 50391* CONTINUE_STMT: Statements for C++. (line 6) 50392* contributors: Contributors. (line 6) 50393* controlling register usage: Register Basics. (line 77) 50394* controlling the compilation driver: Driver. (line 6) 50395* conventions, run-time: Interface. (line 6) 50396* conversions: Conversions. (line 6) 50397* CONVERT_EXPR: Unary and Binary Expressions. 50398 (line 6) 50399* copysignM3 instruction pattern: Standard Names. (line 1024) 50400* copy_rtx: Addressing Modes. (line 189) 50401* copy_rtx_if_shared: Sharing. (line 67) 50402* cosM2 instruction pattern: Standard Names. (line 813) 50403* costs of instructions: Costs. (line 6) 50404* CPLUSPLUS_CPP_SPEC: Driver. (line 50) 50405* CPP_SPEC: Driver. (line 43) 50406* CPSImode: Machine Modes. (line 204) 50407* CP_INTEGRAL_TYPE: Types for C++. (line 55) 50408* cp_namespace_decls: Namespaces. (line 49) 50409* CP_TYPE_CONST_NON_VOLATILE_P: Types for C++. (line 33) 50410* CP_TYPE_CONST_P: Types for C++. (line 24) 50411* cp_type_quals: Types for C++. (line 6) 50412* cp_type_quals <1>: Types for C++. (line 16) 50413* CP_TYPE_RESTRICT_P: Types for C++. (line 30) 50414* CP_TYPE_VOLATILE_P: Types for C++. (line 27) 50415* CQImode: Machine Modes. (line 204) 50416* cross compilation and floating point: Floating Point. (line 6) 50417* CROSSING_JUMP_P: Flags. (line 10) 50418* crtl->args.pops_args: Function Entry. (line 111) 50419* crtl->args.pretend_args_size: Function Entry. (line 117) 50420* crtl->outgoing_args_size: Stack Arguments. (line 48) 50421* CRTSTUFF_T_CFLAGS: Target Fragment. (line 15) 50422* CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 19) 50423* CRT_CALL_STATIC_FUNCTION: Sections. (line 125) 50424* CSImode: Machine Modes. (line 204) 50425* cstoreMODE4 instruction pattern: Standard Names. (line 1471) 50426* CTImode: Machine Modes. (line 204) 50427* ctrapMM4 instruction pattern: Standard Names. (line 1947) 50428* ctz: Arithmetic. (line 230) 50429* ctzM2 instruction pattern: Standard Names. (line 1075) 50430* CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 327) 50431* CUMULATIVE_ARGS: Register Arguments. (line 144) 50432* current_function_is_leaf: Leaf Functions. (line 50) 50433* current_function_uses_only_leaf_regs: Leaf Functions. (line 50) 50434* current_insn_predicate: Conditional Execution. 50435 (line 27) 50436* C_COMMON_OVERRIDE_OPTIONS: Run-time Target. (line 136) 50437* c_register_pragma: Misc. (line 429) 50438* c_register_pragma_with_expansion: Misc. (line 431) 50439* DAmode: Machine Modes. (line 154) 50440* data bypass: Processor pipeline description. 50441 (line 105) 50442* data bypass <1>: Processor pipeline description. 50443 (line 196) 50444* data dependence delays: Processor pipeline description. 50445 (line 6) 50446* Data Dependency Analysis: Dependency analysis. 50447 (line 6) 50448* data structures: Per-Function Data. (line 6) 50449* DATA_ABI_ALIGNMENT: Storage Layout. (line 260) 50450* DATA_ALIGNMENT: Storage Layout. (line 247) 50451* DATA_SECTION_ASM_OP: Sections. (line 52) 50452* DBR_OUTPUT_SEQEND: Instruction Output. (line 133) 50453* dbr_sequence_length: Instruction Output. (line 133) 50454* DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 100) 50455* DBX_CONTIN_CHAR: DBX Options. (line 63) 50456* DBX_CONTIN_LENGTH: DBX Options. (line 53) 50457* DBX_DEBUGGING_INFO: DBX Options. (line 8) 50458* DBX_FUNCTION_FIRST: DBX Options. (line 94) 50459* DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 106) 50460* DBX_NO_XREFS: DBX Options. (line 47) 50461* DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 8) 50462* DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 33) 50463* DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX. 50464 (line 41) 50465* DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 8) 50466* DBX_REGISTER_NUMBER: All Debuggers. (line 8) 50467* DBX_REGPARM_STABS_CODE: DBX Options. (line 84) 50468* DBX_REGPARM_STABS_LETTER: DBX Options. (line 89) 50469* DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 79) 50470* DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 70) 50471* DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 75) 50472* DBX_USE_BINCL: DBX Options. (line 112) 50473* DCmode: Machine Modes. (line 199) 50474* DDmode: Machine Modes. (line 93) 50475* De Morgan's law: Insn Canonicalizations. 50476 (line 67) 50477* dead_or_set_p: define_peephole. (line 65) 50478* DEBUGGER_ARG_OFFSET: All Debuggers. (line 35) 50479* DEBUGGER_AUTO_OFFSET: All Debuggers. (line 27) 50480* debug_expr: Debug Information. (line 22) 50481* DEBUG_EXPR_DECL: Declarations. (line 6) 50482* debug_implicit_ptr: Debug Information. (line 27) 50483* debug_insn: Insns. (line 247) 50484* debug_marker: Debug Information. (line 37) 50485* debug_parameter_ref: Debug Information. (line 34) 50486* DEBUG_SYMS_TEXT: DBX Options. (line 24) 50487* decimal float library: Decimal float library routines. 50488 (line 6) 50489* declaration: Declarations. (line 6) 50490* declarations, RTL: RTL Declarations. (line 6) 50491* DECLARE_LIBRARY_RENAMES: Library Calls. (line 8) 50492* DECL_ALIGN: Declarations. (line 6) 50493* DECL_ANTICIPATED: Functions for C++. (line 42) 50494* DECL_ARGUMENTS: Function Basics. (line 36) 50495* DECL_ARRAY_DELETE_OPERATOR_P: Functions for C++. (line 158) 50496* DECL_ARTIFICIAL: Working with declarations. 50497 (line 24) 50498* DECL_ARTIFICIAL <1>: Function Basics. (line 6) 50499* DECL_ARTIFICIAL <2>: Function Properties. 50500 (line 47) 50501* DECL_ASSEMBLER_NAME: Function Basics. (line 6) 50502* DECL_ASSEMBLER_NAME <1>: Function Basics. (line 19) 50503* DECL_ATTRIBUTES: Attributes. (line 21) 50504* DECL_BASE_CONSTRUCTOR_P: Functions for C++. (line 88) 50505* DECL_COMPLETE_CONSTRUCTOR_P: Functions for C++. (line 84) 50506* DECL_COMPLETE_DESTRUCTOR_P: Functions for C++. (line 98) 50507* DECL_CONSTRUCTOR_P: Functions for C++. (line 77) 50508* DECL_CONST_MEMFUNC_P: Functions for C++. (line 71) 50509* DECL_CONTEXT: Namespaces. (line 31) 50510* DECL_CONV_FN_P: Functions for C++. (line 105) 50511* DECL_COPY_CONSTRUCTOR_P: Functions for C++. (line 92) 50512* DECL_DESTRUCTOR_P: Functions for C++. (line 95) 50513* DECL_EXTERNAL: Declarations. (line 6) 50514* DECL_EXTERNAL <1>: Function Properties. 50515 (line 25) 50516* DECL_EXTERN_C_FUNCTION_P: Functions for C++. (line 46) 50517* DECL_FUNCTION_MEMBER_P: Functions for C++. (line 61) 50518* DECL_FUNCTION_SPECIFIC_OPTIMIZATION: Function Basics. (line 6) 50519* DECL_FUNCTION_SPECIFIC_OPTIMIZATION <1>: Function Properties. 50520 (line 61) 50521* DECL_FUNCTION_SPECIFIC_TARGET: Function Basics. (line 6) 50522* DECL_FUNCTION_SPECIFIC_TARGET <1>: Function Properties. 50523 (line 55) 50524* DECL_GLOBAL_CTOR_P: Functions for C++. (line 108) 50525* DECL_GLOBAL_DTOR_P: Functions for C++. (line 112) 50526* DECL_INITIAL: Declarations. (line 6) 50527* DECL_INITIAL <1>: Function Basics. (line 51) 50528* DECL_LINKONCE_P: Functions for C++. (line 50) 50529* DECL_LOCAL_FUNCTION_P: Functions for C++. (line 38) 50530* DECL_MAIN_P: Functions for C++. (line 34) 50531* DECL_NAME: Working with declarations. 50532 (line 7) 50533* DECL_NAME <1>: Function Basics. (line 6) 50534* DECL_NAME <2>: Function Basics. (line 9) 50535* DECL_NAME <3>: Namespaces. (line 20) 50536* DECL_NAMESPACE_ALIAS: Namespaces. (line 35) 50537* DECL_NAMESPACE_STD_P: Namespaces. (line 45) 50538* DECL_NONCONVERTING_P: Functions for C++. (line 80) 50539* DECL_NONSTATIC_MEMBER_FUNCTION_P: Functions for C++. (line 68) 50540* DECL_NON_THUNK_FUNCTION_P: Functions for C++. (line 138) 50541* DECL_OVERLOADED_OPERATOR_P: Functions for C++. (line 102) 50542* DECL_PURE_P: Function Properties. 50543 (line 40) 50544* DECL_RESULT: Function Basics. (line 41) 50545* DECL_SAVED_TREE: Function Basics. (line 44) 50546* DECL_SIZE: Declarations. (line 6) 50547* DECL_STATIC_FUNCTION_P: Functions for C++. (line 65) 50548* DECL_STMT: Statements for C++. (line 6) 50549* DECL_STMT_DECL: Statements for C++. (line 6) 50550* DECL_THUNK_P: Functions for C++. (line 116) 50551* DECL_VIRTUAL_P: Function Properties. 50552 (line 44) 50553* DECL_VOLATILE_MEMFUNC_P: Functions for C++. (line 74) 50554* decrement_and_branch_until_zero instruction pattern: Standard Names. 50555 (line 1679) 50556* default: GTY Options. (line 90) 50557* default_file_start: File Framework. (line 8) 50558* DEFAULT_GDB_EXTENSIONS: DBX Options. (line 17) 50559* DEFAULT_INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 199) 50560* DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 34) 50561* DEFAULT_SIGNED_CHAR: Type Layout. (line 117) 50562* define_address_constraint: Define Constraints. (line 113) 50563* define_asm_attributes: Tagging Insns. (line 73) 50564* define_attr: Defining Attributes. 50565 (line 6) 50566* define_automaton: Processor pipeline description. 50567 (line 53) 50568* define_bypass: Processor pipeline description. 50569 (line 196) 50570* define_code_attr: Code Iterators. (line 6) 50571* define_code_iterator: Code Iterators. (line 6) 50572* define_cond_exec: Conditional Execution. 50573 (line 13) 50574* define_constants: Constant Definitions. 50575 (line 6) 50576* define_constraint: Define Constraints. (line 45) 50577* define_cpu_unit: Processor pipeline description. 50578 (line 68) 50579* define_c_enum: Constant Definitions. 50580 (line 49) 50581* define_delay: Delay Slots. (line 25) 50582* define_enum: Constant Definitions. 50583 (line 118) 50584* define_enum_attr: Defining Attributes. 50585 (line 83) 50586* define_enum_attr <1>: Constant Definitions. 50587 (line 136) 50588* define_expand: Expander Definitions. 50589 (line 11) 50590* define_insn: Patterns. (line 6) 50591* define_insn example: Example. (line 6) 50592* define_insn_and_split: Insn Splitting. (line 170) 50593* define_insn_reservation: Processor pipeline description. 50594 (line 105) 50595* define_int_attr: Int Iterators. (line 6) 50596* define_int_iterator: Int Iterators. (line 6) 50597* define_memory_constraint: Define Constraints. (line 80) 50598* define_mode_attr: Substitutions. (line 6) 50599* define_mode_iterator: Defining Mode Iterators. 50600 (line 6) 50601* define_peephole: define_peephole. (line 6) 50602* define_peephole2: define_peephole2. (line 6) 50603* define_predicate: Defining Predicates. 50604 (line 6) 50605* define_query_cpu_unit: Processor pipeline description. 50606 (line 90) 50607* define_register_constraint: Define Constraints. (line 26) 50608* define_reservation: Processor pipeline description. 50609 (line 185) 50610* define_special_memory_constraint: Define Constraints. (line 99) 50611* define_special_predicate: Defining Predicates. 50612 (line 6) 50613* define_split: Insn Splitting. (line 32) 50614* define_subst: Define Subst. (line 6) 50615* define_subst <1>: Define Subst Example. 50616 (line 6) 50617* define_subst <2>: Define Subst Pattern Matching. 50618 (line 6) 50619* define_subst <3>: Define Subst Output Template. 50620 (line 6) 50621* define_subst <4>: Define Subst. (line 14) 50622* define_subst <5>: Subst Iterators. (line 6) 50623* define_subst_attr: Subst Iterators. (line 6) 50624* define_subst_attr <1>: Subst Iterators. (line 26) 50625* defining attributes and their values: Defining Attributes. 50626 (line 6) 50627* defining constraints: Define Constraints. (line 6) 50628* defining jump instruction patterns: Jump Patterns. (line 6) 50629* defining looping instruction patterns: Looping Patterns. (line 6) 50630* defining peephole optimizers: Peephole Definitions. 50631 (line 6) 50632* defining predicates: Defining Predicates. 50633 (line 6) 50634* defining RTL sequences for code generation: Expander Definitions. 50635 (line 6) 50636* delay slots, defining: Delay Slots. (line 6) 50637* deletable: GTY Options. (line 134) 50638* DELETE_IF_ORDINARY: Filesystem. (line 79) 50639* Dependent Patterns: Dependent Patterns. (line 6) 50640* desc: GTY Options. (line 90) 50641* destructors, output of: Initialization. (line 6) 50642* deterministic finite state automaton: Processor pipeline description. 50643 (line 6) 50644* deterministic finite state automaton <1>: Processor pipeline description. 50645 (line 304) 50646* DFmode: Machine Modes. (line 76) 50647* digits in constraint: Simple Constraints. (line 128) 50648* DImode: Machine Modes. (line 45) 50649* directory options .md: Including Patterns. (line 47) 50650* DIR_SEPARATOR: Filesystem. (line 18) 50651* DIR_SEPARATOR_2: Filesystem. (line 19) 50652* disabling certain registers: Register Basics. (line 77) 50653* dispatch table: Dispatch Tables. (line 8) 50654* div: Arithmetic. (line 116) 50655* div and attributes: Expressions. (line 83) 50656* division: Arithmetic. (line 116) 50657* division <1>: Arithmetic. (line 130) 50658* division <2>: Arithmetic. (line 136) 50659* divM3 instruction pattern: Standard Names. (line 416) 50660* divmodM4 instruction pattern: Standard Names. (line 710) 50661* dollar sign: Multi-Alternative. (line 57) 50662* DOLLARS_IN_IDENTIFIERS: Misc. (line 474) 50663* doloop_begin instruction pattern: Standard Names. (line 1701) 50664* doloop_end instruction pattern: Standard Names. (line 1689) 50665* DONE: Expander Definitions. 50666 (line 77) 50667* DONT_USE_BUILTIN_SETJMP: Exception Region Output. 50668 (line 78) 50669* DOUBLE_TYPE_SIZE: Type Layout. (line 52) 50670* DO_BODY: Statements for C++. (line 6) 50671* DO_COND: Statements for C++. (line 6) 50672* DO_STMT: Statements for C++. (line 6) 50673* DQmode: Machine Modes. (line 118) 50674* driver: Driver. (line 6) 50675* DRIVER_SELF_SPECS: Driver. (line 8) 50676* dump examples: Dump examples. (line 6) 50677* dump setup: Dump setup. (line 6) 50678* dump types: Dump types. (line 6) 50679* dump verbosity: Dump output verbosity. 50680 (line 6) 50681* DUMPFILE_FORMAT: Filesystem. (line 67) 50682* dump_basic_block: Dump types. (line 29) 50683* dump_generic_expr: Dump types. (line 31) 50684* dump_gimple_stmt: Dump types. (line 33) 50685* dump_printf: Dump types. (line 6) 50686* DWARF2_ASM_LINE_DEBUG_INFO: DWARF. (line 45) 50687* DWARF2_ASM_VIEW_DEBUG_INFO: DWARF. (line 51) 50688* DWARF2_DEBUGGING_INFO: DWARF. (line 8) 50689* DWARF2_FRAME_INFO: DWARF. (line 25) 50690* DWARF2_FRAME_REG_OUT: Frame Registers. (line 149) 50691* DWARF2_UNWIND_INFO: Exception Region Output. 50692 (line 39) 50693* DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 146) 50694* DWARF_CIE_DATA_ALIGNMENT: Exception Region Output. 50695 (line 90) 50696* DWARF_FRAME_REGISTERS: Frame Registers. (line 109) 50697* DWARF_FRAME_REGNUM: Frame Registers. (line 141) 50698* DWARF_LAZY_REGISTER_VALUE: Frame Registers. (line 170) 50699* DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 134) 50700* DWARF_ZERO_REG: Frame Layout. (line 157) 50701* DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 84) 50702* E in constraint: Simple Constraints. (line 87) 50703* earlyclobber operand: Modifiers. (line 25) 50704* edge: Edges. (line 6) 50705* edge in the flow graph: Edges. (line 6) 50706* edge iterators: Edges. (line 15) 50707* edge splitting: Maintaining the CFG. 50708 (line 104) 50709* EDGE_ABNORMAL: Edges. (line 127) 50710* EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 171) 50711* EDGE_ABNORMAL, EDGE_EH: Edges. (line 95) 50712* EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 121) 50713* EDGE_FALLTHRU, force_nonfallthru: Edges. (line 85) 50714* EDOM, implicit usage: Library Calls. (line 59) 50715* EH_FRAME_SECTION_NAME: Exception Region Output. 50716 (line 9) 50717* EH_FRAME_THROUGH_COLLECT2: Exception Region Output. 50718 (line 19) 50719* eh_return instruction pattern: Standard Names. (line 1882) 50720* EH_RETURN_DATA_REGNO: Exception Handling. (line 6) 50721* EH_RETURN_HANDLER_RTX: Exception Handling. (line 38) 50722* EH_RETURN_STACKADJ_RTX: Exception Handling. (line 21) 50723* EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output. 50724 (line 29) 50725* EH_USES: Function Entry. (line 162) 50726* ei_edge: Edges. (line 43) 50727* ei_end_p: Edges. (line 27) 50728* ei_last: Edges. (line 23) 50729* ei_next: Edges. (line 35) 50730* ei_one_before_end_p: Edges. (line 31) 50731* ei_prev: Edges. (line 39) 50732* ei_safe_safe: Edges. (line 47) 50733* ei_start: Edges. (line 19) 50734* ELIMINABLE_REGS: Elimination. (line 34) 50735* ELSE_CLAUSE: Statements for C++. (line 6) 50736* Embedded C: Fixed-point fractional library routines. 50737 (line 6) 50738* Empty Statements: Empty Statements. (line 6) 50739* EMPTY_CLASS_EXPR: Statements for C++. (line 6) 50740* EMPTY_FIELD_BOUNDARY: Storage Layout. (line 338) 50741* Emulated TLS: Emulated TLS. (line 6) 50742* enabled: Disable Insn Alternatives. 50743 (line 6) 50744* ENDFILE_SPEC: Driver. (line 155) 50745* endianness: Portability. (line 20) 50746* ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 10) 50747* entry_value: Debug Information. (line 30) 50748* enum reg_class: Register Classes. (line 70) 50749* ENUMERAL_TYPE: Types. (line 6) 50750* enumerations: Constant Definitions. 50751 (line 49) 50752* epilogue: Function Entry. (line 6) 50753* epilogue instruction pattern: Standard Names. (line 1920) 50754* EPILOGUE_USES: Function Entry. (line 156) 50755* eq: Comparisons. (line 52) 50756* eq and attributes: Expressions. (line 83) 50757* equal: Comparisons. (line 52) 50758* eq_attr: Expressions. (line 104) 50759* EQ_EXPR: Unary and Binary Expressions. 50760 (line 6) 50761* errno, implicit usage: Library Calls. (line 71) 50762* EXACT_DIV_EXPR: Unary and Binary Expressions. 50763 (line 6) 50764* examining SSA_NAMEs: SSA. (line 182) 50765* exception handling: Edges. (line 95) 50766* exception handling <1>: Exception Handling. (line 6) 50767* exception_receiver instruction pattern: Standard Names. (line 1847) 50768* exclamation point: Multi-Alternative. (line 48) 50769* exclusion_set: Processor pipeline description. 50770 (line 223) 50771* exclusive-or, bitwise: Arithmetic. (line 168) 50772* EXIT_EXPR: Unary and Binary Expressions. 50773 (line 6) 50774* EXIT_IGNORE_STACK: Function Entry. (line 144) 50775* exp10M2 instruction pattern: Standard Names. (line 877) 50776* exp2M2 instruction pattern: Standard Names. (line 884) 50777* expander definitions: Expander Definitions. 50778 (line 6) 50779* expm1M2 instruction pattern: Standard Names. (line 867) 50780* expM2 instruction pattern: Standard Names. (line 860) 50781* expression: Expression trees. (line 6) 50782* expression codes: RTL Objects. (line 47) 50783* EXPR_FILENAME: Working with declarations. 50784 (line 14) 50785* EXPR_LINENO: Working with declarations. 50786 (line 20) 50787* expr_list: Insns. (line 568) 50788* EXPR_STMT: Statements for C++. (line 6) 50789* EXPR_STMT_EXPR: Statements for C++. (line 6) 50790* extendMN2 instruction pattern: Standard Names. (line 1283) 50791* extensible constraints: Simple Constraints. (line 171) 50792* extract_last_M instruction pattern: Standard Names. (line 518) 50793* EXTRA_SPECS: Driver. (line 182) 50794* extv instruction pattern: Standard Names. (line 1374) 50795* extvM instruction pattern: Standard Names. (line 1319) 50796* extvmisalignM instruction pattern: Standard Names. (line 1329) 50797* extzv instruction pattern: Standard Names. (line 1392) 50798* extzvM instruction pattern: Standard Names. (line 1343) 50799* extzvmisalignM instruction pattern: Standard Names. (line 1346) 50800* F in constraint: Simple Constraints. (line 92) 50801* FAIL: Expander Definitions. 50802 (line 83) 50803* fall-thru: Edges. (line 68) 50804* FATAL_EXIT_CODE: Host Misc. (line 6) 50805* FDL, GNU Free Documentation License: GNU Free Documentation License. 50806 (line 6) 50807* features, optional, in system conventions: Run-time Target. 50808 (line 59) 50809* ffs: Arithmetic. (line 210) 50810* ffsM2 instruction pattern: Standard Names. (line 1031) 50811* FIELD_DECL: Declarations. (line 6) 50812* files and passes of the compiler: Passes. (line 6) 50813* files, generated: Files. (line 6) 50814* file_end_indicate_exec_stack: File Framework. (line 39) 50815* final_absence_set: Processor pipeline description. 50816 (line 223) 50817* FINAL_PRESCAN_INSN: Instruction Output. (line 60) 50818* final_presence_set: Processor pipeline description. 50819 (line 223) 50820* final_sequence: Instruction Output. (line 144) 50821* FIND_BASE_TERM: Addressing Modes. (line 117) 50822* finite state automaton minimization: Processor pipeline description. 50823 (line 304) 50824* FINI_ARRAY_SECTION_ASM_OP: Sections. (line 113) 50825* FINI_SECTION_ASM_OP: Sections. (line 98) 50826* FIRST_PARM_OFFSET: Frame Layout. (line 59) 50827* FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65) 50828* FIRST_PSEUDO_REGISTER: Register Basics. (line 8) 50829* FIRST_STACK_REG: Stack Registers. (line 26) 50830* FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 50831* fix: Conversions. (line 66) 50832* fixed register: Register Basics. (line 15) 50833* fixed-point fractional library: Fixed-point fractional library routines. 50834 (line 6) 50835* FIXED_CONVERT_EXPR: Unary and Binary Expressions. 50836 (line 6) 50837* FIXED_CST: Constant expressions. 50838 (line 6) 50839* FIXED_POINT_TYPE: Types. (line 6) 50840* FIXED_REGISTERS: Register Basics. (line 14) 50841* fixed_regs: Register Basics. (line 63) 50842* fixed_size_mode: Machine Modes. (line 309) 50843* fixMN2 instruction pattern: Standard Names. (line 1250) 50844* fixunsMN2 instruction pattern: Standard Names. (line 1259) 50845* fixuns_truncMN2 instruction pattern: Standard Names. (line 1274) 50846* fix_truncMN2 instruction pattern: Standard Names. (line 1270) 50847* FIX_TRUNC_EXPR: Unary and Binary Expressions. 50848 (line 6) 50849* flags in RTL expression: Flags. (line 6) 50850* float: Conversions. (line 58) 50851* floating point and cross compilation: Floating Point. (line 6) 50852* floatMN2 instruction pattern: Standard Names. (line 1242) 50853* floatunsMN2 instruction pattern: Standard Names. (line 1246) 50854* FLOAT_EXPR: Unary and Binary Expressions. 50855 (line 6) 50856* float_extend: Conversions. (line 33) 50857* FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 32) 50858* FLOAT_STORE_FLAG_VALUE: Misc. (line 308) 50859* float_truncate: Conversions. (line 53) 50860* FLOAT_TYPE_SIZE: Type Layout. (line 48) 50861* FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 41) 50862* FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory. 50863 (line 234) 50864* floorM2 instruction pattern: Standard Names. (line 951) 50865* FLOOR_DIV_EXPR: Unary and Binary Expressions. 50866 (line 6) 50867* FLOOR_MOD_EXPR: Unary and Binary Expressions. 50868 (line 6) 50869* flow-insensitive alias analysis: Alias analysis. (line 6) 50870* flow-sensitive alias analysis: Alias analysis. (line 6) 50871* fma: Arithmetic. (line 112) 50872* fmaM4 instruction pattern: Standard Names. (line 453) 50873* fmaxM3 instruction pattern: Standard Names. (line 484) 50874* fminM3 instruction pattern: Standard Names. (line 484) 50875* fmodM3 instruction pattern: Standard Names. (line 783) 50876* fmsM4 instruction pattern: Standard Names. (line 460) 50877* fnmaM4 instruction pattern: Standard Names. (line 466) 50878* fnmsM4 instruction pattern: Standard Names. (line 472) 50879* fold_extract_last_M instruction pattern: Standard Names. (line 525) 50880* fold_left_plus_M instruction pattern: Standard Names. (line 533) 50881* FORCE_CODE_SECTION_ALIGN: Sections. (line 149) 50882* force_reg: Standard Names. (line 36) 50883* FOR_BODY: Statements for C++. (line 6) 50884* FOR_COND: Statements for C++. (line 6) 50885* FOR_EXPR: Statements for C++. (line 6) 50886* FOR_INIT_STMT: Statements for C++. (line 6) 50887* FOR_STMT: Statements for C++. (line 6) 50888* for_user: GTY Options. (line 82) 50889* fractional types: Fixed-point fractional library routines. 50890 (line 6) 50891* fractMN2 instruction pattern: Standard Names. (line 1292) 50892* fractunsMN2 instruction pattern: Standard Names. (line 1307) 50893* fract_convert: Conversions. (line 82) 50894* FRACT_TYPE_SIZE: Type Layout. (line 67) 50895* frame layout: Frame Layout. (line 6) 50896* FRAME_ADDR_RTX: Frame Layout. (line 108) 50897* FRAME_GROWS_DOWNWARD: Frame Layout. (line 26) 50898* FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory. 50899 (line 69) 50900* FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 225) 50901* frame_pointer_needed: Function Entry. (line 42) 50902* FRAME_POINTER_REGNUM: Frame Registers. (line 13) 50903* FRAME_POINTER_REGNUM and virtual registers: Regs and Memory. 50904 (line 74) 50905* frame_pointer_rtx: Frame Registers. (line 104) 50906* frame_related: Flags. (line 238) 50907* frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags. 50908 (line 135) 50909* frame_related, in mem: Flags. (line 74) 50910* frame_related, in reg: Flags. (line 102) 50911* frame_related, in symbol_ref: Flags. (line 179) 50912* frequency, count, BB_FREQ_BASE: Profile information. 50913 (line 30) 50914* ftruncM2 instruction pattern: Standard Names. (line 1265) 50915* function: Functions. (line 6) 50916* function <1>: Functions for C++. (line 6) 50917* function call conventions: Interface. (line 6) 50918* function entry and exit: Function Entry. (line 6) 50919* function entry point, alternate function entry point: Edges. 50920 (line 180) 50921* function properties: Function Properties. 50922 (line 6) 50923* function-call insns: Calls. (line 6) 50924* functions, leaf: Leaf Functions. (line 6) 50925* FUNCTION_ARG_REGNO_P: Register Arguments. (line 269) 50926* FUNCTION_BOUNDARY: Storage Layout. (line 176) 50927* FUNCTION_DECL: Functions. (line 6) 50928* FUNCTION_DECL <1>: Functions for C++. (line 6) 50929* FUNCTION_MODE: Misc. (line 363) 50930* FUNCTION_PROFILER: Profiling. (line 8) 50931* FUNCTION_TYPE: Types. (line 6) 50932* FUNCTION_VALUE: Scalar Return. (line 52) 50933* FUNCTION_VALUE_REGNO_P: Scalar Return. (line 78) 50934* fundamental type: Types. (line 6) 50935* G in constraint: Simple Constraints. (line 96) 50936* g in constraint: Simple Constraints. (line 118) 50937* garbage collector, invocation: Invoking the garbage collector. 50938 (line 6) 50939* garbage collector, troubleshooting: Troubleshooting. (line 6) 50940* gather_loadM instruction pattern: Standard Names. (line 232) 50941* GCC and portability: Portability. (line 6) 50942* GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36) 50943* gcov_type: Profile information. 50944 (line 41) 50945* ge: Comparisons. (line 72) 50946* ge and attributes: Expressions. (line 83) 50947* gencodes: RTL passes. (line 18) 50948* general_operand: Machine-Independent Predicates. 50949 (line 104) 50950* GENERAL_REGS: Register Classes. (line 22) 50951* generated files: Files. (line 6) 50952* generating assembler output: Output Statement. (line 6) 50953* generating insns: RTL Template. (line 6) 50954* GENERIC: Parsing pass. (line 6) 50955* GENERIC <1>: GENERIC. (line 6) 50956* generic predicates: Machine-Independent Predicates. 50957 (line 6) 50958* genflags: RTL passes. (line 18) 50959* GEN_ERRNO_RTX: Library Calls. (line 71) 50960* get_attr: Expressions. (line 99) 50961* get_attr_length: Insn Lengths. (line 52) 50962* GET_CLASS_NARROWEST_MODE: Machine Modes. (line 434) 50963* GET_CODE: RTL Objects. (line 47) 50964* get_insns: Insns. (line 34) 50965* get_last_insn: Insns. (line 34) 50966* GET_MODE: Machine Modes. (line 381) 50967* GET_MODE_ALIGNMENT: Machine Modes. (line 421) 50968* GET_MODE_BITSIZE: Machine Modes. (line 405) 50969* GET_MODE_CLASS: Machine Modes. (line 395) 50970* GET_MODE_FBIT: Machine Modes. (line 412) 50971* GET_MODE_IBIT: Machine Modes. (line 408) 50972* GET_MODE_MASK: Machine Modes. (line 416) 50973* GET_MODE_NAME: Machine Modes. (line 392) 50974* GET_MODE_NUNITS: Machine Modes. (line 430) 50975* GET_MODE_SIZE: Machine Modes. (line 402) 50976* GET_MODE_UNIT_SIZE: Machine Modes. (line 424) 50977* GET_MODE_WIDER_MODE: Machine Modes. (line 398) 50978* GET_RTX_CLASS: RTL Classes. (line 6) 50979* GET_RTX_FORMAT: RTL Classes. (line 135) 50980* GET_RTX_LENGTH: RTL Classes. (line 132) 50981* get_thread_pointerMODE instruction pattern: Standard Names. 50982 (line 2285) 50983* geu: Comparisons. (line 72) 50984* geu and attributes: Expressions. (line 83) 50985* GE_EXPR: Unary and Binary Expressions. 50986 (line 6) 50987* GGC: Type Information. (line 6) 50988* ggc_collect: Invoking the garbage collector. 50989 (line 6) 50990* GIMPLE: Parsing pass. (line 13) 50991* GIMPLE <1>: Gimplification pass. 50992 (line 6) 50993* GIMPLE <2>: GIMPLE. (line 6) 50994* gimple: Tuple representation. 50995 (line 14) 50996* GIMPLE API: GIMPLE API. (line 6) 50997* GIMPLE class hierarchy: Class hierarchy of GIMPLE statements. 50998 (line 6) 50999* GIMPLE Exception Handling: GIMPLE Exception Handling. 51000 (line 6) 51001* GIMPLE instruction set: GIMPLE instruction set. 51002 (line 6) 51003* GIMPLE sequences: GIMPLE sequences. (line 6) 51004* GIMPLE statement iterators: Basic Blocks. (line 78) 51005* GIMPLE statement iterators <1>: Maintaining the CFG. 51006 (line 33) 51007* gimple_addresses_taken: Manipulating GIMPLE statements. 51008 (line 89) 51009* GIMPLE_ASM: GIMPLE_ASM. (line 6) 51010* gimple_asm_clobber_op: GIMPLE_ASM. (line 39) 51011* gimple_asm_input_op: GIMPLE_ASM. (line 23) 51012* gimple_asm_nclobbers: GIMPLE_ASM. (line 20) 51013* gimple_asm_ninputs: GIMPLE_ASM. (line 14) 51014* gimple_asm_noutputs: GIMPLE_ASM. (line 17) 51015* gimple_asm_output_op: GIMPLE_ASM. (line 31) 51016* gimple_asm_set_clobber_op: GIMPLE_ASM. (line 43) 51017* gimple_asm_set_input_op: GIMPLE_ASM. (line 27) 51018* gimple_asm_set_output_op: GIMPLE_ASM. (line 35) 51019* gimple_asm_set_volatile: GIMPLE_ASM. (line 54) 51020* gimple_asm_string: GIMPLE_ASM. (line 47) 51021* gimple_asm_volatile_p: GIMPLE_ASM. (line 51) 51022* GIMPLE_ASSIGN: GIMPLE_ASSIGN. (line 6) 51023* gimple_assign_cast_p: Logical Operators. (line 158) 51024* gimple_assign_cast_p <1>: GIMPLE_ASSIGN. (line 104) 51025* gimple_assign_lhs: GIMPLE_ASSIGN. (line 62) 51026* gimple_assign_lhs_ptr: GIMPLE_ASSIGN. (line 65) 51027* gimple_assign_rhs1: GIMPLE_ASSIGN. (line 68) 51028* gimple_assign_rhs1_ptr: GIMPLE_ASSIGN. (line 71) 51029* gimple_assign_rhs2: GIMPLE_ASSIGN. (line 75) 51030* gimple_assign_rhs2_ptr: GIMPLE_ASSIGN. (line 78) 51031* gimple_assign_rhs3: GIMPLE_ASSIGN. (line 82) 51032* gimple_assign_rhs3_ptr: GIMPLE_ASSIGN. (line 85) 51033* gimple_assign_rhs_class: GIMPLE_ASSIGN. (line 56) 51034* gimple_assign_rhs_code: GIMPLE_ASSIGN. (line 52) 51035* gimple_assign_set_lhs: GIMPLE_ASSIGN. (line 89) 51036* gimple_assign_set_rhs1: GIMPLE_ASSIGN. (line 92) 51037* gimple_assign_set_rhs2: GIMPLE_ASSIGN. (line 96) 51038* gimple_assign_set_rhs3: GIMPLE_ASSIGN. (line 100) 51039* gimple_bb: Manipulating GIMPLE statements. 51040 (line 17) 51041* GIMPLE_BIND: GIMPLE_BIND. (line 6) 51042* gimple_bind_add_seq: GIMPLE_BIND. (line 34) 51043* gimple_bind_add_stmt: GIMPLE_BIND. (line 31) 51044* gimple_bind_append_vars: GIMPLE_BIND. (line 18) 51045* gimple_bind_block: GIMPLE_BIND. (line 39) 51046* gimple_bind_body: GIMPLE_BIND. (line 22) 51047* gimple_bind_set_block: GIMPLE_BIND. (line 44) 51048* gimple_bind_set_body: GIMPLE_BIND. (line 26) 51049* gimple_bind_set_vars: GIMPLE_BIND. (line 14) 51050* gimple_bind_vars: GIMPLE_BIND. (line 11) 51051* gimple_block: Manipulating GIMPLE statements. 51052 (line 20) 51053* gimple_build: GIMPLE API. (line 34) 51054* gimple_build <1>: GIMPLE API. (line 36) 51055* gimple_build <2>: GIMPLE API. (line 38) 51056* gimple_build <3>: GIMPLE API. (line 41) 51057* gimple_build <4>: GIMPLE API. (line 44) 51058* gimple_build <5>: GIMPLE API. (line 47) 51059* gimple_build_debug_begin_stmt: GIMPLE_DEBUG. (line 72) 51060* gimple_build_debug_inline_entry: GIMPLE_DEBUG. (line 82) 51061* gimple_build_nop: GIMPLE_NOP. (line 6) 51062* gimple_build_omp_master: GIMPLE_OMP_MASTER. (line 6) 51063* gimple_build_omp_ordered: GIMPLE_OMP_ORDERED. (line 6) 51064* gimple_build_omp_return: GIMPLE_OMP_RETURN. (line 6) 51065* gimple_build_omp_section: GIMPLE_OMP_SECTION. (line 6) 51066* gimple_build_omp_sections_switch: GIMPLE_OMP_SECTIONS. 51067 (line 13) 51068* gimple_build_wce: GIMPLE_WITH_CLEANUP_EXPR. 51069 (line 6) 51070* GIMPLE_CALL: GIMPLE_CALL. (line 6) 51071* gimple_call_arg: GIMPLE_CALL. (line 67) 51072* gimple_call_arg_ptr: GIMPLE_CALL. (line 71) 51073* gimple_call_chain: GIMPLE_CALL. (line 58) 51074* gimple_call_copy_skip_args: GIMPLE_CALL. (line 92) 51075* gimple_call_fn: GIMPLE_CALL. (line 39) 51076* gimple_call_fndecl: GIMPLE_CALL. (line 47) 51077* gimple_call_lhs: GIMPLE_CALL. (line 30) 51078* gimple_call_lhs_ptr: GIMPLE_CALL. (line 33) 51079* gimple_call_noreturn_p: GIMPLE_CALL. (line 89) 51080* gimple_call_num_args: GIMPLE_CALL. (line 64) 51081* gimple_call_return_type: GIMPLE_CALL. (line 55) 51082* gimple_call_set_arg: GIMPLE_CALL. (line 76) 51083* gimple_call_set_chain: GIMPLE_CALL. (line 61) 51084* gimple_call_set_fn: GIMPLE_CALL. (line 43) 51085* gimple_call_set_fndecl: GIMPLE_CALL. (line 52) 51086* gimple_call_set_lhs: GIMPLE_CALL. (line 36) 51087* gimple_call_set_tail: GIMPLE_CALL. (line 81) 51088* gimple_call_tail_p: GIMPLE_CALL. (line 86) 51089* GIMPLE_CATCH: GIMPLE_CATCH. (line 6) 51090* gimple_catch_handler: GIMPLE_CATCH. (line 19) 51091* gimple_catch_set_handler: GIMPLE_CATCH. (line 26) 51092* gimple_catch_set_types: GIMPLE_CATCH. (line 23) 51093* gimple_catch_types: GIMPLE_CATCH. (line 12) 51094* gimple_catch_types_ptr: GIMPLE_CATCH. (line 15) 51095* gimple_code: Manipulating GIMPLE statements. 51096 (line 14) 51097* GIMPLE_COND: GIMPLE_COND. (line 6) 51098* gimple_cond_code: GIMPLE_COND. (line 20) 51099* gimple_cond_false_label: GIMPLE_COND. (line 59) 51100* gimple_cond_lhs: GIMPLE_COND. (line 29) 51101* gimple_cond_make_false: GIMPLE_COND. (line 63) 51102* gimple_cond_make_true: GIMPLE_COND. (line 66) 51103* gimple_cond_rhs: GIMPLE_COND. (line 37) 51104* gimple_cond_set_code: GIMPLE_COND. (line 24) 51105* gimple_cond_set_false_label: GIMPLE_COND. (line 54) 51106* gimple_cond_set_lhs: GIMPLE_COND. (line 33) 51107* gimple_cond_set_rhs: GIMPLE_COND. (line 41) 51108* gimple_cond_set_true_label: GIMPLE_COND. (line 49) 51109* gimple_cond_true_label: GIMPLE_COND. (line 45) 51110* gimple_convert: GIMPLE API. (line 50) 51111* gimple_copy: Manipulating GIMPLE statements. 51112 (line 146) 51113* GIMPLE_DEBUG: GIMPLE_DEBUG. (line 6) 51114* GIMPLE_DEBUG_BEGIN_STMT: GIMPLE_DEBUG. (line 6) 51115* GIMPLE_DEBUG_BIND: GIMPLE_DEBUG. (line 6) 51116* gimple_debug_bind_get_value: GIMPLE_DEBUG. (line 46) 51117* gimple_debug_bind_get_value_ptr: GIMPLE_DEBUG. (line 50) 51118* gimple_debug_bind_get_var: GIMPLE_DEBUG. (line 43) 51119* gimple_debug_bind_has_value_p: GIMPLE_DEBUG. (line 68) 51120* gimple_debug_bind_p: Logical Operators. (line 162) 51121* gimple_debug_bind_reset_value: GIMPLE_DEBUG. (line 64) 51122* gimple_debug_bind_set_value: GIMPLE_DEBUG. (line 59) 51123* gimple_debug_bind_set_var: GIMPLE_DEBUG. (line 55) 51124* GIMPLE_DEBUG_INLINE_ENTRY: GIMPLE_DEBUG. (line 6) 51125* gimple_def_ops: Manipulating GIMPLE statements. 51126 (line 93) 51127* GIMPLE_EH_FILTER: GIMPLE_EH_FILTER. (line 6) 51128* gimple_eh_filter_failure: GIMPLE_EH_FILTER. (line 18) 51129* gimple_eh_filter_set_failure: GIMPLE_EH_FILTER. (line 27) 51130* gimple_eh_filter_set_types: GIMPLE_EH_FILTER. (line 22) 51131* gimple_eh_filter_types: GIMPLE_EH_FILTER. (line 11) 51132* gimple_eh_filter_types_ptr: GIMPLE_EH_FILTER. (line 14) 51133* gimple_eh_must_not_throw_fndecl: GIMPLE_EH_FILTER. (line 32) 51134* gimple_eh_must_not_throw_set_fndecl: GIMPLE_EH_FILTER. (line 36) 51135* gimple_expr_code: Manipulating GIMPLE statements. 51136 (line 30) 51137* gimple_expr_type: Manipulating GIMPLE statements. 51138 (line 23) 51139* GIMPLE_GOTO: GIMPLE_GOTO. (line 6) 51140* gimple_goto_dest: GIMPLE_GOTO. (line 9) 51141* gimple_goto_set_dest: GIMPLE_GOTO. (line 12) 51142* gimple_has_mem_ops: Manipulating GIMPLE statements. 51143 (line 71) 51144* gimple_has_ops: Manipulating GIMPLE statements. 51145 (line 68) 51146* gimple_has_volatile_ops: Manipulating GIMPLE statements. 51147 (line 133) 51148* GIMPLE_LABEL: GIMPLE_LABEL. (line 6) 51149* gimple_label_label: GIMPLE_LABEL. (line 10) 51150* gimple_label_set_label: GIMPLE_LABEL. (line 13) 51151* gimple_loaded_syms: Manipulating GIMPLE statements. 51152 (line 121) 51153* gimple_locus: Manipulating GIMPLE statements. 51154 (line 41) 51155* gimple_locus_empty_p: Manipulating GIMPLE statements. 51156 (line 47) 51157* gimple_modified_p: Manipulating GIMPLE statements. 51158 (line 129) 51159* GIMPLE_NOP: GIMPLE_NOP. (line 6) 51160* gimple_nop_p: GIMPLE_NOP. (line 9) 51161* gimple_no_warning_p: Manipulating GIMPLE statements. 51162 (line 50) 51163* gimple_num_ops: Logical Operators. (line 76) 51164* gimple_num_ops <1>: Manipulating GIMPLE statements. 51165 (line 74) 51166* GIMPLE_OMP_ATOMIC_LOAD: GIMPLE_OMP_ATOMIC_LOAD. 51167 (line 6) 51168* gimple_omp_atomic_load_lhs: GIMPLE_OMP_ATOMIC_LOAD. 51169 (line 16) 51170* gimple_omp_atomic_load_rhs: GIMPLE_OMP_ATOMIC_LOAD. 51171 (line 24) 51172* gimple_omp_atomic_load_set_lhs: GIMPLE_OMP_ATOMIC_LOAD. 51173 (line 12) 51174* gimple_omp_atomic_load_set_rhs: GIMPLE_OMP_ATOMIC_LOAD. 51175 (line 20) 51176* GIMPLE_OMP_ATOMIC_STORE: GIMPLE_OMP_ATOMIC_STORE. 51177 (line 6) 51178* gimple_omp_atomic_store_set_val: GIMPLE_OMP_ATOMIC_STORE. 51179 (line 11) 51180* gimple_omp_atomic_store_val: GIMPLE_OMP_ATOMIC_STORE. 51181 (line 15) 51182* gimple_omp_body: GIMPLE_OMP_PARALLEL. 51183 (line 23) 51184* GIMPLE_OMP_CONTINUE: GIMPLE_OMP_CONTINUE. 51185 (line 6) 51186* gimple_omp_continue_control_def: GIMPLE_OMP_CONTINUE. 51187 (line 12) 51188* gimple_omp_continue_control_def_ptr: GIMPLE_OMP_CONTINUE. 51189 (line 17) 51190* gimple_omp_continue_control_use: GIMPLE_OMP_CONTINUE. 51191 (line 26) 51192* gimple_omp_continue_control_use_ptr: GIMPLE_OMP_CONTINUE. 51193 (line 31) 51194* gimple_omp_continue_set_control_def: GIMPLE_OMP_CONTINUE. 51195 (line 21) 51196* gimple_omp_continue_set_control_use: GIMPLE_OMP_CONTINUE. 51197 (line 35) 51198* GIMPLE_OMP_CRITICAL: GIMPLE_OMP_CRITICAL. 51199 (line 6) 51200* gimple_omp_critical_name: GIMPLE_OMP_CRITICAL. 51201 (line 12) 51202* gimple_omp_critical_name_ptr: GIMPLE_OMP_CRITICAL. 51203 (line 16) 51204* gimple_omp_critical_set_name: GIMPLE_OMP_CRITICAL. 51205 (line 21) 51206* GIMPLE_OMP_FOR: GIMPLE_OMP_FOR. (line 6) 51207* gimple_omp_for_clauses: GIMPLE_OMP_FOR. (line 17) 51208* gimple_omp_for_clauses_ptr: GIMPLE_OMP_FOR. (line 20) 51209* gimple_omp_for_cond: GIMPLE_OMP_FOR. (line 80) 51210* gimple_omp_for_final: GIMPLE_OMP_FOR. (line 48) 51211* gimple_omp_for_final_ptr: GIMPLE_OMP_FOR. (line 51) 51212* gimple_omp_for_incr: GIMPLE_OMP_FOR. (line 58) 51213* gimple_omp_for_incr_ptr: GIMPLE_OMP_FOR. (line 61) 51214* gimple_omp_for_index: GIMPLE_OMP_FOR. (line 28) 51215* gimple_omp_for_index_ptr: GIMPLE_OMP_FOR. (line 31) 51216* gimple_omp_for_initial: GIMPLE_OMP_FOR. (line 38) 51217* gimple_omp_for_initial_ptr: GIMPLE_OMP_FOR. (line 41) 51218* gimple_omp_for_pre_body: GIMPLE_OMP_FOR. (line 67) 51219* gimple_omp_for_set_clauses: GIMPLE_OMP_FOR. (line 23) 51220* gimple_omp_for_set_cond: GIMPLE_OMP_FOR. (line 76) 51221* gimple_omp_for_set_final: GIMPLE_OMP_FOR. (line 54) 51222* gimple_omp_for_set_incr: GIMPLE_OMP_FOR. (line 64) 51223* gimple_omp_for_set_index: GIMPLE_OMP_FOR. (line 34) 51224* gimple_omp_for_set_initial: GIMPLE_OMP_FOR. (line 44) 51225* gimple_omp_for_set_pre_body: GIMPLE_OMP_FOR. (line 71) 51226* GIMPLE_OMP_MASTER: GIMPLE_OMP_MASTER. (line 6) 51227* GIMPLE_OMP_ORDERED: GIMPLE_OMP_ORDERED. (line 6) 51228* GIMPLE_OMP_PARALLEL: GIMPLE_OMP_PARALLEL. 51229 (line 6) 51230* gimple_omp_parallel_child_fn: GIMPLE_OMP_PARALLEL. 51231 (line 42) 51232* gimple_omp_parallel_child_fn_ptr: GIMPLE_OMP_PARALLEL. 51233 (line 47) 51234* gimple_omp_parallel_clauses: GIMPLE_OMP_PARALLEL. 51235 (line 30) 51236* gimple_omp_parallel_clauses_ptr: GIMPLE_OMP_PARALLEL. 51237 (line 33) 51238* gimple_omp_parallel_combined_p: GIMPLE_OMP_PARALLEL. 51239 (line 15) 51240* gimple_omp_parallel_data_arg: GIMPLE_OMP_PARALLEL. 51241 (line 56) 51242* gimple_omp_parallel_data_arg_ptr: GIMPLE_OMP_PARALLEL. 51243 (line 61) 51244* gimple_omp_parallel_set_child_fn: GIMPLE_OMP_PARALLEL. 51245 (line 52) 51246* gimple_omp_parallel_set_clauses: GIMPLE_OMP_PARALLEL. 51247 (line 37) 51248* gimple_omp_parallel_set_combined_p: GIMPLE_OMP_PARALLEL. 51249 (line 19) 51250* gimple_omp_parallel_set_data_arg: GIMPLE_OMP_PARALLEL. 51251 (line 65) 51252* GIMPLE_OMP_RETURN: GIMPLE_OMP_RETURN. (line 6) 51253* gimple_omp_return_nowait_p: GIMPLE_OMP_RETURN. (line 13) 51254* gimple_omp_return_set_nowait: GIMPLE_OMP_RETURN. (line 10) 51255* GIMPLE_OMP_SECTION: GIMPLE_OMP_SECTION. (line 6) 51256* GIMPLE_OMP_SECTIONS: GIMPLE_OMP_SECTIONS. 51257 (line 6) 51258* gimple_omp_sections_clauses: GIMPLE_OMP_SECTIONS. 51259 (line 29) 51260* gimple_omp_sections_clauses_ptr: GIMPLE_OMP_SECTIONS. 51261 (line 32) 51262* gimple_omp_sections_control: GIMPLE_OMP_SECTIONS. 51263 (line 16) 51264* gimple_omp_sections_control_ptr: GIMPLE_OMP_SECTIONS. 51265 (line 20) 51266* gimple_omp_sections_set_clauses: GIMPLE_OMP_SECTIONS. 51267 (line 35) 51268* gimple_omp_sections_set_control: GIMPLE_OMP_SECTIONS. 51269 (line 24) 51270* gimple_omp_section_last_p: GIMPLE_OMP_SECTION. (line 11) 51271* gimple_omp_section_set_last: GIMPLE_OMP_SECTION. (line 15) 51272* gimple_omp_set_body: GIMPLE_OMP_PARALLEL. 51273 (line 26) 51274* GIMPLE_OMP_SINGLE: GIMPLE_OMP_SINGLE. (line 6) 51275* gimple_omp_single_clauses: GIMPLE_OMP_SINGLE. (line 13) 51276* gimple_omp_single_clauses_ptr: GIMPLE_OMP_SINGLE. (line 16) 51277* gimple_omp_single_set_clauses: GIMPLE_OMP_SINGLE. (line 19) 51278* gimple_op: Logical Operators. (line 79) 51279* gimple_op <1>: Manipulating GIMPLE statements. 51280 (line 80) 51281* gimple_ops: Logical Operators. (line 82) 51282* gimple_ops <1>: Manipulating GIMPLE statements. 51283 (line 77) 51284* gimple_op_ptr: Manipulating GIMPLE statements. 51285 (line 83) 51286* GIMPLE_PHI: GIMPLE_PHI. (line 6) 51287* gimple_phi_arg: GIMPLE_PHI. (line 24) 51288* gimple_phi_arg <1>: SSA. (line 62) 51289* gimple_phi_arg_def: SSA. (line 68) 51290* gimple_phi_arg_edge: SSA. (line 65) 51291* gimple_phi_capacity: GIMPLE_PHI. (line 6) 51292* gimple_phi_num_args: GIMPLE_PHI. (line 10) 51293* gimple_phi_num_args <1>: SSA. (line 58) 51294* gimple_phi_result: GIMPLE_PHI. (line 15) 51295* gimple_phi_result <1>: SSA. (line 55) 51296* gimple_phi_result_ptr: GIMPLE_PHI. (line 18) 51297* gimple_phi_set_arg: GIMPLE_PHI. (line 28) 51298* gimple_phi_set_result: GIMPLE_PHI. (line 21) 51299* gimple_plf: Manipulating GIMPLE statements. 51300 (line 64) 51301* GIMPLE_RESX: GIMPLE_RESX. (line 6) 51302* gimple_resx_region: GIMPLE_RESX. (line 12) 51303* gimple_resx_set_region: GIMPLE_RESX. (line 15) 51304* GIMPLE_RETURN: GIMPLE_RETURN. (line 6) 51305* gimple_return_retval: GIMPLE_RETURN. (line 9) 51306* gimple_return_set_retval: GIMPLE_RETURN. (line 12) 51307* gimple_seq_add_seq: GIMPLE sequences. (line 30) 51308* gimple_seq_add_stmt: GIMPLE sequences. (line 24) 51309* gimple_seq_alloc: GIMPLE sequences. (line 61) 51310* gimple_seq_copy: GIMPLE sequences. (line 65) 51311* gimple_seq_deep_copy: GIMPLE sequences. (line 36) 51312* gimple_seq_empty_p: GIMPLE sequences. (line 69) 51313* gimple_seq_first: GIMPLE sequences. (line 43) 51314* gimple_seq_init: GIMPLE sequences. (line 58) 51315* gimple_seq_last: GIMPLE sequences. (line 46) 51316* gimple_seq_reverse: GIMPLE sequences. (line 39) 51317* gimple_seq_set_first: GIMPLE sequences. (line 53) 51318* gimple_seq_set_last: GIMPLE sequences. (line 49) 51319* gimple_seq_singleton_p: GIMPLE sequences. (line 78) 51320* gimple_set_block: Manipulating GIMPLE statements. 51321 (line 38) 51322* gimple_set_def_ops: Manipulating GIMPLE statements. 51323 (line 96) 51324* gimple_set_has_volatile_ops: Manipulating GIMPLE statements. 51325 (line 136) 51326* gimple_set_locus: Manipulating GIMPLE statements. 51327 (line 44) 51328* gimple_set_op: Manipulating GIMPLE statements. 51329 (line 86) 51330* gimple_set_plf: Manipulating GIMPLE statements. 51331 (line 60) 51332* gimple_set_use_ops: Manipulating GIMPLE statements. 51333 (line 103) 51334* gimple_set_vdef_ops: Manipulating GIMPLE statements. 51335 (line 117) 51336* gimple_set_visited: Manipulating GIMPLE statements. 51337 (line 53) 51338* gimple_set_vuse_ops: Manipulating GIMPLE statements. 51339 (line 110) 51340* gimple_simplify: GIMPLE API. (line 6) 51341* gimple_simplify <1>: GIMPLE API. (line 8) 51342* gimple_simplify <2>: GIMPLE API. (line 10) 51343* gimple_simplify <3>: GIMPLE API. (line 12) 51344* gimple_simplify <4>: GIMPLE API. (line 14) 51345* gimple_simplify <5>: GIMPLE API. (line 16) 51346* gimple_statement_with_ops: Tuple representation. 51347 (line 96) 51348* gimple_stored_syms: Manipulating GIMPLE statements. 51349 (line 125) 51350* GIMPLE_SWITCH: GIMPLE_SWITCH. (line 6) 51351* gimple_switch_default_label: GIMPLE_SWITCH. (line 41) 51352* gimple_switch_index: GIMPLE_SWITCH. (line 24) 51353* gimple_switch_label: GIMPLE_SWITCH. (line 31) 51354* gimple_switch_num_labels: GIMPLE_SWITCH. (line 14) 51355* gimple_switch_set_default_label: GIMPLE_SWITCH. (line 45) 51356* gimple_switch_set_index: GIMPLE_SWITCH. (line 27) 51357* gimple_switch_set_label: GIMPLE_SWITCH. (line 36) 51358* gimple_switch_set_num_labels: GIMPLE_SWITCH. (line 19) 51359* GIMPLE_TRY: GIMPLE_TRY. (line 6) 51360* gimple_try_catch_is_cleanup: GIMPLE_TRY. (line 19) 51361* gimple_try_cleanup: GIMPLE_TRY. (line 26) 51362* gimple_try_eval: GIMPLE_TRY. (line 22) 51363* gimple_try_kind: GIMPLE_TRY. (line 15) 51364* gimple_try_set_catch_is_cleanup: GIMPLE_TRY. (line 30) 51365* gimple_try_set_cleanup: GIMPLE_TRY. (line 38) 51366* gimple_try_set_eval: GIMPLE_TRY. (line 34) 51367* gimple_use_ops: Manipulating GIMPLE statements. 51368 (line 100) 51369* gimple_vdef_ops: Manipulating GIMPLE statements. 51370 (line 114) 51371* gimple_visited_p: Manipulating GIMPLE statements. 51372 (line 57) 51373* gimple_vuse_ops: Manipulating GIMPLE statements. 51374 (line 107) 51375* gimple_wce_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 51376 (line 10) 51377* gimple_wce_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 51378 (line 17) 51379* gimple_wce_set_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 51380 (line 13) 51381* gimple_wce_set_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 51382 (line 20) 51383* GIMPLE_WITH_CLEANUP_EXPR: GIMPLE_WITH_CLEANUP_EXPR. 51384 (line 6) 51385* gimplification: Parsing pass. (line 13) 51386* gimplification <1>: Gimplification pass. 51387 (line 6) 51388* gimplifier: Parsing pass. (line 13) 51389* gimplify_assign: GIMPLE_ASSIGN. (line 41) 51390* gimplify_expr: Gimplification pass. 51391 (line 18) 51392* gimplify_function_tree: Gimplification pass. 51393 (line 18) 51394* GLOBAL_INIT_PRIORITY: Functions for C++. (line 141) 51395* global_regs: Register Basics. (line 63) 51396* GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 90) 51397* greater than: Comparisons. (line 60) 51398* greater than <1>: Comparisons. (line 64) 51399* greater than <2>: Comparisons. (line 72) 51400* gsi_after_labels: Sequence iterators. (line 74) 51401* gsi_bb: Sequence iterators. (line 82) 51402* gsi_commit_edge_inserts: Sequence iterators. (line 193) 51403* gsi_commit_edge_inserts <1>: Maintaining the CFG. 51404 (line 104) 51405* gsi_commit_one_edge_insert: Sequence iterators. (line 188) 51406* gsi_end_p: Sequence iterators. (line 59) 51407* gsi_end_p <1>: Maintaining the CFG. 51408 (line 48) 51409* gsi_for_stmt: Sequence iterators. (line 156) 51410* gsi_insert_after: Sequence iterators. (line 145) 51411* gsi_insert_after <1>: Maintaining the CFG. 51412 (line 60) 51413* gsi_insert_before: Sequence iterators. (line 134) 51414* gsi_insert_before <1>: Maintaining the CFG. 51415 (line 66) 51416* gsi_insert_on_edge: Sequence iterators. (line 173) 51417* gsi_insert_on_edge <1>: Maintaining the CFG. 51418 (line 104) 51419* gsi_insert_on_edge_immediate: Sequence iterators. (line 183) 51420* gsi_insert_seq_after: Sequence iterators. (line 152) 51421* gsi_insert_seq_before: Sequence iterators. (line 141) 51422* gsi_insert_seq_on_edge: Sequence iterators. (line 177) 51423* gsi_last: Sequence iterators. (line 49) 51424* gsi_last <1>: Maintaining the CFG. 51425 (line 44) 51426* gsi_last_bb: Sequence iterators. (line 55) 51427* gsi_link_after: Sequence iterators. (line 113) 51428* gsi_link_before: Sequence iterators. (line 103) 51429* gsi_link_seq_after: Sequence iterators. (line 108) 51430* gsi_link_seq_before: Sequence iterators. (line 97) 51431* gsi_move_after: Sequence iterators. (line 159) 51432* gsi_move_before: Sequence iterators. (line 164) 51433* gsi_move_to_bb_end: Sequence iterators. (line 169) 51434* gsi_next: Sequence iterators. (line 65) 51435* gsi_next <1>: Maintaining the CFG. 51436 (line 52) 51437* gsi_one_before_end_p: Sequence iterators. (line 62) 51438* gsi_prev: Sequence iterators. (line 68) 51439* gsi_prev <1>: Maintaining the CFG. 51440 (line 56) 51441* gsi_remove: Sequence iterators. (line 88) 51442* gsi_remove <1>: Maintaining the CFG. 51443 (line 72) 51444* gsi_replace: Sequence iterators. (line 128) 51445* gsi_seq: Sequence iterators. (line 85) 51446* gsi_split_seq_after: Sequence iterators. (line 118) 51447* gsi_split_seq_before: Sequence iterators. (line 123) 51448* gsi_start: Sequence iterators. (line 39) 51449* gsi_start <1>: Maintaining the CFG. 51450 (line 40) 51451* gsi_start_bb: Sequence iterators. (line 45) 51452* gsi_stmt: Sequence iterators. (line 71) 51453* gsi_stmt_ptr: Sequence iterators. (line 79) 51454* gt: Comparisons. (line 60) 51455* gt and attributes: Expressions. (line 83) 51456* gtu: Comparisons. (line 64) 51457* gtu and attributes: Expressions. (line 83) 51458* GTY: Type Information. (line 6) 51459* GT_EXPR: Unary and Binary Expressions. 51460 (line 6) 51461* H in constraint: Simple Constraints. (line 96) 51462* HAmode: Machine Modes. (line 146) 51463* HANDLER: Statements for C++. (line 6) 51464* HANDLER_BODY: Statements for C++. (line 6) 51465* HANDLER_PARMS: Statements for C++. (line 6) 51466* HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 464) 51467* hard registers: Regs and Memory. (line 9) 51468* HARD_FRAME_POINTER_IS_ARG_POINTER: Frame Registers. (line 57) 51469* HARD_FRAME_POINTER_IS_FRAME_POINTER: Frame Registers. (line 50) 51470* HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 19) 51471* HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 10) 51472* HARD_REGNO_NREGS_HAS_PADDING: Values in Registers. 51473 (line 21) 51474* HARD_REGNO_NREGS_WITH_PADDING: Values in Registers. 51475 (line 39) 51476* HARD_REGNO_RENAME_OK: Values in Registers. 51477 (line 113) 51478* HAS_INIT_SECTION: Macros for Initialization. 51479 (line 18) 51480* HAS_LONG_COND_BRANCH: Misc. (line 8) 51481* HAS_LONG_UNCOND_BRANCH: Misc. (line 17) 51482* HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11) 51483* HAVE_POST_DECREMENT: Addressing Modes. (line 11) 51484* HAVE_POST_INCREMENT: Addressing Modes. (line 10) 51485* HAVE_POST_MODIFY_DISP: Addressing Modes. (line 17) 51486* HAVE_POST_MODIFY_REG: Addressing Modes. (line 23) 51487* HAVE_PRE_DECREMENT: Addressing Modes. (line 9) 51488* HAVE_PRE_INCREMENT: Addressing Modes. (line 8) 51489* HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 16) 51490* HAVE_PRE_MODIFY_REG: Addressing Modes. (line 22) 51491* HCmode: Machine Modes. (line 199) 51492* HFmode: Machine Modes. (line 61) 51493* high: Constants. (line 220) 51494* HImode: Machine Modes. (line 29) 51495* HImode, in insn: Insns. (line 291) 51496* HONOR_REG_ALLOC_ORDER: Allocation Order. (line 36) 51497* host configuration: Host Config. (line 6) 51498* host functions: Host Common. (line 6) 51499* host hooks: Host Common. (line 6) 51500* host makefile fragment: Host Fragment. (line 6) 51501* HOST_BIT_BUCKET: Filesystem. (line 51) 51502* HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45) 51503* HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 11) 51504* HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 43) 51505* HOST_HOOKS_GT_PCH_GET_ADDRESS: Host Common. (line 15) 51506* HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 24) 51507* HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89) 51508* HOST_LONG_FORMAT: Host Misc. (line 45) 51509* HOST_LONG_LONG_FORMAT: Host Misc. (line 41) 51510* HOST_OBJECT_SUFFIX: Filesystem. (line 40) 51511* HOST_PTR_PRINTF: Host Misc. (line 49) 51512* HOT_TEXT_SECTION_NAME: Sections. (line 42) 51513* HQmode: Machine Modes. (line 110) 51514* i in constraint: Simple Constraints. (line 68) 51515* I in constraint: Simple Constraints. (line 79) 51516* identifier: Identifiers. (line 6) 51517* IDENTIFIER_LENGTH: Identifiers. (line 22) 51518* IDENTIFIER_NODE: Identifiers. (line 6) 51519* IDENTIFIER_OPNAME_P: Identifiers. (line 27) 51520* IDENTIFIER_POINTER: Identifiers. (line 17) 51521* IDENTIFIER_TYPENAME_P: Identifiers. (line 33) 51522* IEEE 754-2008: Decimal float library routines. 51523 (line 6) 51524* IFCVT_MACHDEP_INIT: Misc. (line 590) 51525* IFCVT_MODIFY_CANCEL: Misc. (line 584) 51526* IFCVT_MODIFY_FINAL: Misc. (line 578) 51527* IFCVT_MODIFY_INSN: Misc. (line 572) 51528* IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 564) 51529* IFCVT_MODIFY_TESTS: Misc. (line 554) 51530* IF_COND: Statements for C++. (line 6) 51531* IF_STMT: Statements for C++. (line 6) 51532* if_then_else: Comparisons. (line 80) 51533* if_then_else and attributes: Expressions. (line 32) 51534* if_then_else usage: Side Effects. (line 56) 51535* IMAGPART_EXPR: Unary and Binary Expressions. 51536 (line 6) 51537* Immediate Uses: SSA Operands. (line 258) 51538* immediate_operand: Machine-Independent Predicates. 51539 (line 10) 51540* IMMEDIATE_PREFIX: Instruction Output. (line 153) 51541* include: Including Patterns. (line 6) 51542* INCLUDE_DEFAULTS: Driver. (line 331) 51543* inclusive-or, bitwise: Arithmetic. (line 163) 51544* INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 188) 51545* INCOMING_REGNO: Register Basics. (line 90) 51546* INCOMING_REG_PARM_STACK_SPACE: Stack Arguments. (line 73) 51547* INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 133) 51548* INCOMING_STACK_BOUNDARY: Storage Layout. (line 171) 51549* INDEX_REG_CLASS: Register Classes. (line 140) 51550* indirect_jump instruction pattern: Standard Names. (line 1638) 51551* indirect_operand: Machine-Independent Predicates. 51552 (line 70) 51553* INDIRECT_REF: Storage References. (line 6) 51554* initialization routines: Initialization. (line 6) 51555* INITIAL_ELIMINATION_OFFSET: Elimination. (line 68) 51556* INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 75) 51557* INIT_ARRAY_SECTION_ASM_OP: Sections. (line 106) 51558* INIT_CUMULATIVE_ARGS: Register Arguments. (line 165) 51559* INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 193) 51560* INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 187) 51561* INIT_ENVIRONMENT: Driver. (line 309) 51562* INIT_EXPANDERS: Per-Function Data. (line 36) 51563* INIT_EXPR: Unary and Binary Expressions. 51564 (line 6) 51565* init_machine_status: Per-Function Data. (line 42) 51566* init_one_libfunc: Library Calls. (line 15) 51567* INIT_SECTION_ASM_OP: Sections. (line 90) 51568* INIT_SECTION_ASM_OP <1>: Macros for Initialization. 51569 (line 9) 51570* inlining: Target Attributes. (line 95) 51571* insert_insn_on_edge: Maintaining the CFG. 51572 (line 104) 51573* insn: Insns. (line 63) 51574* insn and /f: Flags. (line 135) 51575* insn and /j: Flags. (line 171) 51576* insn and /s: Flags. (line 38) 51577* insn and /s <1>: Flags. (line 162) 51578* insn and /u: Flags. (line 28) 51579* insn and /v: Flags. (line 33) 51580* insn attributes: Insn Attributes. (line 6) 51581* insn canonicalization: Insn Canonicalizations. 51582 (line 6) 51583* insn includes: Including Patterns. (line 6) 51584* insn lengths, computing: Insn Lengths. (line 6) 51585* insn notes, notes: Basic Blocks. (line 52) 51586* insn splitting: Insn Splitting. (line 6) 51587* insn-attr.h: Defining Attributes. 51588 (line 34) 51589* insns: Insns. (line 6) 51590* insns, generating: RTL Template. (line 6) 51591* insns, recognizing: RTL Template. (line 6) 51592* INSN_ANNULLED_BRANCH_P: Flags. (line 28) 51593* INSN_CODE: Insns. (line 318) 51594* INSN_DELETED_P: Flags. (line 33) 51595* INSN_FROM_TARGET_P: Flags. (line 38) 51596* insn_list: Insns. (line 568) 51597* INSN_REFERENCES_ARE_DELAYED: Misc. (line 491) 51598* INSN_SETS_ARE_DELAYED: Misc. (line 480) 51599* INSN_UID: Insns. (line 23) 51600* INSN_VAR_LOCATION: Insns. (line 247) 51601* instruction attributes: Insn Attributes. (line 6) 51602* instruction latency time: Processor pipeline description. 51603 (line 6) 51604* instruction latency time <1>: Processor pipeline description. 51605 (line 105) 51606* instruction latency time <2>: Processor pipeline description. 51607 (line 196) 51608* instruction patterns: Patterns. (line 6) 51609* instruction splitting: Insn Splitting. (line 6) 51610* insv instruction pattern: Standard Names. (line 1398) 51611* insvM instruction pattern: Standard Names. (line 1350) 51612* insvmisalignM instruction pattern: Standard Names. (line 1360) 51613* int iterators in .md files: Int Iterators. (line 6) 51614* INT16_TYPE: Type Layout. (line 210) 51615* INT32_TYPE: Type Layout. (line 211) 51616* INT64_TYPE: Type Layout. (line 212) 51617* INT8_TYPE: Type Layout. (line 209) 51618* INTEGER_CST: Constant expressions. 51619 (line 6) 51620* INTEGER_TYPE: Types. (line 6) 51621* Interdependence of Patterns: Dependent Patterns. (line 6) 51622* interfacing to GCC output: Interface. (line 6) 51623* interlock delays: Processor pipeline description. 51624 (line 6) 51625* intermediate representation lowering: Parsing pass. (line 13) 51626* INTMAX_TYPE: Type Layout. (line 186) 51627* INTPTR_TYPE: Type Layout. (line 233) 51628* introduction: Top. (line 6) 51629* INT_FAST16_TYPE: Type Layout. (line 226) 51630* INT_FAST32_TYPE: Type Layout. (line 227) 51631* INT_FAST64_TYPE: Type Layout. (line 228) 51632* INT_FAST8_TYPE: Type Layout. (line 225) 51633* INT_LEAST16_TYPE: Type Layout. (line 218) 51634* INT_LEAST32_TYPE: Type Layout. (line 219) 51635* INT_LEAST64_TYPE: Type Layout. (line 220) 51636* INT_LEAST8_TYPE: Type Layout. (line 217) 51637* INT_TYPE_SIZE: Type Layout. (line 11) 51638* INVOKE__main: Macros for Initialization. 51639 (line 50) 51640* in_struct: Flags. (line 254) 51641* in_struct, in code_label and note: Flags. (line 48) 51642* in_struct, in insn and jump_insn and call_insn: Flags. (line 38) 51643* in_struct, in insn, call_insn, jump_insn and jump_table_data: Flags. 51644 (line 162) 51645* in_struct, in subreg: Flags. (line 201) 51646* ior: Arithmetic. (line 163) 51647* ior and attributes: Expressions. (line 50) 51648* ior, canonicalization of: Insn Canonicalizations. 51649 (line 67) 51650* iorM3 instruction pattern: Standard Names. (line 416) 51651* IRA_HARD_REGNO_ADD_COST_MULTIPLIER: Allocation Order. (line 44) 51652* is_a: Machine Modes. (line 351) 51653* IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 123) 51654* is_gimple_addressable: Logical Operators. (line 113) 51655* is_gimple_asm_val: Logical Operators. (line 117) 51656* is_gimple_assign: Logical Operators. (line 149) 51657* is_gimple_call: Logical Operators. (line 152) 51658* is_gimple_call_addr: Logical Operators. (line 120) 51659* is_gimple_constant: Logical Operators. (line 128) 51660* is_gimple_debug: Logical Operators. (line 155) 51661* is_gimple_ip_invariant: Logical Operators. (line 137) 51662* is_gimple_ip_invariant_address: Logical Operators. (line 142) 51663* is_gimple_mem_ref_addr: Logical Operators. (line 124) 51664* is_gimple_min_invariant: Logical Operators. (line 131) 51665* is_gimple_omp: Logical Operators. (line 166) 51666* is_gimple_val: Logical Operators. (line 107) 51667* iterators in .md files: Iterators. (line 6) 51668* IV analysis on GIMPLE: Scalar evolutions. (line 6) 51669* IV analysis on RTL: loop-iv. (line 6) 51670* JMP_BUF_SIZE: Exception Region Output. 51671 (line 83) 51672* jump: Flags. (line 295) 51673* jump instruction pattern: Standard Names. (line 1516) 51674* jump instruction patterns: Jump Patterns. (line 6) 51675* jump instructions and set: Side Effects. (line 56) 51676* jump, in call_insn: Flags. (line 175) 51677* jump, in insn: Flags. (line 171) 51678* jump, in mem: Flags. (line 59) 51679* Jumps: Jumps. (line 6) 51680* JUMP_ALIGN: Alignment Output. (line 8) 51681* jump_insn: Insns. (line 73) 51682* jump_insn and /f: Flags. (line 135) 51683* jump_insn and /j: Flags. (line 10) 51684* jump_insn and /s: Flags. (line 38) 51685* jump_insn and /s <1>: Flags. (line 162) 51686* jump_insn and /u: Flags. (line 28) 51687* jump_insn and /v: Flags. (line 33) 51688* JUMP_LABEL: Insns. (line 80) 51689* JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 155) 51690* jump_table_data: Insns. (line 166) 51691* jump_table_data and /s: Flags. (line 162) 51692* jump_table_data and /v: Flags. (line 33) 51693* LABEL_ALIGN: Alignment Output. (line 57) 51694* LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 26) 51695* LABEL_ALTERNATE_NAME: Edges. (line 180) 51696* LABEL_ALT_ENTRY_P: Insns. (line 146) 51697* LABEL_DECL: Declarations. (line 6) 51698* LABEL_KIND: Insns. (line 146) 51699* LABEL_NUSES: Insns. (line 142) 51700* LABEL_PRESERVE_P: Flags. (line 48) 51701* label_ref: Constants. (line 199) 51702* label_ref and /v: Flags. (line 54) 51703* label_ref, RTL sharing: Sharing. (line 38) 51704* LABEL_REF_NONLOCAL_P: Flags. (line 54) 51705* language-dependent trees: Language-dependent trees. 51706 (line 6) 51707* language-independent intermediate representation: Parsing pass. 51708 (line 13) 51709* lang_hooks.gimplify_expr: Gimplification pass. 51710 (line 18) 51711* lang_hooks.parse_file: Parsing pass. (line 6) 51712* large return values: Aggregate Return. (line 6) 51713* LAST_STACK_REG: Stack Registers. (line 30) 51714* LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 51715* lceilMN2: Standard Names. (line 1019) 51716* LCSSA: LCSSA. (line 6) 51717* LDD_SUFFIX: Macros for Initialization. 51718 (line 121) 51719* ldexpM3 instruction pattern: Standard Names. (line 804) 51720* LD_FINI_SWITCH: Macros for Initialization. 51721 (line 28) 51722* LD_INIT_SWITCH: Macros for Initialization. 51723 (line 24) 51724* le: Comparisons. (line 76) 51725* le and attributes: Expressions. (line 83) 51726* leaf functions: Leaf Functions. (line 6) 51727* leaf_function_p: Standard Names. (line 1600) 51728* LEAF_REGISTERS: Leaf Functions. (line 23) 51729* LEAF_REG_REMAP: Leaf Functions. (line 37) 51730* left rotate: Arithmetic. (line 195) 51731* left shift: Arithmetic. (line 173) 51732* LEGITIMATE_PIC_OPERAND_P: PIC. (line 31) 51733* LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 150) 51734* length: GTY Options. (line 47) 51735* less than: Comparisons. (line 68) 51736* less than or equal: Comparisons. (line 76) 51737* leu: Comparisons. (line 76) 51738* leu and attributes: Expressions. (line 83) 51739* LE_EXPR: Unary and Binary Expressions. 51740 (line 6) 51741* lfloorMN2: Standard Names. (line 1014) 51742* LIB2FUNCS_EXTRA: Target Fragment. (line 11) 51743* LIBCALL_VALUE: Scalar Return. (line 56) 51744* libgcc.a: Library Calls. (line 6) 51745* LIBGCC2_CFLAGS: Target Fragment. (line 8) 51746* LIBGCC2_GNU_PREFIX: Type Layout. (line 102) 51747* LIBGCC2_UNWIND_ATTRIBUTE: Misc. (line 1093) 51748* LIBGCC_SPEC: Driver. (line 115) 51749* library subroutine names: Library Calls. (line 6) 51750* LIBRARY_PATH_ENV: Misc. (line 532) 51751* LIB_SPEC: Driver. (line 107) 51752* LIMIT_RELOAD_CLASS: Register Classes. (line 296) 51753* LINK_COMMAND_SPEC: Driver. (line 240) 51754* LINK_EH_SPEC: Driver. (line 142) 51755* LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 232) 51756* LINK_LIBGCC_SPECIAL_1: Driver. (line 227) 51757* LINK_SPEC: Driver. (line 100) 51758* list: Containers. (line 6) 51759* Liveness representation: Liveness information. 51760 (line 6) 51761* load address instruction: Simple Constraints. (line 162) 51762* LOAD_EXTEND_OP: Misc. (line 80) 51763* load_multiple instruction pattern: Standard Names. (line 136) 51764* Local Register Allocator (LRA): RTL passes. (line 187) 51765* LOCAL_ALIGNMENT: Storage Layout. (line 281) 51766* LOCAL_CLASS_P: Classes. (line 70) 51767* LOCAL_DECL_ALIGNMENT: Storage Layout. (line 318) 51768* LOCAL_INCLUDE_DIR: Driver. (line 316) 51769* LOCAL_LABEL_PREFIX: Instruction Output. (line 151) 51770* LOCAL_REGNO: Register Basics. (line 104) 51771* log10M2 instruction pattern: Standard Names. (line 908) 51772* log1pM2 instruction pattern: Standard Names. (line 898) 51773* log2M2 instruction pattern: Standard Names. (line 915) 51774* logbM2 instruction pattern: Standard Names. (line 922) 51775* Logical Operators: Logical Operators. (line 6) 51776* logical-and, bitwise: Arithmetic. (line 158) 51777* LOGICAL_OP_NON_SHORT_CIRCUIT: Costs. (line 294) 51778* logM2 instruction pattern: Standard Names. (line 891) 51779* LOG_LINKS: Insns. (line 337) 51780* longjmp and automatic variables: Interface. (line 52) 51781* LONG_ACCUM_TYPE_SIZE: Type Layout. (line 92) 51782* LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 57) 51783* LONG_FRACT_TYPE_SIZE: Type Layout. (line 72) 51784* LONG_LONG_ACCUM_TYPE_SIZE: Type Layout. (line 97) 51785* LONG_LONG_FRACT_TYPE_SIZE: Type Layout. (line 77) 51786* LONG_LONG_TYPE_SIZE: Type Layout. (line 32) 51787* LONG_TYPE_SIZE: Type Layout. (line 21) 51788* Loop analysis: Loop representation. 51789 (line 6) 51790* Loop manipulation: Loop manipulation. (line 6) 51791* Loop querying: Loop querying. (line 6) 51792* Loop representation: Loop representation. 51793 (line 6) 51794* Loop-closed SSA form: LCSSA. (line 6) 51795* looping instruction patterns: Looping Patterns. (line 6) 51796* LOOP_ALIGN: Alignment Output. (line 40) 51797* LOOP_EXPR: Unary and Binary Expressions. 51798 (line 6) 51799* lowering, language-dependent intermediate representation: Parsing pass. 51800 (line 13) 51801* lo_sum: Arithmetic. (line 25) 51802* lrintMN2: Standard Names. (line 1004) 51803* lroundMN2: Standard Names. (line 1009) 51804* lshiftrt: Arithmetic. (line 190) 51805* lshiftrt and attributes: Expressions. (line 83) 51806* LSHIFT_EXPR: Unary and Binary Expressions. 51807 (line 6) 51808* lshrM3 instruction pattern: Standard Names. (line 742) 51809* lt: Comparisons. (line 68) 51810* lt and attributes: Expressions. (line 83) 51811* LTGT_EXPR: Unary and Binary Expressions. 51812 (line 6) 51813* lto: LTO. (line 6) 51814* ltrans: LTO. (line 6) 51815* ltu: Comparisons. (line 68) 51816* LT_EXPR: Unary and Binary Expressions. 51817 (line 6) 51818* m in constraint: Simple Constraints. (line 17) 51819* machine attributes: Target Attributes. (line 6) 51820* machine description macros: Target Macros. (line 6) 51821* machine descriptions: Machine Desc. (line 6) 51822* machine mode conversions: Conversions. (line 6) 51823* machine mode wrapper classes: Machine Modes. (line 290) 51824* machine modes: Machine Modes. (line 6) 51825* machine specific constraints: Machine Constraints. 51826 (line 6) 51827* machine-independent predicates: Machine-Independent Predicates. 51828 (line 6) 51829* machine_mode: Machine Modes. (line 6) 51830* MACH_DEP_SECTION_ASM_FLAG: Sections. (line 120) 51831* macros, target description: Target Macros. (line 6) 51832* maddMN4 instruction pattern: Standard Names. (line 663) 51833* makefile fragment: Fragments. (line 6) 51834* makefile targets: Makefile. (line 6) 51835* MAKE_DECL_ONE_ONLY: Label Output. (line 281) 51836* make_safe_from: Expander Definitions. 51837 (line 151) 51838* MALLOC_ABI_ALIGNMENT: Storage Layout. (line 190) 51839* Manipulating GIMPLE statements: Manipulating GIMPLE statements. 51840 (line 6) 51841* marking roots: GGC Roots. (line 6) 51842* maskloadMN instruction pattern: Standard Names. (line 370) 51843* maskstoreMN instruction pattern: Standard Names. (line 377) 51844* mask_gather_loadM instruction pattern: Standard Names. (line 248) 51845* MASK_RETURN_ADDR: Exception Region Output. 51846 (line 35) 51847* mask_scatter_storeM instruction pattern: Standard Names. (line 271) 51848* Match and Simplify: Match and Simplify. (line 6) 51849* matching constraint: Simple Constraints. (line 140) 51850* matching operands: Output Template. (line 49) 51851* match_dup: RTL Template. (line 73) 51852* match_dup <1>: define_peephole2. (line 28) 51853* match_dup and attributes: Insn Lengths. (line 16) 51854* match_operand: RTL Template. (line 16) 51855* match_operand and attributes: Expressions. (line 55) 51856* match_operator: RTL Template. (line 95) 51857* match_op_dup: RTL Template. (line 163) 51858* match_parallel: RTL Template. (line 172) 51859* match_par_dup: RTL Template. (line 219) 51860* match_scratch: RTL Template. (line 58) 51861* match_scratch <1>: define_peephole2. (line 28) 51862* match_test and attributes: Expressions. (line 64) 51863* math library: Soft float library routines. 51864 (line 6) 51865* math, in RTL: Arithmetic. (line 6) 51866* matherr: Library Calls. (line 59) 51867* MATH_LIBRARY: Misc. (line 525) 51868* maxM3 instruction pattern: Standard Names. (line 478) 51869* MAX_BITSIZE_MODE_ANY_INT: Machine Modes. (line 448) 51870* MAX_BITSIZE_MODE_ANY_MODE: Machine Modes. (line 454) 51871* MAX_BITS_PER_WORD: Storage Layout. (line 54) 51872* MAX_CONDITIONAL_EXECUTE: Misc. (line 547) 51873* MAX_FIXED_MODE_SIZE: Storage Layout. (line 463) 51874* MAX_MOVE_MAX: Misc. (line 127) 51875* MAX_OFILE_ALIGNMENT: Storage Layout. (line 228) 51876* MAX_REGS_PER_ADDRESS: Addressing Modes. (line 42) 51877* MAX_STACK_ALIGNMENT: Storage Layout. (line 222) 51878* maybe_undef: GTY Options. (line 141) 51879* may_trap_p, tree_could_trap_p: Edges. (line 114) 51880* mcount: Profiling. (line 12) 51881* MD_EXEC_PREFIX: Driver. (line 271) 51882* MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 93) 51883* MD_HANDLE_UNWABI: Exception Handling. (line 112) 51884* MD_STARTFILE_PREFIX: Driver. (line 299) 51885* MD_STARTFILE_PREFIX_1: Driver. (line 304) 51886* mem: Regs and Memory. (line 396) 51887* mem and /c: Flags. (line 70) 51888* mem and /f: Flags. (line 74) 51889* mem and /j: Flags. (line 59) 51890* mem and /u: Flags. (line 78) 51891* mem and /v: Flags. (line 65) 51892* mem, RTL sharing: Sharing. (line 43) 51893* memory model: Memory model. (line 6) 51894* memory reference, nonoffsettable: Simple Constraints. (line 254) 51895* memory references in constraints: Simple Constraints. (line 17) 51896* memory_barrier instruction pattern: Standard Names. (line 1994) 51897* memory_blockage instruction pattern: Standard Names. (line 1985) 51898* MEMORY_MOVE_COST: Costs. (line 53) 51899* memory_operand: Machine-Independent Predicates. 51900 (line 57) 51901* MEM_ADDR_SPACE: Special Accessors. (line 48) 51902* MEM_ALIAS_SET: Special Accessors. (line 9) 51903* MEM_ALIGN: Special Accessors. (line 45) 51904* MEM_EXPR: Special Accessors. (line 19) 51905* MEM_KEEP_ALIAS_SET_P: Flags. (line 59) 51906* MEM_NOTRAP_P: Flags. (line 70) 51907* MEM_OFFSET: Special Accessors. (line 31) 51908* MEM_OFFSET_KNOWN_P: Special Accessors. (line 27) 51909* MEM_POINTER: Flags. (line 74) 51910* MEM_READONLY_P: Flags. (line 78) 51911* MEM_REF: Storage References. (line 6) 51912* MEM_SIZE: Special Accessors. (line 39) 51913* MEM_SIZE_KNOWN_P: Special Accessors. (line 35) 51914* mem_thread_fence instruction pattern: Standard Names. (line 2270) 51915* MEM_VOLATILE_P: Flags. (line 65) 51916* METHOD_TYPE: Types. (line 6) 51917* MINIMUM_ALIGNMENT: Storage Layout. (line 331) 51918* MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 198) 51919* minM3 instruction pattern: Standard Names. (line 478) 51920* minus: Arithmetic. (line 38) 51921* minus and attributes: Expressions. (line 83) 51922* minus, canonicalization of: Insn Canonicalizations. 51923 (line 27) 51924* MINUS_EXPR: Unary and Binary Expressions. 51925 (line 6) 51926* MIN_UNITS_PER_WORD: Storage Layout. (line 64) 51927* MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6) 51928* miscellaneous register hooks: Miscellaneous Register Hooks. 51929 (line 6) 51930* mnemonic attribute: Mnemonic Attribute. (line 6) 51931* mod: Arithmetic. (line 136) 51932* mod and attributes: Expressions. (line 83) 51933* mode classes: Machine Modes. (line 226) 51934* mode iterators in .md files: Mode Iterators. (line 6) 51935* mode switching: Mode Switching. (line 6) 51936* MODE_ACCUM: Machine Modes. (line 256) 51937* MODE_BASE_REG_CLASS: Register Classes. (line 116) 51938* MODE_BASE_REG_REG_CLASS: Register Classes. (line 122) 51939* MODE_CC: Machine Modes. (line 275) 51940* MODE_CC <1>: MODE_CC Condition Codes. 51941 (line 6) 51942* MODE_CODE_BASE_REG_CLASS: Register Classes. (line 129) 51943* MODE_COMPLEX_FLOAT: Machine Modes. (line 267) 51944* MODE_COMPLEX_INT: Machine Modes. (line 264) 51945* MODE_DECIMAL_FLOAT: Machine Modes. (line 244) 51946* MODE_FLOAT: Machine Modes. (line 240) 51947* MODE_FRACT: Machine Modes. (line 248) 51948* MODE_FUNCTION: Machine Modes. (line 271) 51949* MODE_INT: Machine Modes. (line 232) 51950* MODE_PARTIAL_INT: Machine Modes. (line 236) 51951* MODE_POINTER_BOUNDS: Machine Modes. (line 280) 51952* MODE_RANDOM: Machine Modes. (line 285) 51953* MODE_UACCUM: Machine Modes. (line 260) 51954* MODE_UFRACT: Machine Modes. (line 252) 51955* modifiers in constraints: Modifiers. (line 6) 51956* MODIFY_EXPR: Unary and Binary Expressions. 51957 (line 6) 51958* MODIFY_JNI_METHOD_CALL: Misc. (line 896) 51959* modM3 instruction pattern: Standard Names. (line 416) 51960* modulo scheduling: RTL passes. (line 123) 51961* MOVE_MAX: Misc. (line 122) 51962* MOVE_MAX_PIECES: Costs. (line 210) 51963* MOVE_RATIO: Costs. (line 149) 51964* movM instruction pattern: Standard Names. (line 11) 51965* movmemM instruction pattern: Standard Names. (line 1118) 51966* movmisalignM instruction pattern: Standard Names. (line 125) 51967* movMODEcc instruction pattern: Standard Names. (line 1412) 51968* movstr instruction pattern: Standard Names. (line 1153) 51969* movstrictM instruction pattern: Standard Names. (line 119) 51970* msubMN4 instruction pattern: Standard Names. (line 686) 51971* mulhisi3 instruction pattern: Standard Names. (line 639) 51972* mulM3 instruction pattern: Standard Names. (line 416) 51973* mulqihi3 instruction pattern: Standard Names. (line 643) 51974* mulsidi3 instruction pattern: Standard Names. (line 643) 51975* mult: Arithmetic. (line 93) 51976* mult and attributes: Expressions. (line 83) 51977* mult, canonicalization of: Insn Canonicalizations. 51978 (line 27) 51979* mult, canonicalization of <1>: Insn Canonicalizations. 51980 (line 107) 51981* MULTIARCH_DIRNAME: Target Fragment. (line 173) 51982* MULTILIB_DEFAULTS: Driver. (line 256) 51983* MULTILIB_DIRNAMES: Target Fragment. (line 44) 51984* MULTILIB_EXCEPTIONS: Target Fragment. (line 70) 51985* MULTILIB_EXTRA_OPTS: Target Fragment. (line 135) 51986* MULTILIB_MATCHES: Target Fragment. (line 63) 51987* MULTILIB_OPTIONS: Target Fragment. (line 24) 51988* MULTILIB_OSDIRNAMES: Target Fragment. (line 142) 51989* MULTILIB_REQUIRED: Target Fragment. (line 82) 51990* MULTILIB_REUSE: Target Fragment. (line 103) 51991* multiple alternative constraints: Multi-Alternative. (line 6) 51992* MULTIPLE_SYMBOL_SPACES: Misc. (line 504) 51993* multiplication: Arithmetic. (line 93) 51994* multiplication with signed saturation: Arithmetic. (line 93) 51995* multiplication with unsigned saturation: Arithmetic. (line 93) 51996* MULT_EXPR: Unary and Binary Expressions. 51997 (line 6) 51998* MULT_HIGHPART_EXPR: Unary and Binary Expressions. 51999 (line 6) 52000* mulvM4 instruction pattern: Standard Names. (line 432) 52001* n in constraint: Simple Constraints. (line 73) 52002* name: Identifiers. (line 6) 52003* named address spaces: Named Address Spaces. 52004 (line 6) 52005* named patterns and conditions: Patterns. (line 49) 52006* names, pattern: Standard Names. (line 6) 52007* namespace, scope: Namespaces. (line 6) 52008* NAMESPACE_DECL: Declarations. (line 6) 52009* NAMESPACE_DECL <1>: Namespaces. (line 6) 52010* NATIVE_SYSTEM_HEADER_COMPONENT: Driver. (line 326) 52011* ne: Comparisons. (line 56) 52012* ne and attributes: Expressions. (line 83) 52013* nearbyintM2 instruction pattern: Standard Names. (line 988) 52014* neg: Arithmetic. (line 82) 52015* neg and attributes: Expressions. (line 83) 52016* neg, canonicalization of: Insn Canonicalizations. 52017 (line 27) 52018* NEGATE_EXPR: Unary and Binary Expressions. 52019 (line 6) 52020* negation: Arithmetic. (line 82) 52021* negation with signed saturation: Arithmetic. (line 82) 52022* negation with unsigned saturation: Arithmetic. (line 82) 52023* negM2 instruction pattern: Standard Names. (line 754) 52024* negMODEcc instruction pattern: Standard Names. (line 1457) 52025* negvM3 instruction pattern: Standard Names. (line 757) 52026* nested functions, trampolines for: Trampolines. (line 6) 52027* nested_ptr: GTY Options. (line 149) 52028* next_bb, prev_bb, FOR_EACH_BB, FOR_ALL_BB: Basic Blocks. (line 25) 52029* NEXT_INSN: Insns. (line 30) 52030* NEXT_OBJC_RUNTIME: Library Calls. (line 82) 52031* NE_EXPR: Unary and Binary Expressions. 52032 (line 6) 52033* nil: RTL Objects. (line 73) 52034* NM_FLAGS: Macros for Initialization. 52035 (line 110) 52036* nondeterministic finite state automaton: Processor pipeline description. 52037 (line 304) 52038* nonimmediate_operand: Machine-Independent Predicates. 52039 (line 100) 52040* nonlocal goto handler: Edges. (line 171) 52041* nonlocal_goto instruction pattern: Standard Names. (line 1820) 52042* nonlocal_goto_receiver instruction pattern: Standard Names. 52043 (line 1837) 52044* nonmemory_operand: Machine-Independent Predicates. 52045 (line 96) 52046* nonoffsettable memory reference: Simple Constraints. (line 254) 52047* NON_LVALUE_EXPR: Unary and Binary Expressions. 52048 (line 6) 52049* nop instruction pattern: Standard Names. (line 1633) 52050* NOP_EXPR: Unary and Binary Expressions. 52051 (line 6) 52052* normal predicates: Predicates. (line 31) 52053* not: Arithmetic. (line 154) 52054* not and attributes: Expressions. (line 50) 52055* not equal: Comparisons. (line 56) 52056* not, canonicalization of: Insn Canonicalizations. 52057 (line 27) 52058* note: Insns. (line 183) 52059* note and /i: Flags. (line 48) 52060* note and /v: Flags. (line 33) 52061* NOTE_INSN_BASIC_BLOCK: Basic Blocks. (line 50) 52062* NOTE_INSN_BASIC_BLOCK <1>: Basic Blocks. (line 52) 52063* NOTE_INSN_BEGIN_STMT: Insns. (line 233) 52064* NOTE_INSN_BLOCK_BEG: Insns. (line 208) 52065* NOTE_INSN_BLOCK_END: Insns. (line 208) 52066* NOTE_INSN_DELETED: Insns. (line 198) 52067* NOTE_INSN_DELETED_LABEL: Insns. (line 203) 52068* NOTE_INSN_EH_REGION_BEG: Insns. (line 214) 52069* NOTE_INSN_EH_REGION_END: Insns. (line 214) 52070* NOTE_INSN_FUNCTION_BEG: Insns. (line 221) 52071* NOTE_INSN_INLINE_ENTRY: Insns. (line 238) 52072* NOTE_INSN_VAR_LOCATION: Insns. (line 225) 52073* NOTE_LINE_NUMBER: Insns. (line 183) 52074* NOTE_SOURCE_FILE: Insns. (line 183) 52075* NOTE_VAR_LOCATION: Insns. (line 225) 52076* NOTICE_UPDATE_CC: CC0 Condition Codes. 52077 (line 30) 52078* notMODEcc instruction pattern: Standard Names. (line 1464) 52079* NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 25) 52080* NO_DBX_FUNCTION_END: DBX Hooks. (line 19) 52081* NO_DBX_GCC_MARKER: File Names and DBX. (line 27) 52082* NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 22) 52083* NO_DOLLAR_IN_LABEL: Label Output. (line 64) 52084* NO_DOT_IN_LABEL: Label Output. (line 70) 52085* NO_FUNCTION_CSE: Costs. (line 289) 52086* NO_IMPLICIT_EXTERN_C: Misc. (line 403) 52087* NO_PROFILE_COUNTERS: Profiling. (line 27) 52088* NO_REGS: Register Classes. (line 17) 52089* Number of iterations analysis: Number of iterations. 52090 (line 6) 52091* NUM_MACHINE_MODES: Machine Modes. (line 387) 52092* NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30) 52093* NUM_POLY_INT_COEFFS: Overview of poly_int. 52094 (line 24) 52095* N_REG_CLASSES: Register Classes. (line 81) 52096* o in constraint: Simple Constraints. (line 23) 52097* OACC_CACHE: OpenACC. (line 6) 52098* OACC_DATA: OpenACC. (line 6) 52099* OACC_DECLARE: OpenACC. (line 6) 52100* OACC_ENTER_DATA: OpenACC. (line 6) 52101* OACC_EXIT_DATA: OpenACC. (line 6) 52102* OACC_HOST_DATA: OpenACC. (line 6) 52103* OACC_KERNELS: OpenACC. (line 6) 52104* OACC_LOOP: OpenACC. (line 6) 52105* OACC_PARALLEL: OpenACC. (line 6) 52106* OACC_UPDATE: OpenACC. (line 6) 52107* OBJC_GEN_METHOD_LABEL: Label Output. (line 482) 52108* OBJC_JBLEN: Misc. (line 1088) 52109* OBJECT_FORMAT_COFF: Macros for Initialization. 52110 (line 96) 52111* offsettable address: Simple Constraints. (line 23) 52112* OFFSET_TYPE: Types. (line 6) 52113* OImode: Machine Modes. (line 51) 52114* OMP_ATOMIC: OpenMP. (line 6) 52115* OMP_CLAUSE: OpenMP. (line 6) 52116* OMP_CONTINUE: OpenMP. (line 6) 52117* OMP_CRITICAL: OpenMP. (line 6) 52118* OMP_FOR: OpenMP. (line 6) 52119* OMP_MASTER: OpenMP. (line 6) 52120* OMP_ORDERED: OpenMP. (line 6) 52121* OMP_PARALLEL: OpenMP. (line 6) 52122* OMP_RETURN: OpenMP. (line 6) 52123* OMP_SECTION: OpenMP. (line 6) 52124* OMP_SECTIONS: OpenMP. (line 6) 52125* OMP_SINGLE: OpenMP. (line 6) 52126* one_cmplM2 instruction pattern: Standard Names. (line 1115) 52127* operand access: Accessors. (line 6) 52128* Operand Access Routines: SSA Operands. (line 116) 52129* operand constraints: Constraints. (line 6) 52130* Operand Iterators: SSA Operands. (line 116) 52131* operand predicates: Predicates. (line 6) 52132* operand substitution: Output Template. (line 6) 52133* Operands: Operands. (line 6) 52134* operands: SSA Operands. (line 6) 52135* operands <1>: Patterns. (line 55) 52136* operator predicates: Predicates. (line 6) 52137* optc-gen.awk: Options. (line 6) 52138* OPTGROUP_ALL: Optimization groups. 52139 (line 28) 52140* OPTGROUP_INLINE: Optimization groups. 52141 (line 15) 52142* OPTGROUP_IPA: Optimization groups. 52143 (line 9) 52144* OPTGROUP_LOOP: Optimization groups. 52145 (line 12) 52146* OPTGROUP_OMP: Optimization groups. 52147 (line 18) 52148* OPTGROUP_OTHER: Optimization groups. 52149 (line 24) 52150* OPTGROUP_VEC: Optimization groups. 52151 (line 21) 52152* optimization dumps: Optimization info. (line 6) 52153* optimization groups: Optimization groups. 52154 (line 6) 52155* optimization info file names: Dump files and streams. 52156 (line 6) 52157* Optimization infrastructure for GIMPLE: Tree SSA. (line 6) 52158* OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 8) 52159* option specification files: Options. (line 6) 52160* optional hardware or system features: Run-time Target. (line 59) 52161* options, directory search: Including Patterns. (line 47) 52162* OPTION_DEFAULT_SPECS: Driver. (line 25) 52163* opt_mode: Machine Modes. (line 326) 52164* order of register allocation: Allocation Order. (line 6) 52165* ordered_comparison_operator: Machine-Independent Predicates. 52166 (line 115) 52167* ORDERED_EXPR: Unary and Binary Expressions. 52168 (line 6) 52169* Ordering of Patterns: Pattern Ordering. (line 6) 52170* ORIGINAL_REGNO: Special Accessors. (line 53) 52171* other register constraints: Simple Constraints. (line 171) 52172* outgoing_args_size: Stack Arguments. (line 48) 52173* OUTGOING_REGNO: Register Basics. (line 97) 52174* OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 79) 52175* output of assembler code: File Framework. (line 6) 52176* output statements: Output Statement. (line 6) 52177* output templates: Output Template. (line 6) 52178* output_asm_insn: Output Statement. (line 52) 52179* OUTPUT_QUOTED_STRING: File Framework. (line 105) 52180* OVERLAPPING_REGISTER_NAMES: Instruction Output. (line 20) 52181* OVERLOAD: Functions for C++. (line 6) 52182* OVERRIDE_ABI_FORMAT: Register Arguments. (line 157) 52183* OVL_CURRENT: Functions for C++. (line 6) 52184* OVL_NEXT: Functions for C++. (line 6) 52185* p in constraint: Simple Constraints. (line 162) 52186* PAD_VARARGS_DOWN: Register Arguments. (line 238) 52187* parallel: Side Effects. (line 210) 52188* parameters, c++ abi: C++ ABI. (line 6) 52189* parameters, miscellaneous: Misc. (line 6) 52190* parameters, precompiled headers: PCH Target. (line 6) 52191* parity: Arithmetic. (line 242) 52192* parityM2 instruction pattern: Standard Names. (line 1102) 52193* PARM_BOUNDARY: Storage Layout. (line 150) 52194* PARM_DECL: Declarations. (line 6) 52195* PARSE_LDD_OUTPUT: Macros for Initialization. 52196 (line 125) 52197* pass dumps: Passes. (line 6) 52198* passes and files of the compiler: Passes. (line 6) 52199* passing arguments: Interface. (line 36) 52200* pass_duplicate_computed_gotos: Edges. (line 161) 52201* PATH_SEPARATOR: Filesystem. (line 31) 52202* PATTERN: Insns. (line 307) 52203* pattern conditions: Patterns. (line 43) 52204* pattern names: Standard Names. (line 6) 52205* Pattern Ordering: Pattern Ordering. (line 6) 52206* patterns: Patterns. (line 6) 52207* pc: Regs and Memory. (line 383) 52208* pc and attributes: Insn Lengths. (line 20) 52209* pc, RTL sharing: Sharing. (line 28) 52210* PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 357) 52211* PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 64) 52212* PC_REGNUM: Register Basics. (line 111) 52213* pc_rtx: Regs and Memory. (line 388) 52214* PDImode: Machine Modes. (line 40) 52215* peephole optimization, RTL representation: Side Effects. (line 244) 52216* peephole optimizer definitions: Peephole Definitions. 52217 (line 6) 52218* per-function data: Per-Function Data. (line 6) 52219* percent sign: Output Template. (line 6) 52220* PHI nodes: SSA. (line 31) 52221* PIC: PIC. (line 6) 52222* PIC_OFFSET_TABLE_REGNUM: PIC. (line 15) 52223* PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 25) 52224* pipeline hazard recognizer: Processor pipeline description. 52225 (line 6) 52226* pipeline hazard recognizer <1>: Processor pipeline description. 52227 (line 53) 52228* Plugins: Plugins. (line 6) 52229* plus: Arithmetic. (line 14) 52230* plus and attributes: Expressions. (line 83) 52231* plus, canonicalization of: Insn Canonicalizations. 52232 (line 27) 52233* PLUS_EXPR: Unary and Binary Expressions. 52234 (line 6) 52235* Pmode: Misc. (line 351) 52236* pmode_register_operand: Machine-Independent Predicates. 52237 (line 34) 52238* pointer: Types. (line 6) 52239* POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 76) 52240* POINTER_DIFF_EXPR: Unary and Binary Expressions. 52241 (line 6) 52242* POINTER_PLUS_EXPR: Unary and Binary Expressions. 52243 (line 6) 52244* POINTER_SIZE: Storage Layout. (line 70) 52245* POINTER_TYPE: Types. (line 6) 52246* polynomial integers: poly_int. (line 6) 52247* poly_int: poly_int. (line 6) 52248* poly_int, invariant range: Overview of poly_int. 52249 (line 31) 52250* poly_int, main typedefs: Overview of poly_int. 52251 (line 46) 52252* poly_int, runtime value: Overview of poly_int. 52253 (line 6) 52254* poly_int, template parameters: Overview of poly_int. 52255 (line 24) 52256* poly_int, use in target-independent code: Consequences of using poly_int. 52257 (line 32) 52258* poly_int, use in target-specific code: Consequences of using poly_int. 52259 (line 40) 52260* POLY_INT_CST: Constant expressions. 52261 (line 6) 52262* popcount: Arithmetic. (line 238) 52263* popcountM2 instruction pattern: Standard Names. (line 1090) 52264* pops_args: Function Entry. (line 111) 52265* pop_operand: Machine-Independent Predicates. 52266 (line 87) 52267* portability: Portability. (line 6) 52268* position independent code: PIC. (line 6) 52269* POSTDECREMENT_EXPR: Unary and Binary Expressions. 52270 (line 6) 52271* POSTINCREMENT_EXPR: Unary and Binary Expressions. 52272 (line 6) 52273* post_dec: Incdec. (line 25) 52274* post_inc: Incdec. (line 30) 52275* POST_LINK_SPEC: Driver. (line 236) 52276* post_modify: Incdec. (line 33) 52277* post_order_compute, inverted_post_order_compute, walk_dominator_tree: Basic Blocks. 52278 (line 34) 52279* POWI_MAX_MULTS: Misc. (line 986) 52280* powM3 instruction pattern: Standard Names. (line 936) 52281* pragma: Misc. (line 409) 52282* PREDECREMENT_EXPR: Unary and Binary Expressions. 52283 (line 6) 52284* predefined macros: Run-time Target. (line 6) 52285* predicates: Predicates. (line 6) 52286* predicates and machine modes: Predicates. (line 31) 52287* predication: Conditional Execution. 52288 (line 6) 52289* predict.def: Profile information. 52290 (line 24) 52291* PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 40) 52292* PREFERRED_RELOAD_CLASS: Register Classes. (line 249) 52293* PREFERRED_STACK_BOUNDARY: Storage Layout. (line 164) 52294* prefetch: Side Effects. (line 324) 52295* prefetch and /v: Flags. (line 92) 52296* prefetch instruction pattern: Standard Names. (line 1962) 52297* PREFETCH_SCHEDULE_BARRIER_P: Flags. (line 92) 52298* PREINCREMENT_EXPR: Unary and Binary Expressions. 52299 (line 6) 52300* presence_set: Processor pipeline description. 52301 (line 223) 52302* preserving SSA form: SSA. (line 74) 52303* pretend_args_size: Function Entry. (line 117) 52304* prev_active_insn: define_peephole. (line 60) 52305* PREV_INSN: Insns. (line 26) 52306* pre_dec: Incdec. (line 8) 52307* PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 126) 52308* pre_inc: Incdec. (line 22) 52309* pre_modify: Incdec. (line 52) 52310* PRINT_OPERAND: Instruction Output. (line 95) 52311* PRINT_OPERAND_ADDRESS: Instruction Output. (line 122) 52312* PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 115) 52313* probe_stack instruction pattern: Standard Names. (line 1812) 52314* probe_stack_address instruction pattern: Standard Names. (line 1805) 52315* processor functional units: Processor pipeline description. 52316 (line 6) 52317* processor functional units <1>: Processor pipeline description. 52318 (line 68) 52319* processor pipeline description: Processor pipeline description. 52320 (line 6) 52321* product: Arithmetic. (line 93) 52322* profile feedback: Profile information. 52323 (line 14) 52324* profile representation: Profile information. 52325 (line 6) 52326* PROFILE_BEFORE_PROLOGUE: Profiling. (line 34) 52327* PROFILE_HOOK: Profiling. (line 22) 52328* profiling, code generation: Profiling. (line 6) 52329* program counter: Regs and Memory. (line 384) 52330* prologue: Function Entry. (line 6) 52331* prologue instruction pattern: Standard Names. (line 1901) 52332* PROMOTE_MODE: Storage Layout. (line 87) 52333* pseudo registers: Regs and Memory. (line 9) 52334* PSImode: Machine Modes. (line 32) 52335* PTRDIFF_TYPE: Type Layout. (line 157) 52336* purge_dead_edges: Edges. (line 103) 52337* purge_dead_edges <1>: Maintaining the CFG. 52338 (line 81) 52339* push address instruction: Simple Constraints. (line 162) 52340* pushM1 instruction pattern: Standard Names. (line 403) 52341* PUSH_ARGS: Stack Arguments. (line 17) 52342* PUSH_ARGS_REVERSED: Stack Arguments. (line 25) 52343* push_operand: Machine-Independent Predicates. 52344 (line 80) 52345* push_reload: Addressing Modes. (line 176) 52346* PUSH_ROUNDING: Stack Arguments. (line 31) 52347* PUT_CODE: RTL Objects. (line 47) 52348* PUT_MODE: Machine Modes. (line 384) 52349* PUT_REG_NOTE_KIND: Insns. (line 369) 52350* QCmode: Machine Modes. (line 199) 52351* QFmode: Machine Modes. (line 57) 52352* QImode: Machine Modes. (line 25) 52353* QImode, in insn: Insns. (line 291) 52354* QQmode: Machine Modes. (line 106) 52355* qualified type: Types. (line 6) 52356* qualified type <1>: Types for C++. (line 6) 52357* querying function unit reservations: Processor pipeline description. 52358 (line 90) 52359* question mark: Multi-Alternative. (line 42) 52360* quotient: Arithmetic. (line 116) 52361* r in constraint: Simple Constraints. (line 64) 52362* RDIV_EXPR: Unary and Binary Expressions. 52363 (line 6) 52364* READONLY_DATA_SECTION_ASM_OP: Sections. (line 62) 52365* real operands: SSA Operands. (line 6) 52366* REALPART_EXPR: Unary and Binary Expressions. 52367 (line 6) 52368* REAL_CST: Constant expressions. 52369 (line 6) 52370* REAL_LIBGCC_SPEC: Driver. (line 124) 52371* REAL_NM_FILE_NAME: Macros for Initialization. 52372 (line 105) 52373* REAL_TYPE: Types. (line 6) 52374* REAL_VALUE_ABS: Floating Point. (line 58) 52375* REAL_VALUE_ATOF: Floating Point. (line 39) 52376* REAL_VALUE_FIX: Floating Point. (line 31) 52377* REAL_VALUE_ISINF: Floating Point. (line 49) 52378* REAL_VALUE_ISNAN: Floating Point. (line 52) 52379* REAL_VALUE_NEGATE: Floating Point. (line 55) 52380* REAL_VALUE_NEGATIVE: Floating Point. (line 46) 52381* REAL_VALUE_TO_TARGET_DECIMAL128: Data Output. (line 147) 52382* REAL_VALUE_TO_TARGET_DECIMAL32: Data Output. (line 145) 52383* REAL_VALUE_TO_TARGET_DECIMAL64: Data Output. (line 146) 52384* REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 143) 52385* REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 144) 52386* REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 142) 52387* REAL_VALUE_TYPE: Floating Point. (line 25) 52388* REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 34) 52389* recognizing insns: RTL Template. (line 6) 52390* recog_data.operand: Instruction Output. (line 54) 52391* RECORD_TYPE: Types. (line 6) 52392* RECORD_TYPE <1>: Classes. (line 6) 52393* redirect_edge_and_branch: Profile information. 52394 (line 71) 52395* redirect_edge_and_branch, redirect_jump: Maintaining the CFG. 52396 (line 89) 52397* reduc_and_scal_M instruction pattern: Standard Names. (line 510) 52398* reduc_ior_scal_M instruction pattern: Standard Names. (line 511) 52399* reduc_plus_scal_M instruction pattern: Standard Names. (line 505) 52400* reduc_smax_scal_M instruction pattern: Standard Names. (line 495) 52401* reduc_smin_scal_M instruction pattern: Standard Names. (line 495) 52402* reduc_umax_scal_M instruction pattern: Standard Names. (line 500) 52403* reduc_umin_scal_M instruction pattern: Standard Names. (line 500) 52404* reduc_xor_scal_M instruction pattern: Standard Names. (line 512) 52405* reference: Types. (line 6) 52406* REFERENCE_TYPE: Types. (line 6) 52407* reg: Regs and Memory. (line 9) 52408* reg and /f: Flags. (line 102) 52409* reg and /i: Flags. (line 97) 52410* reg and /v: Flags. (line 106) 52411* reg, RTL sharing: Sharing. (line 17) 52412* register allocation order: Allocation Order. (line 6) 52413* register class definitions: Register Classes. (line 6) 52414* register class preference constraints: Class Preferences. (line 6) 52415* register pairs: Values in Registers. 52416 (line 65) 52417* Register Transfer Language (RTL): RTL. (line 6) 52418* register usage: Registers. (line 6) 52419* registers arguments: Register Arguments. (line 6) 52420* registers in constraints: Simple Constraints. (line 64) 52421* REGISTER_MOVE_COST: Costs. (line 9) 52422* REGISTER_NAMES: Instruction Output. (line 8) 52423* register_operand: Machine-Independent Predicates. 52424 (line 29) 52425* REGISTER_PREFIX: Instruction Output. (line 150) 52426* REGISTER_TARGET_PRAGMAS: Misc. (line 409) 52427* REGMODE_NATURAL_SIZE: Regs and Memory. (line 191) 52428* REGMODE_NATURAL_SIZE <1>: Regs and Memory. (line 268) 52429* REGMODE_NATURAL_SIZE <2>: Values in Registers. 52430 (line 46) 52431* REGNO_MODE_CODE_OK_FOR_BASE_P: Register Classes. (line 172) 52432* REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 150) 52433* REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 160) 52434* REGNO_OK_FOR_BASE_P: Register Classes. (line 146) 52435* REGNO_OK_FOR_INDEX_P: Register Classes. (line 186) 52436* REGNO_REG_CLASS: Register Classes. (line 105) 52437* regs_ever_live: Function Entry. (line 29) 52438* regular expressions: Processor pipeline description. 52439 (line 6) 52440* regular expressions <1>: Processor pipeline description. 52441 (line 105) 52442* REG_ALLOC_ORDER: Allocation Order. (line 8) 52443* REG_BR_PRED: Insns. (line 541) 52444* REG_BR_PROB: Insns. (line 533) 52445* REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information. 52446 (line 82) 52447* REG_BR_PROB_BASE, EDGE_FREQUENCY: Profile information. 52448 (line 52) 52449* REG_CALL_NOCF_CHECK: Insns. (line 557) 52450* REG_CC_SETTER: Insns. (line 505) 52451* REG_CC_USER: Insns. (line 505) 52452* reg_class_contents: Register Basics. (line 63) 52453* REG_CLASS_CONTENTS: Register Classes. (line 91) 52454* reg_class_for_constraint: C Constraint Interface. 52455 (line 48) 52456* REG_CLASS_NAMES: Register Classes. (line 86) 52457* REG_DEAD: Insns. (line 380) 52458* REG_DEAD, REG_UNUSED: Liveness information. 52459 (line 32) 52460* REG_DEP_ANTI: Insns. (line 527) 52461* REG_DEP_OUTPUT: Insns. (line 523) 52462* REG_DEP_TRUE: Insns. (line 520) 52463* REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 109) 52464* REG_EQUAL: Insns. (line 434) 52465* REG_EQUIV: Insns. (line 434) 52466* REG_EXPR: Special Accessors. (line 58) 52467* REG_FRAME_RELATED_EXPR: Insns. (line 547) 52468* REG_FUNCTION_VALUE_P: Flags. (line 97) 52469* REG_INC: Insns. (line 396) 52470* reg_label and /v: Flags. (line 54) 52471* REG_LABEL_OPERAND: Insns. (line 410) 52472* REG_LABEL_TARGET: Insns. (line 419) 52473* reg_names: Register Basics. (line 63) 52474* reg_names <1>: Instruction Output. (line 107) 52475* REG_NONNEG: Insns. (line 402) 52476* REG_NOTES: Insns. (line 344) 52477* REG_NOTE_KIND: Insns. (line 369) 52478* REG_OFFSET: Special Accessors. (line 62) 52479* REG_OK_STRICT: Addressing Modes. (line 99) 52480* REG_PARM_STACK_SPACE: Stack Arguments. (line 58) 52481* REG_PARM_STACK_SPACE, and TARGET_FUNCTION_ARG: Register Arguments. 52482 (line 56) 52483* REG_POINTER: Flags. (line 102) 52484* REG_SETJMP: Insns. (line 428) 52485* REG_UNUSED: Insns. (line 389) 52486* REG_USERVAR_P: Flags. (line 106) 52487* REG_VALUE_IN_UNWIND_CONTEXT: Frame Registers. (line 156) 52488* REG_WORDS_BIG_ENDIAN: Storage Layout. (line 35) 52489* relative costs: Costs. (line 6) 52490* RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 266) 52491* reloading: RTL passes. (line 170) 52492* reload_completed: Standard Names. (line 1600) 52493* reload_in instruction pattern: Standard Names. (line 98) 52494* reload_in_progress: Standard Names. (line 57) 52495* reload_out instruction pattern: Standard Names. (line 98) 52496* remainder: Arithmetic. (line 136) 52497* remainderM3 instruction pattern: Standard Names. (line 790) 52498* reorder: GTY Options. (line 175) 52499* representation of RTL: RTL. (line 6) 52500* reservation delays: Processor pipeline description. 52501 (line 6) 52502* restore_stack_block instruction pattern: Standard Names. (line 1726) 52503* restore_stack_function instruction pattern: Standard Names. 52504 (line 1726) 52505* restore_stack_nonlocal instruction pattern: Standard Names. 52506 (line 1726) 52507* rest_of_decl_compilation: Parsing pass. (line 51) 52508* rest_of_type_compilation: Parsing pass. (line 51) 52509* RESULT_DECL: Declarations. (line 6) 52510* return: Side Effects. (line 72) 52511* return instruction pattern: Standard Names. (line 1574) 52512* return values in registers: Scalar Return. (line 6) 52513* returning aggregate values: Aggregate Return. (line 6) 52514* returning structures and unions: Interface. (line 10) 52515* RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 64) 52516* RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 127) 52517* RETURN_ADDR_OFFSET: Exception Handling. (line 59) 52518* RETURN_ADDR_RTX: Frame Layout. (line 116) 52519* RETURN_EXPR: Statements for C++. (line 6) 52520* RETURN_STMT: Statements for C++. (line 6) 52521* return_val: Flags. (line 283) 52522* return_val, in call_insn: Flags. (line 120) 52523* return_val, in reg: Flags. (line 97) 52524* return_val, in symbol_ref: Flags. (line 216) 52525* reverse probability: Profile information. 52526 (line 66) 52527* REVERSE_CONDITION: MODE_CC Condition Codes. 52528 (line 92) 52529* REVERSIBLE_CC_MODE: MODE_CC Condition Codes. 52530 (line 77) 52531* right rotate: Arithmetic. (line 195) 52532* right shift: Arithmetic. (line 190) 52533* rintM2 instruction pattern: Standard Names. (line 996) 52534* RISC: Processor pipeline description. 52535 (line 6) 52536* RISC <1>: Processor pipeline description. 52537 (line 223) 52538* roots, marking: GGC Roots. (line 6) 52539* rotate: Arithmetic. (line 195) 52540* rotate <1>: Arithmetic. (line 195) 52541* rotatert: Arithmetic. (line 195) 52542* rotlM3 instruction pattern: Standard Names. (line 742) 52543* rotrM3 instruction pattern: Standard Names. (line 742) 52544* roundM2 instruction pattern: Standard Names. (line 969) 52545* ROUND_DIV_EXPR: Unary and Binary Expressions. 52546 (line 6) 52547* ROUND_MOD_EXPR: Unary and Binary Expressions. 52548 (line 6) 52549* ROUND_TYPE_ALIGN: Storage Layout. (line 454) 52550* RSHIFT_EXPR: Unary and Binary Expressions. 52551 (line 6) 52552* rsqrtM2 instruction pattern: Standard Names. (line 770) 52553* RTL addition: Arithmetic. (line 14) 52554* RTL addition with signed saturation: Arithmetic. (line 14) 52555* RTL addition with unsigned saturation: Arithmetic. (line 14) 52556* RTL classes: RTL Classes. (line 6) 52557* RTL comparison: Arithmetic. (line 46) 52558* RTL comparison operations: Comparisons. (line 6) 52559* RTL constant expression types: Constants. (line 6) 52560* RTL constants: Constants. (line 6) 52561* RTL declarations: RTL Declarations. (line 6) 52562* RTL difference: Arithmetic. (line 38) 52563* RTL expression: RTL Objects. (line 6) 52564* RTL expressions for arithmetic: Arithmetic. (line 6) 52565* RTL format: RTL Classes. (line 72) 52566* RTL format characters: RTL Classes. (line 77) 52567* RTL function-call insns: Calls. (line 6) 52568* RTL insn template: RTL Template. (line 6) 52569* RTL integers: RTL Objects. (line 6) 52570* RTL memory expressions: Regs and Memory. (line 6) 52571* RTL object types: RTL Objects. (line 6) 52572* RTL postdecrement: Incdec. (line 6) 52573* RTL postincrement: Incdec. (line 6) 52574* RTL predecrement: Incdec. (line 6) 52575* RTL preincrement: Incdec. (line 6) 52576* RTL register expressions: Regs and Memory. (line 6) 52577* RTL representation: RTL. (line 6) 52578* RTL side effect expressions: Side Effects. (line 6) 52579* RTL strings: RTL Objects. (line 6) 52580* RTL structure sharing assumptions: Sharing. (line 6) 52581* RTL subtraction: Arithmetic. (line 38) 52582* RTL subtraction with signed saturation: Arithmetic. (line 38) 52583* RTL subtraction with unsigned saturation: Arithmetic. (line 38) 52584* RTL sum: Arithmetic. (line 14) 52585* RTL vectors: RTL Objects. (line 6) 52586* RTL_CONST_CALL_P: Flags. (line 115) 52587* RTL_CONST_OR_PURE_CALL_P: Flags. (line 125) 52588* RTL_LOOPING_CONST_OR_PURE_CALL_P: Flags. (line 129) 52589* RTL_PURE_CALL_P: Flags. (line 120) 52590* RTX (See RTL): RTL Objects. (line 6) 52591* RTX codes, classes of: RTL Classes. (line 6) 52592* RTX_FRAME_RELATED_P: Flags. (line 135) 52593* run-time conventions: Interface. (line 6) 52594* run-time target specification: Run-time Target. (line 6) 52595* s in constraint: Simple Constraints. (line 100) 52596* SAD_EXPR: Vectors. (line 6) 52597* same_type_p: Types. (line 86) 52598* SAmode: Machine Modes. (line 150) 52599* satfractMN2 instruction pattern: Standard Names. (line 1300) 52600* satfractunsMN2 instruction pattern: Standard Names. (line 1313) 52601* satisfies_constraint_M: C Constraint Interface. 52602 (line 36) 52603* sat_fract: Conversions. (line 90) 52604* SAVE_EXPR: Unary and Binary Expressions. 52605 (line 6) 52606* save_stack_block instruction pattern: Standard Names. (line 1726) 52607* save_stack_function instruction pattern: Standard Names. (line 1726) 52608* save_stack_nonlocal instruction pattern: Standard Names. (line 1726) 52609* SBSS_SECTION_ASM_OP: Sections. (line 75) 52610* Scalar evolutions: Scalar evolutions. (line 6) 52611* scalars, returned as values: Scalar Return. (line 6) 52612* scalar_float_mode: Machine Modes. (line 297) 52613* scalar_int_mode: Machine Modes. (line 294) 52614* scalar_mode: Machine Modes. (line 300) 52615* scalbM3 instruction pattern: Standard Names. (line 797) 52616* scatter_storeM instruction pattern: Standard Names. (line 254) 52617* SCHED_GROUP_P: Flags. (line 162) 52618* SCmode: Machine Modes. (line 199) 52619* scratch: Regs and Memory. (line 320) 52620* scratch operands: Regs and Memory. (line 320) 52621* scratch, RTL sharing: Sharing. (line 38) 52622* scratch_operand: Machine-Independent Predicates. 52623 (line 49) 52624* SDATA_SECTION_ASM_OP: Sections. (line 57) 52625* SDmode: Machine Modes. (line 88) 52626* sdot_prodM instruction pattern: Standard Names. (line 539) 52627* search options: Including Patterns. (line 47) 52628* SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 391) 52629* SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 457) 52630* SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 392) 52631* SECONDARY_RELOAD_CLASS: Register Classes. (line 390) 52632* SELECT_CC_MODE: MODE_CC Condition Codes. 52633 (line 6) 52634* sequence: Side Effects. (line 259) 52635* Sequence iterators: Sequence iterators. (line 6) 52636* set: Side Effects. (line 15) 52637* set and /f: Flags. (line 135) 52638* setmemM instruction pattern: Standard Names. (line 1164) 52639* SETUP_FRAME_ADDRESSES: Frame Layout. (line 94) 52640* SET_ASM_OP: Label Output. (line 451) 52641* SET_ASM_OP <1>: Label Output. (line 462) 52642* set_attr: Tagging Insns. (line 31) 52643* set_attr_alternative: Tagging Insns. (line 49) 52644* set_bb_seq: GIMPLE sequences. (line 75) 52645* SET_DEST: Side Effects. (line 69) 52646* SET_IS_RETURN_P: Flags. (line 171) 52647* SET_LABEL_KIND: Insns. (line 146) 52648* set_optab_libfunc: Library Calls. (line 15) 52649* SET_RATIO: Costs. (line 237) 52650* SET_SRC: Side Effects. (line 69) 52651* set_thread_pointerMODE instruction pattern: Standard Names. 52652 (line 2285) 52653* SET_TYPE_STRUCTURAL_EQUALITY: Types. (line 6) 52654* SET_TYPE_STRUCTURAL_EQUALITY <1>: Types. (line 81) 52655* SFmode: Machine Modes. (line 69) 52656* sharing of RTL components: Sharing. (line 6) 52657* shift: Arithmetic. (line 173) 52658* SHIFT_COUNT_TRUNCATED: Misc. (line 134) 52659* SHLIB_SUFFIX: Macros for Initialization. 52660 (line 133) 52661* SHORT_ACCUM_TYPE_SIZE: Type Layout. (line 82) 52662* SHORT_FRACT_TYPE_SIZE: Type Layout. (line 62) 52663* SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 108) 52664* SHORT_TYPE_SIZE: Type Layout. (line 15) 52665* shrink-wrapping separate components: Shrink-wrapping separate components. 52666 (line 6) 52667* sibcall_epilogue instruction pattern: Standard Names. (line 1933) 52668* sibling call: Edges. (line 121) 52669* SIBLING_CALL_P: Flags. (line 175) 52670* signed division: Arithmetic. (line 116) 52671* signed division with signed saturation: Arithmetic. (line 116) 52672* signed maximum: Arithmetic. (line 141) 52673* signed minimum: Arithmetic. (line 141) 52674* significandM2 instruction pattern: Standard Names. (line 929) 52675* sign_extend: Conversions. (line 23) 52676* sign_extract: Bit-Fields. (line 8) 52677* sign_extract, canonicalization of: Insn Canonicalizations. 52678 (line 103) 52679* SIG_ATOMIC_TYPE: Type Layout. (line 208) 52680* SImode: Machine Modes. (line 37) 52681* simple constraints: Simple Constraints. (line 6) 52682* simple_return: Side Effects. (line 86) 52683* simple_return instruction pattern: Standard Names. (line 1589) 52684* sincosM3 instruction pattern: Standard Names. (line 825) 52685* sinM2 instruction pattern: Standard Names. (line 819) 52686* SIZETYPE: Type Layout. (line 147) 52687* SIZE_ASM_OP: Label Output. (line 33) 52688* SIZE_TYPE: Type Layout. (line 131) 52689* skip: GTY Options. (line 76) 52690* SLOW_BYTE_ACCESS: Costs. (line 117) 52691* smax: Arithmetic. (line 141) 52692* smin: Arithmetic. (line 141) 52693* sms, swing, software pipelining: RTL passes. (line 123) 52694* smulM3_highpart instruction pattern: Standard Names. (line 655) 52695* soft float library: Soft float library routines. 52696 (line 6) 52697* special: GTY Options. (line 238) 52698* special predicates: Predicates. (line 31) 52699* SPECS: Target Fragment. (line 194) 52700* speed of instructions: Costs. (line 6) 52701* splitting instructions: Insn Splitting. (line 6) 52702* split_block: Maintaining the CFG. 52703 (line 96) 52704* SQmode: Machine Modes. (line 114) 52705* sqrt: Arithmetic. (line 206) 52706* sqrtM2 instruction pattern: Standard Names. (line 764) 52707* square root: Arithmetic. (line 206) 52708* SSA: SSA. (line 6) 52709* ssaddM3 instruction pattern: Standard Names. (line 416) 52710* ssadM instruction pattern: Standard Names. (line 548) 52711* ssashlM3 instruction pattern: Standard Names. (line 730) 52712* SSA_NAME_DEF_STMT: SSA. (line 184) 52713* SSA_NAME_VERSION: SSA. (line 189) 52714* ssdivM3 instruction pattern: Standard Names. (line 416) 52715* ssmaddMN4 instruction pattern: Standard Names. (line 678) 52716* ssmsubMN4 instruction pattern: Standard Names. (line 702) 52717* ssmulM3 instruction pattern: Standard Names. (line 416) 52718* ssnegM2 instruction pattern: Standard Names. (line 754) 52719* sssubM3 instruction pattern: Standard Names. (line 416) 52720* ss_abs: Arithmetic. (line 200) 52721* ss_ashift: Arithmetic. (line 173) 52722* ss_div: Arithmetic. (line 116) 52723* ss_minus: Arithmetic. (line 38) 52724* ss_mult: Arithmetic. (line 93) 52725* ss_neg: Arithmetic. (line 82) 52726* ss_plus: Arithmetic. (line 14) 52727* ss_truncate: Conversions. (line 43) 52728* stack arguments: Stack Arguments. (line 6) 52729* stack frame layout: Frame Layout. (line 6) 52730* stack smashing protection: Stack Smashing Protection. 52731 (line 6) 52732* STACK_ALIGNMENT_NEEDED: Frame Layout. (line 41) 52733* STACK_BOUNDARY: Storage Layout. (line 156) 52734* STACK_CHECK_BUILTIN: Stack Checking. (line 31) 52735* STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 83) 52736* STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 74) 52737* STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 90) 52738* STACK_CHECK_MOVING_SP: Stack Checking. (line 53) 52739* STACK_CHECK_PROBE_INTERVAL_EXP: Stack Checking. (line 45) 52740* STACK_CHECK_PROTECT: Stack Checking. (line 62) 52741* STACK_CHECK_STATIC_BUILTIN: Stack Checking. (line 38) 52742* STACK_DYNAMIC_OFFSET: Frame Layout. (line 67) 52743* STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory. 52744 (line 83) 52745* STACK_GROWS_DOWNWARD: Frame Layout. (line 8) 52746* STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 89) 52747* STACK_POINTER_OFFSET: Frame Layout. (line 51) 52748* STACK_POINTER_OFFSET and virtual registers: Regs and Memory. 52749 (line 93) 52750* STACK_POINTER_REGNUM: Frame Registers. (line 8) 52751* STACK_POINTER_REGNUM and virtual registers: Regs and Memory. 52752 (line 83) 52753* stack_pointer_rtx: Frame Registers. (line 104) 52754* stack_protect_set instruction pattern: Standard Names. (line 2295) 52755* stack_protect_test instruction pattern: Standard Names. (line 2305) 52756* STACK_PUSH_CODE: Frame Layout. (line 12) 52757* STACK_REGS: Stack Registers. (line 19) 52758* STACK_REG_COVER_CLASS: Stack Registers. (line 22) 52759* STACK_SAVEAREA_MODE: Storage Layout. (line 470) 52760* STACK_SIZE_MODE: Storage Layout. (line 481) 52761* STACK_SLOT_ALIGNMENT: Storage Layout. (line 302) 52762* standard pattern names: Standard Names. (line 6) 52763* STANDARD_STARTFILE_PREFIX: Driver. (line 278) 52764* STANDARD_STARTFILE_PREFIX_1: Driver. (line 285) 52765* STANDARD_STARTFILE_PREFIX_2: Driver. (line 292) 52766* STARTFILE_SPEC: Driver. (line 147) 52767* Statement and operand traversals: Statement and operand traversals. 52768 (line 6) 52769* Statement Sequences: Statement Sequences. 52770 (line 6) 52771* Statements: Statements. (line 6) 52772* statements: Function Properties. 52773 (line 6) 52774* statements <1>: Statements for C++. (line 6) 52775* Static profile estimation: Profile information. 52776 (line 24) 52777* static single assignment: SSA. (line 6) 52778* STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 77) 52779* STATIC_CHAIN_REGNUM: Frame Registers. (line 76) 52780* stdarg.h and register arguments: Register Arguments. (line 51) 52781* STDC_0_IN_SYSTEM_HEADERS: Misc. (line 372) 52782* STMT_EXPR: Unary and Binary Expressions. 52783 (line 6) 52784* STMT_IS_FULL_EXPR_P: Statements for C++. (line 22) 52785* storage layout: Storage Layout. (line 6) 52786* STORE_FLAG_VALUE: Misc. (line 223) 52787* STORE_MAX_PIECES: Costs. (line 215) 52788* store_multiple instruction pattern: Standard Names. (line 159) 52789* strcpy: Storage Layout. (line 255) 52790* STRICT_ALIGNMENT: Storage Layout. (line 352) 52791* strict_low_part: RTL Declarations. (line 9) 52792* strict_memory_address_p: Addressing Modes. (line 186) 52793* STRING_CST: Constant expressions. 52794 (line 6) 52795* STRING_POOL_ADDRESS_P: Flags. (line 179) 52796* strlenM instruction pattern: Standard Names. (line 1235) 52797* structure value address: Aggregate Return. (line 6) 52798* structures, returning: Interface. (line 10) 52799* STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 344) 52800* subM3 instruction pattern: Standard Names. (line 416) 52801* SUBOBJECT: Statements for C++. (line 6) 52802* SUBOBJECT_CLEANUP: Statements for C++. (line 6) 52803* subreg: Regs and Memory. (line 97) 52804* subreg and /s: Flags. (line 201) 52805* subreg and /u: Flags. (line 194) 52806* subreg and /u and /v: Flags. (line 184) 52807* subreg, in strict_low_part: RTL Declarations. (line 9) 52808* SUBREG_BYTE: Regs and Memory. (line 311) 52809* SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 184) 52810* SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 194) 52811* SUBREG_PROMOTED_VAR_P: Flags. (line 201) 52812* SUBREG_REG: Regs and Memory. (line 311) 52813* subst iterators in .md files: Subst Iterators. (line 6) 52814* subvM4 instruction pattern: Standard Names. (line 432) 52815* SUCCESS_EXIT_CODE: Host Misc. (line 12) 52816* SUPPORTS_INIT_PRIORITY: Macros for Initialization. 52817 (line 57) 52818* SUPPORTS_ONE_ONLY: Label Output. (line 290) 52819* SUPPORTS_WEAK: Label Output. (line 264) 52820* SWITCHABLE_TARGET: Run-time Target. (line 164) 52821* SWITCH_BODY: Statements for C++. (line 6) 52822* SWITCH_COND: Statements for C++. (line 6) 52823* SWITCH_STMT: Statements for C++. (line 6) 52824* symbolic label: Sharing. (line 20) 52825* SYMBOL_FLAG_ANCHOR: Special Accessors. (line 117) 52826* SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 99) 52827* SYMBOL_FLAG_FUNCTION: Special Accessors. (line 92) 52828* SYMBOL_FLAG_HAS_BLOCK_INFO: Special Accessors. (line 113) 52829* SYMBOL_FLAG_LOCAL: Special Accessors. (line 95) 52830* SYMBOL_FLAG_SMALL: Special Accessors. (line 104) 52831* SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 108) 52832* symbol_ref: Constants. (line 189) 52833* symbol_ref and /f: Flags. (line 179) 52834* symbol_ref and /i: Flags. (line 216) 52835* symbol_ref and /u: Flags. (line 19) 52836* symbol_ref and /v: Flags. (line 220) 52837* symbol_ref, RTL sharing: Sharing. (line 20) 52838* SYMBOL_REF_ANCHOR_P: Special Accessors. (line 117) 52839* SYMBOL_REF_BLOCK: Special Accessors. (line 130) 52840* SYMBOL_REF_BLOCK_OFFSET: Special Accessors. (line 135) 52841* SYMBOL_REF_CONSTANT: Special Accessors. (line 78) 52842* SYMBOL_REF_DATA: Special Accessors. (line 82) 52843* SYMBOL_REF_DECL: Special Accessors. (line 67) 52844* SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 99) 52845* SYMBOL_REF_FLAG: Flags. (line 220) 52846* SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 282) 52847* SYMBOL_REF_FLAGS: Special Accessors. (line 86) 52848* SYMBOL_REF_FUNCTION_P: Special Accessors. (line 92) 52849* SYMBOL_REF_HAS_BLOCK_INFO_P: Special Accessors. (line 113) 52850* SYMBOL_REF_LOCAL_P: Special Accessors. (line 95) 52851* SYMBOL_REF_SMALL_P: Special Accessors. (line 104) 52852* SYMBOL_REF_TLS_MODEL: Special Accessors. (line 108) 52853* SYMBOL_REF_USED: Flags. (line 211) 52854* SYMBOL_REF_WEAK: Flags. (line 216) 52855* sync_addMODE instruction pattern: Standard Names. (line 2040) 52856* sync_andMODE instruction pattern: Standard Names. (line 2040) 52857* sync_compare_and_swapMODE instruction pattern: Standard Names. 52858 (line 2000) 52859* sync_iorMODE instruction pattern: Standard Names. (line 2040) 52860* sync_lock_releaseMODE instruction pattern: Standard Names. (line 2105) 52861* sync_lock_test_and_setMODE instruction pattern: Standard Names. 52862 (line 2079) 52863* sync_nandMODE instruction pattern: Standard Names. (line 2040) 52864* sync_new_addMODE instruction pattern: Standard Names. (line 2072) 52865* sync_new_andMODE instruction pattern: Standard Names. (line 2072) 52866* sync_new_iorMODE instruction pattern: Standard Names. (line 2072) 52867* sync_new_nandMODE instruction pattern: Standard Names. (line 2072) 52868* sync_new_subMODE instruction pattern: Standard Names. (line 2072) 52869* sync_new_xorMODE instruction pattern: Standard Names. (line 2072) 52870* sync_old_addMODE instruction pattern: Standard Names. (line 2055) 52871* sync_old_andMODE instruction pattern: Standard Names. (line 2055) 52872* sync_old_iorMODE instruction pattern: Standard Names. (line 2055) 52873* sync_old_nandMODE instruction pattern: Standard Names. (line 2055) 52874* sync_old_subMODE instruction pattern: Standard Names. (line 2055) 52875* sync_old_xorMODE instruction pattern: Standard Names. (line 2055) 52876* sync_subMODE instruction pattern: Standard Names. (line 2040) 52877* sync_xorMODE instruction pattern: Standard Names. (line 2040) 52878* SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 176) 52879* SYSROOT_SUFFIX_SPEC: Driver. (line 171) 52880* t-TARGET: Target Fragment. (line 6) 52881* table jump: Basic Blocks. (line 67) 52882* tablejump instruction pattern: Standard Names. (line 1662) 52883* tag: GTY Options. (line 90) 52884* tagging insns: Tagging Insns. (line 6) 52885* tail calls: Tail Calls. (line 6) 52886* TAmode: Machine Modes. (line 158) 52887* tanM2 instruction pattern: Standard Names. (line 836) 52888* target attributes: Target Attributes. (line 6) 52889* target description macros: Target Macros. (line 6) 52890* target functions: Target Structure. (line 6) 52891* target hooks: Target Structure. (line 6) 52892* target makefile fragment: Target Fragment. (line 6) 52893* target specifications: Run-time Target. (line 6) 52894* targetm: Target Structure. (line 6) 52895* targets, makefile: Makefile. (line 6) 52896* TARGET_ABSOLUTE_BIGGEST_ALIGNMENT: Storage Layout. (line 185) 52897* TARGET_ADDITIONAL_ALLOCNO_CLASS_P: Register Classes. (line 639) 52898* TARGET_ADDRESS_COST: Costs. (line 344) 52899* TARGET_ADDR_SPACE_ADDRESS_MODE: Named Address Spaces. 52900 (line 42) 52901* TARGET_ADDR_SPACE_CONVERT: Named Address Spaces. 52902 (line 89) 52903* TARGET_ADDR_SPACE_DEBUG: Named Address Spaces. 52904 (line 99) 52905* TARGET_ADDR_SPACE_DIAGNOSE_USAGE: Named Address Spaces. 52906 (line 103) 52907* TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P: Named Address Spaces. 52908 (line 59) 52909* TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS: Named Address Spaces. 52910 (line 67) 52911* TARGET_ADDR_SPACE_POINTER_MODE: Named Address Spaces. 52912 (line 36) 52913* TARGET_ADDR_SPACE_SUBSET_P: Named Address Spaces. 52914 (line 74) 52915* TARGET_ADDR_SPACE_VALID_POINTER_MODE: Named Address Spaces. 52916 (line 48) 52917* TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID: Named Address Spaces. 52918 (line 83) 52919* TARGET_ALIGN_ANON_BITFIELD: Storage Layout. (line 429) 52920* TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 832) 52921* TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS: Misc. (line 1110) 52922* TARGET_ALWAYS_STRIP_DOTDOT: Driver. (line 250) 52923* TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 99) 52924* TARGET_ARM_EABI_UNWINDER: Exception Region Output. 52925 (line 133) 52926* TARGET_ARRAY_MODE: Register Arguments. (line 349) 52927* TARGET_ARRAY_MODE_SUPPORTED_P: Register Arguments. (line 364) 52928* TARGET_ASAN_SHADOW_OFFSET: Misc. (line 1138) 52929* TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 9) 52930* TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 7) 52931* TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 8) 52932* TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 10) 52933* TARGET_ASM_ASSEMBLE_UNDEFINED_DECL: Label Output. (line 231) 52934* TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 301) 52935* TARGET_ASM_BYTE_OP: Data Output. (line 6) 52936* TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 209) 52937* TARGET_ASM_CLOSE_PAREN: Data Output. (line 133) 52938* TARGET_ASM_CODE_END: File Framework. (line 57) 52939* TARGET_ASM_CONSTRUCTOR: Macros for Initialization. 52940 (line 68) 52941* TARGET_ASM_DECLARE_CONSTANT_NAME: Label Output. (line 177) 52942* TARGET_ASM_DECL_END: Data Output. (line 38) 52943* TARGET_ASM_DESTRUCTOR: Macros for Initialization. 52944 (line 82) 52945* TARGET_ASM_ELF_FLAGS_NUMERIC: File Framework. (line 120) 52946* TARGET_ASM_EMIT_EXCEPT_PERSONALITY: Dispatch Tables. (line 80) 52947* TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL: Dispatch Tables. (line 73) 52948* TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 61) 52949* TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 337) 52950* TARGET_ASM_FILE_END: File Framework. (line 35) 52951* TARGET_ASM_FILE_START: File Framework. (line 8) 52952* TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 16) 52953* TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 29) 52954* TARGET_ASM_FINAL_POSTSCAN_INSN: Instruction Output. (line 82) 52955* TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 67) 52956* TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 61) 52957* TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 73) 52958* TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 18) 52959* TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 218) 52960* TARGET_ASM_FUNCTION_SECTION: File Framework. (line 132) 52961* TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS: File Framework. 52962 (line 142) 52963* TARGET_ASM_GLOBALIZE_DECL_NAME: Label Output. (line 222) 52964* TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 213) 52965* TARGET_ASM_INIT_SECTIONS: Sections. (line 164) 52966* TARGET_ASM_INTEGER: Data Output. (line 25) 52967* TARGET_ASM_INTERNAL_LABEL: Label Output. (line 380) 52968* TARGET_ASM_JUMP_ALIGN_MAX_SKIP: Alignment Output. (line 21) 52969* TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP: Alignment Output. 52970 (line 34) 52971* TARGET_ASM_LABEL_ALIGN_MAX_SKIP: Alignment Output. (line 68) 52972* TARGET_ASM_LOOP_ALIGN_MAX_SKIP: Alignment Output. (line 53) 52973* TARGET_ASM_LTO_END: File Framework. (line 52) 52974* TARGET_ASM_LTO_START: File Framework. (line 47) 52975* TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 343) 52976* TARGET_ASM_MERGEABLE_RODATA_PREFIX: Sections. (line 226) 52977* TARGET_ASM_NAMED_SECTION: File Framework. (line 112) 52978* TARGET_ASM_OPEN_PAREN: Data Output. (line 132) 52979* TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 42) 52980* TARGET_ASM_OUTPUT_ANCHOR: Anchored Addresses. (line 42) 52981* TARGET_ASM_OUTPUT_DWARF_DTPREL: DWARF. (line 121) 52982* TARGET_ASM_OUTPUT_IDENT: File Framework. (line 99) 52983* TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 167) 52984* TARGET_ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 91) 52985* TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY: Function Entry. (line 9) 52986* TARGET_ASM_RECORD_GCC_SWITCHES: File Framework. (line 173) 52987* TARGET_ASM_RECORD_GCC_SWITCHES_SECTION: File Framework. (line 218) 52988* TARGET_ASM_RELOC_RW_MASK: Sections. (line 173) 52989* TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 235) 52990* TARGET_ASM_SELECT_SECTION: Sections. (line 184) 52991* TARGET_ASM_TM_CLONE_TABLE_SECTION: Sections. (line 231) 52992* TARGET_ASM_TRAMPOLINE_TEMPLATE: Trampolines. (line 28) 52993* TARGET_ASM_TTYPE: Exception Region Output. 52994 (line 127) 52995* TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 13) 52996* TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 11) 52997* TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 12) 52998* TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 14) 52999* TARGET_ASM_UNIQUE_SECTION: Sections. (line 206) 53000* TARGET_ASM_UNWIND_EMIT: Dispatch Tables. (line 87) 53001* TARGET_ASM_UNWIND_EMIT_BEFORE_INSN: Dispatch Tables. (line 93) 53002* TARGET_ATOMIC_ALIGN_FOR_MODE: Misc. (line 1157) 53003* TARGET_ATOMIC_ASSIGN_EXPAND_FENV: Misc. (line 1163) 53004* TARGET_ATOMIC_TEST_AND_SET_TRUEVAL: Misc. (line 1148) 53005* TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 10) 53006* TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P: Target Attributes. (line 17) 53007* TARGET_BINDS_LOCAL_P: Sections. (line 313) 53008* TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc. (line 929) 53009* TARGET_BRANCH_TARGET_REGISTER_CLASS: Misc. (line 922) 53010* TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 289) 53011* TARGET_BUILTIN_CHKP_FUNCTION: Misc. (line 647) 53012* TARGET_BUILTIN_DECL: Misc. (line 626) 53013* TARGET_BUILTIN_RECIPROCAL: Addressing Modes. (line 261) 53014* TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 101) 53015* TARGET_CALLEE_COPIES: Register Arguments. (line 131) 53016* TARGET_CALL_ARGS: Varargs. (line 123) 53017* TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS: Miscellaneous Register Hooks. 53018 (line 6) 53019* TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 234) 53020* TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 909) 53021* TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P: Register Classes. (line 610) 53022* TARGET_CANONICALIZE_COMPARISON: MODE_CC Condition Codes. 53023 (line 55) 53024* TARGET_CANONICAL_VA_LIST_TYPE: Register Arguments. (line 310) 53025* TARGET_CAN_CHANGE_MODE_CLASS: Register Classes. (line 543) 53026* TARGET_CAN_CHANGE_MODE_CLASS and subreg semantics: Regs and Memory. 53027 (line 294) 53028* TARGET_CAN_ELIMINATE: Elimination. (line 58) 53029* TARGET_CAN_FOLLOW_JUMP: Misc. (line 818) 53030* TARGET_CAN_INLINE_P: Target Attributes. (line 165) 53031* TARGET_CAN_USE_DOLOOP_P: Misc. (line 782) 53032* TARGET_CASE_VALUES_THRESHOLD: Misc. (line 46) 53033* TARGET_CC_MODES_COMPATIBLE: MODE_CC Condition Codes. 53034 (line 120) 53035* TARGET_CHECK_PCH_TARGET_FLAGS: PCH Target. (line 26) 53036* TARGET_CHECK_STRING_OBJECT_FORMAT_ARG: Run-time Target. (line 119) 53037* TARGET_CHKP_BOUND_MODE: Misc. (line 719) 53038* TARGET_CHKP_BOUND_TYPE: Misc. (line 717) 53039* TARGET_CHKP_FUNCTION_VALUE_BOUNDS: Varargs. (line 182) 53040* TARGET_CHKP_INITIALIZE_BOUNDS: Misc. (line 725) 53041* TARGET_CHKP_MAKE_BOUNDS_CONSTANT: Misc. (line 721) 53042* TARGET_CLASS_LIKELY_SPILLED_P: Register Classes. (line 499) 53043* TARGET_CLASS_MAX_NREGS: Register Classes. (line 515) 53044* TARGET_COMMUTATIVE_P: Misc. (line 825) 53045* TARGET_COMPARE_BY_PIECES_BRANCH_RATIO: Costs. (line 200) 53046* TARGET_COMPARE_VERSION_PRIORITY: Misc. (line 759) 53047* TARGET_COMPUTE_FRAME_LAYOUT: Elimination. (line 74) 53048* TARGET_COMPUTE_PRESSURE_CLASSES: Register Classes. (line 655) 53049* TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 25) 53050* TARGET_CONDITIONAL_REGISTER_USAGE: Register Basics. (line 63) 53051* TARGET_CONSTANT_ALIGNMENT: Storage Layout. (line 268) 53052* TARGET_CONST_ANCHOR: Misc. (line 1121) 53053* TARGET_CONST_NOT_OK_FOR_DEBUG_P: Addressing Modes. (line 230) 53054* TARGET_CONVERT_TO_TYPE: Misc. (line 1081) 53055* TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 8) 53056* TARGET_CSTORE_MODE: Register Classes. (line 647) 53057* TARGET_CUSTOM_FUNCTION_DESCRIPTORS: Trampolines. (line 84) 53058* TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 86) 53059* TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 37) 53060* TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 61) 53061* TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 24) 53062* TARGET_CXX_DECL_MANGLING_CONTEXT: C++ ABI. (line 92) 53063* TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 52) 53064* TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 17) 53065* TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 11) 53066* TARGET_CXX_GUARD_TYPE: C++ ABI. (line 6) 53067* TARGET_CXX_IMPLICIT_EXTERN_C: Misc. (line 395) 53068* TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 28) 53069* TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 42) 53070* TARGET_CXX_LIBRARY_RTTI_COMDAT: C++ ABI. (line 68) 53071* TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 73) 53072* TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT: C++ ABI. (line 79) 53073* TARGET_C_EXCESS_PRECISION: Storage Layout. (line 109) 53074* TARGET_C_PREINCLUDE: Misc. (line 383) 53075* TARGET_DEBUG_UNWIND_INFO: DWARF. (line 32) 53076* TARGET_DECIMAL_FLOAT_SUPPORTED_P: Storage Layout. (line 534) 53077* TARGET_DECLSPEC: Target Attributes. (line 72) 53078* TARGET_DEFAULT_PACK_STRUCT: Misc. (line 468) 53079* TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 123) 53080* TARGET_DEFAULT_TARGET_FLAGS: Run-time Target. (line 55) 53081* TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 465) 53082* TARGET_DELAY_SCHED2: DWARF. (line 77) 53083* TARGET_DELAY_VARTRACK: DWARF. (line 81) 53084* TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 221) 53085* TARGET_DIFFERENT_ADDR_DISPLACEMENT_P: Register Classes. (line 603) 53086* TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 55) 53087* TARGET_DWARF_CALLING_CONVENTION: DWARF. (line 12) 53088* TARGET_DWARF_FRAME_REG_MODE: Exception Region Output. 53089 (line 113) 53090* TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 165) 53091* TARGET_DWARF_POLY_INDETERMINATE_VALUE: Frame Layout. (line 177) 53092* TARGET_DWARF_REGISTER_SPAN: Exception Region Output. 53093 (line 104) 53094* TARGET_EDOM: Library Calls. (line 59) 53095* TARGET_EMPTY_RECORD_P: Aggregate Return. (line 86) 53096* TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS: Emulated TLS. (line 67) 53097* TARGET_EMUTLS_GET_ADDRESS: Emulated TLS. (line 18) 53098* TARGET_EMUTLS_REGISTER_COMMON: Emulated TLS. (line 23) 53099* TARGET_EMUTLS_TMPL_PREFIX: Emulated TLS. (line 44) 53100* TARGET_EMUTLS_TMPL_SECTION: Emulated TLS. (line 35) 53101* TARGET_EMUTLS_VAR_ALIGN_FIXED: Emulated TLS. (line 62) 53102* TARGET_EMUTLS_VAR_FIELDS: Emulated TLS. (line 48) 53103* TARGET_EMUTLS_VAR_INIT: Emulated TLS. (line 55) 53104* TARGET_EMUTLS_VAR_PREFIX: Emulated TLS. (line 40) 53105* TARGET_EMUTLS_VAR_SECTION: Emulated TLS. (line 30) 53106* TARGET_ENCODE_SECTION_INFO: Sections. (line 256) 53107* TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes. 53108 (line 82) 53109* TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 127) 53110* TARGET_END_CALL_ARGS: Varargs. (line 137) 53111* TARGET_ENUM_VA_LIST_P: Register Arguments. (line 293) 53112* TARGET_ESTIMATED_POLY_VALUE: Costs. (line 425) 53113* TARGET_EXCEPT_UNWIND_INFO: Exception Region Output. 53114 (line 46) 53115* TARGET_EXECUTABLE_SUFFIX: Misc. (line 883) 53116* TARGET_EXPAND_BUILTIN: Misc. (line 636) 53117* TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 64) 53118* TARGET_EXPAND_DIVMOD_LIBFUNC: Scheduling. (line 461) 53119* TARGET_EXPAND_TO_RTL_HOOK: Storage Layout. (line 540) 53120* TARGET_EXPR: Unary and Binary Expressions. 53121 (line 6) 53122* TARGET_EXTRA_INCLUDES: Misc. (line 996) 53123* TARGET_EXTRA_LIVE_ON_ENTRY: Tail Calls. (line 20) 53124* TARGET_EXTRA_PRE_INCLUDES: Misc. (line 1003) 53125* TARGET_FIXED_CONDITION_CODE_REGS: MODE_CC Condition Codes. 53126 (line 105) 53127* TARGET_FIXED_POINT_SUPPORTED_P: Storage Layout. (line 537) 53128* target_flags: Run-time Target. (line 51) 53129* TARGET_FLAGS_REGNUM: MODE_CC Condition Codes. 53130 (line 133) 53131* TARGET_FLOATN_BUILTIN_P: Register Arguments. (line 414) 53132* TARGET_FLOATN_MODE: Register Arguments. (line 396) 53133* TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P: Run-time Target. 53134 (line 183) 53135* TARGET_FN_ABI_VA_LIST: Register Arguments. (line 305) 53136* TARGET_FOLD_BUILTIN: Misc. (line 742) 53137* TARGET_FORMAT_TYPES: Misc. (line 1024) 53138* TARGET_FRAME_POINTER_REQUIRED: Elimination. (line 8) 53139* TARGET_FUNCTION_ARG: Register Arguments. (line 10) 53140* TARGET_FUNCTION_ARG_ADVANCE: Register Arguments. (line 202) 53141* TARGET_FUNCTION_ARG_BOUNDARY: Register Arguments. (line 256) 53142* TARGET_FUNCTION_ARG_OFFSET: Register Arguments. (line 214) 53143* TARGET_FUNCTION_ARG_PADDING: Register Arguments. (line 222) 53144* TARGET_FUNCTION_ARG_ROUND_BOUNDARY: Register Arguments. (line 262) 53145* TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 93) 53146* TARGET_FUNCTION_INCOMING_ARG: Register Arguments. (line 71) 53147* TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 6) 53148* TARGET_FUNCTION_VALUE: Scalar Return. (line 9) 53149* TARGET_FUNCTION_VALUE_REGNO_P: Scalar Return. (line 96) 53150* TARGET_GENERATE_VERSION_DISPATCHER_BODY: Misc. (line 775) 53151* TARGET_GEN_CCMP_FIRST: Misc. (line 949) 53152* TARGET_GEN_CCMP_NEXT: Misc. (line 960) 53153* TARGET_GET_DRAP_RTX: Misc. (line 1104) 53154* TARGET_GET_FUNCTION_VERSIONS_DISPATCHER: Misc. (line 768) 53155* TARGET_GET_PCH_VALIDITY: PCH Target. (line 6) 53156* TARGET_GET_RAW_ARG_MODE: Aggregate Return. (line 81) 53157* TARGET_GET_RAW_RESULT_MODE: Aggregate Return. (line 76) 53158* TARGET_GIMPLE_FOLD_BUILTIN: Misc. (line 752) 53159* TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 315) 53160* TARGET_GOACC_DIM_LIMIT: Addressing Modes. (line 499) 53161* TARGET_GOACC_FORK_JOIN: Addressing Modes. (line 503) 53162* TARGET_GOACC_REDUCTION: Addressing Modes. (line 514) 53163* TARGET_GOACC_VALIDATE_DIMS: Addressing Modes. (line 486) 53164* TARGET_HANDLE_C_OPTION: Run-time Target. (line 73) 53165* TARGET_HANDLE_OPTION: Run-time Target. (line 59) 53166* TARGET_HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 52) 53167* TARGET_HARD_REGNO_MODE_OK: Values in Registers. 53168 (line 54) 53169* TARGET_HARD_REGNO_NREGS: Values in Registers. 53170 (line 10) 53171* TARGET_HARD_REGNO_SCRATCH_OK: Values in Registers. 53172 (line 139) 53173* TARGET_HAS_IFUNC_P: Misc. (line 1152) 53174* TARGET_HAS_NO_HW_DIVIDE: Library Calls. (line 52) 53175* TARGET_HAVE_CONDITIONAL_EXECUTION: Misc. (line 943) 53176* TARGET_HAVE_CTORS_DTORS: Macros for Initialization. 53177 (line 63) 53178* TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 150) 53179* TARGET_HAVE_SRODATA_SECTION: Sections. (line 302) 53180* TARGET_HAVE_SWITCHABLE_BSS_SECTIONS: File Framework. (line 155) 53181* TARGET_HAVE_TLS: Sections. (line 322) 53182* TARGET_INIT_BUILTINS: Misc. (line 610) 53183* TARGET_INIT_DWARF_REG_SIZES_EXTRA: Exception Region Output. 53184 (line 119) 53185* TARGET_INIT_LIBFUNCS: Library Calls. (line 15) 53186* TARGET_INIT_PIC_REG: Register Arguments. (line 95) 53187* TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 80) 53188* TARGET_INSN_COST: Costs. (line 380) 53189* TARGET_INSTANTIATE_DECLS: Storage Layout. (line 548) 53190* TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN: Misc. (line 1048) 53191* TARGET_INVALID_BINARY_OP: Misc. (line 1067) 53192* TARGET_INVALID_CONVERSION: Misc. (line 1054) 53193* TARGET_INVALID_UNARY_OP: Misc. (line 1060) 53194* TARGET_INVALID_WITHIN_DOLOOP: Misc. (line 799) 53195* TARGET_IN_SMALL_DATA_P: Sections. (line 298) 53196* TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS: Register Classes. (line 570) 53197* TARGET_KEEP_LEAF_WHEN_PROFILED: Profiling. (line 39) 53198* TARGET_LEGITIMATE_ADDRESS_P: Addressing Modes. (line 48) 53199* TARGET_LEGITIMATE_COMBINED_INSN: Misc. (line 813) 53200* TARGET_LEGITIMATE_CONSTANT_P: Addressing Modes. (line 213) 53201* TARGET_LEGITIMIZE_ADDRESS: Addressing Modes. (line 129) 53202* TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT: Register Classes. (line 618) 53203* TARGET_LIBCALL_VALUE: Scalar Return. (line 65) 53204* TARGET_LIBC_HAS_FUNCTION: Library Calls. (line 77) 53205* TARGET_LIBFUNC_GNU_PREFIX: Library Calls. (line 24) 53206* TARGET_LIBGCC_CMP_RETURN_MODE: Storage Layout. (line 490) 53207* TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P: Register Arguments. 53208 (line 388) 53209* TARGET_LIBGCC_SDATA_SECTION: Sections. (line 136) 53210* TARGET_LIBGCC_SHIFT_COUNT_MODE: Storage Layout. (line 496) 53211* TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 42) 53212* TARGET_LOAD_BOUNDS_FOR_ARG: Varargs. (line 153) 53213* TARGET_LOAD_RETURNED_BOUNDS: Varargs. (line 172) 53214* TARGET_LOOP_UNROLL_ADJUST: Misc. (line 977) 53215* TARGET_LRA_P: Register Classes. (line 577) 53216* TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 595) 53217* TARGET_MANGLE_ASSEMBLER_NAME: Label Output. (line 356) 53218* TARGET_MANGLE_DECL_ASSEMBLER_NAME: Sections. (line 246) 53219* TARGET_MANGLE_TYPE: Storage Layout. (line 552) 53220* TARGET_MAX_ANCHOR_OFFSET: Anchored Addresses. (line 38) 53221* TARGET_MAX_NOCE_IFCVT_SEQ_COST: Costs. (line 390) 53222* TARGET_MD_ASM_ADJUST: Misc. (line 513) 53223* TARGET_MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 442) 53224* TARGET_MEMMODEL_CHECK: Misc. (line 1143) 53225* TARGET_MEMORY_MOVE_COST: Costs. (line 79) 53226* TARGET_MEM_CONSTRAINT: Addressing Modes. (line 107) 53227* TARGET_MEM_REF: Storage References. (line 6) 53228* TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 45) 53229* TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 37) 53230* TARGET_MIN_ANCHOR_OFFSET: Anchored Addresses. (line 32) 53231* TARGET_MIN_ARITHMETIC_PRECISION: Misc. (line 63) 53232* TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 112) 53233* TARGET_MODES_TIEABLE_P: Values in Registers. 53234 (line 123) 53235* TARGET_MODE_AFTER: Mode Switching. (line 57) 53236* TARGET_MODE_DEPENDENT_ADDRESS_P: Addressing Modes. (line 196) 53237* TARGET_MODE_EMIT: Mode Switching. (line 42) 53238* TARGET_MODE_ENTRY: Mode Switching. (line 64) 53239* TARGET_MODE_EXIT: Mode Switching. (line 71) 53240* TARGET_MODE_NEEDED: Mode Switching. (line 50) 53241* TARGET_MODE_PRIORITY: Mode Switching. (line 78) 53242* TARGET_MODE_REP_EXTENDED: Misc. (line 197) 53243* TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 506) 53244* TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 64) 53245* TARGET_MUST_PASS_IN_STACK, and TARGET_FUNCTION_ARG: Register Arguments. 53246 (line 56) 53247* TARGET_NARROW_VOLATILE_BITFIELD: Storage Layout. (line 435) 53248* TARGET_NOCE_CONVERSION_PROFITABLE_P: Costs. (line 409) 53249* TARGET_NO_REGISTER_ALLOCATION: DWARF. (line 85) 53250* TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P: Costs. (line 415) 53251* TARGET_N_FORMAT_TYPES: Misc. (line 1029) 53252* TARGET_OBJC_CONSTRUCT_STRING_OBJECT: Run-time Target. (line 88) 53253* TARGET_OBJC_DECLARE_CLASS_DEFINITION: Run-time Target. (line 109) 53254* TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE: Run-time Target. 53255 (line 104) 53256* TARGET_OBJECT_SUFFIX: Misc. (line 878) 53257* TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 45) 53258* TARGET_OFFLOAD_OPTIONS: Misc. (line 1186) 53259* TARGET_OMIT_STRUCT_RETURN_REG: Scalar Return. (line 117) 53260* TARGET_OPTAB_SUPPORTED_P: Costs. (line 299) 53261* TARGET_OPTF: Misc. (line 1011) 53262* TARGET_OPTION_DEFAULT_PARAMS: Run-time Target. (line 160) 53263* TARGET_OPTION_FUNCTION_VERSIONS: Target Attributes. (line 157) 53264* TARGET_OPTION_INIT_STRUCT: Run-time Target. (line 156) 53265* TARGET_OPTION_OPTIMIZATION_TABLE: Run-time Target. (line 142) 53266* TARGET_OPTION_OVERRIDE: Target Attributes. (line 144) 53267* TARGET_OPTION_POST_STREAM_IN: Target Attributes. (line 125) 53268* TARGET_OPTION_PRAGMA_PARSE: Target Attributes. (line 137) 53269* TARGET_OPTION_PRINT: Target Attributes. (line 131) 53270* TARGET_OPTION_RESTORE: Target Attributes. (line 119) 53271* TARGET_OPTION_SAVE: Target Attributes. (line 112) 53272* TARGET_OPTION_VALID_ATTRIBUTE_P: Target Attributes. (line 100) 53273* TARGET_OS_CPP_BUILTINS: Run-time Target. (line 41) 53274* TARGET_OVERRIDES_FORMAT_ATTRIBUTES: Misc. (line 1033) 53275* TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc. (line 1039) 53276* TARGET_OVERRIDES_FORMAT_INIT: Misc. (line 1043) 53277* TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE: Run-time Target. (line 126) 53278* TARGET_PASS_BY_REFERENCE: Register Arguments. (line 119) 53279* TARGET_PCH_VALID_P: PCH Target. (line 11) 53280* TARGET_POSIX_IO: Misc. (line 539) 53281* TARGET_PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 284) 53282* TARGET_PREFERRED_RELOAD_CLASS: Register Classes. (line 213) 53283* TARGET_PREFERRED_RENAME_CLASS: Register Classes. (line 201) 53284* TARGET_PREPARE_PCH_SAVE: PCH Target. (line 34) 53285* TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 144) 53286* TARGET_PROFILE_BEFORE_PROLOGUE: Sections. (line 306) 53287* TARGET_PROMOTED_TYPE: Misc. (line 1073) 53288* TARGET_PROMOTE_FUNCTION_MODE: Storage Layout. (line 126) 53289* TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 10) 53290* TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 250) 53291* TARGET_RECORD_OFFLOAD_SYMBOL: Misc. (line 1181) 53292* TARGET_REF_MAY_ALIAS_ERRNO: Register Arguments. (line 326) 53293* TARGET_REGISTER_MOVE_COST: Costs. (line 31) 53294* TARGET_REGISTER_PRIORITY: Register Classes. (line 582) 53295* TARGET_REGISTER_USAGE_LEVELING_P: Register Classes. (line 593) 53296* TARGET_RELAYOUT_FUNCTION: Target Attributes. (line 172) 53297* TARGET_RESET_LOCATION_VIEW: DWARF. (line 57) 53298* TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 731) 53299* TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 15) 53300* TARGET_RETURN_IN_MSB: Scalar Return. (line 124) 53301* TARGET_RETURN_POPS_ARGS: Stack Arguments. (line 98) 53302* TARGET_RTX_COSTS: Costs. (line 313) 53303* TARGET_RUN_TARGET_SELFTESTS: Misc. (line 1235) 53304* TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 333) 53305* TARGET_SCHED_ADJUST_COST: Scheduling. (line 35) 53306* TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 50) 53307* TARGET_SCHED_ALLOC_SCHED_CONTEXT: Scheduling. (line 294) 53308* TARGET_SCHED_CAN_SPECULATE_INSN: Scheduling. (line 354) 53309* TARGET_SCHED_CLEAR_SCHED_CONTEXT: Scheduling. (line 309) 53310* TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 101) 53311* TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 255) 53312* TARGET_SCHED_DFA_POST_ADVANCE_CYCLE: Scheduling. (line 172) 53313* TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 156) 53314* TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE: Scheduling. (line 165) 53315* TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 144) 53316* TARGET_SCHED_DISPATCH: Scheduling. (line 370) 53317* TARGET_SCHED_DISPATCH_DO: Scheduling. (line 375) 53318* TARGET_SCHED_EXPOSED_PIPELINE: Scheduling. (line 379) 53319* TARGET_SCHED_FINISH: Scheduling. (line 122) 53320* TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 137) 53321* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK: Scheduling. (line 235) 53322* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN: Scheduling. (line 223) 53323* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling. 53324 (line 179) 53325* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling. 53326 (line 207) 53327* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END: Scheduling. (line 240) 53328* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI: Scheduling. (line 250) 53329* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT: Scheduling. (line 245) 53330* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE: Scheduling. (line 229) 53331* TARGET_SCHED_FREE_SCHED_CONTEXT: Scheduling. (line 313) 53332* TARGET_SCHED_FUSION_PRIORITY: Scheduling. (line 389) 53333* TARGET_SCHED_GEN_SPEC_CHECK: Scheduling. (line 335) 53334* TARGET_SCHED_H_I_D_EXTENDED: Scheduling. (line 289) 53335* TARGET_SCHED_INIT: Scheduling. (line 111) 53336* TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 161) 53337* TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 153) 53338* TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 129) 53339* TARGET_SCHED_INIT_SCHED_CONTEXT: Scheduling. (line 298) 53340* TARGET_SCHED_ISSUE_RATE: Scheduling. (line 11) 53341* TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 267) 53342* TARGET_SCHED_MACRO_FUSION_P: Scheduling. (line 87) 53343* TARGET_SCHED_MACRO_FUSION_PAIR_P: Scheduling. (line 91) 53344* TARGET_SCHED_NEEDS_BLOCK_P: Scheduling. (line 328) 53345* TARGET_SCHED_REASSOCIATION_WIDTH: Scheduling. (line 384) 53346* TARGET_SCHED_REORDER: Scheduling. (line 58) 53347* TARGET_SCHED_REORDER2: Scheduling. (line 75) 53348* TARGET_SCHED_SET_SCHED_CONTEXT: Scheduling. (line 305) 53349* TARGET_SCHED_SET_SCHED_FLAGS: Scheduling. (line 347) 53350* TARGET_SCHED_SMS_RES_MII: Scheduling. (line 361) 53351* TARGET_SCHED_SPECULATE_INSN: Scheduling. (line 316) 53352* TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 22) 53353* TARGET_SECONDARY_MEMORY_NEEDED: Register Classes. (line 447) 53354* TARGET_SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 466) 53355* TARGET_SECONDARY_RELOAD: Register Classes. (line 312) 53356* TARGET_SECTION_TYPE_FLAGS: File Framework. (line 160) 53357* TARGET_SELECT_EARLY_REMAT_MODES: Register Classes. (line 488) 53358* TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 71) 53359* TARGET_SETUP_INCOMING_VARARG_BOUNDS: Varargs. (line 188) 53360* TARGET_SET_CURRENT_FUNCTION: Misc. (line 860) 53361* TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 33) 53362* TARGET_SET_UP_BY_PROLOGUE: Tail Calls. (line 29) 53363* TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 160) 53364* TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB: Shrink-wrapping separate components. 53365 (line 36) 53366* TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS: Shrink-wrapping separate components. 53367 (line 43) 53368* TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS: Shrink-wrapping separate components. 53369 (line 54) 53370* TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS: Shrink-wrapping separate components. 53371 (line 50) 53372* TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS: Shrink-wrapping separate components. 53373 (line 27) 53374* TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS: Shrink-wrapping separate components. 53375 (line 58) 53376* TARGET_SIMD_CLONE_ADJUST: Addressing Modes. (line 473) 53377* TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN: Addressing Modes. 53378 (line 465) 53379* TARGET_SIMD_CLONE_USABLE: Addressing Modes. (line 477) 53380* TARGET_SIMT_VF: Addressing Modes. (line 483) 53381* TARGET_SLOW_UNALIGNED_ACCESS: Costs. (line 132) 53382* TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P: Register Arguments. 53383 (line 424) 53384* TARGET_SPILL_CLASS: Register Classes. (line 632) 53385* TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 277) 53386* TARGET_STACK_CLASH_PROTECTION_FINAL_DYNAMIC_PROBE: Stack Checking. 53387 (line 97) 53388* TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection. 53389 (line 16) 53390* TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection. 53391 (line 6) 53392* TARGET_STACK_PROTECT_RUNTIME_ENABLED_P: Stack Smashing Protection. 53393 (line 25) 53394* TARGET_STARTING_FRAME_OFFSET: Frame Layout. (line 34) 53395* TARGET_STARTING_FRAME_OFFSET and virtual registers: Regs and Memory. 53396 (line 74) 53397* TARGET_STATIC_CHAIN: Frame Registers. (line 90) 53398* TARGET_STATIC_RTX_ALIGNMENT: Storage Layout. (line 240) 53399* TARGET_STORE_BOUNDS_FOR_ARG: Varargs. (line 163) 53400* TARGET_STORE_RETURNED_BOUNDS: Varargs. (line 177) 53401* TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 107) 53402* TARGET_STRING_OBJECT_REF_TYPE_P: Run-time Target. (line 114) 53403* TARGET_STRIP_NAME_ENCODING: Sections. (line 293) 53404* TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 44) 53405* TARGET_SUPPORTS_SPLIT_STACK: Stack Smashing Protection. 53406 (line 30) 53407* TARGET_SUPPORTS_WEAK: Label Output. (line 272) 53408* TARGET_SUPPORTS_WIDE_INT: Misc. (line 1194) 53409* TARGET_TERMINATE_DW2_EH_FRAME_INFO: Exception Region Output. 53410 (line 98) 53411* TARGET_TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 74) 53412* TARGET_TRAMPOLINE_INIT: Trampolines. (line 54) 53413* TARGET_TRULY_NOOP_TRUNCATION: Misc. (line 184) 53414* TARGET_UNSPEC_MAY_TRAP_P: Misc. (line 851) 53415* TARGET_UNWIND_TABLES_DEFAULT: Exception Region Output. 53416 (line 73) 53417* TARGET_UNWIND_WORD_MODE: Storage Layout. (line 502) 53418* TARGET_UPDATE_STACK_BOUNDARY: Misc. (line 1100) 53419* TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 123) 53420* TARGET_USE_ANCHORS_FOR_SYMBOL_P: Anchored Addresses. (line 53) 53421* TARGET_USE_BLOCKS_FOR_CONSTANT_P: Addressing Modes. (line 248) 53422* TARGET_USE_BLOCKS_FOR_DECL_P: Addressing Modes. (line 255) 53423* TARGET_USE_BY_PIECES_INFRASTRUCTURE_P: Costs. (line 165) 53424* TARGET_USE_PSEUDO_PIC_REG: Register Arguments. (line 91) 53425* TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 66) 53426* TARGET_VALID_POINTER_MODE: Register Arguments. (line 321) 53427* TARGET_VECTORIZE_ADD_STMT_COST: Addressing Modes. (line 428) 53428* TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES: Addressing Modes. 53429 (line 388) 53430* TARGET_VECTORIZE_BUILTIN_CONVERSION: Addressing Modes. (line 336) 53431* TARGET_VECTORIZE_BUILTIN_GATHER: Addressing Modes. (line 451) 53432* TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 266) 53433* TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION: Addressing Modes. 53434 (line 356) 53435* TARGET_VECTORIZE_BUILTIN_SCATTER: Addressing Modes. (line 458) 53436* TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST: Addressing Modes. 53437 (line 292) 53438* TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION: Addressing Modes. 53439 (line 348) 53440* TARGET_VECTORIZE_DESTROY_COST_DATA: Addressing Modes. (line 446) 53441* TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE: Addressing Modes. 53442 (line 412) 53443* TARGET_VECTORIZE_FINISH_COST: Addressing Modes. (line 439) 53444* TARGET_VECTORIZE_GET_MASK_MODE: Addressing Modes. (line 400) 53445* TARGET_VECTORIZE_INIT_COST: Addressing Modes. (line 419) 53446* TARGET_VECTORIZE_PREFERRED_SIMD_MODE: Addressing Modes. (line 373) 53447* TARGET_VECTORIZE_PREFERRED_VECTOR_ALIGNMENT: Addressing Modes. 53448 (line 298) 53449* TARGET_VECTORIZE_SPLIT_REDUCTION: Addressing Modes. (line 380) 53450* TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT: Addressing Modes. 53451 (line 363) 53452* TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE: Addressing Modes. 53453 (line 310) 53454* TARGET_VECTORIZE_VEC_PERM_CONST: Addressing Modes. (line 316) 53455* TARGET_VECTOR_ALIGNMENT: Storage Layout. (line 295) 53456* TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 344) 53457* TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 303) 53458* TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 297) 53459* TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 286) 53460* TARGET_WANT_DEBUG_PUB_SECTIONS: DWARF. (line 72) 53461* TARGET_WARN_FUNC_RETURN: Tail Calls. (line 35) 53462* TARGET_WARN_PARAMETER_PASSING_ABI: Aggregate Return. (line 90) 53463* TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 308) 53464* TCmode: Machine Modes. (line 199) 53465* TDmode: Machine Modes. (line 97) 53466* TEMPLATE_DECL: Declarations. (line 6) 53467* Temporaries: Temporaries. (line 6) 53468* termination routines: Initialization. (line 6) 53469* testing constraints: C Constraint Interface. 53470 (line 6) 53471* TEXT_SECTION_ASM_OP: Sections. (line 37) 53472* TFmode: Machine Modes. (line 101) 53473* The Language: The Language. (line 6) 53474* THEN_CLAUSE: Statements for C++. (line 6) 53475* THREAD_MODEL_SPEC: Driver. (line 162) 53476* THROW_EXPR: Unary and Binary Expressions. 53477 (line 6) 53478* THUNK_DECL: Declarations. (line 6) 53479* THUNK_DELTA: Declarations. (line 6) 53480* TImode: Machine Modes. (line 48) 53481* TImode, in insn: Insns. (line 291) 53482* TLS_COMMON_ASM_OP: Sections. (line 80) 53483* TLS_SECTION_ASM_FLAG: Sections. (line 85) 53484* tm.h macros: Target Macros. (line 6) 53485* TQFmode: Machine Modes. (line 65) 53486* TQmode: Machine Modes. (line 122) 53487* trampolines for nested functions: Trampolines. (line 6) 53488* TRAMPOLINE_ALIGNMENT: Trampolines. (line 48) 53489* TRAMPOLINE_SECTION: Trampolines. (line 39) 53490* TRAMPOLINE_SIZE: Trampolines. (line 44) 53491* TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 129) 53492* trap instruction pattern: Standard Names. (line 1943) 53493* tree: Tree overview. (line 6) 53494* tree <1>: Macros and Functions. 53495 (line 6) 53496* Tree SSA: Tree SSA. (line 6) 53497* TREE_CHAIN: Macros and Functions. 53498 (line 6) 53499* TREE_CODE: Tree overview. (line 6) 53500* tree_fits_shwi_p: Constant expressions. 53501 (line 6) 53502* tree_fits_uhwi_p: Constant expressions. 53503 (line 6) 53504* TREE_INT_CST_ELT: Constant expressions. 53505 (line 6) 53506* tree_int_cst_equal: Constant expressions. 53507 (line 6) 53508* TREE_INT_CST_LOW: Constant expressions. 53509 (line 6) 53510* tree_int_cst_lt: Constant expressions. 53511 (line 6) 53512* TREE_INT_CST_NUNITS: Constant expressions. 53513 (line 6) 53514* TREE_LIST: Containers. (line 6) 53515* TREE_OPERAND: Expression trees. (line 6) 53516* TREE_PUBLIC: Function Basics. (line 6) 53517* TREE_PUBLIC <1>: Function Properties. 53518 (line 28) 53519* TREE_PURPOSE: Containers. (line 6) 53520* TREE_READONLY: Function Properties. 53521 (line 37) 53522* tree_size: Macros and Functions. 53523 (line 13) 53524* TREE_STATIC: Function Properties. 53525 (line 31) 53526* TREE_STRING_LENGTH: Constant expressions. 53527 (line 6) 53528* TREE_STRING_POINTER: Constant expressions. 53529 (line 6) 53530* TREE_THIS_VOLATILE: Function Properties. 53531 (line 34) 53532* tree_to_shwi: Constant expressions. 53533 (line 6) 53534* tree_to_uhwi: Constant expressions. 53535 (line 6) 53536* TREE_TYPE: Macros and Functions. 53537 (line 6) 53538* TREE_TYPE <1>: Types. (line 6) 53539* TREE_TYPE <2>: Working with declarations. 53540 (line 11) 53541* TREE_TYPE <3>: Expression trees. (line 6) 53542* TREE_TYPE <4>: Expression trees. (line 17) 53543* TREE_TYPE <5>: Function Basics. (line 47) 53544* TREE_TYPE <6>: Types for C++. (line 6) 53545* TREE_VALUE: Containers. (line 6) 53546* TREE_VEC: Containers. (line 6) 53547* TREE_VEC_ELT: Containers. (line 6) 53548* TREE_VEC_LENGTH: Containers. (line 6) 53549* truncate: Conversions. (line 38) 53550* truncMN2 instruction pattern: Standard Names. (line 1278) 53551* TRUNC_DIV_EXPR: Unary and Binary Expressions. 53552 (line 6) 53553* TRUNC_MOD_EXPR: Unary and Binary Expressions. 53554 (line 6) 53555* TRUTH_ANDIF_EXPR: Unary and Binary Expressions. 53556 (line 6) 53557* TRUTH_AND_EXPR: Unary and Binary Expressions. 53558 (line 6) 53559* TRUTH_NOT_EXPR: Unary and Binary Expressions. 53560 (line 6) 53561* TRUTH_ORIF_EXPR: Unary and Binary Expressions. 53562 (line 6) 53563* TRUTH_OR_EXPR: Unary and Binary Expressions. 53564 (line 6) 53565* TRUTH_XOR_EXPR: Unary and Binary Expressions. 53566 (line 6) 53567* TRY_BLOCK: Statements for C++. (line 6) 53568* TRY_HANDLERS: Statements for C++. (line 6) 53569* TRY_STMTS: Statements for C++. (line 6) 53570* Tuple specific accessors: Tuple specific accessors. 53571 (line 6) 53572* tuples: Tuple representation. 53573 (line 6) 53574* type: Types. (line 6) 53575* type declaration: Declarations. (line 6) 53576* TYPENAME_TYPE: Types for C++. (line 6) 53577* TYPENAME_TYPE_FULLNAME: Types. (line 6) 53578* TYPENAME_TYPE_FULLNAME <1>: Types for C++. (line 6) 53579* TYPEOF_TYPE: Types for C++. (line 6) 53580* TYPE_ALIGN: Types. (line 6) 53581* TYPE_ALIGN <1>: Types. (line 30) 53582* TYPE_ALIGN <2>: Types for C++. (line 6) 53583* TYPE_ALIGN <3>: Types for C++. (line 44) 53584* TYPE_ARG_TYPES: Types. (line 6) 53585* TYPE_ARG_TYPES <1>: Types for C++. (line 6) 53586* TYPE_ASM_OP: Label Output. (line 76) 53587* TYPE_ATTRIBUTES: Attributes. (line 24) 53588* TYPE_BINFO: Classes. (line 6) 53589* TYPE_BUILT_IN: Types for C++. (line 66) 53590* TYPE_CANONICAL: Types. (line 6) 53591* TYPE_CANONICAL <1>: Types. (line 41) 53592* TYPE_CONTEXT: Types. (line 6) 53593* TYPE_CONTEXT <1>: Types for C++. (line 6) 53594* TYPE_DECL: Declarations. (line 6) 53595* TYPE_FIELDS: Types. (line 6) 53596* TYPE_FIELDS <1>: Types for C++. (line 6) 53597* TYPE_FIELDS <2>: Classes. (line 6) 53598* TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 93) 53599* TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 78) 53600* TYPE_HAS_MUTABLE_P: Classes. (line 83) 53601* TYPE_HAS_NEW_OPERATOR: Classes. (line 90) 53602* TYPE_MAIN_VARIANT: Types. (line 6) 53603* TYPE_MAIN_VARIANT <1>: Types. (line 19) 53604* TYPE_MAIN_VARIANT <2>: Types for C++. (line 6) 53605* TYPE_MAX_VALUE: Types. (line 6) 53606* TYPE_METHOD_BASETYPE: Types. (line 6) 53607* TYPE_METHOD_BASETYPE <1>: Types for C++. (line 6) 53608* TYPE_MIN_VALUE: Types. (line 6) 53609* TYPE_NAME: Types. (line 6) 53610* TYPE_NAME <1>: Types. (line 33) 53611* TYPE_NAME <2>: Types for C++. (line 6) 53612* TYPE_NAME <3>: Types for C++. (line 47) 53613* TYPE_NOTHROW_P: Functions for C++. (line 154) 53614* TYPE_OFFSET_BASETYPE: Types. (line 6) 53615* TYPE_OFFSET_BASETYPE <1>: Types for C++. (line 6) 53616* TYPE_OPERAND_FMT: Label Output. (line 87) 53617* TYPE_OVERLOADS_ARRAY_REF: Classes. (line 101) 53618* TYPE_OVERLOADS_ARROW: Classes. (line 104) 53619* TYPE_OVERLOADS_CALL_EXPR: Classes. (line 97) 53620* TYPE_POLYMORPHIC_P: Classes. (line 74) 53621* TYPE_PRECISION: Types. (line 6) 53622* TYPE_PRECISION <1>: Types for C++. (line 6) 53623* TYPE_PTRDATAMEM_P: Types for C++. (line 6) 53624* TYPE_PTRDATAMEM_P <1>: Types for C++. (line 69) 53625* TYPE_PTRFN_P: Types for C++. (line 76) 53626* TYPE_PTROBV_P: Types for C++. (line 6) 53627* TYPE_PTROB_P: Types for C++. (line 79) 53628* TYPE_PTR_P: Types for C++. (line 72) 53629* TYPE_QUAL_CONST: Types. (line 6) 53630* TYPE_QUAL_CONST <1>: Types for C++. (line 6) 53631* TYPE_QUAL_RESTRICT: Types. (line 6) 53632* TYPE_QUAL_RESTRICT <1>: Types for C++. (line 6) 53633* TYPE_QUAL_VOLATILE: Types. (line 6) 53634* TYPE_QUAL_VOLATILE <1>: Types for C++. (line 6) 53635* TYPE_RAISES_EXCEPTIONS: Functions for C++. (line 149) 53636* TYPE_SIZE: Types. (line 6) 53637* TYPE_SIZE <1>: Types. (line 25) 53638* TYPE_SIZE <2>: Types for C++. (line 6) 53639* TYPE_SIZE <3>: Types for C++. (line 39) 53640* TYPE_STRUCTURAL_EQUALITY_P: Types. (line 6) 53641* TYPE_STRUCTURAL_EQUALITY_P <1>: Types. (line 77) 53642* TYPE_UNQUALIFIED: Types. (line 6) 53643* TYPE_UNQUALIFIED <1>: Types for C++. (line 6) 53644* TYPE_VFIELD: Classes. (line 6) 53645* uaddvM4 instruction pattern: Standard Names. (line 435) 53646* UDAmode: Machine Modes. (line 170) 53647* udiv: Arithmetic. (line 130) 53648* udivM3 instruction pattern: Standard Names. (line 416) 53649* udivmodM4 instruction pattern: Standard Names. (line 727) 53650* udot_prodM instruction pattern: Standard Names. (line 540) 53651* UDQmode: Machine Modes. (line 138) 53652* UHAmode: Machine Modes. (line 162) 53653* UHQmode: Machine Modes. (line 130) 53654* UINT16_TYPE: Type Layout. (line 214) 53655* UINT32_TYPE: Type Layout. (line 215) 53656* UINT64_TYPE: Type Layout. (line 216) 53657* UINT8_TYPE: Type Layout. (line 213) 53658* UINTMAX_TYPE: Type Layout. (line 197) 53659* UINTPTR_TYPE: Type Layout. (line 234) 53660* UINT_FAST16_TYPE: Type Layout. (line 230) 53661* UINT_FAST32_TYPE: Type Layout. (line 231) 53662* UINT_FAST64_TYPE: Type Layout. (line 232) 53663* UINT_FAST8_TYPE: Type Layout. (line 229) 53664* UINT_LEAST16_TYPE: Type Layout. (line 222) 53665* UINT_LEAST32_TYPE: Type Layout. (line 223) 53666* UINT_LEAST64_TYPE: Type Layout. (line 224) 53667* UINT_LEAST8_TYPE: Type Layout. (line 221) 53668* umaddMN4 instruction pattern: Standard Names. (line 674) 53669* umax: Arithmetic. (line 149) 53670* umaxM3 instruction pattern: Standard Names. (line 416) 53671* umin: Arithmetic. (line 149) 53672* uminM3 instruction pattern: Standard Names. (line 416) 53673* umod: Arithmetic. (line 136) 53674* umodM3 instruction pattern: Standard Names. (line 416) 53675* umsubMN4 instruction pattern: Standard Names. (line 698) 53676* umulhisi3 instruction pattern: Standard Names. (line 646) 53677* umulM3_highpart instruction pattern: Standard Names. (line 660) 53678* umulqihi3 instruction pattern: Standard Names. (line 646) 53679* umulsidi3 instruction pattern: Standard Names. (line 646) 53680* umulvM4 instruction pattern: Standard Names. (line 440) 53681* unchanging: Flags. (line 307) 53682* unchanging, in call_insn: Flags. (line 115) 53683* unchanging, in jump_insn, call_insn and insn: Flags. (line 28) 53684* unchanging, in mem: Flags. (line 78) 53685* unchanging, in subreg: Flags. (line 184) 53686* unchanging, in subreg <1>: Flags. (line 194) 53687* unchanging, in symbol_ref: Flags. (line 19) 53688* UNEQ_EXPR: Unary and Binary Expressions. 53689 (line 6) 53690* UNGE_EXPR: Unary and Binary Expressions. 53691 (line 6) 53692* UNGT_EXPR: Unary and Binary Expressions. 53693 (line 6) 53694* unions, returning: Interface. (line 10) 53695* UNION_TYPE: Types. (line 6) 53696* UNION_TYPE <1>: Classes. (line 6) 53697* UNITS_PER_WORD: Storage Layout. (line 60) 53698* UNKNOWN_TYPE: Types. (line 6) 53699* UNKNOWN_TYPE <1>: Types for C++. (line 6) 53700* UNLE_EXPR: Unary and Binary Expressions. 53701 (line 6) 53702* UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 48) 53703* UNLT_EXPR: Unary and Binary Expressions. 53704 (line 6) 53705* UNORDERED_EXPR: Unary and Binary Expressions. 53706 (line 6) 53707* unshare_all_rtl: Sharing. (line 61) 53708* unsigned division: Arithmetic. (line 130) 53709* unsigned division with unsigned saturation: Arithmetic. (line 130) 53710* unsigned greater than: Comparisons. (line 64) 53711* unsigned greater than <1>: Comparisons. (line 72) 53712* unsigned less than: Comparisons. (line 68) 53713* unsigned less than <1>: Comparisons. (line 76) 53714* unsigned minimum and maximum: Arithmetic. (line 149) 53715* unsigned_fix: Conversions. (line 77) 53716* unsigned_float: Conversions. (line 62) 53717* unsigned_fract_convert: Conversions. (line 97) 53718* unsigned_sat_fract: Conversions. (line 103) 53719* unspec: Side Effects. (line 299) 53720* unspec <1>: Constant Definitions. 53721 (line 111) 53722* unspec_volatile: Side Effects. (line 299) 53723* unspec_volatile <1>: Constant Definitions. 53724 (line 99) 53725* untyped_call instruction pattern: Standard Names. (line 1559) 53726* untyped_return instruction pattern: Standard Names. (line 1622) 53727* UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59) 53728* update_ssa: SSA. (line 74) 53729* update_stmt: Manipulating GIMPLE statements. 53730 (line 140) 53731* update_stmt <1>: SSA Operands. (line 6) 53732* update_stmt_if_modified: Manipulating GIMPLE statements. 53733 (line 143) 53734* UQQmode: Machine Modes. (line 126) 53735* usaddM3 instruction pattern: Standard Names. (line 416) 53736* usadM instruction pattern: Standard Names. (line 549) 53737* USAmode: Machine Modes. (line 166) 53738* usashlM3 instruction pattern: Standard Names. (line 730) 53739* usdivM3 instruction pattern: Standard Names. (line 416) 53740* use: Side Effects. (line 168) 53741* used: Flags. (line 325) 53742* used, in symbol_ref: Flags. (line 211) 53743* user: GTY Options. (line 245) 53744* user gc: User GC. (line 6) 53745* USER_LABEL_PREFIX: Instruction Output. (line 152) 53746* USE_C_ALLOCA: Host Misc. (line 19) 53747* USE_LD_AS_NEEDED: Driver. (line 135) 53748* USE_LOAD_POST_DECREMENT: Costs. (line 254) 53749* USE_LOAD_POST_INCREMENT: Costs. (line 249) 53750* USE_LOAD_PRE_DECREMENT: Costs. (line 264) 53751* USE_LOAD_PRE_INCREMENT: Costs. (line 259) 53752* USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 198) 53753* USE_STORE_POST_DECREMENT: Costs. (line 274) 53754* USE_STORE_POST_INCREMENT: Costs. (line 269) 53755* USE_STORE_PRE_DECREMENT: Costs. (line 284) 53756* USE_STORE_PRE_INCREMENT: Costs. (line 279) 53757* USING_STMT: Statements for C++. (line 6) 53758* usmaddMN4 instruction pattern: Standard Names. (line 682) 53759* usmsubMN4 instruction pattern: Standard Names. (line 706) 53760* usmulhisi3 instruction pattern: Standard Names. (line 650) 53761* usmulM3 instruction pattern: Standard Names. (line 416) 53762* usmulqihi3 instruction pattern: Standard Names. (line 650) 53763* usmulsidi3 instruction pattern: Standard Names. (line 650) 53764* usnegM2 instruction pattern: Standard Names. (line 754) 53765* USQmode: Machine Modes. (line 134) 53766* ussubM3 instruction pattern: Standard Names. (line 416) 53767* usubvM4 instruction pattern: Standard Names. (line 440) 53768* us_ashift: Arithmetic. (line 173) 53769* us_minus: Arithmetic. (line 38) 53770* us_mult: Arithmetic. (line 93) 53771* us_neg: Arithmetic. (line 82) 53772* us_plus: Arithmetic. (line 14) 53773* us_truncate: Conversions. (line 48) 53774* UTAmode: Machine Modes. (line 174) 53775* UTQmode: Machine Modes. (line 142) 53776* V in constraint: Simple Constraints. (line 43) 53777* values, returned by functions: Scalar Return. (line 6) 53778* varargs implementation: Varargs. (line 6) 53779* variable: Declarations. (line 6) 53780* Variable Location Debug Information in RTL: Debug Information. 53781 (line 6) 53782* VAR_DECL: Declarations. (line 6) 53783* var_location: Debug Information. (line 14) 53784* vashlM3 instruction pattern: Standard Names. (line 746) 53785* vashrM3 instruction pattern: Standard Names. (line 746) 53786* VA_ARG_EXPR: Unary and Binary Expressions. 53787 (line 6) 53788* vcondeqMN instruction pattern: Standard Names. (line 359) 53789* vcondMN instruction pattern: Standard Names. (line 346) 53790* vconduMN instruction pattern: Standard Names. (line 356) 53791* vcond_mask_MN instruction pattern: Standard Names. (line 366) 53792* vector: Containers. (line 6) 53793* vector operations: Vector Operations. (line 6) 53794* VECTOR_CST: Constant expressions. 53795 (line 6) 53796* VECTOR_STORE_FLAG_VALUE: Misc. (line 315) 53797* vec_cmpeqMN instruction pattern: Standard Names. (line 339) 53798* vec_cmpMN instruction pattern: Standard Names. (line 329) 53799* vec_cmpuMN instruction pattern: Standard Names. (line 336) 53800* vec_concat: Vector Operations. (line 28) 53801* VEC_COND_EXPR: Vectors. (line 6) 53802* vec_duplicate: Vector Operations. (line 33) 53803* vec_duplicateM instruction pattern: Standard Names. (line 297) 53804* VEC_DUPLICATE_EXPR: Vectors. (line 6) 53805* vec_extractMN instruction pattern: Standard Names. (line 281) 53806* vec_initMN instruction pattern: Standard Names. (line 290) 53807* vec_load_lanesMN instruction pattern: Standard Names. (line 165) 53808* VEC_LSHIFT_EXPR: Vectors. (line 6) 53809* vec_mask_load_lanesMN instruction pattern: Standard Names. (line 189) 53810* vec_mask_store_lanesMN instruction pattern: Standard Names. 53811 (line 219) 53812* vec_merge: Vector Operations. (line 11) 53813* VEC_PACK_FIX_TRUNC_EXPR: Vectors. (line 6) 53814* VEC_PACK_SAT_EXPR: Vectors. (line 6) 53815* vec_pack_sfix_trunc_M instruction pattern: Standard Names. (line 591) 53816* vec_pack_ssat_M instruction pattern: Standard Names. (line 584) 53817* VEC_PACK_TRUNC_EXPR: Vectors. (line 6) 53818* vec_pack_trunc_M instruction pattern: Standard Names. (line 577) 53819* vec_pack_ufix_trunc_M instruction pattern: Standard Names. (line 591) 53820* vec_pack_usat_M instruction pattern: Standard Names. (line 584) 53821* vec_permM instruction pattern: Standard Names. (line 384) 53822* vec_permM instruction pattern <1>: Addressing Modes. (line 330) 53823* VEC_RSHIFT_EXPR: Vectors. (line 6) 53824* vec_select: Vector Operations. (line 19) 53825* vec_series: Vector Operations. (line 40) 53826* vec_seriesM instruction pattern: Standard Names. (line 307) 53827* VEC_SERIES_EXPR: Vectors. (line 6) 53828* vec_setM instruction pattern: Standard Names. (line 276) 53829* vec_shl_insert_M instruction pattern: Standard Names. (line 564) 53830* vec_shr_M instruction pattern: Standard Names. (line 571) 53831* vec_store_lanesMN instruction pattern: Standard Names. (line 206) 53832* vec_unpacks_float_hi_M instruction pattern: Standard Names. 53833 (line 612) 53834* vec_unpacks_float_lo_M instruction pattern: Standard Names. 53835 (line 612) 53836* vec_unpacks_hi_M instruction pattern: Standard Names. (line 598) 53837* vec_unpacks_lo_M instruction pattern: Standard Names. (line 598) 53838* vec_unpacku_float_hi_M instruction pattern: Standard Names. 53839 (line 612) 53840* vec_unpacku_float_lo_M instruction pattern: Standard Names. 53841 (line 612) 53842* vec_unpacku_hi_M instruction pattern: Standard Names. (line 605) 53843* vec_unpacku_lo_M instruction pattern: Standard Names. (line 605) 53844* VEC_UNPACK_FLOAT_HI_EXPR: Vectors. (line 6) 53845* VEC_UNPACK_FLOAT_LO_EXPR: Vectors. (line 6) 53846* VEC_UNPACK_HI_EXPR: Vectors. (line 6) 53847* VEC_UNPACK_LO_EXPR: Vectors. (line 6) 53848* VEC_WIDEN_MULT_HI_EXPR: Vectors. (line 6) 53849* VEC_WIDEN_MULT_LO_EXPR: Vectors. (line 6) 53850* vec_widen_smult_even_M instruction pattern: Standard Names. 53851 (line 621) 53852* vec_widen_smult_hi_M instruction pattern: Standard Names. (line 621) 53853* vec_widen_smult_lo_M instruction pattern: Standard Names. (line 621) 53854* vec_widen_smult_odd_M instruction pattern: Standard Names. (line 621) 53855* vec_widen_sshiftl_hi_M instruction pattern: Standard Names. 53856 (line 632) 53857* vec_widen_sshiftl_lo_M instruction pattern: Standard Names. 53858 (line 632) 53859* vec_widen_umult_even_M instruction pattern: Standard Names. 53860 (line 621) 53861* vec_widen_umult_hi_M instruction pattern: Standard Names. (line 621) 53862* vec_widen_umult_lo_M instruction pattern: Standard Names. (line 621) 53863* vec_widen_umult_odd_M instruction pattern: Standard Names. (line 621) 53864* vec_widen_ushiftl_hi_M instruction pattern: Standard Names. 53865 (line 632) 53866* vec_widen_ushiftl_lo_M instruction pattern: Standard Names. 53867 (line 632) 53868* verify_flow_info: Maintaining the CFG. 53869 (line 116) 53870* virtual operands: SSA Operands. (line 6) 53871* VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59) 53872* VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87) 53873* VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78) 53874* VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69) 53875* VLIW: Processor pipeline description. 53876 (line 6) 53877* VLIW <1>: Processor pipeline description. 53878 (line 223) 53879* vlshrM3 instruction pattern: Standard Names. (line 746) 53880* VMS: Filesystem. (line 37) 53881* VMS_DEBUGGING_INFO: VMS Debug. (line 8) 53882* void: Misc. (line 708) 53883* void <1>: Misc. (line 713) 53884* VOIDmode: Machine Modes. (line 192) 53885* VOID_TYPE: Types. (line 6) 53886* volatil: Flags. (line 339) 53887* volatil, in insn, call_insn, jump_insn, code_label, jump_table_data, barrier, and note: Flags. 53888 (line 33) 53889* volatil, in label_ref and reg_label: Flags. (line 54) 53890* volatil, in mem, asm_operands, and asm_input: Flags. (line 65) 53891* volatil, in reg: Flags. (line 106) 53892* volatil, in subreg: Flags. (line 184) 53893* volatil, in subreg <1>: Flags. (line 194) 53894* volatil, in symbol_ref: Flags. (line 220) 53895* volatile memory references: Flags. (line 340) 53896* volatile, in prefetch: Flags. (line 92) 53897* voting between constraint alternatives: Class Preferences. (line 6) 53898* vrotlM3 instruction pattern: Standard Names. (line 746) 53899* vrotrM3 instruction pattern: Standard Names. (line 746) 53900* walk_dominator_tree: SSA. (line 195) 53901* walk_gimple_op: Statement and operand traversals. 53902 (line 30) 53903* walk_gimple_seq: Statement and operand traversals. 53904 (line 47) 53905* walk_gimple_stmt: Statement and operand traversals. 53906 (line 10) 53907* WCHAR_TYPE: Type Layout. (line 165) 53908* WCHAR_TYPE_SIZE: Type Layout. (line 173) 53909* which_alternative: Output Statement. (line 58) 53910* WHILE_BODY: Statements for C++. (line 6) 53911* WHILE_COND: Statements for C++. (line 6) 53912* WHILE_STMT: Statements for C++. (line 6) 53913* while_ultMN instruction pattern: Standard Names. (line 319) 53914* whopr: LTO. (line 6) 53915* widen_ssumM3 instruction pattern: Standard Names. (line 557) 53916* widen_usumM3 instruction pattern: Standard Names. (line 558) 53917* WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 110) 53918* window_save instruction pattern: Standard Names. (line 1914) 53919* WINT_TYPE: Type Layout. (line 178) 53920* WORDS_BIG_ENDIAN: Storage Layout. (line 28) 53921* WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 225) 53922* word_mode: Machine Modes. (line 462) 53923* WORD_REGISTER_OPERATIONS: Misc. (line 53) 53924* wpa: LTO. (line 6) 53925* X in constraint: Simple Constraints. (line 122) 53926* x-HOST: Host Fragment. (line 6) 53927* XCmode: Machine Modes. (line 199) 53928* XCOFF_DEBUGGING_INFO: DBX Options. (line 12) 53929* XEXP: Accessors. (line 6) 53930* XFmode: Machine Modes. (line 82) 53931* XImode: Machine Modes. (line 54) 53932* XINT: Accessors. (line 6) 53933* xm-MACHINE.h: Filesystem. (line 6) 53934* xm-MACHINE.h <1>: Host Misc. (line 6) 53935* xor: Arithmetic. (line 168) 53936* xor, canonicalization of: Insn Canonicalizations. 53937 (line 94) 53938* xorM3 instruction pattern: Standard Names. (line 416) 53939* XSTR: Accessors. (line 6) 53940* XVEC: Accessors. (line 38) 53941* XVECEXP: Accessors. (line 45) 53942* XVECLEN: Accessors. (line 41) 53943* XWINT: Accessors. (line 6) 53944* zero_extend: Conversions. (line 28) 53945* zero_extendMN2 instruction pattern: Standard Names. (line 1288) 53946* zero_extract: Bit-Fields. (line 30) 53947* zero_extract, canonicalization of: Insn Canonicalizations. 53948 (line 103) 53949 53950 53951 53952Tag Table: 53953Node: Top1789 53954Node: Contributing5036 53955Node: Portability5766 53956Node: Interface7554 53957Node: Libgcc10595 53958Node: Integer library routines12422 53959Node: Soft float library routines19390 53960Node: Decimal float library routines31328 53961Node: Fixed-point fractional library routines47086 53962Node: Exception handling routines147482 53963Node: Miscellaneous routines148589 53964Node: Languages150709 53965Node: Source Tree152256 53966Node: Configure Terms152838 53967Node: Top Level155794 53968Node: gcc Directory159224 53969Node: Subdirectories160176 53970Node: Configuration162344 53971Node: Config Fragments163064 53972Node: System Config164289 53973Node: Configuration Files165225 53974Node: Build167841 53975Node: Makefile168253 53976Ref: Makefile-Footnote-1175028 53977Ref: Makefile-Footnote-2175175 53978Node: Library Files175249 53979Node: Headers175811 53980Node: Documentation177894 53981Node: Texinfo Manuals178753 53982Node: Man Page Generation181082 53983Node: Miscellaneous Docs182995 53984Node: Front End184382 53985Node: Front End Directory188056 53986Node: Front End Config189372 53987Node: Front End Makefile192208 53988Node: Back End195976 53989Node: Testsuites200862 53990Node: Test Idioms201851 53991Node: Test Directives205249 53992Node: Directives205776 53993Node: Selectors217017 53994Node: Effective-Target Keywords218373 53995Ref: arm_fp_ok228937 53996Ref: arm_neon_ok230019 53997Ref: arm_neon_ok_no_float_abi230188 53998Ref: arm_neonv2_ok230355 53999Ref: arm_fp16_ok230522 54000Ref: arm_neon_fp16_ok230864 54001Ref: arm_vfp3_ok231740 54002Ref: arm_v8_1a_neon_ok232166 54003Ref: arm_v8_2a_fp16_scalar_ok232594 54004Ref: arm_v8_2a_fp16_neon_ok233045 54005Ref: arm_v8_2a_dotprod_neon_ok233520 54006Ref: arm_fp16fml_neon_ok233940 54007Ref: arm_coproc1_ok234782 54008Ref: arm_coproc2_ok234908 54009Ref: arm_coproc3_ok235136 54010Ref: stack_size_et245500 54011Node: Add Options247803 54012Ref: arm_fp16_ieee248821 54013Ref: arm_fp16_alternative249076 54014Ref: stack_size_ao251327 54015Node: Require Support251576 54016Node: Final Actions254405 54017Node: Ada Tests260064 54018Node: C Tests261227 54019Node: LTO Testing265599 54020Node: gcov Testing267242 54021Node: profopt Testing270232 54022Node: compat Testing271947 54023Node: Torture Tests276187 54024Node: GIMPLE Tests277821 54025Node: RTL Tests279064 54026Node: Options280370 54027Node: Option file format280811 54028Node: Option properties287800 54029Node: Passes301774 54030Node: Parsing pass302590 54031Node: Gimplification pass306118 54032Node: Pass manager307951 54033Node: Tree SSA passes309797 54034Node: RTL passes331339 54035Node: Optimization info343603 54036Node: Dump setup344422 54037Node: Optimization groups345551 54038Node: Dump files and streams346530 54039Node: Dump output verbosity347728 54040Node: Dump types348784 54041Node: Dump examples350274 54042Node: poly_int351755 54043Node: Overview of poly_int353235 54044Node: Consequences of using poly_int355839 54045Node: Comparisons involving poly_int357474 54046Node: Comparison functions for poly_int359112 54047Node: Properties of the poly_int comparisons360319 54048Node: Comparing potentially-unordered poly_ints362761 54049Node: Comparing ordered poly_ints363672 54050Node: Checking for a poly_int marker value365696 54051Node: Range checks on poly_ints366545 54052Node: Sorting poly_ints369199 54053Node: Arithmetic on poly_ints369972 54054Node: Using poly_int with C++ arithmetic operators370773 54055Node: wi arithmetic on poly_ints372304 54056Node: Division of poly_ints373156 54057Node: Other poly_int arithmetic374663 54058Node: Alignment of poly_ints376069 54059Node: Computing bounds on poly_ints379346 54060Node: Converting poly_ints380127 54061Node: Miscellaneous poly_int routines383674 54062Node: Guidelines for using poly_int384314 54063Node: GENERIC389246 54064Node: Deficiencies391124 54065Node: Tree overview391365 54066Node: Macros and Functions395489 54067Node: Identifiers396314 54068Node: Containers397923 54069Node: Types399080 54070Node: Declarations411154 54071Node: Working with declarations411649 54072Node: Internal structure417253 54073Node: Current structure hierarchy417637 54074Node: Adding new DECL node types419730 54075Node: Attributes424014 54076Node: Expression trees425258 54077Node: Constant expressions427012 54078Node: Storage References433104 54079Node: Unary and Binary Expressions436623 54080Node: Vectors457309 54081Node: Statements462978 54082Node: Basic Statements463510 54083Node: Blocks468137 54084Node: Statement Sequences469838 54085Node: Empty Statements470171 54086Node: Jumps470745 54087Node: Cleanups471398 54088Node: OpenMP473165 54089Node: OpenACC479010 54090Node: Functions480051 54091Node: Function Basics480522 54092Node: Function Properties484206 54093Node: Language-dependent trees486987 54094Node: C and C++ Trees487874 54095Node: Types for C++490778 54096Node: Namespaces495748 54097Node: Classes498854 54098Node: Functions for C++503762 54099Node: Statements for C++510013 54100Node: C++ Expressions518066 54101Node: Java Trees519571 54102Node: GIMPLE519684 54103Node: Tuple representation523349 54104Node: Class hierarchy of GIMPLE statements530309 54105Node: GIMPLE instruction set535297 54106Node: GIMPLE Exception Handling536929 54107Node: Temporaries538841 54108Ref: Temporaries-Footnote-1540159 54109Node: Operands540224 54110Node: Compound Expressions540985 54111Node: Compound Lvalues541219 54112Node: Conditional Expressions541981 54113Node: Logical Operators542640 54114Node: Manipulating GIMPLE statements549988 54115Node: Tuple specific accessors555924 54116Node: GIMPLE_ASM556703 54117Node: GIMPLE_ASSIGN559086 54118Node: GIMPLE_BIND563790 54119Node: GIMPLE_CALL565604 54120Node: GIMPLE_CATCH569747 54121Node: GIMPLE_COND570897 54122Node: GIMPLE_DEBUG573692 54123Node: GIMPLE_EH_FILTER578290 54124Node: GIMPLE_LABEL579853 54125Node: GIMPLE_GOTO580466 54126Node: GIMPLE_NOP580989 54127Node: GIMPLE_OMP_ATOMIC_LOAD581351 54128Node: GIMPLE_OMP_ATOMIC_STORE582347 54129Node: GIMPLE_OMP_CONTINUE583046 54130Node: GIMPLE_OMP_CRITICAL584525 54131Node: GIMPLE_OMP_FOR585519 54132Node: GIMPLE_OMP_MASTER588935 54133Node: GIMPLE_OMP_ORDERED589313 54134Node: GIMPLE_OMP_PARALLEL589707 54135Node: GIMPLE_OMP_RETURN592476 54136Node: GIMPLE_OMP_SECTION593121 54137Node: GIMPLE_OMP_SECTIONS593781 54138Node: GIMPLE_OMP_SINGLE595391 54139Node: GIMPLE_PHI596337 54140Node: GIMPLE_RESX597616 54141Node: GIMPLE_RETURN598335 54142Node: GIMPLE_SWITCH598909 54143Node: GIMPLE_TRY600784 54144Node: GIMPLE_WITH_CLEANUP_EXPR602556 54145Node: GIMPLE sequences603435 54146Node: Sequence iterators606641 54147Node: Adding a new GIMPLE statement code615098 54148Node: Statement and operand traversals616443 54149Node: Tree SSA619035 54150Node: Annotations620823 54151Node: SSA Operands621228 54152Node: SSA635303 54153Node: Alias analysis645009 54154Node: Memory model648783 54155Node: RTL650142 54156Node: RTL Objects652330 54157Node: RTL Classes656214 54158Node: Accessors661346 54159Node: Special Accessors663519 54160Node: Flags669306 54161Node: Machine Modes684569 54162Node: Constants702102 54163Node: Regs and Memory713381 54164Node: Arithmetic732633 54165Node: Comparisons742679 54166Node: Bit-Fields746971 54167Node: Vector Operations748523 54168Node: Conversions750556 54169Node: RTL Declarations755054 54170Node: Side Effects755898 54171Node: Incdec772909 54172Node: Assembler776245 54173Node: Debug Information777790 54174Node: Insns779717 54175Node: Calls807610 54176Node: Sharing810203 54177Node: Reading RTL813398 54178Node: Control Flow814389 54179Node: Basic Blocks816158 54180Node: Edges821612 54181Node: Profile information830231 54182Node: Maintaining the CFG834915 54183Node: Liveness information840683 54184Node: Loop Analysis and Representation842809 54185Node: Loop representation843845 54186Node: Loop querying851408 54187Node: Loop manipulation854229 54188Node: LCSSA856565 54189Node: Scalar evolutions858634 54190Node: loop-iv861878 54191Node: Number of iterations863800 54192Node: Dependency analysis867881 54193Node: Machine Desc874232 54194Node: Overview876795 54195Node: Patterns878835 54196Node: Example883144 54197Node: RTL Template884605 54198Node: Output Template895261 54199Node: Output Statement899442 54200Node: Predicates903781 54201Node: Machine-Independent Predicates906699 54202Node: Defining Predicates911643 54203Node: Constraints917606 54204Node: Simple Constraints919075 54205Node: Multi-Alternative931915 54206Node: Class Preferences935124 54207Node: Modifiers936016 54208Node: Machine Constraints940749 54209Node: Disable Insn Alternatives1003438 54210Node: Define Constraints1006930 54211Node: C Constraint Interface1014325 54212Node: Standard Names1017452 54213Ref: shift patterns1049498 54214Ref: prologue instruction pattern1101152 54215Ref: window_save instruction pattern1101645 54216Ref: epilogue instruction pattern1101922 54217Node: Pattern Ordering1121078 54218Node: Dependent Patterns1122314 54219Node: Jump Patterns1123934 54220Ref: Jump Patterns-Footnote-11126081 54221Node: Looping Patterns1126129 54222Node: Insn Canonicalizations1130858 54223Node: Expander Definitions1136065 54224Node: Insn Splitting1144279 54225Node: Including Patterns1153883 54226Node: Peephole Definitions1155667 54227Node: define_peephole1156920 54228Node: define_peephole21163250 54229Node: Insn Attributes1166316 54230Node: Defining Attributes1167498 54231Ref: define_enum_attr1170991 54232Node: Expressions1172027 54233Node: Tagging Insns1178777 54234Node: Attr Example1183130 54235Node: Insn Lengths1185503 54236Node: Constant Attributes1188911 54237Node: Mnemonic Attribute1190087 54238Node: Delay Slots1191606 54239Node: Processor pipeline description1194829 54240Ref: Processor pipeline description-Footnote-11213646 54241Node: Conditional Execution1213970 54242Node: Define Subst1217453 54243Node: Define Subst Example1219489 54244Node: Define Subst Pattern Matching1222483 54245Node: Define Subst Output Template1223709 54246Node: Constant Definitions1225779 54247Ref: define_enum1229561 54248Node: Iterators1230049 54249Node: Mode Iterators1230627 54250Node: Defining Mode Iterators1231605 54251Node: Substitutions1233099 54252Node: Examples1235341 54253Node: Code Iterators1236789 54254Node: Int Iterators1239068 54255Node: Subst Iterators1241514 54256Node: Target Macros1243206 54257Node: Target Structure1246218 54258Node: Driver1248334 54259Node: Run-time Target1267304 54260Node: Per-Function Data1277015 54261Node: Storage Layout1279779 54262Node: Type Layout1307096 54263Node: Registers1320437 54264Node: Register Basics1321411 54265Node: Allocation Order1327036 54266Node: Values in Registers1329520 54267Node: Leaf Functions1336996 54268Node: Stack Registers1339855 54269Node: Register Classes1341127 54270Node: Stack and Calling1375909 54271Node: Frame Layout1376515 54272Node: Exception Handling1388350 54273Node: Stack Checking1394560 54274Node: Frame Registers1399936 54275Node: Elimination1408487 54276Node: Stack Arguments1412343 54277Node: Register Arguments1419539 54278Node: Scalar Return1443423 54279Node: Aggregate Return1449879 54280Node: Caller Saves1454433 54281Node: Function Entry1455175 54282Node: Profiling1466727 54283Node: Tail Calls1468837 54284Node: Shrink-wrapping separate components1470748 54285Node: Stack Smashing Protection1473789 54286Node: Miscellaneous Register Hooks1475712 54287Node: Varargs1476578 54288Node: Trampolines1486682 54289Node: Library Calls1493846 54290Node: Addressing Modes1498530 54291Node: Anchored Addresses1524716 54292Node: Condition Code1527359 54293Node: CC0 Condition Codes1529686 54294Node: MODE_CC Condition Codes1532932 54295Node: Costs1539728 54296Node: Scheduling1561100 54297Node: Sections1585022 54298Node: PIC1600951 54299Node: Assembler Format1603010 54300Node: File Framework1604148 54301Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS1611747 54302Node: Data Output1615017 54303Node: Uninitialized Data1622963 54304Node: Label Output1627977 54305Node: Initialization1652588 54306Node: Macros for Initialization1658549 54307Node: Instruction Output1665268 54308Node: Dispatch Tables1675897 54309Node: Exception Region Output1680297 54310Node: Alignment Output1687379 54311Node: Debugging Info1691982 54312Node: All Debuggers1692636 54313Node: DBX Options1695408 54314Node: DBX Hooks1700846 54315Node: File Names and DBX1702155 54316Node: DWARF1704259 54317Node: VMS Debug1710074 54318Node: Floating Point1710653 54319Node: Mode Switching1713408 54320Node: Target Attributes1717845 54321Node: Emulated TLS1726811 54322Node: MIPS Coprocessors1730201 54323Node: PCH Target1731360 54324Node: C++ ABI1733202 54325Node: Named Address Spaces1737996 54326Node: Misc1743912 54327Ref: TARGET_SHIFT_TRUNCATION_MASK1751783 54328Node: Host Config1807227 54329Node: Host Common1808296 54330Node: Filesystem1810670 54331Node: Host Misc1814785 54332Node: Fragments1817234 54333Node: Target Fragment1818429 54334Node: Host Fragment1829242 54335Node: Collect21829482 54336Node: Header Dirs1832118 54337Node: Type Information1833541 54338Node: GTY Options1836817 54339Node: Inheritance and GTY1848076 54340Ref: Inheritance and GTY-Footnote-11849641 54341Node: User GC1849911 54342Node: GGC Roots1853650 54343Node: Files1854363 54344Node: Invoking the garbage collector1857070 54345Node: Troubleshooting1858575 54346Node: Plugins1859650 54347Node: Plugins loading1860779 54348Node: Plugin API1861878 54349Node: Plugins pass1869604 54350Node: Plugins GC1871575 54351Node: Plugins description1873293 54352Node: Plugins attr1873829 54353Node: Plugins recording1876109 54354Node: Plugins gate1876959 54355Node: Plugins tracking1877550 54356Node: Plugins building1878138 54357Node: LTO1881640 54358Node: LTO Overview1882512 54359Node: LTO object file layout1888339 54360Node: IPA1892969 54361Node: WHOPR1901934 54362Node: Internal flags1906494 54363Node: Match and Simplify1907905 54364Node: GIMPLE API1908859 54365Node: The Language1911654 54366Node: Funding1923017 54367Node: GNU Project1925516 54368Node: Copying1926165 54369Node: GNU Free Documentation License1963677 54370Node: Contributors1988798 54371Node: Option Index2029736 54372Node: Concept Index2030613 54373 54374End Tag Table 54375 54376 54377Local Variables: 54378coding: utf-8 54379End: 54380