1This is gccint.info, produced by makeinfo version 6.5 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 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.3.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 by SVN (see 122<http://gcc.gnu.org/svn.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 additional files for a test 4479........................................... 4480 4481'{ dg-additional-files "FILELIST" }' 4482 Specify additional files, other than source files, that must be 4483 copied to the system where the compiler runs. 4484 4485'{ dg-additional-sources "FILELIST" }' 4486 Specify additional source files to appear in the compile line 4487 following the main test file. 4488 44897.2.1.10 Add checks at the end of a test 4490........................................ 4491 4492'{ dg-final { LOCAL-DIRECTIVE } }' 4493 This DejaGnu directive is placed within a comment anywhere in the 4494 source file and is processed after the test has been compiled and 4495 run. Multiple 'dg-final' commands are processed in the order in 4496 which they appear in the source file. *Note Final Actions::, for a 4497 list of directives that can be used within 'dg-final'. 4498 4499 4500File: gccint.info, Node: Selectors, Next: Effective-Target Keywords, Prev: Directives, Up: Test Directives 4501 45027.2.2 Selecting targets to which a test applies 4503----------------------------------------------- 4504 4505Several test directives include SELECTORs to limit the targets for which 4506a test is run or to declare that a test is expected to fail on 4507particular targets. 4508 4509 A selector is: 4510 * one or more target triplets, possibly including wildcard 4511 characters; use '*-*-*' to match any target 4512 * a single effective-target keyword (*note Effective-Target 4513 Keywords::) 4514 * a logical expression 4515 4516 Depending on the context, the selector specifies whether a test is 4517skipped and reported as unsupported or is expected to fail. A context 4518that allows either 'target' or 'xfail' also allows '{ target SELECTOR1 4519xfail SELECTOR2 }' to skip the test for targets that don't match 4520SELECTOR1 and the test to fail for targets that match SELECTOR2. 4521 4522 A selector expression appears within curly braces and uses a single 4523logical operator: one of '!', '&&', or '||'. An operand is another 4524selector expression, an effective-target keyword, a single target 4525triplet, or a list of target triplets within quotes or curly braces. 4526For example: 4527 4528 { target { ! "hppa*-*-* ia64*-*-*" } } 4529 { target { powerpc*-*-* && lp64 } } 4530 { xfail { lp64 || vect_no_align } } 4531 4532 4533File: gccint.info, Node: Effective-Target Keywords, Next: Add Options, Prev: Selectors, Up: Test Directives 4534 45357.2.3 Keywords describing target attributes 4536------------------------------------------- 4537 4538Effective-target keywords identify sets of targets that support 4539particular functionality. They are used to limit tests to be run only 4540for particular targets, or to specify that particular sets of targets 4541are expected to fail some tests. 4542 4543 Effective-target keywords are defined in 'lib/target-supports.exp' in 4544the GCC testsuite, with the exception of those that are documented as 4545being local to a particular test directory. 4546 4547 The 'effective target' takes into account all of the compiler options 4548with which the test will be compiled, including the multilib options. 4549By convention, keywords ending in '_nocache' can also include options 4550specified for the particular test in an earlier 'dg-options' or 4551'dg-add-options' directive. 4552 45537.2.3.1 Endianness 4554.................. 4555 4556'be' 4557 Target uses big-endian memory order for multi-byte and multi-word 4558 data. 4559 4560'le' 4561 Target uses little-endian memory order for multi-byte and 4562 multi-word data. 4563 45647.2.3.2 Data type sizes 4565....................... 4566 4567'ilp32' 4568 Target has 32-bit 'int', 'long', and pointers. 4569 4570'lp64' 4571 Target has 32-bit 'int', 64-bit 'long' and pointers. 4572 4573'llp64' 4574 Target has 32-bit 'int' and 'long', 64-bit 'long long' and 4575 pointers. 4576 4577'double64' 4578 Target has 64-bit 'double'. 4579 4580'double64plus' 4581 Target has 'double' that is 64 bits or longer. 4582 4583'longdouble128' 4584 Target has 128-bit 'long double'. 4585 4586'int32plus' 4587 Target has 'int' that is at 32 bits or longer. 4588 4589'int16' 4590 Target has 'int' that is 16 bits or shorter. 4591 4592'long_neq_int' 4593 Target has 'int' and 'long' with different sizes. 4594 4595'large_double' 4596 Target supports 'double' that is longer than 'float'. 4597 4598'large_long_double' 4599 Target supports 'long double' that is longer than 'double'. 4600 4601'ptr32plus' 4602 Target has pointers that are 32 bits or longer. 4603 4604'size32plus' 4605 Target supports array and structure sizes that are 32 bits or 4606 longer. 4607 4608'4byte_wchar_t' 4609 Target has 'wchar_t' that is at least 4 bytes. 4610 4611'floatN' 4612 Target has the '_FloatN' type. 4613 4614'floatNx' 4615 Target has the '_FloatNx' type. 4616 4617'floatN_runtime' 4618 Target has the '_FloatN' type, including runtime support for any 4619 options added with 'dg-add-options'. 4620 4621'floatNx_runtime' 4622 Target has the '_FloatNx' type, including runtime support for any 4623 options added with 'dg-add-options'. 4624 4625'floatn_nx_runtime' 4626 Target has runtime support for any options added with 4627 'dg-add-options' for any '_FloatN' or '_FloatNx' type. 4628 46297.2.3.3 Fortran-specific attributes 4630................................... 4631 4632'fortran_integer_16' 4633 Target supports Fortran 'integer' that is 16 bytes or longer. 4634 4635'fortran_real_10' 4636 Target supports Fortran 'real' that is 10 bytes or longer. 4637 4638'fortran_real_16' 4639 Target supports Fortran 'real' that is 16 bytes or longer. 4640 4641'fortran_large_int' 4642 Target supports Fortran 'integer' kinds larger than 'integer(8)'. 4643 4644'fortran_large_real' 4645 Target supports Fortran 'real' kinds larger than 'real(8)'. 4646 46477.2.3.4 Vector-specific attributes 4648.................................. 4649 4650'vect_align_stack_vars' 4651 The target's ABI allows stack variables to be aligned to the 4652 preferred vector alignment. 4653 4654'vect_condition' 4655 Target supports vector conditional operations. 4656 4657'vect_cond_mixed' 4658 Target supports vector conditional operations where comparison 4659 operands have different type from the value operands. 4660 4661'vect_double' 4662 Target supports hardware vectors of 'double'. 4663 4664'vect_element_align_preferred' 4665 The target's preferred vector alignment is the same as the element 4666 alignment. 4667 4668'vect_float' 4669 Target supports hardware vectors of 'float' when 4670 '-funsafe-math-optimizations' is in effect. 4671 4672'vect_float_strict' 4673 Target supports hardware vectors of 'float' when 4674 '-funsafe-math-optimizations' is not in effect. This implies 4675 'vect_float'. 4676 4677'vect_int' 4678 Target supports hardware vectors of 'int'. 4679 4680'vect_long' 4681 Target supports hardware vectors of 'long'. 4682 4683'vect_long_long' 4684 Target supports hardware vectors of 'long long'. 4685 4686'vect_fully_masked' 4687 Target supports fully-masked (also known as fully-predicated) 4688 loops, so that vector loops can handle partial as well as full 4689 vectors. 4690 4691'vect_masked_store' 4692 Target supports vector masked stores. 4693 4694'vect_scatter_store' 4695 Target supports vector scatter stores. 4696 4697'vect_aligned_arrays' 4698 Target aligns arrays to vector alignment boundary. 4699 4700'vect_hw_misalign' 4701 Target supports a vector misalign access. 4702 4703'vect_no_align' 4704 Target does not support a vector alignment mechanism. 4705 4706'vect_peeling_profitable' 4707 Target might require to peel loops for alignment purposes. 4708 4709'vect_no_int_min_max' 4710 Target does not support a vector min and max instruction on 'int'. 4711 4712'vect_no_int_add' 4713 Target does not support a vector add instruction on 'int'. 4714 4715'vect_no_bitwise' 4716 Target does not support vector bitwise instructions. 4717 4718'vect_char_mult' 4719 Target supports 'vector char' multiplication. 4720 4721'vect_short_mult' 4722 Target supports 'vector short' multiplication. 4723 4724'vect_int_mult' 4725 Target supports 'vector int' multiplication. 4726 4727'vect_long_mult' 4728 Target supports 64 bit 'vector long' multiplication. 4729 4730'vect_extract_even_odd' 4731 Target supports vector even/odd element extraction. 4732 4733'vect_extract_even_odd_wide' 4734 Target supports vector even/odd element extraction of vectors with 4735 elements 'SImode' or larger. 4736 4737'vect_interleave' 4738 Target supports vector interleaving. 4739 4740'vect_strided' 4741 Target supports vector interleaving and extract even/odd. 4742 4743'vect_strided_wide' 4744 Target supports vector interleaving and extract even/odd for wide 4745 element types. 4746 4747'vect_perm' 4748 Target supports vector permutation. 4749 4750'vect_perm_byte' 4751 Target supports permutation of vectors with 8-bit elements. 4752 4753'vect_perm_short' 4754 Target supports permutation of vectors with 16-bit elements. 4755 4756'vect_perm3_byte' 4757 Target supports permutation of vectors with 8-bit elements, and for 4758 the default vector length it is possible to permute: 4759 { a0, a1, a2, b0, b1, b2, ... } 4760 to: 4761 { a0, a0, a0, b0, b0, b0, ... } 4762 { a1, a1, a1, b1, b1, b1, ... } 4763 { a2, a2, a2, b2, b2, b2, ... } 4764 using only two-vector permutes, regardless of how long the sequence 4765 is. 4766 4767'vect_perm3_int' 4768 Like 'vect_perm3_byte', but for 32-bit elements. 4769 4770'vect_perm3_short' 4771 Like 'vect_perm3_byte', but for 16-bit elements. 4772 4773'vect_shift' 4774 Target supports a hardware vector shift operation. 4775 4776'vect_unaligned_possible' 4777 Target prefers vectors to have an alignment greater than element 4778 alignment, but also allows unaligned vector accesses in some 4779 circumstances. 4780 4781'vect_variable_length' 4782 Target has variable-length vectors. 4783 4784'vect_widen_sum_hi_to_si' 4785 Target supports a vector widening summation of 'short' operands 4786 into 'int' results, or can promote (unpack) from 'short' to 'int'. 4787 4788'vect_widen_sum_qi_to_hi' 4789 Target supports a vector widening summation of 'char' operands into 4790 'short' results, or can promote (unpack) from 'char' to 'short'. 4791 4792'vect_widen_sum_qi_to_si' 4793 Target supports a vector widening summation of 'char' operands into 4794 'int' results. 4795 4796'vect_widen_mult_qi_to_hi' 4797 Target supports a vector widening multiplication of 'char' operands 4798 into 'short' results, or can promote (unpack) from 'char' to 4799 'short' and perform non-widening multiplication of 'short'. 4800 4801'vect_widen_mult_hi_to_si' 4802 Target supports a vector widening multiplication of 'short' 4803 operands into 'int' results, or can promote (unpack) from 'short' 4804 to 'int' and perform non-widening multiplication of 'int'. 4805 4806'vect_widen_mult_si_to_di_pattern' 4807 Target supports a vector widening multiplication of 'int' operands 4808 into 'long' results. 4809 4810'vect_sdot_qi' 4811 Target supports a vector dot-product of 'signed char'. 4812 4813'vect_udot_qi' 4814 Target supports a vector dot-product of 'unsigned char'. 4815 4816'vect_sdot_hi' 4817 Target supports a vector dot-product of 'signed short'. 4818 4819'vect_udot_hi' 4820 Target supports a vector dot-product of 'unsigned short'. 4821 4822'vect_pack_trunc' 4823 Target supports a vector demotion (packing) of 'short' to 'char' 4824 and from 'int' to 'short' using modulo arithmetic. 4825 4826'vect_unpack' 4827 Target supports a vector promotion (unpacking) of 'char' to 'short' 4828 and from 'char' to 'int'. 4829 4830'vect_intfloat_cvt' 4831 Target supports conversion from 'signed int' to 'float'. 4832 4833'vect_uintfloat_cvt' 4834 Target supports conversion from 'unsigned int' to 'float'. 4835 4836'vect_floatint_cvt' 4837 Target supports conversion from 'float' to 'signed int'. 4838 4839'vect_floatuint_cvt' 4840 Target supports conversion from 'float' to 'unsigned int'. 4841 4842'vect_intdouble_cvt' 4843 Target supports conversion from 'signed int' to 'double'. 4844 4845'vect_doubleint_cvt' 4846 Target supports conversion from 'double' to 'signed int'. 4847 4848'vect_max_reduc' 4849 Target supports max reduction for vectors. 4850 4851'vect_sizes_16B_8B' 4852 Target supports 16- and 8-bytes vectors. 4853 4854'vect_sizes_32B_16B' 4855 Target supports 32- and 16-bytes vectors. 4856 4857'vect_logical_reduc' 4858 Target supports AND, IOR and XOR reduction on vectors. 4859 4860'vect_fold_extract_last' 4861 Target supports the 'fold_extract_last' optab. 4862 48637.2.3.5 Thread Local Storage attributes 4864....................................... 4865 4866'tls' 4867 Target supports thread-local storage. 4868 4869'tls_native' 4870 Target supports native (rather than emulated) thread-local storage. 4871 4872'tls_runtime' 4873 Test system supports executing TLS executables. 4874 48757.2.3.6 Decimal floating point attributes 4876......................................... 4877 4878'dfp' 4879 Targets supports compiling decimal floating point extension to C. 4880 4881'dfp_nocache' 4882 Including the options used to compile this particular test, the 4883 target supports compiling decimal floating point extension to C. 4884 4885'dfprt' 4886 Test system can execute decimal floating point tests. 4887 4888'dfprt_nocache' 4889 Including the options used to compile this particular test, the 4890 test system can execute decimal floating point tests. 4891 4892'hard_dfp' 4893 Target generates decimal floating point instructions with current 4894 options. 4895 48967.2.3.7 ARM-specific attributes 4897............................... 4898 4899'arm32' 4900 ARM target generates 32-bit code. 4901 4902'arm_eabi' 4903 ARM target adheres to the ABI for the ARM Architecture. 4904 4905'arm_fp_ok' 4906 ARM target defines '__ARM_FP' using '-mfloat-abi=softfp' or 4907 equivalent options. Some multilibs may be incompatible with these 4908 options. 4909 4910'arm_hf_eabi' 4911 ARM target adheres to the VFP and Advanced SIMD Register Arguments 4912 variant of the ABI for the ARM Architecture (as selected with 4913 '-mfloat-abi=hard'). 4914 4915'arm_softfloat' 4916 ARM target uses the soft-float ABI with no floating-point 4917 instructions used whatsoever (as selected with '-mfloat-abi=soft'). 4918 4919'arm_hard_vfp_ok' 4920 ARM target supports '-mfpu=vfp -mfloat-abi=hard'. Some multilibs 4921 may be incompatible with these options. 4922 4923'arm_iwmmxt_ok' 4924 ARM target supports '-mcpu=iwmmxt'. Some multilibs may be 4925 incompatible with this option. 4926 4927'arm_neon' 4928 ARM target supports generating NEON instructions. 4929 4930'arm_tune_string_ops_prefer_neon' 4931 Test CPU tune supports inlining string operations with NEON 4932 instructions. 4933 4934'arm_neon_hw' 4935 Test system supports executing NEON instructions. 4936 4937'arm_neonv2_hw' 4938 Test system supports executing NEON v2 instructions. 4939 4940'arm_neon_ok' 4941 ARM Target supports '-mfpu=neon -mfloat-abi=softfp' or compatible 4942 options. Some multilibs may be incompatible with these options. 4943 4944'arm_neon_ok_no_float_abi' 4945 ARM Target supports NEON with '-mfpu=neon', but without any 4946 -mfloat-abi= option. Some multilibs may be incompatible with this 4947 option. 4948 4949'arm_neonv2_ok' 4950 ARM Target supports '-mfpu=neon-vfpv4 -mfloat-abi=softfp' or 4951 compatible options. Some multilibs may be incompatible with these 4952 options. 4953 4954'arm_fp16_ok' 4955 Target supports options to generate VFP half-precision 4956 floating-point instructions. Some multilibs may be incompatible 4957 with these options. This test is valid for ARM only. 4958 4959'arm_fp16_hw' 4960 Target supports executing VFP half-precision floating-point 4961 instructions. This test is valid for ARM only. 4962 4963'arm_neon_fp16_ok' 4964 ARM Target supports '-mfpu=neon-fp16 -mfloat-abi=softfp' or 4965 compatible options, including '-mfp16-format=ieee' if necessary to 4966 obtain the '__fp16' type. Some multilibs may be incompatible with 4967 these options. 4968 4969'arm_neon_fp16_hw' 4970 Test system supports executing Neon half-precision float 4971 instructions. (Implies previous.) 4972 4973'arm_fp16_alternative_ok' 4974 ARM target supports the ARM FP16 alternative format. Some 4975 multilibs may be incompatible with the options needed. 4976 4977'arm_fp16_none_ok' 4978 ARM target supports specifying none as the ARM FP16 format. 4979 4980'arm_thumb1_ok' 4981 ARM target generates Thumb-1 code for '-mthumb'. 4982 4983'arm_thumb2_ok' 4984 ARM target generates Thumb-2 code for '-mthumb'. 4985 4986'arm_vfp_ok' 4987 ARM target supports '-mfpu=vfp -mfloat-abi=softfp'. Some multilibs 4988 may be incompatible with these options. 4989 4990'arm_vfp3_ok' 4991 ARM target supports '-mfpu=vfp3 -mfloat-abi=softfp'. Some 4992 multilibs may be incompatible with these options. 4993 4994'arm_v8_vfp_ok' 4995 ARM target supports '-mfpu=fp-armv8 -mfloat-abi=softfp'. Some 4996 multilibs may be incompatible with these options. 4997 4998'arm_v8_neon_ok' 4999 ARM target supports '-mfpu=neon-fp-armv8 -mfloat-abi=softfp'. Some 5000 multilibs may be incompatible with these options. 5001 5002'arm_v8_1a_neon_ok' 5003 ARM target supports options to generate ARMv8.1-A Adv.SIMD 5004 instructions. Some multilibs may be incompatible with these 5005 options. 5006 5007'arm_v8_1a_neon_hw' 5008 ARM target supports executing ARMv8.1-A Adv.SIMD instructions. 5009 Some multilibs may be incompatible with the options needed. 5010 Implies arm_v8_1a_neon_ok. 5011 5012'arm_acq_rel' 5013 ARM target supports acquire-release instructions. 5014 5015'arm_v8_2a_fp16_scalar_ok' 5016 ARM target supports options to generate instructions for ARMv8.2-A 5017 and scalar instructions from the FP16 extension. Some multilibs 5018 may be incompatible with these options. 5019 5020'arm_v8_2a_fp16_scalar_hw' 5021 ARM target supports executing instructions for ARMv8.2-A and scalar 5022 instructions from the FP16 extension. Some multilibs may be 5023 incompatible with these options. Implies arm_v8_2a_fp16_neon_ok. 5024 5025'arm_v8_2a_fp16_neon_ok' 5026 ARM target supports options to generate instructions from ARMv8.2-A 5027 with the FP16 extension. Some multilibs may be incompatible with 5028 these options. Implies arm_v8_2a_fp16_scalar_ok. 5029 5030'arm_v8_2a_fp16_neon_hw' 5031 ARM target supports executing instructions from ARMv8.2-A with the 5032 FP16 extension. Some multilibs may be incompatible with these 5033 options. Implies arm_v8_2a_fp16_neon_ok and 5034 arm_v8_2a_fp16_scalar_hw. 5035 5036'arm_v8_2a_dotprod_neon_ok' 5037 ARM target supports options to generate instructions from ARMv8.2-A 5038 with the Dot Product extension. Some multilibs may be incompatible 5039 with these options. 5040 5041'arm_v8_2a_dotprod_neon_hw' 5042 ARM target supports executing instructions from ARMv8.2-A with the 5043 Dot Product extension. Some multilibs may be incompatible with 5044 these options. Implies arm_v8_2a_dotprod_neon_ok. 5045 5046'arm_fp16fml_neon_ok' 5047 ARM target supports extensions to generate the 'VFMAL' and 'VFMLS' 5048 half-precision floating-point instructions available from ARMv8.2-A 5049 and onwards. Some multilibs may be incompatible with these 5050 options. 5051 5052'arm_prefer_ldrd_strd' 5053 ARM target prefers 'LDRD' and 'STRD' instructions over 'LDM' and 5054 'STM' instructions. 5055 5056'arm_thumb1_movt_ok' 5057 ARM target generates Thumb-1 code for '-mthumb' with 'MOVW' and 5058 'MOVT' instructions available. 5059 5060'arm_thumb1_cbz_ok' 5061 ARM target generates Thumb-1 code for '-mthumb' with 'CBZ' and 5062 'CBNZ' instructions available. 5063 5064'arm_divmod_simode' 5065 ARM target for which divmod transform is disabled, if it supports 5066 hardware div instruction. 5067 5068'arm_cmse_ok' 5069 ARM target supports ARMv8-M Security Extensions, enabled by the 5070 '-mcmse' option. 5071 5072'arm_coproc1_ok' 5073 ARM target supports the following coprocessor instructions: 'CDP', 5074 'LDC', 'STC', 'MCR' and 'MRC'. 5075 5076'arm_coproc2_ok' 5077 ARM target supports all the coprocessor instructions also listed as 5078 supported in *note arm_coproc1_ok:: in addition to the following: 5079 'CDP2', 'LDC2', 'LDC2l', 'STC2', 'STC2l', 'MCR2' and 'MRC2'. 5080 5081'arm_coproc3_ok' 5082 ARM target supports all the coprocessor instructions also listed as 5083 supported in *note arm_coproc2_ok:: in addition the following: 5084 'MCRR' and 'MRRC'. 5085 5086'arm_coproc4_ok' 5087 ARM target supports all the coprocessor instructions also listed as 5088 supported in *note arm_coproc3_ok:: in addition the following: 5089 'MCRR2' and 'MRRC2'. 5090 50917.2.3.8 AArch64-specific attributes 5092................................... 5093 5094'aarch64_asm_<ext>_ok' 5095 AArch64 assembler supports the architecture extension 'ext' via the 5096 '.arch_extension' pseudo-op. 5097'aarch64_tiny' 5098 AArch64 target which generates instruction sequences for tiny 5099 memory model. 5100'aarch64_small' 5101 AArch64 target which generates instruction sequences for small 5102 memory model. 5103'aarch64_large' 5104 AArch64 target which generates instruction sequences for large 5105 memory model. 5106'aarch64_little_endian' 5107 AArch64 target which generates instruction sequences for little 5108 endian. 5109'aarch64_big_endian' 5110 AArch64 target which generates instruction sequences for big 5111 endian. 5112'aarch64_small_fpic' 5113 Binutils installed on test system supports relocation types 5114 required by -fpic for AArch64 small memory model. 5115 51167.2.3.9 MIPS-specific attributes 5117................................ 5118 5119'mips64' 5120 MIPS target supports 64-bit instructions. 5121 5122'nomips16' 5123 MIPS target does not produce MIPS16 code. 5124 5125'mips16_attribute' 5126 MIPS target can generate MIPS16 code. 5127 5128'mips_loongson' 5129 MIPS target is a Loongson-2E or -2F target using an ABI that 5130 supports the Loongson vector modes. 5131 5132'mips_msa' 5133 MIPS target supports '-mmsa', MIPS SIMD Architecture (MSA). 5134 5135'mips_newabi_large_long_double' 5136 MIPS target supports 'long double' larger than 'double' when using 5137 the new ABI. 5138 5139'mpaired_single' 5140 MIPS target supports '-mpaired-single'. 5141 51427.2.3.10 PowerPC-specific attributes 5143.................................... 5144 5145'dfp_hw' 5146 PowerPC target supports executing hardware DFP instructions. 5147 5148'p8vector_hw' 5149 PowerPC target supports executing VSX instructions (ISA 2.07). 5150 5151'powerpc64' 5152 Test system supports executing 64-bit instructions. 5153 5154'powerpc_altivec' 5155 PowerPC target supports AltiVec. 5156 5157'powerpc_altivec_ok' 5158 PowerPC target supports '-maltivec'. 5159 5160'powerpc_eabi_ok' 5161 PowerPC target supports '-meabi'. 5162 5163'powerpc_elfv2' 5164 PowerPC target supports '-mabi=elfv2'. 5165 5166'powerpc_fprs' 5167 PowerPC target supports floating-point registers. 5168 5169'powerpc_hard_double' 5170 PowerPC target supports hardware double-precision floating-point. 5171 5172'powerpc_htm_ok' 5173 PowerPC target supports '-mhtm' 5174 5175'powerpc_p8vector_ok' 5176 PowerPC target supports '-mpower8-vector' 5177 5178'powerpc_popcntb_ok' 5179 PowerPC target supports the 'popcntb' instruction, indicating that 5180 this target supports '-mcpu=power5'. 5181 5182'powerpc_ppu_ok' 5183 PowerPC target supports '-mcpu=cell'. 5184 5185'powerpc_spe' 5186 PowerPC target supports PowerPC SPE. 5187 5188'powerpc_spe_nocache' 5189 Including the options used to compile this particular test, the 5190 PowerPC target supports PowerPC SPE. 5191 5192'powerpc_spu' 5193 PowerPC target supports PowerPC SPU. 5194 5195'powerpc_vsx_ok' 5196 PowerPC target supports '-mvsx'. 5197 5198'powerpc_405_nocache' 5199 Including the options used to compile this particular test, the 5200 PowerPC target supports PowerPC 405. 5201 5202'ppc_recip_hw' 5203 PowerPC target supports executing reciprocal estimate instructions. 5204 5205'spu_auto_overlay' 5206 SPU target has toolchain that supports automatic overlay 5207 generation. 5208 5209'vmx_hw' 5210 PowerPC target supports executing AltiVec instructions. 5211 5212'vsx_hw' 5213 PowerPC target supports executing VSX instructions (ISA 2.06). 5214 52157.2.3.11 Other hardware attributes 5216.................................. 5217 5218'autoincdec' 5219 Target supports autoincrement/decrement addressing. 5220 5221'avx' 5222 Target supports compiling 'avx' instructions. 5223 5224'avx_runtime' 5225 Target supports the execution of 'avx' instructions. 5226 5227'avx2' 5228 Target supports compiling 'avx2' instructions. 5229 5230'avx2_runtime' 5231 Target supports the execution of 'avx2' instructions. 5232 5233'avx512f' 5234 Target supports compiling 'avx512f' instructions. 5235 5236'avx512f_runtime' 5237 Target supports the execution of 'avx512f' instructions. 5238 5239'cell_hw' 5240 Test system can execute AltiVec and Cell PPU instructions. 5241 5242'coldfire_fpu' 5243 Target uses a ColdFire FPU. 5244 5245'divmod' 5246 Target supporting hardware divmod insn or divmod libcall. 5247 5248'divmod_simode' 5249 Target supporting hardware divmod insn or divmod libcall for 5250 SImode. 5251 5252'hard_float' 5253 Target supports FPU instructions. 5254 5255'non_strict_align' 5256 Target does not require strict alignment. 5257 5258'pie_copyreloc' 5259 The x86-64 target linker supports PIE with copy reloc. 5260 5261'rdrand' 5262 Target supports x86 'rdrand' instruction. 5263 5264'sqrt_insn' 5265 Target has a square root instruction that the compiler can 5266 generate. 5267 5268'sse' 5269 Target supports compiling 'sse' instructions. 5270 5271'sse_runtime' 5272 Target supports the execution of 'sse' instructions. 5273 5274'sse2' 5275 Target supports compiling 'sse2' instructions. 5276 5277'sse2_runtime' 5278 Target supports the execution of 'sse2' instructions. 5279 5280'sync_char_short' 5281 Target supports atomic operations on 'char' and 'short'. 5282 5283'sync_int_long' 5284 Target supports atomic operations on 'int' and 'long'. 5285 5286'ultrasparc_hw' 5287 Test environment appears to run executables on a simulator that 5288 accepts only 'EM_SPARC' executables and chokes on 'EM_SPARC32PLUS' 5289 or 'EM_SPARCV9' executables. 5290 5291'vect_cmdline_needed' 5292 Target requires a command line argument to enable a SIMD 5293 instruction set. 5294 5295'xorsign' 5296 Target supports the xorsign optab expansion. 5297 52987.2.3.12 Environment attributes 5299............................... 5300 5301'c' 5302 The language for the compiler under test is C. 5303 5304'c++' 5305 The language for the compiler under test is C++. 5306 5307'c99_runtime' 5308 Target provides a full C99 runtime. 5309 5310'correct_iso_cpp_string_wchar_protos' 5311 Target 'string.h' and 'wchar.h' headers provide C++ required 5312 overloads for 'strchr' etc. functions. 5313 5314'dummy_wcsftime' 5315 Target uses a dummy 'wcsftime' function that always returns zero. 5316 5317'fd_truncate' 5318 Target can truncate a file from a file descriptor, as used by 5319 'libgfortran/io/unix.c:fd_truncate'; i.e. 'ftruncate' or 'chsize'. 5320 5321'freestanding' 5322 Target is 'freestanding' as defined in section 4 of the C99 5323 standard. Effectively, it is a target which supports no extra 5324 headers or libraries other than what is considered essential. 5325 5326'gettimeofday' 5327 Target supports 'gettimeofday'. 5328 5329'init_priority' 5330 Target supports constructors with initialization priority 5331 arguments. 5332 5333'inttypes_types' 5334 Target has the basic signed and unsigned types in 'inttypes.h'. 5335 This is for tests that GCC's notions of these types agree with 5336 those in the header, as some systems have only 'inttypes.h'. 5337 5338'lax_strtofp' 5339 Target might have errors of a few ULP in string to floating-point 5340 conversion functions and overflow is not always detected correctly 5341 by those functions. 5342 5343'mempcpy' 5344 Target provides 'mempcpy' function. 5345 5346'mmap' 5347 Target supports 'mmap'. 5348 5349'newlib' 5350 Target supports Newlib. 5351 5352'pow10' 5353 Target provides 'pow10' function. 5354 5355'pthread' 5356 Target can compile using 'pthread.h' with no errors or warnings. 5357 5358'pthread_h' 5359 Target has 'pthread.h'. 5360 5361'run_expensive_tests' 5362 Expensive testcases (usually those that consume excessive amounts 5363 of CPU time) should be run on this target. This can be enabled by 5364 setting the 'GCC_TEST_RUN_EXPENSIVE' environment variable to a 5365 non-empty string. 5366 5367'simulator' 5368 Test system runs executables on a simulator (i.e. slowly) rather 5369 than hardware (i.e. fast). 5370 5371'signal' 5372 Target has 'signal.h'. 5373 5374'stabs' 5375 Target supports the stabs debugging format. 5376 5377'stdint_types' 5378 Target has the basic signed and unsigned C types in 'stdint.h'. 5379 This will be obsolete when GCC ensures a working 'stdint.h' for all 5380 targets. 5381 5382'stpcpy' 5383 Target provides 'stpcpy' function. 5384 5385'trampolines' 5386 Target supports trampolines. 5387 5388'uclibc' 5389 Target supports uClibc. 5390 5391'unwrapped' 5392 Target does not use a status wrapper. 5393 5394'vxworks_kernel' 5395 Target is a VxWorks kernel. 5396 5397'vxworks_rtp' 5398 Target is a VxWorks RTP. 5399 5400'wchar' 5401 Target supports wide characters. 5402 54037.2.3.13 Other attributes 5404......................... 5405 5406'automatic_stack_alignment' 5407 Target supports automatic stack alignment. 5408 5409'branch_cost' 5410 Target supports '-branch-cost=N'. 5411 5412'cxa_atexit' 5413 Target uses '__cxa_atexit'. 5414 5415'default_packed' 5416 Target has packed layout of structure members by default. 5417 5418'fgraphite' 5419 Target supports Graphite optimizations. 5420 5421'fixed_point' 5422 Target supports fixed-point extension to C. 5423 5424'fopenacc' 5425 Target supports OpenACC via '-fopenacc'. 5426 5427'fopenmp' 5428 Target supports OpenMP via '-fopenmp'. 5429 5430'fpic' 5431 Target supports '-fpic' and '-fPIC'. 5432 5433'freorder' 5434 Target supports '-freorder-blocks-and-partition'. 5435 5436'fstack_protector' 5437 Target supports '-fstack-protector'. 5438 5439'gas' 5440 Target uses GNU 'as'. 5441 5442'gc_sections' 5443 Target supports '--gc-sections'. 5444 5445'gld' 5446 Target uses GNU 'ld'. 5447 5448'keeps_null_pointer_checks' 5449 Target keeps null pointer checks, either due to the use of 5450 '-fno-delete-null-pointer-checks' or hardwired into the target. 5451 5452'lto' 5453 Compiler has been configured to support link-time optimization 5454 (LTO). 5455 5456'naked_functions' 5457 Target supports the 'naked' function attribute. 5458 5459'named_sections' 5460 Target supports named sections. 5461 5462'natural_alignment_32' 5463 Target uses natural alignment (aligned to type size) for types of 5464 32 bits or less. 5465 5466'target_natural_alignment_64' 5467 Target uses natural alignment (aligned to type size) for types of 5468 64 bits or less. 5469 5470'nonpic' 5471 Target does not generate PIC by default. 5472 5473'pie_enabled' 5474 Target generates PIE by default. 5475 5476'pcc_bitfield_type_matters' 5477 Target defines 'PCC_BITFIELD_TYPE_MATTERS'. 5478 5479'pe_aligned_commons' 5480 Target supports '-mpe-aligned-commons'. 5481 5482'pie' 5483 Target supports '-pie', '-fpie' and '-fPIE'. 5484 5485'rdynamic' 5486 Target supports '-rdynamic'. 5487 5488'section_anchors' 5489 Target supports section anchors. 5490 5491'short_enums' 5492 Target defaults to short enums. 5493 5494'stack_size' 5495 Target has limited stack size. The stack size limit can be 5496 obtained using the STACK_SIZE macro defined by *note 5497 'dg-add-options' feature 'stack_size': stack_size_ao. 5498 5499'static' 5500 Target supports '-static'. 5501 5502'static_libgfortran' 5503 Target supports statically linking 'libgfortran'. 5504 5505'string_merging' 5506 Target supports merging string constants at link time. 5507 5508'ucn' 5509 Target supports compiling and assembling UCN. 5510 5511'ucn_nocache' 5512 Including the options used to compile this particular test, the 5513 target supports compiling and assembling UCN. 5514 5515'unaligned_stack' 5516 Target does not guarantee that its 'STACK_BOUNDARY' is greater than 5517 or equal to the required vector alignment. 5518 5519'vector_alignment_reachable' 5520 Vector alignment is reachable for types of 32 bits or less. 5521 5522'vector_alignment_reachable_for_64bit' 5523 Vector alignment is reachable for types of 64 bits or less. 5524 5525'wchar_t_char16_t_compatible' 5526 Target supports 'wchar_t' that is compatible with 'char16_t'. 5527 5528'wchar_t_char32_t_compatible' 5529 Target supports 'wchar_t' that is compatible with 'char32_t'. 5530 5531'comdat_group' 5532 Target uses comdat groups. 5533 55347.2.3.14 Local to tests in 'gcc.target/i386' 5535............................................ 5536 5537'3dnow' 5538 Target supports compiling '3dnow' instructions. 5539 5540'aes' 5541 Target supports compiling 'aes' instructions. 5542 5543'fma4' 5544 Target supports compiling 'fma4' instructions. 5545 5546'ms_hook_prologue' 5547 Target supports attribute 'ms_hook_prologue'. 5548 5549'pclmul' 5550 Target supports compiling 'pclmul' instructions. 5551 5552'sse3' 5553 Target supports compiling 'sse3' instructions. 5554 5555'sse4' 5556 Target supports compiling 'sse4' instructions. 5557 5558'sse4a' 5559 Target supports compiling 'sse4a' instructions. 5560 5561'ssse3' 5562 Target supports compiling 'ssse3' instructions. 5563 5564'vaes' 5565 Target supports compiling 'vaes' instructions. 5566 5567'vpclmul' 5568 Target supports compiling 'vpclmul' instructions. 5569 5570'xop' 5571 Target supports compiling 'xop' instructions. 5572 55737.2.3.15 Local to tests in 'gcc.target/spu/ea' 5574.............................................. 5575 5576'ealib' 5577 Target '__ea' library functions are available. 5578 55797.2.3.16 Local to tests in 'gcc.test-framework' 5580............................................... 5581 5582'no' 5583 Always returns 0. 5584 5585'yes' 5586 Always returns 1. 5587 5588 5589File: gccint.info, Node: Add Options, Next: Require Support, Prev: Effective-Target Keywords, Up: Test Directives 5590 55917.2.4 Features for 'dg-add-options' 5592----------------------------------- 5593 5594The supported values of FEATURE for directive 'dg-add-options' are: 5595 5596'arm_fp' 5597 '__ARM_FP' definition. Only ARM targets support this feature, and 5598 only then in certain modes; see the *note arm_fp_ok effective 5599 target keyword: arm_fp_ok. 5600 5601'arm_neon' 5602 NEON support. Only ARM targets support this feature, and only then 5603 in certain modes; see the *note arm_neon_ok effective target 5604 keyword: arm_neon_ok. 5605 5606'arm_fp16' 5607 VFP half-precision floating point support. This does not select 5608 the FP16 format; for that, use *note arm_fp16_ieee: arm_fp16_ieee. 5609 or *note arm_fp16_alternative: arm_fp16_alternative. instead. This 5610 feature is only supported by ARM targets and then only in certain 5611 modes; see the *note arm_fp16_ok effective target keyword: 5612 arm_fp16_ok. 5613 5614'arm_fp16_ieee' 5615 ARM IEEE 754-2008 format VFP half-precision floating point support. 5616 This feature is only supported by ARM targets and then only in 5617 certain modes; see the *note arm_fp16_ok effective target keyword: 5618 arm_fp16_ok. 5619 5620'arm_fp16_alternative' 5621 ARM Alternative format VFP half-precision floating point support. 5622 This feature is only supported by ARM targets and then only in 5623 certain modes; see the *note arm_fp16_ok effective target keyword: 5624 arm_fp16_ok. 5625 5626'arm_neon_fp16' 5627 NEON and half-precision floating point support. Only ARM targets 5628 support this feature, and only then in certain modes; see the *note 5629 arm_neon_fp16_ok effective target keyword: arm_neon_fp16_ok. 5630 5631'arm_vfp3' 5632 arm vfp3 floating point support; see the *note arm_vfp3_ok 5633 effective target keyword: arm_vfp3_ok. 5634 5635'arm_v8_1a_neon' 5636 Add options for ARMv8.1-A with Adv.SIMD support, if this is 5637 supported by the target; see the *note arm_v8_1a_neon_ok: 5638 arm_v8_1a_neon_ok. effective target keyword. 5639 5640'arm_v8_2a_fp16_scalar' 5641 Add options for ARMv8.2-A with scalar FP16 support, if this is 5642 supported by the target; see the *note arm_v8_2a_fp16_scalar_ok: 5643 arm_v8_2a_fp16_scalar_ok. effective target keyword. 5644 5645'arm_v8_2a_fp16_neon' 5646 Add options for ARMv8.2-A with Adv.SIMD FP16 support, if this is 5647 supported by the target; see the *note arm_v8_2a_fp16_neon_ok: 5648 arm_v8_2a_fp16_neon_ok. effective target keyword. 5649 5650'arm_v8_2a_dotprod_neon' 5651 Add options for ARMv8.2-A with Adv.SIMD Dot Product support, if 5652 this is supported by the target; see the *note 5653 arm_v8_2a_dotprod_neon_ok:: effective target keyword. 5654 5655'arm_fp16fml_neon' 5656 Add options to enable generation of the 'VFMAL' and 'VFMSL' 5657 instructions, if this is supported by the target; see the *note 5658 arm_fp16fml_neon_ok:: effective target keyword. 5659 5660'bind_pic_locally' 5661 Add the target-specific flags needed to enable functions to bind 5662 locally when using pic/PIC passes in the testsuite. 5663 5664'c99_runtime' 5665 Add the target-specific flags needed to access the C99 runtime. 5666 5667'floatN' 5668 Add the target-specific flags needed to use the '_FloatN' type. 5669 5670'floatNx' 5671 Add the target-specific flags needed to use the '_FloatNx' type. 5672 5673'ieee' 5674 Add the target-specific flags needed to enable full IEEE compliance 5675 mode. 5676 5677'mips16_attribute' 5678 'mips16' function attributes. Only MIPS targets support this 5679 feature, and only then in certain modes. 5680 5681'stack_size' 5682 Add the flags needed to define macro STACK_SIZE and set it to the 5683 stack size limit associated with the *note 'stack_size' effective 5684 target: stack_size_et. 5685 5686'tls' 5687 Add the target-specific flags needed to use thread-local storage. 5688 5689 5690File: gccint.info, Node: Require Support, Next: Final Actions, Prev: Add Options, Up: Test Directives 5691 56927.2.5 Variants of 'dg-require-SUPPORT' 5693-------------------------------------- 5694 5695A few of the 'dg-require' directives take arguments. 5696 5697'dg-require-iconv CODESET' 5698 Skip the test if the target does not support iconv. CODESET is the 5699 codeset to convert to. 5700 5701'dg-require-profiling PROFOPT' 5702 Skip the test if the target does not support profiling with option 5703 PROFOPT. 5704 5705'dg-require-stack-check CHECK' 5706 Skip the test if the target does not support the '-fstack-check' 5707 option. If CHECK is '""', support for '-fstack-check' is checked, 5708 for '-fstack-check=("CHECK")' otherwise. 5709 5710'dg-require-stack-size SIZE' 5711 Skip the test if the target does not support a stack size of SIZE. 5712 5713'dg-require-visibility VIS' 5714 Skip the test if the target does not support the 'visibility' 5715 attribute. If VIS is '""', support for 'visibility("hidden")' is 5716 checked, for 'visibility("VIS")' otherwise. 5717 5718 The original 'dg-require' directives were defined before there was 5719support for effective-target keywords. The directives that do not take 5720arguments could be replaced with effective-target keywords. 5721 5722'dg-require-alias ""' 5723 Skip the test if the target does not support the 'alias' attribute. 5724 5725'dg-require-ascii-locale ""' 5726 Skip the test if the host does not support an ASCII locale. 5727 5728'dg-require-compat-dfp ""' 5729 Skip this test unless both compilers in a 'compat' testsuite 5730 support decimal floating point. 5731 5732'dg-require-cxa-atexit ""' 5733 Skip the test if the target does not support '__cxa_atexit'. This 5734 is equivalent to 'dg-require-effective-target cxa_atexit'. 5735 5736'dg-require-dll ""' 5737 Skip the test if the target does not support DLL attributes. 5738 5739'dg-require-fork ""' 5740 Skip the test if the target does not support 'fork'. 5741 5742'dg-require-gc-sections ""' 5743 Skip the test if the target's linker does not support the 5744 '--gc-sections' flags. This is equivalent to 5745 'dg-require-effective-target gc-sections'. 5746 5747'dg-require-host-local ""' 5748 Skip the test if the host is remote, rather than the same as the 5749 build system. Some tests are incompatible with DejaGnu's handling 5750 of remote hosts, which involves copying the source file to the host 5751 and compiling it with a relative path and "'-o a.out'". 5752 5753'dg-require-mkfifo ""' 5754 Skip the test if the target does not support 'mkfifo'. 5755 5756'dg-require-named-sections ""' 5757 Skip the test is the target does not support named sections. This 5758 is equivalent to 'dg-require-effective-target named_sections'. 5759 5760'dg-require-weak ""' 5761 Skip the test if the target does not support weak symbols. 5762 5763'dg-require-weak-override ""' 5764 Skip the test if the target does not support overriding weak 5765 symbols. 5766 5767 5768File: gccint.info, Node: Final Actions, Prev: Require Support, Up: Test Directives 5769 57707.2.6 Commands for use in 'dg-final' 5771------------------------------------ 5772 5773The GCC testsuite defines the following directives to be used within 5774'dg-final'. 5775 57767.2.6.1 Scan a particular file 5777.............................. 5778 5779'scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]' 5780 Passes if REGEXP matches text in FILENAME. 5781'scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]' 5782 Passes if REGEXP does not match text in FILENAME. 5783'scan-module MODULE REGEXP [{ target/xfail SELECTOR }]' 5784 Passes if REGEXP matches in Fortran module MODULE. 5785 57867.2.6.2 Scan the assembly output 5787................................ 5788 5789'scan-assembler REGEX [{ target/xfail SELECTOR }]' 5790 Passes if REGEX matches text in the test's assembler output. 5791 5792'scan-assembler-not REGEX [{ target/xfail SELECTOR }]' 5793 Passes if REGEX does not match text in the test's assembler output. 5794 5795'scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]' 5796 Passes if REGEX is matched exactly NUM times in the test's 5797 assembler output. 5798 5799'scan-assembler-dem REGEX [{ target/xfail SELECTOR }]' 5800 Passes if REGEX matches text in the test's demangled assembler 5801 output. 5802 5803'scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]' 5804 Passes if REGEX does not match text in the test's demangled 5805 assembler output. 5806 5807'scan-hidden SYMBOL [{ target/xfail SELECTOR }]' 5808 Passes if SYMBOL is defined as a hidden symbol in the test's 5809 assembly output. 5810 5811'scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]' 5812 Passes if SYMBOL is not defined as a hidden symbol in the test's 5813 assembly output. 5814 58157.2.6.3 Scan optimization dump files 5816.................................... 5817 5818These commands are available for KIND of 'tree', 'rtl', and 'ipa'. 5819 5820'scan-KIND-dump REGEX SUFFIX [{ target/xfail SELECTOR }]' 5821 Passes if REGEX matches text in the dump file with suffix SUFFIX. 5822 5823'scan-KIND-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5824 Passes if REGEX does not match text in the dump file with suffix 5825 SUFFIX. 5826 5827'scan-KIND-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]' 5828 Passes if REGEX is found exactly NUM times in the dump file with 5829 suffix SUFFIX. 5830 5831'scan-KIND-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]' 5832 Passes if REGEX matches demangled text in the dump file with suffix 5833 SUFFIX. 5834 5835'scan-KIND-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5836 Passes if REGEX does not match demangled text in the dump file with 5837 suffix SUFFIX. 5838 58397.2.6.4 Verify that an output files exists or not 5840................................................. 5841 5842'output-exists [{ target/xfail SELECTOR }]' 5843 Passes if compiler output file exists. 5844 5845'output-exists-not [{ target/xfail SELECTOR }]' 5846 Passes if compiler output file does not exist. 5847 58487.2.6.5 Check for LTO tests 5849........................... 5850 5851'scan-symbol REGEXP [{ target/xfail SELECTOR }]' 5852 Passes if the pattern is present in the final executable. 5853 58547.2.6.6 Checks for 'gcov' tests 5855............................... 5856 5857'run-gcov SOURCEFILE' 5858 Check line counts in 'gcov' tests. 5859 5860'run-gcov [branches] [calls] { OPTS SOURCEFILE }' 5861 Check branch and/or call counts, in addition to line counts, in 5862 'gcov' tests. 5863 58647.2.6.7 Clean up generated test files 5865..................................... 5866 5867Usually the test-framework removes files that were generated during 5868testing. If a testcase, for example, uses any dumping mechanism to 5869inspect a passes dump file, the testsuite recognized the dump option 5870passed to the tool and schedules a final cleanup to remove these files. 5871 5872 There are, however, following additional cleanup directives that can be 5873used to annotate a testcase "manually". 5874'cleanup-coverage-files' 5875 Removes coverage data files generated for this test. 5876 5877'cleanup-modules "LIST-OF-EXTRA-MODULES"' 5878 Removes Fortran module files generated for this test, excluding the 5879 module names listed in keep-modules. Cleaning up module files is 5880 usually done automatically by the testsuite by looking at the 5881 source files and removing the modules after the test has been 5882 executed. 5883 module MoD1 5884 end module MoD1 5885 module Mod2 5886 end module Mod2 5887 module moD3 5888 end module moD3 5889 module mod4 5890 end module mod4 5891 ! { dg-final { cleanup-modules "mod1 mod2" } } ! redundant 5892 ! { dg-final { keep-modules "mod3 mod4" } } 5893 5894'keep-modules "LIST-OF-MODULES-NOT-TO-DELETE"' 5895 Whitespace separated list of module names that should not be 5896 deleted by cleanup-modules. If the list of modules is empty, all 5897 modules defined in this file are kept. 5898 module maybe_unneeded 5899 end module maybe_unneeded 5900 module keep1 5901 end module keep1 5902 module keep2 5903 end module keep2 5904 ! { dg-final { keep-modules "keep1 keep2" } } ! just keep these two 5905 ! { dg-final { keep-modules "" } } ! keep all 5906 5907'dg-keep-saved-temps "LIST-OF-SUFFIXES-NOT-TO-DELETE"' 5908 Whitespace separated list of suffixes that should not be deleted 5909 automatically in a testcase that uses '-save-temps'. 5910 // { dg-options "-save-temps -fpch-preprocess -I." } 5911 int main() { return 0; } 5912 // { dg-keep-saved-temps ".s" } ! just keep assembler file 5913 // { dg-keep-saved-temps ".s" ".i" } ! ... and .i 5914 // { dg-keep-saved-temps ".ii" ".o" } ! or just .ii and .o 5915 5916'cleanup-profile-file' 5917 Removes profiling files generated for this test. 5918 5919'cleanup-repo-files' 5920 Removes files generated for this test for '-frepo'. 5921 5922 5923File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites 5924 59257.3 Ada Language Testsuites 5926=========================== 5927 5928The Ada testsuite includes executable tests from the ACATS testsuite, 5929publicly available at <http://www.ada-auth.org/acats.html>. 5930 5931 These tests are integrated in the GCC testsuite in the 'ada/acats' 5932directory, and enabled automatically when running 'make check', assuming 5933the Ada language has been enabled when configuring GCC. 5934 5935 You can also run the Ada testsuite independently, using 'make 5936check-ada', or run a subset of the tests by specifying which chapter to 5937run, e.g.: 5938 5939 $ make check-ada CHAPTERS="c3 c9" 5940 5941 The tests are organized by directory, each directory corresponding to a 5942chapter of the Ada Reference Manual. So for example, 'c9' corresponds 5943to chapter 9, which deals with tasking features of the language. 5944 5945 The tests are run using two 'sh' scripts: 'run_acats' and 'run_all.sh'. 5946To run the tests using a simulator or a cross target, see the small 5947customization section at the top of 'run_all.sh'. 5948 5949 These tests are run using the build tree: they can be run without doing 5950a 'make install'. 5951 5952 5953File: gccint.info, Node: C Tests, Next: LTO Testing, Prev: Ada Tests, Up: Testsuites 5954 59557.4 C Language Testsuites 5956========================= 5957 5958GCC contains the following C language testsuites, in the 'gcc/testsuite' 5959directory: 5960 5961'gcc.dg' 5962 This contains tests of particular features of the C compiler, using 5963 the more modern 'dg' harness. Correctness tests for various 5964 compiler features should go here if possible. 5965 5966 Magic comments determine whether the file is preprocessed, 5967 compiled, linked or run. In these tests, error and warning message 5968 texts are compared against expected texts or regular expressions 5969 given in comments. These tests are run with the options '-ansi 5970 -pedantic' unless other options are given in the test. Except as 5971 noted below they are not run with multiple optimization options. 5972'gcc.dg/compat' 5973 This subdirectory contains tests for binary compatibility using 5974 'lib/compat.exp', which in turn uses the language-independent 5975 support (*note Support for testing binary compatibility: compat 5976 Testing.). 5977'gcc.dg/cpp' 5978 This subdirectory contains tests of the preprocessor. 5979'gcc.dg/debug' 5980 This subdirectory contains tests for debug formats. Tests in this 5981 subdirectory are run for each debug format that the compiler 5982 supports. 5983'gcc.dg/format' 5984 This subdirectory contains tests of the '-Wformat' format checking. 5985 Tests in this directory are run with and without '-DWIDE'. 5986'gcc.dg/noncompile' 5987 This subdirectory contains tests of code that should not compile 5988 and does not need any special compilation options. They are run 5989 with multiple optimization options, since sometimes invalid code 5990 crashes the compiler with optimization. 5991'gcc.dg/special' 5992 FIXME: describe this. 5993 5994'gcc.c-torture' 5995 This contains particular code fragments which have historically 5996 broken easily. These tests are run with multiple optimization 5997 options, so tests for features which only break at some 5998 optimization levels belong here. This also contains tests to check 5999 that certain optimizations occur. It might be worthwhile to 6000 separate the correctness tests cleanly from the code quality tests, 6001 but it hasn't been done yet. 6002 6003'gcc.c-torture/compat' 6004 FIXME: describe this. 6005 6006 This directory should probably not be used for new tests. 6007'gcc.c-torture/compile' 6008 This testsuite contains test cases that should compile, but do not 6009 need to link or run. These test cases are compiled with several 6010 different combinations of optimization options. All warnings are 6011 disabled for these test cases, so this directory is not suitable if 6012 you wish to test for the presence or absence of compiler warnings. 6013 While special options can be set, and tests disabled on specific 6014 platforms, by the use of '.x' files, mostly these test cases should 6015 not contain platform dependencies. FIXME: discuss how defines such 6016 as 'STACK_SIZE' are used. 6017'gcc.c-torture/execute' 6018 This testsuite contains test cases that should compile, link and 6019 run; otherwise the same comments as for 'gcc.c-torture/compile' 6020 apply. 6021'gcc.c-torture/execute/ieee' 6022 This contains tests which are specific to IEEE floating point. 6023'gcc.c-torture/unsorted' 6024 FIXME: describe this. 6025 6026 This directory should probably not be used for new tests. 6027'gcc.misc-tests' 6028 This directory contains C tests that require special handling. 6029 Some of these tests have individual expect files, and others share 6030 special-purpose expect files: 6031 6032 'bprob*.c' 6033 Test '-fbranch-probabilities' using 6034 'gcc.misc-tests/bprob.exp', which in turn uses the generic, 6035 language-independent framework (*note Support for testing 6036 profile-directed optimizations: profopt Testing.). 6037 6038 'gcov*.c' 6039 Test 'gcov' output using 'gcov.exp', which in turn uses the 6040 language-independent support (*note Support for testing gcov: 6041 gcov Testing.). 6042 6043 'i386-pf-*.c' 6044 Test i386-specific support for data prefetch using 6045 'i386-prefetch.exp'. 6046 6047'gcc.test-framework' 6048 'dg-*.c' 6049 Test the testsuite itself using 6050 'gcc.test-framework/test-framework.exp'. 6051 6052 FIXME: merge in 'testsuite/README.gcc' and discuss the format of test 6053cases and magic comments more. 6054 6055 6056File: gccint.info, Node: LTO Testing, Next: gcov Testing, Prev: C Tests, Up: Testsuites 6057 60587.5 Support for testing link-time optimizations 6059=============================================== 6060 6061Tests for link-time optimizations usually require multiple source files 6062that are compiled separately, perhaps with different sets of options. 6063There are several special-purpose test directives used for these tests. 6064 6065'{ dg-lto-do DO-WHAT-KEYWORD }' 6066 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 6067 is executed. It is one of: 6068 6069 'assemble' 6070 Compile with '-c' to produce a relocatable object file. 6071 'link' 6072 Compile, assemble, and link to produce an executable file. 6073 'run' 6074 Produce and run an executable file, which is expected to 6075 return an exit code of 0. 6076 6077 The default is 'assemble'. That can be overridden for a set of 6078 tests by redefining 'dg-do-what-default' within the '.exp' file for 6079 those tests. 6080 6081 Unlike 'dg-do', 'dg-lto-do' does not support an optional 'target' 6082 or 'xfail' list. Use 'dg-skip-if', 'dg-xfail-if', or 6083 'dg-xfail-run-if'. 6084 6085'{ dg-lto-options { { OPTIONS } [{ OPTIONS }] } [{ target SELECTOR }]}' 6086 This directive provides a list of one or more sets of compiler 6087 options to override LTO_OPTIONS. Each test will be compiled and 6088 run with each of these sets of options. 6089 6090'{ dg-extra-ld-options OPTIONS [{ target SELECTOR }]}' 6091 This directive adds OPTIONS to the linker options used. 6092 6093'{ dg-suppress-ld-options OPTIONS [{ target SELECTOR }]}' 6094 This directive removes OPTIONS from the set of linker options used. 6095 6096 6097File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: LTO Testing, Up: Testsuites 6098 60997.6 Support for testing 'gcov' 6100============================== 6101 6102Language-independent support for testing 'gcov', and for checking that 6103branch profiling produces expected values, is provided by the expect 6104file 'lib/gcov.exp'. 'gcov' tests also rely on procedures in 6105'lib/gcc-dg.exp' to compile and run the test program. A typical 'gcov' 6106test contains the following DejaGnu commands within comments: 6107 6108 { dg-options "-fprofile-arcs -ftest-coverage" } 6109 { dg-do run { target native } } 6110 { dg-final { run-gcov sourcefile } } 6111 6112 Checks of 'gcov' output can include line counts, branch percentages, 6113and call return percentages. All of these checks are requested via 6114commands that appear in comments in the test's source file. Commands to 6115check line counts are processed by default. Commands to check branch 6116percentages and call return percentages are processed if the 'run-gcov' 6117command has arguments 'branches' or 'calls', respectively. For example, 6118the following specifies checking both, as well as passing '-b' to 6119'gcov': 6120 6121 { dg-final { run-gcov branches calls { -b sourcefile } } } 6122 6123 A line count command appears within a comment on the source line that 6124is expected to get the specified count and has the form 'count(CNT)'. A 6125test should only check line counts for lines that will get the same 6126count for any architecture. 6127 6128 Commands to check branch percentages ('branch') and call return 6129percentages ('returns') are very similar to each other. A beginning 6130command appears on or before the first of a range of lines that will 6131report the percentage, and the ending command follows that range of 6132lines. The beginning command can include a list of percentages, all of 6133which are expected to be found within the range. A range is terminated 6134by the next command of the same kind. A command 'branch(end)' or 6135'returns(end)' marks the end of a range without starting a new one. For 6136example: 6137 6138 if (i > 10 && j > i && j < 20) /* branch(27 50 75) */ 6139 /* branch(end) */ 6140 foo (i, j); 6141 6142 For a call return percentage, the value specified is the percentage of 6143calls reported to return. For a branch percentage, the value is either 6144the expected percentage or 100 minus that value, since the direction of 6145a branch can differ depending on the target or the optimization level. 6146 6147 Not all branches and calls need to be checked. A test should not check 6148for branches that might be optimized away or replaced with predicated 6149instructions. Don't check for calls inserted by the compiler or ones 6150that might be inlined or optimized away. 6151 6152 A single test can check for combinations of line counts, branch 6153percentages, and call return percentages. The command to check a line 6154count must appear on the line that will report that count, but commands 6155to check branch percentages and call return percentages can bracket the 6156lines that report them. 6157 6158 6159File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites 6160 61617.7 Support for testing profile-directed optimizations 6162====================================================== 6163 6164The file 'profopt.exp' provides language-independent support for 6165checking correct execution of a test built with profile-directed 6166optimization. This testing requires that a test program be built and 6167executed twice. The first time it is compiled to generate profile data, 6168and the second time it is compiled to use the data that was generated 6169during the first execution. The second execution is to verify that the 6170test produces the expected results. 6171 6172 To check that the optimization actually generated better code, a test 6173can be built and run a third time with normal optimizations to verify 6174that the performance is better with the profile-directed optimizations. 6175'profopt.exp' has the beginnings of this kind of support. 6176 6177 'profopt.exp' provides generic support for profile-directed 6178optimizations. Each set of tests that uses it provides information 6179about a specific optimization: 6180 6181'tool' 6182 tool being tested, e.g., 'gcc' 6183 6184'profile_option' 6185 options used to generate profile data 6186 6187'feedback_option' 6188 options used to optimize using that profile data 6189 6190'prof_ext' 6191 suffix of profile data files 6192 6193'PROFOPT_OPTIONS' 6194 list of options with which to run each test, similar to the lists 6195 for torture tests 6196 6197'{ dg-final-generate { LOCAL-DIRECTIVE } }' 6198 This directive is similar to 'dg-final', but the LOCAL-DIRECTIVE is 6199 run after the generation of profile data. 6200 6201'{ dg-final-use { LOCAL-DIRECTIVE } }' 6202 The LOCAL-DIRECTIVE is run after the profile data have been used. 6203 6204 6205File: gccint.info, Node: compat Testing, Next: Torture Tests, Prev: profopt Testing, Up: Testsuites 6206 62077.8 Support for testing binary compatibility 6208============================================ 6209 6210The file 'compat.exp' provides language-independent support for binary 6211compatibility testing. It supports testing interoperability of two 6212compilers that follow the same ABI, or of multiple sets of compiler 6213options that should not affect binary compatibility. It is intended to 6214be used for testsuites that complement ABI testsuites. 6215 6216 A test supported by this framework has three parts, each in a separate 6217source file: a main program and two pieces that interact with each other 6218to split up the functionality being tested. 6219 6220'TESTNAME_main.SUFFIX' 6221 Contains the main program, which calls a function in file 6222 'TESTNAME_x.SUFFIX'. 6223 6224'TESTNAME_x.SUFFIX' 6225 Contains at least one call to a function in 'TESTNAME_y.SUFFIX'. 6226 6227'TESTNAME_y.SUFFIX' 6228 Shares data with, or gets arguments from, 'TESTNAME_x.SUFFIX'. 6229 6230 Within each test, the main program and one functional piece are 6231compiled by the GCC under test. The other piece can be compiled by an 6232alternate compiler. If no alternate compiler is specified, then all 6233three source files are all compiled by the GCC under test. You can 6234specify pairs of sets of compiler options. The first element of such a 6235pair specifies options used with the GCC under test, and the second 6236element of the pair specifies options used with the alternate compiler. 6237Each test is compiled with each pair of options. 6238 6239 'compat.exp' defines default pairs of compiler options. These can be 6240overridden by defining the environment variable 'COMPAT_OPTIONS' as: 6241 6242 COMPAT_OPTIONS="[list [list {TST1} {ALT1}] 6243 ...[list {TSTN} {ALTN}]]" 6244 6245 where TSTI and ALTI are lists of options, with TSTI used by the 6246compiler under test and ALTI used by the alternate compiler. For 6247example, with '[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]', 6248the test is first built with '-g -O0' by the compiler under test and 6249with '-O3' by the alternate compiler. The test is built a second time 6250using '-fpic' by the compiler under test and '-fPIC -O2' by the 6251alternate compiler. 6252 6253 An alternate compiler is specified by defining an environment variable 6254to be the full pathname of an installed compiler; for C define 6255'ALT_CC_UNDER_TEST', and for C++ define 'ALT_CXX_UNDER_TEST'. These 6256will be written to the 'site.exp' file used by DejaGnu. The default is 6257to build each test with the compiler under test using the first of each 6258pair of compiler options from 'COMPAT_OPTIONS'. When 6259'ALT_CC_UNDER_TEST' or 'ALT_CXX_UNDER_TEST' is 'same', each test is 6260built using the compiler under test but with combinations of the options 6261from 'COMPAT_OPTIONS'. 6262 6263 To run only the C++ compatibility suite using the compiler under test 6264and another version of GCC using specific compiler options, do the 6265following from 'OBJDIR/gcc': 6266 6267 rm site.exp 6268 make -k \ 6269 ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \ 6270 COMPAT_OPTIONS="LISTS AS SHOWN ABOVE" \ 6271 check-c++ \ 6272 RUNTESTFLAGS="compat.exp" 6273 6274 A test that fails when the source files are compiled with different 6275compilers, but passes when the files are compiled with the same 6276compiler, demonstrates incompatibility of the generated code or runtime 6277support. A test that fails for the alternate compiler but passes for 6278the compiler under test probably tests for a bug that was fixed in the 6279compiler under test but is present in the alternate compiler. 6280 6281 The binary compatibility tests support a small number of test framework 6282commands that appear within comments in a test file. 6283 6284'dg-require-*' 6285 These commands can be used in 'TESTNAME_main.SUFFIX' to skip the 6286 test if specific support is not available on the target. 6287 6288'dg-options' 6289 The specified options are used for compiling this particular source 6290 file, appended to the options from 'COMPAT_OPTIONS'. When this 6291 command appears in 'TESTNAME_main.SUFFIX' the options are also used 6292 to link the test program. 6293 6294'dg-xfail-if' 6295 This command can be used in a secondary source file to specify that 6296 compilation is expected to fail for particular options on 6297 particular targets. 6298 6299 6300File: gccint.info, Node: Torture Tests, Next: GIMPLE Tests, Prev: compat Testing, Up: Testsuites 6301 63027.9 Support for torture testing using multiple options 6303====================================================== 6304 6305Throughout the compiler testsuite there are several directories whose 6306tests are run multiple times, each with a different set of options. 6307These are known as torture tests. 'lib/torture-options.exp' defines 6308procedures to set up these lists: 6309 6310'torture-init' 6311 Initialize use of torture lists. 6312'set-torture-options' 6313 Set lists of torture options to use for tests with and without 6314 loops. Optionally combine a set of torture options with a set of 6315 other options, as is done with Objective-C runtime options. 6316'torture-finish' 6317 Finalize use of torture lists. 6318 6319 The '.exp' file for a set of tests that use torture options must 6320include calls to these three procedures if: 6321 6322 * It calls 'gcc-dg-runtest' and overrides DG_TORTURE_OPTIONS. 6323 6324 * It calls ${TOOL}'-torture' or ${TOOL}'-torture-execute', where TOOL 6325 is 'c', 'fortran', or 'objc'. 6326 6327 * It calls 'dg-pch'. 6328 6329 It is not necessary for a '.exp' file that calls 'gcc-dg-runtest' to 6330call the torture procedures if the tests should use the list in 6331DG_TORTURE_OPTIONS defined in 'gcc-dg.exp'. 6332 6333 Most uses of torture options can override the default lists by defining 6334TORTURE_OPTIONS or add to the default list by defining 6335ADDITIONAL_TORTURE_OPTIONS. Define these in a '.dejagnurc' file or add 6336them to the 'site.exp' file; for example 6337 6338 set ADDITIONAL_TORTURE_OPTIONS [list \ 6339 { -O2 -ftree-loop-linear } \ 6340 { -O2 -fpeel-loops } ] 6341 6342 6343File: gccint.info, Node: GIMPLE Tests, Next: RTL Tests, Prev: Torture Tests, Up: Testsuites 6344 63457.10 Support for testing GIMPLE passes 6346====================================== 6347 6348As of gcc 7, C functions can be tagged with '__GIMPLE' to indicate that 6349the function body will be GIMPLE, rather than C. The compiler requires 6350the option '-fgimple' to enable this functionality. For example: 6351 6352 /* { dg-do compile } */ 6353 /* { dg-options "-O -fgimple" } */ 6354 6355 void __GIMPLE (startwith ("dse2")) foo () 6356 { 6357 int a; 6358 6359 bb_2: 6360 if (a > 4) 6361 goto bb_3; 6362 else 6363 goto bb_4; 6364 6365 bb_3: 6366 a_2 = 10; 6367 goto bb_5; 6368 6369 bb_4: 6370 a_3 = 20; 6371 6372 bb_5: 6373 a_1 = __PHI (bb_3: a_2, bb_4: a_3); 6374 a_4 = a_1 + 4; 6375 6376 return; 6377 } 6378 6379 The 'startwith' argument indicates at which pass to begin. 6380 6381 Use the dump modifier '-gimple' (e.g. '-fdump-tree-all-gimple') to 6382make tree dumps more closely follow the format accepted by the GIMPLE 6383parser. 6384 6385 Example DejaGnu tests of GIMPLE can be seen in the source tree at 6386'gcc/testsuite/gcc.dg/gimplefe-*.c'. 6387 6388 The '__GIMPLE' parser is integrated with the C tokenizer and 6389preprocessor, so it should be possible to use macros to build out test 6390coverage. 6391 6392 6393File: gccint.info, Node: RTL Tests, Prev: GIMPLE Tests, Up: Testsuites 6394 63957.11 Support for testing RTL passes 6396=================================== 6397 6398As of gcc 7, C functions can be tagged with '__RTL' to indicate that the 6399function body will be RTL, rather than C. For example: 6400 6401 double __RTL (startwith ("ira")) test (struct foo *f, const struct bar *b) 6402 { 6403 (function "test" 6404 [...snip; various directives go in here...] 6405 ) ;; function "test" 6406 } 6407 6408 The 'startwith' argument indicates at which pass to begin. 6409 6410 The parser expects the RTL body to be in the format emitted by this 6411dumping function: 6412 6413 DEBUG_FUNCTION void 6414 print_rtx_function (FILE *outfile, function *fn, bool compact); 6415 6416 when "compact" is true. So you can capture RTL in the correct format 6417from the debugger using: 6418 6419 (gdb) print_rtx_function (stderr, cfun, true); 6420 6421 and copy and paste the output into the body of the C function. 6422 6423 Example DejaGnu tests of RTL can be seen in the source tree under 6424'gcc/testsuite/gcc.dg/rtl'. 6425 6426 The '__RTL' parser is not integrated with the C tokenizer or 6427preprocessor, and works simply by reading the relevant lines within the 6428braces. In particular, the RTL body must be on separate lines from the 6429enclosing braces, and the preprocessor is not usable within it. 6430 6431 6432File: gccint.info, Node: Options, Next: Passes, Prev: Testsuites, Up: Top 6433 64348 Option specification files 6435**************************** 6436 6437Most GCC command-line options are described by special option definition 6438files, the names of which conventionally end in '.opt'. This chapter 6439describes the format of these files. 6440 6441* Menu: 6442 6443* Option file format:: The general layout of the files 6444* Option properties:: Supported option properties 6445 6446 6447File: gccint.info, Node: Option file format, Next: Option properties, Up: Options 6448 64498.1 Option file format 6450====================== 6451 6452Option files are a simple list of records in which each field occupies 6453its own line and in which the records themselves are separated by blank 6454lines. Comments may appear on their own line anywhere within the file 6455and are preceded by semicolons. Whitespace is allowed before the 6456semicolon. 6457 6458 The files can contain the following types of record: 6459 6460 * A language definition record. These records have two fields: the 6461 string 'Language' and the name of the language. Once a language 6462 has been declared in this way, it can be used as an option 6463 property. *Note Option properties::. 6464 6465 * A target specific save record to save additional information. 6466 These records have two fields: the string 'TargetSave', and a 6467 declaration type to go in the 'cl_target_option' structure. 6468 6469 * A variable record to define a variable used to store option 6470 information. These records have two fields: the string 'Variable', 6471 and a declaration of the type and name of the variable, optionally 6472 with an initializer (but without any trailing ';'). These records 6473 may be used for variables used for many options where declaring the 6474 initializer in a single option definition record, or duplicating it 6475 in many records, would be inappropriate, or for variables set in 6476 option handlers rather than referenced by 'Var' properties. 6477 6478 * A variable record to define a variable used to store option 6479 information. These records have two fields: the string 6480 'TargetVariable', and a declaration of the type and name of the 6481 variable, optionally with an initializer (but without any trailing 6482 ';'). 'TargetVariable' is a combination of 'Variable' and 6483 'TargetSave' records in that the variable is defined in the 6484 'gcc_options' structure, but these variables are also stored in the 6485 'cl_target_option' structure. The variables are saved in the 6486 target save code and restored in the target restore code. 6487 6488 * A variable record to record any additional files that the 6489 'options.h' file should include. This is useful to provide 6490 enumeration or structure definitions needed for target variables. 6491 These records have two fields: the string 'HeaderInclude' and the 6492 name of the include file. 6493 6494 * A variable record to record any additional files that the 6495 'options.c' or 'options-save.c' file should include. This is 6496 useful to provide inline functions needed for target variables 6497 and/or '#ifdef' sequences to properly set up the initialization. 6498 These records have two fields: the string 'SourceInclude' and the 6499 name of the include file. 6500 6501 * An enumeration record to define a set of strings that may be used 6502 as arguments to an option or options. These records have three 6503 fields: the string 'Enum', a space-separated list of properties and 6504 help text used to describe the set of strings in '--help' output. 6505 Properties use the same format as option properties; the following 6506 are valid: 6507 'Name(NAME)' 6508 This property is required; NAME must be a name (suitable for 6509 use in C identifiers) used to identify the set of strings in 6510 'Enum' option properties. 6511 6512 'Type(TYPE)' 6513 This property is required; TYPE is the C type for variables 6514 set by options using this enumeration together with 'Var'. 6515 6516 'UnknownError(MESSAGE)' 6517 The message MESSAGE will be used as an error message if the 6518 argument is invalid; for enumerations without 'UnknownError', 6519 a generic error message is used. MESSAGE should contain a 6520 single '%qs' format, which will be used to format the invalid 6521 argument. 6522 6523 * An enumeration value record to define one of the strings in a set 6524 given in an 'Enum' record. These records have two fields: the 6525 string 'EnumValue' and a space-separated list of properties. 6526 Properties use the same format as option properties; the following 6527 are valid: 6528 'Enum(NAME)' 6529 This property is required; NAME says which 'Enum' record this 6530 'EnumValue' record corresponds to. 6531 6532 'String(STRING)' 6533 This property is required; STRING is the string option 6534 argument being described by this record. 6535 6536 'Value(VALUE)' 6537 This property is required; it says what value (representable 6538 as 'int') should be used for the given string. 6539 6540 'Canonical' 6541 This property is optional. If present, it says the present 6542 string is the canonical one among all those with the given 6543 value. Other strings yielding that value will be mapped to 6544 this one so specs do not need to handle them. 6545 6546 'DriverOnly' 6547 This property is optional. If present, the present string 6548 will only be accepted by the driver. This is used for cases 6549 such as '-march=native' that are processed by the driver so 6550 that 'gcc -v' shows how the options chosen depended on the 6551 system on which the compiler was run. 6552 6553 * An option definition record. These records have the following 6554 fields: 6555 1. the name of the option, with the leading "-" removed 6556 2. a space-separated list of option properties (*note Option 6557 properties::) 6558 3. the help text to use for '--help' (omitted if the second field 6559 contains the 'Undocumented' property). 6560 6561 By default, all options beginning with "f", "W" or "m" are 6562 implicitly assumed to take a "no-" form. This form should not be 6563 listed separately. If an option beginning with one of these 6564 letters does not have a "no-" form, you can use the 6565 'RejectNegative' property to reject it. 6566 6567 The help text is automatically line-wrapped before being displayed. 6568 Normally the name of the option is printed on the left-hand side of 6569 the output and the help text is printed on the right. However, if 6570 the help text contains a tab character, the text to the left of the 6571 tab is used instead of the option's name and the text to the right 6572 of the tab forms the help text. This allows you to elaborate on 6573 what type of argument the option takes. 6574 6575 * A target mask record. These records have one field of the form 6576 'Mask(X)'. The options-processing script will automatically 6577 allocate a bit in 'target_flags' (*note Run-time Target::) for each 6578 mask name X and set the macro 'MASK_X' to the appropriate bitmask. 6579 It will also declare a 'TARGET_X' macro that has the value 1 when 6580 bit 'MASK_X' is set and 0 otherwise. 6581 6582 They are primarily intended to declare target masks that are not 6583 associated with user options, either because these masks represent 6584 internal switches or because the options are not available on all 6585 configurations and yet the masks always need to be defined. 6586 6587 6588File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options 6589 65908.2 Option properties 6591===================== 6592 6593The second field of an option record can specify any of the following 6594properties. When an option takes an argument, it is enclosed in 6595parentheses following the option property name. The parser that handles 6596option files is quite simplistic, and will be tricked by any nested 6597parentheses within the argument text itself; in this case, the entire 6598option argument can be wrapped in curly braces within the parentheses to 6599demarcate it, e.g.: 6600 6601 Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)}) 6602 6603'Common' 6604 The option is available for all languages and targets. 6605 6606'Target' 6607 The option is available for all languages but is target-specific. 6608 6609'Driver' 6610 The option is handled by the compiler driver using code not shared 6611 with the compilers proper ('cc1' etc.). 6612 6613'LANGUAGE' 6614 The option is available when compiling for the given language. 6615 6616 It is possible to specify several different languages for the same 6617 option. Each LANGUAGE must have been declared by an earlier 6618 'Language' record. *Note Option file format::. 6619 6620'RejectDriver' 6621 The option is only handled by the compilers proper ('cc1' etc.) and 6622 should not be accepted by the driver. 6623 6624'RejectNegative' 6625 The option does not have a "no-" form. All options beginning with 6626 "f", "W" or "m" are assumed to have a "no-" form unless this 6627 property is used. 6628 6629'Negative(OTHERNAME)' 6630 The option will turn off another option OTHERNAME, which is the 6631 option name with the leading "-" removed. This chain action will 6632 propagate through the 'Negative' property of the option to be 6633 turned off. 6634 6635 As a consequence, if you have a group of mutually-exclusive 6636 options, their 'Negative' properties should form a circular chain. 6637 For example, if options '-A', '-B' and '-C' are mutually exclusive, 6638 their respective 'Negative' properties should be 'Negative(B)', 6639 'Negative(C)' and 'Negative(A)'. 6640 6641'Joined' 6642'Separate' 6643 The option takes a mandatory argument. 'Joined' indicates that the 6644 option and argument can be included in the same 'argv' entry (as 6645 with '-mflush-func=NAME', for example). 'Separate' indicates that 6646 the option and argument can be separate 'argv' entries (as with 6647 '-o'). An option is allowed to have both of these properties. 6648 6649'JoinedOrMissing' 6650 The option takes an optional argument. If the argument is given, 6651 it will be part of the same 'argv' entry as the option itself. 6652 6653 This property cannot be used alongside 'Joined' or 'Separate'. 6654 6655'MissingArgError(MESSAGE)' 6656 For an option marked 'Joined' or 'Separate', the message MESSAGE 6657 will be used as an error message if the mandatory argument is 6658 missing; for options without 'MissingArgError', a generic error 6659 message is used. MESSAGE should contain a single '%qs' format, 6660 which will be used to format the name of the option passed. 6661 6662'Args(N)' 6663 For an option marked 'Separate', indicate that it takes N 6664 arguments. The default is 1. 6665 6666'UInteger' 6667 The option's argument is a non-negative integer. The option parser 6668 will check and convert the argument before passing it to the 6669 relevant option handler. 'UInteger' should also be used on options 6670 like '-falign-loops' where both '-falign-loops' and 6671 '-falign-loops'=N are supported to make sure the saved options are 6672 given a full integer. 6673 6674'ToLower' 6675 The option's argument should be converted to lowercase as part of 6676 putting it in canonical form, and before comparing with the strings 6677 indicated by any 'Enum' property. 6678 6679'NoDriverArg' 6680 For an option marked 'Separate', the option only takes an argument 6681 in the compiler proper, not in the driver. This is for 6682 compatibility with existing options that are used both directly and 6683 via '-Wp,'; new options should not have this property. 6684 6685'Var(VAR)' 6686 The state of this option should be stored in variable VAR (actually 6687 a macro for 'global_options.x_VAR'). The way that the state is 6688 stored depends on the type of option: 6689 6690 * If the option uses the 'Mask' or 'InverseMask' properties, VAR 6691 is the integer variable that contains the mask. 6692 6693 * If the option is a normal on/off switch, VAR is an integer 6694 variable that is nonzero when the option is enabled. The 6695 options parser will set the variable to 1 when the positive 6696 form of the option is used and 0 when the "no-" form is used. 6697 6698 * If the option takes an argument and has the 'UInteger' 6699 property, VAR is an integer variable that stores the value of 6700 the argument. 6701 6702 * If the option takes an argument and has the 'Enum' property, 6703 VAR is a variable (type given in the 'Type' property of the 6704 'Enum' record whose 'Name' property has the same argument as 6705 the 'Enum' property of this option) that stores the value of 6706 the argument. 6707 6708 * If the option has the 'Defer' property, VAR is a pointer to a 6709 'VEC(cl_deferred_option,heap)' that stores the option for 6710 later processing. (VAR is declared with type 'void *' and 6711 needs to be cast to 'VEC(cl_deferred_option,heap)' before 6712 use.) 6713 6714 * Otherwise, if the option takes an argument, VAR is a pointer 6715 to the argument string. The pointer will be null if the 6716 argument is optional and wasn't given. 6717 6718 The option-processing script will usually zero-initialize VAR. You 6719 can modify this behavior using 'Init'. 6720 6721'Var(VAR, SET)' 6722 The option controls an integer variable VAR and is active when VAR 6723 equals SET. The option parser will set VAR to SET when the 6724 positive form of the option is used and '!SET' when the "no-" form 6725 is used. 6726 6727 VAR is declared in the same way as for the single-argument form 6728 described above. 6729 6730'Init(VALUE)' 6731 The variable specified by the 'Var' property should be statically 6732 initialized to VALUE. If more than one option using the same 6733 variable specifies 'Init', all must specify the same initializer. 6734 6735'Mask(NAME)' 6736 The option is associated with a bit in the 'target_flags' variable 6737 (*note Run-time Target::) and is active when that bit is set. You 6738 may also specify 'Var' to select a variable other than 6739 'target_flags'. 6740 6741 The options-processing script will automatically allocate a unique 6742 bit for the option. If the option is attached to 'target_flags', 6743 the script will set the macro 'MASK_NAME' to the appropriate 6744 bitmask. It will also declare a 'TARGET_NAME' macro that has the 6745 value 1 when the option is active and 0 otherwise. If you use 6746 'Var' to attach the option to a different variable, the bitmask 6747 macro with be called 'OPTION_MASK_NAME'. 6748 6749'InverseMask(OTHERNAME)' 6750'InverseMask(OTHERNAME, THISNAME)' 6751 The option is the inverse of another option that has the 6752 'Mask(OTHERNAME)' property. If THISNAME is given, the 6753 options-processing script will declare a 'TARGET_THISNAME' macro 6754 that is 1 when the option is active and 0 otherwise. 6755 6756'Enum(NAME)' 6757 The option's argument is a string from the set of strings 6758 associated with the corresponding 'Enum' record. The string is 6759 checked and converted to the integer specified in the corresponding 6760 'EnumValue' record before being passed to option handlers. 6761 6762'Defer' 6763 The option should be stored in a vector, specified with 'Var', for 6764 later processing. 6765 6766'Alias(OPT)' 6767'Alias(OPT, ARG)' 6768'Alias(OPT, POSARG, NEGARG)' 6769 The option is an alias for '-OPT' (or the negative form of that 6770 option, depending on 'NegativeAlias'). In the first form, any 6771 argument passed to the alias is considered to be passed to '-OPT', 6772 and '-OPT' is considered to be negated if the alias is used in 6773 negated form. In the second form, the alias may not be negated or 6774 have an argument, and POSARG is considered to be passed as an 6775 argument to '-OPT'. In the third form, the alias may not have an 6776 argument, if the alias is used in the positive form then POSARG is 6777 considered to be passed to '-OPT', and if the alias is used in the 6778 negative form then NEGARG is considered to be passed to '-OPT'. 6779 6780 Aliases should not specify 'Var' or 'Mask' or 'UInteger'. Aliases 6781 should normally specify the same languages as the target of the 6782 alias; the flags on the target will be used to determine any 6783 diagnostic for use of an option for the wrong language, while those 6784 on the alias will be used to identify what command-line text is the 6785 option and what text is any argument to that option. 6786 6787 When an 'Alias' definition is used for an option, driver specs do 6788 not need to handle it and no 'OPT_' enumeration value is defined 6789 for it; only the canonical form of the option will be seen in those 6790 places. 6791 6792'NegativeAlias' 6793 For an option marked with 'Alias(OPT)', the option is considered to 6794 be an alias for the positive form of '-OPT' if negated and for the 6795 negative form of '-OPT' if not negated. 'NegativeAlias' may not be 6796 used with the forms of 'Alias' taking more than one argument. 6797 6798'Ignore' 6799 This option is ignored apart from printing any warning specified 6800 using 'Warn'. The option will not be seen by specs and no 'OPT_' 6801 enumeration value is defined for it. 6802 6803'SeparateAlias' 6804 For an option marked with 'Joined', 'Separate' and 'Alias', the 6805 option only acts as an alias when passed a separate argument; with 6806 a joined argument it acts as a normal option, with an 'OPT_' 6807 enumeration value. This is for compatibility with the Java '-d' 6808 option and should not be used for new options. 6809 6810'Warn(MESSAGE)' 6811 If this option is used, output the warning MESSAGE. MESSAGE is a 6812 format string, either taking a single operand with a '%qs' format 6813 which is the option name, or not taking any operands, which is 6814 passed to the 'warning' function. If an alias is marked 'Warn', 6815 the target of the alias must not also be marked 'Warn'. 6816 6817'Report' 6818 The state of the option should be printed by '-fverbose-asm'. 6819 6820'Warning' 6821 This is a warning option and should be shown as such in '--help' 6822 output. This flag does not currently affect anything other than 6823 '--help'. 6824 6825'Optimization' 6826 This is an optimization option. It should be shown as such in 6827 '--help' output, and any associated variable named using 'Var' 6828 should be saved and restored when the optimization level is changed 6829 with 'optimize' attributes. 6830 6831'PerFunction' 6832 This is an option that can be overridden on a per-function basis. 6833 'Optimization' implies 'PerFunction', but options that do not 6834 affect executable code generation may use this flag instead, so 6835 that the option is not taken into account in ways that might affect 6836 executable code generation. 6837 6838'Undocumented' 6839 The option is deliberately missing documentation and should not be 6840 included in the '--help' output. 6841 6842'Condition(COND)' 6843 The option should only be accepted if preprocessor condition COND 6844 is true. Note that any C declarations associated with the option 6845 will be present even if COND is false; COND simply controls whether 6846 the option is accepted and whether it is printed in the '--help' 6847 output. 6848 6849'Save' 6850 Build the 'cl_target_option' structure to hold a copy of the 6851 option, add the functions 'cl_target_option_save' and 6852 'cl_target_option_restore' to save and restore the options. 6853 6854'SetByCombined' 6855 The option may also be set by a combined option such as 6856 '-ffast-math'. This causes the 'gcc_options' struct to have a 6857 field 'frontend_set_NAME', where 'NAME' is the name of the field 6858 holding the value of this option (without the leading 'x_'). This 6859 gives the front end a way to indicate that the value has been set 6860 explicitly and should not be changed by the combined option. For 6861 example, some front ends use this to prevent '-ffast-math' and 6862 '-fno-fast-math' from changing the value of '-fmath-errno' for 6863 languages that do not use 'errno'. 6864 6865'EnabledBy(OPT)' 6866'EnabledBy(OPT || OPT2)' 6867'EnabledBy(OPT && OPT2)' 6868 If not explicitly set, the option is set to the value of '-OPT'; 6869 multiple options can be given, separated by '||'. The third form 6870 using '&&' specifies that the option is only set if both OPT and 6871 OPT2 are set. The options OPT and OPT2 must have the 'Common' 6872 property; otherwise, use 'LangEnabledBy'. 6873 6874'LangEnabledBy(LANGUAGE, OPT)' 6875'LangEnabledBy(LANGUAGE, OPT, POSARG, NEGARG)' 6876 When compiling for the given language, the option is set to the 6877 value of '-OPT', if not explicitly set. OPT can be also a list of 6878 '||' separated options. In the second form, if OPT is used in the 6879 positive form then POSARG is considered to be passed to the option, 6880 and if OPT is used in the negative form then NEGARG is considered 6881 to be passed to the option. It is possible to specify several 6882 different languages. Each LANGUAGE must have been declared by an 6883 earlier 'Language' record. *Note Option file format::. 6884 6885'NoDWARFRecord' 6886 The option is omitted from the producer string written by 6887 '-grecord-gcc-switches'. 6888 6889'PchIgnore' 6890 Even if this is a target option, this option will not be recorded / 6891 compared to determine if a precompiled header file matches. 6892 6893'CPP(VAR)' 6894 The state of this option should be kept in sync with the 6895 preprocessor option VAR. If this property is set, then properties 6896 'Var' and 'Init' must be set as well. 6897 6898'CppReason(CPP_W_ENUM)' 6899 This warning option corresponds to 'cpplib.h' warning reason code 6900 CPP_W_ENUM. This should only be used for warning options of the 6901 C-family front-ends. 6902 6903 6904File: gccint.info, Node: Passes, Next: poly_int, Prev: Options, Up: Top 6905 69069 Passes and Files of the Compiler 6907********************************** 6908 6909This chapter is dedicated to giving an overview of the optimization and 6910code generation passes of the compiler. In the process, it describes 6911some of the language front end interface, though this description is no 6912where near complete. 6913 6914* Menu: 6915 6916* Parsing pass:: The language front end turns text into bits. 6917* Gimplification pass:: The bits are turned into something we can optimize. 6918* Pass manager:: Sequencing the optimization passes. 6919* Tree SSA passes:: Optimizations on a high-level representation. 6920* RTL passes:: Optimizations on a low-level representation. 6921* Optimization info:: Dumping optimization information from passes. 6922 6923 6924File: gccint.info, Node: Parsing pass, Next: Gimplification pass, Up: Passes 6925 69269.1 Parsing pass 6927================ 6928 6929The language front end is invoked only once, via 6930'lang_hooks.parse_file', to parse the entire input. The language front 6931end may use any intermediate language representation deemed appropriate. 6932The C front end uses GENERIC trees (*note GENERIC::), plus a double 6933handful of language specific tree codes defined in 'c-common.def'. The 6934Fortran front end uses a completely different private representation. 6935 6936 At some point the front end must translate the representation used in 6937the front end to a representation understood by the language-independent 6938portions of the compiler. Current practice takes one of two forms. The 6939C front end manually invokes the gimplifier (*note GIMPLE::) on each 6940function, and uses the gimplifier callbacks to convert the 6941language-specific tree nodes directly to GIMPLE before passing the 6942function off to be compiled. The Fortran front end converts from a 6943private representation to GENERIC, which is later lowered to GIMPLE when 6944the function is compiled. Which route to choose probably depends on how 6945well GENERIC (plus extensions) can be made to match up with the source 6946language and necessary parsing data structures. 6947 6948 BUG: Gimplification must occur before nested function lowering, and 6949nested function lowering must be done by the front end before passing 6950the data off to cgraph. 6951 6952 TODO: Cgraph should control nested function lowering. It would only be 6953invoked when it is certain that the outer-most function is used. 6954 6955 TODO: Cgraph needs a gimplify_function callback. It should be invoked 6956when (1) it is certain that the function is used, (2) warning flags 6957specified by the user require some amount of compilation in order to 6958honor, (3) the language indicates that semantic analysis is not complete 6959until gimplification occurs. Hum... this sounds overly complicated. 6960Perhaps we should just have the front end gimplify always; in most cases 6961it's only one function call. 6962 6963 The front end needs to pass all function definitions and top level 6964declarations off to the middle-end so that they can be compiled and 6965emitted to the object file. For a simple procedural language, it is 6966usually most convenient to do this as each top level declaration or 6967definition is seen. There is also a distinction to be made between 6968generating functional code and generating complete debug information. 6969The only thing that is absolutely required for functional code is that 6970function and data _definitions_ be passed to the middle-end. For 6971complete debug information, function, data and type declarations should 6972all be passed as well. 6973 6974 In any case, the front end needs each complete top-level function or 6975data declaration, and each data definition should be passed to 6976'rest_of_decl_compilation'. Each complete type definition should be 6977passed to 'rest_of_type_compilation'. Each function definition should 6978be passed to 'cgraph_finalize_function'. 6979 6980 TODO: I know rest_of_compilation currently has all sorts of RTL 6981generation semantics. I plan to move all code generation bits (both 6982Tree and RTL) to compile_function. Should we hide cgraph from the front 6983ends and move back to rest_of_compilation as the official interface? 6984Possibly we should rename all three interfaces such that the names match 6985in some meaningful way and that is more descriptive than "rest_of". 6986 6987 The middle-end will, at its option, emit the function and data 6988definitions immediately or queue them for later processing. 6989 6990 6991File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Parsing pass, Up: Passes 6992 69939.2 Gimplification pass 6994======================= 6995 6996"Gimplification" is a whimsical term for the process of converting the 6997intermediate representation of a function into the GIMPLE language 6998(*note GIMPLE::). The term stuck, and so words like "gimplification", 6999"gimplify", "gimplifier" and the like are sprinkled throughout this 7000section of code. 7001 7002 While a front end may certainly choose to generate GIMPLE directly if 7003it chooses, this can be a moderately complex process unless the 7004intermediate language used by the front end is already fairly simple. 7005Usually it is easier to generate GENERIC trees plus extensions and let 7006the language-independent gimplifier do most of the work. 7007 7008 The main entry point to this pass is 'gimplify_function_tree' located 7009in 'gimplify.c'. From here we process the entire function gimplifying 7010each statement in turn. The main workhorse for this pass is 7011'gimplify_expr'. Approximately everything passes through here at least 7012once, and it is from here that we invoke the 'lang_hooks.gimplify_expr' 7013callback. 7014 7015 The callback should examine the expression in question and return 7016'GS_UNHANDLED' if the expression is not a language specific construct 7017that requires attention. Otherwise it should alter the expression in 7018some way to such that forward progress is made toward producing valid 7019GIMPLE. If the callback is certain that the transformation is complete 7020and the expression is valid GIMPLE, it should return 'GS_ALL_DONE'. 7021Otherwise it should return 'GS_OK', which will cause the expression to 7022be processed again. If the callback encounters an error during the 7023transformation (because the front end is relying on the gimplification 7024process to finish semantic checks), it should return 'GS_ERROR'. 7025 7026 7027File: gccint.info, Node: Pass manager, Next: Tree SSA passes, Prev: Gimplification pass, Up: Passes 7028 70299.3 Pass manager 7030================ 7031 7032The pass manager is located in 'passes.c', 'tree-optimize.c' and 7033'tree-pass.h'. It processes passes as described in 'passes.def'. Its 7034job is to run all of the individual passes in the correct order, and 7035take care of standard bookkeeping that applies to every pass. 7036 7037 The theory of operation is that each pass defines a structure that 7038represents everything we need to know about that pass--when it should be 7039run, how it should be run, what intermediate language form or 7040on-the-side data structures it needs. We register the pass to be run in 7041some particular order, and the pass manager arranges for everything to 7042happen in the correct order. 7043 7044 The actuality doesn't completely live up to the theory at present. 7045Command-line switches and 'timevar_id_t' enumerations must still be 7046defined elsewhere. The pass manager validates constraints but does not 7047attempt to (re-)generate data structures or lower intermediate language 7048form based on the requirements of the next pass. Nevertheless, what is 7049present is useful, and a far sight better than nothing at all. 7050 7051 Each pass should have a unique name. Each pass may have its own dump 7052file (for GCC debugging purposes). Passes with a name starting with a 7053star do not dump anything. Sometimes passes are supposed to share a 7054dump file / option name. To still give these unique names, you can use 7055a prefix that is delimited by a space from the part that is used for the 7056dump file / option name. E.g. When the pass name is "ud dce", the name 7057used for dump file/options is "dce". 7058 7059 TODO: describe the global variables set up by the pass manager, and a 7060brief description of how a new pass should use it. I need to look at 7061what info RTL passes use first... 7062 7063 7064File: gccint.info, Node: Tree SSA passes, Next: RTL passes, Prev: Pass manager, Up: Passes 7065 70669.4 Tree SSA passes 7067=================== 7068 7069The following briefly describes the Tree optimization passes that are 7070run after gimplification and what source files they are located in. 7071 7072 * Remove useless statements 7073 7074 This pass is an extremely simple sweep across the gimple code in 7075 which we identify obviously dead code and remove it. Here we do 7076 things like simplify 'if' statements with constant conditions, 7077 remove exception handling constructs surrounding code that 7078 obviously cannot throw, remove lexical bindings that contain no 7079 variables, and other assorted simplistic cleanups. The idea is to 7080 get rid of the obvious stuff quickly rather than wait until later 7081 when it's more work to get rid of it. This pass is located in 7082 'tree-cfg.c' and described by 'pass_remove_useless_stmts'. 7083 7084 * OpenMP lowering 7085 7086 If OpenMP generation ('-fopenmp') is enabled, this pass lowers 7087 OpenMP constructs into GIMPLE. 7088 7089 Lowering of OpenMP constructs involves creating replacement 7090 expressions for local variables that have been mapped using data 7091 sharing clauses, exposing the control flow of most synchronization 7092 directives and adding region markers to facilitate the creation of 7093 the control flow graph. The pass is located in 'omp-low.c' and is 7094 described by 'pass_lower_omp'. 7095 7096 * OpenMP expansion 7097 7098 If OpenMP generation ('-fopenmp') is enabled, this pass expands 7099 parallel regions into their own functions to be invoked by the 7100 thread library. The pass is located in 'omp-low.c' and is 7101 described by 'pass_expand_omp'. 7102 7103 * Lower control flow 7104 7105 This pass flattens 'if' statements ('COND_EXPR') and moves lexical 7106 bindings ('BIND_EXPR') out of line. After this pass, all 'if' 7107 statements will have exactly two 'goto' statements in its 'then' 7108 and 'else' arms. Lexical binding information for each statement 7109 will be found in 'TREE_BLOCK' rather than being inferred from its 7110 position under a 'BIND_EXPR'. This pass is found in 'gimple-low.c' 7111 and is described by 'pass_lower_cf'. 7112 7113 * Lower exception handling control flow 7114 7115 This pass decomposes high-level exception handling constructs 7116 ('TRY_FINALLY_EXPR' and 'TRY_CATCH_EXPR') into a form that 7117 explicitly represents the control flow involved. After this pass, 7118 'lookup_stmt_eh_region' will return a non-negative number for any 7119 statement that may have EH control flow semantics; examine 7120 'tree_can_throw_internal' or 'tree_can_throw_external' for exact 7121 semantics. Exact control flow may be extracted from 7122 'foreach_reachable_handler'. The EH region nesting tree is defined 7123 in 'except.h' and built in 'except.c'. The lowering pass itself is 7124 in 'tree-eh.c' and is described by 'pass_lower_eh'. 7125 7126 * Build the control flow graph 7127 7128 This pass decomposes a function into basic blocks and creates all 7129 of the edges that connect them. It is located in 'tree-cfg.c' and 7130 is described by 'pass_build_cfg'. 7131 7132 * Find all referenced variables 7133 7134 This pass walks the entire function and collects an array of all 7135 variables referenced in the function, 'referenced_vars'. The index 7136 at which a variable is found in the array is used as a UID for the 7137 variable within this function. This data is needed by the SSA 7138 rewriting routines. The pass is located in 'tree-dfa.c' and is 7139 described by 'pass_referenced_vars'. 7140 7141 * Enter static single assignment form 7142 7143 This pass rewrites the function such that it is in SSA form. After 7144 this pass, all 'is_gimple_reg' variables will be referenced by 7145 'SSA_NAME', and all occurrences of other variables will be 7146 annotated with 'VDEFS' and 'VUSES'; PHI nodes will have been 7147 inserted as necessary for each basic block. This pass is located 7148 in 'tree-ssa.c' and is described by 'pass_build_ssa'. 7149 7150 * Warn for uninitialized variables 7151 7152 This pass scans the function for uses of 'SSA_NAME's that are fed 7153 by default definition. For non-parameter variables, such uses are 7154 uninitialized. The pass is run twice, before and after 7155 optimization (if turned on). In the first pass we only warn for 7156 uses that are positively uninitialized; in the second pass we warn 7157 for uses that are possibly uninitialized. The pass is located in 7158 'tree-ssa.c' and is defined by 'pass_early_warn_uninitialized' and 7159 'pass_late_warn_uninitialized'. 7160 7161 * Dead code elimination 7162 7163 This pass scans the function for statements without side effects 7164 whose result is unused. It does not do memory life analysis, so 7165 any value that is stored in memory is considered used. The pass is 7166 run multiple times throughout the optimization process. It is 7167 located in 'tree-ssa-dce.c' and is described by 'pass_dce'. 7168 7169 * Dominator optimizations 7170 7171 This pass performs trivial dominator-based copy and constant 7172 propagation, expression simplification, and jump threading. It is 7173 run multiple times throughout the optimization process. It is 7174 located in 'tree-ssa-dom.c' and is described by 'pass_dominator'. 7175 7176 * Forward propagation of single-use variables 7177 7178 This pass attempts to remove redundant computation by substituting 7179 variables that are used once into the expression that uses them and 7180 seeing if the result can be simplified. It is located in 7181 'tree-ssa-forwprop.c' and is described by 'pass_forwprop'. 7182 7183 * Copy Renaming 7184 7185 This pass attempts to change the name of compiler temporaries 7186 involved in copy operations such that SSA->normal can coalesce the 7187 copy away. When compiler temporaries are copies of user variables, 7188 it also renames the compiler temporary to the user variable 7189 resulting in better use of user symbols. It is located in 7190 'tree-ssa-copyrename.c' and is described by 'pass_copyrename'. 7191 7192 * PHI node optimizations 7193 7194 This pass recognizes forms of PHI inputs that can be represented as 7195 conditional expressions and rewrites them into straight line code. 7196 It is located in 'tree-ssa-phiopt.c' and is described by 7197 'pass_phiopt'. 7198 7199 * May-alias optimization 7200 7201 This pass performs a flow sensitive SSA-based points-to analysis. 7202 The resulting may-alias, must-alias, and escape analysis 7203 information is used to promote variables from in-memory addressable 7204 objects to non-aliased variables that can be renamed into SSA form. 7205 We also update the 'VDEF'/'VUSE' memory tags for non-renameable 7206 aggregates so that we get fewer false kills. The pass is located 7207 in 'tree-ssa-alias.c' and is described by 'pass_may_alias'. 7208 7209 Interprocedural points-to information is located in 7210 'tree-ssa-structalias.c' and described by 'pass_ipa_pta'. 7211 7212 * Profiling 7213 7214 This pass instruments the function in order to collect runtime 7215 block and value profiling data. Such data may be fed back into the 7216 compiler on a subsequent run so as to allow optimization based on 7217 expected execution frequencies. The pass is located in 7218 'tree-profile.c' and is described by 'pass_ipa_tree_profile'. 7219 7220 * Static profile estimation 7221 7222 This pass implements series of heuristics to guess propababilities 7223 of branches. The resulting predictions are turned into edge 7224 profile by propagating branches across the control flow graphs. 7225 The pass is located in 'tree-profile.c' and is described by 7226 'pass_profile'. 7227 7228 * Lower complex arithmetic 7229 7230 This pass rewrites complex arithmetic operations into their 7231 component scalar arithmetic operations. The pass is located in 7232 'tree-complex.c' and is described by 'pass_lower_complex'. 7233 7234 * Scalar replacement of aggregates 7235 7236 This pass rewrites suitable non-aliased local aggregate variables 7237 into a set of scalar variables. The resulting scalar variables are 7238 rewritten into SSA form, which allows subsequent optimization 7239 passes to do a significantly better job with them. The pass is 7240 located in 'tree-sra.c' and is described by 'pass_sra'. 7241 7242 * Dead store elimination 7243 7244 This pass eliminates stores to memory that are subsequently 7245 overwritten by another store, without any intervening loads. The 7246 pass is located in 'tree-ssa-dse.c' and is described by 'pass_dse'. 7247 7248 * Tail recursion elimination 7249 7250 This pass transforms tail recursion into a loop. It is located in 7251 'tree-tailcall.c' and is described by 'pass_tail_recursion'. 7252 7253 * Forward store motion 7254 7255 This pass sinks stores and assignments down the flowgraph closer to 7256 their use point. The pass is located in 'tree-ssa-sink.c' and is 7257 described by 'pass_sink_code'. 7258 7259 * Partial redundancy elimination 7260 7261 This pass eliminates partially redundant computations, as well as 7262 performing load motion. The pass is located in 'tree-ssa-pre.c' 7263 and is described by 'pass_pre'. 7264 7265 Just before partial redundancy elimination, if 7266 '-funsafe-math-optimizations' is on, GCC tries to convert divisions 7267 to multiplications by the reciprocal. The pass is located in 7268 'tree-ssa-math-opts.c' and is described by 'pass_cse_reciprocal'. 7269 7270 * Full redundancy elimination 7271 7272 This is a simpler form of PRE that only eliminates redundancies 7273 that occur on all paths. It is located in 'tree-ssa-pre.c' and 7274 described by 'pass_fre'. 7275 7276 * Loop optimization 7277 7278 The main driver of the pass is placed in 'tree-ssa-loop.c' and 7279 described by 'pass_loop'. 7280 7281 The optimizations performed by this pass are: 7282 7283 Loop invariant motion. This pass moves only invariants that would 7284 be hard to handle on RTL level (function calls, operations that 7285 expand to nontrivial sequences of insns). With '-funswitch-loops' 7286 it also moves operands of conditions that are invariant out of the 7287 loop, so that we can use just trivial invariantness analysis in 7288 loop unswitching. The pass also includes store motion. The pass 7289 is implemented in 'tree-ssa-loop-im.c'. 7290 7291 Canonical induction variable creation. This pass creates a simple 7292 counter for number of iterations of the loop and replaces the exit 7293 condition of the loop using it, in case when a complicated analysis 7294 is necessary to determine the number of iterations. Later 7295 optimizations then may determine the number easily. The pass is 7296 implemented in 'tree-ssa-loop-ivcanon.c'. 7297 7298 Induction variable optimizations. This pass performs standard 7299 induction variable optimizations, including strength reduction, 7300 induction variable merging and induction variable elimination. The 7301 pass is implemented in 'tree-ssa-loop-ivopts.c'. 7302 7303 Loop unswitching. This pass moves the conditional jumps that are 7304 invariant out of the loops. To achieve this, a duplicate of the 7305 loop is created for each possible outcome of conditional jump(s). 7306 The pass is implemented in 'tree-ssa-loop-unswitch.c'. 7307 7308 Loop splitting. If a loop contains a conditional statement that is 7309 always true for one part of the iteration space and false for the 7310 other this pass splits the loop into two, one dealing with one side 7311 the other only with the other, thereby removing one inner-loop 7312 conditional. The pass is implemented in 'tree-ssa-loop-split.c'. 7313 7314 The optimizations also use various utility functions contained in 7315 'tree-ssa-loop-manip.c', 'cfgloop.c', 'cfgloopanal.c' and 7316 'cfgloopmanip.c'. 7317 7318 Vectorization. This pass transforms loops to operate on vector 7319 types instead of scalar types. Data parallelism across loop 7320 iterations is exploited to group data elements from consecutive 7321 iterations into a vector and operate on them in parallel. 7322 Depending on available target support the loop is conceptually 7323 unrolled by a factor 'VF' (vectorization factor), which is the 7324 number of elements operated upon in parallel in each iteration, and 7325 the 'VF' copies of each scalar operation are fused to form a vector 7326 operation. Additional loop transformations such as peeling and 7327 versioning may take place to align the number of iterations, and to 7328 align the memory accesses in the loop. The pass is implemented in 7329 'tree-vectorizer.c' (the main driver), 'tree-vect-loop.c' and 7330 'tree-vect-loop-manip.c' (loop specific parts and general loop 7331 utilities), 'tree-vect-slp' (loop-aware SLP functionality), 7332 'tree-vect-stmts.c' and 'tree-vect-data-refs.c'. Analysis of data 7333 references is in 'tree-data-ref.c'. 7334 7335 SLP Vectorization. This pass performs vectorization of 7336 straight-line code. The pass is implemented in 'tree-vectorizer.c' 7337 (the main driver), 'tree-vect-slp.c', 'tree-vect-stmts.c' and 7338 'tree-vect-data-refs.c'. 7339 7340 Autoparallelization. This pass splits the loop iteration space to 7341 run into several threads. The pass is implemented in 7342 'tree-parloops.c'. 7343 7344 Graphite is a loop transformation framework based on the polyhedral 7345 model. Graphite stands for Gimple Represented as Polyhedra. The 7346 internals of this infrastructure are documented in 7347 <http://gcc.gnu.org/wiki/Graphite>. The passes working on this 7348 representation are implemented in the various 'graphite-*' files. 7349 7350 * Tree level if-conversion for vectorizer 7351 7352 This pass applies if-conversion to simple loops to help vectorizer. 7353 We identify if convertible loops, if-convert statements and merge 7354 basic blocks in one big block. The idea is to present loop in such 7355 form so that vectorizer can have one to one mapping between 7356 statements and available vector operations. This pass is located 7357 in 'tree-if-conv.c' and is described by 'pass_if_conversion'. 7358 7359 * Conditional constant propagation 7360 7361 This pass relaxes a lattice of values in order to identify those 7362 that must be constant even in the presence of conditional branches. 7363 The pass is located in 'tree-ssa-ccp.c' and is described by 7364 'pass_ccp'. 7365 7366 A related pass that works on memory loads and stores, and not just 7367 register values, is located in 'tree-ssa-ccp.c' and described by 7368 'pass_store_ccp'. 7369 7370 * Conditional copy propagation 7371 7372 This is similar to constant propagation but the lattice of values 7373 is the "copy-of" relation. It eliminates redundant copies from the 7374 code. The pass is located in 'tree-ssa-copy.c' and described by 7375 'pass_copy_prop'. 7376 7377 A related pass that works on memory copies, and not just register 7378 copies, is located in 'tree-ssa-copy.c' and described by 7379 'pass_store_copy_prop'. 7380 7381 * Value range propagation 7382 7383 This transformation is similar to constant propagation but instead 7384 of propagating single constant values, it propagates known value 7385 ranges. The implementation is based on Patterson's range 7386 propagation algorithm (Accurate Static Branch Prediction by Value 7387 Range Propagation, J. R. C. Patterson, PLDI '95). In contrast to 7388 Patterson's algorithm, this implementation does not propagate 7389 branch probabilities nor it uses more than a single range per SSA 7390 name. This means that the current implementation cannot be used 7391 for branch prediction (though adapting it would not be difficult). 7392 The pass is located in 'tree-vrp.c' and is described by 'pass_vrp'. 7393 7394 * Folding built-in functions 7395 7396 This pass simplifies built-in functions, as applicable, with 7397 constant arguments or with inferable string lengths. It is located 7398 in 'tree-ssa-ccp.c' and is described by 'pass_fold_builtins'. 7399 7400 * Split critical edges 7401 7402 This pass identifies critical edges and inserts empty basic blocks 7403 such that the edge is no longer critical. The pass is located in 7404 'tree-cfg.c' and is described by 'pass_split_crit_edges'. 7405 7406 * Control dependence dead code elimination 7407 7408 This pass is a stronger form of dead code elimination that can 7409 eliminate unnecessary control flow statements. It is located in 7410 'tree-ssa-dce.c' and is described by 'pass_cd_dce'. 7411 7412 * Tail call elimination 7413 7414 This pass identifies function calls that may be rewritten into 7415 jumps. No code transformation is actually applied here, but the 7416 data and control flow problem is solved. The code transformation 7417 requires target support, and so is delayed until RTL. In the 7418 meantime 'CALL_EXPR_TAILCALL' is set indicating the possibility. 7419 The pass is located in 'tree-tailcall.c' and is described by 7420 'pass_tail_calls'. The RTL transformation is handled by 7421 'fixup_tail_calls' in 'calls.c'. 7422 7423 * Warn for function return without value 7424 7425 For non-void functions, this pass locates return statements that do 7426 not specify a value and issues a warning. Such a statement may 7427 have been injected by falling off the end of the function. This 7428 pass is run last so that we have as much time as possible to prove 7429 that the statement is not reachable. It is located in 'tree-cfg.c' 7430 and is described by 'pass_warn_function_return'. 7431 7432 * Leave static single assignment form 7433 7434 This pass rewrites the function such that it is in normal form. At 7435 the same time, we eliminate as many single-use temporaries as 7436 possible, so the intermediate language is no longer GIMPLE, but 7437 GENERIC. The pass is located in 'tree-outof-ssa.c' and is 7438 described by 'pass_del_ssa'. 7439 7440 * Merge PHI nodes that feed into one another 7441 7442 This is part of the CFG cleanup passes. It attempts to join PHI 7443 nodes from a forwarder CFG block into another block with PHI nodes. 7444 The pass is located in 'tree-cfgcleanup.c' and is described by 7445 'pass_merge_phi'. 7446 7447 * Return value optimization 7448 7449 If a function always returns the same local variable, and that 7450 local variable is an aggregate type, then the variable is replaced 7451 with the return value for the function (i.e., the function's 7452 DECL_RESULT). This is equivalent to the C++ named return value 7453 optimization applied to GIMPLE. The pass is located in 7454 'tree-nrv.c' and is described by 'pass_nrv'. 7455 7456 * Return slot optimization 7457 7458 If a function returns a memory object and is called as 'var = 7459 foo()', this pass tries to change the call so that the address of 7460 'var' is sent to the caller to avoid an extra memory copy. This 7461 pass is located in 'tree-nrv.c' and is described by 7462 'pass_return_slot'. 7463 7464 * Optimize calls to '__builtin_object_size' 7465 7466 This is a propagation pass similar to CCP that tries to remove 7467 calls to '__builtin_object_size' when the size of the object can be 7468 computed at compile-time. This pass is located in 7469 'tree-object-size.c' and is described by 'pass_object_sizes'. 7470 7471 * Loop invariant motion 7472 7473 This pass removes expensive loop-invariant computations out of 7474 loops. The pass is located in 'tree-ssa-loop.c' and described by 7475 'pass_lim'. 7476 7477 * Loop nest optimizations 7478 7479 This is a family of loop transformations that works on loop nests. 7480 It includes loop interchange, scaling, skewing and reversal and 7481 they are all geared to the optimization of data locality in array 7482 traversals and the removal of dependencies that hamper 7483 optimizations such as loop parallelization and vectorization. The 7484 pass is located in 'tree-loop-linear.c' and described by 7485 'pass_linear_transform'. 7486 7487 * Removal of empty loops 7488 7489 This pass removes loops with no code in them. The pass is located 7490 in 'tree-ssa-loop-ivcanon.c' and described by 'pass_empty_loop'. 7491 7492 * Unrolling of small loops 7493 7494 This pass completely unrolls loops with few iterations. The pass 7495 is located in 'tree-ssa-loop-ivcanon.c' and described by 7496 'pass_complete_unroll'. 7497 7498 * Predictive commoning 7499 7500 This pass makes the code reuse the computations from the previous 7501 iterations of the loops, especially loads and stores to memory. It 7502 does so by storing the values of these computations to a bank of 7503 temporary variables that are rotated at the end of loop. To avoid 7504 the need for this rotation, the loop is then unrolled and the 7505 copies of the loop body are rewritten to use the appropriate 7506 version of the temporary variable. This pass is located in 7507 'tree-predcom.c' and described by 'pass_predcom'. 7508 7509 * Array prefetching 7510 7511 This pass issues prefetch instructions for array references inside 7512 loops. The pass is located in 'tree-ssa-loop-prefetch.c' and 7513 described by 'pass_loop_prefetch'. 7514 7515 * Reassociation 7516 7517 This pass rewrites arithmetic expressions to enable optimizations 7518 that operate on them, like redundancy elimination and 7519 vectorization. The pass is located in 'tree-ssa-reassoc.c' and 7520 described by 'pass_reassoc'. 7521 7522 * Optimization of 'stdarg' functions 7523 7524 This pass tries to avoid the saving of register arguments into the 7525 stack on entry to 'stdarg' functions. If the function doesn't use 7526 any 'va_start' macros, no registers need to be saved. If 7527 'va_start' macros are used, the 'va_list' variables don't escape 7528 the function, it is only necessary to save registers that will be 7529 used in 'va_arg' macros. For instance, if 'va_arg' is only used 7530 with integral types in the function, floating point registers don't 7531 need to be saved. This pass is located in 'tree-stdarg.c' and 7532 described by 'pass_stdarg'. 7533 7534 7535File: gccint.info, Node: RTL passes, Next: Optimization info, Prev: Tree SSA passes, Up: Passes 7536 75379.5 RTL passes 7538============== 7539 7540The following briefly describes the RTL generation and optimization 7541passes that are run after the Tree optimization passes. 7542 7543 * RTL generation 7544 7545 The source files for RTL generation include 'stmt.c', 'calls.c', 7546 'expr.c', 'explow.c', 'expmed.c', 'function.c', 'optabs.c' and 7547 'emit-rtl.c'. Also, the file 'insn-emit.c', generated from the 7548 machine description by the program 'genemit', is used in this pass. 7549 The header file 'expr.h' is used for communication within this 7550 pass. 7551 7552 The header files 'insn-flags.h' and 'insn-codes.h', generated from 7553 the machine description by the programs 'genflags' and 'gencodes', 7554 tell this pass which standard names are available for use and which 7555 patterns correspond to them. 7556 7557 * Generation of exception landing pads 7558 7559 This pass generates the glue that handles communication between the 7560 exception handling library routines and the exception handlers 7561 within the function. Entry points in the function that are invoked 7562 by the exception handling library are called "landing pads". The 7563 code for this pass is located in 'except.c'. 7564 7565 * Control flow graph cleanup 7566 7567 This pass removes unreachable code, simplifies jumps to next, jumps 7568 to jump, jumps across jumps, etc. The pass is run multiple times. 7569 For historical reasons, it is occasionally referred to as the "jump 7570 optimization pass". The bulk of the code for this pass is in 7571 'cfgcleanup.c', and there are support routines in 'cfgrtl.c' and 7572 'jump.c'. 7573 7574 * Forward propagation of single-def values 7575 7576 This pass attempts to remove redundant computation by substituting 7577 variables that come from a single definition, and seeing if the 7578 result can be simplified. It performs copy propagation and 7579 addressing mode selection. The pass is run twice, with values 7580 being propagated into loops only on the second run. The code is 7581 located in 'fwprop.c'. 7582 7583 * Common subexpression elimination 7584 7585 This pass removes redundant computation within basic blocks, and 7586 optimizes addressing modes based on cost. The pass is run twice. 7587 The code for this pass is located in 'cse.c'. 7588 7589 * Global common subexpression elimination 7590 7591 This pass performs two different types of GCSE depending on whether 7592 you are optimizing for size or not (LCM based GCSE tends to 7593 increase code size for a gain in speed, while Morel-Renvoise based 7594 GCSE does not). When optimizing for size, GCSE is done using 7595 Morel-Renvoise Partial Redundancy Elimination, with the exception 7596 that it does not try to move invariants out of loops--that is left 7597 to the loop optimization pass. If MR PRE GCSE is done, code 7598 hoisting (aka unification) is also done, as well as load motion. 7599 If you are optimizing for speed, LCM (lazy code motion) based GCSE 7600 is done. LCM is based on the work of Knoop, Ruthing, and Steffen. 7601 LCM based GCSE also does loop invariant code motion. We also 7602 perform load and store motion when optimizing for speed. 7603 Regardless of which type of GCSE is used, the GCSE pass also 7604 performs global constant and copy propagation. The source file for 7605 this pass is 'gcse.c', and the LCM routines are in 'lcm.c'. 7606 7607 * Loop optimization 7608 7609 This pass performs several loop related optimizations. The source 7610 files 'cfgloopanal.c' and 'cfgloopmanip.c' contain generic loop 7611 analysis and manipulation code. Initialization and finalization of 7612 loop structures is handled by 'loop-init.c'. A loop invariant 7613 motion pass is implemented in 'loop-invariant.c'. Basic block 7614 level optimizations--unrolling, and peeling loops-- are implemented 7615 in 'loop-unroll.c'. Replacing of the exit condition of loops by 7616 special machine-dependent instructions is handled by 7617 'loop-doloop.c'. 7618 7619 * Jump bypassing 7620 7621 This pass is an aggressive form of GCSE that transforms the control 7622 flow graph of a function by propagating constants into conditional 7623 branch instructions. The source file for this pass is 'gcse.c'. 7624 7625 * If conversion 7626 7627 This pass attempts to replace conditional branches and surrounding 7628 assignments with arithmetic, boolean value producing comparison 7629 instructions, and conditional move instructions. In the very last 7630 invocation after reload/LRA, it will generate predicated 7631 instructions when supported by the target. The code is located in 7632 'ifcvt.c'. 7633 7634 * Web construction 7635 7636 This pass splits independent uses of each pseudo-register. This 7637 can improve effect of the other transformation, such as CSE or 7638 register allocation. The code for this pass is located in 'web.c'. 7639 7640 * Instruction combination 7641 7642 This pass attempts to combine groups of two or three instructions 7643 that are related by data flow into single instructions. It 7644 combines the RTL expressions for the instructions by substitution, 7645 simplifies the result using algebra, and then attempts to match the 7646 result against the machine description. The code is located in 7647 'combine.c'. 7648 7649 * Mode switching optimization 7650 7651 This pass looks for instructions that require the processor to be 7652 in a specific "mode" and minimizes the number of mode changes 7653 required to satisfy all users. What these modes are, and what they 7654 apply to are completely target-specific. The code for this pass is 7655 located in 'mode-switching.c'. 7656 7657 * Modulo scheduling 7658 7659 This pass looks at innermost loops and reorders their instructions 7660 by overlapping different iterations. Modulo scheduling is 7661 performed immediately before instruction scheduling. The code for 7662 this pass is located in 'modulo-sched.c'. 7663 7664 * Instruction scheduling 7665 7666 This pass looks for instructions whose output will not be available 7667 by the time that it is used in subsequent instructions. Memory 7668 loads and floating point instructions often have this behavior on 7669 RISC machines. It re-orders instructions within a basic block to 7670 try to separate the definition and use of items that otherwise 7671 would cause pipeline stalls. This pass is performed twice, before 7672 and after register allocation. The code for this pass is located 7673 in 'haifa-sched.c', 'sched-deps.c', 'sched-ebb.c', 'sched-rgn.c' 7674 and 'sched-vis.c'. 7675 7676 * Register allocation 7677 7678 These passes make sure that all occurrences of pseudo registers are 7679 eliminated, either by allocating them to a hard register, replacing 7680 them by an equivalent expression (e.g. a constant) or by placing 7681 them on the stack. This is done in several subpasses: 7682 7683 * The integrated register allocator (IRA). It is called 7684 integrated because coalescing, register live range splitting, 7685 and hard register preferencing are done on-the-fly during 7686 coloring. It also has better integration with the reload/LRA 7687 pass. Pseudo-registers spilled by the allocator or the 7688 reload/LRA have still a chance to get hard-registers if the 7689 reload/LRA evicts some pseudo-registers from hard-registers. 7690 The allocator helps to choose better pseudos for spilling 7691 based on their live ranges and to coalesce stack slots 7692 allocated for the spilled pseudo-registers. IRA is a regional 7693 register allocator which is transformed into Chaitin-Briggs 7694 allocator if there is one region. By default, IRA chooses 7695 regions using register pressure but the user can force it to 7696 use one region or regions corresponding to all loops. 7697 7698 Source files of the allocator are 'ira.c', 'ira-build.c', 7699 'ira-costs.c', 'ira-conflicts.c', 'ira-color.c', 'ira-emit.c', 7700 'ira-lives', plus header files 'ira.h' and 'ira-int.h' used 7701 for the communication between the allocator and the rest of 7702 the compiler and between the IRA files. 7703 7704 * Reloading. This pass renumbers pseudo registers with the 7705 hardware registers numbers they were allocated. Pseudo 7706 registers that did not get hard registers are replaced with 7707 stack slots. Then it finds instructions that are invalid 7708 because a value has failed to end up in a register, or has 7709 ended up in a register of the wrong kind. It fixes up these 7710 instructions by reloading the problematical values temporarily 7711 into registers. Additional instructions are generated to do 7712 the copying. 7713 7714 The reload pass also optionally eliminates the frame pointer 7715 and inserts instructions to save and restore call-clobbered 7716 registers around calls. 7717 7718 Source files are 'reload.c' and 'reload1.c', plus the header 7719 'reload.h' used for communication between them. 7720 7721 * This pass is a modern replacement of the reload pass. Source 7722 files are 'lra.c', 'lra-assign.c', 'lra-coalesce.c', 7723 'lra-constraints.c', 'lra-eliminations.c', 'lra-lives.c', 7724 'lra-remat.c', 'lra-spills.c', the header 'lra-int.h' used for 7725 communication between them, and the header 'lra.h' used for 7726 communication between LRA and the rest of compiler. 7727 7728 Unlike the reload pass, intermediate LRA decisions are 7729 reflected in RTL as much as possible. This reduces the number 7730 of target-dependent macros and hooks, leaving instruction 7731 constraints as the primary source of control. 7732 7733 LRA is run on targets for which TARGET_LRA_P returns true. 7734 7735 * Basic block reordering 7736 7737 This pass implements profile guided code positioning. If profile 7738 information is not available, various types of static analysis are 7739 performed to make the predictions normally coming from the profile 7740 feedback (IE execution frequency, branch probability, etc). It is 7741 implemented in the file 'bb-reorder.c', and the various prediction 7742 routines are in 'predict.c'. 7743 7744 * Variable tracking 7745 7746 This pass computes where the variables are stored at each position 7747 in code and generates notes describing the variable locations to 7748 RTL code. The location lists are then generated according to these 7749 notes to debug information if the debugging information format 7750 supports location lists. The code is located in 'var-tracking.c'. 7751 7752 * Delayed branch scheduling 7753 7754 This optional pass attempts to find instructions that can go into 7755 the delay slots of other instructions, usually jumps and calls. 7756 The code for this pass is located in 'reorg.c'. 7757 7758 * Branch shortening 7759 7760 On many RISC machines, branch instructions have a limited range. 7761 Thus, longer sequences of instructions must be used for long 7762 branches. In this pass, the compiler figures out what how far each 7763 instruction will be from each other instruction, and therefore 7764 whether the usual instructions, or the longer sequences, must be 7765 used for each branch. The code for this pass is located in 7766 'final.c'. 7767 7768 * Register-to-stack conversion 7769 7770 Conversion from usage of some hard registers to usage of a register 7771 stack may be done at this point. Currently, this is supported only 7772 for the floating-point registers of the Intel 80387 coprocessor. 7773 The code for this pass is located in 'reg-stack.c'. 7774 7775 * Final 7776 7777 This pass outputs the assembler code for the function. The source 7778 files are 'final.c' plus 'insn-output.c'; the latter is generated 7779 automatically from the machine description by the tool 'genoutput'. 7780 The header file 'conditions.h' is used for communication between 7781 these files. 7782 7783 * Debugging information output 7784 7785 This is run after final because it must output the stack slot 7786 offsets for pseudo registers that did not get hard registers. 7787 Source files are 'dbxout.c' for DBX symbol table format, 7788 'dwarfout.c' for DWARF symbol table format, files 'dwarf2out.c' and 7789 'dwarf2asm.c' for DWARF2 symbol table format, and 'vmsdbgout.c' for 7790 VMS debug symbol table format. 7791 7792 7793File: gccint.info, Node: Optimization info, Prev: RTL passes, Up: Passes 7794 77959.6 Optimization info 7796===================== 7797 7798This section is describes dump infrastructure which is common to both 7799pass dumps as well as optimization dumps. The goal for this 7800infrastructure is to provide both gcc developers and users detailed 7801information about various compiler transformations and optimizations. 7802 7803* Menu: 7804 7805* Dump setup:: Setup of optimization dumps. 7806* Optimization groups:: Groups made up of optimization passes. 7807* Dump files and streams:: Dump output file names and streams. 7808* Dump output verbosity:: How much information to dump. 7809* Dump types:: Various types of dump functions. 7810* Dump examples:: Sample usage. 7811 7812 7813File: gccint.info, Node: Dump setup, Next: Optimization groups, Up: Optimization info 7814 78159.6.1 Dump setup 7816---------------- 7817 7818A dump_manager class is defined in 'dumpfile.h'. Various passes 7819register dumping pass-specific information via 'dump_register' in 7820'passes.c'. During the registration, an optimization pass can select 7821its optimization group (*note Optimization groups::). After that 7822optimization information corresponding to the entire group (presumably 7823from multiple passes) can be output via command-line switches. Note 7824that if a pass does not fit into any of the pre-defined groups, it can 7825select 'OPTGROUP_NONE'. 7826 7827 Note that in general, a pass need not know its dump output file name, 7828whether certain flags are enabled, etc. However, for legacy reasons, 7829passes could also call 'dump_begin' which returns a stream in case the 7830particular pass has optimization dumps enabled. A pass could call 7831'dump_end' when the dump has ended. These methods should go away once 7832all the passes are converted to use the new dump infrastructure. 7833 7834 The recommended way to setup the dump output is via 'dump_start' and 7835'dump_end'. 7836 7837 7838File: gccint.info, Node: Optimization groups, Next: Dump files and streams, Prev: Dump setup, Up: Optimization info 7839 78409.6.2 Optimization groups 7841------------------------- 7842 7843The optimization passes are grouped into several categories. Currently 7844defined categories in 'dumpfile.h' are 7845 7846'OPTGROUP_IPA' 7847 IPA optimization passes. Enabled by '-ipa' 7848 7849'OPTGROUP_LOOP' 7850 Loop optimization passes. Enabled by '-loop'. 7851 7852'OPTGROUP_INLINE' 7853 Inlining passes. Enabled by '-inline'. 7854 7855'OPTGROUP_OMP' 7856 OMP (Offloading and Multi Processing) passes. Enabled by '-omp'. 7857 7858'OPTGROUP_VEC' 7859 Vectorization passes. Enabled by '-vec'. 7860 7861'OPTGROUP_OTHER' 7862 All other optimization passes which do not fall into one of the 7863 above. 7864 7865'OPTGROUP_ALL' 7866 All optimization passes. Enabled by '-optall'. 7867 7868 By using groups a user could selectively enable optimization 7869information only for a group of passes. By default, the optimization 7870information for all the passes is dumped. 7871 7872 7873File: gccint.info, Node: Dump files and streams, Next: Dump output verbosity, Prev: Optimization groups, Up: Optimization info 7874 78759.6.3 Dump files and streams 7876---------------------------- 7877 7878There are two separate output streams available for outputting 7879optimization information from passes. Note that both these streams 7880accept 'stderr' and 'stdout' as valid streams and thus it is possible to 7881dump output to standard output or error. This is specially handy for 7882outputting all available information in a single file by redirecting 7883'stderr'. 7884 7885'pstream' 7886 This stream is for pass-specific dump output. For example, 7887 '-fdump-tree-vect=foo.v' dumps tree vectorization pass output into 7888 the given file name 'foo.v'. If the file name is not provided, the 7889 default file name is based on the source file and pass number. 7890 Note that one could also use special file names 'stdout' and 7891 'stderr' for dumping to standard output and standard error 7892 respectively. 7893 7894'alt_stream' 7895 This steam is used for printing optimization specific output in 7896 response to the '-fopt-info'. Again a file name can be given. If 7897 the file name is not given, it defaults to 'stderr'. 7898 7899 7900File: gccint.info, Node: Dump output verbosity, Next: Dump types, Prev: Dump files and streams, Up: Optimization info 7901 79029.6.4 Dump output verbosity 7903--------------------------- 7904 7905The dump verbosity has the following options 7906 7907'optimized' 7908 Print information when an optimization is successfully applied. It 7909 is up to a pass to decide which information is relevant. For 7910 example, the vectorizer passes print the source location of loops 7911 which got successfully vectorized. 7912 7913'missed' 7914 Print information about missed optimizations. Individual passes 7915 control which information to include in the output. For example, 7916 7917 gcc -O2 -ftree-vectorize -fopt-info-vec-missed 7918 7919 will print information about missed optimization opportunities from 7920 vectorization passes on stderr. 7921 7922'note' 7923 Print verbose information about optimizations, such as certain 7924 transformations, more detailed messages about decisions etc. 7925 7926'all' 7927 Print detailed optimization information. This includes OPTIMIZED, 7928 MISSED, and NOTE. 7929 7930 7931File: gccint.info, Node: Dump types, Next: Dump examples, Prev: Dump output verbosity, Up: Optimization info 7932 79339.6.5 Dump types 7934---------------- 7935 7936'dump_printf' 7937 7938 This is a generic method for doing formatted output. It takes an 7939 additional argument 'dump_kind' which signifies the type of dump. 7940 This method outputs information only when the dumps are enabled for 7941 this particular 'dump_kind'. Note that the caller doesn't need to 7942 know if the particular dump is enabled or not, or even the file 7943 name. The caller only needs to decide which dump output 7944 information is relevant, and under what conditions. This 7945 determines the associated flags. 7946 7947 Consider the following example from 'loop-unroll.c' where an 7948 informative message about a loop (along with its location) is 7949 printed when any of the following flags is enabled 7950 7951 - optimization messages 7952 - RTL dumps 7953 - detailed dumps 7954 7955 int report_flags = MSG_OPTIMIZED_LOCATIONS | TDF_RTL | TDF_DETAILS; 7956 dump_printf_loc (report_flags, locus, 7957 "loop turned into non-loop; it never loops.\n"); 7958 7959'dump_basic_block' 7960 Output basic block. 7961'dump_generic_expr' 7962 Output generic expression. 7963'dump_gimple_stmt' 7964 Output gimple statement. 7965 7966 Note that the above methods also have variants prefixed with 7967 '_loc', such as 'dump_printf_loc', which are similar except they 7968 also output the source location information. 7969 7970 7971File: gccint.info, Node: Dump examples, Prev: Dump types, Up: Optimization info 7972 79739.6.6 Dump examples 7974------------------- 7975 7976 gcc -O3 -fopt-info-missed=missed.all 7977 7978 outputs missed optimization report from all the passes into 7979'missed.all'. 7980 7981 As another example, 7982 gcc -O3 -fopt-info-inline-optimized-missed=inline.txt 7983 7984 will output information about missed optimizations as well as optimized 7985locations from all the inlining passes into 'inline.txt'. 7986 7987 If the FILENAME is provided, then the dumps from all the applicable 7988optimizations are concatenated into the 'filename'. Otherwise the dump 7989is output onto 'stderr'. If OPTIONS is omitted, it defaults to 7990'optimized-optall', which means dump all information about successful 7991optimizations from all the passes. In the following example, the 7992optimization information is output on to 'stderr'. 7993 7994 gcc -O3 -fopt-info 7995 7996 Note that '-fopt-info-vec-missed' behaves the same as 7997'-fopt-info-missed-vec'. The order of the optimization group names and 7998message types listed after '-fopt-info' does not matter. 7999 8000 As another example, consider 8001 8002 gcc -fopt-info-vec-missed=vec.miss -fopt-info-loop-optimized=loop.opt 8003 8004 Here the two output file names 'vec.miss' and 'loop.opt' are in 8005conflict since only one output file is allowed. In this case, only the 8006first option takes effect and the subsequent options are ignored. Thus 8007only the 'vec.miss' is produced which containts dumps from the 8008vectorizer about missed opportunities. 8009 8010 8011File: gccint.info, Node: poly_int, Next: GENERIC, Prev: Passes, Up: Top 8012 801310 Sizes and offsets as runtime invariants 8014****************************************** 8015 8016GCC allows the size of a hardware register to be a runtime invariant 8017rather than a compile-time constant. This in turn means that various 8018sizes and offsets must also be runtime invariants rather than 8019compile-time constants, such as: 8020 8021 * the size of a general 'machine_mode' (*note Machine Modes::); 8022 8023 * the size of a spill slot; 8024 8025 * the offset of something within a stack frame; 8026 8027 * the number of elements in a vector; 8028 8029 * the size and offset of a 'mem' rtx (*note Regs and Memory::); and 8030 8031 * the byte offset in a 'subreg' rtx (*note Regs and Memory::). 8032 8033 The motivating example is the Arm SVE ISA, whose vector registers can 8034be any multiple of 128 bits between 128 and 2048 inclusive. The 8035compiler normally produces code that works for all SVE register sizes, 8036with the actual size only being known at runtime. 8037 8038 GCC's main representation of such runtime invariants is the 'poly_int' 8039class. This chapter describes what 'poly_int' does, lists the available 8040operations, and gives some general usage guidelines. 8041 8042* Menu: 8043 8044* Overview of poly_int:: 8045* Consequences of using poly_int:: 8046* Comparisons involving poly_int:: 8047* Arithmetic on poly_ints:: 8048* Alignment of poly_ints:: 8049* Computing bounds on poly_ints:: 8050* Converting poly_ints:: 8051* Miscellaneous poly_int routines:: 8052* Guidelines for using poly_int:: 8053 8054 8055File: gccint.info, Node: Overview of poly_int, Next: Consequences of using poly_int, Up: poly_int 8056 805710.1 Overview of 'poly_int' 8058=========================== 8059 8060We define indeterminates X1, ..., XN whose values are only known at 8061runtime and use polynomials of the form: 8062 8063 C0 + C1 * X1 + ... + CN * XN 8064 8065 to represent a size or offset whose value might depend on some of these 8066indeterminates. The coefficients C0, ..., CN are always known at 8067compile time, with the C0 term being the "constant" part that does not 8068depend on any runtime value. 8069 8070 GCC uses the 'poly_int' class to represent these coefficients. The 8071class has two template parameters: the first specifies the number of 8072coefficients (N + 1) and the second specifies the type of the 8073coefficients. For example, 'poly_int<2, unsigned short>' represents a 8074polynomial with two coefficients (and thus one indeterminate), with each 8075coefficient having type 'unsigned short'. When N is 0, the class 8076degenerates to a single compile-time constant C0. 8077 8078 The number of coefficients needed for compilation is a fixed property 8079of each target and is specified by the configuration macro 8080'NUM_POLY_INT_COEFFS'. The default value is 1, since most targets do 8081not have such runtime invariants. Targets that need a different value 8082should '#define' the macro in their 'CPU-modes.def' file. *Note Back 8083End::. 8084 8085 'poly_int' makes the simplifying requirement that each indeterminate 8086must be a nonnegative integer. An indeterminate value of 0 should 8087usually represent the minimum possible runtime value, with C0 specifying 8088the value in that case. 8089 8090 For example, when targetting the Arm SVE ISA, the single indeterminate 8091represents the number of 128-bit blocks in a vector _beyond the minimum 8092length of 128 bits_. Thus the number of 64-bit doublewords in a vector 8093is 2 + 2 * X1. If an aggregate has a single SVE vector and 16 8094additional bytes, its total size is 32 + 16 * X1 bytes. 8095 8096 The header file 'poly-int-types.h' provides typedefs for the most 8097common forms of 'poly_int', all having 'NUM_POLY_INT_COEFFS' 8098coefficients: 8099 8100'poly_uint16' 8101 a 'poly_int' with 'unsigned short' coefficients. 8102 8103'poly_int64' 8104 a 'poly_int' with 'HOST_WIDE_INT' coefficients. 8105 8106'poly_uint64' 8107 a 'poly_int' with 'unsigned HOST_WIDE_INT' coefficients. 8108 8109'poly_offset_int' 8110 a 'poly_int' with 'offset_int' coefficients. 8111 8112'poly_wide_int' 8113 a 'poly_int' with 'wide_int' coefficients. 8114 8115'poly_widest_int' 8116 a 'poly_int' with 'widest_int' coefficients. 8117 8118 Since the main purpose of 'poly_int' is to represent sizes and offsets, 8119the last two typedefs are only rarely used. 8120 8121 8122File: gccint.info, Node: Consequences of using poly_int, Next: Comparisons involving poly_int, Prev: Overview of poly_int, Up: poly_int 8123 812410.2 Consequences of using 'poly_int' 8125===================================== 8126 8127The two main consequences of using polynomial sizes and offsets are 8128that: 8129 8130 * there is no total ordering between the values at compile time, and 8131 8132 * some operations might yield results that cannot be expressed as a 8133 'poly_int'. 8134 8135 For example, if X is a runtime invariant, we cannot tell at compile 8136time whether: 8137 8138 3 + 4X <= 1 + 5X 8139 8140 since the condition is false when X <= 1 and true when X >= 2. 8141 8142 Similarly, 'poly_int' cannot represent the result of: 8143 8144 (3 + 4X) * (1 + 5X) 8145 8146 since it cannot (and in practice does not need to) store powers greater 8147than one. It also cannot represent the result of: 8148 8149 (3 + 4X) / (1 + 5X) 8150 8151 The following sections describe how we deal with these restrictions. 8152 8153 As described earlier, a 'poly_int<1, T>' has no indeterminates and so 8154degenerates to a compile-time constant of type T. It would be possible 8155in that case to do all normal arithmetic on the T, and to compare the T 8156using the normal C++ operators. We deliberately prevent 8157target-independent code from doing this, since the compiler needs to 8158support other 'poly_int<N, T>' as well, regardless of the current 8159target's 'NUM_POLY_INT_COEFFS'. 8160 8161 However, it would be very artificial to force target-specific code to 8162follow these restrictions if the target has no runtime indeterminates. 8163There is therefore an implicit conversion from 'poly_int<1, T>' to T 8164when compiling target-specific translation units. 8165 8166 8167File: gccint.info, Node: Comparisons involving poly_int, Next: Arithmetic on poly_ints, Prev: Consequences of using poly_int, Up: poly_int 8168 816910.3 Comparisons involving 'poly_int' 8170===================================== 8171 8172In general we need to compare sizes and offsets in two situations: those 8173in which the values need to be ordered, and those in which the values 8174can be unordered. More loosely, the distinction is often between values 8175that have a definite link (usually because they refer to the same 8176underlying register or memory location) and values that have no definite 8177link. An example of the former is the relationship between the inner 8178and outer sizes of a subreg, where we must know at compile time whether 8179the subreg is paradoxical, partial, or complete. An example of the 8180latter is alias analysis: we might want to check whether two arbitrary 8181memory references overlap. 8182 8183 Referring back to the examples in the previous section, it makes sense 8184to ask whether a memory reference of size '3 + 4X' overlaps one of size 8185'1 + 5X', but it does not make sense to have a subreg in which the outer 8186mode has '3 + 4X' bytes and the inner mode has '1 + 5X' bytes (or vice 8187versa). Such subregs are always invalid and should trigger an internal 8188compiler error if formed. 8189 8190 The underlying operators are the same in both cases, but the 8191distinction affects how they are used. 8192 8193* Menu: 8194 8195* Comparison functions for poly_int:: 8196* Properties of the poly_int comparisons:: 8197* Comparing potentially-unordered poly_ints:: 8198* Comparing ordered poly_ints:: 8199* Checking for a poly_int marker value:: 8200* Range checks on poly_ints:: 8201* Sorting poly_ints:: 8202 8203 8204File: gccint.info, Node: Comparison functions for poly_int, Next: Properties of the poly_int comparisons, Up: Comparisons involving poly_int 8205 820610.3.1 Comparison functions for 'poly_int' 8207------------------------------------------ 8208 8209'poly_int' provides the following routines for checking whether a 8210particular condition "may be" (might be) true: 8211 8212 maybe_lt maybe_le maybe_eq maybe_ge maybe_gt 8213 maybe_ne 8214 8215 The functions have their natural meaning: 8216 8217'maybe_lt(A, B)' 8218 Return true if A might be less than B. 8219 8220'maybe_le(A, B)' 8221 Return true if A might be less than or equal to B. 8222 8223'maybe_eq(A, B)' 8224 Return true if A might be equal to B. 8225 8226'maybe_ne(A, B)' 8227 Return true if A might not be equal to B. 8228 8229'maybe_ge(A, B)' 8230 Return true if A might be greater than or equal to B. 8231 8232'maybe_gt(A, B)' 8233 Return true if A might be greater than B. 8234 8235 For readability, 'poly_int' also provides "known" inverses of these 8236functions: 8237 8238 known_lt (A, B) == !maybe_ge (A, B) 8239 known_le (A, B) == !maybe_gt (A, B) 8240 known_eq (A, B) == !maybe_ne (A, B) 8241 known_ge (A, B) == !maybe_lt (A, B) 8242 known_gt (A, B) == !maybe_le (A, B) 8243 known_ne (A, B) == !maybe_eq (A, B) 8244 8245 8246File: 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 8247 824810.3.2 Properties of the 'poly_int' comparisons 8249----------------------------------------------- 8250 8251All "maybe" relations except 'maybe_ne' are transitive, so for example: 8252 8253 maybe_lt (A, B) && maybe_lt (B, C) implies maybe_lt (A, C) 8254 8255 for all A, B and C. 'maybe_lt', 'maybe_gt' and 'maybe_ne' are 8256irreflexive, so for example: 8257 8258 !maybe_lt (A, A) 8259 8260 is true for all A. 'maybe_le', 'maybe_eq' and 'maybe_ge' are 8261reflexive, so for example: 8262 8263 maybe_le (A, A) 8264 8265 is true for all A. 'maybe_eq' and 'maybe_ne' are symmetric, so: 8266 8267 maybe_eq (A, B) == maybe_eq (B, A) 8268 maybe_ne (A, B) == maybe_ne (B, A) 8269 8270 for all A and B. In addition: 8271 8272 maybe_le (A, B) == maybe_lt (A, B) || maybe_eq (A, B) 8273 maybe_ge (A, B) == maybe_gt (A, B) || maybe_eq (A, B) 8274 maybe_lt (A, B) == maybe_gt (B, A) 8275 maybe_le (A, B) == maybe_ge (B, A) 8276 8277 However: 8278 8279 maybe_le (A, B) && maybe_le (B, A) does not imply !maybe_ne (A, B) [== known_eq (A, B)] 8280 maybe_ge (A, B) && maybe_ge (B, A) does not imply !maybe_ne (A, B) [== known_eq (A, B)] 8281 8282 One example is again 'A == 3 + 4X' and 'B == 1 + 5X', where 'maybe_le 8283(A, B)', 'maybe_ge (A, B)' and 'maybe_ne (A, B)' all hold. 'maybe_le' 8284and 'maybe_ge' are therefore not antisymetric and do not form a partial 8285order. 8286 8287 From the above, it follows that: 8288 8289 * All "known" relations except 'known_ne' are transitive. 8290 8291 * 'known_lt', 'known_ne' and 'known_gt' are irreflexive. 8292 8293 * 'known_le', 'known_eq' and 'known_ge' are reflexive. 8294 8295 Also: 8296 8297 known_lt (A, B) == known_gt (B, A) 8298 known_le (A, B) == known_ge (B, A) 8299 known_lt (A, B) implies !known_lt (B, A) [asymmetry] 8300 known_gt (A, B) implies !known_gt (B, A) 8301 known_le (A, B) && known_le (B, A) == known_eq (A, B) [== !maybe_ne (A, B)] 8302 known_ge (A, B) && known_ge (B, A) == known_eq (A, B) [== !maybe_ne (A, B)] 8303 8304 'known_le' and 'known_ge' are therefore antisymmetric and are partial 8305orders. However: 8306 8307 known_le (A, B) does not imply known_lt (A, B) || known_eq (A, B) 8308 known_ge (A, B) does not imply known_gt (A, B) || known_eq (A, B) 8309 8310 For example, 'known_le (4, 4 + 4X)' holds because the runtime 8311indeterminate X is a nonnegative integer, but neither 'known_lt (4, 4 + 83124X)' nor 'known_eq (4, 4 + 4X)' hold. 8313 8314 8315File: 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 8316 831710.3.3 Comparing potentially-unordered 'poly_int's 8318-------------------------------------------------- 8319 8320In cases where there is no definite link between two 'poly_int's, we can 8321usually make a conservatively-correct assumption. For example, the 8322conservative assumption for alias analysis is that two references 8323_might_ alias. 8324 8325 One way of checking whether [BEGIN1, END1) might overlap [BEGIN2, END2) 8326using the 'poly_int' comparisons is: 8327 8328 maybe_gt (END1, BEGIN2) && maybe_gt (END2, BEGIN1) 8329 8330 and another (equivalent) way is: 8331 8332 !(known_le (END1, BEGIN2) || known_le (END2, BEGIN1)) 8333 8334 However, in this particular example, it is better to use the range 8335helper functions instead. *Note Range checks on poly_ints::. 8336 8337 8338File: 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 8339 834010.3.4 Comparing ordered 'poly_int's 8341------------------------------------ 8342 8343In cases where there is a definite link between two 'poly_int's, such as 8344the outer and inner sizes of subregs, we usually require the sizes to be 8345ordered by the 'known_le' partial order. 'poly_int' provides the 8346following utility functions for ordered values: 8347 8348'ordered_p (A, B)' 8349 Return true if A and B are ordered by the 'known_le' partial order. 8350 8351'ordered_min (A, B)' 8352 Assert that A and B are ordered by 'known_le' and return the 8353 minimum of the two. When using this function, please add a comment 8354 explaining why the values are known to be ordered. 8355 8356'ordered_max (A, B)' 8357 Assert that A and B are ordered by 'known_le' and return the 8358 maximum of the two. When using this function, please add a comment 8359 explaining why the values are known to be ordered. 8360 8361 For example, if a subreg has an outer mode of size OUTER and an inner 8362mode of size INNER: 8363 8364 * the subreg is complete if known_eq (INNER, OUTER) 8365 8366 * otherwise, the subreg is paradoxical if known_le (INNER, OUTER) 8367 8368 * otherwise, the subreg is partial if known_le (OUTER, INNER) 8369 8370 * otherwise, the subreg is ill-formed 8371 8372 Thus the subreg is only valid if 'ordered_p (OUTER, INNER)' is true. 8373If this condition is already known to be true then: 8374 8375 * the subreg is complete if known_eq (INNER, OUTER) 8376 8377 * the subreg is paradoxical if maybe_lt (INNER, OUTER) 8378 8379 * the subreg is partial if maybe_lt (OUTER, INNER) 8380 8381 with the three conditions being mutually exclusive. 8382 8383 Code that checks whether a subreg is valid would therefore generally 8384check whether 'ordered_p' holds (in addition to whatever other checks 8385are required for subreg validity). Code that is dealing with existing 8386subregs can assert that 'ordered_p' holds and use either of the 8387classifications above. 8388 8389 8390File: 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 8391 839210.3.5 Checking for a 'poly_int' marker value 8393--------------------------------------------- 8394 8395It is sometimes useful to have a special "marker value" that is not 8396meant to be taken literally. For example, some code uses a size of -1 8397to represent an unknown size, rather than having to carry around a 8398separate boolean to say whether the size is known. 8399 8400 The best way of checking whether something is a marker value is 8401'known_eq'. Conversely the best way of checking whether something is 8402_not_ a marker value is 'maybe_ne'. 8403 8404 Thus in the size example just mentioned, 'known_eq (size, -1)' would 8405check for an unknown size and 'maybe_ne (size, -1)' would check for a 8406known size. 8407 8408 8409File: 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 8410 841110.3.6 Range checks on 'poly_int's 8412---------------------------------- 8413 8414As well as the core comparisons (*note Comparison functions for 8415poly_int::), 'poly_int' provides utilities for various kinds of range 8416check. In each case the range is represented by a start position and a 8417size rather than a start position and an end position; this is because 8418the former is used much more often than the latter in GCC. Also, the 8419sizes can be -1 (or all ones for unsigned sizes) to indicate a range 8420with a known start position but an unknown size. All other sizes must 8421be nonnegative. A range of size 0 does not contain anything or overlap 8422anything. 8423 8424'known_size_p (SIZE)' 8425 Return true if SIZE represents a known range size, false if it is 8426 -1 or all ones (for signed and unsigned types respectively). 8427 8428'ranges_maybe_overlap_p (POS1, SIZE1, POS2, SIZE2)' 8429 Return true if the range described by POS1 and SIZE1 _might_ 8430 overlap the range described by POS2 and SIZE2 (in other words, 8431 return true if we cannot prove that the ranges are disjoint). 8432 8433'ranges_known_overlap_p (POS1, SIZE1, POS2, SIZE2)' 8434 Return true if the range described by POS1 and SIZE1 is known to 8435 overlap the range described by POS2 and SIZE2. 8436 8437'known_subrange_p (POS1, SIZE1, POS2, SIZE2)' 8438 Return true if the range described by POS1 and SIZE1 is known to be 8439 contained in the range described by POS2 and SIZE2. 8440 8441'maybe_in_range_p (VALUE, POS, SIZE)' 8442 Return true if VALUE _might_ be in the range described by POS and 8443 SIZE (in other words, return true if we cannot prove that VALUE is 8444 outside that range). 8445 8446'known_in_range_p (VALUE, POS, SIZE)' 8447 Return true if VALUE is known to be in the range described by POS 8448 and SIZE. 8449 8450'endpoint_representable_p (POS, SIZE)' 8451 Return true if the range described by POS and SIZE is open-ended or 8452 if the endpoint (POS + SIZE) is representable in the same type as 8453 POS and SIZE. The function returns false if adding SIZE to POS 8454 makes conceptual sense but could overflow. 8455 8456 There is also a 'poly_int' version of the 'IN_RANGE_P' macro: 8457 8458'coeffs_in_range_p (X, LOWER, UPPER)' 8459 Return true if every coefficient of X is in the inclusive range 8460 [LOWER, UPPER]. This function can be useful when testing whether 8461 an operation would cause the values of coefficients to overflow. 8462 8463 Note that the function does not indicate whether X itself is in the 8464 given range. X can be either a constant or a 'poly_int'. 8465 8466 8467File: gccint.info, Node: Sorting poly_ints, Prev: Range checks on poly_ints, Up: Comparisons involving poly_int 8468 846910.3.7 Sorting 'poly_int's 8470-------------------------- 8471 8472'poly_int' provides the following routine for sorting: 8473 8474'compare_sizes_for_sort (A, B)' 8475 Compare A and B in reverse lexicographical order (that is, compare 8476 the highest-indexed coefficients first). This can be useful when 8477 sorting data structures, since it has the effect of separating 8478 constant and non-constant values. If all values are nonnegative, 8479 the constant values come first. 8480 8481 Note that the values do not necessarily end up in numerical order. 8482 For example, '1 + 1X' would come after '100' in the sort order, but 8483 may well be less than '100' at run time. 8484 8485 8486File: gccint.info, Node: Arithmetic on poly_ints, Next: Alignment of poly_ints, Prev: Comparisons involving poly_int, Up: poly_int 8487 848810.4 Arithmetic on 'poly_int's 8489============================== 8490 8491Addition, subtraction, negation and bit inversion all work normally for 8492'poly_int's. Multiplication by a constant multiplier and left shifting 8493by a constant shift amount also work normally. General multiplication 8494of two 'poly_int's is not supported and is not useful in practice. 8495 8496 Other operations are only conditionally supported: the operation might 8497succeed or might fail, depending on the inputs. 8498 8499 This section describes both types of operation. 8500 8501* Menu: 8502 8503* Using poly_int with C++ arithmetic operators:: 8504* wi arithmetic on poly_ints:: 8505* Division of poly_ints:: 8506* Other poly_int arithmetic:: 8507 8508 8509File: gccint.info, Node: Using poly_int with C++ arithmetic operators, Next: wi arithmetic on poly_ints, Up: Arithmetic on poly_ints 8510 851110.4.1 Using 'poly_int' with C++ arithmetic operators 8512----------------------------------------------------- 8513 8514The following C++ expressions are supported, where P1 and P2 are 8515'poly_int's and where C1 and C2 are scalars: 8516 8517 -P1 8518 ~P1 8519 8520 P1 + P2 8521 P1 + C2 8522 C1 + P2 8523 8524 P1 - P2 8525 P1 - C2 8526 C1 - P2 8527 8528 C1 * P2 8529 P1 * C2 8530 8531 P1 << C2 8532 8533 P1 += P2 8534 P1 += C2 8535 8536 P1 -= P2 8537 P1 -= C2 8538 8539 P1 *= C2 8540 P1 <<= C2 8541 8542 These arithmetic operations handle integer ranks in a similar way to 8543C++. The main difference is that every coefficient narrower than 8544'HOST_WIDE_INT' promotes to 'HOST_WIDE_INT', whereas in C++ everything 8545narrower than 'int' promotes to 'int'. For example: 8546 8547 poly_uint16 + int -> poly_int64 8548 unsigned int + poly_uint16 -> poly_int64 8549 poly_int64 + int -> poly_int64 8550 poly_int32 + poly_uint64 -> poly_uint64 8551 uint64 + poly_int64 -> poly_uint64 8552 poly_offset_int + int32 -> poly_offset_int 8553 offset_int + poly_uint16 -> poly_offset_int 8554 8555 In the first two examples, both coefficients are narrower than 8556'HOST_WIDE_INT', so the result has coefficients of type 'HOST_WIDE_INT'. 8557In the other examples, the coefficient with the highest rank "wins". 8558 8559 If one of the operands is 'wide_int' or 'poly_wide_int', the rules are 8560the same as for 'wide_int' arithmetic. 8561 8562 8563File: 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 8564 856510.4.2 'wi' arithmetic on 'poly_int's 8566------------------------------------- 8567 8568As well as the C++ operators, 'poly_int' supports the following 'wi' 8569routines: 8570 8571 wi::neg (P1, &OVERFLOW) 8572 8573 wi::add (P1, P2) 8574 wi::add (P1, C2) 8575 wi::add (C1, P1) 8576 wi::add (P1, P2, SIGN, &OVERFLOW) 8577 8578 wi::sub (P1, P2) 8579 wi::sub (P1, C2) 8580 wi::sub (C1, P1) 8581 wi::sub (P1, P2, SIGN, &OVERFLOW) 8582 8583 wi::mul (P1, C2) 8584 wi::mul (C1, P1) 8585 wi::mul (P1, C2, SIGN, &OVERFLOW) 8586 8587 wi::lshift (P1, C2) 8588 8589 These routines just check whether overflow occurs on any individual 8590coefficient; it is not possible to know at compile time whether the 8591final runtime value would overflow. 8592 8593 8594File: gccint.info, Node: Division of poly_ints, Next: Other poly_int arithmetic, Prev: wi arithmetic on poly_ints, Up: Arithmetic on poly_ints 8595 859610.4.3 Division of 'poly_int's 8597------------------------------ 8598 8599Division of 'poly_int's is possible for certain inputs. The functions 8600for division return true if the operation is possible and in most cases 8601return the results by pointer. The routines are: 8602 8603'multiple_p (A, B)' 8604'multiple_p (A, B, "IENT)' 8605 Return true if A is an exact multiple of B, storing the result in 8606 QUOTIENT if so. There are overloads for various combinations of 8607 polynomial and constant A, B and QUOTIENT. 8608 8609'constant_multiple_p (A, B)' 8610'constant_multiple_p (A, B, "IENT)' 8611 Like 'multiple_p', but also test whether the multiple is a 8612 compile-time constant. 8613 8614'can_div_trunc_p (A, B, "IENT)' 8615'can_div_trunc_p (A, B, "IENT, &REMAINDER)' 8616 Return true if we can calculate 'trunc (A / B)' at compile time, 8617 storing the result in QUOTIENT and REMAINDER if so. 8618 8619'can_div_away_from_zero_p (A, B, "IENT)' 8620 Return true if we can calculate 'A / B' at compile time, rounding 8621 away from zero. Store the result in QUOTIENT if so. 8622 8623 Note that this is true if and only if 'can_div_trunc_p' is true. 8624 The only difference is in the rounding of the result. 8625 8626 There is also an asserting form of division: 8627 8628'exact_div (A, B)' 8629 Assert that A is a multiple of B and return 'A / B'. The result is 8630 a 'poly_int' if A is a 'poly_int'. 8631 8632 8633File: gccint.info, Node: Other poly_int arithmetic, Prev: Division of poly_ints, Up: Arithmetic on poly_ints 8634 863510.4.4 Other 'poly_int' arithmetic 8636---------------------------------- 8637 8638There are tentative routines for other operations besides division: 8639 8640'can_ior_p (A, B, &RESULT)' 8641 Return true if we can calculate 'A | B' at compile time, storing 8642 the result in RESULT if so. 8643 8644 Also, ANDs with a value '(1 << Y) - 1' or its inverse can be treated as 8645alignment operations. *Note Alignment of poly_ints::. 8646 8647 In addition, the following miscellaneous routines are available: 8648 8649'coeff_gcd (A)' 8650 Return the greatest common divisor of all nonzero coefficients in 8651 A, or zero if A is known to be zero. 8652 8653'common_multiple (A, B)' 8654 Return a value that is a multiple of both A and B, where one value 8655 is a 'poly_int' and the other is a scalar. The result will be the 8656 least common multiple for some indeterminate values but not 8657 necessarily for all. 8658 8659'force_common_multiple (A, B)' 8660 Return a value that is a multiple of both 'poly_int' A and 8661 'poly_int' B, asserting that such a value exists. The result will 8662 be the least common multiple for some indeterminate values but not 8663 necessarily for all. 8664 8665 When using this routine, please add a comment explaining why the 8666 assertion is known to hold. 8667 8668 Please add any other operations that you find to be useful. 8669 8670 8671File: gccint.info, Node: Alignment of poly_ints, Next: Computing bounds on poly_ints, Prev: Arithmetic on poly_ints, Up: poly_int 8672 867310.5 Alignment of 'poly_int's 8674============================= 8675 8676'poly_int' provides various routines for aligning values and for 8677querying misalignments. In each case the alignment must be a power of 86782. 8679 8680'can_align_p (VALUE, ALIGN)' 8681 Return true if we can align VALUE up or down to the nearest 8682 multiple of ALIGN at compile time. The answer is the same for both 8683 directions. 8684 8685'can_align_down (VALUE, ALIGN, &ALIGNED)' 8686 Return true if 'can_align_p'; if so, set ALIGNED to the greatest 8687 aligned value that is less than or equal to VALUE. 8688 8689'can_align_up (VALUE, ALIGN, &ALIGNED)' 8690 Return true if 'can_align_p'; if so, set ALIGNED to the lowest 8691 aligned value that is greater than or equal to VALUE. 8692 8693'known_equal_after_align_down (A, B, ALIGN)' 8694 Return true if we can align A and B down to the nearest ALIGN 8695 boundary at compile time and if the two results are equal. 8696 8697'known_equal_after_align_up (A, B, ALIGN)' 8698 Return true if we can align A and B up to the nearest ALIGN 8699 boundary at compile time and if the two results are equal. 8700 8701'aligned_lower_bound (VALUE, ALIGN)' 8702 Return a result that is no greater than VALUE and that is aligned 8703 to ALIGN. The result will the closest aligned value for some 8704 indeterminate values but not necessarily for all. 8705 8706 For example, suppose we are allocating an object of SIZE bytes in a 8707 downward-growing stack whose current limit is given by LIMIT. If 8708 the object requires ALIGN bytes of alignment, the new stack limit 8709 is given by: 8710 8711 aligned_lower_bound (LIMIT - SIZE, ALIGN) 8712 8713'aligned_upper_bound (VALUE, ALIGN)' 8714 Likewise return a result that is no less than VALUE and that is 8715 aligned to ALIGN. This is the routine that would be used for 8716 upward-growing stacks in the scenario just described. 8717 8718'known_misalignment (VALUE, ALIGN, &MISALIGN)' 8719 Return true if we can calculate the misalignment of VALUE with 8720 respect to ALIGN at compile time, storing the result in MISALIGN if 8721 so. 8722 8723'known_alignment (VALUE)' 8724 Return the minimum alignment that VALUE is known to have (in other 8725 words, the largest alignment that can be guaranteed whatever the 8726 values of the indeterminates turn out to be). Return 0 if VALUE is 8727 known to be 0. 8728 8729'force_align_down (VALUE, ALIGN)' 8730 Assert that VALUE can be aligned down to ALIGN at compile time and 8731 return the result. When using this routine, please add a comment 8732 explaining why the assertion is known to hold. 8733 8734'force_align_up (VALUE, ALIGN)' 8735 Likewise, but aligning up. 8736 8737'force_align_down_and_div (VALUE, ALIGN)' 8738 Divide the result of 'force_align_down' by ALIGN. Again, please 8739 add a comment explaining why the assertion in 'force_align_down' is 8740 known to hold. 8741 8742'force_align_up_and_div (VALUE, ALIGN)' 8743 Likewise for 'force_align_up'. 8744 8745'force_get_misalignment (VALUE, ALIGN)' 8746 Assert that we can calculate the misalignment of VALUE with respect 8747 to ALIGN at compile time and return the misalignment. When using 8748 this function, please add a comment explaining why the assertion is 8749 known to hold. 8750 8751 8752File: gccint.info, Node: Computing bounds on poly_ints, Next: Converting poly_ints, Prev: Alignment of poly_ints, Up: poly_int 8753 875410.6 Computing bounds on 'poly_int's 8755==================================== 8756 8757'poly_int' also provides routines for calculating lower and upper 8758bounds: 8759 8760'constant_lower_bound (A)' 8761 Assert that A is nonnegative and return the smallest value it can 8762 have. 8763 8764'lower_bound (A, B)' 8765 Return a value that is always less than or equal to both A and B. 8766 It will be the greatest such value for some indeterminate values 8767 but necessarily for all. 8768 8769'upper_bound (A, B)' 8770 Return a value that is always greater than or equal to both A and 8771 B. It will be the least such value for some indeterminate values 8772 but necessarily for all. 8773 8774 8775File: gccint.info, Node: Converting poly_ints, Next: Miscellaneous poly_int routines, Prev: Computing bounds on poly_ints, Up: poly_int 8776 877710.7 Converting 'poly_int's 8778=========================== 8779 8780A 'poly_int<N, T>' can be constructed from up to N individual T 8781coefficients, with the remaining coefficients being implicitly zero. In 8782particular, this means that every 'poly_int<N, T>' can be constructed 8783from a single scalar T, or something compatible with T. 8784 8785 Also, a 'poly_int<N, T>' can be constructed from a 'poly_int<N, U>' if 8786T can be constructed from U. 8787 8788 The following functions provide other forms of conversion, or test 8789whether such a conversion would succeed. 8790 8791'VALUE.is_constant ()' 8792 Return true if 'poly_int' VALUE is a compile-time constant. 8793 8794'VALUE.is_constant (&C1)' 8795 Return true if 'poly_int' VALUE is a compile-time constant, storing 8796 it in C1 if so. C1 must be able to hold all constant values of 8797 VALUE without loss of precision. 8798 8799'VALUE.to_constant ()' 8800 Assert that VALUE is a compile-time constant and return its value. 8801 When using this function, please add a comment explaining why the 8802 condition is known to hold (for example, because an earlier phase 8803 of analysis rejected non-constants). 8804 8805'VALUE.to_shwi (&P2)' 8806 Return true if 'poly_int<N, T>' VALUE can be represented without 8807 loss of precision as a 'poly_int<N, 'HOST_WIDE_INT'>', storing it 8808 in that form in P2 if so. 8809 8810'VALUE.to_uhwi (&P2)' 8811 Return true if 'poly_int<N, T>' VALUE can be represented without 8812 loss of precision as a 'poly_int<N, 'unsigned HOST_WIDE_INT'>', 8813 storing it in that form in P2 if so. 8814 8815'VALUE.force_shwi ()' 8816 Forcibly convert each coefficient of 'poly_int<N, T>' VALUE to 8817 'HOST_WIDE_INT', truncating any that are out of range. Return the 8818 result as a 'poly_int<N, 'HOST_WIDE_INT'>'. 8819 8820'VALUE.force_uhwi ()' 8821 Forcibly convert each coefficient of 'poly_int<N, T>' VALUE to 8822 'unsigned HOST_WIDE_INT', truncating any that are out of range. 8823 Return the result as a 'poly_int<N, 'unsigned HOST_WIDE_INT'>'. 8824 8825'wi::shwi (VALUE, PRECISION)' 8826 Return a 'poly_int' with the same value as VALUE, but with the 8827 coefficients converted from 'HOST_WIDE_INT' to 'wide_int'. 8828 PRECISION specifies the precision of the 'wide_int' cofficients; if 8829 this is wider than a 'HOST_WIDE_INT', the coefficients of VALUE 8830 will be sign-extended to fit. 8831 8832'wi::uhwi (VALUE, PRECISION)' 8833 Like 'wi::shwi', except that VALUE has coefficients of type 8834 'unsigned HOST_WIDE_INT'. If PRECISION is wider than a 8835 'HOST_WIDE_INT', the coefficients of VALUE will be zero-extended to 8836 fit. 8837 8838'wi::sext (VALUE, PRECISION)' 8839 Return a 'poly_int' of the same type as VALUE, sign-extending every 8840 coefficient from the low PRECISION bits. This in effect applies 8841 'wi::sext' to each coefficient individually. 8842 8843'wi::zext (VALUE, PRECISION)' 8844 Like 'wi::sext', but for zero extension. 8845 8846'poly_wide_int::from (VALUE, PRECISION, SIGN)' 8847 Convert VALUE to a 'poly_wide_int' in which each coefficient has 8848 PRECISION bits. Extend the coefficients according to SIGN if the 8849 coefficients have fewer bits. 8850 8851'poly_offset_int::from (VALUE, SIGN)' 8852 Convert VALUE to a 'poly_offset_int', extending its coefficients 8853 according to SIGN if they have fewer bits than 'offset_int'. 8854 8855'poly_widest_int::from (VALUE, SIGN)' 8856 Convert VALUE to a 'poly_widest_int', extending its coefficients 8857 according to SIGN if they have fewer bits than 'widest_int'. 8858 8859 8860File: gccint.info, Node: Miscellaneous poly_int routines, Next: Guidelines for using poly_int, Prev: Converting poly_ints, Up: poly_int 8861 886210.8 Miscellaneous 'poly_int' routines 8863====================================== 8864 8865'print_dec (VALUE, FILE, SIGN)' 8866'print_dec (VALUE, FILE)' 8867 Print VALUE to FILE as a decimal value, interpreting the 8868 coefficients according to SIGN. The final argument is optional if 8869 VALUE has an inherent sign; for example, 'poly_int64' values print 8870 as signed by default and 'poly_uint64' values print as unsigned by 8871 default. 8872 8873 This is a simply a 'poly_int' version of a wide-int routine. 8874 8875 8876File: gccint.info, Node: Guidelines for using poly_int, Prev: Miscellaneous poly_int routines, Up: poly_int 8877 887810.9 Guidelines for using 'poly_int' 8879==================================== 8880 8881One of the main design goals of 'poly_int' was to make it easy to write 8882target-independent code that handles variable-sized registers even when 8883the current target has fixed-sized registers. There are two aspects to 8884this: 8885 8886 * The set of 'poly_int' operations should be complete enough that the 8887 question in most cases becomes "Can we do this operation on these 8888 particular 'poly_int' values? If not, bail out" rather than "Are 8889 these 'poly_int' values constant? If so, do the operation, 8890 otherwise bail out". 8891 8892 * If target-independent code compiles and runs correctly on a target 8893 with one value of 'NUM_POLY_INT_COEFFS', and if the code does not 8894 use asserting functions like 'to_constant', it is reasonable to 8895 assume that the code also works on targets with other values of 8896 'NUM_POLY_INT_COEFFS'. There is no need to check this during 8897 everyday development. 8898 8899 So the general principle is: if target-independent code is dealing with 8900a 'poly_int' value, it is better to operate on it as a 'poly_int' if at 8901all possible, choosing conservatively-correct behavior if a particular 8902operation fails. For example, the following code handles an index 'pos' 8903into a sequence of vectors that each have 'nunits' elements: 8904 8905 /* Calculate which vector contains the result, and which lane of 8906 that vector we need. */ 8907 if (!can_div_trunc_p (pos, nunits, &vec_entry, &vec_index)) 8908 { 8909 if (dump_enabled_p ()) 8910 dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location, 8911 "Cannot determine which vector holds the" 8912 " final result.\n"); 8913 return false; 8914 } 8915 8916 However, there are some contexts in which operating on a 'poly_int' is 8917not possible or does not make sense. One example is when handling 8918static initializers, since no current target supports the concept of a 8919variable-length static initializer. In these situations, a reasonable 8920fallback is: 8921 8922 if (POLY_VALUE.is_constant (&CONST_VALUE)) 8923 { 8924 ... 8925 /* Operate on CONST_VALUE. */ 8926 ... 8927 } 8928 else 8929 { 8930 ... 8931 /* Conservatively correct fallback. */ 8932 ... 8933 } 8934 8935 'poly_int' also provides some asserting functions like 'to_constant'. 8936Please only use these functions if there is a good theoretical reason to 8937believe that the assertion cannot fire. For example, if some work is 8938divided into an analysis phase and an implementation phase, the analysis 8939phase might reject inputs that are not 'is_constant', in which case the 8940implementation phase can reasonably use 'to_constant' on the remaining 8941inputs. The assertions should not be used to discover whether a 8942condition ever occurs "in the field"; in other words, they should not be 8943used to restrict code to constants at first, with the intention of only 8944implementing a 'poly_int' version if a user hits the assertion. 8945 8946 If a particular asserting function like 'to_constant' is needed more 8947than once for the same reason, it is probably worth adding a helper 8948function or macro for that situation, so that the justification only 8949needs to be given once. For example: 8950 8951 /* Return the size of an element in a vector of size SIZE, given that 8952 the vector has NELTS elements. The return value is in the same units 8953 as SIZE (either bits or bytes). 8954 8955 to_constant () is safe in this situation because vector elements are 8956 always constant-sized scalars. */ 8957 #define vector_element_size(SIZE, NELTS) \ 8958 (exact_div (SIZE, NELTS).to_constant ()) 8959 8960 Target-specific code in 'config/CPU' only needs to handle non-constant 8961'poly_int's if 'NUM_POLY_INT_COEFFS' is greater than one. For other 8962targets, 'poly_int' degenerates to a compile-time constant and is often 8963interchangable with a normal scalar integer. There are two main 8964exceptions: 8965 8966 * Sometimes an explicit cast to an integer type might be needed, such 8967 as to resolve ambiguities in a '?:' expression, or when passing 8968 values through '...' to things like print functions. 8969 8970 * Target macros are included in target-independent code and so do not 8971 have access to the implicit conversion to a scalar integer. If 8972 this becomes a problem for a particular target macro, the possible 8973 solutions, in order of preference, are: 8974 8975 * Convert the target macro to a target hook (for all targets). 8976 8977 * Put the target's implementation of the target macro in its 8978 'CPU.c' file and call it from the target macro in the 'CPU.h' 8979 file. 8980 8981 * Add 'to_constant ()' calls where necessary. The previous 8982 option is preferable because it will help with any future 8983 conversion of the macro to a hook. 8984 8985 8986File: gccint.info, Node: GENERIC, Next: GIMPLE, Prev: poly_int, Up: Top 8987 898811 GENERIC 8989********** 8990 8991The purpose of GENERIC is simply to provide a language-independent way 8992of representing an entire function in trees. To this end, it was 8993necessary to add a few new tree codes to the back end, but almost 8994everything was already there. If you can express it with the codes in 8995'gcc/tree.def', it's GENERIC. 8996 8997 Early on, there was a great deal of debate about how to think about 8998statements in a tree IL. In GENERIC, a statement is defined as any 8999expression whose value, if any, is ignored. A statement will always 9000have 'TREE_SIDE_EFFECTS' set (or it will be discarded), but a 9001non-statement expression may also have side effects. A 'CALL_EXPR', for 9002instance. 9003 9004 It would be possible for some local optimizations to work on the 9005GENERIC form of a function; indeed, the adapted tree inliner works fine 9006on GENERIC, but the current compiler performs inlining after lowering to 9007GIMPLE (a restricted form described in the next section). Indeed, 9008currently the frontends perform this lowering before handing off to 9009'tree_rest_of_compilation', but this seems inelegant. 9010 9011* Menu: 9012 9013* Deficiencies:: Topics net yet covered in this document. 9014* Tree overview:: All about 'tree's. 9015* Types:: Fundamental and aggregate types. 9016* Declarations:: Type declarations and variables. 9017* Attributes:: Declaration and type attributes. 9018* Expressions: Expression trees. Operating on data. 9019* Statements:: Control flow and related trees. 9020* Functions:: Function bodies, linkage, and other aspects. 9021* Language-dependent trees:: Topics and trees specific to language front ends. 9022* C and C++ Trees:: Trees specific to C and C++. 9023* Java Trees:: Trees specific to Java. 9024 9025 9026File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: GENERIC 9027 902811.1 Deficiencies 9029================= 9030 9031There are many places in which this document is incomplet and incorrekt. 9032It is, as of yet, only _preliminary_ documentation. 9033 9034 9035File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: GENERIC 9036 903711.2 Overview 9038============= 9039 9040The central data structure used by the internal representation is the 9041'tree'. These nodes, while all of the C type 'tree', are of many 9042varieties. A 'tree' is a pointer type, but the object to which it 9043points may be of a variety of types. From this point forward, we will 9044refer to trees in ordinary type, rather than in 'this font', except when 9045talking about the actual C type 'tree'. 9046 9047 You can tell what kind of node a particular tree is by using the 9048'TREE_CODE' macro. Many, many macros take trees as input and return 9049trees as output. However, most macros require a certain kind of tree 9050node as input. In other words, there is a type-system for trees, but it 9051is not reflected in the C type-system. 9052 9053 For safety, it is useful to configure GCC with '--enable-checking'. 9054Although this results in a significant performance penalty (since all 9055tree types are checked at run-time), and is therefore inappropriate in a 9056release version, it is extremely helpful during the development process. 9057 9058 Many macros behave as predicates. Many, although not all, of these 9059predicates end in '_P'. Do not rely on the result type of these macros 9060being of any particular type. You may, however, rely on the fact that 9061the type can be compared to '0', so that statements like 9062 if (TEST_P (t) && !TEST_P (y)) 9063 x = 1; 9064and 9065 int i = (TEST_P (t) != 0); 9066are legal. Macros that return 'int' values now may be changed to return 9067'tree' values, or other pointers in the future. Even those that 9068continue to return 'int' may return multiple nonzero codes where 9069previously they returned only zero and one. Therefore, you should not 9070write code like 9071 if (TEST_P (t) == 1) 9072as this code is not guaranteed to work correctly in the future. 9073 9074 You should not take the address of values returned by the macros or 9075functions described here. In particular, no guarantee is given that the 9076values are lvalues. 9077 9078 In general, the names of macros are all in uppercase, while the names 9079of functions are entirely in lowercase. There are rare exceptions to 9080this rule. You should assume that any macro or function whose name is 9081made up entirely of uppercase letters may evaluate its arguments more 9082than once. You may assume that a macro or function whose name is made 9083up entirely of lowercase letters will evaluate its arguments only once. 9084 9085 The 'error_mark_node' is a special tree. Its tree code is 9086'ERROR_MARK', but since there is only ever one node with that code, the 9087usual practice is to compare the tree against 'error_mark_node'. (This 9088test is just a test for pointer equality.) If an error has occurred 9089during front-end processing the flag 'errorcount' will be set. If the 9090front end has encountered code it cannot handle, it will issue a message 9091to the user and set 'sorrycount'. When these flags are set, any macro 9092or function which normally returns a tree of a particular kind may 9093instead return the 'error_mark_node'. Thus, if you intend to do any 9094processing of erroneous code, you must be prepared to deal with the 9095'error_mark_node'. 9096 9097 Occasionally, a particular tree slot (like an operand to an expression, 9098or a particular field in a declaration) will be referred to as "reserved 9099for the back end". These slots are used to store RTL when the tree is 9100converted to RTL for use by the GCC back end. However, if that process 9101is not taking place (e.g., if the front end is being hooked up to an 9102intelligent editor), then those slots may be used by the back end 9103presently in use. 9104 9105 If you encounter situations that do not match this documentation, such 9106as tree nodes of types not mentioned here, or macros documented to 9107return entities of a particular kind that instead return entities of 9108some different kind, you have found a bug, either in the front end or in 9109the documentation. Please report these bugs as you would any other bug. 9110 9111* Menu: 9112 9113* Macros and Functions::Macros and functions that can be used with all trees. 9114* Identifiers:: The names of things. 9115* Containers:: Lists and vectors. 9116 9117 9118File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview 9119 912011.2.1 Trees 9121------------ 9122 9123All GENERIC trees have two fields in common. First, 'TREE_CHAIN' is a 9124pointer that can be used as a singly-linked list to other trees. The 9125other is 'TREE_TYPE'. Many trees store the type of an expression or 9126declaration in this field. 9127 9128 These are some other functions for handling trees: 9129 9130'tree_size' 9131 Return the number of bytes a tree takes. 9132 9133'build0' 9134'build1' 9135'build2' 9136'build3' 9137'build4' 9138'build5' 9139'build6' 9140 9141 These functions build a tree and supply values to put in each 9142 parameter. The basic signature is 'code, type, [operands]'. 9143 'code' is the 'TREE_CODE', and 'type' is a tree representing the 9144 'TREE_TYPE'. These are followed by the operands, each of which is 9145 also a tree. 9146 9147 9148File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview 9149 915011.2.2 Identifiers 9151------------------ 9152 9153An 'IDENTIFIER_NODE' represents a slightly more general concept than the 9154standard C or C++ concept of identifier. In particular, an 9155'IDENTIFIER_NODE' may contain a '$', or other extraordinary characters. 9156 9157 There are never two distinct 'IDENTIFIER_NODE's representing the same 9158identifier. Therefore, you may use pointer equality to compare 9159'IDENTIFIER_NODE's, rather than using a routine like 'strcmp'. Use 9160'get_identifier' to obtain the unique 'IDENTIFIER_NODE' for a supplied 9161string. 9162 9163 You can use the following macros to access identifiers: 9164'IDENTIFIER_POINTER' 9165 The string represented by the identifier, represented as a 'char*'. 9166 This string is always 'NUL'-terminated, and contains no embedded 9167 'NUL' characters. 9168 9169'IDENTIFIER_LENGTH' 9170 The length of the string returned by 'IDENTIFIER_POINTER', not 9171 including the trailing 'NUL'. This value of 'IDENTIFIER_LENGTH 9172 (x)' is always the same as 'strlen (IDENTIFIER_POINTER (x))'. 9173 9174'IDENTIFIER_OPNAME_P' 9175 This predicate holds if the identifier represents the name of an 9176 overloaded operator. In this case, you should not depend on the 9177 contents of either the 'IDENTIFIER_POINTER' or the 9178 'IDENTIFIER_LENGTH'. 9179 9180'IDENTIFIER_TYPENAME_P' 9181 This predicate holds if the identifier represents the name of a 9182 user-defined conversion operator. In this case, the 'TREE_TYPE' of 9183 the 'IDENTIFIER_NODE' holds the type to which the conversion 9184 operator converts. 9185 9186 9187File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview 9188 918911.2.3 Containers 9190----------------- 9191 9192Two common container data structures can be represented directly with 9193tree nodes. A 'TREE_LIST' is a singly linked list containing two trees 9194per node. These are the 'TREE_PURPOSE' and 'TREE_VALUE' of each node. 9195(Often, the 'TREE_PURPOSE' contains some kind of tag, or additional 9196information, while the 'TREE_VALUE' contains the majority of the 9197payload. In other cases, the 'TREE_PURPOSE' is simply 'NULL_TREE', 9198while in still others both the 'TREE_PURPOSE' and 'TREE_VALUE' are of 9199equal stature.) Given one 'TREE_LIST' node, the next node is found by 9200following the 'TREE_CHAIN'. If the 'TREE_CHAIN' is 'NULL_TREE', then 9201you have reached the end of the list. 9202 9203 A 'TREE_VEC' is a simple vector. The 'TREE_VEC_LENGTH' is an integer 9204(not a tree) giving the number of nodes in the vector. The nodes 9205themselves are accessed using the 'TREE_VEC_ELT' macro, which takes two 9206arguments. The first is the 'TREE_VEC' in question; the second is an 9207integer indicating which element in the vector is desired. The elements 9208are indexed from zero. 9209 9210 9211File: gccint.info, Node: Types, Next: Declarations, Prev: Tree overview, Up: GENERIC 9212 921311.3 Types 9214========== 9215 9216All types have corresponding tree nodes. However, you should not assume 9217that there is exactly one tree node corresponding to each type. There 9218are often multiple nodes corresponding to the same type. 9219 9220 For the most part, different kinds of types have different tree codes. 9221(For example, pointer types use a 'POINTER_TYPE' code while arrays use 9222an 'ARRAY_TYPE' code.) However, pointers to member functions use the 9223'RECORD_TYPE' code. Therefore, when writing a 'switch' statement that 9224depends on the code associated with a particular type, you should take 9225care to handle pointers to member functions under the 'RECORD_TYPE' case 9226label. 9227 9228 The following functions and macros deal with cv-qualification of types: 9229'TYPE_MAIN_VARIANT' 9230 This macro returns the unqualified version of a type. It may be 9231 applied to an unqualified type, but it is not always the identity 9232 function in that case. 9233 9234 A few other macros and functions are usable with all types: 9235'TYPE_SIZE' 9236 The number of bits required to represent the type, represented as 9237 an 'INTEGER_CST'. For an incomplete type, 'TYPE_SIZE' will be 9238 'NULL_TREE'. 9239 9240'TYPE_ALIGN' 9241 The alignment of the type, in bits, represented as an 'int'. 9242 9243'TYPE_NAME' 9244 This macro returns a declaration (in the form of a 'TYPE_DECL') for 9245 the type. (Note this macro does _not_ return an 'IDENTIFIER_NODE', 9246 as you might expect, given its name!) You can look at the 9247 'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the 9248 type. The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a 9249 built-in type, the result of a typedef, or a named class type. 9250 9251'TYPE_CANONICAL' 9252 This macro returns the "canonical" type for the given type node. 9253 Canonical types are used to improve performance in the C++ and 9254 Objective-C++ front ends by allowing efficient comparison between 9255 two type nodes in 'same_type_p': if the 'TYPE_CANONICAL' values of 9256 the types are equal, the types are equivalent; otherwise, the types 9257 are not equivalent. The notion of equivalence for canonical types 9258 is the same as the notion of type equivalence in the language 9259 itself. For instance, 9260 9261 When 'TYPE_CANONICAL' is 'NULL_TREE', there is no canonical type 9262 for the given type node. In this case, comparison between this 9263 type and any other type requires the compiler to perform a deep, 9264 "structural" comparison to see if the two type nodes have the same 9265 form and properties. 9266 9267 The canonical type for a node is always the most fundamental type 9268 in the equivalence class of types. For instance, 'int' is its own 9269 canonical type. A typedef 'I' of 'int' will have 'int' as its 9270 canonical type. Similarly, 'I*' and a typedef 'IP' (defined to 9271 'I*') will has 'int*' as their canonical type. When building a new 9272 type node, be sure to set 'TYPE_CANONICAL' to the appropriate 9273 canonical type. If the new type is a compound type (built from 9274 other types), and any of those other types require structural 9275 equality, use 'SET_TYPE_STRUCTURAL_EQUALITY' to ensure that the new 9276 type also requires structural equality. Finally, if for some 9277 reason you cannot guarantee that 'TYPE_CANONICAL' will point to the 9278 canonical type, use 'SET_TYPE_STRUCTURAL_EQUALITY' to make sure 9279 that the new type-and any type constructed based on it-requires 9280 structural equality. If you suspect that the canonical type system 9281 is miscomparing types, pass '--param verify-canonical-types=1' to 9282 the compiler or configure with '--enable-checking' to force the 9283 compiler to verify its canonical-type comparisons against the 9284 structural comparisons; the compiler will then print any warnings 9285 if the canonical types miscompare. 9286 9287'TYPE_STRUCTURAL_EQUALITY_P' 9288 This predicate holds when the node requires structural equality 9289 checks, e.g., when 'TYPE_CANONICAL' is 'NULL_TREE'. 9290 9291'SET_TYPE_STRUCTURAL_EQUALITY' 9292 This macro states that the type node it is given requires 9293 structural equality checks, e.g., it sets 'TYPE_CANONICAL' to 9294 'NULL_TREE'. 9295 9296'same_type_p' 9297 This predicate takes two types as input, and holds if they are the 9298 same type. For example, if one type is a 'typedef' for the other, 9299 or both are 'typedef's for the same type. This predicate also 9300 holds if the two trees given as input are simply copies of one 9301 another; i.e., there is no difference between them at the source 9302 level, but, for whatever reason, a duplicate has been made in the 9303 representation. You should never use '==' (pointer equality) to 9304 compare types; always use 'same_type_p' instead. 9305 9306 Detailed below are the various kinds of types, and the macros that can 9307be used to access them. Although other kinds of types are used 9308elsewhere in G++, the types described here are the only ones that you 9309will encounter while examining the intermediate representation. 9310 9311'VOID_TYPE' 9312 Used to represent the 'void' type. 9313 9314'INTEGER_TYPE' 9315 Used to represent the various integral types, including 'char', 9316 'short', 'int', 'long', and 'long long'. This code is not used for 9317 enumeration types, nor for the 'bool' type. The 'TYPE_PRECISION' 9318 is the number of bits used in the representation, represented as an 9319 'unsigned int'. (Note that in the general case this is not the 9320 same value as 'TYPE_SIZE'; suppose that there were a 24-bit integer 9321 type, but that alignment requirements for the ABI required 32-bit 9322 alignment. Then, 'TYPE_SIZE' would be an 'INTEGER_CST' for 32, 9323 while 'TYPE_PRECISION' would be 24.) The integer type is unsigned 9324 if 'TYPE_UNSIGNED' holds; otherwise, it is signed. 9325 9326 The 'TYPE_MIN_VALUE' is an 'INTEGER_CST' for the smallest integer 9327 that may be represented by this type. Similarly, the 9328 'TYPE_MAX_VALUE' is an 'INTEGER_CST' for the largest integer that 9329 may be represented by this type. 9330 9331'REAL_TYPE' 9332 Used to represent the 'float', 'double', and 'long double' types. 9333 The number of bits in the floating-point representation is given by 9334 'TYPE_PRECISION', as in the 'INTEGER_TYPE' case. 9335 9336'FIXED_POINT_TYPE' 9337 Used to represent the 'short _Fract', '_Fract', 'long _Fract', 9338 'long long _Fract', 'short _Accum', '_Accum', 'long _Accum', and 9339 'long long _Accum' types. The number of bits in the fixed-point 9340 representation is given by 'TYPE_PRECISION', as in the 9341 'INTEGER_TYPE' case. There may be padding bits, fractional bits 9342 and integral bits. The number of fractional bits is given by 9343 'TYPE_FBIT', and the number of integral bits is given by 9344 'TYPE_IBIT'. The fixed-point type is unsigned if 'TYPE_UNSIGNED' 9345 holds; otherwise, it is signed. The fixed-point type is saturating 9346 if 'TYPE_SATURATING' holds; otherwise, it is not saturating. 9347 9348'COMPLEX_TYPE' 9349 Used to represent GCC built-in '__complex__' data types. The 9350 'TREE_TYPE' is the type of the real and imaginary parts. 9351 9352'ENUMERAL_TYPE' 9353 Used to represent an enumeration type. The 'TYPE_PRECISION' gives 9354 (as an 'int'), the number of bits used to represent the type. If 9355 there are no negative enumeration constants, 'TYPE_UNSIGNED' will 9356 hold. The minimum and maximum enumeration constants may be 9357 obtained with 'TYPE_MIN_VALUE' and 'TYPE_MAX_VALUE', respectively; 9358 each of these macros returns an 'INTEGER_CST'. 9359 9360 The actual enumeration constants themselves may be obtained by 9361 looking at the 'TYPE_VALUES'. This macro will return a 9362 'TREE_LIST', containing the constants. The 'TREE_PURPOSE' of each 9363 node will be an 'IDENTIFIER_NODE' giving the name of the constant; 9364 the 'TREE_VALUE' will be an 'INTEGER_CST' giving the value assigned 9365 to that constant. These constants will appear in the order in 9366 which they were declared. The 'TREE_TYPE' of each of these 9367 constants will be the type of enumeration type itself. 9368 9369'BOOLEAN_TYPE' 9370 Used to represent the 'bool' type. 9371 9372'POINTER_TYPE' 9373 Used to represent pointer types, and pointer to data member types. 9374 The 'TREE_TYPE' gives the type to which this type points. 9375 9376'REFERENCE_TYPE' 9377 Used to represent reference types. The 'TREE_TYPE' gives the type 9378 to which this type refers. 9379 9380'FUNCTION_TYPE' 9381 Used to represent the type of non-member functions and of static 9382 member functions. The 'TREE_TYPE' gives the return type of the 9383 function. The 'TYPE_ARG_TYPES' are a 'TREE_LIST' of the argument 9384 types. The 'TREE_VALUE' of each node in this list is the type of 9385 the corresponding argument; the 'TREE_PURPOSE' is an expression for 9386 the default argument value, if any. If the last node in the list 9387 is 'void_list_node' (a 'TREE_LIST' node whose 'TREE_VALUE' is the 9388 'void_type_node'), then functions of this type do not take variable 9389 arguments. Otherwise, they do take a variable number of arguments. 9390 9391 Note that in C (but not in C++) a function declared like 'void f()' 9392 is an unprototyped function taking a variable number of arguments; 9393 the 'TYPE_ARG_TYPES' of such a function will be 'NULL'. 9394 9395'METHOD_TYPE' 9396 Used to represent the type of a non-static member function. Like a 9397 'FUNCTION_TYPE', the return type is given by the 'TREE_TYPE'. The 9398 type of '*this', i.e., the class of which functions of this type 9399 are a member, is given by the 'TYPE_METHOD_BASETYPE'. The 9400 'TYPE_ARG_TYPES' is the parameter list, as for a 'FUNCTION_TYPE', 9401 and includes the 'this' argument. 9402 9403'ARRAY_TYPE' 9404 Used to represent array types. The 'TREE_TYPE' gives the type of 9405 the elements in the array. If the array-bound is present in the 9406 type, the 'TYPE_DOMAIN' is an 'INTEGER_TYPE' whose 'TYPE_MIN_VALUE' 9407 and 'TYPE_MAX_VALUE' will be the lower and upper bounds of the 9408 array, respectively. The 'TYPE_MIN_VALUE' will always be an 9409 'INTEGER_CST' for zero, while the 'TYPE_MAX_VALUE' will be one less 9410 than the number of elements in the array, i.e., the highest value 9411 which may be used to index an element in the array. 9412 9413'RECORD_TYPE' 9414 Used to represent 'struct' and 'class' types, as well as pointers 9415 to member functions and similar constructs in other languages. 9416 'TYPE_FIELDS' contains the items contained in this type, each of 9417 which can be a 'FIELD_DECL', 'VAR_DECL', 'CONST_DECL', or 9418 'TYPE_DECL'. You may not make any assumptions about the ordering 9419 of the fields in the type or whether one or more of them overlap. 9420 9421'UNION_TYPE' 9422 Used to represent 'union' types. Similar to 'RECORD_TYPE' except 9423 that all 'FIELD_DECL' nodes in 'TYPE_FIELD' start at bit position 9424 zero. 9425 9426'QUAL_UNION_TYPE' 9427 Used to represent part of a variant record in Ada. Similar to 9428 'UNION_TYPE' except that each 'FIELD_DECL' has a 'DECL_QUALIFIER' 9429 field, which contains a boolean expression that indicates whether 9430 the field is present in the object. The type will only have one 9431 field, so each field's 'DECL_QUALIFIER' is only evaluated if none 9432 of the expressions in the previous fields in 'TYPE_FIELDS' are 9433 nonzero. Normally these expressions will reference a field in the 9434 outer object using a 'PLACEHOLDER_EXPR'. 9435 9436'LANG_TYPE' 9437 This node is used to represent a language-specific type. The front 9438 end must handle it. 9439 9440'OFFSET_TYPE' 9441 This node is used to represent a pointer-to-data member. For a 9442 data member 'X::m' the 'TYPE_OFFSET_BASETYPE' is 'X' and the 9443 'TREE_TYPE' is the type of 'm'. 9444 9445 There are variables whose values represent some of the basic types. 9446These include: 9447'void_type_node' 9448 A node for 'void'. 9449 9450'integer_type_node' 9451 A node for 'int'. 9452 9453'unsigned_type_node.' 9454 A node for 'unsigned int'. 9455 9456'char_type_node.' 9457 A node for 'char'. 9458It may sometimes be useful to compare one of these variables with a type 9459in hand, using 'same_type_p'. 9460 9461 9462File: gccint.info, Node: Declarations, Next: Attributes, Prev: Types, Up: GENERIC 9463 946411.4 Declarations 9465================= 9466 9467This section covers the various kinds of declarations that appear in the 9468internal representation, except for declarations of functions 9469(represented by 'FUNCTION_DECL' nodes), which are described in *note 9470Functions::. 9471 9472* Menu: 9473 9474* Working with declarations:: Macros and functions that work on 9475declarations. 9476* Internal structure:: How declaration nodes are represented. 9477 9478 9479File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations 9480 948111.4.1 Working with declarations 9482-------------------------------- 9483 9484Some macros can be used with any kind of declaration. These include: 9485'DECL_NAME' 9486 This macro returns an 'IDENTIFIER_NODE' giving the name of the 9487 entity. 9488 9489'TREE_TYPE' 9490 This macro returns the type of the entity declared. 9491 9492'EXPR_FILENAME' 9493 This macro returns the name of the file in which the entity was 9494 declared, as a 'char*'. For an entity declared implicitly by the 9495 compiler (like '__builtin_memcpy'), this will be the string 9496 '"<internal>"'. 9497 9498'EXPR_LINENO' 9499 This macro returns the line number at which the entity was 9500 declared, as an 'int'. 9501 9502'DECL_ARTIFICIAL' 9503 This predicate holds if the declaration was implicitly generated by 9504 the compiler. For example, this predicate will hold of an 9505 implicitly declared member function, or of the 'TYPE_DECL' 9506 implicitly generated for a class type. Recall that in C++ code 9507 like: 9508 struct S {}; 9509 is roughly equivalent to C code like: 9510 struct S {}; 9511 typedef struct S S; 9512 The implicitly generated 'typedef' declaration is represented by a 9513 'TYPE_DECL' for which 'DECL_ARTIFICIAL' holds. 9514 9515 The various kinds of declarations include: 9516'LABEL_DECL' 9517 These nodes are used to represent labels in function bodies. For 9518 more information, see *note Functions::. These nodes only appear 9519 in block scopes. 9520 9521'CONST_DECL' 9522 These nodes are used to represent enumeration constants. The value 9523 of the constant is given by 'DECL_INITIAL' which will be an 9524 'INTEGER_CST' with the same type as the 'TREE_TYPE' of the 9525 'CONST_DECL', i.e., an 'ENUMERAL_TYPE'. 9526 9527'RESULT_DECL' 9528 These nodes represent the value returned by a function. When a 9529 value is assigned to a 'RESULT_DECL', that indicates that the value 9530 should be returned, via bitwise copy, by the function. You can use 9531 'DECL_SIZE' and 'DECL_ALIGN' on a 'RESULT_DECL', just as with a 9532 'VAR_DECL'. 9533 9534'TYPE_DECL' 9535 These nodes represent 'typedef' declarations. The 'TREE_TYPE' is 9536 the type declared to have the name given by 'DECL_NAME'. In some 9537 cases, there is no associated name. 9538 9539'VAR_DECL' 9540 These nodes represent variables with namespace or block scope, as 9541 well as static data members. The 'DECL_SIZE' and 'DECL_ALIGN' are 9542 analogous to 'TYPE_SIZE' and 'TYPE_ALIGN'. For a declaration, you 9543 should always use the 'DECL_SIZE' and 'DECL_ALIGN' rather than the 9544 'TYPE_SIZE' and 'TYPE_ALIGN' given by the 'TREE_TYPE', since 9545 special attributes may have been applied to the variable to give it 9546 a particular size and alignment. You may use the predicates 9547 'DECL_THIS_STATIC' or 'DECL_THIS_EXTERN' to test whether the 9548 storage class specifiers 'static' or 'extern' were used to declare 9549 a variable. 9550 9551 If this variable is initialized (but does not require a 9552 constructor), the 'DECL_INITIAL' will be an expression for the 9553 initializer. The initializer should be evaluated, and a bitwise 9554 copy into the variable performed. If the 'DECL_INITIAL' is the 9555 'error_mark_node', there is an initializer, but it is given by an 9556 explicit statement later in the code; no bitwise copy is required. 9557 9558 GCC provides an extension that allows either automatic variables, 9559 or global variables, to be placed in particular registers. This 9560 extension is being used for a particular 'VAR_DECL' if 9561 'DECL_REGISTER' holds for the 'VAR_DECL', and if 9562 'DECL_ASSEMBLER_NAME' is not equal to 'DECL_NAME'. In that case, 9563 'DECL_ASSEMBLER_NAME' is the name of the register into which the 9564 variable will be placed. 9565 9566'PARM_DECL' 9567 Used to represent a parameter to a function. Treat these nodes 9568 similarly to 'VAR_DECL' nodes. These nodes only appear in the 9569 'DECL_ARGUMENTS' for a 'FUNCTION_DECL'. 9570 9571 The 'DECL_ARG_TYPE' for a 'PARM_DECL' is the type that will 9572 actually be used when a value is passed to this function. It may 9573 be a wider type than the 'TREE_TYPE' of the parameter; for example, 9574 the ordinary type might be 'short' while the 'DECL_ARG_TYPE' is 9575 'int'. 9576 9577'DEBUG_EXPR_DECL' 9578 Used to represent an anonymous debug-information temporary created 9579 to hold an expression as it is optimized away, so that its value 9580 can be referenced in debug bind statements. 9581 9582'FIELD_DECL' 9583 These nodes represent non-static data members. The 'DECL_SIZE' and 9584 'DECL_ALIGN' behave as for 'VAR_DECL' nodes. The position of the 9585 field within the parent record is specified by a combination of 9586 three attributes. 'DECL_FIELD_OFFSET' is the position, counting in 9587 bytes, of the 'DECL_OFFSET_ALIGN'-bit sized word containing the bit 9588 of the field closest to the beginning of the structure. 9589 'DECL_FIELD_BIT_OFFSET' is the bit offset of the first bit of the 9590 field within this word; this may be nonzero even for fields that 9591 are not bit-fields, since 'DECL_OFFSET_ALIGN' may be greater than 9592 the natural alignment of the field's type. 9593 9594 If 'DECL_C_BIT_FIELD' holds, this field is a bit-field. In a 9595 bit-field, 'DECL_BIT_FIELD_TYPE' also contains the type that was 9596 originally specified for it, while DECL_TYPE may be a modified type 9597 with lesser precision, according to the size of the bit field. 9598 9599'NAMESPACE_DECL' 9600 Namespaces provide a name hierarchy for other declarations. They 9601 appear in the 'DECL_CONTEXT' of other '_DECL' nodes. 9602 9603 9604File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations 9605 960611.4.2 Internal structure 9607------------------------- 9608 9609'DECL' nodes are represented internally as a hierarchy of structures. 9610 9611* Menu: 9612 9613* Current structure hierarchy:: The current DECL node structure 9614hierarchy. 9615* Adding new DECL node types:: How to add a new DECL node to a 9616frontend. 9617 9618 9619File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure 9620 962111.4.2.1 Current structure hierarchy 9622.................................... 9623 9624'struct tree_decl_minimal' 9625 This is the minimal structure to inherit from in order for common 9626 'DECL' macros to work. The fields it contains are a unique ID, 9627 source location, context, and name. 9628 9629'struct tree_decl_common' 9630 This structure inherits from 'struct tree_decl_minimal'. It 9631 contains fields that most 'DECL' nodes need, such as a field to 9632 store alignment, machine mode, size, and attributes. 9633 9634'struct tree_field_decl' 9635 This structure inherits from 'struct tree_decl_common'. It is used 9636 to represent 'FIELD_DECL'. 9637 9638'struct tree_label_decl' 9639 This structure inherits from 'struct tree_decl_common'. It is used 9640 to represent 'LABEL_DECL'. 9641 9642'struct tree_translation_unit_decl' 9643 This structure inherits from 'struct tree_decl_common'. It is used 9644 to represent 'TRANSLATION_UNIT_DECL'. 9645 9646'struct tree_decl_with_rtl' 9647 This structure inherits from 'struct tree_decl_common'. It 9648 contains a field to store the low-level RTL associated with a 9649 'DECL' node. 9650 9651'struct tree_result_decl' 9652 This structure inherits from 'struct tree_decl_with_rtl'. It is 9653 used to represent 'RESULT_DECL'. 9654 9655'struct tree_const_decl' 9656 This structure inherits from 'struct tree_decl_with_rtl'. It is 9657 used to represent 'CONST_DECL'. 9658 9659'struct tree_parm_decl' 9660 This structure inherits from 'struct tree_decl_with_rtl'. It is 9661 used to represent 'PARM_DECL'. 9662 9663'struct tree_decl_with_vis' 9664 This structure inherits from 'struct tree_decl_with_rtl'. It 9665 contains fields necessary to store visibility information, as well 9666 as a section name and assembler name. 9667 9668'struct tree_var_decl' 9669 This structure inherits from 'struct tree_decl_with_vis'. It is 9670 used to represent 'VAR_DECL'. 9671 9672'struct tree_function_decl' 9673 This structure inherits from 'struct tree_decl_with_vis'. It is 9674 used to represent 'FUNCTION_DECL'. 9675 9676 9677File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure 9678 967911.4.2.2 Adding new DECL node types 9680................................... 9681 9682Adding a new 'DECL' tree consists of the following steps 9683 9684Add a new tree code for the 'DECL' node 9685 For language specific 'DECL' nodes, there is a '.def' file in each 9686 frontend directory where the tree code should be added. For 'DECL' 9687 nodes that are part of the middle-end, the code should be added to 9688 'tree.def'. 9689 9690Create a new structure type for the 'DECL' node 9691 These structures should inherit from one of the existing structures 9692 in the language hierarchy by using that structure as the first 9693 member. 9694 9695 struct tree_foo_decl 9696 { 9697 struct tree_decl_with_vis common; 9698 } 9699 9700 Would create a structure name 'tree_foo_decl' that inherits from 9701 'struct tree_decl_with_vis'. 9702 9703 For language specific 'DECL' nodes, this new structure type should 9704 go in the appropriate '.h' file. For 'DECL' nodes that are part of 9705 the middle-end, the structure type should go in 'tree.h'. 9706 9707Add a member to the tree structure enumerator for the node 9708 For garbage collection and dynamic checking purposes, each 'DECL' 9709 node structure type is required to have a unique enumerator value 9710 specified with it. For language specific 'DECL' nodes, this new 9711 enumerator value should go in the appropriate '.def' file. For 9712 'DECL' nodes that are part of the middle-end, the enumerator values 9713 are specified in 'treestruct.def'. 9714 9715Update 'union tree_node' 9716 In order to make your new structure type usable, it must be added 9717 to 'union tree_node'. For language specific 'DECL' nodes, a new 9718 entry should be added to the appropriate '.h' file of the form 9719 struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl; 9720 For 'DECL' nodes that are part of the middle-end, the additional 9721 member goes directly into 'union tree_node' in 'tree.h'. 9722 9723Update dynamic checking info 9724 In order to be able to check whether accessing a named portion of 9725 'union tree_node' is legal, and whether a certain 'DECL' node 9726 contains one of the enumerated 'DECL' node structures in the 9727 hierarchy, a simple lookup table is used. This lookup table needs 9728 to be kept up to date with the tree structure hierarchy, or else 9729 checking and containment macros will fail inappropriately. 9730 9731 For language specific 'DECL' nodes, their is an 'init_ts' function 9732 in an appropriate '.c' file, which initializes the lookup table. 9733 Code setting up the table for new 'DECL' nodes should be added 9734 there. For each 'DECL' tree code and enumerator value representing 9735 a member of the inheritance hierarchy, the table should contain 1 9736 if that tree code inherits (directly or indirectly) from that 9737 member. Thus, a 'FOO_DECL' node derived from 'struct 9738 decl_with_rtl', and enumerator value 'TS_FOO_DECL', would be set up 9739 as follows 9740 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1; 9741 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1; 9742 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1; 9743 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1; 9744 9745 For 'DECL' nodes that are part of the middle-end, the setup code 9746 goes into 'tree.c'. 9747 9748Add macros to access any new fields and flags 9749 9750 Each added field or flag should have a macro that is used to access 9751 it, that performs appropriate checking to ensure only the right 9752 type of 'DECL' nodes access the field. 9753 9754 These macros generally take the following form 9755 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname 9756 However, if the structure is simply a base class for further 9757 structures, something like the following should be used 9758 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT) 9759 #define BASE_STRUCT_FIELDNAME(NODE) \ 9760 (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname 9761 9762 Reading them from the generated 'all-tree.def' file (which in turn 9763 includes all the 'tree.def' files), 'gencheck.c' is used during 9764 GCC's build to generate the '*_CHECK' macros for all tree codes. 9765 9766 9767File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: GENERIC 9768 976911.5 Attributes in trees 9770======================== 9771 9772Attributes, as specified using the '__attribute__' keyword, are 9773represented internally as a 'TREE_LIST'. The 'TREE_PURPOSE' is the name 9774of the attribute, as an 'IDENTIFIER_NODE'. The 'TREE_VALUE' is a 9775'TREE_LIST' of the arguments of the attribute, if any, or 'NULL_TREE' if 9776there are no arguments; the arguments are stored as the 'TREE_VALUE' of 9777successive entries in the list, and may be identifiers or expressions. 9778The 'TREE_CHAIN' of the attribute is the next attribute in a list of 9779attributes applying to the same declaration or type, or 'NULL_TREE' if 9780there are no further attributes in the list. 9781 9782 Attributes may be attached to declarations and to types; these 9783attributes may be accessed with the following macros. All attributes 9784are stored in this way, and many also cause other changes to the 9785declaration or type or to other internal compiler data structures. 9786 9787 -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL) 9788 This macro returns the attributes on the declaration DECL. 9789 9790 -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE) 9791 This macro returns the attributes on the type TYPE. 9792 9793 9794File: gccint.info, Node: Expression trees, Next: Statements, Prev: Attributes, Up: GENERIC 9795 979611.6 Expressions 9797================ 9798 9799The internal representation for expressions is for the most part quite 9800straightforward. However, there are a few facts that one must bear in 9801mind. In particular, the expression "tree" is actually a directed 9802acyclic graph. (For example there may be many references to the integer 9803constant zero throughout the source program; many of these will be 9804represented by the same expression node.) You should not rely on 9805certain kinds of node being shared, nor should you rely on certain kinds 9806of nodes being unshared. 9807 9808 The following macros can be used with all expression nodes: 9809 9810'TREE_TYPE' 9811 Returns the type of the expression. This value may not be 9812 precisely the same type that would be given the expression in the 9813 original program. 9814 9815 In what follows, some nodes that one might expect to always have type 9816'bool' are documented to have either integral or boolean type. At some 9817point in the future, the C front end may also make use of this same 9818intermediate representation, and at this point these nodes will 9819certainly have integral type. The previous sentence is not meant to 9820imply that the C++ front end does not or will not give these nodes 9821integral type. 9822 9823 Below, we list the various kinds of expression nodes. Except where 9824noted otherwise, the operands to an expression are accessed using the 9825'TREE_OPERAND' macro. For example, to access the first operand to a 9826binary plus expression 'expr', use: 9827 9828 TREE_OPERAND (expr, 0) 9829 9830 As this example indicates, the operands are zero-indexed. 9831 9832* Menu: 9833 9834* Constants: Constant expressions. 9835* Storage References:: 9836* Unary and Binary Expressions:: 9837* Vectors:: 9838 9839 9840File: gccint.info, Node: Constant expressions, Next: Storage References, Up: Expression trees 9841 984211.6.1 Constant expressions 9843--------------------------- 9844 9845The table below begins with constants, moves on to unary expressions, 9846then proceeds to binary expressions, and concludes with various other 9847kinds of expressions: 9848 9849'INTEGER_CST' 9850 These nodes represent integer constants. Note that the type of 9851 these constants is obtained with 'TREE_TYPE'; they are not always 9852 of type 'int'. In particular, 'char' constants are represented 9853 with 'INTEGER_CST' nodes. The value of the integer constant 'e' is 9854 represented in an array of HOST_WIDE_INT. There are enough elements 9855 in the array to represent the value without taking extra elements 9856 for redundant 0s or -1. The number of elements used to represent 9857 'e' is available via 'TREE_INT_CST_NUNITS'. Element 'i' can be 9858 extracted by using 'TREE_INT_CST_ELT (e, i)'. 'TREE_INT_CST_LOW' 9859 is a shorthand for 'TREE_INT_CST_ELT (e, 0)'. 9860 9861 The functions 'tree_fits_shwi_p' and 'tree_fits_uhwi_p' can be used 9862 to tell if the value is small enough to fit in a signed 9863 HOST_WIDE_INT or an unsigned HOST_WIDE_INT respectively. The value 9864 can then be extracted using 'tree_to_shwi' and 'tree_to_uhwi'. 9865 9866'REAL_CST' 9867 9868 FIXME: Talk about how to obtain representations of this constant, 9869 do comparisons, and so forth. 9870 9871'FIXED_CST' 9872 9873 These nodes represent fixed-point constants. The type of these 9874 constants is obtained with 'TREE_TYPE'. 'TREE_FIXED_CST_PTR' 9875 points to a 'struct fixed_value'; 'TREE_FIXED_CST' returns the 9876 structure itself. 'struct fixed_value' contains 'data' with the 9877 size of two 'HOST_BITS_PER_WIDE_INT' and 'mode' as the associated 9878 fixed-point machine mode for 'data'. 9879 9880'COMPLEX_CST' 9881 These nodes are used to represent complex number constants, that is 9882 a '__complex__' whose parts are constant nodes. The 9883 'TREE_REALPART' and 'TREE_IMAGPART' return the real and the 9884 imaginary parts respectively. 9885 9886'VECTOR_CST' 9887 These nodes are used to represent vector constants. Each vector 9888 constant V is treated as a specific instance of an arbitrary-length 9889 sequence that itself contains 'VECTOR_CST_NPATTERNS (V)' 9890 interleaved patterns. Each pattern has the form: 9891 9892 { BASE0, BASE1, BASE1 + STEP, BASE1 + STEP * 2, ... } 9893 9894 The first three elements in each pattern are enough to determine 9895 the values of the other elements. However, if all STEPs are zero, 9896 only the first two elements are needed. If in addition each BASE1 9897 is equal to the corresponding BASE0, only the first element in each 9898 pattern is needed. The number of encoded elements per pattern is 9899 given by 'VECTOR_CST_NELTS_PER_PATTERN (V)'. 9900 9901 For example, the constant: 9902 9903 { 0, 1, 2, 6, 3, 8, 4, 10, 5, 12, 6, 14, 7, 16, 8, 18 } 9904 9905 is interpreted as an interleaving of the sequences: 9906 9907 { 0, 2, 3, 4, 5, 6, 7, 8 } 9908 { 1, 6, 8, 10, 12, 14, 16, 18 } 9909 9910 where the sequences are represented by the following patterns: 9911 9912 BASE0 == 0, BASE1 == 2, STEP == 1 9913 BASE0 == 1, BASE1 == 6, STEP == 2 9914 9915 In this case: 9916 9917 VECTOR_CST_NPATTERNS (V) == 2 9918 VECTOR_CST_NELTS_PER_PATTERN (V) == 3 9919 9920 The vector is therefore encoded using the first 6 elements ('{ 0, 9921 1, 2, 6, 3, 8 }'), with the remaining 10 elements being implicit 9922 extensions of them. 9923 9924 Sometimes this scheme can create two possible encodings of the same 9925 vector. For example { 0, 1 } could be seen as two patterns with 9926 one element each or one pattern with two elements (BASE0 and 9927 BASE1). The canonical encoding is always the one with the fewest 9928 patterns or (if both encodings have the same number of petterns) 9929 the one with the fewest encoded elements. 9930 9931 'vector_cst_encoding_nelts (V)' gives the total number of encoded 9932 elements in V, which is 6 in the example above. 9933 'VECTOR_CST_ENCODED_ELTS (V)' gives a pointer to the elements 9934 encoded in V and 'VECTOR_CST_ENCODED_ELT (V, I)' accesses the value 9935 of encoded element I. 9936 9937 'VECTOR_CST_DUPLICATE_P (V)' is true if V simply contains repeated 9938 instances of 'VECTOR_CST_NPATTERNS (V)' values. This is a 9939 shorthand for testing 'VECTOR_CST_NELTS_PER_PATTERN (V) == 1'. 9940 9941 'VECTOR_CST_STEPPED_P (V)' is true if at least one pattern in V has 9942 a nonzero step. This is a shorthand for testing 9943 'VECTOR_CST_NELTS_PER_PATTERN (V) == 3'. 9944 9945 The utility function 'vector_cst_elt' gives the value of an 9946 arbitrary index as a 'tree'. 'vector_cst_int_elt' gives the same 9947 value as a 'wide_int'. 9948 9949'STRING_CST' 9950 These nodes represent string-constants. The 'TREE_STRING_LENGTH' 9951 returns the length of the string, as an 'int'. The 9952 'TREE_STRING_POINTER' is a 'char*' containing the string itself. 9953 The string may not be 'NUL'-terminated, and it may contain embedded 9954 'NUL' characters. Therefore, the 'TREE_STRING_LENGTH' includes the 9955 trailing 'NUL' if it is present. 9956 9957 For wide string constants, the 'TREE_STRING_LENGTH' is the number 9958 of bytes in the string, and the 'TREE_STRING_POINTER' points to an 9959 array of the bytes of the string, as represented on the target 9960 system (that is, as integers in the target endianness). Wide and 9961 non-wide string constants are distinguished only by the 'TREE_TYPE' 9962 of the 'STRING_CST'. 9963 9964 FIXME: The formats of string constants are not well-defined when 9965 the target system bytes are not the same width as host system 9966 bytes. 9967 9968'POLY_INT_CST' 9969 These nodes represent invariants that depend on some 9970 target-specific runtime parameters. They consist of 9971 'NUM_POLY_INT_COEFFS' coefficients, with the first coefficient 9972 being the constant term and the others being multipliers that are 9973 applied to the runtime parameters. 9974 9975 'POLY_INT_CST_ELT (X, I)' references coefficient number I of 9976 'POLY_INT_CST' node X. Each coefficient is an 'INTEGER_CST'. 9977 9978 9979File: gccint.info, Node: Storage References, Next: Unary and Binary Expressions, Prev: Constant expressions, Up: Expression trees 9980 998111.6.2 References to storage 9982---------------------------- 9983 9984'ARRAY_REF' 9985 These nodes represent array accesses. The first operand is the 9986 array; the second is the index. To calculate the address of the 9987 memory accessed, you must scale the index by the size of the type 9988 of the array elements. The type of these expressions must be the 9989 type of a component of the array. The third and fourth operands 9990 are used after gimplification to represent the lower bound and 9991 component size but should not be used directly; call 9992 'array_ref_low_bound' and 'array_ref_element_size' instead. 9993 9994'ARRAY_RANGE_REF' 9995 These nodes represent access to a range (or "slice") of an array. 9996 The operands are the same as that for 'ARRAY_REF' and have the same 9997 meanings. The type of these expressions must be an array whose 9998 component type is the same as that of the first operand. The range 9999 of that array type determines the amount of data these expressions 10000 access. 10001 10002'TARGET_MEM_REF' 10003 These nodes represent memory accesses whose address directly map to 10004 an addressing mode of the target architecture. The first argument 10005 is 'TMR_SYMBOL' and must be a 'VAR_DECL' of an object with a fixed 10006 address. The second argument is 'TMR_BASE' and the third one is 10007 'TMR_INDEX'. The fourth argument is 'TMR_STEP' and must be an 10008 'INTEGER_CST'. The fifth argument is 'TMR_OFFSET' and must be an 10009 'INTEGER_CST'. Any of the arguments may be NULL if the appropriate 10010 component does not appear in the address. Address of the 10011 'TARGET_MEM_REF' is determined in the following way. 10012 10013 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET 10014 10015 The sixth argument is the reference to the original memory access, 10016 which is preserved for the purposes of the RTL alias analysis. The 10017 seventh argument is a tag representing the results of tree level 10018 alias analysis. 10019 10020'ADDR_EXPR' 10021 These nodes are used to represent the address of an object. (These 10022 expressions will always have pointer or reference type.) The 10023 operand may be another expression, or it may be a declaration. 10024 10025 As an extension, GCC allows users to take the address of a label. 10026 In this case, the operand of the 'ADDR_EXPR' will be a 10027 'LABEL_DECL'. The type of such an expression is 'void*'. 10028 10029 If the object addressed is not an lvalue, a temporary is created, 10030 and the address of the temporary is used. 10031 10032'INDIRECT_REF' 10033 These nodes are used to represent the object pointed to by a 10034 pointer. The operand is the pointer being dereferenced; it will 10035 always have pointer or reference type. 10036 10037'MEM_REF' 10038 These nodes are used to represent the object pointed to by a 10039 pointer offset by a constant. The first operand is the pointer 10040 being dereferenced; it will always have pointer or reference type. 10041 The second operand is a pointer constant. Its type is specifying 10042 the type to be used for type-based alias analysis. 10043 10044'COMPONENT_REF' 10045 These nodes represent non-static data member accesses. The first 10046 operand is the object (rather than a pointer to it); the second 10047 operand is the 'FIELD_DECL' for the data member. The third operand 10048 represents the byte offset of the field, but should not be used 10049 directly; call 'component_ref_field_offset' instead. 10050 10051 10052File: gccint.info, Node: Unary and Binary Expressions, Next: Vectors, Prev: Storage References, Up: Expression trees 10053 1005411.6.3 Unary and Binary Expressions 10055----------------------------------- 10056 10057'NEGATE_EXPR' 10058 These nodes represent unary negation of the single operand, for 10059 both integer and floating-point types. The type of negation can be 10060 determined by looking at the type of the expression. 10061 10062 The behavior of this operation on signed arithmetic overflow is 10063 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 10064 10065'ABS_EXPR' 10066 These nodes represent the absolute value of the single operand, for 10067 both integer and floating-point types. This is typically used to 10068 implement the 'abs', 'labs' and 'llabs' builtins for integer types, 10069 and the 'fabs', 'fabsf' and 'fabsl' builtins for floating point 10070 types. The type of abs operation can be determined by looking at 10071 the type of the expression. 10072 10073 This node is not used for complex types. To represent the modulus 10074 or complex abs of a complex value, use the 'BUILT_IN_CABS', 10075 'BUILT_IN_CABSF' or 'BUILT_IN_CABSL' builtins, as used to implement 10076 the C99 'cabs', 'cabsf' and 'cabsl' built-in functions. 10077 10078'BIT_NOT_EXPR' 10079 These nodes represent bitwise complement, and will always have 10080 integral type. The only operand is the value to be complemented. 10081 10082'TRUTH_NOT_EXPR' 10083 These nodes represent logical negation, and will always have 10084 integral (or boolean) type. The operand is the value being 10085 negated. The type of the operand and that of the result are always 10086 of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'. 10087 10088'PREDECREMENT_EXPR' 10089'PREINCREMENT_EXPR' 10090'POSTDECREMENT_EXPR' 10091'POSTINCREMENT_EXPR' 10092 These nodes represent increment and decrement expressions. The 10093 value of the single operand is computed, and the operand 10094 incremented or decremented. In the case of 'PREDECREMENT_EXPR' and 10095 'PREINCREMENT_EXPR', the value of the expression is the value 10096 resulting after the increment or decrement; in the case of 10097 'POSTDECREMENT_EXPR' and 'POSTINCREMENT_EXPR' is the value before 10098 the increment or decrement occurs. The type of the operand, like 10099 that of the result, will be either integral, boolean, or 10100 floating-point. 10101 10102'FIX_TRUNC_EXPR' 10103 These nodes represent conversion of a floating-point value to an 10104 integer. The single operand will have a floating-point type, while 10105 the complete expression will have an integral (or boolean) type. 10106 The operand is rounded towards zero. 10107 10108'FLOAT_EXPR' 10109 These nodes represent conversion of an integral (or boolean) value 10110 to a floating-point value. The single operand will have integral 10111 type, while the complete expression will have a floating-point 10112 type. 10113 10114 FIXME: How is the operand supposed to be rounded? Is this 10115 dependent on '-mieee'? 10116 10117'COMPLEX_EXPR' 10118 These nodes are used to represent complex numbers constructed from 10119 two expressions of the same (integer or real) type. The first 10120 operand is the real part and the second operand is the imaginary 10121 part. 10122 10123'CONJ_EXPR' 10124 These nodes represent the conjugate of their operand. 10125 10126'REALPART_EXPR' 10127'IMAGPART_EXPR' 10128 These nodes represent respectively the real and the imaginary parts 10129 of complex numbers (their sole argument). 10130 10131'NON_LVALUE_EXPR' 10132 These nodes indicate that their one and only operand is not an 10133 lvalue. A back end can treat these identically to the single 10134 operand. 10135 10136'NOP_EXPR' 10137 These nodes are used to represent conversions that do not require 10138 any code-generation. For example, conversion of a 'char*' to an 10139 'int*' does not require any code be generated; such a conversion is 10140 represented by a 'NOP_EXPR'. The single operand is the expression 10141 to be converted. The conversion from a pointer to a reference is 10142 also represented with a 'NOP_EXPR'. 10143 10144'CONVERT_EXPR' 10145 These nodes are similar to 'NOP_EXPR's, but are used in those 10146 situations where code may need to be generated. For example, if an 10147 'int*' is converted to an 'int' code may need to be generated on 10148 some platforms. These nodes are never used for C++-specific 10149 conversions, like conversions between pointers to different classes 10150 in an inheritance hierarchy. Any adjustments that need to be made 10151 in such cases are always indicated explicitly. Similarly, a 10152 user-defined conversion is never represented by a 'CONVERT_EXPR'; 10153 instead, the function calls are made explicit. 10154 10155'FIXED_CONVERT_EXPR' 10156 These nodes are used to represent conversions that involve 10157 fixed-point values. For example, from a fixed-point value to 10158 another fixed-point value, from an integer to a fixed-point value, 10159 from a fixed-point value to an integer, from a floating-point value 10160 to a fixed-point value, or from a fixed-point value to a 10161 floating-point value. 10162 10163'LSHIFT_EXPR' 10164'RSHIFT_EXPR' 10165 These nodes represent left and right shifts, respectively. The 10166 first operand is the value to shift; it will always be of integral 10167 type. The second operand is an expression for the number of bits 10168 by which to shift. Right shift should be treated as arithmetic, 10169 i.e., the high-order bits should be zero-filled when the expression 10170 has unsigned type and filled with the sign bit when the expression 10171 has signed type. Note that the result is undefined if the second 10172 operand is larger than or equal to the first operand's type size. 10173 Unlike most nodes, these can have a vector as first operand and a 10174 scalar as second operand. 10175 10176'BIT_IOR_EXPR' 10177'BIT_XOR_EXPR' 10178'BIT_AND_EXPR' 10179 These nodes represent bitwise inclusive or, bitwise exclusive or, 10180 and bitwise and, respectively. Both operands will always have 10181 integral type. 10182 10183'TRUTH_ANDIF_EXPR' 10184'TRUTH_ORIF_EXPR' 10185 These nodes represent logical "and" and logical "or", respectively. 10186 These operators are not strict; i.e., the second operand is 10187 evaluated only if the value of the expression is not determined by 10188 evaluation of the first operand. The type of the operands and that 10189 of the result are always of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'. 10190 10191'TRUTH_AND_EXPR' 10192'TRUTH_OR_EXPR' 10193'TRUTH_XOR_EXPR' 10194 These nodes represent logical and, logical or, and logical 10195 exclusive or. They are strict; both arguments are always 10196 evaluated. There are no corresponding operators in C or C++, but 10197 the front end will sometimes generate these expressions anyhow, if 10198 it can tell that strictness does not matter. The type of the 10199 operands and that of the result are always of 'BOOLEAN_TYPE' or 10200 'INTEGER_TYPE'. 10201 10202'POINTER_PLUS_EXPR' 10203 This node represents pointer arithmetic. The first operand is 10204 always a pointer/reference type. The second operand is always an 10205 unsigned integer type compatible with sizetype. This and 10206 POINTER_DIFF_EXPR are the only binary arithmetic operators that can 10207 operate on pointer types. 10208 10209'POINTER_DIFF_EXPR' 10210 This node represents pointer subtraction. The two operands always 10211 have pointer/reference type. It returns a signed integer of the 10212 same precision as the pointers. The behavior is undefined if the 10213 difference of the two pointers, seen as infinite precision 10214 non-negative integers, does not fit in the result type. The result 10215 does not depend on the pointer type, it is not divided by the size 10216 of the pointed-to type. 10217 10218'PLUS_EXPR' 10219'MINUS_EXPR' 10220'MULT_EXPR' 10221 These nodes represent various binary arithmetic operations. 10222 Respectively, these operations are addition, subtraction (of the 10223 second operand from the first) and multiplication. Their operands 10224 may have either integral or floating type, but there will never be 10225 case in which one operand is of floating type and the other is of 10226 integral type. 10227 10228 The behavior of these operations on signed arithmetic overflow is 10229 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 10230 10231'MULT_HIGHPART_EXPR' 10232 This node represents the "high-part" of a widening multiplication. 10233 For an integral type with B bits of precision, the result is the 10234 most significant B bits of the full 2B product. 10235 10236'RDIV_EXPR' 10237 This node represents a floating point division operation. 10238 10239'TRUNC_DIV_EXPR' 10240'FLOOR_DIV_EXPR' 10241'CEIL_DIV_EXPR' 10242'ROUND_DIV_EXPR' 10243 These nodes represent integer division operations that return an 10244 integer result. 'TRUNC_DIV_EXPR' rounds towards zero, 10245 'FLOOR_DIV_EXPR' rounds towards negative infinity, 'CEIL_DIV_EXPR' 10246 rounds towards positive infinity and 'ROUND_DIV_EXPR' rounds to the 10247 closest integer. Integer division in C and C++ is truncating, i.e. 10248 'TRUNC_DIV_EXPR'. 10249 10250 The behavior of these operations on signed arithmetic overflow, 10251 when dividing the minimum signed integer by minus one, is 10252 controlled by the 'flag_wrapv' and 'flag_trapv' variables. 10253 10254'TRUNC_MOD_EXPR' 10255'FLOOR_MOD_EXPR' 10256'CEIL_MOD_EXPR' 10257'ROUND_MOD_EXPR' 10258 These nodes represent the integer remainder or modulus operation. 10259 The integer modulus of two operands 'a' and 'b' is defined as 'a - 10260 (a/b)*b' where the division calculated using the corresponding 10261 division operator. Hence for 'TRUNC_MOD_EXPR' this definition 10262 assumes division using truncation towards zero, i.e. 10263 'TRUNC_DIV_EXPR'. Integer remainder in C and C++ uses truncating 10264 division, i.e. 'TRUNC_MOD_EXPR'. 10265 10266'EXACT_DIV_EXPR' 10267 The 'EXACT_DIV_EXPR' code is used to represent integer divisions 10268 where the numerator is known to be an exact multiple of the 10269 denominator. This allows the backend to choose between the faster 10270 of 'TRUNC_DIV_EXPR', 'CEIL_DIV_EXPR' and 'FLOOR_DIV_EXPR' for the 10271 current target. 10272 10273'LT_EXPR' 10274'LE_EXPR' 10275'GT_EXPR' 10276'GE_EXPR' 10277'EQ_EXPR' 10278'NE_EXPR' 10279 These nodes represent the less than, less than or equal to, greater 10280 than, greater than or equal to, equal, and not equal comparison 10281 operators. The first and second operands will either be both of 10282 integral type, both of floating type or both of vector type. The 10283 result type of these expressions will always be of integral, 10284 boolean or signed integral vector type. These operations return 10285 the result type's zero value for false, the result type's one value 10286 for true, and a vector whose elements are zero (false) or minus one 10287 (true) for vectors. 10288 10289 For floating point comparisons, if we honor IEEE NaNs and either 10290 operand is NaN, then 'NE_EXPR' always returns true and the 10291 remaining operators always return false. On some targets, 10292 comparisons against an IEEE NaN, other than equality and 10293 inequality, may generate a floating point exception. 10294 10295'ORDERED_EXPR' 10296'UNORDERED_EXPR' 10297 These nodes represent non-trapping ordered and unordered comparison 10298 operators. These operations take two floating point operands and 10299 determine whether they are ordered or unordered relative to each 10300 other. If either operand is an IEEE NaN, their comparison is 10301 defined to be unordered, otherwise the comparison is defined to be 10302 ordered. The result type of these expressions will always be of 10303 integral or boolean type. These operations return the result 10304 type's zero value for false, and the result type's one value for 10305 true. 10306 10307'UNLT_EXPR' 10308'UNLE_EXPR' 10309'UNGT_EXPR' 10310'UNGE_EXPR' 10311'UNEQ_EXPR' 10312'LTGT_EXPR' 10313 These nodes represent the unordered comparison operators. These 10314 operations take two floating point operands and determine whether 10315 the operands are unordered or are less than, less than or equal to, 10316 greater than, greater than or equal to, or equal respectively. For 10317 example, 'UNLT_EXPR' returns true if either operand is an IEEE NaN 10318 or the first operand is less than the second. With the possible 10319 exception of 'LTGT_EXPR', all of these operations are guaranteed 10320 not to generate a floating point exception. The result type of 10321 these expressions will always be of integral or boolean type. 10322 These operations return the result type's zero value for false, and 10323 the result type's one value for true. 10324 10325'MODIFY_EXPR' 10326 These nodes represent assignment. The left-hand side is the first 10327 operand; the right-hand side is the second operand. The left-hand 10328 side will be a 'VAR_DECL', 'INDIRECT_REF', 'COMPONENT_REF', or 10329 other lvalue. 10330 10331 These nodes are used to represent not only assignment with '=' but 10332 also compound assignments (like '+='), by reduction to '=' 10333 assignment. In other words, the representation for 'i += 3' looks 10334 just like that for 'i = i + 3'. 10335 10336'INIT_EXPR' 10337 These nodes are just like 'MODIFY_EXPR', but are used only when a 10338 variable is initialized, rather than assigned to subsequently. 10339 This means that we can assume that the target of the initialization 10340 is not used in computing its own value; any reference to the lhs in 10341 computing the rhs is undefined. 10342 10343'COMPOUND_EXPR' 10344 These nodes represent comma-expressions. The first operand is an 10345 expression whose value is computed and thrown away prior to the 10346 evaluation of the second operand. The value of the entire 10347 expression is the value of the second operand. 10348 10349'COND_EXPR' 10350 These nodes represent '?:' expressions. The first operand is of 10351 boolean or integral type. If it evaluates to a nonzero value, the 10352 second operand should be evaluated, and returned as the value of 10353 the expression. Otherwise, the third operand is evaluated, and 10354 returned as the value of the expression. 10355 10356 The second operand must have the same type as the entire 10357 expression, unless it unconditionally throws an exception or calls 10358 a noreturn function, in which case it should have void type. The 10359 same constraints apply to the third operand. This allows array 10360 bounds checks to be represented conveniently as '(i >= 0 && i < 10) 10361 ? i : abort()'. 10362 10363 As a GNU extension, the C language front-ends allow the second 10364 operand of the '?:' operator may be omitted in the source. For 10365 example, 'x ? : 3' is equivalent to 'x ? x : 3', assuming that 'x' 10366 is an expression without side effects. In the tree representation, 10367 however, the second operand is always present, possibly protected 10368 by 'SAVE_EXPR' if the first argument does cause side effects. 10369 10370'CALL_EXPR' 10371 These nodes are used to represent calls to functions, including 10372 non-static member functions. 'CALL_EXPR's are implemented as 10373 expression nodes with a variable number of operands. Rather than 10374 using 'TREE_OPERAND' to extract them, it is preferable to use the 10375 specialized accessor macros and functions that operate specifically 10376 on 'CALL_EXPR' nodes. 10377 10378 'CALL_EXPR_FN' returns a pointer to the function to call; it is 10379 always an expression whose type is a 'POINTER_TYPE'. 10380 10381 The number of arguments to the call is returned by 10382 'call_expr_nargs', while the arguments themselves can be accessed 10383 with the 'CALL_EXPR_ARG' macro. The arguments are zero-indexed and 10384 numbered left-to-right. You can iterate over the arguments using 10385 'FOR_EACH_CALL_EXPR_ARG', as in: 10386 10387 tree call, arg; 10388 call_expr_arg_iterator iter; 10389 FOR_EACH_CALL_EXPR_ARG (arg, iter, call) 10390 /* arg is bound to successive arguments of call. */ 10391 ...; 10392 10393 For non-static member functions, there will be an operand 10394 corresponding to the 'this' pointer. There will always be 10395 expressions corresponding to all of the arguments, even if the 10396 function is declared with default arguments and some arguments are 10397 not explicitly provided at the call sites. 10398 10399 'CALL_EXPR's also have a 'CALL_EXPR_STATIC_CHAIN' operand that is 10400 used to implement nested functions. This operand is otherwise 10401 null. 10402 10403'CLEANUP_POINT_EXPR' 10404 These nodes represent full-expressions. The single operand is an 10405 expression to evaluate. Any destructor calls engendered by the 10406 creation of temporaries during the evaluation of that expression 10407 should be performed immediately after the expression is evaluated. 10408 10409'CONSTRUCTOR' 10410 These nodes represent the brace-enclosed initializers for a 10411 structure or an array. They contain a sequence of component values 10412 made out of a vector of constructor_elt, which is a ('INDEX', 10413 'VALUE') pair. 10414 10415 If the 'TREE_TYPE' of the 'CONSTRUCTOR' is a 'RECORD_TYPE', 10416 'UNION_TYPE' or 'QUAL_UNION_TYPE' then the 'INDEX' of each node in 10417 the sequence will be a 'FIELD_DECL' and the 'VALUE' will be the 10418 expression used to initialize that field. 10419 10420 If the 'TREE_TYPE' of the 'CONSTRUCTOR' is an 'ARRAY_TYPE', then 10421 the 'INDEX' of each node in the sequence will be an 'INTEGER_CST' 10422 or a 'RANGE_EXPR' of two 'INTEGER_CST's. A single 'INTEGER_CST' 10423 indicates which element of the array is being assigned to. A 10424 'RANGE_EXPR' indicates an inclusive range of elements to 10425 initialize. In both cases the 'VALUE' is the corresponding 10426 initializer. It is re-evaluated for each element of a 10427 'RANGE_EXPR'. If the 'INDEX' is 'NULL_TREE', then the initializer 10428 is for the next available array element. 10429 10430 In the front end, you should not depend on the fields appearing in 10431 any particular order. However, in the middle end, fields must 10432 appear in declaration order. You should not assume that all fields 10433 will be represented. Unrepresented fields will be cleared 10434 (zeroed), unless the CONSTRUCTOR_NO_CLEARING flag is set, in which 10435 case their value becomes undefined. 10436 10437'COMPOUND_LITERAL_EXPR' 10438 These nodes represent ISO C99 compound literals. The 10439 'COMPOUND_LITERAL_EXPR_DECL_EXPR' is a 'DECL_EXPR' containing an 10440 anonymous 'VAR_DECL' for the unnamed object represented by the 10441 compound literal; the 'DECL_INITIAL' of that 'VAR_DECL' is a 10442 'CONSTRUCTOR' representing the brace-enclosed list of initializers 10443 in the compound literal. That anonymous 'VAR_DECL' can also be 10444 accessed directly by the 'COMPOUND_LITERAL_EXPR_DECL' macro. 10445 10446'SAVE_EXPR' 10447 10448 A 'SAVE_EXPR' represents an expression (possibly involving side 10449 effects) that is used more than once. The side effects should 10450 occur only the first time the expression is evaluated. Subsequent 10451 uses should just reuse the computed value. The first operand to 10452 the 'SAVE_EXPR' is the expression to evaluate. The side effects 10453 should be executed where the 'SAVE_EXPR' is first encountered in a 10454 depth-first preorder traversal of the expression tree. 10455 10456'TARGET_EXPR' 10457 A 'TARGET_EXPR' represents a temporary object. The first operand 10458 is a 'VAR_DECL' for the temporary variable. The second operand is 10459 the initializer for the temporary. The initializer is evaluated 10460 and, if non-void, copied (bitwise) into the temporary. If the 10461 initializer is void, that means that it will perform the 10462 initialization itself. 10463 10464 Often, a 'TARGET_EXPR' occurs on the right-hand side of an 10465 assignment, or as the second operand to a comma-expression which is 10466 itself the right-hand side of an assignment, etc. In this case, we 10467 say that the 'TARGET_EXPR' is "normal"; otherwise, we say it is 10468 "orphaned". For a normal 'TARGET_EXPR' the temporary variable 10469 should be treated as an alias for the left-hand side of the 10470 assignment, rather than as a new temporary variable. 10471 10472 The third operand to the 'TARGET_EXPR', if present, is a 10473 cleanup-expression (i.e., destructor call) for the temporary. If 10474 this expression is orphaned, then this expression must be executed 10475 when the statement containing this expression is complete. These 10476 cleanups must always be executed in the order opposite to that in 10477 which they were encountered. Note that if a temporary is created 10478 on one branch of a conditional operator (i.e., in the second or 10479 third operand to a 'COND_EXPR'), the cleanup must be run only if 10480 that branch is actually executed. 10481 10482'VA_ARG_EXPR' 10483 This node is used to implement support for the C/C++ variable 10484 argument-list mechanism. It represents expressions like 'va_arg 10485 (ap, type)'. Its 'TREE_TYPE' yields the tree representation for 10486 'type' and its sole argument yields the representation for 'ap'. 10487 10488'ANNOTATE_EXPR' 10489 This node is used to attach markers to an expression. The first 10490 operand is the annotated expression, the second is an 'INTEGER_CST' 10491 with a value from 'enum annot_expr_kind', the third is an 10492 'INTEGER_CST'. 10493 10494 10495File: gccint.info, Node: Vectors, Prev: Unary and Binary Expressions, Up: Expression trees 10496 1049711.6.4 Vectors 10498-------------- 10499 10500'VEC_DUPLICATE_EXPR' 10501 This node has a single operand and represents a vector in which 10502 every element is equal to that operand. 10503 10504'VEC_SERIES_EXPR' 10505 This node represents a vector formed from a scalar base and step, 10506 given as the first and second operands respectively. Element I of 10507 the result is equal to 'BASE + I*STEP'. 10508 10509 This node is restricted to integral types, in order to avoid 10510 specifying the rounding behavior for floating-point types. 10511 10512'VEC_LSHIFT_EXPR' 10513'VEC_RSHIFT_EXPR' 10514 These nodes represent whole vector left and right shifts, 10515 respectively. The first operand is the vector to shift; it will 10516 always be of vector type. The second operand is an expression for 10517 the number of bits by which to shift. Note that the result is 10518 undefined if the second operand is larger than or equal to the 10519 first operand's type size. 10520 10521'VEC_WIDEN_MULT_HI_EXPR' 10522'VEC_WIDEN_MULT_LO_EXPR' 10523 These nodes represent widening vector multiplication of the high 10524 and low parts of the two input vectors, respectively. Their 10525 operands are vectors that contain the same number of elements ('N') 10526 of the same integral type. The result is a vector that contains 10527 half as many elements, of an integral type whose size is twice as 10528 wide. In the case of 'VEC_WIDEN_MULT_HI_EXPR' the high 'N/2' 10529 elements of the two vector are multiplied to produce the vector of 10530 'N/2' products. In the case of 'VEC_WIDEN_MULT_LO_EXPR' the low 10531 'N/2' elements of the two vector are multiplied to produce the 10532 vector of 'N/2' products. 10533 10534'VEC_UNPACK_HI_EXPR' 10535'VEC_UNPACK_LO_EXPR' 10536 These nodes represent unpacking of the high and low parts of the 10537 input vector, respectively. The single operand is a vector that 10538 contains 'N' elements of the same integral or floating point type. 10539 The result is a vector that contains half as many elements, of an 10540 integral or floating point type whose size is twice as wide. In 10541 the case of 'VEC_UNPACK_HI_EXPR' the high 'N/2' elements of the 10542 vector are extracted and widened (promoted). In the case of 10543 'VEC_UNPACK_LO_EXPR' the low 'N/2' elements of the vector are 10544 extracted and widened (promoted). 10545 10546'VEC_UNPACK_FLOAT_HI_EXPR' 10547'VEC_UNPACK_FLOAT_LO_EXPR' 10548 These nodes represent unpacking of the high and low parts of the 10549 input vector, where the values are converted from fixed point to 10550 floating point. The single operand is a vector that contains 'N' 10551 elements of the same integral type. The result is a vector that 10552 contains half as many elements of a floating point type whose size 10553 is twice as wide. In the case of 'VEC_UNPACK_HI_EXPR' the high 10554 'N/2' elements of the vector are extracted, converted and widened. 10555 In the case of 'VEC_UNPACK_LO_EXPR' the low 'N/2' elements of the 10556 vector are extracted, converted and widened. 10557 10558'VEC_PACK_TRUNC_EXPR' 10559 This node represents packing of truncated elements of the two input 10560 vectors into the output vector. Input operands are vectors that 10561 contain the same number of elements of the same integral or 10562 floating point type. The result is a vector that contains twice as 10563 many elements of an integral or floating point type whose size is 10564 half as wide. The elements of the two vectors are demoted and 10565 merged (concatenated) to form the output vector. 10566 10567'VEC_PACK_SAT_EXPR' 10568 This node represents packing of elements of the two input vectors 10569 into the output vector using saturation. Input operands are 10570 vectors that contain the same number of elements of the same 10571 integral type. The result is a vector that contains twice as many 10572 elements of an integral type whose size is half as wide. The 10573 elements of the two vectors are demoted and merged (concatenated) 10574 to form the output vector. 10575 10576'VEC_PACK_FIX_TRUNC_EXPR' 10577 This node represents packing of elements of the two input vectors 10578 into the output vector, where the values are converted from 10579 floating point to fixed point. Input operands are vectors that 10580 contain the same number of elements of a floating point type. The 10581 result is a vector that contains twice as many elements of an 10582 integral type whose size is half as wide. The elements of the two 10583 vectors are merged (concatenated) to form the output vector. 10584 10585'VEC_COND_EXPR' 10586 These nodes represent '?:' expressions. The three operands must be 10587 vectors of the same size and number of elements. The second and 10588 third operands must have the same type as the entire expression. 10589 The first operand is of signed integral vector type. If an element 10590 of the first operand evaluates to a zero value, the corresponding 10591 element of the result is taken from the third operand. If it 10592 evaluates to a minus one value, it is taken from the second 10593 operand. It should never evaluate to any other value currently, 10594 but optimizations should not rely on that property. In contrast 10595 with a 'COND_EXPR', all operands are always evaluated. 10596 10597'SAD_EXPR' 10598 This node represents the Sum of Absolute Differences operation. 10599 The three operands must be vectors of integral types. The first 10600 and second operand must have the same type. The size of the vector 10601 element of the third operand must be at lease twice of the size of 10602 the vector element of the first and second one. The SAD is 10603 calculated between the first and second operands, added to the 10604 third operand, and returned. 10605 10606 10607File: gccint.info, Node: Statements, Next: Functions, Prev: Expression trees, Up: GENERIC 10608 1060911.7 Statements 10610=============== 10611 10612Most statements in GIMPLE are assignment statements, represented by 10613'GIMPLE_ASSIGN'. No other C expressions can appear at statement level; 10614a reference to a volatile object is converted into a 'GIMPLE_ASSIGN'. 10615 10616 There are also several varieties of complex statements. 10617 10618* Menu: 10619 10620* Basic Statements:: 10621* Blocks:: 10622* Statement Sequences:: 10623* Empty Statements:: 10624* Jumps:: 10625* Cleanups:: 10626* OpenMP:: 10627* OpenACC:: 10628 10629 10630File: gccint.info, Node: Basic Statements, Next: Blocks, Up: Statements 10631 1063211.7.1 Basic Statements 10633----------------------- 10634 10635'ASM_EXPR' 10636 10637 Used to represent an inline assembly statement. For an inline 10638 assembly statement like: 10639 asm ("mov x, y"); 10640 The 'ASM_STRING' macro will return a 'STRING_CST' node for '"mov x, 10641 y"'. If the original statement made use of the extended-assembly 10642 syntax, then 'ASM_OUTPUTS', 'ASM_INPUTS', and 'ASM_CLOBBERS' will 10643 be the outputs, inputs, and clobbers for the statement, represented 10644 as 'STRING_CST' nodes. The extended-assembly syntax looks like: 10645 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); 10646 The first string is the 'ASM_STRING', containing the instruction 10647 template. The next two strings are the output and inputs, 10648 respectively; this statement has no clobbers. As this example 10649 indicates, "plain" assembly statements are merely a special case of 10650 extended assembly statements; they have no cv-qualifiers, outputs, 10651 inputs, or clobbers. All of the strings will be 'NUL'-terminated, 10652 and will contain no embedded 'NUL'-characters. 10653 10654 If the assembly statement is declared 'volatile', or if the 10655 statement was not an extended assembly statement, and is therefore 10656 implicitly volatile, then the predicate 'ASM_VOLATILE_P' will hold 10657 of the 'ASM_EXPR'. 10658 10659'DECL_EXPR' 10660 10661 Used to represent a local declaration. The 'DECL_EXPR_DECL' macro 10662 can be used to obtain the entity declared. This declaration may be 10663 a 'LABEL_DECL', indicating that the label declared is a local 10664 label. (As an extension, GCC allows the declaration of labels with 10665 scope.) In C, this declaration may be a 'FUNCTION_DECL', 10666 indicating the use of the GCC nested function extension. For more 10667 information, *note Functions::. 10668 10669'LABEL_EXPR' 10670 10671 Used to represent a label. The 'LABEL_DECL' declared by this 10672 statement can be obtained with the 'LABEL_EXPR_LABEL' macro. The 10673 'IDENTIFIER_NODE' giving the name of the label can be obtained from 10674 the 'LABEL_DECL' with 'DECL_NAME'. 10675 10676'GOTO_EXPR' 10677 10678 Used to represent a 'goto' statement. The 'GOTO_DESTINATION' will 10679 usually be a 'LABEL_DECL'. However, if the "computed goto" 10680 extension has been used, the 'GOTO_DESTINATION' will be an 10681 arbitrary expression indicating the destination. This expression 10682 will always have pointer type. 10683 10684'RETURN_EXPR' 10685 10686 Used to represent a 'return' statement. Operand 0 represents the 10687 value to return. It should either be the 'RESULT_DECL' for the 10688 containing function, or a 'MODIFY_EXPR' or 'INIT_EXPR' setting the 10689 function's 'RESULT_DECL'. It will be 'NULL_TREE' if the statement 10690 was just 10691 return; 10692 10693'LOOP_EXPR' 10694 These nodes represent "infinite" loops. The 'LOOP_EXPR_BODY' 10695 represents the body of the loop. It should be executed forever, 10696 unless an 'EXIT_EXPR' is encountered. 10697 10698'EXIT_EXPR' 10699 These nodes represent conditional exits from the nearest enclosing 10700 'LOOP_EXPR'. The single operand is the condition; if it is 10701 nonzero, then the loop should be exited. An 'EXIT_EXPR' will only 10702 appear within a 'LOOP_EXPR'. 10703 10704'SWITCH_STMT' 10705 10706 Used to represent a 'switch' statement. The 'SWITCH_STMT_COND' is 10707 the expression on which the switch is occurring. See the 10708 documentation for an 'IF_STMT' for more information on the 10709 representation used for the condition. The 'SWITCH_STMT_BODY' is 10710 the body of the switch statement. The 'SWITCH_STMT_TYPE' is the 10711 original type of switch expression as given in the source, before 10712 any compiler conversions. 10713 10714'CASE_LABEL_EXPR' 10715 10716 Use to represent a 'case' label, range of 'case' labels, or a 10717 'default' label. If 'CASE_LOW' is 'NULL_TREE', then this is a 10718 'default' label. Otherwise, if 'CASE_HIGH' is 'NULL_TREE', then 10719 this is an ordinary 'case' label. In this case, 'CASE_LOW' is an 10720 expression giving the value of the label. Both 'CASE_LOW' and 10721 'CASE_HIGH' are 'INTEGER_CST' nodes. These values will have the 10722 same type as the condition expression in the switch statement. 10723 10724 Otherwise, if both 'CASE_LOW' and 'CASE_HIGH' are defined, the 10725 statement is a range of case labels. Such statements originate 10726 with the extension that allows users to write things of the form: 10727 case 2 ... 5: 10728 The first value will be 'CASE_LOW', while the second will be 10729 'CASE_HIGH'. 10730 10731'DEBUG_BEGIN_STMT' 10732 10733 Marks the beginning of a source statement, for purposes of debug 10734 information generation. 10735 10736 10737File: gccint.info, Node: Blocks, Next: Statement Sequences, Prev: Basic Statements, Up: Statements 10738 1073911.7.2 Blocks 10740------------- 10741 10742Block scopes and the variables they declare in GENERIC are expressed 10743using the 'BIND_EXPR' code, which in previous versions of GCC was 10744primarily used for the C statement-expression extension. 10745 10746 Variables in a block are collected into 'BIND_EXPR_VARS' in declaration 10747order through their 'TREE_CHAIN' field. Any runtime initialization is 10748moved out of 'DECL_INITIAL' and into a statement in the controlled 10749block. When gimplifying from C or C++, this initialization replaces the 10750'DECL_STMT'. These variables will never require cleanups. The scope of 10751these variables is just the body 10752 10753 Variable-length arrays (VLAs) complicate this process, as their size 10754often refers to variables initialized earlier in the block and their 10755initialization involves an explicit stack allocation. To handle this, 10756we add an indirection and replace them with a pointer to stack space 10757allocated by means of 'alloca'. In most cases, we also arrange for this 10758space to be reclaimed when the enclosing 'BIND_EXPR' is exited, the 10759exception to this being when there is an explicit call to 'alloca' in 10760the source code, in which case the stack is left depressed on exit of 10761the 'BIND_EXPR'. 10762 10763 A C++ program will usually contain more 'BIND_EXPR's than there are 10764syntactic blocks in the source code, since several C++ constructs have 10765implicit scopes associated with them. On the other hand, although the 10766C++ front end uses pseudo-scopes to handle cleanups for objects with 10767destructors, these don't translate into the GIMPLE form; multiple 10768declarations at the same level use the same 'BIND_EXPR'. 10769 10770 10771File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements 10772 1077311.7.3 Statement Sequences 10774-------------------------- 10775 10776Multiple statements at the same nesting level are collected into a 10777'STATEMENT_LIST'. Statement lists are modified and traversed using the 10778interface in 'tree-iterator.h'. 10779 10780 10781File: gccint.info, Node: Empty Statements, Next: Jumps, Prev: Statement Sequences, Up: Statements 10782 1078311.7.4 Empty Statements 10784----------------------- 10785 10786Whenever possible, statements with no effect are discarded. But if they 10787are nested within another construct which cannot be discarded for some 10788reason, they are instead replaced with an empty statement, generated by 10789'build_empty_stmt'. Initially, all empty statements were shared, after 10790the pattern of the Java front end, but this caused a lot of trouble in 10791practice. 10792 10793 An empty statement is represented as '(void)0'. 10794 10795 10796File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Empty Statements, Up: Statements 10797 1079811.7.5 Jumps 10799------------ 10800 10801Other jumps are expressed by either 'GOTO_EXPR' or 'RETURN_EXPR'. 10802 10803 The operand of a 'GOTO_EXPR' must be either a label or a variable 10804containing the address to jump to. 10805 10806 The operand of a 'RETURN_EXPR' is either 'NULL_TREE', 'RESULT_DECL', or 10807a 'MODIFY_EXPR' which sets the return value. It would be nice to move 10808the 'MODIFY_EXPR' into a separate statement, but the special return 10809semantics in 'expand_return' make that difficult. It may still happen 10810in the future, perhaps by moving most of that logic into 10811'expand_assignment'. 10812 10813 10814File: gccint.info, Node: Cleanups, Next: OpenMP, Prev: Jumps, Up: Statements 10815 1081611.7.6 Cleanups 10817--------------- 10818 10819Destructors for local C++ objects and similar dynamic cleanups are 10820represented in GIMPLE by a 'TRY_FINALLY_EXPR'. 'TRY_FINALLY_EXPR' has 10821two operands, both of which are a sequence of statements to execute. 10822The first sequence is executed. When it completes the second sequence 10823is executed. 10824 10825 The first sequence may complete in the following ways: 10826 10827 1. Execute the last statement in the sequence and fall off the end. 10828 10829 2. Execute a goto statement ('GOTO_EXPR') to an ordinary label outside 10830 the sequence. 10831 10832 3. Execute a return statement ('RETURN_EXPR'). 10833 10834 4. Throw an exception. This is currently not explicitly represented 10835 in GIMPLE. 10836 10837 The second sequence is not executed if the first sequence completes by 10838calling 'setjmp' or 'exit' or any other function that does not return. 10839The second sequence is also not executed if the first sequence completes 10840via a non-local goto or a computed goto (in general the compiler does 10841not know whether such a goto statement exits the first sequence or not, 10842so we assume that it doesn't). 10843 10844 After the second sequence is executed, if it completes normally by 10845falling off the end, execution continues wherever the first sequence 10846would have continued, by falling off the end, or doing a goto, etc. 10847 10848 'TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs 10849to appear on every edge out of the controlled block; this reduces the 10850freedom to move code across these edges. Therefore, the EH lowering 10851pass which runs before most of the optimization passes eliminates these 10852expressions by explicitly adding the cleanup to each edge. Rethrowing 10853the exception is represented using 'RESX_EXPR'. 10854 10855 10856File: gccint.info, Node: OpenMP, Next: OpenACC, Prev: Cleanups, Up: Statements 10857 1085811.7.7 OpenMP 10859------------- 10860 10861All the statements starting with 'OMP_' represent directives and clauses 10862used by the OpenMP API <http://www.openmp.org/>. 10863 10864'OMP_PARALLEL' 10865 10866 Represents '#pragma omp parallel [clause1 ... clauseN]'. It has 10867 four operands: 10868 10869 Operand 'OMP_PARALLEL_BODY' is valid while in GENERIC and High 10870 GIMPLE forms. It contains the body of code to be executed by all 10871 the threads. During GIMPLE lowering, this operand becomes 'NULL' 10872 and the body is emitted linearly after 'OMP_PARALLEL'. 10873 10874 Operand 'OMP_PARALLEL_CLAUSES' is the list of clauses associated 10875 with the directive. 10876 10877 Operand 'OMP_PARALLEL_FN' is created by 'pass_lower_omp', it 10878 contains the 'FUNCTION_DECL' for the function that will contain the 10879 body of the parallel region. 10880 10881 Operand 'OMP_PARALLEL_DATA_ARG' is also created by 10882 'pass_lower_omp'. If there are shared variables to be communicated 10883 to the children threads, this operand will contain the 'VAR_DECL' 10884 that contains all the shared values and variables. 10885 10886'OMP_FOR' 10887 10888 Represents '#pragma omp for [clause1 ... clauseN]'. It has six 10889 operands: 10890 10891 Operand 'OMP_FOR_BODY' contains the loop body. 10892 10893 Operand 'OMP_FOR_CLAUSES' is the list of clauses associated with 10894 the directive. 10895 10896 Operand 'OMP_FOR_INIT' is the loop initialization code of the form 10897 'VAR = N1'. 10898 10899 Operand 'OMP_FOR_COND' is the loop conditional expression of the 10900 form 'VAR {<,>,<=,>=} N2'. 10901 10902 Operand 'OMP_FOR_INCR' is the loop index increment of the form 'VAR 10903 {+=,-=} INCR'. 10904 10905 Operand 'OMP_FOR_PRE_BODY' contains side effect code from operands 10906 'OMP_FOR_INIT', 'OMP_FOR_COND' and 'OMP_FOR_INC'. These side 10907 effects are part of the 'OMP_FOR' block but must be evaluated 10908 before the start of loop body. 10909 10910 The loop index variable 'VAR' must be a signed integer variable, 10911 which is implicitly private to each thread. Bounds 'N1' and 'N2' 10912 and the increment expression 'INCR' are required to be loop 10913 invariant integer expressions that are evaluated without any 10914 synchronization. The evaluation order, frequency of evaluation and 10915 side effects are unspecified by the standard. 10916 10917'OMP_SECTIONS' 10918 10919 Represents '#pragma omp sections [clause1 ... clauseN]'. 10920 10921 Operand 'OMP_SECTIONS_BODY' contains the sections body, which in 10922 turn contains a set of 'OMP_SECTION' nodes for each of the 10923 concurrent sections delimited by '#pragma omp section'. 10924 10925 Operand 'OMP_SECTIONS_CLAUSES' is the list of clauses associated 10926 with the directive. 10927 10928'OMP_SECTION' 10929 10930 Section delimiter for 'OMP_SECTIONS'. 10931 10932'OMP_SINGLE' 10933 10934 Represents '#pragma omp single'. 10935 10936 Operand 'OMP_SINGLE_BODY' contains the body of code to be executed 10937 by a single thread. 10938 10939 Operand 'OMP_SINGLE_CLAUSES' is the list of clauses associated with 10940 the directive. 10941 10942'OMP_MASTER' 10943 10944 Represents '#pragma omp master'. 10945 10946 Operand 'OMP_MASTER_BODY' contains the body of code to be executed 10947 by the master thread. 10948 10949'OMP_ORDERED' 10950 10951 Represents '#pragma omp ordered'. 10952 10953 Operand 'OMP_ORDERED_BODY' contains the body of code to be executed 10954 in the sequential order dictated by the loop index variable. 10955 10956'OMP_CRITICAL' 10957 10958 Represents '#pragma omp critical [name]'. 10959 10960 Operand 'OMP_CRITICAL_BODY' is the critical section. 10961 10962 Operand 'OMP_CRITICAL_NAME' is an optional identifier to label the 10963 critical section. 10964 10965'OMP_RETURN' 10966 10967 This does not represent any OpenMP directive, it is an artificial 10968 marker to indicate the end of the body of an OpenMP. It is used by 10969 the flow graph ('tree-cfg.c') and OpenMP region building code 10970 ('omp-low.c'). 10971 10972'OMP_CONTINUE' 10973 10974 Similarly, this instruction does not represent an OpenMP directive, 10975 it is used by 'OMP_FOR' (and similar codes) as well as 10976 'OMP_SECTIONS' to mark the place where the code needs to loop to 10977 the next iteration, or the next section, respectively. 10978 10979 In some cases, 'OMP_CONTINUE' is placed right before 'OMP_RETURN'. 10980 But if there are cleanups that need to occur right after the 10981 looping body, it will be emitted between 'OMP_CONTINUE' and 10982 'OMP_RETURN'. 10983 10984'OMP_ATOMIC' 10985 10986 Represents '#pragma omp atomic'. 10987 10988 Operand 0 is the address at which the atomic operation is to be 10989 performed. 10990 10991 Operand 1 is the expression to evaluate. The gimplifier tries 10992 three alternative code generation strategies. Whenever possible, 10993 an atomic update built-in is used. If that fails, a 10994 compare-and-swap loop is attempted. If that also fails, a regular 10995 critical section around the expression is used. 10996 10997'OMP_CLAUSE' 10998 10999 Represents clauses associated with one of the 'OMP_' directives. 11000 Clauses are represented by separate subcodes defined in 'tree.h'. 11001 Clauses codes can be one of: 'OMP_CLAUSE_PRIVATE', 11002 'OMP_CLAUSE_SHARED', 'OMP_CLAUSE_FIRSTPRIVATE', 11003 'OMP_CLAUSE_LASTPRIVATE', 'OMP_CLAUSE_COPYIN', 11004 'OMP_CLAUSE_COPYPRIVATE', 'OMP_CLAUSE_IF', 11005 'OMP_CLAUSE_NUM_THREADS', 'OMP_CLAUSE_SCHEDULE', 11006 'OMP_CLAUSE_NOWAIT', 'OMP_CLAUSE_ORDERED', 'OMP_CLAUSE_DEFAULT', 11007 'OMP_CLAUSE_REDUCTION', 'OMP_CLAUSE_COLLAPSE', 'OMP_CLAUSE_UNTIED', 11008 'OMP_CLAUSE_FINAL', and 'OMP_CLAUSE_MERGEABLE'. Each code 11009 represents the corresponding OpenMP clause. 11010 11011 Clauses associated with the same directive are chained together via 11012 'OMP_CLAUSE_CHAIN'. Those clauses that accept a list of variables 11013 are restricted to exactly one, accessed with 'OMP_CLAUSE_VAR'. 11014 Therefore, multiple variables under the same clause 'C' need to be 11015 represented as multiple 'C' clauses chained together. This 11016 facilitates adding new clauses during compilation. 11017 11018 11019File: gccint.info, Node: OpenACC, Prev: OpenMP, Up: Statements 11020 1102111.7.8 OpenACC 11022-------------- 11023 11024All the statements starting with 'OACC_' represent directives and 11025clauses used by the OpenACC API <https://www.openacc.org>. 11026 11027'OACC_CACHE' 11028 11029 Represents '#pragma acc cache (var ...)'. 11030 11031'OACC_DATA' 11032 11033 Represents '#pragma acc data [clause1 ... clauseN]'. 11034 11035'OACC_DECLARE' 11036 11037 Represents '#pragma acc declare [clause1 ... clauseN]'. 11038 11039'OACC_ENTER_DATA' 11040 11041 Represents '#pragma acc enter data [clause1 ... clauseN]'. 11042 11043'OACC_EXIT_DATA' 11044 11045 Represents '#pragma acc exit data [clause1 ... clauseN]'. 11046 11047'OACC_HOST_DATA' 11048 11049 Represents '#pragma acc host_data [clause1 ... clauseN]'. 11050 11051'OACC_KERNELS' 11052 11053 Represents '#pragma acc kernels [clause1 ... clauseN]'. 11054 11055'OACC_LOOP' 11056 11057 Represents '#pragma acc loop [clause1 ... clauseN]'. 11058 11059 See the description of the 'OMP_FOR' code. 11060 11061'OACC_PARALLEL' 11062 11063 Represents '#pragma acc parallel [clause1 ... clauseN]'. 11064 11065'OACC_UPDATE' 11066 11067 Represents '#pragma acc update [clause1 ... clauseN]'. 11068 11069 11070File: gccint.info, Node: Functions, Next: Language-dependent trees, Prev: Statements, Up: GENERIC 11071 1107211.8 Functions 11073============== 11074 11075A function is represented by a 'FUNCTION_DECL' node. It stores the 11076basic pieces of the function such as body, parameters, and return type 11077as well as information on the surrounding context, visibility, and 11078linkage. 11079 11080* Menu: 11081 11082* Function Basics:: Function names, body, and parameters. 11083* Function Properties:: Context, linkage, etc. 11084 11085 11086File: gccint.info, Node: Function Basics, Next: Function Properties, Up: Functions 11087 1108811.8.1 Function Basics 11089---------------------- 11090 11091A function has four core parts: the name, the parameters, the result, 11092and the body. The following macros and functions access these parts of 11093a 'FUNCTION_DECL' as well as other basic features: 11094'DECL_NAME' 11095 This macro returns the unqualified name of the function, as an 11096 'IDENTIFIER_NODE'. For an instantiation of a function template, 11097 the 'DECL_NAME' is the unqualified name of the template, not 11098 something like 'f<int>'. The value of 'DECL_NAME' is undefined 11099 when used on a constructor, destructor, overloaded operator, or 11100 type-conversion operator, or any function that is implicitly 11101 generated by the compiler. See below for macros that can be used 11102 to distinguish these cases. 11103 11104'DECL_ASSEMBLER_NAME' 11105 This macro returns the mangled name of the function, also an 11106 'IDENTIFIER_NODE'. This name does not contain leading underscores 11107 on systems that prefix all identifiers with underscores. The 11108 mangled name is computed in the same way on all platforms; if 11109 special processing is required to deal with the object file format 11110 used on a particular platform, it is the responsibility of the back 11111 end to perform those modifications. (Of course, the back end 11112 should not modify 'DECL_ASSEMBLER_NAME' itself.) 11113 11114 Using 'DECL_ASSEMBLER_NAME' will cause additional memory to be 11115 allocated (for the mangled name of the entity) so it should be used 11116 only when emitting assembly code. It should not be used within the 11117 optimizers to determine whether or not two declarations are the 11118 same, even though some of the existing optimizers do use it in that 11119 way. These uses will be removed over time. 11120 11121'DECL_ARGUMENTS' 11122 This macro returns the 'PARM_DECL' for the first argument to the 11123 function. Subsequent 'PARM_DECL' nodes can be obtained by 11124 following the 'TREE_CHAIN' links. 11125 11126'DECL_RESULT' 11127 This macro returns the 'RESULT_DECL' for the function. 11128 11129'DECL_SAVED_TREE' 11130 This macro returns the complete body of the function. 11131 11132'TREE_TYPE' 11133 This macro returns the 'FUNCTION_TYPE' or 'METHOD_TYPE' for the 11134 function. 11135 11136'DECL_INITIAL' 11137 A function that has a definition in the current translation unit 11138 will have a non-'NULL' 'DECL_INITIAL'. However, back ends should 11139 not make use of the particular value given by 'DECL_INITIAL'. 11140 11141 It should contain a tree of 'BLOCK' nodes that mirrors the scopes 11142 that variables are bound in the function. Each block contains a 11143 list of decls declared in a basic block, a pointer to a chain of 11144 blocks at the next lower scope level, then a pointer to the next 11145 block at the same level and a backpointer to the parent 'BLOCK' or 11146 'FUNCTION_DECL'. So given a function as follows: 11147 11148 void foo() 11149 { 11150 int a; 11151 { 11152 int b; 11153 } 11154 int c; 11155 } 11156 11157 you would get the following: 11158 11159 tree foo = FUNCTION_DECL; 11160 tree decl_a = VAR_DECL; 11161 tree decl_b = VAR_DECL; 11162 tree decl_c = VAR_DECL; 11163 tree block_a = BLOCK; 11164 tree block_b = BLOCK; 11165 tree block_c = BLOCK; 11166 BLOCK_VARS(block_a) = decl_a; 11167 BLOCK_SUBBLOCKS(block_a) = block_b; 11168 BLOCK_CHAIN(block_a) = block_c; 11169 BLOCK_SUPERCONTEXT(block_a) = foo; 11170 BLOCK_VARS(block_b) = decl_b; 11171 BLOCK_SUPERCONTEXT(block_b) = block_a; 11172 BLOCK_VARS(block_c) = decl_c; 11173 BLOCK_SUPERCONTEXT(block_c) = foo; 11174 DECL_INITIAL(foo) = block_a; 11175 11176 11177File: gccint.info, Node: Function Properties, Prev: Function Basics, Up: Functions 11178 1117911.8.2 Function Properties 11180-------------------------- 11181 11182To determine the scope of a function, you can use the 'DECL_CONTEXT' 11183macro. This macro will return the class (either a 'RECORD_TYPE' or a 11184'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is 11185a member. For a virtual function, this macro returns the class in which 11186the function was actually defined, not the base class in which the 11187virtual declaration occurred. 11188 11189 In C, the 'DECL_CONTEXT' for a function maybe another function. This 11190representation indicates that the GNU nested function extension is in 11191use. For details on the semantics of nested functions, see the GCC 11192Manual. The nested function can refer to local variables in its 11193containing function. Such references are not explicitly marked in the 11194tree structure; back ends must look at the 'DECL_CONTEXT' for the 11195referenced 'VAR_DECL'. If the 'DECL_CONTEXT' for the referenced 11196'VAR_DECL' is not the same as the function currently being processed, 11197and neither 'DECL_EXTERNAL' nor 'TREE_STATIC' hold, then the reference 11198is to a local variable in a containing function, and the back end must 11199take appropriate action. 11200 11201'DECL_EXTERNAL' 11202 This predicate holds if the function is undefined. 11203 11204'TREE_PUBLIC' 11205 This predicate holds if the function has external linkage. 11206 11207'TREE_STATIC' 11208 This predicate holds if the function has been defined. 11209 11210'TREE_THIS_VOLATILE' 11211 This predicate holds if the function does not return normally. 11212 11213'TREE_READONLY' 11214 This predicate holds if the function can only read its arguments. 11215 11216'DECL_PURE_P' 11217 This predicate holds if the function can only read its arguments, 11218 but may also read global memory. 11219 11220'DECL_VIRTUAL_P' 11221 This predicate holds if the function is virtual. 11222 11223'DECL_ARTIFICIAL' 11224 This macro holds if the function was implicitly generated by the 11225 compiler, rather than explicitly declared. In addition to 11226 implicitly generated class member functions, this macro holds for 11227 the special functions created to implement static initialization 11228 and destruction, to compute run-time type information, and so 11229 forth. 11230 11231'DECL_FUNCTION_SPECIFIC_TARGET' 11232 This macro returns a tree node that holds the target options that 11233 are to be used to compile this particular function or 'NULL_TREE' 11234 if the function is to be compiled with the target options specified 11235 on the command line. 11236 11237'DECL_FUNCTION_SPECIFIC_OPTIMIZATION' 11238 This macro returns a tree node that holds the optimization options 11239 that are to be used to compile this particular function or 11240 'NULL_TREE' if the function is to be compiled with the optimization 11241 options specified on the command line. 11242 11243 11244File: gccint.info, Node: Language-dependent trees, Next: C and C++ Trees, Prev: Functions, Up: GENERIC 11245 1124611.9 Language-dependent trees 11247============================= 11248 11249Front ends may wish to keep some state associated with various GENERIC 11250trees while parsing. To support this, trees provide a set of flags that 11251may be used by the front end. They are accessed using 11252'TREE_LANG_FLAG_n' where 'n' is currently 0 through 6. 11253 11254 If necessary, a front end can use some language-dependent tree codes in 11255its GENERIC representation, so long as it provides a hook for converting 11256them to GIMPLE and doesn't expect them to work with any (hypothetical) 11257optimizers that run before the conversion to GIMPLE. The intermediate 11258representation used while parsing C and C++ looks very little like 11259GENERIC, but the C and C++ gimplifier hooks are perfectly happy to take 11260it as input and spit out GIMPLE. 11261 11262 11263File: gccint.info, Node: C and C++ Trees, Next: Java Trees, Prev: Language-dependent trees, Up: GENERIC 11264 1126511.10 C and C++ Trees 11266===================== 11267 11268This section documents the internal representation used by GCC to 11269represent C and C++ source programs. When presented with a C or C++ 11270source program, GCC parses the program, performs semantic analysis 11271(including the generation of error messages), and then produces the 11272internal representation described here. This representation contains a 11273complete representation for the entire translation unit provided as 11274input to the front end. This representation is then typically processed 11275by a code-generator in order to produce machine code, but could also be 11276used in the creation of source browsers, intelligent editors, automatic 11277documentation generators, interpreters, and any other programs needing 11278the ability to process C or C++ code. 11279 11280 This section explains the internal representation. In particular, it 11281documents the internal representation for C and C++ source constructs, 11282and the macros, functions, and variables that can be used to access 11283these constructs. The C++ representation is largely a superset of the 11284representation used in the C front end. There is only one construct 11285used in C that does not appear in the C++ front end and that is the GNU 11286"nested function" extension. Many of the macros documented here do not 11287apply in C because the corresponding language constructs do not appear 11288in C. 11289 11290 The C and C++ front ends generate a mix of GENERIC trees and ones 11291specific to C and C++. These language-specific trees are higher-level 11292constructs than the ones in GENERIC to make the parser's job easier. 11293This section describes those trees that aren't part of GENERIC as well 11294as aspects of GENERIC trees that are treated in a language-specific 11295manner. 11296 11297 If you are developing a "back end", be it is a code-generator or some 11298other tool, that uses this representation, you may occasionally find 11299that you need to ask questions not easily answered by the functions and 11300macros available here. If that situation occurs, it is quite likely 11301that GCC already supports the functionality you desire, but that the 11302interface is simply not documented here. In that case, you should ask 11303the GCC maintainers (via mail to <gcc@gcc.gnu.org>) about documenting 11304the functionality you require. Similarly, if you find yourself writing 11305functions that do not deal directly with your back end, but instead 11306might be useful to other people using the GCC front end, you should 11307submit your patches for inclusion in GCC. 11308 11309* Menu: 11310 11311* Types for C++:: Fundamental and aggregate types. 11312* Namespaces:: Namespaces. 11313* Classes:: Classes. 11314* Functions for C++:: Overloading and accessors for C++. 11315* Statements for C++:: Statements specific to C and C++. 11316* C++ Expressions:: From 'typeid' to 'throw'. 11317 11318 11319File: gccint.info, Node: Types for C++, Next: Namespaces, Up: C and C++ Trees 11320 1132111.10.1 Types for C++ 11322--------------------- 11323 11324In C++, an array type is not qualified; rather the type of the array 11325elements is qualified. This situation is reflected in the intermediate 11326representation. The macros described here will always examine the 11327qualification of the underlying element type when applied to an array 11328type. (If the element type is itself an array, then the recursion 11329continues until a non-array type is found, and the qualification of this 11330type is examined.) So, for example, 'CP_TYPE_CONST_P' will hold of the 11331type 'const int ()[7]', denoting an array of seven 'int's. 11332 11333 The following functions and macros deal with cv-qualification of types: 11334'cp_type_quals' 11335 This function returns the set of type qualifiers applied to this 11336 type. This value is 'TYPE_UNQUALIFIED' if no qualifiers have been 11337 applied. The 'TYPE_QUAL_CONST' bit is set if the type is 11338 'const'-qualified. The 'TYPE_QUAL_VOLATILE' bit is set if the type 11339 is 'volatile'-qualified. The 'TYPE_QUAL_RESTRICT' bit is set if 11340 the type is 'restrict'-qualified. 11341 11342'CP_TYPE_CONST_P' 11343 This macro holds if the type is 'const'-qualified. 11344 11345'CP_TYPE_VOLATILE_P' 11346 This macro holds if the type is 'volatile'-qualified. 11347 11348'CP_TYPE_RESTRICT_P' 11349 This macro holds if the type is 'restrict'-qualified. 11350 11351'CP_TYPE_CONST_NON_VOLATILE_P' 11352 This predicate holds for a type that is 'const'-qualified, but 11353 _not_ 'volatile'-qualified; other cv-qualifiers are ignored as 11354 well: only the 'const'-ness is tested. 11355 11356 A few other macros and functions are usable with all types: 11357'TYPE_SIZE' 11358 The number of bits required to represent the type, represented as 11359 an 'INTEGER_CST'. For an incomplete type, 'TYPE_SIZE' will be 11360 'NULL_TREE'. 11361 11362'TYPE_ALIGN' 11363 The alignment of the type, in bits, represented as an 'int'. 11364 11365'TYPE_NAME' 11366 This macro returns a declaration (in the form of a 'TYPE_DECL') for 11367 the type. (Note this macro does _not_ return an 'IDENTIFIER_NODE', 11368 as you might expect, given its name!) You can look at the 11369 'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the 11370 type. The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a 11371 built-in type, the result of a typedef, or a named class type. 11372 11373'CP_INTEGRAL_TYPE' 11374 This predicate holds if the type is an integral type. Notice that 11375 in C++, enumerations are _not_ integral types. 11376 11377'ARITHMETIC_TYPE_P' 11378 This predicate holds if the type is an integral type (in the C++ 11379 sense) or a floating point type. 11380 11381'CLASS_TYPE_P' 11382 This predicate holds for a class-type. 11383 11384'TYPE_BUILT_IN' 11385 This predicate holds for a built-in type. 11386 11387'TYPE_PTRDATAMEM_P' 11388 This predicate holds if the type is a pointer to data member. 11389 11390'TYPE_PTR_P' 11391 This predicate holds if the type is a pointer type, and the pointee 11392 is not a data member. 11393 11394'TYPE_PTRFN_P' 11395 This predicate holds for a pointer to function type. 11396 11397'TYPE_PTROB_P' 11398 This predicate holds for a pointer to object type. Note however 11399 that it does not hold for the generic pointer to object type 'void 11400 *'. You may use 'TYPE_PTROBV_P' to test for a pointer to object 11401 type as well as 'void *'. 11402 11403 The table below describes types specific to C and C++ as well as 11404language-dependent info about GENERIC types. 11405 11406'POINTER_TYPE' 11407 Used to represent pointer types, and pointer to data member types. 11408 If 'TREE_TYPE' is a pointer to data member type, then 11409 'TYPE_PTRDATAMEM_P' will hold. For a pointer to data member type 11410 of the form 'T X::*', 'TYPE_PTRMEM_CLASS_TYPE' will be the type 11411 'X', while 'TYPE_PTRMEM_POINTED_TO_TYPE' will be the type 'T'. 11412 11413'RECORD_TYPE' 11414 Used to represent 'struct' and 'class' types in C and C++. If 11415 'TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member 11416 type. In that case, the 'TYPE_PTRMEMFUNC_FN_TYPE' is a 11417 'POINTER_TYPE' pointing to a 'METHOD_TYPE'. The 'METHOD_TYPE' is 11418 the type of a function pointed to by the pointer-to-member 11419 function. If 'TYPE_PTRMEMFUNC_P' does not hold, this type is a 11420 class type. For more information, *note Classes::. 11421 11422'UNKNOWN_TYPE' 11423 This node is used to represent a type the knowledge of which is 11424 insufficient for a sound processing. 11425 11426'TYPENAME_TYPE' 11427 Used to represent a construct of the form 'typename T::A'. The 11428 'TYPE_CONTEXT' is 'T'; the 'TYPE_NAME' is an 'IDENTIFIER_NODE' for 11429 'A'. If the type is specified via a template-id, then 11430 'TYPENAME_TYPE_FULLNAME' yields a 'TEMPLATE_ID_EXPR'. The 11431 'TREE_TYPE' is non-'NULL' if the node is implicitly generated in 11432 support for the implicit typename extension; in which case the 11433 'TREE_TYPE' is a type node for the base-class. 11434 11435'TYPEOF_TYPE' 11436 Used to represent the '__typeof__' extension. The 'TYPE_FIELDS' is 11437 the expression the type of which is being represented. 11438 11439 11440File: gccint.info, Node: Namespaces, Next: Classes, Prev: Types for C++, Up: C and C++ Trees 11441 1144211.10.2 Namespaces 11443------------------ 11444 11445The root of the entire intermediate representation is the variable 11446'global_namespace'. This is the namespace specified with '::' in C++ 11447source code. All other namespaces, types, variables, functions, and so 11448forth can be found starting with this namespace. 11449 11450 However, except for the fact that it is distinguished as the root of 11451the representation, the global namespace is no different from any other 11452namespace. Thus, in what follows, we describe namespaces generally, 11453rather than the global namespace in particular. 11454 11455 A namespace is represented by a 'NAMESPACE_DECL' node. 11456 11457 The following macros and functions can be used on a 'NAMESPACE_DECL': 11458 11459'DECL_NAME' 11460 This macro is used to obtain the 'IDENTIFIER_NODE' corresponding to 11461 the unqualified name of the name of the namespace (*note 11462 Identifiers::). The name of the global namespace is '::', even 11463 though in C++ the global namespace is unnamed. However, you should 11464 use comparison with 'global_namespace', rather than 'DECL_NAME' to 11465 determine whether or not a namespace is the global one. An unnamed 11466 namespace will have a 'DECL_NAME' equal to 11467 'anonymous_namespace_name'. Within a single translation unit, all 11468 unnamed namespaces will have the same name. 11469 11470'DECL_CONTEXT' 11471 This macro returns the enclosing namespace. The 'DECL_CONTEXT' for 11472 the 'global_namespace' is 'NULL_TREE'. 11473 11474'DECL_NAMESPACE_ALIAS' 11475 If this declaration is for a namespace alias, then 11476 'DECL_NAMESPACE_ALIAS' is the namespace for which this one is an 11477 alias. 11478 11479 Do not attempt to use 'cp_namespace_decls' for a namespace which is 11480 an alias. Instead, follow 'DECL_NAMESPACE_ALIAS' links until you 11481 reach an ordinary, non-alias, namespace, and call 11482 'cp_namespace_decls' there. 11483 11484'DECL_NAMESPACE_STD_P' 11485 This predicate holds if the namespace is the special '::std' 11486 namespace. 11487 11488'cp_namespace_decls' 11489 This function will return the declarations contained in the 11490 namespace, including types, overloaded functions, other namespaces, 11491 and so forth. If there are no declarations, this function will 11492 return 'NULL_TREE'. The declarations are connected through their 11493 'TREE_CHAIN' fields. 11494 11495 Although most entries on this list will be declarations, 11496 'TREE_LIST' nodes may also appear. In this case, the 'TREE_VALUE' 11497 will be an 'OVERLOAD'. The value of the 'TREE_PURPOSE' is 11498 unspecified; back ends should ignore this value. As with the other 11499 kinds of declarations returned by 'cp_namespace_decls', the 11500 'TREE_CHAIN' will point to the next declaration in this list. 11501 11502 For more information on the kinds of declarations that can occur on 11503 this list, *Note Declarations::. Some declarations will not appear 11504 on this list. In particular, no 'FIELD_DECL', 'LABEL_DECL', or 11505 'PARM_DECL' nodes will appear here. 11506 11507 This function cannot be used with namespaces that have 11508 'DECL_NAMESPACE_ALIAS' set. 11509 11510 11511File: gccint.info, Node: Classes, Next: Functions for C++, Prev: Namespaces, Up: C and C++ Trees 11512 1151311.10.3 Classes 11514--------------- 11515 11516Besides namespaces, the other high-level scoping construct in C++ is the 11517class. (Throughout this manual the term "class" is used to mean the 11518types referred to in the ANSI/ISO C++ Standard as classes; these include 11519types defined with the 'class', 'struct', and 'union' keywords.) 11520 11521 A class type is represented by either a 'RECORD_TYPE' or a 11522'UNION_TYPE'. A class declared with the 'union' tag is represented by a 11523'UNION_TYPE', while classes declared with either the 'struct' or the 11524'class' tag are represented by 'RECORD_TYPE's. You can use the 11525'CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular 11526type is a 'class' as opposed to a 'struct'. This macro will be true 11527only for classes declared with the 'class' tag. 11528 11529 Almost all members are available on the 'TYPE_FIELDS' list. Given one 11530member, the next can be found by following the 'TREE_CHAIN'. You should 11531not depend in any way on the order in which fields appear on this list. 11532All nodes on this list will be 'DECL' nodes. A 'FIELD_DECL' is used to 11533represent a non-static data member, a 'VAR_DECL' is used to represent a 11534static data member, and a 'TYPE_DECL' is used to represent a type. Note 11535that the 'CONST_DECL' for an enumeration constant will appear on this 11536list, if the enumeration type was declared in the class. (Of course, 11537the 'TYPE_DECL' for the enumeration type will appear here as well.) 11538There are no entries for base classes on this list. In particular, 11539there is no 'FIELD_DECL' for the "base-class portion" of an object. If 11540a function member is overloaded, each of the overloaded functions 11541appears; no 'OVERLOAD' nodes appear on the 'TYPE_FIELDS' list. 11542Implicitly declared functions (including default constructors, copy 11543constructors, assignment operators, and destructors) will appear on this 11544list as well. 11545 11546 The 'TYPE_VFIELD' is a compiler-generated field used to point to 11547virtual function tables. It may or may not appear on the 'TYPE_FIELDS' 11548list. However, back ends should handle the 'TYPE_VFIELD' just like all 11549the entries on the 'TYPE_FIELDS' list. 11550 11551 Every class has an associated "binfo", which can be obtained with 11552'TYPE_BINFO'. Binfos are used to represent base-classes. The binfo 11553given by 'TYPE_BINFO' is the degenerate case, whereby every class is 11554considered to be its own base-class. The base binfos for a particular 11555binfo are held in a vector, whose length is obtained with 11556'BINFO_N_BASE_BINFOS'. The base binfos themselves are obtained with 11557'BINFO_BASE_BINFO' and 'BINFO_BASE_ITERATE'. To add a new binfo, use 11558'BINFO_BASE_APPEND'. The vector of base binfos can be obtained with 11559'BINFO_BASE_BINFOS', but normally you do not need to use that. The 11560class type associated with a binfo is given by 'BINFO_TYPE'. It is not 11561always the case that 'BINFO_TYPE (TYPE_BINFO (x))', because of typedefs 11562and qualified types. Neither is it the case that 'TYPE_BINFO 11563(BINFO_TYPE (y))' is the same binfo as 'y'. The reason is that if 'y' 11564is a binfo representing a base-class 'B' of a derived class 'D', then 11565'BINFO_TYPE (y)' will be 'B', and 'TYPE_BINFO (BINFO_TYPE (y))' will be 11566'B' as its own base-class, rather than as a base-class of 'D'. 11567 11568 The access to a base type can be found with 'BINFO_BASE_ACCESS'. This 11569will produce 'access_public_node', 'access_private_node' or 11570'access_protected_node'. If bases are always public, 11571'BINFO_BASE_ACCESSES' may be 'NULL'. 11572 11573 'BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited 11574virtually or not. The other flags, 'BINFO_FLAG_0' to 'BINFO_FLAG_6', 11575can be used for language specific use. 11576 11577 The following macros can be used on a tree node representing a 11578class-type. 11579 11580'LOCAL_CLASS_P' 11581 This predicate holds if the class is local class _i.e._ declared 11582 inside a function body. 11583 11584'TYPE_POLYMORPHIC_P' 11585 This predicate holds if the class has at least one virtual function 11586 (declared or inherited). 11587 11588'TYPE_HAS_DEFAULT_CONSTRUCTOR' 11589 This predicate holds whenever its argument represents a class-type 11590 with default constructor. 11591 11592'CLASSTYPE_HAS_MUTABLE' 11593'TYPE_HAS_MUTABLE_P' 11594 These predicates hold for a class-type having a mutable data 11595 member. 11596 11597'CLASSTYPE_NON_POD_P' 11598 This predicate holds only for class-types that are not PODs. 11599 11600'TYPE_HAS_NEW_OPERATOR' 11601 This predicate holds for a class-type that defines 'operator new'. 11602 11603'TYPE_HAS_ARRAY_NEW_OPERATOR' 11604 This predicate holds for a class-type for which 'operator new[]' is 11605 defined. 11606 11607'TYPE_OVERLOADS_CALL_EXPR' 11608 This predicate holds for class-type for which the function call 11609 'operator()' is overloaded. 11610 11611'TYPE_OVERLOADS_ARRAY_REF' 11612 This predicate holds for a class-type that overloads 'operator[]' 11613 11614'TYPE_OVERLOADS_ARROW' 11615 This predicate holds for a class-type for which 'operator->' is 11616 overloaded. 11617 11618 11619File: gccint.info, Node: Functions for C++, Next: Statements for C++, Prev: Classes, Up: C and C++ Trees 11620 1162111.10.4 Functions for C++ 11622------------------------- 11623 11624A function is represented by a 'FUNCTION_DECL' node. A set of 11625overloaded functions is sometimes represented by an 'OVERLOAD' node. 11626 11627 An 'OVERLOAD' node is not a declaration, so none of the 'DECL_' macros 11628should be used on an 'OVERLOAD'. An 'OVERLOAD' node is similar to a 11629'TREE_LIST'. Use 'OVL_CURRENT' to get the function associated with an 11630'OVERLOAD' node; use 'OVL_NEXT' to get the next 'OVERLOAD' node in the 11631list of overloaded functions. The macros 'OVL_CURRENT' and 'OVL_NEXT' 11632are actually polymorphic; you can use them to work with 'FUNCTION_DECL' 11633nodes as well as with overloads. In the case of a 'FUNCTION_DECL', 11634'OVL_CURRENT' will always return the function itself, and 'OVL_NEXT' 11635will always be 'NULL_TREE'. 11636 11637 To determine the scope of a function, you can use the 'DECL_CONTEXT' 11638macro. This macro will return the class (either a 'RECORD_TYPE' or a 11639'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is 11640a member. For a virtual function, this macro returns the class in which 11641the function was actually defined, not the base class in which the 11642virtual declaration occurred. 11643 11644 If a friend function is defined in a class scope, the 11645'DECL_FRIEND_CONTEXT' macro can be used to determine the class in which 11646it was defined. For example, in 11647 class C { friend void f() {} }; 11648the 'DECL_CONTEXT' for 'f' will be the 'global_namespace', but the 11649'DECL_FRIEND_CONTEXT' will be the 'RECORD_TYPE' for 'C'. 11650 11651 The following macros and functions can be used on a 'FUNCTION_DECL': 11652'DECL_MAIN_P' 11653 This predicate holds for a function that is the program entry point 11654 '::code'. 11655 11656'DECL_LOCAL_FUNCTION_P' 11657 This predicate holds if the function was declared at block scope, 11658 even though it has a global scope. 11659 11660'DECL_ANTICIPATED' 11661 This predicate holds if the function is a built-in function but its 11662 prototype is not yet explicitly declared. 11663 11664'DECL_EXTERN_C_FUNCTION_P' 11665 This predicate holds if the function is declared as an ''extern 11666 "C"'' function. 11667 11668'DECL_LINKONCE_P' 11669 This macro holds if multiple copies of this function may be emitted 11670 in various translation units. It is the responsibility of the 11671 linker to merge the various copies. Template instantiations are 11672 the most common example of functions for which 'DECL_LINKONCE_P' 11673 holds; G++ instantiates needed templates in all translation units 11674 which require them, and then relies on the linker to remove 11675 duplicate instantiations. 11676 11677 FIXME: This macro is not yet implemented. 11678 11679'DECL_FUNCTION_MEMBER_P' 11680 This macro holds if the function is a member of a class, rather 11681 than a member of a namespace. 11682 11683'DECL_STATIC_FUNCTION_P' 11684 This predicate holds if the function a static member function. 11685 11686'DECL_NONSTATIC_MEMBER_FUNCTION_P' 11687 This macro holds for a non-static member function. 11688 11689'DECL_CONST_MEMFUNC_P' 11690 This predicate holds for a 'const'-member function. 11691 11692'DECL_VOLATILE_MEMFUNC_P' 11693 This predicate holds for a 'volatile'-member function. 11694 11695'DECL_CONSTRUCTOR_P' 11696 This macro holds if the function is a constructor. 11697 11698'DECL_NONCONVERTING_P' 11699 This predicate holds if the constructor is a non-converting 11700 constructor. 11701 11702'DECL_COMPLETE_CONSTRUCTOR_P' 11703 This predicate holds for a function which is a constructor for an 11704 object of a complete type. 11705 11706'DECL_BASE_CONSTRUCTOR_P' 11707 This predicate holds for a function which is a constructor for a 11708 base class sub-object. 11709 11710'DECL_COPY_CONSTRUCTOR_P' 11711 This predicate holds for a function which is a copy-constructor. 11712 11713'DECL_DESTRUCTOR_P' 11714 This macro holds if the function is a destructor. 11715 11716'DECL_COMPLETE_DESTRUCTOR_P' 11717 This predicate holds if the function is the destructor for an 11718 object a complete type. 11719 11720'DECL_OVERLOADED_OPERATOR_P' 11721 This macro holds if the function is an overloaded operator. 11722 11723'DECL_CONV_FN_P' 11724 This macro holds if the function is a type-conversion operator. 11725 11726'DECL_GLOBAL_CTOR_P' 11727 This predicate holds if the function is a file-scope initialization 11728 function. 11729 11730'DECL_GLOBAL_DTOR_P' 11731 This predicate holds if the function is a file-scope finalization 11732 function. 11733 11734'DECL_THUNK_P' 11735 This predicate holds if the function is a thunk. 11736 11737 These functions represent stub code that adjusts the 'this' pointer 11738 and then jumps to another function. When the jumped-to function 11739 returns, control is transferred directly to the caller, without 11740 returning to the thunk. The first parameter to the thunk is always 11741 the 'this' pointer; the thunk should add 'THUNK_DELTA' to this 11742 value. (The 'THUNK_DELTA' is an 'int', not an 'INTEGER_CST'.) 11743 11744 Then, if 'THUNK_VCALL_OFFSET' (an 'INTEGER_CST') is nonzero the 11745 adjusted 'this' pointer must be adjusted again. The complete 11746 calculation is given by the following pseudo-code: 11747 11748 this += THUNK_DELTA 11749 if (THUNK_VCALL_OFFSET) 11750 this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET] 11751 11752 Finally, the thunk should jump to the location given by 11753 'DECL_INITIAL'; this will always be an expression for the address 11754 of a function. 11755 11756'DECL_NON_THUNK_FUNCTION_P' 11757 This predicate holds if the function is _not_ a thunk function. 11758 11759'GLOBAL_INIT_PRIORITY' 11760 If either 'DECL_GLOBAL_CTOR_P' or 'DECL_GLOBAL_DTOR_P' holds, then 11761 this gives the initialization priority for the function. The 11762 linker will arrange that all functions for which 11763 'DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority 11764 before 'main' is called. When the program exits, all functions for 11765 which 'DECL_GLOBAL_DTOR_P' holds are run in the reverse order. 11766 11767'TYPE_RAISES_EXCEPTIONS' 11768 This macro returns the list of exceptions that a (member-)function 11769 can raise. The returned list, if non 'NULL', is comprised of nodes 11770 whose 'TREE_VALUE' represents a type. 11771 11772'TYPE_NOTHROW_P' 11773 This predicate holds when the exception-specification of its 11774 arguments is of the form ''()''. 11775 11776'DECL_ARRAY_DELETE_OPERATOR_P' 11777 This predicate holds if the function an overloaded 'operator 11778 delete[]'. 11779 11780 11781File: gccint.info, Node: Statements for C++, Next: C++ Expressions, Prev: Functions for C++, Up: C and C++ Trees 11782 1178311.10.5 Statements for C++ 11784-------------------------- 11785 11786A function that has a definition in the current translation unit will 11787have a non-'NULL' 'DECL_INITIAL'. However, back ends should not make 11788use of the particular value given by 'DECL_INITIAL'. 11789 11790 The 'DECL_SAVED_TREE' macro will give the complete body of the 11791function. 11792 1179311.10.5.1 Statements 11794.................... 11795 11796There are tree nodes corresponding to all of the source-level statement 11797constructs, used within the C and C++ frontends. These are enumerated 11798here, together with a list of the various macros that can be used to 11799obtain information about them. There are a few macros that can be used 11800with all statements: 11801 11802'STMT_IS_FULL_EXPR_P' 11803 In C++, statements normally constitute "full expressions"; 11804 temporaries created during a statement are destroyed when the 11805 statement is complete. However, G++ sometimes represents 11806 expressions by statements; these statements will not have 11807 'STMT_IS_FULL_EXPR_P' set. Temporaries created during such 11808 statements should be destroyed when the innermost enclosing 11809 statement with 'STMT_IS_FULL_EXPR_P' set is exited. 11810 11811 Here is the list of the various statement nodes, and the macros used to 11812access them. This documentation describes the use of these nodes in 11813non-template functions (including instantiations of template functions). 11814In template functions, the same nodes are used, but sometimes in 11815slightly different ways. 11816 11817 Many of the statements have substatements. For example, a 'while' loop 11818will have a body, which is itself a statement. If the substatement is 11819'NULL_TREE', it is considered equivalent to a statement consisting of a 11820single ';', i.e., an expression statement in which the expression has 11821been omitted. A substatement may in fact be a list of statements, 11822connected via their 'TREE_CHAIN's. So, you should always process the 11823statement tree by looping over substatements, like this: 11824 void process_stmt (stmt) 11825 tree stmt; 11826 { 11827 while (stmt) 11828 { 11829 switch (TREE_CODE (stmt)) 11830 { 11831 case IF_STMT: 11832 process_stmt (THEN_CLAUSE (stmt)); 11833 /* More processing here. */ 11834 break; 11835 11836 ... 11837 } 11838 11839 stmt = TREE_CHAIN (stmt); 11840 } 11841 } 11842 In other words, while the 'then' clause of an 'if' statement in C++ can 11843be only one statement (although that one statement may be a compound 11844statement), the intermediate representation will sometimes use several 11845statements chained together. 11846 11847'BREAK_STMT' 11848 11849 Used to represent a 'break' statement. There are no additional 11850 fields. 11851 11852'CLEANUP_STMT' 11853 11854 Used to represent an action that should take place upon exit from 11855 the enclosing scope. Typically, these actions are calls to 11856 destructors for local objects, but back ends cannot rely on this 11857 fact. If these nodes are in fact representing such destructors, 11858 'CLEANUP_DECL' will be the 'VAR_DECL' destroyed. Otherwise, 11859 'CLEANUP_DECL' will be 'NULL_TREE'. In any case, the 11860 'CLEANUP_EXPR' is the expression to execute. The cleanups executed 11861 on exit from a scope should be run in the reverse order of the 11862 order in which the associated 'CLEANUP_STMT's were encountered. 11863 11864'CONTINUE_STMT' 11865 11866 Used to represent a 'continue' statement. There are no additional 11867 fields. 11868 11869'CTOR_STMT' 11870 11871 Used to mark the beginning (if 'CTOR_BEGIN_P' holds) or end (if 11872 'CTOR_END_P' holds of the main body of a constructor. See also 11873 'SUBOBJECT' for more information on how to use these nodes. 11874 11875'DO_STMT' 11876 11877 Used to represent a 'do' loop. The body of the loop is given by 11878 'DO_BODY' while the termination condition for the loop is given by 11879 'DO_COND'. The condition for a 'do'-statement is always an 11880 expression. 11881 11882'EMPTY_CLASS_EXPR' 11883 11884 Used to represent a temporary object of a class with no data whose 11885 address is never taken. (All such objects are interchangeable.) 11886 The 'TREE_TYPE' represents the type of the object. 11887 11888'EXPR_STMT' 11889 11890 Used to represent an expression statement. Use 'EXPR_STMT_EXPR' to 11891 obtain the expression. 11892 11893'FOR_STMT' 11894 11895 Used to represent a 'for' statement. The 'FOR_INIT_STMT' is the 11896 initialization statement for the loop. The 'FOR_COND' is the 11897 termination condition. The 'FOR_EXPR' is the expression executed 11898 right before the 'FOR_COND' on each loop iteration; often, this 11899 expression increments a counter. The body of the loop is given by 11900 'FOR_BODY'. Note that 'FOR_INIT_STMT' and 'FOR_BODY' return 11901 statements, while 'FOR_COND' and 'FOR_EXPR' return expressions. 11902 11903'HANDLER' 11904 11905 Used to represent a C++ 'catch' block. The 'HANDLER_TYPE' is the 11906 type of exception that will be caught by this handler; it is equal 11907 (by pointer equality) to 'NULL' if this handler is for all types. 11908 'HANDLER_PARMS' is the 'DECL_STMT' for the catch parameter, and 11909 'HANDLER_BODY' is the code for the block itself. 11910 11911'IF_STMT' 11912 11913 Used to represent an 'if' statement. The 'IF_COND' is the 11914 expression. 11915 11916 If the condition is a 'TREE_LIST', then the 'TREE_PURPOSE' is a 11917 statement (usually a 'DECL_STMT'). Each time the condition is 11918 evaluated, the statement should be executed. Then, the 11919 'TREE_VALUE' should be used as the conditional expression itself. 11920 This representation is used to handle C++ code like this: 11921 11922 C++ distinguishes between this and 'COND_EXPR' for handling 11923 templates. 11924 11925 if (int i = 7) ... 11926 11927 where there is a new local variable (or variables) declared within 11928 the condition. 11929 11930 The 'THEN_CLAUSE' represents the statement given by the 'then' 11931 condition, while the 'ELSE_CLAUSE' represents the statement given 11932 by the 'else' condition. 11933 11934'SUBOBJECT' 11935 11936 In a constructor, these nodes are used to mark the point at which a 11937 subobject of 'this' is fully constructed. If, after this point, an 11938 exception is thrown before a 'CTOR_STMT' with 'CTOR_END_P' set is 11939 encountered, the 'SUBOBJECT_CLEANUP' must be executed. The 11940 cleanups must be executed in the reverse order in which they 11941 appear. 11942 11943'SWITCH_STMT' 11944 11945 Used to represent a 'switch' statement. The 'SWITCH_STMT_COND' is 11946 the expression on which the switch is occurring. See the 11947 documentation for an 'IF_STMT' for more information on the 11948 representation used for the condition. The 'SWITCH_STMT_BODY' is 11949 the body of the switch statement. The 'SWITCH_STMT_TYPE' is the 11950 original type of switch expression as given in the source, before 11951 any compiler conversions. 11952 11953'TRY_BLOCK' 11954 Used to represent a 'try' block. The body of the try block is 11955 given by 'TRY_STMTS'. Each of the catch blocks is a 'HANDLER' 11956 node. The first handler is given by 'TRY_HANDLERS'. Subsequent 11957 handlers are obtained by following the 'TREE_CHAIN' link from one 11958 handler to the next. The body of the handler is given by 11959 'HANDLER_BODY'. 11960 11961 If 'CLEANUP_P' holds of the 'TRY_BLOCK', then the 'TRY_HANDLERS' 11962 will not be a 'HANDLER' node. Instead, it will be an expression 11963 that should be executed if an exception is thrown in the try block. 11964 It must rethrow the exception after executing that code. And, if 11965 an exception is thrown while the expression is executing, 11966 'terminate' must be called. 11967 11968'USING_STMT' 11969 Used to represent a 'using' directive. The namespace is given by 11970 'USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node 11971 is needed inside template functions, to implement using directives 11972 during instantiation. 11973 11974'WHILE_STMT' 11975 11976 Used to represent a 'while' loop. The 'WHILE_COND' is the 11977 termination condition for the loop. See the documentation for an 11978 'IF_STMT' for more information on the representation used for the 11979 condition. 11980 11981 The 'WHILE_BODY' is the body of the loop. 11982 11983 11984File: gccint.info, Node: C++ Expressions, Prev: Statements for C++, Up: C and C++ Trees 11985 1198611.10.6 C++ Expressions 11987----------------------- 11988 11989This section describes expressions specific to the C and C++ front ends. 11990 11991'TYPEID_EXPR' 11992 11993 Used to represent a 'typeid' expression. 11994 11995'NEW_EXPR' 11996'VEC_NEW_EXPR' 11997 11998 Used to represent a call to 'new' and 'new[]' respectively. 11999 12000'DELETE_EXPR' 12001'VEC_DELETE_EXPR' 12002 12003 Used to represent a call to 'delete' and 'delete[]' respectively. 12004 12005'MEMBER_REF' 12006 12007 Represents a reference to a member of a class. 12008 12009'THROW_EXPR' 12010 12011 Represents an instance of 'throw' in the program. Operand 0, which 12012 is the expression to throw, may be 'NULL_TREE'. 12013 12014'AGGR_INIT_EXPR' 12015 An 'AGGR_INIT_EXPR' represents the initialization as the return 12016 value of a function call, or as the result of a constructor. An 12017 'AGGR_INIT_EXPR' will only appear as a full-expression, or as the 12018 second operand of a 'TARGET_EXPR'. 'AGGR_INIT_EXPR's have a 12019 representation similar to that of 'CALL_EXPR's. You can use the 12020 'AGGR_INIT_EXPR_FN' and 'AGGR_INIT_EXPR_ARG' macros to access the 12021 function to call and the arguments to pass. 12022 12023 If 'AGGR_INIT_VIA_CTOR_P' holds of the 'AGGR_INIT_EXPR', then the 12024 initialization is via a constructor call. The address of the 12025 'AGGR_INIT_EXPR_SLOT' operand, which is always a 'VAR_DECL', is 12026 taken, and this value replaces the first argument in the argument 12027 list. 12028 12029 In either case, the expression is void. 12030 12031 12032File: gccint.info, Node: Java Trees, Prev: C and C++ Trees, Up: GENERIC 12033 1203411.11 Java Trees 12035================ 12036 12037 12038File: gccint.info, Node: GIMPLE, Next: Tree SSA, Prev: GENERIC, Up: Top 12039 1204012 GIMPLE 12041********* 12042 12043GIMPLE is a three-address representation derived from GENERIC by 12044breaking down GENERIC expressions into tuples of no more than 3 operands 12045(with some exceptions like function calls). GIMPLE was heavily 12046influenced by the SIMPLE IL used by the McCAT compiler project at McGill 12047University, though we have made some different choices. For one thing, 12048SIMPLE doesn't support 'goto'. 12049 12050 Temporaries are introduced to hold intermediate values needed to 12051compute complex expressions. Additionally, all the control structures 12052used in GENERIC are lowered into conditional jumps, lexical scopes are 12053removed and exception regions are converted into an on the side 12054exception region tree. 12055 12056 The compiler pass which converts GENERIC into GIMPLE is referred to as 12057the 'gimplifier'. The gimplifier works recursively, generating GIMPLE 12058tuples out of the original GENERIC expressions. 12059 12060 One of the early implementation strategies used for the GIMPLE 12061representation was to use the same internal data structures used by 12062front ends to represent parse trees. This simplified implementation 12063because we could leverage existing functionality and interfaces. 12064However, GIMPLE is a much more restrictive representation than abstract 12065syntax trees (AST), therefore it does not require the full structural 12066complexity provided by the main tree data structure. 12067 12068 The GENERIC representation of a function is stored in the 12069'DECL_SAVED_TREE' field of the associated 'FUNCTION_DECL' tree node. It 12070is converted to GIMPLE by a call to 'gimplify_function_tree'. 12071 12072 If a front end wants to include language-specific tree codes in the 12073tree representation which it provides to the back end, it must provide a 12074definition of 'LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the 12075front end trees to GIMPLE. Usually such a hook will involve much of the 12076same code for expanding front end trees to RTL. This function can 12077return fully lowered GIMPLE, or it can return GENERIC trees and let the 12078main gimplifier lower them the rest of the way; this is often simpler. 12079GIMPLE that is not fully lowered is known as "High GIMPLE" and consists 12080of the IL before the pass 'pass_lower_cf'. High GIMPLE contains some 12081container statements like lexical scopes (represented by 'GIMPLE_BIND') 12082and nested expressions (e.g., 'GIMPLE_TRY'), while "Low GIMPLE" exposes 12083all of the implicit jumps for control and exception expressions directly 12084in the IL and EH region trees. 12085 12086 The C and C++ front ends currently convert directly from front end 12087trees to GIMPLE, and hand that off to the back end rather than first 12088converting to GENERIC. Their gimplifier hooks know about all the 12089'_STMT' nodes and how to convert them to GENERIC forms. There was some 12090work done on a genericization pass which would run first, but the 12091existence of 'STMT_EXPR' meant that in order to convert all of the C 12092statements into GENERIC equivalents would involve walking the entire 12093tree anyway, so it was simpler to lower all the way. This might change 12094in the future if someone writes an optimization pass which would work 12095better with higher-level trees, but currently the optimizers all expect 12096GIMPLE. 12097 12098 You can request to dump a C-like representation of the GIMPLE form with 12099the flag '-fdump-tree-gimple'. 12100 12101* Menu: 12102 12103* Tuple representation:: 12104* Class hierarchy of GIMPLE statements:: 12105* GIMPLE instruction set:: 12106* GIMPLE Exception Handling:: 12107* Temporaries:: 12108* Operands:: 12109* Manipulating GIMPLE statements:: 12110* Tuple specific accessors:: 12111* GIMPLE sequences:: 12112* Sequence iterators:: 12113* Adding a new GIMPLE statement code:: 12114* Statement and operand traversals:: 12115 12116 12117File: gccint.info, Node: Tuple representation, Next: Class hierarchy of GIMPLE statements, Up: GIMPLE 12118 1211912.1 Tuple representation 12120========================= 12121 12122GIMPLE instructions are tuples of variable size divided in two groups: a 12123header describing the instruction and its locations, and a variable 12124length body with all the operands. Tuples are organized into a 12125hierarchy with 3 main classes of tuples. 12126 1212712.1.1 'gimple' (gsbase) 12128------------------------ 12129 12130This is the root of the hierarchy, it holds basic information needed by 12131most GIMPLE statements. There are some fields that may not be relevant 12132to every GIMPLE statement, but those were moved into the base structure 12133to take advantage of holes left by other fields (thus making the 12134structure more compact). The structure takes 4 words (32 bytes) on 64 12135bit hosts: 12136 12137Field Size (bits) 12138'code' 8 12139'subcode' 16 12140'no_warning' 1 12141'visited' 1 12142'nontemporal_move' 1 12143'plf' 2 12144'modified' 1 12145'has_volatile_ops' 1 12146'references_memory_p' 1 12147'uid' 32 12148'location' 32 12149'num_ops' 32 12150'bb' 64 12151'block' 63 12152Total size 32 bytes 12153 12154 * 'code' Main identifier for a GIMPLE instruction. 12155 12156 * 'subcode' Used to distinguish different variants of the same basic 12157 instruction or provide flags applicable to a given code. The 12158 'subcode' flags field has different uses depending on the code of 12159 the instruction, but mostly it distinguishes instructions of the 12160 same family. The most prominent use of this field is in 12161 assignments, where subcode indicates the operation done on the RHS 12162 of the assignment. For example, a = b + c is encoded as 12163 'GIMPLE_ASSIGN <PLUS_EXPR, a, b, c>'. 12164 12165 * 'no_warning' Bitflag to indicate whether a warning has already been 12166 issued on this statement. 12167 12168 * 'visited' General purpose "visited" marker. Set and cleared by 12169 each pass when needed. 12170 12171 * 'nontemporal_move' Bitflag used in assignments that represent 12172 non-temporal moves. Although this bitflag is only used in 12173 assignments, it was moved into the base to take advantage of the 12174 bit holes left by the previous fields. 12175 12176 * 'plf' Pass Local Flags. This 2-bit mask can be used as general 12177 purpose markers by any pass. Passes are responsible for clearing 12178 and setting these two flags accordingly. 12179 12180 * 'modified' Bitflag to indicate whether the statement has been 12181 modified. Used mainly by the operand scanner to determine when to 12182 re-scan a statement for operands. 12183 12184 * 'has_volatile_ops' Bitflag to indicate whether this statement 12185 contains operands that have been marked volatile. 12186 12187 * 'references_memory_p' Bitflag to indicate whether this statement 12188 contains memory references (i.e., its operands are either global 12189 variables, or pointer dereferences or anything that must reside in 12190 memory). 12191 12192 * 'uid' This is an unsigned integer used by passes that want to 12193 assign IDs to every statement. These IDs must be assigned and used 12194 by each pass. 12195 12196 * 'location' This is a 'location_t' identifier to specify source code 12197 location for this statement. It is inherited from the front end. 12198 12199 * 'num_ops' Number of operands that this statement has. This 12200 specifies the size of the operand vector embedded in the tuple. 12201 Only used in some tuples, but it is declared in the base tuple to 12202 take advantage of the 32-bit hole left by the previous fields. 12203 12204 * 'bb' Basic block holding the instruction. 12205 12206 * 'block' Lexical block holding this statement. Also used for debug 12207 information generation. 12208 1220912.1.2 'gimple_statement_with_ops' 12210---------------------------------- 12211 12212This tuple is actually split in two: 'gimple_statement_with_ops_base' 12213and 'gimple_statement_with_ops'. This is needed to accommodate the way 12214the operand vector is allocated. The operand vector is defined to be an 12215array of 1 element. So, to allocate a dynamic number of operands, the 12216memory allocator ('gimple_alloc') simply allocates enough memory to hold 12217the structure itself plus 'N - 1' operands which run "off the end" of 12218the structure. For example, to allocate space for a tuple with 3 12219operands, 'gimple_alloc' reserves 'sizeof (struct 12220gimple_statement_with_ops) + 2 * sizeof (tree)' bytes. 12221 12222 On the other hand, several fields in this tuple need to be shared with 12223the 'gimple_statement_with_memory_ops' tuple. So, these common fields 12224are placed in 'gimple_statement_with_ops_base' which is then inherited 12225from the other two tuples. 12226 12227'gsbase' 256 12228'def_ops' 64 12229'use_ops' 64 12230'op' 'num_ops' * 64 12231Total 48 + 8 * 'num_ops' bytes 12232size 12233 12234 * 'gsbase' Inherited from 'struct gimple'. 12235 12236 * 'def_ops' Array of pointers into the operand array indicating all 12237 the slots that contain a variable written-to by the statement. 12238 This array is also used for immediate use chaining. Note that it 12239 would be possible to not rely on this array, but the changes 12240 required to implement this are pretty invasive. 12241 12242 * 'use_ops' Similar to 'def_ops' but for variables read by the 12243 statement. 12244 12245 * 'op' Array of trees with 'num_ops' slots. 12246 1224712.1.3 'gimple_statement_with_memory_ops' 12248----------------------------------------- 12249 12250This tuple is essentially identical to 'gimple_statement_with_ops', 12251except that it contains 4 additional fields to hold vectors related 12252memory stores and loads. Similar to the previous case, the structure is 12253split in two to accommodate for the operand vector 12254('gimple_statement_with_memory_ops_base' and 12255'gimple_statement_with_memory_ops'). 12256 12257Field Size (bits) 12258'gsbase' 256 12259'def_ops' 64 12260'use_ops' 64 12261'vdef_ops' 64 12262'vuse_ops' 64 12263'stores' 64 12264'loads' 64 12265'op' 'num_ops' * 64 12266Total size 80 + 8 * 'num_ops' bytes 12267 12268 * 'vdef_ops' Similar to 'def_ops' but for 'VDEF' operators. There is 12269 one entry per memory symbol written by this statement. This is 12270 used to maintain the memory SSA use-def and def-def chains. 12271 12272 * 'vuse_ops' Similar to 'use_ops' but for 'VUSE' operators. There is 12273 one entry per memory symbol loaded by this statement. This is used 12274 to maintain the memory SSA use-def chains. 12275 12276 * 'stores' Bitset with all the UIDs for the symbols written-to by the 12277 statement. This is different than 'vdef_ops' in that all the 12278 affected symbols are mentioned in this set. If memory partitioning 12279 is enabled, the 'vdef_ops' vector will refer to memory partitions. 12280 Furthermore, no SSA information is stored in this set. 12281 12282 * 'loads' Similar to 'stores', but for memory loads. (Note that 12283 there is some amount of redundancy here, it should be possible to 12284 reduce memory utilization further by removing these sets). 12285 12286 All the other tuples are defined in terms of these three basic ones. 12287Each tuple will add some fields. 12288 12289 12290File: gccint.info, Node: Class hierarchy of GIMPLE statements, Next: GIMPLE instruction set, Prev: Tuple representation, Up: GIMPLE 12291 1229212.2 Class hierarchy of GIMPLE statements 12293========================================= 12294 12295The following diagram shows the C++ inheritance hierarchy of statement 12296kinds, along with their relationships to 'GSS_' values (layouts) and 12297'GIMPLE_' values (codes): 12298 12299 gimple 12300 | layout: GSS_BASE 12301 | used for 4 codes: GIMPLE_ERROR_MARK 12302 | GIMPLE_NOP 12303 | GIMPLE_OMP_SECTIONS_SWITCH 12304 | GIMPLE_PREDICT 12305 | 12306 + gimple_statement_with_ops_base 12307 | | (no GSS layout) 12308 | | 12309 | + gimple_statement_with_ops 12310 | | | layout: GSS_WITH_OPS 12311 | | | 12312 | | + gcond 12313 | | | code: GIMPLE_COND 12314 | | | 12315 | | + gdebug 12316 | | | code: GIMPLE_DEBUG 12317 | | | 12318 | | + ggoto 12319 | | | code: GIMPLE_GOTO 12320 | | | 12321 | | + glabel 12322 | | | code: GIMPLE_LABEL 12323 | | | 12324 | | + gswitch 12325 | | code: GIMPLE_SWITCH 12326 | | 12327 | + gimple_statement_with_memory_ops_base 12328 | | layout: GSS_WITH_MEM_OPS_BASE 12329 | | 12330 | + gimple_statement_with_memory_ops 12331 | | | layout: GSS_WITH_MEM_OPS 12332 | | | 12333 | | + gassign 12334 | | | code GIMPLE_ASSIGN 12335 | | | 12336 | | + greturn 12337 | | code GIMPLE_RETURN 12338 | | 12339 | + gcall 12340 | | layout: GSS_CALL, code: GIMPLE_CALL 12341 | | 12342 | + gasm 12343 | | layout: GSS_ASM, code: GIMPLE_ASM 12344 | | 12345 | + gtransaction 12346 | layout: GSS_TRANSACTION, code: GIMPLE_TRANSACTION 12347 | 12348 + gimple_statement_omp 12349 | | layout: GSS_OMP. Used for code GIMPLE_OMP_SECTION 12350 | | 12351 | + gomp_critical 12352 | | layout: GSS_OMP_CRITICAL, code: GIMPLE_OMP_CRITICAL 12353 | | 12354 | + gomp_for 12355 | | layout: GSS_OMP_FOR, code: GIMPLE_OMP_FOR 12356 | | 12357 | + gomp_parallel_layout 12358 | | | layout: GSS_OMP_PARALLEL_LAYOUT 12359 | | | 12360 | | + gimple_statement_omp_taskreg 12361 | | | | 12362 | | | + gomp_parallel 12363 | | | | code: GIMPLE_OMP_PARALLEL 12364 | | | | 12365 | | | + gomp_task 12366 | | | code: GIMPLE_OMP_TASK 12367 | | | 12368 | | + gimple_statement_omp_target 12369 | | code: GIMPLE_OMP_TARGET 12370 | | 12371 | + gomp_sections 12372 | | layout: GSS_OMP_SECTIONS, code: GIMPLE_OMP_SECTIONS 12373 | | 12374 | + gimple_statement_omp_single_layout 12375 | | layout: GSS_OMP_SINGLE_LAYOUT 12376 | | 12377 | + gomp_single 12378 | | code: GIMPLE_OMP_SINGLE 12379 | | 12380 | + gomp_teams 12381 | code: GIMPLE_OMP_TEAMS 12382 | 12383 + gbind 12384 | layout: GSS_BIND, code: GIMPLE_BIND 12385 | 12386 + gcatch 12387 | layout: GSS_CATCH, code: GIMPLE_CATCH 12388 | 12389 + geh_filter 12390 | layout: GSS_EH_FILTER, code: GIMPLE_EH_FILTER 12391 | 12392 + geh_else 12393 | layout: GSS_EH_ELSE, code: GIMPLE_EH_ELSE 12394 | 12395 + geh_mnt 12396 | layout: GSS_EH_MNT, code: GIMPLE_EH_MUST_NOT_THROW 12397 | 12398 + gphi 12399 | layout: GSS_PHI, code: GIMPLE_PHI 12400 | 12401 + gimple_statement_eh_ctrl 12402 | | layout: GSS_EH_CTRL 12403 | | 12404 | + gresx 12405 | | code: GIMPLE_RESX 12406 | | 12407 | + geh_dispatch 12408 | code: GIMPLE_EH_DISPATCH 12409 | 12410 + gtry 12411 | layout: GSS_TRY, code: GIMPLE_TRY 12412 | 12413 + gimple_statement_wce 12414 | layout: GSS_WCE, code: GIMPLE_WITH_CLEANUP_EXPR 12415 | 12416 + gomp_continue 12417 | layout: GSS_OMP_CONTINUE, code: GIMPLE_OMP_CONTINUE 12418 | 12419 + gomp_atomic_load 12420 | layout: GSS_OMP_ATOMIC_LOAD, code: GIMPLE_OMP_ATOMIC_LOAD 12421 | 12422 + gimple_statement_omp_atomic_store_layout 12423 | layout: GSS_OMP_ATOMIC_STORE_LAYOUT, 12424 | code: GIMPLE_OMP_ATOMIC_STORE 12425 | 12426 + gomp_atomic_store 12427 | code: GIMPLE_OMP_ATOMIC_STORE 12428 | 12429 + gomp_return 12430 code: GIMPLE_OMP_RETURN 12431 12432 12433File: gccint.info, Node: GIMPLE instruction set, Next: GIMPLE Exception Handling, Prev: Class hierarchy of GIMPLE statements, Up: GIMPLE 12434 1243512.3 GIMPLE instruction set 12436=========================== 12437 12438The following table briefly describes the GIMPLE instruction set. 12439 12440Instruction High GIMPLE Low GIMPLE 12441'GIMPLE_ASM' x x 12442'GIMPLE_ASSIGN' x x 12443'GIMPLE_BIND' x 12444'GIMPLE_CALL' x x 12445'GIMPLE_CATCH' x 12446'GIMPLE_COND' x x 12447'GIMPLE_DEBUG' x x 12448'GIMPLE_EH_FILTER' x 12449'GIMPLE_GOTO' x x 12450'GIMPLE_LABEL' x x 12451'GIMPLE_NOP' x x 12452'GIMPLE_OMP_ATOMIC_LOAD' x x 12453'GIMPLE_OMP_ATOMIC_STORE' x x 12454'GIMPLE_OMP_CONTINUE' x x 12455'GIMPLE_OMP_CRITICAL' x x 12456'GIMPLE_OMP_FOR' x x 12457'GIMPLE_OMP_MASTER' x x 12458'GIMPLE_OMP_ORDERED' x x 12459'GIMPLE_OMP_PARALLEL' x x 12460'GIMPLE_OMP_RETURN' x x 12461'GIMPLE_OMP_SECTION' x x 12462'GIMPLE_OMP_SECTIONS' x x 12463'GIMPLE_OMP_SECTIONS_SWITCH' x x 12464'GIMPLE_OMP_SINGLE' x x 12465'GIMPLE_PHI' x 12466'GIMPLE_RESX' x 12467'GIMPLE_RETURN' x x 12468'GIMPLE_SWITCH' x x 12469'GIMPLE_TRY' x 12470 12471 12472File: gccint.info, Node: GIMPLE Exception Handling, Next: Temporaries, Prev: GIMPLE instruction set, Up: GIMPLE 12473 1247412.4 Exception Handling 12475======================= 12476 12477Other exception handling constructs are represented using 12478'GIMPLE_TRY_CATCH'. 'GIMPLE_TRY_CATCH' has two operands. The first 12479operand is a sequence of statements to execute. If executing these 12480statements does not throw an exception, then the second operand is 12481ignored. Otherwise, if an exception is thrown, then the second operand 12482of the 'GIMPLE_TRY_CATCH' is checked. The second operand may have the 12483following forms: 12484 12485 1. A sequence of statements to execute. When an exception occurs, 12486 these statements are executed, and then the exception is rethrown. 12487 12488 2. A sequence of 'GIMPLE_CATCH' statements. Each 'GIMPLE_CATCH' has a 12489 list of applicable exception types and handler code. If the thrown 12490 exception matches one of the caught types, the associated handler 12491 code is executed. If the handler code falls off the bottom, 12492 execution continues after the original 'GIMPLE_TRY_CATCH'. 12493 12494 3. A 'GIMPLE_EH_FILTER' statement. This has a list of permitted 12495 exception types, and code to handle a match failure. If the thrown 12496 exception does not match one of the allowed types, the associated 12497 match failure code is executed. If the thrown exception does 12498 match, it continues unwinding the stack looking for the next 12499 handler. 12500 12501 Currently throwing an exception is not directly represented in GIMPLE, 12502since it is implemented by calling a function. At some point in the 12503future we will want to add some way to express that the call will throw 12504an exception of a known type. 12505 12506 Just before running the optimizers, the compiler lowers the high-level 12507EH constructs above into a set of 'goto's, magic labels, and EH regions. 12508Continuing to unwind at the end of a cleanup is represented with a 12509'GIMPLE_RESX'. 12510 12511 12512File: gccint.info, Node: Temporaries, Next: Operands, Prev: GIMPLE Exception Handling, Up: GIMPLE 12513 1251412.5 Temporaries 12515================ 12516 12517When gimplification encounters a subexpression that is too complex, it 12518creates a new temporary variable to hold the value of the subexpression, 12519and adds a new statement to initialize it before the current statement. 12520These special temporaries are known as 'expression temporaries', and are 12521allocated using 'get_formal_tmp_var'. The compiler tries to always 12522evaluate identical expressions into the same temporary, to simplify 12523elimination of redundant calculations. 12524 12525 We can only use expression temporaries when we know that it will not be 12526reevaluated before its value is used, and that it will not be otherwise 12527modified(1). Other temporaries can be allocated using 12528'get_initialized_tmp_var' or 'create_tmp_var'. 12529 12530 Currently, an expression like 'a = b + 5' is not reduced any further. 12531We tried converting it to something like 12532 T1 = b + 5; 12533 a = T1; 12534 but this bloated the representation for minimal benefit. However, a 12535variable which must live in memory cannot appear in an expression; its 12536value is explicitly loaded into a temporary first. Similarly, storing 12537the value of an expression to a memory variable goes through a 12538temporary. 12539 12540 ---------- Footnotes ---------- 12541 12542 (1) These restrictions are derived from those in Morgan 4.8. 12543 12544 12545File: gccint.info, Node: Operands, Next: Manipulating GIMPLE statements, Prev: Temporaries, Up: GIMPLE 12546 1254712.6 Operands 12548============= 12549 12550In general, expressions in GIMPLE consist of an operation and the 12551appropriate number of simple operands; these operands must either be a 12552GIMPLE rvalue ('is_gimple_val'), i.e. a constant or a register variable. 12553More complex operands are factored out into temporaries, so that 12554 a = b + c + d 12555 becomes 12556 T1 = b + c; 12557 a = T1 + d; 12558 12559 The same rule holds for arguments to a 'GIMPLE_CALL'. 12560 12561 The target of an assignment is usually a variable, but can also be a 12562'MEM_REF' or a compound lvalue as described below. 12563 12564* Menu: 12565 12566* Compound Expressions:: 12567* Compound Lvalues:: 12568* Conditional Expressions:: 12569* Logical Operators:: 12570 12571 12572File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: Operands 12573 1257412.6.1 Compound Expressions 12575--------------------------- 12576 12577The left-hand side of a C comma expression is simply moved into a 12578separate statement. 12579 12580 12581File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: Operands 12582 1258312.6.2 Compound Lvalues 12584----------------------- 12585 12586Currently compound lvalues involving array and structure field 12587references are not broken down; an expression like 'a.b[2] = 42' is not 12588reduced any further (though complex array subscripts are). This 12589restriction is a workaround for limitations in later optimizers; if we 12590were to convert this to 12591 12592 T1 = &a.b; 12593 T1[2] = 42; 12594 12595 alias analysis would not remember that the reference to 'T1[2]' came by 12596way of 'a.b', so it would think that the assignment could alias another 12597member of 'a'; this broke 'struct-alias-1.c'. Future optimizer 12598improvements may make this limitation unnecessary. 12599 12600 12601File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: Operands 12602 1260312.6.3 Conditional Expressions 12604------------------------------ 12605 12606A C '?:' expression is converted into an 'if' statement with each branch 12607assigning to the same temporary. So, 12608 12609 a = b ? c : d; 12610 becomes 12611 if (b == 1) 12612 T1 = c; 12613 else 12614 T1 = d; 12615 a = T1; 12616 12617 The GIMPLE level if-conversion pass re-introduces '?:' expression, if 12618appropriate. It is used to vectorize loops with conditions using vector 12619conditional operations. 12620 12621 Note that in GIMPLE, 'if' statements are represented using 12622'GIMPLE_COND', as described below. 12623 12624 12625File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: Operands 12626 1262712.6.4 Logical Operators 12628------------------------ 12629 12630Except when they appear in the condition operand of a 'GIMPLE_COND', 12631logical 'and' and 'or' operators are simplified as follows: 'a = b && c' 12632becomes 12633 12634 T1 = (bool)b; 12635 if (T1 == true) 12636 T1 = (bool)c; 12637 a = T1; 12638 12639 Note that 'T1' in this example cannot be an expression temporary, 12640because it has two different assignments. 12641 1264212.6.5 Manipulating operands 12643---------------------------- 12644 12645All gimple operands are of type 'tree'. But only certain types of trees 12646are allowed to be used as operand tuples. Basic validation is 12647controlled by the function 'get_gimple_rhs_class', which given a tree 12648code, returns an 'enum' with the following values of type 'enum 12649gimple_rhs_class' 12650 12651 * 'GIMPLE_INVALID_RHS' The tree cannot be used as a GIMPLE operand. 12652 12653 * 'GIMPLE_TERNARY_RHS' The tree is a valid GIMPLE ternary operation. 12654 12655 * 'GIMPLE_BINARY_RHS' The tree is a valid GIMPLE binary operation. 12656 12657 * 'GIMPLE_UNARY_RHS' The tree is a valid GIMPLE unary operation. 12658 12659 * 'GIMPLE_SINGLE_RHS' The tree is a single object, that cannot be 12660 split into simpler operands (for instance, 'SSA_NAME', 'VAR_DECL', 12661 'COMPONENT_REF', etc). 12662 12663 This operand class also acts as an escape hatch for tree nodes that 12664 may be flattened out into the operand vector, but would need more 12665 than two slots on the RHS. For instance, a 'COND_EXPR' expression 12666 of the form '(a op b) ? x : y' could be flattened out on the 12667 operand vector using 4 slots, but it would also require additional 12668 processing to distinguish 'c = a op b' from 'c = a op b ? x : y'. 12669 Something similar occurs with 'ASSERT_EXPR'. In time, these 12670 special case tree expressions should be flattened into the operand 12671 vector. 12672 12673 For tree nodes in the categories 'GIMPLE_TERNARY_RHS', 12674'GIMPLE_BINARY_RHS' and 'GIMPLE_UNARY_RHS', they cannot be stored inside 12675tuples directly. They first need to be flattened and separated into 12676individual components. For instance, given the GENERIC expression 12677 12678 a = b + c 12679 12680 its tree representation is: 12681 12682 MODIFY_EXPR <VAR_DECL <a>, PLUS_EXPR <VAR_DECL <b>, VAR_DECL <c>>> 12683 12684 In this case, the GIMPLE form for this statement is logically identical 12685to its GENERIC form but in GIMPLE, the 'PLUS_EXPR' on the RHS of the 12686assignment is not represented as a tree, instead the two operands are 12687taken out of the 'PLUS_EXPR' sub-tree and flattened into the GIMPLE 12688tuple as follows: 12689 12690 GIMPLE_ASSIGN <PLUS_EXPR, VAR_DECL <a>, VAR_DECL <b>, VAR_DECL <c>> 12691 1269212.6.6 Operand vector allocation 12693-------------------------------- 12694 12695The operand vector is stored at the bottom of the three tuple structures 12696that accept operands. This means, that depending on the code of a given 12697statement, its operand vector will be at different offsets from the base 12698of the structure. To access tuple operands use the following accessors 12699 12700 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 12701 Returns the number of operands in statement G. 12702 12703 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 12704 Returns operand 'I' from statement 'G'. 12705 12706 -- GIMPLE function: tree * gimple_ops (gimple g) 12707 Returns a pointer into the operand vector for statement 'G'. This 12708 is computed using an internal table called 'gimple_ops_offset_'[]. 12709 This table is indexed by the gimple code of 'G'. 12710 12711 When the compiler is built, this table is filled-in using the sizes 12712 of the structures used by each statement code defined in 12713 gimple.def. Since the operand vector is at the bottom of the 12714 structure, for a gimple code 'C' the offset is computed as sizeof 12715 (struct-of 'C') - sizeof (tree). 12716 12717 This mechanism adds one memory indirection to every access when 12718 using 'gimple_op'(), if this becomes a bottleneck, a pass can 12719 choose to memoize the result from 'gimple_ops'() and use that to 12720 access the operands. 12721 1272212.6.7 Operand validation 12723------------------------- 12724 12725When adding a new operand to a gimple statement, the operand will be 12726validated according to what each tuple accepts in its operand vector. 12727These predicates are called by the 'gimple_NAME_set_...()'. Each tuple 12728will use one of the following predicates (Note, this list is not 12729exhaustive): 12730 12731 -- GIMPLE function: bool is_gimple_val (tree t) 12732 Returns true if t is a "GIMPLE value", which are all the 12733 non-addressable stack variables (variables for which 12734 'is_gimple_reg' returns true) and constants (expressions for which 12735 'is_gimple_min_invariant' returns true). 12736 12737 -- GIMPLE function: bool is_gimple_addressable (tree t) 12738 Returns true if t is a symbol or memory reference whose address can 12739 be taken. 12740 12741 -- GIMPLE function: bool is_gimple_asm_val (tree t) 12742 Similar to 'is_gimple_val' but it also accepts hard registers. 12743 12744 -- GIMPLE function: bool is_gimple_call_addr (tree t) 12745 Return true if t is a valid expression to use as the function 12746 called by a 'GIMPLE_CALL'. 12747 12748 -- GIMPLE function: bool is_gimple_mem_ref_addr (tree t) 12749 Return true if t is a valid expression to use as first operand of a 12750 'MEM_REF' expression. 12751 12752 -- GIMPLE function: bool is_gimple_constant (tree t) 12753 Return true if t is a valid gimple constant. 12754 12755 -- GIMPLE function: bool is_gimple_min_invariant (tree t) 12756 Return true if t is a valid minimal invariant. This is different 12757 from constants, in that the specific value of t may not be known at 12758 compile time, but it is known that it doesn't change (e.g., the 12759 address of a function local variable). 12760 12761 -- GIMPLE function: bool is_gimple_ip_invariant (tree t) 12762 Return true if t is an interprocedural invariant. This means that 12763 t is a valid invariant in all functions (e.g. it can be an address 12764 of a global variable but not of a local one). 12765 12766 -- GIMPLE function: bool is_gimple_ip_invariant_address (tree t) 12767 Return true if t is an 'ADDR_EXPR' that does not change once the 12768 program is running (and which is valid in all functions). 12769 1277012.6.8 Statement validation 12771--------------------------- 12772 12773 -- GIMPLE function: bool is_gimple_assign (gimple g) 12774 Return true if the code of g is 'GIMPLE_ASSIGN'. 12775 12776 -- GIMPLE function: bool is_gimple_call (gimple g) 12777 Return true if the code of g is 'GIMPLE_CALL'. 12778 12779 -- GIMPLE function: bool is_gimple_debug (gimple g) 12780 Return true if the code of g is 'GIMPLE_DEBUG'. 12781 12782 -- GIMPLE function: bool gimple_assign_cast_p (const_gimple g) 12783 Return true if g is a 'GIMPLE_ASSIGN' that performs a type cast 12784 operation. 12785 12786 -- GIMPLE function: bool gimple_debug_bind_p (gimple g) 12787 Return true if g is a 'GIMPLE_DEBUG' that binds the value of an 12788 expression to a variable. 12789 12790 -- GIMPLE function: bool is_gimple_omp (gimple g) 12791 Return true if g is any of the OpenMP codes. 12792 12793 -- GIMPLE function: gimple_debug_begin_stmt_p (gimple g) 12794 Return true if g is a 'GIMPLE_DEBUG' that marks the beginning of a 12795 source statement. 12796 12797 -- GIMPLE function: gimple_debug_inline_entry_p (gimple g) 12798 Return true if g is a 'GIMPLE_DEBUG' that marks the entry point of 12799 an inlined function. 12800 12801 -- GIMPLE function: gimple_debug_nonbind_marker_p (gimple g) 12802 Return true if g is a 'GIMPLE_DEBUG' that marks a program location, 12803 without any variable binding. 12804 12805 12806File: gccint.info, Node: Manipulating GIMPLE statements, Next: Tuple specific accessors, Prev: Operands, Up: GIMPLE 12807 1280812.7 Manipulating GIMPLE statements 12809=================================== 12810 12811This section documents all the functions available to handle each of the 12812GIMPLE instructions. 12813 1281412.7.1 Common accessors 12815----------------------- 12816 12817The following are common accessors for gimple statements. 12818 12819 -- GIMPLE function: enum gimple_code gimple_code (gimple g) 12820 Return the code for statement 'G'. 12821 12822 -- GIMPLE function: basic_block gimple_bb (gimple g) 12823 Return the basic block to which statement 'G' belongs to. 12824 12825 -- GIMPLE function: tree gimple_block (gimple g) 12826 Return the lexical scope block holding statement 'G'. 12827 12828 -- GIMPLE function: tree gimple_expr_type (gimple stmt) 12829 Return the type of the main expression computed by 'STMT'. Return 12830 'void_type_node' if 'STMT' computes nothing. This will only return 12831 something meaningful for 'GIMPLE_ASSIGN', 'GIMPLE_COND' and 12832 'GIMPLE_CALL'. For all other tuple codes, it will return 12833 'void_type_node'. 12834 12835 -- GIMPLE function: enum tree_code gimple_expr_code (gimple stmt) 12836 Return the tree code for the expression computed by 'STMT'. This 12837 is only meaningful for 'GIMPLE_CALL', 'GIMPLE_ASSIGN' and 12838 'GIMPLE_COND'. If 'STMT' is 'GIMPLE_CALL', it will return 12839 'CALL_EXPR'. For 'GIMPLE_COND', it returns the code of the 12840 comparison predicate. For 'GIMPLE_ASSIGN' it returns the code of 12841 the operation performed by the 'RHS' of the assignment. 12842 12843 -- GIMPLE function: void gimple_set_block (gimple g, tree block) 12844 Set the lexical scope block of 'G' to 'BLOCK'. 12845 12846 -- GIMPLE function: location_t gimple_locus (gimple g) 12847 Return locus information for statement 'G'. 12848 12849 -- GIMPLE function: void gimple_set_locus (gimple g, location_t locus) 12850 Set locus information for statement 'G'. 12851 12852 -- GIMPLE function: bool gimple_locus_empty_p (gimple g) 12853 Return true if 'G' does not have locus information. 12854 12855 -- GIMPLE function: bool gimple_no_warning_p (gimple stmt) 12856 Return true if no warnings should be emitted for statement 'STMT'. 12857 12858 -- GIMPLE function: void gimple_set_visited (gimple stmt, bool 12859 visited_p) 12860 Set the visited status on statement 'STMT' to 'VISITED_P'. 12861 12862 -- GIMPLE function: bool gimple_visited_p (gimple stmt) 12863 Return the visited status on statement 'STMT'. 12864 12865 -- GIMPLE function: void gimple_set_plf (gimple stmt, enum plf_mask 12866 plf, bool val_p) 12867 Set pass local flag 'PLF' on statement 'STMT' to 'VAL_P'. 12868 12869 -- GIMPLE function: unsigned int gimple_plf (gimple stmt, enum plf_mask 12870 plf) 12871 Return the value of pass local flag 'PLF' on statement 'STMT'. 12872 12873 -- GIMPLE function: bool gimple_has_ops (gimple g) 12874 Return true if statement 'G' has register or memory operands. 12875 12876 -- GIMPLE function: bool gimple_has_mem_ops (gimple g) 12877 Return true if statement 'G' has memory operands. 12878 12879 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 12880 Return the number of operands for statement 'G'. 12881 12882 -- GIMPLE function: tree * gimple_ops (gimple g) 12883 Return the array of operands for statement 'G'. 12884 12885 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 12886 Return operand 'I' for statement 'G'. 12887 12888 -- GIMPLE function: tree * gimple_op_ptr (gimple g, unsigned i) 12889 Return a pointer to operand 'I' for statement 'G'. 12890 12891 -- GIMPLE function: void gimple_set_op (gimple g, unsigned i, tree op) 12892 Set operand 'I' of statement 'G' to 'OP'. 12893 12894 -- GIMPLE function: bitmap gimple_addresses_taken (gimple stmt) 12895 Return the set of symbols that have had their address taken by 12896 'STMT'. 12897 12898 -- GIMPLE function: struct def_optype_d * gimple_def_ops (gimple g) 12899 Return the set of 'DEF' operands for statement 'G'. 12900 12901 -- GIMPLE function: void gimple_set_def_ops (gimple g, struct 12902 def_optype_d *def) 12903 Set 'DEF' to be the set of 'DEF' operands for statement 'G'. 12904 12905 -- GIMPLE function: struct use_optype_d * gimple_use_ops (gimple g) 12906 Return the set of 'USE' operands for statement 'G'. 12907 12908 -- GIMPLE function: void gimple_set_use_ops (gimple g, struct 12909 use_optype_d *use) 12910 Set 'USE' to be the set of 'USE' operands for statement 'G'. 12911 12912 -- GIMPLE function: struct voptype_d * gimple_vuse_ops (gimple g) 12913 Return the set of 'VUSE' operands for statement 'G'. 12914 12915 -- GIMPLE function: void gimple_set_vuse_ops (gimple g, struct 12916 voptype_d *ops) 12917 Set 'OPS' to be the set of 'VUSE' operands for statement 'G'. 12918 12919 -- GIMPLE function: struct voptype_d * gimple_vdef_ops (gimple g) 12920 Return the set of 'VDEF' operands for statement 'G'. 12921 12922 -- GIMPLE function: void gimple_set_vdef_ops (gimple g, struct 12923 voptype_d *ops) 12924 Set 'OPS' to be the set of 'VDEF' operands for statement 'G'. 12925 12926 -- GIMPLE function: bitmap gimple_loaded_syms (gimple g) 12927 Return the set of symbols loaded by statement 'G'. Each element of 12928 the set is the 'DECL_UID' of the corresponding symbol. 12929 12930 -- GIMPLE function: bitmap gimple_stored_syms (gimple g) 12931 Return the set of symbols stored by statement 'G'. Each element of 12932 the set is the 'DECL_UID' of the corresponding symbol. 12933 12934 -- GIMPLE function: bool gimple_modified_p (gimple g) 12935 Return true if statement 'G' has operands and the modified field 12936 has been set. 12937 12938 -- GIMPLE function: bool gimple_has_volatile_ops (gimple stmt) 12939 Return true if statement 'STMT' contains volatile operands. 12940 12941 -- GIMPLE function: void gimple_set_has_volatile_ops (gimple stmt, bool 12942 volatilep) 12943 Return true if statement 'STMT' contains volatile operands. 12944 12945 -- GIMPLE function: void update_stmt (gimple s) 12946 Mark statement 'S' as modified, and update it. 12947 12948 -- GIMPLE function: void update_stmt_if_modified (gimple s) 12949 Update statement 'S' if it has been marked modified. 12950 12951 -- GIMPLE function: gimple gimple_copy (gimple stmt) 12952 Return a deep copy of statement 'STMT'. 12953 12954 12955File: gccint.info, Node: Tuple specific accessors, Next: GIMPLE sequences, Prev: Manipulating GIMPLE statements, Up: GIMPLE 12956 1295712.8 Tuple specific accessors 12958============================= 12959 12960* Menu: 12961 12962* GIMPLE_ASM:: 12963* GIMPLE_ASSIGN:: 12964* GIMPLE_BIND:: 12965* GIMPLE_CALL:: 12966* GIMPLE_CATCH:: 12967* GIMPLE_COND:: 12968* GIMPLE_DEBUG:: 12969* GIMPLE_EH_FILTER:: 12970* GIMPLE_LABEL:: 12971* GIMPLE_GOTO:: 12972* GIMPLE_NOP:: 12973* GIMPLE_OMP_ATOMIC_LOAD:: 12974* GIMPLE_OMP_ATOMIC_STORE:: 12975* GIMPLE_OMP_CONTINUE:: 12976* GIMPLE_OMP_CRITICAL:: 12977* GIMPLE_OMP_FOR:: 12978* GIMPLE_OMP_MASTER:: 12979* GIMPLE_OMP_ORDERED:: 12980* GIMPLE_OMP_PARALLEL:: 12981* GIMPLE_OMP_RETURN:: 12982* GIMPLE_OMP_SECTION:: 12983* GIMPLE_OMP_SECTIONS:: 12984* GIMPLE_OMP_SINGLE:: 12985* GIMPLE_PHI:: 12986* GIMPLE_RESX:: 12987* GIMPLE_RETURN:: 12988* GIMPLE_SWITCH:: 12989* GIMPLE_TRY:: 12990* GIMPLE_WITH_CLEANUP_EXPR:: 12991 12992 12993File: gccint.info, Node: GIMPLE_ASM, Next: GIMPLE_ASSIGN, Up: Tuple specific accessors 12994 1299512.8.1 'GIMPLE_ASM' 12996------------------- 12997 12998 -- GIMPLE function: gasm *gimple_build_asm_vec ( const char *string, 12999 vec<tree, va_gc> *inputs, vec<tree, va_gc> *outputs, vec<tree, 13000 va_gc> *clobbers, vec<tree, va_gc> *labels) 13001 Build a 'GIMPLE_ASM' statement. This statement is used for 13002 building in-line assembly constructs. 'STRING' is the assembly 13003 code. 'INPUTS', 'OUTPUTS', 'CLOBBERS' and 'LABELS' are the inputs, 13004 outputs, clobbered registers and labels. 13005 13006 -- GIMPLE function: unsigned gimple_asm_ninputs (const gasm *g) 13007 Return the number of input operands for 'GIMPLE_ASM' 'G'. 13008 13009 -- GIMPLE function: unsigned gimple_asm_noutputs (const gasm *g) 13010 Return the number of output operands for 'GIMPLE_ASM' 'G'. 13011 13012 -- GIMPLE function: unsigned gimple_asm_nclobbers (const gasm *g) 13013 Return the number of clobber operands for 'GIMPLE_ASM' 'G'. 13014 13015 -- GIMPLE function: tree gimple_asm_input_op (const gasm *g, unsigned 13016 index) 13017 Return input operand 'INDEX' of 'GIMPLE_ASM' 'G'. 13018 13019 -- GIMPLE function: void gimple_asm_set_input_op (gasm *g, unsigned 13020 index, tree in_op) 13021 Set 'IN_OP' to be input operand 'INDEX' in 'GIMPLE_ASM' 'G'. 13022 13023 -- GIMPLE function: tree gimple_asm_output_op (const gasm *g, unsigned 13024 index) 13025 Return output operand 'INDEX' of 'GIMPLE_ASM' 'G'. 13026 13027 -- GIMPLE function: void gimple_asm_set_output_op (gasm *g, unsigned 13028 index, tree out_op) 13029 Set 'OUT_OP' to be output operand 'INDEX' in 'GIMPLE_ASM' 'G'. 13030 13031 -- GIMPLE function: tree gimple_asm_clobber_op (const gasm *g, unsigned 13032 index) 13033 Return clobber operand 'INDEX' of 'GIMPLE_ASM' 'G'. 13034 13035 -- GIMPLE function: void gimple_asm_set_clobber_op (gasm *g, unsigned 13036 index, tree clobber_op) 13037 Set 'CLOBBER_OP' to be clobber operand 'INDEX' in 'GIMPLE_ASM' 'G'. 13038 13039 -- GIMPLE function: const char * gimple_asm_string (const gasm *g) 13040 Return the string representing the assembly instruction in 13041 'GIMPLE_ASM' 'G'. 13042 13043 -- GIMPLE function: bool gimple_asm_volatile_p (const gasm *g) 13044 Return true if 'G' is an asm statement marked volatile. 13045 13046 -- GIMPLE function: void gimple_asm_set_volatile (gasm *g, bool 13047 volatile_p) 13048 Mark asm statement 'G' as volatile or non-volatile based on 13049 'VOLATILE_P'. 13050 13051 13052File: gccint.info, Node: GIMPLE_ASSIGN, Next: GIMPLE_BIND, Prev: GIMPLE_ASM, Up: Tuple specific accessors 13053 1305412.8.2 'GIMPLE_ASSIGN' 13055---------------------- 13056 13057 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, tree rhs) 13058 Build a 'GIMPLE_ASSIGN' statement. The left-hand side is an lvalue 13059 passed in lhs. The right-hand side can be either a unary or binary 13060 tree expression. The expression tree rhs will be flattened and its 13061 operands assigned to the corresponding operand slots in the new 13062 statement. This function is useful when you already have a tree 13063 expression that you want to convert into a tuple. However, try to 13064 avoid building expression trees for the sole purpose of calling 13065 this function. If you already have the operands in separate trees, 13066 it is better to use 'gimple_build_assign' with 'enum tree_code' 13067 argument and separate arguments for each operand. 13068 13069 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 13070 tree_code subcode, tree op1, tree op2, tree op3) 13071 This function is similar to two operand 'gimple_build_assign', but 13072 is used to build a 'GIMPLE_ASSIGN' statement when the operands of 13073 the right-hand side of the assignment are already split into 13074 different operands. 13075 13076 The left-hand side is an lvalue passed in lhs. Subcode is the 13077 'tree_code' for the right-hand side of the assignment. Op1, op2 13078 and op3 are the operands. 13079 13080 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 13081 tree_code subcode, tree op1, tree op2) 13082 Like the above 5 operand 'gimple_build_assign', but with the last 13083 argument 'NULL' - this overload should not be used for 13084 'GIMPLE_TERNARY_RHS' assignments. 13085 13086 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 13087 tree_code subcode, tree op1) 13088 Like the above 4 operand 'gimple_build_assign', but with the last 13089 argument 'NULL' - this overload should be used only for 13090 'GIMPLE_UNARY_RHS' and 'GIMPLE_SINGLE_RHS' assignments. 13091 13092 -- GIMPLE function: gimple gimplify_assign (tree dst, tree src, 13093 gimple_seq *seq_p) 13094 Build a new 'GIMPLE_ASSIGN' tuple and append it to the end of 13095 '*SEQ_P'. 13096 13097 'DST'/'SRC' are the destination and source respectively. You can pass 13098ungimplified trees in 'DST' or 'SRC', in which case they will be 13099converted to a gimple operand if necessary. 13100 13101 This function returns the newly created 'GIMPLE_ASSIGN' tuple. 13102 13103 -- GIMPLE function: enum tree_code gimple_assign_rhs_code (gimple g) 13104 Return the code of the expression computed on the 'RHS' of 13105 assignment statement 'G'. 13106 13107 -- GIMPLE function: enum gimple_rhs_class gimple_assign_rhs_class 13108 (gimple g) 13109 Return the gimple rhs class of the code for the expression computed 13110 on the rhs of assignment statement 'G'. This will never return 13111 'GIMPLE_INVALID_RHS'. 13112 13113 -- GIMPLE function: tree gimple_assign_lhs (gimple g) 13114 Return the 'LHS' of assignment statement 'G'. 13115 13116 -- GIMPLE function: tree * gimple_assign_lhs_ptr (gimple g) 13117 Return a pointer to the 'LHS' of assignment statement 'G'. 13118 13119 -- GIMPLE function: tree gimple_assign_rhs1 (gimple g) 13120 Return the first operand on the 'RHS' of assignment statement 'G'. 13121 13122 -- GIMPLE function: tree * gimple_assign_rhs1_ptr (gimple g) 13123 Return the address of the first operand on the 'RHS' of assignment 13124 statement 'G'. 13125 13126 -- GIMPLE function: tree gimple_assign_rhs2 (gimple g) 13127 Return the second operand on the 'RHS' of assignment statement 'G'. 13128 13129 -- GIMPLE function: tree * gimple_assign_rhs2_ptr (gimple g) 13130 Return the address of the second operand on the 'RHS' of assignment 13131 statement 'G'. 13132 13133 -- GIMPLE function: tree gimple_assign_rhs3 (gimple g) 13134 Return the third operand on the 'RHS' of assignment statement 'G'. 13135 13136 -- GIMPLE function: tree * gimple_assign_rhs3_ptr (gimple g) 13137 Return the address of the third operand on the 'RHS' of assignment 13138 statement 'G'. 13139 13140 -- GIMPLE function: void gimple_assign_set_lhs (gimple g, tree lhs) 13141 Set 'LHS' to be the 'LHS' operand of assignment statement 'G'. 13142 13143 -- GIMPLE function: void gimple_assign_set_rhs1 (gimple g, tree rhs) 13144 Set 'RHS' to be the first operand on the 'RHS' of assignment 13145 statement 'G'. 13146 13147 -- GIMPLE function: void gimple_assign_set_rhs2 (gimple g, tree rhs) 13148 Set 'RHS' to be the second operand on the 'RHS' of assignment 13149 statement 'G'. 13150 13151 -- GIMPLE function: void gimple_assign_set_rhs3 (gimple g, tree rhs) 13152 Set 'RHS' to be the third operand on the 'RHS' of assignment 13153 statement 'G'. 13154 13155 -- GIMPLE function: bool gimple_assign_cast_p (const_gimple s) 13156 Return true if 'S' is a type-cast assignment. 13157 13158 13159File: gccint.info, Node: GIMPLE_BIND, Next: GIMPLE_CALL, Prev: GIMPLE_ASSIGN, Up: Tuple specific accessors 13160 1316112.8.3 'GIMPLE_BIND' 13162-------------------- 13163 13164 -- GIMPLE function: gbind *gimple_build_bind (tree vars, gimple_seq 13165 body) 13166 Build a 'GIMPLE_BIND' statement with a list of variables in 'VARS' 13167 and a body of statements in sequence 'BODY'. 13168 13169 -- GIMPLE function: tree gimple_bind_vars (const gbind *g) 13170 Return the variables declared in the 'GIMPLE_BIND' statement 'G'. 13171 13172 -- GIMPLE function: void gimple_bind_set_vars (gbind *g, tree vars) 13173 Set 'VARS' to be the set of variables declared in the 'GIMPLE_BIND' 13174 statement 'G'. 13175 13176 -- GIMPLE function: void gimple_bind_append_vars (gbind *g, tree vars) 13177 Append 'VARS' to the set of variables declared in the 'GIMPLE_BIND' 13178 statement 'G'. 13179 13180 -- GIMPLE function: gimple_seq gimple_bind_body (gbind *g) 13181 Return the GIMPLE sequence contained in the 'GIMPLE_BIND' statement 13182 'G'. 13183 13184 -- GIMPLE function: void gimple_bind_set_body (gbind *g, gimple_seq 13185 seq) 13186 Set 'SEQ' to be sequence contained in the 'GIMPLE_BIND' statement 13187 'G'. 13188 13189 -- GIMPLE function: void gimple_bind_add_stmt (gbind *gs, gimple stmt) 13190 Append a statement to the end of a 'GIMPLE_BIND''s body. 13191 13192 -- GIMPLE function: void gimple_bind_add_seq (gbind *gs, gimple_seq 13193 seq) 13194 Append a sequence of statements to the end of a 'GIMPLE_BIND''s 13195 body. 13196 13197 -- GIMPLE function: tree gimple_bind_block (const gbind *g) 13198 Return the 'TREE_BLOCK' node associated with 'GIMPLE_BIND' 13199 statement 'G'. This is analogous to the 'BIND_EXPR_BLOCK' field in 13200 trees. 13201 13202 -- GIMPLE function: void gimple_bind_set_block (gbind *g, tree block) 13203 Set 'BLOCK' to be the 'TREE_BLOCK' node associated with 13204 'GIMPLE_BIND' statement 'G'. 13205 13206 13207File: gccint.info, Node: GIMPLE_CALL, Next: GIMPLE_CATCH, Prev: GIMPLE_BIND, Up: Tuple specific accessors 13208 1320912.8.4 'GIMPLE_CALL' 13210-------------------- 13211 13212 -- GIMPLE function: gcall *gimple_build_call (tree fn, unsigned nargs, 13213 ...) 13214 Build a 'GIMPLE_CALL' statement to function 'FN'. The argument 13215 'FN' must be either a 'FUNCTION_DECL' or a gimple call address as 13216 determined by 'is_gimple_call_addr'. 'NARGS' are the number of 13217 arguments. The rest of the arguments follow the argument 'NARGS', 13218 and must be trees that are valid as rvalues in gimple (i.e., each 13219 operand is validated with 'is_gimple_operand'). 13220 13221 -- GIMPLE function: gcall *gimple_build_call_from_tree (tree call_expr, 13222 tree fnptrtype) 13223 Build a 'GIMPLE_CALL' from a 'CALL_EXPR' node. The arguments and 13224 the function are taken from the expression directly. The type of 13225 the 'GIMPLE_CALL' is set from the second parameter passed by a 13226 caller. This routine assumes that 'call_expr' is already in GIMPLE 13227 form. That is, its operands are GIMPLE values and the function 13228 call needs no further simplification. All the call flags in 13229 'call_expr' are copied over to the new 'GIMPLE_CALL'. 13230 13231 -- GIMPLE function: gcall *gimple_build_call_vec (tree fn, 'vec<tree>' 13232 args) 13233 Identical to 'gimple_build_call' but the arguments are stored in a 13234 'vec<tree>'. 13235 13236 -- GIMPLE function: tree gimple_call_lhs (gimple g) 13237 Return the 'LHS' of call statement 'G'. 13238 13239 -- GIMPLE function: tree * gimple_call_lhs_ptr (gimple g) 13240 Return a pointer to the 'LHS' of call statement 'G'. 13241 13242 -- GIMPLE function: void gimple_call_set_lhs (gimple g, tree lhs) 13243 Set 'LHS' to be the 'LHS' operand of call statement 'G'. 13244 13245 -- GIMPLE function: tree gimple_call_fn (gimple g) 13246 Return the tree node representing the function called by call 13247 statement 'G'. 13248 13249 -- GIMPLE function: void gimple_call_set_fn (gcall *g, tree fn) 13250 Set 'FN' to be the function called by call statement 'G'. This has 13251 to be a gimple value specifying the address of the called function. 13252 13253 -- GIMPLE function: tree gimple_call_fndecl (gimple g) 13254 If a given 'GIMPLE_CALL''s callee is a 'FUNCTION_DECL', return it. 13255 Otherwise return 'NULL'. This function is analogous to 13256 'get_callee_fndecl' in 'GENERIC'. 13257 13258 -- GIMPLE function: tree gimple_call_set_fndecl (gimple g, tree fndecl) 13259 Set the called function to 'FNDECL'. 13260 13261 -- GIMPLE function: tree gimple_call_return_type (const gcall *g) 13262 Return the type returned by call statement 'G'. 13263 13264 -- GIMPLE function: tree gimple_call_chain (gimple g) 13265 Return the static chain for call statement 'G'. 13266 13267 -- GIMPLE function: void gimple_call_set_chain (gcall *g, tree chain) 13268 Set 'CHAIN' to be the static chain for call statement 'G'. 13269 13270 -- GIMPLE function: unsigned gimple_call_num_args (gimple g) 13271 Return the number of arguments used by call statement 'G'. 13272 13273 -- GIMPLE function: tree gimple_call_arg (gimple g, unsigned index) 13274 Return the argument at position 'INDEX' for call statement 'G'. 13275 The first argument is 0. 13276 13277 -- GIMPLE function: tree * gimple_call_arg_ptr (gimple g, unsigned 13278 index) 13279 Return a pointer to the argument at position 'INDEX' for call 13280 statement 'G'. 13281 13282 -- GIMPLE function: void gimple_call_set_arg (gimple g, unsigned index, 13283 tree arg) 13284 Set 'ARG' to be the argument at position 'INDEX' for call statement 13285 'G'. 13286 13287 -- GIMPLE function: void gimple_call_set_tail (gcall *s) 13288 Mark call statement 'S' as being a tail call (i.e., a call just 13289 before the exit of a function). These calls are candidate for tail 13290 call optimization. 13291 13292 -- GIMPLE function: bool gimple_call_tail_p (gcall *s) 13293 Return true if 'GIMPLE_CALL' 'S' is marked as a tail call. 13294 13295 -- GIMPLE function: bool gimple_call_noreturn_p (gimple s) 13296 Return true if 'S' is a noreturn call. 13297 13298 -- GIMPLE function: gimple gimple_call_copy_skip_args (gcall *stmt, 13299 bitmap args_to_skip) 13300 Build a 'GIMPLE_CALL' identical to 'STMT' but skipping the 13301 arguments in the positions marked by the set 'ARGS_TO_SKIP'. 13302 13303 13304File: gccint.info, Node: GIMPLE_CATCH, Next: GIMPLE_COND, Prev: GIMPLE_CALL, Up: Tuple specific accessors 13305 1330612.8.5 'GIMPLE_CATCH' 13307--------------------- 13308 13309 -- GIMPLE function: gcatch *gimple_build_catch (tree types, gimple_seq 13310 handler) 13311 Build a 'GIMPLE_CATCH' statement. 'TYPES' are the tree types this 13312 catch handles. 'HANDLER' is a sequence of statements with the code 13313 for the handler. 13314 13315 -- GIMPLE function: tree gimple_catch_types (const gcatch *g) 13316 Return the types handled by 'GIMPLE_CATCH' statement 'G'. 13317 13318 -- GIMPLE function: tree * gimple_catch_types_ptr (gcatch *g) 13319 Return a pointer to the types handled by 'GIMPLE_CATCH' statement 13320 'G'. 13321 13322 -- GIMPLE function: gimple_seq gimple_catch_handler (gcatch *g) 13323 Return the GIMPLE sequence representing the body of the handler of 13324 'GIMPLE_CATCH' statement 'G'. 13325 13326 -- GIMPLE function: void gimple_catch_set_types (gcatch *g, tree t) 13327 Set 'T' to be the set of types handled by 'GIMPLE_CATCH' 'G'. 13328 13329 -- GIMPLE function: void gimple_catch_set_handler (gcatch *g, 13330 gimple_seq handler) 13331 Set 'HANDLER' to be the body of 'GIMPLE_CATCH' 'G'. 13332 13333 13334File: gccint.info, Node: GIMPLE_COND, Next: GIMPLE_DEBUG, Prev: GIMPLE_CATCH, Up: Tuple specific accessors 13335 1333612.8.6 'GIMPLE_COND' 13337-------------------- 13338 13339 -- GIMPLE function: gcond *gimple_build_cond ( enum tree_code 13340 pred_code, tree lhs, tree rhs, tree t_label, tree f_label) 13341 Build a 'GIMPLE_COND' statement. 'A' 'GIMPLE_COND' statement 13342 compares 'LHS' and 'RHS' and if the condition in 'PRED_CODE' is 13343 true, jump to the label in 't_label', otherwise jump to the label 13344 in 'f_label'. 'PRED_CODE' are relational operator tree codes like 13345 'EQ_EXPR', 'LT_EXPR', 'LE_EXPR', 'NE_EXPR', etc. 13346 13347 -- GIMPLE function: gcond *gimple_build_cond_from_tree (tree cond, tree 13348 t_label, tree f_label) 13349 Build a 'GIMPLE_COND' statement from the conditional expression 13350 tree 'COND'. 'T_LABEL' and 'F_LABEL' are as in 13351 'gimple_build_cond'. 13352 13353 -- GIMPLE function: enum tree_code gimple_cond_code (gimple g) 13354 Return the code of the predicate computed by conditional statement 13355 'G'. 13356 13357 -- GIMPLE function: void gimple_cond_set_code (gcond *g, enum tree_code 13358 code) 13359 Set 'CODE' to be the predicate code for the conditional statement 13360 'G'. 13361 13362 -- GIMPLE function: tree gimple_cond_lhs (gimple g) 13363 Return the 'LHS' of the predicate computed by conditional statement 13364 'G'. 13365 13366 -- GIMPLE function: void gimple_cond_set_lhs (gcond *g, tree lhs) 13367 Set 'LHS' to be the 'LHS' operand of the predicate computed by 13368 conditional statement 'G'. 13369 13370 -- GIMPLE function: tree gimple_cond_rhs (gimple g) 13371 Return the 'RHS' operand of the predicate computed by conditional 13372 'G'. 13373 13374 -- GIMPLE function: void gimple_cond_set_rhs (gcond *g, tree rhs) 13375 Set 'RHS' to be the 'RHS' operand of the predicate computed by 13376 conditional statement 'G'. 13377 13378 -- GIMPLE function: tree gimple_cond_true_label (const gcond *g) 13379 Return the label used by conditional statement 'G' when its 13380 predicate evaluates to true. 13381 13382 -- GIMPLE function: void gimple_cond_set_true_label (gcond *g, tree 13383 label) 13384 Set 'LABEL' to be the label used by conditional statement 'G' when 13385 its predicate evaluates to true. 13386 13387 -- GIMPLE function: void gimple_cond_set_false_label (gcond *g, tree 13388 label) 13389 Set 'LABEL' to be the label used by conditional statement 'G' when 13390 its predicate evaluates to false. 13391 13392 -- GIMPLE function: tree gimple_cond_false_label (const gcond *g) 13393 Return the label used by conditional statement 'G' when its 13394 predicate evaluates to false. 13395 13396 -- GIMPLE function: void gimple_cond_make_false (gcond *g) 13397 Set the conditional 'COND_STMT' to be of the form 'if (1 == 0)'. 13398 13399 -- GIMPLE function: void gimple_cond_make_true (gcond *g) 13400 Set the conditional 'COND_STMT' to be of the form 'if (1 == 1)'. 13401 13402 13403File: gccint.info, Node: GIMPLE_DEBUG, Next: GIMPLE_EH_FILTER, Prev: GIMPLE_COND, Up: Tuple specific accessors 13404 1340512.8.7 'GIMPLE_DEBUG' 13406--------------------- 13407 13408 -- GIMPLE function: gdebug *gimple_build_debug_bind (tree var, tree 13409 value, gimple stmt) 13410 Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_BIND' 13411 'subcode'. The effect of this statement is to tell debug 13412 information generation machinery that the value of user variable 13413 'var' is given by 'value' at that point, and to remain with that 13414 value until 'var' runs out of scope, a dynamically-subsequent debug 13415 bind statement overrides the binding, or conflicting values reach a 13416 control flow merge point. Even if components of the 'value' 13417 expression change afterwards, the variable is supposed to retain 13418 the same value, though not necessarily the same location. 13419 13420 It is expected that 'var' be most often a tree for automatic user 13421 variables ('VAR_DECL' or 'PARM_DECL') that satisfy the requirements 13422 for gimple registers, but it may also be a tree for a scalarized 13423 component of a user variable ('ARRAY_REF', 'COMPONENT_REF'), or a 13424 debug temporary ('DEBUG_EXPR_DECL'). 13425 13426 As for 'value', it can be an arbitrary tree expression, but it is 13427 recommended that it be in a suitable form for a gimple assignment 13428 'RHS'. It is not expected that user variables that could appear as 13429 'var' ever appear in 'value', because in the latter we'd have their 13430 'SSA_NAME's instead, but even if they were not in SSA form, user 13431 variables appearing in 'value' are to be regarded as part of the 13432 executable code space, whereas those in 'var' are to be regarded as 13433 part of the source code space. There is no way to refer to the 13434 value bound to a user variable within a 'value' expression. 13435 13436 If 'value' is 'GIMPLE_DEBUG_BIND_NOVALUE', debug information 13437 generation machinery is informed that the variable 'var' is 13438 unbound, i.e., that its value is indeterminate, which sometimes 13439 means it is really unavailable, and other times that the compiler 13440 could not keep track of it. 13441 13442 Block and location information for the newly-created stmt are taken 13443 from 'stmt', if given. 13444 13445 -- GIMPLE function: tree gimple_debug_bind_get_var (gimple stmt) 13446 Return the user variable VAR that is bound at 'stmt'. 13447 13448 -- GIMPLE function: tree gimple_debug_bind_get_value (gimple stmt) 13449 Return the value expression that is bound to a user variable at 13450 'stmt'. 13451 13452 -- GIMPLE function: tree * gimple_debug_bind_get_value_ptr (gimple 13453 stmt) 13454 Return a pointer to the value expression that is bound to a user 13455 variable at 'stmt'. 13456 13457 -- GIMPLE function: void gimple_debug_bind_set_var (gimple stmt, tree 13458 var) 13459 Modify the user variable bound at 'stmt' to VAR. 13460 13461 -- GIMPLE function: void gimple_debug_bind_set_value (gimple stmt, tree 13462 var) 13463 Modify the value bound to the user variable bound at 'stmt' to 13464 VALUE. 13465 13466 -- GIMPLE function: void gimple_debug_bind_reset_value (gimple stmt) 13467 Modify the value bound to the user variable bound at 'stmt' so that 13468 the variable becomes unbound. 13469 13470 -- GIMPLE function: bool gimple_debug_bind_has_value_p (gimple stmt) 13471 Return 'TRUE' if 'stmt' binds a user variable to a value, and 13472 'FALSE' if it unbinds the variable. 13473 13474 -- GIMPLE function: gimple gimple_build_debug_begin_stmt (tree block, 13475 location_t location) 13476 Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_BEGIN_STMT' 13477 'subcode'. The effect of this statement is to tell debug 13478 information generation machinery that the user statement at the 13479 given 'location' and 'block' starts at the point at which the 13480 statement is inserted. The intent is that side effects (e.g. 13481 variable bindings) of all prior user statements are observable, and 13482 that none of the side effects of subsequent user statements are. 13483 13484 -- GIMPLE function: gimple gimple_build_debug_inline_entry (tree block, 13485 location_t location) 13486 Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_INLINE_ENTRY' 13487 'subcode'. The effect of this statement is to tell debug 13488 information generation machinery that a function call at 'location' 13489 underwent inline substitution, that 'block' is the enclosing 13490 lexical block created for the substitution, and that at the point 13491 of the program in which the stmt is inserted, all parameters for 13492 the inlined function are bound to the respective arguments, and 13493 none of the side effects of its stmts are observable. 13494 13495 13496File: gccint.info, Node: GIMPLE_EH_FILTER, Next: GIMPLE_LABEL, Prev: GIMPLE_DEBUG, Up: Tuple specific accessors 13497 1349812.8.8 'GIMPLE_EH_FILTER' 13499------------------------- 13500 13501 -- GIMPLE function: geh_filter *gimple_build_eh_filter (tree types, 13502 gimple_seq failure) 13503 Build a 'GIMPLE_EH_FILTER' statement. 'TYPES' are the filter's 13504 types. 'FAILURE' is a sequence with the filter's failure action. 13505 13506 -- GIMPLE function: tree gimple_eh_filter_types (gimple g) 13507 Return the types handled by 'GIMPLE_EH_FILTER' statement 'G'. 13508 13509 -- GIMPLE function: tree * gimple_eh_filter_types_ptr (gimple g) 13510 Return a pointer to the types handled by 'GIMPLE_EH_FILTER' 13511 statement 'G'. 13512 13513 -- GIMPLE function: gimple_seq gimple_eh_filter_failure (gimple g) 13514 Return the sequence of statement to execute when 'GIMPLE_EH_FILTER' 13515 statement fails. 13516 13517 -- GIMPLE function: void gimple_eh_filter_set_types (geh_filter *g, 13518 tree types) 13519 Set 'TYPES' to be the set of types handled by 'GIMPLE_EH_FILTER' 13520 'G'. 13521 13522 -- GIMPLE function: void gimple_eh_filter_set_failure (geh_filter *g, 13523 gimple_seq failure) 13524 Set 'FAILURE' to be the sequence of statements to execute on 13525 failure for 'GIMPLE_EH_FILTER' 'G'. 13526 13527 -- GIMPLE function: tree gimple_eh_must_not_throw_fndecl ( geh_mnt 13528 *eh_mnt_stmt) 13529 Get the function decl to be called by the MUST_NOT_THROW region. 13530 13531 -- GIMPLE function: void gimple_eh_must_not_throw_set_fndecl ( geh_mnt 13532 *eh_mnt_stmt, tree decl) 13533 Set the function decl to be called by GS to DECL. 13534 13535 13536File: gccint.info, Node: GIMPLE_LABEL, Next: GIMPLE_GOTO, Prev: GIMPLE_EH_FILTER, Up: Tuple specific accessors 13537 1353812.8.9 'GIMPLE_LABEL' 13539--------------------- 13540 13541 -- GIMPLE function: glabel *gimple_build_label (tree label) 13542 Build a 'GIMPLE_LABEL' statement with corresponding to the tree 13543 label, 'LABEL'. 13544 13545 -- GIMPLE function: tree gimple_label_label (const glabel *g) 13546 Return the 'LABEL_DECL' node used by 'GIMPLE_LABEL' statement 'G'. 13547 13548 -- GIMPLE function: void gimple_label_set_label (glabel *g, tree label) 13549 Set 'LABEL' to be the 'LABEL_DECL' node used by 'GIMPLE_LABEL' 13550 statement 'G'. 13551 13552 13553File: gccint.info, Node: GIMPLE_GOTO, Next: GIMPLE_NOP, Prev: GIMPLE_LABEL, Up: Tuple specific accessors 13554 1355512.8.10 'GIMPLE_GOTO' 13556--------------------- 13557 13558 -- GIMPLE function: ggoto *gimple_build_goto (tree dest) 13559 Build a 'GIMPLE_GOTO' statement to label 'DEST'. 13560 13561 -- GIMPLE function: tree gimple_goto_dest (gimple g) 13562 Return the destination of the unconditional jump 'G'. 13563 13564 -- GIMPLE function: void gimple_goto_set_dest (ggoto *g, tree dest) 13565 Set 'DEST' to be the destination of the unconditional jump 'G'. 13566 13567 13568File: gccint.info, Node: GIMPLE_NOP, Next: GIMPLE_OMP_ATOMIC_LOAD, Prev: GIMPLE_GOTO, Up: Tuple specific accessors 13569 1357012.8.11 'GIMPLE_NOP' 13571-------------------- 13572 13573 -- GIMPLE function: gimple gimple_build_nop (void) 13574 Build a 'GIMPLE_NOP' statement. 13575 13576 -- GIMPLE function: bool gimple_nop_p (gimple g) 13577 Returns 'TRUE' if statement 'G' is a 'GIMPLE_NOP'. 13578 13579 13580File: gccint.info, Node: GIMPLE_OMP_ATOMIC_LOAD, Next: GIMPLE_OMP_ATOMIC_STORE, Prev: GIMPLE_NOP, Up: Tuple specific accessors 13581 1358212.8.12 'GIMPLE_OMP_ATOMIC_LOAD' 13583-------------------------------- 13584 13585 -- GIMPLE function: gomp_atomic_load *gimple_build_omp_atomic_load ( 13586 tree lhs, tree rhs) 13587 Build a 'GIMPLE_OMP_ATOMIC_LOAD' statement. 'LHS' is the left-hand 13588 side of the assignment. 'RHS' is the right-hand side of the 13589 assignment. 13590 13591 -- GIMPLE function: void gimple_omp_atomic_load_set_lhs ( 13592 gomp_atomic_load *g, tree lhs) 13593 Set the 'LHS' of an atomic load. 13594 13595 -- GIMPLE function: tree gimple_omp_atomic_load_lhs ( const 13596 gomp_atomic_load *g) 13597 Get the 'LHS' of an atomic load. 13598 13599 -- GIMPLE function: void gimple_omp_atomic_load_set_rhs ( 13600 gomp_atomic_load *g, tree rhs) 13601 Set the 'RHS' of an atomic set. 13602 13603 -- GIMPLE function: tree gimple_omp_atomic_load_rhs ( const 13604 gomp_atomic_load *g) 13605 Get the 'RHS' of an atomic set. 13606 13607 13608File: gccint.info, Node: GIMPLE_OMP_ATOMIC_STORE, Next: GIMPLE_OMP_CONTINUE, Prev: GIMPLE_OMP_ATOMIC_LOAD, Up: Tuple specific accessors 13609 1361012.8.13 'GIMPLE_OMP_ATOMIC_STORE' 13611--------------------------------- 13612 13613 -- GIMPLE function: gomp_atomic_store *gimple_build_omp_atomic_store ( 13614 tree val) 13615 Build a 'GIMPLE_OMP_ATOMIC_STORE' statement. 'VAL' is the value to 13616 be stored. 13617 13618 -- GIMPLE function: void gimple_omp_atomic_store_set_val ( 13619 gomp_atomic_store *g, tree val) 13620 Set the value being stored in an atomic store. 13621 13622 -- GIMPLE function: tree gimple_omp_atomic_store_val ( const 13623 gomp_atomic_store *g) 13624 Return the value being stored in an atomic store. 13625 13626 13627File: gccint.info, Node: GIMPLE_OMP_CONTINUE, Next: GIMPLE_OMP_CRITICAL, Prev: GIMPLE_OMP_ATOMIC_STORE, Up: Tuple specific accessors 13628 1362912.8.14 'GIMPLE_OMP_CONTINUE' 13630----------------------------- 13631 13632 -- GIMPLE function: gomp_continue *gimple_build_omp_continue ( tree 13633 control_def, tree control_use) 13634 Build a 'GIMPLE_OMP_CONTINUE' statement. 'CONTROL_DEF' is the 13635 definition of the control variable. 'CONTROL_USE' is the use of 13636 the control variable. 13637 13638 -- GIMPLE function: tree gimple_omp_continue_control_def ( const 13639 gomp_continue *s) 13640 Return the definition of the control variable on a 13641 'GIMPLE_OMP_CONTINUE' in 'S'. 13642 13643 -- GIMPLE function: tree gimple_omp_continue_control_def_ptr ( 13644 gomp_continue *s) 13645 Same as above, but return the pointer. 13646 13647 -- GIMPLE function: tree gimple_omp_continue_set_control_def ( 13648 gomp_continue *s) 13649 Set the control variable definition for a 'GIMPLE_OMP_CONTINUE' 13650 statement in 'S'. 13651 13652 -- GIMPLE function: tree gimple_omp_continue_control_use ( const 13653 gomp_continue *s) 13654 Return the use of the control variable on a 'GIMPLE_OMP_CONTINUE' 13655 in 'S'. 13656 13657 -- GIMPLE function: tree gimple_omp_continue_control_use_ptr ( 13658 gomp_continue *s) 13659 Same as above, but return the pointer. 13660 13661 -- GIMPLE function: tree gimple_omp_continue_set_control_use ( 13662 gomp_continue *s) 13663 Set the control variable use for a 'GIMPLE_OMP_CONTINUE' statement 13664 in 'S'. 13665 13666 13667File: gccint.info, Node: GIMPLE_OMP_CRITICAL, Next: GIMPLE_OMP_FOR, Prev: GIMPLE_OMP_CONTINUE, Up: Tuple specific accessors 13668 1366912.8.15 'GIMPLE_OMP_CRITICAL' 13670----------------------------- 13671 13672 -- GIMPLE function: gomp_critical *gimple_build_omp_critical ( 13673 gimple_seq body, tree name) 13674 Build a 'GIMPLE_OMP_CRITICAL' statement. 'BODY' is the sequence of 13675 statements for which only one thread can execute. 'NAME' is an 13676 optional identifier for this critical block. 13677 13678 -- GIMPLE function: tree gimple_omp_critical_name ( const gomp_critical 13679 *g) 13680 Return the name associated with 'OMP_CRITICAL' statement 'G'. 13681 13682 -- GIMPLE function: tree * gimple_omp_critical_name_ptr ( gomp_critical 13683 *g) 13684 Return a pointer to the name associated with 'OMP' critical 13685 statement 'G'. 13686 13687 -- GIMPLE function: void gimple_omp_critical_set_name ( gomp_critical 13688 *g, tree name) 13689 Set 'NAME' to be the name associated with 'OMP' critical statement 13690 'G'. 13691 13692 13693File: gccint.info, Node: GIMPLE_OMP_FOR, Next: GIMPLE_OMP_MASTER, Prev: GIMPLE_OMP_CRITICAL, Up: Tuple specific accessors 13694 1369512.8.16 'GIMPLE_OMP_FOR' 13696------------------------ 13697 13698 -- GIMPLE function: gomp_for *gimple_build_omp_for (gimple_seq body, 13699 tree clauses, tree index, tree initial, tree final, tree incr, 13700 gimple_seq pre_body, enum tree_code omp_for_cond) 13701 Build a 'GIMPLE_OMP_FOR' statement. 'BODY' is sequence of 13702 statements inside the for loop. 'CLAUSES', are any of the loop 13703 construct's clauses. 'PRE_BODY' is the sequence of statements that 13704 are loop invariant. 'INDEX' is the index variable. 'INITIAL' is 13705 the initial value of 'INDEX'. 'FINAL' is final value of 'INDEX'. 13706 OMP_FOR_COND is the predicate used to compare 'INDEX' and 'FINAL'. 13707 'INCR' is the increment expression. 13708 13709 -- GIMPLE function: tree gimple_omp_for_clauses (gimple g) 13710 Return the clauses associated with 'OMP_FOR' 'G'. 13711 13712 -- GIMPLE function: tree * gimple_omp_for_clauses_ptr (gimple g) 13713 Return a pointer to the 'OMP_FOR' 'G'. 13714 13715 -- GIMPLE function: void gimple_omp_for_set_clauses (gimple g, tree 13716 clauses) 13717 Set 'CLAUSES' to be the list of clauses associated with 'OMP_FOR' 13718 'G'. 13719 13720 -- GIMPLE function: tree gimple_omp_for_index (gimple g) 13721 Return the index variable for 'OMP_FOR' 'G'. 13722 13723 -- GIMPLE function: tree * gimple_omp_for_index_ptr (gimple g) 13724 Return a pointer to the index variable for 'OMP_FOR' 'G'. 13725 13726 -- GIMPLE function: void gimple_omp_for_set_index (gimple g, tree 13727 index) 13728 Set 'INDEX' to be the index variable for 'OMP_FOR' 'G'. 13729 13730 -- GIMPLE function: tree gimple_omp_for_initial (gimple g) 13731 Return the initial value for 'OMP_FOR' 'G'. 13732 13733 -- GIMPLE function: tree * gimple_omp_for_initial_ptr (gimple g) 13734 Return a pointer to the initial value for 'OMP_FOR' 'G'. 13735 13736 -- GIMPLE function: void gimple_omp_for_set_initial (gimple g, tree 13737 initial) 13738 Set 'INITIAL' to be the initial value for 'OMP_FOR' 'G'. 13739 13740 -- GIMPLE function: tree gimple_omp_for_final (gimple g) 13741 Return the final value for 'OMP_FOR' 'G'. 13742 13743 -- GIMPLE function: tree * gimple_omp_for_final_ptr (gimple g) 13744 turn a pointer to the final value for 'OMP_FOR' 'G'. 13745 13746 -- GIMPLE function: void gimple_omp_for_set_final (gimple g, tree 13747 final) 13748 Set 'FINAL' to be the final value for 'OMP_FOR' 'G'. 13749 13750 -- GIMPLE function: tree gimple_omp_for_incr (gimple g) 13751 Return the increment value for 'OMP_FOR' 'G'. 13752 13753 -- GIMPLE function: tree * gimple_omp_for_incr_ptr (gimple g) 13754 Return a pointer to the increment value for 'OMP_FOR' 'G'. 13755 13756 -- GIMPLE function: void gimple_omp_for_set_incr (gimple g, tree incr) 13757 Set 'INCR' to be the increment value for 'OMP_FOR' 'G'. 13758 13759 -- GIMPLE function: gimple_seq gimple_omp_for_pre_body (gimple g) 13760 Return the sequence of statements to execute before the 'OMP_FOR' 13761 statement 'G' starts. 13762 13763 -- GIMPLE function: void gimple_omp_for_set_pre_body (gimple g, 13764 gimple_seq pre_body) 13765 Set 'PRE_BODY' to be the sequence of statements to execute before 13766 the 'OMP_FOR' statement 'G' starts. 13767 13768 -- GIMPLE function: void gimple_omp_for_set_cond (gimple g, enum 13769 tree_code cond) 13770 Set 'COND' to be the condition code for 'OMP_FOR' 'G'. 13771 13772 -- GIMPLE function: enum tree_code gimple_omp_for_cond (gimple g) 13773 Return the condition code associated with 'OMP_FOR' 'G'. 13774 13775 13776File: gccint.info, Node: GIMPLE_OMP_MASTER, Next: GIMPLE_OMP_ORDERED, Prev: GIMPLE_OMP_FOR, Up: Tuple specific accessors 13777 1377812.8.17 'GIMPLE_OMP_MASTER' 13779--------------------------- 13780 13781 -- GIMPLE function: gimple gimple_build_omp_master (gimple_seq body) 13782 Build a 'GIMPLE_OMP_MASTER' statement. 'BODY' is the sequence of 13783 statements to be executed by just the master. 13784 13785 13786File: gccint.info, Node: GIMPLE_OMP_ORDERED, Next: GIMPLE_OMP_PARALLEL, Prev: GIMPLE_OMP_MASTER, Up: Tuple specific accessors 13787 1378812.8.18 'GIMPLE_OMP_ORDERED' 13789---------------------------- 13790 13791 -- GIMPLE function: gimple gimple_build_omp_ordered (gimple_seq body) 13792 Build a 'GIMPLE_OMP_ORDERED' statement. 13793 13794 'BODY' is the sequence of statements inside a loop that will executed 13795in sequence. 13796 13797 13798File: gccint.info, Node: GIMPLE_OMP_PARALLEL, Next: GIMPLE_OMP_RETURN, Prev: GIMPLE_OMP_ORDERED, Up: Tuple specific accessors 13799 1380012.8.19 'GIMPLE_OMP_PARALLEL' 13801----------------------------- 13802 13803 -- GIMPLE function: gomp_parallel *gimple_build_omp_parallel 13804 (gimple_seq body, tree clauses, tree child_fn, tree data_arg) 13805 Build a 'GIMPLE_OMP_PARALLEL' statement. 13806 13807 'BODY' is sequence of statements which are executed in parallel. 13808'CLAUSES', are the 'OMP' parallel construct's clauses. 'CHILD_FN' is 13809the function created for the parallel threads to execute. 'DATA_ARG' 13810are the shared data argument(s). 13811 13812 -- GIMPLE function: bool gimple_omp_parallel_combined_p (gimple g) 13813 Return true if 'OMP' parallel statement 'G' has the 13814 'GF_OMP_PARALLEL_COMBINED' flag set. 13815 13816 -- GIMPLE function: void gimple_omp_parallel_set_combined_p (gimple g) 13817 Set the 'GF_OMP_PARALLEL_COMBINED' field in 'OMP' parallel 13818 statement 'G'. 13819 13820 -- GIMPLE function: gimple_seq gimple_omp_body (gimple g) 13821 Return the body for the 'OMP' statement 'G'. 13822 13823 -- GIMPLE function: void gimple_omp_set_body (gimple g, gimple_seq 13824 body) 13825 Set 'BODY' to be the body for the 'OMP' statement 'G'. 13826 13827 -- GIMPLE function: tree gimple_omp_parallel_clauses (gimple g) 13828 Return the clauses associated with 'OMP_PARALLEL' 'G'. 13829 13830 -- GIMPLE function: tree * gimple_omp_parallel_clauses_ptr ( 13831 gomp_parallel *g) 13832 Return a pointer to the clauses associated with 'OMP_PARALLEL' 'G'. 13833 13834 -- GIMPLE function: void gimple_omp_parallel_set_clauses ( 13835 gomp_parallel *g, tree clauses) 13836 Set 'CLAUSES' to be the list of clauses associated with 13837 'OMP_PARALLEL' 'G'. 13838 13839 -- GIMPLE function: tree gimple_omp_parallel_child_fn ( const 13840 gomp_parallel *g) 13841 Return the child function used to hold the body of 'OMP_PARALLEL' 13842 'G'. 13843 13844 -- GIMPLE function: tree * gimple_omp_parallel_child_fn_ptr ( 13845 gomp_parallel *g) 13846 Return a pointer to the child function used to hold the body of 13847 'OMP_PARALLEL' 'G'. 13848 13849 -- GIMPLE function: void gimple_omp_parallel_set_child_fn ( 13850 gomp_parallel *g, tree child_fn) 13851 Set 'CHILD_FN' to be the child function for 'OMP_PARALLEL' 'G'. 13852 13853 -- GIMPLE function: tree gimple_omp_parallel_data_arg ( const 13854 gomp_parallel *g) 13855 Return the artificial argument used to send variables and values 13856 from the parent to the children threads in 'OMP_PARALLEL' 'G'. 13857 13858 -- GIMPLE function: tree * gimple_omp_parallel_data_arg_ptr ( 13859 gomp_parallel *g) 13860 Return a pointer to the data argument for 'OMP_PARALLEL' 'G'. 13861 13862 -- GIMPLE function: void gimple_omp_parallel_set_data_arg ( 13863 gomp_parallel *g, tree data_arg) 13864 Set 'DATA_ARG' to be the data argument for 'OMP_PARALLEL' 'G'. 13865 13866 13867File: gccint.info, Node: GIMPLE_OMP_RETURN, Next: GIMPLE_OMP_SECTION, Prev: GIMPLE_OMP_PARALLEL, Up: Tuple specific accessors 13868 1386912.8.20 'GIMPLE_OMP_RETURN' 13870--------------------------- 13871 13872 -- GIMPLE function: gimple gimple_build_omp_return (bool wait_p) 13873 Build a 'GIMPLE_OMP_RETURN' statement. 'WAIT_P' is true if this is 13874 a non-waiting return. 13875 13876 -- GIMPLE function: void gimple_omp_return_set_nowait (gimple s) 13877 Set the nowait flag on 'GIMPLE_OMP_RETURN' statement 'S'. 13878 13879 -- GIMPLE function: bool gimple_omp_return_nowait_p (gimple g) 13880 Return true if 'OMP' return statement 'G' has the 13881 'GF_OMP_RETURN_NOWAIT' flag set. 13882 13883 13884File: gccint.info, Node: GIMPLE_OMP_SECTION, Next: GIMPLE_OMP_SECTIONS, Prev: GIMPLE_OMP_RETURN, Up: Tuple specific accessors 13885 1388612.8.21 'GIMPLE_OMP_SECTION' 13887---------------------------- 13888 13889 -- GIMPLE function: gimple gimple_build_omp_section (gimple_seq body) 13890 Build a 'GIMPLE_OMP_SECTION' statement for a sections statement. 13891 13892 'BODY' is the sequence of statements in the section. 13893 13894 -- GIMPLE function: bool gimple_omp_section_last_p (gimple g) 13895 Return true if 'OMP' section statement 'G' has the 13896 'GF_OMP_SECTION_LAST' flag set. 13897 13898 -- GIMPLE function: void gimple_omp_section_set_last (gimple g) 13899 Set the 'GF_OMP_SECTION_LAST' flag on 'G'. 13900 13901 13902File: gccint.info, Node: GIMPLE_OMP_SECTIONS, Next: GIMPLE_OMP_SINGLE, Prev: GIMPLE_OMP_SECTION, Up: Tuple specific accessors 13903 1390412.8.22 'GIMPLE_OMP_SECTIONS' 13905----------------------------- 13906 13907 -- GIMPLE function: gomp_sections *gimple_build_omp_sections ( 13908 gimple_seq body, tree clauses) 13909 Build a 'GIMPLE_OMP_SECTIONS' statement. 'BODY' is a sequence of 13910 section statements. 'CLAUSES' are any of the 'OMP' sections 13911 construct's clauses: private, firstprivate, lastprivate, reduction, 13912 and nowait. 13913 13914 -- GIMPLE function: gimple gimple_build_omp_sections_switch (void) 13915 Build a 'GIMPLE_OMP_SECTIONS_SWITCH' statement. 13916 13917 -- GIMPLE function: tree gimple_omp_sections_control (gimple g) 13918 Return the control variable associated with the 13919 'GIMPLE_OMP_SECTIONS' in 'G'. 13920 13921 -- GIMPLE function: tree * gimple_omp_sections_control_ptr (gimple g) 13922 Return a pointer to the clauses associated with the 13923 'GIMPLE_OMP_SECTIONS' in 'G'. 13924 13925 -- GIMPLE function: void gimple_omp_sections_set_control (gimple g, 13926 tree control) 13927 Set 'CONTROL' to be the set of clauses associated with the 13928 'GIMPLE_OMP_SECTIONS' in 'G'. 13929 13930 -- GIMPLE function: tree gimple_omp_sections_clauses (gimple g) 13931 Return the clauses associated with 'OMP_SECTIONS' 'G'. 13932 13933 -- GIMPLE function: tree * gimple_omp_sections_clauses_ptr (gimple g) 13934 Return a pointer to the clauses associated with 'OMP_SECTIONS' 'G'. 13935 13936 -- GIMPLE function: void gimple_omp_sections_set_clauses (gimple g, 13937 tree clauses) 13938 Set 'CLAUSES' to be the set of clauses associated with 13939 'OMP_SECTIONS' 'G'. 13940 13941 13942File: gccint.info, Node: GIMPLE_OMP_SINGLE, Next: GIMPLE_PHI, Prev: GIMPLE_OMP_SECTIONS, Up: Tuple specific accessors 13943 1394412.8.23 'GIMPLE_OMP_SINGLE' 13945--------------------------- 13946 13947 -- GIMPLE function: gomp_single *gimple_build_omp_single ( gimple_seq 13948 body, tree clauses) 13949 Build a 'GIMPLE_OMP_SINGLE' statement. 'BODY' is the sequence of 13950 statements that will be executed once. 'CLAUSES' are any of the 13951 'OMP' single construct's clauses: private, firstprivate, 13952 copyprivate, nowait. 13953 13954 -- GIMPLE function: tree gimple_omp_single_clauses (gimple g) 13955 Return the clauses associated with 'OMP_SINGLE' 'G'. 13956 13957 -- GIMPLE function: tree * gimple_omp_single_clauses_ptr (gimple g) 13958 Return a pointer to the clauses associated with 'OMP_SINGLE' 'G'. 13959 13960 -- GIMPLE function: void gimple_omp_single_set_clauses ( gomp_single 13961 *g, tree clauses) 13962 Set 'CLAUSES' to be the clauses associated with 'OMP_SINGLE' 'G'. 13963 13964 13965File: gccint.info, Node: GIMPLE_PHI, Next: GIMPLE_RESX, Prev: GIMPLE_OMP_SINGLE, Up: Tuple specific accessors 13966 1396712.8.24 'GIMPLE_PHI' 13968-------------------- 13969 13970 -- GIMPLE function: unsigned gimple_phi_capacity (gimple g) 13971 Return the maximum number of arguments supported by 'GIMPLE_PHI' 13972 'G'. 13973 13974 -- GIMPLE function: unsigned gimple_phi_num_args (gimple g) 13975 Return the number of arguments in 'GIMPLE_PHI' 'G'. This must 13976 always be exactly the number of incoming edges for the basic block 13977 holding 'G'. 13978 13979 -- GIMPLE function: tree gimple_phi_result (gimple g) 13980 Return the 'SSA' name created by 'GIMPLE_PHI' 'G'. 13981 13982 -- GIMPLE function: tree * gimple_phi_result_ptr (gimple g) 13983 Return a pointer to the 'SSA' name created by 'GIMPLE_PHI' 'G'. 13984 13985 -- GIMPLE function: void gimple_phi_set_result (gphi *g, tree result) 13986 Set 'RESULT' to be the 'SSA' name created by 'GIMPLE_PHI' 'G'. 13987 13988 -- GIMPLE function: struct phi_arg_d * gimple_phi_arg (gimple g, index) 13989 Return the 'PHI' argument corresponding to incoming edge 'INDEX' 13990 for 'GIMPLE_PHI' 'G'. 13991 13992 -- GIMPLE function: void gimple_phi_set_arg (gphi *g, index, struct 13993 phi_arg_d * phiarg) 13994 Set 'PHIARG' to be the argument corresponding to incoming edge 13995 'INDEX' for 'GIMPLE_PHI' 'G'. 13996 13997 13998File: gccint.info, Node: GIMPLE_RESX, Next: GIMPLE_RETURN, Prev: GIMPLE_PHI, Up: Tuple specific accessors 13999 1400012.8.25 'GIMPLE_RESX' 14001--------------------- 14002 14003 -- GIMPLE function: gresx *gimple_build_resx (int region) 14004 Build a 'GIMPLE_RESX' statement which is a statement. This 14005 statement is a placeholder for _Unwind_Resume before we know if a 14006 function call or a branch is needed. 'REGION' is the exception 14007 region from which control is flowing. 14008 14009 -- GIMPLE function: int gimple_resx_region (const gresx *g) 14010 Return the region number for 'GIMPLE_RESX' 'G'. 14011 14012 -- GIMPLE function: void gimple_resx_set_region (gresx *g, int region) 14013 Set 'REGION' to be the region number for 'GIMPLE_RESX' 'G'. 14014 14015 14016File: gccint.info, Node: GIMPLE_RETURN, Next: GIMPLE_SWITCH, Prev: GIMPLE_RESX, Up: Tuple specific accessors 14017 1401812.8.26 'GIMPLE_RETURN' 14019----------------------- 14020 14021 -- GIMPLE function: greturn *gimple_build_return (tree retval) 14022 Build a 'GIMPLE_RETURN' statement whose return value is retval. 14023 14024 -- GIMPLE function: tree gimple_return_retval (const greturn *g) 14025 Return the return value for 'GIMPLE_RETURN' 'G'. 14026 14027 -- GIMPLE function: void gimple_return_set_retval (greturn *g, tree 14028 retval) 14029 Set 'RETVAL' to be the return value for 'GIMPLE_RETURN' 'G'. 14030 14031 14032File: gccint.info, Node: GIMPLE_SWITCH, Next: GIMPLE_TRY, Prev: GIMPLE_RETURN, Up: Tuple specific accessors 14033 1403412.8.27 'GIMPLE_SWITCH' 14035----------------------- 14036 14037 -- GIMPLE function: gswitch *gimple_build_switch (tree index, tree 14038 default_label, 'vec'<tree> *args) 14039 Build a 'GIMPLE_SWITCH' statement. 'INDEX' is the index variable 14040 to switch on, and 'DEFAULT_LABEL' represents the default label. 14041 'ARGS' is a vector of 'CASE_LABEL_EXPR' trees that contain the 14042 non-default case labels. Each label is a tree of code 14043 'CASE_LABEL_EXPR'. 14044 14045 -- GIMPLE function: unsigned gimple_switch_num_labels ( const gswitch 14046 *g) 14047 Return the number of labels associated with the switch statement 14048 'G'. 14049 14050 -- GIMPLE function: void gimple_switch_set_num_labels (gswitch *g, 14051 unsigned nlabels) 14052 Set 'NLABELS' to be the number of labels for the switch statement 14053 'G'. 14054 14055 -- GIMPLE function: tree gimple_switch_index (const gswitch *g) 14056 Return the index variable used by the switch statement 'G'. 14057 14058 -- GIMPLE function: void gimple_switch_set_index (gswitch *g, tree 14059 index) 14060 Set 'INDEX' to be the index variable for switch statement 'G'. 14061 14062 -- GIMPLE function: tree gimple_switch_label (const gswitch *g, 14063 unsigned index) 14064 Return the label numbered 'INDEX'. The default label is 0, 14065 followed by any labels in a switch statement. 14066 14067 -- GIMPLE function: void gimple_switch_set_label (gswitch *g, unsigned 14068 index, tree label) 14069 Set the label number 'INDEX' to 'LABEL'. 0 is always the default 14070 label. 14071 14072 -- GIMPLE function: tree gimple_switch_default_label ( const gswitch 14073 *g) 14074 Return the default label for a switch statement. 14075 14076 -- GIMPLE function: void gimple_switch_set_default_label (gswitch *g, 14077 tree label) 14078 Set the default label for a switch statement. 14079 14080 14081File: gccint.info, Node: GIMPLE_TRY, Next: GIMPLE_WITH_CLEANUP_EXPR, Prev: GIMPLE_SWITCH, Up: Tuple specific accessors 14082 1408312.8.28 'GIMPLE_TRY' 14084-------------------- 14085 14086 -- GIMPLE function: gtry *gimple_build_try (gimple_seq eval, gimple_seq 14087 cleanup, unsigned int kind) 14088 Build a 'GIMPLE_TRY' statement. 'EVAL' is a sequence with the 14089 expression to evaluate. 'CLEANUP' is a sequence of statements to 14090 run at clean-up time. 'KIND' is the enumeration value 14091 'GIMPLE_TRY_CATCH' if this statement denotes a try/catch construct 14092 or 'GIMPLE_TRY_FINALLY' if this statement denotes a try/finally 14093 construct. 14094 14095 -- GIMPLE function: enum gimple_try_flags gimple_try_kind (gimple g) 14096 Return the kind of try block represented by 'GIMPLE_TRY' 'G'. This 14097 is either 'GIMPLE_TRY_CATCH' or 'GIMPLE_TRY_FINALLY'. 14098 14099 -- GIMPLE function: bool gimple_try_catch_is_cleanup (gimple g) 14100 Return the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 14101 14102 -- GIMPLE function: gimple_seq gimple_try_eval (gimple g) 14103 Return the sequence of statements used as the body for 'GIMPLE_TRY' 14104 'G'. 14105 14106 -- GIMPLE function: gimple_seq gimple_try_cleanup (gimple g) 14107 Return the sequence of statements used as the cleanup body for 14108 'GIMPLE_TRY' 'G'. 14109 14110 -- GIMPLE function: void gimple_try_set_catch_is_cleanup (gimple g, 14111 bool catch_is_cleanup) 14112 Set the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 14113 14114 -- GIMPLE function: void gimple_try_set_eval (gtry *g, gimple_seq eval) 14115 Set 'EVAL' to be the sequence of statements to use as the body for 14116 'GIMPLE_TRY' 'G'. 14117 14118 -- GIMPLE function: void gimple_try_set_cleanup (gtry *g, gimple_seq 14119 cleanup) 14120 Set 'CLEANUP' to be the sequence of statements to use as the 14121 cleanup body for 'GIMPLE_TRY' 'G'. 14122 14123 14124File: gccint.info, Node: GIMPLE_WITH_CLEANUP_EXPR, Prev: GIMPLE_TRY, Up: Tuple specific accessors 14125 1412612.8.29 'GIMPLE_WITH_CLEANUP_EXPR' 14127---------------------------------- 14128 14129 -- GIMPLE function: gimple gimple_build_wce (gimple_seq cleanup) 14130 Build a 'GIMPLE_WITH_CLEANUP_EXPR' statement. 'CLEANUP' is the 14131 clean-up expression. 14132 14133 -- GIMPLE function: gimple_seq gimple_wce_cleanup (gimple g) 14134 Return the cleanup sequence for cleanup statement 'G'. 14135 14136 -- GIMPLE function: void gimple_wce_set_cleanup (gimple g, gimple_seq 14137 cleanup) 14138 Set 'CLEANUP' to be the cleanup sequence for 'G'. 14139 14140 -- GIMPLE function: bool gimple_wce_cleanup_eh_only (gimple g) 14141 Return the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple. 14142 14143 -- GIMPLE function: void gimple_wce_set_cleanup_eh_only (gimple g, bool 14144 eh_only_p) 14145 Set the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple. 14146 14147 14148File: gccint.info, Node: GIMPLE sequences, Next: Sequence iterators, Prev: Tuple specific accessors, Up: GIMPLE 14149 1415012.9 GIMPLE sequences 14151===================== 14152 14153GIMPLE sequences are the tuple equivalent of 'STATEMENT_LIST''s used in 14154'GENERIC'. They are used to chain statements together, and when used in 14155conjunction with sequence iterators, provide a framework for iterating 14156through statements. 14157 14158 GIMPLE sequences are of type struct 'gimple_sequence', but are more 14159commonly passed by reference to functions dealing with sequences. The 14160type for a sequence pointer is 'gimple_seq' which is the same as struct 14161'gimple_sequence' *. When declaring a local sequence, you can define a 14162local variable of type struct 'gimple_sequence'. When declaring a 14163sequence allocated on the garbage collected heap, use the function 14164'gimple_seq_alloc' documented below. 14165 14166 There are convenience functions for iterating through sequences in the 14167section entitled Sequence Iterators. 14168 14169 Below is a list of functions to manipulate and query sequences. 14170 14171 -- GIMPLE function: void gimple_seq_add_stmt (gimple_seq *seq, gimple 14172 g) 14173 Link a gimple statement to the end of the sequence *'SEQ' if 'G' is 14174 not 'NULL'. If *'SEQ' is 'NULL', allocate a sequence before 14175 linking. 14176 14177 -- GIMPLE function: void gimple_seq_add_seq (gimple_seq *dest, 14178 gimple_seq src) 14179 Append sequence 'SRC' to the end of sequence *'DEST' if 'SRC' is 14180 not 'NULL'. If *'DEST' is 'NULL', allocate a new sequence before 14181 appending. 14182 14183 -- GIMPLE function: gimple_seq gimple_seq_deep_copy (gimple_seq src) 14184 Perform a deep copy of sequence 'SRC' and return the result. 14185 14186 -- GIMPLE function: gimple_seq gimple_seq_reverse (gimple_seq seq) 14187 Reverse the order of the statements in the sequence 'SEQ'. Return 14188 'SEQ'. 14189 14190 -- GIMPLE function: gimple gimple_seq_first (gimple_seq s) 14191 Return the first statement in sequence 'S'. 14192 14193 -- GIMPLE function: gimple gimple_seq_last (gimple_seq s) 14194 Return the last statement in sequence 'S'. 14195 14196 -- GIMPLE function: void gimple_seq_set_last (gimple_seq s, gimple 14197 last) 14198 Set the last statement in sequence 'S' to the statement in 'LAST'. 14199 14200 -- GIMPLE function: void gimple_seq_set_first (gimple_seq s, gimple 14201 first) 14202 Set the first statement in sequence 'S' to the statement in 14203 'FIRST'. 14204 14205 -- GIMPLE function: void gimple_seq_init (gimple_seq s) 14206 Initialize sequence 'S' to an empty sequence. 14207 14208 -- GIMPLE function: gimple_seq gimple_seq_alloc (void) 14209 Allocate a new sequence in the garbage collected store and return 14210 it. 14211 14212 -- GIMPLE function: void gimple_seq_copy (gimple_seq dest, gimple_seq 14213 src) 14214 Copy the sequence 'SRC' into the sequence 'DEST'. 14215 14216 -- GIMPLE function: bool gimple_seq_empty_p (gimple_seq s) 14217 Return true if the sequence 'S' is empty. 14218 14219 -- GIMPLE function: gimple_seq bb_seq (basic_block bb) 14220 Returns the sequence of statements in 'BB'. 14221 14222 -- GIMPLE function: void set_bb_seq (basic_block bb, gimple_seq seq) 14223 Sets the sequence of statements in 'BB' to 'SEQ'. 14224 14225 -- GIMPLE function: bool gimple_seq_singleton_p (gimple_seq seq) 14226 Determine whether 'SEQ' contains exactly one statement. 14227 14228 14229File: gccint.info, Node: Sequence iterators, Next: Adding a new GIMPLE statement code, Prev: GIMPLE sequences, Up: GIMPLE 14230 1423112.10 Sequence iterators 14232======================== 14233 14234Sequence iterators are convenience constructs for iterating through 14235statements in a sequence. Given a sequence 'SEQ', here is a typical use 14236of gimple sequence iterators: 14237 14238 gimple_stmt_iterator gsi; 14239 14240 for (gsi = gsi_start (seq); !gsi_end_p (gsi); gsi_next (&gsi)) 14241 { 14242 gimple g = gsi_stmt (gsi); 14243 /* Do something with gimple statement G. */ 14244 } 14245 14246 Backward iterations are possible: 14247 14248 for (gsi = gsi_last (seq); !gsi_end_p (gsi); gsi_prev (&gsi)) 14249 14250 Forward and backward iterations on basic blocks are possible with 14251'gsi_start_bb' and 'gsi_last_bb'. 14252 14253 In the documentation below we sometimes refer to enum 14254'gsi_iterator_update'. The valid options for this enumeration are: 14255 14256 * 'GSI_NEW_STMT' Only valid when a single statement is added. Move 14257 the iterator to it. 14258 14259 * 'GSI_SAME_STMT' Leave the iterator at the same statement. 14260 14261 * 'GSI_CONTINUE_LINKING' Move iterator to whatever position is 14262 suitable for linking other statements in the same direction. 14263 14264 Below is a list of the functions used to manipulate and use statement 14265iterators. 14266 14267 -- GIMPLE function: gimple_stmt_iterator gsi_start (gimple_seq seq) 14268 Return a new iterator pointing to the sequence 'SEQ''s first 14269 statement. If 'SEQ' is empty, the iterator's basic block is 14270 'NULL'. Use 'gsi_start_bb' instead when the iterator needs to 14271 always have the correct basic block set. 14272 14273 -- GIMPLE function: gimple_stmt_iterator gsi_start_bb (basic_block bb) 14274 Return a new iterator pointing to the first statement in basic 14275 block 'BB'. 14276 14277 -- GIMPLE function: gimple_stmt_iterator gsi_last (gimple_seq seq) 14278 Return a new iterator initially pointing to the last statement of 14279 sequence 'SEQ'. If 'SEQ' is empty, the iterator's basic block is 14280 'NULL'. Use 'gsi_last_bb' instead when the iterator needs to 14281 always have the correct basic block set. 14282 14283 -- GIMPLE function: gimple_stmt_iterator gsi_last_bb (basic_block bb) 14284 Return a new iterator pointing to the last statement in basic block 14285 'BB'. 14286 14287 -- GIMPLE function: bool gsi_end_p (gimple_stmt_iterator i) 14288 Return 'TRUE' if at the end of 'I'. 14289 14290 -- GIMPLE function: bool gsi_one_before_end_p (gimple_stmt_iterator i) 14291 Return 'TRUE' if we're one statement before the end of 'I'. 14292 14293 -- GIMPLE function: void gsi_next (gimple_stmt_iterator *i) 14294 Advance the iterator to the next gimple statement. 14295 14296 -- GIMPLE function: void gsi_prev (gimple_stmt_iterator *i) 14297 Advance the iterator to the previous gimple statement. 14298 14299 -- GIMPLE function: gimple gsi_stmt (gimple_stmt_iterator i) 14300 Return the current stmt. 14301 14302 -- GIMPLE function: gimple_stmt_iterator gsi_after_labels (basic_block 14303 bb) 14304 Return a block statement iterator that points to the first 14305 non-label statement in block 'BB'. 14306 14307 -- GIMPLE function: gimple * gsi_stmt_ptr (gimple_stmt_iterator *i) 14308 Return a pointer to the current stmt. 14309 14310 -- GIMPLE function: basic_block gsi_bb (gimple_stmt_iterator i) 14311 Return the basic block associated with this iterator. 14312 14313 -- GIMPLE function: gimple_seq gsi_seq (gimple_stmt_iterator i) 14314 Return the sequence associated with this iterator. 14315 14316 -- GIMPLE function: void gsi_remove (gimple_stmt_iterator *i, bool 14317 remove_eh_info) 14318 Remove the current stmt from the sequence. The iterator is updated 14319 to point to the next statement. When 'REMOVE_EH_INFO' is true we 14320 remove the statement pointed to by iterator 'I' from the 'EH' 14321 tables. Otherwise we do not modify the 'EH' tables. Generally, 14322 'REMOVE_EH_INFO' should be true when the statement is going to be 14323 removed from the 'IL' and not reinserted elsewhere. 14324 14325 -- GIMPLE function: void gsi_link_seq_before (gimple_stmt_iterator *i, 14326 gimple_seq seq, enum gsi_iterator_update mode) 14327 Links the sequence of statements 'SEQ' before the statement pointed 14328 by iterator 'I'. 'MODE' indicates what to do with the iterator 14329 after insertion (see 'enum gsi_iterator_update' above). 14330 14331 -- GIMPLE function: void gsi_link_before (gimple_stmt_iterator *i, 14332 gimple g, enum gsi_iterator_update mode) 14333 Links statement 'G' before the statement pointed-to by iterator 14334 'I'. Updates iterator 'I' according to 'MODE'. 14335 14336 -- GIMPLE function: void gsi_link_seq_after (gimple_stmt_iterator *i, 14337 gimple_seq seq, enum gsi_iterator_update mode) 14338 Links sequence 'SEQ' after the statement pointed-to by iterator 14339 'I'. 'MODE' is as in 'gsi_insert_after'. 14340 14341 -- GIMPLE function: void gsi_link_after (gimple_stmt_iterator *i, 14342 gimple g, enum gsi_iterator_update mode) 14343 Links statement 'G' after the statement pointed-to by iterator 'I'. 14344 'MODE' is as in 'gsi_insert_after'. 14345 14346 -- GIMPLE function: gimple_seq gsi_split_seq_after 14347 (gimple_stmt_iterator i) 14348 Move all statements in the sequence after 'I' to a new sequence. 14349 Return this new sequence. 14350 14351 -- GIMPLE function: gimple_seq gsi_split_seq_before 14352 (gimple_stmt_iterator *i) 14353 Move all statements in the sequence before 'I' to a new sequence. 14354 Return this new sequence. 14355 14356 -- GIMPLE function: void gsi_replace (gimple_stmt_iterator *i, gimple 14357 stmt, bool update_eh_info) 14358 Replace the statement pointed-to by 'I' to 'STMT'. If 14359 'UPDATE_EH_INFO' is true, the exception handling information of the 14360 original statement is moved to the new statement. 14361 14362 -- GIMPLE function: void gsi_insert_before (gimple_stmt_iterator *i, 14363 gimple stmt, enum gsi_iterator_update mode) 14364 Insert statement 'STMT' before the statement pointed-to by iterator 14365 'I', update 'STMT''s basic block and scan it for new operands. 14366 'MODE' specifies how to update iterator 'I' after insertion (see 14367 enum 'gsi_iterator_update'). 14368 14369 -- GIMPLE function: void gsi_insert_seq_before (gimple_stmt_iterator 14370 *i, gimple_seq seq, enum gsi_iterator_update mode) 14371 Like 'gsi_insert_before', but for all the statements in 'SEQ'. 14372 14373 -- GIMPLE function: void gsi_insert_after (gimple_stmt_iterator *i, 14374 gimple stmt, enum gsi_iterator_update mode) 14375 Insert statement 'STMT' after the statement pointed-to by iterator 14376 'I', update 'STMT''s basic block and scan it for new operands. 14377 'MODE' specifies how to update iterator 'I' after insertion (see 14378 enum 'gsi_iterator_update'). 14379 14380 -- GIMPLE function: void gsi_insert_seq_after (gimple_stmt_iterator *i, 14381 gimple_seq seq, enum gsi_iterator_update mode) 14382 Like 'gsi_insert_after', but for all the statements in 'SEQ'. 14383 14384 -- GIMPLE function: gimple_stmt_iterator gsi_for_stmt (gimple stmt) 14385 Finds iterator for 'STMT'. 14386 14387 -- GIMPLE function: void gsi_move_after (gimple_stmt_iterator *from, 14388 gimple_stmt_iterator *to) 14389 Move the statement at 'FROM' so it comes right after the statement 14390 at 'TO'. 14391 14392 -- GIMPLE function: void gsi_move_before (gimple_stmt_iterator *from, 14393 gimple_stmt_iterator *to) 14394 Move the statement at 'FROM' so it comes right before the statement 14395 at 'TO'. 14396 14397 -- GIMPLE function: void gsi_move_to_bb_end (gimple_stmt_iterator 14398 *from, basic_block bb) 14399 Move the statement at 'FROM' to the end of basic block 'BB'. 14400 14401 -- GIMPLE function: void gsi_insert_on_edge (edge e, gimple stmt) 14402 Add 'STMT' to the pending list of edge 'E'. No actual insertion is 14403 made until a call to 'gsi_commit_edge_inserts'() is made. 14404 14405 -- GIMPLE function: void gsi_insert_seq_on_edge (edge e, gimple_seq 14406 seq) 14407 Add the sequence of statements in 'SEQ' to the pending list of edge 14408 'E'. No actual insertion is made until a call to 14409 'gsi_commit_edge_inserts'() is made. 14410 14411 -- GIMPLE function: basic_block gsi_insert_on_edge_immediate (edge e, 14412 gimple stmt) 14413 Similar to 'gsi_insert_on_edge'+'gsi_commit_edge_inserts'. If a 14414 new block has to be created, it is returned. 14415 14416 -- GIMPLE function: void gsi_commit_one_edge_insert (edge e, 14417 basic_block *new_bb) 14418 Commit insertions pending at edge 'E'. If a new block is created, 14419 set 'NEW_BB' to this block, otherwise set it to 'NULL'. 14420 14421 -- GIMPLE function: void gsi_commit_edge_inserts (void) 14422 This routine will commit all pending edge insertions, creating any 14423 new basic blocks which are necessary. 14424 14425 14426File: gccint.info, Node: Adding a new GIMPLE statement code, Next: Statement and operand traversals, Prev: Sequence iterators, Up: GIMPLE 14427 1442812.11 Adding a new GIMPLE statement code 14429======================================== 14430 14431The first step in adding a new GIMPLE statement code, is modifying the 14432file 'gimple.def', which contains all the GIMPLE codes. Then you must 14433add a corresponding gimple subclass located in 'gimple.h'. This in 14434turn, will require you to add a corresponding 'GTY' tag in 14435'gsstruct.def', and code to handle this tag in 'gss_for_code' which is 14436located in 'gimple.c'. 14437 14438 In order for the garbage collector to know the size of the structure 14439you created in 'gimple.h', you need to add a case to handle your new 14440GIMPLE statement in 'gimple_size' which is located in 'gimple.c'. 14441 14442 You will probably want to create a function to build the new gimple 14443statement in 'gimple.c'. The function should be called 14444'gimple_build_NEW-TUPLE-NAME', and should return the new tuple as a 14445pointer to the appropriate gimple subclass. 14446 14447 If your new statement requires accessors for any members or operands it 14448may have, put simple inline accessors in 'gimple.h' and any non-trivial 14449accessors in 'gimple.c' with a corresponding prototype in 'gimple.h'. 14450 14451 You should add the new statement subclass to the class hierarchy 14452diagram in 'gimple.texi'. 14453 14454 14455File: gccint.info, Node: Statement and operand traversals, Prev: Adding a new GIMPLE statement code, Up: GIMPLE 14456 1445712.12 Statement and operand traversals 14458====================================== 14459 14460There are two functions available for walking statements and sequences: 14461'walk_gimple_stmt' and 'walk_gimple_seq', accordingly, and a third 14462function for walking the operands in a statement: 'walk_gimple_op'. 14463 14464 -- GIMPLE function: tree walk_gimple_stmt (gimple_stmt_iterator *gsi, 14465 walk_stmt_fn callback_stmt, walk_tree_fn callback_op, struct 14466 walk_stmt_info *wi) 14467 This function is used to walk the current statement in 'GSI', 14468 optionally using traversal state stored in 'WI'. If 'WI' is 14469 'NULL', no state is kept during the traversal. 14470 14471 The callback 'CALLBACK_STMT' is called. If 'CALLBACK_STMT' returns 14472 true, it means that the callback function has handled all the 14473 operands of the statement and it is not necessary to walk its 14474 operands. 14475 14476 If 'CALLBACK_STMT' is 'NULL' or it returns false, 'CALLBACK_OP' is 14477 called on each operand of the statement via 'walk_gimple_op'. If 14478 'walk_gimple_op' returns non-'NULL' for any operand, the remaining 14479 operands are not scanned. 14480 14481 The return value is that returned by the last call to 14482 'walk_gimple_op', or 'NULL_TREE' if no 'CALLBACK_OP' is specified. 14483 14484 -- GIMPLE function: tree walk_gimple_op (gimple stmt, walk_tree_fn 14485 callback_op, struct walk_stmt_info *wi) 14486 Use this function to walk the operands of statement 'STMT'. Every 14487 operand is walked via 'walk_tree' with optional state information 14488 in 'WI'. 14489 14490 'CALLBACK_OP' is called on each operand of 'STMT' via 'walk_tree'. 14491 Additional parameters to 'walk_tree' must be stored in 'WI'. For 14492 each operand 'OP', 'walk_tree' is called as: 14493 14494 walk_tree (&OP, CALLBACK_OP, WI, PSET) 14495 14496 If 'CALLBACK_OP' returns non-'NULL' for an operand, the remaining 14497 operands are not scanned. The return value is that returned by the 14498 last call to 'walk_tree', or 'NULL_TREE' if no 'CALLBACK_OP' is 14499 specified. 14500 14501 -- GIMPLE function: tree walk_gimple_seq (gimple_seq seq, walk_stmt_fn 14502 callback_stmt, walk_tree_fn callback_op, struct walk_stmt_info 14503 *wi) 14504 This function walks all the statements in the sequence 'SEQ' 14505 calling 'walk_gimple_stmt' on each one. 'WI' is as in 14506 'walk_gimple_stmt'. If 'walk_gimple_stmt' returns non-'NULL', the 14507 walk is stopped and the value returned. Otherwise, all the 14508 statements are walked and 'NULL_TREE' returned. 14509 14510 14511File: gccint.info, Node: Tree SSA, Next: RTL, Prev: GIMPLE, Up: Top 14512 1451313 Analysis and Optimization of GIMPLE tuples 14514********************************************* 14515 14516GCC uses three main intermediate languages to represent the program 14517during compilation: GENERIC, GIMPLE and RTL. GENERIC is a 14518language-independent representation generated by each front end. It is 14519used to serve as an interface between the parser and optimizer. GENERIC 14520is a common representation that is able to represent programs written in 14521all the languages supported by GCC. 14522 14523 GIMPLE and RTL are used to optimize the program. GIMPLE is used for 14524target and language independent optimizations (e.g., inlining, constant 14525propagation, tail call elimination, redundancy elimination, etc). Much 14526like GENERIC, GIMPLE is a language independent, tree based 14527representation. However, it differs from GENERIC in that the GIMPLE 14528grammar is more restrictive: expressions contain no more than 3 operands 14529(except function calls), it has no control flow structures and 14530expressions with side effects are only allowed on the right hand side of 14531assignments. See the chapter describing GENERIC and GIMPLE for more 14532details. 14533 14534 This chapter describes the data structures and functions used in the 14535GIMPLE optimizers (also known as "tree optimizers" or "middle end"). In 14536particular, it focuses on all the macros, data structures, functions and 14537programming constructs needed to implement optimization passes for 14538GIMPLE. 14539 14540* Menu: 14541 14542* Annotations:: Attributes for variables. 14543* SSA Operands:: SSA names referenced by GIMPLE statements. 14544* SSA:: Static Single Assignment representation. 14545* Alias analysis:: Representing aliased loads and stores. 14546* Memory model:: Memory model used by the middle-end. 14547 14548 14549File: gccint.info, Node: Annotations, Next: SSA Operands, Up: Tree SSA 14550 1455113.1 Annotations 14552================ 14553 14554The optimizers need to associate attributes with variables during the 14555optimization process. For instance, we need to know whether a variable 14556has aliases. All these attributes are stored in data structures called 14557annotations which are then linked to the field 'ann' in 'struct 14558tree_common'. 14559 14560 14561File: gccint.info, Node: SSA Operands, Next: SSA, Prev: Annotations, Up: Tree SSA 14562 1456313.2 SSA Operands 14564================= 14565 14566Almost every GIMPLE statement will contain a reference to a variable or 14567memory location. Since statements come in different shapes and sizes, 14568their operands are going to be located at various spots inside the 14569statement's tree. To facilitate access to the statement's operands, 14570they are organized into lists associated inside each statement's 14571annotation. Each element in an operand list is a pointer to a 14572'VAR_DECL', 'PARM_DECL' or 'SSA_NAME' tree node. This provides a very 14573convenient way of examining and replacing operands. 14574 14575 Data flow analysis and optimization is done on all tree nodes 14576representing variables. Any node for which 'SSA_VAR_P' returns nonzero 14577is considered when scanning statement operands. However, not all 14578'SSA_VAR_P' variables are processed in the same way. For the purposes 14579of optimization, we need to distinguish between references to local 14580scalar variables and references to globals, statics, structures, arrays, 14581aliased variables, etc. The reason is simple, the compiler can gather 14582complete data flow information for a local scalar. On the other hand, a 14583global variable may be modified by a function call, it may not be 14584possible to keep track of all the elements of an array or the fields of 14585a structure, etc. 14586 14587 The operand scanner gathers two kinds of operands: "real" and 14588"virtual". An operand for which 'is_gimple_reg' returns true is 14589considered real, otherwise it is a virtual operand. We also distinguish 14590between uses and definitions. An operand is used if its value is loaded 14591by the statement (e.g., the operand at the RHS of an assignment). If 14592the statement assigns a new value to the operand, the operand is 14593considered a definition (e.g., the operand at the LHS of an assignment). 14594 14595 Virtual and real operands also have very different data flow 14596properties. Real operands are unambiguous references to the full object 14597that they represent. For instance, given 14598 14599 { 14600 int a, b; 14601 a = b 14602 } 14603 14604 Since 'a' and 'b' are non-aliased locals, the statement 'a = b' will 14605have one real definition and one real use because variable 'a' is 14606completely modified with the contents of variable 'b'. Real definition 14607are also known as "killing definitions". Similarly, the use of 'b' 14608reads all its bits. 14609 14610 In contrast, virtual operands are used with variables that can have a 14611partial or ambiguous reference. This includes structures, arrays, 14612globals, and aliased variables. In these cases, we have two types of 14613definitions. For globals, structures, and arrays, we can determine from 14614a statement whether a variable of these types has a killing definition. 14615If the variable does, then the statement is marked as having a "must 14616definition" of that variable. However, if a statement is only defining 14617a part of the variable (i.e. a field in a structure), or if we know that 14618a statement might define the variable but we cannot say for sure, then 14619we mark that statement as having a "may definition". For instance, 14620given 14621 14622 { 14623 int a, b, *p; 14624 14625 if (...) 14626 p = &a; 14627 else 14628 p = &b; 14629 *p = 5; 14630 return *p; 14631 } 14632 14633 The assignment '*p = 5' may be a definition of 'a' or 'b'. If we 14634cannot determine statically where 'p' is pointing to at the time of the 14635store operation, we create virtual definitions to mark that statement as 14636a potential definition site for 'a' and 'b'. Memory loads are similarly 14637marked with virtual use operands. Virtual operands are shown in tree 14638dumps right before the statement that contains them. To request a tree 14639dump with virtual operands, use the '-vops' option to '-fdump-tree': 14640 14641 { 14642 int a, b, *p; 14643 14644 if (...) 14645 p = &a; 14646 else 14647 p = &b; 14648 # a = VDEF <a> 14649 # b = VDEF <b> 14650 *p = 5; 14651 14652 # VUSE <a> 14653 # VUSE <b> 14654 return *p; 14655 } 14656 14657 Notice that 'VDEF' operands have two copies of the referenced variable. 14658This indicates that this is not a killing definition of that variable. 14659In this case we refer to it as a "may definition" or "aliased store". 14660The presence of the second copy of the variable in the 'VDEF' operand 14661will become important when the function is converted into SSA form. 14662This will be used to link all the non-killing definitions to prevent 14663optimizations from making incorrect assumptions about them. 14664 14665 Operands are updated as soon as the statement is finished via a call to 14666'update_stmt'. If statement elements are changed via 'SET_USE' or 14667'SET_DEF', then no further action is required (i.e., those macros take 14668care of updating the statement). If changes are made by manipulating 14669the statement's tree directly, then a call must be made to 'update_stmt' 14670when complete. Calling one of the 'bsi_insert' routines or 14671'bsi_replace' performs an implicit call to 'update_stmt'. 14672 1467313.2.1 Operand Iterators And Access Routines 14674-------------------------------------------- 14675 14676Operands are collected by 'tree-ssa-operands.c'. They are stored inside 14677each statement's annotation and can be accessed through either the 14678operand iterators or an access routine. 14679 14680 The following access routines are available for examining operands: 14681 14682 1. 'SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return 14683 NULL unless there is exactly one operand matching the specified 14684 flags. If there is exactly one operand, the operand is returned as 14685 either a 'tree', 'def_operand_p', or 'use_operand_p'. 14686 14687 tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags); 14688 use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES); 14689 def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS); 14690 14691 2. 'ZERO_SSA_OPERANDS': This macro returns true if there are no 14692 operands matching the specified flags. 14693 14694 if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS)) 14695 return; 14696 14697 3. 'NUM_SSA_OPERANDS': This macro Returns the number of operands 14698 matching 'flags'. This actually executes a loop to perform the 14699 count, so only use this if it is really needed. 14700 14701 int count = NUM_SSA_OPERANDS (stmt, flags) 14702 14703 If you wish to iterate over some or all operands, use the 14704'FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator. For example, to print 14705all the operands for a statement: 14706 14707 void 14708 print_ops (tree stmt) 14709 { 14710 ssa_op_iter; 14711 tree var; 14712 14713 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS) 14714 print_generic_expr (stderr, var, TDF_SLIM); 14715 } 14716 14717 How to choose the appropriate iterator: 14718 14719 1. Determine whether you are need to see the operand pointers, or just 14720 the trees, and choose the appropriate macro: 14721 14722 Need Macro: 14723 ---- ------- 14724 use_operand_p FOR_EACH_SSA_USE_OPERAND 14725 def_operand_p FOR_EACH_SSA_DEF_OPERAND 14726 tree FOR_EACH_SSA_TREE_OPERAND 14727 14728 2. You need to declare a variable of the type you are interested in, 14729 and an ssa_op_iter structure which serves as the loop controlling 14730 variable. 14731 14732 3. Determine which operands you wish to use, and specify the flags of 14733 those you are interested in. They are documented in 14734 'tree-ssa-operands.h': 14735 14736 #define SSA_OP_USE 0x01 /* Real USE operands. */ 14737 #define SSA_OP_DEF 0x02 /* Real DEF operands. */ 14738 #define SSA_OP_VUSE 0x04 /* VUSE operands. */ 14739 #define SSA_OP_VDEF 0x08 /* VDEF operands. */ 14740 14741 /* These are commonly grouped operand flags. */ 14742 #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE) 14743 #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VDEF) 14744 #define SSA_OP_ALL_VIRTUALS (SSA_OP_VIRTUAL_USES | SSA_OP_VIRTUAL_DEFS) 14745 #define SSA_OP_ALL_USES (SSA_OP_VIRTUAL_USES | SSA_OP_USE) 14746 #define SSA_OP_ALL_DEFS (SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF) 14747 #define SSA_OP_ALL_OPERANDS (SSA_OP_ALL_USES | SSA_OP_ALL_DEFS) 14748 14749 So if you want to look at the use pointers for all the 'USE' and 'VUSE' 14750operands, you would do something like: 14751 14752 use_operand_p use_p; 14753 ssa_op_iter iter; 14754 14755 FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE)) 14756 { 14757 process_use_ptr (use_p); 14758 } 14759 14760 The 'TREE' macro is basically the same as the 'USE' and 'DEF' macros, 14761only with the use or def dereferenced via 'USE_FROM_PTR (use_p)' and 14762'DEF_FROM_PTR (def_p)'. Since we aren't using operand pointers, use and 14763defs flags can be mixed. 14764 14765 tree var; 14766 ssa_op_iter iter; 14767 14768 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE) 14769 { 14770 print_generic_expr (stderr, var, TDF_SLIM); 14771 } 14772 14773 'VDEF's are broken into two flags, one for the 'DEF' portion 14774('SSA_OP_VDEF') and one for the USE portion ('SSA_OP_VUSE'). 14775 14776 There are many examples in the code, in addition to the documentation 14777in 'tree-ssa-operands.h' and 'ssa-iterators.h'. 14778 14779 There are also a couple of variants on the stmt iterators regarding PHI 14780nodes. 14781 14782 'FOR_EACH_PHI_ARG' Works exactly like 'FOR_EACH_SSA_USE_OPERAND', 14783except it works over 'PHI' arguments instead of statement operands. 14784 14785 /* Look at every virtual PHI use. */ 14786 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES) 14787 { 14788 my_code; 14789 } 14790 14791 /* Look at every real PHI use. */ 14792 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES) 14793 my_code; 14794 14795 /* Look at every PHI use. */ 14796 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES) 14797 my_code; 14798 14799 'FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like 14800'FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a 14801statement or a 'PHI' node. These should be used when it is appropriate 14802but they are not quite as efficient as the individual 'FOR_EACH_PHI' and 14803'FOR_EACH_SSA' routines. 14804 14805 FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags) 14806 { 14807 my_code; 14808 } 14809 14810 FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags) 14811 { 14812 my_code; 14813 } 14814 1481513.2.2 Immediate Uses 14816--------------------- 14817 14818Immediate use information is now always available. Using the immediate 14819use iterators, you may examine every use of any 'SSA_NAME'. For 14820instance, to change each use of 'ssa_var' to 'ssa_var2' and call 14821fold_stmt on each stmt after that is done: 14822 14823 use_operand_p imm_use_p; 14824 imm_use_iterator iterator; 14825 tree ssa_var, stmt; 14826 14827 14828 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 14829 { 14830 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 14831 SET_USE (imm_use_p, ssa_var_2); 14832 fold_stmt (stmt); 14833 } 14834 14835 There are 2 iterators which can be used. 'FOR_EACH_IMM_USE_FAST' is 14836used when the immediate uses are not changed, i.e., you are looking at 14837the uses, but not setting them. 14838 14839 If they do get changed, then care must be taken that things are not 14840changed under the iterators, so use the 'FOR_EACH_IMM_USE_STMT' and 14841'FOR_EACH_IMM_USE_ON_STMT' iterators. They attempt to preserve the 14842sanity of the use list by moving all the uses for a statement into a 14843controlled position, and then iterating over those uses. Then the 14844optimization can manipulate the stmt when all the uses have been 14845processed. This is a little slower than the FAST version since it adds 14846a placeholder element and must sort through the list a bit for each 14847statement. This placeholder element must be also be removed if the loop 14848is terminated early. The macro 'BREAK_FROM_IMM_USE_SAFE' is provided to 14849do this : 14850 14851 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 14852 { 14853 if (stmt == last_stmt) 14854 BREAK_FROM_SAFE_IMM_USE (iter); 14855 14856 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 14857 SET_USE (imm_use_p, ssa_var_2); 14858 fold_stmt (stmt); 14859 } 14860 14861 There are checks in 'verify_ssa' which verify that the immediate use 14862list is up to date, as well as checking that an optimization didn't 14863break from the loop without using this macro. It is safe to simply 14864'break'; from a 'FOR_EACH_IMM_USE_FAST' traverse. 14865 14866 Some useful functions and macros: 14867 1. 'has_zero_uses (ssa_var)' : Returns true if there are no uses of 14868 'ssa_var'. 14869 2. 'has_single_use (ssa_var)' : Returns true if there is only a single 14870 use of 'ssa_var'. 14871 3. 'single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' : 14872 Returns true if there is only a single use of 'ssa_var', and also 14873 returns the use pointer and statement it occurs in, in the second 14874 and third parameters. 14875 4. 'num_imm_uses (ssa_var)' : Returns the number of immediate uses of 14876 'ssa_var'. It is better not to use this if possible since it 14877 simply utilizes a loop to count the uses. 14878 5. 'PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a 'PHI' node, 14879 return the index number for the use. An assert is triggered if the 14880 use isn't located in a 'PHI' node. 14881 6. 'USE_STMT (use_p)' : Return the statement a use occurs in. 14882 14883 Note that uses are not put into an immediate use list until their 14884statement is actually inserted into the instruction stream via a 'bsi_*' 14885routine. 14886 14887 It is also still possible to utilize lazy updating of statements, but 14888this should be used only when absolutely required. Both alias analysis 14889and the dominator optimizations currently do this. 14890 14891 When lazy updating is being used, the immediate use information is out 14892of date and cannot be used reliably. Lazy updating is achieved by 14893simply marking statements modified via calls to 'gimple_set_modified' 14894instead of 'update_stmt'. When lazy updating is no longer required, all 14895the modified statements must have 'update_stmt' called in order to bring 14896them up to date. This must be done before the optimization is finished, 14897or 'verify_ssa' will trigger an abort. 14898 14899 This is done with a simple loop over the instruction stream: 14900 block_stmt_iterator bsi; 14901 basic_block bb; 14902 FOR_EACH_BB (bb) 14903 { 14904 for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi)) 14905 update_stmt_if_modified (bsi_stmt (bsi)); 14906 } 14907 14908 14909File: gccint.info, Node: SSA, Next: Alias analysis, Prev: SSA Operands, Up: Tree SSA 14910 1491113.3 Static Single Assignment 14912============================= 14913 14914Most of the tree optimizers rely on the data flow information provided 14915by the Static Single Assignment (SSA) form. We implement the SSA form 14916as described in 'R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K. 14917Zadeck. Efficiently Computing Static Single Assignment Form and the 14918Control Dependence Graph. ACM Transactions on Programming Languages and 14919Systems, 13(4):451-490, October 1991'. 14920 14921 The SSA form is based on the premise that program variables are 14922assigned in exactly one location in the program. Multiple assignments 14923to the same variable create new versions of that variable. Naturally, 14924actual programs are seldom in SSA form initially because variables tend 14925to be assigned multiple times. The compiler modifies the program 14926representation so that every time a variable is assigned in the code, a 14927new version of the variable is created. Different versions of the same 14928variable are distinguished by subscripting the variable name with its 14929version number. Variables used in the right-hand side of expressions 14930are renamed so that their version number matches that of the most recent 14931assignment. 14932 14933 We represent variable versions using 'SSA_NAME' nodes. The renaming 14934process in 'tree-ssa.c' wraps every real and virtual operand with an 14935'SSA_NAME' node which contains the version number and the statement that 14936created the 'SSA_NAME'. Only definitions and virtual definitions may 14937create new 'SSA_NAME' nodes. 14938 14939 Sometimes, flow of control makes it impossible to determine the most 14940recent version of a variable. In these cases, the compiler inserts an 14941artificial definition for that variable called "PHI function" or "PHI 14942node". This new definition merges all the incoming versions of the 14943variable to create a new name for it. For instance, 14944 14945 if (...) 14946 a_1 = 5; 14947 else if (...) 14948 a_2 = 2; 14949 else 14950 a_3 = 13; 14951 14952 # a_4 = PHI <a_1, a_2, a_3> 14953 return a_4; 14954 14955 Since it is not possible to determine which of the three branches will 14956be taken at runtime, we don't know which of 'a_1', 'a_2' or 'a_3' to use 14957at the return statement. So, the SSA renamer creates a new version 14958'a_4' which is assigned the result of "merging" 'a_1', 'a_2' and 'a_3'. 14959Hence, PHI nodes mean "one of these operands. I don't know which". 14960 14961 The following functions can be used to examine PHI nodes 14962 14963 -- Function: gimple_phi_result (PHI) 14964 Returns the 'SSA_NAME' created by PHI node PHI (i.e., PHI's LHS). 14965 14966 -- Function: gimple_phi_num_args (PHI) 14967 Returns the number of arguments in PHI. This number is exactly the 14968 number of incoming edges to the basic block holding PHI. 14969 14970 -- Function: gimple_phi_arg (PHI, I) 14971 Returns Ith argument of PHI. 14972 14973 -- Function: gimple_phi_arg_edge (PHI, I) 14974 Returns the incoming edge for the Ith argument of PHI. 14975 14976 -- Function: gimple_phi_arg_def (PHI, I) 14977 Returns the 'SSA_NAME' for the Ith argument of PHI. 14978 1497913.3.1 Preserving the SSA form 14980------------------------------ 14981 14982Some optimization passes make changes to the function that invalidate 14983the SSA property. This can happen when a pass has added new symbols or 14984changed the program so that variables that were previously aliased 14985aren't anymore. Whenever something like this happens, the affected 14986symbols must be renamed into SSA form again. Transformations that emit 14987new code or replicate existing statements will also need to update the 14988SSA form. 14989 14990 Since GCC implements two different SSA forms for register and virtual 14991variables, keeping the SSA form up to date depends on whether you are 14992updating register or virtual names. In both cases, the general idea 14993behind incremental SSA updates is similar: when new SSA names are 14994created, they typically are meant to replace other existing names in the 14995program. 14996 14997 For instance, given the following code: 14998 14999 1 L0: 15000 2 x_1 = PHI (0, x_5) 15001 3 if (x_1 < 10) 15002 4 if (x_1 > 7) 15003 5 y_2 = 0 15004 6 else 15005 7 y_3 = x_1 + x_7 15006 8 endif 15007 9 x_5 = x_1 + 1 15008 10 goto L0; 15009 11 endif 15010 15011 Suppose that we insert new names 'x_10' and 'x_11' (lines '4' and '8'). 15012 15013 1 L0: 15014 2 x_1 = PHI (0, x_5) 15015 3 if (x_1 < 10) 15016 4 x_10 = ... 15017 5 if (x_1 > 7) 15018 6 y_2 = 0 15019 7 else 15020 8 x_11 = ... 15021 9 y_3 = x_1 + x_7 15022 10 endif 15023 11 x_5 = x_1 + 1 15024 12 goto L0; 15025 13 endif 15026 15027 We want to replace all the uses of 'x_1' with the new definitions of 15028'x_10' and 'x_11'. Note that the only uses that should be replaced are 15029those at lines '5', '9' and '11'. Also, the use of 'x_7' at line '9' 15030should _not_ be replaced (this is why we cannot just mark symbol 'x' for 15031renaming). 15032 15033 Additionally, we may need to insert a PHI node at line '11' because 15034that is a merge point for 'x_10' and 'x_11'. So the use of 'x_1' at 15035line '11' will be replaced with the new PHI node. The insertion of PHI 15036nodes is optional. They are not strictly necessary to preserve the SSA 15037form, and depending on what the caller inserted, they may not even be 15038useful for the optimizers. 15039 15040 Updating the SSA form is a two step process. First, the pass has to 15041identify which names need to be updated and/or which symbols need to be 15042renamed into SSA form for the first time. When new names are introduced 15043to replace existing names in the program, the mapping between the old 15044and the new names are registered by calling 'register_new_name_mapping' 15045(note that if your pass creates new code by duplicating basic blocks, 15046the call to 'tree_duplicate_bb' will set up the necessary mappings 15047automatically). 15048 15049 After the replacement mappings have been registered and new symbols 15050marked for renaming, a call to 'update_ssa' makes the registered 15051changes. This can be done with an explicit call or by creating 'TODO' 15052flags in the 'tree_opt_pass' structure for your pass. There are several 15053'TODO' flags that control the behavior of 'update_ssa': 15054 15055 * 'TODO_update_ssa'. Update the SSA form inserting PHI nodes for 15056 newly exposed symbols and virtual names marked for updating. When 15057 updating real names, only insert PHI nodes for a real name 'O_j' in 15058 blocks reached by all the new and old definitions for 'O_j'. If 15059 the iterated dominance frontier for 'O_j' is not pruned, we may end 15060 up inserting PHI nodes in blocks that have one or more edges with 15061 no incoming definition for 'O_j'. This would lead to uninitialized 15062 warnings for 'O_j''s symbol. 15063 15064 * 'TODO_update_ssa_no_phi'. Update the SSA form without inserting 15065 any new PHI nodes at all. This is used by passes that have either 15066 inserted all the PHI nodes themselves or passes that need only to 15067 patch use-def and def-def chains for virtuals (e.g., DCE). 15068 15069 * 'TODO_update_ssa_full_phi'. Insert PHI nodes everywhere they are 15070 needed. No pruning of the IDF is done. This is used by passes 15071 that need the PHI nodes for 'O_j' even if it means that some 15072 arguments will come from the default definition of 'O_j''s symbol 15073 (e.g., 'pass_linear_transform'). 15074 15075 WARNING: If you need to use this flag, chances are that your pass 15076 may be doing something wrong. Inserting PHI nodes for an old name 15077 where not all edges carry a new replacement may lead to silent 15078 codegen errors or spurious uninitialized warnings. 15079 15080 * 'TODO_update_ssa_only_virtuals'. Passes that update the SSA form 15081 on their own may want to delegate the updating of virtual names to 15082 the generic updater. Since FUD chains are easier to maintain, this 15083 simplifies the work they need to do. NOTE: If this flag is used, 15084 any OLD->NEW mappings for real names are explicitly destroyed and 15085 only the symbols marked for renaming are processed. 15086 1508713.3.2 Examining 'SSA_NAME' nodes 15088--------------------------------- 15089 15090The following macros can be used to examine 'SSA_NAME' nodes 15091 15092 -- Macro: SSA_NAME_DEF_STMT (VAR) 15093 Returns the statement S that creates the 'SSA_NAME' VAR. If S is 15094 an empty statement (i.e., 'IS_EMPTY_STMT (S)' returns 'true'), it 15095 means that the first reference to this variable is a USE or a VUSE. 15096 15097 -- Macro: SSA_NAME_VERSION (VAR) 15098 Returns the version number of the 'SSA_NAME' object VAR. 15099 1510013.3.3 Walking the dominator tree 15101--------------------------------- 15102 15103 -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB) 15104 15105 This function walks the dominator tree for the current CFG calling 15106 a set of callback functions defined in STRUCT DOM_WALK_DATA in 15107 'domwalk.h'. The call back functions you need to define give you 15108 hooks to execute custom code at various points during traversal: 15109 15110 1. Once to initialize any local data needed while processing BB 15111 and its children. This local data is pushed into an internal 15112 stack which is automatically pushed and popped as the walker 15113 traverses the dominator tree. 15114 15115 2. Once before traversing all the statements in the BB. 15116 15117 3. Once for every statement inside BB. 15118 15119 4. Once after traversing all the statements and before recursing 15120 into BB's dominator children. 15121 15122 5. It then recurses into all the dominator children of BB. 15123 15124 6. After recursing into all the dominator children of BB it can, 15125 optionally, traverse every statement in BB again (i.e., 15126 repeating steps 2 and 3). 15127 15128 7. Once after walking the statements in BB and BB's dominator 15129 children. At this stage, the block local data stack is 15130 popped. 15131 15132 15133File: gccint.info, Node: Alias analysis, Next: Memory model, Prev: SSA, Up: Tree SSA 15134 1513513.4 Alias analysis 15136=================== 15137 15138Alias analysis in GIMPLE SSA form consists of two pieces. First the 15139virtual SSA web ties conflicting memory accesses and provides a SSA 15140use-def chain and SSA immediate-use chains for walking possibly 15141dependent memory accesses. Second an alias-oracle can be queried to 15142disambiguate explicit and implicit memory references. 15143 15144 1. Memory SSA form. 15145 15146 All statements that may use memory have exactly one accompanied use 15147 of a virtual SSA name that represents the state of memory at the 15148 given point in the IL. 15149 15150 All statements that may define memory have exactly one accompanied 15151 definition of a virtual SSA name using the previous state of memory 15152 and defining the new state of memory after the given point in the 15153 IL. 15154 15155 int i; 15156 int foo (void) 15157 { 15158 # .MEM_3 = VDEF <.MEM_2(D)> 15159 i = 1; 15160 # VUSE <.MEM_3> 15161 return i; 15162 } 15163 15164 The virtual SSA names in this case are '.MEM_2(D)' and '.MEM_3'. 15165 The store to the global variable 'i' defines '.MEM_3' invalidating 15166 '.MEM_2(D)'. The load from 'i' uses that new state '.MEM_3'. 15167 15168 The virtual SSA web serves as constraints to SSA optimizers 15169 preventing illegitimate code-motion and optimization. It also 15170 provides a way to walk related memory statements. 15171 15172 2. Points-to and escape analysis. 15173 15174 Points-to analysis builds a set of constraints from the GIMPLE SSA 15175 IL representing all pointer operations and facts we do or do not 15176 know about pointers. Solving this set of constraints yields a 15177 conservatively correct solution for each pointer variable in the 15178 program (though we are only interested in SSA name pointers) as to 15179 what it may possibly point to. 15180 15181 This points-to solution for a given SSA name pointer is stored in 15182 the 'pt_solution' sub-structure of the 'SSA_NAME_PTR_INFO' record. 15183 The following accessor functions are available: 15184 15185 * 'pt_solution_includes' 15186 * 'pt_solutions_intersect' 15187 15188 Points-to analysis also computes the solution for two special set 15189 of pointers, 'ESCAPED' and 'CALLUSED'. Those represent all memory 15190 that has escaped the scope of analysis or that is used by pure or 15191 nested const calls. 15192 15193 3. Type-based alias analysis 15194 15195 Type-based alias analysis is frontend dependent though generic 15196 support is provided by the middle-end in 'alias.c'. TBAA code is 15197 used by both tree optimizers and RTL optimizers. 15198 15199 Every language that wishes to perform language-specific alias 15200 analysis should define a function that computes, given a 'tree' 15201 node, an alias set for the node. Nodes in different alias sets are 15202 not allowed to alias. For an example, see the C front-end function 15203 'c_get_alias_set'. 15204 15205 4. Tree alias-oracle 15206 15207 The tree alias-oracle provides means to disambiguate two memory 15208 references and memory references against statements. The following 15209 queries are available: 15210 15211 * 'refs_may_alias_p' 15212 * 'ref_maybe_used_by_stmt_p' 15213 * 'stmt_may_clobber_ref_p' 15214 15215 In addition to those two kind of statement walkers are available 15216 walking statements related to a reference ref. 15217 'walk_non_aliased_vuses' walks over dominating memory defining 15218 statements and calls back if the statement does not clobber ref 15219 providing the non-aliased VUSE. The walk stops at the first 15220 clobbering statement or if asked to. 'walk_aliased_vdefs' walks 15221 over dominating memory defining statements and calls back on each 15222 statement clobbering ref providing its aliasing VDEF. The walk 15223 stops if asked to. 15224 15225 15226File: gccint.info, Node: Memory model, Prev: Alias analysis, Up: Tree SSA 15227 1522813.5 Memory model 15229================= 15230 15231The memory model used by the middle-end models that of the C/C++ 15232languages. The middle-end has the notion of an effective type of a 15233memory region which is used for type-based alias analysis. 15234 15235 The following is a refinement of ISO C99 6.5/6, clarifying the block 15236copy case to follow common sense and extending the concept of a dynamic 15237effective type to objects with a declared type as required for C++. 15238 15239 The effective type of an object for an access to its stored value is 15240 the declared type of the object or the effective type determined by 15241 a previous store to it. If a value is stored into an object through 15242 an lvalue having a type that is not a character type, then the 15243 type of the lvalue becomes the effective type of the object for that 15244 access and for subsequent accesses that do not modify the stored value. 15245 If a value is copied into an object using memcpy or memmove, 15246 or is copied as an array of character type, then the effective type 15247 of the modified object for that access and for subsequent accesses that 15248 do not modify the value is undetermined. For all other accesses to an 15249 object, the effective type of the object is simply the type of the 15250 lvalue used for the access. 15251 15252 15253File: gccint.info, Node: RTL, Next: Control Flow, Prev: Tree SSA, Up: Top 15254 1525514 RTL Representation 15256********************* 15257 15258The last part of the compiler work is done on a low-level intermediate 15259representation called Register Transfer Language. In this language, the 15260instructions to be output are described, pretty much one by one, in an 15261algebraic form that describes what the instruction does. 15262 15263 RTL is inspired by Lisp lists. It has both an internal form, made up 15264of structures that point at other structures, and a textual form that is 15265used in the machine description and in printed debugging dumps. The 15266textual form uses nested parentheses to indicate the pointers in the 15267internal form. 15268 15269* Menu: 15270 15271* RTL Objects:: Expressions vs vectors vs strings vs integers. 15272* RTL Classes:: Categories of RTL expression objects, and their structure. 15273* Accessors:: Macros to access expression operands or vector elts. 15274* Special Accessors:: Macros to access specific annotations on RTL. 15275* Flags:: Other flags in an RTL expression. 15276* Machine Modes:: Describing the size and format of a datum. 15277* Constants:: Expressions with constant values. 15278* Regs and Memory:: Expressions representing register contents or memory. 15279* Arithmetic:: Expressions representing arithmetic on other expressions. 15280* Comparisons:: Expressions representing comparison of expressions. 15281* Bit-Fields:: Expressions representing bit-fields in memory or reg. 15282* Vector Operations:: Expressions involving vector datatypes. 15283* Conversions:: Extending, truncating, floating or fixing. 15284* RTL Declarations:: Declaring volatility, constancy, etc. 15285* Side Effects:: Expressions for storing in registers, etc. 15286* Incdec:: Embedded side-effects for autoincrement addressing. 15287* Assembler:: Representing 'asm' with operands. 15288* Debug Information:: Expressions representing debugging information. 15289* Insns:: Expression types for entire insns. 15290* Calls:: RTL representation of function call insns. 15291* Sharing:: Some expressions are unique; others *must* be copied. 15292* Reading RTL:: Reading textual RTL from a file. 15293 15294 15295File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL 15296 1529714.1 RTL Object Types 15298===================== 15299 15300RTL uses five kinds of objects: expressions, integers, wide integers, 15301strings and vectors. Expressions are the most important ones. An RTL 15302expression ("RTX", for short) is a C structure, but it is usually 15303referred to with a pointer; a type that is given the typedef name 'rtx'. 15304 15305 An integer is simply an 'int'; their written form uses decimal digits. 15306A wide integer is an integral object whose type is 'HOST_WIDE_INT'; 15307their written form uses decimal digits. 15308 15309 A string is a sequence of characters. In core it is represented as a 15310'char *' in usual C fashion, and it is written in C syntax as well. 15311However, strings in RTL may never be null. If you write an empty string 15312in a machine description, it is represented in core as a null pointer 15313rather than as a pointer to a null character. In certain contexts, 15314these null pointers instead of strings are valid. Within RTL code, 15315strings are most commonly found inside 'symbol_ref' expressions, but 15316they appear in other contexts in the RTL expressions that make up 15317machine descriptions. 15318 15319 In a machine description, strings are normally written with double 15320quotes, as you would in C. However, strings in machine descriptions may 15321extend over many lines, which is invalid C, and adjacent string 15322constants are not concatenated as they are in C. Any string constant 15323may be surrounded with a single set of parentheses. Sometimes this 15324makes the machine description easier to read. 15325 15326 There is also a special syntax for strings, which can be useful when C 15327code is embedded in a machine description. Wherever a string can 15328appear, it is also valid to write a C-style brace block. The entire 15329brace block, including the outermost pair of braces, is considered to be 15330the string constant. Double quote characters inside the braces are not 15331special. Therefore, if you write string constants in the C code, you 15332need not escape each quote character with a backslash. 15333 15334 A vector contains an arbitrary number of pointers to expressions. The 15335number of elements in the vector is explicitly present in the vector. 15336The written form of a vector consists of square brackets ('[...]') 15337surrounding the elements, in sequence and with whitespace separating 15338them. Vectors of length zero are not created; null pointers are used 15339instead. 15340 15341 Expressions are classified by "expression codes" (also called RTX 15342codes). The expression code is a name defined in 'rtl.def', which is 15343also (in uppercase) a C enumeration constant. The possible expression 15344codes and their meanings are machine-independent. The code of an RTX 15345can be extracted with the macro 'GET_CODE (X)' and altered with 15346'PUT_CODE (X, NEWCODE)'. 15347 15348 The expression code determines how many operands the expression 15349contains, and what kinds of objects they are. In RTL, unlike Lisp, you 15350cannot tell by looking at an operand what kind of object it is. 15351Instead, you must know from its context--from the expression code of the 15352containing expression. For example, in an expression of code 'subreg', 15353the first operand is to be regarded as an expression and the second 15354operand as a polynomial integer. In an expression of code 'plus', there 15355are two operands, both of which are to be regarded as expressions. In a 15356'symbol_ref' expression, there is one operand, which is to be regarded 15357as a string. 15358 15359 Expressions are written as parentheses containing the name of the 15360expression type, its flags and machine mode if any, and then the 15361operands of the expression (separated by spaces). 15362 15363 Expression code names in the 'md' file are written in lowercase, but 15364when they appear in C code they are written in uppercase. In this 15365manual, they are shown as follows: 'const_int'. 15366 15367 In a few contexts a null pointer is valid where an expression is 15368normally wanted. The written form of this is '(nil)'. 15369 15370 15371File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL 15372 1537314.2 RTL Classes and Formats 15374============================ 15375 15376The various expression codes are divided into several "classes", which 15377are represented by single characters. You can determine the class of an 15378RTX code with the macro 'GET_RTX_CLASS (CODE)'. Currently, 'rtl.def' 15379defines these classes: 15380 15381'RTX_OBJ' 15382 An RTX code that represents an actual object, such as a register 15383 ('REG') or a memory location ('MEM', 'SYMBOL_REF'). 'LO_SUM') is 15384 also included; instead, 'SUBREG' and 'STRICT_LOW_PART' are not in 15385 this class, but in class 'x'. 15386 15387'RTX_CONST_OBJ' 15388 An RTX code that represents a constant object. 'HIGH' is also 15389 included in this class. 15390 15391'RTX_COMPARE' 15392 An RTX code for a non-symmetric comparison, such as 'GEU' or 'LT'. 15393 15394'RTX_COMM_COMPARE' 15395 An RTX code for a symmetric (commutative) comparison, such as 'EQ' 15396 or 'ORDERED'. 15397 15398'RTX_UNARY' 15399 An RTX code for a unary arithmetic operation, such as 'NEG', 'NOT', 15400 or 'ABS'. This category also includes value extension (sign or 15401 zero) and conversions between integer and floating point. 15402 15403'RTX_COMM_ARITH' 15404 An RTX code for a commutative binary operation, such as 'PLUS' or 15405 'AND'. 'NE' and 'EQ' are comparisons, so they have class '<'. 15406 15407'RTX_BIN_ARITH' 15408 An RTX code for a non-commutative binary operation, such as 15409 'MINUS', 'DIV', or 'ASHIFTRT'. 15410 15411'RTX_BITFIELD_OPS' 15412 An RTX code for a bit-field operation. Currently only 15413 'ZERO_EXTRACT' and 'SIGN_EXTRACT'. These have three inputs and are 15414 lvalues (so they can be used for insertion as well). *Note 15415 Bit-Fields::. 15416 15417'RTX_TERNARY' 15418 An RTX code for other three input operations. Currently only 15419 'IF_THEN_ELSE', 'VEC_MERGE', 'SIGN_EXTRACT', 'ZERO_EXTRACT', and 15420 'FMA'. 15421 15422'RTX_INSN' 15423 An RTX code for an entire instruction: 'INSN', 'JUMP_INSN', and 15424 'CALL_INSN'. *Note Insns::. 15425 15426'RTX_MATCH' 15427 An RTX code for something that matches in insns, such as 15428 'MATCH_DUP'. These only occur in machine descriptions. 15429 15430'RTX_AUTOINC' 15431 An RTX code for an auto-increment addressing mode, such as 15432 'POST_INC'. 'XEXP (X, 0)' gives the auto-modified register. 15433 15434'RTX_EXTRA' 15435 All other RTX codes. This category includes the remaining codes 15436 used only in machine descriptions ('DEFINE_*', etc.). It also 15437 includes all the codes describing side effects ('SET', 'USE', 15438 'CLOBBER', etc.) and the non-insns that may appear on an insn 15439 chain, such as 'NOTE', 'BARRIER', and 'CODE_LABEL'. 'SUBREG' is 15440 also part of this class. 15441 15442 For each expression code, 'rtl.def' specifies the number of contained 15443objects and their kinds using a sequence of characters called the 15444"format" of the expression code. For example, the format of 'subreg' is 15445'ep'. 15446 15447 These are the most commonly used format characters: 15448 15449'e' 15450 An expression (actually a pointer to an expression). 15451 15452'i' 15453 An integer. 15454 15455'w' 15456 A wide integer. 15457 15458's' 15459 A string. 15460 15461'E' 15462 A vector of expressions. 15463 15464 A few other format characters are used occasionally: 15465 15466'u' 15467 'u' is equivalent to 'e' except that it is printed differently in 15468 debugging dumps. It is used for pointers to insns. 15469 15470'n' 15471 'n' is equivalent to 'i' except that it is printed differently in 15472 debugging dumps. It is used for the line number or code number of 15473 a 'note' insn. 15474 15475'S' 15476 'S' indicates a string which is optional. In the RTL objects in 15477 core, 'S' is equivalent to 's', but when the object is read, from 15478 an 'md' file, the string value of this operand may be omitted. An 15479 omitted string is taken to be the null string. 15480 15481'V' 15482 'V' indicates a vector which is optional. In the RTL objects in 15483 core, 'V' is equivalent to 'E', but when the object is read from an 15484 'md' file, the vector value of this operand may be omitted. An 15485 omitted vector is effectively the same as a vector of no elements. 15486 15487'B' 15488 'B' indicates a pointer to basic block structure. 15489 15490'p' 15491 A polynomial integer. At present this is used only for 15492 'SUBREG_BYTE'. 15493 15494'0' 15495 '0' means a slot whose contents do not fit any normal category. 15496 '0' slots are not printed at all in dumps, and are often used in 15497 special ways by small parts of the compiler. 15498 15499 There are macros to get the number of operands and the format of an 15500expression code: 15501 15502'GET_RTX_LENGTH (CODE)' 15503 Number of operands of an RTX of code CODE. 15504 15505'GET_RTX_FORMAT (CODE)' 15506 The format of an RTX of code CODE, as a C string. 15507 15508 Some classes of RTX codes always have the same format. For example, it 15509is safe to assume that all comparison operations have format 'ee'. 15510 15511'1' 15512 All codes of this class have format 'e'. 15513 15514'<' 15515'c' 15516'2' 15517 All codes of these classes have format 'ee'. 15518 15519'b' 15520'3' 15521 All codes of these classes have format 'eee'. 15522 15523'i' 15524 All codes of this class have formats that begin with 'iuueiee'. 15525 *Note Insns::. Note that not all RTL objects linked onto an insn 15526 chain are of class 'i'. 15527 15528'o' 15529'm' 15530'x' 15531 You can make no assumptions about the format of these codes. 15532 15533 15534File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL 15535 1553614.3 Access to Operands 15537======================= 15538 15539Operands of expressions are accessed using the macros 'XEXP', 'XINT', 15540'XWINT' and 'XSTR'. Each of these macros takes two arguments: an 15541expression-pointer (RTX) and an operand number (counting from zero). 15542Thus, 15543 15544 XEXP (X, 2) 15545 15546accesses operand 2 of expression X, as an expression. 15547 15548 XINT (X, 2) 15549 15550accesses the same operand as an integer. 'XSTR', used in the same 15551fashion, would access it as a string. 15552 15553 Any operand can be accessed as an integer, as an expression or as a 15554string. You must choose the correct method of access for the kind of 15555value actually stored in the operand. You would do this based on the 15556expression code of the containing expression. That is also how you 15557would know how many operands there are. 15558 15559 For example, if X is an 'int_list' expression, you know that it has two 15560operands which can be correctly accessed as 'XINT (X, 0)' and 'XEXP (X, 155611)'. Incorrect accesses like 'XEXP (X, 0)' and 'XINT (X, 1)' would 15562compile, but would trigger an internal compiler error when rtl checking 15563is enabled. Nothing stops you from writing 'XEXP (X, 28)' either, but 15564this will access memory past the end of the expression with 15565unpredictable results. 15566 15567 Access to operands which are vectors is more complicated. You can use 15568the macro 'XVEC' to get the vector-pointer itself, or the macros 15569'XVECEXP' and 'XVECLEN' to access the elements and length of a vector. 15570 15571'XVEC (EXP, IDX)' 15572 Access the vector-pointer which is operand number IDX in EXP. 15573 15574'XVECLEN (EXP, IDX)' 15575 Access the length (number of elements) in the vector which is in 15576 operand number IDX in EXP. This value is an 'int'. 15577 15578'XVECEXP (EXP, IDX, ELTNUM)' 15579 Access element number ELTNUM in the vector which is in operand 15580 number IDX in EXP. This value is an RTX. 15581 15582 It is up to you to make sure that ELTNUM is not negative and is 15583 less than 'XVECLEN (EXP, IDX)'. 15584 15585 All the macros defined in this section expand into lvalues and 15586therefore can be used to assign the operands, lengths and vector 15587elements as well as to access them. 15588 15589 15590File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL 15591 1559214.4 Access to Special Operands 15593=============================== 15594 15595Some RTL nodes have special annotations associated with them. 15596 15597'MEM' 15598 'MEM_ALIAS_SET (X)' 15599 If 0, X is not in any alias set, and may alias anything. 15600 Otherwise, X can only alias 'MEM's in a conflicting alias set. 15601 This value is set in a language-dependent manner in the 15602 front-end, and should not be altered in the back-end. In some 15603 front-ends, these numbers may correspond in some way to types, 15604 or other language-level entities, but they need not, and the 15605 back-end makes no such assumptions. These set numbers are 15606 tested with 'alias_sets_conflict_p'. 15607 15608 'MEM_EXPR (X)' 15609 If this register is known to hold the value of some user-level 15610 declaration, this is that tree node. It may also be a 15611 'COMPONENT_REF', in which case this is some field reference, 15612 and 'TREE_OPERAND (X, 0)' contains the declaration, or another 15613 'COMPONENT_REF', or null if there is no compile-time object 15614 associated with the reference. 15615 15616 'MEM_OFFSET_KNOWN_P (X)' 15617 True if the offset of the memory reference from 'MEM_EXPR' is 15618 known. 'MEM_OFFSET (X)' provides the offset if so. 15619 15620 'MEM_OFFSET (X)' 15621 The offset from the start of 'MEM_EXPR'. The value is only 15622 valid if 'MEM_OFFSET_KNOWN_P (X)' is true. 15623 15624 'MEM_SIZE_KNOWN_P (X)' 15625 True if the size of the memory reference is known. 'MEM_SIZE 15626 (X)' provides its size if so. 15627 15628 'MEM_SIZE (X)' 15629 The size in bytes of the memory reference. This is mostly 15630 relevant for 'BLKmode' references as otherwise the size is 15631 implied by the mode. The value is only valid if 15632 'MEM_SIZE_KNOWN_P (X)' is true. 15633 15634 'MEM_ALIGN (X)' 15635 The known alignment in bits of the memory reference. 15636 15637 'MEM_ADDR_SPACE (X)' 15638 The address space of the memory reference. This will commonly 15639 be zero for the generic address space. 15640 15641'REG' 15642 'ORIGINAL_REGNO (X)' 15643 This field holds the number the register "originally" had; for 15644 a pseudo register turned into a hard reg this will hold the 15645 old pseudo register number. 15646 15647 'REG_EXPR (X)' 15648 If this register is known to hold the value of some user-level 15649 declaration, this is that tree node. 15650 15651 'REG_OFFSET (X)' 15652 If this register is known to hold the value of some user-level 15653 declaration, this is the offset into that logical storage. 15654 15655'SYMBOL_REF' 15656 'SYMBOL_REF_DECL (X)' 15657 If the 'symbol_ref' X was created for a 'VAR_DECL' or a 15658 'FUNCTION_DECL', that tree is recorded here. If this value is 15659 null, then X was created by back end code generation routines, 15660 and there is no associated front end symbol table entry. 15661 15662 'SYMBOL_REF_DECL' may also point to a tree of class ''c'', 15663 that is, some sort of constant. In this case, the 15664 'symbol_ref' is an entry in the per-file constant pool; again, 15665 there is no associated front end symbol table entry. 15666 15667 'SYMBOL_REF_CONSTANT (X)' 15668 If 'CONSTANT_POOL_ADDRESS_P (X)' is true, this is the constant 15669 pool entry for X. It is null otherwise. 15670 15671 'SYMBOL_REF_DATA (X)' 15672 A field of opaque type used to store 'SYMBOL_REF_DECL' or 15673 'SYMBOL_REF_CONSTANT'. 15674 15675 'SYMBOL_REF_FLAGS (X)' 15676 In a 'symbol_ref', this is used to communicate various 15677 predicates about the symbol. Some of these are common enough 15678 to be computed by common code, some are specific to the 15679 target. The common bits are: 15680 15681 'SYMBOL_FLAG_FUNCTION' 15682 Set if the symbol refers to a function. 15683 15684 'SYMBOL_FLAG_LOCAL' 15685 Set if the symbol is local to this "module". See 15686 'TARGET_BINDS_LOCAL_P'. 15687 15688 'SYMBOL_FLAG_EXTERNAL' 15689 Set if this symbol is not defined in this translation 15690 unit. Note that this is not the inverse of 15691 'SYMBOL_FLAG_LOCAL'. 15692 15693 'SYMBOL_FLAG_SMALL' 15694 Set if the symbol is located in the small data section. 15695 See 'TARGET_IN_SMALL_DATA_P'. 15696 15697 'SYMBOL_REF_TLS_MODEL (X)' 15698 This is a multi-bit field accessor that returns the 15699 'tls_model' to be used for a thread-local storage symbol. 15700 It returns zero for non-thread-local symbols. 15701 15702 'SYMBOL_FLAG_HAS_BLOCK_INFO' 15703 Set if the symbol has 'SYMBOL_REF_BLOCK' and 15704 'SYMBOL_REF_BLOCK_OFFSET' fields. 15705 15706 'SYMBOL_FLAG_ANCHOR' 15707 Set if the symbol is used as a section anchor. "Section 15708 anchors" are symbols that have a known position within an 15709 'object_block' and that can be used to access nearby 15710 members of that block. They are used to implement 15711 '-fsection-anchors'. 15712 15713 If this flag is set, then 'SYMBOL_FLAG_HAS_BLOCK_INFO' 15714 will be too. 15715 15716 Bits beginning with 'SYMBOL_FLAG_MACH_DEP' are available for 15717 the target's use. 15718 15719'SYMBOL_REF_BLOCK (X)' 15720 If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the 'object_block' 15721 structure to which the symbol belongs, or 'NULL' if it has not been 15722 assigned a block. 15723 15724'SYMBOL_REF_BLOCK_OFFSET (X)' 15725 If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the offset of X from 15726 the first object in 'SYMBOL_REF_BLOCK (X)'. The value is negative 15727 if X has not yet been assigned to a block, or it has not been given 15728 an offset within that block. 15729 15730 15731File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL 15732 1573314.5 Flags in an RTL Expression 15734=============================== 15735 15736RTL expressions contain several flags (one-bit bit-fields) that are used 15737in certain types of expression. Most often they are accessed with the 15738following macros, which expand into lvalues. 15739 15740'CROSSING_JUMP_P (X)' 15741 Nonzero in a 'jump_insn' if it crosses between hot and cold 15742 sections, which could potentially be very far apart in the 15743 executable. The presence of this flag indicates to other 15744 optimizations that this branching instruction should not be 15745 "collapsed" into a simpler branching construct. It is used when 15746 the optimization to partition basic blocks into hot and cold 15747 sections is turned on. 15748 15749'CONSTANT_POOL_ADDRESS_P (X)' 15750 Nonzero in a 'symbol_ref' if it refers to part of the current 15751 function's constant pool. For most targets these addresses are in 15752 a '.rodata' section entirely separate from the function, but for 15753 some targets the addresses are close to the beginning of the 15754 function. In either case GCC assumes these addresses can be 15755 addressed directly, perhaps with the help of base registers. 15756 Stored in the 'unchanging' field and printed as '/u'. 15757 15758'INSN_ANNULLED_BRANCH_P (X)' 15759 In a 'jump_insn', 'call_insn', or 'insn' indicates that the branch 15760 is an annulling one. See the discussion under 'sequence' below. 15761 Stored in the 'unchanging' field and printed as '/u'. 15762 15763'INSN_DELETED_P (X)' 15764 In an 'insn', 'call_insn', 'jump_insn', 'code_label', 15765 'jump_table_data', 'barrier', or 'note', nonzero if the insn has 15766 been deleted. Stored in the 'volatil' field and printed as '/v'. 15767 15768'INSN_FROM_TARGET_P (X)' 15769 In an 'insn' or 'jump_insn' or 'call_insn' in a delay slot of a 15770 branch, indicates that the insn is from the target of the branch. 15771 If the branch insn has 'INSN_ANNULLED_BRANCH_P' set, this insn will 15772 only be executed if the branch is taken. For annulled branches 15773 with 'INSN_FROM_TARGET_P' clear, the insn will be executed only if 15774 the branch is not taken. When 'INSN_ANNULLED_BRANCH_P' is not set, 15775 this insn will always be executed. Stored in the 'in_struct' field 15776 and printed as '/s'. 15777 15778'LABEL_PRESERVE_P (X)' 15779 In a 'code_label' or 'note', indicates that the label is referenced 15780 by code or data not visible to the RTL of a given function. Labels 15781 referenced by a non-local goto will have this bit set. Stored in 15782 the 'in_struct' field and printed as '/s'. 15783 15784'LABEL_REF_NONLOCAL_P (X)' 15785 In 'label_ref' and 'reg_label' expressions, nonzero if this is a 15786 reference to a non-local label. Stored in the 'volatil' field and 15787 printed as '/v'. 15788 15789'MEM_KEEP_ALIAS_SET_P (X)' 15790 In 'mem' expressions, 1 if we should keep the alias set for this 15791 mem unchanged when we access a component. Set to 1, for example, 15792 when we are already in a non-addressable component of an aggregate. 15793 Stored in the 'jump' field and printed as '/j'. 15794 15795'MEM_VOLATILE_P (X)' 15796 In 'mem', 'asm_operands', and 'asm_input' expressions, nonzero for 15797 volatile memory references. Stored in the 'volatil' field and 15798 printed as '/v'. 15799 15800'MEM_NOTRAP_P (X)' 15801 In 'mem', nonzero for memory references that will not trap. Stored 15802 in the 'call' field and printed as '/c'. 15803 15804'MEM_POINTER (X)' 15805 Nonzero in a 'mem' if the memory reference holds a pointer. Stored 15806 in the 'frame_related' field and printed as '/f'. 15807 15808'MEM_READONLY_P (X)' 15809 Nonzero in a 'mem', if the memory is statically allocated and 15810 read-only. 15811 15812 Read-only in this context means never modified during the lifetime 15813 of the program, not necessarily in ROM or in write-disabled pages. 15814 A common example of the later is a shared library's global offset 15815 table. This table is initialized by the runtime loader, so the 15816 memory is technically writable, but after control is transferred 15817 from the runtime loader to the application, this memory will never 15818 be subsequently modified. 15819 15820 Stored in the 'unchanging' field and printed as '/u'. 15821 15822'PREFETCH_SCHEDULE_BARRIER_P (X)' 15823 In a 'prefetch', indicates that the prefetch is a scheduling 15824 barrier. No other INSNs will be moved over it. Stored in the 15825 'volatil' field and printed as '/v'. 15826 15827'REG_FUNCTION_VALUE_P (X)' 15828 Nonzero in a 'reg' if it is the place in which this function's 15829 value is going to be returned. (This happens only in a hard 15830 register.) Stored in the 'return_val' field and printed as '/i'. 15831 15832'REG_POINTER (X)' 15833 Nonzero in a 'reg' if the register holds a pointer. Stored in the 15834 'frame_related' field and printed as '/f'. 15835 15836'REG_USERVAR_P (X)' 15837 In a 'reg', nonzero if it corresponds to a variable present in the 15838 user's source code. Zero for temporaries generated internally by 15839 the compiler. Stored in the 'volatil' field and printed as '/v'. 15840 15841 The same hard register may be used also for collecting the values 15842 of functions called by this one, but 'REG_FUNCTION_VALUE_P' is zero 15843 in this kind of use. 15844 15845'RTL_CONST_CALL_P (X)' 15846 In a 'call_insn' indicates that the insn represents a call to a 15847 const function. Stored in the 'unchanging' field and printed as 15848 '/u'. 15849 15850'RTL_PURE_CALL_P (X)' 15851 In a 'call_insn' indicates that the insn represents a call to a 15852 pure function. Stored in the 'return_val' field and printed as 15853 '/i'. 15854 15855'RTL_CONST_OR_PURE_CALL_P (X)' 15856 In a 'call_insn', true if 'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P' 15857 is true. 15858 15859'RTL_LOOPING_CONST_OR_PURE_CALL_P (X)' 15860 In a 'call_insn' indicates that the insn represents a possibly 15861 infinite looping call to a const or pure function. Stored in the 15862 'call' field and printed as '/c'. Only true if one of 15863 'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P' is true. 15864 15865'RTX_FRAME_RELATED_P (X)' 15866 Nonzero in an 'insn', 'call_insn', 'jump_insn', 'barrier', or 'set' 15867 which is part of a function prologue and sets the stack pointer, 15868 sets the frame pointer, or saves a register. This flag should also 15869 be set on an instruction that sets up a temporary register to use 15870 in place of the frame pointer. Stored in the 'frame_related' field 15871 and printed as '/f'. 15872 15873 In particular, on RISC targets where there are limits on the sizes 15874 of immediate constants, it is sometimes impossible to reach the 15875 register save area directly from the stack pointer. In that case, 15876 a temporary register is used that is near enough to the register 15877 save area, and the Canonical Frame Address, i.e., DWARF2's logical 15878 frame pointer, register must (temporarily) be changed to be this 15879 temporary register. So, the instruction that sets this temporary 15880 register must be marked as 'RTX_FRAME_RELATED_P'. 15881 15882 If the marked instruction is overly complex (defined in terms of 15883 what 'dwarf2out_frame_debug_expr' can handle), you will also have 15884 to create a 'REG_FRAME_RELATED_EXPR' note and attach it to the 15885 instruction. This note should contain a simple expression of the 15886 computation performed by this instruction, i.e., one that 15887 'dwarf2out_frame_debug_expr' can handle. 15888 15889 This flag is required for exception handling support on targets 15890 with RTL prologues. 15891 15892'SCHED_GROUP_P (X)' 15893 During instruction scheduling, in an 'insn', 'call_insn', 15894 'jump_insn' or 'jump_table_data', indicates that the previous insn 15895 must be scheduled together with this insn. This is used to ensure 15896 that certain groups of instructions will not be split up by the 15897 instruction scheduling pass, for example, 'use' insns before a 15898 'call_insn' may not be separated from the 'call_insn'. Stored in 15899 the 'in_struct' field and printed as '/s'. 15900 15901'SET_IS_RETURN_P (X)' 15902 For a 'set', nonzero if it is for a return. Stored in the 'jump' 15903 field and printed as '/j'. 15904 15905'SIBLING_CALL_P (X)' 15906 For a 'call_insn', nonzero if the insn is a sibling call. Stored 15907 in the 'jump' field and printed as '/j'. 15908 15909'STRING_POOL_ADDRESS_P (X)' 15910 For a 'symbol_ref' expression, nonzero if it addresses this 15911 function's string constant pool. Stored in the 'frame_related' 15912 field and printed as '/f'. 15913 15914'SUBREG_PROMOTED_UNSIGNED_P (X)' 15915 Returns a value greater then zero for a 'subreg' that has 15916 'SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is 15917 kept zero-extended, zero if it is kept sign-extended, and less then 15918 zero if it is extended some other way via the 'ptr_extend' 15919 instruction. Stored in the 'unchanging' field and 'volatil' field, 15920 printed as '/u' and '/v'. This macro may only be used to get the 15921 value it may not be used to change the value. Use 15922 'SUBREG_PROMOTED_UNSIGNED_SET' to change the value. 15923 15924'SUBREG_PROMOTED_UNSIGNED_SET (X)' 15925 Set the 'unchanging' and 'volatil' fields in a 'subreg' to reflect 15926 zero, sign, or other extension. If 'volatil' is zero, then 15927 'unchanging' as nonzero means zero extension and as zero means sign 15928 extension. If 'volatil' is nonzero then some other type of 15929 extension was done via the 'ptr_extend' instruction. 15930 15931'SUBREG_PROMOTED_VAR_P (X)' 15932 Nonzero in a 'subreg' if it was made when accessing an object that 15933 was promoted to a wider mode in accord with the 'PROMOTED_MODE' 15934 machine description macro (*note Storage Layout::). In this case, 15935 the mode of the 'subreg' is the declared mode of the object and the 15936 mode of 'SUBREG_REG' is the mode of the register that holds the 15937 object. Promoted variables are always either sign- or 15938 zero-extended to the wider mode on every assignment. Stored in the 15939 'in_struct' field and printed as '/s'. 15940 15941'SYMBOL_REF_USED (X)' 15942 In a 'symbol_ref', indicates that X has been used. This is 15943 normally only used to ensure that X is only declared external once. 15944 Stored in the 'used' field. 15945 15946'SYMBOL_REF_WEAK (X)' 15947 In a 'symbol_ref', indicates that X has been declared weak. Stored 15948 in the 'return_val' field and printed as '/i'. 15949 15950'SYMBOL_REF_FLAG (X)' 15951 In a 'symbol_ref', this is used as a flag for machine-specific 15952 purposes. Stored in the 'volatil' field and printed as '/v'. 15953 15954 Most uses of 'SYMBOL_REF_FLAG' are historic and may be subsumed by 15955 'SYMBOL_REF_FLAGS'. Certainly use of 'SYMBOL_REF_FLAGS' is 15956 mandatory if the target requires more than one bit of storage. 15957 15958 These are the fields to which the above macros refer: 15959 15960'call' 15961 In a 'mem', 1 means that the memory reference will not trap. 15962 15963 In a 'call', 1 means that this pure or const call may possibly 15964 infinite loop. 15965 15966 In an RTL dump, this flag is represented as '/c'. 15967 15968'frame_related' 15969 In an 'insn' or 'set' expression, 1 means that it is part of a 15970 function prologue and sets the stack pointer, sets the frame 15971 pointer, saves a register, or sets up a temporary register to use 15972 in place of the frame pointer. 15973 15974 In 'reg' expressions, 1 means that the register holds a pointer. 15975 15976 In 'mem' expressions, 1 means that the memory reference holds a 15977 pointer. 15978 15979 In 'symbol_ref' expressions, 1 means that the reference addresses 15980 this function's string constant pool. 15981 15982 In an RTL dump, this flag is represented as '/f'. 15983 15984'in_struct' 15985 In 'reg' expressions, it is 1 if the register has its entire life 15986 contained within the test expression of some loop. 15987 15988 In 'subreg' expressions, 1 means that the 'subreg' is accessing an 15989 object that has had its mode promoted from a wider mode. 15990 15991 In 'label_ref' expressions, 1 means that the referenced label is 15992 outside the innermost loop containing the insn in which the 15993 'label_ref' was found. 15994 15995 In 'code_label' expressions, it is 1 if the label may never be 15996 deleted. This is used for labels which are the target of non-local 15997 gotos. Such a label that would have been deleted is replaced with 15998 a 'note' of type 'NOTE_INSN_DELETED_LABEL'. 15999 16000 In an 'insn' during dead-code elimination, 1 means that the insn is 16001 dead code. 16002 16003 In an 'insn' or 'jump_insn' during reorg for an insn in the delay 16004 slot of a branch, 1 means that this insn is from the target of the 16005 branch. 16006 16007 In an 'insn' during instruction scheduling, 1 means that this insn 16008 must be scheduled as part of a group together with the previous 16009 insn. 16010 16011 In an RTL dump, this flag is represented as '/s'. 16012 16013'return_val' 16014 In 'reg' expressions, 1 means the register contains the value to be 16015 returned by the current function. On machines that pass parameters 16016 in registers, the same register number may be used for parameters 16017 as well, but this flag is not set on such uses. 16018 16019 In 'symbol_ref' expressions, 1 means the referenced symbol is weak. 16020 16021 In 'call' expressions, 1 means the call is pure. 16022 16023 In an RTL dump, this flag is represented as '/i'. 16024 16025'jump' 16026 In a 'mem' expression, 1 means we should keep the alias set for 16027 this mem unchanged when we access a component. 16028 16029 In a 'set', 1 means it is for a return. 16030 16031 In a 'call_insn', 1 means it is a sibling call. 16032 16033 In a 'jump_insn', 1 means it is a crossing jump. 16034 16035 In an RTL dump, this flag is represented as '/j'. 16036 16037'unchanging' 16038 In 'reg' and 'mem' expressions, 1 means that the value of the 16039 expression never changes. 16040 16041 In 'subreg' expressions, it is 1 if the 'subreg' references an 16042 unsigned object whose mode has been promoted to a wider mode. 16043 16044 In an 'insn' or 'jump_insn' in the delay slot of a branch 16045 instruction, 1 means an annulling branch should be used. 16046 16047 In a 'symbol_ref' expression, 1 means that this symbol addresses 16048 something in the per-function constant pool. 16049 16050 In a 'call_insn' 1 means that this instruction is a call to a const 16051 function. 16052 16053 In an RTL dump, this flag is represented as '/u'. 16054 16055'used' 16056 This flag is used directly (without an access macro) at the end of 16057 RTL generation for a function, to count the number of times an 16058 expression appears in insns. Expressions that appear more than 16059 once are copied, according to the rules for shared structure (*note 16060 Sharing::). 16061 16062 For a 'reg', it is used directly (without an access macro) by the 16063 leaf register renumbering code to ensure that each register is only 16064 renumbered once. 16065 16066 In a 'symbol_ref', it indicates that an external declaration for 16067 the symbol has already been written. 16068 16069'volatil' 16070 In a 'mem', 'asm_operands', or 'asm_input' expression, it is 1 if 16071 the memory reference is volatile. Volatile memory references may 16072 not be deleted, reordered or combined. 16073 16074 In a 'symbol_ref' expression, it is used for machine-specific 16075 purposes. 16076 16077 In a 'reg' expression, it is 1 if the value is a user-level 16078 variable. 0 indicates an internal compiler temporary. 16079 16080 In an 'insn', 1 means the insn has been deleted. 16081 16082 In 'label_ref' and 'reg_label' expressions, 1 means a reference to 16083 a non-local label. 16084 16085 In 'prefetch' expressions, 1 means that the containing insn is a 16086 scheduling barrier. 16087 16088 In an RTL dump, this flag is represented as '/v'. 16089 16090 16091File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 16092 1609314.6 Machine Modes 16094================== 16095 16096A machine mode describes a size of data object and the representation 16097used for it. In the C code, machine modes are represented by an 16098enumeration type, 'machine_mode', defined in 'machmode.def'. Each RTL 16099expression has room for a machine mode and so do certain kinds of tree 16100expressions (declarations and types, to be precise). 16101 16102 In debugging dumps and machine descriptions, the machine mode of an RTL 16103expression is written after the expression code with a colon to separate 16104them. The letters 'mode' which appear at the end of each machine mode 16105name are omitted. For example, '(reg:SI 38)' is a 'reg' expression with 16106machine mode 'SImode'. If the mode is 'VOIDmode', it is not written at 16107all. 16108 16109 Here is a table of machine modes. The term "byte" below refers to an 16110object of 'BITS_PER_UNIT' bits (*note Storage Layout::). 16111 16112'BImode' 16113 "Bit" mode represents a single bit, for predicate registers. 16114 16115'QImode' 16116 "Quarter-Integer" mode represents a single byte treated as an 16117 integer. 16118 16119'HImode' 16120 "Half-Integer" mode represents a two-byte integer. 16121 16122'PSImode' 16123 "Partial Single Integer" mode represents an integer which occupies 16124 four bytes but which doesn't really use all four. On some 16125 machines, this is the right mode to use for pointers. 16126 16127'SImode' 16128 "Single Integer" mode represents a four-byte integer. 16129 16130'PDImode' 16131 "Partial Double Integer" mode represents an integer which occupies 16132 eight bytes but which doesn't really use all eight. On some 16133 machines, this is the right mode to use for certain pointers. 16134 16135'DImode' 16136 "Double Integer" mode represents an eight-byte integer. 16137 16138'TImode' 16139 "Tetra Integer" (?) mode represents a sixteen-byte integer. 16140 16141'OImode' 16142 "Octa Integer" (?) mode represents a thirty-two-byte integer. 16143 16144'XImode' 16145 "Hexadeca Integer" (?) mode represents a sixty-four-byte integer. 16146 16147'QFmode' 16148 "Quarter-Floating" mode represents a quarter-precision (single 16149 byte) floating point number. 16150 16151'HFmode' 16152 "Half-Floating" mode represents a half-precision (two byte) 16153 floating point number. 16154 16155'TQFmode' 16156 "Three-Quarter-Floating" (?) mode represents a 16157 three-quarter-precision (three byte) floating point number. 16158 16159'SFmode' 16160 "Single Floating" mode represents a four byte floating point 16161 number. In the common case, of a processor with IEEE arithmetic 16162 and 8-bit bytes, this is a single-precision IEEE floating point 16163 number; it can also be used for double-precision (on processors 16164 with 16-bit bytes) and single-precision VAX and IBM types. 16165 16166'DFmode' 16167 "Double Floating" mode represents an eight byte floating point 16168 number. In the common case, of a processor with IEEE arithmetic 16169 and 8-bit bytes, this is a double-precision IEEE floating point 16170 number. 16171 16172'XFmode' 16173 "Extended Floating" mode represents an IEEE extended floating point 16174 number. This mode only has 80 meaningful bits (ten bytes). Some 16175 processors require such numbers to be padded to twelve bytes, 16176 others to sixteen; this mode is used for either. 16177 16178'SDmode' 16179 "Single Decimal Floating" mode represents a four byte decimal 16180 floating point number (as distinct from conventional binary 16181 floating point). 16182 16183'DDmode' 16184 "Double Decimal Floating" mode represents an eight byte decimal 16185 floating point number. 16186 16187'TDmode' 16188 "Tetra Decimal Floating" mode represents a sixteen byte decimal 16189 floating point number all 128 of whose bits are meaningful. 16190 16191'TFmode' 16192 "Tetra Floating" mode represents a sixteen byte floating point 16193 number all 128 of whose bits are meaningful. One common use is the 16194 IEEE quad-precision format. 16195 16196'QQmode' 16197 "Quarter-Fractional" mode represents a single byte treated as a 16198 signed fractional number. The default format is "s.7". 16199 16200'HQmode' 16201 "Half-Fractional" mode represents a two-byte signed fractional 16202 number. The default format is "s.15". 16203 16204'SQmode' 16205 "Single Fractional" mode represents a four-byte signed fractional 16206 number. The default format is "s.31". 16207 16208'DQmode' 16209 "Double Fractional" mode represents an eight-byte signed fractional 16210 number. The default format is "s.63". 16211 16212'TQmode' 16213 "Tetra Fractional" mode represents a sixteen-byte signed fractional 16214 number. The default format is "s.127". 16215 16216'UQQmode' 16217 "Unsigned Quarter-Fractional" mode represents a single byte treated 16218 as an unsigned fractional number. The default format is ".8". 16219 16220'UHQmode' 16221 "Unsigned Half-Fractional" mode represents a two-byte unsigned 16222 fractional number. The default format is ".16". 16223 16224'USQmode' 16225 "Unsigned Single Fractional" mode represents a four-byte unsigned 16226 fractional number. The default format is ".32". 16227 16228'UDQmode' 16229 "Unsigned Double Fractional" mode represents an eight-byte unsigned 16230 fractional number. The default format is ".64". 16231 16232'UTQmode' 16233 "Unsigned Tetra Fractional" mode represents a sixteen-byte unsigned 16234 fractional number. The default format is ".128". 16235 16236'HAmode' 16237 "Half-Accumulator" mode represents a two-byte signed accumulator. 16238 The default format is "s8.7". 16239 16240'SAmode' 16241 "Single Accumulator" mode represents a four-byte signed 16242 accumulator. The default format is "s16.15". 16243 16244'DAmode' 16245 "Double Accumulator" mode represents an eight-byte signed 16246 accumulator. The default format is "s32.31". 16247 16248'TAmode' 16249 "Tetra Accumulator" mode represents a sixteen-byte signed 16250 accumulator. The default format is "s64.63". 16251 16252'UHAmode' 16253 "Unsigned Half-Accumulator" mode represents a two-byte unsigned 16254 accumulator. The default format is "8.8". 16255 16256'USAmode' 16257 "Unsigned Single Accumulator" mode represents a four-byte unsigned 16258 accumulator. The default format is "16.16". 16259 16260'UDAmode' 16261 "Unsigned Double Accumulator" mode represents an eight-byte 16262 unsigned accumulator. The default format is "32.32". 16263 16264'UTAmode' 16265 "Unsigned Tetra Accumulator" mode represents a sixteen-byte 16266 unsigned accumulator. The default format is "64.64". 16267 16268'CCmode' 16269 "Condition Code" mode represents the value of a condition code, 16270 which is a machine-specific set of bits used to represent the 16271 result of a comparison operation. Other machine-specific modes may 16272 also be used for the condition code. These modes are not used on 16273 machines that use 'cc0' (*note Condition Code::). 16274 16275'BLKmode' 16276 "Block" mode represents values that are aggregates to which none of 16277 the other modes apply. In RTL, only memory references can have 16278 this mode, and only if they appear in string-move or vector 16279 instructions. On machines which have no such instructions, 16280 'BLKmode' will not appear in RTL. 16281 16282'VOIDmode' 16283 Void mode means the absence of a mode or an unspecified mode. For 16284 example, RTL expressions of code 'const_int' have mode 'VOIDmode' 16285 because they can be taken to have whatever mode the context 16286 requires. In debugging dumps of RTL, 'VOIDmode' is expressed by 16287 the absence of any mode. 16288 16289'QCmode, HCmode, SCmode, DCmode, XCmode, TCmode' 16290 These modes stand for a complex number represented as a pair of 16291 floating point values. The floating point values are in 'QFmode', 16292 'HFmode', 'SFmode', 'DFmode', 'XFmode', and 'TFmode', respectively. 16293 16294'CQImode, CHImode, CSImode, CDImode, CTImode, COImode, CPSImode' 16295 These modes stand for a complex number represented as a pair of 16296 integer values. The integer values are in 'QImode', 'HImode', 16297 'SImode', 'DImode', 'TImode', 'OImode', and 'PSImode', 16298 respectively. 16299 16300'BND32mode BND64mode' 16301 These modes stand for bounds for pointer of 32 and 64 bit size 16302 respectively. Mode size is double pointer mode size. 16303 16304 The machine description defines 'Pmode' as a C macro which expands into 16305the machine mode used for addresses. Normally this is the mode whose 16306size is 'BITS_PER_WORD', 'SImode' on 32-bit machines. 16307 16308 The only modes which a machine description must support are 'QImode', 16309and the modes corresponding to 'BITS_PER_WORD', 'FLOAT_TYPE_SIZE' and 16310'DOUBLE_TYPE_SIZE'. The compiler will attempt to use 'DImode' for 163118-byte structures and unions, but this can be prevented by overriding 16312the definition of 'MAX_FIXED_MODE_SIZE'. Alternatively, you can have 16313the compiler use 'TImode' for 16-byte structures and unions. Likewise, 16314you can arrange for the C type 'short int' to avoid using 'HImode'. 16315 16316 Very few explicit references to machine modes remain in the compiler 16317and these few references will soon be removed. Instead, the machine 16318modes are divided into mode classes. These are represented by the 16319enumeration type 'enum mode_class' defined in 'machmode.h'. The 16320possible mode classes are: 16321 16322'MODE_INT' 16323 Integer modes. By default these are 'BImode', 'QImode', 'HImode', 16324 'SImode', 'DImode', 'TImode', and 'OImode'. 16325 16326'MODE_PARTIAL_INT' 16327 The "partial integer" modes, 'PQImode', 'PHImode', 'PSImode' and 16328 'PDImode'. 16329 16330'MODE_FLOAT' 16331 Floating point modes. By default these are 'QFmode', 'HFmode', 16332 'TQFmode', 'SFmode', 'DFmode', 'XFmode' and 'TFmode'. 16333 16334'MODE_DECIMAL_FLOAT' 16335 Decimal floating point modes. By default these are 'SDmode', 16336 'DDmode' and 'TDmode'. 16337 16338'MODE_FRACT' 16339 Signed fractional modes. By default these are 'QQmode', 'HQmode', 16340 'SQmode', 'DQmode' and 'TQmode'. 16341 16342'MODE_UFRACT' 16343 Unsigned fractional modes. By default these are 'UQQmode', 16344 'UHQmode', 'USQmode', 'UDQmode' and 'UTQmode'. 16345 16346'MODE_ACCUM' 16347 Signed accumulator modes. By default these are 'HAmode', 'SAmode', 16348 'DAmode' and 'TAmode'. 16349 16350'MODE_UACCUM' 16351 Unsigned accumulator modes. By default these are 'UHAmode', 16352 'USAmode', 'UDAmode' and 'UTAmode'. 16353 16354'MODE_COMPLEX_INT' 16355 Complex integer modes. (These are not currently implemented). 16356 16357'MODE_COMPLEX_FLOAT' 16358 Complex floating point modes. By default these are 'QCmode', 16359 'HCmode', 'SCmode', 'DCmode', 'XCmode', and 'TCmode'. 16360 16361'MODE_FUNCTION' 16362 Algol or Pascal function variables including a static chain. 16363 (These are not currently implemented). 16364 16365'MODE_CC' 16366 Modes representing condition code values. These are 'CCmode' plus 16367 any 'CC_MODE' modes listed in the 'MACHINE-modes.def'. *Note Jump 16368 Patterns::, also see *note Condition Code::. 16369 16370'MODE_POINTER_BOUNDS' 16371 Pointer bounds modes. Used to represent values of pointer bounds 16372 type. Operations in these modes may be executed as NOPs depending 16373 on hardware features and environment setup. 16374 16375'MODE_RANDOM' 16376 This is a catchall mode class for modes which don't fit into the 16377 above classes. Currently 'VOIDmode' and 'BLKmode' are in 16378 'MODE_RANDOM'. 16379 16380 'machmode.h' also defines various wrapper classes that combine a 16381'machine_mode' with a static assertion that a particular condition 16382holds. The classes are: 16383 16384'scalar_int_mode' 16385 A mode that has class 'MODE_INT' or 'MODE_PARTIAL_INT'. 16386 16387'scalar_float_mode' 16388 A mode that has class 'MODE_FLOAT' or 'MODE_DECIMAL_FLOAT'. 16389 16390'scalar_mode' 16391 A mode that holds a single numerical value. In practice this means 16392 that the mode is a 'scalar_int_mode', is a 'scalar_float_mode', or 16393 has class 'MODE_FRACT', 'MODE_UFRACT', 'MODE_ACCUM', 'MODE_UACCUM' 16394 or 'MODE_POINTER_BOUNDS'. 16395 16396'complex_mode' 16397 A mode that has class 'MODE_COMPLEX_INT' or 'MODE_COMPLEX_FLOAT'. 16398 16399'fixed_size_mode' 16400 A mode whose size is known at compile time. 16401 16402 Named modes use the most constrained of the available wrapper classes, 16403if one exists, otherwise they use 'machine_mode'. For example, 'QImode' 16404is a 'scalar_int_mode', 'SFmode' is a 'scalar_float_mode' and 'BLKmode' 16405is a plain 'machine_mode'. It is possible to refer to any mode as a raw 16406'machine_mode' by adding the 'E_' prefix, where 'E' stands for 16407"enumeration". For example, the raw 'machine_mode' names of the modes 16408just mentioned are 'E_QImode', 'E_SFmode' and 'E_BLKmode' respectively. 16409 16410 The wrapper classes implicitly convert to 'machine_mode' and to any 16411wrapper class that represents a more general condition; for example 16412'scalar_int_mode' and 'scalar_float_mode' both convert to 'scalar_mode' 16413and all three convert to 'fixed_size_mode'. The classes act like 16414'machine_mode's that accept only certain named modes. 16415 16416 'machmode.h' also defines a template class 'opt_mode<T>' that holds a 16417'T' or nothing, where 'T' can be either 'machine_mode' or one of the 16418wrapper classes above. The main operations on an 'opt_mode<T>' X are as 16419follows: 16420 16421'X.exists ()' 16422 Return true if X holds a mode rather than nothing. 16423 16424'X.exists (&Y)' 16425 Return true if X holds a mode rather than nothing, storing the mode 16426 in Y if so. Y must be assignment-compatible with T. 16427 16428'X.require ()' 16429 Assert that X holds a mode rather than nothing and return that 16430 mode. 16431 16432'X = Y' 16433 Set X to Y, where Y is a T or implicitly converts to a T. 16434 16435 The default constructor sets an 'opt_mode<T>' to nothing. There is 16436also a constructor that takes an initial value of type T. 16437 16438 It is possible to use the 'is-a.h' accessors on a 'machine_mode' or 16439machine mode wrapper X: 16440 16441'is_a <T> (X)' 16442 Return true if X meets the conditions for wrapper class T. 16443 16444'is_a <T> (X, &Y)' 16445 Return true if X meets the conditions for wrapper class T, storing 16446 it in Y if so. Y must be assignment-compatible with T. 16447 16448'as_a <T> (X)' 16449 Assert that X meets the conditions for wrapper class T and return 16450 it as a T. 16451 16452'dyn_cast <T> (X)' 16453 Return an 'opt_mode<T>' that holds X if X meets the conditions for 16454 wrapper class T and that holds nothing otherwise. 16455 16456 The purpose of these wrapper classes is to give stronger static type 16457checking. For example, if a function takes a 'scalar_int_mode', a 16458caller that has a general 'machine_mode' must either check or assert 16459that the code is indeed a scalar integer first, using one of the 16460functions above. 16461 16462 The wrapper classes are normal C++ classes, with user-defined 16463constructors. Sometimes it is useful to have a POD version of the same 16464type, particularly if the type appears in a 'union'. The template class 16465'pod_mode<T>' provides a POD version of wrapper class T. It is 16466assignment-compatible with T and implicitly converts to both 16467'machine_mode' and T. 16468 16469 Here are some C macros that relate to machine modes: 16470 16471'GET_MODE (X)' 16472 Returns the machine mode of the RTX X. 16473 16474'PUT_MODE (X, NEWMODE)' 16475 Alters the machine mode of the RTX X to be NEWMODE. 16476 16477'NUM_MACHINE_MODES' 16478 Stands for the number of machine modes available on the target 16479 machine. This is one greater than the largest numeric value of any 16480 machine mode. 16481 16482'GET_MODE_NAME (M)' 16483 Returns the name of mode M as a string. 16484 16485'GET_MODE_CLASS (M)' 16486 Returns the mode class of mode M. 16487 16488'GET_MODE_WIDER_MODE (M)' 16489 Returns the next wider natural mode. For example, the expression 16490 'GET_MODE_WIDER_MODE (QImode)' returns 'HImode'. 16491 16492'GET_MODE_SIZE (M)' 16493 Returns the size in bytes of a datum of mode M. 16494 16495'GET_MODE_BITSIZE (M)' 16496 Returns the size in bits of a datum of mode M. 16497 16498'GET_MODE_IBIT (M)' 16499 Returns the number of integral bits of a datum of fixed-point mode 16500 M. 16501 16502'GET_MODE_FBIT (M)' 16503 Returns the number of fractional bits of a datum of fixed-point 16504 mode M. 16505 16506'GET_MODE_MASK (M)' 16507 Returns a bitmask containing 1 for all bits in a word that fit 16508 within mode M. This macro can only be used for modes whose bitsize 16509 is less than or equal to 'HOST_BITS_PER_INT'. 16510 16511'GET_MODE_ALIGNMENT (M)' 16512 Return the required alignment, in bits, for an object of mode M. 16513 16514'GET_MODE_UNIT_SIZE (M)' 16515 Returns the size in bytes of the subunits of a datum of mode M. 16516 This is the same as 'GET_MODE_SIZE' except in the case of complex 16517 modes. For them, the unit size is the size of the real or 16518 imaginary part. 16519 16520'GET_MODE_NUNITS (M)' 16521 Returns the number of units contained in a mode, i.e., 16522 'GET_MODE_SIZE' divided by 'GET_MODE_UNIT_SIZE'. 16523 16524'GET_CLASS_NARROWEST_MODE (C)' 16525 Returns the narrowest mode in mode class C. 16526 16527 The following 3 variables are defined on every target. They can be 16528used to allocate buffers that are guaranteed to be large enough to hold 16529any value that can be represented on the target. The first two can be 16530overridden by defining them in the target's mode.def file, however, the 16531value must be a constant that can determined very early in the 16532compilation process. The third symbol cannot be overridden. 16533 16534'BITS_PER_UNIT' 16535 The number of bits in an addressable storage unit (byte). If you 16536 do not define this, the default is 8. 16537 16538'MAX_BITSIZE_MODE_ANY_INT' 16539 The maximum bitsize of any mode that is used in integer math. This 16540 should be overridden by the target if it uses large integers as 16541 containers for larger vectors but otherwise never uses the contents 16542 to compute integer values. 16543 16544'MAX_BITSIZE_MODE_ANY_MODE' 16545 The bitsize of the largest mode on the target. The default value 16546 is the largest mode size given in the mode definition file, which 16547 is always correct for targets whose modes have a fixed size. 16548 Targets that might increase the size of a mode beyond this default 16549 should define 'MAX_BITSIZE_MODE_ANY_MODE' to the actual upper limit 16550 in 'MACHINE-modes.def'. 16551 16552 The global variables 'byte_mode' and 'word_mode' contain modes whose 16553classes are 'MODE_INT' and whose bitsizes are either 'BITS_PER_UNIT' or 16554'BITS_PER_WORD', respectively. On 32-bit machines, these are 'QImode' 16555and 'SImode', respectively. 16556 16557 16558File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL 16559 1656014.7 Constant Expression Types 16561============================== 16562 16563The simplest RTL expressions are those that represent constant values. 16564 16565'(const_int I)' 16566 This type of expression represents the integer value I. I is 16567 customarily accessed with the macro 'INTVAL' as in 'INTVAL (EXP)', 16568 which is equivalent to 'XWINT (EXP, 0)'. 16569 16570 Constants generated for modes with fewer bits than in 16571 'HOST_WIDE_INT' must be sign extended to full width (e.g., with 16572 'gen_int_mode'). For constants for modes with more bits than in 16573 'HOST_WIDE_INT' the implied high order bits of that constant are 16574 copies of the top bit. Note however that values are neither 16575 inherently signed nor inherently unsigned; where necessary, 16576 signedness is determined by the rtl operation instead. 16577 16578 There is only one expression object for the integer value zero; it 16579 is the value of the variable 'const0_rtx'. Likewise, the only 16580 expression for integer value one is found in 'const1_rtx', the only 16581 expression for integer value two is found in 'const2_rtx', and the 16582 only expression for integer value negative one is found in 16583 'constm1_rtx'. Any attempt to create an expression of code 16584 'const_int' and value zero, one, two or negative one will return 16585 'const0_rtx', 'const1_rtx', 'const2_rtx' or 'constm1_rtx' as 16586 appropriate. 16587 16588 Similarly, there is only one object for the integer whose value is 16589 'STORE_FLAG_VALUE'. It is found in 'const_true_rtx'. If 16590 'STORE_FLAG_VALUE' is one, 'const_true_rtx' and 'const1_rtx' will 16591 point to the same object. If 'STORE_FLAG_VALUE' is -1, 16592 'const_true_rtx' and 'constm1_rtx' will point to the same object. 16593 16594'(const_double:M I0 I1 ...)' 16595 This represents either a floating-point constant of mode M or (on 16596 older ports that do not define 'TARGET_SUPPORTS_WIDE_INT') an 16597 integer constant too large to fit into 'HOST_BITS_PER_WIDE_INT' 16598 bits but small enough to fit within twice that number of bits. In 16599 the latter case, M will be 'VOIDmode'. For integral values 16600 constants for modes with more bits than twice the number in 16601 'HOST_WIDE_INT' the implied high order bits of that constant are 16602 copies of the top bit of 'CONST_DOUBLE_HIGH'. Note however that 16603 integral values are neither inherently signed nor inherently 16604 unsigned; where necessary, signedness is determined by the rtl 16605 operation instead. 16606 16607 On more modern ports, 'CONST_DOUBLE' only represents floating point 16608 values. New ports define 'TARGET_SUPPORTS_WIDE_INT' to make this 16609 designation. 16610 16611 If M is 'VOIDmode', the bits of the value are stored in I0 and I1. 16612 I0 is customarily accessed with the macro 'CONST_DOUBLE_LOW' and I1 16613 with 'CONST_DOUBLE_HIGH'. 16614 16615 If the constant is floating point (regardless of its precision), 16616 then the number of integers used to store the value depends on the 16617 size of 'REAL_VALUE_TYPE' (*note Floating Point::). The integers 16618 represent a floating point number, but not precisely in the target 16619 machine's or host machine's floating point format. To convert them 16620 to the precise bit pattern used by the target machine, use the 16621 macro 'REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data 16622 Output::). 16623 16624'(const_wide_int:M NUNITS ELT0 ...)' 16625 This contains an array of 'HOST_WIDE_INT's that is large enough to 16626 hold any constant that can be represented on the target. This form 16627 of rtl is only used on targets that define 16628 'TARGET_SUPPORTS_WIDE_INT' to be nonzero and then 'CONST_DOUBLE's 16629 are only used to hold floating-point values. If the target leaves 16630 'TARGET_SUPPORTS_WIDE_INT' defined as 0, 'CONST_WIDE_INT's are not 16631 used and 'CONST_DOUBLE's are as they were before. 16632 16633 The values are stored in a compressed format. The higher-order 0s 16634 or -1s are not represented if they are just the logical sign 16635 extension of the number that is represented. 16636 16637'CONST_WIDE_INT_VEC (CODE)' 16638 Returns the entire array of 'HOST_WIDE_INT's that are used to store 16639 the value. This macro should be rarely used. 16640 16641'CONST_WIDE_INT_NUNITS (CODE)' 16642 The number of 'HOST_WIDE_INT's used to represent the number. Note 16643 that this generally is smaller than the number of 'HOST_WIDE_INT's 16644 implied by the mode size. 16645 16646'CONST_WIDE_INT_NUNITS (CODE,I)' 16647 Returns the 'i'th element of the array. Element 0 is contains the 16648 low order bits of the constant. 16649 16650'(const_fixed:M ...)' 16651 Represents a fixed-point constant of mode M. The operand is a data 16652 structure of type 'struct fixed_value' and is accessed with the 16653 macro 'CONST_FIXED_VALUE'. The high part of data is accessed with 16654 'CONST_FIXED_VALUE_HIGH'; the low part is accessed with 16655 'CONST_FIXED_VALUE_LOW'. 16656 16657'(const_poly_int:M [C0 C1 ...])' 16658 Represents a 'poly_int'-style polynomial integer with coefficients 16659 C0, C1, .... The coefficients are 'wide_int'-based integers rather 16660 than rtxes. 'CONST_POLY_INT_COEFFS' gives the values of individual 16661 coefficients (which is mostly only useful in low-level routines) 16662 and 'const_poly_int_value' gives the full 'poly_int' value. 16663 16664'(const_vector:M [X0 X1 ...])' 16665 Represents a vector constant. The values in square brackets are 16666 elements of the vector, which are always 'const_int', 16667 'const_wide_int', 'const_double' or 'const_fixed' expressions. 16668 16669 Each vector constant V is treated as a specific instance of an 16670 arbitrary-length sequence that itself contains 16671 'CONST_VECTOR_NPATTERNS (V)' interleaved patterns. Each pattern 16672 has the form: 16673 16674 { BASE0, BASE1, BASE1 + STEP, BASE1 + STEP * 2, ... } 16675 16676 The first three elements in each pattern are enough to determine 16677 the values of the other elements. However, if all STEPs are zero, 16678 only the first two elements are needed. If in addition each BASE1 16679 is equal to the corresponding BASE0, only the first element in each 16680 pattern is needed. The number of determining elements per pattern 16681 is given by 'CONST_VECTOR_NELTS_PER_PATTERN (V)'. 16682 16683 For example, the constant: 16684 16685 { 0, 1, 2, 6, 3, 8, 4, 10, 5, 12, 6, 14, 7, 16, 8, 18 } 16686 16687 is interpreted as an interleaving of the sequences: 16688 16689 { 0, 2, 3, 4, 5, 6, 7, 8 } 16690 { 1, 6, 8, 10, 12, 14, 16, 18 } 16691 16692 where the sequences are represented by the following patterns: 16693 16694 BASE0 == 0, BASE1 == 2, STEP == 1 16695 BASE0 == 1, BASE1 == 6, STEP == 2 16696 16697 In this case: 16698 16699 CONST_VECTOR_NPATTERNS (V) == 2 16700 CONST_VECTOR_NELTS_PER_PATTERN (V) == 3 16701 16702 Thus the first 6 elements ('{ 0, 1, 2, 6, 3, 8 }') are enough to 16703 determine the whole sequence; we refer to them as the "encoded" 16704 elements. They are the only elements present in the square 16705 brackets for variable-length 'const_vector's (i.e. for 16706 'const_vector's whose mode M has a variable number of elements). 16707 However, as a convenience to code that needs to handle both 16708 'const_vector's and 'parallel's, all elements are present in the 16709 square brackets for fixed-length 'const_vector's; the encoding 16710 scheme simply reduces the amount of work involved in processing 16711 constants that follow a regular pattern. 16712 16713 Sometimes this scheme can create two possible encodings of the same 16714 vector. For example { 0, 1 } could be seen as two patterns with 16715 one element each or one pattern with two elements (BASE0 and 16716 BASE1). The canonical encoding is always the one with the fewest 16717 patterns or (if both encodings have the same number of petterns) 16718 the one with the fewest encoded elements. 16719 16720 'const_vector_encoding_nelts (V)' gives the total number of encoded 16721 elements in V, which is 6 in the example above. 16722 'CONST_VECTOR_ENCODED_ELT (V, I)' accesses the value of encoded 16723 element I. 16724 16725 'CONST_VECTOR_DUPLICATE_P (V)' is true if V simply contains 16726 repeated instances of 'CONST_VECTOR_NPATTERNS (V)' values. This is 16727 a shorthand for testing 'CONST_VECTOR_NELTS_PER_PATTERN (V) == 1'. 16728 16729 'CONST_VECTOR_STEPPED_P (V)' is true if at least one pattern in V 16730 has a nonzero step. This is a shorthand for testing 16731 'CONST_VECTOR_NELTS_PER_PATTERN (V) == 3'. 16732 16733 'CONST_VECTOR_NUNITS (V)' gives the total number of elements in V; 16734 it is a shorthand for getting the number of units in 'GET_MODE 16735 (V)'. 16736 16737 The utility function 'const_vector_elt' gives the value of an 16738 arbitrary element as an 'rtx'. 'const_vector_int_elt' gives the 16739 same value as a 'wide_int'. 16740 16741'(const_string STR)' 16742 Represents a constant string with value STR. Currently this is 16743 used only for insn attributes (*note Insn Attributes::) since 16744 constant strings in C are placed in memory. 16745 16746'(symbol_ref:MODE SYMBOL)' 16747 Represents the value of an assembler label for data. SYMBOL is a 16748 string that describes the name of the assembler label. If it 16749 starts with a '*', the label is the rest of SYMBOL not including 16750 the '*'. Otherwise, the label is SYMBOL, usually prefixed with 16751 '_'. 16752 16753 The 'symbol_ref' contains a mode, which is usually 'Pmode'. 16754 Usually that is the only mode for which a symbol is directly valid. 16755 16756'(label_ref:MODE LABEL)' 16757 Represents the value of an assembler label for code. It contains 16758 one operand, an expression, which must be a 'code_label' or a 16759 'note' of type 'NOTE_INSN_DELETED_LABEL' that appears in the 16760 instruction sequence to identify the place where the label should 16761 go. 16762 16763 The reason for using a distinct expression type for code label 16764 references is so that jump optimization can distinguish them. 16765 16766 The 'label_ref' contains a mode, which is usually 'Pmode'. Usually 16767 that is the only mode for which a label is directly valid. 16768 16769'(const:M EXP)' 16770 Represents a constant that is the result of an assembly-time 16771 arithmetic computation. The operand, EXP, contains only 16772 'const_int', 'symbol_ref', 'label_ref' or 'unspec' expressions, 16773 combined with 'plus' and 'minus'. Any such 'unspec's are 16774 target-specific and typically represent some form of relocation 16775 operator. M should be a valid address mode. 16776 16777'(high:M EXP)' 16778 Represents the high-order bits of EXP, usually a 'symbol_ref'. The 16779 number of bits is machine-dependent and is normally the number of 16780 bits specified in an instruction that initializes the high order 16781 bits of a register. It is used with 'lo_sum' to represent the 16782 typical two-instruction sequence used in RISC machines to reference 16783 a global memory location. 16784 16785 M should be 'Pmode'. 16786 16787 The macro 'CONST0_RTX (MODE)' refers to an expression with value 0 in 16788mode MODE. If mode MODE is of mode class 'MODE_INT', it returns 16789'const0_rtx'. If mode MODE is of mode class 'MODE_FLOAT', it returns a 16790'CONST_DOUBLE' expression in mode MODE. Otherwise, it returns a 16791'CONST_VECTOR' expression in mode MODE. Similarly, the macro 16792'CONST1_RTX (MODE)' refers to an expression with value 1 in mode MODE 16793and similarly for 'CONST2_RTX'. The 'CONST1_RTX' and 'CONST2_RTX' 16794macros are undefined for vector modes. 16795 16796 16797File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL 16798 1679914.8 Registers and Memory 16800========================= 16801 16802Here are the RTL expression types for describing access to machine 16803registers and to main memory. 16804 16805'(reg:M N)' 16806 For small values of the integer N (those that are less than 16807 'FIRST_PSEUDO_REGISTER'), this stands for a reference to machine 16808 register number N: a "hard register". For larger values of N, it 16809 stands for a temporary value or "pseudo register". The compiler's 16810 strategy is to generate code assuming an unlimited number of such 16811 pseudo registers, and later convert them into hard registers or 16812 into memory references. 16813 16814 M is the machine mode of the reference. It is necessary because 16815 machines can generally refer to each register in more than one 16816 mode. For example, a register may contain a full word but there 16817 may be instructions to refer to it as a half word or as a single 16818 byte, as well as instructions to refer to it as a floating point 16819 number of various precisions. 16820 16821 Even for a register that the machine can access in only one mode, 16822 the mode must always be specified. 16823 16824 The symbol 'FIRST_PSEUDO_REGISTER' is defined by the machine 16825 description, since the number of hard registers on the machine is 16826 an invariant characteristic of the machine. Note, however, that 16827 not all of the machine registers must be general registers. All 16828 the machine registers that can be used for storage of data are 16829 given hard register numbers, even those that can be used only in 16830 certain instructions or can hold only certain types of data. 16831 16832 A hard register may be accessed in various modes throughout one 16833 function, but each pseudo register is given a natural mode and is 16834 accessed only in that mode. When it is necessary to describe an 16835 access to a pseudo register using a nonnatural mode, a 'subreg' 16836 expression is used. 16837 16838 A 'reg' expression with a machine mode that specifies more than one 16839 word of data may actually stand for several consecutive registers. 16840 If in addition the register number specifies a hardware register, 16841 then it actually represents several consecutive hardware registers 16842 starting with the specified one. 16843 16844 Each pseudo register number used in a function's RTL code is 16845 represented by a unique 'reg' expression. 16846 16847 Some pseudo register numbers, those within the range of 16848 'FIRST_VIRTUAL_REGISTER' to 'LAST_VIRTUAL_REGISTER' only appear 16849 during the RTL generation phase and are eliminated before the 16850 optimization phases. These represent locations in the stack frame 16851 that cannot be determined until RTL generation for the function has 16852 been completed. The following virtual register numbers are 16853 defined: 16854 16855 'VIRTUAL_INCOMING_ARGS_REGNUM' 16856 This points to the first word of the incoming arguments passed 16857 on the stack. Normally these arguments are placed there by 16858 the caller, but the callee may have pushed some arguments that 16859 were previously passed in registers. 16860 16861 When RTL generation is complete, this virtual register is 16862 replaced by the sum of the register given by 16863 'ARG_POINTER_REGNUM' and the value of 'FIRST_PARM_OFFSET'. 16864 16865 'VIRTUAL_STACK_VARS_REGNUM' 16866 If 'FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this 16867 points to immediately above the first variable on the stack. 16868 Otherwise, it points to the first variable on the stack. 16869 16870 'VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the 16871 register given by 'FRAME_POINTER_REGNUM' and the value 16872 'TARGET_STARTING_FRAME_OFFSET'. 16873 16874 'VIRTUAL_STACK_DYNAMIC_REGNUM' 16875 This points to the location of dynamically allocated memory on 16876 the stack immediately after the stack pointer has been 16877 adjusted by the amount of memory desired. 16878 16879 This virtual register is replaced by the sum of the register 16880 given by 'STACK_POINTER_REGNUM' and the value 16881 'STACK_DYNAMIC_OFFSET'. 16882 16883 'VIRTUAL_OUTGOING_ARGS_REGNUM' 16884 This points to the location in the stack at which outgoing 16885 arguments should be written when the stack is pre-pushed 16886 (arguments pushed using push insns should always use 16887 'STACK_POINTER_REGNUM'). 16888 16889 This virtual register is replaced by the sum of the register 16890 given by 'STACK_POINTER_REGNUM' and the value 16891 'STACK_POINTER_OFFSET'. 16892 16893'(subreg:M1 REG:M2 BYTENUM)' 16894 16895 'subreg' expressions are used to refer to a register in a machine 16896 mode other than its natural one, or to refer to one register of a 16897 multi-part 'reg' that actually refers to several registers. 16898 16899 Each pseudo register has a natural mode. If it is necessary to 16900 operate on it in a different mode, the register must be enclosed in 16901 a 'subreg'. 16902 16903 There are currently three supported types for the first operand of 16904 a 'subreg': 16905 * pseudo registers This is the most common case. Most 'subreg's 16906 have pseudo 'reg's as their first operand. 16907 16908 * mem 'subreg's of 'mem' were common in earlier versions of GCC 16909 and are still supported. During the reload pass these are 16910 replaced by plain 'mem's. On machines that do not do 16911 instruction scheduling, use of 'subreg's of 'mem' are still 16912 used, but this is no longer recommended. Such 'subreg's are 16913 considered to be 'register_operand's rather than 16914 'memory_operand's before and during reload. Because of this, 16915 the scheduling passes cannot properly schedule instructions 16916 with 'subreg's of 'mem', so for machines that do scheduling, 16917 'subreg's of 'mem' should never be used. To support this, the 16918 combine and recog passes have explicit code to inhibit the 16919 creation of 'subreg's of 'mem' when 'INSN_SCHEDULING' is 16920 defined. 16921 16922 The use of 'subreg's of 'mem' after the reload pass is an area 16923 that is not well understood and should be avoided. There is 16924 still some code in the compiler to support this, but this code 16925 has possibly rotted. This use of 'subreg's is discouraged and 16926 will most likely not be supported in the future. 16927 16928 * hard registers It is seldom necessary to wrap hard registers 16929 in 'subreg's; such registers would normally reduce to a single 16930 'reg' rtx. This use of 'subreg's is discouraged and may not 16931 be supported in the future. 16932 16933 'subreg's of 'subreg's are not supported. Using 16934 'simplify_gen_subreg' is the recommended way to avoid this problem. 16935 16936 'subreg's come in two distinct flavors, each having its own usage 16937 and rules: 16938 16939 Paradoxical subregs 16940 When M1 is strictly wider than M2, the 'subreg' expression is 16941 called "paradoxical". The canonical test for this class of 16942 'subreg' is: 16943 16944 paradoxical_subreg_p (M1, M2) 16945 16946 Paradoxical 'subreg's can be used as both lvalues and rvalues. 16947 When used as an lvalue, the low-order bits of the source value 16948 are stored in REG and the high-order bits are discarded. When 16949 used as an rvalue, the low-order bits of the 'subreg' are 16950 taken from REG while the high-order bits may or may not be 16951 defined. 16952 16953 The high-order bits of rvalues are defined in the following 16954 circumstances: 16955 16956 * 'subreg's of 'mem' When M2 is smaller than a word, the 16957 macro 'LOAD_EXTEND_OP', can control how the high-order 16958 bits are defined. 16959 16960 * 'subreg' of 'reg's The upper bits are defined when 16961 'SUBREG_PROMOTED_VAR_P' is true. 16962 'SUBREG_PROMOTED_UNSIGNED_P' describes what the upper 16963 bits hold. Such subregs usually represent local 16964 variables, register variables and parameter pseudo 16965 variables that have been promoted to a wider mode. 16966 16967 BYTENUM is always zero for a paradoxical 'subreg', even on 16968 big-endian targets. 16969 16970 For example, the paradoxical 'subreg': 16971 16972 (set (subreg:SI (reg:HI X) 0) Y) 16973 16974 stores the lower 2 bytes of Y in X and discards the upper 2 16975 bytes. A subsequent: 16976 16977 (set Z (subreg:SI (reg:HI X) 0)) 16978 16979 would set the lower two bytes of Z to Y and set the upper two 16980 bytes to an unknown value assuming 'SUBREG_PROMOTED_VAR_P' is 16981 false. 16982 16983 Normal subregs 16984 When M1 is at least as narrow as M2 the 'subreg' expression is 16985 called "normal". 16986 16987 Normal 'subreg's restrict consideration to certain bits of 16988 REG. For this purpose, REG is divided into 16989 individually-addressable blocks in which each block has: 16990 16991 REGMODE_NATURAL_SIZE (M2) 16992 16993 bytes. Usually the value is 'UNITS_PER_WORD'; that is, most 16994 targets usually treat each word of a register as being 16995 independently addressable. 16996 16997 There are two types of normal 'subreg'. If M1 is known to be 16998 no bigger than a block, the 'subreg' refers to the 16999 least-significant part (or "lowpart") of one block of REG. If 17000 M1 is known to be larger than a block, the 'subreg' refers to 17001 two or more complete blocks. 17002 17003 When used as an lvalue, 'subreg' is a block-based accessor. 17004 Storing to a 'subreg' modifies all the blocks of REG that 17005 overlap the 'subreg', but it leaves the other blocks of REG 17006 alone. 17007 17008 When storing to a normal 'subreg' that is smaller than a 17009 block, the other bits of the referenced block are usually left 17010 in an undefined state. This laxity makes it easier to 17011 generate efficient code for such instructions. To represent 17012 an instruction that preserves all the bits outside of those in 17013 the 'subreg', use 'strict_low_part' or 'zero_extract' around 17014 the 'subreg'. 17015 17016 BYTENUM must identify the offset of the first byte of the 17017 'subreg' from the start of REG, assuming that REG is laid out 17018 in memory order. The memory order of bytes is defined by two 17019 target macros, 'WORDS_BIG_ENDIAN' and 'BYTES_BIG_ENDIAN': 17020 17021 * 'WORDS_BIG_ENDIAN', if set to 1, says that byte number 17022 zero is part of the most significant word; otherwise, it 17023 is part of the least significant word. 17024 17025 * 'BYTES_BIG_ENDIAN', if set to 1, says that byte number 17026 zero is the most significant byte within a word; 17027 otherwise, it is the least significant byte within a 17028 word. 17029 17030 On a few targets, 'FLOAT_WORDS_BIG_ENDIAN' disagrees with 17031 'WORDS_BIG_ENDIAN'. However, most parts of the compiler treat 17032 floating point values as if they had the same endianness as 17033 integer values. This works because they handle them solely as 17034 a collection of integer values, with no particular numerical 17035 value. Only real.c and the runtime libraries care about 17036 'FLOAT_WORDS_BIG_ENDIAN'. 17037 17038 Thus, 17039 17040 (subreg:HI (reg:SI X) 2) 17041 17042 on a 'BYTES_BIG_ENDIAN', 'UNITS_PER_WORD == 4' target is the 17043 same as 17044 17045 (subreg:HI (reg:SI X) 0) 17046 17047 on a little-endian, 'UNITS_PER_WORD == 4' target. Both 17048 'subreg's access the lower two bytes of register X. 17049 17050 Note that the byte offset is a polynomial integer; it may not 17051 be a compile-time constant on targets with variable-sized 17052 modes. However, the restrictions above mean that there are 17053 only a certain set of acceptable offsets for a given 17054 combination of M1 and M2. The compiler can always tell which 17055 blocks a valid subreg occupies, and whether the subreg is a 17056 lowpart of a block. 17057 17058 A 'MODE_PARTIAL_INT' mode behaves as if it were as wide as the 17059 corresponding 'MODE_INT' mode, except that it has an unknown number 17060 of undefined bits. For example: 17061 17062 (subreg:PSI (reg:SI 0) 0) 17063 17064 accesses the whole of '(reg:SI 0)', but the exact relationship 17065 between the 'PSImode' value and the 'SImode' value is not defined. 17066 If we assume 'REGMODE_NATURAL_SIZE (DImode) <= 4', then the 17067 following two 'subreg's: 17068 17069 (subreg:PSI (reg:DI 0) 0) 17070 (subreg:PSI (reg:DI 0) 4) 17071 17072 represent independent 4-byte accesses to the two halves of '(reg:DI 17073 0)'. Both 'subreg's have an unknown number of undefined bits. 17074 17075 If 'REGMODE_NATURAL_SIZE (PSImode) <= 2' then these two 'subreg's: 17076 17077 (subreg:HI (reg:PSI 0) 0) 17078 (subreg:HI (reg:PSI 0) 2) 17079 17080 represent independent 2-byte accesses that together span the whole 17081 of '(reg:PSI 0)'. Storing to the first 'subreg' does not affect 17082 the value of the second, and vice versa. '(reg:PSI 0)' has an 17083 unknown number of undefined bits, so the assignment: 17084 17085 (set (subreg:HI (reg:PSI 0) 0) (reg:HI 4)) 17086 17087 does not guarantee that '(subreg:HI (reg:PSI 0) 0)' has the value 17088 '(reg:HI 4)'. 17089 17090 The rules above apply to both pseudo REGs and hard REGs. If the 17091 semantics are not correct for particular combinations of M1, M2 and 17092 hard REG, the target-specific code must ensure that those 17093 combinations are never used. For example: 17094 17095 TARGET_CAN_CHANGE_MODE_CLASS (M2, M1, CLASS) 17096 17097 must be false for every class CLASS that includes REG. 17098 17099 GCC must be able to determine at compile time whether a subreg is 17100 paradoxical, whether it occupies a whole number of blocks, or 17101 whether it is a lowpart of a block. This means that certain 17102 combinations of variable-sized mode are not permitted. For 17103 example, if M2 holds N 'SI' values, where N is greater than zero, 17104 it is not possible to form a 'DI' 'subreg' of it; such a 'subreg' 17105 would be paradoxical when N is 1 but not when N is greater than 1. 17106 17107 The first operand of a 'subreg' expression is customarily accessed 17108 with the 'SUBREG_REG' macro and the second operand is customarily 17109 accessed with the 'SUBREG_BYTE' macro. 17110 17111 It has been several years since a platform in which 17112 'BYTES_BIG_ENDIAN' not equal to 'WORDS_BIG_ENDIAN' has been tested. 17113 Anyone wishing to support such a platform in the future may be 17114 confronted with code rot. 17115 17116'(scratch:M)' 17117 This represents a scratch register that will be required for the 17118 execution of a single instruction and not used subsequently. It is 17119 converted into a 'reg' by either the local register allocator or 17120 the reload pass. 17121 17122 'scratch' is usually present inside a 'clobber' operation (*note 17123 Side Effects::). 17124 17125'(cc0)' 17126 This refers to the machine's condition code register. It has no 17127 operands and may not have a machine mode. There are two ways to 17128 use it: 17129 17130 * To stand for a complete set of condition code flags. This is 17131 best on most machines, where each comparison sets the entire 17132 series of flags. 17133 17134 With this technique, '(cc0)' may be validly used in only two 17135 contexts: as the destination of an assignment (in test and 17136 compare instructions) and in comparison operators comparing 17137 against zero ('const_int' with value zero; that is to say, 17138 'const0_rtx'). 17139 17140 * To stand for a single flag that is the result of a single 17141 condition. This is useful on machines that have only a single 17142 flag bit, and in which comparison instructions must specify 17143 the condition to test. 17144 17145 With this technique, '(cc0)' may be validly used in only two 17146 contexts: as the destination of an assignment (in test and 17147 compare instructions) where the source is a comparison 17148 operator, and as the first operand of 'if_then_else' (in a 17149 conditional branch). 17150 17151 There is only one expression object of code 'cc0'; it is the value 17152 of the variable 'cc0_rtx'. Any attempt to create an expression of 17153 code 'cc0' will return 'cc0_rtx'. 17154 17155 Instructions can set the condition code implicitly. On many 17156 machines, nearly all instructions set the condition code based on 17157 the value that they compute or store. It is not necessary to 17158 record these actions explicitly in the RTL because the machine 17159 description includes a prescription for recognizing the 17160 instructions that do so (by means of the macro 'NOTICE_UPDATE_CC'). 17161 *Note Condition Code::. Only instructions whose sole purpose is to 17162 set the condition code, and instructions that use the condition 17163 code, need mention '(cc0)'. 17164 17165 On some machines, the condition code register is given a register 17166 number and a 'reg' is used instead of '(cc0)'. This is usually the 17167 preferable approach if only a small subset of instructions modify 17168 the condition code. Other machines store condition codes in 17169 general registers; in such cases a pseudo register should be used. 17170 17171 Some machines, such as the SPARC and RS/6000, have two sets of 17172 arithmetic instructions, one that sets and one that does not set 17173 the condition code. This is best handled by normally generating 17174 the instruction that does not set the condition code, and making a 17175 pattern that both performs the arithmetic and sets the condition 17176 code register (which would not be '(cc0)' in this case). For 17177 examples, search for 'addcc' and 'andcc' in 'sparc.md'. 17178 17179'(pc)' 17180 This represents the machine's program counter. It has no operands 17181 and may not have a machine mode. '(pc)' may be validly used only 17182 in certain specific contexts in jump instructions. 17183 17184 There is only one expression object of code 'pc'; it is the value 17185 of the variable 'pc_rtx'. Any attempt to create an expression of 17186 code 'pc' will return 'pc_rtx'. 17187 17188 All instructions that do not jump alter the program counter 17189 implicitly by incrementing it, but there is no need to mention this 17190 in the RTL. 17191 17192'(mem:M ADDR ALIAS)' 17193 This RTX represents a reference to main memory at an address 17194 represented by the expression ADDR. M specifies how large a unit 17195 of memory is accessed. ALIAS specifies an alias set for the 17196 reference. In general two items are in different alias sets if 17197 they cannot reference the same memory address. 17198 17199 The construct '(mem:BLK (scratch))' is considered to alias all 17200 other memories. Thus it may be used as a memory barrier in 17201 epilogue stack deallocation patterns. 17202 17203'(concatM RTX RTX)' 17204 This RTX represents the concatenation of two other RTXs. This is 17205 used for complex values. It should only appear in the RTL attached 17206 to declarations and during RTL generation. It should not appear in 17207 the ordinary insn chain. 17208 17209'(concatnM [RTX ...])' 17210 This RTX represents the concatenation of all the RTX to make a 17211 single value. Like 'concat', this should only appear in 17212 declarations, and not in the insn chain. 17213 17214 17215File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL 17216 1721714.9 RTL Expressions for Arithmetic 17218=================================== 17219 17220Unless otherwise specified, all the operands of arithmetic expressions 17221must be valid for mode M. An operand is valid for mode M if it has mode 17222M, or if it is a 'const_int' or 'const_double' and M is a mode of class 17223'MODE_INT'. 17224 17225 For commutative binary operations, constants should be placed in the 17226second operand. 17227 17228'(plus:M X Y)' 17229'(ss_plus:M X Y)' 17230'(us_plus:M X Y)' 17231 17232 These three expressions all represent the sum of the values 17233 represented by X and Y carried out in machine mode M. They differ 17234 in their behavior on overflow of integer modes. 'plus' wraps round 17235 modulo the width of M; 'ss_plus' saturates at the maximum signed 17236 value representable in M; 'us_plus' saturates at the maximum 17237 unsigned value. 17238 17239'(lo_sum:M X Y)' 17240 17241 This expression represents the sum of X and the low-order bits of 17242 Y. It is used with 'high' (*note Constants::) to represent the 17243 typical two-instruction sequence used in RISC machines to reference 17244 a global memory location. 17245 17246 The number of low order bits is machine-dependent but is normally 17247 the number of bits in a 'Pmode' item minus the number of bits set 17248 by 'high'. 17249 17250 M should be 'Pmode'. 17251 17252'(minus:M X Y)' 17253'(ss_minus:M X Y)' 17254'(us_minus:M X Y)' 17255 17256 These three expressions represent the result of subtracting Y from 17257 X, carried out in mode M. Behavior on overflow is the same as for 17258 the three variants of 'plus' (see above). 17259 17260'(compare:M X Y)' 17261 Represents the result of subtracting Y from X for purposes of 17262 comparison. The result is computed without overflow, as if with 17263 infinite precision. 17264 17265 Of course, machines cannot really subtract with infinite precision. 17266 However, they can pretend to do so when only the sign of the result 17267 will be used, which is the case when the result is stored in the 17268 condition code. And that is the _only_ way this kind of expression 17269 may validly be used: as a value to be stored in the condition 17270 codes, either '(cc0)' or a register. *Note Comparisons::. 17271 17272 The mode M is not related to the modes of X and Y, but instead is 17273 the mode of the condition code value. If '(cc0)' is used, it is 17274 'VOIDmode'. Otherwise it is some mode in class 'MODE_CC', often 17275 'CCmode'. *Note Condition Code::. If M is 'VOIDmode' or 'CCmode', 17276 the operation returns sufficient information (in an unspecified 17277 format) so that any comparison operator can be applied to the 17278 result of the 'COMPARE' operation. For other modes in class 17279 'MODE_CC', the operation only returns a subset of this information. 17280 17281 Normally, X and Y must have the same mode. Otherwise, 'compare' is 17282 valid only if the mode of X is in class 'MODE_INT' and Y is a 17283 'const_int' or 'const_double' with mode 'VOIDmode'. The mode of X 17284 determines what mode the comparison is to be done in; thus it must 17285 not be 'VOIDmode'. 17286 17287 If one of the operands is a constant, it should be placed in the 17288 second operand and the comparison code adjusted as appropriate. 17289 17290 A 'compare' specifying two 'VOIDmode' constants is not valid since 17291 there is no way to know in what mode the comparison is to be 17292 performed; the comparison must either be folded during the 17293 compilation or the first operand must be loaded into a register 17294 while its mode is still known. 17295 17296'(neg:M X)' 17297'(ss_neg:M X)' 17298'(us_neg:M X)' 17299 These two expressions represent the negation (subtraction from 17300 zero) of the value represented by X, carried out in mode M. They 17301 differ in the behavior on overflow of integer modes. In the case 17302 of 'neg', the negation of the operand may be a number not 17303 representable in mode M, in which case it is truncated to M. 17304 'ss_neg' and 'us_neg' ensure that an out-of-bounds result saturates 17305 to the maximum or minimum signed or unsigned value. 17306 17307'(mult:M X Y)' 17308'(ss_mult:M X Y)' 17309'(us_mult:M X Y)' 17310 Represents the signed product of the values represented by X and Y 17311 carried out in machine mode M. 'ss_mult' and 'us_mult' ensure that 17312 an out-of-bounds result saturates to the maximum or minimum signed 17313 or unsigned value. 17314 17315 Some machines support a multiplication that generates a product 17316 wider than the operands. Write the pattern for this as 17317 17318 (mult:M (sign_extend:M X) (sign_extend:M Y)) 17319 17320 where M is wider than the modes of X and Y, which need not be the 17321 same. 17322 17323 For unsigned widening multiplication, use the same idiom, but with 17324 'zero_extend' instead of 'sign_extend'. 17325 17326'(fma:M X Y Z)' 17327 Represents the 'fma', 'fmaf', and 'fmal' builtin functions, which 17328 compute 'X * Y + Z' without doing an intermediate rounding step. 17329 17330'(div:M X Y)' 17331'(ss_div:M X Y)' 17332 Represents the quotient in signed division of X by Y, carried out 17333 in machine mode M. If M is a floating point mode, it represents 17334 the exact quotient; otherwise, the integerized quotient. 'ss_div' 17335 ensures that an out-of-bounds result saturates to the maximum or 17336 minimum signed value. 17337 17338 Some machines have division instructions in which the operands and 17339 quotient widths are not all the same; you should represent such 17340 instructions using 'truncate' and 'sign_extend' as in, 17341 17342 (truncate:M1 (div:M2 X (sign_extend:M2 Y))) 17343 17344'(udiv:M X Y)' 17345'(us_div:M X Y)' 17346 Like 'div' but represents unsigned division. 'us_div' ensures that 17347 an out-of-bounds result saturates to the maximum or minimum 17348 unsigned value. 17349 17350'(mod:M X Y)' 17351'(umod:M X Y)' 17352 Like 'div' and 'udiv' but represent the remainder instead of the 17353 quotient. 17354 17355'(smin:M X Y)' 17356'(smax:M X Y)' 17357 Represents the smaller (for 'smin') or larger (for 'smax') of X and 17358 Y, interpreted as signed values in mode M. When used with floating 17359 point, if both operands are zeros, or if either operand is 'NaN', 17360 then it is unspecified which of the two operands is returned as the 17361 result. 17362 17363'(umin:M X Y)' 17364'(umax:M X Y)' 17365 Like 'smin' and 'smax', but the values are interpreted as unsigned 17366 integers. 17367 17368'(not:M X)' 17369 Represents the bitwise complement of the value represented by X, 17370 carried out in mode M, which must be a fixed-point machine mode. 17371 17372'(and:M X Y)' 17373 Represents the bitwise logical-and of the values represented by X 17374 and Y, carried out in machine mode M, which must be a fixed-point 17375 machine mode. 17376 17377'(ior:M X Y)' 17378 Represents the bitwise inclusive-or of the values represented by X 17379 and Y, carried out in machine mode M, which must be a fixed-point 17380 mode. 17381 17382'(xor:M X Y)' 17383 Represents the bitwise exclusive-or of the values represented by X 17384 and Y, carried out in machine mode M, which must be a fixed-point 17385 mode. 17386 17387'(ashift:M X C)' 17388'(ss_ashift:M X C)' 17389'(us_ashift:M X C)' 17390 These three expressions represent the result of arithmetically 17391 shifting X left by C places. They differ in their behavior on 17392 overflow of integer modes. An 'ashift' operation is a plain shift 17393 with no special behavior in case of a change in the sign bit; 17394 'ss_ashift' and 'us_ashift' saturates to the minimum or maximum 17395 representable value if any of the bits shifted out differs from the 17396 final sign bit. 17397 17398 X have mode M, a fixed-point machine mode. C be a fixed-point mode 17399 or be a constant with mode 'VOIDmode'; which mode is determined by 17400 the mode called for in the machine description entry for the 17401 left-shift instruction. For example, on the VAX, the mode of C is 17402 'QImode' regardless of M. 17403 17404'(lshiftrt:M X C)' 17405'(ashiftrt:M X C)' 17406 Like 'ashift' but for right shift. Unlike the case for left shift, 17407 these two operations are distinct. 17408 17409'(rotate:M X C)' 17410'(rotatert:M X C)' 17411 Similar but represent left and right rotate. If C is a constant, 17412 use 'rotate'. 17413 17414'(abs:M X)' 17415'(ss_abs:M X)' 17416 Represents the absolute value of X, computed in mode M. 'ss_abs' 17417 ensures that an out-of-bounds result saturates to the maximum 17418 signed value. 17419 17420'(sqrt:M X)' 17421 Represents the square root of X, computed in mode M. Most often M 17422 will be a floating point mode. 17423 17424'(ffs:M X)' 17425 Represents one plus the index of the least significant 1-bit in X, 17426 represented as an integer of mode M. (The value is zero if X is 17427 zero.) The mode of X must be M or 'VOIDmode'. 17428 17429'(clrsb:M X)' 17430 Represents the number of redundant leading sign bits in X, 17431 represented as an integer of mode M, starting at the most 17432 significant bit position. This is one less than the number of 17433 leading sign bits (either 0 or 1), with no special cases. The mode 17434 of X must be M or 'VOIDmode'. 17435 17436'(clz:M X)' 17437 Represents the number of leading 0-bits in X, represented as an 17438 integer of mode M, starting at the most significant bit position. 17439 If X is zero, the value is determined by 17440 'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Note that this is one 17441 of the few expressions that is not invariant under widening. The 17442 mode of X must be M or 'VOIDmode'. 17443 17444'(ctz:M X)' 17445 Represents the number of trailing 0-bits in X, represented as an 17446 integer of mode M, starting at the least significant bit position. 17447 If X is zero, the value is determined by 17448 'CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Except for this case, 17449 'ctz(x)' is equivalent to 'ffs(X) - 1'. The mode of X must be M or 17450 'VOIDmode'. 17451 17452'(popcount:M X)' 17453 Represents the number of 1-bits in X, represented as an integer of 17454 mode M. The mode of X must be M or 'VOIDmode'. 17455 17456'(parity:M X)' 17457 Represents the number of 1-bits modulo 2 in X, represented as an 17458 integer of mode M. The mode of X must be M or 'VOIDmode'. 17459 17460'(bswap:M X)' 17461 Represents the value X with the order of bytes reversed, carried 17462 out in mode M, which must be a fixed-point machine mode. The mode 17463 of X must be M or 'VOIDmode'. 17464 17465 17466File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL 17467 1746814.10 Comparison Operations 17469=========================== 17470 17471Comparison operators test a relation on two operands and are considered 17472to represent a machine-dependent nonzero value described by, but not 17473necessarily equal to, 'STORE_FLAG_VALUE' (*note Misc::) if the relation 17474holds, or zero if it does not, for comparison operators whose results 17475have a 'MODE_INT' mode, 'FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the 17476relation holds, or zero if it does not, for comparison operators that 17477return floating-point values, and a vector of either 17478'VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of 17479zeros if it does not, for comparison operators that return vector 17480results. The mode of the comparison operation is independent of the 17481mode of the data being compared. If the comparison operation is being 17482tested (e.g., the first operand of an 'if_then_else'), the mode must be 17483'VOIDmode'. 17484 17485 There are two ways that comparison operations may be used. The 17486comparison operators may be used to compare the condition codes '(cc0)' 17487against zero, as in '(eq (cc0) (const_int 0))'. Such a construct 17488actually refers to the result of the preceding instruction in which the 17489condition codes were set. The instruction setting the condition code 17490must be adjacent to the instruction using the condition code; only 17491'note' insns may separate them. 17492 17493 Alternatively, a comparison operation may directly compare two data 17494objects. The mode of the comparison is determined by the operands; they 17495must both be valid for a common machine mode. A comparison with both 17496operands constant would be invalid as the machine mode could not be 17497deduced from it, but such a comparison should never exist in RTL due to 17498constant folding. 17499 17500 In the example above, if '(cc0)' were last set to '(compare X Y)', the 17501comparison operation is identical to '(eq X Y)'. Usually only one style 17502of comparisons is supported on a particular machine, but the combine 17503pass will try to merge the operations to produce the 'eq' shown in case 17504it exists in the context of the particular insn involved. 17505 17506 Inequality comparisons come in two flavors, signed and unsigned. Thus, 17507there are distinct expression codes 'gt' and 'gtu' for signed and 17508unsigned greater-than. These can produce different results for the same 17509pair of integer values: for example, 1 is signed greater-than -1 but not 17510unsigned greater-than, because -1 when regarded as unsigned is actually 17511'0xffffffff' which is greater than 1. 17512 17513 The signed comparisons are also used for floating point values. 17514Floating point comparisons are distinguished by the machine modes of the 17515operands. 17516 17517'(eq:M X Y)' 17518 'STORE_FLAG_VALUE' if the values represented by X and Y are equal, 17519 otherwise 0. 17520 17521'(ne:M X Y)' 17522 'STORE_FLAG_VALUE' if the values represented by X and Y are not 17523 equal, otherwise 0. 17524 17525'(gt:M X Y)' 17526 'STORE_FLAG_VALUE' if the X is greater than Y. If they are 17527 fixed-point, the comparison is done in a signed sense. 17528 17529'(gtu:M X Y)' 17530 Like 'gt' but does unsigned comparison, on fixed-point numbers 17531 only. 17532 17533'(lt:M X Y)' 17534'(ltu:M X Y)' 17535 Like 'gt' and 'gtu' but test for "less than". 17536 17537'(ge:M X Y)' 17538'(geu:M X Y)' 17539 Like 'gt' and 'gtu' but test for "greater than or equal". 17540 17541'(le:M X Y)' 17542'(leu:M X Y)' 17543 Like 'gt' and 'gtu' but test for "less than or equal". 17544 17545'(if_then_else COND THEN ELSE)' 17546 This is not a comparison operation but is listed here because it is 17547 always used in conjunction with a comparison operation. To be 17548 precise, COND is a comparison expression. This expression 17549 represents a choice, according to COND, between the value 17550 represented by THEN and the one represented by ELSE. 17551 17552 On most machines, 'if_then_else' expressions are valid only to 17553 express conditional jumps. 17554 17555'(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' 17556 Similar to 'if_then_else', but more general. Each of TEST1, TEST2, 17557 ... is performed in turn. The result of this expression is the 17558 VALUE corresponding to the first nonzero test, or DEFAULT if none 17559 of the tests are nonzero expressions. 17560 17561 This is currently not valid for instruction patterns and is 17562 supported only for insn attributes. *Note Insn Attributes::. 17563 17564 17565File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL 17566 1756714.11 Bit-Fields 17568================ 17569 17570Special expression codes exist to represent bit-field instructions. 17571 17572'(sign_extract:M LOC SIZE POS)' 17573 This represents a reference to a sign-extended bit-field contained 17574 or starting in LOC (a memory or register reference). The bit-field 17575 is SIZE bits wide and starts at bit POS. The compilation option 17576 'BITS_BIG_ENDIAN' says which end of the memory unit POS counts 17577 from. 17578 17579 If LOC is in memory, its mode must be a single-byte integer mode. 17580 If LOC is in a register, the mode to use is specified by the 17581 operand of the 'insv' or 'extv' pattern (*note Standard Names::) 17582 and is usually a full-word integer mode, which is the default if 17583 none is specified. 17584 17585 The mode of POS is machine-specific and is also specified in the 17586 'insv' or 'extv' pattern. 17587 17588 The mode M is the same as the mode that would be used for LOC if it 17589 were a register. 17590 17591 A 'sign_extract' can not appear as an lvalue, or part thereof, in 17592 RTL. 17593 17594'(zero_extract:M LOC SIZE POS)' 17595 Like 'sign_extract' but refers to an unsigned or zero-extended 17596 bit-field. The same sequence of bits are extracted, but they are 17597 filled to an entire word with zeros instead of by sign-extension. 17598 17599 Unlike 'sign_extract', this type of expressions can be lvalues in 17600 RTL; they may appear on the left side of an assignment, indicating 17601 insertion of a value into the specified bit-field. 17602 17603 17604File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL 17605 1760614.12 Vector Operations 17607======================= 17608 17609All normal RTL expressions can be used with vector modes; they are 17610interpreted as operating on each part of the vector independently. 17611Additionally, there are a few new expressions to describe specific 17612vector operations. 17613 17614'(vec_merge:M VEC1 VEC2 ITEMS)' 17615 This describes a merge operation between two vectors. The result 17616 is a vector of mode M; its elements are selected from either VEC1 17617 or VEC2. Which elements are selected is described by ITEMS, which 17618 is a bit mask represented by a 'const_int'; a zero bit indicates 17619 the corresponding element in the result vector is taken from VEC2 17620 while a set bit indicates it is taken from VEC1. 17621 17622'(vec_select:M VEC1 SELECTION)' 17623 This describes an operation that selects parts of a vector. VEC1 17624 is the source vector, and SELECTION is a 'parallel' that contains a 17625 'const_int' for each of the subparts of the result vector, giving 17626 the number of the source subpart that should be stored into it. 17627 The result mode M is either the submode for a single element of 17628 VEC1 (if only one subpart is selected), or another vector mode with 17629 that element submode (if multiple subparts are selected). 17630 17631'(vec_concat:M X1 X2)' 17632 Describes a vector concat operation. The result is a concatenation 17633 of the vectors or scalars X1 and X2; its length is the sum of the 17634 lengths of the two inputs. 17635 17636'(vec_duplicate:M X)' 17637 This operation converts a scalar into a vector or a small vector 17638 into a larger one by duplicating the input values. The output 17639 vector mode must have the same submodes as the input vector mode or 17640 the scalar modes, and the number of output parts must be an integer 17641 multiple of the number of input parts. 17642 17643'(vec_series:M BASE STEP)' 17644 This operation creates a vector in which element I is equal to 17645 'BASE + I*STEP'. M must be a vector integer mode. 17646 17647 17648File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL 17649 1765014.13 Conversions 17651================= 17652 17653All conversions between machine modes must be represented by explicit 17654conversion operations. For example, an expression which is the sum of a 17655byte and a full word cannot be written as '(plus:SI (reg:QI 34) (reg:SI 1765680))' because the 'plus' operation requires two operands of the same 17657machine mode. Therefore, the byte-sized operand is enclosed in a 17658conversion operation, as in 17659 17660 (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) 17661 17662 The conversion operation is not a mere placeholder, because there may 17663be more than one way of converting from a given starting mode to the 17664desired final mode. The conversion operation code says how to do it. 17665 17666 For all conversion operations, X must not be 'VOIDmode' because the 17667mode in which to do the conversion would not be known. The conversion 17668must either be done at compile-time or X must be placed into a register. 17669 17670'(sign_extend:M X)' 17671 Represents the result of sign-extending the value X to machine mode 17672 M. M must be a fixed-point mode and X a fixed-point value of a 17673 mode narrower than M. 17674 17675'(zero_extend:M X)' 17676 Represents the result of zero-extending the value X to machine mode 17677 M. M must be a fixed-point mode and X a fixed-point value of a 17678 mode narrower than M. 17679 17680'(float_extend:M X)' 17681 Represents the result of extending the value X to machine mode M. 17682 M must be a floating point mode and X a floating point value of a 17683 mode narrower than M. 17684 17685'(truncate:M X)' 17686 Represents the result of truncating the value X to machine mode M. 17687 M must be a fixed-point mode and X a fixed-point value of a mode 17688 wider than M. 17689 17690'(ss_truncate:M X)' 17691 Represents the result of truncating the value X to machine mode M, 17692 using signed saturation in the case of overflow. Both M and the 17693 mode of X must be fixed-point modes. 17694 17695'(us_truncate:M X)' 17696 Represents the result of truncating the value X to machine mode M, 17697 using unsigned saturation in the case of overflow. Both M and the 17698 mode of X must be fixed-point modes. 17699 17700'(float_truncate:M X)' 17701 Represents the result of truncating the value X to machine mode M. 17702 M must be a floating point mode and X a floating point value of a 17703 mode wider than M. 17704 17705'(float:M X)' 17706 Represents the result of converting fixed point value X, regarded 17707 as signed, to floating point mode M. 17708 17709'(unsigned_float:M X)' 17710 Represents the result of converting fixed point value X, regarded 17711 as unsigned, to floating point mode M. 17712 17713'(fix:M X)' 17714 When M is a floating-point mode, represents the result of 17715 converting floating point value X (valid for mode M) to an integer, 17716 still represented in floating point mode M, by rounding towards 17717 zero. 17718 17719 When M is a fixed-point mode, represents the result of converting 17720 floating point value X to mode M, regarded as signed. How rounding 17721 is done is not specified, so this operation may be used validly in 17722 compiling C code only for integer-valued operands. 17723 17724'(unsigned_fix:M X)' 17725 Represents the result of converting floating point value X to fixed 17726 point mode M, regarded as unsigned. How rounding is done is not 17727 specified. 17728 17729'(fract_convert:M X)' 17730 Represents the result of converting fixed-point value X to 17731 fixed-point mode M, signed integer value X to fixed-point mode M, 17732 floating-point value X to fixed-point mode M, fixed-point value X 17733 to integer mode M regarded as signed, or fixed-point value X to 17734 floating-point mode M. When overflows or underflows happen, the 17735 results are undefined. 17736 17737'(sat_fract:M X)' 17738 Represents the result of converting fixed-point value X to 17739 fixed-point mode M, signed integer value X to fixed-point mode M, 17740 or floating-point value X to fixed-point mode M. When overflows or 17741 underflows happen, the results are saturated to the maximum or the 17742 minimum. 17743 17744'(unsigned_fract_convert:M X)' 17745 Represents the result of converting fixed-point value X to integer 17746 mode M regarded as unsigned, or unsigned integer value X to 17747 fixed-point mode M. When overflows or underflows happen, the 17748 results are undefined. 17749 17750'(unsigned_sat_fract:M X)' 17751 Represents the result of converting unsigned integer value X to 17752 fixed-point mode M. When overflows or underflows happen, the 17753 results are saturated to the maximum or the minimum. 17754 17755 17756File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL 17757 1775814.14 Declarations 17759================== 17760 17761Declaration expression codes do not represent arithmetic operations but 17762rather state assertions about their operands. 17763 17764'(strict_low_part (subreg:M (reg:N R) 0))' 17765 This expression code is used in only one context: as the 17766 destination operand of a 'set' expression. In addition, the 17767 operand of this expression must be a non-paradoxical 'subreg' 17768 expression. 17769 17770 The presence of 'strict_low_part' says that the part of the 17771 register which is meaningful in mode N, but is not part of mode M, 17772 is not to be altered. Normally, an assignment to such a subreg is 17773 allowed to have undefined effects on the rest of the register when 17774 M is smaller than 'REGMODE_NATURAL_SIZE (N)'. 17775 17776 17777File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL 17778 1777914.15 Side Effect Expressions 17780============================= 17781 17782The expression codes described so far represent values, not actions. 17783But machine instructions never produce values; they are meaningful only 17784for their side effects on the state of the machine. Special expression 17785codes are used to represent side effects. 17786 17787 The body of an instruction is always one of these side effect codes; 17788the codes described above, which represent values, appear only as the 17789operands of these. 17790 17791'(set LVAL X)' 17792 Represents the action of storing the value of X into the place 17793 represented by LVAL. LVAL must be an expression representing a 17794 place that can be stored in: 'reg' (or 'subreg', 'strict_low_part' 17795 or 'zero_extract'), 'mem', 'pc', 'parallel', or 'cc0'. 17796 17797 If LVAL is a 'reg', 'subreg' or 'mem', it has a machine mode; then 17798 X must be valid for that mode. 17799 17800 If LVAL is a 'reg' whose machine mode is less than the full width 17801 of the register, then it means that the part of the register 17802 specified by the machine mode is given the specified value and the 17803 rest of the register receives an undefined value. Likewise, if 17804 LVAL is a 'subreg' whose machine mode is narrower than the mode of 17805 the register, the rest of the register can be changed in an 17806 undefined way. 17807 17808 If LVAL is a 'strict_low_part' of a subreg, then the part of the 17809 register specified by the machine mode of the 'subreg' is given the 17810 value X and the rest of the register is not changed. 17811 17812 If LVAL is a 'zero_extract', then the referenced part of the 17813 bit-field (a memory or register reference) specified by the 17814 'zero_extract' is given the value X and the rest of the bit-field 17815 is not changed. Note that 'sign_extract' can not appear in LVAL. 17816 17817 If LVAL is '(cc0)', it has no machine mode, and X may be either a 17818 'compare' expression or a value that may have any mode. The latter 17819 case represents a "test" instruction. The expression '(set (cc0) 17820 (reg:M N))' is equivalent to '(set (cc0) (compare (reg:M N) 17821 (const_int 0)))'. Use the former expression to save space during 17822 the compilation. 17823 17824 If LVAL is a 'parallel', it is used to represent the case of a 17825 function returning a structure in multiple registers. Each element 17826 of the 'parallel' is an 'expr_list' whose first operand is a 'reg' 17827 and whose second operand is a 'const_int' representing the offset 17828 (in bytes) into the structure at which the data in that register 17829 corresponds. The first element may be null to indicate that the 17830 structure is also passed partly in memory. 17831 17832 If LVAL is '(pc)', we have a jump instruction, and the 17833 possibilities for X are very limited. It may be a 'label_ref' 17834 expression (unconditional jump). It may be an 'if_then_else' 17835 (conditional jump), in which case either the second or the third 17836 operand must be '(pc)' (for the case which does not jump) and the 17837 other of the two must be a 'label_ref' (for the case which does 17838 jump). X may also be a 'mem' or '(plus:SI (pc) Y)', where Y may be 17839 a 'reg' or a 'mem'; these unusual patterns are used to represent 17840 jumps through branch tables. 17841 17842 If LVAL is neither '(cc0)' nor '(pc)', the mode of LVAL must not be 17843 'VOIDmode' and the mode of X must be valid for the mode of LVAL. 17844 17845 LVAL is customarily accessed with the 'SET_DEST' macro and X with 17846 the 'SET_SRC' macro. 17847 17848'(return)' 17849 As the sole expression in a pattern, represents a return from the 17850 current function, on machines where this can be done with one 17851 instruction, such as VAXen. On machines where a multi-instruction 17852 "epilogue" must be executed in order to return from the function, 17853 returning is done by jumping to a label which precedes the 17854 epilogue, and the 'return' expression code is never used. 17855 17856 Inside an 'if_then_else' expression, represents the value to be 17857 placed in 'pc' to return to the caller. 17858 17859 Note that an insn pattern of '(return)' is logically equivalent to 17860 '(set (pc) (return))', but the latter form is never used. 17861 17862'(simple_return)' 17863 Like '(return)', but truly represents only a function return, while 17864 '(return)' may represent an insn that also performs other functions 17865 of the function epilogue. Like '(return)', this may also occur in 17866 conditional jumps. 17867 17868'(call FUNCTION NARGS)' 17869 Represents a function call. FUNCTION is a 'mem' expression whose 17870 address is the address of the function to be called. NARGS is an 17871 expression which can be used for two purposes: on some machines it 17872 represents the number of bytes of stack argument; on others, it 17873 represents the number of argument registers. 17874 17875 Each machine has a standard machine mode which FUNCTION must have. 17876 The machine description defines macro 'FUNCTION_MODE' to expand 17877 into the requisite mode name. The purpose of this mode is to 17878 specify what kind of addressing is allowed, on machines where the 17879 allowed kinds of addressing depend on the machine mode being 17880 addressed. 17881 17882'(clobber X)' 17883 Represents the storing or possible storing of an unpredictable, 17884 undescribed value into X, which must be a 'reg', 'scratch', 17885 'parallel' or 'mem' expression. 17886 17887 One place this is used is in string instructions that store 17888 standard values into particular hard registers. It may not be 17889 worth the trouble to describe the values that are stored, but it is 17890 essential to inform the compiler that the registers will be 17891 altered, lest it attempt to keep data in them across the string 17892 instruction. 17893 17894 If X is '(mem:BLK (const_int 0))' or '(mem:BLK (scratch))', it 17895 means that all memory locations must be presumed clobbered. If X 17896 is a 'parallel', it has the same meaning as a 'parallel' in a 'set' 17897 expression. 17898 17899 Note that the machine description classifies certain hard registers 17900 as "call-clobbered". All function call instructions are assumed by 17901 default to clobber these registers, so there is no need to use 17902 'clobber' expressions to indicate this fact. Also, each function 17903 call is assumed to have the potential to alter any memory location, 17904 unless the function is declared 'const'. 17905 17906 If the last group of expressions in a 'parallel' are each a 17907 'clobber' expression whose arguments are 'reg' or 'match_scratch' 17908 (*note RTL Template::) expressions, the combiner phase can add the 17909 appropriate 'clobber' expressions to an insn it has constructed 17910 when doing so will cause a pattern to be matched. 17911 17912 This feature can be used, for example, on a machine that whose 17913 multiply and add instructions don't use an MQ register but which 17914 has an add-accumulate instruction that does clobber the MQ 17915 register. Similarly, a combined instruction might require a 17916 temporary register while the constituent instructions might not. 17917 17918 When a 'clobber' expression for a register appears inside a 17919 'parallel' with other side effects, the register allocator 17920 guarantees that the register is unoccupied both before and after 17921 that insn if it is a hard register clobber. For pseudo-register 17922 clobber, the register allocator and the reload pass do not assign 17923 the same hard register to the clobber and the input operands if 17924 there is an insn alternative containing the '&' constraint (*note 17925 Modifiers::) for the clobber and the hard register is in register 17926 classes of the clobber in the alternative. You can clobber either 17927 a specific hard register, a pseudo register, or a 'scratch' 17928 expression; in the latter two cases, GCC will allocate a hard 17929 register that is available there for use as a temporary. 17930 17931 For instructions that require a temporary register, you should use 17932 'scratch' instead of a pseudo-register because this will allow the 17933 combiner phase to add the 'clobber' when required. You do this by 17934 coding ('clobber' ('match_scratch' ...)). If you do clobber a 17935 pseudo register, use one which appears nowhere else--generate a new 17936 one each time. Otherwise, you may confuse CSE. 17937 17938 There is one other known use for clobbering a pseudo register in a 17939 'parallel': when one of the input operands of the insn is also 17940 clobbered by the insn. In this case, using the same pseudo 17941 register in the clobber and elsewhere in the insn produces the 17942 expected results. 17943 17944'(use X)' 17945 Represents the use of the value of X. It indicates that the value 17946 in X at this point in the program is needed, even though it may not 17947 be apparent why this is so. Therefore, the compiler will not 17948 attempt to delete previous instructions whose only effect is to 17949 store a value in X. X must be a 'reg' expression. 17950 17951 In some situations, it may be tempting to add a 'use' of a register 17952 in a 'parallel' to describe a situation where the value of a 17953 special register will modify the behavior of the instruction. A 17954 hypothetical example might be a pattern for an addition that can 17955 either wrap around or use saturating addition depending on the 17956 value of a special control register: 17957 17958 (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3) 17959 (reg:SI 4)] 0)) 17960 (use (reg:SI 1))]) 17961 17962 17963 This will not work, several of the optimizers only look at 17964 expressions locally; it is very likely that if you have multiple 17965 insns with identical inputs to the 'unspec', they will be optimized 17966 away even if register 1 changes in between. 17967 17968 This means that 'use' can _only_ be used to describe that the 17969 register is live. You should think twice before adding 'use' 17970 statements, more often you will want to use 'unspec' instead. The 17971 'use' RTX is most commonly useful to describe that a fixed register 17972 is implicitly used in an insn. It is also safe to use in patterns 17973 where the compiler knows for other reasons that the result of the 17974 whole pattern is variable, such as 'movmemM' or 'call' patterns. 17975 17976 During the reload phase, an insn that has a 'use' as pattern can 17977 carry a reg_equal note. These 'use' insns will be deleted before 17978 the reload phase exits. 17979 17980 During the delayed branch scheduling phase, X may be an insn. This 17981 indicates that X previously was located at this place in the code 17982 and its data dependencies need to be taken into account. These 17983 'use' insns will be deleted before the delayed branch scheduling 17984 phase exits. 17985 17986'(parallel [X0 X1 ...])' 17987 Represents several side effects performed in parallel. The square 17988 brackets stand for a vector; the operand of 'parallel' is a vector 17989 of expressions. X0, X1 and so on are individual side effect 17990 expressions--expressions of code 'set', 'call', 'return', 17991 'simple_return', 'clobber' or 'use'. 17992 17993 "In parallel" means that first all the values used in the 17994 individual side-effects are computed, and second all the actual 17995 side-effects are performed. For example, 17996 17997 (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) 17998 (set (mem:SI (reg:SI 1)) (reg:SI 1))]) 17999 18000 says unambiguously that the values of hard register 1 and the 18001 memory location addressed by it are interchanged. In both places 18002 where '(reg:SI 1)' appears as a memory address it refers to the 18003 value in register 1 _before_ the execution of the insn. 18004 18005 It follows that it is _incorrect_ to use 'parallel' and expect the 18006 result of one 'set' to be available for the next one. For example, 18007 people sometimes attempt to represent a jump-if-zero instruction 18008 this way: 18009 18010 (parallel [(set (cc0) (reg:SI 34)) 18011 (set (pc) (if_then_else 18012 (eq (cc0) (const_int 0)) 18013 (label_ref ...) 18014 (pc)))]) 18015 18016 But this is incorrect, because it says that the jump condition 18017 depends on the condition code value _before_ this instruction, not 18018 on the new value that is set by this instruction. 18019 18020 Peephole optimization, which takes place together with final 18021 assembly code output, can produce insns whose patterns consist of a 18022 'parallel' whose elements are the operands needed to output the 18023 resulting assembler code--often 'reg', 'mem' or constant 18024 expressions. This would not be well-formed RTL at any other stage 18025 in compilation, but it is OK then because no further optimization 18026 remains to be done. However, the definition of the macro 18027 'NOTICE_UPDATE_CC', if any, must deal with such insns if you define 18028 any peephole optimizations. 18029 18030'(cond_exec [COND EXPR])' 18031 Represents a conditionally executed expression. The EXPR is 18032 executed only if the COND is nonzero. The COND expression must not 18033 have side-effects, but the EXPR may very well have side-effects. 18034 18035'(sequence [INSNS ...])' 18036 Represents a sequence of insns. If a 'sequence' appears in the 18037 chain of insns, then each of the INSNS that appears in the sequence 18038 must be suitable for appearing in the chain of insns, i.e. must 18039 satisfy the 'INSN_P' predicate. 18040 18041 After delay-slot scheduling is completed, an insn and all the insns 18042 that reside in its delay slots are grouped together into a 18043 'sequence'. The insn requiring the delay slot is the first insn in 18044 the vector; subsequent insns are to be placed in the delay slot. 18045 18046 'INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to 18047 indicate that a branch insn should be used that will conditionally 18048 annul the effect of the insns in the delay slots. In such a case, 18049 'INSN_FROM_TARGET_P' indicates that the insn is from the target of 18050 the branch and should be executed only if the branch is taken; 18051 otherwise the insn should be executed only if the branch is not 18052 taken. *Note Delay Slots::. 18053 18054 Some back ends also use 'sequence' objects for purposes other than 18055 delay-slot groups. This is not supported in the common parts of 18056 the compiler, which treat such sequences as delay-slot groups. 18057 18058 DWARF2 Call Frame Address (CFA) adjustments are sometimes also 18059 expressed using 'sequence' objects as the value of a 18060 'RTX_FRAME_RELATED_P' note. This only happens if the CFA 18061 adjustments cannot be easily derived from the pattern of the 18062 instruction to which the note is attached. In such cases, the 18063 value of the note is used instead of best-guesing the semantics of 18064 the instruction. The back end can attach notes containing a 18065 'sequence' of 'set' patterns that express the effect of the parent 18066 instruction. 18067 18068 These expression codes appear in place of a side effect, as the body of 18069an insn, though strictly speaking they do not always describe side 18070effects as such: 18071 18072'(asm_input S)' 18073 Represents literal assembler code as described by the string S. 18074 18075'(unspec [OPERANDS ...] INDEX)' 18076'(unspec_volatile [OPERANDS ...] INDEX)' 18077 Represents a machine-specific operation on OPERANDS. INDEX selects 18078 between multiple machine-specific operations. 'unspec_volatile' is 18079 used for volatile operations and operations that may trap; 'unspec' 18080 is used for other operations. 18081 18082 These codes may appear inside a 'pattern' of an insn, inside a 18083 'parallel', or inside an expression. 18084 18085'(addr_vec:M [LR0 LR1 ...])' 18086 Represents a table of jump addresses. The vector elements LR0, 18087 etc., are 'label_ref' expressions. The mode M specifies how much 18088 space is given to each address; normally M would be 'Pmode'. 18089 18090'(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)' 18091 Represents a table of jump addresses expressed as offsets from 18092 BASE. The vector elements LR0, etc., are 'label_ref' expressions 18093 and so is BASE. The mode M specifies how much space is given to 18094 each address-difference. MIN and MAX are set up by branch 18095 shortening and hold a label with a minimum and a maximum address, 18096 respectively. FLAGS indicates the relative position of BASE, MIN 18097 and MAX to the containing insn and of MIN and MAX to BASE. See 18098 rtl.def for details. 18099 18100'(prefetch:M ADDR RW LOCALITY)' 18101 Represents prefetch of memory at address ADDR. Operand RW is 1 if 18102 the prefetch is for data to be written, 0 otherwise; targets that 18103 do not support write prefetches should treat this as a normal 18104 prefetch. Operand LOCALITY specifies the amount of temporal 18105 locality; 0 if there is none or 1, 2, or 3 for increasing levels of 18106 temporal locality; targets that do not support locality hints 18107 should ignore this. 18108 18109 This insn is used to minimize cache-miss latency by moving data 18110 into a cache before it is accessed. It should use only 18111 non-faulting data prefetch instructions. 18112 18113 18114File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL 18115 1811614.16 Embedded Side-Effects on Addresses 18117======================================== 18118 18119Six special side-effect expression codes appear as memory addresses. 18120 18121'(pre_dec:M X)' 18122 Represents the side effect of decrementing X by a standard amount 18123 and represents also the value that X has after being decremented. 18124 X must be a 'reg' or 'mem', but most machines allow only a 'reg'. 18125 M must be the machine mode for pointers on the machine in use. The 18126 amount X is decremented by is the length in bytes of the machine 18127 mode of the containing memory reference of which this expression 18128 serves as the address. Here is an example of its use: 18129 18130 (mem:DF (pre_dec:SI (reg:SI 39))) 18131 18132 This says to decrement pseudo register 39 by the length of a 18133 'DFmode' value and use the result to address a 'DFmode' value. 18134 18135'(pre_inc:M X)' 18136 Similar, but specifies incrementing X instead of decrementing it. 18137 18138'(post_dec:M X)' 18139 Represents the same side effect as 'pre_dec' but a different value. 18140 The value represented here is the value X has before being 18141 decremented. 18142 18143'(post_inc:M X)' 18144 Similar, but specifies incrementing X instead of decrementing it. 18145 18146'(post_modify:M X Y)' 18147 18148 Represents the side effect of setting X to Y and represents X 18149 before X is modified. X must be a 'reg' or 'mem', but most 18150 machines allow only a 'reg'. M must be the machine mode for 18151 pointers on the machine in use. 18152 18153 The expression Y must be one of three forms: '(plus:M X Z)', 18154 '(minus:M X Z)', or '(plus:M X I)', where Z is an index register 18155 and I is a constant. 18156 18157 Here is an example of its use: 18158 18159 (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42) 18160 (reg:SI 48)))) 18161 18162 This says to modify pseudo register 42 by adding the contents of 18163 pseudo register 48 to it, after the use of what ever 42 points to. 18164 18165'(pre_modify:M X EXPR)' 18166 Similar except side effects happen before the use. 18167 18168 These embedded side effect expressions must be used with care. 18169Instruction patterns may not use them. Until the 'flow' pass of the 18170compiler, they may occur only to represent pushes onto the stack. The 18171'flow' pass finds cases where registers are incremented or decremented 18172in one instruction and used as an address shortly before or after; these 18173cases are then transformed to use pre- or post-increment or -decrement. 18174 18175 If a register used as the operand of these expressions is used in 18176another address in an insn, the original value of the register is used. 18177Uses of the register outside of an address are not permitted within the 18178same insn as a use in an embedded side effect expression because such 18179insns behave differently on different machines and hence must be treated 18180as ambiguous and disallowed. 18181 18182 An instruction that can be represented with an embedded side effect 18183could also be represented using 'parallel' containing an additional 18184'set' to describe how the address register is altered. This is not done 18185because machines that allow these operations at all typically allow them 18186wherever a memory address is called for. Describing them as additional 18187parallel stores would require doubling the number of entries in the 18188machine description. 18189 18190 18191File: gccint.info, Node: Assembler, Next: Debug Information, Prev: Incdec, Up: RTL 18192 1819314.17 Assembler Instructions as Expressions 18194=========================================== 18195 18196The RTX code 'asm_operands' represents a value produced by a 18197user-specified assembler instruction. It is used to represent an 'asm' 18198statement with arguments. An 'asm' statement with a single output 18199operand, like this: 18200 18201 asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); 18202 18203is represented using a single 'asm_operands' RTX which represents the 18204value that is stored in 'outputvar': 18205 18206 (set RTX-FOR-OUTPUTVAR 18207 (asm_operands "foo %1,%2,%0" "a" 0 18208 [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] 18209 [(asm_input:M1 "g") 18210 (asm_input:M2 "di")])) 18211 18212Here the operands of the 'asm_operands' RTX are the assembler template 18213string, the output-operand's constraint, the index-number of the output 18214operand among the output operands specified, a vector of input operand 18215RTX's, and a vector of input-operand modes and constraints. The mode M1 18216is the mode of the sum 'x+y'; M2 is that of '*z'. 18217 18218 When an 'asm' statement has multiple output values, its insn has 18219several such 'set' RTX's inside of a 'parallel'. Each 'set' contains an 18220'asm_operands'; all of these share the same assembler template and 18221vectors, but each contains the constraint for the respective output 18222operand. They are also distinguished by the output-operand index 18223number, which is 0, 1, ... for successive output operands. 18224 18225 18226File: gccint.info, Node: Debug Information, Next: Insns, Prev: Assembler, Up: RTL 18227 1822814.18 Variable Location Debug Information in RTL 18229================================================ 18230 18231Variable tracking relies on 'MEM_EXPR' and 'REG_EXPR' annotations to 18232determine what user variables memory and register references refer to. 18233 18234 Variable tracking at assignments uses these notes only when they refer 18235to variables that live at fixed locations (e.g., addressable variables, 18236global non-automatic variables). For variables whose location may vary, 18237it relies on the following types of notes. 18238 18239'(var_location:MODE VAR EXP STAT)' 18240 Binds variable 'var', a tree, to value EXP, an RTL expression. It 18241 appears only in 'NOTE_INSN_VAR_LOCATION' and 'DEBUG_INSN's, with 18242 slightly different meanings. MODE, if present, represents the mode 18243 of EXP, which is useful if it is a modeless expression. STAT is 18244 only meaningful in notes, indicating whether the variable is known 18245 to be initialized or uninitialized. 18246 18247'(debug_expr:MODE DECL)' 18248 Stands for the value bound to the 'DEBUG_EXPR_DECL' DECL, that 18249 points back to it, within value expressions in 'VAR_LOCATION' 18250 nodes. 18251 18252'(debug_implicit_ptr:MODE DECL)' 18253 Stands for the location of a DECL that is no longer addressable. 18254 18255'(entry_value:MODE DECL)' 18256 Stands for the value a DECL had at the entry point of the 18257 containing function. 18258 18259'(debug_parameter_ref:MODE DECL)' 18260 Refers to a parameter that was completely optimized out. 18261 18262'(debug_marker:MODE)' 18263 Marks a program location. With 'VOIDmode', it stands for the 18264 beginning of a statement, a recommended inspection point logically 18265 after all prior side effects, and before any subsequent side 18266 effects. With 'BLKmode', it indicates an inline entry point: the 18267 lexical block encoded in the 'INSN_LOCATION' is the enclosing block 18268 that encloses the inlined function. 18269 18270 18271File: gccint.info, Node: Insns, Next: Calls, Prev: Debug Information, Up: RTL 18272 1827314.19 Insns 18274=========== 18275 18276The RTL representation of the code for a function is a doubly-linked 18277chain of objects called "insns". Insns are expressions with special 18278codes that are used for no other purpose. Some insns are actual 18279instructions; others represent dispatch tables for 'switch' statements; 18280others represent labels to jump to or various sorts of declarative 18281information. 18282 18283 In addition to its own specific data, each insn must have a unique 18284id-number that distinguishes it from all other insns in the current 18285function (after delayed branch scheduling, copies of an insn with the 18286same id-number may be present in multiple places in a function, but 18287these copies will always be identical and will only appear inside a 18288'sequence'), and chain pointers to the preceding and following insns. 18289These three fields occupy the same position in every insn, independent 18290of the expression code of the insn. They could be accessed with 'XEXP' 18291and 'XINT', but instead three special macros are always used: 18292 18293'INSN_UID (I)' 18294 Accesses the unique id of insn I. 18295 18296'PREV_INSN (I)' 18297 Accesses the chain pointer to the insn preceding I. If I is the 18298 first insn, this is a null pointer. 18299 18300'NEXT_INSN (I)' 18301 Accesses the chain pointer to the insn following I. If I is the 18302 last insn, this is a null pointer. 18303 18304 The first insn in the chain is obtained by calling 'get_insns'; the 18305last insn is the result of calling 'get_last_insn'. Within the chain 18306delimited by these insns, the 'NEXT_INSN' and 'PREV_INSN' pointers must 18307always correspond: if INSN is not the first insn, 18308 18309 NEXT_INSN (PREV_INSN (INSN)) == INSN 18310 18311is always true and if INSN is not the last insn, 18312 18313 PREV_INSN (NEXT_INSN (INSN)) == INSN 18314 18315is always true. 18316 18317 After delay slot scheduling, some of the insns in the chain might be 18318'sequence' expressions, which contain a vector of insns. The value of 18319'NEXT_INSN' in all but the last of these insns is the next insn in the 18320vector; the value of 'NEXT_INSN' of the last insn in the vector is the 18321same as the value of 'NEXT_INSN' for the 'sequence' in which it is 18322contained. Similar rules apply for 'PREV_INSN'. 18323 18324 This means that the above invariants are not necessarily true for insns 18325inside 'sequence' expressions. Specifically, if INSN is the first insn 18326in a 'sequence', 'NEXT_INSN (PREV_INSN (INSN))' is the insn containing 18327the 'sequence' expression, as is the value of 'PREV_INSN (NEXT_INSN 18328(INSN))' if INSN is the last insn in the 'sequence' expression. You can 18329use these expressions to find the containing 'sequence' expression. 18330 18331 Every insn has one of the following expression codes: 18332 18333'insn' 18334 The expression code 'insn' is used for instructions that do not 18335 jump and do not do function calls. 'sequence' expressions are 18336 always contained in insns with code 'insn' even if one of those 18337 insns should jump or do function calls. 18338 18339 Insns with code 'insn' have four additional fields beyond the three 18340 mandatory ones listed above. These four are described in a table 18341 below. 18342 18343'jump_insn' 18344 The expression code 'jump_insn' is used for instructions that may 18345 jump (or, more generally, may contain 'label_ref' expressions to 18346 which 'pc' can be set in that instruction). If there is an 18347 instruction to return from the current function, it is recorded as 18348 a 'jump_insn'. 18349 18350 'jump_insn' insns have the same extra fields as 'insn' insns, 18351 accessed in the same way and in addition contain a field 18352 'JUMP_LABEL' which is defined once jump optimization has completed. 18353 18354 For simple conditional and unconditional jumps, this field contains 18355 the 'code_label' to which this insn will (possibly conditionally) 18356 branch. In a more complex jump, 'JUMP_LABEL' records one of the 18357 labels that the insn refers to; other jump target labels are 18358 recorded as 'REG_LABEL_TARGET' notes. The exception is 'addr_vec' 18359 and 'addr_diff_vec', where 'JUMP_LABEL' is 'NULL_RTX' and the only 18360 way to find the labels is to scan the entire body of the insn. 18361 18362 Return insns count as jumps, but their 'JUMP_LABEL' is 'RETURN' or 18363 'SIMPLE_RETURN'. 18364 18365'call_insn' 18366 The expression code 'call_insn' is used for instructions that may 18367 do function calls. It is important to distinguish these 18368 instructions because they imply that certain registers and memory 18369 locations may be altered unpredictably. 18370 18371 'call_insn' insns have the same extra fields as 'insn' insns, 18372 accessed in the same way and in addition contain a field 18373 'CALL_INSN_FUNCTION_USAGE', which contains a list (chain of 18374 'expr_list' expressions) containing 'use', 'clobber' and sometimes 18375 'set' expressions that denote hard registers and 'mem's used or 18376 clobbered by the called function. 18377 18378 A 'mem' generally points to a stack slot in which arguments passed 18379 to the libcall by reference (*note TARGET_PASS_BY_REFERENCE: 18380 Register Arguments.) are stored. If the argument is caller-copied 18381 (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot 18382 will be mentioned in 'clobber' and 'use' entries; if it's 18383 callee-copied, only a 'use' will appear, and the 'mem' may point to 18384 addresses that are not stack slots. 18385 18386 Registers occurring inside a 'clobber' in this list augment 18387 registers specified in 'CALL_USED_REGISTERS' (*note Register 18388 Basics::). 18389 18390 If the list contains a 'set' involving two registers, it indicates 18391 that the function returns one of its arguments. Such a 'set' may 18392 look like a no-op if the same register holds the argument and the 18393 return value. 18394 18395'code_label' 18396 A 'code_label' insn represents a label that a jump insn can jump 18397 to. It contains two special fields of data in addition to the 18398 three standard ones. 'CODE_LABEL_NUMBER' is used to hold the 18399 "label number", a number that identifies this label uniquely among 18400 all the labels in the compilation (not just in the current 18401 function). Ultimately, the label is represented in the assembler 18402 output as an assembler label, usually of the form 'LN' where N is 18403 the label number. 18404 18405 When a 'code_label' appears in an RTL expression, it normally 18406 appears within a 'label_ref' which represents the address of the 18407 label, as a number. 18408 18409 Besides as a 'code_label', a label can also be represented as a 18410 'note' of type 'NOTE_INSN_DELETED_LABEL'. 18411 18412 The field 'LABEL_NUSES' is only defined once the jump optimization 18413 phase is completed. It contains the number of times this label is 18414 referenced in the current function. 18415 18416 The field 'LABEL_KIND' differentiates four different types of 18417 labels: 'LABEL_NORMAL', 'LABEL_STATIC_ENTRY', 'LABEL_GLOBAL_ENTRY', 18418 and 'LABEL_WEAK_ENTRY'. The only labels that do not have type 18419 'LABEL_NORMAL' are "alternate entry points" to the current 18420 function. These may be static (visible only in the containing 18421 translation unit), global (exposed to all translation units), or 18422 weak (global, but can be overridden by another symbol with the same 18423 name). 18424 18425 Much of the compiler treats all four kinds of label identically. 18426 Some of it needs to know whether or not a label is an alternate 18427 entry point; for this purpose, the macro 'LABEL_ALT_ENTRY_P' is 18428 provided. It is equivalent to testing whether 'LABEL_KIND (label) 18429 == LABEL_NORMAL'. The only place that cares about the distinction 18430 between static, global, and weak alternate entry points, besides 18431 the front-end code that creates them, is the function 18432 'output_alternate_entry_point', in 'final.c'. 18433 18434 To set the kind of a label, use the 'SET_LABEL_KIND' macro. 18435 18436'jump_table_data' 18437 A 'jump_table_data' insn is a placeholder for the jump-table data 18438 of a 'casesi' or 'tablejump' insn. They are placed after a 18439 'tablejump_p' insn. A 'jump_table_data' insn is not part o a basic 18440 blockm but it is associated with the basic block that ends with the 18441 'tablejump_p' insn. The 'PATTERN' of a 'jump_table_data' is always 18442 either an 'addr_vec' or an 'addr_diff_vec', and a 'jump_table_data' 18443 insn is always preceded by a 'code_label'. The 'tablejump_p' insn 18444 refers to that 'code_label' via its 'JUMP_LABEL'. 18445 18446'barrier' 18447 Barriers are placed in the instruction stream when control cannot 18448 flow past them. They are placed after unconditional jump 18449 instructions to indicate that the jumps are unconditional and after 18450 calls to 'volatile' functions, which do not return (e.g., 'exit'). 18451 They contain no information beyond the three standard fields. 18452 18453'note' 18454 'note' insns are used to represent additional debugging and 18455 declarative information. They contain two nonstandard fields, an 18456 integer which is accessed with the macro 'NOTE_LINE_NUMBER' and a 18457 string accessed with 'NOTE_SOURCE_FILE'. 18458 18459 If 'NOTE_LINE_NUMBER' is positive, the note represents the position 18460 of a source line and 'NOTE_SOURCE_FILE' is the source file name 18461 that the line came from. These notes control generation of line 18462 number data in the assembler output. 18463 18464 Otherwise, 'NOTE_LINE_NUMBER' is not really a line number but a 18465 code with one of the following values (and 'NOTE_SOURCE_FILE' must 18466 contain a null pointer): 18467 18468 'NOTE_INSN_DELETED' 18469 Such a note is completely ignorable. Some passes of the 18470 compiler delete insns by altering them into notes of this 18471 kind. 18472 18473 'NOTE_INSN_DELETED_LABEL' 18474 This marks what used to be a 'code_label', but was not used 18475 for other purposes than taking its address and was transformed 18476 to mark that no code jumps to it. 18477 18478 'NOTE_INSN_BLOCK_BEG' 18479 'NOTE_INSN_BLOCK_END' 18480 These types of notes indicate the position of the beginning 18481 and end of a level of scoping of variable names. They control 18482 the output of debugging information. 18483 18484 'NOTE_INSN_EH_REGION_BEG' 18485 'NOTE_INSN_EH_REGION_END' 18486 These types of notes indicate the position of the beginning 18487 and end of a level of scoping for exception handling. 18488 'NOTE_EH_HANDLER' identifies which region is associated with 18489 these notes. 18490 18491 'NOTE_INSN_FUNCTION_BEG' 18492 Appears at the start of the function body, after the function 18493 prologue. 18494 18495 'NOTE_INSN_VAR_LOCATION' 18496 This note is used to generate variable location debugging 18497 information. It indicates that the user variable in its 18498 'VAR_LOCATION' operand is at the location given in the RTL 18499 expression, or holds a value that can be computed by 18500 evaluating the RTL expression from that static point in the 18501 program up to the next such note for the same user variable. 18502 18503 'NOTE_INSN_BEGIN_STMT' 18504 This note is used to generate 'is_stmt' markers in line number 18505 debuggign information. It indicates the beginning of a user 18506 statement. 18507 18508 'NOTE_INSN_INLINE_ENTRY' 18509 This note is used to generate 'entry_pc' for inlined 18510 subroutines in debugging information. It indicates an 18511 inspection point at which all arguments for the inlined 18512 function have been bound, and before its first statement. 18513 18514 These codes are printed symbolically when they appear in debugging 18515 dumps. 18516 18517'debug_insn' 18518 The expression code 'debug_insn' is used for pseudo-instructions 18519 that hold debugging information for variable tracking at 18520 assignments (see '-fvar-tracking-assignments' option). They are 18521 the RTL representation of 'GIMPLE_DEBUG' statements (*note 18522 GIMPLE_DEBUG::), with a 'VAR_LOCATION' operand that binds a user 18523 variable tree to an RTL representation of the 'value' in the 18524 corresponding statement. A 'DEBUG_EXPR' in it stands for the value 18525 bound to the corresponding 'DEBUG_EXPR_DECL'. 18526 18527 'GIMPLE_DEBUG_BEGIN_STMT' and 'GIMPLE_DEBUG_INLINE_ENTRY' are 18528 expanded to RTL as a 'DEBUG_INSN' with a 'DEBUG_MARKER' 'PATTERN'; 18529 the difference is the RTL mode: the former's 'DEBUG_MARKER' is 18530 'VOIDmode', whereas the latter is 'BLKmode'; information about the 18531 inlined function can be taken from the lexical block encoded in the 18532 'INSN_LOCATION'. These 'DEBUG_INSN's, that do not carry 18533 'VAR_LOCATION' information, just 'DEBUG_MARKER's, can be detected 18534 by testing 'DEBUG_MARKER_INSN_P', whereas those that do can be 18535 recognized as 'DEBUG_BIND_INSN_P'. 18536 18537 Throughout optimization passes, 'DEBUG_INSN's are not reordered 18538 with respect to each other, particularly during scheduling. 18539 Binding information is kept in pseudo-instruction form, so that, 18540 unlike notes, it gets the same treatment and adjustments that 18541 regular instructions would. It is the variable tracking pass that 18542 turns these pseudo-instructions into 'NOTE_INSN_VAR_LOCATION', 18543 'NOTE_INSN_BEGIN_STMT' and 'NOTE_INSN_INLINE_ENTRY' notes, 18544 analyzing control flow, value equivalences and changes to registers 18545 and memory referenced in value expressions, propagating the values 18546 of debug temporaries and determining expressions that can be used 18547 to compute the value of each user variable at as many points 18548 (ranges, actually) in the program as possible. 18549 18550 Unlike 'NOTE_INSN_VAR_LOCATION', the value expression in an 18551 'INSN_VAR_LOCATION' denotes a value at that specific point in the 18552 program, rather than an expression that can be evaluated at any 18553 later point before an overriding 'VAR_LOCATION' is encountered. 18554 E.g., if a user variable is bound to a 'REG' and then a subsequent 18555 insn modifies the 'REG', the note location would keep mapping the 18556 user variable to the register across the insn, whereas the insn 18557 location would keep the variable bound to the value, so that the 18558 variable tracking pass would emit another location note for the 18559 variable at the point in which the register is modified. 18560 18561 The machine mode of an insn is normally 'VOIDmode', but some phases use 18562the mode for various purposes. 18563 18564 The common subexpression elimination pass sets the mode of an insn to 18565'QImode' when it is the first insn in a block that has already been 18566processed. 18567 18568 The second Haifa scheduling pass, for targets that can multiple issue, 18569sets the mode of an insn to 'TImode' when it is believed that the 18570instruction begins an issue group. That is, when the instruction cannot 18571issue simultaneously with the previous. This may be relied on by later 18572passes, in particular machine-dependent reorg. 18573 18574 Here is a table of the extra fields of 'insn', 'jump_insn' and 18575'call_insn' insns: 18576 18577'PATTERN (I)' 18578 An expression for the side effect performed by this insn. This 18579 must be one of the following codes: 'set', 'call', 'use', 18580 'clobber', 'return', 'simple_return', 'asm_input', 'asm_output', 18581 'addr_vec', 'addr_diff_vec', 'trap_if', 'unspec', 18582 'unspec_volatile', 'parallel', 'cond_exec', or 'sequence'. If it 18583 is a 'parallel', each element of the 'parallel' must be one these 18584 codes, except that 'parallel' expressions cannot be nested and 18585 'addr_vec' and 'addr_diff_vec' are not permitted inside a 18586 'parallel' expression. 18587 18588'INSN_CODE (I)' 18589 An integer that says which pattern in the machine description 18590 matches this insn, or -1 if the matching has not yet been 18591 attempted. 18592 18593 Such matching is never attempted and this field remains -1 on an 18594 insn whose pattern consists of a single 'use', 'clobber', 18595 'asm_input', 'addr_vec' or 'addr_diff_vec' expression. 18596 18597 Matching is also never attempted on insns that result from an 'asm' 18598 statement. These contain at least one 'asm_operands' expression. 18599 The function 'asm_noperands' returns a non-negative value for such 18600 insns. 18601 18602 In the debugging output, this field is printed as a number followed 18603 by a symbolic representation that locates the pattern in the 'md' 18604 file as some small positive or negative offset from a named 18605 pattern. 18606 18607'LOG_LINKS (I)' 18608 A list (chain of 'insn_list' expressions) giving information about 18609 dependencies between instructions within a basic block. Neither a 18610 jump nor a label may come between the related insns. These are 18611 only used by the schedulers and by combine. This is a deprecated 18612 data structure. Def-use and use-def chains are now preferred. 18613 18614'REG_NOTES (I)' 18615 A list (chain of 'expr_list', 'insn_list' and 'int_list' 18616 expressions) giving miscellaneous information about the insn. It 18617 is often information pertaining to the registers used in this insn. 18618 18619 The 'LOG_LINKS' field of an insn is a chain of 'insn_list' expressions. 18620Each of these has two operands: the first is an insn, and the second is 18621another 'insn_list' expression (the next one in the chain). The last 18622'insn_list' in the chain has a null pointer as second operand. The 18623significant thing about the chain is which insns appear in it (as first 18624operands of 'insn_list' expressions). Their order is not significant. 18625 18626 This list is originally set up by the flow analysis pass; it is a null 18627pointer until then. Flow only adds links for those data dependencies 18628which can be used for instruction combination. For each insn, the flow 18629analysis pass adds a link to insns which store into registers values 18630that are used for the first time in this insn. 18631 18632 The 'REG_NOTES' field of an insn is a chain similar to the 'LOG_LINKS' 18633field but it includes 'expr_list' and 'int_list' expressions in addition 18634to 'insn_list' expressions. There are several kinds of register notes, 18635which are distinguished by the machine mode, which in a register note is 18636really understood as being an 'enum reg_note'. The first operand OP of 18637the note is data whose meaning depends on the kind of note. 18638 18639 The macro 'REG_NOTE_KIND (X)' returns the kind of register note. Its 18640counterpart, the macro 'PUT_REG_NOTE_KIND (X, NEWKIND)' sets the 18641register note type of X to be NEWKIND. 18642 18643 Register notes are of three classes: They may say something about an 18644input to an insn, they may say something about an output of an insn, or 18645they may create a linkage between two insns. There are also a set of 18646values that are only used in 'LOG_LINKS'. 18647 18648 These register notes annotate inputs to an insn: 18649 18650'REG_DEAD' 18651 The value in OP dies in this insn; that is to say, altering the 18652 value immediately after this insn would not affect the future 18653 behavior of the program. 18654 18655 It does not follow that the register OP has no useful value after 18656 this insn since OP is not necessarily modified by this insn. 18657 Rather, no subsequent instruction uses the contents of OP. 18658 18659'REG_UNUSED' 18660 The register OP being set by this insn will not be used in a 18661 subsequent insn. This differs from a 'REG_DEAD' note, which 18662 indicates that the value in an input will not be used subsequently. 18663 These two notes are independent; both may be present for the same 18664 register. 18665 18666'REG_INC' 18667 The register OP is incremented (or decremented; at this level there 18668 is no distinction) by an embedded side effect inside this insn. 18669 This means it appears in a 'post_inc', 'pre_inc', 'post_dec' or 18670 'pre_dec' expression. 18671 18672'REG_NONNEG' 18673 The register OP is known to have a nonnegative value when this insn 18674 is reached. This is used so that decrement and branch until zero 18675 instructions, such as the m68k dbra, can be matched. 18676 18677 The 'REG_NONNEG' note is added to insns only if the machine 18678 description has a 'decrement_and_branch_until_zero' pattern. 18679 18680'REG_LABEL_OPERAND' 18681 This insn uses OP, a 'code_label' or a 'note' of type 18682 'NOTE_INSN_DELETED_LABEL', but is not a 'jump_insn', or it is a 18683 'jump_insn' that refers to the operand as an ordinary operand. The 18684 label may still eventually be a jump target, but if so in an 18685 indirect jump in a subsequent insn. The presence of this note 18686 allows jump optimization to be aware that OP is, in fact, being 18687 used, and flow optimization to build an accurate flow graph. 18688 18689'REG_LABEL_TARGET' 18690 This insn is a 'jump_insn' but not an 'addr_vec' or 18691 'addr_diff_vec'. It uses OP, a 'code_label' as a direct or 18692 indirect jump target. Its purpose is similar to that of 18693 'REG_LABEL_OPERAND'. This note is only present if the insn has 18694 multiple targets; the last label in the insn (in the highest 18695 numbered insn-field) goes into the 'JUMP_LABEL' field and does not 18696 have a 'REG_LABEL_TARGET' note. *Note JUMP_LABEL: Insns. 18697 18698'REG_SETJMP' 18699 Appears attached to each 'CALL_INSN' to 'setjmp' or a related 18700 function. 18701 18702 The following notes describe attributes of outputs of an insn: 18703 18704'REG_EQUIV' 18705'REG_EQUAL' 18706 This note is only valid on an insn that sets only one register and 18707 indicates that that register will be equal to OP at run time; the 18708 scope of this equivalence differs between the two types of notes. 18709 The value which the insn explicitly copies into the register may 18710 look different from OP, but they will be equal at run time. If the 18711 output of the single 'set' is a 'strict_low_part' or 'zero_extract' 18712 expression, the note refers to the register that is contained in 18713 its first operand. 18714 18715 For 'REG_EQUIV', the register is equivalent to OP throughout the 18716 entire function, and could validly be replaced in all its 18717 occurrences by OP. ("Validly" here refers to the data flow of the 18718 program; simple replacement may make some insns invalid.) For 18719 example, when a constant is loaded into a register that is never 18720 assigned any other value, this kind of note is used. 18721 18722 When a parameter is copied into a pseudo-register at entry to a 18723 function, a note of this kind records that the register is 18724 equivalent to the stack slot where the parameter was passed. 18725 Although in this case the register may be set by other insns, it is 18726 still valid to replace the register by the stack slot throughout 18727 the function. 18728 18729 A 'REG_EQUIV' note is also used on an instruction which copies a 18730 register parameter into a pseudo-register at entry to a function, 18731 if there is a stack slot where that parameter could be stored. 18732 Although other insns may set the pseudo-register, it is valid for 18733 the compiler to replace the pseudo-register by stack slot 18734 throughout the function, provided the compiler ensures that the 18735 stack slot is properly initialized by making the replacement in the 18736 initial copy instruction as well. This is used on machines for 18737 which the calling convention allocates stack space for register 18738 parameters. See 'REG_PARM_STACK_SPACE' in *note Stack Arguments::. 18739 18740 In the case of 'REG_EQUAL', the register that is set by this insn 18741 will be equal to OP at run time at the end of this insn but not 18742 necessarily elsewhere in the function. In this case, OP is 18743 typically an arithmetic expression. For example, when a sequence 18744 of insns such as a library call is used to perform an arithmetic 18745 operation, this kind of note is attached to the insn that produces 18746 or copies the final value. 18747 18748 These two notes are used in different ways by the compiler passes. 18749 'REG_EQUAL' is used by passes prior to register allocation (such as 18750 common subexpression elimination and loop optimization) to tell 18751 them how to think of that value. 'REG_EQUIV' notes are used by 18752 register allocation to indicate that there is an available 18753 substitute expression (either a constant or a 'mem' expression for 18754 the location of a parameter on the stack) that may be used in place 18755 of a register if insufficient registers are available. 18756 18757 Except for stack homes for parameters, which are indicated by a 18758 'REG_EQUIV' note and are not useful to the early optimization 18759 passes and pseudo registers that are equivalent to a memory 18760 location throughout their entire life, which is not detected until 18761 later in the compilation, all equivalences are initially indicated 18762 by an attached 'REG_EQUAL' note. In the early stages of register 18763 allocation, a 'REG_EQUAL' note is changed into a 'REG_EQUIV' note 18764 if OP is a constant and the insn represents the only set of its 18765 destination register. 18766 18767 Thus, compiler passes prior to register allocation need only check 18768 for 'REG_EQUAL' notes and passes subsequent to register allocation 18769 need only check for 'REG_EQUIV' notes. 18770 18771 These notes describe linkages between insns. They occur in pairs: one 18772insn has one of a pair of notes that points to a second insn, which has 18773the inverse note pointing back to the first insn. 18774 18775'REG_CC_SETTER' 18776'REG_CC_USER' 18777 On machines that use 'cc0', the insns which set and use 'cc0' set 18778 and use 'cc0' are adjacent. However, when branch delay slot 18779 filling is done, this may no longer be true. In this case a 18780 'REG_CC_USER' note will be placed on the insn setting 'cc0' to 18781 point to the insn using 'cc0' and a 'REG_CC_SETTER' note will be 18782 placed on the insn using 'cc0' to point to the insn setting 'cc0'. 18783 18784 These values are only used in the 'LOG_LINKS' field, and indicate the 18785type of dependency that each link represents. Links which indicate a 18786data dependence (a read after write dependence) do not use any code, 18787they simply have mode 'VOIDmode', and are printed without any 18788descriptive text. 18789 18790'REG_DEP_TRUE' 18791 This indicates a true dependence (a read after write dependence). 18792 18793'REG_DEP_OUTPUT' 18794 This indicates an output dependence (a write after write 18795 dependence). 18796 18797'REG_DEP_ANTI' 18798 This indicates an anti dependence (a write after read dependence). 18799 18800 These notes describe information gathered from gcov profile data. They 18801are stored in the 'REG_NOTES' field of an insn. 18802 18803'REG_BR_PROB' 18804 This is used to specify the ratio of branches to non-branches of a 18805 branch insn according to the profile data. The note is represented 18806 as an 'int_list' expression whose integer value is an encoding of 18807 'profile_probability' type. 'profile_probability' provide member 18808 function 'from_reg_br_prob_note' and 'to_reg_br_prob_note' to 18809 extract and store the probability into the RTL encoding. 18810 18811'REG_BR_PRED' 18812 These notes are found in JUMP insns after delayed branch scheduling 18813 has taken place. They indicate both the direction and the 18814 likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_* 18815 values. 18816 18817'REG_FRAME_RELATED_EXPR' 18818 This is used on an RTX_FRAME_RELATED_P insn wherein the attached 18819 expression is used in place of the actual insn pattern. This is 18820 done in cases where the pattern is either complex or misleading. 18821 18822 The note 'REG_CALL_NOCF_CHECK' is used in conjunction with the 18823'-fcf-protection=branch' option. The note is set if a 'nocf_check' 18824attribute is specified for a function type or a pointer to function 18825type. The note is stored in the 'REG_NOTES' field of an insn. 18826 18827'REG_CALL_NOCF_CHECK' 18828 Users have control through the 'nocf_check' attribute to identify 18829 which calls to a function should be skipped from control-flow 18830 instrumentation when the option '-fcf-protection=branch' is 18831 specified. The compiler puts a 'REG_CALL_NOCF_CHECK' note on each 18832 'CALL_INSN' instruction that has a function type marked with a 18833 'nocf_check' attribute. 18834 18835 For convenience, the machine mode in an 'insn_list' or 'expr_list' is 18836printed using these symbolic codes in debugging dumps. 18837 18838 The only difference between the expression codes 'insn_list' and 18839'expr_list' is that the first operand of an 'insn_list' is assumed to be 18840an insn and is printed in debugging dumps as the insn's unique id; the 18841first operand of an 'expr_list' is printed in the ordinary way as an 18842expression. 18843 18844 18845File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL 18846 1884714.20 RTL Representation of Function-Call Insns 18848=============================================== 18849 18850Insns that call subroutines have the RTL expression code 'call_insn'. 18851These insns must satisfy special rules, and their bodies must use a 18852special RTL expression code, 'call'. 18853 18854 A 'call' expression has two operands, as follows: 18855 18856 (call (mem:FM ADDR) NBYTES) 18857 18858Here NBYTES is an operand that represents the number of bytes of 18859argument data being passed to the subroutine, FM is a machine mode 18860(which must equal as the definition of the 'FUNCTION_MODE' macro in the 18861machine description) and ADDR represents the address of the subroutine. 18862 18863 For a subroutine that returns no value, the 'call' expression as shown 18864above is the entire body of the insn, except that the insn might also 18865contain 'use' or 'clobber' expressions. 18866 18867 For a subroutine that returns a value whose mode is not 'BLKmode', the 18868value is returned in a hard register. If this register's number is R, 18869then the body of the call insn looks like this: 18870 18871 (set (reg:M R) 18872 (call (mem:FM ADDR) NBYTES)) 18873 18874This RTL expression makes it clear (to the optimizer passes) that the 18875appropriate register receives a useful value in this insn. 18876 18877 When a subroutine returns a 'BLKmode' value, it is handled by passing 18878to the subroutine the address of a place to store the value. So the 18879call insn itself does not "return" any value, and it has the same RTL 18880form as a call that returns nothing. 18881 18882 On some machines, the call instruction itself clobbers some register, 18883for example to contain the return address. 'call_insn' insns on these 18884machines should have a body which is a 'parallel' that contains both the 18885'call' expression and 'clobber' expressions that indicate which 18886registers are destroyed. Similarly, if the call instruction requires 18887some register other than the stack pointer that is not explicitly 18888mentioned in its RTL, a 'use' subexpression should mention that 18889register. 18890 18891 Functions that are called are assumed to modify all registers listed in 18892the configuration macro 'CALL_USED_REGISTERS' (*note Register Basics::) 18893and, with the exception of 'const' functions and library calls, to 18894modify all of memory. 18895 18896 Insns containing just 'use' expressions directly precede the 18897'call_insn' insn to indicate which registers contain inputs to the 18898function. Similarly, if registers other than those in 18899'CALL_USED_REGISTERS' are clobbered by the called function, insns 18900containing a single 'clobber' follow immediately after the call to 18901indicate which registers. 18902 18903 18904File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL 18905 1890614.21 Structure Sharing Assumptions 18907=================================== 18908 18909The compiler assumes that certain kinds of RTL expressions are unique; 18910there do not exist two distinct objects representing the same value. In 18911other cases, it makes an opposite assumption: that no RTL expression 18912object of a certain kind appears in more than one place in the 18913containing structure. 18914 18915 These assumptions refer to a single function; except for the RTL 18916objects that describe global variables and external functions, and a few 18917standard objects such as small integer constants, no RTL objects are 18918common to two functions. 18919 18920 * Each pseudo-register has only a single 'reg' object to represent 18921 it, and therefore only a single machine mode. 18922 18923 * For any symbolic label, there is only one 'symbol_ref' object 18924 referring to it. 18925 18926 * All 'const_int' expressions with equal values are shared. 18927 18928 * All 'const_poly_int' expressions with equal modes and values are 18929 shared. 18930 18931 * There is only one 'pc' expression. 18932 18933 * There is only one 'cc0' expression. 18934 18935 * There is only one 'const_double' expression with value 0 for each 18936 floating point mode. Likewise for values 1 and 2. 18937 18938 * There is only one 'const_vector' expression with value 0 for each 18939 vector mode, be it an integer or a double constant vector. 18940 18941 * No 'label_ref' or 'scratch' appears in more than one place in the 18942 RTL structure; in other words, it is safe to do a tree-walk of all 18943 the insns in the function and assume that each time a 'label_ref' 18944 or 'scratch' is seen it is distinct from all others that are seen. 18945 18946 * Only one 'mem' object is normally created for each static variable 18947 or stack slot, so these objects are frequently shared in all the 18948 places they appear. However, separate but equal objects for these 18949 variables are occasionally made. 18950 18951 * When a single 'asm' statement has multiple output operands, a 18952 distinct 'asm_operands' expression is made for each output operand. 18953 However, these all share the vector which contains the sequence of 18954 input operands. This sharing is used later on to test whether two 18955 'asm_operands' expressions come from the same statement, so all 18956 optimizations must carefully preserve the sharing if they copy the 18957 vector at all. 18958 18959 * No RTL object appears in more than one place in the RTL structure 18960 except as described above. Many passes of the compiler rely on 18961 this by assuming that they can modify RTL objects in place without 18962 unwanted side-effects on other insns. 18963 18964 * During initial RTL generation, shared structure is freely 18965 introduced. After all the RTL for a function has been generated, 18966 all shared structure is copied by 'unshare_all_rtl' in 18967 'emit-rtl.c', after which the above rules are guaranteed to be 18968 followed. 18969 18970 * During the combiner pass, shared structure within an insn can exist 18971 temporarily. However, the shared structure is copied before the 18972 combiner is finished with the insn. This is done by calling 18973 'copy_rtx_if_shared', which is a subroutine of 'unshare_all_rtl'. 18974 18975 18976File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL 18977 1897814.22 Reading RTL 18979================= 18980 18981To read an RTL object from a file, call 'read_rtx'. It takes one 18982argument, a stdio stream, and returns a single RTL object. This routine 18983is defined in 'read-rtl.c'. It is not available in the compiler itself, 18984only the various programs that generate the compiler back end from the 18985machine description. 18986 18987 People frequently have the idea of using RTL stored as text in a file 18988as an interface between a language front end and the bulk of GCC. This 18989idea is not feasible. 18990 18991 GCC was designed to use RTL internally only. Correct RTL for a given 18992program is very dependent on the particular target machine. And the RTL 18993does not contain all the information about the program. 18994 18995 The proper way to interface GCC to a new language front end is with the 18996"tree" data structure, described in the files 'tree.h' and 'tree.def'. 18997The documentation for this structure (*note GENERIC::) is incomplete. 18998 18999 19000File: gccint.info, Node: Control Flow, Next: Loop Analysis and Representation, Prev: RTL, Up: Top 19001 1900215 Control Flow Graph 19003********************* 19004 19005A control flow graph (CFG) is a data structure built on top of the 19006intermediate code representation (the RTL or 'GIMPLE' instruction 19007stream) abstracting the control flow behavior of a function that is 19008being compiled. The CFG is a directed graph where the vertices 19009represent basic blocks and edges represent possible transfer of control 19010flow from one basic block to another. The data structures used to 19011represent the control flow graph are defined in 'basic-block.h'. 19012 19013 In GCC, the representation of control flow is maintained throughout the 19014compilation process, from constructing the CFG early in 'pass_build_cfg' 19015to 'pass_free_cfg' (see 'passes.def'). The CFG takes various different 19016modes and may undergo extensive manipulations, but the graph is always 19017valid between its construction and its release. This way, transfer of 19018information such as data flow, a measured profile, or the loop tree, can 19019be propagated through the passes pipeline, and even from 'GIMPLE' to 19020'RTL'. 19021 19022 Often the CFG may be better viewed as integral part of instruction 19023chain, than structure built on the top of it. Updating the compiler's 19024intermediate representation for instructions can not be easily done 19025without proper maintenance of the CFG simultaneously. 19026 19027* Menu: 19028 19029* Basic Blocks:: The definition and representation of basic blocks. 19030* Edges:: Types of edges and their representation. 19031* Profile information:: Representation of frequencies and probabilities. 19032* Maintaining the CFG:: Keeping the control flow graph and up to date. 19033* Liveness information:: Using and maintaining liveness information. 19034 19035 19036File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow 19037 1903815.1 Basic Blocks 19039================= 19040 19041A basic block is a straight-line sequence of code with only one entry 19042point and only one exit. In GCC, basic blocks are represented using the 19043'basic_block' data type. 19044 19045 Special basic blocks represent possible entry and exit points of a 19046function. These blocks are called 'ENTRY_BLOCK_PTR' and 19047'EXIT_BLOCK_PTR'. These blocks do not contain any code. 19048 19049 The 'BASIC_BLOCK' array contains all basic blocks in an unspecified 19050order. Each 'basic_block' structure has a field that holds a unique 19051integer identifier 'index' that is the index of the block in the 19052'BASIC_BLOCK' array. The total number of basic blocks in the function 19053is 'n_basic_blocks'. Both the basic block indices and the total number 19054of basic blocks may vary during the compilation process, as passes 19055reorder, create, duplicate, and destroy basic blocks. The index for any 19056block should never be greater than 'last_basic_block'. The indices 0 19057and 1 are special codes reserved for 'ENTRY_BLOCK' and 'EXIT_BLOCK', the 19058indices of 'ENTRY_BLOCK_PTR' and 'EXIT_BLOCK_PTR'. 19059 19060 Two pointer members of the 'basic_block' structure are the pointers 19061'next_bb' and 'prev_bb'. These are used to keep doubly linked chain of 19062basic blocks in the same order as the underlying instruction stream. 19063The chain of basic blocks is updated transparently by the provided API 19064for manipulating the CFG. The macro 'FOR_EACH_BB' can be used to visit 19065all the basic blocks in lexicographical order, except 'ENTRY_BLOCK' and 19066'EXIT_BLOCK'. The macro 'FOR_ALL_BB' also visits all basic blocks in 19067lexicographical order, including 'ENTRY_BLOCK' and 'EXIT_BLOCK'. 19068 19069 The functions 'post_order_compute' and 'inverted_post_order_compute' 19070can be used to compute topological orders of the CFG. The orders are 19071stored as vectors of basic block indices. The 'BASIC_BLOCK' array can 19072be used to iterate each basic block by index. Dominator traversals are 19073also possible using 'walk_dominator_tree'. Given two basic blocks A and 19074B, block A dominates block B if A is _always_ executed before B. 19075 19076 Each 'basic_block' also contains pointers to the first instruction (the 19077"head") and the last instruction (the "tail") or "end" of the 19078instruction stream contained in a basic block. In fact, since the 19079'basic_block' data type is used to represent blocks in both major 19080intermediate representations of GCC ('GIMPLE' and RTL), there are 19081pointers to the head and end of a basic block for both representations, 19082stored in intermediate representation specific data in the 'il' field of 19083'struct basic_block_def'. 19084 19085 For RTL, these pointers are 'BB_HEAD' and 'BB_END'. 19086 19087 In the RTL representation of a function, the instruction stream 19088contains not only the "real" instructions, but also "notes" or "insn 19089notes" (to distinguish them from "reg notes"). Any function that moves 19090or duplicates the basic blocks needs to take care of updating of these 19091notes. Many of these notes expect that the instruction stream consists 19092of linear regions, so updating can sometimes be tedious. All types of 19093insn notes are defined in 'insn-notes.def'. 19094 19095 In the RTL function representation, the instructions contained in a 19096basic block always follow a 'NOTE_INSN_BASIC_BLOCK', but zero or more 19097'CODE_LABEL' nodes can precede the block note. A basic block ends with 19098a control flow instruction or with the last instruction before the next 19099'CODE_LABEL' or 'NOTE_INSN_BASIC_BLOCK'. By definition, a 'CODE_LABEL' 19100cannot appear in the middle of the instruction stream of a basic block. 19101 19102 In addition to notes, the jump table vectors are also represented as 19103"pseudo-instructions" inside the insn stream. These vectors never 19104appear in the basic block and should always be placed just after the 19105table jump instructions referencing them. After removing the table-jump 19106it is often difficult to eliminate the code computing the address and 19107referencing the vector, so cleaning up these vectors is postponed until 19108after liveness analysis. Thus the jump table vectors may appear in the 19109insn stream unreferenced and without any purpose. Before any edge is 19110made "fall-thru", the existence of such construct in the way needs to be 19111checked by calling 'can_fallthru' function. 19112 19113 For the 'GIMPLE' representation, the PHI nodes and statements contained 19114in a basic block are in a 'gimple_seq' pointed to by the basic block 19115intermediate language specific pointers. Abstract containers and 19116iterators are used to access the PHI nodes and statements in a basic 19117blocks. These iterators are called "GIMPLE statement iterators" (GSIs). 19118Grep for '^gsi' in the various 'gimple-*' and 'tree-*' files. There is 19119a 'gimple_stmt_iterator' type for iterating over all kinds of statement, 19120and a 'gphi_iterator' subclass for iterating over PHI nodes. The 19121following snippet will pretty-print all PHI nodes the statements of the 19122current function in the GIMPLE representation. 19123 19124 basic_block bb; 19125 19126 FOR_EACH_BB (bb) 19127 { 19128 gphi_iterator pi; 19129 gimple_stmt_iterator si; 19130 19131 for (pi = gsi_start_phis (bb); !gsi_end_p (pi); gsi_next (&pi)) 19132 { 19133 gphi *phi = pi.phi (); 19134 print_gimple_stmt (dump_file, phi, 0, TDF_SLIM); 19135 } 19136 for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si)) 19137 { 19138 gimple stmt = gsi_stmt (si); 19139 print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM); 19140 } 19141 } 19142 19143 19144File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow 19145 1914615.2 Edges 19147========== 19148 19149Edges represent possible control flow transfers from the end of some 19150basic block A to the head of another basic block B. We say that A is a 19151predecessor of B, and B is a successor of A. Edges are represented in 19152GCC with the 'edge' data type. Each 'edge' acts as a link between two 19153basic blocks: The 'src' member of an edge points to the predecessor 19154basic block of the 'dest' basic block. The members 'preds' and 'succs' 19155of the 'basic_block' data type point to type-safe vectors of edges to 19156the predecessors and successors of the block. 19157 19158 When walking the edges in an edge vector, "edge iterators" should be 19159used. Edge iterators are constructed using the 'edge_iterator' data 19160structure and several methods are available to operate on them: 19161 19162'ei_start' 19163 This function initializes an 'edge_iterator' that points to the 19164 first edge in a vector of edges. 19165 19166'ei_last' 19167 This function initializes an 'edge_iterator' that points to the 19168 last edge in a vector of edges. 19169 19170'ei_end_p' 19171 This predicate is 'true' if an 'edge_iterator' represents the last 19172 edge in an edge vector. 19173 19174'ei_one_before_end_p' 19175 This predicate is 'true' if an 'edge_iterator' represents the 19176 second last edge in an edge vector. 19177 19178'ei_next' 19179 This function takes a pointer to an 'edge_iterator' and makes it 19180 point to the next edge in the sequence. 19181 19182'ei_prev' 19183 This function takes a pointer to an 'edge_iterator' and makes it 19184 point to the previous edge in the sequence. 19185 19186'ei_edge' 19187 This function returns the 'edge' currently pointed to by an 19188 'edge_iterator'. 19189 19190'ei_safe_safe' 19191 This function returns the 'edge' currently pointed to by an 19192 'edge_iterator', but returns 'NULL' if the iterator is pointing at 19193 the end of the sequence. This function has been provided for 19194 existing code makes the assumption that a 'NULL' edge indicates the 19195 end of the sequence. 19196 19197 The convenience macro 'FOR_EACH_EDGE' can be used to visit all of the 19198edges in a sequence of predecessor or successor edges. It must not be 19199used when an element might be removed during the traversal, otherwise 19200elements will be missed. Here is an example of how to use the macro: 19201 19202 edge e; 19203 edge_iterator ei; 19204 19205 FOR_EACH_EDGE (e, ei, bb->succs) 19206 { 19207 if (e->flags & EDGE_FALLTHRU) 19208 break; 19209 } 19210 19211 There are various reasons why control flow may transfer from one block 19212to another. One possibility is that some instruction, for example a 19213'CODE_LABEL', in a linearized instruction stream just always starts a 19214new basic block. In this case a "fall-thru" edge links the basic block 19215to the first following basic block. But there are several other reasons 19216why edges may be created. The 'flags' field of the 'edge' data type is 19217used to store information about the type of edge we are dealing with. 19218Each edge is of one of the following types: 19219 19220_jump_ 19221 No type flags are set for edges corresponding to jump instructions. 19222 These edges are used for unconditional or conditional jumps and in 19223 RTL also for table jumps. They are the easiest to manipulate as 19224 they may be freely redirected when the flow graph is not in SSA 19225 form. 19226 19227_fall-thru_ 19228 Fall-thru edges are present in case where the basic block may 19229 continue execution to the following one without branching. These 19230 edges have the 'EDGE_FALLTHRU' flag set. Unlike other types of 19231 edges, these edges must come into the basic block immediately 19232 following in the instruction stream. The function 19233 'force_nonfallthru' is available to insert an unconditional jump in 19234 the case that redirection is needed. Note that this may require 19235 creation of a new basic block. 19236 19237_exception handling_ 19238 Exception handling edges represent possible control transfers from 19239 a trapping instruction to an exception handler. The definition of 19240 "trapping" varies. In C++, only function calls can throw, but for 19241 Ada exceptions like division by zero or segmentation fault are 19242 defined and thus each instruction possibly throwing this kind of 19243 exception needs to be handled as control flow instruction. 19244 Exception edges have the 'EDGE_ABNORMAL' and 'EDGE_EH' flags set. 19245 19246 When updating the instruction stream it is easy to change possibly 19247 trapping instruction to non-trapping, by simply removing the 19248 exception edge. The opposite conversion is difficult, but should 19249 not happen anyway. The edges can be eliminated via 19250 'purge_dead_edges' call. 19251 19252 In the RTL representation, the destination of an exception edge is 19253 specified by 'REG_EH_REGION' note attached to the insn. In case of 19254 a trapping call the 'EDGE_ABNORMAL_CALL' flag is set too. In the 19255 'GIMPLE' representation, this extra flag is not set. 19256 19257 In the RTL representation, the predicate 'may_trap_p' may be used 19258 to check whether instruction still may trap or not. For the tree 19259 representation, the 'tree_could_trap_p' predicate is available, but 19260 this predicate only checks for possible memory traps, as in 19261 dereferencing an invalid pointer location. 19262 19263_sibling calls_ 19264 Sibling calls or tail calls terminate the function in a 19265 non-standard way and thus an edge to the exit must be present. 19266 'EDGE_SIBCALL' and 'EDGE_ABNORMAL' are set in such case. These 19267 edges only exist in the RTL representation. 19268 19269_computed jumps_ 19270 Computed jumps contain edges to all labels in the function 19271 referenced from the code. All those edges have 'EDGE_ABNORMAL' 19272 flag set. The edges used to represent computed jumps often cause 19273 compile time performance problems, since functions consisting of 19274 many taken labels and many computed jumps may have _very_ dense 19275 flow graphs, so these edges need to be handled with special care. 19276 During the earlier stages of the compilation process, GCC tries to 19277 avoid such dense flow graphs by factoring computed jumps. For 19278 example, given the following series of jumps, 19279 19280 goto *x; 19281 [ ... ] 19282 19283 goto *x; 19284 [ ... ] 19285 19286 goto *x; 19287 [ ... ] 19288 19289 factoring the computed jumps results in the following code sequence 19290 which has a much simpler flow graph: 19291 19292 goto y; 19293 [ ... ] 19294 19295 goto y; 19296 [ ... ] 19297 19298 goto y; 19299 [ ... ] 19300 19301 y: 19302 goto *x; 19303 19304 However, the classic problem with this transformation is that it 19305 has a runtime cost in there resulting code: An extra jump. 19306 Therefore, the computed jumps are un-factored in the later passes 19307 of the compiler (in the pass called 19308 'pass_duplicate_computed_gotos'). Be aware of that when you work 19309 on passes in that area. There have been numerous examples already 19310 where the compile time for code with unfactored computed jumps 19311 caused some serious headaches. 19312 19313_nonlocal goto handlers_ 19314 GCC allows nested functions to return into caller using a 'goto' to 19315 a label passed to as an argument to the callee. The labels passed 19316 to nested functions contain special code to cleanup after function 19317 call. Such sections of code are referred to as "nonlocal goto 19318 receivers". If a function contains such nonlocal goto receivers, 19319 an edge from the call to the label is created with the 19320 'EDGE_ABNORMAL' and 'EDGE_ABNORMAL_CALL' flags set. 19321 19322_function entry points_ 19323 By definition, execution of function starts at basic block 0, so 19324 there is always an edge from the 'ENTRY_BLOCK_PTR' to basic block 19325 0. There is no 'GIMPLE' representation for alternate entry points 19326 at this moment. In RTL, alternate entry points are specified by 19327 'CODE_LABEL' with 'LABEL_ALTERNATE_NAME' defined. This feature is 19328 currently used for multiple entry point prologues and is limited to 19329 post-reload passes only. This can be used by back-ends to emit 19330 alternate prologues for functions called from different contexts. 19331 In future full support for multiple entry functions defined by 19332 Fortran 90 needs to be implemented. 19333 19334_function exits_ 19335 In the pre-reload representation a function terminates after the 19336 last instruction in the insn chain and no explicit return 19337 instructions are used. This corresponds to the fall-thru edge into 19338 exit block. After reload, optimal RTL epilogues are used that use 19339 explicit (conditional) return instructions that are represented by 19340 edges with no flags set. 19341 19342 19343File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow 19344 1934515.3 Profile information 19346======================== 19347 19348In many cases a compiler must make a choice whether to trade speed in 19349one part of code for speed in another, or to trade code size for code 19350speed. In such cases it is useful to know information about how often 19351some given block will be executed. That is the purpose for maintaining 19352profile within the flow graph. GCC can handle profile information 19353obtained through "profile feedback", but it can also estimate branch 19354probabilities based on statics and heuristics. 19355 19356 The feedback based profile is produced by compiling the program with 19357instrumentation, executing it on a train run and reading the numbers of 19358executions of basic blocks and edges back to the compiler while 19359re-compiling the program to produce the final executable. This method 19360provides very accurate information about where a program spends most of 19361its time on the train run. Whether it matches the average run of course 19362depends on the choice of train data set, but several studies have shown 19363that the behavior of a program usually changes just marginally over 19364different data sets. 19365 19366 When profile feedback is not available, the compiler may be asked to 19367attempt to predict the behavior of each branch in the program using a 19368set of heuristics (see 'predict.def' for details) and compute estimated 19369frequencies of each basic block by propagating the probabilities over 19370the graph. 19371 19372 Each 'basic_block' contains two integer fields to represent profile 19373information: 'frequency' and 'count'. The 'frequency' is an estimation 19374how often is basic block executed within a function. It is represented 19375as an integer scaled in the range from 0 to 'BB_FREQ_BASE'. The most 19376frequently executed basic block in function is initially set to 19377'BB_FREQ_BASE' and the rest of frequencies are scaled accordingly. 19378During optimization, the frequency of the most frequent basic block can 19379both decrease (for instance by loop unrolling) or grow (for instance by 19380cross-jumping optimization), so scaling sometimes has to be performed 19381multiple times. 19382 19383 The 'count' contains hard-counted numbers of execution measured during 19384training runs and is nonzero only when profile feedback is available. 19385This value is represented as the host's widest integer (typically a 64 19386bit integer) of the special type 'gcov_type'. 19387 19388 Most optimization passes can use only the frequency information of a 19389basic block, but a few passes may want to know hard execution counts. 19390The frequencies should always match the counts after scaling, however 19391during updating of the profile information numerical error may 19392accumulate into quite large errors. 19393 19394 Each edge also contains a branch probability field: an integer in the 19395range from 0 to 'REG_BR_PROB_BASE'. It represents probability of 19396passing control from the end of the 'src' basic block to the 'dest' 19397basic block, i.e. the probability that control will flow along this 19398edge. The 'EDGE_FREQUENCY' macro is available to compute how frequently 19399a given edge is taken. There is a 'count' field for each edge as well, 19400representing same information as for a basic block. 19401 19402 The basic block frequencies are not represented in the instruction 19403stream, but in the RTL representation the edge frequencies are 19404represented for conditional jumps (via the 'REG_BR_PROB' macro) since 19405they are used when instructions are output to the assembly file and the 19406flow graph is no longer maintained. 19407 19408 The probability that control flow arrives via a given edge to its 19409destination basic block is called "reverse probability" and is not 19410directly represented, but it may be easily computed from frequencies of 19411basic blocks. 19412 19413 Updating profile information is a delicate task that can unfortunately 19414not be easily integrated with the CFG manipulation API. Many of the 19415functions and hooks to modify the CFG, such as 19416'redirect_edge_and_branch', do not have enough information to easily 19417update the profile, so updating it is in the majority of cases left up 19418to the caller. It is difficult to uncover bugs in the profile updating 19419code, because they manifest themselves only by producing worse code, and 19420checking profile consistency is not possible because of numeric error 19421accumulation. Hence special attention needs to be given to this issue 19422in each pass that modifies the CFG. 19423 19424 It is important to point out that 'REG_BR_PROB_BASE' and 'BB_FREQ_BASE' 19425are both set low enough to be possible to compute second power of any 19426frequency or probability in the flow graph, it is not possible to even 19427square the 'count' field, as modern CPUs are fast enough to execute 19428$2^32$ operations quickly. 19429 19430 19431File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow 19432 1943315.4 Maintaining the CFG 19434======================== 19435 19436An important task of each compiler pass is to keep both the control flow 19437graph and all profile information up-to-date. Reconstruction of the 19438control flow graph after each pass is not an option, since it may be 19439very expensive and lost profile information cannot be reconstructed at 19440all. 19441 19442 GCC has two major intermediate representations, and both use the 19443'basic_block' and 'edge' data types to represent control flow. Both 19444representations share as much of the CFG maintenance code as possible. 19445For each representation, a set of "hooks" is defined so that each 19446representation can provide its own implementation of CFG manipulation 19447routines when necessary. These hooks are defined in 'cfghooks.h'. 19448There are hooks for almost all common CFG manipulations, including block 19449splitting and merging, edge redirection and creating and deleting basic 19450blocks. These hooks should provide everything you need to maintain and 19451manipulate the CFG in both the RTL and 'GIMPLE' representation. 19452 19453 At the moment, the basic block boundaries are maintained transparently 19454when modifying instructions, so there rarely is a need to move them 19455manually (such as in case someone wants to output instruction outside 19456basic block explicitly). 19457 19458 In the RTL representation, each instruction has a 'BLOCK_FOR_INSN' 19459value that represents pointer to the basic block that contains the 19460instruction. In the 'GIMPLE' representation, the function 'gimple_bb' 19461returns a pointer to the basic block containing the queried statement. 19462 19463 When changes need to be applied to a function in its 'GIMPLE' 19464representation, "GIMPLE statement iterators" should be used. These 19465iterators provide an integrated abstraction of the flow graph and the 19466instruction stream. Block statement iterators are constructed using the 19467'gimple_stmt_iterator' data structure and several modifiers are 19468available, including the following: 19469 19470'gsi_start' 19471 This function initializes a 'gimple_stmt_iterator' that points to 19472 the first non-empty statement in a basic block. 19473 19474'gsi_last' 19475 This function initializes a 'gimple_stmt_iterator' that points to 19476 the last statement in a basic block. 19477 19478'gsi_end_p' 19479 This predicate is 'true' if a 'gimple_stmt_iterator' represents the 19480 end of a basic block. 19481 19482'gsi_next' 19483 This function takes a 'gimple_stmt_iterator' and makes it point to 19484 its successor. 19485 19486'gsi_prev' 19487 This function takes a 'gimple_stmt_iterator' and makes it point to 19488 its predecessor. 19489 19490'gsi_insert_after' 19491 This function inserts a statement after the 'gimple_stmt_iterator' 19492 passed in. The final parameter determines whether the statement 19493 iterator is updated to point to the newly inserted statement, or 19494 left pointing to the original statement. 19495 19496'gsi_insert_before' 19497 This function inserts a statement before the 'gimple_stmt_iterator' 19498 passed in. The final parameter determines whether the statement 19499 iterator is updated to point to the newly inserted statement, or 19500 left pointing to the original statement. 19501 19502'gsi_remove' 19503 This function removes the 'gimple_stmt_iterator' passed in and 19504 rechains the remaining statements in a basic block, if any. 19505 19506 In the RTL representation, the macros 'BB_HEAD' and 'BB_END' may be 19507used to get the head and end 'rtx' of a basic block. No abstract 19508iterators are defined for traversing the insn chain, but you can just 19509use 'NEXT_INSN' and 'PREV_INSN' instead. *Note Insns::. 19510 19511 Usually a code manipulating pass simplifies the instruction stream and 19512the flow of control, possibly eliminating some edges. This may for 19513example happen when a conditional jump is replaced with an unconditional 19514jump. Updating of edges is not transparent and each optimization pass 19515is required to do so manually. However only few cases occur in 19516practice. The pass may call 'purge_dead_edges' on a given basic block 19517to remove superfluous edges, if any. 19518 19519 Another common scenario is redirection of branch instructions, but this 19520is best modeled as redirection of edges in the control flow graph and 19521thus use of 'redirect_edge_and_branch' is preferred over more low level 19522functions, such as 'redirect_jump' that operate on RTL chain only. The 19523CFG hooks defined in 'cfghooks.h' should provide the complete API 19524required for manipulating and maintaining the CFG. 19525 19526 It is also possible that a pass has to insert control flow instruction 19527into the middle of a basic block, thus creating an entry point in the 19528middle of the basic block, which is impossible by definition: The block 19529must be split to make sure it only has one entry point, i.e. the head of 19530the basic block. The CFG hook 'split_block' may be used when an 19531instruction in the middle of a basic block has to become the target of a 19532jump or branch instruction. 19533 19534 For a global optimizer, a common operation is to split edges in the 19535flow graph and insert instructions on them. In the RTL representation, 19536this can be easily done using the 'insert_insn_on_edge' function that 19537emits an instruction "on the edge", caching it for a later 19538'commit_edge_insertions' call that will take care of moving the inserted 19539instructions off the edge into the instruction stream contained in a 19540basic block. This includes the creation of new basic blocks where 19541needed. In the 'GIMPLE' representation, the equivalent functions are 19542'gsi_insert_on_edge' which inserts a block statement iterator on an 19543edge, and 'gsi_commit_edge_inserts' which flushes the instruction to 19544actual instruction stream. 19545 19546 While debugging the optimization pass, the 'verify_flow_info' function 19547may be useful to find bugs in the control flow graph updating code. 19548 19549 19550File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow 19551 1955215.5 Liveness information 19553========================= 19554 19555Liveness information is useful to determine whether some register is 19556"live" at given point of program, i.e. that it contains a value that may 19557be used at a later point in the program. This information is used, for 19558instance, during register allocation, as the pseudo registers only need 19559to be assigned to a unique hard register or to a stack slot if they are 19560live. The hard registers and stack slots may be freely reused for other 19561values when a register is dead. 19562 19563 Liveness information is available in the back end starting with 19564'pass_df_initialize' and ending with 'pass_df_finish'. Three flavors of 19565live analysis are available: With 'LR', it is possible to determine at 19566any point 'P' in the function if the register may be used on some path 19567from 'P' to the end of the function. With 'UR', it is possible to 19568determine if there is a path from the beginning of the function to 'P' 19569that defines the variable. 'LIVE' is the intersection of the 'LR' and 19570'UR' and a variable is live at 'P' if there is both an assignment that 19571reaches it from the beginning of the function and a use that can be 19572reached on some path from 'P' to the end of the function. 19573 19574 In general 'LIVE' is the most useful of the three. The macros 19575'DF_[LR,UR,LIVE]_[IN,OUT]' can be used to access this information. The 19576macros take a basic block number and return a bitmap that is indexed by 19577the register number. This information is only guaranteed to be up to 19578date after calls are made to 'df_analyze'. See the file 'df-core.c' for 19579details on using the dataflow. 19580 19581 The liveness information is stored partly in the RTL instruction stream 19582and partly in the flow graph. Local information is stored in the 19583instruction stream: Each instruction may contain 'REG_DEAD' notes 19584representing that the value of a given register is no longer needed, or 19585'REG_UNUSED' notes representing that the value computed by the 19586instruction is never used. The second is useful for instructions 19587computing multiple values at once. 19588 19589 19590File: gccint.info, Node: Loop Analysis and Representation, Next: Machine Desc, Prev: Control Flow, Up: Top 19591 1959216 Analysis and Representation of Loops 19593*************************************** 19594 19595GCC provides extensive infrastructure for work with natural loops, i.e., 19596strongly connected components of CFG with only one entry block. This 19597chapter describes representation of loops in GCC, both on GIMPLE and in 19598RTL, as well as the interfaces to loop-related analyses (induction 19599variable analysis and number of iterations analysis). 19600 19601* Menu: 19602 19603* Loop representation:: Representation and analysis of loops. 19604* Loop querying:: Getting information about loops. 19605* Loop manipulation:: Loop manipulation functions. 19606* LCSSA:: Loop-closed SSA form. 19607* Scalar evolutions:: Induction variables on GIMPLE. 19608* loop-iv:: Induction variables on RTL. 19609* Number of iterations:: Number of iterations analysis. 19610* Dependency analysis:: Data dependency analysis. 19611 19612 19613File: gccint.info, Node: Loop representation, Next: Loop querying, Up: Loop Analysis and Representation 19614 1961516.1 Loop representation 19616======================== 19617 19618This chapter describes the representation of loops in GCC, and functions 19619that can be used to build, modify and analyze this representation. Most 19620of the interfaces and data structures are declared in 'cfgloop.h'. Loop 19621structures are analyzed and this information disposed or updated at the 19622discretion of individual passes. Still most of the generic CFG 19623manipulation routines are aware of loop structures and try to keep them 19624up-to-date. By this means an increasing part of the compilation 19625pipeline is setup to maintain loop structure across passes to allow 19626attaching meta information to individual loops for consumption by later 19627passes. 19628 19629 In general, a natural loop has one entry block (header) and possibly 19630several back edges (latches) leading to the header from the inside of 19631the loop. Loops with several latches may appear if several loops share 19632a single header, or if there is a branching in the middle of the loop. 19633The representation of loops in GCC however allows only loops with a 19634single latch. During loop analysis, headers of such loops are split and 19635forwarder blocks are created in order to disambiguate their structures. 19636Heuristic based on profile information and structure of the induction 19637variables in the loops is used to determine whether the latches 19638correspond to sub-loops or to control flow in a single loop. This means 19639that the analysis sometimes changes the CFG, and if you run it in the 19640middle of an optimization pass, you must be able to deal with the new 19641blocks. You may avoid CFG changes by passing 19642'LOOPS_MAY_HAVE_MULTIPLE_LATCHES' flag to the loop discovery, note 19643however that most other loop manipulation functions will not work 19644correctly for loops with multiple latch edges (the functions that only 19645query membership of blocks to loops and subloop relationships, or 19646enumerate and test loop exits, can be expected to work). 19647 19648 Body of the loop is the set of blocks that are dominated by its header, 19649and reachable from its latch against the direction of edges in CFG. The 19650loops are organized in a containment hierarchy (tree) such that all the 19651loops immediately contained inside loop L are the children of L in the 19652tree. This tree is represented by the 'struct loops' structure. The 19653root of this tree is a fake loop that contains all blocks in the 19654function. Each of the loops is represented in a 'struct loop' 19655structure. Each loop is assigned an index ('num' field of the 'struct 19656loop' structure), and the pointer to the loop is stored in the 19657corresponding field of the 'larray' vector in the loops structure. The 19658indices do not have to be continuous, there may be empty ('NULL') 19659entries in the 'larray' created by deleting loops. Also, there is no 19660guarantee on the relative order of a loop and its subloops in the 19661numbering. The index of a loop never changes. 19662 19663 The entries of the 'larray' field should not be accessed directly. The 19664function 'get_loop' returns the loop description for a loop with the 19665given index. 'number_of_loops' function returns number of loops in the 19666function. To traverse all loops, use 'FOR_EACH_LOOP' macro. The 19667'flags' argument of the macro is used to determine the direction of 19668traversal and the set of loops visited. Each loop is guaranteed to be 19669visited exactly once, regardless of the changes to the loop tree, and 19670the loops may be removed during the traversal. The newly created loops 19671are never traversed, if they need to be visited, this must be done 19672separately after their creation. The 'FOR_EACH_LOOP' macro allocates 19673temporary variables. If the 'FOR_EACH_LOOP' loop were ended using break 19674or goto, they would not be released; 'FOR_EACH_LOOP_BREAK' macro must be 19675used instead. 19676 19677 Each basic block contains the reference to the innermost loop it 19678belongs to ('loop_father'). For this reason, it is only possible to 19679have one 'struct loops' structure initialized at the same time for each 19680CFG. The global variable 'current_loops' contains the 'struct loops' 19681structure. Many of the loop manipulation functions assume that 19682dominance information is up-to-date. 19683 19684 The loops are analyzed through 'loop_optimizer_init' function. The 19685argument of this function is a set of flags represented in an integer 19686bitmask. These flags specify what other properties of the loop 19687structures should be calculated/enforced and preserved later: 19688 19689 * 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES': If this flag is set, no changes 19690 to CFG will be performed in the loop analysis, in particular, loops 19691 with multiple latch edges will not be disambiguated. If a loop has 19692 multiple latches, its latch block is set to NULL. Most of the loop 19693 manipulation functions will not work for loops in this shape. No 19694 other flags that require CFG changes can be passed to 19695 loop_optimizer_init. 19696 * 'LOOPS_HAVE_PREHEADERS': Forwarder blocks are created in such a way 19697 that each loop has only one entry edge, and additionally, the 19698 source block of this entry edge has only one successor. This 19699 creates a natural place where the code can be moved out of the 19700 loop, and ensures that the entry edge of the loop leads from its 19701 immediate super-loop. 19702 * 'LOOPS_HAVE_SIMPLE_LATCHES': Forwarder blocks are created to force 19703 the latch block of each loop to have only one successor. This 19704 ensures that the latch of the loop does not belong to any of its 19705 sub-loops, and makes manipulation with the loops significantly 19706 easier. Most of the loop manipulation functions assume that the 19707 loops are in this shape. Note that with this flag, the "normal" 19708 loop without any control flow inside and with one exit consists of 19709 two basic blocks. 19710 * 'LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS': Basic blocks and edges in 19711 the strongly connected components that are not natural loops (have 19712 more than one entry block) are marked with 'BB_IRREDUCIBLE_LOOP' 19713 and 'EDGE_IRREDUCIBLE_LOOP' flags. The flag is not set for blocks 19714 and edges that belong to natural loops that are in such an 19715 irreducible region (but it is set for the entry and exit edges of 19716 such a loop, if they lead to/from this region). 19717 * 'LOOPS_HAVE_RECORDED_EXITS': The lists of exits are recorded and 19718 updated for each loop. This makes some functions (e.g., 19719 'get_loop_exit_edges') more efficient. Some functions (e.g., 19720 'single_exit') can be used only if the lists of exits are recorded. 19721 19722 These properties may also be computed/enforced later, using functions 19723'create_preheaders', 'force_single_succ_latches', 19724'mark_irreducible_loops' and 'record_loop_exits'. The properties can be 19725queried using 'loops_state_satisfies_p'. 19726 19727 The memory occupied by the loops structures should be freed with 19728'loop_optimizer_finalize' function. When loop structures are setup to 19729be preserved across passes this function reduces the information to be 19730kept up-to-date to a minimum (only 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES' 19731set). 19732 19733 The CFG manipulation functions in general do not update loop 19734structures. Specialized versions that additionally do so are provided 19735for the most common tasks. On GIMPLE, 'cleanup_tree_cfg_loop' function 19736can be used to cleanup CFG while updating the loops structures if 19737'current_loops' is set. 19738 19739 At the moment loop structure is preserved from the start of GIMPLE loop 19740optimizations until the end of RTL loop optimizations. During this time 19741a loop can be tracked by its 'struct loop' and number. 19742 19743 19744File: gccint.info, Node: Loop querying, Next: Loop manipulation, Prev: Loop representation, Up: Loop Analysis and Representation 19745 1974616.2 Loop querying 19747================== 19748 19749The functions to query the information about loops are declared in 19750'cfgloop.h'. Some of the information can be taken directly from the 19751structures. 'loop_father' field of each basic block contains the 19752innermost loop to that the block belongs. The most useful fields of 19753loop structure (that are kept up-to-date at all times) are: 19754 19755 * 'header', 'latch': Header and latch basic blocks of the loop. 19756 * 'num_nodes': Number of basic blocks in the loop (including the 19757 basic blocks of the sub-loops). 19758 * 'outer', 'inner', 'next': The super-loop, the first sub-loop, and 19759 the sibling of the loop in the loops tree. 19760 19761 There are other fields in the loop structures, many of them used only 19762by some of the passes, or not updated during CFG changes; in general, 19763they should not be accessed directly. 19764 19765 The most important functions to query loop structures are: 19766 19767 * 'loop_depth': The depth of the loop in the loops tree, i.e., the 19768 number of super-loops of the loop. 19769 * 'flow_loops_dump': Dumps the information about loops to a file. 19770 * 'verify_loop_structure': Checks consistency of the loop structures. 19771 * 'loop_latch_edge': Returns the latch edge of a loop. 19772 * 'loop_preheader_edge': If loops have preheaders, returns the 19773 preheader edge of a loop. 19774 * 'flow_loop_nested_p': Tests whether loop is a sub-loop of another 19775 loop. 19776 * 'flow_bb_inside_loop_p': Tests whether a basic block belongs to a 19777 loop (including its sub-loops). 19778 * 'find_common_loop': Finds the common super-loop of two loops. 19779 * 'superloop_at_depth': Returns the super-loop of a loop with the 19780 given depth. 19781 * 'tree_num_loop_insns', 'num_loop_insns': Estimates the number of 19782 insns in the loop, on GIMPLE and on RTL. 19783 * 'loop_exit_edge_p': Tests whether edge is an exit from a loop. 19784 * 'mark_loop_exit_edges': Marks all exit edges of all loops with 19785 'EDGE_LOOP_EXIT' flag. 19786 * 'get_loop_body', 'get_loop_body_in_dom_order', 19787 'get_loop_body_in_bfs_order': Enumerates the basic blocks in the 19788 loop in depth-first search order in reversed CFG, ordered by 19789 dominance relation, and breath-first search order, respectively. 19790 * 'single_exit': Returns the single exit edge of the loop, or 'NULL' 19791 if the loop has more than one exit. You can only use this function 19792 if LOOPS_HAVE_MARKED_SINGLE_EXITS property is used. 19793 * 'get_loop_exit_edges': Enumerates the exit edges of a loop. 19794 * 'just_once_each_iteration_p': Returns true if the basic block is 19795 executed exactly once during each iteration of a loop (that is, it 19796 does not belong to a sub-loop, and it dominates the latch of the 19797 loop). 19798 19799 19800File: gccint.info, Node: Loop manipulation, Next: LCSSA, Prev: Loop querying, Up: Loop Analysis and Representation 19801 1980216.3 Loop manipulation 19803====================== 19804 19805The loops tree can be manipulated using the following functions: 19806 19807 * 'flow_loop_tree_node_add': Adds a node to the tree. 19808 * 'flow_loop_tree_node_remove': Removes a node from the tree. 19809 * 'add_bb_to_loop': Adds a basic block to a loop. 19810 * 'remove_bb_from_loops': Removes a basic block from loops. 19811 19812 Most low-level CFG functions update loops automatically. The following 19813functions handle some more complicated cases of CFG manipulations: 19814 19815 * 'remove_path': Removes an edge and all blocks it dominates. 19816 * 'split_loop_exit_edge': Splits exit edge of the loop, ensuring that 19817 PHI node arguments remain in the loop (this ensures that 19818 loop-closed SSA form is preserved). Only useful on GIMPLE. 19819 19820 Finally, there are some higher-level loop transformations implemented. 19821While some of them are written so that they should work on non-innermost 19822loops, they are mostly untested in that case, and at the moment, they 19823are only reliable for the innermost loops: 19824 19825 * 'create_iv': Creates a new induction variable. Only works on 19826 GIMPLE. 'standard_iv_increment_position' can be used to find a 19827 suitable place for the iv increment. 19828 * 'duplicate_loop_to_header_edge', 19829 'tree_duplicate_loop_to_header_edge': These functions (on RTL and 19830 on GIMPLE) duplicate the body of the loop prescribed number of 19831 times on one of the edges entering loop header, thus performing 19832 either loop unrolling or loop peeling. 'can_duplicate_loop_p' 19833 ('can_unroll_loop_p' on GIMPLE) must be true for the duplicated 19834 loop. 19835 * 'loop_version': This function creates a copy of a loop, and a 19836 branch before them that selects one of them depending on the 19837 prescribed condition. This is useful for optimizations that need 19838 to verify some assumptions in runtime (one of the copies of the 19839 loop is usually left unchanged, while the other one is transformed 19840 in some way). 19841 * 'tree_unroll_loop': Unrolls the loop, including peeling the extra 19842 iterations to make the number of iterations divisible by unroll 19843 factor, updating the exit condition, and removing the exits that 19844 now cannot be taken. Works only on GIMPLE. 19845 19846 19847File: gccint.info, Node: LCSSA, Next: Scalar evolutions, Prev: Loop manipulation, Up: Loop Analysis and Representation 19848 1984916.4 Loop-closed SSA form 19850========================= 19851 19852Throughout the loop optimizations on tree level, one extra condition is 19853enforced on the SSA form: No SSA name is used outside of the loop in 19854that it is defined. The SSA form satisfying this condition is called 19855"loop-closed SSA form" - LCSSA. To enforce LCSSA, PHI nodes must be 19856created at the exits of the loops for the SSA names that are used 19857outside of them. Only the real operands (not virtual SSA names) are 19858held in LCSSA, in order to save memory. 19859 19860 There are various benefits of LCSSA: 19861 19862 * Many optimizations (value range analysis, final value replacement) 19863 are interested in the values that are defined in the loop and used 19864 outside of it, i.e., exactly those for that we create new PHI 19865 nodes. 19866 * In induction variable analysis, it is not necessary to specify the 19867 loop in that the analysis should be performed - the scalar 19868 evolution analysis always returns the results with respect to the 19869 loop in that the SSA name is defined. 19870 * It makes updating of SSA form during loop transformations simpler. 19871 Without LCSSA, operations like loop unrolling may force creation of 19872 PHI nodes arbitrarily far from the loop, while in LCSSA, the SSA 19873 form can be updated locally. However, since we only keep real 19874 operands in LCSSA, we cannot use this advantage (we could have 19875 local updating of real operands, but it is not much more efficient 19876 than to use generic SSA form updating for it as well; the amount of 19877 changes to SSA is the same). 19878 19879 However, it also means LCSSA must be updated. This is usually 19880straightforward, unless you create a new value in loop and use it 19881outside, or unless you manipulate loop exit edges (functions are 19882provided to make these manipulations simple). 19883'rewrite_into_loop_closed_ssa' is used to rewrite SSA form to LCSSA, and 19884'verify_loop_closed_ssa' to check that the invariant of LCSSA is 19885preserved. 19886 19887 19888File: gccint.info, Node: Scalar evolutions, Next: loop-iv, Prev: LCSSA, Up: Loop Analysis and Representation 19889 1989016.5 Scalar evolutions 19891====================== 19892 19893Scalar evolutions (SCEV) are used to represent results of induction 19894variable analysis on GIMPLE. They enable us to represent variables with 19895complicated behavior in a simple and consistent way (we only use it to 19896express values of polynomial induction variables, but it is possible to 19897extend it). The interfaces to SCEV analysis are declared in 19898'tree-scalar-evolution.h'. To use scalar evolutions analysis, 19899'scev_initialize' must be used. To stop using SCEV, 'scev_finalize' 19900should be used. SCEV analysis caches results in order to save time and 19901memory. This cache however is made invalid by most of the loop 19902transformations, including removal of code. If such a transformation is 19903performed, 'scev_reset' must be called to clean the caches. 19904 19905 Given an SSA name, its behavior in loops can be analyzed using the 19906'analyze_scalar_evolution' function. The returned SCEV however does not 19907have to be fully analyzed and it may contain references to other SSA 19908names defined in the loop. To resolve these (potentially recursive) 19909references, 'instantiate_parameters' or 'resolve_mixers' functions must 19910be used. 'instantiate_parameters' is useful when you use the results of 19911SCEV only for some analysis, and when you work with whole nest of loops 19912at once. It will try replacing all SSA names by their SCEV in all 19913loops, including the super-loops of the current loop, thus providing a 19914complete information about the behavior of the variable in the loop 19915nest. 'resolve_mixers' is useful if you work with only one loop at a 19916time, and if you possibly need to create code based on the value of the 19917induction variable. It will only resolve the SSA names defined in the 19918current loop, leaving the SSA names defined outside unchanged, even if 19919their evolution in the outer loops is known. 19920 19921 The SCEV is a normal tree expression, except for the fact that it may 19922contain several special tree nodes. One of them is 'SCEV_NOT_KNOWN', 19923used for SSA names whose value cannot be expressed. The other one is 19924'POLYNOMIAL_CHREC'. Polynomial chrec has three arguments - base, step 19925and loop (both base and step may contain further polynomial chrecs). 19926Type of the expression and of base and step must be the same. A 19927variable has evolution 'POLYNOMIAL_CHREC(base, step, loop)' if it is (in 19928the specified loop) equivalent to 'x_1' in the following example 19929 19930 while (...) 19931 { 19932 x_1 = phi (base, x_2); 19933 x_2 = x_1 + step; 19934 } 19935 19936 Note that this includes the language restrictions on the operations. 19937For example, if we compile C code and 'x' has signed type, then the 19938overflow in addition would cause undefined behavior, and we may assume 19939that this does not happen. Hence, the value with this SCEV cannot 19940overflow (which restricts the number of iterations of such a loop). 19941 19942 In many cases, one wants to restrict the attention just to affine 19943induction variables. In this case, the extra expressive power of SCEV 19944is not useful, and may complicate the optimizations. In this case, 19945'simple_iv' function may be used to analyze a value - the result is a 19946loop-invariant base and step. 19947 19948 19949File: gccint.info, Node: loop-iv, Next: Number of iterations, Prev: Scalar evolutions, Up: Loop Analysis and Representation 19950 1995116.6 IV analysis on RTL 19952======================= 19953 19954The induction variable on RTL is simple and only allows analysis of 19955affine induction variables, and only in one loop at once. The interface 19956is declared in 'cfgloop.h'. Before analyzing induction variables in a 19957loop L, 'iv_analysis_loop_init' function must be called on L. After the 19958analysis (possibly calling 'iv_analysis_loop_init' for several loops) is 19959finished, 'iv_analysis_done' should be called. The following functions 19960can be used to access the results of the analysis: 19961 19962 * 'iv_analyze': Analyzes a single register used in the given insn. 19963 If no use of the register in this insn is found, the following 19964 insns are scanned, so that this function can be called on the insn 19965 returned by get_condition. 19966 * 'iv_analyze_result': Analyzes result of the assignment in the given 19967 insn. 19968 * 'iv_analyze_expr': Analyzes a more complicated expression. All its 19969 operands are analyzed by 'iv_analyze', and hence they must be used 19970 in the specified insn or one of the following insns. 19971 19972 The description of the induction variable is provided in 'struct 19973rtx_iv'. In order to handle subregs, the representation is a bit 19974complicated; if the value of the 'extend' field is not 'UNKNOWN', the 19975value of the induction variable in the i-th iteration is 19976 19977 delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)), 19978 19979 with the following exception: if 'first_special' is true, then the 19980value in the first iteration (when 'i' is zero) is 'delta + mult * 19981base'. However, if 'extend' is equal to 'UNKNOWN', then 'first_special' 19982must be false, 'delta' 0, 'mult' 1 and the value in the i-th iteration 19983is 19984 19985 subreg_{mode} (base + i * step) 19986 19987 The function 'get_iv_value' can be used to perform these calculations. 19988 19989 19990File: gccint.info, Node: Number of iterations, Next: Dependency analysis, Prev: loop-iv, Up: Loop Analysis and Representation 19991 1999216.7 Number of iterations analysis 19993================================== 19994 19995Both on GIMPLE and on RTL, there are functions available to determine 19996the number of iterations of a loop, with a similar interface. The 19997number of iterations of a loop in GCC is defined as the number of 19998executions of the loop latch. In many cases, it is not possible to 19999determine the number of iterations unconditionally - the determined 20000number is correct only if some assumptions are satisfied. The analysis 20001tries to verify these conditions using the information contained in the 20002program; if it fails, the conditions are returned together with the 20003result. The following information and conditions are provided by the 20004analysis: 20005 20006 * 'assumptions': If this condition is false, the rest of the 20007 information is invalid. 20008 * 'noloop_assumptions' on RTL, 'may_be_zero' on GIMPLE: If this 20009 condition is true, the loop exits in the first iteration. 20010 * 'infinite': If this condition is true, the loop is infinite. This 20011 condition is only available on RTL. On GIMPLE, conditions for 20012 finiteness of the loop are included in 'assumptions'. 20013 * 'niter_expr' on RTL, 'niter' on GIMPLE: The expression that gives 20014 number of iterations. The number of iterations is defined as the 20015 number of executions of the loop latch. 20016 20017 Both on GIMPLE and on RTL, it necessary for the induction variable 20018analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL). 20019On GIMPLE, the results are stored to 'struct tree_niter_desc' structure. 20020Number of iterations before the loop is exited through a given exit can 20021be determined using 'number_of_iterations_exit' function. On RTL, the 20022results are returned in 'struct niter_desc' structure. The 20023corresponding function is named 'check_simple_exit'. There are also 20024functions that pass through all the exits of a loop and try to find one 20025with easy to determine number of iterations - 'find_loop_niter' on 20026GIMPLE and 'find_simple_exit' on RTL. Finally, there are functions that 20027provide the same information, but additionally cache it, so that 20028repeated calls to number of iterations are not so costly - 20029'number_of_latch_executions' on GIMPLE and 'get_simple_loop_desc' on 20030RTL. 20031 20032 Note that some of these functions may behave slightly differently than 20033others - some of them return only the expression for the number of 20034iterations, and fail if there are some assumptions. The function 20035'number_of_latch_executions' works only for single-exit loops. The 20036function 'number_of_cond_exit_executions' can be used to determine 20037number of executions of the exit condition of a single-exit loop (i.e., 20038the 'number_of_latch_executions' increased by one). 20039 20040 On GIMPLE, below constraint flags affect semantics of some APIs of 20041number of iterations analyzer: 20042 20043 * 'LOOP_C_INFINITE': If this constraint flag is set, the loop is 20044 known to be infinite. APIs like 'number_of_iterations_exit' can 20045 return false directly without doing any analysis. 20046 * 'LOOP_C_FINITE': If this constraint flag is set, the loop is known 20047 to be finite, in other words, loop's number of iterations can be 20048 computed with 'assumptions' be true. 20049 20050 Generally, the constraint flags are set/cleared by consumers which are 20051loop optimizers. It's also the consumers' responsibility to set/clear 20052constraints correctly. Failing to do that might result in hard to track 20053down bugs in scev/niter consumers. One typical use case is vectorizer: 20054it drives number of iterations analyzer by setting 'LOOP_C_FINITE' and 20055vectorizes possibly infinite loop by versioning loop with analysis 20056result. In return, constraints set by consumers can also help number of 20057iterations analyzer in following optimizers. For example, 'niter' of a 20058loop versioned under 'assumptions' is valid unconditionally. 20059 20060 Other constraints may be added in the future, for example, a constraint 20061indicating that loops' latch must roll thus 'may_be_zero' would be false 20062unconditionally. 20063 20064 20065File: gccint.info, Node: Dependency analysis, Prev: Number of iterations, Up: Loop Analysis and Representation 20066 2006716.8 Data Dependency Analysis 20068============================= 20069 20070The code for the data dependence analysis can be found in 20071'tree-data-ref.c' and its interface and data structures are described in 20072'tree-data-ref.h'. The function that computes the data dependences for 20073all the array and pointer references for a given loop is 20074'compute_data_dependences_for_loop'. This function is currently used by 20075the linear loop transform and the vectorization passes. Before calling 20076this function, one has to allocate two vectors: a first vector will 20077contain the set of data references that are contained in the analyzed 20078loop body, and the second vector will contain the dependence relations 20079between the data references. Thus if the vector of data references is 20080of size 'n', the vector containing the dependence relations will contain 20081'n*n' elements. However if the analyzed loop contains side effects, 20082such as calls that potentially can interfere with the data references in 20083the current analyzed loop, the analysis stops while scanning the loop 20084body for data references, and inserts a single 'chrec_dont_know' in the 20085dependence relation array. 20086 20087 The data references are discovered in a particular order during the 20088scanning of the loop body: the loop body is analyzed in execution order, 20089and the data references of each statement are pushed at the end of the 20090data reference array. Two data references syntactically occur in the 20091program in the same order as in the array of data references. This 20092syntactic order is important in some classical data dependence tests, 20093and mapping this order to the elements of this array avoids costly 20094queries to the loop body representation. 20095 20096 Three types of data references are currently handled: ARRAY_REF, 20097INDIRECT_REF and COMPONENT_REF. The data structure for the data 20098reference is 'data_reference', where 'data_reference_p' is a name of a 20099pointer to the data reference structure. The structure contains the 20100following elements: 20101 20102 * 'base_object_info': Provides information about the base object of 20103 the data reference and its access functions. These access 20104 functions represent the evolution of the data reference in the loop 20105 relative to its base, in keeping with the classical meaning of the 20106 data reference access function for the support of arrays. For 20107 example, for a reference 'a.b[i][j]', the base object is 'a.b' and 20108 the access functions, one for each array subscript, are: '{i_init, 20109 + i_step}_1, {j_init, +, j_step}_2'. 20110 20111 * 'first_location_in_loop': Provides information about the first 20112 location accessed by the data reference in the loop and about the 20113 access function used to represent evolution relative to this 20114 location. This data is used to support pointers, and is not used 20115 for arrays (for which we have base objects). Pointer accesses are 20116 represented as a one-dimensional access that starts from the first 20117 location accessed in the loop. For example: 20118 20119 for1 i 20120 for2 j 20121 *((int *)p + i + j) = a[i][j]; 20122 20123 The access function of the pointer access is '{0, + 4B}_for2' 20124 relative to 'p + i'. The access functions of the array are 20125 '{i_init, + i_step}_for1' and '{j_init, +, j_step}_for2' relative 20126 to 'a'. 20127 20128 Usually, the object the pointer refers to is either unknown, or we 20129 cannot prove that the access is confined to the boundaries of a 20130 certain object. 20131 20132 Two data references can be compared only if at least one of these 20133 two representations has all its fields filled for both data 20134 references. 20135 20136 The current strategy for data dependence tests is as follows: If 20137 both 'a' and 'b' are represented as arrays, compare 'a.base_object' 20138 and 'b.base_object'; if they are equal, apply dependence tests (use 20139 access functions based on base_objects). Else if both 'a' and 'b' 20140 are represented as pointers, compare 'a.first_location' and 20141 'b.first_location'; if they are equal, apply dependence tests (use 20142 access functions based on first location). However, if 'a' and 'b' 20143 are represented differently, only try to prove that the bases are 20144 definitely different. 20145 20146 * Aliasing information. 20147 * Alignment information. 20148 20149 The structure describing the relation between two data references is 20150'data_dependence_relation' and the shorter name for a pointer to such a 20151structure is 'ddr_p'. This structure contains: 20152 20153 * a pointer to each data reference, 20154 * a tree node 'are_dependent' that is set to 'chrec_known' if the 20155 analysis has proved that there is no dependence between these two 20156 data references, 'chrec_dont_know' if the analysis was not able to 20157 determine any useful result and potentially there could exist a 20158 dependence between these data references, and 'are_dependent' is 20159 set to 'NULL_TREE' if there exist a dependence relation between the 20160 data references, and the description of this dependence relation is 20161 given in the 'subscripts', 'dir_vects', and 'dist_vects' arrays, 20162 * a boolean that determines whether the dependence relation can be 20163 represented by a classical distance vector, 20164 * an array 'subscripts' that contains a description of each subscript 20165 of the data references. Given two array accesses a subscript is 20166 the tuple composed of the access functions for a given dimension. 20167 For example, given 'A[f1][f2][f3]' and 'B[g1][g2][g3]', there are 20168 three subscripts: '(f1, g1), (f2, g2), (f3, g3)'. 20169 * two arrays 'dir_vects' and 'dist_vects' that contain classical 20170 representations of the data dependences under the form of direction 20171 and distance dependence vectors, 20172 * an array of loops 'loop_nest' that contains the loops to which the 20173 distance and direction vectors refer to. 20174 20175 Several functions for pretty printing the information extracted by the 20176data dependence analysis are available: 'dump_ddrs' prints with a 20177maximum verbosity the details of a data dependence relations array, 20178'dump_dist_dir_vectors' prints only the classical distance and direction 20179vectors for a data dependence relations array, and 20180'dump_data_references' prints the details of the data references 20181contained in a data reference array. 20182 20183 20184File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: Loop Analysis and Representation, Up: Top 20185 2018617 Machine Descriptions 20187*********************** 20188 20189A machine description has two parts: a file of instruction patterns 20190('.md' file) and a C header file of macro definitions. 20191 20192 The '.md' file for a target machine contains a pattern for each 20193instruction that the target machine supports (or at least each 20194instruction that is worth telling the compiler about). It may also 20195contain comments. A semicolon causes the rest of the line to be a 20196comment, unless the semicolon is inside a quoted string. 20197 20198 See the next chapter for information on the C header file. 20199 20200* Menu: 20201 20202* Overview:: How the machine description is used. 20203* Patterns:: How to write instruction patterns. 20204* Example:: An explained example of a 'define_insn' pattern. 20205* RTL Template:: The RTL template defines what insns match a pattern. 20206* Output Template:: The output template says how to make assembler code 20207 from such an insn. 20208* Output Statement:: For more generality, write C code to output 20209 the assembler code. 20210* Predicates:: Controlling what kinds of operands can be used 20211 for an insn. 20212* Constraints:: Fine-tuning operand selection. 20213* Standard Names:: Names mark patterns to use for code generation. 20214* Pattern Ordering:: When the order of patterns makes a difference. 20215* Dependent Patterns:: Having one pattern may make you need another. 20216* Jump Patterns:: Special considerations for patterns for jump insns. 20217* Looping Patterns:: How to define patterns for special looping insns. 20218* Insn Canonicalizations::Canonicalization of Instructions 20219* Expander Definitions::Generating a sequence of several RTL insns 20220 for a standard operation. 20221* Insn Splitting:: Splitting Instructions into Multiple Instructions. 20222* Including Patterns:: Including Patterns in Machine Descriptions. 20223* Peephole Definitions::Defining machine-specific peephole optimizations. 20224* Insn Attributes:: Specifying the value of attributes for generated insns. 20225* Conditional Execution::Generating 'define_insn' patterns for 20226 predication. 20227* Define Subst:: Generating 'define_insn' and 'define_expand' 20228 patterns from other patterns. 20229* Constant Definitions::Defining symbolic constants that can be used in the 20230 md file. 20231* Iterators:: Using iterators to generate patterns from a template. 20232 20233 20234File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc 20235 2023617.1 Overview of How the Machine Description is Used 20237==================================================== 20238 20239There are three main conversions that happen in the compiler: 20240 20241 1. The front end reads the source code and builds a parse tree. 20242 20243 2. The parse tree is used to generate an RTL insn list based on named 20244 instruction patterns. 20245 20246 3. The insn list is matched against the RTL templates to produce 20247 assembler code. 20248 20249 For the generate pass, only the names of the insns matter, from either 20250a named 'define_insn' or a 'define_expand'. The compiler will choose 20251the pattern with the right name and apply the operands according to the 20252documentation later in this chapter, without regard for the RTL template 20253or operand constraints. Note that the names the compiler looks for are 20254hard-coded in the compiler--it will ignore unnamed patterns and patterns 20255with names it doesn't know about, but if you don't provide a named 20256pattern it needs, it will abort. 20257 20258 If a 'define_insn' is used, the template given is inserted into the 20259insn list. If a 'define_expand' is used, one of three things happens, 20260based on the condition logic. The condition logic may manually create 20261new insns for the insn list, say via 'emit_insn()', and invoke 'DONE'. 20262For certain named patterns, it may invoke 'FAIL' to tell the compiler to 20263use an alternate way of performing that task. If it invokes neither 20264'DONE' nor 'FAIL', the template given in the pattern is inserted, as if 20265the 'define_expand' were a 'define_insn'. 20266 20267 Once the insn list is generated, various optimization passes convert, 20268replace, and rearrange the insns in the insn list. This is where the 20269'define_split' and 'define_peephole' patterns get used, for example. 20270 20271 Finally, the insn list's RTL is matched up with the RTL templates in 20272the 'define_insn' patterns, and those patterns are used to emit the 20273final assembly code. For this purpose, each named 'define_insn' acts 20274like it's unnamed, since the names are ignored. 20275 20276 20277File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc 20278 2027917.2 Everything about Instruction Patterns 20280========================================== 20281 20282A 'define_insn' expression is used to define instruction patterns to 20283which insns may be matched. A 'define_insn' expression contains an 20284incomplete RTL expression, with pieces to be filled in later, operand 20285constraints that restrict how the pieces can be filled in, and an output 20286template or C code to generate the assembler output. 20287 20288 A 'define_insn' is an RTL expression containing four or five operands: 20289 20290 1. An optional name. The presence of a name indicates that this 20291 instruction pattern can perform a certain standard job for the 20292 RTL-generation pass of the compiler. This pass knows certain names 20293 and will use the instruction patterns with those names, if the 20294 names are defined in the machine description. 20295 20296 The absence of a name is indicated by writing an empty string where 20297 the name should go. Nameless instruction patterns are never used 20298 for generating RTL code, but they may permit several simpler insns 20299 to be combined later on. 20300 20301 Names that are not thus known and used in RTL-generation have no 20302 effect; they are equivalent to no name at all. 20303 20304 For the purpose of debugging the compiler, you may also specify a 20305 name beginning with the '*' character. Such a name is used only 20306 for identifying the instruction in RTL dumps; it is equivalent to 20307 having a nameless pattern for all other purposes. Names beginning 20308 with the '*' character are not required to be unique. 20309 20310 2. The "RTL template": This is a vector of incomplete RTL expressions 20311 which describe the semantics of the instruction (*note RTL 20312 Template::). It is incomplete because it may contain 20313 'match_operand', 'match_operator', and 'match_dup' expressions that 20314 stand for operands of the instruction. 20315 20316 If the vector has multiple elements, the RTL template is treated as 20317 a 'parallel' expression. 20318 20319 3. The condition: This is a string which contains a C expression. 20320 When the compiler attempts to match RTL against a pattern, the 20321 condition is evaluated. If the condition evaluates to 'true', the 20322 match is permitted. The condition may be an empty string, which is 20323 treated as always 'true'. 20324 20325 For a named pattern, the condition may not depend on the data in 20326 the insn being matched, but only the target-machine-type flags. 20327 The compiler needs to test these conditions during initialization 20328 in order to learn exactly which named instructions are available in 20329 a particular run. 20330 20331 For nameless patterns, the condition is applied only when matching 20332 an individual insn, and only after the insn has matched the 20333 pattern's recognition template. The insn's operands may be found 20334 in the vector 'operands'. 20335 20336 An instruction condition cannot become more restrictive as 20337 compilation progresses. If the condition accepts a particular RTL 20338 instruction at one stage of compilation, it must continue to accept 20339 that instruction until the final pass. For example, 20340 '!reload_completed' and 'can_create_pseudo_p ()' are both invalid 20341 instruction conditions, because they are true during the earlier 20342 RTL passes and false during the later ones. For the same reason, 20343 if a condition accepts an instruction before register allocation, 20344 it cannot later try to control register allocation by excluding 20345 certain register or value combinations. 20346 20347 Although a condition cannot become more restrictive as compilation 20348 progresses, the condition for a nameless pattern _can_ become more 20349 permissive. For example, a nameless instruction can require 20350 'reload_completed' to be true, in which case it only matches after 20351 register allocation. 20352 20353 4. The "output template" or "output statement": This is either a 20354 string, or a fragment of C code which returns a string. 20355 20356 When simple substitution isn't general enough, you can specify a 20357 piece of C code to compute the output. *Note Output Statement::. 20358 20359 5. The "insn attributes": This is an optional vector containing the 20360 values of attributes for insns matching this pattern (*note Insn 20361 Attributes::). 20362 20363 20364File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc 20365 2036617.3 Example of 'define_insn' 20367============================= 20368 20369Here is an example of an instruction pattern, taken from the machine 20370description for the 68000/68020. 20371 20372 (define_insn "tstsi" 20373 [(set (cc0) 20374 (match_operand:SI 0 "general_operand" "rm"))] 20375 "" 20376 "* 20377 { 20378 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 20379 return \"tstl %0\"; 20380 return \"cmpl #0,%0\"; 20381 }") 20382 20383This can also be written using braced strings: 20384 20385 (define_insn "tstsi" 20386 [(set (cc0) 20387 (match_operand:SI 0 "general_operand" "rm"))] 20388 "" 20389 { 20390 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 20391 return "tstl %0"; 20392 return "cmpl #0,%0"; 20393 }) 20394 20395 This describes an instruction which sets the condition codes based on 20396the value of a general operand. It has no condition, so any insn with 20397an RTL description of the form shown may be matched to this pattern. 20398The name 'tstsi' means "test a 'SImode' value" and tells the RTL 20399generation pass that, when it is necessary to test such a value, an insn 20400to do so can be constructed using this pattern. 20401 20402 The output control string is a piece of C code which chooses which 20403output template to return based on the kind of operand and the specific 20404type of CPU for which code is being generated. 20405 20406 '"rm"' is an operand constraint. Its meaning is explained below. 20407 20408 20409File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc 20410 2041117.4 RTL Template 20412================= 20413 20414The RTL template is used to define which insns match the particular 20415pattern and how to find their operands. For named patterns, the RTL 20416template also says how to construct an insn from specified operands. 20417 20418 Construction involves substituting specified operands into a copy of 20419the template. Matching involves determining the values that serve as 20420the operands in the insn being matched. Both of these activities are 20421controlled by special expression types that direct matching and 20422substitution of the operands. 20423 20424'(match_operand:M N PREDICATE CONSTRAINT)' 20425 This expression is a placeholder for operand number N of the insn. 20426 When constructing an insn, operand number N will be substituted at 20427 this point. When matching an insn, whatever appears at this 20428 position in the insn will be taken as operand number N; but it must 20429 satisfy PREDICATE or this instruction pattern will not match at 20430 all. 20431 20432 Operand numbers must be chosen consecutively counting from zero in 20433 each instruction pattern. There may be only one 'match_operand' 20434 expression in the pattern for each operand number. Usually 20435 operands are numbered in the order of appearance in 'match_operand' 20436 expressions. In the case of a 'define_expand', any operand numbers 20437 used only in 'match_dup' expressions have higher values than all 20438 other operand numbers. 20439 20440 PREDICATE is a string that is the name of a function that accepts 20441 two arguments, an expression and a machine mode. *Note 20442 Predicates::. During matching, the function will be called with 20443 the putative operand as the expression and M as the mode argument 20444 (if M is not specified, 'VOIDmode' will be used, which normally 20445 causes PREDICATE to accept any mode). If it returns zero, this 20446 instruction pattern fails to match. PREDICATE may be an empty 20447 string; then it means no test is to be done on the operand, so 20448 anything which occurs in this position is valid. 20449 20450 Most of the time, PREDICATE will reject modes other than M--but not 20451 always. For example, the predicate 'address_operand' uses M as the 20452 mode of memory ref that the address should be valid for. Many 20453 predicates accept 'const_int' nodes even though their mode is 20454 'VOIDmode'. 20455 20456 CONSTRAINT controls reloading and the choice of the best register 20457 class to use for a value, as explained later (*note Constraints::). 20458 If the constraint would be an empty string, it can be omitted. 20459 20460 People are often unclear on the difference between the constraint 20461 and the predicate. The predicate helps decide whether a given insn 20462 matches the pattern. The constraint plays no role in this 20463 decision; instead, it controls various decisions in the case of an 20464 insn which does match. 20465 20466'(match_scratch:M N CONSTRAINT)' 20467 This expression is also a placeholder for operand number N and 20468 indicates that operand must be a 'scratch' or 'reg' expression. 20469 20470 When matching patterns, this is equivalent to 20471 20472 (match_operand:M N "scratch_operand" CONSTRAINT) 20473 20474 but, when generating RTL, it produces a ('scratch':M) expression. 20475 20476 If the last few expressions in a 'parallel' are 'clobber' 20477 expressions whose operands are either a hard register or 20478 'match_scratch', the combiner can add or delete them when 20479 necessary. *Note Side Effects::. 20480 20481'(match_dup N)' 20482 This expression is also a placeholder for operand number N. It is 20483 used when the operand needs to appear more than once in the insn. 20484 20485 In construction, 'match_dup' acts just like 'match_operand': the 20486 operand is substituted into the insn being constructed. But in 20487 matching, 'match_dup' behaves differently. It assumes that operand 20488 number N has already been determined by a 'match_operand' appearing 20489 earlier in the recognition template, and it matches only an 20490 identical-looking expression. 20491 20492 Note that 'match_dup' should not be used to tell the compiler that 20493 a particular register is being used for two operands (example: 20494 'add' that adds one register to another; the second register is 20495 both an input operand and the output operand). Use a matching 20496 constraint (*note Simple Constraints::) for those. 'match_dup' is 20497 for the cases where one operand is used in two places in the 20498 template, such as an instruction that computes both a quotient and 20499 a remainder, where the opcode takes two input operands but the RTL 20500 template has to refer to each of those twice; once for the quotient 20501 pattern and once for the remainder pattern. 20502 20503'(match_operator:M N PREDICATE [OPERANDS...])' 20504 This pattern is a kind of placeholder for a variable RTL expression 20505 code. 20506 20507 When constructing an insn, it stands for an RTL expression whose 20508 expression code is taken from that of operand N, and whose operands 20509 are constructed from the patterns OPERANDS. 20510 20511 When matching an expression, it matches an expression if the 20512 function PREDICATE returns nonzero on that expression _and_ the 20513 patterns OPERANDS match the operands of the expression. 20514 20515 Suppose that the function 'commutative_operator' is defined as 20516 follows, to match any expression whose operator is one of the 20517 commutative arithmetic operators of RTL and whose mode is MODE: 20518 20519 int 20520 commutative_integer_operator (x, mode) 20521 rtx x; 20522 machine_mode mode; 20523 { 20524 enum rtx_code code = GET_CODE (x); 20525 if (GET_MODE (x) != mode) 20526 return 0; 20527 return (GET_RTX_CLASS (code) == RTX_COMM_ARITH 20528 || code == EQ || code == NE); 20529 } 20530 20531 Then the following pattern will match any RTL expression consisting 20532 of a commutative operator applied to two general operands: 20533 20534 (match_operator:SI 3 "commutative_operator" 20535 [(match_operand:SI 1 "general_operand" "g") 20536 (match_operand:SI 2 "general_operand" "g")]) 20537 20538 Here the vector '[OPERANDS...]' contains two patterns because the 20539 expressions to be matched all contain two operands. 20540 20541 When this pattern does match, the two operands of the commutative 20542 operator are recorded as operands 1 and 2 of the insn. (This is 20543 done by the two instances of 'match_operand'.) Operand 3 of the 20544 insn will be the entire commutative expression: use 'GET_CODE 20545 (operands[3])' to see which commutative operator was used. 20546 20547 The machine mode M of 'match_operator' works like that of 20548 'match_operand': it is passed as the second argument to the 20549 predicate function, and that function is solely responsible for 20550 deciding whether the expression to be matched "has" that mode. 20551 20552 When constructing an insn, argument 3 of the gen-function will 20553 specify the operation (i.e. the expression code) for the expression 20554 to be made. It should be an RTL expression, whose expression code 20555 is copied into a new expression whose operands are arguments 1 and 20556 2 of the gen-function. The subexpressions of argument 3 are not 20557 used; only its expression code matters. 20558 20559 When 'match_operator' is used in a pattern for matching an insn, it 20560 usually best if the operand number of the 'match_operator' is 20561 higher than that of the actual operands of the insn. This improves 20562 register allocation because the register allocator often looks at 20563 operands 1 and 2 of insns to see if it can do register tying. 20564 20565 There is no way to specify constraints in 'match_operator'. The 20566 operand of the insn which corresponds to the 'match_operator' never 20567 has any constraints because it is never reloaded as a whole. 20568 However, if parts of its OPERANDS are matched by 'match_operand' 20569 patterns, those parts may have constraints of their own. 20570 20571'(match_op_dup:M N[OPERANDS...])' 20572 Like 'match_dup', except that it applies to operators instead of 20573 operands. When constructing an insn, operand number N will be 20574 substituted at this point. But in matching, 'match_op_dup' behaves 20575 differently. It assumes that operand number N has already been 20576 determined by a 'match_operator' appearing earlier in the 20577 recognition template, and it matches only an identical-looking 20578 expression. 20579 20580'(match_parallel N PREDICATE [SUBPAT...])' 20581 This pattern is a placeholder for an insn that consists of a 20582 'parallel' expression with a variable number of elements. This 20583 expression should only appear at the top level of an insn pattern. 20584 20585 When constructing an insn, operand number N will be substituted at 20586 this point. When matching an insn, it matches if the body of the 20587 insn is a 'parallel' expression with at least as many elements as 20588 the vector of SUBPAT expressions in the 'match_parallel', if each 20589 SUBPAT matches the corresponding element of the 'parallel', _and_ 20590 the function PREDICATE returns nonzero on the 'parallel' that is 20591 the body of the insn. It is the responsibility of the predicate to 20592 validate elements of the 'parallel' beyond those listed in the 20593 'match_parallel'. 20594 20595 A typical use of 'match_parallel' is to match load and store 20596 multiple expressions, which can contain a variable number of 20597 elements in a 'parallel'. For example, 20598 20599 (define_insn "" 20600 [(match_parallel 0 "load_multiple_operation" 20601 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 20602 (match_operand:SI 2 "memory_operand" "m")) 20603 (use (reg:SI 179)) 20604 (clobber (reg:SI 179))])] 20605 "" 20606 "loadm 0,0,%1,%2") 20607 20608 This example comes from 'a29k.md'. The function 20609 'load_multiple_operation' is defined in 'a29k.c' and checks that 20610 subsequent elements in the 'parallel' are the same as the 'set' in 20611 the pattern, except that they are referencing subsequent registers 20612 and memory locations. 20613 20614 An insn that matches this pattern might look like: 20615 20616 (parallel 20617 [(set (reg:SI 20) (mem:SI (reg:SI 100))) 20618 (use (reg:SI 179)) 20619 (clobber (reg:SI 179)) 20620 (set (reg:SI 21) 20621 (mem:SI (plus:SI (reg:SI 100) 20622 (const_int 4)))) 20623 (set (reg:SI 22) 20624 (mem:SI (plus:SI (reg:SI 100) 20625 (const_int 8))))]) 20626 20627'(match_par_dup N [SUBPAT...])' 20628 Like 'match_op_dup', but for 'match_parallel' instead of 20629 'match_operator'. 20630 20631 20632File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc 20633 2063417.5 Output Templates and Operand Substitution 20635============================================== 20636 20637The "output template" is a string which specifies how to output the 20638assembler code for an instruction pattern. Most of the template is a 20639fixed string which is output literally. The character '%' is used to 20640specify where to substitute an operand; it can also be used to identify 20641places where different variants of the assembler require different 20642syntax. 20643 20644 In the simplest case, a '%' followed by a digit N says to output 20645operand N at that point in the string. 20646 20647 '%' followed by a letter and a digit says to output an operand in an 20648alternate fashion. Four letters have standard, built-in meanings 20649described below. The machine description macro 'PRINT_OPERAND' can 20650define additional letters with nonstandard meanings. 20651 20652 '%cDIGIT' can be used to substitute an operand that is a constant value 20653without the syntax that normally indicates an immediate operand. 20654 20655 '%nDIGIT' is like '%cDIGIT' except that the value of the constant is 20656negated before printing. 20657 20658 '%aDIGIT' can be used to substitute an operand as if it were a memory 20659reference, with the actual operand treated as the address. This may be 20660useful when outputting a "load address" instruction, because often the 20661assembler syntax for such an instruction requires you to write the 20662operand as if it were a memory reference. 20663 20664 '%lDIGIT' is used to substitute a 'label_ref' into a jump instruction. 20665 20666 '%=' outputs a number which is unique to each instruction in the entire 20667compilation. This is useful for making local labels to be referred to 20668more than once in a single template that generates multiple assembler 20669instructions. 20670 20671 '%' followed by a punctuation character specifies a substitution that 20672does not use an operand. Only one case is standard: '%%' outputs a '%' 20673into the assembler code. Other nonstandard cases can be defined in the 20674'PRINT_OPERAND' macro. You must also define which punctuation 20675characters are valid with the 'PRINT_OPERAND_PUNCT_VALID_P' macro. 20676 20677 The template may generate multiple assembler instructions. Write the 20678text for the instructions, with '\;' between them. 20679 20680 When the RTL contains two operands which are required by constraint to 20681match each other, the output template must refer only to the 20682lower-numbered operand. Matching operands are not always identical, and 20683the rest of the compiler arranges to put the proper RTL expression for 20684printing into the lower-numbered operand. 20685 20686 One use of nonstandard letters or punctuation following '%' is to 20687distinguish between different assembler languages for the same machine; 20688for example, Motorola syntax versus MIT syntax for the 68000. Motorola 20689syntax requires periods in most opcode names, while MIT syntax does not. 20690For example, the opcode 'movel' in MIT syntax is 'move.l' in Motorola 20691syntax. The same file of patterns is used for both kinds of output 20692syntax, but the character sequence '%.' is used in each place where 20693Motorola syntax wants a period. The 'PRINT_OPERAND' macro for Motorola 20694syntax defines the sequence to output a period; the macro for MIT syntax 20695defines it to do nothing. 20696 20697 As a special case, a template consisting of the single character '#' 20698instructs the compiler to first split the insn, and then output the 20699resulting instructions separately. This helps eliminate redundancy in 20700the output templates. If you have a 'define_insn' that needs to emit 20701multiple assembler instructions, and there is a matching 'define_split' 20702already defined, then you can simply use '#' as the output template 20703instead of writing an output template that emits the multiple assembler 20704instructions. 20705 20706 Note that '#' only has an effect while generating assembly code; it 20707does not affect whether a split occurs earlier. An associated 20708'define_split' must exist and it must be suitable for use after register 20709allocation. 20710 20711 If the macro 'ASSEMBLER_DIALECT' is defined, you can use construct of 20712the form '{option0|option1|option2}' in the templates. These describe 20713multiple variants of assembler language syntax. *Note Instruction 20714Output::. 20715 20716 20717File: gccint.info, Node: Output Statement, Next: Predicates, Prev: Output Template, Up: Machine Desc 20718 2071917.6 C Statements for Assembler Output 20720====================================== 20721 20722Often a single fixed template string cannot produce correct and 20723efficient assembler code for all the cases that are recognized by a 20724single instruction pattern. For example, the opcodes may depend on the 20725kinds of operands; or some unfortunate combinations of operands may 20726require extra machine instructions. 20727 20728 If the output control string starts with a '@', then it is actually a 20729series of templates, each on a separate line. (Blank lines and leading 20730spaces and tabs are ignored.) The templates correspond to the pattern's 20731constraint alternatives (*note Multi-Alternative::). For example, if a 20732target machine has a two-address add instruction 'addr' to add into a 20733register and another 'addm' to add a register to memory, you might write 20734this pattern: 20735 20736 (define_insn "addsi3" 20737 [(set (match_operand:SI 0 "general_operand" "=r,m") 20738 (plus:SI (match_operand:SI 1 "general_operand" "0,0") 20739 (match_operand:SI 2 "general_operand" "g,r")))] 20740 "" 20741 "@ 20742 addr %2,%0 20743 addm %2,%0") 20744 20745 If the output control string starts with a '*', then it is not an 20746output template but rather a piece of C program that should compute a 20747template. It should execute a 'return' statement to return the 20748template-string you want. Most such templates use C string literals, 20749which require doublequote characters to delimit them. To include these 20750doublequote characters in the string, prefix each one with '\'. 20751 20752 If the output control string is written as a brace block instead of a 20753double-quoted string, it is automatically assumed to be C code. In that 20754case, it is not necessary to put in a leading asterisk, or to escape the 20755doublequotes surrounding C string literals. 20756 20757 The operands may be found in the array 'operands', whose C data type is 20758'rtx []'. 20759 20760 It is very common to select different ways of generating assembler code 20761based on whether an immediate operand is within a certain range. Be 20762careful when doing this, because the result of 'INTVAL' is an integer on 20763the host machine. If the host machine has more bits in an 'int' than 20764the target machine has in the mode in which the constant will be used, 20765then some of the bits you get from 'INTVAL' will be superfluous. For 20766proper results, you must carefully disregard the values of those bits. 20767 20768 It is possible to output an assembler instruction and then go on to 20769output or compute more of them, using the subroutine 'output_asm_insn'. 20770This receives two arguments: a template-string and a vector of operands. 20771The vector may be 'operands', or it may be another array of 'rtx' that 20772you declare locally and initialize yourself. 20773 20774 When an insn pattern has multiple alternatives in its constraints, 20775often the appearance of the assembler code is determined mostly by which 20776alternative was matched. When this is so, the C code can test the 20777variable 'which_alternative', which is the ordinal number of the 20778alternative that was actually satisfied (0 for the first, 1 for the 20779second alternative, etc.). 20780 20781 For example, suppose there are two opcodes for storing zero, 'clrreg' 20782for registers and 'clrmem' for memory locations. Here is how a pattern 20783could use 'which_alternative' to choose between them: 20784 20785 (define_insn "" 20786 [(set (match_operand:SI 0 "general_operand" "=r,m") 20787 (const_int 0))] 20788 "" 20789 { 20790 return (which_alternative == 0 20791 ? "clrreg %0" : "clrmem %0"); 20792 }) 20793 20794 The example above, where the assembler code to generate was _solely_ 20795determined by the alternative, could also have been specified as 20796follows, having the output control string start with a '@': 20797 20798 (define_insn "" 20799 [(set (match_operand:SI 0 "general_operand" "=r,m") 20800 (const_int 0))] 20801 "" 20802 "@ 20803 clrreg %0 20804 clrmem %0") 20805 20806 If you just need a little bit of C code in one (or a few) alternatives, 20807you can use '*' inside of a '@' multi-alternative template: 20808 20809 (define_insn "" 20810 [(set (match_operand:SI 0 "general_operand" "=r,<,m") 20811 (const_int 0))] 20812 "" 20813 "@ 20814 clrreg %0 20815 * return stack_mem_p (operands[0]) ? \"push 0\" : \"clrmem %0\"; 20816 clrmem %0") 20817 20818 20819File: gccint.info, Node: Predicates, Next: Constraints, Prev: Output Statement, Up: Machine Desc 20820 2082117.7 Predicates 20822=============== 20823 20824A predicate determines whether a 'match_operand' or 'match_operator' 20825expression matches, and therefore whether the surrounding instruction 20826pattern will be used for that combination of operands. GCC has a number 20827of machine-independent predicates, and you can define machine-specific 20828predicates as needed. By convention, predicates used with 20829'match_operand' have names that end in '_operand', and those used with 20830'match_operator' have names that end in '_operator'. 20831 20832 All predicates are boolean functions (in the mathematical sense) of two 20833arguments: the RTL expression that is being considered at that position 20834in the instruction pattern, and the machine mode that the 20835'match_operand' or 'match_operator' specifies. In this section, the 20836first argument is called OP and the second argument MODE. Predicates 20837can be called from C as ordinary two-argument functions; this can be 20838useful in output templates or other machine-specific code. 20839 20840 Operand predicates can allow operands that are not actually acceptable 20841to the hardware, as long as the constraints give reload the ability to 20842fix them up (*note Constraints::). However, GCC will usually generate 20843better code if the predicates specify the requirements of the machine 20844instructions as closely as possible. Reload cannot fix up operands that 20845must be constants ("immediate operands"); you must use a predicate that 20846allows only constants, or else enforce the requirement in the extra 20847condition. 20848 20849 Most predicates handle their MODE argument in a uniform manner. If 20850MODE is 'VOIDmode' (unspecified), then OP can have any mode. If MODE is 20851anything else, then OP must have the same mode, unless OP is a 20852'CONST_INT' or integer 'CONST_DOUBLE'. These RTL expressions always 20853have 'VOIDmode', so it would be counterproductive to check that their 20854mode matches. Instead, predicates that accept 'CONST_INT' and/or 20855integer 'CONST_DOUBLE' check that the value stored in the constant will 20856fit in the requested mode. 20857 20858 Predicates with this behavior are called "normal". 'genrecog' can 20859optimize the instruction recognizer based on knowledge of how normal 20860predicates treat modes. It can also diagnose certain kinds of common 20861errors in the use of normal predicates; for instance, it is almost 20862always an error to use a normal predicate without specifying a mode. 20863 20864 Predicates that do something different with their MODE argument are 20865called "special". The generic predicates 'address_operand' and 20866'pmode_register_operand' are special predicates. 'genrecog' does not do 20867any optimizations or diagnosis when special predicates are used. 20868 20869* Menu: 20870 20871* Machine-Independent Predicates:: Predicates available to all back ends. 20872* Defining Predicates:: How to write machine-specific predicate 20873 functions. 20874 20875 20876File: gccint.info, Node: Machine-Independent Predicates, Next: Defining Predicates, Up: Predicates 20877 2087817.7.1 Machine-Independent Predicates 20879------------------------------------- 20880 20881These are the generic predicates available to all back ends. They are 20882defined in 'recog.c'. The first category of predicates allow only 20883constant, or "immediate", operands. 20884 20885 -- Function: immediate_operand 20886 This predicate allows any sort of constant that fits in MODE. It 20887 is an appropriate choice for instructions that take operands that 20888 must be constant. 20889 20890 -- Function: const_int_operand 20891 This predicate allows any 'CONST_INT' expression that fits in MODE. 20892 It is an appropriate choice for an immediate operand that does not 20893 allow a symbol or label. 20894 20895 -- Function: const_double_operand 20896 This predicate accepts any 'CONST_DOUBLE' expression that has 20897 exactly MODE. If MODE is 'VOIDmode', it will also accept 20898 'CONST_INT'. It is intended for immediate floating point 20899 constants. 20900 20901The second category of predicates allow only some kind of machine 20902register. 20903 20904 -- Function: register_operand 20905 This predicate allows any 'REG' or 'SUBREG' expression that is 20906 valid for MODE. It is often suitable for arithmetic instruction 20907 operands on a RISC machine. 20908 20909 -- Function: pmode_register_operand 20910 This is a slight variant on 'register_operand' which works around a 20911 limitation in the machine-description reader. 20912 20913 (match_operand N "pmode_register_operand" CONSTRAINT) 20914 20915 means exactly what 20916 20917 (match_operand:P N "register_operand" CONSTRAINT) 20918 20919 would mean, if the machine-description reader accepted ':P' mode 20920 suffixes. Unfortunately, it cannot, because 'Pmode' is an alias 20921 for some other mode, and might vary with machine-specific options. 20922 *Note Misc::. 20923 20924 -- Function: scratch_operand 20925 This predicate allows hard registers and 'SCRATCH' expressions, but 20926 not pseudo-registers. It is used internally by 'match_scratch'; it 20927 should not be used directly. 20928 20929The third category of predicates allow only some kind of memory 20930reference. 20931 20932 -- Function: memory_operand 20933 This predicate allows any valid reference to a quantity of mode 20934 MODE in memory, as determined by the weak form of 20935 'GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::). 20936 20937 -- Function: address_operand 20938 This predicate is a little unusual; it allows any operand that is a 20939 valid expression for the _address_ of a quantity of mode MODE, 20940 again determined by the weak form of 'GO_IF_LEGITIMATE_ADDRESS'. 20941 To first order, if '(mem:MODE (EXP))' is acceptable to 20942 'memory_operand', then EXP is acceptable to 'address_operand'. 20943 Note that EXP does not necessarily have the mode MODE. 20944 20945 -- Function: indirect_operand 20946 This is a stricter form of 'memory_operand' which allows only 20947 memory references with a 'general_operand' as the address 20948 expression. New uses of this predicate are discouraged, because 20949 'general_operand' is very permissive, so it's hard to tell what an 20950 'indirect_operand' does or does not allow. If a target has 20951 different requirements for memory operands for different 20952 instructions, it is better to define target-specific predicates 20953 which enforce the hardware's requirements explicitly. 20954 20955 -- Function: push_operand 20956 This predicate allows a memory reference suitable for pushing a 20957 value onto the stack. This will be a 'MEM' which refers to 20958 'stack_pointer_rtx', with a side effect in its address expression 20959 (*note Incdec::); which one is determined by the 'STACK_PUSH_CODE' 20960 macro (*note Frame Layout::). 20961 20962 -- Function: pop_operand 20963 This predicate allows a memory reference suitable for popping a 20964 value off the stack. Again, this will be a 'MEM' referring to 20965 'stack_pointer_rtx', with a side effect in its address expression. 20966 However, this time 'STACK_POP_CODE' is expected. 20967 20968The fourth category of predicates allow some combination of the above 20969operands. 20970 20971 -- Function: nonmemory_operand 20972 This predicate allows any immediate or register operand valid for 20973 MODE. 20974 20975 -- Function: nonimmediate_operand 20976 This predicate allows any register or memory operand valid for 20977 MODE. 20978 20979 -- Function: general_operand 20980 This predicate allows any immediate, register, or memory operand 20981 valid for MODE. 20982 20983Finally, there are two generic operator predicates. 20984 20985 -- Function: comparison_operator 20986 This predicate matches any expression which performs an arithmetic 20987 comparison in MODE; that is, 'COMPARISON_P' is true for the 20988 expression code. 20989 20990 -- Function: ordered_comparison_operator 20991 This predicate matches any expression which performs an arithmetic 20992 comparison in MODE and whose expression code is valid for integer 20993 modes; that is, the expression code will be one of 'eq', 'ne', 20994 'lt', 'ltu', 'le', 'leu', 'gt', 'gtu', 'ge', 'geu'. 20995 20996 20997File: gccint.info, Node: Defining Predicates, Prev: Machine-Independent Predicates, Up: Predicates 20998 2099917.7.2 Defining Machine-Specific Predicates 21000------------------------------------------- 21001 21002Many machines have requirements for their operands that cannot be 21003expressed precisely using the generic predicates. You can define 21004additional predicates using 'define_predicate' and 21005'define_special_predicate' expressions. These expressions have three 21006operands: 21007 21008 * The name of the predicate, as it will be referred to in 21009 'match_operand' or 'match_operator' expressions. 21010 21011 * An RTL expression which evaluates to true if the predicate allows 21012 the operand OP, false if it does not. This expression can only use 21013 the following RTL codes: 21014 21015 'MATCH_OPERAND' 21016 When written inside a predicate expression, a 'MATCH_OPERAND' 21017 expression evaluates to true if the predicate it names would 21018 allow OP. The operand number and constraint are ignored. Due 21019 to limitations in 'genrecog', you can only refer to generic 21020 predicates and predicates that have already been defined. 21021 21022 'MATCH_CODE' 21023 This expression evaluates to true if OP or a specified 21024 subexpression of OP has one of a given list of RTX codes. 21025 21026 The first operand of this expression is a string constant 21027 containing a comma-separated list of RTX code names (in lower 21028 case). These are the codes for which the 'MATCH_CODE' will be 21029 true. 21030 21031 The second operand is a string constant which indicates what 21032 subexpression of OP to examine. If it is absent or the empty 21033 string, OP itself is examined. Otherwise, the string constant 21034 must be a sequence of digits and/or lowercase letters. Each 21035 character indicates a subexpression to extract from the 21036 current expression; for the first character this is OP, for 21037 the second and subsequent characters it is the result of the 21038 previous character. A digit N extracts 'XEXP (E, N)'; a 21039 letter L extracts 'XVECEXP (E, 0, N)' where N is the 21040 alphabetic ordinal of L (0 for 'a', 1 for 'b', and so on). 21041 The 'MATCH_CODE' then examines the RTX code of the 21042 subexpression extracted by the complete string. It is not 21043 possible to extract components of an 'rtvec' that is not at 21044 position 0 within its RTX object. 21045 21046 'MATCH_TEST' 21047 This expression has one operand, a string constant containing 21048 a C expression. The predicate's arguments, OP and MODE, are 21049 available with those names in the C expression. The 21050 'MATCH_TEST' evaluates to true if the C expression evaluates 21051 to a nonzero value. 'MATCH_TEST' expressions must not have 21052 side effects. 21053 21054 'AND' 21055 'IOR' 21056 'NOT' 21057 'IF_THEN_ELSE' 21058 The basic 'MATCH_' expressions can be combined using these 21059 logical operators, which have the semantics of the C operators 21060 '&&', '||', '!', and '? :' respectively. As in Common Lisp, 21061 you may give an 'AND' or 'IOR' expression an arbitrary number 21062 of arguments; this has exactly the same effect as writing a 21063 chain of two-argument 'AND' or 'IOR' expressions. 21064 21065 * An optional block of C code, which should execute 'return true' if 21066 the predicate is found to match and 'return false' if it does not. 21067 It must not have any side effects. The predicate arguments, OP and 21068 MODE, are available with those names. 21069 21070 If a code block is present in a predicate definition, then the RTL 21071 expression must evaluate to true _and_ the code block must execute 21072 'return true' for the predicate to allow the operand. The RTL 21073 expression is evaluated first; do not re-check anything in the code 21074 block that was checked in the RTL expression. 21075 21076 The program 'genrecog' scans 'define_predicate' and 21077'define_special_predicate' expressions to determine which RTX codes are 21078possibly allowed. You should always make this explicit in the RTL 21079predicate expression, using 'MATCH_OPERAND' and 'MATCH_CODE'. 21080 21081 Here is an example of a simple predicate definition, from the IA64 21082machine description: 21083 21084 ;; True if OP is a 'SYMBOL_REF' which refers to the sdata section. 21085 (define_predicate "small_addr_symbolic_operand" 21086 (and (match_code "symbol_ref") 21087 (match_test "SYMBOL_REF_SMALL_ADDR_P (op)"))) 21088 21089And here is another, showing the use of the C block. 21090 21091 ;; True if OP is a register operand that is (or could be) a GR reg. 21092 (define_predicate "gr_register_operand" 21093 (match_operand 0 "register_operand") 21094 { 21095 unsigned int regno; 21096 if (GET_CODE (op) == SUBREG) 21097 op = SUBREG_REG (op); 21098 21099 regno = REGNO (op); 21100 return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno)); 21101 }) 21102 21103 Predicates written with 'define_predicate' automatically include a test 21104that MODE is 'VOIDmode', or OP has the same mode as MODE, or OP is a 21105'CONST_INT' or 'CONST_DOUBLE'. They do _not_ check specifically for 21106integer 'CONST_DOUBLE', nor do they test that the value of either kind 21107of constant fits in the requested mode. This is because target-specific 21108predicates that take constants usually have to do more stringent value 21109checks anyway. If you need the exact same treatment of 'CONST_INT' or 21110'CONST_DOUBLE' that the generic predicates provide, use a 21111'MATCH_OPERAND' subexpression to call 'const_int_operand', 21112'const_double_operand', or 'immediate_operand'. 21113 21114 Predicates written with 'define_special_predicate' do not get any 21115automatic mode checks, and are treated as having special mode handling 21116by 'genrecog'. 21117 21118 The program 'genpreds' is responsible for generating code to test 21119predicates. It also writes a header file containing function 21120declarations for all machine-specific predicates. It is not necessary 21121to declare these predicates in 'CPU-protos.h'. 21122 21123 21124File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Predicates, Up: Machine Desc 21125 2112617.8 Operand Constraints 21127======================== 21128 21129Each 'match_operand' in an instruction pattern can specify constraints 21130for the operands allowed. The constraints allow you to fine-tune 21131matching within the set of operands allowed by the predicate. 21132 21133 Constraints can say whether an operand may be in a register, and which 21134kinds of register; whether the operand can be a memory reference, and 21135which kinds of address; whether the operand may be an immediate 21136constant, and which possible values it may have. Constraints can also 21137require two operands to match. Side-effects aren't allowed in operands 21138of inline 'asm', unless '<' or '>' constraints are used, because there 21139is no guarantee that the side effects will happen exactly once in an 21140instruction that can update the addressing register. 21141 21142* Menu: 21143 21144* Simple Constraints:: Basic use of constraints. 21145* Multi-Alternative:: When an insn has two alternative constraint-patterns. 21146* Class Preferences:: Constraints guide which hard register to put things in. 21147* Modifiers:: More precise control over effects of constraints. 21148* Machine Constraints:: Existing constraints for some particular machines. 21149* Disable Insn Alternatives:: Disable insn alternatives using attributes. 21150* Define Constraints:: How to define machine-specific constraints. 21151* C Constraint Interface:: How to test constraints from C code. 21152 21153 21154File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints 21155 2115617.8.1 Simple Constraints 21157------------------------- 21158 21159The simplest kind of constraint is a string full of letters, each of 21160which describes one kind of operand that is permitted. Here are the 21161letters that are allowed: 21162 21163whitespace 21164 Whitespace characters are ignored and can be inserted at any 21165 position except the first. This enables each alternative for 21166 different operands to be visually aligned in the machine 21167 description even if they have different number of constraints and 21168 modifiers. 21169 21170'm' 21171 A memory operand is allowed, with any kind of address that the 21172 machine supports in general. Note that the letter used for the 21173 general memory constraint can be re-defined by a back end using the 21174 'TARGET_MEM_CONSTRAINT' macro. 21175 21176'o' 21177 A memory operand is allowed, but only if the address is 21178 "offsettable". This means that adding a small integer (actually, 21179 the width in bytes of the operand, as determined by its machine 21180 mode) may be added to the address and the result is also a valid 21181 memory address. 21182 21183 For example, an address which is constant is offsettable; so is an 21184 address that is the sum of a register and a constant (as long as a 21185 slightly larger constant is also within the range of 21186 address-offsets supported by the machine); but an autoincrement or 21187 autodecrement address is not offsettable. More complicated 21188 indirect/indexed addresses may or may not be offsettable depending 21189 on the other addressing modes that the machine supports. 21190 21191 Note that in an output operand which can be matched by another 21192 operand, the constraint letter 'o' is valid only when accompanied 21193 by both '<' (if the target machine has predecrement addressing) and 21194 '>' (if the target machine has preincrement addressing). 21195 21196'V' 21197 A memory operand that is not offsettable. In other words, anything 21198 that would fit the 'm' constraint but not the 'o' constraint. 21199 21200'<' 21201 A memory operand with autodecrement addressing (either predecrement 21202 or postdecrement) is allowed. In inline 'asm' this constraint is 21203 only allowed if the operand is used exactly once in an instruction 21204 that can handle the side effects. Not using an operand with '<' in 21205 constraint string in the inline 'asm' pattern at all or using it in 21206 multiple instructions isn't valid, because the side effects 21207 wouldn't be performed or would be performed more than once. 21208 Furthermore, on some targets the operand with '<' in constraint 21209 string must be accompanied by special instruction suffixes like 21210 '%U0' instruction suffix on PowerPC or '%P0' on IA-64. 21211 21212'>' 21213 A memory operand with autoincrement addressing (either preincrement 21214 or postincrement) is allowed. In inline 'asm' the same 21215 restrictions as for '<' apply. 21216 21217'r' 21218 A register operand is allowed provided that it is in a general 21219 register. 21220 21221'i' 21222 An immediate integer operand (one with constant value) is allowed. 21223 This includes symbolic constants whose values will be known only at 21224 assembly time or later. 21225 21226'n' 21227 An immediate integer operand with a known numeric value is allowed. 21228 Many systems cannot support assembly-time constants for operands 21229 less than a word wide. Constraints for these operands should use 21230 'n' rather than 'i'. 21231 21232'I', 'J', 'K', ... 'P' 21233 Other letters in the range 'I' through 'P' may be defined in a 21234 machine-dependent fashion to permit immediate integer operands with 21235 explicit integer values in specified ranges. For example, on the 21236 68000, 'I' is defined to stand for the range of values 1 to 8. 21237 This is the range permitted as a shift count in the shift 21238 instructions. 21239 21240'E' 21241 An immediate floating operand (expression code 'const_double') is 21242 allowed, but only if the target floating point format is the same 21243 as that of the host machine (on which the compiler is running). 21244 21245'F' 21246 An immediate floating operand (expression code 'const_double' or 21247 'const_vector') is allowed. 21248 21249'G', 'H' 21250 'G' and 'H' may be defined in a machine-dependent fashion to permit 21251 immediate floating operands in particular ranges of values. 21252 21253's' 21254 An immediate integer operand whose value is not an explicit integer 21255 is allowed. 21256 21257 This might appear strange; if an insn allows a constant operand 21258 with a value not known at compile time, it certainly must allow any 21259 known value. So why use 's' instead of 'i'? Sometimes it allows 21260 better code to be generated. 21261 21262 For example, on the 68000 in a fullword instruction it is possible 21263 to use an immediate operand; but if the immediate value is between 21264 -128 and 127, better code results from loading the value into a 21265 register and using the register. This is because the load into the 21266 register can be done with a 'moveq' instruction. We arrange for 21267 this to happen by defining the letter 'K' to mean "any integer 21268 outside the range -128 to 127", and then specifying 'Ks' in the 21269 operand constraints. 21270 21271'g' 21272 Any register, memory or immediate integer operand is allowed, 21273 except for registers that are not general registers. 21274 21275'X' 21276 Any operand whatsoever is allowed, even if it does not satisfy 21277 'general_operand'. This is normally used in the constraint of a 21278 'match_scratch' when certain alternatives will not actually require 21279 a scratch register. 21280 21281'0', '1', '2', ... '9' 21282 An operand that matches the specified operand number is allowed. 21283 If a digit is used together with letters within the same 21284 alternative, the digit should come last. 21285 21286 This number is allowed to be more than a single digit. If multiple 21287 digits are encountered consecutively, they are interpreted as a 21288 single decimal integer. There is scant chance for ambiguity, since 21289 to-date it has never been desirable that '10' be interpreted as 21290 matching either operand 1 _or_ operand 0. Should this be desired, 21291 one can use multiple alternatives instead. 21292 21293 This is called a "matching constraint" and what it really means is 21294 that the assembler has only a single operand that fills two roles 21295 considered separate in the RTL insn. For example, an add insn has 21296 two input operands and one output operand in the RTL, but on most 21297 CISC machines an add instruction really has only two operands, one 21298 of them an input-output operand: 21299 21300 addl #35,r12 21301 21302 Matching constraints are used in these circumstances. More 21303 precisely, the two operands that match must include one input-only 21304 operand and one output-only operand. Moreover, the digit must be a 21305 smaller number than the number of the operand that uses it in the 21306 constraint. 21307 21308 For operands to match in a particular case usually means that they 21309 are identical-looking RTL expressions. But in a few special cases 21310 specific kinds of dissimilarity are allowed. For example, '*x' as 21311 an input operand will match '*x++' as an output operand. For 21312 proper results in such cases, the output template should always use 21313 the output-operand's number when printing the operand. 21314 21315'p' 21316 An operand that is a valid memory address is allowed. This is for 21317 "load address" and "push address" instructions. 21318 21319 'p' in the constraint must be accompanied by 'address_operand' as 21320 the predicate in the 'match_operand'. This predicate interprets 21321 the mode specified in the 'match_operand' as the mode of the memory 21322 reference for which the address would be valid. 21323 21324OTHER-LETTERS 21325 Other letters can be defined in machine-dependent fashion to stand 21326 for particular classes of registers or other arbitrary operand 21327 types. 'd', 'a' and 'f' are defined on the 68000/68020 to stand 21328 for data, address and floating point registers. 21329 21330 In order to have valid assembler code, each operand must satisfy its 21331constraint. But a failure to do so does not prevent the pattern from 21332applying to an insn. Instead, it directs the compiler to modify the 21333code so that the constraint will be satisfied. Usually this is done by 21334copying an operand into a register. 21335 21336 Contrast, therefore, the two instruction patterns that follow: 21337 21338 (define_insn "" 21339 [(set (match_operand:SI 0 "general_operand" "=r") 21340 (plus:SI (match_dup 0) 21341 (match_operand:SI 1 "general_operand" "r")))] 21342 "" 21343 "...") 21344 21345which has two operands, one of which must appear in two places, and 21346 21347 (define_insn "" 21348 [(set (match_operand:SI 0 "general_operand" "=r") 21349 (plus:SI (match_operand:SI 1 "general_operand" "0") 21350 (match_operand:SI 2 "general_operand" "r")))] 21351 "" 21352 "...") 21353 21354which has three operands, two of which are required by a constraint to 21355be identical. If we are considering an insn of the form 21356 21357 (insn N PREV NEXT 21358 (set (reg:SI 3) 21359 (plus:SI (reg:SI 6) (reg:SI 109))) 21360 ...) 21361 21362the first pattern would not apply at all, because this insn does not 21363contain two identical subexpressions in the right place. The pattern 21364would say, "That does not look like an add instruction; try other 21365patterns". The second pattern would say, "Yes, that's an add 21366instruction, but there is something wrong with it". It would direct the 21367reload pass of the compiler to generate additional insns to make the 21368constraint true. The results might look like this: 21369 21370 (insn N2 PREV N 21371 (set (reg:SI 3) (reg:SI 6)) 21372 ...) 21373 21374 (insn N N2 NEXT 21375 (set (reg:SI 3) 21376 (plus:SI (reg:SI 3) (reg:SI 109))) 21377 ...) 21378 21379 It is up to you to make sure that each operand, in each pattern, has 21380constraints that can handle any RTL expression that could be present for 21381that operand. (When multiple alternatives are in use, each pattern 21382must, for each possible combination of operand expressions, have at 21383least one alternative which can handle that combination of operands.) 21384The constraints don't need to _allow_ any possible operand--when this is 21385the case, they do not constrain--but they must at least point the way to 21386reloading any possible operand so that it will fit. 21387 21388 * If the constraint accepts whatever operands the predicate permits, 21389 there is no problem: reloading is never necessary for this operand. 21390 21391 For example, an operand whose constraints permit everything except 21392 registers is safe provided its predicate rejects registers. 21393 21394 An operand whose predicate accepts only constant values is safe 21395 provided its constraints include the letter 'i'. If any possible 21396 constant value is accepted, then nothing less than 'i' will do; if 21397 the predicate is more selective, then the constraints may also be 21398 more selective. 21399 21400 * Any operand expression can be reloaded by copying it into a 21401 register. So if an operand's constraints allow some kind of 21402 register, it is certain to be safe. It need not permit all classes 21403 of registers; the compiler knows how to copy a register into 21404 another register of the proper class in order to make an 21405 instruction valid. 21406 21407 * A nonoffsettable memory reference can be reloaded by copying the 21408 address into a register. So if the constraint uses the letter 'o', 21409 all memory references are taken care of. 21410 21411 * A constant operand can be reloaded by allocating space in memory to 21412 hold it as preinitialized data. Then the memory reference can be 21413 used in place of the constant. So if the constraint uses the 21414 letters 'o' or 'm', constant operands are not a problem. 21415 21416 * If the constraint permits a constant and a pseudo register used in 21417 an insn was not allocated to a hard register and is equivalent to a 21418 constant, the register will be replaced with the constant. If the 21419 predicate does not permit a constant and the insn is re-recognized 21420 for some reason, the compiler will crash. Thus the predicate must 21421 always recognize any objects allowed by the constraint. 21422 21423 If the operand's predicate can recognize registers, but the constraint 21424does not permit them, it can make the compiler crash. When this operand 21425happens to be a register, the reload pass will be stymied, because it 21426does not know how to copy a register temporarily into memory. 21427 21428 If the predicate accepts a unary operator, the constraint applies to 21429the operand. For example, the MIPS processor at ISA level 3 supports an 21430instruction which adds two registers in 'SImode' to produce a 'DImode' 21431result, but only if the registers are correctly sign extended. This 21432predicate for the input operands accepts a 'sign_extend' of an 'SImode' 21433register. Write the constraint to indicate the type of register that is 21434required for the operand of the 'sign_extend'. 21435 21436 21437File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints 21438 2143917.8.2 Multiple Alternative Constraints 21440--------------------------------------- 21441 21442Sometimes a single instruction has multiple alternative sets of possible 21443operands. For example, on the 68000, a logical-or instruction can 21444combine register or an immediate value into memory, or it can combine 21445any kind of operand into a register; but it cannot combine one memory 21446location into another. 21447 21448 These constraints are represented as multiple alternatives. An 21449alternative can be described by a series of letters for each operand. 21450The overall constraint for an operand is made from the letters for this 21451operand from the first alternative, a comma, the letters for this 21452operand from the second alternative, a comma, and so on until the last 21453alternative. All operands for a single instruction must have the same 21454number of alternatives. Here is how it is done for fullword logical-or 21455on the 68000: 21456 21457 (define_insn "iorsi3" 21458 [(set (match_operand:SI 0 "general_operand" "=m,d") 21459 (ior:SI (match_operand:SI 1 "general_operand" "%0,0") 21460 (match_operand:SI 2 "general_operand" "dKs,dmKs")))] 21461 ...) 21462 21463 The first alternative has 'm' (memory) for operand 0, '0' for operand 1 21464(meaning it must match operand 0), and 'dKs' for operand 2. The second 21465alternative has 'd' (data register) for operand 0, '0' for operand 1, 21466and 'dmKs' for operand 2. The '=' and '%' in the constraints apply to 21467all the alternatives; their meaning is explained in the next section 21468(*note Class Preferences::). 21469 21470 If all the operands fit any one alternative, the instruction is valid. 21471Otherwise, for each alternative, the compiler counts how many 21472instructions must be added to copy the operands so that that alternative 21473applies. The alternative requiring the least copying is chosen. If two 21474alternatives need the same amount of copying, the one that comes first 21475is chosen. These choices can be altered with the '?' and '!' 21476characters: 21477 21478'?' 21479 Disparage slightly the alternative that the '?' appears in, as a 21480 choice when no alternative applies exactly. The compiler regards 21481 this alternative as one unit more costly for each '?' that appears 21482 in it. 21483 21484'!' 21485 Disparage severely the alternative that the '!' appears in. This 21486 alternative can still be used if it fits without reloading, but if 21487 reloading is needed, some other alternative will be used. 21488 21489'^' 21490 This constraint is analogous to '?' but it disparages slightly the 21491 alternative only if the operand with the '^' needs a reload. 21492 21493'$' 21494 This constraint is analogous to '!' but it disparages severely the 21495 alternative only if the operand with the '$' needs a reload. 21496 21497 When an insn pattern has multiple alternatives in its constraints, 21498often the appearance of the assembler code is determined mostly by which 21499alternative was matched. When this is so, the C code for writing the 21500assembler code can use the variable 'which_alternative', which is the 21501ordinal number of the alternative that was actually satisfied (0 for the 21502first, 1 for the second alternative, etc.). *Note Output Statement::. 21503 21504 21505File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints 21506 2150717.8.3 Register Class Preferences 21508--------------------------------- 21509 21510The operand constraints have another function: they enable the compiler 21511to decide which kind of hardware register a pseudo register is best 21512allocated to. The compiler examines the constraints that apply to the 21513insns that use the pseudo register, looking for the machine-dependent 21514letters such as 'd' and 'a' that specify classes of registers. The 21515pseudo register is put in whichever class gets the most "votes". The 21516constraint letters 'g' and 'r' also vote: they vote in favor of a 21517general register. The machine description says which registers are 21518considered general. 21519 21520 Of course, on some machines all registers are equivalent, and no 21521register classes are defined. Then none of this complexity is relevant. 21522 21523 21524File: gccint.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints 21525 2152617.8.4 Constraint Modifier Characters 21527------------------------------------- 21528 21529Here are constraint modifier characters. 21530 21531'=' 21532 Means that this operand is written to by this instruction: the 21533 previous value is discarded and replaced by new data. 21534 21535'+' 21536 Means that this operand is both read and written by the 21537 instruction. 21538 21539 When the compiler fixes up the operands to satisfy the constraints, 21540 it needs to know which operands are read by the instruction and 21541 which are written by it. '=' identifies an operand which is only 21542 written; '+' identifies an operand that is both read and written; 21543 all other operands are assumed to only be read. 21544 21545 If you specify '=' or '+' in a constraint, you put it in the first 21546 character of the constraint string. 21547 21548'&' 21549 Means (in a particular alternative) that this operand is an 21550 "earlyclobber" operand, which is written before the instruction is 21551 finished using the input operands. Therefore, this operand may not 21552 lie in a register that is read by the instruction or as part of any 21553 memory address. 21554 21555 '&' applies only to the alternative in which it is written. In 21556 constraints with multiple alternatives, sometimes one alternative 21557 requires '&' while others do not. See, for example, the 'movdf' 21558 insn of the 68000. 21559 21560 A operand which is read by the instruction can be tied to an 21561 earlyclobber operand if its only use as an input occurs before the 21562 early result is written. Adding alternatives of this form often 21563 allows GCC to produce better code when only some of the read 21564 operands can be affected by the earlyclobber. See, for example, 21565 the 'mulsi3' insn of the ARM. 21566 21567 Furthermore, if the "earlyclobber" operand is also a read/write 21568 operand, then that operand is written only after it's used. 21569 21570 '&' does not obviate the need to write '=' or '+'. As 21571 "earlyclobber" operands are always written, a read-only 21572 "earlyclobber" operand is ill-formed and will be rejected by the 21573 compiler. 21574 21575'%' 21576 Declares the instruction to be commutative for this operand and the 21577 following operand. This means that the compiler may interchange 21578 the two operands if that is the cheapest way to make all operands 21579 fit the constraints. '%' applies to all alternatives and must 21580 appear as the first character in the constraint. Only read-only 21581 operands can use '%'. 21582 21583 This is often used in patterns for addition instructions that 21584 really have only two operands: the result must go in one of the 21585 arguments. Here for example, is how the 68000 halfword-add 21586 instruction is defined: 21587 21588 (define_insn "addhi3" 21589 [(set (match_operand:HI 0 "general_operand" "=m,r") 21590 (plus:HI (match_operand:HI 1 "general_operand" "%0,0") 21591 (match_operand:HI 2 "general_operand" "di,g")))] 21592 ...) 21593 GCC can only handle one commutative pair in an asm; if you use 21594 more, the compiler may fail. Note that you need not use the 21595 modifier if the two alternatives are strictly identical; this would 21596 only waste time in the reload pass. The modifier is not 21597 operational after register allocation, so the result of 21598 'define_peephole2' and 'define_split's performed after reload 21599 cannot rely on '%' to make the intended insn match. 21600 21601'#' 21602 Says that all following characters, up to the next comma, are to be 21603 ignored as a constraint. They are significant only for choosing 21604 register preferences. 21605 21606'*' 21607 Says that the following character should be ignored when choosing 21608 register preferences. '*' has no effect on the meaning of the 21609 constraint as a constraint, and no effect on reloading. For LRA 21610 '*' additionally disparages slightly the alternative if the 21611 following character matches the operand. 21612 21613 Here is an example: the 68000 has an instruction to sign-extend a 21614 halfword in a data register, and can also sign-extend a value by 21615 copying it into an address register. While either kind of register 21616 is acceptable, the constraints on an address-register destination 21617 are less strict, so it is best if register allocation makes an 21618 address register its goal. Therefore, '*' is used so that the 'd' 21619 constraint letter (for data register) is ignored when computing 21620 register preferences. 21621 21622 (define_insn "extendhisi2" 21623 [(set (match_operand:SI 0 "general_operand" "=*d,a") 21624 (sign_extend:SI 21625 (match_operand:HI 1 "general_operand" "0,g")))] 21626 ...) 21627 21628 21629File: gccint.info, Node: Machine Constraints, Next: Disable Insn Alternatives, Prev: Modifiers, Up: Constraints 21630 2163117.8.5 Constraints for Particular Machines 21632------------------------------------------ 21633 21634Whenever possible, you should use the general-purpose constraint letters 21635in 'asm' arguments, since they will convey meaning more readily to 21636people reading your code. Failing that, use the constraint letters that 21637usually have very similar meanings across architectures. The most 21638commonly used constraints are 'm' and 'r' (for memory and 21639general-purpose registers respectively; *note Simple Constraints::), and 21640'I', usually the letter indicating the most common immediate-constant 21641format. 21642 21643 Each architecture defines additional constraints. These constraints 21644are used by the compiler itself for instruction generation, as well as 21645for 'asm' statements; therefore, some of the constraints are not 21646particularly useful for 'asm'. Here is a summary of some of the 21647machine-dependent constraints available on some particular machines; it 21648includes both constraints that are useful for 'asm' and constraints that 21649aren't. The compiler source file mentioned in the table heading for 21650each architecture is the definitive reference for the meanings of that 21651architecture's constraints. 21652 21653_AArch64 family--'config/aarch64/constraints.md'_ 21654 'k' 21655 The stack pointer register ('SP') 21656 21657 'w' 21658 Floating point register, Advanced SIMD vector register or SVE 21659 vector register 21660 21661 'Upl' 21662 One of the low eight SVE predicate registers ('P0' to 'P7') 21663 21664 'Upa' 21665 Any of the SVE predicate registers ('P0' to 'P15') 21666 21667 'I' 21668 Integer constant that is valid as an immediate operand in an 21669 'ADD' instruction 21670 21671 'J' 21672 Integer constant that is valid as an immediate operand in a 21673 'SUB' instruction (once negated) 21674 21675 'K' 21676 Integer constant that can be used with a 32-bit logical 21677 instruction 21678 21679 'L' 21680 Integer constant that can be used with a 64-bit logical 21681 instruction 21682 21683 'M' 21684 Integer constant that is valid as an immediate operand in a 21685 32-bit 'MOV' pseudo instruction. The 'MOV' may be assembled 21686 to one of several different machine instructions depending on 21687 the value 21688 21689 'N' 21690 Integer constant that is valid as an immediate operand in a 21691 64-bit 'MOV' pseudo instruction 21692 21693 'S' 21694 An absolute symbolic address or a label reference 21695 21696 'Y' 21697 Floating point constant zero 21698 21699 'Z' 21700 Integer constant zero 21701 21702 'Ush' 21703 The high part (bits 12 and upwards) of the pc-relative address 21704 of a symbol within 4GB of the instruction 21705 21706 'Q' 21707 A memory address which uses a single base register with no 21708 offset 21709 21710 'Ump' 21711 A memory address suitable for a load/store pair instruction in 21712 SI, DI, SF and DF modes 21713 21714_ARC --'config/arc/constraints.md'_ 21715 'q' 21716 Registers usable in ARCompact 16-bit instructions: 'r0'-'r3', 21717 'r12'-'r15'. This constraint can only match when the '-mq' 21718 option is in effect. 21719 21720 'e' 21721 Registers usable as base-regs of memory addresses in ARCompact 21722 16-bit memory instructions: 'r0'-'r3', 'r12'-'r15', 'sp'. 21723 This constraint can only match when the '-mq' option is in 21724 effect. 21725 'D' 21726 ARC FPX (dpfp) 64-bit registers. 'D0', 'D1'. 21727 21728 'I' 21729 A signed 12-bit integer constant. 21730 21731 'Cal' 21732 constant for arithmetic/logical operations. This might be any 21733 constant that can be put into a long immediate by the assmbler 21734 or linker without involving a PIC relocation. 21735 21736 'K' 21737 A 3-bit unsigned integer constant. 21738 21739 'L' 21740 A 6-bit unsigned integer constant. 21741 21742 'CnL' 21743 One's complement of a 6-bit unsigned integer constant. 21744 21745 'CmL' 21746 Two's complement of a 6-bit unsigned integer constant. 21747 21748 'M' 21749 A 5-bit unsigned integer constant. 21750 21751 'O' 21752 A 7-bit unsigned integer constant. 21753 21754 'P' 21755 A 8-bit unsigned integer constant. 21756 21757 'H' 21758 Any const_double value. 21759 21760_ARM family--'config/arm/constraints.md'_ 21761 21762 'h' 21763 In Thumb state, the core registers 'r8'-'r15'. 21764 21765 'k' 21766 The stack pointer register. 21767 21768 'l' 21769 In Thumb State the core registers 'r0'-'r7'. In ARM state 21770 this is an alias for the 'r' constraint. 21771 21772 't' 21773 VFP floating-point registers 's0'-'s31'. Used for 32 bit 21774 values. 21775 21776 'w' 21777 VFP floating-point registers 'd0'-'d31' and the appropriate 21778 subset 'd0'-'d15' based on command line options. Used for 64 21779 bit values only. Not valid for Thumb1. 21780 21781 'y' 21782 The iWMMX co-processor registers. 21783 21784 'z' 21785 The iWMMX GR registers. 21786 21787 'G' 21788 The floating-point constant 0.0 21789 21790 'I' 21791 Integer that is valid as an immediate operand in a data 21792 processing instruction. That is, an integer in the range 0 to 21793 255 rotated by a multiple of 2 21794 21795 'J' 21796 Integer in the range -4095 to 4095 21797 21798 'K' 21799 Integer that satisfies constraint 'I' when inverted (ones 21800 complement) 21801 21802 'L' 21803 Integer that satisfies constraint 'I' when negated (twos 21804 complement) 21805 21806 'M' 21807 Integer in the range 0 to 32 21808 21809 'Q' 21810 A memory reference where the exact address is in a single 21811 register (''m'' is preferable for 'asm' statements) 21812 21813 'R' 21814 An item in the constant pool 21815 21816 'S' 21817 A symbol in the text segment of the current file 21818 21819 'Uv' 21820 A memory reference suitable for VFP load/store insns 21821 (reg+constant offset) 21822 21823 'Uy' 21824 A memory reference suitable for iWMMXt load/store 21825 instructions. 21826 21827 'Uq' 21828 A memory reference suitable for the ARMv4 ldrsb instruction. 21829 21830_AVR family--'config/avr/constraints.md'_ 21831 'l' 21832 Registers from r0 to r15 21833 21834 'a' 21835 Registers from r16 to r23 21836 21837 'd' 21838 Registers from r16 to r31 21839 21840 'w' 21841 Registers from r24 to r31. These registers can be used in 21842 'adiw' command 21843 21844 'e' 21845 Pointer register (r26-r31) 21846 21847 'b' 21848 Base pointer register (r28-r31) 21849 21850 'q' 21851 Stack pointer register (SPH:SPL) 21852 21853 't' 21854 Temporary register r0 21855 21856 'x' 21857 Register pair X (r27:r26) 21858 21859 'y' 21860 Register pair Y (r29:r28) 21861 21862 'z' 21863 Register pair Z (r31:r30) 21864 21865 'I' 21866 Constant greater than -1, less than 64 21867 21868 'J' 21869 Constant greater than -64, less than 1 21870 21871 'K' 21872 Constant integer 2 21873 21874 'L' 21875 Constant integer 0 21876 21877 'M' 21878 Constant that fits in 8 bits 21879 21880 'N' 21881 Constant integer -1 21882 21883 'O' 21884 Constant integer 8, 16, or 24 21885 21886 'P' 21887 Constant integer 1 21888 21889 'G' 21890 A floating point constant 0.0 21891 21892 'Q' 21893 A memory address based on Y or Z pointer with displacement. 21894 21895_Blackfin family--'config/bfin/constraints.md'_ 21896 'a' 21897 P register 21898 21899 'd' 21900 D register 21901 21902 'z' 21903 A call clobbered P register. 21904 21905 'qN' 21906 A single register. If N is in the range 0 to 7, the 21907 corresponding D register. If it is 'A', then the register P0. 21908 21909 'D' 21910 Even-numbered D register 21911 21912 'W' 21913 Odd-numbered D register 21914 21915 'e' 21916 Accumulator register. 21917 21918 'A' 21919 Even-numbered accumulator register. 21920 21921 'B' 21922 Odd-numbered accumulator register. 21923 21924 'b' 21925 I register 21926 21927 'v' 21928 B register 21929 21930 'f' 21931 M register 21932 21933 'c' 21934 Registers used for circular buffering, i.e. I, B, or L 21935 registers. 21936 21937 'C' 21938 The CC register. 21939 21940 't' 21941 LT0 or LT1. 21942 21943 'k' 21944 LC0 or LC1. 21945 21946 'u' 21947 LB0 or LB1. 21948 21949 'x' 21950 Any D, P, B, M, I or L register. 21951 21952 'y' 21953 Additional registers typically used only in prologues and 21954 epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and 21955 USP. 21956 21957 'w' 21958 Any register except accumulators or CC. 21959 21960 'Ksh' 21961 Signed 16 bit integer (in the range -32768 to 32767) 21962 21963 'Kuh' 21964 Unsigned 16 bit integer (in the range 0 to 65535) 21965 21966 'Ks7' 21967 Signed 7 bit integer (in the range -64 to 63) 21968 21969 'Ku7' 21970 Unsigned 7 bit integer (in the range 0 to 127) 21971 21972 'Ku5' 21973 Unsigned 5 bit integer (in the range 0 to 31) 21974 21975 'Ks4' 21976 Signed 4 bit integer (in the range -8 to 7) 21977 21978 'Ks3' 21979 Signed 3 bit integer (in the range -3 to 4) 21980 21981 'Ku3' 21982 Unsigned 3 bit integer (in the range 0 to 7) 21983 21984 'PN' 21985 Constant N, where N is a single-digit constant in the range 0 21986 to 4. 21987 21988 'PA' 21989 An integer equal to one of the MACFLAG_XXX constants that is 21990 suitable for use with either accumulator. 21991 21992 'PB' 21993 An integer equal to one of the MACFLAG_XXX constants that is 21994 suitable for use only with accumulator A1. 21995 21996 'M1' 21997 Constant 255. 21998 21999 'M2' 22000 Constant 65535. 22001 22002 'J' 22003 An integer constant with exactly a single bit set. 22004 22005 'L' 22006 An integer constant with all bits set except exactly one. 22007 22008 'H' 22009 22010 'Q' 22011 Any SYMBOL_REF. 22012 22013_CR16 Architecture--'config/cr16/cr16.h'_ 22014 22015 'b' 22016 Registers from r0 to r14 (registers without stack pointer) 22017 22018 't' 22019 Register from r0 to r11 (all 16-bit registers) 22020 22021 'p' 22022 Register from r12 to r15 (all 32-bit registers) 22023 22024 'I' 22025 Signed constant that fits in 4 bits 22026 22027 'J' 22028 Signed constant that fits in 5 bits 22029 22030 'K' 22031 Signed constant that fits in 6 bits 22032 22033 'L' 22034 Unsigned constant that fits in 4 bits 22035 22036 'M' 22037 Signed constant that fits in 32 bits 22038 22039 'N' 22040 Check for 64 bits wide constants for add/sub instructions 22041 22042 'G' 22043 Floating point constant that is legal for store immediate 22044 22045_Epiphany--'config/epiphany/constraints.md'_ 22046 'U16' 22047 An unsigned 16-bit constant. 22048 22049 'K' 22050 An unsigned 5-bit constant. 22051 22052 'L' 22053 A signed 11-bit constant. 22054 22055 'Cm1' 22056 A signed 11-bit constant added to -1. Can only match when the 22057 '-m1reg-REG' option is active. 22058 22059 'Cl1' 22060 Left-shift of -1, i.e., a bit mask with a block of leading 22061 ones, the rest being a block of trailing zeroes. Can only 22062 match when the '-m1reg-REG' option is active. 22063 22064 'Cr1' 22065 Right-shift of -1, i.e., a bit mask with a trailing block of 22066 ones, the rest being zeroes. Or to put it another way, one 22067 less than a power of two. Can only match when the 22068 '-m1reg-REG' option is active. 22069 22070 'Cal' 22071 Constant for arithmetic/logical operations. This is like 'i', 22072 except that for position independent code, no symbols / 22073 expressions needing relocations are allowed. 22074 22075 'Csy' 22076 Symbolic constant for call/jump instruction. 22077 22078 'Rcs' 22079 The register class usable in short insns. This is a register 22080 class constraint, and can thus drive register allocation. 22081 This constraint won't match unless '-mprefer-short-insn-regs' 22082 is in effect. 22083 22084 'Rsc' 22085 The the register class of registers that can be used to hold a 22086 sibcall call address. I.e., a caller-saved register. 22087 22088 'Rct' 22089 Core control register class. 22090 22091 'Rgs' 22092 The register group usable in short insns. This constraint 22093 does not use a register class, so that it only passively 22094 matches suitable registers, and doesn't drive register 22095 allocation. 22096 22097 'Car' 22098 Constant suitable for the addsi3_r pattern. This is a valid 22099 offset For byte, halfword, or word addressing. 22100 22101 'Rra' 22102 Matches the return address if it can be replaced with the link 22103 register. 22104 22105 'Rcc' 22106 Matches the integer condition code register. 22107 22108 'Sra' 22109 Matches the return address if it is in a stack slot. 22110 22111 'Cfm' 22112 Matches control register values to switch fp mode, which are 22113 encapsulated in 'UNSPEC_FP_MODE'. 22114 22115_FRV--'config/frv/frv.h'_ 22116 'a' 22117 Register in the class 'ACC_REGS' ('acc0' to 'acc7'). 22118 22119 'b' 22120 Register in the class 'EVEN_ACC_REGS' ('acc0' to 'acc7'). 22121 22122 'c' 22123 Register in the class 'CC_REGS' ('fcc0' to 'fcc3' and 'icc0' 22124 to 'icc3'). 22125 22126 'd' 22127 Register in the class 'GPR_REGS' ('gr0' to 'gr63'). 22128 22129 'e' 22130 Register in the class 'EVEN_REGS' ('gr0' to 'gr63'). Odd 22131 registers are excluded not in the class but through the use of 22132 a machine mode larger than 4 bytes. 22133 22134 'f' 22135 Register in the class 'FPR_REGS' ('fr0' to 'fr63'). 22136 22137 'h' 22138 Register in the class 'FEVEN_REGS' ('fr0' to 'fr63'). Odd 22139 registers are excluded not in the class but through the use of 22140 a machine mode larger than 4 bytes. 22141 22142 'l' 22143 Register in the class 'LR_REG' (the 'lr' register). 22144 22145 'q' 22146 Register in the class 'QUAD_REGS' ('gr2' to 'gr63'). Register 22147 numbers not divisible by 4 are excluded not in the class but 22148 through the use of a machine mode larger than 8 bytes. 22149 22150 't' 22151 Register in the class 'ICC_REGS' ('icc0' to 'icc3'). 22152 22153 'u' 22154 Register in the class 'FCC_REGS' ('fcc0' to 'fcc3'). 22155 22156 'v' 22157 Register in the class 'ICR_REGS' ('cc4' to 'cc7'). 22158 22159 'w' 22160 Register in the class 'FCR_REGS' ('cc0' to 'cc3'). 22161 22162 'x' 22163 Register in the class 'QUAD_FPR_REGS' ('fr0' to 'fr63'). 22164 Register numbers not divisible by 4 are excluded not in the 22165 class but through the use of a machine mode larger than 8 22166 bytes. 22167 22168 'z' 22169 Register in the class 'SPR_REGS' ('lcr' and 'lr'). 22170 22171 'A' 22172 Register in the class 'QUAD_ACC_REGS' ('acc0' to 'acc7'). 22173 22174 'B' 22175 Register in the class 'ACCG_REGS' ('accg0' to 'accg7'). 22176 22177 'C' 22178 Register in the class 'CR_REGS' ('cc0' to 'cc7'). 22179 22180 'G' 22181 Floating point constant zero 22182 22183 'I' 22184 6-bit signed integer constant 22185 22186 'J' 22187 10-bit signed integer constant 22188 22189 'L' 22190 16-bit signed integer constant 22191 22192 'M' 22193 16-bit unsigned integer constant 22194 22195 'N' 22196 12-bit signed integer constant that is negative--i.e. in the 22197 range of -2048 to -1 22198 22199 'O' 22200 Constant zero 22201 22202 'P' 22203 12-bit signed integer constant that is greater than zero--i.e. 22204 in the range of 1 to 2047. 22205 22206_FT32--'config/ft32/constraints.md'_ 22207 'A' 22208 An absolute address 22209 22210 'B' 22211 An offset address 22212 22213 'W' 22214 A register indirect memory operand 22215 22216 'e' 22217 An offset address. 22218 22219 'f' 22220 An offset address. 22221 22222 'O' 22223 The constant zero or one 22224 22225 'I' 22226 A 16-bit signed constant (-32768 ... 32767) 22227 22228 'w' 22229 A bitfield mask suitable for bext or bins 22230 22231 'x' 22232 An inverted bitfield mask suitable for bext or bins 22233 22234 'L' 22235 A 16-bit unsigned constant, multiple of 4 (0 ... 65532) 22236 22237 'S' 22238 A 20-bit signed constant (-524288 ... 524287) 22239 22240 'b' 22241 A constant for a bitfield width (1 ... 16) 22242 22243 'KA' 22244 A 10-bit signed constant (-512 ... 511) 22245 22246_Hewlett-Packard PA-RISC--'config/pa/pa.h'_ 22247 'a' 22248 General register 1 22249 22250 'f' 22251 Floating point register 22252 22253 'q' 22254 Shift amount register 22255 22256 'x' 22257 Floating point register (deprecated) 22258 22259 'y' 22260 Upper floating point register (32-bit), floating point 22261 register (64-bit) 22262 22263 'Z' 22264 Any register 22265 22266 'I' 22267 Signed 11-bit integer constant 22268 22269 'J' 22270 Signed 14-bit integer constant 22271 22272 'K' 22273 Integer constant that can be deposited with a 'zdepi' 22274 instruction 22275 22276 'L' 22277 Signed 5-bit integer constant 22278 22279 'M' 22280 Integer constant 0 22281 22282 'N' 22283 Integer constant that can be loaded with a 'ldil' instruction 22284 22285 'O' 22286 Integer constant whose value plus one is a power of 2 22287 22288 'P' 22289 Integer constant that can be used for 'and' operations in 22290 'depi' and 'extru' instructions 22291 22292 'S' 22293 Integer constant 31 22294 22295 'U' 22296 Integer constant 63 22297 22298 'G' 22299 Floating-point constant 0.0 22300 22301 'A' 22302 A 'lo_sum' data-linkage-table memory operand 22303 22304 'Q' 22305 A memory operand that can be used as the destination operand 22306 of an integer store instruction 22307 22308 'R' 22309 A scaled or unscaled indexed memory operand 22310 22311 'T' 22312 A memory operand for floating-point loads and stores 22313 22314 'W' 22315 A register indirect memory operand 22316 22317_Intel IA-64--'config/ia64/ia64.h'_ 22318 'a' 22319 General register 'r0' to 'r3' for 'addl' instruction 22320 22321 'b' 22322 Branch register 22323 22324 'c' 22325 Predicate register ('c' as in "conditional") 22326 22327 'd' 22328 Application register residing in M-unit 22329 22330 'e' 22331 Application register residing in I-unit 22332 22333 'f' 22334 Floating-point register 22335 22336 'm' 22337 Memory operand. If used together with '<' or '>', the operand 22338 can have postincrement and postdecrement which require 22339 printing with '%Pn' on IA-64. 22340 22341 'G' 22342 Floating-point constant 0.0 or 1.0 22343 22344 'I' 22345 14-bit signed integer constant 22346 22347 'J' 22348 22-bit signed integer constant 22349 22350 'K' 22351 8-bit signed integer constant for logical instructions 22352 22353 'L' 22354 8-bit adjusted signed integer constant for compare pseudo-ops 22355 22356 'M' 22357 6-bit unsigned integer constant for shift counts 22358 22359 'N' 22360 9-bit signed integer constant for load and store 22361 postincrements 22362 22363 'O' 22364 The constant zero 22365 22366 'P' 22367 0 or -1 for 'dep' instruction 22368 22369 'Q' 22370 Non-volatile memory for floating-point loads and stores 22371 22372 'R' 22373 Integer constant in the range 1 to 4 for 'shladd' instruction 22374 22375 'S' 22376 Memory operand except postincrement and postdecrement. This 22377 is now roughly the same as 'm' when not used together with '<' 22378 or '>'. 22379 22380_M32C--'config/m32c/m32c.c'_ 22381 'Rsp' 22382 'Rfb' 22383 'Rsb' 22384 '$sp', '$fb', '$sb'. 22385 22386 'Rcr' 22387 Any control register, when they're 16 bits wide (nothing if 22388 control registers are 24 bits wide) 22389 22390 'Rcl' 22391 Any control register, when they're 24 bits wide. 22392 22393 'R0w' 22394 'R1w' 22395 'R2w' 22396 'R3w' 22397 $r0, $r1, $r2, $r3. 22398 22399 'R02' 22400 $r0 or $r2, or $r2r0 for 32 bit values. 22401 22402 'R13' 22403 $r1 or $r3, or $r3r1 for 32 bit values. 22404 22405 'Rdi' 22406 A register that can hold a 64 bit value. 22407 22408 'Rhl' 22409 $r0 or $r1 (registers with addressable high/low bytes) 22410 22411 'R23' 22412 $r2 or $r3 22413 22414 'Raa' 22415 Address registers 22416 22417 'Raw' 22418 Address registers when they're 16 bits wide. 22419 22420 'Ral' 22421 Address registers when they're 24 bits wide. 22422 22423 'Rqi' 22424 Registers that can hold QI values. 22425 22426 'Rad' 22427 Registers that can be used with displacements ($a0, $a1, $sb). 22428 22429 'Rsi' 22430 Registers that can hold 32 bit values. 22431 22432 'Rhi' 22433 Registers that can hold 16 bit values. 22434 22435 'Rhc' 22436 Registers chat can hold 16 bit values, including all control 22437 registers. 22438 22439 'Rra' 22440 $r0 through R1, plus $a0 and $a1. 22441 22442 'Rfl' 22443 The flags register. 22444 22445 'Rmm' 22446 The memory-based pseudo-registers $mem0 through $mem15. 22447 22448 'Rpi' 22449 Registers that can hold pointers (16 bit registers for r8c, 22450 m16c; 24 bit registers for m32cm, m32c). 22451 22452 'Rpa' 22453 Matches multiple registers in a PARALLEL to form a larger 22454 register. Used to match function return values. 22455 22456 'Is3' 22457 -8 ... 7 22458 22459 'IS1' 22460 -128 ... 127 22461 22462 'IS2' 22463 -32768 ... 32767 22464 22465 'IU2' 22466 0 ... 65535 22467 22468 'In4' 22469 -8 ... -1 or 1 ... 8 22470 22471 'In5' 22472 -16 ... -1 or 1 ... 16 22473 22474 'In6' 22475 -32 ... -1 or 1 ... 32 22476 22477 'IM2' 22478 -65536 ... -1 22479 22480 'Ilb' 22481 An 8 bit value with exactly one bit set. 22482 22483 'Ilw' 22484 A 16 bit value with exactly one bit set. 22485 22486 'Sd' 22487 The common src/dest memory addressing modes. 22488 22489 'Sa' 22490 Memory addressed using $a0 or $a1. 22491 22492 'Si' 22493 Memory addressed with immediate addresses. 22494 22495 'Ss' 22496 Memory addressed using the stack pointer ($sp). 22497 22498 'Sf' 22499 Memory addressed using the frame base register ($fb). 22500 22501 'Ss' 22502 Memory addressed using the small base register ($sb). 22503 22504 'S1' 22505 $r1h 22506 22507_MicroBlaze--'config/microblaze/constraints.md'_ 22508 'd' 22509 A general register ('r0' to 'r31'). 22510 22511 'z' 22512 A status register ('rmsr', '$fcc1' to '$fcc7'). 22513 22514_MIPS--'config/mips/constraints.md'_ 22515 'd' 22516 A general-purpose register. This is equivalent to 'r' unless 22517 generating MIPS16 code, in which case the MIPS16 register set 22518 is used. 22519 22520 'f' 22521 A floating-point register (if available). 22522 22523 'h' 22524 Formerly the 'hi' register. This constraint is no longer 22525 supported. 22526 22527 'l' 22528 The 'lo' register. Use this register to store values that are 22529 no bigger than a word. 22530 22531 'x' 22532 The concatenated 'hi' and 'lo' registers. Use this register 22533 to store doubleword values. 22534 22535 'c' 22536 A register suitable for use in an indirect jump. This will 22537 always be '$25' for '-mabicalls'. 22538 22539 'v' 22540 Register '$3'. Do not use this constraint in new code; it is 22541 retained only for compatibility with glibc. 22542 22543 'y' 22544 Equivalent to 'r'; retained for backwards compatibility. 22545 22546 'z' 22547 A floating-point condition code register. 22548 22549 'I' 22550 A signed 16-bit constant (for arithmetic instructions). 22551 22552 'J' 22553 Integer zero. 22554 22555 'K' 22556 An unsigned 16-bit constant (for logic instructions). 22557 22558 'L' 22559 A signed 32-bit constant in which the lower 16 bits are zero. 22560 Such constants can be loaded using 'lui'. 22561 22562 'M' 22563 A constant that cannot be loaded using 'lui', 'addiu' or 22564 'ori'. 22565 22566 'N' 22567 A constant in the range -65535 to -1 (inclusive). 22568 22569 'O' 22570 A signed 15-bit constant. 22571 22572 'P' 22573 A constant in the range 1 to 65535 (inclusive). 22574 22575 'G' 22576 Floating-point zero. 22577 22578 'R' 22579 An address that can be used in a non-macro load or store. 22580 22581 'ZC' 22582 A memory operand whose address is formed by a base register 22583 and offset that is suitable for use in instructions with the 22584 same addressing mode as 'll' and 'sc'. 22585 22586 'ZD' 22587 An address suitable for a 'prefetch' instruction, or for any 22588 other instruction with the same addressing mode as 'prefetch'. 22589 22590_Motorola 680x0--'config/m68k/constraints.md'_ 22591 'a' 22592 Address register 22593 22594 'd' 22595 Data register 22596 22597 'f' 22598 68881 floating-point register, if available 22599 22600 'I' 22601 Integer in the range 1 to 8 22602 22603 'J' 22604 16-bit signed number 22605 22606 'K' 22607 Signed number whose magnitude is greater than 0x80 22608 22609 'L' 22610 Integer in the range -8 to -1 22611 22612 'M' 22613 Signed number whose magnitude is greater than 0x100 22614 22615 'N' 22616 Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate 22617 22618 'O' 22619 16 (for rotate using swap) 22620 22621 'P' 22622 Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate 22623 22624 'R' 22625 Numbers that mov3q can handle 22626 22627 'G' 22628 Floating point constant that is not a 68881 constant 22629 22630 'S' 22631 Operands that satisfy 'm' when -mpcrel is in effect 22632 22633 'T' 22634 Operands that satisfy 's' when -mpcrel is not in effect 22635 22636 'Q' 22637 Address register indirect addressing mode 22638 22639 'U' 22640 Register offset addressing 22641 22642 'W' 22643 const_call_operand 22644 22645 'Cs' 22646 symbol_ref or const 22647 22648 'Ci' 22649 const_int 22650 22651 'C0' 22652 const_int 0 22653 22654 'Cj' 22655 Range of signed numbers that don't fit in 16 bits 22656 22657 'Cmvq' 22658 Integers valid for mvq 22659 22660 'Capsw' 22661 Integers valid for a moveq followed by a swap 22662 22663 'Cmvz' 22664 Integers valid for mvz 22665 22666 'Cmvs' 22667 Integers valid for mvs 22668 22669 'Ap' 22670 push_operand 22671 22672 'Ac' 22673 Non-register operands allowed in clr 22674 22675_Moxie--'config/moxie/constraints.md'_ 22676 'A' 22677 An absolute address 22678 22679 'B' 22680 An offset address 22681 22682 'W' 22683 A register indirect memory operand 22684 22685 'I' 22686 A constant in the range of 0 to 255. 22687 22688 'N' 22689 A constant in the range of 0 to -255. 22690 22691_MSP430-'config/msp430/constraints.md'_ 22692 22693 'R12' 22694 Register R12. 22695 22696 'R13' 22697 Register R13. 22698 22699 'K' 22700 Integer constant 1. 22701 22702 'L' 22703 Integer constant -1^20..1^19. 22704 22705 'M' 22706 Integer constant 1-4. 22707 22708 'Ya' 22709 Memory references which do not require an extended MOVX 22710 instruction. 22711 22712 'Yl' 22713 Memory reference, labels only. 22714 22715 'Ys' 22716 Memory reference, stack only. 22717 22718_NDS32--'config/nds32/constraints.md'_ 22719 'w' 22720 LOW register class $r0 to $r7 constraint for V3/V3M ISA. 22721 'l' 22722 LOW register class $r0 to $r7. 22723 'd' 22724 MIDDLE register class $r0 to $r11, $r16 to $r19. 22725 'h' 22726 HIGH register class $r12 to $r14, $r20 to $r31. 22727 't' 22728 Temporary assist register $ta (i.e. $r15). 22729 'k' 22730 Stack register $sp. 22731 'Iu03' 22732 Unsigned immediate 3-bit value. 22733 'In03' 22734 Negative immediate 3-bit value in the range of -7-0. 22735 'Iu04' 22736 Unsigned immediate 4-bit value. 22737 'Is05' 22738 Signed immediate 5-bit value. 22739 'Iu05' 22740 Unsigned immediate 5-bit value. 22741 'In05' 22742 Negative immediate 5-bit value in the range of -31-0. 22743 'Ip05' 22744 Unsigned immediate 5-bit value for movpi45 instruction with 22745 range 16-47. 22746 'Iu06' 22747 Unsigned immediate 6-bit value constraint for addri36.sp 22748 instruction. 22749 'Iu08' 22750 Unsigned immediate 8-bit value. 22751 'Iu09' 22752 Unsigned immediate 9-bit value. 22753 'Is10' 22754 Signed immediate 10-bit value. 22755 'Is11' 22756 Signed immediate 11-bit value. 22757 'Is15' 22758 Signed immediate 15-bit value. 22759 'Iu15' 22760 Unsigned immediate 15-bit value. 22761 'Ic15' 22762 A constant which is not in the range of imm15u but ok for bclr 22763 instruction. 22764 'Ie15' 22765 A constant which is not in the range of imm15u but ok for bset 22766 instruction. 22767 'It15' 22768 A constant which is not in the range of imm15u but ok for btgl 22769 instruction. 22770 'Ii15' 22771 A constant whose compliment value is in the range of imm15u 22772 and ok for bitci instruction. 22773 'Is16' 22774 Signed immediate 16-bit value. 22775 'Is17' 22776 Signed immediate 17-bit value. 22777 'Is19' 22778 Signed immediate 19-bit value. 22779 'Is20' 22780 Signed immediate 20-bit value. 22781 'Ihig' 22782 The immediate value that can be simply set high 20-bit. 22783 'Izeb' 22784 The immediate value 0xff. 22785 'Izeh' 22786 The immediate value 0xffff. 22787 'Ixls' 22788 The immediate value 0x01. 22789 'Ix11' 22790 The immediate value 0x7ff. 22791 'Ibms' 22792 The immediate value with power of 2. 22793 'Ifex' 22794 The immediate value with power of 2 minus 1. 22795 'U33' 22796 Memory constraint for 333 format. 22797 'U45' 22798 Memory constraint for 45 format. 22799 'U37' 22800 Memory constraint for 37 format. 22801 22802_Nios II family--'config/nios2/constraints.md'_ 22803 22804 'I' 22805 Integer that is valid as an immediate operand in an 22806 instruction taking a signed 16-bit number. Range -32768 to 22807 32767. 22808 22809 'J' 22810 Integer that is valid as an immediate operand in an 22811 instruction taking an unsigned 16-bit number. Range 0 to 22812 65535. 22813 22814 'K' 22815 Integer that is valid as an immediate operand in an 22816 instruction taking only the upper 16-bits of a 32-bit number. 22817 Range 32-bit numbers with the lower 16-bits being 0. 22818 22819 'L' 22820 Integer that is valid as an immediate operand for a shift 22821 instruction. Range 0 to 31. 22822 22823 'M' 22824 Integer that is valid as an immediate operand for only the 22825 value 0. Can be used in conjunction with the format modifier 22826 'z' to use 'r0' instead of '0' in the assembly output. 22827 22828 'N' 22829 Integer that is valid as an immediate operand for a custom 22830 instruction opcode. Range 0 to 255. 22831 22832 'P' 22833 An immediate operand for R2 andchi/andci instructions. 22834 22835 'S' 22836 Matches immediates which are addresses in the small data 22837 section and therefore can be added to 'gp' as a 16-bit 22838 immediate to re-create their 32-bit value. 22839 22840 'U' 22841 Matches constants suitable as an operand for the rdprs and 22842 cache instructions. 22843 22844 'v' 22845 A memory operand suitable for Nios II R2 load/store exclusive 22846 instructions. 22847 22848 'w' 22849 A memory operand suitable for load/store IO and cache 22850 instructions. 22851 22852 'T' 22853 A 'const' wrapped 'UNSPEC' expression, representing a 22854 supported PIC or TLS relocation. 22855 22856_PDP-11--'config/pdp11/constraints.md'_ 22857 'a' 22858 Floating point registers AC0 through AC3. These can be loaded 22859 from/to memory with a single instruction. 22860 22861 'd' 22862 Odd numbered general registers (R1, R3, R5). These are used 22863 for 16-bit multiply operations. 22864 22865 'f' 22866 Any of the floating point registers (AC0 through AC5). 22867 22868 'G' 22869 Floating point constant 0. 22870 22871 'I' 22872 An integer constant that fits in 16 bits. 22873 22874 'J' 22875 An integer constant whose low order 16 bits are zero. 22876 22877 'K' 22878 An integer constant that does not meet the constraints for 22879 codes 'I' or 'J'. 22880 22881 'L' 22882 The integer constant 1. 22883 22884 'M' 22885 The integer constant -1. 22886 22887 'N' 22888 The integer constant 0. 22889 22890 'O' 22891 Integer constants -4 through -1 and 1 through 4; shifts by 22892 these amounts are handled as multiple single-bit shifts rather 22893 than a single variable-length shift. 22894 22895 'Q' 22896 A memory reference which requires an additional word (address 22897 or offset) after the opcode. 22898 22899 'R' 22900 A memory reference that is encoded within the opcode. 22901 22902_PowerPC and IBM RS6000--'config/rs6000/constraints.md'_ 22903 'b' 22904 Address base register 22905 22906 'd' 22907 Floating point register (containing 64-bit value) 22908 22909 'f' 22910 Floating point register (containing 32-bit value) 22911 22912 'v' 22913 Altivec vector register 22914 22915 'wa' 22916 Any VSX register if the '-mvsx' option was used or NO_REGS. 22917 22918 When using any of the register constraints ('wa', 'wd', 'wf', 22919 'wg', 'wh', 'wi', 'wj', 'wk', 'wl', 'wm', 'wo', 'wp', 'wq', 22920 'ws', 'wt', 'wu', 'wv', 'ww', or 'wy') that take VSX 22921 registers, you must use '%x<n>' in the template so that the 22922 correct register is used. Otherwise the register number 22923 output in the assembly file will be incorrect if an Altivec 22924 register is an operand of a VSX instruction that expects VSX 22925 register numbering. 22926 22927 asm ("xvadddp %x0,%x1,%x2" 22928 : "=wa" (v1) 22929 : "wa" (v2), "wa" (v3)); 22930 22931 is correct, but: 22932 22933 asm ("xvadddp %0,%1,%2" 22934 : "=wa" (v1) 22935 : "wa" (v2), "wa" (v3)); 22936 22937 is not correct. 22938 22939 If an instruction only takes Altivec registers, you do not 22940 want to use '%x<n>'. 22941 22942 asm ("xsaddqp %0,%1,%2" 22943 : "=v" (v1) 22944 : "v" (v2), "v" (v3)); 22945 22946 is correct because the 'xsaddqp' instruction only takes 22947 Altivec registers, while: 22948 22949 asm ("xsaddqp %x0,%x1,%x2" 22950 : "=v" (v1) 22951 : "v" (v2), "v" (v3)); 22952 22953 is incorrect. 22954 22955 'wb' 22956 Altivec register if '-mcpu=power9' is used or NO_REGS. 22957 22958 'wd' 22959 VSX vector register to hold vector double data or NO_REGS. 22960 22961 'we' 22962 VSX register if the '-mcpu=power9' and '-m64' options were 22963 used or NO_REGS. 22964 22965 'wf' 22966 VSX vector register to hold vector float data or NO_REGS. 22967 22968 'wg' 22969 If '-mmfpgpr' was used, a floating point register or NO_REGS. 22970 22971 'wh' 22972 Floating point register if direct moves are available, or 22973 NO_REGS. 22974 22975 'wi' 22976 FP or VSX register to hold 64-bit integers for VSX insns or 22977 NO_REGS. 22978 22979 'wj' 22980 FP or VSX register to hold 64-bit integers for direct moves or 22981 NO_REGS. 22982 22983 'wk' 22984 FP or VSX register to hold 64-bit doubles for direct moves or 22985 NO_REGS. 22986 22987 'wl' 22988 Floating point register if the LFIWAX instruction is enabled 22989 or NO_REGS. 22990 22991 'wm' 22992 VSX register if direct move instructions are enabled, or 22993 NO_REGS. 22994 22995 'wn' 22996 No register (NO_REGS). 22997 22998 'wo' 22999 VSX register to use for ISA 3.0 vector instructions, or 23000 NO_REGS. 23001 23002 'wp' 23003 VSX register to use for IEEE 128-bit floating point TFmode, or 23004 NO_REGS. 23005 23006 'wq' 23007 VSX register to use for IEEE 128-bit floating point, or 23008 NO_REGS. 23009 23010 'wr' 23011 General purpose register if 64-bit instructions are enabled or 23012 NO_REGS. 23013 23014 'ws' 23015 VSX vector register to hold scalar double values or NO_REGS. 23016 23017 'wt' 23018 VSX vector register to hold 128 bit integer or NO_REGS. 23019 23020 'wu' 23021 Altivec register to use for float/32-bit int loads/stores or 23022 NO_REGS. 23023 23024 'wv' 23025 Altivec register to use for double loads/stores or NO_REGS. 23026 23027 'ww' 23028 FP or VSX register to perform float operations under '-mvsx' 23029 or NO_REGS. 23030 23031 'wx' 23032 Floating point register if the STFIWX instruction is enabled 23033 or NO_REGS. 23034 23035 'wy' 23036 FP or VSX register to perform ISA 2.07 float ops or NO_REGS. 23037 23038 'wz' 23039 Floating point register if the LFIWZX instruction is enabled 23040 or NO_REGS. 23041 23042 'wA' 23043 Address base register if 64-bit instructions are enabled or 23044 NO_REGS. 23045 23046 'wB' 23047 Signed 5-bit constant integer that can be loaded into an 23048 altivec register. 23049 23050 'wD' 23051 Int constant that is the element number of the 64-bit scalar 23052 in a vector. 23053 23054 'wE' 23055 Vector constant that can be loaded with the XXSPLTIB 23056 instruction. 23057 23058 'wF' 23059 Memory operand suitable for power9 fusion load/stores. 23060 23061 'wG' 23062 Memory operand suitable for TOC fusion memory references. 23063 23064 'wH' 23065 Altivec register if '-mvsx-small-integer'. 23066 23067 'wI' 23068 Floating point register if '-mvsx-small-integer'. 23069 23070 'wJ' 23071 FP register if '-mvsx-small-integer' and '-mpower9-vector'. 23072 23073 'wK' 23074 Altivec register if '-mvsx-small-integer' and 23075 '-mpower9-vector'. 23076 23077 'wL' 23078 Int constant that is the element number that the MFVSRLD 23079 instruction. targets. 23080 23081 'wM' 23082 Match vector constant with all 1's if the XXLORC instruction 23083 is available. 23084 23085 'wO' 23086 A memory operand suitable for the ISA 3.0 vector d-form 23087 instructions. 23088 23089 'wQ' 23090 A memory address that will work with the 'lq' and 'stq' 23091 instructions. 23092 23093 'wS' 23094 Vector constant that can be loaded with XXSPLTIB & sign 23095 extension. 23096 23097 'h' 23098 'MQ', 'CTR', or 'LINK' register 23099 23100 'c' 23101 'CTR' register 23102 23103 'l' 23104 'LINK' register 23105 23106 'x' 23107 'CR' register (condition register) number 0 23108 23109 'y' 23110 'CR' register (condition register) 23111 23112 'z' 23113 'XER[CA]' carry bit (part of the XER register) 23114 23115 'I' 23116 Signed 16-bit constant 23117 23118 'J' 23119 Unsigned 16-bit constant shifted left 16 bits (use 'L' instead 23120 for 'SImode' constants) 23121 23122 'K' 23123 Unsigned 16-bit constant 23124 23125 'L' 23126 Signed 16-bit constant shifted left 16 bits 23127 23128 'M' 23129 Constant larger than 31 23130 23131 'N' 23132 Exact power of 2 23133 23134 'O' 23135 Zero 23136 23137 'P' 23138 Constant whose negation is a signed 16-bit constant 23139 23140 'G' 23141 Floating point constant that can be loaded into a register 23142 with one instruction per word 23143 23144 'H' 23145 Integer/Floating point constant that can be loaded into a 23146 register using three instructions 23147 23148 'm' 23149 Memory operand. Normally, 'm' does not allow addresses that 23150 update the base register. If '<' or '>' constraint is also 23151 used, they are allowed and therefore on PowerPC targets in 23152 that case it is only safe to use 'm<>' in an 'asm' statement 23153 if that 'asm' statement accesses the operand exactly once. 23154 The 'asm' statement must also use '%U<OPNO>' as a placeholder 23155 for the "update" flag in the corresponding load or store 23156 instruction. For example: 23157 23158 asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val)); 23159 23160 is correct but: 23161 23162 asm ("st %1,%0" : "=m<>" (mem) : "r" (val)); 23163 23164 is not. 23165 23166 'es' 23167 A "stable" memory operand; that is, one which does not include 23168 any automodification of the base register. This used to be 23169 useful when 'm' allowed automodification of the base register, 23170 but as those are now only allowed when '<' or '>' is used, 23171 'es' is basically the same as 'm' without '<' and '>'. 23172 23173 'Q' 23174 Memory operand that is an offset from a register (it is 23175 usually better to use 'm' or 'es' in 'asm' statements) 23176 23177 'Z' 23178 Memory operand that is an indexed or indirect from a register 23179 (it is usually better to use 'm' or 'es' in 'asm' statements) 23180 23181 'R' 23182 AIX TOC entry 23183 23184 'a' 23185 Address operand that is an indexed or indirect from a register 23186 ('p' is preferable for 'asm' statements) 23187 23188 'U' 23189 System V Release 4 small data area reference 23190 23191 'W' 23192 Vector constant that does not require memory 23193 23194 'j' 23195 Vector constant that is all zeros. 23196 23197_RL78--'config/rl78/constraints.md'_ 23198 23199 'Int3' 23200 An integer constant in the range 1 ... 7. 23201 'Int8' 23202 An integer constant in the range 0 ... 255. 23203 'J' 23204 An integer constant in the range -255 ... 0 23205 'K' 23206 The integer constant 1. 23207 'L' 23208 The integer constant -1. 23209 'M' 23210 The integer constant 0. 23211 'N' 23212 The integer constant 2. 23213 'O' 23214 The integer constant -2. 23215 'P' 23216 An integer constant in the range 1 ... 15. 23217 'Qbi' 23218 The built-in compare types-eq, ne, gtu, ltu, geu, and leu. 23219 'Qsc' 23220 The synthetic compare types-gt, lt, ge, and le. 23221 'Wab' 23222 A memory reference with an absolute address. 23223 'Wbc' 23224 A memory reference using 'BC' as a base register, with an 23225 optional offset. 23226 'Wca' 23227 A memory reference using 'AX', 'BC', 'DE', or 'HL' for the 23228 address, for calls. 23229 'Wcv' 23230 A memory reference using any 16-bit register pair for the 23231 address, for calls. 23232 'Wd2' 23233 A memory reference using 'DE' as a base register, with an 23234 optional offset. 23235 'Wde' 23236 A memory reference using 'DE' as a base register, without any 23237 offset. 23238 'Wfr' 23239 Any memory reference to an address in the far address space. 23240 'Wh1' 23241 A memory reference using 'HL' as a base register, with an 23242 optional one-byte offset. 23243 'Whb' 23244 A memory reference using 'HL' as a base register, with 'B' or 23245 'C' as the index register. 23246 'Whl' 23247 A memory reference using 'HL' as a base register, without any 23248 offset. 23249 'Ws1' 23250 A memory reference using 'SP' as a base register, with an 23251 optional one-byte offset. 23252 'Y' 23253 Any memory reference to an address in the near address space. 23254 'A' 23255 The 'AX' register. 23256 'B' 23257 The 'BC' register. 23258 'D' 23259 The 'DE' register. 23260 'R' 23261 'A' through 'L' registers. 23262 'S' 23263 The 'SP' register. 23264 'T' 23265 The 'HL' register. 23266 'Z08W' 23267 The 16-bit 'R8' register. 23268 'Z10W' 23269 The 16-bit 'R10' register. 23270 'Zint' 23271 The registers reserved for interrupts ('R24' to 'R31'). 23272 'a' 23273 The 'A' register. 23274 'b' 23275 The 'B' register. 23276 'c' 23277 The 'C' register. 23278 'd' 23279 The 'D' register. 23280 'e' 23281 The 'E' register. 23282 'h' 23283 The 'H' register. 23284 'l' 23285 The 'L' register. 23286 'v' 23287 The virtual registers. 23288 'w' 23289 The 'PSW' register. 23290 'x' 23291 The 'X' register. 23292 23293_RISC-V--'config/riscv/constraints.md'_ 23294 23295 'f' 23296 A floating-point register (if availiable). 23297 23298 'I' 23299 An I-type 12-bit signed immediate. 23300 23301 'J' 23302 Integer zero. 23303 23304 'K' 23305 A 5-bit unsigned immediate for CSR access instructions. 23306 23307 'A' 23308 An address that is held in a general-purpose register. 23309 23310_RX--'config/rx/constraints.md'_ 23311 'Q' 23312 An address which does not involve register indirect addressing 23313 or pre/post increment/decrement addressing. 23314 23315 'Symbol' 23316 A symbol reference. 23317 23318 'Int08' 23319 A constant in the range -256 to 255, inclusive. 23320 23321 'Sint08' 23322 A constant in the range -128 to 127, inclusive. 23323 23324 'Sint16' 23325 A constant in the range -32768 to 32767, inclusive. 23326 23327 'Sint24' 23328 A constant in the range -8388608 to 8388607, inclusive. 23329 23330 'Uint04' 23331 A constant in the range 0 to 15, inclusive. 23332 23333_S/390 and zSeries--'config/s390/s390.h'_ 23334 'a' 23335 Address register (general purpose register except r0) 23336 23337 'c' 23338 Condition code register 23339 23340 'd' 23341 Data register (arbitrary general purpose register) 23342 23343 'f' 23344 Floating-point register 23345 23346 'I' 23347 Unsigned 8-bit constant (0-255) 23348 23349 'J' 23350 Unsigned 12-bit constant (0-4095) 23351 23352 'K' 23353 Signed 16-bit constant (-32768-32767) 23354 23355 'L' 23356 Value appropriate as displacement. 23357 '(0..4095)' 23358 for short displacement 23359 '(-524288..524287)' 23360 for long displacement 23361 23362 'M' 23363 Constant integer with a value of 0x7fffffff. 23364 23365 'N' 23366 Multiple letter constraint followed by 4 parameter letters. 23367 '0..9:' 23368 number of the part counting from most to least 23369 significant 23370 'H,Q:' 23371 mode of the part 23372 'D,S,H:' 23373 mode of the containing operand 23374 '0,F:' 23375 value of the other parts (F--all bits set) 23376 The constraint matches if the specified part of a constant has 23377 a value different from its other parts. 23378 23379 'Q' 23380 Memory reference without index register and with short 23381 displacement. 23382 23383 'R' 23384 Memory reference with index register and short displacement. 23385 23386 'S' 23387 Memory reference without index register but with long 23388 displacement. 23389 23390 'T' 23391 Memory reference with index register and long displacement. 23392 23393 'U' 23394 Pointer with short displacement. 23395 23396 'W' 23397 Pointer with long displacement. 23398 23399 'Y' 23400 Shift count operand. 23401 23402_SPARC--'config/sparc/sparc.h'_ 23403 'f' 23404 Floating-point register on the SPARC-V8 architecture and lower 23405 floating-point register on the SPARC-V9 architecture. 23406 23407 'e' 23408 Floating-point register. It is equivalent to 'f' on the 23409 SPARC-V8 architecture and contains both lower and upper 23410 floating-point registers on the SPARC-V9 architecture. 23411 23412 'c' 23413 Floating-point condition code register. 23414 23415 'd' 23416 Lower floating-point register. It is only valid on the 23417 SPARC-V9 architecture when the Visual Instruction Set is 23418 available. 23419 23420 'b' 23421 Floating-point register. It is only valid on the SPARC-V9 23422 architecture when the Visual Instruction Set is available. 23423 23424 'h' 23425 64-bit global or out register for the SPARC-V8+ architecture. 23426 23427 'C' 23428 The constant all-ones, for floating-point. 23429 23430 'A' 23431 Signed 5-bit constant 23432 23433 'D' 23434 A vector constant 23435 23436 'I' 23437 Signed 13-bit constant 23438 23439 'J' 23440 Zero 23441 23442 'K' 23443 32-bit constant with the low 12 bits clear (a constant that 23444 can be loaded with the 'sethi' instruction) 23445 23446 'L' 23447 A constant in the range supported by 'movcc' instructions 23448 (11-bit signed immediate) 23449 23450 'M' 23451 A constant in the range supported by 'movrcc' instructions 23452 (10-bit signed immediate) 23453 23454 'N' 23455 Same as 'K', except that it verifies that bits that are not in 23456 the lower 32-bit range are all zero. Must be used instead of 23457 'K' for modes wider than 'SImode' 23458 23459 'O' 23460 The constant 4096 23461 23462 'G' 23463 Floating-point zero 23464 23465 'H' 23466 Signed 13-bit constant, sign-extended to 32 or 64 bits 23467 23468 'P' 23469 The constant -1 23470 23471 'Q' 23472 Floating-point constant whose integral representation can be 23473 moved into an integer register using a single sethi 23474 instruction 23475 23476 'R' 23477 Floating-point constant whose integral representation can be 23478 moved into an integer register using a single mov instruction 23479 23480 'S' 23481 Floating-point constant whose integral representation can be 23482 moved into an integer register using a high/lo_sum instruction 23483 sequence 23484 23485 'T' 23486 Memory address aligned to an 8-byte boundary 23487 23488 'U' 23489 Even register 23490 23491 'W' 23492 Memory address for 'e' constraint registers 23493 23494 'w' 23495 Memory address with only a base register 23496 23497 'Y' 23498 Vector zero 23499 23500_SPU--'config/spu/spu.h'_ 23501 'a' 23502 An immediate which can be loaded with the il/ila/ilh/ilhu 23503 instructions. const_int is treated as a 64 bit value. 23504 23505 'c' 23506 An immediate for and/xor/or instructions. const_int is 23507 treated as a 64 bit value. 23508 23509 'd' 23510 An immediate for the 'iohl' instruction. const_int is treated 23511 as a 64 bit value. 23512 23513 'f' 23514 An immediate which can be loaded with 'fsmbi'. 23515 23516 'A' 23517 An immediate which can be loaded with the il/ila/ilh/ilhu 23518 instructions. const_int is treated as a 32 bit value. 23519 23520 'B' 23521 An immediate for most arithmetic instructions. const_int is 23522 treated as a 32 bit value. 23523 23524 'C' 23525 An immediate for and/xor/or instructions. const_int is 23526 treated as a 32 bit value. 23527 23528 'D' 23529 An immediate for the 'iohl' instruction. const_int is treated 23530 as a 32 bit value. 23531 23532 'I' 23533 A constant in the range [-64, 63] for shift/rotate 23534 instructions. 23535 23536 'J' 23537 An unsigned 7-bit constant for conversion/nop/channel 23538 instructions. 23539 23540 'K' 23541 A signed 10-bit constant for most arithmetic instructions. 23542 23543 'M' 23544 A signed 16 bit immediate for 'stop'. 23545 23546 'N' 23547 An unsigned 16-bit constant for 'iohl' and 'fsmbi'. 23548 23549 'O' 23550 An unsigned 7-bit constant whose 3 least significant bits are 23551 0. 23552 23553 'P' 23554 An unsigned 3-bit constant for 16-byte rotates and shifts 23555 23556 'R' 23557 Call operand, reg, for indirect calls 23558 23559 'S' 23560 Call operand, symbol, for relative calls. 23561 23562 'T' 23563 Call operand, const_int, for absolute calls. 23564 23565 'U' 23566 An immediate which can be loaded with the il/ila/ilh/ilhu 23567 instructions. const_int is sign extended to 128 bit. 23568 23569 'W' 23570 An immediate for shift and rotate instructions. const_int is 23571 treated as a 32 bit value. 23572 23573 'Y' 23574 An immediate for and/xor/or instructions. const_int is sign 23575 extended as a 128 bit. 23576 23577 'Z' 23578 An immediate for the 'iohl' instruction. const_int is sign 23579 extended to 128 bit. 23580 23581_TI C6X family--'config/c6x/constraints.md'_ 23582 'a' 23583 Register file A (A0-A31). 23584 23585 'b' 23586 Register file B (B0-B31). 23587 23588 'A' 23589 Predicate registers in register file A (A0-A2 on C64X and 23590 higher, A1 and A2 otherwise). 23591 23592 'B' 23593 Predicate registers in register file B (B0-B2). 23594 23595 'C' 23596 A call-used register in register file B (B0-B9, B16-B31). 23597 23598 'Da' 23599 Register file A, excluding predicate registers (A3-A31, plus 23600 A0 if not C64X or higher). 23601 23602 'Db' 23603 Register file B, excluding predicate registers (B3-B31). 23604 23605 'Iu4' 23606 Integer constant in the range 0 ... 15. 23607 23608 'Iu5' 23609 Integer constant in the range 0 ... 31. 23610 23611 'In5' 23612 Integer constant in the range -31 ... 0. 23613 23614 'Is5' 23615 Integer constant in the range -16 ... 15. 23616 23617 'I5x' 23618 Integer constant that can be the operand of an ADDA or a SUBA 23619 insn. 23620 23621 'IuB' 23622 Integer constant in the range 0 ... 65535. 23623 23624 'IsB' 23625 Integer constant in the range -32768 ... 32767. 23626 23627 'IsC' 23628 Integer constant in the range -2^{20} ... 2^{20} - 1. 23629 23630 'Jc' 23631 Integer constant that is a valid mask for the clr instruction. 23632 23633 'Js' 23634 Integer constant that is a valid mask for the set instruction. 23635 23636 'Q' 23637 Memory location with A base register. 23638 23639 'R' 23640 Memory location with B base register. 23641 23642 'S0' 23643 On C64x+ targets, a GP-relative small data reference. 23644 23645 'S1' 23646 Any kind of 'SYMBOL_REF', for use in a call address. 23647 23648 'Si' 23649 Any kind of immediate operand, unless it matches the S0 23650 constraint. 23651 23652 'T' 23653 Memory location with B base register, but not using a long 23654 offset. 23655 23656 'W' 23657 A memory operand with an address that cannot be used in an 23658 unaligned access. 23659 23660 'Z' 23661 Register B14 (aka DP). 23662 23663_TILE-Gx--'config/tilegx/constraints.md'_ 23664 'R00' 23665 'R01' 23666 'R02' 23667 'R03' 23668 'R04' 23669 'R05' 23670 'R06' 23671 'R07' 23672 'R08' 23673 'R09' 23674 'R10' 23675 Each of these represents a register constraint for an 23676 individual register, from r0 to r10. 23677 23678 'I' 23679 Signed 8-bit integer constant. 23680 23681 'J' 23682 Signed 16-bit integer constant. 23683 23684 'K' 23685 Unsigned 16-bit integer constant. 23686 23687 'L' 23688 Integer constant that fits in one signed byte when incremented 23689 by one (-129 ... 126). 23690 23691 'm' 23692 Memory operand. If used together with '<' or '>', the operand 23693 can have postincrement which requires printing with '%In' and 23694 '%in' on TILE-Gx. For example: 23695 23696 asm ("st_add %I0,%1,%i0" : "=m<>" (*mem) : "r" (val)); 23697 23698 'M' 23699 A bit mask suitable for the BFINS instruction. 23700 23701 'N' 23702 Integer constant that is a byte tiled out eight times. 23703 23704 'O' 23705 The integer zero constant. 23706 23707 'P' 23708 Integer constant that is a sign-extended byte tiled out as 23709 four shorts. 23710 23711 'Q' 23712 Integer constant that fits in one signed byte when incremented 23713 (-129 ... 126), but excluding -1. 23714 23715 'S' 23716 Integer constant that has all 1 bits consecutive and starting 23717 at bit 0. 23718 23719 'T' 23720 A 16-bit fragment of a got, tls, or pc-relative reference. 23721 23722 'U' 23723 Memory operand except postincrement. This is roughly the same 23724 as 'm' when not used together with '<' or '>'. 23725 23726 'W' 23727 An 8-element vector constant with identical elements. 23728 23729 'Y' 23730 A 4-element vector constant with identical elements. 23731 23732 'Z0' 23733 The integer constant 0xffffffff. 23734 23735 'Z1' 23736 The integer constant 0xffffffff00000000. 23737 23738_TILEPro--'config/tilepro/constraints.md'_ 23739 'R00' 23740 'R01' 23741 'R02' 23742 'R03' 23743 'R04' 23744 'R05' 23745 'R06' 23746 'R07' 23747 'R08' 23748 'R09' 23749 'R10' 23750 Each of these represents a register constraint for an 23751 individual register, from r0 to r10. 23752 23753 'I' 23754 Signed 8-bit integer constant. 23755 23756 'J' 23757 Signed 16-bit integer constant. 23758 23759 'K' 23760 Nonzero integer constant with low 16 bits zero. 23761 23762 'L' 23763 Integer constant that fits in one signed byte when incremented 23764 by one (-129 ... 126). 23765 23766 'm' 23767 Memory operand. If used together with '<' or '>', the operand 23768 can have postincrement which requires printing with '%In' and 23769 '%in' on TILEPro. For example: 23770 23771 asm ("swadd %I0,%1,%i0" : "=m<>" (mem) : "r" (val)); 23772 23773 'M' 23774 A bit mask suitable for the MM instruction. 23775 23776 'N' 23777 Integer constant that is a byte tiled out four times. 23778 23779 'O' 23780 The integer zero constant. 23781 23782 'P' 23783 Integer constant that is a sign-extended byte tiled out as two 23784 shorts. 23785 23786 'Q' 23787 Integer constant that fits in one signed byte when incremented 23788 (-129 ... 126), but excluding -1. 23789 23790 'T' 23791 A symbolic operand, or a 16-bit fragment of a got, tls, or 23792 pc-relative reference. 23793 23794 'U' 23795 Memory operand except postincrement. This is roughly the same 23796 as 'm' when not used together with '<' or '>'. 23797 23798 'W' 23799 A 4-element vector constant with identical elements. 23800 23801 'Y' 23802 A 2-element vector constant with identical elements. 23803 23804_Visium--'config/visium/constraints.md'_ 23805 'b' 23806 EAM register 'mdb' 23807 23808 'c' 23809 EAM register 'mdc' 23810 23811 'f' 23812 Floating point register 23813 23814 'k' 23815 Register for sibcall optimization 23816 23817 'l' 23818 General register, but not 'r29', 'r30' and 'r31' 23819 23820 't' 23821 Register 'r1' 23822 23823 'u' 23824 Register 'r2' 23825 23826 'v' 23827 Register 'r3' 23828 23829 'G' 23830 Floating-point constant 0.0 23831 23832 'J' 23833 Integer constant in the range 0 .. 65535 (16-bit immediate) 23834 23835 'K' 23836 Integer constant in the range 1 .. 31 (5-bit immediate) 23837 23838 'L' 23839 Integer constant in the range -65535 .. -1 (16-bit negative 23840 immediate) 23841 23842 'M' 23843 Integer constant -1 23844 23845 'O' 23846 Integer constant 0 23847 23848 'P' 23849 Integer constant 32 23850 23851_x86 family--'config/i386/constraints.md'_ 23852 'R' 23853 Legacy register--the eight integer registers available on all 23854 i386 processors ('a', 'b', 'c', 'd', 'si', 'di', 'bp', 'sp'). 23855 23856 'q' 23857 Any register accessible as 'Rl'. In 32-bit mode, 'a', 'b', 23858 'c', and 'd'; in 64-bit mode, any integer register. 23859 23860 'Q' 23861 Any register accessible as 'Rh': 'a', 'b', 'c', and 'd'. 23862 23863 'l' 23864 Any register that can be used as the index in a base+index 23865 memory access: that is, any general register except the stack 23866 pointer. 23867 23868 'a' 23869 The 'a' register. 23870 23871 'b' 23872 The 'b' register. 23873 23874 'c' 23875 The 'c' register. 23876 23877 'd' 23878 The 'd' register. 23879 23880 'S' 23881 The 'si' register. 23882 23883 'D' 23884 The 'di' register. 23885 23886 'A' 23887 The 'a' and 'd' registers. This class is used for 23888 instructions that return double word results in the 'ax:dx' 23889 register pair. Single word values will be allocated either in 23890 'ax' or 'dx'. For example on i386 the following implements 23891 'rdtsc': 23892 23893 unsigned long long rdtsc (void) 23894 { 23895 unsigned long long tick; 23896 __asm__ __volatile__("rdtsc":"=A"(tick)); 23897 return tick; 23898 } 23899 23900 This is not correct on x86-64 as it would allocate tick in 23901 either 'ax' or 'dx'. You have to use the following variant 23902 instead: 23903 23904 unsigned long long rdtsc (void) 23905 { 23906 unsigned int tickl, tickh; 23907 __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh)); 23908 return ((unsigned long long)tickh << 32)|tickl; 23909 } 23910 23911 'U' 23912 The call-clobbered integer registers. 23913 23914 'f' 23915 Any 80387 floating-point (stack) register. 23916 23917 't' 23918 Top of 80387 floating-point stack ('%st(0)'). 23919 23920 'u' 23921 Second from top of 80387 floating-point stack ('%st(1)'). 23922 23923 'Yk' 23924 Any mask register that can be used as a predicate, i.e. 23925 'k1-k7'. 23926 23927 'k' 23928 Any mask register. 23929 23930 'y' 23931 Any MMX register. 23932 23933 'x' 23934 Any SSE register. 23935 23936 'v' 23937 Any EVEX encodable SSE register ('%xmm0-%xmm31'). 23938 23939 'w' 23940 Any bound register. 23941 23942 'Yz' 23943 First SSE register ('%xmm0'). 23944 23945 'Yi' 23946 Any SSE register, when SSE2 and inter-unit moves are enabled. 23947 23948 'Yj' 23949 Any SSE register, when SSE2 and inter-unit moves from vector 23950 registers are enabled. 23951 23952 'Ym' 23953 Any MMX register, when inter-unit moves are enabled. 23954 23955 'Yn' 23956 Any MMX register, when inter-unit moves from vector registers 23957 are enabled. 23958 23959 'Yp' 23960 Any integer register when 'TARGET_PARTIAL_REG_STALL' is 23961 disabled. 23962 23963 'Ya' 23964 Any integer register when zero extensions with 'AND' are 23965 disabled. 23966 23967 'Yb' 23968 Any register that can be used as the GOT base when calling 23969 '___tls_get_addr': that is, any general register except 'a' 23970 and 'sp' registers, for '-fno-plt' if linker supports it. 23971 Otherwise, 'b' register. 23972 23973 'Yf' 23974 Any x87 register when 80387 floating-point arithmetic is 23975 enabled. 23976 23977 'Yr' 23978 Lower SSE register when avoiding REX prefix and all SSE 23979 registers otherwise. 23980 23981 'Yv' 23982 For AVX512VL, any EVEX-encodable SSE register 23983 ('%xmm0-%xmm31'), otherwise any SSE register. 23984 23985 'Yh' 23986 Any EVEX-encodable SSE register, that has number factor of 23987 four. 23988 23989 'Bf' 23990 Flags register operand. 23991 23992 'Bg' 23993 GOT memory operand. 23994 23995 'Bm' 23996 Vector memory operand. 23997 23998 'Bc' 23999 Constant memory operand. 24000 24001 'Bn' 24002 Memory operand without REX prefix. 24003 24004 'Bs' 24005 Sibcall memory operand. 24006 24007 'Bw' 24008 Call memory operand. 24009 24010 'Bz' 24011 Constant call address operand. 24012 24013 'BC' 24014 SSE constant -1 operand. 24015 24016 'I' 24017 Integer constant in the range 0 ... 31, for 32-bit shifts. 24018 24019 'J' 24020 Integer constant in the range 0 ... 63, for 64-bit shifts. 24021 24022 'K' 24023 Signed 8-bit integer constant. 24024 24025 'L' 24026 '0xFF' or '0xFFFF', for andsi as a zero-extending move. 24027 24028 'M' 24029 0, 1, 2, or 3 (shifts for the 'lea' instruction). 24030 24031 'N' 24032 Unsigned 8-bit integer constant (for 'in' and 'out' 24033 instructions). 24034 24035 'O' 24036 Integer constant in the range 0 ... 127, for 128-bit shifts. 24037 24038 'G' 24039 Standard 80387 floating point constant. 24040 24041 'C' 24042 SSE constant zero operand. 24043 24044 'e' 24045 32-bit signed integer constant, or a symbolic reference known 24046 to fit that range (for immediate operands in sign-extending 24047 x86-64 instructions). 24048 24049 'We' 24050 32-bit signed integer constant, or a symbolic reference known 24051 to fit that range (for sign-extending conversion operations 24052 that require non-'VOIDmode' immediate operands). 24053 24054 'Wz' 24055 32-bit unsigned integer constant, or a symbolic reference 24056 known to fit that range (for zero-extending conversion 24057 operations that require non-'VOIDmode' immediate operands). 24058 24059 'Wd' 24060 128-bit integer constant where both the high and low 64-bit 24061 word satisfy the 'e' constraint. 24062 24063 'Z' 24064 32-bit unsigned integer constant, or a symbolic reference 24065 known to fit that range (for immediate operands in 24066 zero-extending x86-64 instructions). 24067 24068 'Tv' 24069 VSIB address operand. 24070 24071 'Ts' 24072 Address operand without segment register. 24073 24074 'Ti' 24075 MPX address operand without index. 24076 24077 'Tb' 24078 MPX address operand without base. 24079 24080_Xstormy16--'config/stormy16/stormy16.h'_ 24081 'a' 24082 Register r0. 24083 24084 'b' 24085 Register r1. 24086 24087 'c' 24088 Register r2. 24089 24090 'd' 24091 Register r8. 24092 24093 'e' 24094 Registers r0 through r7. 24095 24096 't' 24097 Registers r0 and r1. 24098 24099 'y' 24100 The carry register. 24101 24102 'z' 24103 Registers r8 and r9. 24104 24105 'I' 24106 A constant between 0 and 3 inclusive. 24107 24108 'J' 24109 A constant that has exactly one bit set. 24110 24111 'K' 24112 A constant that has exactly one bit clear. 24113 24114 'L' 24115 A constant between 0 and 255 inclusive. 24116 24117 'M' 24118 A constant between -255 and 0 inclusive. 24119 24120 'N' 24121 A constant between -3 and 0 inclusive. 24122 24123 'O' 24124 A constant between 1 and 4 inclusive. 24125 24126 'P' 24127 A constant between -4 and -1 inclusive. 24128 24129 'Q' 24130 A memory reference that is a stack push. 24131 24132 'R' 24133 A memory reference that is a stack pop. 24134 24135 'S' 24136 A memory reference that refers to a constant address of known 24137 value. 24138 24139 'T' 24140 The register indicated by Rx (not implemented yet). 24141 24142 'U' 24143 A constant that is not between 2 and 15 inclusive. 24144 24145 'Z' 24146 The constant 0. 24147 24148_Xtensa--'config/xtensa/constraints.md'_ 24149 'a' 24150 General-purpose 32-bit register 24151 24152 'b' 24153 One-bit boolean register 24154 24155 'A' 24156 MAC16 40-bit accumulator register 24157 24158 'I' 24159 Signed 12-bit integer constant, for use in MOVI instructions 24160 24161 'J' 24162 Signed 8-bit integer constant, for use in ADDI instructions 24163 24164 'K' 24165 Integer constant valid for BccI instructions 24166 24167 'L' 24168 Unsigned constant valid for BccUI instructions 24169 24170 24171File: gccint.info, Node: Disable Insn Alternatives, Next: Define Constraints, Prev: Machine Constraints, Up: Constraints 24172 2417317.8.6 Disable insn alternatives using the 'enabled' attribute 24174-------------------------------------------------------------- 24175 24176There are three insn attributes that may be used to selectively disable 24177instruction alternatives: 24178 24179'enabled' 24180 Says whether an alternative is available on the current subtarget. 24181 24182'preferred_for_size' 24183 Says whether an enabled alternative should be used in code that is 24184 optimized for size. 24185 24186'preferred_for_speed' 24187 Says whether an enabled alternative should be used in code that is 24188 optimized for speed. 24189 24190 All these attributes should use '(const_int 1)' to allow an alternative 24191or '(const_int 0)' to disallow it. The attributes must be a static 24192property of the subtarget; they cannot for example depend on the current 24193operands, on the current optimization level, on the location of the insn 24194within the body of a loop, on whether register allocation has finished, 24195or on the current compiler pass. 24196 24197 The 'enabled' attribute is a correctness property. It tells GCC to act 24198as though the disabled alternatives were never defined in the first 24199place. This is useful when adding new instructions to an existing 24200pattern in cases where the new instructions are only available for 24201certain cpu architecture levels (typically mapped to the '-march=' 24202command-line option). 24203 24204 In contrast, the 'preferred_for_size' and 'preferred_for_speed' 24205attributes are strong optimization hints rather than correctness 24206properties. 'preferred_for_size' tells GCC which alternatives to 24207consider when adding or modifying an instruction that GCC wants to 24208optimize for size. 'preferred_for_speed' does the same thing for speed. 24209Note that things like code motion can lead to cases where code optimized 24210for size uses alternatives that are not preferred for size, and 24211similarly for speed. 24212 24213 Although 'define_insn's can in principle specify the 'enabled' 24214attribute directly, it is often clearer to have subsiduary attributes 24215for each architectural feature of interest. The 'define_insn's can then 24216use these subsiduary attributes to say which alternatives require which 24217features. The example below does this for 'cpu_facility'. 24218 24219 E.g. the following two patterns could easily be merged using the 24220'enabled' attribute: 24221 24222 24223 (define_insn "*movdi_old" 24224 [(set (match_operand:DI 0 "register_operand" "=d") 24225 (match_operand:DI 1 "register_operand" " d"))] 24226 "!TARGET_NEW" 24227 "lgr %0,%1") 24228 24229 (define_insn "*movdi_new" 24230 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 24231 (match_operand:DI 1 "register_operand" " d,d,f"))] 24232 "TARGET_NEW" 24233 "@ 24234 lgr %0,%1 24235 ldgr %0,%1 24236 lgdr %0,%1") 24237 24238 24239 to: 24240 24241 24242 (define_insn "*movdi_combined" 24243 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 24244 (match_operand:DI 1 "register_operand" " d,d,f"))] 24245 "" 24246 "@ 24247 lgr %0,%1 24248 ldgr %0,%1 24249 lgdr %0,%1" 24250 [(set_attr "cpu_facility" "*,new,new")]) 24251 24252 24253 with the 'enabled' attribute defined like this: 24254 24255 24256 (define_attr "cpu_facility" "standard,new" (const_string "standard")) 24257 24258 (define_attr "enabled" "" 24259 (cond [(eq_attr "cpu_facility" "standard") (const_int 1) 24260 (and (eq_attr "cpu_facility" "new") 24261 (ne (symbol_ref "TARGET_NEW") (const_int 0))) 24262 (const_int 1)] 24263 (const_int 0))) 24264 24265 24266 24267File: gccint.info, Node: Define Constraints, Next: C Constraint Interface, Prev: Disable Insn Alternatives, Up: Constraints 24268 2426917.8.7 Defining Machine-Specific Constraints 24270-------------------------------------------- 24271 24272Machine-specific constraints fall into two categories: register and 24273non-register constraints. Within the latter category, constraints which 24274allow subsets of all possible memory or address operands should be 24275specially marked, to give 'reload' more information. 24276 24277 Machine-specific constraints can be given names of arbitrary length, 24278but they must be entirely composed of letters, digits, underscores 24279('_'), and angle brackets ('< >'). Like C identifiers, they must begin 24280with a letter or underscore. 24281 24282 In order to avoid ambiguity in operand constraint strings, no 24283constraint can have a name that begins with any other constraint's name. 24284For example, if 'x' is defined as a constraint name, 'xy' may not be, 24285and vice versa. As a consequence of this rule, no constraint may begin 24286with one of the generic constraint letters: 'E F V X g i m n o p r s'. 24287 24288 Register constraints correspond directly to register classes. *Note 24289Register Classes::. There is thus not much flexibility in their 24290definitions. 24291 24292 -- MD Expression: define_register_constraint name regclass docstring 24293 All three arguments are string constants. NAME is the name of the 24294 constraint, as it will appear in 'match_operand' expressions. If 24295 NAME is a multi-letter constraint its length shall be the same for 24296 all constraints starting with the same letter. REGCLASS can be 24297 either the name of the corresponding register class (*note Register 24298 Classes::), or a C expression which evaluates to the appropriate 24299 register class. If it is an expression, it must have no side 24300 effects, and it cannot look at the operand. The usual use of 24301 expressions is to map some register constraints to 'NO_REGS' when 24302 the register class is not available on a given subarchitecture. 24303 24304 DOCSTRING is a sentence documenting the meaning of the constraint. 24305 Docstrings are explained further below. 24306 24307 Non-register constraints are more like predicates: the constraint 24308definition gives a boolean expression which indicates whether the 24309constraint matches. 24310 24311 -- MD Expression: define_constraint name docstring exp 24312 The NAME and DOCSTRING arguments are the same as for 24313 'define_register_constraint', but note that the docstring comes 24314 immediately after the name for these expressions. EXP is an RTL 24315 expression, obeying the same rules as the RTL expressions in 24316 predicate definitions. *Note Defining Predicates::, for details. 24317 If it evaluates true, the constraint matches; if it evaluates 24318 false, it doesn't. Constraint expressions should indicate which 24319 RTL codes they might match, just like predicate expressions. 24320 24321 'match_test' C expressions have access to the following variables: 24322 24323 OP 24324 The RTL object defining the operand. 24325 MODE 24326 The machine mode of OP. 24327 IVAL 24328 'INTVAL (OP)', if OP is a 'const_int'. 24329 HVAL 24330 'CONST_DOUBLE_HIGH (OP)', if OP is an integer 'const_double'. 24331 LVAL 24332 'CONST_DOUBLE_LOW (OP)', if OP is an integer 'const_double'. 24333 RVAL 24334 'CONST_DOUBLE_REAL_VALUE (OP)', if OP is a floating-point 24335 'const_double'. 24336 24337 The *VAL variables should only be used once another piece of the 24338 expression has verified that OP is the appropriate kind of RTL 24339 object. 24340 24341 Most non-register constraints should be defined with 24342'define_constraint'. The remaining two definition expressions are only 24343appropriate for constraints that should be handled specially by 'reload' 24344if they fail to match. 24345 24346 -- MD Expression: define_memory_constraint name docstring exp 24347 Use this expression for constraints that match a subset of all 24348 memory operands: that is, 'reload' can make them match by 24349 converting the operand to the form '(mem (reg X))', where X is a 24350 base register (from the register class specified by 24351 'BASE_REG_CLASS', *note Register Classes::). 24352 24353 For example, on the S/390, some instructions do not accept 24354 arbitrary memory references, but only those that do not make use of 24355 an index register. The constraint letter 'Q' is defined to 24356 represent a memory address of this type. If 'Q' is defined with 24357 'define_memory_constraint', a 'Q' constraint can handle any memory 24358 operand, because 'reload' knows it can simply copy the memory 24359 address into a base register if required. This is analogous to the 24360 way an 'o' constraint can handle any memory operand. 24361 24362 The syntax and semantics are otherwise identical to 24363 'define_constraint'. 24364 24365 -- MD Expression: define_special_memory_constraint name docstring exp 24366 Use this expression for constraints that match a subset of all 24367 memory operands: that is, 'reload' can not make them match by 24368 reloading the address as it is described for 24369 'define_memory_constraint' or such address reload is undesirable 24370 with the performance point of view. 24371 24372 For example, 'define_special_memory_constraint' can be useful if 24373 specifically aligned memory is necessary or desirable for some insn 24374 operand. 24375 24376 The syntax and semantics are otherwise identical to 24377 'define_constraint'. 24378 24379 -- MD Expression: define_address_constraint name docstring exp 24380 Use this expression for constraints that match a subset of all 24381 address operands: that is, 'reload' can make the constraint match 24382 by converting the operand to the form '(reg X)', again with X a 24383 base register. 24384 24385 Constraints defined with 'define_address_constraint' can only be 24386 used with the 'address_operand' predicate, or machine-specific 24387 predicates that work the same way. They are treated analogously to 24388 the generic 'p' constraint. 24389 24390 The syntax and semantics are otherwise identical to 24391 'define_constraint'. 24392 24393 For historical reasons, names beginning with the letters 'G H' are 24394reserved for constraints that match only 'const_double's, and names 24395beginning with the letters 'I J K L M N O P' are reserved for 24396constraints that match only 'const_int's. This may change in the 24397future. For the time being, constraints with these names must be 24398written in a stylized form, so that 'genpreds' can tell you did it 24399correctly: 24400 24401 (define_constraint "[GHIJKLMNOP]..." 24402 "DOC..." 24403 (and (match_code "const_int") ; 'const_double' for G/H 24404 CONDITION...)) ; usually a 'match_test' 24405 24406 It is fine to use names beginning with other letters for constraints 24407that match 'const_double's or 'const_int's. 24408 24409 Each docstring in a constraint definition should be one or more 24410complete sentences, marked up in Texinfo format. _They are currently 24411unused._ In the future they will be copied into the GCC manual, in 24412*note Machine Constraints::, replacing the hand-maintained tables 24413currently found in that section. Also, in the future the compiler may 24414use this to give more helpful diagnostics when poor choice of 'asm' 24415constraints causes a reload failure. 24416 24417 If you put the pseudo-Texinfo directive '@internal' at the beginning of 24418a docstring, then (in the future) it will appear only in the internals 24419manual's version of the machine-specific constraint tables. Use this 24420for constraints that should not appear in 'asm' statements. 24421 24422 24423File: gccint.info, Node: C Constraint Interface, Prev: Define Constraints, Up: Constraints 24424 2442517.8.8 Testing constraints from C 24426--------------------------------- 24427 24428It is occasionally useful to test a constraint from C code rather than 24429implicitly via the constraint string in a 'match_operand'. The 24430generated file 'tm_p.h' declares a few interfaces for working with 24431constraints. At present these are defined for all constraints except 24432'g' (which is equivalent to 'general_operand'). 24433 24434 Some valid constraint names are not valid C identifiers, so there is a 24435mangling scheme for referring to them from C. Constraint names that do 24436not contain angle brackets or underscores are left unchanged. 24437Underscores are doubled, each '<' is replaced with '_l', and each '>' 24438with '_g'. Here are some examples: 24439 24440 *Original* *Mangled* 24441 x x 24442 P42x P42x 24443 P4_x P4__x 24444 P4>x P4_gx 24445 P4>> P4_g_g 24446 P4_g> P4__g_g 24447 24448 Throughout this section, the variable C is either a constraint in the 24449abstract sense, or a constant from 'enum constraint_num'; the variable M 24450is a mangled constraint name (usually as part of a larger identifier). 24451 24452 -- Enum: constraint_num 24453 For each constraint except 'g', there is a corresponding 24454 enumeration constant: 'CONSTRAINT_' plus the mangled name of the 24455 constraint. Functions that take an 'enum constraint_num' as an 24456 argument expect one of these constants. 24457 24458 -- Function: inline bool satisfies_constraint_M (rtx EXP) 24459 For each non-register constraint M except 'g', there is one of 24460 these functions; it returns 'true' if EXP satisfies the constraint. 24461 These functions are only visible if 'rtl.h' was included before 24462 'tm_p.h'. 24463 24464 -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num 24465 C) 24466 Like the 'satisfies_constraint_M' functions, but the constraint to 24467 test is given as an argument, C. If C specifies a register 24468 constraint, this function will always return 'false'. 24469 24470 -- Function: enum reg_class reg_class_for_constraint (enum 24471 constraint_num C) 24472 Returns the register class associated with C. If C is not a 24473 register constraint, or those registers are not available for the 24474 currently selected subtarget, returns 'NO_REGS'. 24475 24476 Here is an example use of 'satisfies_constraint_M'. In peephole 24477optimizations (*note Peephole Definitions::), operand constraint strings 24478are ignored, so if there are relevant constraints, they must be tested 24479in the C condition. In the example, the optimization is applied if 24480operand 2 does _not_ satisfy the 'K' constraint. (This is a simplified 24481version of a peephole definition from the i386 machine description.) 24482 24483 (define_peephole2 24484 [(match_scratch:SI 3 "r") 24485 (set (match_operand:SI 0 "register_operand" "") 24486 (mult:SI (match_operand:SI 1 "memory_operand" "") 24487 (match_operand:SI 2 "immediate_operand" "")))] 24488 24489 "!satisfies_constraint_K (operands[2])" 24490 24491 [(set (match_dup 3) (match_dup 1)) 24492 (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))] 24493 24494 "") 24495 24496 24497File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc 24498 2449917.9 Standard Pattern Names For Generation 24500========================================== 24501 24502Here is a table of the instruction names that are meaningful in the RTL 24503generation pass of the compiler. Giving one of these names to an 24504instruction pattern tells the RTL generation pass that it can use the 24505pattern to accomplish a certain task. 24506 24507'movM' 24508 Here M stands for a two-letter machine mode name, in lowercase. 24509 This instruction pattern moves data with that machine mode from 24510 operand 1 to operand 0. For example, 'movsi' moves full-word data. 24511 24512 If operand 0 is a 'subreg' with mode M of a register whose own mode 24513 is wider than M, the effect of this instruction is to store the 24514 specified value in the part of the register that corresponds to 24515 mode M. Bits outside of M, but which are within the same target 24516 word as the 'subreg' are undefined. Bits which are outside the 24517 target word are left unchanged. 24518 24519 This class of patterns is special in several ways. First of all, 24520 each of these names up to and including full word size _must_ be 24521 defined, because there is no other way to copy a datum from one 24522 place to another. If there are patterns accepting operands in 24523 larger modes, 'movM' must be defined for integer modes of those 24524 sizes. 24525 24526 Second, these patterns are not used solely in the RTL generation 24527 pass. Even the reload pass can generate move insns to copy values 24528 from stack slots into temporary registers. When it does so, one of 24529 the operands is a hard register and the other is an operand that 24530 can need to be reloaded into a register. 24531 24532 Therefore, when given such a pair of operands, the pattern must 24533 generate RTL which needs no reloading and needs no temporary 24534 registers--no registers other than the operands. For example, if 24535 you support the pattern with a 'define_expand', then in such a case 24536 the 'define_expand' mustn't call 'force_reg' or any other such 24537 function which might generate new pseudo registers. 24538 24539 This requirement exists even for subword modes on a RISC machine 24540 where fetching those modes from memory normally requires several 24541 insns and some temporary registers. 24542 24543 During reload a memory reference with an invalid address may be 24544 passed as an operand. Such an address will be replaced with a 24545 valid address later in the reload pass. In this case, nothing may 24546 be done with the address except to use it as it stands. If it is 24547 copied, it will not be replaced with a valid address. No attempt 24548 should be made to make such an address into a valid address and no 24549 routine (such as 'change_address') that will do so may be called. 24550 Note that 'general_operand' will fail when applied to such an 24551 address. 24552 24553 The global variable 'reload_in_progress' (which must be explicitly 24554 declared if required) can be used to determine whether such special 24555 handling is required. 24556 24557 The variety of operands that have reloads depends on the rest of 24558 the machine description, but typically on a RISC machine these can 24559 only be pseudo registers that did not get hard registers, while on 24560 other machines explicit memory references will get optional 24561 reloads. 24562 24563 If a scratch register is required to move an object to or from 24564 memory, it can be allocated using 'gen_reg_rtx' prior to life 24565 analysis. 24566 24567 If there are cases which need scratch registers during or after 24568 reload, you must provide an appropriate secondary_reload target 24569 hook. 24570 24571 The macro 'can_create_pseudo_p' can be used to determine if it is 24572 unsafe to create new pseudo registers. If this variable is 24573 nonzero, then it is unsafe to call 'gen_reg_rtx' to allocate a new 24574 pseudo. 24575 24576 The constraints on a 'movM' must permit moving any hard register to 24577 any other hard register provided that 'TARGET_HARD_REGNO_MODE_OK' 24578 permits mode M in both registers and 'TARGET_REGISTER_MOVE_COST' 24579 applied to their classes returns a value of 2. 24580 24581 It is obligatory to support floating point 'movM' instructions into 24582 and out of any registers that can hold fixed point values, because 24583 unions and structures (which have modes 'SImode' or 'DImode') can 24584 be in those registers and they may have floating point members. 24585 24586 There may also be a need to support fixed point 'movM' instructions 24587 in and out of floating point registers. Unfortunately, I have 24588 forgotten why this was so, and I don't know whether it is still 24589 true. If 'TARGET_HARD_REGNO_MODE_OK' rejects fixed point values in 24590 floating point registers, then the constraints of the fixed point 24591 'movM' instructions must be designed to avoid ever trying to reload 24592 into a floating point register. 24593 24594'reload_inM' 24595'reload_outM' 24596 These named patterns have been obsoleted by the target hook 24597 'secondary_reload'. 24598 24599 Like 'movM', but used when a scratch register is required to move 24600 between operand 0 and operand 1. Operand 2 describes the scratch 24601 register. See the discussion of the 'SECONDARY_RELOAD_CLASS' macro 24602 in *note Register Classes::. 24603 24604 There are special restrictions on the form of the 'match_operand's 24605 used in these patterns. First, only the predicate for the reload 24606 operand is examined, i.e., 'reload_in' examines operand 1, but not 24607 the predicates for operand 0 or 2. Second, there may be only one 24608 alternative in the constraints. Third, only a single register 24609 class letter may be used for the constraint; subsequent constraint 24610 letters are ignored. As a special exception, an empty constraint 24611 string matches the 'ALL_REGS' register class. This may relieve 24612 ports of the burden of defining an 'ALL_REGS' constraint letter 24613 just for these patterns. 24614 24615'movstrictM' 24616 Like 'movM' except that if operand 0 is a 'subreg' with mode M of a 24617 register whose natural mode is wider, the 'movstrictM' instruction 24618 is guaranteed not to alter any of the register except the part 24619 which belongs to mode M. 24620 24621'movmisalignM' 24622 This variant of a move pattern is designed to load or store a value 24623 from a memory address that is not naturally aligned for its mode. 24624 For a store, the memory will be in operand 0; for a load, the 24625 memory will be in operand 1. The other operand is guaranteed not 24626 to be a memory, so that it's easy to tell whether this is a load or 24627 store. 24628 24629 This pattern is used by the autovectorizer, and when expanding a 24630 'MISALIGNED_INDIRECT_REF' expression. 24631 24632'load_multiple' 24633 Load several consecutive memory locations into consecutive 24634 registers. Operand 0 is the first of the consecutive registers, 24635 operand 1 is the first memory location, and operand 2 is a 24636 constant: the number of consecutive registers. 24637 24638 Define this only if the target machine really has such an 24639 instruction; do not define this if the most efficient way of 24640 loading consecutive registers from memory is to do them one at a 24641 time. 24642 24643 On some machines, there are restrictions as to which consecutive 24644 registers can be stored into memory, such as particular starting or 24645 ending register numbers or only a range of valid counts. For those 24646 machines, use a 'define_expand' (*note Expander Definitions::) and 24647 make the pattern fail if the restrictions are not met. 24648 24649 Write the generated insn as a 'parallel' with elements being a 24650 'set' of one register from the appropriate memory location (you may 24651 also need 'use' or 'clobber' elements). Use a 'match_parallel' 24652 (*note RTL Template::) to recognize the insn. See 'rs6000.md' for 24653 examples of the use of this insn pattern. 24654 24655'store_multiple' 24656 Similar to 'load_multiple', but store several consecutive registers 24657 into consecutive memory locations. Operand 0 is the first of the 24658 consecutive memory locations, operand 1 is the first register, and 24659 operand 2 is a constant: the number of consecutive registers. 24660 24661'vec_load_lanesMN' 24662 Perform an interleaved load of several vectors from memory operand 24663 1 into register operand 0. Both operands have mode M. The 24664 register operand is viewed as holding consecutive vectors of mode 24665 N, while the memory operand is a flat array that contains the same 24666 number of elements. The operation is equivalent to: 24667 24668 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 24669 for (j = 0; j < GET_MODE_NUNITS (N); j++) 24670 for (i = 0; i < c; i++) 24671 operand0[i][j] = operand1[j * c + i]; 24672 24673 For example, 'vec_load_lanestiv4hi' loads 8 16-bit values from 24674 memory into a register of mode 'TI'. The register contains two 24675 consecutive vectors of mode 'V4HI'. 24676 24677 This pattern can only be used if: 24678 TARGET_ARRAY_MODE_SUPPORTED_P (N, C) 24679 is true. GCC assumes that, if a target supports this kind of 24680 instruction for some mode N, it also supports unaligned loads for 24681 vectors of mode N. 24682 24683 This pattern is not allowed to 'FAIL'. 24684 24685'vec_mask_load_lanesMN' 24686 Like 'vec_load_lanesMN', but takes an additional mask operand 24687 (operand 2) that specifies which elements of the destination 24688 vectors should be loaded. Other elements of the destination 24689 vectors are set to zero. The operation is equivalent to: 24690 24691 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 24692 for (j = 0; j < GET_MODE_NUNITS (N); j++) 24693 if (operand2[j]) 24694 for (i = 0; i < c; i++) 24695 operand0[i][j] = operand1[j * c + i]; 24696 else 24697 for (i = 0; i < c; i++) 24698 operand0[i][j] = 0; 24699 24700 This pattern is not allowed to 'FAIL'. 24701 24702'vec_store_lanesMN' 24703 Equivalent to 'vec_load_lanesMN', with the memory and register 24704 operands reversed. That is, the instruction 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 for (i = 0; i < c; i++) 24709 operand0[j * c + i] = operand1[i][j]; 24710 24711 for a memory operand 0 and register operand 1. 24712 24713 This pattern is not allowed to 'FAIL'. 24714 24715'vec_mask_store_lanesMN' 24716 Like 'vec_store_lanesMN', but takes an additional mask operand 24717 (operand 2) that specifies which elements of the source vectors 24718 should be stored. The operation is equivalent to: 24719 24720 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 24721 for (j = 0; j < GET_MODE_NUNITS (N); j++) 24722 if (operand2[j]) 24723 for (i = 0; i < c; i++) 24724 operand0[j * c + i] = operand1[i][j]; 24725 24726 This pattern is not allowed to 'FAIL'. 24727 24728'gather_loadM' 24729 Load several separate memory locations into a vector of mode M. 24730 Operand 1 is a scalar base address and operand 2 is a vector of 24731 offsets from that base. Operand 0 is a destination vector with the 24732 same number of elements as the offset. For each element index I: 24733 24734 * extend the offset element I to address width, using zero 24735 extension if operand 3 is 1 and sign extension if operand 3 is 24736 zero; 24737 * multiply the extended offset by operand 4; 24738 * add the result to the base; and 24739 * load the value at that address into element I of operand 0. 24740 24741 The value of operand 3 does not matter if the offsets are already 24742 address width. 24743 24744'mask_gather_loadM' 24745 Like 'gather_loadM', but takes an extra mask operand as operand 5. 24746 Bit I of the mask is set if element I of the result should be 24747 loaded from memory and clear if element I of the result should be 24748 set to zero. 24749 24750'scatter_storeM' 24751 Store a vector of mode M into several distinct memory locations. 24752 Operand 0 is a scalar base address and operand 1 is a vector of 24753 offsets from that base. Operand 4 is the vector of values that 24754 should be stored, which has the same number of elements as the 24755 offset. For each element index I: 24756 24757 * extend the offset element I to address width, using zero 24758 extension if operand 2 is 1 and sign extension if operand 2 is 24759 zero; 24760 * multiply the extended offset by operand 3; 24761 * add the result to the base; and 24762 * store element I of operand 4 to that address. 24763 24764 The value of operand 2 does not matter if the offsets are already 24765 address width. 24766 24767'mask_scatter_storeM' 24768 Like 'scatter_storeM', but takes an extra mask operand as operand 24769 5. Bit I of the mask is set if element I of the result should be 24770 stored to memory. 24771 24772'vec_setM' 24773 Set given field in the vector value. Operand 0 is the vector to 24774 modify, operand 1 is new value of field and operand 2 specify the 24775 field index. 24776 24777'vec_extractMN' 24778 Extract given field from the vector value. Operand 1 is the 24779 vector, operand 2 specify field index and operand 0 place to store 24780 value into. The N mode is the mode of the field or vector of 24781 fields that should be extracted, should be either element mode of 24782 the vector mode M, or a vector mode with the same element mode and 24783 smaller number of elements. If N is a vector mode, the index is 24784 counted in units of that mode. 24785 24786'vec_initMN' 24787 Initialize the vector to given values. Operand 0 is the vector to 24788 initialize and operand 1 is parallel containing values for 24789 individual fields. The N mode is the mode of the elements, should 24790 be either element mode of the vector mode M, or a vector mode with 24791 the same element mode and smaller number of elements. 24792 24793'vec_duplicateM' 24794 Initialize vector output operand 0 so that each element has the 24795 value given by scalar input operand 1. The vector has mode M and 24796 the scalar has the mode appropriate for one element of M. 24797 24798 This pattern only handles duplicates of non-constant inputs. 24799 Constant vectors go through the 'movM' pattern instead. 24800 24801 This pattern is not allowed to 'FAIL'. 24802 24803'vec_seriesM' 24804 Initialize vector output operand 0 so that element I is equal to 24805 operand 1 plus I times operand 2. In other words, create a linear 24806 series whose base value is operand 1 and whose step is operand 2. 24807 24808 The vector output has mode M and the scalar inputs have the mode 24809 appropriate for one element of M. This pattern is not used for 24810 floating-point vectors, in order to avoid having to specify the 24811 rounding behavior for I > 1. 24812 24813 This pattern is not allowed to 'FAIL'. 24814 24815'while_ultMN' 24816 Set operand 0 to a mask that is true while incrementing operand 1 24817 gives a value that is less than operand 2. Operand 0 has mode N 24818 and operands 1 and 2 are scalar integers of mode M. The operation 24819 is equivalent to: 24820 24821 operand0[0] = operand1 < operand2; 24822 for (i = 1; i < GET_MODE_NUNITS (N); i++) 24823 operand0[i] = operand0[i - 1] && (operand1 + i < operand2); 24824 24825'vec_cmpMN' 24826 Output a vector comparison. Operand 0 of mode N is the destination 24827 for predicate in operand 1 which is a signed vector comparison with 24828 operands of mode M in operands 2 and 3. Predicate is computed by 24829 element-wise evaluation of the vector comparison with a truth value 24830 of all-ones and a false value of all-zeros. 24831 24832'vec_cmpuMN' 24833 Similar to 'vec_cmpMN' but perform unsigned vector comparison. 24834 24835'vec_cmpeqMN' 24836 Similar to 'vec_cmpMN' but perform equality or non-equality vector 24837 comparison only. If 'vec_cmpMN' or 'vec_cmpuMN' instruction 24838 pattern is supported, it will be preferred over 'vec_cmpeqMN', so 24839 there is no need to define this instruction pattern if the others 24840 are supported. 24841 24842'vcondMN' 24843 Output a conditional vector move. Operand 0 is the destination to 24844 receive a combination of operand 1 and operand 2, which are of mode 24845 M, dependent on the outcome of the predicate in operand 3 which is 24846 a signed vector comparison with operands of mode N in operands 4 24847 and 5. The modes M and N should have the same size. Operand 0 24848 will be set to the value OP1 & MSK | OP2 & ~MSK where MSK is 24849 computed by element-wise evaluation of the vector comparison with a 24850 truth value of all-ones and a false value of all-zeros. 24851 24852'vconduMN' 24853 Similar to 'vcondMN' but performs unsigned vector comparison. 24854 24855'vcondeqMN' 24856 Similar to 'vcondMN' but performs equality or non-equality vector 24857 comparison only. If 'vcondMN' or 'vconduMN' instruction pattern is 24858 supported, it will be preferred over 'vcondeqMN', so there is no 24859 need to define this instruction pattern if the others are 24860 supported. 24861 24862'vcond_mask_MN' 24863 Similar to 'vcondMN' but operand 3 holds a pre-computed result of 24864 vector comparison. 24865 24866'maskloadMN' 24867 Perform a masked load of vector from memory operand 1 of mode M 24868 into register operand 0. Mask is provided in register operand 2 of 24869 mode N. 24870 24871 This pattern is not allowed to 'FAIL'. 24872 24873'maskstoreMN' 24874 Perform a masked store of vector from register operand 1 of mode M 24875 into memory operand 0. Mask is provided in register operand 2 of 24876 mode N. 24877 24878 This pattern is not allowed to 'FAIL'. 24879 24880'vec_permM' 24881 Output a (variable) vector permutation. Operand 0 is the 24882 destination to receive elements from operand 1 and operand 2, which 24883 are of mode M. Operand 3 is the "selector". It is an integral 24884 mode vector of the same width and number of elements as mode M. 24885 24886 The input elements are numbered from 0 in operand 1 through 2*N-1 24887 in operand 2. The elements of the selector must be computed modulo 24888 2*N. Note that if 'rtx_equal_p(operand1, operand2)', this can be 24889 implemented with just operand 1 and selector elements modulo N. 24890 24891 In order to make things easy for a number of targets, if there is 24892 no 'vec_perm' pattern for mode M, but there is for mode Q where Q 24893 is a vector of 'QImode' of the same width as M, the middle-end will 24894 lower the mode M 'VEC_PERM_EXPR' to mode Q. 24895 24896 See also 'TARGET_VECTORIZER_VEC_PERM_CONST', which performs the 24897 analogous operation for constant selectors. 24898 24899'pushM1' 24900 Output a push instruction. Operand 0 is value to push. Used only 24901 when 'PUSH_ROUNDING' is defined. For historical reason, this 24902 pattern may be missing and in such case an 'mov' expander is used 24903 instead, with a 'MEM' expression forming the push operation. The 24904 'mov' expander method is deprecated. 24905 24906'addM3' 24907 Add operand 2 and operand 1, storing the result in operand 0. All 24908 operands must have mode M. This can be used even on two-address 24909 machines, by means of constraints requiring operands 1 and 0 to be 24910 the same location. 24911 24912'ssaddM3', 'usaddM3' 24913'subM3', 'sssubM3', 'ussubM3' 24914'mulM3', 'ssmulM3', 'usmulM3' 24915'divM3', 'ssdivM3' 24916'udivM3', 'usdivM3' 24917'modM3', 'umodM3' 24918'uminM3', 'umaxM3' 24919'andM3', 'iorM3', 'xorM3' 24920 Similar, for other arithmetic operations. 24921 24922'addvM4' 24923 Like 'addM3' but takes a 'code_label' as operand 3 and emits code 24924 to jump to it if signed overflow occurs during the addition. This 24925 pattern is used to implement the built-in functions performing 24926 signed integer addition with overflow checking. 24927 24928'subvM4', 'mulvM4' 24929 Similar, for other signed arithmetic operations. 24930 24931'uaddvM4' 24932 Like 'addvM4' but for unsigned addition. That is to say, the 24933 operation is the same as signed addition but the jump is taken only 24934 on unsigned overflow. 24935 24936'usubvM4', 'umulvM4' 24937 Similar, for other unsigned arithmetic operations. 24938 24939'addptrM3' 24940 Like 'addM3' but is guaranteed to only be used for address 24941 calculations. The expanded code is not allowed to clobber the 24942 condition code. It only needs to be defined if 'addM3' sets the 24943 condition code. If adds used for address calculations and normal 24944 adds are not compatible it is required to expand a distinct pattern 24945 (e.g. using an unspec). The pattern is used by LRA to emit 24946 address calculations. 'addM3' is used if 'addptrM3' is not 24947 defined. 24948 24949'fmaM4' 24950 Multiply operand 2 and operand 1, then add operand 3, storing the 24951 result in operand 0 without doing an intermediate rounding step. 24952 All operands must have mode M. This pattern is used to implement 24953 the 'fma', 'fmaf', and 'fmal' builtin functions from the ISO C99 24954 standard. 24955 24956'fmsM4' 24957 Like 'fmaM4', except operand 3 subtracted from the product instead 24958 of added to the product. This is represented in the rtl as 24959 24960 (fma:M OP1 OP2 (neg:M OP3)) 24961 24962'fnmaM4' 24963 Like 'fmaM4' except that the intermediate product is negated before 24964 being added to operand 3. This is represented in the rtl as 24965 24966 (fma:M (neg:M OP1) OP2 OP3) 24967 24968'fnmsM4' 24969 Like 'fmsM4' except that the intermediate product is negated before 24970 subtracting operand 3. This is represented in the rtl as 24971 24972 (fma:M (neg:M OP1) OP2 (neg:M OP3)) 24973 24974'sminM3', 'smaxM3' 24975 Signed minimum and maximum operations. When used with floating 24976 point, if both operands are zeros, or if either operand is 'NaN', 24977 then it is unspecified which of the two operands is returned as the 24978 result. 24979 24980'fminM3', 'fmaxM3' 24981 IEEE-conformant minimum and maximum operations. If one operand is 24982 a quiet 'NaN', then the other operand is returned. If both 24983 operands are quiet 'NaN', then a quiet 'NaN' is returned. In the 24984 case when gcc supports signaling 'NaN' (-fsignaling-nans) an 24985 invalid floating point exception is raised and a quiet 'NaN' is 24986 returned. 24987 24988 All operands have mode M, which is a scalar or vector 24989 floating-point mode. These patterns are not allowed to 'FAIL'. 24990 24991'reduc_smin_scal_M', 'reduc_smax_scal_M' 24992 Find the signed minimum/maximum of the elements of a vector. The 24993 vector is operand 1, and operand 0 is the scalar result, with mode 24994 equal to the mode of the elements of the input vector. 24995 24996'reduc_umin_scal_M', 'reduc_umax_scal_M' 24997 Find the unsigned minimum/maximum of the elements of a vector. The 24998 vector is operand 1, and operand 0 is the scalar result, with mode 24999 equal to the mode of the elements of the input vector. 25000 25001'reduc_plus_scal_M' 25002 Compute the sum of the elements of a vector. The vector is operand 25003 1, and operand 0 is the scalar result, with mode equal to the mode 25004 of the elements of the input vector. 25005 25006'reduc_and_scal_M' 25007'reduc_ior_scal_M' 25008'reduc_xor_scal_M' 25009 Compute the bitwise 'AND'/'IOR'/'XOR' reduction of the elements of 25010 a vector of mode M. Operand 1 is the vector input and operand 0 is 25011 the scalar result. The mode of the scalar result is the same as 25012 one element of M. 25013 25014'extract_last_M' 25015 Find the last set bit in mask operand 1 and extract the associated 25016 element of vector operand 2. Store the result in scalar operand 0. 25017 Operand 2 has vector mode M while operand 0 has the mode 25018 appropriate for one element of M. Operand 1 has the usual mask 25019 mode for vectors of mode M; see 'TARGET_VECTORIZE_GET_MASK_MODE'. 25020 25021'fold_extract_last_M' 25022 If any bits of mask operand 2 are set, find the last set bit, 25023 extract the associated element from vector operand 3, and store the 25024 result in operand 0. Store operand 1 in operand 0 otherwise. 25025 Operand 3 has mode M and operands 0 and 1 have the mode appropriate 25026 for one element of M. Operand 2 has the usual mask mode for 25027 vectors of mode M; see 'TARGET_VECTORIZE_GET_MASK_MODE'. 25028 25029'fold_left_plus_M' 25030 Take scalar operand 1 and successively add each element from vector 25031 operand 2. Store the result in scalar operand 0. The vector has 25032 mode M and the scalars have the mode appropriate for one element of 25033 M. The operation is strictly in-order: there is no reassociation. 25034 25035'sdot_prodM' 25036'udot_prodM' 25037 Compute the sum of the products of two signed/unsigned elements. 25038 Operand 1 and operand 2 are of the same mode. Their product, which 25039 is of a wider mode, is computed and added to operand 3. Operand 3 25040 is of a mode equal or wider than the mode of the product. The 25041 result is placed in operand 0, which is of the same mode as operand 25042 3. 25043 25044'ssadM' 25045'usadM' 25046 Compute the sum of absolute differences of two signed/unsigned 25047 elements. Operand 1 and operand 2 are of the same mode. Their 25048 absolute difference, which is of a wider mode, is computed and 25049 added to operand 3. Operand 3 is of a mode equal or wider than the 25050 mode of the absolute difference. The result is placed in operand 25051 0, which is of the same mode as operand 3. 25052 25053'widen_ssumM3' 25054'widen_usumM3' 25055 Operands 0 and 2 are of the same mode, which is wider than the mode 25056 of operand 1. Add operand 1 to operand 2 and place the widened 25057 result in operand 0. (This is used express accumulation of 25058 elements into an accumulator of a wider mode.) 25059 25060'vec_shl_insert_M' 25061 Shift the elements in vector input operand 1 left one element (i.e. 25062 away from element 0) and fill the vacated element 0 with the scalar 25063 in operand 2. Store the result in vector output operand 0. 25064 Operands 0 and 1 have mode M and operand 2 has the mode appropriate 25065 for one element of M. 25066 25067'vec_shr_M' 25068 Whole vector right shift in bits, i.e. towards element 0. Operand 25069 1 is a vector to be shifted. Operand 2 is an integer shift amount 25070 in bits. Operand 0 is where the resulting shifted vector is 25071 stored. The output and input vectors should have the same modes. 25072 25073'vec_pack_trunc_M' 25074 Narrow (demote) and merge the elements of two vectors. Operands 1 25075 and 2 are vectors of the same mode having N integral or floating 25076 point elements of size S. Operand 0 is the resulting vector in 25077 which 2*N elements of size N/2 are concatenated after narrowing 25078 them down using truncation. 25079 25080'vec_pack_ssat_M', 'vec_pack_usat_M' 25081 Narrow (demote) and merge the elements of two vectors. Operands 1 25082 and 2 are vectors of the same mode having N integral elements of 25083 size S. Operand 0 is the resulting vector in which the elements of 25084 the two input vectors are concatenated after narrowing them down 25085 using signed/unsigned saturating arithmetic. 25086 25087'vec_pack_sfix_trunc_M', 'vec_pack_ufix_trunc_M' 25088 Narrow, convert to signed/unsigned integral type and merge the 25089 elements of two vectors. Operands 1 and 2 are vectors of the same 25090 mode having N floating point elements of size S. Operand 0 is the 25091 resulting vector in which 2*N elements of size N/2 are 25092 concatenated. 25093 25094'vec_unpacks_hi_M', 'vec_unpacks_lo_M' 25095 Extract and widen (promote) the high/low part of a vector of signed 25096 integral or floating point elements. The input vector (operand 1) 25097 has N elements of size S. Widen (promote) the high/low elements of 25098 the vector using signed or floating point extension and place the 25099 resulting N/2 values of size 2*S in the output vector (operand 0). 25100 25101'vec_unpacku_hi_M', 'vec_unpacku_lo_M' 25102 Extract and widen (promote) the high/low part of a vector of 25103 unsigned integral elements. The input vector (operand 1) has N 25104 elements of size S. Widen (promote) the high/low elements of the 25105 vector using zero extension and place the resulting N/2 values of 25106 size 2*S in the output vector (operand 0). 25107 25108'vec_unpacks_float_hi_M', 'vec_unpacks_float_lo_M' 25109'vec_unpacku_float_hi_M', 'vec_unpacku_float_lo_M' 25110 Extract, convert to floating point type and widen the high/low part 25111 of a vector of signed/unsigned integral elements. The input vector 25112 (operand 1) has N elements of size S. Convert the high/low 25113 elements of the vector using floating point conversion and place 25114 the resulting N/2 values of size 2*S in the output vector (operand 25115 0). 25116 25117'vec_widen_umult_hi_M', 'vec_widen_umult_lo_M' 25118'vec_widen_smult_hi_M', 'vec_widen_smult_lo_M' 25119'vec_widen_umult_even_M', 'vec_widen_umult_odd_M' 25120'vec_widen_smult_even_M', 'vec_widen_smult_odd_M' 25121 Signed/Unsigned widening multiplication. The two inputs (operands 25122 1 and 2) are vectors with N signed/unsigned elements of size S. 25123 Multiply the high/low or even/odd elements of the two vectors, and 25124 put the N/2 products of size 2*S in the output vector (operand 0). 25125 A target shouldn't implement even/odd pattern pair if it is less 25126 efficient than lo/hi one. 25127 25128'vec_widen_ushiftl_hi_M', 'vec_widen_ushiftl_lo_M' 25129'vec_widen_sshiftl_hi_M', 'vec_widen_sshiftl_lo_M' 25130 Signed/Unsigned widening shift left. The first input (operand 1) 25131 is a vector with N signed/unsigned elements of size S. Operand 2 25132 is a constant. Shift the high/low elements of operand 1, and put 25133 the N/2 results of size 2*S in the output vector (operand 0). 25134 25135'mulhisi3' 25136 Multiply operands 1 and 2, which have mode 'HImode', and store a 25137 'SImode' product in operand 0. 25138 25139'mulqihi3', 'mulsidi3' 25140 Similar widening-multiplication instructions of other widths. 25141 25142'umulqihi3', 'umulhisi3', 'umulsidi3' 25143 Similar widening-multiplication instructions that do unsigned 25144 multiplication. 25145 25146'usmulqihi3', 'usmulhisi3', 'usmulsidi3' 25147 Similar widening-multiplication instructions that interpret the 25148 first operand as unsigned and the second operand as signed, then do 25149 a signed multiplication. 25150 25151'smulM3_highpart' 25152 Perform a signed multiplication of operands 1 and 2, which have 25153 mode M, and store the most significant half of the product in 25154 operand 0. The least significant half of the product is discarded. 25155 25156'umulM3_highpart' 25157 Similar, but the multiplication is unsigned. 25158 25159'maddMN4' 25160 Multiply operands 1 and 2, sign-extend them to mode N, add operand 25161 3, and store the result in operand 0. Operands 1 and 2 have mode M 25162 and operands 0 and 3 have mode N. Both modes must be integer or 25163 fixed-point modes and N must be twice the size of M. 25164 25165 In other words, 'maddMN4' is like 'mulMN3' except that it also adds 25166 operand 3. 25167 25168 These instructions are not allowed to 'FAIL'. 25169 25170'umaddMN4' 25171 Like 'maddMN4', but zero-extend the multiplication operands instead 25172 of sign-extending them. 25173 25174'ssmaddMN4' 25175 Like 'maddMN4', but all involved operations must be 25176 signed-saturating. 25177 25178'usmaddMN4' 25179 Like 'umaddMN4', but all involved operations must be 25180 unsigned-saturating. 25181 25182'msubMN4' 25183 Multiply operands 1 and 2, sign-extend them to mode N, subtract the 25184 result from operand 3, and store the result in operand 0. Operands 25185 1 and 2 have mode M and operands 0 and 3 have mode N. Both modes 25186 must be integer or fixed-point modes and N must be twice the size 25187 of M. 25188 25189 In other words, 'msubMN4' is like 'mulMN3' except that it also 25190 subtracts the result from operand 3. 25191 25192 These instructions are not allowed to 'FAIL'. 25193 25194'umsubMN4' 25195 Like 'msubMN4', but zero-extend the multiplication operands instead 25196 of sign-extending them. 25197 25198'ssmsubMN4' 25199 Like 'msubMN4', but all involved operations must be 25200 signed-saturating. 25201 25202'usmsubMN4' 25203 Like 'umsubMN4', but all involved operations must be 25204 unsigned-saturating. 25205 25206'divmodM4' 25207 Signed division that produces both a quotient and a remainder. 25208 Operand 1 is divided by operand 2 to produce a quotient stored in 25209 operand 0 and a remainder stored in operand 3. 25210 25211 For machines with an instruction that produces both a quotient and 25212 a remainder, provide a pattern for 'divmodM4' but do not provide 25213 patterns for 'divM3' and 'modM3'. This allows optimization in the 25214 relatively common case when both the quotient and remainder are 25215 computed. 25216 25217 If an instruction that just produces a quotient or just a remainder 25218 exists and is more efficient than the instruction that produces 25219 both, write the output routine of 'divmodM4' to call 25220 'find_reg_note' and look for a 'REG_UNUSED' note on the quotient or 25221 remainder and generate the appropriate instruction. 25222 25223'udivmodM4' 25224 Similar, but does unsigned division. 25225 25226'ashlM3', 'ssashlM3', 'usashlM3' 25227 Arithmetic-shift operand 1 left by a number of bits specified by 25228 operand 2, and store the result in operand 0. Here M is the mode 25229 of operand 0 and operand 1; operand 2's mode is specified by the 25230 instruction pattern, and the compiler will convert the operand to 25231 that mode before generating the instruction. The shift or rotate 25232 expander or instruction pattern should explicitly specify the mode 25233 of the operand 2, it should never be 'VOIDmode'. The meaning of 25234 out-of-range shift counts can optionally be specified by 25235 'TARGET_SHIFT_TRUNCATION_MASK'. *Note 25236 TARGET_SHIFT_TRUNCATION_MASK::. Operand 2 is always a scalar type. 25237 25238'ashrM3', 'lshrM3', 'rotlM3', 'rotrM3' 25239 Other shift and rotate instructions, analogous to the 'ashlM3' 25240 instructions. Operand 2 is always a scalar type. 25241 25242'vashlM3', 'vashrM3', 'vlshrM3', 'vrotlM3', 'vrotrM3' 25243 Vector shift and rotate instructions that take vectors as operand 2 25244 instead of a scalar type. 25245 25246'bswapM2' 25247 Reverse the order of bytes of operand 1 and store the result in 25248 operand 0. 25249 25250'negM2', 'ssnegM2', 'usnegM2' 25251 Negate operand 1 and store the result in operand 0. 25252 25253'negvM3' 25254 Like 'negM2' but takes a 'code_label' as operand 2 and emits code 25255 to jump to it if signed overflow occurs during the negation. 25256 25257'absM2' 25258 Store the absolute value of operand 1 into operand 0. 25259 25260'sqrtM2' 25261 Store the square root of operand 1 into operand 0. Both operands 25262 have mode M, which is a scalar or vector floating-point mode. 25263 25264 This pattern is not allowed to 'FAIL'. 25265 25266'rsqrtM2' 25267 Store the reciprocal of the square root of operand 1 into operand 25268 0. Both operands have mode M, which is a scalar or vector 25269 floating-point mode. 25270 25271 On most architectures this pattern is only approximate, so either 25272 its C condition or the 'TARGET_OPTAB_SUPPORTED_P' hook should check 25273 for the appropriate math flags. (Using the C condition is more 25274 direct, but using 'TARGET_OPTAB_SUPPORTED_P' can be useful if a 25275 target-specific built-in also uses the 'rsqrtM2' pattern.) 25276 25277 This pattern is not allowed to 'FAIL'. 25278 25279'fmodM3' 25280 Store the remainder of dividing operand 1 by operand 2 into operand 25281 0, rounded towards zero to an integer. All operands have mode M, 25282 which is a scalar or vector floating-point mode. 25283 25284 This pattern is not allowed to 'FAIL'. 25285 25286'remainderM3' 25287 Store the remainder of dividing operand 1 by operand 2 into operand 25288 0, rounded to the nearest integer. All operands have mode M, which 25289 is a scalar or vector floating-point mode. 25290 25291 This pattern is not allowed to 'FAIL'. 25292 25293'scalbM3' 25294 Raise 'FLT_RADIX' to the power of operand 2, multiply it by operand 25295 1, and store the result in operand 0. All operands have mode M, 25296 which is a scalar or vector floating-point mode. 25297 25298 This pattern is not allowed to 'FAIL'. 25299 25300'ldexpM3' 25301 Raise 2 to the power of operand 2, multiply it by operand 1, and 25302 store the result in operand 0. Operands 0 and 1 have mode M, which 25303 is a scalar or vector floating-point mode. Operand 2's mode has 25304 the same number of elements as M and each element is wide enough to 25305 store an 'int'. The integers are signed. 25306 25307 This pattern is not allowed to 'FAIL'. 25308 25309'cosM2' 25310 Store the cosine of operand 1 into operand 0. Both operands have 25311 mode M, which is a scalar or vector floating-point mode. 25312 25313 This pattern is not allowed to 'FAIL'. 25314 25315'sinM2' 25316 Store the sine of operand 1 into operand 0. Both operands have 25317 mode M, which is a scalar or vector floating-point mode. 25318 25319 This pattern is not allowed to 'FAIL'. 25320 25321'sincosM3' 25322 Store the cosine of operand 2 into operand 0 and the sine of 25323 operand 2 into operand 1. All operands have mode M, which is a 25324 scalar or vector floating-point mode. 25325 25326 Targets that can calculate the sine and cosine simultaneously can 25327 implement this pattern as opposed to implementing individual 25328 'sinM2' and 'cosM2' patterns. The 'sin' and 'cos' built-in 25329 functions will then be expanded to the 'sincosM3' pattern, with one 25330 of the output values left unused. 25331 25332'tanM2' 25333 Store the tangent of operand 1 into operand 0. Both operands have 25334 mode M, which is a scalar or vector floating-point mode. 25335 25336 This pattern is not allowed to 'FAIL'. 25337 25338'asinM2' 25339 Store the arc sine of operand 1 into operand 0. Both operands have 25340 mode M, which is a scalar or vector floating-point mode. 25341 25342 This pattern is not allowed to 'FAIL'. 25343 25344'acosM2' 25345 Store the arc cosine of operand 1 into operand 0. Both operands 25346 have mode M, which is a scalar or vector floating-point mode. 25347 25348 This pattern is not allowed to 'FAIL'. 25349 25350'atanM2' 25351 Store the arc tangent of operand 1 into operand 0. Both operands 25352 have mode M, which is a scalar or vector floating-point mode. 25353 25354 This pattern is not allowed to 'FAIL'. 25355 25356'expM2' 25357 Raise e (the base of natural logarithms) to the power of operand 1 25358 and store the result in operand 0. Both operands have mode M, 25359 which is a scalar or vector floating-point mode. 25360 25361 This pattern is not allowed to 'FAIL'. 25362 25363'expm1M2' 25364 Raise e (the base of natural logarithms) to the power of operand 1, 25365 subtract 1, and store the result in operand 0. Both operands have 25366 mode M, which is a scalar or vector floating-point mode. 25367 25368 For inputs close to zero, the pattern is expected to be more 25369 accurate than a separate 'expM2' and 'subM3' would be. 25370 25371 This pattern is not allowed to 'FAIL'. 25372 25373'exp10M2' 25374 Raise 10 to the power of operand 1 and store the result in operand 25375 0. Both operands have mode M, which is a scalar or vector 25376 floating-point mode. 25377 25378 This pattern is not allowed to 'FAIL'. 25379 25380'exp2M2' 25381 Raise 2 to the power of operand 1 and store the result in operand 25382 0. Both operands have mode M, which is a scalar or vector 25383 floating-point mode. 25384 25385 This pattern is not allowed to 'FAIL'. 25386 25387'logM2' 25388 Store the natural logarithm of operand 1 into operand 0. Both 25389 operands have mode M, which is a scalar or vector floating-point 25390 mode. 25391 25392 This pattern is not allowed to 'FAIL'. 25393 25394'log1pM2' 25395 Add 1 to operand 1, compute the natural logarithm, and store the 25396 result in operand 0. Both operands have mode M, which is a scalar 25397 or vector floating-point mode. 25398 25399 For inputs close to zero, the pattern is expected to be more 25400 accurate than a separate 'addM3' and 'logM2' would be. 25401 25402 This pattern is not allowed to 'FAIL'. 25403 25404'log10M2' 25405 Store the base-10 logarithm of operand 1 into operand 0. Both 25406 operands have mode M, which is a scalar or vector floating-point 25407 mode. 25408 25409 This pattern is not allowed to 'FAIL'. 25410 25411'log2M2' 25412 Store the base-2 logarithm of operand 1 into operand 0. Both 25413 operands have mode M, which is a scalar or vector floating-point 25414 mode. 25415 25416 This pattern is not allowed to 'FAIL'. 25417 25418'logbM2' 25419 Store the base-'FLT_RADIX' logarithm of operand 1 into operand 0. 25420 Both operands have mode M, which is a scalar or vector 25421 floating-point mode. 25422 25423 This pattern is not allowed to 'FAIL'. 25424 25425'significandM2' 25426 Store the significand of floating-point operand 1 in operand 0. 25427 Both operands have mode M, which is a scalar or vector 25428 floating-point mode. 25429 25430 This pattern is not allowed to 'FAIL'. 25431 25432'powM3' 25433 Store the value of operand 1 raised to the exponent operand 2 into 25434 operand 0. All operands have mode M, which is a scalar or vector 25435 floating-point mode. 25436 25437 This pattern is not allowed to 'FAIL'. 25438 25439'atan2M3' 25440 Store the arc tangent (inverse tangent) of operand 1 divided by 25441 operand 2 into operand 0, using the signs of both arguments to 25442 determine the quadrant of the result. All operands have mode M, 25443 which is a scalar or vector floating-point mode. 25444 25445 This pattern is not allowed to 'FAIL'. 25446 25447'floorM2' 25448 Store the largest integral value not greater than operand 1 in 25449 operand 0. Both operands have mode M, which is a scalar or vector 25450 floating-point mode. If '-ffp-int-builtin-inexact' is in effect, 25451 the "inexact" exception may be raised for noninteger operands; 25452 otherwise, it may not. 25453 25454 This pattern is not allowed to 'FAIL'. 25455 25456'btruncM2' 25457 Round operand 1 to an integer, towards zero, and store the result 25458 in operand 0. Both operands have mode M, which is a scalar or 25459 vector floating-point mode. If '-ffp-int-builtin-inexact' is in 25460 effect, the "inexact" exception may be raised for noninteger 25461 operands; otherwise, it may not. 25462 25463 This pattern is not allowed to 'FAIL'. 25464 25465'roundM2' 25466 Round operand 1 to the nearest integer, rounding away from zero in 25467 the event of a tie, and store the result in operand 0. Both 25468 operands have mode M, which is a scalar or vector floating-point 25469 mode. If '-ffp-int-builtin-inexact' is in effect, the "inexact" 25470 exception may be raised for noninteger operands; otherwise, it may 25471 not. 25472 25473 This pattern is not allowed to 'FAIL'. 25474 25475'ceilM2' 25476 Store the smallest integral value not less than operand 1 in 25477 operand 0. Both operands have mode M, which is a scalar or vector 25478 floating-point mode. If '-ffp-int-builtin-inexact' is in effect, 25479 the "inexact" exception may be raised for noninteger operands; 25480 otherwise, it may not. 25481 25482 This pattern is not allowed to 'FAIL'. 25483 25484'nearbyintM2' 25485 Round operand 1 to an integer, using the current rounding mode, and 25486 store the result in operand 0. Do not raise an inexact condition 25487 when the result is different from the argument. Both operands have 25488 mode M, which is a scalar or vector floating-point mode. 25489 25490 This pattern is not allowed to 'FAIL'. 25491 25492'rintM2' 25493 Round operand 1 to an integer, using the current rounding mode, and 25494 store the result in operand 0. Raise an inexact condition when the 25495 result is different from the argument. Both operands have mode M, 25496 which is a scalar or vector floating-point mode. 25497 25498 This pattern is not allowed to 'FAIL'. 25499 25500'lrintMN2' 25501 Convert operand 1 (valid for floating point mode M) to fixed point 25502 mode N as a signed number according to the current rounding mode 25503 and store in operand 0 (which has mode N). 25504 25505'lroundMN2' 25506 Convert operand 1 (valid for floating point mode M) to fixed point 25507 mode N as a signed number rounding to nearest and away from zero 25508 and store in operand 0 (which has mode N). 25509 25510'lfloorMN2' 25511 Convert operand 1 (valid for floating point mode M) to fixed point 25512 mode N as a signed number rounding down and store in operand 0 25513 (which has mode N). 25514 25515'lceilMN2' 25516 Convert operand 1 (valid for floating point mode M) to fixed point 25517 mode N as a signed number rounding up and store in operand 0 (which 25518 has mode N). 25519 25520'copysignM3' 25521 Store a value with the magnitude of operand 1 and the sign of 25522 operand 2 into operand 0. All operands have mode M, which is a 25523 scalar or vector floating-point mode. 25524 25525 This pattern is not allowed to 'FAIL'. 25526 25527'ffsM2' 25528 Store into operand 0 one plus the index of the least significant 25529 1-bit of operand 1. If operand 1 is zero, store zero. 25530 25531 M is either a scalar or vector integer mode. When it is a scalar, 25532 operand 1 has mode M but operand 0 can have whatever scalar integer 25533 mode is suitable for the target. The compiler will insert 25534 conversion instructions as necessary (typically to convert the 25535 result to the same width as 'int'). When M is a vector, both 25536 operands must have mode M. 25537 25538 This pattern is not allowed to 'FAIL'. 25539 25540'clrsbM2' 25541 Count leading redundant sign bits. Store into operand 0 the number 25542 of redundant sign bits in operand 1, starting at the most 25543 significant bit position. A redundant sign bit is defined as any 25544 sign bit after the first. As such, this count will be one less 25545 than the count of leading sign bits. 25546 25547 M is either a scalar or vector integer mode. When it is a scalar, 25548 operand 1 has mode M but operand 0 can have whatever scalar integer 25549 mode is suitable for the target. The compiler will insert 25550 conversion instructions as necessary (typically to convert the 25551 result to the same width as 'int'). When M is a vector, both 25552 operands must have mode M. 25553 25554 This pattern is not allowed to 'FAIL'. 25555 25556'clzM2' 25557 Store into operand 0 the number of leading 0-bits in operand 1, 25558 starting at the most significant bit position. If operand 1 is 0, 25559 the 'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the 25560 result is undefined or has a useful value. 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'ctzM2' 25572 Store into operand 0 the number of trailing 0-bits in operand 1, 25573 starting at the least significant bit position. If operand 1 is 0, 25574 the 'CTZ_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'popcountM2' 25587 Store into operand 0 the number of 1-bits in operand 1. 25588 25589 M is either a scalar or vector integer mode. When it is a scalar, 25590 operand 1 has mode M but operand 0 can have whatever scalar integer 25591 mode is suitable for the target. The compiler will insert 25592 conversion instructions as necessary (typically to convert the 25593 result to the same width as 'int'). When M is a vector, both 25594 operands must have mode M. 25595 25596 This pattern is not allowed to 'FAIL'. 25597 25598'parityM2' 25599 Store into operand 0 the parity of operand 1, i.e. the number of 25600 1-bits in operand 1 modulo 2. 25601 25602 M is either a scalar or vector integer mode. When it is a scalar, 25603 operand 1 has mode M but operand 0 can have whatever scalar integer 25604 mode is suitable for the target. The compiler will insert 25605 conversion instructions as necessary (typically to convert the 25606 result to the same width as 'int'). When M is a vector, both 25607 operands must have mode M. 25608 25609 This pattern is not allowed to 'FAIL'. 25610 25611'one_cmplM2' 25612 Store the bitwise-complement of operand 1 into operand 0. 25613 25614'movmemM' 25615 Block move instruction. The destination and source blocks of 25616 memory are the first two operands, and both are 'mem:BLK's with an 25617 address in mode 'Pmode'. 25618 25619 The number of bytes to move is the third operand, in mode M. 25620 Usually, you specify 'Pmode' for M. However, if you can generate 25621 better code knowing the range of valid lengths is smaller than 25622 those representable in a full Pmode pointer, you should provide a 25623 pattern with a mode corresponding to the range of values you can 25624 handle efficiently (e.g., 'QImode' for values in the range 0-127; 25625 note we avoid numbers that appear negative) and also a pattern with 25626 'Pmode'. 25627 25628 The fourth operand is the known shared alignment of the source and 25629 destination, in the form of a 'const_int' rtx. Thus, if the 25630 compiler knows that both source and destination are word-aligned, 25631 it may provide the value 4 for this operand. 25632 25633 Optional operands 5 and 6 specify expected alignment and size of 25634 block respectively. The expected alignment differs from alignment 25635 in operand 4 in a way that the blocks are not required to be 25636 aligned according to it in all cases. This expected alignment is 25637 also in bytes, just like operand 4. Expected size, when unknown, 25638 is set to '(const_int -1)'. 25639 25640 Descriptions of multiple 'movmemM' patterns can only be beneficial 25641 if the patterns for smaller modes have fewer restrictions on their 25642 first, second and fourth operands. Note that the mode M in 25643 'movmemM' does not impose any restriction on the mode of 25644 individually moved data units in the block. 25645 25646 These patterns need not give special consideration to the 25647 possibility that the source and destination strings might overlap. 25648 25649'movstr' 25650 String copy instruction, with 'stpcpy' semantics. Operand 0 is an 25651 output operand in mode 'Pmode'. The addresses of the destination 25652 and source strings are operands 1 and 2, and both are 'mem:BLK's 25653 with addresses in mode 'Pmode'. The execution of the expansion of 25654 this pattern should store in operand 0 the address in which the 25655 'NUL' terminator was stored in the destination string. 25656 25657 This patern has also several optional operands that are same as in 25658 'setmem'. 25659 25660'setmemM' 25661 Block set instruction. The destination string is the first 25662 operand, given as a 'mem:BLK' whose address is in mode 'Pmode'. 25663 The number of bytes to set is the second operand, in mode M. The 25664 value to initialize the memory with is the third operand. Targets 25665 that only support the clearing of memory should reject any value 25666 that is not the constant 0. See 'movmemM' for a discussion of the 25667 choice of mode. 25668 25669 The fourth operand is the known alignment of the destination, in 25670 the form of a 'const_int' rtx. Thus, if the compiler knows that 25671 the destination is word-aligned, it may provide the value 4 for 25672 this operand. 25673 25674 Optional operands 5 and 6 specify expected alignment and size of 25675 block respectively. The expected alignment differs from alignment 25676 in operand 4 in a way that the blocks are not required to be 25677 aligned according to it in all cases. This expected alignment is 25678 also in bytes, just like operand 4. Expected size, when unknown, 25679 is set to '(const_int -1)'. Operand 7 is the minimal size of the 25680 block and operand 8 is the maximal size of the block (NULL if it 25681 can not be represented as CONST_INT). Operand 9 is the probable 25682 maximal size (i.e. we can not rely on it for correctness, but it 25683 can be used for choosing proper code sequence for a given size). 25684 25685 The use for multiple 'setmemM' is as for 'movmemM'. 25686 25687'cmpstrnM' 25688 String compare instruction, with five operands. Operand 0 is the 25689 output; it has mode M. The remaining four operands are like the 25690 operands of 'movmemM'. The two memory blocks specified are 25691 compared byte by byte in lexicographic order starting at the 25692 beginning of each string. The instruction is not allowed to 25693 prefetch more than one byte at a time since either string may end 25694 in the first byte and reading past that may access an invalid page 25695 or segment and cause a fault. The comparison terminates early if 25696 the fetched bytes are different or if they are equal to zero. The 25697 effect of the instruction is to store a value in operand 0 whose 25698 sign indicates the result of the comparison. 25699 25700'cmpstrM' 25701 String compare instruction, without known maximum length. Operand 25702 0 is the output; it has mode M. The second and third operand are 25703 the blocks of memory to be compared; both are 'mem:BLK' with an 25704 address in mode 'Pmode'. 25705 25706 The fourth operand is the known shared alignment of the source and 25707 destination, in the form of a 'const_int' rtx. Thus, if the 25708 compiler knows that both source and destination are word-aligned, 25709 it may provide the value 4 for this operand. 25710 25711 The two memory blocks specified are compared byte by byte in 25712 lexicographic order starting at the beginning of each string. The 25713 instruction is not allowed to prefetch more than one byte at a time 25714 since either string may end in the first byte and reading past that 25715 may access an invalid page or segment and cause a fault. The 25716 comparison will terminate when the fetched bytes are different or 25717 if they are equal to zero. The effect of the instruction is to 25718 store a value in operand 0 whose sign indicates the result of the 25719 comparison. 25720 25721'cmpmemM' 25722 Block compare instruction, with five operands like the operands of 25723 'cmpstrM'. The two memory blocks specified are compared byte by 25724 byte in lexicographic order starting at the beginning of each 25725 block. Unlike 'cmpstrM' the instruction can prefetch any bytes in 25726 the two memory blocks. Also unlike 'cmpstrM' the comparison will 25727 not stop if both bytes are zero. The effect of the instruction is 25728 to store a value in operand 0 whose sign indicates the result of 25729 the comparison. 25730 25731'strlenM' 25732 Compute the length of a string, with three operands. Operand 0 is 25733 the result (of mode M), operand 1 is a 'mem' referring to the first 25734 character of the string, operand 2 is the character to search for 25735 (normally zero), and operand 3 is a constant describing the known 25736 alignment of the beginning of the string. 25737 25738'floatMN2' 25739 Convert signed integer operand 1 (valid for fixed point mode M) to 25740 floating point mode N and store in operand 0 (which has mode N). 25741 25742'floatunsMN2' 25743 Convert unsigned integer operand 1 (valid for fixed point mode M) 25744 to floating point mode N and store in operand 0 (which has mode N). 25745 25746'fixMN2' 25747 Convert operand 1 (valid for floating point mode M) to fixed point 25748 mode N as a signed number and store in operand 0 (which has mode 25749 N). This instruction's result is defined only when the value of 25750 operand 1 is an integer. 25751 25752 If the machine description defines this pattern, it also needs to 25753 define the 'ftrunc' pattern. 25754 25755'fixunsMN2' 25756 Convert operand 1 (valid for floating point mode M) to fixed point 25757 mode N as an unsigned number and store in operand 0 (which has mode 25758 N). This instruction's result is defined only when the value of 25759 operand 1 is an integer. 25760 25761'ftruncM2' 25762 Convert operand 1 (valid for floating point mode M) to an integer 25763 value, still represented in floating point mode M, and store it in 25764 operand 0 (valid for floating point mode M). 25765 25766'fix_truncMN2' 25767 Like 'fixMN2' but works for any floating point value of mode M by 25768 converting the value to an integer. 25769 25770'fixuns_truncMN2' 25771 Like 'fixunsMN2' but works for any floating point value of mode M 25772 by converting the value to an integer. 25773 25774'truncMN2' 25775 Truncate operand 1 (valid for mode M) to mode N and store in 25776 operand 0 (which has mode N). Both modes must be fixed point or 25777 both floating point. 25778 25779'extendMN2' 25780 Sign-extend operand 1 (valid for mode M) to mode N and store in 25781 operand 0 (which has mode N). Both modes must be fixed point or 25782 both floating point. 25783 25784'zero_extendMN2' 25785 Zero-extend operand 1 (valid for mode M) to mode N and store in 25786 operand 0 (which has mode N). Both modes must be fixed point. 25787 25788'fractMN2' 25789 Convert operand 1 of mode M to mode N and store in operand 0 (which 25790 has mode N). Mode M and mode N could be fixed-point to 25791 fixed-point, signed integer to fixed-point, fixed-point to signed 25792 integer, floating-point to fixed-point, or fixed-point to 25793 floating-point. When overflows or underflows happen, the results 25794 are undefined. 25795 25796'satfractMN2' 25797 Convert operand 1 of mode M to mode N and store in operand 0 (which 25798 has mode N). Mode M and mode N could be fixed-point to 25799 fixed-point, signed integer to fixed-point, or floating-point to 25800 fixed-point. When overflows or underflows happen, the instruction 25801 saturates the results to the maximum or the minimum. 25802 25803'fractunsMN2' 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 unsigned integer to 25806 fixed-point, or fixed-point to unsigned integer. When overflows or 25807 underflows happen, the results are undefined. 25808 25809'satfractunsMN2' 25810 Convert unsigned integer operand 1 of mode M to fixed-point mode N 25811 and store in operand 0 (which has mode N). When overflows or 25812 underflows happen, the instruction saturates the results to the 25813 maximum or the minimum. 25814 25815'extvM' 25816 Extract a bit-field from register operand 1, sign-extend it, and 25817 store it in operand 0. Operand 2 specifies the width of the field 25818 in bits and operand 3 the starting bit, which counts from the most 25819 significant bit if 'BITS_BIG_ENDIAN' is true and from the least 25820 significant bit otherwise. 25821 25822 Operands 0 and 1 both have mode M. Operands 2 and 3 have a 25823 target-specific mode. 25824 25825'extvmisalignM' 25826 Extract a bit-field from memory operand 1, sign extend it, and 25827 store it in operand 0. Operand 2 specifies the width in bits and 25828 operand 3 the starting bit. The starting bit is always somewhere 25829 in the first byte of operand 1; it counts from the most significant 25830 bit if 'BITS_BIG_ENDIAN' is true and from the least significant bit 25831 otherwise. 25832 25833 Operand 0 has mode M while operand 1 has 'BLK' mode. Operands 2 25834 and 3 have a target-specific mode. 25835 25836 The instruction must not read beyond the last byte of the 25837 bit-field. 25838 25839'extzvM' 25840 Like 'extvM' except that the bit-field value is zero-extended. 25841 25842'extzvmisalignM' 25843 Like 'extvmisalignM' except that the bit-field value is 25844 zero-extended. 25845 25846'insvM' 25847 Insert operand 3 into a bit-field of register operand 0. Operand 1 25848 specifies the width of the field in bits and operand 2 the starting 25849 bit, which counts from the most significant bit if 25850 'BITS_BIG_ENDIAN' is true and from the least significant bit 25851 otherwise. 25852 25853 Operands 0 and 3 both have mode M. Operands 1 and 2 have a 25854 target-specific mode. 25855 25856'insvmisalignM' 25857 Insert operand 3 into a bit-field of memory operand 0. Operand 1 25858 specifies the width of the field in bits and operand 2 the starting 25859 bit. The starting bit is always somewhere in the first byte of 25860 operand 0; it counts from the most significant bit if 25861 'BITS_BIG_ENDIAN' is true and from the least significant bit 25862 otherwise. 25863 25864 Operand 3 has mode M while operand 0 has 'BLK' mode. Operands 1 25865 and 2 have a target-specific mode. 25866 25867 The instruction must not read or write beyond the last byte of the 25868 bit-field. 25869 25870'extv' 25871 Extract a bit-field from operand 1 (a register or memory operand), 25872 where operand 2 specifies the width in bits and operand 3 the 25873 starting bit, and store it in operand 0. Operand 0 must have mode 25874 'word_mode'. Operand 1 may have mode 'byte_mode' or 'word_mode'; 25875 often 'word_mode' is allowed only for registers. Operands 2 and 3 25876 must be valid for 'word_mode'. 25877 25878 The RTL generation pass generates this instruction only with 25879 constants for operands 2 and 3 and the constant is never zero for 25880 operand 2. 25881 25882 The bit-field value is sign-extended to a full word integer before 25883 it is stored in operand 0. 25884 25885 This pattern is deprecated; please use 'extvM' and 'extvmisalignM' 25886 instead. 25887 25888'extzv' 25889 Like 'extv' except that the bit-field value is zero-extended. 25890 25891 This pattern is deprecated; please use 'extzvM' and 25892 'extzvmisalignM' instead. 25893 25894'insv' 25895 Store operand 3 (which must be valid for 'word_mode') into a 25896 bit-field in operand 0, where operand 1 specifies the width in bits 25897 and operand 2 the starting bit. Operand 0 may have mode 25898 'byte_mode' or 'word_mode'; often 'word_mode' is allowed only for 25899 registers. Operands 1 and 2 must be valid for 'word_mode'. 25900 25901 The RTL generation pass generates this instruction only with 25902 constants for operands 1 and 2 and the constant is never zero for 25903 operand 1. 25904 25905 This pattern is deprecated; please use 'insvM' and 'insvmisalignM' 25906 instead. 25907 25908'movMODEcc' 25909 Conditionally move operand 2 or operand 3 into operand 0 according 25910 to the comparison in operand 1. If the comparison is true, operand 25911 2 is moved into operand 0, otherwise operand 3 is moved. 25912 25913 The mode of the operands being compared need not be the same as the 25914 operands being moved. Some machines, sparc64 for example, have 25915 instructions that conditionally move an integer value based on the 25916 floating point condition codes and vice versa. 25917 25918 If the machine does not have conditional move instructions, do not 25919 define these patterns. 25920 25921'addMODEcc' 25922 Similar to 'movMODEcc' but for conditional addition. Conditionally 25923 move operand 2 or (operands 2 + operand 3) into operand 0 according 25924 to the comparison in operand 1. If the comparison is false, 25925 operand 2 is moved into operand 0, otherwise (operand 2 + operand 25926 3) is moved. 25927 25928'cond_addMODE' 25929'cond_subMODE' 25930'cond_andMODE' 25931'cond_iorMODE' 25932'cond_xorMODE' 25933'cond_sminMODE' 25934'cond_smaxMODE' 25935'cond_uminMODE' 25936'cond_umaxMODE' 25937 Perform an elementwise operation on vector operands 2 and 3, under 25938 the control of the vector mask in operand 1, and store the result 25939 in operand 0. This is equivalent to: 25940 25941 for (i = 0; i < GET_MODE_NUNITS (N); i++) 25942 op0[i] = op1[i] ? op2[i] OP op3[i] : op2[i]; 25943 25944 where, for example, OP is '+' for 'cond_addMODE'. 25945 25946 When defined for floating-point modes, the contents of 'op3[i]' are 25947 not interpreted if OP1[I] is false, just like they would not be in 25948 a normal C '?:' condition. 25949 25950 Operands 0, 2 and 3 all have mode M, while operand 1 has the mode 25951 returned by 'TARGET_VECTORIZE_GET_MASK_MODE'. 25952 25953'negMODEcc' 25954 Similar to 'movMODEcc' but for conditional negation. Conditionally 25955 move the negation of operand 2 or the unchanged operand 3 into 25956 operand 0 according to the comparison in operand 1. If the 25957 comparison is true, the negation of operand 2 is moved into operand 25958 0, otherwise operand 3 is moved. 25959 25960'notMODEcc' 25961 Similar to 'negMODEcc' but for conditional complement. 25962 Conditionally move the bitwise complement of operand 2 or the 25963 unchanged operand 3 into operand 0 according to the comparison in 25964 operand 1. If the comparison is true, the complement of operand 2 25965 is moved into operand 0, otherwise operand 3 is moved. 25966 25967'cstoreMODE4' 25968 Store zero or nonzero in operand 0 according to whether a 25969 comparison is true. Operand 1 is a comparison operator. Operand 2 25970 and operand 3 are the first and second operand of the comparison, 25971 respectively. You specify the mode that operand 0 must have when 25972 you write the 'match_operand' expression. The compiler 25973 automatically sees which mode you have used and supplies an operand 25974 of that mode. 25975 25976 The value stored for a true condition must have 1 as its low bit, 25977 or else must be negative. Otherwise the instruction is not 25978 suitable and you should omit it from the machine description. You 25979 describe to the compiler exactly which value is stored by defining 25980 the macro 'STORE_FLAG_VALUE' (*note Misc::). If a description 25981 cannot be found that can be used for all the possible comparison 25982 operators, you should pick one and use a 'define_expand' to map all 25983 results onto the one you chose. 25984 25985 These operations may 'FAIL', but should do so only in relatively 25986 uncommon cases; if they would 'FAIL' for common cases involving 25987 integer comparisons, it is best to restrict the predicates to not 25988 allow these operands. Likewise if a given comparison operator will 25989 always fail, independent of the operands (for floating-point modes, 25990 the 'ordered_comparison_operator' predicate is often useful in this 25991 case). 25992 25993 If this pattern is omitted, the compiler will generate a 25994 conditional branch--for example, it may copy a constant one to the 25995 target and branching around an assignment of zero to the target--or 25996 a libcall. If the predicate for operand 1 only rejects some 25997 operators, it will also try reordering the operands and/or 25998 inverting the result value (e.g. by an exclusive OR). These 25999 possibilities could be cheaper or equivalent to the instructions 26000 used for the 'cstoreMODE4' pattern followed by those required to 26001 convert a positive result from 'STORE_FLAG_VALUE' to 1; in this 26002 case, you can and should make operand 1's predicate reject some 26003 operators in the 'cstoreMODE4' pattern, or remove the pattern 26004 altogether from the machine description. 26005 26006'cbranchMODE4' 26007 Conditional branch instruction combined with a compare instruction. 26008 Operand 0 is a comparison operator. Operand 1 and operand 2 are 26009 the first and second operands of the comparison, respectively. 26010 Operand 3 is the 'code_label' to jump to. 26011 26012'jump' 26013 A jump inside a function; an unconditional branch. Operand 0 is 26014 the 'code_label' to jump to. This pattern name is mandatory on all 26015 machines. 26016 26017'call' 26018 Subroutine call instruction returning no value. Operand 0 is the 26019 function to call; operand 1 is the number of bytes of arguments 26020 pushed as a 'const_int'; operand 2 is the number of registers used 26021 as operands. 26022 26023 On most machines, operand 2 is not actually stored into the RTL 26024 pattern. It is supplied for the sake of some RISC machines which 26025 need to put this information into the assembler code; they can put 26026 it in the RTL instead of operand 1. 26027 26028 Operand 0 should be a 'mem' RTX whose address is the address of the 26029 function. Note, however, that this address can be a 'symbol_ref' 26030 expression even if it would not be a legitimate memory address on 26031 the target machine. If it is also not a valid argument for a call 26032 instruction, the pattern for this operation should be a 26033 'define_expand' (*note Expander Definitions::) that places the 26034 address into a register and uses that register in the call 26035 instruction. 26036 26037'call_value' 26038 Subroutine call instruction returning a value. Operand 0 is the 26039 hard register in which the value is returned. There are three more 26040 operands, the same as the three operands of the 'call' instruction 26041 (but with numbers increased by one). 26042 26043 Subroutines that return 'BLKmode' objects use the 'call' insn. 26044 26045'call_pop', 'call_value_pop' 26046 Similar to 'call' and 'call_value', except used if defined and if 26047 'RETURN_POPS_ARGS' is nonzero. They should emit a 'parallel' that 26048 contains both the function call and a 'set' to indicate the 26049 adjustment made to the frame pointer. 26050 26051 For machines where 'RETURN_POPS_ARGS' can be nonzero, the use of 26052 these patterns increases the number of functions for which the 26053 frame pointer can be eliminated, if desired. 26054 26055'untyped_call' 26056 Subroutine call instruction returning a value of any type. Operand 26057 0 is the function to call; operand 1 is a memory location where the 26058 result of calling the function is to be stored; operand 2 is a 26059 'parallel' expression where each element is a 'set' expression that 26060 indicates the saving of a function return value into the result 26061 block. 26062 26063 This instruction pattern should be defined to support 26064 '__builtin_apply' on machines where special instructions are needed 26065 to call a subroutine with arbitrary arguments or to save the value 26066 returned. This instruction pattern is required on machines that 26067 have multiple registers that can hold a return value (i.e. 26068 'FUNCTION_VALUE_REGNO_P' is true for more than one register). 26069 26070'return' 26071 Subroutine return instruction. This instruction pattern name 26072 should be defined only if a single instruction can do all the work 26073 of returning from a function. 26074 26075 Like the 'movM' patterns, this pattern is also used after the RTL 26076 generation phase. In this case it is to support machines where 26077 multiple instructions are usually needed to return from a function, 26078 but some class of functions only requires one instruction to 26079 implement a return. Normally, the applicable functions are those 26080 which do not need to save any registers or allocate stack space. 26081 26082 It is valid for this pattern to expand to an instruction using 26083 'simple_return' if no epilogue is required. 26084 26085'simple_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 on a path where no epilogue is 26089 required. This pattern is very similar to the 'return' instruction 26090 pattern, but it is emitted only by the shrink-wrapping optimization 26091 on paths where the function prologue has not been executed, and a 26092 function return should occur without any of the effects of the 26093 epilogue. Additional uses may be introduced on paths where both 26094 the prologue and the epilogue have executed. 26095 26096 For such machines, the condition specified in this pattern should 26097 only be true when 'reload_completed' is nonzero and the function's 26098 epilogue would only be a single instruction. For machines with 26099 register windows, the routine 'leaf_function_p' may be used to 26100 determine if a register window push is required. 26101 26102 Machines that have conditional return instructions should define 26103 patterns such as 26104 26105 (define_insn "" 26106 [(set (pc) 26107 (if_then_else (match_operator 26108 0 "comparison_operator" 26109 [(cc0) (const_int 0)]) 26110 (return) 26111 (pc)))] 26112 "CONDITION" 26113 "...") 26114 26115 where CONDITION would normally be the same condition specified on 26116 the named 'return' pattern. 26117 26118'untyped_return' 26119 Untyped subroutine return instruction. This instruction pattern 26120 should be defined to support '__builtin_return' on machines where 26121 special instructions are needed to return a value of any type. 26122 26123 Operand 0 is a memory location where the result of calling a 26124 function with '__builtin_apply' is stored; operand 1 is a 26125 'parallel' expression where each element is a 'set' expression that 26126 indicates the restoring of a function return value from the result 26127 block. 26128 26129'nop' 26130 No-op instruction. This instruction pattern name should always be 26131 defined to output a no-op in assembler code. '(const_int 0)' will 26132 do as an RTL pattern. 26133 26134'indirect_jump' 26135 An instruction to jump to an address which is operand zero. This 26136 pattern name is mandatory on all machines. 26137 26138'casesi' 26139 Instruction to jump through a dispatch table, including bounds 26140 checking. This instruction takes five operands: 26141 26142 1. The index to dispatch on, which has mode 'SImode'. 26143 26144 2. The lower bound for indices in the table, an integer constant. 26145 26146 3. The total range of indices in the table--the largest index 26147 minus the smallest one (both inclusive). 26148 26149 4. A label that precedes the table itself. 26150 26151 5. A label to jump to if the index has a value outside the 26152 bounds. 26153 26154 The table is an 'addr_vec' or 'addr_diff_vec' inside of a 26155 'jump_table_data'. The number of elements in the table is one plus 26156 the difference between the upper bound and the lower bound. 26157 26158'tablejump' 26159 Instruction to jump to a variable address. This is a low-level 26160 capability which can be used to implement a dispatch table when 26161 there is no 'casesi' pattern. 26162 26163 This pattern requires two operands: the address or offset, and a 26164 label which should immediately precede the jump table. If the 26165 macro 'CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then 26166 the first operand is an offset which counts from the address of the 26167 table; otherwise, it is an absolute address to jump to. In either 26168 case, the first operand has mode 'Pmode'. 26169 26170 The 'tablejump' insn is always the last insn before the jump table 26171 it uses. Its assembler code normally has no need to use the second 26172 operand, but you should incorporate it in the RTL pattern so that 26173 the jump optimizer will not delete the table as unreachable code. 26174 26175'decrement_and_branch_until_zero' 26176 Conditional branch instruction that decrements a register and jumps 26177 if the register is nonzero. Operand 0 is the register to decrement 26178 and test; operand 1 is the label to jump to if the register is 26179 nonzero. *Note Looping Patterns::. 26180 26181 This optional instruction pattern is only used by the combiner, 26182 typically for loops reversed by the loop optimizer when strength 26183 reduction is enabled. 26184 26185'doloop_end' 26186 Conditional branch instruction that decrements a register and jumps 26187 if the register is nonzero. Operand 0 is the register to decrement 26188 and test; operand 1 is the label to jump to if the register is 26189 nonzero. *Note Looping Patterns::. 26190 26191 This optional instruction pattern should be defined for machines 26192 with low-overhead looping instructions as the loop optimizer will 26193 try to modify suitable loops to utilize it. The target hook 26194 'TARGET_CAN_USE_DOLOOP_P' controls the conditions under which 26195 low-overhead loops can be used. 26196 26197'doloop_begin' 26198 Companion instruction to 'doloop_end' required for machines that 26199 need to perform some initialization, such as loading a special 26200 counter register. Operand 1 is the associated 'doloop_end' pattern 26201 and operand 0 is the register that it decrements. 26202 26203 If initialization insns do not always need to be emitted, use a 26204 'define_expand' (*note Expander Definitions::) and make it fail. 26205 26206'canonicalize_funcptr_for_compare' 26207 Canonicalize the function pointer in operand 1 and store the result 26208 into operand 0. 26209 26210 Operand 0 is always a 'reg' and has mode 'Pmode'; operand 1 may be 26211 a 'reg', 'mem', 'symbol_ref', 'const_int', etc and also has mode 26212 'Pmode'. 26213 26214 Canonicalization of a function pointer usually involves computing 26215 the address of the function which would be called if the function 26216 pointer were used in an indirect call. 26217 26218 Only define this pattern if function pointers on the target machine 26219 can have different values but still call the same function when 26220 used in an indirect call. 26221 26222'save_stack_block' 26223'save_stack_function' 26224'save_stack_nonlocal' 26225'restore_stack_block' 26226'restore_stack_function' 26227'restore_stack_nonlocal' 26228 Most machines save and restore the stack pointer by copying it to 26229 or from an object of mode 'Pmode'. Do not define these patterns on 26230 such machines. 26231 26232 Some machines require special handling for stack pointer saves and 26233 restores. On those machines, define the patterns corresponding to 26234 the non-standard cases by using a 'define_expand' (*note Expander 26235 Definitions::) that produces the required insns. The three types 26236 of saves and restores are: 26237 26238 1. 'save_stack_block' saves the stack pointer at the start of a 26239 block that allocates a variable-sized object, and 26240 'restore_stack_block' restores the stack pointer when the 26241 block is exited. 26242 26243 2. 'save_stack_function' and 'restore_stack_function' do a 26244 similar job for the outermost block of a function and are used 26245 when the function allocates variable-sized objects or calls 26246 'alloca'. Only the epilogue uses the restored stack pointer, 26247 allowing a simpler save or restore sequence on some machines. 26248 26249 3. 'save_stack_nonlocal' is used in functions that contain labels 26250 branched to by nested functions. It saves the stack pointer 26251 in such a way that the inner function can use 26252 'restore_stack_nonlocal' to restore the stack pointer. The 26253 compiler generates code to restore the frame and argument 26254 pointer registers, but some machines require saving and 26255 restoring additional data such as register window information 26256 or stack backchains. Place insns in these patterns to save 26257 and restore any such required data. 26258 26259 When saving the stack pointer, operand 0 is the save area and 26260 operand 1 is the stack pointer. The mode used to allocate the save 26261 area defaults to 'Pmode' but you can override that choice by 26262 defining the 'STACK_SAVEAREA_MODE' macro (*note Storage Layout::). 26263 You must specify an integral mode, or 'VOIDmode' if no save area is 26264 needed for a particular type of save (either because no save is 26265 needed or because a machine-specific save area can be used). 26266 Operand 0 is the stack pointer and operand 1 is the save area for 26267 restore operations. If 'save_stack_block' is defined, operand 0 26268 must not be 'VOIDmode' since these saves can be arbitrarily nested. 26269 26270 A save area is a 'mem' that is at a constant offset from 26271 'virtual_stack_vars_rtx' when the stack pointer is saved for use by 26272 nonlocal gotos and a 'reg' in the other two cases. 26273 26274'allocate_stack' 26275 Subtract (or add if 'STACK_GROWS_DOWNWARD' is undefined) operand 1 26276 from the stack pointer to create space for dynamically allocated 26277 data. 26278 26279 Store the resultant pointer to this space into operand 0. If you 26280 are allocating space from the main stack, do this by emitting a 26281 move insn to copy 'virtual_stack_dynamic_rtx' to operand 0. If you 26282 are allocating the space elsewhere, generate code to copy the 26283 location of the space to operand 0. In the latter case, you must 26284 ensure this space gets freed when the corresponding space on the 26285 main stack is free. 26286 26287 Do not define this pattern if all that must be done is the 26288 subtraction. Some machines require other operations such as stack 26289 probes or maintaining the back chain. Define this pattern to emit 26290 those operations in addition to updating the stack pointer. 26291 26292'check_stack' 26293 If stack checking (*note Stack Checking::) cannot be done on your 26294 system by probing the stack, define this pattern to perform the 26295 needed check and signal an error if the stack has overflowed. The 26296 single operand is the address in the stack farthest from the 26297 current stack pointer that you need to validate. Normally, on 26298 platforms where this pattern is needed, you would obtain the stack 26299 limit from a global or thread-specific variable or register. 26300 26301'probe_stack_address' 26302 If stack checking (*note Stack Checking::) can be done on your 26303 system by probing the stack but without the need to actually access 26304 it, define this pattern and signal an error if the stack has 26305 overflowed. The single operand is the memory address in the stack 26306 that needs to be probed. 26307 26308'probe_stack' 26309 If stack checking (*note Stack Checking::) can be done on your 26310 system by probing the stack but doing it with a "store zero" 26311 instruction is not valid or optimal, define this pattern to do the 26312 probing differently and signal an error if the stack has 26313 overflowed. The single operand is the memory reference in the 26314 stack that needs to be probed. 26315 26316'nonlocal_goto' 26317 Emit code to generate a non-local goto, e.g., a jump from one 26318 function to a label in an outer function. This pattern has four 26319 arguments, each representing a value to be used in the jump. The 26320 first argument is to be loaded into the frame pointer, the second 26321 is the address to branch to (code to dispatch to the actual label), 26322 the third is the address of a location where the stack is saved, 26323 and the last is the address of the label, to be placed in the 26324 location for the incoming static chain. 26325 26326 On most machines you need not define this pattern, since GCC will 26327 already generate the correct code, which is to load the frame 26328 pointer and static chain, restore the stack (using the 26329 'restore_stack_nonlocal' pattern, if defined), and jump indirectly 26330 to the dispatcher. You need only define this pattern if this code 26331 will not work on your machine. 26332 26333'nonlocal_goto_receiver' 26334 This pattern, if defined, contains code needed at the target of a 26335 nonlocal goto after the code already generated by GCC. You will 26336 not normally need to define this pattern. A typical reason why you 26337 might need this pattern is if some value, such as a pointer to a 26338 global table, must be restored when the frame pointer is restored. 26339 Note that a nonlocal goto only occurs within a unit-of-translation, 26340 so a global table pointer that is shared by all functions of a 26341 given module need not be restored. There are no arguments. 26342 26343'exception_receiver' 26344 This pattern, if defined, contains code needed at the site of an 26345 exception handler that isn't needed at the site of a nonlocal goto. 26346 You will not normally need to define this pattern. A typical 26347 reason why you might need this pattern is if some value, such as a 26348 pointer to a global table, must be restored after control flow is 26349 branched to the handler of an exception. There are no arguments. 26350 26351'builtin_setjmp_setup' 26352 This pattern, if defined, contains additional code needed to 26353 initialize the 'jmp_buf'. You will not normally need to define 26354 this pattern. A typical reason why you might need this pattern is 26355 if some value, such as a pointer to a global table, must be 26356 restored. Though it is preferred that the pointer value be 26357 recalculated if possible (given the address of a label for 26358 instance). The single argument is a pointer to the 'jmp_buf'. 26359 Note that the buffer is five words long and that the first three 26360 are normally used by the generic mechanism. 26361 26362'builtin_setjmp_receiver' 26363 This pattern, if defined, contains code needed at the site of a 26364 built-in setjmp that isn't needed at the site of a nonlocal goto. 26365 You will not normally need to define this pattern. A typical 26366 reason why you might need this pattern is if some value, such as a 26367 pointer to a global table, must be restored. It takes one 26368 argument, which is the label to which builtin_longjmp transferred 26369 control; this pattern may be emitted at a small offset from that 26370 label. 26371 26372'builtin_longjmp' 26373 This pattern, if defined, performs the entire action of the 26374 longjmp. You will not normally need to define this pattern unless 26375 you also define 'builtin_setjmp_setup'. The single argument is a 26376 pointer to the 'jmp_buf'. 26377 26378'eh_return' 26379 This pattern, if defined, affects the way '__builtin_eh_return', 26380 and thence the call frame exception handling library routines, are 26381 built. It is intended to handle non-trivial actions needed along 26382 the abnormal return path. 26383 26384 The address of the exception handler to which the function should 26385 return is passed as operand to this pattern. It will normally need 26386 to copied by the pattern to some special register or memory 26387 location. If the pattern needs to determine the location of the 26388 target call frame in order to do so, it may use 26389 'EH_RETURN_STACKADJ_RTX', if defined; it will have already been 26390 assigned. 26391 26392 If this pattern is not defined, the default action will be to 26393 simply copy the return address to 'EH_RETURN_HANDLER_RTX'. Either 26394 that macro or this pattern needs to be defined if call frame 26395 exception handling is to be used. 26396 26397'prologue' 26398 This pattern, if defined, emits RTL for entry to a function. The 26399 function entry is responsible for setting up the stack frame, 26400 initializing the frame pointer register, saving callee saved 26401 registers, etc. 26402 26403 Using a prologue pattern is generally preferred over defining 26404 'TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the 26405 prologue. 26406 26407 The 'prologue' pattern is particularly useful for targets which 26408 perform instruction scheduling. 26409 26410'window_save' 26411 This pattern, if defined, emits RTL for a register window save. It 26412 should be defined if the target machine has register windows but 26413 the window events are decoupled from calls to subroutines. The 26414 canonical example is the SPARC architecture. 26415 26416'epilogue' 26417 This pattern emits RTL for exit from a function. The function exit 26418 is responsible for deallocating the stack frame, restoring callee 26419 saved registers and emitting the return instruction. 26420 26421 Using an epilogue pattern is generally preferred over defining 26422 'TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the 26423 epilogue. 26424 26425 The 'epilogue' pattern is particularly useful for targets which 26426 perform instruction scheduling or which have delay slots for their 26427 return instruction. 26428 26429'sibcall_epilogue' 26430 This pattern, if defined, emits RTL for exit from a function 26431 without the final branch back to the calling function. This 26432 pattern will be emitted before any sibling call (aka tail call) 26433 sites. 26434 26435 The 'sibcall_epilogue' pattern must not clobber any arguments used 26436 for parameter passing or any stack slots for arguments passed to 26437 the current function. 26438 26439'trap' 26440 This pattern, if defined, signals an error, typically by causing 26441 some kind of signal to be raised. 26442 26443'ctrapMM4' 26444 Conditional trap instruction. Operand 0 is a piece of RTL which 26445 performs a comparison, and operands 1 and 2 are the arms of the 26446 comparison. Operand 3 is the trap code, an integer. 26447 26448 A typical 'ctrap' pattern looks like 26449 26450 (define_insn "ctrapsi4" 26451 [(trap_if (match_operator 0 "trap_operator" 26452 [(match_operand 1 "register_operand") 26453 (match_operand 2 "immediate_operand")]) 26454 (match_operand 3 "const_int_operand" "i"))] 26455 "" 26456 "...") 26457 26458'prefetch' 26459 This pattern, if defined, emits code for a non-faulting data 26460 prefetch instruction. Operand 0 is the address of the memory to 26461 prefetch. Operand 1 is a constant 1 if the prefetch is preparing 26462 for a write to the memory address, or a constant 0 otherwise. 26463 Operand 2 is the expected degree of temporal locality of the data 26464 and is a value between 0 and 3, inclusive; 0 means that the data 26465 has no temporal locality, so it need not be left in the cache after 26466 the access; 3 means that the data has a high degree of temporal 26467 locality and should be left in all levels of cache possible; 1 and 26468 2 mean, respectively, a low or moderate degree of temporal 26469 locality. 26470 26471 Targets that do not support write prefetches or locality hints can 26472 ignore the values of operands 1 and 2. 26473 26474'blockage' 26475 This pattern defines a pseudo insn that prevents the instruction 26476 scheduler and other passes from moving instructions and using 26477 register equivalences across the boundary defined by the blockage 26478 insn. This needs to be an UNSPEC_VOLATILE pattern or a volatile 26479 ASM. 26480 26481'memory_blockage' 26482 This pattern, if defined, represents a compiler memory barrier, and 26483 will be placed at points across which RTL passes may not propagate 26484 memory accesses. This instruction needs to read and write volatile 26485 BLKmode memory. It does not need to generate any machine 26486 instruction. If this pattern is not defined, the compiler falls 26487 back to emitting an instruction corresponding to 'asm volatile ("" 26488 ::: "memory")'. 26489 26490'memory_barrier' 26491 If the target memory model is not fully synchronous, then this 26492 pattern should be defined to an instruction that orders both loads 26493 and stores before the instruction with respect to loads and stores 26494 after the instruction. This pattern has no operands. 26495 26496'sync_compare_and_swapMODE' 26497 This pattern, if defined, emits code for an atomic compare-and-swap 26498 operation. Operand 1 is the memory on which the atomic operation 26499 is performed. Operand 2 is the "old" value to be compared against 26500 the current contents of the memory location. Operand 3 is the 26501 "new" value to store in the memory if the compare succeeds. 26502 Operand 0 is the result of the operation; it should contain the 26503 contents of the memory before the operation. If the compare 26504 succeeds, this should obviously be a copy of operand 2. 26505 26506 This pattern must show that both operand 0 and operand 1 are 26507 modified. 26508 26509 This pattern must issue any memory barrier instructions such that 26510 all memory operations before the atomic operation occur before the 26511 atomic operation and all memory operations after the atomic 26512 operation occur after the atomic operation. 26513 26514 For targets where the success or failure of the compare-and-swap 26515 operation is available via the status flags, it is possible to 26516 avoid a separate compare operation and issue the subsequent branch 26517 or store-flag operation immediately after the compare-and-swap. To 26518 this end, GCC will look for a 'MODE_CC' set in the output of 26519 'sync_compare_and_swapMODE'; if the machine description includes 26520 such a set, the target should also define special 'cbranchcc4' 26521 and/or 'cstorecc4' instructions. GCC will then be able to take the 26522 destination of the 'MODE_CC' set and pass it to the 'cbranchcc4' or 26523 'cstorecc4' pattern as the first operand of the comparison (the 26524 second will be '(const_int 0)'). 26525 26526 For targets where the operating system may provide support for this 26527 operation via library calls, the 'sync_compare_and_swap_optab' may 26528 be initialized to a function with the same interface as the 26529 '__sync_val_compare_and_swap_N' built-in. If the entire set of 26530 __SYNC builtins are supported via library calls, the target can 26531 initialize all of the optabs at once with 'init_sync_libfuncs'. 26532 For the purposes of C++11 'std::atomic::is_lock_free', it is 26533 assumed that these library calls do _not_ use any kind of 26534 interruptable locking. 26535 26536'sync_addMODE', 'sync_subMODE' 26537'sync_iorMODE', 'sync_andMODE' 26538'sync_xorMODE', 'sync_nandMODE' 26539 These patterns emit code for an atomic operation on memory. 26540 Operand 0 is the memory on which the atomic operation is performed. 26541 Operand 1 is the second operand to the binary operator. 26542 26543 This pattern must issue any memory barrier instructions such that 26544 all memory operations before the atomic operation occur before the 26545 atomic operation and all memory operations after the atomic 26546 operation occur after the atomic operation. 26547 26548 If these patterns are not defined, the operation will be 26549 constructed from a compare-and-swap operation, if defined. 26550 26551'sync_old_addMODE', 'sync_old_subMODE' 26552'sync_old_iorMODE', 'sync_old_andMODE' 26553'sync_old_xorMODE', 'sync_old_nandMODE' 26554 These patterns emit code for an atomic operation on memory, and 26555 return the value that the memory contained before the operation. 26556 Operand 0 is the result value, operand 1 is the memory on which the 26557 atomic operation is performed, and operand 2 is the second operand 26558 to the binary operator. 26559 26560 This pattern must issue any memory barrier instructions such that 26561 all memory operations before the atomic operation occur before the 26562 atomic operation and all memory operations after the atomic 26563 operation occur after the atomic operation. 26564 26565 If these patterns are not defined, the operation will be 26566 constructed from a compare-and-swap operation, if defined. 26567 26568'sync_new_addMODE', 'sync_new_subMODE' 26569'sync_new_iorMODE', 'sync_new_andMODE' 26570'sync_new_xorMODE', 'sync_new_nandMODE' 26571 These patterns are like their 'sync_old_OP' counterparts, except 26572 that they return the value that exists in the memory location after 26573 the operation, rather than before the operation. 26574 26575'sync_lock_test_and_setMODE' 26576 This pattern takes two forms, based on the capabilities of the 26577 target. In either case, operand 0 is the result of the operand, 26578 operand 1 is the memory on which the atomic operation is performed, 26579 and operand 2 is the value to set in the lock. 26580 26581 In the ideal case, this operation is an atomic exchange operation, 26582 in which the previous value in memory operand is copied into the 26583 result operand, and the value operand is stored in the memory 26584 operand. 26585 26586 For less capable targets, any value operand that is not the 26587 constant 1 should be rejected with 'FAIL'. In this case the target 26588 may use an atomic test-and-set bit operation. The result operand 26589 should contain 1 if the bit was previously set and 0 if the bit was 26590 previously clear. The true contents of the memory operand are 26591 implementation defined. 26592 26593 This pattern must issue any memory barrier instructions such that 26594 the pattern as a whole acts as an acquire barrier, that is all 26595 memory operations after the pattern do not occur until the lock is 26596 acquired. 26597 26598 If this pattern is not defined, the operation will be constructed 26599 from a compare-and-swap operation, if defined. 26600 26601'sync_lock_releaseMODE' 26602 This pattern, if defined, releases a lock set by 26603 'sync_lock_test_and_setMODE'. Operand 0 is the memory that 26604 contains the lock; operand 1 is the value to store in the lock. 26605 26606 If the target doesn't implement full semantics for 26607 'sync_lock_test_and_setMODE', any value operand which is not the 26608 constant 0 should be rejected with 'FAIL', and the true contents of 26609 the memory operand are implementation defined. 26610 26611 This pattern must issue any memory barrier instructions such that 26612 the pattern as a whole acts as a release barrier, that is the lock 26613 is released only after all previous memory operations have 26614 completed. 26615 26616 If this pattern is not defined, then a 'memory_barrier' pattern 26617 will be emitted, followed by a store of the value to the memory 26618 operand. 26619 26620'atomic_compare_and_swapMODE' 26621 This pattern, if defined, emits code for an atomic compare-and-swap 26622 operation with memory model semantics. Operand 2 is the memory on 26623 which the atomic operation is performed. Operand 0 is an output 26624 operand which is set to true or false based on whether the 26625 operation succeeded. Operand 1 is an output operand which is set 26626 to the contents of the memory before the operation was attempted. 26627 Operand 3 is the value that is expected to be in memory. Operand 4 26628 is the value to put in memory if the expected value is found there. 26629 Operand 5 is set to 1 if this compare and swap is to be treated as 26630 a weak operation. Operand 6 is the memory model to be used if the 26631 operation is a success. Operand 7 is the memory model to be used 26632 if the operation fails. 26633 26634 If memory referred to in operand 2 contains the value in operand 3, 26635 then operand 4 is stored in memory pointed to by operand 2 and 26636 fencing based on the memory model in operand 6 is issued. 26637 26638 If memory referred to in operand 2 does not contain the value in 26639 operand 3, then fencing based on the memory model in operand 7 is 26640 issued. 26641 26642 If a target does not support weak compare-and-swap operations, or 26643 the port elects not to implement weak operations, the argument in 26644 operand 5 can be ignored. Note a strong implementation must be 26645 provided. 26646 26647 If this pattern is not provided, the '__atomic_compare_exchange' 26648 built-in functions will utilize the legacy 'sync_compare_and_swap' 26649 pattern with an '__ATOMIC_SEQ_CST' memory model. 26650 26651'atomic_loadMODE' 26652 This pattern implements an atomic load operation with memory model 26653 semantics. Operand 1 is the memory address being loaded from. 26654 Operand 0 is the result of the load. Operand 2 is the memory model 26655 to be used for the load operation. 26656 26657 If not present, the '__atomic_load' built-in function will either 26658 resort to a normal load with memory barriers, or a compare-and-swap 26659 operation if a normal load would not be atomic. 26660 26661'atomic_storeMODE' 26662 This pattern implements an atomic store operation with memory model 26663 semantics. Operand 0 is the memory address being stored to. 26664 Operand 1 is the value to be written. Operand 2 is the memory 26665 model to be used for the operation. 26666 26667 If not present, the '__atomic_store' built-in function will attempt 26668 to perform a normal store and surround it with any required memory 26669 fences. If the store would not be atomic, then an 26670 '__atomic_exchange' is attempted with the result being ignored. 26671 26672'atomic_exchangeMODE' 26673 This pattern implements an atomic exchange operation with memory 26674 model semantics. Operand 1 is the memory location the operation is 26675 performed on. Operand 0 is an output operand which is set to the 26676 original value contained in the memory pointed to by operand 1. 26677 Operand 2 is the value to be stored. Operand 3 is the memory model 26678 to be used. 26679 26680 If this pattern is not present, the built-in function 26681 '__atomic_exchange' will attempt to preform the operation with a 26682 compare and swap loop. 26683 26684'atomic_addMODE', 'atomic_subMODE' 26685'atomic_orMODE', 'atomic_andMODE' 26686'atomic_xorMODE', 'atomic_nandMODE' 26687 These patterns emit code for an atomic operation on memory with 26688 memory model semantics. Operand 0 is the memory on which the 26689 atomic operation is performed. Operand 1 is the second operand to 26690 the binary operator. Operand 2 is the memory model to be used by 26691 the operation. 26692 26693 If these patterns are not defined, attempts will be made to use 26694 legacy 'sync' patterns, or equivalent patterns which return a 26695 result. If none of these are available a compare-and-swap loop 26696 will be used. 26697 26698'atomic_fetch_addMODE', 'atomic_fetch_subMODE' 26699'atomic_fetch_orMODE', 'atomic_fetch_andMODE' 26700'atomic_fetch_xorMODE', 'atomic_fetch_nandMODE' 26701 These patterns emit code for an atomic operation on memory with 26702 memory model semantics, and return the original value. Operand 0 26703 is an output operand which contains the value of the memory 26704 location before the operation was performed. Operand 1 is the 26705 memory on which the atomic operation is performed. Operand 2 is 26706 the second operand to the binary operator. Operand 3 is the memory 26707 model to be used by the operation. 26708 26709 If these patterns are not defined, attempts will be made to use 26710 legacy 'sync' patterns. If none of these are available a 26711 compare-and-swap loop will be used. 26712 26713'atomic_add_fetchMODE', 'atomic_sub_fetchMODE' 26714'atomic_or_fetchMODE', 'atomic_and_fetchMODE' 26715'atomic_xor_fetchMODE', 'atomic_nand_fetchMODE' 26716 These patterns emit code for an atomic operation on memory with 26717 memory model semantics and return the result after the operation is 26718 performed. Operand 0 is an output operand which contains the value 26719 after the operation. Operand 1 is the memory on which the atomic 26720 operation is performed. Operand 2 is the second operand to the 26721 binary operator. Operand 3 is the memory model to be used by the 26722 operation. 26723 26724 If these patterns are not defined, attempts will be made to use 26725 legacy 'sync' patterns, or equivalent patterns which return the 26726 result before the operation followed by the arithmetic operation 26727 required to produce the result. If none of these are available a 26728 compare-and-swap loop will be used. 26729 26730'atomic_test_and_set' 26731 This pattern emits code for '__builtin_atomic_test_and_set'. 26732 Operand 0 is an output operand which is set to true if the previous 26733 previous contents of the byte was "set", and false otherwise. 26734 Operand 1 is the 'QImode' memory to be modified. Operand 2 is the 26735 memory model to be used. 26736 26737 The specific value that defines "set" is implementation defined, 26738 and is normally based on what is performed by the native atomic 26739 test and set instruction. 26740 26741'atomic_bit_test_and_setMODE' 26742'atomic_bit_test_and_complementMODE' 26743'atomic_bit_test_and_resetMODE' 26744 These patterns emit code for an atomic bitwise operation on memory 26745 with memory model semantics, and return the original value of the 26746 specified bit. Operand 0 is an output operand which contains the 26747 value of the specified bit from the memory location before the 26748 operation was performed. Operand 1 is the memory on which the 26749 atomic operation is performed. Operand 2 is the bit within the 26750 operand, starting with least significant bit. Operand 3 is the 26751 memory model to be used by the operation. Operand 4 is a flag - it 26752 is 'const1_rtx' if operand 0 should contain the original value of 26753 the specified bit in the least significant bit of the operand, and 26754 'const0_rtx' if the bit should be in its original position in the 26755 operand. 'atomic_bit_test_and_setMODE' atomically sets the 26756 specified bit after remembering its original value, 26757 'atomic_bit_test_and_complementMODE' inverts the specified bit and 26758 'atomic_bit_test_and_resetMODE' clears the specified bit. 26759 26760 If these patterns are not defined, attempts will be made to use 26761 'atomic_fetch_orMODE', 'atomic_fetch_xorMODE' or 26762 'atomic_fetch_andMODE' instruction patterns, or their 'sync' 26763 counterparts. If none of these are available a compare-and-swap 26764 loop will be used. 26765 26766'mem_thread_fence' 26767 This pattern emits code required to implement a thread fence with 26768 memory model semantics. Operand 0 is the memory model to be used. 26769 26770 For the '__ATOMIC_RELAXED' model no instructions need to be issued 26771 and this expansion is not invoked. 26772 26773 The compiler always emits a compiler memory barrier regardless of 26774 what expanding this pattern produced. 26775 26776 If this pattern is not defined, the compiler falls back to 26777 expanding the 'memory_barrier' pattern, then to emitting 26778 '__sync_synchronize' library call, and finally to just placing a 26779 compiler memory barrier. 26780 26781'get_thread_pointerMODE' 26782'set_thread_pointerMODE' 26783 These patterns emit code that reads/sets the TLS thread pointer. 26784 Currently, these are only needed if the target needs to support the 26785 '__builtin_thread_pointer' and '__builtin_set_thread_pointer' 26786 builtins. 26787 26788 The get/set patterns have a single output/input operand 26789 respectively, with MODE intended to be 'Pmode'. 26790 26791'stack_protect_set' 26792 This pattern, if defined, moves a 'ptr_mode' value from the memory 26793 in operand 1 to the memory in operand 0 without leaving the value 26794 in a register afterward. This is to avoid leaking the value some 26795 place that an attacker might use to rewrite the stack guard slot 26796 after having clobbered it. 26797 26798 If this pattern is not defined, then a plain move pattern is 26799 generated. 26800 26801'stack_protect_test' 26802 This pattern, if defined, compares a 'ptr_mode' value from the 26803 memory in operand 1 with the memory in operand 0 without leaving 26804 the value in a register afterward and branches to operand 2 if the 26805 values were equal. 26806 26807 If this pattern is not defined, then a plain compare pattern and 26808 conditional branch pattern is used. 26809 26810'clear_cache' 26811 This pattern, if defined, flushes the instruction cache for a 26812 region of memory. The region is bounded to by the Pmode pointers 26813 in operand 0 inclusive and operand 1 exclusive. 26814 26815 If this pattern is not defined, a call to the library function 26816 '__clear_cache' is used. 26817 26818 26819File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc 26820 2682117.10 When the Order of Patterns Matters 26822======================================== 26823 26824Sometimes an insn can match more than one instruction pattern. Then the 26825pattern that appears first in the machine description is the one used. 26826Therefore, more specific patterns (patterns that will match fewer 26827things) and faster instructions (those that will produce better code 26828when they do match) should usually go first in the description. 26829 26830 In some cases the effect of ordering the patterns can be used to hide a 26831pattern when it is not valid. For example, the 68000 has an instruction 26832for converting a fullword to floating point and another for converting a 26833byte to floating point. An instruction converting an integer to 26834floating point could match either one. We put the pattern to convert 26835the fullword first to make sure that one will be used rather than the 26836other. (Otherwise a large integer might be generated as a single-byte 26837immediate quantity, which would not work.) Instead of using this 26838pattern ordering it would be possible to make the pattern for 26839convert-a-byte smart enough to deal properly with any constant value. 26840 26841 26842File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc 26843 2684417.11 Interdependence of Patterns 26845================================= 26846 26847In some cases machines support instructions identical except for the 26848machine mode of one or more operands. For example, there may be 26849"sign-extend halfword" and "sign-extend byte" instructions whose 26850patterns are 26851 26852 (set (match_operand:SI 0 ...) 26853 (extend:SI (match_operand:HI 1 ...))) 26854 26855 (set (match_operand:SI 0 ...) 26856 (extend:SI (match_operand:QI 1 ...))) 26857 26858Constant integers do not specify a machine mode, so an instruction to 26859extend a constant value could match either pattern. The pattern it 26860actually will match is the one that appears first in the file. For 26861correct results, this must be the one for the widest possible mode 26862('HImode', here). If the pattern matches the 'QImode' instruction, the 26863results will be incorrect if the constant value does not actually fit 26864that mode. 26865 26866 Such instructions to extend constants are rarely generated because they 26867are optimized away, but they do occasionally happen in nonoptimized 26868compilations. 26869 26870 If a constraint in a pattern allows a constant, the reload pass may 26871replace a register with a constant permitted by the constraint in some 26872cases. Similarly for memory references. Because of this substitution, 26873you should not provide separate patterns for increment and decrement 26874instructions. Instead, they should be generated from the same pattern 26875that supports register-register add insns by examining the operands and 26876generating the appropriate machine instruction. 26877 26878 26879File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc 26880 2688117.12 Defining Jump Instruction Patterns 26882======================================== 26883 26884GCC does not assume anything about how the machine realizes jumps. The 26885machine description should define a single pattern, usually a 26886'define_expand', which expands to all the required insns. 26887 26888 Usually, this would be a comparison insn to set the condition code and 26889a separate branch insn testing the condition code and branching or not 26890according to its value. For many machines, however, separating compares 26891and branches is limiting, which is why the more flexible approach with 26892one 'define_expand' is used in GCC. The machine description becomes 26893clearer for architectures that have compare-and-branch instructions but 26894no condition code. It also works better when different sets of 26895comparison operators are supported by different kinds of conditional 26896branches (e.g. integer vs. floating-point), or by conditional branches 26897with respect to conditional stores. 26898 26899 Two separate insns are always used if the machine description 26900represents a condition code register using the legacy RTL expression 26901'(cc0)', and on most machines that use a separate condition code 26902register (*note Condition Code::). For machines that use '(cc0)', in 26903fact, the set and use of the condition code must be separate and 26904adjacent(1), thus allowing flags in 'cc_status' to be used (*note 26905Condition Code::) and so that the comparison and branch insns could be 26906located from each other by using the functions 'prev_cc0_setter' and 26907'next_cc0_user'. 26908 26909 Even in this case having a single entry point for conditional branches 26910is advantageous, because it handles equally well the case where a single 26911comparison instruction records the results of both signed and unsigned 26912comparison of the given operands (with the branch insns coming in 26913distinct signed and unsigned flavors) as in the x86 or SPARC, and the 26914case where there are distinct signed and unsigned compare instructions 26915and only one set of conditional branch instructions as in the PowerPC. 26916 26917 ---------- Footnotes ---------- 26918 26919 (1) 'note' insns can separate them, though. 26920 26921 26922File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc 26923 2692417.13 Defining Looping Instruction Patterns 26925=========================================== 26926 26927Some machines have special jump instructions that can be utilized to 26928make loops more efficient. A common example is the 68000 'dbra' 26929instruction which performs a decrement of a register and a branch if the 26930result was greater than zero. Other machines, in particular digital 26931signal processors (DSPs), have special block repeat instructions to 26932provide low-overhead loop support. For example, the TI TMS320C3x/C4x 26933DSPs have a block repeat instruction that loads special registers to 26934mark the top and end of a loop and to count the number of loop 26935iterations. This avoids the need for fetching and executing a 26936'dbra'-like instruction and avoids pipeline stalls associated with the 26937jump. 26938 26939 GCC has three special named patterns to support low overhead looping. 26940They are 'decrement_and_branch_until_zero', 'doloop_begin', and 26941'doloop_end'. The first pattern, 'decrement_and_branch_until_zero', is 26942not emitted during RTL generation but may be emitted during the 26943instruction combination phase. This requires the assistance of the loop 26944optimizer, using information collected during strength reduction, to 26945reverse a loop to count down to zero. Some targets also require the 26946loop optimizer to add a 'REG_NONNEG' note to indicate that the iteration 26947count is always positive. This is needed if the target performs a 26948signed loop termination test. For example, the 68000 uses a pattern 26949similar to the following for its 'dbra' instruction: 26950 26951 (define_insn "decrement_and_branch_until_zero" 26952 [(set (pc) 26953 (if_then_else 26954 (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am") 26955 (const_int -1)) 26956 (const_int 0)) 26957 (label_ref (match_operand 1 "" "")) 26958 (pc))) 26959 (set (match_dup 0) 26960 (plus:SI (match_dup 0) 26961 (const_int -1)))] 26962 "find_reg_note (insn, REG_NONNEG, 0)" 26963 "...") 26964 26965 Note that since the insn is both a jump insn and has an output, it must 26966deal with its own reloads, hence the 'm' constraints. Also note that 26967since this insn is generated by the instruction combination phase 26968combining two sequential insns together into an implicit parallel insn, 26969the iteration counter needs to be biased by the same amount as the 26970decrement operation, in this case -1. Note that the following similar 26971pattern will not be matched by the combiner. 26972 26973 (define_insn "decrement_and_branch_until_zero" 26974 [(set (pc) 26975 (if_then_else 26976 (ge (match_operand:SI 0 "general_operand" "+d*am") 26977 (const_int 1)) 26978 (label_ref (match_operand 1 "" "")) 26979 (pc))) 26980 (set (match_dup 0) 26981 (plus:SI (match_dup 0) 26982 (const_int -1)))] 26983 "find_reg_note (insn, REG_NONNEG, 0)" 26984 "...") 26985 26986 The other two special looping patterns, 'doloop_begin' and 26987'doloop_end', are emitted by the loop optimizer for certain well-behaved 26988loops with a finite number of loop iterations using information 26989collected during strength reduction. 26990 26991 The 'doloop_end' pattern describes the actual looping instruction (or 26992the implicit looping operation) and the 'doloop_begin' pattern is an 26993optional companion pattern that can be used for initialization needed 26994for some low-overhead looping instructions. 26995 26996 Note that some machines require the actual looping instruction to be 26997emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting 26998the true RTL for a looping instruction at the top of the loop can cause 26999problems with flow analysis. So instead, a dummy 'doloop' insn is 27000emitted at the end of the loop. The machine dependent reorg pass checks 27001for the presence of this 'doloop' insn and then searches back to the top 27002of the loop, where it inserts the true looping insn (provided there are 27003no instructions in the loop which would cause problems). Any additional 27004labels can be emitted at this point. In addition, if the desired 27005special iteration counter register was not allocated, this machine 27006dependent reorg pass could emit a traditional compare and jump 27007instruction pair. 27008 27009 The essential difference between the 'decrement_and_branch_until_zero' 27010and the 'doloop_end' patterns is that the loop optimizer allocates an 27011additional pseudo register for the latter as an iteration counter. This 27012pseudo register cannot be used within the loop (i.e., general induction 27013variables cannot be derived from it), however, in many cases the loop 27014induction variable may become redundant and removed by the flow pass. 27015 27016 27017File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc 27018 2701917.14 Canonicalization of Instructions 27020====================================== 27021 27022There are often cases where multiple RTL expressions could represent an 27023operation performed by a single machine instruction. This situation is 27024most commonly encountered with logical, branch, and multiply-accumulate 27025instructions. In such cases, the compiler attempts to convert these 27026multiple RTL expressions into a single canonical form to reduce the 27027number of insn patterns required. 27028 27029 In addition to algebraic simplifications, following canonicalizations 27030are performed: 27031 27032 * For commutative and comparison operators, a constant is always made 27033 the second operand. If a machine only supports a constant as the 27034 second operand, only patterns that match a constant in the second 27035 operand need be supplied. 27036 27037 * For associative operators, a sequence of operators will always 27038 chain to the left; for instance, only the left operand of an 27039 integer 'plus' can itself be a 'plus'. 'and', 'ior', 'xor', 27040 'plus', 'mult', 'smin', 'smax', 'umin', and 'umax' are associative 27041 when applied to integers, and sometimes to floating-point. 27042 27043 * For these operators, if only one operand is a 'neg', 'not', 'mult', 27044 'plus', or 'minus' expression, it will be the first operand. 27045 27046 * In combinations of 'neg', 'mult', 'plus', and 'minus', the 'neg' 27047 operations (if any) will be moved inside the operations as far as 27048 possible. For instance, '(neg (mult A B))' is canonicalized as 27049 '(mult (neg A) B)', but '(plus (mult (neg B) C) A)' is 27050 canonicalized as '(minus A (mult B C))'. 27051 27052 * For the 'compare' operator, a constant is always the second operand 27053 if the first argument is a condition code register or '(cc0)'. 27054 27055 * For instructions that inherently set a condition code register, the 27056 'compare' operator is always written as the first RTL expression of 27057 the 'parallel' instruction pattern. For example, 27058 27059 (define_insn "" 27060 [(set (reg:CCZ FLAGS_REG) 27061 (compare:CCZ 27062 (plus:SI 27063 (match_operand:SI 1 "register_operand" "%r") 27064 (match_operand:SI 2 "register_operand" "r")) 27065 (const_int 0))) 27066 (set (match_operand:SI 0 "register_operand" "=r") 27067 (plus:SI (match_dup 1) (match_dup 2)))] 27068 "" 27069 "addl %0, %1, %2") 27070 27071 * An operand of 'neg', 'not', 'mult', 'plus', or 'minus' is made the 27072 first operand under the same conditions as above. 27073 27074 * '(ltu (plus A B) B)' is converted to '(ltu (plus A B) A)'. 27075 Likewise with 'geu' instead of 'ltu'. 27076 27077 * '(minus X (const_int N))' is converted to '(plus X (const_int 27078 -N))'. 27079 27080 * Within address computations (i.e., inside 'mem'), a left shift is 27081 converted into the appropriate multiplication by a power of two. 27082 27083 * De Morgan's Law is used to move bitwise negation inside a bitwise 27084 logical-and or logical-or operation. If this results in only one 27085 operand being a 'not' expression, it will be the first one. 27086 27087 A machine that has an instruction that performs a bitwise 27088 logical-and of one operand with the bitwise negation of the other 27089 should specify the pattern for that instruction as 27090 27091 (define_insn "" 27092 [(set (match_operand:M 0 ...) 27093 (and:M (not:M (match_operand:M 1 ...)) 27094 (match_operand:M 2 ...)))] 27095 "..." 27096 "...") 27097 27098 Similarly, a pattern for a "NAND" instruction should be written 27099 27100 (define_insn "" 27101 [(set (match_operand:M 0 ...) 27102 (ior:M (not:M (match_operand:M 1 ...)) 27103 (not:M (match_operand:M 2 ...))))] 27104 "..." 27105 "...") 27106 27107 In both cases, it is not necessary to include patterns for the many 27108 logically equivalent RTL expressions. 27109 27110 * The only possible RTL expressions involving both bitwise 27111 exclusive-or and bitwise negation are '(xor:M X Y)' and '(not:M 27112 (xor:M X Y))'. 27113 27114 * The sum of three items, one of which is a constant, will only 27115 appear in the form 27116 27117 (plus:M (plus:M X Y) CONSTANT) 27118 27119 * Equality comparisons of a group of bits (usually a single bit) with 27120 zero will be written using 'zero_extract' rather than the 27121 equivalent 'and' or 'sign_extract' operations. 27122 27123 * '(sign_extend:M1 (mult:M2 (sign_extend:M2 X) (sign_extend:M2 Y)))' 27124 is converted to '(mult:M1 (sign_extend:M1 X) (sign_extend:M1 Y))', 27125 and likewise for 'zero_extend'. 27126 27127 * '(sign_extend:M1 (mult:M2 (ashiftrt:M2 X S) (sign_extend:M2 Y)))' 27128 is converted to '(mult:M1 (sign_extend:M1 (ashiftrt:M2 X S)) 27129 (sign_extend:M1 Y))', and likewise for patterns using 'zero_extend' 27130 and 'lshiftrt'. If the second operand of 'mult' is also a shift, 27131 then that is extended also. This transformation is only applied 27132 when it can be proven that the original operation had sufficient 27133 precision to prevent overflow. 27134 27135 Further canonicalization rules are defined in the function 27136'commutative_operand_precedence' in 'gcc/rtlanal.c'. 27137 27138 27139File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc 27140 2714117.15 Defining RTL Sequences for Code Generation 27142================================================ 27143 27144On some target machines, some standard pattern names for RTL generation 27145cannot be handled with single insn, but a sequence of RTL insns can 27146represent them. For these target machines, you can write a 27147'define_expand' to specify how to generate the sequence of RTL. 27148 27149 A 'define_expand' is an RTL expression that looks almost like a 27150'define_insn'; but, unlike the latter, a 'define_expand' is used only 27151for RTL generation and it can produce more than one RTL insn. 27152 27153 A 'define_expand' RTX has four operands: 27154 27155 * The name. Each 'define_expand' must have a name, since the only 27156 use for it is to refer to it by name. 27157 27158 * The RTL template. This is a vector of RTL expressions representing 27159 a sequence of separate instructions. Unlike 'define_insn', there 27160 is no implicit surrounding 'PARALLEL'. 27161 27162 * The condition, a string containing a C expression. This expression 27163 is used to express how the availability of this pattern depends on 27164 subclasses of target machine, selected by command-line options when 27165 GCC is run. This is just like the condition of a 'define_insn' 27166 that has a standard name. Therefore, the condition (if present) 27167 may not depend on the data in the insn being matched, but only the 27168 target-machine-type flags. The compiler needs to test these 27169 conditions during initialization in order to learn exactly which 27170 named instructions are available in a particular run. 27171 27172 * The preparation statements, a string containing zero or more C 27173 statements which are to be executed before RTL code is generated 27174 from the RTL template. 27175 27176 Usually these statements prepare temporary registers for use as 27177 internal operands in the RTL template, but they can also generate 27178 RTL insns directly by calling routines such as 'emit_insn', etc. 27179 Any such insns precede the ones that come from the RTL template. 27180 27181 * Optionally, a vector containing the values of attributes. *Note 27182 Insn Attributes::. 27183 27184 Every RTL insn emitted by a 'define_expand' must match some 27185'define_insn' in the machine description. Otherwise, the compiler will 27186crash when trying to generate code for the insn or trying to optimize 27187it. 27188 27189 The RTL template, in addition to controlling generation of RTL insns, 27190also describes the operands that need to be specified when this pattern 27191is used. In particular, it gives a predicate for each operand. 27192 27193 A true operand, which needs to be specified in order to generate RTL 27194from the pattern, should be described with a 'match_operand' in its 27195first occurrence in the RTL template. This enters information on the 27196operand's predicate into the tables that record such things. GCC uses 27197the information to preload the operand into a register if that is 27198required for valid RTL code. If the operand is referred to more than 27199once, subsequent references should use 'match_dup'. 27200 27201 The RTL template may also refer to internal "operands" which are 27202temporary registers or labels used only within the sequence made by the 27203'define_expand'. Internal operands are substituted into the RTL 27204template with 'match_dup', never with 'match_operand'. The values of 27205the internal operands are not passed in as arguments by the compiler 27206when it requests use of this pattern. Instead, they are computed within 27207the pattern, in the preparation statements. These statements compute 27208the values and store them into the appropriate elements of 'operands' so 27209that 'match_dup' can find them. 27210 27211 There are two special macros defined for use in the preparation 27212statements: 'DONE' and 'FAIL'. Use them with a following semicolon, as 27213a statement. 27214 27215'DONE' 27216 Use the 'DONE' macro to end RTL generation for the pattern. The 27217 only RTL insns resulting from the pattern on this occasion will be 27218 those already emitted by explicit calls to 'emit_insn' within the 27219 preparation statements; the RTL template will not be generated. 27220 27221'FAIL' 27222 Make the pattern fail on this occasion. When a pattern fails, it 27223 means that the pattern was not truly available. The calling 27224 routines in the compiler will try other strategies for code 27225 generation using other patterns. 27226 27227 Failure is currently supported only for binary (addition, 27228 multiplication, shifting, etc.) and bit-field ('extv', 'extzv', 27229 and 'insv') operations. 27230 27231 If the preparation falls through (invokes neither 'DONE' nor 'FAIL'), 27232then the 'define_expand' acts like a 'define_insn' in that the RTL 27233template is used to generate the insn. 27234 27235 The RTL template is not used for matching, only for generating the 27236initial insn list. If the preparation statement always invokes 'DONE' 27237or 'FAIL', the RTL template may be reduced to a simple list of operands, 27238such as this example: 27239 27240 (define_expand "addsi3" 27241 [(match_operand:SI 0 "register_operand" "") 27242 (match_operand:SI 1 "register_operand" "") 27243 (match_operand:SI 2 "register_operand" "")] 27244 "" 27245 " 27246 { 27247 handle_add (operands[0], operands[1], operands[2]); 27248 DONE; 27249 }") 27250 27251 Here is an example, the definition of left-shift for the SPUR chip: 27252 27253 (define_expand "ashlsi3" 27254 [(set (match_operand:SI 0 "register_operand" "") 27255 (ashift:SI 27256 (match_operand:SI 1 "register_operand" "") 27257 (match_operand:SI 2 "nonmemory_operand" "")))] 27258 "" 27259 " 27260 27261 { 27262 if (GET_CODE (operands[2]) != CONST_INT 27263 || (unsigned) INTVAL (operands[2]) > 3) 27264 FAIL; 27265 }") 27266 27267This example uses 'define_expand' so that it can generate an RTL insn 27268for shifting when the shift-count is in the supported range of 0 to 3 27269but fail in other cases where machine insns aren't available. When it 27270fails, the compiler tries another strategy using different patterns 27271(such as, a library call). 27272 27273 If the compiler were able to handle nontrivial condition-strings in 27274patterns with names, then it would be possible to use a 'define_insn' in 27275that case. Here is another case (zero-extension on the 68000) which 27276makes more use of the power of 'define_expand': 27277 27278 (define_expand "zero_extendhisi2" 27279 [(set (match_operand:SI 0 "general_operand" "") 27280 (const_int 0)) 27281 (set (strict_low_part 27282 (subreg:HI 27283 (match_dup 0) 27284 0)) 27285 (match_operand:HI 1 "general_operand" ""))] 27286 "" 27287 "operands[1] = make_safe_from (operands[1], operands[0]);") 27288 27289Here two RTL insns are generated, one to clear the entire output operand 27290and the other to copy the input operand into its low half. This 27291sequence is incorrect if the input operand refers to [the old value of] 27292the output operand, so the preparation statement makes sure this isn't 27293so. The function 'make_safe_from' copies the 'operands[1]' into a 27294temporary register if it refers to 'operands[0]'. It does this by 27295emitting another RTL insn. 27296 27297 Finally, a third example shows the use of an internal operand. 27298Zero-extension on the SPUR chip is done by 'and'-ing the result against 27299a halfword mask. But this mask cannot be represented by a 'const_int' 27300because the constant value is too large to be legitimate on this 27301machine. So it must be copied into a register with 'force_reg' and then 27302the register used in the 'and'. 27303 27304 (define_expand "zero_extendhisi2" 27305 [(set (match_operand:SI 0 "register_operand" "") 27306 (and:SI (subreg:SI 27307 (match_operand:HI 1 "register_operand" "") 27308 0) 27309 (match_dup 2)))] 27310 "" 27311 "operands[2] 27312 = force_reg (SImode, GEN_INT (65535)); ") 27313 27314 _Note:_ If the 'define_expand' is used to serve a standard binary or 27315unary arithmetic operation or a bit-field operation, then the last insn 27316it generates must not be a 'code_label', 'barrier' or 'note'. It must 27317be an 'insn', 'jump_insn' or 'call_insn'. If you don't need a real insn 27318at the end, emit an insn to copy the result of the operation into 27319itself. Such an insn will generate no code, but it can avoid problems 27320in the compiler. 27321 27322 27323File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc 27324 2732517.16 Defining How to Split Instructions 27326======================================== 27327 27328There are two cases where you should specify how to split a pattern into 27329multiple insns. On machines that have instructions requiring delay 27330slots (*note Delay Slots::) or that have instructions whose output is 27331not available for multiple cycles (*note Processor pipeline 27332description::), the compiler phases that optimize these cases need to be 27333able to move insns into one-instruction delay slots. However, some 27334insns may generate more than one machine instruction. These insns 27335cannot be placed into a delay slot. 27336 27337 Often you can rewrite the single insn as a list of individual insns, 27338each corresponding to one machine instruction. The disadvantage of 27339doing so is that it will cause the compilation to be slower and require 27340more space. If the resulting insns are too complex, it may also 27341suppress some optimizations. The compiler splits the insn if there is a 27342reason to believe that it might improve instruction or delay slot 27343scheduling. 27344 27345 The insn combiner phase also splits putative insns. If three insns are 27346merged into one insn with a complex expression that cannot be matched by 27347some 'define_insn' pattern, the combiner phase attempts to split the 27348complex pattern into two insns that are recognized. Usually it can 27349break the complex pattern into two patterns by splitting out some 27350subexpression. However, in some other cases, such as performing an 27351addition of a large constant in two insns on a RISC machine, the way to 27352split the addition into two insns is machine-dependent. 27353 27354 The 'define_split' definition tells the compiler how to split a complex 27355insn into several simpler insns. It looks like this: 27356 27357 (define_split 27358 [INSN-PATTERN] 27359 "CONDITION" 27360 [NEW-INSN-PATTERN-1 27361 NEW-INSN-PATTERN-2 27362 ...] 27363 "PREPARATION-STATEMENTS") 27364 27365 INSN-PATTERN is a pattern that needs to be split and CONDITION is the 27366final condition to be tested, as in a 'define_insn'. When an insn 27367matching INSN-PATTERN and satisfying CONDITION is found, it is replaced 27368in the insn list with the insns given by NEW-INSN-PATTERN-1, 27369NEW-INSN-PATTERN-2, etc. 27370 27371 The PREPARATION-STATEMENTS are similar to those statements that are 27372specified for 'define_expand' (*note Expander Definitions::) and are 27373executed before the new RTL is generated to prepare for the generated 27374code or emit some insns whose pattern is not fixed. Unlike those in 27375'define_expand', however, these statements must not generate any new 27376pseudo-registers. Once reload has completed, they also must not 27377allocate any space in the stack frame. 27378 27379 Patterns are matched against INSN-PATTERN in two different 27380circumstances. If an insn needs to be split for delay slot scheduling 27381or insn scheduling, the insn is already known to be valid, which means 27382that it must have been matched by some 'define_insn' and, if 27383'reload_completed' is nonzero, is known to satisfy the constraints of 27384that 'define_insn'. In that case, the new insn patterns must also be 27385insns that are matched by some 'define_insn' and, if 'reload_completed' 27386is nonzero, must also satisfy the constraints of those definitions. 27387 27388 As an example of this usage of 'define_split', consider the following 27389example from 'a29k.md', which splits a 'sign_extend' from 'HImode' to 27390'SImode' into a pair of shift insns: 27391 27392 (define_split 27393 [(set (match_operand:SI 0 "gen_reg_operand" "") 27394 (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] 27395 "" 27396 [(set (match_dup 0) 27397 (ashift:SI (match_dup 1) 27398 (const_int 16))) 27399 (set (match_dup 0) 27400 (ashiftrt:SI (match_dup 0) 27401 (const_int 16)))] 27402 " 27403 { operands[1] = gen_lowpart (SImode, operands[1]); }") 27404 27405 When the combiner phase tries to split an insn pattern, it is always 27406the case that the pattern is _not_ matched by any 'define_insn'. The 27407combiner pass first tries to split a single 'set' expression and then 27408the same 'set' expression inside a 'parallel', but followed by a 27409'clobber' of a pseudo-reg to use as a scratch register. In these cases, 27410the combiner expects exactly two new insn patterns to be generated. It 27411will verify that these patterns match some 'define_insn' definitions, so 27412you need not do this test in the 'define_split' (of course, there is no 27413point in writing a 'define_split' that will never produce insns that 27414match). 27415 27416 Here is an example of this use of 'define_split', taken from 27417'rs6000.md': 27418 27419 (define_split 27420 [(set (match_operand:SI 0 "gen_reg_operand" "") 27421 (plus:SI (match_operand:SI 1 "gen_reg_operand" "") 27422 (match_operand:SI 2 "non_add_cint_operand" "")))] 27423 "" 27424 [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) 27425 (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] 27426 " 27427 { 27428 int low = INTVAL (operands[2]) & 0xffff; 27429 int high = (unsigned) INTVAL (operands[2]) >> 16; 27430 27431 if (low & 0x8000) 27432 high++, low |= 0xffff0000; 27433 27434 operands[3] = GEN_INT (high << 16); 27435 operands[4] = GEN_INT (low); 27436 }") 27437 27438 Here the predicate 'non_add_cint_operand' matches any 'const_int' that 27439is _not_ a valid operand of a single add insn. The add with the smaller 27440displacement is written so that it can be substituted into the address 27441of a subsequent operation. 27442 27443 An example that uses a scratch register, from the same file, generates 27444an equality comparison of a register and a large constant: 27445 27446 (define_split 27447 [(set (match_operand:CC 0 "cc_reg_operand" "") 27448 (compare:CC (match_operand:SI 1 "gen_reg_operand" "") 27449 (match_operand:SI 2 "non_short_cint_operand" ""))) 27450 (clobber (match_operand:SI 3 "gen_reg_operand" ""))] 27451 "find_single_use (operands[0], insn, 0) 27452 && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ 27453 || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" 27454 [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) 27455 (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] 27456 " 27457 { 27458 /* Get the constant we are comparing against, C, and see what it 27459 looks like sign-extended to 16 bits. Then see what constant 27460 could be XOR'ed with C to get the sign-extended value. */ 27461 27462 int c = INTVAL (operands[2]); 27463 int sextc = (c << 16) >> 16; 27464 int xorv = c ^ sextc; 27465 27466 operands[4] = GEN_INT (xorv); 27467 operands[5] = GEN_INT (sextc); 27468 }") 27469 27470 To avoid confusion, don't write a single 'define_split' that accepts 27471some insns that match some 'define_insn' as well as some insns that 27472don't. Instead, write two separate 'define_split' definitions, one for 27473the insns that are valid and one for the insns that are not valid. 27474 27475 The splitter is allowed to split jump instructions into sequence of 27476jumps or create new jumps in while splitting non-jump instructions. As 27477the control flow graph and branch prediction information needs to be 27478updated, several restriction apply. 27479 27480 Splitting of jump instruction into sequence that over by another jump 27481instruction is always valid, as compiler expect identical behavior of 27482new jump. When new sequence contains multiple jump instructions or new 27483labels, more assistance is needed. Splitter is required to create only 27484unconditional jumps, or simple conditional jump instructions. 27485Additionally it must attach a 'REG_BR_PROB' note to each conditional 27486jump. A global variable 'split_branch_probability' holds the 27487probability of the original branch in case it was a simple conditional 27488jump, -1 otherwise. To simplify recomputing of edge frequencies, the 27489new sequence is required to have only forward jumps to the newly created 27490labels. 27491 27492 For the common case where the pattern of a define_split exactly matches 27493the pattern of a define_insn, use 'define_insn_and_split'. It looks 27494like this: 27495 27496 (define_insn_and_split 27497 [INSN-PATTERN] 27498 "CONDITION" 27499 "OUTPUT-TEMPLATE" 27500 "SPLIT-CONDITION" 27501 [NEW-INSN-PATTERN-1 27502 NEW-INSN-PATTERN-2 27503 ...] 27504 "PREPARATION-STATEMENTS" 27505 [INSN-ATTRIBUTES]) 27506 27507 27508 INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used 27509as in 'define_insn'. The NEW-INSN-PATTERN vector and the 27510PREPARATION-STATEMENTS are used as in a 'define_split'. The 27511SPLIT-CONDITION is also used as in 'define_split', with the additional 27512behavior that if the condition starts with '&&', the condition used for 27513the split will be the constructed as a logical "and" of the split 27514condition with the insn condition. For example, from i386.md: 27515 27516 (define_insn_and_split "zero_extendhisi2_and" 27517 [(set (match_operand:SI 0 "register_operand" "=r") 27518 (zero_extend:SI (match_operand:HI 1 "register_operand" "0"))) 27519 (clobber (reg:CC 17))] 27520 "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size" 27521 "#" 27522 "&& reload_completed" 27523 [(parallel [(set (match_dup 0) 27524 (and:SI (match_dup 0) (const_int 65535))) 27525 (clobber (reg:CC 17))])] 27526 "" 27527 [(set_attr "type" "alu1")]) 27528 27529 27530 In this case, the actual split condition will be 27531'TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'. 27532 27533 The 'define_insn_and_split' construction provides exactly the same 27534functionality as two separate 'define_insn' and 'define_split' patterns. 27535It exists for compactness, and as a maintenance tool to prevent having 27536to ensure the two patterns' templates match. 27537 27538 27539File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc 27540 2754117.17 Including Patterns in Machine Descriptions. 27542================================================= 27543 27544The 'include' pattern tells the compiler tools where to look for 27545patterns that are in files other than in the file '.md'. This is used 27546only at build time and there is no preprocessing allowed. 27547 27548 It looks like: 27549 27550 27551 (include 27552 PATHNAME) 27553 27554 For example: 27555 27556 27557 (include "filestuff") 27558 27559 27560 Where PATHNAME is a string that specifies the location of the file, 27561specifies the include file to be in 'gcc/config/target/filestuff'. The 27562directory 'gcc/config/target' is regarded as the default directory. 27563 27564 Machine descriptions may be split up into smaller more manageable 27565subsections and placed into subdirectories. 27566 27567 By specifying: 27568 27569 27570 (include "BOGUS/filestuff") 27571 27572 27573 the include file is specified to be in 27574'gcc/config/TARGET/BOGUS/filestuff'. 27575 27576 Specifying an absolute path for the include file such as; 27577 27578 (include "/u2/BOGUS/filestuff") 27579 27580 is permitted but is not encouraged. 27581 2758217.17.1 RTL Generation Tool Options for Directory Search 27583-------------------------------------------------------- 27584 27585The '-IDIR' option specifies directories to search for machine 27586descriptions. For example: 27587 27588 27589 genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md 27590 27591 27592 Add the directory DIR to the head of the list of directories to be 27593searched for header files. This can be used to override a system 27594machine definition file, substituting your own version, since these 27595directories are searched before the default machine description file 27596directories. If you use more than one '-I' option, the directories are 27597scanned in left-to-right order; the standard default directory come 27598after. 27599 27600 27601File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc 27602 2760317.18 Machine-Specific Peephole Optimizers 27604========================================== 27605 27606In addition to instruction patterns the 'md' file may contain 27607definitions of machine-specific peephole optimizations. 27608 27609 The combiner does not notice certain peephole optimizations when the 27610data flow in the program does not suggest that it should try them. For 27611example, sometimes two consecutive insns related in purpose can be 27612combined even though the second one does not appear to use a register 27613computed in the first one. A machine-specific peephole optimizer can 27614detect such opportunities. 27615 27616 There are two forms of peephole definitions that may be used. The 27617original 'define_peephole' is run at assembly output time to match insns 27618and substitute assembly text. Use of 'define_peephole' is deprecated. 27619 27620 A newer 'define_peephole2' matches insns and substitutes new insns. 27621The 'peephole2' pass is run after register allocation but before 27622scheduling, which may result in much better code for targets that do 27623scheduling. 27624 27625* Menu: 27626 27627* define_peephole:: RTL to Text Peephole Optimizers 27628* define_peephole2:: RTL to RTL Peephole Optimizers 27629 27630 27631File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions 27632 2763317.18.1 RTL to Text Peephole Optimizers 27634--------------------------------------- 27635 27636A definition looks like this: 27637 27638 (define_peephole 27639 [INSN-PATTERN-1 27640 INSN-PATTERN-2 27641 ...] 27642 "CONDITION" 27643 "TEMPLATE" 27644 "OPTIONAL-INSN-ATTRIBUTES") 27645 27646The last string operand may be omitted if you are not using any 27647machine-specific information in this machine description. If present, 27648it must obey the same rules as in a 'define_insn'. 27649 27650 In this skeleton, INSN-PATTERN-1 and so on are patterns to match 27651consecutive insns. The optimization applies to a sequence of insns when 27652INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next, 27653and so on. 27654 27655 Each of the insns matched by a peephole must also match a 27656'define_insn'. Peepholes are checked only at the last stage just before 27657code generation, and only optionally. Therefore, any insn which would 27658match a peephole but no 'define_insn' will cause a crash in code 27659generation in an unoptimized compilation, or at various optimization 27660stages. 27661 27662 The operands of the insns are matched with 'match_operands', 27663'match_operator', and 'match_dup', as usual. What is not usual is that 27664the operand numbers apply to all the insn patterns in the definition. 27665So, you can check for identical operands in two insns by using 27666'match_operand' in one insn and 'match_dup' in the other. 27667 27668 The operand constraints used in 'match_operand' patterns do not have 27669any direct effect on the applicability of the peephole, but they will be 27670validated afterward, so make sure your constraints are general enough to 27671apply whenever the peephole matches. If the peephole matches but the 27672constraints are not satisfied, the compiler will crash. 27673 27674 It is safe to omit constraints in all the operands of the peephole; or 27675you can write constraints which serve as a double-check on the criteria 27676previously tested. 27677 27678 Once a sequence of insns matches the patterns, the CONDITION is 27679checked. This is a C expression which makes the final decision whether 27680to perform the optimization (we do so if the expression is nonzero). If 27681CONDITION is omitted (in other words, the string is empty) then the 27682optimization is applied to every sequence of insns that matches the 27683patterns. 27684 27685 The defined peephole optimizations are applied after register 27686allocation is complete. Therefore, the peephole definition can check 27687which operands have ended up in which kinds of registers, just by 27688looking at the operands. 27689 27690 The way to refer to the operands in CONDITION is to write 'operands[I]' 27691for operand number I (as matched by '(match_operand I ...)'). Use the 27692variable 'insn' to refer to the last of the insns being matched; use 27693'prev_active_insn' to find the preceding insns. 27694 27695 When optimizing computations with intermediate results, you can use 27696CONDITION to match only when the intermediate results are not used 27697elsewhere. Use the C expression 'dead_or_set_p (INSN, OP)', where INSN 27698is the insn in which you expect the value to be used for the last time 27699(from the value of 'insn', together with use of 'prev_nonnote_insn'), 27700and OP is the intermediate value (from 'operands[I]'). 27701 27702 Applying the optimization means replacing the sequence of insns with 27703one new insn. The TEMPLATE controls ultimate output of assembler code 27704for this combined insn. It works exactly like the template of a 27705'define_insn'. Operand numbers in this template are the same ones used 27706in matching the original sequence of insns. 27707 27708 The result of a defined peephole optimizer does not need to match any 27709of the insn patterns in the machine description; it does not even have 27710an opportunity to match them. The peephole optimizer definition itself 27711serves as the insn pattern to control how the insn is output. 27712 27713 Defined peephole optimizers are run as assembler code is being output, 27714so the insns they produce are never combined or rearranged in any way. 27715 27716 Here is an example, taken from the 68000 machine description: 27717 27718 (define_peephole 27719 [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) 27720 (set (match_operand:DF 0 "register_operand" "=f") 27721 (match_operand:DF 1 "register_operand" "ad"))] 27722 "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" 27723 { 27724 rtx xoperands[2]; 27725 xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1); 27726 #ifdef MOTOROLA 27727 output_asm_insn ("move.l %1,(sp)", xoperands); 27728 output_asm_insn ("move.l %1,-(sp)", operands); 27729 return "fmove.d (sp)+,%0"; 27730 #else 27731 output_asm_insn ("movel %1,sp@", xoperands); 27732 output_asm_insn ("movel %1,sp@-", operands); 27733 return "fmoved sp@+,%0"; 27734 #endif 27735 }) 27736 27737 The effect of this optimization is to change 27738 27739 jbsr _foobar 27740 addql #4,sp 27741 movel d1,sp@- 27742 movel d0,sp@- 27743 fmoved sp@+,fp0 27744 27745into 27746 27747 jbsr _foobar 27748 movel d1,sp@ 27749 movel d0,sp@- 27750 fmoved sp@+,fp0 27751 27752 INSN-PATTERN-1 and so on look _almost_ like the second operand of 27753'define_insn'. There is one important difference: the second operand of 27754'define_insn' consists of one or more RTX's enclosed in square brackets. 27755Usually, there is only one: then the same action can be written as an 27756element of a 'define_peephole'. But when there are multiple actions in 27757a 'define_insn', they are implicitly enclosed in a 'parallel'. Then you 27758must explicitly write the 'parallel', and the square brackets within it, 27759in the 'define_peephole'. Thus, if an insn pattern looks like this, 27760 27761 (define_insn "divmodsi4" 27762 [(set (match_operand:SI 0 "general_operand" "=d") 27763 (div:SI (match_operand:SI 1 "general_operand" "0") 27764 (match_operand:SI 2 "general_operand" "dmsK"))) 27765 (set (match_operand:SI 3 "general_operand" "=d") 27766 (mod:SI (match_dup 1) (match_dup 2)))] 27767 "TARGET_68020" 27768 "divsl%.l %2,%3:%0") 27769 27770then the way to mention this insn in a peephole is as follows: 27771 27772 (define_peephole 27773 [... 27774 (parallel 27775 [(set (match_operand:SI 0 "general_operand" "=d") 27776 (div:SI (match_operand:SI 1 "general_operand" "0") 27777 (match_operand:SI 2 "general_operand" "dmsK"))) 27778 (set (match_operand:SI 3 "general_operand" "=d") 27779 (mod:SI (match_dup 1) (match_dup 2)))]) 27780 ...] 27781 ...) 27782 27783 27784File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions 27785 2778617.18.2 RTL to RTL Peephole Optimizers 27787-------------------------------------- 27788 27789The 'define_peephole2' definition tells the compiler how to substitute 27790one sequence of instructions for another sequence, what additional 27791scratch registers may be needed and what their lifetimes must be. 27792 27793 (define_peephole2 27794 [INSN-PATTERN-1 27795 INSN-PATTERN-2 27796 ...] 27797 "CONDITION" 27798 [NEW-INSN-PATTERN-1 27799 NEW-INSN-PATTERN-2 27800 ...] 27801 "PREPARATION-STATEMENTS") 27802 27803 The definition is almost identical to 'define_split' (*note Insn 27804Splitting::) except that the pattern to match is not a single 27805instruction, but a sequence of instructions. 27806 27807 It is possible to request additional scratch registers for use in the 27808output template. If appropriate registers are not free, the pattern 27809will simply not match. 27810 27811 Scratch registers are requested with a 'match_scratch' pattern at the 27812top level of the input pattern. The allocated register (initially) will 27813be dead at the point requested within the original sequence. If the 27814scratch is used at more than a single point, a 'match_dup' pattern at 27815the top level of the input pattern marks the last position in the input 27816sequence at which the register must be available. 27817 27818 Here is an example from the IA-32 machine description: 27819 27820 (define_peephole2 27821 [(match_scratch:SI 2 "r") 27822 (parallel [(set (match_operand:SI 0 "register_operand" "") 27823 (match_operator:SI 3 "arith_or_logical_operator" 27824 [(match_dup 0) 27825 (match_operand:SI 1 "memory_operand" "")])) 27826 (clobber (reg:CC 17))])] 27827 "! optimize_size && ! TARGET_READ_MODIFY" 27828 [(set (match_dup 2) (match_dup 1)) 27829 (parallel [(set (match_dup 0) 27830 (match_op_dup 3 [(match_dup 0) (match_dup 2)])) 27831 (clobber (reg:CC 17))])] 27832 "") 27833 27834This pattern tries to split a load from its use in the hopes that we'll 27835be able to schedule around the memory load latency. It allocates a 27836single 'SImode' register of class 'GENERAL_REGS' ('"r"') that needs to 27837be live only at the point just before the arithmetic. 27838 27839 A real example requiring extended scratch lifetimes is harder to come 27840by, so here's a silly made-up example: 27841 27842 (define_peephole2 27843 [(match_scratch:SI 4 "r") 27844 (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" "")) 27845 (set (match_operand:SI 2 "" "") (match_dup 1)) 27846 (match_dup 4) 27847 (set (match_operand:SI 3 "" "") (match_dup 1))] 27848 "/* determine 1 does not overlap 0 and 2 */" 27849 [(set (match_dup 4) (match_dup 1)) 27850 (set (match_dup 0) (match_dup 4)) 27851 (set (match_dup 2) (match_dup 4)) 27852 (set (match_dup 3) (match_dup 4))] 27853 "") 27854 27855If we had not added the '(match_dup 4)' in the middle of the input 27856sequence, it might have been the case that the register we chose at the 27857beginning of the sequence is killed by the first or second 'set'. 27858 27859 27860File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc 27861 2786217.19 Instruction Attributes 27863============================ 27864 27865In addition to describing the instruction supported by the target 27866machine, the 'md' file also defines a group of "attributes" and a set of 27867values for each. Every generated insn is assigned a value for each 27868attribute. One possible attribute would be the effect that the insn has 27869on the machine's condition code. This attribute can then be used by 27870'NOTICE_UPDATE_CC' to track the condition codes. 27871 27872* Menu: 27873 27874* Defining Attributes:: Specifying attributes and their values. 27875* Expressions:: Valid expressions for attribute values. 27876* Tagging Insns:: Assigning attribute values to insns. 27877* Attr Example:: An example of assigning attributes. 27878* Insn Lengths:: Computing the length of insns. 27879* Constant Attributes:: Defining attributes that are constant. 27880* Mnemonic Attribute:: Obtain the instruction mnemonic as attribute value. 27881* Delay Slots:: Defining delay slots required for a machine. 27882* Processor pipeline description:: Specifying information for insn scheduling. 27883 27884 27885File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes 27886 2788717.19.1 Defining Attributes and their Values 27888-------------------------------------------- 27889 27890The 'define_attr' expression is used to define each attribute required 27891by the target machine. It looks like: 27892 27893 (define_attr NAME LIST-OF-VALUES DEFAULT) 27894 27895 NAME is a string specifying the name of the attribute being defined. 27896Some attributes are used in a special way by the rest of the compiler. 27897The 'enabled' attribute can be used to conditionally enable or disable 27898insn alternatives (*note Disable Insn Alternatives::). The 'predicable' 27899attribute, together with a suitable 'define_cond_exec' (*note 27900Conditional Execution::), can be used to automatically generate 27901conditional variants of instruction patterns. The 'mnemonic' attribute 27902can be used to check for the instruction mnemonic (*note Mnemonic 27903Attribute::). The compiler internally uses the names 'ce_enabled' and 27904'nonce_enabled', so they should not be used elsewhere as alternative 27905names. 27906 27907 LIST-OF-VALUES is either a string that specifies a comma-separated list 27908of values that can be assigned to the attribute, or a null string to 27909indicate that the attribute takes numeric values. 27910 27911 DEFAULT is an attribute expression that gives the value of this 27912attribute for insns that match patterns whose definition does not 27913include an explicit value for this attribute. *Note Attr Example::, for 27914more information on the handling of defaults. *Note Constant 27915Attributes::, for information on attributes that do not depend on any 27916particular insn. 27917 27918 For each defined attribute, a number of definitions are written to the 27919'insn-attr.h' file. For cases where an explicit set of values is 27920specified for an attribute, the following are defined: 27921 27922 * A '#define' is written for the symbol 'HAVE_ATTR_NAME'. 27923 27924 * An enumerated class is defined for 'attr_NAME' with elements of the 27925 form 'UPPER-NAME_UPPER-VALUE' where the attribute name and value 27926 are first converted to uppercase. 27927 27928 * A function 'get_attr_NAME' is defined that is passed an insn and 27929 returns the attribute value for that insn. 27930 27931 For example, if the following is present in the 'md' file: 27932 27933 (define_attr "type" "branch,fp,load,store,arith" ...) 27934 27935the following lines will be written to the file 'insn-attr.h'. 27936 27937 #define HAVE_ATTR_type 1 27938 enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, 27939 TYPE_STORE, TYPE_ARITH}; 27940 extern enum attr_type get_attr_type (); 27941 27942 If the attribute takes numeric values, no 'enum' type will be defined 27943and the function to obtain the attribute's value will return 'int'. 27944 27945 There are attributes which are tied to a specific meaning. These 27946attributes are not free to use for other purposes: 27947 27948'length' 27949 The 'length' attribute is used to calculate the length of emitted 27950 code chunks. This is especially important when verifying branch 27951 distances. *Note Insn Lengths::. 27952 27953'enabled' 27954 The 'enabled' attribute can be defined to prevent certain 27955 alternatives of an insn definition from being used during code 27956 generation. *Note Disable Insn Alternatives::. 27957 27958'mnemonic' 27959 The 'mnemonic' attribute can be defined to implement instruction 27960 specific checks in e.g. the pipeline description. *Note Mnemonic 27961 Attribute::. 27962 27963 For each of these special attributes, the corresponding 27964'HAVE_ATTR_NAME' '#define' is also written when the attribute is not 27965defined; in that case, it is defined as '0'. 27966 27967 Another way of defining an attribute is to use: 27968 27969 (define_enum_attr "ATTR" "ENUM" DEFAULT) 27970 27971 This works in just the same way as 'define_attr', except that the list 27972of values is taken from a separate enumeration called ENUM (*note 27973define_enum::). This form allows you to use the same list of values for 27974several attributes without having to repeat the list each time. For 27975example: 27976 27977 (define_enum "processor" [ 27978 model_a 27979 model_b 27980 ... 27981 ]) 27982 (define_enum_attr "arch" "processor" 27983 (const (symbol_ref "target_arch"))) 27984 (define_enum_attr "tune" "processor" 27985 (const (symbol_ref "target_tune"))) 27986 27987 defines the same attributes as: 27988 27989 (define_attr "arch" "model_a,model_b,..." 27990 (const (symbol_ref "target_arch"))) 27991 (define_attr "tune" "model_a,model_b,..." 27992 (const (symbol_ref "target_tune"))) 27993 27994 but without duplicating the processor list. The second example defines 27995two separate C enums ('attr_arch' and 'attr_tune') whereas the first 27996defines a single C enum ('processor'). 27997 27998 27999File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes 28000 2800117.19.2 Attribute Expressions 28002----------------------------- 28003 28004RTL expressions used to define attributes use the codes described above 28005plus a few specific to attribute definitions, to be discussed below. 28006Attribute value expressions must have one of the following forms: 28007 28008'(const_int I)' 28009 The integer I specifies the value of a numeric attribute. I must 28010 be non-negative. 28011 28012 The value of a numeric attribute can be specified either with a 28013 'const_int', or as an integer represented as a string in 28014 'const_string', 'eq_attr' (see below), 'attr', 'symbol_ref', simple 28015 arithmetic expressions, and 'set_attr' overrides on specific 28016 instructions (*note Tagging Insns::). 28017 28018'(const_string VALUE)' 28019 The string VALUE specifies a constant attribute value. If VALUE is 28020 specified as '"*"', it means that the default value of the 28021 attribute is to be used for the insn containing this expression. 28022 '"*"' obviously cannot be used in the DEFAULT expression of a 28023 'define_attr'. 28024 28025 If the attribute whose value is being specified is numeric, VALUE 28026 must be a string containing a non-negative integer (normally 28027 'const_int' would be used in this case). Otherwise, it must 28028 contain one of the valid values for the attribute. 28029 28030'(if_then_else TEST TRUE-VALUE FALSE-VALUE)' 28031 TEST specifies an attribute test, whose format is defined below. 28032 The value of this expression is TRUE-VALUE if TEST is true, 28033 otherwise it is FALSE-VALUE. 28034 28035'(cond [TEST1 VALUE1 ...] DEFAULT)' 28036 The first operand of this expression is a vector containing an even 28037 number of expressions and consisting of pairs of TEST and VALUE 28038 expressions. The value of the 'cond' expression is that of the 28039 VALUE corresponding to the first true TEST expression. If none of 28040 the TEST expressions are true, the value of the 'cond' expression 28041 is that of the DEFAULT expression. 28042 28043 TEST expressions can have one of the following forms: 28044 28045'(const_int I)' 28046 This test is true if I is nonzero and false otherwise. 28047 28048'(not TEST)' 28049'(ior TEST1 TEST2)' 28050'(and TEST1 TEST2)' 28051 These tests are true if the indicated logical function is true. 28052 28053'(match_operand:M N PRED CONSTRAINTS)' 28054 This test is true if operand N of the insn whose attribute value is 28055 being determined has mode M (this part of the test is ignored if M 28056 is 'VOIDmode') and the function specified by the string PRED 28057 returns a nonzero value when passed operand N and mode M (this part 28058 of the test is ignored if PRED is the null string). 28059 28060 The CONSTRAINTS operand is ignored and should be the null string. 28061 28062'(match_test C-EXPR)' 28063 The test is true if C expression C-EXPR is true. In non-constant 28064 attributes, C-EXPR has access to the following variables: 28065 28066 INSN 28067 The rtl instruction under test. 28068 WHICH_ALTERNATIVE 28069 The 'define_insn' alternative that INSN matches. *Note Output 28070 Statement::. 28071 OPERANDS 28072 An array of INSN's rtl operands. 28073 28074 C-EXPR behaves like the condition in a C 'if' statement, so there 28075 is no need to explicitly convert the expression into a boolean 0 or 28076 1 value. For example, the following two tests are equivalent: 28077 28078 (match_test "x & 2") 28079 (match_test "(x & 2) != 0") 28080 28081'(le ARITH1 ARITH2)' 28082'(leu ARITH1 ARITH2)' 28083'(lt ARITH1 ARITH2)' 28084'(ltu ARITH1 ARITH2)' 28085'(gt ARITH1 ARITH2)' 28086'(gtu ARITH1 ARITH2)' 28087'(ge ARITH1 ARITH2)' 28088'(geu ARITH1 ARITH2)' 28089'(ne ARITH1 ARITH2)' 28090'(eq ARITH1 ARITH2)' 28091 These tests are true if the indicated comparison of the two 28092 arithmetic expressions is true. Arithmetic expressions are formed 28093 with 'plus', 'minus', 'mult', 'div', 'mod', 'abs', 'neg', 'and', 28094 'ior', 'xor', 'not', 'ashift', 'lshiftrt', and 'ashiftrt' 28095 expressions. 28096 28097 'const_int' and 'symbol_ref' are always valid terms (*note Insn 28098 Lengths::,for additional forms). 'symbol_ref' is a string denoting 28099 a C expression that yields an 'int' when evaluated by the 28100 'get_attr_...' routine. It should normally be a global variable. 28101 28102'(eq_attr NAME VALUE)' 28103 NAME is a string specifying the name of an attribute. 28104 28105 VALUE is a string that is either a valid value for attribute NAME, 28106 a comma-separated list of values, or '!' followed by a value or 28107 list. If VALUE does not begin with a '!', this test is true if the 28108 value of the NAME attribute of the current insn is in the list 28109 specified by VALUE. If VALUE begins with a '!', this test is true 28110 if the attribute's value is _not_ in the specified list. 28111 28112 For example, 28113 28114 (eq_attr "type" "load,store") 28115 28116 is equivalent to 28117 28118 (ior (eq_attr "type" "load") (eq_attr "type" "store")) 28119 28120 If NAME specifies an attribute of 'alternative', it refers to the 28121 value of the compiler variable 'which_alternative' (*note Output 28122 Statement::) and the values must be small integers. For example, 28123 28124 (eq_attr "alternative" "2,3") 28125 28126 is equivalent to 28127 28128 (ior (eq (symbol_ref "which_alternative") (const_int 2)) 28129 (eq (symbol_ref "which_alternative") (const_int 3))) 28130 28131 Note that, for most attributes, an 'eq_attr' test is simplified in 28132 cases where the value of the attribute being tested is known for 28133 all insns matching a particular pattern. This is by far the most 28134 common case. 28135 28136'(attr_flag NAME)' 28137 The value of an 'attr_flag' expression is true if the flag 28138 specified by NAME is true for the 'insn' currently being scheduled. 28139 28140 NAME is a string specifying one of a fixed set of flags to test. 28141 Test the flags 'forward' and 'backward' to determine the direction 28142 of a conditional branch. 28143 28144 This example describes a conditional branch delay slot which can be 28145 nullified for forward branches that are taken (annul-true) or for 28146 backward branches which are not taken (annul-false). 28147 28148 (define_delay (eq_attr "type" "cbranch") 28149 [(eq_attr "in_branch_delay" "true") 28150 (and (eq_attr "in_branch_delay" "true") 28151 (attr_flag "forward")) 28152 (and (eq_attr "in_branch_delay" "true") 28153 (attr_flag "backward"))]) 28154 28155 The 'forward' and 'backward' flags are false if the current 'insn' 28156 being scheduled is not a conditional branch. 28157 28158 'attr_flag' is only used during delay slot scheduling and has no 28159 meaning to other passes of the compiler. 28160 28161'(attr NAME)' 28162 The value of another attribute is returned. This is most useful 28163 for numeric attributes, as 'eq_attr' and 'attr_flag' produce more 28164 efficient code for non-numeric attributes. 28165 28166 28167File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes 28168 2816917.19.3 Assigning Attribute Values to Insns 28170------------------------------------------- 28171 28172The value assigned to an attribute of an insn is primarily determined by 28173which pattern is matched by that insn (or which 'define_peephole' 28174generated it). Every 'define_insn' and 'define_peephole' can have an 28175optional last argument to specify the values of attributes for matching 28176insns. The value of any attribute not specified in a particular insn is 28177set to the default value for that attribute, as specified in its 28178'define_attr'. Extensive use of default values for attributes permits 28179the specification of the values for only one or two attributes in the 28180definition of most insn patterns, as seen in the example in the next 28181section. 28182 28183 The optional last argument of 'define_insn' and 'define_peephole' is a 28184vector of expressions, each of which defines the value for a single 28185attribute. The most general way of assigning an attribute's value is to 28186use a 'set' expression whose first operand is an 'attr' expression 28187giving the name of the attribute being set. The second operand of the 28188'set' is an attribute expression (*note Expressions::) giving the value 28189of the attribute. 28190 28191 When the attribute value depends on the 'alternative' attribute (i.e., 28192which is the applicable alternative in the constraint of the insn), the 28193'set_attr_alternative' expression can be used. It allows the 28194specification of a vector of attribute expressions, one for each 28195alternative. 28196 28197 When the generality of arbitrary attribute expressions is not required, 28198the simpler 'set_attr' expression can be used, which allows specifying a 28199string giving either a single attribute value or a list of attribute 28200values, one for each alternative. 28201 28202 The form of each of the above specifications is shown below. In each 28203case, NAME is a string specifying the attribute to be set. 28204 28205'(set_attr NAME VALUE-STRING)' 28206 VALUE-STRING is either a string giving the desired attribute value, 28207 or a string containing a comma-separated list giving the values for 28208 succeeding alternatives. The number of elements must match the 28209 number of alternatives in the constraint of the insn pattern. 28210 28211 Note that it may be useful to specify '*' for some alternative, in 28212 which case the attribute will assume its default value for insns 28213 matching that alternative. 28214 28215'(set_attr_alternative NAME [VALUE1 VALUE2 ...])' 28216 Depending on the alternative of the insn, the value will be one of 28217 the specified values. This is a shorthand for using a 'cond' with 28218 tests on the 'alternative' attribute. 28219 28220'(set (attr NAME) VALUE)' 28221 The first operand of this 'set' must be the special RTL expression 28222 'attr', whose sole operand is a string giving the name of the 28223 attribute being set. VALUE is the value of the attribute. 28224 28225 The following shows three different ways of representing the same 28226attribute value specification: 28227 28228 (set_attr "type" "load,store,arith") 28229 28230 (set_attr_alternative "type" 28231 [(const_string "load") (const_string "store") 28232 (const_string "arith")]) 28233 28234 (set (attr "type") 28235 (cond [(eq_attr "alternative" "1") (const_string "load") 28236 (eq_attr "alternative" "2") (const_string "store")] 28237 (const_string "arith"))) 28238 28239 The 'define_asm_attributes' expression provides a mechanism to specify 28240the attributes assigned to insns produced from an 'asm' statement. It 28241has the form: 28242 28243 (define_asm_attributes [ATTR-SETS]) 28244 28245where ATTR-SETS is specified the same as for both the 'define_insn' and 28246the 'define_peephole' expressions. 28247 28248 These values will typically be the "worst case" attribute values. For 28249example, they might indicate that the condition code will be clobbered. 28250 28251 A specification for a 'length' attribute is handled specially. The way 28252to compute the length of an 'asm' insn is to multiply the length 28253specified in the expression 'define_asm_attributes' by the number of 28254machine instructions specified in the 'asm' statement, determined by 28255counting the number of semicolons and newlines in the string. 28256Therefore, the value of the 'length' attribute specified in a 28257'define_asm_attributes' should be the maximum possible length of a 28258single machine instruction. 28259 28260 28261File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes 28262 2826317.19.4 Example of Attribute Specifications 28264------------------------------------------- 28265 28266The judicious use of defaulting is important in the efficient use of 28267insn attributes. Typically, insns are divided into "types" and an 28268attribute, customarily called 'type', is used to represent this value. 28269This attribute is normally used only to define the default value for 28270other attributes. An example will clarify this usage. 28271 28272 Assume we have a RISC machine with a condition code and in which only 28273full-word operations are performed in registers. Let us assume that we 28274can divide all insns into loads, stores, (integer) arithmetic 28275operations, floating point operations, and branches. 28276 28277 Here we will concern ourselves with determining the effect of an insn 28278on the condition code and will limit ourselves to the following possible 28279effects: The condition code can be set unpredictably (clobbered), not be 28280changed, be set to agree with the results of the operation, or only 28281changed if the item previously set into the condition code has been 28282modified. 28283 28284 Here is part of a sample 'md' file for such a machine: 28285 28286 (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) 28287 28288 (define_attr "cc" "clobber,unchanged,set,change0" 28289 (cond [(eq_attr "type" "load") 28290 (const_string "change0") 28291 (eq_attr "type" "store,branch") 28292 (const_string "unchanged") 28293 (eq_attr "type" "arith") 28294 (if_then_else (match_operand:SI 0 "" "") 28295 (const_string "set") 28296 (const_string "clobber"))] 28297 (const_string "clobber"))) 28298 28299 (define_insn "" 28300 [(set (match_operand:SI 0 "general_operand" "=r,r,m") 28301 (match_operand:SI 1 "general_operand" "r,m,r"))] 28302 "" 28303 "@ 28304 move %0,%1 28305 load %0,%1 28306 store %0,%1" 28307 [(set_attr "type" "arith,load,store")]) 28308 28309 Note that we assume in the above example that arithmetic operations 28310performed on quantities smaller than a machine word clobber the 28311condition code since they will set the condition code to a value 28312corresponding to the full-word result. 28313 28314 28315File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes 28316 2831717.19.5 Computing the Length of an Insn 28318--------------------------------------- 28319 28320For many machines, multiple types of branch instructions are provided, 28321each for different length branch displacements. In most cases, the 28322assembler will choose the correct instruction to use. However, when the 28323assembler cannot do so, GCC can when a special attribute, the 'length' 28324attribute, is defined. This attribute must be defined to have numeric 28325values by specifying a null string in its 'define_attr'. 28326 28327 In the case of the 'length' attribute, two additional forms of 28328arithmetic terms are allowed in test expressions: 28329 28330'(match_dup N)' 28331 This refers to the address of operand N of the current insn, which 28332 must be a 'label_ref'. 28333 28334'(pc)' 28335 For non-branch instructions and backward branch instructions, this 28336 refers to the address of the current insn. But for forward branch 28337 instructions, this refers to the address of the next insn, because 28338 the length of the current insn is to be computed. 28339 28340 For normal insns, the length will be determined by value of the 28341'length' attribute. In the case of 'addr_vec' and 'addr_diff_vec' insn 28342patterns, the length is computed as the number of vectors multiplied by 28343the size of each vector. 28344 28345 Lengths are measured in addressable storage units (bytes). 28346 28347 Note that it is possible to call functions via the 'symbol_ref' 28348mechanism to compute the length of an insn. However, if you use this 28349mechanism you must provide dummy clauses to express the maximum length 28350without using the function call. You can an example of this in the 'pa' 28351machine description for the 'call_symref' pattern. 28352 28353 The following macros can be used to refine the length computation: 28354 28355'ADJUST_INSN_LENGTH (INSN, LENGTH)' 28356 If defined, modifies the length assigned to instruction INSN as a 28357 function of the context in which it is used. LENGTH is an lvalue 28358 that contains the initially computed length of the insn and should 28359 be updated with the correct length of the insn. 28360 28361 This macro will normally not be required. A case in which it is 28362 required is the ROMP. On this machine, the size of an 'addr_vec' 28363 insn must be increased by two to compensate for the fact that 28364 alignment may be required. 28365 28366 The routine that returns 'get_attr_length' (the value of the 'length' 28367attribute) can be used by the output routine to determine the form of 28368the branch instruction to be written, as the example below illustrates. 28369 28370 As an example of the specification of variable-length branches, 28371consider the IBM 360. If we adopt the convention that a register will 28372be set to the starting address of a function, we can jump to labels 28373within 4k of the start using a four-byte instruction. Otherwise, we 28374need a six-byte sequence to load the address from memory and then branch 28375to it. 28376 28377 On such a machine, a pattern for a branch instruction might be 28378specified as follows: 28379 28380 (define_insn "jump" 28381 [(set (pc) 28382 (label_ref (match_operand 0 "" "")))] 28383 "" 28384 { 28385 return (get_attr_length (insn) == 4 28386 ? "b %l0" : "l r15,=a(%l0); br r15"); 28387 } 28388 [(set (attr "length") 28389 (if_then_else (lt (match_dup 0) (const_int 4096)) 28390 (const_int 4) 28391 (const_int 6)))]) 28392 28393 28394File: gccint.info, Node: Constant Attributes, Next: Mnemonic Attribute, Prev: Insn Lengths, Up: Insn Attributes 28395 2839617.19.6 Constant Attributes 28397--------------------------- 28398 28399A special form of 'define_attr', where the expression for the default 28400value is a 'const' expression, indicates an attribute that is constant 28401for a given run of the compiler. Constant attributes may be used to 28402specify which variety of processor is used. For example, 28403 28404 (define_attr "cpu" "m88100,m88110,m88000" 28405 (const 28406 (cond [(symbol_ref "TARGET_88100") (const_string "m88100") 28407 (symbol_ref "TARGET_88110") (const_string "m88110")] 28408 (const_string "m88000")))) 28409 28410 (define_attr "memory" "fast,slow" 28411 (const 28412 (if_then_else (symbol_ref "TARGET_FAST_MEM") 28413 (const_string "fast") 28414 (const_string "slow")))) 28415 28416 The routine generated for constant attributes has no parameters as it 28417does not depend on any particular insn. RTL expressions used to define 28418the value of a constant attribute may use the 'symbol_ref' form, but may 28419not use either the 'match_operand' form or 'eq_attr' forms involving 28420insn attributes. 28421 28422 28423File: gccint.info, Node: Mnemonic Attribute, Next: Delay Slots, Prev: Constant Attributes, Up: Insn Attributes 28424 2842517.19.7 Mnemonic Attribute 28426-------------------------- 28427 28428The 'mnemonic' attribute is a string type attribute holding the 28429instruction mnemonic for an insn alternative. The attribute values will 28430automatically be generated by the machine description parser if there is 28431an attribute definition in the md file: 28432 28433 (define_attr "mnemonic" "unknown" (const_string "unknown")) 28434 28435 The default value can be freely chosen as long as it does not collide 28436with any of the instruction mnemonics. This value will be used whenever 28437the machine description parser is not able to determine the mnemonic 28438string. This might be the case for output templates containing more 28439than a single instruction as in '"mvcle\t%0,%1,0\;jo\t.-4"'. 28440 28441 The 'mnemonic' attribute set is not generated automatically if the 28442instruction string is generated via C code. 28443 28444 An existing 'mnemonic' attribute set in an insn definition will not be 28445overriden by the md file parser. That way it is possible to manually 28446set the instruction mnemonics for the cases where the md file parser 28447fails to determine it automatically. 28448 28449 The 'mnemonic' attribute is useful for dealing with instruction 28450specific properties in the pipeline description without defining 28451additional insn attributes. 28452 28453 (define_attr "ooo_expanded" "" 28454 (cond [(eq_attr "mnemonic" "dlr,dsgr,d,dsgf,stam,dsgfr,dlgr") 28455 (const_int 1)] 28456 (const_int 0))) 28457 28458 28459File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Mnemonic Attribute, Up: Insn Attributes 28460 2846117.19.8 Delay Slot Scheduling 28462----------------------------- 28463 28464The insn attribute mechanism can be used to specify the requirements for 28465delay slots, if any, on a target machine. An instruction is said to 28466require a "delay slot" if some instructions that are physically after 28467the instruction are executed as if they were located before it. Classic 28468examples are branch and call instructions, which often execute the 28469following instruction before the branch or call is performed. 28470 28471 On some machines, conditional branch instructions can optionally 28472"annul" instructions in the delay slot. This means that the instruction 28473will not be executed for certain branch outcomes. Both instructions 28474that annul if the branch is true and instructions that annul if the 28475branch is false are supported. 28476 28477 Delay slot scheduling differs from instruction scheduling in that 28478determining whether an instruction needs a delay slot is dependent only 28479on the type of instruction being generated, not on data flow between the 28480instructions. See the next section for a discussion of data-dependent 28481instruction scheduling. 28482 28483 The requirement of an insn needing one or more delay slots is indicated 28484via the 'define_delay' expression. It has the following form: 28485 28486 (define_delay TEST 28487 [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 28488 DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 28489 ...]) 28490 28491 TEST is an attribute test that indicates whether this 'define_delay' 28492applies to a particular insn. If so, the number of required delay slots 28493is determined by the length of the vector specified as the second 28494argument. An insn placed in delay slot N must satisfy attribute test 28495DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns 28496may be annulled if the branch is true. Similarly, ANNUL-FALSE-N 28497specifies which insns in the delay slot may be annulled if the branch is 28498false. If annulling is not supported for that delay slot, '(nil)' 28499should be coded. 28500 28501 For example, in the common case where branch and call insns require a 28502single delay slot, which may contain any insn other than a branch or 28503call, the following would be placed in the 'md' file: 28504 28505 (define_delay (eq_attr "type" "branch,call") 28506 [(eq_attr "type" "!branch,call") (nil) (nil)]) 28507 28508 Multiple 'define_delay' expressions may be specified. In this case, 28509each such expression specifies different delay slot requirements and 28510there must be no insn for which tests in two 'define_delay' expressions 28511are both true. 28512 28513 For example, if we have a machine that requires one delay slot for 28514branches but two for calls, no delay slot can contain a branch or call 28515insn, and any valid insn in the delay slot for the branch can be 28516annulled if the branch is true, we might represent this as follows: 28517 28518 (define_delay (eq_attr "type" "branch") 28519 [(eq_attr "type" "!branch,call") 28520 (eq_attr "type" "!branch,call") 28521 (nil)]) 28522 28523 (define_delay (eq_attr "type" "call") 28524 [(eq_attr "type" "!branch,call") (nil) (nil) 28525 (eq_attr "type" "!branch,call") (nil) (nil)]) 28526 28527 28528File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes 28529 2853017.19.9 Specifying processor pipeline description 28531------------------------------------------------- 28532 28533To achieve better performance, most modern processors (super-pipelined, 28534superscalar RISC, and VLIW processors) have many "functional units" on 28535which several instructions can be executed simultaneously. An 28536instruction starts execution if its issue conditions are satisfied. If 28537not, the instruction is stalled until its conditions are satisfied. 28538Such "interlock (pipeline) delay" causes interruption of the fetching of 28539successor instructions (or demands nop instructions, e.g. for some MIPS 28540processors). 28541 28542 There are two major kinds of interlock delays in modern processors. 28543The first one is a data dependence delay determining "instruction 28544latency time". The instruction execution is not started until all 28545source data have been evaluated by prior instructions (there are more 28546complex cases when the instruction execution starts even when the data 28547are not available but will be ready in given time after the instruction 28548execution start). Taking the data dependence delays into account is 28549simple. The data dependence (true, output, and anti-dependence) delay 28550between two instructions is given by a constant. In most cases this 28551approach is adequate. The second kind of interlock delays is a 28552reservation delay. The reservation delay means that two instructions 28553under execution will be in need of shared processors resources, i.e. 28554buses, internal registers, and/or functional units, which are reserved 28555for some time. Taking this kind of delay into account is complex 28556especially for modern RISC processors. 28557 28558 The task of exploiting more processor parallelism is solved by an 28559instruction scheduler. For a better solution to this problem, the 28560instruction scheduler has to have an adequate description of the 28561processor parallelism (or "pipeline description"). GCC machine 28562descriptions describe processor parallelism and functional unit 28563reservations for groups of instructions with the aid of "regular 28564expressions". 28565 28566 The GCC instruction scheduler uses a "pipeline hazard recognizer" to 28567figure out the possibility of the instruction issue by the processor on 28568a given simulated processor cycle. The pipeline hazard recognizer is 28569automatically generated from the processor pipeline description. The 28570pipeline hazard recognizer generated from the machine description is 28571based on a deterministic finite state automaton (DFA): the instruction 28572issue is possible if there is a transition from one automaton state to 28573another one. This algorithm is very fast, and furthermore, its speed is 28574not dependent on processor complexity(1). 28575 28576 The rest of this section describes the directives that constitute an 28577automaton-based processor pipeline description. The order of these 28578constructions within the machine description file is not important. 28579 28580 The following optional construction describes names of automata 28581generated and used for the pipeline hazards recognition. Sometimes the 28582generated finite state automaton used by the pipeline hazard recognizer 28583is large. If we use more than one automaton and bind functional units 28584to the automata, the total size of the automata is usually less than the 28585size of the single automaton. If there is no one such construction, 28586only one finite state automaton is generated. 28587 28588 (define_automaton AUTOMATA-NAMES) 28589 28590 AUTOMATA-NAMES is a string giving names of the automata. The names are 28591separated by commas. All the automata should have unique names. The 28592automaton name is used in the constructions 'define_cpu_unit' and 28593'define_query_cpu_unit'. 28594 28595 Each processor functional unit used in the description of instruction 28596reservations should be described by the following construction. 28597 28598 (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 28599 28600 UNIT-NAMES is a string giving the names of the functional units 28601separated by commas. Don't use name 'nothing', it is reserved for other 28602goals. 28603 28604 AUTOMATON-NAME is a string giving the name of the automaton with which 28605the unit is bound. The automaton should be described in construction 28606'define_automaton'. You should give "automaton-name", if there is a 28607defined automaton. 28608 28609 The assignment of units to automata are constrained by the uses of the 28610units in insn reservations. The most important constraint is: if a unit 28611reservation is present on a particular cycle of an alternative for an 28612insn reservation, then some unit from the same automaton must be present 28613on the same cycle for the other alternatives of the insn reservation. 28614The rest of the constraints are mentioned in the description of the 28615subsequent constructions. 28616 28617 The following construction describes CPU functional units analogously 28618to 'define_cpu_unit'. The reservation of such units can be queried for 28619an automaton state. The instruction scheduler never queries reservation 28620of functional units for given automaton state. So as a rule, you don't 28621need this construction. This construction could be used for future code 28622generation goals (e.g. to generate VLIW insn templates). 28623 28624 (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 28625 28626 UNIT-NAMES is a string giving names of the functional units separated 28627by commas. 28628 28629 AUTOMATON-NAME is a string giving the name of the automaton with which 28630the unit is bound. 28631 28632 The following construction is the major one to describe pipeline 28633characteristics of an instruction. 28634 28635 (define_insn_reservation INSN-NAME DEFAULT_LATENCY 28636 CONDITION REGEXP) 28637 28638 DEFAULT_LATENCY is a number giving latency time of the instruction. 28639There is an important difference between the old description and the 28640automaton based pipeline description. The latency time is used for all 28641dependencies when we use the old description. In the automaton based 28642pipeline description, the given latency time is only used for true 28643dependencies. The cost of anti-dependencies is always zero and the cost 28644of output dependencies is the difference between latency times of the 28645producing and consuming insns (if the difference is negative, the cost 28646is considered to be zero). You can always change the default costs for 28647any description by using the target hook 'TARGET_SCHED_ADJUST_COST' 28648(*note Scheduling::). 28649 28650 INSN-NAME is a string giving the internal name of the insn. The 28651internal names are used in constructions 'define_bypass' and in the 28652automaton description file generated for debugging. The internal name 28653has nothing in common with the names in 'define_insn'. It is a good 28654practice to use insn classes described in the processor manual. 28655 28656 CONDITION defines what RTL insns are described by this construction. 28657You should remember that you will be in trouble if CONDITION for two or 28658more different 'define_insn_reservation' constructions is TRUE for an 28659insn. In this case what reservation will be used for the insn is not 28660defined. Such cases are not checked during generation of the pipeline 28661hazards recognizer because in general recognizing that two conditions 28662may have the same value is quite difficult (especially if the conditions 28663contain 'symbol_ref'). It is also not checked during the pipeline 28664hazard recognizer work because it would slow down the recognizer 28665considerably. 28666 28667 REGEXP is a string describing the reservation of the cpu's functional 28668units by the instruction. The reservations are described by a regular 28669expression according to the following syntax: 28670 28671 regexp = regexp "," oneof 28672 | oneof 28673 28674 oneof = oneof "|" allof 28675 | allof 28676 28677 allof = allof "+" repeat 28678 | repeat 28679 28680 repeat = element "*" number 28681 | element 28682 28683 element = cpu_function_unit_name 28684 | reservation_name 28685 | result_name 28686 | "nothing" 28687 | "(" regexp ")" 28688 28689 * ',' is used for describing the start of the next cycle in the 28690 reservation. 28691 28692 * '|' is used for describing a reservation described by the first 28693 regular expression *or* a reservation described by the second 28694 regular expression *or* etc. 28695 28696 * '+' is used for describing a reservation described by the first 28697 regular expression *and* a reservation described by the second 28698 regular expression *and* etc. 28699 28700 * '*' is used for convenience and simply means a sequence in which 28701 the regular expression are repeated NUMBER times with cycle 28702 advancing (see ','). 28703 28704 * 'cpu_function_unit_name' denotes reservation of the named 28705 functional unit. 28706 28707 * 'reservation_name' -- see description of construction 28708 'define_reservation'. 28709 28710 * 'nothing' denotes no unit reservations. 28711 28712 Sometimes unit reservations for different insns contain common parts. 28713In such case, you can simplify the pipeline description by describing 28714the common part by the following construction 28715 28716 (define_reservation RESERVATION-NAME REGEXP) 28717 28718 RESERVATION-NAME is a string giving name of REGEXP. Functional unit 28719names and reservation names are in the same name space. So the 28720reservation names should be different from the functional unit names and 28721can not be the reserved name 'nothing'. 28722 28723 The following construction is used to describe exceptions in the 28724latency time for given instruction pair. This is so called bypasses. 28725 28726 (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES 28727 [GUARD]) 28728 28729 NUMBER defines when the result generated by the instructions given in 28730string OUT_INSN_NAMES will be ready for the instructions given in string 28731IN_INSN_NAMES. Each of these strings is a comma-separated list of 28732filename-style globs and they refer to the names of 28733'define_insn_reservation's. For example: 28734 (define_bypass 1 "cpu1_load_*, cpu1_store_*" "cpu1_load_*") 28735 defines a bypass between instructions that start with 'cpu1_load_' or 28736'cpu1_store_' and those that start with 'cpu1_load_'. 28737 28738 GUARD is an optional string giving the name of a C function which 28739defines an additional guard for the bypass. The function will get the 28740two insns as parameters. If the function returns zero the bypass will 28741be ignored for this case. The additional guard is necessary to 28742recognize complicated bypasses, e.g. when the consumer is only an 28743address of insn 'store' (not a stored value). 28744 28745 If there are more one bypass with the same output and input insns, the 28746chosen bypass is the first bypass with a guard in description whose 28747guard function returns nonzero. If there is no such bypass, then bypass 28748without the guard function is chosen. 28749 28750 The following five constructions are usually used to describe VLIW 28751processors, or more precisely, to describe a placement of small 28752instructions into VLIW instruction slots. They can be used for RISC 28753processors, too. 28754 28755 (exclusion_set UNIT-NAMES UNIT-NAMES) 28756 (presence_set UNIT-NAMES PATTERNS) 28757 (final_presence_set UNIT-NAMES PATTERNS) 28758 (absence_set UNIT-NAMES PATTERNS) 28759 (final_absence_set UNIT-NAMES PATTERNS) 28760 28761 UNIT-NAMES is a string giving names of functional units separated by 28762commas. 28763 28764 PATTERNS is a string giving patterns of functional units separated by 28765comma. Currently pattern is one unit or units separated by 28766white-spaces. 28767 28768 The first construction ('exclusion_set') means that each functional 28769unit in the first string can not be reserved simultaneously with a unit 28770whose name is in the second string and vice versa. For example, the 28771construction is useful for describing processors (e.g. some SPARC 28772processors) with a fully pipelined floating point functional unit which 28773can execute simultaneously only single floating point insns or only 28774double floating point insns. 28775 28776 The second construction ('presence_set') means that each functional 28777unit in the first string can not be reserved unless at least one of 28778pattern of units whose names are in the second string is reserved. This 28779is an asymmetric relation. For example, it is useful for description 28780that VLIW 'slot1' is reserved after 'slot0' reservation. We could 28781describe it by the following construction 28782 28783 (presence_set "slot1" "slot0") 28784 28785 Or 'slot1' is reserved only after 'slot0' and unit 'b0' reservation. 28786In this case we could write 28787 28788 (presence_set "slot1" "slot0 b0") 28789 28790 The third construction ('final_presence_set') is analogous to 28791'presence_set'. The difference between them is when checking is done. 28792When an instruction is issued in given automaton state reflecting all 28793current and planned unit reservations, the automaton state is changed. 28794The first state is a source state, the second one is a result state. 28795Checking for 'presence_set' is done on the source state reservation, 28796checking for 'final_presence_set' is done on the result reservation. 28797This construction is useful to describe a reservation which is actually 28798two subsequent reservations. For example, if we use 28799 28800 (presence_set "slot1" "slot0") 28801 28802 the following insn will be never issued (because 'slot1' requires 28803'slot0' which is absent in the source state). 28804 28805 (define_reservation "insn_and_nop" "slot0 + slot1") 28806 28807 but it can be issued if we use analogous 'final_presence_set'. 28808 28809 The forth construction ('absence_set') means that each functional unit 28810in the first string can be reserved only if each pattern of units whose 28811names are in the second string is not reserved. This is an asymmetric 28812relation (actually 'exclusion_set' is analogous to this one but it is 28813symmetric). For example it might be useful in a VLIW description to say 28814that 'slot0' cannot be reserved after either 'slot1' or 'slot2' have 28815been reserved. This can be described as: 28816 28817 (absence_set "slot0" "slot1, slot2") 28818 28819 Or 'slot2' can not be reserved if 'slot0' and unit 'b0' are reserved or 28820'slot1' and unit 'b1' are reserved. In this case we could write 28821 28822 (absence_set "slot2" "slot0 b0, slot1 b1") 28823 28824 All functional units mentioned in a set should belong to the same 28825automaton. 28826 28827 The last construction ('final_absence_set') is analogous to 28828'absence_set' but checking is done on the result (state) reservation. 28829See comments for 'final_presence_set'. 28830 28831 You can control the generator of the pipeline hazard recognizer with 28832the following construction. 28833 28834 (automata_option OPTIONS) 28835 28836 OPTIONS is a string giving options which affect the generated code. 28837Currently there are the following options: 28838 28839 * "no-minimization" makes no minimization of the automaton. This is 28840 only worth to do when we are debugging the description and need to 28841 look more accurately at reservations of states. 28842 28843 * "time" means printing time statistics about the generation of 28844 automata. 28845 28846 * "stats" means printing statistics about the generated automata such 28847 as the number of DFA states, NDFA states and arcs. 28848 28849 * "v" means a generation of the file describing the result automata. 28850 The file has suffix '.dfa' and can be used for the description 28851 verification and debugging. 28852 28853 * "w" means a generation of warning instead of error for non-critical 28854 errors. 28855 28856 * "no-comb-vect" prevents the automaton generator from generating two 28857 data structures and comparing them for space efficiency. Using a 28858 comb vector to represent transitions may be better, but it can be 28859 very expensive to construct. This option is useful if the build 28860 process spends an unacceptably long time in genautomata. 28861 28862 * "ndfa" makes nondeterministic finite state automata. This affects 28863 the treatment of operator '|' in the regular expressions. The 28864 usual treatment of the operator is to try the first alternative 28865 and, if the reservation is not possible, the second alternative. 28866 The nondeterministic treatment means trying all alternatives, some 28867 of them may be rejected by reservations in the subsequent insns. 28868 28869 * "collapse-ndfa" modifies the behavior of the generator when 28870 producing an automaton. An additional state transition to collapse 28871 a nondeterministic NDFA state to a deterministic DFA state is 28872 generated. It can be triggered by passing 'const0_rtx' to 28873 state_transition. In such an automaton, cycle advance transitions 28874 are available only for these collapsed states. This option is 28875 useful for ports that want to use the 'ndfa' option, but also want 28876 to use 'define_query_cpu_unit' to assign units to insns issued in a 28877 cycle. 28878 28879 * "progress" means output of a progress bar showing how many states 28880 were generated so far for automaton being processed. This is 28881 useful during debugging a DFA description. If you see too many 28882 generated states, you could interrupt the generator of the pipeline 28883 hazard recognizer and try to figure out a reason for generation of 28884 the huge automaton. 28885 28886 As an example, consider a superscalar RISC machine which can issue 28887three insns (two integer insns and one floating point insn) on the cycle 28888but can finish only two insns. To describe this, we define the 28889following functional units. 28890 28891 (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline") 28892 (define_cpu_unit "port0, port1") 28893 28894 All simple integer insns can be executed in any integer pipeline and 28895their result is ready in two cycles. The simple integer insns are 28896issued into the first pipeline unless it is reserved, otherwise they are 28897issued into the second pipeline. Integer division and multiplication 28898insns can be executed only in the second integer pipeline and their 28899results are ready correspondingly in 9 and 4 cycles. The integer 28900division is not pipelined, i.e. the subsequent integer division insn can 28901not be issued until the current division insn finished. Floating point 28902insns are fully pipelined and their results are ready in 3 cycles. 28903Where the result of a floating point insn is used by an integer insn, an 28904additional delay of one cycle is incurred. To describe all of this we 28905could specify 28906 28907 (define_cpu_unit "div") 28908 28909 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 28910 "(i0_pipeline | i1_pipeline), (port0 | port1)") 28911 28912 (define_insn_reservation "mult" 4 (eq_attr "type" "mult") 28913 "i1_pipeline, nothing*2, (port0 | port1)") 28914 28915 (define_insn_reservation "div" 9 (eq_attr "type" "div") 28916 "i1_pipeline, div*7, div + (port0 | port1)") 28917 28918 (define_insn_reservation "float" 3 (eq_attr "type" "float") 28919 "f_pipeline, nothing, (port0 | port1)) 28920 28921 (define_bypass 4 "float" "simple,mult,div") 28922 28923 To simplify the description we could describe the following reservation 28924 28925 (define_reservation "finish" "port0|port1") 28926 28927 and use it in all 'define_insn_reservation' as in the following 28928construction 28929 28930 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 28931 "(i0_pipeline | i1_pipeline), finish") 28932 28933 ---------- Footnotes ---------- 28934 28935 (1) However, the size of the automaton depends on processor 28936complexity. To limit this effect, machine descriptions can split 28937orthogonal parts of the machine description among several automata: but 28938then, since each of these must be stepped independently, this does cause 28939a small decrease in the algorithm's performance. 28940 28941 28942File: gccint.info, Node: Conditional Execution, Next: Define Subst, Prev: Insn Attributes, Up: Machine Desc 28943 2894417.20 Conditional Execution 28945=========================== 28946 28947A number of architectures provide for some form of conditional 28948execution, or predication. The hallmark of this feature is the ability 28949to nullify most of the instructions in the instruction set. When the 28950instruction set is large and not entirely symmetric, it can be quite 28951tedious to describe these forms directly in the '.md' file. An 28952alternative is the 'define_cond_exec' template. 28953 28954 (define_cond_exec 28955 [PREDICATE-PATTERN] 28956 "CONDITION" 28957 "OUTPUT-TEMPLATE" 28958 "OPTIONAL-INSN-ATTRIBUES") 28959 28960 PREDICATE-PATTERN is the condition that must be true for the insn to be 28961executed at runtime and should match a relational operator. One can use 28962'match_operator' to match several relational operators at once. Any 28963'match_operand' operands must have no more than one alternative. 28964 28965 CONDITION is a C expression that must be true for the generated pattern 28966to match. 28967 28968 OUTPUT-TEMPLATE is a string similar to the 'define_insn' output 28969template (*note Output Template::), except that the '*' and '@' special 28970cases do not apply. This is only useful if the assembly text for the 28971predicate is a simple prefix to the main insn. In order to handle the 28972general case, there is a global variable 'current_insn_predicate' that 28973will contain the entire predicate if the current insn is predicated, and 28974will otherwise be 'NULL'. 28975 28976 OPTIONAL-INSN-ATTRIBUTES is an optional vector of attributes that gets 28977appended to the insn attributes of the produced cond_exec rtx. It can 28978be used to add some distinguishing attribute to cond_exec rtxs produced 28979that way. An example usage would be to use this attribute in 28980conjunction with attributes on the main pattern to disable particular 28981alternatives under certain conditions. 28982 28983 When 'define_cond_exec' is used, an implicit reference to the 28984'predicable' instruction attribute is made. *Note Insn Attributes::. 28985This attribute must be a boolean (i.e. have exactly two elements in its 28986LIST-OF-VALUES), with the possible values being 'no' and 'yes'. The 28987default and all uses in the insns must be a simple constant, not a 28988complex expressions. It may, however, depend on the alternative, by 28989using a comma-separated list of values. If that is the case, the port 28990should also define an 'enabled' attribute (*note Disable Insn 28991Alternatives::), which should also allow only 'no' and 'yes' as its 28992values. 28993 28994 For each 'define_insn' for which the 'predicable' attribute is true, a 28995new 'define_insn' pattern will be generated that matches a predicated 28996version of the instruction. For example, 28997 28998 (define_insn "addsi" 28999 [(set (match_operand:SI 0 "register_operand" "r") 29000 (plus:SI (match_operand:SI 1 "register_operand" "r") 29001 (match_operand:SI 2 "register_operand" "r")))] 29002 "TEST1" 29003 "add %2,%1,%0") 29004 29005 (define_cond_exec 29006 [(ne (match_operand:CC 0 "register_operand" "c") 29007 (const_int 0))] 29008 "TEST2" 29009 "(%0)") 29010 29011generates a new pattern 29012 29013 (define_insn "" 29014 [(cond_exec 29015 (ne (match_operand:CC 3 "register_operand" "c") (const_int 0)) 29016 (set (match_operand:SI 0 "register_operand" "r") 29017 (plus:SI (match_operand:SI 1 "register_operand" "r") 29018 (match_operand:SI 2 "register_operand" "r"))))] 29019 "(TEST2) && (TEST1)" 29020 "(%3) add %2,%1,%0") 29021 29022 29023File: gccint.info, Node: Define Subst, Next: Constant Definitions, Prev: Conditional Execution, Up: Machine Desc 29024 2902517.21 RTL Templates Transformations 29026=================================== 29027 29028For some hardware architectures there are common cases when the RTL 29029templates for the instructions can be derived from the other RTL 29030templates using simple transformations. E.g., 'i386.md' contains an RTL 29031template for the ordinary 'sub' instruction-- '*subsi_1', and for the 29032'sub' instruction with subsequent zero-extension--'*subsi_1_zext'. Such 29033cases can be easily implemented by a single meta-template capable of 29034generating a modified case based on the initial one: 29035 29036 (define_subst "NAME" 29037 [INPUT-TEMPLATE] 29038 "CONDITION" 29039 [OUTPUT-TEMPLATE]) 29040 INPUT-TEMPLATE is a pattern describing the source RTL template, which 29041will be transformed. 29042 29043 CONDITION is a C expression that is conjunct with the condition from 29044the input-template to generate a condition to be used in the 29045output-template. 29046 29047 OUTPUT-TEMPLATE is a pattern that will be used in the resulting 29048template. 29049 29050 'define_subst' mechanism is tightly coupled with the notion of the 29051subst attribute (*note Subst Iterators::). The use of 'define_subst' is 29052triggered by a reference to a subst attribute in the transforming RTL 29053template. This reference initiates duplication of the source RTL 29054template and substitution of the attributes with their values. The 29055source RTL template is left unchanged, while the copy is transformed by 29056'define_subst'. This transformation can fail in the case when the 29057source RTL template is not matched against the input-template of the 29058'define_subst'. In such case the copy is deleted. 29059 29060 'define_subst' can be used only in 'define_insn' and 'define_expand', 29061it cannot be used in other expressions (e.g. in 29062'define_insn_and_split'). 29063 29064* Menu: 29065 29066* Define Subst Example:: Example of 'define_subst' work. 29067* Define Subst Pattern Matching:: Process of template comparison. 29068* Define Subst Output Template:: Generation of output template. 29069 29070 29071File: gccint.info, Node: Define Subst Example, Next: Define Subst Pattern Matching, Up: Define Subst 29072 2907317.21.1 'define_subst' Example 29074------------------------------ 29075 29076To illustrate how 'define_subst' works, let us examine a simple template 29077transformation. 29078 29079 Suppose there are two kinds of instructions: one that touches flags and 29080the other that does not. The instructions of the second type could be 29081generated with the following 'define_subst': 29082 29083 (define_subst "add_clobber_subst" 29084 [(set (match_operand:SI 0 "" "") 29085 (match_operand:SI 1 "" ""))] 29086 "" 29087 [(set (match_dup 0) 29088 (match_dup 1)) 29089 (clobber (reg:CC FLAGS_REG))] 29090 29091 This 'define_subst' can be applied to any RTL pattern containing 'set' 29092of mode SI and generates a copy with clobber when it is applied. 29093 29094 Assume there is an RTL template for a 'max' instruction to be used in 29095'define_subst' mentioned above: 29096 29097 (define_insn "maxsi" 29098 [(set (match_operand:SI 0 "register_operand" "=r") 29099 (max:SI 29100 (match_operand:SI 1 "register_operand" "r") 29101 (match_operand:SI 2 "register_operand" "r")))] 29102 "" 29103 "max\t{%2, %1, %0|%0, %1, %2}" 29104 [...]) 29105 29106 To mark the RTL template for 'define_subst' application, 29107subst-attributes are used. They should be declared in advance: 29108 29109 (define_subst_attr "add_clobber_name" "add_clobber_subst" "_noclobber" "_clobber") 29110 29111 Here 'add_clobber_name' is the attribute name, 'add_clobber_subst' is 29112the name of the corresponding 'define_subst', the third argument 29113('_noclobber') is the attribute value that would be substituted into the 29114unchanged version of the source RTL template, and the last argument 29115('_clobber') is the value that would be substituted into the second, 29116transformed, version of the RTL template. 29117 29118 Once the subst-attribute has been defined, it should be used in RTL 29119templates which need to be processed by the 'define_subst'. So, the 29120original RTL template should be changed: 29121 29122 (define_insn "maxsi<add_clobber_name>" 29123 [(set (match_operand:SI 0 "register_operand" "=r") 29124 (max:SI 29125 (match_operand:SI 1 "register_operand" "r") 29126 (match_operand:SI 2 "register_operand" "r")))] 29127 "" 29128 "max\t{%2, %1, %0|%0, %1, %2}" 29129 [...]) 29130 29131 The result of the 'define_subst' usage would look like the following: 29132 29133 (define_insn "maxsi_noclobber" 29134 [(set (match_operand:SI 0 "register_operand" "=r") 29135 (max:SI 29136 (match_operand:SI 1 "register_operand" "r") 29137 (match_operand:SI 2 "register_operand" "r")))] 29138 "" 29139 "max\t{%2, %1, %0|%0, %1, %2}" 29140 [...]) 29141 (define_insn "maxsi_clobber" 29142 [(set (match_operand:SI 0 "register_operand" "=r") 29143 (max:SI 29144 (match_operand:SI 1 "register_operand" "r") 29145 (match_operand:SI 2 "register_operand" "r"))) 29146 (clobber (reg:CC FLAGS_REG))] 29147 "" 29148 "max\t{%2, %1, %0|%0, %1, %2}" 29149 [...]) 29150 29151 29152File: gccint.info, Node: Define Subst Pattern Matching, Next: Define Subst Output Template, Prev: Define Subst Example, Up: Define Subst 29153 2915417.21.2 Pattern Matching in 'define_subst' 29155------------------------------------------ 29156 29157All expressions, allowed in 'define_insn' or 'define_expand', are 29158allowed in the input-template of 'define_subst', except 'match_par_dup', 29159'match_scratch', 'match_parallel'. The meanings of expressions in the 29160input-template were changed: 29161 29162 'match_operand' matches any expression (possibly, a subtree in 29163RTL-template), if modes of the 'match_operand' and this expression are 29164the same, or mode of the 'match_operand' is 'VOIDmode', or this 29165expression is 'match_dup', 'match_op_dup'. If the expression is 29166'match_operand' too, and predicate of 'match_operand' from the input 29167pattern is not empty, then the predicates are compared. That can be 29168used for more accurate filtering of accepted RTL-templates. 29169 29170 'match_operator' matches common operators (like 'plus', 'minus'), 29171'unspec', 'unspec_volatile' operators and 'match_operator's from the 29172original pattern if the modes match and 'match_operator' from the input 29173pattern has the same number of operands as the operator from the 29174original pattern. 29175 29176 29177File: gccint.info, Node: Define Subst Output Template, Prev: Define Subst Pattern Matching, Up: Define Subst 29178 2917917.21.3 Generation of output template in 'define_subst' 29180------------------------------------------------------- 29181 29182If all necessary checks for 'define_subst' application pass, a new 29183RTL-pattern, based on the output-template, is created to replace the old 29184template. Like in input-patterns, meanings of some RTL expressions are 29185changed when they are used in output-patterns of a 'define_subst'. 29186Thus, 'match_dup' is used for copying the whole expression from the 29187original pattern, which matched corresponding 'match_operand' from the 29188input pattern. 29189 29190 'match_dup N' is used in the output template to be replaced with the 29191expression from the original pattern, which matched 'match_operand N' 29192from the input pattern. As a consequence, 'match_dup' cannot be used to 29193point to 'match_operand's from the output pattern, it should always 29194refer to a 'match_operand' from the input pattern. 29195 29196 In the output template one can refer to the expressions from the 29197original pattern and create new ones. For instance, some operands could 29198be added by means of standard 'match_operand'. 29199 29200 After replacing 'match_dup' with some RTL-subtree from the original 29201pattern, it could happen that several 'match_operand's in the output 29202pattern have the same indexes. It is unknown, how many and what indexes 29203would be used in the expression which would replace 'match_dup', so such 29204conflicts in indexes are inevitable. To overcome this issue, 29205'match_operands' and 'match_operators', which were introduced into the 29206output pattern, are renumerated when all 'match_dup's are replaced. 29207 29208 Number of alternatives in 'match_operand's introduced into the output 29209template 'M' could differ from the number of alternatives in the 29210original pattern 'N', so in the resultant pattern there would be 'N*M' 29211alternatives. Thus, constraints from the original pattern would be 29212duplicated 'N' times, constraints from the output pattern would be 29213duplicated 'M' times, producing all possible combinations. 29214 29215 29216File: gccint.info, Node: Constant Definitions, Next: Iterators, Prev: Define Subst, Up: Machine Desc 29217 2921817.22 Constant Definitions 29219========================== 29220 29221Using literal constants inside instruction patterns reduces legibility 29222and can be a maintenance problem. 29223 29224 To overcome this problem, you may use the 'define_constants' 29225expression. It contains a vector of name-value pairs. From that point 29226on, wherever any of the names appears in the MD file, it is as if the 29227corresponding value had been written instead. You may use 29228'define_constants' multiple times; each appearance adds more constants 29229to the table. It is an error to redefine a constant with a different 29230value. 29231 29232 To come back to the a29k load multiple example, instead of 29233 29234 (define_insn "" 29235 [(match_parallel 0 "load_multiple_operation" 29236 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 29237 (match_operand:SI 2 "memory_operand" "m")) 29238 (use (reg:SI 179)) 29239 (clobber (reg:SI 179))])] 29240 "" 29241 "loadm 0,0,%1,%2") 29242 29243 You could write: 29244 29245 (define_constants [ 29246 (R_BP 177) 29247 (R_FC 178) 29248 (R_CR 179) 29249 (R_Q 180) 29250 ]) 29251 29252 (define_insn "" 29253 [(match_parallel 0 "load_multiple_operation" 29254 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 29255 (match_operand:SI 2 "memory_operand" "m")) 29256 (use (reg:SI R_CR)) 29257 (clobber (reg:SI R_CR))])] 29258 "" 29259 "loadm 0,0,%1,%2") 29260 29261 The constants that are defined with a define_constant are also output 29262in the insn-codes.h header file as #defines. 29263 29264 You can also use the machine description file to define enumerations. 29265Like the constants defined by 'define_constant', these enumerations are 29266visible to both the machine description file and the main C code. 29267 29268 The syntax is as follows: 29269 29270 (define_c_enum "NAME" [ 29271 VALUE0 29272 VALUE1 29273 ... 29274 VALUEN 29275 ]) 29276 29277 This definition causes the equivalent of the following C code to appear 29278in 'insn-constants.h': 29279 29280 enum NAME { 29281 VALUE0 = 0, 29282 VALUE1 = 1, 29283 ... 29284 VALUEN = N 29285 }; 29286 #define NUM_CNAME_VALUES (N + 1) 29287 29288 where CNAME is the capitalized form of NAME. It also makes each VALUEI 29289available in the machine description file, just as if it had been 29290declared with: 29291 29292 (define_constants [(VALUEI I)]) 29293 29294 Each VALUEI is usually an upper-case identifier and usually begins with 29295CNAME. 29296 29297 You can split the enumeration definition into as many statements as you 29298like. The above example is directly equivalent to: 29299 29300 (define_c_enum "NAME" [VALUE0]) 29301 (define_c_enum "NAME" [VALUE1]) 29302 ... 29303 (define_c_enum "NAME" [VALUEN]) 29304 29305 Splitting the enumeration helps to improve the modularity of each 29306individual '.md' file. For example, if a port defines its 29307synchronization instructions in a separate 'sync.md' file, it is 29308convenient to define all synchronization-specific enumeration values in 29309'sync.md' rather than in the main '.md' file. 29310 29311 Some enumeration names have special significance to GCC: 29312 29313'unspecv' 29314 If an enumeration called 'unspecv' is defined, GCC will use it when 29315 printing out 'unspec_volatile' expressions. For example: 29316 29317 (define_c_enum "unspecv" [ 29318 UNSPECV_BLOCKAGE 29319 ]) 29320 29321 causes GCC to print '(unspec_volatile ... 0)' as: 29322 29323 (unspec_volatile ... UNSPECV_BLOCKAGE) 29324 29325'unspec' 29326 If an enumeration called 'unspec' is defined, GCC will use it when 29327 printing out 'unspec' expressions. GCC will also use it when 29328 printing out 'unspec_volatile' expressions unless an 'unspecv' 29329 enumeration is also defined. You can therefore decide whether to 29330 keep separate enumerations for volatile and non-volatile 29331 expressions or whether to use the same enumeration for both. 29332 29333 Another way of defining an enumeration is to use 'define_enum': 29334 29335 (define_enum "NAME" [ 29336 VALUE0 29337 VALUE1 29338 ... 29339 VALUEN 29340 ]) 29341 29342 This directive implies: 29343 29344 (define_c_enum "NAME" [ 29345 CNAME_CVALUE0 29346 CNAME_CVALUE1 29347 ... 29348 CNAME_CVALUEN 29349 ]) 29350 29351 where CVALUEI is the capitalized form of VALUEI. However, unlike 29352'define_c_enum', the enumerations defined by 'define_enum' can be used 29353in attribute specifications (*note define_enum_attr::). 29354 29355 29356File: gccint.info, Node: Iterators, Prev: Constant Definitions, Up: Machine Desc 29357 2935817.23 Iterators 29359=============== 29360 29361Ports often need to define similar patterns for more than one machine 29362mode or for more than one rtx code. GCC provides some simple iterator 29363facilities to make this process easier. 29364 29365* Menu: 29366 29367* Mode Iterators:: Generating variations of patterns for different modes. 29368* Code Iterators:: Doing the same for codes. 29369* Int Iterators:: Doing the same for integers. 29370* Subst Iterators:: Generating variations of patterns for define_subst. 29371 29372 29373File: gccint.info, Node: Mode Iterators, Next: Code Iterators, Up: Iterators 29374 2937517.23.1 Mode Iterators 29376---------------------- 29377 29378Ports often need to define similar patterns for two or more different 29379modes. For example: 29380 29381 * If a processor has hardware support for both single and double 29382 floating-point arithmetic, the 'SFmode' patterns tend to be very 29383 similar to the 'DFmode' ones. 29384 29385 * If a port uses 'SImode' pointers in one configuration and 'DImode' 29386 pointers in another, it will usually have very similar 'SImode' and 29387 'DImode' patterns for manipulating pointers. 29388 29389 Mode iterators allow several patterns to be instantiated from one '.md' 29390file template. They can be used with any type of rtx-based construct, 29391such as a 'define_insn', 'define_split', or 'define_peephole2'. 29392 29393* Menu: 29394 29395* Defining Mode Iterators:: Defining a new mode iterator. 29396* Substitutions:: Combining mode iterators with substitutions 29397* Examples:: Examples 29398 29399 29400File: gccint.info, Node: Defining Mode Iterators, Next: Substitutions, Up: Mode Iterators 29401 2940217.23.1.1 Defining Mode Iterators 29403................................. 29404 29405The syntax for defining a mode iterator is: 29406 29407 (define_mode_iterator NAME [(MODE1 "COND1") ... (MODEN "CONDN")]) 29408 29409 This allows subsequent '.md' file constructs to use the mode suffix 29410':NAME'. Every construct that does so will be expanded N times, once 29411with every use of ':NAME' replaced by ':MODE1', once with every use 29412replaced by ':MODE2', and so on. In the expansion for a particular 29413MODEI, every C condition will also require that CONDI be true. 29414 29415 For example: 29416 29417 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 29418 29419 defines a new mode suffix ':P'. Every construct that uses ':P' will be 29420expanded twice, once with every ':P' replaced by ':SI' and once with 29421every ':P' replaced by ':DI'. The ':SI' version will only apply if 29422'Pmode == SImode' and the ':DI' version will only apply if 'Pmode == 29423DImode'. 29424 29425 As with other '.md' conditions, an empty string is treated as "always 29426true". '(MODE "")' can also be abbreviated to 'MODE'. For example: 29427 29428 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 29429 29430 means that the ':DI' expansion only applies if 'TARGET_64BIT' but that 29431the ':SI' expansion has no such constraint. 29432 29433 Iterators are applied in the order they are defined. This can be 29434significant if two iterators are used in a construct that requires 29435substitutions. *Note Substitutions::. 29436 29437 29438File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Iterators, Up: Mode Iterators 29439 2944017.23.1.2 Substitution in Mode Iterators 29441........................................ 29442 29443If an '.md' file construct uses mode iterators, each version of the 29444construct will often need slightly different strings or modes. For 29445example: 29446 29447 * When a 'define_expand' defines several 'addM3' patterns (*note 29448 Standard Names::), each expander will need to use the appropriate 29449 mode name for M. 29450 29451 * When a 'define_insn' defines several instruction patterns, each 29452 instruction will often use a different assembler mnemonic. 29453 29454 * When a 'define_insn' requires operands with different modes, using 29455 an iterator for one of the operand modes usually requires a 29456 specific mode for the other operand(s). 29457 29458 GCC supports such variations through a system of "mode attributes". 29459There are two standard attributes: 'mode', which is the name of the mode 29460in lower case, and 'MODE', which is the same thing in upper case. You 29461can define other attributes using: 29462 29463 (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")]) 29464 29465 where NAME is the name of the attribute and VALUEI is the value 29466associated with MODEI. 29467 29468 When GCC replaces some :ITERATOR with :MODE, it will scan each string 29469and mode in the pattern for sequences of the form '<ITERATOR:ATTR>', 29470where ATTR is the name of a mode attribute. If the attribute is defined 29471for MODE, the whole '<...>' sequence will be replaced by the appropriate 29472attribute value. 29473 29474 For example, suppose an '.md' file has: 29475 29476 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 29477 (define_mode_attr load [(SI "lw") (DI "ld")]) 29478 29479 If one of the patterns that uses ':P' contains the string 29480'"<P:load>\t%0,%1"', the 'SI' version of that pattern will use 29481'"lw\t%0,%1"' and the 'DI' version will use '"ld\t%0,%1"'. 29482 29483 Here is an example of using an attribute for a mode: 29484 29485 (define_mode_iterator LONG [SI DI]) 29486 (define_mode_attr SHORT [(SI "HI") (DI "SI")]) 29487 (define_insn ... 29488 (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...) 29489 29490 The 'ITERATOR:' prefix may be omitted, in which case the substitution 29491will be attempted for every iterator expansion. 29492 29493 29494File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Iterators 29495 2949617.23.1.3 Mode Iterator Examples 29497................................ 29498 29499Here is an example from the MIPS port. It defines the following modes 29500and attributes (among others): 29501 29502 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 29503 (define_mode_attr d [(SI "") (DI "d")]) 29504 29505 and uses the following template to define both 'subsi3' and 'subdi3': 29506 29507 (define_insn "sub<mode>3" 29508 [(set (match_operand:GPR 0 "register_operand" "=d") 29509 (minus:GPR (match_operand:GPR 1 "register_operand" "d") 29510 (match_operand:GPR 2 "register_operand" "d")))] 29511 "" 29512 "<d>subu\t%0,%1,%2" 29513 [(set_attr "type" "arith") 29514 (set_attr "mode" "<MODE>")]) 29515 29516 This is exactly equivalent to: 29517 29518 (define_insn "subsi3" 29519 [(set (match_operand:SI 0 "register_operand" "=d") 29520 (minus:SI (match_operand:SI 1 "register_operand" "d") 29521 (match_operand:SI 2 "register_operand" "d")))] 29522 "" 29523 "subu\t%0,%1,%2" 29524 [(set_attr "type" "arith") 29525 (set_attr "mode" "SI")]) 29526 29527 (define_insn "subdi3" 29528 [(set (match_operand:DI 0 "register_operand" "=d") 29529 (minus:DI (match_operand:DI 1 "register_operand" "d") 29530 (match_operand:DI 2 "register_operand" "d")))] 29531 "" 29532 "dsubu\t%0,%1,%2" 29533 [(set_attr "type" "arith") 29534 (set_attr "mode" "DI")]) 29535 29536 29537File: gccint.info, Node: Code Iterators, Next: Int Iterators, Prev: Mode Iterators, Up: Iterators 29538 2953917.23.2 Code Iterators 29540---------------------- 29541 29542Code iterators operate in a similar way to mode iterators. *Note Mode 29543Iterators::. 29544 29545 The construct: 29546 29547 (define_code_iterator NAME [(CODE1 "COND1") ... (CODEN "CONDN")]) 29548 29549 defines a pseudo rtx code NAME that can be instantiated as CODEI if 29550condition CONDI is true. Each CODEI must have the same rtx format. 29551*Note RTL Classes::. 29552 29553 As with mode iterators, each pattern that uses NAME will be expanded N 29554times, once with all uses of NAME replaced by CODE1, once with all uses 29555replaced by CODE2, and so on. *Note Defining Mode Iterators::. 29556 29557 It is possible to define attributes for codes as well as for modes. 29558There are two standard code attributes: 'code', the name of the code in 29559lower case, and 'CODE', the name of the code in upper case. Other 29560attributes are defined using: 29561 29562 (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")]) 29563 29564 Here's an example of code iterators in action, taken from the MIPS 29565port: 29566 29567 (define_code_iterator any_cond [unordered ordered unlt unge uneq ltgt unle ungt 29568 eq ne gt ge lt le gtu geu ltu leu]) 29569 29570 (define_expand "b<code>" 29571 [(set (pc) 29572 (if_then_else (any_cond:CC (cc0) 29573 (const_int 0)) 29574 (label_ref (match_operand 0 "")) 29575 (pc)))] 29576 "" 29577 { 29578 gen_conditional_branch (operands, <CODE>); 29579 DONE; 29580 }) 29581 29582 This is equivalent to: 29583 29584 (define_expand "bunordered" 29585 [(set (pc) 29586 (if_then_else (unordered:CC (cc0) 29587 (const_int 0)) 29588 (label_ref (match_operand 0 "")) 29589 (pc)))] 29590 "" 29591 { 29592 gen_conditional_branch (operands, UNORDERED); 29593 DONE; 29594 }) 29595 29596 (define_expand "bordered" 29597 [(set (pc) 29598 (if_then_else (ordered:CC (cc0) 29599 (const_int 0)) 29600 (label_ref (match_operand 0 "")) 29601 (pc)))] 29602 "" 29603 { 29604 gen_conditional_branch (operands, ORDERED); 29605 DONE; 29606 }) 29607 29608 ... 29609 29610 29611File: gccint.info, Node: Int Iterators, Next: Subst Iterators, Prev: Code Iterators, Up: Iterators 29612 2961317.23.3 Int Iterators 29614--------------------- 29615 29616Int iterators operate in a similar way to code iterators. *Note Code 29617Iterators::. 29618 29619 The construct: 29620 29621 (define_int_iterator NAME [(INT1 "COND1") ... (INTN "CONDN")]) 29622 29623 defines a pseudo integer constant NAME that can be instantiated as INTI 29624if condition CONDI is true. Each INT must have the same rtx format. 29625*Note RTL Classes::. Int iterators can appear in only those rtx fields 29626that have 'i' as the specifier. This means that each INT has to be a 29627constant defined using define_constant or define_c_enum. 29628 29629 As with mode and code iterators, each pattern that uses NAME will be 29630expanded N times, once with all uses of NAME replaced by INT1, once with 29631all uses replaced by INT2, and so on. *Note Defining Mode Iterators::. 29632 29633 It is possible to define attributes for ints as well as for codes and 29634modes. Attributes are defined using: 29635 29636 (define_int_attr NAME [(INT1 "VALUE1") ... (INTN "VALUEN")]) 29637 29638 Here's an example of int iterators in action, taken from the ARM port: 29639 29640 (define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG]) 29641 29642 (define_int_attr absneg [(UNSPEC_VQABS "abs") (UNSPEC_VQNEG "neg")]) 29643 29644 (define_insn "neon_vq<absneg><mode>" 29645 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 29646 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 29647 (match_operand:SI 2 "immediate_operand" "i")] 29648 QABSNEG))] 29649 "TARGET_NEON" 29650 "vq<absneg>.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 29651 [(set_attr "type" "neon_vqneg_vqabs")] 29652 ) 29653 29654 29655 This is equivalent to: 29656 29657 (define_insn "neon_vqabs<mode>" 29658 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 29659 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 29660 (match_operand:SI 2 "immediate_operand" "i")] 29661 UNSPEC_VQABS))] 29662 "TARGET_NEON" 29663 "vqabs.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 29664 [(set_attr "type" "neon_vqneg_vqabs")] 29665 ) 29666 29667 (define_insn "neon_vqneg<mode>" 29668 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 29669 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 29670 (match_operand:SI 2 "immediate_operand" "i")] 29671 UNSPEC_VQNEG))] 29672 "TARGET_NEON" 29673 "vqneg.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 29674 [(set_attr "type" "neon_vqneg_vqabs")] 29675 ) 29676 29677 29678 29679File: gccint.info, Node: Subst Iterators, Prev: Int Iterators, Up: Iterators 29680 2968117.23.4 Subst Iterators 29682----------------------- 29683 29684Subst iterators are special type of iterators with the following 29685restrictions: they could not be declared explicitly, they always have 29686only two values, and they do not have explicit dedicated name. 29687Subst-iterators are triggered only when corresponding subst-attribute is 29688used in RTL-pattern. 29689 29690 Subst iterators transform templates in the following way: the templates 29691are duplicated, the subst-attributes in these templates are replaced 29692with the corresponding values, and a new attribute is implicitly added 29693to the given 'define_insn'/'define_expand'. The name of the added 29694attribute matches the name of 'define_subst'. Such attributes are 29695declared implicitly, and it is not allowed to have a 'define_attr' named 29696as a 'define_subst'. 29697 29698 Each subst iterator is linked to a 'define_subst'. It is declared 29699implicitly by the first appearance of the corresponding 29700'define_subst_attr', and it is not allowed to define it explicitly. 29701 29702 Declarations of subst-attributes have the following syntax: 29703 29704 (define_subst_attr "NAME" 29705 "SUBST-NAME" 29706 "NO-SUBST-VALUE" 29707 "SUBST-APPLIED-VALUE") 29708 29709 NAME is a string with which the given subst-attribute could be referred 29710to. 29711 29712 SUBST-NAME shows which 'define_subst' should be applied to an 29713RTL-template if the given subst-attribute is present in the 29714RTL-template. 29715 29716 NO-SUBST-VALUE is a value with which subst-attribute would be replaced 29717in the first copy of the original RTL-template. 29718 29719 SUBST-APPLIED-VALUE is a value with which subst-attribute would be 29720replaced in the second copy of the original RTL-template. 29721 29722 29723File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top 29724 2972518 Target Description Macros and Functions 29726****************************************** 29727 29728In addition to the file 'MACHINE.md', a machine description includes a C 29729header file conventionally given the name 'MACHINE.h' and a C source 29730file named 'MACHINE.c'. The header file defines numerous macros that 29731convey the information about the target machine that does not fit into 29732the scheme of the '.md' file. The file 'tm.h' should be a link to 29733'MACHINE.h'. The header file 'config.h' includes 'tm.h' and most 29734compiler source files include 'config.h'. The source file defines a 29735variable 'targetm', which is a structure containing pointers to 29736functions and data relating to the target machine. 'MACHINE.c' should 29737also contain their definitions, if they are not defined elsewhere in 29738GCC, and other functions called through the macros defined in the '.h' 29739file. 29740 29741* Menu: 29742 29743* Target Structure:: The 'targetm' variable. 29744* Driver:: Controlling how the driver runs the compilation passes. 29745* Run-time Target:: Defining '-m' options like '-m68000' and '-m68020'. 29746* Per-Function Data:: Defining data structures for per-function information. 29747* Storage Layout:: Defining sizes and alignments of data. 29748* Type Layout:: Defining sizes and properties of basic user data types. 29749* Registers:: Naming and describing the hardware registers. 29750* Register Classes:: Defining the classes of hardware registers. 29751* Stack and Calling:: Defining which way the stack grows and by how much. 29752* Varargs:: Defining the varargs macros. 29753* Trampolines:: Code set up at run time to enter a nested function. 29754* Library Calls:: Controlling how library routines are implicitly called. 29755* Addressing Modes:: Defining addressing modes valid for memory operands. 29756* Anchored Addresses:: Defining how '-fsection-anchors' should work. 29757* Condition Code:: Defining how insns update the condition code. 29758* Costs:: Defining relative costs of different operations. 29759* Scheduling:: Adjusting the behavior of the instruction scheduler. 29760* Sections:: Dividing storage into text, data, and other sections. 29761* PIC:: Macros for position independent code. 29762* Assembler Format:: Defining how to write insns and pseudo-ops to output. 29763* Debugging Info:: Defining the format of debugging output. 29764* Floating Point:: Handling floating point for cross-compilers. 29765* Mode Switching:: Insertion of mode-switching instructions. 29766* Target Attributes:: Defining target-specific uses of '__attribute__'. 29767* Emulated TLS:: Emulated TLS support. 29768* MIPS Coprocessors:: MIPS coprocessor support and how to customize it. 29769* PCH Target:: Validity checking for precompiled headers. 29770* C++ ABI:: Controlling C++ ABI changes. 29771* Named Address Spaces:: Adding support for named address spaces 29772* Misc:: Everything else. 29773 29774 29775File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros 29776 2977718.1 The Global 'targetm' Variable 29778================================== 29779 29780 -- Variable: struct gcc_target targetm 29781 The target '.c' file must define the global 'targetm' variable 29782 which contains pointers to functions and data relating to the 29783 target machine. The variable is declared in 'target.h'; 29784 'target-def.h' defines the macro 'TARGET_INITIALIZER' which is used 29785 to initialize the variable, and macros for the default initializers 29786 for elements of the structure. The '.c' file should override those 29787 macros for which the default definition is inappropriate. For 29788 example: 29789 #include "target.h" 29790 #include "target-def.h" 29791 29792 /* Initialize the GCC target structure. */ 29793 29794 #undef TARGET_COMP_TYPE_ATTRIBUTES 29795 #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes 29796 29797 struct gcc_target targetm = TARGET_INITIALIZER; 29798 29799 Where a macro should be defined in the '.c' file in this manner to form 29800part of the 'targetm' structure, it is documented below as a "Target 29801Hook" with a prototype. Many macros will change in future from being 29802defined in the '.h' file to being part of the 'targetm' structure. 29803 29804 Similarly, there is a 'targetcm' variable for hooks that are specific 29805to front ends for C-family languages, documented as "C Target Hook". 29806This is declared in 'c-family/c-target.h', the initializer 29807'TARGETCM_INITIALIZER' in 'c-family/c-target-def.h'. If targets 29808initialize 'targetcm' themselves, they should set 29809'target_has_targetcm=yes' in 'config.gcc'; otherwise a default 29810definition is used. 29811 29812 Similarly, there is a 'targetm_common' variable for hooks that are 29813shared between the compiler driver and the compilers proper, documented 29814as "Common Target Hook". This is declared in 'common/common-target.h', 29815the initializer 'TARGETM_COMMON_INITIALIZER' in 29816'common/common-target-def.h'. If targets initialize 'targetm_common' 29817themselves, they should set 'target_has_targetm_common=yes' in 29818'config.gcc'; otherwise a default definition is used. 29819 29820 29821File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros 29822 2982318.2 Controlling the Compilation Driver, 'gcc' 29824============================================== 29825 29826You can control the compilation driver. 29827 29828 -- Macro: DRIVER_SELF_SPECS 29829 A list of specs for the driver itself. It should be a suitable 29830 initializer for an array of strings, with no surrounding braces. 29831 29832 The driver applies these specs to its own command line between 29833 loading default 'specs' files (but not command-line specified ones) 29834 and choosing the multilib directory or running any subcommands. It 29835 applies them in the order given, so each spec can depend on the 29836 options added by earlier ones. It is also possible to remove 29837 options using '%<OPTION' in the usual way. 29838 29839 This macro can be useful when a port has several interdependent 29840 target options. It provides a way of standardizing the command 29841 line so that the other specs are easier to write. 29842 29843 Do not define this macro if it does not need to do anything. 29844 29845 -- Macro: OPTION_DEFAULT_SPECS 29846 A list of specs used to support configure-time default options 29847 (i.e. '--with' options) in the driver. It should be a suitable 29848 initializer for an array of structures, each containing two 29849 strings, without the outermost pair of surrounding braces. 29850 29851 The first item in the pair is the name of the default. This must 29852 match the code in 'config.gcc' for the target. The second item is 29853 a spec to apply if a default with this name was specified. The 29854 string '%(VALUE)' in the spec will be replaced by the value of the 29855 default everywhere it occurs. 29856 29857 The driver will apply these specs to its own command line between 29858 loading default 'specs' files and processing 'DRIVER_SELF_SPECS', 29859 using the same mechanism as 'DRIVER_SELF_SPECS'. 29860 29861 Do not define this macro if it does not need to do anything. 29862 29863 -- Macro: CPP_SPEC 29864 A C string constant that tells the GCC driver program options to 29865 pass to CPP. It can also specify how to translate options you give 29866 to GCC into options for GCC to pass to the CPP. 29867 29868 Do not define this macro if it does not need to do anything. 29869 29870 -- Macro: CPLUSPLUS_CPP_SPEC 29871 This macro is just like 'CPP_SPEC', but is used for C++, rather 29872 than C. If you do not define this macro, then the value of 29873 'CPP_SPEC' (if any) will be used instead. 29874 29875 -- Macro: CC1_SPEC 29876 A C string constant that tells the GCC driver program options to 29877 pass to 'cc1', 'cc1plus', 'f771', and the other language front 29878 ends. It can also specify how to translate options you give to GCC 29879 into options for GCC to pass to front ends. 29880 29881 Do not define this macro if it does not need to do anything. 29882 29883 -- Macro: CC1PLUS_SPEC 29884 A C string constant that tells the GCC driver program options to 29885 pass to 'cc1plus'. It can also specify how to translate options 29886 you give to GCC into options for GCC to pass to the 'cc1plus'. 29887 29888 Do not define this macro if it does not need to do anything. Note 29889 that everything defined in CC1_SPEC is already passed to 'cc1plus' 29890 so there is no need to duplicate the contents of CC1_SPEC in 29891 CC1PLUS_SPEC. 29892 29893 -- Macro: ASM_SPEC 29894 A C string constant that tells the GCC driver program options to 29895 pass to the assembler. It can also specify how to translate 29896 options you give to GCC into options for GCC to pass to the 29897 assembler. See the file 'sun3.h' for an example of this. 29898 29899 Do not define this macro if it does not need to do anything. 29900 29901 -- Macro: ASM_FINAL_SPEC 29902 A C string constant that tells the GCC driver program how to run 29903 any programs which cleanup after the normal assembler. Normally, 29904 this is not needed. See the file 'mips.h' for an example of this. 29905 29906 Do not define this macro if it does not need to do anything. 29907 29908 -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT 29909 Define this macro, with no value, if the driver should give the 29910 assembler an argument consisting of a single dash, '-', to instruct 29911 it to read from its standard input (which will be a pipe connected 29912 to the output of the compiler proper). This argument is given 29913 after any '-o' option specifying the name of the output file. 29914 29915 If you do not define this macro, the assembler is assumed to read 29916 its standard input if given no non-option arguments. If your 29917 assembler cannot read standard input at all, use a '%{pipe:%e}' 29918 construct; see 'mips.h' for instance. 29919 29920 -- Macro: LINK_SPEC 29921 A C string constant that tells the GCC driver program options to 29922 pass to the linker. It can also specify how to translate options 29923 you give to GCC into options for GCC to pass to the linker. 29924 29925 Do not define this macro if it does not need to do anything. 29926 29927 -- Macro: LIB_SPEC 29928 Another C string constant used much like 'LINK_SPEC'. The 29929 difference between the two is that 'LIB_SPEC' is used at the end of 29930 the command given to the linker. 29931 29932 If this macro is not defined, a default is provided that loads the 29933 standard C library from the usual place. See 'gcc.c'. 29934 29935 -- Macro: LIBGCC_SPEC 29936 Another C string constant that tells the GCC driver program how and 29937 when to place a reference to 'libgcc.a' into the linker command 29938 line. This constant is placed both before and after the value of 29939 'LIB_SPEC'. 29940 29941 If this macro is not defined, the GCC driver provides a default 29942 that passes the string '-lgcc' to the linker. 29943 29944 -- Macro: REAL_LIBGCC_SPEC 29945 By default, if 'ENABLE_SHARED_LIBGCC' is defined, the 'LIBGCC_SPEC' 29946 is not directly used by the driver program but is instead modified 29947 to refer to different versions of 'libgcc.a' depending on the 29948 values of the command line flags '-static', '-shared', 29949 '-static-libgcc', and '-shared-libgcc'. On targets where these 29950 modifications are inappropriate, define 'REAL_LIBGCC_SPEC' instead. 29951 'REAL_LIBGCC_SPEC' tells the driver how to place a reference to 29952 'libgcc' on the link command line, but, unlike 'LIBGCC_SPEC', it is 29953 used unmodified. 29954 29955 -- Macro: USE_LD_AS_NEEDED 29956 A macro that controls the modifications to 'LIBGCC_SPEC' mentioned 29957 in 'REAL_LIBGCC_SPEC'. If nonzero, a spec will be generated that 29958 uses '--as-needed' or equivalent options and the shared 'libgcc' in 29959 place of the static exception handler library, when linking without 29960 any of '-static', '-static-libgcc', or '-shared-libgcc'. 29961 29962 -- Macro: LINK_EH_SPEC 29963 If defined, this C string constant is added to 'LINK_SPEC'. When 29964 'USE_LD_AS_NEEDED' is zero or undefined, it also affects the 29965 modifications to 'LIBGCC_SPEC' mentioned in 'REAL_LIBGCC_SPEC'. 29966 29967 -- Macro: STARTFILE_SPEC 29968 Another C string constant used much like 'LINK_SPEC'. The 29969 difference between the two is that 'STARTFILE_SPEC' is used at the 29970 very beginning of the command given to the linker. 29971 29972 If this macro is not defined, a default is provided that loads the 29973 standard C startup file from the usual place. See 'gcc.c'. 29974 29975 -- Macro: ENDFILE_SPEC 29976 Another C string constant used much like 'LINK_SPEC'. The 29977 difference between the two is that 'ENDFILE_SPEC' is used at the 29978 very end of the command given to the linker. 29979 29980 Do not define this macro if it does not need to do anything. 29981 29982 -- Macro: THREAD_MODEL_SPEC 29983 GCC '-v' will print the thread model GCC was configured to use. 29984 However, this doesn't work on platforms that are multilibbed on 29985 thread models, such as AIX 4.3. On such platforms, define 29986 'THREAD_MODEL_SPEC' such that it evaluates to a string without 29987 blanks that names one of the recognized thread models. '%*', the 29988 default value of this macro, will expand to the value of 29989 'thread_file' set in 'config.gcc'. 29990 29991 -- Macro: SYSROOT_SUFFIX_SPEC 29992 Define this macro to add a suffix to the target sysroot when GCC is 29993 configured with a sysroot. This will cause GCC to search for 29994 usr/lib, et al, within sysroot+suffix. 29995 29996 -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC 29997 Define this macro to add a headers_suffix to the target sysroot 29998 when GCC is configured with a sysroot. This will cause GCC to pass 29999 the updated sysroot+headers_suffix to CPP, causing it to search for 30000 usr/include, et al, within sysroot+headers_suffix. 30001 30002 -- Macro: EXTRA_SPECS 30003 Define this macro to provide additional specifications to put in 30004 the 'specs' file that can be used in various specifications like 30005 'CC1_SPEC'. 30006 30007 The definition should be an initializer for an array of structures, 30008 containing a string constant, that defines the specification name, 30009 and a string constant that provides the specification. 30010 30011 Do not define this macro if it does not need to do anything. 30012 30013 'EXTRA_SPECS' is useful when an architecture contains several 30014 related targets, which have various '..._SPECS' which are similar 30015 to each other, and the maintainer would like one central place to 30016 keep these definitions. 30017 30018 For example, the PowerPC System V.4 targets use 'EXTRA_SPECS' to 30019 define either '_CALL_SYSV' when the System V calling sequence is 30020 used or '_CALL_AIX' when the older AIX-based calling sequence is 30021 used. 30022 30023 The 'config/rs6000/rs6000.h' target file defines: 30024 30025 #define EXTRA_SPECS \ 30026 { "cpp_sysv_default", CPP_SYSV_DEFAULT }, 30027 30028 #define CPP_SYS_DEFAULT "" 30029 30030 The 'config/rs6000/sysv.h' target file defines: 30031 #undef CPP_SPEC 30032 #define CPP_SPEC \ 30033 "%{posix: -D_POSIX_SOURCE } \ 30034 %{mcall-sysv: -D_CALL_SYSV } \ 30035 %{!mcall-sysv: %(cpp_sysv_default) } \ 30036 %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}" 30037 30038 #undef CPP_SYSV_DEFAULT 30039 #define CPP_SYSV_DEFAULT "-D_CALL_SYSV" 30040 30041 while the 'config/rs6000/eabiaix.h' target file defines 30042 'CPP_SYSV_DEFAULT' as: 30043 30044 #undef CPP_SYSV_DEFAULT 30045 #define CPP_SYSV_DEFAULT "-D_CALL_AIX" 30046 30047 -- Macro: LINK_LIBGCC_SPECIAL_1 30048 Define this macro if the driver program should find the library 30049 'libgcc.a'. If you do not define this macro, the driver program 30050 will pass the argument '-lgcc' to tell the linker to do the search. 30051 30052 -- Macro: LINK_GCC_C_SEQUENCE_SPEC 30053 The sequence in which libgcc and libc are specified to the linker. 30054 By default this is '%G %L %G'. 30055 30056 -- Macro: POST_LINK_SPEC 30057 Define this macro to add additional steps to be executed after 30058 linker. The default value of this macro is empty string. 30059 30060 -- Macro: LINK_COMMAND_SPEC 30061 A C string constant giving the complete command line need to 30062 execute the linker. When you do this, you will need to update your 30063 port each time a change is made to the link command line within 30064 'gcc.c'. Therefore, define this macro only if you need to 30065 completely redefine the command line for invoking the linker and 30066 there is no other way to accomplish the effect you need. 30067 Overriding this macro may be avoidable by overriding 30068 'LINK_GCC_C_SEQUENCE_SPEC' instead. 30069 30070 -- Common Target Hook: bool TARGET_ALWAYS_STRIP_DOTDOT 30071 True if '..' components should always be removed from directory 30072 names computed relative to GCC's internal directories, false 30073 (default) if such components should be preserved and directory 30074 names containing them passed to other tools such as the linker. 30075 30076 -- Macro: MULTILIB_DEFAULTS 30077 Define this macro as a C expression for the initializer of an array 30078 of string to tell the driver program which options are defaults for 30079 this target and thus do not need to be handled specially when using 30080 'MULTILIB_OPTIONS'. 30081 30082 Do not define this macro if 'MULTILIB_OPTIONS' is not defined in 30083 the target makefile fragment or if none of the options listed in 30084 'MULTILIB_OPTIONS' are set by default. *Note Target Fragment::. 30085 30086 -- Macro: RELATIVE_PREFIX_NOT_LINKDIR 30087 Define this macro to tell 'gcc' that it should only translate a 30088 '-B' prefix into a '-L' linker option if the prefix indicates an 30089 absolute file name. 30090 30091 -- Macro: MD_EXEC_PREFIX 30092 If defined, this macro is an additional prefix to try after 30093 'STANDARD_EXEC_PREFIX'. 'MD_EXEC_PREFIX' is not searched when the 30094 compiler is built as a cross compiler. If you define 30095 'MD_EXEC_PREFIX', then be sure to add it to the list of directories 30096 used to find the assembler in 'configure.ac'. 30097 30098 -- Macro: STANDARD_STARTFILE_PREFIX 30099 Define this macro as a C string constant if you wish to override 30100 the standard choice of 'libdir' as the default prefix to try when 30101 searching for startup files such as 'crt0.o'. 30102 'STANDARD_STARTFILE_PREFIX' is not searched when the compiler is 30103 built as a cross compiler. 30104 30105 -- Macro: STANDARD_STARTFILE_PREFIX_1 30106 Define this macro as a C string constant if you wish to override 30107 the standard choice of '/lib' as a prefix to try after the default 30108 prefix when searching for startup files such as 'crt0.o'. 30109 'STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is 30110 built as a cross compiler. 30111 30112 -- Macro: STANDARD_STARTFILE_PREFIX_2 30113 Define this macro as a C string constant if you wish to override 30114 the standard choice of '/lib' as yet another prefix to try after 30115 the default prefix when searching for startup files such as 30116 'crt0.o'. 'STANDARD_STARTFILE_PREFIX_2' is not searched when the 30117 compiler is built as a cross compiler. 30118 30119 -- Macro: MD_STARTFILE_PREFIX 30120 If defined, this macro supplies an additional prefix to try after 30121 the standard prefixes. 'MD_EXEC_PREFIX' is not searched when the 30122 compiler is built as a cross compiler. 30123 30124 -- Macro: MD_STARTFILE_PREFIX_1 30125 If defined, this macro supplies yet another prefix to try after the 30126 standard prefixes. It is not searched when the compiler is built 30127 as a cross compiler. 30128 30129 -- Macro: INIT_ENVIRONMENT 30130 Define this macro as a C string constant if you wish to set 30131 environment variables for programs called by the driver, such as 30132 the assembler and loader. The driver passes the value of this 30133 macro to 'putenv' to initialize the necessary environment 30134 variables. 30135 30136 -- Macro: LOCAL_INCLUDE_DIR 30137 Define this macro as a C string constant if you wish to override 30138 the standard choice of '/usr/local/include' as the default prefix 30139 to try when searching for local header files. 'LOCAL_INCLUDE_DIR' 30140 comes before 'NATIVE_SYSTEM_HEADER_DIR' (set in 'config.gcc', 30141 normally '/usr/include') in the search order. 30142 30143 Cross compilers do not search either '/usr/local/include' or its 30144 replacement. 30145 30146 -- Macro: NATIVE_SYSTEM_HEADER_COMPONENT 30147 The "component" corresponding to 'NATIVE_SYSTEM_HEADER_DIR'. See 30148 'INCLUDE_DEFAULTS', below, for the description of components. If 30149 you do not define this macro, no component is used. 30150 30151 -- Macro: INCLUDE_DEFAULTS 30152 Define this macro if you wish to override the entire default search 30153 path for include files. For a native compiler, the default search 30154 path usually consists of 'GCC_INCLUDE_DIR', 'LOCAL_INCLUDE_DIR', 30155 'GPLUSPLUS_INCLUDE_DIR', and 'NATIVE_SYSTEM_HEADER_DIR'. In 30156 addition, 'GPLUSPLUS_INCLUDE_DIR' and 'GCC_INCLUDE_DIR' are defined 30157 automatically by 'Makefile', and specify private search areas for 30158 GCC. The directory 'GPLUSPLUS_INCLUDE_DIR' is used only for C++ 30159 programs. 30160 30161 The definition should be an initializer for an array of structures. 30162 Each array element should have four elements: the directory name (a 30163 string constant), the component name (also a string constant), a 30164 flag for C++-only directories, and a flag showing that the includes 30165 in the directory don't need to be wrapped in 'extern 'C'' when 30166 compiling C++. Mark the end of the array with a null element. 30167 30168 The component name denotes what GNU package the include file is 30169 part of, if any, in all uppercase letters. For example, it might 30170 be 'GCC' or 'BINUTILS'. If the package is part of a 30171 vendor-supplied operating system, code the component name as '0'. 30172 30173 For example, here is the definition used for VAX/VMS: 30174 30175 #define INCLUDE_DEFAULTS \ 30176 { \ 30177 { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \ 30178 { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \ 30179 { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \ 30180 { ".", 0, 0, 0}, \ 30181 { 0, 0, 0, 0} \ 30182 } 30183 30184 Here is the order of prefixes tried for exec files: 30185 30186 1. Any prefixes specified by the user with '-B'. 30187 30188 2. The environment variable 'GCC_EXEC_PREFIX' or, if 'GCC_EXEC_PREFIX' 30189 is not set and the compiler has not been installed in the 30190 configure-time PREFIX, the location in which the compiler has 30191 actually been installed. 30192 30193 3. The directories specified by the environment variable 30194 'COMPILER_PATH'. 30195 30196 4. The macro 'STANDARD_EXEC_PREFIX', if the compiler has been 30197 installed in the configured-time PREFIX. 30198 30199 5. The location '/usr/libexec/gcc/', but only if this is a native 30200 compiler. 30201 30202 6. The location '/usr/lib/gcc/', but only if this is a native 30203 compiler. 30204 30205 7. The macro 'MD_EXEC_PREFIX', if defined, but only if this is a 30206 native compiler. 30207 30208 Here is the order of prefixes tried for startfiles: 30209 30210 1. Any prefixes specified by the user with '-B'. 30211 30212 2. The environment variable 'GCC_EXEC_PREFIX' or its automatically 30213 determined value based on the installed toolchain location. 30214 30215 3. The directories specified by the environment variable 30216 'LIBRARY_PATH' (or port-specific name; native only, cross compilers 30217 do not use this). 30218 30219 4. The macro 'STANDARD_EXEC_PREFIX', but only if the toolchain is 30220 installed in the configured PREFIX or this is a native compiler. 30221 30222 5. The location '/usr/lib/gcc/', but only if this is a native 30223 compiler. 30224 30225 6. The macro 'MD_EXEC_PREFIX', if defined, but only if this is a 30226 native compiler. 30227 30228 7. The macro 'MD_STARTFILE_PREFIX', if defined, but only if this is a 30229 native compiler, or we have a target system root. 30230 30231 8. The macro 'MD_STARTFILE_PREFIX_1', if defined, but only if this is 30232 a native compiler, or we have a target system root. 30233 30234 9. The macro 'STANDARD_STARTFILE_PREFIX', with any sysroot 30235 modifications. If this path is relative it will be prefixed by 30236 'GCC_EXEC_PREFIX' and the machine suffix or 'STANDARD_EXEC_PREFIX' 30237 and the machine suffix. 30238 30239 10. The macro 'STANDARD_STARTFILE_PREFIX_1', but only if this is a 30240 native compiler, or we have a target system root. The default for 30241 this macro is '/lib/'. 30242 30243 11. The macro 'STANDARD_STARTFILE_PREFIX_2', but only if this is a 30244 native compiler, or we have a target system root. The default for 30245 this macro is '/usr/lib/'. 30246 30247 30248File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros 30249 3025018.3 Run-time Target Specification 30251================================== 30252 30253Here are run-time target specifications. 30254 30255 -- Macro: TARGET_CPU_CPP_BUILTINS () 30256 This function-like macro expands to a block of code that defines 30257 built-in preprocessor macros and assertions for the target CPU, 30258 using the functions 'builtin_define', 'builtin_define_std' and 30259 'builtin_assert'. When the front end calls this macro it provides 30260 a trailing semicolon, and since it has finished command line option 30261 processing your code can use those results freely. 30262 30263 'builtin_assert' takes a string in the form you pass to the 30264 command-line option '-A', such as 'cpu=mips', and creates the 30265 assertion. 'builtin_define' takes a string in the form accepted by 30266 option '-D' and unconditionally defines the macro. 30267 30268 'builtin_define_std' takes a string representing the name of an 30269 object-like macro. If it doesn't lie in the user's namespace, 30270 'builtin_define_std' defines it unconditionally. Otherwise, it 30271 defines a version with two leading underscores, and another version 30272 with two leading and trailing underscores, and defines the original 30273 only if an ISO standard was not requested on the command line. For 30274 example, passing 'unix' defines '__unix', '__unix__' and possibly 30275 'unix'; passing '_mips' defines '__mips', '__mips__' and possibly 30276 '_mips', and passing '_ABI64' defines only '_ABI64'. 30277 30278 You can also test for the C dialect being compiled. The variable 30279 'c_language' is set to one of 'clk_c', 'clk_cplusplus' or 30280 'clk_objective_c'. Note that if we are preprocessing assembler, 30281 this variable will be 'clk_c' but the function-like macro 30282 'preprocessing_asm_p()' will return true, so you might want to 30283 check for that first. If you need to check for strict ANSI, the 30284 variable 'flag_iso' can be used. The function-like macro 30285 'preprocessing_trad_p()' can be used to check for traditional 30286 preprocessing. 30287 30288 -- Macro: TARGET_OS_CPP_BUILTINS () 30289 Similarly to 'TARGET_CPU_CPP_BUILTINS' but this macro is optional 30290 and is used for the target operating system instead. 30291 30292 -- Macro: TARGET_OBJFMT_CPP_BUILTINS () 30293 Similarly to 'TARGET_CPU_CPP_BUILTINS' but this macro is optional 30294 and is used for the target object format. 'elfos.h' uses this 30295 macro to define '__ELF__', so you probably do not need to define it 30296 yourself. 30297 30298 -- Variable: extern int target_flags 30299 This variable is declared in 'options.h', which is included before 30300 any target-specific headers. 30301 30302 -- Common Target Hook: int TARGET_DEFAULT_TARGET_FLAGS 30303 This variable specifies the initial value of 'target_flags'. Its 30304 default setting is 0. 30305 30306 -- Common Target Hook: bool TARGET_HANDLE_OPTION (struct gcc_options 30307 *OPTS, struct gcc_options *OPTS_SET, const struct 30308 cl_decoded_option *DECODED, location_t LOC) 30309 This hook is called whenever the user specifies one of the 30310 target-specific options described by the '.opt' definition files 30311 (*note Options::). It has the opportunity to do some 30312 option-specific processing and should return true if the option is 30313 valid. The default definition does nothing but return true. 30314 30315 DECODED specifies the option and its arguments. OPTS and OPTS_SET 30316 are the 'gcc_options' structures to be used for storing option 30317 state, and LOC is the location at which the option was passed 30318 ('UNKNOWN_LOCATION' except for options passed via attributes). 30319 30320 -- C Target Hook: bool TARGET_HANDLE_C_OPTION (size_t CODE, const char 30321 *ARG, int VALUE) 30322 This target hook is called whenever the user specifies one of the 30323 target-specific C language family options described by the '.opt' 30324 definition files(*note Options::). It has the opportunity to do 30325 some option-specific processing and should return true if the 30326 option is valid. The arguments are like for 30327 'TARGET_HANDLE_OPTION'. The default definition does nothing but 30328 return false. 30329 30330 In general, you should use 'TARGET_HANDLE_OPTION' to handle 30331 options. However, if processing an option requires routines that 30332 are only available in the C (and related language) front ends, then 30333 you should use 'TARGET_HANDLE_C_OPTION' instead. 30334 30335 -- C Target Hook: tree TARGET_OBJC_CONSTRUCT_STRING_OBJECT (tree 30336 STRING) 30337 Targets may provide a string object type that can be used within 30338 and between C, C++ and their respective Objective-C dialects. A 30339 string object might, for example, embed encoding and length 30340 information. These objects are considered opaque to the compiler 30341 and handled as references. An ideal implementation makes the 30342 composition of the string object match that of the Objective-C 30343 'NSString' ('NXString' for GNUStep), allowing efficient 30344 interworking between C-only and Objective-C code. If a target 30345 implements string objects then this hook should return a reference 30346 to such an object constructed from the normal 'C' string 30347 representation provided in STRING. At present, the hook is used by 30348 Objective-C only, to obtain a common-format string object when the 30349 target provides one. 30350 30351 -- C Target Hook: void TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE 30352 (const char *CLASSNAME) 30353 Declare that Objective C class CLASSNAME is referenced by the 30354 current TU. 30355 30356 -- C Target Hook: void TARGET_OBJC_DECLARE_CLASS_DEFINITION (const char 30357 *CLASSNAME) 30358 Declare that Objective C class CLASSNAME is defined by the current 30359 TU. 30360 30361 -- C Target Hook: bool TARGET_STRING_OBJECT_REF_TYPE_P (const_tree 30362 STRINGREF) 30363 If a target implements string objects then this hook should return 30364 'true' if STRINGREF is a valid reference to such an object. 30365 30366 -- C Target Hook: void TARGET_CHECK_STRING_OBJECT_FORMAT_ARG (tree 30367 FORMAT_ARG, tree ARGS_LIST) 30368 If a target implements string objects then this hook should should 30369 provide a facility to check the function arguments in ARGS_LIST 30370 against the format specifiers in FORMAT_ARG where the type of 30371 FORMAT_ARG is one recognized as a valid string reference type. 30372 30373 -- Target Hook: void TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE (void) 30374 This target function is similar to the hook 30375 'TARGET_OPTION_OVERRIDE' but is called when the optimize level is 30376 changed via an attribute or pragma or when it is reset at the end 30377 of the code affected by the attribute or pragma. It is not called 30378 at the beginning of compilation when 'TARGET_OPTION_OVERRIDE' is 30379 called so if you want to perform these actions then, you should 30380 have 'TARGET_OPTION_OVERRIDE' call 30381 'TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE'. 30382 30383 -- Macro: C_COMMON_OVERRIDE_OPTIONS 30384 This is similar to the 'TARGET_OPTION_OVERRIDE' hook but is only 30385 used in the C language frontends (C, Objective-C, C++, 30386 Objective-C++) and so can be used to alter option flag variables 30387 which only exist in those frontends. 30388 30389 -- Common Target Hook: const struct default_options * 30390 TARGET_OPTION_OPTIMIZATION_TABLE 30391 Some machines may desire to change what optimizations are performed 30392 for various optimization levels. This variable, if defined, 30393 describes options to enable at particular sets of optimization 30394 levels. These options are processed once just after the 30395 optimization level is determined and before the remainder of the 30396 command options have been parsed, so may be overridden by other 30397 options passed explicitly. 30398 30399 This processing is run once at program startup and when the 30400 optimization options are changed via '#pragma GCC optimize' or by 30401 using the 'optimize' attribute. 30402 30403 -- Common Target Hook: void TARGET_OPTION_INIT_STRUCT (struct 30404 gcc_options *OPTS) 30405 Set target-dependent initial values of fields in OPTS. 30406 30407 -- Common Target Hook: void TARGET_OPTION_DEFAULT_PARAMS (void) 30408 Set target-dependent default values for '--param' settings, using 30409 calls to 'set_default_param_value'. 30410 30411 -- Macro: SWITCHABLE_TARGET 30412 Some targets need to switch between substantially different 30413 subtargets during compilation. For example, the MIPS target has 30414 one subtarget for the traditional MIPS architecture and another for 30415 MIPS16. Source code can switch between these two subarchitectures 30416 using the 'mips16' and 'nomips16' attributes. 30417 30418 Such subtargets can differ in things like the set of available 30419 registers, the set of available instructions, the costs of various 30420 operations, and so on. GCC caches a lot of this type of 30421 information in global variables, and recomputing them for each 30422 subtarget takes a significant amount of time. The compiler 30423 therefore provides a facility for maintaining several versions of 30424 the global variables and quickly switching between them; see 30425 'target-globals.h' for details. 30426 30427 Define this macro to 1 if your target needs this facility. The 30428 default is 0. 30429 30430 -- Target Hook: bool TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P 30431 (void) 30432 Returns true if the target supports IEEE 754 floating-point 30433 exceptions and rounding modes, false otherwise. This is intended 30434 to relate to the 'float' and 'double' types, but not necessarily 30435 'long double'. By default, returns true if the 'adddf3' 30436 instruction pattern is available and false otherwise, on the 30437 assumption that hardware floating point supports exceptions and 30438 rounding modes but software floating point does not. 30439 30440 30441File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros 30442 3044318.4 Defining data structures for per-function information. 30444=========================================================== 30445 30446If the target needs to store information on a per-function basis, GCC 30447provides a macro and a couple of variables to allow this. Note, just 30448using statics to store the information is a bad idea, since GCC supports 30449nested functions, so you can be halfway through encoding one function 30450when another one comes along. 30451 30452 GCC defines a data structure called 'struct function' which contains 30453all of the data specific to an individual function. This structure 30454contains a field called 'machine' whose type is 'struct machine_function 30455*', which can be used by targets to point to their own specific data. 30456 30457 If a target needs per-function specific data it should define the type 30458'struct machine_function' and also the macro 'INIT_EXPANDERS'. This 30459macro should be used to initialize the function pointer 30460'init_machine_status'. This pointer is explained below. 30461 30462 One typical use of per-function, target specific data is to create an 30463RTX to hold the register containing the function's return address. This 30464RTX can then be used to implement the '__builtin_return_address' 30465function, for level 0. 30466 30467 Note--earlier implementations of GCC used a single data area to hold 30468all of the per-function information. Thus when processing of a nested 30469function began the old per-function data had to be pushed onto a stack, 30470and when the processing was finished, it had to be popped off the stack. 30471GCC used to provide function pointers called 'save_machine_status' and 30472'restore_machine_status' to handle the saving and restoring of the 30473target specific information. Since the single data area approach is no 30474longer used, these pointers are no longer supported. 30475 30476 -- Macro: INIT_EXPANDERS 30477 Macro called to initialize any target specific information. This 30478 macro is called once per function, before generation of any RTL has 30479 begun. The intention of this macro is to allow the initialization 30480 of the function pointer 'init_machine_status'. 30481 30482 -- Variable: void (*)(struct function *) init_machine_status 30483 If this function pointer is non-'NULL' it will be called once per 30484 function, before function compilation starts, in order to allow the 30485 target to perform any target specific initialization of the 'struct 30486 function' structure. It is intended that this would be used to 30487 initialize the 'machine' of that structure. 30488 30489 'struct machine_function' structures are expected to be freed by 30490 GC. Generally, any memory that they reference must be allocated by 30491 using GC allocation, including the structure itself. 30492 30493 30494File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros 30495 3049618.5 Storage Layout 30497=================== 30498 30499Note that the definitions of the macros in this table which are sizes or 30500alignments measured in bits do not need to be constant. They can be C 30501expressions that refer to static variables, such as the 'target_flags'. 30502*Note Run-time Target::. 30503 30504 -- Macro: BITS_BIG_ENDIAN 30505 Define this macro to have the value 1 if the most significant bit 30506 in a byte has the lowest number; otherwise define it to have the 30507 value zero. This means that bit-field instructions count from the 30508 most significant bit. If the machine has no bit-field 30509 instructions, then this must still be defined, but it doesn't 30510 matter which value it is defined to. This macro need not be a 30511 constant. 30512 30513 This macro does not affect the way structure fields are packed into 30514 bytes or words; that is controlled by 'BYTES_BIG_ENDIAN'. 30515 30516 -- Macro: BYTES_BIG_ENDIAN 30517 Define this macro to have the value 1 if the most significant byte 30518 in a word has the lowest number. This macro need not be a 30519 constant. 30520 30521 -- Macro: WORDS_BIG_ENDIAN 30522 Define this macro to have the value 1 if, in a multiword object, 30523 the most significant word has the lowest number. This applies to 30524 both memory locations and registers; see 'REG_WORDS_BIG_ENDIAN' if 30525 the order of words in memory is not the same as the order in 30526 registers. This macro need not be a constant. 30527 30528 -- Macro: REG_WORDS_BIG_ENDIAN 30529 On some machines, the order of words in a multiword object differs 30530 between registers in memory. In such a situation, define this 30531 macro to describe the order of words in a register. The macro 30532 'WORDS_BIG_ENDIAN' controls the order of words in memory. 30533 30534 -- Macro: FLOAT_WORDS_BIG_ENDIAN 30535 Define this macro to have the value 1 if 'DFmode', 'XFmode' or 30536 'TFmode' floating point numbers are stored in memory with the word 30537 containing the sign bit at the lowest address; otherwise define it 30538 to have the value 0. This macro need not be a constant. 30539 30540 You need not define this macro if the ordering is the same as for 30541 multi-word integers. 30542 30543 -- Macro: BITS_PER_WORD 30544 Number of bits in a word. If you do not define this macro, the 30545 default is 'BITS_PER_UNIT * UNITS_PER_WORD'. 30546 30547 -- Macro: MAX_BITS_PER_WORD 30548 Maximum number of bits in a word. If this is undefined, the 30549 default is 'BITS_PER_WORD'. Otherwise, it is the constant value 30550 that is the largest value that 'BITS_PER_WORD' can have at 30551 run-time. 30552 30553 -- Macro: UNITS_PER_WORD 30554 Number of storage units in a word; normally the size of a 30555 general-purpose register, a power of two from 1 or 8. 30556 30557 -- Macro: MIN_UNITS_PER_WORD 30558 Minimum number of units in a word. If this is undefined, the 30559 default is 'UNITS_PER_WORD'. Otherwise, it is the constant value 30560 that is the smallest value that 'UNITS_PER_WORD' can have at 30561 run-time. 30562 30563 -- Macro: POINTER_SIZE 30564 Width of a pointer, in bits. You must specify a value no wider 30565 than the width of 'Pmode'. If it is not equal to the width of 30566 'Pmode', you must define 'POINTERS_EXTEND_UNSIGNED'. If you do not 30567 specify a value the default is 'BITS_PER_WORD'. 30568 30569 -- Macro: POINTERS_EXTEND_UNSIGNED 30570 A C expression that determines how pointers should be extended from 30571 'ptr_mode' to either 'Pmode' or 'word_mode'. It is greater than 30572 zero if pointers should be zero-extended, zero if they should be 30573 sign-extended, and negative if some other sort of conversion is 30574 needed. In the last case, the extension is done by the target's 30575 'ptr_extend' instruction. 30576 30577 You need not define this macro if the 'ptr_mode', 'Pmode' and 30578 'word_mode' are all the same width. 30579 30580 -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE) 30581 A macro to update M and UNSIGNEDP when an object whose type is TYPE 30582 and which has the specified mode and signedness is to be stored in 30583 a register. This macro is only called when TYPE is a scalar type. 30584 30585 On most RISC machines, which only have operations that operate on a 30586 full register, define this macro to set M to 'word_mode' if M is an 30587 integer mode narrower than 'BITS_PER_WORD'. In most cases, only 30588 integer modes should be widened because wider-precision 30589 floating-point operations are usually more expensive than their 30590 narrower counterparts. 30591 30592 For most machines, the macro definition does not change UNSIGNEDP. 30593 However, some machines, have instructions that preferentially 30594 handle either signed or unsigned quantities of certain modes. For 30595 example, on the DEC Alpha, 32-bit loads from memory and 32-bit add 30596 instructions sign-extend the result to 64 bits. On such machines, 30597 set UNSIGNEDP according to which kind of extension is more 30598 efficient. 30599 30600 Do not define this macro if it would never modify M. 30601 30602 -- Target Hook: enum flt_eval_method TARGET_C_EXCESS_PRECISION (enum 30603 excess_precision_type TYPE) 30604 Return a value, with the same meaning as the C99 macro 30605 'FLT_EVAL_METHOD' that describes which excess precision should be 30606 applied. TYPE is either 'EXCESS_PRECISION_TYPE_IMPLICIT', 30607 'EXCESS_PRECISION_TYPE_FAST', or 'EXCESS_PRECISION_TYPE_STANDARD'. 30608 For 'EXCESS_PRECISION_TYPE_IMPLICIT', the target should return 30609 which precision and range operations will be implictly evaluated in 30610 regardless of the excess precision explicitly added. For 30611 'EXCESS_PRECISION_TYPE_STANDARD' and 'EXCESS_PRECISION_TYPE_FAST', 30612 the target should return the explicit excess precision that should 30613 be added depending on the value set for 30614 '-fexcess-precision=[standard|fast]'. Note that unpredictable 30615 explicit excess precision does not make sense, so a target should 30616 never return 'FLT_EVAL_METHOD_UNPREDICTABLE' when TYPE is 30617 'EXCESS_PRECISION_TYPE_STANDARD' or 'EXCESS_PRECISION_TYPE_FAST'. 30618 30619 -- Target Hook: machine_mode TARGET_PROMOTE_FUNCTION_MODE (const_tree 30620 TYPE, machine_mode MODE, int *PUNSIGNEDP, const_tree FUNTYPE, 30621 int FOR_RETURN) 30622 Like 'PROMOTE_MODE', but it is applied to outgoing function 30623 arguments or function return values. The target hook should return 30624 the new mode and possibly change '*PUNSIGNEDP' if the promotion 30625 should change signedness. This function is called only for scalar 30626 _or pointer_ types. 30627 30628 FOR_RETURN allows to distinguish the promotion of arguments and 30629 return values. If it is '1', a return value is being promoted and 30630 'TARGET_FUNCTION_VALUE' must perform the same promotions done here. 30631 If it is '2', the returned mode should be that of the register in 30632 which an incoming parameter is copied, or the outgoing result is 30633 computed; then the hook should return the same mode as 30634 'promote_mode', though the signedness may be different. 30635 30636 TYPE can be NULL when promoting function arguments of libcalls. 30637 30638 The default is to not promote arguments and return values. You can 30639 also define the hook to 30640 'default_promote_function_mode_always_promote' if you would like to 30641 apply the same rules given by 'PROMOTE_MODE'. 30642 30643 -- Macro: PARM_BOUNDARY 30644 Normal alignment required for function parameters on the stack, in 30645 bits. All stack parameters receive at least this much alignment 30646 regardless of data type. On most machines, this is the same as the 30647 size of an integer. 30648 30649 -- Macro: STACK_BOUNDARY 30650 Define this macro to the minimum alignment enforced by hardware for 30651 the stack pointer on this machine. The definition is a C 30652 expression for the desired alignment (measured in bits). This 30653 value is used as a default if 'PREFERRED_STACK_BOUNDARY' is not 30654 defined. On most machines, this should be the same as 30655 'PARM_BOUNDARY'. 30656 30657 -- Macro: PREFERRED_STACK_BOUNDARY 30658 Define this macro if you wish to preserve a certain alignment for 30659 the stack pointer, greater than what the hardware enforces. The 30660 definition is a C expression for the desired alignment (measured in 30661 bits). This macro must evaluate to a value equal to or larger than 30662 'STACK_BOUNDARY'. 30663 30664 -- Macro: INCOMING_STACK_BOUNDARY 30665 Define this macro if the incoming stack boundary may be different 30666 from 'PREFERRED_STACK_BOUNDARY'. This macro must evaluate to a 30667 value equal to or larger than 'STACK_BOUNDARY'. 30668 30669 -- Macro: FUNCTION_BOUNDARY 30670 Alignment required for a function entry point, in bits. 30671 30672 -- Macro: BIGGEST_ALIGNMENT 30673 Biggest alignment that any data type can require on this machine, 30674 in bits. Note that this is not the biggest alignment that is 30675 supported, just the biggest alignment that, when violated, may 30676 cause a fault. 30677 30678 -- Target Hook: HOST_WIDE_INT TARGET_ABSOLUTE_BIGGEST_ALIGNMENT 30679 If defined, this target hook specifies the absolute biggest 30680 alignment that a type or variable can have on this machine, 30681 otherwise, 'BIGGEST_ALIGNMENT' is used. 30682 30683 -- Macro: MALLOC_ABI_ALIGNMENT 30684 Alignment, in bits, a C conformant malloc implementation has to 30685 provide. If not defined, the default value is 'BITS_PER_WORD'. 30686 30687 -- Macro: ATTRIBUTE_ALIGNED_VALUE 30688 Alignment used by the '__attribute__ ((aligned))' construct. If 30689 not defined, the default value is 'BIGGEST_ALIGNMENT'. 30690 30691 -- Macro: MINIMUM_ATOMIC_ALIGNMENT 30692 If defined, the smallest alignment, in bits, that can be given to 30693 an object that can be referenced in one operation, without 30694 disturbing any nearby object. Normally, this is 'BITS_PER_UNIT', 30695 but may be larger on machines that don't have byte or half-word 30696 store operations. 30697 30698 -- Macro: BIGGEST_FIELD_ALIGNMENT 30699 Biggest alignment that any structure or union field can require on 30700 this machine, in bits. If defined, this overrides 30701 'BIGGEST_ALIGNMENT' for structure and union fields only, unless the 30702 field alignment has been set by the '__attribute__ ((aligned (N)))' 30703 construct. 30704 30705 -- Macro: ADJUST_FIELD_ALIGN (FIELD, TYPE, COMPUTED) 30706 An expression for the alignment of a structure field FIELD of type 30707 TYPE if the alignment computed in the usual way (including applying 30708 of 'BIGGEST_ALIGNMENT' and 'BIGGEST_FIELD_ALIGNMENT' to the 30709 alignment) is COMPUTED. It overrides alignment only if the field 30710 alignment has not been set by the '__attribute__ ((aligned (N)))' 30711 construct. Note that FIELD may be 'NULL_TREE' in case we just 30712 query for the minimum alignment of a field of type TYPE in 30713 structure context. 30714 30715 -- Macro: MAX_STACK_ALIGNMENT 30716 Biggest stack alignment guaranteed by the backend. Use this macro 30717 to specify the maximum alignment of a variable on stack. 30718 30719 If not defined, the default value is 'STACK_BOUNDARY'. 30720 30721 -- Macro: MAX_OFILE_ALIGNMENT 30722 Biggest alignment supported by the object file format of this 30723 machine. Use this macro to limit the alignment which can be 30724 specified using the '__attribute__ ((aligned (N)))' construct. If 30725 not defined, the default value is 'BIGGEST_ALIGNMENT'. 30726 30727 On systems that use ELF, the default (in 'config/elfos.h') is the 30728 largest supported 32-bit ELF section alignment representable on a 30729 32-bit host e.g. '(((uint64_t) 1 << 28) * 8)'. On 32-bit ELF the 30730 largest supported section alignment in bits is '(0x80000000 * 8)', 30731 but this is not representable on 32-bit hosts. 30732 30733 -- Target Hook: HOST_WIDE_INT TARGET_STATIC_RTX_ALIGNMENT (machine_mode 30734 MODE) 30735 This hook returns the preferred alignment in bits for a 30736 statically-allocated rtx, such as a constant pool entry. MODE is 30737 the mode of the rtx. The default implementation returns 30738 'GET_MODE_ALIGNMENT (MODE)'. 30739 30740 -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN) 30741 If defined, a C expression to compute the alignment for a variable 30742 in the static store. TYPE is the data type, and BASIC-ALIGN is the 30743 alignment that the object would ordinarily have. The value of this 30744 macro is used instead of that alignment to align the object. 30745 30746 If this macro is not defined, then BASIC-ALIGN is used. 30747 30748 One use of this macro is to increase alignment of medium-size data 30749 to make it all fit in fewer cache lines. Another is to cause 30750 character arrays to be word-aligned so that 'strcpy' calls that 30751 copy constants to character arrays can be done inline. 30752 30753 -- Macro: DATA_ABI_ALIGNMENT (TYPE, BASIC-ALIGN) 30754 Similar to 'DATA_ALIGNMENT', but for the cases where the ABI 30755 mandates some alignment increase, instead of optimization only 30756 purposes. E.g. AMD x86-64 psABI says that variables with array 30757 type larger than 15 bytes must be aligned to 16 byte boundaries. 30758 30759 If this macro is not defined, then BASIC-ALIGN is used. 30760 30761 -- Target Hook: HOST_WIDE_INT TARGET_CONSTANT_ALIGNMENT (const_tree 30762 CONSTANT, HOST_WIDE_INT BASIC_ALIGN) 30763 This hook returns the alignment in bits of a constant that is being 30764 placed in memory. CONSTANT is the constant and BASIC_ALIGN is the 30765 alignment that the object would ordinarily have. 30766 30767 The default definition just returns BASIC_ALIGN. 30768 30769 The typical use of this hook is to increase alignment for string 30770 constants to be word aligned so that 'strcpy' calls that copy 30771 constants can be done inline. The function 30772 'constant_alignment_word_strings' provides such a definition. 30773 30774 -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN) 30775 If defined, a C expression to compute the alignment for a variable 30776 in the local store. TYPE is the data type, and BASIC-ALIGN is the 30777 alignment that the object would ordinarily have. The value of this 30778 macro is used instead of that alignment to align the object. 30779 30780 If this macro is not defined, then BASIC-ALIGN is used. 30781 30782 One use of this macro is to increase alignment of medium-size data 30783 to make it all fit in fewer cache lines. 30784 30785 If the value of this macro has a type, it should be an unsigned 30786 type. 30787 30788 -- Target Hook: HOST_WIDE_INT TARGET_VECTOR_ALIGNMENT (const_tree TYPE) 30789 This hook can be used to define the alignment for a vector of type 30790 TYPE, in order to comply with a platform ABI. The default is to 30791 require natural alignment for vector types. The alignment returned 30792 by this hook must be a power-of-two multiple of the default 30793 alignment of the vector element type. 30794 30795 -- Macro: STACK_SLOT_ALIGNMENT (TYPE, MODE, BASIC-ALIGN) 30796 If defined, a C expression to compute the alignment for stack slot. 30797 TYPE is the data type, MODE is the widest mode available, and 30798 BASIC-ALIGN is the alignment that the slot would ordinarily have. 30799 The value of this macro is used instead of that alignment to align 30800 the slot. 30801 30802 If this macro is not defined, then BASIC-ALIGN is used when TYPE is 30803 'NULL'. Otherwise, 'LOCAL_ALIGNMENT' will be used. 30804 30805 This macro is to set alignment of stack slot to the maximum 30806 alignment of all possible modes which the slot may have. 30807 30808 If the value of this macro has a type, it should be an unsigned 30809 type. 30810 30811 -- Macro: LOCAL_DECL_ALIGNMENT (DECL) 30812 If defined, a C expression to compute the alignment for a local 30813 variable DECL. 30814 30815 If this macro is not defined, then 'LOCAL_ALIGNMENT (TREE_TYPE 30816 (DECL), DECL_ALIGN (DECL))' is used. 30817 30818 One use of this macro is to increase alignment of medium-size data 30819 to make it all fit in fewer cache lines. 30820 30821 If the value of this macro has a type, it should be an unsigned 30822 type. 30823 30824 -- Macro: MINIMUM_ALIGNMENT (EXP, MODE, ALIGN) 30825 If defined, a C expression to compute the minimum required 30826 alignment for dynamic stack realignment purposes for EXP (a type or 30827 decl), MODE, assuming normal alignment ALIGN. 30828 30829 If this macro is not defined, then ALIGN will be used. 30830 30831 -- Macro: EMPTY_FIELD_BOUNDARY 30832 Alignment in bits to be given to a structure bit-field that follows 30833 an empty field such as 'int : 0;'. 30834 30835 If 'PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro. 30836 30837 -- Macro: STRUCTURE_SIZE_BOUNDARY 30838 Number of bits which any structure or union's size must be a 30839 multiple of. Each structure or union's size is rounded up to a 30840 multiple of this. 30841 30842 If you do not define this macro, the default is the same as 30843 'BITS_PER_UNIT'. 30844 30845 -- Macro: STRICT_ALIGNMENT 30846 Define this macro to be the value 1 if instructions will fail to 30847 work if given data not on the nominal alignment. If instructions 30848 will merely go slower in that case, define this macro as 0. 30849 30850 -- Macro: PCC_BITFIELD_TYPE_MATTERS 30851 Define this if you wish to imitate the way many other C compilers 30852 handle alignment of bit-fields and the structures that contain 30853 them. 30854 30855 The behavior is that the type written for a named bit-field ('int', 30856 'short', or other integer type) imposes an alignment for the entire 30857 structure, as if the structure really did contain an ordinary field 30858 of that type. In addition, the bit-field is placed within the 30859 structure so that it would fit within such a field, not crossing a 30860 boundary for it. 30861 30862 Thus, on most machines, a named bit-field whose type is written as 30863 'int' would not cross a four-byte boundary, and would force 30864 four-byte alignment for the whole structure. (The alignment used 30865 may not be four bytes; it is controlled by the other alignment 30866 parameters.) 30867 30868 An unnamed bit-field will not affect the alignment of the 30869 containing structure. 30870 30871 If the macro is defined, its definition should be a C expression; a 30872 nonzero value for the expression enables this behavior. 30873 30874 Note that if this macro is not defined, or its value is zero, some 30875 bit-fields may cross more than one alignment boundary. The 30876 compiler can support such references if there are 'insv', 'extv', 30877 and 'extzv' insns that can directly reference memory. 30878 30879 The other known way of making bit-fields work is to define 30880 'STRUCTURE_SIZE_BOUNDARY' as large as 'BIGGEST_ALIGNMENT'. Then 30881 every structure can be accessed with fullwords. 30882 30883 Unless the machine has bit-field instructions or you define 30884 'STRUCTURE_SIZE_BOUNDARY' that way, you must define 30885 'PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value. 30886 30887 If your aim is to make GCC use the same conventions for laying out 30888 bit-fields as are used by another compiler, here is how to 30889 investigate what the other compiler does. Compile and run this 30890 program: 30891 30892 struct foo1 30893 { 30894 char x; 30895 char :0; 30896 char y; 30897 }; 30898 30899 struct foo2 30900 { 30901 char x; 30902 int :0; 30903 char y; 30904 }; 30905 30906 main () 30907 { 30908 printf ("Size of foo1 is %d\n", 30909 sizeof (struct foo1)); 30910 printf ("Size of foo2 is %d\n", 30911 sizeof (struct foo2)); 30912 exit (0); 30913 } 30914 30915 If this prints 2 and 5, then the compiler's behavior is what you 30916 would get from 'PCC_BITFIELD_TYPE_MATTERS'. 30917 30918 -- Macro: BITFIELD_NBYTES_LIMITED 30919 Like 'PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited 30920 to aligning a bit-field within the structure. 30921 30922 -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELD (void) 30923 When 'PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine 30924 whether unnamed bitfields affect the alignment of the containing 30925 structure. The hook should return true if the structure should 30926 inherit the alignment requirements of an unnamed bitfield's type. 30927 30928 -- Target Hook: bool TARGET_NARROW_VOLATILE_BITFIELD (void) 30929 This target hook should return 'true' if accesses to volatile 30930 bitfields should use the narrowest mode possible. It should return 30931 'false' if these accesses should use the bitfield container type. 30932 30933 The default is 'false'. 30934 30935 -- Target Hook: bool TARGET_MEMBER_TYPE_FORCES_BLK (const_tree FIELD, 30936 machine_mode MODE) 30937 Return true if a structure, union or array containing FIELD should 30938 be accessed using 'BLKMODE'. 30939 30940 If FIELD is the only field in the structure, MODE is its mode, 30941 otherwise MODE is VOIDmode. MODE is provided in the case where 30942 structures of one field would require the structure's mode to 30943 retain the field's mode. 30944 30945 Normally, this is not needed. 30946 30947 -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED) 30948 Define this macro as an expression for the alignment of a type 30949 (given by TYPE as a tree node) if the alignment computed in the 30950 usual way is COMPUTED and the alignment explicitly specified was 30951 SPECIFIED. 30952 30953 The default is to use SPECIFIED if it is larger; otherwise, use the 30954 smaller of COMPUTED and 'BIGGEST_ALIGNMENT' 30955 30956 -- Macro: MAX_FIXED_MODE_SIZE 30957 An integer expression for the size in bits of the largest integer 30958 machine mode that should actually be used. All integer machine 30959 modes of this size or smaller can be used for structures and unions 30960 with the appropriate sizes. If this macro is undefined, 30961 'GET_MODE_BITSIZE (DImode)' is assumed. 30962 30963 -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL) 30964 If defined, an expression of type 'machine_mode' that specifies the 30965 mode of the save area operand of a 'save_stack_LEVEL' named pattern 30966 (*note Standard Names::). SAVE_LEVEL is one of 'SAVE_BLOCK', 30967 'SAVE_FUNCTION', or 'SAVE_NONLOCAL' and selects which of the three 30968 named patterns is having its mode specified. 30969 30970 You need not define this macro if it always returns 'Pmode'. You 30971 would most commonly define this macro if the 'save_stack_LEVEL' 30972 patterns need to support both a 32- and a 64-bit mode. 30973 30974 -- Macro: STACK_SIZE_MODE 30975 If defined, an expression of type 'machine_mode' that specifies the 30976 mode of the size increment operand of an 'allocate_stack' named 30977 pattern (*note Standard Names::). 30978 30979 You need not define this macro if it always returns 'word_mode'. 30980 You would most commonly define this macro if the 'allocate_stack' 30981 pattern needs to support both a 32- and a 64-bit mode. 30982 30983 -- Target Hook: scalar_int_mode TARGET_LIBGCC_CMP_RETURN_MODE (void) 30984 This target hook should return the mode to be used for the return 30985 value of compare instructions expanded to libgcc calls. If not 30986 defined 'word_mode' is returned which is the right choice for a 30987 majority of targets. 30988 30989 -- Target Hook: scalar_int_mode TARGET_LIBGCC_SHIFT_COUNT_MODE (void) 30990 This target hook should return the mode to be used for the shift 30991 count operand of shift instructions expanded to libgcc calls. If 30992 not defined 'word_mode' is returned which is the right choice for a 30993 majority of targets. 30994 30995 -- Target Hook: scalar_int_mode TARGET_UNWIND_WORD_MODE (void) 30996 Return machine mode to be used for '_Unwind_Word' type. The 30997 default is to use 'word_mode'. 30998 30999 -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (const_tree 31000 RECORD_TYPE) 31001 This target hook returns 'true' if bit-fields in the given 31002 RECORD_TYPE are to be laid out following the rules of Microsoft 31003 Visual C/C++, namely: (i) a bit-field won't share the same storage 31004 unit with the previous bit-field if their underlying types have 31005 different sizes, and the bit-field will be aligned to the highest 31006 alignment of the underlying types of itself and of the previous 31007 bit-field; (ii) a zero-sized bit-field will affect the alignment of 31008 the whole enclosing structure, even if it is unnamed; except that 31009 (iii) a zero-sized bit-field will be disregarded unless it follows 31010 another bit-field of nonzero size. If this hook returns 'true', 31011 other macros that control bit-field layout are ignored. 31012 31013 When a bit-field is inserted into a packed record, the whole size 31014 of the underlying type is used by one or more same-size adjacent 31015 bit-fields (that is, if its long:3, 32 bits is used in the record, 31016 and any additional adjacent long bit-fields are packed into the 31017 same chunk of 32 bits. However, if the size changes, a new field 31018 of that size is allocated). In an unpacked record, this is the 31019 same as using alignment, but not equivalent when packing. 31020 31021 If both MS bit-fields and '__attribute__((packed))' are used, the 31022 latter will take precedence. If '__attribute__((packed))' is used 31023 on a single field when MS bit-fields are in use, it will take 31024 precedence for that field, but the alignment of the rest of the 31025 structure may affect its placement. 31026 31027 -- Target Hook: bool TARGET_DECIMAL_FLOAT_SUPPORTED_P (void) 31028 Returns true if the target supports decimal floating point. 31029 31030 -- Target Hook: bool TARGET_FIXED_POINT_SUPPORTED_P (void) 31031 Returns true if the target supports fixed-point arithmetic. 31032 31033 -- Target Hook: void TARGET_EXPAND_TO_RTL_HOOK (void) 31034 This hook is called just before expansion into rtl, allowing the 31035 target to perform additional initializations or analysis before the 31036 expansion. For example, the rs6000 port uses it to allocate a 31037 scratch stack slot for use in copying SDmode values between memory 31038 and floating point registers whenever the function being expanded 31039 has any SDmode usage. 31040 31041 -- Target Hook: void TARGET_INSTANTIATE_DECLS (void) 31042 This hook allows the backend to perform additional instantiations 31043 on rtl that are not actually in any insns yet, but will be later. 31044 31045 -- Target Hook: const char * TARGET_MANGLE_TYPE (const_tree TYPE) 31046 If your target defines any fundamental types, or any types your 31047 target uses should be mangled differently from the default, define 31048 this hook to return the appropriate encoding for these types as 31049 part of a C++ mangled name. The TYPE argument is the tree 31050 structure representing the type to be mangled. The hook may be 31051 applied to trees which are not target-specific fundamental types; 31052 it should return 'NULL' for all such types, as well as arguments it 31053 does not recognize. If the return value is not 'NULL', it must 31054 point to a statically-allocated string constant. 31055 31056 Target-specific fundamental types might be new fundamental types or 31057 qualified versions of ordinary fundamental types. Encode new 31058 fundamental types as 'u N NAME', where NAME is the name used for 31059 the type in source code, and N is the length of NAME in decimal. 31060 Encode qualified versions of ordinary types as 'U N NAME CODE', 31061 where NAME is the name used for the type qualifier in source code, 31062 N is the length of NAME as above, and CODE is the code used to 31063 represent the unqualified version of this type. (See 31064 'write_builtin_type' in 'cp/mangle.c' for the list of codes.) In 31065 both cases the spaces are for clarity; do not include any spaces in 31066 your string. 31067 31068 This hook is applied to types prior to typedef resolution. If the 31069 mangled name for a particular type depends only on that type's main 31070 variant, you can perform typedef resolution yourself using 31071 'TYPE_MAIN_VARIANT' before mangling. 31072 31073 The default version of this hook always returns 'NULL', which is 31074 appropriate for a target that does not define any new fundamental 31075 types. 31076 31077 31078File: gccint.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros 31079 3108018.6 Layout of Source Language Data Types 31081========================================= 31082 31083These macros define the sizes and other characteristics of the standard 31084basic data types used in programs being compiled. Unlike the macros in 31085the previous section, these apply to specific features of C and related 31086languages, rather than to fundamental aspects of storage layout. 31087 31088 -- Macro: INT_TYPE_SIZE 31089 A C expression for the size in bits of the type 'int' on the target 31090 machine. If you don't define this, the default is one word. 31091 31092 -- Macro: SHORT_TYPE_SIZE 31093 A C expression for the size in bits of the type 'short' on the 31094 target machine. If you don't define this, the default is half a 31095 word. (If this would be less than one storage unit, it is rounded 31096 up to one unit.) 31097 31098 -- Macro: LONG_TYPE_SIZE 31099 A C expression for the size in bits of the type 'long' on the 31100 target machine. If you don't define this, the default is one word. 31101 31102 -- Macro: ADA_LONG_TYPE_SIZE 31103 On some machines, the size used for the Ada equivalent of the type 31104 'long' by a native Ada compiler differs from that used by C. In 31105 that situation, define this macro to be a C expression to be used 31106 for the size of that type. If you don't define this, the default 31107 is the value of 'LONG_TYPE_SIZE'. 31108 31109 -- Macro: LONG_LONG_TYPE_SIZE 31110 A C expression for the size in bits of the type 'long long' on the 31111 target machine. If you don't define this, the default is two 31112 words. If you want to support GNU Ada on your machine, the value 31113 of this macro must be at least 64. 31114 31115 -- Macro: CHAR_TYPE_SIZE 31116 A C expression for the size in bits of the type 'char' on the 31117 target machine. If you don't define this, the default is 31118 'BITS_PER_UNIT'. 31119 31120 -- Macro: BOOL_TYPE_SIZE 31121 A C expression for the size in bits of the C++ type 'bool' and C99 31122 type '_Bool' on the target machine. If you don't define this, and 31123 you probably shouldn't, the default is 'CHAR_TYPE_SIZE'. 31124 31125 -- Macro: FLOAT_TYPE_SIZE 31126 A C expression for the size in bits of the type 'float' on the 31127 target machine. If you don't define this, the default is one word. 31128 31129 -- Macro: DOUBLE_TYPE_SIZE 31130 A C expression for the size in bits of the type 'double' on the 31131 target machine. If you don't define this, the default is two 31132 words. 31133 31134 -- Macro: LONG_DOUBLE_TYPE_SIZE 31135 A C expression for the size in bits of the type 'long double' on 31136 the target machine. If you don't define this, the default is two 31137 words. 31138 31139 -- Macro: SHORT_FRACT_TYPE_SIZE 31140 A C expression for the size in bits of the type 'short _Fract' on 31141 the target machine. If you don't define this, the default is 31142 'BITS_PER_UNIT'. 31143 31144 -- Macro: FRACT_TYPE_SIZE 31145 A C expression for the size in bits of the type '_Fract' on the 31146 target machine. If you don't define this, the default is 31147 'BITS_PER_UNIT * 2'. 31148 31149 -- Macro: LONG_FRACT_TYPE_SIZE 31150 A C expression for the size in bits of the type 'long _Fract' on 31151 the target machine. If you don't define this, the default is 31152 'BITS_PER_UNIT * 4'. 31153 31154 -- Macro: LONG_LONG_FRACT_TYPE_SIZE 31155 A C expression for the size in bits of the type 'long long _Fract' 31156 on the target machine. If you don't define this, the default is 31157 'BITS_PER_UNIT * 8'. 31158 31159 -- Macro: SHORT_ACCUM_TYPE_SIZE 31160 A C expression for the size in bits of the type 'short _Accum' on 31161 the target machine. If you don't define this, the default is 31162 'BITS_PER_UNIT * 2'. 31163 31164 -- Macro: ACCUM_TYPE_SIZE 31165 A C expression for the size in bits of the type '_Accum' on the 31166 target machine. If you don't define this, the default is 31167 'BITS_PER_UNIT * 4'. 31168 31169 -- Macro: LONG_ACCUM_TYPE_SIZE 31170 A C expression for the size in bits of the type 'long _Accum' on 31171 the target machine. If you don't define this, the default is 31172 'BITS_PER_UNIT * 8'. 31173 31174 -- Macro: LONG_LONG_ACCUM_TYPE_SIZE 31175 A C expression for the size in bits of the type 'long long _Accum' 31176 on the target machine. If you don't define this, the default is 31177 'BITS_PER_UNIT * 16'. 31178 31179 -- Macro: LIBGCC2_GNU_PREFIX 31180 This macro corresponds to the 'TARGET_LIBFUNC_GNU_PREFIX' target 31181 hook and should be defined if that hook is overriden to be true. 31182 It causes function names in libgcc to be changed to use a '__gnu_' 31183 prefix for their name rather than the default '__'. A port which 31184 uses this macro should also arrange to use 't-gnu-prefix' in the 31185 libgcc 'config.host'. 31186 31187 -- Macro: WIDEST_HARDWARE_FP_SIZE 31188 A C expression for the size in bits of the widest floating-point 31189 format supported by the hardware. If you define this macro, you 31190 must specify a value less than or equal to the value of 31191 'LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the 31192 value of 'LONG_DOUBLE_TYPE_SIZE' is the default. 31193 31194 -- Macro: DEFAULT_SIGNED_CHAR 31195 An expression whose value is 1 or 0, according to whether the type 31196 'char' should be signed or unsigned by default. The user can 31197 always override this default with the options '-fsigned-char' and 31198 '-funsigned-char'. 31199 31200 -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void) 31201 This target hook should return true if the compiler should give an 31202 'enum' type only as many bytes as it takes to represent the range 31203 of possible values of that type. It should return false if all 31204 'enum' types should be allocated like 'int'. 31205 31206 The default is to return false. 31207 31208 -- Macro: SIZE_TYPE 31209 A C expression for a string describing the name of the data type to 31210 use for size values. The typedef name 'size_t' is defined using 31211 the contents of the string. 31212 31213 The string can contain more than one keyword. If so, separate them 31214 with spaces, and write first any length keyword, then 'unsigned' if 31215 appropriate, and finally 'int'. The string must exactly match one 31216 of the data type names defined in the function 31217 'c_common_nodes_and_builtins' in the file 'c-family/c-common.c'. 31218 You may not omit 'int' or change the order--that would cause the 31219 compiler to crash on startup. 31220 31221 If you don't define this macro, the default is '"long unsigned 31222 int"'. 31223 31224 -- Macro: SIZETYPE 31225 GCC defines internal types ('sizetype', 'ssizetype', 'bitsizetype' 31226 and 'sbitsizetype') for expressions dealing with size. This macro 31227 is a C expression for a string describing the name of the data type 31228 from which the precision of 'sizetype' is extracted. 31229 31230 The string has the same restrictions as 'SIZE_TYPE' string. 31231 31232 If you don't define this macro, the default is 'SIZE_TYPE'. 31233 31234 -- Macro: PTRDIFF_TYPE 31235 A C expression for a string describing the name of the data type to 31236 use for the result of subtracting two pointers. The typedef name 31237 'ptrdiff_t' is defined using the contents of the string. See 31238 'SIZE_TYPE' above for more information. 31239 31240 If you don't define this macro, the default is '"long int"'. 31241 31242 -- Macro: WCHAR_TYPE 31243 A C expression for a string describing the name of the data type to 31244 use for wide characters. The typedef name 'wchar_t' is defined 31245 using the contents of the string. See 'SIZE_TYPE' above for more 31246 information. 31247 31248 If you don't define this macro, the default is '"int"'. 31249 31250 -- Macro: WCHAR_TYPE_SIZE 31251 A C expression for the size in bits of the data type for wide 31252 characters. This is used in 'cpp', which cannot make use of 31253 'WCHAR_TYPE'. 31254 31255 -- Macro: WINT_TYPE 31256 A C expression for a string describing the name of the data type to 31257 use for wide characters passed to 'printf' and returned from 31258 'getwc'. The typedef name 'wint_t' is defined using the contents 31259 of the string. See 'SIZE_TYPE' above for more information. 31260 31261 If you don't define this macro, the default is '"unsigned int"'. 31262 31263 -- Macro: INTMAX_TYPE 31264 A C expression for a string describing the name of the data type 31265 that can represent any value of any standard or extended signed 31266 integer type. The typedef name 'intmax_t' is defined using the 31267 contents of the string. See 'SIZE_TYPE' above for more 31268 information. 31269 31270 If you don't define this macro, the default is the first of 31271 '"int"', '"long int"', or '"long long int"' that has as much 31272 precision as 'long long int'. 31273 31274 -- Macro: UINTMAX_TYPE 31275 A C expression for a string describing the name of the data type 31276 that can represent any value of any standard or extended unsigned 31277 integer type. The typedef name 'uintmax_t' is defined using the 31278 contents of the string. See 'SIZE_TYPE' above for more 31279 information. 31280 31281 If you don't define this macro, the default is the first of 31282 '"unsigned int"', '"long unsigned int"', or '"long long unsigned 31283 int"' that has as much precision as 'long long unsigned int'. 31284 31285 -- Macro: SIG_ATOMIC_TYPE 31286 -- Macro: INT8_TYPE 31287 -- Macro: INT16_TYPE 31288 -- Macro: INT32_TYPE 31289 -- Macro: INT64_TYPE 31290 -- Macro: UINT8_TYPE 31291 -- Macro: UINT16_TYPE 31292 -- Macro: UINT32_TYPE 31293 -- Macro: UINT64_TYPE 31294 -- Macro: INT_LEAST8_TYPE 31295 -- Macro: INT_LEAST16_TYPE 31296 -- Macro: INT_LEAST32_TYPE 31297 -- Macro: INT_LEAST64_TYPE 31298 -- Macro: UINT_LEAST8_TYPE 31299 -- Macro: UINT_LEAST16_TYPE 31300 -- Macro: UINT_LEAST32_TYPE 31301 -- Macro: UINT_LEAST64_TYPE 31302 -- Macro: INT_FAST8_TYPE 31303 -- Macro: INT_FAST16_TYPE 31304 -- Macro: INT_FAST32_TYPE 31305 -- Macro: INT_FAST64_TYPE 31306 -- Macro: UINT_FAST8_TYPE 31307 -- Macro: UINT_FAST16_TYPE 31308 -- Macro: UINT_FAST32_TYPE 31309 -- Macro: UINT_FAST64_TYPE 31310 -- Macro: INTPTR_TYPE 31311 -- Macro: UINTPTR_TYPE 31312 C expressions for the standard types 'sig_atomic_t', 'int8_t', 31313 'int16_t', 'int32_t', 'int64_t', 'uint8_t', 'uint16_t', 'uint32_t', 31314 'uint64_t', 'int_least8_t', 'int_least16_t', 'int_least32_t', 31315 'int_least64_t', 'uint_least8_t', 'uint_least16_t', 31316 'uint_least32_t', 'uint_least64_t', 'int_fast8_t', 'int_fast16_t', 31317 'int_fast32_t', 'int_fast64_t', 'uint_fast8_t', 'uint_fast16_t', 31318 'uint_fast32_t', 'uint_fast64_t', 'intptr_t', and 'uintptr_t'. See 31319 'SIZE_TYPE' above for more information. 31320 31321 If any of these macros evaluates to a null pointer, the 31322 corresponding type is not supported; if GCC is configured to 31323 provide '<stdint.h>' in such a case, the header provided may not 31324 conform to C99, depending on the type in question. The defaults 31325 for all of these macros are null pointers. 31326 31327 -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION 31328 The C++ compiler represents a pointer-to-member-function with a 31329 struct that looks like: 31330 31331 struct { 31332 union { 31333 void (*fn)(); 31334 ptrdiff_t vtable_index; 31335 }; 31336 ptrdiff_t delta; 31337 }; 31338 31339 The C++ compiler must use one bit to indicate whether the function 31340 that will be called through a pointer-to-member-function is 31341 virtual. Normally, we assume that the low-order bit of a function 31342 pointer must always be zero. Then, by ensuring that the 31343 vtable_index is odd, we can distinguish which variant of the union 31344 is in use. But, on some platforms function pointers can be odd, 31345 and so this doesn't work. In that case, we use the low-order bit 31346 of the 'delta' field, and shift the remainder of the 'delta' field 31347 to the left. 31348 31349 GCC will automatically make the right selection about where to 31350 store this bit using the 'FUNCTION_BOUNDARY' setting for your 31351 platform. However, some platforms such as ARM/Thumb have 31352 'FUNCTION_BOUNDARY' set such that functions always start at even 31353 addresses, but the lowest bit of pointers to functions indicate 31354 whether the function at that address is in ARM or Thumb mode. If 31355 this is the case of your architecture, you should define this macro 31356 to 'ptrmemfunc_vbit_in_delta'. 31357 31358 In general, you should not have to define this macro. On 31359 architectures in which function addresses are always even, 31360 according to 'FUNCTION_BOUNDARY', GCC will automatically define 31361 this macro to 'ptrmemfunc_vbit_in_pfn'. 31362 31363 -- Macro: TARGET_VTABLE_USES_DESCRIPTORS 31364 Normally, the C++ compiler uses function pointers in vtables. This 31365 macro allows the target to change to use "function descriptors" 31366 instead. Function descriptors are found on targets for whom a 31367 function pointer is actually a small data structure. Normally the 31368 data structure consists of the actual code address plus a data 31369 pointer to which the function's data is relative. 31370 31371 If vtables are used, the value of this macro should be the number 31372 of words that the function descriptor occupies. 31373 31374 -- Macro: TARGET_VTABLE_ENTRY_ALIGN 31375 By default, the vtable entries are void pointers, the so the 31376 alignment is the same as pointer alignment. The value of this 31377 macro specifies the alignment of the vtable entry in bits. It 31378 should be defined only when special alignment is necessary. */ 31379 31380 -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE 31381 There are a few non-descriptor entries in the vtable at offsets 31382 below zero. If these entries must be padded (say, to preserve the 31383 alignment specified by 'TARGET_VTABLE_ENTRY_ALIGN'), set this to 31384 the number of words in each data entry. 31385 31386 31387File: gccint.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros 31388 3138918.7 Register Usage 31390=================== 31391 31392This section explains how to describe what registers the target machine 31393has, and how (in general) they can be used. 31394 31395 The description of which registers a specific instruction can use is 31396done with register classes; see *note Register Classes::. For 31397information on using registers to access a stack frame, see *note Frame 31398Registers::. For passing values in registers, see *note Register 31399Arguments::. For returning values in registers, see *note Scalar 31400Return::. 31401 31402* Menu: 31403 31404* Register Basics:: Number and kinds of registers. 31405* Allocation Order:: Order in which registers are allocated. 31406* Values in Registers:: What kinds of values each reg can hold. 31407* Leaf Functions:: Renumbering registers for leaf functions. 31408* Stack Registers:: Handling a register stack such as 80387. 31409 31410 31411File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers 31412 3141318.7.1 Basic Characteristics of Registers 31414----------------------------------------- 31415 31416Registers have various characteristics. 31417 31418 -- Macro: FIRST_PSEUDO_REGISTER 31419 Number of hardware registers known to the compiler. They receive 31420 numbers 0 through 'FIRST_PSEUDO_REGISTER-1'; thus, the first pseudo 31421 register's number really is assigned the number 31422 'FIRST_PSEUDO_REGISTER'. 31423 31424 -- Macro: FIXED_REGISTERS 31425 An initializer that says which registers are used for fixed 31426 purposes all throughout the compiled code and are therefore not 31427 available for general allocation. These would include the stack 31428 pointer, the frame pointer (except on machines where that can be 31429 used as a general register when no frame pointer is needed), the 31430 program counter on machines where that is considered one of the 31431 addressable registers, and any other numbered register with a 31432 standard use. 31433 31434 This information is expressed as a sequence of numbers, separated 31435 by commas and surrounded by braces. The Nth number is 1 if 31436 register N is fixed, 0 otherwise. 31437 31438 The table initialized from this macro, and the table initialized by 31439 the following one, may be overridden at run time either 31440 automatically, by the actions of the macro 31441 'CONDITIONAL_REGISTER_USAGE', or by the user with the command 31442 options '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG'. 31443 31444 -- Macro: CALL_USED_REGISTERS 31445 Like 'FIXED_REGISTERS' but has 1 for each register that is 31446 clobbered (in general) by function calls as well as for fixed 31447 registers. This macro therefore identifies the registers that are 31448 not available for general allocation of values that must live 31449 across function calls. 31450 31451 If a register has 0 in 'CALL_USED_REGISTERS', the compiler 31452 automatically saves it on function entry and restores it on 31453 function exit, if the register is used within the function. 31454 31455 -- Macro: CALL_REALLY_USED_REGISTERS 31456 Like 'CALL_USED_REGISTERS' except this macro doesn't require that 31457 the entire set of 'FIXED_REGISTERS' be included. 31458 ('CALL_USED_REGISTERS' must be a superset of 'FIXED_REGISTERS'). 31459 This macro is optional. If not specified, it defaults to the value 31460 of 'CALL_USED_REGISTERS'. 31461 31462 -- Target Hook: bool TARGET_HARD_REGNO_CALL_PART_CLOBBERED (unsigned 31463 int REGNO, machine_mode MODE) 31464 This hook should return true if REGNO is partly call-saved and 31465 partly call-clobbered, and if a value of mode MODE would be partly 31466 clobbered by a call. For example, if the low 32 bits of REGNO are 31467 preserved across a call but higher bits are clobbered, this hook 31468 should return true for a 64-bit mode but false for a 32-bit mode. 31469 31470 The default implementation returns false, which is correct for 31471 targets that don't have partly call-clobbered registers. 31472 31473 -- Target Hook: void TARGET_CONDITIONAL_REGISTER_USAGE (void) 31474 This hook may conditionally modify five variables 'fixed_regs', 31475 'call_used_regs', 'global_regs', 'reg_names', and 31476 'reg_class_contents', to take into account any dependence of these 31477 register sets on target flags. The first three of these are of 31478 type 'char []' (interpreted as boolean vectors). 'global_regs' is 31479 a 'const char *[]', and 'reg_class_contents' is a 'HARD_REG_SET'. 31480 Before the macro is called, 'fixed_regs', 'call_used_regs', 31481 'reg_class_contents', and 'reg_names' have been initialized from 31482 'FIXED_REGISTERS', 'CALL_USED_REGISTERS', 'REG_CLASS_CONTENTS', and 31483 'REGISTER_NAMES', respectively. 'global_regs' has been cleared, 31484 and any '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG' 31485 command options have been applied. 31486 31487 If the usage of an entire class of registers depends on the target 31488 flags, you may indicate this to GCC by using this macro to modify 31489 'fixed_regs' and 'call_used_regs' to 1 for each of the registers in 31490 the classes which should not be used by GCC. Also make 31491 'define_register_constraint's return 'NO_REGS' for constraints that 31492 shouldn't be used. 31493 31494 (However, if this class is not included in 'GENERAL_REGS' and all 31495 of the insn patterns whose constraints permit this class are 31496 controlled by target switches, then GCC will automatically avoid 31497 using these registers when the target switches are opposed to 31498 them.) 31499 31500 -- Macro: INCOMING_REGNO (OUT) 31501 Define this macro if the target machine has register windows. This 31502 C expression returns the register number as seen by the called 31503 function corresponding to the register number OUT as seen by the 31504 calling function. Return OUT if register number OUT is not an 31505 outbound register. 31506 31507 -- Macro: OUTGOING_REGNO (IN) 31508 Define this macro if the target machine has register windows. This 31509 C expression returns the register number as seen by the calling 31510 function corresponding to the register number IN as seen by the 31511 called function. Return IN if register number IN is not an inbound 31512 register. 31513 31514 -- Macro: LOCAL_REGNO (REGNO) 31515 Define this macro if the target machine has register windows. This 31516 C expression returns true if the register is call-saved but is in 31517 the register window. Unlike most call-saved registers, such 31518 registers need not be explicitly restored on function exit or 31519 during non-local gotos. 31520 31521 -- Macro: PC_REGNUM 31522 If the program counter has a register number, define this as that 31523 register number. Otherwise, do not define it. 31524 31525 31526File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers 31527 3152818.7.2 Order of Allocation of Registers 31529--------------------------------------- 31530 31531Registers are allocated in order. 31532 31533 -- Macro: REG_ALLOC_ORDER 31534 If defined, an initializer for a vector of integers, containing the 31535 numbers of hard registers in the order in which GCC should prefer 31536 to use them (from most preferred to least). 31537 31538 If this macro is not defined, registers are used lowest numbered 31539 first (all else being equal). 31540 31541 One use of this macro is on machines where the highest numbered 31542 registers must always be saved and the save-multiple-registers 31543 instruction supports only sequences of consecutive registers. On 31544 such machines, define 'REG_ALLOC_ORDER' to be an initializer that 31545 lists the highest numbered allocable register first. 31546 31547 -- Macro: ADJUST_REG_ALLOC_ORDER 31548 A C statement (sans semicolon) to choose the order in which to 31549 allocate hard registers for pseudo-registers local to a basic 31550 block. 31551 31552 Store the desired register order in the array 'reg_alloc_order'. 31553 Element 0 should be the register to allocate first; element 1, the 31554 next register; and so on. 31555 31556 The macro body should not assume anything about the contents of 31557 'reg_alloc_order' before execution of the macro. 31558 31559 On most machines, it is not necessary to define this macro. 31560 31561 -- Macro: HONOR_REG_ALLOC_ORDER 31562 Normally, IRA tries to estimate the costs for saving a register in 31563 the prologue and restoring it in the epilogue. This discourages it 31564 from using call-saved registers. If a machine wants to ensure that 31565 IRA allocates registers in the order given by REG_ALLOC_ORDER even 31566 if some call-saved registers appear earlier than call-used ones, 31567 then define this macro as a C expression to nonzero. Default is 0. 31568 31569 -- Macro: IRA_HARD_REGNO_ADD_COST_MULTIPLIER (REGNO) 31570 In some case register allocation order is not enough for the 31571 Integrated Register Allocator (IRA) to generate a good code. If 31572 this macro is defined, it should return a floating point value 31573 based on REGNO. The cost of using REGNO for a pseudo will be 31574 increased by approximately the pseudo's usage frequency times the 31575 value returned by this macro. Not defining this macro is 31576 equivalent to having it always return '0.0'. 31577 31578 On most machines, it is not necessary to define this macro. 31579 31580 31581File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers 31582 3158318.7.3 How Values Fit in Registers 31584---------------------------------- 31585 31586This section discusses the macros that describe which kinds of values 31587(specifically, which machine modes) each register can hold, and how many 31588consecutive registers are needed for a given mode. 31589 31590 -- Target Hook: unsigned int TARGET_HARD_REGNO_NREGS (unsigned int 31591 REGNO, machine_mode MODE) 31592 This hook returns the number of consecutive hard registers, 31593 starting at register number REGNO, required to hold a value of mode 31594 MODE. This hook must never return zero, even if a register cannot 31595 hold the requested mode - indicate that with 31596 'TARGET_HARD_REGNO_MODE_OK' and/or 'TARGET_CAN_CHANGE_MODE_CLASS' 31597 instead. 31598 31599 The default definition returns the number of words in MODE. 31600 31601 -- Macro: HARD_REGNO_NREGS_HAS_PADDING (REGNO, MODE) 31602 A C expression that is nonzero if a value of mode MODE, stored in 31603 memory, ends with padding that causes it to take up more space than 31604 in registers starting at register number REGNO (as determined by 31605 multiplying GCC's notion of the size of the register when 31606 containing this mode by the number of registers returned by 31607 'TARGET_HARD_REGNO_NREGS'). By default this is zero. 31608 31609 For example, if a floating-point value is stored in three 32-bit 31610 registers but takes up 128 bits in memory, then this would be 31611 nonzero. 31612 31613 This macros only needs to be defined if there are cases where 31614 'subreg_get_info' would otherwise wrongly determine that a 'subreg' 31615 can be represented by an offset to the register number, when in 31616 fact such a 'subreg' would contain some of the padding not stored 31617 in registers and so not be representable. 31618 31619 -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE) 31620 For values of REGNO and MODE for which 31621 'HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression 31622 returning the greater number of registers required to hold the 31623 value including any padding. In the example above, the value would 31624 be four. 31625 31626 -- Macro: REGMODE_NATURAL_SIZE (MODE) 31627 Define this macro if the natural size of registers that hold values 31628 of mode MODE is not the word size. It is a C expression that 31629 should give the natural size in bytes for the specified mode. It 31630 is used by the register allocator to try to optimize its results. 31631 This happens for example on SPARC 64-bit where the natural size of 31632 floating-point registers is still 32-bit. 31633 31634 -- Target Hook: bool TARGET_HARD_REGNO_MODE_OK (unsigned int REGNO, 31635 machine_mode MODE) 31636 This hook returns true if it is permissible to store a value of 31637 mode MODE in hard register number REGNO (or in several registers 31638 starting with that one). The default definition returns true 31639 unconditionally. 31640 31641 You need not include code to check for the numbers of fixed 31642 registers, because the allocation mechanism considers them to be 31643 always occupied. 31644 31645 On some machines, double-precision values must be kept in even/odd 31646 register pairs. You can implement that by defining this hook to 31647 reject odd register numbers for such modes. 31648 31649 The minimum requirement for a mode to be OK in a register is that 31650 the 'movMODE' instruction pattern support moves between the 31651 register and other hard register in the same class and that moving 31652 a value into the register and back out not alter it. 31653 31654 Since the same instruction used to move 'word_mode' will work for 31655 all narrower integer modes, it is not necessary on any machine for 31656 this hook to distinguish between these modes, provided you define 31657 patterns 'movhi', etc., to take advantage of this. This is useful 31658 because of the interaction between 'TARGET_HARD_REGNO_MODE_OK' and 31659 'TARGET_MODES_TIEABLE_P'; it is very desirable for all integer 31660 modes to be tieable. 31661 31662 Many machines have special registers for floating point arithmetic. 31663 Often people assume that floating point machine modes are allowed 31664 only in floating point registers. This is not true. Any registers 31665 that can hold integers can safely _hold_ a floating point machine 31666 mode, whether or not floating arithmetic can be done on it in those 31667 registers. Integer move instructions can be used to move the 31668 values. 31669 31670 On some machines, though, the converse is true: fixed-point machine 31671 modes may not go in floating registers. This is true if the 31672 floating registers normalize any value stored in them, because 31673 storing a non-floating value there would garble it. In this case, 31674 'TARGET_HARD_REGNO_MODE_OK' should reject fixed-point machine modes 31675 in floating registers. But if the floating registers do not 31676 automatically normalize, if you can store any bit pattern in one 31677 and retrieve it unchanged without a trap, then any machine mode may 31678 go in a floating register, so you can define this hook to say so. 31679 31680 The primary significance of special floating registers is rather 31681 that they are the registers acceptable in floating point arithmetic 31682 instructions. However, this is of no concern to 31683 'TARGET_HARD_REGNO_MODE_OK'. You handle it by writing the proper 31684 constraints for those instructions. 31685 31686 On some machines, the floating registers are especially slow to 31687 access, so that it is better to store a value in a stack frame than 31688 in such a register if floating point arithmetic is not being done. 31689 As long as the floating registers are not in class 'GENERAL_REGS', 31690 they will not be used unless some pattern's constraint asks for 31691 one. 31692 31693 -- Macro: HARD_REGNO_RENAME_OK (FROM, TO) 31694 A C expression that is nonzero if it is OK to rename a hard 31695 register FROM to another hard register TO. 31696 31697 One common use of this macro is to prevent renaming of a register 31698 to another register that is not saved by a prologue in an interrupt 31699 handler. 31700 31701 The default is always nonzero. 31702 31703 -- Target Hook: bool TARGET_MODES_TIEABLE_P (machine_mode MODE1, 31704 machine_mode MODE2) 31705 This hook returns true if a value of mode MODE1 is accessible in 31706 mode MODE2 without copying. 31707 31708 If 'TARGET_HARD_REGNO_MODE_OK (R, MODE1)' and 31709 'TARGET_HARD_REGNO_MODE_OK (R, MODE2)' are always the same for any 31710 R, then 'TARGET_MODES_TIEABLE_P (MODE1, MODE2)' should be true. If 31711 they differ for any R, you should define this hook to return false 31712 unless some other mechanism ensures the accessibility of the value 31713 in a narrower mode. 31714 31715 You should define this hook to return true in as many cases as 31716 possible since doing so will allow GCC to perform better register 31717 allocation. The default definition returns true unconditionally. 31718 31719 -- Target Hook: bool TARGET_HARD_REGNO_SCRATCH_OK (unsigned int REGNO) 31720 This target hook should return 'true' if it is OK to use a hard 31721 register REGNO as scratch reg in peephole2. 31722 31723 One common use of this macro is to prevent using of a register that 31724 is not saved by a prologue in an interrupt handler. 31725 31726 The default version of this hook always returns 'true'. 31727 31728 -- Macro: AVOID_CCMODE_COPIES 31729 Define this macro if the compiler should avoid copies to/from 31730 'CCmode' registers. You should only define this macro if support 31731 for copying to/from 'CCmode' is incomplete. 31732 31733 31734File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers 31735 3173618.7.4 Handling Leaf Functions 31737------------------------------ 31738 31739On some machines, a leaf function (i.e., one which makes no calls) can 31740run more efficiently if it does not make its own register window. Often 31741this means it is required to receive its arguments in the registers 31742where they are passed by the caller, instead of the registers where they 31743would normally arrive. 31744 31745 The special treatment for leaf functions generally applies only when 31746other conditions are met; for example, often they may use only those 31747registers for its own variables and temporaries. We use the term "leaf 31748function" to mean a function that is suitable for this special handling, 31749so that functions with no calls are not necessarily "leaf functions". 31750 31751 GCC assigns register numbers before it knows whether the function is 31752suitable for leaf function treatment. So it needs to renumber the 31753registers in order to output a leaf function. The following macros 31754accomplish this. 31755 31756 -- Macro: LEAF_REGISTERS 31757 Name of a char vector, indexed by hard register number, which 31758 contains 1 for a register that is allowable in a candidate for leaf 31759 function treatment. 31760 31761 If leaf function treatment involves renumbering the registers, then 31762 the registers marked here should be the ones before 31763 renumbering--those that GCC would ordinarily allocate. The 31764 registers which will actually be used in the assembler code, after 31765 renumbering, should not be marked with 1 in this vector. 31766 31767 Define this macro only if the target machine offers a way to 31768 optimize the treatment of leaf functions. 31769 31770 -- Macro: LEAF_REG_REMAP (REGNO) 31771 A C expression whose value is the register number to which REGNO 31772 should be renumbered, when a function is treated as a leaf 31773 function. 31774 31775 If REGNO is a register number which should not appear in a leaf 31776 function before renumbering, then the expression should yield -1, 31777 which will cause the compiler to abort. 31778 31779 Define this macro only if the target machine offers a way to 31780 optimize the treatment of leaf functions, and registers need to be 31781 renumbered to do this. 31782 31783 'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE' must 31784usually treat leaf functions specially. They can test the C variable 31785'current_function_is_leaf' which is nonzero for leaf functions. 31786'current_function_is_leaf' is set prior to local register allocation and 31787is valid for the remaining compiler passes. They can also test the C 31788variable 'current_function_uses_only_leaf_regs' which is nonzero for 31789leaf functions which only use leaf registers. 31790'current_function_uses_only_leaf_regs' is valid after all passes that 31791modify the instructions have been run and is only useful if 31792'LEAF_REGISTERS' is defined. 31793 31794 31795File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers 31796 3179718.7.5 Registers That Form a Stack 31798---------------------------------- 31799 31800There are special features to handle computers where some of the 31801"registers" form a stack. Stack registers are normally written by 31802pushing onto the stack, and are numbered relative to the top of the 31803stack. 31804 31805 Currently, GCC can only handle one group of stack-like registers, and 31806they must be consecutively numbered. Furthermore, the existing support 31807for stack-like registers is specific to the 80387 floating point 31808coprocessor. If you have a new architecture that uses stack-like 31809registers, you will need to do substantial work on 'reg-stack.c' and 31810write your machine description to cooperate with it, as well as defining 31811these macros. 31812 31813 -- Macro: STACK_REGS 31814 Define this if the machine has any stack-like registers. 31815 31816 -- Macro: STACK_REG_COVER_CLASS 31817 This is a cover class containing the stack registers. Define this 31818 if the machine has any stack-like registers. 31819 31820 -- Macro: FIRST_STACK_REG 31821 The number of the first stack-like register. This one is the top 31822 of the stack. 31823 31824 -- Macro: LAST_STACK_REG 31825 The number of the last stack-like register. This one is the bottom 31826 of the stack. 31827 31828 31829File: gccint.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros 31830 3183118.8 Register Classes 31832===================== 31833 31834On many machines, the numbered registers are not all equivalent. For 31835example, certain registers may not be allowed for indexed addressing; 31836certain registers may not be allowed in some instructions. These 31837machine restrictions are described to the compiler using "register 31838classes". 31839 31840 You define a number of register classes, giving each one a name and 31841saying which of the registers belong to it. Then you can specify 31842register classes that are allowed as operands to particular instruction 31843patterns. 31844 31845 In general, each register will belong to several classes. In fact, one 31846class must be named 'ALL_REGS' and contain all the registers. Another 31847class must be named 'NO_REGS' and contain no registers. Often the union 31848of two classes will be another class; however, this is not required. 31849 31850 One of the classes must be named 'GENERAL_REGS'. There is nothing 31851terribly special about the name, but the operand constraint letters 'r' 31852and 'g' specify this class. If 'GENERAL_REGS' is the same as 31853'ALL_REGS', just define it as a macro which expands to 'ALL_REGS'. 31854 31855 Order the classes so that if class X is contained in class Y then X has 31856a lower class number than Y. 31857 31858 The way classes other than 'GENERAL_REGS' are specified in operand 31859constraints is through machine-dependent operand constraint letters. 31860You can define such letters to correspond to various classes, then use 31861them in operand constraints. 31862 31863 You must define the narrowest register classes for allocatable 31864registers, so that each class either has no subclasses, or that for some 31865mode, the move cost between registers within the class is cheaper than 31866moving a register in the class to or from memory (*note Costs::). 31867 31868 You should define a class for the union of two classes whenever some 31869instruction allows both classes. For example, if an instruction allows 31870either a floating point (coprocessor) register or a general register for 31871a certain operand, you should define a class 'FLOAT_OR_GENERAL_REGS' 31872which includes both of them. Otherwise you will get suboptimal code, or 31873even internal compiler errors when reload cannot find a register in the 31874class computed via 'reg_class_subunion'. 31875 31876 You must also specify certain redundant information about the register 31877classes: for each class, which classes contain it and which ones are 31878contained in it; for each pair of classes, the largest class contained 31879in their union. 31880 31881 When a value occupying several consecutive registers is expected in a 31882certain class, all the registers used must belong to that class. 31883Therefore, register classes cannot be used to enforce a requirement for 31884a register pair to start with an even-numbered register. The way to 31885specify this requirement is with 'TARGET_HARD_REGNO_MODE_OK'. 31886 31887 Register classes used for input-operands of bitwise-and or shift 31888instructions have a special requirement: each such class must have, for 31889each fixed-point machine mode, a subclass whose registers can transfer 31890that mode to or from memory. For example, on some machines, the 31891operations for single-byte values ('QImode') are limited to certain 31892registers. When this is so, each register class that is used in a 31893bitwise-and or shift instruction must have a subclass consisting of 31894registers from which single-byte values can be loaded or stored. This 31895is so that 'PREFERRED_RELOAD_CLASS' can always have a possible value to 31896return. 31897 31898 -- Data type: enum reg_class 31899 An enumerated type that must be defined with all the register class 31900 names as enumerated values. 'NO_REGS' must be first. 'ALL_REGS' 31901 must be the last register class, followed by one more enumerated 31902 value, 'LIM_REG_CLASSES', which is not a register class but rather 31903 tells how many classes there are. 31904 31905 Each register class has a number, which is the value of casting the 31906 class name to type 'int'. The number serves as an index in many of 31907 the tables described below. 31908 31909 -- Macro: N_REG_CLASSES 31910 The number of distinct register classes, defined as follows: 31911 31912 #define N_REG_CLASSES (int) LIM_REG_CLASSES 31913 31914 -- Macro: REG_CLASS_NAMES 31915 An initializer containing the names of the register classes as C 31916 string constants. These names are used in writing some of the 31917 debugging dumps. 31918 31919 -- Macro: REG_CLASS_CONTENTS 31920 An initializer containing the contents of the register classes, as 31921 integers which are bit masks. The Nth integer specifies the 31922 contents of class N. The way the integer MASK is interpreted is 31923 that register R is in the class if 'MASK & (1 << R)' is 1. 31924 31925 When the machine has more than 32 registers, an integer does not 31926 suffice. Then the integers are replaced by sub-initializers, 31927 braced groupings containing several integers. Each sub-initializer 31928 must be suitable as an initializer for the type 'HARD_REG_SET' 31929 which is defined in 'hard-reg-set.h'. In this situation, the first 31930 integer in each sub-initializer corresponds to registers 0 through 31931 31, the second integer to registers 32 through 63, and so on. 31932 31933 -- Macro: REGNO_REG_CLASS (REGNO) 31934 A C expression whose value is a register class containing hard 31935 register REGNO. In general there is more than one such class; 31936 choose a class which is "minimal", meaning that no smaller class 31937 also contains the register. 31938 31939 -- Macro: BASE_REG_CLASS 31940 A macro whose definition is the name of the class to which a valid 31941 base register must belong. A base register is one used in an 31942 address which is the register value plus a displacement. 31943 31944 -- Macro: MODE_BASE_REG_CLASS (MODE) 31945 This is a variation of the 'BASE_REG_CLASS' macro which allows the 31946 selection of a base register in a mode dependent manner. If MODE 31947 is VOIDmode then it should return the same value as 31948 'BASE_REG_CLASS'. 31949 31950 -- Macro: MODE_BASE_REG_REG_CLASS (MODE) 31951 A C expression whose value is the register class to which a valid 31952 base register must belong in order to be used in a base plus index 31953 register address. You should define this macro if base plus index 31954 addresses have different requirements than other base register 31955 uses. 31956 31957 -- Macro: MODE_CODE_BASE_REG_CLASS (MODE, ADDRESS_SPACE, OUTER_CODE, 31958 INDEX_CODE) 31959 A C expression whose value is the register class to which a valid 31960 base register for a memory reference in mode MODE to address space 31961 ADDRESS_SPACE must belong. OUTER_CODE and INDEX_CODE define the 31962 context in which the base register occurs. OUTER_CODE is the code 31963 of the immediately enclosing expression ('MEM' for the top level of 31964 an address, 'ADDRESS' for something that occurs in an 31965 'address_operand'). INDEX_CODE is the code of the corresponding 31966 index expression if OUTER_CODE is 'PLUS'; 'SCRATCH' otherwise. 31967 31968 -- Macro: INDEX_REG_CLASS 31969 A macro whose definition is the name of the class to which a valid 31970 index register must belong. An index register is one used in an 31971 address where its value is either multiplied by a scale factor or 31972 added to another register (as well as added to a displacement). 31973 31974 -- Macro: REGNO_OK_FOR_BASE_P (NUM) 31975 A C expression which is nonzero if register number NUM is suitable 31976 for use as a base register in operand addresses. 31977 31978 -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE) 31979 A C expression that is just like 'REGNO_OK_FOR_BASE_P', except that 31980 that expression may examine the mode of the memory reference in 31981 MODE. You should define this macro if the mode of the memory 31982 reference affects whether a register may be used as a base 31983 register. If you define this macro, the compiler will use it 31984 instead of 'REGNO_OK_FOR_BASE_P'. The mode may be 'VOIDmode' for 31985 addresses that appear outside a 'MEM', i.e., as an 31986 'address_operand'. 31987 31988 -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE) 31989 A C expression which is nonzero if register number NUM is suitable 31990 for use as a base register in base plus index operand addresses, 31991 accessing memory in mode MODE. It may be either a suitable hard 31992 register or a pseudo register that has been allocated such a hard 31993 register. You should define this macro if base plus index 31994 addresses have different requirements than other base register 31995 uses. 31996 31997 Use of this macro is deprecated; please use the more general 31998 'REGNO_MODE_CODE_OK_FOR_BASE_P'. 31999 32000 -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, ADDRESS_SPACE, 32001 OUTER_CODE, INDEX_CODE) 32002 A C expression which is nonzero if register number NUM is suitable 32003 for use as a base register in operand addresses, accessing memory 32004 in mode MODE in address space ADDRESS_SPACE. This is similar to 32005 'REGNO_MODE_OK_FOR_BASE_P', except that that expression may examine 32006 the context in which the register appears in the memory reference. 32007 OUTER_CODE is the code of the immediately enclosing expression 32008 ('MEM' if at the top level of the address, 'ADDRESS' for something 32009 that occurs in an 'address_operand'). INDEX_CODE is the code of 32010 the corresponding index expression if OUTER_CODE is 'PLUS'; 32011 'SCRATCH' otherwise. The mode may be 'VOIDmode' for addresses that 32012 appear outside a 'MEM', i.e., as an 'address_operand'. 32013 32014 -- Macro: REGNO_OK_FOR_INDEX_P (NUM) 32015 A C expression which is nonzero if register number NUM is suitable 32016 for use as an index register in operand addresses. It may be 32017 either a suitable hard register or a pseudo register that has been 32018 allocated such a hard register. 32019 32020 The difference between an index register and a base register is 32021 that the index register may be scaled. If an address involves the 32022 sum of two registers, neither one of them scaled, then either one 32023 may be labeled the "base" and the other the "index"; but whichever 32024 labeling is used must fit the machine's constraints of which 32025 registers may serve in each capacity. The compiler will try both 32026 labelings, looking for one that is valid, and will reload one or 32027 both registers only if neither labeling works. 32028 32029 -- Target Hook: reg_class_t TARGET_PREFERRED_RENAME_CLASS (reg_class_t 32030 RCLASS) 32031 A target hook that places additional preference on the register 32032 class to use when it is necessary to rename a register in class 32033 RCLASS to another class, or perhaps NO_REGS, if no preferred 32034 register class is found or hook 'preferred_rename_class' is not 32035 implemented. Sometimes returning a more restrictive class makes 32036 better code. For example, on ARM, thumb-2 instructions using 32037 'LO_REGS' may be smaller than instructions using 'GENERIC_REGS'. 32038 By returning 'LO_REGS' from 'preferred_rename_class', code size can 32039 be reduced. 32040 32041 -- Target Hook: reg_class_t TARGET_PREFERRED_RELOAD_CLASS (rtx X, 32042 reg_class_t RCLASS) 32043 A target hook that places additional restrictions on the register 32044 class to use when it is necessary to copy value X into a register 32045 in class RCLASS. The value is a register class; perhaps RCLASS, or 32046 perhaps another, smaller class. 32047 32048 The default version of this hook always returns value of 'rclass' 32049 argument. 32050 32051 Sometimes returning a more restrictive class makes better code. 32052 For example, on the 68000, when X is an integer constant that is in 32053 range for a 'moveq' instruction, the value of this macro is always 32054 'DATA_REGS' as long as RCLASS includes the data registers. 32055 Requiring a data register guarantees that a 'moveq' will be used. 32056 32057 One case where 'TARGET_PREFERRED_RELOAD_CLASS' must not return 32058 RCLASS is if X is a legitimate constant which cannot be loaded into 32059 some register class. By returning 'NO_REGS' you can force X into a 32060 memory location. For example, rs6000 can load immediate values 32061 into general-purpose registers, but does not have an instruction 32062 for loading an immediate value into a floating-point register, so 32063 'TARGET_PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a 32064 floating-point constant. If the constant can't be loaded into any 32065 kind of register, code generation will be better if 32066 'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 32067 instead of using 'TARGET_PREFERRED_RELOAD_CLASS'. 32068 32069 If an insn has pseudos in it after register allocation, reload will 32070 go through the alternatives and call repeatedly 32071 'TARGET_PREFERRED_RELOAD_CLASS' to find the best one. Returning 32072 'NO_REGS', in this case, makes reload add a '!' in front of the 32073 constraint: the x86 back-end uses this feature to discourage usage 32074 of 387 registers when math is done in the SSE registers (and vice 32075 versa). 32076 32077 -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS) 32078 A C expression that places additional restrictions on the register 32079 class to use when it is necessary to copy value X into a register 32080 in class CLASS. The value is a register class; perhaps CLASS, or 32081 perhaps another, smaller class. On many machines, the following 32082 definition is safe: 32083 32084 #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS 32085 32086 Sometimes returning a more restrictive class makes better code. 32087 For example, on the 68000, when X is an integer constant that is in 32088 range for a 'moveq' instruction, the value of this macro is always 32089 'DATA_REGS' as long as CLASS includes the data registers. 32090 Requiring a data register guarantees that a 'moveq' will be used. 32091 32092 One case where 'PREFERRED_RELOAD_CLASS' must not return CLASS is if 32093 X is a legitimate constant which cannot be loaded into some 32094 register class. By returning 'NO_REGS' you can force X into a 32095 memory location. For example, rs6000 can load immediate values 32096 into general-purpose registers, but does not have an instruction 32097 for loading an immediate value into a floating-point register, so 32098 'PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a 32099 floating-point constant. If the constant cannot be loaded into any 32100 kind of register, code generation will be better if 32101 'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 32102 instead of using 'TARGET_PREFERRED_RELOAD_CLASS'. 32103 32104 If an insn has pseudos in it after register allocation, reload will 32105 go through the alternatives and call repeatedly 32106 'PREFERRED_RELOAD_CLASS' to find the best one. Returning 32107 'NO_REGS', in this case, makes reload add a '!' in front of the 32108 constraint: the x86 back-end uses this feature to discourage usage 32109 of 387 registers when math is done in the SSE registers (and vice 32110 versa). 32111 32112 -- Target Hook: reg_class_t TARGET_PREFERRED_OUTPUT_RELOAD_CLASS (rtx 32113 X, reg_class_t RCLASS) 32114 Like 'TARGET_PREFERRED_RELOAD_CLASS', but for output reloads 32115 instead of input reloads. 32116 32117 The default version of this hook always returns value of 'rclass' 32118 argument. 32119 32120 You can also use 'TARGET_PREFERRED_OUTPUT_RELOAD_CLASS' to 32121 discourage reload from using some alternatives, like 32122 'TARGET_PREFERRED_RELOAD_CLASS'. 32123 32124 -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS) 32125 A C expression that places additional restrictions on the register 32126 class to use when it is necessary to be able to hold a value of 32127 mode MODE in a reload register for which class CLASS would 32128 ordinarily be used. 32129 32130 Unlike 'PREFERRED_RELOAD_CLASS', this macro should be used when 32131 there are certain modes that simply cannot go in certain reload 32132 classes. 32133 32134 The value is a register class; perhaps CLASS, or perhaps another, 32135 smaller class. 32136 32137 Don't define this macro unless the target machine has limitations 32138 which require the macro to do something nontrivial. 32139 32140 -- Target Hook: reg_class_t TARGET_SECONDARY_RELOAD (bool IN_P, rtx X, 32141 reg_class_t RELOAD_CLASS, machine_mode RELOAD_MODE, 32142 secondary_reload_info *SRI) 32143 Many machines have some registers that cannot be copied directly to 32144 or from memory or even from other types of registers. An example 32145 is the 'MQ' register, which on most machines, can only be copied to 32146 or from general registers, but not memory. Below, we shall be 32147 using the term 'intermediate register' when a move operation cannot 32148 be performed directly, but has to be done by copying the source 32149 into the intermediate register first, and then copying the 32150 intermediate register to the destination. An intermediate register 32151 always has the same mode as source and destination. Since it holds 32152 the actual value being copied, reload might apply optimizations to 32153 re-use an intermediate register and eliding the copy from the 32154 source when it can determine that the intermediate register still 32155 holds the required value. 32156 32157 Another kind of secondary reload is required on some machines which 32158 allow copying all registers to and from memory, but require a 32159 scratch register for stores to some memory locations (e.g., those 32160 with symbolic address on the RT, and those with certain symbolic 32161 address on the SPARC when compiling PIC). Scratch registers need 32162 not have the same mode as the value being copied, and usually hold 32163 a different value than that being copied. Special patterns in the 32164 md file are needed to describe how the copy is performed with the 32165 help of the scratch register; these patterns also describe the 32166 number, register class(es) and mode(s) of the scratch register(s). 32167 32168 In some cases, both an intermediate and a scratch register are 32169 required. 32170 32171 For input reloads, this target hook is called with nonzero IN_P, 32172 and X is an rtx that needs to be copied to a register of class 32173 RELOAD_CLASS in RELOAD_MODE. For output reloads, this target hook 32174 is called with zero IN_P, and a register of class RELOAD_CLASS 32175 needs to be copied to rtx X in RELOAD_MODE. 32176 32177 If copying a register of RELOAD_CLASS from/to X requires an 32178 intermediate register, the hook 'secondary_reload' should return 32179 the register class required for this intermediate register. If no 32180 intermediate register is required, it should return NO_REGS. If 32181 more than one intermediate register is required, describe the one 32182 that is closest in the copy chain to the reload register. 32183 32184 If scratch registers are needed, you also have to describe how to 32185 perform the copy from/to the reload register to/from this closest 32186 intermediate register. Or if no intermediate register is required, 32187 but still a scratch register is needed, describe the copy from/to 32188 the reload register to/from the reload operand X. 32189 32190 You do this by setting 'sri->icode' to the instruction code of a 32191 pattern in the md file which performs the move. Operands 0 and 1 32192 are the output and input of this copy, respectively. Operands from 32193 operand 2 onward are for scratch operands. These scratch operands 32194 must have a mode, and a single-register-class output constraint. 32195 32196 When an intermediate register is used, the 'secondary_reload' hook 32197 will be called again to determine how to copy the intermediate 32198 register to/from the reload operand X, so your hook must also have 32199 code to handle the register class of the intermediate operand. 32200 32201 X might be a pseudo-register or a 'subreg' of a pseudo-register, 32202 which could either be in a hard register or in memory. Use 32203 'true_regnum' to find out; it will return -1 if the pseudo is in 32204 memory and the hard register number if it is in a register. 32205 32206 Scratch operands in memory (constraint '"=m"' / '"=&m"') are 32207 currently not supported. For the time being, you will have to 32208 continue to use 'TARGET_SECONDARY_MEMORY_NEEDED' for that purpose. 32209 32210 'copy_cost' also uses this target hook to find out how values are 32211 copied. If you want it to include some extra cost for the need to 32212 allocate (a) scratch register(s), set 'sri->extra_cost' to the 32213 additional cost. Or if two dependent moves are supposed to have a 32214 lower cost than the sum of the individual moves due to expected 32215 fortuitous scheduling and/or special forwarding logic, you can set 32216 'sri->extra_cost' to a negative amount. 32217 32218 -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X) 32219 -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X) 32220 -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X) 32221 These macros are obsolete, new ports should use the target hook 32222 'TARGET_SECONDARY_RELOAD' instead. 32223 32224 These are obsolete macros, replaced by the 32225 'TARGET_SECONDARY_RELOAD' target hook. Older ports still define 32226 these macros to indicate to the reload phase that it may need to 32227 allocate at least one register for a reload in addition to the 32228 register to contain the data. Specifically, if copying X to a 32229 register CLASS in MODE requires an intermediate register, you were 32230 supposed to define 'SECONDARY_INPUT_RELOAD_CLASS' to return the 32231 largest register class all of whose registers can be used as 32232 intermediate registers or scratch registers. 32233 32234 If copying a register CLASS in MODE to X requires an intermediate 32235 or scratch register, 'SECONDARY_OUTPUT_RELOAD_CLASS' was supposed 32236 to be defined be defined to return the largest register class 32237 required. If the requirements for input and output reloads were 32238 the same, the macro 'SECONDARY_RELOAD_CLASS' should have been used 32239 instead of defining both macros identically. 32240 32241 The values returned by these macros are often 'GENERAL_REGS'. 32242 Return 'NO_REGS' if no spare register is needed; i.e., if X can be 32243 directly copied to or from a register of CLASS in MODE without 32244 requiring a scratch register. Do not define this macro if it would 32245 always return 'NO_REGS'. 32246 32247 If a scratch register is required (either with or without an 32248 intermediate register), you were supposed to define patterns for 32249 'reload_inM' or 'reload_outM', as required (*note Standard Names::. 32250 These patterns, which were normally implemented with a 32251 'define_expand', should be similar to the 'movM' patterns, except 32252 that operand 2 is the scratch register. 32253 32254 These patterns need constraints for the reload register and scratch 32255 register that contain a single register class. If the original 32256 reload register (whose class is CLASS) can meet the constraint 32257 given in the pattern, the value returned by these macros is used 32258 for the class of the scratch register. Otherwise, two additional 32259 reload registers are required. Their classes are obtained from the 32260 constraints in the insn pattern. 32261 32262 X might be a pseudo-register or a 'subreg' of a pseudo-register, 32263 which could either be in a hard register or in memory. Use 32264 'true_regnum' to find out; it will return -1 if the pseudo is in 32265 memory and the hard register number if it is in a register. 32266 32267 These macros should not be used in the case where a particular 32268 class of registers can only be copied to memory and not to another 32269 class of registers. In that case, secondary reload registers are 32270 not needed and would not be helpful. Instead, a stack location 32271 must be used to perform the copy and the 'movM' pattern should use 32272 memory as an intermediate storage. This case often occurs between 32273 floating-point and general registers. 32274 32275 -- Target Hook: bool TARGET_SECONDARY_MEMORY_NEEDED (machine_mode MODE, 32276 reg_class_t CLASS1, reg_class_t CLASS2) 32277 Certain machines have the property that some registers cannot be 32278 copied to some other registers without using memory. Define this 32279 hook on those machines to return true if objects of mode M in 32280 registers of CLASS1 can only be copied to registers of class CLASS2 32281 by storing a register of CLASS1 into memory and loading that memory 32282 location into a register of CLASS2. The default definition returns 32283 false for all inputs. 32284 32285 -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE) 32286 Normally when 'TARGET_SECONDARY_MEMORY_NEEDED' is defined, the 32287 compiler allocates a stack slot for a memory location needed for 32288 register copies. If this macro is defined, the compiler instead 32289 uses the memory location defined by this macro. 32290 32291 Do not define this macro if you do not define 32292 'TARGET_SECONDARY_MEMORY_NEEDED'. 32293 32294 -- Target Hook: machine_mode TARGET_SECONDARY_MEMORY_NEEDED_MODE 32295 (machine_mode MODE) 32296 If 'TARGET_SECONDARY_MEMORY_NEEDED' tells the compiler to use 32297 memory when moving between two particular registers of mode MODE, 32298 this hook specifies the mode that the memory should have. 32299 32300 The default depends on 'TARGET_LRA_P'. Without LRA, the default is 32301 to use a word-sized mode for integral modes that are smaller than a 32302 a word. This is right thing to do on most machines because it 32303 ensures that all bits of the register are copied and prevents 32304 accesses to the registers in a narrower mode, which some machines 32305 prohibit for floating-point registers. 32306 32307 However, this default behavior is not correct on some machines, 32308 such as the DEC Alpha, that store short integers in floating-point 32309 registers differently than in integer registers. On those 32310 machines, the default widening will not work correctly and you must 32311 define this hook to suppress that widening in some cases. See the 32312 file 'alpha.c' for details. 32313 32314 With LRA, the default is to use MODE unmodified. 32315 32316 -- Target Hook: void TARGET_SELECT_EARLY_REMAT_MODES (sbitmap MODES) 32317 On some targets, certain modes cannot be held in registers around a 32318 standard ABI call and are relatively expensive to spill to the 32319 stack. The early rematerialization pass can help in such cases by 32320 aggressively recomputing values after calls, so that they don't 32321 need to be spilled. 32322 32323 This hook returns the set of such modes by setting the associated 32324 bits in MODES. The default implementation selects no modes, which 32325 has the effect of disabling the early rematerialization pass. 32326 32327 -- Target Hook: bool TARGET_CLASS_LIKELY_SPILLED_P (reg_class_t RCLASS) 32328 A target hook which returns 'true' if pseudos that have been 32329 assigned to registers of class RCLASS would likely be spilled 32330 because registers of RCLASS are needed for spill registers. 32331 32332 The default version of this target hook returns 'true' if RCLASS 32333 has exactly one register and 'false' otherwise. On most machines, 32334 this default should be used. For generally register-starved 32335 machines, such as i386, or machines with right register 32336 constraints, such as SH, this hook can be used to avoid excessive 32337 spilling. 32338 32339 This hook is also used by some of the global intra-procedural code 32340 transformations to throtle code motion, to avoid increasing 32341 register pressure. 32342 32343 -- Target Hook: unsigned char TARGET_CLASS_MAX_NREGS (reg_class_t 32344 RCLASS, machine_mode MODE) 32345 A target hook returns the maximum number of consecutive registers 32346 of class RCLASS needed to hold a value of mode MODE. 32347 32348 This is closely related to the macro 'TARGET_HARD_REGNO_NREGS'. In 32349 fact, the value returned by 'TARGET_CLASS_MAX_NREGS (RCLASS, MODE)' 32350 target hook should be the maximum value of 'TARGET_HARD_REGNO_NREGS 32351 (REGNO, MODE)' for all REGNO values in the class RCLASS. 32352 32353 This target hook helps control the handling of multiple-word values 32354 in the reload pass. 32355 32356 The default version of this target hook returns the size of MODE in 32357 words. 32358 32359 -- Macro: CLASS_MAX_NREGS (CLASS, MODE) 32360 A C expression for the maximum number of consecutive registers of 32361 class CLASS 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 of the macro 'CLASS_MAX_NREGS (CLASS, MODE)' should 32365 be the maximum value of 'TARGET_HARD_REGNO_NREGS (REGNO, MODE)' for 32366 all REGNO values in the class CLASS. 32367 32368 This macro helps control the handling of multiple-word values in 32369 the reload pass. 32370 32371 -- Target Hook: bool TARGET_CAN_CHANGE_MODE_CLASS (machine_mode FROM, 32372 machine_mode TO, reg_class_t RCLASS) 32373 This hook returns true if it is possible to bitcast values held in 32374 registers of class RCLASS from mode FROM to mode TO and if doing so 32375 preserves the low-order bits that are common to both modes. The 32376 result is only meaningful if RCLASS has registers that can hold 32377 both 'from' and 'to'. The default implementation returns true. 32378 32379 As an example of when such bitcasting is invalid, loading 32-bit 32380 integer or floating-point objects into floating-point registers on 32381 Alpha extends them to 64 bits. Therefore loading a 64-bit object 32382 and then storing it as a 32-bit object does not store the low-order 32383 32 bits, as would be the case for a normal register. Therefore, 32384 'alpha.h' defines 'TARGET_CAN_CHANGE_MODE_CLASS' to return: 32385 32386 (GET_MODE_SIZE (from) == GET_MODE_SIZE (to) 32387 || !reg_classes_intersect_p (FLOAT_REGS, rclass)) 32388 32389 Even if storing from a register in mode TO would be valid, if both 32390 FROM and 'raw_reg_mode' for RCLASS are wider than 'word_mode', then 32391 we must prevent TO narrowing the mode. This happens when the 32392 middle-end assumes that it can load or store pieces of an N-word 32393 pseudo, and that the pseudo will eventually be allocated to N 32394 'word_mode' hard registers. Failure to prevent this kind of mode 32395 change will result in the entire 'raw_reg_mode' being modified 32396 instead of the partial value that the middle-end intended. 32397 32398 -- Target Hook: reg_class_t TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS 32399 (int, REG_CLASS_T, REG_CLASS_T) 32400 A target hook which can change allocno class for given pseudo from 32401 allocno and best class calculated by IRA. 32402 32403 The default version of this target hook always returns given class. 32404 32405 -- Target Hook: bool TARGET_LRA_P (void) 32406 A target hook which returns true if we use LRA instead of reload 32407 pass. The default version of this target hook returns true. New 32408 ports should use LRA, and existing ports are encouraged to convert. 32409 32410 -- Target Hook: int TARGET_REGISTER_PRIORITY (int) 32411 A target hook which returns the register priority number to which 32412 the register HARD_REGNO belongs to. The bigger the number, the 32413 more preferable the hard register usage (when all other conditions 32414 are the same). This hook can be used to prefer some hard register 32415 over others in LRA. For example, some x86-64 register usage needs 32416 additional prefix which makes instructions longer. The hook can 32417 return lower priority number for such registers make them less 32418 favorable and as result making the generated code smaller. The 32419 default version of this target hook returns always zero. 32420 32421 -- Target Hook: bool TARGET_REGISTER_USAGE_LEVELING_P (void) 32422 A target hook which returns true if we need register usage 32423 leveling. That means if a few hard registers are equally good for 32424 the assignment, we choose the least used hard register. The 32425 register usage leveling may be profitable for some targets. Don't 32426 use the usage leveling for targets with conditional execution or 32427 targets with big register files as it hurts if-conversion and 32428 cross-jumping optimizations. The default version of this target 32429 hook returns always false. 32430 32431 -- Target Hook: bool TARGET_DIFFERENT_ADDR_DISPLACEMENT_P (void) 32432 A target hook which returns true if an address with the same 32433 structure can have different maximal legitimate displacement. For 32434 example, the displacement can depend on memory mode or on operand 32435 combinations in the insn. The default version of this target hook 32436 returns always false. 32437 32438 -- Target Hook: bool TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P (rtx SUBST) 32439 A target hook which returns 'true' if SUBST can't substitute safely 32440 pseudos with equivalent memory values during register allocation. 32441 The default version of this target hook returns 'false'. On most 32442 machines, this default should be used. For generally machines with 32443 non orthogonal register usage for addressing, such as SH, this hook 32444 can be used to avoid excessive spilling. 32445 32446 -- Target Hook: bool TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT (rtx 32447 *OFFSET1, rtx *OFFSET2, poly_int64 ORIG_OFFSET, machine_mode 32448 MODE) 32449 This hook tries to split address offset ORIG_OFFSET into two parts: 32450 one that should be added to the base address to create a local 32451 anchor point, and an additional offset that can be applied to the 32452 anchor to address a value of mode MODE. The idea is that the local 32453 anchor could be shared by other accesses to nearby locations. 32454 32455 The hook returns true if it succeeds, storing the offset of the 32456 anchor from the base in OFFSET1 and the offset of the final address 32457 from the anchor in OFFSET2. The default implementation returns 32458 false. 32459 32460 -- Target Hook: reg_class_t TARGET_SPILL_CLASS (reg_class_t, 32461 MACHINE_MODE) 32462 This hook defines a class of registers which could be used for 32463 spilling pseudos of the given mode and class, or 'NO_REGS' if only 32464 memory should be used. Not defining this hook is equivalent to 32465 returning 'NO_REGS' for all inputs. 32466 32467 -- Target Hook: bool TARGET_ADDITIONAL_ALLOCNO_CLASS_P (reg_class_t) 32468 This hook should return 'true' if given class of registers should 32469 be an allocno class in any way. Usually RA uses only one register 32470 class from all classes containing the same register set. In some 32471 complicated cases, you need to have two or more such classes as 32472 allocno ones for RA correct work. Not defining this hook is 32473 equivalent to returning 'false' for all inputs. 32474 32475 -- Target Hook: scalar_int_mode TARGET_CSTORE_MODE (enum insn_code 32476 ICODE) 32477 This hook defines the machine mode to use for the boolean result of 32478 conditional store patterns. The ICODE argument is the instruction 32479 code for the cstore being performed. Not definiting this hook is 32480 the same as accepting the mode encoded into operand 0 of the cstore 32481 expander patterns. 32482 32483 -- Target Hook: int TARGET_COMPUTE_PRESSURE_CLASSES (enum reg_class 32484 *PRESSURE_CLASSES) 32485 A target hook which lets a backend compute the set of pressure 32486 classes to be used by those optimization passes which take register 32487 pressure into account, as opposed to letting IRA compute them. It 32488 returns the number of register classes stored in the array 32489 PRESSURE_CLASSES. 32490 32491 32492File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros 32493 3249418.9 Stack Layout and Calling Conventions 32495========================================= 32496 32497This describes the stack layout and calling conventions. 32498 32499* Menu: 32500 32501* Frame Layout:: 32502* Exception Handling:: 32503* Stack Checking:: 32504* Frame Registers:: 32505* Elimination:: 32506* Stack Arguments:: 32507* Register Arguments:: 32508* Scalar Return:: 32509* Aggregate Return:: 32510* Caller Saves:: 32511* Function Entry:: 32512* Profiling:: 32513* Tail Calls:: 32514* Shrink-wrapping separate components:: 32515* Stack Smashing Protection:: 32516* Miscellaneous Register Hooks:: 32517 32518 32519File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling 32520 3252118.9.1 Basic Stack Layout 32522------------------------- 32523 32524Here is the basic stack layout. 32525 32526 -- Macro: STACK_GROWS_DOWNWARD 32527 Define this macro to be true if pushing a word onto the stack moves 32528 the stack pointer to a smaller address, and false otherwise. 32529 32530 -- Macro: STACK_PUSH_CODE 32531 This macro defines the operation used when something is pushed on 32532 the stack. In RTL, a push operation will be '(set (mem 32533 (STACK_PUSH_CODE (reg sp))) ...)' 32534 32535 The choices are 'PRE_DEC', 'POST_DEC', 'PRE_INC', and 'POST_INC'. 32536 Which of these is correct depends on the stack direction and on 32537 whether the stack pointer points to the last item on the stack or 32538 whether it points to the space for the next item on the stack. 32539 32540 The default is 'PRE_DEC' when 'STACK_GROWS_DOWNWARD' is true, which 32541 is almost always right, and 'PRE_INC' otherwise, which is often 32542 wrong. 32543 32544 -- Macro: FRAME_GROWS_DOWNWARD 32545 Define this macro to nonzero value if the addresses of local 32546 variable slots are at negative offsets from the frame pointer. 32547 32548 -- Macro: ARGS_GROW_DOWNWARD 32549 Define this macro if successive arguments to a function occupy 32550 decreasing addresses on the stack. 32551 32552 -- Target Hook: HOST_WIDE_INT TARGET_STARTING_FRAME_OFFSET (void) 32553 This hook returns the offset from the frame pointer to the first 32554 local variable slot to be allocated. If 'FRAME_GROWS_DOWNWARD', it 32555 is the offset to _end_ of the first slot allocated, otherwise it is 32556 the offset to _beginning_ of the first slot allocated. The default 32557 implementation returns 0. 32558 32559 -- Macro: STACK_ALIGNMENT_NEEDED 32560 Define to zero to disable final alignment of the stack during 32561 reload. The nonzero default for this macro is suitable for most 32562 ports. 32563 32564 On ports where 'TARGET_STARTING_FRAME_OFFSET' is nonzero or where 32565 there is a register save block following the local block that 32566 doesn't require alignment to 'STACK_BOUNDARY', it may be beneficial 32567 to disable stack alignment and do it in the backend. 32568 32569 -- Macro: STACK_POINTER_OFFSET 32570 Offset from the stack pointer register to the first location at 32571 which outgoing arguments are placed. If not specified, the default 32572 value of zero is used. This is the proper value for most machines. 32573 32574 If 'ARGS_GROW_DOWNWARD', this is the offset to the location above 32575 the first location at which outgoing arguments are placed. 32576 32577 -- Macro: FIRST_PARM_OFFSET (FUNDECL) 32578 Offset from the argument pointer register to the first argument's 32579 address. On some machines it may depend on the data type of the 32580 function. 32581 32582 If 'ARGS_GROW_DOWNWARD', this is the offset to the location above 32583 the first argument's address. 32584 32585 -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL) 32586 Offset from the stack pointer register to an item dynamically 32587 allocated on the stack, e.g., by 'alloca'. 32588 32589 The default value for this macro is 'STACK_POINTER_OFFSET' plus the 32590 length of the outgoing arguments. The default is correct for most 32591 machines. See 'function.c' for details. 32592 32593 -- Macro: INITIAL_FRAME_ADDRESS_RTX 32594 A C expression whose value is RTL representing the address of the 32595 initial stack frame. This address is passed to 'RETURN_ADDR_RTX' 32596 and 'DYNAMIC_CHAIN_ADDRESS'. If you don't define this macro, a 32597 reasonable default value will be used. Define this macro in order 32598 to make frame pointer elimination work in the presence of 32599 '__builtin_frame_address (count)' and '__builtin_return_address 32600 (count)' for 'count' not equal to zero. 32601 32602 -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR) 32603 A C expression whose value is RTL representing the address in a 32604 stack frame where the pointer to the caller's frame is stored. 32605 Assume that FRAMEADDR is an RTL expression for the address of the 32606 stack frame itself. 32607 32608 If you don't define this macro, the default is to return the value 32609 of FRAMEADDR--that is, the stack frame address is also the address 32610 of the stack word that points to the previous frame. 32611 32612 -- Macro: SETUP_FRAME_ADDRESSES 32613 A C expression that produces the machine-specific code to setup the 32614 stack so that arbitrary frames can be accessed. For example, on 32615 the SPARC, we must flush all of the register windows to the stack 32616 before we can access arbitrary stack frames. You will seldom need 32617 to define this macro. The default is to do nothing. 32618 32619 -- Target Hook: rtx TARGET_BUILTIN_SETJMP_FRAME_VALUE (void) 32620 This target hook should return an rtx that is used to store the 32621 address of the current frame into the built in 'setjmp' buffer. 32622 The default value, 'virtual_stack_vars_rtx', is correct for most 32623 machines. One reason you may need to define this target hook is if 32624 'hard_frame_pointer_rtx' is the appropriate value on your machine. 32625 32626 -- Macro: FRAME_ADDR_RTX (FRAMEADDR) 32627 A C expression whose value is RTL representing the value of the 32628 frame address for the current frame. FRAMEADDR is the frame 32629 pointer of the current frame. This is used for 32630 __builtin_frame_address. You need only define this macro if the 32631 frame address is not the same as the frame pointer. Most machines 32632 do not need to define it. 32633 32634 -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR) 32635 A C expression whose value is RTL representing the value of the 32636 return address for the frame COUNT steps up from the current frame, 32637 after the prologue. FRAMEADDR is the frame pointer of the COUNT 32638 frame, or the frame pointer of the COUNT - 1 frame if 32639 'RETURN_ADDR_IN_PREVIOUS_FRAME' is nonzero. 32640 32641 The value of the expression must always be the correct address when 32642 COUNT is zero, but may be 'NULL_RTX' if there is no way to 32643 determine the return address of other frames. 32644 32645 -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME 32646 Define this macro to nonzero value if the return address of a 32647 particular stack frame is accessed from the frame pointer of the 32648 previous stack frame. The zero default for this macro is suitable 32649 for most ports. 32650 32651 -- Macro: INCOMING_RETURN_ADDR_RTX 32652 A C expression whose value is RTL representing the location of the 32653 incoming return address at the beginning of any function, before 32654 the prologue. This RTL is either a 'REG', indicating that the 32655 return value is saved in 'REG', or a 'MEM' representing a location 32656 in the stack. 32657 32658 You only need to define this macro if you want to support call 32659 frame debugging information like that provided by DWARF 2. 32660 32661 If this RTL is a 'REG', you should also define 32662 'DWARF_FRAME_RETURN_COLUMN' to 'DWARF_FRAME_REGNUM (REGNO)'. 32663 32664 -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN 32665 A C expression whose value is an integer giving a DWARF 2 column 32666 number that may be used as an alternative return column. The 32667 column must not correspond to any gcc hard register (that is, it 32668 must not be in the range of 'DWARF_FRAME_REGNUM'). 32669 32670 This macro can be useful if 'DWARF_FRAME_RETURN_COLUMN' is set to a 32671 general register, but an alternative column needs to be used for 32672 signal frames. Some targets have also used different frame return 32673 columns over time. 32674 32675 -- Macro: DWARF_ZERO_REG 32676 A C expression whose value is an integer giving a DWARF 2 register 32677 number that is considered to always have the value zero. This 32678 should only be defined if the target has an architected zero 32679 register, and someone decided it was a good idea to use that 32680 register number to terminate the stack backtrace. New ports should 32681 avoid this. 32682 32683 -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char 32684 *LABEL, rtx PATTERN, int INDEX) 32685 This target hook allows the backend to emit frame-related insns 32686 that contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame 32687 debugging info engine will invoke it on insns of the form 32688 (set (reg) (unspec [...] UNSPEC_INDEX)) 32689 and 32690 (set (reg) (unspec_volatile [...] UNSPECV_INDEX)). 32691 to let the backend emit the call frame instructions. LABEL is the 32692 CFI label attached to the insn, PATTERN is the pattern of the insn 32693 and INDEX is 'UNSPEC_INDEX' or 'UNSPECV_INDEX'. 32694 32695 -- Target Hook: unsigned int TARGET_DWARF_POLY_INDETERMINATE_VALUE 32696 (unsigned int I, unsigned int *FACTOR, int *OFFSET) 32697 Express the value of 'poly_int' indeterminate I as a DWARF 32698 expression, with I counting from 1. Return the number of a DWARF 32699 register R and set '*FACTOR' and '*OFFSET' such that the value of 32700 the indeterminate is: 32701 value_of(R) / FACTOR - OFFSET 32702 32703 A target only needs to define this hook if it sets 32704 'NUM_POLY_INT_COEFFS' to a value greater than 1. 32705 32706 -- Macro: INCOMING_FRAME_SP_OFFSET 32707 A C expression whose value is an integer giving the offset, in 32708 bytes, from the value of the stack pointer register to the top of 32709 the stack frame at the beginning of any function, before the 32710 prologue. The top of the frame is defined to be the value of the 32711 stack pointer in the previous frame, just before the call 32712 instruction. 32713 32714 You only need to define this macro if you want to support call 32715 frame debugging information like that provided by DWARF 2. 32716 32717 -- Macro: DEFAULT_INCOMING_FRAME_SP_OFFSET 32718 Like 'INCOMING_FRAME_SP_OFFSET', but must be the same for all 32719 functions of the same ABI, and when using GAS '.cfi_*' directives 32720 must also agree with the default CFI GAS emits. Define this macro 32721 only if 'INCOMING_FRAME_SP_OFFSET' can have different values 32722 between different functions of the same ABI or when 32723 'INCOMING_FRAME_SP_OFFSET' does not agree with GAS default CFI. 32724 32725 -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL) 32726 A C expression whose value is an integer giving the offset, in 32727 bytes, from the argument pointer to the canonical frame address 32728 (cfa). The final value should coincide with that calculated by 32729 'INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable 32730 during virtual register instantiation. 32731 32732 The default value for this macro is 'FIRST_PARM_OFFSET (fundecl) + 32733 crtl->args.pretend_args_size', which is correct for most machines; 32734 in general, the arguments are found immediately before the stack 32735 frame. Note that this is not the case on some targets that save 32736 registers into the caller's frame, such as SPARC and rs6000, and so 32737 such targets need to define this macro. 32738 32739 You only need to define this macro if the default is incorrect, and 32740 you want to support call frame debugging information like that 32741 provided by DWARF 2. 32742 32743 -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL) 32744 If defined, a C expression whose value is an integer giving the 32745 offset in bytes from the frame pointer to the canonical frame 32746 address (cfa). The final value should coincide with that 32747 calculated by 'INCOMING_FRAME_SP_OFFSET'. 32748 32749 Normally the CFA is calculated as an offset from the argument 32750 pointer, via 'ARG_POINTER_CFA_OFFSET', but if the argument pointer 32751 is variable due to the ABI, this may not be possible. If this 32752 macro is defined, it implies that the virtual register 32753 instantiation should be based on the frame pointer instead of the 32754 argument pointer. Only one of 'FRAME_POINTER_CFA_OFFSET' and 32755 'ARG_POINTER_CFA_OFFSET' should be defined. 32756 32757 -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL) 32758 If defined, a C expression whose value is an integer giving the 32759 offset in bytes from the canonical frame address (cfa) to the frame 32760 base used in DWARF 2 debug information. The default is zero. A 32761 different value may reduce the size of debug information on some 32762 ports. 32763 32764 32765File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling 32766 3276718.9.2 Exception Handling Support 32768--------------------------------- 32769 32770 -- Macro: EH_RETURN_DATA_REGNO (N) 32771 A C expression whose value is the Nth register number used for data 32772 by exception handlers, or 'INVALID_REGNUM' if fewer than N 32773 registers are usable. 32774 32775 The exception handling library routines communicate with the 32776 exception handlers via a set of agreed upon registers. Ideally 32777 these registers should be call-clobbered; it is possible to use 32778 call-saved registers, but may negatively impact code size. The 32779 target must support at least 2 data registers, but should define 4 32780 if there are enough free registers. 32781 32782 You must define this macro if you want to support call frame 32783 exception handling like that provided by DWARF 2. 32784 32785 -- Macro: EH_RETURN_STACKADJ_RTX 32786 A C expression whose value is RTL representing a location in which 32787 to store a stack adjustment to be applied before function return. 32788 This is used to unwind the stack to an exception handler's call 32789 frame. It will be assigned zero on code paths that return 32790 normally. 32791 32792 Typically this is a call-clobbered hard register that is otherwise 32793 untouched by the epilogue, but could also be a stack slot. 32794 32795 Do not define this macro if the stack pointer is saved and restored 32796 by the regular prolog and epilog code in the call frame itself; in 32797 this case, the exception handling library routines will update the 32798 stack location to be restored in place. Otherwise, you must define 32799 this macro if you want to support call frame exception handling 32800 like that provided by DWARF 2. 32801 32802 -- Macro: EH_RETURN_HANDLER_RTX 32803 A C expression whose value is RTL representing a location in which 32804 to store the address of an exception handler to which we should 32805 return. It will not be assigned on code paths that return 32806 normally. 32807 32808 Typically this is the location in the call frame at which the 32809 normal return address is stored. For targets that return by 32810 popping an address off the stack, this might be a memory address 32811 just below the _target_ call frame rather than inside the current 32812 call frame. If defined, 'EH_RETURN_STACKADJ_RTX' will have already 32813 been assigned, so it may be used to calculate the location of the 32814 target call frame. 32815 32816 Some targets have more complex requirements than storing to an 32817 address calculable during initial code generation. In that case 32818 the 'eh_return' instruction pattern should be used instead. 32819 32820 If you want to support call frame exception handling, you must 32821 define either this macro or the 'eh_return' instruction pattern. 32822 32823 -- Macro: RETURN_ADDR_OFFSET 32824 If defined, an integer-valued C expression for which rtl will be 32825 generated to add it to the exception handler address before it is 32826 searched in the exception handling tables, and to subtract it again 32827 from the address before using it to return to the exception 32828 handler. 32829 32830 -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL) 32831 This macro chooses the encoding of pointers embedded in the 32832 exception handling sections. If at all possible, this should be 32833 defined such that the exception handling section will not require 32834 dynamic relocations, and so may be read-only. 32835 32836 CODE is 0 for data, 1 for code labels, 2 for function pointers. 32837 GLOBAL is true if the symbol may be affected by dynamic 32838 relocations. The macro should return a combination of the 32839 'DW_EH_PE_*' defines as found in 'dwarf2.h'. 32840 32841 If this macro is not defined, pointers will not be encoded but 32842 represented directly. 32843 32844 -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE, 32845 ADDR, DONE) 32846 This macro allows the target to emit whatever special magic is 32847 required to represent the encoding chosen by 32848 'ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of 32849 pc-relative and indirect encodings; this must be defined if the 32850 target uses text-relative or data-relative encodings. 32851 32852 This is a C statement that branches to DONE if the format was 32853 handled. ENCODING is the format chosen, SIZE is the number of 32854 bytes that the format occupies, ADDR is the 'SYMBOL_REF' to be 32855 emitted. 32856 32857 -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS) 32858 This macro allows the target to add CPU and operating system 32859 specific code to the call-frame unwinder for use when there is no 32860 unwind data available. The most common reason to implement this 32861 macro is to unwind through signal frames. 32862 32863 This macro is called from 'uw_frame_state_for' in 'unwind-dw2.c', 32864 'unwind-dw2-xtensa.c' and 'unwind-ia64.c'. CONTEXT is an 32865 '_Unwind_Context'; FS is an '_Unwind_FrameState'. Examine 32866 'context->ra' for the address of the code being executed and 32867 'context->cfa' for the stack pointer value. If the frame can be 32868 decoded, the register save addresses should be updated in FS and 32869 the macro should evaluate to '_URC_NO_REASON'. If the frame cannot 32870 be decoded, the macro should evaluate to '_URC_END_OF_STACK'. 32871 32872 For proper signal handling in Java this macro is accompanied by 32873 'MAKE_THROW_FRAME', defined in 'libjava/include/*-signal.h' 32874 headers. 32875 32876 -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS) 32877 This macro allows the target to add operating system specific code 32878 to the call-frame unwinder to handle the IA-64 '.unwabi' unwinding 32879 directive, usually used for signal or interrupt frames. 32880 32881 This macro is called from 'uw_update_context' in libgcc's 32882 'unwind-ia64.c'. CONTEXT is an '_Unwind_Context'; FS is an 32883 '_Unwind_FrameState'. Examine 'fs->unwabi' for the abi and context 32884 in the '.unwabi' directive. If the '.unwabi' directive can be 32885 handled, the register save addresses should be updated in FS. 32886 32887 -- Macro: TARGET_USES_WEAK_UNWIND_INFO 32888 A C expression that evaluates to true if the target requires unwind 32889 info to be given comdat linkage. Define it to be '1' if comdat 32890 linkage is necessary. The default is '0'. 32891 32892 32893File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling 32894 3289518.9.3 Specifying How Stack Checking is Done 32896-------------------------------------------- 32897 32898GCC will check that stack references are within the boundaries of the 32899stack, if the option '-fstack-check' is specified, in one of three ways: 32900 32901 1. If the value of the 'STACK_CHECK_BUILTIN' macro is nonzero, GCC 32902 will assume that you have arranged for full stack checking to be 32903 done at appropriate places in the configuration files. GCC will 32904 not do other special processing. 32905 32906 2. If 'STACK_CHECK_BUILTIN' is zero and the value of the 32907 'STACK_CHECK_STATIC_BUILTIN' macro is nonzero, GCC will assume that 32908 you have arranged for static stack checking (checking of the static 32909 stack frame of functions) to be done at appropriate places in the 32910 configuration files. GCC will only emit code to do dynamic stack 32911 checking (checking on dynamic stack allocations) using the third 32912 approach below. 32913 32914 3. If neither of the above are true, GCC will generate code to 32915 periodically "probe" the stack pointer using the values of the 32916 macros defined below. 32917 32918 If neither STACK_CHECK_BUILTIN nor STACK_CHECK_STATIC_BUILTIN is 32919defined, GCC will change its allocation strategy for large objects if 32920the option '-fstack-check' is specified: they will always be allocated 32921dynamically if their size exceeds 'STACK_CHECK_MAX_VAR_SIZE' bytes. 32922 32923 -- Macro: STACK_CHECK_BUILTIN 32924 A nonzero value if stack checking is done by the configuration 32925 files in a machine-dependent manner. You should define this macro 32926 if stack checking is required by the ABI of your machine or if you 32927 would like to do stack checking in some more efficient way than the 32928 generic approach. The default value of this macro is zero. 32929 32930 -- Macro: STACK_CHECK_STATIC_BUILTIN 32931 A nonzero value if static stack checking is done by the 32932 configuration files in a machine-dependent manner. You should 32933 define this macro if you would like to do static stack checking in 32934 some more efficient way than the generic approach. The default 32935 value of this macro is zero. 32936 32937 -- Macro: STACK_CHECK_PROBE_INTERVAL_EXP 32938 An integer specifying the interval at which GCC must generate stack 32939 probe instructions, defined as 2 raised to this integer. You will 32940 normally define this macro so that the interval be no larger than 32941 the size of the "guard pages" at the end of a stack area. The 32942 default value of 12 (4096-byte interval) is suitable for most 32943 systems. 32944 32945 -- Macro: STACK_CHECK_MOVING_SP 32946 An integer which is nonzero if GCC should move the stack pointer 32947 page by page when doing probes. This can be necessary on systems 32948 where the stack pointer contains the bottom address of the memory 32949 area accessible to the executing thread at any point in time. In 32950 this situation an alternate signal stack is required in order to be 32951 able to recover from a stack overflow. The default value of this 32952 macro is zero. 32953 32954 -- Macro: STACK_CHECK_PROTECT 32955 The number of bytes of stack needed to recover from a stack 32956 overflow, for languages where such a recovery is supported. The 32957 default value of 4KB/8KB with the 'setjmp'/'longjmp'-based 32958 exception handling mechanism and 8KB/12KB with other exception 32959 handling mechanisms should be adequate for most architectures and 32960 operating systems. 32961 32962 The following macros are relevant only if neither STACK_CHECK_BUILTIN 32963nor STACK_CHECK_STATIC_BUILTIN is defined; you can omit them altogether 32964in the opposite case. 32965 32966 -- Macro: STACK_CHECK_MAX_FRAME_SIZE 32967 The maximum size of a stack frame, in bytes. GCC will generate 32968 probe instructions in non-leaf functions to ensure at least this 32969 many bytes of stack are available. If a stack frame is larger than 32970 this size, stack checking will not be reliable and GCC will issue a 32971 warning. The default is chosen so that GCC only generates one 32972 instruction on most systems. You should normally not change the 32973 default value of this macro. 32974 32975 -- Macro: STACK_CHECK_FIXED_FRAME_SIZE 32976 GCC uses this value to generate the above warning message. It 32977 represents the amount of fixed frame used by a function, not 32978 including space for any callee-saved registers, temporaries and 32979 user variables. You need only specify an upper bound for this 32980 amount and will normally use the default of four words. 32981 32982 -- Macro: STACK_CHECK_MAX_VAR_SIZE 32983 The maximum size, in bytes, of an object that GCC will place in the 32984 fixed area of the stack frame when the user specifies 32985 '-fstack-check'. GCC computed the default from the values of the 32986 above macros and you will normally not need to override that 32987 default. 32988 32989 -- Target Hook: bool TARGET_STACK_CLASH_PROTECTION_FINAL_DYNAMIC_PROBE 32990 (rtx RESIDUAL) 32991 Some targets make optimistic assumptions about the state of stack 32992 probing when they emit their prologues. On such targets a probe 32993 into the end of any dynamically allocated space is likely required 32994 for safety against stack clash style attacks. Define this variable 32995 to return nonzero if such a probe is required or zero otherwise. 32996 You need not define this macro if it would always have the value 32997 zero. 32998 32999 33000File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling 33001 3300218.9.4 Registers That Address the Stack Frame 33003--------------------------------------------- 33004 33005This discusses registers that address the stack frame. 33006 33007 -- Macro: STACK_POINTER_REGNUM 33008 The register number of the stack pointer register, which must also 33009 be a fixed register according to 'FIXED_REGISTERS'. On most 33010 machines, the hardware determines which register this is. 33011 33012 -- Macro: FRAME_POINTER_REGNUM 33013 The register number of the frame pointer register, which is used to 33014 access automatic variables in the stack frame. On some machines, 33015 the hardware determines which register this is. On other machines, 33016 you can choose any register you wish for this purpose. 33017 33018 -- Macro: HARD_FRAME_POINTER_REGNUM 33019 On some machines the offset between the frame pointer and starting 33020 offset of the automatic variables is not known until after register 33021 allocation has been done (for example, because the saved registers 33022 are between these two locations). On those machines, define 33023 'FRAME_POINTER_REGNUM' the number of a special, fixed register to 33024 be used internally until the offset is known, and define 33025 'HARD_FRAME_POINTER_REGNUM' to be the actual hard register number 33026 used for the frame pointer. 33027 33028 You should define this macro only in the very rare circumstances 33029 when it is not possible to calculate the offset between the frame 33030 pointer and the automatic variables until after register allocation 33031 has been completed. When this macro is defined, you must also 33032 indicate in your definition of 'ELIMINABLE_REGS' how to eliminate 33033 'FRAME_POINTER_REGNUM' into either 'HARD_FRAME_POINTER_REGNUM' or 33034 'STACK_POINTER_REGNUM'. 33035 33036 Do not define this macro if it would be the same as 33037 'FRAME_POINTER_REGNUM'. 33038 33039 -- Macro: ARG_POINTER_REGNUM 33040 The register number of the arg pointer register, which is used to 33041 access the function's argument list. On some machines, this is the 33042 same as the frame pointer register. On some machines, the hardware 33043 determines which register this is. On other machines, you can 33044 choose any register you wish for this purpose. If this is not the 33045 same register as the frame pointer register, then you must mark it 33046 as a fixed register according to 'FIXED_REGISTERS', or arrange to 33047 be able to eliminate it (*note Elimination::). 33048 33049 -- Macro: HARD_FRAME_POINTER_IS_FRAME_POINTER 33050 Define this to a preprocessor constant that is nonzero if 33051 'hard_frame_pointer_rtx' and 'frame_pointer_rtx' should be the 33052 same. The default definition is '(HARD_FRAME_POINTER_REGNUM == 33053 FRAME_POINTER_REGNUM)'; you only need to define this macro if that 33054 definition is not suitable for use in preprocessor conditionals. 33055 33056 -- Macro: HARD_FRAME_POINTER_IS_ARG_POINTER 33057 Define this to a preprocessor constant that is nonzero if 33058 'hard_frame_pointer_rtx' and 'arg_pointer_rtx' should be the same. 33059 The default definition is '(HARD_FRAME_POINTER_REGNUM == 33060 ARG_POINTER_REGNUM)'; you only need to define this macro if that 33061 definition is not suitable for use in preprocessor conditionals. 33062 33063 -- Macro: RETURN_ADDRESS_POINTER_REGNUM 33064 The register number of the return address pointer register, which 33065 is used to access the current function's return address from the 33066 stack. On some machines, the return address is not at a fixed 33067 offset from the frame pointer or stack pointer or argument pointer. 33068 This register can be defined to point to the return address on the 33069 stack, and then be converted by 'ELIMINABLE_REGS' into either the 33070 frame pointer or stack pointer. 33071 33072 Do not define this macro unless there is no other way to get the 33073 return address from the stack. 33074 33075 -- Macro: STATIC_CHAIN_REGNUM 33076 -- Macro: STATIC_CHAIN_INCOMING_REGNUM 33077 Register numbers used for passing a function's static chain 33078 pointer. If register windows are used, the register number as seen 33079 by the called function is 'STATIC_CHAIN_INCOMING_REGNUM', while the 33080 register number as seen by the calling function is 33081 'STATIC_CHAIN_REGNUM'. If these registers are the same, 33082 'STATIC_CHAIN_INCOMING_REGNUM' need not be defined. 33083 33084 The static chain register need not be a fixed register. 33085 33086 If the static chain is passed in memory, these macros should not be 33087 defined; instead, the 'TARGET_STATIC_CHAIN' hook should be used. 33088 33089 -- Target Hook: rtx TARGET_STATIC_CHAIN (const_tree FNDECL_OR_TYPE, 33090 bool INCOMING_P) 33091 This hook replaces the use of 'STATIC_CHAIN_REGNUM' et al for 33092 targets that may use different static chain locations for different 33093 nested functions. This may be required if the target has function 33094 attributes that affect the calling conventions of the function and 33095 those calling conventions use different static chain locations. 33096 33097 The default version of this hook uses 'STATIC_CHAIN_REGNUM' et al. 33098 33099 If the static chain is passed in memory, this hook should be used 33100 to provide rtx giving 'mem' expressions that denote where they are 33101 stored. Often the 'mem' expression as seen by the caller will be 33102 at an offset from the stack pointer and the 'mem' expression as 33103 seen by the callee will be at an offset from the frame pointer. 33104 The variables 'stack_pointer_rtx', 'frame_pointer_rtx', and 33105 'arg_pointer_rtx' will have been initialized and should be used to 33106 refer to those items. 33107 33108 -- Macro: DWARF_FRAME_REGISTERS 33109 This macro specifies the maximum number of hard registers that can 33110 be saved in a call frame. This is used to size data structures 33111 used in DWARF2 exception handling. 33112 33113 Prior to GCC 3.0, this macro was needed in order to establish a 33114 stable exception handling ABI in the face of adding new hard 33115 registers for ISA extensions. In GCC 3.0 and later, the EH ABI is 33116 insulated from changes in the number of hard registers. 33117 Nevertheless, this macro can still be used to reduce the runtime 33118 memory requirements of the exception handling routines, which can 33119 be substantial if the ISA contains a lot of registers that are not 33120 call-saved. 33121 33122 If this macro is not defined, it defaults to 33123 'FIRST_PSEUDO_REGISTER'. 33124 33125 -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS 33126 33127 This macro is similar to 'DWARF_FRAME_REGISTERS', but is provided 33128 for backward compatibility in pre GCC 3.0 compiled code. 33129 33130 If this macro is not defined, it defaults to 33131 'DWARF_FRAME_REGISTERS'. 33132 33133 -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO) 33134 33135 Define this macro if the target's representation for dwarf 33136 registers is different than the internal representation for unwind 33137 column. Given a dwarf register, this macro should return the 33138 internal unwind column number to use instead. 33139 33140 -- Macro: DWARF_FRAME_REGNUM (REGNO) 33141 33142 Define this macro if the target's representation for dwarf 33143 registers used in .eh_frame or .debug_frame is different from that 33144 used in other debug info sections. Given a GCC hard register 33145 number, this macro should return the .eh_frame register number. 33146 The default is 'DBX_REGISTER_NUMBER (REGNO)'. 33147 33148 -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH) 33149 33150 Define this macro to map register numbers held in the call frame 33151 info that GCC has collected using 'DWARF_FRAME_REGNUM' to those 33152 that should be output in .debug_frame ('FOR_EH' is zero) and 33153 .eh_frame ('FOR_EH' is nonzero). The default is to return 'REGNO'. 33154 33155 -- Macro: REG_VALUE_IN_UNWIND_CONTEXT 33156 33157 Define this macro if the target stores register values as 33158 '_Unwind_Word' type in unwind context. It should be defined if 33159 target register size is larger than the size of 'void *'. The 33160 default is to store register values as 'void *' type. 33161 33162 -- Macro: ASSUME_EXTENDED_UNWIND_CONTEXT 33163 33164 Define this macro to be 1 if the target always uses extended unwind 33165 context with version, args_size and by_value fields. If it is 33166 undefined, it will be defined to 1 when 33167 'REG_VALUE_IN_UNWIND_CONTEXT' is defined and 0 otherwise. 33168 33169 -- Macro: DWARF_LAZY_REGISTER_VALUE (REGNO, VALUE) 33170 Define this macro if the target has pseudo DWARF registers whose 33171 values need to be computed lazily on demand by the unwinder (such 33172 as when referenced in a CFA expression). The macro returns true if 33173 REGNO is such a register and stores its value in '*VALUE' if so. 33174 33175 33176File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling 33177 3317818.9.5 Eliminating Frame Pointer and Arg Pointer 33179------------------------------------------------ 33180 33181This is about eliminating the frame pointer and arg pointer. 33182 33183 -- Target Hook: bool TARGET_FRAME_POINTER_REQUIRED (void) 33184 This target hook should return 'true' if a function must have and 33185 use a frame pointer. This target hook is called in the reload 33186 pass. If its return value is 'true' the function will have a frame 33187 pointer. 33188 33189 This target hook can in principle examine the current function and 33190 decide according to the facts, but on most machines the constant 33191 'false' or the constant 'true' suffices. Use 'false' when the 33192 machine allows code to be generated with no frame pointer, and 33193 doing so saves some time or space. Use 'true' when there is no 33194 possible advantage to avoiding a frame pointer. 33195 33196 In certain cases, the compiler does not know how to produce valid 33197 code without a frame pointer. The compiler recognizes those cases 33198 and automatically gives the function a frame pointer regardless of 33199 what 'targetm.frame_pointer_required' returns. You don't need to 33200 worry about them. 33201 33202 In a function that does not require a frame pointer, the frame 33203 pointer register can be allocated for ordinary usage, unless you 33204 mark it as a fixed register. See 'FIXED_REGISTERS' for more 33205 information. 33206 33207 Default return value is 'false'. 33208 33209 -- Macro: ELIMINABLE_REGS 33210 This macro specifies a table of register pairs used to eliminate 33211 unneeded registers that point into the stack frame. 33212 33213 The definition of this macro is a list of structure 33214 initializations, each of which specifies an original and 33215 replacement register. 33216 33217 On some machines, the position of the argument pointer is not known 33218 until the compilation is completed. In such a case, a separate 33219 hard register must be used for the argument pointer. This register 33220 can be eliminated by replacing it with either the frame pointer or 33221 the argument pointer, depending on whether or not the frame pointer 33222 has been eliminated. 33223 33224 In this case, you might specify: 33225 #define ELIMINABLE_REGS \ 33226 {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ 33227 {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ 33228 {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} 33229 33230 Note that the elimination of the argument pointer with the stack 33231 pointer is specified first since that is the preferred elimination. 33232 33233 -- Target Hook: bool TARGET_CAN_ELIMINATE (const int FROM_REG, const 33234 int TO_REG) 33235 This target hook should return 'true' if the compiler is allowed to 33236 try to replace register number FROM_REG with register number 33237 TO_REG. This target hook will usually be 'true', since most of the 33238 cases preventing register elimination are things that the compiler 33239 already knows about. 33240 33241 Default return value is 'true'. 33242 33243 -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR) 33244 This macro returns the initial difference between the specified 33245 pair of registers. The value would be computed from information 33246 such as the result of 'get_frame_size ()' and the tables of 33247 registers 'df_regs_ever_live_p' and 'call_used_regs'. 33248 33249 -- Target Hook: void TARGET_COMPUTE_FRAME_LAYOUT (void) 33250 This target hook is called once each time the frame layout needs to 33251 be recalculated. The calculations can be cached by the target and 33252 can then be used by 'INITIAL_ELIMINATION_OFFSET' instead of 33253 re-computing the layout on every invocation of that hook. This is 33254 particularly useful for targets that have an expensive frame layout 33255 function. Implementing this callback is optional. 33256 33257 33258File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling 33259 3326018.9.6 Passing Function Arguments on the Stack 33261---------------------------------------------- 33262 33263The macros in this section control how arguments are passed on the 33264stack. See the following section for other macros that control passing 33265certain arguments in registers. 33266 33267 -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (const_tree FNTYPE) 33268 This target hook returns 'true' if an argument declared in a 33269 prototype as an integral type smaller than 'int' should actually be 33270 passed as an 'int'. In addition to avoiding errors in certain 33271 cases of mismatch, it also makes for better code on certain 33272 machines. The default is to not promote prototypes. 33273 33274 -- Macro: PUSH_ARGS 33275 A C expression. If nonzero, push insns will be used to pass 33276 outgoing arguments. If the target machine does not have a push 33277 instruction, set it to zero. That directs GCC to use an alternate 33278 strategy: to allocate the entire argument block and then store the 33279 arguments into it. When 'PUSH_ARGS' is nonzero, 'PUSH_ROUNDING' 33280 must be defined too. 33281 33282 -- Macro: PUSH_ARGS_REVERSED 33283 A C expression. If nonzero, function arguments will be evaluated 33284 from last to first, rather than from first to last. If this macro 33285 is not defined, it defaults to 'PUSH_ARGS' on targets where the 33286 stack and args grow in opposite directions, and 0 otherwise. 33287 33288 -- Macro: PUSH_ROUNDING (NPUSHED) 33289 A C expression that is the number of bytes actually pushed onto the 33290 stack when an instruction attempts to push NPUSHED bytes. 33291 33292 On some machines, the definition 33293 33294 #define PUSH_ROUNDING(BYTES) (BYTES) 33295 33296 will suffice. But on other machines, instructions that appear to 33297 push one byte actually push two bytes in an attempt to maintain 33298 alignment. Then the definition should be 33299 33300 #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) 33301 33302 If the value of this macro has a type, it should be an unsigned 33303 type. 33304 33305 -- Macro: ACCUMULATE_OUTGOING_ARGS 33306 A C expression. If nonzero, the maximum amount of space required 33307 for outgoing arguments will be computed and placed into 33308 'crtl->outgoing_args_size'. No space will be pushed onto the stack 33309 for each call; instead, the function prologue should increase the 33310 stack frame size by this amount. 33311 33312 Setting both 'PUSH_ARGS' and 'ACCUMULATE_OUTGOING_ARGS' is not 33313 proper. 33314 33315 -- Macro: REG_PARM_STACK_SPACE (FNDECL) 33316 Define this macro if functions should assume that stack space has 33317 been allocated for arguments even when their values are passed in 33318 registers. 33319 33320 The value of this macro is the size, in bytes, of the area reserved 33321 for arguments passed in registers for the function represented by 33322 FNDECL, which can be zero if GCC is calling a library function. 33323 The argument FNDECL can be the FUNCTION_DECL, or the type itself of 33324 the function. 33325 33326 This space can be allocated by the caller, or be a part of the 33327 machine-dependent stack frame: 'OUTGOING_REG_PARM_STACK_SPACE' says 33328 which. 33329 33330 -- Macro: INCOMING_REG_PARM_STACK_SPACE (FNDECL) 33331 Like 'REG_PARM_STACK_SPACE', but for incoming register arguments. 33332 Define this macro if space guaranteed when compiling a function 33333 body is different to space required when making a call, a situation 33334 that can arise with K&R style function definitions. 33335 33336 -- Macro: OUTGOING_REG_PARM_STACK_SPACE (FNTYPE) 33337 Define this to a nonzero value if it is the responsibility of the 33338 caller to allocate the area reserved for arguments passed in 33339 registers when calling a function of FNTYPE. FNTYPE may be NULL if 33340 the function called is a library function. 33341 33342 If 'ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls 33343 whether the space for these arguments counts in the value of 33344 'crtl->outgoing_args_size'. 33345 33346 -- Macro: STACK_PARMS_IN_REG_PARM_AREA 33347 Define this macro if 'REG_PARM_STACK_SPACE' is defined, but the 33348 stack parameters don't skip the area specified by it. 33349 33350 Normally, when a parameter is not passed in registers, it is placed 33351 on the stack beyond the 'REG_PARM_STACK_SPACE' area. Defining this 33352 macro suppresses this behavior and causes the parameter to be 33353 passed on the stack in its natural location. 33354 33355 -- Target Hook: poly_int64 TARGET_RETURN_POPS_ARGS (tree FUNDECL, tree 33356 FUNTYPE, poly_int64 SIZE) 33357 This target hook returns the number of bytes of its own arguments 33358 that a function pops on returning, or 0 if the function pops no 33359 arguments and the caller must therefore pop them all after the 33360 function returns. 33361 33362 FUNDECL is a C variable whose value is a tree node that describes 33363 the function in question. Normally it is a node of type 33364 'FUNCTION_DECL' that describes the declaration of the function. 33365 From this you can obtain the 'DECL_ATTRIBUTES' of the function. 33366 33367 FUNTYPE is a C variable whose value is a tree node that describes 33368 the function in question. Normally it is a node of type 33369 'FUNCTION_TYPE' that describes the data type of the function. From 33370 this it is possible to obtain the data types of the value and 33371 arguments (if known). 33372 33373 When a call to a library function is being considered, FUNDECL will 33374 contain an identifier node for the library function. Thus, if you 33375 need to distinguish among various library functions, you can do so 33376 by their names. Note that "library function" in this context means 33377 a function used to perform arithmetic, whose name is known 33378 specially in the compiler and was not mentioned in the C code being 33379 compiled. 33380 33381 SIZE is the number of bytes of arguments passed on the stack. If a 33382 variable number of bytes is passed, it is zero, and argument 33383 popping will always be the responsibility of the calling function. 33384 33385 On the VAX, all functions always pop their arguments, so the 33386 definition of this macro is SIZE. On the 68000, using the standard 33387 calling convention, no functions pop their arguments, so the value 33388 of the macro is always 0 in this case. But an alternative calling 33389 convention is available in which functions that take a fixed number 33390 of arguments pop them but other functions (such as 'printf') pop 33391 nothing (the caller pops all). When this convention is in use, 33392 FUNTYPE is examined to determine whether a function takes a fixed 33393 number of arguments. 33394 33395 -- Macro: CALL_POPS_ARGS (CUM) 33396 A C expression that should indicate the number of bytes a call 33397 sequence pops off the stack. It is added to the value of 33398 'RETURN_POPS_ARGS' when compiling a function call. 33399 33400 CUM is the variable in which all arguments to the called function 33401 have been accumulated. 33402 33403 On certain architectures, such as the SH5, a call trampoline is 33404 used that pops certain registers off the stack, depending on the 33405 arguments that have been passed to the function. Since this is a 33406 property of the call site, not of the called function, 33407 'RETURN_POPS_ARGS' is not appropriate. 33408 33409 33410File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling 33411 3341218.9.7 Passing Arguments in Registers 33413------------------------------------- 33414 33415This section describes the macros which let you control how various 33416types of arguments are passed in registers or how they are arranged in 33417the stack. 33418 33419 -- Target Hook: rtx TARGET_FUNCTION_ARG (cumulative_args_t CA, 33420 machine_mode MODE, const_tree TYPE, bool NAMED) 33421 Return an RTX indicating whether a function argument is passed in a 33422 register and if so, which register. 33423 33424 The arguments are CA, which summarizes all the previous arguments; 33425 MODE, the machine mode of the argument; TYPE, the data type of the 33426 argument as a tree node or 0 if that is not known (which happens 33427 for C support library functions); and NAMED, which is 'true' for an 33428 ordinary argument and 'false' for nameless arguments that 33429 correspond to '...' in the called function's prototype. TYPE can 33430 be an incomplete type if a syntax error has previously occurred. 33431 33432 The return value is usually either a 'reg' RTX for the hard 33433 register in which to pass the argument, or zero to pass the 33434 argument on the stack. 33435 33436 The return value can be a 'const_int' which means argument is 33437 passed in a target specific slot with specified number. Target 33438 hooks should be used to store or load argument in such case. See 33439 'TARGET_STORE_BOUNDS_FOR_ARG' and 'TARGET_LOAD_BOUNDS_FOR_ARG' for 33440 more information. 33441 33442 The value of the expression can also be a 'parallel' RTX. This is 33443 used when an argument is passed in multiple locations. The mode of 33444 the 'parallel' should be the mode of the entire argument. The 33445 'parallel' holds any number of 'expr_list' pairs; each one 33446 describes where part of the argument is passed. In each 33447 'expr_list' the first operand must be a 'reg' RTX for the hard 33448 register in which to pass this part of the argument, and the mode 33449 of the register RTX indicates how large this part of the argument 33450 is. The second operand of the 'expr_list' is a 'const_int' which 33451 gives the offset in bytes into the entire argument of where this 33452 part starts. As a special exception the first 'expr_list' in the 33453 'parallel' RTX may have a first operand of zero. This indicates 33454 that the entire argument is also stored on the stack. 33455 33456 The last time this hook is called, it is called with 'MODE == 33457 VOIDmode', and its result is passed to the 'call' or 'call_value' 33458 pattern as operands 2 and 3 respectively. 33459 33460 The usual way to make the ISO library 'stdarg.h' work on a machine 33461 where some arguments are usually passed in registers, is to cause 33462 nameless arguments to be passed on the stack instead. This is done 33463 by making 'TARGET_FUNCTION_ARG' return 0 whenever NAMED is 'false'. 33464 33465 You may use the hook 'targetm.calls.must_pass_in_stack' in the 33466 definition of this macro to determine if this argument is of a type 33467 that must be passed in the stack. If 'REG_PARM_STACK_SPACE' is not 33468 defined and 'TARGET_FUNCTION_ARG' returns nonzero for such an 33469 argument, the compiler will abort. If 'REG_PARM_STACK_SPACE' is 33470 defined, the argument will be computed in the stack and then loaded 33471 into a register. 33472 33473 -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (machine_mode MODE, 33474 const_tree TYPE) 33475 This target hook should return 'true' if we should not pass TYPE 33476 solely in registers. The file 'expr.h' defines a definition that 33477 is usually appropriate, refer to 'expr.h' for additional 33478 documentation. 33479 33480 -- Target Hook: rtx TARGET_FUNCTION_INCOMING_ARG (cumulative_args_t CA, 33481 machine_mode MODE, const_tree TYPE, bool NAMED) 33482 Define this hook if the caller and callee on the target have 33483 different views of where arguments are passed. Also define this 33484 hook if there are functions that are never directly called, but are 33485 invoked by the hardware and which have nonstandard calling 33486 conventions. 33487 33488 In this case 'TARGET_FUNCTION_ARG' computes the register in which 33489 the caller passes the value, and 'TARGET_FUNCTION_INCOMING_ARG' 33490 should be defined in a similar fashion to tell the function being 33491 called where the arguments will arrive. 33492 33493 'TARGET_FUNCTION_INCOMING_ARG' can also return arbitrary address 33494 computation using hard register, which can be forced into a 33495 register, so that it can be used to pass special arguments. 33496 33497 If 'TARGET_FUNCTION_INCOMING_ARG' is not defined, 33498 'TARGET_FUNCTION_ARG' serves both purposes. 33499 33500 -- Target Hook: bool TARGET_USE_PSEUDO_PIC_REG (void) 33501 This hook should return 1 in case pseudo register should be created 33502 for pic_offset_table_rtx during function expand. 33503 33504 -- Target Hook: void TARGET_INIT_PIC_REG (void) 33505 Perform a target dependent initialization of pic_offset_table_rtx. 33506 This hook is called at the start of register allocation. 33507 33508 -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (cumulative_args_t CUM, 33509 machine_mode MODE, tree TYPE, bool NAMED) 33510 This target hook returns the number of bytes at the beginning of an 33511 argument that must be put in registers. The value must be zero for 33512 arguments that are passed entirely in registers or that are 33513 entirely pushed on the stack. 33514 33515 On some machines, certain arguments must be passed partially in 33516 registers and partially in memory. On these machines, typically 33517 the first few words of arguments are passed in registers, and the 33518 rest on the stack. If a multi-word argument (a 'double' or a 33519 structure) crosses that boundary, its first few words must be 33520 passed in registers and the rest must be pushed. This macro tells 33521 the compiler when this occurs, and how many bytes should go in 33522 registers. 33523 33524 'TARGET_FUNCTION_ARG' for these arguments should return the first 33525 register to be used by the caller for this argument; likewise 33526 'TARGET_FUNCTION_INCOMING_ARG', for the called function. 33527 33528 -- Target Hook: bool TARGET_PASS_BY_REFERENCE (cumulative_args_t CUM, 33529 machine_mode MODE, const_tree TYPE, bool NAMED) 33530 This target hook should return 'true' if an argument at the 33531 position indicated by CUM should be passed by reference. This 33532 predicate is queried after target independent reasons for being 33533 passed by reference, such as 'TREE_ADDRESSABLE (type)'. 33534 33535 If the hook returns true, a copy of that argument is made in memory 33536 and a pointer to the argument is passed instead of the argument 33537 itself. The pointer is passed in whatever way is appropriate for 33538 passing a pointer to that type. 33539 33540 -- Target Hook: bool TARGET_CALLEE_COPIES (cumulative_args_t CUM, 33541 machine_mode MODE, const_tree TYPE, bool NAMED) 33542 The function argument described by the parameters to this hook is 33543 known to be passed by reference. The hook should return true if 33544 the function argument should be copied by the callee instead of 33545 copied by the caller. 33546 33547 For any argument for which the hook returns true, if it can be 33548 determined that the argument is not modified, then a copy need not 33549 be generated. 33550 33551 The default version of this hook always returns false. 33552 33553 -- Macro: CUMULATIVE_ARGS 33554 A C type for declaring a variable that is used as the first 33555 argument of 'TARGET_FUNCTION_ARG' and other related values. For 33556 some target machines, the type 'int' suffices and can hold the 33557 number of bytes of argument so far. 33558 33559 There is no need to record in 'CUMULATIVE_ARGS' anything about the 33560 arguments that have been passed on the stack. The compiler has 33561 other variables to keep track of that. For target machines on 33562 which all arguments are passed on the stack, there is no need to 33563 store anything in 'CUMULATIVE_ARGS'; however, the data structure 33564 must exist and should not be empty, so use 'int'. 33565 33566 -- Macro: OVERRIDE_ABI_FORMAT (FNDECL) 33567 If defined, this macro is called before generating any code for a 33568 function, but after the CFUN descriptor for the function has been 33569 created. The back end may use this macro to update CFUN to reflect 33570 an ABI other than that which would normally be used by default. If 33571 the compiler is generating code for a compiler-generated function, 33572 FNDECL may be 'NULL'. 33573 33574 -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL, 33575 N_NAMED_ARGS) 33576 A C statement (sans semicolon) for initializing the variable CUM 33577 for the state at the beginning of the argument list. The variable 33578 has type 'CUMULATIVE_ARGS'. The value of FNTYPE is the tree node 33579 for the data type of the function which will receive the args, or 0 33580 if the args are to a compiler support library function. For direct 33581 calls that are not libcalls, FNDECL contain the declaration node of 33582 the function. FNDECL is also set when 'INIT_CUMULATIVE_ARGS' is 33583 used to find arguments for the function being compiled. 33584 N_NAMED_ARGS is set to the number of named arguments, including a 33585 structure return address if it is passed as a parameter, when 33586 making a call. When processing incoming arguments, N_NAMED_ARGS is 33587 set to -1. 33588 33589 When processing a call to a compiler support library function, 33590 LIBNAME identifies which one. It is a 'symbol_ref' rtx which 33591 contains the name of the function, as a string. LIBNAME is 0 when 33592 an ordinary C function call is being processed. Thus, each time 33593 this macro is called, either LIBNAME or FNTYPE is nonzero, but 33594 never both of them at once. 33595 33596 -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME) 33597 Like 'INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls, it 33598 gets a 'MODE' argument instead of FNTYPE, that would be 'NULL'. 33599 INDIRECT would always be zero, too. If this macro is not defined, 33600 'INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is used instead. 33601 33602 -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME) 33603 Like 'INIT_CUMULATIVE_ARGS' but overrides it for the purposes of 33604 finding the arguments for the function being compiled. If this 33605 macro is undefined, 'INIT_CUMULATIVE_ARGS' is used instead. 33606 33607 The value passed for LIBNAME is always 0, since library routines 33608 with special calling conventions are never compiled with GCC. The 33609 argument LIBNAME exists for symmetry with 'INIT_CUMULATIVE_ARGS'. 33610 33611 -- Target Hook: void TARGET_FUNCTION_ARG_ADVANCE (cumulative_args_t CA, 33612 machine_mode MODE, const_tree TYPE, bool NAMED) 33613 This hook updates the summarizer variable pointed to by CA to 33614 advance past an argument in the argument list. The values MODE, 33615 TYPE and NAMED describe that argument. Once this is done, the 33616 variable CUM is suitable for analyzing the _following_ argument 33617 with 'TARGET_FUNCTION_ARG', etc. 33618 33619 This hook need not do anything if the argument in question was 33620 passed on the stack. The compiler knows how to track the amount of 33621 stack space used for arguments without any special help. 33622 33623 -- Target Hook: HOST_WIDE_INT TARGET_FUNCTION_ARG_OFFSET (machine_mode 33624 MODE, const_tree TYPE) 33625 This hook returns the number of bytes to add to the offset of an 33626 argument of type TYPE and mode MODE when passed in memory. This is 33627 needed for the SPU, which passes 'char' and 'short' arguments in 33628 the preferred slot that is in the middle of the quad word instead 33629 of starting at the top. The default implementation returns 0. 33630 33631 -- Target Hook: pad_direction TARGET_FUNCTION_ARG_PADDING (machine_mode 33632 MODE, const_tree TYPE) 33633 This hook determines whether, and in which direction, to pad out an 33634 argument of mode MODE and type TYPE. It returns 'PAD_UPWARD' to 33635 insert padding above the argument, 'PAD_DOWNWARD' to insert padding 33636 below the argument, or 'PAD_NONE' to inhibit padding. 33637 33638 The _amount_ of padding is not controlled by this hook, but by 33639 'TARGET_FUNCTION_ARG_ROUND_BOUNDARY'. It is always just enough to 33640 reach the next multiple of that boundary. 33641 33642 This hook has a default definition that is right for most systems. 33643 For little-endian machines, the default is to pad upward. For 33644 big-endian machines, the default is to pad downward for an argument 33645 of constant size shorter than an 'int', and upward otherwise. 33646 33647 -- Macro: PAD_VARARGS_DOWN 33648 If defined, a C expression which determines whether the default 33649 implementation of va_arg will attempt to pad down before reading 33650 the next argument, if that argument is smaller than its aligned 33651 space as controlled by 'PARM_BOUNDARY'. If this macro is not 33652 defined, all such arguments are padded down if 'BYTES_BIG_ENDIAN' 33653 is true. 33654 33655 -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST) 33656 Specify padding for the last element of a block move between 33657 registers and memory. FIRST is nonzero if this is the only 33658 element. Defining this macro allows better control of register 33659 function parameters on big-endian machines, without using 33660 'PARALLEL' rtl. In particular, 'MUST_PASS_IN_STACK' need not test 33661 padding and mode of types in registers, as there is no longer a 33662 "wrong" part of a register; For example, a three byte aggregate may 33663 be passed in the high part of a register if so required. 33664 33665 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_BOUNDARY (machine_mode 33666 MODE, const_tree TYPE) 33667 This hook returns the alignment boundary, in bits, of an argument 33668 with the specified mode and type. The default hook returns 33669 'PARM_BOUNDARY' for all arguments. 33670 33671 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_ROUND_BOUNDARY 33672 (machine_mode MODE, const_tree TYPE) 33673 Normally, the size of an argument is rounded up to 'PARM_BOUNDARY', 33674 which is the default value for this hook. You can define this hook 33675 to return a different value if an argument size must be rounded to 33676 a larger value. 33677 33678 -- Macro: FUNCTION_ARG_REGNO_P (REGNO) 33679 A C expression that is nonzero if REGNO is the number of a hard 33680 register in which function arguments are sometimes passed. This 33681 does _not_ include implicit arguments such as the static chain and 33682 the structure-value address. On many machines, no registers can be 33683 used for this purpose since all function arguments are pushed on 33684 the stack. 33685 33686 -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (const_tree TYPE) 33687 This hook should return true if parameter of type TYPE are passed 33688 as two scalar parameters. By default, GCC will attempt to pack 33689 complex arguments into the target's word size. Some ABIs require 33690 complex arguments to be split and treated as their individual 33691 components. For example, on AIX64, complex floats should be passed 33692 in a pair of floating point registers, even though a complex float 33693 would fit in one 64-bit floating point register. 33694 33695 The default value of this hook is 'NULL', which is treated as 33696 always false. 33697 33698 -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void) 33699 This hook returns a type node for 'va_list' for the target. The 33700 default version of the hook returns 'void*'. 33701 33702 -- Target Hook: int TARGET_ENUM_VA_LIST_P (int IDX, const char **PNAME, 33703 tree *PTREE) 33704 This target hook is used in function 'c_common_nodes_and_builtins' 33705 to iterate through the target specific builtin types for va_list. 33706 The variable IDX is used as iterator. PNAME has to be a pointer to 33707 a 'const char *' and PTREE a pointer to a 'tree' typed variable. 33708 The arguments PNAME and PTREE are used to store the result of this 33709 macro and are set to the name of the va_list builtin type and its 33710 internal type. If the return value of this macro is zero, then 33711 there is no more element. Otherwise the IDX should be increased 33712 for the next call of this macro to iterate through all types. 33713 33714 -- Target Hook: tree TARGET_FN_ABI_VA_LIST (tree FNDECL) 33715 This hook returns the va_list type of the calling convention 33716 specified by FNDECL. The default version of this hook returns 33717 'va_list_type_node'. 33718 33719 -- Target Hook: tree TARGET_CANONICAL_VA_LIST_TYPE (tree TYPE) 33720 This hook returns the va_list type of the calling convention 33721 specified by the type of TYPE. If TYPE is not a valid va_list 33722 type, it returns 'NULL_TREE'. 33723 33724 -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree 33725 TYPE, gimple_seq *PRE_P, gimple_seq *POST_P) 33726 This hook performs target-specific gimplification of 'VA_ARG_EXPR'. 33727 The first two parameters correspond to the arguments to 'va_arg'; 33728 the latter two are as in 'gimplify.c:gimplify_expr'. 33729 33730 -- Target Hook: bool TARGET_VALID_POINTER_MODE (scalar_int_mode MODE) 33731 Define this to return nonzero if the port can handle pointers with 33732 machine mode MODE. The default version of this hook returns true 33733 for both 'ptr_mode' and 'Pmode'. 33734 33735 -- Target Hook: bool TARGET_REF_MAY_ALIAS_ERRNO (struct ao_ref *REF) 33736 Define this to return nonzero if the memory reference REF may alias 33737 with the system C library errno location. The default version of 33738 this hook assumes the system C library errno location is either a 33739 declaration of type int or accessed by dereferencing a pointer to 33740 int. 33741 33742 -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (scalar_mode MODE) 33743 Define this to return nonzero if the port is prepared to handle 33744 insns involving scalar mode MODE. For a scalar mode to be 33745 considered supported, all the basic arithmetic and comparisons must 33746 work. 33747 33748 The default version of this hook returns true for any mode required 33749 to handle the basic C types (as defined by the port). Included 33750 here are the double-word arithmetic supported by the code in 33751 'optabs.c'. 33752 33753 -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (machine_mode MODE) 33754 Define this to return nonzero if the port is prepared to handle 33755 insns involving vector mode MODE. At the very least, it must have 33756 move patterns for this mode. 33757 33758 -- Target Hook: opt_machine_mode TARGET_ARRAY_MODE (machine_mode MODE, 33759 unsigned HOST_WIDE_INT NELEMS) 33760 Return the mode that GCC should use for an array that has NELEMS 33761 elements, with each element having mode MODE. Return no mode if 33762 the target has no special requirements. In the latter case, GCC 33763 looks for an integer mode of the appropriate size if available and 33764 uses BLKmode otherwise. Usually the search for the integer mode is 33765 limited to 'MAX_FIXED_MODE_SIZE', but the 33766 'TARGET_ARRAY_MODE_SUPPORTED_P' hook allows a larger mode to be 33767 used in specific cases. 33768 33769 The main use of this hook is to specify that an array of vectors 33770 should also have a vector mode. The default implementation returns 33771 no mode. 33772 33773 -- Target Hook: bool TARGET_ARRAY_MODE_SUPPORTED_P (machine_mode MODE, 33774 unsigned HOST_WIDE_INT NELEMS) 33775 Return true if GCC should try to use a scalar mode to store an 33776 array of NELEMS elements, given that each element has mode MODE. 33777 Returning true here overrides the usual 'MAX_FIXED_MODE' limit and 33778 allows GCC to use any defined integer mode. 33779 33780 One use of this hook is to support vector load and store operations 33781 that operate on several homogeneous vectors. For example, ARM NEON 33782 has operations like: 33783 33784 int8x8x3_t vld3_s8 (const int8_t *) 33785 33786 where the return type is defined as: 33787 33788 typedef struct int8x8x3_t 33789 { 33790 int8x8_t val[3]; 33791 } int8x8x3_t; 33792 33793 If this hook allows 'val' to have a scalar mode, then 'int8x8x3_t' 33794 can have the same mode. GCC can then store 'int8x8x3_t's in 33795 registers rather than forcing them onto the stack. 33796 33797 -- Target Hook: bool TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P 33798 (scalar_float_mode MODE) 33799 Define this to return nonzero if libgcc provides support for the 33800 floating-point mode MODE, which is known to pass 33801 'TARGET_SCALAR_MODE_SUPPORTED_P'. The default version of this hook 33802 returns true for all of 'SFmode', 'DFmode', 'XFmode' and 'TFmode', 33803 if such modes exist. 33804 33805 -- Target Hook: opt_scalar_float_mode TARGET_FLOATN_MODE (int N, bool 33806 EXTENDED) 33807 Define this to return the machine mode to use for the type 33808 '_FloatN', if EXTENDED is false, or the type '_FloatNx', if 33809 EXTENDED is true. If such a type is not supported, return 33810 'opt_scalar_float_mode ()'. The default version of this hook 33811 returns 'SFmode' for '_Float32', 'DFmode' for '_Float64' and 33812 '_Float32x' and 'TFmode' for '_Float128', if those modes exist and 33813 satisfy the requirements for those types and pass 33814 'TARGET_SCALAR_MODE_SUPPORTED_P' and 33815 'TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P'; for '_Float64x', it 33816 returns the first of 'XFmode' and 'TFmode' that exists and 33817 satisfies the same requirements; for other types, it returns 33818 'opt_scalar_float_mode ()'. The hook is only called for values of 33819 N and EXTENDED that are valid according to ISO/IEC TS 18661-3:2015; 33820 that is, N is one of 32, 64, 128, or, if EXTENDED is false, 16 or 33821 greater than 128 and a multiple of 32. 33822 33823 -- Target Hook: bool TARGET_FLOATN_BUILTIN_P (int FUNC) 33824 Define this to return true if the '_FloatN' and '_FloatNx' built-in 33825 functions should implicitly enable the built-in function without 33826 the '__builtin_' prefix in addition to the normal built-in function 33827 with the '__builtin_' prefix. The default is to only enable 33828 built-in functions without the '__builtin_' prefix for the GNU C 33829 langauge. In strict ANSI/ISO mode, the built-in function without 33830 the '__builtin_' prefix is not enabled. The argument 'FUNC' is the 33831 'enum built_in_function' id of the function to be enabled. 33832 33833 -- Target Hook: bool TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P 33834 (machine_mode MODE) 33835 Define this to return nonzero for machine modes for which the port 33836 has small register classes. If this target hook returns nonzero 33837 for a given MODE, the compiler will try to minimize the lifetime of 33838 registers in MODE. The hook may be called with 'VOIDmode' as 33839 argument. In this case, the hook is expected to return nonzero if 33840 it returns nonzero for any mode. 33841 33842 On some machines, it is risky to let hard registers live across 33843 arbitrary insns. Typically, these machines have instructions that 33844 require values to be in specific registers (like an accumulator), 33845 and reload will fail if the required hard register is used for 33846 another purpose across such an insn. 33847 33848 Passes before reload do not know which hard registers will be used 33849 in an instruction, but the machine modes of the registers set or 33850 used in the instruction are already known. And for some machines, 33851 register classes are small for, say, integer registers but not for 33852 floating point registers. For example, the AMD x86-64 architecture 33853 requires specific registers for the legacy x86 integer 33854 instructions, but there are many SSE registers for floating point 33855 operations. On such targets, a good strategy may be to return 33856 nonzero from this hook for 'INTEGRAL_MODE_P' machine modes but zero 33857 for the SSE register classes. 33858 33859 The default version of this hook returns false for any mode. It is 33860 always safe to redefine this hook to return with a nonzero value. 33861 But if you unnecessarily define it, you will reduce the amount of 33862 optimizations that can be performed in some cases. If you do not 33863 define this hook to return a nonzero value when it is required, the 33864 compiler will run out of spill registers and print a fatal error 33865 message. 33866 33867 33868File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling 33869 3387018.9.8 How Scalar Function Values Are Returned 33871---------------------------------------------- 33872 33873This section discusses the macros that control returning scalars as 33874values--values that can fit in registers. 33875 33876 -- Target Hook: rtx TARGET_FUNCTION_VALUE (const_tree RET_TYPE, 33877 const_tree FN_DECL_OR_TYPE, bool OUTGOING) 33878 33879 Define this to return an RTX representing the place where a 33880 function returns or receives a value of data type RET_TYPE, a tree 33881 node representing a data type. FN_DECL_OR_TYPE is a tree node 33882 representing 'FUNCTION_DECL' or 'FUNCTION_TYPE' of a function being 33883 called. If OUTGOING is false, the hook should compute the register 33884 in which the caller will see the return value. Otherwise, the hook 33885 should return an RTX representing the place where a function 33886 returns a value. 33887 33888 On many machines, only 'TYPE_MODE (RET_TYPE)' is relevant. 33889 (Actually, on most machines, scalar values are returned in the same 33890 place regardless of mode.) The value of the expression is usually 33891 a 'reg' RTX for the hard register where the return value is stored. 33892 The value can also be a 'parallel' RTX, if the return value is in 33893 multiple places. See 'TARGET_FUNCTION_ARG' for an explanation of 33894 the 'parallel' form. Note that the callee will populate every 33895 location specified in the 'parallel', but if the first element of 33896 the 'parallel' contains the whole return value, callers will use 33897 that element as the canonical location and ignore the others. The 33898 m68k port uses this type of 'parallel' to return pointers in both 33899 '%a0' (the canonical location) and '%d0'. 33900 33901 If 'TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply 33902 the same promotion rules specified in 'PROMOTE_MODE' if VALTYPE is 33903 a scalar type. 33904 33905 If the precise function being called is known, FUNC is a tree node 33906 ('FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This 33907 makes it possible to use a different value-returning convention for 33908 specific functions when all their calls are known. 33909 33910 Some target machines have "register windows" so that the register 33911 in which a function returns its value is not the same as the one in 33912 which the caller sees the value. For such machines, you should 33913 return different RTX depending on OUTGOING. 33914 33915 'TARGET_FUNCTION_VALUE' is not used for return values with 33916 aggregate data types, because these are returned in another way. 33917 See 'TARGET_STRUCT_VALUE_RTX' and related macros, below. 33918 33919 -- Macro: FUNCTION_VALUE (VALTYPE, FUNC) 33920 This macro has been deprecated. Use 'TARGET_FUNCTION_VALUE' for a 33921 new target instead. 33922 33923 -- Macro: LIBCALL_VALUE (MODE) 33924 A C expression to create an RTX representing the place where a 33925 library function returns a value of mode MODE. 33926 33927 Note that "library function" in this context means a compiler 33928 support routine, used to perform arithmetic, whose name is known 33929 specially by the compiler and was not mentioned in the C code being 33930 compiled. 33931 33932 -- Target Hook: rtx TARGET_LIBCALL_VALUE (machine_mode MODE, const_rtx 33933 FUN) 33934 Define this hook if the back-end needs to know the name of the 33935 libcall function in order to determine where the result should be 33936 returned. 33937 33938 The mode of the result is given by MODE and the name of the called 33939 library function is given by FUN. The hook should return an RTX 33940 representing the place where the library function result will be 33941 returned. 33942 33943 If this hook is not defined, then LIBCALL_VALUE will be used. 33944 33945 -- Macro: FUNCTION_VALUE_REGNO_P (REGNO) 33946 A C expression that is nonzero if REGNO is the number of a hard 33947 register in which the values of called function may come back. 33948 33949 A register whose use for returning values is limited to serving as 33950 the second of a pair (for a value of type 'double', say) need not 33951 be recognized by this macro. So for most machines, this definition 33952 suffices: 33953 33954 #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) 33955 33956 If the machine has register windows, so that the caller and the 33957 called function use different registers for the return value, this 33958 macro should recognize only the caller's register numbers. 33959 33960 This macro has been deprecated. Use 33961 'TARGET_FUNCTION_VALUE_REGNO_P' for a new target instead. 33962 33963 -- Target Hook: bool TARGET_FUNCTION_VALUE_REGNO_P (const unsigned int 33964 REGNO) 33965 A target hook that return 'true' if REGNO is the number of a hard 33966 register in which the values of called function may come back. 33967 33968 A register whose use for returning values is limited to serving as 33969 the second of a pair (for a value of type 'double', say) need not 33970 be recognized by this target hook. 33971 33972 If the machine has register windows, so that the caller and the 33973 called function use different registers for the return value, this 33974 target hook should recognize only the caller's register numbers. 33975 33976 If this hook is not defined, then FUNCTION_VALUE_REGNO_P will be 33977 used. 33978 33979 -- Macro: APPLY_RESULT_SIZE 33980 Define this macro if 'untyped_call' and 'untyped_return' need more 33981 space than is implied by 'FUNCTION_VALUE_REGNO_P' for saving and 33982 restoring an arbitrary return value. 33983 33984 -- Target Hook: bool TARGET_OMIT_STRUCT_RETURN_REG 33985 Normally, when a function returns a structure by memory, the 33986 address is passed as an invisible pointer argument, but the 33987 compiler also arranges to return the address from the function like 33988 it would a normal pointer return value. Define this to true if 33989 that behavior is undesirable on your target. 33990 33991 -- Target Hook: bool TARGET_RETURN_IN_MSB (const_tree TYPE) 33992 This hook should return true if values of type TYPE are returned at 33993 the most significant end of a register (in other words, if they are 33994 padded at the least significant end). You can assume that TYPE is 33995 returned in a register; the caller is required to check this. 33996 33997 Note that the register provided by 'TARGET_FUNCTION_VALUE' must be 33998 able to hold the complete return value. For example, if a 1-, 2- 33999 or 3-byte structure is returned at the most significant end of a 34000 4-byte register, 'TARGET_FUNCTION_VALUE' should provide an 'SImode' 34001 rtx. 34002 34003 34004File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling 34005 3400618.9.9 How Large Values Are Returned 34007------------------------------------ 34008 34009When a function value's mode is 'BLKmode' (and in some other cases), the 34010value is not returned according to 'TARGET_FUNCTION_VALUE' (*note Scalar 34011Return::). Instead, the caller passes the address of a block of memory 34012in which the value should be stored. This address is called the 34013"structure value address". 34014 34015 This section describes how to control returning structure values in 34016memory. 34017 34018 -- Target Hook: bool TARGET_RETURN_IN_MEMORY (const_tree TYPE, 34019 const_tree FNTYPE) 34020 This target hook should return a nonzero value to say to return the 34021 function value in memory, just as large structures are always 34022 returned. Here TYPE will be the data type of the value, and FNTYPE 34023 will be the type of the function doing the returning, or 'NULL' for 34024 libcalls. 34025 34026 Note that values of mode 'BLKmode' must be explicitly handled by 34027 this function. Also, the option '-fpcc-struct-return' takes effect 34028 regardless of this macro. On most systems, it is possible to leave 34029 the hook undefined; this causes a default definition to be used, 34030 whose value is the constant 1 for 'BLKmode' values, and 0 34031 otherwise. 34032 34033 Do not use this hook to indicate that structures and unions should 34034 always be returned in memory. You should instead use 34035 'DEFAULT_PCC_STRUCT_RETURN' to indicate this. 34036 34037 -- Macro: DEFAULT_PCC_STRUCT_RETURN 34038 Define this macro to be 1 if all structure and union return values 34039 must be in memory. Since this results in slower code, this should 34040 be defined only if needed for compatibility with other compilers or 34041 with an ABI. If you define this macro to be 0, then the 34042 conventions used for structure and union return values are decided 34043 by the 'TARGET_RETURN_IN_MEMORY' target hook. 34044 34045 If not defined, this defaults to the value 1. 34046 34047 -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING) 34048 This target hook should return the location of the structure value 34049 address (normally a 'mem' or 'reg'), or 0 if the address is passed 34050 as an "invisible" first argument. Note that FNDECL may be 'NULL', 34051 for libcalls. You do not need to define this target hook if the 34052 address is always passed as an "invisible" first argument. 34053 34054 On some architectures the place where the structure value address 34055 is found by the called function is not the same place that the 34056 caller put it. This can be due to register windows, or it could be 34057 because the function prologue moves it to a different place. 34058 INCOMING is '1' or '2' when the location is needed in the context 34059 of the called function, and '0' in the context of the caller. 34060 34061 If INCOMING is nonzero and the address is to be found on the stack, 34062 return a 'mem' which refers to the frame pointer. If INCOMING is 34063 '2', the result is being used to fetch the structure value address 34064 at the beginning of a function. If you need to emit adjusting 34065 code, you should do it at this point. 34066 34067 -- Macro: PCC_STATIC_STRUCT_RETURN 34068 Define this macro if the usual system convention on the target 34069 machine for returning structures and unions is for the called 34070 function to return the address of a static variable containing the 34071 value. 34072 34073 Do not define this if the usual system convention is for the caller 34074 to pass an address to the subroutine. 34075 34076 This macro has effect in '-fpcc-struct-return' mode, but it does 34077 nothing when you use '-freg-struct-return' mode. 34078 34079 -- Target Hook: fixed_size_mode TARGET_GET_RAW_RESULT_MODE (int REGNO) 34080 This target hook returns the mode to be used when accessing raw 34081 return registers in '__builtin_return'. Define this macro if the 34082 value in REG_RAW_MODE is not correct. 34083 34084 -- Target Hook: fixed_size_mode TARGET_GET_RAW_ARG_MODE (int REGNO) 34085 This target hook returns the mode to be used when accessing raw 34086 argument registers in '__builtin_apply_args'. Define this macro if 34087 the value in REG_RAW_MODE is not correct. 34088 34089 -- Target Hook: bool TARGET_EMPTY_RECORD_P (const_tree TYPE) 34090 This target hook returns true if the type is an empty record. The 34091 default is to return 'false'. 34092 34093 -- Target Hook: void TARGET_WARN_PARAMETER_PASSING_ABI 34094 (cumulative_args_t CA, tree TYPE) 34095 This target hook warns about the change in empty class parameter 34096 passing ABI. 34097 34098 34099File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling 34100 3410118.9.10 Caller-Saves Register Allocation 34102---------------------------------------- 34103 34104If you enable it, GCC can save registers around function calls. This 34105makes it possible to use call-clobbered registers to hold variables that 34106must live across calls. 34107 34108 -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS) 34109 A C expression specifying which mode is required for saving NREGS 34110 of a pseudo-register in call-clobbered hard register REGNO. If 34111 REGNO is unsuitable for caller save, 'VOIDmode' should be returned. 34112 For most machines this macro need not be defined since GCC will 34113 select the smallest suitable mode. 34114 34115 34116File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling 34117 3411818.9.11 Function Entry and Exit 34119------------------------------- 34120 34121This section describes the macros that output function entry 34122("prologue") and exit ("epilogue") code. 34123 34124 -- Target Hook: void TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY (FILE 34125 *FILE, unsigned HOST_WIDE_INT PATCH_AREA_SIZE, bool RECORD_P) 34126 Generate a patchable area at the function start, consisting of 34127 PATCH_AREA_SIZE NOP instructions. If the target supports named 34128 sections and if RECORD_P is true, insert a pointer to the current 34129 location in the table of patchable functions. The default 34130 implementation of the hook places the table of pointers in the 34131 special section named '__patchable_function_entries'. 34132 34133 -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE) 34134 If defined, a function that outputs the assembler code for entry to 34135 a function. The prologue is responsible for setting up the stack 34136 frame, initializing the frame pointer register, saving registers 34137 that must be saved, and allocating SIZE additional bytes of storage 34138 for the local variables. FILE is a stdio stream to which the 34139 assembler code should be output. 34140 34141 The label for the beginning of the function need not be output by 34142 this macro. That has already been done when the macro is run. 34143 34144 To determine which registers to save, the macro can refer to the 34145 array 'regs_ever_live': element R is nonzero if hard register R is 34146 used anywhere within the function. This implies the function 34147 prologue should save register R, provided it is not one of the 34148 call-used registers. ('TARGET_ASM_FUNCTION_EPILOGUE' must likewise 34149 use 'regs_ever_live'.) 34150 34151 On machines that have "register windows", the function entry code 34152 does not save on the stack the registers that are in the windows, 34153 even if they are supposed to be preserved by function calls; 34154 instead it takes appropriate steps to "push" the register stack, if 34155 any non-call-used registers are used in the function. 34156 34157 On machines where functions may or may not have frame-pointers, the 34158 function entry code must vary accordingly; it must set up the frame 34159 pointer if one is wanted, and not otherwise. To determine whether 34160 a frame pointer is in wanted, the macro can refer to the variable 34161 'frame_pointer_needed'. The variable's value will be 1 at run time 34162 in a function that needs a frame pointer. *Note Elimination::. 34163 34164 The function entry code is responsible for allocating any stack 34165 space required for the function. This stack space consists of the 34166 regions listed below. In most cases, these regions are allocated 34167 in the order listed, with the last listed region closest to the top 34168 of the stack (the lowest address if 'STACK_GROWS_DOWNWARD' is 34169 defined, and the highest address if it is not defined). You can 34170 use a different order for a machine if doing so is more convenient 34171 or required for compatibility reasons. Except in cases where 34172 required by standard or by a debugger, there is no reason why the 34173 stack layout used by GCC need agree with that used by other 34174 compilers for a machine. 34175 34176 -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE) 34177 If defined, a function that outputs assembler code at the end of a 34178 prologue. This should be used when the function prologue is being 34179 emitted as RTL, and you have some extra assembler that needs to be 34180 emitted. *Note prologue instruction pattern::. 34181 34182 -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE) 34183 If defined, a function that outputs assembler code at the start of 34184 an epilogue. This should be used when the function epilogue is 34185 being emitted as RTL, and you have some extra assembler that needs 34186 to be emitted. *Note epilogue instruction pattern::. 34187 34188 -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE) 34189 If defined, a function that outputs the assembler code for exit 34190 from a function. The epilogue is responsible for restoring the 34191 saved registers and stack pointer to their values when the function 34192 was called, and returning control to the caller. This macro takes 34193 the same argument as the macro 'TARGET_ASM_FUNCTION_PROLOGUE', and 34194 the registers to restore are determined from 'regs_ever_live' and 34195 'CALL_USED_REGISTERS' in the same way. 34196 34197 On some machines, there is a single instruction that does all the 34198 work of returning from the function. On these machines, give that 34199 instruction the name 'return' and do not define the macro 34200 'TARGET_ASM_FUNCTION_EPILOGUE' at all. 34201 34202 Do not define a pattern named 'return' if you want the 34203 'TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target 34204 switches to control whether return instructions or epilogues are 34205 used, define a 'return' pattern with a validity condition that 34206 tests the target switches appropriately. If the 'return' pattern's 34207 validity condition is false, epilogues will be used. 34208 34209 On machines where functions may or may not have frame-pointers, the 34210 function exit code must vary accordingly. Sometimes the code for 34211 these two cases is completely different. To determine whether a 34212 frame pointer is wanted, the macro can refer to the variable 34213 'frame_pointer_needed'. The variable's value will be 1 when 34214 compiling a function that needs a frame pointer. 34215 34216 Normally, 'TARGET_ASM_FUNCTION_PROLOGUE' and 34217 'TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially. 34218 The C variable 'current_function_is_leaf' is nonzero for such a 34219 function. *Note Leaf Functions::. 34220 34221 On some machines, some functions pop their arguments on exit while 34222 others leave that for the caller to do. For example, the 68020 34223 when given '-mrtd' pops arguments in functions that take a fixed 34224 number of arguments. 34225 34226 Your definition of the macro 'RETURN_POPS_ARGS' decides which 34227 functions pop their own arguments. 'TARGET_ASM_FUNCTION_EPILOGUE' 34228 needs to know what was decided. The number of bytes of the current 34229 function's arguments that this function should pop is available in 34230 'crtl->args.pops_args'. *Note Scalar Return::. 34231 34232 * A region of 'crtl->args.pretend_args_size' bytes of uninitialized 34233 space just underneath the first argument arriving on the stack. 34234 (This may not be at the very start of the allocated stack region if 34235 the calling sequence has pushed anything else since pushing the 34236 stack arguments. But usually, on such machines, nothing else has 34237 been pushed yet, because the function prologue itself does all the 34238 pushing.) This region is used on machines where an argument may be 34239 passed partly in registers and partly in memory, and, in some cases 34240 to support the features in '<stdarg.h>'. 34241 34242 * An area of memory used to save certain registers used by the 34243 function. The size of this area, which may also include space for 34244 such things as the return address and pointers to previous stack 34245 frames, is machine-specific and usually depends on which registers 34246 have been used in the function. Machines with register windows 34247 often do not require a save area. 34248 34249 * A region of at least SIZE bytes, possibly rounded up to an 34250 allocation boundary, to contain the local variables of the 34251 function. On some machines, this region and the save area may 34252 occur in the opposite order, with the save area closer to the top 34253 of the stack. 34254 34255 * Optionally, when 'ACCUMULATE_OUTGOING_ARGS' is defined, a region of 34256 'crtl->outgoing_args_size' bytes to be used for outgoing argument 34257 lists of the function. *Note Stack Arguments::. 34258 34259 -- Macro: EXIT_IGNORE_STACK 34260 Define this macro as a C expression that is nonzero if the return 34261 instruction or the function epilogue ignores the value of the stack 34262 pointer; in other words, if it is safe to delete an instruction to 34263 adjust the stack pointer before a return from the function. The 34264 default is 0. 34265 34266 Note that this macro's value is relevant only for functions for 34267 which frame pointers are maintained. It is never safe to delete a 34268 final stack adjustment in a function that has no frame pointer, and 34269 the compiler knows this regardless of 'EXIT_IGNORE_STACK'. 34270 34271 -- Macro: EPILOGUE_USES (REGNO) 34272 Define this macro as a C expression that is nonzero for registers 34273 that are used by the epilogue or the 'return' pattern. The stack 34274 and frame pointer registers are already assumed to be used as 34275 needed. 34276 34277 -- Macro: EH_USES (REGNO) 34278 Define this macro as a C expression that is nonzero for registers 34279 that are used by the exception handling mechanism, and so should be 34280 considered live on entry to an exception edge. 34281 34282 -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree 34283 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT VCALL_OFFSET, 34284 tree FUNCTION) 34285 A function that outputs the assembler code for a thunk function, 34286 used to implement C++ virtual function calls with multiple 34287 inheritance. The thunk acts as a wrapper around a virtual 34288 function, adjusting the implicit object parameter before handing 34289 control off to the real function. 34290 34291 First, emit code to add the integer DELTA to the location that 34292 contains the incoming first argument. Assume that this argument 34293 contains a pointer, and is the one used to pass the 'this' pointer 34294 in C++. This is the incoming argument _before_ the function 34295 prologue, e.g. '%o0' on a sparc. The addition must preserve the 34296 values of all other incoming arguments. 34297 34298 Then, if VCALL_OFFSET is nonzero, an additional adjustment should 34299 be made after adding 'delta'. In particular, if P is the adjusted 34300 pointer, the following adjustment should be made: 34301 34302 p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)] 34303 34304 After the additions, emit code to jump to FUNCTION, which is a 34305 'FUNCTION_DECL'. This is a direct pure jump, not a call, and does 34306 not touch the return address. Hence returning from FUNCTION will 34307 return to whoever called the current 'thunk'. 34308 34309 The effect must be as if FUNCTION had been called directly with the 34310 adjusted first argument. This macro is responsible for emitting 34311 all of the code for a thunk function; 34312 'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE' 34313 are not invoked. 34314 34315 The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already 34316 been extracted from it.) It might possibly be useful on some 34317 targets, but probably not. 34318 34319 If you do not define this macro, the target-independent code in the 34320 C++ front end will generate a less efficient heavyweight thunk that 34321 calls FUNCTION instead of jumping to it. The generic approach does 34322 not support varargs. 34323 34324 -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (const_tree 34325 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT VCALL_OFFSET, 34326 const_tree FUNCTION) 34327 A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would be 34328 able to output the assembler code for the thunk function specified 34329 by the arguments it is passed, and false otherwise. In the latter 34330 case, the generic approach will be used by the C++ front end, with 34331 the limitations previously exposed. 34332 34333 34334File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling 34335 3433618.9.12 Generating Code for Profiling 34337------------------------------------- 34338 34339These macros will help you generate code for profiling. 34340 34341 -- Macro: FUNCTION_PROFILER (FILE, LABELNO) 34342 A C statement or compound statement to output to FILE some 34343 assembler code to call the profiling subroutine 'mcount'. 34344 34345 The details of how 'mcount' expects to be called are determined by 34346 your operating system environment, not by GCC. To figure them out, 34347 compile a small program for profiling using the system's installed 34348 C compiler and look at the assembler code that results. 34349 34350 Older implementations of 'mcount' expect the address of a counter 34351 variable to be loaded into some register. The name of this 34352 variable is 'LP' followed by the number LABELNO, so you would 34353 generate the name using 'LP%d' in a 'fprintf'. 34354 34355 -- Macro: PROFILE_HOOK 34356 A C statement or compound statement to output to FILE some assembly 34357 code to call the profiling subroutine 'mcount' even the target does 34358 not support profiling. 34359 34360 -- Macro: NO_PROFILE_COUNTERS 34361 Define this macro to be an expression with a nonzero value if the 34362 'mcount' subroutine on your system does not need a counter variable 34363 allocated for each function. This is true for almost all modern 34364 implementations. If you define this macro, you must not use the 34365 LABELNO argument to 'FUNCTION_PROFILER'. 34366 34367 -- Macro: PROFILE_BEFORE_PROLOGUE 34368 Define this macro if the code for function profiling should come 34369 before the function prologue. Normally, the profiling code comes 34370 after. 34371 34372 -- Target Hook: bool TARGET_KEEP_LEAF_WHEN_PROFILED (void) 34373 This target hook returns true if the target wants the leaf flag for 34374 the current function to stay true even if it calls mcount. This 34375 might make sense for targets using the leaf flag only to determine 34376 whether a stack frame needs to be generated or not and for which 34377 the call to mcount is generated before the function prologue. 34378 34379 34380File: gccint.info, Node: Tail Calls, Next: Shrink-wrapping separate components, Prev: Profiling, Up: Stack and Calling 34381 3438218.9.13 Permitting tail calls 34383----------------------------- 34384 34385 -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree 34386 EXP) 34387 True if it is OK to do sibling call optimization for the specified 34388 call expression EXP. DECL will be the called function, or 'NULL' 34389 if this is an indirect call. 34390 34391 It is not uncommon for limitations of calling conventions to 34392 prevent tail calls to functions outside the current unit of 34393 translation, or during PIC compilation. The hook is used to 34394 enforce these restrictions, as the 'sibcall' md pattern can not 34395 fail, or fall over to a "normal" call. The criteria for successful 34396 sibling call optimization may vary greatly between different 34397 architectures. 34398 34399 -- Target Hook: void TARGET_EXTRA_LIVE_ON_ENTRY (bitmap REGS) 34400 Add any hard registers to REGS that are live on entry to the 34401 function. This hook only needs to be defined to provide registers 34402 that cannot be found by examination of FUNCTION_ARG_REGNO_P, the 34403 callee saved registers, STATIC_CHAIN_INCOMING_REGNUM, 34404 STATIC_CHAIN_REGNUM, TARGET_STRUCT_VALUE_RTX, FRAME_POINTER_REGNUM, 34405 EH_USES, FRAME_POINTER_REGNUM, ARG_POINTER_REGNUM, and the 34406 PIC_OFFSET_TABLE_REGNUM. 34407 34408 -- Target Hook: void TARGET_SET_UP_BY_PROLOGUE (struct 34409 hard_reg_set_container *) 34410 This hook should add additional registers that are computed by the 34411 prologue to the hard regset for shrink-wrapping optimization 34412 purposes. 34413 34414 -- Target Hook: bool TARGET_WARN_FUNC_RETURN (tree) 34415 True if a function's return statements should be checked for 34416 matching the function's return type. This includes checking for 34417 falling off the end of a non-void function. Return false if no 34418 such check should be made. 34419 34420 34421File: gccint.info, Node: Shrink-wrapping separate components, Next: Stack Smashing Protection, Prev: Tail Calls, Up: Stack and Calling 34422 3442318.9.14 Shrink-wrapping separate components 34424------------------------------------------- 34425 34426The prologue may perform a variety of target dependent tasks such as 34427saving callee-saved registers, saving the return address, aligning the 34428stack, creating a stack frame, initializing the PIC register, setting up 34429the static chain, etc. 34430 34431 On some targets some of these tasks may be independent of others and 34432thus may be shrink-wrapped separately. These independent tasks are 34433referred to as components and are handled generically by the target 34434independent parts of GCC. 34435 34436 Using the following hooks those prologue or epilogue components can be 34437shrink-wrapped separately, so that the initialization (and possibly 34438teardown) those components do is not done as frequently on execution 34439paths where this would unnecessary. 34440 34441 What exactly those components are is up to the target code; the generic 34442code treats them abstractly, as a bit in an 'sbitmap'. These 'sbitmap's 34443are allocated by the 'shrink_wrap.get_separate_components' and 34444'shrink_wrap.components_for_bb' hooks, and deallocated by the generic 34445code. 34446 34447 -- Target Hook: sbitmap TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS 34448 (void) 34449 This hook should return an 'sbitmap' with the bits set for those 34450 components that can be separately shrink-wrapped in the current 34451 function. Return 'NULL' if the current function should not get any 34452 separate shrink-wrapping. Don't define this hook if it would 34453 always return 'NULL'. If it is defined, the other hooks in this 34454 group have to be defined as well. 34455 34456 -- Target Hook: sbitmap TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB 34457 (basic_block) 34458 This hook should return an 'sbitmap' with the bits set for those 34459 components where either the prologue component has to be executed 34460 before the 'basic_block', or the epilogue component after it, or 34461 both. 34462 34463 -- Target Hook: void TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS (sbitmap 34464 COMPONENTS, edge E, sbitmap EDGE_COMPONENTS, bool IS_PROLOGUE) 34465 This hook should clear the bits in the COMPONENTS bitmap for those 34466 components in EDGE_COMPONENTS that the target cannot handle on edge 34467 E, where IS_PROLOGUE says if this is for a prologue or an epilogue 34468 instead. 34469 34470 -- Target Hook: void TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS 34471 (sbitmap) 34472 Emit prologue insns for the components indicated by the parameter. 34473 34474 -- Target Hook: void TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS 34475 (sbitmap) 34476 Emit epilogue insns for the components indicated by the parameter. 34477 34478 -- Target Hook: void TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS 34479 (sbitmap) 34480 Mark the components in the parameter as handled, so that the 34481 'prologue' and 'epilogue' named patterns know to ignore those 34482 components. The target code should not hang on to the 'sbitmap', 34483 it will be deleted after this call. 34484 34485 34486File: gccint.info, Node: Stack Smashing Protection, Next: Miscellaneous Register Hooks, Prev: Shrink-wrapping separate components, Up: Stack and Calling 34487 3448818.9.15 Stack smashing protection 34489--------------------------------- 34490 34491 -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void) 34492 This hook returns a 'DECL' node for the external variable to use 34493 for the stack protection guard. This variable is initialized by 34494 the runtime to some random value and is used to initialize the 34495 guard value that is placed at the top of the local stack frame. 34496 The type of this variable must be 'ptr_type_node'. 34497 34498 The default version of this hook creates a variable called 34499 '__stack_chk_guard', which is normally defined in 'libgcc2.c'. 34500 34501 -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void) 34502 This hook returns a 'CALL_EXPR' that alerts the runtime that the 34503 stack protect guard variable has been modified. This expression 34504 should involve a call to a 'noreturn' function. 34505 34506 The default version of this hook invokes a function called 34507 '__stack_chk_fail', taking no arguments. This function is normally 34508 defined in 'libgcc2.c'. 34509 34510 -- Target Hook: bool TARGET_STACK_PROTECT_RUNTIME_ENABLED_P (void) 34511 Returns true if the target wants GCC's default stack protect 34512 runtime support, otherwise return false. The default 34513 implementation always returns true. 34514 34515 -- Common Target Hook: bool TARGET_SUPPORTS_SPLIT_STACK (bool REPORT, 34516 struct gcc_options *OPTS) 34517 Whether this target supports splitting the stack when the options 34518 described in OPTS have been passed. This is called after options 34519 have been parsed, so the target may reject splitting the stack in 34520 some configurations. The default version of this hook returns 34521 false. If REPORT is true, this function may issue a warning or 34522 error; if REPORT is false, it must simply return a value 34523 34524 34525File: gccint.info, Node: Miscellaneous Register Hooks, Prev: Stack Smashing Protection, Up: Stack and Calling 34526 3452718.9.16 Miscellaneous register hooks 34528------------------------------------ 34529 34530 -- Target Hook: bool TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS 34531 Set to true if each call that binds to a local definition 34532 explicitly clobbers or sets all non-fixed registers modified by 34533 performing the call. That is, by the call pattern itself, or by 34534 code that might be inserted by the linker (e.g. stubs, veneers, 34535 branch islands), but not including those modifiable by the callee. 34536 The affected registers may be mentioned explicitly in the call 34537 pattern, or included as clobbers in CALL_INSN_FUNCTION_USAGE. The 34538 default version of this hook is set to false. The purpose of this 34539 hook is to enable the fipa-ra optimization. 34540 34541 34542File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros 34543 3454418.10 Implementing the Varargs Macros 34545===================================== 34546 34547GCC comes with an implementation of '<varargs.h>' and '<stdarg.h>' that 34548work without change on machines that pass arguments on the stack. Other 34549machines require their own implementations of varargs, and the two 34550machine independent header files must have conditionals to include it. 34551 34552 ISO '<stdarg.h>' differs from traditional '<varargs.h>' mainly in the 34553calling convention for 'va_start'. The traditional implementation takes 34554just one argument, which is the variable in which to store the argument 34555pointer. The ISO implementation of 'va_start' takes an additional 34556second argument. The user is supposed to write the last named argument 34557of the function here. 34558 34559 However, 'va_start' should not use this argument. The way to find the 34560end of the named arguments is with the built-in functions described 34561below. 34562 34563 -- Macro: __builtin_saveregs () 34564 Use this built-in function to save the argument registers in memory 34565 so that the varargs mechanism can access them. Both ISO and 34566 traditional versions of 'va_start' must use '__builtin_saveregs', 34567 unless you use 'TARGET_SETUP_INCOMING_VARARGS' (see below) instead. 34568 34569 On some machines, '__builtin_saveregs' is open-coded under the 34570 control of the target hook 'TARGET_EXPAND_BUILTIN_SAVEREGS'. On 34571 other machines, it calls a routine written in assembler language, 34572 found in 'libgcc2.c'. 34573 34574 Code generated for the call to '__builtin_saveregs' appears at the 34575 beginning of the function, as opposed to where the call to 34576 '__builtin_saveregs' is written, regardless of what the code is. 34577 This is because the registers must be saved before the function 34578 starts to use them for its own purposes. 34579 34580 -- Macro: __builtin_next_arg (LASTARG) 34581 This builtin returns the address of the first anonymous stack 34582 argument, as type 'void *'. If 'ARGS_GROW_DOWNWARD', it returns 34583 the address of the location above the first anonymous stack 34584 argument. Use it in 'va_start' to initialize the pointer for 34585 fetching arguments from the stack. Also use it in 'va_start' to 34586 verify that the second parameter LASTARG is the last named argument 34587 of the current function. 34588 34589 -- Macro: __builtin_classify_type (OBJECT) 34590 Since each machine has its own conventions for which data types are 34591 passed in which kind of register, your implementation of 'va_arg' 34592 has to embody these conventions. The easiest way to categorize the 34593 specified data type is to use '__builtin_classify_type' together 34594 with 'sizeof' and '__alignof__'. 34595 34596 '__builtin_classify_type' ignores the value of OBJECT, considering 34597 only its data type. It returns an integer describing what kind of 34598 type that is--integer, floating, pointer, structure, and so on. 34599 34600 The file 'typeclass.h' defines an enumeration that you can use to 34601 interpret the values of '__builtin_classify_type'. 34602 34603 These machine description macros help implement varargs: 34604 34605 -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void) 34606 If defined, this hook produces the machine-specific code for a call 34607 to '__builtin_saveregs'. This code will be moved to the very 34608 beginning of the function, before any parameter access are made. 34609 The return value of this function should be an RTX that contains 34610 the value to use as the return of '__builtin_saveregs'. 34611 34612 -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (cumulative_args_t 34613 ARGS_SO_FAR, machine_mode MODE, tree TYPE, int 34614 *PRETEND_ARGS_SIZE, int SECOND_TIME) 34615 This target hook offers an alternative to using 34616 '__builtin_saveregs' and defining the hook 34617 'TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous 34618 register arguments into the stack so that all the arguments appear 34619 to have been passed consecutively on the stack. Once this is done, 34620 you can use the standard implementation of varargs that works for 34621 machines that pass all their arguments on the stack. 34622 34623 The argument ARGS_SO_FAR points to the 'CUMULATIVE_ARGS' data 34624 structure, containing the values that are obtained after processing 34625 the named arguments. The arguments MODE and TYPE describe the last 34626 named argument--its machine mode and its data type as a tree node. 34627 34628 The target hook should do two things: first, push onto the stack 34629 all the argument registers _not_ used for the named arguments, and 34630 second, store the size of the data thus pushed into the 34631 'int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value 34632 that you store here will serve as additional offset for setting up 34633 the stack frame. 34634 34635 Because you must generate code to push the anonymous arguments at 34636 compile time without knowing their data types, 34637 'TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that 34638 have just a single category of argument register and use it 34639 uniformly for all data types. 34640 34641 If the argument SECOND_TIME is nonzero, it means that the arguments 34642 of the function are being analyzed for the second time. This 34643 happens for an inline function, which is not actually compiled 34644 until the end of the source file. The hook 34645 'TARGET_SETUP_INCOMING_VARARGS' should not generate any 34646 instructions in this case. 34647 34648 -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (cumulative_args_t 34649 CA) 34650 Define this hook to return 'true' if the location where a function 34651 argument is passed depends on whether or not it is a named 34652 argument. 34653 34654 This hook controls how the NAMED argument to 'TARGET_FUNCTION_ARG' 34655 is set for varargs and stdarg functions. If this hook returns 34656 'true', the NAMED argument is always true for named arguments, and 34657 false for unnamed arguments. If it returns 'false', but 34658 'TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns 'true', then all 34659 arguments are treated as named. Otherwise, all named arguments 34660 except the last are treated as named. 34661 34662 You need not define this hook if it always returns 'false'. 34663 34664 -- Target Hook: void TARGET_CALL_ARGS (rtx, TREE) 34665 While generating RTL for a function call, this target hook is 34666 invoked once for each argument passed to the function, either a 34667 register returned by 'TARGET_FUNCTION_ARG' or a memory location. 34668 It is called just before the point where argument registers are 34669 stored. The type of the function to be called is also passed as 34670 the second argument; it is 'NULL_TREE' for libcalls. The 34671 'TARGET_END_CALL_ARGS' hook is invoked just after the code to copy 34672 the return reg has been emitted. This functionality can be used to 34673 perform special setup of call argument registers if a target needs 34674 it. For functions without arguments, the hook is called once with 34675 'pc_rtx' passed instead of an argument register. Most ports do not 34676 need to implement anything for this hook. 34677 34678 -- Target Hook: void TARGET_END_CALL_ARGS (void) 34679 This target hook is invoked while generating RTL for a function 34680 call, just after the point where the return reg is copied into a 34681 pseudo. It signals that all the call argument and return registers 34682 for the just emitted call are now no longer in use. Most ports do 34683 not need to implement anything for this hook. 34684 34685 -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED 34686 (cumulative_args_t CA) 34687 If you need to conditionally change ABIs so that one works with 34688 'TARGET_SETUP_INCOMING_VARARGS', but the other works like neither 34689 'TARGET_SETUP_INCOMING_VARARGS' nor 'TARGET_STRICT_ARGUMENT_NAMING' 34690 was defined, then define this hook to return 'true' if 34691 'TARGET_SETUP_INCOMING_VARARGS' is used, 'false' otherwise. 34692 Otherwise, you should not define this hook. 34693 34694 -- Target Hook: rtx TARGET_LOAD_BOUNDS_FOR_ARG (rtx SLOT, rtx ARG, rtx 34695 SLOT_NO) 34696 This hook is used by expand pass to emit insn to load bounds of ARG 34697 passed in SLOT. Expand pass uses this hook in case bounds of ARG 34698 are not passed in register. If SLOT is a memory, then bounds are 34699 loaded as for regular pointer loaded from memory. If SLOT is not a 34700 memory then SLOT_NO is an integer constant holding number of the 34701 target dependent special slot which should be used to obtain 34702 bounds. Hook returns RTX holding loaded bounds. 34703 34704 -- Target Hook: void TARGET_STORE_BOUNDS_FOR_ARG (rtx ARG, rtx SLOT, 34705 rtx BOUNDS, rtx SLOT_NO) 34706 This hook is used by expand pass to emit insns to store BOUNDS of 34707 ARG passed in SLOT. Expand pass uses this hook in case BOUNDS of 34708 ARG are not passed in register. If SLOT is a memory, then BOUNDS 34709 are stored as for regular pointer stored in memory. If SLOT is not 34710 a memory then SLOT_NO is an integer constant holding number of the 34711 target dependent special slot which should be used to store BOUNDS. 34712 34713 -- Target Hook: rtx TARGET_LOAD_RETURNED_BOUNDS (rtx SLOT) 34714 This hook is used by expand pass to emit insn to load bounds 34715 returned by function call in SLOT. Hook returns RTX holding loaded 34716 bounds. 34717 34718 -- Target Hook: void TARGET_STORE_RETURNED_BOUNDS (rtx SLOT, rtx 34719 BOUNDS) 34720 This hook is used by expand pass to emit insn to store BOUNDS 34721 returned by function call into SLOT. 34722 34723 -- Target Hook: rtx TARGET_CHKP_FUNCTION_VALUE_BOUNDS (const_tree 34724 RET_TYPE, const_tree FN_DECL_OR_TYPE, bool OUTGOING) 34725 Define this to return an RTX representing the place where a 34726 function returns bounds for returned pointers. Arguments meaning 34727 is similar to 'TARGET_FUNCTION_VALUE'. 34728 34729 -- Target Hook: void TARGET_SETUP_INCOMING_VARARG_BOUNDS 34730 (cumulative_args_t ARGS_SO_FAR, machine_mode MODE, tree TYPE, 34731 int *PRETEND_ARGS_SIZE, int SECOND_TIME) 34732 Use it to store bounds for anonymous register arguments stored into 34733 the stack. Arguments meaning is similar to 34734 'TARGET_SETUP_INCOMING_VARARGS'. 34735 34736 34737File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros 34738 3473918.11 Trampolines for Nested Functions 34740====================================== 34741 34742A "trampoline" is a small piece of code that is created at run time when 34743the address of a nested function is taken. It normally resides on the 34744stack, in the stack frame of the containing function. These macros tell 34745GCC how to generate code to allocate and initialize a trampoline. 34746 34747 The instructions in the trampoline must do two things: load a constant 34748address into the static chain register, and jump to the real address of 34749the nested function. On CISC machines such as the m68k, this requires 34750two instructions, a move immediate and a jump. Then the two addresses 34751exist in the trampoline as word-long immediate operands. On RISC 34752machines, it is often necessary to load each address into a register in 34753two parts. Then pieces of each address form separate immediate 34754operands. 34755 34756 The code generated to initialize the trampoline must store the variable 34757parts--the static chain value and the function address--into the 34758immediate operands of the instructions. On a CISC machine, this is 34759simply a matter of copying each address to a memory reference at the 34760proper offset from the start of the trampoline. On a RISC machine, it 34761may be necessary to take out pieces of the address and store them 34762separately. 34763 34764 -- Target Hook: void TARGET_ASM_TRAMPOLINE_TEMPLATE (FILE *F) 34765 This hook is called by 'assemble_trampoline_template' to output, on 34766 the stream F, assembler code for a block of data that contains the 34767 constant parts of a trampoline. This code should not include a 34768 label--the label is taken care of automatically. 34769 34770 If you do not define this hook, it means no template is needed for 34771 the target. Do not define this hook on systems where the block 34772 move code to copy the trampoline into place would be larger than 34773 the code to generate it on the spot. 34774 34775 -- Macro: TRAMPOLINE_SECTION 34776 Return the section into which the trampoline template is to be 34777 placed (*note Sections::). The default value is 34778 'readonly_data_section'. 34779 34780 -- Macro: TRAMPOLINE_SIZE 34781 A C expression for the size in bytes of the trampoline, as an 34782 integer. 34783 34784 -- Macro: TRAMPOLINE_ALIGNMENT 34785 Alignment required for trampolines, in bits. 34786 34787 If you don't define this macro, the value of 'FUNCTION_ALIGNMENT' 34788 is used for aligning trampolines. 34789 34790 -- Target Hook: void TARGET_TRAMPOLINE_INIT (rtx M_TRAMP, tree FNDECL, 34791 rtx STATIC_CHAIN) 34792 This hook is called to initialize a trampoline. M_TRAMP is an RTX 34793 for the memory block for the trampoline; FNDECL is the 34794 'FUNCTION_DECL' for the nested function; STATIC_CHAIN is an RTX for 34795 the static chain value that should be passed to the function when 34796 it is called. 34797 34798 If the target defines 'TARGET_ASM_TRAMPOLINE_TEMPLATE', then the 34799 first thing this hook should do is emit a block move into M_TRAMP 34800 from the memory block returned by 'assemble_trampoline_template'. 34801 Note that the block move need only cover the constant parts of the 34802 trampoline. If the target isolates the variable parts of the 34803 trampoline to the end, not all 'TRAMPOLINE_SIZE' bytes need be 34804 copied. 34805 34806 If the target requires any other actions, such as flushing caches 34807 or enabling stack execution, these actions should be performed 34808 after initializing the trampoline proper. 34809 34810 -- Target Hook: rtx TARGET_TRAMPOLINE_ADJUST_ADDRESS (rtx ADDR) 34811 This hook should perform any machine-specific adjustment in the 34812 address of the trampoline. Its argument contains the address of 34813 the memory block that was passed to 'TARGET_TRAMPOLINE_INIT'. In 34814 case the address to be used for a function call should be different 34815 from the address at which the template was stored, the different 34816 address should be returned; otherwise ADDR should be returned 34817 unchanged. If this hook is not defined, ADDR will be used for 34818 function calls. 34819 34820 -- Target Hook: int TARGET_CUSTOM_FUNCTION_DESCRIPTORS 34821 This hook should be defined to a power of 2 if the target will 34822 benefit from the use of custom descriptors for nested functions 34823 instead of the standard trampolines. Such descriptors are created 34824 at run time on the stack and made up of data only, but they are 34825 non-standard so the generated code must be prepared to deal with 34826 them. This hook should be defined to 0 if the target uses function 34827 descriptors for its standard calling sequence, like for example 34828 HP-PA or IA-64. Using descriptors for nested functions eliminates 34829 the need for trampolines that reside on the stack and require it to 34830 be made executable. 34831 34832 The value of the macro is used to parameterize the run-time 34833 identification scheme implemented to distinguish descriptors from 34834 function addresses: it gives the number of bytes by which their 34835 address is misaligned compared with function addresses. The value 34836 of 1 will generally work, unless it is already reserved by the 34837 target for another purpose, like for example on ARM. 34838 34839 Implementing trampolines is difficult on many machines because they 34840have separate instruction and data caches. Writing into a stack 34841location fails to clear the memory in the instruction cache, so when the 34842program jumps to that location, it executes the old contents. 34843 34844 Here are two possible solutions. One is to clear the relevant parts of 34845the instruction cache whenever a trampoline is set up. The other is to 34846make all trampolines identical, by having them jump to a standard 34847subroutine. The former technique makes trampoline execution faster; the 34848latter makes initialization faster. 34849 34850 To clear the instruction cache when a trampoline is initialized, define 34851the following macro. 34852 34853 -- Macro: CLEAR_INSN_CACHE (BEG, END) 34854 If defined, expands to a C expression clearing the _instruction 34855 cache_ in the specified interval. The definition of this macro 34856 would typically be a series of 'asm' statements. Both BEG and END 34857 are both pointer expressions. 34858 34859 To use a standard subroutine, define the following macro. In addition, 34860you must make sure that the instructions in a trampoline fill an entire 34861cache line with identical instructions, or else ensure that the 34862beginning of the trampoline code is always aligned at the same point in 34863its cache line. Look in 'm68k.h' as a guide. 34864 34865 -- Macro: TRANSFER_FROM_TRAMPOLINE 34866 Define this macro if trampolines need a special subroutine to do 34867 their work. The macro should expand to a series of 'asm' 34868 statements which will be compiled with GCC. They go in a library 34869 function named '__transfer_from_trampoline'. 34870 34871 If you need to avoid executing the ordinary prologue code of a 34872 compiled C function when you jump to the subroutine, you can do so 34873 by placing a special label of your own in the assembler code. Use 34874 one 'asm' statement to generate an assembler label, and another to 34875 make the label global. Then trampolines can use that label to jump 34876 directly to your special assembler code. 34877 34878 34879File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros 34880 3488118.12 Implicit Calls to Library Routines 34882======================================== 34883 34884Here is an explanation of implicit calls to library routines. 34885 34886 -- Macro: DECLARE_LIBRARY_RENAMES 34887 This macro, if defined, should expand to a piece of C code that 34888 will get expanded when compiling functions for libgcc.a. It can be 34889 used to provide alternate names for GCC's internal library 34890 functions if there are ABI-mandated names that the compiler should 34891 provide. 34892 34893 -- Target Hook: void TARGET_INIT_LIBFUNCS (void) 34894 This hook should declare additional library routines or rename 34895 existing ones, using the functions 'set_optab_libfunc' and 34896 'init_one_libfunc' defined in 'optabs.c'. 'init_optabs' calls this 34897 macro after initializing all the normal library routines. 34898 34899 The default is to do nothing. Most ports don't need to define this 34900 hook. 34901 34902 -- Target Hook: bool TARGET_LIBFUNC_GNU_PREFIX 34903 If false (the default), internal library routines start with two 34904 underscores. If set to true, these routines start with '__gnu_' 34905 instead. E.g., '__muldi3' changes to '__gnu_muldi3'. This 34906 currently only affects functions defined in 'libgcc2.c'. If this 34907 is set to true, the 'tm.h' file must also '#define 34908 LIBGCC2_GNU_PREFIX'. 34909 34910 -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON) 34911 This macro should return 'true' if the library routine that 34912 implements the floating point comparison operator COMPARISON in 34913 mode MODE will return a boolean, and FALSE if it will return a 34914 tristate. 34915 34916 GCC's own floating point libraries return tristates from the 34917 comparison operators, so the default returns false always. Most 34918 ports don't need to define this macro. 34919 34920 -- Macro: TARGET_LIB_INT_CMP_BIASED 34921 This macro should evaluate to 'true' if the integer comparison 34922 functions (like '__cmpdi2') return 0 to indicate that the first 34923 operand is smaller than the second, 1 to indicate that they are 34924 equal, and 2 to indicate that the first operand is greater than the 34925 second. If this macro evaluates to 'false' the comparison 34926 functions return -1, 0, and 1 instead of 0, 1, and 2. If the 34927 target uses the routines in 'libgcc.a', you do not need to define 34928 this macro. 34929 34930 -- Macro: TARGET_HAS_NO_HW_DIVIDE 34931 This macro should be defined if the target has no hardware divide 34932 instructions. If this macro is defined, GCC will use an algorithm 34933 which make use of simple logical and arithmetic operations for 34934 64-bit division. If the macro is not defined, GCC will use an 34935 algorithm which make use of a 64-bit by 32-bit divide primitive. 34936 34937 -- Macro: TARGET_EDOM 34938 The value of 'EDOM' on the target machine, as a C integer constant 34939 expression. If you don't define this macro, GCC does not attempt 34940 to deposit the value of 'EDOM' into 'errno' directly. Look in 34941 '/usr/include/errno.h' to find the value of 'EDOM' on your system. 34942 34943 If you do not define 'TARGET_EDOM', then compiled code reports 34944 domain errors by calling the library function and letting it report 34945 the error. If mathematical functions on your system use 'matherr' 34946 when there is an error, then you should leave 'TARGET_EDOM' 34947 undefined so that 'matherr' is used normally. 34948 34949 -- Macro: GEN_ERRNO_RTX 34950 Define this macro as a C expression to create an rtl expression 34951 that refers to the global "variable" 'errno'. (On certain systems, 34952 'errno' may not actually be a variable.) If you don't define this 34953 macro, a reasonable default is used. 34954 34955 -- Target Hook: bool TARGET_LIBC_HAS_FUNCTION (enum function_class 34956 FN_CLASS) 34957 This hook determines whether a function from a class of functions 34958 FN_CLASS is present at the runtime. 34959 34960 -- Macro: NEXT_OBJC_RUNTIME 34961 Set this macro to 1 to use the "NeXT" Objective-C message sending 34962 conventions by default. This calling convention involves passing 34963 the object, the selector and the method arguments all at once to 34964 the method-lookup library function. This is the usual setting when 34965 targeting Darwin/Mac OS X systems, which have the NeXT runtime 34966 installed. 34967 34968 If the macro is set to 0, the "GNU" Objective-C message sending 34969 convention will be used by default. This convention passes just 34970 the object and the selector to the method-lookup function, which 34971 returns a pointer to the method. 34972 34973 In either case, it remains possible to select code-generation for 34974 the alternate scheme, by means of compiler command line switches. 34975 34976 34977File: gccint.info, Node: Addressing Modes, Next: Anchored Addresses, Prev: Library Calls, Up: Target Macros 34978 3497918.13 Addressing Modes 34980====================== 34981 34982This is about addressing modes. 34983 34984 -- Macro: HAVE_PRE_INCREMENT 34985 -- Macro: HAVE_PRE_DECREMENT 34986 -- Macro: HAVE_POST_INCREMENT 34987 -- Macro: HAVE_POST_DECREMENT 34988 A C expression that is nonzero if the machine supports 34989 pre-increment, pre-decrement, post-increment, or post-decrement 34990 addressing respectively. 34991 34992 -- Macro: HAVE_PRE_MODIFY_DISP 34993 -- Macro: HAVE_POST_MODIFY_DISP 34994 A C expression that is nonzero if the machine supports pre- or 34995 post-address side-effect generation involving constants other than 34996 the size of the memory operand. 34997 34998 -- Macro: HAVE_PRE_MODIFY_REG 34999 -- Macro: HAVE_POST_MODIFY_REG 35000 A C expression that is nonzero if the machine supports pre- or 35001 post-address side-effect generation involving a register 35002 displacement. 35003 35004 -- Macro: CONSTANT_ADDRESS_P (X) 35005 A C expression that is 1 if the RTX X is a constant which is a 35006 valid address. On most machines the default definition of 35007 '(CONSTANT_P (X) && GET_CODE (X) != CONST_DOUBLE)' is acceptable, 35008 but a few machines are more restrictive as to which constant 35009 addresses are supported. 35010 35011 -- Macro: CONSTANT_P (X) 35012 'CONSTANT_P', which is defined by target-independent code, accepts 35013 integer-values expressions whose values are not explicitly known, 35014 such as 'symbol_ref', 'label_ref', and 'high' expressions and 35015 'const' arithmetic expressions, in addition to 'const_int' and 35016 'const_double' expressions. 35017 35018 -- Macro: MAX_REGS_PER_ADDRESS 35019 A number, the maximum number of registers that can appear in a 35020 valid memory address. Note that it is up to you to specify a value 35021 equal to the maximum number that 'TARGET_LEGITIMATE_ADDRESS_P' 35022 would ever accept. 35023 35024 -- Target Hook: bool TARGET_LEGITIMATE_ADDRESS_P (machine_mode MODE, 35025 rtx X, bool STRICT) 35026 A function that returns whether X (an RTX) is a legitimate memory 35027 address on the target machine for a memory operand of mode MODE. 35028 35029 Legitimate addresses are defined in two variants: a strict variant 35030 and a non-strict one. The STRICT parameter chooses which variant 35031 is desired by the caller. 35032 35033 The strict variant is used in the reload pass. It must be defined 35034 so that any pseudo-register that has not been allocated a hard 35035 register is considered a memory reference. This is because in 35036 contexts where some kind of register is required, a pseudo-register 35037 with no hard register must be rejected. For non-hard registers, 35038 the strict variant should look up the 'reg_renumber' array; it 35039 should then proceed using the hard register number in the array, or 35040 treat the pseudo as a memory reference if the array holds '-1'. 35041 35042 The non-strict variant is used in other passes. It must be defined 35043 to accept all pseudo-registers in every context where some kind of 35044 register is required. 35045 35046 Normally, constant addresses which are the sum of a 'symbol_ref' 35047 and an integer are stored inside a 'const' RTX to mark them as 35048 constant. Therefore, there is no need to recognize such sums 35049 specifically as legitimate addresses. Normally you would simply 35050 recognize any 'const' as legitimate. 35051 35052 Usually 'PRINT_OPERAND_ADDRESS' is not prepared to handle constant 35053 sums that are not marked with 'const'. It assumes that a naked 35054 'plus' indicates indexing. If so, then you _must_ reject such 35055 naked constant sums as illegitimate addresses, so that none of them 35056 will be given to 'PRINT_OPERAND_ADDRESS'. 35057 35058 On some machines, whether a symbolic address is legitimate depends 35059 on the section that the address refers to. On these machines, 35060 define the target hook 'TARGET_ENCODE_SECTION_INFO' to store the 35061 information into the 'symbol_ref', and then check for it here. 35062 When you see a 'const', you will have to look inside it to find the 35063 'symbol_ref' in order to determine the section. *Note Assembler 35064 Format::. 35065 35066 Some ports are still using a deprecated legacy substitute for this 35067 hook, the 'GO_IF_LEGITIMATE_ADDRESS' macro. This macro has this 35068 syntax: 35069 35070 #define GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL) 35071 35072 and should 'goto LABEL' if the address X is a valid address on the 35073 target machine for a memory operand of mode MODE. 35074 35075 Compiler source files that want to use the strict variant of this 35076 macro define the macro 'REG_OK_STRICT'. You should use an '#ifdef 35077 REG_OK_STRICT' conditional to define the strict variant in that 35078 case and the non-strict variant otherwise. 35079 35080 Using the hook is usually simpler because it limits the number of 35081 files that are recompiled when changes are made. 35082 35083 -- Macro: TARGET_MEM_CONSTRAINT 35084 A single character to be used instead of the default ''m'' 35085 character for general memory addresses. This defines the 35086 constraint letter which matches the memory addresses accepted by 35087 'TARGET_LEGITIMATE_ADDRESS_P'. Define this macro if you want to 35088 support new address formats in your back end without changing the 35089 semantics of the ''m'' constraint. This is necessary in order to 35090 preserve functionality of inline assembly constructs using the 35091 ''m'' constraint. 35092 35093 -- Macro: FIND_BASE_TERM (X) 35094 A C expression to determine the base term of address X, or to 35095 provide a simplified version of X from which 'alias.c' can easily 35096 find the base term. This macro is used in only two places: 35097 'find_base_value' and 'find_base_term' in 'alias.c'. 35098 35099 It is always safe for this macro to not be defined. It exists so 35100 that alias analysis can understand machine-dependent addresses. 35101 35102 The typical use of this macro is to handle addresses containing a 35103 label_ref or symbol_ref within an UNSPEC. 35104 35105 -- Target Hook: rtx TARGET_LEGITIMIZE_ADDRESS (rtx X, rtx OLDX, 35106 machine_mode MODE) 35107 This hook is given an invalid memory address X for an operand of 35108 mode MODE and should try to return a valid memory address. 35109 35110 X will always be the result of a call to 'break_out_memory_refs', 35111 and OLDX will be the operand that was given to that function to 35112 produce X. 35113 35114 The code of the hook should not alter the substructure of X. If it 35115 transforms X into a more legitimate form, it should return the new 35116 X. 35117 35118 It is not necessary for this hook to come up with a legitimate 35119 address, with the exception of native TLS addresses (*note Emulated 35120 TLS::). The compiler has standard ways of doing so in all cases. 35121 In fact, if the target supports only emulated TLS, it is safe to 35122 omit this hook or make it return X if it cannot find a valid way to 35123 legitimize the address. But often a machine-dependent strategy can 35124 generate better code. 35125 35126 -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, 35127 WIN) 35128 A C compound statement that attempts to replace X, which is an 35129 address that needs reloading, with a valid memory address for an 35130 operand of mode MODE. WIN will be a C statement label elsewhere in 35131 the code. It is not necessary to define this macro, but it might 35132 be useful for performance reasons. 35133 35134 For example, on the i386, it is sometimes possible to use a single 35135 reload register instead of two by reloading a sum of two pseudo 35136 registers into a register. On the other hand, for number of RISC 35137 processors offsets are limited so that often an intermediate 35138 address needs to be generated in order to address a stack slot. By 35139 defining 'LEGITIMIZE_RELOAD_ADDRESS' appropriately, the 35140 intermediate addresses generated for adjacent some stack slots can 35141 be made identical, and thus be shared. 35142 35143 _Note_: This macro should be used with caution. It is necessary to 35144 know something of how reload works in order to effectively use 35145 this, and it is quite easy to produce macros that build in too much 35146 knowledge of reload internals. 35147 35148 _Note_: This macro must be able to reload an address created by a 35149 previous invocation of this macro. If it fails to handle such 35150 addresses then the compiler may generate incorrect code or abort. 35151 35152 The macro definition should use 'push_reload' to indicate parts 35153 that need reloading; OPNUM, TYPE and IND_LEVELS are usually 35154 suitable to be passed unaltered to 'push_reload'. 35155 35156 The code generated by this macro must not alter the substructure of 35157 X. If it transforms X into a more legitimate form, it should 35158 assign X (which will always be a C variable) a new value. This 35159 also applies to parts that you change indirectly by calling 35160 'push_reload'. 35161 35162 The macro definition may use 'strict_memory_address_p' to test if 35163 the address has become legitimate. 35164 35165 If you want to change only a part of X, one standard way of doing 35166 this is to use 'copy_rtx'. Note, however, that it unshares only a 35167 single level of rtl. Thus, if the part to be changed is not at the 35168 top level, you'll need to replace first the top level. It is not 35169 necessary for this macro to come up with a legitimate address; but 35170 often a machine-dependent strategy can generate better code. 35171 35172 -- Target Hook: bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx ADDR, 35173 addr_space_t ADDRSPACE) 35174 This hook returns 'true' if memory address ADDR in address space 35175 ADDRSPACE can have different meanings depending on the machine mode 35176 of the memory reference it is used for or if the address is valid 35177 for some modes but not others. 35178 35179 Autoincrement and autodecrement addresses typically have 35180 mode-dependent effects because the amount of the increment or 35181 decrement is the size of the operand being addressed. Some 35182 machines have other mode-dependent addresses. Many RISC machines 35183 have no mode-dependent addresses. 35184 35185 You may assume that ADDR is a valid address for the machine. 35186 35187 The default version of this hook returns 'false'. 35188 35189 -- Target Hook: bool TARGET_LEGITIMATE_CONSTANT_P (machine_mode MODE, 35190 rtx X) 35191 This hook returns true if X is a legitimate constant for a 35192 MODE-mode immediate operand on the target machine. You can assume 35193 that X satisfies 'CONSTANT_P', so you need not check this. 35194 35195 The default definition returns true. 35196 35197 -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X) 35198 This hook is used to undo the possibly obfuscating effects of the 35199 'LEGITIMIZE_ADDRESS' and 'LEGITIMIZE_RELOAD_ADDRESS' target macros. 35200 Some backend implementations of these macros wrap symbol references 35201 inside an 'UNSPEC' rtx to represent PIC or similar addressing 35202 modes. This target hook allows GCC's optimizers to understand the 35203 semantics of these opaque 'UNSPEC's by converting them back into 35204 their original form. 35205 35206 -- Target Hook: bool TARGET_CONST_NOT_OK_FOR_DEBUG_P (rtx X) 35207 This hook should return true if X should not be emitted into debug 35208 sections. 35209 35210 -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (machine_mode MODE, 35211 rtx X) 35212 This hook should return true if X is of a form that cannot (or 35213 should not) be spilled to the constant pool. MODE is the mode of 35214 X. 35215 35216 The default version of this hook returns false. 35217 35218 The primary reason to define this hook is to prevent reload from 35219 deciding that a non-legitimate constant would be better reloaded 35220 from the constant pool instead of spilling and reloading a register 35221 holding the constant. This restriction is often true of addresses 35222 of TLS symbols for various targets. 35223 35224 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (machine_mode 35225 MODE, const_rtx X) 35226 This hook should return true if pool entries for constant X can be 35227 placed in an 'object_block' structure. MODE is the mode of X. 35228 35229 The default version returns false for all constants. 35230 35231 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_DECL_P (const_tree DECL) 35232 This hook should return true if pool entries for DECL should be 35233 placed in an 'object_block' structure. 35234 35235 The default version returns true for all decls. 35236 35237 -- Target Hook: tree TARGET_BUILTIN_RECIPROCAL (tree FNDECL) 35238 This hook should return the DECL of a function that implements the 35239 reciprocal of the machine-specific builtin function FNDECL, or 35240 'NULL_TREE' if such a function is not available. 35241 35242 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void) 35243 This hook should return the DECL of a function F that given an 35244 address ADDR as an argument returns a mask M that can be used to 35245 extract from two vectors the relevant data that resides in ADDR in 35246 case ADDR is not properly aligned. 35247 35248 The autovectorizer, when vectorizing a load operation from an 35249 address ADDR that may be unaligned, will generate two vector loads 35250 from the two aligned addresses around ADDR. It then generates a 35251 'REALIGN_LOAD' operation to extract the relevant data from the two 35252 loaded vectors. The first two arguments to 'REALIGN_LOAD', V1 and 35253 V2, are the two vectors, each of size VS, and the third argument, 35254 OFF, defines how the data will be extracted from these two vectors: 35255 if OFF is 0, then the returned vector is V2; otherwise, the 35256 returned vector is composed from the last VS-OFF elements of V1 35257 concatenated to the first OFF elements of V2. 35258 35259 If this hook is defined, the autovectorizer will generate a call to 35260 F (using the DECL tree that this hook returns) and will use the 35261 return value of F as the argument OFF to 'REALIGN_LOAD'. 35262 Therefore, the mask M returned by F should comply with the 35263 semantics expected by 'REALIGN_LOAD' described above. If this hook 35264 is not defined, then ADDR will be used as the argument OFF to 35265 'REALIGN_LOAD', in which case the low log2(VS) - 1 bits of ADDR 35266 will be considered. 35267 35268 -- Target Hook: int TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST (enum 35269 vect_cost_for_stmt TYPE_OF_COST, tree VECTYPE, int MISALIGN) 35270 Returns cost of different scalar or vector statements for 35271 vectorization cost model. For vector memory operations the cost 35272 may depend on type (VECTYPE) and misalignment value (MISALIGN). 35273 35274 -- Target Hook: HOST_WIDE_INT 35275 TARGET_VECTORIZE_PREFERRED_VECTOR_ALIGNMENT (const_tree TYPE) 35276 This hook returns the preferred alignment in bits for accesses to 35277 vectors of type TYPE in vectorized code. This might be less than 35278 or greater than the ABI-defined value returned by 35279 'TARGET_VECTOR_ALIGNMENT'. It can be equal to the alignment of a 35280 single element, in which case the vectorizer will not try to 35281 optimize for alignment. 35282 35283 The default hook returns 'TYPE_ALIGN (TYPE)', which is correct for 35284 most targets. 35285 35286 -- Target Hook: bool TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE 35287 (const_tree TYPE, bool IS_PACKED) 35288 Return true if vector alignment is reachable (by peeling N 35289 iterations) for the given scalar type TYPE. IS_PACKED is false if 35290 the scalar access using TYPE is known to be naturally aligned. 35291 35292 -- Target Hook: bool TARGET_VECTORIZE_VEC_PERM_CONST (machine_mode 35293 MODE, rtx OUTPUT, rtx IN0, rtx IN1, const vec_perm_indices 35294 &SEL) 35295 This hook is used to test whether the target can permute up to two 35296 vectors of mode MODE using the permutation vector 'sel', and also 35297 to emit such a permutation. In the former case IN0, IN1 and OUT 35298 are all null. In the latter case IN0 and IN1 are the source 35299 vectors and OUT is the destination vector; all three are registers 35300 of mode MODE. IN1 is the same as IN0 if SEL describes a 35301 permutation on one vector instead of two. 35302 35303 Return true if the operation is possible, emitting instructions for 35304 it if rtxes are provided. 35305 35306 If the hook returns false for a mode with multibyte elements, GCC 35307 will try the equivalent byte operation. If that also fails, it 35308 will try forcing the selector into a register and using the 35309 VEC_PERMMODE instruction pattern. There is no need for the hook to 35310 handle these two implementation approaches itself. 35311 35312 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_CONVERSION (unsigned 35313 CODE, tree DEST_TYPE, tree SRC_TYPE) 35314 This hook should return the DECL of a function that implements 35315 conversion of the input vector of type SRC_TYPE to type DEST_TYPE. 35316 The value of CODE is one of the enumerators in 'enum tree_code' and 35317 specifies how the conversion is to be applied (truncation, 35318 rounding, etc.). 35319 35320 If this hook is defined, the autovectorizer will use the 35321 'TARGET_VECTORIZE_BUILTIN_CONVERSION' target hook when vectorizing 35322 conversion. Otherwise, it will return 'NULL_TREE'. 35323 35324 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION 35325 (unsigned CODE, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 35326 This hook should return the decl of a function that implements the 35327 vectorized variant of the function with the 'combined_fn' code CODE 35328 or 'NULL_TREE' if such a function is not available. The return 35329 type of the vectorized function shall be of vector type 35330 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 35331 35332 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION 35333 (tree FNDECL, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 35334 This hook should return the decl of a function that implements the 35335 vectorized variant of target built-in function 'fndecl'. The 35336 return type of the vectorized function shall be of vector type 35337 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 35338 35339 -- Target Hook: bool TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT 35340 (machine_mode MODE, const_tree TYPE, int MISALIGNMENT, bool 35341 IS_PACKED) 35342 This hook should return true if the target supports misaligned 35343 vector store/load of a specific factor denoted in the MISALIGNMENT 35344 parameter. The vector store/load should be of machine mode MODE 35345 and the elements in the vectors should be of type TYPE. IS_PACKED 35346 parameter is true if the memory access is defined in a packed 35347 struct. 35348 35349 -- Target Hook: machine_mode TARGET_VECTORIZE_PREFERRED_SIMD_MODE 35350 (scalar_mode MODE) 35351 This hook should return the preferred mode for vectorizing scalar 35352 mode MODE. The default is equal to 'word_mode', because the 35353 vectorizer can do some transformations even in absence of 35354 specialized SIMD hardware. 35355 35356 -- Target Hook: machine_mode TARGET_VECTORIZE_SPLIT_REDUCTION 35357 (machine_mode) 35358 This hook should return the preferred mode to split the final 35359 reduction step on MODE to. The reduction is then carried out 35360 reducing upper against lower halves of vectors recursively until 35361 the specified mode is reached. The default is MODE which means no 35362 splitting. 35363 35364 -- Target Hook: void TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES 35365 (vector_sizes *SIZES) 35366 If the mode returned by 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE' is 35367 not the only one that is worth considering, this hook should add 35368 all suitable vector sizes to SIZES, in order of decreasing 35369 preference. The first one should be the size of 35370 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE'. 35371 35372 The hook does not need to do anything if the vector returned by 35373 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE' is the only one relevant for 35374 autovectorization. The default implementation does nothing. 35375 35376 -- Target Hook: opt_machine_mode TARGET_VECTORIZE_GET_MASK_MODE 35377 (poly_uint64 NUNITS, poly_uint64 LENGTH) 35378 A vector mask is a value that holds one boolean result for every 35379 element in a vector. This hook returns the machine mode that 35380 should be used to represent such a mask when the vector in question 35381 is LENGTH bytes long and contains NUNITS elements. The hook 35382 returns an empty 'opt_machine_mode' if no such mode exists. 35383 35384 The default implementation returns the mode of an integer vector 35385 that is LENGTH bytes long and that contains NUNITS elements, if 35386 such a mode exists. 35387 35388 -- Target Hook: bool TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE (unsigned 35389 IFN) 35390 This hook returns true if masked internal function IFN (really of 35391 type 'internal_fn') should be considered expensive when the mask is 35392 all zeros. GCC can then try to branch around the instruction 35393 instead. 35394 35395 -- Target Hook: void * TARGET_VECTORIZE_INIT_COST (struct loop 35396 *LOOP_INFO) 35397 This hook should initialize target-specific data structures in 35398 preparation for modeling the costs of vectorizing a loop or basic 35399 block. The default allocates three unsigned integers for 35400 accumulating costs for the prologue, body, and epilogue of the loop 35401 or basic block. If LOOP_INFO is non-NULL, it identifies the loop 35402 being vectorized; otherwise a single block is being vectorized. 35403 35404 -- Target Hook: unsigned TARGET_VECTORIZE_ADD_STMT_COST (void *DATA, 35405 int COUNT, enum vect_cost_for_stmt KIND, struct _stmt_vec_info 35406 *STMT_INFO, int MISALIGN, enum vect_cost_model_location WHERE) 35407 This hook should update the target-specific DATA in response to 35408 adding COUNT copies of the given KIND of statement to a loop or 35409 basic block. The default adds the builtin vectorizer cost for the 35410 copies of the statement to the accumulator specified by WHERE, (the 35411 prologue, body, or epilogue) and returns the amount added. The 35412 return value should be viewed as a tentative cost that may later be 35413 revised. 35414 35415 -- Target Hook: void TARGET_VECTORIZE_FINISH_COST (void *DATA, unsigned 35416 *PROLOGUE_COST, unsigned *BODY_COST, unsigned *EPILOGUE_COST) 35417 This hook should complete calculations of the cost of vectorizing a 35418 loop or basic block based on DATA, and return the prologue, body, 35419 and epilogue costs as unsigned integers. The default returns the 35420 value of the three accumulators. 35421 35422 -- Target Hook: void TARGET_VECTORIZE_DESTROY_COST_DATA (void *DATA) 35423 This hook should release DATA and any related data structures 35424 allocated by TARGET_VECTORIZE_INIT_COST. The default releases the 35425 accumulator. 35426 35427 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_GATHER (const_tree 35428 MEM_VECTYPE, const_tree INDEX_TYPE, int SCALE) 35429 Target builtin that implements vector gather operation. 35430 MEM_VECTYPE is the vector type of the load and INDEX_TYPE is scalar 35431 type of the index, scaled by SCALE. The default is 'NULL_TREE' 35432 which means to not vectorize gather loads. 35433 35434 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_SCATTER (const_tree 35435 VECTYPE, const_tree INDEX_TYPE, int SCALE) 35436 Target builtin that implements vector scatter operation. VECTYPE 35437 is the vector type of the store and INDEX_TYPE is scalar type of 35438 the index, scaled by SCALE. The default is 'NULL_TREE' which means 35439 to not vectorize scatter stores. 35440 35441 -- Target Hook: int TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN 35442 (struct cgraph_node *, struct cgraph_simd_clone *, TREE, INT) 35443 This hook should set VECSIZE_MANGLE, VECSIZE_INT, VECSIZE_FLOAT 35444 fields in SIMD_CLONE structure pointed by CLONE_INFO argument and 35445 also SIMDLEN field if it was previously 0. The hook should return 35446 0 if SIMD clones shouldn't be emitted, or number of VECSIZE_MANGLE 35447 variants that should be emitted. 35448 35449 -- Target Hook: void TARGET_SIMD_CLONE_ADJUST (struct cgraph_node *) 35450 This hook should add implicit 'attribute(target("..."))' attribute 35451 to SIMD clone NODE if needed. 35452 35453 -- Target Hook: int TARGET_SIMD_CLONE_USABLE (struct cgraph_node *) 35454 This hook should return -1 if SIMD clone NODE shouldn't be used in 35455 vectorized loops in current function, or non-negative number if it 35456 is usable. In that case, the smaller the number is, the more 35457 desirable it is to use it. 35458 35459 -- Target Hook: int TARGET_SIMT_VF (void) 35460 Return number of threads in SIMT thread group on the target. 35461 35462 -- Target Hook: bool TARGET_GOACC_VALIDATE_DIMS (tree DECL, int *DIMS, 35463 int FN_LEVEL) 35464 This hook should check the launch dimensions provided for an 35465 OpenACC compute region, or routine. Defaulted values are 35466 represented as -1 and non-constant values as 0. The FN_LEVEL is 35467 negative for the function corresponding to the compute region. For 35468 a routine is is the outermost level at which partitioned execution 35469 may be spawned. The hook should verify non-default values. If 35470 DECL is NULL, global defaults are being validated and unspecified 35471 defaults should be filled in. Diagnostics should be issued as 35472 appropriate. Return true, if changes have been made. You must 35473 override this hook to provide dimensions larger than 1. 35474 35475 -- Target Hook: int TARGET_GOACC_DIM_LIMIT (int AXIS) 35476 This hook should return the maximum size of a particular dimension, 35477 or zero if unbounded. 35478 35479 -- Target Hook: bool TARGET_GOACC_FORK_JOIN (gcall *CALL, const int 35480 *DIMS, bool IS_FORK) 35481 This hook can be used to convert IFN_GOACC_FORK and IFN_GOACC_JOIN 35482 function calls to target-specific gimple, or indicate whether they 35483 should be retained. It is executed during the oacc_device_lower 35484 pass. It should return true, if the call should be retained. It 35485 should return false, if it is to be deleted (either because 35486 target-specific gimple has been inserted before it, or there is no 35487 need for it). The default hook returns false, if there are no RTL 35488 expanders for them. 35489 35490 -- Target Hook: void TARGET_GOACC_REDUCTION (gcall *CALL) 35491 This hook is used by the oacc_transform pass to expand calls to the 35492 GOACC_REDUCTION internal function, into a sequence of gimple 35493 instructions. CALL is gimple statement containing the call to the 35494 function. This hook removes statement CALL after the expanded 35495 sequence has been inserted. This hook is also responsible for 35496 allocating any storage for reductions when necessary. 35497 35498 35499File: gccint.info, Node: Anchored Addresses, Next: Condition Code, Prev: Addressing Modes, Up: Target Macros 35500 3550118.14 Anchored Addresses 35502======================== 35503 35504GCC usually addresses every static object as a separate entity. For 35505example, if we have: 35506 35507 static int a, b, c; 35508 int foo (void) { return a + b + c; } 35509 35510 the code for 'foo' will usually calculate three separate symbolic 35511addresses: those of 'a', 'b' and 'c'. On some targets, it would be 35512better to calculate just one symbolic address and access the three 35513variables relative to it. The equivalent pseudocode would be something 35514like: 35515 35516 int foo (void) 35517 { 35518 register int *xr = &x; 35519 return xr[&a - &x] + xr[&b - &x] + xr[&c - &x]; 35520 } 35521 35522 (which isn't valid C). We refer to shared addresses like 'x' as 35523"section anchors". Their use is controlled by '-fsection-anchors'. 35524 35525 The hooks below describe the target properties that GCC needs to know 35526in order to make effective use of section anchors. It won't use section 35527anchors at all unless either 'TARGET_MIN_ANCHOR_OFFSET' or 35528'TARGET_MAX_ANCHOR_OFFSET' is set to a nonzero value. 35529 35530 -- Target Hook: HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET 35531 The minimum offset that should be applied to a section anchor. On 35532 most targets, it should be the smallest offset that can be applied 35533 to a base register while still giving a legitimate address for 35534 every mode. The default value is 0. 35535 35536 -- Target Hook: HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET 35537 Like 'TARGET_MIN_ANCHOR_OFFSET', but the maximum (inclusive) offset 35538 that should be applied to section anchors. The default value is 0. 35539 35540 -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X) 35541 Write the assembly code to define section anchor X, which is a 35542 'SYMBOL_REF' for which 'SYMBOL_REF_ANCHOR_P (X)' is true. The hook 35543 is called with the assembly output position set to the beginning of 35544 'SYMBOL_REF_BLOCK (X)'. 35545 35546 If 'ASM_OUTPUT_DEF' is available, the hook's default definition 35547 uses it to define the symbol as '. + SYMBOL_REF_BLOCK_OFFSET (X)'. 35548 If 'ASM_OUTPUT_DEF' is not available, the hook's default definition 35549 is 'NULL', which disables the use of section anchors altogether. 35550 35551 -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (const_rtx X) 35552 Return true if GCC should attempt to use anchors to access 35553 'SYMBOL_REF' X. You can assume 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)' 35554 and '!SYMBOL_REF_ANCHOR_P (X)'. 35555 35556 The default version is correct for most targets, but you might need 35557 to intercept this hook to handle things like target-specific 35558 attributes or target-specific sections. 35559 35560 35561File: gccint.info, Node: Condition Code, Next: Costs, Prev: Anchored Addresses, Up: Target Macros 35562 3556318.15 Condition Code Status 35564=========================== 35565 35566The macros in this section can be split in two families, according to 35567the two ways of representing condition codes in GCC. 35568 35569 The first representation is the so called '(cc0)' representation (*note 35570Jump Patterns::), where all instructions can have an implicit clobber of 35571the condition codes. The second is the condition code register 35572representation, which provides better schedulability for architectures 35573that do have a condition code register, but on which most instructions 35574do not affect it. The latter category includes most RISC machines. 35575 35576 The implicit clobbering poses a strong restriction on the placement of 35577the definition and use of the condition code. In the past the 35578definition and use were always adjacent. However, recent changes to 35579support trapping arithmatic may result in the definition and user being 35580in different blocks. Thus, there may be a 'NOTE_INSN_BASIC_BLOCK' 35581between them. Additionally, the definition may be the source of 35582exception handling edges. 35583 35584 These restrictions can prevent important optimizations on some 35585machines. For example, on the IBM RS/6000, there is a delay for taken 35586branches unless the condition code register is set three instructions 35587earlier than the conditional branch. The instruction scheduler cannot 35588perform this optimization if it is not permitted to separate the 35589definition and use of the condition code register. 35590 35591 For this reason, it is possible and suggested to use a register to 35592represent the condition code for new ports. If there is a specific 35593condition code register in the machine, use a hard register. If the 35594condition code or comparison result can be placed in any general 35595register, or if there are multiple condition registers, use a pseudo 35596register. Registers used to store the condition code value will usually 35597have a mode that is in class 'MODE_CC'. 35598 35599 Alternatively, you can use 'BImode' if the comparison operator is 35600specified already in the compare instruction. In this case, you are not 35601interested in most macros in this section. 35602 35603* Menu: 35604 35605* CC0 Condition Codes:: Old style representation of condition codes. 35606* MODE_CC Condition Codes:: Modern representation of condition codes. 35607 35608 35609File: gccint.info, Node: CC0 Condition Codes, Next: MODE_CC Condition Codes, Up: Condition Code 35610 3561118.15.1 Representation of condition codes using '(cc0)' 35612------------------------------------------------------- 35613 35614The file 'conditions.h' defines a variable 'cc_status' to describe how 35615the condition code was computed (in case the interpretation of the 35616condition code depends on the instruction that it was set by). This 35617variable contains the RTL expressions on which the condition code is 35618currently based, and several standard flags. 35619 35620 Sometimes additional machine-specific flags must be defined in the 35621machine description header file. It can also add additional 35622machine-specific information by defining 'CC_STATUS_MDEP'. 35623 35624 -- Macro: CC_STATUS_MDEP 35625 C code for a data type which is used for declaring the 'mdep' 35626 component of 'cc_status'. It defaults to 'int'. 35627 35628 This macro is not used on machines that do not use 'cc0'. 35629 35630 -- Macro: CC_STATUS_MDEP_INIT 35631 A C expression to initialize the 'mdep' field to "empty". The 35632 default definition does nothing, since most machines don't use the 35633 field anyway. If you want to use the field, you should probably 35634 define this macro to initialize it. 35635 35636 This macro is not used on machines that do not use 'cc0'. 35637 35638 -- Macro: NOTICE_UPDATE_CC (EXP, INSN) 35639 A C compound statement to set the components of 'cc_status' 35640 appropriately for an insn INSN whose body is EXP. It is this 35641 macro's responsibility to recognize insns that set the condition 35642 code as a byproduct of other activity as well as those that 35643 explicitly set '(cc0)'. 35644 35645 This macro is not used on machines that do not use 'cc0'. 35646 35647 If there are insns that do not set the condition code but do alter 35648 other machine registers, this macro must check to see whether they 35649 invalidate the expressions that the condition code is recorded as 35650 reflecting. For example, on the 68000, insns that store in address 35651 registers do not set the condition code, which means that usually 35652 'NOTICE_UPDATE_CC' can leave 'cc_status' unaltered for such insns. 35653 But suppose that the previous insn set the condition code based on 35654 location 'a4@(102)' and the current insn stores a new value in 35655 'a4'. Although the condition code is not changed by this, it will 35656 no longer be true that it reflects the contents of 'a4@(102)'. 35657 Therefore, 'NOTICE_UPDATE_CC' must alter 'cc_status' in this case 35658 to say that nothing is known about the condition code value. 35659 35660 The definition of 'NOTICE_UPDATE_CC' must be prepared to deal with 35661 the results of peephole optimization: insns whose patterns are 35662 'parallel' RTXs containing various 'reg', 'mem' or constants which 35663 are just the operands. The RTL structure of these insns is not 35664 sufficient to indicate what the insns actually do. What 35665 'NOTICE_UPDATE_CC' should do when it sees one is just to run 35666 'CC_STATUS_INIT'. 35667 35668 A possible definition of 'NOTICE_UPDATE_CC' is to call a function 35669 that looks at an attribute (*note Insn Attributes::) named, for 35670 example, 'cc'. This avoids having detailed information about 35671 patterns in two places, the 'md' file and in 'NOTICE_UPDATE_CC'. 35672 35673 35674File: gccint.info, Node: MODE_CC Condition Codes, Prev: CC0 Condition Codes, Up: Condition Code 35675 3567618.15.2 Representation of condition codes using registers 35677--------------------------------------------------------- 35678 35679 -- Macro: SELECT_CC_MODE (OP, X, Y) 35680 On many machines, the condition code may be produced by other 35681 instructions than compares, for example the branch can use directly 35682 the condition code set by a subtract instruction. However, on some 35683 machines when the condition code is set this way some bits (such as 35684 the overflow bit) are not set in the same way as a test 35685 instruction, so that a different branch instruction must be used 35686 for some conditional branches. When this happens, use the machine 35687 mode of the condition code register to record different formats of 35688 the condition code register. Modes can also be used to record 35689 which compare instruction (e.g. a signed or an unsigned 35690 comparison) produced the condition codes. 35691 35692 If other modes than 'CCmode' are required, add them to 35693 'MACHINE-modes.def' and define 'SELECT_CC_MODE' to choose a mode 35694 given an operand of a compare. This is needed because the modes 35695 have to be chosen not only during RTL generation but also, for 35696 example, by instruction combination. The result of 35697 'SELECT_CC_MODE' should be consistent with the mode used in the 35698 patterns; for example to support the case of the add on the SPARC 35699 discussed above, we have the pattern 35700 35701 (define_insn "" 35702 [(set (reg:CCNZ 0) 35703 (compare:CCNZ 35704 (plus:SI (match_operand:SI 0 "register_operand" "%r") 35705 (match_operand:SI 1 "arith_operand" "rI")) 35706 (const_int 0)))] 35707 "" 35708 "...") 35709 35710 together with a 'SELECT_CC_MODE' that returns 'CCNZmode' for 35711 comparisons whose argument is a 'plus': 35712 35713 #define SELECT_CC_MODE(OP,X,Y) \ 35714 (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ 35715 ? ((OP == LT || OP == LE || OP == GT || OP == GE) \ 35716 ? CCFPEmode : CCFPmode) \ 35717 : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ 35718 || GET_CODE (X) == NEG || GET_CODE (x) == ASHIFT) \ 35719 ? CCNZmode : CCmode)) 35720 35721 Another reason to use modes is to retain information on which 35722 operands were used by the comparison; see 'REVERSIBLE_CC_MODE' 35723 later in this section. 35724 35725 You should define this macro if and only if you define extra CC 35726 modes in 'MACHINE-modes.def'. 35727 35728 -- Target Hook: void TARGET_CANONICALIZE_COMPARISON (int *CODE, rtx 35729 *OP0, rtx *OP1, bool OP0_PRESERVE_VALUE) 35730 On some machines not all possible comparisons are defined, but you 35731 can convert an invalid comparison into a valid one. For example, 35732 the Alpha does not have a 'GT' comparison, but you can use an 'LT' 35733 comparison instead and swap the order of the operands. 35734 35735 On such machines, implement this hook to do any required 35736 conversions. CODE is the initial comparison code and OP0 and OP1 35737 are the left and right operands of the comparison, respectively. 35738 If OP0_PRESERVE_VALUE is 'true' the implementation is not allowed 35739 to change the value of OP0 since the value might be used in RTXs 35740 which aren't comparisons. E.g. the implementation is not allowed 35741 to swap operands in that case. 35742 35743 GCC will not assume that the comparison resulting from this macro 35744 is valid but will see if the resulting insn matches a pattern in 35745 the 'md' file. 35746 35747 You need not to implement this hook if it would never change the 35748 comparison code or operands. 35749 35750 -- Macro: REVERSIBLE_CC_MODE (MODE) 35751 A C expression whose value is one if it is always safe to reverse a 35752 comparison whose mode is MODE. If 'SELECT_CC_MODE' can ever return 35753 MODE for a floating-point inequality comparison, then 35754 'REVERSIBLE_CC_MODE (MODE)' must be zero. 35755 35756 You need not define this macro if it would always returns zero or 35757 if the floating-point format is anything other than 35758 'IEEE_FLOAT_FORMAT'. For example, here is the definition used on 35759 the SPARC, where floating-point inequality comparisons are given 35760 either 'CCFPEmode' or 'CCFPmode': 35761 35762 #define REVERSIBLE_CC_MODE(MODE) \ 35763 ((MODE) != CCFPEmode && (MODE) != CCFPmode) 35764 35765 -- Macro: REVERSE_CONDITION (CODE, MODE) 35766 A C expression whose value is reversed condition code of the CODE 35767 for comparison done in CC_MODE MODE. The macro is used only in 35768 case 'REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in 35769 case machine has some non-standard way how to reverse certain 35770 conditionals. For instance in case all floating point conditions 35771 are non-trapping, compiler may freely convert unordered compares to 35772 ordered ones. Then definition may look like: 35773 35774 #define REVERSE_CONDITION(CODE, MODE) \ 35775 ((MODE) != CCFPmode ? reverse_condition (CODE) \ 35776 : reverse_condition_maybe_unordered (CODE)) 35777 35778 -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int 35779 *P1, unsigned int *P2) 35780 On targets which do not use '(cc0)', and which use a hard register 35781 rather than a pseudo-register to hold condition codes, the regular 35782 CSE passes are often not able to identify cases in which the hard 35783 register is set to a common value. Use this hook to enable a small 35784 pass which optimizes such cases. This hook should return true to 35785 enable this pass, and it should set the integers to which its 35786 arguments point to the hard register numbers used for condition 35787 codes. When there is only one such register, as is true on most 35788 systems, the integer pointed to by P2 should be set to 35789 'INVALID_REGNUM'. 35790 35791 The default version of this hook returns false. 35792 35793 -- Target Hook: machine_mode TARGET_CC_MODES_COMPATIBLE (machine_mode 35794 M1, machine_mode M2) 35795 On targets which use multiple condition code modes in class 35796 'MODE_CC', it is sometimes the case that a comparison can be 35797 validly done in more than one mode. On such a system, define this 35798 target hook to take two mode arguments and to return a mode in 35799 which both comparisons may be validly done. If there is no such 35800 mode, return 'VOIDmode'. 35801 35802 The default version of this hook checks whether the modes are the 35803 same. If they are, it returns that mode. If they are different, 35804 it returns 'VOIDmode'. 35805 35806 -- Target Hook: unsigned int TARGET_FLAGS_REGNUM 35807 If the target has a dedicated flags register, and it needs to use 35808 the post-reload comparison elimination pass, then this value should 35809 be set appropriately. 35810 35811 35812File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros 35813 3581418.16 Describing Relative Costs of Operations 35815============================================= 35816 35817These macros let you describe the relative speed of various operations 35818on the target machine. 35819 35820 -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO) 35821 A C expression for the cost of moving data of mode MODE from a 35822 register in class FROM to one in class TO. The classes are 35823 expressed using the enumeration values such as 'GENERAL_REGS'. A 35824 value of 2 is the default; other values are interpreted relative to 35825 that. 35826 35827 It is not required that the cost always equal 2 when FROM is the 35828 same as TO; on some machines it is expensive to move between 35829 registers if they are not general registers. 35830 35831 If reload sees an insn consisting of a single 'set' between two 35832 hard registers, and if 'REGISTER_MOVE_COST' applied to their 35833 classes returns a value of 2, reload does not check to ensure that 35834 the constraints of the insn are met. Setting a cost of other than 35835 2 will allow reload to verify that the constraints are met. You 35836 should do this if the 'movM' pattern's constraints do not allow 35837 such copying. 35838 35839 These macros are obsolete, new ports should use the target hook 35840 'TARGET_REGISTER_MOVE_COST' instead. 35841 35842 -- Target Hook: int TARGET_REGISTER_MOVE_COST (machine_mode MODE, 35843 reg_class_t FROM, reg_class_t TO) 35844 This target hook should return the cost of moving data of mode MODE 35845 from a register in class FROM to one in class TO. The classes are 35846 expressed using the enumeration values such as 'GENERAL_REGS'. A 35847 value of 2 is the default; other values are interpreted relative to 35848 that. 35849 35850 It is not required that the cost always equal 2 when FROM is the 35851 same as TO; on some machines it is expensive to move between 35852 registers if they are not general registers. 35853 35854 If reload sees an insn consisting of a single 'set' between two 35855 hard registers, and if 'TARGET_REGISTER_MOVE_COST' applied to their 35856 classes returns a value of 2, reload does not check to ensure that 35857 the constraints of the insn are met. Setting a cost of other than 35858 2 will allow reload to verify that the constraints are met. You 35859 should do this if the 'movM' pattern's constraints do not allow 35860 such copying. 35861 35862 The default version of this function returns 2. 35863 35864 -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN) 35865 A C expression for the cost of moving data of mode MODE between a 35866 register of class CLASS and memory; IN is zero if the value is to 35867 be written to memory, nonzero if it is to be read in. This cost is 35868 relative to those in 'REGISTER_MOVE_COST'. If moving between 35869 registers and memory is more expensive than between two registers, 35870 you should define this macro to express the relative cost. 35871 35872 If you do not define this macro, GCC uses a default cost of 4 plus 35873 the cost of copying via a secondary reload register, if one is 35874 needed. If your machine requires a secondary reload register to 35875 copy between memory and a register of CLASS but the reload 35876 mechanism is more complex than copying via an intermediate, define 35877 this macro to reflect the actual cost of the move. 35878 35879 GCC defines the function 'memory_move_secondary_cost' if secondary 35880 reloads are needed. It computes the costs due to copying via a 35881 secondary register. If your machine copies from memory using a 35882 secondary register in the conventional way but the default base 35883 value of 4 is not correct for your machine, define this macro to 35884 add some other value to the result of that function. The arguments 35885 to that function are the same as to this macro. 35886 35887 These macros are obsolete, new ports should use the target hook 35888 'TARGET_MEMORY_MOVE_COST' instead. 35889 35890 -- Target Hook: int TARGET_MEMORY_MOVE_COST (machine_mode MODE, 35891 reg_class_t RCLASS, bool IN) 35892 This target hook should return the cost of moving data of mode MODE 35893 between a register of class RCLASS and memory; IN is 'false' if the 35894 value is to be written to memory, 'true' if it is to be read in. 35895 This cost is relative to those in 'TARGET_REGISTER_MOVE_COST'. If 35896 moving between registers and memory is more expensive than between 35897 two registers, you should add this target hook to express the 35898 relative cost. 35899 35900 If you do not add this target hook, GCC uses a default cost of 4 35901 plus the cost of copying via a secondary reload register, if one is 35902 needed. If your machine requires a secondary reload register to 35903 copy between memory and a register of RCLASS but the reload 35904 mechanism is more complex than copying via an intermediate, use 35905 this target hook to reflect the actual cost of the move. 35906 35907 GCC defines the function 'memory_move_secondary_cost' if secondary 35908 reloads are needed. It computes the costs due to copying via a 35909 secondary register. If your machine copies from memory using a 35910 secondary register in the conventional way but the default base 35911 value of 4 is not correct for your machine, use this target hook to 35912 add some other value to the result of that function. The arguments 35913 to that function are the same as to this target hook. 35914 35915 -- Macro: BRANCH_COST (SPEED_P, PREDICTABLE_P) 35916 A C expression for the cost of a branch instruction. A value of 1 35917 is the default; other values are interpreted relative to that. 35918 Parameter SPEED_P is true when the branch in question should be 35919 optimized for speed. When it is false, 'BRANCH_COST' should return 35920 a value optimal for code size rather than performance. 35921 PREDICTABLE_P is true for well-predicted branches. On many 35922 architectures the 'BRANCH_COST' can be reduced then. 35923 35924 Here are additional macros which do not specify precise relative costs, 35925but only that certain actions are more expensive than GCC would 35926ordinarily expect. 35927 35928 -- Macro: SLOW_BYTE_ACCESS 35929 Define this macro as a C expression which is nonzero if accessing 35930 less than a word of memory (i.e. a 'char' or a 'short') is no 35931 faster than accessing a word of memory, i.e., if such access 35932 require more than one instruction or if there is no difference in 35933 cost between byte and (aligned) word loads. 35934 35935 When this macro is not defined, the compiler will access a field by 35936 finding the smallest containing object; when it is defined, a 35937 fullword load will be used if alignment permits. Unless bytes 35938 accesses are faster than word accesses, using word accesses is 35939 preferable since it may eliminate subsequent memory access if 35940 subsequent accesses occur to other fields in the same word of the 35941 structure, but to different bytes. 35942 35943 -- Target Hook: bool TARGET_SLOW_UNALIGNED_ACCESS (machine_mode MODE, 35944 unsigned int ALIGN) 35945 This hook returns true if memory accesses described by the MODE and 35946 ALIGNMENT parameters have a cost many times greater than aligned 35947 accesses, for example if they are emulated in a trap handler. This 35948 hook is invoked only for unaligned accesses, i.e. when 'ALIGNMENT 35949 < GET_MODE_ALIGNMENT (MODE)'. 35950 35951 When this hook returns true, the compiler will act as if 35952 'STRICT_ALIGNMENT' were true when generating code for block moves. 35953 This can cause significantly more instructions to be produced. 35954 Therefore, do not make this hook return true if unaligned accesses 35955 only add a cycle or two to the time for a memory access. 35956 35957 The hook must return true whenever 'STRICT_ALIGNMENT' is true. The 35958 default implementation returns 'STRICT_ALIGNMENT'. 35959 35960 -- Macro: MOVE_RATIO (SPEED) 35961 The threshold of number of scalar memory-to-memory move insns, 35962 _below_ which a sequence of insns should be generated instead of a 35963 string move insn or a library call. Increasing the value will 35964 always make code faster, but eventually incurs high cost in 35965 increased code size. 35966 35967 Note that on machines where the corresponding move insn is a 35968 'define_expand' that emits a sequence of insns, this macro counts 35969 the number of such sequences. 35970 35971 The parameter SPEED is true if the code is currently being 35972 optimized for speed rather than size. 35973 35974 If you don't define this, a reasonable default is used. 35975 35976 -- Target Hook: bool TARGET_USE_BY_PIECES_INFRASTRUCTURE_P (unsigned 35977 HOST_WIDE_INT SIZE, unsigned int ALIGNMENT, enum 35978 by_pieces_operation OP, bool SPEED_P) 35979 GCC will attempt several strategies when asked to copy between two 35980 areas of memory, or to set, clear or store to memory, for example 35981 when copying a 'struct'. The 'by_pieces' infrastructure implements 35982 such memory operations as a sequence of load, store or move insns. 35983 Alternate strategies are to expand the 'movmem' or 'setmem' optabs, 35984 to emit a library call, or to emit unit-by-unit, loop-based 35985 operations. 35986 35987 This target hook should return true if, for a memory operation with 35988 a given SIZE and ALIGNMENT, using the 'by_pieces' infrastructure is 35989 expected to result in better code generation. Both SIZE and 35990 ALIGNMENT are measured in terms of storage units. 35991 35992 The parameter OP is one of: 'CLEAR_BY_PIECES', 'MOVE_BY_PIECES', 35993 'SET_BY_PIECES', 'STORE_BY_PIECES' or 'COMPARE_BY_PIECES'. These 35994 describe the type of memory operation under consideration. 35995 35996 The parameter SPEED_P is true if the code is currently being 35997 optimized for speed rather than size. 35998 35999 Returning true for higher values of SIZE can improve code 36000 generation for speed if the target does not provide an 36001 implementation of the 'movmem' or 'setmem' standard names, if the 36002 'movmem' or 'setmem' implementation would be more expensive than a 36003 sequence of insns, or if the overhead of a library call would 36004 dominate that of the body of the memory operation. 36005 36006 Returning true for higher values of 'size' may also cause an 36007 increase in code size, for example where the number of insns 36008 emitted to perform a move would be greater than that of a library 36009 call. 36010 36011 -- Target Hook: int TARGET_COMPARE_BY_PIECES_BRANCH_RATIO (machine_mode 36012 MODE) 36013 When expanding a block comparison in MODE, gcc can try to reduce 36014 the number of branches at the expense of more memory operations. 36015 This hook allows the target to override the default choice. It 36016 should return the factor by which branches should be reduced over 36017 the plain expansion with one comparison per MODE-sized piece. A 36018 port can also prevent a particular mode from being used for block 36019 comparisons by returning a negative number from this hook. 36020 36021 -- Macro: MOVE_MAX_PIECES 36022 A C expression used by 'move_by_pieces' to determine the largest 36023 unit a load or store used to copy memory is. Defaults to 36024 'MOVE_MAX'. 36025 36026 -- Macro: STORE_MAX_PIECES 36027 A C expression used by 'store_by_pieces' to determine the largest 36028 unit a store used to memory is. Defaults to 'MOVE_MAX_PIECES', or 36029 two times the size of 'HOST_WIDE_INT', whichever is smaller. 36030 36031 -- Macro: COMPARE_MAX_PIECES 36032 A C expression used by 'compare_by_pieces' to determine the largest 36033 unit a load or store used to compare memory is. Defaults to 36034 'MOVE_MAX_PIECES'. 36035 36036 -- Macro: CLEAR_RATIO (SPEED) 36037 The threshold of number of scalar move insns, _below_ which a 36038 sequence of insns should be generated to clear memory instead of a 36039 string clear insn or a library call. Increasing the value will 36040 always make code faster, but eventually incurs high cost in 36041 increased code size. 36042 36043 The parameter SPEED is true if the code is currently being 36044 optimized for speed rather than size. 36045 36046 If you don't define this, a reasonable default is used. 36047 36048 -- Macro: SET_RATIO (SPEED) 36049 The threshold of number of scalar move insns, _below_ which a 36050 sequence of insns should be generated to set memory to a constant 36051 value, instead of a block set insn or a library call. Increasing 36052 the value will always make code faster, but eventually incurs high 36053 cost in increased code size. 36054 36055 The parameter SPEED is true if the code is currently being 36056 optimized for speed rather than size. 36057 36058 If you don't define this, it defaults to the value of 'MOVE_RATIO'. 36059 36060 -- Macro: USE_LOAD_POST_INCREMENT (MODE) 36061 A C expression used to determine whether a load postincrement is a 36062 good thing to use for a given mode. Defaults to the value of 36063 'HAVE_POST_INCREMENT'. 36064 36065 -- Macro: USE_LOAD_POST_DECREMENT (MODE) 36066 A C expression used to determine whether a load postdecrement is a 36067 good thing to use for a given mode. Defaults to the value of 36068 'HAVE_POST_DECREMENT'. 36069 36070 -- Macro: USE_LOAD_PRE_INCREMENT (MODE) 36071 A C expression used to determine whether a load preincrement is a 36072 good thing to use for a given mode. Defaults to the value of 36073 'HAVE_PRE_INCREMENT'. 36074 36075 -- Macro: USE_LOAD_PRE_DECREMENT (MODE) 36076 A C expression used to determine whether a load predecrement is a 36077 good thing to use for a given mode. Defaults to the value of 36078 'HAVE_PRE_DECREMENT'. 36079 36080 -- Macro: USE_STORE_POST_INCREMENT (MODE) 36081 A C expression used to determine whether a store postincrement is a 36082 good thing to use for a given mode. Defaults to the value of 36083 'HAVE_POST_INCREMENT'. 36084 36085 -- Macro: USE_STORE_POST_DECREMENT (MODE) 36086 A C expression used to determine whether a store postdecrement is a 36087 good thing to use for a given mode. Defaults to the value of 36088 'HAVE_POST_DECREMENT'. 36089 36090 -- Macro: USE_STORE_PRE_INCREMENT (MODE) 36091 This macro is used to determine whether a store preincrement is a 36092 good thing to use for a given mode. Defaults to the value of 36093 'HAVE_PRE_INCREMENT'. 36094 36095 -- Macro: USE_STORE_PRE_DECREMENT (MODE) 36096 This macro is used to determine whether a store predecrement is a 36097 good thing to use for a given mode. Defaults to the value of 36098 'HAVE_PRE_DECREMENT'. 36099 36100 -- Macro: NO_FUNCTION_CSE 36101 Define this macro to be true if it is as good or better to call a 36102 constant function address than to call an address kept in a 36103 register. 36104 36105 -- Macro: LOGICAL_OP_NON_SHORT_CIRCUIT 36106 Define this macro if a non-short-circuit operation produced by 36107 'fold_range_test ()' is optimal. This macro defaults to true if 36108 'BRANCH_COST' is greater than or equal to the value 2. 36109 36110 -- Target Hook: bool TARGET_OPTAB_SUPPORTED_P (int OP, machine_mode 36111 MODE1, machine_mode MODE2, optimization_type OPT_TYPE) 36112 Return true if the optimizers should use optab OP with modes MODE1 36113 and MODE2 for optimization type OPT_TYPE. The optab is known to 36114 have an associated '.md' instruction whose C condition is true. 36115 MODE2 is only meaningful for conversion optabs; for direct optabs 36116 it is a copy of MODE1. 36117 36118 For example, when called with OP equal to 'rint_optab' and MODE1 36119 equal to 'DFmode', the hook should say whether the optimizers 36120 should use optab 'rintdf2'. 36121 36122 The default hook returns true for all inputs. 36123 36124 -- Target Hook: bool TARGET_RTX_COSTS (rtx X, machine_mode MODE, int 36125 OUTER_CODE, int OPNO, int *TOTAL, bool SPEED) 36126 This target hook describes the relative costs of RTL expressions. 36127 36128 The cost may depend on the precise form of the expression, which is 36129 available for examination in X, and the fact that X appears as 36130 operand OPNO of an expression with rtx code OUTER_CODE. That is, 36131 the hook can assume that there is some rtx Y such that 'GET_CODE 36132 (Y) == OUTER_CODE' and such that either (a) 'XEXP (Y, OPNO) == X' 36133 or (b) 'XVEC (Y, OPNO)' contains X. 36134 36135 MODE is X's machine mode, or for cases like 'const_int' that do not 36136 have a mode, the mode in which X is used. 36137 36138 In implementing this hook, you can use the construct 'COSTS_N_INSNS 36139 (N)' to specify a cost equal to N fast instructions. 36140 36141 On entry to the hook, '*TOTAL' contains a default estimate for the 36142 cost of the expression. The hook should modify this value as 36143 necessary. Traditionally, the default costs are 'COSTS_N_INSNS 36144 (5)' for multiplications, 'COSTS_N_INSNS (7)' for division and 36145 modulus operations, and 'COSTS_N_INSNS (1)' for all other 36146 operations. 36147 36148 When optimizing for code size, i.e. when 'speed' is false, this 36149 target hook should be used to estimate the relative size cost of an 36150 expression, again relative to 'COSTS_N_INSNS'. 36151 36152 The hook returns true when all subexpressions of X have been 36153 processed, and false when 'rtx_cost' should recurse. 36154 36155 -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS, machine_mode 36156 MODE, addr_space_t AS, bool SPEED) 36157 This hook computes the cost of an addressing mode that contains 36158 ADDRESS. If not defined, the cost is computed from the ADDRESS 36159 expression and the 'TARGET_RTX_COST' hook. 36160 36161 For most CISC machines, the default cost is a good approximation of 36162 the true cost of the addressing mode. However, on RISC machines, 36163 all instructions normally have the same length and execution time. 36164 Hence all addresses will have equal costs. 36165 36166 In cases where more than one form of an address is known, the form 36167 with the lowest cost will be used. If multiple forms have the 36168 same, lowest, cost, the one that is the most complex will be used. 36169 36170 For example, suppose an address that is equal to the sum of a 36171 register and a constant is used twice in the same basic block. 36172 When this macro is not defined, the address will be computed in a 36173 register and memory references will be indirect through that 36174 register. On machines where the cost of the addressing mode 36175 containing the sum is no higher than that of a simple indirect 36176 reference, this will produce an additional instruction and possibly 36177 require an additional register. Proper specification of this macro 36178 eliminates this overhead for such machines. 36179 36180 This hook is never called with an invalid address. 36181 36182 On machines where an address involving more than one register is as 36183 cheap as an address computation involving only one register, 36184 defining 'TARGET_ADDRESS_COST' to reflect this can cause two 36185 registers to be live over a region of code where only one would 36186 have been if 'TARGET_ADDRESS_COST' were not defined in that manner. 36187 This effect should be considered in the definition of this macro. 36188 Equivalent costs should probably only be given to addresses with 36189 different numbers of registers on machines with lots of registers. 36190 36191 -- Target Hook: int TARGET_INSN_COST (rtx_insn *INSN, bool SPEED) 36192 This target hook describes the relative costs of RTL instructions. 36193 36194 In implementing this hook, you can use the construct 'COSTS_N_INSNS 36195 (N)' to specify a cost equal to N fast instructions. 36196 36197 When optimizing for code size, i.e. when 'speed' is false, this 36198 target hook should be used to estimate the relative size cost of an 36199 expression, again relative to 'COSTS_N_INSNS'. 36200 36201 -- Target Hook: unsigned int TARGET_MAX_NOCE_IFCVT_SEQ_COST (edge E) 36202 This hook returns a value in the same units as 'TARGET_RTX_COSTS', 36203 giving the maximum acceptable cost for a sequence generated by the 36204 RTL if-conversion pass when conditional execution is not available. 36205 The RTL if-conversion pass attempts to convert conditional 36206 operations that would require a branch to a series of unconditional 36207 operations and 'movMODEcc' insns. This hook returns the maximum 36208 cost of the unconditional instructions and the 'movMODEcc' insns. 36209 RTL if-conversion is cancelled if the cost of the converted 36210 sequence is greater than the value returned by this hook. 36211 36212 'e' is the edge between the basic block containing the conditional 36213 branch to the basic block which would be executed if the condition 36214 were true. 36215 36216 The default implementation of this hook uses the 36217 'max-rtl-if-conversion-[un]predictable' parameters if they are set, 36218 and uses a multiple of 'BRANCH_COST' otherwise. 36219 36220 -- Target Hook: bool TARGET_NOCE_CONVERSION_PROFITABLE_P (rtx_insn 36221 *SEQ, struct noce_if_info *IF_INFO) 36222 This hook returns true if the instruction sequence 'seq' is a good 36223 candidate as a replacement for the if-convertible sequence 36224 described in 'if_info'. 36225 36226 -- Target Hook: bool TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P (void) 36227 This predicate controls the use of the eager delay slot filler to 36228 disallow speculatively executed instructions being placed in delay 36229 slots. Targets such as certain MIPS architectures possess both 36230 branches with and without delay slots. As the eager delay slot 36231 filler can decrease performance, disabling it is beneficial when 36232 ordinary branches are available. Use of delay slot branches filled 36233 using the basic filler is often still desirable as the delay slot 36234 can hide a pipeline bubble. 36235 36236 -- Target Hook: HOST_WIDE_INT TARGET_ESTIMATED_POLY_VALUE (poly_int64 36237 VAL) 36238 Return an estimate of the runtime value of VAL, for use in things 36239 like cost calculations or profiling frequencies. The default 36240 implementation returns the lowest possible value of VAL. 36241 36242 36243File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros 36244 3624518.17 Adjusting the Instruction Scheduler 36246========================================= 36247 36248The instruction scheduler may need a fair amount of machine-specific 36249adjustment in order to produce good code. GCC provides several target 36250hooks for this purpose. It is usually enough to define just a few of 36251them: try the first ones in this list first. 36252 36253 -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void) 36254 This hook returns the maximum number of instructions that can ever 36255 issue at the same time on the target machine. The default is one. 36256 Although the insn scheduler can define itself the possibility of 36257 issue an insn on the same cycle, the value can serve as an 36258 additional constraint to issue insns on the same simulated 36259 processor cycle (see hooks 'TARGET_SCHED_REORDER' and 36260 'TARGET_SCHED_REORDER2'). This value must be constant over the 36261 entire compilation. If you need it to vary depending on what the 36262 instructions are, you must use 'TARGET_SCHED_VARIABLE_ISSUE'. 36263 36264 -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int 36265 VERBOSE, rtx_insn *INSN, int MORE) 36266 This hook is executed by the scheduler after it has scheduled an 36267 insn from the ready list. It should return the number of insns 36268 which can still be issued in the current cycle. The default is 36269 'MORE - 1' for insns other than 'CLOBBER' and 'USE', which normally 36270 are not counted against the issue rate. You should define this 36271 hook if some insns take more machine resources than others, so that 36272 fewer insns can follow them in the same cycle. FILE is either a 36273 null pointer, or a stdio stream to write any debug output to. 36274 VERBOSE is the verbose level provided by '-fsched-verbose-N'. INSN 36275 is the instruction that was scheduled. 36276 36277 -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx_insn *INSN, int 36278 DEP_TYPE1, rtx_insn *DEP_INSN, int COST, unsigned int DW) 36279 This function corrects the value of COST based on the relationship 36280 between INSN and DEP_INSN through a dependence of type dep_type, 36281 and strength DW. It should return the new value. The default is 36282 to make no adjustment to COST. This can be used for example to 36283 specify to the scheduler using the traditional pipeline description 36284 that an output- or anti-dependence does not incur the same cost as 36285 a data-dependence. If the scheduler using the automaton based 36286 pipeline description, the cost of anti-dependence is zero and the 36287 cost of output-dependence is maximum of one and the difference of 36288 latency times of the first and the second insns. If these values 36289 are not acceptable, you could use the hook to modify them too. See 36290 also *note Processor pipeline description::. 36291 36292 -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx_insn *INSN, int 36293 PRIORITY) 36294 This hook adjusts the integer scheduling priority PRIORITY of INSN. 36295 It should return the new priority. Increase the priority to 36296 execute INSN earlier, reduce the priority to execute INSN later. 36297 Do not define this hook if you do not need to adjust the scheduling 36298 priorities of insns. 36299 36300 -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, 36301 rtx_insn **READY, int *N_READYP, int CLOCK) 36302 This hook is executed by the scheduler after it has scheduled the 36303 ready list, to allow the machine description to reorder it (for 36304 example to combine two small instructions together on 'VLIW' 36305 machines). FILE is either a null pointer, or a stdio stream to 36306 write any debug output to. VERBOSE is the verbose level provided 36307 by '-fsched-verbose-N'. READY is a pointer to the ready list of 36308 instructions that are ready to be scheduled. N_READYP is a pointer 36309 to the number of elements in the ready list. The scheduler reads 36310 the ready list in reverse order, starting with READY[*N_READYP - 1] 36311 and going to READY[0]. CLOCK is the timer tick of the scheduler. 36312 You may modify the ready list and the number of ready insns. The 36313 return value is the number of insns that can issue this cycle; 36314 normally this is just 'issue_rate'. See also 36315 'TARGET_SCHED_REORDER2'. 36316 36317 -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE, 36318 rtx_insn **READY, int *N_READYP, int CLOCK) 36319 Like 'TARGET_SCHED_REORDER', but called at a different time. That 36320 function is called whenever the scheduler starts a new cycle. This 36321 one is called once per iteration over a cycle, immediately after 36322 'TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list and 36323 return the number of insns to be scheduled in the same cycle. 36324 Defining this hook can be useful if there are frequent situations 36325 where scheduling one insn causes other insns to become ready in the 36326 same cycle. These other insns can then be taken into account 36327 properly. 36328 36329 -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_P (void) 36330 This hook is used to check whether target platform supports macro 36331 fusion. 36332 36333 -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_PAIR_P (rtx_insn *PREV, 36334 rtx_insn *CURR) 36335 This hook is used to check whether two insns should be macro fused 36336 for a target microarchitecture. If this hook returns true for the 36337 given insn pair (PREV and CURR), the scheduler will put them into a 36338 sched group, and they will not be scheduled apart. The two insns 36339 will be either two SET insns or a compare and a conditional jump 36340 and this hook should validate any dependencies needed to fuse the 36341 two insns together. 36342 36343 -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK 36344 (rtx_insn *HEAD, rtx_insn *TAIL) 36345 This hook is called after evaluation forward dependencies of insns 36346 in chain given by two parameter values (HEAD and TAIL 36347 correspondingly) but before insns scheduling of the insn chain. 36348 For example, it can be used for better insn classification if it 36349 requires analysis of dependencies. This hook can use backward and 36350 forward dependencies of the insn scheduler because they are already 36351 calculated. 36352 36353 -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int 36354 MAX_READY) 36355 This hook is executed by the scheduler at the beginning of each 36356 block of instructions that are to be scheduled. FILE is either a 36357 null pointer, or a stdio stream to write any debug output to. 36358 VERBOSE is the verbose level provided by '-fsched-verbose-N'. 36359 MAX_READY is the maximum number of insns in the current scheduling 36360 region that can be live at the same time. This can be used to 36361 allocate scratch space if it is needed, e.g. by 36362 'TARGET_SCHED_REORDER'. 36363 36364 -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE) 36365 This hook is executed by the scheduler at the end of each block of 36366 instructions that are to be scheduled. It can be used to perform 36367 cleanup of any actions done by the other scheduling hooks. FILE is 36368 either a null pointer, or a stdio stream to write any debug output 36369 to. VERBOSE is the verbose level provided by '-fsched-verbose-N'. 36370 36371 -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int VERBOSE, 36372 int OLD_MAX_UID) 36373 This hook is executed by the scheduler after function level 36374 initializations. FILE is either a null pointer, or a stdio stream 36375 to write any debug output to. VERBOSE is the verbose level 36376 provided by '-fsched-verbose-N'. OLD_MAX_UID is the maximum insn 36377 uid when scheduling begins. 36378 36379 -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int 36380 VERBOSE) 36381 This is the cleanup hook corresponding to 36382 'TARGET_SCHED_INIT_GLOBAL'. FILE is either a null pointer, or a 36383 stdio stream to write any debug output to. VERBOSE is the verbose 36384 level provided by '-fsched-verbose-N'. 36385 36386 -- Target Hook: rtx TARGET_SCHED_DFA_PRE_CYCLE_INSN (void) 36387 The hook returns an RTL insn. The automaton state used in the 36388 pipeline hazard recognizer is changed as if the insn were scheduled 36389 when the new simulated processor cycle starts. Usage of the hook 36390 may simplify the automaton pipeline description for some VLIW 36391 processors. If the hook is defined, it is used only for the 36392 automaton based pipeline description. The default is not to change 36393 the state when the new simulated processor cycle starts. 36394 36395 -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void) 36396 The hook can be used to initialize data used by the previous hook. 36397 36398 -- Target Hook: rtx_insn * TARGET_SCHED_DFA_POST_CYCLE_INSN (void) 36399 The hook is analogous to 'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used 36400 to changed the state as if the insn were scheduled when the new 36401 simulated processor cycle finishes. 36402 36403 -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void) 36404 The hook is analogous to 'TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but 36405 used to initialize data used by the previous hook. 36406 36407 -- Target Hook: void TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE (void) 36408 The hook to notify target that the current simulated cycle is about 36409 to finish. The hook is analogous to 36410 'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used to change the state in 36411 more complicated situations - e.g., when advancing state on a 36412 single insn is not enough. 36413 36414 -- Target Hook: void TARGET_SCHED_DFA_POST_ADVANCE_CYCLE (void) 36415 The hook to notify target that new simulated cycle has just 36416 started. The hook is analogous to 36417 'TARGET_SCHED_DFA_POST_CYCLE_INSN' but used to change the state in 36418 more complicated situations - e.g., when advancing state on a 36419 single insn is not enough. 36420 36421 -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 36422 (void) 36423 This hook controls better choosing an insn from the ready insn 36424 queue for the DFA-based insn scheduler. Usually the scheduler 36425 chooses the first insn from the queue. If the hook returns a 36426 positive value, an additional scheduler code tries all permutations 36427 of 'TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD ()' subsequent 36428 ready insns to choose an insn whose issue will result in maximal 36429 number of issued insns on the same cycle. For the VLIW processor, 36430 the code could actually solve the problem of packing simple insns 36431 into the VLIW insn. Of course, if the rules of VLIW packing are 36432 described in the automaton. 36433 36434 This code also could be used for superscalar RISC processors. Let 36435 us consider a superscalar RISC processor with 3 pipelines. Some 36436 insns can be executed in pipelines A or B, some insns can be 36437 executed only in pipelines B or C, and one insn can be executed in 36438 pipeline B. The processor may issue the 1st insn into A and the 36439 2nd one into B. In this case, the 3rd insn will wait for freeing B 36440 until the next cycle. If the scheduler issues the 3rd insn the 36441 first, the processor could issue all 3 insns per cycle. 36442 36443 Actually this code demonstrates advantages of the automaton based 36444 pipeline hazard recognizer. We try quickly and easy many insn 36445 schedules to choose the best one. 36446 36447 The default is no multipass scheduling. 36448 36449 -- Target Hook: int 36450 TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD 36451 (rtx_insn *INSN, int READY_INDEX) 36452 36453 This hook controls what insns from the ready insn queue will be 36454 considered for the multipass insn scheduling. If the hook returns 36455 zero for INSN, the insn will be considered in multipass scheduling. 36456 Positive return values will remove INSN from consideration on the 36457 current round of multipass scheduling. Negative return values will 36458 remove INSN from consideration for given number of cycles. 36459 Backends should be careful about returning non-zero for highest 36460 priority instruction at position 0 in the ready list. READY_INDEX 36461 is passed to allow backends make correct judgements. 36462 36463 The default is that any ready insns can be chosen to be issued. 36464 36465 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN (void 36466 *DATA, signed char *READY_TRY, int N_READY, bool 36467 FIRST_CYCLE_INSN_P) 36468 This hook prepares the target backend for a new round of multipass 36469 scheduling. 36470 36471 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE (void 36472 *DATA, signed char *READY_TRY, int N_READY, rtx_insn *INSN, 36473 const void *PREV_DATA) 36474 This hook is called when multipass scheduling evaluates instruction 36475 INSN. 36476 36477 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK 36478 (const void *DATA, signed char *READY_TRY, int N_READY) 36479 This is called when multipass scheduling backtracks from evaluation 36480 of an instruction. 36481 36482 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END (const void 36483 *DATA) 36484 This hook notifies the target about the result of the concluded 36485 current round of multipass scheduling. 36486 36487 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT (void 36488 *DATA) 36489 This hook initializes target-specific data used in multipass 36490 scheduling. 36491 36492 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI (void 36493 *DATA) 36494 This hook finalizes target-specific data used in multipass 36495 scheduling. 36496 36497 -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *DUMP, int 36498 VERBOSE, rtx_insn *INSN, int LAST_CLOCK, int CLOCK, int 36499 *SORT_P) 36500 This hook is called by the insn scheduler before issuing INSN on 36501 cycle CLOCK. If the hook returns nonzero, INSN is not issued on 36502 this processor cycle. Instead, the processor cycle is advanced. 36503 If *SORT_P is zero, the insn ready queue is not sorted on the new 36504 cycle start as usually. DUMP and VERBOSE specify the file and 36505 verbosity level to use for debugging output. LAST_CLOCK and CLOCK 36506 are, respectively, the processor cycle on which the previous insn 36507 has been issued, and the current processor cycle. 36508 36509 -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (struct _dep 36510 *_DEP, int COST, int DISTANCE) 36511 This hook is used to define which dependences are considered costly 36512 by the target, so costly that it is not advisable to schedule the 36513 insns that are involved in the dependence too close to one another. 36514 The parameters to this hook are as follows: The first parameter 36515 _DEP is the dependence being evaluated. The second parameter COST 36516 is the cost of the dependence as estimated by the scheduler, and 36517 the third parameter DISTANCE is the distance in cycles between the 36518 two insns. The hook returns 'true' if considering the distance 36519 between the two insns the dependence between them is considered 36520 costly by the target, and 'false' otherwise. 36521 36522 Defining this hook can be useful in multiple-issue out-of-order 36523 machines, where (a) it's practically hopeless to predict the actual 36524 data/resource delays, however: (b) there's a better chance to 36525 predict the actual grouping that will be formed, and (c) correctly 36526 emulating the grouping can be very important. In such targets one 36527 may want to allow issuing dependent insns closer to one 36528 another--i.e., closer than the dependence distance; however, not in 36529 cases of "costly dependences", which this hooks allows to define. 36530 36531 -- Target Hook: void TARGET_SCHED_H_I_D_EXTENDED (void) 36532 This hook is called by the insn scheduler after emitting a new 36533 instruction to the instruction stream. The hook notifies a target 36534 backend to extend its per instruction data structures. 36535 36536 -- Target Hook: void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void) 36537 Return a pointer to a store large enough to hold target scheduling 36538 context. 36539 36540 -- Target Hook: void TARGET_SCHED_INIT_SCHED_CONTEXT (void *TC, bool 36541 CLEAN_P) 36542 Initialize store pointed to by TC to hold target scheduling 36543 context. It CLEAN_P is true then initialize TC as if scheduler is 36544 at the beginning of the block. Otherwise, copy the current context 36545 into TC. 36546 36547 -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC) 36548 Copy target scheduling context pointed to by TC to the current 36549 context. 36550 36551 -- Target Hook: void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *TC) 36552 Deallocate internal data in target scheduling context pointed to by 36553 TC. 36554 36555 -- Target Hook: void TARGET_SCHED_FREE_SCHED_CONTEXT (void *TC) 36556 Deallocate a store for target scheduling context pointed to by TC. 36557 36558 -- Target Hook: int TARGET_SCHED_SPECULATE_INSN (rtx_insn *INSN, 36559 unsigned int DEP_STATUS, rtx *NEW_PAT) 36560 This hook is called by the insn scheduler when INSN has only 36561 speculative dependencies and therefore can be scheduled 36562 speculatively. The hook is used to check if the pattern of INSN 36563 has a speculative version and, in case of successful check, to 36564 generate that speculative pattern. The hook should return 1, if 36565 the instruction has a speculative form, or -1, if it doesn't. 36566 REQUEST describes the type of requested speculation. If the return 36567 value equals 1 then NEW_PAT is assigned the generated speculative 36568 pattern. 36569 36570 -- Target Hook: bool TARGET_SCHED_NEEDS_BLOCK_P (unsigned int 36571 DEP_STATUS) 36572 This hook is called by the insn scheduler during generation of 36573 recovery code for INSN. It should return 'true', if the 36574 corresponding check instruction should branch to recovery code, or 36575 'false' otherwise. 36576 36577 -- Target Hook: rtx TARGET_SCHED_GEN_SPEC_CHECK (rtx_insn *INSN, 36578 rtx_insn *LABEL, unsigned int DS) 36579 This hook is called by the insn scheduler to generate a pattern for 36580 recovery check instruction. If MUTATE_P is zero, then INSN is a 36581 speculative instruction for which the check should be generated. 36582 LABEL is either a label of a basic block, where recovery code 36583 should be emitted, or a null pointer, when requested check doesn't 36584 branch to recovery code (a simple check). If MUTATE_P is nonzero, 36585 then a pattern for a branchy check corresponding to a simple check 36586 denoted by INSN should be generated. In this case LABEL can't be 36587 null. 36588 36589 -- Target Hook: void TARGET_SCHED_SET_SCHED_FLAGS (struct spec_info_def 36590 *SPEC_INFO) 36591 This hook is used by the insn scheduler to find out what features 36592 should be enabled/used. The structure *SPEC_INFO should be filled 36593 in by the target. The structure describes speculation types that 36594 can be used in the scheduler. 36595 36596 -- Target Hook: bool TARGET_SCHED_CAN_SPECULATE_INSN (rtx_insn *INSN) 36597 Some instructions should never be speculated by the schedulers, 36598 usually because the instruction is too expensive to get this wrong. 36599 Often such instructions have long latency, and often they are not 36600 fully modeled in the pipeline descriptions. This hook should 36601 return 'false' if INSN should not be speculated. 36602 36603 -- Target Hook: int TARGET_SCHED_SMS_RES_MII (struct ddg *G) 36604 This hook is called by the swing modulo scheduler to calculate a 36605 resource-based lower bound which is based on the resources 36606 available in the machine and the resources required by each 36607 instruction. The target backend can use G to calculate such bound. 36608 A very simple lower bound will be used in case this hook is not 36609 implemented: the total number of instructions divided by the issue 36610 rate. 36611 36612 -- Target Hook: bool TARGET_SCHED_DISPATCH (rtx_insn *INSN, int X) 36613 This hook is called by Haifa Scheduler. It returns true if 36614 dispatch scheduling is supported in hardware and the condition 36615 specified in the parameter is true. 36616 36617 -- Target Hook: void TARGET_SCHED_DISPATCH_DO (rtx_insn *INSN, int X) 36618 This hook is called by Haifa Scheduler. It performs the operation 36619 specified in its second parameter. 36620 36621 -- Target Hook: bool TARGET_SCHED_EXPOSED_PIPELINE 36622 True if the processor has an exposed pipeline, which means that not 36623 just the order of instructions is important for correctness when 36624 scheduling, but also the latencies of operations. 36625 36626 -- Target Hook: int TARGET_SCHED_REASSOCIATION_WIDTH (unsigned int OPC, 36627 machine_mode MODE) 36628 This hook is called by tree reassociator to determine a level of 36629 parallelism required in output calculations chain. 36630 36631 -- Target Hook: void TARGET_SCHED_FUSION_PRIORITY (rtx_insn *INSN, int 36632 MAX_PRI, int *FUSION_PRI, int *PRI) 36633 This hook is called by scheduling fusion pass. It calculates 36634 fusion priorities for each instruction passed in by parameter. The 36635 priorities are returned via pointer parameters. 36636 36637 INSN is the instruction whose priorities need to be calculated. 36638 MAX_PRI is the maximum priority can be returned in any cases. 36639 FUSION_PRI is the pointer parameter through which INSN's fusion 36640 priority should be calculated and returned. PRI is the pointer 36641 parameter through which INSN's priority should be calculated and 36642 returned. 36643 36644 Same FUSION_PRI should be returned for instructions which should be 36645 scheduled together. Different PRI should be returned for 36646 instructions with same FUSION_PRI. FUSION_PRI is the major sort 36647 key, PRI is the minor sort key. All instructions will be scheduled 36648 according to the two priorities. All priorities calculated should 36649 be between 0 (exclusive) and MAX_PRI (inclusive). To avoid false 36650 dependencies, FUSION_PRI of instructions which need to be scheduled 36651 together should be smaller than FUSION_PRI of irrelevant 36652 instructions. 36653 36654 Given below example: 36655 36656 ldr r10, [r1, 4] 36657 add r4, r4, r10 36658 ldr r15, [r2, 8] 36659 sub r5, r5, r15 36660 ldr r11, [r1, 0] 36661 add r4, r4, r11 36662 ldr r16, [r2, 12] 36663 sub r5, r5, r16 36664 36665 On targets like ARM/AArch64, the two pairs of consecutive loads 36666 should be merged. Since peephole2 pass can't help in this case 36667 unless consecutive loads are actually next to each other in 36668 instruction flow. That's where this scheduling fusion pass works. 36669 This hook calculates priority for each instruction based on its 36670 fustion type, like: 36671 36672 ldr r10, [r1, 4] ; fusion_pri=99, pri=96 36673 add r4, r4, r10 ; fusion_pri=100, pri=100 36674 ldr r15, [r2, 8] ; fusion_pri=98, pri=92 36675 sub r5, r5, r15 ; fusion_pri=100, pri=100 36676 ldr r11, [r1, 0] ; fusion_pri=99, pri=100 36677 add r4, r4, r11 ; fusion_pri=100, pri=100 36678 ldr r16, [r2, 12] ; fusion_pri=98, pri=88 36679 sub r5, r5, r16 ; fusion_pri=100, pri=100 36680 36681 Scheduling fusion pass then sorts all ready to issue instructions 36682 according to the priorities. As a result, instructions of same 36683 fusion type will be pushed together in instruction flow, like: 36684 36685 ldr r11, [r1, 0] 36686 ldr r10, [r1, 4] 36687 ldr r15, [r2, 8] 36688 ldr r16, [r2, 12] 36689 add r4, r4, r10 36690 sub r5, r5, r15 36691 add r4, r4, r11 36692 sub r5, r5, r16 36693 36694 Now peephole2 pass can simply merge the two pairs of loads. 36695 36696 Since scheduling fusion pass relies on peephole2 to do real fusion 36697 work, it is only enabled by default when peephole2 is in effect. 36698 36699 This is firstly introduced on ARM/AArch64 targets, please refer to 36700 the hook implementation for how different fusion types are 36701 supported. 36702 36703 -- Target Hook: void TARGET_EXPAND_DIVMOD_LIBFUNC (rtx LIBFUNC, 36704 machine_mode MODE, rtx OP0, rtx OP1, rtx *QUOT, rtx *REM) 36705 Define this hook for enabling divmod transform if the port does not 36706 have hardware divmod insn but defines target-specific divmod 36707 libfuncs. 36708 36709 36710File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros 36711 3671218.18 Dividing the Output into Sections (Texts, Data, ...) 36713========================================================== 36714 36715An object file is divided into sections containing different types of 36716data. In the most common case, there are three sections: the "text 36717section", which holds instructions and read-only data; the "data 36718section", which holds initialized writable data; and the "bss section", 36719which holds uninitialized data. Some systems have other kinds of 36720sections. 36721 36722 'varasm.c' provides several well-known sections, such as 36723'text_section', 'data_section' and 'bss_section'. The normal way of 36724controlling a 'FOO_section' variable is to define the associated 36725'FOO_SECTION_ASM_OP' macro, as described below. The macros are only 36726read once, when 'varasm.c' initializes itself, so their values must be 36727run-time constants. They may however depend on command-line flags. 36728 36729 _Note:_ Some run-time files, such 'crtstuff.c', also make use of the 36730'FOO_SECTION_ASM_OP' macros, and expect them to be string literals. 36731 36732 Some assemblers require a different string to be written every time a 36733section is selected. If your assembler falls into this category, you 36734should define the 'TARGET_ASM_INIT_SECTIONS' hook and use 36735'get_unnamed_section' to set up the sections. 36736 36737 You must always create a 'text_section', either by defining 36738'TEXT_SECTION_ASM_OP' or by initializing 'text_section' in 36739'TARGET_ASM_INIT_SECTIONS'. The same is true of 'data_section' and 36740'DATA_SECTION_ASM_OP'. If you do not create a distinct 36741'readonly_data_section', the default is to reuse 'text_section'. 36742 36743 All the other 'varasm.c' sections are optional, and are null if the 36744target does not provide them. 36745 36746 -- Macro: TEXT_SECTION_ASM_OP 36747 A C expression whose value is a string, including spacing, 36748 containing the assembler operation that should precede instructions 36749 and read-only data. Normally '"\t.text"' is right. 36750 36751 -- Macro: HOT_TEXT_SECTION_NAME 36752 If defined, a C string constant for the name of the section 36753 containing most frequently executed functions of the program. If 36754 not defined, GCC will provide a default definition if the target 36755 supports named sections. 36756 36757 -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME 36758 If defined, a C string constant for the name of the section 36759 containing unlikely executed functions in the program. 36760 36761 -- Macro: DATA_SECTION_ASM_OP 36762 A C expression whose value is a string, including spacing, 36763 containing the assembler operation to identify the following data 36764 as writable initialized data. Normally '"\t.data"' is right. 36765 36766 -- Macro: SDATA_SECTION_ASM_OP 36767 If defined, a C expression whose value is a string, including 36768 spacing, containing the assembler operation to identify the 36769 following data as initialized, writable small data. 36770 36771 -- Macro: READONLY_DATA_SECTION_ASM_OP 36772 A C expression whose value is a string, including spacing, 36773 containing the assembler operation to identify the following data 36774 as read-only initialized data. 36775 36776 -- Macro: BSS_SECTION_ASM_OP 36777 If defined, a C expression whose value is a string, including 36778 spacing, containing the assembler operation to identify the 36779 following data as uninitialized global data. If not defined, and 36780 'ASM_OUTPUT_ALIGNED_BSS' not defined, uninitialized global data 36781 will be output in the data section if '-fno-common' is passed, 36782 otherwise 'ASM_OUTPUT_COMMON' will be used. 36783 36784 -- Macro: SBSS_SECTION_ASM_OP 36785 If defined, a C expression whose value is a string, including 36786 spacing, containing the assembler operation to identify the 36787 following data as uninitialized, writable small data. 36788 36789 -- Macro: TLS_COMMON_ASM_OP 36790 If defined, a C expression whose value is a string containing the 36791 assembler operation to identify the following data as thread-local 36792 common data. The default is '".tls_common"'. 36793 36794 -- Macro: TLS_SECTION_ASM_FLAG 36795 If defined, a C expression whose value is a character constant 36796 containing the flag used to mark a section as a TLS section. The 36797 default is ''T''. 36798 36799 -- Macro: INIT_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 initialization code. If not defined, GCC will 36803 assume such a section does not exist. This section has no 36804 corresponding 'init_section' variable; it is used entirely in 36805 runtime code. 36806 36807 -- Macro: FINI_SECTION_ASM_OP 36808 If defined, a C expression whose value is a string, including 36809 spacing, containing the assembler operation to identify the 36810 following data as finalization code. If not defined, GCC will 36811 assume such a section does not exist. This section has no 36812 corresponding 'fini_section' variable; it is used entirely in 36813 runtime code. 36814 36815 -- Macro: INIT_ARRAY_SECTION_ASM_OP 36816 If defined, a C expression whose value is a string, including 36817 spacing, containing the assembler operation to identify the 36818 following data as part of the '.init_array' (or equivalent) 36819 section. If not defined, GCC will assume such a section does not 36820 exist. Do not define both this macro and 'INIT_SECTION_ASM_OP'. 36821 36822 -- Macro: FINI_ARRAY_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 part of the '.fini_array' (or equivalent) 36826 section. If not defined, GCC will assume such a section does not 36827 exist. Do not define both this macro and 'FINI_SECTION_ASM_OP'. 36828 36829 -- Macro: MACH_DEP_SECTION_ASM_FLAG 36830 If defined, a C expression whose value is a character constant 36831 containing the flag used to mark a machine-dependent section. This 36832 corresponds to the 'SECTION_MACH_DEP' section flag. 36833 36834 -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION) 36835 If defined, an ASM statement that switches to a different section 36836 via SECTION_OP, calls FUNCTION, and switches back to the text 36837 section. This is used in 'crtstuff.c' if 'INIT_SECTION_ASM_OP' or 36838 'FINI_SECTION_ASM_OP' to calls to initialization and finalization 36839 functions from the init and fini sections. By default, this macro 36840 uses a simple function call. Some ports need hand-crafted assembly 36841 code to avoid dependencies on registers initialized in the function 36842 prologue or to ensure that constant pools don't end up too far way 36843 in the text section. 36844 36845 -- Macro: TARGET_LIBGCC_SDATA_SECTION 36846 If defined, a string which names the section into which small 36847 variables defined in crtstuff and libgcc should go. This is useful 36848 when the target has options for optimizing access to small data, 36849 and you want the crtstuff and libgcc routines to be conservative in 36850 what they expect of your application yet liberal in what your 36851 application expects. For example, for targets with a '.sdata' 36852 section (like MIPS), you could compile crtstuff with '-G 0' so that 36853 it doesn't require small data support from your application, but 36854 use this macro to put small data into '.sdata' so that your 36855 application can access these variables whether it uses small data 36856 or not. 36857 36858 -- Macro: FORCE_CODE_SECTION_ALIGN 36859 If defined, an ASM statement that aligns a code section to some 36860 arbitrary boundary. This is used to force all fragments of the 36861 '.init' and '.fini' sections to have to same alignment and thus 36862 prevent the linker from having to add any padding. 36863 36864 -- Macro: JUMP_TABLES_IN_TEXT_SECTION 36865 Define this macro to be an expression with a nonzero value if jump 36866 tables (for 'tablejump' insns) should be output in the text 36867 section, along with the assembler instructions. Otherwise, the 36868 readonly data section is used. 36869 36870 This macro is irrelevant if there is no separate readonly data 36871 section. 36872 36873 -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void) 36874 Define this hook if you need to do something special to set up the 36875 'varasm.c' sections, or if your target has some special sections of 36876 its own that you need to create. 36877 36878 GCC calls this hook after processing the command line, but before 36879 writing any assembly code, and before calling any of the 36880 section-returning hooks described below. 36881 36882 -- Target Hook: int TARGET_ASM_RELOC_RW_MASK (void) 36883 Return a mask describing how relocations should be treated when 36884 selecting sections. Bit 1 should be set if global relocations 36885 should be placed in a read-write section; bit 0 should be set if 36886 local relocations should be placed in a read-write section. 36887 36888 The default version of this function returns 3 when '-fpic' is in 36889 effect, and 0 otherwise. The hook is typically redefined when the 36890 target cannot support (some kinds of) dynamic relocations in 36891 read-only sections even in executables. 36892 36893 -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int 36894 RELOC, unsigned HOST_WIDE_INT ALIGN) 36895 Return the section into which EXP should be placed. You can assume 36896 that EXP is either a 'VAR_DECL' node or a constant of some sort. 36897 RELOC indicates whether the initial value of EXP requires link-time 36898 relocations. Bit 0 is set when variable contains local relocations 36899 only, while bit 1 is set for global relocations. ALIGN is the 36900 constant alignment in bits. 36901 36902 The default version of this function takes care of putting 36903 read-only variables in 'readonly_data_section'. 36904 36905 See also USE_SELECT_SECTION_FOR_FUNCTIONS. 36906 36907 -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS 36908 Define this macro if you wish TARGET_ASM_SELECT_SECTION to be 36909 called for 'FUNCTION_DECL's as well as for variables and constants. 36910 36911 In the case of a 'FUNCTION_DECL', RELOC will be zero if the 36912 function has been determined to be likely to be called, and nonzero 36913 if it is unlikely to be called. 36914 36915 -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC) 36916 Build up a unique section name, expressed as a 'STRING_CST' node, 36917 and assign it to 'DECL_SECTION_NAME (DECL)'. As with 36918 'TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial 36919 value of EXP requires link-time relocations. 36920 36921 The default version of this function appends the symbol name to the 36922 ELF section name that would normally be used for the symbol. For 36923 example, the function 'foo' would be placed in '.text.foo'. 36924 Whatever the actual target object format, this is often good 36925 enough. 36926 36927 -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree 36928 DECL) 36929 Return the readonly data section associated with 'DECL_SECTION_NAME 36930 (DECL)'. The default version of this function selects 36931 '.gnu.linkonce.r.name' if the function's section is 36932 '.gnu.linkonce.t.name', '.rodata.name' if function is in 36933 '.text.name', and the normal readonly-data section otherwise. 36934 36935 -- Target Hook: const char * TARGET_ASM_MERGEABLE_RODATA_PREFIX 36936 Usually, the compiler uses the prefix '".rodata"' to construct 36937 section names for mergeable constant data. Define this macro to 36938 override the string if a different section name should be used. 36939 36940 -- Target Hook: section * TARGET_ASM_TM_CLONE_TABLE_SECTION (void) 36941 Return the section that should be used for transactional memory 36942 clone tables. 36943 36944 -- Target Hook: section * TARGET_ASM_SELECT_RTX_SECTION (machine_mode 36945 MODE, rtx X, unsigned HOST_WIDE_INT ALIGN) 36946 Return the section into which a constant X, of mode MODE, should be 36947 placed. You can assume that X is some kind of constant in RTL. 36948 The argument MODE is redundant except in the case of a 'const_int' 36949 rtx. ALIGN is the constant alignment in bits. 36950 36951 The default version of this function takes care of putting symbolic 36952 constants in 'flag_pic' mode in 'data_section' and everything else 36953 in 'readonly_data_section'. 36954 36955 -- Target Hook: tree TARGET_MANGLE_DECL_ASSEMBLER_NAME (tree DECL, tree 36956 ID) 36957 Define this hook if you need to postprocess the assembler name 36958 generated by target-independent code. The ID provided to this hook 36959 will be the computed name (e.g., the macro 'DECL_NAME' of the DECL 36960 in C, or the mangled name of the DECL in C++). The return value of 36961 the hook is an 'IDENTIFIER_NODE' for the appropriate mangled name 36962 on your target system. The default implementation of this hook 36963 just returns the ID provided. 36964 36965 -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL, 36966 int NEW_DECL_P) 36967 Define this hook if references to a symbol or a constant must be 36968 treated differently depending on something about the variable or 36969 function named by the symbol (such as what section it is in). 36970 36971 The hook is executed immediately after rtl has been created for 36972 DECL, which may be a variable or function declaration or an entry 36973 in the constant pool. In either case, RTL is the rtl in question. 36974 Do _not_ use 'DECL_RTL (DECL)' in this hook; that field may not 36975 have been initialized yet. 36976 36977 In the case of a constant, it is safe to assume that the rtl is a 36978 'mem' whose address is a 'symbol_ref'. Most decls will also have 36979 this form, but that is not guaranteed. Global register variables, 36980 for instance, will have a 'reg' for their rtl. (Normally the right 36981 thing to do with such unusual rtl is leave it alone.) 36982 36983 The NEW_DECL_P argument will be true if this is the first time that 36984 'TARGET_ENCODE_SECTION_INFO' has been invoked on this decl. It 36985 will be false for subsequent invocations, which will happen for 36986 duplicate declarations. Whether or not anything must be done for 36987 the duplicate declaration depends on whether the hook examines 36988 'DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is 36989 called for a constant. 36990 36991 The usual thing for this hook to do is to record flags in the 36992 'symbol_ref', using 'SYMBOL_REF_FLAG' or 'SYMBOL_REF_FLAGS'. 36993 Historically, the name string was modified if it was necessary to 36994 encode more than one bit of information, but this practice is now 36995 discouraged; use 'SYMBOL_REF_FLAGS'. 36996 36997 The default definition of this hook, 'default_encode_section_info' 36998 in 'varasm.c', sets a number of commonly-useful bits in 36999 'SYMBOL_REF_FLAGS'. Check whether the default does what you need 37000 before overriding it. 37001 37002 -- Target Hook: const char * TARGET_STRIP_NAME_ENCODING (const char 37003 *NAME) 37004 Decode NAME and return the real name part, sans the characters that 37005 'TARGET_ENCODE_SECTION_INFO' may have added. 37006 37007 -- Target Hook: bool TARGET_IN_SMALL_DATA_P (const_tree EXP) 37008 Returns true if EXP should be placed into a "small data" section. 37009 The default version of this hook always returns false. 37010 37011 -- Target Hook: bool TARGET_HAVE_SRODATA_SECTION 37012 Contains the value true if the target places read-only "small data" 37013 into a separate section. The default value is false. 37014 37015 -- Target Hook: bool TARGET_PROFILE_BEFORE_PROLOGUE (void) 37016 It returns true if target wants profile code emitted before 37017 prologue. 37018 37019 The default version of this hook use the target macro 37020 'PROFILE_BEFORE_PROLOGUE'. 37021 37022 -- Target Hook: bool TARGET_BINDS_LOCAL_P (const_tree EXP) 37023 Returns true if EXP names an object for which name resolution rules 37024 must resolve to the current "module" (dynamic shared library or 37025 executable image). 37026 37027 The default version of this hook implements the name resolution 37028 rules for ELF, which has a looser model of global name binding than 37029 other currently supported object file formats. 37030 37031 -- Target Hook: bool TARGET_HAVE_TLS 37032 Contains the value true if the target supports thread-local 37033 storage. The default value is false. 37034 37035 37036File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros 37037 3703818.19 Position Independent Code 37039=============================== 37040 37041This section describes macros that help implement generation of position 37042independent code. Simply defining these macros is not enough to 37043generate valid PIC; you must also add support to the hook 37044'TARGET_LEGITIMATE_ADDRESS_P' and to the macro 'PRINT_OPERAND_ADDRESS', 37045as well as 'LEGITIMIZE_ADDRESS'. You must modify the definition of 37046'movsi' to do something appropriate when the source operand contains a 37047symbolic address. You may also need to alter the handling of switch 37048statements so that they use relative addresses. 37049 37050 -- Macro: PIC_OFFSET_TABLE_REGNUM 37051 The register number of the register used to address a table of 37052 static data addresses in memory. In some cases this register is 37053 defined by a processor's "application binary interface" (ABI). 37054 When this macro is defined, RTL is generated for this register 37055 once, as with the stack pointer and frame pointer registers. If 37056 this macro is not defined, it is up to the machine-dependent files 37057 to allocate such a register (if necessary). Note that this 37058 register must be fixed when in use (e.g. when 'flag_pic' is true). 37059 37060 -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED 37061 A C expression that is nonzero if the register defined by 37062 'PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. If not defined, 37063 the default is zero. Do not define this macro if 37064 'PIC_OFFSET_TABLE_REGNUM' is not defined. 37065 37066 -- Macro: LEGITIMATE_PIC_OPERAND_P (X) 37067 A C expression that is nonzero if X is a legitimate immediate 37068 operand on the target machine when generating position independent 37069 code. You can assume that X satisfies 'CONSTANT_P', so you need 37070 not check this. You can also assume FLAG_PIC is true, so you need 37071 not check it either. You need not define this macro if all 37072 constants (including 'SYMBOL_REF') can be immediate operands when 37073 generating position independent code. 37074 37075 37076File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros 37077 3707818.20 Defining the Output Assembler Language 37079============================================ 37080 37081This section describes macros whose principal purpose is to describe how 37082to write instructions in assembler language--rather than what the 37083instructions do. 37084 37085* Menu: 37086 37087* File Framework:: Structural information for the assembler file. 37088* Data Output:: Output of constants (numbers, strings, addresses). 37089* Uninitialized Data:: Output of uninitialized variables. 37090* Label Output:: Output and generation of labels. 37091* Initialization:: General principles of initialization 37092 and termination routines. 37093* Macros for Initialization:: 37094 Specific macros that control the handling of 37095 initialization and termination routines. 37096* Instruction Output:: Output of actual instructions. 37097* Dispatch Tables:: Output of jump tables. 37098* Exception Region Output:: Output of exception region code. 37099* Alignment Output:: Pseudo ops for alignment and skipping data. 37100 37101 37102File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format 37103 3710418.20.1 The Overall Framework of an Assembler File 37105-------------------------------------------------- 37106 37107This describes the overall framework of an assembly file. 37108 37109 -- Target Hook: void TARGET_ASM_FILE_START (void) 37110 Output to 'asm_out_file' any text which the assembler expects to 37111 find at the beginning of a file. The default behavior is 37112 controlled by two flags, documented below. Unless your target's 37113 assembler is quite unusual, if you override the default, you should 37114 call 'default_file_start' at some point in your target hook. This 37115 lets other target files rely on these variables. 37116 37117 -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF 37118 If this flag is true, the text of the macro 'ASM_APP_OFF' will be 37119 printed as the very first line in the assembly file, unless 37120 '-fverbose-asm' is in effect. (If that macro has been defined to 37121 the empty string, this variable has no effect.) With the normal 37122 definition of 'ASM_APP_OFF', the effect is to notify the GNU 37123 assembler that it need not bother stripping comments or extra 37124 whitespace from its input. This allows it to work a bit faster. 37125 37126 The default is false. You should not set it to true unless you 37127 have verified that your port does not generate any extra whitespace 37128 or comments that will cause GAS to issue errors in NO_APP mode. 37129 37130 -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE 37131 If this flag is true, 'output_file_directive' will be called for 37132 the primary source file, immediately after printing 'ASM_APP_OFF' 37133 (if that is enabled). Most ELF assemblers expect this to be done. 37134 The default is false. 37135 37136 -- Target Hook: void TARGET_ASM_FILE_END (void) 37137 Output to 'asm_out_file' any text which the assembler expects to 37138 find at the end of a file. The default is to output nothing. 37139 37140 -- Function: void file_end_indicate_exec_stack () 37141 Some systems use a common convention, the '.note.GNU-stack' special 37142 section, to indicate whether or not an object file relies on the 37143 stack being executable. If your system uses this convention, you 37144 should define 'TARGET_ASM_FILE_END' to this function. If you need 37145 to do other things in that hook, have your hook function call this 37146 function. 37147 37148 -- Target Hook: void TARGET_ASM_LTO_START (void) 37149 Output to 'asm_out_file' any text which the assembler expects to 37150 find at the start of an LTO section. The default is to output 37151 nothing. 37152 37153 -- Target Hook: void TARGET_ASM_LTO_END (void) 37154 Output to 'asm_out_file' any text which the assembler expects to 37155 find at the end of an LTO section. The default is to output 37156 nothing. 37157 37158 -- Target Hook: void TARGET_ASM_CODE_END (void) 37159 Output to 'asm_out_file' any text which is needed before emitting 37160 unwind info and debug info at the end of a file. Some targets emit 37161 here PIC setup thunks that cannot be emitted at the end of file, 37162 because they couldn't have unwind info then. The default is to 37163 output nothing. 37164 37165 -- Macro: ASM_COMMENT_START 37166 A C string constant describing how to begin a comment in the target 37167 assembler language. The compiler assumes that the comment will end 37168 at the end of the line. 37169 37170 -- Macro: ASM_APP_ON 37171 A C string constant for text to be output before each 'asm' 37172 statement or group of consecutive ones. Normally this is '"#APP"', 37173 which is a comment that has no effect on most assemblers but tells 37174 the GNU assembler that it must check the lines that follow for all 37175 valid assembler constructs. 37176 37177 -- Macro: ASM_APP_OFF 37178 A C string constant for text to be output after each 'asm' 37179 statement or group of consecutive ones. Normally this is 37180 '"#NO_APP"', which tells the GNU assembler to resume making the 37181 time-saving assumptions that are valid for ordinary compiler 37182 output. 37183 37184 -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME) 37185 A C statement to output COFF information or DWARF debugging 37186 information which indicates that filename NAME is the current 37187 source file to the stdio stream STREAM. 37188 37189 This macro need not be defined if the standard form of output for 37190 the file format in use is appropriate. 37191 37192 -- Target Hook: void TARGET_ASM_OUTPUT_SOURCE_FILENAME (FILE *FILE, 37193 const char *NAME) 37194 Output DWARF debugging information which indicates that filename 37195 NAME is the current source file to the stdio stream FILE. 37196 37197 This target hook need not be defined if the standard form of output 37198 for the file format in use is appropriate. 37199 37200 -- Target Hook: void TARGET_ASM_OUTPUT_IDENT (const char *NAME) 37201 Output a string based on NAME, suitable for the '#ident' directive, 37202 or the equivalent directive or pragma in non-C-family languages. 37203 If this hook is not defined, nothing is output for the '#ident' 37204 directive. 37205 37206 -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING) 37207 A C statement to output the string STRING to the stdio stream 37208 STREAM. If you do not call the function 'output_quoted_string' in 37209 your config files, GCC will only call it to output filenames to the 37210 assembler source. So you can use it to canonicalize the format of 37211 the filename using this macro. 37212 37213 -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME, 37214 unsigned int FLAGS, tree DECL) 37215 Output assembly directives to switch to section NAME. The section 37216 should have attributes as specified by FLAGS, which is a bit mask 37217 of the 'SECTION_*' flags defined in 'output.h'. If DECL is 37218 non-NULL, it is the 'VAR_DECL' or 'FUNCTION_DECL' with which this 37219 section is associated. 37220 37221 -- Target Hook: bool TARGET_ASM_ELF_FLAGS_NUMERIC (unsigned int FLAGS, 37222 unsigned int *NUM) 37223 This hook can be used to encode ELF section flags for which no 37224 letter code has been defined in the assembler. It is called by 37225 'default_asm_named_section' whenever the section flags need to be 37226 emitted in the assembler output. If the hook returns true, then 37227 the numerical value for ELF section flags should be calculated from 37228 FLAGS and saved in *NUM; the value is printed out instead of the 37229 normal sequence of letter codes. If the hook is not defined, or if 37230 it returns false, then NUM is ignored and the traditional letter 37231 sequence is emitted. 37232 37233 -- Target Hook: section * TARGET_ASM_FUNCTION_SECTION (tree DECL, enum 37234 node_frequency FREQ, bool STARTUP, bool EXIT) 37235 Return preferred text (sub)section for function DECL. Main purpose 37236 of this function is to separate cold, normal and hot functions. 37237 STARTUP is true when function is known to be used only at startup 37238 (from static constructors or it is 'main()'). EXIT is true when 37239 function is known to be used only at exit (from static 37240 destructors). Return NULL if function should go to default text 37241 section. 37242 37243 -- Target Hook: void TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS (FILE 37244 *FILE, tree DECL, bool NEW_IS_COLD) 37245 Used by the target to emit any assembler directives or additional 37246 labels needed when a function is partitioned between different 37247 sections. Output should be written to FILE. The function decl is 37248 available as DECL and the new section is 'cold' if NEW_IS_COLD is 37249 'true'. 37250 37251 -- Common Target Hook: bool TARGET_HAVE_NAMED_SECTIONS 37252 This flag is true if the target supports 37253 'TARGET_ASM_NAMED_SECTION'. It must not be modified by 37254 command-line option processing. 37255 37256 -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS 37257 This flag is true if we can create zeroed data by switching to a 37258 BSS section and then using 'ASM_OUTPUT_SKIP' to allocate the space. 37259 This is true on most ELF targets. 37260 37261 -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL, 37262 const char *NAME, int RELOC) 37263 Choose a set of section attributes for use by 37264 'TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a 37265 section name, and whether or not the declaration's initializer may 37266 contain runtime relocations. DECL may be null, in which case 37267 read-write data should be assumed. 37268 37269 The default version of this function handles choosing code vs data, 37270 read-only vs read-write data, and 'flag_pic'. You should only need 37271 to override this if your target has special flags that might be set 37272 via '__attribute__'. 37273 37274 -- Target Hook: int TARGET_ASM_RECORD_GCC_SWITCHES (print_switch_type 37275 TYPE, const char *TEXT) 37276 Provides the target with the ability to record the gcc command line 37277 switches that have been passed to the compiler, and options that 37278 are enabled. The TYPE argument specifies what is being recorded. 37279 It can take the following values: 37280 37281 'SWITCH_TYPE_PASSED' 37282 TEXT is a command line switch that has been set by the user. 37283 37284 'SWITCH_TYPE_ENABLED' 37285 TEXT is an option which has been enabled. This might be as a 37286 direct result of a command line switch, or because it is 37287 enabled by default or because it has been enabled as a side 37288 effect of a different command line switch. For example, the 37289 '-O2' switch enables various different individual optimization 37290 passes. 37291 37292 'SWITCH_TYPE_DESCRIPTIVE' 37293 TEXT is either NULL or some descriptive text which should be 37294 ignored. If TEXT is NULL then it is being used to warn the 37295 target hook that either recording is starting or ending. The 37296 first time TYPE is SWITCH_TYPE_DESCRIPTIVE and TEXT is NULL, 37297 the warning is for start up and the second time the warning is 37298 for wind down. This feature is to allow the target hook to 37299 make any necessary preparations before it starts to record 37300 switches and to perform any necessary tidying up after it has 37301 finished recording switches. 37302 37303 'SWITCH_TYPE_LINE_START' 37304 This option can be ignored by this target hook. 37305 37306 'SWITCH_TYPE_LINE_END' 37307 This option can be ignored by this target hook. 37308 37309 The hook's return value must be zero. Other return values may be 37310 supported in the future. 37311 37312 By default this hook is set to NULL, but an example implementation 37313 is provided for ELF based targets. Called ELF_RECORD_GCC_SWITCHES, 37314 it records the switches as ASCII text inside a new, string 37315 mergeable section in the assembler output file. The name of the 37316 new section is provided by the 37317 'TARGET_ASM_RECORD_GCC_SWITCHES_SECTION' target hook. 37318 37319 -- Target Hook: const char * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION 37320 This is the name of the section that will be created by the example 37321 ELF implementation of the 'TARGET_ASM_RECORD_GCC_SWITCHES' target 37322 hook. 37323 37324 37325File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format 37326 3732718.20.2 Output of Data 37328---------------------- 37329 37330 -- Target Hook: const char * TARGET_ASM_BYTE_OP 37331 -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP 37332 -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP 37333 -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP 37334 -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP 37335 -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP 37336 -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP 37337 -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP 37338 -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP 37339 These hooks specify assembly directives for creating certain kinds 37340 of integer object. The 'TARGET_ASM_BYTE_OP' directive creates a 37341 byte-sized object, the 'TARGET_ASM_ALIGNED_HI_OP' one creates an 37342 aligned two-byte object, and so on. Any of the hooks may be 37343 'NULL', indicating that no suitable directive is available. 37344 37345 The compiler will print these strings at the start of a new line, 37346 followed immediately by the object's initial value. In most cases, 37347 the string should contain a tab, a pseudo-op, and then another tab. 37348 37349 -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int 37350 ALIGNED_P) 37351 The 'assemble_integer' function uses this hook to output an integer 37352 object. X is the object's value, SIZE is its size in bytes and 37353 ALIGNED_P indicates whether it is aligned. The function should 37354 return 'true' if it was able to output the object. If it returns 37355 false, 'assemble_integer' will try to split the object into smaller 37356 parts. 37357 37358 The default implementation of this hook will use the 37359 'TARGET_ASM_BYTE_OP' family of strings, returning 'false' when the 37360 relevant string is 'NULL'. 37361 37362 -- Target Hook: void TARGET_ASM_DECL_END (void) 37363 Define this hook if the target assembler requires a special marker 37364 to terminate an initialized variable declaration. 37365 37366 -- Target Hook: bool TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA (FILE *FILE, 37367 rtx X) 37368 A target hook to recognize RTX patterns that 'output_addr_const' 37369 can't deal with, and output assembly code to FILE corresponding to 37370 the pattern X. This may be used to allow machine-dependent 37371 'UNSPEC's to appear within constants. 37372 37373 If target hook fails to recognize a pattern, it must return 37374 'false', so that a standard error message is printed. If it prints 37375 an error message itself, by calling, for example, 37376 'output_operand_lossage', it may just return 'true'. 37377 37378 -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN) 37379 A C statement to output to the stdio stream STREAM an assembler 37380 instruction to assemble a string constant containing the LEN bytes 37381 at PTR. PTR will be a C expression of type 'char *' and LEN a C 37382 expression of type 'int'. 37383 37384 If the assembler has a '.ascii' pseudo-op as found in the Berkeley 37385 Unix assembler, do not define the macro 'ASM_OUTPUT_ASCII'. 37386 37387 -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N) 37388 A C statement to output word N of a function descriptor for DECL. 37389 This must be defined if 'TARGET_VTABLE_USES_DESCRIPTORS' is 37390 defined, and is otherwise unused. 37391 37392 -- Macro: CONSTANT_POOL_BEFORE_FUNCTION 37393 You may define this macro as a C expression. You should define the 37394 expression to have a nonzero value if GCC should output the 37395 constant pool for a function before the code for the function, or a 37396 zero value if GCC should output the constant pool after the 37397 function. If you do not define this macro, the usual case, GCC 37398 will output the constant pool before the function. 37399 37400 -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE) 37401 A C statement to output assembler commands to define the start of 37402 the constant pool for a function. FUNNAME is a string giving the 37403 name of the function. Should the return type of the function be 37404 required, it can be obtained via FUNDECL. SIZE is the size, in 37405 bytes, of the constant pool that will be written immediately after 37406 this call. 37407 37408 If no constant-pool prefix is required, the usual case, this macro 37409 need not be defined. 37410 37411 -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, LABELNO, 37412 JUMPTO) 37413 A C statement (with or without semicolon) to output a constant in 37414 the constant pool, if it needs special treatment. (This macro need 37415 not do anything for RTL expressions that can be output normally.) 37416 37417 The argument FILE is the standard I/O stream to output the 37418 assembler code on. X is the RTL expression for the constant to 37419 output, and MODE is the machine mode (in case X is a 'const_int'). 37420 ALIGN is the required alignment for the value X; you should output 37421 an assembler directive to force this much alignment. 37422 37423 The argument LABELNO is a number to use in an internal label for 37424 the address of this pool entry. The definition of this macro is 37425 responsible for outputting the label definition at the proper 37426 place. Here is how to do this: 37427 37428 (*targetm.asm_out.internal_label) (FILE, "LC", LABELNO); 37429 37430 When you output a pool entry specially, you should end with a 37431 'goto' to the label JUMPTO. This will prevent the same pool entry 37432 from being output a second time in the usual manner. 37433 37434 You need not define this macro if it would do nothing. 37435 37436 -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE) 37437 A C statement to output assembler commands to at the end of the 37438 constant pool for a function. FUNNAME is a string giving the name 37439 of the function. Should the return type of the function be 37440 required, you can obtain it via FUNDECL. SIZE is the size, in 37441 bytes, of the constant pool that GCC wrote immediately before this 37442 call. 37443 37444 If no constant-pool epilogue is required, the usual case, you need 37445 not define this macro. 37446 37447 -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C, STR) 37448 Define this macro as a C expression which is nonzero if C is used 37449 as a logical line separator by the assembler. STR points to the 37450 position in the string where C was found; this can be used if a 37451 line separator uses multiple characters. 37452 37453 If you do not define this macro, the default is that only the 37454 character ';' is treated as a logical line separator. 37455 37456 -- Target Hook: const char * TARGET_ASM_OPEN_PAREN 37457 -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN 37458 These target hooks are C string constants, describing the syntax in 37459 the assembler for grouping arithmetic expressions. If not 37460 overridden, they default to normal parentheses, which is correct 37461 for most assemblers. 37462 37463 These macros are provided by 'real.h' for writing the definitions of 37464'ASM_OUTPUT_DOUBLE' and the like: 37465 37466 -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L) 37467 -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L) 37468 -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L) 37469 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L) 37470 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L) 37471 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L) 37472 These translate X, of type 'REAL_VALUE_TYPE', to the target's 37473 floating point representation, and store its bit pattern in the 37474 variable L. For 'REAL_VALUE_TO_TARGET_SINGLE' and 37475 'REAL_VALUE_TO_TARGET_DECIMAL32', this variable should be a simple 37476 'long int'. For the others, it should be an array of 'long int'. 37477 The number of elements in this array is determined by the size of 37478 the desired target floating point data type: 32 bits of it go in 37479 each 'long int' array element. Each array element holds 32 bits of 37480 the result, even if 'long int' is wider than 32 bits on the host 37481 machine. 37482 37483 The array element values are designed so that you can print them 37484 out using 'fprintf' in the order they should appear in the target 37485 machine's memory. 37486 37487 37488File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format 37489 3749018.20.3 Output of Uninitialized Variables 37491----------------------------------------- 37492 37493Each of the macros in this section is used to do the whole job of 37494outputting a single uninitialized variable. 37495 37496 -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED) 37497 A C statement (sans semicolon) to output to the stdio stream STREAM 37498 the assembler definition of a common-label named NAME whose size is 37499 SIZE bytes. The variable ROUNDED is the size rounded up to 37500 whatever alignment the caller wants. It is possible that SIZE may 37501 be zero, for instance if a struct with no other member than a 37502 zero-length array is defined. In this case, the backend must 37503 output a symbol definition that allocates at least one byte, both 37504 so that the address of the resulting object does not compare equal 37505 to any other, and because some object formats cannot even express 37506 the concept of a zero-sized common symbol, as that is how they 37507 represent an ordinary undefined external. 37508 37509 Use the expression 'assemble_name (STREAM, NAME)' to output the 37510 name itself; before and after that, output the additional assembler 37511 syntax for defining the name, and a newline. 37512 37513 This macro controls how the assembler definitions of uninitialized 37514 common global variables are output. 37515 37516 -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT) 37517 Like 'ASM_OUTPUT_COMMON' except takes the required alignment as a 37518 separate, explicit argument. If you define this macro, it is used 37519 in place of 'ASM_OUTPUT_COMMON', and gives you more flexibility in 37520 handling the required alignment of the variable. The alignment is 37521 specified as the number of bits. 37522 37523 -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE, 37524 ALIGNMENT) 37525 Like 'ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable 37526 to be output, if there is one, or 'NULL_TREE' if there is no 37527 corresponding variable. If you define this macro, GCC will use it 37528 in place of both 'ASM_OUTPUT_COMMON' and 37529 'ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to 37530 see the variable's decl in order to chose what to output. 37531 37532 -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT) 37533 A C statement (sans semicolon) to output to the stdio stream STREAM 37534 the assembler definition of uninitialized global DECL named NAME 37535 whose size is SIZE bytes. The variable ALIGNMENT is the alignment 37536 specified as the number of bits. 37537 37538 Try to use function 'asm_output_aligned_bss' defined in file 37539 'varasm.c' when defining this macro. If unable, use the expression 37540 'assemble_name (STREAM, NAME)' to output the name itself; before 37541 and after that, output the additional assembler syntax for defining 37542 the name, and a newline. 37543 37544 There are two ways of handling global BSS. One is to define this 37545 macro. The other is to have 'TARGET_ASM_SELECT_SECTION' return a 37546 switchable BSS section (*note 37547 TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::). You do not need to do 37548 both. 37549 37550 Some languages do not have 'common' data, and require a non-common 37551 form of global BSS in order to handle uninitialized globals 37552 efficiently. C++ is one example of this. However, if the target 37553 does not support global BSS, the front end may choose to make 37554 globals common in order to save space in the object file. 37555 37556 -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED) 37557 A C statement (sans semicolon) to output to the stdio stream STREAM 37558 the assembler definition of a local-common-label named NAME whose 37559 size is SIZE bytes. The variable ROUNDED is the size rounded up to 37560 whatever alignment the caller wants. 37561 37562 Use the expression 'assemble_name (STREAM, NAME)' to output the 37563 name itself; before and after that, output the additional assembler 37564 syntax for defining the name, and a newline. 37565 37566 This macro controls how the assembler definitions of uninitialized 37567 static variables are output. 37568 37569 -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT) 37570 Like 'ASM_OUTPUT_LOCAL' except takes the required alignment as a 37571 separate, explicit argument. If you define this macro, it is used 37572 in place of 'ASM_OUTPUT_LOCAL', and gives you more flexibility in 37573 handling the required alignment of the variable. The alignment is 37574 specified as the number of bits. 37575 37576 -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE, 37577 ALIGNMENT) 37578 Like 'ASM_OUTPUT_ALIGNED_DECL' except that DECL of the variable to 37579 be output, if there is one, or 'NULL_TREE' if there is no 37580 corresponding variable. If you define this macro, GCC will use it 37581 in place of both 'ASM_OUTPUT_DECL' and 'ASM_OUTPUT_ALIGNED_DECL'. 37582 Define this macro when you need to see the variable's decl in order 37583 to chose what to output. 37584 37585 37586File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format 37587 3758818.20.4 Output and Generation of Labels 37589--------------------------------------- 37590 37591This is about outputting labels. 37592 37593 -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME) 37594 A C statement (sans semicolon) to output to the stdio stream STREAM 37595 the assembler definition of a label named NAME. Use the expression 37596 'assemble_name (STREAM, NAME)' to output the name itself; before 37597 and after that, output the additional assembler syntax for defining 37598 the name, and a newline. A default definition of this macro is 37599 provided which is correct for most systems. 37600 37601 -- Macro: ASM_OUTPUT_FUNCTION_LABEL (STREAM, NAME, DECL) 37602 A C statement (sans semicolon) to output to the stdio stream STREAM 37603 the assembler definition of a label named NAME of a function. Use 37604 the expression 'assemble_name (STREAM, NAME)' to output the name 37605 itself; before and after that, output the additional assembler 37606 syntax for defining the name, and a newline. A default definition 37607 of this macro is provided which is correct for most systems. 37608 37609 If this macro is not defined, then the function name is defined in 37610 the usual manner as a label (by means of 'ASM_OUTPUT_LABEL'). 37611 37612 -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME) 37613 Identical to 'ASM_OUTPUT_LABEL', except that NAME is known to refer 37614 to a compiler-generated label. The default definition uses 37615 'assemble_name_raw', which is like 'assemble_name' except that it 37616 is more efficient. 37617 37618 -- Macro: SIZE_ASM_OP 37619 A C string containing the appropriate assembler directive to 37620 specify the size of a symbol, without any arguments. On systems 37621 that use ELF, the default (in 'config/elfos.h') is '"\t.size\t"'; 37622 on other systems, the default is not to define this macro. 37623 37624 Define this macro only if it is correct to use the default 37625 definitions of 'ASM_OUTPUT_SIZE_DIRECTIVE' and 37626 'ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own 37627 custom definitions of those macros, or if you do not need explicit 37628 symbol sizes at all, do not define this macro. 37629 37630 -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE) 37631 A C statement (sans semicolon) to output to the stdio stream STREAM 37632 a directive telling the assembler that the size of the symbol NAME 37633 is SIZE. SIZE is a 'HOST_WIDE_INT'. If you define 'SIZE_ASM_OP', 37634 a default definition of this macro is provided. 37635 37636 -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME) 37637 A C statement (sans semicolon) to output to the stdio stream STREAM 37638 a directive telling the assembler to calculate the size of the 37639 symbol NAME by subtracting its address from the current address. 37640 37641 If you define 'SIZE_ASM_OP', a default definition of this macro is 37642 provided. The default assumes that the assembler recognizes a 37643 special '.' symbol as referring to the current address, and can 37644 calculate the difference between this and another symbol. If your 37645 assembler does not recognize '.' or cannot do calculations with it, 37646 you will need to redefine 'ASM_OUTPUT_MEASURED_SIZE' to use some 37647 other technique. 37648 37649 -- Macro: NO_DOLLAR_IN_LABEL 37650 Define this macro if the assembler does not accept the character 37651 '$' in label names. By default constructors and destructors in G++ 37652 have '$' in the identifiers. If this macro is defined, '.' is used 37653 instead. 37654 37655 -- Macro: NO_DOT_IN_LABEL 37656 Define this macro if the assembler does not accept the character 37657 '.' in label names. By default constructors and destructors in G++ 37658 have names that use '.'. If this macro is defined, these names are 37659 rewritten to avoid '.'. 37660 37661 -- Macro: TYPE_ASM_OP 37662 A C string containing the appropriate assembler directive to 37663 specify the type of a symbol, without any arguments. On systems 37664 that use ELF, the default (in 'config/elfos.h') is '"\t.type\t"'; 37665 on other systems, the default is not to define this macro. 37666 37667 Define this macro only if it is correct to use the default 37668 definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 37669 need your own custom definition of this macro, or if you do not 37670 need explicit symbol types at all, do not define this macro. 37671 37672 -- Macro: TYPE_OPERAND_FMT 37673 A C string which specifies (using 'printf' syntax) the format of 37674 the second operand to 'TYPE_ASM_OP'. On systems that use ELF, the 37675 default (in 'config/elfos.h') is '"@%s"'; on other systems, the 37676 default is not to define this macro. 37677 37678 Define this macro only if it is correct to use the default 37679 definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 37680 need your own custom definition of this macro, or if you do not 37681 need explicit symbol types at all, do not define this macro. 37682 37683 -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE) 37684 A C statement (sans semicolon) to output to the stdio stream STREAM 37685 a directive telling the assembler that the type of the symbol NAME 37686 is TYPE. TYPE is a C string; currently, that string is always 37687 either '"function"' or '"object"', but you should not count on 37688 this. 37689 37690 If you define 'TYPE_ASM_OP' and 'TYPE_OPERAND_FMT', a default 37691 definition of this macro is provided. 37692 37693 -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL) 37694 A C statement (sans semicolon) to output to the stdio stream STREAM 37695 any text necessary for declaring the name NAME of a function which 37696 is being defined. This macro is responsible for outputting the 37697 label definition (perhaps using 'ASM_OUTPUT_FUNCTION_LABEL'). The 37698 argument DECL is the 'FUNCTION_DECL' tree node representing the 37699 function. 37700 37701 If this macro is not defined, then the function name is defined in 37702 the usual manner as a label (by means of 37703 'ASM_OUTPUT_FUNCTION_LABEL'). 37704 37705 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 37706 of this macro. 37707 37708 -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL) 37709 A C statement (sans semicolon) to output to the stdio stream STREAM 37710 any text necessary for declaring the size of a function which is 37711 being defined. The argument NAME is the name of the function. The 37712 argument DECL is the 'FUNCTION_DECL' tree node representing the 37713 function. 37714 37715 If this macro is not defined, then the function size is not 37716 defined. 37717 37718 You may wish to use 'ASM_OUTPUT_MEASURED_SIZE' in the definition of 37719 this macro. 37720 37721 -- Macro: ASM_DECLARE_COLD_FUNCTION_NAME (STREAM, NAME, DECL) 37722 A C statement (sans semicolon) to output to the stdio stream STREAM 37723 any text necessary for declaring the name NAME of a cold function 37724 partition which is being defined. This macro is responsible for 37725 outputting the label definition (perhaps using 37726 'ASM_OUTPUT_FUNCTION_LABEL'). The argument DECL is the 37727 'FUNCTION_DECL' tree node representing the function. 37728 37729 If this macro is not defined, then the cold partition name is 37730 defined in the usual manner as a label (by means of 37731 'ASM_OUTPUT_LABEL'). 37732 37733 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 37734 of this macro. 37735 37736 -- Macro: ASM_DECLARE_COLD_FUNCTION_SIZE (STREAM, NAME, DECL) 37737 A C statement (sans semicolon) to output to the stdio stream STREAM 37738 any text necessary for declaring the size of a cold function 37739 partition which is being defined. The argument NAME is the name of 37740 the cold partition of the function. The argument DECL is the 37741 'FUNCTION_DECL' tree node representing the function. 37742 37743 If this macro is not defined, then the partition size is not 37744 defined. 37745 37746 You may wish to use 'ASM_OUTPUT_MEASURED_SIZE' in the definition of 37747 this macro. 37748 37749 -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL) 37750 A C statement (sans semicolon) to output to the stdio stream STREAM 37751 any text necessary for declaring the name NAME of an initialized 37752 variable which is being defined. This macro must output the label 37753 definition (perhaps using 'ASM_OUTPUT_LABEL'). The argument DECL 37754 is the 'VAR_DECL' tree node representing the variable. 37755 37756 If this macro is not defined, then the variable name is defined in 37757 the usual manner as a label (by means of 'ASM_OUTPUT_LABEL'). 37758 37759 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' and/or 37760 'ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro. 37761 37762 -- Target Hook: void TARGET_ASM_DECLARE_CONSTANT_NAME (FILE *FILE, 37763 const char *NAME, const_tree EXPR, HOST_WIDE_INT SIZE) 37764 A target hook to output to the stdio stream FILE any text necessary 37765 for declaring the name NAME of a constant which is being defined. 37766 This target hook is responsible for outputting the label definition 37767 (perhaps using 'assemble_label'). The argument EXP is the value of 37768 the constant, and SIZE is the size of the constant in bytes. The 37769 NAME will be an internal label. 37770 37771 The default version of this target hook, define the NAME in the 37772 usual manner as a label (by means of 'assemble_label'). 37773 37774 You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in this target 37775 hook. 37776 37777 -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME) 37778 A C statement (sans semicolon) to output to the stdio stream STREAM 37779 any text necessary for claiming a register REGNO for a global 37780 variable DECL with name NAME. 37781 37782 If you don't define this macro, that is equivalent to defining it 37783 to do nothing. 37784 37785 -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND) 37786 A C statement (sans semicolon) to finish up declaring a variable 37787 name once the compiler has processed its initializer fully and thus 37788 has had a chance to determine the size of an array when controlled 37789 by an initializer. This is used on systems where it's necessary to 37790 declare something about the size of the object. 37791 37792 If you don't define this macro, that is equivalent to defining it 37793 to do nothing. 37794 37795 You may wish to use 'ASM_OUTPUT_SIZE_DIRECTIVE' and/or 37796 'ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro. 37797 37798 -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const 37799 char *NAME) 37800 This target hook is a function to output to the stdio stream STREAM 37801 some commands that will make the label NAME global; that is, 37802 available for reference from other files. 37803 37804 The default implementation relies on a proper definition of 37805 'GLOBAL_ASM_OP'. 37806 37807 -- Target Hook: void TARGET_ASM_GLOBALIZE_DECL_NAME (FILE *STREAM, tree 37808 DECL) 37809 This target hook is a function to output to the stdio stream STREAM 37810 some commands that will make the name associated with DECL global; 37811 that is, available for reference from other files. 37812 37813 The default implementation uses the TARGET_ASM_GLOBALIZE_LABEL 37814 target hook. 37815 37816 -- Target Hook: void TARGET_ASM_ASSEMBLE_UNDEFINED_DECL (FILE *STREAM, 37817 const char *NAME, const_tree DECL) 37818 This target hook is a function to output to the stdio stream STREAM 37819 some commands that will declare the name associated with DECL which 37820 is not defined in the current translation unit. Most assemblers do 37821 not require anything to be output in this case. 37822 37823 -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME) 37824 A C statement (sans semicolon) to output to the stdio stream STREAM 37825 some commands that will make the label NAME weak; that is, 37826 available for reference from other files but only used if no other 37827 definition is available. Use the expression 'assemble_name 37828 (STREAM, NAME)' to output the name itself; before and after that, 37829 output the additional assembler syntax for making that name weak, 37830 and a newline. 37831 37832 If you don't define this macro or 'ASM_WEAKEN_DECL', GCC will not 37833 support weak symbols and you should not define the 'SUPPORTS_WEAK' 37834 macro. 37835 37836 -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE) 37837 Combines (and replaces) the function of 'ASM_WEAKEN_LABEL' and 37838 'ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function 37839 or variable decl. If VALUE is not 'NULL', this C statement should 37840 output to the stdio stream STREAM assembler code which defines 37841 (equates) the weak symbol NAME to have the value VALUE. If VALUE 37842 is 'NULL', it should output commands to make NAME weak. 37843 37844 -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE) 37845 Outputs a directive that enables NAME to be used to refer to symbol 37846 VALUE with weak-symbol semantics. 'decl' is the declaration of 37847 'name'. 37848 37849 -- Macro: SUPPORTS_WEAK 37850 A preprocessor constant expression which evaluates to true if the 37851 target supports weak symbols. 37852 37853 If you don't define this macro, 'defaults.h' provides a default 37854 definition. If either 'ASM_WEAKEN_LABEL' or 'ASM_WEAKEN_DECL' is 37855 defined, the default definition is '1'; otherwise, it is '0'. 37856 37857 -- Macro: TARGET_SUPPORTS_WEAK 37858 A C expression which evaluates to true if the target supports weak 37859 symbols. 37860 37861 If you don't define this macro, 'defaults.h' provides a default 37862 definition. The default definition is '(SUPPORTS_WEAK)'. Define 37863 this macro if you want to control weak symbol support with a 37864 compiler flag such as '-melf'. 37865 37866 -- Macro: MAKE_DECL_ONE_ONLY (DECL) 37867 A C statement (sans semicolon) to mark DECL to be emitted as a 37868 public symbol such that extra copies in multiple translation units 37869 will be discarded by the linker. Define this macro if your object 37870 file format provides support for this concept, such as the 'COMDAT' 37871 section flags in the Microsoft Windows PE/COFF format, and this 37872 support requires changes to DECL, such as putting it in a separate 37873 section. 37874 37875 -- Macro: SUPPORTS_ONE_ONLY 37876 A C expression which evaluates to true if the target supports 37877 one-only semantics. 37878 37879 If you don't define this macro, 'varasm.c' provides a default 37880 definition. If 'MAKE_DECL_ONE_ONLY' is defined, the default 37881 definition is '1'; otherwise, it is '0'. Define this macro if you 37882 want to control one-only symbol support with a compiler flag, or if 37883 setting the 'DECL_ONE_ONLY' flag is enough to mark a declaration to 37884 be emitted as one-only. 37885 37886 -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, int 37887 VISIBILITY) 37888 This target hook is a function to output to ASM_OUT_FILE some 37889 commands that will make the symbol(s) associated with DECL have 37890 hidden, protected or internal visibility as specified by 37891 VISIBILITY. 37892 37893 -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC 37894 A C expression that evaluates to true if the target's linker 37895 expects that weak symbols do not appear in a static archive's table 37896 of contents. The default is '0'. 37897 37898 Leaving weak symbols out of an archive's table of contents means 37899 that, if a symbol will only have a definition in one translation 37900 unit and will have undefined references from other translation 37901 units, that symbol should not be weak. Defining this macro to be 37902 nonzero will thus have the effect that certain symbols that would 37903 normally be weak (explicit template instantiations, and vtables for 37904 polymorphic classes with noninline key methods) will instead be 37905 nonweak. 37906 37907 The C++ ABI requires this macro to be zero. Define this macro for 37908 targets where full C++ ABI compliance is impossible and where 37909 linker restrictions require weak symbols to be left out of a static 37910 archive's table of contents. 37911 37912 -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME) 37913 A C statement (sans semicolon) to output to the stdio stream STREAM 37914 any text necessary for declaring the name of an external symbol 37915 named NAME which is referenced in this compilation but not defined. 37916 The value of DECL is the tree node for the declaration. 37917 37918 This macro need not be defined if it does not need to output 37919 anything. The GNU assembler and most Unix assemblers don't require 37920 anything. 37921 37922 -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF) 37923 This target hook is a function to output to ASM_OUT_FILE an 37924 assembler pseudo-op to declare a library function name external. 37925 The name of the library function is given by SYMREF, which is a 37926 'symbol_ref'. 37927 37928 -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (const char 37929 *SYMBOL) 37930 This target hook is a function to output to ASM_OUT_FILE an 37931 assembler directive to annotate SYMBOL as used. The Darwin target 37932 uses the .no_dead_code_strip directive. 37933 37934 -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME) 37935 A C statement (sans semicolon) to output to the stdio stream STREAM 37936 a reference in assembler syntax to a label named NAME. This should 37937 add '_' to the front of the name, if that is customary on your 37938 operating system, as it is in most Berkeley Unix systems. This 37939 macro is used in 'assemble_name'. 37940 37941 -- Target Hook: tree TARGET_MANGLE_ASSEMBLER_NAME (const char *NAME) 37942 Given a symbol NAME, perform same mangling as 'varasm.c''s 37943 'assemble_name', but in memory rather than to a file stream, 37944 returning result as an 'IDENTIFIER_NODE'. Required for correct LTO 37945 symtabs. The default implementation calls the 37946 'TARGET_STRIP_NAME_ENCODING' hook and then prepends the 37947 'USER_LABEL_PREFIX', if any. 37948 37949 -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM) 37950 A C statement (sans semicolon) to output a reference to 37951 'SYMBOL_REF' SYM. If not defined, 'assemble_name' will be used to 37952 output the name of the symbol. This macro may be used to modify 37953 the way a symbol is referenced depending on information encoded by 37954 'TARGET_ENCODE_SECTION_INFO'. 37955 37956 -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF) 37957 A C statement (sans semicolon) to output a reference to BUF, the 37958 result of 'ASM_GENERATE_INTERNAL_LABEL'. If not defined, 37959 'assemble_name' will be used to output the name of the symbol. 37960 This macro is not used by 'output_asm_label', or the '%l' specifier 37961 that calls it; the intention is that this macro should be set when 37962 it is necessary to output a label differently when its address is 37963 being taken. 37964 37965 -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const 37966 char *PREFIX, unsigned long LABELNO) 37967 A function to output to the stdio stream STREAM a label whose name 37968 is made from the string PREFIX and the number LABELNO. 37969 37970 It is absolutely essential that these labels be distinct from the 37971 labels used for user-level functions and variables. Otherwise, 37972 certain programs will have name conflicts with internal labels. 37973 37974 It is desirable to exclude internal labels from the symbol table of 37975 the object file. Most assemblers have a naming convention for 37976 labels that should be excluded; on many systems, the letter 'L' at 37977 the beginning of a label has this effect. You should find out what 37978 convention your system uses, and follow it. 37979 37980 The default version of this function utilizes 37981 'ASM_GENERATE_INTERNAL_LABEL'. 37982 37983 -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM) 37984 A C statement to output to the stdio stream STREAM a debug info 37985 label whose name is made from the string PREFIX and the number NUM. 37986 This is useful for VLIW targets, where debug info labels may need 37987 to be treated differently than branch target labels. On some 37988 systems, branch target labels must be at the beginning of 37989 instruction bundles, but debug info labels can occur in the middle 37990 of instruction bundles. 37991 37992 If this macro is not defined, then 37993 '(*targetm.asm_out.internal_label)' will be used. 37994 37995 -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM) 37996 A C statement to store into the string STRING a label whose name is 37997 made from the string PREFIX and the number NUM. 37998 37999 This string, when output subsequently by 'assemble_name', should 38000 produce the output that '(*targetm.asm_out.internal_label)' would 38001 produce with the same PREFIX and NUM. 38002 38003 If the string begins with '*', then 'assemble_name' will output the 38004 rest of the string unchanged. It is often convenient for 38005 'ASM_GENERATE_INTERNAL_LABEL' to use '*' in this way. If the 38006 string doesn't start with '*', then 'ASM_OUTPUT_LABELREF' gets to 38007 output the string, and may change it. (Of course, 38008 'ASM_OUTPUT_LABELREF' is also part of your machine description, so 38009 you should know what it does on your machine.) 38010 38011 -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER) 38012 A C expression to assign to OUTVAR (which is a variable of type 38013 'char *') a newly allocated string made from the string NAME and 38014 the number NUMBER, with some suitable punctuation added. Use 38015 'alloca' to get space for the string. 38016 38017 The string will be used as an argument to 'ASM_OUTPUT_LABELREF' to 38018 produce an assembler label for an internal static variable whose 38019 name is NAME. Therefore, the string must be such as to result in 38020 valid assembler code. The argument NUMBER is different each time 38021 this macro is executed; it prevents conflicts between 38022 similarly-named internal static variables in different scopes. 38023 38024 Ideally this string should not be a valid C identifier, to prevent 38025 any conflict with the user's own symbols. Most assemblers allow 38026 periods or percent signs in assembler symbols; putting at least one 38027 of these between the name and the number will suffice. 38028 38029 If this macro is not defined, a default definition will be provided 38030 which is correct for most systems. 38031 38032 -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE) 38033 A C statement to output to the stdio stream STREAM assembler code 38034 which defines (equates) the symbol NAME to have the value VALUE. 38035 38036 If 'SET_ASM_OP' is defined, a default definition is provided which 38037 is correct for most systems. 38038 38039 -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME, 38040 DECL_OF_VALUE) 38041 A C statement to output to the stdio stream STREAM assembler code 38042 which defines (equates) the symbol whose tree node is DECL_OF_NAME 38043 to have the value of the tree node DECL_OF_VALUE. This macro will 38044 be used in preference to 'ASM_OUTPUT_DEF' if it is defined and if 38045 the tree nodes are available. 38046 38047 If 'SET_ASM_OP' is defined, a default definition is provided which 38048 is correct for most systems. 38049 38050 -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE) 38051 A C statement that evaluates to true if the assembler code which 38052 defines (equates) the symbol whose tree node is DECL_OF_NAME to 38053 have the value of the tree node DECL_OF_VALUE should be emitted 38054 near the end of the current compilation unit. The default is to 38055 not defer output of defines. This macro affects defines output by 38056 'ASM_OUTPUT_DEF' and 'ASM_OUTPUT_DEF_FROM_DECLS'. 38057 38058 -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE) 38059 A C statement to output to the stdio stream STREAM assembler code 38060 which defines (equates) the weak symbol NAME to have the value 38061 VALUE. If VALUE is 'NULL', it defines NAME as an undefined weak 38062 symbol. 38063 38064 Define this macro if the target only supports weak aliases; define 38065 'ASM_OUTPUT_DEF' instead if possible. 38066 38067 -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME, 38068 SEL_NAME) 38069 Define this macro to override the default assembler names used for 38070 Objective-C methods. 38071 38072 The default name is a unique method number followed by the name of 38073 the class (e.g. '_1_Foo'). For methods in categories, the name of 38074 the category is also included in the assembler name (e.g. 38075 '_1_Foo_Bar'). 38076 38077 These names are safe on most systems, but make debugging difficult 38078 since the method's selector is not present in the name. Therefore, 38079 particular systems define other ways of computing names. 38080 38081 BUF is an expression of type 'char *' which gives you a buffer in 38082 which to store the name; its length is as long as CLASS_NAME, 38083 CAT_NAME and SEL_NAME put together, plus 50 characters extra. 38084 38085 The argument IS_INST specifies whether the method is an instance 38086 method or a class method; CLASS_NAME is the name of the class; 38087 CAT_NAME is the name of the category (or 'NULL' if the method is 38088 not in a category); and SEL_NAME is the name of the selector. 38089 38090 On systems where the assembler can handle quoted names, you can use 38091 this macro to provide more human-readable names. 38092 38093 38094File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format 38095 3809618.20.5 How Initialization Functions Are Handled 38097------------------------------------------------ 38098 38099The compiled code for certain languages includes "constructors" (also 38100called "initialization routines")--functions to initialize data in the 38101program when the program is started. These functions need to be called 38102before the program is "started"--that is to say, before 'main' is 38103called. 38104 38105 Compiling some languages generates "destructors" (also called 38106"termination routines") that should be called when the program 38107terminates. 38108 38109 To make the initialization and termination functions work, the compiler 38110must output something in the assembler code to cause those functions to 38111be called at the appropriate time. When you port the compiler to a new 38112system, you need to specify how to do this. 38113 38114 There are two major ways that GCC currently supports the execution of 38115initialization and termination functions. Each way has two variants. 38116Much of the structure is common to all four variations. 38117 38118 The linker must build two lists of these functions--a list of 38119initialization functions, called '__CTOR_LIST__', and a list of 38120termination functions, called '__DTOR_LIST__'. 38121 38122 Each list always begins with an ignored function pointer (which may 38123hold 0, -1, or a count of the function pointers after it, depending on 38124the environment). This is followed by a series of zero or more function 38125pointers to constructors (or destructors), followed by a function 38126pointer containing zero. 38127 38128 Depending on the operating system and its executable file format, 38129either 'crtstuff.c' or 'libgcc2.c' traverses these lists at startup time 38130and exit time. Constructors are called in reverse order of the list; 38131destructors in forward order. 38132 38133 The best way to handle static constructors works only for object file 38134formats which provide arbitrarily-named sections. A section is set 38135aside for a list of constructors, and another for a list of destructors. 38136Traditionally these are called '.ctors' and '.dtors'. Each object file 38137that defines an initialization function also puts a word in the 38138constructor section to point to that function. The linker accumulates 38139all these words into one contiguous '.ctors' section. Termination 38140functions are handled similarly. 38141 38142 This method will be chosen as the default by 'target-def.h' if 38143'TARGET_ASM_NAMED_SECTION' is defined. A target that does not support 38144arbitrary sections, but does support special designated constructor and 38145destructor sections may define 'CTORS_SECTION_ASM_OP' and 38146'DTORS_SECTION_ASM_OP' to achieve the same effect. 38147 38148 When arbitrary sections are available, there are two variants, 38149depending upon how the code in 'crtstuff.c' is called. On systems that 38150support a ".init" section which is executed at program startup, parts of 38151'crtstuff.c' are compiled into that section. The program is linked by 38152the 'gcc' driver like this: 38153 38154 ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o 38155 38156 The prologue of a function ('__init') appears in the '.init' section of 38157'crti.o'; the epilogue appears in 'crtn.o'. Likewise for the function 38158'__fini' in the ".fini" section. Normally these files are provided by 38159the operating system or by the GNU C library, but are provided by GCC 38160for a few targets. 38161 38162 The objects 'crtbegin.o' and 'crtend.o' are (for most targets) compiled 38163from 'crtstuff.c'. They contain, among other things, code fragments 38164within the '.init' and '.fini' sections that branch to routines in the 38165'.text' section. The linker will pull all parts of a section together, 38166which results in a complete '__init' function that invokes the routines 38167we need at startup. 38168 38169 To use this variant, you must define the 'INIT_SECTION_ASM_OP' macro 38170properly. 38171 38172 If no init section is available, when GCC compiles any function called 38173'main' (or more accurately, any function designated as a program entry 38174point by the language front end calling 'expand_main_function'), it 38175inserts a procedure call to '__main' as the first executable code after 38176the function prologue. The '__main' function is defined in 'libgcc2.c' 38177and runs the global constructors. 38178 38179 In file formats that don't support arbitrary sections, there are again 38180two variants. In the simplest variant, the GNU linker (GNU 'ld') and an 38181'a.out' format must be used. In this case, 'TARGET_ASM_CONSTRUCTOR' is 38182defined to produce a '.stabs' entry of type 'N_SETT', referencing the 38183name '__CTOR_LIST__', and with the address of the void function 38184containing the initialization code as its value. The GNU linker 38185recognizes this as a request to add the value to a "set"; the values are 38186accumulated, and are eventually placed in the executable as a vector in 38187the format described above, with a leading (ignored) count and a 38188trailing zero element. 'TARGET_ASM_DESTRUCTOR' is handled similarly. 38189Since no init section is available, the absence of 'INIT_SECTION_ASM_OP' 38190causes the compilation of 'main' to call '__main' as above, starting the 38191initialization process. 38192 38193 The last variant uses neither arbitrary sections nor the GNU linker. 38194This is preferable when you want to do dynamic linking and when using 38195file formats which the GNU linker does not support, such as 'ECOFF'. In 38196this case, 'TARGET_HAVE_CTORS_DTORS' is false, initialization and 38197termination functions are recognized simply by their names. This 38198requires an extra program in the linkage step, called 'collect2'. This 38199program pretends to be the linker, for use with GCC; it does its job by 38200running the ordinary linker, but also arranges to include the vectors of 38201initialization and termination functions. These functions are called 38202via '__main' as described above. In order to use this method, 38203'use_collect2' must be defined in the target in 'config.gcc'. 38204 38205 The following section describes the specific macros that control and 38206customize the handling of initialization and termination functions. 38207 38208 38209File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format 38210 3821118.20.6 Macros Controlling Initialization Routines 38212-------------------------------------------------- 38213 38214Here are the macros that control how the compiler handles initialization 38215and termination functions: 38216 38217 -- Macro: INIT_SECTION_ASM_OP 38218 If defined, a C string constant, including spacing, for the 38219 assembler operation to identify the following data as 38220 initialization code. If not defined, GCC will assume such a 38221 section does not exist. When you are using special sections for 38222 initialization and termination functions, this macro also controls 38223 how 'crtstuff.c' and 'libgcc2.c' arrange to run the initialization 38224 functions. 38225 38226 -- Macro: HAS_INIT_SECTION 38227 If defined, 'main' will not call '__main' as described above. This 38228 macro should be defined for systems that control start-up code on a 38229 symbol-by-symbol basis, such as OSF/1, and should not be defined 38230 explicitly for systems that support 'INIT_SECTION_ASM_OP'. 38231 38232 -- Macro: LD_INIT_SWITCH 38233 If defined, a C string constant for a switch that tells the linker 38234 that the following symbol is an initialization routine. 38235 38236 -- Macro: LD_FINI_SWITCH 38237 If defined, a C string constant for a switch that tells the linker 38238 that the following symbol is a finalization routine. 38239 38240 -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC) 38241 If defined, a C statement that will write a function that can be 38242 automatically called when a shared library is loaded. The function 38243 should call FUNC, which takes no arguments. If not defined, and 38244 the object format requires an explicit initialization function, 38245 then a function called '_GLOBAL__DI' will be generated. 38246 38247 This function and the following one are used by collect2 when 38248 linking a shared library that needs constructors or destructors, or 38249 has DWARF2 exception tables embedded in the code. 38250 38251 -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC) 38252 If defined, a C statement that will write a function that can be 38253 automatically called when a shared library is unloaded. The 38254 function should call FUNC, which takes no arguments. If not 38255 defined, and the object format requires an explicit finalization 38256 function, then a function called '_GLOBAL__DD' will be generated. 38257 38258 -- Macro: INVOKE__main 38259 If defined, 'main' will call '__main' despite the presence of 38260 'INIT_SECTION_ASM_OP'. This macro should be defined for systems 38261 where the init section is not actually run automatically, but is 38262 still useful for collecting the lists of constructors and 38263 destructors. 38264 38265 -- Macro: SUPPORTS_INIT_PRIORITY 38266 If nonzero, the C++ 'init_priority' attribute is supported and the 38267 compiler should emit instructions to control the order of 38268 initialization of objects. If zero, the compiler will issue an 38269 error message upon encountering an 'init_priority' attribute. 38270 38271 -- Target Hook: bool TARGET_HAVE_CTORS_DTORS 38272 This value is true if the target supports some "native" method of 38273 collecting constructors and destructors to be run at startup and 38274 exit. It is false if we must use 'collect2'. 38275 38276 -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY) 38277 If defined, a function that outputs assembler code to arrange to 38278 call the function referenced by SYMBOL at initialization time. 38279 38280 Assume that SYMBOL is a 'SYMBOL_REF' for a function taking no 38281 arguments and with no return value. If the target supports 38282 initialization priorities, PRIORITY is a value between 0 and 38283 'MAX_INIT_PRIORITY'; otherwise it must be 'DEFAULT_INIT_PRIORITY'. 38284 38285 If this macro is not defined by the target, a suitable default will 38286 be chosen if (1) the target supports arbitrary section names, (2) 38287 the target defines 'CTORS_SECTION_ASM_OP', or (3) 'USE_COLLECT2' is 38288 not defined. 38289 38290 -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY) 38291 This is like 'TARGET_ASM_CONSTRUCTOR' but used for termination 38292 functions rather than initialization functions. 38293 38294 If 'TARGET_HAVE_CTORS_DTORS' is true, the initialization routine 38295generated for the generated object file will have static linkage. 38296 38297 If your system uses 'collect2' as the means of processing constructors, 38298then that program normally uses 'nm' to scan an object file for 38299constructor functions to be called. 38300 38301 On certain kinds of systems, you can define this macro to make 38302'collect2' work faster (and, in some cases, make it work at all): 38303 38304 -- Macro: OBJECT_FORMAT_COFF 38305 Define this macro if the system uses COFF (Common Object File 38306 Format) object files, so that 'collect2' can assume this format and 38307 scan object files directly for dynamic constructor/destructor 38308 functions. 38309 38310 This macro is effective only in a native compiler; 'collect2' as 38311 part of a cross compiler always uses 'nm' for the target machine. 38312 38313 -- Macro: REAL_NM_FILE_NAME 38314 Define this macro as a C string constant containing the file name 38315 to use to execute 'nm'. The default is to search the path normally 38316 for 'nm'. 38317 38318 -- Macro: NM_FLAGS 38319 'collect2' calls 'nm' to scan object files for static constructors 38320 and destructors and LTO info. By default, '-n' is passed. Define 38321 'NM_FLAGS' to a C string constant if other options are needed to 38322 get the same output format as GNU 'nm -n' produces. 38323 38324 If your system supports shared libraries and has a program to list the 38325dynamic dependencies of a given library or executable, you can define 38326these macros to enable support for running initialization and 38327termination functions in shared libraries: 38328 38329 -- Macro: LDD_SUFFIX 38330 Define this macro to a C string constant containing the name of the 38331 program which lists dynamic dependencies, like 'ldd' under SunOS 4. 38332 38333 -- Macro: PARSE_LDD_OUTPUT (PTR) 38334 Define this macro to be C code that extracts filenames from the 38335 output of the program denoted by 'LDD_SUFFIX'. PTR is a variable 38336 of type 'char *' that points to the beginning of a line of output 38337 from 'LDD_SUFFIX'. If the line lists a dynamic dependency, the 38338 code must advance PTR to the beginning of the filename on that 38339 line. Otherwise, it must set PTR to 'NULL'. 38340 38341 -- Macro: SHLIB_SUFFIX 38342 Define this macro to a C string constant containing the default 38343 shared library extension of the target (e.g., '".so"'). 'collect2' 38344 strips version information after this suffix when generating global 38345 constructor and destructor names. This define is only needed on 38346 targets that use 'collect2' to process constructors and 38347 destructors. 38348 38349 38350File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format 38351 3835218.20.7 Output of Assembler Instructions 38353---------------------------------------- 38354 38355This describes assembler instruction output. 38356 38357 -- Macro: REGISTER_NAMES 38358 A C initializer containing the assembler's names for the machine 38359 registers, each one as a C string constant. This is what 38360 translates register numbers in the compiler into assembler 38361 language. 38362 38363 -- Macro: ADDITIONAL_REGISTER_NAMES 38364 If defined, a C initializer for an array of structures containing a 38365 name and a register number. This macro defines additional names 38366 for hard registers, thus allowing the 'asm' option in declarations 38367 to refer to registers using alternate names. 38368 38369 -- Macro: OVERLAPPING_REGISTER_NAMES 38370 If defined, a C initializer for an array of structures containing a 38371 name, a register number and a count of the number of consecutive 38372 machine registers the name overlaps. This macro defines additional 38373 names for hard registers, thus allowing the 'asm' option in 38374 declarations to refer to registers using alternate names. Unlike 38375 'ADDITIONAL_REGISTER_NAMES', this macro should be used when the 38376 register name implies multiple underlying registers. 38377 38378 This macro should be used when it is important that a clobber in an 38379 'asm' statement clobbers all the underlying values implied by the 38380 register name. For example, on ARM, clobbering the 38381 double-precision VFP register "d0" implies clobbering both 38382 single-precision registers "s0" and "s1". 38383 38384 -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR) 38385 Define this macro if you are using an unusual assembler that 38386 requires different names for the machine instructions. 38387 38388 The definition is a C statement or statements which output an 38389 assembler instruction opcode to the stdio stream STREAM. The 38390 macro-operand PTR is a variable of type 'char *' which points to 38391 the opcode name in its "internal" form--the form that is written in 38392 the machine description. The definition should output the opcode 38393 name to STREAM, performing any translation you desire, and 38394 increment the variable PTR to point at the end of the opcode so 38395 that it will not be output twice. 38396 38397 In fact, your macro definition may process less than the entire 38398 opcode name, or more than the opcode name; but if you want to 38399 process text that includes '%'-sequences to substitute operands, 38400 you must take care of the substitution yourself. Just be sure to 38401 increment PTR over whatever text should not be output normally. 38402 38403 If you need to look at the operand values, they can be found as the 38404 elements of 'recog_data.operand'. 38405 38406 If the macro definition does nothing, the instruction is output in 38407 the usual way. 38408 38409 -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS) 38410 If defined, a C statement to be executed just prior to the output 38411 of assembler code for INSN, to modify the extracted operands so 38412 they will be output differently. 38413 38414 Here the argument OPVEC is the vector containing the operands 38415 extracted from INSN, and NOPERANDS is the number of elements of the 38416 vector which contain meaningful data for this insn. The contents 38417 of this vector are what will be used to convert the insn template 38418 into assembler code, so you can change the assembler output by 38419 changing the contents of the vector. 38420 38421 This macro is useful when various assembler syntaxes share a single 38422 file of instruction patterns; by defining this macro differently, 38423 you can cause a large class of instructions to be output 38424 differently (such as with rearranged operands). Naturally, 38425 variations in assembler syntax affecting individual insn patterns 38426 ought to be handled by writing conditional output routines in those 38427 patterns. 38428 38429 If this macro is not defined, it is equivalent to a null statement. 38430 38431 -- Target Hook: void TARGET_ASM_FINAL_POSTSCAN_INSN (FILE *FILE, 38432 rtx_insn *INSN, rtx *OPVEC, int NOPERANDS) 38433 If defined, this target hook is a function which is executed just 38434 after the output of assembler code for INSN, to change the mode of 38435 the assembler if necessary. 38436 38437 Here the argument OPVEC is the vector containing the operands 38438 extracted from INSN, and NOPERANDS is the number of elements of the 38439 vector which contain meaningful data for this insn. The contents 38440 of this vector are what was used to convert the insn template into 38441 assembler code, so you can change the assembler mode by checking 38442 the contents of the vector. 38443 38444 -- Macro: PRINT_OPERAND (STREAM, X, CODE) 38445 A C compound statement to output to stdio stream STREAM the 38446 assembler syntax for an instruction operand X. X is an RTL 38447 expression. 38448 38449 CODE is a value that can be used to specify one of several ways of 38450 printing the operand. It is used when identical operands must be 38451 printed differently depending on the context. CODE comes from the 38452 '%' specification that was used to request printing of the operand. 38453 If the specification was just '%DIGIT' then CODE is 0; if the 38454 specification was '%LTR DIGIT' then CODE is the ASCII code for LTR. 38455 38456 If X is a register, this macro should print the register's name. 38457 The names can be found in an array 'reg_names' whose type is 'char 38458 *[]'. 'reg_names' is initialized from 'REGISTER_NAMES'. 38459 38460 When the machine description has a specification '%PUNCT' (a '%' 38461 followed by a punctuation character), this macro is called with a 38462 null pointer for X and the punctuation character for CODE. 38463 38464 -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE) 38465 A C expression which evaluates to true if CODE is a valid 38466 punctuation character for use in the 'PRINT_OPERAND' macro. If 38467 'PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no 38468 punctuation characters (except for the standard one, '%') are used 38469 in this way. 38470 38471 -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X) 38472 A C compound statement to output to stdio stream STREAM the 38473 assembler syntax for an instruction operand that is a memory 38474 reference whose address is X. X is an RTL expression. 38475 38476 On some machines, the syntax for a symbolic address depends on the 38477 section that the address refers to. On these machines, define the 38478 hook 'TARGET_ENCODE_SECTION_INFO' to store the information into the 38479 'symbol_ref', and then check for it here. *Note Assembler 38480 Format::. 38481 38482 -- Macro: DBR_OUTPUT_SEQEND (FILE) 38483 A C statement, to be executed after all slot-filler instructions 38484 have been output. If necessary, call 'dbr_sequence_length' to 38485 determine the number of slots filled in a sequence (zero if not 38486 currently outputting a sequence), to decide how many no-ops to 38487 output, or whatever. 38488 38489 Don't define this macro if it has nothing to do, but it is helpful 38490 in reading assembly output if the extent of the delay sequence is 38491 made explicit (e.g. with white space). 38492 38493 Note that output routines for instructions with delay slots must be 38494prepared to deal with not being output as part of a sequence (i.e. when 38495the scheduling pass is not run, or when no slot fillers could be found.) 38496The variable 'final_sequence' is null when not processing a sequence, 38497otherwise it contains the 'sequence' rtx being output. 38498 38499 -- Macro: REGISTER_PREFIX 38500 -- Macro: LOCAL_LABEL_PREFIX 38501 -- Macro: USER_LABEL_PREFIX 38502 -- Macro: IMMEDIATE_PREFIX 38503 If defined, C string expressions to be used for the '%R', '%L', 38504 '%U', and '%I' options of 'asm_fprintf' (see 'final.c'). These are 38505 useful when a single 'md' file must support multiple assembler 38506 formats. In that case, the various 'tm.h' files can define these 38507 macros differently. 38508 38509 -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT) 38510 If defined this macro should expand to a series of 'case' 38511 statements which will be parsed inside the 'switch' statement of 38512 the 'asm_fprintf' function. This allows targets to define extra 38513 printf formats which may useful when generating their assembler 38514 statements. Note that uppercase letters are reserved for future 38515 generic extensions to asm_fprintf, and so are not available to 38516 target specific code. The output file is given by the parameter 38517 FILE. The varargs input pointer is ARGPTR and the rest of the 38518 format string, starting the character after the one that is being 38519 switched upon, is pointed to by FORMAT. 38520 38521 -- Macro: ASSEMBLER_DIALECT 38522 If your target supports multiple dialects of assembler language 38523 (such as different opcodes), define this macro as a C expression 38524 that gives the numeric index of the assembler language dialect to 38525 use, with zero as the first variant. 38526 38527 If this macro is defined, you may use constructs of the form 38528 '{option0|option1|option2...}' 38529 in the output templates of patterns (*note Output Template::) or in 38530 the first argument of 'asm_fprintf'. This construct outputs 38531 'option0', 'option1', 'option2', etc., if the value of 38532 'ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters 38533 within these strings retain their usual meaning. If there are 38534 fewer alternatives within the braces than the value of 38535 'ASSEMBLER_DIALECT', the construct outputs nothing. If it's needed 38536 to print curly braces or '|' character in assembler output 38537 directly, '%{', '%}' and '%|' can be used. 38538 38539 If you do not define this macro, the characters '{', '|' and '}' do 38540 not have any special meaning when used in templates or operands to 38541 'asm_fprintf'. 38542 38543 Define the macros 'REGISTER_PREFIX', 'LOCAL_LABEL_PREFIX', 38544 'USER_LABEL_PREFIX' and 'IMMEDIATE_PREFIX' if you can express the 38545 variations in assembler language syntax with that mechanism. 38546 Define 'ASSEMBLER_DIALECT' and use the '{option0|option1}' syntax 38547 if the syntax variant are larger and involve such things as 38548 different opcodes or operand order. 38549 38550 -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO) 38551 A C expression to output to STREAM some assembler code which will 38552 push hard register number REGNO onto the stack. The code need not 38553 be optimal, since this macro is used only when profiling. 38554 38555 -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO) 38556 A C expression to output to STREAM some assembler code which will 38557 pop hard register number REGNO off of the stack. The code need not 38558 be optimal, since this macro is used only when profiling. 38559 38560 38561File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format 38562 3856318.20.8 Output of Dispatch Tables 38564--------------------------------- 38565 38566This concerns dispatch tables. 38567 38568 -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL) 38569 A C statement to output to the stdio stream STREAM an assembler 38570 pseudo-instruction to generate a difference between two labels. 38571 VALUE and REL are the numbers of two internal labels. The 38572 definitions of these labels are output using 38573 '(*targetm.asm_out.internal_label)', and they must be printed in 38574 the same way here. For example, 38575 38576 fprintf (STREAM, "\t.word L%d-L%d\n", 38577 VALUE, REL) 38578 38579 You must provide this macro on machines where the addresses in a 38580 dispatch table are relative to the table's own address. If 38581 defined, GCC will also use this macro on all machines when 38582 producing PIC. BODY is the body of the 'ADDR_DIFF_VEC'; it is 38583 provided so that the mode and flags can be read. 38584 38585 -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE) 38586 This macro should be provided on machines where the addresses in a 38587 dispatch table are absolute. 38588 38589 The definition should be a C statement to output to the stdio 38590 stream STREAM an assembler pseudo-instruction to generate a 38591 reference to a label. VALUE is the number of an internal label 38592 whose definition is output using 38593 '(*targetm.asm_out.internal_label)'. For example, 38594 38595 fprintf (STREAM, "\t.word L%d\n", VALUE) 38596 38597 -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE) 38598 Define this if the label before a jump-table needs to be output 38599 specially. The first three arguments are the same as for 38600 '(*targetm.asm_out.internal_label)'; the fourth argument is the 38601 jump-table which follows (a 'jump_table_data' containing an 38602 'addr_vec' or 'addr_diff_vec'). 38603 38604 This feature is used on system V to output a 'swbeg' statement for 38605 the table. 38606 38607 If this macro is not defined, these labels are output with 38608 '(*targetm.asm_out.internal_label)'. 38609 38610 -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE) 38611 Define this if something special must be output at the end of a 38612 jump-table. The definition should be a C statement to be executed 38613 after the assembler code for the table is written. It should write 38614 the appropriate code to stdio stream STREAM. The argument TABLE is 38615 the jump-table insn, and NUM is the label-number of the preceding 38616 label. 38617 38618 If this macro is not defined, nothing special is output at the end 38619 of the jump-table. 38620 38621 -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (FILE *STREAM, tree 38622 DECL, int FOR_EH, int EMPTY) 38623 This target hook emits a label at the beginning of each FDE. It 38624 should be defined on targets where FDEs need special labels, and it 38625 should write the appropriate label, for the FDE associated with the 38626 function declaration DECL, to the stdio stream STREAM. The third 38627 argument, FOR_EH, is a boolean: true if this is for an exception 38628 table. The fourth argument, EMPTY, is a boolean: true if this is a 38629 placeholder label for an omitted FDE. 38630 38631 The default is that FDEs are not given nonlocal labels. 38632 38633 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL (FILE *STREAM) 38634 This target hook emits a label at the beginning of the exception 38635 table. It should be defined on targets where it is desirable for 38636 the table to be broken up according to function. 38637 38638 The default is that no label is emitted. 38639 38640 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_PERSONALITY (rtx 38641 PERSONALITY) 38642 If the target implements 'TARGET_ASM_UNWIND_EMIT', this hook may be 38643 used to emit a directive to install a personality hook into the 38644 unwind info. This hook should not be used if dwarf2 unwind info is 38645 used. 38646 38647 -- Target Hook: void TARGET_ASM_UNWIND_EMIT (FILE *STREAM, rtx_insn 38648 *INSN) 38649 This target hook emits assembly directives required to unwind the 38650 given instruction. This is only used when 38651 'TARGET_EXCEPT_UNWIND_INFO' returns 'UI_TARGET'. 38652 38653 -- Target Hook: bool TARGET_ASM_UNWIND_EMIT_BEFORE_INSN 38654 True if the 'TARGET_ASM_UNWIND_EMIT' hook should be called before 38655 the assembly for INSN has been emitted, false if the hook should be 38656 called afterward. 38657 38658 38659File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format 38660 3866118.20.9 Assembler Commands for Exception Regions 38662------------------------------------------------ 38663 38664This describes commands marking the start and the end of an exception 38665region. 38666 38667 -- Macro: EH_FRAME_SECTION_NAME 38668 If defined, a C string constant for the name of the section 38669 containing exception handling frame unwind information. If not 38670 defined, GCC will provide a default definition if the target 38671 supports named sections. 'crtstuff.c' uses this macro to switch to 38672 the appropriate section. 38673 38674 You should define this symbol if your target supports DWARF 2 frame 38675 unwind information and the default definition does not work. 38676 38677 -- Macro: EH_FRAME_THROUGH_COLLECT2 38678 If defined, DWARF 2 frame unwind information will identified by 38679 specially named labels. The collect2 process will locate these 38680 labels and generate code to register the frames. 38681 38682 This might be necessary, for instance, if the system linker will 38683 not place the eh_frames in-between the sentinals from 'crtstuff.c', 38684 or if the system linker does garbage collection and sections cannot 38685 be marked as not to be collected. 38686 38687 -- Macro: EH_TABLES_CAN_BE_READ_ONLY 38688 Define this macro to 1 if your target is such that no frame unwind 38689 information encoding used with non-PIC code will ever require a 38690 runtime relocation, but the linker may not support merging 38691 read-only and read-write sections into a single read-write section. 38692 38693 -- Macro: MASK_RETURN_ADDR 38694 An rtx used to mask the return address found via 'RETURN_ADDR_RTX', 38695 so that it does not contain any extraneous set bits in it. 38696 38697 -- Macro: DWARF2_UNWIND_INFO 38698 Define this macro to 0 if your target supports DWARF 2 frame unwind 38699 information, but it does not yet work with exception handling. 38700 Otherwise, if your target supports this information (if it defines 38701 'INCOMING_RETURN_ADDR_RTX' and 'OBJECT_FORMAT_ELF'), GCC will 38702 provide a default definition of 1. 38703 38704 -- Common Target Hook: enum unwind_info_type TARGET_EXCEPT_UNWIND_INFO 38705 (struct gcc_options *OPTS) 38706 This hook defines the mechanism that will be used for exception 38707 handling by the target. If the target has ABI specified unwind 38708 tables, the hook should return 'UI_TARGET'. If the target is to 38709 use the 'setjmp'/'longjmp'-based exception handling scheme, the 38710 hook should return 'UI_SJLJ'. If the target supports DWARF 2 frame 38711 unwind information, the hook should return 'UI_DWARF2'. 38712 38713 A target may, if exceptions are disabled, choose to return 38714 'UI_NONE'. This may end up simplifying other parts of 38715 target-specific code. The default implementation of this hook 38716 never returns 'UI_NONE'. 38717 38718 Note that the value returned by this hook should be constant. It 38719 should not depend on anything except the command-line switches 38720 described by OPTS. In particular, the setting 'UI_SJLJ' must be 38721 fixed at compiler start-up as C pre-processor macros and builtin 38722 functions related to exception handling are set up depending on 38723 this setting. 38724 38725 The default implementation of the hook first honors the 38726 '--enable-sjlj-exceptions' configure option, then 38727 'DWARF2_UNWIND_INFO', and finally defaults to 'UI_SJLJ'. If 38728 'DWARF2_UNWIND_INFO' depends on command-line options, the target 38729 must define this hook so that OPTS is used correctly. 38730 38731 -- Common Target Hook: bool TARGET_UNWIND_TABLES_DEFAULT 38732 This variable should be set to 'true' if the target ABI requires 38733 unwinding tables even when exceptions are not used. It must not be 38734 modified by command-line option processing. 38735 38736 -- Macro: DONT_USE_BUILTIN_SETJMP 38737 Define this macro to 1 if the 'setjmp'/'longjmp'-based scheme 38738 should use the 'setjmp'/'longjmp' functions from the C library 38739 instead of the '__builtin_setjmp'/'__builtin_longjmp' machinery. 38740 38741 -- Macro: JMP_BUF_SIZE 38742 This macro has no effect unless 'DONT_USE_BUILTIN_SETJMP' is also 38743 defined. Define this macro if the default size of 'jmp_buf' buffer 38744 for the 'setjmp'/'longjmp'-based exception handling mechanism is 38745 not large enough, or if it is much too large. The default size is 38746 'FIRST_PSEUDO_REGISTER * sizeof(void *)'. 38747 38748 -- Macro: DWARF_CIE_DATA_ALIGNMENT 38749 This macro need only be defined if the target might save registers 38750 in the function prologue at an offset to the stack pointer that is 38751 not aligned to 'UNITS_PER_WORD'. The definition should be the 38752 negative minimum alignment if 'STACK_GROWS_DOWNWARD' is true, and 38753 the positive minimum alignment otherwise. *Note DWARF::. Only 38754 applicable if the target supports DWARF 2 frame unwind information. 38755 38756 -- Target Hook: bool TARGET_TERMINATE_DW2_EH_FRAME_INFO 38757 Contains the value true if the target should add a zero word onto 38758 the end of a Dwarf-2 frame info section when used for exception 38759 handling. Default value is false if 'EH_FRAME_SECTION_NAME' is 38760 defined, and true otherwise. 38761 38762 -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG) 38763 Given a register, this hook should return a parallel of registers 38764 to represent where to find the register pieces. Define this hook 38765 if the register and its mode are represented in Dwarf in 38766 non-contiguous locations, or if the register should be represented 38767 in more than one register in Dwarf. Otherwise, this hook should 38768 return 'NULL_RTX'. If not defined, the default is to return 38769 'NULL_RTX'. 38770 38771 -- Target Hook: machine_mode TARGET_DWARF_FRAME_REG_MODE (int REGNO) 38772 Given a register, this hook should return the mode which the 38773 corresponding Dwarf frame register should have. This is normally 38774 used to return a smaller mode than the raw mode to prevent call 38775 clobbered parts of a register altering the frame register size 38776 38777 -- Target Hook: void TARGET_INIT_DWARF_REG_SIZES_EXTRA (tree ADDRESS) 38778 If some registers are represented in Dwarf-2 unwind information in 38779 multiple pieces, define this hook to fill in information about the 38780 sizes of those pieces in the table used by the unwinder at runtime. 38781 It will be called by 'expand_builtin_init_dwarf_reg_sizes' after 38782 filling in a single size corresponding to each hard register; 38783 ADDRESS is the address of the table. 38784 38785 -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM) 38786 This hook is used to output a reference from a frame unwinding 38787 table to the type_info object identified by SYM. It should return 38788 'true' if the reference was output. Returning 'false' will cause 38789 the reference to be output using the normal Dwarf2 routines. 38790 38791 -- Target Hook: bool TARGET_ARM_EABI_UNWINDER 38792 This flag should be set to 'true' on targets that use an ARM EABI 38793 based unwinding library, and 'false' on other targets. This 38794 effects the format of unwinding tables, and how the unwinder in 38795 entered after running a cleanup. The default is 'false'. 38796 38797 38798File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format 38799 3880018.20.10 Assembler Commands for Alignment 38801----------------------------------------- 38802 38803This describes commands for alignment. 38804 38805 -- Macro: JUMP_ALIGN (LABEL) 38806 The alignment (log base 2) to put in front of LABEL, which is a 38807 common destination of jumps and has no fallthru incoming edge. 38808 38809 This macro need not be defined if you don't want any special 38810 alignment to be done at such a time. Most machine descriptions do 38811 not currently define the macro. 38812 38813 Unless it's necessary to inspect the LABEL parameter, it is better 38814 to set the variable ALIGN_JUMPS in the target's 38815 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 38816 user's selection in ALIGN_JUMPS in a 'JUMP_ALIGN' implementation. 38817 38818 -- Target Hook: int TARGET_ASM_JUMP_ALIGN_MAX_SKIP (rtx_insn *LABEL) 38819 The maximum number of bytes to skip before LABEL when applying 38820 'JUMP_ALIGN'. This works only if 'ASM_OUTPUT_MAX_SKIP_ALIGN' is 38821 defined. 38822 38823 -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL) 38824 The alignment (log base 2) to put in front of LABEL, which follows 38825 a 'BARRIER'. 38826 38827 This macro need not be defined if you don't want any special 38828 alignment to be done at such a time. Most machine descriptions do 38829 not currently define the macro. 38830 38831 -- Target Hook: int TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP 38832 (rtx_insn *LABEL) 38833 The maximum number of bytes to skip before LABEL when applying 38834 'LABEL_ALIGN_AFTER_BARRIER'. This works only if 38835 'ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 38836 38837 -- Macro: LOOP_ALIGN (LABEL) 38838 The alignment (log base 2) to put in front of LABEL that heads a 38839 frequently executed basic block (usually the header of a loop). 38840 38841 This macro need not be defined if you don't want any special 38842 alignment to be done at such a time. Most machine descriptions do 38843 not currently define the macro. 38844 38845 Unless it's necessary to inspect the LABEL parameter, it is better 38846 to set the variable 'align_loops' in the target's 38847 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 38848 user's selection in 'align_loops' in a 'LOOP_ALIGN' implementation. 38849 38850 -- Target Hook: int TARGET_ASM_LOOP_ALIGN_MAX_SKIP (rtx_insn *LABEL) 38851 The maximum number of bytes to skip when applying 'LOOP_ALIGN' to 38852 LABEL. This works only if 'ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 38853 38854 -- Macro: LABEL_ALIGN (LABEL) 38855 The alignment (log base 2) to put in front of LABEL. If 38856 'LABEL_ALIGN_AFTER_BARRIER' / 'LOOP_ALIGN' specify a different 38857 alignment, the maximum of the specified values is used. 38858 38859 Unless it's necessary to inspect the LABEL parameter, it is better 38860 to set the variable 'align_labels' in the target's 38861 'TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 38862 user's selection in 'align_labels' in a 'LABEL_ALIGN' 38863 implementation. 38864 38865 -- Target Hook: int TARGET_ASM_LABEL_ALIGN_MAX_SKIP (rtx_insn *LABEL) 38866 The maximum number of bytes to skip when applying 'LABEL_ALIGN' to 38867 LABEL. This works only if 'ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 38868 38869 -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES) 38870 A C statement to output to the stdio stream STREAM an assembler 38871 instruction to advance the location counter by NBYTES bytes. Those 38872 bytes should be zero when loaded. NBYTES will be a C expression of 38873 type 'unsigned HOST_WIDE_INT'. 38874 38875 -- Macro: ASM_NO_SKIP_IN_TEXT 38876 Define this macro if 'ASM_OUTPUT_SKIP' should not be used in the 38877 text section because it fails to put zeros in the bytes that are 38878 skipped. This is true on many Unix systems, where the pseudo-op to 38879 skip bytes produces no-op instructions rather than zeros when used 38880 in the text section. 38881 38882 -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER) 38883 A C statement to output to the stdio stream STREAM an assembler 38884 command to advance the location counter to a multiple of 2 to the 38885 POWER bytes. POWER will be a C expression of type 'int'. 38886 38887 -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER) 38888 Like 'ASM_OUTPUT_ALIGN', except that the "nop" instruction is used 38889 for padding, if necessary. 38890 38891 -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP) 38892 A C statement to output to the stdio stream STREAM an assembler 38893 command to advance the location counter to a multiple of 2 to the 38894 POWER bytes, but only if MAX_SKIP or fewer bytes are needed to 38895 satisfy the alignment request. POWER and MAX_SKIP will be a C 38896 expression of type 'int'. 38897 38898 38899File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros 38900 3890118.21 Controlling Debugging Information Format 38902============================================== 38903 38904This describes how to specify debugging information. 38905 38906* Menu: 38907 38908* All Debuggers:: Macros that affect all debugging formats uniformly. 38909* DBX Options:: Macros enabling specific options in DBX format. 38910* DBX Hooks:: Hook macros for varying DBX format. 38911* File Names and DBX:: Macros controlling output of file names in DBX format. 38912* DWARF:: Macros for DWARF format. 38913* VMS Debug:: Macros for VMS debug format. 38914 38915 38916File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info 38917 3891818.21.1 Macros Affecting All Debugging Formats 38919---------------------------------------------- 38920 38921These macros affect all debugging formats. 38922 38923 -- Macro: DBX_REGISTER_NUMBER (REGNO) 38924 A C expression that returns the DBX register number for the 38925 compiler register number REGNO. In the default macro provided, the 38926 value of this expression will be REGNO itself. But sometimes there 38927 are some registers that the compiler knows about and DBX does not, 38928 or vice versa. In such cases, some register may need to have one 38929 number in the compiler and another for DBX. 38930 38931 If two registers have consecutive numbers inside GCC, and they can 38932 be used as a pair to hold a multiword value, then they _must_ have 38933 consecutive numbers after renumbering with 'DBX_REGISTER_NUMBER'. 38934 Otherwise, debuggers will be unable to access such a pair, because 38935 they expect register pairs to be consecutive in their own numbering 38936 scheme. 38937 38938 If you find yourself defining 'DBX_REGISTER_NUMBER' in way that 38939 does not preserve register pairs, then what you must do instead is 38940 redefine the actual register numbering scheme. 38941 38942 -- Macro: DEBUGGER_AUTO_OFFSET (X) 38943 A C expression that returns the integer offset value for an 38944 automatic variable having address X (an RTL expression). The 38945 default computation assumes that X is based on the frame-pointer 38946 and gives the offset from the frame-pointer. This is required for 38947 targets that produce debugging output for DBX and allow the 38948 frame-pointer to be eliminated when the '-g' option is used. 38949 38950 -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X) 38951 A C expression that returns the integer offset value for an 38952 argument having address X (an RTL expression). The nominal offset 38953 is OFFSET. 38954 38955 -- Macro: PREFERRED_DEBUGGING_TYPE 38956 A C expression that returns the type of debugging output GCC should 38957 produce when the user specifies just '-g'. Define this if you have 38958 arranged for GCC to support more than one format of debugging 38959 output. Currently, the allowable values are 'DBX_DEBUG', 38960 'DWARF2_DEBUG', 'XCOFF_DEBUG', 'VMS_DEBUG', and 38961 'VMS_AND_DWARF2_DEBUG'. 38962 38963 When the user specifies '-ggdb', GCC normally also uses the value 38964 of this macro to select the debugging output format, but with two 38965 exceptions. If 'DWARF2_DEBUGGING_INFO' is defined, GCC uses the 38966 value 'DWARF2_DEBUG'. Otherwise, if 'DBX_DEBUGGING_INFO' is 38967 defined, GCC uses 'DBX_DEBUG'. 38968 38969 The value of this macro only affects the default debugging output; 38970 the user can always get a specific type of output by using 38971 '-gstabs', '-gdwarf-2', '-gxcoff', or '-gvms'. 38972 38973 38974File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info 38975 3897618.21.2 Specific Options for DBX Output 38977--------------------------------------- 38978 38979These are specific options for DBX output. 38980 38981 -- Macro: DBX_DEBUGGING_INFO 38982 Define this macro if GCC should produce debugging output for DBX in 38983 response to the '-g' option. 38984 38985 -- Macro: XCOFF_DEBUGGING_INFO 38986 Define this macro if GCC should produce XCOFF format debugging 38987 output in response to the '-g' option. This is a variant of DBX 38988 format. 38989 38990 -- Macro: DEFAULT_GDB_EXTENSIONS 38991 Define this macro to control whether GCC should by default generate 38992 GDB's extended version of DBX debugging information (assuming 38993 DBX-format debugging information is enabled at all). If you don't 38994 define the macro, the default is 1: always generate the extended 38995 information if there is any occasion to. 38996 38997 -- Macro: DEBUG_SYMS_TEXT 38998 Define this macro if all '.stabs' commands should be output while 38999 in the text section. 39000 39001 -- Macro: ASM_STABS_OP 39002 A C string constant, including spacing, naming the assembler pseudo 39003 op to use instead of '"\t.stabs\t"' to define an ordinary debugging 39004 symbol. If you don't define this macro, '"\t.stabs\t"' is used. 39005 This macro applies only to DBX debugging information format. 39006 39007 -- Macro: ASM_STABD_OP 39008 A C string constant, including spacing, naming the assembler pseudo 39009 op to use instead of '"\t.stabd\t"' to define a debugging symbol 39010 whose value is the current location. If you don't define this 39011 macro, '"\t.stabd\t"' is used. This macro applies only to DBX 39012 debugging information format. 39013 39014 -- Macro: ASM_STABN_OP 39015 A C string constant, including spacing, naming the assembler pseudo 39016 op to use instead of '"\t.stabn\t"' to define a debugging symbol 39017 with no name. If you don't define this macro, '"\t.stabn\t"' is 39018 used. This macro applies only to DBX debugging information format. 39019 39020 -- Macro: DBX_NO_XREFS 39021 Define this macro if DBX on your system does not support the 39022 construct 'xsTAGNAME'. On some systems, this construct is used to 39023 describe a forward reference to a structure named TAGNAME. On 39024 other systems, this construct is not supported at all. 39025 39026 -- Macro: DBX_CONTIN_LENGTH 39027 A symbol name in DBX-format debugging information is normally 39028 continued (split into two separate '.stabs' directives) when it 39029 exceeds a certain length (by default, 80 characters). On some 39030 operating systems, DBX requires this splitting; on others, 39031 splitting must not be done. You can inhibit splitting by defining 39032 this macro with the value zero. You can override the default 39033 splitting-length by defining this macro as an expression for the 39034 length you desire. 39035 39036 -- Macro: DBX_CONTIN_CHAR 39037 Normally continuation is indicated by adding a '\' character to the 39038 end of a '.stabs' string when a continuation follows. To use a 39039 different character instead, define this macro as a character 39040 constant for the character you want to use. Do not define this 39041 macro if backslash is correct for your system. 39042 39043 -- Macro: DBX_STATIC_STAB_DATA_SECTION 39044 Define this macro if it is necessary to go to the data section 39045 before outputting the '.stabs' pseudo-op for a non-global static 39046 variable. 39047 39048 -- Macro: DBX_TYPE_DECL_STABS_CODE 39049 The value to use in the "code" field of the '.stabs' directive for 39050 a typedef. The default is 'N_LSYM'. 39051 39052 -- Macro: DBX_STATIC_CONST_VAR_CODE 39053 The value to use in the "code" field of the '.stabs' directive for 39054 a static variable located in the text section. DBX format does not 39055 provide any "right" way to do this. The default is 'N_FUN'. 39056 39057 -- Macro: DBX_REGPARM_STABS_CODE 39058 The value to use in the "code" field of the '.stabs' directive for 39059 a parameter passed in registers. DBX format does not provide any 39060 "right" way to do this. The default is 'N_RSYM'. 39061 39062 -- Macro: DBX_REGPARM_STABS_LETTER 39063 The letter to use in DBX symbol data to identify a symbol as a 39064 parameter passed in registers. DBX format does not customarily 39065 provide any way to do this. The default is ''P''. 39066 39067 -- Macro: DBX_FUNCTION_FIRST 39068 Define this macro if the DBX information for a function and its 39069 arguments should precede the assembler code for the function. 39070 Normally, in DBX format, the debugging information entirely follows 39071 the assembler code. 39072 39073 -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE 39074 Define this macro, with value 1, if the value of a symbol 39075 describing the scope of a block ('N_LBRAC' or 'N_RBRAC') should be 39076 relative to the start of the enclosing function. Normally, GCC 39077 uses an absolute address. 39078 39079 -- Macro: DBX_LINES_FUNCTION_RELATIVE 39080 Define this macro, with value 1, if the value of a symbol 39081 indicating the current line number ('N_SLINE') should be relative 39082 to the start of the enclosing function. Normally, GCC uses an 39083 absolute address. 39084 39085 -- Macro: DBX_USE_BINCL 39086 Define this macro if GCC should generate 'N_BINCL' and 'N_EINCL' 39087 stabs for included header files, as on Sun systems. This macro 39088 also directs GCC to output a type number as a pair of a file number 39089 and a type number within the file. Normally, GCC does not generate 39090 'N_BINCL' or 'N_EINCL' stabs, and it outputs a single number for a 39091 type number. 39092 39093 39094File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info 39095 3909618.21.3 Open-Ended Hooks for DBX Format 39097--------------------------------------- 39098 39099These are hooks for DBX format. 39100 39101 -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER) 39102 A C statement to output DBX debugging information before code for 39103 line number LINE of the current source file to the stdio stream 39104 STREAM. COUNTER is the number of time the macro was invoked, 39105 including the current invocation; it is intended to generate unique 39106 labels in the assembly output. 39107 39108 This macro should not be defined if the default output is correct, 39109 or if it can be made correct by defining 39110 'DBX_LINES_FUNCTION_RELATIVE'. 39111 39112 -- Macro: NO_DBX_FUNCTION_END 39113 Some stabs encapsulation formats (in particular ECOFF), cannot 39114 handle the '.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx 39115 extension construct. On those machines, define this macro to turn 39116 this feature off without disturbing the rest of the gdb extensions. 39117 39118 -- Macro: NO_DBX_BNSYM_ENSYM 39119 Some assemblers cannot handle the '.stabd BNSYM/ENSYM,0,0' gdb dbx 39120 extension construct. On those machines, define this macro to turn 39121 this feature off without disturbing the rest of the gdb extensions. 39122 39123 39124File: gccint.info, Node: File Names and DBX, Next: DWARF, Prev: DBX Hooks, Up: Debugging Info 39125 3912618.21.4 File Names in DBX Format 39127-------------------------------- 39128 39129This describes file names in DBX format. 39130 39131 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME) 39132 A C statement to output DBX debugging information to the stdio 39133 stream STREAM, which indicates that file NAME is the main source 39134 file--the file specified as the input file for compilation. This 39135 macro is called only once, at the beginning of compilation. 39136 39137 This macro need not be defined if the standard form of output for 39138 DBX debugging information is appropriate. 39139 39140 It may be necessary to refer to a label equal to the beginning of 39141 the text section. You can use 'assemble_name (stream, 39142 ltext_label_name)' to do so. If you do this, you must also set the 39143 variable USED_LTEXT_LABEL_NAME to 'true'. 39144 39145 -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY 39146 Define this macro, with value 1, if GCC should not emit an 39147 indication of the current directory for compilation and current 39148 source language at the beginning of the file. 39149 39150 -- Macro: NO_DBX_GCC_MARKER 39151 Define this macro, with value 1, if GCC should not emit an 39152 indication that this object file was compiled by GCC. The default 39153 is to emit an 'N_OPT' stab at the beginning of every source file, 39154 with 'gcc2_compiled.' for the string and value 0. 39155 39156 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME) 39157 A C statement to output DBX debugging information at the end of 39158 compilation of the main source file NAME. Output should be written 39159 to the stdio stream STREAM. 39160 39161 If you don't define this macro, nothing special is output at the 39162 end of compilation, which is correct for most machines. 39163 39164 -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END 39165 Define this macro _instead of_ defining 39166 'DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at 39167 the end of compilation is an 'N_SO' stab with an empty string, 39168 whose value is the highest absolute text address in the file. 39169 39170 39171File: gccint.info, Node: DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info 39172 3917318.21.5 Macros for DWARF Output 39174------------------------------- 39175 39176Here are macros for DWARF output. 39177 39178 -- Macro: DWARF2_DEBUGGING_INFO 39179 Define this macro if GCC should produce dwarf version 2 format 39180 debugging output in response to the '-g' option. 39181 39182 -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (const_tree 39183 FUNCTION) 39184 Define this to enable the dwarf attribute 39185 'DW_AT_calling_convention' to be emitted for each function. 39186 Instead of an integer return the enum value for the 'DW_CC_' 39187 tag. 39188 39189 To support optional call frame debugging information, you must also 39190 define 'INCOMING_RETURN_ADDR_RTX' and either set 39191 'RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the 39192 prologue, or call 'dwarf2out_def_cfa' and 'dwarf2out_reg_save' as 39193 appropriate from 'TARGET_ASM_FUNCTION_PROLOGUE' if you don't. 39194 39195 -- Macro: DWARF2_FRAME_INFO 39196 Define this macro to a nonzero value if GCC should always output 39197 Dwarf 2 frame information. If 'TARGET_EXCEPT_UNWIND_INFO' (*note 39198 Exception Region Output::) returns 'UI_DWARF2', and exceptions are 39199 enabled, GCC will output this information not matter how you define 39200 'DWARF2_FRAME_INFO'. 39201 39202 -- Target Hook: enum unwind_info_type TARGET_DEBUG_UNWIND_INFO (void) 39203 This hook defines the mechanism that will be used for describing 39204 frame unwind information to the debugger. Normally the hook will 39205 return 'UI_DWARF2' if DWARF 2 debug information is enabled, and 39206 return 'UI_NONE' otherwise. 39207 39208 A target may return 'UI_DWARF2' even when DWARF 2 debug information 39209 is disabled in order to always output DWARF 2 frame information. 39210 39211 A target may return 'UI_TARGET' if it has ABI specified unwind 39212 tables. This will suppress generation of the normal debug frame 39213 unwind information. 39214 39215 -- Macro: DWARF2_ASM_LINE_DEBUG_INFO 39216 Define this macro to be a nonzero value if the assembler can 39217 generate Dwarf 2 line debug info sections. This will result in 39218 much more compact line number tables, and hence is desirable if it 39219 works. 39220 39221 -- Macro: DWARF2_ASM_VIEW_DEBUG_INFO 39222 Define this macro to be a nonzero value if the assembler supports 39223 view assignment and verification in '.loc'. If it does not, but 39224 the user enables location views, the compiler may have to fallback 39225 to internal line number tables. 39226 39227 -- Target Hook: int TARGET_RESET_LOCATION_VIEW (rtx_insn *) 39228 This hook, if defined, enables -ginternal-reset-location-views, and 39229 uses its result to override cases in which the estimated min insn 39230 length might be nonzero even when a PC advance (i.e., a view reset) 39231 cannot be taken for granted. 39232 39233 If the hook is defined, it must return a positive value to indicate 39234 the insn definitely advances the PC, and so the view number can be 39235 safely assumed to be reset; a negative value to mean the insn 39236 definitely does not advance the PC, and os the view number must not 39237 be reset; or zero to decide based on the estimated insn length. 39238 39239 If insn length is to be regarded as reliable, set the hook to 39240 'hook_int_rtx_insn_0'. 39241 39242 -- Target Hook: bool TARGET_WANT_DEBUG_PUB_SECTIONS 39243 True if the '.debug_pubtypes' and '.debug_pubnames' sections should 39244 be emitted. These sections are not used on most platforms, and in 39245 particular GDB does not use them. 39246 39247 -- Target Hook: bool TARGET_DELAY_SCHED2 39248 True if sched2 is not to be run at its normal place. This usually 39249 means it will be run as part of machine-specific reorg. 39250 39251 -- Target Hook: bool TARGET_DELAY_VARTRACK 39252 True if vartrack is not to be run at its normal place. This 39253 usually means it will be run as part of machine-specific reorg. 39254 39255 -- Target Hook: bool TARGET_NO_REGISTER_ALLOCATION 39256 True if register allocation and the passes following it should not 39257 be run. Usually true only for virtual assembler targets. 39258 39259 -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2) 39260 A C statement to issue assembly directives that create a difference 39261 LAB1 minus LAB2, using an integer of the given SIZE. 39262 39263 -- Macro: ASM_OUTPUT_DWARF_VMS_DELTA (STREAM, SIZE, LABEL1, LABEL2) 39264 A C statement to issue assembly directives that create a difference 39265 between the two given labels in system defined units, e.g. 39266 instruction slots on IA64 VMS, using an integer of the given size. 39267 39268 -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL, OFFSET, 39269 SECTION) 39270 A C statement to issue assembly directives that create a 39271 section-relative reference to the given LABEL plus OFFSET, using an 39272 integer of the given SIZE. The label is known to be defined in the 39273 given SECTION. 39274 39275 -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL) 39276 A C statement to issue assembly directives that create a 39277 self-relative reference to the given LABEL, using an integer of the 39278 given SIZE. 39279 39280 -- Macro: ASM_OUTPUT_DWARF_DATAREL (STREAM, SIZE, LABEL) 39281 A C statement to issue assembly directives that create a reference 39282 to the given LABEL relative to the dbase, using an integer of the 39283 given SIZE. 39284 39285 -- Macro: ASM_OUTPUT_DWARF_TABLE_REF (LABEL) 39286 A C statement to issue assembly directives that create a reference 39287 to the DWARF table identifier LABEL from the current section. This 39288 is used on some systems to avoid garbage collecting a DWARF table 39289 which is referenced by a function. 39290 39291 -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int 39292 SIZE, rtx X) 39293 If defined, this target hook is a function which outputs a 39294 DTP-relative reference to the given TLS symbol of the specified 39295 size. 39296 39297 39298File: gccint.info, Node: VMS Debug, Prev: DWARF, Up: Debugging Info 39299 3930018.21.6 Macros for VMS Debug Format 39301----------------------------------- 39302 39303Here are macros for VMS debug format. 39304 39305 -- Macro: VMS_DEBUGGING_INFO 39306 Define this macro if GCC should produce debugging output for VMS in 39307 response to the '-g' option. The default behavior for VMS is to 39308 generate minimal debug info for a traceback in the absence of '-g' 39309 unless explicitly overridden with '-g0'. This behavior is 39310 controlled by 'TARGET_OPTION_OPTIMIZATION' and 39311 'TARGET_OPTION_OVERRIDE'. 39312 39313 39314File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros 39315 3931618.22 Cross Compilation and Floating Point 39317========================================== 39318 39319While all modern machines use twos-complement representation for 39320integers, there are a variety of representations for floating point 39321numbers. This means that in a cross-compiler the representation of 39322floating point numbers in the compiled program may be different from 39323that used in the machine doing the compilation. 39324 39325 Because different representation systems may offer different amounts of 39326range and precision, all floating point constants must be represented in 39327the target machine's format. Therefore, the cross compiler cannot 39328safely use the host machine's floating point arithmetic; it must emulate 39329the target's arithmetic. To ensure consistency, GCC always uses 39330emulation to work with floating point values, even when the host and 39331target floating point formats are identical. 39332 39333 The following macros are provided by 'real.h' for the compiler to use. 39334All parts of the compiler which generate or optimize floating-point 39335calculations must use these macros. They may evaluate their operands 39336more than once, so operands must not have side effects. 39337 39338 -- Macro: REAL_VALUE_TYPE 39339 The C data type to be used to hold a floating point value in the 39340 target machine's format. Typically this is a 'struct' containing 39341 an array of 'HOST_WIDE_INT', but all code should treat it as an 39342 opaque quantity. 39343 39344 -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X) 39345 Truncates X to a signed integer, rounding toward zero. 39346 39347 -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX 39348 (REAL_VALUE_TYPE X) 39349 Truncates X to an unsigned integer, rounding toward zero. If X is 39350 negative, returns zero. 39351 39352 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, 39353 machine_mode MODE) 39354 Converts STRING into a floating point number in the target 39355 machine's representation for mode MODE. This routine can handle 39356 both decimal and hexadecimal floating point constants, using the 39357 syntax defined by the C language for both. 39358 39359 -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X) 39360 Returns 1 if X is negative (including negative zero), 0 otherwise. 39361 39362 -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X) 39363 Determines whether X represents infinity (positive or negative). 39364 39365 -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X) 39366 Determines whether X represents a "NaN" (not-a-number). 39367 39368 -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X) 39369 Returns the negative of the floating point value X. 39370 39371 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X) 39372 Returns the absolute value of X. 39373 39374 39375File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros 39376 3937718.23 Mode Switching Instructions 39378================================= 39379 39380The following macros control mode switching optimizations: 39381 39382 -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY) 39383 Define this macro if the port needs extra instructions inserted for 39384 mode switching in an optimizing compilation. 39385 39386 For an example, the SH4 can perform both single and double 39387 precision floating point operations, but to perform a single 39388 precision operation, the FPSCR PR bit has to be cleared, while for 39389 a double precision operation, this bit has to be set. Changing the 39390 PR bit requires a general purpose register as a scratch register, 39391 hence these FPSCR sets have to be inserted before reload, i.e. you 39392 cannot put this into instruction emitting or 39393 'TARGET_MACHINE_DEPENDENT_REORG'. 39394 39395 You can have multiple entities that are mode-switched, and select 39396 at run time which entities actually need it. 39397 'OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY that 39398 needs mode-switching. If you define this macro, you also have to 39399 define 'NUM_MODES_FOR_MODE_SWITCHING', 'TARGET_MODE_NEEDED', 39400 'TARGET_MODE_PRIORITY' and 'TARGET_MODE_EMIT'. 39401 'TARGET_MODE_AFTER', 'TARGET_MODE_ENTRY', and 'TARGET_MODE_EXIT' 39402 are optional. 39403 39404 -- Macro: NUM_MODES_FOR_MODE_SWITCHING 39405 If you define 'OPTIMIZE_MODE_SWITCHING', you have to define this as 39406 initializer for an array of integers. Each initializer element N 39407 refers to an entity that needs mode switching, and specifies the 39408 number of different modes that might need to be set for this 39409 entity. The position of the initializer in the 39410 initializer--starting counting at zero--determines the integer that 39411 is used to refer to the mode-switched entity in question. In 39412 macros that take mode arguments / yield a mode result, modes are 39413 represented as numbers 0 ... N - 1. N is used to specify that no 39414 mode switch is needed / supplied. 39415 39416 -- Target Hook: void TARGET_MODE_EMIT (int ENTITY, int MODE, int 39417 PREV_MODE, HARD_REG_SET REGS_LIVE) 39418 Generate one or more insns to set ENTITY to MODE. HARD_REG_LIVE is 39419 the set of hard registers live at the point where the insn(s) are 39420 to be inserted. PREV_MOXDE indicates the mode to switch from. 39421 Sets of a lower numbered entity will be emitted before sets of a 39422 higher numbered entity to a mode of the same or lower priority. 39423 39424 -- Target Hook: int TARGET_MODE_NEEDED (int ENTITY, rtx_insn *INSN) 39425 ENTITY is an integer specifying a mode-switched entity. If 39426 'OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to 39427 return an integer value not larger than the corresponding element 39428 in 'NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY 39429 must be switched into prior to the execution of INSN. 39430 39431 -- Target Hook: int TARGET_MODE_AFTER (int ENTITY, int MODE, rtx_insn 39432 *INSN) 39433 ENTITY is an integer specifying a mode-switched entity. If this 39434 macro is defined, it is evaluated for every INSN during mode 39435 switching. It determines the mode that an insn results in (if 39436 different from the incoming mode). 39437 39438 -- Target Hook: int TARGET_MODE_ENTRY (int ENTITY) 39439 If this macro is defined, it is evaluated for every ENTITY that 39440 needs mode switching. It should evaluate to an integer, which is a 39441 mode that ENTITY is assumed to be switched to at function entry. 39442 If 'TARGET_MODE_ENTRY' is defined then 'TARGET_MODE_EXIT' must be 39443 defined. 39444 39445 -- Target Hook: int TARGET_MODE_EXIT (int ENTITY) 39446 If this macro is defined, it is evaluated for every ENTITY that 39447 needs mode switching. It should evaluate to an integer, which is a 39448 mode that ENTITY is assumed to be switched to at function exit. If 39449 'TARGET_MODE_EXIT' is defined then 'TARGET_MODE_ENTRY' must be 39450 defined. 39451 39452 -- Target Hook: int TARGET_MODE_PRIORITY (int ENTITY, int N) 39453 This macro specifies the order in which modes for ENTITY are 39454 processed. 0 is the highest priority, 39455 'NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest. The value 39456 of the macro should be an integer designating a mode for ENTITY. 39457 For any fixed ENTITY, 'mode_priority' (ENTITY, N) shall be a 39458 bijection in 0 ... 'num_modes_for_mode_switching[ENTITY] - 1'. 39459 39460 39461File: gccint.info, Node: Target Attributes, Next: Emulated TLS, Prev: Mode Switching, Up: Target Macros 39462 3946318.24 Defining target-specific uses of '__attribute__' 39464====================================================== 39465 39466Target-specific attributes may be defined for functions, data and types. 39467These are described using the following target hooks; they also need to 39468be documented in 'extend.texi'. 39469 39470 -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE 39471 If defined, this target hook points to an array of 'struct 39472 attribute_spec' (defined in 'tree-core.h') specifying the machine 39473 specific attributes for this target and some of the restrictions on 39474 the entities to which these attributes are applied and the 39475 arguments they take. 39476 39477 -- Target Hook: bool TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P (const_tree 39478 NAME) 39479 If defined, this target hook is a function which returns true if 39480 the machine-specific attribute named NAME expects an identifier 39481 given as its first argument to be passed on as a plain identifier, 39482 not subjected to name lookup. If this is not defined, the default 39483 is false for all machine-specific attributes. 39484 39485 -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (const_tree TYPE1, 39486 const_tree TYPE2) 39487 If defined, this target hook is a function which returns zero if 39488 the attributes on TYPE1 and TYPE2 are incompatible, one if they are 39489 compatible, and two if they are nearly compatible (which causes a 39490 warning to be generated). If this is not defined, machine-specific 39491 attributes are supposed always to be compatible. 39492 39493 -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE) 39494 If defined, this target hook is a function which assigns default 39495 attributes to the newly defined TYPE. 39496 39497 -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree 39498 TYPE2) 39499 Define this target hook if the merging of type attributes needs 39500 special handling. If defined, the result is a list of the combined 39501 'TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that 39502 'comptypes' has already been called and returned 1. This function 39503 may call 'merge_attributes' to handle machine-independent merging. 39504 39505 -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree 39506 NEWDECL) 39507 Define this target hook if the merging of decl attributes needs 39508 special handling. If defined, the result is a list of the combined 39509 'DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate 39510 declaration of OLDDECL. Examples of when this is needed are when 39511 one attribute overrides another, or when an attribute is nullified 39512 by a subsequent definition. This function may call 39513 'merge_attributes' to handle machine-independent merging. 39514 39515 If the only target-specific handling you require is 'dllimport' for 39516 Microsoft Windows targets, you should define the macro 39517 'TARGET_DLLIMPORT_DECL_ATTRIBUTES' to '1'. The compiler will then 39518 define a function called 'merge_dllimport_decl_attributes' which 39519 can then be defined as the expansion of 39520 'TARGET_MERGE_DECL_ATTRIBUTES'. You can also add 39521 'handle_dll_attribute' in the attribute table for your port to 39522 perform initial processing of the 'dllimport' and 'dllexport' 39523 attributes. This is done in 'i386/cygwin.h' and 'i386/i386.c', for 39524 example. 39525 39526 -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (const_tree 39527 DECL) 39528 DECL is a variable or function with '__attribute__((dllimport))' 39529 specified. Use this hook if the target needs to add extra 39530 validation checks to 'handle_dll_attribute'. 39531 39532 -- Macro: TARGET_DECLSPEC 39533 Define this macro to a nonzero value if you want to treat 39534 '__declspec(X)' as equivalent to '__attribute((X))'. By default, 39535 this behavior is enabled only for targets that define 39536 'TARGET_DLLIMPORT_DECL_ATTRIBUTES'. The current implementation of 39537 '__declspec' is via a built-in macro, but you should not rely on 39538 this implementation detail. 39539 39540 -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree 39541 *ATTR_PTR) 39542 Define this target hook if you want to be able to add attributes to 39543 a decl when it is being created. This is normally useful for back 39544 ends which wish to implement a pragma by using the attributes which 39545 correspond to the pragma's effect. The NODE argument is the decl 39546 which is being created. The ATTR_PTR argument is a pointer to the 39547 attribute list for this decl. The list itself should not be 39548 modified, since it may be shared with other decls, but attributes 39549 may be chained on the head of the list and '*ATTR_PTR' modified to 39550 point to the new attributes, or a copy of the list may be made if 39551 further changes are needed. 39552 39553 -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (const_tree 39554 FNDECL) 39555 This target hook returns 'true' if it is OK to inline FNDECL into 39556 the current function, despite its having target-specific 39557 attributes, 'false' otherwise. By default, if a function has a 39558 target specific attribute attached to it, it will not be inlined. 39559 39560 -- Target Hook: bool TARGET_OPTION_VALID_ATTRIBUTE_P (tree FNDECL, tree 39561 NAME, tree ARGS, int FLAGS) 39562 This hook is called to parse 'attribute(target("..."))', which 39563 allows setting target-specific options on individual functions. 39564 These function-specific options may differ from the options 39565 specified on the command line. The hook should return 'true' if 39566 the options are valid. 39567 39568 The hook should set the 'DECL_FUNCTION_SPECIFIC_TARGET' field in 39569 the function declaration to hold a pointer to a target-specific 39570 'struct cl_target_option' structure. 39571 39572 -- Target Hook: void TARGET_OPTION_SAVE (struct cl_target_option *PTR, 39573 struct gcc_options *OPTS) 39574 This hook is called to save any additional target-specific 39575 information in the 'struct cl_target_option' structure for 39576 function-specific options from the 'struct gcc_options' structure. 39577 *Note Option file format::. 39578 39579 -- Target Hook: void TARGET_OPTION_RESTORE (struct gcc_options *OPTS, 39580 struct cl_target_option *PTR) 39581 This hook is called to restore any additional target-specific 39582 information in the 'struct cl_target_option' structure for 39583 function-specific options to the 'struct gcc_options' structure. 39584 39585 -- Target Hook: void TARGET_OPTION_POST_STREAM_IN (struct 39586 cl_target_option *PTR) 39587 This hook is called to update target-specific information in the 39588 'struct cl_target_option' structure after it is streamed in from 39589 LTO bytecode. 39590 39591 -- Target Hook: void TARGET_OPTION_PRINT (FILE *FILE, int INDENT, 39592 struct cl_target_option *PTR) 39593 This hook is called to print any additional target-specific 39594 information in the 'struct cl_target_option' structure for 39595 function-specific options. 39596 39597 -- Target Hook: bool TARGET_OPTION_PRAGMA_PARSE (tree ARGS, tree 39598 POP_TARGET) 39599 This target hook parses the options for '#pragma GCC target', which 39600 sets the target-specific options for functions that occur later in 39601 the input stream. The options accepted should be the same as those 39602 handled by the 'TARGET_OPTION_VALID_ATTRIBUTE_P' hook. 39603 39604 -- Target Hook: void TARGET_OPTION_OVERRIDE (void) 39605 Sometimes certain combinations of command options do not make sense 39606 on a particular target machine. You can override the hook 39607 'TARGET_OPTION_OVERRIDE' to take account of this. This hooks is 39608 called once just after all the command options have been parsed. 39609 39610 Don't use this hook to turn on various extra optimizations for 39611 '-O'. That is what 'TARGET_OPTION_OPTIMIZATION' is for. 39612 39613 If you need to do something whenever the optimization level is 39614 changed via the optimize attribute or pragma, see 39615 'TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE' 39616 39617 -- Target Hook: bool TARGET_OPTION_FUNCTION_VERSIONS (tree DECL1, tree 39618 DECL2) 39619 This target hook returns 'true' if DECL1 and DECL2 are versions of 39620 the same function. DECL1 and DECL2 are function versions if and 39621 only if they have the same function signature and different target 39622 specific attributes, that is, they are compiled for different 39623 target machines. 39624 39625 -- Target Hook: bool TARGET_CAN_INLINE_P (tree CALLER, tree CALLEE) 39626 This target hook returns 'false' if the CALLER function cannot 39627 inline CALLEE, based on target specific information. By default, 39628 inlining is not allowed if the callee function has function 39629 specific target options and the caller does not use the same 39630 options. 39631 39632 -- Target Hook: void TARGET_RELAYOUT_FUNCTION (tree FNDECL) 39633 This target hook fixes function FNDECL after attributes are 39634 processed. Default does nothing. On ARM, the default function's 39635 alignment is updated with the attribute target. 39636 39637 39638File: gccint.info, Node: Emulated TLS, Next: MIPS Coprocessors, Prev: Target Attributes, Up: Target Macros 39639 3964018.25 Emulating TLS 39641=================== 39642 39643For targets whose psABI does not provide Thread Local Storage via 39644specific relocations and instruction sequences, an emulation layer is 39645used. A set of target hooks allows this emulation layer to be 39646configured for the requirements of a particular target. For instance 39647the psABI may in fact specify TLS support in terms of an emulation 39648layer. 39649 39650 The emulation layer works by creating a control object for every TLS 39651object. To access the TLS object, a lookup function is provided which, 39652when given the address of the control object, will return the address of 39653the current thread's instance of the TLS object. 39654 39655 -- Target Hook: const char * TARGET_EMUTLS_GET_ADDRESS 39656 Contains the name of the helper function that uses a TLS control 39657 object to locate a TLS instance. The default causes libgcc's 39658 emulated TLS helper function to be used. 39659 39660 -- Target Hook: const char * TARGET_EMUTLS_REGISTER_COMMON 39661 Contains the name of the helper function that should be used at 39662 program startup to register TLS objects that are implicitly 39663 initialized to zero. If this is 'NULL', all TLS objects will have 39664 explicit initializers. The default causes libgcc's emulated TLS 39665 registration function to be used. 39666 39667 -- Target Hook: const char * TARGET_EMUTLS_VAR_SECTION 39668 Contains the name of the section in which TLS control variables 39669 should be placed. The default of 'NULL' allows these to be placed 39670 in any section. 39671 39672 -- Target Hook: const char * TARGET_EMUTLS_TMPL_SECTION 39673 Contains the name of the section in which TLS initializers should 39674 be placed. The default of 'NULL' allows these to be placed in any 39675 section. 39676 39677 -- Target Hook: const char * TARGET_EMUTLS_VAR_PREFIX 39678 Contains the prefix to be prepended to TLS control variable names. 39679 The default of 'NULL' uses a target-specific prefix. 39680 39681 -- Target Hook: const char * TARGET_EMUTLS_TMPL_PREFIX 39682 Contains the prefix to be prepended to TLS initializer objects. 39683 The default of 'NULL' uses a target-specific prefix. 39684 39685 -- Target Hook: tree TARGET_EMUTLS_VAR_FIELDS (tree TYPE, tree *NAME) 39686 Specifies a function that generates the FIELD_DECLs for a TLS 39687 control object type. TYPE is the RECORD_TYPE the fields are for 39688 and NAME should be filled with the structure tag, if the default of 39689 '__emutls_object' is unsuitable. The default creates a type 39690 suitable for libgcc's emulated TLS function. 39691 39692 -- Target Hook: tree TARGET_EMUTLS_VAR_INIT (tree VAR, tree DECL, tree 39693 TMPL_ADDR) 39694 Specifies a function that generates the CONSTRUCTOR to initialize a 39695 TLS control object. VAR is the TLS control object, DECL is the TLS 39696 object and TMPL_ADDR is the address of the initializer. The 39697 default initializes libgcc's emulated TLS control object. 39698 39699 -- Target Hook: bool TARGET_EMUTLS_VAR_ALIGN_FIXED 39700 Specifies whether the alignment of TLS control variable objects is 39701 fixed and should not be increased as some backends may do to 39702 optimize single objects. The default is false. 39703 39704 -- Target Hook: bool TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS 39705 Specifies whether a DWARF 'DW_OP_form_tls_address' location 39706 descriptor may be used to describe emulated TLS control objects. 39707 39708 39709File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Emulated TLS, Up: Target Macros 39710 3971118.26 Defining coprocessor specifics for MIPS targets. 39712====================================================== 39713 39714The MIPS specification allows MIPS implementations to have as many as 4 39715coprocessors, each with as many as 32 private registers. GCC supports 39716accessing these registers and transferring values between the registers 39717and memory using asm-ized variables. For example: 39718 39719 register unsigned int cp0count asm ("c0r1"); 39720 unsigned int d; 39721 39722 d = cp0count + 3; 39723 39724 ("c0r1" is the default name of register 1 in coprocessor 0; alternate 39725names may be added as described below, or the default names may be 39726overridden entirely in 'SUBTARGET_CONDITIONAL_REGISTER_USAGE'.) 39727 39728 Coprocessor registers are assumed to be epilogue-used; sets to them 39729will be preserved even if it does not appear that the register is used 39730again later in the function. 39731 39732 Another note: according to the MIPS spec, coprocessor 1 (if present) is 39733the FPU. One accesses COP1 registers through standard mips 39734floating-point support; they are not included in this mechanism. 39735 39736 39737File: gccint.info, Node: PCH Target, Next: C++ ABI, Prev: MIPS Coprocessors, Up: Target Macros 39738 3973918.27 Parameters for Precompiled Header Validity Checking 39740========================================================= 39741 39742 -- Target Hook: void * TARGET_GET_PCH_VALIDITY (size_t *SZ) 39743 This hook returns a pointer to the data needed by 39744 'TARGET_PCH_VALID_P' and sets '*SZ' to the size of the data in 39745 bytes. 39746 39747 -- Target Hook: const char * TARGET_PCH_VALID_P (const void *DATA, 39748 size_t SZ) 39749 This hook checks whether the options used to create a PCH file are 39750 compatible with the current settings. It returns 'NULL' if so and 39751 a suitable error message if not. Error messages will be presented 39752 to the user and must be localized using '_(MSG)'. 39753 39754 DATA is the data that was returned by 'TARGET_GET_PCH_VALIDITY' 39755 when the PCH file was created and SZ is the size of that data in 39756 bytes. It's safe to assume that the data was created by the same 39757 version of the compiler, so no format checking is needed. 39758 39759 The default definition of 'default_pch_valid_p' should be suitable 39760 for most targets. 39761 39762 -- Target Hook: const char * TARGET_CHECK_PCH_TARGET_FLAGS (int 39763 PCH_FLAGS) 39764 If this hook is nonnull, the default implementation of 39765 'TARGET_PCH_VALID_P' will use it to check for compatible values of 39766 'target_flags'. PCH_FLAGS specifies the value that 'target_flags' 39767 had when the PCH file was created. The return value is the same as 39768 for 'TARGET_PCH_VALID_P'. 39769 39770 -- Target Hook: void TARGET_PREPARE_PCH_SAVE (void) 39771 Called before writing out a PCH file. If the target has some 39772 garbage-collected data that needs to be in a particular state on 39773 PCH loads, it can use this hook to enforce that state. Very few 39774 targets need to do anything here. 39775 39776 39777File: gccint.info, Node: C++ ABI, Next: Named Address Spaces, Prev: PCH Target, Up: Target Macros 39778 3977918.28 C++ ABI parameters 39780======================== 39781 39782 -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void) 39783 Define this hook to override the integer type used for guard 39784 variables. These are used to implement one-time construction of 39785 static objects. The default is long_long_integer_type_node. 39786 39787 -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void) 39788 This hook determines how guard variables are used. It should 39789 return 'false' (the default) if the first byte should be used. A 39790 return value of 'true' indicates that only the least significant 39791 bit should be used. 39792 39793 -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE) 39794 This hook returns the size of the cookie to use when allocating an 39795 array whose elements have the indicated TYPE. Assumes that it is 39796 already known that a cookie is needed. The default is 'max(sizeof 39797 (size_t), alignof(type))', as defined in section 2.7 of the 39798 IA64/Generic C++ ABI. 39799 39800 -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void) 39801 This hook should return 'true' if the element size should be stored 39802 in array cookies. The default is to return 'false'. 39803 39804 -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int 39805 IMPORT_EXPORT) 39806 If defined by a backend this hook allows the decision made to 39807 export class TYPE to be overruled. Upon entry IMPORT_EXPORT will 39808 contain 1 if the class is going to be exported, -1 if it is going 39809 to be imported and 0 otherwise. This function should return the 39810 modified value and perform any other actions necessary to support 39811 the backend's targeted operating system. 39812 39813 -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void) 39814 This hook should return 'true' if constructors and destructors 39815 return the address of the object created/destroyed. The default is 39816 to return 'false'. 39817 39818 -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void) 39819 This hook returns true if the key method for a class (i.e., the 39820 method which, if defined in the current translation unit, causes 39821 the virtual table to be emitted) may be an inline function. Under 39822 the standard Itanium C++ ABI the key method may be an inline 39823 function so long as the function is not declared inline in the 39824 class definition. Under some variants of the ABI, an inline 39825 function can never be the key method. The default is to return 39826 'true'. 39827 39828 -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree 39829 DECL) 39830 DECL is a virtual table, virtual table table, typeinfo object, or 39831 other similar implicit class data object that will be emitted with 39832 external linkage in this translation unit. No ELF visibility has 39833 been explicitly specified. If the target needs to specify a 39834 visibility other than that of the containing class, use this hook 39835 to set 'DECL_VISIBILITY' and 'DECL_VISIBILITY_SPECIFIED'. 39836 39837 -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void) 39838 This hook returns true (the default) if virtual tables and other 39839 similar implicit class data objects are always COMDAT if they have 39840 external linkage. If this hook returns false, then class data for 39841 classes whose virtual table will be emitted in only one translation 39842 unit will not be COMDAT. 39843 39844 -- Target Hook: bool TARGET_CXX_LIBRARY_RTTI_COMDAT (void) 39845 This hook returns true (the default) if the RTTI information for 39846 the basic types which is defined in the C++ runtime should always 39847 be COMDAT, false if it should not be COMDAT. 39848 39849 -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void) 39850 This hook returns true if '__aeabi_atexit' (as defined by the ARM 39851 EABI) should be used to register static destructors when 39852 '-fuse-cxa-atexit' is in effect. The default is to return false to 39853 use '__cxa_atexit'. 39854 39855 -- Target Hook: bool TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT (void) 39856 This hook returns true if the target 'atexit' function can be used 39857 in the same manner as '__cxa_atexit' to register C++ static 39858 destructors. This requires that 'atexit'-registered functions in 39859 shared libraries are run in the correct order when the libraries 39860 are unloaded. The default is to return false. 39861 39862 -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE) 39863 TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has just 39864 been defined. Use this hook to make adjustments to the class (eg, 39865 tweak visibility or perform any other required target 39866 modifications). 39867 39868 -- Target Hook: tree TARGET_CXX_DECL_MANGLING_CONTEXT (const_tree DECL) 39869 Return target-specific mangling context of DECL or 'NULL_TREE'. 39870 39871 39872File: gccint.info, Node: Named Address Spaces, Next: Misc, Prev: C++ ABI, Up: Target Macros 39873 3987418.29 Adding support for named address spaces 39875============================================= 39876 39877The draft technical report of the ISO/IEC JTC1 S22 WG14 N1275 standards 39878committee, 'Programming Languages - C - Extensions to support embedded 39879processors', specifies a syntax for embedded processors to specify 39880alternate address spaces. You can configure a GCC port to support 39881section 5.1 of the draft report to add support for address spaces other 39882than the default address space. These address spaces are new keywords 39883that are similar to the 'volatile' and 'const' type attributes. 39884 39885 Pointers to named address spaces can have a different size than 39886pointers to the generic address space. 39887 39888 For example, the SPU port uses the '__ea' address space to refer to 39889memory in the host processor, rather than memory local to the SPU 39890processor. Access to memory in the '__ea' address space involves 39891issuing DMA operations to move data between the host processor and the 39892local processor memory address space. Pointers in the '__ea' address 39893space are either 32 bits or 64 bits based on the '-mea32' or '-mea64' 39894switches (native SPU pointers are always 32 bits). 39895 39896 Internally, address spaces are represented as a small integer in the 39897range 0 to 15 with address space 0 being reserved for the generic 39898address space. 39899 39900 To register a named address space qualifier keyword with the C front 39901end, the target may call the 'c_register_addr_space' routine. For 39902example, the SPU port uses the following to declare '__ea' as the 39903keyword for named address space #1: 39904 #define ADDR_SPACE_EA 1 39905 c_register_addr_space ("__ea", ADDR_SPACE_EA); 39906 39907 -- Target Hook: scalar_int_mode TARGET_ADDR_SPACE_POINTER_MODE 39908 (addr_space_t ADDRESS_SPACE) 39909 Define this to return the machine mode to use for pointers to 39910 ADDRESS_SPACE if the target supports named address spaces. The 39911 default version of this hook returns 'ptr_mode'. 39912 39913 -- Target Hook: scalar_int_mode TARGET_ADDR_SPACE_ADDRESS_MODE 39914 (addr_space_t ADDRESS_SPACE) 39915 Define this to return the machine mode to use for addresses in 39916 ADDRESS_SPACE if the target supports named address spaces. The 39917 default version of this hook returns 'Pmode'. 39918 39919 -- Target Hook: bool TARGET_ADDR_SPACE_VALID_POINTER_MODE 39920 (scalar_int_mode MODE, addr_space_t AS) 39921 Define this to return nonzero if the port can handle pointers with 39922 machine mode MODE to address space AS. This target hook is the 39923 same as the 'TARGET_VALID_POINTER_MODE' target hook, except that it 39924 includes explicit named address space support. The default version 39925 of this hook returns true for the modes returned by either the 39926 'TARGET_ADDR_SPACE_POINTER_MODE' or 39927 'TARGET_ADDR_SPACE_ADDRESS_MODE' target hooks for the given address 39928 space. 39929 39930 -- Target Hook: bool TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P 39931 (machine_mode MODE, rtx EXP, bool STRICT, addr_space_t AS) 39932 Define this to return true if EXP is a valid address for mode MODE 39933 in the named address space AS. The STRICT parameter says whether 39934 strict addressing is in effect after reload has finished. This 39935 target hook is the same as the 'TARGET_LEGITIMATE_ADDRESS_P' target 39936 hook, except that it includes explicit named address space support. 39937 39938 -- Target Hook: rtx TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS (rtx X, rtx 39939 OLDX, machine_mode MODE, addr_space_t AS) 39940 Define this to modify an invalid address X to be a valid address 39941 with mode MODE in the named address space AS. This target hook is 39942 the same as the 'TARGET_LEGITIMIZE_ADDRESS' target hook, except 39943 that it includes explicit named address space support. 39944 39945 -- Target Hook: bool TARGET_ADDR_SPACE_SUBSET_P (addr_space_t SUBSET, 39946 addr_space_t SUPERSET) 39947 Define this to return whether the SUBSET named address space is 39948 contained within the SUPERSET named address space. Pointers to a 39949 named address space that is a subset of another named address space 39950 will be converted automatically without a cast if used together in 39951 arithmetic operations. Pointers to a superset address space can be 39952 converted to pointers to a subset address space via explicit casts. 39953 39954 -- Target Hook: bool TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID (addr_space_t 39955 AS) 39956 Define this to modify the default handling of address 0 for the 39957 address space. Return true if 0 should be considered a valid 39958 address. 39959 39960 -- Target Hook: rtx TARGET_ADDR_SPACE_CONVERT (rtx OP, tree FROM_TYPE, 39961 tree TO_TYPE) 39962 Define this to convert the pointer expression represented by the 39963 RTL OP with type FROM_TYPE that points to a named address space to 39964 a new pointer expression with type TO_TYPE that points to a 39965 different named address space. When this hook it called, it is 39966 guaranteed that one of the two address spaces is a subset of the 39967 other, as determined by the 'TARGET_ADDR_SPACE_SUBSET_P' target 39968 hook. 39969 39970 -- Target Hook: int TARGET_ADDR_SPACE_DEBUG (addr_space_t AS) 39971 Define this to define how the address space is encoded in dwarf. 39972 The result is the value to be used with 'DW_AT_address_class'. 39973 39974 -- Target Hook: void TARGET_ADDR_SPACE_DIAGNOSE_USAGE (addr_space_t AS, 39975 location_t LOC) 39976 Define this hook if the availability of an address space depends on 39977 command line options and some diagnostics should be printed when 39978 the address space is used. This hook is called during parsing and 39979 allows to emit a better diagnostic compared to the case where the 39980 address space was not registered with 'c_register_addr_space'. AS 39981 is the address space as registered with 'c_register_addr_space'. 39982 LOC is the location of the address space qualifier token. The 39983 default implementation does nothing. 39984 39985 39986File: gccint.info, Node: Misc, Prev: Named Address Spaces, Up: Target Macros 39987 3998818.30 Miscellaneous Parameters 39989============================== 39990 39991Here are several miscellaneous parameters. 39992 39993 -- Macro: HAS_LONG_COND_BRANCH 39994 Define this boolean macro to indicate whether or not your 39995 architecture has conditional branches that can span all of memory. 39996 It is used in conjunction with an optimization that partitions hot 39997 and cold basic blocks into separate sections of the executable. If 39998 this macro is set to false, gcc will convert any conditional 39999 branches that attempt to cross between sections into unconditional 40000 branches or indirect jumps. 40001 40002 -- Macro: HAS_LONG_UNCOND_BRANCH 40003 Define this boolean macro to indicate whether or not your 40004 architecture has unconditional branches that can span all of 40005 memory. It is used in conjunction with an optimization that 40006 partitions hot and cold basic blocks into separate sections of the 40007 executable. If this macro is set to false, gcc will convert any 40008 unconditional branches that attempt to cross between sections into 40009 indirect jumps. 40010 40011 -- Macro: CASE_VECTOR_MODE 40012 An alias for a machine mode name. This is the machine mode that 40013 elements of a jump-table should have. 40014 40015 -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY) 40016 Optional: return the preferred mode for an 'addr_diff_vec' when the 40017 minimum and maximum offset are known. If you define this, it 40018 enables extra code in branch shortening to deal with 40019 'addr_diff_vec'. To make this work, you also have to define 40020 'INSN_ALIGN' and make the alignment for 'addr_diff_vec' explicit. 40021 The BODY argument is provided so that the offset_unsigned and scale 40022 flags can be updated. 40023 40024 -- Macro: CASE_VECTOR_PC_RELATIVE 40025 Define this macro to be a C expression to indicate when jump-tables 40026 should contain relative addresses. You need not define this macro 40027 if jump-tables never contain relative addresses, or jump-tables 40028 should contain relative addresses only when '-fPIC' or '-fPIC' is 40029 in effect. 40030 40031 -- Target Hook: unsigned int TARGET_CASE_VALUES_THRESHOLD (void) 40032 This function return the smallest number of different values for 40033 which it is best to use a jump-table instead of a tree of 40034 conditional branches. The default is four for machines with a 40035 'casesi' instruction and five otherwise. This is best for most 40036 machines. 40037 40038 -- Macro: WORD_REGISTER_OPERATIONS 40039 Define this macro to 1 if operations between registers with 40040 integral mode smaller than a word are always performed on the 40041 entire register. To be more explicit, if you start with a pair of 40042 'word_mode' registers with known values and you do a subword, for 40043 example 'QImode', addition on the low part of the registers, then 40044 the compiler may consider that the result has a known value in 40045 'word_mode' too if the macro is defined to 1. Most RISC machines 40046 have this property and most CISC machines do not. 40047 40048 -- Target Hook: unsigned int TARGET_MIN_ARITHMETIC_PRECISION (void) 40049 On some RISC architectures with 64-bit registers, the processor 40050 also maintains 32-bit condition codes that make it possible to do 40051 real 32-bit arithmetic, although the operations are performed on 40052 the full registers. 40053 40054 On such architectures, defining this hook to 32 tells the compiler 40055 to try using 32-bit arithmetical operations setting the condition 40056 codes instead of doing full 64-bit arithmetic. 40057 40058 More generally, define this hook on RISC architectures if you want 40059 the compiler to try using arithmetical operations setting the 40060 condition codes with a precision lower than the word precision. 40061 40062 You need not define this hook if 'WORD_REGISTER_OPERATIONS' is not 40063 defined to 1. 40064 40065 -- Macro: LOAD_EXTEND_OP (MEM_MODE) 40066 Define this macro to be a C expression indicating when insns that 40067 read memory in MEM_MODE, an integral mode narrower than a word, set 40068 the bits outside of MEM_MODE to be either the sign-extension or the 40069 zero-extension of the data read. Return 'SIGN_EXTEND' for values 40070 of MEM_MODE for which the insn sign-extends, 'ZERO_EXTEND' for 40071 which it zero-extends, and 'UNKNOWN' for other modes. 40072 40073 This macro is not called with MEM_MODE non-integral or with a width 40074 greater than or equal to 'BITS_PER_WORD', so you may return any 40075 value in this case. Do not define this macro if it would always 40076 return 'UNKNOWN'. On machines where this macro is defined, you 40077 will normally define it as the constant 'SIGN_EXTEND' or 40078 'ZERO_EXTEND'. 40079 40080 You may return a non-'UNKNOWN' value even if for some hard 40081 registers the sign extension is not performed, if for the 40082 'REGNO_REG_CLASS' of these hard registers 40083 'TARGET_CAN_CHANGE_MODE_CLASS' returns false when the FROM mode is 40084 MEM_MODE and the TO mode is any integral mode larger than this but 40085 not larger than 'word_mode'. 40086 40087 You must return 'UNKNOWN' if for some hard registers that allow 40088 this mode, 'TARGET_CAN_CHANGE_MODE_CLASS' says that they cannot 40089 change to 'word_mode', but that they can change to another integral 40090 mode that is larger then MEM_MODE but still smaller than 40091 'word_mode'. 40092 40093 -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND 40094 Define this macro to 1 if loading short immediate values into 40095 registers sign extends. 40096 40097 -- Target Hook: unsigned int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL 40098 (machine_mode MODE) 40099 When '-ffast-math' is in effect, GCC tries to optimize divisions by 40100 the same divisor, by turning them into multiplications by the 40101 reciprocal. This target hook specifies the minimum number of 40102 divisions that should be there for GCC to perform the optimization 40103 for a variable of mode MODE. The default implementation returns 3 40104 if the machine has an instruction for the division, and 2 if it 40105 does not. 40106 40107 -- Macro: MOVE_MAX 40108 The maximum number of bytes that a single instruction can move 40109 quickly between memory and registers or between two memory 40110 locations. 40111 40112 -- Macro: MAX_MOVE_MAX 40113 The maximum number of bytes that a single instruction can move 40114 quickly between memory and registers or between two memory 40115 locations. If this is undefined, the default is 'MOVE_MAX'. 40116 Otherwise, it is the constant value that is the largest value that 40117 'MOVE_MAX' can have at run-time. 40118 40119 -- Macro: SHIFT_COUNT_TRUNCATED 40120 A C expression that is nonzero if on this machine the number of 40121 bits actually used for the count of a shift operation is equal to 40122 the number of bits needed to represent the size of the object being 40123 shifted. When this macro is nonzero, the compiler will assume that 40124 it is safe to omit a sign-extend, zero-extend, and certain bitwise 40125 'and' instructions that truncates the count of a shift operation. 40126 On machines that have instructions that act on bit-fields at 40127 variable positions, which may include 'bit test' instructions, a 40128 nonzero 'SHIFT_COUNT_TRUNCATED' also enables deletion of 40129 truncations of the values that serve as arguments to bit-field 40130 instructions. 40131 40132 If both types of instructions truncate the count (for shifts) and 40133 position (for bit-field operations), or if no variable-position 40134 bit-field instructions exist, you should define this macro. 40135 40136 However, on some machines, such as the 80386 and the 680x0, 40137 truncation only applies to shift operations and not the (real or 40138 pretended) bit-field operations. Define 'SHIFT_COUNT_TRUNCATED' to 40139 be zero on such machines. Instead, add patterns to the 'md' file 40140 that include the implied truncation of the shift instructions. 40141 40142 You need not define this macro if it would always have the value of 40143 zero. 40144 40145 -- Target Hook: unsigned HOST_WIDE_INT TARGET_SHIFT_TRUNCATION_MASK 40146 (machine_mode MODE) 40147 This function describes how the standard shift patterns for MODE 40148 deal with shifts by negative amounts or by more than the width of 40149 the mode. *Note shift patterns::. 40150 40151 On many machines, the shift patterns will apply a mask M to the 40152 shift count, meaning that a fixed-width shift of X by Y is 40153 equivalent to an arbitrary-width shift of X by Y & M. If this is 40154 true for mode MODE, the function should return M, otherwise it 40155 should return 0. A return value of 0 indicates that no particular 40156 behavior is guaranteed. 40157 40158 Note that, unlike 'SHIFT_COUNT_TRUNCATED', this function does _not_ 40159 apply to general shift rtxes; it applies only to instructions that 40160 are generated by the named shift patterns. 40161 40162 The default implementation of this function returns 40163 'GET_MODE_BITSIZE (MODE) - 1' if 'SHIFT_COUNT_TRUNCATED' and 0 40164 otherwise. This definition is always safe, but if 40165 'SHIFT_COUNT_TRUNCATED' is false, and some shift patterns 40166 nevertheless truncate the shift count, you may get better code by 40167 overriding it. 40168 40169 -- Target Hook: bool TARGET_TRULY_NOOP_TRUNCATION (poly_uint64 OUTPREC, 40170 poly_uint64 INPREC) 40171 This hook returns true if it is safe to "convert" a value of INPREC 40172 bits to one of OUTPREC bits (where OUTPREC is smaller than INPREC) 40173 by merely operating on it as if it had only OUTPREC bits. The 40174 default returns true unconditionally, which is correct for most 40175 machines. 40176 40177 If 'TARGET_MODES_TIEABLE_P' returns false for a pair of modes, 40178 suboptimal code can result if this hook returns true for the 40179 corresponding mode sizes. Making this hook return false in such 40180 cases may improve things. 40181 40182 -- Target Hook: int TARGET_MODE_REP_EXTENDED (scalar_int_mode MODE, 40183 scalar_int_mode REP_MODE) 40184 The representation of an integral mode can be such that the values 40185 are always extended to a wider integral mode. Return 'SIGN_EXTEND' 40186 if values of MODE are represented in sign-extended form to 40187 REP_MODE. Return 'UNKNOWN' otherwise. (Currently, none of the 40188 targets use zero-extended representation this way so unlike 40189 'LOAD_EXTEND_OP', 'TARGET_MODE_REP_EXTENDED' is expected to return 40190 either 'SIGN_EXTEND' or 'UNKNOWN'. Also no target extends MODE to 40191 REP_MODE so that REP_MODE is not the next widest integral mode and 40192 currently we take advantage of this fact.) 40193 40194 Similarly to 'LOAD_EXTEND_OP' you may return a non-'UNKNOWN' value 40195 even if the extension is not performed on certain hard registers as 40196 long as for the 'REGNO_REG_CLASS' of these hard registers 40197 'TARGET_CAN_CHANGE_MODE_CLASS' returns false. 40198 40199 Note that 'TARGET_MODE_REP_EXTENDED' and 'LOAD_EXTEND_OP' describe 40200 two related properties. If you define 'TARGET_MODE_REP_EXTENDED 40201 (mode, word_mode)' you probably also want to define 'LOAD_EXTEND_OP 40202 (mode)' to return the same type of extension. 40203 40204 In order to enforce the representation of 'mode', 40205 'TARGET_TRULY_NOOP_TRUNCATION' should return false when truncating 40206 to 'mode'. 40207 40208 -- Macro: STORE_FLAG_VALUE 40209 A C expression describing the value returned by a comparison 40210 operator with an integral mode and stored by a store-flag 40211 instruction ('cstoreMODE4') when the condition is true. This 40212 description must apply to _all_ the 'cstoreMODE4' patterns and all 40213 the comparison operators whose results have a 'MODE_INT' mode. 40214 40215 A value of 1 or -1 means that the instruction implementing the 40216 comparison operator returns exactly 1 or -1 when the comparison is 40217 true and 0 when the comparison is false. Otherwise, the value 40218 indicates which bits of the result are guaranteed to be 1 when the 40219 comparison is true. This value is interpreted in the mode of the 40220 comparison operation, which is given by the mode of the first 40221 operand in the 'cstoreMODE4' pattern. Either the low bit or the 40222 sign bit of 'STORE_FLAG_VALUE' be on. Presently, only those bits 40223 are used by the compiler. 40224 40225 If 'STORE_FLAG_VALUE' is neither 1 or -1, the compiler will 40226 generate code that depends only on the specified bits. It can also 40227 replace comparison operators with equivalent operations if they 40228 cause the required bits to be set, even if the remaining bits are 40229 undefined. For example, on a machine whose comparison operators 40230 return an 'SImode' value and where 'STORE_FLAG_VALUE' is defined as 40231 '0x80000000', saying that just the sign bit is relevant, the 40232 expression 40233 40234 (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0)) 40235 40236 can be converted to 40237 40238 (ashift:SI X (const_int N)) 40239 40240 where N is the appropriate shift count to move the bit being tested 40241 into the sign bit. 40242 40243 There is no way to describe a machine that always sets the 40244 low-order bit for a true value, but does not guarantee the value of 40245 any other bits, but we do not know of any machine that has such an 40246 instruction. If you are trying to port GCC to such a machine, 40247 include an instruction to perform a logical-and of the result with 40248 1 in the pattern for the comparison operators and let us know at 40249 <gcc@gcc.gnu.org>. 40250 40251 Often, a machine will have multiple instructions that obtain a 40252 value from a comparison (or the condition codes). Here are rules 40253 to guide the choice of value for 'STORE_FLAG_VALUE', and hence the 40254 instructions to be used: 40255 40256 * Use the shortest sequence that yields a valid definition for 40257 'STORE_FLAG_VALUE'. It is more efficient for the compiler to 40258 "normalize" the value (convert it to, e.g., 1 or 0) than for 40259 the comparison operators to do so because there may be 40260 opportunities to combine the normalization with other 40261 operations. 40262 40263 * For equal-length sequences, use a value of 1 or -1, with -1 40264 being slightly preferred on machines with expensive jumps and 40265 1 preferred on other machines. 40266 40267 * As a second choice, choose a value of '0x80000001' if 40268 instructions exist that set both the sign and low-order bits 40269 but do not define the others. 40270 40271 * Otherwise, use a value of '0x80000000'. 40272 40273 Many machines can produce both the value chosen for 40274 'STORE_FLAG_VALUE' and its negation in the same number of 40275 instructions. On those machines, you should also define a pattern 40276 for those cases, e.g., one matching 40277 40278 (set A (neg:M (ne:M B C))) 40279 40280 Some machines can also perform 'and' or 'plus' operations on 40281 condition code values with less instructions than the corresponding 40282 'cstoreMODE4' insn followed by 'and' or 'plus'. On those machines, 40283 define the appropriate patterns. Use the names 'incscc' and 40284 'decscc', respectively, for the patterns which perform 'plus' or 40285 'minus' operations on condition code values. See 'rs6000.md' for 40286 some examples. The GNU Superoptimizer can be used to find such 40287 instruction sequences on other machines. 40288 40289 If this macro is not defined, the default value, 1, is used. You 40290 need not define 'STORE_FLAG_VALUE' if the machine has no store-flag 40291 instructions, or if the value generated by these instructions is 1. 40292 40293 -- Macro: FLOAT_STORE_FLAG_VALUE (MODE) 40294 A C expression that gives a nonzero 'REAL_VALUE_TYPE' value that is 40295 returned when comparison operators with floating-point results are 40296 true. Define this macro on machines that have comparison 40297 operations that return floating-point values. If there are no such 40298 operations, do not define this macro. 40299 40300 -- Macro: VECTOR_STORE_FLAG_VALUE (MODE) 40301 A C expression that gives a rtx representing the nonzero true 40302 element for vector comparisons. The returned rtx should be valid 40303 for the inner mode of MODE which is guaranteed to be a vector mode. 40304 Define this macro on machines that have vector comparison 40305 operations that return a vector result. If there are no such 40306 operations, do not define this macro. Typically, this macro is 40307 defined as 'const1_rtx' or 'constm1_rtx'. This macro may return 40308 'NULL_RTX' to prevent the compiler optimizing such vector 40309 comparison operations for the given mode. 40310 40311 -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 40312 -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 40313 A C expression that indicates whether the architecture defines a 40314 value for 'clz' or 'ctz' with a zero operand. A result of '0' 40315 indicates the value is undefined. If the value is defined for only 40316 the RTL expression, the macro should evaluate to '1'; if the value 40317 applies also to the corresponding optab entry (which is normally 40318 the case if it expands directly into the corresponding RTL), then 40319 the macro should evaluate to '2'. In the cases where the value is 40320 defined, VALUE should be set to this value. 40321 40322 If this macro is not defined, the value of 'clz' or 'ctz' at zero 40323 is assumed to be undefined. 40324 40325 This macro must be defined if the target's expansion for 'ffs' 40326 relies on a particular value to get correct results. Otherwise it 40327 is not necessary, though it may be used to optimize some corner 40328 cases, and to provide a default expansion for the 'ffs' optab. 40329 40330 Note that regardless of this macro the "definedness" of 'clz' and 40331 'ctz' at zero do _not_ extend to the builtin functions visible to 40332 the user. Thus one may be free to adjust the value at will to 40333 match the target expansion of these operations without fear of 40334 breaking the API. 40335 40336 -- Macro: Pmode 40337 An alias for the machine mode for pointers. On most machines, 40338 define this to be the integer mode corresponding to the width of a 40339 hardware pointer; 'SImode' on 32-bit machine or 'DImode' on 64-bit 40340 machines. On some machines you must define this to be one of the 40341 partial integer modes, such as 'PSImode'. 40342 40343 The width of 'Pmode' must be at least as large as the value of 40344 'POINTER_SIZE'. If it is not equal, you must define the macro 40345 'POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to 40346 'Pmode'. 40347 40348 -- Macro: FUNCTION_MODE 40349 An alias for the machine mode used for memory references to 40350 functions being called, in 'call' RTL expressions. On most CISC 40351 machines, where an instruction can begin at any byte address, this 40352 should be 'QImode'. On most RISC machines, where all instructions 40353 have fixed size and alignment, this should be a mode with the same 40354 size and alignment as the machine instruction words - typically 40355 'SImode' or 'HImode'. 40356 40357 -- Macro: STDC_0_IN_SYSTEM_HEADERS 40358 In normal operation, the preprocessor expands '__STDC__' to the 40359 constant 1, to signify that GCC conforms to ISO Standard C. On 40360 some hosts, like Solaris, the system compiler uses a different 40361 convention, where '__STDC__' is normally 0, but is 1 if the user 40362 specifies strict conformance to the C Standard. 40363 40364 Defining 'STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host 40365 convention when processing system header files, but when processing 40366 user files '__STDC__' will always expand to 1. 40367 40368 -- C Target Hook: const char * TARGET_C_PREINCLUDE (void) 40369 Define this hook to return the name of a header file to be included 40370 at the start of all compilations, as if it had been included with 40371 '#include <FILE>'. If this hook returns 'NULL', or is not defined, 40372 or the header is not found, or if the user specifies 40373 '-ffreestanding' or '-nostdinc', no header is included. 40374 40375 This hook can be used together with a header provided by the system 40376 C library to implement ISO C requirements for certain macros to be 40377 predefined that describe properties of the whole implementation 40378 rather than just the compiler. 40379 40380 -- C Target Hook: bool TARGET_CXX_IMPLICIT_EXTERN_C (const char*) 40381 Define this hook to add target-specific C++ implicit extern C 40382 functions. If this function returns true for the name of a 40383 file-scope function, that function implicitly gets extern "C" 40384 linkage rather than whatever language linkage the declaration would 40385 normally have. An example of such function is WinMain on Win32 40386 targets. 40387 40388 -- Macro: NO_IMPLICIT_EXTERN_C 40389 Define this macro if the system header files support C++ as well as 40390 C. This macro inhibits the usual method of using system header 40391 files in C++, which is to pretend that the file's contents are 40392 enclosed in 'extern "C" {...}'. 40393 40394 -- Macro: REGISTER_TARGET_PRAGMAS () 40395 Define this macro if you want to implement any target-specific 40396 pragmas. If defined, it is a C expression which makes a series of 40397 calls to 'c_register_pragma' or 'c_register_pragma_with_expansion' 40398 for each pragma. The macro may also do any setup required for the 40399 pragmas. 40400 40401 The primary reason to define this macro is to provide compatibility 40402 with other compilers for the same target. In general, we 40403 discourage definition of target-specific pragmas for GCC. 40404 40405 If the pragma can be implemented by attributes then you should 40406 consider defining the target hook 'TARGET_INSERT_ATTRIBUTES' as 40407 well. 40408 40409 Preprocessor macros that appear on pragma lines are not expanded. 40410 All '#pragma' directives that do not match any registered pragma 40411 are silently ignored, unless the user specifies 40412 '-Wunknown-pragmas'. 40413 40414 -- Function: void c_register_pragma (const char *SPACE, const char 40415 *NAME, void (*CALLBACK) (struct cpp_reader *)) 40416 -- Function: void c_register_pragma_with_expansion (const char *SPACE, 40417 const char *NAME, void (*CALLBACK) (struct cpp_reader *)) 40418 40419 Each call to 'c_register_pragma' or 40420 'c_register_pragma_with_expansion' establishes one pragma. The 40421 CALLBACK routine will be called when the preprocessor encounters a 40422 pragma of the form 40423 40424 #pragma [SPACE] NAME ... 40425 40426 SPACE is the case-sensitive namespace of the pragma, or 'NULL' to 40427 put the pragma in the global namespace. The callback routine 40428 receives PFILE as its first argument, which can be passed on to 40429 cpplib's functions if necessary. You can lex tokens after the NAME 40430 by calling 'pragma_lex'. Tokens that are not read by the callback 40431 will be silently ignored. The end of the line is indicated by a 40432 token of type 'CPP_EOF'. Macro expansion occurs on the arguments 40433 of pragmas registered with 'c_register_pragma_with_expansion' but 40434 not on the arguments of pragmas registered with 40435 'c_register_pragma'. 40436 40437 Note that the use of 'pragma_lex' is specific to the C and C++ 40438 compilers. It will not work in the Java or Fortran compilers, or 40439 any other language compilers for that matter. Thus if 'pragma_lex' 40440 is going to be called from target-specific code, it must only be 40441 done so when building the C and C++ compilers. This can be done by 40442 defining the variables 'c_target_objs' and 'cxx_target_objs' in the 40443 target entry in the 'config.gcc' file. These variables should name 40444 the target-specific, language-specific object file which contains 40445 the code that uses 'pragma_lex'. Note it will also be necessary to 40446 add a rule to the makefile fragment pointed to by 'tmake_file' that 40447 shows how to build this object file. 40448 40449 -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION 40450 Define this macro if macros should be expanded in the arguments of 40451 '#pragma pack'. 40452 40453 -- Macro: TARGET_DEFAULT_PACK_STRUCT 40454 If your target requires a structure packing default other than 0 40455 (meaning the machine default), define this macro to the necessary 40456 value (in bytes). This must be a value that would also be valid to 40457 use with '#pragma pack()' (that is, a small power of two). 40458 40459 -- Macro: DOLLARS_IN_IDENTIFIERS 40460 Define this macro to control use of the character '$' in identifier 40461 names for the C family of languages. 0 means '$' is not allowed by 40462 default; 1 means it is allowed. 1 is the default; there is no need 40463 to define this macro in that case. 40464 40465 -- Macro: INSN_SETS_ARE_DELAYED (INSN) 40466 Define this macro as a C expression that is nonzero if it is safe 40467 for the delay slot scheduler to place instructions in the delay 40468 slot of INSN, even if they appear to use a resource set or 40469 clobbered in INSN. INSN is always a 'jump_insn' or an 'insn'; GCC 40470 knows that every 'call_insn' has this behavior. On machines where 40471 some 'insn' or 'jump_insn' is really a function call and hence has 40472 this behavior, you should define this macro. 40473 40474 You need not define this macro if it would always return zero. 40475 40476 -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN) 40477 Define this macro as a C expression that is nonzero if it is safe 40478 for the delay slot scheduler to place instructions in the delay 40479 slot of INSN, even if they appear to set or clobber a resource 40480 referenced in INSN. INSN is always a 'jump_insn' or an 'insn'. On 40481 machines where some 'insn' or 'jump_insn' is really a function call 40482 and its operands are registers whose use is actually in the 40483 subroutine it calls, you should define this macro. Doing so allows 40484 the delay slot scheduler to move instructions which copy arguments 40485 into the argument registers into the delay slot of INSN. 40486 40487 You need not define this macro if it would always return zero. 40488 40489 -- Macro: MULTIPLE_SYMBOL_SPACES 40490 Define this macro as a C expression that is nonzero if, in some 40491 cases, global symbols from one translation unit may not be bound to 40492 undefined symbols in another translation unit without user 40493 intervention. For instance, under Microsoft Windows symbols must 40494 be explicitly imported from shared libraries (DLLs). 40495 40496 You need not define this macro if it would always evaluate to zero. 40497 40498 -- Target Hook: rtx_insn * TARGET_MD_ASM_ADJUST (vec<rtx>& OUTPUTS, 40499 vec<rtx>& INPUTS, vec<const char *>& CONSTRAINTS, vec<rtx>& 40500 CLOBBERS, HARD_REG_SET& CLOBBERED_REGS) 40501 This target hook may add "clobbers" to CLOBBERS and CLOBBERED_REGS 40502 for any hard regs the port wishes to automatically clobber for an 40503 asm. The OUTPUTS and INPUTS may be inspected to avoid clobbering a 40504 register that is already used by the asm. 40505 40506 It may modify the OUTPUTS, INPUTS, and CONSTRAINTS as necessary for 40507 other pre-processing. In this case the return value is a sequence 40508 of insns to emit after the asm. 40509 40510 -- Macro: MATH_LIBRARY 40511 Define this macro as a C string constant for the linker argument to 40512 link in the system math library, minus the initial '"-l"', or '""' 40513 if the target does not have a separate math library. 40514 40515 You need only define this macro if the default of '"m"' is wrong. 40516 40517 -- Macro: LIBRARY_PATH_ENV 40518 Define this macro as a C string constant for the environment 40519 variable that specifies where the linker should look for libraries. 40520 40521 You need only define this macro if the default of '"LIBRARY_PATH"' 40522 is wrong. 40523 40524 -- Macro: TARGET_POSIX_IO 40525 Define this macro if the target supports the following POSIX file 40526 functions, access, mkdir and file locking with fcntl / F_SETLKW. 40527 Defining 'TARGET_POSIX_IO' will enable the test coverage code to 40528 use file locking when exiting a program, which avoids race 40529 conditions if the program has forked. It will also create 40530 directories at run-time for cross-profiling. 40531 40532 -- Macro: MAX_CONDITIONAL_EXECUTE 40533 40534 A C expression for the maximum number of instructions to execute 40535 via conditional execution instructions instead of a branch. A 40536 value of 'BRANCH_COST'+1 is the default if the machine does not use 40537 cc0, and 1 if it does use cc0. 40538 40539 -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR) 40540 Used if the target needs to perform machine-dependent modifications 40541 on the conditionals used for turning basic blocks into 40542 conditionally executed code. CE_INFO points to a data structure, 40543 'struct ce_if_block', which contains information about the 40544 currently processed blocks. TRUE_EXPR and FALSE_EXPR are the tests 40545 that are used for converting the then-block and the else-block, 40546 respectively. Set either TRUE_EXPR or FALSE_EXPR to a null pointer 40547 if the tests cannot be converted. 40548 40549 -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR, 40550 FALSE_EXPR) 40551 Like 'IFCVT_MODIFY_TESTS', but used when converting more 40552 complicated if-statements into conditions combined by 'and' and 40553 'or' operations. BB contains the basic block that contains the 40554 test that is currently being processed and about to be turned into 40555 a condition. 40556 40557 -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN) 40558 A C expression to modify the PATTERN of an INSN that is to be 40559 converted to conditional execution format. CE_INFO points to a 40560 data structure, 'struct ce_if_block', which contains information 40561 about the currently processed blocks. 40562 40563 -- Macro: IFCVT_MODIFY_FINAL (CE_INFO) 40564 A C expression to perform any final machine dependent modifications 40565 in converting code to conditional execution. The involved basic 40566 blocks can be found in the 'struct ce_if_block' structure that is 40567 pointed to by CE_INFO. 40568 40569 -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO) 40570 A C expression to cancel any machine dependent modifications in 40571 converting code to conditional execution. The involved basic 40572 blocks can be found in the 'struct ce_if_block' structure that is 40573 pointed to by CE_INFO. 40574 40575 -- Macro: IFCVT_MACHDEP_INIT (CE_INFO) 40576 A C expression to initialize any machine specific data for 40577 if-conversion of the if-block in the 'struct ce_if_block' structure 40578 that is pointed to by CE_INFO. 40579 40580 -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG (void) 40581 If non-null, this hook performs a target-specific pass over the 40582 instruction stream. The compiler will run it at all optimization 40583 levels, just before the point at which it normally does 40584 delayed-branch scheduling. 40585 40586 The exact purpose of the hook varies from target to target. Some 40587 use it to do transformations that are necessary for correctness, 40588 such as laying out in-function constant pools or avoiding hardware 40589 hazards. Others use it as an opportunity to do some 40590 machine-dependent optimizations. 40591 40592 You need not implement the hook if it has nothing to do. The 40593 default definition is null. 40594 40595 -- Target Hook: void TARGET_INIT_BUILTINS (void) 40596 Define this hook if you have any machine-specific built-in 40597 functions that need to be defined. It should be a function that 40598 performs the necessary setup. 40599 40600 Machine specific built-in functions can be useful to expand special 40601 machine instructions that would otherwise not normally be generated 40602 because they have no equivalent in the source language (for 40603 example, SIMD vector instructions or prefetch instructions). 40604 40605 To create a built-in function, call the function 40606 'lang_hooks.builtin_function' which is defined by the language 40607 front end. You can use any type nodes set up by 40608 'build_common_tree_nodes'; only language front ends that use those 40609 two functions will call 'TARGET_INIT_BUILTINS'. 40610 40611 -- Target Hook: tree TARGET_BUILTIN_DECL (unsigned CODE, bool 40612 INITIALIZE_P) 40613 Define this hook if you have any machine-specific built-in 40614 functions that need to be defined. It should be a function that 40615 returns the builtin function declaration for the builtin function 40616 code CODE. If there is no such builtin and it cannot be 40617 initialized at this time if INITIALIZE_P is true the function 40618 should return 'NULL_TREE'. If CODE is out of range the function 40619 should return 'error_mark_node'. 40620 40621 -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx 40622 SUBTARGET, machine_mode MODE, int IGNORE) 40623 40624 Expand a call to a machine specific built-in function that was set 40625 up by 'TARGET_INIT_BUILTINS'. EXP is the expression for the 40626 function call; the result should go to TARGET if that is 40627 convenient, and have mode MODE if that is convenient. SUBTARGET 40628 may be used as the target for computing one of EXP's operands. 40629 IGNORE is nonzero if the value is to be ignored. This function 40630 should return the result of the call to the built-in function. 40631 40632 -- Target Hook: tree TARGET_BUILTIN_CHKP_FUNCTION (unsigned FCODE) 40633 This hook allows target to redefine built-in functions used by 40634 Pointer Bounds Checker for code instrumentation. Hook should 40635 return fndecl of function implementing generic builtin whose code 40636 is passed in FCODE. Currently following built-in functions are 40637 obtained using this hook: 40638 -- Built-in Function: __bounds_type __chkp_bndmk (const void *LB, 40639 size_t SIZE) 40640 Function code - BUILT_IN_CHKP_BNDMK. This built-in function is 40641 used by Pointer Bounds Checker to create bound values. LB 40642 holds low bound of the resulting bounds. SIZE holds size of 40643 created bounds. 40644 40645 -- Built-in Function: void __chkp_bndstx (const void *PTR, 40646 __bounds_type B, const void **LOC) 40647 Function code - 'BUILT_IN_CHKP_BNDSTX'. This built-in 40648 function is used by Pointer Bounds Checker to store bounds B 40649 for pointer PTR when PTR is stored by address LOC. 40650 40651 -- Built-in Function: __bounds_type __chkp_bndldx (const void 40652 **LOC, const void *PTR) 40653 Function code - 'BUILT_IN_CHKP_BNDLDX'. This built-in 40654 function is used by Pointer Bounds Checker to get bounds of 40655 pointer PTR loaded by address LOC. 40656 40657 -- Built-in Function: void __chkp_bndcl (const void *PTR, 40658 __bounds_type B) 40659 Function code - 'BUILT_IN_CHKP_BNDCL'. This built-in function 40660 is used by Pointer Bounds Checker to perform check for pointer 40661 PTR against lower bound of bounds B. 40662 40663 -- Built-in Function: void __chkp_bndcu (const void *PTR, 40664 __bounds_type B) 40665 Function code - 'BUILT_IN_CHKP_BNDCU'. This built-in function 40666 is used by Pointer Bounds Checker to perform check for pointer 40667 PTR against upper bound of bounds B. 40668 40669 -- Built-in Function: __bounds_type __chkp_bndret (void *PTR) 40670 Function code - 'BUILT_IN_CHKP_BNDRET'. This built-in 40671 function is used by Pointer Bounds Checker to obtain bounds 40672 returned by a call statement. PTR passed to built-in is 40673 'SSA_NAME' returned by the call. 40674 40675 -- Built-in Function: __bounds_type __chkp_intersect 40676 (__bounds_type B1, __bounds_type B2) 40677 Function code - 'BUILT_IN_CHKP_INTERSECT'. This built-in 40678 function returns intersection of bounds B1 and B2. 40679 40680 -- Built-in Function: __bounds_type __chkp_narrow (const void 40681 *PTR, __bounds_type B, size_t S) 40682 Function code - 'BUILT_IN_CHKP_NARROW'. This built-in 40683 function returns intersection of bounds B and [PTR, PTR + S - 40684 '1']. 40685 40686 -- Built-in Function: size_t __chkp_sizeof (const void *PTR) 40687 Function code - 'BUILT_IN_CHKP_SIZEOF'. This built-in 40688 function returns size of object referenced by PTR. PTR is 40689 always 'ADDR_EXPR' of 'VAR_DECL'. This built-in is used by 40690 Pointer Bounds Checker when bounds of object cannot be 40691 computed statically (e.g. object has incomplete type). 40692 40693 -- Built-in Function: const void *__chkp_extract_lower 40694 (__bounds_type B) 40695 Function code - 'BUILT_IN_CHKP_EXTRACT_LOWER'. This built-in 40696 function returns lower bound of bounds B. 40697 40698 -- Built-in Function: const void *__chkp_extract_upper 40699 (__bounds_type B) 40700 Function code - 'BUILT_IN_CHKP_EXTRACT_UPPER'. This built-in 40701 function returns upper bound of bounds B. 40702 -- Target Hook: tree TARGET_CHKP_BOUND_TYPE (void) 40703 Return type to be used for bounds 40704 -- Target Hook: machine_mode TARGET_CHKP_BOUND_MODE (void) 40705 Return mode to be used for bounds. 40706 -- Target Hook: tree TARGET_CHKP_MAKE_BOUNDS_CONSTANT (HOST_WIDE_INT 40707 LB, HOST_WIDE_INT UB) 40708 Return constant used to statically initialize constant bounds with 40709 specified lower bound LB and upper bounds UB. 40710 -- Target Hook: int TARGET_CHKP_INITIALIZE_BOUNDS (tree VAR, tree LB, 40711 tree UB, tree *STMTS) 40712 Generate a list of statements STMTS to initialize pointer bounds 40713 variable VAR with bounds LB and UB. Return the number of generated 40714 statements. 40715 40716 -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (unsigned int 40717 LOC, tree FNDECL, void *ARGLIST) 40718 Select a replacement for a machine specific built-in function that 40719 was set up by 'TARGET_INIT_BUILTINS'. This is done _before_ 40720 regular type checking, and so allows the target to implement a 40721 crude form of function overloading. FNDECL is the declaration of 40722 the built-in function. ARGLIST is the list of arguments passed to 40723 the built-in function. The result is a complete expression that 40724 implements the operation, usually another 'CALL_EXPR'. ARGLIST 40725 really has type 'VEC(tree,gc)*' 40726 40727 -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, int N_ARGS, tree 40728 *ARGP, bool IGNORE) 40729 Fold a call to a machine specific built-in function that was set up 40730 by 'TARGET_INIT_BUILTINS'. FNDECL is the declaration of the 40731 built-in function. N_ARGS is the number of arguments passed to the 40732 function; the arguments themselves are pointed to by ARGP. The 40733 result is another tree, valid for both GIMPLE and GENERIC, 40734 containing a simplified expression for the call's result. If 40735 IGNORE is true the value will be ignored. 40736 40737 -- Target Hook: bool TARGET_GIMPLE_FOLD_BUILTIN (gimple_stmt_iterator 40738 *GSI) 40739 Fold a call to a machine specific built-in function that was set up 40740 by 'TARGET_INIT_BUILTINS'. GSI points to the gimple statement 40741 holding the function call. Returns true if any change was made to 40742 the GIMPLE stream. 40743 40744 -- Target Hook: int TARGET_COMPARE_VERSION_PRIORITY (tree DECL1, tree 40745 DECL2) 40746 This hook is used to compare the target attributes in two functions 40747 to determine which function's features get higher priority. This 40748 is used during function multi-versioning to figure out the order in 40749 which two versions must be dispatched. A function version with a 40750 higher priority is checked for dispatching earlier. DECL1 and 40751 DECL2 are the two function decls that will be compared. 40752 40753 -- Target Hook: tree TARGET_GET_FUNCTION_VERSIONS_DISPATCHER (void 40754 *DECL) 40755 This hook is used to get the dispatcher function for a set of 40756 function versions. The dispatcher function is called to invoke the 40757 right function version at run-time. DECL is one version from a set 40758 of semantically identical versions. 40759 40760 -- Target Hook: tree TARGET_GENERATE_VERSION_DISPATCHER_BODY (void 40761 *ARG) 40762 This hook is used to generate the dispatcher logic to invoke the 40763 right function version at run-time for a given set of function 40764 versions. ARG points to the callgraph node of the dispatcher 40765 function whose body must be generated. 40766 40767 -- Target Hook: bool TARGET_CAN_USE_DOLOOP_P (const widest_int 40768 &ITERATIONS, const widest_int &ITERATIONS_MAX, unsigned int 40769 LOOP_DEPTH, bool ENTERED_AT_TOP) 40770 Return true if it is possible to use low-overhead loops 40771 ('doloop_end' and 'doloop_begin') for a particular loop. 40772 ITERATIONS gives the exact number of iterations, or 0 if not known. 40773 ITERATIONS_MAX gives the maximum number of iterations, or 0 if not 40774 known. LOOP_DEPTH is the nesting depth of the loop, with 1 for 40775 innermost loops, 2 for loops that contain innermost loops, and so 40776 on. ENTERED_AT_TOP is true if the loop is only entered from the 40777 top. 40778 40779 This hook is only used if 'doloop_end' is available. The default 40780 implementation returns true. You can use 40781 'can_use_doloop_if_innermost' if the loop must be the innermost, 40782 and if there are no other restrictions. 40783 40784 -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (const 40785 rtx_insn *INSN) 40786 40787 Take an instruction in INSN and return NULL if it is valid within a 40788 low-overhead loop, otherwise return a string explaining why doloop 40789 could not be applied. 40790 40791 Many targets use special registers for low-overhead looping. For 40792 any instruction that clobbers these this function should return a 40793 string indicating the reason why the doloop could not be applied. 40794 By default, the RTL loop optimizer does not use a present doloop 40795 pattern for loops containing function calls or branch on table 40796 instructions. 40797 40798 -- Target Hook: bool TARGET_LEGITIMATE_COMBINED_INSN (rtx_insn *INSN) 40799 Take an instruction in INSN and return 'false' if the instruction 40800 is not appropriate as a combination of two or more instructions. 40801 The default is to accept all instructions. 40802 40803 -- Target Hook: bool TARGET_CAN_FOLLOW_JUMP (const rtx_insn *FOLLOWER, 40804 const rtx_insn *FOLLOWEE) 40805 FOLLOWER and FOLLOWEE are JUMP_INSN instructions; return true if 40806 FOLLOWER may be modified to follow FOLLOWEE; false, if it can't. 40807 For example, on some targets, certain kinds of branches can't be 40808 made to follow through a hot/cold partitioning. 40809 40810 -- Target Hook: bool TARGET_COMMUTATIVE_P (const_rtx X, int OUTER_CODE) 40811 This target hook returns 'true' if X is considered to be 40812 commutative. Usually, this is just COMMUTATIVE_P (X), but the HP 40813 PA doesn't consider PLUS to be commutative inside a MEM. 40814 OUTER_CODE is the rtx code of the enclosing rtl, if known, 40815 otherwise it is UNKNOWN. 40816 40817 -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG) 40818 40819 When the initial value of a hard register has been copied in a 40820 pseudo register, it is often not necessary to actually allocate 40821 another register to this pseudo register, because the original hard 40822 register or a stack slot it has been saved into can be used. 40823 'TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register 40824 allocation once for each hard register that had its initial value 40825 copied by using 'get_func_hard_reg_initial_val' or 40826 'get_hard_reg_initial_val'. Possible values are 'NULL_RTX', if you 40827 don't want to do any special allocation, a 'REG' rtx--that would 40828 typically be the hard register itself, if it is known not to be 40829 clobbered--or a 'MEM'. If you are returning a 'MEM', this is only 40830 a hint for the allocator; it might decide to use another register 40831 anyways. You may use 'current_function_is_leaf' or 'REG_N_SETS' in 40832 the hook to determine if the hard register in question will not be 40833 clobbered. The default value of this hook is 'NULL', which 40834 disables any special allocation. 40835 40836 -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned 40837 FLAGS) 40838 This target hook returns nonzero if X, an 'unspec' or 40839 'unspec_volatile' operation, might cause a trap. Targets can use 40840 this hook to enhance precision of analysis for 'unspec' and 40841 'unspec_volatile' operations. You may call 'may_trap_p_1' to 40842 analyze inner elements of X in which case FLAGS should be passed 40843 along. 40844 40845 -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL) 40846 The compiler invokes this hook whenever it changes its current 40847 function context ('cfun'). You can define this function if the 40848 back end needs to perform any initialization or reset actions on a 40849 per-function basis. For example, it may be used to implement 40850 function attributes that affect register usage or code generation 40851 patterns. The argument DECL is the declaration for the new 40852 function context, and may be null to indicate that the compiler has 40853 left a function context and is returning to processing at the top 40854 level. The default hook function does nothing. 40855 40856 GCC sets 'cfun' to a dummy function context during initialization 40857 of some parts of the back end. The hook function is not invoked in 40858 this situation; you need not worry about the hook being invoked 40859 recursively, or when the back end is in a partially-initialized 40860 state. 'cfun' might be 'NULL' to indicate processing at top level, 40861 outside of any function scope. 40862 40863 -- Macro: TARGET_OBJECT_SUFFIX 40864 Define this macro to be a C string representing the suffix for 40865 object files on your target machine. If you do not define this 40866 macro, GCC will use '.o' as the suffix for object files. 40867 40868 -- Macro: TARGET_EXECUTABLE_SUFFIX 40869 Define this macro to be a C string representing the suffix to be 40870 automatically added to executable files on your target machine. If 40871 you do not define this macro, GCC will use the null string as the 40872 suffix for executable files. 40873 40874 -- Macro: COLLECT_EXPORT_LIST 40875 If defined, 'collect2' will scan the individual object files 40876 specified on its command line and create an export list for the 40877 linker. Define this macro for systems like AIX, where the linker 40878 discards object files that are not referenced from 'main' and uses 40879 export lists. 40880 40881 -- Macro: MODIFY_JNI_METHOD_CALL (MDECL) 40882 Define this macro to a C expression representing a variant of the 40883 method call MDECL, if Java Native Interface (JNI) methods must be 40884 invoked differently from other methods on your target. For 40885 example, on 32-bit Microsoft Windows, JNI methods must be invoked 40886 using the 'stdcall' calling convention and this macro is then 40887 defined as this expression: 40888 40889 build_type_attribute_variant (MDECL, 40890 build_tree_list 40891 (get_identifier ("stdcall"), 40892 NULL)) 40893 40894 -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void) 40895 This target hook returns 'true' past the point in which new jump 40896 instructions could be created. On machines that require a register 40897 for every jump such as the SHmedia ISA of SH5, this point would 40898 typically be reload, so this target hook should be defined to a 40899 function such as: 40900 40901 static bool 40902 cannot_modify_jumps_past_reload_p () 40903 { 40904 return (reload_completed || reload_in_progress); 40905 } 40906 40907 -- Target Hook: reg_class_t TARGET_BRANCH_TARGET_REGISTER_CLASS (void) 40908 This target hook returns a register class for which branch target 40909 register optimizations should be applied. All registers in this 40910 class should be usable interchangeably. After reload, registers in 40911 this class will be re-allocated and loads will be hoisted out of 40912 loops and be subjected to inter-block scheduling. 40913 40914 -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool 40915 AFTER_PROLOGUE_EPILOGUE_GEN) 40916 Branch target register optimization will by default exclude 40917 callee-saved registers that are not already live during the current 40918 function; if this target hook returns true, they will be included. 40919 The target code must than make sure that all target registers in 40920 the class returned by 'TARGET_BRANCH_TARGET_REGISTER_CLASS' that 40921 might need saving are saved. AFTER_PROLOGUE_EPILOGUE_GEN indicates 40922 if prologues and epilogues have already been generated. Note, even 40923 if you only return true when AFTER_PROLOGUE_EPILOGUE_GEN is false, 40924 you still are likely to have to make special provisions in 40925 'INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved 40926 target registers. 40927 40928 -- Target Hook: bool TARGET_HAVE_CONDITIONAL_EXECUTION (void) 40929 This target hook returns true if the target supports conditional 40930 execution. This target hook is required only when the target has 40931 several different modes and they have different conditional 40932 execution capability, such as ARM. 40933 40934 -- Target Hook: rtx TARGET_GEN_CCMP_FIRST (rtx_insn **PREP_SEQ, 40935 rtx_insn **GEN_SEQ, int CODE, tree OP0, tree OP1) 40936 This function prepares to emit a comparison insn for the first 40937 compare in a sequence of conditional comparisions. It returns an 40938 appropriate comparison with 'CC' for passing to 'gen_ccmp_next' or 40939 'cbranch_optab'. The insns to prepare the compare are saved in 40940 PREP_SEQ and the compare insns are saved in GEN_SEQ. They will be 40941 emitted when all the compares in the the conditional comparision 40942 are generated without error. CODE is the 'rtx_code' of the compare 40943 for OP0 and OP1. 40944 40945 -- Target Hook: rtx TARGET_GEN_CCMP_NEXT (rtx_insn **PREP_SEQ, rtx_insn 40946 **GEN_SEQ, rtx PREV, int CMP_CODE, tree OP0, tree OP1, int 40947 BIT_CODE) 40948 This function prepares to emit a conditional comparison within a 40949 sequence of conditional comparisons. It returns an appropriate 40950 comparison with 'CC' for passing to 'gen_ccmp_next' or 40951 'cbranch_optab'. The insns to prepare the compare are saved in 40952 PREP_SEQ and the compare insns are saved in GEN_SEQ. They will be 40953 emitted when all the compares in the conditional comparision are 40954 generated without error. The PREV expression is the result of a 40955 prior call to 'gen_ccmp_first' or 'gen_ccmp_next'. It may return 40956 'NULL' if the combination of PREV and this comparison is not 40957 supported, otherwise the result must be appropriate for passing to 40958 'gen_ccmp_next' or 'cbranch_optab'. CODE is the 'rtx_code' of the 40959 compare for OP0 and OP1. BIT_CODE is 'AND' or 'IOR', which is the 40960 op on the compares. 40961 40962 -- Target Hook: unsigned TARGET_LOOP_UNROLL_ADJUST (unsigned NUNROLL, 40963 struct loop *LOOP) 40964 This target hook returns a new value for the number of times LOOP 40965 should be unrolled. The parameter NUNROLL is the number of times 40966 the loop is to be unrolled. The parameter LOOP is a pointer to the 40967 loop, which is going to be checked for unrolling. This target hook 40968 is required only when the target has special constraints like 40969 maximum number of memory accesses. 40970 40971 -- Macro: POWI_MAX_MULTS 40972 If defined, this macro is interpreted as a signed integer C 40973 expression that specifies the maximum number of floating point 40974 multiplications that should be emitted when expanding 40975 exponentiation by an integer constant inline. When this value is 40976 defined, exponentiation requiring more than this number of 40977 multiplications is implemented by calling the system library's 40978 'pow', 'powf' or 'powl' routines. The default value places no 40979 upper bound on the multiplication count. 40980 40981 -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char 40982 *IPREFIX, int STDINC) 40983 This target hook should register any extra include files for the 40984 target. The parameter STDINC indicates if normal include files are 40985 present. The parameter SYSROOT is the system root directory. The 40986 parameter IPREFIX is the prefix for the gcc directory. 40987 40988 -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const 40989 char *IPREFIX, int STDINC) 40990 This target hook should register any extra include files for the 40991 target before any standard headers. The parameter STDINC indicates 40992 if normal include files are present. The parameter SYSROOT is the 40993 system root directory. The parameter IPREFIX is the prefix for the 40994 gcc directory. 40995 40996 -- Macro: void TARGET_OPTF (char *PATH) 40997 This target hook should register special include paths for the 40998 target. The parameter PATH is the include to register. On Darwin 40999 systems, this is used for Framework includes, which have semantics 41000 that are different from '-I'. 41001 41002 -- Macro: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL) 41003 This target macro returns 'true' if it is safe to use a local alias 41004 for a virtual function FNDECL when constructing thunks, 'false' 41005 otherwise. By default, the macro returns 'true' for all functions, 41006 if a target supports aliases (i.e. defines 'ASM_OUTPUT_DEF'), 41007 'false' otherwise, 41008 41009 -- Macro: TARGET_FORMAT_TYPES 41010 If defined, this macro is the name of a global variable containing 41011 target-specific format checking information for the '-Wformat' 41012 option. The default is to have no target-specific format checks. 41013 41014 -- Macro: TARGET_N_FORMAT_TYPES 41015 If defined, this macro is the number of entries in 41016 'TARGET_FORMAT_TYPES'. 41017 41018 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES 41019 If defined, this macro is the name of a global variable containing 41020 target-specific format overrides for the '-Wformat' option. The 41021 default is to have no target-specific format overrides. If 41022 defined, 'TARGET_FORMAT_TYPES' must be defined, too. 41023 41024 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT 41025 If defined, this macro specifies the number of entries in 41026 'TARGET_OVERRIDES_FORMAT_ATTRIBUTES'. 41027 41028 -- Macro: TARGET_OVERRIDES_FORMAT_INIT 41029 If defined, this macro specifies the optional initialization 41030 routine for target specific customizations of the system printf and 41031 scanf formatter settings. 41032 41033 -- Target Hook: const char * TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN 41034 (const_tree TYPELIST, const_tree FUNCDECL, const_tree VAL) 41035 If defined, this macro returns the diagnostic message when it is 41036 illegal to pass argument VAL to function FUNCDECL with prototype 41037 TYPELIST. 41038 41039 -- Target Hook: const char * TARGET_INVALID_CONVERSION (const_tree 41040 FROMTYPE, const_tree TOTYPE) 41041 If defined, this macro returns the diagnostic message when it is 41042 invalid to convert from FROMTYPE to TOTYPE, or 'NULL' if validity 41043 should be determined by the front end. 41044 41045 -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP, 41046 const_tree TYPE) 41047 If defined, this macro returns the diagnostic message when it is 41048 invalid to apply operation OP (where unary plus is denoted by 41049 'CONVERT_EXPR') to an operand of type TYPE, or 'NULL' if validity 41050 should be determined by the front end. 41051 41052 -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP, 41053 const_tree TYPE1, const_tree TYPE2) 41054 If defined, this macro returns the diagnostic message when it is 41055 invalid to apply operation OP to operands of types TYPE1 and TYPE2, 41056 or 'NULL' if validity should be determined by the front end. 41057 41058 -- Target Hook: tree TARGET_PROMOTED_TYPE (const_tree TYPE) 41059 If defined, this target hook returns the type to which values of 41060 TYPE should be promoted when they appear in expressions, analogous 41061 to the integer promotions, or 'NULL_TREE' to use the front end's 41062 normal promotion rules. This hook is useful when there are 41063 target-specific types with special promotion rules. This is 41064 currently used only by the C and C++ front ends. 41065 41066 -- Target Hook: tree TARGET_CONVERT_TO_TYPE (tree TYPE, tree EXPR) 41067 If defined, this hook returns the result of converting EXPR to 41068 TYPE. It should return the converted expression, or 'NULL_TREE' to 41069 apply the front end's normal conversion rules. This hook is useful 41070 when there are target-specific types with special conversion rules. 41071 This is currently used only by the C and C++ front ends. 41072 41073 -- Macro: OBJC_JBLEN 41074 This macro determines the size of the objective C jump buffer for 41075 the NeXT runtime. By default, OBJC_JBLEN is defined to an 41076 innocuous value. 41077 41078 -- Macro: LIBGCC2_UNWIND_ATTRIBUTE 41079 Define this macro if any target-specific attributes need to be 41080 attached to the functions in 'libgcc' that provide low-level 41081 support for call stack unwinding. It is used in declarations in 41082 'unwind-generic.h' and the associated definitions of those 41083 functions. 41084 41085 -- Target Hook: void TARGET_UPDATE_STACK_BOUNDARY (void) 41086 Define this macro to update the current function stack boundary if 41087 necessary. 41088 41089 -- Target Hook: rtx TARGET_GET_DRAP_RTX (void) 41090 This hook should return an rtx for Dynamic Realign Argument Pointer 41091 (DRAP) if a different argument pointer register is needed to access 41092 the function's argument list due to stack realignment. Return 41093 'NULL' if no DRAP is needed. 41094 41095 -- Target Hook: bool TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS (void) 41096 When optimization is disabled, this hook indicates whether or not 41097 arguments should be allocated to stack slots. Normally, GCC 41098 allocates stacks slots for arguments when not optimizing in order 41099 to make debugging easier. However, when a function is declared 41100 with '__attribute__((naked))', there is no stack frame, and the 41101 compiler cannot safely move arguments from the registers in which 41102 they are passed to the stack. Therefore, this hook should return 41103 true in general, but false for naked functions. The default 41104 implementation always returns true. 41105 41106 -- Target Hook: unsigned HOST_WIDE_INT TARGET_CONST_ANCHOR 41107 On some architectures it can take multiple instructions to 41108 synthesize a constant. If there is another constant already in a 41109 register that is close enough in value then it is preferable that 41110 the new constant is computed from this register using immediate 41111 addition or subtraction. We accomplish this through CSE. Besides 41112 the value of the constant we also add a lower and an upper constant 41113 anchor to the available expressions. These are then queried when 41114 encountering new constants. The anchors are computed by rounding 41115 the constant up and down to a multiple of the value of 41116 'TARGET_CONST_ANCHOR'. 'TARGET_CONST_ANCHOR' should be the maximum 41117 positive value accepted by immediate-add plus one. We currently 41118 assume that the value of 'TARGET_CONST_ANCHOR' is a power of 2. 41119 For example, on MIPS, where add-immediate takes a 16-bit signed 41120 value, 'TARGET_CONST_ANCHOR' is set to '0x8000'. The default value 41121 is zero, which disables this optimization. 41122 41123 -- Target Hook: unsigned HOST_WIDE_INT TARGET_ASAN_SHADOW_OFFSET (void) 41124 Return the offset bitwise ored into shifted address to get 41125 corresponding Address Sanitizer shadow memory address. NULL if 41126 Address Sanitizer is not supported by the target. 41127 41128 -- Target Hook: unsigned HOST_WIDE_INT TARGET_MEMMODEL_CHECK (unsigned 41129 HOST_WIDE_INT VAL) 41130 Validate target specific memory model mask bits. When NULL no 41131 target specific memory model bits are allowed. 41132 41133 -- Target Hook: unsigned char TARGET_ATOMIC_TEST_AND_SET_TRUEVAL 41134 This value should be set if the result written by 41135 'atomic_test_and_set' is not exactly 1, i.e. the 'bool' 'true'. 41136 41137 -- Target Hook: bool TARGET_HAS_IFUNC_P (void) 41138 It returns true if the target supports GNU indirect functions. The 41139 support includes the assembler, linker and dynamic linker. The 41140 default value of this hook is based on target's libc. 41141 41142 -- Target Hook: unsigned int TARGET_ATOMIC_ALIGN_FOR_MODE (machine_mode 41143 MODE) 41144 If defined, this function returns an appropriate alignment in bits 41145 for an atomic object of machine_mode MODE. If 0 is returned then 41146 the default alignment for the specified mode is used. 41147 41148 -- Target Hook: void TARGET_ATOMIC_ASSIGN_EXPAND_FENV (tree *HOLD, tree 41149 *CLEAR, tree *UPDATE) 41150 ISO C11 requires atomic compound assignments that may raise 41151 floating-point exceptions to raise exceptions corresponding to the 41152 arithmetic operation whose result was successfully stored in a 41153 compare-and-exchange sequence. This requires code equivalent to 41154 calls to 'feholdexcept', 'feclearexcept' and 'feupdateenv' to be 41155 generated at appropriate points in the compare-and-exchange 41156 sequence. This hook should set '*HOLD' to an expression equivalent 41157 to the call to 'feholdexcept', '*CLEAR' to an expression equivalent 41158 to the call to 'feclearexcept' and '*UPDATE' to an expression 41159 equivalent to the call to 'feupdateenv'. The three expressions are 41160 'NULL_TREE' on entry to the hook and may be left as 'NULL_TREE' if 41161 no code is required in a particular place. The default 41162 implementation leaves all three expressions as 'NULL_TREE'. The 41163 '__atomic_feraiseexcept' function from 'libatomic' may be of use as 41164 part of the code generated in '*UPDATE'. 41165 41166 -- Target Hook: void TARGET_RECORD_OFFLOAD_SYMBOL (tree) 41167 Used when offloaded functions are seen in the compilation unit and 41168 no named sections are available. It is called once for each symbol 41169 that must be recorded in the offload function and variable table. 41170 41171 -- Target Hook: char * TARGET_OFFLOAD_OPTIONS (void) 41172 Used when writing out the list of options into an LTO file. It 41173 should translate any relevant target-specific options (such as the 41174 ABI in use) into one of the '-foffload' options that exist as a 41175 common interface to express such options. It should return a 41176 string containing these options, separated by spaces, which the 41177 caller will free. 41178 41179 -- Macro: TARGET_SUPPORTS_WIDE_INT 41180 41181 On older ports, large integers are stored in 'CONST_DOUBLE' rtl 41182 objects. Newer ports define 'TARGET_SUPPORTS_WIDE_INT' to be 41183 nonzero to indicate that large integers are stored in 41184 'CONST_WIDE_INT' rtl objects. The 'CONST_WIDE_INT' allows very 41185 large integer constants to be represented. 'CONST_DOUBLE' is 41186 limited to twice the size of the host's 'HOST_WIDE_INT' 41187 representation. 41188 41189 Converting a port mostly requires looking for the places where 41190 'CONST_DOUBLE's are used with 'VOIDmode' and replacing that code 41191 with code that accesses 'CONST_WIDE_INT's. '"grep -i 41192 const_double"' at the port level gets you to 95% of the changes 41193 that need to be made. There are a few places that require a deeper 41194 look. 41195 41196 * There is no equivalent to 'hval' and 'lval' for 41197 'CONST_WIDE_INT's. This would be difficult to express in the 41198 md language since there are a variable number of elements. 41199 41200 Most ports only check that 'hval' is either 0 or -1 to see if 41201 the value is small. As mentioned above, this will no longer 41202 be necessary since small constants are always 'CONST_INT'. Of 41203 course there are still a few exceptions, the alpha's 41204 constraint used by the zap instruction certainly requires 41205 careful examination by C code. However, all the current code 41206 does is pass the hval and lval to C code, so evolving the c 41207 code to look at the 'CONST_WIDE_INT' is not really a large 41208 change. 41209 41210 * Because there is no standard template that ports use to 41211 materialize constants, there is likely to be some futzing that 41212 is unique to each port in this code. 41213 41214 * The rtx costs may have to be adjusted to properly account for 41215 larger constants that are represented as 'CONST_WIDE_INT'. 41216 41217 All and all it does not take long to convert ports that the 41218 maintainer is familiar with. 41219 41220 -- Target Hook: void TARGET_RUN_TARGET_SELFTESTS (void) 41221 If selftests are enabled, run any selftests for this target. 41222 41223 41224File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top 41225 4122619 Host Configuration 41227********************* 41228 41229Most details about the machine and system on which the compiler is 41230actually running are detected by the 'configure' script. Some things 41231are impossible for 'configure' to detect; these are described in two 41232ways, either by macros defined in a file named 'xm-MACHINE.h' or by hook 41233functions in the file specified by the OUT_HOST_HOOK_OBJ variable in 41234'config.gcc'. (The intention is that very few hosts will need a header 41235file but nearly every fully supported host will need to override some 41236hooks.) 41237 41238 If you need to define only a few macros, and they have simple 41239definitions, consider using the 'xm_defines' variable in your 41240'config.gcc' entry instead of creating a host configuration header. 41241*Note System Config::. 41242 41243* Menu: 41244 41245* Host Common:: Things every host probably needs implemented. 41246* Filesystem:: Your host cannot have the letter 'a' in filenames? 41247* Host Misc:: Rare configuration options for hosts. 41248 41249 41250File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config 41251 4125219.1 Host Common 41253================ 41254 41255Some things are just not portable, even between similar operating 41256systems, and are too difficult for autoconf to detect. They get 41257implemented using hook functions in the file specified by the 41258HOST_HOOK_OBJ variable in 'config.gcc'. 41259 41260 -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void) 41261 This host hook is used to set up handling for extra signals. The 41262 most common thing to do in this hook is to detect stack overflow. 41263 41264 -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int 41265 FD) 41266 This host hook returns the address of some space that is likely to 41267 be free in some subsequent invocation of the compiler. We intend 41268 to load the PCH data at this address such that the data need not be 41269 relocated. The area should be able to hold SIZE bytes. If the 41270 host uses 'mmap', FD is an open file descriptor that can be used 41271 for probing. 41272 41273 -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS, size_t 41274 SIZE, int FD, size_t OFFSET) 41275 This host hook is called when a PCH file is about to be loaded. We 41276 want to load SIZE bytes from FD at OFFSET into memory at ADDRESS. 41277 The given address will be the result of a previous invocation of 41278 'HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we couldn't allocate 41279 SIZE bytes at ADDRESS. Return 0 if the memory is allocated but the 41280 data is not loaded. Return 1 if the hook has performed everything. 41281 41282 If the implementation uses reserved address space, free any 41283 reserved space beyond SIZE, regardless of the return value. If no 41284 PCH will be loaded, this hook may be called with SIZE zero, in 41285 which case all reserved address space should be freed. 41286 41287 Do not try to handle values of ADDRESS that could not have been 41288 returned by this executable; just return -1. Such values usually 41289 indicate an out-of-date PCH file (built by some other GCC 41290 executable), and such a PCH file won't work. 41291 41292 -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void); 41293 This host hook returns the alignment required for allocating 41294 virtual memory. Usually this is the same as getpagesize, but on 41295 some hosts the alignment for reserving memory differs from the 41296 pagesize for committing memory. 41297 41298 41299File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config 41300 4130119.2 Host Filesystem 41302==================== 41303 41304GCC needs to know a number of things about the semantics of the host 41305machine's filesystem. Filesystems with Unix and MS-DOS semantics are 41306automatically detected. For other systems, you can define the following 41307macros in 'xm-MACHINE.h'. 41308 41309'HAVE_DOS_BASED_FILE_SYSTEM' 41310 This macro is automatically defined by 'system.h' if the host file 41311 system obeys the semantics defined by MS-DOS instead of Unix. DOS 41312 file systems are case insensitive, file specifications may begin 41313 with a drive letter, and both forward slash and backslash ('/' and 41314 '\') are directory separators. 41315 41316'DIR_SEPARATOR' 41317'DIR_SEPARATOR_2' 41318 If defined, these macros expand to character constants specifying 41319 separators for directory names within a file specification. 41320 'system.h' will automatically give them appropriate values on Unix 41321 and MS-DOS file systems. If your file system is neither of these, 41322 define one or both appropriately in 'xm-MACHINE.h'. 41323 41324 However, operating systems like VMS, where constructing a pathname 41325 is more complicated than just stringing together directory names 41326 separated by a special character, should not define either of these 41327 macros. 41328 41329'PATH_SEPARATOR' 41330 If defined, this macro should expand to a character constant 41331 specifying the separator for elements of search paths. The default 41332 value is a colon (':'). DOS-based systems usually, but not always, 41333 use semicolon (';'). 41334 41335'VMS' 41336 Define this macro if the host system is VMS. 41337 41338'HOST_OBJECT_SUFFIX' 41339 Define this macro to be a C string representing the suffix for 41340 object files on your host machine. If you do not define this 41341 macro, GCC will use '.o' as the suffix for object files. 41342 41343'HOST_EXECUTABLE_SUFFIX' 41344 Define this macro to be a C string representing the suffix for 41345 executable files on your host machine. If you do not define this 41346 macro, GCC will use the null string as the suffix for executable 41347 files. 41348 41349'HOST_BIT_BUCKET' 41350 A pathname defined by the host operating system, which can be 41351 opened as a file and written to, but all the information written is 41352 discarded. This is commonly known as a "bit bucket" or "null 41353 device". If you do not define this macro, GCC will use '/dev/null' 41354 as the bit bucket. If the host does not support a bit bucket, 41355 define this macro to an invalid filename. 41356 41357'UPDATE_PATH_HOST_CANONICALIZE (PATH)' 41358 If defined, a C statement (sans semicolon) that performs 41359 host-dependent canonicalization when a path used in a compilation 41360 driver or preprocessor is canonicalized. PATH is a malloc-ed path 41361 to be canonicalized. If the C statement does canonicalize PATH 41362 into a different buffer, the old path should be freed and the new 41363 buffer should have been allocated with malloc. 41364 41365'DUMPFILE_FORMAT' 41366 Define this macro to be a C string representing the format to use 41367 for constructing the index part of debugging dump file names. The 41368 resultant string must fit in fifteen bytes. The full filename will 41369 be the concatenation of: the prefix of the assembler file name, the 41370 string resulting from applying this format to an index number, and 41371 a string unique to each dump file kind, e.g. 'rtl'. 41372 41373 If you do not define this macro, GCC will use '.%02d.'. You should 41374 define this macro if using the default will create an invalid file 41375 name. 41376 41377'DELETE_IF_ORDINARY' 41378 Define this macro to be a C statement (sans semicolon) that 41379 performs host-dependent removal of ordinary temp files in the 41380 compilation driver. 41381 41382 If you do not define this macro, GCC will use the default version. 41383 You should define this macro if the default version does not 41384 reliably remove the temp file as, for example, on VMS which allows 41385 multiple versions of a file. 41386 41387'HOST_LACKS_INODE_NUMBERS' 41388 Define this macro if the host filesystem does not report meaningful 41389 inode numbers in struct stat. 41390 41391 41392File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config 41393 4139419.3 Host Misc 41395============== 41396 41397'FATAL_EXIT_CODE' 41398 A C expression for the status code to be returned when the compiler 41399 exits after serious errors. The default is the system-provided 41400 macro 'EXIT_FAILURE', or '1' if the system doesn't define that 41401 macro. Define this macro only if these defaults are incorrect. 41402 41403'SUCCESS_EXIT_CODE' 41404 A C expression for the status code to be returned when the compiler 41405 exits without serious errors. (Warnings are not serious errors.) 41406 The default is the system-provided macro 'EXIT_SUCCESS', or '0' if 41407 the system doesn't define that macro. Define this macro only if 41408 these defaults are incorrect. 41409 41410'USE_C_ALLOCA' 41411 Define this macro if GCC should use the C implementation of 41412 'alloca' provided by 'libiberty.a'. This only affects how some 41413 parts of the compiler itself allocate memory. It does not change 41414 code generation. 41415 41416 When GCC is built with a compiler other than itself, the C 'alloca' 41417 is always used. This is because most other implementations have 41418 serious bugs. You should define this macro only on a system where 41419 no stack-based 'alloca' can possibly work. For instance, if a 41420 system has a small limit on the size of the stack, GCC's builtin 41421 'alloca' will not work reliably. 41422 41423'COLLECT2_HOST_INITIALIZATION' 41424 If defined, a C statement (sans semicolon) that performs 41425 host-dependent initialization when 'collect2' is being initialized. 41426 41427'GCC_DRIVER_HOST_INITIALIZATION' 41428 If defined, a C statement (sans semicolon) that performs 41429 host-dependent initialization when a compilation driver is being 41430 initialized. 41431 41432'HOST_LONG_LONG_FORMAT' 41433 If defined, the string used to indicate an argument of type 'long 41434 long' to functions like 'printf'. The default value is '"ll"'. 41435 41436'HOST_LONG_FORMAT' 41437 If defined, the string used to indicate an argument of type 'long' 41438 to functions like 'printf'. The default value is '"l"'. 41439 41440'HOST_PTR_PRINTF' 41441 If defined, the string used to indicate an argument of type 'void 41442 *' to functions like 'printf'. The default value is '"%p"'. 41443 41444 In addition, if 'configure' generates an incorrect definition of any of 41445the macros in 'auto-host.h', you can override that definition in a host 41446configuration header. If you need to do this, first see if it is 41447possible to fix 'configure'. 41448 41449 41450File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top 41451 4145220 Makefile Fragments 41453********************* 41454 41455When you configure GCC using the 'configure' script, it will construct 41456the file 'Makefile' from the template file 'Makefile.in'. When it does 41457this, it can incorporate makefile fragments from the 'config' directory. 41458These are used to set Makefile parameters that are not amenable to being 41459calculated by autoconf. The list of fragments to incorporate is set by 41460'config.gcc' (and occasionally 'config.build' and 'config.host'); *Note 41461System Config::. 41462 41463 Fragments are named either 't-TARGET' or 'x-HOST', depending on whether 41464they are relevant to configuring GCC to produce code for a particular 41465target, or to configuring GCC to run on a particular host. Here TARGET 41466and HOST are mnemonics which usually have some relationship to the 41467canonical system name, but no formal connection. 41468 41469 If these files do not exist, it means nothing needs to be added for a 41470given target or host. Most targets need a few 't-TARGET' fragments, but 41471needing 'x-HOST' fragments is rare. 41472 41473* Menu: 41474 41475* Target Fragment:: Writing 't-TARGET' files. 41476* Host Fragment:: Writing 'x-HOST' files. 41477 41478 41479File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments 41480 4148120.1 Target Makefile Fragments 41482============================== 41483 41484Target makefile fragments can set these Makefile variables. 41485 41486'LIBGCC2_CFLAGS' 41487 Compiler flags to use when compiling 'libgcc2.c'. 41488 41489'LIB2FUNCS_EXTRA' 41490 A list of source file names to be compiled or assembled and 41491 inserted into 'libgcc.a'. 41492 41493'CRTSTUFF_T_CFLAGS' 41494 Special flags used when compiling 'crtstuff.c'. *Note 41495 Initialization::. 41496 41497'CRTSTUFF_T_CFLAGS_S' 41498 Special flags used when compiling 'crtstuff.c' for shared linking. 41499 Used if you use 'crtbeginS.o' and 'crtendS.o' in 'EXTRA-PARTS'. 41500 *Note Initialization::. 41501 41502'MULTILIB_OPTIONS' 41503 For some targets, invoking GCC in different ways produces objects 41504 that can not be linked together. For example, for some targets GCC 41505 produces both big and little endian code. For these targets, you 41506 must arrange for multiple versions of 'libgcc.a' to be compiled, 41507 one for each set of incompatible options. When GCC invokes the 41508 linker, it arranges to link in the right version of 'libgcc.a', 41509 based on the command line options used. 41510 41511 The 'MULTILIB_OPTIONS' macro lists the set of options for which 41512 special versions of 'libgcc.a' must be built. Write options that 41513 are mutually incompatible side by side, separated by a slash. 41514 Write options that may be used together separated by a space. The 41515 build procedure will build all combinations of compatible options. 41516 41517 For example, if you set 'MULTILIB_OPTIONS' to 'm68000/m68020 41518 msoft-float', 'Makefile' will build special versions of 'libgcc.a' 41519 using the following sets of options: '-m68000', '-m68020', 41520 '-msoft-float', '-m68000 -msoft-float', and '-m68020 -msoft-float'. 41521 41522'MULTILIB_DIRNAMES' 41523 If 'MULTILIB_OPTIONS' is used, this variable specifies the 41524 directory names that should be used to hold the various libraries. 41525 Write one element in 'MULTILIB_DIRNAMES' for each element in 41526 'MULTILIB_OPTIONS'. If 'MULTILIB_DIRNAMES' is not used, the 41527 default value will be 'MULTILIB_OPTIONS', with all slashes treated 41528 as spaces. 41529 41530 'MULTILIB_DIRNAMES' describes the multilib directories using GCC 41531 conventions and is applied to directories that are part of the GCC 41532 installation. When multilib-enabled, the compiler will add a 41533 subdirectory of the form PREFIX/MULTILIB before each directory in 41534 the search path for libraries and crt files. 41535 41536 For example, if 'MULTILIB_OPTIONS' is set to 'm68000/m68020 41537 msoft-float', then the default value of 'MULTILIB_DIRNAMES' is 41538 'm68000 m68020 msoft-float'. You may specify a different value if 41539 you desire a different set of directory names. 41540 41541'MULTILIB_MATCHES' 41542 Sometimes the same option may be written in two different ways. If 41543 an option is listed in 'MULTILIB_OPTIONS', GCC needs to know about 41544 any synonyms. In that case, set 'MULTILIB_MATCHES' to a list of 41545 items of the form 'option=option' to describe all relevant 41546 synonyms. For example, 'm68000=mc68000 m68020=mc68020'. 41547 41548'MULTILIB_EXCEPTIONS' 41549 Sometimes when there are multiple sets of 'MULTILIB_OPTIONS' being 41550 specified, there are combinations that should not be built. In 41551 that case, set 'MULTILIB_EXCEPTIONS' to be all of the switch 41552 exceptions in shell case syntax that should not be built. 41553 41554 For example the ARM processor cannot execute both hardware floating 41555 point instructions and the reduced size THUMB instructions at the 41556 same time, so there is no need to build libraries with both of 41557 these options enabled. Therefore 'MULTILIB_EXCEPTIONS' is set to: 41558 *mthumb/*mhard-float* 41559 41560'MULTILIB_REQUIRED' 41561 Sometimes when there are only a few combinations are required, it 41562 would be a big effort to come up with a 'MULTILIB_EXCEPTIONS' list 41563 to cover all undesired ones. In such a case, just listing all the 41564 required combinations in 'MULTILIB_REQUIRED' would be more 41565 straightforward. 41566 41567 The way to specify the entries in 'MULTILIB_REQUIRED' is same with 41568 the way used for 'MULTILIB_EXCEPTIONS', only this time what are 41569 required will be specified. Suppose there are multiple sets of 41570 'MULTILIB_OPTIONS' and only two combinations are required, one for 41571 ARMv7-M and one for ARMv7-R with hard floating-point ABI and FPU, 41572 the 'MULTILIB_REQUIRED' can be set to: 41573 MULTILIB_REQUIRED = mthumb/march=armv7-m 41574 MULTILIB_REQUIRED += march=armv7-r/mfloat-abi=hard/mfpu=vfpv3-d16 41575 41576 The 'MULTILIB_REQUIRED' can be used together with 41577 'MULTILIB_EXCEPTIONS'. The option combinations generated from 41578 'MULTILIB_OPTIONS' will be filtered by 'MULTILIB_EXCEPTIONS' and 41579 then by 'MULTILIB_REQUIRED'. 41580 41581'MULTILIB_REUSE' 41582 Sometimes it is desirable to reuse one existing multilib for 41583 different sets of options. Such kind of reuse can minimize the 41584 number of multilib variants. And for some targets it is better to 41585 reuse an existing multilib than to fall back to default multilib 41586 when there is no corresponding multilib. This can be done by 41587 adding reuse rules to 'MULTILIB_REUSE'. 41588 41589 A reuse rule is comprised of two parts connected by equality sign. 41590 The left part is the option set used to build multilib and the 41591 right part is the option set that will reuse this multilib. Both 41592 parts should only use options specified in 'MULTILIB_OPTIONS' and 41593 the equality signs found in options name should be replaced with 41594 periods. An explicit period in the rule can be escaped by 41595 preceding it with a backslash. The order of options in the left 41596 part matters and should be same with those specified in 41597 'MULTILIB_REQUIRED' or aligned with the order in 41598 'MULTILIB_OPTIONS'. There is no such limitation for options in the 41599 right part as we don't build multilib from them. 41600 41601 'MULTILIB_REUSE' is different from 'MULTILIB_MATCHES' in that it 41602 sets up relations between two option sets rather than two options. 41603 Here is an example to demo how we reuse libraries built in Thumb 41604 mode for applications built in ARM mode: 41605 MULTILIB_REUSE = mthumb/march.armv7-r=marm/march.armv7-r 41606 41607 Before the advent of 'MULTILIB_REUSE', GCC select multilib by 41608 comparing command line options with options used to build multilib. 41609 The 'MULTILIB_REUSE' is complementary to that way. Only when the 41610 original comparison matches nothing it will work to see if it is OK 41611 to reuse some existing multilib. 41612 41613'MULTILIB_EXTRA_OPTS' 41614 Sometimes it is desirable that when building multiple versions of 41615 'libgcc.a' certain options should always be passed on to the 41616 compiler. In that case, set 'MULTILIB_EXTRA_OPTS' to be the list 41617 of options to be used for all builds. If you set this, you should 41618 probably set 'CRTSTUFF_T_CFLAGS' to a dash followed by it. 41619 41620'MULTILIB_OSDIRNAMES' 41621 If 'MULTILIB_OPTIONS' is used, this variable specifies a list of 41622 subdirectory names, that are used to modify the search path 41623 depending on the chosen multilib. Unlike 'MULTILIB_DIRNAMES', 41624 'MULTILIB_OSDIRNAMES' describes the multilib directories using 41625 operating systems conventions, and is applied to the directories 41626 such as 'lib' or those in the 'LIBRARY_PATH' environment variable. 41627 The format is either the same as of 'MULTILIB_DIRNAMES', or a set 41628 of mappings. When it is the same as 'MULTILIB_DIRNAMES', it 41629 describes the multilib directories using operating system 41630 conventions, rather than GCC conventions. When it is a set of 41631 mappings of the form GCCDIR=OSDIR, the left side gives the GCC 41632 convention and the right gives the equivalent OS defined location. 41633 If the OSDIR part begins with a '!', GCC will not search in the 41634 non-multilib directory and use exclusively the multilib directory. 41635 Otherwise, the compiler will examine the search path for libraries 41636 and crt files twice; the first time it will add MULTILIB to each 41637 directory in the search path, the second it will not. 41638 41639 For configurations that support both multilib and multiarch, 41640 'MULTILIB_OSDIRNAMES' also encodes the multiarch name, thus 41641 subsuming 'MULTIARCH_DIRNAME'. The multiarch name is appended to 41642 each directory name, separated by a colon (e.g. 41643 '../lib32:i386-linux-gnu'). 41644 41645 Each multiarch subdirectory will be searched before the 41646 corresponding OS multilib directory, for example 41647 '/lib/i386-linux-gnu' before '/lib/../lib32'. The multiarch name 41648 will also be used to modify the system header search path, as 41649 explained for 'MULTIARCH_DIRNAME'. 41650 41651'MULTIARCH_DIRNAME' 41652 This variable specifies the multiarch name for configurations that 41653 are multiarch-enabled but not multilibbed configurations. 41654 41655 The multiarch name is used to augment the search path for 41656 libraries, crt files and system header files with additional 41657 locations. The compiler will add a multiarch subdirectory of the 41658 form PREFIX/MULTIARCH before each directory in the library and crt 41659 search path. It will also add two directories 41660 'LOCAL_INCLUDE_DIR'/MULTIARCH and 41661 'NATIVE_SYSTEM_HEADER_DIR'/MULTIARCH) to the system header search 41662 path, respectively before 'LOCAL_INCLUDE_DIR' and 41663 'NATIVE_SYSTEM_HEADER_DIR'. 41664 41665 'MULTIARCH_DIRNAME' is not used for configurations that support 41666 both multilib and multiarch. In that case, multiarch names are 41667 encoded in 'MULTILIB_OSDIRNAMES' instead. 41668 41669 More documentation about multiarch can be found at 41670 <https://wiki.debian.org/Multiarch>. 41671 41672'SPECS' 41673 Unfortunately, setting 'MULTILIB_EXTRA_OPTS' is not enough, since 41674 it does not affect the build of target libraries, at least not the 41675 build of the default multilib. One possible work-around is to use 41676 'DRIVER_SELF_SPECS' to bring options from the 'specs' file as if 41677 they had been passed in the compiler driver command line. However, 41678 you don't want to be adding these options after the toolchain is 41679 installed, so you can instead tweak the 'specs' file that will be 41680 used during the toolchain build, while you still install the 41681 original, built-in 'specs'. The trick is to set 'SPECS' to some 41682 other filename (say 'specs.install'), that will then be created out 41683 of the built-in specs, and introduce a 'Makefile' rule to generate 41684 the 'specs' file that's going to be used at build time out of your 41685 'specs.install'. 41686 41687'T_CFLAGS' 41688 These are extra flags to pass to the C compiler. They are used 41689 both when building GCC, and when compiling things with the 41690 just-built GCC. This variable is deprecated and should not be 41691 used. 41692 41693 41694File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments 41695 4169620.2 Host Makefile Fragments 41697============================ 41698 41699The use of 'x-HOST' fragments is discouraged. You should only use it 41700for makefile dependencies. 41701 41702 41703File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top 41704 4170521 'collect2' 41706************* 41707 41708GCC uses a utility called 'collect2' on nearly all systems to arrange to 41709call various initialization functions at start time. 41710 41711 The program 'collect2' works by linking the program once and looking 41712through the linker output file for symbols with particular names 41713indicating they are constructor functions. If it finds any, it creates 41714a new temporary '.c' file containing a table of them, compiles it, and 41715links the program a second time including that file. 41716 41717 The actual calls to the constructors are carried out by a subroutine 41718called '__main', which is called (automatically) at the beginning of the 41719body of 'main' (provided 'main' was compiled with GNU CC). Calling 41720'__main' is necessary, even when compiling C code, to allow linking C 41721and C++ object code together. (If you use '-nostdlib', you get an 41722unresolved reference to '__main', since it's defined in the standard GCC 41723library. Include '-lgcc' at the end of your compiler command line to 41724resolve this reference.) 41725 41726 The program 'collect2' is installed as 'ld' in the directory where the 41727passes of the compiler are installed. When 'collect2' needs to find the 41728_real_ 'ld', it tries the following file names: 41729 41730 * a hard coded linker file name, if GCC was configured with the 41731 '--with-ld' option. 41732 41733 * 'real-ld' in the directories listed in the compiler's search 41734 directories. 41735 41736 * 'real-ld' in the directories listed in the environment variable 41737 'PATH'. 41738 41739 * The file specified in the 'REAL_LD_FILE_NAME' configuration macro, 41740 if specified. 41741 41742 * 'ld' in the compiler's search directories, except that 'collect2' 41743 will not execute itself recursively. 41744 41745 * 'ld' in 'PATH'. 41746 41747 "The compiler's search directories" means all the directories where 41748'gcc' searches for passes of the compiler. This includes directories 41749that you specify with '-B'. 41750 41751 Cross-compilers search a little differently: 41752 41753 * 'real-ld' in the compiler's search directories. 41754 41755 * 'TARGET-real-ld' in 'PATH'. 41756 41757 * The file specified in the 'REAL_LD_FILE_NAME' configuration macro, 41758 if specified. 41759 41760 * 'ld' in the compiler's search directories. 41761 41762 * 'TARGET-ld' in 'PATH'. 41763 41764 'collect2' explicitly avoids running 'ld' using the file name under 41765which 'collect2' itself was invoked. In fact, it remembers up a list of 41766such names--in case one copy of 'collect2' finds another copy (or 41767version) of 'collect2' installed as 'ld' in a second place in the search 41768path. 41769 41770 'collect2' searches for the utilities 'nm' and 'strip' using the same 41771algorithm as above for 'ld'. 41772 41773 41774File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top 41775 4177622 Standard Header File Directories 41777*********************************** 41778 41779'GCC_INCLUDE_DIR' means the same thing for native and cross. It is 41780where GCC stores its private include files, and also where GCC stores 41781the fixed include files. A cross compiled GCC runs 'fixincludes' on the 41782header files in '$(tooldir)/include'. (If the cross compilation header 41783files need to be fixed, they must be installed before GCC is built. If 41784the cross compilation header files are already suitable for GCC, nothing 41785special need be done). 41786 41787 'GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It 41788is where 'g++' looks first for header files. The C++ library installs 41789only target independent header files in that directory. 41790 41791 'LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't 41792install anything there. It is normally '/usr/local/include'. This is 41793where local additions to a packaged system should place header files. 41794 41795 'CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't 41796install anything there. 41797 41798 'TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is 41799the place for other packages to install header files that GCC will use. 41800For a cross-compiler, this is the equivalent of '/usr/include'. When 41801you build a cross-compiler, 'fixincludes' processes any header files in 41802this directory. 41803 41804 41805File: gccint.info, Node: Type Information, Next: Plugins, Prev: Header Dirs, Up: Top 41806 4180723 Memory Management and Type Information 41808***************************************** 41809 41810GCC uses some fairly sophisticated memory management techniques, which 41811involve determining information about GCC's data structures from GCC's 41812source code and using this information to perform garbage collection and 41813implement precompiled headers. 41814 41815 A full C++ parser would be too complicated for this task, so a limited 41816subset of C++ is interpreted and special markers are used to determine 41817what parts of the source to look at. All 'struct', 'union' and 41818'template' structure declarations that define data structures that are 41819allocated under control of the garbage collector must be marked. All 41820global variables that hold pointers to garbage-collected memory must 41821also be marked. Finally, all global variables that need to be saved and 41822restored by a precompiled header must be marked. (The precompiled 41823header mechanism can only save static variables if they're scalar. 41824Complex data structures must be allocated in garbage-collected memory to 41825be saved in a precompiled header.) 41826 41827 The full format of a marker is 41828 GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...)) 41829but in most cases no options are needed. The outer double parentheses 41830are still necessary, though: 'GTY(())'. Markers can appear: 41831 41832 * In a structure definition, before the open brace; 41833 * In a global variable declaration, after the keyword 'static' or 41834 'extern'; and 41835 * In a structure field definition, before the name of the field. 41836 41837 Here are some examples of marking simple data structures and globals. 41838 41839 struct GTY(()) TAG 41840 { 41841 FIELDS... 41842 }; 41843 41844 typedef struct GTY(()) TAG 41845 { 41846 FIELDS... 41847 } *TYPENAME; 41848 41849 static GTY(()) struct TAG *LIST; /* points to GC memory */ 41850 static GTY(()) int COUNTER; /* save counter in a PCH */ 41851 41852 The parser understands simple typedefs such as 'typedef struct TAG 41853*NAME;' and 'typedef int NAME;'. These don't need to be marked. 41854 41855 Since 'gengtype''s understanding of C++ is limited, there are several 41856constructs and declarations that are not supported inside 41857classes/structures marked for automatic GC code generation. The 41858following C++ constructs produce a 'gengtype' error on 41859structures/classes marked for automatic GC code generation: 41860 41861 * Type definitions inside classes/structures are not supported. 41862 * Enumerations inside classes/structures are not supported. 41863 41864 If you have a class or structure using any of the above constructs, you 41865need to mark that class as 'GTY ((user))' and provide your own marking 41866routines (see section *note User GC:: for details). 41867 41868 It is always valid to include function definitions inside classes. 41869Those are always ignored by 'gengtype', as it only cares about data 41870members. 41871 41872* Menu: 41873 41874* GTY Options:: What goes inside a 'GTY(())'. 41875* Inheritance and GTY:: Adding GTY to a class hierarchy. 41876* User GC:: Adding user-provided GC marking routines. 41877* GGC Roots:: Making global variables GGC roots. 41878* Files:: How the generated files work. 41879* Invoking the garbage collector:: How to invoke the garbage collector. 41880* Troubleshooting:: When something does not work as expected. 41881 41882 41883File: gccint.info, Node: GTY Options, Next: Inheritance and GTY, Up: Type Information 41884 4188523.1 The Inside of a 'GTY(())' 41886============================== 41887 41888Sometimes the C code is not enough to fully describe the type structure. 41889Extra information can be provided with 'GTY' options and additional 41890markers. Some options take a parameter, which may be either a string or 41891a type name, depending on the parameter. If an option takes no 41892parameter, it is acceptable either to omit the parameter entirely, or to 41893provide an empty string as a parameter. For example, 'GTY ((skip))' and 41894'GTY ((skip ("")))' are equivalent. 41895 41896 When the parameter is a string, often it is a fragment of C code. Four 41897special escapes may be used in these strings, to refer to pieces of the 41898data structure being marked: 41899 41900'%h' 41901 The current structure. 41902'%1' 41903 The structure that immediately contains the current structure. 41904'%0' 41905 The outermost structure that contains the current structure. 41906'%a' 41907 A partial expression of the form '[i1][i2]...' that indexes the 41908 array item currently being marked. 41909 41910 For instance, suppose that you have a structure of the form 41911 struct A { 41912 ... 41913 }; 41914 struct B { 41915 struct A foo[12]; 41916 }; 41917and 'b' is a variable of type 'struct B'. When marking 'b.foo[11]', 41918'%h' would expand to 'b.foo[11]', '%0' and '%1' would both expand to 41919'b', and '%a' would expand to '[11]'. 41920 41921 As in ordinary C, adjacent strings will be concatenated; this is 41922helpful when you have a complicated expression. 41923 GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE" 41924 " ? TYPE_NEXT_VARIANT (&%h.generic)" 41925 " : TREE_CHAIN (&%h.generic)"))) 41926 41927 The available options are: 41928 41929'length ("EXPRESSION")' 41930 41931 There are two places the type machinery will need to be explicitly 41932 told the length of an array of non-atomic objects. The first case 41933 is when a structure ends in a variable-length array, like this: 41934 struct GTY(()) rtvec_def { 41935 int num_elem; /* number of elements */ 41936 rtx GTY ((length ("%h.num_elem"))) elem[1]; 41937 }; 41938 41939 In this case, the 'length' option is used to override the specified 41940 array length (which should usually be '1'). The parameter of the 41941 option is a fragment of C code that calculates the length. 41942 41943 The second case is when a structure or a global variable contains a 41944 pointer to an array, like this: 41945 struct gimple_omp_for_iter * GTY((length ("%h.collapse"))) iter; 41946 In this case, 'iter' has been allocated by writing something like 41947 x->iter = ggc_alloc_cleared_vec_gimple_omp_for_iter (collapse); 41948 and the 'collapse' provides the length of the field. 41949 41950 This second use of 'length' also works on global variables, like: 41951 static GTY((length("reg_known_value_size"))) rtx *reg_known_value; 41952 41953 Note that the 'length' option is only meant for use with arrays of 41954 non-atomic objects, that is, objects that contain pointers pointing 41955 to other GTY-managed objects. For other GC-allocated arrays and 41956 strings you should use 'atomic'. 41957 41958'skip' 41959 41960 If 'skip' is applied to a field, the type machinery will ignore it. 41961 This is somewhat dangerous; the only safe use is in a union when 41962 one field really isn't ever used. 41963 41964'for_user' 41965 41966 Use this to mark types that need to be marked by user gc routines, 41967 but are not refered to in a template argument. So if you have some 41968 user gc type T1 and a non user gc type T2 you can give T2 the 41969 for_user option so that the marking functions for T1 can call non 41970 mangled functions to mark T2. 41971 41972'desc ("EXPRESSION")' 41973'tag ("CONSTANT")' 41974'default' 41975 41976 The type machinery needs to be told which field of a 'union' is 41977 currently active. This is done by giving each field a constant 41978 'tag' value, and then specifying a discriminator using 'desc'. The 41979 value of the expression given by 'desc' is compared against each 41980 'tag' value, each of which should be different. If no 'tag' is 41981 matched, the field marked with 'default' is used if there is one, 41982 otherwise no field in the union will be marked. 41983 41984 In the 'desc' option, the "current structure" is the union that it 41985 discriminates. Use '%1' to mean the structure containing it. 41986 There are no escapes available to the 'tag' option, since it is a 41987 constant. 41988 41989 For example, 41990 struct GTY(()) tree_binding 41991 { 41992 struct tree_common common; 41993 union tree_binding_u { 41994 tree GTY ((tag ("0"))) scope; 41995 struct cp_binding_level * GTY ((tag ("1"))) level; 41996 } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope; 41997 tree value; 41998 }; 41999 42000 In this example, the value of BINDING_HAS_LEVEL_P when applied to a 42001 'struct tree_binding *' is presumed to be 0 or 1. If 1, the type 42002 mechanism will treat the field 'level' as being present and if 0, 42003 will treat the field 'scope' as being present. 42004 42005 The 'desc' and 'tag' options can also be used for inheritance to 42006 denote which subclass an instance is. See *note Inheritance and 42007 GTY:: for more information. 42008 42009'cache' 42010 42011 When the 'cache' option is applied to a global variable 42012 gt_clear_cache is called on that variable between the mark and 42013 sweep phases of garbage collection. The gt_clear_cache function is 42014 free to mark blocks as used, or to clear pointers in the variable. 42015 42016'deletable' 42017 42018 'deletable', when applied to a global variable, indicates that when 42019 garbage collection runs, there's no need to mark anything pointed 42020 to by this variable, it can just be set to 'NULL' instead. This is 42021 used to keep a list of free structures around for re-use. 42022 42023'maybe_undef' 42024 42025 When applied to a field, 'maybe_undef' indicates that it's OK if 42026 the structure that this fields points to is never defined, so long 42027 as this field is always 'NULL'. This is used to avoid requiring 42028 backends to define certain optional structures. It doesn't work 42029 with language frontends. 42030 42031'nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")' 42032 42033 The type machinery expects all pointers to point to the start of an 42034 object. Sometimes for abstraction purposes it's convenient to have 42035 a pointer which points inside an object. So long as it's possible 42036 to convert the original object to and from the pointer, such 42037 pointers can still be used. TYPE is the type of the original 42038 object, the TO EXPRESSION returns the pointer given the original 42039 object, and the FROM EXPRESSION returns the original object given 42040 the pointer. The pointer will be available using the '%h' escape. 42041 42042'chain_next ("EXPRESSION")' 42043'chain_prev ("EXPRESSION")' 42044'chain_circular ("EXPRESSION")' 42045 42046 It's helpful for the type machinery to know if objects are often 42047 chained together in long lists; this lets it generate code that 42048 uses less stack space by iterating along the list instead of 42049 recursing down it. 'chain_next' is an expression for the next item 42050 in the list, 'chain_prev' is an expression for the previous item. 42051 For singly linked lists, use only 'chain_next'; for doubly linked 42052 lists, use both. The machinery requires that taking the next item 42053 of the previous item gives the original item. 'chain_circular' is 42054 similar to 'chain_next', but can be used for circular single linked 42055 lists. 42056 42057'reorder ("FUNCTION NAME")' 42058 42059 Some data structures depend on the relative ordering of pointers. 42060 If the precompiled header machinery needs to change that ordering, 42061 it will call the function referenced by the 'reorder' option, 42062 before changing the pointers in the object that's pointed to by the 42063 field the option applies to. The function must take four 42064 arguments, with the signature 42065 'void *, void *, gt_pointer_operator, void *'. The first parameter 42066 is a pointer to the structure that contains the object being 42067 updated, or the object itself if there is no containing structure. 42068 The second parameter is a cookie that should be ignored. The third 42069 parameter is a routine that, given a pointer, will update it to its 42070 correct new value. The fourth parameter is a cookie that must be 42071 passed to the second parameter. 42072 42073 PCH cannot handle data structures that depend on the absolute 42074 values of pointers. 'reorder' functions can be expensive. When 42075 possible, it is better to depend on properties of the data, like an 42076 ID number or the hash of a string instead. 42077 42078'atomic' 42079 42080 The 'atomic' option can only be used with pointers. It informs the 42081 GC machinery that the memory that the pointer points to does not 42082 contain any pointers, and hence it should be treated by the GC and 42083 PCH machinery as an "atomic" block of memory that does not need to 42084 be examined when scanning memory for pointers. In particular, the 42085 machinery will not scan that memory for pointers to mark them as 42086 reachable (when marking pointers for GC) or to relocate them (when 42087 writing a PCH file). 42088 42089 The 'atomic' option differs from the 'skip' option. 'atomic' keeps 42090 the memory under Garbage Collection, but makes the GC ignore the 42091 contents of the memory. 'skip' is more drastic in that it causes 42092 the pointer and the memory to be completely ignored by the Garbage 42093 Collector. So, memory marked as 'atomic' is automatically freed 42094 when no longer reachable, while memory marked as 'skip' is not. 42095 42096 The 'atomic' option must be used with great care, because all sorts 42097 of problem can occur if used incorrectly, that is, if the memory 42098 the pointer points to does actually contain a pointer. 42099 42100 Here is an example of how to use it: 42101 struct GTY(()) my_struct { 42102 int number_of_elements; 42103 unsigned int * GTY ((atomic)) elements; 42104 }; 42105 In this case, 'elements' is a pointer under GC, and the memory it 42106 points to needs to be allocated using the Garbage Collector, and 42107 will be freed automatically by the Garbage Collector when it is no 42108 longer referenced. But the memory that the pointer points to is an 42109 array of 'unsigned int' elements, and the GC must not try to scan 42110 it to find pointers to mark or relocate, which is why it is marked 42111 with the 'atomic' option. 42112 42113 Note that, currently, global variables can not be marked with 42114 'atomic'; only fields of a struct can. This is a known limitation. 42115 It would be useful to be able to mark global pointers with 'atomic' 42116 to make the PCH machinery aware of them so that they are saved and 42117 restored correctly to PCH files. 42118 42119'special ("NAME")' 42120 42121 The 'special' option is used to mark types that have to be dealt 42122 with by special case machinery. The parameter is the name of the 42123 special case. See 'gengtype.c' for further details. Avoid adding 42124 new special cases unless there is no other alternative. 42125 42126'user' 42127 42128 The 'user' option indicates that the code to mark structure fields 42129 is completely handled by user-provided routines. See section *note 42130 User GC:: for details on what functions need to be provided. 42131 42132 42133File: gccint.info, Node: Inheritance and GTY, Next: User GC, Prev: GTY Options, Up: Type Information 42134 4213523.2 Support for inheritance 42136============================ 42137 42138gengtype has some support for simple class hierarchies. You can use 42139this to have gengtype autogenerate marking routines, provided: 42140 42141 * There must be a concrete base class, with a discriminator 42142 expression that can be used to identify which subclass an instance 42143 is. 42144 * Only single inheritance is used. 42145 * None of the classes within the hierarchy are templates. 42146 42147 If your class hierarchy does not fit in this pattern, you must use 42148*note User GC:: instead. 42149 42150 The base class and its discriminator must be identified using the 42151"desc" option. Each concrete subclass must use the "tag" option to 42152identify which value of the discriminator it corresponds to. 42153 42154 Every class in the hierarchy must have a 'GTY(())' marker, as gengtype 42155will only attempt to parse classes that have such a marker (1). 42156 42157 class GTY((desc("%h.kind"), tag("0"))) example_base 42158 { 42159 public: 42160 int kind; 42161 tree a; 42162 }; 42163 42164 class GTY((tag("1"))) some_subclass : public example_base 42165 { 42166 public: 42167 tree b; 42168 }; 42169 42170 class GTY((tag("2"))) some_other_subclass : public example_base 42171 { 42172 public: 42173 tree c; 42174 }; 42175 42176 The generated marking routines for the above will contain a "switch" on 42177"kind", visiting all appropriate fields. For example, if kind is 2, it 42178will cast to "some_other_subclass" and visit fields a, b, and c. 42179 42180 ---------- Footnotes ---------- 42181 42182 (1) Classes lacking such a marker will not be identified as being 42183part of the hierarchy, and so the marking routines will not handle them, 42184leading to a assertion failure within the marking routines due to an 42185unknown tag value (assuming that assertions are enabled). 42186 42187 42188File: gccint.info, Node: User GC, Next: GGC Roots, Prev: Inheritance and GTY, Up: Type Information 42189 4219023.3 Support for user-provided GC marking routines 42191================================================== 42192 42193The garbage collector supports types for which no automatic marking code 42194is generated. For these types, the user is required to provide three 42195functions: one to act as a marker for garbage collection, and two 42196functions to act as marker and pointer walker for pre-compiled headers. 42197 42198 Given a structure 'struct GTY((user)) my_struct', the following 42199functions should be defined to mark 'my_struct': 42200 42201 void gt_ggc_mx (my_struct *p) 42202 { 42203 /* This marks field 'fld'. */ 42204 gt_ggc_mx (p->fld); 42205 } 42206 42207 void gt_pch_nx (my_struct *p) 42208 { 42209 /* This marks field 'fld'. */ 42210 gt_pch_nx (tp->fld); 42211 } 42212 42213 void gt_pch_nx (my_struct *p, gt_pointer_operator op, void *cookie) 42214 { 42215 /* For every field 'fld', call the given pointer operator. */ 42216 op (&(tp->fld), cookie); 42217 } 42218 42219 In general, each marker 'M' should call 'M' for every pointer field in 42220the structure. Fields that are not allocated in GC or are not pointers 42221must be ignored. 42222 42223 For embedded lists (e.g., structures with a 'next' or 'prev' pointer), 42224the marker must follow the chain and mark every element in it. 42225 42226 Note that the rules for the pointer walker 'gt_pch_nx (my_struct *, 42227gt_pointer_operator, void *)' are slightly different. In this case, the 42228operation 'op' must be applied to the _address_ of every pointer field. 42229 4223023.3.1 User-provided marking routines for template types 42231-------------------------------------------------------- 42232 42233When a template type 'TP' is marked with 'GTY', all instances of that 42234type are considered user-provided types. This means that the individual 42235instances of 'TP' do not need to be marked with 'GTY'. The user needs 42236to provide template functions to mark all the fields of the type. 42237 42238 The following code snippets represent all the functions that need to be 42239provided. Note that type 'TP' may reference to more than one type. In 42240these snippets, there is only one type 'T', but there could be more. 42241 42242 template<typename T> 42243 void gt_ggc_mx (TP<T> *tp) 42244 { 42245 extern void gt_ggc_mx (T&); 42246 42247 /* This marks field 'fld' of type 'T'. */ 42248 gt_ggc_mx (tp->fld); 42249 } 42250 42251 template<typename T> 42252 void gt_pch_nx (TP<T> *tp) 42253 { 42254 extern void gt_pch_nx (T&); 42255 42256 /* This marks field 'fld' of type 'T'. */ 42257 gt_pch_nx (tp->fld); 42258 } 42259 42260 template<typename T> 42261 void gt_pch_nx (TP<T *> *tp, gt_pointer_operator op, void *cookie) 42262 { 42263 /* For every field 'fld' of 'tp' with type 'T *', call the given 42264 pointer operator. */ 42265 op (&(tp->fld), cookie); 42266 } 42267 42268 template<typename T> 42269 void gt_pch_nx (TP<T> *tp, gt_pointer_operator, void *cookie) 42270 { 42271 extern void gt_pch_nx (T *, gt_pointer_operator, void *); 42272 42273 /* For every field 'fld' of 'tp' with type 'T', call the pointer 42274 walker for all the fields of T. */ 42275 gt_pch_nx (&(tp->fld), op, cookie); 42276 } 42277 42278 Support for user-defined types is currently limited. The following 42279restrictions apply: 42280 42281 1. Type 'TP' and all the argument types 'T' must be marked with 'GTY'. 42282 42283 2. Type 'TP' can only have type names in its argument list. 42284 42285 3. The pointer walker functions are different for 'TP<T>' and 'TP<T 42286 *>'. In the case of 'TP<T>', references to 'T' must be handled by 42287 calling 'gt_pch_nx' (which will, in turn, walk all the pointers 42288 inside fields of 'T'). In the case of 'TP<T *>', references to 'T 42289 *' must be handled by calling the 'op' function on the address of 42290 the pointer (see the code snippets above). 42291 42292 42293File: gccint.info, Node: GGC Roots, Next: Files, Prev: User GC, Up: Type Information 42294 4229523.4 Marking Roots for the Garbage Collector 42296============================================ 42297 42298In addition to keeping track of types, the type machinery also locates 42299the global variables ("roots") that the garbage collector starts at. 42300Roots must be declared using one of the following syntaxes: 42301 42302 * 'extern GTY(([OPTIONS])) TYPE NAME;' 42303 * 'static GTY(([OPTIONS])) TYPE NAME;' 42304The syntax 42305 * 'GTY(([OPTIONS])) TYPE NAME;' 42306is _not_ accepted. There should be an 'extern' declaration of such a 42307variable in a header somewhere--mark that, not the definition. Or, if 42308the variable is only used in one file, make it 'static'. 42309 42310 42311File: gccint.info, Node: Files, Next: Invoking the garbage collector, Prev: GGC Roots, Up: Type Information 42312 4231323.5 Source Files Containing Type Information 42314============================================= 42315 42316Whenever you add 'GTY' markers to a source file that previously had 42317none, or create a new source file containing 'GTY' markers, there are 42318three things you need to do: 42319 42320 1. You need to add the file to the list of source files the type 42321 machinery scans. There are four cases: 42322 42323 a. For a back-end file, this is usually done automatically; if 42324 not, you should add it to 'target_gtfiles' in the appropriate 42325 port's entries in 'config.gcc'. 42326 42327 b. For files shared by all front ends, add the filename to the 42328 'GTFILES' variable in 'Makefile.in'. 42329 42330 c. For files that are part of one front end, add the filename to 42331 the 'gtfiles' variable defined in the appropriate 42332 'config-lang.in'. Headers should appear before non-headers in 42333 this list. 42334 42335 d. For files that are part of some but not all front ends, add 42336 the filename to the 'gtfiles' variable of _all_ the front ends 42337 that use it. 42338 42339 2. If the file was a header file, you'll need to check that it's 42340 included in the right place to be visible to the generated files. 42341 For a back-end header file, this should be done automatically. For 42342 a front-end header file, it needs to be included by the same file 42343 that includes 'gtype-LANG.h'. For other header files, it needs to 42344 be included in 'gtype-desc.c', which is a generated file, so add it 42345 to 'ifiles' in 'open_base_file' in 'gengtype.c'. 42346 42347 For source files that aren't header files, the machinery will 42348 generate a header file that should be included in the source file 42349 you just changed. The file will be called 'gt-PATH.h' where PATH 42350 is the pathname relative to the 'gcc' directory with slashes 42351 replaced by -, so for example the header file to be included in 42352 'cp/parser.c' is called 'gt-cp-parser.c'. The generated header 42353 file should be included after everything else in the source file. 42354 Don't forget to mention this file as a dependency in the 42355 'Makefile'! 42356 42357 For language frontends, there is another file that needs to be included 42358somewhere. It will be called 'gtype-LANG.h', where LANG is the name of 42359the subdirectory the language is contained in. 42360 42361 Plugins can add additional root tables. Run the 'gengtype' utility in 42362plugin mode as 'gengtype -P pluginout.h SOURCE-DIR FILE-LIST PLUGIN*.C' 42363with your plugin files PLUGIN*.C using 'GTY' to generate the PLUGINOUT.H 42364file. The GCC build tree is needed to be present in that mode. 42365 42366 42367File: gccint.info, Node: Invoking the garbage collector, Next: Troubleshooting, Prev: Files, Up: Type Information 42368 4236923.6 How to invoke the garbage collector 42370======================================== 42371 42372The GCC garbage collector GGC is only invoked explicitly. In contrast 42373with many other garbage collectors, it is not implicitly invoked by 42374allocation routines when a lot of memory has been consumed. So the only 42375way to have GGC reclaim storage is to call the 'ggc_collect' function 42376explicitly. This call is an expensive operation, as it may have to scan 42377the entire heap. Beware that local variables (on the GCC call stack) 42378are not followed by such an invocation (as many other garbage collectors 42379do): you should reference all your data from static or external 'GTY'-ed 42380variables, and it is advised to call 'ggc_collect' with a shallow call 42381stack. The GGC is an exact mark and sweep garbage collector (so it does 42382not scan the call stack for pointers). In practice GCC passes don't 42383often call 'ggc_collect' themselves, because it is called by the pass 42384manager between passes. 42385 42386 At the time of the 'ggc_collect' call all pointers in the GC-marked 42387structures must be valid or 'NULL'. In practice this means that there 42388should not be uninitialized pointer fields in the structures even if 42389your code never reads or writes those fields at a particular instance. 42390One way to ensure this is to use cleared versions of allocators unless 42391all the fields are initialized manually immediately after allocation. 42392 42393 42394File: gccint.info, Node: Troubleshooting, Prev: Invoking the garbage collector, Up: Type Information 42395 4239623.7 Troubleshooting the garbage collector 42397========================================== 42398 42399With the current garbage collector implementation, most issues should 42400show up as GCC compilation errors. Some of the most commonly 42401encountered issues are described below. 42402 42403 * Gengtype does not produce allocators for a 'GTY'-marked type. 42404 Gengtype checks if there is at least one possible path from GC 42405 roots to at least one instance of each type before outputting 42406 allocators. If there is no such path, the 'GTY' markers will be 42407 ignored and no allocators will be output. Solve this by making 42408 sure that there exists at least one such path. If creating it is 42409 unfeasible or raises a "code smell", consider if you really must 42410 use GC for allocating such type. 42411 42412 * Link-time errors about undefined 'gt_ggc_r_foo_bar' and 42413 similarly-named symbols. Check if your 'foo_bar' source file has 42414 '#include "gt-foo_bar.h"' as its very last line. 42415 42416 42417File: gccint.info, Node: Plugins, Next: LTO, Prev: Type Information, Up: Top 42418 4241924 Plugins 42420********** 42421 42422GCC plugins are loadable modules that provide extra features to the 42423compiler. Like GCC itself they can be distributed in source and binary 42424forms. 42425 42426 GCC plugins provide developers with a rich subset of the GCC API to 42427allow them to extend GCC as they see fit. Whether it is writing an 42428additional optimization pass, transforming code, or analyzing 42429information, plugins can be quite useful. 42430 42431* Menu: 42432 42433* Plugins loading:: How can we load plugins. 42434* Plugin API:: The APIs for plugins. 42435* Plugins pass:: How a plugin interact with the pass manager. 42436* Plugins GC:: How a plugin Interact with GCC Garbage Collector. 42437* Plugins description:: Giving information about a plugin itself. 42438* Plugins attr:: Registering custom attributes or pragmas. 42439* Plugins recording:: Recording information about pass execution. 42440* Plugins gate:: Controlling which passes are being run. 42441* Plugins tracking:: Keeping track of available passes. 42442* Plugins building:: How can we build a plugin. 42443 42444 42445File: gccint.info, Node: Plugins loading, Next: Plugin API, Up: Plugins 42446 4244724.1 Loading Plugins 42448==================== 42449 42450Plugins are supported on platforms that support '-ldl -rdynamic' as well 42451as Windows/MinGW. They are loaded by the compiler using 'dlopen' or 42452equivalent and invoked at pre-determined locations in the compilation 42453process. 42454 42455 Plugins are loaded with 42456 42457 '-fplugin=/path/to/NAME.EXT' '-fplugin-arg-NAME-KEY1[=VALUE1]' 42458 42459 Where NAME is the plugin name and EXT is the platform-specific dynamic 42460library extension. It should be 'dll' on Windows/MinGW, 'dylib' on 42461Darwin/Mac OS X, and 'so' on all other platforms. The plugin arguments 42462are parsed by GCC and passed to respective plugins as key-value pairs. 42463Multiple plugins can be invoked by specifying multiple '-fplugin' 42464arguments. 42465 42466 A plugin can be simply given by its short name (no dots or slashes). 42467When simply passing '-fplugin=NAME', the plugin is loaded from the 42468'plugin' directory, so '-fplugin=NAME' is the same as '-fplugin=`gcc 42469-print-file-name=plugin`/NAME.EXT', using backquote shell syntax to 42470query the 'plugin' directory. 42471 42472 42473File: gccint.info, Node: Plugin API, Next: Plugins pass, Prev: Plugins loading, Up: Plugins 42474 4247524.2 Plugin API 42476=============== 42477 42478Plugins are activated by the compiler at specific events as defined in 42479'gcc-plugin.h'. For each event of interest, the plugin should call 42480'register_callback' specifying the name of the event and address of the 42481callback function that will handle that event. 42482 42483 The header 'gcc-plugin.h' must be the first gcc header to be included. 42484 4248524.2.1 Plugin license check 42486--------------------------- 42487 42488Every plugin should define the global symbol 'plugin_is_GPL_compatible' 42489to assert that it has been licensed under a GPL-compatible license. If 42490this symbol does not exist, the compiler will emit a fatal error and 42491exit with the error message: 42492 42493 fatal error: plugin NAME is not licensed under a GPL-compatible license 42494 NAME: undefined symbol: plugin_is_GPL_compatible 42495 compilation terminated 42496 42497 The declared type of the symbol should be int, to match a forward 42498declaration in 'gcc-plugin.h' that suppresses C++ mangling. It does not 42499need to be in any allocated section, though. The compiler merely 42500asserts that the symbol exists in the global scope. Something like this 42501is enough: 42502 42503 int plugin_is_GPL_compatible; 42504 4250524.2.2 Plugin initialization 42506---------------------------- 42507 42508Every plugin should export a function called 'plugin_init' that is 42509called right after the plugin is loaded. This function is responsible 42510for registering all the callbacks required by the plugin and do any 42511other required initialization. 42512 42513 This function is called from 'compile_file' right before invoking the 42514parser. The arguments to 'plugin_init' are: 42515 42516 * 'plugin_info': Plugin invocation information. 42517 * 'version': GCC version. 42518 42519 The 'plugin_info' struct is defined as follows: 42520 42521 struct plugin_name_args 42522 { 42523 char *base_name; /* Short name of the plugin 42524 (filename without .so suffix). */ 42525 const char *full_name; /* Path to the plugin as specified with 42526 -fplugin=. */ 42527 int argc; /* Number of arguments specified with 42528 -fplugin-arg-.... */ 42529 struct plugin_argument *argv; /* Array of ARGC key-value pairs. */ 42530 const char *version; /* Version string provided by plugin. */ 42531 const char *help; /* Help string provided by plugin. */ 42532 } 42533 42534 If initialization fails, 'plugin_init' must return a non-zero value. 42535Otherwise, it should return 0. 42536 42537 The version of the GCC compiler loading the plugin is described by the 42538following structure: 42539 42540 struct plugin_gcc_version 42541 { 42542 const char *basever; 42543 const char *datestamp; 42544 const char *devphase; 42545 const char *revision; 42546 const char *configuration_arguments; 42547 }; 42548 42549 The function 'plugin_default_version_check' takes two pointers to such 42550structure and compare them field by field. It can be used by the 42551plugin's 'plugin_init' function. 42552 42553 The version of GCC used to compile the plugin can be found in the 42554symbol 'gcc_version' defined in the header 'plugin-version.h'. The 42555recommended version check to perform looks like 42556 42557 #include "plugin-version.h" 42558 ... 42559 42560 int 42561 plugin_init (struct plugin_name_args *plugin_info, 42562 struct plugin_gcc_version *version) 42563 { 42564 if (!plugin_default_version_check (version, &gcc_version)) 42565 return 1; 42566 42567 } 42568 42569 but you can also check the individual fields if you want a less strict 42570check. 42571 4257224.2.3 Plugin callbacks 42573----------------------- 42574 42575Callback functions have the following prototype: 42576 42577 /* The prototype for a plugin callback function. 42578 gcc_data - event-specific data provided by GCC 42579 user_data - plugin-specific data provided by the plug-in. */ 42580 typedef void (*plugin_callback_func)(void *gcc_data, void *user_data); 42581 42582 Callbacks can be invoked at the following pre-determined events: 42583 42584 enum plugin_event 42585 { 42586 PLUGIN_START_PARSE_FUNCTION, /* Called before parsing the body of a function. */ 42587 PLUGIN_FINISH_PARSE_FUNCTION, /* After finishing parsing a function. */ 42588 PLUGIN_PASS_MANAGER_SETUP, /* To hook into pass manager. */ 42589 PLUGIN_FINISH_TYPE, /* After finishing parsing a type. */ 42590 PLUGIN_FINISH_DECL, /* After finishing parsing a declaration. */ 42591 PLUGIN_FINISH_UNIT, /* Useful for summary processing. */ 42592 PLUGIN_PRE_GENERICIZE, /* Allows to see low level AST in C and C++ frontends. */ 42593 PLUGIN_FINISH, /* Called before GCC exits. */ 42594 PLUGIN_INFO, /* Information about the plugin. */ 42595 PLUGIN_GGC_START, /* Called at start of GCC Garbage Collection. */ 42596 PLUGIN_GGC_MARKING, /* Extend the GGC marking. */ 42597 PLUGIN_GGC_END, /* Called at end of GGC. */ 42598 PLUGIN_REGISTER_GGC_ROOTS, /* Register an extra GGC root table. */ 42599 PLUGIN_ATTRIBUTES, /* Called during attribute registration */ 42600 PLUGIN_START_UNIT, /* Called before processing a translation unit. */ 42601 PLUGIN_PRAGMAS, /* Called during pragma registration. */ 42602 /* Called before first pass from all_passes. */ 42603 PLUGIN_ALL_PASSES_START, 42604 /* Called after last pass from all_passes. */ 42605 PLUGIN_ALL_PASSES_END, 42606 /* Called before first ipa pass. */ 42607 PLUGIN_ALL_IPA_PASSES_START, 42608 /* Called after last ipa pass. */ 42609 PLUGIN_ALL_IPA_PASSES_END, 42610 /* Allows to override pass gate decision for current_pass. */ 42611 PLUGIN_OVERRIDE_GATE, 42612 /* Called before executing a pass. */ 42613 PLUGIN_PASS_EXECUTION, 42614 /* Called before executing subpasses of a GIMPLE_PASS in 42615 execute_ipa_pass_list. */ 42616 PLUGIN_EARLY_GIMPLE_PASSES_START, 42617 /* Called after executing subpasses of a GIMPLE_PASS in 42618 execute_ipa_pass_list. */ 42619 PLUGIN_EARLY_GIMPLE_PASSES_END, 42620 /* Called when a pass is first instantiated. */ 42621 PLUGIN_NEW_PASS, 42622 /* Called when a file is #include-d or given via the #line directive. 42623 This could happen many times. The event data is the included file path, 42624 as a const char* pointer. */ 42625 PLUGIN_INCLUDE_FILE, 42626 42627 PLUGIN_EVENT_FIRST_DYNAMIC /* Dummy event used for indexing callback 42628 array. */ 42629 }; 42630 42631 In addition, plugins can also look up the enumerator of a named event, 42632and / or generate new events dynamically, by calling the function 42633'get_named_event_id'. 42634 42635 To register a callback, the plugin calls 'register_callback' with the 42636arguments: 42637 42638 * 'char *name': Plugin name. 42639 * 'int event': The event code. 42640 * 'plugin_callback_func callback': The function that handles 'event'. 42641 * 'void *user_data': Pointer to plugin-specific data. 42642 42643 For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, and 42644PLUGIN_REGISTER_GGC_ROOTS pseudo-events the 'callback' should be null, 42645and the 'user_data' is specific. 42646 42647 When the PLUGIN_PRAGMAS event is triggered (with a null pointer as data 42648from GCC), plugins may register their own pragmas. Notice that pragmas 42649are not available from 'lto1', so plugins used with '-flto' option to 42650GCC during link-time optimization cannot use pragmas and do not even see 42651functions like 'c_register_pragma' or 'pragma_lex'. 42652 42653 The PLUGIN_INCLUDE_FILE event, with a 'const char*' file path as GCC 42654data, is triggered for processing of '#include' or '#line' directives. 42655 42656 The PLUGIN_FINISH event is the last time that plugins can call GCC 42657functions, notably emit diagnostics with 'warning', 'error' etc. 42658 42659 42660File: gccint.info, Node: Plugins pass, Next: Plugins GC, Prev: Plugin API, Up: Plugins 42661 4266224.3 Interacting with the pass manager 42663====================================== 42664 42665There needs to be a way to add/reorder/remove passes dynamically. This 42666is useful for both analysis plugins (plugging in after a certain pass 42667such as CFG or an IPA pass) and optimization plugins. 42668 42669 Basic support for inserting new passes or replacing existing passes is 42670provided. A plugin registers a new pass with GCC by calling 42671'register_callback' with the 'PLUGIN_PASS_MANAGER_SETUP' event and a 42672pointer to a 'struct register_pass_info' object defined as follows 42673 42674 enum pass_positioning_ops 42675 { 42676 PASS_POS_INSERT_AFTER, // Insert after the reference pass. 42677 PASS_POS_INSERT_BEFORE, // Insert before the reference pass. 42678 PASS_POS_REPLACE // Replace the reference pass. 42679 }; 42680 42681 struct register_pass_info 42682 { 42683 struct opt_pass *pass; /* New pass provided by the plugin. */ 42684 const char *reference_pass_name; /* Name of the reference pass for hooking 42685 up the new pass. */ 42686 int ref_pass_instance_number; /* Insert the pass at the specified 42687 instance number of the reference pass. */ 42688 /* Do it for every instance if it is 0. */ 42689 enum pass_positioning_ops pos_op; /* how to insert the new pass. */ 42690 }; 42691 42692 42693 /* Sample plugin code that registers a new pass. */ 42694 int 42695 plugin_init (struct plugin_name_args *plugin_info, 42696 struct plugin_gcc_version *version) 42697 { 42698 struct register_pass_info pass_info; 42699 42700 ... 42701 42702 /* Code to fill in the pass_info object with new pass information. */ 42703 42704 ... 42705 42706 /* Register the new pass. */ 42707 register_callback (plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &pass_info); 42708 42709 ... 42710 } 42711 42712 42713File: gccint.info, Node: Plugins GC, Next: Plugins description, Prev: Plugins pass, Up: Plugins 42714 4271524.4 Interacting with the GCC Garbage Collector 42716=============================================== 42717 42718Some plugins may want to be informed when GGC (the GCC Garbage 42719Collector) is running. They can register callbacks for the 42720'PLUGIN_GGC_START' and 'PLUGIN_GGC_END' events (for which the callback 42721is called with a null 'gcc_data') to be notified of the start or end of 42722the GCC garbage collection. 42723 42724 Some plugins may need to have GGC mark additional data. This can be 42725done by registering a callback (called with a null 'gcc_data') for the 42726'PLUGIN_GGC_MARKING' event. Such callbacks can call the 'ggc_set_mark' 42727routine, preferably through the 'ggc_mark' macro (and conversely, these 42728routines should usually not be used in plugins outside of the 42729'PLUGIN_GGC_MARKING' event). Plugins that wish to hold weak references 42730to gc data may also use this event to drop weak references when the 42731object is about to be collected. The 'ggc_marked_p' function can be 42732used to tell if an object is marked, or is about to be collected. The 42733'gt_clear_cache' overloads which some types define may also be of use in 42734managing weak references. 42735 42736 Some plugins may need to add extra GGC root tables, e.g. to handle 42737their own 'GTY'-ed data. This can be done with the 42738'PLUGIN_REGISTER_GGC_ROOTS' pseudo-event with a null callback and the 42739extra root table (of type 'struct ggc_root_tab*') as 'user_data'. 42740Running the 'gengtype -p SOURCE-DIR FILE-LIST PLUGIN*.C ...' utility 42741generates these extra root tables. 42742 42743 You should understand the details of memory management inside GCC 42744before using 'PLUGIN_GGC_MARKING' or 'PLUGIN_REGISTER_GGC_ROOTS'. 42745 42746 42747File: gccint.info, Node: Plugins description, Next: Plugins attr, Prev: Plugins GC, Up: Plugins 42748 4274924.5 Giving information about a plugin 42750====================================== 42751 42752A plugin should give some information to the user about itself. This 42753uses the following structure: 42754 42755 struct plugin_info 42756 { 42757 const char *version; 42758 const char *help; 42759 }; 42760 42761 Such a structure is passed as the 'user_data' by the plugin's init 42762routine using 'register_callback' with the 'PLUGIN_INFO' pseudo-event 42763and a null callback. 42764 42765 42766File: gccint.info, Node: Plugins attr, Next: Plugins recording, Prev: Plugins description, Up: Plugins 42767 4276824.6 Registering custom attributes or pragmas 42769============================================= 42770 42771For analysis (or other) purposes it is useful to be able to add custom 42772attributes or pragmas. 42773 42774 The 'PLUGIN_ATTRIBUTES' callback is called during attribute 42775registration. Use the 'register_attribute' function to register custom 42776attributes. 42777 42778 /* Attribute handler callback */ 42779 static tree 42780 handle_user_attribute (tree *node, tree name, tree args, 42781 int flags, bool *no_add_attrs) 42782 { 42783 return NULL_TREE; 42784 } 42785 42786 /* Attribute definition */ 42787 static struct attribute_spec user_attr = 42788 { "user", 1, 1, false, false, false, false, handle_user_attribute, NULL }; 42789 42790 /* Plugin callback called during attribute registration. 42791 Registered with register_callback (plugin_name, PLUGIN_ATTRIBUTES, register_attributes, NULL) 42792 */ 42793 static void 42794 register_attributes (void *event_data, void *data) 42795 { 42796 warning (0, G_("Callback to register attributes")); 42797 register_attribute (&user_attr); 42798 } 42799 42800 42801 The PLUGIN_PRAGMAS callback is called once during pragmas registration. 42802Use the 'c_register_pragma', 'c_register_pragma_with_data', 42803'c_register_pragma_with_expansion', 42804'c_register_pragma_with_expansion_and_data' functions to register custom 42805pragmas and their handlers (which often want to call 'pragma_lex') from 42806'c-family/c-pragma.h'. 42807 42808 /* Plugin callback called during pragmas registration. Registered with 42809 register_callback (plugin_name, PLUGIN_PRAGMAS, 42810 register_my_pragma, NULL); 42811 */ 42812 static void 42813 register_my_pragma (void *event_data, void *data) 42814 { 42815 warning (0, G_("Callback to register pragmas")); 42816 c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello); 42817 } 42818 42819 It is suggested to pass '"GCCPLUGIN"' (or a short name identifying your 42820plugin) as the "space" argument of your pragma. 42821 42822 Pragmas registered with 'c_register_pragma_with_expansion' or 42823'c_register_pragma_with_expansion_and_data' support preprocessor 42824expansions. For example: 42825 42826 #define NUMBER 10 42827 #pragma GCCPLUGIN foothreshold (NUMBER) 42828 42829 42830File: gccint.info, Node: Plugins recording, Next: Plugins gate, Prev: Plugins attr, Up: Plugins 42831 4283224.7 Recording information about pass execution 42833=============================================== 42834 42835The event PLUGIN_PASS_EXECUTION passes the pointer to the executed pass 42836(the same as current_pass) as 'gcc_data' to the callback. You can also 42837inspect cfun to find out about which function this pass is executed for. 42838Note that this event will only be invoked if the gate check (if 42839applicable, modified by PLUGIN_OVERRIDE_GATE) succeeds. You can use 42840other hooks, like 'PLUGIN_ALL_PASSES_START', 'PLUGIN_ALL_PASSES_END', 42841'PLUGIN_ALL_IPA_PASSES_START', 'PLUGIN_ALL_IPA_PASSES_END', 42842'PLUGIN_EARLY_GIMPLE_PASSES_START', and/or 42843'PLUGIN_EARLY_GIMPLE_PASSES_END' to manipulate global state in your 42844plugin(s) in order to get context for the pass execution. 42845 42846 42847File: gccint.info, Node: Plugins gate, Next: Plugins tracking, Prev: Plugins recording, Up: Plugins 42848 4284924.8 Controlling which passes are being run 42850=========================================== 42851 42852After the original gate function for a pass is called, its result - the 42853gate status - is stored as an integer. Then the event 42854'PLUGIN_OVERRIDE_GATE' is invoked, with a pointer to the gate status in 42855the 'gcc_data' parameter to the callback function. A nonzero value of 42856the gate status means that the pass is to be executed. You can both 42857read and write the gate status via the passed pointer. 42858 42859 42860File: gccint.info, Node: Plugins tracking, Next: Plugins building, Prev: Plugins gate, Up: Plugins 42861 4286224.9 Keeping track of available passes 42863====================================== 42864 42865When your plugin is loaded, you can inspect the various pass lists to 42866determine what passes are available. However, other plugins might add 42867new passes. Also, future changes to GCC might cause generic passes to 42868be added after plugin loading. When a pass is first added to one of the 42869pass lists, the event 'PLUGIN_NEW_PASS' is invoked, with the callback 42870parameter 'gcc_data' pointing to the new pass. 42871 42872 42873File: gccint.info, Node: Plugins building, Prev: Plugins tracking, Up: Plugins 42874 4287524.10 Building GCC plugins 42876========================== 42877 42878If plugins are enabled, GCC installs the headers needed to build a 42879plugin (somewhere in the installation tree, e.g. under '/usr/local'). 42880In particular a 'plugin/include' directory is installed, containing all 42881the header files needed to build plugins. 42882 42883 On most systems, you can query this 'plugin' directory by invoking 'gcc 42884-print-file-name=plugin' (replace if needed 'gcc' with the appropriate 42885program path). 42886 42887 Inside plugins, this 'plugin' directory name can be queried by calling 42888'default_plugin_dir_name ()'. 42889 42890 Plugins may know, when they are compiled, the GCC version for which 42891'plugin-version.h' is provided. The constant macros 42892'GCCPLUGIN_VERSION_MAJOR', 'GCCPLUGIN_VERSION_MINOR', 42893'GCCPLUGIN_VERSION_PATCHLEVEL', 'GCCPLUGIN_VERSION' are integer numbers, 42894so a plugin could ensure it is built for GCC 4.7 with 42895 #if GCCPLUGIN_VERSION != 4007 42896 #error this GCC plugin is for GCC 4.7 42897 #endif 42898 42899 The following GNU Makefile excerpt shows how to build a simple plugin: 42900 42901 HOST_GCC=g++ 42902 TARGET_GCC=gcc 42903 PLUGIN_SOURCE_FILES= plugin1.c plugin2.cc 42904 GCCPLUGINS_DIR:= $(shell $(TARGET_GCC) -print-file-name=plugin) 42905 CXXFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC -fno-rtti -O2 42906 42907 plugin.so: $(PLUGIN_SOURCE_FILES) 42908 $(HOST_GCC) -shared $(CXXFLAGS) $^ -o $@ 42909 42910 A single source file plugin may be built with 'g++ -I`gcc 42911-print-file-name=plugin`/include -fPIC -shared -fno-rtti -O2 plugin.c -o 42912plugin.so', using backquote shell syntax to query the 'plugin' 42913directory. 42914 42915 Plugin support on Windows/MinGW has a number of limitations and 42916additional requirements. When building a plugin on Windows we have to 42917link an import library for the corresponding backend executable, for 42918example, 'cc1.exe', 'cc1plus.exe', etc., in order to gain access to the 42919symbols provided by GCC. This means that on Windows a plugin is 42920language-specific, for example, for C, C++, etc. If you wish to use 42921your plugin with multiple languages, then you will need to build 42922multiple plugin libraries and either instruct your users on how to load 42923the correct version or provide a compiler wrapper that does this 42924automatically. 42925 42926 Additionally, on Windows the plugin library has to export the 42927'plugin_is_GPL_compatible' and 'plugin_init' symbols. If you do not 42928wish to modify the source code of your plugin, then you can use the 42929'-Wl,--export-all-symbols' option or provide a suitable DEF file. 42930Alternatively, you can export just these two symbols by decorating them 42931with '__declspec(dllexport)', for example: 42932 42933 #ifdef _WIN32 42934 __declspec(dllexport) 42935 #endif 42936 int plugin_is_GPL_compatible; 42937 42938 #ifdef _WIN32 42939 __declspec(dllexport) 42940 #endif 42941 int plugin_init (plugin_name_args *, plugin_gcc_version *) 42942 42943 The import libraries are installed into the 'plugin' directory and 42944their names are derived by appending the '.a' extension to the backend 42945executable names, for example, 'cc1.exe.a', 'cc1plus.exe.a', etc. The 42946following command line shows how to build the single source file plugin 42947on Windows to be used with the C++ compiler: 42948 42949 g++ -I`gcc -print-file-name=plugin`/include -shared -Wl,--export-all-symbols \ 42950 -o plugin.dll plugin.c `gcc -print-file-name=plugin`/cc1plus.exe.a 42951 42952 When a plugin needs to use 'gengtype', be sure that both 'gengtype' and 42953'gtype.state' have the same version as the GCC for which the plugin is 42954built. 42955 42956 42957File: gccint.info, Node: LTO, Next: Match and Simplify, Prev: Plugins, Up: Top 42958 4295925 Link Time Optimization 42960************************* 42961 42962Link Time Optimization (LTO) gives GCC the capability of dumping its 42963internal representation (GIMPLE) to disk, so that all the different 42964compilation units that make up a single executable can be optimized as a 42965single module. This expands the scope of inter-procedural optimizations 42966to encompass the whole program (or, rather, everything that is visible 42967at link time). 42968 42969* Menu: 42970 42971* LTO Overview:: Overview of LTO. 42972* LTO object file layout:: LTO file sections in ELF. 42973* IPA:: Using summary information in IPA passes. 42974* WHOPR:: Whole program assumptions, 42975 linker plugin and symbol visibilities. 42976* Internal flags:: Internal flags controlling 'lto1'. 42977 42978 42979File: gccint.info, Node: LTO Overview, Next: LTO object file layout, Up: LTO 42980 4298125.1 Design Overview 42982==================== 42983 42984Link time optimization is implemented as a GCC front end for a bytecode 42985representation of GIMPLE that is emitted in special sections of '.o' 42986files. Currently, LTO support is enabled in most ELF-based systems, as 42987well as darwin, cygwin and mingw systems. 42988 42989 Since GIMPLE bytecode is saved alongside final object code, object 42990files generated with LTO support are larger than regular object files. 42991This "fat" object format makes it easy to integrate LTO into existing 42992build systems, as one can, for instance, produce archives of the files. 42993Additionally, one might be able to ship one set of fat objects which 42994could be used both for development and the production of optimized 42995builds. A, perhaps surprising, side effect of this feature is that any 42996mistake in the toolchain leads to LTO information not being used (e.g. 42997an older 'libtool' calling 'ld' directly). This is both an advantage, 42998as the system is more robust, and a disadvantage, as the user is not 42999informed that the optimization has been disabled. 43000 43001 The current implementation only produces "fat" objects, effectively 43002doubling compilation time and increasing file sizes up to 5x the 43003original size. This hides the problem that some tools, such as 'ar' and 43004'nm', need to understand symbol tables of LTO sections. These tools 43005were extended to use the plugin infrastructure, and with these problems 43006solved, GCC will also support "slim" objects consisting of the 43007intermediate code alone. 43008 43009 At the highest level, LTO splits the compiler in two. The first half 43010(the "writer") produces a streaming representation of all the internal 43011data structures needed to optimize and generate code. This includes 43012declarations, types, the callgraph and the GIMPLE representation of 43013function bodies. 43014 43015 When '-flto' is given during compilation of a source file, the pass 43016manager executes all the passes in 'all_lto_gen_passes'. Currently, 43017this phase is composed of two IPA passes: 43018 43019 * 'pass_ipa_lto_gimple_out' This pass executes the function 43020 'lto_output' in 'lto-streamer-out.c', which traverses the call 43021 graph encoding every reachable declaration, type and function. 43022 This generates a memory representation of all the file sections 43023 described below. 43024 43025 * 'pass_ipa_lto_finish_out' This pass executes the function 43026 'produce_asm_for_decls' in 'lto-streamer-out.c', which takes the 43027 memory image built in the previous pass and encodes it in the 43028 corresponding ELF file sections. 43029 43030 The second half of LTO support is the "reader". This is implemented as 43031the GCC front end 'lto1' in 'lto/lto.c'. When 'collect2' detects a link 43032set of '.o'/'.a' files with LTO information and the '-flto' is enabled, 43033it invokes 'lto1' which reads the set of files and aggregates them into 43034a single translation unit for optimization. The main entry point for 43035the reader is 'lto/lto.c':'lto_main'. 43036 4303725.1.1 LTO modes of operation 43038----------------------------- 43039 43040One of the main goals of the GCC link-time infrastructure was to allow 43041effective compilation of large programs. For this reason GCC implements 43042two link-time compilation modes. 43043 43044 1. _LTO mode_, in which the whole program is read into the compiler at 43045 link-time and optimized in a similar way as if it were a single 43046 source-level compilation unit. 43047 43048 2. _WHOPR or partitioned mode_, designed to utilize multiple CPUs 43049 and/or a distributed compilation environment to quickly link large 43050 applications. WHOPR stands for WHOle Program optimizeR (not to be 43051 confused with the semantics of '-fwhole-program'). It partitions 43052 the aggregated callgraph from many different '.o' files and 43053 distributes the compilation of the sub-graphs to different CPUs. 43054 43055 Note that distributed compilation is not implemented yet, but since 43056 the parallelism is facilitated via generating a 'Makefile', it 43057 would be easy to implement. 43058 43059 WHOPR splits LTO into three main stages: 43060 1. Local generation (LGEN) This stage executes in parallel. Every 43061 file in the program is compiled into the intermediate language and 43062 packaged together with the local call-graph and summary 43063 information. This stage is the same for both the LTO and WHOPR 43064 compilation mode. 43065 43066 2. Whole Program Analysis (WPA) WPA is performed sequentially. The 43067 global call-graph is generated, and a global analysis procedure 43068 makes transformation decisions. The global call-graph is 43069 partitioned to facilitate parallel optimization during phase 3. 43070 The results of the WPA stage are stored into new object files which 43071 contain the partitions of program expressed in the intermediate 43072 language and the optimization decisions. 43073 43074 3. Local transformations (LTRANS) This stage executes in parallel. 43075 All the decisions made during phase 2 are implemented locally in 43076 each partitioned object file, and the final object code is 43077 generated. Optimizations which cannot be decided efficiently 43078 during the phase 2 may be performed on the local call-graph 43079 partitions. 43080 43081 WHOPR can be seen as an extension of the usual LTO mode of compilation. 43082In LTO, WPA and LTRANS are executed within a single execution of the 43083compiler, after the whole program has been read into memory. 43084 43085 When compiling in WHOPR mode, the callgraph is partitioned during the 43086WPA stage. The whole program is split into a given number of partitions 43087of roughly the same size. The compiler tries to minimize the number of 43088references which cross partition boundaries. The main advantage of 43089WHOPR is to allow the parallel execution of LTRANS stages, which are the 43090most time-consuming part of the compilation process. Additionally, it 43091avoids the need to load the whole program into memory. 43092 43093 43094File: gccint.info, Node: LTO object file layout, Next: IPA, Prev: LTO Overview, Up: LTO 43095 4309625.2 LTO file sections 43097====================== 43098 43099LTO information is stored in several ELF sections inside object files. 43100Data structures and enum codes for sections are defined in 43101'lto-streamer.h'. 43102 43103 These sections are emitted from 'lto-streamer-out.c' and mapped in all 43104at once from 'lto/lto.c':'lto_file_read'. The individual functions 43105dealing with the reading/writing of each section are described below. 43106 43107 * Command line options ('.gnu.lto_.opts') 43108 43109 This section contains the command line options used to generate the 43110 object files. This is used at link time to determine the 43111 optimization level and other settings when they are not explicitly 43112 specified at the linker command line. 43113 43114 Currently, GCC does not support combining LTO object files compiled 43115 with different set of the command line options into a single 43116 binary. At link time, the options given on the command line and 43117 the options saved on all the files in a link-time set are applied 43118 globally. No attempt is made at validating the combination of 43119 flags (other than the usual validation done by option processing). 43120 This is implemented in 'lto/lto.c':'lto_read_all_file_options'. 43121 43122 * Symbol table ('.gnu.lto_.symtab') 43123 43124 This table replaces the ELF symbol table for functions and 43125 variables represented in the LTO IL. Symbols used and exported by 43126 the optimized assembly code of "fat" objects might not match the 43127 ones used and exported by the intermediate code. This table is 43128 necessary because the intermediate code is less optimized and thus 43129 requires a separate symbol table. 43130 43131 Additionally, the binary code in the "fat" object will lack a call 43132 to a function, since the call was optimized out at compilation time 43133 after the intermediate language was streamed out. In some special 43134 cases, the same optimization may not happen during link-time 43135 optimization. This would lead to an undefined symbol if only one 43136 symbol table was used. 43137 43138 The symbol table is emitted in 43139 'lto-streamer-out.c':'produce_symtab'. 43140 43141 * Global declarations and types ('.gnu.lto_.decls') 43142 43143 This section contains an intermediate language dump of all 43144 declarations and types required to represent the callgraph, static 43145 variables and top-level debug info. 43146 43147 The contents of this section are emitted in 43148 'lto-streamer-out.c':'produce_asm_for_decls'. Types and symbols 43149 are emitted in a topological order that preserves the sharing of 43150 pointers when the file is read back in 43151 ('lto.c':'read_cgraph_and_symbols'). 43152 43153 * The callgraph ('.gnu.lto_.cgraph') 43154 43155 This section contains the basic data structure used by the GCC 43156 inter-procedural optimization infrastructure. This section stores 43157 an annotated multi-graph which represents the functions and call 43158 sites as well as the variables, aliases and top-level 'asm' 43159 statements. 43160 43161 This section is emitted in 'lto-streamer-out.c':'output_cgraph' and 43162 read in 'lto-cgraph.c':'input_cgraph'. 43163 43164 * IPA references ('.gnu.lto_.refs') 43165 43166 This section contains references between function and static 43167 variables. It is emitted by 'lto-cgraph.c':'output_refs' and read 43168 by 'lto-cgraph.c':'input_refs'. 43169 43170 * Function bodies ('.gnu.lto_.function_body.<name>') 43171 43172 This section contains function bodies in the intermediate language 43173 representation. Every function body is in a separate section to 43174 allow copying of the section independently to different object 43175 files or reading the function on demand. 43176 43177 Functions are emitted in 'lto-streamer-out.c':'output_function' and 43178 read in 'lto-streamer-in.c':'input_function'. 43179 43180 * Static variable initializers ('.gnu.lto_.vars') 43181 43182 This section contains all the symbols in the global variable pool. 43183 It is emitted by 'lto-cgraph.c':'output_varpool' and read in 43184 'lto-cgraph.c':'input_cgraph'. 43185 43186 * Summaries and optimization summaries used by IPA passes 43187 ('.gnu.lto_.<xxx>', where '<xxx>' is one of 'jmpfuncs', 'pureconst' 43188 or 'reference') 43189 43190 These sections are used by IPA passes that need to emit summary 43191 information during LTO generation to be read and aggregated at link 43192 time. Each pass is responsible for implementing two pass manager 43193 hooks: one for writing the summary and another for reading it in. 43194 The format of these sections is entirely up to each individual 43195 pass. The only requirement is that the writer and reader hooks 43196 agree on the format. 43197 43198 43199File: gccint.info, Node: IPA, Next: WHOPR, Prev: LTO object file layout, Up: LTO 43200 4320125.3 Using summary information in IPA passes 43202============================================ 43203 43204Programs are represented internally as a _callgraph_ (a multi-graph 43205where nodes are functions and edges are call sites) and a _varpool_ (a 43206list of static and external variables in the program). 43207 43208 The inter-procedural optimization is organized as a sequence of 43209individual passes, which operate on the callgraph and the varpool. To 43210make the implementation of WHOPR possible, every inter-procedural 43211optimization pass is split into several stages that are executed at 43212different times during WHOPR compilation: 43213 43214 * LGEN time 43215 1. _Generate summary_ ('generate_summary' in 'struct 43216 ipa_opt_pass_d'). This stage analyzes every function body and 43217 variable initializer is examined and stores relevant 43218 information into a pass-specific data structure. 43219 43220 2. _Write summary_ ('write_summary' in 'struct ipa_opt_pass_d'). 43221 This stage writes all the pass-specific information generated 43222 by 'generate_summary'. Summaries go into their own 43223 'LTO_section_*' sections that have to be declared in 43224 'lto-streamer.h':'enum lto_section_type'. A new section is 43225 created by calling 'create_output_block' and data can be 43226 written using the 'lto_output_*' routines. 43227 43228 * WPA time 43229 1. _Read summary_ ('read_summary' in 'struct ipa_opt_pass_d'). 43230 This stage reads all the pass-specific information in exactly 43231 the same order that it was written by 'write_summary'. 43232 43233 2. _Execute_ ('execute' in 'struct opt_pass'). This performs 43234 inter-procedural propagation. This must be done without 43235 actual access to the individual function bodies or variable 43236 initializers. Typically, this results in a transitive closure 43237 operation over the summary information of all the nodes in the 43238 callgraph. 43239 43240 3. _Write optimization summary_ ('write_optimization_summary' in 43241 'struct ipa_opt_pass_d'). This writes the result of the 43242 inter-procedural propagation into the object file. This can 43243 use the same data structures and helper routines used in 43244 'write_summary'. 43245 43246 * LTRANS time 43247 1. _Read optimization summary_ ('read_optimization_summary' in 43248 'struct ipa_opt_pass_d'). The counterpart to 43249 'write_optimization_summary'. This reads the interprocedural 43250 optimization decisions in exactly the same format emitted by 43251 'write_optimization_summary'. 43252 43253 2. _Transform_ ('function_transform' and 'variable_transform' in 43254 'struct ipa_opt_pass_d'). The actual function bodies and 43255 variable initializers are updated based on the information 43256 passed down from the _Execute_ stage. 43257 43258 The implementation of the inter-procedural passes are shared between 43259LTO, WHOPR and classic non-LTO compilation. 43260 43261 * During the traditional file-by-file mode every pass executes its 43262 own _Generate summary_, _Execute_, and _Transform_ stages within 43263 the single execution context of the compiler. 43264 43265 * In LTO compilation mode, every pass uses _Generate summary_ and 43266 _Write summary_ stages at compilation time, while the _Read 43267 summary_, _Execute_, and _Transform_ stages are executed at link 43268 time. 43269 43270 * In WHOPR mode all stages are used. 43271 43272 To simplify development, the GCC pass manager differentiates between 43273normal inter-procedural passes and small inter-procedural passes. A 43274_small inter-procedural pass_ ('SIMPLE_IPA_PASS') is a pass that does 43275everything at once and thus it can not be executed during WPA in WHOPR 43276mode. It defines only the _Execute_ stage and during this stage it 43277accesses and modifies the function bodies. Such passes are useful for 43278optimization at LGEN or LTRANS time and are used, for example, to 43279implement early optimization before writing object files. The simple 43280inter-procedural passes can also be used for easier prototyping and 43281development of a new inter-procedural pass. 43282 4328325.3.1 Virtual clones 43284--------------------- 43285 43286One of the main challenges of introducing the WHOPR compilation mode was 43287addressing the interactions between optimization passes. In LTO 43288compilation mode, the passes are executed in a sequence, each of which 43289consists of analysis (or _Generate summary_), propagation (or _Execute_) 43290and _Transform_ stages. Once the work of one pass is finished, the next 43291pass sees the updated program representation and can execute. This 43292makes the individual passes dependent on each other. 43293 43294 In WHOPR mode all passes first execute their _Generate summary_ stage. 43295Then summary writing marks the end of the LGEN stage. At WPA time, the 43296summaries are read back into memory and all passes run the _Execute_ 43297stage. Optimization summaries are streamed and sent to LTRANS, where 43298all the passes execute the _Transform_ stage. 43299 43300 Most optimization passes split naturally into analysis, propagation and 43301transformation stages. But some do not. The main problem arises when 43302one pass performs changes and the following pass gets confused by seeing 43303different callgraphs between the _Transform_ stage and the _Generate 43304summary_ or _Execute_ stage. This means that the passes are required to 43305communicate their decisions with each other. 43306 43307 To facilitate this communication, the GCC callgraph infrastructure 43308implements _virtual clones_, a method of representing the changes 43309performed by the optimization passes in the callgraph without needing to 43310update function bodies. 43311 43312 A _virtual clone_ in the callgraph is a function that has no associated 43313body, just a description of how to create its body based on a different 43314function (which itself may be a virtual clone). 43315 43316 The description of function modifications includes adjustments to the 43317function's signature (which allows, for example, removing or adding 43318function arguments), substitutions to perform on the function body, and, 43319for inlined functions, a pointer to the function that it will be inlined 43320into. 43321 43322 It is also possible to redirect any edge of the callgraph from a 43323function to its virtual clone. This implies updating of the call site 43324to adjust for the new function signature. 43325 43326 Most of the transformations performed by inter-procedural optimizations 43327can be represented via virtual clones. For instance, a constant 43328propagation pass can produce a virtual clone of the function which 43329replaces one of its arguments by a constant. The inliner can represent 43330its decisions by producing a clone of a function whose body will be 43331later integrated into a given function. 43332 43333 Using _virtual clones_, the program can be easily updated during the 43334_Execute_ stage, solving most of pass interactions problems that would 43335otherwise occur during _Transform_. 43336 43337 Virtual clones are later materialized in the LTRANS stage and turned 43338into real functions. Passes executed after the virtual clone were 43339introduced also perform their _Transform_ stage on new functions, so for 43340a pass there is no significant difference between operating on a real 43341function or a virtual clone introduced before its _Execute_ stage. 43342 43343 Optimization passes then work on virtual clones introduced before their 43344_Execute_ stage as if they were real functions. The only difference is 43345that clones are not visible during the _Generate Summary_ stage. 43346 43347 To keep function summaries updated, the callgraph interface allows an 43348optimizer to register a callback that is called every time a new clone 43349is introduced as well as when the actual function or variable is 43350generated or when a function or variable is removed. These hooks are 43351registered in the _Generate summary_ stage and allow the pass to keep 43352its information intact until the _Execute_ stage. The same hooks can 43353also be registered during the _Execute_ stage to keep the optimization 43354summaries updated for the _Transform_ stage. 43355 4335625.3.2 IPA references 43357--------------------- 43358 43359GCC represents IPA references in the callgraph. For a function or 43360variable 'A', the _IPA reference_ is a list of all locations where the 43361address of 'A' is taken and, when 'A' is a variable, a list of all 43362direct stores and reads to/from 'A'. References represent an oriented 43363multi-graph on the union of nodes of the callgraph and the varpool. See 43364'ipa-reference.c':'ipa_reference_write_optimization_summary' and 43365'ipa-reference.c':'ipa_reference_read_optimization_summary' for details. 43366 4336725.3.3 Jump functions 43368--------------------- 43369 43370Suppose that an optimization pass sees a function 'A' and it knows the 43371values of (some of) its arguments. The _jump function_ describes the 43372value of a parameter of a given function call in function 'A' based on 43373this knowledge. 43374 43375 Jump functions are used by several optimizations, such as the 43376inter-procedural constant propagation pass and the devirtualization 43377pass. The inliner also uses jump functions to perform inlining of 43378callbacks. 43379 43380 43381File: gccint.info, Node: WHOPR, Next: Internal flags, Prev: IPA, Up: LTO 43382 4338325.4 Whole program assumptions, linker plugin and symbol visibilities 43384===================================================================== 43385 43386Link-time optimization gives relatively minor benefits when used alone. 43387The problem is that propagation of inter-procedural information does not 43388work well across functions and variables that are called or referenced 43389by other compilation units (such as from a dynamically linked library). 43390We say that such functions and variables are _externally visible_. 43391 43392 To make the situation even more difficult, many applications organize 43393themselves as a set of shared libraries, and the default ELF visibility 43394rules allow one to overwrite any externally visible symbol with a 43395different symbol at runtime. This basically disables any optimizations 43396across such functions and variables, because the compiler cannot be sure 43397that the function body it is seeing is the same function body that will 43398be used at runtime. Any function or variable not declared 'static' in 43399the sources degrades the quality of inter-procedural optimization. 43400 43401 To avoid this problem the compiler must assume that it sees the whole 43402program when doing link-time optimization. Strictly speaking, the whole 43403program is rarely visible even at link-time. Standard system libraries 43404are usually linked dynamically or not provided with the link-time 43405information. In GCC, the whole program option ('-fwhole-program') 43406asserts that every function and variable defined in the current 43407compilation unit is static, except for function 'main' (note: at link 43408time, the current unit is the union of all objects compiled with LTO). 43409Since some functions and variables need to be referenced externally, for 43410example by another DSO or from an assembler file, GCC also provides the 43411function and variable attribute 'externally_visible' which can be used 43412to disable the effect of '-fwhole-program' on a specific symbol. 43413 43414 The whole program mode assumptions are slightly more complex in C++, 43415where inline functions in headers are put into _COMDAT_ sections. 43416COMDAT function and variables can be defined by multiple object files 43417and their bodies are unified at link-time and dynamic link-time. COMDAT 43418functions are changed to local only when their address is not taken and 43419thus un-sharing them with a library is not harmful. COMDAT variables 43420always remain externally visible, however for readonly variables it is 43421assumed that their initializers cannot be overwritten by a different 43422value. 43423 43424 GCC provides the function and variable attribute 'visibility' that can 43425be used to specify the visibility of externally visible symbols (or 43426alternatively an '-fdefault-visibility' command line option). ELF 43427defines the 'default', 'protected', 'hidden' and 'internal' 43428visibilities. 43429 43430 The most commonly used is visibility is 'hidden'. It specifies that 43431the symbol cannot be referenced from outside of the current shared 43432library. Unfortunately, this information cannot be used directly by the 43433link-time optimization in the compiler since the whole shared library 43434also might contain non-LTO objects and those are not visible to the 43435compiler. 43436 43437 GCC solves this problem using linker plugins. A _linker plugin_ is an 43438interface to the linker that allows an external program to claim the 43439ownership of a given object file. The linker then performs the linking 43440procedure by querying the plugin about the symbol table of the claimed 43441objects and once the linking decisions are complete, the plugin is 43442allowed to provide the final object file before the actual linking is 43443made. The linker plugin obtains the symbol resolution information which 43444specifies which symbols provided by the claimed objects are bound from 43445the rest of a binary being linked. 43446 43447 GCC is designed to be independent of the rest of the toolchain and aims 43448to support linkers without plugin support. For this reason it does not 43449use the linker plugin by default. Instead, the object files are 43450examined by 'collect2' before being passed to the linker and objects 43451found to have LTO sections are passed to 'lto1' first. This mode does 43452not work for library archives. The decision on what object files from 43453the archive are needed depends on the actual linking and thus GCC would 43454have to implement the linker itself. The resolution information is 43455missing too and thus GCC needs to make an educated guess based on 43456'-fwhole-program'. Without the linker plugin GCC also assumes that 43457symbols are declared 'hidden' and not referred by non-LTO code by 43458default. 43459 43460 43461File: gccint.info, Node: Internal flags, Prev: WHOPR, Up: LTO 43462 4346325.5 Internal flags controlling 'lto1' 43464====================================== 43465 43466The following flags are passed into 'lto1' and are not meant to be used 43467directly from the command line. 43468 43469 * -fwpa This option runs the serial part of the link-time optimizer 43470 performing the inter-procedural propagation (WPA mode). The 43471 compiler reads in summary information from all inputs and performs 43472 an analysis based on summary information only. It generates object 43473 files for subsequent runs of the link-time optimizer where 43474 individual object files are optimized using both summary 43475 information from the WPA mode and the actual function bodies. It 43476 then drives the LTRANS phase. 43477 43478 * -fltrans This option runs the link-time optimizer in the 43479 local-transformation (LTRANS) mode, which reads in output from a 43480 previous run of the LTO in WPA mode. In the LTRANS mode, LTO 43481 optimizes an object and produces the final assembly. 43482 43483 * -fltrans-output-list=FILE This option specifies a file to which the 43484 names of LTRANS output files are written. This option is only 43485 meaningful in conjunction with '-fwpa'. 43486 43487 * -fresolution=FILE This option specifies the linker resolution file. 43488 This option is only meaningful in conjunction with '-fwpa' and as 43489 option to pass through to the LTO linker plugin. 43490 43491 43492File: gccint.info, Node: Match and Simplify, Next: Funding, Prev: LTO, Up: Top 43493 4349426 Match and Simplify 43495********************* 43496 43497The GIMPLE and GENERIC pattern matching project match-and-simplify tries 43498to address several issues. 43499 43500 1. unify expression simplifications currently spread and duplicated 43501 over separate files like fold-const.c, gimple-fold.c and builtins.c 43502 2. allow for a cheap way to implement building and simplifying 43503 non-trivial GIMPLE expressions, avoiding the need to go through 43504 building and simplifying GENERIC via fold_buildN and then 43505 gimplifying via force_gimple_operand 43506 43507 To address these the project introduces a simple domain specific 43508language to write expression simplifications from which code targeting 43509GIMPLE and GENERIC is auto-generated. The GENERIC variant follows the 43510fold_buildN API while for the GIMPLE variant and to address 2) new APIs 43511are introduced. 43512 43513* Menu: 43514 43515* GIMPLE API:: 43516* The Language:: 43517 43518 43519File: gccint.info, Node: GIMPLE API, Next: The Language, Up: Match and Simplify 43520 4352126.1 GIMPLE API 43522=============== 43523 43524 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 43525 gimple_seq *, tree (*)(tree)) 43526 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 43527 tree, gimple_seq *, tree (*)(tree)) 43528 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 43529 tree, tree, gimple_seq *, tree (*)(tree)) 43530 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 43531 tree, gimple_seq *, tree (*)(tree)) 43532 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 43533 tree, tree, gimple_seq *, tree (*)(tree)) 43534 -- GIMPLE function: tree gimple_simplify (enum built_in_function, tree, 43535 tree, tree, tree, gimple_seq *, tree (*)(tree)) 43536 The main GIMPLE API entry to the expression simplifications 43537 mimicing that of the GENERIC fold_{unary,binary,ternary} functions. 43538 43539 thus providing n-ary overloads for operation or function. The 43540additional arguments are a gimple_seq where built statements are 43541inserted on (if 'NULL' then simplifications requiring new statements are 43542not performed) and a valueization hook that can be used to tie 43543simplifications to a SSA lattice. 43544 43545 In addition to those APIs 'fold_stmt' is overloaded with a valueization 43546hook: 43547 43548 -- bool: fold_stmt (gimple_stmt_iterator *, tree (*)(tree)); 43549 43550 Ontop of these a 'fold_buildN'-like API for GIMPLE is introduced: 43551 43552 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 43553 tree_code, tree, tree, tree (*valueize) (tree) = NULL); 43554 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 43555 tree_code, tree, tree, tree, tree (*valueize) (tree) = NULL); 43556 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 43557 tree_code, tree, tree, tree, tree, tree (*valueize) (tree) = 43558 NULL); 43559 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 43560 built_in_function, tree, tree, tree (*valueize) (tree) = 43561 NULL); 43562 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 43563 built_in_function, tree, tree, tree, tree (*valueize) (tree) = 43564 NULL); 43565 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 43566 built_in_function, tree, tree, tree, tree, tree (*valueize) 43567 (tree) = NULL); 43568 -- GIMPLE function: tree gimple_convert (gimple_seq *, location_t, 43569 tree, tree); 43570 43571 which is supposed to replace 'force_gimple_operand (fold_buildN (...), 43572...)' and calls to 'fold_convert'. Overloads without the 'location_t' 43573argument exist. Built statements are inserted on the provided sequence 43574and simplification is performed using the optional valueization hook. 43575 43576 43577File: gccint.info, Node: The Language, Prev: GIMPLE API, Up: Match and Simplify 43578 4357926.2 The Language 43580================= 43581 43582The language to write expression simplifications in resembles other 43583domain-specific languages GCC uses. Thus it is lispy. Lets start with 43584an example from the match.pd file: 43585 43586 (simplify 43587 (bit_and @0 integer_all_onesp) 43588 @0) 43589 43590 This example contains all required parts of an expression 43591simplification. A simplification is wrapped inside a '(simplify ...)' 43592expression. That contains at least two operands - an expression that is 43593matched with the GIMPLE or GENERIC IL and a replacement expression that 43594is returned if the match was successful. 43595 43596 Expressions have an operator ID, 'bit_and' in this case. Expressions 43597can be lower-case tree codes with '_expr' stripped off or builtin 43598function code names in all-caps, like 'BUILT_IN_SQRT'. 43599 43600 '@n' denotes a so-called capture. It captures the operand and lets you 43601refer to it in other places of the match-and-simplify. In the above 43602example it is refered to in the replacement expression. Captures are 43603'@' followed by a number or an identifier. 43604 43605 (simplify 43606 (bit_xor @0 @0) 43607 { build_zero_cst (type); }) 43608 43609 In this example '@0' is mentioned twice which constrains the matched 43610expression to have two equal operands. Usually matches are constraint 43611to equal types. If operands may be constants and conversions are 43612involved matching by value might be preferred in which case use '@@0' to 43613denote a by value match and the specific operand you want to refer to in 43614the result part. This example also introduces operands written in C 43615code. These can be used in the expression replacements and are supposed 43616to evaluate to a tree node which has to be a valid GIMPLE operand (so 43617you cannot generate expressions in C code). 43618 43619 (simplify 43620 (trunc_mod integer_zerop@0 @1) 43621 (if (!integer_zerop (@1)) 43622 @0)) 43623 43624 Here '@0' captures the first operand of the trunc_mod expression which 43625is also predicated with 'integer_zerop'. Expression operands may be 43626either expressions, predicates or captures. Captures can be 43627unconstrained or capture expresions or predicates. 43628 43629 This example introduces an optional operand of simplify, the 43630if-expression. This condition is evaluated after the expression matched 43631in the IL and is required to evaluate to true to enable the replacement 43632expression in the second operand position. The expression operand of 43633the 'if' is a standard C expression which may contain references to 43634captures. The 'if' has an optional third operand which may contain the 43635replacement expression that is enabled when the condition evaluates to 43636false. 43637 43638 A 'if' expression can be used to specify a common condition for 43639multiple simplify patterns, avoiding the need to repeat that multiple 43640times: 43641 43642 (if (!TYPE_SATURATING (type) 43643 && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) 43644 (simplify 43645 (minus (plus @0 @1) @0) 43646 @1) 43647 (simplify 43648 (minus (minus @0 @1) @0) 43649 (negate @1))) 43650 43651 Note that 'if's in outer position do not have the optional else clause 43652but instead have multiple then clauses. 43653 43654 Ifs can be nested. 43655 43656 There exists a 'switch' expression which can be used to chain 43657conditions avoiding nesting 'if's too much: 43658 43659 (simplify 43660 (simple_comparison @0 REAL_CST@1) 43661 (switch 43662 /* a CMP (-0) -> a CMP 0 */ 43663 (if (REAL_VALUE_MINUS_ZERO (TREE_REAL_CST (@1))) 43664 (cmp @0 { build_real (TREE_TYPE (@1), dconst0); })) 43665 /* x != NaN is always true, other ops are always false. */ 43666 (if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1)) 43667 && ! HONOR_SNANS (@1)) 43668 { constant_boolean_node (cmp == NE_EXPR, type); }))) 43669 43670 Is equal to 43671 43672 (simplify 43673 (simple_comparison @0 REAL_CST@1) 43674 (switch 43675 /* a CMP (-0) -> a CMP 0 */ 43676 (if (REAL_VALUE_MINUS_ZERO (TREE_REAL_CST (@1))) 43677 (cmp @0 { build_real (TREE_TYPE (@1), dconst0); }) 43678 /* x != NaN is always true, other ops are always false. */ 43679 (if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1)) 43680 && ! HONOR_SNANS (@1)) 43681 { constant_boolean_node (cmp == NE_EXPR, type); })))) 43682 43683 which has the second 'if' in the else operand of the first. The 43684'switch' expression takes 'if' expressions as operands (which may not 43685have else clauses) and as a last operand a replacement expression which 43686should be enabled by default if no other condition evaluated to true. 43687 43688 Captures can also be used for capturing results of sub-expressions. 43689 43690 #if GIMPLE 43691 (simplify 43692 (pointer_plus (addr@2 @0) INTEGER_CST_P@1) 43693 (if (is_gimple_min_invariant (@2))) 43694 { 43695 poly_int64 off; 43696 tree base = get_addr_base_and_unit_offset (@0, &off); 43697 off += tree_to_uhwi (@1); 43698 /* Now with that we should be able to simply write 43699 (addr (mem_ref (addr @base) (plus @off @1))) */ 43700 build1 (ADDR_EXPR, type, 43701 build2 (MEM_REF, TREE_TYPE (TREE_TYPE (@2)), 43702 build_fold_addr_expr (base), 43703 build_int_cst (ptr_type_node, off))); 43704 }) 43705 #endif 43706 43707 In the above example, '@2' captures the result of the expression '(addr 43708@0)'. For outermost expression only its type can be captured, and the 43709keyword 'type' is reserved for this purpose. The above example also 43710gives a way to conditionalize patterns to only apply to 'GIMPLE' or 43711'GENERIC' by means of using the pre-defined preprocessor macros 'GIMPLE' 43712and 'GENERIC' and using preprocessor directives. 43713 43714 (simplify 43715 (bit_and:c integral_op_p@0 (bit_ior:c (bit_not @0) @1)) 43716 (bit_and @1 @0)) 43717 43718 Here we introduce flags on match expressions. The flag used above, 43719'c', denotes that the expression should be also matched commutated. 43720Thus the above match expression is really the following four match 43721expressions: 43722 43723 (bit_and integral_op_p@0 (bit_ior (bit_not @0) @1)) 43724 (bit_and (bit_ior (bit_not @0) @1) integral_op_p@0) 43725 (bit_and integral_op_p@0 (bit_ior @1 (bit_not @0))) 43726 (bit_and (bit_ior @1 (bit_not @0)) integral_op_p@0) 43727 43728 Usual canonicalizations you know from GENERIC expressions are applied 43729before matching, so for example constant operands always come second in 43730commutative expressions. 43731 43732 The second supported flag is 's' which tells the code generator to fail 43733the pattern if the expression marked with 's' does have more than one 43734use. For example in 43735 43736 (simplify 43737 (pointer_plus (pointer_plus:s @0 @1) @3) 43738 (pointer_plus @0 (plus @1 @3))) 43739 43740 this avoids the association if '(pointer_plus @0 @1)' is used outside 43741of the matched expression and thus it would stay live and not trivially 43742removed by dead code elimination. 43743 43744 More features exist to avoid too much repetition. 43745 43746 (for op (plus pointer_plus minus bit_ior bit_xor) 43747 (simplify 43748 (op @0 integer_zerop) 43749 @0)) 43750 43751 A 'for' expression can be used to repeat a pattern for each operator 43752specified, substituting 'op'. 'for' can be nested and a 'for' can have 43753multiple operators to iterate. 43754 43755 (for opa (plus minus) 43756 opb (minus plus) 43757 (for opc (plus minus) 43758 (simplify... 43759 43760 In this example the pattern will be repeated four times with 'opa, opb, 43761opc' being 'plus, minus, plus', 'plus, minus, minus', 'minus, plus, 43762plus', 'minus, plus, minus'. 43763 43764 To avoid repeating operator lists in 'for' you can name them via 43765 43766 (define_operator_list pmm plus minus mult) 43767 43768 and use them in 'for' operator lists where they get expanded. 43769 43770 (for opa (pmm trunc_div) 43771 (simplify... 43772 43773 So this example iterates over 'plus', 'minus', 'mult' and 'trunc_div'. 43774 43775 Using operator lists can also remove the need to explicitely write a 43776'for'. All operator list uses that appear in a 'simplify' or 'match' 43777pattern in operator positions will implicitely be added to a new 'for'. 43778For example 43779 43780 (define_operator_list SQRT BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL) 43781 (define_operator_list POW BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL) 43782 (simplify 43783 (SQRT (POW @0 @1)) 43784 (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); }))) 43785 43786 is the same as 43787 43788 (for SQRT (BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL) 43789 POW (BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL) 43790 (simplify 43791 (SQRT (POW @0 @1)) 43792 (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); })))) 43793 43794 'for's and operator lists can include the special identifier 'null' 43795that matches nothing and can never be generated. This can be used to 43796pad an operator list so that it has a standard form, even if there isn't 43797a suitable operator for every form. 43798 43799 Another building block are 'with' expressions in the result expression 43800which nest the generated code in a new C block followed by its argument: 43801 43802 (simplify 43803 (convert (mult @0 @1)) 43804 (with { tree utype = unsigned_type_for (type); } 43805 (convert (mult (convert:utype @0) (convert:utype @1))))) 43806 43807 This allows code nested in the 'with' to refer to the declared 43808variables. In the above case we use the feature to specify the type of 43809a generated expression with the ':type' syntax where 'type' needs to be 43810an identifier that refers to the desired type. Usually the types of the 43811generated result expressions are determined from the context, but 43812sometimes like in the above case it is required that you specify them 43813explicitely. 43814 43815 As intermediate conversions are often optional there is a way to avoid 43816the need to repeat patterns both with and without such conversions. 43817Namely you can mark a conversion as being optional with a '?': 43818 43819 (simplify 43820 (eq (convert@0 @1) (convert? @2)) 43821 (eq @1 (convert @2))) 43822 43823 which will match both '(eq (convert @1) (convert @2))' and '(eq 43824(convert @1) @2)'. The optional converts are supposed to be all either 43825present or not, thus '(eq (convert? @1) (convert? @2))' will result in 43826two patterns only. If you want to match all four combinations you have 43827access to two additional conditional converts as in '(eq (convert1? @1) 43828(convert2? @2))'. 43829 43830 Predicates available from the GCC middle-end need to be made available 43831explicitely via 'define_predicates': 43832 43833 (define_predicates 43834 integer_onep integer_zerop integer_all_onesp) 43835 43836 You can also define predicates using the pattern matching language and 43837the 'match' form: 43838 43839 (match negate_expr_p 43840 INTEGER_CST 43841 (if (TYPE_OVERFLOW_WRAPS (type) 43842 || may_negate_without_overflow_p (t)))) 43843 (match negate_expr_p 43844 (negate @0)) 43845 43846 This shows that for 'match' expressions there is 't' available which 43847captures the outermost expression (something not possible in the 43848'simplify' context). As you can see 'match' has an identifier as first 43849operand which is how you refer to the predicate in patterns. Multiple 43850'match' for the same identifier add additional cases where the predicate 43851matches. 43852 43853 Predicates can also match an expression in which case you need to 43854provide a template specifying the identifier and where to get its 43855operands from: 43856 43857 (match (logical_inverted_value @0) 43858 (eq @0 integer_zerop)) 43859 (match (logical_inverted_value @0) 43860 (bit_not truth_valued_p@0)) 43861 43862 You can use the above predicate like 43863 43864 (simplify 43865 (bit_and @0 (logical_inverted_value @0)) 43866 { build_zero_cst (type); }) 43867 43868 Which will match a bitwise and of an operand with its logical inverted 43869value. 43870 43871 43872File: gccint.info, Node: Funding, Next: GNU Project, Prev: Match and Simplify, Up: Top 43873 43874Funding Free Software 43875********************* 43876 43877If you want to have more free software a few years from now, it makes 43878sense for you to help encourage people to contribute funds for its 43879development. The most effective approach known is to encourage 43880commercial redistributors to donate. 43881 43882 Users of free software systems can boost the pace of development by 43883encouraging for-a-fee distributors to donate part of their selling price 43884to free software developers--the Free Software Foundation, and others. 43885 43886 The way to convince distributors to do this is to demand it and expect 43887it from them. So when you compare distributors, judge them partly by 43888how much they give to free software development. Show distributors they 43889must compete to be the one who gives the most. 43890 43891 To make this approach work, you must insist on numbers that you can 43892compare, such as, "We will donate ten dollars to the Frobnitz project 43893for each disk sold." Don't be satisfied with a vague promise, such as 43894"A portion of the profits are donated," since it doesn't give a basis 43895for comparison. 43896 43897 Even a precise fraction "of the profits from this disk" is not very 43898meaningful, since creative accounting and unrelated business decisions 43899can greatly alter what fraction of the sales price counts as profit. If 43900the price you pay is $50, ten percent of the profit is probably less 43901than a dollar; it might be a few cents, or nothing at all. 43902 43903 Some redistributors do development work themselves. This is useful 43904too; but to keep everyone honest, you need to inquire how much they do, 43905and what kind. Some kinds of development make much more long-term 43906difference than others. For example, maintaining a separate version of 43907a program contributes very little; maintaining the standard version of a 43908program for the whole community contributes much. Easy new ports 43909contribute little, since someone else would surely do them; difficult 43910ports such as adding a new CPU to the GNU Compiler Collection contribute 43911more; major new features or packages contribute the most. 43912 43913 By establishing the idea that supporting further development is "the 43914proper thing to do" when distributing free software for a fee, we can 43915assure a steady flow of resources into making more free software. 43916 43917 Copyright (C) 1994 Free Software Foundation, Inc. 43918 Verbatim copying and redistribution of this section is permitted 43919 without royalty; alteration is not permitted. 43920 43921 43922File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top 43923 43924The GNU Project and GNU/Linux 43925***************************** 43926 43927The GNU Project was launched in 1984 to develop a complete Unix-like 43928operating system which is free software: the GNU system. (GNU is a 43929recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".) 43930Variants of the GNU operating system, which use the kernel Linux, are 43931now widely used; though these systems are often referred to as "Linux", 43932they are more accurately called GNU/Linux systems. 43933 43934 For more information, see: 43935 <http://www.gnu.org/> 43936 <http://www.gnu.org/gnu/linux-and-gnu.html> 43937 43938 43939File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top 43940 43941GNU General Public License 43942************************** 43943 43944 Version 3, 29 June 2007 43945 43946 Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/> 43947 43948 Everyone is permitted to copy and distribute verbatim copies of this 43949 license document, but changing it is not allowed. 43950 43951Preamble 43952======== 43953 43954The GNU General Public License is a free, copyleft license for software 43955and other kinds of works. 43956 43957 The licenses for most software and other practical works are designed 43958to take away your freedom to share and change the works. By contrast, 43959the GNU General Public License is intended to guarantee your freedom to 43960share and change all versions of a program-to make sure it remains free 43961software for all its users. We, the Free Software Foundation, use the 43962GNU General Public License for most of our software; it applies also to 43963any other work released this way by its authors. You can apply it to 43964your programs, too. 43965 43966 When we speak of free software, we are referring to freedom, not price. 43967Our General Public Licenses are designed to make sure that you have the 43968freedom to distribute copies of free software (and charge for them if 43969you wish), that you receive source code or can get it if you want it, 43970that you can change the software or use pieces of it in new free 43971programs, and that you know you can do these things. 43972 43973 To protect your rights, we need to prevent others from denying you 43974these rights or asking you to surrender the rights. Therefore, you have 43975certain responsibilities if you distribute copies of the software, or if 43976you modify it: responsibilities to respect the freedom of others. 43977 43978 For example, if you distribute copies of such a program, whether gratis 43979or for a fee, you must pass on to the recipients the same freedoms that 43980you received. You must make sure that they, too, receive or can get the 43981source code. And you must show them these terms so they know their 43982rights. 43983 43984 Developers that use the GNU GPL protect your rights with two steps: (1) 43985assert copyright on the software, and (2) offer you this License giving 43986you legal permission to copy, distribute and/or modify it. 43987 43988 For the developers' and authors' protection, the GPL clearly explains 43989that there is no warranty for this free software. For both users' and 43990authors' sake, the GPL requires that modified versions be marked as 43991changed, so that their problems will not be attributed erroneously to 43992authors of previous versions. 43993 43994 Some devices are designed to deny users access to install or run 43995modified versions of the software inside them, although the manufacturer 43996can do so. This is fundamentally incompatible with the aim of 43997protecting users' freedom to change the software. The systematic 43998pattern of such abuse occurs in the area of products for individuals to 43999use, which is precisely where it is most unacceptable. Therefore, we 44000have designed this version of the GPL to prohibit the practice for those 44001products. If such problems arise substantially in other domains, we 44002stand ready to extend this provision to those domains in future versions 44003of the GPL, as needed to protect the freedom of users. 44004 44005 Finally, every program is threatened constantly by software patents. 44006States should not allow patents to restrict development and use of 44007software on general-purpose computers, but in those that do, we wish to 44008avoid the special danger that patents applied to a free program could 44009make it effectively proprietary. To prevent this, the GPL assures that 44010patents cannot be used to render the program non-free. 44011 44012 The precise terms and conditions for copying, distribution and 44013modification follow. 44014 44015TERMS AND CONDITIONS 44016==================== 44017 44018 0. Definitions. 44019 44020 "This License" refers to version 3 of the GNU General Public 44021 License. 44022 44023 "Copyright" also means copyright-like laws that apply to other 44024 kinds of works, such as semiconductor masks. 44025 44026 "The Program" refers to any copyrightable work licensed under this 44027 License. Each licensee is addressed as "you". "Licensees" and 44028 "recipients" may be individuals or organizations. 44029 44030 To "modify" a work means to copy from or adapt all or part of the 44031 work in a fashion requiring copyright permission, other than the 44032 making of an exact copy. The resulting work is called a "modified 44033 version" of the earlier work or a work "based on" the earlier work. 44034 44035 A "covered work" means either the unmodified Program or a work 44036 based on the Program. 44037 44038 To "propagate" a work means to do anything with it that, without 44039 permission, would make you directly or secondarily liable for 44040 infringement under applicable copyright law, except executing it on 44041 a computer or modifying a private copy. Propagation includes 44042 copying, distribution (with or without modification), making 44043 available to the public, and in some countries other activities as 44044 well. 44045 44046 To "convey" a work means any kind of propagation that enables other 44047 parties to make or receive copies. Mere interaction with a user 44048 through a computer network, with no transfer of a copy, is not 44049 conveying. 44050 44051 An interactive user interface displays "Appropriate Legal Notices" 44052 to the extent that it includes a convenient and prominently visible 44053 feature that (1) displays an appropriate copyright notice, and (2) 44054 tells the user that there is no warranty for the work (except to 44055 the extent that warranties are provided), that licensees may convey 44056 the work under this License, and how to view a copy of this 44057 License. If the interface presents a list of user commands or 44058 options, such as a menu, a prominent item in the list meets this 44059 criterion. 44060 44061 1. Source Code. 44062 44063 The "source code" for a work means the preferred form of the work 44064 for making modifications to it. "Object code" means any non-source 44065 form of a work. 44066 44067 A "Standard Interface" means an interface that either is an 44068 official standard defined by a recognized standards body, or, in 44069 the case of interfaces specified for a particular programming 44070 language, one that is widely used among developers working in that 44071 language. 44072 44073 The "System Libraries" of an executable work include anything, 44074 other than the work as a whole, that (a) is included in the normal 44075 form of packaging a Major Component, but which is not part of that 44076 Major Component, and (b) serves only to enable use of the work with 44077 that Major Component, or to implement a Standard Interface for 44078 which an implementation is available to the public in source code 44079 form. A "Major Component", in this context, means a major 44080 essential component (kernel, window system, and so on) of the 44081 specific operating system (if any) on which the executable work 44082 runs, or a compiler used to produce the work, or an object code 44083 interpreter used to run it. 44084 44085 The "Corresponding Source" for a work in object code form means all 44086 the source code needed to generate, install, and (for an executable 44087 work) run the object code and to modify the work, including scripts 44088 to control those activities. However, it does not include the 44089 work's System Libraries, or general-purpose tools or generally 44090 available free programs which are used unmodified in performing 44091 those activities but which are not part of the work. For example, 44092 Corresponding Source includes interface definition files associated 44093 with source files for the work, and the source code for shared 44094 libraries and dynamically linked subprograms that the work is 44095 specifically designed to require, such as by intimate data 44096 communication or control flow between those subprograms and other 44097 parts of the work. 44098 44099 The Corresponding Source need not include anything that users can 44100 regenerate automatically from other parts of the Corresponding 44101 Source. 44102 44103 The Corresponding Source for a work in source code form is that 44104 same work. 44105 44106 2. Basic Permissions. 44107 44108 All rights granted under this License are granted for the term of 44109 copyright on the Program, and are irrevocable provided the stated 44110 conditions are met. This License explicitly affirms your unlimited 44111 permission to run the unmodified Program. The output from running 44112 a covered work is covered by this License only if the output, given 44113 its content, constitutes a covered work. This License acknowledges 44114 your rights of fair use or other equivalent, as provided by 44115 copyright law. 44116 44117 You may make, run and propagate covered works that you do not 44118 convey, without conditions so long as your license otherwise 44119 remains in force. You may convey covered works to others for the 44120 sole purpose of having them make modifications exclusively for you, 44121 or provide you with facilities for running those works, provided 44122 that you comply with the terms of this License in conveying all 44123 material for which you do not control copyright. Those thus making 44124 or running the covered works for you must do so exclusively on your 44125 behalf, under your direction and control, on terms that prohibit 44126 them from making any copies of your copyrighted material outside 44127 their relationship with you. 44128 44129 Conveying under any other circumstances is permitted solely under 44130 the conditions stated below. Sublicensing is not allowed; section 44131 10 makes it unnecessary. 44132 44133 3. Protecting Users' Legal Rights From Anti-Circumvention Law. 44134 44135 No covered work shall be deemed part of an effective technological 44136 measure under any applicable law fulfilling obligations under 44137 article 11 of the WIPO copyright treaty adopted on 20 December 44138 1996, or similar laws prohibiting or restricting circumvention of 44139 such measures. 44140 44141 When you convey a covered work, you waive any legal power to forbid 44142 circumvention of technological measures to the extent such 44143 circumvention is effected by exercising rights under this License 44144 with respect to the covered work, and you disclaim any intention to 44145 limit operation or modification of the work as a means of 44146 enforcing, against the work's users, your or third parties' legal 44147 rights to forbid circumvention of technological measures. 44148 44149 4. Conveying Verbatim Copies. 44150 44151 You may convey verbatim copies of the Program's source code as you 44152 receive it, in any medium, provided that you conspicuously and 44153 appropriately publish on each copy an appropriate copyright notice; 44154 keep intact all notices stating that this License and any 44155 non-permissive terms added in accord with section 7 apply to the 44156 code; keep intact all notices of the absence of any warranty; and 44157 give all recipients a copy of this License along with the Program. 44158 44159 You may charge any price or no price for each copy that you convey, 44160 and you may offer support or warranty protection for a fee. 44161 44162 5. Conveying Modified Source Versions. 44163 44164 You may convey a work based on the Program, or the modifications to 44165 produce it from the Program, in the form of source code under the 44166 terms of section 4, provided that you also meet all of these 44167 conditions: 44168 44169 a. The work must carry prominent notices stating that you 44170 modified it, and giving a relevant date. 44171 44172 b. The work must carry prominent notices stating that it is 44173 released under this License and any conditions added under 44174 section 7. This requirement modifies the requirement in 44175 section 4 to "keep intact all notices". 44176 44177 c. You must license the entire work, as a whole, under this 44178 License to anyone who comes into possession of a copy. This 44179 License will therefore apply, along with any applicable 44180 section 7 additional terms, to the whole of the work, and all 44181 its parts, regardless of how they are packaged. This License 44182 gives no permission to license the work in any other way, but 44183 it does not invalidate such permission if you have separately 44184 received it. 44185 44186 d. If the work has interactive user interfaces, each must display 44187 Appropriate Legal Notices; however, if the Program has 44188 interactive interfaces that do not display Appropriate Legal 44189 Notices, your work need not make them do so. 44190 44191 A compilation of a covered work with other separate and independent 44192 works, which are not by their nature extensions of the covered 44193 work, and which are not combined with it such as to form a larger 44194 program, in or on a volume of a storage or distribution medium, is 44195 called an "aggregate" if the compilation and its resulting 44196 copyright are not used to limit the access or legal rights of the 44197 compilation's users beyond what the individual works permit. 44198 Inclusion of a covered work in an aggregate does not cause this 44199 License to apply to the other parts of the aggregate. 44200 44201 6. Conveying Non-Source Forms. 44202 44203 You may convey a covered work in object code form under the terms 44204 of sections 4 and 5, provided that you also convey the 44205 machine-readable Corresponding Source under the terms of this 44206 License, in one of these ways: 44207 44208 a. Convey the object code in, or embodied in, a physical product 44209 (including a physical distribution medium), accompanied by the 44210 Corresponding Source fixed on a durable physical medium 44211 customarily used for software interchange. 44212 44213 b. Convey the object code in, or embodied in, a physical product 44214 (including a physical distribution medium), accompanied by a 44215 written offer, valid for at least three years and valid for as 44216 long as you offer spare parts or customer support for that 44217 product model, to give anyone who possesses the object code 44218 either (1) a copy of the Corresponding Source for all the 44219 software in the product that is covered by this License, on a 44220 durable physical medium customarily used for software 44221 interchange, for a price no more than your reasonable cost of 44222 physically performing this conveying of source, or (2) access 44223 to copy the Corresponding Source from a network server at no 44224 charge. 44225 44226 c. Convey individual copies of the object code with a copy of the 44227 written offer to provide the Corresponding Source. This 44228 alternative is allowed only occasionally and noncommercially, 44229 and only if you received the object code with such an offer, 44230 in accord with subsection 6b. 44231 44232 d. Convey the object code by offering access from a designated 44233 place (gratis or for a charge), and offer equivalent access to 44234 the Corresponding Source in the same way through the same 44235 place at no further charge. You need not require recipients 44236 to copy the Corresponding Source along with the object code. 44237 If the place to copy the object code is a network server, the 44238 Corresponding Source may be on a different server (operated by 44239 you or a third party) that supports equivalent copying 44240 facilities, provided you maintain clear directions next to the 44241 object code saying where to find the Corresponding Source. 44242 Regardless of what server hosts the Corresponding Source, you 44243 remain obligated to ensure that it is available for as long as 44244 needed to satisfy these requirements. 44245 44246 e. Convey the object code using peer-to-peer transmission, 44247 provided you inform other peers where the object code and 44248 Corresponding Source of the work are being offered to the 44249 general public at no charge under subsection 6d. 44250 44251 A separable portion of the object code, whose source code is 44252 excluded from the Corresponding Source as a System Library, need 44253 not be included in conveying the object code work. 44254 44255 A "User Product" is either (1) a "consumer product", which means 44256 any tangible personal property which is normally used for personal, 44257 family, or household purposes, or (2) anything designed or sold for 44258 incorporation into a dwelling. In determining whether a product is 44259 a consumer product, doubtful cases shall be resolved in favor of 44260 coverage. For a particular product received by a particular user, 44261 "normally used" refers to a typical or common use of that class of 44262 product, regardless of the status of the particular user or of the 44263 way in which the particular user actually uses, or expects or is 44264 expected to use, the product. A product is a consumer product 44265 regardless of whether the product has substantial commercial, 44266 industrial or non-consumer uses, unless such uses represent the 44267 only significant mode of use of the product. 44268 44269 "Installation Information" for a User Product means any methods, 44270 procedures, authorization keys, or other information required to 44271 install and execute modified versions of a covered work in that 44272 User Product from a modified version of its Corresponding Source. 44273 The information must suffice to ensure that the continued 44274 functioning of the modified object code is in no case prevented or 44275 interfered with solely because modification has been made. 44276 44277 If you convey an object code work under this section in, or with, 44278 or specifically for use in, a User Product, and the conveying 44279 occurs as part of a transaction in which the right of possession 44280 and use of the User Product is transferred to the recipient in 44281 perpetuity or for a fixed term (regardless of how the transaction 44282 is characterized), the Corresponding Source conveyed under this 44283 section must be accompanied by the Installation Information. But 44284 this requirement does not apply if neither you nor any third party 44285 retains the ability to install modified object code on the User 44286 Product (for example, the work has been installed in ROM). 44287 44288 The requirement to provide Installation Information does not 44289 include a requirement to continue to provide support service, 44290 warranty, or updates for a work that has been modified or installed 44291 by the recipient, or for the User Product in which it has been 44292 modified or installed. Access to a network may be denied when the 44293 modification itself materially and adversely affects the operation 44294 of the network or violates the rules and protocols for 44295 communication across the network. 44296 44297 Corresponding Source conveyed, and Installation Information 44298 provided, in accord with this section must be in a format that is 44299 publicly documented (and with an implementation available to the 44300 public in source code form), and must require no special password 44301 or key for unpacking, reading or copying. 44302 44303 7. Additional Terms. 44304 44305 "Additional permissions" are terms that supplement the terms of 44306 this License by making exceptions from one or more of its 44307 conditions. Additional permissions that are applicable to the 44308 entire Program shall be treated as though they were included in 44309 this License, to the extent that they are valid under applicable 44310 law. If additional permissions apply only to part of the Program, 44311 that part may be used separately under those permissions, but the 44312 entire Program remains governed by this License without regard to 44313 the additional permissions. 44314 44315 When you convey a copy of a covered work, you may at your option 44316 remove any additional permissions from that copy, or from any part 44317 of it. (Additional permissions may be written to require their own 44318 removal in certain cases when you modify the work.) You may place 44319 additional permissions on material, added by you to a covered work, 44320 for which you have or can give appropriate copyright permission. 44321 44322 Notwithstanding any other provision of this License, for material 44323 you add to a covered work, you may (if authorized by the copyright 44324 holders of that material) supplement the terms of this License with 44325 terms: 44326 44327 a. Disclaiming warranty or limiting liability differently from 44328 the terms of sections 15 and 16 of this License; or 44329 44330 b. Requiring preservation of specified reasonable legal notices 44331 or author attributions in that material or in the Appropriate 44332 Legal Notices displayed by works containing it; or 44333 44334 c. Prohibiting misrepresentation of the origin of that material, 44335 or requiring that modified versions of such material be marked 44336 in reasonable ways as different from the original version; or 44337 44338 d. Limiting the use for publicity purposes of names of licensors 44339 or authors of the material; or 44340 44341 e. Declining to grant rights under trademark law for use of some 44342 trade names, trademarks, or service marks; or 44343 44344 f. Requiring indemnification of licensors and authors of that 44345 material by anyone who conveys the material (or modified 44346 versions of it) with contractual assumptions of liability to 44347 the recipient, for any liability that these contractual 44348 assumptions directly impose on those licensors and authors. 44349 44350 All other non-permissive additional terms are considered "further 44351 restrictions" within the meaning of section 10. If the Program as 44352 you received it, or any part of it, contains a notice stating that 44353 it is governed by this License along with a term that is a further 44354 restriction, you may remove that term. If a license document 44355 contains a further restriction but permits relicensing or conveying 44356 under this License, you may add to a covered work material governed 44357 by the terms of that license document, provided that the further 44358 restriction does not survive such relicensing or conveying. 44359 44360 If you add terms to a covered work in accord with this section, you 44361 must place, in the relevant source files, a statement of the 44362 additional terms that apply to those files, or a notice indicating 44363 where to find the applicable terms. 44364 44365 Additional terms, permissive or non-permissive, may be stated in 44366 the form of a separately written license, or stated as exceptions; 44367 the above requirements apply either way. 44368 44369 8. Termination. 44370 44371 You may not propagate or modify a covered work except as expressly 44372 provided under this License. Any attempt otherwise to propagate or 44373 modify it is void, and will automatically terminate your rights 44374 under this License (including any patent licenses granted under the 44375 third paragraph of section 11). 44376 44377 However, if you cease all violation of this License, then your 44378 license from a particular copyright holder is reinstated (a) 44379 provisionally, unless and until the copyright holder explicitly and 44380 finally terminates your license, and (b) permanently, if the 44381 copyright holder fails to notify you of the violation by some 44382 reasonable means prior to 60 days after the cessation. 44383 44384 Moreover, your license from a particular copyright holder is 44385 reinstated permanently if the copyright holder notifies you of the 44386 violation by some reasonable means, this is the first time you have 44387 received notice of violation of this License (for any work) from 44388 that copyright holder, and you cure the violation prior to 30 days 44389 after your receipt of the notice. 44390 44391 Termination of your rights under this section does not terminate 44392 the licenses of parties who have received copies or rights from you 44393 under this License. If your rights have been terminated and not 44394 permanently reinstated, you do not qualify to receive new licenses 44395 for the same material under section 10. 44396 44397 9. Acceptance Not Required for Having Copies. 44398 44399 You are not required to accept this License in order to receive or 44400 run a copy of the Program. Ancillary propagation of a covered work 44401 occurring solely as a consequence of using peer-to-peer 44402 transmission to receive a copy likewise does not require 44403 acceptance. However, nothing other than this License grants you 44404 permission to propagate or modify any covered work. These actions 44405 infringe copyright if you do not accept this License. Therefore, 44406 by modifying or propagating a covered work, you indicate your 44407 acceptance of this License to do so. 44408 44409 10. Automatic Licensing of Downstream Recipients. 44410 44411 Each time you convey a covered work, the recipient automatically 44412 receives a license from the original licensors, to run, modify and 44413 propagate that work, subject to this License. You are not 44414 responsible for enforcing compliance by third parties with this 44415 License. 44416 44417 An "entity transaction" is a transaction transferring control of an 44418 organization, or substantially all assets of one, or subdividing an 44419 organization, or merging organizations. If propagation of a 44420 covered work results from an entity transaction, each party to that 44421 transaction who receives a copy of the work also receives whatever 44422 licenses to the work the party's predecessor in interest had or 44423 could give under the previous paragraph, plus a right to possession 44424 of the Corresponding Source of the work from the predecessor in 44425 interest, if the predecessor has it or can get it with reasonable 44426 efforts. 44427 44428 You may not impose any further restrictions on the exercise of the 44429 rights granted or affirmed under this License. For example, you 44430 may not impose a license fee, royalty, or other charge for exercise 44431 of rights granted under this License, and you may not initiate 44432 litigation (including a cross-claim or counterclaim in a lawsuit) 44433 alleging that any patent claim is infringed by making, using, 44434 selling, offering for sale, or importing the Program or any portion 44435 of it. 44436 44437 11. Patents. 44438 44439 A "contributor" is a copyright holder who authorizes use under this 44440 License of the Program or a work on which the Program is based. 44441 The work thus licensed is called the contributor's "contributor 44442 version". 44443 44444 A contributor's "essential patent claims" are all patent claims 44445 owned or controlled by the contributor, whether already acquired or 44446 hereafter acquired, that would be infringed by some manner, 44447 permitted by this License, of making, using, or selling its 44448 contributor version, but do not include claims that would be 44449 infringed only as a consequence of further modification of the 44450 contributor version. For purposes of this definition, "control" 44451 includes the right to grant patent sublicenses in a manner 44452 consistent with the requirements of this License. 44453 44454 Each contributor grants you a non-exclusive, worldwide, 44455 royalty-free patent license under the contributor's essential 44456 patent claims, to make, use, sell, offer for sale, import and 44457 otherwise run, modify and propagate the contents of its contributor 44458 version. 44459 44460 In the following three paragraphs, a "patent license" is any 44461 express agreement or commitment, however denominated, not to 44462 enforce a patent (such as an express permission to practice a 44463 patent or covenant not to sue for patent infringement). To "grant" 44464 such a patent license to a party means to make such an agreement or 44465 commitment not to enforce a patent against the party. 44466 44467 If you convey a covered work, knowingly relying on a patent 44468 license, and the Corresponding Source of the work is not available 44469 for anyone to copy, free of charge and under the terms of this 44470 License, through a publicly available network server or other 44471 readily accessible means, then you must either (1) cause the 44472 Corresponding Source to be so available, or (2) arrange to deprive 44473 yourself of the benefit of the patent license for this particular 44474 work, or (3) arrange, in a manner consistent with the requirements 44475 of this License, to extend the patent license to downstream 44476 recipients. "Knowingly relying" means you have actual knowledge 44477 that, but for the patent license, your conveying the covered work 44478 in a country, or your recipient's use of the covered work in a 44479 country, would infringe one or more identifiable patents in that 44480 country that you have reason to believe are valid. 44481 44482 If, pursuant to or in connection with a single transaction or 44483 arrangement, you convey, or propagate by procuring conveyance of, a 44484 covered work, and grant a patent license to some of the parties 44485 receiving the covered work authorizing them to use, propagate, 44486 modify or convey a specific copy of the covered work, then the 44487 patent license you grant is automatically extended to all 44488 recipients of the covered work and works based on it. 44489 44490 A patent license is "discriminatory" if it does not include within 44491 the scope of its coverage, prohibits the exercise of, or is 44492 conditioned on the non-exercise of one or more of the rights that 44493 are specifically granted under this License. You may not convey a 44494 covered work if you are a party to an arrangement with a third 44495 party that is in the business of distributing software, under which 44496 you make payment to the third party based on the extent of your 44497 activity of conveying the work, and under which the third party 44498 grants, to any of the parties who would receive the covered work 44499 from you, a discriminatory patent license (a) in connection with 44500 copies of the covered work conveyed by you (or copies made from 44501 those copies), or (b) primarily for and in connection with specific 44502 products or compilations that contain the covered work, unless you 44503 entered into that arrangement, or that patent license was granted, 44504 prior to 28 March 2007. 44505 44506 Nothing in this License shall be construed as excluding or limiting 44507 any implied license or other defenses to infringement that may 44508 otherwise be available to you under applicable patent law. 44509 44510 12. No Surrender of Others' Freedom. 44511 44512 If conditions are imposed on you (whether by court order, agreement 44513 or otherwise) that contradict the conditions of this License, they 44514 do not excuse you from the conditions of this License. If you 44515 cannot convey a covered work so as to satisfy simultaneously your 44516 obligations under this License and any other pertinent obligations, 44517 then as a consequence you may not convey it at all. For example, 44518 if you agree to terms that obligate you to collect a royalty for 44519 further conveying from those to whom you convey the Program, the 44520 only way you could satisfy both those terms and this License would 44521 be to refrain entirely from conveying the Program. 44522 44523 13. Use with the GNU Affero General Public License. 44524 44525 Notwithstanding any other provision of this License, you have 44526 permission to link or combine any covered work with a work licensed 44527 under version 3 of the GNU Affero General Public License into a 44528 single combined work, and to convey the resulting work. The terms 44529 of this License will continue to apply to the part which is the 44530 covered work, but the special requirements of the GNU Affero 44531 General Public License, section 13, concerning interaction through 44532 a network will apply to the combination as such. 44533 44534 14. Revised Versions of this License. 44535 44536 The Free Software Foundation may publish revised and/or new 44537 versions of the GNU General Public License from time to time. Such 44538 new versions will be similar in spirit to the present version, but 44539 may differ in detail to address new problems or concerns. 44540 44541 Each version is given a distinguishing version number. If the 44542 Program specifies that a certain numbered version of the GNU 44543 General Public License "or any later version" applies to it, you 44544 have the option of following the terms and conditions either of 44545 that numbered version or of any later version published by the Free 44546 Software Foundation. If the Program does not specify a version 44547 number of the GNU General Public License, you may choose any 44548 version ever published by the Free Software Foundation. 44549 44550 If the Program specifies that a proxy can decide which future 44551 versions of the GNU General Public License can be used, that 44552 proxy's public statement of acceptance of a version permanently 44553 authorizes you to choose that version for the Program. 44554 44555 Later license versions may give you additional or different 44556 permissions. However, no additional obligations are imposed on any 44557 author or copyright holder as a result of your choosing to follow a 44558 later version. 44559 44560 15. Disclaimer of Warranty. 44561 44562 THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY 44563 APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE 44564 COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" 44565 WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, 44566 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 44567 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE 44568 RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. 44569 SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL 44570 NECESSARY SERVICING, REPAIR OR CORRECTION. 44571 44572 16. Limitation of Liability. 44573 44574 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN 44575 WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES 44576 AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR 44577 DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR 44578 CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE 44579 THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA 44580 BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD 44581 PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER 44582 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF 44583 THE POSSIBILITY OF SUCH DAMAGES. 44584 44585 17. Interpretation of Sections 15 and 16. 44586 44587 If the disclaimer of warranty and limitation of liability provided 44588 above cannot be given local legal effect according to their terms, 44589 reviewing courts shall apply local law that most closely 44590 approximates an absolute waiver of all civil liability in 44591 connection with the Program, unless a warranty or assumption of 44592 liability accompanies a copy of the Program in return for a fee. 44593 44594END OF TERMS AND CONDITIONS 44595=========================== 44596 44597How to Apply These Terms to Your New Programs 44598============================================= 44599 44600If you develop a new program, and you want it to be of the greatest 44601possible use to the public, the best way to achieve this is to make it 44602free software which everyone can redistribute and change under these 44603terms. 44604 44605 To do so, attach the following notices to the program. It is safest to 44606attach them to the start of each source file to most effectively state 44607the exclusion of warranty; and each file should have at least the 44608"copyright" line and a pointer to where the full notice is found. 44609 44610 ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES. 44611 Copyright (C) YEAR NAME OF AUTHOR 44612 44613 This program is free software: you can redistribute it and/or modify 44614 it under the terms of the GNU General Public License as published by 44615 the Free Software Foundation, either version 3 of the License, or (at 44616 your option) any later version. 44617 44618 This program is distributed in the hope that it will be useful, but 44619 WITHOUT ANY WARRANTY; without even the implied warranty of 44620 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU 44621 General Public License for more details. 44622 44623 You should have received a copy of the GNU General Public License 44624 along with this program. If not, see <http://www.gnu.org/licenses/>. 44625 44626 Also add information on how to contact you by electronic and paper 44627mail. 44628 44629 If the program does terminal interaction, make it output a short notice 44630like this when it starts in an interactive mode: 44631 44632 PROGRAM Copyright (C) YEAR NAME OF AUTHOR 44633 This program comes with ABSOLUTELY NO WARRANTY; for details type 'show w'. 44634 This is free software, and you are welcome to redistribute it 44635 under certain conditions; type 'show c' for details. 44636 44637 The hypothetical commands 'show w' and 'show c' should show the 44638appropriate parts of the General Public License. Of course, your 44639program's commands might be different; for a GUI interface, you would 44640use an "about box". 44641 44642 You should also get your employer (if you work as a programmer) or 44643school, if any, to sign a "copyright disclaimer" for the program, if 44644necessary. For more information on this, and how to apply and follow 44645the GNU GPL, see <http://www.gnu.org/licenses/>. 44646 44647 The GNU General Public License does not permit incorporating your 44648program into proprietary programs. If your program is a subroutine 44649library, you may consider it more useful to permit linking proprietary 44650applications with the library. If this is what you want to do, use the 44651GNU Lesser General Public License instead of this License. But first, 44652please read <http://www.gnu.org/philosophy/why-not-lgpl.html>. 44653 44654 44655File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top 44656 44657GNU Free Documentation License 44658****************************** 44659 44660 Version 1.3, 3 November 2008 44661 44662 Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. 44663 <http://fsf.org/> 44664 44665 Everyone is permitted to copy and distribute verbatim copies 44666 of this license document, but changing it is not allowed. 44667 44668 0. PREAMBLE 44669 44670 The purpose of this License is to make a manual, textbook, or other 44671 functional and useful document "free" in the sense of freedom: to 44672 assure everyone the effective freedom to copy and redistribute it, 44673 with or without modifying it, either commercially or 44674 noncommercially. Secondarily, this License preserves for the 44675 author and publisher a way to get credit for their work, while not 44676 being considered responsible for modifications made by others. 44677 44678 This License is a kind of "copyleft", which means that derivative 44679 works of the document must themselves be free in the same sense. 44680 It complements the GNU General Public License, which is a copyleft 44681 license designed for free software. 44682 44683 We have designed this License in order to use it for manuals for 44684 free software, because free software needs free documentation: a 44685 free program should come with manuals providing the same freedoms 44686 that the software does. But this License is not limited to 44687 software manuals; it can be used for any textual work, regardless 44688 of subject matter or whether it is published as a printed book. We 44689 recommend this License principally for works whose purpose is 44690 instruction or reference. 44691 44692 1. APPLICABILITY AND DEFINITIONS 44693 44694 This License applies to any manual or other work, in any medium, 44695 that contains a notice placed by the copyright holder saying it can 44696 be distributed under the terms of this License. Such a notice 44697 grants a world-wide, royalty-free license, unlimited in duration, 44698 to use that work under the conditions stated herein. The 44699 "Document", below, refers to any such manual or work. Any member 44700 of the public is a licensee, and is addressed as "you". You accept 44701 the license if you copy, modify or distribute the work in a way 44702 requiring permission under copyright law. 44703 44704 A "Modified Version" of the Document means any work containing the 44705 Document or a portion of it, either copied verbatim, or with 44706 modifications and/or translated into another language. 44707 44708 A "Secondary Section" is a named appendix or a front-matter section 44709 of the Document that deals exclusively with the relationship of the 44710 publishers or authors of the Document to the Document's overall 44711 subject (or to related matters) and contains nothing that could 44712 fall directly within that overall subject. (Thus, if the Document 44713 is in part a textbook of mathematics, a Secondary Section may not 44714 explain any mathematics.) The relationship could be a matter of 44715 historical connection with the subject or with related matters, or 44716 of legal, commercial, philosophical, ethical or political position 44717 regarding them. 44718 44719 The "Invariant Sections" are certain Secondary Sections whose 44720 titles are designated, as being those of Invariant Sections, in the 44721 notice that says that the Document is released under this License. 44722 If a section does not fit the above definition of Secondary then it 44723 is not allowed to be designated as Invariant. The Document may 44724 contain zero Invariant Sections. If the Document does not identify 44725 any Invariant Sections then there are none. 44726 44727 The "Cover Texts" are certain short passages of text that are 44728 listed, as Front-Cover Texts or Back-Cover Texts, in the notice 44729 that says that the Document is released under this License. A 44730 Front-Cover Text may be at most 5 words, and a Back-Cover Text may 44731 be at most 25 words. 44732 44733 A "Transparent" copy of the Document means a machine-readable copy, 44734 represented in a format whose specification is available to the 44735 general public, that is suitable for revising the document 44736 straightforwardly with generic text editors or (for images composed 44737 of pixels) generic paint programs or (for drawings) some widely 44738 available drawing editor, and that is suitable for input to text 44739 formatters or for automatic translation to a variety of formats 44740 suitable for input to text formatters. A copy made in an otherwise 44741 Transparent file format whose markup, or absence of markup, has 44742 been arranged to thwart or discourage subsequent modification by 44743 readers is not Transparent. An image format is not Transparent if 44744 used for any substantial amount of text. A copy that is not 44745 "Transparent" is called "Opaque". 44746 44747 Examples of suitable formats for Transparent copies include plain 44748 ASCII without markup, Texinfo input format, LaTeX input format, 44749 SGML or XML using a publicly available DTD, and standard-conforming 44750 simple HTML, PostScript or PDF designed for human modification. 44751 Examples of transparent image formats include PNG, XCF and JPG. 44752 Opaque formats include proprietary formats that can be read and 44753 edited only by proprietary word processors, SGML or XML for which 44754 the DTD and/or processing tools are not generally available, and 44755 the machine-generated HTML, PostScript or PDF produced by some word 44756 processors for output purposes only. 44757 44758 The "Title Page" means, for a printed book, the title page itself, 44759 plus such following pages as are needed to hold, legibly, the 44760 material this License requires to appear in the title page. For 44761 works in formats which do not have any title page as such, "Title 44762 Page" means the text near the most prominent appearance of the 44763 work's title, preceding the beginning of the body of the text. 44764 44765 The "publisher" means any person or entity that distributes copies 44766 of the Document to the public. 44767 44768 A section "Entitled XYZ" means a named subunit of the Document 44769 whose title either is precisely XYZ or contains XYZ in parentheses 44770 following text that translates XYZ in another language. (Here XYZ 44771 stands for a specific section name mentioned below, such as 44772 "Acknowledgements", "Dedications", "Endorsements", or "History".) 44773 To "Preserve the Title" of such a section when you modify the 44774 Document means that it remains a section "Entitled XYZ" according 44775 to this definition. 44776 44777 The Document may include Warranty Disclaimers next to the notice 44778 which states that this License applies to the Document. These 44779 Warranty Disclaimers are considered to be included by reference in 44780 this License, but only as regards disclaiming warranties: any other 44781 implication that these Warranty Disclaimers may have is void and 44782 has no effect on the meaning of this License. 44783 44784 2. VERBATIM COPYING 44785 44786 You may copy and distribute the Document in any medium, either 44787 commercially or noncommercially, provided that this License, the 44788 copyright notices, and the license notice saying this License 44789 applies to the Document are reproduced in all copies, and that you 44790 add no other conditions whatsoever to those of this License. You 44791 may not use technical measures to obstruct or control the reading 44792 or further copying of the copies you make or distribute. However, 44793 you may accept compensation in exchange for copies. If you 44794 distribute a large enough number of copies you must also follow the 44795 conditions in section 3. 44796 44797 You may also lend copies, under the same conditions stated above, 44798 and you may publicly display copies. 44799 44800 3. COPYING IN QUANTITY 44801 44802 If you publish printed copies (or copies in media that commonly 44803 have printed covers) of the Document, numbering more than 100, and 44804 the Document's license notice requires Cover Texts, you must 44805 enclose the copies in covers that carry, clearly and legibly, all 44806 these Cover Texts: Front-Cover Texts on the front cover, and 44807 Back-Cover Texts on the back cover. Both covers must also clearly 44808 and legibly identify you as the publisher of these copies. The 44809 front cover must present the full title with all words of the title 44810 equally prominent and visible. You may add other material on the 44811 covers in addition. Copying with changes limited to the covers, as 44812 long as they preserve the title of the Document and satisfy these 44813 conditions, can be treated as verbatim copying in other respects. 44814 44815 If the required texts for either cover are too voluminous to fit 44816 legibly, you should put the first ones listed (as many as fit 44817 reasonably) on the actual cover, and continue the rest onto 44818 adjacent pages. 44819 44820 If you publish or distribute Opaque copies of the Document 44821 numbering more than 100, you must either include a machine-readable 44822 Transparent copy along with each Opaque copy, or state in or with 44823 each Opaque copy a computer-network location from which the general 44824 network-using public has access to download using public-standard 44825 network protocols a complete Transparent copy of the Document, free 44826 of added material. If you use the latter option, you must take 44827 reasonably prudent steps, when you begin distribution of Opaque 44828 copies in quantity, to ensure that this Transparent copy will 44829 remain thus accessible at the stated location until at least one 44830 year after the last time you distribute an Opaque copy (directly or 44831 through your agents or retailers) of that edition to the public. 44832 44833 It is requested, but not required, that you contact the authors of 44834 the Document well before redistributing any large number of copies, 44835 to give them a chance to provide you with an updated version of the 44836 Document. 44837 44838 4. MODIFICATIONS 44839 44840 You may copy and distribute a Modified Version of the Document 44841 under the conditions of sections 2 and 3 above, provided that you 44842 release the Modified Version under precisely this License, with the 44843 Modified Version filling the role of the Document, thus licensing 44844 distribution and modification of the Modified Version to whoever 44845 possesses a copy of it. In addition, you must do these things in 44846 the Modified Version: 44847 44848 A. Use in the Title Page (and on the covers, if any) a title 44849 distinct from that of the Document, and from those of previous 44850 versions (which should, if there were any, be listed in the 44851 History section of the Document). You may use the same title 44852 as a previous version if the original publisher of that 44853 version gives permission. 44854 44855 B. List on the Title Page, as authors, one or more persons or 44856 entities responsible for authorship of the modifications in 44857 the Modified Version, together with at least five of the 44858 principal authors of the Document (all of its principal 44859 authors, if it has fewer than five), unless they release you 44860 from this requirement. 44861 44862 C. State on the Title page the name of the publisher of the 44863 Modified Version, as the publisher. 44864 44865 D. Preserve all the copyright notices of the Document. 44866 44867 E. Add an appropriate copyright notice for your modifications 44868 adjacent to the other copyright notices. 44869 44870 F. Include, immediately after the copyright notices, a license 44871 notice giving the public permission to use the Modified 44872 Version under the terms of this License, in the form shown in 44873 the Addendum below. 44874 44875 G. Preserve in that license notice the full lists of Invariant 44876 Sections and required Cover Texts given in the Document's 44877 license notice. 44878 44879 H. Include an unaltered copy of this License. 44880 44881 I. Preserve the section Entitled "History", Preserve its Title, 44882 and add to it an item stating at least the title, year, new 44883 authors, and publisher of the Modified Version as given on the 44884 Title Page. If there is no section Entitled "History" in the 44885 Document, create one stating the title, year, authors, and 44886 publisher of the Document as given on its Title Page, then add 44887 an item describing the Modified Version as stated in the 44888 previous sentence. 44889 44890 J. Preserve the network location, if any, given in the Document 44891 for public access to a Transparent copy of the Document, and 44892 likewise the network locations given in the Document for 44893 previous versions it was based on. These may be placed in the 44894 "History" section. You may omit a network location for a work 44895 that was published at least four years before the Document 44896 itself, or if the original publisher of the version it refers 44897 to gives permission. 44898 44899 K. For any section Entitled "Acknowledgements" or "Dedications", 44900 Preserve the Title of the section, and preserve in the section 44901 all the substance and tone of each of the contributor 44902 acknowledgements and/or dedications given therein. 44903 44904 L. Preserve all the Invariant Sections of the Document, unaltered 44905 in their text and in their titles. Section numbers or the 44906 equivalent are not considered part of the section titles. 44907 44908 M. Delete any section Entitled "Endorsements". Such a section 44909 may not be included in the Modified Version. 44910 44911 N. Do not retitle any existing section to be Entitled 44912 "Endorsements" or to conflict in title with any Invariant 44913 Section. 44914 44915 O. Preserve any Warranty Disclaimers. 44916 44917 If the Modified Version includes new front-matter sections or 44918 appendices that qualify as Secondary Sections and contain no 44919 material copied from the Document, you may at your option designate 44920 some or all of these sections as invariant. To do this, add their 44921 titles to the list of Invariant Sections in the Modified Version's 44922 license notice. These titles must be distinct from any other 44923 section titles. 44924 44925 You may add a section Entitled "Endorsements", provided it contains 44926 nothing but endorsements of your Modified Version by various 44927 parties--for example, statements of peer review or that the text 44928 has been approved by an organization as the authoritative 44929 definition of a standard. 44930 44931 You may add a passage of up to five words as a Front-Cover Text, 44932 and a passage of up to 25 words as a Back-Cover Text, to the end of 44933 the list of Cover Texts in the Modified Version. Only one passage 44934 of Front-Cover Text and one of Back-Cover Text may be added by (or 44935 through arrangements made by) any one entity. If the Document 44936 already includes a cover text for the same cover, previously added 44937 by you or by arrangement made by the same entity you are acting on 44938 behalf of, you may not add another; but you may replace the old 44939 one, on explicit permission from the previous publisher that added 44940 the old one. 44941 44942 The author(s) and publisher(s) of the Document do not by this 44943 License give permission to use their names for publicity for or to 44944 assert or imply endorsement of any Modified Version. 44945 44946 5. COMBINING DOCUMENTS 44947 44948 You may combine the Document with other documents released under 44949 this License, under the terms defined in section 4 above for 44950 modified versions, provided that you include in the combination all 44951 of the Invariant Sections of all of the original documents, 44952 unmodified, and list them all as Invariant Sections of your 44953 combined work in its license notice, and that you preserve all 44954 their Warranty Disclaimers. 44955 44956 The combined work need only contain one copy of this License, and 44957 multiple identical Invariant Sections may be replaced with a single 44958 copy. If there are multiple Invariant Sections with the same name 44959 but different contents, make the title of each such section unique 44960 by adding at the end of it, in parentheses, the name of the 44961 original author or publisher of that section if known, or else a 44962 unique number. Make the same adjustment to the section titles in 44963 the list of Invariant Sections in the license notice of the 44964 combined work. 44965 44966 In the combination, you must combine any sections Entitled 44967 "History" in the various original documents, forming one section 44968 Entitled "History"; likewise combine any sections Entitled 44969 "Acknowledgements", and any sections Entitled "Dedications". You 44970 must delete all sections Entitled "Endorsements." 44971 44972 6. COLLECTIONS OF DOCUMENTS 44973 44974 You may make a collection consisting of the Document and other 44975 documents released under this License, and replace the individual 44976 copies of this License in the various documents with a single copy 44977 that is included in the collection, provided that you follow the 44978 rules of this License for verbatim copying of each of the documents 44979 in all other respects. 44980 44981 You may extract a single document from such a collection, and 44982 distribute it individually under this License, provided you insert 44983 a copy of this License into the extracted document, and follow this 44984 License in all other respects regarding verbatim copying of that 44985 document. 44986 44987 7. AGGREGATION WITH INDEPENDENT WORKS 44988 44989 A compilation of the Document or its derivatives with other 44990 separate and independent documents or works, in or on a volume of a 44991 storage or distribution medium, is called an "aggregate" if the 44992 copyright resulting from the compilation is not used to limit the 44993 legal rights of the compilation's users beyond what the individual 44994 works permit. When the Document is included in an aggregate, this 44995 License does not apply to the other works in the aggregate which 44996 are not themselves derivative works of the Document. 44997 44998 If the Cover Text requirement of section 3 is applicable to these 44999 copies of the Document, then if the Document is less than one half 45000 of the entire aggregate, the Document's Cover Texts may be placed 45001 on covers that bracket the Document within the aggregate, or the 45002 electronic equivalent of covers if the Document is in electronic 45003 form. Otherwise they must appear on printed covers that bracket 45004 the whole aggregate. 45005 45006 8. TRANSLATION 45007 45008 Translation is considered a kind of modification, so you may 45009 distribute translations of the Document under the terms of section 45010 4. Replacing Invariant Sections with translations requires special 45011 permission from their copyright holders, but you may include 45012 translations of some or all Invariant Sections in addition to the 45013 original versions of these Invariant Sections. You may include a 45014 translation of this License, and all the license notices in the 45015 Document, and any Warranty Disclaimers, provided that you also 45016 include the original English version of this License and the 45017 original versions of those notices and disclaimers. In case of a 45018 disagreement between the translation and the original version of 45019 this License or a notice or disclaimer, the original version will 45020 prevail. 45021 45022 If a section in the Document is Entitled "Acknowledgements", 45023 "Dedications", or "History", the requirement (section 4) to 45024 Preserve its Title (section 1) will typically require changing the 45025 actual title. 45026 45027 9. TERMINATION 45028 45029 You may not copy, modify, sublicense, or distribute the Document 45030 except as expressly provided under this License. Any attempt 45031 otherwise to copy, modify, sublicense, or distribute it is void, 45032 and will automatically terminate your rights under this License. 45033 45034 However, if you cease all violation of this License, then your 45035 license from a particular copyright holder is reinstated (a) 45036 provisionally, unless and until the copyright holder explicitly and 45037 finally terminates your license, and (b) permanently, if the 45038 copyright holder fails to notify you of the violation by some 45039 reasonable means prior to 60 days after the cessation. 45040 45041 Moreover, your license from a particular copyright holder is 45042 reinstated permanently if the copyright holder notifies you of the 45043 violation by some reasonable means, this is the first time you have 45044 received notice of violation of this License (for any work) from 45045 that copyright holder, and you cure the violation prior to 30 days 45046 after your receipt of the notice. 45047 45048 Termination of your rights under this section does not terminate 45049 the licenses of parties who have received copies or rights from you 45050 under this License. If your rights have been terminated and not 45051 permanently reinstated, receipt of a copy of some or all of the 45052 same material does not give you any rights to use it. 45053 45054 10. FUTURE REVISIONS OF THIS LICENSE 45055 45056 The Free Software Foundation may publish new, revised versions of 45057 the GNU Free Documentation License from time to time. Such new 45058 versions will be similar in spirit to the present version, but may 45059 differ in detail to address new problems or concerns. See 45060 <http://www.gnu.org/copyleft/>. 45061 45062 Each version of the License is given a distinguishing version 45063 number. If the Document specifies that a particular numbered 45064 version of this License "or any later version" applies to it, you 45065 have the option of following the terms and conditions either of 45066 that specified version or of any later version that has been 45067 published (not as a draft) by the Free Software Foundation. If the 45068 Document does not specify a version number of this License, you may 45069 choose any version ever published (not as a draft) by the Free 45070 Software Foundation. If the Document specifies that a proxy can 45071 decide which future versions of this License can be used, that 45072 proxy's public statement of acceptance of a version permanently 45073 authorizes you to choose that version for the Document. 45074 45075 11. RELICENSING 45076 45077 "Massive Multiauthor Collaboration Site" (or "MMC Site") means any 45078 World Wide Web server that publishes copyrightable works and also 45079 provides prominent facilities for anybody to edit those works. A 45080 public wiki that anybody can edit is an example of such a server. 45081 A "Massive Multiauthor Collaboration" (or "MMC") contained in the 45082 site means any set of copyrightable works thus published on the MMC 45083 site. 45084 45085 "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 45086 license published by Creative Commons Corporation, a not-for-profit 45087 corporation with a principal place of business in San Francisco, 45088 California, as well as future copyleft versions of that license 45089 published by that same organization. 45090 45091 "Incorporate" means to publish or republish a Document, in whole or 45092 in part, as part of another Document. 45093 45094 An MMC is "eligible for relicensing" if it is licensed under this 45095 License, and if all works that were first published under this 45096 License somewhere other than this MMC, and subsequently 45097 incorporated in whole or in part into the MMC, (1) had no cover 45098 texts or invariant sections, and (2) were thus incorporated prior 45099 to November 1, 2008. 45100 45101 The operator of an MMC Site may republish an MMC contained in the 45102 site under CC-BY-SA on the same site at any time before August 1, 45103 2009, provided the MMC is eligible for relicensing. 45104 45105ADDENDUM: How to use this License for your documents 45106==================================================== 45107 45108To use this License in a document you have written, include a copy of 45109the License in the document and put the following copyright and license 45110notices just after the title page: 45111 45112 Copyright (C) YEAR YOUR NAME. 45113 Permission is granted to copy, distribute and/or modify this document 45114 under the terms of the GNU Free Documentation License, Version 1.3 45115 or any later version published by the Free Software Foundation; 45116 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover 45117 Texts. A copy of the license is included in the section entitled ``GNU 45118 Free Documentation License''. 45119 45120 If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, 45121replace the "with...Texts." line with this: 45122 45123 with the Invariant Sections being LIST THEIR TITLES, with 45124 the Front-Cover Texts being LIST, and with the Back-Cover Texts 45125 being LIST. 45126 45127 If you have Invariant Sections without Cover Texts, or some other 45128combination of the three, merge those two alternatives to suit the 45129situation. 45130 45131 If your document contains nontrivial examples of program code, we 45132recommend releasing these examples in parallel under your choice of free 45133software license, such as the GNU General Public License, to permit 45134their use in free software. 45135 45136 45137File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top 45138 45139Contributors to GCC 45140******************* 45141 45142The GCC project would like to thank its many contributors. Without them 45143the project would not have been nearly as successful as it has been. 45144Any omissions in this list are accidental. Feel free to contact 45145<law@redhat.com> or <gerald@pfeifer.com> if you have been left out or 45146some of your contributions are not listed. Please keep this list in 45147alphabetical order. 45148 45149 * Analog Devices helped implement the support for complex data types 45150 and iterators. 45151 45152 * John David Anglin for threading-related fixes and improvements to 45153 libstdc++-v3, and the HP-UX port. 45154 45155 * James van Artsdalen wrote the code that makes efficient use of the 45156 Intel 80387 register stack. 45157 45158 * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta 45159 Series port. 45160 45161 * Alasdair Baird for various bug fixes. 45162 45163 * Giovanni Bajo for analyzing lots of complicated C++ problem 45164 reports. 45165 45166 * Peter Barada for his work to improve code generation for new 45167 ColdFire cores. 45168 45169 * Gerald Baumgartner added the signature extension to the C++ front 45170 end. 45171 45172 * Godmar Back for his Java improvements and encouragement. 45173 45174 * Scott Bambrough for help porting the Java compiler. 45175 45176 * Wolfgang Bangerth for processing tons of bug reports. 45177 45178 * Jon Beniston for his Microsoft Windows port of Java and port to 45179 Lattice Mico32. 45180 45181 * Daniel Berlin for better DWARF 2 support, faster/better 45182 optimizations, improved alias analysis, plus migrating GCC to 45183 Bugzilla. 45184 45185 * Geoff Berry for his Java object serialization work and various 45186 patches. 45187 45188 * David Binderman tests weekly snapshots of GCC trunk against Fedora 45189 Rawhide for several architectures. 45190 45191 * Laurynas Biveinis for memory management work and DJGPP port fixes. 45192 45193 * Uros Bizjak for the implementation of x87 math built-in functions 45194 and for various middle end and i386 back end improvements and bug 45195 fixes. 45196 45197 * Eric Blake for helping to make GCJ and libgcj conform to the 45198 specifications. 45199 45200 * Janne Blomqvist for contributions to GNU Fortran. 45201 45202 * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and 45203 other Java work. 45204 45205 * Segher Boessenkool for helping maintain the PowerPC port and the 45206 instruction combiner plus various contributions to the middle end. 45207 45208 * Neil Booth for work on cpplib, lang hooks, debug hooks and other 45209 miscellaneous clean-ups. 45210 45211 * Steven Bosscher for integrating the GNU Fortran front end into GCC 45212 and for contributing to the tree-ssa branch. 45213 45214 * Eric Botcazou for fixing middle- and backend bugs left and right. 45215 45216 * Per Bothner for his direction via the steering committee and 45217 various improvements to the infrastructure for supporting new 45218 languages. Chill front end implementation. Initial 45219 implementations of cpplib, fix-header, config.guess, libio, and 45220 past C++ library (libg++) maintainer. Dreaming up, designing and 45221 implementing much of GCJ. 45222 45223 * Devon Bowen helped port GCC to the Tahoe. 45224 45225 * Don Bowman for mips-vxworks contributions. 45226 45227 * James Bowman for the FT32 port. 45228 45229 * Dave Brolley for work on cpplib and Chill. 45230 45231 * Paul Brook for work on the ARM architecture and maintaining GNU 45232 Fortran. 45233 45234 * Robert Brown implemented the support for Encore 32000 systems. 45235 45236 * Christian Bruel for improvements to local store elimination. 45237 45238 * Herman A.J. ten Brugge for various fixes. 45239 45240 * Joerg Brunsmann for Java compiler hacking and help with the GCJ 45241 FAQ. 45242 45243 * Joe Buck for his direction via the steering committee from its 45244 creation to 2013. 45245 45246 * Craig Burley for leadership of the G77 Fortran effort. 45247 45248 * Tobias Burnus for contributions to GNU Fortran. 45249 45250 * Stephan Buys for contributing Doxygen notes for libstdc++. 45251 45252 * Paolo Carlini for libstdc++ work: lots of efficiency improvements 45253 to the C++ strings, streambufs and formatted I/O, hard detective 45254 work on the frustrating localization issues, and keeping up with 45255 the problem reports. 45256 45257 * John Carr for his alias work, SPARC hacking, infrastructure 45258 improvements, previous contributions to the steering committee, 45259 loop optimizations, etc. 45260 45261 * Stephane Carrez for 68HC11 and 68HC12 ports. 45262 45263 * Steve Chamberlain for support for the Renesas SH and H8 processors 45264 and the PicoJava processor, and for GCJ config fixes. 45265 45266 * Glenn Chambers for help with the GCJ FAQ. 45267 45268 * John-Marc Chandonia for various libgcj patches. 45269 45270 * Denis Chertykov for contributing and maintaining the AVR port, the 45271 first GCC port for an 8-bit architecture. 45272 45273 * Kito Cheng for his work on the RISC-V port, including bringing up 45274 the test suite and maintenance. 45275 45276 * Scott Christley for his Objective-C contributions. 45277 45278 * Eric Christopher for his Java porting help and clean-ups. 45279 45280 * Branko Cibej for more warning contributions. 45281 45282 * The GNU Classpath project for all of their merged runtime code. 45283 45284 * Nick Clifton for arm, mcore, fr30, v850, m32r, msp430 rx work, 45285 '--help', and other random hacking. 45286 45287 * Michael Cook for libstdc++ cleanup patches to reduce warnings. 45288 45289 * R. Kelley Cook for making GCC buildable from a read-only directory 45290 as well as other miscellaneous build process and documentation 45291 clean-ups. 45292 45293 * Ralf Corsepius for SH testing and minor bug fixing. 45294 45295 * Franc,ois-Xavier Coudert for contributions to GNU Fortran. 45296 45297 * Stan Cox for care and feeding of the x86 port and lots of behind 45298 the scenes hacking. 45299 45300 * Alex Crain provided changes for the 3b1. 45301 45302 * Ian Dall for major improvements to the NS32k port. 45303 45304 * Paul Dale for his work to add uClinux platform support to the m68k 45305 backend. 45306 45307 * Palmer Dabbelt for his work maintaining the RISC-V port. 45308 45309 * Dario Dariol contributed the four varieties of sample programs that 45310 print a copy of their source. 45311 45312 * Russell Davidson for fstream and stringstream fixes in libstdc++. 45313 45314 * Bud Davis for work on the G77 and GNU Fortran compilers. 45315 45316 * Mo DeJong for GCJ and libgcj bug fixes. 45317 45318 * Jerry DeLisle for contributions to GNU Fortran. 45319 45320 * DJ Delorie for the DJGPP port, build and libiberty maintenance, 45321 various bug fixes, and the M32C, MeP, MSP430, and RL78 ports. 45322 45323 * Arnaud Desitter for helping to debug GNU Fortran. 45324 45325 * Gabriel Dos Reis for contributions to G++, contributions and 45326 maintenance of GCC diagnostics infrastructure, libstdc++-v3, 45327 including 'valarray<>', 'complex<>', maintaining the numerics 45328 library (including that pesky '<limits>' :-) and keeping up-to-date 45329 anything to do with numbers. 45330 45331 * Ulrich Drepper for his work on glibc, testing of GCC using glibc, 45332 ISO C99 support, CFG dumping support, etc., plus support of the C++ 45333 runtime libraries including for all kinds of C interface issues, 45334 contributing and maintaining 'complex<>', sanity checking and 45335 disbursement, configuration architecture, libio maintenance, and 45336 early math work. 45337 45338 * Franc,ois Dumont for his work on libstdc++-v3, especially 45339 maintaining and improving 'debug-mode' and associative and 45340 unordered containers. 45341 45342 * Zdenek Dvorak for a new loop unroller and various fixes. 45343 45344 * Michael Eager for his work on the Xilinx MicroBlaze port. 45345 45346 * Richard Earnshaw for his ongoing work with the ARM. 45347 45348 * David Edelsohn for his direction via the steering committee, 45349 ongoing work with the RS6000/PowerPC port, help cleaning up Haifa 45350 loop changes, doing the entire AIX port of libstdc++ with his bare 45351 hands, and for ensuring GCC properly keeps working on AIX. 45352 45353 * Kevin Ediger for the floating point formatting of num_put::do_put 45354 in libstdc++. 45355 45356 * Phil Edwards for libstdc++ work including configuration hackery, 45357 documentation maintainer, chief breaker of the web pages, the 45358 occasional iostream bug fix, and work on shared library symbol 45359 versioning. 45360 45361 * Paul Eggert for random hacking all over GCC. 45362 45363 * Mark Elbrecht for various DJGPP improvements, and for libstdc++ 45364 configuration support for locales and fstream-related fixes. 45365 45366 * Vadim Egorov for libstdc++ fixes in strings, streambufs, and 45367 iostreams. 45368 45369 * Christian Ehrhardt for dealing with bug reports. 45370 45371 * Ben Elliston for his work to move the Objective-C runtime into its 45372 own subdirectory and for his work on autoconf. 45373 45374 * Revital Eres for work on the PowerPC 750CL port. 45375 45376 * Marc Espie for OpenBSD support. 45377 45378 * Doug Evans for much of the global optimization framework, arc, 45379 m32r, and SPARC work. 45380 45381 * Christopher Faylor for his work on the Cygwin port and for caring 45382 and feeding the gcc.gnu.org box and saving its users tons of spam. 45383 45384 * Fred Fish for BeOS support and Ada fixes. 45385 45386 * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ. 45387 45388 * Peter Gerwinski for various bug fixes and the Pascal front end. 45389 45390 * Kaveh R. Ghazi for his direction via the steering committee, 45391 amazing work to make '-W -Wall -W* -Werror' useful, and testing GCC 45392 on a plethora of platforms. Kaveh extends his gratitude to the 45393 CAIP Center at Rutgers University for providing him with computing 45394 resources to work on Free Software from the late 1980s to 2010. 45395 45396 * John Gilmore for a donation to the FSF earmarked improving GNU 45397 Java. 45398 45399 * Judy Goldberg for c++ contributions. 45400 45401 * Torbjorn Granlund for various fixes and the c-torture testsuite, 45402 multiply- and divide-by-constant optimization, improved long long 45403 support, improved leaf function register allocation, and his 45404 direction via the steering committee. 45405 45406 * Jonny Grant for improvements to 'collect2's' '--help' 45407 documentation. 45408 45409 * Anthony Green for his '-Os' contributions, the moxie port, and Java 45410 front end work. 45411 45412 * Stu Grossman for gdb hacking, allowing GCJ developers to debug Java 45413 code. 45414 45415 * Michael K. Gschwind contributed the port to the PDP-11. 45416 45417 * Richard Biener for his ongoing middle-end contributions and bug 45418 fixes and for release management. 45419 45420 * Ron Guilmette implemented the 'protoize' and 'unprotoize' tools, 45421 the support for DWARF 1 symbolic debugging information, and much of 45422 the support for System V Release 4. He has also worked heavily on 45423 the Intel 386 and 860 support. 45424 45425 * Sumanth Gundapaneni for contributing the CR16 port. 45426 45427 * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload 45428 GCSE. 45429 45430 * Bruno Haible for improvements in the runtime overhead for EH, new 45431 warnings and assorted bug fixes. 45432 45433 * Andrew Haley for his amazing Java compiler and library efforts. 45434 45435 * Chris Hanson assisted in making GCC work on HP-UX for the 9000 45436 series 300. 45437 45438 * Michael Hayes for various thankless work he's done trying to get 45439 the c30/c40 ports functional. Lots of loop and unroll improvements 45440 and fixes. 45441 45442 * Dara Hazeghi for wading through myriads of target-specific bug 45443 reports. 45444 45445 * Kate Hedstrom for staking the G77 folks with an initial testsuite. 45446 45447 * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64 45448 work, loop opts, and generally fixing lots of old problems we've 45449 ignored for years, flow rewrite and lots of further stuff, 45450 including reviewing tons of patches. 45451 45452 * Aldy Hernandez for working on the PowerPC port, SIMD support, and 45453 various fixes. 45454 45455 * Nobuyuki Hikichi of Software Research Associates, Tokyo, 45456 contributed the support for the Sony NEWS machine. 45457 45458 * Kazu Hirata for caring and feeding the Renesas H8/300 port and 45459 various fixes. 45460 45461 * Katherine Holcomb for work on GNU Fortran. 45462 45463 * Manfred Hollstein for his ongoing work to keep the m88k alive, lots 45464 of testing and bug fixing, particularly of GCC configury code. 45465 45466 * Steve Holmgren for MachTen patches. 45467 45468 * Mat Hostetter for work on the TILE-Gx and TILEPro ports. 45469 45470 * Jan Hubicka for his x86 port improvements. 45471 45472 * Falk Hueffner for working on C and optimization bug reports. 45473 45474 * Bernardo Innocenti for his m68k work, including merging of ColdFire 45475 improvements and uClinux support. 45476 45477 * Christian Iseli for various bug fixes. 45478 45479 * Kamil Iskra for general m68k hacking. 45480 45481 * Lee Iverson for random fixes and MIPS testing. 45482 45483 * Balaji V. Iyer for Cilk+ development and merging. 45484 45485 * Andreas Jaeger for testing and benchmarking of GCC and various bug 45486 fixes. 45487 45488 * Martin Jambor for his work on inter-procedural optimizations, the 45489 switch conversion pass, and scalar replacement of aggregates. 45490 45491 * Jakub Jelinek for his SPARC work and sibling call optimizations as 45492 well as lots of bug fixes and test cases, and for improving the 45493 Java build system. 45494 45495 * Janis Johnson for ia64 testing and fixes, her quality improvement 45496 sidetracks, and web page maintenance. 45497 45498 * Kean Johnston for SCO OpenServer support and various fixes. 45499 45500 * Tim Josling for the sample language treelang based originally on 45501 Richard Kenner's "toy" language. 45502 45503 * Nicolai Josuttis for additional libstdc++ documentation. 45504 45505 * Klaus Kaempf for his ongoing work to make alpha-vms a viable 45506 target. 45507 45508 * Steven G. Kargl for work on GNU Fortran. 45509 45510 * David Kashtan of SRI adapted GCC to VMS. 45511 45512 * Ryszard Kabatek for many, many libstdc++ bug fixes and 45513 optimizations of strings, especially member functions, and for 45514 auto_ptr fixes. 45515 45516 * Geoffrey Keating for his ongoing work to make the PPC work for 45517 GNU/Linux and his automatic regression tester. 45518 45519 * Brendan Kehoe for his ongoing work with G++ and for a lot of early 45520 work in just about every part of libstdc++. 45521 45522 * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the 45523 MIL-STD-1750A. 45524 45525 * Richard Kenner of the New York University Ultracomputer Research 45526 Laboratory wrote the machine descriptions for the AMD 29000, the 45527 DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the 45528 support for instruction attributes. He also made changes to better 45529 support RISC processors including changes to common subexpression 45530 elimination, strength reduction, function calling sequence 45531 handling, and condition code support, in addition to generalizing 45532 the code for frame pointer elimination and delay slot scheduling. 45533 Richard Kenner was also the head maintainer of GCC for several 45534 years. 45535 45536 * Mumit Khan for various contributions to the Cygwin and Mingw32 45537 ports and maintaining binary releases for Microsoft Windows hosts, 45538 and for massive libstdc++ porting work to Cygwin/Mingw32. 45539 45540 * Robin Kirkham for cpu32 support. 45541 45542 * Mark Klein for PA improvements. 45543 45544 * Thomas Koenig for various bug fixes. 45545 45546 * Bruce Korb for the new and improved fixincludes code. 45547 45548 * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3 45549 effort. 45550 45551 * Maxim Kuvyrkov for contributions to the instruction scheduler, the 45552 Android and m68k/Coldfire ports, and optimizations. 45553 45554 * Charles LaBrec contributed the support for the Integrated Solutions 45555 68020 system. 45556 45557 * Asher Langton and Mike Kumbera for contributing Cray pointer 45558 support to GNU Fortran, and for other GNU Fortran improvements. 45559 45560 * Jeff Law for his direction via the steering committee, coordinating 45561 the entire egcs project and GCC 2.95, rolling out snapshots and 45562 releases, handling merges from GCC2, reviewing tons of patches that 45563 might have fallen through the cracks else, and random but extensive 45564 hacking. 45565 45566 * Walter Lee for work on the TILE-Gx and TILEPro ports. 45567 45568 * Marc Lehmann for his direction via the steering committee and 45569 helping with analysis and improvements of x86 performance. 45570 45571 * Victor Leikehman for work on GNU Fortran. 45572 45573 * Ted Lemon wrote parts of the RTL reader and printer. 45574 45575 * Kriang Lerdsuwanakij for C++ improvements including template as 45576 template parameter support, and many C++ fixes. 45577 45578 * Warren Levy for tremendous work on libgcj (Java Runtime Library) 45579 and random work on the Java front end. 45580 45581 * Alain Lichnewsky ported GCC to the MIPS CPU. 45582 45583 * Oskar Liljeblad for hacking on AWT and his many Java bug reports 45584 and patches. 45585 45586 * Robert Lipe for OpenServer support, new testsuites, testing, etc. 45587 45588 * Chen Liqin for various S+core related fixes/improvement, and for 45589 maintaining the S+core port. 45590 45591 * Martin Liska for his work on identical code folding, the 45592 sanitizers, HSA, general bug fixing and for running automated 45593 regression testing of GCC and reporting numerous bugs. 45594 45595 * Weiwen Liu for testing and various bug fixes. 45596 45597 * Manuel Lo'pez-Iba'n~ez for improving '-Wconversion' and many other 45598 diagnostics fixes and improvements. 45599 45600 * Dave Love for his ongoing work with the Fortran front end and 45601 runtime libraries. 45602 45603 * Martin von Lo"wis for internal consistency checking infrastructure, 45604 various C++ improvements including namespace support, and tons of 45605 assistance with libstdc++/compiler merges. 45606 45607 * H.J. Lu for his previous contributions to the steering committee, 45608 many x86 bug reports, prototype patches, and keeping the GNU/Linux 45609 ports working. 45610 45611 * Greg McGary for random fixes and (someday) bounded pointers. 45612 45613 * Andrew MacLeod for his ongoing work in building a real EH system, 45614 various code generation improvements, work on the global optimizer, 45615 etc. 45616 45617 * Vladimir Makarov for hacking some ugly i960 problems, PowerPC 45618 hacking improvements to compile-time performance, overall knowledge 45619 and direction in the area of instruction scheduling, design and 45620 implementation of the automaton based instruction scheduler and 45621 design and implementation of the integrated and local register 45622 allocators. 45623 45624 * David Malcolm for his work on improving GCC diagnostics, JIT, 45625 self-tests and unit testing. 45626 45627 * Bob Manson for his behind the scenes work on dejagnu. 45628 45629 * John Marino for contributing the DragonFly BSD port. 45630 45631 * Philip Martin for lots of libstdc++ string and vector iterator 45632 fixes and improvements, and string clean up and testsuites. 45633 45634 * Michael Matz for his work on dominance tree discovery, the x86-64 45635 port, link-time optimization framework and general optimization 45636 improvements. 45637 45638 * All of the Mauve project contributors for Java test code. 45639 45640 * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements. 45641 45642 * Adam Megacz for his work on the Microsoft Windows port of GCJ. 45643 45644 * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS, 45645 powerpc, haifa, ECOFF debug support, and other assorted hacking. 45646 45647 * Jason Merrill for his direction via the steering committee and 45648 leading the G++ effort. 45649 45650 * Martin Michlmayr for testing GCC on several architectures using the 45651 entire Debian archive. 45652 45653 * David Miller for his direction via the steering committee, lots of 45654 SPARC work, improvements in jump.c and interfacing with the Linux 45655 kernel developers. 45656 45657 * Gary Miller ported GCC to Charles River Data Systems machines. 45658 45659 * Alfred Minarik for libstdc++ string and ios bug fixes, and turning 45660 the entire libstdc++ testsuite namespace-compatible. 45661 45662 * Mark Mitchell for his direction via the steering committee, 45663 mountains of C++ work, load/store hoisting out of loops, alias 45664 analysis improvements, ISO C 'restrict' support, and serving as 45665 release manager from 2000 to 2011. 45666 45667 * Alan Modra for various GNU/Linux bits and testing. 45668 45669 * Toon Moene for his direction via the steering committee, Fortran 45670 maintenance, and his ongoing work to make us make Fortran run fast. 45671 45672 * Jason Molenda for major help in the care and feeding of all the 45673 services on the gcc.gnu.org (formerly egcs.cygnus.com) 45674 machine--mail, web services, ftp services, etc etc. Doing all this 45675 work on scrap paper and the backs of envelopes would have been... 45676 difficult. 45677 45678 * Catherine Moore for fixing various ugly problems we have sent her 45679 way, including the haifa bug which was killing the Alpha & PowerPC 45680 Linux kernels. 45681 45682 * Mike Moreton for his various Java patches. 45683 45684 * David Mosberger-Tang for various Alpha improvements, and for the 45685 initial IA-64 port. 45686 45687 * Stephen Moshier contributed the floating point emulator that 45688 assists in cross-compilation and permits support for floating point 45689 numbers wider than 64 bits and for ISO C99 support. 45690 45691 * Bill Moyer for his behind the scenes work on various issues. 45692 45693 * Philippe De Muyter for his work on the m68k port. 45694 45695 * Joseph S. Myers for his work on the PDP-11 port, format checking 45696 and ISO C99 support, and continuous emphasis on (and contributions 45697 to) documentation. 45698 45699 * Nathan Myers for his work on libstdc++-v3: architecture and 45700 authorship through the first three snapshots, including 45701 implementation of locale infrastructure, string, shadow C headers, 45702 and the initial project documentation (DESIGN, CHECKLIST, and so 45703 forth). Later, more work on MT-safe string and shadow headers. 45704 45705 * Felix Natter for documentation on porting libstdc++. 45706 45707 * Nathanael Nerode for cleaning up the configuration/build process. 45708 45709 * NeXT, Inc. donated the front end that supports the Objective-C 45710 language. 45711 45712 * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to the 45713 search engine setup, various documentation fixes and other small 45714 fixes. 45715 45716 * Geoff Noer for his work on getting cygwin native builds working. 45717 45718 * Vegard Nossum for running automated regression testing of GCC and 45719 reporting numerous bugs. 45720 45721 * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance 45722 tracking web pages, GIMPLE tuples, and assorted fixes. 45723 45724 * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64, 45725 FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and related 45726 infrastructure improvements. 45727 45728 * Alexandre Oliva for various build infrastructure improvements, 45729 scripts and amazing testing work, including keeping libtool issues 45730 sane and happy. 45731 45732 * Stefan Olsson for work on mt_alloc. 45733 45734 * Melissa O'Neill for various NeXT fixes. 45735 45736 * Rainer Orth for random MIPS work, including improvements to GCC's 45737 o32 ABI support, improvements to dejagnu's MIPS support, Java 45738 configuration clean-ups and porting work, and maintaining the IRIX, 45739 Solaris 2, and Tru64 UNIX ports. 45740 45741 * Steven Pemberton for his contribution of 'enquire' which allowed 45742 GCC to determine various properties of the floating point unit and 45743 generate 'float.h' in older versions of GCC. 45744 45745 * Hartmut Penner for work on the s390 port. 45746 45747 * Paul Petersen wrote the machine description for the Alliant FX/8. 45748 45749 * Alexandre Petit-Bianco for implementing much of the Java compiler 45750 and continued Java maintainership. 45751 45752 * Matthias Pfaller for major improvements to the NS32k port. 45753 45754 * Gerald Pfeifer for his direction via the steering committee, 45755 pointing out lots of problems we need to solve, maintenance of the 45756 web pages, and taking care of documentation maintenance in general. 45757 45758 * Marek Polacek for his work on the C front end, the sanitizers and 45759 general bug fixing. 45760 45761 * Andrew Pinski for processing bug reports by the dozen. 45762 45763 * Ovidiu Predescu for his work on the Objective-C front end and 45764 runtime libraries. 45765 45766 * Jerry Quinn for major performance improvements in C++ formatted 45767 I/O. 45768 45769 * Ken Raeburn for various improvements to checker, MIPS ports and 45770 various cleanups in the compiler. 45771 45772 * Rolf W. Rasmussen for hacking on AWT. 45773 45774 * David Reese of Sun Microsystems contributed to the Solaris on 45775 PowerPC port. 45776 45777 * John Regehr for running automated regression testing of GCC and 45778 reporting numerous bugs. 45779 45780 * Volker Reichelt for running automated regression testing of GCC and 45781 reporting numerous bugs and for keeping up with the problem 45782 reports. 45783 45784 * Joern Rennecke for maintaining the sh port, loop, regmove & reload 45785 hacking and developing and maintaining the Epiphany port. 45786 45787 * Loren J. Rittle for improvements to libstdc++-v3 including the 45788 FreeBSD port, threading fixes, thread-related configury changes, 45789 critical threading documentation, and solutions to really tricky 45790 I/O problems, as well as keeping GCC properly working on FreeBSD 45791 and continuous testing. 45792 45793 * Craig Rodrigues for processing tons of bug reports. 45794 45795 * Ola Ro"nnerup for work on mt_alloc. 45796 45797 * Gavin Romig-Koch for lots of behind the scenes MIPS work. 45798 45799 * David Ronis inspired and encouraged Craig to rewrite the G77 45800 documentation in texinfo format by contributing a first pass at a 45801 translation of the old 'g77-0.5.16/f/DOC' file. 45802 45803 * Ken Rose for fixes to GCC's delay slot filling code. 45804 45805 * Ira Rosen for her contributions to the auto-vectorizer. 45806 45807 * Paul Rubin wrote most of the preprocessor. 45808 45809 * Pe'tur Runo'lfsson for major performance improvements in C++ 45810 formatted I/O and large file support in C++ filebuf. 45811 45812 * Chip Salzenberg for libstdc++ patches and improvements to locales, 45813 traits, Makefiles, libio, libtool hackery, and "long long" support. 45814 45815 * Juha Sarlin for improvements to the H8 code generator. 45816 45817 * Greg Satz assisted in making GCC work on HP-UX for the 9000 series 45818 300. 45819 45820 * Roger Sayle for improvements to constant folding and GCC's RTL 45821 optimizers as well as for fixing numerous bugs. 45822 45823 * Bradley Schatz for his work on the GCJ FAQ. 45824 45825 * Peter Schauer wrote the code to allow debugging to work on the 45826 Alpha. 45827 45828 * William Schelter did most of the work on the Intel 80386 support. 45829 45830 * Tobias Schlu"ter for work on GNU Fortran. 45831 45832 * Bernd Schmidt for various code generation improvements and major 45833 work in the reload pass, serving as release manager for GCC 2.95.3, 45834 and work on the Blackfin and C6X ports. 45835 45836 * Peter Schmid for constant testing of libstdc++--especially 45837 application testing, going above and beyond what was requested for 45838 the release criteria--and libstdc++ header file tweaks. 45839 45840 * Jason Schroeder for jcf-dump patches. 45841 45842 * Andreas Schwab for his work on the m68k port. 45843 45844 * Lars Segerlund for work on GNU Fortran. 45845 45846 * Dodji Seketeli for numerous C++ bug fixes and debug info 45847 improvements. 45848 45849 * Tim Shen for major work on '<regex>'. 45850 45851 * Joel Sherrill for his direction via the steering committee, RTEMS 45852 contributions and RTEMS testing. 45853 45854 * Nathan Sidwell for many C++ fixes/improvements. 45855 45856 * Jeffrey Siegal for helping RMS with the original design of GCC, 45857 some code which handles the parse tree and RTL data structures, 45858 constant folding and help with the original VAX & m68k ports. 45859 45860 * Kenny Simpson for prompting libstdc++ fixes due to defect reports 45861 from the LWG (thereby keeping GCC in line with updates from the 45862 ISO). 45863 45864 * Franz Sirl for his ongoing work with making the PPC port stable for 45865 GNU/Linux. 45866 45867 * Andrey Slepuhin for assorted AIX hacking. 45868 45869 * Trevor Smigiel for contributing the SPU port. 45870 45871 * Christopher Smith did the port for Convex machines. 45872 45873 * Danny Smith for his major efforts on the Mingw (and Cygwin) ports. 45874 Retired from GCC maintainership August 2010, having mentored two 45875 new maintainers into the role. 45876 45877 * Randy Smith finished the Sun FPA support. 45878 45879 * Ed Smith-Rowland for his continuous work on libstdc++-v3, special 45880 functions, '<random>', and various improvements to C++11 features. 45881 45882 * Scott Snyder for queue, iterator, istream, and string fixes and 45883 libstdc++ testsuite entries. Also for providing the patch to G77 45884 to add rudimentary support for 'INTEGER*1', 'INTEGER*2', and 45885 'LOGICAL*1'. 45886 45887 * Zdenek Sojka for running automated regression testing of GCC and 45888 reporting numerous bugs. 45889 45890 * Arseny Solokha for running automated regression testing of GCC and 45891 reporting numerous bugs. 45892 45893 * Jayant Sonar for contributing the CR16 port. 45894 45895 * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique. 45896 45897 * Richard Stallman, for writing the original GCC and launching the 45898 GNU project. 45899 45900 * Jan Stein of the Chalmers Computer Society provided support for 45901 Genix, as well as part of the 32000 machine description. 45902 45903 * Gerhard Steinmetz for running automated regression testing of GCC 45904 and reporting numerous bugs. 45905 45906 * Nigel Stephens for various mips16 related fixes/improvements. 45907 45908 * Jonathan Stone wrote the machine description for the Pyramid 45909 computer. 45910 45911 * Graham Stott for various infrastructure improvements. 45912 45913 * John Stracke for his Java HTTP protocol fixes. 45914 45915 * Mike Stump for his Elxsi port, G++ contributions over the years and 45916 more recently his vxworks contributions 45917 45918 * Jeff Sturm for Java porting help, bug fixes, and encouragement. 45919 45920 * Zhendong Su for running automated regression testing of GCC and 45921 reporting numerous bugs. 45922 45923 * Chengnian Sun for running automated regression testing of GCC and 45924 reporting numerous bugs. 45925 45926 * Shigeya Suzuki for this fixes for the bsdi platforms. 45927 45928 * Ian Lance Taylor for the Go frontend, the initial mips16 and mips64 45929 support, general configury hacking, fixincludes, etc. 45930 45931 * Holger Teutsch provided the support for the Clipper CPU. 45932 45933 * Gary Thomas for his ongoing work to make the PPC work for 45934 GNU/Linux. 45935 45936 * Paul Thomas for contributions to GNU Fortran. 45937 45938 * Philipp Thomas for random bug fixes throughout the compiler 45939 45940 * Jason Thorpe for thread support in libstdc++ on NetBSD. 45941 45942 * Kresten Krab Thorup wrote the run time support for the Objective-C 45943 language and the fantastic Java bytecode interpreter. 45944 45945 * Michael Tiemann for random bug fixes, the first instruction 45946 scheduler, initial C++ support, function integration, NS32k, SPARC 45947 and M88k machine description work, delay slot scheduling. 45948 45949 * Andreas Tobler for his work porting libgcj to Darwin. 45950 45951 * Teemu Torma for thread safe exception handling support. 45952 45953 * Leonard Tower wrote parts of the parser, RTL generator, and RTL 45954 definitions, and of the VAX machine description. 45955 45956 * Daniel Towner and Hariharan Sandanagobalane contributed and 45957 maintain the picoChip port. 45958 45959 * Tom Tromey for internationalization support and for his many Java 45960 contributions and libgcj maintainership. 45961 45962 * Lassi Tuura for improvements to config.guess to determine HP 45963 processor types. 45964 45965 * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes. 45966 45967 * Andy Vaught for the design and initial implementation of the GNU 45968 Fortran front end. 45969 45970 * Brent Verner for work with the libstdc++ cshadow files and their 45971 associated configure steps. 45972 45973 * Todd Vierling for contributions for NetBSD ports. 45974 45975 * Andrew Waterman for contributing the RISC-V port, as well as 45976 maintaining it. 45977 45978 * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML 45979 guidance and maintaining libstdc++. 45980 45981 * Dean Wakerley for converting the install documentation from HTML to 45982 texinfo in time for GCC 3.0. 45983 45984 * Krister Walfridsson for random bug fixes. 45985 45986 * Feng Wang for contributions to GNU Fortran. 45987 45988 * Stephen M. Webb for time and effort on making libstdc++ shadow 45989 files work with the tricky Solaris 8+ headers, and for pushing the 45990 build-time header tree. Also, for starting and driving the 45991 '<regex>' effort. 45992 45993 * John Wehle for various improvements for the x86 code generator, 45994 related infrastructure improvements to help x86 code generation, 45995 value range propagation and other work, WE32k port. 45996 45997 * Ulrich Weigand for work on the s390 port. 45998 45999 * Janus Weil for contributions to GNU Fortran. 46000 46001 * Zack Weinberg for major work on cpplib and various other bug fixes. 46002 46003 * Matt Welsh for help with Linux Threads support in GCJ. 46004 46005 * Urban Widmark for help fixing java.io. 46006 46007 * Mark Wielaard for new Java library code and his work integrating 46008 with Classpath. 46009 46010 * Dale Wiles helped port GCC to the Tahoe. 46011 46012 * Bob Wilson from Tensilica, Inc. for the Xtensa port. 46013 46014 * Jim Wilson for his direction via the steering committee, tackling 46015 hard problems in various places that nobody else wanted to work on, 46016 strength reduction and other loop optimizations. 46017 46018 * Paul Woegerer and Tal Agmon for the CRX port. 46019 46020 * Carlo Wood for various fixes. 46021 46022 * Tom Wood for work on the m88k port. 46023 46024 * Chung-Ju Wu for his work on the Andes NDS32 port. 46025 46026 * Canqun Yang for work on GNU Fortran. 46027 46028 * Masanobu Yuhara of Fujitsu Laboratories implemented the machine 46029 description for the Tron architecture (specifically, the Gmicro). 46030 46031 * Kevin Zachmann helped port GCC to the Tahoe. 46032 46033 * Ayal Zaks for Swing Modulo Scheduling (SMS). 46034 46035 * Qirun Zhang for running automated regression testing of GCC and 46036 reporting numerous bugs. 46037 46038 * Xiaoqiang Zhang for work on GNU Fortran. 46039 46040 * Gilles Zunino for help porting Java to Irix. 46041 46042 The following people are recognized for their contributions to GNAT, 46043the Ada front end of GCC: 46044 * Bernard Banner 46045 46046 * Romain Berrendonner 46047 46048 * Geert Bosch 46049 46050 * Emmanuel Briot 46051 46052 * Joel Brobecker 46053 46054 * Ben Brosgol 46055 46056 * Vincent Celier 46057 46058 * Arnaud Charlet 46059 46060 * Chien Chieng 46061 46062 * Cyrille Comar 46063 46064 * Cyrille Crozes 46065 46066 * Robert Dewar 46067 46068 * Gary Dismukes 46069 46070 * Robert Duff 46071 46072 * Ed Falis 46073 46074 * Ramon Fernandez 46075 46076 * Sam Figueroa 46077 46078 * Vasiliy Fofanov 46079 46080 * Michael Friess 46081 46082 * Franco Gasperoni 46083 46084 * Ted Giering 46085 46086 * Matthew Gingell 46087 46088 * Laurent Guerby 46089 46090 * Jerome Guitton 46091 46092 * Olivier Hainque 46093 46094 * Jerome Hugues 46095 46096 * Hristian Kirtchev 46097 46098 * Jerome Lambourg 46099 46100 * Bruno Leclerc 46101 46102 * Albert Lee 46103 46104 * Sean McNeil 46105 46106 * Javier Miranda 46107 46108 * Laurent Nana 46109 46110 * Pascal Obry 46111 46112 * Dong-Ik Oh 46113 46114 * Laurent Pautet 46115 46116 * Brett Porter 46117 46118 * Thomas Quinot 46119 46120 * Nicolas Roche 46121 46122 * Pat Rogers 46123 46124 * Jose Ruiz 46125 46126 * Douglas Rupp 46127 46128 * Sergey Rybin 46129 46130 * Gail Schenker 46131 46132 * Ed Schonberg 46133 46134 * Nicolas Setton 46135 46136 * Samuel Tardieu 46137 46138 The following people are recognized for their contributions of new 46139features, bug reports, testing and integration of classpath/libgcj for 46140GCC version 4.1: 46141 * Lillian Angel for 'JTree' implementation and lots Free Swing 46142 additions and bug fixes. 46143 46144 * Wolfgang Baer for 'GapContent' bug fixes. 46145 46146 * Anthony Balkissoon for 'JList', Free Swing 1.5 updates and mouse 46147 event fixes, lots of Free Swing work including 'JTable' editing. 46148 46149 * Stuart Ballard for RMI constant fixes. 46150 46151 * Goffredo Baroncelli for 'HTTPURLConnection' fixes. 46152 46153 * Gary Benson for 'MessageFormat' fixes. 46154 46155 * Daniel Bonniot for 'Serialization' fixes. 46156 46157 * Chris Burdess for lots of gnu.xml and http protocol fixes, 'StAX' 46158 and 'DOM xml:id' support. 46159 46160 * Ka-Hing Cheung for 'TreePath' and 'TreeSelection' fixes. 46161 46162 * Archie Cobbs for build fixes, VM interface updates, 46163 'URLClassLoader' updates. 46164 46165 * Kelley Cook for build fixes. 46166 46167 * Martin Cordova for Suggestions for better 'SocketTimeoutException'. 46168 46169 * David Daney for 'BitSet' bug fixes, 'HttpURLConnection' rewrite and 46170 improvements. 46171 46172 * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo 46173 2D support. Lots of imageio framework additions, lots of AWT and 46174 Free Swing bug fixes. 46175 46176 * Jeroen Frijters for 'ClassLoader' and nio cleanups, serialization 46177 fixes, better 'Proxy' support, bug fixes and IKVM integration. 46178 46179 * Santiago Gala for 'AccessControlContext' fixes. 46180 46181 * Nicolas Geoffray for 'VMClassLoader' and 'AccessController' 46182 improvements. 46183 46184 * David Gilbert for 'basic' and 'metal' icon and plaf support and 46185 lots of documenting, Lots of Free Swing and metal theme additions. 46186 'MetalIconFactory' implementation. 46187 46188 * Anthony Green for 'MIDI' framework, 'ALSA' and 'DSSI' providers. 46189 46190 * Andrew Haley for 'Serialization' and 'URLClassLoader' fixes, gcj 46191 build speedups. 46192 46193 * Kim Ho for 'JFileChooser' implementation. 46194 46195 * Andrew John Hughes for 'Locale' and net fixes, URI RFC2986 updates, 46196 'Serialization' fixes, 'Properties' XML support and generic branch 46197 work, VMIntegration guide update. 46198 46199 * Bastiaan Huisman for 'TimeZone' bug fixing. 46200 46201 * Andreas Jaeger for mprec updates. 46202 46203 * Paul Jenner for better '-Werror' support. 46204 46205 * Ito Kazumitsu for 'NetworkInterface' implementation and updates. 46206 46207 * Roman Kennke for 'BoxLayout', 'GrayFilter' and 'SplitPane', plus 46208 bug fixes all over. Lots of Free Swing work including styled text. 46209 46210 * Simon Kitching for 'String' cleanups and optimization suggestions. 46211 46212 * Michael Koch for configuration fixes, 'Locale' updates, bug and 46213 build fixes. 46214 46215 * Guilhem Lavaux for configuration, thread and channel fixes and 46216 Kaffe integration. JCL native 'Pointer' updates. Logger bug 46217 fixes. 46218 46219 * David Lichteblau for JCL support library global/local reference 46220 cleanups. 46221 46222 * Aaron Luchko for JDWP updates and documentation fixes. 46223 46224 * Ziga Mahkovec for 'Graphics2D' upgraded to Cairo 0.5 and new regex 46225 features. 46226 46227 * Sven de Marothy for BMP imageio support, CSS and 'TextLayout' 46228 fixes. 'GtkImage' rewrite, 2D, awt, free swing and date/time fixes 46229 and implementing the Qt4 peers. 46230 46231 * Casey Marshall for crypto algorithm fixes, 'FileChannel' lock, 46232 'SystemLogger' and 'FileHandler' rotate implementations, NIO 46233 'FileChannel.map' support, security and policy updates. 46234 46235 * Bryce McKinlay for RMI work. 46236 46237 * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus 46238 testing and documenting. 46239 46240 * Kalle Olavi Niemitalo for build fixes. 46241 46242 * Rainer Orth for build fixes. 46243 46244 * Andrew Overholt for 'File' locking fixes. 46245 46246 * Ingo Proetel for 'Image', 'Logger' and 'URLClassLoader' updates. 46247 46248 * Olga Rodimina for 'MenuSelectionManager' implementation. 46249 46250 * Jan Roehrich for 'BasicTreeUI' and 'JTree' fixes. 46251 46252 * Julian Scheid for documentation updates and gjdoc support. 46253 46254 * Christian Schlichtherle for zip fixes and cleanups. 46255 46256 * Robert Schuster for documentation updates and beans fixes, 46257 'TreeNode' enumerations and 'ActionCommand' and various fixes, XML 46258 and URL, AWT and Free Swing bug fixes. 46259 46260 * Keith Seitz for lots of JDWP work. 46261 46262 * Christian Thalinger for 64-bit cleanups, Configuration and VM 46263 interface fixes and 'CACAO' integration, 'fdlibm' updates. 46264 46265 * Gael Thomas for 'VMClassLoader' boot packages support suggestions. 46266 46267 * Andreas Tobler for Darwin and Solaris testing and fixing, 'Qt4' 46268 support for Darwin/OS X, 'Graphics2D' support, 'gtk+' updates. 46269 46270 * Dalibor Topic for better 'DEBUG' support, build cleanups and Kaffe 46271 integration. 'Qt4' build infrastructure, 'SHA1PRNG' and 46272 'GdkPixbugDecoder' updates. 46273 46274 * Tom Tromey for Eclipse integration, generics work, lots of bug 46275 fixes and gcj integration including coordinating The Big Merge. 46276 46277 * Mark Wielaard for bug fixes, packaging and release management, 46278 'Clipboard' implementation, system call interrupts and network 46279 timeouts and 'GdkPixpufDecoder' fixes. 46280 46281 In addition to the above, all of which also contributed time and energy 46282in testing GCC, we would like to thank the following for their 46283contributions to testing: 46284 46285 * Michael Abd-El-Malek 46286 46287 * Thomas Arend 46288 46289 * Bonzo Armstrong 46290 46291 * Steven Ashe 46292 46293 * Chris Baldwin 46294 46295 * David Billinghurst 46296 46297 * Jim Blandy 46298 46299 * Stephane Bortzmeyer 46300 46301 * Horst von Brand 46302 46303 * Frank Braun 46304 46305 * Rodney Brown 46306 46307 * Sidney Cadot 46308 46309 * Bradford Castalia 46310 46311 * Robert Clark 46312 46313 * Jonathan Corbet 46314 46315 * Ralph Doncaster 46316 46317 * Richard Emberson 46318 46319 * Levente Farkas 46320 46321 * Graham Fawcett 46322 46323 * Mark Fernyhough 46324 46325 * Robert A. French 46326 46327 * Jo"rgen Freyh 46328 46329 * Mark K. Gardner 46330 46331 * Charles-Antoine Gauthier 46332 46333 * Yung Shing Gene 46334 46335 * David Gilbert 46336 46337 * Simon Gornall 46338 46339 * Fred Gray 46340 46341 * John Griffin 46342 46343 * Patrik Hagglund 46344 46345 * Phil Hargett 46346 46347 * Amancio Hasty 46348 46349 * Takafumi Hayashi 46350 46351 * Bryan W. Headley 46352 46353 * Kevin B. Hendricks 46354 46355 * Joep Jansen 46356 46357 * Christian Joensson 46358 46359 * Michel Kern 46360 46361 * David Kidd 46362 46363 * Tobias Kuipers 46364 46365 * Anand Krishnaswamy 46366 46367 * A. O. V. Le Blanc 46368 46369 * llewelly 46370 46371 * Damon Love 46372 46373 * Brad Lucier 46374 46375 * Matthias Klose 46376 46377 * Martin Knoblauch 46378 46379 * Rick Lutowski 46380 46381 * Jesse Macnish 46382 46383 * Stefan Morrell 46384 46385 * Anon A. Mous 46386 46387 * Matthias Mueller 46388 46389 * Pekka Nikander 46390 46391 * Rick Niles 46392 46393 * Jon Olson 46394 46395 * Magnus Persson 46396 46397 * Chris Pollard 46398 46399 * Richard Polton 46400 46401 * Derk Reefman 46402 46403 * David Rees 46404 46405 * Paul Reilly 46406 46407 * Tom Reilly 46408 46409 * Torsten Rueger 46410 46411 * Danny Sadinoff 46412 46413 * Marc Schifer 46414 46415 * Erik Schnetter 46416 46417 * Wayne K. Schroll 46418 46419 * David Schuler 46420 46421 * Vin Shelton 46422 46423 * Tim Souder 46424 46425 * Adam Sulmicki 46426 46427 * Bill Thorson 46428 46429 * George Talbot 46430 46431 * Pedro A. M. Vazquez 46432 46433 * Gregory Warnes 46434 46435 * Ian Watson 46436 46437 * David E. Young 46438 46439 * And many others 46440 46441 And finally we'd like to thank everyone who uses the compiler, provides 46442feedback and generally reminds us why we're doing this work in the first 46443place. 46444 46445 46446File: gccint.info, Node: Option Index, Next: Concept Index, Prev: Contributors, Up: Top 46447 46448Option Index 46449************ 46450 46451GCC's command line options are indexed here without any initial '-' or 46452'--'. Where an option has both positive and negative forms (such as 46453'-fOPTION' and '-fno-OPTION'), relevant entries in the manual are 46454indexed under the most appropriate form; it may sometimes be useful to 46455look up both forms. 46456 46457�[index�] 46458* Menu: 46459 46460* fltrans: Internal flags. (line 18) 46461* fltrans-output-list: Internal flags. (line 23) 46462* fresolution: Internal flags. (line 27) 46463* fwpa: Internal flags. (line 9) 46464* msoft-float: Soft float library routines. 46465 (line 6) 46466 46467 46468File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top 46469 46470Concept Index 46471************* 46472 46473�[index�] 46474* Menu: 46475 46476* ! in constraint: Multi-Alternative. (line 48) 46477* # in constraint: Modifiers. (line 78) 46478* # in template: Output Template. (line 66) 46479* #pragma: Misc. (line 409) 46480* $ in constraint: Multi-Alternative. (line 57) 46481* % in constraint: Modifiers. (line 52) 46482* % in GTY option: GTY Options. (line 18) 46483* % in template: Output Template. (line 6) 46484* & in constraint: Modifiers. (line 25) 46485* (gimple: Logical Operators. (line 169) 46486* (gimple <1>: Logical Operators. (line 173) 46487* (gimple <2>: Logical Operators. (line 177) 46488* (gimple_stmt_iterator: GIMPLE API. (line 30) 46489* (nil): RTL Objects. (line 73) 46490* * in constraint: Modifiers. (line 83) 46491* * in template: Output Statement. (line 29) 46492* *gimple_build_asm_vec: GIMPLE_ASM. (line 6) 46493* *gimple_build_assign: GIMPLE_ASSIGN. (line 6) 46494* *gimple_build_assign <1>: GIMPLE_ASSIGN. (line 18) 46495* *gimple_build_assign <2>: GIMPLE_ASSIGN. (line 29) 46496* *gimple_build_assign <3>: GIMPLE_ASSIGN. (line 35) 46497* *gimple_build_bind: GIMPLE_BIND. (line 6) 46498* *gimple_build_call: GIMPLE_CALL. (line 6) 46499* *gimple_build_call_from_tree: GIMPLE_CALL. (line 15) 46500* *gimple_build_call_vec: GIMPLE_CALL. (line 25) 46501* *gimple_build_catch: GIMPLE_CATCH. (line 6) 46502* *gimple_build_cond: GIMPLE_COND. (line 6) 46503* *gimple_build_cond_from_tree: GIMPLE_COND. (line 14) 46504* *gimple_build_debug_bind: GIMPLE_DEBUG. (line 6) 46505* *gimple_build_eh_filter: GIMPLE_EH_FILTER. (line 6) 46506* *gimple_build_goto: GIMPLE_GOTO. (line 6) 46507* *gimple_build_label: GIMPLE_LABEL. (line 6) 46508* *gimple_build_omp_atomic_load: GIMPLE_OMP_ATOMIC_LOAD. 46509 (line 6) 46510* *gimple_build_omp_atomic_store: GIMPLE_OMP_ATOMIC_STORE. 46511 (line 6) 46512* *gimple_build_omp_continue: GIMPLE_OMP_CONTINUE. 46513 (line 6) 46514* *gimple_build_omp_critical: GIMPLE_OMP_CRITICAL. 46515 (line 6) 46516* *gimple_build_omp_for: GIMPLE_OMP_FOR. (line 6) 46517* *gimple_build_omp_parallel: GIMPLE_OMP_PARALLEL. 46518 (line 6) 46519* *gimple_build_omp_sections: GIMPLE_OMP_SECTIONS. 46520 (line 6) 46521* *gimple_build_omp_single: GIMPLE_OMP_SINGLE. (line 6) 46522* *gimple_build_resx: GIMPLE_RESX. (line 6) 46523* *gimple_build_return: GIMPLE_RETURN. (line 6) 46524* *gimple_build_switch: GIMPLE_SWITCH. (line 6) 46525* *gimple_build_try: GIMPLE_TRY. (line 6) 46526* + in constraint: Modifiers. (line 12) 46527* -fsection-anchors: Special Accessors. (line 117) 46528* -fsection-anchors <1>: Anchored Addresses. (line 6) 46529* /c in RTL dump: Flags. (line 230) 46530* /f in RTL dump: Flags. (line 238) 46531* /i in RTL dump: Flags. (line 283) 46532* /j in RTL dump: Flags. (line 295) 46533* /s in RTL dump: Flags. (line 254) 46534* /u in RTL dump: Flags. (line 307) 46535* /v in RTL dump: Flags. (line 339) 46536* 0 in constraint: Simple Constraints. (line 128) 46537* < in constraint: Simple Constraints. (line 47) 46538* = in constraint: Modifiers. (line 8) 46539* > in constraint: Simple Constraints. (line 59) 46540* ? in constraint: Multi-Alternative. (line 42) 46541* \: Output Template. (line 46) 46542* ^ in constraint: Multi-Alternative. (line 53) 46543* __absvdi2: Integer library routines. 46544 (line 106) 46545* __absvsi2: Integer library routines. 46546 (line 105) 46547* __addda3: Fixed-point fractional library routines. 46548 (line 52) 46549* __adddf3: Soft float library routines. 46550 (line 22) 46551* __adddq3: Fixed-point fractional library routines. 46552 (line 39) 46553* __addha3: Fixed-point fractional library routines. 46554 (line 49) 46555* __addhq3: Fixed-point fractional library routines. 46556 (line 37) 46557* __addqq3: Fixed-point fractional library routines. 46558 (line 35) 46559* __addsa3: Fixed-point fractional library routines. 46560 (line 51) 46561* __addsf3: Soft float library routines. 46562 (line 21) 46563* __addsq3: Fixed-point fractional library routines. 46564 (line 38) 46565* __addta3: Fixed-point fractional library routines. 46566 (line 53) 46567* __addtf3: Soft float library routines. 46568 (line 23) 46569* __adduda3: Fixed-point fractional library routines. 46570 (line 59) 46571* __addudq3: Fixed-point fractional library routines. 46572 (line 47) 46573* __adduha3: Fixed-point fractional library routines. 46574 (line 55) 46575* __adduhq3: Fixed-point fractional library routines. 46576 (line 43) 46577* __adduqq3: Fixed-point fractional library routines. 46578 (line 41) 46579* __addusa3: Fixed-point fractional library routines. 46580 (line 57) 46581* __addusq3: Fixed-point fractional library routines. 46582 (line 45) 46583* __adduta3: Fixed-point fractional library routines. 46584 (line 61) 46585* __addvdi3: Integer library routines. 46586 (line 110) 46587* __addvsi3: Integer library routines. 46588 (line 109) 46589* __addxf3: Soft float library routines. 46590 (line 25) 46591* __ashlda3: Fixed-point fractional library routines. 46592 (line 358) 46593* __ashldi3: Integer library routines. 46594 (line 13) 46595* __ashldq3: Fixed-point fractional library routines. 46596 (line 346) 46597* __ashlha3: Fixed-point fractional library routines. 46598 (line 356) 46599* __ashlhq3: Fixed-point fractional library routines. 46600 (line 344) 46601* __ashlqq3: Fixed-point fractional library routines. 46602 (line 343) 46603* __ashlsa3: Fixed-point fractional library routines. 46604 (line 357) 46605* __ashlsi3: Integer library routines. 46606 (line 12) 46607* __ashlsq3: Fixed-point fractional library routines. 46608 (line 345) 46609* __ashlta3: Fixed-point fractional library routines. 46610 (line 359) 46611* __ashlti3: Integer library routines. 46612 (line 14) 46613* __ashluda3: Fixed-point fractional library routines. 46614 (line 365) 46615* __ashludq3: Fixed-point fractional library routines. 46616 (line 354) 46617* __ashluha3: Fixed-point fractional library routines. 46618 (line 361) 46619* __ashluhq3: Fixed-point fractional library routines. 46620 (line 350) 46621* __ashluqq3: Fixed-point fractional library routines. 46622 (line 348) 46623* __ashlusa3: Fixed-point fractional library routines. 46624 (line 363) 46625* __ashlusq3: Fixed-point fractional library routines. 46626 (line 352) 46627* __ashluta3: Fixed-point fractional library routines. 46628 (line 367) 46629* __ashrda3: Fixed-point fractional library routines. 46630 (line 378) 46631* __ashrdi3: Integer library routines. 46632 (line 18) 46633* __ashrdq3: Fixed-point fractional library routines. 46634 (line 374) 46635* __ashrha3: Fixed-point fractional library routines. 46636 (line 376) 46637* __ashrhq3: Fixed-point fractional library routines. 46638 (line 372) 46639* __ashrqq3: Fixed-point fractional library routines. 46640 (line 371) 46641* __ashrsa3: Fixed-point fractional library routines. 46642 (line 377) 46643* __ashrsi3: Integer library routines. 46644 (line 17) 46645* __ashrsq3: Fixed-point fractional library routines. 46646 (line 373) 46647* __ashrta3: Fixed-point fractional library routines. 46648 (line 379) 46649* __ashrti3: Integer library routines. 46650 (line 19) 46651* __bid_adddd3: Decimal float library routines. 46652 (line 23) 46653* __bid_addsd3: Decimal float library routines. 46654 (line 19) 46655* __bid_addtd3: Decimal float library routines. 46656 (line 27) 46657* __bid_divdd3: Decimal float library routines. 46658 (line 66) 46659* __bid_divsd3: Decimal float library routines. 46660 (line 62) 46661* __bid_divtd3: Decimal float library routines. 46662 (line 70) 46663* __bid_eqdd2: Decimal float library routines. 46664 (line 258) 46665* __bid_eqsd2: Decimal float library routines. 46666 (line 256) 46667* __bid_eqtd2: Decimal float library routines. 46668 (line 260) 46669* __bid_extendddtd2: Decimal float library routines. 46670 (line 91) 46671* __bid_extendddtf: Decimal float library routines. 46672 (line 139) 46673* __bid_extendddxf: Decimal float library routines. 46674 (line 133) 46675* __bid_extenddfdd: Decimal float library routines. 46676 (line 146) 46677* __bid_extenddftd: Decimal float library routines. 46678 (line 106) 46679* __bid_extendsddd2: Decimal float library routines. 46680 (line 87) 46681* __bid_extendsddf: Decimal float library routines. 46682 (line 127) 46683* __bid_extendsdtd2: Decimal float library routines. 46684 (line 89) 46685* __bid_extendsdtf: Decimal float library routines. 46686 (line 137) 46687* __bid_extendsdxf: Decimal float library routines. 46688 (line 131) 46689* __bid_extendsfdd: Decimal float library routines. 46690 (line 102) 46691* __bid_extendsfsd: Decimal float library routines. 46692 (line 144) 46693* __bid_extendsftd: Decimal float library routines. 46694 (line 104) 46695* __bid_extendtftd: Decimal float library routines. 46696 (line 148) 46697* __bid_extendxftd: Decimal float library routines. 46698 (line 108) 46699* __bid_fixdddi: Decimal float library routines. 46700 (line 169) 46701* __bid_fixddsi: Decimal float library routines. 46702 (line 161) 46703* __bid_fixsddi: Decimal float library routines. 46704 (line 167) 46705* __bid_fixsdsi: Decimal float library routines. 46706 (line 159) 46707* __bid_fixtddi: Decimal float library routines. 46708 (line 171) 46709* __bid_fixtdsi: Decimal float library routines. 46710 (line 163) 46711* __bid_fixunsdddi: Decimal float library routines. 46712 (line 186) 46713* __bid_fixunsddsi: Decimal float library routines. 46714 (line 177) 46715* __bid_fixunssddi: Decimal float library routines. 46716 (line 184) 46717* __bid_fixunssdsi: Decimal float library routines. 46718 (line 175) 46719* __bid_fixunstddi: Decimal float library routines. 46720 (line 188) 46721* __bid_fixunstdsi: Decimal float library routines. 46722 (line 179) 46723* __bid_floatdidd: Decimal float library routines. 46724 (line 204) 46725* __bid_floatdisd: Decimal float library routines. 46726 (line 202) 46727* __bid_floatditd: Decimal float library routines. 46728 (line 206) 46729* __bid_floatsidd: Decimal float library routines. 46730 (line 195) 46731* __bid_floatsisd: Decimal float library routines. 46732 (line 193) 46733* __bid_floatsitd: Decimal float library routines. 46734 (line 197) 46735* __bid_floatunsdidd: Decimal float library routines. 46736 (line 222) 46737* __bid_floatunsdisd: Decimal float library routines. 46738 (line 220) 46739* __bid_floatunsditd: Decimal float library routines. 46740 (line 224) 46741* __bid_floatunssidd: Decimal float library routines. 46742 (line 213) 46743* __bid_floatunssisd: Decimal float library routines. 46744 (line 211) 46745* __bid_floatunssitd: Decimal float library routines. 46746 (line 215) 46747* __bid_gedd2: Decimal float library routines. 46748 (line 276) 46749* __bid_gesd2: Decimal float library routines. 46750 (line 274) 46751* __bid_getd2: Decimal float library routines. 46752 (line 278) 46753* __bid_gtdd2: Decimal float library routines. 46754 (line 303) 46755* __bid_gtsd2: Decimal float library routines. 46756 (line 301) 46757* __bid_gttd2: Decimal float library routines. 46758 (line 305) 46759* __bid_ledd2: Decimal float library routines. 46760 (line 294) 46761* __bid_lesd2: Decimal float library routines. 46762 (line 292) 46763* __bid_letd2: Decimal float library routines. 46764 (line 296) 46765* __bid_ltdd2: Decimal float library routines. 46766 (line 285) 46767* __bid_ltsd2: Decimal float library routines. 46768 (line 283) 46769* __bid_lttd2: Decimal float library routines. 46770 (line 287) 46771* __bid_muldd3: Decimal float library routines. 46772 (line 52) 46773* __bid_mulsd3: Decimal float library routines. 46774 (line 48) 46775* __bid_multd3: Decimal float library routines. 46776 (line 56) 46777* __bid_nedd2: Decimal float library routines. 46778 (line 267) 46779* __bid_negdd2: Decimal float library routines. 46780 (line 77) 46781* __bid_negsd2: Decimal float library routines. 46782 (line 75) 46783* __bid_negtd2: Decimal float library routines. 46784 (line 79) 46785* __bid_nesd2: Decimal float library routines. 46786 (line 265) 46787* __bid_netd2: Decimal float library routines. 46788 (line 269) 46789* __bid_subdd3: Decimal float library routines. 46790 (line 37) 46791* __bid_subsd3: Decimal float library routines. 46792 (line 33) 46793* __bid_subtd3: Decimal float library routines. 46794 (line 41) 46795* __bid_truncdddf: Decimal float library routines. 46796 (line 152) 46797* __bid_truncddsd2: Decimal float library routines. 46798 (line 93) 46799* __bid_truncddsf: Decimal float library routines. 46800 (line 123) 46801* __bid_truncdfsd: Decimal float library routines. 46802 (line 110) 46803* __bid_truncsdsf: Decimal float library routines. 46804 (line 150) 46805* __bid_trunctddd2: Decimal float library routines. 46806 (line 97) 46807* __bid_trunctddf: Decimal float library routines. 46808 (line 129) 46809* __bid_trunctdsd2: Decimal float library routines. 46810 (line 95) 46811* __bid_trunctdsf: Decimal float library routines. 46812 (line 125) 46813* __bid_trunctdtf: Decimal float library routines. 46814 (line 154) 46815* __bid_trunctdxf: Decimal float library routines. 46816 (line 135) 46817* __bid_trunctfdd: Decimal float library routines. 46818 (line 118) 46819* __bid_trunctfsd: Decimal float library routines. 46820 (line 114) 46821* __bid_truncxfdd: Decimal float library routines. 46822 (line 116) 46823* __bid_truncxfsd: Decimal float library routines. 46824 (line 112) 46825* __bid_unorddd2: Decimal float library routines. 46826 (line 234) 46827* __bid_unordsd2: Decimal float library routines. 46828 (line 232) 46829* __bid_unordtd2: Decimal float library routines. 46830 (line 236) 46831* __bswapdi2: Integer library routines. 46832 (line 161) 46833* __bswapsi2: Integer library routines. 46834 (line 160) 46835* __builtin_classify_type: Varargs. (line 48) 46836* __builtin_next_arg: Varargs. (line 39) 46837* __builtin_saveregs: Varargs. (line 22) 46838* __chkp_bndcl: Misc. (line 672) 46839* __chkp_bndcu: Misc. (line 678) 46840* __chkp_bndldx: Misc. (line 666) 46841* __chkp_bndmk: Misc. (line 653) 46842* __chkp_bndret: Misc. (line 684) 46843* __chkp_bndstx: Misc. (line 660) 46844* __chkp_intersect: Misc. (line 690) 46845* __chkp_narrow: Misc. (line 695) 46846* __chkp_sizeof: Misc. (line 701) 46847* __clear_cache: Miscellaneous routines. 46848 (line 9) 46849* __clzdi2: Integer library routines. 46850 (line 130) 46851* __clzsi2: Integer library routines. 46852 (line 129) 46853* __clzti2: Integer library routines. 46854 (line 131) 46855* __cmpda2: Fixed-point fractional library routines. 46856 (line 458) 46857* __cmpdf2: Soft float library routines. 46858 (line 163) 46859* __cmpdi2: Integer library routines. 46860 (line 86) 46861* __cmpdq2: Fixed-point fractional library routines. 46862 (line 447) 46863* __cmpha2: Fixed-point fractional library routines. 46864 (line 456) 46865* __cmphq2: Fixed-point fractional library routines. 46866 (line 445) 46867* __cmpqq2: Fixed-point fractional library routines. 46868 (line 444) 46869* __cmpsa2: Fixed-point fractional library routines. 46870 (line 457) 46871* __cmpsf2: Soft float library routines. 46872 (line 162) 46873* __cmpsq2: Fixed-point fractional library routines. 46874 (line 446) 46875* __cmpta2: Fixed-point fractional library routines. 46876 (line 459) 46877* __cmptf2: Soft float library routines. 46878 (line 164) 46879* __cmpti2: Integer library routines. 46880 (line 87) 46881* __cmpuda2: Fixed-point fractional library routines. 46882 (line 464) 46883* __cmpudq2: Fixed-point fractional library routines. 46884 (line 454) 46885* __cmpuha2: Fixed-point fractional library routines. 46886 (line 461) 46887* __cmpuhq2: Fixed-point fractional library routines. 46888 (line 451) 46889* __cmpuqq2: Fixed-point fractional library routines. 46890 (line 449) 46891* __cmpusa2: Fixed-point fractional library routines. 46892 (line 463) 46893* __cmpusq2: Fixed-point fractional library routines. 46894 (line 452) 46895* __cmputa2: Fixed-point fractional library routines. 46896 (line 466) 46897* __CTOR_LIST__: Initialization. (line 25) 46898* __ctzdi2: Integer library routines. 46899 (line 137) 46900* __ctzsi2: Integer library routines. 46901 (line 136) 46902* __ctzti2: Integer library routines. 46903 (line 138) 46904* __divda3: Fixed-point fractional library routines. 46905 (line 234) 46906* __divdc3: Soft float library routines. 46907 (line 250) 46908* __divdf3: Soft float library routines. 46909 (line 47) 46910* __divdi3: Integer library routines. 46911 (line 24) 46912* __divdq3: Fixed-point fractional library routines. 46913 (line 229) 46914* __divha3: Fixed-point fractional library routines. 46915 (line 231) 46916* __divhq3: Fixed-point fractional library routines. 46917 (line 227) 46918* __divqq3: Fixed-point fractional library routines. 46919 (line 225) 46920* __divsa3: Fixed-point fractional library routines. 46921 (line 233) 46922* __divsc3: Soft float library routines. 46923 (line 248) 46924* __divsf3: Soft float library routines. 46925 (line 46) 46926* __divsi3: Integer library routines. 46927 (line 23) 46928* __divsq3: Fixed-point fractional library routines. 46929 (line 228) 46930* __divta3: Fixed-point fractional library routines. 46931 (line 235) 46932* __divtc3: Soft float library routines. 46933 (line 252) 46934* __divtf3: Soft float library routines. 46935 (line 48) 46936* __divti3: Integer library routines. 46937 (line 25) 46938* __divxc3: Soft float library routines. 46939 (line 254) 46940* __divxf3: Soft float library routines. 46941 (line 50) 46942* __dpd_adddd3: Decimal float library routines. 46943 (line 21) 46944* __dpd_addsd3: Decimal float library routines. 46945 (line 17) 46946* __dpd_addtd3: Decimal float library routines. 46947 (line 25) 46948* __dpd_divdd3: Decimal float library routines. 46949 (line 64) 46950* __dpd_divsd3: Decimal float library routines. 46951 (line 60) 46952* __dpd_divtd3: Decimal float library routines. 46953 (line 68) 46954* __dpd_eqdd2: Decimal float library routines. 46955 (line 257) 46956* __dpd_eqsd2: Decimal float library routines. 46957 (line 255) 46958* __dpd_eqtd2: Decimal float library routines. 46959 (line 259) 46960* __dpd_extendddtd2: Decimal float library routines. 46961 (line 90) 46962* __dpd_extendddtf: Decimal float library routines. 46963 (line 138) 46964* __dpd_extendddxf: Decimal float library routines. 46965 (line 132) 46966* __dpd_extenddfdd: Decimal float library routines. 46967 (line 145) 46968* __dpd_extenddftd: Decimal float library routines. 46969 (line 105) 46970* __dpd_extendsddd2: Decimal float library routines. 46971 (line 86) 46972* __dpd_extendsddf: Decimal float library routines. 46973 (line 126) 46974* __dpd_extendsdtd2: Decimal float library routines. 46975 (line 88) 46976* __dpd_extendsdtf: Decimal float library routines. 46977 (line 136) 46978* __dpd_extendsdxf: Decimal float library routines. 46979 (line 130) 46980* __dpd_extendsfdd: Decimal float library routines. 46981 (line 101) 46982* __dpd_extendsfsd: Decimal float library routines. 46983 (line 143) 46984* __dpd_extendsftd: Decimal float library routines. 46985 (line 103) 46986* __dpd_extendtftd: Decimal float library routines. 46987 (line 147) 46988* __dpd_extendxftd: Decimal float library routines. 46989 (line 107) 46990* __dpd_fixdddi: Decimal float library routines. 46991 (line 168) 46992* __dpd_fixddsi: Decimal float library routines. 46993 (line 160) 46994* __dpd_fixsddi: Decimal float library routines. 46995 (line 166) 46996* __dpd_fixsdsi: Decimal float library routines. 46997 (line 158) 46998* __dpd_fixtddi: Decimal float library routines. 46999 (line 170) 47000* __dpd_fixtdsi: Decimal float library routines. 47001 (line 162) 47002* __dpd_fixunsdddi: Decimal float library routines. 47003 (line 185) 47004* __dpd_fixunsddsi: Decimal float library routines. 47005 (line 176) 47006* __dpd_fixunssddi: Decimal float library routines. 47007 (line 183) 47008* __dpd_fixunssdsi: Decimal float library routines. 47009 (line 174) 47010* __dpd_fixunstddi: Decimal float library routines. 47011 (line 187) 47012* __dpd_fixunstdsi: Decimal float library routines. 47013 (line 178) 47014* __dpd_floatdidd: Decimal float library routines. 47015 (line 203) 47016* __dpd_floatdisd: Decimal float library routines. 47017 (line 201) 47018* __dpd_floatditd: Decimal float library routines. 47019 (line 205) 47020* __dpd_floatsidd: Decimal float library routines. 47021 (line 194) 47022* __dpd_floatsisd: Decimal float library routines. 47023 (line 192) 47024* __dpd_floatsitd: Decimal float library routines. 47025 (line 196) 47026* __dpd_floatunsdidd: Decimal float library routines. 47027 (line 221) 47028* __dpd_floatunsdisd: Decimal float library routines. 47029 (line 219) 47030* __dpd_floatunsditd: Decimal float library routines. 47031 (line 223) 47032* __dpd_floatunssidd: Decimal float library routines. 47033 (line 212) 47034* __dpd_floatunssisd: Decimal float library routines. 47035 (line 210) 47036* __dpd_floatunssitd: Decimal float library routines. 47037 (line 214) 47038* __dpd_gedd2: Decimal float library routines. 47039 (line 275) 47040* __dpd_gesd2: Decimal float library routines. 47041 (line 273) 47042* __dpd_getd2: Decimal float library routines. 47043 (line 277) 47044* __dpd_gtdd2: Decimal float library routines. 47045 (line 302) 47046* __dpd_gtsd2: Decimal float library routines. 47047 (line 300) 47048* __dpd_gttd2: Decimal float library routines. 47049 (line 304) 47050* __dpd_ledd2: Decimal float library routines. 47051 (line 293) 47052* __dpd_lesd2: Decimal float library routines. 47053 (line 291) 47054* __dpd_letd2: Decimal float library routines. 47055 (line 295) 47056* __dpd_ltdd2: Decimal float library routines. 47057 (line 284) 47058* __dpd_ltsd2: Decimal float library routines. 47059 (line 282) 47060* __dpd_lttd2: Decimal float library routines. 47061 (line 286) 47062* __dpd_muldd3: Decimal float library routines. 47063 (line 50) 47064* __dpd_mulsd3: Decimal float library routines. 47065 (line 46) 47066* __dpd_multd3: Decimal float library routines. 47067 (line 54) 47068* __dpd_nedd2: Decimal float library routines. 47069 (line 266) 47070* __dpd_negdd2: Decimal float library routines. 47071 (line 76) 47072* __dpd_negsd2: Decimal float library routines. 47073 (line 74) 47074* __dpd_negtd2: Decimal float library routines. 47075 (line 78) 47076* __dpd_nesd2: Decimal float library routines. 47077 (line 264) 47078* __dpd_netd2: Decimal float library routines. 47079 (line 268) 47080* __dpd_subdd3: Decimal float library routines. 47081 (line 35) 47082* __dpd_subsd3: Decimal float library routines. 47083 (line 31) 47084* __dpd_subtd3: Decimal float library routines. 47085 (line 39) 47086* __dpd_truncdddf: Decimal float library routines. 47087 (line 151) 47088* __dpd_truncddsd2: Decimal float library routines. 47089 (line 92) 47090* __dpd_truncddsf: Decimal float library routines. 47091 (line 122) 47092* __dpd_truncdfsd: Decimal float library routines. 47093 (line 109) 47094* __dpd_truncsdsf: Decimal float library routines. 47095 (line 149) 47096* __dpd_trunctddd2: Decimal float library routines. 47097 (line 96) 47098* __dpd_trunctddf: Decimal float library routines. 47099 (line 128) 47100* __dpd_trunctdsd2: Decimal float library routines. 47101 (line 94) 47102* __dpd_trunctdsf: Decimal float library routines. 47103 (line 124) 47104* __dpd_trunctdtf: Decimal float library routines. 47105 (line 153) 47106* __dpd_trunctdxf: Decimal float library routines. 47107 (line 134) 47108* __dpd_trunctfdd: Decimal float library routines. 47109 (line 117) 47110* __dpd_trunctfsd: Decimal float library routines. 47111 (line 113) 47112* __dpd_truncxfdd: Decimal float library routines. 47113 (line 115) 47114* __dpd_truncxfsd: Decimal float library routines. 47115 (line 111) 47116* __dpd_unorddd2: Decimal float library routines. 47117 (line 233) 47118* __dpd_unordsd2: Decimal float library routines. 47119 (line 231) 47120* __dpd_unordtd2: Decimal float library routines. 47121 (line 235) 47122* __DTOR_LIST__: Initialization. (line 25) 47123* __eqdf2: Soft float library routines. 47124 (line 193) 47125* __eqsf2: Soft float library routines. 47126 (line 192) 47127* __eqtf2: Soft float library routines. 47128 (line 194) 47129* __extenddftf2: Soft float library routines. 47130 (line 67) 47131* __extenddfxf2: Soft float library routines. 47132 (line 68) 47133* __extendsfdf2: Soft float library routines. 47134 (line 64) 47135* __extendsftf2: Soft float library routines. 47136 (line 65) 47137* __extendsfxf2: Soft float library routines. 47138 (line 66) 47139* __ffsdi2: Integer library routines. 47140 (line 143) 47141* __ffsti2: Integer library routines. 47142 (line 144) 47143* __fixdfdi: Soft float library routines. 47144 (line 87) 47145* __fixdfsi: Soft float library routines. 47146 (line 80) 47147* __fixdfti: Soft float library routines. 47148 (line 93) 47149* __fixsfdi: Soft float library routines. 47150 (line 86) 47151* __fixsfsi: Soft float library routines. 47152 (line 79) 47153* __fixsfti: Soft float library routines. 47154 (line 92) 47155* __fixtfdi: Soft float library routines. 47156 (line 88) 47157* __fixtfsi: Soft float library routines. 47158 (line 81) 47159* __fixtfti: Soft float library routines. 47160 (line 94) 47161* __fixunsdfdi: Soft float library routines. 47162 (line 107) 47163* __fixunsdfsi: Soft float library routines. 47164 (line 100) 47165* __fixunsdfti: Soft float library routines. 47166 (line 114) 47167* __fixunssfdi: Soft float library routines. 47168 (line 106) 47169* __fixunssfsi: Soft float library routines. 47170 (line 99) 47171* __fixunssfti: Soft float library routines. 47172 (line 113) 47173* __fixunstfdi: Soft float library routines. 47174 (line 108) 47175* __fixunstfsi: Soft float library routines. 47176 (line 101) 47177* __fixunstfti: Soft float library routines. 47178 (line 115) 47179* __fixunsxfdi: Soft float library routines. 47180 (line 109) 47181* __fixunsxfsi: Soft float library routines. 47182 (line 102) 47183* __fixunsxfti: Soft float library routines. 47184 (line 116) 47185* __fixxfdi: Soft float library routines. 47186 (line 89) 47187* __fixxfsi: Soft float library routines. 47188 (line 82) 47189* __fixxfti: Soft float library routines. 47190 (line 95) 47191* __floatdidf: Soft float library routines. 47192 (line 127) 47193* __floatdisf: Soft float library routines. 47194 (line 126) 47195* __floatditf: Soft float library routines. 47196 (line 128) 47197* __floatdixf: Soft float library routines. 47198 (line 129) 47199* __floatsidf: Soft float library routines. 47200 (line 121) 47201* __floatsisf: Soft float library routines. 47202 (line 120) 47203* __floatsitf: Soft float library routines. 47204 (line 122) 47205* __floatsixf: Soft float library routines. 47206 (line 123) 47207* __floattidf: Soft float library routines. 47208 (line 133) 47209* __floattisf: Soft float library routines. 47210 (line 132) 47211* __floattitf: Soft float library routines. 47212 (line 134) 47213* __floattixf: Soft float library routines. 47214 (line 135) 47215* __floatundidf: Soft float library routines. 47216 (line 145) 47217* __floatundisf: Soft float library routines. 47218 (line 144) 47219* __floatunditf: Soft float library routines. 47220 (line 146) 47221* __floatundixf: Soft float library routines. 47222 (line 147) 47223* __floatunsidf: Soft float library routines. 47224 (line 139) 47225* __floatunsisf: Soft float library routines. 47226 (line 138) 47227* __floatunsitf: Soft float library routines. 47228 (line 140) 47229* __floatunsixf: Soft float library routines. 47230 (line 141) 47231* __floatuntidf: Soft float library routines. 47232 (line 151) 47233* __floatuntisf: Soft float library routines. 47234 (line 150) 47235* __floatuntitf: Soft float library routines. 47236 (line 152) 47237* __floatuntixf: Soft float library routines. 47238 (line 153) 47239* __fractdadf: Fixed-point fractional library routines. 47240 (line 643) 47241* __fractdadi: Fixed-point fractional library routines. 47242 (line 640) 47243* __fractdadq: Fixed-point fractional library routines. 47244 (line 623) 47245* __fractdaha2: Fixed-point fractional library routines. 47246 (line 624) 47247* __fractdahi: Fixed-point fractional library routines. 47248 (line 638) 47249* __fractdahq: Fixed-point fractional library routines. 47250 (line 621) 47251* __fractdaqi: Fixed-point fractional library routines. 47252 (line 637) 47253* __fractdaqq: Fixed-point fractional library routines. 47254 (line 620) 47255* __fractdasa2: Fixed-point fractional library routines. 47256 (line 625) 47257* __fractdasf: Fixed-point fractional library routines. 47258 (line 642) 47259* __fractdasi: Fixed-point fractional library routines. 47260 (line 639) 47261* __fractdasq: Fixed-point fractional library routines. 47262 (line 622) 47263* __fractdata2: Fixed-point fractional library routines. 47264 (line 626) 47265* __fractdati: Fixed-point fractional library routines. 47266 (line 641) 47267* __fractdauda: Fixed-point fractional library routines. 47268 (line 634) 47269* __fractdaudq: Fixed-point fractional library routines. 47270 (line 630) 47271* __fractdauha: Fixed-point fractional library routines. 47272 (line 632) 47273* __fractdauhq: Fixed-point fractional library routines. 47274 (line 628) 47275* __fractdauqq: Fixed-point fractional library routines. 47276 (line 627) 47277* __fractdausa: Fixed-point fractional library routines. 47278 (line 633) 47279* __fractdausq: Fixed-point fractional library routines. 47280 (line 629) 47281* __fractdauta: Fixed-point fractional library routines. 47282 (line 635) 47283* __fractdfda: Fixed-point fractional library routines. 47284 (line 1032) 47285* __fractdfdq: Fixed-point fractional library routines. 47286 (line 1029) 47287* __fractdfha: Fixed-point fractional library routines. 47288 (line 1030) 47289* __fractdfhq: Fixed-point fractional library routines. 47290 (line 1027) 47291* __fractdfqq: Fixed-point fractional library routines. 47292 (line 1026) 47293* __fractdfsa: Fixed-point fractional library routines. 47294 (line 1031) 47295* __fractdfsq: Fixed-point fractional library routines. 47296 (line 1028) 47297* __fractdfta: Fixed-point fractional library routines. 47298 (line 1033) 47299* __fractdfuda: Fixed-point fractional library routines. 47300 (line 1040) 47301* __fractdfudq: Fixed-point fractional library routines. 47302 (line 1037) 47303* __fractdfuha: Fixed-point fractional library routines. 47304 (line 1038) 47305* __fractdfuhq: Fixed-point fractional library routines. 47306 (line 1035) 47307* __fractdfuqq: Fixed-point fractional library routines. 47308 (line 1034) 47309* __fractdfusa: Fixed-point fractional library routines. 47310 (line 1039) 47311* __fractdfusq: Fixed-point fractional library routines. 47312 (line 1036) 47313* __fractdfuta: Fixed-point fractional library routines. 47314 (line 1041) 47315* __fractdida: Fixed-point fractional library routines. 47316 (line 982) 47317* __fractdidq: Fixed-point fractional library routines. 47318 (line 979) 47319* __fractdiha: Fixed-point fractional library routines. 47320 (line 980) 47321* __fractdihq: Fixed-point fractional library routines. 47322 (line 977) 47323* __fractdiqq: Fixed-point fractional library routines. 47324 (line 976) 47325* __fractdisa: Fixed-point fractional library routines. 47326 (line 981) 47327* __fractdisq: Fixed-point fractional library routines. 47328 (line 978) 47329* __fractdita: Fixed-point fractional library routines. 47330 (line 983) 47331* __fractdiuda: Fixed-point fractional library routines. 47332 (line 990) 47333* __fractdiudq: Fixed-point fractional library routines. 47334 (line 987) 47335* __fractdiuha: Fixed-point fractional library routines. 47336 (line 988) 47337* __fractdiuhq: Fixed-point fractional library routines. 47338 (line 985) 47339* __fractdiuqq: Fixed-point fractional library routines. 47340 (line 984) 47341* __fractdiusa: Fixed-point fractional library routines. 47342 (line 989) 47343* __fractdiusq: Fixed-point fractional library routines. 47344 (line 986) 47345* __fractdiuta: Fixed-point fractional library routines. 47346 (line 991) 47347* __fractdqda: Fixed-point fractional library routines. 47348 (line 551) 47349* __fractdqdf: Fixed-point fractional library routines. 47350 (line 573) 47351* __fractdqdi: Fixed-point fractional library routines. 47352 (line 570) 47353* __fractdqha: Fixed-point fractional library routines. 47354 (line 549) 47355* __fractdqhi: Fixed-point fractional library routines. 47356 (line 568) 47357* __fractdqhq2: Fixed-point fractional library routines. 47358 (line 547) 47359* __fractdqqi: Fixed-point fractional library routines. 47360 (line 567) 47361* __fractdqqq2: Fixed-point fractional library routines. 47362 (line 546) 47363* __fractdqsa: Fixed-point fractional library routines. 47364 (line 550) 47365* __fractdqsf: Fixed-point fractional library routines. 47366 (line 572) 47367* __fractdqsi: Fixed-point fractional library routines. 47368 (line 569) 47369* __fractdqsq2: Fixed-point fractional library routines. 47370 (line 548) 47371* __fractdqta: Fixed-point fractional library routines. 47372 (line 552) 47373* __fractdqti: Fixed-point fractional library routines. 47374 (line 571) 47375* __fractdquda: Fixed-point fractional library routines. 47376 (line 563) 47377* __fractdqudq: Fixed-point fractional library routines. 47378 (line 558) 47379* __fractdquha: Fixed-point fractional library routines. 47380 (line 560) 47381* __fractdquhq: Fixed-point fractional library routines. 47382 (line 555) 47383* __fractdquqq: Fixed-point fractional library routines. 47384 (line 553) 47385* __fractdqusa: Fixed-point fractional library routines. 47386 (line 562) 47387* __fractdqusq: Fixed-point fractional library routines. 47388 (line 556) 47389* __fractdquta: Fixed-point fractional library routines. 47390 (line 565) 47391* __fracthada2: Fixed-point fractional library routines. 47392 (line 579) 47393* __fracthadf: Fixed-point fractional library routines. 47394 (line 597) 47395* __fracthadi: Fixed-point fractional library routines. 47396 (line 594) 47397* __fracthadq: Fixed-point fractional library routines. 47398 (line 577) 47399* __fracthahi: Fixed-point fractional library routines. 47400 (line 592) 47401* __fracthahq: Fixed-point fractional library routines. 47402 (line 575) 47403* __fracthaqi: Fixed-point fractional library routines. 47404 (line 591) 47405* __fracthaqq: Fixed-point fractional library routines. 47406 (line 574) 47407* __fracthasa2: Fixed-point fractional library routines. 47408 (line 578) 47409* __fracthasf: Fixed-point fractional library routines. 47410 (line 596) 47411* __fracthasi: Fixed-point fractional library routines. 47412 (line 593) 47413* __fracthasq: Fixed-point fractional library routines. 47414 (line 576) 47415* __fracthata2: Fixed-point fractional library routines. 47416 (line 580) 47417* __fracthati: Fixed-point fractional library routines. 47418 (line 595) 47419* __fracthauda: Fixed-point fractional library routines. 47420 (line 588) 47421* __fracthaudq: Fixed-point fractional library routines. 47422 (line 584) 47423* __fracthauha: Fixed-point fractional library routines. 47424 (line 586) 47425* __fracthauhq: Fixed-point fractional library routines. 47426 (line 582) 47427* __fracthauqq: Fixed-point fractional library routines. 47428 (line 581) 47429* __fracthausa: Fixed-point fractional library routines. 47430 (line 587) 47431* __fracthausq: Fixed-point fractional library routines. 47432 (line 583) 47433* __fracthauta: Fixed-point fractional library routines. 47434 (line 589) 47435* __fracthida: Fixed-point fractional library routines. 47436 (line 950) 47437* __fracthidq: Fixed-point fractional library routines. 47438 (line 947) 47439* __fracthiha: Fixed-point fractional library routines. 47440 (line 948) 47441* __fracthihq: Fixed-point fractional library routines. 47442 (line 945) 47443* __fracthiqq: Fixed-point fractional library routines. 47444 (line 944) 47445* __fracthisa: Fixed-point fractional library routines. 47446 (line 949) 47447* __fracthisq: Fixed-point fractional library routines. 47448 (line 946) 47449* __fracthita: Fixed-point fractional library routines. 47450 (line 951) 47451* __fracthiuda: Fixed-point fractional library routines. 47452 (line 958) 47453* __fracthiudq: Fixed-point fractional library routines. 47454 (line 955) 47455* __fracthiuha: Fixed-point fractional library routines. 47456 (line 956) 47457* __fracthiuhq: Fixed-point fractional library routines. 47458 (line 953) 47459* __fracthiuqq: Fixed-point fractional library routines. 47460 (line 952) 47461* __fracthiusa: Fixed-point fractional library routines. 47462 (line 957) 47463* __fracthiusq: Fixed-point fractional library routines. 47464 (line 954) 47465* __fracthiuta: Fixed-point fractional library routines. 47466 (line 959) 47467* __fracthqda: Fixed-point fractional library routines. 47468 (line 505) 47469* __fracthqdf: Fixed-point fractional library routines. 47470 (line 521) 47471* __fracthqdi: Fixed-point fractional library routines. 47472 (line 518) 47473* __fracthqdq2: Fixed-point fractional library routines. 47474 (line 502) 47475* __fracthqha: Fixed-point fractional library routines. 47476 (line 503) 47477* __fracthqhi: Fixed-point fractional library routines. 47478 (line 516) 47479* __fracthqqi: Fixed-point fractional library routines. 47480 (line 515) 47481* __fracthqqq2: Fixed-point fractional library routines. 47482 (line 500) 47483* __fracthqsa: Fixed-point fractional library routines. 47484 (line 504) 47485* __fracthqsf: Fixed-point fractional library routines. 47486 (line 520) 47487* __fracthqsi: Fixed-point fractional library routines. 47488 (line 517) 47489* __fracthqsq2: Fixed-point fractional library routines. 47490 (line 501) 47491* __fracthqta: Fixed-point fractional library routines. 47492 (line 506) 47493* __fracthqti: Fixed-point fractional library routines. 47494 (line 519) 47495* __fracthquda: Fixed-point fractional library routines. 47496 (line 513) 47497* __fracthqudq: Fixed-point fractional library routines. 47498 (line 510) 47499* __fracthquha: Fixed-point fractional library routines. 47500 (line 511) 47501* __fracthquhq: Fixed-point fractional library routines. 47502 (line 508) 47503* __fracthquqq: Fixed-point fractional library routines. 47504 (line 507) 47505* __fracthqusa: Fixed-point fractional library routines. 47506 (line 512) 47507* __fracthqusq: Fixed-point fractional library routines. 47508 (line 509) 47509* __fracthquta: Fixed-point fractional library routines. 47510 (line 514) 47511* __fractqida: Fixed-point fractional library routines. 47512 (line 932) 47513* __fractqidq: Fixed-point fractional library routines. 47514 (line 929) 47515* __fractqiha: Fixed-point fractional library routines. 47516 (line 930) 47517* __fractqihq: Fixed-point fractional library routines. 47518 (line 927) 47519* __fractqiqq: Fixed-point fractional library routines. 47520 (line 926) 47521* __fractqisa: Fixed-point fractional library routines. 47522 (line 931) 47523* __fractqisq: Fixed-point fractional library routines. 47524 (line 928) 47525* __fractqita: Fixed-point fractional library routines. 47526 (line 933) 47527* __fractqiuda: Fixed-point fractional library routines. 47528 (line 941) 47529* __fractqiudq: Fixed-point fractional library routines. 47530 (line 937) 47531* __fractqiuha: Fixed-point fractional library routines. 47532 (line 939) 47533* __fractqiuhq: Fixed-point fractional library routines. 47534 (line 935) 47535* __fractqiuqq: Fixed-point fractional library routines. 47536 (line 934) 47537* __fractqiusa: Fixed-point fractional library routines. 47538 (line 940) 47539* __fractqiusq: Fixed-point fractional library routines. 47540 (line 936) 47541* __fractqiuta: Fixed-point fractional library routines. 47542 (line 942) 47543* __fractqqda: Fixed-point fractional library routines. 47544 (line 481) 47545* __fractqqdf: Fixed-point fractional library routines. 47546 (line 499) 47547* __fractqqdi: Fixed-point fractional library routines. 47548 (line 496) 47549* __fractqqdq2: Fixed-point fractional library routines. 47550 (line 478) 47551* __fractqqha: Fixed-point fractional library routines. 47552 (line 479) 47553* __fractqqhi: Fixed-point fractional library routines. 47554 (line 494) 47555* __fractqqhq2: Fixed-point fractional library routines. 47556 (line 476) 47557* __fractqqqi: Fixed-point fractional library routines. 47558 (line 493) 47559* __fractqqsa: Fixed-point fractional library routines. 47560 (line 480) 47561* __fractqqsf: Fixed-point fractional library routines. 47562 (line 498) 47563* __fractqqsi: Fixed-point fractional library routines. 47564 (line 495) 47565* __fractqqsq2: Fixed-point fractional library routines. 47566 (line 477) 47567* __fractqqta: Fixed-point fractional library routines. 47568 (line 482) 47569* __fractqqti: Fixed-point fractional library routines. 47570 (line 497) 47571* __fractqquda: Fixed-point fractional library routines. 47572 (line 490) 47573* __fractqqudq: Fixed-point fractional library routines. 47574 (line 486) 47575* __fractqquha: Fixed-point fractional library routines. 47576 (line 488) 47577* __fractqquhq: Fixed-point fractional library routines. 47578 (line 484) 47579* __fractqquqq: Fixed-point fractional library routines. 47580 (line 483) 47581* __fractqqusa: Fixed-point fractional library routines. 47582 (line 489) 47583* __fractqqusq: Fixed-point fractional library routines. 47584 (line 485) 47585* __fractqquta: Fixed-point fractional library routines. 47586 (line 491) 47587* __fractsada2: Fixed-point fractional library routines. 47588 (line 603) 47589* __fractsadf: Fixed-point fractional library routines. 47590 (line 619) 47591* __fractsadi: Fixed-point fractional library routines. 47592 (line 616) 47593* __fractsadq: Fixed-point fractional library routines. 47594 (line 601) 47595* __fractsaha2: Fixed-point fractional library routines. 47596 (line 602) 47597* __fractsahi: Fixed-point fractional library routines. 47598 (line 614) 47599* __fractsahq: Fixed-point fractional library routines. 47600 (line 599) 47601* __fractsaqi: Fixed-point fractional library routines. 47602 (line 613) 47603* __fractsaqq: Fixed-point fractional library routines. 47604 (line 598) 47605* __fractsasf: Fixed-point fractional library routines. 47606 (line 618) 47607* __fractsasi: Fixed-point fractional library routines. 47608 (line 615) 47609* __fractsasq: Fixed-point fractional library routines. 47610 (line 600) 47611* __fractsata2: Fixed-point fractional library routines. 47612 (line 604) 47613* __fractsati: Fixed-point fractional library routines. 47614 (line 617) 47615* __fractsauda: Fixed-point fractional library routines. 47616 (line 611) 47617* __fractsaudq: Fixed-point fractional library routines. 47618 (line 608) 47619* __fractsauha: Fixed-point fractional library routines. 47620 (line 609) 47621* __fractsauhq: Fixed-point fractional library routines. 47622 (line 606) 47623* __fractsauqq: Fixed-point fractional library routines. 47624 (line 605) 47625* __fractsausa: Fixed-point fractional library routines. 47626 (line 610) 47627* __fractsausq: Fixed-point fractional library routines. 47628 (line 607) 47629* __fractsauta: Fixed-point fractional library routines. 47630 (line 612) 47631* __fractsfda: Fixed-point fractional library routines. 47632 (line 1016) 47633* __fractsfdq: Fixed-point fractional library routines. 47634 (line 1013) 47635* __fractsfha: Fixed-point fractional library routines. 47636 (line 1014) 47637* __fractsfhq: Fixed-point fractional library routines. 47638 (line 1011) 47639* __fractsfqq: Fixed-point fractional library routines. 47640 (line 1010) 47641* __fractsfsa: Fixed-point fractional library routines. 47642 (line 1015) 47643* __fractsfsq: Fixed-point fractional library routines. 47644 (line 1012) 47645* __fractsfta: Fixed-point fractional library routines. 47646 (line 1017) 47647* __fractsfuda: Fixed-point fractional library routines. 47648 (line 1024) 47649* __fractsfudq: Fixed-point fractional library routines. 47650 (line 1021) 47651* __fractsfuha: Fixed-point fractional library routines. 47652 (line 1022) 47653* __fractsfuhq: Fixed-point fractional library routines. 47654 (line 1019) 47655* __fractsfuqq: Fixed-point fractional library routines. 47656 (line 1018) 47657* __fractsfusa: Fixed-point fractional library routines. 47658 (line 1023) 47659* __fractsfusq: Fixed-point fractional library routines. 47660 (line 1020) 47661* __fractsfuta: Fixed-point fractional library routines. 47662 (line 1025) 47663* __fractsida: Fixed-point fractional library routines. 47664 (line 966) 47665* __fractsidq: Fixed-point fractional library routines. 47666 (line 963) 47667* __fractsiha: Fixed-point fractional library routines. 47668 (line 964) 47669* __fractsihq: Fixed-point fractional library routines. 47670 (line 961) 47671* __fractsiqq: Fixed-point fractional library routines. 47672 (line 960) 47673* __fractsisa: Fixed-point fractional library routines. 47674 (line 965) 47675* __fractsisq: Fixed-point fractional library routines. 47676 (line 962) 47677* __fractsita: Fixed-point fractional library routines. 47678 (line 967) 47679* __fractsiuda: Fixed-point fractional library routines. 47680 (line 974) 47681* __fractsiudq: Fixed-point fractional library routines. 47682 (line 971) 47683* __fractsiuha: Fixed-point fractional library routines. 47684 (line 972) 47685* __fractsiuhq: Fixed-point fractional library routines. 47686 (line 969) 47687* __fractsiuqq: Fixed-point fractional library routines. 47688 (line 968) 47689* __fractsiusa: Fixed-point fractional library routines. 47690 (line 973) 47691* __fractsiusq: Fixed-point fractional library routines. 47692 (line 970) 47693* __fractsiuta: Fixed-point fractional library routines. 47694 (line 975) 47695* __fractsqda: Fixed-point fractional library routines. 47696 (line 527) 47697* __fractsqdf: Fixed-point fractional library routines. 47698 (line 545) 47699* __fractsqdi: Fixed-point fractional library routines. 47700 (line 542) 47701* __fractsqdq2: Fixed-point fractional library routines. 47702 (line 524) 47703* __fractsqha: Fixed-point fractional library routines. 47704 (line 525) 47705* __fractsqhi: Fixed-point fractional library routines. 47706 (line 540) 47707* __fractsqhq2: Fixed-point fractional library routines. 47708 (line 523) 47709* __fractsqqi: Fixed-point fractional library routines. 47710 (line 539) 47711* __fractsqqq2: Fixed-point fractional library routines. 47712 (line 522) 47713* __fractsqsa: Fixed-point fractional library routines. 47714 (line 526) 47715* __fractsqsf: Fixed-point fractional library routines. 47716 (line 544) 47717* __fractsqsi: Fixed-point fractional library routines. 47718 (line 541) 47719* __fractsqta: Fixed-point fractional library routines. 47720 (line 528) 47721* __fractsqti: Fixed-point fractional library routines. 47722 (line 543) 47723* __fractsquda: Fixed-point fractional library routines. 47724 (line 536) 47725* __fractsqudq: Fixed-point fractional library routines. 47726 (line 532) 47727* __fractsquha: Fixed-point fractional library routines. 47728 (line 534) 47729* __fractsquhq: Fixed-point fractional library routines. 47730 (line 530) 47731* __fractsquqq: Fixed-point fractional library routines. 47732 (line 529) 47733* __fractsqusa: Fixed-point fractional library routines. 47734 (line 535) 47735* __fractsqusq: Fixed-point fractional library routines. 47736 (line 531) 47737* __fractsquta: Fixed-point fractional library routines. 47738 (line 537) 47739* __fracttada2: Fixed-point fractional library routines. 47740 (line 650) 47741* __fracttadf: Fixed-point fractional library routines. 47742 (line 671) 47743* __fracttadi: Fixed-point fractional library routines. 47744 (line 668) 47745* __fracttadq: Fixed-point fractional library routines. 47746 (line 647) 47747* __fracttaha2: Fixed-point fractional library routines. 47748 (line 648) 47749* __fracttahi: Fixed-point fractional library routines. 47750 (line 666) 47751* __fracttahq: Fixed-point fractional library routines. 47752 (line 645) 47753* __fracttaqi: Fixed-point fractional library routines. 47754 (line 665) 47755* __fracttaqq: Fixed-point fractional library routines. 47756 (line 644) 47757* __fracttasa2: Fixed-point fractional library routines. 47758 (line 649) 47759* __fracttasf: Fixed-point fractional library routines. 47760 (line 670) 47761* __fracttasi: Fixed-point fractional library routines. 47762 (line 667) 47763* __fracttasq: Fixed-point fractional library routines. 47764 (line 646) 47765* __fracttati: Fixed-point fractional library routines. 47766 (line 669) 47767* __fracttauda: Fixed-point fractional library routines. 47768 (line 661) 47769* __fracttaudq: Fixed-point fractional library routines. 47770 (line 656) 47771* __fracttauha: Fixed-point fractional library routines. 47772 (line 658) 47773* __fracttauhq: Fixed-point fractional library routines. 47774 (line 653) 47775* __fracttauqq: Fixed-point fractional library routines. 47776 (line 651) 47777* __fracttausa: Fixed-point fractional library routines. 47778 (line 660) 47779* __fracttausq: Fixed-point fractional library routines. 47780 (line 654) 47781* __fracttauta: Fixed-point fractional library routines. 47782 (line 663) 47783* __fracttida: Fixed-point fractional library routines. 47784 (line 998) 47785* __fracttidq: Fixed-point fractional library routines. 47786 (line 995) 47787* __fracttiha: Fixed-point fractional library routines. 47788 (line 996) 47789* __fracttihq: Fixed-point fractional library routines. 47790 (line 993) 47791* __fracttiqq: Fixed-point fractional library routines. 47792 (line 992) 47793* __fracttisa: Fixed-point fractional library routines. 47794 (line 997) 47795* __fracttisq: Fixed-point fractional library routines. 47796 (line 994) 47797* __fracttita: Fixed-point fractional library routines. 47798 (line 999) 47799* __fracttiuda: Fixed-point fractional library routines. 47800 (line 1007) 47801* __fracttiudq: Fixed-point fractional library routines. 47802 (line 1003) 47803* __fracttiuha: Fixed-point fractional library routines. 47804 (line 1005) 47805* __fracttiuhq: Fixed-point fractional library routines. 47806 (line 1001) 47807* __fracttiuqq: Fixed-point fractional library routines. 47808 (line 1000) 47809* __fracttiusa: Fixed-point fractional library routines. 47810 (line 1006) 47811* __fracttiusq: Fixed-point fractional library routines. 47812 (line 1002) 47813* __fracttiuta: Fixed-point fractional library routines. 47814 (line 1008) 47815* __fractudada: Fixed-point fractional library routines. 47816 (line 865) 47817* __fractudadf: Fixed-point fractional library routines. 47818 (line 888) 47819* __fractudadi: Fixed-point fractional library routines. 47820 (line 885) 47821* __fractudadq: Fixed-point fractional library routines. 47822 (line 861) 47823* __fractudaha: Fixed-point fractional library routines. 47824 (line 863) 47825* __fractudahi: Fixed-point fractional library routines. 47826 (line 883) 47827* __fractudahq: Fixed-point fractional library routines. 47828 (line 859) 47829* __fractudaqi: Fixed-point fractional library routines. 47830 (line 882) 47831* __fractudaqq: Fixed-point fractional library routines. 47832 (line 858) 47833* __fractudasa: Fixed-point fractional library routines. 47834 (line 864) 47835* __fractudasf: Fixed-point fractional library routines. 47836 (line 887) 47837* __fractudasi: Fixed-point fractional library routines. 47838 (line 884) 47839* __fractudasq: Fixed-point fractional library routines. 47840 (line 860) 47841* __fractudata: Fixed-point fractional library routines. 47842 (line 866) 47843* __fractudati: Fixed-point fractional library routines. 47844 (line 886) 47845* __fractudaudq: Fixed-point fractional library routines. 47846 (line 874) 47847* __fractudauha2: Fixed-point fractional library routines. 47848 (line 876) 47849* __fractudauhq: Fixed-point fractional library routines. 47850 (line 870) 47851* __fractudauqq: Fixed-point fractional library routines. 47852 (line 868) 47853* __fractudausa2: Fixed-point fractional library routines. 47854 (line 878) 47855* __fractudausq: Fixed-point fractional library routines. 47856 (line 872) 47857* __fractudauta2: Fixed-point fractional library routines. 47858 (line 880) 47859* __fractudqda: Fixed-point fractional library routines. 47860 (line 772) 47861* __fractudqdf: Fixed-point fractional library routines. 47862 (line 798) 47863* __fractudqdi: Fixed-point fractional library routines. 47864 (line 794) 47865* __fractudqdq: Fixed-point fractional library routines. 47866 (line 767) 47867* __fractudqha: Fixed-point fractional library routines. 47868 (line 769) 47869* __fractudqhi: Fixed-point fractional library routines. 47870 (line 792) 47871* __fractudqhq: Fixed-point fractional library routines. 47872 (line 764) 47873* __fractudqqi: Fixed-point fractional library routines. 47874 (line 790) 47875* __fractudqqq: Fixed-point fractional library routines. 47876 (line 762) 47877* __fractudqsa: Fixed-point fractional library routines. 47878 (line 771) 47879* __fractudqsf: Fixed-point fractional library routines. 47880 (line 797) 47881* __fractudqsi: Fixed-point fractional library routines. 47882 (line 793) 47883* __fractudqsq: Fixed-point fractional library routines. 47884 (line 765) 47885* __fractudqta: Fixed-point fractional library routines. 47886 (line 774) 47887* __fractudqti: Fixed-point fractional library routines. 47888 (line 795) 47889* __fractudquda: Fixed-point fractional library routines. 47890 (line 786) 47891* __fractudquha: Fixed-point fractional library routines. 47892 (line 782) 47893* __fractudquhq2: Fixed-point fractional library routines. 47894 (line 778) 47895* __fractudquqq2: Fixed-point fractional library routines. 47896 (line 776) 47897* __fractudqusa: Fixed-point fractional library routines. 47898 (line 784) 47899* __fractudqusq2: Fixed-point fractional library routines. 47900 (line 780) 47901* __fractudquta: Fixed-point fractional library routines. 47902 (line 788) 47903* __fractuhada: Fixed-point fractional library routines. 47904 (line 806) 47905* __fractuhadf: Fixed-point fractional library routines. 47906 (line 829) 47907* __fractuhadi: Fixed-point fractional library routines. 47908 (line 826) 47909* __fractuhadq: Fixed-point fractional library routines. 47910 (line 802) 47911* __fractuhaha: Fixed-point fractional library routines. 47912 (line 804) 47913* __fractuhahi: Fixed-point fractional library routines. 47914 (line 824) 47915* __fractuhahq: Fixed-point fractional library routines. 47916 (line 800) 47917* __fractuhaqi: Fixed-point fractional library routines. 47918 (line 823) 47919* __fractuhaqq: Fixed-point fractional library routines. 47920 (line 799) 47921* __fractuhasa: Fixed-point fractional library routines. 47922 (line 805) 47923* __fractuhasf: Fixed-point fractional library routines. 47924 (line 828) 47925* __fractuhasi: Fixed-point fractional library routines. 47926 (line 825) 47927* __fractuhasq: Fixed-point fractional library routines. 47928 (line 801) 47929* __fractuhata: Fixed-point fractional library routines. 47930 (line 807) 47931* __fractuhati: Fixed-point fractional library routines. 47932 (line 827) 47933* __fractuhauda2: Fixed-point fractional library routines. 47934 (line 819) 47935* __fractuhaudq: Fixed-point fractional library routines. 47936 (line 815) 47937* __fractuhauhq: Fixed-point fractional library routines. 47938 (line 811) 47939* __fractuhauqq: Fixed-point fractional library routines. 47940 (line 809) 47941* __fractuhausa2: Fixed-point fractional library routines. 47942 (line 817) 47943* __fractuhausq: Fixed-point fractional library routines. 47944 (line 813) 47945* __fractuhauta2: Fixed-point fractional library routines. 47946 (line 821) 47947* __fractuhqda: Fixed-point fractional library routines. 47948 (line 709) 47949* __fractuhqdf: Fixed-point fractional library routines. 47950 (line 730) 47951* __fractuhqdi: Fixed-point fractional library routines. 47952 (line 727) 47953* __fractuhqdq: Fixed-point fractional library routines. 47954 (line 706) 47955* __fractuhqha: Fixed-point fractional library routines. 47956 (line 707) 47957* __fractuhqhi: Fixed-point fractional library routines. 47958 (line 725) 47959* __fractuhqhq: Fixed-point fractional library routines. 47960 (line 704) 47961* __fractuhqqi: Fixed-point fractional library routines. 47962 (line 724) 47963* __fractuhqqq: Fixed-point fractional library routines. 47964 (line 703) 47965* __fractuhqsa: Fixed-point fractional library routines. 47966 (line 708) 47967* __fractuhqsf: Fixed-point fractional library routines. 47968 (line 729) 47969* __fractuhqsi: Fixed-point fractional library routines. 47970 (line 726) 47971* __fractuhqsq: Fixed-point fractional library routines. 47972 (line 705) 47973* __fractuhqta: Fixed-point fractional library routines. 47974 (line 710) 47975* __fractuhqti: Fixed-point fractional library routines. 47976 (line 728) 47977* __fractuhquda: Fixed-point fractional library routines. 47978 (line 720) 47979* __fractuhqudq2: Fixed-point fractional library routines. 47980 (line 715) 47981* __fractuhquha: Fixed-point fractional library routines. 47982 (line 717) 47983* __fractuhquqq2: Fixed-point fractional library routines. 47984 (line 711) 47985* __fractuhqusa: Fixed-point fractional library routines. 47986 (line 719) 47987* __fractuhqusq2: Fixed-point fractional library routines. 47988 (line 713) 47989* __fractuhquta: Fixed-point fractional library routines. 47990 (line 722) 47991* __fractunsdadi: Fixed-point fractional library routines. 47992 (line 1562) 47993* __fractunsdahi: Fixed-point fractional library routines. 47994 (line 1560) 47995* __fractunsdaqi: Fixed-point fractional library routines. 47996 (line 1559) 47997* __fractunsdasi: Fixed-point fractional library routines. 47998 (line 1561) 47999* __fractunsdati: Fixed-point fractional library routines. 48000 (line 1563) 48001* __fractunsdida: Fixed-point fractional library routines. 48002 (line 1714) 48003* __fractunsdidq: Fixed-point fractional library routines. 48004 (line 1711) 48005* __fractunsdiha: Fixed-point fractional library routines. 48006 (line 1712) 48007* __fractunsdihq: Fixed-point fractional library routines. 48008 (line 1709) 48009* __fractunsdiqq: Fixed-point fractional library routines. 48010 (line 1708) 48011* __fractunsdisa: Fixed-point fractional library routines. 48012 (line 1713) 48013* __fractunsdisq: Fixed-point fractional library routines. 48014 (line 1710) 48015* __fractunsdita: Fixed-point fractional library routines. 48016 (line 1715) 48017* __fractunsdiuda: Fixed-point fractional library routines. 48018 (line 1726) 48019* __fractunsdiudq: Fixed-point fractional library routines. 48020 (line 1721) 48021* __fractunsdiuha: Fixed-point fractional library routines. 48022 (line 1723) 48023* __fractunsdiuhq: Fixed-point fractional library routines. 48024 (line 1718) 48025* __fractunsdiuqq: Fixed-point fractional library routines. 48026 (line 1716) 48027* __fractunsdiusa: Fixed-point fractional library routines. 48028 (line 1725) 48029* __fractunsdiusq: Fixed-point fractional library routines. 48030 (line 1719) 48031* __fractunsdiuta: Fixed-point fractional library routines. 48032 (line 1728) 48033* __fractunsdqdi: Fixed-point fractional library routines. 48034 (line 1546) 48035* __fractunsdqhi: Fixed-point fractional library routines. 48036 (line 1544) 48037* __fractunsdqqi: Fixed-point fractional library routines. 48038 (line 1543) 48039* __fractunsdqsi: Fixed-point fractional library routines. 48040 (line 1545) 48041* __fractunsdqti: Fixed-point fractional library routines. 48042 (line 1547) 48043* __fractunshadi: Fixed-point fractional library routines. 48044 (line 1552) 48045* __fractunshahi: Fixed-point fractional library routines. 48046 (line 1550) 48047* __fractunshaqi: Fixed-point fractional library routines. 48048 (line 1549) 48049* __fractunshasi: Fixed-point fractional library routines. 48050 (line 1551) 48051* __fractunshati: Fixed-point fractional library routines. 48052 (line 1553) 48053* __fractunshida: Fixed-point fractional library routines. 48054 (line 1670) 48055* __fractunshidq: Fixed-point fractional library routines. 48056 (line 1667) 48057* __fractunshiha: Fixed-point fractional library routines. 48058 (line 1668) 48059* __fractunshihq: Fixed-point fractional library routines. 48060 (line 1665) 48061* __fractunshiqq: Fixed-point fractional library routines. 48062 (line 1664) 48063* __fractunshisa: Fixed-point fractional library routines. 48064 (line 1669) 48065* __fractunshisq: Fixed-point fractional library routines. 48066 (line 1666) 48067* __fractunshita: Fixed-point fractional library routines. 48068 (line 1671) 48069* __fractunshiuda: Fixed-point fractional library routines. 48070 (line 1682) 48071* __fractunshiudq: Fixed-point fractional library routines. 48072 (line 1677) 48073* __fractunshiuha: Fixed-point fractional library routines. 48074 (line 1679) 48075* __fractunshiuhq: Fixed-point fractional library routines. 48076 (line 1674) 48077* __fractunshiuqq: Fixed-point fractional library routines. 48078 (line 1672) 48079* __fractunshiusa: Fixed-point fractional library routines. 48080 (line 1681) 48081* __fractunshiusq: Fixed-point fractional library routines. 48082 (line 1675) 48083* __fractunshiuta: Fixed-point fractional library routines. 48084 (line 1684) 48085* __fractunshqdi: Fixed-point fractional library routines. 48086 (line 1536) 48087* __fractunshqhi: Fixed-point fractional library routines. 48088 (line 1534) 48089* __fractunshqqi: Fixed-point fractional library routines. 48090 (line 1533) 48091* __fractunshqsi: Fixed-point fractional library routines. 48092 (line 1535) 48093* __fractunshqti: Fixed-point fractional library routines. 48094 (line 1537) 48095* __fractunsqida: Fixed-point fractional library routines. 48096 (line 1648) 48097* __fractunsqidq: Fixed-point fractional library routines. 48098 (line 1645) 48099* __fractunsqiha: Fixed-point fractional library routines. 48100 (line 1646) 48101* __fractunsqihq: Fixed-point fractional library routines. 48102 (line 1643) 48103* __fractunsqiqq: Fixed-point fractional library routines. 48104 (line 1642) 48105* __fractunsqisa: Fixed-point fractional library routines. 48106 (line 1647) 48107* __fractunsqisq: Fixed-point fractional library routines. 48108 (line 1644) 48109* __fractunsqita: Fixed-point fractional library routines. 48110 (line 1649) 48111* __fractunsqiuda: Fixed-point fractional library routines. 48112 (line 1660) 48113* __fractunsqiudq: Fixed-point fractional library routines. 48114 (line 1655) 48115* __fractunsqiuha: Fixed-point fractional library routines. 48116 (line 1657) 48117* __fractunsqiuhq: Fixed-point fractional library routines. 48118 (line 1652) 48119* __fractunsqiuqq: Fixed-point fractional library routines. 48120 (line 1650) 48121* __fractunsqiusa: Fixed-point fractional library routines. 48122 (line 1659) 48123* __fractunsqiusq: Fixed-point fractional library routines. 48124 (line 1653) 48125* __fractunsqiuta: Fixed-point fractional library routines. 48126 (line 1662) 48127* __fractunsqqdi: Fixed-point fractional library routines. 48128 (line 1531) 48129* __fractunsqqhi: Fixed-point fractional library routines. 48130 (line 1529) 48131* __fractunsqqqi: Fixed-point fractional library routines. 48132 (line 1528) 48133* __fractunsqqsi: Fixed-point fractional library routines. 48134 (line 1530) 48135* __fractunsqqti: Fixed-point fractional library routines. 48136 (line 1532) 48137* __fractunssadi: Fixed-point fractional library routines. 48138 (line 1557) 48139* __fractunssahi: Fixed-point fractional library routines. 48140 (line 1555) 48141* __fractunssaqi: Fixed-point fractional library routines. 48142 (line 1554) 48143* __fractunssasi: Fixed-point fractional library routines. 48144 (line 1556) 48145* __fractunssati: Fixed-point fractional library routines. 48146 (line 1558) 48147* __fractunssida: Fixed-point fractional library routines. 48148 (line 1692) 48149* __fractunssidq: Fixed-point fractional library routines. 48150 (line 1689) 48151* __fractunssiha: Fixed-point fractional library routines. 48152 (line 1690) 48153* __fractunssihq: Fixed-point fractional library routines. 48154 (line 1687) 48155* __fractunssiqq: Fixed-point fractional library routines. 48156 (line 1686) 48157* __fractunssisa: Fixed-point fractional library routines. 48158 (line 1691) 48159* __fractunssisq: Fixed-point fractional library routines. 48160 (line 1688) 48161* __fractunssita: Fixed-point fractional library routines. 48162 (line 1693) 48163* __fractunssiuda: Fixed-point fractional library routines. 48164 (line 1704) 48165* __fractunssiudq: Fixed-point fractional library routines. 48166 (line 1699) 48167* __fractunssiuha: Fixed-point fractional library routines. 48168 (line 1701) 48169* __fractunssiuhq: Fixed-point fractional library routines. 48170 (line 1696) 48171* __fractunssiuqq: Fixed-point fractional library routines. 48172 (line 1694) 48173* __fractunssiusa: Fixed-point fractional library routines. 48174 (line 1703) 48175* __fractunssiusq: Fixed-point fractional library routines. 48176 (line 1697) 48177* __fractunssiuta: Fixed-point fractional library routines. 48178 (line 1706) 48179* __fractunssqdi: Fixed-point fractional library routines. 48180 (line 1541) 48181* __fractunssqhi: Fixed-point fractional library routines. 48182 (line 1539) 48183* __fractunssqqi: Fixed-point fractional library routines. 48184 (line 1538) 48185* __fractunssqsi: Fixed-point fractional library routines. 48186 (line 1540) 48187* __fractunssqti: Fixed-point fractional library routines. 48188 (line 1542) 48189* __fractunstadi: Fixed-point fractional library routines. 48190 (line 1567) 48191* __fractunstahi: Fixed-point fractional library routines. 48192 (line 1565) 48193* __fractunstaqi: Fixed-point fractional library routines. 48194 (line 1564) 48195* __fractunstasi: Fixed-point fractional library routines. 48196 (line 1566) 48197* __fractunstati: Fixed-point fractional library routines. 48198 (line 1568) 48199* __fractunstida: Fixed-point fractional library routines. 48200 (line 1737) 48201* __fractunstidq: Fixed-point fractional library routines. 48202 (line 1733) 48203* __fractunstiha: Fixed-point fractional library routines. 48204 (line 1735) 48205* __fractunstihq: Fixed-point fractional library routines. 48206 (line 1731) 48207* __fractunstiqq: Fixed-point fractional library routines. 48208 (line 1730) 48209* __fractunstisa: Fixed-point fractional library routines. 48210 (line 1736) 48211* __fractunstisq: Fixed-point fractional library routines. 48212 (line 1732) 48213* __fractunstita: Fixed-point fractional library routines. 48214 (line 1738) 48215* __fractunstiuda: Fixed-point fractional library routines. 48216 (line 1752) 48217* __fractunstiudq: Fixed-point fractional library routines. 48218 (line 1746) 48219* __fractunstiuha: Fixed-point fractional library routines. 48220 (line 1748) 48221* __fractunstiuhq: Fixed-point fractional library routines. 48222 (line 1742) 48223* __fractunstiuqq: Fixed-point fractional library routines. 48224 (line 1740) 48225* __fractunstiusa: Fixed-point fractional library routines. 48226 (line 1750) 48227* __fractunstiusq: Fixed-point fractional library routines. 48228 (line 1744) 48229* __fractunstiuta: Fixed-point fractional library routines. 48230 (line 1754) 48231* __fractunsudadi: Fixed-point fractional library routines. 48232 (line 1628) 48233* __fractunsudahi: Fixed-point fractional library routines. 48234 (line 1624) 48235* __fractunsudaqi: Fixed-point fractional library routines. 48236 (line 1622) 48237* __fractunsudasi: Fixed-point fractional library routines. 48238 (line 1626) 48239* __fractunsudati: Fixed-point fractional library routines. 48240 (line 1630) 48241* __fractunsudqdi: Fixed-point fractional library routines. 48242 (line 1602) 48243* __fractunsudqhi: Fixed-point fractional library routines. 48244 (line 1598) 48245* __fractunsudqqi: Fixed-point fractional library routines. 48246 (line 1596) 48247* __fractunsudqsi: Fixed-point fractional library routines. 48248 (line 1600) 48249* __fractunsudqti: Fixed-point fractional library routines. 48250 (line 1604) 48251* __fractunsuhadi: Fixed-point fractional library routines. 48252 (line 1612) 48253* __fractunsuhahi: Fixed-point fractional library routines. 48254 (line 1608) 48255* __fractunsuhaqi: Fixed-point fractional library routines. 48256 (line 1606) 48257* __fractunsuhasi: Fixed-point fractional library routines. 48258 (line 1610) 48259* __fractunsuhati: Fixed-point fractional library routines. 48260 (line 1614) 48261* __fractunsuhqdi: Fixed-point fractional library routines. 48262 (line 1583) 48263* __fractunsuhqhi: Fixed-point fractional library routines. 48264 (line 1581) 48265* __fractunsuhqqi: Fixed-point fractional library routines. 48266 (line 1580) 48267* __fractunsuhqsi: Fixed-point fractional library routines. 48268 (line 1582) 48269* __fractunsuhqti: Fixed-point fractional library routines. 48270 (line 1584) 48271* __fractunsuqqdi: Fixed-point fractional library routines. 48272 (line 1576) 48273* __fractunsuqqhi: Fixed-point fractional library routines. 48274 (line 1572) 48275* __fractunsuqqqi: Fixed-point fractional library routines. 48276 (line 1570) 48277* __fractunsuqqsi: Fixed-point fractional library routines. 48278 (line 1574) 48279* __fractunsuqqti: Fixed-point fractional library routines. 48280 (line 1578) 48281* __fractunsusadi: Fixed-point fractional library routines. 48282 (line 1619) 48283* __fractunsusahi: Fixed-point fractional library routines. 48284 (line 1617) 48285* __fractunsusaqi: Fixed-point fractional library routines. 48286 (line 1616) 48287* __fractunsusasi: Fixed-point fractional library routines. 48288 (line 1618) 48289* __fractunsusati: Fixed-point fractional library routines. 48290 (line 1620) 48291* __fractunsusqdi: Fixed-point fractional library routines. 48292 (line 1592) 48293* __fractunsusqhi: Fixed-point fractional library routines. 48294 (line 1588) 48295* __fractunsusqqi: Fixed-point fractional library routines. 48296 (line 1586) 48297* __fractunsusqsi: Fixed-point fractional library routines. 48298 (line 1590) 48299* __fractunsusqti: Fixed-point fractional library routines. 48300 (line 1594) 48301* __fractunsutadi: Fixed-point fractional library routines. 48302 (line 1638) 48303* __fractunsutahi: Fixed-point fractional library routines. 48304 (line 1634) 48305* __fractunsutaqi: Fixed-point fractional library routines. 48306 (line 1632) 48307* __fractunsutasi: Fixed-point fractional library routines. 48308 (line 1636) 48309* __fractunsutati: Fixed-point fractional library routines. 48310 (line 1640) 48311* __fractuqqda: Fixed-point fractional library routines. 48312 (line 679) 48313* __fractuqqdf: Fixed-point fractional library routines. 48314 (line 702) 48315* __fractuqqdi: Fixed-point fractional library routines. 48316 (line 699) 48317* __fractuqqdq: Fixed-point fractional library routines. 48318 (line 675) 48319* __fractuqqha: Fixed-point fractional library routines. 48320 (line 677) 48321* __fractuqqhi: Fixed-point fractional library routines. 48322 (line 697) 48323* __fractuqqhq: Fixed-point fractional library routines. 48324 (line 673) 48325* __fractuqqqi: Fixed-point fractional library routines. 48326 (line 696) 48327* __fractuqqqq: Fixed-point fractional library routines. 48328 (line 672) 48329* __fractuqqsa: Fixed-point fractional library routines. 48330 (line 678) 48331* __fractuqqsf: Fixed-point fractional library routines. 48332 (line 701) 48333* __fractuqqsi: Fixed-point fractional library routines. 48334 (line 698) 48335* __fractuqqsq: Fixed-point fractional library routines. 48336 (line 674) 48337* __fractuqqta: Fixed-point fractional library routines. 48338 (line 680) 48339* __fractuqqti: Fixed-point fractional library routines. 48340 (line 700) 48341* __fractuqquda: Fixed-point fractional library routines. 48342 (line 692) 48343* __fractuqqudq2: Fixed-point fractional library routines. 48344 (line 686) 48345* __fractuqquha: Fixed-point fractional library routines. 48346 (line 688) 48347* __fractuqquhq2: Fixed-point fractional library routines. 48348 (line 682) 48349* __fractuqqusa: Fixed-point fractional library routines. 48350 (line 690) 48351* __fractuqqusq2: Fixed-point fractional library routines. 48352 (line 684) 48353* __fractuqquta: Fixed-point fractional library routines. 48354 (line 694) 48355* __fractusada: Fixed-point fractional library routines. 48356 (line 836) 48357* __fractusadf: Fixed-point fractional library routines. 48358 (line 857) 48359* __fractusadi: Fixed-point fractional library routines. 48360 (line 854) 48361* __fractusadq: Fixed-point fractional library routines. 48362 (line 833) 48363* __fractusaha: Fixed-point fractional library routines. 48364 (line 834) 48365* __fractusahi: Fixed-point fractional library routines. 48366 (line 852) 48367* __fractusahq: Fixed-point fractional library routines. 48368 (line 831) 48369* __fractusaqi: Fixed-point fractional library routines. 48370 (line 851) 48371* __fractusaqq: Fixed-point fractional library routines. 48372 (line 830) 48373* __fractusasa: Fixed-point fractional library routines. 48374 (line 835) 48375* __fractusasf: Fixed-point fractional library routines. 48376 (line 856) 48377* __fractusasi: Fixed-point fractional library routines. 48378 (line 853) 48379* __fractusasq: Fixed-point fractional library routines. 48380 (line 832) 48381* __fractusata: Fixed-point fractional library routines. 48382 (line 837) 48383* __fractusati: Fixed-point fractional library routines. 48384 (line 855) 48385* __fractusauda2: Fixed-point fractional library routines. 48386 (line 847) 48387* __fractusaudq: Fixed-point fractional library routines. 48388 (line 843) 48389* __fractusauha2: Fixed-point fractional library routines. 48390 (line 845) 48391* __fractusauhq: Fixed-point fractional library routines. 48392 (line 840) 48393* __fractusauqq: Fixed-point fractional library routines. 48394 (line 838) 48395* __fractusausq: Fixed-point fractional library routines. 48396 (line 841) 48397* __fractusauta2: Fixed-point fractional library routines. 48398 (line 849) 48399* __fractusqda: Fixed-point fractional library routines. 48400 (line 738) 48401* __fractusqdf: Fixed-point fractional library routines. 48402 (line 761) 48403* __fractusqdi: Fixed-point fractional library routines. 48404 (line 758) 48405* __fractusqdq: Fixed-point fractional library routines. 48406 (line 734) 48407* __fractusqha: Fixed-point fractional library routines. 48408 (line 736) 48409* __fractusqhi: Fixed-point fractional library routines. 48410 (line 756) 48411* __fractusqhq: Fixed-point fractional library routines. 48412 (line 732) 48413* __fractusqqi: Fixed-point fractional library routines. 48414 (line 755) 48415* __fractusqqq: Fixed-point fractional library routines. 48416 (line 731) 48417* __fractusqsa: Fixed-point fractional library routines. 48418 (line 737) 48419* __fractusqsf: Fixed-point fractional library routines. 48420 (line 760) 48421* __fractusqsi: Fixed-point fractional library routines. 48422 (line 757) 48423* __fractusqsq: Fixed-point fractional library routines. 48424 (line 733) 48425* __fractusqta: Fixed-point fractional library routines. 48426 (line 739) 48427* __fractusqti: Fixed-point fractional library routines. 48428 (line 759) 48429* __fractusquda: Fixed-point fractional library routines. 48430 (line 751) 48431* __fractusqudq2: Fixed-point fractional library routines. 48432 (line 745) 48433* __fractusquha: Fixed-point fractional library routines. 48434 (line 747) 48435* __fractusquhq2: Fixed-point fractional library routines. 48436 (line 743) 48437* __fractusquqq2: Fixed-point fractional library routines. 48438 (line 741) 48439* __fractusqusa: Fixed-point fractional library routines. 48440 (line 749) 48441* __fractusquta: Fixed-point fractional library routines. 48442 (line 753) 48443* __fractutada: Fixed-point fractional library routines. 48444 (line 899) 48445* __fractutadf: Fixed-point fractional library routines. 48446 (line 925) 48447* __fractutadi: Fixed-point fractional library routines. 48448 (line 921) 48449* __fractutadq: Fixed-point fractional library routines. 48450 (line 894) 48451* __fractutaha: Fixed-point fractional library routines. 48452 (line 896) 48453* __fractutahi: Fixed-point fractional library routines. 48454 (line 919) 48455* __fractutahq: Fixed-point fractional library routines. 48456 (line 891) 48457* __fractutaqi: Fixed-point fractional library routines. 48458 (line 917) 48459* __fractutaqq: Fixed-point fractional library routines. 48460 (line 889) 48461* __fractutasa: Fixed-point fractional library routines. 48462 (line 898) 48463* __fractutasf: Fixed-point fractional library routines. 48464 (line 924) 48465* __fractutasi: Fixed-point fractional library routines. 48466 (line 920) 48467* __fractutasq: Fixed-point fractional library routines. 48468 (line 892) 48469* __fractutata: Fixed-point fractional library routines. 48470 (line 901) 48471* __fractutati: Fixed-point fractional library routines. 48472 (line 922) 48473* __fractutauda2: Fixed-point fractional library routines. 48474 (line 915) 48475* __fractutaudq: Fixed-point fractional library routines. 48476 (line 909) 48477* __fractutauha2: Fixed-point fractional library routines. 48478 (line 911) 48479* __fractutauhq: Fixed-point fractional library routines. 48480 (line 905) 48481* __fractutauqq: Fixed-point fractional library routines. 48482 (line 903) 48483* __fractutausa2: Fixed-point fractional library routines. 48484 (line 913) 48485* __fractutausq: Fixed-point fractional library routines. 48486 (line 907) 48487* __gedf2: Soft float library routines. 48488 (line 205) 48489* __gesf2: Soft float library routines. 48490 (line 204) 48491* __getf2: Soft float library routines. 48492 (line 206) 48493* __gtdf2: Soft float library routines. 48494 (line 223) 48495* __gtsf2: Soft float library routines. 48496 (line 222) 48497* __gttf2: Soft float library routines. 48498 (line 224) 48499* __ledf2: Soft float library routines. 48500 (line 217) 48501* __lesf2: Soft float library routines. 48502 (line 216) 48503* __letf2: Soft float library routines. 48504 (line 218) 48505* __lshrdi3: Integer library routines. 48506 (line 30) 48507* __lshrsi3: Integer library routines. 48508 (line 29) 48509* __lshrti3: Integer library routines. 48510 (line 31) 48511* __lshruda3: Fixed-point fractional library routines. 48512 (line 396) 48513* __lshrudq3: Fixed-point fractional library routines. 48514 (line 390) 48515* __lshruha3: Fixed-point fractional library routines. 48516 (line 392) 48517* __lshruhq3: Fixed-point fractional library routines. 48518 (line 386) 48519* __lshruqq3: Fixed-point fractional library routines. 48520 (line 384) 48521* __lshrusa3: Fixed-point fractional library routines. 48522 (line 394) 48523* __lshrusq3: Fixed-point fractional library routines. 48524 (line 388) 48525* __lshruta3: Fixed-point fractional library routines. 48526 (line 398) 48527* __ltdf2: Soft float library routines. 48528 (line 211) 48529* __ltsf2: Soft float library routines. 48530 (line 210) 48531* __lttf2: Soft float library routines. 48532 (line 212) 48533* __main: Collect2. (line 15) 48534* __moddi3: Integer library routines. 48535 (line 36) 48536* __modsi3: Integer library routines. 48537 (line 35) 48538* __modti3: Integer library routines. 48539 (line 37) 48540* __morestack_current_segment: Miscellaneous routines. 48541 (line 45) 48542* __morestack_initial_sp: Miscellaneous routines. 48543 (line 46) 48544* __morestack_segments: Miscellaneous routines. 48545 (line 44) 48546* __mulda3: Fixed-point fractional library routines. 48547 (line 178) 48548* __muldc3: Soft float library routines. 48549 (line 239) 48550* __muldf3: Soft float library routines. 48551 (line 39) 48552* __muldi3: Integer library routines. 48553 (line 42) 48554* __muldq3: Fixed-point fractional library routines. 48555 (line 165) 48556* __mulha3: Fixed-point fractional library routines. 48557 (line 175) 48558* __mulhq3: Fixed-point fractional library routines. 48559 (line 163) 48560* __mulqq3: Fixed-point fractional library routines. 48561 (line 161) 48562* __mulsa3: Fixed-point fractional library routines. 48563 (line 177) 48564* __mulsc3: Soft float library routines. 48565 (line 237) 48566* __mulsf3: Soft float library routines. 48567 (line 38) 48568* __mulsi3: Integer library routines. 48569 (line 41) 48570* __mulsq3: Fixed-point fractional library routines. 48571 (line 164) 48572* __multa3: Fixed-point fractional library routines. 48573 (line 179) 48574* __multc3: Soft float library routines. 48575 (line 241) 48576* __multf3: Soft float library routines. 48577 (line 40) 48578* __multi3: Integer library routines. 48579 (line 43) 48580* __muluda3: Fixed-point fractional library routines. 48581 (line 185) 48582* __muludq3: Fixed-point fractional library routines. 48583 (line 173) 48584* __muluha3: Fixed-point fractional library routines. 48585 (line 181) 48586* __muluhq3: Fixed-point fractional library routines. 48587 (line 169) 48588* __muluqq3: Fixed-point fractional library routines. 48589 (line 167) 48590* __mulusa3: Fixed-point fractional library routines. 48591 (line 183) 48592* __mulusq3: Fixed-point fractional library routines. 48593 (line 171) 48594* __muluta3: Fixed-point fractional library routines. 48595 (line 187) 48596* __mulvdi3: Integer library routines. 48597 (line 114) 48598* __mulvsi3: Integer library routines. 48599 (line 113) 48600* __mulxc3: Soft float library routines. 48601 (line 243) 48602* __mulxf3: Soft float library routines. 48603 (line 42) 48604* __nedf2: Soft float library routines. 48605 (line 199) 48606* __negda2: Fixed-point fractional library routines. 48607 (line 306) 48608* __negdf2: Soft float library routines. 48609 (line 55) 48610* __negdi2: Integer library routines. 48611 (line 46) 48612* __negdq2: Fixed-point fractional library routines. 48613 (line 296) 48614* __negha2: Fixed-point fractional library routines. 48615 (line 304) 48616* __neghq2: Fixed-point fractional library routines. 48617 (line 294) 48618* __negqq2: Fixed-point fractional library routines. 48619 (line 293) 48620* __negsa2: Fixed-point fractional library routines. 48621 (line 305) 48622* __negsf2: Soft float library routines. 48623 (line 54) 48624* __negsq2: Fixed-point fractional library routines. 48625 (line 295) 48626* __negta2: Fixed-point fractional library routines. 48627 (line 307) 48628* __negtf2: Soft float library routines. 48629 (line 56) 48630* __negti2: Integer library routines. 48631 (line 47) 48632* __neguda2: Fixed-point fractional library routines. 48633 (line 311) 48634* __negudq2: Fixed-point fractional library routines. 48635 (line 302) 48636* __neguha2: Fixed-point fractional library routines. 48637 (line 308) 48638* __neguhq2: Fixed-point fractional library routines. 48639 (line 299) 48640* __neguqq2: Fixed-point fractional library routines. 48641 (line 297) 48642* __negusa2: Fixed-point fractional library routines. 48643 (line 310) 48644* __negusq2: Fixed-point fractional library routines. 48645 (line 300) 48646* __neguta2: Fixed-point fractional library routines. 48647 (line 313) 48648* __negvdi2: Integer library routines. 48649 (line 118) 48650* __negvsi2: Integer library routines. 48651 (line 117) 48652* __negxf2: Soft float library routines. 48653 (line 57) 48654* __nesf2: Soft float library routines. 48655 (line 198) 48656* __netf2: Soft float library routines. 48657 (line 200) 48658* __paritydi2: Integer library routines. 48659 (line 150) 48660* __paritysi2: Integer library routines. 48661 (line 149) 48662* __parityti2: Integer library routines. 48663 (line 151) 48664* __popcountdi2: Integer library routines. 48665 (line 156) 48666* __popcountsi2: Integer library routines. 48667 (line 155) 48668* __popcountti2: Integer library routines. 48669 (line 157) 48670* __powidf2: Soft float library routines. 48671 (line 232) 48672* __powisf2: Soft float library routines. 48673 (line 231) 48674* __powitf2: Soft float library routines. 48675 (line 233) 48676* __powixf2: Soft float library routines. 48677 (line 234) 48678* __satfractdadq: Fixed-point fractional library routines. 48679 (line 1160) 48680* __satfractdaha2: Fixed-point fractional library routines. 48681 (line 1161) 48682* __satfractdahq: Fixed-point fractional library routines. 48683 (line 1158) 48684* __satfractdaqq: Fixed-point fractional library routines. 48685 (line 1157) 48686* __satfractdasa2: Fixed-point fractional library routines. 48687 (line 1162) 48688* __satfractdasq: Fixed-point fractional library routines. 48689 (line 1159) 48690* __satfractdata2: Fixed-point fractional library routines. 48691 (line 1163) 48692* __satfractdauda: Fixed-point fractional library routines. 48693 (line 1173) 48694* __satfractdaudq: Fixed-point fractional library routines. 48695 (line 1168) 48696* __satfractdauha: Fixed-point fractional library routines. 48697 (line 1170) 48698* __satfractdauhq: Fixed-point fractional library routines. 48699 (line 1166) 48700* __satfractdauqq: Fixed-point fractional library routines. 48701 (line 1164) 48702* __satfractdausa: Fixed-point fractional library routines. 48703 (line 1172) 48704* __satfractdausq: Fixed-point fractional library routines. 48705 (line 1167) 48706* __satfractdauta: Fixed-point fractional library routines. 48707 (line 1174) 48708* __satfractdfda: Fixed-point fractional library routines. 48709 (line 1513) 48710* __satfractdfdq: Fixed-point fractional library routines. 48711 (line 1510) 48712* __satfractdfha: Fixed-point fractional library routines. 48713 (line 1511) 48714* __satfractdfhq: Fixed-point fractional library routines. 48715 (line 1508) 48716* __satfractdfqq: Fixed-point fractional library routines. 48717 (line 1507) 48718* __satfractdfsa: Fixed-point fractional library routines. 48719 (line 1512) 48720* __satfractdfsq: Fixed-point fractional library routines. 48721 (line 1509) 48722* __satfractdfta: Fixed-point fractional library routines. 48723 (line 1514) 48724* __satfractdfuda: Fixed-point fractional library routines. 48725 (line 1522) 48726* __satfractdfudq: Fixed-point fractional library routines. 48727 (line 1518) 48728* __satfractdfuha: Fixed-point fractional library routines. 48729 (line 1520) 48730* __satfractdfuhq: Fixed-point fractional library routines. 48731 (line 1516) 48732* __satfractdfuqq: Fixed-point fractional library routines. 48733 (line 1515) 48734* __satfractdfusa: Fixed-point fractional library routines. 48735 (line 1521) 48736* __satfractdfusq: Fixed-point fractional library routines. 48737 (line 1517) 48738* __satfractdfuta: Fixed-point fractional library routines. 48739 (line 1523) 48740* __satfractdida: Fixed-point fractional library routines. 48741 (line 1463) 48742* __satfractdidq: Fixed-point fractional library routines. 48743 (line 1460) 48744* __satfractdiha: Fixed-point fractional library routines. 48745 (line 1461) 48746* __satfractdihq: Fixed-point fractional library routines. 48747 (line 1458) 48748* __satfractdiqq: Fixed-point fractional library routines. 48749 (line 1457) 48750* __satfractdisa: Fixed-point fractional library routines. 48751 (line 1462) 48752* __satfractdisq: Fixed-point fractional library routines. 48753 (line 1459) 48754* __satfractdita: Fixed-point fractional library routines. 48755 (line 1464) 48756* __satfractdiuda: Fixed-point fractional library routines. 48757 (line 1471) 48758* __satfractdiudq: Fixed-point fractional library routines. 48759 (line 1468) 48760* __satfractdiuha: Fixed-point fractional library routines. 48761 (line 1469) 48762* __satfractdiuhq: Fixed-point fractional library routines. 48763 (line 1466) 48764* __satfractdiuqq: Fixed-point fractional library routines. 48765 (line 1465) 48766* __satfractdiusa: Fixed-point fractional library routines. 48767 (line 1470) 48768* __satfractdiusq: Fixed-point fractional library routines. 48769 (line 1467) 48770* __satfractdiuta: Fixed-point fractional library routines. 48771 (line 1472) 48772* __satfractdqda: Fixed-point fractional library routines. 48773 (line 1105) 48774* __satfractdqha: Fixed-point fractional library routines. 48775 (line 1103) 48776* __satfractdqhq2: Fixed-point fractional library routines. 48777 (line 1101) 48778* __satfractdqqq2: Fixed-point fractional library routines. 48779 (line 1100) 48780* __satfractdqsa: Fixed-point fractional library routines. 48781 (line 1104) 48782* __satfractdqsq2: Fixed-point fractional library routines. 48783 (line 1102) 48784* __satfractdqta: Fixed-point fractional library routines. 48785 (line 1106) 48786* __satfractdquda: Fixed-point fractional library routines. 48787 (line 1117) 48788* __satfractdqudq: Fixed-point fractional library routines. 48789 (line 1112) 48790* __satfractdquha: Fixed-point fractional library routines. 48791 (line 1114) 48792* __satfractdquhq: Fixed-point fractional library routines. 48793 (line 1109) 48794* __satfractdquqq: Fixed-point fractional library routines. 48795 (line 1107) 48796* __satfractdqusa: Fixed-point fractional library routines. 48797 (line 1116) 48798* __satfractdqusq: Fixed-point fractional library routines. 48799 (line 1110) 48800* __satfractdquta: Fixed-point fractional library routines. 48801 (line 1119) 48802* __satfracthada2: Fixed-point fractional library routines. 48803 (line 1126) 48804* __satfracthadq: Fixed-point fractional library routines. 48805 (line 1124) 48806* __satfracthahq: Fixed-point fractional library routines. 48807 (line 1122) 48808* __satfracthaqq: Fixed-point fractional library routines. 48809 (line 1121) 48810* __satfracthasa2: Fixed-point fractional library routines. 48811 (line 1125) 48812* __satfracthasq: Fixed-point fractional library routines. 48813 (line 1123) 48814* __satfracthata2: Fixed-point fractional library routines. 48815 (line 1127) 48816* __satfracthauda: Fixed-point fractional library routines. 48817 (line 1138) 48818* __satfracthaudq: Fixed-point fractional library routines. 48819 (line 1133) 48820* __satfracthauha: Fixed-point fractional library routines. 48821 (line 1135) 48822* __satfracthauhq: Fixed-point fractional library routines. 48823 (line 1130) 48824* __satfracthauqq: Fixed-point fractional library routines. 48825 (line 1128) 48826* __satfracthausa: Fixed-point fractional library routines. 48827 (line 1137) 48828* __satfracthausq: Fixed-point fractional library routines. 48829 (line 1131) 48830* __satfracthauta: Fixed-point fractional library routines. 48831 (line 1140) 48832* __satfracthida: Fixed-point fractional library routines. 48833 (line 1431) 48834* __satfracthidq: Fixed-point fractional library routines. 48835 (line 1428) 48836* __satfracthiha: Fixed-point fractional library routines. 48837 (line 1429) 48838* __satfracthihq: Fixed-point fractional library routines. 48839 (line 1426) 48840* __satfracthiqq: Fixed-point fractional library routines. 48841 (line 1425) 48842* __satfracthisa: Fixed-point fractional library routines. 48843 (line 1430) 48844* __satfracthisq: Fixed-point fractional library routines. 48845 (line 1427) 48846* __satfracthita: Fixed-point fractional library routines. 48847 (line 1432) 48848* __satfracthiuda: Fixed-point fractional library routines. 48849 (line 1439) 48850* __satfracthiudq: Fixed-point fractional library routines. 48851 (line 1436) 48852* __satfracthiuha: Fixed-point fractional library routines. 48853 (line 1437) 48854* __satfracthiuhq: Fixed-point fractional library routines. 48855 (line 1434) 48856* __satfracthiuqq: Fixed-point fractional library routines. 48857 (line 1433) 48858* __satfracthiusa: Fixed-point fractional library routines. 48859 (line 1438) 48860* __satfracthiusq: Fixed-point fractional library routines. 48861 (line 1435) 48862* __satfracthiuta: Fixed-point fractional library routines. 48863 (line 1440) 48864* __satfracthqda: Fixed-point fractional library routines. 48865 (line 1071) 48866* __satfracthqdq2: Fixed-point fractional library routines. 48867 (line 1068) 48868* __satfracthqha: Fixed-point fractional library routines. 48869 (line 1069) 48870* __satfracthqqq2: Fixed-point fractional library routines. 48871 (line 1066) 48872* __satfracthqsa: Fixed-point fractional library routines. 48873 (line 1070) 48874* __satfracthqsq2: Fixed-point fractional library routines. 48875 (line 1067) 48876* __satfracthqta: Fixed-point fractional library routines. 48877 (line 1072) 48878* __satfracthquda: Fixed-point fractional library routines. 48879 (line 1079) 48880* __satfracthqudq: Fixed-point fractional library routines. 48881 (line 1076) 48882* __satfracthquha: Fixed-point fractional library routines. 48883 (line 1077) 48884* __satfracthquhq: Fixed-point fractional library routines. 48885 (line 1074) 48886* __satfracthquqq: Fixed-point fractional library routines. 48887 (line 1073) 48888* __satfracthqusa: Fixed-point fractional library routines. 48889 (line 1078) 48890* __satfracthqusq: Fixed-point fractional library routines. 48891 (line 1075) 48892* __satfracthquta: Fixed-point fractional library routines. 48893 (line 1080) 48894* __satfractqida: Fixed-point fractional library routines. 48895 (line 1409) 48896* __satfractqidq: Fixed-point fractional library routines. 48897 (line 1406) 48898* __satfractqiha: Fixed-point fractional library routines. 48899 (line 1407) 48900* __satfractqihq: Fixed-point fractional library routines. 48901 (line 1404) 48902* __satfractqiqq: Fixed-point fractional library routines. 48903 (line 1403) 48904* __satfractqisa: Fixed-point fractional library routines. 48905 (line 1408) 48906* __satfractqisq: Fixed-point fractional library routines. 48907 (line 1405) 48908* __satfractqita: Fixed-point fractional library routines. 48909 (line 1410) 48910* __satfractqiuda: Fixed-point fractional library routines. 48911 (line 1421) 48912* __satfractqiudq: Fixed-point fractional library routines. 48913 (line 1416) 48914* __satfractqiuha: Fixed-point fractional library routines. 48915 (line 1418) 48916* __satfractqiuhq: Fixed-point fractional library routines. 48917 (line 1413) 48918* __satfractqiuqq: Fixed-point fractional library routines. 48919 (line 1411) 48920* __satfractqiusa: Fixed-point fractional library routines. 48921 (line 1420) 48922* __satfractqiusq: Fixed-point fractional library routines. 48923 (line 1414) 48924* __satfractqiuta: Fixed-point fractional library routines. 48925 (line 1423) 48926* __satfractqqda: Fixed-point fractional library routines. 48927 (line 1050) 48928* __satfractqqdq2: Fixed-point fractional library routines. 48929 (line 1047) 48930* __satfractqqha: Fixed-point fractional library routines. 48931 (line 1048) 48932* __satfractqqhq2: Fixed-point fractional library routines. 48933 (line 1045) 48934* __satfractqqsa: Fixed-point fractional library routines. 48935 (line 1049) 48936* __satfractqqsq2: Fixed-point fractional library routines. 48937 (line 1046) 48938* __satfractqqta: Fixed-point fractional library routines. 48939 (line 1051) 48940* __satfractqquda: Fixed-point fractional library routines. 48941 (line 1062) 48942* __satfractqqudq: Fixed-point fractional library routines. 48943 (line 1057) 48944* __satfractqquha: Fixed-point fractional library routines. 48945 (line 1059) 48946* __satfractqquhq: Fixed-point fractional library routines. 48947 (line 1054) 48948* __satfractqquqq: Fixed-point fractional library routines. 48949 (line 1052) 48950* __satfractqqusa: Fixed-point fractional library routines. 48951 (line 1061) 48952* __satfractqqusq: Fixed-point fractional library routines. 48953 (line 1055) 48954* __satfractqquta: Fixed-point fractional library routines. 48955 (line 1064) 48956* __satfractsada2: Fixed-point fractional library routines. 48957 (line 1147) 48958* __satfractsadq: Fixed-point fractional library routines. 48959 (line 1145) 48960* __satfractsaha2: Fixed-point fractional library routines. 48961 (line 1146) 48962* __satfractsahq: Fixed-point fractional library routines. 48963 (line 1143) 48964* __satfractsaqq: Fixed-point fractional library routines. 48965 (line 1142) 48966* __satfractsasq: Fixed-point fractional library routines. 48967 (line 1144) 48968* __satfractsata2: Fixed-point fractional library routines. 48969 (line 1148) 48970* __satfractsauda: Fixed-point fractional library routines. 48971 (line 1155) 48972* __satfractsaudq: Fixed-point fractional library routines. 48973 (line 1152) 48974* __satfractsauha: Fixed-point fractional library routines. 48975 (line 1153) 48976* __satfractsauhq: Fixed-point fractional library routines. 48977 (line 1150) 48978* __satfractsauqq: Fixed-point fractional library routines. 48979 (line 1149) 48980* __satfractsausa: Fixed-point fractional library routines. 48981 (line 1154) 48982* __satfractsausq: Fixed-point fractional library routines. 48983 (line 1151) 48984* __satfractsauta: Fixed-point fractional library routines. 48985 (line 1156) 48986* __satfractsfda: Fixed-point fractional library routines. 48987 (line 1497) 48988* __satfractsfdq: Fixed-point fractional library routines. 48989 (line 1494) 48990* __satfractsfha: Fixed-point fractional library routines. 48991 (line 1495) 48992* __satfractsfhq: Fixed-point fractional library routines. 48993 (line 1492) 48994* __satfractsfqq: Fixed-point fractional library routines. 48995 (line 1491) 48996* __satfractsfsa: Fixed-point fractional library routines. 48997 (line 1496) 48998* __satfractsfsq: Fixed-point fractional library routines. 48999 (line 1493) 49000* __satfractsfta: Fixed-point fractional library routines. 49001 (line 1498) 49002* __satfractsfuda: Fixed-point fractional library routines. 49003 (line 1505) 49004* __satfractsfudq: Fixed-point fractional library routines. 49005 (line 1502) 49006* __satfractsfuha: Fixed-point fractional library routines. 49007 (line 1503) 49008* __satfractsfuhq: Fixed-point fractional library routines. 49009 (line 1500) 49010* __satfractsfuqq: Fixed-point fractional library routines. 49011 (line 1499) 49012* __satfractsfusa: Fixed-point fractional library routines. 49013 (line 1504) 49014* __satfractsfusq: Fixed-point fractional library routines. 49015 (line 1501) 49016* __satfractsfuta: Fixed-point fractional library routines. 49017 (line 1506) 49018* __satfractsida: Fixed-point fractional library routines. 49019 (line 1447) 49020* __satfractsidq: Fixed-point fractional library routines. 49021 (line 1444) 49022* __satfractsiha: Fixed-point fractional library routines. 49023 (line 1445) 49024* __satfractsihq: Fixed-point fractional library routines. 49025 (line 1442) 49026* __satfractsiqq: Fixed-point fractional library routines. 49027 (line 1441) 49028* __satfractsisa: Fixed-point fractional library routines. 49029 (line 1446) 49030* __satfractsisq: Fixed-point fractional library routines. 49031 (line 1443) 49032* __satfractsita: Fixed-point fractional library routines. 49033 (line 1448) 49034* __satfractsiuda: Fixed-point fractional library routines. 49035 (line 1455) 49036* __satfractsiudq: Fixed-point fractional library routines. 49037 (line 1452) 49038* __satfractsiuha: Fixed-point fractional library routines. 49039 (line 1453) 49040* __satfractsiuhq: Fixed-point fractional library routines. 49041 (line 1450) 49042* __satfractsiuqq: Fixed-point fractional library routines. 49043 (line 1449) 49044* __satfractsiusa: Fixed-point fractional library routines. 49045 (line 1454) 49046* __satfractsiusq: Fixed-point fractional library routines. 49047 (line 1451) 49048* __satfractsiuta: Fixed-point fractional library routines. 49049 (line 1456) 49050* __satfractsqda: Fixed-point fractional library routines. 49051 (line 1086) 49052* __satfractsqdq2: Fixed-point fractional library routines. 49053 (line 1083) 49054* __satfractsqha: Fixed-point fractional library routines. 49055 (line 1084) 49056* __satfractsqhq2: Fixed-point fractional library routines. 49057 (line 1082) 49058* __satfractsqqq2: Fixed-point fractional library routines. 49059 (line 1081) 49060* __satfractsqsa: Fixed-point fractional library routines. 49061 (line 1085) 49062* __satfractsqta: Fixed-point fractional library routines. 49063 (line 1087) 49064* __satfractsquda: Fixed-point fractional library routines. 49065 (line 1097) 49066* __satfractsqudq: Fixed-point fractional library routines. 49067 (line 1092) 49068* __satfractsquha: Fixed-point fractional library routines. 49069 (line 1094) 49070* __satfractsquhq: Fixed-point fractional library routines. 49071 (line 1090) 49072* __satfractsquqq: Fixed-point fractional library routines. 49073 (line 1088) 49074* __satfractsqusa: Fixed-point fractional library routines. 49075 (line 1096) 49076* __satfractsqusq: Fixed-point fractional library routines. 49077 (line 1091) 49078* __satfractsquta: Fixed-point fractional library routines. 49079 (line 1098) 49080* __satfracttada2: Fixed-point fractional library routines. 49081 (line 1182) 49082* __satfracttadq: Fixed-point fractional library routines. 49083 (line 1179) 49084* __satfracttaha2: Fixed-point fractional library routines. 49085 (line 1180) 49086* __satfracttahq: Fixed-point fractional library routines. 49087 (line 1177) 49088* __satfracttaqq: Fixed-point fractional library routines. 49089 (line 1176) 49090* __satfracttasa2: Fixed-point fractional library routines. 49091 (line 1181) 49092* __satfracttasq: Fixed-point fractional library routines. 49093 (line 1178) 49094* __satfracttauda: Fixed-point fractional library routines. 49095 (line 1193) 49096* __satfracttaudq: Fixed-point fractional library routines. 49097 (line 1188) 49098* __satfracttauha: Fixed-point fractional library routines. 49099 (line 1190) 49100* __satfracttauhq: Fixed-point fractional library routines. 49101 (line 1185) 49102* __satfracttauqq: Fixed-point fractional library routines. 49103 (line 1183) 49104* __satfracttausa: Fixed-point fractional library routines. 49105 (line 1192) 49106* __satfracttausq: Fixed-point fractional library routines. 49107 (line 1186) 49108* __satfracttauta: Fixed-point fractional library routines. 49109 (line 1195) 49110* __satfracttida: Fixed-point fractional library routines. 49111 (line 1479) 49112* __satfracttidq: Fixed-point fractional library routines. 49113 (line 1476) 49114* __satfracttiha: Fixed-point fractional library routines. 49115 (line 1477) 49116* __satfracttihq: Fixed-point fractional library routines. 49117 (line 1474) 49118* __satfracttiqq: Fixed-point fractional library routines. 49119 (line 1473) 49120* __satfracttisa: Fixed-point fractional library routines. 49121 (line 1478) 49122* __satfracttisq: Fixed-point fractional library routines. 49123 (line 1475) 49124* __satfracttita: Fixed-point fractional library routines. 49125 (line 1480) 49126* __satfracttiuda: Fixed-point fractional library routines. 49127 (line 1488) 49128* __satfracttiudq: Fixed-point fractional library routines. 49129 (line 1484) 49130* __satfracttiuha: Fixed-point fractional library routines. 49131 (line 1486) 49132* __satfracttiuhq: Fixed-point fractional library routines. 49133 (line 1482) 49134* __satfracttiuqq: Fixed-point fractional library routines. 49135 (line 1481) 49136* __satfracttiusa: Fixed-point fractional library routines. 49137 (line 1487) 49138* __satfracttiusq: Fixed-point fractional library routines. 49139 (line 1483) 49140* __satfracttiuta: Fixed-point fractional library routines. 49141 (line 1489) 49142* __satfractudada: Fixed-point fractional library routines. 49143 (line 1358) 49144* __satfractudadq: Fixed-point fractional library routines. 49145 (line 1353) 49146* __satfractudaha: Fixed-point fractional library routines. 49147 (line 1355) 49148* __satfractudahq: Fixed-point fractional library routines. 49149 (line 1351) 49150* __satfractudaqq: Fixed-point fractional library routines. 49151 (line 1349) 49152* __satfractudasa: Fixed-point fractional library routines. 49153 (line 1357) 49154* __satfractudasq: Fixed-point fractional library routines. 49155 (line 1352) 49156* __satfractudata: Fixed-point fractional library routines. 49157 (line 1359) 49158* __satfractudaudq: Fixed-point fractional library routines. 49159 (line 1367) 49160* __satfractudauha2: Fixed-point fractional library routines. 49161 (line 1369) 49162* __satfractudauhq: Fixed-point fractional library routines. 49163 (line 1363) 49164* __satfractudauqq: Fixed-point fractional library routines. 49165 (line 1361) 49166* __satfractudausa2: Fixed-point fractional library routines. 49167 (line 1371) 49168* __satfractudausq: Fixed-point fractional library routines. 49169 (line 1365) 49170* __satfractudauta2: Fixed-point fractional library routines. 49171 (line 1373) 49172* __satfractudqda: Fixed-point fractional library routines. 49173 (line 1282) 49174* __satfractudqdq: Fixed-point fractional library routines. 49175 (line 1277) 49176* __satfractudqha: Fixed-point fractional library routines. 49177 (line 1279) 49178* __satfractudqhq: Fixed-point fractional library routines. 49179 (line 1274) 49180* __satfractudqqq: Fixed-point fractional library routines. 49181 (line 1272) 49182* __satfractudqsa: Fixed-point fractional library routines. 49183 (line 1281) 49184* __satfractudqsq: Fixed-point fractional library routines. 49185 (line 1275) 49186* __satfractudqta: Fixed-point fractional library routines. 49187 (line 1284) 49188* __satfractudquda: Fixed-point fractional library routines. 49189 (line 1296) 49190* __satfractudquha: Fixed-point fractional library routines. 49191 (line 1292) 49192* __satfractudquhq2: Fixed-point fractional library routines. 49193 (line 1288) 49194* __satfractudquqq2: Fixed-point fractional library routines. 49195 (line 1286) 49196* __satfractudqusa: Fixed-point fractional library routines. 49197 (line 1294) 49198* __satfractudqusq2: Fixed-point fractional library routines. 49199 (line 1290) 49200* __satfractudquta: Fixed-point fractional library routines. 49201 (line 1298) 49202* __satfractuhada: Fixed-point fractional library routines. 49203 (line 1310) 49204* __satfractuhadq: Fixed-point fractional library routines. 49205 (line 1305) 49206* __satfractuhaha: Fixed-point fractional library routines. 49207 (line 1307) 49208* __satfractuhahq: Fixed-point fractional library routines. 49209 (line 1302) 49210* __satfractuhaqq: Fixed-point fractional library routines. 49211 (line 1300) 49212* __satfractuhasa: Fixed-point fractional library routines. 49213 (line 1309) 49214* __satfractuhasq: Fixed-point fractional library routines. 49215 (line 1303) 49216* __satfractuhata: Fixed-point fractional library routines. 49217 (line 1312) 49218* __satfractuhauda2: Fixed-point fractional library routines. 49219 (line 1324) 49220* __satfractuhaudq: Fixed-point fractional library routines. 49221 (line 1320) 49222* __satfractuhauhq: Fixed-point fractional library routines. 49223 (line 1316) 49224* __satfractuhauqq: Fixed-point fractional library routines. 49225 (line 1314) 49226* __satfractuhausa2: Fixed-point fractional library routines. 49227 (line 1322) 49228* __satfractuhausq: Fixed-point fractional library routines. 49229 (line 1318) 49230* __satfractuhauta2: Fixed-point fractional library routines. 49231 (line 1326) 49232* __satfractuhqda: Fixed-point fractional library routines. 49233 (line 1231) 49234* __satfractuhqdq: Fixed-point fractional library routines. 49235 (line 1228) 49236* __satfractuhqha: Fixed-point fractional library routines. 49237 (line 1229) 49238* __satfractuhqhq: Fixed-point fractional library routines. 49239 (line 1226) 49240* __satfractuhqqq: Fixed-point fractional library routines. 49241 (line 1225) 49242* __satfractuhqsa: Fixed-point fractional library routines. 49243 (line 1230) 49244* __satfractuhqsq: Fixed-point fractional library routines. 49245 (line 1227) 49246* __satfractuhqta: Fixed-point fractional library routines. 49247 (line 1232) 49248* __satfractuhquda: Fixed-point fractional library routines. 49249 (line 1242) 49250* __satfractuhqudq2: Fixed-point fractional library routines. 49251 (line 1237) 49252* __satfractuhquha: Fixed-point fractional library routines. 49253 (line 1239) 49254* __satfractuhquqq2: Fixed-point fractional library routines. 49255 (line 1233) 49256* __satfractuhqusa: Fixed-point fractional library routines. 49257 (line 1241) 49258* __satfractuhqusq2: Fixed-point fractional library routines. 49259 (line 1235) 49260* __satfractuhquta: Fixed-point fractional library routines. 49261 (line 1244) 49262* __satfractunsdida: Fixed-point fractional library routines. 49263 (line 1841) 49264* __satfractunsdidq: Fixed-point fractional library routines. 49265 (line 1837) 49266* __satfractunsdiha: Fixed-point fractional library routines. 49267 (line 1839) 49268* __satfractunsdihq: Fixed-point fractional library routines. 49269 (line 1835) 49270* __satfractunsdiqq: Fixed-point fractional library routines. 49271 (line 1834) 49272* __satfractunsdisa: Fixed-point fractional library routines. 49273 (line 1840) 49274* __satfractunsdisq: Fixed-point fractional library routines. 49275 (line 1836) 49276* __satfractunsdita: Fixed-point fractional library routines. 49277 (line 1842) 49278* __satfractunsdiuda: Fixed-point fractional library routines. 49279 (line 1856) 49280* __satfractunsdiudq: Fixed-point fractional library routines. 49281 (line 1850) 49282* __satfractunsdiuha: Fixed-point fractional library routines. 49283 (line 1852) 49284* __satfractunsdiuhq: Fixed-point fractional library routines. 49285 (line 1846) 49286* __satfractunsdiuqq: Fixed-point fractional library routines. 49287 (line 1844) 49288* __satfractunsdiusa: Fixed-point fractional library routines. 49289 (line 1854) 49290* __satfractunsdiusq: Fixed-point fractional library routines. 49291 (line 1848) 49292* __satfractunsdiuta: Fixed-point fractional library routines. 49293 (line 1858) 49294* __satfractunshida: Fixed-point fractional library routines. 49295 (line 1793) 49296* __satfractunshidq: Fixed-point fractional library routines. 49297 (line 1789) 49298* __satfractunshiha: Fixed-point fractional library routines. 49299 (line 1791) 49300* __satfractunshihq: Fixed-point fractional library routines. 49301 (line 1787) 49302* __satfractunshiqq: Fixed-point fractional library routines. 49303 (line 1786) 49304* __satfractunshisa: Fixed-point fractional library routines. 49305 (line 1792) 49306* __satfractunshisq: Fixed-point fractional library routines. 49307 (line 1788) 49308* __satfractunshita: Fixed-point fractional library routines. 49309 (line 1794) 49310* __satfractunshiuda: Fixed-point fractional library routines. 49311 (line 1808) 49312* __satfractunshiudq: Fixed-point fractional library routines. 49313 (line 1802) 49314* __satfractunshiuha: Fixed-point fractional library routines. 49315 (line 1804) 49316* __satfractunshiuhq: Fixed-point fractional library routines. 49317 (line 1798) 49318* __satfractunshiuqq: Fixed-point fractional library routines. 49319 (line 1796) 49320* __satfractunshiusa: Fixed-point fractional library routines. 49321 (line 1806) 49322* __satfractunshiusq: Fixed-point fractional library routines. 49323 (line 1800) 49324* __satfractunshiuta: Fixed-point fractional library routines. 49325 (line 1810) 49326* __satfractunsqida: Fixed-point fractional library routines. 49327 (line 1767) 49328* __satfractunsqidq: Fixed-point fractional library routines. 49329 (line 1763) 49330* __satfractunsqiha: Fixed-point fractional library routines. 49331 (line 1765) 49332* __satfractunsqihq: Fixed-point fractional library routines. 49333 (line 1761) 49334* __satfractunsqiqq: Fixed-point fractional library routines. 49335 (line 1760) 49336* __satfractunsqisa: Fixed-point fractional library routines. 49337 (line 1766) 49338* __satfractunsqisq: Fixed-point fractional library routines. 49339 (line 1762) 49340* __satfractunsqita: Fixed-point fractional library routines. 49341 (line 1768) 49342* __satfractunsqiuda: Fixed-point fractional library routines. 49343 (line 1782) 49344* __satfractunsqiudq: Fixed-point fractional library routines. 49345 (line 1776) 49346* __satfractunsqiuha: Fixed-point fractional library routines. 49347 (line 1778) 49348* __satfractunsqiuhq: Fixed-point fractional library routines. 49349 (line 1772) 49350* __satfractunsqiuqq: Fixed-point fractional library routines. 49351 (line 1770) 49352* __satfractunsqiusa: Fixed-point fractional library routines. 49353 (line 1780) 49354* __satfractunsqiusq: Fixed-point fractional library routines. 49355 (line 1774) 49356* __satfractunsqiuta: Fixed-point fractional library routines. 49357 (line 1784) 49358* __satfractunssida: Fixed-point fractional library routines. 49359 (line 1818) 49360* __satfractunssidq: Fixed-point fractional library routines. 49361 (line 1815) 49362* __satfractunssiha: Fixed-point fractional library routines. 49363 (line 1816) 49364* __satfractunssihq: Fixed-point fractional library routines. 49365 (line 1813) 49366* __satfractunssiqq: Fixed-point fractional library routines. 49367 (line 1812) 49368* __satfractunssisa: Fixed-point fractional library routines. 49369 (line 1817) 49370* __satfractunssisq: Fixed-point fractional library routines. 49371 (line 1814) 49372* __satfractunssita: Fixed-point fractional library routines. 49373 (line 1819) 49374* __satfractunssiuda: Fixed-point fractional library routines. 49375 (line 1830) 49376* __satfractunssiudq: Fixed-point fractional library routines. 49377 (line 1825) 49378* __satfractunssiuha: Fixed-point fractional library routines. 49379 (line 1827) 49380* __satfractunssiuhq: Fixed-point fractional library routines. 49381 (line 1822) 49382* __satfractunssiuqq: Fixed-point fractional library routines. 49383 (line 1820) 49384* __satfractunssiusa: Fixed-point fractional library routines. 49385 (line 1829) 49386* __satfractunssiusq: Fixed-point fractional library routines. 49387 (line 1823) 49388* __satfractunssiuta: Fixed-point fractional library routines. 49389 (line 1832) 49390* __satfractunstida: Fixed-point fractional library routines. 49391 (line 1870) 49392* __satfractunstidq: Fixed-point fractional library routines. 49393 (line 1865) 49394* __satfractunstiha: Fixed-point fractional library routines. 49395 (line 1867) 49396* __satfractunstihq: Fixed-point fractional library routines. 49397 (line 1862) 49398* __satfractunstiqq: Fixed-point fractional library routines. 49399 (line 1860) 49400* __satfractunstisa: Fixed-point fractional library routines. 49401 (line 1869) 49402* __satfractunstisq: Fixed-point fractional library routines. 49403 (line 1863) 49404* __satfractunstita: Fixed-point fractional library routines. 49405 (line 1872) 49406* __satfractunstiuda: Fixed-point fractional library routines. 49407 (line 1886) 49408* __satfractunstiudq: Fixed-point fractional library routines. 49409 (line 1880) 49410* __satfractunstiuha: Fixed-point fractional library routines. 49411 (line 1882) 49412* __satfractunstiuhq: Fixed-point fractional library routines. 49413 (line 1876) 49414* __satfractunstiuqq: Fixed-point fractional library routines. 49415 (line 1874) 49416* __satfractunstiusa: Fixed-point fractional library routines. 49417 (line 1884) 49418* __satfractunstiusq: Fixed-point fractional library routines. 49419 (line 1878) 49420* __satfractunstiuta: Fixed-point fractional library routines. 49421 (line 1888) 49422* __satfractuqqda: Fixed-point fractional library routines. 49423 (line 1207) 49424* __satfractuqqdq: Fixed-point fractional library routines. 49425 (line 1202) 49426* __satfractuqqha: Fixed-point fractional library routines. 49427 (line 1204) 49428* __satfractuqqhq: Fixed-point fractional library routines. 49429 (line 1199) 49430* __satfractuqqqq: Fixed-point fractional library routines. 49431 (line 1197) 49432* __satfractuqqsa: Fixed-point fractional library routines. 49433 (line 1206) 49434* __satfractuqqsq: Fixed-point fractional library routines. 49435 (line 1200) 49436* __satfractuqqta: Fixed-point fractional library routines. 49437 (line 1209) 49438* __satfractuqquda: Fixed-point fractional library routines. 49439 (line 1221) 49440* __satfractuqqudq2: Fixed-point fractional library routines. 49441 (line 1215) 49442* __satfractuqquha: Fixed-point fractional library routines. 49443 (line 1217) 49444* __satfractuqquhq2: Fixed-point fractional library routines. 49445 (line 1211) 49446* __satfractuqqusa: Fixed-point fractional library routines. 49447 (line 1219) 49448* __satfractuqqusq2: Fixed-point fractional library routines. 49449 (line 1213) 49450* __satfractuqquta: Fixed-point fractional library routines. 49451 (line 1223) 49452* __satfractusada: Fixed-point fractional library routines. 49453 (line 1334) 49454* __satfractusadq: Fixed-point fractional library routines. 49455 (line 1331) 49456* __satfractusaha: Fixed-point fractional library routines. 49457 (line 1332) 49458* __satfractusahq: Fixed-point fractional library routines. 49459 (line 1329) 49460* __satfractusaqq: Fixed-point fractional library routines. 49461 (line 1328) 49462* __satfractusasa: Fixed-point fractional library routines. 49463 (line 1333) 49464* __satfractusasq: Fixed-point fractional library routines. 49465 (line 1330) 49466* __satfractusata: Fixed-point fractional library routines. 49467 (line 1335) 49468* __satfractusauda2: Fixed-point fractional library routines. 49469 (line 1345) 49470* __satfractusaudq: Fixed-point fractional library routines. 49471 (line 1341) 49472* __satfractusauha2: Fixed-point fractional library routines. 49473 (line 1343) 49474* __satfractusauhq: Fixed-point fractional library routines. 49475 (line 1338) 49476* __satfractusauqq: Fixed-point fractional library routines. 49477 (line 1336) 49478* __satfractusausq: Fixed-point fractional library routines. 49479 (line 1339) 49480* __satfractusauta2: Fixed-point fractional library routines. 49481 (line 1347) 49482* __satfractusqda: Fixed-point fractional library routines. 49483 (line 1255) 49484* __satfractusqdq: Fixed-point fractional library routines. 49485 (line 1250) 49486* __satfractusqha: Fixed-point fractional library routines. 49487 (line 1252) 49488* __satfractusqhq: Fixed-point fractional library routines. 49489 (line 1248) 49490* __satfractusqqq: Fixed-point fractional library routines. 49491 (line 1246) 49492* __satfractusqsa: Fixed-point fractional library routines. 49493 (line 1254) 49494* __satfractusqsq: Fixed-point fractional library routines. 49495 (line 1249) 49496* __satfractusqta: Fixed-point fractional library routines. 49497 (line 1256) 49498* __satfractusquda: Fixed-point fractional library routines. 49499 (line 1268) 49500* __satfractusqudq2: Fixed-point fractional library routines. 49501 (line 1262) 49502* __satfractusquha: Fixed-point fractional library routines. 49503 (line 1264) 49504* __satfractusquhq2: Fixed-point fractional library routines. 49505 (line 1260) 49506* __satfractusquqq2: Fixed-point fractional library routines. 49507 (line 1258) 49508* __satfractusqusa: Fixed-point fractional library routines. 49509 (line 1266) 49510* __satfractusquta: Fixed-point fractional library routines. 49511 (line 1270) 49512* __satfractutada: Fixed-point fractional library routines. 49513 (line 1385) 49514* __satfractutadq: Fixed-point fractional library routines. 49515 (line 1380) 49516* __satfractutaha: Fixed-point fractional library routines. 49517 (line 1382) 49518* __satfractutahq: Fixed-point fractional library routines. 49519 (line 1377) 49520* __satfractutaqq: Fixed-point fractional library routines. 49521 (line 1375) 49522* __satfractutasa: Fixed-point fractional library routines. 49523 (line 1384) 49524* __satfractutasq: Fixed-point fractional library routines. 49525 (line 1378) 49526* __satfractutata: Fixed-point fractional library routines. 49527 (line 1387) 49528* __satfractutauda2: Fixed-point fractional library routines. 49529 (line 1401) 49530* __satfractutaudq: Fixed-point fractional library routines. 49531 (line 1395) 49532* __satfractutauha2: Fixed-point fractional library routines. 49533 (line 1397) 49534* __satfractutauhq: Fixed-point fractional library routines. 49535 (line 1391) 49536* __satfractutauqq: Fixed-point fractional library routines. 49537 (line 1389) 49538* __satfractutausa2: Fixed-point fractional library routines. 49539 (line 1399) 49540* __satfractutausq: Fixed-point fractional library routines. 49541 (line 1393) 49542* __splitstack_find: Miscellaneous routines. 49543 (line 15) 49544* __ssaddda3: Fixed-point fractional library routines. 49545 (line 74) 49546* __ssadddq3: Fixed-point fractional library routines. 49547 (line 69) 49548* __ssaddha3: Fixed-point fractional library routines. 49549 (line 71) 49550* __ssaddhq3: Fixed-point fractional library routines. 49551 (line 67) 49552* __ssaddqq3: Fixed-point fractional library routines. 49553 (line 65) 49554* __ssaddsa3: Fixed-point fractional library routines. 49555 (line 73) 49556* __ssaddsq3: Fixed-point fractional library routines. 49557 (line 68) 49558* __ssaddta3: Fixed-point fractional library routines. 49559 (line 75) 49560* __ssashlda3: Fixed-point fractional library routines. 49561 (line 409) 49562* __ssashldq3: Fixed-point fractional library routines. 49563 (line 405) 49564* __ssashlha3: Fixed-point fractional library routines. 49565 (line 407) 49566* __ssashlhq3: Fixed-point fractional library routines. 49567 (line 403) 49568* __ssashlsa3: Fixed-point fractional library routines. 49569 (line 408) 49570* __ssashlsq3: Fixed-point fractional library routines. 49571 (line 404) 49572* __ssashlta3: Fixed-point fractional library routines. 49573 (line 410) 49574* __ssdivda3: Fixed-point fractional library routines. 49575 (line 268) 49576* __ssdivdq3: Fixed-point fractional library routines. 49577 (line 263) 49578* __ssdivha3: Fixed-point fractional library routines. 49579 (line 265) 49580* __ssdivhq3: Fixed-point fractional library routines. 49581 (line 261) 49582* __ssdivqq3: Fixed-point fractional library routines. 49583 (line 259) 49584* __ssdivsa3: Fixed-point fractional library routines. 49585 (line 267) 49586* __ssdivsq3: Fixed-point fractional library routines. 49587 (line 262) 49588* __ssdivta3: Fixed-point fractional library routines. 49589 (line 269) 49590* __ssmulda3: Fixed-point fractional library routines. 49591 (line 200) 49592* __ssmuldq3: Fixed-point fractional library routines. 49593 (line 195) 49594* __ssmulha3: Fixed-point fractional library routines. 49595 (line 197) 49596* __ssmulhq3: Fixed-point fractional library routines. 49597 (line 193) 49598* __ssmulqq3: Fixed-point fractional library routines. 49599 (line 191) 49600* __ssmulsa3: Fixed-point fractional library routines. 49601 (line 199) 49602* __ssmulsq3: Fixed-point fractional library routines. 49603 (line 194) 49604* __ssmulta3: Fixed-point fractional library routines. 49605 (line 201) 49606* __ssnegda2: Fixed-point fractional library routines. 49607 (line 323) 49608* __ssnegdq2: Fixed-point fractional library routines. 49609 (line 320) 49610* __ssnegha2: Fixed-point fractional library routines. 49611 (line 321) 49612* __ssneghq2: Fixed-point fractional library routines. 49613 (line 318) 49614* __ssnegqq2: Fixed-point fractional library routines. 49615 (line 317) 49616* __ssnegsa2: Fixed-point fractional library routines. 49617 (line 322) 49618* __ssnegsq2: Fixed-point fractional library routines. 49619 (line 319) 49620* __ssnegta2: Fixed-point fractional library routines. 49621 (line 324) 49622* __sssubda3: Fixed-point fractional library routines. 49623 (line 136) 49624* __sssubdq3: Fixed-point fractional library routines. 49625 (line 131) 49626* __sssubha3: Fixed-point fractional library routines. 49627 (line 133) 49628* __sssubhq3: Fixed-point fractional library routines. 49629 (line 129) 49630* __sssubqq3: Fixed-point fractional library routines. 49631 (line 127) 49632* __sssubsa3: Fixed-point fractional library routines. 49633 (line 135) 49634* __sssubsq3: Fixed-point fractional library routines. 49635 (line 130) 49636* __sssubta3: Fixed-point fractional library routines. 49637 (line 137) 49638* __subda3: Fixed-point fractional library routines. 49639 (line 114) 49640* __subdf3: Soft float library routines. 49641 (line 30) 49642* __subdq3: Fixed-point fractional library routines. 49643 (line 101) 49644* __subha3: Fixed-point fractional library routines. 49645 (line 111) 49646* __subhq3: Fixed-point fractional library routines. 49647 (line 99) 49648* __subqq3: Fixed-point fractional library routines. 49649 (line 97) 49650* __subsa3: Fixed-point fractional library routines. 49651 (line 113) 49652* __subsf3: Soft float library routines. 49653 (line 29) 49654* __subsq3: Fixed-point fractional library routines. 49655 (line 100) 49656* __subta3: Fixed-point fractional library routines. 49657 (line 115) 49658* __subtf3: Soft float library routines. 49659 (line 31) 49660* __subuda3: Fixed-point fractional library routines. 49661 (line 121) 49662* __subudq3: Fixed-point fractional library routines. 49663 (line 109) 49664* __subuha3: Fixed-point fractional library routines. 49665 (line 117) 49666* __subuhq3: Fixed-point fractional library routines. 49667 (line 105) 49668* __subuqq3: Fixed-point fractional library routines. 49669 (line 103) 49670* __subusa3: Fixed-point fractional library routines. 49671 (line 119) 49672* __subusq3: Fixed-point fractional library routines. 49673 (line 107) 49674* __subuta3: Fixed-point fractional library routines. 49675 (line 123) 49676* __subvdi3: Integer library routines. 49677 (line 122) 49678* __subvsi3: Integer library routines. 49679 (line 121) 49680* __subxf3: Soft float library routines. 49681 (line 33) 49682* __truncdfsf2: Soft float library routines. 49683 (line 75) 49684* __trunctfdf2: Soft float library routines. 49685 (line 72) 49686* __trunctfsf2: Soft float library routines. 49687 (line 74) 49688* __truncxfdf2: Soft float library routines. 49689 (line 71) 49690* __truncxfsf2: Soft float library routines. 49691 (line 73) 49692* __ucmpdi2: Integer library routines. 49693 (line 92) 49694* __ucmpti2: Integer library routines. 49695 (line 93) 49696* __udivdi3: Integer library routines. 49697 (line 52) 49698* __udivmoddi4: Integer library routines. 49699 (line 59) 49700* __udivmodti4: Integer library routines. 49701 (line 61) 49702* __udivsi3: Integer library routines. 49703 (line 50) 49704* __udivti3: Integer library routines. 49705 (line 54) 49706* __udivuda3: Fixed-point fractional library routines. 49707 (line 252) 49708* __udivudq3: Fixed-point fractional library routines. 49709 (line 246) 49710* __udivuha3: Fixed-point fractional library routines. 49711 (line 248) 49712* __udivuhq3: Fixed-point fractional library routines. 49713 (line 242) 49714* __udivuqq3: Fixed-point fractional library routines. 49715 (line 240) 49716* __udivusa3: Fixed-point fractional library routines. 49717 (line 250) 49718* __udivusq3: Fixed-point fractional library routines. 49719 (line 244) 49720* __udivuta3: Fixed-point fractional library routines. 49721 (line 254) 49722* __umoddi3: Integer library routines. 49723 (line 69) 49724* __umodsi3: Integer library routines. 49725 (line 67) 49726* __umodti3: Integer library routines. 49727 (line 71) 49728* __unorddf2: Soft float library routines. 49729 (line 172) 49730* __unordsf2: Soft float library routines. 49731 (line 171) 49732* __unordtf2: Soft float library routines. 49733 (line 173) 49734* __usadduda3: Fixed-point fractional library routines. 49735 (line 91) 49736* __usaddudq3: Fixed-point fractional library routines. 49737 (line 85) 49738* __usadduha3: Fixed-point fractional library routines. 49739 (line 87) 49740* __usadduhq3: Fixed-point fractional library routines. 49741 (line 81) 49742* __usadduqq3: Fixed-point fractional library routines. 49743 (line 79) 49744* __usaddusa3: Fixed-point fractional library routines. 49745 (line 89) 49746* __usaddusq3: Fixed-point fractional library routines. 49747 (line 83) 49748* __usadduta3: Fixed-point fractional library routines. 49749 (line 93) 49750* __usashluda3: Fixed-point fractional library routines. 49751 (line 427) 49752* __usashludq3: Fixed-point fractional library routines. 49753 (line 421) 49754* __usashluha3: Fixed-point fractional library routines. 49755 (line 423) 49756* __usashluhq3: Fixed-point fractional library routines. 49757 (line 417) 49758* __usashluqq3: Fixed-point fractional library routines. 49759 (line 415) 49760* __usashlusa3: Fixed-point fractional library routines. 49761 (line 425) 49762* __usashlusq3: Fixed-point fractional library routines. 49763 (line 419) 49764* __usashluta3: Fixed-point fractional library routines. 49765 (line 429) 49766* __usdivuda3: Fixed-point fractional library routines. 49767 (line 286) 49768* __usdivudq3: Fixed-point fractional library routines. 49769 (line 280) 49770* __usdivuha3: Fixed-point fractional library routines. 49771 (line 282) 49772* __usdivuhq3: Fixed-point fractional library routines. 49773 (line 276) 49774* __usdivuqq3: Fixed-point fractional library routines. 49775 (line 274) 49776* __usdivusa3: Fixed-point fractional library routines. 49777 (line 284) 49778* __usdivusq3: Fixed-point fractional library routines. 49779 (line 278) 49780* __usdivuta3: Fixed-point fractional library routines. 49781 (line 288) 49782* __usmuluda3: Fixed-point fractional library routines. 49783 (line 218) 49784* __usmuludq3: Fixed-point fractional library routines. 49785 (line 212) 49786* __usmuluha3: Fixed-point fractional library routines. 49787 (line 214) 49788* __usmuluhq3: Fixed-point fractional library routines. 49789 (line 208) 49790* __usmuluqq3: Fixed-point fractional library routines. 49791 (line 206) 49792* __usmulusa3: Fixed-point fractional library routines. 49793 (line 216) 49794* __usmulusq3: Fixed-point fractional library routines. 49795 (line 210) 49796* __usmuluta3: Fixed-point fractional library routines. 49797 (line 220) 49798* __usneguda2: Fixed-point fractional library routines. 49799 (line 337) 49800* __usnegudq2: Fixed-point fractional library routines. 49801 (line 332) 49802* __usneguha2: Fixed-point fractional library routines. 49803 (line 334) 49804* __usneguhq2: Fixed-point fractional library routines. 49805 (line 329) 49806* __usneguqq2: Fixed-point fractional library routines. 49807 (line 327) 49808* __usnegusa2: Fixed-point fractional library routines. 49809 (line 336) 49810* __usnegusq2: Fixed-point fractional library routines. 49811 (line 330) 49812* __usneguta2: Fixed-point fractional library routines. 49813 (line 339) 49814* __ussubuda3: Fixed-point fractional library routines. 49815 (line 154) 49816* __ussubudq3: Fixed-point fractional library routines. 49817 (line 148) 49818* __ussubuha3: Fixed-point fractional library routines. 49819 (line 150) 49820* __ussubuhq3: Fixed-point fractional library routines. 49821 (line 144) 49822* __ussubuqq3: Fixed-point fractional library routines. 49823 (line 142) 49824* __ussubusa3: Fixed-point fractional library routines. 49825 (line 152) 49826* __ussubusq3: Fixed-point fractional library routines. 49827 (line 146) 49828* __ussubuta3: Fixed-point fractional library routines. 49829 (line 156) 49830* abort: Portability. (line 20) 49831* abs: Arithmetic. (line 200) 49832* abs and attributes: Expressions. (line 83) 49833* absence_set: Processor pipeline description. 49834 (line 223) 49835* absM2 instruction pattern: Standard Names. (line 761) 49836* absolute value: Arithmetic. (line 200) 49837* ABS_EXPR: Unary and Binary Expressions. 49838 (line 6) 49839* access to operands: Accessors. (line 6) 49840* access to special operands: Special Accessors. (line 6) 49841* accessors: Accessors. (line 6) 49842* ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 48) 49843* ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 140) 49844* ACCUM_TYPE_SIZE: Type Layout. (line 87) 49845* acosM2 instruction pattern: Standard Names. (line 848) 49846* ADA_LONG_TYPE_SIZE: Type Layout. (line 25) 49847* Adding a new GIMPLE statement code: Adding a new GIMPLE statement code. 49848 (line 6) 49849* ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 14) 49850* addM3 instruction pattern: Standard Names. (line 410) 49851* addMODEcc instruction pattern: Standard Names. (line 1425) 49852* addptrM3 instruction pattern: Standard Names. (line 443) 49853* address constraints: Simple Constraints. (line 162) 49854* addressing modes: Addressing Modes. (line 6) 49855* address_operand: Machine-Independent Predicates. 49856 (line 62) 49857* address_operand <1>: Simple Constraints. (line 166) 49858* addr_diff_vec: Side Effects. (line 314) 49859* addr_diff_vec, length of: Insn Lengths. (line 26) 49860* ADDR_EXPR: Storage References. (line 6) 49861* addr_vec: Side Effects. (line 309) 49862* addr_vec, length of: Insn Lengths. (line 26) 49863* addvM4 instruction pattern: Standard Names. (line 426) 49864* ADJUST_FIELD_ALIGN: Storage Layout. (line 212) 49865* ADJUST_INSN_LENGTH: Insn Lengths. (line 41) 49866* ADJUST_REG_ALLOC_ORDER: Allocation Order. (line 22) 49867* aggregates as return values: Aggregate Return. (line 6) 49868* alias: Alias analysis. (line 6) 49869* allocate_stack instruction pattern: Standard Names. (line 1778) 49870* ALL_REGS: Register Classes. (line 17) 49871* alternate entry points: Insns. (line 146) 49872* anchored addresses: Anchored Addresses. (line 6) 49873* and: Arithmetic. (line 158) 49874* and and attributes: Expressions. (line 50) 49875* and, canonicalization of: Insn Canonicalizations. 49876 (line 67) 49877* andM3 instruction pattern: Standard Names. (line 416) 49878* ANNOTATE_EXPR: Unary and Binary Expressions. 49879 (line 6) 49880* annotations: Annotations. (line 6) 49881* APPLY_RESULT_SIZE: Scalar Return. (line 112) 49882* ARGS_GROW_DOWNWARD: Frame Layout. (line 30) 49883* argument passing: Interface. (line 36) 49884* arguments in registers: Register Arguments. (line 6) 49885* arguments on stack: Stack Arguments. (line 6) 49886* ARG_POINTER_CFA_OFFSET: Frame Layout. (line 207) 49887* ARG_POINTER_REGNUM: Frame Registers. (line 40) 49888* ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65) 49889* arg_pointer_rtx: Frame Registers. (line 104) 49890* arithmetic library: Soft float library routines. 49891 (line 6) 49892* arithmetic shift: Arithmetic. (line 173) 49893* arithmetic shift with signed saturation: Arithmetic. (line 173) 49894* arithmetic shift with unsigned saturation: Arithmetic. (line 173) 49895* arithmetic, in RTL: Arithmetic. (line 6) 49896* ARITHMETIC_TYPE_P: Types for C++. (line 59) 49897* array: Types. (line 6) 49898* ARRAY_RANGE_REF: Storage References. (line 6) 49899* ARRAY_REF: Storage References. (line 6) 49900* ARRAY_TYPE: Types. (line 6) 49901* ashift: Arithmetic. (line 173) 49902* ashift and attributes: Expressions. (line 83) 49903* ashiftrt: Arithmetic. (line 190) 49904* ashiftrt and attributes: Expressions. (line 83) 49905* ashlM3 instruction pattern: Standard Names. (line 730) 49906* ashrM3 instruction pattern: Standard Names. (line 742) 49907* asinM2 instruction pattern: Standard Names. (line 842) 49908* ASM_APP_OFF: File Framework. (line 76) 49909* ASM_APP_ON: File Framework. (line 69) 49910* ASM_COMMENT_START: File Framework. (line 64) 49911* ASM_DECLARE_COLD_FUNCTION_NAME: Label Output. (line 136) 49912* ASM_DECLARE_COLD_FUNCTION_SIZE: Label Output. (line 151) 49913* ASM_DECLARE_FUNCTION_NAME: Label Output. (line 108) 49914* ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 123) 49915* ASM_DECLARE_OBJECT_NAME: Label Output. (line 164) 49916* ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 192) 49917* ASM_FINAL_SPEC: Driver. (line 81) 49918* ASM_FINISH_DECLARE_OBJECT: Label Output. (line 200) 49919* ASM_FORMAT_PRIVATE_NAME: Label Output. (line 426) 49920* asm_fprintf: Instruction Output. (line 150) 49921* ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 160) 49922* ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 410) 49923* asm_input: Side Effects. (line 296) 49924* asm_input and /v: Flags. (line 65) 49925* ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 80) 49926* asm_noperands: Insns. (line 327) 49927* ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 78) 49928* asm_operands and /v: Flags. (line 65) 49929* asm_operands, RTL sharing: Sharing. (line 48) 49930* asm_operands, usage: Assembler. (line 6) 49931* ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 8) 49932* ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 25) 49933* ASM_OUTPUT_ALIGN: Alignment Output. (line 85) 49934* ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 45) 49935* ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 29) 49936* ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 36) 49937* ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 89) 49938* ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 82) 49939* ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 90) 49940* ASM_OUTPUT_ASCII: Data Output. (line 54) 49941* ASM_OUTPUT_CASE_END: Dispatch Tables. (line 50) 49942* ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 37) 49943* ASM_OUTPUT_COMMON: Uninitialized Data. (line 9) 49944* ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 398) 49945* ASM_OUTPUT_DEF: Label Output. (line 447) 49946* ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 454) 49947* ASM_OUTPUT_DWARF_DATAREL: DWARF. (line 110) 49948* ASM_OUTPUT_DWARF_DELTA: DWARF. (line 89) 49949* ASM_OUTPUT_DWARF_OFFSET: DWARF. (line 98) 49950* ASM_OUTPUT_DWARF_PCREL: DWARF. (line 105) 49951* ASM_OUTPUT_DWARF_TABLE_REF: DWARF. (line 115) 49952* ASM_OUTPUT_DWARF_VMS_DELTA: DWARF. (line 93) 49953* ASM_OUTPUT_EXTERNAL: Label Output. (line 327) 49954* ASM_OUTPUT_FDESC: Data Output. (line 63) 49955* ASM_OUTPUT_FUNCTION_LABEL: Label Output. (line 16) 49956* ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 27) 49957* ASM_OUTPUT_LABEL: Label Output. (line 8) 49958* ASM_OUTPUT_LABELREF: Label Output. (line 349) 49959* ASM_OUTPUT_LABEL_REF: Label Output. (line 371) 49960* ASM_OUTPUT_LOCAL: Uninitialized Data. (line 69) 49961* ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 94) 49962* ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 51) 49963* ASM_OUTPUT_OPCODE: Instruction Output. (line 35) 49964* ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 112) 49965* ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 76) 49966* ASM_OUTPUT_REG_POP: Instruction Output. (line 206) 49967* ASM_OUTPUT_REG_PUSH: Instruction Output. (line 201) 49968* ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 45) 49969* ASM_OUTPUT_SKIP: Alignment Output. (line 72) 49970* ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 83) 49971* ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 87) 49972* ASM_OUTPUT_SYMBOL_REF: Label Output. (line 364) 49973* ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 98) 49974* ASM_OUTPUT_WEAKREF: Label Output. (line 259) 49975* ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 473) 49976* ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 66) 49977* ASM_SPEC: Driver. (line 73) 49978* ASM_STABD_OP: DBX Options. (line 34) 49979* ASM_STABN_OP: DBX Options. (line 41) 49980* ASM_STABS_OP: DBX Options. (line 28) 49981* ASM_WEAKEN_DECL: Label Output. (line 251) 49982* ASM_WEAKEN_LABEL: Label Output. (line 238) 49983* assembler format: File Framework. (line 6) 49984* assembler instructions in RTL: Assembler. (line 6) 49985* ASSEMBLER_DIALECT: Instruction Output. (line 172) 49986* assemble_name: Label Output. (line 8) 49987* assemble_name_raw: Label Output. (line 27) 49988* assigning attribute values to insns: Tagging Insns. (line 6) 49989* ASSUME_EXTENDED_UNWIND_CONTEXT: Frame Registers. (line 163) 49990* asterisk in template: Output Statement. (line 29) 49991* AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 88) 49992* atan2M3 instruction pattern: Standard Names. (line 943) 49993* atanM2 instruction pattern: Standard Names. (line 854) 49994* atomic: GTY Options. (line 197) 49995* atomic_addMODE instruction pattern: Standard Names. (line 2188) 49996* atomic_add_fetchMODE instruction pattern: Standard Names. (line 2217) 49997* atomic_andMODE instruction pattern: Standard Names. (line 2188) 49998* atomic_and_fetchMODE instruction pattern: Standard Names. (line 2217) 49999* atomic_bit_test_and_complementMODE instruction pattern: Standard Names. 50000 (line 2245) 50001* atomic_bit_test_and_resetMODE instruction pattern: Standard Names. 50002 (line 2245) 50003* atomic_bit_test_and_setMODE instruction pattern: Standard Names. 50004 (line 2245) 50005* atomic_compare_and_swapMODE instruction pattern: Standard Names. 50006 (line 2124) 50007* atomic_exchangeMODE instruction pattern: Standard Names. (line 2176) 50008* atomic_fetch_addMODE instruction pattern: Standard Names. (line 2202) 50009* atomic_fetch_andMODE instruction pattern: Standard Names. (line 2202) 50010* atomic_fetch_nandMODE instruction pattern: Standard Names. (line 2202) 50011* atomic_fetch_orMODE instruction pattern: Standard Names. (line 2202) 50012* atomic_fetch_subMODE instruction pattern: Standard Names. (line 2202) 50013* atomic_fetch_xorMODE instruction pattern: Standard Names. (line 2202) 50014* atomic_loadMODE instruction pattern: Standard Names. (line 2155) 50015* atomic_nandMODE instruction pattern: Standard Names. (line 2188) 50016* atomic_nand_fetchMODE instruction pattern: Standard Names. (line 2217) 50017* atomic_orMODE instruction pattern: Standard Names. (line 2188) 50018* atomic_or_fetchMODE instruction pattern: Standard Names. (line 2217) 50019* atomic_storeMODE instruction pattern: Standard Names. (line 2165) 50020* atomic_subMODE instruction pattern: Standard Names. (line 2188) 50021* atomic_sub_fetchMODE instruction pattern: Standard Names. (line 2217) 50022* atomic_test_and_set instruction pattern: Standard Names. (line 2234) 50023* atomic_xorMODE instruction pattern: Standard Names. (line 2188) 50024* atomic_xor_fetchMODE instruction pattern: Standard Names. (line 2217) 50025* attr: Expressions. (line 163) 50026* attr <1>: Tagging Insns. (line 54) 50027* attribute expressions: Expressions. (line 6) 50028* attribute specifications: Attr Example. (line 6) 50029* attribute specifications example: Attr Example. (line 6) 50030* attributes: Attributes. (line 6) 50031* attributes, defining: Defining Attributes. 50032 (line 6) 50033* attributes, target-specific: Target Attributes. (line 6) 50034* ATTRIBUTE_ALIGNED_VALUE: Storage Layout. (line 194) 50035* attr_flag: Expressions. (line 138) 50036* autoincrement addressing, availability: Portability. (line 20) 50037* autoincrement/decrement addressing: Simple Constraints. (line 30) 50038* automata_option: Processor pipeline description. 50039 (line 304) 50040* automaton based pipeline description: Processor pipeline description. 50041 (line 6) 50042* automaton based pipeline description <1>: Processor pipeline description. 50043 (line 49) 50044* automaton based scheduler: Processor pipeline description. 50045 (line 6) 50046* AVOID_CCMODE_COPIES: Values in Registers. 50047 (line 148) 50048* backslash: Output Template. (line 46) 50049* barrier: Insns. (line 176) 50050* barrier and /f: Flags. (line 135) 50051* barrier and /v: Flags. (line 33) 50052* BASE_REG_CLASS: Register Classes. (line 111) 50053* basic block: Basic Blocks. (line 6) 50054* Basic Statements: Basic Statements. (line 6) 50055* basic-block.h: Control Flow. (line 6) 50056* basic_block: Basic Blocks. (line 6) 50057* BASIC_BLOCK: Basic Blocks. (line 14) 50058* BB_HEAD, BB_END: Maintaining the CFG. 50059 (line 76) 50060* bb_seq: GIMPLE sequences. (line 72) 50061* BIGGEST_ALIGNMENT: Storage Layout. (line 179) 50062* BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 205) 50063* BImode: Machine Modes. (line 22) 50064* BIND_EXPR: Unary and Binary Expressions. 50065 (line 6) 50066* BINFO_TYPE: Classes. (line 6) 50067* bit-fields: Bit-Fields. (line 6) 50068* BITFIELD_NBYTES_LIMITED: Storage Layout. (line 425) 50069* BITS_BIG_ENDIAN: Storage Layout. (line 11) 50070* BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8) 50071* BITS_PER_UNIT: Machine Modes. (line 444) 50072* BITS_PER_WORD: Storage Layout. (line 50) 50073* bitwise complement: Arithmetic. (line 154) 50074* bitwise exclusive-or: Arithmetic. (line 168) 50075* bitwise inclusive-or: Arithmetic. (line 163) 50076* bitwise logical-and: Arithmetic. (line 158) 50077* BIT_AND_EXPR: Unary and Binary Expressions. 50078 (line 6) 50079* BIT_IOR_EXPR: Unary and Binary Expressions. 50080 (line 6) 50081* BIT_NOT_EXPR: Unary and Binary Expressions. 50082 (line 6) 50083* BIT_XOR_EXPR: Unary and Binary Expressions. 50084 (line 6) 50085* BLKmode: Machine Modes. (line 185) 50086* BLKmode, and function return values: Calls. (line 23) 50087* blockage instruction pattern: Standard Names. (line 1978) 50088* Blocks: Blocks. (line 6) 50089* BLOCK_FOR_INSN, gimple_bb: Maintaining the CFG. 50090 (line 28) 50091* BLOCK_REG_PADDING: Register Arguments. (line 246) 50092* BND32mode: Machine Modes. (line 210) 50093* BND64mode: Machine Modes. (line 210) 50094* bool: Misc. (line 1017) 50095* BOOLEAN_TYPE: Types. (line 6) 50096* BOOL_TYPE_SIZE: Type Layout. (line 43) 50097* branch prediction: Profile information. 50098 (line 24) 50099* BRANCH_COST: Costs. (line 104) 50100* break_out_memory_refs: Addressing Modes. (line 134) 50101* BREAK_STMT: Statements for C++. (line 6) 50102* BSS_SECTION_ASM_OP: Sections. (line 67) 50103* bswap: Arithmetic. (line 246) 50104* bswapM2 instruction pattern: Standard Names. (line 750) 50105* btruncM2 instruction pattern: Standard Names. (line 960) 50106* build0: Macros and Functions. 50107 (line 16) 50108* build1: Macros and Functions. 50109 (line 17) 50110* build2: Macros and Functions. 50111 (line 18) 50112* build3: Macros and Functions. 50113 (line 19) 50114* build4: Macros and Functions. 50115 (line 20) 50116* build5: Macros and Functions. 50117 (line 21) 50118* build6: Macros and Functions. 50119 (line 22) 50120* builtin_longjmp instruction pattern: Standard Names. (line 1876) 50121* builtin_setjmp_receiver instruction pattern: Standard Names. 50122 (line 1866) 50123* builtin_setjmp_setup instruction pattern: Standard Names. (line 1855) 50124* BYTES_BIG_ENDIAN: Storage Layout. (line 23) 50125* BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 229) 50126* byte_mode: Machine Modes. (line 462) 50127* C statements for assembler output: Output Statement. (line 6) 50128* cache: GTY Options. (line 127) 50129* call: Flags. (line 230) 50130* call <1>: Side Effects. (line 92) 50131* call instruction pattern: Standard Names. (line 1521) 50132* call usage: Calls. (line 10) 50133* call, in call_insn: Flags. (line 129) 50134* call, in mem: Flags. (line 70) 50135* call-clobbered register: Register Basics. (line 35) 50136* call-clobbered register <1>: Register Basics. (line 46) 50137* call-clobbered register <2>: Register Basics. (line 52) 50138* call-saved register: Register Basics. (line 35) 50139* call-saved register <1>: Register Basics. (line 46) 50140* call-saved register <2>: Register Basics. (line 52) 50141* call-used register: Register Basics. (line 35) 50142* call-used register <1>: Register Basics. (line 46) 50143* call-used register <2>: Register Basics. (line 52) 50144* calling conventions: Stack and Calling. (line 6) 50145* calling functions in RTL: Calls. (line 6) 50146* CALL_EXPR: Unary and Binary Expressions. 50147 (line 6) 50148* call_insn: Insns. (line 95) 50149* call_insn and /c: Flags. (line 129) 50150* call_insn and /f: Flags. (line 135) 50151* call_insn and /i: Flags. (line 120) 50152* call_insn and /j: Flags. (line 175) 50153* call_insn and /s: Flags. (line 38) 50154* call_insn and /s <1>: Flags. (line 162) 50155* call_insn and /u: Flags. (line 28) 50156* call_insn and /u <1>: Flags. (line 115) 50157* call_insn and /u or /i: Flags. (line 125) 50158* call_insn and /v: Flags. (line 33) 50159* CALL_INSN_FUNCTION_USAGE: Insns. (line 101) 50160* call_pop instruction pattern: Standard Names. (line 1549) 50161* CALL_POPS_ARGS: Stack Arguments. (line 138) 50162* CALL_REALLY_USED_REGISTERS: Register Basics. (line 45) 50163* CALL_USED_REGISTERS: Register Basics. (line 34) 50164* call_used_regs: Register Basics. (line 63) 50165* call_value instruction pattern: Standard Names. (line 1541) 50166* call_value_pop instruction pattern: Standard Names. (line 1549) 50167* canadian: Configure Terms. (line 6) 50168* canonicalization of instructions: Insn Canonicalizations. 50169 (line 6) 50170* canonicalize_funcptr_for_compare instruction pattern: Standard Names. 50171 (line 1710) 50172* can_create_pseudo_p: Standard Names. (line 75) 50173* can_fallthru: Basic Blocks. (line 67) 50174* caret: Multi-Alternative. (line 53) 50175* casesi instruction pattern: Standard Names. (line 1642) 50176* CASE_VECTOR_MODE: Misc. (line 26) 50177* CASE_VECTOR_PC_RELATIVE: Misc. (line 39) 50178* CASE_VECTOR_SHORTEN_MODE: Misc. (line 30) 50179* cbranchMODE4 instruction pattern: Standard Names. (line 1510) 50180* cc0: Regs and Memory. (line 329) 50181* cc0 <1>: CC0 Condition Codes. 50182 (line 6) 50183* cc0, RTL sharing: Sharing. (line 30) 50184* cc0_rtx: Regs and Memory. (line 355) 50185* CC1PLUS_SPEC: Driver. (line 63) 50186* CC1_SPEC: Driver. (line 55) 50187* CCmode: Machine Modes. (line 178) 50188* CCmode <1>: MODE_CC Condition Codes. 50189 (line 6) 50190* cc_status: CC0 Condition Codes. 50191 (line 6) 50192* CC_STATUS_MDEP: CC0 Condition Codes. 50193 (line 16) 50194* CC_STATUS_MDEP_INIT: CC0 Condition Codes. 50195 (line 22) 50196* CDImode: Machine Modes. (line 204) 50197* ceilM2 instruction pattern: Standard Names. (line 979) 50198* CEIL_DIV_EXPR: Unary and Binary Expressions. 50199 (line 6) 50200* CEIL_MOD_EXPR: Unary and Binary Expressions. 50201 (line 6) 50202* CFA_FRAME_BASE_OFFSET: Frame Layout. (line 239) 50203* CFG verification: Maintaining the CFG. 50204 (line 116) 50205* CFG, Control Flow Graph: Control Flow. (line 6) 50206* cfghooks.h: Maintaining the CFG. 50207 (line 6) 50208* cgraph_finalize_function: Parsing pass. (line 51) 50209* chain_circular: GTY Options. (line 160) 50210* chain_next: GTY Options. (line 160) 50211* chain_prev: GTY Options. (line 160) 50212* change_address: Standard Names. (line 47) 50213* CHAR_TYPE_SIZE: Type Layout. (line 38) 50214* check_stack instruction pattern: Standard Names. (line 1796) 50215* CHImode: Machine Modes. (line 204) 50216* class definitions, register: Register Classes. (line 6) 50217* class preference constraints: Class Preferences. (line 6) 50218* class, scope: Classes. (line 6) 50219* classes of RTX codes: RTL Classes. (line 6) 50220* CLASSTYPE_DECLARED_CLASS: Classes. (line 6) 50221* CLASSTYPE_HAS_MUTABLE: Classes. (line 82) 50222* CLASSTYPE_NON_POD_P: Classes. (line 87) 50223* CLASS_MAX_NREGS: Register Classes. (line 531) 50224* CLASS_TYPE_P: Types for C++. (line 63) 50225* Cleanups: Cleanups. (line 6) 50226* CLEANUP_DECL: Statements for C++. (line 6) 50227* CLEANUP_EXPR: Statements for C++. (line 6) 50228* CLEANUP_POINT_EXPR: Unary and Binary Expressions. 50229 (line 6) 50230* CLEANUP_STMT: Statements for C++. (line 6) 50231* clear_cache instruction pattern: Standard Names. (line 2314) 50232* CLEAR_INSN_CACHE: Trampolines. (line 117) 50233* CLEAR_RATIO: Costs. (line 225) 50234* clobber: Side Effects. (line 106) 50235* clrsb: Arithmetic. (line 215) 50236* clrsbM2 instruction pattern: Standard Names. (line 1044) 50237* clz: Arithmetic. (line 222) 50238* clzM2 instruction pattern: Standard Names. (line 1060) 50239* CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 326) 50240* cmpmemM instruction pattern: Standard Names. (line 1225) 50241* cmpstrM instruction pattern: Standard Names. (line 1204) 50242* cmpstrnM instruction pattern: Standard Names. (line 1191) 50243* code generation RTL sequences: Expander Definitions. 50244 (line 6) 50245* code iterators in .md files: Code Iterators. (line 6) 50246* codes, RTL expression: RTL Objects. (line 47) 50247* code_label: Insns. (line 125) 50248* CODE_LABEL: Basic Blocks. (line 50) 50249* code_label and /i: Flags. (line 48) 50250* code_label and /v: Flags. (line 33) 50251* CODE_LABEL_NUMBER: Insns. (line 125) 50252* COImode: Machine Modes. (line 204) 50253* COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32) 50254* COLLECT_EXPORT_LIST: Misc. (line 889) 50255* COLLECT_SHARED_FINI_FUNC: Macros for Initialization. 50256 (line 43) 50257* COLLECT_SHARED_INIT_FUNC: Macros for Initialization. 50258 (line 32) 50259* commit_edge_insertions: Maintaining the CFG. 50260 (line 104) 50261* compare: Arithmetic. (line 46) 50262* compare, canonicalization of: Insn Canonicalizations. 50263 (line 36) 50264* COMPARE_MAX_PIECES: Costs. (line 220) 50265* comparison_operator: Machine-Independent Predicates. 50266 (line 110) 50267* compiler passes and files: Passes. (line 6) 50268* complement, bitwise: Arithmetic. (line 154) 50269* COMPLEX_CST: Constant expressions. 50270 (line 6) 50271* COMPLEX_EXPR: Unary and Binary Expressions. 50272 (line 6) 50273* complex_mode: Machine Modes. (line 306) 50274* COMPLEX_TYPE: Types. (line 6) 50275* COMPONENT_REF: Storage References. (line 6) 50276* Compound Expressions: Compound Expressions. 50277 (line 6) 50278* Compound Lvalues: Compound Lvalues. (line 6) 50279* COMPOUND_EXPR: Unary and Binary Expressions. 50280 (line 6) 50281* COMPOUND_LITERAL_EXPR: Unary and Binary Expressions. 50282 (line 6) 50283* COMPOUND_LITERAL_EXPR_DECL: Unary and Binary Expressions. 50284 (line 387) 50285* COMPOUND_LITERAL_EXPR_DECL_EXPR: Unary and Binary Expressions. 50286 (line 387) 50287* computed jump: Edges. (line 127) 50288* computing the length of an insn: Insn Lengths. (line 6) 50289* concat: Regs and Memory. (line 407) 50290* concatn: Regs and Memory. (line 413) 50291* cond: Comparisons. (line 90) 50292* cond and attributes: Expressions. (line 37) 50293* condition code register: Regs and Memory. (line 329) 50294* condition code status: Condition Code. (line 6) 50295* condition codes: Comparisons. (line 20) 50296* conditional execution: Conditional Execution. 50297 (line 6) 50298* Conditional Expressions: Conditional Expressions. 50299 (line 6) 50300* conditions, in patterns: Patterns. (line 43) 50301* cond_addMODE instruction pattern: Standard Names. (line 1432) 50302* cond_andMODE instruction pattern: Standard Names. (line 1432) 50303* cond_exec: Side Effects. (line 254) 50304* COND_EXPR: Unary and Binary Expressions. 50305 (line 6) 50306* cond_iorMODE instruction pattern: Standard Names. (line 1432) 50307* cond_smaxMODE instruction pattern: Standard Names. (line 1432) 50308* cond_sminMODE instruction pattern: Standard Names. (line 1432) 50309* cond_subMODE instruction pattern: Standard Names. (line 1432) 50310* cond_umaxMODE instruction pattern: Standard Names. (line 1432) 50311* cond_uminMODE instruction pattern: Standard Names. (line 1432) 50312* cond_xorMODE instruction pattern: Standard Names. (line 1432) 50313* configuration file: Filesystem. (line 6) 50314* configuration file <1>: Host Misc. (line 6) 50315* configure terms: Configure Terms. (line 6) 50316* CONJ_EXPR: Unary and Binary Expressions. 50317 (line 6) 50318* const: Constants. (line 212) 50319* const0_rtx: Constants. (line 21) 50320* CONST0_RTX: Constants. (line 230) 50321* const1_rtx: Constants. (line 21) 50322* CONST1_RTX: Constants. (line 230) 50323* const2_rtx: Constants. (line 21) 50324* CONST2_RTX: Constants. (line 230) 50325* constant attributes: Constant Attributes. 50326 (line 6) 50327* constant definitions: Constant Definitions. 50328 (line 6) 50329* constants in constraints: Simple Constraints. (line 68) 50330* CONSTANT_ADDRESS_P: Addressing Modes. (line 28) 50331* CONSTANT_P: Addressing Modes. (line 35) 50332* CONSTANT_POOL_ADDRESS_P: Flags. (line 19) 50333* CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 68) 50334* constm1_rtx: Constants. (line 21) 50335* constraint modifier characters: Modifiers. (line 6) 50336* constraint, matching: Simple Constraints. (line 140) 50337* constraints: Constraints. (line 6) 50338* constraints, defining: Define Constraints. (line 6) 50339* constraints, machine specific: Machine Constraints. 50340 (line 6) 50341* constraints, testing: C Constraint Interface. 50342 (line 6) 50343* constraint_num: C Constraint Interface. 50344 (line 30) 50345* constraint_satisfied_p: C Constraint Interface. 50346 (line 42) 50347* CONSTRUCTOR: Unary and Binary Expressions. 50348 (line 6) 50349* constructors, automatic calls: Collect2. (line 15) 50350* constructors, output of: Initialization. (line 6) 50351* CONST_DECL: Declarations. (line 6) 50352* const_double: Constants. (line 37) 50353* const_double, RTL sharing: Sharing. (line 32) 50354* CONST_DOUBLE_LOW: Constants. (line 54) 50355* const_double_operand: Machine-Independent Predicates. 50356 (line 20) 50357* const_fixed: Constants. (line 93) 50358* const_int: Constants. (line 8) 50359* const_int and attribute tests: Expressions. (line 47) 50360* const_int and attributes: Expressions. (line 10) 50361* const_int, RTL sharing: Sharing. (line 23) 50362* const_int_operand: Machine-Independent Predicates. 50363 (line 15) 50364* const_poly_int: Constants. (line 100) 50365* const_poly_int, RTL sharing: Sharing. (line 25) 50366* const_string: Constants. (line 184) 50367* const_string and attributes: Expressions. (line 20) 50368* const_true_rtx: Constants. (line 31) 50369* const_vector: Constants. (line 107) 50370* const_vector, RTL sharing: Sharing. (line 35) 50371* CONST_WIDE_INT: Constants. (line 67) 50372* CONST_WIDE_INT_ELT: Constants. (line 89) 50373* CONST_WIDE_INT_NUNITS: Constants. (line 84) 50374* CONST_WIDE_INT_VEC: Constants. (line 80) 50375* container: Containers. (line 6) 50376* CONTINUE_STMT: Statements for C++. (line 6) 50377* contributors: Contributors. (line 6) 50378* controlling register usage: Register Basics. (line 77) 50379* controlling the compilation driver: Driver. (line 6) 50380* conventions, run-time: Interface. (line 6) 50381* conversions: Conversions. (line 6) 50382* CONVERT_EXPR: Unary and Binary Expressions. 50383 (line 6) 50384* copysignM3 instruction pattern: Standard Names. (line 1024) 50385* copy_rtx: Addressing Modes. (line 189) 50386* copy_rtx_if_shared: Sharing. (line 67) 50387* cosM2 instruction pattern: Standard Names. (line 813) 50388* costs of instructions: Costs. (line 6) 50389* CPLUSPLUS_CPP_SPEC: Driver. (line 50) 50390* CPP_SPEC: Driver. (line 43) 50391* CPSImode: Machine Modes. (line 204) 50392* CP_INTEGRAL_TYPE: Types for C++. (line 55) 50393* cp_namespace_decls: Namespaces. (line 49) 50394* CP_TYPE_CONST_NON_VOLATILE_P: Types for C++. (line 33) 50395* CP_TYPE_CONST_P: Types for C++. (line 24) 50396* cp_type_quals: Types for C++. (line 6) 50397* cp_type_quals <1>: Types for C++. (line 16) 50398* CP_TYPE_RESTRICT_P: Types for C++. (line 30) 50399* CP_TYPE_VOLATILE_P: Types for C++. (line 27) 50400* CQImode: Machine Modes. (line 204) 50401* cross compilation and floating point: Floating Point. (line 6) 50402* CROSSING_JUMP_P: Flags. (line 10) 50403* crtl->args.pops_args: Function Entry. (line 111) 50404* crtl->args.pretend_args_size: Function Entry. (line 117) 50405* crtl->outgoing_args_size: Stack Arguments. (line 48) 50406* CRTSTUFF_T_CFLAGS: Target Fragment. (line 15) 50407* CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 19) 50408* CRT_CALL_STATIC_FUNCTION: Sections. (line 125) 50409* CSImode: Machine Modes. (line 204) 50410* cstoreMODE4 instruction pattern: Standard Names. (line 1471) 50411* CTImode: Machine Modes. (line 204) 50412* ctrapMM4 instruction pattern: Standard Names. (line 1947) 50413* ctz: Arithmetic. (line 230) 50414* ctzM2 instruction pattern: Standard Names. (line 1075) 50415* CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 327) 50416* CUMULATIVE_ARGS: Register Arguments. (line 144) 50417* current_function_is_leaf: Leaf Functions. (line 50) 50418* current_function_uses_only_leaf_regs: Leaf Functions. (line 50) 50419* current_insn_predicate: Conditional Execution. 50420 (line 27) 50421* C_COMMON_OVERRIDE_OPTIONS: Run-time Target. (line 136) 50422* c_register_pragma: Misc. (line 429) 50423* c_register_pragma_with_expansion: Misc. (line 431) 50424* DAmode: Machine Modes. (line 154) 50425* data bypass: Processor pipeline description. 50426 (line 105) 50427* data bypass <1>: Processor pipeline description. 50428 (line 196) 50429* data dependence delays: Processor pipeline description. 50430 (line 6) 50431* Data Dependency Analysis: Dependency analysis. 50432 (line 6) 50433* data structures: Per-Function Data. (line 6) 50434* DATA_ABI_ALIGNMENT: Storage Layout. (line 260) 50435* DATA_ALIGNMENT: Storage Layout. (line 247) 50436* DATA_SECTION_ASM_OP: Sections. (line 52) 50437* DBR_OUTPUT_SEQEND: Instruction Output. (line 133) 50438* dbr_sequence_length: Instruction Output. (line 133) 50439* DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 100) 50440* DBX_CONTIN_CHAR: DBX Options. (line 63) 50441* DBX_CONTIN_LENGTH: DBX Options. (line 53) 50442* DBX_DEBUGGING_INFO: DBX Options. (line 8) 50443* DBX_FUNCTION_FIRST: DBX Options. (line 94) 50444* DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 106) 50445* DBX_NO_XREFS: DBX Options. (line 47) 50446* DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 8) 50447* DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 33) 50448* DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX. 50449 (line 41) 50450* DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 8) 50451* DBX_REGISTER_NUMBER: All Debuggers. (line 8) 50452* DBX_REGPARM_STABS_CODE: DBX Options. (line 84) 50453* DBX_REGPARM_STABS_LETTER: DBX Options. (line 89) 50454* DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 79) 50455* DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 70) 50456* DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 75) 50457* DBX_USE_BINCL: DBX Options. (line 112) 50458* DCmode: Machine Modes. (line 199) 50459* DDmode: Machine Modes. (line 93) 50460* De Morgan's law: Insn Canonicalizations. 50461 (line 67) 50462* dead_or_set_p: define_peephole. (line 65) 50463* DEBUGGER_ARG_OFFSET: All Debuggers. (line 35) 50464* DEBUGGER_AUTO_OFFSET: All Debuggers. (line 27) 50465* debug_expr: Debug Information. (line 22) 50466* DEBUG_EXPR_DECL: Declarations. (line 6) 50467* debug_implicit_ptr: Debug Information. (line 27) 50468* debug_insn: Insns. (line 247) 50469* debug_marker: Debug Information. (line 37) 50470* debug_parameter_ref: Debug Information. (line 34) 50471* DEBUG_SYMS_TEXT: DBX Options. (line 24) 50472* decimal float library: Decimal float library routines. 50473 (line 6) 50474* declaration: Declarations. (line 6) 50475* declarations, RTL: RTL Declarations. (line 6) 50476* DECLARE_LIBRARY_RENAMES: Library Calls. (line 8) 50477* DECL_ALIGN: Declarations. (line 6) 50478* DECL_ANTICIPATED: Functions for C++. (line 42) 50479* DECL_ARGUMENTS: Function Basics. (line 36) 50480* DECL_ARRAY_DELETE_OPERATOR_P: Functions for C++. (line 158) 50481* DECL_ARTIFICIAL: Working with declarations. 50482 (line 24) 50483* DECL_ARTIFICIAL <1>: Function Basics. (line 6) 50484* DECL_ARTIFICIAL <2>: Function Properties. 50485 (line 47) 50486* DECL_ASSEMBLER_NAME: Function Basics. (line 6) 50487* DECL_ASSEMBLER_NAME <1>: Function Basics. (line 19) 50488* DECL_ATTRIBUTES: Attributes. (line 21) 50489* DECL_BASE_CONSTRUCTOR_P: Functions for C++. (line 88) 50490* DECL_COMPLETE_CONSTRUCTOR_P: Functions for C++. (line 84) 50491* DECL_COMPLETE_DESTRUCTOR_P: Functions for C++. (line 98) 50492* DECL_CONSTRUCTOR_P: Functions for C++. (line 77) 50493* DECL_CONST_MEMFUNC_P: Functions for C++. (line 71) 50494* DECL_CONTEXT: Namespaces. (line 31) 50495* DECL_CONV_FN_P: Functions for C++. (line 105) 50496* DECL_COPY_CONSTRUCTOR_P: Functions for C++. (line 92) 50497* DECL_DESTRUCTOR_P: Functions for C++. (line 95) 50498* DECL_EXTERNAL: Declarations. (line 6) 50499* DECL_EXTERNAL <1>: Function Properties. 50500 (line 25) 50501* DECL_EXTERN_C_FUNCTION_P: Functions for C++. (line 46) 50502* DECL_FUNCTION_MEMBER_P: Functions for C++. (line 61) 50503* DECL_FUNCTION_SPECIFIC_OPTIMIZATION: Function Basics. (line 6) 50504* DECL_FUNCTION_SPECIFIC_OPTIMIZATION <1>: Function Properties. 50505 (line 61) 50506* DECL_FUNCTION_SPECIFIC_TARGET: Function Basics. (line 6) 50507* DECL_FUNCTION_SPECIFIC_TARGET <1>: Function Properties. 50508 (line 55) 50509* DECL_GLOBAL_CTOR_P: Functions for C++. (line 108) 50510* DECL_GLOBAL_DTOR_P: Functions for C++. (line 112) 50511* DECL_INITIAL: Declarations. (line 6) 50512* DECL_INITIAL <1>: Function Basics. (line 51) 50513* DECL_LINKONCE_P: Functions for C++. (line 50) 50514* DECL_LOCAL_FUNCTION_P: Functions for C++. (line 38) 50515* DECL_MAIN_P: Functions for C++. (line 34) 50516* DECL_NAME: Working with declarations. 50517 (line 7) 50518* DECL_NAME <1>: Function Basics. (line 6) 50519* DECL_NAME <2>: Function Basics. (line 9) 50520* DECL_NAME <3>: Namespaces. (line 20) 50521* DECL_NAMESPACE_ALIAS: Namespaces. (line 35) 50522* DECL_NAMESPACE_STD_P: Namespaces. (line 45) 50523* DECL_NONCONVERTING_P: Functions for C++. (line 80) 50524* DECL_NONSTATIC_MEMBER_FUNCTION_P: Functions for C++. (line 68) 50525* DECL_NON_THUNK_FUNCTION_P: Functions for C++. (line 138) 50526* DECL_OVERLOADED_OPERATOR_P: Functions for C++. (line 102) 50527* DECL_PURE_P: Function Properties. 50528 (line 40) 50529* DECL_RESULT: Function Basics. (line 41) 50530* DECL_SAVED_TREE: Function Basics. (line 44) 50531* DECL_SIZE: Declarations. (line 6) 50532* DECL_STATIC_FUNCTION_P: Functions for C++. (line 65) 50533* DECL_STMT: Statements for C++. (line 6) 50534* DECL_STMT_DECL: Statements for C++. (line 6) 50535* DECL_THUNK_P: Functions for C++. (line 116) 50536* DECL_VIRTUAL_P: Function Properties. 50537 (line 44) 50538* DECL_VOLATILE_MEMFUNC_P: Functions for C++. (line 74) 50539* decrement_and_branch_until_zero instruction pattern: Standard Names. 50540 (line 1679) 50541* default: GTY Options. (line 90) 50542* default_file_start: File Framework. (line 8) 50543* DEFAULT_GDB_EXTENSIONS: DBX Options. (line 17) 50544* DEFAULT_INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 199) 50545* DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 34) 50546* DEFAULT_SIGNED_CHAR: Type Layout. (line 117) 50547* define_address_constraint: Define Constraints. (line 113) 50548* define_asm_attributes: Tagging Insns. (line 73) 50549* define_attr: Defining Attributes. 50550 (line 6) 50551* define_automaton: Processor pipeline description. 50552 (line 53) 50553* define_bypass: Processor pipeline description. 50554 (line 196) 50555* define_code_attr: Code Iterators. (line 6) 50556* define_code_iterator: Code Iterators. (line 6) 50557* define_cond_exec: Conditional Execution. 50558 (line 13) 50559* define_constants: Constant Definitions. 50560 (line 6) 50561* define_constraint: Define Constraints. (line 45) 50562* define_cpu_unit: Processor pipeline description. 50563 (line 68) 50564* define_c_enum: Constant Definitions. 50565 (line 49) 50566* define_delay: Delay Slots. (line 25) 50567* define_enum: Constant Definitions. 50568 (line 118) 50569* define_enum_attr: Defining Attributes. 50570 (line 83) 50571* define_enum_attr <1>: Constant Definitions. 50572 (line 136) 50573* define_expand: Expander Definitions. 50574 (line 11) 50575* define_insn: Patterns. (line 6) 50576* define_insn example: Example. (line 6) 50577* define_insn_and_split: Insn Splitting. (line 170) 50578* define_insn_reservation: Processor pipeline description. 50579 (line 105) 50580* define_int_attr: Int Iterators. (line 6) 50581* define_int_iterator: Int Iterators. (line 6) 50582* define_memory_constraint: Define Constraints. (line 80) 50583* define_mode_attr: Substitutions. (line 6) 50584* define_mode_iterator: Defining Mode Iterators. 50585 (line 6) 50586* define_peephole: define_peephole. (line 6) 50587* define_peephole2: define_peephole2. (line 6) 50588* define_predicate: Defining Predicates. 50589 (line 6) 50590* define_query_cpu_unit: Processor pipeline description. 50591 (line 90) 50592* define_register_constraint: Define Constraints. (line 26) 50593* define_reservation: Processor pipeline description. 50594 (line 185) 50595* define_special_memory_constraint: Define Constraints. (line 99) 50596* define_special_predicate: Defining Predicates. 50597 (line 6) 50598* define_split: Insn Splitting. (line 32) 50599* define_subst: Define Subst. (line 6) 50600* define_subst <1>: Define Subst Example. 50601 (line 6) 50602* define_subst <2>: Define Subst Pattern Matching. 50603 (line 6) 50604* define_subst <3>: Define Subst Output Template. 50605 (line 6) 50606* define_subst <4>: Define Subst. (line 14) 50607* define_subst <5>: Subst Iterators. (line 6) 50608* define_subst_attr: Subst Iterators. (line 6) 50609* define_subst_attr <1>: Subst Iterators. (line 26) 50610* defining attributes and their values: Defining Attributes. 50611 (line 6) 50612* defining constraints: Define Constraints. (line 6) 50613* defining jump instruction patterns: Jump Patterns. (line 6) 50614* defining looping instruction patterns: Looping Patterns. (line 6) 50615* defining peephole optimizers: Peephole Definitions. 50616 (line 6) 50617* defining predicates: Defining Predicates. 50618 (line 6) 50619* defining RTL sequences for code generation: Expander Definitions. 50620 (line 6) 50621* delay slots, defining: Delay Slots. (line 6) 50622* deletable: GTY Options. (line 134) 50623* DELETE_IF_ORDINARY: Filesystem. (line 79) 50624* Dependent Patterns: Dependent Patterns. (line 6) 50625* desc: GTY Options. (line 90) 50626* destructors, output of: Initialization. (line 6) 50627* deterministic finite state automaton: Processor pipeline description. 50628 (line 6) 50629* deterministic finite state automaton <1>: Processor pipeline description. 50630 (line 304) 50631* DFmode: Machine Modes. (line 76) 50632* digits in constraint: Simple Constraints. (line 128) 50633* DImode: Machine Modes. (line 45) 50634* directory options .md: Including Patterns. (line 47) 50635* DIR_SEPARATOR: Filesystem. (line 18) 50636* DIR_SEPARATOR_2: Filesystem. (line 19) 50637* disabling certain registers: Register Basics. (line 77) 50638* dispatch table: Dispatch Tables. (line 8) 50639* div: Arithmetic. (line 116) 50640* div and attributes: Expressions. (line 83) 50641* division: Arithmetic. (line 116) 50642* division <1>: Arithmetic. (line 130) 50643* division <2>: Arithmetic. (line 136) 50644* divM3 instruction pattern: Standard Names. (line 416) 50645* divmodM4 instruction pattern: Standard Names. (line 710) 50646* dollar sign: Multi-Alternative. (line 57) 50647* DOLLARS_IN_IDENTIFIERS: Misc. (line 474) 50648* doloop_begin instruction pattern: Standard Names. (line 1701) 50649* doloop_end instruction pattern: Standard Names. (line 1689) 50650* DONE: Expander Definitions. 50651 (line 77) 50652* DONT_USE_BUILTIN_SETJMP: Exception Region Output. 50653 (line 78) 50654* DOUBLE_TYPE_SIZE: Type Layout. (line 52) 50655* DO_BODY: Statements for C++. (line 6) 50656* DO_COND: Statements for C++. (line 6) 50657* DO_STMT: Statements for C++. (line 6) 50658* DQmode: Machine Modes. (line 118) 50659* driver: Driver. (line 6) 50660* DRIVER_SELF_SPECS: Driver. (line 8) 50661* dump examples: Dump examples. (line 6) 50662* dump setup: Dump setup. (line 6) 50663* dump types: Dump types. (line 6) 50664* dump verbosity: Dump output verbosity. 50665 (line 6) 50666* DUMPFILE_FORMAT: Filesystem. (line 67) 50667* dump_basic_block: Dump types. (line 29) 50668* dump_generic_expr: Dump types. (line 31) 50669* dump_gimple_stmt: Dump types. (line 33) 50670* dump_printf: Dump types. (line 6) 50671* DWARF2_ASM_LINE_DEBUG_INFO: DWARF. (line 45) 50672* DWARF2_ASM_VIEW_DEBUG_INFO: DWARF. (line 51) 50673* DWARF2_DEBUGGING_INFO: DWARF. (line 8) 50674* DWARF2_FRAME_INFO: DWARF. (line 25) 50675* DWARF2_FRAME_REG_OUT: Frame Registers. (line 149) 50676* DWARF2_UNWIND_INFO: Exception Region Output. 50677 (line 39) 50678* DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 146) 50679* DWARF_CIE_DATA_ALIGNMENT: Exception Region Output. 50680 (line 90) 50681* DWARF_FRAME_REGISTERS: Frame Registers. (line 109) 50682* DWARF_FRAME_REGNUM: Frame Registers. (line 141) 50683* DWARF_LAZY_REGISTER_VALUE: Frame Registers. (line 170) 50684* DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 134) 50685* DWARF_ZERO_REG: Frame Layout. (line 157) 50686* DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 84) 50687* E in constraint: Simple Constraints. (line 87) 50688* earlyclobber operand: Modifiers. (line 25) 50689* edge: Edges. (line 6) 50690* edge in the flow graph: Edges. (line 6) 50691* edge iterators: Edges. (line 15) 50692* edge splitting: Maintaining the CFG. 50693 (line 104) 50694* EDGE_ABNORMAL: Edges. (line 127) 50695* EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 171) 50696* EDGE_ABNORMAL, EDGE_EH: Edges. (line 95) 50697* EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 121) 50698* EDGE_FALLTHRU, force_nonfallthru: Edges. (line 85) 50699* EDOM, implicit usage: Library Calls. (line 59) 50700* EH_FRAME_SECTION_NAME: Exception Region Output. 50701 (line 9) 50702* EH_FRAME_THROUGH_COLLECT2: Exception Region Output. 50703 (line 19) 50704* eh_return instruction pattern: Standard Names. (line 1882) 50705* EH_RETURN_DATA_REGNO: Exception Handling. (line 6) 50706* EH_RETURN_HANDLER_RTX: Exception Handling. (line 38) 50707* EH_RETURN_STACKADJ_RTX: Exception Handling. (line 21) 50708* EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output. 50709 (line 29) 50710* EH_USES: Function Entry. (line 162) 50711* ei_edge: Edges. (line 43) 50712* ei_end_p: Edges. (line 27) 50713* ei_last: Edges. (line 23) 50714* ei_next: Edges. (line 35) 50715* ei_one_before_end_p: Edges. (line 31) 50716* ei_prev: Edges. (line 39) 50717* ei_safe_safe: Edges. (line 47) 50718* ei_start: Edges. (line 19) 50719* ELIMINABLE_REGS: Elimination. (line 34) 50720* ELSE_CLAUSE: Statements for C++. (line 6) 50721* Embedded C: Fixed-point fractional library routines. 50722 (line 6) 50723* Empty Statements: Empty Statements. (line 6) 50724* EMPTY_CLASS_EXPR: Statements for C++. (line 6) 50725* EMPTY_FIELD_BOUNDARY: Storage Layout. (line 338) 50726* Emulated TLS: Emulated TLS. (line 6) 50727* enabled: Disable Insn Alternatives. 50728 (line 6) 50729* ENDFILE_SPEC: Driver. (line 155) 50730* endianness: Portability. (line 20) 50731* ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 10) 50732* entry_value: Debug Information. (line 30) 50733* enum reg_class: Register Classes. (line 70) 50734* ENUMERAL_TYPE: Types. (line 6) 50735* enumerations: Constant Definitions. 50736 (line 49) 50737* epilogue: Function Entry. (line 6) 50738* epilogue instruction pattern: Standard Names. (line 1920) 50739* EPILOGUE_USES: Function Entry. (line 156) 50740* eq: Comparisons. (line 52) 50741* eq and attributes: Expressions. (line 83) 50742* equal: Comparisons. (line 52) 50743* eq_attr: Expressions. (line 104) 50744* EQ_EXPR: Unary and Binary Expressions. 50745 (line 6) 50746* errno, implicit usage: Library Calls. (line 71) 50747* EXACT_DIV_EXPR: Unary and Binary Expressions. 50748 (line 6) 50749* examining SSA_NAMEs: SSA. (line 182) 50750* exception handling: Edges. (line 95) 50751* exception handling <1>: Exception Handling. (line 6) 50752* exception_receiver instruction pattern: Standard Names. (line 1847) 50753* exclamation point: Multi-Alternative. (line 48) 50754* exclusion_set: Processor pipeline description. 50755 (line 223) 50756* exclusive-or, bitwise: Arithmetic. (line 168) 50757* EXIT_EXPR: Unary and Binary Expressions. 50758 (line 6) 50759* EXIT_IGNORE_STACK: Function Entry. (line 144) 50760* exp10M2 instruction pattern: Standard Names. (line 877) 50761* exp2M2 instruction pattern: Standard Names. (line 884) 50762* expander definitions: Expander Definitions. 50763 (line 6) 50764* expm1M2 instruction pattern: Standard Names. (line 867) 50765* expM2 instruction pattern: Standard Names. (line 860) 50766* expression: Expression trees. (line 6) 50767* expression codes: RTL Objects. (line 47) 50768* EXPR_FILENAME: Working with declarations. 50769 (line 14) 50770* EXPR_LINENO: Working with declarations. 50771 (line 20) 50772* expr_list: Insns. (line 568) 50773* EXPR_STMT: Statements for C++. (line 6) 50774* EXPR_STMT_EXPR: Statements for C++. (line 6) 50775* extendMN2 instruction pattern: Standard Names. (line 1283) 50776* extensible constraints: Simple Constraints. (line 171) 50777* extract_last_M instruction pattern: Standard Names. (line 518) 50778* EXTRA_SPECS: Driver. (line 182) 50779* extv instruction pattern: Standard Names. (line 1374) 50780* extvM instruction pattern: Standard Names. (line 1319) 50781* extvmisalignM instruction pattern: Standard Names. (line 1329) 50782* extzv instruction pattern: Standard Names. (line 1392) 50783* extzvM instruction pattern: Standard Names. (line 1343) 50784* extzvmisalignM instruction pattern: Standard Names. (line 1346) 50785* F in constraint: Simple Constraints. (line 92) 50786* FAIL: Expander Definitions. 50787 (line 83) 50788* fall-thru: Edges. (line 68) 50789* FATAL_EXIT_CODE: Host Misc. (line 6) 50790* FDL, GNU Free Documentation License: GNU Free Documentation License. 50791 (line 6) 50792* features, optional, in system conventions: Run-time Target. 50793 (line 59) 50794* ffs: Arithmetic. (line 210) 50795* ffsM2 instruction pattern: Standard Names. (line 1031) 50796* FIELD_DECL: Declarations. (line 6) 50797* files and passes of the compiler: Passes. (line 6) 50798* files, generated: Files. (line 6) 50799* file_end_indicate_exec_stack: File Framework. (line 39) 50800* final_absence_set: Processor pipeline description. 50801 (line 223) 50802* FINAL_PRESCAN_INSN: Instruction Output. (line 60) 50803* final_presence_set: Processor pipeline description. 50804 (line 223) 50805* final_sequence: Instruction Output. (line 144) 50806* FIND_BASE_TERM: Addressing Modes. (line 117) 50807* finite state automaton minimization: Processor pipeline description. 50808 (line 304) 50809* FINI_ARRAY_SECTION_ASM_OP: Sections. (line 113) 50810* FINI_SECTION_ASM_OP: Sections. (line 98) 50811* FIRST_PARM_OFFSET: Frame Layout. (line 59) 50812* FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65) 50813* FIRST_PSEUDO_REGISTER: Register Basics. (line 8) 50814* FIRST_STACK_REG: Stack Registers. (line 26) 50815* FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 50816* fix: Conversions. (line 66) 50817* fixed register: Register Basics. (line 15) 50818* fixed-point fractional library: Fixed-point fractional library routines. 50819 (line 6) 50820* FIXED_CONVERT_EXPR: Unary and Binary Expressions. 50821 (line 6) 50822* FIXED_CST: Constant expressions. 50823 (line 6) 50824* FIXED_POINT_TYPE: Types. (line 6) 50825* FIXED_REGISTERS: Register Basics. (line 14) 50826* fixed_regs: Register Basics. (line 63) 50827* fixed_size_mode: Machine Modes. (line 309) 50828* fixMN2 instruction pattern: Standard Names. (line 1250) 50829* fixunsMN2 instruction pattern: Standard Names. (line 1259) 50830* fixuns_truncMN2 instruction pattern: Standard Names. (line 1274) 50831* fix_truncMN2 instruction pattern: Standard Names. (line 1270) 50832* FIX_TRUNC_EXPR: Unary and Binary Expressions. 50833 (line 6) 50834* flags in RTL expression: Flags. (line 6) 50835* float: Conversions. (line 58) 50836* floating point and cross compilation: Floating Point. (line 6) 50837* floatMN2 instruction pattern: Standard Names. (line 1242) 50838* floatunsMN2 instruction pattern: Standard Names. (line 1246) 50839* FLOAT_EXPR: Unary and Binary Expressions. 50840 (line 6) 50841* float_extend: Conversions. (line 33) 50842* FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 32) 50843* FLOAT_STORE_FLAG_VALUE: Misc. (line 308) 50844* float_truncate: Conversions. (line 53) 50845* FLOAT_TYPE_SIZE: Type Layout. (line 48) 50846* FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 41) 50847* FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory. 50848 (line 234) 50849* floorM2 instruction pattern: Standard Names. (line 951) 50850* FLOOR_DIV_EXPR: Unary and Binary Expressions. 50851 (line 6) 50852* FLOOR_MOD_EXPR: Unary and Binary Expressions. 50853 (line 6) 50854* flow-insensitive alias analysis: Alias analysis. (line 6) 50855* flow-sensitive alias analysis: Alias analysis. (line 6) 50856* fma: Arithmetic. (line 112) 50857* fmaM4 instruction pattern: Standard Names. (line 453) 50858* fmaxM3 instruction pattern: Standard Names. (line 484) 50859* fminM3 instruction pattern: Standard Names. (line 484) 50860* fmodM3 instruction pattern: Standard Names. (line 783) 50861* fmsM4 instruction pattern: Standard Names. (line 460) 50862* fnmaM4 instruction pattern: Standard Names. (line 466) 50863* fnmsM4 instruction pattern: Standard Names. (line 472) 50864* fold_extract_last_M instruction pattern: Standard Names. (line 525) 50865* fold_left_plus_M instruction pattern: Standard Names. (line 533) 50866* FORCE_CODE_SECTION_ALIGN: Sections. (line 149) 50867* force_reg: Standard Names. (line 36) 50868* FOR_BODY: Statements for C++. (line 6) 50869* FOR_COND: Statements for C++. (line 6) 50870* FOR_EXPR: Statements for C++. (line 6) 50871* FOR_INIT_STMT: Statements for C++. (line 6) 50872* FOR_STMT: Statements for C++. (line 6) 50873* for_user: GTY Options. (line 82) 50874* fractional types: Fixed-point fractional library routines. 50875 (line 6) 50876* fractMN2 instruction pattern: Standard Names. (line 1292) 50877* fractunsMN2 instruction pattern: Standard Names. (line 1307) 50878* fract_convert: Conversions. (line 82) 50879* FRACT_TYPE_SIZE: Type Layout. (line 67) 50880* frame layout: Frame Layout. (line 6) 50881* FRAME_ADDR_RTX: Frame Layout. (line 108) 50882* FRAME_GROWS_DOWNWARD: Frame Layout. (line 26) 50883* FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory. 50884 (line 69) 50885* FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 225) 50886* frame_pointer_needed: Function Entry. (line 42) 50887* FRAME_POINTER_REGNUM: Frame Registers. (line 13) 50888* FRAME_POINTER_REGNUM and virtual registers: Regs and Memory. 50889 (line 74) 50890* frame_pointer_rtx: Frame Registers. (line 104) 50891* frame_related: Flags. (line 238) 50892* frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags. 50893 (line 135) 50894* frame_related, in mem: Flags. (line 74) 50895* frame_related, in reg: Flags. (line 102) 50896* frame_related, in symbol_ref: Flags. (line 179) 50897* frequency, count, BB_FREQ_BASE: Profile information. 50898 (line 30) 50899* ftruncM2 instruction pattern: Standard Names. (line 1265) 50900* function: Functions. (line 6) 50901* function <1>: Functions for C++. (line 6) 50902* function call conventions: Interface. (line 6) 50903* function entry and exit: Function Entry. (line 6) 50904* function entry point, alternate function entry point: Edges. 50905 (line 180) 50906* function properties: Function Properties. 50907 (line 6) 50908* function-call insns: Calls. (line 6) 50909* functions, leaf: Leaf Functions. (line 6) 50910* FUNCTION_ARG_REGNO_P: Register Arguments. (line 269) 50911* FUNCTION_BOUNDARY: Storage Layout. (line 176) 50912* FUNCTION_DECL: Functions. (line 6) 50913* FUNCTION_DECL <1>: Functions for C++. (line 6) 50914* FUNCTION_MODE: Misc. (line 363) 50915* FUNCTION_PROFILER: Profiling. (line 8) 50916* FUNCTION_TYPE: Types. (line 6) 50917* FUNCTION_VALUE: Scalar Return. (line 52) 50918* FUNCTION_VALUE_REGNO_P: Scalar Return. (line 78) 50919* fundamental type: Types. (line 6) 50920* G in constraint: Simple Constraints. (line 96) 50921* g in constraint: Simple Constraints. (line 118) 50922* garbage collector, invocation: Invoking the garbage collector. 50923 (line 6) 50924* garbage collector, troubleshooting: Troubleshooting. (line 6) 50925* gather_loadM instruction pattern: Standard Names. (line 232) 50926* GCC and portability: Portability. (line 6) 50927* GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36) 50928* gcov_type: Profile information. 50929 (line 41) 50930* ge: Comparisons. (line 72) 50931* ge and attributes: Expressions. (line 83) 50932* gencodes: RTL passes. (line 18) 50933* general_operand: Machine-Independent Predicates. 50934 (line 104) 50935* GENERAL_REGS: Register Classes. (line 22) 50936* generated files: Files. (line 6) 50937* generating assembler output: Output Statement. (line 6) 50938* generating insns: RTL Template. (line 6) 50939* GENERIC: Parsing pass. (line 6) 50940* GENERIC <1>: GENERIC. (line 6) 50941* generic predicates: Machine-Independent Predicates. 50942 (line 6) 50943* genflags: RTL passes. (line 18) 50944* GEN_ERRNO_RTX: Library Calls. (line 71) 50945* get_attr: Expressions. (line 99) 50946* get_attr_length: Insn Lengths. (line 52) 50947* GET_CLASS_NARROWEST_MODE: Machine Modes. (line 434) 50948* GET_CODE: RTL Objects. (line 47) 50949* get_insns: Insns. (line 34) 50950* get_last_insn: Insns. (line 34) 50951* GET_MODE: Machine Modes. (line 381) 50952* GET_MODE_ALIGNMENT: Machine Modes. (line 421) 50953* GET_MODE_BITSIZE: Machine Modes. (line 405) 50954* GET_MODE_CLASS: Machine Modes. (line 395) 50955* GET_MODE_FBIT: Machine Modes. (line 412) 50956* GET_MODE_IBIT: Machine Modes. (line 408) 50957* GET_MODE_MASK: Machine Modes. (line 416) 50958* GET_MODE_NAME: Machine Modes. (line 392) 50959* GET_MODE_NUNITS: Machine Modes. (line 430) 50960* GET_MODE_SIZE: Machine Modes. (line 402) 50961* GET_MODE_UNIT_SIZE: Machine Modes. (line 424) 50962* GET_MODE_WIDER_MODE: Machine Modes. (line 398) 50963* GET_RTX_CLASS: RTL Classes. (line 6) 50964* GET_RTX_FORMAT: RTL Classes. (line 135) 50965* GET_RTX_LENGTH: RTL Classes. (line 132) 50966* get_thread_pointerMODE instruction pattern: Standard Names. 50967 (line 2285) 50968* geu: Comparisons. (line 72) 50969* geu and attributes: Expressions. (line 83) 50970* GE_EXPR: Unary and Binary Expressions. 50971 (line 6) 50972* GGC: Type Information. (line 6) 50973* ggc_collect: Invoking the garbage collector. 50974 (line 6) 50975* GIMPLE: Parsing pass. (line 13) 50976* GIMPLE <1>: Gimplification pass. 50977 (line 6) 50978* GIMPLE <2>: GIMPLE. (line 6) 50979* gimple: Tuple representation. 50980 (line 14) 50981* GIMPLE API: GIMPLE API. (line 6) 50982* GIMPLE class hierarchy: Class hierarchy of GIMPLE statements. 50983 (line 6) 50984* GIMPLE Exception Handling: GIMPLE Exception Handling. 50985 (line 6) 50986* GIMPLE instruction set: GIMPLE instruction set. 50987 (line 6) 50988* GIMPLE sequences: GIMPLE sequences. (line 6) 50989* GIMPLE statement iterators: Basic Blocks. (line 78) 50990* GIMPLE statement iterators <1>: Maintaining the CFG. 50991 (line 33) 50992* gimple_addresses_taken: Manipulating GIMPLE statements. 50993 (line 89) 50994* GIMPLE_ASM: GIMPLE_ASM. (line 6) 50995* gimple_asm_clobber_op: GIMPLE_ASM. (line 39) 50996* gimple_asm_input_op: GIMPLE_ASM. (line 23) 50997* gimple_asm_nclobbers: GIMPLE_ASM. (line 20) 50998* gimple_asm_ninputs: GIMPLE_ASM. (line 14) 50999* gimple_asm_noutputs: GIMPLE_ASM. (line 17) 51000* gimple_asm_output_op: GIMPLE_ASM. (line 31) 51001* gimple_asm_set_clobber_op: GIMPLE_ASM. (line 43) 51002* gimple_asm_set_input_op: GIMPLE_ASM. (line 27) 51003* gimple_asm_set_output_op: GIMPLE_ASM. (line 35) 51004* gimple_asm_set_volatile: GIMPLE_ASM. (line 54) 51005* gimple_asm_string: GIMPLE_ASM. (line 47) 51006* gimple_asm_volatile_p: GIMPLE_ASM. (line 51) 51007* GIMPLE_ASSIGN: GIMPLE_ASSIGN. (line 6) 51008* gimple_assign_cast_p: Logical Operators. (line 158) 51009* gimple_assign_cast_p <1>: GIMPLE_ASSIGN. (line 104) 51010* gimple_assign_lhs: GIMPLE_ASSIGN. (line 62) 51011* gimple_assign_lhs_ptr: GIMPLE_ASSIGN. (line 65) 51012* gimple_assign_rhs1: GIMPLE_ASSIGN. (line 68) 51013* gimple_assign_rhs1_ptr: GIMPLE_ASSIGN. (line 71) 51014* gimple_assign_rhs2: GIMPLE_ASSIGN. (line 75) 51015* gimple_assign_rhs2_ptr: GIMPLE_ASSIGN. (line 78) 51016* gimple_assign_rhs3: GIMPLE_ASSIGN. (line 82) 51017* gimple_assign_rhs3_ptr: GIMPLE_ASSIGN. (line 85) 51018* gimple_assign_rhs_class: GIMPLE_ASSIGN. (line 56) 51019* gimple_assign_rhs_code: GIMPLE_ASSIGN. (line 52) 51020* gimple_assign_set_lhs: GIMPLE_ASSIGN. (line 89) 51021* gimple_assign_set_rhs1: GIMPLE_ASSIGN. (line 92) 51022* gimple_assign_set_rhs2: GIMPLE_ASSIGN. (line 96) 51023* gimple_assign_set_rhs3: GIMPLE_ASSIGN. (line 100) 51024* gimple_bb: Manipulating GIMPLE statements. 51025 (line 17) 51026* GIMPLE_BIND: GIMPLE_BIND. (line 6) 51027* gimple_bind_add_seq: GIMPLE_BIND. (line 34) 51028* gimple_bind_add_stmt: GIMPLE_BIND. (line 31) 51029* gimple_bind_append_vars: GIMPLE_BIND. (line 18) 51030* gimple_bind_block: GIMPLE_BIND. (line 39) 51031* gimple_bind_body: GIMPLE_BIND. (line 22) 51032* gimple_bind_set_block: GIMPLE_BIND. (line 44) 51033* gimple_bind_set_body: GIMPLE_BIND. (line 26) 51034* gimple_bind_set_vars: GIMPLE_BIND. (line 14) 51035* gimple_bind_vars: GIMPLE_BIND. (line 11) 51036* gimple_block: Manipulating GIMPLE statements. 51037 (line 20) 51038* gimple_build: GIMPLE API. (line 34) 51039* gimple_build <1>: GIMPLE API. (line 36) 51040* gimple_build <2>: GIMPLE API. (line 38) 51041* gimple_build <3>: GIMPLE API. (line 41) 51042* gimple_build <4>: GIMPLE API. (line 44) 51043* gimple_build <5>: GIMPLE API. (line 47) 51044* gimple_build_debug_begin_stmt: GIMPLE_DEBUG. (line 72) 51045* gimple_build_debug_inline_entry: GIMPLE_DEBUG. (line 82) 51046* gimple_build_nop: GIMPLE_NOP. (line 6) 51047* gimple_build_omp_master: GIMPLE_OMP_MASTER. (line 6) 51048* gimple_build_omp_ordered: GIMPLE_OMP_ORDERED. (line 6) 51049* gimple_build_omp_return: GIMPLE_OMP_RETURN. (line 6) 51050* gimple_build_omp_section: GIMPLE_OMP_SECTION. (line 6) 51051* gimple_build_omp_sections_switch: GIMPLE_OMP_SECTIONS. 51052 (line 13) 51053* gimple_build_wce: GIMPLE_WITH_CLEANUP_EXPR. 51054 (line 6) 51055* GIMPLE_CALL: GIMPLE_CALL. (line 6) 51056* gimple_call_arg: GIMPLE_CALL. (line 67) 51057* gimple_call_arg_ptr: GIMPLE_CALL. (line 71) 51058* gimple_call_chain: GIMPLE_CALL. (line 58) 51059* gimple_call_copy_skip_args: GIMPLE_CALL. (line 92) 51060* gimple_call_fn: GIMPLE_CALL. (line 39) 51061* gimple_call_fndecl: GIMPLE_CALL. (line 47) 51062* gimple_call_lhs: GIMPLE_CALL. (line 30) 51063* gimple_call_lhs_ptr: GIMPLE_CALL. (line 33) 51064* gimple_call_noreturn_p: GIMPLE_CALL. (line 89) 51065* gimple_call_num_args: GIMPLE_CALL. (line 64) 51066* gimple_call_return_type: GIMPLE_CALL. (line 55) 51067* gimple_call_set_arg: GIMPLE_CALL. (line 76) 51068* gimple_call_set_chain: GIMPLE_CALL. (line 61) 51069* gimple_call_set_fn: GIMPLE_CALL. (line 43) 51070* gimple_call_set_fndecl: GIMPLE_CALL. (line 52) 51071* gimple_call_set_lhs: GIMPLE_CALL. (line 36) 51072* gimple_call_set_tail: GIMPLE_CALL. (line 81) 51073* gimple_call_tail_p: GIMPLE_CALL. (line 86) 51074* GIMPLE_CATCH: GIMPLE_CATCH. (line 6) 51075* gimple_catch_handler: GIMPLE_CATCH. (line 19) 51076* gimple_catch_set_handler: GIMPLE_CATCH. (line 26) 51077* gimple_catch_set_types: GIMPLE_CATCH. (line 23) 51078* gimple_catch_types: GIMPLE_CATCH. (line 12) 51079* gimple_catch_types_ptr: GIMPLE_CATCH. (line 15) 51080* gimple_code: Manipulating GIMPLE statements. 51081 (line 14) 51082* GIMPLE_COND: GIMPLE_COND. (line 6) 51083* gimple_cond_code: GIMPLE_COND. (line 20) 51084* gimple_cond_false_label: GIMPLE_COND. (line 59) 51085* gimple_cond_lhs: GIMPLE_COND. (line 29) 51086* gimple_cond_make_false: GIMPLE_COND. (line 63) 51087* gimple_cond_make_true: GIMPLE_COND. (line 66) 51088* gimple_cond_rhs: GIMPLE_COND. (line 37) 51089* gimple_cond_set_code: GIMPLE_COND. (line 24) 51090* gimple_cond_set_false_label: GIMPLE_COND. (line 54) 51091* gimple_cond_set_lhs: GIMPLE_COND. (line 33) 51092* gimple_cond_set_rhs: GIMPLE_COND. (line 41) 51093* gimple_cond_set_true_label: GIMPLE_COND. (line 49) 51094* gimple_cond_true_label: GIMPLE_COND. (line 45) 51095* gimple_convert: GIMPLE API. (line 50) 51096* gimple_copy: Manipulating GIMPLE statements. 51097 (line 146) 51098* GIMPLE_DEBUG: GIMPLE_DEBUG. (line 6) 51099* GIMPLE_DEBUG_BEGIN_STMT: GIMPLE_DEBUG. (line 6) 51100* GIMPLE_DEBUG_BIND: GIMPLE_DEBUG. (line 6) 51101* gimple_debug_bind_get_value: GIMPLE_DEBUG. (line 46) 51102* gimple_debug_bind_get_value_ptr: GIMPLE_DEBUG. (line 50) 51103* gimple_debug_bind_get_var: GIMPLE_DEBUG. (line 43) 51104* gimple_debug_bind_has_value_p: GIMPLE_DEBUG. (line 68) 51105* gimple_debug_bind_p: Logical Operators. (line 162) 51106* gimple_debug_bind_reset_value: GIMPLE_DEBUG. (line 64) 51107* gimple_debug_bind_set_value: GIMPLE_DEBUG. (line 59) 51108* gimple_debug_bind_set_var: GIMPLE_DEBUG. (line 55) 51109* GIMPLE_DEBUG_INLINE_ENTRY: GIMPLE_DEBUG. (line 6) 51110* gimple_def_ops: Manipulating GIMPLE statements. 51111 (line 93) 51112* GIMPLE_EH_FILTER: GIMPLE_EH_FILTER. (line 6) 51113* gimple_eh_filter_failure: GIMPLE_EH_FILTER. (line 18) 51114* gimple_eh_filter_set_failure: GIMPLE_EH_FILTER. (line 27) 51115* gimple_eh_filter_set_types: GIMPLE_EH_FILTER. (line 22) 51116* gimple_eh_filter_types: GIMPLE_EH_FILTER. (line 11) 51117* gimple_eh_filter_types_ptr: GIMPLE_EH_FILTER. (line 14) 51118* gimple_eh_must_not_throw_fndecl: GIMPLE_EH_FILTER. (line 32) 51119* gimple_eh_must_not_throw_set_fndecl: GIMPLE_EH_FILTER. (line 36) 51120* gimple_expr_code: Manipulating GIMPLE statements. 51121 (line 30) 51122* gimple_expr_type: Manipulating GIMPLE statements. 51123 (line 23) 51124* GIMPLE_GOTO: GIMPLE_GOTO. (line 6) 51125* gimple_goto_dest: GIMPLE_GOTO. (line 9) 51126* gimple_goto_set_dest: GIMPLE_GOTO. (line 12) 51127* gimple_has_mem_ops: Manipulating GIMPLE statements. 51128 (line 71) 51129* gimple_has_ops: Manipulating GIMPLE statements. 51130 (line 68) 51131* gimple_has_volatile_ops: Manipulating GIMPLE statements. 51132 (line 133) 51133* GIMPLE_LABEL: GIMPLE_LABEL. (line 6) 51134* gimple_label_label: GIMPLE_LABEL. (line 10) 51135* gimple_label_set_label: GIMPLE_LABEL. (line 13) 51136* gimple_loaded_syms: Manipulating GIMPLE statements. 51137 (line 121) 51138* gimple_locus: Manipulating GIMPLE statements. 51139 (line 41) 51140* gimple_locus_empty_p: Manipulating GIMPLE statements. 51141 (line 47) 51142* gimple_modified_p: Manipulating GIMPLE statements. 51143 (line 129) 51144* GIMPLE_NOP: GIMPLE_NOP. (line 6) 51145* gimple_nop_p: GIMPLE_NOP. (line 9) 51146* gimple_no_warning_p: Manipulating GIMPLE statements. 51147 (line 50) 51148* gimple_num_ops: Logical Operators. (line 76) 51149* gimple_num_ops <1>: Manipulating GIMPLE statements. 51150 (line 74) 51151* GIMPLE_OMP_ATOMIC_LOAD: GIMPLE_OMP_ATOMIC_LOAD. 51152 (line 6) 51153* gimple_omp_atomic_load_lhs: GIMPLE_OMP_ATOMIC_LOAD. 51154 (line 16) 51155* gimple_omp_atomic_load_rhs: GIMPLE_OMP_ATOMIC_LOAD. 51156 (line 24) 51157* gimple_omp_atomic_load_set_lhs: GIMPLE_OMP_ATOMIC_LOAD. 51158 (line 12) 51159* gimple_omp_atomic_load_set_rhs: GIMPLE_OMP_ATOMIC_LOAD. 51160 (line 20) 51161* GIMPLE_OMP_ATOMIC_STORE: GIMPLE_OMP_ATOMIC_STORE. 51162 (line 6) 51163* gimple_omp_atomic_store_set_val: GIMPLE_OMP_ATOMIC_STORE. 51164 (line 11) 51165* gimple_omp_atomic_store_val: GIMPLE_OMP_ATOMIC_STORE. 51166 (line 15) 51167* gimple_omp_body: GIMPLE_OMP_PARALLEL. 51168 (line 23) 51169* GIMPLE_OMP_CONTINUE: GIMPLE_OMP_CONTINUE. 51170 (line 6) 51171* gimple_omp_continue_control_def: GIMPLE_OMP_CONTINUE. 51172 (line 12) 51173* gimple_omp_continue_control_def_ptr: GIMPLE_OMP_CONTINUE. 51174 (line 17) 51175* gimple_omp_continue_control_use: GIMPLE_OMP_CONTINUE. 51176 (line 26) 51177* gimple_omp_continue_control_use_ptr: GIMPLE_OMP_CONTINUE. 51178 (line 31) 51179* gimple_omp_continue_set_control_def: GIMPLE_OMP_CONTINUE. 51180 (line 21) 51181* gimple_omp_continue_set_control_use: GIMPLE_OMP_CONTINUE. 51182 (line 35) 51183* GIMPLE_OMP_CRITICAL: GIMPLE_OMP_CRITICAL. 51184 (line 6) 51185* gimple_omp_critical_name: GIMPLE_OMP_CRITICAL. 51186 (line 12) 51187* gimple_omp_critical_name_ptr: GIMPLE_OMP_CRITICAL. 51188 (line 16) 51189* gimple_omp_critical_set_name: GIMPLE_OMP_CRITICAL. 51190 (line 21) 51191* GIMPLE_OMP_FOR: GIMPLE_OMP_FOR. (line 6) 51192* gimple_omp_for_clauses: GIMPLE_OMP_FOR. (line 17) 51193* gimple_omp_for_clauses_ptr: GIMPLE_OMP_FOR. (line 20) 51194* gimple_omp_for_cond: GIMPLE_OMP_FOR. (line 80) 51195* gimple_omp_for_final: GIMPLE_OMP_FOR. (line 48) 51196* gimple_omp_for_final_ptr: GIMPLE_OMP_FOR. (line 51) 51197* gimple_omp_for_incr: GIMPLE_OMP_FOR. (line 58) 51198* gimple_omp_for_incr_ptr: GIMPLE_OMP_FOR. (line 61) 51199* gimple_omp_for_index: GIMPLE_OMP_FOR. (line 28) 51200* gimple_omp_for_index_ptr: GIMPLE_OMP_FOR. (line 31) 51201* gimple_omp_for_initial: GIMPLE_OMP_FOR. (line 38) 51202* gimple_omp_for_initial_ptr: GIMPLE_OMP_FOR. (line 41) 51203* gimple_omp_for_pre_body: GIMPLE_OMP_FOR. (line 67) 51204* gimple_omp_for_set_clauses: GIMPLE_OMP_FOR. (line 23) 51205* gimple_omp_for_set_cond: GIMPLE_OMP_FOR. (line 76) 51206* gimple_omp_for_set_final: GIMPLE_OMP_FOR. (line 54) 51207* gimple_omp_for_set_incr: GIMPLE_OMP_FOR. (line 64) 51208* gimple_omp_for_set_index: GIMPLE_OMP_FOR. (line 34) 51209* gimple_omp_for_set_initial: GIMPLE_OMP_FOR. (line 44) 51210* gimple_omp_for_set_pre_body: GIMPLE_OMP_FOR. (line 71) 51211* GIMPLE_OMP_MASTER: GIMPLE_OMP_MASTER. (line 6) 51212* GIMPLE_OMP_ORDERED: GIMPLE_OMP_ORDERED. (line 6) 51213* GIMPLE_OMP_PARALLEL: GIMPLE_OMP_PARALLEL. 51214 (line 6) 51215* gimple_omp_parallel_child_fn: GIMPLE_OMP_PARALLEL. 51216 (line 42) 51217* gimple_omp_parallel_child_fn_ptr: GIMPLE_OMP_PARALLEL. 51218 (line 47) 51219* gimple_omp_parallel_clauses: GIMPLE_OMP_PARALLEL. 51220 (line 30) 51221* gimple_omp_parallel_clauses_ptr: GIMPLE_OMP_PARALLEL. 51222 (line 33) 51223* gimple_omp_parallel_combined_p: GIMPLE_OMP_PARALLEL. 51224 (line 15) 51225* gimple_omp_parallel_data_arg: GIMPLE_OMP_PARALLEL. 51226 (line 56) 51227* gimple_omp_parallel_data_arg_ptr: GIMPLE_OMP_PARALLEL. 51228 (line 61) 51229* gimple_omp_parallel_set_child_fn: GIMPLE_OMP_PARALLEL. 51230 (line 52) 51231* gimple_omp_parallel_set_clauses: GIMPLE_OMP_PARALLEL. 51232 (line 37) 51233* gimple_omp_parallel_set_combined_p: GIMPLE_OMP_PARALLEL. 51234 (line 19) 51235* gimple_omp_parallel_set_data_arg: GIMPLE_OMP_PARALLEL. 51236 (line 65) 51237* GIMPLE_OMP_RETURN: GIMPLE_OMP_RETURN. (line 6) 51238* gimple_omp_return_nowait_p: GIMPLE_OMP_RETURN. (line 13) 51239* gimple_omp_return_set_nowait: GIMPLE_OMP_RETURN. (line 10) 51240* GIMPLE_OMP_SECTION: GIMPLE_OMP_SECTION. (line 6) 51241* GIMPLE_OMP_SECTIONS: GIMPLE_OMP_SECTIONS. 51242 (line 6) 51243* gimple_omp_sections_clauses: GIMPLE_OMP_SECTIONS. 51244 (line 29) 51245* gimple_omp_sections_clauses_ptr: GIMPLE_OMP_SECTIONS. 51246 (line 32) 51247* gimple_omp_sections_control: GIMPLE_OMP_SECTIONS. 51248 (line 16) 51249* gimple_omp_sections_control_ptr: GIMPLE_OMP_SECTIONS. 51250 (line 20) 51251* gimple_omp_sections_set_clauses: GIMPLE_OMP_SECTIONS. 51252 (line 35) 51253* gimple_omp_sections_set_control: GIMPLE_OMP_SECTIONS. 51254 (line 24) 51255* gimple_omp_section_last_p: GIMPLE_OMP_SECTION. (line 11) 51256* gimple_omp_section_set_last: GIMPLE_OMP_SECTION. (line 15) 51257* gimple_omp_set_body: GIMPLE_OMP_PARALLEL. 51258 (line 26) 51259* GIMPLE_OMP_SINGLE: GIMPLE_OMP_SINGLE. (line 6) 51260* gimple_omp_single_clauses: GIMPLE_OMP_SINGLE. (line 13) 51261* gimple_omp_single_clauses_ptr: GIMPLE_OMP_SINGLE. (line 16) 51262* gimple_omp_single_set_clauses: GIMPLE_OMP_SINGLE. (line 19) 51263* gimple_op: Logical Operators. (line 79) 51264* gimple_op <1>: Manipulating GIMPLE statements. 51265 (line 80) 51266* gimple_ops: Logical Operators. (line 82) 51267* gimple_ops <1>: Manipulating GIMPLE statements. 51268 (line 77) 51269* gimple_op_ptr: Manipulating GIMPLE statements. 51270 (line 83) 51271* GIMPLE_PHI: GIMPLE_PHI. (line 6) 51272* gimple_phi_arg: GIMPLE_PHI. (line 24) 51273* gimple_phi_arg <1>: SSA. (line 62) 51274* gimple_phi_arg_def: SSA. (line 68) 51275* gimple_phi_arg_edge: SSA. (line 65) 51276* gimple_phi_capacity: GIMPLE_PHI. (line 6) 51277* gimple_phi_num_args: GIMPLE_PHI. (line 10) 51278* gimple_phi_num_args <1>: SSA. (line 58) 51279* gimple_phi_result: GIMPLE_PHI. (line 15) 51280* gimple_phi_result <1>: SSA. (line 55) 51281* gimple_phi_result_ptr: GIMPLE_PHI. (line 18) 51282* gimple_phi_set_arg: GIMPLE_PHI. (line 28) 51283* gimple_phi_set_result: GIMPLE_PHI. (line 21) 51284* gimple_plf: Manipulating GIMPLE statements. 51285 (line 64) 51286* GIMPLE_RESX: GIMPLE_RESX. (line 6) 51287* gimple_resx_region: GIMPLE_RESX. (line 12) 51288* gimple_resx_set_region: GIMPLE_RESX. (line 15) 51289* GIMPLE_RETURN: GIMPLE_RETURN. (line 6) 51290* gimple_return_retval: GIMPLE_RETURN. (line 9) 51291* gimple_return_set_retval: GIMPLE_RETURN. (line 12) 51292* gimple_seq_add_seq: GIMPLE sequences. (line 30) 51293* gimple_seq_add_stmt: GIMPLE sequences. (line 24) 51294* gimple_seq_alloc: GIMPLE sequences. (line 61) 51295* gimple_seq_copy: GIMPLE sequences. (line 65) 51296* gimple_seq_deep_copy: GIMPLE sequences. (line 36) 51297* gimple_seq_empty_p: GIMPLE sequences. (line 69) 51298* gimple_seq_first: GIMPLE sequences. (line 43) 51299* gimple_seq_init: GIMPLE sequences. (line 58) 51300* gimple_seq_last: GIMPLE sequences. (line 46) 51301* gimple_seq_reverse: GIMPLE sequences. (line 39) 51302* gimple_seq_set_first: GIMPLE sequences. (line 53) 51303* gimple_seq_set_last: GIMPLE sequences. (line 49) 51304* gimple_seq_singleton_p: GIMPLE sequences. (line 78) 51305* gimple_set_block: Manipulating GIMPLE statements. 51306 (line 38) 51307* gimple_set_def_ops: Manipulating GIMPLE statements. 51308 (line 96) 51309* gimple_set_has_volatile_ops: Manipulating GIMPLE statements. 51310 (line 136) 51311* gimple_set_locus: Manipulating GIMPLE statements. 51312 (line 44) 51313* gimple_set_op: Manipulating GIMPLE statements. 51314 (line 86) 51315* gimple_set_plf: Manipulating GIMPLE statements. 51316 (line 60) 51317* gimple_set_use_ops: Manipulating GIMPLE statements. 51318 (line 103) 51319* gimple_set_vdef_ops: Manipulating GIMPLE statements. 51320 (line 117) 51321* gimple_set_visited: Manipulating GIMPLE statements. 51322 (line 53) 51323* gimple_set_vuse_ops: Manipulating GIMPLE statements. 51324 (line 110) 51325* gimple_simplify: GIMPLE API. (line 6) 51326* gimple_simplify <1>: GIMPLE API. (line 8) 51327* gimple_simplify <2>: GIMPLE API. (line 10) 51328* gimple_simplify <3>: GIMPLE API. (line 12) 51329* gimple_simplify <4>: GIMPLE API. (line 14) 51330* gimple_simplify <5>: GIMPLE API. (line 16) 51331* gimple_statement_with_ops: Tuple representation. 51332 (line 96) 51333* gimple_stored_syms: Manipulating GIMPLE statements. 51334 (line 125) 51335* GIMPLE_SWITCH: GIMPLE_SWITCH. (line 6) 51336* gimple_switch_default_label: GIMPLE_SWITCH. (line 41) 51337* gimple_switch_index: GIMPLE_SWITCH. (line 24) 51338* gimple_switch_label: GIMPLE_SWITCH. (line 31) 51339* gimple_switch_num_labels: GIMPLE_SWITCH. (line 14) 51340* gimple_switch_set_default_label: GIMPLE_SWITCH. (line 45) 51341* gimple_switch_set_index: GIMPLE_SWITCH. (line 27) 51342* gimple_switch_set_label: GIMPLE_SWITCH. (line 36) 51343* gimple_switch_set_num_labels: GIMPLE_SWITCH. (line 19) 51344* GIMPLE_TRY: GIMPLE_TRY. (line 6) 51345* gimple_try_catch_is_cleanup: GIMPLE_TRY. (line 19) 51346* gimple_try_cleanup: GIMPLE_TRY. (line 26) 51347* gimple_try_eval: GIMPLE_TRY. (line 22) 51348* gimple_try_kind: GIMPLE_TRY. (line 15) 51349* gimple_try_set_catch_is_cleanup: GIMPLE_TRY. (line 30) 51350* gimple_try_set_cleanup: GIMPLE_TRY. (line 38) 51351* gimple_try_set_eval: GIMPLE_TRY. (line 34) 51352* gimple_use_ops: Manipulating GIMPLE statements. 51353 (line 100) 51354* gimple_vdef_ops: Manipulating GIMPLE statements. 51355 (line 114) 51356* gimple_visited_p: Manipulating GIMPLE statements. 51357 (line 57) 51358* gimple_vuse_ops: Manipulating GIMPLE statements. 51359 (line 107) 51360* gimple_wce_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 51361 (line 10) 51362* gimple_wce_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 51363 (line 17) 51364* gimple_wce_set_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 51365 (line 13) 51366* gimple_wce_set_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 51367 (line 20) 51368* GIMPLE_WITH_CLEANUP_EXPR: GIMPLE_WITH_CLEANUP_EXPR. 51369 (line 6) 51370* gimplification: Parsing pass. (line 13) 51371* gimplification <1>: Gimplification pass. 51372 (line 6) 51373* gimplifier: Parsing pass. (line 13) 51374* gimplify_assign: GIMPLE_ASSIGN. (line 41) 51375* gimplify_expr: Gimplification pass. 51376 (line 18) 51377* gimplify_function_tree: Gimplification pass. 51378 (line 18) 51379* GLOBAL_INIT_PRIORITY: Functions for C++. (line 141) 51380* global_regs: Register Basics. (line 63) 51381* GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 90) 51382* greater than: Comparisons. (line 60) 51383* greater than <1>: Comparisons. (line 64) 51384* greater than <2>: Comparisons. (line 72) 51385* gsi_after_labels: Sequence iterators. (line 74) 51386* gsi_bb: Sequence iterators. (line 82) 51387* gsi_commit_edge_inserts: Sequence iterators. (line 193) 51388* gsi_commit_edge_inserts <1>: Maintaining the CFG. 51389 (line 104) 51390* gsi_commit_one_edge_insert: Sequence iterators. (line 188) 51391* gsi_end_p: Sequence iterators. (line 59) 51392* gsi_end_p <1>: Maintaining the CFG. 51393 (line 48) 51394* gsi_for_stmt: Sequence iterators. (line 156) 51395* gsi_insert_after: Sequence iterators. (line 145) 51396* gsi_insert_after <1>: Maintaining the CFG. 51397 (line 60) 51398* gsi_insert_before: Sequence iterators. (line 134) 51399* gsi_insert_before <1>: Maintaining the CFG. 51400 (line 66) 51401* gsi_insert_on_edge: Sequence iterators. (line 173) 51402* gsi_insert_on_edge <1>: Maintaining the CFG. 51403 (line 104) 51404* gsi_insert_on_edge_immediate: Sequence iterators. (line 183) 51405* gsi_insert_seq_after: Sequence iterators. (line 152) 51406* gsi_insert_seq_before: Sequence iterators. (line 141) 51407* gsi_insert_seq_on_edge: Sequence iterators. (line 177) 51408* gsi_last: Sequence iterators. (line 49) 51409* gsi_last <1>: Maintaining the CFG. 51410 (line 44) 51411* gsi_last_bb: Sequence iterators. (line 55) 51412* gsi_link_after: Sequence iterators. (line 113) 51413* gsi_link_before: Sequence iterators. (line 103) 51414* gsi_link_seq_after: Sequence iterators. (line 108) 51415* gsi_link_seq_before: Sequence iterators. (line 97) 51416* gsi_move_after: Sequence iterators. (line 159) 51417* gsi_move_before: Sequence iterators. (line 164) 51418* gsi_move_to_bb_end: Sequence iterators. (line 169) 51419* gsi_next: Sequence iterators. (line 65) 51420* gsi_next <1>: Maintaining the CFG. 51421 (line 52) 51422* gsi_one_before_end_p: Sequence iterators. (line 62) 51423* gsi_prev: Sequence iterators. (line 68) 51424* gsi_prev <1>: Maintaining the CFG. 51425 (line 56) 51426* gsi_remove: Sequence iterators. (line 88) 51427* gsi_remove <1>: Maintaining the CFG. 51428 (line 72) 51429* gsi_replace: Sequence iterators. (line 128) 51430* gsi_seq: Sequence iterators. (line 85) 51431* gsi_split_seq_after: Sequence iterators. (line 118) 51432* gsi_split_seq_before: Sequence iterators. (line 123) 51433* gsi_start: Sequence iterators. (line 39) 51434* gsi_start <1>: Maintaining the CFG. 51435 (line 40) 51436* gsi_start_bb: Sequence iterators. (line 45) 51437* gsi_stmt: Sequence iterators. (line 71) 51438* gsi_stmt_ptr: Sequence iterators. (line 79) 51439* gt: Comparisons. (line 60) 51440* gt and attributes: Expressions. (line 83) 51441* gtu: Comparisons. (line 64) 51442* gtu and attributes: Expressions. (line 83) 51443* GTY: Type Information. (line 6) 51444* GT_EXPR: Unary and Binary Expressions. 51445 (line 6) 51446* H in constraint: Simple Constraints. (line 96) 51447* HAmode: Machine Modes. (line 146) 51448* HANDLER: Statements for C++. (line 6) 51449* HANDLER_BODY: Statements for C++. (line 6) 51450* HANDLER_PARMS: Statements for C++. (line 6) 51451* HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 464) 51452* hard registers: Regs and Memory. (line 9) 51453* HARD_FRAME_POINTER_IS_ARG_POINTER: Frame Registers. (line 57) 51454* HARD_FRAME_POINTER_IS_FRAME_POINTER: Frame Registers. (line 50) 51455* HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 19) 51456* HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 10) 51457* HARD_REGNO_NREGS_HAS_PADDING: Values in Registers. 51458 (line 21) 51459* HARD_REGNO_NREGS_WITH_PADDING: Values in Registers. 51460 (line 39) 51461* HARD_REGNO_RENAME_OK: Values in Registers. 51462 (line 113) 51463* HAS_INIT_SECTION: Macros for Initialization. 51464 (line 18) 51465* HAS_LONG_COND_BRANCH: Misc. (line 8) 51466* HAS_LONG_UNCOND_BRANCH: Misc. (line 17) 51467* HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11) 51468* HAVE_POST_DECREMENT: Addressing Modes. (line 11) 51469* HAVE_POST_INCREMENT: Addressing Modes. (line 10) 51470* HAVE_POST_MODIFY_DISP: Addressing Modes. (line 17) 51471* HAVE_POST_MODIFY_REG: Addressing Modes. (line 23) 51472* HAVE_PRE_DECREMENT: Addressing Modes. (line 9) 51473* HAVE_PRE_INCREMENT: Addressing Modes. (line 8) 51474* HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 16) 51475* HAVE_PRE_MODIFY_REG: Addressing Modes. (line 22) 51476* HCmode: Machine Modes. (line 199) 51477* HFmode: Machine Modes. (line 61) 51478* high: Constants. (line 220) 51479* HImode: Machine Modes. (line 29) 51480* HImode, in insn: Insns. (line 291) 51481* HONOR_REG_ALLOC_ORDER: Allocation Order. (line 36) 51482* host configuration: Host Config. (line 6) 51483* host functions: Host Common. (line 6) 51484* host hooks: Host Common. (line 6) 51485* host makefile fragment: Host Fragment. (line 6) 51486* HOST_BIT_BUCKET: Filesystem. (line 51) 51487* HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45) 51488* HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 11) 51489* HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 43) 51490* HOST_HOOKS_GT_PCH_GET_ADDRESS: Host Common. (line 15) 51491* HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 24) 51492* HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89) 51493* HOST_LONG_FORMAT: Host Misc. (line 45) 51494* HOST_LONG_LONG_FORMAT: Host Misc. (line 41) 51495* HOST_OBJECT_SUFFIX: Filesystem. (line 40) 51496* HOST_PTR_PRINTF: Host Misc. (line 49) 51497* HOT_TEXT_SECTION_NAME: Sections. (line 42) 51498* HQmode: Machine Modes. (line 110) 51499* i in constraint: Simple Constraints. (line 68) 51500* I in constraint: Simple Constraints. (line 79) 51501* identifier: Identifiers. (line 6) 51502* IDENTIFIER_LENGTH: Identifiers. (line 22) 51503* IDENTIFIER_NODE: Identifiers. (line 6) 51504* IDENTIFIER_OPNAME_P: Identifiers. (line 27) 51505* IDENTIFIER_POINTER: Identifiers. (line 17) 51506* IDENTIFIER_TYPENAME_P: Identifiers. (line 33) 51507* IEEE 754-2008: Decimal float library routines. 51508 (line 6) 51509* IFCVT_MACHDEP_INIT: Misc. (line 590) 51510* IFCVT_MODIFY_CANCEL: Misc. (line 584) 51511* IFCVT_MODIFY_FINAL: Misc. (line 578) 51512* IFCVT_MODIFY_INSN: Misc. (line 572) 51513* IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 564) 51514* IFCVT_MODIFY_TESTS: Misc. (line 554) 51515* IF_COND: Statements for C++. (line 6) 51516* IF_STMT: Statements for C++. (line 6) 51517* if_then_else: Comparisons. (line 80) 51518* if_then_else and attributes: Expressions. (line 32) 51519* if_then_else usage: Side Effects. (line 56) 51520* IMAGPART_EXPR: Unary and Binary Expressions. 51521 (line 6) 51522* Immediate Uses: SSA Operands. (line 258) 51523* immediate_operand: Machine-Independent Predicates. 51524 (line 10) 51525* IMMEDIATE_PREFIX: Instruction Output. (line 153) 51526* include: Including Patterns. (line 6) 51527* INCLUDE_DEFAULTS: Driver. (line 331) 51528* inclusive-or, bitwise: Arithmetic. (line 163) 51529* INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 188) 51530* INCOMING_REGNO: Register Basics. (line 90) 51531* INCOMING_REG_PARM_STACK_SPACE: Stack Arguments. (line 73) 51532* INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 133) 51533* INCOMING_STACK_BOUNDARY: Storage Layout. (line 171) 51534* INDEX_REG_CLASS: Register Classes. (line 140) 51535* indirect_jump instruction pattern: Standard Names. (line 1638) 51536* indirect_operand: Machine-Independent Predicates. 51537 (line 70) 51538* INDIRECT_REF: Storage References. (line 6) 51539* initialization routines: Initialization. (line 6) 51540* INITIAL_ELIMINATION_OFFSET: Elimination. (line 68) 51541* INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 75) 51542* INIT_ARRAY_SECTION_ASM_OP: Sections. (line 106) 51543* INIT_CUMULATIVE_ARGS: Register Arguments. (line 165) 51544* INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 193) 51545* INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 187) 51546* INIT_ENVIRONMENT: Driver. (line 309) 51547* INIT_EXPANDERS: Per-Function Data. (line 36) 51548* INIT_EXPR: Unary and Binary Expressions. 51549 (line 6) 51550* init_machine_status: Per-Function Data. (line 42) 51551* init_one_libfunc: Library Calls. (line 15) 51552* INIT_SECTION_ASM_OP: Sections. (line 90) 51553* INIT_SECTION_ASM_OP <1>: Macros for Initialization. 51554 (line 9) 51555* inlining: Target Attributes. (line 95) 51556* insert_insn_on_edge: Maintaining the CFG. 51557 (line 104) 51558* insn: Insns. (line 63) 51559* insn and /f: Flags. (line 135) 51560* insn and /j: Flags. (line 171) 51561* insn and /s: Flags. (line 38) 51562* insn and /s <1>: Flags. (line 162) 51563* insn and /u: Flags. (line 28) 51564* insn and /v: Flags. (line 33) 51565* insn attributes: Insn Attributes. (line 6) 51566* insn canonicalization: Insn Canonicalizations. 51567 (line 6) 51568* insn includes: Including Patterns. (line 6) 51569* insn lengths, computing: Insn Lengths. (line 6) 51570* insn notes, notes: Basic Blocks. (line 52) 51571* insn splitting: Insn Splitting. (line 6) 51572* insn-attr.h: Defining Attributes. 51573 (line 34) 51574* insns: Insns. (line 6) 51575* insns, generating: RTL Template. (line 6) 51576* insns, recognizing: RTL Template. (line 6) 51577* INSN_ANNULLED_BRANCH_P: Flags. (line 28) 51578* INSN_CODE: Insns. (line 318) 51579* INSN_DELETED_P: Flags. (line 33) 51580* INSN_FROM_TARGET_P: Flags. (line 38) 51581* insn_list: Insns. (line 568) 51582* INSN_REFERENCES_ARE_DELAYED: Misc. (line 491) 51583* INSN_SETS_ARE_DELAYED: Misc. (line 480) 51584* INSN_UID: Insns. (line 23) 51585* INSN_VAR_LOCATION: Insns. (line 247) 51586* instruction attributes: Insn Attributes. (line 6) 51587* instruction latency time: Processor pipeline description. 51588 (line 6) 51589* instruction latency time <1>: Processor pipeline description. 51590 (line 105) 51591* instruction latency time <2>: Processor pipeline description. 51592 (line 196) 51593* instruction patterns: Patterns. (line 6) 51594* instruction splitting: Insn Splitting. (line 6) 51595* insv instruction pattern: Standard Names. (line 1398) 51596* insvM instruction pattern: Standard Names. (line 1350) 51597* insvmisalignM instruction pattern: Standard Names. (line 1360) 51598* int iterators in .md files: Int Iterators. (line 6) 51599* INT16_TYPE: Type Layout. (line 210) 51600* INT32_TYPE: Type Layout. (line 211) 51601* INT64_TYPE: Type Layout. (line 212) 51602* INT8_TYPE: Type Layout. (line 209) 51603* INTEGER_CST: Constant expressions. 51604 (line 6) 51605* INTEGER_TYPE: Types. (line 6) 51606* Interdependence of Patterns: Dependent Patterns. (line 6) 51607* interfacing to GCC output: Interface. (line 6) 51608* interlock delays: Processor pipeline description. 51609 (line 6) 51610* intermediate representation lowering: Parsing pass. (line 13) 51611* INTMAX_TYPE: Type Layout. (line 186) 51612* INTPTR_TYPE: Type Layout. (line 233) 51613* introduction: Top. (line 6) 51614* INT_FAST16_TYPE: Type Layout. (line 226) 51615* INT_FAST32_TYPE: Type Layout. (line 227) 51616* INT_FAST64_TYPE: Type Layout. (line 228) 51617* INT_FAST8_TYPE: Type Layout. (line 225) 51618* INT_LEAST16_TYPE: Type Layout. (line 218) 51619* INT_LEAST32_TYPE: Type Layout. (line 219) 51620* INT_LEAST64_TYPE: Type Layout. (line 220) 51621* INT_LEAST8_TYPE: Type Layout. (line 217) 51622* INT_TYPE_SIZE: Type Layout. (line 11) 51623* INVOKE__main: Macros for Initialization. 51624 (line 50) 51625* in_struct: Flags. (line 254) 51626* in_struct, in code_label and note: Flags. (line 48) 51627* in_struct, in insn and jump_insn and call_insn: Flags. (line 38) 51628* in_struct, in insn, call_insn, jump_insn and jump_table_data: Flags. 51629 (line 162) 51630* in_struct, in subreg: Flags. (line 201) 51631* ior: Arithmetic. (line 163) 51632* ior and attributes: Expressions. (line 50) 51633* ior, canonicalization of: Insn Canonicalizations. 51634 (line 67) 51635* iorM3 instruction pattern: Standard Names. (line 416) 51636* IRA_HARD_REGNO_ADD_COST_MULTIPLIER: Allocation Order. (line 44) 51637* is_a: Machine Modes. (line 351) 51638* IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 123) 51639* is_gimple_addressable: Logical Operators. (line 113) 51640* is_gimple_asm_val: Logical Operators. (line 117) 51641* is_gimple_assign: Logical Operators. (line 149) 51642* is_gimple_call: Logical Operators. (line 152) 51643* is_gimple_call_addr: Logical Operators. (line 120) 51644* is_gimple_constant: Logical Operators. (line 128) 51645* is_gimple_debug: Logical Operators. (line 155) 51646* is_gimple_ip_invariant: Logical Operators. (line 137) 51647* is_gimple_ip_invariant_address: Logical Operators. (line 142) 51648* is_gimple_mem_ref_addr: Logical Operators. (line 124) 51649* is_gimple_min_invariant: Logical Operators. (line 131) 51650* is_gimple_omp: Logical Operators. (line 166) 51651* is_gimple_val: Logical Operators. (line 107) 51652* iterators in .md files: Iterators. (line 6) 51653* IV analysis on GIMPLE: Scalar evolutions. (line 6) 51654* IV analysis on RTL: loop-iv. (line 6) 51655* JMP_BUF_SIZE: Exception Region Output. 51656 (line 83) 51657* jump: Flags. (line 295) 51658* jump instruction pattern: Standard Names. (line 1516) 51659* jump instruction patterns: Jump Patterns. (line 6) 51660* jump instructions and set: Side Effects. (line 56) 51661* jump, in call_insn: Flags. (line 175) 51662* jump, in insn: Flags. (line 171) 51663* jump, in mem: Flags. (line 59) 51664* Jumps: Jumps. (line 6) 51665* JUMP_ALIGN: Alignment Output. (line 8) 51666* jump_insn: Insns. (line 73) 51667* jump_insn and /f: Flags. (line 135) 51668* jump_insn and /j: Flags. (line 10) 51669* jump_insn and /s: Flags. (line 38) 51670* jump_insn and /s <1>: Flags. (line 162) 51671* jump_insn and /u: Flags. (line 28) 51672* jump_insn and /v: Flags. (line 33) 51673* JUMP_LABEL: Insns. (line 80) 51674* JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 155) 51675* jump_table_data: Insns. (line 166) 51676* jump_table_data and /s: Flags. (line 162) 51677* jump_table_data and /v: Flags. (line 33) 51678* LABEL_ALIGN: Alignment Output. (line 57) 51679* LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 26) 51680* LABEL_ALTERNATE_NAME: Edges. (line 180) 51681* LABEL_ALT_ENTRY_P: Insns. (line 146) 51682* LABEL_DECL: Declarations. (line 6) 51683* LABEL_KIND: Insns. (line 146) 51684* LABEL_NUSES: Insns. (line 142) 51685* LABEL_PRESERVE_P: Flags. (line 48) 51686* label_ref: Constants. (line 199) 51687* label_ref and /v: Flags. (line 54) 51688* label_ref, RTL sharing: Sharing. (line 38) 51689* LABEL_REF_NONLOCAL_P: Flags. (line 54) 51690* language-dependent trees: Language-dependent trees. 51691 (line 6) 51692* language-independent intermediate representation: Parsing pass. 51693 (line 13) 51694* lang_hooks.gimplify_expr: Gimplification pass. 51695 (line 18) 51696* lang_hooks.parse_file: Parsing pass. (line 6) 51697* large return values: Aggregate Return. (line 6) 51698* LAST_STACK_REG: Stack Registers. (line 30) 51699* LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 51700* lceilMN2: Standard Names. (line 1019) 51701* LCSSA: LCSSA. (line 6) 51702* LDD_SUFFIX: Macros for Initialization. 51703 (line 121) 51704* ldexpM3 instruction pattern: Standard Names. (line 804) 51705* LD_FINI_SWITCH: Macros for Initialization. 51706 (line 28) 51707* LD_INIT_SWITCH: Macros for Initialization. 51708 (line 24) 51709* le: Comparisons. (line 76) 51710* le and attributes: Expressions. (line 83) 51711* leaf functions: Leaf Functions. (line 6) 51712* leaf_function_p: Standard Names. (line 1600) 51713* LEAF_REGISTERS: Leaf Functions. (line 23) 51714* LEAF_REG_REMAP: Leaf Functions. (line 37) 51715* left rotate: Arithmetic. (line 195) 51716* left shift: Arithmetic. (line 173) 51717* LEGITIMATE_PIC_OPERAND_P: PIC. (line 31) 51718* LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 150) 51719* length: GTY Options. (line 47) 51720* less than: Comparisons. (line 68) 51721* less than or equal: Comparisons. (line 76) 51722* leu: Comparisons. (line 76) 51723* leu and attributes: Expressions. (line 83) 51724* LE_EXPR: Unary and Binary Expressions. 51725 (line 6) 51726* lfloorMN2: Standard Names. (line 1014) 51727* LIB2FUNCS_EXTRA: Target Fragment. (line 11) 51728* LIBCALL_VALUE: Scalar Return. (line 56) 51729* libgcc.a: Library Calls. (line 6) 51730* LIBGCC2_CFLAGS: Target Fragment. (line 8) 51731* LIBGCC2_GNU_PREFIX: Type Layout. (line 102) 51732* LIBGCC2_UNWIND_ATTRIBUTE: Misc. (line 1093) 51733* LIBGCC_SPEC: Driver. (line 115) 51734* library subroutine names: Library Calls. (line 6) 51735* LIBRARY_PATH_ENV: Misc. (line 532) 51736* LIB_SPEC: Driver. (line 107) 51737* LIMIT_RELOAD_CLASS: Register Classes. (line 296) 51738* LINK_COMMAND_SPEC: Driver. (line 240) 51739* LINK_EH_SPEC: Driver. (line 142) 51740* LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 232) 51741* LINK_LIBGCC_SPECIAL_1: Driver. (line 227) 51742* LINK_SPEC: Driver. (line 100) 51743* list: Containers. (line 6) 51744* Liveness representation: Liveness information. 51745 (line 6) 51746* load address instruction: Simple Constraints. (line 162) 51747* LOAD_EXTEND_OP: Misc. (line 80) 51748* load_multiple instruction pattern: Standard Names. (line 136) 51749* Local Register Allocator (LRA): RTL passes. (line 187) 51750* LOCAL_ALIGNMENT: Storage Layout. (line 281) 51751* LOCAL_CLASS_P: Classes. (line 70) 51752* LOCAL_DECL_ALIGNMENT: Storage Layout. (line 318) 51753* LOCAL_INCLUDE_DIR: Driver. (line 316) 51754* LOCAL_LABEL_PREFIX: Instruction Output. (line 151) 51755* LOCAL_REGNO: Register Basics. (line 104) 51756* log10M2 instruction pattern: Standard Names. (line 908) 51757* log1pM2 instruction pattern: Standard Names. (line 898) 51758* log2M2 instruction pattern: Standard Names. (line 915) 51759* logbM2 instruction pattern: Standard Names. (line 922) 51760* Logical Operators: Logical Operators. (line 6) 51761* logical-and, bitwise: Arithmetic. (line 158) 51762* LOGICAL_OP_NON_SHORT_CIRCUIT: Costs. (line 294) 51763* logM2 instruction pattern: Standard Names. (line 891) 51764* LOG_LINKS: Insns. (line 337) 51765* longjmp and automatic variables: Interface. (line 52) 51766* LONG_ACCUM_TYPE_SIZE: Type Layout. (line 92) 51767* LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 57) 51768* LONG_FRACT_TYPE_SIZE: Type Layout. (line 72) 51769* LONG_LONG_ACCUM_TYPE_SIZE: Type Layout. (line 97) 51770* LONG_LONG_FRACT_TYPE_SIZE: Type Layout. (line 77) 51771* LONG_LONG_TYPE_SIZE: Type Layout. (line 32) 51772* LONG_TYPE_SIZE: Type Layout. (line 21) 51773* Loop analysis: Loop representation. 51774 (line 6) 51775* Loop manipulation: Loop manipulation. (line 6) 51776* Loop querying: Loop querying. (line 6) 51777* Loop representation: Loop representation. 51778 (line 6) 51779* Loop-closed SSA form: LCSSA. (line 6) 51780* looping instruction patterns: Looping Patterns. (line 6) 51781* LOOP_ALIGN: Alignment Output. (line 40) 51782* LOOP_EXPR: Unary and Binary Expressions. 51783 (line 6) 51784* lowering, language-dependent intermediate representation: Parsing pass. 51785 (line 13) 51786* lo_sum: Arithmetic. (line 25) 51787* lrintMN2: Standard Names. (line 1004) 51788* lroundMN2: Standard Names. (line 1009) 51789* lshiftrt: Arithmetic. (line 190) 51790* lshiftrt and attributes: Expressions. (line 83) 51791* LSHIFT_EXPR: Unary and Binary Expressions. 51792 (line 6) 51793* lshrM3 instruction pattern: Standard Names. (line 742) 51794* lt: Comparisons. (line 68) 51795* lt and attributes: Expressions. (line 83) 51796* LTGT_EXPR: Unary and Binary Expressions. 51797 (line 6) 51798* lto: LTO. (line 6) 51799* ltrans: LTO. (line 6) 51800* ltu: Comparisons. (line 68) 51801* LT_EXPR: Unary and Binary Expressions. 51802 (line 6) 51803* m in constraint: Simple Constraints. (line 17) 51804* machine attributes: Target Attributes. (line 6) 51805* machine description macros: Target Macros. (line 6) 51806* machine descriptions: Machine Desc. (line 6) 51807* machine mode conversions: Conversions. (line 6) 51808* machine mode wrapper classes: Machine Modes. (line 290) 51809* machine modes: Machine Modes. (line 6) 51810* machine specific constraints: Machine Constraints. 51811 (line 6) 51812* machine-independent predicates: Machine-Independent Predicates. 51813 (line 6) 51814* machine_mode: Machine Modes. (line 6) 51815* MACH_DEP_SECTION_ASM_FLAG: Sections. (line 120) 51816* macros, target description: Target Macros. (line 6) 51817* maddMN4 instruction pattern: Standard Names. (line 663) 51818* makefile fragment: Fragments. (line 6) 51819* makefile targets: Makefile. (line 6) 51820* MAKE_DECL_ONE_ONLY: Label Output. (line 281) 51821* make_safe_from: Expander Definitions. 51822 (line 151) 51823* MALLOC_ABI_ALIGNMENT: Storage Layout. (line 190) 51824* Manipulating GIMPLE statements: Manipulating GIMPLE statements. 51825 (line 6) 51826* marking roots: GGC Roots. (line 6) 51827* maskloadMN instruction pattern: Standard Names. (line 370) 51828* maskstoreMN instruction pattern: Standard Names. (line 377) 51829* mask_gather_loadM instruction pattern: Standard Names. (line 248) 51830* MASK_RETURN_ADDR: Exception Region Output. 51831 (line 35) 51832* mask_scatter_storeM instruction pattern: Standard Names. (line 271) 51833* Match and Simplify: Match and Simplify. (line 6) 51834* matching constraint: Simple Constraints. (line 140) 51835* matching operands: Output Template. (line 49) 51836* match_dup: RTL Template. (line 73) 51837* match_dup <1>: define_peephole2. (line 28) 51838* match_dup and attributes: Insn Lengths. (line 16) 51839* match_operand: RTL Template. (line 16) 51840* match_operand and attributes: Expressions. (line 55) 51841* match_operator: RTL Template. (line 95) 51842* match_op_dup: RTL Template. (line 163) 51843* match_parallel: RTL Template. (line 172) 51844* match_par_dup: RTL Template. (line 219) 51845* match_scratch: RTL Template. (line 58) 51846* match_scratch <1>: define_peephole2. (line 28) 51847* match_test and attributes: Expressions. (line 64) 51848* math library: Soft float library routines. 51849 (line 6) 51850* math, in RTL: Arithmetic. (line 6) 51851* matherr: Library Calls. (line 59) 51852* MATH_LIBRARY: Misc. (line 525) 51853* maxM3 instruction pattern: Standard Names. (line 478) 51854* MAX_BITSIZE_MODE_ANY_INT: Machine Modes. (line 448) 51855* MAX_BITSIZE_MODE_ANY_MODE: Machine Modes. (line 454) 51856* MAX_BITS_PER_WORD: Storage Layout. (line 54) 51857* MAX_CONDITIONAL_EXECUTE: Misc. (line 547) 51858* MAX_FIXED_MODE_SIZE: Storage Layout. (line 463) 51859* MAX_MOVE_MAX: Misc. (line 127) 51860* MAX_OFILE_ALIGNMENT: Storage Layout. (line 228) 51861* MAX_REGS_PER_ADDRESS: Addressing Modes. (line 42) 51862* MAX_STACK_ALIGNMENT: Storage Layout. (line 222) 51863* maybe_undef: GTY Options. (line 141) 51864* may_trap_p, tree_could_trap_p: Edges. (line 114) 51865* mcount: Profiling. (line 12) 51866* MD_EXEC_PREFIX: Driver. (line 271) 51867* MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 93) 51868* MD_HANDLE_UNWABI: Exception Handling. (line 112) 51869* MD_STARTFILE_PREFIX: Driver. (line 299) 51870* MD_STARTFILE_PREFIX_1: Driver. (line 304) 51871* mem: Regs and Memory. (line 396) 51872* mem and /c: Flags. (line 70) 51873* mem and /f: Flags. (line 74) 51874* mem and /j: Flags. (line 59) 51875* mem and /u: Flags. (line 78) 51876* mem and /v: Flags. (line 65) 51877* mem, RTL sharing: Sharing. (line 43) 51878* memory model: Memory model. (line 6) 51879* memory reference, nonoffsettable: Simple Constraints. (line 254) 51880* memory references in constraints: Simple Constraints. (line 17) 51881* memory_barrier instruction pattern: Standard Names. (line 1994) 51882* memory_blockage instruction pattern: Standard Names. (line 1985) 51883* MEMORY_MOVE_COST: Costs. (line 53) 51884* memory_operand: Machine-Independent Predicates. 51885 (line 57) 51886* MEM_ADDR_SPACE: Special Accessors. (line 48) 51887* MEM_ALIAS_SET: Special Accessors. (line 9) 51888* MEM_ALIGN: Special Accessors. (line 45) 51889* MEM_EXPR: Special Accessors. (line 19) 51890* MEM_KEEP_ALIAS_SET_P: Flags. (line 59) 51891* MEM_NOTRAP_P: Flags. (line 70) 51892* MEM_OFFSET: Special Accessors. (line 31) 51893* MEM_OFFSET_KNOWN_P: Special Accessors. (line 27) 51894* MEM_POINTER: Flags. (line 74) 51895* MEM_READONLY_P: Flags. (line 78) 51896* MEM_REF: Storage References. (line 6) 51897* MEM_SIZE: Special Accessors. (line 39) 51898* MEM_SIZE_KNOWN_P: Special Accessors. (line 35) 51899* mem_thread_fence instruction pattern: Standard Names. (line 2270) 51900* MEM_VOLATILE_P: Flags. (line 65) 51901* METHOD_TYPE: Types. (line 6) 51902* MINIMUM_ALIGNMENT: Storage Layout. (line 331) 51903* MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 198) 51904* minM3 instruction pattern: Standard Names. (line 478) 51905* minus: Arithmetic. (line 38) 51906* minus and attributes: Expressions. (line 83) 51907* minus, canonicalization of: Insn Canonicalizations. 51908 (line 27) 51909* MINUS_EXPR: Unary and Binary Expressions. 51910 (line 6) 51911* MIN_UNITS_PER_WORD: Storage Layout. (line 64) 51912* MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6) 51913* miscellaneous register hooks: Miscellaneous Register Hooks. 51914 (line 6) 51915* mnemonic attribute: Mnemonic Attribute. (line 6) 51916* mod: Arithmetic. (line 136) 51917* mod and attributes: Expressions. (line 83) 51918* mode classes: Machine Modes. (line 226) 51919* mode iterators in .md files: Mode Iterators. (line 6) 51920* mode switching: Mode Switching. (line 6) 51921* MODE_ACCUM: Machine Modes. (line 256) 51922* MODE_BASE_REG_CLASS: Register Classes. (line 116) 51923* MODE_BASE_REG_REG_CLASS: Register Classes. (line 122) 51924* MODE_CC: Machine Modes. (line 275) 51925* MODE_CC <1>: MODE_CC Condition Codes. 51926 (line 6) 51927* MODE_CODE_BASE_REG_CLASS: Register Classes. (line 129) 51928* MODE_COMPLEX_FLOAT: Machine Modes. (line 267) 51929* MODE_COMPLEX_INT: Machine Modes. (line 264) 51930* MODE_DECIMAL_FLOAT: Machine Modes. (line 244) 51931* MODE_FLOAT: Machine Modes. (line 240) 51932* MODE_FRACT: Machine Modes. (line 248) 51933* MODE_FUNCTION: Machine Modes. (line 271) 51934* MODE_INT: Machine Modes. (line 232) 51935* MODE_PARTIAL_INT: Machine Modes. (line 236) 51936* MODE_POINTER_BOUNDS: Machine Modes. (line 280) 51937* MODE_RANDOM: Machine Modes. (line 285) 51938* MODE_UACCUM: Machine Modes. (line 260) 51939* MODE_UFRACT: Machine Modes. (line 252) 51940* modifiers in constraints: Modifiers. (line 6) 51941* MODIFY_EXPR: Unary and Binary Expressions. 51942 (line 6) 51943* MODIFY_JNI_METHOD_CALL: Misc. (line 896) 51944* modM3 instruction pattern: Standard Names. (line 416) 51945* modulo scheduling: RTL passes. (line 123) 51946* MOVE_MAX: Misc. (line 122) 51947* MOVE_MAX_PIECES: Costs. (line 210) 51948* MOVE_RATIO: Costs. (line 149) 51949* movM instruction pattern: Standard Names. (line 11) 51950* movmemM instruction pattern: Standard Names. (line 1118) 51951* movmisalignM instruction pattern: Standard Names. (line 125) 51952* movMODEcc instruction pattern: Standard Names. (line 1412) 51953* movstr instruction pattern: Standard Names. (line 1153) 51954* movstrictM instruction pattern: Standard Names. (line 119) 51955* msubMN4 instruction pattern: Standard Names. (line 686) 51956* mulhisi3 instruction pattern: Standard Names. (line 639) 51957* mulM3 instruction pattern: Standard Names. (line 416) 51958* mulqihi3 instruction pattern: Standard Names. (line 643) 51959* mulsidi3 instruction pattern: Standard Names. (line 643) 51960* mult: Arithmetic. (line 93) 51961* mult and attributes: Expressions. (line 83) 51962* mult, canonicalization of: Insn Canonicalizations. 51963 (line 27) 51964* mult, canonicalization of <1>: Insn Canonicalizations. 51965 (line 107) 51966* MULTIARCH_DIRNAME: Target Fragment. (line 173) 51967* MULTILIB_DEFAULTS: Driver. (line 256) 51968* MULTILIB_DIRNAMES: Target Fragment. (line 44) 51969* MULTILIB_EXCEPTIONS: Target Fragment. (line 70) 51970* MULTILIB_EXTRA_OPTS: Target Fragment. (line 135) 51971* MULTILIB_MATCHES: Target Fragment. (line 63) 51972* MULTILIB_OPTIONS: Target Fragment. (line 24) 51973* MULTILIB_OSDIRNAMES: Target Fragment. (line 142) 51974* MULTILIB_REQUIRED: Target Fragment. (line 82) 51975* MULTILIB_REUSE: Target Fragment. (line 103) 51976* multiple alternative constraints: Multi-Alternative. (line 6) 51977* MULTIPLE_SYMBOL_SPACES: Misc. (line 504) 51978* multiplication: Arithmetic. (line 93) 51979* multiplication with signed saturation: Arithmetic. (line 93) 51980* multiplication with unsigned saturation: Arithmetic. (line 93) 51981* MULT_EXPR: Unary and Binary Expressions. 51982 (line 6) 51983* MULT_HIGHPART_EXPR: Unary and Binary Expressions. 51984 (line 6) 51985* mulvM4 instruction pattern: Standard Names. (line 432) 51986* n in constraint: Simple Constraints. (line 73) 51987* name: Identifiers. (line 6) 51988* named address spaces: Named Address Spaces. 51989 (line 6) 51990* named patterns and conditions: Patterns. (line 49) 51991* names, pattern: Standard Names. (line 6) 51992* namespace, scope: Namespaces. (line 6) 51993* NAMESPACE_DECL: Declarations. (line 6) 51994* NAMESPACE_DECL <1>: Namespaces. (line 6) 51995* NATIVE_SYSTEM_HEADER_COMPONENT: Driver. (line 326) 51996* ne: Comparisons. (line 56) 51997* ne and attributes: Expressions. (line 83) 51998* nearbyintM2 instruction pattern: Standard Names. (line 988) 51999* neg: Arithmetic. (line 82) 52000* neg and attributes: Expressions. (line 83) 52001* neg, canonicalization of: Insn Canonicalizations. 52002 (line 27) 52003* NEGATE_EXPR: Unary and Binary Expressions. 52004 (line 6) 52005* negation: Arithmetic. (line 82) 52006* negation with signed saturation: Arithmetic. (line 82) 52007* negation with unsigned saturation: Arithmetic. (line 82) 52008* negM2 instruction pattern: Standard Names. (line 754) 52009* negMODEcc instruction pattern: Standard Names. (line 1457) 52010* negvM3 instruction pattern: Standard Names. (line 757) 52011* nested functions, trampolines for: Trampolines. (line 6) 52012* nested_ptr: GTY Options. (line 149) 52013* next_bb, prev_bb, FOR_EACH_BB, FOR_ALL_BB: Basic Blocks. (line 25) 52014* NEXT_INSN: Insns. (line 30) 52015* NEXT_OBJC_RUNTIME: Library Calls. (line 82) 52016* NE_EXPR: Unary and Binary Expressions. 52017 (line 6) 52018* nil: RTL Objects. (line 73) 52019* NM_FLAGS: Macros for Initialization. 52020 (line 110) 52021* nondeterministic finite state automaton: Processor pipeline description. 52022 (line 304) 52023* nonimmediate_operand: Machine-Independent Predicates. 52024 (line 100) 52025* nonlocal goto handler: Edges. (line 171) 52026* nonlocal_goto instruction pattern: Standard Names. (line 1820) 52027* nonlocal_goto_receiver instruction pattern: Standard Names. 52028 (line 1837) 52029* nonmemory_operand: Machine-Independent Predicates. 52030 (line 96) 52031* nonoffsettable memory reference: Simple Constraints. (line 254) 52032* NON_LVALUE_EXPR: Unary and Binary Expressions. 52033 (line 6) 52034* nop instruction pattern: Standard Names. (line 1633) 52035* NOP_EXPR: Unary and Binary Expressions. 52036 (line 6) 52037* normal predicates: Predicates. (line 31) 52038* not: Arithmetic. (line 154) 52039* not and attributes: Expressions. (line 50) 52040* not equal: Comparisons. (line 56) 52041* not, canonicalization of: Insn Canonicalizations. 52042 (line 27) 52043* note: Insns. (line 183) 52044* note and /i: Flags. (line 48) 52045* note and /v: Flags. (line 33) 52046* NOTE_INSN_BASIC_BLOCK: Basic Blocks. (line 50) 52047* NOTE_INSN_BASIC_BLOCK <1>: Basic Blocks. (line 52) 52048* NOTE_INSN_BEGIN_STMT: Insns. (line 233) 52049* NOTE_INSN_BLOCK_BEG: Insns. (line 208) 52050* NOTE_INSN_BLOCK_END: Insns. (line 208) 52051* NOTE_INSN_DELETED: Insns. (line 198) 52052* NOTE_INSN_DELETED_LABEL: Insns. (line 203) 52053* NOTE_INSN_EH_REGION_BEG: Insns. (line 214) 52054* NOTE_INSN_EH_REGION_END: Insns. (line 214) 52055* NOTE_INSN_FUNCTION_BEG: Insns. (line 221) 52056* NOTE_INSN_INLINE_ENTRY: Insns. (line 238) 52057* NOTE_INSN_VAR_LOCATION: Insns. (line 225) 52058* NOTE_LINE_NUMBER: Insns. (line 183) 52059* NOTE_SOURCE_FILE: Insns. (line 183) 52060* NOTE_VAR_LOCATION: Insns. (line 225) 52061* NOTICE_UPDATE_CC: CC0 Condition Codes. 52062 (line 30) 52063* notMODEcc instruction pattern: Standard Names. (line 1464) 52064* NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 25) 52065* NO_DBX_FUNCTION_END: DBX Hooks. (line 19) 52066* NO_DBX_GCC_MARKER: File Names and DBX. (line 27) 52067* NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 22) 52068* NO_DOLLAR_IN_LABEL: Label Output. (line 64) 52069* NO_DOT_IN_LABEL: Label Output. (line 70) 52070* NO_FUNCTION_CSE: Costs. (line 289) 52071* NO_IMPLICIT_EXTERN_C: Misc. (line 403) 52072* NO_PROFILE_COUNTERS: Profiling. (line 27) 52073* NO_REGS: Register Classes. (line 17) 52074* Number of iterations analysis: Number of iterations. 52075 (line 6) 52076* NUM_MACHINE_MODES: Machine Modes. (line 387) 52077* NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30) 52078* NUM_POLY_INT_COEFFS: Overview of poly_int. 52079 (line 24) 52080* N_REG_CLASSES: Register Classes. (line 81) 52081* o in constraint: Simple Constraints. (line 23) 52082* OACC_CACHE: OpenACC. (line 6) 52083* OACC_DATA: OpenACC. (line 6) 52084* OACC_DECLARE: OpenACC. (line 6) 52085* OACC_ENTER_DATA: OpenACC. (line 6) 52086* OACC_EXIT_DATA: OpenACC. (line 6) 52087* OACC_HOST_DATA: OpenACC. (line 6) 52088* OACC_KERNELS: OpenACC. (line 6) 52089* OACC_LOOP: OpenACC. (line 6) 52090* OACC_PARALLEL: OpenACC. (line 6) 52091* OACC_UPDATE: OpenACC. (line 6) 52092* OBJC_GEN_METHOD_LABEL: Label Output. (line 482) 52093* OBJC_JBLEN: Misc. (line 1088) 52094* OBJECT_FORMAT_COFF: Macros for Initialization. 52095 (line 96) 52096* offsettable address: Simple Constraints. (line 23) 52097* OFFSET_TYPE: Types. (line 6) 52098* OImode: Machine Modes. (line 51) 52099* OMP_ATOMIC: OpenMP. (line 6) 52100* OMP_CLAUSE: OpenMP. (line 6) 52101* OMP_CONTINUE: OpenMP. (line 6) 52102* OMP_CRITICAL: OpenMP. (line 6) 52103* OMP_FOR: OpenMP. (line 6) 52104* OMP_MASTER: OpenMP. (line 6) 52105* OMP_ORDERED: OpenMP. (line 6) 52106* OMP_PARALLEL: OpenMP. (line 6) 52107* OMP_RETURN: OpenMP. (line 6) 52108* OMP_SECTION: OpenMP. (line 6) 52109* OMP_SECTIONS: OpenMP. (line 6) 52110* OMP_SINGLE: OpenMP. (line 6) 52111* one_cmplM2 instruction pattern: Standard Names. (line 1115) 52112* operand access: Accessors. (line 6) 52113* Operand Access Routines: SSA Operands. (line 116) 52114* operand constraints: Constraints. (line 6) 52115* Operand Iterators: SSA Operands. (line 116) 52116* operand predicates: Predicates. (line 6) 52117* operand substitution: Output Template. (line 6) 52118* Operands: Operands. (line 6) 52119* operands: SSA Operands. (line 6) 52120* operands <1>: Patterns. (line 55) 52121* operator predicates: Predicates. (line 6) 52122* optc-gen.awk: Options. (line 6) 52123* OPTGROUP_ALL: Optimization groups. 52124 (line 28) 52125* OPTGROUP_INLINE: Optimization groups. 52126 (line 15) 52127* OPTGROUP_IPA: Optimization groups. 52128 (line 9) 52129* OPTGROUP_LOOP: Optimization groups. 52130 (line 12) 52131* OPTGROUP_OMP: Optimization groups. 52132 (line 18) 52133* OPTGROUP_OTHER: Optimization groups. 52134 (line 24) 52135* OPTGROUP_VEC: Optimization groups. 52136 (line 21) 52137* optimization dumps: Optimization info. (line 6) 52138* optimization groups: Optimization groups. 52139 (line 6) 52140* optimization info file names: Dump files and streams. 52141 (line 6) 52142* Optimization infrastructure for GIMPLE: Tree SSA. (line 6) 52143* OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 8) 52144* option specification files: Options. (line 6) 52145* optional hardware or system features: Run-time Target. (line 59) 52146* options, directory search: Including Patterns. (line 47) 52147* OPTION_DEFAULT_SPECS: Driver. (line 25) 52148* opt_mode: Machine Modes. (line 326) 52149* order of register allocation: Allocation Order. (line 6) 52150* ordered_comparison_operator: Machine-Independent Predicates. 52151 (line 115) 52152* ORDERED_EXPR: Unary and Binary Expressions. 52153 (line 6) 52154* Ordering of Patterns: Pattern Ordering. (line 6) 52155* ORIGINAL_REGNO: Special Accessors. (line 53) 52156* other register constraints: Simple Constraints. (line 171) 52157* outgoing_args_size: Stack Arguments. (line 48) 52158* OUTGOING_REGNO: Register Basics. (line 97) 52159* OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 79) 52160* output of assembler code: File Framework. (line 6) 52161* output statements: Output Statement. (line 6) 52162* output templates: Output Template. (line 6) 52163* output_asm_insn: Output Statement. (line 52) 52164* OUTPUT_QUOTED_STRING: File Framework. (line 105) 52165* OVERLAPPING_REGISTER_NAMES: Instruction Output. (line 20) 52166* OVERLOAD: Functions for C++. (line 6) 52167* OVERRIDE_ABI_FORMAT: Register Arguments. (line 157) 52168* OVL_CURRENT: Functions for C++. (line 6) 52169* OVL_NEXT: Functions for C++. (line 6) 52170* p in constraint: Simple Constraints. (line 162) 52171* PAD_VARARGS_DOWN: Register Arguments. (line 238) 52172* parallel: Side Effects. (line 210) 52173* parameters, c++ abi: C++ ABI. (line 6) 52174* parameters, miscellaneous: Misc. (line 6) 52175* parameters, precompiled headers: PCH Target. (line 6) 52176* parity: Arithmetic. (line 242) 52177* parityM2 instruction pattern: Standard Names. (line 1102) 52178* PARM_BOUNDARY: Storage Layout. (line 150) 52179* PARM_DECL: Declarations. (line 6) 52180* PARSE_LDD_OUTPUT: Macros for Initialization. 52181 (line 125) 52182* pass dumps: Passes. (line 6) 52183* passes and files of the compiler: Passes. (line 6) 52184* passing arguments: Interface. (line 36) 52185* pass_duplicate_computed_gotos: Edges. (line 161) 52186* PATH_SEPARATOR: Filesystem. (line 31) 52187* PATTERN: Insns. (line 307) 52188* pattern conditions: Patterns. (line 43) 52189* pattern names: Standard Names. (line 6) 52190* Pattern Ordering: Pattern Ordering. (line 6) 52191* patterns: Patterns. (line 6) 52192* pc: Regs and Memory. (line 383) 52193* pc and attributes: Insn Lengths. (line 20) 52194* pc, RTL sharing: Sharing. (line 28) 52195* PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 357) 52196* PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 64) 52197* PC_REGNUM: Register Basics. (line 111) 52198* pc_rtx: Regs and Memory. (line 388) 52199* PDImode: Machine Modes. (line 40) 52200* peephole optimization, RTL representation: Side Effects. (line 244) 52201* peephole optimizer definitions: Peephole Definitions. 52202 (line 6) 52203* per-function data: Per-Function Data. (line 6) 52204* percent sign: Output Template. (line 6) 52205* PHI nodes: SSA. (line 31) 52206* PIC: PIC. (line 6) 52207* PIC_OFFSET_TABLE_REGNUM: PIC. (line 15) 52208* PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 25) 52209* pipeline hazard recognizer: Processor pipeline description. 52210 (line 6) 52211* pipeline hazard recognizer <1>: Processor pipeline description. 52212 (line 53) 52213* Plugins: Plugins. (line 6) 52214* plus: Arithmetic. (line 14) 52215* plus and attributes: Expressions. (line 83) 52216* plus, canonicalization of: Insn Canonicalizations. 52217 (line 27) 52218* PLUS_EXPR: Unary and Binary Expressions. 52219 (line 6) 52220* Pmode: Misc. (line 351) 52221* pmode_register_operand: Machine-Independent Predicates. 52222 (line 34) 52223* pointer: Types. (line 6) 52224* POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 76) 52225* POINTER_DIFF_EXPR: Unary and Binary Expressions. 52226 (line 6) 52227* POINTER_PLUS_EXPR: Unary and Binary Expressions. 52228 (line 6) 52229* POINTER_SIZE: Storage Layout. (line 70) 52230* POINTER_TYPE: Types. (line 6) 52231* polynomial integers: poly_int. (line 6) 52232* poly_int: poly_int. (line 6) 52233* poly_int, invariant range: Overview of poly_int. 52234 (line 31) 52235* poly_int, main typedefs: Overview of poly_int. 52236 (line 46) 52237* poly_int, runtime value: Overview of poly_int. 52238 (line 6) 52239* poly_int, template parameters: Overview of poly_int. 52240 (line 24) 52241* poly_int, use in target-independent code: Consequences of using poly_int. 52242 (line 32) 52243* poly_int, use in target-specific code: Consequences of using poly_int. 52244 (line 40) 52245* POLY_INT_CST: Constant expressions. 52246 (line 6) 52247* popcount: Arithmetic. (line 238) 52248* popcountM2 instruction pattern: Standard Names. (line 1090) 52249* pops_args: Function Entry. (line 111) 52250* pop_operand: Machine-Independent Predicates. 52251 (line 87) 52252* portability: Portability. (line 6) 52253* position independent code: PIC. (line 6) 52254* POSTDECREMENT_EXPR: Unary and Binary Expressions. 52255 (line 6) 52256* POSTINCREMENT_EXPR: Unary and Binary Expressions. 52257 (line 6) 52258* post_dec: Incdec. (line 25) 52259* post_inc: Incdec. (line 30) 52260* POST_LINK_SPEC: Driver. (line 236) 52261* post_modify: Incdec. (line 33) 52262* post_order_compute, inverted_post_order_compute, walk_dominator_tree: Basic Blocks. 52263 (line 34) 52264* POWI_MAX_MULTS: Misc. (line 986) 52265* powM3 instruction pattern: Standard Names. (line 936) 52266* pragma: Misc. (line 409) 52267* PREDECREMENT_EXPR: Unary and Binary Expressions. 52268 (line 6) 52269* predefined macros: Run-time Target. (line 6) 52270* predicates: Predicates. (line 6) 52271* predicates and machine modes: Predicates. (line 31) 52272* predication: Conditional Execution. 52273 (line 6) 52274* predict.def: Profile information. 52275 (line 24) 52276* PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 40) 52277* PREFERRED_RELOAD_CLASS: Register Classes. (line 249) 52278* PREFERRED_STACK_BOUNDARY: Storage Layout. (line 164) 52279* prefetch: Side Effects. (line 324) 52280* prefetch and /v: Flags. (line 92) 52281* prefetch instruction pattern: Standard Names. (line 1962) 52282* PREFETCH_SCHEDULE_BARRIER_P: Flags. (line 92) 52283* PREINCREMENT_EXPR: Unary and Binary Expressions. 52284 (line 6) 52285* presence_set: Processor pipeline description. 52286 (line 223) 52287* preserving SSA form: SSA. (line 74) 52288* pretend_args_size: Function Entry. (line 117) 52289* prev_active_insn: define_peephole. (line 60) 52290* PREV_INSN: Insns. (line 26) 52291* pre_dec: Incdec. (line 8) 52292* PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 126) 52293* pre_inc: Incdec. (line 22) 52294* pre_modify: Incdec. (line 52) 52295* PRINT_OPERAND: Instruction Output. (line 95) 52296* PRINT_OPERAND_ADDRESS: Instruction Output. (line 122) 52297* PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 115) 52298* probe_stack instruction pattern: Standard Names. (line 1812) 52299* probe_stack_address instruction pattern: Standard Names. (line 1805) 52300* processor functional units: Processor pipeline description. 52301 (line 6) 52302* processor functional units <1>: Processor pipeline description. 52303 (line 68) 52304* processor pipeline description: Processor pipeline description. 52305 (line 6) 52306* product: Arithmetic. (line 93) 52307* profile feedback: Profile information. 52308 (line 14) 52309* profile representation: Profile information. 52310 (line 6) 52311* PROFILE_BEFORE_PROLOGUE: Profiling. (line 34) 52312* PROFILE_HOOK: Profiling. (line 22) 52313* profiling, code generation: Profiling. (line 6) 52314* program counter: Regs and Memory. (line 384) 52315* prologue: Function Entry. (line 6) 52316* prologue instruction pattern: Standard Names. (line 1901) 52317* PROMOTE_MODE: Storage Layout. (line 87) 52318* pseudo registers: Regs and Memory. (line 9) 52319* PSImode: Machine Modes. (line 32) 52320* PTRDIFF_TYPE: Type Layout. (line 157) 52321* purge_dead_edges: Edges. (line 103) 52322* purge_dead_edges <1>: Maintaining the CFG. 52323 (line 81) 52324* push address instruction: Simple Constraints. (line 162) 52325* pushM1 instruction pattern: Standard Names. (line 403) 52326* PUSH_ARGS: Stack Arguments. (line 17) 52327* PUSH_ARGS_REVERSED: Stack Arguments. (line 25) 52328* push_operand: Machine-Independent Predicates. 52329 (line 80) 52330* push_reload: Addressing Modes. (line 176) 52331* PUSH_ROUNDING: Stack Arguments. (line 31) 52332* PUT_CODE: RTL Objects. (line 47) 52333* PUT_MODE: Machine Modes. (line 384) 52334* PUT_REG_NOTE_KIND: Insns. (line 369) 52335* QCmode: Machine Modes. (line 199) 52336* QFmode: Machine Modes. (line 57) 52337* QImode: Machine Modes. (line 25) 52338* QImode, in insn: Insns. (line 291) 52339* QQmode: Machine Modes. (line 106) 52340* qualified type: Types. (line 6) 52341* qualified type <1>: Types for C++. (line 6) 52342* querying function unit reservations: Processor pipeline description. 52343 (line 90) 52344* question mark: Multi-Alternative. (line 42) 52345* quotient: Arithmetic. (line 116) 52346* r in constraint: Simple Constraints. (line 64) 52347* RDIV_EXPR: Unary and Binary Expressions. 52348 (line 6) 52349* READONLY_DATA_SECTION_ASM_OP: Sections. (line 62) 52350* real operands: SSA Operands. (line 6) 52351* REALPART_EXPR: Unary and Binary Expressions. 52352 (line 6) 52353* REAL_CST: Constant expressions. 52354 (line 6) 52355* REAL_LIBGCC_SPEC: Driver. (line 124) 52356* REAL_NM_FILE_NAME: Macros for Initialization. 52357 (line 105) 52358* REAL_TYPE: Types. (line 6) 52359* REAL_VALUE_ABS: Floating Point. (line 58) 52360* REAL_VALUE_ATOF: Floating Point. (line 39) 52361* REAL_VALUE_FIX: Floating Point. (line 31) 52362* REAL_VALUE_ISINF: Floating Point. (line 49) 52363* REAL_VALUE_ISNAN: Floating Point. (line 52) 52364* REAL_VALUE_NEGATE: Floating Point. (line 55) 52365* REAL_VALUE_NEGATIVE: Floating Point. (line 46) 52366* REAL_VALUE_TO_TARGET_DECIMAL128: Data Output. (line 147) 52367* REAL_VALUE_TO_TARGET_DECIMAL32: Data Output. (line 145) 52368* REAL_VALUE_TO_TARGET_DECIMAL64: Data Output. (line 146) 52369* REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 143) 52370* REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 144) 52371* REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 142) 52372* REAL_VALUE_TYPE: Floating Point. (line 25) 52373* REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 34) 52374* recognizing insns: RTL Template. (line 6) 52375* recog_data.operand: Instruction Output. (line 54) 52376* RECORD_TYPE: Types. (line 6) 52377* RECORD_TYPE <1>: Classes. (line 6) 52378* redirect_edge_and_branch: Profile information. 52379 (line 71) 52380* redirect_edge_and_branch, redirect_jump: Maintaining the CFG. 52381 (line 89) 52382* reduc_and_scal_M instruction pattern: Standard Names. (line 510) 52383* reduc_ior_scal_M instruction pattern: Standard Names. (line 511) 52384* reduc_plus_scal_M instruction pattern: Standard Names. (line 505) 52385* reduc_smax_scal_M instruction pattern: Standard Names. (line 495) 52386* reduc_smin_scal_M instruction pattern: Standard Names. (line 495) 52387* reduc_umax_scal_M instruction pattern: Standard Names. (line 500) 52388* reduc_umin_scal_M instruction pattern: Standard Names. (line 500) 52389* reduc_xor_scal_M instruction pattern: Standard Names. (line 512) 52390* reference: Types. (line 6) 52391* REFERENCE_TYPE: Types. (line 6) 52392* reg: Regs and Memory. (line 9) 52393* reg and /f: Flags. (line 102) 52394* reg and /i: Flags. (line 97) 52395* reg and /v: Flags. (line 106) 52396* reg, RTL sharing: Sharing. (line 17) 52397* register allocation order: Allocation Order. (line 6) 52398* register class definitions: Register Classes. (line 6) 52399* register class preference constraints: Class Preferences. (line 6) 52400* register pairs: Values in Registers. 52401 (line 65) 52402* Register Transfer Language (RTL): RTL. (line 6) 52403* register usage: Registers. (line 6) 52404* registers arguments: Register Arguments. (line 6) 52405* registers in constraints: Simple Constraints. (line 64) 52406* REGISTER_MOVE_COST: Costs. (line 9) 52407* REGISTER_NAMES: Instruction Output. (line 8) 52408* register_operand: Machine-Independent Predicates. 52409 (line 29) 52410* REGISTER_PREFIX: Instruction Output. (line 150) 52411* REGISTER_TARGET_PRAGMAS: Misc. (line 409) 52412* REGMODE_NATURAL_SIZE: Regs and Memory. (line 191) 52413* REGMODE_NATURAL_SIZE <1>: Regs and Memory. (line 268) 52414* REGMODE_NATURAL_SIZE <2>: Values in Registers. 52415 (line 46) 52416* REGNO_MODE_CODE_OK_FOR_BASE_P: Register Classes. (line 172) 52417* REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 150) 52418* REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 160) 52419* REGNO_OK_FOR_BASE_P: Register Classes. (line 146) 52420* REGNO_OK_FOR_INDEX_P: Register Classes. (line 186) 52421* REGNO_REG_CLASS: Register Classes. (line 105) 52422* regs_ever_live: Function Entry. (line 29) 52423* regular expressions: Processor pipeline description. 52424 (line 6) 52425* regular expressions <1>: Processor pipeline description. 52426 (line 105) 52427* REG_ALLOC_ORDER: Allocation Order. (line 8) 52428* REG_BR_PRED: Insns. (line 541) 52429* REG_BR_PROB: Insns. (line 533) 52430* REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information. 52431 (line 82) 52432* REG_BR_PROB_BASE, EDGE_FREQUENCY: Profile information. 52433 (line 52) 52434* REG_CALL_NOCF_CHECK: Insns. (line 557) 52435* REG_CC_SETTER: Insns. (line 505) 52436* REG_CC_USER: Insns. (line 505) 52437* reg_class_contents: Register Basics. (line 63) 52438* REG_CLASS_CONTENTS: Register Classes. (line 91) 52439* reg_class_for_constraint: C Constraint Interface. 52440 (line 48) 52441* REG_CLASS_NAMES: Register Classes. (line 86) 52442* REG_DEAD: Insns. (line 380) 52443* REG_DEAD, REG_UNUSED: Liveness information. 52444 (line 32) 52445* REG_DEP_ANTI: Insns. (line 527) 52446* REG_DEP_OUTPUT: Insns. (line 523) 52447* REG_DEP_TRUE: Insns. (line 520) 52448* REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 109) 52449* REG_EQUAL: Insns. (line 434) 52450* REG_EQUIV: Insns. (line 434) 52451* REG_EXPR: Special Accessors. (line 58) 52452* REG_FRAME_RELATED_EXPR: Insns. (line 547) 52453* REG_FUNCTION_VALUE_P: Flags. (line 97) 52454* REG_INC: Insns. (line 396) 52455* reg_label and /v: Flags. (line 54) 52456* REG_LABEL_OPERAND: Insns. (line 410) 52457* REG_LABEL_TARGET: Insns. (line 419) 52458* reg_names: Register Basics. (line 63) 52459* reg_names <1>: Instruction Output. (line 107) 52460* REG_NONNEG: Insns. (line 402) 52461* REG_NOTES: Insns. (line 344) 52462* REG_NOTE_KIND: Insns. (line 369) 52463* REG_OFFSET: Special Accessors. (line 62) 52464* REG_OK_STRICT: Addressing Modes. (line 99) 52465* REG_PARM_STACK_SPACE: Stack Arguments. (line 58) 52466* REG_PARM_STACK_SPACE, and TARGET_FUNCTION_ARG: Register Arguments. 52467 (line 56) 52468* REG_POINTER: Flags. (line 102) 52469* REG_SETJMP: Insns. (line 428) 52470* REG_UNUSED: Insns. (line 389) 52471* REG_USERVAR_P: Flags. (line 106) 52472* REG_VALUE_IN_UNWIND_CONTEXT: Frame Registers. (line 156) 52473* REG_WORDS_BIG_ENDIAN: Storage Layout. (line 35) 52474* relative costs: Costs. (line 6) 52475* RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 266) 52476* reloading: RTL passes. (line 170) 52477* reload_completed: Standard Names. (line 1600) 52478* reload_in instruction pattern: Standard Names. (line 98) 52479* reload_in_progress: Standard Names. (line 57) 52480* reload_out instruction pattern: Standard Names. (line 98) 52481* remainder: Arithmetic. (line 136) 52482* remainderM3 instruction pattern: Standard Names. (line 790) 52483* reorder: GTY Options. (line 175) 52484* representation of RTL: RTL. (line 6) 52485* reservation delays: Processor pipeline description. 52486 (line 6) 52487* restore_stack_block instruction pattern: Standard Names. (line 1726) 52488* restore_stack_function instruction pattern: Standard Names. 52489 (line 1726) 52490* restore_stack_nonlocal instruction pattern: Standard Names. 52491 (line 1726) 52492* rest_of_decl_compilation: Parsing pass. (line 51) 52493* rest_of_type_compilation: Parsing pass. (line 51) 52494* RESULT_DECL: Declarations. (line 6) 52495* return: Side Effects. (line 72) 52496* return instruction pattern: Standard Names. (line 1574) 52497* return values in registers: Scalar Return. (line 6) 52498* returning aggregate values: Aggregate Return. (line 6) 52499* returning structures and unions: Interface. (line 10) 52500* RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 64) 52501* RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 127) 52502* RETURN_ADDR_OFFSET: Exception Handling. (line 59) 52503* RETURN_ADDR_RTX: Frame Layout. (line 116) 52504* RETURN_EXPR: Statements for C++. (line 6) 52505* RETURN_STMT: Statements for C++. (line 6) 52506* return_val: Flags. (line 283) 52507* return_val, in call_insn: Flags. (line 120) 52508* return_val, in reg: Flags. (line 97) 52509* return_val, in symbol_ref: Flags. (line 216) 52510* reverse probability: Profile information. 52511 (line 66) 52512* REVERSE_CONDITION: MODE_CC Condition Codes. 52513 (line 92) 52514* REVERSIBLE_CC_MODE: MODE_CC Condition Codes. 52515 (line 77) 52516* right rotate: Arithmetic. (line 195) 52517* right shift: Arithmetic. (line 190) 52518* rintM2 instruction pattern: Standard Names. (line 996) 52519* RISC: Processor pipeline description. 52520 (line 6) 52521* RISC <1>: Processor pipeline description. 52522 (line 223) 52523* roots, marking: GGC Roots. (line 6) 52524* rotate: Arithmetic. (line 195) 52525* rotate <1>: Arithmetic. (line 195) 52526* rotatert: Arithmetic. (line 195) 52527* rotlM3 instruction pattern: Standard Names. (line 742) 52528* rotrM3 instruction pattern: Standard Names. (line 742) 52529* roundM2 instruction pattern: Standard Names. (line 969) 52530* ROUND_DIV_EXPR: Unary and Binary Expressions. 52531 (line 6) 52532* ROUND_MOD_EXPR: Unary and Binary Expressions. 52533 (line 6) 52534* ROUND_TYPE_ALIGN: Storage Layout. (line 454) 52535* RSHIFT_EXPR: Unary and Binary Expressions. 52536 (line 6) 52537* rsqrtM2 instruction pattern: Standard Names. (line 770) 52538* RTL addition: Arithmetic. (line 14) 52539* RTL addition with signed saturation: Arithmetic. (line 14) 52540* RTL addition with unsigned saturation: Arithmetic. (line 14) 52541* RTL classes: RTL Classes. (line 6) 52542* RTL comparison: Arithmetic. (line 46) 52543* RTL comparison operations: Comparisons. (line 6) 52544* RTL constant expression types: Constants. (line 6) 52545* RTL constants: Constants. (line 6) 52546* RTL declarations: RTL Declarations. (line 6) 52547* RTL difference: Arithmetic. (line 38) 52548* RTL expression: RTL Objects. (line 6) 52549* RTL expressions for arithmetic: Arithmetic. (line 6) 52550* RTL format: RTL Classes. (line 72) 52551* RTL format characters: RTL Classes. (line 77) 52552* RTL function-call insns: Calls. (line 6) 52553* RTL insn template: RTL Template. (line 6) 52554* RTL integers: RTL Objects. (line 6) 52555* RTL memory expressions: Regs and Memory. (line 6) 52556* RTL object types: RTL Objects. (line 6) 52557* RTL postdecrement: Incdec. (line 6) 52558* RTL postincrement: Incdec. (line 6) 52559* RTL predecrement: Incdec. (line 6) 52560* RTL preincrement: Incdec. (line 6) 52561* RTL register expressions: Regs and Memory. (line 6) 52562* RTL representation: RTL. (line 6) 52563* RTL side effect expressions: Side Effects. (line 6) 52564* RTL strings: RTL Objects. (line 6) 52565* RTL structure sharing assumptions: Sharing. (line 6) 52566* RTL subtraction: Arithmetic. (line 38) 52567* RTL subtraction with signed saturation: Arithmetic. (line 38) 52568* RTL subtraction with unsigned saturation: Arithmetic. (line 38) 52569* RTL sum: Arithmetic. (line 14) 52570* RTL vectors: RTL Objects. (line 6) 52571* RTL_CONST_CALL_P: Flags. (line 115) 52572* RTL_CONST_OR_PURE_CALL_P: Flags. (line 125) 52573* RTL_LOOPING_CONST_OR_PURE_CALL_P: Flags. (line 129) 52574* RTL_PURE_CALL_P: Flags. (line 120) 52575* RTX (See RTL): RTL Objects. (line 6) 52576* RTX codes, classes of: RTL Classes. (line 6) 52577* RTX_FRAME_RELATED_P: Flags. (line 135) 52578* run-time conventions: Interface. (line 6) 52579* run-time target specification: Run-time Target. (line 6) 52580* s in constraint: Simple Constraints. (line 100) 52581* SAD_EXPR: Vectors. (line 6) 52582* same_type_p: Types. (line 86) 52583* SAmode: Machine Modes. (line 150) 52584* satfractMN2 instruction pattern: Standard Names. (line 1300) 52585* satfractunsMN2 instruction pattern: Standard Names. (line 1313) 52586* satisfies_constraint_M: C Constraint Interface. 52587 (line 36) 52588* sat_fract: Conversions. (line 90) 52589* SAVE_EXPR: Unary and Binary Expressions. 52590 (line 6) 52591* save_stack_block instruction pattern: Standard Names. (line 1726) 52592* save_stack_function instruction pattern: Standard Names. (line 1726) 52593* save_stack_nonlocal instruction pattern: Standard Names. (line 1726) 52594* SBSS_SECTION_ASM_OP: Sections. (line 75) 52595* Scalar evolutions: Scalar evolutions. (line 6) 52596* scalars, returned as values: Scalar Return. (line 6) 52597* scalar_float_mode: Machine Modes. (line 297) 52598* scalar_int_mode: Machine Modes. (line 294) 52599* scalar_mode: Machine Modes. (line 300) 52600* scalbM3 instruction pattern: Standard Names. (line 797) 52601* scatter_storeM instruction pattern: Standard Names. (line 254) 52602* SCHED_GROUP_P: Flags. (line 162) 52603* SCmode: Machine Modes. (line 199) 52604* scratch: Regs and Memory. (line 320) 52605* scratch operands: Regs and Memory. (line 320) 52606* scratch, RTL sharing: Sharing. (line 38) 52607* scratch_operand: Machine-Independent Predicates. 52608 (line 49) 52609* SDATA_SECTION_ASM_OP: Sections. (line 57) 52610* SDmode: Machine Modes. (line 88) 52611* sdot_prodM instruction pattern: Standard Names. (line 539) 52612* search options: Including Patterns. (line 47) 52613* SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 391) 52614* SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 457) 52615* SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 392) 52616* SECONDARY_RELOAD_CLASS: Register Classes. (line 390) 52617* SELECT_CC_MODE: MODE_CC Condition Codes. 52618 (line 6) 52619* sequence: Side Effects. (line 259) 52620* Sequence iterators: Sequence iterators. (line 6) 52621* set: Side Effects. (line 15) 52622* set and /f: Flags. (line 135) 52623* setmemM instruction pattern: Standard Names. (line 1164) 52624* SETUP_FRAME_ADDRESSES: Frame Layout. (line 94) 52625* SET_ASM_OP: Label Output. (line 451) 52626* SET_ASM_OP <1>: Label Output. (line 462) 52627* set_attr: Tagging Insns. (line 31) 52628* set_attr_alternative: Tagging Insns. (line 49) 52629* set_bb_seq: GIMPLE sequences. (line 75) 52630* SET_DEST: Side Effects. (line 69) 52631* SET_IS_RETURN_P: Flags. (line 171) 52632* SET_LABEL_KIND: Insns. (line 146) 52633* set_optab_libfunc: Library Calls. (line 15) 52634* SET_RATIO: Costs. (line 237) 52635* SET_SRC: Side Effects. (line 69) 52636* set_thread_pointerMODE instruction pattern: Standard Names. 52637 (line 2285) 52638* SET_TYPE_STRUCTURAL_EQUALITY: Types. (line 6) 52639* SET_TYPE_STRUCTURAL_EQUALITY <1>: Types. (line 81) 52640* SFmode: Machine Modes. (line 69) 52641* sharing of RTL components: Sharing. (line 6) 52642* shift: Arithmetic. (line 173) 52643* SHIFT_COUNT_TRUNCATED: Misc. (line 134) 52644* SHLIB_SUFFIX: Macros for Initialization. 52645 (line 133) 52646* SHORT_ACCUM_TYPE_SIZE: Type Layout. (line 82) 52647* SHORT_FRACT_TYPE_SIZE: Type Layout. (line 62) 52648* SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 108) 52649* SHORT_TYPE_SIZE: Type Layout. (line 15) 52650* shrink-wrapping separate components: Shrink-wrapping separate components. 52651 (line 6) 52652* sibcall_epilogue instruction pattern: Standard Names. (line 1933) 52653* sibling call: Edges. (line 121) 52654* SIBLING_CALL_P: Flags. (line 175) 52655* signed division: Arithmetic. (line 116) 52656* signed division with signed saturation: Arithmetic. (line 116) 52657* signed maximum: Arithmetic. (line 141) 52658* signed minimum: Arithmetic. (line 141) 52659* significandM2 instruction pattern: Standard Names. (line 929) 52660* sign_extend: Conversions. (line 23) 52661* sign_extract: Bit-Fields. (line 8) 52662* sign_extract, canonicalization of: Insn Canonicalizations. 52663 (line 103) 52664* SIG_ATOMIC_TYPE: Type Layout. (line 208) 52665* SImode: Machine Modes. (line 37) 52666* simple constraints: Simple Constraints. (line 6) 52667* simple_return: Side Effects. (line 86) 52668* simple_return instruction pattern: Standard Names. (line 1589) 52669* sincosM3 instruction pattern: Standard Names. (line 825) 52670* sinM2 instruction pattern: Standard Names. (line 819) 52671* SIZETYPE: Type Layout. (line 147) 52672* SIZE_ASM_OP: Label Output. (line 33) 52673* SIZE_TYPE: Type Layout. (line 131) 52674* skip: GTY Options. (line 76) 52675* SLOW_BYTE_ACCESS: Costs. (line 117) 52676* smax: Arithmetic. (line 141) 52677* smin: Arithmetic. (line 141) 52678* sms, swing, software pipelining: RTL passes. (line 123) 52679* smulM3_highpart instruction pattern: Standard Names. (line 655) 52680* soft float library: Soft float library routines. 52681 (line 6) 52682* special: GTY Options. (line 238) 52683* special predicates: Predicates. (line 31) 52684* SPECS: Target Fragment. (line 194) 52685* speed of instructions: Costs. (line 6) 52686* splitting instructions: Insn Splitting. (line 6) 52687* split_block: Maintaining the CFG. 52688 (line 96) 52689* SQmode: Machine Modes. (line 114) 52690* sqrt: Arithmetic. (line 206) 52691* sqrtM2 instruction pattern: Standard Names. (line 764) 52692* square root: Arithmetic. (line 206) 52693* SSA: SSA. (line 6) 52694* ssaddM3 instruction pattern: Standard Names. (line 416) 52695* ssadM instruction pattern: Standard Names. (line 548) 52696* ssashlM3 instruction pattern: Standard Names. (line 730) 52697* SSA_NAME_DEF_STMT: SSA. (line 184) 52698* SSA_NAME_VERSION: SSA. (line 189) 52699* ssdivM3 instruction pattern: Standard Names. (line 416) 52700* ssmaddMN4 instruction pattern: Standard Names. (line 678) 52701* ssmsubMN4 instruction pattern: Standard Names. (line 702) 52702* ssmulM3 instruction pattern: Standard Names. (line 416) 52703* ssnegM2 instruction pattern: Standard Names. (line 754) 52704* sssubM3 instruction pattern: Standard Names. (line 416) 52705* ss_abs: Arithmetic. (line 200) 52706* ss_ashift: Arithmetic. (line 173) 52707* ss_div: Arithmetic. (line 116) 52708* ss_minus: Arithmetic. (line 38) 52709* ss_mult: Arithmetic. (line 93) 52710* ss_neg: Arithmetic. (line 82) 52711* ss_plus: Arithmetic. (line 14) 52712* ss_truncate: Conversions. (line 43) 52713* stack arguments: Stack Arguments. (line 6) 52714* stack frame layout: Frame Layout. (line 6) 52715* stack smashing protection: Stack Smashing Protection. 52716 (line 6) 52717* STACK_ALIGNMENT_NEEDED: Frame Layout. (line 41) 52718* STACK_BOUNDARY: Storage Layout. (line 156) 52719* STACK_CHECK_BUILTIN: Stack Checking. (line 31) 52720* STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 83) 52721* STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 74) 52722* STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 90) 52723* STACK_CHECK_MOVING_SP: Stack Checking. (line 53) 52724* STACK_CHECK_PROBE_INTERVAL_EXP: Stack Checking. (line 45) 52725* STACK_CHECK_PROTECT: Stack Checking. (line 62) 52726* STACK_CHECK_STATIC_BUILTIN: Stack Checking. (line 38) 52727* STACK_DYNAMIC_OFFSET: Frame Layout. (line 67) 52728* STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory. 52729 (line 83) 52730* STACK_GROWS_DOWNWARD: Frame Layout. (line 8) 52731* STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 89) 52732* STACK_POINTER_OFFSET: Frame Layout. (line 51) 52733* STACK_POINTER_OFFSET and virtual registers: Regs and Memory. 52734 (line 93) 52735* STACK_POINTER_REGNUM: Frame Registers. (line 8) 52736* STACK_POINTER_REGNUM and virtual registers: Regs and Memory. 52737 (line 83) 52738* stack_pointer_rtx: Frame Registers. (line 104) 52739* stack_protect_set instruction pattern: Standard Names. (line 2295) 52740* stack_protect_test instruction pattern: Standard Names. (line 2305) 52741* STACK_PUSH_CODE: Frame Layout. (line 12) 52742* STACK_REGS: Stack Registers. (line 19) 52743* STACK_REG_COVER_CLASS: Stack Registers. (line 22) 52744* STACK_SAVEAREA_MODE: Storage Layout. (line 470) 52745* STACK_SIZE_MODE: Storage Layout. (line 481) 52746* STACK_SLOT_ALIGNMENT: Storage Layout. (line 302) 52747* standard pattern names: Standard Names. (line 6) 52748* STANDARD_STARTFILE_PREFIX: Driver. (line 278) 52749* STANDARD_STARTFILE_PREFIX_1: Driver. (line 285) 52750* STANDARD_STARTFILE_PREFIX_2: Driver. (line 292) 52751* STARTFILE_SPEC: Driver. (line 147) 52752* Statement and operand traversals: Statement and operand traversals. 52753 (line 6) 52754* Statement Sequences: Statement Sequences. 52755 (line 6) 52756* Statements: Statements. (line 6) 52757* statements: Function Properties. 52758 (line 6) 52759* statements <1>: Statements for C++. (line 6) 52760* Static profile estimation: Profile information. 52761 (line 24) 52762* static single assignment: SSA. (line 6) 52763* STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 77) 52764* STATIC_CHAIN_REGNUM: Frame Registers. (line 76) 52765* stdarg.h and register arguments: Register Arguments. (line 51) 52766* STDC_0_IN_SYSTEM_HEADERS: Misc. (line 372) 52767* STMT_EXPR: Unary and Binary Expressions. 52768 (line 6) 52769* STMT_IS_FULL_EXPR_P: Statements for C++. (line 22) 52770* storage layout: Storage Layout. (line 6) 52771* STORE_FLAG_VALUE: Misc. (line 223) 52772* STORE_MAX_PIECES: Costs. (line 215) 52773* store_multiple instruction pattern: Standard Names. (line 159) 52774* strcpy: Storage Layout. (line 255) 52775* STRICT_ALIGNMENT: Storage Layout. (line 352) 52776* strict_low_part: RTL Declarations. (line 9) 52777* strict_memory_address_p: Addressing Modes. (line 186) 52778* STRING_CST: Constant expressions. 52779 (line 6) 52780* STRING_POOL_ADDRESS_P: Flags. (line 179) 52781* strlenM instruction pattern: Standard Names. (line 1235) 52782* structure value address: Aggregate Return. (line 6) 52783* structures, returning: Interface. (line 10) 52784* STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 344) 52785* subM3 instruction pattern: Standard Names. (line 416) 52786* SUBOBJECT: Statements for C++. (line 6) 52787* SUBOBJECT_CLEANUP: Statements for C++. (line 6) 52788* subreg: Regs and Memory. (line 97) 52789* subreg and /s: Flags. (line 201) 52790* subreg and /u: Flags. (line 194) 52791* subreg and /u and /v: Flags. (line 184) 52792* subreg, in strict_low_part: RTL Declarations. (line 9) 52793* SUBREG_BYTE: Regs and Memory. (line 311) 52794* SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 184) 52795* SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 194) 52796* SUBREG_PROMOTED_VAR_P: Flags. (line 201) 52797* SUBREG_REG: Regs and Memory. (line 311) 52798* subst iterators in .md files: Subst Iterators. (line 6) 52799* subvM4 instruction pattern: Standard Names. (line 432) 52800* SUCCESS_EXIT_CODE: Host Misc. (line 12) 52801* SUPPORTS_INIT_PRIORITY: Macros for Initialization. 52802 (line 57) 52803* SUPPORTS_ONE_ONLY: Label Output. (line 290) 52804* SUPPORTS_WEAK: Label Output. (line 264) 52805* SWITCHABLE_TARGET: Run-time Target. (line 164) 52806* SWITCH_BODY: Statements for C++. (line 6) 52807* SWITCH_COND: Statements for C++. (line 6) 52808* SWITCH_STMT: Statements for C++. (line 6) 52809* symbolic label: Sharing. (line 20) 52810* SYMBOL_FLAG_ANCHOR: Special Accessors. (line 117) 52811* SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 99) 52812* SYMBOL_FLAG_FUNCTION: Special Accessors. (line 92) 52813* SYMBOL_FLAG_HAS_BLOCK_INFO: Special Accessors. (line 113) 52814* SYMBOL_FLAG_LOCAL: Special Accessors. (line 95) 52815* SYMBOL_FLAG_SMALL: Special Accessors. (line 104) 52816* SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 108) 52817* symbol_ref: Constants. (line 189) 52818* symbol_ref and /f: Flags. (line 179) 52819* symbol_ref and /i: Flags. (line 216) 52820* symbol_ref and /u: Flags. (line 19) 52821* symbol_ref and /v: Flags. (line 220) 52822* symbol_ref, RTL sharing: Sharing. (line 20) 52823* SYMBOL_REF_ANCHOR_P: Special Accessors. (line 117) 52824* SYMBOL_REF_BLOCK: Special Accessors. (line 130) 52825* SYMBOL_REF_BLOCK_OFFSET: Special Accessors. (line 135) 52826* SYMBOL_REF_CONSTANT: Special Accessors. (line 78) 52827* SYMBOL_REF_DATA: Special Accessors. (line 82) 52828* SYMBOL_REF_DECL: Special Accessors. (line 67) 52829* SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 99) 52830* SYMBOL_REF_FLAG: Flags. (line 220) 52831* SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 282) 52832* SYMBOL_REF_FLAGS: Special Accessors. (line 86) 52833* SYMBOL_REF_FUNCTION_P: Special Accessors. (line 92) 52834* SYMBOL_REF_HAS_BLOCK_INFO_P: Special Accessors. (line 113) 52835* SYMBOL_REF_LOCAL_P: Special Accessors. (line 95) 52836* SYMBOL_REF_SMALL_P: Special Accessors. (line 104) 52837* SYMBOL_REF_TLS_MODEL: Special Accessors. (line 108) 52838* SYMBOL_REF_USED: Flags. (line 211) 52839* SYMBOL_REF_WEAK: Flags. (line 216) 52840* sync_addMODE instruction pattern: Standard Names. (line 2040) 52841* sync_andMODE instruction pattern: Standard Names. (line 2040) 52842* sync_compare_and_swapMODE instruction pattern: Standard Names. 52843 (line 2000) 52844* sync_iorMODE instruction pattern: Standard Names. (line 2040) 52845* sync_lock_releaseMODE instruction pattern: Standard Names. (line 2105) 52846* sync_lock_test_and_setMODE instruction pattern: Standard Names. 52847 (line 2079) 52848* sync_nandMODE instruction pattern: Standard Names. (line 2040) 52849* sync_new_addMODE instruction pattern: Standard Names. (line 2072) 52850* sync_new_andMODE instruction pattern: Standard Names. (line 2072) 52851* sync_new_iorMODE instruction pattern: Standard Names. (line 2072) 52852* sync_new_nandMODE instruction pattern: Standard Names. (line 2072) 52853* sync_new_subMODE instruction pattern: Standard Names. (line 2072) 52854* sync_new_xorMODE instruction pattern: Standard Names. (line 2072) 52855* sync_old_addMODE instruction pattern: Standard Names. (line 2055) 52856* sync_old_andMODE instruction pattern: Standard Names. (line 2055) 52857* sync_old_iorMODE instruction pattern: Standard Names. (line 2055) 52858* sync_old_nandMODE instruction pattern: Standard Names. (line 2055) 52859* sync_old_subMODE instruction pattern: Standard Names. (line 2055) 52860* sync_old_xorMODE instruction pattern: Standard Names. (line 2055) 52861* sync_subMODE instruction pattern: Standard Names. (line 2040) 52862* sync_xorMODE instruction pattern: Standard Names. (line 2040) 52863* SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 176) 52864* SYSROOT_SUFFIX_SPEC: Driver. (line 171) 52865* t-TARGET: Target Fragment. (line 6) 52866* table jump: Basic Blocks. (line 67) 52867* tablejump instruction pattern: Standard Names. (line 1662) 52868* tag: GTY Options. (line 90) 52869* tagging insns: Tagging Insns. (line 6) 52870* tail calls: Tail Calls. (line 6) 52871* TAmode: Machine Modes. (line 158) 52872* tanM2 instruction pattern: Standard Names. (line 836) 52873* target attributes: Target Attributes. (line 6) 52874* target description macros: Target Macros. (line 6) 52875* target functions: Target Structure. (line 6) 52876* target hooks: Target Structure. (line 6) 52877* target makefile fragment: Target Fragment. (line 6) 52878* target specifications: Run-time Target. (line 6) 52879* targetm: Target Structure. (line 6) 52880* targets, makefile: Makefile. (line 6) 52881* TARGET_ABSOLUTE_BIGGEST_ALIGNMENT: Storage Layout. (line 185) 52882* TARGET_ADDITIONAL_ALLOCNO_CLASS_P: Register Classes. (line 639) 52883* TARGET_ADDRESS_COST: Costs. (line 344) 52884* TARGET_ADDR_SPACE_ADDRESS_MODE: Named Address Spaces. 52885 (line 42) 52886* TARGET_ADDR_SPACE_CONVERT: Named Address Spaces. 52887 (line 89) 52888* TARGET_ADDR_SPACE_DEBUG: Named Address Spaces. 52889 (line 99) 52890* TARGET_ADDR_SPACE_DIAGNOSE_USAGE: Named Address Spaces. 52891 (line 103) 52892* TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P: Named Address Spaces. 52893 (line 59) 52894* TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS: Named Address Spaces. 52895 (line 67) 52896* TARGET_ADDR_SPACE_POINTER_MODE: Named Address Spaces. 52897 (line 36) 52898* TARGET_ADDR_SPACE_SUBSET_P: Named Address Spaces. 52899 (line 74) 52900* TARGET_ADDR_SPACE_VALID_POINTER_MODE: Named Address Spaces. 52901 (line 48) 52902* TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID: Named Address Spaces. 52903 (line 83) 52904* TARGET_ALIGN_ANON_BITFIELD: Storage Layout. (line 429) 52905* TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 832) 52906* TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS: Misc. (line 1110) 52907* TARGET_ALWAYS_STRIP_DOTDOT: Driver. (line 250) 52908* TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 99) 52909* TARGET_ARM_EABI_UNWINDER: Exception Region Output. 52910 (line 133) 52911* TARGET_ARRAY_MODE: Register Arguments. (line 349) 52912* TARGET_ARRAY_MODE_SUPPORTED_P: Register Arguments. (line 364) 52913* TARGET_ASAN_SHADOW_OFFSET: Misc. (line 1138) 52914* TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 9) 52915* TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 7) 52916* TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 8) 52917* TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 10) 52918* TARGET_ASM_ASSEMBLE_UNDEFINED_DECL: Label Output. (line 231) 52919* TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 301) 52920* TARGET_ASM_BYTE_OP: Data Output. (line 6) 52921* TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 209) 52922* TARGET_ASM_CLOSE_PAREN: Data Output. (line 133) 52923* TARGET_ASM_CODE_END: File Framework. (line 57) 52924* TARGET_ASM_CONSTRUCTOR: Macros for Initialization. 52925 (line 68) 52926* TARGET_ASM_DECLARE_CONSTANT_NAME: Label Output. (line 177) 52927* TARGET_ASM_DECL_END: Data Output. (line 38) 52928* TARGET_ASM_DESTRUCTOR: Macros for Initialization. 52929 (line 82) 52930* TARGET_ASM_ELF_FLAGS_NUMERIC: File Framework. (line 120) 52931* TARGET_ASM_EMIT_EXCEPT_PERSONALITY: Dispatch Tables. (line 80) 52932* TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL: Dispatch Tables. (line 73) 52933* TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 61) 52934* TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 337) 52935* TARGET_ASM_FILE_END: File Framework. (line 35) 52936* TARGET_ASM_FILE_START: File Framework. (line 8) 52937* TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 16) 52938* TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 29) 52939* TARGET_ASM_FINAL_POSTSCAN_INSN: Instruction Output. (line 82) 52940* TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 67) 52941* TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 61) 52942* TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 73) 52943* TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 18) 52944* TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 218) 52945* TARGET_ASM_FUNCTION_SECTION: File Framework. (line 132) 52946* TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS: File Framework. 52947 (line 142) 52948* TARGET_ASM_GLOBALIZE_DECL_NAME: Label Output. (line 222) 52949* TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 213) 52950* TARGET_ASM_INIT_SECTIONS: Sections. (line 164) 52951* TARGET_ASM_INTEGER: Data Output. (line 25) 52952* TARGET_ASM_INTERNAL_LABEL: Label Output. (line 380) 52953* TARGET_ASM_JUMP_ALIGN_MAX_SKIP: Alignment Output. (line 21) 52954* TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP: Alignment Output. 52955 (line 34) 52956* TARGET_ASM_LABEL_ALIGN_MAX_SKIP: Alignment Output. (line 68) 52957* TARGET_ASM_LOOP_ALIGN_MAX_SKIP: Alignment Output. (line 53) 52958* TARGET_ASM_LTO_END: File Framework. (line 52) 52959* TARGET_ASM_LTO_START: File Framework. (line 47) 52960* TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 343) 52961* TARGET_ASM_MERGEABLE_RODATA_PREFIX: Sections. (line 226) 52962* TARGET_ASM_NAMED_SECTION: File Framework. (line 112) 52963* TARGET_ASM_OPEN_PAREN: Data Output. (line 132) 52964* TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 42) 52965* TARGET_ASM_OUTPUT_ANCHOR: Anchored Addresses. (line 42) 52966* TARGET_ASM_OUTPUT_DWARF_DTPREL: DWARF. (line 121) 52967* TARGET_ASM_OUTPUT_IDENT: File Framework. (line 99) 52968* TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 167) 52969* TARGET_ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 91) 52970* TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY: Function Entry. (line 9) 52971* TARGET_ASM_RECORD_GCC_SWITCHES: File Framework. (line 173) 52972* TARGET_ASM_RECORD_GCC_SWITCHES_SECTION: File Framework. (line 218) 52973* TARGET_ASM_RELOC_RW_MASK: Sections. (line 173) 52974* TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 235) 52975* TARGET_ASM_SELECT_SECTION: Sections. (line 184) 52976* TARGET_ASM_TM_CLONE_TABLE_SECTION: Sections. (line 231) 52977* TARGET_ASM_TRAMPOLINE_TEMPLATE: Trampolines. (line 28) 52978* TARGET_ASM_TTYPE: Exception Region Output. 52979 (line 127) 52980* TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 13) 52981* TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 11) 52982* TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 12) 52983* TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 14) 52984* TARGET_ASM_UNIQUE_SECTION: Sections. (line 206) 52985* TARGET_ASM_UNWIND_EMIT: Dispatch Tables. (line 87) 52986* TARGET_ASM_UNWIND_EMIT_BEFORE_INSN: Dispatch Tables. (line 93) 52987* TARGET_ATOMIC_ALIGN_FOR_MODE: Misc. (line 1157) 52988* TARGET_ATOMIC_ASSIGN_EXPAND_FENV: Misc. (line 1163) 52989* TARGET_ATOMIC_TEST_AND_SET_TRUEVAL: Misc. (line 1148) 52990* TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 10) 52991* TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P: Target Attributes. (line 17) 52992* TARGET_BINDS_LOCAL_P: Sections. (line 313) 52993* TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc. (line 929) 52994* TARGET_BRANCH_TARGET_REGISTER_CLASS: Misc. (line 922) 52995* TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 289) 52996* TARGET_BUILTIN_CHKP_FUNCTION: Misc. (line 647) 52997* TARGET_BUILTIN_DECL: Misc. (line 626) 52998* TARGET_BUILTIN_RECIPROCAL: Addressing Modes. (line 261) 52999* TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 101) 53000* TARGET_CALLEE_COPIES: Register Arguments. (line 131) 53001* TARGET_CALL_ARGS: Varargs. (line 123) 53002* TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS: Miscellaneous Register Hooks. 53003 (line 6) 53004* TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 234) 53005* TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 909) 53006* TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P: Register Classes. (line 610) 53007* TARGET_CANONICALIZE_COMPARISON: MODE_CC Condition Codes. 53008 (line 55) 53009* TARGET_CANONICAL_VA_LIST_TYPE: Register Arguments. (line 310) 53010* TARGET_CAN_CHANGE_MODE_CLASS: Register Classes. (line 543) 53011* TARGET_CAN_CHANGE_MODE_CLASS and subreg semantics: Regs and Memory. 53012 (line 294) 53013* TARGET_CAN_ELIMINATE: Elimination. (line 58) 53014* TARGET_CAN_FOLLOW_JUMP: Misc. (line 818) 53015* TARGET_CAN_INLINE_P: Target Attributes. (line 165) 53016* TARGET_CAN_USE_DOLOOP_P: Misc. (line 782) 53017* TARGET_CASE_VALUES_THRESHOLD: Misc. (line 46) 53018* TARGET_CC_MODES_COMPATIBLE: MODE_CC Condition Codes. 53019 (line 120) 53020* TARGET_CHECK_PCH_TARGET_FLAGS: PCH Target. (line 26) 53021* TARGET_CHECK_STRING_OBJECT_FORMAT_ARG: Run-time Target. (line 119) 53022* TARGET_CHKP_BOUND_MODE: Misc. (line 719) 53023* TARGET_CHKP_BOUND_TYPE: Misc. (line 717) 53024* TARGET_CHKP_FUNCTION_VALUE_BOUNDS: Varargs. (line 182) 53025* TARGET_CHKP_INITIALIZE_BOUNDS: Misc. (line 725) 53026* TARGET_CHKP_MAKE_BOUNDS_CONSTANT: Misc. (line 721) 53027* TARGET_CLASS_LIKELY_SPILLED_P: Register Classes. (line 499) 53028* TARGET_CLASS_MAX_NREGS: Register Classes. (line 515) 53029* TARGET_COMMUTATIVE_P: Misc. (line 825) 53030* TARGET_COMPARE_BY_PIECES_BRANCH_RATIO: Costs. (line 200) 53031* TARGET_COMPARE_VERSION_PRIORITY: Misc. (line 759) 53032* TARGET_COMPUTE_FRAME_LAYOUT: Elimination. (line 74) 53033* TARGET_COMPUTE_PRESSURE_CLASSES: Register Classes. (line 655) 53034* TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 25) 53035* TARGET_CONDITIONAL_REGISTER_USAGE: Register Basics. (line 63) 53036* TARGET_CONSTANT_ALIGNMENT: Storage Layout. (line 268) 53037* TARGET_CONST_ANCHOR: Misc. (line 1121) 53038* TARGET_CONST_NOT_OK_FOR_DEBUG_P: Addressing Modes. (line 230) 53039* TARGET_CONVERT_TO_TYPE: Misc. (line 1081) 53040* TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 8) 53041* TARGET_CSTORE_MODE: Register Classes. (line 647) 53042* TARGET_CUSTOM_FUNCTION_DESCRIPTORS: Trampolines. (line 84) 53043* TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 86) 53044* TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 37) 53045* TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 61) 53046* TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 24) 53047* TARGET_CXX_DECL_MANGLING_CONTEXT: C++ ABI. (line 92) 53048* TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 52) 53049* TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 17) 53050* TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 11) 53051* TARGET_CXX_GUARD_TYPE: C++ ABI. (line 6) 53052* TARGET_CXX_IMPLICIT_EXTERN_C: Misc. (line 395) 53053* TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 28) 53054* TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 42) 53055* TARGET_CXX_LIBRARY_RTTI_COMDAT: C++ ABI. (line 68) 53056* TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 73) 53057* TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT: C++ ABI. (line 79) 53058* TARGET_C_EXCESS_PRECISION: Storage Layout. (line 109) 53059* TARGET_C_PREINCLUDE: Misc. (line 383) 53060* TARGET_DEBUG_UNWIND_INFO: DWARF. (line 32) 53061* TARGET_DECIMAL_FLOAT_SUPPORTED_P: Storage Layout. (line 534) 53062* TARGET_DECLSPEC: Target Attributes. (line 72) 53063* TARGET_DEFAULT_PACK_STRUCT: Misc. (line 468) 53064* TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 123) 53065* TARGET_DEFAULT_TARGET_FLAGS: Run-time Target. (line 55) 53066* TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 465) 53067* TARGET_DELAY_SCHED2: DWARF. (line 77) 53068* TARGET_DELAY_VARTRACK: DWARF. (line 81) 53069* TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 221) 53070* TARGET_DIFFERENT_ADDR_DISPLACEMENT_P: Register Classes. (line 603) 53071* TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 55) 53072* TARGET_DWARF_CALLING_CONVENTION: DWARF. (line 12) 53073* TARGET_DWARF_FRAME_REG_MODE: Exception Region Output. 53074 (line 113) 53075* TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 165) 53076* TARGET_DWARF_POLY_INDETERMINATE_VALUE: Frame Layout. (line 177) 53077* TARGET_DWARF_REGISTER_SPAN: Exception Region Output. 53078 (line 104) 53079* TARGET_EDOM: Library Calls. (line 59) 53080* TARGET_EMPTY_RECORD_P: Aggregate Return. (line 86) 53081* TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS: Emulated TLS. (line 67) 53082* TARGET_EMUTLS_GET_ADDRESS: Emulated TLS. (line 18) 53083* TARGET_EMUTLS_REGISTER_COMMON: Emulated TLS. (line 23) 53084* TARGET_EMUTLS_TMPL_PREFIX: Emulated TLS. (line 44) 53085* TARGET_EMUTLS_TMPL_SECTION: Emulated TLS. (line 35) 53086* TARGET_EMUTLS_VAR_ALIGN_FIXED: Emulated TLS. (line 62) 53087* TARGET_EMUTLS_VAR_FIELDS: Emulated TLS. (line 48) 53088* TARGET_EMUTLS_VAR_INIT: Emulated TLS. (line 55) 53089* TARGET_EMUTLS_VAR_PREFIX: Emulated TLS. (line 40) 53090* TARGET_EMUTLS_VAR_SECTION: Emulated TLS. (line 30) 53091* TARGET_ENCODE_SECTION_INFO: Sections. (line 256) 53092* TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes. 53093 (line 82) 53094* TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 127) 53095* TARGET_END_CALL_ARGS: Varargs. (line 137) 53096* TARGET_ENUM_VA_LIST_P: Register Arguments. (line 293) 53097* TARGET_ESTIMATED_POLY_VALUE: Costs. (line 425) 53098* TARGET_EXCEPT_UNWIND_INFO: Exception Region Output. 53099 (line 46) 53100* TARGET_EXECUTABLE_SUFFIX: Misc. (line 883) 53101* TARGET_EXPAND_BUILTIN: Misc. (line 636) 53102* TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 64) 53103* TARGET_EXPAND_DIVMOD_LIBFUNC: Scheduling. (line 461) 53104* TARGET_EXPAND_TO_RTL_HOOK: Storage Layout. (line 540) 53105* TARGET_EXPR: Unary and Binary Expressions. 53106 (line 6) 53107* TARGET_EXTRA_INCLUDES: Misc. (line 996) 53108* TARGET_EXTRA_LIVE_ON_ENTRY: Tail Calls. (line 20) 53109* TARGET_EXTRA_PRE_INCLUDES: Misc. (line 1003) 53110* TARGET_FIXED_CONDITION_CODE_REGS: MODE_CC Condition Codes. 53111 (line 105) 53112* TARGET_FIXED_POINT_SUPPORTED_P: Storage Layout. (line 537) 53113* target_flags: Run-time Target. (line 51) 53114* TARGET_FLAGS_REGNUM: MODE_CC Condition Codes. 53115 (line 133) 53116* TARGET_FLOATN_BUILTIN_P: Register Arguments. (line 414) 53117* TARGET_FLOATN_MODE: Register Arguments. (line 396) 53118* TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P: Run-time Target. 53119 (line 183) 53120* TARGET_FN_ABI_VA_LIST: Register Arguments. (line 305) 53121* TARGET_FOLD_BUILTIN: Misc. (line 742) 53122* TARGET_FORMAT_TYPES: Misc. (line 1024) 53123* TARGET_FRAME_POINTER_REQUIRED: Elimination. (line 8) 53124* TARGET_FUNCTION_ARG: Register Arguments. (line 10) 53125* TARGET_FUNCTION_ARG_ADVANCE: Register Arguments. (line 202) 53126* TARGET_FUNCTION_ARG_BOUNDARY: Register Arguments. (line 256) 53127* TARGET_FUNCTION_ARG_OFFSET: Register Arguments. (line 214) 53128* TARGET_FUNCTION_ARG_PADDING: Register Arguments. (line 222) 53129* TARGET_FUNCTION_ARG_ROUND_BOUNDARY: Register Arguments. (line 262) 53130* TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 93) 53131* TARGET_FUNCTION_INCOMING_ARG: Register Arguments. (line 71) 53132* TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 6) 53133* TARGET_FUNCTION_VALUE: Scalar Return. (line 9) 53134* TARGET_FUNCTION_VALUE_REGNO_P: Scalar Return. (line 96) 53135* TARGET_GENERATE_VERSION_DISPATCHER_BODY: Misc. (line 775) 53136* TARGET_GEN_CCMP_FIRST: Misc. (line 949) 53137* TARGET_GEN_CCMP_NEXT: Misc. (line 960) 53138* TARGET_GET_DRAP_RTX: Misc. (line 1104) 53139* TARGET_GET_FUNCTION_VERSIONS_DISPATCHER: Misc. (line 768) 53140* TARGET_GET_PCH_VALIDITY: PCH Target. (line 6) 53141* TARGET_GET_RAW_ARG_MODE: Aggregate Return. (line 81) 53142* TARGET_GET_RAW_RESULT_MODE: Aggregate Return. (line 76) 53143* TARGET_GIMPLE_FOLD_BUILTIN: Misc. (line 752) 53144* TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 315) 53145* TARGET_GOACC_DIM_LIMIT: Addressing Modes. (line 499) 53146* TARGET_GOACC_FORK_JOIN: Addressing Modes. (line 503) 53147* TARGET_GOACC_REDUCTION: Addressing Modes. (line 514) 53148* TARGET_GOACC_VALIDATE_DIMS: Addressing Modes. (line 486) 53149* TARGET_HANDLE_C_OPTION: Run-time Target. (line 73) 53150* TARGET_HANDLE_OPTION: Run-time Target. (line 59) 53151* TARGET_HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 52) 53152* TARGET_HARD_REGNO_MODE_OK: Values in Registers. 53153 (line 54) 53154* TARGET_HARD_REGNO_NREGS: Values in Registers. 53155 (line 10) 53156* TARGET_HARD_REGNO_SCRATCH_OK: Values in Registers. 53157 (line 139) 53158* TARGET_HAS_IFUNC_P: Misc. (line 1152) 53159* TARGET_HAS_NO_HW_DIVIDE: Library Calls. (line 52) 53160* TARGET_HAVE_CONDITIONAL_EXECUTION: Misc. (line 943) 53161* TARGET_HAVE_CTORS_DTORS: Macros for Initialization. 53162 (line 63) 53163* TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 150) 53164* TARGET_HAVE_SRODATA_SECTION: Sections. (line 302) 53165* TARGET_HAVE_SWITCHABLE_BSS_SECTIONS: File Framework. (line 155) 53166* TARGET_HAVE_TLS: Sections. (line 322) 53167* TARGET_INIT_BUILTINS: Misc. (line 610) 53168* TARGET_INIT_DWARF_REG_SIZES_EXTRA: Exception Region Output. 53169 (line 119) 53170* TARGET_INIT_LIBFUNCS: Library Calls. (line 15) 53171* TARGET_INIT_PIC_REG: Register Arguments. (line 95) 53172* TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 80) 53173* TARGET_INSN_COST: Costs. (line 380) 53174* TARGET_INSTANTIATE_DECLS: Storage Layout. (line 548) 53175* TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN: Misc. (line 1048) 53176* TARGET_INVALID_BINARY_OP: Misc. (line 1067) 53177* TARGET_INVALID_CONVERSION: Misc. (line 1054) 53178* TARGET_INVALID_UNARY_OP: Misc. (line 1060) 53179* TARGET_INVALID_WITHIN_DOLOOP: Misc. (line 799) 53180* TARGET_IN_SMALL_DATA_P: Sections. (line 298) 53181* TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS: Register Classes. (line 570) 53182* TARGET_KEEP_LEAF_WHEN_PROFILED: Profiling. (line 39) 53183* TARGET_LEGITIMATE_ADDRESS_P: Addressing Modes. (line 48) 53184* TARGET_LEGITIMATE_COMBINED_INSN: Misc. (line 813) 53185* TARGET_LEGITIMATE_CONSTANT_P: Addressing Modes. (line 213) 53186* TARGET_LEGITIMIZE_ADDRESS: Addressing Modes. (line 129) 53187* TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT: Register Classes. (line 618) 53188* TARGET_LIBCALL_VALUE: Scalar Return. (line 65) 53189* TARGET_LIBC_HAS_FUNCTION: Library Calls. (line 77) 53190* TARGET_LIBFUNC_GNU_PREFIX: Library Calls. (line 24) 53191* TARGET_LIBGCC_CMP_RETURN_MODE: Storage Layout. (line 490) 53192* TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P: Register Arguments. 53193 (line 388) 53194* TARGET_LIBGCC_SDATA_SECTION: Sections. (line 136) 53195* TARGET_LIBGCC_SHIFT_COUNT_MODE: Storage Layout. (line 496) 53196* TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 42) 53197* TARGET_LOAD_BOUNDS_FOR_ARG: Varargs. (line 153) 53198* TARGET_LOAD_RETURNED_BOUNDS: Varargs. (line 172) 53199* TARGET_LOOP_UNROLL_ADJUST: Misc. (line 977) 53200* TARGET_LRA_P: Register Classes. (line 577) 53201* TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 595) 53202* TARGET_MANGLE_ASSEMBLER_NAME: Label Output. (line 356) 53203* TARGET_MANGLE_DECL_ASSEMBLER_NAME: Sections. (line 246) 53204* TARGET_MANGLE_TYPE: Storage Layout. (line 552) 53205* TARGET_MAX_ANCHOR_OFFSET: Anchored Addresses. (line 38) 53206* TARGET_MAX_NOCE_IFCVT_SEQ_COST: Costs. (line 390) 53207* TARGET_MD_ASM_ADJUST: Misc. (line 513) 53208* TARGET_MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 442) 53209* TARGET_MEMMODEL_CHECK: Misc. (line 1143) 53210* TARGET_MEMORY_MOVE_COST: Costs. (line 79) 53211* TARGET_MEM_CONSTRAINT: Addressing Modes. (line 107) 53212* TARGET_MEM_REF: Storage References. (line 6) 53213* TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 45) 53214* TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 37) 53215* TARGET_MIN_ANCHOR_OFFSET: Anchored Addresses. (line 32) 53216* TARGET_MIN_ARITHMETIC_PRECISION: Misc. (line 63) 53217* TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 112) 53218* TARGET_MODES_TIEABLE_P: Values in Registers. 53219 (line 123) 53220* TARGET_MODE_AFTER: Mode Switching. (line 57) 53221* TARGET_MODE_DEPENDENT_ADDRESS_P: Addressing Modes. (line 196) 53222* TARGET_MODE_EMIT: Mode Switching. (line 42) 53223* TARGET_MODE_ENTRY: Mode Switching. (line 64) 53224* TARGET_MODE_EXIT: Mode Switching. (line 71) 53225* TARGET_MODE_NEEDED: Mode Switching. (line 50) 53226* TARGET_MODE_PRIORITY: Mode Switching. (line 78) 53227* TARGET_MODE_REP_EXTENDED: Misc. (line 197) 53228* TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 506) 53229* TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 64) 53230* TARGET_MUST_PASS_IN_STACK, and TARGET_FUNCTION_ARG: Register Arguments. 53231 (line 56) 53232* TARGET_NARROW_VOLATILE_BITFIELD: Storage Layout. (line 435) 53233* TARGET_NOCE_CONVERSION_PROFITABLE_P: Costs. (line 409) 53234* TARGET_NO_REGISTER_ALLOCATION: DWARF. (line 85) 53235* TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P: Costs. (line 415) 53236* TARGET_N_FORMAT_TYPES: Misc. (line 1029) 53237* TARGET_OBJC_CONSTRUCT_STRING_OBJECT: Run-time Target. (line 88) 53238* TARGET_OBJC_DECLARE_CLASS_DEFINITION: Run-time Target. (line 109) 53239* TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE: Run-time Target. 53240 (line 104) 53241* TARGET_OBJECT_SUFFIX: Misc. (line 878) 53242* TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 45) 53243* TARGET_OFFLOAD_OPTIONS: Misc. (line 1186) 53244* TARGET_OMIT_STRUCT_RETURN_REG: Scalar Return. (line 117) 53245* TARGET_OPTAB_SUPPORTED_P: Costs. (line 299) 53246* TARGET_OPTF: Misc. (line 1011) 53247* TARGET_OPTION_DEFAULT_PARAMS: Run-time Target. (line 160) 53248* TARGET_OPTION_FUNCTION_VERSIONS: Target Attributes. (line 157) 53249* TARGET_OPTION_INIT_STRUCT: Run-time Target. (line 156) 53250* TARGET_OPTION_OPTIMIZATION_TABLE: Run-time Target. (line 142) 53251* TARGET_OPTION_OVERRIDE: Target Attributes. (line 144) 53252* TARGET_OPTION_POST_STREAM_IN: Target Attributes. (line 125) 53253* TARGET_OPTION_PRAGMA_PARSE: Target Attributes. (line 137) 53254* TARGET_OPTION_PRINT: Target Attributes. (line 131) 53255* TARGET_OPTION_RESTORE: Target Attributes. (line 119) 53256* TARGET_OPTION_SAVE: Target Attributes. (line 112) 53257* TARGET_OPTION_VALID_ATTRIBUTE_P: Target Attributes. (line 100) 53258* TARGET_OS_CPP_BUILTINS: Run-time Target. (line 41) 53259* TARGET_OVERRIDES_FORMAT_ATTRIBUTES: Misc. (line 1033) 53260* TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc. (line 1039) 53261* TARGET_OVERRIDES_FORMAT_INIT: Misc. (line 1043) 53262* TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE: Run-time Target. (line 126) 53263* TARGET_PASS_BY_REFERENCE: Register Arguments. (line 119) 53264* TARGET_PCH_VALID_P: PCH Target. (line 11) 53265* TARGET_POSIX_IO: Misc. (line 539) 53266* TARGET_PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 284) 53267* TARGET_PREFERRED_RELOAD_CLASS: Register Classes. (line 213) 53268* TARGET_PREFERRED_RENAME_CLASS: Register Classes. (line 201) 53269* TARGET_PREPARE_PCH_SAVE: PCH Target. (line 34) 53270* TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 144) 53271* TARGET_PROFILE_BEFORE_PROLOGUE: Sections. (line 306) 53272* TARGET_PROMOTED_TYPE: Misc. (line 1073) 53273* TARGET_PROMOTE_FUNCTION_MODE: Storage Layout. (line 126) 53274* TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 10) 53275* TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 250) 53276* TARGET_RECORD_OFFLOAD_SYMBOL: Misc. (line 1181) 53277* TARGET_REF_MAY_ALIAS_ERRNO: Register Arguments. (line 326) 53278* TARGET_REGISTER_MOVE_COST: Costs. (line 31) 53279* TARGET_REGISTER_PRIORITY: Register Classes. (line 582) 53280* TARGET_REGISTER_USAGE_LEVELING_P: Register Classes. (line 593) 53281* TARGET_RELAYOUT_FUNCTION: Target Attributes. (line 172) 53282* TARGET_RESET_LOCATION_VIEW: DWARF. (line 57) 53283* TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 731) 53284* TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 15) 53285* TARGET_RETURN_IN_MSB: Scalar Return. (line 124) 53286* TARGET_RETURN_POPS_ARGS: Stack Arguments. (line 98) 53287* TARGET_RTX_COSTS: Costs. (line 313) 53288* TARGET_RUN_TARGET_SELFTESTS: Misc. (line 1235) 53289* TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 333) 53290* TARGET_SCHED_ADJUST_COST: Scheduling. (line 35) 53291* TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 50) 53292* TARGET_SCHED_ALLOC_SCHED_CONTEXT: Scheduling. (line 294) 53293* TARGET_SCHED_CAN_SPECULATE_INSN: Scheduling. (line 354) 53294* TARGET_SCHED_CLEAR_SCHED_CONTEXT: Scheduling. (line 309) 53295* TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 101) 53296* TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 255) 53297* TARGET_SCHED_DFA_POST_ADVANCE_CYCLE: Scheduling. (line 172) 53298* TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 156) 53299* TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE: Scheduling. (line 165) 53300* TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 144) 53301* TARGET_SCHED_DISPATCH: Scheduling. (line 370) 53302* TARGET_SCHED_DISPATCH_DO: Scheduling. (line 375) 53303* TARGET_SCHED_EXPOSED_PIPELINE: Scheduling. (line 379) 53304* TARGET_SCHED_FINISH: Scheduling. (line 122) 53305* TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 137) 53306* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK: Scheduling. (line 235) 53307* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN: Scheduling. (line 223) 53308* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling. 53309 (line 179) 53310* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling. 53311 (line 207) 53312* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END: Scheduling. (line 240) 53313* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI: Scheduling. (line 250) 53314* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT: Scheduling. (line 245) 53315* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE: Scheduling. (line 229) 53316* TARGET_SCHED_FREE_SCHED_CONTEXT: Scheduling. (line 313) 53317* TARGET_SCHED_FUSION_PRIORITY: Scheduling. (line 389) 53318* TARGET_SCHED_GEN_SPEC_CHECK: Scheduling. (line 335) 53319* TARGET_SCHED_H_I_D_EXTENDED: Scheduling. (line 289) 53320* TARGET_SCHED_INIT: Scheduling. (line 111) 53321* TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 161) 53322* TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 153) 53323* TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 129) 53324* TARGET_SCHED_INIT_SCHED_CONTEXT: Scheduling. (line 298) 53325* TARGET_SCHED_ISSUE_RATE: Scheduling. (line 11) 53326* TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 267) 53327* TARGET_SCHED_MACRO_FUSION_P: Scheduling. (line 87) 53328* TARGET_SCHED_MACRO_FUSION_PAIR_P: Scheduling. (line 91) 53329* TARGET_SCHED_NEEDS_BLOCK_P: Scheduling. (line 328) 53330* TARGET_SCHED_REASSOCIATION_WIDTH: Scheduling. (line 384) 53331* TARGET_SCHED_REORDER: Scheduling. (line 58) 53332* TARGET_SCHED_REORDER2: Scheduling. (line 75) 53333* TARGET_SCHED_SET_SCHED_CONTEXT: Scheduling. (line 305) 53334* TARGET_SCHED_SET_SCHED_FLAGS: Scheduling. (line 347) 53335* TARGET_SCHED_SMS_RES_MII: Scheduling. (line 361) 53336* TARGET_SCHED_SPECULATE_INSN: Scheduling. (line 316) 53337* TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 22) 53338* TARGET_SECONDARY_MEMORY_NEEDED: Register Classes. (line 447) 53339* TARGET_SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 466) 53340* TARGET_SECONDARY_RELOAD: Register Classes. (line 312) 53341* TARGET_SECTION_TYPE_FLAGS: File Framework. (line 160) 53342* TARGET_SELECT_EARLY_REMAT_MODES: Register Classes. (line 488) 53343* TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 71) 53344* TARGET_SETUP_INCOMING_VARARG_BOUNDS: Varargs. (line 188) 53345* TARGET_SET_CURRENT_FUNCTION: Misc. (line 860) 53346* TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 33) 53347* TARGET_SET_UP_BY_PROLOGUE: Tail Calls. (line 29) 53348* TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 160) 53349* TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB: Shrink-wrapping separate components. 53350 (line 36) 53351* TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS: Shrink-wrapping separate components. 53352 (line 43) 53353* TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS: Shrink-wrapping separate components. 53354 (line 54) 53355* TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS: Shrink-wrapping separate components. 53356 (line 50) 53357* TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS: Shrink-wrapping separate components. 53358 (line 27) 53359* TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS: Shrink-wrapping separate components. 53360 (line 58) 53361* TARGET_SIMD_CLONE_ADJUST: Addressing Modes. (line 473) 53362* TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN: Addressing Modes. 53363 (line 465) 53364* TARGET_SIMD_CLONE_USABLE: Addressing Modes. (line 477) 53365* TARGET_SIMT_VF: Addressing Modes. (line 483) 53366* TARGET_SLOW_UNALIGNED_ACCESS: Costs. (line 132) 53367* TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P: Register Arguments. 53368 (line 424) 53369* TARGET_SPILL_CLASS: Register Classes. (line 632) 53370* TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 277) 53371* TARGET_STACK_CLASH_PROTECTION_FINAL_DYNAMIC_PROBE: Stack Checking. 53372 (line 97) 53373* TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection. 53374 (line 16) 53375* TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection. 53376 (line 6) 53377* TARGET_STACK_PROTECT_RUNTIME_ENABLED_P: Stack Smashing Protection. 53378 (line 25) 53379* TARGET_STARTING_FRAME_OFFSET: Frame Layout. (line 34) 53380* TARGET_STARTING_FRAME_OFFSET and virtual registers: Regs and Memory. 53381 (line 74) 53382* TARGET_STATIC_CHAIN: Frame Registers. (line 90) 53383* TARGET_STATIC_RTX_ALIGNMENT: Storage Layout. (line 240) 53384* TARGET_STORE_BOUNDS_FOR_ARG: Varargs. (line 163) 53385* TARGET_STORE_RETURNED_BOUNDS: Varargs. (line 177) 53386* TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 107) 53387* TARGET_STRING_OBJECT_REF_TYPE_P: Run-time Target. (line 114) 53388* TARGET_STRIP_NAME_ENCODING: Sections. (line 293) 53389* TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 44) 53390* TARGET_SUPPORTS_SPLIT_STACK: Stack Smashing Protection. 53391 (line 30) 53392* TARGET_SUPPORTS_WEAK: Label Output. (line 272) 53393* TARGET_SUPPORTS_WIDE_INT: Misc. (line 1194) 53394* TARGET_TERMINATE_DW2_EH_FRAME_INFO: Exception Region Output. 53395 (line 98) 53396* TARGET_TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 74) 53397* TARGET_TRAMPOLINE_INIT: Trampolines. (line 54) 53398* TARGET_TRULY_NOOP_TRUNCATION: Misc. (line 184) 53399* TARGET_UNSPEC_MAY_TRAP_P: Misc. (line 851) 53400* TARGET_UNWIND_TABLES_DEFAULT: Exception Region Output. 53401 (line 73) 53402* TARGET_UNWIND_WORD_MODE: Storage Layout. (line 502) 53403* TARGET_UPDATE_STACK_BOUNDARY: Misc. (line 1100) 53404* TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 123) 53405* TARGET_USE_ANCHORS_FOR_SYMBOL_P: Anchored Addresses. (line 53) 53406* TARGET_USE_BLOCKS_FOR_CONSTANT_P: Addressing Modes. (line 248) 53407* TARGET_USE_BLOCKS_FOR_DECL_P: Addressing Modes. (line 255) 53408* TARGET_USE_BY_PIECES_INFRASTRUCTURE_P: Costs. (line 165) 53409* TARGET_USE_PSEUDO_PIC_REG: Register Arguments. (line 91) 53410* TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 66) 53411* TARGET_VALID_POINTER_MODE: Register Arguments. (line 321) 53412* TARGET_VECTORIZE_ADD_STMT_COST: Addressing Modes. (line 428) 53413* TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES: Addressing Modes. 53414 (line 388) 53415* TARGET_VECTORIZE_BUILTIN_CONVERSION: Addressing Modes. (line 336) 53416* TARGET_VECTORIZE_BUILTIN_GATHER: Addressing Modes. (line 451) 53417* TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 266) 53418* TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION: Addressing Modes. 53419 (line 356) 53420* TARGET_VECTORIZE_BUILTIN_SCATTER: Addressing Modes. (line 458) 53421* TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST: Addressing Modes. 53422 (line 292) 53423* TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION: Addressing Modes. 53424 (line 348) 53425* TARGET_VECTORIZE_DESTROY_COST_DATA: Addressing Modes. (line 446) 53426* TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE: Addressing Modes. 53427 (line 412) 53428* TARGET_VECTORIZE_FINISH_COST: Addressing Modes. (line 439) 53429* TARGET_VECTORIZE_GET_MASK_MODE: Addressing Modes. (line 400) 53430* TARGET_VECTORIZE_INIT_COST: Addressing Modes. (line 419) 53431* TARGET_VECTORIZE_PREFERRED_SIMD_MODE: Addressing Modes. (line 373) 53432* TARGET_VECTORIZE_PREFERRED_VECTOR_ALIGNMENT: Addressing Modes. 53433 (line 298) 53434* TARGET_VECTORIZE_SPLIT_REDUCTION: Addressing Modes. (line 380) 53435* TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT: Addressing Modes. 53436 (line 363) 53437* TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE: Addressing Modes. 53438 (line 310) 53439* TARGET_VECTORIZE_VEC_PERM_CONST: Addressing Modes. (line 316) 53440* TARGET_VECTOR_ALIGNMENT: Storage Layout. (line 295) 53441* TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 344) 53442* TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 303) 53443* TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 297) 53444* TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 286) 53445* TARGET_WANT_DEBUG_PUB_SECTIONS: DWARF. (line 72) 53446* TARGET_WARN_FUNC_RETURN: Tail Calls. (line 35) 53447* TARGET_WARN_PARAMETER_PASSING_ABI: Aggregate Return. (line 90) 53448* TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 308) 53449* TCmode: Machine Modes. (line 199) 53450* TDmode: Machine Modes. (line 97) 53451* TEMPLATE_DECL: Declarations. (line 6) 53452* Temporaries: Temporaries. (line 6) 53453* termination routines: Initialization. (line 6) 53454* testing constraints: C Constraint Interface. 53455 (line 6) 53456* TEXT_SECTION_ASM_OP: Sections. (line 37) 53457* TFmode: Machine Modes. (line 101) 53458* The Language: The Language. (line 6) 53459* THEN_CLAUSE: Statements for C++. (line 6) 53460* THREAD_MODEL_SPEC: Driver. (line 162) 53461* THROW_EXPR: Unary and Binary Expressions. 53462 (line 6) 53463* THUNK_DECL: Declarations. (line 6) 53464* THUNK_DELTA: Declarations. (line 6) 53465* TImode: Machine Modes. (line 48) 53466* TImode, in insn: Insns. (line 291) 53467* TLS_COMMON_ASM_OP: Sections. (line 80) 53468* TLS_SECTION_ASM_FLAG: Sections. (line 85) 53469* tm.h macros: Target Macros. (line 6) 53470* TQFmode: Machine Modes. (line 65) 53471* TQmode: Machine Modes. (line 122) 53472* trampolines for nested functions: Trampolines. (line 6) 53473* TRAMPOLINE_ALIGNMENT: Trampolines. (line 48) 53474* TRAMPOLINE_SECTION: Trampolines. (line 39) 53475* TRAMPOLINE_SIZE: Trampolines. (line 44) 53476* TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 129) 53477* trap instruction pattern: Standard Names. (line 1943) 53478* tree: Tree overview. (line 6) 53479* tree <1>: Macros and Functions. 53480 (line 6) 53481* Tree SSA: Tree SSA. (line 6) 53482* TREE_CHAIN: Macros and Functions. 53483 (line 6) 53484* TREE_CODE: Tree overview. (line 6) 53485* tree_fits_shwi_p: Constant expressions. 53486 (line 6) 53487* tree_fits_uhwi_p: Constant expressions. 53488 (line 6) 53489* TREE_INT_CST_ELT: Constant expressions. 53490 (line 6) 53491* tree_int_cst_equal: Constant expressions. 53492 (line 6) 53493* TREE_INT_CST_LOW: Constant expressions. 53494 (line 6) 53495* tree_int_cst_lt: Constant expressions. 53496 (line 6) 53497* TREE_INT_CST_NUNITS: Constant expressions. 53498 (line 6) 53499* TREE_LIST: Containers. (line 6) 53500* TREE_OPERAND: Expression trees. (line 6) 53501* TREE_PUBLIC: Function Basics. (line 6) 53502* TREE_PUBLIC <1>: Function Properties. 53503 (line 28) 53504* TREE_PURPOSE: Containers. (line 6) 53505* TREE_READONLY: Function Properties. 53506 (line 37) 53507* tree_size: Macros and Functions. 53508 (line 13) 53509* TREE_STATIC: Function Properties. 53510 (line 31) 53511* TREE_STRING_LENGTH: Constant expressions. 53512 (line 6) 53513* TREE_STRING_POINTER: Constant expressions. 53514 (line 6) 53515* TREE_THIS_VOLATILE: Function Properties. 53516 (line 34) 53517* tree_to_shwi: Constant expressions. 53518 (line 6) 53519* tree_to_uhwi: Constant expressions. 53520 (line 6) 53521* TREE_TYPE: Macros and Functions. 53522 (line 6) 53523* TREE_TYPE <1>: Types. (line 6) 53524* TREE_TYPE <2>: Working with declarations. 53525 (line 11) 53526* TREE_TYPE <3>: Expression trees. (line 6) 53527* TREE_TYPE <4>: Expression trees. (line 17) 53528* TREE_TYPE <5>: Function Basics. (line 47) 53529* TREE_TYPE <6>: Types for C++. (line 6) 53530* TREE_VALUE: Containers. (line 6) 53531* TREE_VEC: Containers. (line 6) 53532* TREE_VEC_ELT: Containers. (line 6) 53533* TREE_VEC_LENGTH: Containers. (line 6) 53534* truncate: Conversions. (line 38) 53535* truncMN2 instruction pattern: Standard Names. (line 1278) 53536* TRUNC_DIV_EXPR: Unary and Binary Expressions. 53537 (line 6) 53538* TRUNC_MOD_EXPR: Unary and Binary Expressions. 53539 (line 6) 53540* TRUTH_ANDIF_EXPR: Unary and Binary Expressions. 53541 (line 6) 53542* TRUTH_AND_EXPR: Unary and Binary Expressions. 53543 (line 6) 53544* TRUTH_NOT_EXPR: Unary and Binary Expressions. 53545 (line 6) 53546* TRUTH_ORIF_EXPR: Unary and Binary Expressions. 53547 (line 6) 53548* TRUTH_OR_EXPR: Unary and Binary Expressions. 53549 (line 6) 53550* TRUTH_XOR_EXPR: Unary and Binary Expressions. 53551 (line 6) 53552* TRY_BLOCK: Statements for C++. (line 6) 53553* TRY_HANDLERS: Statements for C++. (line 6) 53554* TRY_STMTS: Statements for C++. (line 6) 53555* Tuple specific accessors: Tuple specific accessors. 53556 (line 6) 53557* tuples: Tuple representation. 53558 (line 6) 53559* type: Types. (line 6) 53560* type declaration: Declarations. (line 6) 53561* TYPENAME_TYPE: Types for C++. (line 6) 53562* TYPENAME_TYPE_FULLNAME: Types. (line 6) 53563* TYPENAME_TYPE_FULLNAME <1>: Types for C++. (line 6) 53564* TYPEOF_TYPE: Types for C++. (line 6) 53565* TYPE_ALIGN: Types. (line 6) 53566* TYPE_ALIGN <1>: Types. (line 30) 53567* TYPE_ALIGN <2>: Types for C++. (line 6) 53568* TYPE_ALIGN <3>: Types for C++. (line 44) 53569* TYPE_ARG_TYPES: Types. (line 6) 53570* TYPE_ARG_TYPES <1>: Types for C++. (line 6) 53571* TYPE_ASM_OP: Label Output. (line 76) 53572* TYPE_ATTRIBUTES: Attributes. (line 24) 53573* TYPE_BINFO: Classes. (line 6) 53574* TYPE_BUILT_IN: Types for C++. (line 66) 53575* TYPE_CANONICAL: Types. (line 6) 53576* TYPE_CANONICAL <1>: Types. (line 41) 53577* TYPE_CONTEXT: Types. (line 6) 53578* TYPE_CONTEXT <1>: Types for C++. (line 6) 53579* TYPE_DECL: Declarations. (line 6) 53580* TYPE_FIELDS: Types. (line 6) 53581* TYPE_FIELDS <1>: Types for C++. (line 6) 53582* TYPE_FIELDS <2>: Classes. (line 6) 53583* TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 93) 53584* TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 78) 53585* TYPE_HAS_MUTABLE_P: Classes. (line 83) 53586* TYPE_HAS_NEW_OPERATOR: Classes. (line 90) 53587* TYPE_MAIN_VARIANT: Types. (line 6) 53588* TYPE_MAIN_VARIANT <1>: Types. (line 19) 53589* TYPE_MAIN_VARIANT <2>: Types for C++. (line 6) 53590* TYPE_MAX_VALUE: Types. (line 6) 53591* TYPE_METHOD_BASETYPE: Types. (line 6) 53592* TYPE_METHOD_BASETYPE <1>: Types for C++. (line 6) 53593* TYPE_MIN_VALUE: Types. (line 6) 53594* TYPE_NAME: Types. (line 6) 53595* TYPE_NAME <1>: Types. (line 33) 53596* TYPE_NAME <2>: Types for C++. (line 6) 53597* TYPE_NAME <3>: Types for C++. (line 47) 53598* TYPE_NOTHROW_P: Functions for C++. (line 154) 53599* TYPE_OFFSET_BASETYPE: Types. (line 6) 53600* TYPE_OFFSET_BASETYPE <1>: Types for C++. (line 6) 53601* TYPE_OPERAND_FMT: Label Output. (line 87) 53602* TYPE_OVERLOADS_ARRAY_REF: Classes. (line 101) 53603* TYPE_OVERLOADS_ARROW: Classes. (line 104) 53604* TYPE_OVERLOADS_CALL_EXPR: Classes. (line 97) 53605* TYPE_POLYMORPHIC_P: Classes. (line 74) 53606* TYPE_PRECISION: Types. (line 6) 53607* TYPE_PRECISION <1>: Types for C++. (line 6) 53608* TYPE_PTRDATAMEM_P: Types for C++. (line 6) 53609* TYPE_PTRDATAMEM_P <1>: Types for C++. (line 69) 53610* TYPE_PTRFN_P: Types for C++. (line 76) 53611* TYPE_PTROBV_P: Types for C++. (line 6) 53612* TYPE_PTROB_P: Types for C++. (line 79) 53613* TYPE_PTR_P: Types for C++. (line 72) 53614* TYPE_QUAL_CONST: Types. (line 6) 53615* TYPE_QUAL_CONST <1>: Types for C++. (line 6) 53616* TYPE_QUAL_RESTRICT: Types. (line 6) 53617* TYPE_QUAL_RESTRICT <1>: Types for C++. (line 6) 53618* TYPE_QUAL_VOLATILE: Types. (line 6) 53619* TYPE_QUAL_VOLATILE <1>: Types for C++. (line 6) 53620* TYPE_RAISES_EXCEPTIONS: Functions for C++. (line 149) 53621* TYPE_SIZE: Types. (line 6) 53622* TYPE_SIZE <1>: Types. (line 25) 53623* TYPE_SIZE <2>: Types for C++. (line 6) 53624* TYPE_SIZE <3>: Types for C++. (line 39) 53625* TYPE_STRUCTURAL_EQUALITY_P: Types. (line 6) 53626* TYPE_STRUCTURAL_EQUALITY_P <1>: Types. (line 77) 53627* TYPE_UNQUALIFIED: Types. (line 6) 53628* TYPE_UNQUALIFIED <1>: Types for C++. (line 6) 53629* TYPE_VFIELD: Classes. (line 6) 53630* uaddvM4 instruction pattern: Standard Names. (line 435) 53631* UDAmode: Machine Modes. (line 170) 53632* udiv: Arithmetic. (line 130) 53633* udivM3 instruction pattern: Standard Names. (line 416) 53634* udivmodM4 instruction pattern: Standard Names. (line 727) 53635* udot_prodM instruction pattern: Standard Names. (line 540) 53636* UDQmode: Machine Modes. (line 138) 53637* UHAmode: Machine Modes. (line 162) 53638* UHQmode: Machine Modes. (line 130) 53639* UINT16_TYPE: Type Layout. (line 214) 53640* UINT32_TYPE: Type Layout. (line 215) 53641* UINT64_TYPE: Type Layout. (line 216) 53642* UINT8_TYPE: Type Layout. (line 213) 53643* UINTMAX_TYPE: Type Layout. (line 197) 53644* UINTPTR_TYPE: Type Layout. (line 234) 53645* UINT_FAST16_TYPE: Type Layout. (line 230) 53646* UINT_FAST32_TYPE: Type Layout. (line 231) 53647* UINT_FAST64_TYPE: Type Layout. (line 232) 53648* UINT_FAST8_TYPE: Type Layout. (line 229) 53649* UINT_LEAST16_TYPE: Type Layout. (line 222) 53650* UINT_LEAST32_TYPE: Type Layout. (line 223) 53651* UINT_LEAST64_TYPE: Type Layout. (line 224) 53652* UINT_LEAST8_TYPE: Type Layout. (line 221) 53653* umaddMN4 instruction pattern: Standard Names. (line 674) 53654* umax: Arithmetic. (line 149) 53655* umaxM3 instruction pattern: Standard Names. (line 416) 53656* umin: Arithmetic. (line 149) 53657* uminM3 instruction pattern: Standard Names. (line 416) 53658* umod: Arithmetic. (line 136) 53659* umodM3 instruction pattern: Standard Names. (line 416) 53660* umsubMN4 instruction pattern: Standard Names. (line 698) 53661* umulhisi3 instruction pattern: Standard Names. (line 646) 53662* umulM3_highpart instruction pattern: Standard Names. (line 660) 53663* umulqihi3 instruction pattern: Standard Names. (line 646) 53664* umulsidi3 instruction pattern: Standard Names. (line 646) 53665* umulvM4 instruction pattern: Standard Names. (line 440) 53666* unchanging: Flags. (line 307) 53667* unchanging, in call_insn: Flags. (line 115) 53668* unchanging, in jump_insn, call_insn and insn: Flags. (line 28) 53669* unchanging, in mem: Flags. (line 78) 53670* unchanging, in subreg: Flags. (line 184) 53671* unchanging, in subreg <1>: Flags. (line 194) 53672* unchanging, in symbol_ref: Flags. (line 19) 53673* UNEQ_EXPR: Unary and Binary Expressions. 53674 (line 6) 53675* UNGE_EXPR: Unary and Binary Expressions. 53676 (line 6) 53677* UNGT_EXPR: Unary and Binary Expressions. 53678 (line 6) 53679* unions, returning: Interface. (line 10) 53680* UNION_TYPE: Types. (line 6) 53681* UNION_TYPE <1>: Classes. (line 6) 53682* UNITS_PER_WORD: Storage Layout. (line 60) 53683* UNKNOWN_TYPE: Types. (line 6) 53684* UNKNOWN_TYPE <1>: Types for C++. (line 6) 53685* UNLE_EXPR: Unary and Binary Expressions. 53686 (line 6) 53687* UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 48) 53688* UNLT_EXPR: Unary and Binary Expressions. 53689 (line 6) 53690* UNORDERED_EXPR: Unary and Binary Expressions. 53691 (line 6) 53692* unshare_all_rtl: Sharing. (line 61) 53693* unsigned division: Arithmetic. (line 130) 53694* unsigned division with unsigned saturation: Arithmetic. (line 130) 53695* unsigned greater than: Comparisons. (line 64) 53696* unsigned greater than <1>: Comparisons. (line 72) 53697* unsigned less than: Comparisons. (line 68) 53698* unsigned less than <1>: Comparisons. (line 76) 53699* unsigned minimum and maximum: Arithmetic. (line 149) 53700* unsigned_fix: Conversions. (line 77) 53701* unsigned_float: Conversions. (line 62) 53702* unsigned_fract_convert: Conversions. (line 97) 53703* unsigned_sat_fract: Conversions. (line 103) 53704* unspec: Side Effects. (line 299) 53705* unspec <1>: Constant Definitions. 53706 (line 111) 53707* unspec_volatile: Side Effects. (line 299) 53708* unspec_volatile <1>: Constant Definitions. 53709 (line 99) 53710* untyped_call instruction pattern: Standard Names. (line 1559) 53711* untyped_return instruction pattern: Standard Names. (line 1622) 53712* UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59) 53713* update_ssa: SSA. (line 74) 53714* update_stmt: Manipulating GIMPLE statements. 53715 (line 140) 53716* update_stmt <1>: SSA Operands. (line 6) 53717* update_stmt_if_modified: Manipulating GIMPLE statements. 53718 (line 143) 53719* UQQmode: Machine Modes. (line 126) 53720* usaddM3 instruction pattern: Standard Names. (line 416) 53721* usadM instruction pattern: Standard Names. (line 549) 53722* USAmode: Machine Modes. (line 166) 53723* usashlM3 instruction pattern: Standard Names. (line 730) 53724* usdivM3 instruction pattern: Standard Names. (line 416) 53725* use: Side Effects. (line 168) 53726* used: Flags. (line 325) 53727* used, in symbol_ref: Flags. (line 211) 53728* user: GTY Options. (line 245) 53729* user gc: User GC. (line 6) 53730* USER_LABEL_PREFIX: Instruction Output. (line 152) 53731* USE_C_ALLOCA: Host Misc. (line 19) 53732* USE_LD_AS_NEEDED: Driver. (line 135) 53733* USE_LOAD_POST_DECREMENT: Costs. (line 254) 53734* USE_LOAD_POST_INCREMENT: Costs. (line 249) 53735* USE_LOAD_PRE_DECREMENT: Costs. (line 264) 53736* USE_LOAD_PRE_INCREMENT: Costs. (line 259) 53737* USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 198) 53738* USE_STORE_POST_DECREMENT: Costs. (line 274) 53739* USE_STORE_POST_INCREMENT: Costs. (line 269) 53740* USE_STORE_PRE_DECREMENT: Costs. (line 284) 53741* USE_STORE_PRE_INCREMENT: Costs. (line 279) 53742* USING_STMT: Statements for C++. (line 6) 53743* usmaddMN4 instruction pattern: Standard Names. (line 682) 53744* usmsubMN4 instruction pattern: Standard Names. (line 706) 53745* usmulhisi3 instruction pattern: Standard Names. (line 650) 53746* usmulM3 instruction pattern: Standard Names. (line 416) 53747* usmulqihi3 instruction pattern: Standard Names. (line 650) 53748* usmulsidi3 instruction pattern: Standard Names. (line 650) 53749* usnegM2 instruction pattern: Standard Names. (line 754) 53750* USQmode: Machine Modes. (line 134) 53751* ussubM3 instruction pattern: Standard Names. (line 416) 53752* usubvM4 instruction pattern: Standard Names. (line 440) 53753* us_ashift: Arithmetic. (line 173) 53754* us_minus: Arithmetic. (line 38) 53755* us_mult: Arithmetic. (line 93) 53756* us_neg: Arithmetic. (line 82) 53757* us_plus: Arithmetic. (line 14) 53758* us_truncate: Conversions. (line 48) 53759* UTAmode: Machine Modes. (line 174) 53760* UTQmode: Machine Modes. (line 142) 53761* V in constraint: Simple Constraints. (line 43) 53762* values, returned by functions: Scalar Return. (line 6) 53763* varargs implementation: Varargs. (line 6) 53764* variable: Declarations. (line 6) 53765* Variable Location Debug Information in RTL: Debug Information. 53766 (line 6) 53767* VAR_DECL: Declarations. (line 6) 53768* var_location: Debug Information. (line 14) 53769* vashlM3 instruction pattern: Standard Names. (line 746) 53770* vashrM3 instruction pattern: Standard Names. (line 746) 53771* VA_ARG_EXPR: Unary and Binary Expressions. 53772 (line 6) 53773* vcondeqMN instruction pattern: Standard Names. (line 359) 53774* vcondMN instruction pattern: Standard Names. (line 346) 53775* vconduMN instruction pattern: Standard Names. (line 356) 53776* vcond_mask_MN instruction pattern: Standard Names. (line 366) 53777* vector: Containers. (line 6) 53778* vector operations: Vector Operations. (line 6) 53779* VECTOR_CST: Constant expressions. 53780 (line 6) 53781* VECTOR_STORE_FLAG_VALUE: Misc. (line 315) 53782* vec_cmpeqMN instruction pattern: Standard Names. (line 339) 53783* vec_cmpMN instruction pattern: Standard Names. (line 329) 53784* vec_cmpuMN instruction pattern: Standard Names. (line 336) 53785* vec_concat: Vector Operations. (line 28) 53786* VEC_COND_EXPR: Vectors. (line 6) 53787* vec_duplicate: Vector Operations. (line 33) 53788* vec_duplicateM instruction pattern: Standard Names. (line 297) 53789* VEC_DUPLICATE_EXPR: Vectors. (line 6) 53790* vec_extractMN instruction pattern: Standard Names. (line 281) 53791* vec_initMN instruction pattern: Standard Names. (line 290) 53792* vec_load_lanesMN instruction pattern: Standard Names. (line 165) 53793* VEC_LSHIFT_EXPR: Vectors. (line 6) 53794* vec_mask_load_lanesMN instruction pattern: Standard Names. (line 189) 53795* vec_mask_store_lanesMN instruction pattern: Standard Names. 53796 (line 219) 53797* vec_merge: Vector Operations. (line 11) 53798* VEC_PACK_FIX_TRUNC_EXPR: Vectors. (line 6) 53799* VEC_PACK_SAT_EXPR: Vectors. (line 6) 53800* vec_pack_sfix_trunc_M instruction pattern: Standard Names. (line 591) 53801* vec_pack_ssat_M instruction pattern: Standard Names. (line 584) 53802* VEC_PACK_TRUNC_EXPR: Vectors. (line 6) 53803* vec_pack_trunc_M instruction pattern: Standard Names. (line 577) 53804* vec_pack_ufix_trunc_M instruction pattern: Standard Names. (line 591) 53805* vec_pack_usat_M instruction pattern: Standard Names. (line 584) 53806* vec_permM instruction pattern: Standard Names. (line 384) 53807* vec_permM instruction pattern <1>: Addressing Modes. (line 330) 53808* VEC_RSHIFT_EXPR: Vectors. (line 6) 53809* vec_select: Vector Operations. (line 19) 53810* vec_series: Vector Operations. (line 40) 53811* vec_seriesM instruction pattern: Standard Names. (line 307) 53812* VEC_SERIES_EXPR: Vectors. (line 6) 53813* vec_setM instruction pattern: Standard Names. (line 276) 53814* vec_shl_insert_M instruction pattern: Standard Names. (line 564) 53815* vec_shr_M instruction pattern: Standard Names. (line 571) 53816* vec_store_lanesMN instruction pattern: Standard Names. (line 206) 53817* vec_unpacks_float_hi_M instruction pattern: Standard Names. 53818 (line 612) 53819* vec_unpacks_float_lo_M instruction pattern: Standard Names. 53820 (line 612) 53821* vec_unpacks_hi_M instruction pattern: Standard Names. (line 598) 53822* vec_unpacks_lo_M instruction pattern: Standard Names. (line 598) 53823* vec_unpacku_float_hi_M instruction pattern: Standard Names. 53824 (line 612) 53825* vec_unpacku_float_lo_M instruction pattern: Standard Names. 53826 (line 612) 53827* vec_unpacku_hi_M instruction pattern: Standard Names. (line 605) 53828* vec_unpacku_lo_M instruction pattern: Standard Names. (line 605) 53829* VEC_UNPACK_FLOAT_HI_EXPR: Vectors. (line 6) 53830* VEC_UNPACK_FLOAT_LO_EXPR: Vectors. (line 6) 53831* VEC_UNPACK_HI_EXPR: Vectors. (line 6) 53832* VEC_UNPACK_LO_EXPR: Vectors. (line 6) 53833* VEC_WIDEN_MULT_HI_EXPR: Vectors. (line 6) 53834* VEC_WIDEN_MULT_LO_EXPR: Vectors. (line 6) 53835* vec_widen_smult_even_M instruction pattern: Standard Names. 53836 (line 621) 53837* vec_widen_smult_hi_M instruction pattern: Standard Names. (line 621) 53838* vec_widen_smult_lo_M instruction pattern: Standard Names. (line 621) 53839* vec_widen_smult_odd_M instruction pattern: Standard Names. (line 621) 53840* vec_widen_sshiftl_hi_M instruction pattern: Standard Names. 53841 (line 632) 53842* vec_widen_sshiftl_lo_M instruction pattern: Standard Names. 53843 (line 632) 53844* vec_widen_umult_even_M instruction pattern: Standard Names. 53845 (line 621) 53846* vec_widen_umult_hi_M instruction pattern: Standard Names. (line 621) 53847* vec_widen_umult_lo_M instruction pattern: Standard Names. (line 621) 53848* vec_widen_umult_odd_M instruction pattern: Standard Names. (line 621) 53849* vec_widen_ushiftl_hi_M instruction pattern: Standard Names. 53850 (line 632) 53851* vec_widen_ushiftl_lo_M instruction pattern: Standard Names. 53852 (line 632) 53853* verify_flow_info: Maintaining the CFG. 53854 (line 116) 53855* virtual operands: SSA Operands. (line 6) 53856* VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59) 53857* VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87) 53858* VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78) 53859* VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69) 53860* VLIW: Processor pipeline description. 53861 (line 6) 53862* VLIW <1>: Processor pipeline description. 53863 (line 223) 53864* vlshrM3 instruction pattern: Standard Names. (line 746) 53865* VMS: Filesystem. (line 37) 53866* VMS_DEBUGGING_INFO: VMS Debug. (line 8) 53867* void: Misc. (line 708) 53868* void <1>: Misc. (line 713) 53869* VOIDmode: Machine Modes. (line 192) 53870* VOID_TYPE: Types. (line 6) 53871* volatil: Flags. (line 339) 53872* volatil, in insn, call_insn, jump_insn, code_label, jump_table_data, barrier, and note: Flags. 53873 (line 33) 53874* volatil, in label_ref and reg_label: Flags. (line 54) 53875* volatil, in mem, asm_operands, and asm_input: Flags. (line 65) 53876* volatil, in reg: Flags. (line 106) 53877* volatil, in subreg: Flags. (line 184) 53878* volatil, in subreg <1>: Flags. (line 194) 53879* volatil, in symbol_ref: Flags. (line 220) 53880* volatile memory references: Flags. (line 340) 53881* volatile, in prefetch: Flags. (line 92) 53882* voting between constraint alternatives: Class Preferences. (line 6) 53883* vrotlM3 instruction pattern: Standard Names. (line 746) 53884* vrotrM3 instruction pattern: Standard Names. (line 746) 53885* walk_dominator_tree: SSA. (line 195) 53886* walk_gimple_op: Statement and operand traversals. 53887 (line 30) 53888* walk_gimple_seq: Statement and operand traversals. 53889 (line 47) 53890* walk_gimple_stmt: Statement and operand traversals. 53891 (line 10) 53892* WCHAR_TYPE: Type Layout. (line 165) 53893* WCHAR_TYPE_SIZE: Type Layout. (line 173) 53894* which_alternative: Output Statement. (line 58) 53895* WHILE_BODY: Statements for C++. (line 6) 53896* WHILE_COND: Statements for C++. (line 6) 53897* WHILE_STMT: Statements for C++. (line 6) 53898* while_ultMN instruction pattern: Standard Names. (line 319) 53899* whopr: LTO. (line 6) 53900* widen_ssumM3 instruction pattern: Standard Names. (line 557) 53901* widen_usumM3 instruction pattern: Standard Names. (line 558) 53902* WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 110) 53903* window_save instruction pattern: Standard Names. (line 1914) 53904* WINT_TYPE: Type Layout. (line 178) 53905* WORDS_BIG_ENDIAN: Storage Layout. (line 28) 53906* WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 225) 53907* word_mode: Machine Modes. (line 462) 53908* WORD_REGISTER_OPERATIONS: Misc. (line 53) 53909* wpa: LTO. (line 6) 53910* X in constraint: Simple Constraints. (line 122) 53911* x-HOST: Host Fragment. (line 6) 53912* XCmode: Machine Modes. (line 199) 53913* XCOFF_DEBUGGING_INFO: DBX Options. (line 12) 53914* XEXP: Accessors. (line 6) 53915* XFmode: Machine Modes. (line 82) 53916* XImode: Machine Modes. (line 54) 53917* XINT: Accessors. (line 6) 53918* xm-MACHINE.h: Filesystem. (line 6) 53919* xm-MACHINE.h <1>: Host Misc. (line 6) 53920* xor: Arithmetic. (line 168) 53921* xor, canonicalization of: Insn Canonicalizations. 53922 (line 94) 53923* xorM3 instruction pattern: Standard Names. (line 416) 53924* XSTR: Accessors. (line 6) 53925* XVEC: Accessors. (line 38) 53926* XVECEXP: Accessors. (line 45) 53927* XVECLEN: Accessors. (line 41) 53928* XWINT: Accessors. (line 6) 53929* zero_extend: Conversions. (line 28) 53930* zero_extendMN2 instruction pattern: Standard Names. (line 1288) 53931* zero_extract: Bit-Fields. (line 30) 53932* zero_extract, canonicalization of: Insn Canonicalizations. 53933 (line 103) 53934 53935 53936 53937Tag Table: 53938Node: Top1789 53939Node: Contributing5024 53940Node: Portability5753 53941Node: Interface7541 53942Node: Libgcc10582 53943Node: Integer library routines12409 53944Node: Soft float library routines19377 53945Node: Decimal float library routines31315 53946Node: Fixed-point fractional library routines47073 53947Node: Exception handling routines147469 53948Node: Miscellaneous routines148576 53949Node: Languages150696 53950Node: Source Tree152243 53951Node: Configure Terms152825 53952Node: Top Level155781 53953Node: gcc Directory159211 53954Node: Subdirectories160163 53955Node: Configuration162331 53956Node: Config Fragments163051 53957Node: System Config164276 53958Node: Configuration Files165212 53959Node: Build167828 53960Node: Makefile168240 53961Ref: Makefile-Footnote-1175015 53962Ref: Makefile-Footnote-2175162 53963Node: Library Files175236 53964Node: Headers175798 53965Node: Documentation177881 53966Node: Texinfo Manuals178740 53967Node: Man Page Generation181069 53968Node: Miscellaneous Docs182982 53969Node: Front End184369 53970Node: Front End Directory188043 53971Node: Front End Config189359 53972Node: Front End Makefile192195 53973Node: Back End195963 53974Node: Testsuites200849 53975Node: Test Idioms201838 53976Node: Test Directives205236 53977Node: Directives205763 53978Node: Selectors216529 53979Node: Effective-Target Keywords217885 53980Ref: arm_fp_ok228449 53981Ref: arm_neon_ok229531 53982Ref: arm_neon_ok_no_float_abi229700 53983Ref: arm_neonv2_ok229867 53984Ref: arm_fp16_ok230034 53985Ref: arm_neon_fp16_ok230376 53986Ref: arm_vfp3_ok231252 53987Ref: arm_v8_1a_neon_ok231678 53988Ref: arm_v8_2a_fp16_scalar_ok232106 53989Ref: arm_v8_2a_fp16_neon_ok232557 53990Ref: arm_v8_2a_dotprod_neon_ok233032 53991Ref: arm_fp16fml_neon_ok233452 53992Ref: arm_coproc1_ok234294 53993Ref: arm_coproc2_ok234420 53994Ref: arm_coproc3_ok234648 53995Ref: stack_size_et244897 53996Node: Add Options247200 53997Ref: arm_fp16_ieee248218 53998Ref: arm_fp16_alternative248473 53999Ref: stack_size_ao250724 54000Node: Require Support250973 54001Node: Final Actions253802 54002Node: Ada Tests259461 54003Node: C Tests260624 54004Node: LTO Testing264996 54005Node: gcov Testing266639 54006Node: profopt Testing269629 54007Node: compat Testing271344 54008Node: Torture Tests275584 54009Node: GIMPLE Tests277218 54010Node: RTL Tests278461 54011Node: Options279767 54012Node: Option file format280208 54013Node: Option properties287197 54014Node: Passes301171 54015Node: Parsing pass301987 54016Node: Gimplification pass305515 54017Node: Pass manager307348 54018Node: Tree SSA passes309194 54019Node: RTL passes330736 54020Node: Optimization info343000 54021Node: Dump setup343819 54022Node: Optimization groups344948 54023Node: Dump files and streams345927 54024Node: Dump output verbosity347125 54025Node: Dump types348181 54026Node: Dump examples349671 54027Node: poly_int351152 54028Node: Overview of poly_int352632 54029Node: Consequences of using poly_int355236 54030Node: Comparisons involving poly_int356871 54031Node: Comparison functions for poly_int358509 54032Node: Properties of the poly_int comparisons359716 54033Node: Comparing potentially-unordered poly_ints362158 54034Node: Comparing ordered poly_ints363069 54035Node: Checking for a poly_int marker value365093 54036Node: Range checks on poly_ints365942 54037Node: Sorting poly_ints368596 54038Node: Arithmetic on poly_ints369369 54039Node: Using poly_int with C++ arithmetic operators370170 54040Node: wi arithmetic on poly_ints371701 54041Node: Division of poly_ints372553 54042Node: Other poly_int arithmetic374060 54043Node: Alignment of poly_ints375466 54044Node: Computing bounds on poly_ints378743 54045Node: Converting poly_ints379524 54046Node: Miscellaneous poly_int routines383071 54047Node: Guidelines for using poly_int383711 54048Node: GENERIC388643 54049Node: Deficiencies390521 54050Node: Tree overview390762 54051Node: Macros and Functions394886 54052Node: Identifiers395711 54053Node: Containers397320 54054Node: Types398477 54055Node: Declarations410551 54056Node: Working with declarations411046 54057Node: Internal structure416650 54058Node: Current structure hierarchy417034 54059Node: Adding new DECL node types419127 54060Node: Attributes423411 54061Node: Expression trees424655 54062Node: Constant expressions426409 54063Node: Storage References432501 54064Node: Unary and Binary Expressions436020 54065Node: Vectors456706 54066Node: Statements462375 54067Node: Basic Statements462907 54068Node: Blocks467534 54069Node: Statement Sequences469235 54070Node: Empty Statements469568 54071Node: Jumps470142 54072Node: Cleanups470795 54073Node: OpenMP472562 54074Node: OpenACC478407 54075Node: Functions479448 54076Node: Function Basics479919 54077Node: Function Properties483603 54078Node: Language-dependent trees486384 54079Node: C and C++ Trees487271 54080Node: Types for C++490175 54081Node: Namespaces495145 54082Node: Classes498251 54083Node: Functions for C++503159 54084Node: Statements for C++509410 54085Node: C++ Expressions517463 54086Node: Java Trees518968 54087Node: GIMPLE519081 54088Node: Tuple representation522746 54089Node: Class hierarchy of GIMPLE statements529706 54090Node: GIMPLE instruction set534694 54091Node: GIMPLE Exception Handling536326 54092Node: Temporaries538238 54093Ref: Temporaries-Footnote-1539556 54094Node: Operands539621 54095Node: Compound Expressions540382 54096Node: Compound Lvalues540616 54097Node: Conditional Expressions541378 54098Node: Logical Operators542037 54099Node: Manipulating GIMPLE statements549385 54100Node: Tuple specific accessors555321 54101Node: GIMPLE_ASM556100 54102Node: GIMPLE_ASSIGN558483 54103Node: GIMPLE_BIND563187 54104Node: GIMPLE_CALL565001 54105Node: GIMPLE_CATCH569144 54106Node: GIMPLE_COND570294 54107Node: GIMPLE_DEBUG573089 54108Node: GIMPLE_EH_FILTER577687 54109Node: GIMPLE_LABEL579250 54110Node: GIMPLE_GOTO579863 54111Node: GIMPLE_NOP580386 54112Node: GIMPLE_OMP_ATOMIC_LOAD580748 54113Node: GIMPLE_OMP_ATOMIC_STORE581744 54114Node: GIMPLE_OMP_CONTINUE582443 54115Node: GIMPLE_OMP_CRITICAL583922 54116Node: GIMPLE_OMP_FOR584916 54117Node: GIMPLE_OMP_MASTER588332 54118Node: GIMPLE_OMP_ORDERED588710 54119Node: GIMPLE_OMP_PARALLEL589104 54120Node: GIMPLE_OMP_RETURN591873 54121Node: GIMPLE_OMP_SECTION592518 54122Node: GIMPLE_OMP_SECTIONS593178 54123Node: GIMPLE_OMP_SINGLE594788 54124Node: GIMPLE_PHI595734 54125Node: GIMPLE_RESX597013 54126Node: GIMPLE_RETURN597732 54127Node: GIMPLE_SWITCH598306 54128Node: GIMPLE_TRY600181 54129Node: GIMPLE_WITH_CLEANUP_EXPR601953 54130Node: GIMPLE sequences602832 54131Node: Sequence iterators606038 54132Node: Adding a new GIMPLE statement code614495 54133Node: Statement and operand traversals615840 54134Node: Tree SSA618432 54135Node: Annotations620220 54136Node: SSA Operands620625 54137Node: SSA634700 54138Node: Alias analysis644406 54139Node: Memory model648180 54140Node: RTL649539 54141Node: RTL Objects651727 54142Node: RTL Classes655611 54143Node: Accessors660743 54144Node: Special Accessors662916 54145Node: Flags668703 54146Node: Machine Modes683966 54147Node: Constants701499 54148Node: Regs and Memory712778 54149Node: Arithmetic732030 54150Node: Comparisons742076 54151Node: Bit-Fields746368 54152Node: Vector Operations747920 54153Node: Conversions749953 54154Node: RTL Declarations754451 54155Node: Side Effects755295 54156Node: Incdec772306 54157Node: Assembler775642 54158Node: Debug Information777187 54159Node: Insns779114 54160Node: Calls807007 54161Node: Sharing809600 54162Node: Reading RTL812795 54163Node: Control Flow813786 54164Node: Basic Blocks815555 54165Node: Edges821009 54166Node: Profile information829628 54167Node: Maintaining the CFG834312 54168Node: Liveness information840080 54169Node: Loop Analysis and Representation842206 54170Node: Loop representation843242 54171Node: Loop querying850805 54172Node: Loop manipulation853626 54173Node: LCSSA855962 54174Node: Scalar evolutions858031 54175Node: loop-iv861275 54176Node: Number of iterations863197 54177Node: Dependency analysis867278 54178Node: Machine Desc873629 54179Node: Overview876192 54180Node: Patterns878232 54181Node: Example882541 54182Node: RTL Template884002 54183Node: Output Template894658 54184Node: Output Statement898839 54185Node: Predicates903178 54186Node: Machine-Independent Predicates906096 54187Node: Defining Predicates911040 54188Node: Constraints917003 54189Node: Simple Constraints918472 54190Node: Multi-Alternative931312 54191Node: Class Preferences934521 54192Node: Modifiers935413 54193Node: Machine Constraints940146 54194Node: Disable Insn Alternatives1002836 54195Node: Define Constraints1006328 54196Node: C Constraint Interface1013723 54197Node: Standard Names1016850 54198Ref: shift patterns1048896 54199Ref: prologue instruction pattern1100550 54200Ref: window_save instruction pattern1101043 54201Ref: epilogue instruction pattern1101320 54202Node: Pattern Ordering1120476 54203Node: Dependent Patterns1121712 54204Node: Jump Patterns1123332 54205Ref: Jump Patterns-Footnote-11125479 54206Node: Looping Patterns1125527 54207Node: Insn Canonicalizations1130256 54208Node: Expander Definitions1135463 54209Node: Insn Splitting1143677 54210Node: Including Patterns1153281 54211Node: Peephole Definitions1155065 54212Node: define_peephole1156318 54213Node: define_peephole21162648 54214Node: Insn Attributes1165714 54215Node: Defining Attributes1166896 54216Ref: define_enum_attr1170389 54217Node: Expressions1171425 54218Node: Tagging Insns1178175 54219Node: Attr Example1182528 54220Node: Insn Lengths1184901 54221Node: Constant Attributes1188309 54222Node: Mnemonic Attribute1189485 54223Node: Delay Slots1191004 54224Node: Processor pipeline description1194227 54225Ref: Processor pipeline description-Footnote-11213044 54226Node: Conditional Execution1213368 54227Node: Define Subst1216851 54228Node: Define Subst Example1218887 54229Node: Define Subst Pattern Matching1221881 54230Node: Define Subst Output Template1223107 54231Node: Constant Definitions1225177 54232Ref: define_enum1228959 54233Node: Iterators1229447 54234Node: Mode Iterators1230025 54235Node: Defining Mode Iterators1231003 54236Node: Substitutions1232497 54237Node: Examples1234739 54238Node: Code Iterators1236187 54239Node: Int Iterators1238466 54240Node: Subst Iterators1240912 54241Node: Target Macros1242604 54242Node: Target Structure1245616 54243Node: Driver1247732 54244Node: Run-time Target1266702 54245Node: Per-Function Data1276413 54246Node: Storage Layout1279177 54247Node: Type Layout1306494 54248Node: Registers1319835 54249Node: Register Basics1320809 54250Node: Allocation Order1326434 54251Node: Values in Registers1328918 54252Node: Leaf Functions1336394 54253Node: Stack Registers1339253 54254Node: Register Classes1340525 54255Node: Stack and Calling1375307 54256Node: Frame Layout1375913 54257Node: Exception Handling1387748 54258Node: Stack Checking1393958 54259Node: Frame Registers1399334 54260Node: Elimination1407885 54261Node: Stack Arguments1411741 54262Node: Register Arguments1418937 54263Node: Scalar Return1442821 54264Node: Aggregate Return1449277 54265Node: Caller Saves1453831 54266Node: Function Entry1454573 54267Node: Profiling1466125 54268Node: Tail Calls1468235 54269Node: Shrink-wrapping separate components1470146 54270Node: Stack Smashing Protection1473187 54271Node: Miscellaneous Register Hooks1475110 54272Node: Varargs1475976 54273Node: Trampolines1486080 54274Node: Library Calls1493244 54275Node: Addressing Modes1497928 54276Node: Anchored Addresses1524114 54277Node: Condition Code1526757 54278Node: CC0 Condition Codes1529084 54279Node: MODE_CC Condition Codes1532330 54280Node: Costs1539126 54281Node: Scheduling1560498 54282Node: Sections1584420 54283Node: PIC1600349 54284Node: Assembler Format1602408 54285Node: File Framework1603546 54286Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS1611145 54287Node: Data Output1614415 54288Node: Uninitialized Data1622361 54289Node: Label Output1627372 54290Node: Initialization1651983 54291Node: Macros for Initialization1657944 54292Node: Instruction Output1664663 54293Node: Dispatch Tables1675292 54294Node: Exception Region Output1679692 54295Node: Alignment Output1686774 54296Node: Debugging Info1691377 54297Node: All Debuggers1692031 54298Node: DBX Options1694803 54299Node: DBX Hooks1700241 54300Node: File Names and DBX1701550 54301Node: DWARF1703654 54302Node: VMS Debug1709469 54303Node: Floating Point1710048 54304Node: Mode Switching1712803 54305Node: Target Attributes1717240 54306Node: Emulated TLS1726206 54307Node: MIPS Coprocessors1729596 54308Node: PCH Target1730755 54309Node: C++ ABI1732597 54310Node: Named Address Spaces1737391 54311Node: Misc1743307 54312Ref: TARGET_SHIFT_TRUNCATION_MASK1751178 54313Node: Host Config1806622 54314Node: Host Common1807691 54315Node: Filesystem1810065 54316Node: Host Misc1814180 54317Node: Fragments1816629 54318Node: Target Fragment1817824 54319Node: Host Fragment1828637 54320Node: Collect21828877 54321Node: Header Dirs1831513 54322Node: Type Information1832936 54323Node: GTY Options1836212 54324Node: Inheritance and GTY1847471 54325Ref: Inheritance and GTY-Footnote-11849036 54326Node: User GC1849306 54327Node: GGC Roots1853045 54328Node: Files1853758 54329Node: Invoking the garbage collector1856465 54330Node: Troubleshooting1857970 54331Node: Plugins1859045 54332Node: Plugins loading1860174 54333Node: Plugin API1861273 54334Node: Plugins pass1868999 54335Node: Plugins GC1870970 54336Node: Plugins description1872688 54337Node: Plugins attr1873224 54338Node: Plugins recording1875504 54339Node: Plugins gate1876354 54340Node: Plugins tracking1876945 54341Node: Plugins building1877533 54342Node: LTO1881035 54343Node: LTO Overview1881907 54344Node: LTO object file layout1887734 54345Node: IPA1892364 54346Node: WHOPR1901329 54347Node: Internal flags1905889 54348Node: Match and Simplify1907300 54349Node: GIMPLE API1908254 54350Node: The Language1911049 54351Node: Funding1922412 54352Node: GNU Project1924911 54353Node: Copying1925560 54354Node: GNU Free Documentation License1963072 54355Node: Contributors1988193 54356Node: Option Index2029131 54357Node: Concept Index2030008 54358 54359End Tag Table 54360