1This is doc/gccint.info, produced by makeinfo version 4.12 from 2/space/rguenther/gcc-5.4.0/gcc-5.4.0/gcc/doc/gccint.texi. 3 4Copyright (C) 1988-2015 Free Software Foundation, Inc. 5 6 Permission is granted to copy, distribute and/or modify this document 7under the terms of the GNU Free Documentation License, Version 1.3 or 8any later version published by the Free Software Foundation; with the 9Invariant Sections being "Funding Free Software", the Front-Cover Texts 10being (a) (see below), and with the Back-Cover Texts being (b) (see 11below). A copy of the license is included in the section entitled "GNU 12Free Documentation License". 13 14 (a) The FSF's Front-Cover Text is: 15 16 A GNU Manual 17 18 (b) The FSF's Back-Cover Text is: 19 20 You have freedom to copy and modify this GNU Manual, like GNU 21software. Copies published by the Free Software Foundation raise 22funds for GNU development. 23 24INFO-DIR-SECTION Software development 25START-INFO-DIR-ENTRY 26* gccint: (gccint). Internals of the GNU Compiler Collection. 27END-INFO-DIR-ENTRY 28 This file documents the internals of the GNU compilers. 29 30 Copyright (C) 1988-2015 Free Software Foundation, Inc. 31 32 Permission is granted to copy, distribute and/or modify this document 33under the terms of the GNU Free Documentation License, Version 1.3 or 34any later version published by the Free Software Foundation; with the 35Invariant Sections being "Funding Free Software", the Front-Cover Texts 36being (a) (see below), and with the Back-Cover Texts being (b) (see 37below). A copy of the license is included in the section entitled "GNU 38Free Documentation License". 39 40 (a) The FSF's Front-Cover Text is: 41 42 A GNU Manual 43 44 (b) The FSF's Back-Cover Text is: 45 46 You have freedom to copy and modify this GNU Manual, like GNU 47software. Copies published by the Free Software Foundation raise 48funds for GNU development. 49 50 51 52File: gccint.info, Node: Top, Next: Contributing, Up: (DIR) 53 54Introduction 55************ 56 57This manual documents the internals of the GNU compilers, including how 58to port them to new targets and some information about how to write 59front ends for new languages. It corresponds to the compilers 60(GCC) version 5.4.0. The use of the GNU compilers is documented in a 61separate manual. *Note Introduction: (gcc)Top. 62 63 This manual is mainly a reference manual rather than a tutorial. It 64discusses how to contribute to GCC (*note Contributing::), the 65characteristics of the machines supported by GCC as hosts and targets 66(*note Portability::), how GCC relates to the ABIs on such systems 67(*note Interface::), and the characteristics of the languages for which 68GCC front ends are written (*note Languages::). It then describes the 69GCC source tree structure and build system, some of the interfaces to 70GCC front ends, and how support for a target system is implemented in 71GCC. 72 73 Additional tutorial information is linked to from 74`http://gcc.gnu.org/readings.html'. 75 76* Menu: 77 78* Contributing:: How to contribute to testing and developing GCC. 79* Portability:: Goals of GCC's portability features. 80* Interface:: Function-call interface of GCC output. 81* Libgcc:: Low-level runtime library used by GCC. 82* Languages:: Languages for which GCC front ends are written. 83* Source Tree:: GCC source tree structure and build system. 84* Testsuites:: GCC testsuites. 85* Options:: Option specification files. 86* Passes:: Order of passes, what they do, and what each file is for. 87* GENERIC:: Language-independent representation generated by Front Ends 88* GIMPLE:: Tuple representation used by Tree SSA optimizers 89* Tree SSA:: Analysis and optimization of GIMPLE 90* RTL:: Machine-dependent low-level intermediate representation. 91* Control Flow:: Maintaining and manipulating the control flow graph. 92* Loop Analysis and Representation:: Analysis and representation of loops 93* Machine Desc:: How to write machine description instruction patterns. 94* Target Macros:: How to write the machine description C macros and functions. 95* Host Config:: Writing the `xm-MACHINE.h' file. 96* Fragments:: Writing the `t-TARGET' and `x-HOST' files. 97* Collect2:: How `collect2' works; how it finds `ld'. 98* Header Dirs:: Understanding the standard header file directories. 99* Type Information:: GCC's memory management; generating type information. 100* Plugins:: Extending the compiler with plugins. 101* LTO:: Using Link-Time Optimization. 102 103* Match and Simplify:: How to write expression simplification patterns for GIMPLE and GENERIC 104* Funding:: How to help assure funding for free software. 105* GNU Project:: The GNU Project and GNU/Linux. 106 107* Copying:: GNU General Public License says 108 how you can copy and share GCC. 109* GNU Free Documentation License:: How you can copy and share this manual. 110* Contributors:: People who have contributed to GCC. 111 112* Option Index:: Index to command line options. 113* Concept Index:: Index of concepts and symbol names. 114 115 116File: gccint.info, Node: Contributing, Next: Portability, Prev: Top, Up: Top 117 1181 Contributing to GCC Development 119********************************* 120 121If you would like to help pretest GCC releases to assure they work well, 122current development sources are available by SVN (see 123`http://gcc.gnu.org/svn.html'). Source and binary snapshots are also 124available for FTP; see `http://gcc.gnu.org/snapshots.html'. 125 126 If you would like to work on improvements to GCC, please read the 127advice at these URLs: 128 129 `http://gcc.gnu.org/contribute.html' 130 `http://gcc.gnu.org/contributewhy.html' 131 132for information on how to make useful contributions and avoid 133duplication of effort. Suggested projects are listed at 134`http://gcc.gnu.org/projects/'. 135 136 137File: gccint.info, Node: Portability, Next: Interface, Prev: Contributing, Up: Top 138 1392 GCC and Portability 140********************* 141 142GCC itself aims to be portable to any machine where `int' is at least a 14332-bit type. It aims to target machines with a flat (non-segmented) 144byte addressed data address space (the code address space can be 145separate). Target ABIs may have 8, 16, 32 or 64-bit `int' type. `char' 146can be wider than 8 bits. 147 148 GCC gets most of the information about the target machine from a 149machine description which gives an algebraic formula for each of the 150machine's instructions. This is a very clean way to describe the 151target. But when the compiler needs information that is difficult to 152express in this fashion, ad-hoc parameters have been defined for 153machine descriptions. The purpose of portability is to reduce the 154total work needed on the compiler; it was not of interest for its own 155sake. 156 157 GCC does not contain machine dependent code, but it does contain code 158that depends on machine parameters such as endianness (whether the most 159significant byte has the highest or lowest address of the bytes in a 160word) and the availability of autoincrement addressing. In the 161RTL-generation pass, it is often necessary to have multiple strategies 162for generating code for a particular kind of syntax tree, strategies 163that are usable for different combinations of parameters. Often, not 164all possible cases have been addressed, but only the common ones or 165only the ones that have been encountered. As a result, a new target 166may require additional strategies. You will know if this happens 167because the compiler will call `abort'. Fortunately, the new 168strategies can be added in a machine-independent fashion, and will 169affect only the target machines that need them. 170 171 172File: gccint.info, Node: Interface, Next: Libgcc, Prev: Portability, Up: Top 173 1743 Interfacing to GCC Output 175*************************** 176 177GCC is normally configured to use the same function calling convention 178normally in use on the target system. This is done with the 179machine-description macros described (*note Target Macros::). 180 181 However, returning of structure and union values is done differently on 182some target machines. As a result, functions compiled with PCC 183returning such types cannot be called from code compiled with GCC, and 184vice versa. This does not cause trouble often because few Unix library 185routines return structures or unions. 186 187 GCC code returns structures and unions that are 1, 2, 4 or 8 bytes 188long in the same registers used for `int' or `double' return values. 189(GCC typically allocates variables of such types in registers also.) 190Structures and unions of other sizes are returned by storing them into 191an address passed by the caller (usually in a register). The target 192hook `TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address. 193 194 By contrast, PCC on most target machines returns structures and unions 195of any size by copying the data into an area of static storage, and then 196returning the address of that storage as if it were a pointer value. 197The caller must copy the data from that memory area to the place where 198the value is wanted. This is slower than the method used by GCC, and 199fails to be reentrant. 200 201 On some target machines, such as RISC machines and the 80386, the 202standard system convention is to pass to the subroutine the address of 203where to return the value. On these machines, GCC has been configured 204to be compatible with the standard compiler, when this method is used. 205It may not be compatible for structures of 1, 2, 4 or 8 bytes. 206 207 GCC uses the system's standard convention for passing arguments. On 208some machines, the first few arguments are passed in registers; in 209others, all are passed on the stack. It would be possible to use 210registers for argument passing on any machine, and this would probably 211result in a significant speedup. But the result would be complete 212incompatibility with code that follows the standard convention. So this 213change is practical only if you are switching to GCC as the sole C 214compiler for the system. We may implement register argument passing on 215certain machines once we have a complete GNU system so that we can 216compile the libraries with GCC. 217 218 On some machines (particularly the SPARC), certain types of arguments 219are passed "by invisible reference". This means that the value is 220stored in memory, and the address of the memory location is passed to 221the subroutine. 222 223 If you use `longjmp', beware of automatic variables. ISO C says that 224automatic variables that are not declared `volatile' have undefined 225values after a `longjmp'. And this is all GCC promises to do, because 226it is very difficult to restore register variables correctly, and one 227of GCC's features is that it can put variables in registers without 228your asking it to. 229 230 231File: gccint.info, Node: Libgcc, Next: Languages, Prev: Interface, Up: Top 232 2334 The GCC low-level runtime library 234*********************************** 235 236GCC provides a low-level runtime library, `libgcc.a' or `libgcc_s.so.1' 237on some platforms. GCC generates calls to routines in this library 238automatically, whenever it needs to perform some operation that is too 239complicated to emit inline code for. 240 241 Most of the routines in `libgcc' handle arithmetic operations that the 242target processor cannot perform directly. This includes integer 243multiply and divide on some machines, and all floating-point and 244fixed-point operations on other machines. `libgcc' also includes 245routines for exception handling, and a handful of miscellaneous 246operations. 247 248 Some of these routines can be defined in mostly machine-independent C. 249Others must be hand-written in assembly language for each processor 250that needs them. 251 252 GCC will also generate calls to C library routines, such as `memcpy' 253and `memset', in some cases. The set of routines that GCC may possibly 254use is documented in *note Other Builtins: (gcc)Other Builtins. 255 256 These routines take arguments and return values of a specific machine 257mode, not a specific C type. *Note Machine Modes::, for an explanation 258of this concept. For illustrative purposes, in this chapter the 259floating point type `float' is assumed to correspond to `SFmode'; 260`double' to `DFmode'; and `long double' to both `TFmode' and `XFmode'. 261Similarly, the integer types `int' and `unsigned int' correspond to 262`SImode'; `long' and `unsigned long' to `DImode'; and `long long' and 263`unsigned long long' to `TImode'. 264 265* Menu: 266 267* Integer library routines:: 268* Soft float library routines:: 269* Decimal float library routines:: 270* Fixed-point fractional library routines:: 271* Exception handling routines:: 272* Miscellaneous routines:: 273 274 275File: gccint.info, Node: Integer library routines, Next: Soft float library routines, Up: Libgcc 276 2774.1 Routines for integer arithmetic 278=================================== 279 280The integer arithmetic routines are used on platforms that don't provide 281hardware support for arithmetic operations on some modes. 282 2834.1.1 Arithmetic functions 284-------------------------- 285 286 -- Runtime Function: int __ashlsi3 (int A, int B) 287 -- Runtime Function: long __ashldi3 (long A, int B) 288 -- Runtime Function: long long __ashlti3 (long long A, int B) 289 These functions return the result of shifting A left by B bits. 290 291 -- Runtime Function: int __ashrsi3 (int A, int B) 292 -- Runtime Function: long __ashrdi3 (long A, int B) 293 -- Runtime Function: long long __ashrti3 (long long A, int B) 294 These functions return the result of arithmetically shifting A 295 right by B bits. 296 297 -- Runtime Function: int __divsi3 (int A, int B) 298 -- Runtime Function: long __divdi3 (long A, long B) 299 -- Runtime Function: long long __divti3 (long long A, long long B) 300 These functions return the quotient of the signed division of A and 301 B. 302 303 -- Runtime Function: int __lshrsi3 (int A, int B) 304 -- Runtime Function: long __lshrdi3 (long A, int B) 305 -- Runtime Function: long long __lshrti3 (long long A, int B) 306 These functions return the result of logically shifting A right by 307 B bits. 308 309 -- Runtime Function: int __modsi3 (int A, int B) 310 -- Runtime Function: long __moddi3 (long A, long B) 311 -- Runtime Function: long long __modti3 (long long A, long long B) 312 These functions return the remainder of the signed division of A 313 and B. 314 315 -- Runtime Function: int __mulsi3 (int A, int B) 316 -- Runtime Function: long __muldi3 (long A, long B) 317 -- Runtime Function: long long __multi3 (long long A, long long B) 318 These functions return the product of A and B. 319 320 -- Runtime Function: long __negdi2 (long A) 321 -- Runtime Function: long long __negti2 (long long A) 322 These functions return the negation of A. 323 324 -- Runtime Function: unsigned int __udivsi3 (unsigned int A, unsigned 325 int B) 326 -- Runtime Function: unsigned long __udivdi3 (unsigned long A, 327 unsigned long B) 328 -- Runtime Function: unsigned long long __udivti3 (unsigned long long 329 A, unsigned long long B) 330 These functions return the quotient of the unsigned division of A 331 and B. 332 333 -- Runtime Function: unsigned long __udivmoddi4 (unsigned long A, 334 unsigned long B, unsigned long *C) 335 -- Runtime Function: unsigned long long __udivmodti4 (unsigned long 336 long A, unsigned long long B, unsigned long long *C) 337 These functions calculate both the quotient and remainder of the 338 unsigned division of A and B. The return value is the quotient, 339 and the remainder is placed in variable pointed to by C. 340 341 -- Runtime Function: unsigned int __umodsi3 (unsigned int A, unsigned 342 int B) 343 -- Runtime Function: unsigned long __umoddi3 (unsigned long A, 344 unsigned long B) 345 -- Runtime Function: unsigned long long __umodti3 (unsigned long long 346 A, unsigned long long B) 347 These functions return the remainder of the unsigned division of A 348 and B. 349 3504.1.2 Comparison functions 351-------------------------- 352 353The following functions implement integral comparisons. These functions 354implement a low-level compare, upon which the higher level comparison 355operators (such as less than and greater than or equal to) can be 356constructed. The returned values lie in the range zero to two, to allow 357the high-level operators to be implemented by testing the returned 358result using either signed or unsigned comparison. 359 360 -- Runtime Function: int __cmpdi2 (long A, long B) 361 -- Runtime Function: int __cmpti2 (long long A, long long B) 362 These functions perform a signed comparison of A and B. If A is 363 less than B, they return 0; if A is greater than B, they return 2; 364 and if A and B are equal they return 1. 365 366 -- Runtime Function: int __ucmpdi2 (unsigned long A, unsigned long B) 367 -- Runtime Function: int __ucmpti2 (unsigned long long A, unsigned 368 long long B) 369 These functions perform an unsigned comparison of A and B. If A 370 is less than B, they return 0; if A is greater than B, they return 371 2; and if A and B are equal they return 1. 372 3734.1.3 Trapping arithmetic functions 374----------------------------------- 375 376The following functions implement trapping arithmetic. These functions 377call the libc function `abort' upon signed arithmetic overflow. 378 379 -- Runtime Function: int __absvsi2 (int A) 380 -- Runtime Function: long __absvdi2 (long A) 381 These functions return the absolute value of A. 382 383 -- Runtime Function: int __addvsi3 (int A, int B) 384 -- Runtime Function: long __addvdi3 (long A, long B) 385 These functions return the sum of A and B; that is `A + B'. 386 387 -- Runtime Function: int __mulvsi3 (int A, int B) 388 -- Runtime Function: long __mulvdi3 (long A, long B) 389 The functions return the product of A and B; that is `A * B'. 390 391 -- Runtime Function: int __negvsi2 (int A) 392 -- Runtime Function: long __negvdi2 (long A) 393 These functions return the negation of A; that is `-A'. 394 395 -- Runtime Function: int __subvsi3 (int A, int B) 396 -- Runtime Function: long __subvdi3 (long A, long B) 397 These functions return the difference between B and A; that is `A 398 - B'. 399 4004.1.4 Bit operations 401-------------------- 402 403 -- Runtime Function: int __clzsi2 (unsigned int A) 404 -- Runtime Function: int __clzdi2 (unsigned long A) 405 -- Runtime Function: int __clzti2 (unsigned long long A) 406 These functions return the number of leading 0-bits in A, starting 407 at the most significant bit position. If A is zero, the result is 408 undefined. 409 410 -- Runtime Function: int __ctzsi2 (unsigned int A) 411 -- Runtime Function: int __ctzdi2 (unsigned long A) 412 -- Runtime Function: int __ctzti2 (unsigned long long A) 413 These functions return the number of trailing 0-bits in A, starting 414 at the least significant bit position. If A is zero, the result is 415 undefined. 416 417 -- Runtime Function: int __ffsdi2 (unsigned long A) 418 -- Runtime Function: int __ffsti2 (unsigned long long A) 419 These functions return the index of the least significant 1-bit in 420 A, or the value zero if A is zero. The least significant bit is 421 index one. 422 423 -- Runtime Function: int __paritysi2 (unsigned int A) 424 -- Runtime Function: int __paritydi2 (unsigned long A) 425 -- Runtime Function: int __parityti2 (unsigned long long A) 426 These functions return the value zero if the number of bits set in 427 A is even, and the value one otherwise. 428 429 -- Runtime Function: int __popcountsi2 (unsigned int A) 430 -- Runtime Function: int __popcountdi2 (unsigned long A) 431 -- Runtime Function: int __popcountti2 (unsigned long long A) 432 These functions return the number of bits set in A. 433 434 -- Runtime Function: int32_t __bswapsi2 (int32_t A) 435 -- Runtime Function: int64_t __bswapdi2 (int64_t A) 436 These functions return the A byteswapped. 437 438 439File: gccint.info, Node: Soft float library routines, Next: Decimal float library routines, Prev: Integer library routines, Up: Libgcc 440 4414.2 Routines for floating point emulation 442========================================= 443 444The software floating point library is used on machines which do not 445have hardware support for floating point. It is also used whenever 446`-msoft-float' is used to disable generation of floating point 447instructions. (Not all targets support this switch.) 448 449 For compatibility with other compilers, the floating point emulation 450routines can be renamed with the `DECLARE_LIBRARY_RENAMES' macro (*note 451Library Calls::). In this section, the default names are used. 452 453 Presently the library does not support `XFmode', which is used for 454`long double' on some architectures. 455 4564.2.1 Arithmetic functions 457-------------------------- 458 459 -- Runtime Function: float __addsf3 (float A, float B) 460 -- Runtime Function: double __adddf3 (double A, double B) 461 -- Runtime Function: long double __addtf3 (long double A, long double 462 B) 463 -- Runtime Function: long double __addxf3 (long double A, long double 464 B) 465 These functions return the sum of A and B. 466 467 -- Runtime Function: float __subsf3 (float A, float B) 468 -- Runtime Function: double __subdf3 (double A, double B) 469 -- Runtime Function: long double __subtf3 (long double A, long double 470 B) 471 -- Runtime Function: long double __subxf3 (long double A, long double 472 B) 473 These functions return the difference between B and A; that is, 474 A - B. 475 476 -- Runtime Function: float __mulsf3 (float A, float B) 477 -- Runtime Function: double __muldf3 (double A, double B) 478 -- Runtime Function: long double __multf3 (long double A, long double 479 B) 480 -- Runtime Function: long double __mulxf3 (long double A, long double 481 B) 482 These functions return the product of A and B. 483 484 -- Runtime Function: float __divsf3 (float A, float B) 485 -- Runtime Function: double __divdf3 (double A, double B) 486 -- Runtime Function: long double __divtf3 (long double A, long double 487 B) 488 -- Runtime Function: long double __divxf3 (long double A, long double 489 B) 490 These functions return the quotient of A and B; that is, A / B. 491 492 -- Runtime Function: float __negsf2 (float A) 493 -- Runtime Function: double __negdf2 (double A) 494 -- Runtime Function: long double __negtf2 (long double A) 495 -- Runtime Function: long double __negxf2 (long double A) 496 These functions return the negation of A. They simply flip the 497 sign bit, so they can produce negative zero and negative NaN. 498 4994.2.2 Conversion functions 500-------------------------- 501 502 -- Runtime Function: double __extendsfdf2 (float A) 503 -- Runtime Function: long double __extendsftf2 (float A) 504 -- Runtime Function: long double __extendsfxf2 (float A) 505 -- Runtime Function: long double __extenddftf2 (double A) 506 -- Runtime Function: long double __extenddfxf2 (double A) 507 These functions extend A to the wider mode of their return type. 508 509 -- Runtime Function: double __truncxfdf2 (long double A) 510 -- Runtime Function: double __trunctfdf2 (long double A) 511 -- Runtime Function: float __truncxfsf2 (long double A) 512 -- Runtime Function: float __trunctfsf2 (long double A) 513 -- Runtime Function: float __truncdfsf2 (double A) 514 These functions truncate A to the narrower mode of their return 515 type, rounding toward zero. 516 517 -- Runtime Function: int __fixsfsi (float A) 518 -- Runtime Function: int __fixdfsi (double A) 519 -- Runtime Function: int __fixtfsi (long double A) 520 -- Runtime Function: int __fixxfsi (long double A) 521 These functions convert A to a signed integer, rounding toward 522 zero. 523 524 -- Runtime Function: long __fixsfdi (float A) 525 -- Runtime Function: long __fixdfdi (double A) 526 -- Runtime Function: long __fixtfdi (long double A) 527 -- Runtime Function: long __fixxfdi (long double A) 528 These functions convert A to a signed long, rounding toward zero. 529 530 -- Runtime Function: long long __fixsfti (float A) 531 -- Runtime Function: long long __fixdfti (double A) 532 -- Runtime Function: long long __fixtfti (long double A) 533 -- Runtime Function: long long __fixxfti (long double A) 534 These functions convert A to a signed long long, rounding toward 535 zero. 536 537 -- Runtime Function: unsigned int __fixunssfsi (float A) 538 -- Runtime Function: unsigned int __fixunsdfsi (double A) 539 -- Runtime Function: unsigned int __fixunstfsi (long double A) 540 -- Runtime Function: unsigned int __fixunsxfsi (long double A) 541 These functions convert A to an unsigned integer, rounding toward 542 zero. Negative values all become zero. 543 544 -- Runtime Function: unsigned long __fixunssfdi (float A) 545 -- Runtime Function: unsigned long __fixunsdfdi (double A) 546 -- Runtime Function: unsigned long __fixunstfdi (long double A) 547 -- Runtime Function: unsigned long __fixunsxfdi (long double A) 548 These functions convert A to an unsigned long, rounding toward 549 zero. Negative values all become zero. 550 551 -- Runtime Function: unsigned long long __fixunssfti (float A) 552 -- Runtime Function: unsigned long long __fixunsdfti (double A) 553 -- Runtime Function: unsigned long long __fixunstfti (long double A) 554 -- Runtime Function: unsigned long long __fixunsxfti (long double A) 555 These functions convert A to an unsigned long long, rounding 556 toward zero. Negative values all become zero. 557 558 -- Runtime Function: float __floatsisf (int I) 559 -- Runtime Function: double __floatsidf (int I) 560 -- Runtime Function: long double __floatsitf (int I) 561 -- Runtime Function: long double __floatsixf (int I) 562 These functions convert I, a signed integer, to floating point. 563 564 -- Runtime Function: float __floatdisf (long I) 565 -- Runtime Function: double __floatdidf (long I) 566 -- Runtime Function: long double __floatditf (long I) 567 -- Runtime Function: long double __floatdixf (long I) 568 These functions convert I, a signed long, to floating point. 569 570 -- Runtime Function: float __floattisf (long long I) 571 -- Runtime Function: double __floattidf (long long I) 572 -- Runtime Function: long double __floattitf (long long I) 573 -- Runtime Function: long double __floattixf (long long I) 574 These functions convert I, a signed long long, to floating point. 575 576 -- Runtime Function: float __floatunsisf (unsigned int I) 577 -- Runtime Function: double __floatunsidf (unsigned int I) 578 -- Runtime Function: long double __floatunsitf (unsigned int I) 579 -- Runtime Function: long double __floatunsixf (unsigned int I) 580 These functions convert I, an unsigned integer, to floating point. 581 582 -- Runtime Function: float __floatundisf (unsigned long I) 583 -- Runtime Function: double __floatundidf (unsigned long I) 584 -- Runtime Function: long double __floatunditf (unsigned long I) 585 -- Runtime Function: long double __floatundixf (unsigned long I) 586 These functions convert I, an unsigned long, to floating point. 587 588 -- Runtime Function: float __floatuntisf (unsigned long long I) 589 -- Runtime Function: double __floatuntidf (unsigned long long I) 590 -- Runtime Function: long double __floatuntitf (unsigned long long I) 591 -- Runtime Function: long double __floatuntixf (unsigned long long I) 592 These functions convert I, an unsigned long long, to floating 593 point. 594 5954.2.3 Comparison functions 596-------------------------- 597 598There are two sets of basic comparison functions. 599 600 -- Runtime Function: int __cmpsf2 (float A, float B) 601 -- Runtime Function: int __cmpdf2 (double A, double B) 602 -- Runtime Function: int __cmptf2 (long double A, long double B) 603 These functions calculate a <=> b. That is, if A is less than B, 604 they return -1; if A is greater than B, they return 1; and if A 605 and B are equal they return 0. If either argument is NaN they 606 return 1, but you should not rely on this; if NaN is a 607 possibility, use one of the higher-level comparison functions. 608 609 -- Runtime Function: int __unordsf2 (float A, float B) 610 -- Runtime Function: int __unorddf2 (double A, double B) 611 -- Runtime Function: int __unordtf2 (long double A, long double B) 612 These functions return a nonzero value if either argument is NaN, 613 otherwise 0. 614 615 There is also a complete group of higher level functions which 616correspond directly to comparison operators. They implement the ISO C 617semantics for floating-point comparisons, taking NaN into account. Pay 618careful attention to the return values defined for each set. Under the 619hood, all of these routines are implemented as 620 621 if (__unordXf2 (a, b)) 622 return E; 623 return __cmpXf2 (a, b); 624 625where E is a constant chosen to give the proper behavior for NaN. 626Thus, the meaning of the return value is different for each set. Do 627not rely on this implementation; only the semantics documented below 628are guaranteed. 629 630 -- Runtime Function: int __eqsf2 (float A, float B) 631 -- Runtime Function: int __eqdf2 (double A, double B) 632 -- Runtime Function: int __eqtf2 (long double A, long double B) 633 These functions return zero if neither argument is NaN, and A and 634 B are equal. 635 636 -- Runtime Function: int __nesf2 (float A, float B) 637 -- Runtime Function: int __nedf2 (double A, double B) 638 -- Runtime Function: int __netf2 (long double A, long double B) 639 These functions return a nonzero value if either argument is NaN, 640 or if A and B are unequal. 641 642 -- Runtime Function: int __gesf2 (float A, float B) 643 -- Runtime Function: int __gedf2 (double A, double B) 644 -- Runtime Function: int __getf2 (long double A, long double B) 645 These functions return a value greater than or equal to zero if 646 neither argument is NaN, and A is greater than or equal to B. 647 648 -- Runtime Function: int __ltsf2 (float A, float B) 649 -- Runtime Function: int __ltdf2 (double A, double B) 650 -- Runtime Function: int __lttf2 (long double A, long double B) 651 These functions return a value less than zero if neither argument 652 is NaN, and A is strictly less than B. 653 654 -- Runtime Function: int __lesf2 (float A, float B) 655 -- Runtime Function: int __ledf2 (double A, double B) 656 -- Runtime Function: int __letf2 (long double A, long double B) 657 These functions return a value less than or equal to zero if 658 neither argument is NaN, and A is less than or equal to B. 659 660 -- Runtime Function: int __gtsf2 (float A, float B) 661 -- Runtime Function: int __gtdf2 (double A, double B) 662 -- Runtime Function: int __gttf2 (long double A, long double B) 663 These functions return a value greater than zero if neither 664 argument is NaN, and A is strictly greater than B. 665 6664.2.4 Other floating-point functions 667------------------------------------ 668 669 -- Runtime Function: float __powisf2 (float A, int B) 670 -- Runtime Function: double __powidf2 (double A, int B) 671 -- Runtime Function: long double __powitf2 (long double A, int B) 672 -- Runtime Function: long double __powixf2 (long double A, int B) 673 These functions convert raise A to the power B. 674 675 -- Runtime Function: complex float __mulsc3 (float A, float B, float 676 C, float D) 677 -- Runtime Function: complex double __muldc3 (double A, double B, 678 double C, double D) 679 -- Runtime Function: complex long double __multc3 (long double A, long 680 double B, long double C, long double D) 681 -- Runtime Function: complex long double __mulxc3 (long double A, long 682 double B, long double C, long double D) 683 These functions return the product of A + iB and C + iD, following 684 the rules of C99 Annex G. 685 686 -- Runtime Function: complex float __divsc3 (float A, float B, float 687 C, float D) 688 -- Runtime Function: complex double __divdc3 (double A, double B, 689 double C, double D) 690 -- Runtime Function: complex long double __divtc3 (long double A, long 691 double B, long double C, long double D) 692 -- Runtime Function: complex long double __divxc3 (long double A, long 693 double B, long double C, long double D) 694 These functions return the quotient of A + iB and C + iD (i.e., (A 695 + iB) / (C + iD)), following the rules of C99 Annex G. 696 697 698File: gccint.info, Node: Decimal float library routines, Next: Fixed-point fractional library routines, Prev: Soft float library routines, Up: Libgcc 699 7004.3 Routines for decimal floating point emulation 701================================================= 702 703The software decimal floating point library implements IEEE 754-2008 704decimal floating point arithmetic and is only activated on selected 705targets. 706 707 The software decimal floating point library supports either DPD 708(Densely Packed Decimal) or BID (Binary Integer Decimal) encoding as 709selected at configure time. 710 7114.3.1 Arithmetic functions 712-------------------------- 713 714 -- Runtime Function: _Decimal32 __dpd_addsd3 (_Decimal32 A, _Decimal32 715 B) 716 -- Runtime Function: _Decimal32 __bid_addsd3 (_Decimal32 A, _Decimal32 717 B) 718 -- Runtime Function: _Decimal64 __dpd_adddd3 (_Decimal64 A, _Decimal64 719 B) 720 -- Runtime Function: _Decimal64 __bid_adddd3 (_Decimal64 A, _Decimal64 721 B) 722 -- Runtime Function: _Decimal128 __dpd_addtd3 (_Decimal128 A, 723 _Decimal128 B) 724 -- Runtime Function: _Decimal128 __bid_addtd3 (_Decimal128 A, 725 _Decimal128 B) 726 These functions return the sum of A and B. 727 728 -- Runtime Function: _Decimal32 __dpd_subsd3 (_Decimal32 A, _Decimal32 729 B) 730 -- Runtime Function: _Decimal32 __bid_subsd3 (_Decimal32 A, _Decimal32 731 B) 732 -- Runtime Function: _Decimal64 __dpd_subdd3 (_Decimal64 A, _Decimal64 733 B) 734 -- Runtime Function: _Decimal64 __bid_subdd3 (_Decimal64 A, _Decimal64 735 B) 736 -- Runtime Function: _Decimal128 __dpd_subtd3 (_Decimal128 A, 737 _Decimal128 B) 738 -- Runtime Function: _Decimal128 __bid_subtd3 (_Decimal128 A, 739 _Decimal128 B) 740 These functions return the difference between B and A; that is, 741 A - B. 742 743 -- Runtime Function: _Decimal32 __dpd_mulsd3 (_Decimal32 A, _Decimal32 744 B) 745 -- Runtime Function: _Decimal32 __bid_mulsd3 (_Decimal32 A, _Decimal32 746 B) 747 -- Runtime Function: _Decimal64 __dpd_muldd3 (_Decimal64 A, _Decimal64 748 B) 749 -- Runtime Function: _Decimal64 __bid_muldd3 (_Decimal64 A, _Decimal64 750 B) 751 -- Runtime Function: _Decimal128 __dpd_multd3 (_Decimal128 A, 752 _Decimal128 B) 753 -- Runtime Function: _Decimal128 __bid_multd3 (_Decimal128 A, 754 _Decimal128 B) 755 These functions return the product of A and B. 756 757 -- Runtime Function: _Decimal32 __dpd_divsd3 (_Decimal32 A, _Decimal32 758 B) 759 -- Runtime Function: _Decimal32 __bid_divsd3 (_Decimal32 A, _Decimal32 760 B) 761 -- Runtime Function: _Decimal64 __dpd_divdd3 (_Decimal64 A, _Decimal64 762 B) 763 -- Runtime Function: _Decimal64 __bid_divdd3 (_Decimal64 A, _Decimal64 764 B) 765 -- Runtime Function: _Decimal128 __dpd_divtd3 (_Decimal128 A, 766 _Decimal128 B) 767 -- Runtime Function: _Decimal128 __bid_divtd3 (_Decimal128 A, 768 _Decimal128 B) 769 These functions return the quotient of A and B; that is, A / B. 770 771 -- Runtime Function: _Decimal32 __dpd_negsd2 (_Decimal32 A) 772 -- Runtime Function: _Decimal32 __bid_negsd2 (_Decimal32 A) 773 -- Runtime Function: _Decimal64 __dpd_negdd2 (_Decimal64 A) 774 -- Runtime Function: _Decimal64 __bid_negdd2 (_Decimal64 A) 775 -- Runtime Function: _Decimal128 __dpd_negtd2 (_Decimal128 A) 776 -- Runtime Function: _Decimal128 __bid_negtd2 (_Decimal128 A) 777 These functions return the negation of A. They simply flip the 778 sign bit, so they can produce negative zero and negative NaN. 779 7804.3.2 Conversion functions 781-------------------------- 782 783 -- Runtime Function: _Decimal64 __dpd_extendsddd2 (_Decimal32 A) 784 -- Runtime Function: _Decimal64 __bid_extendsddd2 (_Decimal32 A) 785 -- Runtime Function: _Decimal128 __dpd_extendsdtd2 (_Decimal32 A) 786 -- Runtime Function: _Decimal128 __bid_extendsdtd2 (_Decimal32 A) 787 -- Runtime Function: _Decimal128 __dpd_extendddtd2 (_Decimal64 A) 788 -- Runtime Function: _Decimal128 __bid_extendddtd2 (_Decimal64 A) 789 -- Runtime Function: _Decimal32 __dpd_truncddsd2 (_Decimal64 A) 790 -- Runtime Function: _Decimal32 __bid_truncddsd2 (_Decimal64 A) 791 -- Runtime Function: _Decimal32 __dpd_trunctdsd2 (_Decimal128 A) 792 -- Runtime Function: _Decimal32 __bid_trunctdsd2 (_Decimal128 A) 793 -- Runtime Function: _Decimal64 __dpd_trunctddd2 (_Decimal128 A) 794 -- Runtime Function: _Decimal64 __bid_trunctddd2 (_Decimal128 A) 795 These functions convert the value A from one decimal floating type 796 to another. 797 798 -- Runtime Function: _Decimal64 __dpd_extendsfdd (float A) 799 -- Runtime Function: _Decimal64 __bid_extendsfdd (float A) 800 -- Runtime Function: _Decimal128 __dpd_extendsftd (float A) 801 -- Runtime Function: _Decimal128 __bid_extendsftd (float A) 802 -- Runtime Function: _Decimal128 __dpd_extenddftd (double A) 803 -- Runtime Function: _Decimal128 __bid_extenddftd (double A) 804 -- Runtime Function: _Decimal128 __dpd_extendxftd (long double A) 805 -- Runtime Function: _Decimal128 __bid_extendxftd (long double A) 806 -- Runtime Function: _Decimal32 __dpd_truncdfsd (double A) 807 -- Runtime Function: _Decimal32 __bid_truncdfsd (double A) 808 -- Runtime Function: _Decimal32 __dpd_truncxfsd (long double A) 809 -- Runtime Function: _Decimal32 __bid_truncxfsd (long double A) 810 -- Runtime Function: _Decimal32 __dpd_trunctfsd (long double A) 811 -- Runtime Function: _Decimal32 __bid_trunctfsd (long double A) 812 -- Runtime Function: _Decimal64 __dpd_truncxfdd (long double A) 813 -- Runtime Function: _Decimal64 __bid_truncxfdd (long double A) 814 -- Runtime Function: _Decimal64 __dpd_trunctfdd (long double A) 815 -- Runtime Function: _Decimal64 __bid_trunctfdd (long double A) 816 These functions convert the value of A from a binary floating type 817 to a decimal floating type of a different size. 818 819 -- Runtime Function: float __dpd_truncddsf (_Decimal64 A) 820 -- Runtime Function: float __bid_truncddsf (_Decimal64 A) 821 -- Runtime Function: float __dpd_trunctdsf (_Decimal128 A) 822 -- Runtime Function: float __bid_trunctdsf (_Decimal128 A) 823 -- Runtime Function: double __dpd_extendsddf (_Decimal32 A) 824 -- Runtime Function: double __bid_extendsddf (_Decimal32 A) 825 -- Runtime Function: double __dpd_trunctddf (_Decimal128 A) 826 -- Runtime Function: double __bid_trunctddf (_Decimal128 A) 827 -- Runtime Function: long double __dpd_extendsdxf (_Decimal32 A) 828 -- Runtime Function: long double __bid_extendsdxf (_Decimal32 A) 829 -- Runtime Function: long double __dpd_extendddxf (_Decimal64 A) 830 -- Runtime Function: long double __bid_extendddxf (_Decimal64 A) 831 -- Runtime Function: long double __dpd_trunctdxf (_Decimal128 A) 832 -- Runtime Function: long double __bid_trunctdxf (_Decimal128 A) 833 -- Runtime Function: long double __dpd_extendsdtf (_Decimal32 A) 834 -- Runtime Function: long double __bid_extendsdtf (_Decimal32 A) 835 -- Runtime Function: long double __dpd_extendddtf (_Decimal64 A) 836 -- Runtime Function: long double __bid_extendddtf (_Decimal64 A) 837 These functions convert the value of A from a decimal floating type 838 to a binary floating type of a different size. 839 840 -- Runtime Function: _Decimal32 __dpd_extendsfsd (float A) 841 -- Runtime Function: _Decimal32 __bid_extendsfsd (float A) 842 -- Runtime Function: _Decimal64 __dpd_extenddfdd (double A) 843 -- Runtime Function: _Decimal64 __bid_extenddfdd (double A) 844 -- Runtime Function: _Decimal128 __dpd_extendtftd (long double A) 845 -- Runtime Function: _Decimal128 __bid_extendtftd (long double A) 846 -- Runtime Function: float __dpd_truncsdsf (_Decimal32 A) 847 -- Runtime Function: float __bid_truncsdsf (_Decimal32 A) 848 -- Runtime Function: double __dpd_truncdddf (_Decimal64 A) 849 -- Runtime Function: double __bid_truncdddf (_Decimal64 A) 850 -- Runtime Function: long double __dpd_trunctdtf (_Decimal128 A) 851 -- Runtime Function: long double __bid_trunctdtf (_Decimal128 A) 852 These functions convert the value of A between decimal and binary 853 floating types of the same size. 854 855 -- Runtime Function: int __dpd_fixsdsi (_Decimal32 A) 856 -- Runtime Function: int __bid_fixsdsi (_Decimal32 A) 857 -- Runtime Function: int __dpd_fixddsi (_Decimal64 A) 858 -- Runtime Function: int __bid_fixddsi (_Decimal64 A) 859 -- Runtime Function: int __dpd_fixtdsi (_Decimal128 A) 860 -- Runtime Function: int __bid_fixtdsi (_Decimal128 A) 861 These functions convert A to a signed integer. 862 863 -- Runtime Function: long __dpd_fixsddi (_Decimal32 A) 864 -- Runtime Function: long __bid_fixsddi (_Decimal32 A) 865 -- Runtime Function: long __dpd_fixdddi (_Decimal64 A) 866 -- Runtime Function: long __bid_fixdddi (_Decimal64 A) 867 -- Runtime Function: long __dpd_fixtddi (_Decimal128 A) 868 -- Runtime Function: long __bid_fixtddi (_Decimal128 A) 869 These functions convert A to a signed long. 870 871 -- Runtime Function: unsigned int __dpd_fixunssdsi (_Decimal32 A) 872 -- Runtime Function: unsigned int __bid_fixunssdsi (_Decimal32 A) 873 -- Runtime Function: unsigned int __dpd_fixunsddsi (_Decimal64 A) 874 -- Runtime Function: unsigned int __bid_fixunsddsi (_Decimal64 A) 875 -- Runtime Function: unsigned int __dpd_fixunstdsi (_Decimal128 A) 876 -- Runtime Function: unsigned int __bid_fixunstdsi (_Decimal128 A) 877 These functions convert A to an unsigned integer. Negative values 878 all become zero. 879 880 -- Runtime Function: unsigned long __dpd_fixunssddi (_Decimal32 A) 881 -- Runtime Function: unsigned long __bid_fixunssddi (_Decimal32 A) 882 -- Runtime Function: unsigned long __dpd_fixunsdddi (_Decimal64 A) 883 -- Runtime Function: unsigned long __bid_fixunsdddi (_Decimal64 A) 884 -- Runtime Function: unsigned long __dpd_fixunstddi (_Decimal128 A) 885 -- Runtime Function: unsigned long __bid_fixunstddi (_Decimal128 A) 886 These functions convert A to an unsigned long. Negative values 887 all become zero. 888 889 -- Runtime Function: _Decimal32 __dpd_floatsisd (int I) 890 -- Runtime Function: _Decimal32 __bid_floatsisd (int I) 891 -- Runtime Function: _Decimal64 __dpd_floatsidd (int I) 892 -- Runtime Function: _Decimal64 __bid_floatsidd (int I) 893 -- Runtime Function: _Decimal128 __dpd_floatsitd (int I) 894 -- Runtime Function: _Decimal128 __bid_floatsitd (int I) 895 These functions convert I, a signed integer, to decimal floating 896 point. 897 898 -- Runtime Function: _Decimal32 __dpd_floatdisd (long I) 899 -- Runtime Function: _Decimal32 __bid_floatdisd (long I) 900 -- Runtime Function: _Decimal64 __dpd_floatdidd (long I) 901 -- Runtime Function: _Decimal64 __bid_floatdidd (long I) 902 -- Runtime Function: _Decimal128 __dpd_floatditd (long I) 903 -- Runtime Function: _Decimal128 __bid_floatditd (long I) 904 These functions convert I, a signed long, to decimal floating 905 point. 906 907 -- Runtime Function: _Decimal32 __dpd_floatunssisd (unsigned int I) 908 -- Runtime Function: _Decimal32 __bid_floatunssisd (unsigned int I) 909 -- Runtime Function: _Decimal64 __dpd_floatunssidd (unsigned int I) 910 -- Runtime Function: _Decimal64 __bid_floatunssidd (unsigned int I) 911 -- Runtime Function: _Decimal128 __dpd_floatunssitd (unsigned int I) 912 -- Runtime Function: _Decimal128 __bid_floatunssitd (unsigned int I) 913 These functions convert I, an unsigned integer, to decimal 914 floating point. 915 916 -- Runtime Function: _Decimal32 __dpd_floatunsdisd (unsigned long I) 917 -- Runtime Function: _Decimal32 __bid_floatunsdisd (unsigned long I) 918 -- Runtime Function: _Decimal64 __dpd_floatunsdidd (unsigned long I) 919 -- Runtime Function: _Decimal64 __bid_floatunsdidd (unsigned long I) 920 -- Runtime Function: _Decimal128 __dpd_floatunsditd (unsigned long I) 921 -- Runtime Function: _Decimal128 __bid_floatunsditd (unsigned long I) 922 These functions convert I, an unsigned long, to decimal floating 923 point. 924 9254.3.3 Comparison functions 926-------------------------- 927 928 -- Runtime Function: int __dpd_unordsd2 (_Decimal32 A, _Decimal32 B) 929 -- Runtime Function: int __bid_unordsd2 (_Decimal32 A, _Decimal32 B) 930 -- Runtime Function: int __dpd_unorddd2 (_Decimal64 A, _Decimal64 B) 931 -- Runtime Function: int __bid_unorddd2 (_Decimal64 A, _Decimal64 B) 932 -- Runtime Function: int __dpd_unordtd2 (_Decimal128 A, _Decimal128 B) 933 -- Runtime Function: int __bid_unordtd2 (_Decimal128 A, _Decimal128 B) 934 These functions return a nonzero value if either argument is NaN, 935 otherwise 0. 936 937 There is also a complete group of higher level functions which 938correspond directly to comparison operators. They implement the ISO C 939semantics for floating-point comparisons, taking NaN into account. Pay 940careful attention to the return values defined for each set. Under the 941hood, all of these routines are implemented as 942 943 if (__bid_unordXd2 (a, b)) 944 return E; 945 return __bid_cmpXd2 (a, b); 946 947where E is a constant chosen to give the proper behavior for NaN. 948Thus, the meaning of the return value is different for each set. Do 949not rely on this implementation; only the semantics documented below 950are guaranteed. 951 952 -- Runtime Function: int __dpd_eqsd2 (_Decimal32 A, _Decimal32 B) 953 -- Runtime Function: int __bid_eqsd2 (_Decimal32 A, _Decimal32 B) 954 -- Runtime Function: int __dpd_eqdd2 (_Decimal64 A, _Decimal64 B) 955 -- Runtime Function: int __bid_eqdd2 (_Decimal64 A, _Decimal64 B) 956 -- Runtime Function: int __dpd_eqtd2 (_Decimal128 A, _Decimal128 B) 957 -- Runtime Function: int __bid_eqtd2 (_Decimal128 A, _Decimal128 B) 958 These functions return zero if neither argument is NaN, and A and 959 B are equal. 960 961 -- Runtime Function: int __dpd_nesd2 (_Decimal32 A, _Decimal32 B) 962 -- Runtime Function: int __bid_nesd2 (_Decimal32 A, _Decimal32 B) 963 -- Runtime Function: int __dpd_nedd2 (_Decimal64 A, _Decimal64 B) 964 -- Runtime Function: int __bid_nedd2 (_Decimal64 A, _Decimal64 B) 965 -- Runtime Function: int __dpd_netd2 (_Decimal128 A, _Decimal128 B) 966 -- Runtime Function: int __bid_netd2 (_Decimal128 A, _Decimal128 B) 967 These functions return a nonzero value if either argument is NaN, 968 or if A and B are unequal. 969 970 -- Runtime Function: int __dpd_gesd2 (_Decimal32 A, _Decimal32 B) 971 -- Runtime Function: int __bid_gesd2 (_Decimal32 A, _Decimal32 B) 972 -- Runtime Function: int __dpd_gedd2 (_Decimal64 A, _Decimal64 B) 973 -- Runtime Function: int __bid_gedd2 (_Decimal64 A, _Decimal64 B) 974 -- Runtime Function: int __dpd_getd2 (_Decimal128 A, _Decimal128 B) 975 -- Runtime Function: int __bid_getd2 (_Decimal128 A, _Decimal128 B) 976 These functions return a value greater than or equal to zero if 977 neither argument is NaN, and A is greater than or equal to B. 978 979 -- Runtime Function: int __dpd_ltsd2 (_Decimal32 A, _Decimal32 B) 980 -- Runtime Function: int __bid_ltsd2 (_Decimal32 A, _Decimal32 B) 981 -- Runtime Function: int __dpd_ltdd2 (_Decimal64 A, _Decimal64 B) 982 -- Runtime Function: int __bid_ltdd2 (_Decimal64 A, _Decimal64 B) 983 -- Runtime Function: int __dpd_lttd2 (_Decimal128 A, _Decimal128 B) 984 -- Runtime Function: int __bid_lttd2 (_Decimal128 A, _Decimal128 B) 985 These functions return a value less than zero if neither argument 986 is NaN, and A is strictly less than B. 987 988 -- Runtime Function: int __dpd_lesd2 (_Decimal32 A, _Decimal32 B) 989 -- Runtime Function: int __bid_lesd2 (_Decimal32 A, _Decimal32 B) 990 -- Runtime Function: int __dpd_ledd2 (_Decimal64 A, _Decimal64 B) 991 -- Runtime Function: int __bid_ledd2 (_Decimal64 A, _Decimal64 B) 992 -- Runtime Function: int __dpd_letd2 (_Decimal128 A, _Decimal128 B) 993 -- Runtime Function: int __bid_letd2 (_Decimal128 A, _Decimal128 B) 994 These functions return a value less than or equal to zero if 995 neither argument is NaN, and A is less than or equal to B. 996 997 -- Runtime Function: int __dpd_gtsd2 (_Decimal32 A, _Decimal32 B) 998 -- Runtime Function: int __bid_gtsd2 (_Decimal32 A, _Decimal32 B) 999 -- Runtime Function: int __dpd_gtdd2 (_Decimal64 A, _Decimal64 B) 1000 -- Runtime Function: int __bid_gtdd2 (_Decimal64 A, _Decimal64 B) 1001 -- Runtime Function: int __dpd_gttd2 (_Decimal128 A, _Decimal128 B) 1002 -- Runtime Function: int __bid_gttd2 (_Decimal128 A, _Decimal128 B) 1003 These functions return a value greater than zero if neither 1004 argument is NaN, and A is strictly greater than B. 1005 1006 1007File: gccint.info, Node: Fixed-point fractional library routines, Next: Exception handling routines, Prev: Decimal float library routines, Up: Libgcc 1008 10094.4 Routines for fixed-point fractional emulation 1010================================================= 1011 1012The software fixed-point library implements fixed-point fractional 1013arithmetic, and is only activated on selected targets. 1014 1015 For ease of comprehension `fract' is an alias for the `_Fract' type, 1016`accum' an alias for `_Accum', and `sat' an alias for `_Sat'. 1017 1018 For illustrative purposes, in this section the fixed-point fractional 1019type `short fract' is assumed to correspond to machine mode `QQmode'; 1020`unsigned short fract' to `UQQmode'; `fract' to `HQmode'; 1021`unsigned fract' to `UHQmode'; `long fract' to `SQmode'; 1022`unsigned long fract' to `USQmode'; `long long fract' to `DQmode'; and 1023`unsigned long long fract' to `UDQmode'. Similarly the fixed-point 1024accumulator type `short accum' corresponds to `HAmode'; 1025`unsigned short accum' to `UHAmode'; `accum' to `SAmode'; 1026`unsigned accum' to `USAmode'; `long accum' to `DAmode'; 1027`unsigned long accum' to `UDAmode'; `long long accum' to `TAmode'; and 1028`unsigned long long accum' to `UTAmode'. 1029 10304.4.1 Arithmetic functions 1031-------------------------- 1032 1033 -- Runtime Function: short fract __addqq3 (short fract A, short fract 1034 B) 1035 -- Runtime Function: fract __addhq3 (fract A, fract B) 1036 -- Runtime Function: long fract __addsq3 (long fract A, long fract B) 1037 -- Runtime Function: long long fract __adddq3 (long long fract A, long 1038 long fract B) 1039 -- Runtime Function: unsigned short fract __adduqq3 (unsigned short 1040 fract A, unsigned short fract B) 1041 -- Runtime Function: unsigned fract __adduhq3 (unsigned fract A, 1042 unsigned fract B) 1043 -- Runtime Function: unsigned long fract __addusq3 (unsigned long 1044 fract A, unsigned long fract B) 1045 -- Runtime Function: unsigned long long fract __addudq3 (unsigned long 1046 long fract A, unsigned long long fract B) 1047 -- Runtime Function: short accum __addha3 (short accum A, short accum 1048 B) 1049 -- Runtime Function: accum __addsa3 (accum A, accum B) 1050 -- Runtime Function: long accum __addda3 (long accum A, long accum B) 1051 -- Runtime Function: long long accum __addta3 (long long accum A, long 1052 long accum B) 1053 -- Runtime Function: unsigned short accum __adduha3 (unsigned short 1054 accum A, unsigned short accum B) 1055 -- Runtime Function: unsigned accum __addusa3 (unsigned accum A, 1056 unsigned accum B) 1057 -- Runtime Function: unsigned long accum __adduda3 (unsigned long 1058 accum A, unsigned long accum B) 1059 -- Runtime Function: unsigned long long accum __adduta3 (unsigned long 1060 long accum A, unsigned long long accum B) 1061 These functions return the sum of A and B. 1062 1063 -- Runtime Function: short fract __ssaddqq3 (short fract A, short 1064 fract B) 1065 -- Runtime Function: fract __ssaddhq3 (fract A, fract B) 1066 -- Runtime Function: long fract __ssaddsq3 (long fract A, long fract B) 1067 -- Runtime Function: long long fract __ssadddq3 (long long fract A, 1068 long long fract B) 1069 -- Runtime Function: short accum __ssaddha3 (short accum A, short 1070 accum B) 1071 -- Runtime Function: accum __ssaddsa3 (accum A, accum B) 1072 -- Runtime Function: long accum __ssaddda3 (long accum A, long accum B) 1073 -- Runtime Function: long long accum __ssaddta3 (long long accum A, 1074 long long accum B) 1075 These functions return the sum of A and B with signed saturation. 1076 1077 -- Runtime Function: unsigned short fract __usadduqq3 (unsigned short 1078 fract A, unsigned short fract B) 1079 -- Runtime Function: unsigned fract __usadduhq3 (unsigned fract A, 1080 unsigned fract B) 1081 -- Runtime Function: unsigned long fract __usaddusq3 (unsigned long 1082 fract A, unsigned long fract B) 1083 -- Runtime Function: unsigned long long fract __usaddudq3 (unsigned 1084 long long fract A, unsigned long long fract B) 1085 -- Runtime Function: unsigned short accum __usadduha3 (unsigned short 1086 accum A, unsigned short accum B) 1087 -- Runtime Function: unsigned accum __usaddusa3 (unsigned accum A, 1088 unsigned accum B) 1089 -- Runtime Function: unsigned long accum __usadduda3 (unsigned long 1090 accum A, unsigned long accum B) 1091 -- Runtime Function: unsigned long long accum __usadduta3 (unsigned 1092 long long accum A, unsigned long long accum B) 1093 These functions return the sum of A and B with unsigned saturation. 1094 1095 -- Runtime Function: short fract __subqq3 (short fract A, short fract 1096 B) 1097 -- Runtime Function: fract __subhq3 (fract A, fract B) 1098 -- Runtime Function: long fract __subsq3 (long fract A, long fract B) 1099 -- Runtime Function: long long fract __subdq3 (long long fract A, long 1100 long fract B) 1101 -- Runtime Function: unsigned short fract __subuqq3 (unsigned short 1102 fract A, unsigned short fract B) 1103 -- Runtime Function: unsigned fract __subuhq3 (unsigned fract A, 1104 unsigned fract B) 1105 -- Runtime Function: unsigned long fract __subusq3 (unsigned long 1106 fract A, unsigned long fract B) 1107 -- Runtime Function: unsigned long long fract __subudq3 (unsigned long 1108 long fract A, unsigned long long fract B) 1109 -- Runtime Function: short accum __subha3 (short accum A, short accum 1110 B) 1111 -- Runtime Function: accum __subsa3 (accum A, accum B) 1112 -- Runtime Function: long accum __subda3 (long accum A, long accum B) 1113 -- Runtime Function: long long accum __subta3 (long long accum A, long 1114 long accum B) 1115 -- Runtime Function: unsigned short accum __subuha3 (unsigned short 1116 accum A, unsigned short accum B) 1117 -- Runtime Function: unsigned accum __subusa3 (unsigned accum A, 1118 unsigned accum B) 1119 -- Runtime Function: unsigned long accum __subuda3 (unsigned long 1120 accum A, unsigned long accum B) 1121 -- Runtime Function: unsigned long long accum __subuta3 (unsigned long 1122 long accum A, unsigned long long accum B) 1123 These functions return the difference of A and B; that is, `A - B'. 1124 1125 -- Runtime Function: short fract __sssubqq3 (short fract A, short 1126 fract B) 1127 -- Runtime Function: fract __sssubhq3 (fract A, fract B) 1128 -- Runtime Function: long fract __sssubsq3 (long fract A, long fract B) 1129 -- Runtime Function: long long fract __sssubdq3 (long long fract A, 1130 long long fract B) 1131 -- Runtime Function: short accum __sssubha3 (short accum A, short 1132 accum B) 1133 -- Runtime Function: accum __sssubsa3 (accum A, accum B) 1134 -- Runtime Function: long accum __sssubda3 (long accum A, long accum B) 1135 -- Runtime Function: long long accum __sssubta3 (long long accum A, 1136 long long accum B) 1137 These functions return the difference of A and B with signed 1138 saturation; that is, `A - B'. 1139 1140 -- Runtime Function: unsigned short fract __ussubuqq3 (unsigned short 1141 fract A, unsigned short fract B) 1142 -- Runtime Function: unsigned fract __ussubuhq3 (unsigned fract A, 1143 unsigned fract B) 1144 -- Runtime Function: unsigned long fract __ussubusq3 (unsigned long 1145 fract A, unsigned long fract B) 1146 -- Runtime Function: unsigned long long fract __ussubudq3 (unsigned 1147 long long fract A, unsigned long long fract B) 1148 -- Runtime Function: unsigned short accum __ussubuha3 (unsigned short 1149 accum A, unsigned short accum B) 1150 -- Runtime Function: unsigned accum __ussubusa3 (unsigned accum A, 1151 unsigned accum B) 1152 -- Runtime Function: unsigned long accum __ussubuda3 (unsigned long 1153 accum A, unsigned long accum B) 1154 -- Runtime Function: unsigned long long accum __ussubuta3 (unsigned 1155 long long accum A, unsigned long long accum B) 1156 These functions return the difference of A and B with unsigned 1157 saturation; that is, `A - B'. 1158 1159 -- Runtime Function: short fract __mulqq3 (short fract A, short fract 1160 B) 1161 -- Runtime Function: fract __mulhq3 (fract A, fract B) 1162 -- Runtime Function: long fract __mulsq3 (long fract A, long fract B) 1163 -- Runtime Function: long long fract __muldq3 (long long fract A, long 1164 long fract B) 1165 -- Runtime Function: unsigned short fract __muluqq3 (unsigned short 1166 fract A, unsigned short fract B) 1167 -- Runtime Function: unsigned fract __muluhq3 (unsigned fract A, 1168 unsigned fract B) 1169 -- Runtime Function: unsigned long fract __mulusq3 (unsigned long 1170 fract A, unsigned long fract B) 1171 -- Runtime Function: unsigned long long fract __muludq3 (unsigned long 1172 long fract A, unsigned long long fract B) 1173 -- Runtime Function: short accum __mulha3 (short accum A, short accum 1174 B) 1175 -- Runtime Function: accum __mulsa3 (accum A, accum B) 1176 -- Runtime Function: long accum __mulda3 (long accum A, long accum B) 1177 -- Runtime Function: long long accum __multa3 (long long accum A, long 1178 long accum B) 1179 -- Runtime Function: unsigned short accum __muluha3 (unsigned short 1180 accum A, unsigned short accum B) 1181 -- Runtime Function: unsigned accum __mulusa3 (unsigned accum A, 1182 unsigned accum B) 1183 -- Runtime Function: unsigned long accum __muluda3 (unsigned long 1184 accum A, unsigned long accum B) 1185 -- Runtime Function: unsigned long long accum __muluta3 (unsigned long 1186 long accum A, unsigned long long accum B) 1187 These functions return the product of A and B. 1188 1189 -- Runtime Function: short fract __ssmulqq3 (short fract A, short 1190 fract B) 1191 -- Runtime Function: fract __ssmulhq3 (fract A, fract B) 1192 -- Runtime Function: long fract __ssmulsq3 (long fract A, long fract B) 1193 -- Runtime Function: long long fract __ssmuldq3 (long long fract A, 1194 long long fract B) 1195 -- Runtime Function: short accum __ssmulha3 (short accum A, short 1196 accum B) 1197 -- Runtime Function: accum __ssmulsa3 (accum A, accum B) 1198 -- Runtime Function: long accum __ssmulda3 (long accum A, long accum B) 1199 -- Runtime Function: long long accum __ssmulta3 (long long accum A, 1200 long long accum B) 1201 These functions return the product of A and B with signed 1202 saturation. 1203 1204 -- Runtime Function: unsigned short fract __usmuluqq3 (unsigned short 1205 fract A, unsigned short fract B) 1206 -- Runtime Function: unsigned fract __usmuluhq3 (unsigned fract A, 1207 unsigned fract B) 1208 -- Runtime Function: unsigned long fract __usmulusq3 (unsigned long 1209 fract A, unsigned long fract B) 1210 -- Runtime Function: unsigned long long fract __usmuludq3 (unsigned 1211 long long fract A, unsigned long long fract B) 1212 -- Runtime Function: unsigned short accum __usmuluha3 (unsigned short 1213 accum A, unsigned short accum B) 1214 -- Runtime Function: unsigned accum __usmulusa3 (unsigned accum A, 1215 unsigned accum B) 1216 -- Runtime Function: unsigned long accum __usmuluda3 (unsigned long 1217 accum A, unsigned long accum B) 1218 -- Runtime Function: unsigned long long accum __usmuluta3 (unsigned 1219 long long accum A, unsigned long long accum B) 1220 These functions return the product of A and B with unsigned 1221 saturation. 1222 1223 -- Runtime Function: short fract __divqq3 (short fract A, short fract 1224 B) 1225 -- Runtime Function: fract __divhq3 (fract A, fract B) 1226 -- Runtime Function: long fract __divsq3 (long fract A, long fract B) 1227 -- Runtime Function: long long fract __divdq3 (long long fract A, long 1228 long fract B) 1229 -- Runtime Function: short accum __divha3 (short accum A, short accum 1230 B) 1231 -- Runtime Function: accum __divsa3 (accum A, accum B) 1232 -- Runtime Function: long accum __divda3 (long accum A, long accum B) 1233 -- Runtime Function: long long accum __divta3 (long long accum A, long 1234 long accum B) 1235 These functions return the quotient of the signed division of A 1236 and B. 1237 1238 -- Runtime Function: unsigned short fract __udivuqq3 (unsigned short 1239 fract A, unsigned short fract B) 1240 -- Runtime Function: unsigned fract __udivuhq3 (unsigned fract A, 1241 unsigned fract B) 1242 -- Runtime Function: unsigned long fract __udivusq3 (unsigned long 1243 fract A, unsigned long fract B) 1244 -- Runtime Function: unsigned long long fract __udivudq3 (unsigned 1245 long long fract A, unsigned long long fract B) 1246 -- Runtime Function: unsigned short accum __udivuha3 (unsigned short 1247 accum A, unsigned short accum B) 1248 -- Runtime Function: unsigned accum __udivusa3 (unsigned accum A, 1249 unsigned accum B) 1250 -- Runtime Function: unsigned long accum __udivuda3 (unsigned long 1251 accum A, unsigned long accum B) 1252 -- Runtime Function: unsigned long long accum __udivuta3 (unsigned 1253 long long accum A, unsigned long long accum B) 1254 These functions return the quotient of the unsigned division of A 1255 and B. 1256 1257 -- Runtime Function: short fract __ssdivqq3 (short fract A, short 1258 fract B) 1259 -- Runtime Function: fract __ssdivhq3 (fract A, fract B) 1260 -- Runtime Function: long fract __ssdivsq3 (long fract A, long fract B) 1261 -- Runtime Function: long long fract __ssdivdq3 (long long fract A, 1262 long long fract B) 1263 -- Runtime Function: short accum __ssdivha3 (short accum A, short 1264 accum B) 1265 -- Runtime Function: accum __ssdivsa3 (accum A, accum B) 1266 -- Runtime Function: long accum __ssdivda3 (long accum A, long accum B) 1267 -- Runtime Function: long long accum __ssdivta3 (long long accum A, 1268 long long accum B) 1269 These functions return the quotient of the signed division of A 1270 and B with signed saturation. 1271 1272 -- Runtime Function: unsigned short fract __usdivuqq3 (unsigned short 1273 fract A, unsigned short fract B) 1274 -- Runtime Function: unsigned fract __usdivuhq3 (unsigned fract A, 1275 unsigned fract B) 1276 -- Runtime Function: unsigned long fract __usdivusq3 (unsigned long 1277 fract A, unsigned long fract B) 1278 -- Runtime Function: unsigned long long fract __usdivudq3 (unsigned 1279 long long fract A, unsigned long long fract B) 1280 -- Runtime Function: unsigned short accum __usdivuha3 (unsigned short 1281 accum A, unsigned short accum B) 1282 -- Runtime Function: unsigned accum __usdivusa3 (unsigned accum A, 1283 unsigned accum B) 1284 -- Runtime Function: unsigned long accum __usdivuda3 (unsigned long 1285 accum A, unsigned long accum B) 1286 -- Runtime Function: unsigned long long accum __usdivuta3 (unsigned 1287 long long accum A, unsigned long long accum B) 1288 These functions return the quotient of the unsigned division of A 1289 and B with unsigned saturation. 1290 1291 -- Runtime Function: short fract __negqq2 (short fract A) 1292 -- Runtime Function: fract __neghq2 (fract A) 1293 -- Runtime Function: long fract __negsq2 (long fract A) 1294 -- Runtime Function: long long fract __negdq2 (long long fract A) 1295 -- Runtime Function: unsigned short fract __neguqq2 (unsigned short 1296 fract A) 1297 -- Runtime Function: unsigned fract __neguhq2 (unsigned fract A) 1298 -- Runtime Function: unsigned long fract __negusq2 (unsigned long 1299 fract A) 1300 -- Runtime Function: unsigned long long fract __negudq2 (unsigned long 1301 long fract A) 1302 -- Runtime Function: short accum __negha2 (short accum A) 1303 -- Runtime Function: accum __negsa2 (accum A) 1304 -- Runtime Function: long accum __negda2 (long accum A) 1305 -- Runtime Function: long long accum __negta2 (long long accum A) 1306 -- Runtime Function: unsigned short accum __neguha2 (unsigned short 1307 accum A) 1308 -- Runtime Function: unsigned accum __negusa2 (unsigned accum A) 1309 -- Runtime Function: unsigned long accum __neguda2 (unsigned long 1310 accum A) 1311 -- Runtime Function: unsigned long long accum __neguta2 (unsigned long 1312 long accum A) 1313 These functions return the negation of A. 1314 1315 -- Runtime Function: short fract __ssnegqq2 (short fract A) 1316 -- Runtime Function: fract __ssneghq2 (fract A) 1317 -- Runtime Function: long fract __ssnegsq2 (long fract A) 1318 -- Runtime Function: long long fract __ssnegdq2 (long long fract A) 1319 -- Runtime Function: short accum __ssnegha2 (short accum A) 1320 -- Runtime Function: accum __ssnegsa2 (accum A) 1321 -- Runtime Function: long accum __ssnegda2 (long accum A) 1322 -- Runtime Function: long long accum __ssnegta2 (long long accum A) 1323 These functions return the negation of A with signed saturation. 1324 1325 -- Runtime Function: unsigned short fract __usneguqq2 (unsigned short 1326 fract A) 1327 -- Runtime Function: unsigned fract __usneguhq2 (unsigned fract A) 1328 -- Runtime Function: unsigned long fract __usnegusq2 (unsigned long 1329 fract A) 1330 -- Runtime Function: unsigned long long fract __usnegudq2 (unsigned 1331 long long fract A) 1332 -- Runtime Function: unsigned short accum __usneguha2 (unsigned short 1333 accum A) 1334 -- Runtime Function: unsigned accum __usnegusa2 (unsigned accum A) 1335 -- Runtime Function: unsigned long accum __usneguda2 (unsigned long 1336 accum A) 1337 -- Runtime Function: unsigned long long accum __usneguta2 (unsigned 1338 long long accum A) 1339 These functions return the negation of A with unsigned saturation. 1340 1341 -- Runtime Function: short fract __ashlqq3 (short fract A, int B) 1342 -- Runtime Function: fract __ashlhq3 (fract A, int B) 1343 -- Runtime Function: long fract __ashlsq3 (long fract A, int B) 1344 -- Runtime Function: long long fract __ashldq3 (long long fract A, int 1345 B) 1346 -- Runtime Function: unsigned short fract __ashluqq3 (unsigned short 1347 fract A, int B) 1348 -- Runtime Function: unsigned fract __ashluhq3 (unsigned fract A, int 1349 B) 1350 -- Runtime Function: unsigned long fract __ashlusq3 (unsigned long 1351 fract A, int B) 1352 -- Runtime Function: unsigned long long fract __ashludq3 (unsigned 1353 long long fract A, int B) 1354 -- Runtime Function: short accum __ashlha3 (short accum A, int B) 1355 -- Runtime Function: accum __ashlsa3 (accum A, int B) 1356 -- Runtime Function: long accum __ashlda3 (long accum A, int B) 1357 -- Runtime Function: long long accum __ashlta3 (long long accum A, int 1358 B) 1359 -- Runtime Function: unsigned short accum __ashluha3 (unsigned short 1360 accum A, int B) 1361 -- Runtime Function: unsigned accum __ashlusa3 (unsigned accum A, int 1362 B) 1363 -- Runtime Function: unsigned long accum __ashluda3 (unsigned long 1364 accum A, int B) 1365 -- Runtime Function: unsigned long long accum __ashluta3 (unsigned 1366 long long accum A, int B) 1367 These functions return the result of shifting A left by B bits. 1368 1369 -- Runtime Function: short fract __ashrqq3 (short fract A, int B) 1370 -- Runtime Function: fract __ashrhq3 (fract A, int B) 1371 -- Runtime Function: long fract __ashrsq3 (long fract A, int B) 1372 -- Runtime Function: long long fract __ashrdq3 (long long fract A, int 1373 B) 1374 -- Runtime Function: short accum __ashrha3 (short accum A, int B) 1375 -- Runtime Function: accum __ashrsa3 (accum A, int B) 1376 -- Runtime Function: long accum __ashrda3 (long accum A, int B) 1377 -- Runtime Function: long long accum __ashrta3 (long long accum A, int 1378 B) 1379 These functions return the result of arithmetically shifting A 1380 right by B bits. 1381 1382 -- Runtime Function: unsigned short fract __lshruqq3 (unsigned short 1383 fract A, int B) 1384 -- Runtime Function: unsigned fract __lshruhq3 (unsigned fract A, int 1385 B) 1386 -- Runtime Function: unsigned long fract __lshrusq3 (unsigned long 1387 fract A, int B) 1388 -- Runtime Function: unsigned long long fract __lshrudq3 (unsigned 1389 long long fract A, int B) 1390 -- Runtime Function: unsigned short accum __lshruha3 (unsigned short 1391 accum A, int B) 1392 -- Runtime Function: unsigned accum __lshrusa3 (unsigned accum A, int 1393 B) 1394 -- Runtime Function: unsigned long accum __lshruda3 (unsigned long 1395 accum A, int B) 1396 -- Runtime Function: unsigned long long accum __lshruta3 (unsigned 1397 long long accum A, int B) 1398 These functions return the result of logically shifting A right by 1399 B bits. 1400 1401 -- Runtime Function: fract __ssashlhq3 (fract A, int B) 1402 -- Runtime Function: long fract __ssashlsq3 (long fract A, int B) 1403 -- Runtime Function: long long fract __ssashldq3 (long long fract A, 1404 int B) 1405 -- Runtime Function: short accum __ssashlha3 (short accum A, int B) 1406 -- Runtime Function: accum __ssashlsa3 (accum A, int B) 1407 -- Runtime Function: long accum __ssashlda3 (long accum A, int B) 1408 -- Runtime Function: long long accum __ssashlta3 (long long accum A, 1409 int B) 1410 These functions return the result of shifting A left by B bits 1411 with signed saturation. 1412 1413 -- Runtime Function: unsigned short fract __usashluqq3 (unsigned short 1414 fract A, int B) 1415 -- Runtime Function: unsigned fract __usashluhq3 (unsigned fract A, 1416 int B) 1417 -- Runtime Function: unsigned long fract __usashlusq3 (unsigned long 1418 fract A, int B) 1419 -- Runtime Function: unsigned long long fract __usashludq3 (unsigned 1420 long long fract A, int B) 1421 -- Runtime Function: unsigned short accum __usashluha3 (unsigned short 1422 accum A, int B) 1423 -- Runtime Function: unsigned accum __usashlusa3 (unsigned accum A, 1424 int B) 1425 -- Runtime Function: unsigned long accum __usashluda3 (unsigned long 1426 accum A, int B) 1427 -- Runtime Function: unsigned long long accum __usashluta3 (unsigned 1428 long long accum A, int B) 1429 These functions return the result of shifting A left by B bits 1430 with unsigned saturation. 1431 14324.4.2 Comparison functions 1433-------------------------- 1434 1435The following functions implement fixed-point comparisons. These 1436functions implement a low-level compare, upon which the higher level 1437comparison operators (such as less than and greater than or equal to) 1438can be constructed. The returned values lie in the range zero to two, 1439to allow the high-level operators to be implemented by testing the 1440returned result using either signed or unsigned comparison. 1441 1442 -- Runtime Function: int __cmpqq2 (short fract A, short fract B) 1443 -- Runtime Function: int __cmphq2 (fract A, fract B) 1444 -- Runtime Function: int __cmpsq2 (long fract A, long fract B) 1445 -- Runtime Function: int __cmpdq2 (long long fract A, long long fract 1446 B) 1447 -- Runtime Function: int __cmpuqq2 (unsigned short fract A, unsigned 1448 short fract B) 1449 -- Runtime Function: int __cmpuhq2 (unsigned fract A, unsigned fract B) 1450 -- Runtime Function: int __cmpusq2 (unsigned long fract A, unsigned 1451 long fract B) 1452 -- Runtime Function: int __cmpudq2 (unsigned long long fract A, 1453 unsigned long long fract B) 1454 -- Runtime Function: int __cmpha2 (short accum A, short accum B) 1455 -- Runtime Function: int __cmpsa2 (accum A, accum B) 1456 -- Runtime Function: int __cmpda2 (long accum A, long accum B) 1457 -- Runtime Function: int __cmpta2 (long long accum A, long long accum 1458 B) 1459 -- Runtime Function: int __cmpuha2 (unsigned short accum A, unsigned 1460 short accum B) 1461 -- Runtime Function: int __cmpusa2 (unsigned accum A, unsigned accum B) 1462 -- Runtime Function: int __cmpuda2 (unsigned long accum A, unsigned 1463 long accum B) 1464 -- Runtime Function: int __cmputa2 (unsigned long long accum A, 1465 unsigned long long accum B) 1466 These functions perform a signed or unsigned comparison of A and B 1467 (depending on the selected machine mode). If A is less than B, 1468 they return 0; if A is greater than B, they return 2; and if A and 1469 B are equal they return 1. 1470 14714.4.3 Conversion functions 1472-------------------------- 1473 1474 -- Runtime Function: fract __fractqqhq2 (short fract A) 1475 -- Runtime Function: long fract __fractqqsq2 (short fract A) 1476 -- Runtime Function: long long fract __fractqqdq2 (short fract A) 1477 -- Runtime Function: short accum __fractqqha (short fract A) 1478 -- Runtime Function: accum __fractqqsa (short fract A) 1479 -- Runtime Function: long accum __fractqqda (short fract A) 1480 -- Runtime Function: long long accum __fractqqta (short fract A) 1481 -- Runtime Function: unsigned short fract __fractqquqq (short fract A) 1482 -- Runtime Function: unsigned fract __fractqquhq (short fract A) 1483 -- Runtime Function: unsigned long fract __fractqqusq (short fract A) 1484 -- Runtime Function: unsigned long long fract __fractqqudq (short 1485 fract A) 1486 -- Runtime Function: unsigned short accum __fractqquha (short fract A) 1487 -- Runtime Function: unsigned accum __fractqqusa (short fract A) 1488 -- Runtime Function: unsigned long accum __fractqquda (short fract A) 1489 -- Runtime Function: unsigned long long accum __fractqquta (short 1490 fract A) 1491 -- Runtime Function: signed char __fractqqqi (short fract A) 1492 -- Runtime Function: short __fractqqhi (short fract A) 1493 -- Runtime Function: int __fractqqsi (short fract A) 1494 -- Runtime Function: long __fractqqdi (short fract A) 1495 -- Runtime Function: long long __fractqqti (short fract A) 1496 -- Runtime Function: float __fractqqsf (short fract A) 1497 -- Runtime Function: double __fractqqdf (short fract A) 1498 -- Runtime Function: short fract __fracthqqq2 (fract A) 1499 -- Runtime Function: long fract __fracthqsq2 (fract A) 1500 -- Runtime Function: long long fract __fracthqdq2 (fract A) 1501 -- Runtime Function: short accum __fracthqha (fract A) 1502 -- Runtime Function: accum __fracthqsa (fract A) 1503 -- Runtime Function: long accum __fracthqda (fract A) 1504 -- Runtime Function: long long accum __fracthqta (fract A) 1505 -- Runtime Function: unsigned short fract __fracthquqq (fract A) 1506 -- Runtime Function: unsigned fract __fracthquhq (fract A) 1507 -- Runtime Function: unsigned long fract __fracthqusq (fract A) 1508 -- Runtime Function: unsigned long long fract __fracthqudq (fract A) 1509 -- Runtime Function: unsigned short accum __fracthquha (fract A) 1510 -- Runtime Function: unsigned accum __fracthqusa (fract A) 1511 -- Runtime Function: unsigned long accum __fracthquda (fract A) 1512 -- Runtime Function: unsigned long long accum __fracthquta (fract A) 1513 -- Runtime Function: signed char __fracthqqi (fract A) 1514 -- Runtime Function: short __fracthqhi (fract A) 1515 -- Runtime Function: int __fracthqsi (fract A) 1516 -- Runtime Function: long __fracthqdi (fract A) 1517 -- Runtime Function: long long __fracthqti (fract A) 1518 -- Runtime Function: float __fracthqsf (fract A) 1519 -- Runtime Function: double __fracthqdf (fract A) 1520 -- Runtime Function: short fract __fractsqqq2 (long fract A) 1521 -- Runtime Function: fract __fractsqhq2 (long fract A) 1522 -- Runtime Function: long long fract __fractsqdq2 (long fract A) 1523 -- Runtime Function: short accum __fractsqha (long fract A) 1524 -- Runtime Function: accum __fractsqsa (long fract A) 1525 -- Runtime Function: long accum __fractsqda (long fract A) 1526 -- Runtime Function: long long accum __fractsqta (long fract A) 1527 -- Runtime Function: unsigned short fract __fractsquqq (long fract A) 1528 -- Runtime Function: unsigned fract __fractsquhq (long fract A) 1529 -- Runtime Function: unsigned long fract __fractsqusq (long fract A) 1530 -- Runtime Function: unsigned long long fract __fractsqudq (long fract 1531 A) 1532 -- Runtime Function: unsigned short accum __fractsquha (long fract A) 1533 -- Runtime Function: unsigned accum __fractsqusa (long fract A) 1534 -- Runtime Function: unsigned long accum __fractsquda (long fract A) 1535 -- Runtime Function: unsigned long long accum __fractsquta (long fract 1536 A) 1537 -- Runtime Function: signed char __fractsqqi (long fract A) 1538 -- Runtime Function: short __fractsqhi (long fract A) 1539 -- Runtime Function: int __fractsqsi (long fract A) 1540 -- Runtime Function: long __fractsqdi (long fract A) 1541 -- Runtime Function: long long __fractsqti (long fract A) 1542 -- Runtime Function: float __fractsqsf (long fract A) 1543 -- Runtime Function: double __fractsqdf (long fract A) 1544 -- Runtime Function: short fract __fractdqqq2 (long long fract A) 1545 -- Runtime Function: fract __fractdqhq2 (long long fract A) 1546 -- Runtime Function: long fract __fractdqsq2 (long long fract A) 1547 -- Runtime Function: short accum __fractdqha (long long fract A) 1548 -- Runtime Function: accum __fractdqsa (long long fract A) 1549 -- Runtime Function: long accum __fractdqda (long long fract A) 1550 -- Runtime Function: long long accum __fractdqta (long long fract A) 1551 -- Runtime Function: unsigned short fract __fractdquqq (long long 1552 fract A) 1553 -- Runtime Function: unsigned fract __fractdquhq (long long fract A) 1554 -- Runtime Function: unsigned long fract __fractdqusq (long long fract 1555 A) 1556 -- Runtime Function: unsigned long long fract __fractdqudq (long long 1557 fract A) 1558 -- Runtime Function: unsigned short accum __fractdquha (long long 1559 fract A) 1560 -- Runtime Function: unsigned accum __fractdqusa (long long fract A) 1561 -- Runtime Function: unsigned long accum __fractdquda (long long fract 1562 A) 1563 -- Runtime Function: unsigned long long accum __fractdquta (long long 1564 fract A) 1565 -- Runtime Function: signed char __fractdqqi (long long fract A) 1566 -- Runtime Function: short __fractdqhi (long long fract A) 1567 -- Runtime Function: int __fractdqsi (long long fract A) 1568 -- Runtime Function: long __fractdqdi (long long fract A) 1569 -- Runtime Function: long long __fractdqti (long long fract A) 1570 -- Runtime Function: float __fractdqsf (long long fract A) 1571 -- Runtime Function: double __fractdqdf (long long fract A) 1572 -- Runtime Function: short fract __fracthaqq (short accum A) 1573 -- Runtime Function: fract __fracthahq (short accum A) 1574 -- Runtime Function: long fract __fracthasq (short accum A) 1575 -- Runtime Function: long long fract __fracthadq (short accum A) 1576 -- Runtime Function: accum __fracthasa2 (short accum A) 1577 -- Runtime Function: long accum __fracthada2 (short accum A) 1578 -- Runtime Function: long long accum __fracthata2 (short accum A) 1579 -- Runtime Function: unsigned short fract __fracthauqq (short accum A) 1580 -- Runtime Function: unsigned fract __fracthauhq (short accum A) 1581 -- Runtime Function: unsigned long fract __fracthausq (short accum A) 1582 -- Runtime Function: unsigned long long fract __fracthaudq (short 1583 accum A) 1584 -- Runtime Function: unsigned short accum __fracthauha (short accum A) 1585 -- Runtime Function: unsigned accum __fracthausa (short accum A) 1586 -- Runtime Function: unsigned long accum __fracthauda (short accum A) 1587 -- Runtime Function: unsigned long long accum __fracthauta (short 1588 accum A) 1589 -- Runtime Function: signed char __fracthaqi (short accum A) 1590 -- Runtime Function: short __fracthahi (short accum A) 1591 -- Runtime Function: int __fracthasi (short accum A) 1592 -- Runtime Function: long __fracthadi (short accum A) 1593 -- Runtime Function: long long __fracthati (short accum A) 1594 -- Runtime Function: float __fracthasf (short accum A) 1595 -- Runtime Function: double __fracthadf (short accum A) 1596 -- Runtime Function: short fract __fractsaqq (accum A) 1597 -- Runtime Function: fract __fractsahq (accum A) 1598 -- Runtime Function: long fract __fractsasq (accum A) 1599 -- Runtime Function: long long fract __fractsadq (accum A) 1600 -- Runtime Function: short accum __fractsaha2 (accum A) 1601 -- Runtime Function: long accum __fractsada2 (accum A) 1602 -- Runtime Function: long long accum __fractsata2 (accum A) 1603 -- Runtime Function: unsigned short fract __fractsauqq (accum A) 1604 -- Runtime Function: unsigned fract __fractsauhq (accum A) 1605 -- Runtime Function: unsigned long fract __fractsausq (accum A) 1606 -- Runtime Function: unsigned long long fract __fractsaudq (accum A) 1607 -- Runtime Function: unsigned short accum __fractsauha (accum A) 1608 -- Runtime Function: unsigned accum __fractsausa (accum A) 1609 -- Runtime Function: unsigned long accum __fractsauda (accum A) 1610 -- Runtime Function: unsigned long long accum __fractsauta (accum A) 1611 -- Runtime Function: signed char __fractsaqi (accum A) 1612 -- Runtime Function: short __fractsahi (accum A) 1613 -- Runtime Function: int __fractsasi (accum A) 1614 -- Runtime Function: long __fractsadi (accum A) 1615 -- Runtime Function: long long __fractsati (accum A) 1616 -- Runtime Function: float __fractsasf (accum A) 1617 -- Runtime Function: double __fractsadf (accum A) 1618 -- Runtime Function: short fract __fractdaqq (long accum A) 1619 -- Runtime Function: fract __fractdahq (long accum A) 1620 -- Runtime Function: long fract __fractdasq (long accum A) 1621 -- Runtime Function: long long fract __fractdadq (long accum A) 1622 -- Runtime Function: short accum __fractdaha2 (long accum A) 1623 -- Runtime Function: accum __fractdasa2 (long accum A) 1624 -- Runtime Function: long long accum __fractdata2 (long accum A) 1625 -- Runtime Function: unsigned short fract __fractdauqq (long accum A) 1626 -- Runtime Function: unsigned fract __fractdauhq (long accum A) 1627 -- Runtime Function: unsigned long fract __fractdausq (long accum A) 1628 -- Runtime Function: unsigned long long fract __fractdaudq (long accum 1629 A) 1630 -- Runtime Function: unsigned short accum __fractdauha (long accum A) 1631 -- Runtime Function: unsigned accum __fractdausa (long accum A) 1632 -- Runtime Function: unsigned long accum __fractdauda (long accum A) 1633 -- Runtime Function: unsigned long long accum __fractdauta (long accum 1634 A) 1635 -- Runtime Function: signed char __fractdaqi (long accum A) 1636 -- Runtime Function: short __fractdahi (long accum A) 1637 -- Runtime Function: int __fractdasi (long accum A) 1638 -- Runtime Function: long __fractdadi (long accum A) 1639 -- Runtime Function: long long __fractdati (long accum A) 1640 -- Runtime Function: float __fractdasf (long accum A) 1641 -- Runtime Function: double __fractdadf (long accum A) 1642 -- Runtime Function: short fract __fracttaqq (long long accum A) 1643 -- Runtime Function: fract __fracttahq (long long accum A) 1644 -- Runtime Function: long fract __fracttasq (long long accum A) 1645 -- Runtime Function: long long fract __fracttadq (long long accum A) 1646 -- Runtime Function: short accum __fracttaha2 (long long accum A) 1647 -- Runtime Function: accum __fracttasa2 (long long accum A) 1648 -- Runtime Function: long accum __fracttada2 (long long accum A) 1649 -- Runtime Function: unsigned short fract __fracttauqq (long long 1650 accum A) 1651 -- Runtime Function: unsigned fract __fracttauhq (long long accum A) 1652 -- Runtime Function: unsigned long fract __fracttausq (long long accum 1653 A) 1654 -- Runtime Function: unsigned long long fract __fracttaudq (long long 1655 accum A) 1656 -- Runtime Function: unsigned short accum __fracttauha (long long 1657 accum A) 1658 -- Runtime Function: unsigned accum __fracttausa (long long accum A) 1659 -- Runtime Function: unsigned long accum __fracttauda (long long accum 1660 A) 1661 -- Runtime Function: unsigned long long accum __fracttauta (long long 1662 accum A) 1663 -- Runtime Function: signed char __fracttaqi (long long accum A) 1664 -- Runtime Function: short __fracttahi (long long accum A) 1665 -- Runtime Function: int __fracttasi (long long accum A) 1666 -- Runtime Function: long __fracttadi (long long accum A) 1667 -- Runtime Function: long long __fracttati (long long accum A) 1668 -- Runtime Function: float __fracttasf (long long accum A) 1669 -- Runtime Function: double __fracttadf (long long accum A) 1670 -- Runtime Function: short fract __fractuqqqq (unsigned short fract A) 1671 -- Runtime Function: fract __fractuqqhq (unsigned short fract A) 1672 -- Runtime Function: long fract __fractuqqsq (unsigned short fract A) 1673 -- Runtime Function: long long fract __fractuqqdq (unsigned short 1674 fract A) 1675 -- Runtime Function: short accum __fractuqqha (unsigned short fract A) 1676 -- Runtime Function: accum __fractuqqsa (unsigned short fract A) 1677 -- Runtime Function: long accum __fractuqqda (unsigned short fract A) 1678 -- Runtime Function: long long accum __fractuqqta (unsigned short 1679 fract A) 1680 -- Runtime Function: unsigned fract __fractuqquhq2 (unsigned short 1681 fract A) 1682 -- Runtime Function: unsigned long fract __fractuqqusq2 (unsigned 1683 short fract A) 1684 -- Runtime Function: unsigned long long fract __fractuqqudq2 (unsigned 1685 short fract A) 1686 -- Runtime Function: unsigned short accum __fractuqquha (unsigned 1687 short fract A) 1688 -- Runtime Function: unsigned accum __fractuqqusa (unsigned short 1689 fract A) 1690 -- Runtime Function: unsigned long accum __fractuqquda (unsigned short 1691 fract A) 1692 -- Runtime Function: unsigned long long accum __fractuqquta (unsigned 1693 short fract A) 1694 -- Runtime Function: signed char __fractuqqqi (unsigned short fract A) 1695 -- Runtime Function: short __fractuqqhi (unsigned short fract A) 1696 -- Runtime Function: int __fractuqqsi (unsigned short fract A) 1697 -- Runtime Function: long __fractuqqdi (unsigned short fract A) 1698 -- Runtime Function: long long __fractuqqti (unsigned short fract A) 1699 -- Runtime Function: float __fractuqqsf (unsigned short fract A) 1700 -- Runtime Function: double __fractuqqdf (unsigned short fract A) 1701 -- Runtime Function: short fract __fractuhqqq (unsigned fract A) 1702 -- Runtime Function: fract __fractuhqhq (unsigned fract A) 1703 -- Runtime Function: long fract __fractuhqsq (unsigned fract A) 1704 -- Runtime Function: long long fract __fractuhqdq (unsigned fract A) 1705 -- Runtime Function: short accum __fractuhqha (unsigned fract A) 1706 -- Runtime Function: accum __fractuhqsa (unsigned fract A) 1707 -- Runtime Function: long accum __fractuhqda (unsigned fract A) 1708 -- Runtime Function: long long accum __fractuhqta (unsigned fract A) 1709 -- Runtime Function: unsigned short fract __fractuhquqq2 (unsigned 1710 fract A) 1711 -- Runtime Function: unsigned long fract __fractuhqusq2 (unsigned 1712 fract A) 1713 -- Runtime Function: unsigned long long fract __fractuhqudq2 (unsigned 1714 fract A) 1715 -- Runtime Function: unsigned short accum __fractuhquha (unsigned 1716 fract A) 1717 -- Runtime Function: unsigned accum __fractuhqusa (unsigned fract A) 1718 -- Runtime Function: unsigned long accum __fractuhquda (unsigned fract 1719 A) 1720 -- Runtime Function: unsigned long long accum __fractuhquta (unsigned 1721 fract A) 1722 -- Runtime Function: signed char __fractuhqqi (unsigned fract A) 1723 -- Runtime Function: short __fractuhqhi (unsigned fract A) 1724 -- Runtime Function: int __fractuhqsi (unsigned fract A) 1725 -- Runtime Function: long __fractuhqdi (unsigned fract A) 1726 -- Runtime Function: long long __fractuhqti (unsigned fract A) 1727 -- Runtime Function: float __fractuhqsf (unsigned fract A) 1728 -- Runtime Function: double __fractuhqdf (unsigned fract A) 1729 -- Runtime Function: short fract __fractusqqq (unsigned long fract A) 1730 -- Runtime Function: fract __fractusqhq (unsigned long fract A) 1731 -- Runtime Function: long fract __fractusqsq (unsigned long fract A) 1732 -- Runtime Function: long long fract __fractusqdq (unsigned long fract 1733 A) 1734 -- Runtime Function: short accum __fractusqha (unsigned long fract A) 1735 -- Runtime Function: accum __fractusqsa (unsigned long fract A) 1736 -- Runtime Function: long accum __fractusqda (unsigned long fract A) 1737 -- Runtime Function: long long accum __fractusqta (unsigned long fract 1738 A) 1739 -- Runtime Function: unsigned short fract __fractusquqq2 (unsigned 1740 long fract A) 1741 -- Runtime Function: unsigned fract __fractusquhq2 (unsigned long 1742 fract A) 1743 -- Runtime Function: unsigned long long fract __fractusqudq2 (unsigned 1744 long fract A) 1745 -- Runtime Function: unsigned short accum __fractusquha (unsigned long 1746 fract A) 1747 -- Runtime Function: unsigned accum __fractusqusa (unsigned long fract 1748 A) 1749 -- Runtime Function: unsigned long accum __fractusquda (unsigned long 1750 fract A) 1751 -- Runtime Function: unsigned long long accum __fractusquta (unsigned 1752 long fract A) 1753 -- Runtime Function: signed char __fractusqqi (unsigned long fract A) 1754 -- Runtime Function: short __fractusqhi (unsigned long fract A) 1755 -- Runtime Function: int __fractusqsi (unsigned long fract A) 1756 -- Runtime Function: long __fractusqdi (unsigned long fract A) 1757 -- Runtime Function: long long __fractusqti (unsigned long fract A) 1758 -- Runtime Function: float __fractusqsf (unsigned long fract A) 1759 -- Runtime Function: double __fractusqdf (unsigned long fract A) 1760 -- Runtime Function: short fract __fractudqqq (unsigned long long 1761 fract A) 1762 -- Runtime Function: fract __fractudqhq (unsigned long long fract A) 1763 -- Runtime Function: long fract __fractudqsq (unsigned long long fract 1764 A) 1765 -- Runtime Function: long long fract __fractudqdq (unsigned long long 1766 fract A) 1767 -- Runtime Function: short accum __fractudqha (unsigned long long 1768 fract A) 1769 -- Runtime Function: accum __fractudqsa (unsigned long long fract A) 1770 -- Runtime Function: long accum __fractudqda (unsigned long long fract 1771 A) 1772 -- Runtime Function: long long accum __fractudqta (unsigned long long 1773 fract A) 1774 -- Runtime Function: unsigned short fract __fractudquqq2 (unsigned 1775 long long fract A) 1776 -- Runtime Function: unsigned fract __fractudquhq2 (unsigned long long 1777 fract A) 1778 -- Runtime Function: unsigned long fract __fractudqusq2 (unsigned long 1779 long fract A) 1780 -- Runtime Function: unsigned short accum __fractudquha (unsigned long 1781 long fract A) 1782 -- Runtime Function: unsigned accum __fractudqusa (unsigned long long 1783 fract A) 1784 -- Runtime Function: unsigned long accum __fractudquda (unsigned long 1785 long fract A) 1786 -- Runtime Function: unsigned long long accum __fractudquta (unsigned 1787 long long fract A) 1788 -- Runtime Function: signed char __fractudqqi (unsigned long long 1789 fract A) 1790 -- Runtime Function: short __fractudqhi (unsigned long long fract A) 1791 -- Runtime Function: int __fractudqsi (unsigned long long fract A) 1792 -- Runtime Function: long __fractudqdi (unsigned long long fract A) 1793 -- Runtime Function: long long __fractudqti (unsigned long long fract 1794 A) 1795 -- Runtime Function: float __fractudqsf (unsigned long long fract A) 1796 -- Runtime Function: double __fractudqdf (unsigned long long fract A) 1797 -- Runtime Function: short fract __fractuhaqq (unsigned short accum A) 1798 -- Runtime Function: fract __fractuhahq (unsigned short accum A) 1799 -- Runtime Function: long fract __fractuhasq (unsigned short accum A) 1800 -- Runtime Function: long long fract __fractuhadq (unsigned short 1801 accum A) 1802 -- Runtime Function: short accum __fractuhaha (unsigned short accum A) 1803 -- Runtime Function: accum __fractuhasa (unsigned short accum A) 1804 -- Runtime Function: long accum __fractuhada (unsigned short accum A) 1805 -- Runtime Function: long long accum __fractuhata (unsigned short 1806 accum A) 1807 -- Runtime Function: unsigned short fract __fractuhauqq (unsigned 1808 short accum A) 1809 -- Runtime Function: unsigned fract __fractuhauhq (unsigned short 1810 accum A) 1811 -- Runtime Function: unsigned long fract __fractuhausq (unsigned short 1812 accum A) 1813 -- Runtime Function: unsigned long long fract __fractuhaudq (unsigned 1814 short accum A) 1815 -- Runtime Function: unsigned accum __fractuhausa2 (unsigned short 1816 accum A) 1817 -- Runtime Function: unsigned long accum __fractuhauda2 (unsigned 1818 short accum A) 1819 -- Runtime Function: unsigned long long accum __fractuhauta2 (unsigned 1820 short accum A) 1821 -- Runtime Function: signed char __fractuhaqi (unsigned short accum A) 1822 -- Runtime Function: short __fractuhahi (unsigned short accum A) 1823 -- Runtime Function: int __fractuhasi (unsigned short accum A) 1824 -- Runtime Function: long __fractuhadi (unsigned short accum A) 1825 -- Runtime Function: long long __fractuhati (unsigned short accum A) 1826 -- Runtime Function: float __fractuhasf (unsigned short accum A) 1827 -- Runtime Function: double __fractuhadf (unsigned short accum A) 1828 -- Runtime Function: short fract __fractusaqq (unsigned accum A) 1829 -- Runtime Function: fract __fractusahq (unsigned accum A) 1830 -- Runtime Function: long fract __fractusasq (unsigned accum A) 1831 -- Runtime Function: long long fract __fractusadq (unsigned accum A) 1832 -- Runtime Function: short accum __fractusaha (unsigned accum A) 1833 -- Runtime Function: accum __fractusasa (unsigned accum A) 1834 -- Runtime Function: long accum __fractusada (unsigned accum A) 1835 -- Runtime Function: long long accum __fractusata (unsigned accum A) 1836 -- Runtime Function: unsigned short fract __fractusauqq (unsigned 1837 accum A) 1838 -- Runtime Function: unsigned fract __fractusauhq (unsigned accum A) 1839 -- Runtime Function: unsigned long fract __fractusausq (unsigned accum 1840 A) 1841 -- Runtime Function: unsigned long long fract __fractusaudq (unsigned 1842 accum A) 1843 -- Runtime Function: unsigned short accum __fractusauha2 (unsigned 1844 accum A) 1845 -- Runtime Function: unsigned long accum __fractusauda2 (unsigned 1846 accum A) 1847 -- Runtime Function: unsigned long long accum __fractusauta2 (unsigned 1848 accum A) 1849 -- Runtime Function: signed char __fractusaqi (unsigned accum A) 1850 -- Runtime Function: short __fractusahi (unsigned accum A) 1851 -- Runtime Function: int __fractusasi (unsigned accum A) 1852 -- Runtime Function: long __fractusadi (unsigned accum A) 1853 -- Runtime Function: long long __fractusati (unsigned accum A) 1854 -- Runtime Function: float __fractusasf (unsigned accum A) 1855 -- Runtime Function: double __fractusadf (unsigned accum A) 1856 -- Runtime Function: short fract __fractudaqq (unsigned long accum A) 1857 -- Runtime Function: fract __fractudahq (unsigned long accum A) 1858 -- Runtime Function: long fract __fractudasq (unsigned long accum A) 1859 -- Runtime Function: long long fract __fractudadq (unsigned long accum 1860 A) 1861 -- Runtime Function: short accum __fractudaha (unsigned long accum A) 1862 -- Runtime Function: accum __fractudasa (unsigned long accum A) 1863 -- Runtime Function: long accum __fractudada (unsigned long accum A) 1864 -- Runtime Function: long long accum __fractudata (unsigned long accum 1865 A) 1866 -- Runtime Function: unsigned short fract __fractudauqq (unsigned long 1867 accum A) 1868 -- Runtime Function: unsigned fract __fractudauhq (unsigned long accum 1869 A) 1870 -- Runtime Function: unsigned long fract __fractudausq (unsigned long 1871 accum A) 1872 -- Runtime Function: unsigned long long fract __fractudaudq (unsigned 1873 long accum A) 1874 -- Runtime Function: unsigned short accum __fractudauha2 (unsigned 1875 long accum A) 1876 -- Runtime Function: unsigned accum __fractudausa2 (unsigned long 1877 accum A) 1878 -- Runtime Function: unsigned long long accum __fractudauta2 (unsigned 1879 long accum A) 1880 -- Runtime Function: signed char __fractudaqi (unsigned long accum A) 1881 -- Runtime Function: short __fractudahi (unsigned long accum A) 1882 -- Runtime Function: int __fractudasi (unsigned long accum A) 1883 -- Runtime Function: long __fractudadi (unsigned long accum A) 1884 -- Runtime Function: long long __fractudati (unsigned long accum A) 1885 -- Runtime Function: float __fractudasf (unsigned long accum A) 1886 -- Runtime Function: double __fractudadf (unsigned long accum A) 1887 -- Runtime Function: short fract __fractutaqq (unsigned long long 1888 accum A) 1889 -- Runtime Function: fract __fractutahq (unsigned long long accum A) 1890 -- Runtime Function: long fract __fractutasq (unsigned long long accum 1891 A) 1892 -- Runtime Function: long long fract __fractutadq (unsigned long long 1893 accum A) 1894 -- Runtime Function: short accum __fractutaha (unsigned long long 1895 accum A) 1896 -- Runtime Function: accum __fractutasa (unsigned long long accum A) 1897 -- Runtime Function: long accum __fractutada (unsigned long long accum 1898 A) 1899 -- Runtime Function: long long accum __fractutata (unsigned long long 1900 accum A) 1901 -- Runtime Function: unsigned short fract __fractutauqq (unsigned long 1902 long accum A) 1903 -- Runtime Function: unsigned fract __fractutauhq (unsigned long long 1904 accum A) 1905 -- Runtime Function: unsigned long fract __fractutausq (unsigned long 1906 long accum A) 1907 -- Runtime Function: unsigned long long fract __fractutaudq (unsigned 1908 long long accum A) 1909 -- Runtime Function: unsigned short accum __fractutauha2 (unsigned 1910 long long accum A) 1911 -- Runtime Function: unsigned accum __fractutausa2 (unsigned long long 1912 accum A) 1913 -- Runtime Function: unsigned long accum __fractutauda2 (unsigned long 1914 long accum A) 1915 -- Runtime Function: signed char __fractutaqi (unsigned long long 1916 accum A) 1917 -- Runtime Function: short __fractutahi (unsigned long long accum A) 1918 -- Runtime Function: int __fractutasi (unsigned long long accum A) 1919 -- Runtime Function: long __fractutadi (unsigned long long accum A) 1920 -- Runtime Function: long long __fractutati (unsigned long long accum 1921 A) 1922 -- Runtime Function: float __fractutasf (unsigned long long accum A) 1923 -- Runtime Function: double __fractutadf (unsigned long long accum A) 1924 -- Runtime Function: short fract __fractqiqq (signed char A) 1925 -- Runtime Function: fract __fractqihq (signed char A) 1926 -- Runtime Function: long fract __fractqisq (signed char A) 1927 -- Runtime Function: long long fract __fractqidq (signed char A) 1928 -- Runtime Function: short accum __fractqiha (signed char A) 1929 -- Runtime Function: accum __fractqisa (signed char A) 1930 -- Runtime Function: long accum __fractqida (signed char A) 1931 -- Runtime Function: long long accum __fractqita (signed char A) 1932 -- Runtime Function: unsigned short fract __fractqiuqq (signed char A) 1933 -- Runtime Function: unsigned fract __fractqiuhq (signed char A) 1934 -- Runtime Function: unsigned long fract __fractqiusq (signed char A) 1935 -- Runtime Function: unsigned long long fract __fractqiudq (signed 1936 char A) 1937 -- Runtime Function: unsigned short accum __fractqiuha (signed char A) 1938 -- Runtime Function: unsigned accum __fractqiusa (signed char A) 1939 -- Runtime Function: unsigned long accum __fractqiuda (signed char A) 1940 -- Runtime Function: unsigned long long accum __fractqiuta (signed 1941 char A) 1942 -- Runtime Function: short fract __fracthiqq (short A) 1943 -- Runtime Function: fract __fracthihq (short A) 1944 -- Runtime Function: long fract __fracthisq (short A) 1945 -- Runtime Function: long long fract __fracthidq (short A) 1946 -- Runtime Function: short accum __fracthiha (short A) 1947 -- Runtime Function: accum __fracthisa (short A) 1948 -- Runtime Function: long accum __fracthida (short A) 1949 -- Runtime Function: long long accum __fracthita (short A) 1950 -- Runtime Function: unsigned short fract __fracthiuqq (short A) 1951 -- Runtime Function: unsigned fract __fracthiuhq (short A) 1952 -- Runtime Function: unsigned long fract __fracthiusq (short A) 1953 -- Runtime Function: unsigned long long fract __fracthiudq (short A) 1954 -- Runtime Function: unsigned short accum __fracthiuha (short A) 1955 -- Runtime Function: unsigned accum __fracthiusa (short A) 1956 -- Runtime Function: unsigned long accum __fracthiuda (short A) 1957 -- Runtime Function: unsigned long long accum __fracthiuta (short A) 1958 -- Runtime Function: short fract __fractsiqq (int A) 1959 -- Runtime Function: fract __fractsihq (int A) 1960 -- Runtime Function: long fract __fractsisq (int A) 1961 -- Runtime Function: long long fract __fractsidq (int A) 1962 -- Runtime Function: short accum __fractsiha (int A) 1963 -- Runtime Function: accum __fractsisa (int A) 1964 -- Runtime Function: long accum __fractsida (int A) 1965 -- Runtime Function: long long accum __fractsita (int A) 1966 -- Runtime Function: unsigned short fract __fractsiuqq (int A) 1967 -- Runtime Function: unsigned fract __fractsiuhq (int A) 1968 -- Runtime Function: unsigned long fract __fractsiusq (int A) 1969 -- Runtime Function: unsigned long long fract __fractsiudq (int A) 1970 -- Runtime Function: unsigned short accum __fractsiuha (int A) 1971 -- Runtime Function: unsigned accum __fractsiusa (int A) 1972 -- Runtime Function: unsigned long accum __fractsiuda (int A) 1973 -- Runtime Function: unsigned long long accum __fractsiuta (int A) 1974 -- Runtime Function: short fract __fractdiqq (long A) 1975 -- Runtime Function: fract __fractdihq (long A) 1976 -- Runtime Function: long fract __fractdisq (long A) 1977 -- Runtime Function: long long fract __fractdidq (long A) 1978 -- Runtime Function: short accum __fractdiha (long A) 1979 -- Runtime Function: accum __fractdisa (long A) 1980 -- Runtime Function: long accum __fractdida (long A) 1981 -- Runtime Function: long long accum __fractdita (long A) 1982 -- Runtime Function: unsigned short fract __fractdiuqq (long A) 1983 -- Runtime Function: unsigned fract __fractdiuhq (long A) 1984 -- Runtime Function: unsigned long fract __fractdiusq (long A) 1985 -- Runtime Function: unsigned long long fract __fractdiudq (long A) 1986 -- Runtime Function: unsigned short accum __fractdiuha (long A) 1987 -- Runtime Function: unsigned accum __fractdiusa (long A) 1988 -- Runtime Function: unsigned long accum __fractdiuda (long A) 1989 -- Runtime Function: unsigned long long accum __fractdiuta (long A) 1990 -- Runtime Function: short fract __fracttiqq (long long A) 1991 -- Runtime Function: fract __fracttihq (long long A) 1992 -- Runtime Function: long fract __fracttisq (long long A) 1993 -- Runtime Function: long long fract __fracttidq (long long A) 1994 -- Runtime Function: short accum __fracttiha (long long A) 1995 -- Runtime Function: accum __fracttisa (long long A) 1996 -- Runtime Function: long accum __fracttida (long long A) 1997 -- Runtime Function: long long accum __fracttita (long long A) 1998 -- Runtime Function: unsigned short fract __fracttiuqq (long long A) 1999 -- Runtime Function: unsigned fract __fracttiuhq (long long A) 2000 -- Runtime Function: unsigned long fract __fracttiusq (long long A) 2001 -- Runtime Function: unsigned long long fract __fracttiudq (long long 2002 A) 2003 -- Runtime Function: unsigned short accum __fracttiuha (long long A) 2004 -- Runtime Function: unsigned accum __fracttiusa (long long A) 2005 -- Runtime Function: unsigned long accum __fracttiuda (long long A) 2006 -- Runtime Function: unsigned long long accum __fracttiuta (long long 2007 A) 2008 -- Runtime Function: short fract __fractsfqq (float A) 2009 -- Runtime Function: fract __fractsfhq (float A) 2010 -- Runtime Function: long fract __fractsfsq (float A) 2011 -- Runtime Function: long long fract __fractsfdq (float A) 2012 -- Runtime Function: short accum __fractsfha (float A) 2013 -- Runtime Function: accum __fractsfsa (float A) 2014 -- Runtime Function: long accum __fractsfda (float A) 2015 -- Runtime Function: long long accum __fractsfta (float A) 2016 -- Runtime Function: unsigned short fract __fractsfuqq (float A) 2017 -- Runtime Function: unsigned fract __fractsfuhq (float A) 2018 -- Runtime Function: unsigned long fract __fractsfusq (float A) 2019 -- Runtime Function: unsigned long long fract __fractsfudq (float A) 2020 -- Runtime Function: unsigned short accum __fractsfuha (float A) 2021 -- Runtime Function: unsigned accum __fractsfusa (float A) 2022 -- Runtime Function: unsigned long accum __fractsfuda (float A) 2023 -- Runtime Function: unsigned long long accum __fractsfuta (float A) 2024 -- Runtime Function: short fract __fractdfqq (double A) 2025 -- Runtime Function: fract __fractdfhq (double A) 2026 -- Runtime Function: long fract __fractdfsq (double A) 2027 -- Runtime Function: long long fract __fractdfdq (double A) 2028 -- Runtime Function: short accum __fractdfha (double A) 2029 -- Runtime Function: accum __fractdfsa (double A) 2030 -- Runtime Function: long accum __fractdfda (double A) 2031 -- Runtime Function: long long accum __fractdfta (double A) 2032 -- Runtime Function: unsigned short fract __fractdfuqq (double A) 2033 -- Runtime Function: unsigned fract __fractdfuhq (double A) 2034 -- Runtime Function: unsigned long fract __fractdfusq (double A) 2035 -- Runtime Function: unsigned long long fract __fractdfudq (double A) 2036 -- Runtime Function: unsigned short accum __fractdfuha (double A) 2037 -- Runtime Function: unsigned accum __fractdfusa (double A) 2038 -- Runtime Function: unsigned long accum __fractdfuda (double A) 2039 -- Runtime Function: unsigned long long accum __fractdfuta (double A) 2040 These functions convert from fractional and signed non-fractionals 2041 to fractionals and signed non-fractionals, without saturation. 2042 2043 -- Runtime Function: fract __satfractqqhq2 (short fract A) 2044 -- Runtime Function: long fract __satfractqqsq2 (short fract A) 2045 -- Runtime Function: long long fract __satfractqqdq2 (short fract A) 2046 -- Runtime Function: short accum __satfractqqha (short fract A) 2047 -- Runtime Function: accum __satfractqqsa (short fract A) 2048 -- Runtime Function: long accum __satfractqqda (short fract A) 2049 -- Runtime Function: long long accum __satfractqqta (short fract A) 2050 -- Runtime Function: unsigned short fract __satfractqquqq (short fract 2051 A) 2052 -- Runtime Function: unsigned fract __satfractqquhq (short fract A) 2053 -- Runtime Function: unsigned long fract __satfractqqusq (short fract 2054 A) 2055 -- Runtime Function: unsigned long long fract __satfractqqudq (short 2056 fract A) 2057 -- Runtime Function: unsigned short accum __satfractqquha (short fract 2058 A) 2059 -- Runtime Function: unsigned accum __satfractqqusa (short fract A) 2060 -- Runtime Function: unsigned long accum __satfractqquda (short fract 2061 A) 2062 -- Runtime Function: unsigned long long accum __satfractqquta (short 2063 fract A) 2064 -- Runtime Function: short fract __satfracthqqq2 (fract A) 2065 -- Runtime Function: long fract __satfracthqsq2 (fract A) 2066 -- Runtime Function: long long fract __satfracthqdq2 (fract A) 2067 -- Runtime Function: short accum __satfracthqha (fract A) 2068 -- Runtime Function: accum __satfracthqsa (fract A) 2069 -- Runtime Function: long accum __satfracthqda (fract A) 2070 -- Runtime Function: long long accum __satfracthqta (fract A) 2071 -- Runtime Function: unsigned short fract __satfracthquqq (fract A) 2072 -- Runtime Function: unsigned fract __satfracthquhq (fract A) 2073 -- Runtime Function: unsigned long fract __satfracthqusq (fract A) 2074 -- Runtime Function: unsigned long long fract __satfracthqudq (fract A) 2075 -- Runtime Function: unsigned short accum __satfracthquha (fract A) 2076 -- Runtime Function: unsigned accum __satfracthqusa (fract A) 2077 -- Runtime Function: unsigned long accum __satfracthquda (fract A) 2078 -- Runtime Function: unsigned long long accum __satfracthquta (fract A) 2079 -- Runtime Function: short fract __satfractsqqq2 (long fract A) 2080 -- Runtime Function: fract __satfractsqhq2 (long fract A) 2081 -- Runtime Function: long long fract __satfractsqdq2 (long fract A) 2082 -- Runtime Function: short accum __satfractsqha (long fract A) 2083 -- Runtime Function: accum __satfractsqsa (long fract A) 2084 -- Runtime Function: long accum __satfractsqda (long fract A) 2085 -- Runtime Function: long long accum __satfractsqta (long fract A) 2086 -- Runtime Function: unsigned short fract __satfractsquqq (long fract 2087 A) 2088 -- Runtime Function: unsigned fract __satfractsquhq (long fract A) 2089 -- Runtime Function: unsigned long fract __satfractsqusq (long fract A) 2090 -- Runtime Function: unsigned long long fract __satfractsqudq (long 2091 fract A) 2092 -- Runtime Function: unsigned short accum __satfractsquha (long fract 2093 A) 2094 -- Runtime Function: unsigned accum __satfractsqusa (long fract A) 2095 -- Runtime Function: unsigned long accum __satfractsquda (long fract A) 2096 -- Runtime Function: unsigned long long accum __satfractsquta (long 2097 fract A) 2098 -- Runtime Function: short fract __satfractdqqq2 (long long fract A) 2099 -- Runtime Function: fract __satfractdqhq2 (long long fract A) 2100 -- Runtime Function: long fract __satfractdqsq2 (long long fract A) 2101 -- Runtime Function: short accum __satfractdqha (long long fract A) 2102 -- Runtime Function: accum __satfractdqsa (long long fract A) 2103 -- Runtime Function: long accum __satfractdqda (long long fract A) 2104 -- Runtime Function: long long accum __satfractdqta (long long fract A) 2105 -- Runtime Function: unsigned short fract __satfractdquqq (long long 2106 fract A) 2107 -- Runtime Function: unsigned fract __satfractdquhq (long long fract A) 2108 -- Runtime Function: unsigned long fract __satfractdqusq (long long 2109 fract A) 2110 -- Runtime Function: unsigned long long fract __satfractdqudq (long 2111 long fract A) 2112 -- Runtime Function: unsigned short accum __satfractdquha (long long 2113 fract A) 2114 -- Runtime Function: unsigned accum __satfractdqusa (long long fract A) 2115 -- Runtime Function: unsigned long accum __satfractdquda (long long 2116 fract A) 2117 -- Runtime Function: unsigned long long accum __satfractdquta (long 2118 long fract A) 2119 -- Runtime Function: short fract __satfracthaqq (short accum A) 2120 -- Runtime Function: fract __satfracthahq (short accum A) 2121 -- Runtime Function: long fract __satfracthasq (short accum A) 2122 -- Runtime Function: long long fract __satfracthadq (short accum A) 2123 -- Runtime Function: accum __satfracthasa2 (short accum A) 2124 -- Runtime Function: long accum __satfracthada2 (short accum A) 2125 -- Runtime Function: long long accum __satfracthata2 (short accum A) 2126 -- Runtime Function: unsigned short fract __satfracthauqq (short accum 2127 A) 2128 -- Runtime Function: unsigned fract __satfracthauhq (short accum A) 2129 -- Runtime Function: unsigned long fract __satfracthausq (short accum 2130 A) 2131 -- Runtime Function: unsigned long long fract __satfracthaudq (short 2132 accum A) 2133 -- Runtime Function: unsigned short accum __satfracthauha (short accum 2134 A) 2135 -- Runtime Function: unsigned accum __satfracthausa (short accum A) 2136 -- Runtime Function: unsigned long accum __satfracthauda (short accum 2137 A) 2138 -- Runtime Function: unsigned long long accum __satfracthauta (short 2139 accum A) 2140 -- Runtime Function: short fract __satfractsaqq (accum A) 2141 -- Runtime Function: fract __satfractsahq (accum A) 2142 -- Runtime Function: long fract __satfractsasq (accum A) 2143 -- Runtime Function: long long fract __satfractsadq (accum A) 2144 -- Runtime Function: short accum __satfractsaha2 (accum A) 2145 -- Runtime Function: long accum __satfractsada2 (accum A) 2146 -- Runtime Function: long long accum __satfractsata2 (accum A) 2147 -- Runtime Function: unsigned short fract __satfractsauqq (accum A) 2148 -- Runtime Function: unsigned fract __satfractsauhq (accum A) 2149 -- Runtime Function: unsigned long fract __satfractsausq (accum A) 2150 -- Runtime Function: unsigned long long fract __satfractsaudq (accum A) 2151 -- Runtime Function: unsigned short accum __satfractsauha (accum A) 2152 -- Runtime Function: unsigned accum __satfractsausa (accum A) 2153 -- Runtime Function: unsigned long accum __satfractsauda (accum A) 2154 -- Runtime Function: unsigned long long accum __satfractsauta (accum A) 2155 -- Runtime Function: short fract __satfractdaqq (long accum A) 2156 -- Runtime Function: fract __satfractdahq (long accum A) 2157 -- Runtime Function: long fract __satfractdasq (long accum A) 2158 -- Runtime Function: long long fract __satfractdadq (long accum A) 2159 -- Runtime Function: short accum __satfractdaha2 (long accum A) 2160 -- Runtime Function: accum __satfractdasa2 (long accum A) 2161 -- Runtime Function: long long accum __satfractdata2 (long accum A) 2162 -- Runtime Function: unsigned short fract __satfractdauqq (long accum 2163 A) 2164 -- Runtime Function: unsigned fract __satfractdauhq (long accum A) 2165 -- Runtime Function: unsigned long fract __satfractdausq (long accum A) 2166 -- Runtime Function: unsigned long long fract __satfractdaudq (long 2167 accum A) 2168 -- Runtime Function: unsigned short accum __satfractdauha (long accum 2169 A) 2170 -- Runtime Function: unsigned accum __satfractdausa (long accum A) 2171 -- Runtime Function: unsigned long accum __satfractdauda (long accum A) 2172 -- Runtime Function: unsigned long long accum __satfractdauta (long 2173 accum A) 2174 -- Runtime Function: short fract __satfracttaqq (long long accum A) 2175 -- Runtime Function: fract __satfracttahq (long long accum A) 2176 -- Runtime Function: long fract __satfracttasq (long long accum A) 2177 -- Runtime Function: long long fract __satfracttadq (long long accum A) 2178 -- Runtime Function: short accum __satfracttaha2 (long long accum A) 2179 -- Runtime Function: accum __satfracttasa2 (long long accum A) 2180 -- Runtime Function: long accum __satfracttada2 (long long accum A) 2181 -- Runtime Function: unsigned short fract __satfracttauqq (long long 2182 accum A) 2183 -- Runtime Function: unsigned fract __satfracttauhq (long long accum A) 2184 -- Runtime Function: unsigned long fract __satfracttausq (long long 2185 accum A) 2186 -- Runtime Function: unsigned long long fract __satfracttaudq (long 2187 long accum A) 2188 -- Runtime Function: unsigned short accum __satfracttauha (long long 2189 accum A) 2190 -- Runtime Function: unsigned accum __satfracttausa (long long accum A) 2191 -- Runtime Function: unsigned long accum __satfracttauda (long long 2192 accum A) 2193 -- Runtime Function: unsigned long long accum __satfracttauta (long 2194 long accum A) 2195 -- Runtime Function: short fract __satfractuqqqq (unsigned short fract 2196 A) 2197 -- Runtime Function: fract __satfractuqqhq (unsigned short fract A) 2198 -- Runtime Function: long fract __satfractuqqsq (unsigned short fract 2199 A) 2200 -- Runtime Function: long long fract __satfractuqqdq (unsigned short 2201 fract A) 2202 -- Runtime Function: short accum __satfractuqqha (unsigned short fract 2203 A) 2204 -- Runtime Function: accum __satfractuqqsa (unsigned short fract A) 2205 -- Runtime Function: long accum __satfractuqqda (unsigned short fract 2206 A) 2207 -- Runtime Function: long long accum __satfractuqqta (unsigned short 2208 fract A) 2209 -- Runtime Function: unsigned fract __satfractuqquhq2 (unsigned short 2210 fract A) 2211 -- Runtime Function: unsigned long fract __satfractuqqusq2 (unsigned 2212 short fract A) 2213 -- Runtime Function: unsigned long long fract __satfractuqqudq2 2214 (unsigned short fract A) 2215 -- Runtime Function: unsigned short accum __satfractuqquha (unsigned 2216 short fract A) 2217 -- Runtime Function: unsigned accum __satfractuqqusa (unsigned short 2218 fract A) 2219 -- Runtime Function: unsigned long accum __satfractuqquda (unsigned 2220 short fract A) 2221 -- Runtime Function: unsigned long long accum __satfractuqquta 2222 (unsigned short fract A) 2223 -- Runtime Function: short fract __satfractuhqqq (unsigned fract A) 2224 -- Runtime Function: fract __satfractuhqhq (unsigned fract A) 2225 -- Runtime Function: long fract __satfractuhqsq (unsigned fract A) 2226 -- Runtime Function: long long fract __satfractuhqdq (unsigned fract A) 2227 -- Runtime Function: short accum __satfractuhqha (unsigned fract A) 2228 -- Runtime Function: accum __satfractuhqsa (unsigned fract A) 2229 -- Runtime Function: long accum __satfractuhqda (unsigned fract A) 2230 -- Runtime Function: long long accum __satfractuhqta (unsigned fract A) 2231 -- Runtime Function: unsigned short fract __satfractuhquqq2 (unsigned 2232 fract A) 2233 -- Runtime Function: unsigned long fract __satfractuhqusq2 (unsigned 2234 fract A) 2235 -- Runtime Function: unsigned long long fract __satfractuhqudq2 2236 (unsigned fract A) 2237 -- Runtime Function: unsigned short accum __satfractuhquha (unsigned 2238 fract A) 2239 -- Runtime Function: unsigned accum __satfractuhqusa (unsigned fract A) 2240 -- Runtime Function: unsigned long accum __satfractuhquda (unsigned 2241 fract A) 2242 -- Runtime Function: unsigned long long accum __satfractuhquta 2243 (unsigned fract A) 2244 -- Runtime Function: short fract __satfractusqqq (unsigned long fract 2245 A) 2246 -- Runtime Function: fract __satfractusqhq (unsigned long fract A) 2247 -- Runtime Function: long fract __satfractusqsq (unsigned long fract A) 2248 -- Runtime Function: long long fract __satfractusqdq (unsigned long 2249 fract A) 2250 -- Runtime Function: short accum __satfractusqha (unsigned long fract 2251 A) 2252 -- Runtime Function: accum __satfractusqsa (unsigned long fract A) 2253 -- Runtime Function: long accum __satfractusqda (unsigned long fract A) 2254 -- Runtime Function: long long accum __satfractusqta (unsigned long 2255 fract A) 2256 -- Runtime Function: unsigned short fract __satfractusquqq2 (unsigned 2257 long fract A) 2258 -- Runtime Function: unsigned fract __satfractusquhq2 (unsigned long 2259 fract A) 2260 -- Runtime Function: unsigned long long fract __satfractusqudq2 2261 (unsigned long fract A) 2262 -- Runtime Function: unsigned short accum __satfractusquha (unsigned 2263 long fract A) 2264 -- Runtime Function: unsigned accum __satfractusqusa (unsigned long 2265 fract A) 2266 -- Runtime Function: unsigned long accum __satfractusquda (unsigned 2267 long fract A) 2268 -- Runtime Function: unsigned long long accum __satfractusquta 2269 (unsigned long fract A) 2270 -- Runtime Function: short fract __satfractudqqq (unsigned long long 2271 fract A) 2272 -- Runtime Function: fract __satfractudqhq (unsigned long long fract A) 2273 -- Runtime Function: long fract __satfractudqsq (unsigned long long 2274 fract A) 2275 -- Runtime Function: long long fract __satfractudqdq (unsigned long 2276 long fract A) 2277 -- Runtime Function: short accum __satfractudqha (unsigned long long 2278 fract A) 2279 -- Runtime Function: accum __satfractudqsa (unsigned long long fract A) 2280 -- Runtime Function: long accum __satfractudqda (unsigned long long 2281 fract A) 2282 -- Runtime Function: long long accum __satfractudqta (unsigned long 2283 long fract A) 2284 -- Runtime Function: unsigned short fract __satfractudquqq2 (unsigned 2285 long long fract A) 2286 -- Runtime Function: unsigned fract __satfractudquhq2 (unsigned long 2287 long fract A) 2288 -- Runtime Function: unsigned long fract __satfractudqusq2 (unsigned 2289 long long fract A) 2290 -- Runtime Function: unsigned short accum __satfractudquha (unsigned 2291 long long fract A) 2292 -- Runtime Function: unsigned accum __satfractudqusa (unsigned long 2293 long fract A) 2294 -- Runtime Function: unsigned long accum __satfractudquda (unsigned 2295 long long fract A) 2296 -- Runtime Function: unsigned long long accum __satfractudquta 2297 (unsigned long long fract A) 2298 -- Runtime Function: short fract __satfractuhaqq (unsigned short accum 2299 A) 2300 -- Runtime Function: fract __satfractuhahq (unsigned short accum A) 2301 -- Runtime Function: long fract __satfractuhasq (unsigned short accum 2302 A) 2303 -- Runtime Function: long long fract __satfractuhadq (unsigned short 2304 accum A) 2305 -- Runtime Function: short accum __satfractuhaha (unsigned short accum 2306 A) 2307 -- Runtime Function: accum __satfractuhasa (unsigned short accum A) 2308 -- Runtime Function: long accum __satfractuhada (unsigned short accum 2309 A) 2310 -- Runtime Function: long long accum __satfractuhata (unsigned short 2311 accum A) 2312 -- Runtime Function: unsigned short fract __satfractuhauqq (unsigned 2313 short accum A) 2314 -- Runtime Function: unsigned fract __satfractuhauhq (unsigned short 2315 accum A) 2316 -- Runtime Function: unsigned long fract __satfractuhausq (unsigned 2317 short accum A) 2318 -- Runtime Function: unsigned long long fract __satfractuhaudq 2319 (unsigned short accum A) 2320 -- Runtime Function: unsigned accum __satfractuhausa2 (unsigned short 2321 accum A) 2322 -- Runtime Function: unsigned long accum __satfractuhauda2 (unsigned 2323 short accum A) 2324 -- Runtime Function: unsigned long long accum __satfractuhauta2 2325 (unsigned short accum A) 2326 -- Runtime Function: short fract __satfractusaqq (unsigned accum A) 2327 -- Runtime Function: fract __satfractusahq (unsigned accum A) 2328 -- Runtime Function: long fract __satfractusasq (unsigned accum A) 2329 -- Runtime Function: long long fract __satfractusadq (unsigned accum A) 2330 -- Runtime Function: short accum __satfractusaha (unsigned accum A) 2331 -- Runtime Function: accum __satfractusasa (unsigned accum A) 2332 -- Runtime Function: long accum __satfractusada (unsigned accum A) 2333 -- Runtime Function: long long accum __satfractusata (unsigned accum A) 2334 -- Runtime Function: unsigned short fract __satfractusauqq (unsigned 2335 accum A) 2336 -- Runtime Function: unsigned fract __satfractusauhq (unsigned accum A) 2337 -- Runtime Function: unsigned long fract __satfractusausq (unsigned 2338 accum A) 2339 -- Runtime Function: unsigned long long fract __satfractusaudq 2340 (unsigned accum A) 2341 -- Runtime Function: unsigned short accum __satfractusauha2 (unsigned 2342 accum A) 2343 -- Runtime Function: unsigned long accum __satfractusauda2 (unsigned 2344 accum A) 2345 -- Runtime Function: unsigned long long accum __satfractusauta2 2346 (unsigned accum A) 2347 -- Runtime Function: short fract __satfractudaqq (unsigned long accum 2348 A) 2349 -- Runtime Function: fract __satfractudahq (unsigned long accum A) 2350 -- Runtime Function: long fract __satfractudasq (unsigned long accum A) 2351 -- Runtime Function: long long fract __satfractudadq (unsigned long 2352 accum A) 2353 -- Runtime Function: short accum __satfractudaha (unsigned long accum 2354 A) 2355 -- Runtime Function: accum __satfractudasa (unsigned long accum A) 2356 -- Runtime Function: long accum __satfractudada (unsigned long accum A) 2357 -- Runtime Function: long long accum __satfractudata (unsigned long 2358 accum A) 2359 -- Runtime Function: unsigned short fract __satfractudauqq (unsigned 2360 long accum A) 2361 -- Runtime Function: unsigned fract __satfractudauhq (unsigned long 2362 accum A) 2363 -- Runtime Function: unsigned long fract __satfractudausq (unsigned 2364 long accum A) 2365 -- Runtime Function: unsigned long long fract __satfractudaudq 2366 (unsigned long accum A) 2367 -- Runtime Function: unsigned short accum __satfractudauha2 (unsigned 2368 long accum A) 2369 -- Runtime Function: unsigned accum __satfractudausa2 (unsigned long 2370 accum A) 2371 -- Runtime Function: unsigned long long accum __satfractudauta2 2372 (unsigned long accum A) 2373 -- Runtime Function: short fract __satfractutaqq (unsigned long long 2374 accum A) 2375 -- Runtime Function: fract __satfractutahq (unsigned long long accum A) 2376 -- Runtime Function: long fract __satfractutasq (unsigned long long 2377 accum A) 2378 -- Runtime Function: long long fract __satfractutadq (unsigned long 2379 long accum A) 2380 -- Runtime Function: short accum __satfractutaha (unsigned long long 2381 accum A) 2382 -- Runtime Function: accum __satfractutasa (unsigned long long accum A) 2383 -- Runtime Function: long accum __satfractutada (unsigned long long 2384 accum A) 2385 -- Runtime Function: long long accum __satfractutata (unsigned long 2386 long accum A) 2387 -- Runtime Function: unsigned short fract __satfractutauqq (unsigned 2388 long long accum A) 2389 -- Runtime Function: unsigned fract __satfractutauhq (unsigned long 2390 long accum A) 2391 -- Runtime Function: unsigned long fract __satfractutausq (unsigned 2392 long long accum A) 2393 -- Runtime Function: unsigned long long fract __satfractutaudq 2394 (unsigned long long accum A) 2395 -- Runtime Function: unsigned short accum __satfractutauha2 (unsigned 2396 long long accum A) 2397 -- Runtime Function: unsigned accum __satfractutausa2 (unsigned long 2398 long accum A) 2399 -- Runtime Function: unsigned long accum __satfractutauda2 (unsigned 2400 long long accum A) 2401 -- Runtime Function: short fract __satfractqiqq (signed char A) 2402 -- Runtime Function: fract __satfractqihq (signed char A) 2403 -- Runtime Function: long fract __satfractqisq (signed char A) 2404 -- Runtime Function: long long fract __satfractqidq (signed char A) 2405 -- Runtime Function: short accum __satfractqiha (signed char A) 2406 -- Runtime Function: accum __satfractqisa (signed char A) 2407 -- Runtime Function: long accum __satfractqida (signed char A) 2408 -- Runtime Function: long long accum __satfractqita (signed char A) 2409 -- Runtime Function: unsigned short fract __satfractqiuqq (signed char 2410 A) 2411 -- Runtime Function: unsigned fract __satfractqiuhq (signed char A) 2412 -- Runtime Function: unsigned long fract __satfractqiusq (signed char 2413 A) 2414 -- Runtime Function: unsigned long long fract __satfractqiudq (signed 2415 char A) 2416 -- Runtime Function: unsigned short accum __satfractqiuha (signed char 2417 A) 2418 -- Runtime Function: unsigned accum __satfractqiusa (signed char A) 2419 -- Runtime Function: unsigned long accum __satfractqiuda (signed char 2420 A) 2421 -- Runtime Function: unsigned long long accum __satfractqiuta (signed 2422 char A) 2423 -- Runtime Function: short fract __satfracthiqq (short A) 2424 -- Runtime Function: fract __satfracthihq (short A) 2425 -- Runtime Function: long fract __satfracthisq (short A) 2426 -- Runtime Function: long long fract __satfracthidq (short A) 2427 -- Runtime Function: short accum __satfracthiha (short A) 2428 -- Runtime Function: accum __satfracthisa (short A) 2429 -- Runtime Function: long accum __satfracthida (short A) 2430 -- Runtime Function: long long accum __satfracthita (short A) 2431 -- Runtime Function: unsigned short fract __satfracthiuqq (short A) 2432 -- Runtime Function: unsigned fract __satfracthiuhq (short A) 2433 -- Runtime Function: unsigned long fract __satfracthiusq (short A) 2434 -- Runtime Function: unsigned long long fract __satfracthiudq (short A) 2435 -- Runtime Function: unsigned short accum __satfracthiuha (short A) 2436 -- Runtime Function: unsigned accum __satfracthiusa (short A) 2437 -- Runtime Function: unsigned long accum __satfracthiuda (short A) 2438 -- Runtime Function: unsigned long long accum __satfracthiuta (short A) 2439 -- Runtime Function: short fract __satfractsiqq (int A) 2440 -- Runtime Function: fract __satfractsihq (int A) 2441 -- Runtime Function: long fract __satfractsisq (int A) 2442 -- Runtime Function: long long fract __satfractsidq (int A) 2443 -- Runtime Function: short accum __satfractsiha (int A) 2444 -- Runtime Function: accum __satfractsisa (int A) 2445 -- Runtime Function: long accum __satfractsida (int A) 2446 -- Runtime Function: long long accum __satfractsita (int A) 2447 -- Runtime Function: unsigned short fract __satfractsiuqq (int A) 2448 -- Runtime Function: unsigned fract __satfractsiuhq (int A) 2449 -- Runtime Function: unsigned long fract __satfractsiusq (int A) 2450 -- Runtime Function: unsigned long long fract __satfractsiudq (int A) 2451 -- Runtime Function: unsigned short accum __satfractsiuha (int A) 2452 -- Runtime Function: unsigned accum __satfractsiusa (int A) 2453 -- Runtime Function: unsigned long accum __satfractsiuda (int A) 2454 -- Runtime Function: unsigned long long accum __satfractsiuta (int A) 2455 -- Runtime Function: short fract __satfractdiqq (long A) 2456 -- Runtime Function: fract __satfractdihq (long A) 2457 -- Runtime Function: long fract __satfractdisq (long A) 2458 -- Runtime Function: long long fract __satfractdidq (long A) 2459 -- Runtime Function: short accum __satfractdiha (long A) 2460 -- Runtime Function: accum __satfractdisa (long A) 2461 -- Runtime Function: long accum __satfractdida (long A) 2462 -- Runtime Function: long long accum __satfractdita (long A) 2463 -- Runtime Function: unsigned short fract __satfractdiuqq (long A) 2464 -- Runtime Function: unsigned fract __satfractdiuhq (long A) 2465 -- Runtime Function: unsigned long fract __satfractdiusq (long A) 2466 -- Runtime Function: unsigned long long fract __satfractdiudq (long A) 2467 -- Runtime Function: unsigned short accum __satfractdiuha (long A) 2468 -- Runtime Function: unsigned accum __satfractdiusa (long A) 2469 -- Runtime Function: unsigned long accum __satfractdiuda (long A) 2470 -- Runtime Function: unsigned long long accum __satfractdiuta (long A) 2471 -- Runtime Function: short fract __satfracttiqq (long long A) 2472 -- Runtime Function: fract __satfracttihq (long long A) 2473 -- Runtime Function: long fract __satfracttisq (long long A) 2474 -- Runtime Function: long long fract __satfracttidq (long long A) 2475 -- Runtime Function: short accum __satfracttiha (long long A) 2476 -- Runtime Function: accum __satfracttisa (long long A) 2477 -- Runtime Function: long accum __satfracttida (long long A) 2478 -- Runtime Function: long long accum __satfracttita (long long A) 2479 -- Runtime Function: unsigned short fract __satfracttiuqq (long long A) 2480 -- Runtime Function: unsigned fract __satfracttiuhq (long long A) 2481 -- Runtime Function: unsigned long fract __satfracttiusq (long long A) 2482 -- Runtime Function: unsigned long long fract __satfracttiudq (long 2483 long A) 2484 -- Runtime Function: unsigned short accum __satfracttiuha (long long A) 2485 -- Runtime Function: unsigned accum __satfracttiusa (long long A) 2486 -- Runtime Function: unsigned long accum __satfracttiuda (long long A) 2487 -- Runtime Function: unsigned long long accum __satfracttiuta (long 2488 long A) 2489 -- Runtime Function: short fract __satfractsfqq (float A) 2490 -- Runtime Function: fract __satfractsfhq (float A) 2491 -- Runtime Function: long fract __satfractsfsq (float A) 2492 -- Runtime Function: long long fract __satfractsfdq (float A) 2493 -- Runtime Function: short accum __satfractsfha (float A) 2494 -- Runtime Function: accum __satfractsfsa (float A) 2495 -- Runtime Function: long accum __satfractsfda (float A) 2496 -- Runtime Function: long long accum __satfractsfta (float A) 2497 -- Runtime Function: unsigned short fract __satfractsfuqq (float A) 2498 -- Runtime Function: unsigned fract __satfractsfuhq (float A) 2499 -- Runtime Function: unsigned long fract __satfractsfusq (float A) 2500 -- Runtime Function: unsigned long long fract __satfractsfudq (float A) 2501 -- Runtime Function: unsigned short accum __satfractsfuha (float A) 2502 -- Runtime Function: unsigned accum __satfractsfusa (float A) 2503 -- Runtime Function: unsigned long accum __satfractsfuda (float A) 2504 -- Runtime Function: unsigned long long accum __satfractsfuta (float A) 2505 -- Runtime Function: short fract __satfractdfqq (double A) 2506 -- Runtime Function: fract __satfractdfhq (double A) 2507 -- Runtime Function: long fract __satfractdfsq (double A) 2508 -- Runtime Function: long long fract __satfractdfdq (double A) 2509 -- Runtime Function: short accum __satfractdfha (double A) 2510 -- Runtime Function: accum __satfractdfsa (double A) 2511 -- Runtime Function: long accum __satfractdfda (double A) 2512 -- Runtime Function: long long accum __satfractdfta (double A) 2513 -- Runtime Function: unsigned short fract __satfractdfuqq (double A) 2514 -- Runtime Function: unsigned fract __satfractdfuhq (double A) 2515 -- Runtime Function: unsigned long fract __satfractdfusq (double A) 2516 -- Runtime Function: unsigned long long fract __satfractdfudq (double 2517 A) 2518 -- Runtime Function: unsigned short accum __satfractdfuha (double A) 2519 -- Runtime Function: unsigned accum __satfractdfusa (double A) 2520 -- Runtime Function: unsigned long accum __satfractdfuda (double A) 2521 -- Runtime Function: unsigned long long accum __satfractdfuta (double 2522 A) 2523 The functions convert from fractional and signed non-fractionals to 2524 fractionals, with saturation. 2525 2526 -- Runtime Function: unsigned char __fractunsqqqi (short fract A) 2527 -- Runtime Function: unsigned short __fractunsqqhi (short fract A) 2528 -- Runtime Function: unsigned int __fractunsqqsi (short fract A) 2529 -- Runtime Function: unsigned long __fractunsqqdi (short fract A) 2530 -- Runtime Function: unsigned long long __fractunsqqti (short fract A) 2531 -- Runtime Function: unsigned char __fractunshqqi (fract A) 2532 -- Runtime Function: unsigned short __fractunshqhi (fract A) 2533 -- Runtime Function: unsigned int __fractunshqsi (fract A) 2534 -- Runtime Function: unsigned long __fractunshqdi (fract A) 2535 -- Runtime Function: unsigned long long __fractunshqti (fract A) 2536 -- Runtime Function: unsigned char __fractunssqqi (long fract A) 2537 -- Runtime Function: unsigned short __fractunssqhi (long fract A) 2538 -- Runtime Function: unsigned int __fractunssqsi (long fract A) 2539 -- Runtime Function: unsigned long __fractunssqdi (long fract A) 2540 -- Runtime Function: unsigned long long __fractunssqti (long fract A) 2541 -- Runtime Function: unsigned char __fractunsdqqi (long long fract A) 2542 -- Runtime Function: unsigned short __fractunsdqhi (long long fract A) 2543 -- Runtime Function: unsigned int __fractunsdqsi (long long fract A) 2544 -- Runtime Function: unsigned long __fractunsdqdi (long long fract A) 2545 -- Runtime Function: unsigned long long __fractunsdqti (long long 2546 fract A) 2547 -- Runtime Function: unsigned char __fractunshaqi (short accum A) 2548 -- Runtime Function: unsigned short __fractunshahi (short accum A) 2549 -- Runtime Function: unsigned int __fractunshasi (short accum A) 2550 -- Runtime Function: unsigned long __fractunshadi (short accum A) 2551 -- Runtime Function: unsigned long long __fractunshati (short accum A) 2552 -- Runtime Function: unsigned char __fractunssaqi (accum A) 2553 -- Runtime Function: unsigned short __fractunssahi (accum A) 2554 -- Runtime Function: unsigned int __fractunssasi (accum A) 2555 -- Runtime Function: unsigned long __fractunssadi (accum A) 2556 -- Runtime Function: unsigned long long __fractunssati (accum A) 2557 -- Runtime Function: unsigned char __fractunsdaqi (long accum A) 2558 -- Runtime Function: unsigned short __fractunsdahi (long accum A) 2559 -- Runtime Function: unsigned int __fractunsdasi (long accum A) 2560 -- Runtime Function: unsigned long __fractunsdadi (long accum A) 2561 -- Runtime Function: unsigned long long __fractunsdati (long accum A) 2562 -- Runtime Function: unsigned char __fractunstaqi (long long accum A) 2563 -- Runtime Function: unsigned short __fractunstahi (long long accum A) 2564 -- Runtime Function: unsigned int __fractunstasi (long long accum A) 2565 -- Runtime Function: unsigned long __fractunstadi (long long accum A) 2566 -- Runtime Function: unsigned long long __fractunstati (long long 2567 accum A) 2568 -- Runtime Function: unsigned char __fractunsuqqqi (unsigned short 2569 fract A) 2570 -- Runtime Function: unsigned short __fractunsuqqhi (unsigned short 2571 fract A) 2572 -- Runtime Function: unsigned int __fractunsuqqsi (unsigned short 2573 fract A) 2574 -- Runtime Function: unsigned long __fractunsuqqdi (unsigned short 2575 fract A) 2576 -- Runtime Function: unsigned long long __fractunsuqqti (unsigned 2577 short fract A) 2578 -- Runtime Function: unsigned char __fractunsuhqqi (unsigned fract A) 2579 -- Runtime Function: unsigned short __fractunsuhqhi (unsigned fract A) 2580 -- Runtime Function: unsigned int __fractunsuhqsi (unsigned fract A) 2581 -- Runtime Function: unsigned long __fractunsuhqdi (unsigned fract A) 2582 -- Runtime Function: unsigned long long __fractunsuhqti (unsigned 2583 fract A) 2584 -- Runtime Function: unsigned char __fractunsusqqi (unsigned long 2585 fract A) 2586 -- Runtime Function: unsigned short __fractunsusqhi (unsigned long 2587 fract A) 2588 -- Runtime Function: unsigned int __fractunsusqsi (unsigned long fract 2589 A) 2590 -- Runtime Function: unsigned long __fractunsusqdi (unsigned long 2591 fract A) 2592 -- Runtime Function: unsigned long long __fractunsusqti (unsigned long 2593 fract A) 2594 -- Runtime Function: unsigned char __fractunsudqqi (unsigned long long 2595 fract A) 2596 -- Runtime Function: unsigned short __fractunsudqhi (unsigned long 2597 long fract A) 2598 -- Runtime Function: unsigned int __fractunsudqsi (unsigned long long 2599 fract A) 2600 -- Runtime Function: unsigned long __fractunsudqdi (unsigned long long 2601 fract A) 2602 -- Runtime Function: unsigned long long __fractunsudqti (unsigned long 2603 long fract A) 2604 -- Runtime Function: unsigned char __fractunsuhaqi (unsigned short 2605 accum A) 2606 -- Runtime Function: unsigned short __fractunsuhahi (unsigned short 2607 accum A) 2608 -- Runtime Function: unsigned int __fractunsuhasi (unsigned short 2609 accum A) 2610 -- Runtime Function: unsigned long __fractunsuhadi (unsigned short 2611 accum A) 2612 -- Runtime Function: unsigned long long __fractunsuhati (unsigned 2613 short accum A) 2614 -- Runtime Function: unsigned char __fractunsusaqi (unsigned accum A) 2615 -- Runtime Function: unsigned short __fractunsusahi (unsigned accum A) 2616 -- Runtime Function: unsigned int __fractunsusasi (unsigned accum A) 2617 -- Runtime Function: unsigned long __fractunsusadi (unsigned accum A) 2618 -- Runtime Function: unsigned long long __fractunsusati (unsigned 2619 accum A) 2620 -- Runtime Function: unsigned char __fractunsudaqi (unsigned long 2621 accum A) 2622 -- Runtime Function: unsigned short __fractunsudahi (unsigned long 2623 accum A) 2624 -- Runtime Function: unsigned int __fractunsudasi (unsigned long accum 2625 A) 2626 -- Runtime Function: unsigned long __fractunsudadi (unsigned long 2627 accum A) 2628 -- Runtime Function: unsigned long long __fractunsudati (unsigned long 2629 accum A) 2630 -- Runtime Function: unsigned char __fractunsutaqi (unsigned long long 2631 accum A) 2632 -- Runtime Function: unsigned short __fractunsutahi (unsigned long 2633 long accum A) 2634 -- Runtime Function: unsigned int __fractunsutasi (unsigned long long 2635 accum A) 2636 -- Runtime Function: unsigned long __fractunsutadi (unsigned long long 2637 accum A) 2638 -- Runtime Function: unsigned long long __fractunsutati (unsigned long 2639 long accum A) 2640 -- Runtime Function: short fract __fractunsqiqq (unsigned char A) 2641 -- Runtime Function: fract __fractunsqihq (unsigned char A) 2642 -- Runtime Function: long fract __fractunsqisq (unsigned char A) 2643 -- Runtime Function: long long fract __fractunsqidq (unsigned char A) 2644 -- Runtime Function: short accum __fractunsqiha (unsigned char A) 2645 -- Runtime Function: accum __fractunsqisa (unsigned char A) 2646 -- Runtime Function: long accum __fractunsqida (unsigned char A) 2647 -- Runtime Function: long long accum __fractunsqita (unsigned char A) 2648 -- Runtime Function: unsigned short fract __fractunsqiuqq (unsigned 2649 char A) 2650 -- Runtime Function: unsigned fract __fractunsqiuhq (unsigned char A) 2651 -- Runtime Function: unsigned long fract __fractunsqiusq (unsigned 2652 char A) 2653 -- Runtime Function: unsigned long long fract __fractunsqiudq 2654 (unsigned char A) 2655 -- Runtime Function: unsigned short accum __fractunsqiuha (unsigned 2656 char A) 2657 -- Runtime Function: unsigned accum __fractunsqiusa (unsigned char A) 2658 -- Runtime Function: unsigned long accum __fractunsqiuda (unsigned 2659 char A) 2660 -- Runtime Function: unsigned long long accum __fractunsqiuta 2661 (unsigned char A) 2662 -- Runtime Function: short fract __fractunshiqq (unsigned short A) 2663 -- Runtime Function: fract __fractunshihq (unsigned short A) 2664 -- Runtime Function: long fract __fractunshisq (unsigned short A) 2665 -- Runtime Function: long long fract __fractunshidq (unsigned short A) 2666 -- Runtime Function: short accum __fractunshiha (unsigned short A) 2667 -- Runtime Function: accum __fractunshisa (unsigned short A) 2668 -- Runtime Function: long accum __fractunshida (unsigned short A) 2669 -- Runtime Function: long long accum __fractunshita (unsigned short A) 2670 -- Runtime Function: unsigned short fract __fractunshiuqq (unsigned 2671 short A) 2672 -- Runtime Function: unsigned fract __fractunshiuhq (unsigned short A) 2673 -- Runtime Function: unsigned long fract __fractunshiusq (unsigned 2674 short A) 2675 -- Runtime Function: unsigned long long fract __fractunshiudq 2676 (unsigned short A) 2677 -- Runtime Function: unsigned short accum __fractunshiuha (unsigned 2678 short A) 2679 -- Runtime Function: unsigned accum __fractunshiusa (unsigned short A) 2680 -- Runtime Function: unsigned long accum __fractunshiuda (unsigned 2681 short A) 2682 -- Runtime Function: unsigned long long accum __fractunshiuta 2683 (unsigned short A) 2684 -- Runtime Function: short fract __fractunssiqq (unsigned int A) 2685 -- Runtime Function: fract __fractunssihq (unsigned int A) 2686 -- Runtime Function: long fract __fractunssisq (unsigned int A) 2687 -- Runtime Function: long long fract __fractunssidq (unsigned int A) 2688 -- Runtime Function: short accum __fractunssiha (unsigned int A) 2689 -- Runtime Function: accum __fractunssisa (unsigned int A) 2690 -- Runtime Function: long accum __fractunssida (unsigned int A) 2691 -- Runtime Function: long long accum __fractunssita (unsigned int A) 2692 -- Runtime Function: unsigned short fract __fractunssiuqq (unsigned 2693 int A) 2694 -- Runtime Function: unsigned fract __fractunssiuhq (unsigned int A) 2695 -- Runtime Function: unsigned long fract __fractunssiusq (unsigned int 2696 A) 2697 -- Runtime Function: unsigned long long fract __fractunssiudq 2698 (unsigned int A) 2699 -- Runtime Function: unsigned short accum __fractunssiuha (unsigned 2700 int A) 2701 -- Runtime Function: unsigned accum __fractunssiusa (unsigned int A) 2702 -- Runtime Function: unsigned long accum __fractunssiuda (unsigned int 2703 A) 2704 -- Runtime Function: unsigned long long accum __fractunssiuta 2705 (unsigned int A) 2706 -- Runtime Function: short fract __fractunsdiqq (unsigned long A) 2707 -- Runtime Function: fract __fractunsdihq (unsigned long A) 2708 -- Runtime Function: long fract __fractunsdisq (unsigned long A) 2709 -- Runtime Function: long long fract __fractunsdidq (unsigned long A) 2710 -- Runtime Function: short accum __fractunsdiha (unsigned long A) 2711 -- Runtime Function: accum __fractunsdisa (unsigned long A) 2712 -- Runtime Function: long accum __fractunsdida (unsigned long A) 2713 -- Runtime Function: long long accum __fractunsdita (unsigned long A) 2714 -- Runtime Function: unsigned short fract __fractunsdiuqq (unsigned 2715 long A) 2716 -- Runtime Function: unsigned fract __fractunsdiuhq (unsigned long A) 2717 -- Runtime Function: unsigned long fract __fractunsdiusq (unsigned 2718 long A) 2719 -- Runtime Function: unsigned long long fract __fractunsdiudq 2720 (unsigned long A) 2721 -- Runtime Function: unsigned short accum __fractunsdiuha (unsigned 2722 long A) 2723 -- Runtime Function: unsigned accum __fractunsdiusa (unsigned long A) 2724 -- Runtime Function: unsigned long accum __fractunsdiuda (unsigned 2725 long A) 2726 -- Runtime Function: unsigned long long accum __fractunsdiuta 2727 (unsigned long A) 2728 -- Runtime Function: short fract __fractunstiqq (unsigned long long A) 2729 -- Runtime Function: fract __fractunstihq (unsigned long long A) 2730 -- Runtime Function: long fract __fractunstisq (unsigned long long A) 2731 -- Runtime Function: long long fract __fractunstidq (unsigned long 2732 long A) 2733 -- Runtime Function: short accum __fractunstiha (unsigned long long A) 2734 -- Runtime Function: accum __fractunstisa (unsigned long long A) 2735 -- Runtime Function: long accum __fractunstida (unsigned long long A) 2736 -- Runtime Function: long long accum __fractunstita (unsigned long 2737 long A) 2738 -- Runtime Function: unsigned short fract __fractunstiuqq (unsigned 2739 long long A) 2740 -- Runtime Function: unsigned fract __fractunstiuhq (unsigned long 2741 long A) 2742 -- Runtime Function: unsigned long fract __fractunstiusq (unsigned 2743 long long A) 2744 -- Runtime Function: unsigned long long fract __fractunstiudq 2745 (unsigned long long A) 2746 -- Runtime Function: unsigned short accum __fractunstiuha (unsigned 2747 long long A) 2748 -- Runtime Function: unsigned accum __fractunstiusa (unsigned long 2749 long A) 2750 -- Runtime Function: unsigned long accum __fractunstiuda (unsigned 2751 long long A) 2752 -- Runtime Function: unsigned long long accum __fractunstiuta 2753 (unsigned long long A) 2754 These functions convert from fractionals to unsigned 2755 non-fractionals; and from unsigned non-fractionals to fractionals, 2756 without saturation. 2757 2758 -- Runtime Function: short fract __satfractunsqiqq (unsigned char A) 2759 -- Runtime Function: fract __satfractunsqihq (unsigned char A) 2760 -- Runtime Function: long fract __satfractunsqisq (unsigned char A) 2761 -- Runtime Function: long long fract __satfractunsqidq (unsigned char 2762 A) 2763 -- Runtime Function: short accum __satfractunsqiha (unsigned char A) 2764 -- Runtime Function: accum __satfractunsqisa (unsigned char A) 2765 -- Runtime Function: long accum __satfractunsqida (unsigned char A) 2766 -- Runtime Function: long long accum __satfractunsqita (unsigned char 2767 A) 2768 -- Runtime Function: unsigned short fract __satfractunsqiuqq (unsigned 2769 char A) 2770 -- Runtime Function: unsigned fract __satfractunsqiuhq (unsigned char 2771 A) 2772 -- Runtime Function: unsigned long fract __satfractunsqiusq (unsigned 2773 char A) 2774 -- Runtime Function: unsigned long long fract __satfractunsqiudq 2775 (unsigned char A) 2776 -- Runtime Function: unsigned short accum __satfractunsqiuha (unsigned 2777 char A) 2778 -- Runtime Function: unsigned accum __satfractunsqiusa (unsigned char 2779 A) 2780 -- Runtime Function: unsigned long accum __satfractunsqiuda (unsigned 2781 char A) 2782 -- Runtime Function: unsigned long long accum __satfractunsqiuta 2783 (unsigned char A) 2784 -- Runtime Function: short fract __satfractunshiqq (unsigned short A) 2785 -- Runtime Function: fract __satfractunshihq (unsigned short A) 2786 -- Runtime Function: long fract __satfractunshisq (unsigned short A) 2787 -- Runtime Function: long long fract __satfractunshidq (unsigned short 2788 A) 2789 -- Runtime Function: short accum __satfractunshiha (unsigned short A) 2790 -- Runtime Function: accum __satfractunshisa (unsigned short A) 2791 -- Runtime Function: long accum __satfractunshida (unsigned short A) 2792 -- Runtime Function: long long accum __satfractunshita (unsigned short 2793 A) 2794 -- Runtime Function: unsigned short fract __satfractunshiuqq (unsigned 2795 short A) 2796 -- Runtime Function: unsigned fract __satfractunshiuhq (unsigned short 2797 A) 2798 -- Runtime Function: unsigned long fract __satfractunshiusq (unsigned 2799 short A) 2800 -- Runtime Function: unsigned long long fract __satfractunshiudq 2801 (unsigned short A) 2802 -- Runtime Function: unsigned short accum __satfractunshiuha (unsigned 2803 short A) 2804 -- Runtime Function: unsigned accum __satfractunshiusa (unsigned short 2805 A) 2806 -- Runtime Function: unsigned long accum __satfractunshiuda (unsigned 2807 short A) 2808 -- Runtime Function: unsigned long long accum __satfractunshiuta 2809 (unsigned short A) 2810 -- Runtime Function: short fract __satfractunssiqq (unsigned int A) 2811 -- Runtime Function: fract __satfractunssihq (unsigned int A) 2812 -- Runtime Function: long fract __satfractunssisq (unsigned int A) 2813 -- Runtime Function: long long fract __satfractunssidq (unsigned int A) 2814 -- Runtime Function: short accum __satfractunssiha (unsigned int A) 2815 -- Runtime Function: accum __satfractunssisa (unsigned int A) 2816 -- Runtime Function: long accum __satfractunssida (unsigned int A) 2817 -- Runtime Function: long long accum __satfractunssita (unsigned int A) 2818 -- Runtime Function: unsigned short fract __satfractunssiuqq (unsigned 2819 int A) 2820 -- Runtime Function: unsigned fract __satfractunssiuhq (unsigned int A) 2821 -- Runtime Function: unsigned long fract __satfractunssiusq (unsigned 2822 int A) 2823 -- Runtime Function: unsigned long long fract __satfractunssiudq 2824 (unsigned int A) 2825 -- Runtime Function: unsigned short accum __satfractunssiuha (unsigned 2826 int A) 2827 -- Runtime Function: unsigned accum __satfractunssiusa (unsigned int A) 2828 -- Runtime Function: unsigned long accum __satfractunssiuda (unsigned 2829 int A) 2830 -- Runtime Function: unsigned long long accum __satfractunssiuta 2831 (unsigned int A) 2832 -- Runtime Function: short fract __satfractunsdiqq (unsigned long A) 2833 -- Runtime Function: fract __satfractunsdihq (unsigned long A) 2834 -- Runtime Function: long fract __satfractunsdisq (unsigned long A) 2835 -- Runtime Function: long long fract __satfractunsdidq (unsigned long 2836 A) 2837 -- Runtime Function: short accum __satfractunsdiha (unsigned long A) 2838 -- Runtime Function: accum __satfractunsdisa (unsigned long A) 2839 -- Runtime Function: long accum __satfractunsdida (unsigned long A) 2840 -- Runtime Function: long long accum __satfractunsdita (unsigned long 2841 A) 2842 -- Runtime Function: unsigned short fract __satfractunsdiuqq (unsigned 2843 long A) 2844 -- Runtime Function: unsigned fract __satfractunsdiuhq (unsigned long 2845 A) 2846 -- Runtime Function: unsigned long fract __satfractunsdiusq (unsigned 2847 long A) 2848 -- Runtime Function: unsigned long long fract __satfractunsdiudq 2849 (unsigned long A) 2850 -- Runtime Function: unsigned short accum __satfractunsdiuha (unsigned 2851 long A) 2852 -- Runtime Function: unsigned accum __satfractunsdiusa (unsigned long 2853 A) 2854 -- Runtime Function: unsigned long accum __satfractunsdiuda (unsigned 2855 long A) 2856 -- Runtime Function: unsigned long long accum __satfractunsdiuta 2857 (unsigned long A) 2858 -- Runtime Function: short fract __satfractunstiqq (unsigned long long 2859 A) 2860 -- Runtime Function: fract __satfractunstihq (unsigned long long A) 2861 -- Runtime Function: long fract __satfractunstisq (unsigned long long 2862 A) 2863 -- Runtime Function: long long fract __satfractunstidq (unsigned long 2864 long A) 2865 -- Runtime Function: short accum __satfractunstiha (unsigned long long 2866 A) 2867 -- Runtime Function: accum __satfractunstisa (unsigned long long A) 2868 -- Runtime Function: long accum __satfractunstida (unsigned long long 2869 A) 2870 -- Runtime Function: long long accum __satfractunstita (unsigned long 2871 long A) 2872 -- Runtime Function: unsigned short fract __satfractunstiuqq (unsigned 2873 long long A) 2874 -- Runtime Function: unsigned fract __satfractunstiuhq (unsigned long 2875 long A) 2876 -- Runtime Function: unsigned long fract __satfractunstiusq (unsigned 2877 long long A) 2878 -- Runtime Function: unsigned long long fract __satfractunstiudq 2879 (unsigned long long A) 2880 -- Runtime Function: unsigned short accum __satfractunstiuha (unsigned 2881 long long A) 2882 -- Runtime Function: unsigned accum __satfractunstiusa (unsigned long 2883 long A) 2884 -- Runtime Function: unsigned long accum __satfractunstiuda (unsigned 2885 long long A) 2886 -- Runtime Function: unsigned long long accum __satfractunstiuta 2887 (unsigned long long A) 2888 These functions convert from unsigned non-fractionals to 2889 fractionals, with saturation. 2890 2891 2892File: gccint.info, Node: Exception handling routines, Next: Miscellaneous routines, Prev: Fixed-point fractional library routines, Up: Libgcc 2893 28944.5 Language-independent routines for exception handling 2895======================================================== 2896 2897document me! 2898 2899 _Unwind_DeleteException 2900 _Unwind_Find_FDE 2901 _Unwind_ForcedUnwind 2902 _Unwind_GetGR 2903 _Unwind_GetIP 2904 _Unwind_GetLanguageSpecificData 2905 _Unwind_GetRegionStart 2906 _Unwind_GetTextRelBase 2907 _Unwind_GetDataRelBase 2908 _Unwind_RaiseException 2909 _Unwind_Resume 2910 _Unwind_SetGR 2911 _Unwind_SetIP 2912 _Unwind_FindEnclosingFunction 2913 _Unwind_SjLj_Register 2914 _Unwind_SjLj_Unregister 2915 _Unwind_SjLj_RaiseException 2916 _Unwind_SjLj_ForcedUnwind 2917 _Unwind_SjLj_Resume 2918 __deregister_frame 2919 __deregister_frame_info 2920 __deregister_frame_info_bases 2921 __register_frame 2922 __register_frame_info 2923 __register_frame_info_bases 2924 __register_frame_info_table 2925 __register_frame_info_table_bases 2926 __register_frame_table 2927 2928 2929File: gccint.info, Node: Miscellaneous routines, Prev: Exception handling routines, Up: Libgcc 2930 29314.6 Miscellaneous runtime library routines 2932========================================== 2933 29344.6.1 Cache control functions 2935----------------------------- 2936 2937 -- Runtime Function: void __clear_cache (char *BEG, char *END) 2938 This function clears the instruction cache between BEG and END. 2939 29404.6.2 Split stack functions and variables 2941----------------------------------------- 2942 2943 -- Runtime Function: void * __splitstack_find (void *SEGMENT_ARG, void 2944 *SP, size_t LEN, void **NEXT_SEGMENT, void **NEXT_SP, void 2945 **INITIAL_SP) 2946 When using `-fsplit-stack', this call may be used to iterate over 2947 the stack segments. It may be called like this: 2948 void *next_segment = NULL; 2949 void *next_sp = NULL; 2950 void *initial_sp = NULL; 2951 void *stack; 2952 size_t stack_size; 2953 while ((stack = __splitstack_find (next_segment, next_sp, 2954 &stack_size, &next_segment, 2955 &next_sp, &initial_sp)) 2956 != NULL) 2957 { 2958 /* Stack segment starts at stack and is 2959 stack_size bytes long. */ 2960 } 2961 2962 There is no way to iterate over the stack segments of a different 2963 thread. However, what is permitted is for one thread to call this 2964 with the SEGMENT_ARG and SP arguments NULL, to pass NEXT_SEGMENT, 2965 NEXT_SP, and INITIAL_SP to a different thread, and then to suspend 2966 one way or another. A different thread may run the subsequent 2967 `__splitstack_find' iterations. Of course, this will only work if 2968 the first thread is suspended while the second thread is calling 2969 `__splitstack_find'. If not, the second thread could be looking 2970 at the stack while it is changing, and anything could happen. 2971 2972 -- Variable: __morestack_segments 2973 -- Variable: __morestack_current_segment 2974 -- Variable: __morestack_initial_sp 2975 Internal variables used by the `-fsplit-stack' implementation. 2976 2977 2978File: gccint.info, Node: Languages, Next: Source Tree, Prev: Libgcc, Up: Top 2979 29805 Language Front Ends in GCC 2981**************************** 2982 2983The interface to front ends for languages in GCC, and in particular the 2984`tree' structure (*note GENERIC::), was initially designed for C, and 2985many aspects of it are still somewhat biased towards C and C-like 2986languages. It is, however, reasonably well suited to other procedural 2987languages, and front ends for many such languages have been written for 2988GCC. 2989 2990 Writing a compiler as a front end for GCC, rather than compiling 2991directly to assembler or generating C code which is then compiled by 2992GCC, has several advantages: 2993 2994 * GCC front ends benefit from the support for many different target 2995 machines already present in GCC. 2996 2997 * GCC front ends benefit from all the optimizations in GCC. Some of 2998 these, such as alias analysis, may work better when GCC is 2999 compiling directly from source code then when it is compiling from 3000 generated C code. 3001 3002 * Better debugging information is generated when compiling directly 3003 from source code than when going via intermediate generated C code. 3004 3005 Because of the advantages of writing a compiler as a GCC front end, 3006GCC front ends have also been created for languages very different from 3007those for which GCC was designed, such as the declarative 3008logic/functional language Mercury. For these reasons, it may also be 3009useful to implement compilers created for specialized purposes (for 3010example, as part of a research project) as GCC front ends. 3011 3012 3013File: gccint.info, Node: Source Tree, Next: Testsuites, Prev: Languages, Up: Top 3014 30156 Source Tree Structure and Build System 3016**************************************** 3017 3018This chapter describes the structure of the GCC source tree, and how 3019GCC is built. The user documentation for building and installing GCC 3020is in a separate manual (`http://gcc.gnu.org/install/'), with which it 3021is presumed that you are familiar. 3022 3023* Menu: 3024 3025* Configure Terms:: Configuration terminology and history. 3026* Top Level:: The top level source directory. 3027* gcc Directory:: The `gcc' subdirectory. 3028 3029 3030File: gccint.info, Node: Configure Terms, Next: Top Level, Up: Source Tree 3031 30326.1 Configure Terms and History 3033=============================== 3034 3035The configure and build process has a long and colorful history, and can 3036be confusing to anyone who doesn't know why things are the way they are. 3037While there are other documents which describe the configuration process 3038in detail, here are a few things that everyone working on GCC should 3039know. 3040 3041 There are three system names that the build knows about: the machine 3042you are building on ("build"), the machine that you are building for 3043("host"), and the machine that GCC will produce code for ("target"). 3044When you configure GCC, you specify these with `--build=', `--host=', 3045and `--target='. 3046 3047 Specifying the host without specifying the build should be avoided, as 3048`configure' may (and once did) assume that the host you specify is also 3049the build, which may not be true. 3050 3051 If build, host, and target are all the same, this is called a 3052"native". If build and host are the same but target is different, this 3053is called a "cross". If build, host, and target are all different this 3054is called a "canadian" (for obscure reasons dealing with Canada's 3055political party and the background of the person working on the build 3056at that time). If host and target are the same, but build is 3057different, you are using a cross-compiler to build a native for a 3058different system. Some people call this a "host-x-host", "crossed 3059native", or "cross-built native". If build and target are the same, 3060but host is different, you are using a cross compiler to build a cross 3061compiler that produces code for the machine you're building on. This 3062is rare, so there is no common way of describing it. There is a 3063proposal to call this a "crossback". 3064 3065 If build and host are the same, the GCC you are building will also be 3066used to build the target libraries (like `libstdc++'). If build and 3067host are different, you must have already built and installed a cross 3068compiler that will be used to build the target libraries (if you 3069configured with `--target=foo-bar', this compiler will be called 3070`foo-bar-gcc'). 3071 3072 In the case of target libraries, the machine you're building for is the 3073machine you specified with `--target'. So, build is the machine you're 3074building on (no change there), host is the machine you're building for 3075(the target libraries are built for the target, so host is the target 3076you specified), and target doesn't apply (because you're not building a 3077compiler, you're building libraries). The configure/make process will 3078adjust these variables as needed. It also sets `$with_cross_host' to 3079the original `--host' value in case you need it. 3080 3081 The `libiberty' support library is built up to three times: once for 3082the host, once for the target (even if they are the same), and once for 3083the build if build and host are different. This allows it to be used 3084by all programs which are generated in the course of the build process. 3085 3086 3087File: gccint.info, Node: Top Level, Next: gcc Directory, Prev: Configure Terms, Up: Source Tree 3088 30896.2 Top Level Source Directory 3090============================== 3091 3092The top level source directory in a GCC distribution contains several 3093files and directories that are shared with other software distributions 3094such as that of GNU Binutils. It also contains several subdirectories 3095that contain parts of GCC and its runtime libraries: 3096 3097`boehm-gc' 3098 The Boehm conservative garbage collector, used as part of the Java 3099 runtime library. 3100 3101`config' 3102 Autoconf macros and Makefile fragments used throughout the tree. 3103 3104`contrib' 3105 Contributed scripts that may be found useful in conjunction with 3106 GCC. One of these, `contrib/texi2pod.pl', is used to generate man 3107 pages from Texinfo manuals as part of the GCC build process. 3108 3109`fixincludes' 3110 The support for fixing system headers to work with GCC. See 3111 `fixincludes/README' for more information. The headers fixed by 3112 this mechanism are installed in `LIBSUBDIR/include-fixed'. Along 3113 with those headers, `README-fixinc' is also installed, as 3114 `LIBSUBDIR/include-fixed/README'. 3115 3116`gcc' 3117 The main sources of GCC itself (except for runtime libraries), 3118 including optimizers, support for different target architectures, 3119 language front ends, and testsuites. *Note The `gcc' 3120 Subdirectory: gcc Directory, for details. 3121 3122`gnattools' 3123 Support tools for GNAT. 3124 3125`include' 3126 Headers for the `libiberty' library. 3127 3128`intl' 3129 GNU `libintl', from GNU `gettext', for systems which do not 3130 include it in `libc'. 3131 3132`libada' 3133 The Ada runtime library. 3134 3135`libatomic' 3136 The runtime support library for atomic operations (e.g. for 3137 `__sync' and `__atomic'). 3138 3139`libcpp' 3140 The C preprocessor library. 3141 3142`libdecnumber' 3143 The Decimal Float support library. 3144 3145`libffi' 3146 The `libffi' library, used as part of the Java runtime library. 3147 3148`libgcc' 3149 The GCC runtime library. 3150 3151`libgfortran' 3152 The Fortran runtime library. 3153 3154`libgo' 3155 The Go runtime library. The bulk of this library is mirrored from 3156 the master Go repository (http://code.google.com/p/go/). 3157 3158`libgomp' 3159 The GNU Offloading and Multi Processing Runtime Library. 3160 3161`libiberty' 3162 The `libiberty' library, used for portability and for some 3163 generally useful data structures and algorithms. *Note 3164 Introduction: (libiberty)Top, for more information about this 3165 library. 3166 3167`libitm' 3168 The runtime support library for transactional memory. 3169 3170`libjava' 3171 The Java runtime library. 3172 3173`libobjc' 3174 The Objective-C and Objective-C++ runtime library. 3175 3176`libquadmath' 3177 The runtime support library for quad-precision math operations. 3178 3179`libssp' 3180 The Stack protector runtime library. 3181 3182`libstdc++-v3' 3183 The C++ runtime library. 3184 3185`lto-plugin' 3186 Plugin used by the linker if link-time optimizations are enabled. 3187 3188`maintainer-scripts' 3189 Scripts used by the `gccadmin' account on `gcc.gnu.org'. 3190 3191`zlib' 3192 The `zlib' compression library, used by the Java front end, as 3193 part of the Java runtime library, and for compressing and 3194 uncompressing GCC's intermediate language in LTO object files. 3195 3196 The build system in the top level directory, including how recursion 3197into subdirectories works and how building runtime libraries for 3198multilibs is handled, is documented in a separate manual, included with 3199GNU Binutils. *Note GNU configure and build system: (configure)Top, 3200for details. 3201 3202 3203File: gccint.info, Node: gcc Directory, Prev: Top Level, Up: Source Tree 3204 32056.3 The `gcc' Subdirectory 3206========================== 3207 3208The `gcc' directory contains many files that are part of the C sources 3209of GCC, other files used as part of the configuration and build 3210process, and subdirectories including documentation and a testsuite. 3211The files that are sources of GCC are documented in a separate chapter. 3212*Note Passes and Files of the Compiler: Passes. 3213 3214* Menu: 3215 3216* Subdirectories:: Subdirectories of `gcc'. 3217* Configuration:: The configuration process, and the files it uses. 3218* Build:: The build system in the `gcc' directory. 3219* Makefile:: Targets in `gcc/Makefile'. 3220* Library Files:: Library source files and headers under `gcc/'. 3221* Headers:: Headers installed by GCC. 3222* Documentation:: Building documentation in GCC. 3223* Front End:: Anatomy of a language front end. 3224* Back End:: Anatomy of a target back end. 3225 3226 3227File: gccint.info, Node: Subdirectories, Next: Configuration, Up: gcc Directory 3228 32296.3.1 Subdirectories of `gcc' 3230----------------------------- 3231 3232The `gcc' directory contains the following subdirectories: 3233 3234`LANGUAGE' 3235 Subdirectories for various languages. Directories containing a 3236 file `config-lang.in' are language subdirectories. The contents of 3237 the subdirectories `c' (for C), `cp' (for C++), `objc' (for 3238 Objective-C), `objcp' (for Objective-C++), and `lto' (for LTO) are 3239 documented in this manual (*note Passes and Files of the Compiler: 3240 Passes.); those for other languages are not. *Note Anatomy of a 3241 Language Front End: Front End, for details of the files in these 3242 directories. 3243 3244`common' 3245 Source files shared between the compiler drivers (such as `gcc') 3246 and the compilers proper (such as `cc1'). If an architecture 3247 defines target hooks shared between those places, it also has a 3248 subdirectory in `common/config'. *Note Target Structure::. 3249 3250`config' 3251 Configuration files for supported architectures and operating 3252 systems. *Note Anatomy of a Target Back End: Back End, for 3253 details of the files in this directory. 3254 3255`doc' 3256 Texinfo documentation for GCC, together with automatically 3257 generated man pages and support for converting the installation 3258 manual to HTML. *Note Documentation::. 3259 3260`ginclude' 3261 System headers installed by GCC, mainly those required by the C 3262 standard of freestanding implementations. *Note Headers Installed 3263 by GCC: Headers, for details of when these and other headers are 3264 installed. 3265 3266`po' 3267 Message catalogs with translations of messages produced by GCC into 3268 various languages, `LANGUAGE.po'. This directory also contains 3269 `gcc.pot', the template for these message catalogues, `exgettext', 3270 a wrapper around `gettext' to extract the messages from the GCC 3271 sources and create `gcc.pot', which is run by `make gcc.pot', and 3272 `EXCLUDES', a list of files from which messages should not be 3273 extracted. 3274 3275`testsuite' 3276 The GCC testsuites (except for those for runtime libraries). 3277 *Note Testsuites::. 3278 3279 3280File: gccint.info, Node: Configuration, Next: Build, Prev: Subdirectories, Up: gcc Directory 3281 32826.3.2 Configuration in the `gcc' Directory 3283------------------------------------------ 3284 3285The `gcc' directory is configured with an Autoconf-generated script 3286`configure'. The `configure' script is generated from `configure.ac' 3287and `aclocal.m4'. From the files `configure.ac' and `acconfig.h', 3288Autoheader generates the file `config.in'. The file `cstamp-h.in' is 3289used as a timestamp. 3290 3291* Menu: 3292 3293* Config Fragments:: Scripts used by `configure'. 3294* System Config:: The `config.build', `config.host', and 3295 `config.gcc' files. 3296* Configuration Files:: Files created by running `configure'. 3297 3298 3299File: gccint.info, Node: Config Fragments, Next: System Config, Up: Configuration 3300 33016.3.2.1 Scripts Used by `configure' 3302................................... 3303 3304`configure' uses some other scripts to help in its work: 3305 3306 * The standard GNU `config.sub' and `config.guess' files, kept in 3307 the top level directory, are used. 3308 3309 * The file `config.gcc' is used to handle configuration specific to 3310 the particular target machine. The file `config.build' is used to 3311 handle configuration specific to the particular build machine. 3312 The file `config.host' is used to handle configuration specific to 3313 the particular host machine. (In general, these should only be 3314 used for features that cannot reasonably be tested in Autoconf 3315 feature tests.) *Note The `config.build'; `config.host'; and 3316 `config.gcc' Files: System Config, for details of the contents of 3317 these files. 3318 3319 * Each language subdirectory has a file `LANGUAGE/config-lang.in' 3320 that is used for front-end-specific configuration. *Note The 3321 Front End `config-lang.in' File: Front End Config, for details of 3322 this file. 3323 3324 * A helper script `configure.frag' is used as part of creating the 3325 output of `configure'. 3326 3327 3328File: gccint.info, Node: System Config, Next: Configuration Files, Prev: Config Fragments, Up: Configuration 3329 33306.3.2.2 The `config.build'; `config.host'; and `config.gcc' Files 3331................................................................. 3332 3333The `config.build' file contains specific rules for particular systems 3334which GCC is built on. This should be used as rarely as possible, as 3335the behavior of the build system can always be detected by autoconf. 3336 3337 The `config.host' file contains specific rules for particular systems 3338which GCC will run on. This is rarely needed. 3339 3340 The `config.gcc' file contains specific rules for particular systems 3341which GCC will generate code for. This is usually needed. 3342 3343 Each file has a list of the shell variables it sets, with 3344descriptions, at the top of the file. 3345 3346 FIXME: document the contents of these files, and what variables should 3347be set to control build, host and target configuration. 3348 3349 3350File: gccint.info, Node: Configuration Files, Prev: System Config, Up: Configuration 3351 33526.3.2.3 Files Created by `configure' 3353.................................... 3354 3355Here we spell out what files will be set up by `configure' in the `gcc' 3356directory. Some other files are created as temporary files in the 3357configuration process, and are not used in the subsequent build; these 3358are not documented. 3359 3360 * `Makefile' is constructed from `Makefile.in', together with the 3361 host and target fragments (*note Makefile Fragments: Fragments.) 3362 `t-TARGET' and `x-HOST' from `config', if any, and language 3363 Makefile fragments `LANGUAGE/Make-lang.in'. 3364 3365 * `auto-host.h' contains information about the host machine 3366 determined by `configure'. If the host machine is different from 3367 the build machine, then `auto-build.h' is also created, containing 3368 such information about the build machine. 3369 3370 * `config.status' is a script that may be run to recreate the 3371 current configuration. 3372 3373 * `configargs.h' is a header containing details of the arguments 3374 passed to `configure' to configure GCC, and of the thread model 3375 used. 3376 3377 * `cstamp-h' is used as a timestamp. 3378 3379 * If a language `config-lang.in' file (*note The Front End 3380 `config-lang.in' File: Front End Config.) sets `outputs', then the 3381 files listed in `outputs' there are also generated. 3382 3383 The following configuration headers are created from the Makefile, 3384using `mkconfig.sh', rather than directly by `configure'. `config.h', 3385`bconfig.h' and `tconfig.h' all contain the `xm-MACHINE.h' header, if 3386any, appropriate to the host, build and target machines respectively, 3387the configuration headers for the target, and some definitions; for the 3388host and build machines, these include the autoconfigured headers 3389generated by `configure'. The other configuration headers are 3390determined by `config.gcc'. They also contain the typedefs for `rtx', 3391`rtvec' and `tree'. 3392 3393 * `config.h', for use in programs that run on the host machine. 3394 3395 * `bconfig.h', for use in programs that run on the build machine. 3396 3397 * `tconfig.h', for use in programs and libraries for the target 3398 machine. 3399 3400 * `tm_p.h', which includes the header `MACHINE-protos.h' that 3401 contains prototypes for functions in the target `MACHINE.c' file. 3402 The header `MACHINE-protos.h' can include prototypes of functions 3403 that use rtl and tree data structures inside appropriate `#ifdef 3404 RTX_CODE' and `#ifdef TREE_CODE' conditional code segements. The 3405 `MACHINE-protos.h' is included after the `rtl.h' and/or `tree.h' 3406 would have been included. The `tm_p.h' also includes the header 3407 `tm-preds.h' which is generated by `genpreds' program during the 3408 build to define the declarations and inline functions for the 3409 predicate functions. 3410 3411 3412File: gccint.info, Node: Build, Next: Makefile, Prev: Configuration, Up: gcc Directory 3413 34146.3.3 Build System in the `gcc' Directory 3415----------------------------------------- 3416 3417FIXME: describe the build system, including what is built in what 3418stages. Also list the various source files that are used in the build 3419process but aren't source files of GCC itself and so aren't documented 3420below (*note Passes::). 3421 3422 3423File: gccint.info, Node: Makefile, Next: Library Files, Prev: Build, Up: gcc Directory 3424 34256.3.4 Makefile Targets 3426---------------------- 3427 3428These targets are available from the `gcc' directory: 3429 3430`all' 3431 This is the default target. Depending on what your 3432 build/host/target configuration is, it coordinates all the things 3433 that need to be built. 3434 3435`doc' 3436 Produce info-formatted documentation and man pages. Essentially it 3437 calls `make man' and `make info'. 3438 3439`dvi' 3440 Produce DVI-formatted documentation. 3441 3442`pdf' 3443 Produce PDF-formatted documentation. 3444 3445`html' 3446 Produce HTML-formatted documentation. 3447 3448`man' 3449 Generate man pages. 3450 3451`info' 3452 Generate info-formatted pages. 3453 3454`mostlyclean' 3455 Delete the files made while building the compiler. 3456 3457`clean' 3458 That, and all the other files built by `make all'. 3459 3460`distclean' 3461 That, and all the files created by `configure'. 3462 3463`maintainer-clean' 3464 Distclean plus any file that can be generated from other files. 3465 Note that additional tools may be required beyond what is normally 3466 needed to build GCC. 3467 3468`srcextra' 3469 Generates files in the source directory that are not 3470 version-controlled but should go into a release tarball. 3471 3472`srcinfo' 3473`srcman' 3474 Copies the info-formatted and manpage documentation into the source 3475 directory usually for the purpose of generating a release tarball. 3476 3477`install' 3478 Installs GCC. 3479 3480`uninstall' 3481 Deletes installed files, though this is not supported. 3482 3483`check' 3484 Run the testsuite. This creates a `testsuite' subdirectory that 3485 has various `.sum' and `.log' files containing the results of the 3486 testing. You can run subsets with, for example, `make check-gcc'. 3487 You can specify specific tests by setting `RUNTESTFLAGS' to be the 3488 name of the `.exp' file, optionally followed by (for some tests) 3489 an equals and a file wildcard, like: 3490 3491 make check-gcc RUNTESTFLAGS="execute.exp=19980413-*" 3492 3493 Note that running the testsuite may require additional tools be 3494 installed, such as Tcl or DejaGnu. 3495 3496 The toplevel tree from which you start GCC compilation is not the GCC 3497directory, but rather a complex Makefile that coordinates the various 3498steps of the build, including bootstrapping the compiler and using the 3499new compiler to build target libraries. 3500 3501 When GCC is configured for a native configuration, the default action 3502for `make' is to do a full three-stage bootstrap. This means that GCC 3503is built three times--once with the native compiler, once with the 3504native-built compiler it just built, and once with the compiler it 3505built the second time. In theory, the last two should produce the same 3506results, which `make compare' can check. Each stage is configured 3507separately and compiled into a separate directory, to minimize problems 3508due to ABI incompatibilities between the native compiler and GCC. 3509 3510 If you do a change, rebuilding will also start from the first stage 3511and "bubble" up the change through the three stages. Each stage is 3512taken from its build directory (if it had been built previously), 3513rebuilt, and copied to its subdirectory. This will allow you to, for 3514example, continue a bootstrap after fixing a bug which causes the 3515stage2 build to crash. It does not provide as good coverage of the 3516compiler as bootstrapping from scratch, but it ensures that the new 3517code is syntactically correct (e.g., that you did not use GCC extensions 3518by mistake), and avoids spurious bootstrap comparison failures(1). 3519 3520 Other targets available from the top level include: 3521 3522`bootstrap-lean' 3523 Like `bootstrap', except that the various stages are removed once 3524 they're no longer needed. This saves disk space. 3525 3526`bootstrap2' 3527`bootstrap2-lean' 3528 Performs only the first two stages of bootstrap. Unlike a 3529 three-stage bootstrap, this does not perform a comparison to test 3530 that the compiler is running properly. Note that the disk space 3531 required by a "lean" bootstrap is approximately independent of the 3532 number of stages. 3533 3534`stageN-bubble (N = 1...4, profile, feedback)' 3535 Rebuild all the stages up to N, with the appropriate flags, 3536 "bubbling" the changes as described above. 3537 3538`all-stageN (N = 1...4, profile, feedback)' 3539 Assuming that stage N has already been built, rebuild it with the 3540 appropriate flags. This is rarely needed. 3541 3542`cleanstrap' 3543 Remove everything (`make clean') and rebuilds (`make bootstrap'). 3544 3545`compare' 3546 Compares the results of stages 2 and 3. This ensures that the 3547 compiler is running properly, since it should produce the same 3548 object files regardless of how it itself was compiled. 3549 3550`profiledbootstrap' 3551 Builds a compiler with profiling feedback information. In this 3552 case, the second and third stages are named `profile' and 3553 `feedback', respectively. For more information, see *note 3554 Building with profile feedback: (gccinstall)Building. 3555 3556`restrap' 3557 Restart a bootstrap, so that everything that was not built with 3558 the system compiler is rebuilt. 3559 3560`stageN-start (N = 1...4, profile, feedback)' 3561 For each package that is bootstrapped, rename directories so that, 3562 for example, `gcc' points to the stageN GCC, compiled with the 3563 stageN-1 GCC(2). 3564 3565 You will invoke this target if you need to test or debug the 3566 stageN GCC. If you only need to execute GCC (but you need not run 3567 `make' either to rebuild it or to run test suites), you should be 3568 able to work directly in the `stageN-gcc' directory. This makes 3569 it easier to debug multiple stages in parallel. 3570 3571`stage' 3572 For each package that is bootstrapped, relocate its build directory 3573 to indicate its stage. For example, if the `gcc' directory points 3574 to the stage2 GCC, after invoking this target it will be renamed 3575 to `stage2-gcc'. 3576 3577 3578 If you wish to use non-default GCC flags when compiling the stage2 and 3579stage3 compilers, set `BOOT_CFLAGS' on the command line when doing 3580`make'. 3581 3582 Usually, the first stage only builds the languages that the compiler 3583is written in: typically, C and maybe Ada. If you are debugging a 3584miscompilation of a different stage2 front-end (for example, of the 3585Fortran front-end), you may want to have front-ends for other languages 3586in the first stage as well. To do so, set `STAGE1_LANGUAGES' on the 3587command line when doing `make'. 3588 3589 For example, in the aforementioned scenario of debugging a Fortran 3590front-end miscompilation caused by the stage1 compiler, you may need a 3591command like 3592 3593 make stage2-bubble STAGE1_LANGUAGES=c,fortran 3594 3595 Alternatively, you can use per-language targets to build and test 3596languages that are not enabled by default in stage1. For example, 3597`make f951' will build a Fortran compiler even in the stage1 build 3598directory. 3599 3600 ---------- Footnotes ---------- 3601 3602 (1) Except if the compiler was buggy and miscompiled some of the files 3603that were not modified. In this case, it's best to use `make restrap'. 3604 3605 (2) Customarily, the system compiler is also termed the `stage0' GCC. 3606 3607 3608File: gccint.info, Node: Library Files, Next: Headers, Prev: Makefile, Up: gcc Directory 3609 36106.3.5 Library Source Files and Headers under the `gcc' Directory 3611---------------------------------------------------------------- 3612 3613FIXME: list here, with explanation, all the C source files and headers 3614under the `gcc' directory that aren't built into the GCC executable but 3615rather are part of runtime libraries and object files, such as 3616`crtstuff.c' and `unwind-dw2.c'. *Note Headers Installed by GCC: 3617Headers, for more information about the `ginclude' directory. 3618 3619 3620File: gccint.info, Node: Headers, Next: Documentation, Prev: Library Files, Up: gcc Directory 3621 36226.3.6 Headers Installed by GCC 3623------------------------------ 3624 3625In general, GCC expects the system C library to provide most of the 3626headers to be used with it. However, GCC will fix those headers if 3627necessary to make them work with GCC, and will install some headers 3628required of freestanding implementations. These headers are installed 3629in `LIBSUBDIR/include'. Headers for non-C runtime libraries are also 3630installed by GCC; these are not documented here. (FIXME: document them 3631somewhere.) 3632 3633 Several of the headers GCC installs are in the `ginclude' directory. 3634These headers, `iso646.h', `stdarg.h', `stdbool.h', and `stddef.h', are 3635installed in `LIBSUBDIR/include', unless the target Makefile fragment 3636(*note Target Fragment::) overrides this by setting `USER_H'. 3637 3638 In addition to these headers and those generated by fixing system 3639headers to work with GCC, some other headers may also be installed in 3640`LIBSUBDIR/include'. `config.gcc' may set `extra_headers'; this 3641specifies additional headers under `config' to be installed on some 3642systems. 3643 3644 GCC installs its own version of `<float.h>', from `ginclude/float.h'. 3645This is done to cope with command-line options that change the 3646representation of floating point numbers. 3647 3648 GCC also installs its own version of `<limits.h>'; this is generated 3649from `glimits.h', together with `limitx.h' and `limity.h' if the system 3650also has its own version of `<limits.h>'. (GCC provides its own header 3651because it is required of ISO C freestanding implementations, but needs 3652to include the system header from its own header as well because other 3653standards such as POSIX specify additional values to be defined in 3654`<limits.h>'.) The system's `<limits.h>' header is used via 3655`LIBSUBDIR/include/syslimits.h', which is copied from `gsyslimits.h' if 3656it does not need fixing to work with GCC; if it needs fixing, 3657`syslimits.h' is the fixed copy. 3658 3659 GCC can also install `<tgmath.h>'. It will do this when `config.gcc' 3660sets `use_gcc_tgmath' to `yes'. 3661 3662 3663File: gccint.info, Node: Documentation, Next: Front End, Prev: Headers, Up: gcc Directory 3664 36656.3.7 Building Documentation 3666---------------------------- 3667 3668The main GCC documentation is in the form of manuals in Texinfo format. 3669These are installed in Info format; DVI versions may be generated by 3670`make dvi', PDF versions by `make pdf', and HTML versions by `make 3671html'. In addition, some man pages are generated from the Texinfo 3672manuals, there are some other text files with miscellaneous 3673documentation, and runtime libraries have their own documentation 3674outside the `gcc' directory. FIXME: document the documentation for 3675runtime libraries somewhere. 3676 3677* Menu: 3678 3679* Texinfo Manuals:: GCC manuals in Texinfo format. 3680* Man Page Generation:: Generating man pages from Texinfo manuals. 3681* Miscellaneous Docs:: Miscellaneous text files with documentation. 3682 3683 3684File: gccint.info, Node: Texinfo Manuals, Next: Man Page Generation, Up: Documentation 3685 36866.3.7.1 Texinfo Manuals 3687....................... 3688 3689The manuals for GCC as a whole, and the C and C++ front ends, are in 3690files `doc/*.texi'. Other front ends have their own manuals in files 3691`LANGUAGE/*.texi'. Common files `doc/include/*.texi' are provided 3692which may be included in multiple manuals; the following files are in 3693`doc/include': 3694 3695`fdl.texi' 3696 The GNU Free Documentation License. 3697 3698`funding.texi' 3699 The section "Funding Free Software". 3700 3701`gcc-common.texi' 3702 Common definitions for manuals. 3703 3704`gpl_v3.texi' 3705 The GNU General Public License. 3706 3707`texinfo.tex' 3708 A copy of `texinfo.tex' known to work with the GCC manuals. 3709 3710 DVI-formatted manuals are generated by `make dvi', which uses 3711`texi2dvi' (via the Makefile macro `$(TEXI2DVI)'). PDF-formatted 3712manuals are generated by `make pdf', which uses `texi2pdf' (via the 3713Makefile macro `$(TEXI2PDF)'). HTML formatted manuals are generated by 3714`make html'. Info manuals are generated by `make info' (which is run 3715as part of a bootstrap); this generates the manuals in the source 3716directory, using `makeinfo' via the Makefile macro `$(MAKEINFO)', and 3717they are included in release distributions. 3718 3719 Manuals are also provided on the GCC web site, in both HTML and 3720PostScript forms. This is done via the script 3721`maintainer-scripts/update_web_docs_svn'. Each manual to be provided 3722online must be listed in the definition of `MANUALS' in that file; a 3723file `NAME.texi' must only appear once in the source tree, and the 3724output manual must have the same name as the source file. (However, 3725other Texinfo files, included in manuals but not themselves the root 3726files of manuals, may have names that appear more than once in the 3727source tree.) The manual file `NAME.texi' should only include other 3728files in its own directory or in `doc/include'. HTML manuals will be 3729generated by `makeinfo --html', PostScript manuals by `texi2dvi' and 3730`dvips', and PDF manuals by `texi2pdf'. All Texinfo files that are 3731parts of manuals must be version-controlled, even if they are generated 3732files, for the generation of online manuals to work. 3733 3734 The installation manual, `doc/install.texi', is also provided on the 3735GCC web site. The HTML version is generated by the script 3736`doc/install.texi2html'. 3737 3738 3739File: gccint.info, Node: Man Page Generation, Next: Miscellaneous Docs, Prev: Texinfo Manuals, Up: Documentation 3740 37416.3.7.2 Man Page Generation 3742........................... 3743 3744Because of user demand, in addition to full Texinfo manuals, man pages 3745are provided which contain extracts from those manuals. These man 3746pages are generated from the Texinfo manuals using 3747`contrib/texi2pod.pl' and `pod2man'. (The man page for `g++', 3748`cp/g++.1', just contains a `.so' reference to `gcc.1', but all the 3749other man pages are generated from Texinfo manuals.) 3750 3751 Because many systems may not have the necessary tools installed to 3752generate the man pages, they are only generated if the `configure' 3753script detects that recent enough tools are installed, and the 3754Makefiles allow generating man pages to fail without aborting the 3755build. Man pages are also included in release distributions. They are 3756generated in the source directory. 3757 3758 Magic comments in Texinfo files starting `@c man' control what parts 3759of a Texinfo file go into a man page. Only a subset of Texinfo is 3760supported by `texi2pod.pl', and it may be necessary to add support for 3761more Texinfo features to this script when generating new man pages. To 3762improve the man page output, some special Texinfo macros are provided 3763in `doc/include/gcc-common.texi' which `texi2pod.pl' understands: 3764 3765`@gcctabopt' 3766 Use in the form `@table @gcctabopt' for tables of options, where 3767 for printed output the effect of `@code' is better than that of 3768 `@option' but for man page output a different effect is wanted. 3769 3770`@gccoptlist' 3771 Use for summary lists of options in manuals. 3772 3773`@gol' 3774 Use at the end of each line inside `@gccoptlist'. This is 3775 necessary to avoid problems with differences in how the 3776 `@gccoptlist' macro is handled by different Texinfo formatters. 3777 3778 FIXME: describe the `texi2pod.pl' input language and magic comments in 3779more detail. 3780 3781 3782File: gccint.info, Node: Miscellaneous Docs, Prev: Man Page Generation, Up: Documentation 3783 37846.3.7.3 Miscellaneous Documentation 3785................................... 3786 3787In addition to the formal documentation that is installed by GCC, there 3788are several other text files in the `gcc' subdirectory with 3789miscellaneous documentation: 3790 3791`ABOUT-GCC-NLS' 3792 Notes on GCC's Native Language Support. FIXME: this should be 3793 part of this manual rather than a separate file. 3794 3795`ABOUT-NLS' 3796 Notes on the Free Translation Project. 3797 3798`COPYING' 3799`COPYING3' 3800 The GNU General Public License, Versions 2 and 3. 3801 3802`COPYING.LIB' 3803`COPYING3.LIB' 3804 The GNU Lesser General Public License, Versions 2.1 and 3. 3805 3806`*ChangeLog*' 3807`*/ChangeLog*' 3808 Change log files for various parts of GCC. 3809 3810`LANGUAGES' 3811 Details of a few changes to the GCC front-end interface. FIXME: 3812 the information in this file should be part of general 3813 documentation of the front-end interface in this manual. 3814 3815`ONEWS' 3816 Information about new features in old versions of GCC. (For recent 3817 versions, the information is on the GCC web site.) 3818 3819`README.Portability' 3820 Information about portability issues when writing code in GCC. 3821 FIXME: why isn't this part of this manual or of the GCC Coding 3822 Conventions? 3823 3824 FIXME: document such files in subdirectories, at least `config', `c', 3825`cp', `objc', `testsuite'. 3826 3827 3828File: gccint.info, Node: Front End, Next: Back End, Prev: Documentation, Up: gcc Directory 3829 38306.3.8 Anatomy of a Language Front End 3831------------------------------------- 3832 3833A front end for a language in GCC has the following parts: 3834 3835 * A directory `LANGUAGE' under `gcc' containing source files for 3836 that front end. *Note The Front End `LANGUAGE' Directory: Front 3837 End Directory, for details. 3838 3839 * A mention of the language in the list of supported languages in 3840 `gcc/doc/install.texi'. 3841 3842 * A mention of the name under which the language's runtime library is 3843 recognized by `--enable-shared=PACKAGE' in the documentation of 3844 that option in `gcc/doc/install.texi'. 3845 3846 * A mention of any special prerequisites for building the front end 3847 in the documentation of prerequisites in `gcc/doc/install.texi'. 3848 3849 * Details of contributors to that front end in 3850 `gcc/doc/contrib.texi'. If the details are in that front end's 3851 own manual then there should be a link to that manual's list in 3852 `contrib.texi'. 3853 3854 * Information about support for that language in 3855 `gcc/doc/frontends.texi'. 3856 3857 * Information about standards for that language, and the front end's 3858 support for them, in `gcc/doc/standards.texi'. This may be a link 3859 to such information in the front end's own manual. 3860 3861 * Details of source file suffixes for that language and `-x LANG' 3862 options supported, in `gcc/doc/invoke.texi'. 3863 3864 * Entries in `default_compilers' in `gcc.c' for source file suffixes 3865 for that language. 3866 3867 * Preferably testsuites, which may be under `gcc/testsuite' or 3868 runtime library directories. FIXME: document somewhere how to 3869 write testsuite harnesses. 3870 3871 * Probably a runtime library for the language, outside the `gcc' 3872 directory. FIXME: document this further. 3873 3874 * Details of the directories of any runtime libraries in 3875 `gcc/doc/sourcebuild.texi'. 3876 3877 * Check targets in `Makefile.def' for the top-level `Makefile' to 3878 check just the compiler or the compiler and runtime library for the 3879 language. 3880 3881 If the front end is added to the official GCC source repository, the 3882following are also necessary: 3883 3884 * At least one Bugzilla component for bugs in that front end and 3885 runtime libraries. This category needs to be added to the 3886 Bugzilla database. 3887 3888 * Normally, one or more maintainers of that front end listed in 3889 `MAINTAINERS'. 3890 3891 * Mentions on the GCC web site in `index.html' and `frontends.html', 3892 with any relevant links on `readings.html'. (Front ends that are 3893 not an official part of GCC may also be listed on 3894 `frontends.html', with relevant links.) 3895 3896 * A news item on `index.html', and possibly an announcement on the 3897 <gcc-announce@gcc.gnu.org> mailing list. 3898 3899 * The front end's manuals should be mentioned in 3900 `maintainer-scripts/update_web_docs_svn' (*note Texinfo Manuals::) 3901 and the online manuals should be linked to from 3902 `onlinedocs/index.html'. 3903 3904 * Any old releases or CVS repositories of the front end, before its 3905 inclusion in GCC, should be made available on the GCC FTP site 3906 `ftp://gcc.gnu.org/pub/gcc/old-releases/'. 3907 3908 * The release and snapshot script `maintainer-scripts/gcc_release' 3909 should be updated to generate appropriate tarballs for this front 3910 end. 3911 3912 * If this front end includes its own version files that include the 3913 current date, `maintainer-scripts/update_version' should be 3914 updated accordingly. 3915 3916* Menu: 3917 3918* Front End Directory:: The front end `LANGUAGE' directory. 3919* Front End Config:: The front end `config-lang.in' file. 3920* Front End Makefile:: The front end `Make-lang.in' file. 3921 3922 3923File: gccint.info, Node: Front End Directory, Next: Front End Config, Up: Front End 3924 39256.3.8.1 The Front End `LANGUAGE' Directory 3926.......................................... 3927 3928A front end `LANGUAGE' directory contains the source files of that 3929front end (but not of any runtime libraries, which should be outside 3930the `gcc' directory). This includes documentation, and possibly some 3931subsidiary programs built alongside the front end. Certain files are 3932special and other parts of the compiler depend on their names: 3933 3934`config-lang.in' 3935 This file is required in all language subdirectories. *Note The 3936 Front End `config-lang.in' File: Front End Config, for details of 3937 its contents 3938 3939`Make-lang.in' 3940 This file is required in all language subdirectories. *Note The 3941 Front End `Make-lang.in' File: Front End Makefile, for details of 3942 its contents. 3943 3944`lang.opt' 3945 This file registers the set of switches that the front end accepts 3946 on the command line, and their `--help' text. *Note Options::. 3947 3948`lang-specs.h' 3949 This file provides entries for `default_compilers' in `gcc.c' 3950 which override the default of giving an error that a compiler for 3951 that language is not installed. 3952 3953`LANGUAGE-tree.def' 3954 This file, which need not exist, defines any language-specific tree 3955 codes. 3956 3957 3958File: gccint.info, Node: Front End Config, Next: Front End Makefile, Prev: Front End Directory, Up: Front End 3959 39606.3.8.2 The Front End `config-lang.in' File 3961........................................... 3962 3963Each language subdirectory contains a `config-lang.in' file. This file 3964is a shell script that may define some variables describing the 3965language: 3966 3967`language' 3968 This definition must be present, and gives the name of the language 3969 for some purposes such as arguments to `--enable-languages'. 3970 3971`lang_requires' 3972 If defined, this variable lists (space-separated) language front 3973 ends other than C that this front end requires to be enabled (with 3974 the names given being their `language' settings). For example, the 3975 Java front end depends on the C++ front end, so sets 3976 `lang_requires=c++'. 3977 3978`subdir_requires' 3979 If defined, this variable lists (space-separated) front end 3980 directories other than C that this front end requires to be 3981 present. For example, the Objective-C++ front end uses source 3982 files from the C++ and Objective-C front ends, so sets 3983 `subdir_requires="cp objc"'. 3984 3985`target_libs' 3986 If defined, this variable lists (space-separated) targets in the 3987 top level `Makefile' to build the runtime libraries for this 3988 language, such as `target-libobjc'. 3989 3990`lang_dirs' 3991 If defined, this variable lists (space-separated) top level 3992 directories (parallel to `gcc'), apart from the runtime libraries, 3993 that should not be configured if this front end is not built. 3994 3995`build_by_default' 3996 If defined to `no', this language front end is not built unless 3997 enabled in a `--enable-languages' argument. Otherwise, front ends 3998 are built by default, subject to any special logic in 3999 `configure.ac' (as is present to disable the Ada front end if the 4000 Ada compiler is not already installed). 4001 4002`boot_language' 4003 If defined to `yes', this front end is built in stage1 of the 4004 bootstrap. This is only relevant to front ends written in their 4005 own languages. 4006 4007`compilers' 4008 If defined, a space-separated list of compiler executables that 4009 will be run by the driver. The names here will each end with 4010 `\$(exeext)'. 4011 4012`outputs' 4013 If defined, a space-separated list of files that should be 4014 generated by `configure' substituting values in them. This 4015 mechanism can be used to create a file `LANGUAGE/Makefile' from 4016 `LANGUAGE/Makefile.in', but this is deprecated, building 4017 everything from the single `gcc/Makefile' is preferred. 4018 4019`gtfiles' 4020 If defined, a space-separated list of files that should be scanned 4021 by `gengtype.c' to generate the garbage collection tables and 4022 routines for this language. This excludes the files that are 4023 common to all front ends. *Note Type Information::. 4024 4025 4026 4027File: gccint.info, Node: Front End Makefile, Prev: Front End Config, Up: Front End 4028 40296.3.8.3 The Front End `Make-lang.in' File 4030......................................... 4031 4032Each language subdirectory contains a `Make-lang.in' file. It contains 4033targets `LANG.HOOK' (where `LANG' is the setting of `language' in 4034`config-lang.in') for the following values of `HOOK', and any other 4035Makefile rules required to build those targets (which may if necessary 4036use other Makefiles specified in `outputs' in `config-lang.in', 4037although this is deprecated). It also adds any testsuite targets that 4038can use the standard rule in `gcc/Makefile.in' to the variable 4039`lang_checks'. 4040 4041`all.cross' 4042`start.encap' 4043`rest.encap' 4044 FIXME: exactly what goes in each of these targets? 4045 4046`tags' 4047 Build an `etags' `TAGS' file in the language subdirectory in the 4048 source tree. 4049 4050`info' 4051 Build info documentation for the front end, in the build directory. 4052 This target is only called by `make bootstrap' if a suitable 4053 version of `makeinfo' is available, so does not need to check for 4054 this, and should fail if an error occurs. 4055 4056`dvi' 4057 Build DVI documentation for the front end, in the build directory. 4058 This should be done using `$(TEXI2DVI)', with appropriate `-I' 4059 arguments pointing to directories of included files. 4060 4061`pdf' 4062 Build PDF documentation for the front end, in the build directory. 4063 This should be done using `$(TEXI2PDF)', with appropriate `-I' 4064 arguments pointing to directories of included files. 4065 4066`html' 4067 Build HTML documentation for the front end, in the build directory. 4068 4069`man' 4070 Build generated man pages for the front end from Texinfo manuals 4071 (*note Man Page Generation::), in the build directory. This target 4072 is only called if the necessary tools are available, but should 4073 ignore errors so as not to stop the build if errors occur; man 4074 pages are optional and the tools involved may be installed in a 4075 broken way. 4076 4077`install-common' 4078 Install everything that is part of the front end, apart from the 4079 compiler executables listed in `compilers' in `config-lang.in'. 4080 4081`install-info' 4082 Install info documentation for the front end, if it is present in 4083 the source directory. This target should have dependencies on 4084 info files that should be installed. 4085 4086`install-man' 4087 Install man pages for the front end. This target should ignore 4088 errors. 4089 4090`install-plugin' 4091 Install headers needed for plugins. 4092 4093`srcextra' 4094 Copies its dependencies into the source directory. This generally 4095 should be used for generated files such as Bison output files 4096 which are not version-controlled, but should be included in any 4097 release tarballs. This target will be executed during a bootstrap 4098 if `--enable-generated-files-in-srcdir' was specified as a 4099 `configure' option. 4100 4101`srcinfo' 4102`srcman' 4103 Copies its dependencies into the source directory. These targets 4104 will be executed during a bootstrap if 4105 `--enable-generated-files-in-srcdir' was specified as a 4106 `configure' option. 4107 4108`uninstall' 4109 Uninstall files installed by installing the compiler. This is 4110 currently documented not to be supported, so the hook need not do 4111 anything. 4112 4113`mostlyclean' 4114`clean' 4115`distclean' 4116`maintainer-clean' 4117 The language parts of the standard GNU `*clean' targets. *Note 4118 Standard Targets for Users: (standards)Standard Targets, for 4119 details of the standard targets. For GCC, `maintainer-clean' 4120 should delete all generated files in the source directory that are 4121 not version-controlled, but should not delete anything that is. 4122 4123 `Make-lang.in' must also define a variable `LANG_OBJS' to a list of 4124host object files that are used by that language. 4125 4126 4127File: gccint.info, Node: Back End, Prev: Front End, Up: gcc Directory 4128 41296.3.9 Anatomy of a Target Back End 4130---------------------------------- 4131 4132A back end for a target architecture in GCC has the following parts: 4133 4134 * A directory `MACHINE' under `gcc/config', containing a machine 4135 description `MACHINE.md' file (*note Machine Descriptions: Machine 4136 Desc.), header files `MACHINE.h' and `MACHINE-protos.h' and a 4137 source file `MACHINE.c' (*note Target Description Macros and 4138 Functions: Target Macros.), possibly a target Makefile fragment 4139 `t-MACHINE' (*note The Target Makefile Fragment: Target 4140 Fragment.), and maybe some other files. The names of these files 4141 may be changed from the defaults given by explicit specifications 4142 in `config.gcc'. 4143 4144 * If necessary, a file `MACHINE-modes.def' in the `MACHINE' 4145 directory, containing additional machine modes to represent 4146 condition codes. *Note Condition Code::, for further details. 4147 4148 * An optional `MACHINE.opt' file in the `MACHINE' directory, 4149 containing a list of target-specific options. You can also add 4150 other option files using the `extra_options' variable in 4151 `config.gcc'. *Note Options::. 4152 4153 * Entries in `config.gcc' (*note The `config.gcc' File: System 4154 Config.) for the systems with this target architecture. 4155 4156 * Documentation in `gcc/doc/invoke.texi' for any command-line 4157 options supported by this target (*note Run-time Target 4158 Specification: Run-time Target.). This means both entries in the 4159 summary table of options and details of the individual options. 4160 4161 * Documentation in `gcc/doc/extend.texi' for any target-specific 4162 attributes supported (*note Defining target-specific uses of 4163 `__attribute__': Target Attributes.), including where the same 4164 attribute is already supported on some targets, which are 4165 enumerated in the manual. 4166 4167 * Documentation in `gcc/doc/extend.texi' for any target-specific 4168 pragmas supported. 4169 4170 * Documentation in `gcc/doc/extend.texi' of any target-specific 4171 built-in functions supported. 4172 4173 * Documentation in `gcc/doc/extend.texi' of any target-specific 4174 format checking styles supported. 4175 4176 * Documentation in `gcc/doc/md.texi' of any target-specific 4177 constraint letters (*note Constraints for Particular Machines: 4178 Machine Constraints.). 4179 4180 * A note in `gcc/doc/contrib.texi' under the person or people who 4181 contributed the target support. 4182 4183 * Entries in `gcc/doc/install.texi' for all target triplets 4184 supported with this target architecture, giving details of any 4185 special notes about installation for this target, or saying that 4186 there are no special notes if there are none. 4187 4188 * Possibly other support outside the `gcc' directory for runtime 4189 libraries. FIXME: reference docs for this. The `libstdc++' 4190 porting manual needs to be installed as info for this to work, or 4191 to be a chapter of this manual. 4192 4193 If the back end is added to the official GCC source repository, the 4194following are also necessary: 4195 4196 * An entry for the target architecture in `readings.html' on the GCC 4197 web site, with any relevant links. 4198 4199 * Details of the properties of the back end and target architecture 4200 in `backends.html' on the GCC web site. 4201 4202 * A news item about the contribution of support for that target 4203 architecture, in `index.html' on the GCC web site. 4204 4205 * Normally, one or more maintainers of that target listed in 4206 `MAINTAINERS'. Some existing architectures may be unmaintained, 4207 but it would be unusual to add support for a target that does not 4208 have a maintainer when support is added. 4209 4210 * Target triplets covering all `config.gcc' stanzas for the target, 4211 in the list in `contrib/config-list.mk'. 4212 4213 4214File: gccint.info, Node: Testsuites, Next: Options, Prev: Source Tree, Up: Top 4215 42167 Testsuites 4217************ 4218 4219GCC contains several testsuites to help maintain compiler quality. 4220Most of the runtime libraries and language front ends in GCC have 4221testsuites. Currently only the C language testsuites are documented 4222here; FIXME: document the others. 4223 4224* Menu: 4225 4226* Test Idioms:: Idioms used in testsuite code. 4227* Test Directives:: Directives used within DejaGnu tests. 4228* Ada Tests:: The Ada language testsuites. 4229* C Tests:: The C language testsuites. 4230* libgcj Tests:: The Java library testsuites. 4231* LTO Testing:: Support for testing link-time optimizations. 4232* gcov Testing:: Support for testing gcov. 4233* profopt Testing:: Support for testing profile-directed optimizations. 4234* compat Testing:: Support for testing binary compatibility. 4235* Torture Tests:: Support for torture testing using multiple options. 4236 4237 4238File: gccint.info, Node: Test Idioms, Next: Test Directives, Up: Testsuites 4239 42407.1 Idioms Used in Testsuite Code 4241================================= 4242 4243In general, C testcases have a trailing `-N.c', starting with `-1.c', 4244in case other testcases with similar names are added later. If the 4245test is a test of some well-defined feature, it should have a name 4246referring to that feature such as `FEATURE-1.c'. If it does not test a 4247well-defined feature but just happens to exercise a bug somewhere in 4248the compiler, and a bug report has been filed for this bug in the GCC 4249bug database, `prBUG-NUMBER-1.c' is the appropriate form of name. 4250Otherwise (for miscellaneous bugs not filed in the GCC bug database), 4251and previously more generally, test cases are named after the date on 4252which they were added. This allows people to tell at a glance whether 4253a test failure is because of a recently found bug that has not yet been 4254fixed, or whether it may be a regression, but does not give any other 4255information about the bug or where discussion of it may be found. Some 4256other language testsuites follow similar conventions. 4257 4258 In the `gcc.dg' testsuite, it is often necessary to test that an error 4259is indeed a hard error and not just a warning--for example, where it is 4260a constraint violation in the C standard, which must become an error 4261with `-pedantic-errors'. The following idiom, where the first line 4262shown is line LINE of the file and the line that generates the error, 4263is used for this: 4264 4265 /* { dg-bogus "warning" "warning in place of error" } */ 4266 /* { dg-error "REGEXP" "MESSAGE" { target *-*-* } LINE } */ 4267 4268 It may be necessary to check that an expression is an integer constant 4269expression and has a certain value. To check that `E' has value `V', 4270an idiom similar to the following is used: 4271 4272 char x[((E) == (V) ? 1 : -1)]; 4273 4274 In `gcc.dg' tests, `__typeof__' is sometimes used to make assertions 4275about the types of expressions. See, for example, 4276`gcc.dg/c99-condexpr-1.c'. The more subtle uses depend on the exact 4277rules for the types of conditional expressions in the C standard; see, 4278for example, `gcc.dg/c99-intconst-1.c'. 4279 4280 It is useful to be able to test that optimizations are being made 4281properly. This cannot be done in all cases, but it can be done where 4282the optimization will lead to code being optimized away (for example, 4283where flow analysis or alias analysis should show that certain code 4284cannot be called) or to functions not being called because they have 4285been expanded as built-in functions. Such tests go in 4286`gcc.c-torture/execute'. Where code should be optimized away, a call 4287to a nonexistent function such as `link_failure ()' may be inserted; a 4288definition 4289 4290 #ifndef __OPTIMIZE__ 4291 void 4292 link_failure (void) 4293 { 4294 abort (); 4295 } 4296 #endif 4297 4298will also be needed so that linking still succeeds when the test is run 4299without optimization. When all calls to a built-in function should 4300have been optimized and no calls to the non-built-in version of the 4301function should remain, that function may be defined as `static' to 4302call `abort ()' (although redeclaring a function as static may not work 4303on all targets). 4304 4305 All testcases must be portable. Target-specific testcases must have 4306appropriate code to avoid causing failures on unsupported systems; 4307unfortunately, the mechanisms for this differ by directory. 4308 4309 FIXME: discuss non-C testsuites here. 4310 4311 4312File: gccint.info, Node: Test Directives, Next: Ada Tests, Prev: Test Idioms, Up: Testsuites 4313 43147.2 Directives used within DejaGnu tests 4315======================================== 4316 4317* Menu: 4318 4319* Directives:: Syntax and descriptions of test directives. 4320* Selectors:: Selecting targets to which a test applies. 4321* Effective-Target Keywords:: Keywords describing target attributes. 4322* Add Options:: Features for `dg-add-options' 4323* Require Support:: Variants of `dg-require-SUPPORT' 4324* Final Actions:: Commands for use in `dg-final' 4325 4326 4327File: gccint.info, Node: Directives, Next: Selectors, Up: Test Directives 4328 43297.2.1 Syntax and Descriptions of test directives 4330------------------------------------------------ 4331 4332Test directives appear within comments in a test source file and begin 4333with `dg-'. Some of these are defined within DejaGnu and others are 4334local to the GCC testsuite. 4335 4336 The order in which test directives appear in a test can be important: 4337directives local to GCC sometimes override information used by the 4338DejaGnu directives, which know nothing about the GCC directives, so the 4339DejaGnu directives must precede GCC directives. 4340 4341 Several test directives include selectors (*note Selectors::) which 4342are usually preceded by the keyword `target' or `xfail'. 4343 43447.2.1.1 Specify how to build the test 4345..................................... 4346 4347`{ dg-do DO-WHAT-KEYWORD [{ target/xfail SELECTOR }] }' 4348 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 4349 is executed. It is one of: 4350 4351 `preprocess' 4352 Compile with `-E' to run only the preprocessor. 4353 4354 `compile' 4355 Compile with `-S' to produce an assembly code file. 4356 4357 `assemble' 4358 Compile with `-c' to produce a relocatable object file. 4359 4360 `link' 4361 Compile, assemble, and link to produce an executable file. 4362 4363 `run' 4364 Produce and run an executable file, which is expected to 4365 return an exit code of 0. 4366 4367 The default is `compile'. That can be overridden for a set of 4368 tests by redefining `dg-do-what-default' within the `.exp' file 4369 for those tests. 4370 4371 If the directive includes the optional `{ target SELECTOR }' then 4372 the test is skipped unless the target system matches the SELECTOR. 4373 4374 If DO-WHAT-KEYWORD is `run' and the directive includes the 4375 optional `{ xfail SELECTOR }' and the selector is met then the 4376 test is expected to fail. The `xfail' clause is ignored for other 4377 values of DO-WHAT-KEYWORD; those tests can use directive 4378 `dg-xfail-if'. 4379 43807.2.1.2 Specify additional compiler options 4381........................................... 4382 4383`{ dg-options OPTIONS [{ target SELECTOR }] }' 4384 This DejaGnu directive provides a list of compiler options, to be 4385 used if the target system matches SELECTOR, that replace the 4386 default options used for this set of tests. 4387 4388`{ dg-add-options FEATURE ... }' 4389 Add any compiler options that are needed to access certain 4390 features. This directive does nothing on targets that enable the 4391 features by default, or that don't provide them at all. It must 4392 come after all `dg-options' directives. For supported values of 4393 FEATURE see *note Add Options::. 4394 4395`{ dg-additional-options OPTIONS [{ target SELECTOR }] }' 4396 This directive provides a list of compiler options, to be used if 4397 the target system matches SELECTOR, that are added to the default 4398 options used for this set of tests. 4399 44007.2.1.3 Modify the test timeout value 4401..................................... 4402 4403The normal timeout limit, in seconds, is found by searching the 4404following in order: 4405 4406 * the value defined by an earlier `dg-timeout' directive in the test 4407 4408 * variable TOOL_TIMEOUT defined by the set of tests 4409 4410 * GCC,TIMEOUT set in the target board 4411 4412 * 300 4413 4414`{ dg-timeout N [{target SELECTOR }] }' 4415 Set the time limit for the compilation and for the execution of 4416 the test to the specified number of seconds. 4417 4418`{ dg-timeout-factor X [{ target SELECTOR }] }' 4419 Multiply the normal time limit for compilation and execution of 4420 the test by the specified floating-point factor. 4421 44227.2.1.4 Skip a test for some targets 4423.................................... 4424 4425`{ dg-skip-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4426 Arguments INCLUDE-OPTS and EXCLUDE-OPTS are lists in which each 4427 element is a string of zero or more GCC options. Skip the test if 4428 all of the following conditions are met: 4429 * the test system is included in SELECTOR 4430 4431 * for at least one of the option strings in INCLUDE-OPTS, every 4432 option from that string is in the set of options with which 4433 the test would be compiled; use `"*"' for an INCLUDE-OPTS list 4434 that matches any options; that is the default if INCLUDE-OPTS 4435 is not specified 4436 4437 * for each of the option strings in EXCLUDE-OPTS, at least one 4438 option from that string is not in the set of options with 4439 which the test would be compiled; use `""' for an empty 4440 EXCLUDE-OPTS list; that is the default if EXCLUDE-OPTS is not 4441 specified 4442 4443 For example, to skip a test if option `-Os' is present: 4444 4445 /* { dg-skip-if "" { *-*-* } { "-Os" } { "" } } */ 4446 4447 To skip a test if both options `-O2' and `-g' are present: 4448 4449 /* { dg-skip-if "" { *-*-* } { "-O2 -g" } { "" } } */ 4450 4451 To skip a test if either `-O2' or `-O3' is present: 4452 4453 /* { dg-skip-if "" { *-*-* } { "-O2" "-O3" } { "" } } */ 4454 4455 To skip a test unless option `-Os' is present: 4456 4457 /* { dg-skip-if "" { *-*-* } { "*" } { "-Os" } } */ 4458 4459 To skip a test if either `-O2' or `-O3' is used with `-g' but not 4460 if `-fpic' is also present: 4461 4462 /* { dg-skip-if "" { *-*-* } { "-O2 -g" "-O3 -g" } { "-fpic" } } */ 4463 4464`{ dg-require-effective-target KEYWORD [{ SELECTOR }] }' 4465 Skip the test if the test target, including current multilib flags, 4466 is not covered by the effective-target keyword. If the directive 4467 includes the optional `{ SELECTOR }' then the effective-target 4468 test is only performed if the target system matches the SELECTOR. 4469 This directive must appear after any `dg-do' directive in the test 4470 and before any `dg-additional-sources' directive. *Note 4471 Effective-Target Keywords::. 4472 4473`{ dg-require-SUPPORT args }' 4474 Skip the test if the target does not provide the required support. 4475 These directives must appear after any `dg-do' directive in the 4476 test and before any `dg-additional-sources' directive. They 4477 require at least one argument, which can be an empty string if the 4478 specific procedure does not examine the argument. *Note Require 4479 Support::, for a complete list of these directives. 4480 44817.2.1.5 Expect a test to fail for some targets 4482.............................................. 4483 4484`{ dg-xfail-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4485 Expect the test to fail if the conditions (which are the same as 4486 for `dg-skip-if') are met. This does not affect the execute step. 4487 4488`{ dg-xfail-run-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }' 4489 Expect the execute step of a test to fail if the conditions (which 4490 are the same as for `dg-skip-if') are met. 4491 44927.2.1.6 Expect the test executable to fail 4493.......................................... 4494 4495`{ dg-shouldfail COMMENT [{ SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]]] }' 4496 Expect the test executable to return a nonzero exit status if the 4497 conditions (which are the same as for `dg-skip-if') are met. 4498 44997.2.1.7 Verify compiler messages 4500................................ 4501 4502`{ dg-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4503 This DejaGnu directive appears on a source line that is expected 4504 to get an error message, or else specifies the source line 4505 associated with the message. If there is no message for that line 4506 or if the text of that message is not matched by REGEXP then the 4507 check fails and COMMENT is included in the `FAIL' message. The 4508 check does not look for the string `error' unless it is part of 4509 REGEXP. 4510 4511`{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4512 This DejaGnu directive appears on a source line that is expected 4513 to get a warning message, or else specifies the source line 4514 associated with the message. If there is no message for that line 4515 or if the text of that message is not matched by REGEXP then the 4516 check fails and COMMENT is included in the `FAIL' message. The 4517 check does not look for the string `warning' unless it is part of 4518 REGEXP. 4519 4520`{ dg-message REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4521 The line is expected to get a message other than an error or 4522 warning. If there is no message for that line or if the text of 4523 that message is not matched by REGEXP then the check fails and 4524 COMMENT is included in the `FAIL' message. 4525 4526`{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }' 4527 This DejaGnu directive appears on a source line that should not 4528 get a message matching REGEXP, or else specifies the source line 4529 associated with the bogus message. It is usually used with `xfail' 4530 to indicate that the message is a known problem for a particular 4531 set of targets. 4532 4533`{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }' 4534 This DejaGnu directive indicates that the test is expected to fail 4535 due to compiler messages that are not handled by `dg-error', 4536 `dg-warning' or `dg-bogus'. For this directive `xfail' has the 4537 same effect as `target'. 4538 4539`{ dg-prune-output REGEXP }' 4540 Prune messages matching REGEXP from the test output. 4541 45427.2.1.8 Verify output of the test executable 4543............................................ 4544 4545`{ dg-output REGEXP [{ target/xfail SELECTOR }] }' 4546 This DejaGnu directive compares REGEXP to the combined output that 4547 the test executable writes to `stdout' and `stderr'. 4548 45497.2.1.9 Specify additional files for a test 4550........................................... 4551 4552`{ dg-additional-files "FILELIST" }' 4553 Specify additional files, other than source files, that must be 4554 copied to the system where the compiler runs. 4555 4556`{ dg-additional-sources "FILELIST" }' 4557 Specify additional source files to appear in the compile line 4558 following the main test file. 4559 45607.2.1.10 Add checks at the end of a test 4561........................................ 4562 4563`{ dg-final { LOCAL-DIRECTIVE } }' 4564 This DejaGnu directive is placed within a comment anywhere in the 4565 source file and is processed after the test has been compiled and 4566 run. Multiple `dg-final' commands are processed in the order in 4567 which they appear in the source file. *Note Final Actions::, for 4568 a list of directives that can be used within `dg-final'. 4569 4570 4571File: gccint.info, Node: Selectors, Next: Effective-Target Keywords, Prev: Directives, Up: Test Directives 4572 45737.2.2 Selecting targets to which a test applies 4574----------------------------------------------- 4575 4576Several test directives include SELECTORs to limit the targets for 4577which a test is run or to declare that a test is expected to fail on 4578particular targets. 4579 4580 A selector is: 4581 * one or more target triplets, possibly including wildcard 4582 characters; use `*-*-*' to match any target 4583 4584 * a single effective-target keyword (*note Effective-Target 4585 Keywords::) 4586 4587 * a logical expression 4588 4589 Depending on the context, the selector specifies whether a test is 4590skipped and reported as unsupported or is expected to fail. A context 4591that allows either `target' or `xfail' also allows `{ target SELECTOR1 4592xfail SELECTOR2 }' to skip the test for targets that don't match 4593SELECTOR1 and the test to fail for targets that match SELECTOR2. 4594 4595 A selector expression appears within curly braces and uses a single 4596logical operator: one of `!', `&&', or `||'. An operand is another 4597selector expression, an effective-target keyword, a single target 4598triplet, or a list of target triplets within quotes or curly braces. 4599For example: 4600 4601 { target { ! "hppa*-*-* ia64*-*-*" } } 4602 { target { powerpc*-*-* && lp64 } } 4603 { xfail { lp64 || vect_no_align } } 4604 4605 4606File: gccint.info, Node: Effective-Target Keywords, Next: Add Options, Prev: Selectors, Up: Test Directives 4607 46087.2.3 Keywords describing target attributes 4609------------------------------------------- 4610 4611Effective-target keywords identify sets of targets that support 4612particular functionality. They are used to limit tests to be run only 4613for particular targets, or to specify that particular sets of targets 4614are expected to fail some tests. 4615 4616 Effective-target keywords are defined in `lib/target-supports.exp' in 4617the GCC testsuite, with the exception of those that are documented as 4618being local to a particular test directory. 4619 4620 The `effective target' takes into account all of the compiler options 4621with which the test will be compiled, including the multilib options. 4622By convention, keywords ending in `_nocache' can also include options 4623specified for the particular test in an earlier `dg-options' or 4624`dg-add-options' directive. 4625 46267.2.3.1 Data type sizes 4627....................... 4628 4629`ilp32' 4630 Target has 32-bit `int', `long', and pointers. 4631 4632`lp64' 4633 Target has 32-bit `int', 64-bit `long' and pointers. 4634 4635`llp64' 4636 Target has 32-bit `int' and `long', 64-bit `long long' and 4637 pointers. 4638 4639`double64' 4640 Target has 64-bit `double'. 4641 4642`double64plus' 4643 Target has `double' that is 64 bits or longer. 4644 4645`longdouble128' 4646 Target has 128-bit `long double'. 4647 4648`int32plus' 4649 Target has `int' that is at 32 bits or longer. 4650 4651`int16' 4652 Target has `int' that is 16 bits or shorter. 4653 4654`long_neq_int' 4655 Target has `int' and `long' with different sizes. 4656 4657`large_double' 4658 Target supports `double' that is longer than `float'. 4659 4660`large_long_double' 4661 Target supports `long double' that is longer than `double'. 4662 4663`ptr32plus' 4664 Target has pointers that are 32 bits or longer. 4665 4666`size32plus' 4667 Target supports array and structure sizes that are 32 bits or 4668 longer. 4669 4670`4byte_wchar_t' 4671 Target has `wchar_t' that is at least 4 bytes. 4672 46737.2.3.2 Fortran-specific attributes 4674................................... 4675 4676`fortran_integer_16' 4677 Target supports Fortran `integer' that is 16 bytes or longer. 4678 4679`fortran_large_int' 4680 Target supports Fortran `integer' kinds larger than `integer(8)'. 4681 4682`fortran_large_real' 4683 Target supports Fortran `real' kinds larger than `real(8)'. 4684 46857.2.3.3 Vector-specific attributes 4686.................................. 4687 4688`vect_condition' 4689 Target supports vector conditional operations. 4690 4691`vect_double' 4692 Target supports hardware vectors of `double'. 4693 4694`vect_float' 4695 Target supports hardware vectors of `float'. 4696 4697`vect_int' 4698 Target supports hardware vectors of `int'. 4699 4700`vect_long' 4701 Target supports hardware vectors of `long'. 4702 4703`vect_long_long' 4704 Target supports hardware vectors of `long long'. 4705 4706`vect_aligned_arrays' 4707 Target aligns arrays to vector alignment boundary. 4708 4709`vect_hw_misalign' 4710 Target supports a vector misalign access. 4711 4712`vect_no_align' 4713 Target does not support a vector alignment mechanism. 4714 4715`vect_no_int_max' 4716 Target does not support a vector max instruction on `int'. 4717 4718`vect_no_int_add' 4719 Target does not support a vector add instruction on `int'. 4720 4721`vect_no_bitwise' 4722 Target does not support vector bitwise instructions. 4723 4724`vect_char_mult' 4725 Target supports `vector char' multiplication. 4726 4727`vect_short_mult' 4728 Target supports `vector short' multiplication. 4729 4730`vect_int_mult' 4731 Target supports `vector int' multiplication. 4732 4733`vect_extract_even_odd' 4734 Target supports vector even/odd element extraction. 4735 4736`vect_extract_even_odd_wide' 4737 Target supports vector even/odd element extraction of vectors with 4738 elements `SImode' or larger. 4739 4740`vect_interleave' 4741 Target supports vector interleaving. 4742 4743`vect_strided' 4744 Target supports vector interleaving and extract even/odd. 4745 4746`vect_strided_wide' 4747 Target supports vector interleaving and extract even/odd for wide 4748 element types. 4749 4750`vect_perm' 4751 Target supports vector permutation. 4752 4753`vect_shift' 4754 Target supports a hardware vector shift operation. 4755 4756`vect_widen_sum_hi_to_si' 4757 Target supports a vector widening summation of `short' operands 4758 into `int' results, or can promote (unpack) from `short' to `int'. 4759 4760`vect_widen_sum_qi_to_hi' 4761 Target supports a vector widening summation of `char' operands 4762 into `short' results, or can promote (unpack) from `char' to 4763 `short'. 4764 4765`vect_widen_sum_qi_to_si' 4766 Target supports a vector widening summation of `char' operands 4767 into `int' results. 4768 4769`vect_widen_mult_qi_to_hi' 4770 Target supports a vector widening multiplication of `char' operands 4771 into `short' results, or can promote (unpack) from `char' to 4772 `short' and perform non-widening multiplication of `short'. 4773 4774`vect_widen_mult_hi_to_si' 4775 Target supports a vector widening multiplication of `short' 4776 operands into `int' results, or can promote (unpack) from `short' 4777 to `int' and perform non-widening multiplication of `int'. 4778 4779`vect_widen_mult_si_to_di_pattern' 4780 Target supports a vector widening multiplication of `int' operands 4781 into `long' results. 4782 4783`vect_sdot_qi' 4784 Target supports a vector dot-product of `signed char'. 4785 4786`vect_udot_qi' 4787 Target supports a vector dot-product of `unsigned char'. 4788 4789`vect_sdot_hi' 4790 Target supports a vector dot-product of `signed short'. 4791 4792`vect_udot_hi' 4793 Target supports a vector dot-product of `unsigned short'. 4794 4795`vect_pack_trunc' 4796 Target supports a vector demotion (packing) of `short' to `char' 4797 and from `int' to `short' using modulo arithmetic. 4798 4799`vect_unpack' 4800 Target supports a vector promotion (unpacking) of `char' to `short' 4801 and from `char' to `int'. 4802 4803`vect_intfloat_cvt' 4804 Target supports conversion from `signed int' to `float'. 4805 4806`vect_uintfloat_cvt' 4807 Target supports conversion from `unsigned int' to `float'. 4808 4809`vect_floatint_cvt' 4810 Target supports conversion from `float' to `signed int'. 4811 4812`vect_floatuint_cvt' 4813 Target supports conversion from `float' to `unsigned int'. 4814 48157.2.3.4 Thread Local Storage attributes 4816....................................... 4817 4818`tls' 4819 Target supports thread-local storage. 4820 4821`tls_native' 4822 Target supports native (rather than emulated) thread-local storage. 4823 4824`tls_runtime' 4825 Test system supports executing TLS executables. 4826 48277.2.3.5 Decimal floating point attributes 4828......................................... 4829 4830`dfp' 4831 Targets supports compiling decimal floating point extension to C. 4832 4833`dfp_nocache' 4834 Including the options used to compile this particular test, the 4835 target supports compiling decimal floating point extension to C. 4836 4837`dfprt' 4838 Test system can execute decimal floating point tests. 4839 4840`dfprt_nocache' 4841 Including the options used to compile this particular test, the 4842 test system can execute decimal floating point tests. 4843 4844`hard_dfp' 4845 Target generates decimal floating point instructions with current 4846 options. 4847 48487.2.3.6 ARM-specific attributes 4849............................... 4850 4851`arm32' 4852 ARM target generates 32-bit code. 4853 4854`arm_eabi' 4855 ARM target adheres to the ABI for the ARM Architecture. 4856 4857`arm_hf_eabi' 4858 ARM target adheres to the VFP and Advanced SIMD Register Arguments 4859 variant of the ABI for the ARM Architecture (as selected with 4860 `-mfloat-abi=hard'). 4861 4862`arm_hard_vfp_ok' 4863 ARM target supports `-mfpu=vfp -mfloat-abi=hard'. Some multilibs 4864 may be incompatible with these options. 4865 4866`arm_iwmmxt_ok' 4867 ARM target supports `-mcpu=iwmmxt'. Some multilibs may be 4868 incompatible with this option. 4869 4870`arm_neon' 4871 ARM target supports generating NEON instructions. 4872 4873`arm_tune_string_ops_prefer_neon' 4874 Test CPU tune supports inlining string operations with NEON 4875 instructions. 4876 4877`arm_neon_hw' 4878 Test system supports executing NEON instructions. 4879 4880`arm_neonv2_hw' 4881 Test system supports executing NEON v2 instructions. 4882 4883`arm_neon_ok' 4884 ARM Target supports `-mfpu=neon -mfloat-abi=softfp' or compatible 4885 options. Some multilibs may be incompatible with these options. 4886 4887`arm_neonv2_ok' 4888 ARM Target supports `-mfpu=neon-vfpv4 -mfloat-abi=softfp' or 4889 compatible options. Some multilibs may be incompatible with these 4890 options. 4891 4892`arm_neon_fp16_ok' 4893 ARM Target supports `-mfpu=neon-fp16 -mfloat-abi=softfp' or 4894 compatible options. Some multilibs may be incompatible with these 4895 options. 4896 4897`arm_thumb1_ok' 4898 ARM target generates Thumb-1 code for `-mthumb'. 4899 4900`arm_thumb2_ok' 4901 ARM target generates Thumb-2 code for `-mthumb'. 4902 4903`arm_vfp_ok' 4904 ARM target supports `-mfpu=vfp -mfloat-abi=softfp'. Some 4905 multilibs may be incompatible with these options. 4906 4907`arm_vfp3_ok' 4908 ARM target supports `-mfpu=vfp3 -mfloat-abi=softfp'. Some 4909 multilibs may be incompatible with these options. 4910 4911`arm_v8_vfp_ok' 4912 ARM target supports `-mfpu=fp-armv8 -mfloat-abi=softfp'. Some 4913 multilibs may be incompatible with these options. 4914 4915`arm_v8_neon_ok' 4916 ARM target supports `-mfpu=neon-fp-armv8 -mfloat-abi=softfp'. 4917 Some multilibs may be incompatible with these options. 4918 4919`arm_prefer_ldrd_strd' 4920 ARM target prefers `LDRD' and `STRD' instructions over `LDM' and 4921 `STM' instructions. 4922 4923 49247.2.3.7 MIPS-specific attributes 4925................................ 4926 4927`mips64' 4928 MIPS target supports 64-bit instructions. 4929 4930`nomips16' 4931 MIPS target does not produce MIPS16 code. 4932 4933`mips16_attribute' 4934 MIPS target can generate MIPS16 code. 4935 4936`mips_loongson' 4937 MIPS target is a Loongson-2E or -2F target using an ABI that 4938 supports the Loongson vector modes. 4939 4940`mips_newabi_large_long_double' 4941 MIPS target supports `long double' larger than `double' when using 4942 the new ABI. 4943 4944`mpaired_single' 4945 MIPS target supports `-mpaired-single'. 4946 49477.2.3.8 PowerPC-specific attributes 4948................................... 4949 4950`dfp_hw' 4951 PowerPC target supports executing hardware DFP instructions. 4952 4953`p8vector_hw' 4954 PowerPC target supports executing VSX instructions (ISA 2.07). 4955 4956`powerpc64' 4957 Test system supports executing 64-bit instructions. 4958 4959`powerpc_altivec' 4960 PowerPC target supports AltiVec. 4961 4962`powerpc_altivec_ok' 4963 PowerPC target supports `-maltivec'. 4964 4965`powerpc_eabi_ok' 4966 PowerPC target supports `-meabi'. 4967 4968`powerpc_elfv2' 4969 PowerPC target supports `-mabi=elfv2'. 4970 4971`powerpc_fprs' 4972 PowerPC target supports floating-point registers. 4973 4974`powerpc_hard_double' 4975 PowerPC target supports hardware double-precision floating-point. 4976 4977`powerpc_htm_ok' 4978 PowerPC target supports `-mhtm' 4979 4980`powerpc_p8vector_ok' 4981 PowerPC target supports `-mpower8-vector' 4982 4983`powerpc_ppu_ok' 4984 PowerPC target supports `-mcpu=cell'. 4985 4986`powerpc_spe' 4987 PowerPC target supports PowerPC SPE. 4988 4989`powerpc_spe_nocache' 4990 Including the options used to compile this particular test, the 4991 PowerPC target supports PowerPC SPE. 4992 4993`powerpc_spu' 4994 PowerPC target supports PowerPC SPU. 4995 4996`powerpc_vsx_ok' 4997 PowerPC target supports `-mvsx'. 4998 4999`powerpc_405_nocache' 5000 Including the options used to compile this particular test, the 5001 PowerPC target supports PowerPC 405. 5002 5003`ppc_recip_hw' 5004 PowerPC target supports executing reciprocal estimate instructions. 5005 5006`spu_auto_overlay' 5007 SPU target has toolchain that supports automatic overlay 5008 generation. 5009 5010`vmx_hw' 5011 PowerPC target supports executing AltiVec instructions. 5012 5013`vsx_hw' 5014 PowerPC target supports executing VSX instructions (ISA 2.06). 5015 50167.2.3.9 Other hardware attributes 5017................................. 5018 5019`avx' 5020 Target supports compiling `avx' instructions. 5021 5022`avx_runtime' 5023 Target supports the execution of `avx' instructions. 5024 5025`cell_hw' 5026 Test system can execute AltiVec and Cell PPU instructions. 5027 5028`coldfire_fpu' 5029 Target uses a ColdFire FPU. 5030 5031`hard_float' 5032 Target supports FPU instructions. 5033 5034`non_strict_align' 5035 Target does not require strict alignment. 5036 5037`sse' 5038 Target supports compiling `sse' instructions. 5039 5040`sse_runtime' 5041 Target supports the execution of `sse' instructions. 5042 5043`sse2' 5044 Target supports compiling `sse2' instructions. 5045 5046`sse2_runtime' 5047 Target supports the execution of `sse2' instructions. 5048 5049`sync_char_short' 5050 Target supports atomic operations on `char' and `short'. 5051 5052`sync_int_long' 5053 Target supports atomic operations on `int' and `long'. 5054 5055`ultrasparc_hw' 5056 Test environment appears to run executables on a simulator that 5057 accepts only `EM_SPARC' executables and chokes on `EM_SPARC32PLUS' 5058 or `EM_SPARCV9' executables. 5059 5060`vect_cmdline_needed' 5061 Target requires a command line argument to enable a SIMD 5062 instruction set. 5063 5064`pie_copyreloc' 5065 The x86-64 target linker supports PIE with copy reloc. 5066 50677.2.3.10 Environment attributes 5068............................... 5069 5070`c' 5071 The language for the compiler under test is C. 5072 5073`c++' 5074 The language for the compiler under test is C++. 5075 5076`c99_runtime' 5077 Target provides a full C99 runtime. 5078 5079`correct_iso_cpp_string_wchar_protos' 5080 Target `string.h' and `wchar.h' headers provide C++ required 5081 overloads for `strchr' etc. functions. 5082 5083`dummy_wcsftime' 5084 Target uses a dummy `wcsftime' function that always returns zero. 5085 5086`fd_truncate' 5087 Target can truncate a file from a file descriptor, as used by 5088 `libgfortran/io/unix.c:fd_truncate'; i.e. `ftruncate' or `chsize'. 5089 5090`freestanding' 5091 Target is `freestanding' as defined in section 4 of the C99 5092 standard. Effectively, it is a target which supports no extra 5093 headers or libraries other than what is considered essential. 5094 5095`init_priority' 5096 Target supports constructors with initialization priority 5097 arguments. 5098 5099`inttypes_types' 5100 Target has the basic signed and unsigned types in `inttypes.h'. 5101 This is for tests that GCC's notions of these types agree with 5102 those in the header, as some systems have only `inttypes.h'. 5103 5104`lax_strtofp' 5105 Target might have errors of a few ULP in string to floating-point 5106 conversion functions and overflow is not always detected correctly 5107 by those functions. 5108 5109`mempcpy' 5110 Target provides `mempcpy' function. 5111 5112`mmap' 5113 Target supports `mmap'. 5114 5115`newlib' 5116 Target supports Newlib. 5117 5118`pow10' 5119 Target provides `pow10' function. 5120 5121`pthread' 5122 Target can compile using `pthread.h' with no errors or warnings. 5123 5124`pthread_h' 5125 Target has `pthread.h'. 5126 5127`run_expensive_tests' 5128 Expensive testcases (usually those that consume excessive amounts 5129 of CPU time) should be run on this target. This can be enabled by 5130 setting the `GCC_TEST_RUN_EXPENSIVE' environment variable to a 5131 non-empty string. 5132 5133`simulator' 5134 Test system runs executables on a simulator (i.e. slowly) rather 5135 than hardware (i.e. fast). 5136 5137`stabs' 5138 Target supports the stabs debugging format. 5139 5140`stdint_types' 5141 Target has the basic signed and unsigned C types in `stdint.h'. 5142 This will be obsolete when GCC ensures a working `stdint.h' for 5143 all targets. 5144 5145`stpcpy' 5146 Target provides `stpcpy' function. 5147 5148`trampolines' 5149 Target supports trampolines. 5150 5151`uclibc' 5152 Target supports uClibc. 5153 5154`unwrapped' 5155 Target does not use a status wrapper. 5156 5157`vxworks_kernel' 5158 Target is a VxWorks kernel. 5159 5160`vxworks_rtp' 5161 Target is a VxWorks RTP. 5162 5163`wchar' 5164 Target supports wide characters. 5165 51667.2.3.11 Other attributes 5167......................... 5168 5169`automatic_stack_alignment' 5170 Target supports automatic stack alignment. 5171 5172`cxa_atexit' 5173 Target uses `__cxa_atexit'. 5174 5175`default_packed' 5176 Target has packed layout of structure members by default. 5177 5178`fgraphite' 5179 Target supports Graphite optimizations. 5180 5181`fixed_point' 5182 Target supports fixed-point extension to C. 5183 5184`fopenacc' 5185 Target supports OpenACC via `-fopenacc'. 5186 5187`fopenmp' 5188 Target supports OpenMP via `-fopenmp'. 5189 5190`fpic' 5191 Target supports `-fpic' and `-fPIC'. 5192 5193`freorder' 5194 Target supports `-freorder-blocks-and-partition'. 5195 5196`fstack_protector' 5197 Target supports `-fstack-protector'. 5198 5199`gas' 5200 Target uses GNU `as'. 5201 5202`gc_sections' 5203 Target supports `--gc-sections'. 5204 5205`gld' 5206 Target uses GNU `ld'. 5207 5208`keeps_null_pointer_checks' 5209 Target keeps null pointer checks, either due to the use of 5210 `-fno-delete-null-pointer-checks' or hardwired into the target. 5211 5212`lto' 5213 Compiler has been configured to support link-time optimization 5214 (LTO). 5215 5216`naked_functions' 5217 Target supports the `naked' function attribute. 5218 5219`named_sections' 5220 Target supports named sections. 5221 5222`natural_alignment_32' 5223 Target uses natural alignment (aligned to type size) for types of 5224 32 bits or less. 5225 5226`target_natural_alignment_64' 5227 Target uses natural alignment (aligned to type size) for types of 5228 64 bits or less. 5229 5230`nonpic' 5231 Target does not generate PIC by default. 5232 5233`pie_enabled' 5234 Target generates PIE by default. 5235 5236`pcc_bitfield_type_matters' 5237 Target defines `PCC_BITFIELD_TYPE_MATTERS'. 5238 5239`pe_aligned_commons' 5240 Target supports `-mpe-aligned-commons'. 5241 5242`pie' 5243 Target supports `-pie', `-fpie' and `-fPIE'. 5244 5245`section_anchors' 5246 Target supports section anchors. 5247 5248`short_enums' 5249 Target defaults to short enums. 5250 5251`static' 5252 Target supports `-static'. 5253 5254`static_libgfortran' 5255 Target supports statically linking `libgfortran'. 5256 5257`string_merging' 5258 Target supports merging string constants at link time. 5259 5260`ucn' 5261 Target supports compiling and assembling UCN. 5262 5263`ucn_nocache' 5264 Including the options used to compile this particular test, the 5265 target supports compiling and assembling UCN. 5266 5267`unaligned_stack' 5268 Target does not guarantee that its `STACK_BOUNDARY' is greater than 5269 or equal to the required vector alignment. 5270 5271`vector_alignment_reachable' 5272 Vector alignment is reachable for types of 32 bits or less. 5273 5274`vector_alignment_reachable_for_64bit' 5275 Vector alignment is reachable for types of 64 bits or less. 5276 5277`wchar_t_char16_t_compatible' 5278 Target supports `wchar_t' that is compatible with `char16_t'. 5279 5280`wchar_t_char32_t_compatible' 5281 Target supports `wchar_t' that is compatible with `char32_t'. 5282 5283`comdat_group' 5284 Target uses comdat groups. 5285 52867.2.3.12 Local to tests in `gcc.target/i386' 5287............................................ 5288 5289`3dnow' 5290 Target supports compiling `3dnow' instructions. 5291 5292`aes' 5293 Target supports compiling `aes' instructions. 5294 5295`fma4' 5296 Target supports compiling `fma4' instructions. 5297 5298`ms_hook_prologue' 5299 Target supports attribute `ms_hook_prologue'. 5300 5301`pclmul' 5302 Target supports compiling `pclmul' instructions. 5303 5304`sse3' 5305 Target supports compiling `sse3' instructions. 5306 5307`sse4' 5308 Target supports compiling `sse4' instructions. 5309 5310`sse4a' 5311 Target supports compiling `sse4a' instructions. 5312 5313`ssse3' 5314 Target supports compiling `ssse3' instructions. 5315 5316`vaes' 5317 Target supports compiling `vaes' instructions. 5318 5319`vpclmul' 5320 Target supports compiling `vpclmul' instructions. 5321 5322`xop' 5323 Target supports compiling `xop' instructions. 5324 53257.2.3.13 Local to tests in `gcc.target/spu/ea' 5326.............................................. 5327 5328`ealib' 5329 Target `__ea' library functions are available. 5330 53317.2.3.14 Local to tests in `gcc.test-framework' 5332............................................... 5333 5334`no' 5335 Always returns 0. 5336 5337`yes' 5338 Always returns 1. 5339 5340 5341File: gccint.info, Node: Add Options, Next: Require Support, Prev: Effective-Target Keywords, Up: Test Directives 5342 53437.2.4 Features for `dg-add-options' 5344----------------------------------- 5345 5346The supported values of FEATURE for directive `dg-add-options' are: 5347 5348`arm_neon' 5349 NEON support. Only ARM targets support this feature, and only then 5350 in certain modes; see the *note arm_neon_ok effective target 5351 keyword: arm_neon_ok. 5352 5353`arm_neon_fp16' 5354 NEON and half-precision floating point support. Only ARM targets 5355 support this feature, and only then in certain modes; see the 5356 *note arm_neon_fp16_ok effective target keyword: arm_neon_ok. 5357 5358`arm_vfp3' 5359 arm vfp3 floating point support; see the *note arm_vfp3_ok 5360 effective target keyword: arm_vfp3_ok. 5361 5362`bind_pic_locally' 5363 Add the target-specific flags needed to enable functions to bind 5364 locally when using pic/PIC passes in the testsuite. 5365 5366`c99_runtime' 5367 Add the target-specific flags needed to access the C99 runtime. 5368 5369`ieee' 5370 Add the target-specific flags needed to enable full IEEE 5371 compliance mode. 5372 5373`mips16_attribute' 5374 `mips16' function attributes. Only MIPS targets support this 5375 feature, and only then in certain modes. 5376 5377`tls' 5378 Add the target-specific flags needed to use thread-local storage. 5379 5380 5381File: gccint.info, Node: Require Support, Next: Final Actions, Prev: Add Options, Up: Test Directives 5382 53837.2.5 Variants of `dg-require-SUPPORT' 5384-------------------------------------- 5385 5386A few of the `dg-require' directives take arguments. 5387 5388`dg-require-iconv CODESET' 5389 Skip the test if the target does not support iconv. CODESET is 5390 the codeset to convert to. 5391 5392`dg-require-profiling PROFOPT' 5393 Skip the test if the target does not support profiling with option 5394 PROFOPT. 5395 5396`dg-require-visibility VIS' 5397 Skip the test if the target does not support the `visibility' 5398 attribute. If VIS is `""', support for `visibility("hidden")' is 5399 checked, for `visibility("VIS")' otherwise. 5400 5401 The original `dg-require' directives were defined before there was 5402support for effective-target keywords. The directives that do not take 5403arguments could be replaced with effective-target keywords. 5404 5405`dg-require-alias ""' 5406 Skip the test if the target does not support the `alias' attribute. 5407 5408`dg-require-ascii-locale ""' 5409 Skip the test if the host does not support an ASCII locale. 5410 5411`dg-require-compat-dfp ""' 5412 Skip this test unless both compilers in a `compat' testsuite 5413 support decimal floating point. 5414 5415`dg-require-cxa-atexit ""' 5416 Skip the test if the target does not support `__cxa_atexit'. This 5417 is equivalent to `dg-require-effective-target cxa_atexit'. 5418 5419`dg-require-dll ""' 5420 Skip the test if the target does not support DLL attributes. 5421 5422`dg-require-fork ""' 5423 Skip the test if the target does not support `fork'. 5424 5425`dg-require-gc-sections ""' 5426 Skip the test if the target's linker does not support the 5427 `--gc-sections' flags. This is equivalent to 5428 `dg-require-effective-target gc-sections'. 5429 5430`dg-require-host-local ""' 5431 Skip the test if the host is remote, rather than the same as the 5432 build system. Some tests are incompatible with DejaGnu's handling 5433 of remote hosts, which involves copying the source file to the 5434 host and compiling it with a relative path and "`-o a.out'". 5435 5436`dg-require-mkfifo ""' 5437 Skip the test if the target does not support `mkfifo'. 5438 5439`dg-require-named-sections ""' 5440 Skip the test is the target does not support named sections. This 5441 is equivalent to `dg-require-effective-target named_sections'. 5442 5443`dg-require-weak ""' 5444 Skip the test if the target does not support weak symbols. 5445 5446`dg-require-weak-override ""' 5447 Skip the test if the target does not support overriding weak 5448 symbols. 5449 5450 5451File: gccint.info, Node: Final Actions, Prev: Require Support, Up: Test Directives 5452 54537.2.6 Commands for use in `dg-final' 5454------------------------------------ 5455 5456The GCC testsuite defines the following directives to be used within 5457`dg-final'. 5458 54597.2.6.1 Scan a particular file 5460.............................. 5461 5462`scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]' 5463 Passes if REGEXP matches text in FILENAME. 5464 5465`scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]' 5466 Passes if REGEXP does not match text in FILENAME. 5467 5468`scan-module MODULE REGEXP [{ target/xfail SELECTOR }]' 5469 Passes if REGEXP matches in Fortran module MODULE. 5470 54717.2.6.2 Scan the assembly output 5472................................ 5473 5474`scan-assembler REGEX [{ target/xfail SELECTOR }]' 5475 Passes if REGEX matches text in the test's assembler output. 5476 5477`scan-assembler-not REGEX [{ target/xfail SELECTOR }]' 5478 Passes if REGEX does not match text in the test's assembler output. 5479 5480`scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]' 5481 Passes if REGEX is matched exactly NUM times in the test's 5482 assembler output. 5483 5484`scan-assembler-dem REGEX [{ target/xfail SELECTOR }]' 5485 Passes if REGEX matches text in the test's demangled assembler 5486 output. 5487 5488`scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]' 5489 Passes if REGEX does not match text in the test's demangled 5490 assembler output. 5491 5492`scan-hidden SYMBOL [{ target/xfail SELECTOR }]' 5493 Passes if SYMBOL is defined as a hidden symbol in the test's 5494 assembly output. 5495 5496`scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]' 5497 Passes if SYMBOL is not defined as a hidden symbol in the test's 5498 assembly output. 5499 55007.2.6.3 Scan optimization dump files 5501.................................... 5502 5503These commands are available for KIND of `tree', `rtl', and `ipa'. 5504 5505`scan-KIND-dump REGEX SUFFIX [{ target/xfail SELECTOR }]' 5506 Passes if REGEX matches text in the dump file with suffix SUFFIX. 5507 5508`scan-KIND-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5509 Passes if REGEX does not match text in the dump file with suffix 5510 SUFFIX. 5511 5512`scan-KIND-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]' 5513 Passes if REGEX is found exactly NUM times in the dump file with 5514 suffix SUFFIX. 5515 5516`scan-KIND-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]' 5517 Passes if REGEX matches demangled text in the dump file with 5518 suffix SUFFIX. 5519 5520`scan-KIND-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]' 5521 Passes if REGEX does not match demangled text in the dump file with 5522 suffix SUFFIX. 5523 55247.2.6.4 Verify that an output files exists or not 5525................................................. 5526 5527`output-exists [{ target/xfail SELECTOR }]' 5528 Passes if compiler output file exists. 5529 5530`output-exists-not [{ target/xfail SELECTOR }]' 5531 Passes if compiler output file does not exist. 5532 55337.2.6.5 Check for LTO tests 5534........................... 5535 5536`scan-symbol REGEXP [{ target/xfail SELECTOR }]' 5537 Passes if the pattern is present in the final executable. 5538 55397.2.6.6 Checks for `gcov' tests 5540............................... 5541 5542`run-gcov SOURCEFILE' 5543 Check line counts in `gcov' tests. 5544 5545`run-gcov [branches] [calls] { OPTS SOURCEFILE }' 5546 Check branch and/or call counts, in addition to line counts, in 5547 `gcov' tests. 5548 55497.2.6.7 Clean up generated test files 5550..................................... 5551 5552`cleanup-coverage-files' 5553 Removes coverage data files generated for this test. 5554 5555`cleanup-ipa-dump SUFFIX' 5556 Removes IPA dump files generated for this test. 5557 5558`cleanup-modules "LIST-OF-EXTRA-MODULES"' 5559 Removes Fortran module files generated for this test, excluding the 5560 module names listed in keep-modules. Cleaning up module files is 5561 usually done automatically by the testsuite by looking at the 5562 source files and removing the modules after the test has been 5563 executed. 5564 module MoD1 5565 end module MoD1 5566 module Mod2 5567 end module Mod2 5568 module moD3 5569 end module moD3 5570 module mod4 5571 end module mod4 5572 ! { dg-final { cleanup-modules "mod1 mod2" } } ! redundant 5573 ! { dg-final { keep-modules "mod3 mod4" } } 5574 5575`keep-modules "LIST-OF-MODULES-NOT-TO-DELETE"' 5576 Whitespace separated list of module names that should not be 5577 deleted by cleanup-modules. If the list of modules is empty, all 5578 modules defined in this file are kept. 5579 module maybe_unneeded 5580 end module maybe_unneeded 5581 module keep1 5582 end module keep1 5583 module keep2 5584 end module keep2 5585 ! { dg-final { keep-modules "keep1 keep2" } } ! just keep these two 5586 ! { dg-final { keep-modules "" } } ! keep all 5587 5588`cleanup-profile-file' 5589 Removes profiling files generated for this test. 5590 5591`cleanup-repo-files' 5592 Removes files generated for this test for `-frepo'. 5593 5594`cleanup-rtl-dump SUFFIX' 5595 Removes RTL dump files generated for this test. 5596 5597`cleanup-saved-temps' 5598 Removes files for the current test which were kept for 5599 `-save-temps'. 5600 5601`cleanup-tree-dump SUFFIX' 5602 Removes tree dump files matching SUFFIX which were generated for 5603 this test. 5604 5605 5606File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites 5607 56087.3 Ada Language Testsuites 5609=========================== 5610 5611The Ada testsuite includes executable tests from the ACATS testsuite, 5612publicly available at `http://www.ada-auth.org/acats.html'. 5613 5614 These tests are integrated in the GCC testsuite in the `ada/acats' 5615directory, and enabled automatically when running `make check', assuming 5616the Ada language has been enabled when configuring GCC. 5617 5618 You can also run the Ada testsuite independently, using `make 5619check-ada', or run a subset of the tests by specifying which chapter to 5620run, e.g.: 5621 5622 $ make check-ada CHAPTERS="c3 c9" 5623 5624 The tests are organized by directory, each directory corresponding to 5625a chapter of the Ada Reference Manual. So for example, `c9' corresponds 5626to chapter 9, which deals with tasking features of the language. 5627 5628 There is also an extra chapter called `gcc' containing a template for 5629creating new executable tests, although this is deprecated in favor of 5630the `gnat.dg' testsuite. 5631 5632 The tests are run using two `sh' scripts: `run_acats' and 5633`run_all.sh'. To run the tests using a simulator or a cross target, 5634see the small customization section at the top of `run_all.sh'. 5635 5636 These tests are run using the build tree: they can be run without doing 5637a `make install'. 5638 5639 5640File: gccint.info, Node: C Tests, Next: libgcj Tests, Prev: Ada Tests, Up: Testsuites 5641 56427.4 C Language Testsuites 5643========================= 5644 5645GCC contains the following C language testsuites, in the 5646`gcc/testsuite' directory: 5647 5648`gcc.dg' 5649 This contains tests of particular features of the C compiler, 5650 using the more modern `dg' harness. Correctness tests for various 5651 compiler features should go here if possible. 5652 5653 Magic comments determine whether the file is preprocessed, 5654 compiled, linked or run. In these tests, error and warning 5655 message texts are compared against expected texts or regular 5656 expressions given in comments. These tests are run with the 5657 options `-ansi -pedantic' unless other options are given in the 5658 test. Except as noted below they are not run with multiple 5659 optimization options. 5660 5661`gcc.dg/compat' 5662 This subdirectory contains tests for binary compatibility using 5663 `lib/compat.exp', which in turn uses the language-independent 5664 support (*note Support for testing binary compatibility: compat 5665 Testing.). 5666 5667`gcc.dg/cpp' 5668 This subdirectory contains tests of the preprocessor. 5669 5670`gcc.dg/debug' 5671 This subdirectory contains tests for debug formats. Tests in this 5672 subdirectory are run for each debug format that the compiler 5673 supports. 5674 5675`gcc.dg/format' 5676 This subdirectory contains tests of the `-Wformat' format 5677 checking. Tests in this directory are run with and without 5678 `-DWIDE'. 5679 5680`gcc.dg/noncompile' 5681 This subdirectory contains tests of code that should not compile 5682 and does not need any special compilation options. They are run 5683 with multiple optimization options, since sometimes invalid code 5684 crashes the compiler with optimization. 5685 5686`gcc.dg/special' 5687 FIXME: describe this. 5688 5689`gcc.c-torture' 5690 This contains particular code fragments which have historically 5691 broken easily. These tests are run with multiple optimization 5692 options, so tests for features which only break at some 5693 optimization levels belong here. This also contains tests to 5694 check that certain optimizations occur. It might be worthwhile to 5695 separate the correctness tests cleanly from the code quality 5696 tests, but it hasn't been done yet. 5697 5698`gcc.c-torture/compat' 5699 FIXME: describe this. 5700 5701 This directory should probably not be used for new tests. 5702 5703`gcc.c-torture/compile' 5704 This testsuite contains test cases that should compile, but do not 5705 need to link or run. These test cases are compiled with several 5706 different combinations of optimization options. All warnings are 5707 disabled for these test cases, so this directory is not suitable if 5708 you wish to test for the presence or absence of compiler warnings. 5709 While special options can be set, and tests disabled on specific 5710 platforms, by the use of `.x' files, mostly these test cases 5711 should not contain platform dependencies. FIXME: discuss how 5712 defines such as `NO_LABEL_VALUES' and `STACK_SIZE' are used. 5713 5714`gcc.c-torture/execute' 5715 This testsuite contains test cases that should compile, link and 5716 run; otherwise the same comments as for `gcc.c-torture/compile' 5717 apply. 5718 5719`gcc.c-torture/execute/ieee' 5720 This contains tests which are specific to IEEE floating point. 5721 5722`gcc.c-torture/unsorted' 5723 FIXME: describe this. 5724 5725 This directory should probably not be used for new tests. 5726 5727`gcc.misc-tests' 5728 This directory contains C tests that require special handling. 5729 Some of these tests have individual expect files, and others share 5730 special-purpose expect files: 5731 5732 ``bprob*.c'' 5733 Test `-fbranch-probabilities' using 5734 `gcc.misc-tests/bprob.exp', which in turn uses the generic, 5735 language-independent framework (*note Support for testing 5736 profile-directed optimizations: profopt Testing.). 5737 5738 ``gcov*.c'' 5739 Test `gcov' output using `gcov.exp', which in turn uses the 5740 language-independent support (*note Support for testing gcov: 5741 gcov Testing.). 5742 5743 ``i386-pf-*.c'' 5744 Test i386-specific support for data prefetch using 5745 `i386-prefetch.exp'. 5746 5747`gcc.test-framework' 5748 5749 ``dg-*.c'' 5750 Test the testsuite itself using 5751 `gcc.test-framework/test-framework.exp'. 5752 5753 5754 FIXME: merge in `testsuite/README.gcc' and discuss the format of test 5755cases and magic comments more. 5756 5757 5758File: gccint.info, Node: libgcj Tests, Next: LTO Testing, Prev: C Tests, Up: Testsuites 5759 57607.5 The Java library testsuites. 5761================================ 5762 5763Runtime tests are executed via `make check' in the 5764`TARGET/libjava/testsuite' directory in the build tree. Additional 5765runtime tests can be checked into this testsuite. 5766 5767 Regression testing of the core packages in libgcj is also covered by 5768the Mauve testsuite. The Mauve Project develops tests for the Java 5769Class Libraries. These tests are run as part of libgcj testing by 5770placing the Mauve tree within the libjava testsuite sources at 5771`libjava/testsuite/libjava.mauve/mauve', or by specifying the location 5772of that tree when invoking `make', as in `make MAUVEDIR=~/mauve check'. 5773 5774 To detect regressions, a mechanism in `mauve.exp' compares the 5775failures for a test run against the list of expected failures in 5776`libjava/testsuite/libjava.mauve/xfails' from the source hierarchy. 5777Update this file when adding new failing tests to Mauve, or when fixing 5778bugs in libgcj that had caused Mauve test failures. 5779 5780 We encourage developers to contribute test cases to Mauve. 5781 5782 5783File: gccint.info, Node: LTO Testing, Next: gcov Testing, Prev: libgcj Tests, Up: Testsuites 5784 57857.6 Support for testing link-time optimizations 5786=============================================== 5787 5788Tests for link-time optimizations usually require multiple source files 5789that are compiled separately, perhaps with different sets of options. 5790There are several special-purpose test directives used for these tests. 5791 5792`{ dg-lto-do DO-WHAT-KEYWORD }' 5793 DO-WHAT-KEYWORD specifies how the test is compiled and whether it 5794 is executed. It is one of: 5795 5796 `assemble' 5797 Compile with `-c' to produce a relocatable object file. 5798 5799 `link' 5800 Compile, assemble, and link to produce an executable file. 5801 5802 `run' 5803 Produce and run an executable file, which is expected to 5804 return an exit code of 0. 5805 5806 The default is `assemble'. That can be overridden for a set of 5807 tests by redefining `dg-do-what-default' within the `.exp' file 5808 for those tests. 5809 5810 Unlike `dg-do', `dg-lto-do' does not support an optional `target' 5811 or `xfail' list. Use `dg-skip-if', `dg-xfail-if', or 5812 `dg-xfail-run-if'. 5813 5814`{ dg-lto-options { { OPTIONS } [{ OPTIONS }] } [{ target SELECTOR }]}' 5815 This directive provides a list of one or more sets of compiler 5816 options to override LTO_OPTIONS. Each test will be compiled and 5817 run with each of these sets of options. 5818 5819`{ dg-extra-ld-options OPTIONS [{ target SELECTOR }]}' 5820 This directive adds OPTIONS to the linker options used. 5821 5822`{ dg-suppress-ld-options OPTIONS [{ target SELECTOR }]}' 5823 This directive removes OPTIONS from the set of linker options used. 5824 5825 5826File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: LTO Testing, Up: Testsuites 5827 58287.7 Support for testing `gcov' 5829============================== 5830 5831Language-independent support for testing `gcov', and for checking that 5832branch profiling produces expected values, is provided by the expect 5833file `lib/gcov.exp'. `gcov' tests also rely on procedures in 5834`lib/gcc-dg.exp' to compile and run the test program. A typical `gcov' 5835test contains the following DejaGnu commands within comments: 5836 5837 { dg-options "-fprofile-arcs -ftest-coverage" } 5838 { dg-do run { target native } } 5839 { dg-final { run-gcov sourcefile } } 5840 5841 Checks of `gcov' output can include line counts, branch percentages, 5842and call return percentages. All of these checks are requested via 5843commands that appear in comments in the test's source file. Commands 5844to check line counts are processed by default. Commands to check 5845branch percentages and call return percentages are processed if the 5846`run-gcov' command has arguments `branches' or `calls', respectively. 5847For example, the following specifies checking both, as well as passing 5848`-b' to `gcov': 5849 5850 { dg-final { run-gcov branches calls { -b sourcefile } } } 5851 5852 A line count command appears within a comment on the source line that 5853is expected to get the specified count and has the form `count(CNT)'. 5854A test should only check line counts for lines that will get the same 5855count for any architecture. 5856 5857 Commands to check branch percentages (`branch') and call return 5858percentages (`returns') are very similar to each other. A beginning 5859command appears on or before the first of a range of lines that will 5860report the percentage, and the ending command follows that range of 5861lines. The beginning command can include a list of percentages, all of 5862which are expected to be found within the range. A range is terminated 5863by the next command of the same kind. A command `branch(end)' or 5864`returns(end)' marks the end of a range without starting a new one. 5865For example: 5866 5867 if (i > 10 && j > i && j < 20) /* branch(27 50 75) */ 5868 /* branch(end) */ 5869 foo (i, j); 5870 5871 For a call return percentage, the value specified is the percentage of 5872calls reported to return. For a branch percentage, the value is either 5873the expected percentage or 100 minus that value, since the direction of 5874a branch can differ depending on the target or the optimization level. 5875 5876 Not all branches and calls need to be checked. A test should not 5877check for branches that might be optimized away or replaced with 5878predicated instructions. Don't check for calls inserted by the 5879compiler or ones that might be inlined or optimized away. 5880 5881 A single test can check for combinations of line counts, branch 5882percentages, and call return percentages. The command to check a line 5883count must appear on the line that will report that count, but commands 5884to check branch percentages and call return percentages can bracket the 5885lines that report them. 5886 5887 5888File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites 5889 58907.8 Support for testing profile-directed optimizations 5891====================================================== 5892 5893The file `profopt.exp' provides language-independent support for 5894checking correct execution of a test built with profile-directed 5895optimization. This testing requires that a test program be built and 5896executed twice. The first time it is compiled to generate profile 5897data, and the second time it is compiled to use the data that was 5898generated during the first execution. The second execution is to 5899verify that the test produces the expected results. 5900 5901 To check that the optimization actually generated better code, a test 5902can be built and run a third time with normal optimizations to verify 5903that the performance is better with the profile-directed optimizations. 5904`profopt.exp' has the beginnings of this kind of support. 5905 5906 `profopt.exp' provides generic support for profile-directed 5907optimizations. Each set of tests that uses it provides information 5908about a specific optimization: 5909 5910`tool' 5911 tool being tested, e.g., `gcc' 5912 5913`profile_option' 5914 options used to generate profile data 5915 5916`feedback_option' 5917 options used to optimize using that profile data 5918 5919`prof_ext' 5920 suffix of profile data files 5921 5922`PROFOPT_OPTIONS' 5923 list of options with which to run each test, similar to the lists 5924 for torture tests 5925 5926`{ dg-final-generate { LOCAL-DIRECTIVE } }' 5927 This directive is similar to `dg-final', but the LOCAL-DIRECTIVE 5928 is run after the generation of profile data. 5929 5930`{ dg-final-use { LOCAL-DIRECTIVE } }' 5931 The LOCAL-DIRECTIVE is run after the profile data have been used. 5932 5933 5934File: gccint.info, Node: compat Testing, Next: Torture Tests, Prev: profopt Testing, Up: Testsuites 5935 59367.9 Support for testing binary compatibility 5937============================================ 5938 5939The file `compat.exp' provides language-independent support for binary 5940compatibility testing. It supports testing interoperability of two 5941compilers that follow the same ABI, or of multiple sets of compiler 5942options that should not affect binary compatibility. It is intended to 5943be used for testsuites that complement ABI testsuites. 5944 5945 A test supported by this framework has three parts, each in a separate 5946source file: a main program and two pieces that interact with each 5947other to split up the functionality being tested. 5948 5949`TESTNAME_main.SUFFIX' 5950 Contains the main program, which calls a function in file 5951 `TESTNAME_x.SUFFIX'. 5952 5953`TESTNAME_x.SUFFIX' 5954 Contains at least one call to a function in `TESTNAME_y.SUFFIX'. 5955 5956`TESTNAME_y.SUFFIX' 5957 Shares data with, or gets arguments from, `TESTNAME_x.SUFFIX'. 5958 5959 Within each test, the main program and one functional piece are 5960compiled by the GCC under test. The other piece can be compiled by an 5961alternate compiler. If no alternate compiler is specified, then all 5962three source files are all compiled by the GCC under test. You can 5963specify pairs of sets of compiler options. The first element of such a 5964pair specifies options used with the GCC under test, and the second 5965element of the pair specifies options used with the alternate compiler. 5966Each test is compiled with each pair of options. 5967 5968 `compat.exp' defines default pairs of compiler options. These can be 5969overridden by defining the environment variable `COMPAT_OPTIONS' as: 5970 5971 COMPAT_OPTIONS="[list [list {TST1} {ALT1}] 5972 ...[list {TSTN} {ALTN}]]" 5973 5974 where TSTI and ALTI are lists of options, with TSTI used by the 5975compiler under test and ALTI used by the alternate compiler. For 5976example, with `[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]', 5977the test is first built with `-g -O0' by the compiler under test and 5978with `-O3' by the alternate compiler. The test is built a second time 5979using `-fpic' by the compiler under test and `-fPIC -O2' by the 5980alternate compiler. 5981 5982 An alternate compiler is specified by defining an environment variable 5983to be the full pathname of an installed compiler; for C define 5984`ALT_CC_UNDER_TEST', and for C++ define `ALT_CXX_UNDER_TEST'. These 5985will be written to the `site.exp' file used by DejaGnu. The default is 5986to build each test with the compiler under test using the first of each 5987pair of compiler options from `COMPAT_OPTIONS'. When 5988`ALT_CC_UNDER_TEST' or `ALT_CXX_UNDER_TEST' is `same', each test is 5989built using the compiler under test but with combinations of the 5990options from `COMPAT_OPTIONS'. 5991 5992 To run only the C++ compatibility suite using the compiler under test 5993and another version of GCC using specific compiler options, do the 5994following from `OBJDIR/gcc': 5995 5996 rm site.exp 5997 make -k \ 5998 ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \ 5999 COMPAT_OPTIONS="LISTS AS SHOWN ABOVE" \ 6000 check-c++ \ 6001 RUNTESTFLAGS="compat.exp" 6002 6003 A test that fails when the source files are compiled with different 6004compilers, but passes when the files are compiled with the same 6005compiler, demonstrates incompatibility of the generated code or runtime 6006support. A test that fails for the alternate compiler but passes for 6007the compiler under test probably tests for a bug that was fixed in the 6008compiler under test but is present in the alternate compiler. 6009 6010 The binary compatibility tests support a small number of test framework 6011commands that appear within comments in a test file. 6012 6013`dg-require-*' 6014 These commands can be used in `TESTNAME_main.SUFFIX' to skip the 6015 test if specific support is not available on the target. 6016 6017`dg-options' 6018 The specified options are used for compiling this particular source 6019 file, appended to the options from `COMPAT_OPTIONS'. When this 6020 command appears in `TESTNAME_main.SUFFIX' the options are also 6021 used to link the test program. 6022 6023`dg-xfail-if' 6024 This command can be used in a secondary source file to specify that 6025 compilation is expected to fail for particular options on 6026 particular targets. 6027 6028 6029File: gccint.info, Node: Torture Tests, Prev: compat Testing, Up: Testsuites 6030 60317.10 Support for torture testing using multiple options 6032======================================================= 6033 6034Throughout the compiler testsuite there are several directories whose 6035tests are run multiple times, each with a different set of options. 6036These are known as torture tests. `lib/torture-options.exp' defines 6037procedures to set up these lists: 6038 6039`torture-init' 6040 Initialize use of torture lists. 6041 6042`set-torture-options' 6043 Set lists of torture options to use for tests with and without 6044 loops. Optionally combine a set of torture options with a set of 6045 other options, as is done with Objective-C runtime options. 6046 6047`torture-finish' 6048 Finalize use of torture lists. 6049 6050 The `.exp' file for a set of tests that use torture options must 6051include calls to these three procedures if: 6052 6053 * It calls `gcc-dg-runtest' and overrides DG_TORTURE_OPTIONS. 6054 6055 * It calls ${TOOL}`-torture' or ${TOOL}`-torture-execute', where 6056 TOOL is `c', `fortran', or `objc'. 6057 6058 * It calls `dg-pch'. 6059 6060 It is not necessary for a `.exp' file that calls `gcc-dg-runtest' to 6061call the torture procedures if the tests should use the list in 6062DG_TORTURE_OPTIONS defined in `gcc-dg.exp'. 6063 6064 Most uses of torture options can override the default lists by defining 6065TORTURE_OPTIONS or add to the default list by defining 6066ADDITIONAL_TORTURE_OPTIONS. Define these in a `.dejagnurc' file or add 6067them to the `site.exp' file; for example 6068 6069 set ADDITIONAL_TORTURE_OPTIONS [list \ 6070 { -O2 -ftree-loop-linear } \ 6071 { -O2 -fpeel-loops } ] 6072 6073 6074File: gccint.info, Node: Options, Next: Passes, Prev: Testsuites, Up: Top 6075 60768 Option specification files 6077**************************** 6078 6079Most GCC command-line options are described by special option 6080definition files, the names of which conventionally end in `.opt'. 6081This chapter describes the format of these files. 6082 6083* Menu: 6084 6085* Option file format:: The general layout of the files 6086* Option properties:: Supported option properties 6087 6088 6089File: gccint.info, Node: Option file format, Next: Option properties, Up: Options 6090 60918.1 Option file format 6092====================== 6093 6094Option files are a simple list of records in which each field occupies 6095its own line and in which the records themselves are separated by blank 6096lines. Comments may appear on their own line anywhere within the file 6097and are preceded by semicolons. Whitespace is allowed before the 6098semicolon. 6099 6100 The files can contain the following types of record: 6101 6102 * A language definition record. These records have two fields: the 6103 string `Language' and the name of the language. Once a language 6104 has been declared in this way, it can be used as an option 6105 property. *Note Option properties::. 6106 6107 * A target specific save record to save additional information. These 6108 records have two fields: the string `TargetSave', and a 6109 declaration type to go in the `cl_target_option' structure. 6110 6111 * A variable record to define a variable used to store option 6112 information. These records have two fields: the string 6113 `Variable', and a declaration of the type and name of the 6114 variable, optionally with an initializer (but without any trailing 6115 `;'). These records may be used for variables used for many 6116 options where declaring the initializer in a single option 6117 definition record, or duplicating it in many records, would be 6118 inappropriate, or for variables set in option handlers rather than 6119 referenced by `Var' properties. 6120 6121 * A variable record to define a variable used to store option 6122 information. These records have two fields: the string 6123 `TargetVariable', and a declaration of the type and name of the 6124 variable, optionally with an initializer (but without any trailing 6125 `;'). `TargetVariable' is a combination of `Variable' and 6126 `TargetSave' records in that the variable is defined in the 6127 `gcc_options' structure, but these variables are also stored in 6128 the `cl_target_option' structure. The variables are saved in the 6129 target save code and restored in the target restore code. 6130 6131 * A variable record to record any additional files that the 6132 `options.h' file should include. This is useful to provide 6133 enumeration or structure definitions needed for target variables. 6134 These records have two fields: the string `HeaderInclude' and the 6135 name of the include file. 6136 6137 * A variable record to record any additional files that the 6138 `options.c' or `options-save.c' file should include. This is 6139 useful to provide inline functions needed for target variables 6140 and/or `#ifdef' sequences to properly set up the initialization. 6141 These records have two fields: the string `SourceInclude' and the 6142 name of the include file. 6143 6144 * An enumeration record to define a set of strings that may be used 6145 as arguments to an option or options. These records have three 6146 fields: the string `Enum', a space-separated list of properties 6147 and help text used to describe the set of strings in `--help' 6148 output. Properties use the same format as option properties; the 6149 following are valid: 6150 `Name(NAME)' 6151 This property is required; NAME must be a name (suitable for 6152 use in C identifiers) used to identify the set of strings in 6153 `Enum' option properties. 6154 6155 `Type(TYPE)' 6156 This property is required; TYPE is the C type for variables 6157 set by options using this enumeration together with `Var'. 6158 6159 `UnknownError(MESSAGE)' 6160 The message MESSAGE will be used as an error message if the 6161 argument is invalid; for enumerations without `UnknownError', 6162 a generic error message is used. MESSAGE should contain a 6163 single `%qs' format, which will be used to format the invalid 6164 argument. 6165 6166 * An enumeration value record to define one of the strings in a set 6167 given in an `Enum' record. These records have two fields: the 6168 string `EnumValue' and a space-separated list of properties. 6169 Properties use the same format as option properties; the following 6170 are valid: 6171 `Enum(NAME)' 6172 This property is required; NAME says which `Enum' record this 6173 `EnumValue' record corresponds to. 6174 6175 `String(STRING)' 6176 This property is required; STRING is the string option 6177 argument being described by this record. 6178 6179 `Value(VALUE)' 6180 This property is required; it says what value (representable 6181 as `int') should be used for the given string. 6182 6183 `Canonical' 6184 This property is optional. If present, it says the present 6185 string is the canonical one among all those with the given 6186 value. Other strings yielding that value will be mapped to 6187 this one so specs do not need to handle them. 6188 6189 `DriverOnly' 6190 This property is optional. If present, the present string 6191 will only be accepted by the driver. This is used for cases 6192 such as `-march=native' that are processed by the driver so 6193 that `gcc -v' shows how the options chosen depended on the 6194 system on which the compiler was run. 6195 6196 * An option definition record. These records have the following 6197 fields: 6198 1. the name of the option, with the leading "-" removed 6199 6200 2. a space-separated list of option properties (*note Option 6201 properties::) 6202 6203 3. the help text to use for `--help' (omitted if the second field 6204 contains the `Undocumented' property). 6205 6206 By default, all options beginning with "f", "W" or "m" are 6207 implicitly assumed to take a "no-" form. This form should not be 6208 listed separately. If an option beginning with one of these 6209 letters does not have a "no-" form, you can use the 6210 `RejectNegative' property to reject it. 6211 6212 The help text is automatically line-wrapped before being displayed. 6213 Normally the name of the option is printed on the left-hand side of 6214 the output and the help text is printed on the right. However, if 6215 the help text contains a tab character, the text to the left of 6216 the tab is used instead of the option's name and the text to the 6217 right of the tab forms the help text. This allows you to 6218 elaborate on what type of argument the option takes. 6219 6220 * A target mask record. These records have one field of the form 6221 `Mask(X)'. The options-processing script will automatically 6222 allocate a bit in `target_flags' (*note Run-time Target::) for 6223 each mask name X and set the macro `MASK_X' to the appropriate 6224 bitmask. It will also declare a `TARGET_X' macro that has the 6225 value 1 when bit `MASK_X' is set and 0 otherwise. 6226 6227 They are primarily intended to declare target masks that are not 6228 associated with user options, either because these masks represent 6229 internal switches or because the options are not available on all 6230 configurations and yet the masks always need to be defined. 6231 6232 6233File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options 6234 62358.2 Option properties 6236===================== 6237 6238The second field of an option record can specify any of the following 6239properties. When an option takes an argument, it is enclosed in 6240parentheses following the option property name. The parser that 6241handles option files is quite simplistic, and will be tricked by any 6242nested parentheses within the argument text itself; in this case, the 6243entire option argument can be wrapped in curly braces within the 6244parentheses to demarcate it, e.g.: 6245 6246 Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)}) 6247 6248`Common' 6249 The option is available for all languages and targets. 6250 6251`Target' 6252 The option is available for all languages but is target-specific. 6253 6254`Driver' 6255 The option is handled by the compiler driver using code not shared 6256 with the compilers proper (`cc1' etc.). 6257 6258`LANGUAGE' 6259 The option is available when compiling for the given language. 6260 6261 It is possible to specify several different languages for the same 6262 option. Each LANGUAGE must have been declared by an earlier 6263 `Language' record. *Note Option file format::. 6264 6265`RejectDriver' 6266 The option is only handled by the compilers proper (`cc1' etc.) 6267 and should not be accepted by the driver. 6268 6269`RejectNegative' 6270 The option does not have a "no-" form. All options beginning with 6271 "f", "W" or "m" are assumed to have a "no-" form unless this 6272 property is used. 6273 6274`Negative(OTHERNAME)' 6275 The option will turn off another option OTHERNAME, which is the 6276 option name with the leading "-" removed. This chain action will 6277 propagate through the `Negative' property of the option to be 6278 turned off. 6279 6280 As a consequence, if you have a group of mutually-exclusive 6281 options, their `Negative' properties should form a circular chain. 6282 For example, if options `-A', `-B' and `-C' are mutually 6283 exclusive, their respective `Negative' properties should be 6284 `Negative(B)', `Negative(C)' and `Negative(A)'. 6285 6286`Joined' 6287`Separate' 6288 The option takes a mandatory argument. `Joined' indicates that 6289 the option and argument can be included in the same `argv' entry 6290 (as with `-mflush-func=NAME', for example). `Separate' indicates 6291 that the option and argument can be separate `argv' entries (as 6292 with `-o'). An option is allowed to have both of these properties. 6293 6294`JoinedOrMissing' 6295 The option takes an optional argument. If the argument is given, 6296 it will be part of the same `argv' entry as the option itself. 6297 6298 This property cannot be used alongside `Joined' or `Separate'. 6299 6300`MissingArgError(MESSAGE)' 6301 For an option marked `Joined' or `Separate', the message MESSAGE 6302 will be used as an error message if the mandatory argument is 6303 missing; for options without `MissingArgError', a generic error 6304 message is used. MESSAGE should contain a single `%qs' format, 6305 which will be used to format the name of the option passed. 6306 6307`Args(N)' 6308 For an option marked `Separate', indicate that it takes N 6309 arguments. The default is 1. 6310 6311`UInteger' 6312 The option's argument is a non-negative integer. The option parser 6313 will check and convert the argument before passing it to the 6314 relevant option handler. `UInteger' should also be used on 6315 options like `-falign-loops' where both `-falign-loops' and 6316 `-falign-loops'=N are supported to make sure the saved options are 6317 given a full integer. 6318 6319`ToLower' 6320 The option's argument should be converted to lowercase as part of 6321 putting it in canonical form, and before comparing with the strings 6322 indicated by any `Enum' property. 6323 6324`NoDriverArg' 6325 For an option marked `Separate', the option only takes an argument 6326 in the compiler proper, not in the driver. This is for 6327 compatibility with existing options that are used both directly and 6328 via `-Wp,'; new options should not have this property. 6329 6330`Var(VAR)' 6331 The state of this option should be stored in variable VAR 6332 (actually a macro for `global_options.x_VAR'). The way that the 6333 state is stored depends on the type of option: 6334 6335 * If the option uses the `Mask' or `InverseMask' properties, 6336 VAR is the integer variable that contains the mask. 6337 6338 * If the option is a normal on/off switch, VAR is an integer 6339 variable that is nonzero when the option is enabled. The 6340 options parser will set the variable to 1 when the positive 6341 form of the option is used and 0 when the "no-" form is used. 6342 6343 * If the option takes an argument and has the `UInteger' 6344 property, VAR is an integer variable that stores the value of 6345 the argument. 6346 6347 * If the option takes an argument and has the `Enum' property, 6348 VAR is a variable (type given in the `Type' property of the 6349 `Enum' record whose `Name' property has the same argument as 6350 the `Enum' property of this option) that stores the value of 6351 the argument. 6352 6353 * If the option has the `Defer' property, VAR is a pointer to a 6354 `VEC(cl_deferred_option,heap)' that stores the option for 6355 later processing. (VAR is declared with type `void *' and 6356 needs to be cast to `VEC(cl_deferred_option,heap)' before 6357 use.) 6358 6359 * Otherwise, if the option takes an argument, VAR is a pointer 6360 to the argument string. The pointer will be null if the 6361 argument is optional and wasn't given. 6362 6363 The option-processing script will usually zero-initialize VAR. 6364 You can modify this behavior using `Init'. 6365 6366`Var(VAR, SET)' 6367 The option controls an integer variable VAR and is active when VAR 6368 equals SET. The option parser will set VAR to SET when the 6369 positive form of the option is used and `!SET' when the "no-" form 6370 is used. 6371 6372 VAR is declared in the same way as for the single-argument form 6373 described above. 6374 6375`Init(VALUE)' 6376 The variable specified by the `Var' property should be statically 6377 initialized to VALUE. If more than one option using the same 6378 variable specifies `Init', all must specify the same initializer. 6379 6380`Mask(NAME)' 6381 The option is associated with a bit in the `target_flags' variable 6382 (*note Run-time Target::) and is active when that bit is set. You 6383 may also specify `Var' to select a variable other than 6384 `target_flags'. 6385 6386 The options-processing script will automatically allocate a unique 6387 bit for the option. If the option is attached to `target_flags', 6388 the script will set the macro `MASK_NAME' to the appropriate 6389 bitmask. It will also declare a `TARGET_NAME' macro that has the 6390 value 1 when the option is active and 0 otherwise. If you use 6391 `Var' to attach the option to a different variable, the bitmask 6392 macro with be called `OPTION_MASK_NAME'. 6393 6394`InverseMask(OTHERNAME)' 6395`InverseMask(OTHERNAME, THISNAME)' 6396 The option is the inverse of another option that has the 6397 `Mask(OTHERNAME)' property. If THISNAME is given, the 6398 options-processing script will declare a `TARGET_THISNAME' macro 6399 that is 1 when the option is active and 0 otherwise. 6400 6401`Enum(NAME)' 6402 The option's argument is a string from the set of strings 6403 associated with the corresponding `Enum' record. The string is 6404 checked and converted to the integer specified in the corresponding 6405 `EnumValue' record before being passed to option handlers. 6406 6407`Defer' 6408 The option should be stored in a vector, specified with `Var', for 6409 later processing. 6410 6411`Alias(OPT)' 6412`Alias(OPT, ARG)' 6413`Alias(OPT, POSARG, NEGARG)' 6414 The option is an alias for `-OPT' (or the negative form of that 6415 option, depending on `NegativeAlias'). In the first form, any 6416 argument passed to the alias is considered to be passed to `-OPT', 6417 and `-OPT' is considered to be negated if the alias is used in 6418 negated form. In the second form, the alias may not be negated or 6419 have an argument, and POSARG is considered to be passed as an 6420 argument to `-OPT'. In the third form, the alias may not have an 6421 argument, if the alias is used in the positive form then POSARG is 6422 considered to be passed to `-OPT', and if the alias is used in the 6423 negative form then NEGARG is considered to be passed to `-OPT'. 6424 6425 Aliases should not specify `Var' or `Mask' or `UInteger'. Aliases 6426 should normally specify the same languages as the target of the 6427 alias; the flags on the target will be used to determine any 6428 diagnostic for use of an option for the wrong language, while 6429 those on the alias will be used to identify what command-line text 6430 is the option and what text is any argument to that option. 6431 6432 When an `Alias' definition is used for an option, driver specs do 6433 not need to handle it and no `OPT_' enumeration value is defined 6434 for it; only the canonical form of the option will be seen in those 6435 places. 6436 6437`NegativeAlias' 6438 For an option marked with `Alias(OPT)', the option is considered 6439 to be an alias for the positive form of `-OPT' if negated and for 6440 the negative form of `-OPT' if not negated. `NegativeAlias' may 6441 not be used with the forms of `Alias' taking more than one 6442 argument. 6443 6444`Ignore' 6445 This option is ignored apart from printing any warning specified 6446 using `Warn'. The option will not be seen by specs and no `OPT_' 6447 enumeration value is defined for it. 6448 6449`SeparateAlias' 6450 For an option marked with `Joined', `Separate' and `Alias', the 6451 option only acts as an alias when passed a separate argument; with 6452 a joined argument it acts as a normal option, with an `OPT_' 6453 enumeration value. This is for compatibility with the Java `-d' 6454 option and should not be used for new options. 6455 6456`Warn(MESSAGE)' 6457 If this option is used, output the warning MESSAGE. MESSAGE is a 6458 format string, either taking a single operand with a `%qs' format 6459 which is the option name, or not taking any operands, which is 6460 passed to the `warning' function. If an alias is marked `Warn', 6461 the target of the alias must not also be marked `Warn'. 6462 6463`Report' 6464 The state of the option should be printed by `-fverbose-asm'. 6465 6466`Warning' 6467 This is a warning option and should be shown as such in `--help' 6468 output. This flag does not currently affect anything other than 6469 `--help'. 6470 6471`Optimization' 6472 This is an optimization option. It should be shown as such in 6473 `--help' output, and any associated variable named using `Var' 6474 should be saved and restored when the optimization level is 6475 changed with `optimize' attributes. 6476 6477`Undocumented' 6478 The option is deliberately missing documentation and should not be 6479 included in the `--help' output. 6480 6481`Condition(COND)' 6482 The option should only be accepted if preprocessor condition COND 6483 is true. Note that any C declarations associated with the option 6484 will be present even if COND is false; COND simply controls 6485 whether the option is accepted and whether it is printed in the 6486 `--help' output. 6487 6488`Save' 6489 Build the `cl_target_option' structure to hold a copy of the 6490 option, add the functions `cl_target_option_save' and 6491 `cl_target_option_restore' to save and restore the options. 6492 6493`SetByCombined' 6494 The option may also be set by a combined option such as 6495 `-ffast-math'. This causes the `gcc_options' struct to have a 6496 field `frontend_set_NAME', where `NAME' is the name of the field 6497 holding the value of this option (without the leading `x_'). This 6498 gives the front end a way to indicate that the value has been set 6499 explicitly and should not be changed by the combined option. For 6500 example, some front ends use this to prevent `-ffast-math' and 6501 `-fno-fast-math' from changing the value of `-fmath-errno' for 6502 languages that do not use `errno'. 6503 6504`EnabledBy(OPT)' 6505`EnabledBy(OPT || OPT2)' 6506`EnabledBy(OPT && OPT2)' 6507 If not explicitly set, the option is set to the value of `-OPT'; 6508 multiple options can be given, separated by `||'. The third form 6509 using `&&' specifies that the option is only set if both OPT and 6510 OPT2 are set. 6511 6512`LangEnabledBy(LANGUAGE, OPT)' 6513`LangEnabledBy(LANGUAGE, OPT, POSARG, NEGARG)' 6514 When compiling for the given language, the option is set to the 6515 value of `-OPT', if not explicitly set. OPT can be also a list of 6516 `||' separated options. In the second form, if OPT is used in the 6517 positive form then POSARG is considered to be passed to the 6518 option, and if OPT is used in the negative form then NEGARG is 6519 considered to be passed to the option. It is possible to specify 6520 several different languages. Each LANGUAGE must have been 6521 declared by an earlier `Language' record. *Note Option file 6522 format::. 6523 6524`NoDWARFRecord' 6525 The option is omitted from the producer string written by 6526 `-grecord-gcc-switches'. 6527 6528`PchIgnore' 6529 Even if this is a target option, this option will not be recorded 6530 / compared to determine if a precompiled header file matches. 6531 6532`CPP(VAR)' 6533 The state of this option should be kept in sync with the 6534 preprocessor option VAR. If this property is set, then properties 6535 `Var' and `Init' must be set as well. 6536 6537`CppReason(CPP_W_ENUM)' 6538 This warning option corresponds to `cpplib.h' warning reason code 6539 CPP_W_ENUM. This should only be used for warning options of the 6540 C-family front-ends. 6541 6542 6543 6544File: gccint.info, Node: Passes, Next: GENERIC, Prev: Options, Up: Top 6545 65469 Passes and Files of the Compiler 6547********************************** 6548 6549This chapter is dedicated to giving an overview of the optimization and 6550code generation passes of the compiler. In the process, it describes 6551some of the language front end interface, though this description is no 6552where near complete. 6553 6554* Menu: 6555 6556* Parsing pass:: The language front end turns text into bits. 6557* Cilk Plus Transformation:: Transform Cilk Plus Code to equivalent C/C++. 6558* Gimplification pass:: The bits are turned into something we can optimize. 6559* Pass manager:: Sequencing the optimization passes. 6560* Tree SSA passes:: Optimizations on a high-level representation. 6561* RTL passes:: Optimizations on a low-level representation. 6562* Optimization info:: Dumping optimization information from passes. 6563 6564 6565File: gccint.info, Node: Parsing pass, Next: Cilk Plus Transformation, Up: Passes 6566 65679.1 Parsing pass 6568================ 6569 6570The language front end is invoked only once, via 6571`lang_hooks.parse_file', to parse the entire input. The language front 6572end may use any intermediate language representation deemed 6573appropriate. The C front end uses GENERIC trees (*note GENERIC::), plus 6574a double handful of language specific tree codes defined in 6575`c-common.def'. The Fortran front end uses a completely different 6576private representation. 6577 6578 At some point the front end must translate the representation used in 6579the front end to a representation understood by the language-independent 6580portions of the compiler. Current practice takes one of two forms. 6581The C front end manually invokes the gimplifier (*note GIMPLE::) on 6582each function, and uses the gimplifier callbacks to convert the 6583language-specific tree nodes directly to GIMPLE before passing the 6584function off to be compiled. The Fortran front end converts from a 6585private representation to GENERIC, which is later lowered to GIMPLE 6586when the function is compiled. Which route to choose probably depends 6587on how well GENERIC (plus extensions) can be made to match up with the 6588source language and necessary parsing data structures. 6589 6590 BUG: Gimplification must occur before nested function lowering, and 6591nested function lowering must be done by the front end before passing 6592the data off to cgraph. 6593 6594 TODO: Cgraph should control nested function lowering. It would only 6595be invoked when it is certain that the outer-most function is used. 6596 6597 TODO: Cgraph needs a gimplify_function callback. It should be invoked 6598when (1) it is certain that the function is used, (2) warning flags 6599specified by the user require some amount of compilation in order to 6600honor, (3) the language indicates that semantic analysis is not 6601complete until gimplification occurs. Hum... this sounds overly 6602complicated. Perhaps we should just have the front end gimplify 6603always; in most cases it's only one function call. 6604 6605 The front end needs to pass all function definitions and top level 6606declarations off to the middle-end so that they can be compiled and 6607emitted to the object file. For a simple procedural language, it is 6608usually most convenient to do this as each top level declaration or 6609definition is seen. There is also a distinction to be made between 6610generating functional code and generating complete debug information. 6611The only thing that is absolutely required for functional code is that 6612function and data _definitions_ be passed to the middle-end. For 6613complete debug information, function, data and type declarations should 6614all be passed as well. 6615 6616 In any case, the front end needs each complete top-level function or 6617data declaration, and each data definition should be passed to 6618`rest_of_decl_compilation'. Each complete type definition should be 6619passed to `rest_of_type_compilation'. Each function definition should 6620be passed to `cgraph_finalize_function'. 6621 6622 TODO: I know rest_of_compilation currently has all sorts of RTL 6623generation semantics. I plan to move all code generation bits (both 6624Tree and RTL) to compile_function. Should we hide cgraph from the 6625front ends and move back to rest_of_compilation as the official 6626interface? Possibly we should rename all three interfaces such that 6627the names match in some meaningful way and that is more descriptive 6628than "rest_of". 6629 6630 The middle-end will, at its option, emit the function and data 6631definitions immediately or queue them for later processing. 6632 6633 6634File: gccint.info, Node: Cilk Plus Transformation, Next: Gimplification pass, Prev: Parsing pass, Up: Passes 6635 66369.2 Cilk Plus Transformation 6637============================ 6638 6639If Cilk Plus generation (flag `-fcilkplus') is enabled, all the Cilk 6640Plus code is transformed into equivalent C and C++ functions. Majority 6641of this transformation occurs toward the end of the parsing and right 6642before the gimplification pass. 6643 6644 These are the major components to the Cilk Plus language extension: 6645 * Array Notations: During parsing phase, all the array notation 6646 specific information is stored in `ARRAY_NOTATION_REF' tree using 6647 the function `c_parser_array_notation'. During the end of 6648 parsing, we check the entire function to see if there are any 6649 array notation specific code (using the function 6650 `contains_array_notation_expr'). If this function returns true, 6651 then we expand them using either `expand_array_notation_exprs' or 6652 `build_array_notation_expr'. For the cases where array notations 6653 are inside conditions, they are transformed using the function 6654 `fix_conditional_array_notations'. The C language-specific 6655 routines are located in `c/c-array-notation.c' and the equivalent 6656 C++ routines are in the file `cp/cp-array-notation.c'. Common 6657 routines such as functions to initialize built-in functions are 6658 stored in `array-notation-common.c'. 6659 6660 * Cilk keywords: 6661 * `_Cilk_spawn': The `_Cilk_spawn' keyword is parsed and the 6662 function it contains is marked as a spawning function. The 6663 spawning function is called the spawner. At the end of the 6664 parsing phase, appropriate built-in functions are added to 6665 the spawner that are defined in the Cilk runtime. The 6666 appropriate locations of these functions, and the internal 6667 structures are detailed in `cilk_init_builtins' in the file 6668 `cilk-common.c'. The pointers to Cilk functions and fields 6669 of internal structures are described in `cilk.h'. The 6670 built-in functions are described in `cilk-builtins.def'. 6671 6672 During gimplification, a new "spawn-helper" function is 6673 created. The spawned function is replaced with a spawn 6674 helper function in the spawner. The spawned function-call is 6675 moved into the spawn helper. The main function that does 6676 these transformations is `gimplify_cilk_spawn' in 6677 `c-family/cilk.c'. In the spawn-helper, the gimplification 6678 function `gimplify_call_expr', inserts a function call 6679 `__cilkrts_detach'. This function is expanded by 6680 `builtin_expand_cilk_detach' located in `c-family/cilk.c'. 6681 6682 * `_Cilk_sync': `_Cilk_sync' is parsed like a keyword. During 6683 gimplification, the function `gimplify_cilk_sync' in 6684 `c-family/cilk.c', will replace this keyword with a set of 6685 functions that are stored in the Cilk runtime. One of the 6686 internal functions inserted during gimplification, 6687 `__cilkrts_pop_frame' must be expanded by the compiler and is 6688 done by `builtin_expand_cilk_pop_frame' in `cilk-common.c'. 6689 6690 6691 Documentation about Cilk Plus and language specification is provided 6692under the "Learn" section in `http://www.cilkplus.org/'. It is worth 6693mentioning that the current implementation follows ABI 1.1. 6694 6695 6696File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Cilk Plus Transformation, Up: Passes 6697 66989.3 Gimplification pass 6699======================= 6700 6701"Gimplification" is a whimsical term for the process of converting the 6702intermediate representation of a function into the GIMPLE language 6703(*note GIMPLE::). The term stuck, and so words like "gimplification", 6704"gimplify", "gimplifier" and the like are sprinkled throughout this 6705section of code. 6706 6707 While a front end may certainly choose to generate GIMPLE directly if 6708it chooses, this can be a moderately complex process unless the 6709intermediate language used by the front end is already fairly simple. 6710Usually it is easier to generate GENERIC trees plus extensions and let 6711the language-independent gimplifier do most of the work. 6712 6713 The main entry point to this pass is `gimplify_function_tree' located 6714in `gimplify.c'. From here we process the entire function gimplifying 6715each statement in turn. The main workhorse for this pass is 6716`gimplify_expr'. Approximately everything passes through here at least 6717once, and it is from here that we invoke the `lang_hooks.gimplify_expr' 6718callback. 6719 6720 The callback should examine the expression in question and return 6721`GS_UNHANDLED' if the expression is not a language specific construct 6722that requires attention. Otherwise it should alter the expression in 6723some way to such that forward progress is made toward producing valid 6724GIMPLE. If the callback is certain that the transformation is complete 6725and the expression is valid GIMPLE, it should return `GS_ALL_DONE'. 6726Otherwise it should return `GS_OK', which will cause the expression to 6727be processed again. If the callback encounters an error during the 6728transformation (because the front end is relying on the gimplification 6729process to finish semantic checks), it should return `GS_ERROR'. 6730 6731 6732File: gccint.info, Node: Pass manager, Next: Tree SSA passes, Prev: Gimplification pass, Up: Passes 6733 67349.4 Pass manager 6735================ 6736 6737The pass manager is located in `passes.c', `tree-optimize.c' and 6738`tree-pass.h'. It processes passes as described in `passes.def'. Its 6739job is to run all of the individual passes in the correct order, and 6740take care of standard bookkeeping that applies to every pass. 6741 6742 The theory of operation is that each pass defines a structure that 6743represents everything we need to know about that pass--when it should 6744be run, how it should be run, what intermediate language form or 6745on-the-side data structures it needs. We register the pass to be run 6746in some particular order, and the pass manager arranges for everything 6747to happen in the correct order. 6748 6749 The actuality doesn't completely live up to the theory at present. 6750Command-line switches and `timevar_id_t' enumerations must still be 6751defined elsewhere. The pass manager validates constraints but does not 6752attempt to (re-)generate data structures or lower intermediate language 6753form based on the requirements of the next pass. Nevertheless, what is 6754present is useful, and a far sight better than nothing at all. 6755 6756 Each pass should have a unique name. Each pass may have its own dump 6757file (for GCC debugging purposes). Passes with a name starting with a 6758star do not dump anything. Sometimes passes are supposed to share a 6759dump file / option name. To still give these unique names, you can use 6760a prefix that is delimited by a space from the part that is used for 6761the dump file / option name. E.g. When the pass name is "ud dce", the 6762name used for dump file/options is "dce". 6763 6764 TODO: describe the global variables set up by the pass manager, and a 6765brief description of how a new pass should use it. I need to look at 6766what info RTL passes use first... 6767 6768 6769File: gccint.info, Node: Tree SSA passes, Next: RTL passes, Prev: Pass manager, Up: Passes 6770 67719.5 Tree SSA passes 6772=================== 6773 6774The following briefly describes the Tree optimization passes that are 6775run after gimplification and what source files they are located in. 6776 6777 * Remove useless statements 6778 6779 This pass is an extremely simple sweep across the gimple code in 6780 which we identify obviously dead code and remove it. Here we do 6781 things like simplify `if' statements with constant conditions, 6782 remove exception handling constructs surrounding code that 6783 obviously cannot throw, remove lexical bindings that contain no 6784 variables, and other assorted simplistic cleanups. The idea is to 6785 get rid of the obvious stuff quickly rather than wait until later 6786 when it's more work to get rid of it. This pass is located in 6787 `tree-cfg.c' and described by `pass_remove_useless_stmts'. 6788 6789 * OpenMP lowering 6790 6791 If OpenMP generation (`-fopenmp') is enabled, this pass lowers 6792 OpenMP constructs into GIMPLE. 6793 6794 Lowering of OpenMP constructs involves creating replacement 6795 expressions for local variables that have been mapped using data 6796 sharing clauses, exposing the control flow of most synchronization 6797 directives and adding region markers to facilitate the creation of 6798 the control flow graph. The pass is located in `omp-low.c' and is 6799 described by `pass_lower_omp'. 6800 6801 * OpenMP expansion 6802 6803 If OpenMP generation (`-fopenmp') is enabled, this pass expands 6804 parallel regions into their own functions to be invoked by the 6805 thread library. The pass is located in `omp-low.c' and is 6806 described by `pass_expand_omp'. 6807 6808 * Lower control flow 6809 6810 This pass flattens `if' statements (`COND_EXPR') and moves lexical 6811 bindings (`BIND_EXPR') out of line. After this pass, all `if' 6812 statements will have exactly two `goto' statements in its `then' 6813 and `else' arms. Lexical binding information for each statement 6814 will be found in `TREE_BLOCK' rather than being inferred from its 6815 position under a `BIND_EXPR'. This pass is found in 6816 `gimple-low.c' and is described by `pass_lower_cf'. 6817 6818 * Lower exception handling control flow 6819 6820 This pass decomposes high-level exception handling constructs 6821 (`TRY_FINALLY_EXPR' and `TRY_CATCH_EXPR') into a form that 6822 explicitly represents the control flow involved. After this pass, 6823 `lookup_stmt_eh_region' will return a non-negative number for any 6824 statement that may have EH control flow semantics; examine 6825 `tree_can_throw_internal' or `tree_can_throw_external' for exact 6826 semantics. Exact control flow may be extracted from 6827 `foreach_reachable_handler'. The EH region nesting tree is defined 6828 in `except.h' and built in `except.c'. The lowering pass itself 6829 is in `tree-eh.c' and is described by `pass_lower_eh'. 6830 6831 * Build the control flow graph 6832 6833 This pass decomposes a function into basic blocks and creates all 6834 of the edges that connect them. It is located in `tree-cfg.c' and 6835 is described by `pass_build_cfg'. 6836 6837 * Find all referenced variables 6838 6839 This pass walks the entire function and collects an array of all 6840 variables referenced in the function, `referenced_vars'. The 6841 index at which a variable is found in the array is used as a UID 6842 for the variable within this function. This data is needed by the 6843 SSA rewriting routines. The pass is located in `tree-dfa.c' and 6844 is described by `pass_referenced_vars'. 6845 6846 * Enter static single assignment form 6847 6848 This pass rewrites the function such that it is in SSA form. After 6849 this pass, all `is_gimple_reg' variables will be referenced by 6850 `SSA_NAME', and all occurrences of other variables will be 6851 annotated with `VDEFS' and `VUSES'; PHI nodes will have been 6852 inserted as necessary for each basic block. This pass is located 6853 in `tree-ssa.c' and is described by `pass_build_ssa'. 6854 6855 * Warn for uninitialized variables 6856 6857 This pass scans the function for uses of `SSA_NAME's that are fed 6858 by default definition. For non-parameter variables, such uses are 6859 uninitialized. The pass is run twice, before and after 6860 optimization (if turned on). In the first pass we only warn for 6861 uses that are positively uninitialized; in the second pass we warn 6862 for uses that are possibly uninitialized. The pass is located in 6863 `tree-ssa.c' and is defined by `pass_early_warn_uninitialized' and 6864 `pass_late_warn_uninitialized'. 6865 6866 * Dead code elimination 6867 6868 This pass scans the function for statements without side effects 6869 whose result is unused. It does not do memory life analysis, so 6870 any value that is stored in memory is considered used. The pass 6871 is run multiple times throughout the optimization process. It is 6872 located in `tree-ssa-dce.c' and is described by `pass_dce'. 6873 6874 * Dominator optimizations 6875 6876 This pass performs trivial dominator-based copy and constant 6877 propagation, expression simplification, and jump threading. It is 6878 run multiple times throughout the optimization process. It is 6879 located in `tree-ssa-dom.c' and is described by `pass_dominator'. 6880 6881 * Forward propagation of single-use variables 6882 6883 This pass attempts to remove redundant computation by substituting 6884 variables that are used once into the expression that uses them and 6885 seeing if the result can be simplified. It is located in 6886 `tree-ssa-forwprop.c' and is described by `pass_forwprop'. 6887 6888 * Copy Renaming 6889 6890 This pass attempts to change the name of compiler temporaries 6891 involved in copy operations such that SSA->normal can coalesce the 6892 copy away. When compiler temporaries are copies of user 6893 variables, it also renames the compiler temporary to the user 6894 variable resulting in better use of user symbols. It is located 6895 in `tree-ssa-copyrename.c' and is described by `pass_copyrename'. 6896 6897 * PHI node optimizations 6898 6899 This pass recognizes forms of PHI inputs that can be represented as 6900 conditional expressions and rewrites them into straight line code. 6901 It is located in `tree-ssa-phiopt.c' and is described by 6902 `pass_phiopt'. 6903 6904 * May-alias optimization 6905 6906 This pass performs a flow sensitive SSA-based points-to analysis. 6907 The resulting may-alias, must-alias, and escape analysis 6908 information is used to promote variables from in-memory 6909 addressable objects to non-aliased variables that can be renamed 6910 into SSA form. We also update the `VDEF'/`VUSE' memory tags for 6911 non-renameable aggregates so that we get fewer false kills. The 6912 pass is located in `tree-ssa-alias.c' and is described by 6913 `pass_may_alias'. 6914 6915 Interprocedural points-to information is located in 6916 `tree-ssa-structalias.c' and described by `pass_ipa_pta'. 6917 6918 * Profiling 6919 6920 This pass instruments the function in order to collect runtime 6921 block and value profiling data. Such data may be fed back into 6922 the compiler on a subsequent run so as to allow optimization based 6923 on expected execution frequencies. The pass is located in 6924 `tree-profile.c' and is described by `pass_ipa_tree_profile'. 6925 6926 * Static profile estimation 6927 6928 This pass implements series of heuristics to guess propababilities 6929 of branches. The resulting predictions are turned into edge 6930 profile by propagating branches across the control flow graphs. 6931 The pass is located in `tree-profile.c' and is described by 6932 `pass_profile'. 6933 6934 * Lower complex arithmetic 6935 6936 This pass rewrites complex arithmetic operations into their 6937 component scalar arithmetic operations. The pass is located in 6938 `tree-complex.c' and is described by `pass_lower_complex'. 6939 6940 * Scalar replacement of aggregates 6941 6942 This pass rewrites suitable non-aliased local aggregate variables 6943 into a set of scalar variables. The resulting scalar variables are 6944 rewritten into SSA form, which allows subsequent optimization 6945 passes to do a significantly better job with them. The pass is 6946 located in `tree-sra.c' and is described by `pass_sra'. 6947 6948 * Dead store elimination 6949 6950 This pass eliminates stores to memory that are subsequently 6951 overwritten by another store, without any intervening loads. The 6952 pass is located in `tree-ssa-dse.c' and is described by `pass_dse'. 6953 6954 * Tail recursion elimination 6955 6956 This pass transforms tail recursion into a loop. It is located in 6957 `tree-tailcall.c' and is described by `pass_tail_recursion'. 6958 6959 * Forward store motion 6960 6961 This pass sinks stores and assignments down the flowgraph closer 6962 to their use point. The pass is located in `tree-ssa-sink.c' and 6963 is described by `pass_sink_code'. 6964 6965 * Partial redundancy elimination 6966 6967 This pass eliminates partially redundant computations, as well as 6968 performing load motion. The pass is located in `tree-ssa-pre.c' 6969 and is described by `pass_pre'. 6970 6971 Just before partial redundancy elimination, if 6972 `-funsafe-math-optimizations' is on, GCC tries to convert 6973 divisions to multiplications by the reciprocal. The pass is 6974 located in `tree-ssa-math-opts.c' and is described by 6975 `pass_cse_reciprocal'. 6976 6977 * Full redundancy elimination 6978 6979 This is a simpler form of PRE that only eliminates redundancies 6980 that occur on all paths. It is located in `tree-ssa-pre.c' and 6981 described by `pass_fre'. 6982 6983 * Loop optimization 6984 6985 The main driver of the pass is placed in `tree-ssa-loop.c' and 6986 described by `pass_loop'. 6987 6988 The optimizations performed by this pass are: 6989 6990 Loop invariant motion. This pass moves only invariants that would 6991 be hard to handle on RTL level (function calls, operations that 6992 expand to nontrivial sequences of insns). With `-funswitch-loops' 6993 it also moves operands of conditions that are invariant out of the 6994 loop, so that we can use just trivial invariantness analysis in 6995 loop unswitching. The pass also includes store motion. The pass 6996 is implemented in `tree-ssa-loop-im.c'. 6997 6998 Canonical induction variable creation. This pass creates a simple 6999 counter for number of iterations of the loop and replaces the exit 7000 condition of the loop using it, in case when a complicated 7001 analysis is necessary to determine the number of iterations. 7002 Later optimizations then may determine the number easily. The 7003 pass is implemented in `tree-ssa-loop-ivcanon.c'. 7004 7005 Induction variable optimizations. This pass performs standard 7006 induction variable optimizations, including strength reduction, 7007 induction variable merging and induction variable elimination. 7008 The pass is implemented in `tree-ssa-loop-ivopts.c'. 7009 7010 Loop unswitching. This pass moves the conditional jumps that are 7011 invariant out of the loops. To achieve this, a duplicate of the 7012 loop is created for each possible outcome of conditional jump(s). 7013 The pass is implemented in `tree-ssa-loop-unswitch.c'. 7014 7015 The optimizations also use various utility functions contained in 7016 `tree-ssa-loop-manip.c', `cfgloop.c', `cfgloopanal.c' and 7017 `cfgloopmanip.c'. 7018 7019 Vectorization. This pass transforms loops to operate on vector 7020 types instead of scalar types. Data parallelism across loop 7021 iterations is exploited to group data elements from consecutive 7022 iterations into a vector and operate on them in parallel. 7023 Depending on available target support the loop is conceptually 7024 unrolled by a factor `VF' (vectorization factor), which is the 7025 number of elements operated upon in parallel in each iteration, 7026 and the `VF' copies of each scalar operation are fused to form a 7027 vector operation. Additional loop transformations such as peeling 7028 and versioning may take place to align the number of iterations, 7029 and to align the memory accesses in the loop. The pass is 7030 implemented in `tree-vectorizer.c' (the main driver), 7031 `tree-vect-loop.c' and `tree-vect-loop-manip.c' (loop specific 7032 parts and general loop utilities), `tree-vect-slp' (loop-aware SLP 7033 functionality), `tree-vect-stmts.c' and `tree-vect-data-refs.c'. 7034 Analysis of data references is in `tree-data-ref.c'. 7035 7036 SLP Vectorization. This pass performs vectorization of 7037 straight-line code. The pass is implemented in `tree-vectorizer.c' 7038 (the main driver), `tree-vect-slp.c', `tree-vect-stmts.c' and 7039 `tree-vect-data-refs.c'. 7040 7041 Autoparallelization. This pass splits the loop iteration space to 7042 run into several threads. The pass is implemented in 7043 `tree-parloops.c'. 7044 7045 Graphite is a loop transformation framework based on the polyhedral 7046 model. Graphite stands for Gimple Represented as Polyhedra. The 7047 internals of this infrastructure are documented in 7048 `http://gcc.gnu.org/wiki/Graphite'. The passes working on this 7049 representation are implemented in the various `graphite-*' files. 7050 7051 * Tree level if-conversion for vectorizer 7052 7053 This pass applies if-conversion to simple loops to help vectorizer. 7054 We identify if convertible loops, if-convert statements and merge 7055 basic blocks in one big block. The idea is to present loop in such 7056 form so that vectorizer can have one to one mapping between 7057 statements and available vector operations. This pass is located 7058 in `tree-if-conv.c' and is described by `pass_if_conversion'. 7059 7060 * Conditional constant propagation 7061 7062 This pass relaxes a lattice of values in order to identify those 7063 that must be constant even in the presence of conditional branches. 7064 The pass is located in `tree-ssa-ccp.c' and is described by 7065 `pass_ccp'. 7066 7067 A related pass that works on memory loads and stores, and not just 7068 register values, is located in `tree-ssa-ccp.c' and described by 7069 `pass_store_ccp'. 7070 7071 * Conditional copy propagation 7072 7073 This is similar to constant propagation but the lattice of values 7074 is the "copy-of" relation. It eliminates redundant copies from the 7075 code. The pass is located in `tree-ssa-copy.c' and described by 7076 `pass_copy_prop'. 7077 7078 A related pass that works on memory copies, and not just register 7079 copies, is located in `tree-ssa-copy.c' and described by 7080 `pass_store_copy_prop'. 7081 7082 * Value range propagation 7083 7084 This transformation is similar to constant propagation but instead 7085 of propagating single constant values, it propagates known value 7086 ranges. The implementation is based on Patterson's range 7087 propagation algorithm (Accurate Static Branch Prediction by Value 7088 Range Propagation, J. R. C. Patterson, PLDI '95). In contrast to 7089 Patterson's algorithm, this implementation does not propagate 7090 branch probabilities nor it uses more than a single range per SSA 7091 name. This means that the current implementation cannot be used 7092 for branch prediction (though adapting it would not be difficult). 7093 The pass is located in `tree-vrp.c' and is described by `pass_vrp'. 7094 7095 * Folding built-in functions 7096 7097 This pass simplifies built-in functions, as applicable, with 7098 constant arguments or with inferable string lengths. It is 7099 located in `tree-ssa-ccp.c' and is described by 7100 `pass_fold_builtins'. 7101 7102 * Split critical edges 7103 7104 This pass identifies critical edges and inserts empty basic blocks 7105 such that the edge is no longer critical. The pass is located in 7106 `tree-cfg.c' and is described by `pass_split_crit_edges'. 7107 7108 * Control dependence dead code elimination 7109 7110 This pass is a stronger form of dead code elimination that can 7111 eliminate unnecessary control flow statements. It is located in 7112 `tree-ssa-dce.c' and is described by `pass_cd_dce'. 7113 7114 * Tail call elimination 7115 7116 This pass identifies function calls that may be rewritten into 7117 jumps. No code transformation is actually applied here, but the 7118 data and control flow problem is solved. The code transformation 7119 requires target support, and so is delayed until RTL. In the 7120 meantime `CALL_EXPR_TAILCALL' is set indicating the possibility. 7121 The pass is located in `tree-tailcall.c' and is described by 7122 `pass_tail_calls'. The RTL transformation is handled by 7123 `fixup_tail_calls' in `calls.c'. 7124 7125 * Warn for function return without value 7126 7127 For non-void functions, this pass locates return statements that do 7128 not specify a value and issues a warning. Such a statement may 7129 have been injected by falling off the end of the function. This 7130 pass is run last so that we have as much time as possible to prove 7131 that the statement is not reachable. It is located in 7132 `tree-cfg.c' and is described by `pass_warn_function_return'. 7133 7134 * Leave static single assignment form 7135 7136 This pass rewrites the function such that it is in normal form. At 7137 the same time, we eliminate as many single-use temporaries as 7138 possible, so the intermediate language is no longer GIMPLE, but 7139 GENERIC. The pass is located in `tree-outof-ssa.c' and is 7140 described by `pass_del_ssa'. 7141 7142 * Merge PHI nodes that feed into one another 7143 7144 This is part of the CFG cleanup passes. It attempts to join PHI 7145 nodes from a forwarder CFG block into another block with PHI 7146 nodes. The pass is located in `tree-cfgcleanup.c' and is 7147 described by `pass_merge_phi'. 7148 7149 * Return value optimization 7150 7151 If a function always returns the same local variable, and that 7152 local variable is an aggregate type, then the variable is replaced 7153 with the return value for the function (i.e., the function's 7154 DECL_RESULT). This is equivalent to the C++ named return value 7155 optimization applied to GIMPLE. The pass is located in 7156 `tree-nrv.c' and is described by `pass_nrv'. 7157 7158 * Return slot optimization 7159 7160 If a function returns a memory object and is called as `var = 7161 foo()', this pass tries to change the call so that the address of 7162 `var' is sent to the caller to avoid an extra memory copy. This 7163 pass is located in `tree-nrv.c' and is described by 7164 `pass_return_slot'. 7165 7166 * Optimize calls to `__builtin_object_size' 7167 7168 This is a propagation pass similar to CCP that tries to remove 7169 calls to `__builtin_object_size' when the size of the object can be 7170 computed at compile-time. This pass is located in 7171 `tree-object-size.c' and is described by `pass_object_sizes'. 7172 7173 * Loop invariant motion 7174 7175 This pass removes expensive loop-invariant computations out of 7176 loops. The pass is located in `tree-ssa-loop.c' and described by 7177 `pass_lim'. 7178 7179 * Loop nest optimizations 7180 7181 This is a family of loop transformations that works on loop nests. 7182 It includes loop interchange, scaling, skewing and reversal and 7183 they are all geared to the optimization of data locality in array 7184 traversals and the removal of dependencies that hamper 7185 optimizations such as loop parallelization and vectorization. The 7186 pass is located in `tree-loop-linear.c' and described by 7187 `pass_linear_transform'. 7188 7189 * Removal of empty loops 7190 7191 This pass removes loops with no code in them. The pass is located 7192 in `tree-ssa-loop-ivcanon.c' and described by `pass_empty_loop'. 7193 7194 * Unrolling of small loops 7195 7196 This pass completely unrolls loops with few iterations. The pass 7197 is located in `tree-ssa-loop-ivcanon.c' and described by 7198 `pass_complete_unroll'. 7199 7200 * Predictive commoning 7201 7202 This pass makes the code reuse the computations from the previous 7203 iterations of the loops, especially loads and stores to memory. 7204 It does so by storing the values of these computations to a bank 7205 of temporary variables that are rotated at the end of loop. To 7206 avoid the need for this rotation, the loop is then unrolled and 7207 the copies of the loop body are rewritten to use the appropriate 7208 version of the temporary variable. This pass is located in 7209 `tree-predcom.c' and described by `pass_predcom'. 7210 7211 * Array prefetching 7212 7213 This pass issues prefetch instructions for array references inside 7214 loops. The pass is located in `tree-ssa-loop-prefetch.c' and 7215 described by `pass_loop_prefetch'. 7216 7217 * Reassociation 7218 7219 This pass rewrites arithmetic expressions to enable optimizations 7220 that operate on them, like redundancy elimination and 7221 vectorization. The pass is located in `tree-ssa-reassoc.c' and 7222 described by `pass_reassoc'. 7223 7224 * Optimization of `stdarg' functions 7225 7226 This pass tries to avoid the saving of register arguments into the 7227 stack on entry to `stdarg' functions. If the function doesn't use 7228 any `va_start' macros, no registers need to be saved. If 7229 `va_start' macros are used, the `va_list' variables don't escape 7230 the function, it is only necessary to save registers that will be 7231 used in `va_arg' macros. For instance, if `va_arg' is only used 7232 with integral types in the function, floating point registers 7233 don't need to be saved. This pass is located in `tree-stdarg.c' 7234 and described by `pass_stdarg'. 7235 7236 7237 7238File: gccint.info, Node: RTL passes, Next: Optimization info, Prev: Tree SSA passes, Up: Passes 7239 72409.6 RTL passes 7241============== 7242 7243The following briefly describes the RTL generation and optimization 7244passes that are run after the Tree optimization passes. 7245 7246 * RTL generation 7247 7248 The source files for RTL generation include `stmt.c', `calls.c', 7249 `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and 7250 `emit-rtl.c'. Also, the file `insn-emit.c', generated from the 7251 machine description by the program `genemit', is used in this 7252 pass. The header file `expr.h' is used for communication within 7253 this pass. 7254 7255 The header files `insn-flags.h' and `insn-codes.h', generated from 7256 the machine description by the programs `genflags' and `gencodes', 7257 tell this pass which standard names are available for use and 7258 which patterns correspond to them. 7259 7260 * Generation of exception landing pads 7261 7262 This pass generates the glue that handles communication between the 7263 exception handling library routines and the exception handlers 7264 within the function. Entry points in the function that are 7265 invoked by the exception handling library are called "landing 7266 pads". The code for this pass is located in `except.c'. 7267 7268 * Control flow graph cleanup 7269 7270 This pass removes unreachable code, simplifies jumps to next, 7271 jumps to jump, jumps across jumps, etc. The pass is run multiple 7272 times. For historical reasons, it is occasionally referred to as 7273 the "jump optimization pass". The bulk of the code for this pass 7274 is in `cfgcleanup.c', and there are support routines in `cfgrtl.c' 7275 and `jump.c'. 7276 7277 * Forward propagation of single-def values 7278 7279 This pass attempts to remove redundant computation by substituting 7280 variables that come from a single definition, and seeing if the 7281 result can be simplified. It performs copy propagation and 7282 addressing mode selection. The pass is run twice, with values 7283 being propagated into loops only on the second run. The code is 7284 located in `fwprop.c'. 7285 7286 * Common subexpression elimination 7287 7288 This pass removes redundant computation within basic blocks, and 7289 optimizes addressing modes based on cost. The pass is run twice. 7290 The code for this pass is located in `cse.c'. 7291 7292 * Global common subexpression elimination 7293 7294 This pass performs two different types of GCSE depending on 7295 whether you are optimizing for size or not (LCM based GCSE tends 7296 to increase code size for a gain in speed, while Morel-Renvoise 7297 based GCSE does not). When optimizing for size, GCSE is done 7298 using Morel-Renvoise Partial Redundancy Elimination, with the 7299 exception that it does not try to move invariants out of 7300 loops--that is left to the loop optimization pass. If MR PRE 7301 GCSE is done, code hoisting (aka unification) is also done, as 7302 well as load motion. If you are optimizing for speed, LCM (lazy 7303 code motion) based GCSE is done. LCM is based on the work of 7304 Knoop, Ruthing, and Steffen. LCM based GCSE also does loop 7305 invariant code motion. We also perform load and store motion when 7306 optimizing for speed. Regardless of which type of GCSE is used, 7307 the GCSE pass also performs global constant and copy propagation. 7308 The source file for this pass is `gcse.c', and the LCM routines 7309 are in `lcm.c'. 7310 7311 * Loop optimization 7312 7313 This pass performs several loop related optimizations. The source 7314 files `cfgloopanal.c' and `cfgloopmanip.c' contain generic loop 7315 analysis and manipulation code. Initialization and finalization 7316 of loop structures is handled by `loop-init.c'. A loop invariant 7317 motion pass is implemented in `loop-invariant.c'. Basic block 7318 level optimizations--unrolling, and peeling loops-- are 7319 implemented in `loop-unroll.c'. Replacing of the exit condition 7320 of loops by special machine-dependent instructions is handled by 7321 `loop-doloop.c'. 7322 7323 * Jump bypassing 7324 7325 This pass is an aggressive form of GCSE that transforms the control 7326 flow graph of a function by propagating constants into conditional 7327 branch instructions. The source file for this pass is `gcse.c'. 7328 7329 * If conversion 7330 7331 This pass attempts to replace conditional branches and surrounding 7332 assignments with arithmetic, boolean value producing comparison 7333 instructions, and conditional move instructions. In the very last 7334 invocation after reload/LRA, it will generate predicated 7335 instructions when supported by the target. The code is located in 7336 `ifcvt.c'. 7337 7338 * Web construction 7339 7340 This pass splits independent uses of each pseudo-register. This 7341 can improve effect of the other transformation, such as CSE or 7342 register allocation. The code for this pass is located in `web.c'. 7343 7344 * Instruction combination 7345 7346 This pass attempts to combine groups of two or three instructions 7347 that are related by data flow into single instructions. It 7348 combines the RTL expressions for the instructions by substitution, 7349 simplifies the result using algebra, and then attempts to match 7350 the result against the machine description. The code is located 7351 in `combine.c'. 7352 7353 * Mode switching optimization 7354 7355 This pass looks for instructions that require the processor to be 7356 in a specific "mode" and minimizes the number of mode changes 7357 required to satisfy all users. What these modes are, and what 7358 they apply to are completely target-specific. The code for this 7359 pass is located in `mode-switching.c'. 7360 7361 * Modulo scheduling 7362 7363 This pass looks at innermost loops and reorders their instructions 7364 by overlapping different iterations. Modulo scheduling is 7365 performed immediately before instruction scheduling. The code for 7366 this pass is located in `modulo-sched.c'. 7367 7368 * Instruction scheduling 7369 7370 This pass looks for instructions whose output will not be 7371 available by the time that it is used in subsequent instructions. 7372 Memory loads and floating point instructions often have this 7373 behavior on RISC machines. It re-orders instructions within a 7374 basic block to try to separate the definition and use of items 7375 that otherwise would cause pipeline stalls. This pass is 7376 performed twice, before and after register allocation. The code 7377 for this pass is located in `haifa-sched.c', `sched-deps.c', 7378 `sched-ebb.c', `sched-rgn.c' and `sched-vis.c'. 7379 7380 * Register allocation 7381 7382 These passes make sure that all occurrences of pseudo registers are 7383 eliminated, either by allocating them to a hard register, replacing 7384 them by an equivalent expression (e.g. a constant) or by placing 7385 them on the stack. This is done in several subpasses: 7386 7387 * The integrated register allocator (IRA). It is called 7388 integrated because coalescing, register live range splitting, 7389 and hard register preferencing are done on-the-fly during 7390 coloring. It also has better integration with the reload/LRA 7391 pass. Pseudo-registers spilled by the allocator or the 7392 reload/LRA have still a chance to get hard-registers if the 7393 reload/LRA evicts some pseudo-registers from hard-registers. 7394 The allocator helps to choose better pseudos for spilling 7395 based on their live ranges and to coalesce stack slots 7396 allocated for the spilled pseudo-registers. IRA is a regional 7397 register allocator which is transformed into Chaitin-Briggs 7398 allocator if there is one region. By default, IRA chooses 7399 regions using register pressure but the user can force it to 7400 use one region or regions corresponding to all loops. 7401 7402 Source files of the allocator are `ira.c', `ira-build.c', 7403 `ira-costs.c', `ira-conflicts.c', `ira-color.c', 7404 `ira-emit.c', `ira-lives', plus header files `ira.h' and 7405 `ira-int.h' used for the communication between the allocator 7406 and the rest of the compiler and between the IRA files. 7407 7408 * Reloading. This pass renumbers pseudo registers with the 7409 hardware registers numbers they were allocated. Pseudo 7410 registers that did not get hard registers are replaced with 7411 stack slots. Then it finds instructions that are invalid 7412 because a value has failed to end up in a register, or has 7413 ended up in a register of the wrong kind. It fixes up these 7414 instructions by reloading the problematical values 7415 temporarily into registers. Additional instructions are 7416 generated to do the copying. 7417 7418 The reload pass also optionally eliminates the frame pointer 7419 and inserts instructions to save and restore call-clobbered 7420 registers around calls. 7421 7422 Source files are `reload.c' and `reload1.c', plus the header 7423 `reload.h' used for communication between them. 7424 7425 * This pass is a modern replacement of the reload pass. Source 7426 files are `lra.c', `lra-assign.c', `lra-coalesce.c', 7427 `lra-constraints.c', `lra-eliminations.c', `lra-lives.c', 7428 `lra-remat.c', `lra-spills.c', the header `lra-int.h' used 7429 for communication between them, and the header `lra.h' used 7430 for communication between LRA and the rest of compiler. 7431 7432 Unlike the reload pass, intermediate LRA decisions are 7433 reflected in RTL as much as possible. This reduces the 7434 number of target-dependent macros and hooks, leaving 7435 instruction constraints as the primary source of control. 7436 7437 LRA is run on targets for which TARGET_LRA_P returns true. 7438 7439 * Basic block reordering 7440 7441 This pass implements profile guided code positioning. If profile 7442 information is not available, various types of static analysis are 7443 performed to make the predictions normally coming from the profile 7444 feedback (IE execution frequency, branch probability, etc). It is 7445 implemented in the file `bb-reorder.c', and the various prediction 7446 routines are in `predict.c'. 7447 7448 * Variable tracking 7449 7450 This pass computes where the variables are stored at each position 7451 in code and generates notes describing the variable locations to 7452 RTL code. The location lists are then generated according to these 7453 notes to debug information if the debugging information format 7454 supports location lists. The code is located in `var-tracking.c'. 7455 7456 * Delayed branch scheduling 7457 7458 This optional pass attempts to find instructions that can go into 7459 the delay slots of other instructions, usually jumps and calls. 7460 The code for this pass is located in `reorg.c'. 7461 7462 * Branch shortening 7463 7464 On many RISC machines, branch instructions have a limited range. 7465 Thus, longer sequences of instructions must be used for long 7466 branches. In this pass, the compiler figures out what how far 7467 each instruction will be from each other instruction, and 7468 therefore whether the usual instructions, or the longer sequences, 7469 must be used for each branch. The code for this pass is located 7470 in `final.c'. 7471 7472 * Register-to-stack conversion 7473 7474 Conversion from usage of some hard registers to usage of a register 7475 stack may be done at this point. Currently, this is supported only 7476 for the floating-point registers of the Intel 80387 coprocessor. 7477 The code for this pass is located in `reg-stack.c'. 7478 7479 * Final 7480 7481 This pass outputs the assembler code for the function. The source 7482 files are `final.c' plus `insn-output.c'; the latter is generated 7483 automatically from the machine description by the tool `genoutput'. 7484 The header file `conditions.h' is used for communication between 7485 these files. 7486 7487 * Debugging information output 7488 7489 This is run after final because it must output the stack slot 7490 offsets for pseudo registers that did not get hard registers. 7491 Source files are `dbxout.c' for DBX symbol table format, 7492 `sdbout.c' for SDB symbol table format, `dwarfout.c' for DWARF 7493 symbol table format, files `dwarf2out.c' and `dwarf2asm.c' for 7494 DWARF2 symbol table format, and `vmsdbgout.c' for VMS debug symbol 7495 table format. 7496 7497 7498 7499File: gccint.info, Node: Optimization info, Prev: RTL passes, Up: Passes 7500 75019.7 Optimization info 7502===================== 7503 7504This section is describes dump infrastructure which is common to both 7505pass dumps as well as optimization dumps. The goal for this 7506infrastructure is to provide both gcc developers and users detailed 7507information about various compiler transformations and optimizations. 7508 7509* Menu: 7510 7511* Dump setup:: Setup of optimization dumps. 7512* Optimization groups:: Groups made up of optimization passes. 7513* Dump files and streams:: Dump output file names and streams. 7514* Dump output verbosity:: How much information to dump. 7515* Dump types:: Various types of dump functions. 7516* Dump examples:: Sample usage. 7517 7518 7519File: gccint.info, Node: Dump setup, Next: Optimization groups, Up: Optimization info 7520 75219.7.1 Dump setup 7522---------------- 7523 7524A dump_manager class is defined in `dumpfile.h'. Various passes 7525register dumping pass-specific information via `dump_register' in 7526`passes.c'. During the registration, an optimization pass can select 7527its optimization group (*note Optimization groups::). After that 7528optimization information corresponding to the entire group (presumably 7529from multiple passes) can be output via command-line switches. Note 7530that if a pass does not fit into any of the pre-defined groups, it can 7531select `OPTGROUP_NONE'. 7532 7533 Note that in general, a pass need not know its dump output file name, 7534whether certain flags are enabled, etc. However, for legacy reasons, 7535passes could also call `dump_begin' which returns a stream in case the 7536particular pass has optimization dumps enabled. A pass could call 7537`dump_end' when the dump has ended. These methods should go away once 7538all the passes are converted to use the new dump infrastructure. 7539 7540 The recommended way to setup the dump output is via `dump_start' and 7541`dump_end'. 7542 7543 7544File: gccint.info, Node: Optimization groups, Next: Dump files and streams, Prev: Dump setup, Up: Optimization info 7545 75469.7.2 Optimization groups 7547------------------------- 7548 7549The optimization passes are grouped into several categories. Currently 7550defined categories in `dumpfile.h' are 7551 7552`OPTGROUP_IPA' 7553 IPA optimization passes. Enabled by `-ipa' 7554 7555`OPTGROUP_LOOP' 7556 Loop optimization passes. Enabled by `-loop'. 7557 7558`OPTGROUP_INLINE' 7559 Inlining passes. Enabled by `-inline'. 7560 7561`OPTGROUP_VEC' 7562 Vectorization passes. Enabled by `-vec'. 7563 7564`OPTGROUP_OTHER' 7565 All other optimization passes which do not fall into one of the 7566 above. 7567 7568`OPTGROUP_ALL' 7569 All optimization passes. Enabled by `-all'. 7570 7571 7572 By using groups a user could selectively enable optimization 7573information only for a group of passes. By default, the optimization 7574information for all the passes is dumped. 7575 7576 7577File: gccint.info, Node: Dump files and streams, Next: Dump output verbosity, Prev: Optimization groups, Up: Optimization info 7578 75799.7.3 Dump files and streams 7580---------------------------- 7581 7582There are two separate output streams available for outputting 7583optimization information from passes. Note that both these streams 7584accept `stderr' and `stdout' as valid streams and thus it is possible 7585to dump output to standard output or error. This is specially handy for 7586outputting all available information in a single file by redirecting 7587`stderr'. 7588 7589``pstream'' 7590 This stream is for pass-specific dump output. For example, 7591 `-fdump-tree-vect=foo.v' dumps tree vectorization pass output into 7592 the given file name `foo.v'. If the file name is not provided, the 7593 default file name is based on the source file and pass number. Note 7594 that one could also use special file names `stdout' and `stderr' 7595 for dumping to standard output and standard error respectively. 7596 7597``alt_stream'' 7598 This steam is used for printing optimization specific output in 7599 response to the `-fopt-info'. Again a file name can be given. If 7600 the file name is not given, it defaults to `stderr'. 7601 7602 7603File: gccint.info, Node: Dump output verbosity, Next: Dump types, Prev: Dump files and streams, Up: Optimization info 7604 76059.7.4 Dump output verbosity 7606--------------------------- 7607 7608The dump verbosity has the following options 7609 7610`optimized' 7611 Print information when an optimization is successfully applied. It 7612 is up to a pass to decide which information is relevant. For 7613 example, the vectorizer passes print the source location of loops 7614 which got successfully vectorized. 7615 7616`missed' 7617 Print information about missed optimizations. Individual passes 7618 control which information to include in the output. For example, 7619 7620 gcc -O2 -ftree-vectorize -fopt-info-vec-missed 7621 7622 will print information about missed optimization opportunities from 7623 vectorization passes on stderr. 7624 7625`note' 7626 Print verbose information about optimizations, such as certain 7627 transformations, more detailed messages about decisions etc. 7628 7629`all' 7630 Print detailed optimization information. This includes OPTIMIZED, 7631 MISSED, and NOTE. 7632 7633 7634File: gccint.info, Node: Dump types, Next: Dump examples, Prev: Dump output verbosity, Up: Optimization info 7635 76369.7.5 Dump types 7637---------------- 7638 7639`dump_printf' 7640 This is a generic method for doing formatted output. It takes an 7641 additional argument `dump_kind' which signifies the type of dump. 7642 This method outputs information only when the dumps are enabled 7643 for this particular `dump_kind'. Note that the caller doesn't need 7644 to know if the particular dump is enabled or not, or even the file 7645 name. The caller only needs to decide which dump output 7646 information is relevant, and under what conditions. This determines 7647 the associated flags. 7648 7649 Consider the following example from `loop-unroll.c' where an 7650 informative message about a loop (along with its location) is 7651 printed when any of the following flags is enabled 7652 - optimization messages 7653 7654 - RTL dumps 7655 7656 - detailed dumps 7657 7658 7659 int report_flags = MSG_OPTIMIZED_LOCATIONS | TDF_RTL | TDF_DETAILS; 7660 dump_printf_loc (report_flags, locus, 7661 "loop turned into non-loop; it never loops.\n"); 7662 7663`dump_basic_block' 7664 Output basic block. 7665 7666`dump_generic_expr' 7667 Output generic expression. 7668 7669`dump_gimple_stmt' 7670 Output gimple statement. 7671 7672 Note that the above methods also have variants prefixed with 7673 `_loc', such as `dump_printf_loc', which are similar except they 7674 also output the source location information. 7675 7676 7677 7678File: gccint.info, Node: Dump examples, Prev: Dump types, Up: Optimization info 7679 76809.7.6 Dump examples 7681------------------- 7682 7683 gcc -O3 -fopt-info-missed=missed.all 7684 7685 outputs missed optimization report from all the passes into 7686`missed.all'. 7687 7688 As another example, 7689 gcc -O3 -fopt-info-inline-optimized-missed=inline.txt 7690 7691 will output information about missed optimizations as well as 7692optimized locations from all the inlining passes into `inline.txt'. 7693 7694 If the FILENAME is provided, then the dumps from all the applicable 7695optimizations are concatenated into the `filename'. Otherwise the dump 7696is output onto `stderr'. If OPTIONS is omitted, it defaults to 7697`all-all', which means dump all available optimization info from all 7698the passes. In the following example, all optimization info is output 7699on to `stderr'. 7700 7701 gcc -O3 -fopt-info 7702 7703 Note that `-fopt-info-vec-missed' behaves the same as 7704`-fopt-info-missed-vec'. 7705 7706 As another example, consider 7707 7708 gcc -fopt-info-vec-missed=vec.miss -fopt-info-loop-optimized=loop.opt 7709 7710 Here the two output file names `vec.miss' and `loop.opt' are in 7711conflict since only one output file is allowed. In this case, only the 7712first option takes effect and the subsequent options are ignored. Thus 7713only the `vec.miss' is produced which containts dumps from the 7714vectorizer about missed opportunities. 7715 7716 7717File: gccint.info, Node: GENERIC, Next: GIMPLE, Prev: Passes, Up: Top 7718 771910 GENERIC 7720********** 7721 7722The purpose of GENERIC is simply to provide a language-independent way 7723of representing an entire function in trees. To this end, it was 7724necessary to add a few new tree codes to the back end, but almost 7725everything was already there. If you can express it with the codes in 7726`gcc/tree.def', it's GENERIC. 7727 7728 Early on, there was a great deal of debate about how to think about 7729statements in a tree IL. In GENERIC, a statement is defined as any 7730expression whose value, if any, is ignored. A statement will always 7731have `TREE_SIDE_EFFECTS' set (or it will be discarded), but a 7732non-statement expression may also have side effects. A `CALL_EXPR', 7733for instance. 7734 7735 It would be possible for some local optimizations to work on the 7736GENERIC form of a function; indeed, the adapted tree inliner works fine 7737on GENERIC, but the current compiler performs inlining after lowering 7738to GIMPLE (a restricted form described in the next section). Indeed, 7739currently the frontends perform this lowering before handing off to 7740`tree_rest_of_compilation', but this seems inelegant. 7741 7742* Menu: 7743 7744* Deficiencies:: Topics net yet covered in this document. 7745* Tree overview:: All about `tree's. 7746* Types:: Fundamental and aggregate types. 7747* Declarations:: Type declarations and variables. 7748* Attributes:: Declaration and type attributes. 7749* Expressions: Expression trees. Operating on data. 7750* Statements:: Control flow and related trees. 7751* Functions:: Function bodies, linkage, and other aspects. 7752* Language-dependent trees:: Topics and trees specific to language front ends. 7753* C and C++ Trees:: Trees specific to C and C++. 7754* Java Trees:: Trees specific to Java. 7755 7756 7757File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: GENERIC 7758 775910.1 Deficiencies 7760================= 7761 7762There are many places in which this document is incomplet and incorrekt. 7763It is, as of yet, only _preliminary_ documentation. 7764 7765 7766File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: GENERIC 7767 776810.2 Overview 7769============= 7770 7771The central data structure used by the internal representation is the 7772`tree'. These nodes, while all of the C type `tree', are of many 7773varieties. A `tree' is a pointer type, but the object to which it 7774points may be of a variety of types. From this point forward, we will 7775refer to trees in ordinary type, rather than in `this font', except 7776when talking about the actual C type `tree'. 7777 7778 You can tell what kind of node a particular tree is by using the 7779`TREE_CODE' macro. Many, many macros take trees as input and return 7780trees as output. However, most macros require a certain kind of tree 7781node as input. In other words, there is a type-system for trees, but 7782it is not reflected in the C type-system. 7783 7784 For safety, it is useful to configure GCC with `--enable-checking'. 7785Although this results in a significant performance penalty (since all 7786tree types are checked at run-time), and is therefore inappropriate in a 7787release version, it is extremely helpful during the development process. 7788 7789 Many macros behave as predicates. Many, although not all, of these 7790predicates end in `_P'. Do not rely on the result type of these macros 7791being of any particular type. You may, however, rely on the fact that 7792the type can be compared to `0', so that statements like 7793 if (TEST_P (t) && !TEST_P (y)) 7794 x = 1; 7795 and 7796 int i = (TEST_P (t) != 0); 7797 are legal. Macros that return `int' values now may be changed to 7798return `tree' values, or other pointers in the future. Even those that 7799continue to return `int' may return multiple nonzero codes where 7800previously they returned only zero and one. Therefore, you should not 7801write code like 7802 if (TEST_P (t) == 1) 7803 as this code is not guaranteed to work correctly in the future. 7804 7805 You should not take the address of values returned by the macros or 7806functions described here. In particular, no guarantee is given that the 7807values are lvalues. 7808 7809 In general, the names of macros are all in uppercase, while the names 7810of functions are entirely in lowercase. There are rare exceptions to 7811this rule. You should assume that any macro or function whose name is 7812made up entirely of uppercase letters may evaluate its arguments more 7813than once. You may assume that a macro or function whose name is made 7814up entirely of lowercase letters will evaluate its arguments only once. 7815 7816 The `error_mark_node' is a special tree. Its tree code is 7817`ERROR_MARK', but since there is only ever one node with that code, the 7818usual practice is to compare the tree against `error_mark_node'. (This 7819test is just a test for pointer equality.) If an error has occurred 7820during front-end processing the flag `errorcount' will be set. If the 7821front end has encountered code it cannot handle, it will issue a 7822message to the user and set `sorrycount'. When these flags are set, 7823any macro or function which normally returns a tree of a particular 7824kind may instead return the `error_mark_node'. Thus, if you intend to 7825do any processing of erroneous code, you must be prepared to deal with 7826the `error_mark_node'. 7827 7828 Occasionally, a particular tree slot (like an operand to an expression, 7829or a particular field in a declaration) will be referred to as 7830"reserved for the back end". These slots are used to store RTL when 7831the tree is converted to RTL for use by the GCC back end. However, if 7832that process is not taking place (e.g., if the front end is being hooked 7833up to an intelligent editor), then those slots may be used by the back 7834end presently in use. 7835 7836 If you encounter situations that do not match this documentation, such 7837as tree nodes of types not mentioned here, or macros documented to 7838return entities of a particular kind that instead return entities of 7839some different kind, you have found a bug, either in the front end or in 7840the documentation. Please report these bugs as you would any other bug. 7841 7842* Menu: 7843 7844* Macros and Functions::Macros and functions that can be used with all trees. 7845* Identifiers:: The names of things. 7846* Containers:: Lists and vectors. 7847 7848 7849File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview 7850 785110.2.1 Trees 7852------------ 7853 7854All GENERIC trees have two fields in common. First, `TREE_CHAIN' is a 7855pointer that can be used as a singly-linked list to other trees. The 7856other is `TREE_TYPE'. Many trees store the type of an expression or 7857declaration in this field. 7858 7859 These are some other functions for handling trees: 7860 7861`tree_size' 7862 Return the number of bytes a tree takes. 7863 7864`build0' 7865`build1' 7866`build2' 7867`build3' 7868`build4' 7869`build5' 7870`build6' 7871 These functions build a tree and supply values to put in each 7872 parameter. The basic signature is `code, type, [operands]'. 7873 `code' is the `TREE_CODE', and `type' is a tree representing the 7874 `TREE_TYPE'. These are followed by the operands, each of which is 7875 also a tree. 7876 7877 7878 7879File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview 7880 788110.2.2 Identifiers 7882------------------ 7883 7884An `IDENTIFIER_NODE' represents a slightly more general concept than 7885the standard C or C++ concept of identifier. In particular, an 7886`IDENTIFIER_NODE' may contain a `$', or other extraordinary characters. 7887 7888 There are never two distinct `IDENTIFIER_NODE's representing the same 7889identifier. Therefore, you may use pointer equality to compare 7890`IDENTIFIER_NODE's, rather than using a routine like `strcmp'. Use 7891`get_identifier' to obtain the unique `IDENTIFIER_NODE' for a supplied 7892string. 7893 7894 You can use the following macros to access identifiers: 7895`IDENTIFIER_POINTER' 7896 The string represented by the identifier, represented as a 7897 `char*'. This string is always `NUL'-terminated, and contains no 7898 embedded `NUL' characters. 7899 7900`IDENTIFIER_LENGTH' 7901 The length of the string returned by `IDENTIFIER_POINTER', not 7902 including the trailing `NUL'. This value of `IDENTIFIER_LENGTH 7903 (x)' is always the same as `strlen (IDENTIFIER_POINTER (x))'. 7904 7905`IDENTIFIER_OPNAME_P' 7906 This predicate holds if the identifier represents the name of an 7907 overloaded operator. In this case, you should not depend on the 7908 contents of either the `IDENTIFIER_POINTER' or the 7909 `IDENTIFIER_LENGTH'. 7910 7911`IDENTIFIER_TYPENAME_P' 7912 This predicate holds if the identifier represents the name of a 7913 user-defined conversion operator. In this case, the `TREE_TYPE' of 7914 the `IDENTIFIER_NODE' holds the type to which the conversion 7915 operator converts. 7916 7917 7918 7919File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview 7920 792110.2.3 Containers 7922----------------- 7923 7924Two common container data structures can be represented directly with 7925tree nodes. A `TREE_LIST' is a singly linked list containing two trees 7926per node. These are the `TREE_PURPOSE' and `TREE_VALUE' of each node. 7927(Often, the `TREE_PURPOSE' contains some kind of tag, or additional 7928information, while the `TREE_VALUE' contains the majority of the 7929payload. In other cases, the `TREE_PURPOSE' is simply `NULL_TREE', 7930while in still others both the `TREE_PURPOSE' and `TREE_VALUE' are of 7931equal stature.) Given one `TREE_LIST' node, the next node is found by 7932following the `TREE_CHAIN'. If the `TREE_CHAIN' is `NULL_TREE', then 7933you have reached the end of the list. 7934 7935 A `TREE_VEC' is a simple vector. The `TREE_VEC_LENGTH' is an integer 7936(not a tree) giving the number of nodes in the vector. The nodes 7937themselves are accessed using the `TREE_VEC_ELT' macro, which takes two 7938arguments. The first is the `TREE_VEC' in question; the second is an 7939integer indicating which element in the vector is desired. The 7940elements are indexed from zero. 7941 7942 7943File: gccint.info, Node: Types, Next: Declarations, Prev: Tree overview, Up: GENERIC 7944 794510.3 Types 7946========== 7947 7948All types have corresponding tree nodes. However, you should not assume 7949that there is exactly one tree node corresponding to each type. There 7950are often multiple nodes corresponding to the same type. 7951 7952 For the most part, different kinds of types have different tree codes. 7953(For example, pointer types use a `POINTER_TYPE' code while arrays use 7954an `ARRAY_TYPE' code.) However, pointers to member functions use the 7955`RECORD_TYPE' code. Therefore, when writing a `switch' statement that 7956depends on the code associated with a particular type, you should take 7957care to handle pointers to member functions under the `RECORD_TYPE' 7958case label. 7959 7960 The following functions and macros deal with cv-qualification of types: 7961`TYPE_MAIN_VARIANT' 7962 This macro returns the unqualified version of a type. It may be 7963 applied to an unqualified type, but it is not always the identity 7964 function in that case. 7965 7966 A few other macros and functions are usable with all types: 7967`TYPE_SIZE' 7968 The number of bits required to represent the type, represented as 7969 an `INTEGER_CST'. For an incomplete type, `TYPE_SIZE' will be 7970 `NULL_TREE'. 7971 7972`TYPE_ALIGN' 7973 The alignment of the type, in bits, represented as an `int'. 7974 7975`TYPE_NAME' 7976 This macro returns a declaration (in the form of a `TYPE_DECL') for 7977 the type. (Note this macro does _not_ return an 7978 `IDENTIFIER_NODE', as you might expect, given its name!) You can 7979 look at the `DECL_NAME' of the `TYPE_DECL' to obtain the actual 7980 name of the type. The `TYPE_NAME' will be `NULL_TREE' for a type 7981 that is not a built-in type, the result of a typedef, or a named 7982 class type. 7983 7984`TYPE_CANONICAL' 7985 This macro returns the "canonical" type for the given type node. 7986 Canonical types are used to improve performance in the C++ and 7987 Objective-C++ front ends by allowing efficient comparison between 7988 two type nodes in `same_type_p': if the `TYPE_CANONICAL' values of 7989 the types are equal, the types are equivalent; otherwise, the types 7990 are not equivalent. The notion of equivalence for canonical types 7991 is the same as the notion of type equivalence in the language 7992 itself. For instance, 7993 7994 When `TYPE_CANONICAL' is `NULL_TREE', there is no canonical type 7995 for the given type node. In this case, comparison between this 7996 type and any other type requires the compiler to perform a deep, 7997 "structural" comparison to see if the two type nodes have the same 7998 form and properties. 7999 8000 The canonical type for a node is always the most fundamental type 8001 in the equivalence class of types. For instance, `int' is its own 8002 canonical type. A typedef `I' of `int' will have `int' as its 8003 canonical type. Similarly, `I*' and a typedef `IP' (defined to 8004 `I*') will has `int*' as their canonical type. When building a new 8005 type node, be sure to set `TYPE_CANONICAL' to the appropriate 8006 canonical type. If the new type is a compound type (built from 8007 other types), and any of those other types require structural 8008 equality, use `SET_TYPE_STRUCTURAL_EQUALITY' to ensure that the 8009 new type also requires structural equality. Finally, if for some 8010 reason you cannot guarantee that `TYPE_CANONICAL' will point to 8011 the canonical type, use `SET_TYPE_STRUCTURAL_EQUALITY' to make 8012 sure that the new type-and any type constructed based on 8013 it-requires structural equality. If you suspect that the canonical 8014 type system is miscomparing types, pass `--param 8015 verify-canonical-types=1' to the compiler or configure with 8016 `--enable-checking' to force the compiler to verify its 8017 canonical-type comparisons against the structural comparisons; the 8018 compiler will then print any warnings if the canonical types 8019 miscompare. 8020 8021`TYPE_STRUCTURAL_EQUALITY_P' 8022 This predicate holds when the node requires structural equality 8023 checks, e.g., when `TYPE_CANONICAL' is `NULL_TREE'. 8024 8025`SET_TYPE_STRUCTURAL_EQUALITY' 8026 This macro states that the type node it is given requires 8027 structural equality checks, e.g., it sets `TYPE_CANONICAL' to 8028 `NULL_TREE'. 8029 8030`same_type_p' 8031 This predicate takes two types as input, and holds if they are the 8032 same type. For example, if one type is a `typedef' for the other, 8033 or both are `typedef's for the same type. This predicate also 8034 holds if the two trees given as input are simply copies of one 8035 another; i.e., there is no difference between them at the source 8036 level, but, for whatever reason, a duplicate has been made in the 8037 representation. You should never use `==' (pointer equality) to 8038 compare types; always use `same_type_p' instead. 8039 8040 Detailed below are the various kinds of types, and the macros that can 8041be used to access them. Although other kinds of types are used 8042elsewhere in G++, the types described here are the only ones that you 8043will encounter while examining the intermediate representation. 8044 8045`VOID_TYPE' 8046 Used to represent the `void' type. 8047 8048`INTEGER_TYPE' 8049 Used to represent the various integral types, including `char', 8050 `short', `int', `long', and `long long'. This code is not used 8051 for enumeration types, nor for the `bool' type. The 8052 `TYPE_PRECISION' is the number of bits used in the representation, 8053 represented as an `unsigned int'. (Note that in the general case 8054 this is not the same value as `TYPE_SIZE'; suppose that there were 8055 a 24-bit integer type, but that alignment requirements for the ABI 8056 required 32-bit alignment. Then, `TYPE_SIZE' would be an 8057 `INTEGER_CST' for 32, while `TYPE_PRECISION' would be 24.) The 8058 integer type is unsigned if `TYPE_UNSIGNED' holds; otherwise, it 8059 is signed. 8060 8061 The `TYPE_MIN_VALUE' is an `INTEGER_CST' for the smallest integer 8062 that may be represented by this type. Similarly, the 8063 `TYPE_MAX_VALUE' is an `INTEGER_CST' for the largest integer that 8064 may be represented by this type. 8065 8066`REAL_TYPE' 8067 Used to represent the `float', `double', and `long double' types. 8068 The number of bits in the floating-point representation is given 8069 by `TYPE_PRECISION', as in the `INTEGER_TYPE' case. 8070 8071`FIXED_POINT_TYPE' 8072 Used to represent the `short _Fract', `_Fract', `long _Fract', 8073 `long long _Fract', `short _Accum', `_Accum', `long _Accum', and 8074 `long long _Accum' types. The number of bits in the fixed-point 8075 representation is given by `TYPE_PRECISION', as in the 8076 `INTEGER_TYPE' case. There may be padding bits, fractional bits 8077 and integral bits. The number of fractional bits is given by 8078 `TYPE_FBIT', and the number of integral bits is given by 8079 `TYPE_IBIT'. The fixed-point type is unsigned if `TYPE_UNSIGNED' 8080 holds; otherwise, it is signed. The fixed-point type is 8081 saturating if `TYPE_SATURATING' holds; otherwise, it is not 8082 saturating. 8083 8084`COMPLEX_TYPE' 8085 Used to represent GCC built-in `__complex__' data types. The 8086 `TREE_TYPE' is the type of the real and imaginary parts. 8087 8088`ENUMERAL_TYPE' 8089 Used to represent an enumeration type. The `TYPE_PRECISION' gives 8090 (as an `int'), the number of bits used to represent the type. If 8091 there are no negative enumeration constants, `TYPE_UNSIGNED' will 8092 hold. The minimum and maximum enumeration constants may be 8093 obtained with `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE', respectively; 8094 each of these macros returns an `INTEGER_CST'. 8095 8096 The actual enumeration constants themselves may be obtained by 8097 looking at the `TYPE_VALUES'. This macro will return a 8098 `TREE_LIST', containing the constants. The `TREE_PURPOSE' of each 8099 node will be an `IDENTIFIER_NODE' giving the name of the constant; 8100 the `TREE_VALUE' will be an `INTEGER_CST' giving the value 8101 assigned to that constant. These constants will appear in the 8102 order in which they were declared. The `TREE_TYPE' of each of 8103 these constants will be the type of enumeration type itself. 8104 8105`BOOLEAN_TYPE' 8106 Used to represent the `bool' type. 8107 8108`POINTER_TYPE' 8109 Used to represent pointer types, and pointer to data member types. 8110 The `TREE_TYPE' gives the type to which this type points. 8111 8112`REFERENCE_TYPE' 8113 Used to represent reference types. The `TREE_TYPE' gives the type 8114 to which this type refers. 8115 8116`FUNCTION_TYPE' 8117 Used to represent the type of non-member functions and of static 8118 member functions. The `TREE_TYPE' gives the return type of the 8119 function. The `TYPE_ARG_TYPES' are a `TREE_LIST' of the argument 8120 types. The `TREE_VALUE' of each node in this list is the type of 8121 the corresponding argument; the `TREE_PURPOSE' is an expression 8122 for the default argument value, if any. If the last node in the 8123 list is `void_list_node' (a `TREE_LIST' node whose `TREE_VALUE' is 8124 the `void_type_node'), then functions of this type do not take 8125 variable arguments. Otherwise, they do take a variable number of 8126 arguments. 8127 8128 Note that in C (but not in C++) a function declared like `void f()' 8129 is an unprototyped function taking a variable number of arguments; 8130 the `TYPE_ARG_TYPES' of such a function will be `NULL'. 8131 8132`METHOD_TYPE' 8133 Used to represent the type of a non-static member function. Like a 8134 `FUNCTION_TYPE', the return type is given by the `TREE_TYPE'. The 8135 type of `*this', i.e., the class of which functions of this type 8136 are a member, is given by the `TYPE_METHOD_BASETYPE'. The 8137 `TYPE_ARG_TYPES' is the parameter list, as for a `FUNCTION_TYPE', 8138 and includes the `this' argument. 8139 8140`ARRAY_TYPE' 8141 Used to represent array types. The `TREE_TYPE' gives the type of 8142 the elements in the array. If the array-bound is present in the 8143 type, the `TYPE_DOMAIN' is an `INTEGER_TYPE' whose 8144 `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE' will be the lower and upper 8145 bounds of the array, respectively. The `TYPE_MIN_VALUE' will 8146 always be an `INTEGER_CST' for zero, while the `TYPE_MAX_VALUE' 8147 will be one less than the number of elements in the array, i.e., 8148 the highest value which may be used to index an element in the 8149 array. 8150 8151`RECORD_TYPE' 8152 Used to represent `struct' and `class' types, as well as pointers 8153 to member functions and similar constructs in other languages. 8154 `TYPE_FIELDS' contains the items contained in this type, each of 8155 which can be a `FIELD_DECL', `VAR_DECL', `CONST_DECL', or 8156 `TYPE_DECL'. You may not make any assumptions about the ordering 8157 of the fields in the type or whether one or more of them overlap. 8158 8159`UNION_TYPE' 8160 Used to represent `union' types. Similar to `RECORD_TYPE' except 8161 that all `FIELD_DECL' nodes in `TYPE_FIELD' start at bit position 8162 zero. 8163 8164`QUAL_UNION_TYPE' 8165 Used to represent part of a variant record in Ada. Similar to 8166 `UNION_TYPE' except that each `FIELD_DECL' has a `DECL_QUALIFIER' 8167 field, which contains a boolean expression that indicates whether 8168 the field is present in the object. The type will only have one 8169 field, so each field's `DECL_QUALIFIER' is only evaluated if none 8170 of the expressions in the previous fields in `TYPE_FIELDS' are 8171 nonzero. Normally these expressions will reference a field in the 8172 outer object using a `PLACEHOLDER_EXPR'. 8173 8174`LANG_TYPE' 8175 This node is used to represent a language-specific type. The front 8176 end must handle it. 8177 8178`OFFSET_TYPE' 8179 This node is used to represent a pointer-to-data member. For a 8180 data member `X::m' the `TYPE_OFFSET_BASETYPE' is `X' and the 8181 `TREE_TYPE' is the type of `m'. 8182 8183 8184 There are variables whose values represent some of the basic types. 8185These include: 8186`void_type_node' 8187 A node for `void'. 8188 8189`integer_type_node' 8190 A node for `int'. 8191 8192`unsigned_type_node.' 8193 A node for `unsigned int'. 8194 8195`char_type_node.' 8196 A node for `char'. 8197 It may sometimes be useful to compare one of these variables with a 8198type in hand, using `same_type_p'. 8199 8200 8201File: gccint.info, Node: Declarations, Next: Attributes, Prev: Types, Up: GENERIC 8202 820310.4 Declarations 8204================= 8205 8206This section covers the various kinds of declarations that appear in the 8207internal representation, except for declarations of functions 8208(represented by `FUNCTION_DECL' nodes), which are described in *note 8209Functions::. 8210 8211* Menu: 8212 8213* Working with declarations:: Macros and functions that work on 8214declarations. 8215* Internal structure:: How declaration nodes are represented. 8216 8217 8218File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations 8219 822010.4.1 Working with declarations 8221-------------------------------- 8222 8223Some macros can be used with any kind of declaration. These include: 8224`DECL_NAME' 8225 This macro returns an `IDENTIFIER_NODE' giving the name of the 8226 entity. 8227 8228`TREE_TYPE' 8229 This macro returns the type of the entity declared. 8230 8231`EXPR_FILENAME' 8232 This macro returns the name of the file in which the entity was 8233 declared, as a `char*'. For an entity declared implicitly by the 8234 compiler (like `__builtin_memcpy'), this will be the string 8235 `"<internal>"'. 8236 8237`EXPR_LINENO' 8238 This macro returns the line number at which the entity was 8239 declared, as an `int'. 8240 8241`DECL_ARTIFICIAL' 8242 This predicate holds if the declaration was implicitly generated 8243 by the compiler. For example, this predicate will hold of an 8244 implicitly declared member function, or of the `TYPE_DECL' 8245 implicitly generated for a class type. Recall that in C++ code 8246 like: 8247 struct S {}; 8248 is roughly equivalent to C code like: 8249 struct S {}; 8250 typedef struct S S; 8251 The implicitly generated `typedef' declaration is represented by a 8252 `TYPE_DECL' for which `DECL_ARTIFICIAL' holds. 8253 8254 8255 The various kinds of declarations include: 8256`LABEL_DECL' 8257 These nodes are used to represent labels in function bodies. For 8258 more information, see *note Functions::. These nodes only appear 8259 in block scopes. 8260 8261`CONST_DECL' 8262 These nodes are used to represent enumeration constants. The 8263 value of the constant is given by `DECL_INITIAL' which will be an 8264 `INTEGER_CST' with the same type as the `TREE_TYPE' of the 8265 `CONST_DECL', i.e., an `ENUMERAL_TYPE'. 8266 8267`RESULT_DECL' 8268 These nodes represent the value returned by a function. When a 8269 value is assigned to a `RESULT_DECL', that indicates that the 8270 value should be returned, via bitwise copy, by the function. You 8271 can use `DECL_SIZE' and `DECL_ALIGN' on a `RESULT_DECL', just as 8272 with a `VAR_DECL'. 8273 8274`TYPE_DECL' 8275 These nodes represent `typedef' declarations. The `TREE_TYPE' is 8276 the type declared to have the name given by `DECL_NAME'. In some 8277 cases, there is no associated name. 8278 8279`VAR_DECL' 8280 These nodes represent variables with namespace or block scope, as 8281 well as static data members. The `DECL_SIZE' and `DECL_ALIGN' are 8282 analogous to `TYPE_SIZE' and `TYPE_ALIGN'. For a declaration, you 8283 should always use the `DECL_SIZE' and `DECL_ALIGN' rather than the 8284 `TYPE_SIZE' and `TYPE_ALIGN' given by the `TREE_TYPE', since 8285 special attributes may have been applied to the variable to give 8286 it a particular size and alignment. You may use the predicates 8287 `DECL_THIS_STATIC' or `DECL_THIS_EXTERN' to test whether the 8288 storage class specifiers `static' or `extern' were used to declare 8289 a variable. 8290 8291 If this variable is initialized (but does not require a 8292 constructor), the `DECL_INITIAL' will be an expression for the 8293 initializer. The initializer should be evaluated, and a bitwise 8294 copy into the variable performed. If the `DECL_INITIAL' is the 8295 `error_mark_node', there is an initializer, but it is given by an 8296 explicit statement later in the code; no bitwise copy is required. 8297 8298 GCC provides an extension that allows either automatic variables, 8299 or global variables, to be placed in particular registers. This 8300 extension is being used for a particular `VAR_DECL' if 8301 `DECL_REGISTER' holds for the `VAR_DECL', and if 8302 `DECL_ASSEMBLER_NAME' is not equal to `DECL_NAME'. In that case, 8303 `DECL_ASSEMBLER_NAME' is the name of the register into which the 8304 variable will be placed. 8305 8306`PARM_DECL' 8307 Used to represent a parameter to a function. Treat these nodes 8308 similarly to `VAR_DECL' nodes. These nodes only appear in the 8309 `DECL_ARGUMENTS' for a `FUNCTION_DECL'. 8310 8311 The `DECL_ARG_TYPE' for a `PARM_DECL' is the type that will 8312 actually be used when a value is passed to this function. It may 8313 be a wider type than the `TREE_TYPE' of the parameter; for 8314 example, the ordinary type might be `short' while the 8315 `DECL_ARG_TYPE' is `int'. 8316 8317`DEBUG_EXPR_DECL' 8318 Used to represent an anonymous debug-information temporary created 8319 to hold an expression as it is optimized away, so that its value 8320 can be referenced in debug bind statements. 8321 8322`FIELD_DECL' 8323 These nodes represent non-static data members. The `DECL_SIZE' and 8324 `DECL_ALIGN' behave as for `VAR_DECL' nodes. The position of the 8325 field within the parent record is specified by a combination of 8326 three attributes. `DECL_FIELD_OFFSET' is the position, counting 8327 in bytes, of the `DECL_OFFSET_ALIGN'-bit sized word containing the 8328 bit of the field closest to the beginning of the structure. 8329 `DECL_FIELD_BIT_OFFSET' is the bit offset of the first bit of the 8330 field within this word; this may be nonzero even for fields that 8331 are not bit-fields, since `DECL_OFFSET_ALIGN' may be greater than 8332 the natural alignment of the field's type. 8333 8334 If `DECL_C_BIT_FIELD' holds, this field is a bit-field. In a 8335 bit-field, `DECL_BIT_FIELD_TYPE' also contains the type that was 8336 originally specified for it, while DECL_TYPE may be a modified 8337 type with lesser precision, according to the size of the bit field. 8338 8339`NAMESPACE_DECL' 8340 Namespaces provide a name hierarchy for other declarations. They 8341 appear in the `DECL_CONTEXT' of other `_DECL' nodes. 8342 8343 8344 8345File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations 8346 834710.4.2 Internal structure 8348------------------------- 8349 8350`DECL' nodes are represented internally as a hierarchy of structures. 8351 8352* Menu: 8353 8354* Current structure hierarchy:: The current DECL node structure 8355hierarchy. 8356* Adding new DECL node types:: How to add a new DECL node to a 8357frontend. 8358 8359 8360File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure 8361 836210.4.2.1 Current structure hierarchy 8363.................................... 8364 8365`struct tree_decl_minimal' 8366 This is the minimal structure to inherit from in order for common 8367 `DECL' macros to work. The fields it contains are a unique ID, 8368 source location, context, and name. 8369 8370`struct tree_decl_common' 8371 This structure inherits from `struct tree_decl_minimal'. It 8372 contains fields that most `DECL' nodes need, such as a field to 8373 store alignment, machine mode, size, and attributes. 8374 8375`struct tree_field_decl' 8376 This structure inherits from `struct tree_decl_common'. It is 8377 used to represent `FIELD_DECL'. 8378 8379`struct tree_label_decl' 8380 This structure inherits from `struct tree_decl_common'. It is 8381 used to represent `LABEL_DECL'. 8382 8383`struct tree_translation_unit_decl' 8384 This structure inherits from `struct tree_decl_common'. It is 8385 used to represent `TRANSLATION_UNIT_DECL'. 8386 8387`struct tree_decl_with_rtl' 8388 This structure inherits from `struct tree_decl_common'. It 8389 contains a field to store the low-level RTL associated with a 8390 `DECL' node. 8391 8392`struct tree_result_decl' 8393 This structure inherits from `struct tree_decl_with_rtl'. It is 8394 used to represent `RESULT_DECL'. 8395 8396`struct tree_const_decl' 8397 This structure inherits from `struct tree_decl_with_rtl'. It is 8398 used to represent `CONST_DECL'. 8399 8400`struct tree_parm_decl' 8401 This structure inherits from `struct tree_decl_with_rtl'. It is 8402 used to represent `PARM_DECL'. 8403 8404`struct tree_decl_with_vis' 8405 This structure inherits from `struct tree_decl_with_rtl'. It 8406 contains fields necessary to store visibility information, as well 8407 as a section name and assembler name. 8408 8409`struct tree_var_decl' 8410 This structure inherits from `struct tree_decl_with_vis'. It is 8411 used to represent `VAR_DECL'. 8412 8413`struct tree_function_decl' 8414 This structure inherits from `struct tree_decl_with_vis'. It is 8415 used to represent `FUNCTION_DECL'. 8416 8417 8418 8419File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure 8420 842110.4.2.2 Adding new DECL node types 8422................................... 8423 8424Adding a new `DECL' tree consists of the following steps 8425 8426Add a new tree code for the `DECL' node 8427 For language specific `DECL' nodes, there is a `.def' file in each 8428 frontend directory where the tree code should be added. For 8429 `DECL' nodes that are part of the middle-end, the code should be 8430 added to `tree.def'. 8431 8432Create a new structure type for the `DECL' node 8433 These structures should inherit from one of the existing 8434 structures in the language hierarchy by using that structure as 8435 the first member. 8436 8437 struct tree_foo_decl 8438 { 8439 struct tree_decl_with_vis common; 8440 } 8441 8442 Would create a structure name `tree_foo_decl' that inherits from 8443 `struct tree_decl_with_vis'. 8444 8445 For language specific `DECL' nodes, this new structure type should 8446 go in the appropriate `.h' file. For `DECL' nodes that are part 8447 of the middle-end, the structure type should go in `tree.h'. 8448 8449Add a member to the tree structure enumerator for the node 8450 For garbage collection and dynamic checking purposes, each `DECL' 8451 node structure type is required to have a unique enumerator value 8452 specified with it. For language specific `DECL' nodes, this new 8453 enumerator value should go in the appropriate `.def' file. For 8454 `DECL' nodes that are part of the middle-end, the enumerator 8455 values are specified in `treestruct.def'. 8456 8457Update `union tree_node' 8458 In order to make your new structure type usable, it must be added 8459 to `union tree_node'. For language specific `DECL' nodes, a new 8460 entry should be added to the appropriate `.h' file of the form 8461 struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl; 8462 For `DECL' nodes that are part of the middle-end, the additional 8463 member goes directly into `union tree_node' in `tree.h'. 8464 8465Update dynamic checking info 8466 In order to be able to check whether accessing a named portion of 8467 `union tree_node' is legal, and whether a certain `DECL' node 8468 contains one of the enumerated `DECL' node structures in the 8469 hierarchy, a simple lookup table is used. This lookup table needs 8470 to be kept up to date with the tree structure hierarchy, or else 8471 checking and containment macros will fail inappropriately. 8472 8473 For language specific `DECL' nodes, their is an `init_ts' function 8474 in an appropriate `.c' file, which initializes the lookup table. 8475 Code setting up the table for new `DECL' nodes should be added 8476 there. For each `DECL' tree code and enumerator value 8477 representing a member of the inheritance hierarchy, the table 8478 should contain 1 if that tree code inherits (directly or 8479 indirectly) from that member. Thus, a `FOO_DECL' node derived 8480 from `struct decl_with_rtl', and enumerator value `TS_FOO_DECL', 8481 would be set up as follows 8482 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1; 8483 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1; 8484 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1; 8485 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1; 8486 8487 For `DECL' nodes that are part of the middle-end, the setup code 8488 goes into `tree.c'. 8489 8490Add macros to access any new fields and flags 8491 Each added field or flag should have a macro that is used to access 8492 it, that performs appropriate checking to ensure only the right 8493 type of `DECL' nodes access the field. 8494 8495 These macros generally take the following form 8496 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname 8497 However, if the structure is simply a base class for further 8498 structures, something like the following should be used 8499 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT) 8500 #define BASE_STRUCT_FIELDNAME(NODE) \ 8501 (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname 8502 8503 Reading them from the generated `all-tree.def' file (which in turn 8504 includes all the `tree.def' files), `gencheck.c' is used during 8505 GCC's build to generate the `*_CHECK' macros for all tree codes. 8506 8507 8508 8509File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: GENERIC 8510 851110.5 Attributes in trees 8512======================== 8513 8514Attributes, as specified using the `__attribute__' keyword, are 8515represented internally as a `TREE_LIST'. The `TREE_PURPOSE' is the 8516name of the attribute, as an `IDENTIFIER_NODE'. The `TREE_VALUE' is a 8517`TREE_LIST' of the arguments of the attribute, if any, or `NULL_TREE' 8518if there are no arguments; the arguments are stored as the `TREE_VALUE' 8519of successive entries in the list, and may be identifiers or 8520expressions. The `TREE_CHAIN' of the attribute is the next attribute 8521in a list of attributes applying to the same declaration or type, or 8522`NULL_TREE' if there are no further attributes in the list. 8523 8524 Attributes may be attached to declarations and to types; these 8525attributes may be accessed with the following macros. All attributes 8526are stored in this way, and many also cause other changes to the 8527declaration or type or to other internal compiler data structures. 8528 8529 -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL) 8530 This macro returns the attributes on the declaration DECL. 8531 8532 -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE) 8533 This macro returns the attributes on the type TYPE. 8534 8535 8536File: gccint.info, Node: Expression trees, Next: Statements, Prev: Attributes, Up: GENERIC 8537 853810.6 Expressions 8539================ 8540 8541The internal representation for expressions is for the most part quite 8542straightforward. However, there are a few facts that one must bear in 8543mind. In particular, the expression "tree" is actually a directed 8544acyclic graph. (For example there may be many references to the integer 8545constant zero throughout the source program; many of these will be 8546represented by the same expression node.) You should not rely on 8547certain kinds of node being shared, nor should you rely on certain 8548kinds of nodes being unshared. 8549 8550 The following macros can be used with all expression nodes: 8551 8552`TREE_TYPE' 8553 Returns the type of the expression. This value may not be 8554 precisely the same type that would be given the expression in the 8555 original program. 8556 8557 In what follows, some nodes that one might expect to always have type 8558`bool' are documented to have either integral or boolean type. At some 8559point in the future, the C front end may also make use of this same 8560intermediate representation, and at this point these nodes will 8561certainly have integral type. The previous sentence is not meant to 8562imply that the C++ front end does not or will not give these nodes 8563integral type. 8564 8565 Below, we list the various kinds of expression nodes. Except where 8566noted otherwise, the operands to an expression are accessed using the 8567`TREE_OPERAND' macro. For example, to access the first operand to a 8568binary plus expression `expr', use: 8569 8570 TREE_OPERAND (expr, 0) 8571 As this example indicates, the operands are zero-indexed. 8572 8573* Menu: 8574 8575* Constants: Constant expressions. 8576* Storage References:: 8577* Unary and Binary Expressions:: 8578* Vectors:: 8579 8580 8581File: gccint.info, Node: Constant expressions, Next: Storage References, Up: Expression trees 8582 858310.6.1 Constant expressions 8584--------------------------- 8585 8586The table below begins with constants, moves on to unary expressions, 8587then proceeds to binary expressions, and concludes with various other 8588kinds of expressions: 8589 8590`INTEGER_CST' 8591 These nodes represent integer constants. Note that the type of 8592 these constants is obtained with `TREE_TYPE'; they are not always 8593 of type `int'. In particular, `char' constants are represented 8594 with `INTEGER_CST' nodes. The value of the integer constant `e' is 8595 represented in an array of HOST_WIDE_INT. There are enough 8596 elements in the array to represent the value without taking extra 8597 elements for redundant 0s or -1. The number of elements used to 8598 represent `e' is available via `TREE_INT_CST_NUNITS'. Element `i' 8599 can be extracted by using `TREE_INT_CST_ELT (e, i)'. 8600 `TREE_INT_CST_LOW' is a shorthand for `TREE_INT_CST_ELT (e, 0)'. 8601 8602 The functions `tree_fits_shwi_p' and `tree_fits_uhwi_p' can be 8603 used to tell if the value is small enough to fit in a signed 8604 HOST_WIDE_INT or an unsigned HOST_WIDE_INT respectively. The 8605 value can then be extracted using `tree_to_shwi' and 8606 `tree_to_uhwi'. 8607 8608`REAL_CST' 8609 FIXME: Talk about how to obtain representations of this constant, 8610 do comparisons, and so forth. 8611 8612`FIXED_CST' 8613 These nodes represent fixed-point constants. The type of these 8614 constants is obtained with `TREE_TYPE'. `TREE_FIXED_CST_PTR' 8615 points to a `struct fixed_value'; `TREE_FIXED_CST' returns the 8616 structure itself. `struct fixed_value' contains `data' with the 8617 size of two `HOST_BITS_PER_WIDE_INT' and `mode' as the associated 8618 fixed-point machine mode for `data'. 8619 8620`COMPLEX_CST' 8621 These nodes are used to represent complex number constants, that 8622 is a `__complex__' whose parts are constant nodes. The 8623 `TREE_REALPART' and `TREE_IMAGPART' return the real and the 8624 imaginary parts respectively. 8625 8626`VECTOR_CST' 8627 These nodes are used to represent vector constants, whose parts are 8628 constant nodes. Each individual constant node is either an 8629 integer or a double constant node. The first operand is a 8630 `TREE_LIST' of the constant nodes and is accessed through 8631 `TREE_VECTOR_CST_ELTS'. 8632 8633`STRING_CST' 8634 These nodes represent string-constants. The `TREE_STRING_LENGTH' 8635 returns the length of the string, as an `int'. The 8636 `TREE_STRING_POINTER' is a `char*' containing the string itself. 8637 The string may not be `NUL'-terminated, and it may contain 8638 embedded `NUL' characters. Therefore, the `TREE_STRING_LENGTH' 8639 includes the trailing `NUL' if it is present. 8640 8641 For wide string constants, the `TREE_STRING_LENGTH' is the number 8642 of bytes in the string, and the `TREE_STRING_POINTER' points to an 8643 array of the bytes of the string, as represented on the target 8644 system (that is, as integers in the target endianness). Wide and 8645 non-wide string constants are distinguished only by the `TREE_TYPE' 8646 of the `STRING_CST'. 8647 8648 FIXME: The formats of string constants are not well-defined when 8649 the target system bytes are not the same width as host system 8650 bytes. 8651 8652 8653 8654File: gccint.info, Node: Storage References, Next: Unary and Binary Expressions, Prev: Constant expressions, Up: Expression trees 8655 865610.6.2 References to storage 8657---------------------------- 8658 8659`ARRAY_REF' 8660 These nodes represent array accesses. The first operand is the 8661 array; the second is the index. To calculate the address of the 8662 memory accessed, you must scale the index by the size of the type 8663 of the array elements. The type of these expressions must be the 8664 type of a component of the array. The third and fourth operands 8665 are used after gimplification to represent the lower bound and 8666 component size but should not be used directly; call 8667 `array_ref_low_bound' and `array_ref_element_size' instead. 8668 8669`ARRAY_RANGE_REF' 8670 These nodes represent access to a range (or "slice") of an array. 8671 The operands are the same as that for `ARRAY_REF' and have the same 8672 meanings. The type of these expressions must be an array whose 8673 component type is the same as that of the first operand. The 8674 range of that array type determines the amount of data these 8675 expressions access. 8676 8677`TARGET_MEM_REF' 8678 These nodes represent memory accesses whose address directly map to 8679 an addressing mode of the target architecture. The first argument 8680 is `TMR_SYMBOL' and must be a `VAR_DECL' of an object with a fixed 8681 address. The second argument is `TMR_BASE' and the third one is 8682 `TMR_INDEX'. The fourth argument is `TMR_STEP' and must be an 8683 `INTEGER_CST'. The fifth argument is `TMR_OFFSET' and must be an 8684 `INTEGER_CST'. Any of the arguments may be NULL if the 8685 appropriate component does not appear in the address. Address of 8686 the `TARGET_MEM_REF' is determined in the following way. 8687 8688 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET 8689 8690 The sixth argument is the reference to the original memory access, 8691 which is preserved for the purposes of the RTL alias analysis. 8692 The seventh argument is a tag representing the results of tree 8693 level alias analysis. 8694 8695`ADDR_EXPR' 8696 These nodes are used to represent the address of an object. (These 8697 expressions will always have pointer or reference type.) The 8698 operand may be another expression, or it may be a declaration. 8699 8700 As an extension, GCC allows users to take the address of a label. 8701 In this case, the operand of the `ADDR_EXPR' will be a 8702 `LABEL_DECL'. The type of such an expression is `void*'. 8703 8704 If the object addressed is not an lvalue, a temporary is created, 8705 and the address of the temporary is used. 8706 8707`INDIRECT_REF' 8708 These nodes are used to represent the object pointed to by a 8709 pointer. The operand is the pointer being dereferenced; it will 8710 always have pointer or reference type. 8711 8712`MEM_REF' 8713 These nodes are used to represent the object pointed to by a 8714 pointer offset by a constant. The first operand is the pointer 8715 being dereferenced; it will always have pointer or reference type. 8716 The second operand is a pointer constant. Its type is specifying 8717 the type to be used for type-based alias analysis. 8718 8719`COMPONENT_REF' 8720 These nodes represent non-static data member accesses. The first 8721 operand is the object (rather than a pointer to it); the second 8722 operand is the `FIELD_DECL' for the data member. The third 8723 operand represents the byte offset of the field, but should not be 8724 used directly; call `component_ref_field_offset' instead. 8725 8726 8727 8728File: gccint.info, Node: Unary and Binary Expressions, Next: Vectors, Prev: Storage References, Up: Expression trees 8729 873010.6.3 Unary and Binary Expressions 8731----------------------------------- 8732 8733`NEGATE_EXPR' 8734 These nodes represent unary negation of the single operand, for 8735 both integer and floating-point types. The type of negation can be 8736 determined by looking at the type of the expression. 8737 8738 The behavior of this operation on signed arithmetic overflow is 8739 controlled by the `flag_wrapv' and `flag_trapv' variables. 8740 8741`ABS_EXPR' 8742 These nodes represent the absolute value of the single operand, for 8743 both integer and floating-point types. This is typically used to 8744 implement the `abs', `labs' and `llabs' builtins for integer 8745 types, and the `fabs', `fabsf' and `fabsl' builtins for floating 8746 point types. The type of abs operation can be determined by 8747 looking at the type of the expression. 8748 8749 This node is not used for complex types. To represent the modulus 8750 or complex abs of a complex value, use the `BUILT_IN_CABS', 8751 `BUILT_IN_CABSF' or `BUILT_IN_CABSL' builtins, as used to 8752 implement the C99 `cabs', `cabsf' and `cabsl' built-in functions. 8753 8754`BIT_NOT_EXPR' 8755 These nodes represent bitwise complement, and will always have 8756 integral type. The only operand is the value to be complemented. 8757 8758`TRUTH_NOT_EXPR' 8759 These nodes represent logical negation, and will always have 8760 integral (or boolean) type. The operand is the value being 8761 negated. The type of the operand and that of the result are 8762 always of `BOOLEAN_TYPE' or `INTEGER_TYPE'. 8763 8764`PREDECREMENT_EXPR' 8765`PREINCREMENT_EXPR' 8766`POSTDECREMENT_EXPR' 8767`POSTINCREMENT_EXPR' 8768 These nodes represent increment and decrement expressions. The 8769 value of the single operand is computed, and the operand 8770 incremented or decremented. In the case of `PREDECREMENT_EXPR' and 8771 `PREINCREMENT_EXPR', the value of the expression is the value 8772 resulting after the increment or decrement; in the case of 8773 `POSTDECREMENT_EXPR' and `POSTINCREMENT_EXPR' is the value before 8774 the increment or decrement occurs. The type of the operand, like 8775 that of the result, will be either integral, boolean, or 8776 floating-point. 8777 8778`FIX_TRUNC_EXPR' 8779 These nodes represent conversion of a floating-point value to an 8780 integer. The single operand will have a floating-point type, while 8781 the complete expression will have an integral (or boolean) type. 8782 The operand is rounded towards zero. 8783 8784`FLOAT_EXPR' 8785 These nodes represent conversion of an integral (or boolean) value 8786 to a floating-point value. The single operand will have integral 8787 type, while the complete expression will have a floating-point 8788 type. 8789 8790 FIXME: How is the operand supposed to be rounded? Is this 8791 dependent on `-mieee'? 8792 8793`COMPLEX_EXPR' 8794 These nodes are used to represent complex numbers constructed from 8795 two expressions of the same (integer or real) type. The first 8796 operand is the real part and the second operand is the imaginary 8797 part. 8798 8799`CONJ_EXPR' 8800 These nodes represent the conjugate of their operand. 8801 8802`REALPART_EXPR' 8803`IMAGPART_EXPR' 8804 These nodes represent respectively the real and the imaginary parts 8805 of complex numbers (their sole argument). 8806 8807`NON_LVALUE_EXPR' 8808 These nodes indicate that their one and only operand is not an 8809 lvalue. A back end can treat these identically to the single 8810 operand. 8811 8812`NOP_EXPR' 8813 These nodes are used to represent conversions that do not require 8814 any code-generation. For example, conversion of a `char*' to an 8815 `int*' does not require any code be generated; such a conversion is 8816 represented by a `NOP_EXPR'. The single operand is the expression 8817 to be converted. The conversion from a pointer to a reference is 8818 also represented with a `NOP_EXPR'. 8819 8820`CONVERT_EXPR' 8821 These nodes are similar to `NOP_EXPR's, but are used in those 8822 situations where code may need to be generated. For example, if an 8823 `int*' is converted to an `int' code may need to be generated on 8824 some platforms. These nodes are never used for C++-specific 8825 conversions, like conversions between pointers to different 8826 classes in an inheritance hierarchy. Any adjustments that need to 8827 be made in such cases are always indicated explicitly. Similarly, 8828 a user-defined conversion is never represented by a 8829 `CONVERT_EXPR'; instead, the function calls are made explicit. 8830 8831`FIXED_CONVERT_EXPR' 8832 These nodes are used to represent conversions that involve 8833 fixed-point values. For example, from a fixed-point value to 8834 another fixed-point value, from an integer to a fixed-point value, 8835 from a fixed-point value to an integer, from a floating-point 8836 value to a fixed-point value, or from a fixed-point value to a 8837 floating-point value. 8838 8839`LSHIFT_EXPR' 8840`RSHIFT_EXPR' 8841 These nodes represent left and right shifts, respectively. The 8842 first operand is the value to shift; it will always be of integral 8843 type. The second operand is an expression for the number of bits 8844 by which to shift. Right shift should be treated as arithmetic, 8845 i.e., the high-order bits should be zero-filled when the 8846 expression has unsigned type and filled with the sign bit when the 8847 expression has signed type. Note that the result is undefined if 8848 the second operand is larger than or equal to the first operand's 8849 type size. Unlike most nodes, these can have a vector as first 8850 operand and a scalar as second operand. 8851 8852`BIT_IOR_EXPR' 8853`BIT_XOR_EXPR' 8854`BIT_AND_EXPR' 8855 These nodes represent bitwise inclusive or, bitwise exclusive or, 8856 and bitwise and, respectively. Both operands will always have 8857 integral type. 8858 8859`TRUTH_ANDIF_EXPR' 8860`TRUTH_ORIF_EXPR' 8861 These nodes represent logical "and" and logical "or", respectively. 8862 These operators are not strict; i.e., the second operand is 8863 evaluated only if the value of the expression is not determined by 8864 evaluation of the first operand. The type of the operands and 8865 that of the result are always of `BOOLEAN_TYPE' or `INTEGER_TYPE'. 8866 8867`TRUTH_AND_EXPR' 8868`TRUTH_OR_EXPR' 8869`TRUTH_XOR_EXPR' 8870 These nodes represent logical and, logical or, and logical 8871 exclusive or. They are strict; both arguments are always 8872 evaluated. There are no corresponding operators in C or C++, but 8873 the front end will sometimes generate these expressions anyhow, if 8874 it can tell that strictness does not matter. The type of the 8875 operands and that of the result are always of `BOOLEAN_TYPE' or 8876 `INTEGER_TYPE'. 8877 8878`POINTER_PLUS_EXPR' 8879 This node represents pointer arithmetic. The first operand is 8880 always a pointer/reference type. The second operand is always an 8881 unsigned integer type compatible with sizetype. This is the only 8882 binary arithmetic operand that can operate on pointer types. 8883 8884`PLUS_EXPR' 8885`MINUS_EXPR' 8886`MULT_EXPR' 8887 These nodes represent various binary arithmetic operations. 8888 Respectively, these operations are addition, subtraction (of the 8889 second operand from the first) and multiplication. Their operands 8890 may have either integral or floating type, but there will never be 8891 case in which one operand is of floating type and the other is of 8892 integral type. 8893 8894 The behavior of these operations on signed arithmetic overflow is 8895 controlled by the `flag_wrapv' and `flag_trapv' variables. 8896 8897`MULT_HIGHPART_EXPR' 8898 This node represents the "high-part" of a widening multiplication. 8899 For an integral type with B bits of precision, the result is the 8900 most significant B bits of the full 2B product. 8901 8902`RDIV_EXPR' 8903 This node represents a floating point division operation. 8904 8905`TRUNC_DIV_EXPR' 8906`FLOOR_DIV_EXPR' 8907`CEIL_DIV_EXPR' 8908`ROUND_DIV_EXPR' 8909 These nodes represent integer division operations that return an 8910 integer result. `TRUNC_DIV_EXPR' rounds towards zero, 8911 `FLOOR_DIV_EXPR' rounds towards negative infinity, `CEIL_DIV_EXPR' 8912 rounds towards positive infinity and `ROUND_DIV_EXPR' rounds to 8913 the closest integer. Integer division in C and C++ is truncating, 8914 i.e. `TRUNC_DIV_EXPR'. 8915 8916 The behavior of these operations on signed arithmetic overflow, 8917 when dividing the minimum signed integer by minus one, is 8918 controlled by the `flag_wrapv' and `flag_trapv' variables. 8919 8920`TRUNC_MOD_EXPR' 8921`FLOOR_MOD_EXPR' 8922`CEIL_MOD_EXPR' 8923`ROUND_MOD_EXPR' 8924 These nodes represent the integer remainder or modulus operation. 8925 The integer modulus of two operands `a' and `b' is defined as `a - 8926 (a/b)*b' where the division calculated using the corresponding 8927 division operator. Hence for `TRUNC_MOD_EXPR' this definition 8928 assumes division using truncation towards zero, i.e. 8929 `TRUNC_DIV_EXPR'. Integer remainder in C and C++ uses truncating 8930 division, i.e. `TRUNC_MOD_EXPR'. 8931 8932`EXACT_DIV_EXPR' 8933 The `EXACT_DIV_EXPR' code is used to represent integer divisions 8934 where the numerator is known to be an exact multiple of the 8935 denominator. This allows the backend to choose between the faster 8936 of `TRUNC_DIV_EXPR', `CEIL_DIV_EXPR' and `FLOOR_DIV_EXPR' for the 8937 current target. 8938 8939`LT_EXPR' 8940`LE_EXPR' 8941`GT_EXPR' 8942`GE_EXPR' 8943`EQ_EXPR' 8944`NE_EXPR' 8945 These nodes represent the less than, less than or equal to, greater 8946 than, greater than or equal to, equal, and not equal comparison 8947 operators. The first and second operands will either be both of 8948 integral type, both of floating type or both of vector type. The 8949 result type of these expressions will always be of integral, 8950 boolean or signed integral vector type. These operations return 8951 the result type's zero value for false, the result type's one 8952 value for true, and a vector whose elements are zero (false) or 8953 minus one (true) for vectors. 8954 8955 For floating point comparisons, if we honor IEEE NaNs and either 8956 operand is NaN, then `NE_EXPR' always returns true and the 8957 remaining operators always return false. On some targets, 8958 comparisons against an IEEE NaN, other than equality and 8959 inequality, may generate a floating point exception. 8960 8961`ORDERED_EXPR' 8962`UNORDERED_EXPR' 8963 These nodes represent non-trapping ordered and unordered comparison 8964 operators. These operations take two floating point operands and 8965 determine whether they are ordered or unordered relative to each 8966 other. If either operand is an IEEE NaN, their comparison is 8967 defined to be unordered, otherwise the comparison is defined to be 8968 ordered. The result type of these expressions will always be of 8969 integral or boolean type. These operations return the result 8970 type's zero value for false, and the result type's one value for 8971 true. 8972 8973`UNLT_EXPR' 8974`UNLE_EXPR' 8975`UNGT_EXPR' 8976`UNGE_EXPR' 8977`UNEQ_EXPR' 8978`LTGT_EXPR' 8979 These nodes represent the unordered comparison operators. These 8980 operations take two floating point operands and determine whether 8981 the operands are unordered or are less than, less than or equal to, 8982 greater than, greater than or equal to, or equal respectively. For 8983 example, `UNLT_EXPR' returns true if either operand is an IEEE NaN 8984 or the first operand is less than the second. With the possible 8985 exception of `LTGT_EXPR', all of these operations are guaranteed 8986 not to generate a floating point exception. The result type of 8987 these expressions will always be of integral or boolean type. 8988 These operations return the result type's zero value for false, 8989 and the result type's one value for true. 8990 8991`MODIFY_EXPR' 8992 These nodes represent assignment. The left-hand side is the first 8993 operand; the right-hand side is the second operand. The left-hand 8994 side will be a `VAR_DECL', `INDIRECT_REF', `COMPONENT_REF', or 8995 other lvalue. 8996 8997 These nodes are used to represent not only assignment with `=' but 8998 also compound assignments (like `+='), by reduction to `=' 8999 assignment. In other words, the representation for `i += 3' looks 9000 just like that for `i = i + 3'. 9001 9002`INIT_EXPR' 9003 These nodes are just like `MODIFY_EXPR', but are used only when a 9004 variable is initialized, rather than assigned to subsequently. 9005 This means that we can assume that the target of the 9006 initialization is not used in computing its own value; any 9007 reference to the lhs in computing the rhs is undefined. 9008 9009`COMPOUND_EXPR' 9010 These nodes represent comma-expressions. The first operand is an 9011 expression whose value is computed and thrown away prior to the 9012 evaluation of the second operand. The value of the entire 9013 expression is the value of the second operand. 9014 9015`COND_EXPR' 9016 These nodes represent `?:' expressions. The first operand is of 9017 boolean or integral type. If it evaluates to a nonzero value, the 9018 second operand should be evaluated, and returned as the value of 9019 the expression. Otherwise, the third operand is evaluated, and 9020 returned as the value of the expression. 9021 9022 The second operand must have the same type as the entire 9023 expression, unless it unconditionally throws an exception or calls 9024 a noreturn function, in which case it should have void type. The 9025 same constraints apply to the third operand. This allows array 9026 bounds checks to be represented conveniently as `(i >= 0 && i < 9027 10) ? i : abort()'. 9028 9029 As a GNU extension, the C language front-ends allow the second 9030 operand of the `?:' operator may be omitted in the source. For 9031 example, `x ? : 3' is equivalent to `x ? x : 3', assuming that `x' 9032 is an expression without side-effects. In the tree 9033 representation, however, the second operand is always present, 9034 possibly protected by `SAVE_EXPR' if the first argument does cause 9035 side-effects. 9036 9037`CALL_EXPR' 9038 These nodes are used to represent calls to functions, including 9039 non-static member functions. `CALL_EXPR's are implemented as 9040 expression nodes with a variable number of operands. Rather than 9041 using `TREE_OPERAND' to extract them, it is preferable to use the 9042 specialized accessor macros and functions that operate 9043 specifically on `CALL_EXPR' nodes. 9044 9045 `CALL_EXPR_FN' returns a pointer to the function to call; it is 9046 always an expression whose type is a `POINTER_TYPE'. 9047 9048 The number of arguments to the call is returned by 9049 `call_expr_nargs', while the arguments themselves can be accessed 9050 with the `CALL_EXPR_ARG' macro. The arguments are zero-indexed 9051 and numbered left-to-right. You can iterate over the arguments 9052 using `FOR_EACH_CALL_EXPR_ARG', as in: 9053 9054 tree call, arg; 9055 call_expr_arg_iterator iter; 9056 FOR_EACH_CALL_EXPR_ARG (arg, iter, call) 9057 /* arg is bound to successive arguments of call. */ 9058 ...; 9059 9060 For non-static member functions, there will be an operand 9061 corresponding to the `this' pointer. There will always be 9062 expressions corresponding to all of the arguments, even if the 9063 function is declared with default arguments and some arguments are 9064 not explicitly provided at the call sites. 9065 9066 `CALL_EXPR's also have a `CALL_EXPR_STATIC_CHAIN' operand that is 9067 used to implement nested functions. This operand is otherwise 9068 null. 9069 9070`CLEANUP_POINT_EXPR' 9071 These nodes represent full-expressions. The single operand is an 9072 expression to evaluate. Any destructor calls engendered by the 9073 creation of temporaries during the evaluation of that expression 9074 should be performed immediately after the expression is evaluated. 9075 9076`CONSTRUCTOR' 9077 These nodes represent the brace-enclosed initializers for a 9078 structure or an array. They contain a sequence of component 9079 values made out of a vector of constructor_elt, which is a 9080 (`INDEX', `VALUE') pair. 9081 9082 If the `TREE_TYPE' of the `CONSTRUCTOR' is a `RECORD_TYPE', 9083 `UNION_TYPE' or `QUAL_UNION_TYPE' then the `INDEX' of each node in 9084 the sequence will be a `FIELD_DECL' and the `VALUE' will be the 9085 expression used to initialize that field. 9086 9087 If the `TREE_TYPE' of the `CONSTRUCTOR' is an `ARRAY_TYPE', then 9088 the `INDEX' of each node in the sequence will be an `INTEGER_CST' 9089 or a `RANGE_EXPR' of two `INTEGER_CST's. A single `INTEGER_CST' 9090 indicates which element of the array is being assigned to. A 9091 `RANGE_EXPR' indicates an inclusive range of elements to 9092 initialize. In both cases the `VALUE' is the corresponding 9093 initializer. It is re-evaluated for each element of a 9094 `RANGE_EXPR'. If the `INDEX' is `NULL_TREE', then the initializer 9095 is for the next available array element. 9096 9097 In the front end, you should not depend on the fields appearing in 9098 any particular order. However, in the middle end, fields must 9099 appear in declaration order. You should not assume that all 9100 fields will be represented. Unrepresented fields will be cleared 9101 (zeroed), unless the CONSTRUCTOR_NO_CLEARING flag is set, in which 9102 case their value becomes undefined. 9103 9104`COMPOUND_LITERAL_EXPR' 9105 These nodes represent ISO C99 compound literals. The 9106 `COMPOUND_LITERAL_EXPR_DECL_EXPR' is a `DECL_EXPR' containing an 9107 anonymous `VAR_DECL' for the unnamed object represented by the 9108 compound literal; the `DECL_INITIAL' of that `VAR_DECL' is a 9109 `CONSTRUCTOR' representing the brace-enclosed list of initializers 9110 in the compound literal. That anonymous `VAR_DECL' can also be 9111 accessed directly by the `COMPOUND_LITERAL_EXPR_DECL' macro. 9112 9113`SAVE_EXPR' 9114 A `SAVE_EXPR' represents an expression (possibly involving 9115 side-effects) that is used more than once. The side-effects should 9116 occur only the first time the expression is evaluated. Subsequent 9117 uses should just reuse the computed value. The first operand to 9118 the `SAVE_EXPR' is the expression to evaluate. The side-effects 9119 should be executed where the `SAVE_EXPR' is first encountered in a 9120 depth-first preorder traversal of the expression tree. 9121 9122`TARGET_EXPR' 9123 A `TARGET_EXPR' represents a temporary object. The first operand 9124 is a `VAR_DECL' for the temporary variable. The second operand is 9125 the initializer for the temporary. The initializer is evaluated 9126 and, if non-void, copied (bitwise) into the temporary. If the 9127 initializer is void, that means that it will perform the 9128 initialization itself. 9129 9130 Often, a `TARGET_EXPR' occurs on the right-hand side of an 9131 assignment, or as the second operand to a comma-expression which is 9132 itself the right-hand side of an assignment, etc. In this case, 9133 we say that the `TARGET_EXPR' is "normal"; otherwise, we say it is 9134 "orphaned". For a normal `TARGET_EXPR' the temporary variable 9135 should be treated as an alias for the left-hand side of the 9136 assignment, rather than as a new temporary variable. 9137 9138 The third operand to the `TARGET_EXPR', if present, is a 9139 cleanup-expression (i.e., destructor call) for the temporary. If 9140 this expression is orphaned, then this expression must be executed 9141 when the statement containing this expression is complete. These 9142 cleanups must always be executed in the order opposite to that in 9143 which they were encountered. Note that if a temporary is created 9144 on one branch of a conditional operator (i.e., in the second or 9145 third operand to a `COND_EXPR'), the cleanup must be run only if 9146 that branch is actually executed. 9147 9148`VA_ARG_EXPR' 9149 This node is used to implement support for the C/C++ variable 9150 argument-list mechanism. It represents expressions like `va_arg 9151 (ap, type)'. Its `TREE_TYPE' yields the tree representation for 9152 `type' and its sole argument yields the representation for `ap'. 9153 9154`ANNOTATE_EXPR' 9155 This node is used to attach markers to an expression. The first 9156 operand is the annotated expression, the second is an 9157 `INTEGER_CST' with a value from `enum annot_expr_kind'. 9158 9159 9160File: gccint.info, Node: Vectors, Prev: Unary and Binary Expressions, Up: Expression trees 9161 916210.6.4 Vectors 9163-------------- 9164 9165`VEC_LSHIFT_EXPR' 9166`VEC_RSHIFT_EXPR' 9167 These nodes represent whole vector left and right shifts, 9168 respectively. The first operand is the vector to shift; it will 9169 always be of vector type. The second operand is an expression for 9170 the number of bits by which to shift. Note that the result is 9171 undefined if the second operand is larger than or equal to the 9172 first operand's type size. 9173 9174`VEC_WIDEN_MULT_HI_EXPR' 9175`VEC_WIDEN_MULT_LO_EXPR' 9176 These nodes represent widening vector multiplication of the high 9177 and low parts of the two input vectors, respectively. Their 9178 operands are vectors that contain the same number of elements 9179 (`N') of the same integral type. The result is a vector that 9180 contains half as many elements, of an integral type whose size is 9181 twice as wide. In the case of `VEC_WIDEN_MULT_HI_EXPR' the high 9182 `N/2' elements of the two vector are multiplied to produce the 9183 vector of `N/2' products. In the case of `VEC_WIDEN_MULT_LO_EXPR' 9184 the low `N/2' elements of the two vector are multiplied to produce 9185 the vector of `N/2' products. 9186 9187`VEC_UNPACK_HI_EXPR' 9188`VEC_UNPACK_LO_EXPR' 9189 These nodes represent unpacking of the high and low parts of the 9190 input vector, respectively. The single operand is a vector that 9191 contains `N' elements of the same integral or floating point type. 9192 The result is a vector that contains half as many elements, of an 9193 integral or floating point type whose size is twice as wide. In 9194 the case of `VEC_UNPACK_HI_EXPR' the high `N/2' elements of the 9195 vector are extracted and widened (promoted). In the case of 9196 `VEC_UNPACK_LO_EXPR' the low `N/2' elements of the vector are 9197 extracted and widened (promoted). 9198 9199`VEC_UNPACK_FLOAT_HI_EXPR' 9200`VEC_UNPACK_FLOAT_LO_EXPR' 9201 These nodes represent unpacking of the high and low parts of the 9202 input vector, where the values are converted from fixed point to 9203 floating point. The single operand is a vector that contains `N' 9204 elements of the same integral type. The result is a vector that 9205 contains half as many elements of a floating point type whose size 9206 is twice as wide. In the case of `VEC_UNPACK_HI_EXPR' the high 9207 `N/2' elements of the vector are extracted, converted and widened. 9208 In the case of `VEC_UNPACK_LO_EXPR' the low `N/2' elements of the 9209 vector are extracted, converted and widened. 9210 9211`VEC_PACK_TRUNC_EXPR' 9212 This node represents packing of truncated elements of the two 9213 input vectors into the output vector. Input operands are vectors 9214 that contain the same number of elements of the same integral or 9215 floating point type. The result is a vector that contains twice 9216 as many elements of an integral or floating point type whose size 9217 is half as wide. The elements of the two vectors are demoted and 9218 merged (concatenated) to form the output vector. 9219 9220`VEC_PACK_SAT_EXPR' 9221 This node represents packing of elements of the two input vectors 9222 into the output vector using saturation. Input operands are 9223 vectors that contain the same number of elements of the same 9224 integral type. The result is a vector that contains twice as many 9225 elements of an integral type whose size is half as wide. The 9226 elements of the two vectors are demoted and merged (concatenated) 9227 to form the output vector. 9228 9229`VEC_PACK_FIX_TRUNC_EXPR' 9230 This node represents packing of elements of the two input vectors 9231 into the output vector, where the values are converted from 9232 floating point to fixed point. Input operands are vectors that 9233 contain the same number of elements of a floating point type. The 9234 result is a vector that contains twice as many elements of an 9235 integral type whose size is half as wide. The elements of the two 9236 vectors are merged (concatenated) to form the output vector. 9237 9238`VEC_COND_EXPR' 9239 These nodes represent `?:' expressions. The three operands must be 9240 vectors of the same size and number of elements. The second and 9241 third operands must have the same type as the entire expression. 9242 The first operand is of signed integral vector type. If an 9243 element of the first operand evaluates to a zero value, the 9244 corresponding element of the result is taken from the third 9245 operand. If it evaluates to a minus one value, it is taken from 9246 the second operand. It should never evaluate to any other value 9247 currently, but optimizations should not rely on that property. In 9248 contrast with a `COND_EXPR', all operands are always evaluated. 9249 9250`SAD_EXPR' 9251 This node represents the Sum of Absolute Differences operation. 9252 The three operands must be vectors of integral types. The first 9253 and second operand must have the same type. The size of the 9254 vector element of the third operand must be at lease twice of the 9255 size of the vector element of the first and second one. The SAD 9256 is calculated between the first and second operands, added to the 9257 third operand, and returned. 9258 9259 9260 9261File: gccint.info, Node: Statements, Next: Functions, Prev: Expression trees, Up: GENERIC 9262 926310.7 Statements 9264=============== 9265 9266Most statements in GIMPLE are assignment statements, represented by 9267`GIMPLE_ASSIGN'. No other C expressions can appear at statement level; 9268a reference to a volatile object is converted into a `GIMPLE_ASSIGN'. 9269 9270 There are also several varieties of complex statements. 9271 9272* Menu: 9273 9274* Basic Statements:: 9275* Blocks:: 9276* Statement Sequences:: 9277* Empty Statements:: 9278* Jumps:: 9279* Cleanups:: 9280* OpenMP:: 9281* OpenACC:: 9282 9283 9284File: gccint.info, Node: Basic Statements, Next: Blocks, Up: Statements 9285 928610.7.1 Basic Statements 9287----------------------- 9288 9289`ASM_EXPR' 9290 Used to represent an inline assembly statement. For an inline 9291 assembly statement like: 9292 asm ("mov x, y"); 9293 The `ASM_STRING' macro will return a `STRING_CST' node for `"mov 9294 x, y"'. If the original statement made use of the 9295 extended-assembly syntax, then `ASM_OUTPUTS', `ASM_INPUTS', and 9296 `ASM_CLOBBERS' will be the outputs, inputs, and clobbers for the 9297 statement, represented as `STRING_CST' nodes. The 9298 extended-assembly syntax looks like: 9299 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); 9300 The first string is the `ASM_STRING', containing the instruction 9301 template. The next two strings are the output and inputs, 9302 respectively; this statement has no clobbers. As this example 9303 indicates, "plain" assembly statements are merely a special case 9304 of extended assembly statements; they have no cv-qualifiers, 9305 outputs, inputs, or clobbers. All of the strings will be 9306 `NUL'-terminated, and will contain no embedded `NUL'-characters. 9307 9308 If the assembly statement is declared `volatile', or if the 9309 statement was not an extended assembly statement, and is therefore 9310 implicitly volatile, then the predicate `ASM_VOLATILE_P' will hold 9311 of the `ASM_EXPR'. 9312 9313`DECL_EXPR' 9314 Used to represent a local declaration. The `DECL_EXPR_DECL' macro 9315 can be used to obtain the entity declared. This declaration may 9316 be a `LABEL_DECL', indicating that the label declared is a local 9317 label. (As an extension, GCC allows the declaration of labels 9318 with scope.) In C, this declaration may be a `FUNCTION_DECL', 9319 indicating the use of the GCC nested function extension. For more 9320 information, *note Functions::. 9321 9322`LABEL_EXPR' 9323 Used to represent a label. The `LABEL_DECL' declared by this 9324 statement can be obtained with the `LABEL_EXPR_LABEL' macro. The 9325 `IDENTIFIER_NODE' giving the name of the label can be obtained from 9326 the `LABEL_DECL' with `DECL_NAME'. 9327 9328`GOTO_EXPR' 9329 Used to represent a `goto' statement. The `GOTO_DESTINATION' will 9330 usually be a `LABEL_DECL'. However, if the "computed goto" 9331 extension has been used, the `GOTO_DESTINATION' will be an 9332 arbitrary expression indicating the destination. This expression 9333 will always have pointer type. 9334 9335`RETURN_EXPR' 9336 Used to represent a `return' statement. Operand 0 represents the 9337 value to return. It should either be the `RESULT_DECL' for the 9338 containing function, or a `MODIFY_EXPR' or `INIT_EXPR' setting the 9339 function's `RESULT_DECL'. It will be `NULL_TREE' if the statement 9340 was just 9341 return; 9342 9343`LOOP_EXPR' 9344 These nodes represent "infinite" loops. The `LOOP_EXPR_BODY' 9345 represents the body of the loop. It should be executed forever, 9346 unless an `EXIT_EXPR' is encountered. 9347 9348`EXIT_EXPR' 9349 These nodes represent conditional exits from the nearest enclosing 9350 `LOOP_EXPR'. The single operand is the condition; if it is 9351 nonzero, then the loop should be exited. An `EXIT_EXPR' will only 9352 appear within a `LOOP_EXPR'. 9353 9354`SWITCH_STMT' 9355 Used to represent a `switch' statement. The `SWITCH_STMT_COND' is 9356 the expression on which the switch is occurring. See the 9357 documentation for an `IF_STMT' for more information on the 9358 representation used for the condition. The `SWITCH_STMT_BODY' is 9359 the body of the switch statement. The `SWITCH_STMT_TYPE' is the 9360 original type of switch expression as given in the source, before 9361 any compiler conversions. 9362 9363`CASE_LABEL_EXPR' 9364 Use to represent a `case' label, range of `case' labels, or a 9365 `default' label. If `CASE_LOW' is `NULL_TREE', then this is a 9366 `default' label. Otherwise, if `CASE_HIGH' is `NULL_TREE', then 9367 this is an ordinary `case' label. In this case, `CASE_LOW' is an 9368 expression giving the value of the label. Both `CASE_LOW' and 9369 `CASE_HIGH' are `INTEGER_CST' nodes. These values will have the 9370 same type as the condition expression in the switch statement. 9371 9372 Otherwise, if both `CASE_LOW' and `CASE_HIGH' are defined, the 9373 statement is a range of case labels. Such statements originate 9374 with the extension that allows users to write things of the form: 9375 case 2 ... 5: 9376 The first value will be `CASE_LOW', while the second will be 9377 `CASE_HIGH'. 9378 9379 9380 9381File: gccint.info, Node: Blocks, Next: Statement Sequences, Prev: Basic Statements, Up: Statements 9382 938310.7.2 Blocks 9384------------- 9385 9386Block scopes and the variables they declare in GENERIC are expressed 9387using the `BIND_EXPR' code, which in previous versions of GCC was 9388primarily used for the C statement-expression extension. 9389 9390 Variables in a block are collected into `BIND_EXPR_VARS' in 9391declaration order through their `TREE_CHAIN' field. Any runtime 9392initialization is moved out of `DECL_INITIAL' and into a statement in 9393the controlled block. When gimplifying from C or C++, this 9394initialization replaces the `DECL_STMT'. These variables will never 9395require cleanups. The scope of these variables is just the body 9396 9397 Variable-length arrays (VLAs) complicate this process, as their size 9398often refers to variables initialized earlier in the block. To handle 9399this, we currently split the block at that point, and move the VLA into 9400a new, inner `BIND_EXPR'. This strategy may change in the future. 9401 9402 A C++ program will usually contain more `BIND_EXPR's than there are 9403syntactic blocks in the source code, since several C++ constructs have 9404implicit scopes associated with them. On the other hand, although the 9405C++ front end uses pseudo-scopes to handle cleanups for objects with 9406destructors, these don't translate into the GIMPLE form; multiple 9407declarations at the same level use the same `BIND_EXPR'. 9408 9409 9410File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements 9411 941210.7.3 Statement Sequences 9413-------------------------- 9414 9415Multiple statements at the same nesting level are collected into a 9416`STATEMENT_LIST'. Statement lists are modified and traversed using the 9417interface in `tree-iterator.h'. 9418 9419 9420File: gccint.info, Node: Empty Statements, Next: Jumps, Prev: Statement Sequences, Up: Statements 9421 942210.7.4 Empty Statements 9423----------------------- 9424 9425Whenever possible, statements with no effect are discarded. But if 9426they are nested within another construct which cannot be discarded for 9427some reason, they are instead replaced with an empty statement, 9428generated by `build_empty_stmt'. Initially, all empty statements were 9429shared, after the pattern of the Java front end, but this caused a lot 9430of trouble in practice. 9431 9432 An empty statement is represented as `(void)0'. 9433 9434 9435File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Empty Statements, Up: Statements 9436 943710.7.5 Jumps 9438------------ 9439 9440Other jumps are expressed by either `GOTO_EXPR' or `RETURN_EXPR'. 9441 9442 The operand of a `GOTO_EXPR' must be either a label or a variable 9443containing the address to jump to. 9444 9445 The operand of a `RETURN_EXPR' is either `NULL_TREE', `RESULT_DECL', 9446or a `MODIFY_EXPR' which sets the return value. It would be nice to 9447move the `MODIFY_EXPR' into a separate statement, but the special 9448return semantics in `expand_return' make that difficult. It may still 9449happen in the future, perhaps by moving most of that logic into 9450`expand_assignment'. 9451 9452 9453File: gccint.info, Node: Cleanups, Next: OpenMP, Prev: Jumps, Up: Statements 9454 945510.7.6 Cleanups 9456--------------- 9457 9458Destructors for local C++ objects and similar dynamic cleanups are 9459represented in GIMPLE by a `TRY_FINALLY_EXPR'. `TRY_FINALLY_EXPR' has 9460two operands, both of which are a sequence of statements to execute. 9461The first sequence is executed. When it completes the second sequence 9462is executed. 9463 9464 The first sequence may complete in the following ways: 9465 9466 1. Execute the last statement in the sequence and fall off the end. 9467 9468 2. Execute a goto statement (`GOTO_EXPR') to an ordinary label 9469 outside the sequence. 9470 9471 3. Execute a return statement (`RETURN_EXPR'). 9472 9473 4. Throw an exception. This is currently not explicitly represented 9474 in GIMPLE. 9475 9476 9477 The second sequence is not executed if the first sequence completes by 9478calling `setjmp' or `exit' or any other function that does not return. 9479The second sequence is also not executed if the first sequence 9480completes via a non-local goto or a computed goto (in general the 9481compiler does not know whether such a goto statement exits the first 9482sequence or not, so we assume that it doesn't). 9483 9484 After the second sequence is executed, if it completes normally by 9485falling off the end, execution continues wherever the first sequence 9486would have continued, by falling off the end, or doing a goto, etc. 9487 9488 `TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs 9489to appear on every edge out of the controlled block; this reduces the 9490freedom to move code across these edges. Therefore, the EH lowering 9491pass which runs before most of the optimization passes eliminates these 9492expressions by explicitly adding the cleanup to each edge. Rethrowing 9493the exception is represented using `RESX_EXPR'. 9494 9495 9496File: gccint.info, Node: OpenMP, Next: OpenACC, Prev: Cleanups, Up: Statements 9497 949810.7.7 OpenMP 9499------------- 9500 9501All the statements starting with `OMP_' represent directives and 9502clauses used by the OpenMP API `http://www.openmp.org/'. 9503 9504`OMP_PARALLEL' 9505 Represents `#pragma omp parallel [clause1 ... clauseN]'. It has 9506 four operands: 9507 9508 Operand `OMP_PARALLEL_BODY' is valid while in GENERIC and High 9509 GIMPLE forms. It contains the body of code to be executed by all 9510 the threads. During GIMPLE lowering, this operand becomes `NULL' 9511 and the body is emitted linearly after `OMP_PARALLEL'. 9512 9513 Operand `OMP_PARALLEL_CLAUSES' is the list of clauses associated 9514 with the directive. 9515 9516 Operand `OMP_PARALLEL_FN' is created by `pass_lower_omp', it 9517 contains the `FUNCTION_DECL' for the function that will contain 9518 the body of the parallel region. 9519 9520 Operand `OMP_PARALLEL_DATA_ARG' is also created by 9521 `pass_lower_omp'. If there are shared variables to be communicated 9522 to the children threads, this operand will contain the `VAR_DECL' 9523 that contains all the shared values and variables. 9524 9525`OMP_FOR' 9526 Represents `#pragma omp for [clause1 ... clauseN]'. It has six 9527 operands: 9528 9529 Operand `OMP_FOR_BODY' contains the loop body. 9530 9531 Operand `OMP_FOR_CLAUSES' is the list of clauses associated with 9532 the directive. 9533 9534 Operand `OMP_FOR_INIT' is the loop initialization code of the form 9535 `VAR = N1'. 9536 9537 Operand `OMP_FOR_COND' is the loop conditional expression of the 9538 form `VAR {<,>,<=,>=} N2'. 9539 9540 Operand `OMP_FOR_INCR' is the loop index increment of the form 9541 `VAR {+=,-=} INCR'. 9542 9543 Operand `OMP_FOR_PRE_BODY' contains side-effect code from operands 9544 `OMP_FOR_INIT', `OMP_FOR_COND' and `OMP_FOR_INC'. These 9545 side-effects are part of the `OMP_FOR' block but must be evaluated 9546 before the start of loop body. 9547 9548 The loop index variable `VAR' must be a signed integer variable, 9549 which is implicitly private to each thread. Bounds `N1' and `N2' 9550 and the increment expression `INCR' are required to be loop 9551 invariant integer expressions that are evaluated without any 9552 synchronization. The evaluation order, frequency of evaluation and 9553 side-effects are unspecified by the standard. 9554 9555`OMP_SECTIONS' 9556 Represents `#pragma omp sections [clause1 ... clauseN]'. 9557 9558 Operand `OMP_SECTIONS_BODY' contains the sections body, which in 9559 turn contains a set of `OMP_SECTION' nodes for each of the 9560 concurrent sections delimited by `#pragma omp section'. 9561 9562 Operand `OMP_SECTIONS_CLAUSES' is the list of clauses associated 9563 with the directive. 9564 9565`OMP_SECTION' 9566 Section delimiter for `OMP_SECTIONS'. 9567 9568`OMP_SINGLE' 9569 Represents `#pragma omp single'. 9570 9571 Operand `OMP_SINGLE_BODY' contains the body of code to be executed 9572 by a single thread. 9573 9574 Operand `OMP_SINGLE_CLAUSES' is the list of clauses associated 9575 with the directive. 9576 9577`OMP_MASTER' 9578 Represents `#pragma omp master'. 9579 9580 Operand `OMP_MASTER_BODY' contains the body of code to be executed 9581 by the master thread. 9582 9583`OMP_ORDERED' 9584 Represents `#pragma omp ordered'. 9585 9586 Operand `OMP_ORDERED_BODY' contains the body of code to be 9587 executed in the sequential order dictated by the loop index 9588 variable. 9589 9590`OMP_CRITICAL' 9591 Represents `#pragma omp critical [name]'. 9592 9593 Operand `OMP_CRITICAL_BODY' is the critical section. 9594 9595 Operand `OMP_CRITICAL_NAME' is an optional identifier to label the 9596 critical section. 9597 9598`OMP_RETURN' 9599 This does not represent any OpenMP directive, it is an artificial 9600 marker to indicate the end of the body of an OpenMP. It is used by 9601 the flow graph (`tree-cfg.c') and OpenMP region building code 9602 (`omp-low.c'). 9603 9604`OMP_CONTINUE' 9605 Similarly, this instruction does not represent an OpenMP 9606 directive, it is used by `OMP_FOR' (and similar codes) as well as 9607 `OMP_SECTIONS' to mark the place where the code needs to loop to 9608 the next iteration, or the next section, respectively. 9609 9610 In some cases, `OMP_CONTINUE' is placed right before `OMP_RETURN'. 9611 But if there are cleanups that need to occur right after the 9612 looping body, it will be emitted between `OMP_CONTINUE' and 9613 `OMP_RETURN'. 9614 9615`OMP_ATOMIC' 9616 Represents `#pragma omp atomic'. 9617 9618 Operand 0 is the address at which the atomic operation is to be 9619 performed. 9620 9621 Operand 1 is the expression to evaluate. The gimplifier tries 9622 three alternative code generation strategies. Whenever possible, 9623 an atomic update built-in is used. If that fails, a 9624 compare-and-swap loop is attempted. If that also fails, a regular 9625 critical section around the expression is used. 9626 9627`OMP_CLAUSE' 9628 Represents clauses associated with one of the `OMP_' directives. 9629 Clauses are represented by separate subcodes defined in `tree.h'. 9630 Clauses codes can be one of: `OMP_CLAUSE_PRIVATE', 9631 `OMP_CLAUSE_SHARED', `OMP_CLAUSE_FIRSTPRIVATE', 9632 `OMP_CLAUSE_LASTPRIVATE', `OMP_CLAUSE_COPYIN', 9633 `OMP_CLAUSE_COPYPRIVATE', `OMP_CLAUSE_IF', 9634 `OMP_CLAUSE_NUM_THREADS', `OMP_CLAUSE_SCHEDULE', 9635 `OMP_CLAUSE_NOWAIT', `OMP_CLAUSE_ORDERED', `OMP_CLAUSE_DEFAULT', 9636 `OMP_CLAUSE_REDUCTION', `OMP_CLAUSE_COLLAPSE', `OMP_CLAUSE_UNTIED', 9637 `OMP_CLAUSE_FINAL', and `OMP_CLAUSE_MERGEABLE'. Each code 9638 represents the corresponding OpenMP clause. 9639 9640 Clauses associated with the same directive are chained together 9641 via `OMP_CLAUSE_CHAIN'. Those clauses that accept a list of 9642 variables are restricted to exactly one, accessed with 9643 `OMP_CLAUSE_VAR'. Therefore, multiple variables under the same 9644 clause `C' need to be represented as multiple `C' clauses chained 9645 together. This facilitates adding new clauses during compilation. 9646 9647 9648 9649File: gccint.info, Node: OpenACC, Prev: OpenMP, Up: Statements 9650 965110.7.8 OpenACC 9652-------------- 9653 9654All the statements starting with `OACC_' represent directives and 9655clauses used by the OpenACC API `http://www.openacc.org/'. 9656 9657`OACC_CACHE' 9658 Represents `#pragma acc cache (var ...)'. 9659 9660`OACC_DATA' 9661 Represents `#pragma acc data [clause1 ... clauseN]'. 9662 9663`OACC_DECLARE' 9664 Represents `#pragma acc declare [clause1 ... clauseN]'. 9665 9666`OACC_ENTER_DATA' 9667 Represents `#pragma acc enter data [clause1 ... clauseN]'. 9668 9669`OACC_EXIT_DATA' 9670 Represents `#pragma acc exit data [clause1 ... clauseN]'. 9671 9672`OACC_HOST_DATA' 9673 Represents `#pragma acc host_data [clause1 ... clauseN]'. 9674 9675`OACC_KERNELS' 9676 Represents `#pragma acc kernels [clause1 ... clauseN]'. 9677 9678`OACC_LOOP' 9679 Represents `#pragma acc loop [clause1 ... clauseN]'. 9680 9681 See the description of the `OMP_FOR' code. 9682 9683`OACC_PARALLEL' 9684 Represents `#pragma acc parallel [clause1 ... clauseN]'. 9685 9686`OACC_UPDATE' 9687 Represents `#pragma acc update [clause1 ... clauseN]'. 9688 9689 9690 9691File: gccint.info, Node: Functions, Next: Language-dependent trees, Prev: Statements, Up: GENERIC 9692 969310.8 Functions 9694============== 9695 9696A function is represented by a `FUNCTION_DECL' node. It stores the 9697basic pieces of the function such as body, parameters, and return type 9698as well as information on the surrounding context, visibility, and 9699linkage. 9700 9701* Menu: 9702 9703* Function Basics:: Function names, body, and parameters. 9704* Function Properties:: Context, linkage, etc. 9705 9706 9707File: gccint.info, Node: Function Basics, Next: Function Properties, Up: Functions 9708 970910.8.1 Function Basics 9710---------------------- 9711 9712A function has four core parts: the name, the parameters, the result, 9713and the body. The following macros and functions access these parts of 9714a `FUNCTION_DECL' as well as other basic features: 9715`DECL_NAME' 9716 This macro returns the unqualified name of the function, as an 9717 `IDENTIFIER_NODE'. For an instantiation of a function template, 9718 the `DECL_NAME' is the unqualified name of the template, not 9719 something like `f<int>'. The value of `DECL_NAME' is undefined 9720 when used on a constructor, destructor, overloaded operator, or 9721 type-conversion operator, or any function that is implicitly 9722 generated by the compiler. See below for macros that can be used 9723 to distinguish these cases. 9724 9725`DECL_ASSEMBLER_NAME' 9726 This macro returns the mangled name of the function, also an 9727 `IDENTIFIER_NODE'. This name does not contain leading underscores 9728 on systems that prefix all identifiers with underscores. The 9729 mangled name is computed in the same way on all platforms; if 9730 special processing is required to deal with the object file format 9731 used on a particular platform, it is the responsibility of the 9732 back end to perform those modifications. (Of course, the back end 9733 should not modify `DECL_ASSEMBLER_NAME' itself.) 9734 9735 Using `DECL_ASSEMBLER_NAME' will cause additional memory to be 9736 allocated (for the mangled name of the entity) so it should be used 9737 only when emitting assembly code. It should not be used within the 9738 optimizers to determine whether or not two declarations are the 9739 same, even though some of the existing optimizers do use it in 9740 that way. These uses will be removed over time. 9741 9742`DECL_ARGUMENTS' 9743 This macro returns the `PARM_DECL' for the first argument to the 9744 function. Subsequent `PARM_DECL' nodes can be obtained by 9745 following the `TREE_CHAIN' links. 9746 9747`DECL_RESULT' 9748 This macro returns the `RESULT_DECL' for the function. 9749 9750`DECL_SAVED_TREE' 9751 This macro returns the complete body of the function. 9752 9753`TREE_TYPE' 9754 This macro returns the `FUNCTION_TYPE' or `METHOD_TYPE' for the 9755 function. 9756 9757`DECL_INITIAL' 9758 A function that has a definition in the current translation unit 9759 will have a non-`NULL' `DECL_INITIAL'. However, back ends should 9760 not make use of the particular value given by `DECL_INITIAL'. 9761 9762 It should contain a tree of `BLOCK' nodes that mirrors the scopes 9763 that variables are bound in the function. Each block contains a 9764 list of decls declared in a basic block, a pointer to a chain of 9765 blocks at the next lower scope level, then a pointer to the next 9766 block at the same level and a backpointer to the parent `BLOCK' or 9767 `FUNCTION_DECL'. So given a function as follows: 9768 9769 void foo() 9770 { 9771 int a; 9772 { 9773 int b; 9774 } 9775 int c; 9776 } 9777 9778 you would get the following: 9779 9780 tree foo = FUNCTION_DECL; 9781 tree decl_a = VAR_DECL; 9782 tree decl_b = VAR_DECL; 9783 tree decl_c = VAR_DECL; 9784 tree block_a = BLOCK; 9785 tree block_b = BLOCK; 9786 tree block_c = BLOCK; 9787 BLOCK_VARS(block_a) = decl_a; 9788 BLOCK_SUBBLOCKS(block_a) = block_b; 9789 BLOCK_CHAIN(block_a) = block_c; 9790 BLOCK_SUPERCONTEXT(block_a) = foo; 9791 BLOCK_VARS(block_b) = decl_b; 9792 BLOCK_SUPERCONTEXT(block_b) = block_a; 9793 BLOCK_VARS(block_c) = decl_c; 9794 BLOCK_SUPERCONTEXT(block_c) = foo; 9795 DECL_INITIAL(foo) = block_a; 9796 9797 9798 9799File: gccint.info, Node: Function Properties, Prev: Function Basics, Up: Functions 9800 980110.8.2 Function Properties 9802-------------------------- 9803 9804To determine the scope of a function, you can use the `DECL_CONTEXT' 9805macro. This macro will return the class (either a `RECORD_TYPE' or a 9806`UNION_TYPE') or namespace (a `NAMESPACE_DECL') of which the function 9807is a member. For a virtual function, this macro returns the class in 9808which the function was actually defined, not the base class in which 9809the virtual declaration occurred. 9810 9811 In C, the `DECL_CONTEXT' for a function maybe another function. This 9812representation indicates that the GNU nested function extension is in 9813use. For details on the semantics of nested functions, see the GCC 9814Manual. The nested function can refer to local variables in its 9815containing function. Such references are not explicitly marked in the 9816tree structure; back ends must look at the `DECL_CONTEXT' for the 9817referenced `VAR_DECL'. If the `DECL_CONTEXT' for the referenced 9818`VAR_DECL' is not the same as the function currently being processed, 9819and neither `DECL_EXTERNAL' nor `TREE_STATIC' hold, then the reference 9820is to a local variable in a containing function, and the back end must 9821take appropriate action. 9822 9823`DECL_EXTERNAL' 9824 This predicate holds if the function is undefined. 9825 9826`TREE_PUBLIC' 9827 This predicate holds if the function has external linkage. 9828 9829`TREE_STATIC' 9830 This predicate holds if the function has been defined. 9831 9832`TREE_THIS_VOLATILE' 9833 This predicate holds if the function does not return normally. 9834 9835`TREE_READONLY' 9836 This predicate holds if the function can only read its arguments. 9837 9838`DECL_PURE_P' 9839 This predicate holds if the function can only read its arguments, 9840 but may also read global memory. 9841 9842`DECL_VIRTUAL_P' 9843 This predicate holds if the function is virtual. 9844 9845`DECL_ARTIFICIAL' 9846 This macro holds if the function was implicitly generated by the 9847 compiler, rather than explicitly declared. In addition to 9848 implicitly generated class member functions, this macro holds for 9849 the special functions created to implement static initialization 9850 and destruction, to compute run-time type information, and so 9851 forth. 9852 9853`DECL_FUNCTION_SPECIFIC_TARGET' 9854 This macro returns a tree node that holds the target options that 9855 are to be used to compile this particular function or `NULL_TREE' 9856 if the function is to be compiled with the target options 9857 specified on the command line. 9858 9859`DECL_FUNCTION_SPECIFIC_OPTIMIZATION' 9860 This macro returns a tree node that holds the optimization options 9861 that are to be used to compile this particular function or 9862 `NULL_TREE' if the function is to be compiled with the 9863 optimization options specified on the command line. 9864 9865 9866 9867File: gccint.info, Node: Language-dependent trees, Next: C and C++ Trees, Prev: Functions, Up: GENERIC 9868 986910.9 Language-dependent trees 9870============================= 9871 9872Front ends may wish to keep some state associated with various GENERIC 9873trees while parsing. To support this, trees provide a set of flags 9874that may be used by the front end. They are accessed using 9875`TREE_LANG_FLAG_n' where `n' is currently 0 through 6. 9876 9877 If necessary, a front end can use some language-dependent tree codes 9878in its GENERIC representation, so long as it provides a hook for 9879converting them to GIMPLE and doesn't expect them to work with any 9880(hypothetical) optimizers that run before the conversion to GIMPLE. The 9881intermediate representation used while parsing C and C++ looks very 9882little like GENERIC, but the C and C++ gimplifier hooks are perfectly 9883happy to take it as input and spit out GIMPLE. 9884 9885 9886File: gccint.info, Node: C and C++ Trees, Next: Java Trees, Prev: Language-dependent trees, Up: GENERIC 9887 988810.10 C and C++ Trees 9889===================== 9890 9891This section documents the internal representation used by GCC to 9892represent C and C++ source programs. When presented with a C or C++ 9893source program, GCC parses the program, performs semantic analysis 9894(including the generation of error messages), and then produces the 9895internal representation described here. This representation contains a 9896complete representation for the entire translation unit provided as 9897input to the front end. This representation is then typically processed 9898by a code-generator in order to produce machine code, but could also be 9899used in the creation of source browsers, intelligent editors, automatic 9900documentation generators, interpreters, and any other programs needing 9901the ability to process C or C++ code. 9902 9903 This section explains the internal representation. In particular, it 9904documents the internal representation for C and C++ source constructs, 9905and the macros, functions, and variables that can be used to access 9906these constructs. The C++ representation is largely a superset of the 9907representation used in the C front end. There is only one construct 9908used in C that does not appear in the C++ front end and that is the GNU 9909"nested function" extension. Many of the macros documented here do not 9910apply in C because the corresponding language constructs do not appear 9911in C. 9912 9913 The C and C++ front ends generate a mix of GENERIC trees and ones 9914specific to C and C++. These language-specific trees are higher-level 9915constructs than the ones in GENERIC to make the parser's job easier. 9916This section describes those trees that aren't part of GENERIC as well 9917as aspects of GENERIC trees that are treated in a language-specific 9918manner. 9919 9920 If you are developing a "back end", be it is a code-generator or some 9921other tool, that uses this representation, you may occasionally find 9922that you need to ask questions not easily answered by the functions and 9923macros available here. If that situation occurs, it is quite likely 9924that GCC already supports the functionality you desire, but that the 9925interface is simply not documented here. In that case, you should ask 9926the GCC maintainers (via mail to <gcc@gcc.gnu.org>) about documenting 9927the functionality you require. Similarly, if you find yourself writing 9928functions that do not deal directly with your back end, but instead 9929might be useful to other people using the GCC front end, you should 9930submit your patches for inclusion in GCC. 9931 9932* Menu: 9933 9934* Types for C++:: Fundamental and aggregate types. 9935* Namespaces:: Namespaces. 9936* Classes:: Classes. 9937* Functions for C++:: Overloading and accessors for C++. 9938* Statements for C++:: Statements specific to C and C++. 9939* C++ Expressions:: From `typeid' to `throw'. 9940 9941 9942File: gccint.info, Node: Types for C++, Next: Namespaces, Up: C and C++ Trees 9943 994410.10.1 Types for C++ 9945--------------------- 9946 9947In C++, an array type is not qualified; rather the type of the array 9948elements is qualified. This situation is reflected in the intermediate 9949representation. The macros described here will always examine the 9950qualification of the underlying element type when applied to an array 9951type. (If the element type is itself an array, then the recursion 9952continues until a non-array type is found, and the qualification of this 9953type is examined.) So, for example, `CP_TYPE_CONST_P' will hold of the 9954type `const int ()[7]', denoting an array of seven `int's. 9955 9956 The following functions and macros deal with cv-qualification of types: 9957`cp_type_quals' 9958 This function returns the set of type qualifiers applied to this 9959 type. This value is `TYPE_UNQUALIFIED' if no qualifiers have been 9960 applied. The `TYPE_QUAL_CONST' bit is set if the type is 9961 `const'-qualified. The `TYPE_QUAL_VOLATILE' bit is set if the 9962 type is `volatile'-qualified. The `TYPE_QUAL_RESTRICT' bit is set 9963 if the type is `restrict'-qualified. 9964 9965`CP_TYPE_CONST_P' 9966 This macro holds if the type is `const'-qualified. 9967 9968`CP_TYPE_VOLATILE_P' 9969 This macro holds if the type is `volatile'-qualified. 9970 9971`CP_TYPE_RESTRICT_P' 9972 This macro holds if the type is `restrict'-qualified. 9973 9974`CP_TYPE_CONST_NON_VOLATILE_P' 9975 This predicate holds for a type that is `const'-qualified, but 9976 _not_ `volatile'-qualified; other cv-qualifiers are ignored as 9977 well: only the `const'-ness is tested. 9978 9979 9980 A few other macros and functions are usable with all types: 9981`TYPE_SIZE' 9982 The number of bits required to represent the type, represented as 9983 an `INTEGER_CST'. For an incomplete type, `TYPE_SIZE' will be 9984 `NULL_TREE'. 9985 9986`TYPE_ALIGN' 9987 The alignment of the type, in bits, represented as an `int'. 9988 9989`TYPE_NAME' 9990 This macro returns a declaration (in the form of a `TYPE_DECL') for 9991 the type. (Note this macro does _not_ return an 9992 `IDENTIFIER_NODE', as you might expect, given its name!) You can 9993 look at the `DECL_NAME' of the `TYPE_DECL' to obtain the actual 9994 name of the type. The `TYPE_NAME' will be `NULL_TREE' for a type 9995 that is not a built-in type, the result of a typedef, or a named 9996 class type. 9997 9998`CP_INTEGRAL_TYPE' 9999 This predicate holds if the type is an integral type. Notice that 10000 in C++, enumerations are _not_ integral types. 10001 10002`ARITHMETIC_TYPE_P' 10003 This predicate holds if the type is an integral type (in the C++ 10004 sense) or a floating point type. 10005 10006`CLASS_TYPE_P' 10007 This predicate holds for a class-type. 10008 10009`TYPE_BUILT_IN' 10010 This predicate holds for a built-in type. 10011 10012`TYPE_PTRDATAMEM_P' 10013 This predicate holds if the type is a pointer to data member. 10014 10015`TYPE_PTR_P' 10016 This predicate holds if the type is a pointer type, and the 10017 pointee is not a data member. 10018 10019`TYPE_PTRFN_P' 10020 This predicate holds for a pointer to function type. 10021 10022`TYPE_PTROB_P' 10023 This predicate holds for a pointer to object type. Note however 10024 that it does not hold for the generic pointer to object type `void 10025 *'. You may use `TYPE_PTROBV_P' to test for a pointer to object 10026 type as well as `void *'. 10027 10028 10029 The table below describes types specific to C and C++ as well as 10030language-dependent info about GENERIC types. 10031 10032`POINTER_TYPE' 10033 Used to represent pointer types, and pointer to data member types. 10034 If `TREE_TYPE' is a pointer to data member type, then 10035 `TYPE_PTRDATAMEM_P' will hold. For a pointer to data member type 10036 of the form `T X::*', `TYPE_PTRMEM_CLASS_TYPE' will be the type 10037 `X', while `TYPE_PTRMEM_POINTED_TO_TYPE' will be the type `T'. 10038 10039`RECORD_TYPE' 10040 Used to represent `struct' and `class' types in C and C++. If 10041 `TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member 10042 type. In that case, the `TYPE_PTRMEMFUNC_FN_TYPE' is a 10043 `POINTER_TYPE' pointing to a `METHOD_TYPE'. The `METHOD_TYPE' is 10044 the type of a function pointed to by the pointer-to-member 10045 function. If `TYPE_PTRMEMFUNC_P' does not hold, this type is a 10046 class type. For more information, *note Classes::. 10047 10048`UNKNOWN_TYPE' 10049 This node is used to represent a type the knowledge of which is 10050 insufficient for a sound processing. 10051 10052`TYPENAME_TYPE' 10053 Used to represent a construct of the form `typename T::A'. The 10054 `TYPE_CONTEXT' is `T'; the `TYPE_NAME' is an `IDENTIFIER_NODE' for 10055 `A'. If the type is specified via a template-id, then 10056 `TYPENAME_TYPE_FULLNAME' yields a `TEMPLATE_ID_EXPR'. The 10057 `TREE_TYPE' is non-`NULL' if the node is implicitly generated in 10058 support for the implicit typename extension; in which case the 10059 `TREE_TYPE' is a type node for the base-class. 10060 10061`TYPEOF_TYPE' 10062 Used to represent the `__typeof__' extension. The `TYPE_FIELDS' 10063 is the expression the type of which is being represented. 10064 10065 10066 10067File: gccint.info, Node: Namespaces, Next: Classes, Prev: Types for C++, Up: C and C++ Trees 10068 1006910.10.2 Namespaces 10070------------------ 10071 10072The root of the entire intermediate representation is the variable 10073`global_namespace'. This is the namespace specified with `::' in C++ 10074source code. All other namespaces, types, variables, functions, and so 10075forth can be found starting with this namespace. 10076 10077 However, except for the fact that it is distinguished as the root of 10078the representation, the global namespace is no different from any other 10079namespace. Thus, in what follows, we describe namespaces generally, 10080rather than the global namespace in particular. 10081 10082 A namespace is represented by a `NAMESPACE_DECL' node. 10083 10084 The following macros and functions can be used on a `NAMESPACE_DECL': 10085 10086`DECL_NAME' 10087 This macro is used to obtain the `IDENTIFIER_NODE' corresponding to 10088 the unqualified name of the name of the namespace (*note 10089 Identifiers::). The name of the global namespace is `::', even 10090 though in C++ the global namespace is unnamed. However, you 10091 should use comparison with `global_namespace', rather than 10092 `DECL_NAME' to determine whether or not a namespace is the global 10093 one. An unnamed namespace will have a `DECL_NAME' equal to 10094 `anonymous_namespace_name'. Within a single translation unit, all 10095 unnamed namespaces will have the same name. 10096 10097`DECL_CONTEXT' 10098 This macro returns the enclosing namespace. The `DECL_CONTEXT' for 10099 the `global_namespace' is `NULL_TREE'. 10100 10101`DECL_NAMESPACE_ALIAS' 10102 If this declaration is for a namespace alias, then 10103 `DECL_NAMESPACE_ALIAS' is the namespace for which this one is an 10104 alias. 10105 10106 Do not attempt to use `cp_namespace_decls' for a namespace which is 10107 an alias. Instead, follow `DECL_NAMESPACE_ALIAS' links until you 10108 reach an ordinary, non-alias, namespace, and call 10109 `cp_namespace_decls' there. 10110 10111`DECL_NAMESPACE_STD_P' 10112 This predicate holds if the namespace is the special `::std' 10113 namespace. 10114 10115`cp_namespace_decls' 10116 This function will return the declarations contained in the 10117 namespace, including types, overloaded functions, other 10118 namespaces, and so forth. If there are no declarations, this 10119 function will return `NULL_TREE'. The declarations are connected 10120 through their `TREE_CHAIN' fields. 10121 10122 Although most entries on this list will be declarations, 10123 `TREE_LIST' nodes may also appear. In this case, the `TREE_VALUE' 10124 will be an `OVERLOAD'. The value of the `TREE_PURPOSE' is 10125 unspecified; back ends should ignore this value. As with the 10126 other kinds of declarations returned by `cp_namespace_decls', the 10127 `TREE_CHAIN' will point to the next declaration in this list. 10128 10129 For more information on the kinds of declarations that can occur 10130 on this list, *Note Declarations::. Some declarations will not 10131 appear on this list. In particular, no `FIELD_DECL', 10132 `LABEL_DECL', or `PARM_DECL' nodes will appear here. 10133 10134 This function cannot be used with namespaces that have 10135 `DECL_NAMESPACE_ALIAS' set. 10136 10137 10138 10139File: gccint.info, Node: Classes, Next: Functions for C++, Prev: Namespaces, Up: C and C++ Trees 10140 1014110.10.3 Classes 10142--------------- 10143 10144Besides namespaces, the other high-level scoping construct in C++ is the 10145class. (Throughout this manual the term "class" is used to mean the 10146types referred to in the ANSI/ISO C++ Standard as classes; these include 10147types defined with the `class', `struct', and `union' keywords.) 10148 10149 A class type is represented by either a `RECORD_TYPE' or a 10150`UNION_TYPE'. A class declared with the `union' tag is represented by 10151a `UNION_TYPE', while classes declared with either the `struct' or the 10152`class' tag are represented by `RECORD_TYPE's. You can use the 10153`CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular 10154type is a `class' as opposed to a `struct'. This macro will be true 10155only for classes declared with the `class' tag. 10156 10157 Almost all non-function members are available on the `TYPE_FIELDS' 10158list. Given one member, the next can be found by following the 10159`TREE_CHAIN'. You should not depend in any way on the order in which 10160fields appear on this list. All nodes on this list will be `DECL' 10161nodes. A `FIELD_DECL' is used to represent a non-static data member, a 10162`VAR_DECL' is used to represent a static data member, and a `TYPE_DECL' 10163is used to represent a type. Note that the `CONST_DECL' for an 10164enumeration constant will appear on this list, if the enumeration type 10165was declared in the class. (Of course, the `TYPE_DECL' for the 10166enumeration type will appear here as well.) There are no entries for 10167base classes on this list. In particular, there is no `FIELD_DECL' for 10168the "base-class portion" of an object. 10169 10170 The `TYPE_VFIELD' is a compiler-generated field used to point to 10171virtual function tables. It may or may not appear on the `TYPE_FIELDS' 10172list. However, back ends should handle the `TYPE_VFIELD' just like all 10173the entries on the `TYPE_FIELDS' list. 10174 10175 The function members are available on the `TYPE_METHODS' list. Again, 10176subsequent members are found by following the `TREE_CHAIN' field. If a 10177function is overloaded, each of the overloaded functions appears; no 10178`OVERLOAD' nodes appear on the `TYPE_METHODS' list. Implicitly 10179declared functions (including default constructors, copy constructors, 10180assignment operators, and destructors) will appear on this list as well. 10181 10182 Every class has an associated "binfo", which can be obtained with 10183`TYPE_BINFO'. Binfos are used to represent base-classes. The binfo 10184given by `TYPE_BINFO' is the degenerate case, whereby every class is 10185considered to be its own base-class. The base binfos for a particular 10186binfo are held in a vector, whose length is obtained with 10187`BINFO_N_BASE_BINFOS'. The base binfos themselves are obtained with 10188`BINFO_BASE_BINFO' and `BINFO_BASE_ITERATE'. To add a new binfo, use 10189`BINFO_BASE_APPEND'. The vector of base binfos can be obtained with 10190`BINFO_BASE_BINFOS', but normally you do not need to use that. The 10191class type associated with a binfo is given by `BINFO_TYPE'. It is not 10192always the case that `BINFO_TYPE (TYPE_BINFO (x))', because of typedefs 10193and qualified types. Neither is it the case that `TYPE_BINFO 10194(BINFO_TYPE (y))' is the same binfo as `y'. The reason is that if `y' 10195is a binfo representing a base-class `B' of a derived class `D', then 10196`BINFO_TYPE (y)' will be `B', and `TYPE_BINFO (BINFO_TYPE (y))' will be 10197`B' as its own base-class, rather than as a base-class of `D'. 10198 10199 The access to a base type can be found with `BINFO_BASE_ACCESS'. This 10200will produce `access_public_node', `access_private_node' or 10201`access_protected_node'. If bases are always public, 10202`BINFO_BASE_ACCESSES' may be `NULL'. 10203 10204 `BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited 10205virtually or not. The other flags, `BINFO_MARKED_P' and `BINFO_FLAG_1' 10206to `BINFO_FLAG_6' can be used for language specific use. 10207 10208 The following macros can be used on a tree node representing a 10209class-type. 10210 10211`LOCAL_CLASS_P' 10212 This predicate holds if the class is local class _i.e._ declared 10213 inside a function body. 10214 10215`TYPE_POLYMORPHIC_P' 10216 This predicate holds if the class has at least one virtual function 10217 (declared or inherited). 10218 10219`TYPE_HAS_DEFAULT_CONSTRUCTOR' 10220 This predicate holds whenever its argument represents a class-type 10221 with default constructor. 10222 10223`CLASSTYPE_HAS_MUTABLE' 10224`TYPE_HAS_MUTABLE_P' 10225 These predicates hold for a class-type having a mutable data 10226 member. 10227 10228`CLASSTYPE_NON_POD_P' 10229 This predicate holds only for class-types that are not PODs. 10230 10231`TYPE_HAS_NEW_OPERATOR' 10232 This predicate holds for a class-type that defines `operator new'. 10233 10234`TYPE_HAS_ARRAY_NEW_OPERATOR' 10235 This predicate holds for a class-type for which `operator new[]' 10236 is defined. 10237 10238`TYPE_OVERLOADS_CALL_EXPR' 10239 This predicate holds for class-type for which the function call 10240 `operator()' is overloaded. 10241 10242`TYPE_OVERLOADS_ARRAY_REF' 10243 This predicate holds for a class-type that overloads `operator[]' 10244 10245`TYPE_OVERLOADS_ARROW' 10246 This predicate holds for a class-type for which `operator->' is 10247 overloaded. 10248 10249 10250 10251File: gccint.info, Node: Functions for C++, Next: Statements for C++, Prev: Classes, Up: C and C++ Trees 10252 1025310.10.4 Functions for C++ 10254------------------------- 10255 10256A function is represented by a `FUNCTION_DECL' node. A set of 10257overloaded functions is sometimes represented by an `OVERLOAD' node. 10258 10259 An `OVERLOAD' node is not a declaration, so none of the `DECL_' macros 10260should be used on an `OVERLOAD'. An `OVERLOAD' node is similar to a 10261`TREE_LIST'. Use `OVL_CURRENT' to get the function associated with an 10262`OVERLOAD' node; use `OVL_NEXT' to get the next `OVERLOAD' node in the 10263list of overloaded functions. The macros `OVL_CURRENT' and `OVL_NEXT' 10264are actually polymorphic; you can use them to work with `FUNCTION_DECL' 10265nodes as well as with overloads. In the case of a `FUNCTION_DECL', 10266`OVL_CURRENT' will always return the function itself, and `OVL_NEXT' 10267will always be `NULL_TREE'. 10268 10269 To determine the scope of a function, you can use the `DECL_CONTEXT' 10270macro. This macro will return the class (either a `RECORD_TYPE' or a 10271`UNION_TYPE') or namespace (a `NAMESPACE_DECL') of which the function 10272is a member. For a virtual function, this macro returns the class in 10273which the function was actually defined, not the base class in which 10274the virtual declaration occurred. 10275 10276 If a friend function is defined in a class scope, the 10277`DECL_FRIEND_CONTEXT' macro can be used to determine the class in which 10278it was defined. For example, in 10279 class C { friend void f() {} }; 10280 the `DECL_CONTEXT' for `f' will be the `global_namespace', but the 10281`DECL_FRIEND_CONTEXT' will be the `RECORD_TYPE' for `C'. 10282 10283 The following macros and functions can be used on a `FUNCTION_DECL': 10284`DECL_MAIN_P' 10285 This predicate holds for a function that is the program entry point 10286 `::code'. 10287 10288`DECL_LOCAL_FUNCTION_P' 10289 This predicate holds if the function was declared at block scope, 10290 even though it has a global scope. 10291 10292`DECL_ANTICIPATED' 10293 This predicate holds if the function is a built-in function but its 10294 prototype is not yet explicitly declared. 10295 10296`DECL_EXTERN_C_FUNCTION_P' 10297 This predicate holds if the function is declared as an ``extern 10298 "C"'' function. 10299 10300`DECL_LINKONCE_P' 10301 This macro holds if multiple copies of this function may be 10302 emitted in various translation units. It is the responsibility of 10303 the linker to merge the various copies. Template instantiations 10304 are the most common example of functions for which 10305 `DECL_LINKONCE_P' holds; G++ instantiates needed templates in all 10306 translation units which require them, and then relies on the 10307 linker to remove duplicate instantiations. 10308 10309 FIXME: This macro is not yet implemented. 10310 10311`DECL_FUNCTION_MEMBER_P' 10312 This macro holds if the function is a member of a class, rather 10313 than a member of a namespace. 10314 10315`DECL_STATIC_FUNCTION_P' 10316 This predicate holds if the function a static member function. 10317 10318`DECL_NONSTATIC_MEMBER_FUNCTION_P' 10319 This macro holds for a non-static member function. 10320 10321`DECL_CONST_MEMFUNC_P' 10322 This predicate holds for a `const'-member function. 10323 10324`DECL_VOLATILE_MEMFUNC_P' 10325 This predicate holds for a `volatile'-member function. 10326 10327`DECL_CONSTRUCTOR_P' 10328 This macro holds if the function is a constructor. 10329 10330`DECL_NONCONVERTING_P' 10331 This predicate holds if the constructor is a non-converting 10332 constructor. 10333 10334`DECL_COMPLETE_CONSTRUCTOR_P' 10335 This predicate holds for a function which is a constructor for an 10336 object of a complete type. 10337 10338`DECL_BASE_CONSTRUCTOR_P' 10339 This predicate holds for a function which is a constructor for a 10340 base class sub-object. 10341 10342`DECL_COPY_CONSTRUCTOR_P' 10343 This predicate holds for a function which is a copy-constructor. 10344 10345`DECL_DESTRUCTOR_P' 10346 This macro holds if the function is a destructor. 10347 10348`DECL_COMPLETE_DESTRUCTOR_P' 10349 This predicate holds if the function is the destructor for an 10350 object a complete type. 10351 10352`DECL_OVERLOADED_OPERATOR_P' 10353 This macro holds if the function is an overloaded operator. 10354 10355`DECL_CONV_FN_P' 10356 This macro holds if the function is a type-conversion operator. 10357 10358`DECL_GLOBAL_CTOR_P' 10359 This predicate holds if the function is a file-scope initialization 10360 function. 10361 10362`DECL_GLOBAL_DTOR_P' 10363 This predicate holds if the function is a file-scope finalization 10364 function. 10365 10366`DECL_THUNK_P' 10367 This predicate holds if the function is a thunk. 10368 10369 These functions represent stub code that adjusts the `this' pointer 10370 and then jumps to another function. When the jumped-to function 10371 returns, control is transferred directly to the caller, without 10372 returning to the thunk. The first parameter to the thunk is 10373 always the `this' pointer; the thunk should add `THUNK_DELTA' to 10374 this value. (The `THUNK_DELTA' is an `int', not an `INTEGER_CST'.) 10375 10376 Then, if `THUNK_VCALL_OFFSET' (an `INTEGER_CST') is nonzero the 10377 adjusted `this' pointer must be adjusted again. The complete 10378 calculation is given by the following pseudo-code: 10379 10380 this += THUNK_DELTA 10381 if (THUNK_VCALL_OFFSET) 10382 this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET] 10383 10384 Finally, the thunk should jump to the location given by 10385 `DECL_INITIAL'; this will always be an expression for the address 10386 of a function. 10387 10388`DECL_NON_THUNK_FUNCTION_P' 10389 This predicate holds if the function is _not_ a thunk function. 10390 10391`GLOBAL_INIT_PRIORITY' 10392 If either `DECL_GLOBAL_CTOR_P' or `DECL_GLOBAL_DTOR_P' holds, then 10393 this gives the initialization priority for the function. The 10394 linker will arrange that all functions for which 10395 `DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority 10396 before `main' is called. When the program exits, all functions for 10397 which `DECL_GLOBAL_DTOR_P' holds are run in the reverse order. 10398 10399`TYPE_RAISES_EXCEPTIONS' 10400 This macro returns the list of exceptions that a (member-)function 10401 can raise. The returned list, if non `NULL', is comprised of nodes 10402 whose `TREE_VALUE' represents a type. 10403 10404`TYPE_NOTHROW_P' 10405 This predicate holds when the exception-specification of its 10406 arguments is of the form ``()''. 10407 10408`DECL_ARRAY_DELETE_OPERATOR_P' 10409 This predicate holds if the function an overloaded `operator 10410 delete[]'. 10411 10412 10413 10414File: gccint.info, Node: Statements for C++, Next: C++ Expressions, Prev: Functions for C++, Up: C and C++ Trees 10415 1041610.10.5 Statements for C++ 10417-------------------------- 10418 10419A function that has a definition in the current translation unit will 10420have a non-`NULL' `DECL_INITIAL'. However, back ends should not make 10421use of the particular value given by `DECL_INITIAL'. 10422 10423 The `DECL_SAVED_TREE' macro will give the complete body of the 10424function. 10425 1042610.10.5.1 Statements 10427.................... 10428 10429There are tree nodes corresponding to all of the source-level statement 10430constructs, used within the C and C++ frontends. These are enumerated 10431here, together with a list of the various macros that can be used to 10432obtain information about them. There are a few macros that can be used 10433with all statements: 10434 10435`STMT_IS_FULL_EXPR_P' 10436 In C++, statements normally constitute "full expressions"; 10437 temporaries created during a statement are destroyed when the 10438 statement is complete. However, G++ sometimes represents 10439 expressions by statements; these statements will not have 10440 `STMT_IS_FULL_EXPR_P' set. Temporaries created during such 10441 statements should be destroyed when the innermost enclosing 10442 statement with `STMT_IS_FULL_EXPR_P' set is exited. 10443 10444 10445 Here is the list of the various statement nodes, and the macros used to 10446access them. This documentation describes the use of these nodes in 10447non-template functions (including instantiations of template functions). 10448In template functions, the same nodes are used, but sometimes in 10449slightly different ways. 10450 10451 Many of the statements have substatements. For example, a `while' 10452loop will have a body, which is itself a statement. If the substatement 10453is `NULL_TREE', it is considered equivalent to a statement consisting 10454of a single `;', i.e., an expression statement in which the expression 10455has been omitted. A substatement may in fact be a list of statements, 10456connected via their `TREE_CHAIN's. So, you should always process the 10457statement tree by looping over substatements, like this: 10458 void process_stmt (stmt) 10459 tree stmt; 10460 { 10461 while (stmt) 10462 { 10463 switch (TREE_CODE (stmt)) 10464 { 10465 case IF_STMT: 10466 process_stmt (THEN_CLAUSE (stmt)); 10467 /* More processing here. */ 10468 break; 10469 10470 ... 10471 } 10472 10473 stmt = TREE_CHAIN (stmt); 10474 } 10475 } 10476 In other words, while the `then' clause of an `if' statement in C++ 10477can be only one statement (although that one statement may be a 10478compound statement), the intermediate representation will sometimes use 10479several statements chained together. 10480 10481`BREAK_STMT' 10482 Used to represent a `break' statement. There are no additional 10483 fields. 10484 10485`CILK_SPAWN_STMT' 10486 Used to represent a spawning function in the Cilk Plus language 10487 extension. This tree has one field that holds the name of the 10488 spawning function. `_Cilk_spawn' can be written in C in the 10489 following way: 10490 10491 `_Cilk_spawn' <function_name> (<parameters>); 10492 10493 Detailed description for usage and functionality of `_Cilk_spawn' 10494 can be found at http://www.cilkplus.org 10495 10496`CILK_SYNC_STMT' 10497 This statement is part of the Cilk Plus language extension. It 10498 indicates that the current function cannot continue in parallel 10499 with its spawned children. There are no additional fields. 10500 `_Cilk_sync' can be written in C in the following way: 10501 10502 `_Cilk_sync'; 10503 10504`CLEANUP_STMT' 10505 Used to represent an action that should take place upon exit from 10506 the enclosing scope. Typically, these actions are calls to 10507 destructors for local objects, but back ends cannot rely on this 10508 fact. If these nodes are in fact representing such destructors, 10509 `CLEANUP_DECL' will be the `VAR_DECL' destroyed. Otherwise, 10510 `CLEANUP_DECL' will be `NULL_TREE'. In any case, the 10511 `CLEANUP_EXPR' is the expression to execute. The cleanups 10512 executed on exit from a scope should be run in the reverse order 10513 of the order in which the associated `CLEANUP_STMT's were 10514 encountered. 10515 10516`CONTINUE_STMT' 10517 Used to represent a `continue' statement. There are no additional 10518 fields. 10519 10520`CTOR_STMT' 10521 Used to mark the beginning (if `CTOR_BEGIN_P' holds) or end (if 10522 `CTOR_END_P' holds of the main body of a constructor. See also 10523 `SUBOBJECT' for more information on how to use these nodes. 10524 10525`DO_STMT' 10526 Used to represent a `do' loop. The body of the loop is given by 10527 `DO_BODY' while the termination condition for the loop is given by 10528 `DO_COND'. The condition for a `do'-statement is always an 10529 expression. 10530 10531`EMPTY_CLASS_EXPR' 10532 Used to represent a temporary object of a class with no data whose 10533 address is never taken. (All such objects are interchangeable.) 10534 The `TREE_TYPE' represents the type of the object. 10535 10536`EXPR_STMT' 10537 Used to represent an expression statement. Use `EXPR_STMT_EXPR' to 10538 obtain the expression. 10539 10540`FOR_STMT' 10541 Used to represent a `for' statement. The `FOR_INIT_STMT' is the 10542 initialization statement for the loop. The `FOR_COND' is the 10543 termination condition. The `FOR_EXPR' is the expression executed 10544 right before the `FOR_COND' on each loop iteration; often, this 10545 expression increments a counter. The body of the loop is given by 10546 `FOR_BODY'. Note that `FOR_INIT_STMT' and `FOR_BODY' return 10547 statements, while `FOR_COND' and `FOR_EXPR' return expressions. 10548 10549`HANDLER' 10550 Used to represent a C++ `catch' block. The `HANDLER_TYPE' is the 10551 type of exception that will be caught by this handler; it is equal 10552 (by pointer equality) to `NULL' if this handler is for all types. 10553 `HANDLER_PARMS' is the `DECL_STMT' for the catch parameter, and 10554 `HANDLER_BODY' is the code for the block itself. 10555 10556`IF_STMT' 10557 Used to represent an `if' statement. The `IF_COND' is the 10558 expression. 10559 10560 If the condition is a `TREE_LIST', then the `TREE_PURPOSE' is a 10561 statement (usually a `DECL_STMT'). Each time the condition is 10562 evaluated, the statement should be executed. Then, the 10563 `TREE_VALUE' should be used as the conditional expression itself. 10564 This representation is used to handle C++ code like this: 10565 10566 C++ distinguishes between this and `COND_EXPR' for handling 10567 templates. 10568 10569 if (int i = 7) ... 10570 10571 where there is a new local variable (or variables) declared within 10572 the condition. 10573 10574 The `THEN_CLAUSE' represents the statement given by the `then' 10575 condition, while the `ELSE_CLAUSE' represents the statement given 10576 by the `else' condition. 10577 10578`SUBOBJECT' 10579 In a constructor, these nodes are used to mark the point at which a 10580 subobject of `this' is fully constructed. If, after this point, an 10581 exception is thrown before a `CTOR_STMT' with `CTOR_END_P' set is 10582 encountered, the `SUBOBJECT_CLEANUP' must be executed. The 10583 cleanups must be executed in the reverse order in which they 10584 appear. 10585 10586`SWITCH_STMT' 10587 Used to represent a `switch' statement. The `SWITCH_STMT_COND' is 10588 the expression on which the switch is occurring. See the 10589 documentation for an `IF_STMT' for more information on the 10590 representation used for the condition. The `SWITCH_STMT_BODY' is 10591 the body of the switch statement. The `SWITCH_STMT_TYPE' is the 10592 original type of switch expression as given in the source, before 10593 any compiler conversions. 10594 10595`TRY_BLOCK' 10596 Used to represent a `try' block. The body of the try block is 10597 given by `TRY_STMTS'. Each of the catch blocks is a `HANDLER' 10598 node. The first handler is given by `TRY_HANDLERS'. Subsequent 10599 handlers are obtained by following the `TREE_CHAIN' link from one 10600 handler to the next. The body of the handler is given by 10601 `HANDLER_BODY'. 10602 10603 If `CLEANUP_P' holds of the `TRY_BLOCK', then the `TRY_HANDLERS' 10604 will not be a `HANDLER' node. Instead, it will be an expression 10605 that should be executed if an exception is thrown in the try 10606 block. It must rethrow the exception after executing that code. 10607 And, if an exception is thrown while the expression is executing, 10608 `terminate' must be called. 10609 10610`USING_STMT' 10611 Used to represent a `using' directive. The namespace is given by 10612 `USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node 10613 is needed inside template functions, to implement using directives 10614 during instantiation. 10615 10616`WHILE_STMT' 10617 Used to represent a `while' loop. The `WHILE_COND' is the 10618 termination condition for the loop. See the documentation for an 10619 `IF_STMT' for more information on the representation used for the 10620 condition. 10621 10622 The `WHILE_BODY' is the body of the loop. 10623 10624 10625 10626File: gccint.info, Node: C++ Expressions, Prev: Statements for C++, Up: C and C++ Trees 10627 1062810.10.6 C++ Expressions 10629----------------------- 10630 10631This section describes expressions specific to the C and C++ front ends. 10632 10633`TYPEID_EXPR' 10634 Used to represent a `typeid' expression. 10635 10636`NEW_EXPR' 10637`VEC_NEW_EXPR' 10638 Used to represent a call to `new' and `new[]' respectively. 10639 10640`DELETE_EXPR' 10641`VEC_DELETE_EXPR' 10642 Used to represent a call to `delete' and `delete[]' respectively. 10643 10644`MEMBER_REF' 10645 Represents a reference to a member of a class. 10646 10647`THROW_EXPR' 10648 Represents an instance of `throw' in the program. Operand 0, 10649 which is the expression to throw, may be `NULL_TREE'. 10650 10651`AGGR_INIT_EXPR' 10652 An `AGGR_INIT_EXPR' represents the initialization as the return 10653 value of a function call, or as the result of a constructor. An 10654 `AGGR_INIT_EXPR' will only appear as a full-expression, or as the 10655 second operand of a `TARGET_EXPR'. `AGGR_INIT_EXPR's have a 10656 representation similar to that of `CALL_EXPR's. You can use the 10657 `AGGR_INIT_EXPR_FN' and `AGGR_INIT_EXPR_ARG' macros to access the 10658 function to call and the arguments to pass. 10659 10660 If `AGGR_INIT_VIA_CTOR_P' holds of the `AGGR_INIT_EXPR', then the 10661 initialization is via a constructor call. The address of the 10662 `AGGR_INIT_EXPR_SLOT' operand, which is always a `VAR_DECL', is 10663 taken, and this value replaces the first argument in the argument 10664 list. 10665 10666 In either case, the expression is void. 10667 10668 10669 10670File: gccint.info, Node: Java Trees, Prev: C and C++ Trees, Up: GENERIC 10671 1067210.11 Java Trees 10673================ 10674 10675 10676File: gccint.info, Node: GIMPLE, Next: Tree SSA, Prev: GENERIC, Up: Top 10677 1067811 GIMPLE 10679********* 10680 10681GIMPLE is a three-address representation derived from GENERIC by 10682breaking down GENERIC expressions into tuples of no more than 3 10683operands (with some exceptions like function calls). GIMPLE was 10684heavily influenced by the SIMPLE IL used by the McCAT compiler project 10685at McGill University, though we have made some different choices. For 10686one thing, SIMPLE doesn't support `goto'. 10687 10688 Temporaries are introduced to hold intermediate values needed to 10689compute complex expressions. Additionally, all the control structures 10690used in GENERIC are lowered into conditional jumps, lexical scopes are 10691removed and exception regions are converted into an on the side 10692exception region tree. 10693 10694 The compiler pass which converts GENERIC into GIMPLE is referred to as 10695the `gimplifier'. The gimplifier works recursively, generating GIMPLE 10696tuples out of the original GENERIC expressions. 10697 10698 One of the early implementation strategies used for the GIMPLE 10699representation was to use the same internal data structures used by 10700front ends to represent parse trees. This simplified implementation 10701because we could leverage existing functionality and interfaces. 10702However, GIMPLE is a much more restrictive representation than abstract 10703syntax trees (AST), therefore it does not require the full structural 10704complexity provided by the main tree data structure. 10705 10706 The GENERIC representation of a function is stored in the 10707`DECL_SAVED_TREE' field of the associated `FUNCTION_DECL' tree node. 10708It is converted to GIMPLE by a call to `gimplify_function_tree'. 10709 10710 If a front end wants to include language-specific tree codes in the 10711tree representation which it provides to the back end, it must provide a 10712definition of `LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the 10713front end trees to GIMPLE. Usually such a hook will involve much of 10714the same code for expanding front end trees to RTL. This function can 10715return fully lowered GIMPLE, or it can return GENERIC trees and let the 10716main gimplifier lower them the rest of the way; this is often simpler. 10717GIMPLE that is not fully lowered is known as "High GIMPLE" and consists 10718of the IL before the pass `pass_lower_cf'. High GIMPLE contains some 10719container statements like lexical scopes (represented by `GIMPLE_BIND') 10720and nested expressions (e.g., `GIMPLE_TRY'), while "Low GIMPLE" exposes 10721all of the implicit jumps for control and exception expressions 10722directly in the IL and EH region trees. 10723 10724 The C and C++ front ends currently convert directly from front end 10725trees to GIMPLE, and hand that off to the back end rather than first 10726converting to GENERIC. Their gimplifier hooks know about all the 10727`_STMT' nodes and how to convert them to GENERIC forms. There was some 10728work done on a genericization pass which would run first, but the 10729existence of `STMT_EXPR' meant that in order to convert all of the C 10730statements into GENERIC equivalents would involve walking the entire 10731tree anyway, so it was simpler to lower all the way. This might change 10732in the future if someone writes an optimization pass which would work 10733better with higher-level trees, but currently the optimizers all expect 10734GIMPLE. 10735 10736 You can request to dump a C-like representation of the GIMPLE form 10737with the flag `-fdump-tree-gimple'. 10738 10739* Menu: 10740 10741* Tuple representation:: 10742* Class hierarchy of GIMPLE statements:: 10743* GIMPLE instruction set:: 10744* GIMPLE Exception Handling:: 10745* Temporaries:: 10746* Operands:: 10747* Manipulating GIMPLE statements:: 10748* Tuple specific accessors:: 10749* GIMPLE sequences:: 10750* Sequence iterators:: 10751* Adding a new GIMPLE statement code:: 10752* Statement and operand traversals:: 10753 10754 10755File: gccint.info, Node: Tuple representation, Next: Class hierarchy of GIMPLE statements, Up: GIMPLE 10756 1075711.1 Tuple representation 10758========================= 10759 10760GIMPLE instructions are tuples of variable size divided in two groups: 10761a header describing the instruction and its locations, and a variable 10762length body with all the operands. Tuples are organized into a 10763hierarchy with 3 main classes of tuples. 10764 1076511.1.1 `gimple_statement_base' (gsbase) 10766--------------------------------------- 10767 10768This is the root of the hierarchy, it holds basic information needed by 10769most GIMPLE statements. There are some fields that may not be relevant 10770to every GIMPLE statement, but those were moved into the base structure 10771to take advantage of holes left by other fields (thus making the 10772structure more compact). The structure takes 4 words (32 bytes) on 64 10773bit hosts: 10774 10775Field Size (bits) 10776`code' 8 10777`subcode' 16 10778`no_warning' 1 10779`visited' 1 10780`nontemporal_move' 1 10781`plf' 2 10782`modified' 1 10783`has_volatile_ops' 1 10784`references_memory_p' 1 10785`uid' 32 10786`location' 32 10787`num_ops' 32 10788`bb' 64 10789`block' 63 10790Total size 32 bytes 10791 10792 * `code' Main identifier for a GIMPLE instruction. 10793 10794 * `subcode' Used to distinguish different variants of the same basic 10795 instruction or provide flags applicable to a given code. The 10796 `subcode' flags field has different uses depending on the code of 10797 the instruction, but mostly it distinguishes instructions of the 10798 same family. The most prominent use of this field is in 10799 assignments, where subcode indicates the operation done on the RHS 10800 of the assignment. For example, a = b + c is encoded as 10801 `GIMPLE_ASSIGN <PLUS_EXPR, a, b, c>'. 10802 10803 * `no_warning' Bitflag to indicate whether a warning has already 10804 been issued on this statement. 10805 10806 * `visited' General purpose "visited" marker. Set and cleared by 10807 each pass when needed. 10808 10809 * `nontemporal_move' Bitflag used in assignments that represent 10810 non-temporal moves. Although this bitflag is only used in 10811 assignments, it was moved into the base to take advantage of the 10812 bit holes left by the previous fields. 10813 10814 * `plf' Pass Local Flags. This 2-bit mask can be used as general 10815 purpose markers by any pass. Passes are responsible for clearing 10816 and setting these two flags accordingly. 10817 10818 * `modified' Bitflag to indicate whether the statement has been 10819 modified. Used mainly by the operand scanner to determine when to 10820 re-scan a statement for operands. 10821 10822 * `has_volatile_ops' Bitflag to indicate whether this statement 10823 contains operands that have been marked volatile. 10824 10825 * `references_memory_p' Bitflag to indicate whether this statement 10826 contains memory references (i.e., its operands are either global 10827 variables, or pointer dereferences or anything that must reside in 10828 memory). 10829 10830 * `uid' This is an unsigned integer used by passes that want to 10831 assign IDs to every statement. These IDs must be assigned and used 10832 by each pass. 10833 10834 * `location' This is a `location_t' identifier to specify source code 10835 location for this statement. It is inherited from the front end. 10836 10837 * `num_ops' Number of operands that this statement has. This 10838 specifies the size of the operand vector embedded in the tuple. 10839 Only used in some tuples, but it is declared in the base tuple to 10840 take advantage of the 32-bit hole left by the previous fields. 10841 10842 * `bb' Basic block holding the instruction. 10843 10844 * `block' Lexical block holding this statement. Also used for debug 10845 information generation. 10846 1084711.1.2 `gimple_statement_with_ops' 10848---------------------------------- 10849 10850This tuple is actually split in two: `gimple_statement_with_ops_base' 10851and `gimple_statement_with_ops'. This is needed to accommodate the way 10852the operand vector is allocated. The operand vector is defined to be an 10853array of 1 element. So, to allocate a dynamic number of operands, the 10854memory allocator (`gimple_alloc') simply allocates enough memory to 10855hold the structure itself plus `N - 1' operands which run "off the end" 10856of the structure. For example, to allocate space for a tuple with 3 10857operands, `gimple_alloc' reserves `sizeof (struct 10858gimple_statement_with_ops) + 2 * sizeof (tree)' bytes. 10859 10860 On the other hand, several fields in this tuple need to be shared with 10861the `gimple_statement_with_memory_ops' tuple. So, these common fields 10862are placed in `gimple_statement_with_ops_base' which is then inherited 10863from the other two tuples. 10864 10865`gsbase' 256 10866`def_ops' 64 10867`use_ops' 64 10868`op' `num_ops' * 64 10869Total size 48 + 8 * `num_ops' bytes 10870 10871 * `gsbase' Inherited from `struct gimple_statement_base'. 10872 10873 * `def_ops' Array of pointers into the operand array indicating all 10874 the slots that contain a variable written-to by the statement. 10875 This array is also used for immediate use chaining. Note that it 10876 would be possible to not rely on this array, but the changes 10877 required to implement this are pretty invasive. 10878 10879 * `use_ops' Similar to `def_ops' but for variables read by the 10880 statement. 10881 10882 * `op' Array of trees with `num_ops' slots. 10883 1088411.1.3 `gimple_statement_with_memory_ops' 10885----------------------------------------- 10886 10887This tuple is essentially identical to `gimple_statement_with_ops', 10888except that it contains 4 additional fields to hold vectors related 10889memory stores and loads. Similar to the previous case, the structure 10890is split in two to accommodate for the operand vector 10891(`gimple_statement_with_memory_ops_base' and 10892`gimple_statement_with_memory_ops'). 10893 10894Field Size (bits) 10895`gsbase' 256 10896`def_ops' 64 10897`use_ops' 64 10898`vdef_ops' 64 10899`vuse_ops' 64 10900`stores' 64 10901`loads' 64 10902`op' `num_ops' * 64 10903Total size 80 + 8 * `num_ops' bytes 10904 10905 * `vdef_ops' Similar to `def_ops' but for `VDEF' operators. There is 10906 one entry per memory symbol written by this statement. This is 10907 used to maintain the memory SSA use-def and def-def chains. 10908 10909 * `vuse_ops' Similar to `use_ops' but for `VUSE' operators. There is 10910 one entry per memory symbol loaded by this statement. This is used 10911 to maintain the memory SSA use-def chains. 10912 10913 * `stores' Bitset with all the UIDs for the symbols written-to by the 10914 statement. This is different than `vdef_ops' in that all the 10915 affected symbols are mentioned in this set. If memory 10916 partitioning is enabled, the `vdef_ops' vector will refer to memory 10917 partitions. Furthermore, no SSA information is stored in this set. 10918 10919 * `loads' Similar to `stores', but for memory loads. (Note that there 10920 is some amount of redundancy here, it should be possible to reduce 10921 memory utilization further by removing these sets). 10922 10923 All the other tuples are defined in terms of these three basic ones. 10924Each tuple will add some fields. 10925 10926 10927File: gccint.info, Node: Class hierarchy of GIMPLE statements, Next: GIMPLE instruction set, Prev: Tuple representation, Up: GIMPLE 10928 1092911.2 Class hierarchy of GIMPLE statements 10930========================================= 10931 10932The following diagram shows the C++ inheritance hierarchy of statement 10933kinds, along with their relationships to `GSS_' values (layouts) and 10934`GIMPLE_' values (codes): 10935 10936 gimple_statement_base 10937 | layout: GSS_BASE 10938 | used for 4 codes: GIMPLE_ERROR_MARK 10939 | GIMPLE_NOP 10940 | GIMPLE_OMP_SECTIONS_SWITCH 10941 | GIMPLE_PREDICT 10942 | 10943 + gimple_statement_with_ops_base 10944 | | (no GSS layout) 10945 | | 10946 | + gimple_statement_with_ops 10947 | | | layout: GSS_WITH_OPS 10948 | | | 10949 | | + gcond 10950 | | | code: GIMPLE_COND 10951 | | | 10952 | | + gdebug 10953 | | | code: GIMPLE_DEBUG 10954 | | | 10955 | | + ggoto 10956 | | | code: GIMPLE_GOTO 10957 | | | 10958 | | + glabel 10959 | | | code: GIMPLE_LABEL 10960 | | | 10961 | | + gswitch 10962 | | code: GIMPLE_SWITCH 10963 | | 10964 | + gimple_statement_with_memory_ops_base 10965 | | layout: GSS_WITH_MEM_OPS_BASE 10966 | | 10967 | + gimple_statement_with_memory_ops 10968 | | | layout: GSS_WITH_MEM_OPS 10969 | | | 10970 | | + gassign 10971 | | | code GIMPLE_ASSIGN 10972 | | | 10973 | | + greturn 10974 | | code GIMPLE_RETURN 10975 | | 10976 | + gcall 10977 | | layout: GSS_CALL, code: GIMPLE_CALL 10978 | | 10979 | + gasm 10980 | | layout: GSS_ASM, code: GIMPLE_ASM 10981 | | 10982 | + gtransaction 10983 | layout: GSS_TRANSACTION, code: GIMPLE_TRANSACTION 10984 | 10985 + gimple_statement_omp 10986 | | layout: GSS_OMP. Used for code GIMPLE_OMP_SECTION 10987 | | 10988 | + gomp_critical 10989 | | layout: GSS_OMP_CRITICAL, code: GIMPLE_OMP_CRITICAL 10990 | | 10991 | + gomp_for 10992 | | layout: GSS_OMP_FOR, code: GIMPLE_OMP_FOR 10993 | | 10994 | + gomp_parallel_layout 10995 | | | layout: GSS_OMP_PARALLEL_LAYOUT 10996 | | | 10997 | | + gimple_statement_omp_taskreg 10998 | | | | 10999 | | | + gomp_parallel 11000 | | | | code: GIMPLE_OMP_PARALLEL 11001 | | | | 11002 | | | + gomp_task 11003 | | | code: GIMPLE_OMP_TASK 11004 | | | 11005 | | + gimple_statement_omp_target 11006 | | code: GIMPLE_OMP_TARGET 11007 | | 11008 | + gomp_sections 11009 | | layout: GSS_OMP_SECTIONS, code: GIMPLE_OMP_SECTIONS 11010 | | 11011 | + gimple_statement_omp_single_layout 11012 | | layout: GSS_OMP_SINGLE_LAYOUT 11013 | | 11014 | + gomp_single 11015 | | code: GIMPLE_OMP_SINGLE 11016 | | 11017 | + gomp_teams 11018 | code: GIMPLE_OMP_TEAMS 11019 | 11020 + gbind 11021 | layout: GSS_BIND, code: GIMPLE_BIND 11022 | 11023 + gcatch 11024 | layout: GSS_CATCH, code: GIMPLE_CATCH 11025 | 11026 + geh_filter 11027 | layout: GSS_EH_FILTER, code: GIMPLE_EH_FILTER 11028 | 11029 + geh_else 11030 | layout: GSS_EH_ELSE, code: GIMPLE_EH_ELSE 11031 | 11032 + geh_mnt 11033 | layout: GSS_EH_MNT, code: GIMPLE_EH_MUST_NOT_THROW 11034 | 11035 + gphi 11036 | layout: GSS_PHI, code: GIMPLE_PHI 11037 | 11038 + gimple_statement_eh_ctrl 11039 | | layout: GSS_EH_CTRL 11040 | | 11041 | + gresx 11042 | | code: GIMPLE_RESX 11043 | | 11044 | + geh_dispatch 11045 | code: GIMPLE_EH_DISPATCH 11046 | 11047 + gtry 11048 | layout: GSS_TRY, code: GIMPLE_TRY 11049 | 11050 + gimple_statement_wce 11051 | layout: GSS_WCE, code: GIMPLE_WITH_CLEANUP_EXPR 11052 | 11053 + gomp_continue 11054 | layout: GSS_OMP_CONTINUE, code: GIMPLE_OMP_CONTINUE 11055 | 11056 + gomp_atomic_load 11057 | layout: GSS_OMP_ATOMIC_LOAD, code: GIMPLE_OMP_ATOMIC_LOAD 11058 | 11059 + gimple_statement_omp_atomic_store_layout 11060 | layout: GSS_OMP_ATOMIC_STORE_LAYOUT, 11061 | code: GIMPLE_OMP_ATOMIC_STORE 11062 | 11063 + gomp_atomic_store 11064 | code: GIMPLE_OMP_ATOMIC_STORE 11065 | 11066 + gomp_return 11067 code: GIMPLE_OMP_RETURN 11068 11069 11070File: gccint.info, Node: GIMPLE instruction set, Next: GIMPLE Exception Handling, Prev: Class hierarchy of GIMPLE statements, Up: GIMPLE 11071 1107211.3 GIMPLE instruction set 11073=========================== 11074 11075The following table briefly describes the GIMPLE instruction set. 11076 11077Instruction High GIMPLE Low GIMPLE 11078`GIMPLE_ASM' x x 11079`GIMPLE_ASSIGN' x x 11080`GIMPLE_BIND' x 11081`GIMPLE_CALL' x x 11082`GIMPLE_CATCH' x 11083`GIMPLE_COND' x x 11084`GIMPLE_DEBUG' x x 11085`GIMPLE_EH_FILTER' x 11086`GIMPLE_GOTO' x x 11087`GIMPLE_LABEL' x x 11088`GIMPLE_NOP' x x 11089`GIMPLE_OMP_ATOMIC_LOAD' x x 11090`GIMPLE_OMP_ATOMIC_STORE' x x 11091`GIMPLE_OMP_CONTINUE' x x 11092`GIMPLE_OMP_CRITICAL' x x 11093`GIMPLE_OMP_FOR' x x 11094`GIMPLE_OMP_MASTER' x x 11095`GIMPLE_OMP_ORDERED' x x 11096`GIMPLE_OMP_PARALLEL' x x 11097`GIMPLE_OMP_RETURN' x x 11098`GIMPLE_OMP_SECTION' x x 11099`GIMPLE_OMP_SECTIONS' x x 11100`GIMPLE_OMP_SECTIONS_SWITCH' x x 11101`GIMPLE_OMP_SINGLE' x x 11102`GIMPLE_PHI' x 11103`GIMPLE_RESX' x 11104`GIMPLE_RETURN' x x 11105`GIMPLE_SWITCH' x x 11106`GIMPLE_TRY' x 11107 11108 11109File: gccint.info, Node: GIMPLE Exception Handling, Next: Temporaries, Prev: GIMPLE instruction set, Up: GIMPLE 11110 1111111.4 Exception Handling 11112======================= 11113 11114Other exception handling constructs are represented using 11115`GIMPLE_TRY_CATCH'. `GIMPLE_TRY_CATCH' has two operands. The first 11116operand is a sequence of statements to execute. If executing these 11117statements does not throw an exception, then the second operand is 11118ignored. Otherwise, if an exception is thrown, then the second operand 11119of the `GIMPLE_TRY_CATCH' is checked. The second operand may have the 11120following forms: 11121 11122 1. A sequence of statements to execute. When an exception occurs, 11123 these statements are executed, and then the exception is rethrown. 11124 11125 2. A sequence of `GIMPLE_CATCH' statements. Each `GIMPLE_CATCH' has 11126 a list of applicable exception types and handler code. If the 11127 thrown exception matches one of the caught types, the associated 11128 handler code is executed. If the handler code falls off the 11129 bottom, execution continues after the original `GIMPLE_TRY_CATCH'. 11130 11131 3. A `GIMPLE_EH_FILTER' statement. This has a list of permitted 11132 exception types, and code to handle a match failure. If the 11133 thrown exception does not match one of the allowed types, the 11134 associated match failure code is executed. If the thrown exception 11135 does match, it continues unwinding the stack looking for the next 11136 handler. 11137 11138 11139 Currently throwing an exception is not directly represented in GIMPLE, 11140since it is implemented by calling a function. At some point in the 11141future we will want to add some way to express that the call will throw 11142an exception of a known type. 11143 11144 Just before running the optimizers, the compiler lowers the high-level 11145EH constructs above into a set of `goto's, magic labels, and EH 11146regions. Continuing to unwind at the end of a cleanup is represented 11147with a `GIMPLE_RESX'. 11148 11149 11150File: gccint.info, Node: Temporaries, Next: Operands, Prev: GIMPLE Exception Handling, Up: GIMPLE 11151 1115211.5 Temporaries 11153================ 11154 11155When gimplification encounters a subexpression that is too complex, it 11156creates a new temporary variable to hold the value of the 11157subexpression, and adds a new statement to initialize it before the 11158current statement. These special temporaries are known as `expression 11159temporaries', and are allocated using `get_formal_tmp_var'. The 11160compiler tries to always evaluate identical expressions into the same 11161temporary, to simplify elimination of redundant calculations. 11162 11163 We can only use expression temporaries when we know that it will not 11164be reevaluated before its value is used, and that it will not be 11165otherwise modified(1). Other temporaries can be allocated using 11166`get_initialized_tmp_var' or `create_tmp_var'. 11167 11168 Currently, an expression like `a = b + 5' is not reduced any further. 11169We tried converting it to something like 11170 T1 = b + 5; 11171 a = T1; 11172 but this bloated the representation for minimal benefit. However, a 11173variable which must live in memory cannot appear in an expression; its 11174value is explicitly loaded into a temporary first. Similarly, storing 11175the value of an expression to a memory variable goes through a 11176temporary. 11177 11178 ---------- Footnotes ---------- 11179 11180 (1) These restrictions are derived from those in Morgan 4.8. 11181 11182 11183File: gccint.info, Node: Operands, Next: Manipulating GIMPLE statements, Prev: Temporaries, Up: GIMPLE 11184 1118511.6 Operands 11186============= 11187 11188In general, expressions in GIMPLE consist of an operation and the 11189appropriate number of simple operands; these operands must either be a 11190GIMPLE rvalue (`is_gimple_val'), i.e. a constant or a register 11191variable. More complex operands are factored out into temporaries, so 11192that 11193 a = b + c + d 11194 becomes 11195 T1 = b + c; 11196 a = T1 + d; 11197 11198 The same rule holds for arguments to a `GIMPLE_CALL'. 11199 11200 The target of an assignment is usually a variable, but can also be a 11201`MEM_REF' or a compound lvalue as described below. 11202 11203* Menu: 11204 11205* Compound Expressions:: 11206* Compound Lvalues:: 11207* Conditional Expressions:: 11208* Logical Operators:: 11209 11210 11211File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: Operands 11212 1121311.6.1 Compound Expressions 11214--------------------------- 11215 11216The left-hand side of a C comma expression is simply moved into a 11217separate statement. 11218 11219 11220File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: Operands 11221 1122211.6.2 Compound Lvalues 11223----------------------- 11224 11225Currently compound lvalues involving array and structure field 11226references are not broken down; an expression like `a.b[2] = 42' is not 11227reduced any further (though complex array subscripts are). This 11228restriction is a workaround for limitations in later optimizers; if we 11229were to convert this to 11230 11231 T1 = &a.b; 11232 T1[2] = 42; 11233 11234 alias analysis would not remember that the reference to `T1[2]' came 11235by way of `a.b', so it would think that the assignment could alias 11236another member of `a'; this broke `struct-alias-1.c'. Future optimizer 11237improvements may make this limitation unnecessary. 11238 11239 11240File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: Operands 11241 1124211.6.3 Conditional Expressions 11243------------------------------ 11244 11245A C `?:' expression is converted into an `if' statement with each 11246branch assigning to the same temporary. So, 11247 11248 a = b ? c : d; 11249 becomes 11250 if (b == 1) 11251 T1 = c; 11252 else 11253 T1 = d; 11254 a = T1; 11255 11256 The GIMPLE level if-conversion pass re-introduces `?:' expression, if 11257appropriate. It is used to vectorize loops with conditions using vector 11258conditional operations. 11259 11260 Note that in GIMPLE, `if' statements are represented using 11261`GIMPLE_COND', as described below. 11262 11263 11264File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: Operands 11265 1126611.6.4 Logical Operators 11267------------------------ 11268 11269Except when they appear in the condition operand of a `GIMPLE_COND', 11270logical `and' and `or' operators are simplified as follows: `a = b && 11271c' becomes 11272 11273 T1 = (bool)b; 11274 if (T1 == true) 11275 T1 = (bool)c; 11276 a = T1; 11277 11278 Note that `T1' in this example cannot be an expression temporary, 11279because it has two different assignments. 11280 1128111.6.5 Manipulating operands 11282---------------------------- 11283 11284All gimple operands are of type `tree'. But only certain types of 11285trees are allowed to be used as operand tuples. Basic validation is 11286controlled by the function `get_gimple_rhs_class', which given a tree 11287code, returns an `enum' with the following values of type `enum 11288gimple_rhs_class' 11289 11290 * `GIMPLE_INVALID_RHS' The tree cannot be used as a GIMPLE operand. 11291 11292 * `GIMPLE_TERNARY_RHS' The tree is a valid GIMPLE ternary operation. 11293 11294 * `GIMPLE_BINARY_RHS' The tree is a valid GIMPLE binary operation. 11295 11296 * `GIMPLE_UNARY_RHS' The tree is a valid GIMPLE unary operation. 11297 11298 * `GIMPLE_SINGLE_RHS' The tree is a single object, that cannot be 11299 split into simpler operands (for instance, `SSA_NAME', `VAR_DECL', 11300 `COMPONENT_REF', etc). 11301 11302 This operand class also acts as an escape hatch for tree nodes 11303 that may be flattened out into the operand vector, but would need 11304 more than two slots on the RHS. For instance, a `COND_EXPR' 11305 expression of the form `(a op b) ? x : y' could be flattened out 11306 on the operand vector using 4 slots, but it would also require 11307 additional processing to distinguish `c = a op b' from `c = a op b 11308 ? x : y'. Something similar occurs with `ASSERT_EXPR'. In time, 11309 these special case tree expressions should be flattened into the 11310 operand vector. 11311 11312 For tree nodes in the categories `GIMPLE_TERNARY_RHS', 11313`GIMPLE_BINARY_RHS' and `GIMPLE_UNARY_RHS', they cannot be stored 11314inside tuples directly. They first need to be flattened and separated 11315into individual components. For instance, given the GENERIC expression 11316 11317 a = b + c 11318 11319 its tree representation is: 11320 11321 MODIFY_EXPR <VAR_DECL <a>, PLUS_EXPR <VAR_DECL <b>, VAR_DECL <c>>> 11322 11323 In this case, the GIMPLE form for this statement is logically 11324identical to its GENERIC form but in GIMPLE, the `PLUS_EXPR' on the RHS 11325of the assignment is not represented as a tree, instead the two 11326operands are taken out of the `PLUS_EXPR' sub-tree and flattened into 11327the GIMPLE tuple as follows: 11328 11329 GIMPLE_ASSIGN <PLUS_EXPR, VAR_DECL <a>, VAR_DECL <b>, VAR_DECL <c>> 11330 1133111.6.6 Operand vector allocation 11332-------------------------------- 11333 11334The operand vector is stored at the bottom of the three tuple 11335structures that accept operands. This means, that depending on the code 11336of a given statement, its operand vector will be at different offsets 11337from the base of the structure. To access tuple operands use the 11338following accessors 11339 11340 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 11341 Returns the number of operands in statement G. 11342 11343 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 11344 Returns operand `I' from statement `G'. 11345 11346 -- GIMPLE function: tree * gimple_ops (gimple g) 11347 Returns a pointer into the operand vector for statement `G'. This 11348 is computed using an internal table called `gimple_ops_offset_'[]. 11349 This table is indexed by the gimple code of `G'. 11350 11351 When the compiler is built, this table is filled-in using the 11352 sizes of the structures used by each statement code defined in 11353 gimple.def. Since the operand vector is at the bottom of the 11354 structure, for a gimple code `C' the offset is computed as sizeof 11355 (struct-of `C') - sizeof (tree). 11356 11357 This mechanism adds one memory indirection to every access when 11358 using `gimple_op'(), if this becomes a bottleneck, a pass can 11359 choose to memoize the result from `gimple_ops'() and use that to 11360 access the operands. 11361 1136211.6.7 Operand validation 11363------------------------- 11364 11365When adding a new operand to a gimple statement, the operand will be 11366validated according to what each tuple accepts in its operand vector. 11367These predicates are called by the `gimple_NAME_set_...()'. Each tuple 11368will use one of the following predicates (Note, this list is not 11369exhaustive): 11370 11371 -- GIMPLE function: bool is_gimple_val (tree t) 11372 Returns true if t is a "GIMPLE value", which are all the 11373 non-addressable stack variables (variables for which 11374 `is_gimple_reg' returns true) and constants (expressions for which 11375 `is_gimple_min_invariant' returns true). 11376 11377 -- GIMPLE function: bool is_gimple_addressable (tree t) 11378 Returns true if t is a symbol or memory reference whose address 11379 can be taken. 11380 11381 -- GIMPLE function: bool is_gimple_asm_val (tree t) 11382 Similar to `is_gimple_val' but it also accepts hard registers. 11383 11384 -- GIMPLE function: bool is_gimple_call_addr (tree t) 11385 Return true if t is a valid expression to use as the function 11386 called by a `GIMPLE_CALL'. 11387 11388 -- GIMPLE function: bool is_gimple_mem_ref_addr (tree t) 11389 Return true if t is a valid expression to use as first operand of 11390 a `MEM_REF' expression. 11391 11392 -- GIMPLE function: bool is_gimple_constant (tree t) 11393 Return true if t is a valid gimple constant. 11394 11395 -- GIMPLE function: bool is_gimple_min_invariant (tree t) 11396 Return true if t is a valid minimal invariant. This is different 11397 from constants, in that the specific value of t may not be known 11398 at compile time, but it is known that it doesn't change (e.g., the 11399 address of a function local variable). 11400 11401 -- GIMPLE function: bool is_gimple_ip_invariant (tree t) 11402 Return true if t is an interprocedural invariant. This means that 11403 t is a valid invariant in all functions (e.g. it can be an address 11404 of a global variable but not of a local one). 11405 11406 -- GIMPLE function: bool is_gimple_ip_invariant_address (tree t) 11407 Return true if t is an `ADDR_EXPR' that does not change once the 11408 program is running (and which is valid in all functions). 11409 1141011.6.8 Statement validation 11411--------------------------- 11412 11413 -- GIMPLE function: bool is_gimple_assign (gimple g) 11414 Return true if the code of g is `GIMPLE_ASSIGN'. 11415 11416 -- GIMPLE function: bool is_gimple_call (gimple g) 11417 Return true if the code of g is `GIMPLE_CALL'. 11418 11419 -- GIMPLE function: bool is_gimple_debug (gimple g) 11420 Return true if the code of g is `GIMPLE_DEBUG'. 11421 11422 -- GIMPLE function: bool gimple_assign_cast_p (const_gimple g) 11423 Return true if g is a `GIMPLE_ASSIGN' that performs a type cast 11424 operation. 11425 11426 -- GIMPLE function: bool gimple_debug_bind_p (gimple g) 11427 Return true if g is a `GIMPLE_DEBUG' that binds the value of an 11428 expression to a variable. 11429 11430 -- GIMPLE function: bool is_gimple_omp (gimple g) 11431 Return true if g is any of the OpenMP codes. 11432 11433 11434File: gccint.info, Node: Manipulating GIMPLE statements, Next: Tuple specific accessors, Prev: Operands, Up: GIMPLE 11435 1143611.7 Manipulating GIMPLE statements 11437=================================== 11438 11439This section documents all the functions available to handle each of 11440the GIMPLE instructions. 11441 1144211.7.1 Common accessors 11443----------------------- 11444 11445The following are common accessors for gimple statements. 11446 11447 -- GIMPLE function: enum gimple_code gimple_code (gimple g) 11448 Return the code for statement `G'. 11449 11450 -- GIMPLE function: basic_block gimple_bb (gimple g) 11451 Return the basic block to which statement `G' belongs to. 11452 11453 -- GIMPLE function: tree gimple_block (gimple g) 11454 Return the lexical scope block holding statement `G'. 11455 11456 -- GIMPLE function: tree gimple_expr_type (gimple stmt) 11457 Return the type of the main expression computed by `STMT'. Return 11458 `void_type_node' if `STMT' computes nothing. This will only return 11459 something meaningful for `GIMPLE_ASSIGN', `GIMPLE_COND' and 11460 `GIMPLE_CALL'. For all other tuple codes, it will return 11461 `void_type_node'. 11462 11463 -- GIMPLE function: enum tree_code gimple_expr_code (gimple stmt) 11464 Return the tree code for the expression computed by `STMT'. This 11465 is only meaningful for `GIMPLE_CALL', `GIMPLE_ASSIGN' and 11466 `GIMPLE_COND'. If `STMT' is `GIMPLE_CALL', it will return 11467 `CALL_EXPR'. For `GIMPLE_COND', it returns the code of the 11468 comparison predicate. For `GIMPLE_ASSIGN' it returns the code of 11469 the operation performed by the `RHS' of the assignment. 11470 11471 -- GIMPLE function: void gimple_set_block (gimple g, tree block) 11472 Set the lexical scope block of `G' to `BLOCK'. 11473 11474 -- GIMPLE function: location_t gimple_locus (gimple g) 11475 Return locus information for statement `G'. 11476 11477 -- GIMPLE function: void gimple_set_locus (gimple g, location_t locus) 11478 Set locus information for statement `G'. 11479 11480 -- GIMPLE function: bool gimple_locus_empty_p (gimple g) 11481 Return true if `G' does not have locus information. 11482 11483 -- GIMPLE function: bool gimple_no_warning_p (gimple stmt) 11484 Return true if no warnings should be emitted for statement `STMT'. 11485 11486 -- GIMPLE function: void gimple_set_visited (gimple stmt, bool 11487 visited_p) 11488 Set the visited status on statement `STMT' to `VISITED_P'. 11489 11490 -- GIMPLE function: bool gimple_visited_p (gimple stmt) 11491 Return the visited status on statement `STMT'. 11492 11493 -- GIMPLE function: void gimple_set_plf (gimple stmt, enum plf_mask 11494 plf, bool val_p) 11495 Set pass local flag `PLF' on statement `STMT' to `VAL_P'. 11496 11497 -- GIMPLE function: unsigned int gimple_plf (gimple stmt, enum 11498 plf_mask plf) 11499 Return the value of pass local flag `PLF' on statement `STMT'. 11500 11501 -- GIMPLE function: bool gimple_has_ops (gimple g) 11502 Return true if statement `G' has register or memory operands. 11503 11504 -- GIMPLE function: bool gimple_has_mem_ops (gimple g) 11505 Return true if statement `G' has memory operands. 11506 11507 -- GIMPLE function: unsigned gimple_num_ops (gimple g) 11508 Return the number of operands for statement `G'. 11509 11510 -- GIMPLE function: tree * gimple_ops (gimple g) 11511 Return the array of operands for statement `G'. 11512 11513 -- GIMPLE function: tree gimple_op (gimple g, unsigned i) 11514 Return operand `I' for statement `G'. 11515 11516 -- GIMPLE function: tree * gimple_op_ptr (gimple g, unsigned i) 11517 Return a pointer to operand `I' for statement `G'. 11518 11519 -- GIMPLE function: void gimple_set_op (gimple g, unsigned i, tree op) 11520 Set operand `I' of statement `G' to `OP'. 11521 11522 -- GIMPLE function: bitmap gimple_addresses_taken (gimple stmt) 11523 Return the set of symbols that have had their address taken by 11524 `STMT'. 11525 11526 -- GIMPLE function: struct def_optype_d * gimple_def_ops (gimple g) 11527 Return the set of `DEF' operands for statement `G'. 11528 11529 -- GIMPLE function: void gimple_set_def_ops (gimple g, struct 11530 def_optype_d *def) 11531 Set `DEF' to be the set of `DEF' operands for statement `G'. 11532 11533 -- GIMPLE function: struct use_optype_d * gimple_use_ops (gimple g) 11534 Return the set of `USE' operands for statement `G'. 11535 11536 -- GIMPLE function: void gimple_set_use_ops (gimple g, struct 11537 use_optype_d *use) 11538 Set `USE' to be the set of `USE' operands for statement `G'. 11539 11540 -- GIMPLE function: struct voptype_d * gimple_vuse_ops (gimple g) 11541 Return the set of `VUSE' operands for statement `G'. 11542 11543 -- GIMPLE function: void gimple_set_vuse_ops (gimple g, struct 11544 voptype_d *ops) 11545 Set `OPS' to be the set of `VUSE' operands for statement `G'. 11546 11547 -- GIMPLE function: struct voptype_d * gimple_vdef_ops (gimple g) 11548 Return the set of `VDEF' operands for statement `G'. 11549 11550 -- GIMPLE function: void gimple_set_vdef_ops (gimple g, struct 11551 voptype_d *ops) 11552 Set `OPS' to be the set of `VDEF' operands for statement `G'. 11553 11554 -- GIMPLE function: bitmap gimple_loaded_syms (gimple g) 11555 Return the set of symbols loaded by statement `G'. Each element of 11556 the set is the `DECL_UID' of the corresponding symbol. 11557 11558 -- GIMPLE function: bitmap gimple_stored_syms (gimple g) 11559 Return the set of symbols stored by statement `G'. Each element of 11560 the set is the `DECL_UID' of the corresponding symbol. 11561 11562 -- GIMPLE function: bool gimple_modified_p (gimple g) 11563 Return true if statement `G' has operands and the modified field 11564 has been set. 11565 11566 -- GIMPLE function: bool gimple_has_volatile_ops (gimple stmt) 11567 Return true if statement `STMT' contains volatile operands. 11568 11569 -- GIMPLE function: void gimple_set_has_volatile_ops (gimple stmt, 11570 bool volatilep) 11571 Return true if statement `STMT' contains volatile operands. 11572 11573 -- GIMPLE function: void update_stmt (gimple s) 11574 Mark statement `S' as modified, and update it. 11575 11576 -- GIMPLE function: void update_stmt_if_modified (gimple s) 11577 Update statement `S' if it has been marked modified. 11578 11579 -- GIMPLE function: gimple gimple_copy (gimple stmt) 11580 Return a deep copy of statement `STMT'. 11581 11582 11583File: gccint.info, Node: Tuple specific accessors, Next: GIMPLE sequences, Prev: Manipulating GIMPLE statements, Up: GIMPLE 11584 1158511.8 Tuple specific accessors 11586============================= 11587 11588* Menu: 11589 11590* `GIMPLE_ASM':: 11591* `GIMPLE_ASSIGN':: 11592* `GIMPLE_BIND':: 11593* `GIMPLE_CALL':: 11594* `GIMPLE_CATCH':: 11595* `GIMPLE_COND':: 11596* `GIMPLE_DEBUG':: 11597* `GIMPLE_EH_FILTER':: 11598* `GIMPLE_LABEL':: 11599* `GIMPLE_GOTO':: 11600* `GIMPLE_NOP':: 11601* `GIMPLE_OMP_ATOMIC_LOAD':: 11602* `GIMPLE_OMP_ATOMIC_STORE':: 11603* `GIMPLE_OMP_CONTINUE':: 11604* `GIMPLE_OMP_CRITICAL':: 11605* `GIMPLE_OMP_FOR':: 11606* `GIMPLE_OMP_MASTER':: 11607* `GIMPLE_OMP_ORDERED':: 11608* `GIMPLE_OMP_PARALLEL':: 11609* `GIMPLE_OMP_RETURN':: 11610* `GIMPLE_OMP_SECTION':: 11611* `GIMPLE_OMP_SECTIONS':: 11612* `GIMPLE_OMP_SINGLE':: 11613* `GIMPLE_PHI':: 11614* `GIMPLE_RESX':: 11615* `GIMPLE_RETURN':: 11616* `GIMPLE_SWITCH':: 11617* `GIMPLE_TRY':: 11618* `GIMPLE_WITH_CLEANUP_EXPR':: 11619 11620 11621File: gccint.info, Node: `GIMPLE_ASM', Next: `GIMPLE_ASSIGN', Up: Tuple specific accessors 11622 1162311.8.1 `GIMPLE_ASM' 11624------------------- 11625 11626 -- GIMPLE function: gasm *gimple_build_asm_vec ( const char *string, 11627 vec<tree, va_gc> *inputs, vec<tree, va_gc> *outputs, 11628 vec<tree, va_gc> *clobbers, vec<tree, va_gc> *labels) 11629 Build a `GIMPLE_ASM' statement. This statement is used for 11630 building in-line assembly constructs. `STRING' is the assembly 11631 code. `INPUTS', `OUTPUTS', `CLOBBERS' and `LABELS' are the 11632 inputs, outputs, clobbered registers and labels. 11633 11634 -- GIMPLE function: unsigned gimple_asm_ninputs (const gasm *g) 11635 Return the number of input operands for `GIMPLE_ASM' `G'. 11636 11637 -- GIMPLE function: unsigned gimple_asm_noutputs (const gasm *g) 11638 Return the number of output operands for `GIMPLE_ASM' `G'. 11639 11640 -- GIMPLE function: unsigned gimple_asm_nclobbers (const gasm *g) 11641 Return the number of clobber operands for `GIMPLE_ASM' `G'. 11642 11643 -- GIMPLE function: tree gimple_asm_input_op (const gasm *g, unsigned 11644 index) 11645 Return input operand `INDEX' of `GIMPLE_ASM' `G'. 11646 11647 -- GIMPLE function: void gimple_asm_set_input_op (gasm *g, unsigned 11648 index, tree in_op) 11649 Set `IN_OP' to be input operand `INDEX' in `GIMPLE_ASM' `G'. 11650 11651 -- GIMPLE function: tree gimple_asm_output_op (const gasm *g, unsigned 11652 index) 11653 Return output operand `INDEX' of `GIMPLE_ASM' `G'. 11654 11655 -- GIMPLE function: void gimple_asm_set_output_op (gasm *g, unsigned 11656 index, tree out_op) 11657 Set `OUT_OP' to be output operand `INDEX' in `GIMPLE_ASM' `G'. 11658 11659 -- GIMPLE function: tree gimple_asm_clobber_op (const gasm *g, 11660 unsigned index) 11661 Return clobber operand `INDEX' of `GIMPLE_ASM' `G'. 11662 11663 -- GIMPLE function: void gimple_asm_set_clobber_op (gasm *g, unsigned 11664 index, tree clobber_op) 11665 Set `CLOBBER_OP' to be clobber operand `INDEX' in `GIMPLE_ASM' `G'. 11666 11667 -- GIMPLE function: const char * gimple_asm_string (const gasm *g) 11668 Return the string representing the assembly instruction in 11669 `GIMPLE_ASM' `G'. 11670 11671 -- GIMPLE function: bool gimple_asm_volatile_p (const gasm *g) 11672 Return true if `G' is an asm statement marked volatile. 11673 11674 -- GIMPLE function: void gimple_asm_set_volatile (gasm *g, bool 11675 volatile_p) 11676 Mark asm statement `G' as volatile or non-volatile based on 11677 `VOLATILE_P'. 11678 11679 11680File: gccint.info, Node: `GIMPLE_ASSIGN', Next: `GIMPLE_BIND', Prev: `GIMPLE_ASM', Up: Tuple specific accessors 11681 1168211.8.2 `GIMPLE_ASSIGN' 11683---------------------- 11684 11685 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, tree rhs) 11686 Build a `GIMPLE_ASSIGN' statement. The left-hand side is an lvalue 11687 passed in lhs. The right-hand side can be either a unary or 11688 binary tree expression. The expression tree rhs will be flattened 11689 and its operands assigned to the corresponding operand slots in 11690 the new statement. This function is useful when you already have 11691 a tree expression that you want to convert into a tuple. However, 11692 try to avoid building expression trees for the sole purpose of 11693 calling this function. If you already have the operands in 11694 separate trees, it is better to use `gimple_build_assign' with 11695 `enum tree_code' argument and separate arguments for each operand. 11696 11697 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 11698 tree_code subcode, tree op1, tree op2, tree op3) 11699 This function is similar to two operand `gimple_build_assign', but 11700 is used to build a `GIMPLE_ASSIGN' statement when the operands of 11701 the right-hand side of the assignment are already split into 11702 different operands. 11703 11704 The left-hand side is an lvalue passed in lhs. Subcode is the 11705 `tree_code' for the right-hand side of the assignment. Op1, op2 11706 and op3 are the operands. 11707 11708 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 11709 tree_code subcode, tree op1, tree op2) 11710 Like the above 5 operand `gimple_build_assign', but with the last 11711 argument `NULL' - this overload should not be used for 11712 `GIMPLE_TERNARY_RHS' assignments. 11713 11714 -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum 11715 tree_code subcode, tree op1) 11716 Like the above 4 operand `gimple_build_assign', but with the last 11717 argument `NULL' - this overload should be used only for 11718 `GIMPLE_UNARY_RHS' and `GIMPLE_SINGLE_RHS' assignments. 11719 11720 -- GIMPLE function: gimple gimplify_assign (tree dst, tree src, 11721 gimple_seq *seq_p) 11722 Build a new `GIMPLE_ASSIGN' tuple and append it to the end of 11723 `*SEQ_P'. 11724 11725 `DST'/`SRC' are the destination and source respectively. You can pass 11726ungimplified trees in `DST' or `SRC', in which case they will be 11727converted to a gimple operand if necessary. 11728 11729 This function returns the newly created `GIMPLE_ASSIGN' tuple. 11730 11731 -- GIMPLE function: enum tree_code gimple_assign_rhs_code (gimple g) 11732 Return the code of the expression computed on the `RHS' of 11733 assignment statement `G'. 11734 11735 -- GIMPLE function: enum gimple_rhs_class gimple_assign_rhs_class 11736 (gimple g) 11737 Return the gimple rhs class of the code for the expression 11738 computed on the rhs of assignment statement `G'. This will never 11739 return `GIMPLE_INVALID_RHS'. 11740 11741 -- GIMPLE function: tree gimple_assign_lhs (gimple g) 11742 Return the `LHS' of assignment statement `G'. 11743 11744 -- GIMPLE function: tree * gimple_assign_lhs_ptr (gimple g) 11745 Return a pointer to the `LHS' of assignment statement `G'. 11746 11747 -- GIMPLE function: tree gimple_assign_rhs1 (gimple g) 11748 Return the first operand on the `RHS' of assignment statement `G'. 11749 11750 -- GIMPLE function: tree * gimple_assign_rhs1_ptr (gimple g) 11751 Return the address of the first operand on the `RHS' of assignment 11752 statement `G'. 11753 11754 -- GIMPLE function: tree gimple_assign_rhs2 (gimple g) 11755 Return the second operand on the `RHS' of assignment statement `G'. 11756 11757 -- GIMPLE function: tree * gimple_assign_rhs2_ptr (gimple g) 11758 Return the address of the second operand on the `RHS' of assignment 11759 statement `G'. 11760 11761 -- GIMPLE function: tree gimple_assign_rhs3 (gimple g) 11762 Return the third operand on the `RHS' of assignment statement `G'. 11763 11764 -- GIMPLE function: tree * gimple_assign_rhs3_ptr (gimple g) 11765 Return the address of the third operand on the `RHS' of assignment 11766 statement `G'. 11767 11768 -- GIMPLE function: void gimple_assign_set_lhs (gimple g, tree lhs) 11769 Set `LHS' to be the `LHS' operand of assignment statement `G'. 11770 11771 -- GIMPLE function: void gimple_assign_set_rhs1 (gimple g, tree rhs) 11772 Set `RHS' to be the first operand on the `RHS' of assignment 11773 statement `G'. 11774 11775 -- GIMPLE function: void gimple_assign_set_rhs2 (gimple g, tree rhs) 11776 Set `RHS' to be the second operand on the `RHS' of assignment 11777 statement `G'. 11778 11779 -- GIMPLE function: void gimple_assign_set_rhs3 (gimple g, tree rhs) 11780 Set `RHS' to be the third operand on the `RHS' of assignment 11781 statement `G'. 11782 11783 -- GIMPLE function: bool gimple_assign_cast_p (const_gimple s) 11784 Return true if `S' is a type-cast assignment. 11785 11786 11787File: gccint.info, Node: `GIMPLE_BIND', Next: `GIMPLE_CALL', Prev: `GIMPLE_ASSIGN', Up: Tuple specific accessors 11788 1178911.8.3 `GIMPLE_BIND' 11790-------------------- 11791 11792 -- GIMPLE function: gbind *gimple_build_bind (tree vars, gimple_seq 11793 body) 11794 Build a `GIMPLE_BIND' statement with a list of variables in `VARS' 11795 and a body of statements in sequence `BODY'. 11796 11797 -- GIMPLE function: tree gimple_bind_vars (const gbind *g) 11798 Return the variables declared in the `GIMPLE_BIND' statement `G'. 11799 11800 -- GIMPLE function: void gimple_bind_set_vars (gbind *g, tree vars) 11801 Set `VARS' to be the set of variables declared in the `GIMPLE_BIND' 11802 statement `G'. 11803 11804 -- GIMPLE function: void gimple_bind_append_vars (gbind *g, tree vars) 11805 Append `VARS' to the set of variables declared in the `GIMPLE_BIND' 11806 statement `G'. 11807 11808 -- GIMPLE function: gimple_seq gimple_bind_body (gbind *g) 11809 Return the GIMPLE sequence contained in the `GIMPLE_BIND' statement 11810 `G'. 11811 11812 -- GIMPLE function: void gimple_bind_set_body (gbind *g, gimple_seq 11813 seq) 11814 Set `SEQ' to be sequence contained in the `GIMPLE_BIND' statement 11815 `G'. 11816 11817 -- GIMPLE function: void gimple_bind_add_stmt (gbind *gs, gimple stmt) 11818 Append a statement to the end of a `GIMPLE_BIND''s body. 11819 11820 -- GIMPLE function: void gimple_bind_add_seq (gbind *gs, gimple_seq 11821 seq) 11822 Append a sequence of statements to the end of a `GIMPLE_BIND''s 11823 body. 11824 11825 -- GIMPLE function: tree gimple_bind_block (const gbind *g) 11826 Return the `TREE_BLOCK' node associated with `GIMPLE_BIND' 11827 statement `G'. This is analogous to the `BIND_EXPR_BLOCK' field in 11828 trees. 11829 11830 -- GIMPLE function: void gimple_bind_set_block (gbind *g, tree block) 11831 Set `BLOCK' to be the `TREE_BLOCK' node associated with 11832 `GIMPLE_BIND' statement `G'. 11833 11834 11835File: gccint.info, Node: `GIMPLE_CALL', Next: `GIMPLE_CATCH', Prev: `GIMPLE_BIND', Up: Tuple specific accessors 11836 1183711.8.4 `GIMPLE_CALL' 11838-------------------- 11839 11840 -- GIMPLE function: gcall *gimple_build_call (tree fn, unsigned nargs, 11841 ...) 11842 Build a `GIMPLE_CALL' statement to function `FN'. The argument 11843 `FN' must be either a `FUNCTION_DECL' or a gimple call address as 11844 determined by `is_gimple_call_addr'. `NARGS' are the number of 11845 arguments. The rest of the arguments follow the argument `NARGS', 11846 and must be trees that are valid as rvalues in gimple (i.e., each 11847 operand is validated with `is_gimple_operand'). 11848 11849 -- GIMPLE function: gcall *gimple_build_call_from_tree (tree call_expr) 11850 Build a `GIMPLE_CALL' from a `CALL_EXPR' node. The arguments and 11851 the function are taken from the expression directly. This routine 11852 assumes that `call_expr' is already in GIMPLE form. That is, its 11853 operands are GIMPLE values and the function call needs no further 11854 simplification. All the call flags in `call_expr' are copied over 11855 to the new `GIMPLE_CALL'. 11856 11857 -- GIMPLE function: gcall *gimple_build_call_vec (tree fn, `vec<tree>' 11858 args) 11859 Identical to `gimple_build_call' but the arguments are stored in a 11860 `vec<tree>'. 11861 11862 -- GIMPLE function: tree gimple_call_lhs (gimple g) 11863 Return the `LHS' of call statement `G'. 11864 11865 -- GIMPLE function: tree * gimple_call_lhs_ptr (gimple g) 11866 Return a pointer to the `LHS' of call statement `G'. 11867 11868 -- GIMPLE function: void gimple_call_set_lhs (gimple g, tree lhs) 11869 Set `LHS' to be the `LHS' operand of call statement `G'. 11870 11871 -- GIMPLE function: tree gimple_call_fn (gimple g) 11872 Return the tree node representing the function called by call 11873 statement `G'. 11874 11875 -- GIMPLE function: void gimple_call_set_fn (gcall *g, tree fn) 11876 Set `FN' to be the function called by call statement `G'. This has 11877 to be a gimple value specifying the address of the called function. 11878 11879 -- GIMPLE function: tree gimple_call_fndecl (gimple g) 11880 If a given `GIMPLE_CALL''s callee is a `FUNCTION_DECL', return it. 11881 Otherwise return `NULL'. This function is analogous to 11882 `get_callee_fndecl' in `GENERIC'. 11883 11884 -- GIMPLE function: tree gimple_call_set_fndecl (gimple g, tree fndecl) 11885 Set the called function to `FNDECL'. 11886 11887 -- GIMPLE function: tree gimple_call_return_type (const gcall *g) 11888 Return the type returned by call statement `G'. 11889 11890 -- GIMPLE function: tree gimple_call_chain (gimple g) 11891 Return the static chain for call statement `G'. 11892 11893 -- GIMPLE function: void gimple_call_set_chain (gcall *g, tree chain) 11894 Set `CHAIN' to be the static chain for call statement `G'. 11895 11896 -- GIMPLE function: unsigned gimple_call_num_args (gimple g) 11897 Return the number of arguments used by call statement `G'. 11898 11899 -- GIMPLE function: tree gimple_call_arg (gimple g, unsigned index) 11900 Return the argument at position `INDEX' for call statement `G'. 11901 The first argument is 0. 11902 11903 -- GIMPLE function: tree * gimple_call_arg_ptr (gimple g, unsigned 11904 index) 11905 Return a pointer to the argument at position `INDEX' for call 11906 statement `G'. 11907 11908 -- GIMPLE function: void gimple_call_set_arg (gimple g, unsigned 11909 index, tree arg) 11910 Set `ARG' to be the argument at position `INDEX' for call statement 11911 `G'. 11912 11913 -- GIMPLE function: void gimple_call_set_tail (gcall *s) 11914 Mark call statement `S' as being a tail call (i.e., a call just 11915 before the exit of a function). These calls are candidate for tail 11916 call optimization. 11917 11918 -- GIMPLE function: bool gimple_call_tail_p (gcall *s) 11919 Return true if `GIMPLE_CALL' `S' is marked as a tail call. 11920 11921 -- GIMPLE function: bool gimple_call_noreturn_p (gimple s) 11922 Return true if `S' is a noreturn call. 11923 11924 -- GIMPLE function: gimple gimple_call_copy_skip_args (gcall *stmt, 11925 bitmap args_to_skip) 11926 Build a `GIMPLE_CALL' identical to `STMT' but skipping the 11927 arguments in the positions marked by the set `ARGS_TO_SKIP'. 11928 11929 11930File: gccint.info, Node: `GIMPLE_CATCH', Next: `GIMPLE_COND', Prev: `GIMPLE_CALL', Up: Tuple specific accessors 11931 1193211.8.5 `GIMPLE_CATCH' 11933--------------------- 11934 11935 -- GIMPLE function: gcatch *gimple_build_catch (tree types, gimple_seq 11936 handler) 11937 Build a `GIMPLE_CATCH' statement. `TYPES' are the tree types this 11938 catch handles. `HANDLER' is a sequence of statements with the code 11939 for the handler. 11940 11941 -- GIMPLE function: tree gimple_catch_types (const gcatch *g) 11942 Return the types handled by `GIMPLE_CATCH' statement `G'. 11943 11944 -- GIMPLE function: tree * gimple_catch_types_ptr (gcatch *g) 11945 Return a pointer to the types handled by `GIMPLE_CATCH' statement 11946 `G'. 11947 11948 -- GIMPLE function: gimple_seq gimple_catch_handler (gcatch *g) 11949 Return the GIMPLE sequence representing the body of the handler of 11950 `GIMPLE_CATCH' statement `G'. 11951 11952 -- GIMPLE function: void gimple_catch_set_types (gcatch *g, tree t) 11953 Set `T' to be the set of types handled by `GIMPLE_CATCH' `G'. 11954 11955 -- GIMPLE function: void gimple_catch_set_handler (gcatch *g, 11956 gimple_seq handler) 11957 Set `HANDLER' to be the body of `GIMPLE_CATCH' `G'. 11958 11959 11960File: gccint.info, Node: `GIMPLE_COND', Next: `GIMPLE_DEBUG', Prev: `GIMPLE_CATCH', Up: Tuple specific accessors 11961 1196211.8.6 `GIMPLE_COND' 11963-------------------- 11964 11965 -- GIMPLE function: gcond *gimple_build_cond ( enum tree_code 11966 pred_code, tree lhs, tree rhs, tree t_label, tree f_label) 11967 Build a `GIMPLE_COND' statement. `A' `GIMPLE_COND' statement 11968 compares `LHS' and `RHS' and if the condition in `PRED_CODE' is 11969 true, jump to the label in `t_label', otherwise jump to the label 11970 in `f_label'. `PRED_CODE' are relational operator tree codes like 11971 `EQ_EXPR', `LT_EXPR', `LE_EXPR', `NE_EXPR', etc. 11972 11973 -- GIMPLE function: gcond *gimple_build_cond_from_tree (tree cond, 11974 tree t_label, tree f_label) 11975 Build a `GIMPLE_COND' statement from the conditional expression 11976 tree `COND'. `T_LABEL' and `F_LABEL' are as in 11977 `gimple_build_cond'. 11978 11979 -- GIMPLE function: enum tree_code gimple_cond_code (gimple g) 11980 Return the code of the predicate computed by conditional statement 11981 `G'. 11982 11983 -- GIMPLE function: void gimple_cond_set_code (gcond *g, enum 11984 tree_code code) 11985 Set `CODE' to be the predicate code for the conditional statement 11986 `G'. 11987 11988 -- GIMPLE function: tree gimple_cond_lhs (gimple g) 11989 Return the `LHS' of the predicate computed by conditional statement 11990 `G'. 11991 11992 -- GIMPLE function: void gimple_cond_set_lhs (gcond *g, tree lhs) 11993 Set `LHS' to be the `LHS' operand of the predicate computed by 11994 conditional statement `G'. 11995 11996 -- GIMPLE function: tree gimple_cond_rhs (gimple g) 11997 Return the `RHS' operand of the predicate computed by conditional 11998 `G'. 11999 12000 -- GIMPLE function: void gimple_cond_set_rhs (gcond *g, tree rhs) 12001 Set `RHS' to be the `RHS' operand of the predicate computed by 12002 conditional statement `G'. 12003 12004 -- GIMPLE function: tree gimple_cond_true_label (const gcond *g) 12005 Return the label used by conditional statement `G' when its 12006 predicate evaluates to true. 12007 12008 -- GIMPLE function: void gimple_cond_set_true_label (gcond *g, tree 12009 label) 12010 Set `LABEL' to be the label used by conditional statement `G' when 12011 its predicate evaluates to true. 12012 12013 -- GIMPLE function: void gimple_cond_set_false_label (gcond *g, tree 12014 label) 12015 Set `LABEL' to be the label used by conditional statement `G' when 12016 its predicate evaluates to false. 12017 12018 -- GIMPLE function: tree gimple_cond_false_label (const gcond *g) 12019 Return the label used by conditional statement `G' when its 12020 predicate evaluates to false. 12021 12022 -- GIMPLE function: void gimple_cond_make_false (gcond *g) 12023 Set the conditional `COND_STMT' to be of the form 'if (1 == 0)'. 12024 12025 -- GIMPLE function: void gimple_cond_make_true (gcond *g) 12026 Set the conditional `COND_STMT' to be of the form 'if (1 == 1)'. 12027 12028 12029File: gccint.info, Node: `GIMPLE_DEBUG', Next: `GIMPLE_EH_FILTER', Prev: `GIMPLE_COND', Up: Tuple specific accessors 12030 1203111.8.7 `GIMPLE_DEBUG' 12032--------------------- 12033 12034 -- GIMPLE function: gdebug *gimple_build_debug_bind (tree var, tree 12035 value, gimple stmt) 12036 Build a `GIMPLE_DEBUG' statement with `GIMPLE_DEBUG_BIND' of 12037 `subcode'. The effect of this statement is to tell debug 12038 information generation machinery that the value of user variable 12039 `var' is given by `value' at that point, and to remain with that 12040 value until `var' runs out of scope, a dynamically-subsequent 12041 debug bind statement overrides the binding, or conflicting values 12042 reach a control flow merge point. Even if components of the 12043 `value' expression change afterwards, the variable is supposed to 12044 retain the same value, though not necessarily the same location. 12045 12046 It is expected that `var' be most often a tree for automatic user 12047 variables (`VAR_DECL' or `PARM_DECL') that satisfy the 12048 requirements for gimple registers, but it may also be a tree for a 12049 scalarized component of a user variable (`ARRAY_REF', 12050 `COMPONENT_REF'), or a debug temporary (`DEBUG_EXPR_DECL'). 12051 12052 As for `value', it can be an arbitrary tree expression, but it is 12053 recommended that it be in a suitable form for a gimple assignment 12054 `RHS'. It is not expected that user variables that could appear 12055 as `var' ever appear in `value', because in the latter we'd have 12056 their `SSA_NAME's instead, but even if they were not in SSA form, 12057 user variables appearing in `value' are to be regarded as part of 12058 the executable code space, whereas those in `var' are to be 12059 regarded as part of the source code space. There is no way to 12060 refer to the value bound to a user variable within a `value' 12061 expression. 12062 12063 If `value' is `GIMPLE_DEBUG_BIND_NOVALUE', debug information 12064 generation machinery is informed that the variable `var' is 12065 unbound, i.e., that its value is indeterminate, which sometimes 12066 means it is really unavailable, and other times that the compiler 12067 could not keep track of it. 12068 12069 Block and location information for the newly-created stmt are 12070 taken from `stmt', if given. 12071 12072 -- GIMPLE function: tree gimple_debug_bind_get_var (gimple stmt) 12073 Return the user variable VAR that is bound at `stmt'. 12074 12075 -- GIMPLE function: tree gimple_debug_bind_get_value (gimple stmt) 12076 Return the value expression that is bound to a user variable at 12077 `stmt'. 12078 12079 -- GIMPLE function: tree * gimple_debug_bind_get_value_ptr (gimple 12080 stmt) 12081 Return a pointer to the value expression that is bound to a user 12082 variable at `stmt'. 12083 12084 -- GIMPLE function: void gimple_debug_bind_set_var (gimple stmt, tree 12085 var) 12086 Modify the user variable bound at `stmt' to VAR. 12087 12088 -- GIMPLE function: void gimple_debug_bind_set_value (gimple stmt, 12089 tree var) 12090 Modify the value bound to the user variable bound at `stmt' to 12091 VALUE. 12092 12093 -- GIMPLE function: void gimple_debug_bind_reset_value (gimple stmt) 12094 Modify the value bound to the user variable bound at `stmt' so 12095 that the variable becomes unbound. 12096 12097 -- GIMPLE function: bool gimple_debug_bind_has_value_p (gimple stmt) 12098 Return `TRUE' if `stmt' binds a user variable to a value, and 12099 `FALSE' if it unbinds the variable. 12100 12101 12102File: gccint.info, Node: `GIMPLE_EH_FILTER', Next: `GIMPLE_LABEL', Prev: `GIMPLE_DEBUG', Up: Tuple specific accessors 12103 1210411.8.8 `GIMPLE_EH_FILTER' 12105------------------------- 12106 12107 -- GIMPLE function: geh_filter *gimple_build_eh_filter (tree types, 12108 gimple_seq failure) 12109 Build a `GIMPLE_EH_FILTER' statement. `TYPES' are the filter's 12110 types. `FAILURE' is a sequence with the filter's failure action. 12111 12112 -- GIMPLE function: tree gimple_eh_filter_types (gimple g) 12113 Return the types handled by `GIMPLE_EH_FILTER' statement `G'. 12114 12115 -- GIMPLE function: tree * gimple_eh_filter_types_ptr (gimple g) 12116 Return a pointer to the types handled by `GIMPLE_EH_FILTER' 12117 statement `G'. 12118 12119 -- GIMPLE function: gimple_seq gimple_eh_filter_failure (gimple g) 12120 Return the sequence of statement to execute when `GIMPLE_EH_FILTER' 12121 statement fails. 12122 12123 -- GIMPLE function: void gimple_eh_filter_set_types (geh_filter *g, 12124 tree types) 12125 Set `TYPES' to be the set of types handled by `GIMPLE_EH_FILTER' 12126 `G'. 12127 12128 -- GIMPLE function: void gimple_eh_filter_set_failure (geh_filter *g, 12129 gimple_seq failure) 12130 Set `FAILURE' to be the sequence of statements to execute on 12131 failure for `GIMPLE_EH_FILTER' `G'. 12132 12133 -- GIMPLE function: tree gimple_eh_must_not_throw_fndecl ( geh_mnt 12134 *eh_mnt_stmt) 12135 Get the function decl to be called by the MUST_NOT_THROW region. 12136 12137 -- GIMPLE function: void gimple_eh_must_not_throw_set_fndecl ( geh_mnt 12138 *eh_mnt_stmt, tree decl) 12139 Set the function decl to be called by GS to DECL. 12140 12141 12142File: gccint.info, Node: `GIMPLE_LABEL', Next: `GIMPLE_GOTO', Prev: `GIMPLE_EH_FILTER', Up: Tuple specific accessors 12143 1214411.8.9 `GIMPLE_LABEL' 12145--------------------- 12146 12147 -- GIMPLE function: glabel *gimple_build_label (tree label) 12148 Build a `GIMPLE_LABEL' statement with corresponding to the tree 12149 label, `LABEL'. 12150 12151 -- GIMPLE function: tree gimple_label_label (const glabel *g) 12152 Return the `LABEL_DECL' node used by `GIMPLE_LABEL' statement `G'. 12153 12154 -- GIMPLE function: void gimple_label_set_label (glabel *g, tree label) 12155 Set `LABEL' to be the `LABEL_DECL' node used by `GIMPLE_LABEL' 12156 statement `G'. 12157 12158 12159File: gccint.info, Node: `GIMPLE_GOTO', Next: `GIMPLE_NOP', Prev: `GIMPLE_LABEL', Up: Tuple specific accessors 12160 1216111.8.10 `GIMPLE_GOTO' 12162--------------------- 12163 12164 -- GIMPLE function: ggoto *gimple_build_goto (tree dest) 12165 Build a `GIMPLE_GOTO' statement to label `DEST'. 12166 12167 -- GIMPLE function: tree gimple_goto_dest (gimple g) 12168 Return the destination of the unconditional jump `G'. 12169 12170 -- GIMPLE function: void gimple_goto_set_dest (ggoto *g, tree dest) 12171 Set `DEST' to be the destination of the unconditional jump `G'. 12172 12173 12174File: gccint.info, Node: `GIMPLE_NOP', Next: `GIMPLE_OMP_ATOMIC_LOAD', Prev: `GIMPLE_GOTO', Up: Tuple specific accessors 12175 1217611.8.11 `GIMPLE_NOP' 12177-------------------- 12178 12179 -- GIMPLE function: gimple gimple_build_nop (void) 12180 Build a `GIMPLE_NOP' statement. 12181 12182 -- GIMPLE function: bool gimple_nop_p (gimple g) 12183 Returns `TRUE' if statement `G' is a `GIMPLE_NOP'. 12184 12185 12186File: gccint.info, Node: `GIMPLE_OMP_ATOMIC_LOAD', Next: `GIMPLE_OMP_ATOMIC_STORE', Prev: `GIMPLE_NOP', Up: Tuple specific accessors 12187 1218811.8.12 `GIMPLE_OMP_ATOMIC_LOAD' 12189-------------------------------- 12190 12191 -- GIMPLE function: gomp_atomic_load *gimple_build_omp_atomic_load ( 12192 tree lhs, tree rhs) 12193 Build a `GIMPLE_OMP_ATOMIC_LOAD' statement. `LHS' is the left-hand 12194 side of the assignment. `RHS' is the right-hand side of the 12195 assignment. 12196 12197 -- GIMPLE function: void gimple_omp_atomic_load_set_lhs ( 12198 gomp_atomic_load *g, tree lhs) 12199 Set the `LHS' of an atomic load. 12200 12201 -- GIMPLE function: tree gimple_omp_atomic_load_lhs ( const 12202 gomp_atomic_load *g) 12203 Get the `LHS' of an atomic load. 12204 12205 -- GIMPLE function: void gimple_omp_atomic_load_set_rhs ( 12206 gomp_atomic_load *g, tree rhs) 12207 Set the `RHS' of an atomic set. 12208 12209 -- GIMPLE function: tree gimple_omp_atomic_load_rhs ( const 12210 gomp_atomic_load *g) 12211 Get the `RHS' of an atomic set. 12212 12213 12214File: gccint.info, Node: `GIMPLE_OMP_ATOMIC_STORE', Next: `GIMPLE_OMP_CONTINUE', Prev: `GIMPLE_OMP_ATOMIC_LOAD', Up: Tuple specific accessors 12215 1221611.8.13 `GIMPLE_OMP_ATOMIC_STORE' 12217--------------------------------- 12218 12219 -- GIMPLE function: gomp_atomic_store *gimple_build_omp_atomic_store ( 12220 tree val) 12221 Build a `GIMPLE_OMP_ATOMIC_STORE' statement. `VAL' is the value to 12222 be stored. 12223 12224 -- GIMPLE function: void gimple_omp_atomic_store_set_val ( 12225 gomp_atomic_store *g, tree val) 12226 Set the value being stored in an atomic store. 12227 12228 -- GIMPLE function: tree gimple_omp_atomic_store_val ( const 12229 gomp_atomic_store *g) 12230 Return the value being stored in an atomic store. 12231 12232 12233File: gccint.info, Node: `GIMPLE_OMP_CONTINUE', Next: `GIMPLE_OMP_CRITICAL', Prev: `GIMPLE_OMP_ATOMIC_STORE', Up: Tuple specific accessors 12234 1223511.8.14 `GIMPLE_OMP_CONTINUE' 12236----------------------------- 12237 12238 -- GIMPLE function: gomp_continue *gimple_build_omp_continue ( tree 12239 control_def, tree control_use) 12240 Build a `GIMPLE_OMP_CONTINUE' statement. `CONTROL_DEF' is the 12241 definition of the control variable. `CONTROL_USE' is the use of 12242 the control variable. 12243 12244 -- GIMPLE function: tree gimple_omp_continue_control_def ( const 12245 gomp_continue *s) 12246 Return the definition of the control variable on a 12247 `GIMPLE_OMP_CONTINUE' in `S'. 12248 12249 -- GIMPLE function: tree gimple_omp_continue_control_def_ptr ( 12250 gomp_continue *s) 12251 Same as above, but return the pointer. 12252 12253 -- GIMPLE function: tree gimple_omp_continue_set_control_def ( 12254 gomp_continue *s) 12255 Set the control variable definition for a `GIMPLE_OMP_CONTINUE' 12256 statement in `S'. 12257 12258 -- GIMPLE function: tree gimple_omp_continue_control_use ( const 12259 gomp_continue *s) 12260 Return the use of the control variable on a `GIMPLE_OMP_CONTINUE' 12261 in `S'. 12262 12263 -- GIMPLE function: tree gimple_omp_continue_control_use_ptr ( 12264 gomp_continue *s) 12265 Same as above, but return the pointer. 12266 12267 -- GIMPLE function: tree gimple_omp_continue_set_control_use ( 12268 gomp_continue *s) 12269 Set the control variable use for a `GIMPLE_OMP_CONTINUE' statement 12270 in `S'. 12271 12272 12273File: gccint.info, Node: `GIMPLE_OMP_CRITICAL', Next: `GIMPLE_OMP_FOR', Prev: `GIMPLE_OMP_CONTINUE', Up: Tuple specific accessors 12274 1227511.8.15 `GIMPLE_OMP_CRITICAL' 12276----------------------------- 12277 12278 -- GIMPLE function: gomp_critical *gimple_build_omp_critical ( 12279 gimple_seq body, tree name) 12280 Build a `GIMPLE_OMP_CRITICAL' statement. `BODY' is the sequence of 12281 statements for which only one thread can execute. `NAME' is an 12282 optional identifier for this critical block. 12283 12284 -- GIMPLE function: tree gimple_omp_critical_name ( const 12285 gomp_critical *g) 12286 Return the name associated with `OMP_CRITICAL' statement `G'. 12287 12288 -- GIMPLE function: tree * gimple_omp_critical_name_ptr ( 12289 gomp_critical *g) 12290 Return a pointer to the name associated with `OMP' critical 12291 statement `G'. 12292 12293 -- GIMPLE function: void gimple_omp_critical_set_name ( gomp_critical 12294 *g, tree name) 12295 Set `NAME' to be the name associated with `OMP' critical statement 12296 `G'. 12297 12298 12299File: gccint.info, Node: `GIMPLE_OMP_FOR', Next: `GIMPLE_OMP_MASTER', Prev: `GIMPLE_OMP_CRITICAL', Up: Tuple specific accessors 12300 1230111.8.16 `GIMPLE_OMP_FOR' 12302------------------------ 12303 12304 -- GIMPLE function: gomp_for *gimple_build_omp_for (gimple_seq body, 12305 tree clauses, tree index, tree initial, tree final, tree 12306 incr, gimple_seq pre_body, enum tree_code omp_for_cond) 12307 Build a `GIMPLE_OMP_FOR' statement. `BODY' is sequence of 12308 statements inside the for loop. `CLAUSES', are any of the loop 12309 construct's clauses. `PRE_BODY' is the sequence of statements 12310 that are loop invariant. `INDEX' is the index variable. 12311 `INITIAL' is the initial value of `INDEX'. `FINAL' is final value 12312 of `INDEX'. OMP_FOR_COND is the predicate used to compare `INDEX' 12313 and `FINAL'. `INCR' is the increment expression. 12314 12315 -- GIMPLE function: tree gimple_omp_for_clauses (gimple g) 12316 Return the clauses associated with `OMP_FOR' `G'. 12317 12318 -- GIMPLE function: tree * gimple_omp_for_clauses_ptr (gimple g) 12319 Return a pointer to the `OMP_FOR' `G'. 12320 12321 -- GIMPLE function: void gimple_omp_for_set_clauses (gimple g, tree 12322 clauses) 12323 Set `CLAUSES' to be the list of clauses associated with `OMP_FOR' 12324 `G'. 12325 12326 -- GIMPLE function: tree gimple_omp_for_index (gimple g) 12327 Return the index variable for `OMP_FOR' `G'. 12328 12329 -- GIMPLE function: tree * gimple_omp_for_index_ptr (gimple g) 12330 Return a pointer to the index variable for `OMP_FOR' `G'. 12331 12332 -- GIMPLE function: void gimple_omp_for_set_index (gimple g, tree 12333 index) 12334 Set `INDEX' to be the index variable for `OMP_FOR' `G'. 12335 12336 -- GIMPLE function: tree gimple_omp_for_initial (gimple g) 12337 Return the initial value for `OMP_FOR' `G'. 12338 12339 -- GIMPLE function: tree * gimple_omp_for_initial_ptr (gimple g) 12340 Return a pointer to the initial value for `OMP_FOR' `G'. 12341 12342 -- GIMPLE function: void gimple_omp_for_set_initial (gimple g, tree 12343 initial) 12344 Set `INITIAL' to be the initial value for `OMP_FOR' `G'. 12345 12346 -- GIMPLE function: tree gimple_omp_for_final (gimple g) 12347 Return the final value for `OMP_FOR' `G'. 12348 12349 -- GIMPLE function: tree * gimple_omp_for_final_ptr (gimple g) 12350 turn a pointer to the final value for `OMP_FOR' `G'. 12351 12352 -- GIMPLE function: void gimple_omp_for_set_final (gimple g, tree 12353 final) 12354 Set `FINAL' to be the final value for `OMP_FOR' `G'. 12355 12356 -- GIMPLE function: tree gimple_omp_for_incr (gimple g) 12357 Return the increment value for `OMP_FOR' `G'. 12358 12359 -- GIMPLE function: tree * gimple_omp_for_incr_ptr (gimple g) 12360 Return a pointer to the increment value for `OMP_FOR' `G'. 12361 12362 -- GIMPLE function: void gimple_omp_for_set_incr (gimple g, tree incr) 12363 Set `INCR' to be the increment value for `OMP_FOR' `G'. 12364 12365 -- GIMPLE function: gimple_seq gimple_omp_for_pre_body (gimple g) 12366 Return the sequence of statements to execute before the `OMP_FOR' 12367 statement `G' starts. 12368 12369 -- GIMPLE function: void gimple_omp_for_set_pre_body (gimple g, 12370 gimple_seq pre_body) 12371 Set `PRE_BODY' to be the sequence of statements to execute before 12372 the `OMP_FOR' statement `G' starts. 12373 12374 -- GIMPLE function: void gimple_omp_for_set_cond (gimple g, enum 12375 tree_code cond) 12376 Set `COND' to be the condition code for `OMP_FOR' `G'. 12377 12378 -- GIMPLE function: enum tree_code gimple_omp_for_cond (gimple g) 12379 Return the condition code associated with `OMP_FOR' `G'. 12380 12381 12382File: gccint.info, Node: `GIMPLE_OMP_MASTER', Next: `GIMPLE_OMP_ORDERED', Prev: `GIMPLE_OMP_FOR', Up: Tuple specific accessors 12383 1238411.8.17 `GIMPLE_OMP_MASTER' 12385--------------------------- 12386 12387 -- GIMPLE function: gimple gimple_build_omp_master (gimple_seq body) 12388 Build a `GIMPLE_OMP_MASTER' statement. `BODY' is the sequence of 12389 statements to be executed by just the master. 12390 12391 12392File: gccint.info, Node: `GIMPLE_OMP_ORDERED', Next: `GIMPLE_OMP_PARALLEL', Prev: `GIMPLE_OMP_MASTER', Up: Tuple specific accessors 12393 1239411.8.18 `GIMPLE_OMP_ORDERED' 12395---------------------------- 12396 12397 -- GIMPLE function: gimple gimple_build_omp_ordered (gimple_seq body) 12398 Build a `GIMPLE_OMP_ORDERED' statement. 12399 12400 `BODY' is the sequence of statements inside a loop that will executed 12401in sequence. 12402 12403 12404File: gccint.info, Node: `GIMPLE_OMP_PARALLEL', Next: `GIMPLE_OMP_RETURN', Prev: `GIMPLE_OMP_ORDERED', Up: Tuple specific accessors 12405 1240611.8.19 `GIMPLE_OMP_PARALLEL' 12407----------------------------- 12408 12409 -- GIMPLE function: gomp_parallel *gimple_build_omp_parallel ( 12410 gimple_seq body, tree clauses, tree child_fn, tree data_arg) 12411 Build a `GIMPLE_OMP_PARALLEL' statement. 12412 12413 `BODY' is sequence of statements which are executed in parallel. 12414`CLAUSES', are the `OMP' parallel construct's clauses. `CHILD_FN' is 12415the function created for the parallel threads to execute. `DATA_ARG' 12416are the shared data argument(s). 12417 12418 -- GIMPLE function: bool gimple_omp_parallel_combined_p (gimple g) 12419 Return true if `OMP' parallel statement `G' has the 12420 `GF_OMP_PARALLEL_COMBINED' flag set. 12421 12422 -- GIMPLE function: void gimple_omp_parallel_set_combined_p (gimple g) 12423 Set the `GF_OMP_PARALLEL_COMBINED' field in `OMP' parallel 12424 statement `G'. 12425 12426 -- GIMPLE function: gimple_seq gimple_omp_body (gimple g) 12427 Return the body for the `OMP' statement `G'. 12428 12429 -- GIMPLE function: void gimple_omp_set_body (gimple g, gimple_seq 12430 body) 12431 Set `BODY' to be the body for the `OMP' statement `G'. 12432 12433 -- GIMPLE function: tree gimple_omp_parallel_clauses (gimple g) 12434 Return the clauses associated with `OMP_PARALLEL' `G'. 12435 12436 -- GIMPLE function: tree * gimple_omp_parallel_clauses_ptr ( 12437 gomp_parallel *g) 12438 Return a pointer to the clauses associated with `OMP_PARALLEL' `G'. 12439 12440 -- GIMPLE function: void gimple_omp_parallel_set_clauses ( 12441 gomp_parallel *g, tree clauses) 12442 Set `CLAUSES' to be the list of clauses associated with 12443 `OMP_PARALLEL' `G'. 12444 12445 -- GIMPLE function: tree gimple_omp_parallel_child_fn ( const 12446 gomp_parallel *g) 12447 Return the child function used to hold the body of `OMP_PARALLEL' 12448 `G'. 12449 12450 -- GIMPLE function: tree * gimple_omp_parallel_child_fn_ptr ( 12451 gomp_parallel *g) 12452 Return a pointer to the child function used to hold the body of 12453 `OMP_PARALLEL' `G'. 12454 12455 -- GIMPLE function: void gimple_omp_parallel_set_child_fn ( 12456 gomp_parallel *g, tree child_fn) 12457 Set `CHILD_FN' to be the child function for `OMP_PARALLEL' `G'. 12458 12459 -- GIMPLE function: tree gimple_omp_parallel_data_arg ( const 12460 gomp_parallel *g) 12461 Return the artificial argument used to send variables and values 12462 from the parent to the children threads in `OMP_PARALLEL' `G'. 12463 12464 -- GIMPLE function: tree * gimple_omp_parallel_data_arg_ptr ( 12465 gomp_parallel *g) 12466 Return a pointer to the data argument for `OMP_PARALLEL' `G'. 12467 12468 -- GIMPLE function: void gimple_omp_parallel_set_data_arg ( 12469 gomp_parallel *g, tree data_arg) 12470 Set `DATA_ARG' to be the data argument for `OMP_PARALLEL' `G'. 12471 12472 12473File: gccint.info, Node: `GIMPLE_OMP_RETURN', Next: `GIMPLE_OMP_SECTION', Prev: `GIMPLE_OMP_PARALLEL', Up: Tuple specific accessors 12474 1247511.8.20 `GIMPLE_OMP_RETURN' 12476--------------------------- 12477 12478 -- GIMPLE function: gimple gimple_build_omp_return (bool wait_p) 12479 Build a `GIMPLE_OMP_RETURN' statement. `WAIT_P' is true if this is 12480 a non-waiting return. 12481 12482 -- GIMPLE function: void gimple_omp_return_set_nowait (gimple s) 12483 Set the nowait flag on `GIMPLE_OMP_RETURN' statement `S'. 12484 12485 -- GIMPLE function: bool gimple_omp_return_nowait_p (gimple g) 12486 Return true if `OMP' return statement `G' has the 12487 `GF_OMP_RETURN_NOWAIT' flag set. 12488 12489 12490File: gccint.info, Node: `GIMPLE_OMP_SECTION', Next: `GIMPLE_OMP_SECTIONS', Prev: `GIMPLE_OMP_RETURN', Up: Tuple specific accessors 12491 1249211.8.21 `GIMPLE_OMP_SECTION' 12493---------------------------- 12494 12495 -- GIMPLE function: gimple gimple_build_omp_section (gimple_seq body) 12496 Build a `GIMPLE_OMP_SECTION' statement for a sections statement. 12497 12498 `BODY' is the sequence of statements in the section. 12499 12500 -- GIMPLE function: bool gimple_omp_section_last_p (gimple g) 12501 Return true if `OMP' section statement `G' has the 12502 `GF_OMP_SECTION_LAST' flag set. 12503 12504 -- GIMPLE function: void gimple_omp_section_set_last (gimple g) 12505 Set the `GF_OMP_SECTION_LAST' flag on `G'. 12506 12507 12508File: gccint.info, Node: `GIMPLE_OMP_SECTIONS', Next: `GIMPLE_OMP_SINGLE', Prev: `GIMPLE_OMP_SECTION', Up: Tuple specific accessors 12509 1251011.8.22 `GIMPLE_OMP_SECTIONS' 12511----------------------------- 12512 12513 -- GIMPLE function: gomp_sections *gimple_build_omp_sections ( 12514 gimple_seq body, tree clauses) 12515 Build a `GIMPLE_OMP_SECTIONS' statement. `BODY' is a sequence of 12516 section statements. `CLAUSES' are any of the `OMP' sections 12517 construct's clauses: private, firstprivate, lastprivate, 12518 reduction, and nowait. 12519 12520 -- GIMPLE function: gimple gimple_build_omp_sections_switch (void) 12521 Build a `GIMPLE_OMP_SECTIONS_SWITCH' statement. 12522 12523 -- GIMPLE function: tree gimple_omp_sections_control (gimple g) 12524 Return the control variable associated with the 12525 `GIMPLE_OMP_SECTIONS' in `G'. 12526 12527 -- GIMPLE function: tree * gimple_omp_sections_control_ptr (gimple g) 12528 Return a pointer to the clauses associated with the 12529 `GIMPLE_OMP_SECTIONS' in `G'. 12530 12531 -- GIMPLE function: void gimple_omp_sections_set_control (gimple g, 12532 tree control) 12533 Set `CONTROL' to be the set of clauses associated with the 12534 `GIMPLE_OMP_SECTIONS' in `G'. 12535 12536 -- GIMPLE function: tree gimple_omp_sections_clauses (gimple g) 12537 Return the clauses associated with `OMP_SECTIONS' `G'. 12538 12539 -- GIMPLE function: tree * gimple_omp_sections_clauses_ptr (gimple g) 12540 Return a pointer to the clauses associated with `OMP_SECTIONS' `G'. 12541 12542 -- GIMPLE function: void gimple_omp_sections_set_clauses (gimple g, 12543 tree clauses) 12544 Set `CLAUSES' to be the set of clauses associated with 12545 `OMP_SECTIONS' `G'. 12546 12547 12548File: gccint.info, Node: `GIMPLE_OMP_SINGLE', Next: `GIMPLE_PHI', Prev: `GIMPLE_OMP_SECTIONS', Up: Tuple specific accessors 12549 1255011.8.23 `GIMPLE_OMP_SINGLE' 12551--------------------------- 12552 12553 -- GIMPLE function: gomp_single *gimple_build_omp_single ( gimple_seq 12554 body, tree clauses) 12555 Build a `GIMPLE_OMP_SINGLE' statement. `BODY' is the sequence of 12556 statements that will be executed once. `CLAUSES' are any of the 12557 `OMP' single construct's clauses: private, firstprivate, 12558 copyprivate, nowait. 12559 12560 -- GIMPLE function: tree gimple_omp_single_clauses (gimple g) 12561 Return the clauses associated with `OMP_SINGLE' `G'. 12562 12563 -- GIMPLE function: tree * gimple_omp_single_clauses_ptr (gimple g) 12564 Return a pointer to the clauses associated with `OMP_SINGLE' `G'. 12565 12566 -- GIMPLE function: void gimple_omp_single_set_clauses ( gomp_single 12567 *g, tree clauses) 12568 Set `CLAUSES' to be the clauses associated with `OMP_SINGLE' `G'. 12569 12570 12571File: gccint.info, Node: `GIMPLE_PHI', Next: `GIMPLE_RESX', Prev: `GIMPLE_OMP_SINGLE', Up: Tuple specific accessors 12572 1257311.8.24 `GIMPLE_PHI' 12574-------------------- 12575 12576 -- GIMPLE function: unsigned gimple_phi_capacity (gimple g) 12577 Return the maximum number of arguments supported by `GIMPLE_PHI' 12578 `G'. 12579 12580 -- GIMPLE function: unsigned gimple_phi_num_args (gimple g) 12581 Return the number of arguments in `GIMPLE_PHI' `G'. This must 12582 always be exactly the number of incoming edges for the basic block 12583 holding `G'. 12584 12585 -- GIMPLE function: tree gimple_phi_result (gimple g) 12586 Return the `SSA' name created by `GIMPLE_PHI' `G'. 12587 12588 -- GIMPLE function: tree * gimple_phi_result_ptr (gimple g) 12589 Return a pointer to the `SSA' name created by `GIMPLE_PHI' `G'. 12590 12591 -- GIMPLE function: void gimple_phi_set_result (gphi *g, tree result) 12592 Set `RESULT' to be the `SSA' name created by `GIMPLE_PHI' `G'. 12593 12594 -- GIMPLE function: struct phi_arg_d * gimple_phi_arg (gimple g, index) 12595 Return the `PHI' argument corresponding to incoming edge `INDEX' 12596 for `GIMPLE_PHI' `G'. 12597 12598 -- GIMPLE function: void gimple_phi_set_arg (gphi *g, index, struct 12599 phi_arg_d * phiarg) 12600 Set `PHIARG' to be the argument corresponding to incoming edge 12601 `INDEX' for `GIMPLE_PHI' `G'. 12602 12603 12604File: gccint.info, Node: `GIMPLE_RESX', Next: `GIMPLE_RETURN', Prev: `GIMPLE_PHI', Up: Tuple specific accessors 12605 1260611.8.25 `GIMPLE_RESX' 12607--------------------- 12608 12609 -- GIMPLE function: gresx *gimple_build_resx (int region) 12610 Build a `GIMPLE_RESX' statement which is a statement. This 12611 statement is a placeholder for _Unwind_Resume before we know if a 12612 function call or a branch is needed. `REGION' is the exception 12613 region from which control is flowing. 12614 12615 -- GIMPLE function: int gimple_resx_region (const gresx *g) 12616 Return the region number for `GIMPLE_RESX' `G'. 12617 12618 -- GIMPLE function: void gimple_resx_set_region (gresx *g, int region) 12619 Set `REGION' to be the region number for `GIMPLE_RESX' `G'. 12620 12621 12622File: gccint.info, Node: `GIMPLE_RETURN', Next: `GIMPLE_SWITCH', Prev: `GIMPLE_RESX', Up: Tuple specific accessors 12623 1262411.8.26 `GIMPLE_RETURN' 12625----------------------- 12626 12627 -- GIMPLE function: greturn *gimple_build_return (tree retval) 12628 Build a `GIMPLE_RETURN' statement whose return value is retval. 12629 12630 -- GIMPLE function: tree gimple_return_retval (const greturn *g) 12631 Return the return value for `GIMPLE_RETURN' `G'. 12632 12633 -- GIMPLE function: void gimple_return_set_retval (greturn *g, tree 12634 retval) 12635 Set `RETVAL' to be the return value for `GIMPLE_RETURN' `G'. 12636 12637 12638File: gccint.info, Node: `GIMPLE_SWITCH', Next: `GIMPLE_TRY', Prev: `GIMPLE_RETURN', Up: Tuple specific accessors 12639 1264011.8.27 `GIMPLE_SWITCH' 12641----------------------- 12642 12643 -- GIMPLE function: gswitch *gimple_build_switch (tree index, tree 12644 default_label, `vec'<tree> *args) 12645 Build a `GIMPLE_SWITCH' statement. `INDEX' is the index variable 12646 to switch on, and `DEFAULT_LABEL' represents the default label. 12647 `ARGS' is a vector of `CASE_LABEL_EXPR' trees that contain the 12648 non-default case labels. Each label is a tree of code 12649 `CASE_LABEL_EXPR'. 12650 12651 -- GIMPLE function: unsigned gimple_switch_num_labels ( const gswitch 12652 *g) 12653 Return the number of labels associated with the switch statement 12654 `G'. 12655 12656 -- GIMPLE function: void gimple_switch_set_num_labels (gswitch *g, 12657 unsigned nlabels) 12658 Set `NLABELS' to be the number of labels for the switch statement 12659 `G'. 12660 12661 -- GIMPLE function: tree gimple_switch_index (const gswitch *g) 12662 Return the index variable used by the switch statement `G'. 12663 12664 -- GIMPLE function: void gimple_switch_set_index (gswitch *g, tree 12665 index) 12666 Set `INDEX' to be the index variable for switch statement `G'. 12667 12668 -- GIMPLE function: tree gimple_switch_label (const gswitch *g, 12669 unsigned index) 12670 Return the label numbered `INDEX'. The default label is 0, followed 12671 by any labels in a switch statement. 12672 12673 -- GIMPLE function: void gimple_switch_set_label (gswitch *g, unsigned 12674 index, tree label) 12675 Set the label number `INDEX' to `LABEL'. 0 is always the default 12676 label. 12677 12678 -- GIMPLE function: tree gimple_switch_default_label ( const gswitch 12679 *g) 12680 Return the default label for a switch statement. 12681 12682 -- GIMPLE function: void gimple_switch_set_default_label (gswitch *g, 12683 tree label) 12684 Set the default label for a switch statement. 12685 12686 12687File: gccint.info, Node: `GIMPLE_TRY', Next: `GIMPLE_WITH_CLEANUP_EXPR', Prev: `GIMPLE_SWITCH', Up: Tuple specific accessors 12688 1268911.8.28 `GIMPLE_TRY' 12690-------------------- 12691 12692 -- GIMPLE function: gtry *gimple_build_try (gimple_seq eval, 12693 gimple_seq cleanup, unsigned int kind) 12694 Build a `GIMPLE_TRY' statement. `EVAL' is a sequence with the 12695 expression to evaluate. `CLEANUP' is a sequence of statements to 12696 run at clean-up time. `KIND' is the enumeration value 12697 `GIMPLE_TRY_CATCH' if this statement denotes a try/catch construct 12698 or `GIMPLE_TRY_FINALLY' if this statement denotes a try/finally 12699 construct. 12700 12701 -- GIMPLE function: enum gimple_try_flags gimple_try_kind (gimple g) 12702 Return the kind of try block represented by `GIMPLE_TRY' `G'. This 12703 is either `GIMPLE_TRY_CATCH' or `GIMPLE_TRY_FINALLY'. 12704 12705 -- GIMPLE function: bool gimple_try_catch_is_cleanup (gimple g) 12706 Return the `GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 12707 12708 -- GIMPLE function: gimple_seq gimple_try_eval (gimple g) 12709 Return the sequence of statements used as the body for `GIMPLE_TRY' 12710 `G'. 12711 12712 -- GIMPLE function: gimple_seq gimple_try_cleanup (gimple g) 12713 Return the sequence of statements used as the cleanup body for 12714 `GIMPLE_TRY' `G'. 12715 12716 -- GIMPLE function: void gimple_try_set_catch_is_cleanup (gimple g, 12717 bool catch_is_cleanup) 12718 Set the `GIMPLE_TRY_CATCH_IS_CLEANUP' flag. 12719 12720 -- GIMPLE function: void gimple_try_set_eval (gtry *g, gimple_seq eval) 12721 Set `EVAL' to be the sequence of statements to use as the body for 12722 `GIMPLE_TRY' `G'. 12723 12724 -- GIMPLE function: void gimple_try_set_cleanup (gtry *g, gimple_seq 12725 cleanup) 12726 Set `CLEANUP' to be the sequence of statements to use as the 12727 cleanup body for `GIMPLE_TRY' `G'. 12728 12729 12730File: gccint.info, Node: `GIMPLE_WITH_CLEANUP_EXPR', Prev: `GIMPLE_TRY', Up: Tuple specific accessors 12731 1273211.8.29 `GIMPLE_WITH_CLEANUP_EXPR' 12733---------------------------------- 12734 12735 -- GIMPLE function: gimple gimple_build_wce (gimple_seq cleanup) 12736 Build a `GIMPLE_WITH_CLEANUP_EXPR' statement. `CLEANUP' is the 12737 clean-up expression. 12738 12739 -- GIMPLE function: gimple_seq gimple_wce_cleanup (gimple g) 12740 Return the cleanup sequence for cleanup statement `G'. 12741 12742 -- GIMPLE function: void gimple_wce_set_cleanup (gimple g, gimple_seq 12743 cleanup) 12744 Set `CLEANUP' to be the cleanup sequence for `G'. 12745 12746 -- GIMPLE function: bool gimple_wce_cleanup_eh_only (gimple g) 12747 Return the `CLEANUP_EH_ONLY' flag for a `WCE' tuple. 12748 12749 -- GIMPLE function: void gimple_wce_set_cleanup_eh_only (gimple g, 12750 bool eh_only_p) 12751 Set the `CLEANUP_EH_ONLY' flag for a `WCE' tuple. 12752 12753 12754File: gccint.info, Node: GIMPLE sequences, Next: Sequence iterators, Prev: Tuple specific accessors, Up: GIMPLE 12755 1275611.9 GIMPLE sequences 12757===================== 12758 12759GIMPLE sequences are the tuple equivalent of `STATEMENT_LIST''s used in 12760`GENERIC'. They are used to chain statements together, and when used 12761in conjunction with sequence iterators, provide a framework for 12762iterating through statements. 12763 12764 GIMPLE sequences are of type struct `gimple_sequence', but are more 12765commonly passed by reference to functions dealing with sequences. The 12766type for a sequence pointer is `gimple_seq' which is the same as struct 12767`gimple_sequence' *. When declaring a local sequence, you can define a 12768local variable of type struct `gimple_sequence'. When declaring a 12769sequence allocated on the garbage collected heap, use the function 12770`gimple_seq_alloc' documented below. 12771 12772 There are convenience functions for iterating through sequences in the 12773section entitled Sequence Iterators. 12774 12775 Below is a list of functions to manipulate and query sequences. 12776 12777 -- GIMPLE function: void gimple_seq_add_stmt (gimple_seq *seq, gimple 12778 g) 12779 Link a gimple statement to the end of the sequence *`SEQ' if `G' is 12780 not `NULL'. If *`SEQ' is `NULL', allocate a sequence before 12781 linking. 12782 12783 -- GIMPLE function: void gimple_seq_add_seq (gimple_seq *dest, 12784 gimple_seq src) 12785 Append sequence `SRC' to the end of sequence *`DEST' if `SRC' is 12786 not `NULL'. If *`DEST' is `NULL', allocate a new sequence before 12787 appending. 12788 12789 -- GIMPLE function: gimple_seq gimple_seq_deep_copy (gimple_seq src) 12790 Perform a deep copy of sequence `SRC' and return the result. 12791 12792 -- GIMPLE function: gimple_seq gimple_seq_reverse (gimple_seq seq) 12793 Reverse the order of the statements in the sequence `SEQ'. Return 12794 `SEQ'. 12795 12796 -- GIMPLE function: gimple gimple_seq_first (gimple_seq s) 12797 Return the first statement in sequence `S'. 12798 12799 -- GIMPLE function: gimple gimple_seq_last (gimple_seq s) 12800 Return the last statement in sequence `S'. 12801 12802 -- GIMPLE function: void gimple_seq_set_last (gimple_seq s, gimple 12803 last) 12804 Set the last statement in sequence `S' to the statement in `LAST'. 12805 12806 -- GIMPLE function: void gimple_seq_set_first (gimple_seq s, gimple 12807 first) 12808 Set the first statement in sequence `S' to the statement in 12809 `FIRST'. 12810 12811 -- GIMPLE function: void gimple_seq_init (gimple_seq s) 12812 Initialize sequence `S' to an empty sequence. 12813 12814 -- GIMPLE function: gimple_seq gimple_seq_alloc (void) 12815 Allocate a new sequence in the garbage collected store and return 12816 it. 12817 12818 -- GIMPLE function: void gimple_seq_copy (gimple_seq dest, gimple_seq 12819 src) 12820 Copy the sequence `SRC' into the sequence `DEST'. 12821 12822 -- GIMPLE function: bool gimple_seq_empty_p (gimple_seq s) 12823 Return true if the sequence `S' is empty. 12824 12825 -- GIMPLE function: gimple_seq bb_seq (basic_block bb) 12826 Returns the sequence of statements in `BB'. 12827 12828 -- GIMPLE function: void set_bb_seq (basic_block bb, gimple_seq seq) 12829 Sets the sequence of statements in `BB' to `SEQ'. 12830 12831 -- GIMPLE function: bool gimple_seq_singleton_p (gimple_seq seq) 12832 Determine whether `SEQ' contains exactly one statement. 12833 12834 12835File: gccint.info, Node: Sequence iterators, Next: Adding a new GIMPLE statement code, Prev: GIMPLE sequences, Up: GIMPLE 12836 1283711.10 Sequence iterators 12838======================== 12839 12840Sequence iterators are convenience constructs for iterating through 12841statements in a sequence. Given a sequence `SEQ', here is a typical 12842use of gimple sequence iterators: 12843 12844 gimple_stmt_iterator gsi; 12845 12846 for (gsi = gsi_start (seq); !gsi_end_p (gsi); gsi_next (&gsi)) 12847 { 12848 gimple g = gsi_stmt (gsi); 12849 /* Do something with gimple statement `G'. */ 12850 } 12851 12852 Backward iterations are possible: 12853 12854 for (gsi = gsi_last (seq); !gsi_end_p (gsi); gsi_prev (&gsi)) 12855 12856 Forward and backward iterations on basic blocks are possible with 12857`gsi_start_bb' and `gsi_last_bb'. 12858 12859 In the documentation below we sometimes refer to enum 12860`gsi_iterator_update'. The valid options for this enumeration are: 12861 12862 * `GSI_NEW_STMT' Only valid when a single statement is added. Move 12863 the iterator to it. 12864 12865 * `GSI_SAME_STMT' Leave the iterator at the same statement. 12866 12867 * `GSI_CONTINUE_LINKING' Move iterator to whatever position is 12868 suitable for linking other statements in the same direction. 12869 12870 Below is a list of the functions used to manipulate and use statement 12871iterators. 12872 12873 -- GIMPLE function: gimple_stmt_iterator gsi_start (gimple_seq seq) 12874 Return a new iterator pointing to the sequence `SEQ''s first 12875 statement. If `SEQ' is empty, the iterator's basic block is 12876 `NULL'. Use `gsi_start_bb' instead when the iterator needs to 12877 always have the correct basic block set. 12878 12879 -- GIMPLE function: gimple_stmt_iterator gsi_start_bb (basic_block bb) 12880 Return a new iterator pointing to the first statement in basic 12881 block `BB'. 12882 12883 -- GIMPLE function: gimple_stmt_iterator gsi_last (gimple_seq seq) 12884 Return a new iterator initially pointing to the last statement of 12885 sequence `SEQ'. If `SEQ' is empty, the iterator's basic block is 12886 `NULL'. Use `gsi_last_bb' instead when the iterator needs to 12887 always have the correct basic block set. 12888 12889 -- GIMPLE function: gimple_stmt_iterator gsi_last_bb (basic_block bb) 12890 Return a new iterator pointing to the last statement in basic 12891 block `BB'. 12892 12893 -- GIMPLE function: bool gsi_end_p (gimple_stmt_iterator i) 12894 Return `TRUE' if at the end of `I'. 12895 12896 -- GIMPLE function: bool gsi_one_before_end_p (gimple_stmt_iterator i) 12897 Return `TRUE' if we're one statement before the end of `I'. 12898 12899 -- GIMPLE function: void gsi_next (gimple_stmt_iterator *i) 12900 Advance the iterator to the next gimple statement. 12901 12902 -- GIMPLE function: void gsi_prev (gimple_stmt_iterator *i) 12903 Advance the iterator to the previous gimple statement. 12904 12905 -- GIMPLE function: gimple gsi_stmt (gimple_stmt_iterator i) 12906 Return the current stmt. 12907 12908 -- GIMPLE function: gimple_stmt_iterator gsi_after_labels (basic_block 12909 bb) 12910 Return a block statement iterator that points to the first 12911 non-label statement in block `BB'. 12912 12913 -- GIMPLE function: gimple * gsi_stmt_ptr (gimple_stmt_iterator *i) 12914 Return a pointer to the current stmt. 12915 12916 -- GIMPLE function: basic_block gsi_bb (gimple_stmt_iterator i) 12917 Return the basic block associated with this iterator. 12918 12919 -- GIMPLE function: gimple_seq gsi_seq (gimple_stmt_iterator i) 12920 Return the sequence associated with this iterator. 12921 12922 -- GIMPLE function: void gsi_remove (gimple_stmt_iterator *i, bool 12923 remove_eh_info) 12924 Remove the current stmt from the sequence. The iterator is 12925 updated to point to the next statement. When `REMOVE_EH_INFO' is 12926 true we remove the statement pointed to by iterator `I' from the 12927 `EH' tables. Otherwise we do not modify the `EH' tables. 12928 Generally, `REMOVE_EH_INFO' should be true when the statement is 12929 going to be removed from the `IL' and not reinserted elsewhere. 12930 12931 -- GIMPLE function: void gsi_link_seq_before (gimple_stmt_iterator *i, 12932 gimple_seq seq, enum gsi_iterator_update mode) 12933 Links the sequence of statements `SEQ' before the statement pointed 12934 by iterator `I'. `MODE' indicates what to do with the iterator 12935 after insertion (see `enum gsi_iterator_update' above). 12936 12937 -- GIMPLE function: void gsi_link_before (gimple_stmt_iterator *i, 12938 gimple g, enum gsi_iterator_update mode) 12939 Links statement `G' before the statement pointed-to by iterator 12940 `I'. Updates iterator `I' according to `MODE'. 12941 12942 -- GIMPLE function: void gsi_link_seq_after (gimple_stmt_iterator *i, 12943 gimple_seq seq, enum gsi_iterator_update mode) 12944 Links sequence `SEQ' after the statement pointed-to by iterator 12945 `I'. `MODE' is as in `gsi_insert_after'. 12946 12947 -- GIMPLE function: void gsi_link_after (gimple_stmt_iterator *i, 12948 gimple g, enum gsi_iterator_update mode) 12949 Links statement `G' after the statement pointed-to by iterator `I'. 12950 `MODE' is as in `gsi_insert_after'. 12951 12952 -- GIMPLE function: gimple_seq gsi_split_seq_after 12953 (gimple_stmt_iterator i) 12954 Move all statements in the sequence after `I' to a new sequence. 12955 Return this new sequence. 12956 12957 -- GIMPLE function: gimple_seq gsi_split_seq_before 12958 (gimple_stmt_iterator *i) 12959 Move all statements in the sequence before `I' to a new sequence. 12960 Return this new sequence. 12961 12962 -- GIMPLE function: void gsi_replace (gimple_stmt_iterator *i, gimple 12963 stmt, bool update_eh_info) 12964 Replace the statement pointed-to by `I' to `STMT'. If 12965 `UPDATE_EH_INFO' is true, the exception handling information of 12966 the original statement is moved to the new statement. 12967 12968 -- GIMPLE function: void gsi_insert_before (gimple_stmt_iterator *i, 12969 gimple stmt, enum gsi_iterator_update mode) 12970 Insert statement `STMT' before the statement pointed-to by iterator 12971 `I', update `STMT''s basic block and scan it for new operands. 12972 `MODE' specifies how to update iterator `I' after insertion (see 12973 enum `gsi_iterator_update'). 12974 12975 -- GIMPLE function: void gsi_insert_seq_before (gimple_stmt_iterator 12976 *i, gimple_seq seq, enum gsi_iterator_update mode) 12977 Like `gsi_insert_before', but for all the statements in `SEQ'. 12978 12979 -- GIMPLE function: void gsi_insert_after (gimple_stmt_iterator *i, 12980 gimple stmt, enum gsi_iterator_update mode) 12981 Insert statement `STMT' after the statement pointed-to by iterator 12982 `I', update `STMT''s basic block and scan it for new operands. 12983 `MODE' specifies how to update iterator `I' after insertion (see 12984 enum `gsi_iterator_update'). 12985 12986 -- GIMPLE function: void gsi_insert_seq_after (gimple_stmt_iterator 12987 *i, gimple_seq seq, enum gsi_iterator_update mode) 12988 Like `gsi_insert_after', but for all the statements in `SEQ'. 12989 12990 -- GIMPLE function: gimple_stmt_iterator gsi_for_stmt (gimple stmt) 12991 Finds iterator for `STMT'. 12992 12993 -- GIMPLE function: void gsi_move_after (gimple_stmt_iterator *from, 12994 gimple_stmt_iterator *to) 12995 Move the statement at `FROM' so it comes right after the statement 12996 at `TO'. 12997 12998 -- GIMPLE function: void gsi_move_before (gimple_stmt_iterator *from, 12999 gimple_stmt_iterator *to) 13000 Move the statement at `FROM' so it comes right before the statement 13001 at `TO'. 13002 13003 -- GIMPLE function: void gsi_move_to_bb_end (gimple_stmt_iterator 13004 *from, basic_block bb) 13005 Move the statement at `FROM' to the end of basic block `BB'. 13006 13007 -- GIMPLE function: void gsi_insert_on_edge (edge e, gimple stmt) 13008 Add `STMT' to the pending list of edge `E'. No actual insertion is 13009 made until a call to `gsi_commit_edge_inserts'() is made. 13010 13011 -- GIMPLE function: void gsi_insert_seq_on_edge (edge e, gimple_seq 13012 seq) 13013 Add the sequence of statements in `SEQ' to the pending list of edge 13014 `E'. No actual insertion is made until a call to 13015 `gsi_commit_edge_inserts'() is made. 13016 13017 -- GIMPLE function: basic_block gsi_insert_on_edge_immediate (edge e, 13018 gimple stmt) 13019 Similar to `gsi_insert_on_edge'+`gsi_commit_edge_inserts'. If a 13020 new block has to be created, it is returned. 13021 13022 -- GIMPLE function: void gsi_commit_one_edge_insert (edge e, 13023 basic_block *new_bb) 13024 Commit insertions pending at edge `E'. If a new block is created, 13025 set `NEW_BB' to this block, otherwise set it to `NULL'. 13026 13027 -- GIMPLE function: void gsi_commit_edge_inserts (void) 13028 This routine will commit all pending edge insertions, creating any 13029 new basic blocks which are necessary. 13030 13031 13032File: gccint.info, Node: Adding a new GIMPLE statement code, Next: Statement and operand traversals, Prev: Sequence iterators, Up: GIMPLE 13033 1303411.11 Adding a new GIMPLE statement code 13035======================================== 13036 13037The first step in adding a new GIMPLE statement code, is modifying the 13038file `gimple.def', which contains all the GIMPLE codes. Then you must 13039add a corresponding gimple_statement_base subclass located in 13040`gimple.h'. This in turn, will require you to add a corresponding 13041`GTY' tag in `gsstruct.def', and code to handle this tag in 13042`gss_for_code' which is located in `gimple.c'. 13043 13044 In order for the garbage collector to know the size of the structure 13045you created in `gimple.h', you need to add a case to handle your new 13046GIMPLE statement in `gimple_size' which is located in `gimple.c'. 13047 13048 You will probably want to create a function to build the new gimple 13049statement in `gimple.c'. The function should be called 13050`gimple_build_NEW-TUPLE-NAME', and should return the new tuple as a 13051pointer to the appropriate gimple_statement_base subclass. 13052 13053 If your new statement requires accessors for any members or operands 13054it may have, put simple inline accessors in `gimple.h' and any 13055non-trivial accessors in `gimple.c' with a corresponding prototype in 13056`gimple.h'. 13057 13058 You should add the new statement subclass to the class hierarchy 13059diagram in `gimple.texi'. 13060 13061 13062File: gccint.info, Node: Statement and operand traversals, Prev: Adding a new GIMPLE statement code, Up: GIMPLE 13063 1306411.12 Statement and operand traversals 13065====================================== 13066 13067There are two functions available for walking statements and sequences: 13068`walk_gimple_stmt' and `walk_gimple_seq', accordingly, and a third 13069function for walking the operands in a statement: `walk_gimple_op'. 13070 13071 -- GIMPLE function: tree walk_gimple_stmt (gimple_stmt_iterator *gsi, 13072 walk_stmt_fn callback_stmt, walk_tree_fn callback_op, struct 13073 walk_stmt_info *wi) 13074 This function is used to walk the current statement in `GSI', 13075 optionally using traversal state stored in `WI'. If `WI' is 13076 `NULL', no state is kept during the traversal. 13077 13078 The callback `CALLBACK_STMT' is called. If `CALLBACK_STMT' returns 13079 true, it means that the callback function has handled all the 13080 operands of the statement and it is not necessary to walk its 13081 operands. 13082 13083 If `CALLBACK_STMT' is `NULL' or it returns false, `CALLBACK_OP' is 13084 called on each operand of the statement via `walk_gimple_op'. If 13085 `walk_gimple_op' returns non-`NULL' for any operand, the remaining 13086 operands are not scanned. 13087 13088 The return value is that returned by the last call to 13089 `walk_gimple_op', or `NULL_TREE' if no `CALLBACK_OP' is specified. 13090 13091 -- GIMPLE function: tree walk_gimple_op (gimple stmt, walk_tree_fn 13092 callback_op, struct walk_stmt_info *wi) 13093 Use this function to walk the operands of statement `STMT'. Every 13094 operand is walked via `walk_tree' with optional state information 13095 in `WI'. 13096 13097 `CALLBACK_OP' is called on each operand of `STMT' via `walk_tree'. 13098 Additional parameters to `walk_tree' must be stored in `WI'. For 13099 each operand `OP', `walk_tree' is called as: 13100 13101 walk_tree (&`OP', `CALLBACK_OP', `WI', `PSET') 13102 13103 If `CALLBACK_OP' returns non-`NULL' for an operand, the remaining 13104 operands are not scanned. The return value is that returned by 13105 the last call to `walk_tree', or `NULL_TREE' if no `CALLBACK_OP' is 13106 specified. 13107 13108 -- GIMPLE function: tree walk_gimple_seq (gimple_seq seq, walk_stmt_fn 13109 callback_stmt, walk_tree_fn callback_op, struct 13110 walk_stmt_info *wi) 13111 This function walks all the statements in the sequence `SEQ' 13112 calling `walk_gimple_stmt' on each one. `WI' is as in 13113 `walk_gimple_stmt'. If `walk_gimple_stmt' returns non-`NULL', the 13114 walk is stopped and the value returned. Otherwise, all the 13115 statements are walked and `NULL_TREE' returned. 13116 13117 13118File: gccint.info, Node: Tree SSA, Next: RTL, Prev: GIMPLE, Up: Top 13119 1312012 Analysis and Optimization of GIMPLE tuples 13121********************************************* 13122 13123GCC uses three main intermediate languages to represent the program 13124during compilation: GENERIC, GIMPLE and RTL. GENERIC is a 13125language-independent representation generated by each front end. It is 13126used to serve as an interface between the parser and optimizer. 13127GENERIC is a common representation that is able to represent programs 13128written in all the languages supported by GCC. 13129 13130 GIMPLE and RTL are used to optimize the program. GIMPLE is used for 13131target and language independent optimizations (e.g., inlining, constant 13132propagation, tail call elimination, redundancy elimination, etc). Much 13133like GENERIC, GIMPLE is a language independent, tree based 13134representation. However, it differs from GENERIC in that the GIMPLE 13135grammar is more restrictive: expressions contain no more than 3 13136operands (except function calls), it has no control flow structures and 13137expressions with side-effects are only allowed on the right hand side 13138of assignments. See the chapter describing GENERIC and GIMPLE for more 13139details. 13140 13141 This chapter describes the data structures and functions used in the 13142GIMPLE optimizers (also known as "tree optimizers" or "middle end"). 13143In particular, it focuses on all the macros, data structures, functions 13144and programming constructs needed to implement optimization passes for 13145GIMPLE. 13146 13147* Menu: 13148 13149* Annotations:: Attributes for variables. 13150* SSA Operands:: SSA names referenced by GIMPLE statements. 13151* SSA:: Static Single Assignment representation. 13152* Alias analysis:: Representing aliased loads and stores. 13153* Memory model:: Memory model used by the middle-end. 13154 13155 13156File: gccint.info, Node: Annotations, Next: SSA Operands, Up: Tree SSA 13157 1315812.1 Annotations 13159================ 13160 13161The optimizers need to associate attributes with variables during the 13162optimization process. For instance, we need to know whether a variable 13163has aliases. All these attributes are stored in data structures called 13164annotations which are then linked to the field `ann' in `struct 13165tree_common'. 13166 13167 13168File: gccint.info, Node: SSA Operands, Next: SSA, Prev: Annotations, Up: Tree SSA 13169 1317012.2 SSA Operands 13171================= 13172 13173Almost every GIMPLE statement will contain a reference to a variable or 13174memory location. Since statements come in different shapes and sizes, 13175their operands are going to be located at various spots inside the 13176statement's tree. To facilitate access to the statement's operands, 13177they are organized into lists associated inside each statement's 13178annotation. Each element in an operand list is a pointer to a 13179`VAR_DECL', `PARM_DECL' or `SSA_NAME' tree node. This provides a very 13180convenient way of examining and replacing operands. 13181 13182 Data flow analysis and optimization is done on all tree nodes 13183representing variables. Any node for which `SSA_VAR_P' returns nonzero 13184is considered when scanning statement operands. However, not all 13185`SSA_VAR_P' variables are processed in the same way. For the purposes 13186of optimization, we need to distinguish between references to local 13187scalar variables and references to globals, statics, structures, 13188arrays, aliased variables, etc. The reason is simple, the compiler can 13189gather complete data flow information for a local scalar. On the other 13190hand, a global variable may be modified by a function call, it may not 13191be possible to keep track of all the elements of an array or the fields 13192of a structure, etc. 13193 13194 The operand scanner gathers two kinds of operands: "real" and 13195"virtual". An operand for which `is_gimple_reg' returns true is 13196considered real, otherwise it is a virtual operand. We also 13197distinguish between uses and definitions. An operand is used if its 13198value is loaded by the statement (e.g., the operand at the RHS of an 13199assignment). If the statement assigns a new value to the operand, the 13200operand is considered a definition (e.g., the operand at the LHS of an 13201assignment). 13202 13203 Virtual and real operands also have very different data flow 13204properties. Real operands are unambiguous references to the full 13205object that they represent. For instance, given 13206 13207 { 13208 int a, b; 13209 a = b 13210 } 13211 13212 Since `a' and `b' are non-aliased locals, the statement `a = b' will 13213have one real definition and one real use because variable `a' is 13214completely modified with the contents of variable `b'. Real definition 13215are also known as "killing definitions". Similarly, the use of `b' 13216reads all its bits. 13217 13218 In contrast, virtual operands are used with variables that can have a 13219partial or ambiguous reference. This includes structures, arrays, 13220globals, and aliased variables. In these cases, we have two types of 13221definitions. For globals, structures, and arrays, we can determine from 13222a statement whether a variable of these types has a killing definition. 13223If the variable does, then the statement is marked as having a "must 13224definition" of that variable. However, if a statement is only defining 13225a part of the variable (i.e. a field in a structure), or if we know 13226that a statement might define the variable but we cannot say for sure, 13227then we mark that statement as having a "may definition". For 13228instance, given 13229 13230 { 13231 int a, b, *p; 13232 13233 if (...) 13234 p = &a; 13235 else 13236 p = &b; 13237 *p = 5; 13238 return *p; 13239 } 13240 13241 The assignment `*p = 5' may be a definition of `a' or `b'. If we 13242cannot determine statically where `p' is pointing to at the time of the 13243store operation, we create virtual definitions to mark that statement 13244as a potential definition site for `a' and `b'. Memory loads are 13245similarly marked with virtual use operands. Virtual operands are shown 13246in tree dumps right before the statement that contains them. To 13247request a tree dump with virtual operands, use the `-vops' option to 13248`-fdump-tree': 13249 13250 { 13251 int a, b, *p; 13252 13253 if (...) 13254 p = &a; 13255 else 13256 p = &b; 13257 # a = VDEF <a> 13258 # b = VDEF <b> 13259 *p = 5; 13260 13261 # VUSE <a> 13262 # VUSE <b> 13263 return *p; 13264 } 13265 13266 Notice that `VDEF' operands have two copies of the referenced 13267variable. This indicates that this is not a killing definition of that 13268variable. In this case we refer to it as a "may definition" or 13269"aliased store". The presence of the second copy of the variable in 13270the `VDEF' operand will become important when the function is converted 13271into SSA form. This will be used to link all the non-killing 13272definitions to prevent optimizations from making incorrect assumptions 13273about them. 13274 13275 Operands are updated as soon as the statement is finished via a call 13276to `update_stmt'. If statement elements are changed via `SET_USE' or 13277`SET_DEF', then no further action is required (i.e., those macros take 13278care of updating the statement). If changes are made by manipulating 13279the statement's tree directly, then a call must be made to 13280`update_stmt' when complete. Calling one of the `bsi_insert' routines 13281or `bsi_replace' performs an implicit call to `update_stmt'. 13282 1328312.2.1 Operand Iterators And Access Routines 13284-------------------------------------------- 13285 13286Operands are collected by `tree-ssa-operands.c'. They are stored 13287inside each statement's annotation and can be accessed through either 13288the operand iterators or an access routine. 13289 13290 The following access routines are available for examining operands: 13291 13292 1. `SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return 13293 NULL unless there is exactly one operand matching the specified 13294 flags. If there is exactly one operand, the operand is returned 13295 as either a `tree', `def_operand_p', or `use_operand_p'. 13296 13297 tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags); 13298 use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES); 13299 def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS); 13300 13301 2. `ZERO_SSA_OPERANDS': This macro returns true if there are no 13302 operands matching the specified flags. 13303 13304 if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS)) 13305 return; 13306 13307 3. `NUM_SSA_OPERANDS': This macro Returns the number of operands 13308 matching 'flags'. This actually executes a loop to perform the 13309 count, so only use this if it is really needed. 13310 13311 int count = NUM_SSA_OPERANDS (stmt, flags) 13312 13313 If you wish to iterate over some or all operands, use the 13314`FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator. For example, to print 13315all the operands for a statement: 13316 13317 void 13318 print_ops (tree stmt) 13319 { 13320 ssa_op_iter; 13321 tree var; 13322 13323 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS) 13324 print_generic_expr (stderr, var, TDF_SLIM); 13325 } 13326 13327 How to choose the appropriate iterator: 13328 13329 1. Determine whether you are need to see the operand pointers, or 13330 just the trees, and choose the appropriate macro: 13331 13332 Need Macro: 13333 ---- ------- 13334 use_operand_p FOR_EACH_SSA_USE_OPERAND 13335 def_operand_p FOR_EACH_SSA_DEF_OPERAND 13336 tree FOR_EACH_SSA_TREE_OPERAND 13337 13338 2. You need to declare a variable of the type you are interested in, 13339 and an ssa_op_iter structure which serves as the loop controlling 13340 variable. 13341 13342 3. Determine which operands you wish to use, and specify the flags of 13343 those you are interested in. They are documented in 13344 `tree-ssa-operands.h': 13345 13346 #define SSA_OP_USE 0x01 /* Real USE operands. */ 13347 #define SSA_OP_DEF 0x02 /* Real DEF operands. */ 13348 #define SSA_OP_VUSE 0x04 /* VUSE operands. */ 13349 #define SSA_OP_VDEF 0x08 /* VDEF operands. */ 13350 13351 /* These are commonly grouped operand flags. */ 13352 #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE) 13353 #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VDEF) 13354 #define SSA_OP_ALL_VIRTUALS (SSA_OP_VIRTUAL_USES | SSA_OP_VIRTUAL_DEFS) 13355 #define SSA_OP_ALL_USES (SSA_OP_VIRTUAL_USES | SSA_OP_USE) 13356 #define SSA_OP_ALL_DEFS (SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF) 13357 #define SSA_OP_ALL_OPERANDS (SSA_OP_ALL_USES | SSA_OP_ALL_DEFS) 13358 13359 So if you want to look at the use pointers for all the `USE' and 13360`VUSE' operands, you would do something like: 13361 13362 use_operand_p use_p; 13363 ssa_op_iter iter; 13364 13365 FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE)) 13366 { 13367 process_use_ptr (use_p); 13368 } 13369 13370 The `TREE' macro is basically the same as the `USE' and `DEF' macros, 13371only with the use or def dereferenced via `USE_FROM_PTR (use_p)' and 13372`DEF_FROM_PTR (def_p)'. Since we aren't using operand pointers, use 13373and defs flags can be mixed. 13374 13375 tree var; 13376 ssa_op_iter iter; 13377 13378 FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE) 13379 { 13380 print_generic_expr (stderr, var, TDF_SLIM); 13381 } 13382 13383 `VDEF's are broken into two flags, one for the `DEF' portion 13384(`SSA_OP_VDEF') and one for the USE portion (`SSA_OP_VUSE'). 13385 13386 There are many examples in the code, in addition to the documentation 13387in `tree-ssa-operands.h' and `ssa-iterators.h'. 13388 13389 There are also a couple of variants on the stmt iterators regarding PHI 13390nodes. 13391 13392 `FOR_EACH_PHI_ARG' Works exactly like `FOR_EACH_SSA_USE_OPERAND', 13393except it works over `PHI' arguments instead of statement operands. 13394 13395 /* Look at every virtual PHI use. */ 13396 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES) 13397 { 13398 my_code; 13399 } 13400 13401 /* Look at every real PHI use. */ 13402 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES) 13403 my_code; 13404 13405 /* Look at every PHI use. */ 13406 FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES) 13407 my_code; 13408 13409 `FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like 13410`FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a 13411statement or a `PHI' node. These should be used when it is appropriate 13412but they are not quite as efficient as the individual `FOR_EACH_PHI' 13413and `FOR_EACH_SSA' routines. 13414 13415 FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags) 13416 { 13417 my_code; 13418 } 13419 13420 FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags) 13421 { 13422 my_code; 13423 } 13424 1342512.2.2 Immediate Uses 13426--------------------- 13427 13428Immediate use information is now always available. Using the immediate 13429use iterators, you may examine every use of any `SSA_NAME'. For 13430instance, to change each use of `ssa_var' to `ssa_var2' and call 13431fold_stmt on each stmt after that is done: 13432 13433 use_operand_p imm_use_p; 13434 imm_use_iterator iterator; 13435 tree ssa_var, stmt; 13436 13437 13438 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 13439 { 13440 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 13441 SET_USE (imm_use_p, ssa_var_2); 13442 fold_stmt (stmt); 13443 } 13444 13445 There are 2 iterators which can be used. `FOR_EACH_IMM_USE_FAST' is 13446used when the immediate uses are not changed, i.e., you are looking at 13447the uses, but not setting them. 13448 13449 If they do get changed, then care must be taken that things are not 13450changed under the iterators, so use the `FOR_EACH_IMM_USE_STMT' and 13451`FOR_EACH_IMM_USE_ON_STMT' iterators. They attempt to preserve the 13452sanity of the use list by moving all the uses for a statement into a 13453controlled position, and then iterating over those uses. Then the 13454optimization can manipulate the stmt when all the uses have been 13455processed. This is a little slower than the FAST version since it adds 13456a placeholder element and must sort through the list a bit for each 13457statement. This placeholder element must be also be removed if the 13458loop is terminated early. The macro `BREAK_FROM_IMM_USE_SAFE' is 13459provided to do this : 13460 13461 FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var) 13462 { 13463 if (stmt == last_stmt) 13464 BREAK_FROM_SAFE_IMM_USE (iter); 13465 13466 FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator) 13467 SET_USE (imm_use_p, ssa_var_2); 13468 fold_stmt (stmt); 13469 } 13470 13471 There are checks in `verify_ssa' which verify that the immediate use 13472list is up to date, as well as checking that an optimization didn't 13473break from the loop without using this macro. It is safe to simply 13474'break'; from a `FOR_EACH_IMM_USE_FAST' traverse. 13475 13476 Some useful functions and macros: 13477 1. `has_zero_uses (ssa_var)' : Returns true if there are no uses of 13478 `ssa_var'. 13479 13480 2. `has_single_use (ssa_var)' : Returns true if there is only a 13481 single use of `ssa_var'. 13482 13483 3. `single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' : 13484 Returns true if there is only a single use of `ssa_var', and also 13485 returns the use pointer and statement it occurs in, in the second 13486 and third parameters. 13487 13488 4. `num_imm_uses (ssa_var)' : Returns the number of immediate uses of 13489 `ssa_var'. It is better not to use this if possible since it simply 13490 utilizes a loop to count the uses. 13491 13492 5. `PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a `PHI' 13493 node, return the index number for the use. An assert is triggered 13494 if the use isn't located in a `PHI' node. 13495 13496 6. `USE_STMT (use_p)' : Return the statement a use occurs in. 13497 13498 Note that uses are not put into an immediate use list until their 13499statement is actually inserted into the instruction stream via a 13500`bsi_*' routine. 13501 13502 It is also still possible to utilize lazy updating of statements, but 13503this should be used only when absolutely required. Both alias analysis 13504and the dominator optimizations currently do this. 13505 13506 When lazy updating is being used, the immediate use information is out 13507of date and cannot be used reliably. Lazy updating is achieved by 13508simply marking statements modified via calls to `mark_stmt_modified' 13509instead of `update_stmt'. When lazy updating is no longer required, 13510all the modified statements must have `update_stmt' called in order to 13511bring them up to date. This must be done before the optimization is 13512finished, or `verify_ssa' will trigger an abort. 13513 13514 This is done with a simple loop over the instruction stream: 13515 block_stmt_iterator bsi; 13516 basic_block bb; 13517 FOR_EACH_BB (bb) 13518 { 13519 for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi)) 13520 update_stmt_if_modified (bsi_stmt (bsi)); 13521 } 13522 13523 13524File: gccint.info, Node: SSA, Next: Alias analysis, Prev: SSA Operands, Up: Tree SSA 13525 1352612.3 Static Single Assignment 13527============================= 13528 13529Most of the tree optimizers rely on the data flow information provided 13530by the Static Single Assignment (SSA) form. We implement the SSA form 13531as described in `R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K. 13532Zadeck. Efficiently Computing Static Single Assignment Form and the 13533Control Dependence Graph. ACM Transactions on Programming Languages 13534and Systems, 13(4):451-490, October 1991'. 13535 13536 The SSA form is based on the premise that program variables are 13537assigned in exactly one location in the program. Multiple assignments 13538to the same variable create new versions of that variable. Naturally, 13539actual programs are seldom in SSA form initially because variables tend 13540to be assigned multiple times. The compiler modifies the program 13541representation so that every time a variable is assigned in the code, a 13542new version of the variable is created. Different versions of the same 13543variable are distinguished by subscripting the variable name with its 13544version number. Variables used in the right-hand side of expressions 13545are renamed so that their version number matches that of the most 13546recent assignment. 13547 13548 We represent variable versions using `SSA_NAME' nodes. The renaming 13549process in `tree-ssa.c' wraps every real and virtual operand with an 13550`SSA_NAME' node which contains the version number and the statement 13551that created the `SSA_NAME'. Only definitions and virtual definitions 13552may create new `SSA_NAME' nodes. 13553 13554 Sometimes, flow of control makes it impossible to determine the most 13555recent version of a variable. In these cases, the compiler inserts an 13556artificial definition for that variable called "PHI function" or "PHI 13557node". This new definition merges all the incoming versions of the 13558variable to create a new name for it. For instance, 13559 13560 if (...) 13561 a_1 = 5; 13562 else if (...) 13563 a_2 = 2; 13564 else 13565 a_3 = 13; 13566 13567 # a_4 = PHI <a_1, a_2, a_3> 13568 return a_4; 13569 13570 Since it is not possible to determine which of the three branches will 13571be taken at runtime, we don't know which of `a_1', `a_2' or `a_3' to 13572use at the return statement. So, the SSA renamer creates a new version 13573`a_4' which is assigned the result of "merging" `a_1', `a_2' and `a_3'. 13574Hence, PHI nodes mean "one of these operands. I don't know which". 13575 13576 The following functions can be used to examine PHI nodes 13577 13578 -- Function: gimple_phi_result (PHI) 13579 Returns the `SSA_NAME' created by PHI node PHI (i.e., PHI's LHS). 13580 13581 -- Function: gimple_phi_num_args (PHI) 13582 Returns the number of arguments in PHI. This number is exactly 13583 the number of incoming edges to the basic block holding PHI. 13584 13585 -- Function: gimple_phi_arg (PHI, I) 13586 Returns Ith argument of PHI. 13587 13588 -- Function: gimple_phi_arg_edge (PHI, I) 13589 Returns the incoming edge for the Ith argument of PHI. 13590 13591 -- Function: gimple_phi_arg_def (PHI, I) 13592 Returns the `SSA_NAME' for the Ith argument of PHI. 13593 1359412.3.1 Preserving the SSA form 13595------------------------------ 13596 13597Some optimization passes make changes to the function that invalidate 13598the SSA property. This can happen when a pass has added new symbols or 13599changed the program so that variables that were previously aliased 13600aren't anymore. Whenever something like this happens, the affected 13601symbols must be renamed into SSA form again. Transformations that emit 13602new code or replicate existing statements will also need to update the 13603SSA form. 13604 13605 Since GCC implements two different SSA forms for register and virtual 13606variables, keeping the SSA form up to date depends on whether you are 13607updating register or virtual names. In both cases, the general idea 13608behind incremental SSA updates is similar: when new SSA names are 13609created, they typically are meant to replace other existing names in 13610the program. 13611 13612 For instance, given the following code: 13613 13614 1 L0: 13615 2 x_1 = PHI (0, x_5) 13616 3 if (x_1 < 10) 13617 4 if (x_1 > 7) 13618 5 y_2 = 0 13619 6 else 13620 7 y_3 = x_1 + x_7 13621 8 endif 13622 9 x_5 = x_1 + 1 13623 10 goto L0; 13624 11 endif 13625 13626 Suppose that we insert new names `x_10' and `x_11' (lines `4' and `8'). 13627 13628 1 L0: 13629 2 x_1 = PHI (0, x_5) 13630 3 if (x_1 < 10) 13631 4 x_10 = ... 13632 5 if (x_1 > 7) 13633 6 y_2 = 0 13634 7 else 13635 8 x_11 = ... 13636 9 y_3 = x_1 + x_7 13637 10 endif 13638 11 x_5 = x_1 + 1 13639 12 goto L0; 13640 13 endif 13641 13642 We want to replace all the uses of `x_1' with the new definitions of 13643`x_10' and `x_11'. Note that the only uses that should be replaced are 13644those at lines `5', `9' and `11'. Also, the use of `x_7' at line `9' 13645should _not_ be replaced (this is why we cannot just mark symbol `x' for 13646renaming). 13647 13648 Additionally, we may need to insert a PHI node at line `11' because 13649that is a merge point for `x_10' and `x_11'. So the use of `x_1' at 13650line `11' will be replaced with the new PHI node. The insertion of PHI 13651nodes is optional. They are not strictly necessary to preserve the SSA 13652form, and depending on what the caller inserted, they may not even be 13653useful for the optimizers. 13654 13655 Updating the SSA form is a two step process. First, the pass has to 13656identify which names need to be updated and/or which symbols need to be 13657renamed into SSA form for the first time. When new names are 13658introduced to replace existing names in the program, the mapping 13659between the old and the new names are registered by calling 13660`register_new_name_mapping' (note that if your pass creates new code by 13661duplicating basic blocks, the call to `tree_duplicate_bb' will set up 13662the necessary mappings automatically). 13663 13664 After the replacement mappings have been registered and new symbols 13665marked for renaming, a call to `update_ssa' makes the registered 13666changes. This can be done with an explicit call or by creating `TODO' 13667flags in the `tree_opt_pass' structure for your pass. There are 13668several `TODO' flags that control the behavior of `update_ssa': 13669 13670 * `TODO_update_ssa'. Update the SSA form inserting PHI nodes for 13671 newly exposed symbols and virtual names marked for updating. When 13672 updating real names, only insert PHI nodes for a real name `O_j' 13673 in blocks reached by all the new and old definitions for `O_j'. 13674 If the iterated dominance frontier for `O_j' is not pruned, we may 13675 end up inserting PHI nodes in blocks that have one or more edges 13676 with no incoming definition for `O_j'. This would lead to 13677 uninitialized warnings for `O_j''s symbol. 13678 13679 * `TODO_update_ssa_no_phi'. Update the SSA form without inserting 13680 any new PHI nodes at all. This is used by passes that have either 13681 inserted all the PHI nodes themselves or passes that need only to 13682 patch use-def and def-def chains for virtuals (e.g., DCE). 13683 13684 * `TODO_update_ssa_full_phi'. Insert PHI nodes everywhere they are 13685 needed. No pruning of the IDF is done. This is used by passes 13686 that need the PHI nodes for `O_j' even if it means that some 13687 arguments will come from the default definition of `O_j''s symbol 13688 (e.g., `pass_linear_transform'). 13689 13690 WARNING: If you need to use this flag, chances are that your pass 13691 may be doing something wrong. Inserting PHI nodes for an old name 13692 where not all edges carry a new replacement may lead to silent 13693 codegen errors or spurious uninitialized warnings. 13694 13695 * `TODO_update_ssa_only_virtuals'. Passes that update the SSA form 13696 on their own may want to delegate the updating of virtual names to 13697 the generic updater. Since FUD chains are easier to maintain, 13698 this simplifies the work they need to do. NOTE: If this flag is 13699 used, any OLD->NEW mappings for real names are explicitly 13700 destroyed and only the symbols marked for renaming are processed. 13701 1370212.3.2 Preserving the virtual SSA form 13703-------------------------------------- 13704 13705The virtual SSA form is harder to preserve than the non-virtual SSA form 13706mainly because the set of virtual operands for a statement may change at 13707what some would consider unexpected times. In general, statement 13708modifications should be bracketed between calls to `push_stmt_changes' 13709and `pop_stmt_changes'. For example, 13710 13711 munge_stmt (tree stmt) 13712 { 13713 push_stmt_changes (&stmt); 13714 ... rewrite STMT ... 13715 pop_stmt_changes (&stmt); 13716 } 13717 13718 The call to `push_stmt_changes' saves the current state of the 13719statement operands and the call to `pop_stmt_changes' compares the 13720saved state with the current one and does the appropriate symbol 13721marking for the SSA renamer. 13722 13723 It is possible to modify several statements at a time, provided that 13724`push_stmt_changes' and `pop_stmt_changes' are called in LIFO order, as 13725when processing a stack of statements. 13726 13727 Additionally, if the pass discovers that it did not need to make 13728changes to the statement after calling `push_stmt_changes', it can 13729simply discard the topmost change buffer by calling 13730`discard_stmt_changes'. This will avoid the expensive operand re-scan 13731operation and the buffer comparison that determines if symbols need to 13732be marked for renaming. 13733 1373412.3.3 Examining `SSA_NAME' nodes 13735--------------------------------- 13736 13737The following macros can be used to examine `SSA_NAME' nodes 13738 13739 -- Macro: SSA_NAME_DEF_STMT (VAR) 13740 Returns the statement S that creates the `SSA_NAME' VAR. If S is 13741 an empty statement (i.e., `IS_EMPTY_STMT (S)' returns `true'), it 13742 means that the first reference to this variable is a USE or a VUSE. 13743 13744 -- Macro: SSA_NAME_VERSION (VAR) 13745 Returns the version number of the `SSA_NAME' object VAR. 13746 1374712.3.4 Walking the dominator tree 13748--------------------------------- 13749 13750 -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB) 13751 This function walks the dominator tree for the current CFG calling 13752 a set of callback functions defined in STRUCT DOM_WALK_DATA in 13753 `domwalk.h'. The call back functions you need to define give you 13754 hooks to execute custom code at various points during traversal: 13755 13756 1. Once to initialize any local data needed while processing BB 13757 and its children. This local data is pushed into an internal 13758 stack which is automatically pushed and popped as the walker 13759 traverses the dominator tree. 13760 13761 2. Once before traversing all the statements in the BB. 13762 13763 3. Once for every statement inside BB. 13764 13765 4. Once after traversing all the statements and before recursing 13766 into BB's dominator children. 13767 13768 5. It then recurses into all the dominator children of BB. 13769 13770 6. After recursing into all the dominator children of BB it can, 13771 optionally, traverse every statement in BB again (i.e., 13772 repeating steps 2 and 3). 13773 13774 7. Once after walking the statements in BB and BB's dominator 13775 children. At this stage, the block local data stack is 13776 popped. 13777 13778 13779File: gccint.info, Node: Alias analysis, Next: Memory model, Prev: SSA, Up: Tree SSA 13780 1378112.4 Alias analysis 13782=================== 13783 13784Alias analysis in GIMPLE SSA form consists of two pieces. First the 13785virtual SSA web ties conflicting memory accesses and provides a SSA 13786use-def chain and SSA immediate-use chains for walking possibly 13787dependent memory accesses. Second an alias-oracle can be queried to 13788disambiguate explicit and implicit memory references. 13789 13790 1. Memory SSA form. 13791 13792 All statements that may use memory have exactly one accompanied 13793 use of a virtual SSA name that represents the state of memory at 13794 the given point in the IL. 13795 13796 All statements that may define memory have exactly one accompanied 13797 definition of a virtual SSA name using the previous state of memory 13798 and defining the new state of memory after the given point in the 13799 IL. 13800 13801 int i; 13802 int foo (void) 13803 { 13804 # .MEM_3 = VDEF <.MEM_2(D)> 13805 i = 1; 13806 # VUSE <.MEM_3> 13807 return i; 13808 } 13809 13810 The virtual SSA names in this case are `.MEM_2(D)' and `.MEM_3'. 13811 The store to the global variable `i' defines `.MEM_3' invalidating 13812 `.MEM_2(D)'. The load from `i' uses that new state `.MEM_3'. 13813 13814 The virtual SSA web serves as constraints to SSA optimizers 13815 preventing illegitimate code-motion and optimization. It also 13816 provides a way to walk related memory statements. 13817 13818 2. Points-to and escape analysis. 13819 13820 Points-to analysis builds a set of constraints from the GIMPLE SSA 13821 IL representing all pointer operations and facts we do or do not 13822 know about pointers. Solving this set of constraints yields a 13823 conservatively correct solution for each pointer variable in the 13824 program (though we are only interested in SSA name pointers) as to 13825 what it may possibly point to. 13826 13827 This points-to solution for a given SSA name pointer is stored in 13828 the `pt_solution' sub-structure of the `SSA_NAME_PTR_INFO' record. 13829 The following accessor functions are available: 13830 13831 * `pt_solution_includes' 13832 13833 * `pt_solutions_intersect' 13834 13835 Points-to analysis also computes the solution for two special set 13836 of pointers, `ESCAPED' and `CALLUSED'. Those represent all memory 13837 that has escaped the scope of analysis or that is used by pure or 13838 nested const calls. 13839 13840 3. Type-based alias analysis 13841 13842 Type-based alias analysis is frontend dependent though generic 13843 support is provided by the middle-end in `alias.c'. TBAA code is 13844 used by both tree optimizers and RTL optimizers. 13845 13846 Every language that wishes to perform language-specific alias 13847 analysis should define a function that computes, given a `tree' 13848 node, an alias set for the node. Nodes in different alias sets 13849 are not allowed to alias. For an example, see the C front-end 13850 function `c_get_alias_set'. 13851 13852 4. Tree alias-oracle 13853 13854 The tree alias-oracle provides means to disambiguate two memory 13855 references and memory references against statements. The following 13856 queries are available: 13857 13858 * `refs_may_alias_p' 13859 13860 * `ref_maybe_used_by_stmt_p' 13861 13862 * `stmt_may_clobber_ref_p' 13863 13864 In addition to those two kind of statement walkers are available 13865 walking statements related to a reference ref. 13866 `walk_non_aliased_vuses' walks over dominating memory defining 13867 statements and calls back if the statement does not clobber ref 13868 providing the non-aliased VUSE. The walk stops at the first 13869 clobbering statement or if asked to. `walk_aliased_vdefs' walks 13870 over dominating memory defining statements and calls back on each 13871 statement clobbering ref providing its aliasing VDEF. The walk 13872 stops if asked to. 13873 13874 13875 13876File: gccint.info, Node: Memory model, Prev: Alias analysis, Up: Tree SSA 13877 1387812.5 Memory model 13879================= 13880 13881The memory model used by the middle-end models that of the C/C++ 13882languages. The middle-end has the notion of an effective type of a 13883memory region which is used for type-based alias analysis. 13884 13885 The following is a refinement of ISO C99 6.5/6, clarifying the block 13886copy case to follow common sense and extending the concept of a dynamic 13887effective type to objects with a declared type as required for C++. 13888 13889 The effective type of an object for an access to its stored value is 13890 the declared type of the object or the effective type determined by 13891 a previous store to it. If a value is stored into an object through 13892 an lvalue having a type that is not a character type, then the 13893 type of the lvalue becomes the effective type of the object for that 13894 access and for subsequent accesses that do not modify the stored value. 13895 If a value is copied into an object using `memcpy' or `memmove', 13896 or is copied as an array of character type, then the effective type 13897 of the modified object for that access and for subsequent accesses that 13898 do not modify the value is undetermined. For all other accesses to an 13899 object, the effective type of the object is simply the type of the 13900 lvalue used for the access. 13901 13902 13903File: gccint.info, Node: RTL, Next: Control Flow, Prev: Tree SSA, Up: Top 13904 1390513 RTL Representation 13906********************* 13907 13908The last part of the compiler work is done on a low-level intermediate 13909representation called Register Transfer Language. In this language, the 13910instructions to be output are described, pretty much one by one, in an 13911algebraic form that describes what the instruction does. 13912 13913 RTL is inspired by Lisp lists. It has both an internal form, made up 13914of structures that point at other structures, and a textual form that 13915is used in the machine description and in printed debugging dumps. The 13916textual form uses nested parentheses to indicate the pointers in the 13917internal form. 13918 13919* Menu: 13920 13921* RTL Objects:: Expressions vs vectors vs strings vs integers. 13922* RTL Classes:: Categories of RTL expression objects, and their structure. 13923* Accessors:: Macros to access expression operands or vector elts. 13924* Special Accessors:: Macros to access specific annotations on RTL. 13925* Flags:: Other flags in an RTL expression. 13926* Machine Modes:: Describing the size and format of a datum. 13927* Constants:: Expressions with constant values. 13928* Regs and Memory:: Expressions representing register contents or memory. 13929* Arithmetic:: Expressions representing arithmetic on other expressions. 13930* Comparisons:: Expressions representing comparison of expressions. 13931* Bit-Fields:: Expressions representing bit-fields in memory or reg. 13932* Vector Operations:: Expressions involving vector datatypes. 13933* Conversions:: Extending, truncating, floating or fixing. 13934* RTL Declarations:: Declaring volatility, constancy, etc. 13935* Side Effects:: Expressions for storing in registers, etc. 13936* Incdec:: Embedded side-effects for autoincrement addressing. 13937* Assembler:: Representing `asm' with operands. 13938* Debug Information:: Expressions representing debugging information. 13939* Insns:: Expression types for entire insns. 13940* Calls:: RTL representation of function call insns. 13941* Sharing:: Some expressions are unique; others *must* be copied. 13942* Reading RTL:: Reading textual RTL from a file. 13943 13944 13945File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL 13946 1394713.1 RTL Object Types 13948===================== 13949 13950RTL uses five kinds of objects: expressions, integers, wide integers, 13951strings and vectors. Expressions are the most important ones. An RTL 13952expression ("RTX", for short) is a C structure, but it is usually 13953referred to with a pointer; a type that is given the typedef name `rtx'. 13954 13955 An integer is simply an `int'; their written form uses decimal digits. 13956A wide integer is an integral object whose type is `HOST_WIDE_INT'; 13957their written form uses decimal digits. 13958 13959 A string is a sequence of characters. In core it is represented as a 13960`char *' in usual C fashion, and it is written in C syntax as well. 13961However, strings in RTL may never be null. If you write an empty 13962string in a machine description, it is represented in core as a null 13963pointer rather than as a pointer to a null character. In certain 13964contexts, these null pointers instead of strings are valid. Within RTL 13965code, strings are most commonly found inside `symbol_ref' expressions, 13966but they appear in other contexts in the RTL expressions that make up 13967machine descriptions. 13968 13969 In a machine description, strings are normally written with double 13970quotes, as you would in C. However, strings in machine descriptions may 13971extend over many lines, which is invalid C, and adjacent string 13972constants are not concatenated as they are in C. Any string constant 13973may be surrounded with a single set of parentheses. Sometimes this 13974makes the machine description easier to read. 13975 13976 There is also a special syntax for strings, which can be useful when C 13977code is embedded in a machine description. Wherever a string can 13978appear, it is also valid to write a C-style brace block. The entire 13979brace block, including the outermost pair of braces, is considered to be 13980the string constant. Double quote characters inside the braces are not 13981special. Therefore, if you write string constants in the C code, you 13982need not escape each quote character with a backslash. 13983 13984 A vector contains an arbitrary number of pointers to expressions. The 13985number of elements in the vector is explicitly present in the vector. 13986The written form of a vector consists of square brackets (`[...]') 13987surrounding the elements, in sequence and with whitespace separating 13988them. Vectors of length zero are not created; null pointers are used 13989instead. 13990 13991 Expressions are classified by "expression codes" (also called RTX 13992codes). The expression code is a name defined in `rtl.def', which is 13993also (in uppercase) a C enumeration constant. The possible expression 13994codes and their meanings are machine-independent. The code of an RTX 13995can be extracted with the macro `GET_CODE (X)' and altered with 13996`PUT_CODE (X, NEWCODE)'. 13997 13998 The expression code determines how many operands the expression 13999contains, and what kinds of objects they are. In RTL, unlike Lisp, you 14000cannot tell by looking at an operand what kind of object it is. 14001Instead, you must know from its context--from the expression code of 14002the containing expression. For example, in an expression of code 14003`subreg', the first operand is to be regarded as an expression and the 14004second operand as an integer. In an expression of code `plus', there 14005are two operands, both of which are to be regarded as expressions. In 14006a `symbol_ref' expression, there is one operand, which is to be 14007regarded as a string. 14008 14009 Expressions are written as parentheses containing the name of the 14010expression type, its flags and machine mode if any, and then the 14011operands of the expression (separated by spaces). 14012 14013 Expression code names in the `md' file are written in lowercase, but 14014when they appear in C code they are written in uppercase. In this 14015manual, they are shown as follows: `const_int'. 14016 14017 In a few contexts a null pointer is valid where an expression is 14018normally wanted. The written form of this is `(nil)'. 14019 14020 14021File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL 14022 1402313.2 RTL Classes and Formats 14024============================ 14025 14026The various expression codes are divided into several "classes", which 14027are represented by single characters. You can determine the class of 14028an RTX code with the macro `GET_RTX_CLASS (CODE)'. Currently, 14029`rtl.def' defines these classes: 14030 14031`RTX_OBJ' 14032 An RTX code that represents an actual object, such as a register 14033 (`REG') or a memory location (`MEM', `SYMBOL_REF'). `LO_SUM') is 14034 also included; instead, `SUBREG' and `STRICT_LOW_PART' are not in 14035 this class, but in class `x'. 14036 14037`RTX_CONST_OBJ' 14038 An RTX code that represents a constant object. `HIGH' is also 14039 included in this class. 14040 14041`RTX_COMPARE' 14042 An RTX code for a non-symmetric comparison, such as `GEU' or `LT'. 14043 14044`RTX_COMM_COMPARE' 14045 An RTX code for a symmetric (commutative) comparison, such as `EQ' 14046 or `ORDERED'. 14047 14048`RTX_UNARY' 14049 An RTX code for a unary arithmetic operation, such as `NEG', 14050 `NOT', or `ABS'. This category also includes value extension 14051 (sign or zero) and conversions between integer and floating point. 14052 14053`RTX_COMM_ARITH' 14054 An RTX code for a commutative binary operation, such as `PLUS' or 14055 `AND'. `NE' and `EQ' are comparisons, so they have class `<'. 14056 14057`RTX_BIN_ARITH' 14058 An RTX code for a non-commutative binary operation, such as 14059 `MINUS', `DIV', or `ASHIFTRT'. 14060 14061`RTX_BITFIELD_OPS' 14062 An RTX code for a bit-field operation. Currently only 14063 `ZERO_EXTRACT' and `SIGN_EXTRACT'. These have three inputs and 14064 are lvalues (so they can be used for insertion as well). *Note 14065 Bit-Fields::. 14066 14067`RTX_TERNARY' 14068 An RTX code for other three input operations. Currently only 14069 `IF_THEN_ELSE', `VEC_MERGE', `SIGN_EXTRACT', `ZERO_EXTRACT', and 14070 `FMA'. 14071 14072`RTX_INSN' 14073 An RTX code for an entire instruction: `INSN', `JUMP_INSN', and 14074 `CALL_INSN'. *Note Insns::. 14075 14076`RTX_MATCH' 14077 An RTX code for something that matches in insns, such as 14078 `MATCH_DUP'. These only occur in machine descriptions. 14079 14080`RTX_AUTOINC' 14081 An RTX code for an auto-increment addressing mode, such as 14082 `POST_INC'. `XEXP (X, 0)' gives the auto-modified register. 14083 14084`RTX_EXTRA' 14085 All other RTX codes. This category includes the remaining codes 14086 used only in machine descriptions (`DEFINE_*', etc.). It also 14087 includes all the codes describing side effects (`SET', `USE', 14088 `CLOBBER', etc.) and the non-insns that may appear on an insn 14089 chain, such as `NOTE', `BARRIER', and `CODE_LABEL'. `SUBREG' is 14090 also part of this class. 14091 14092 For each expression code, `rtl.def' specifies the number of contained 14093objects and their kinds using a sequence of characters called the 14094"format" of the expression code. For example, the format of `subreg' 14095is `ei'. 14096 14097 These are the most commonly used format characters: 14098 14099`e' 14100 An expression (actually a pointer to an expression). 14101 14102`i' 14103 An integer. 14104 14105`w' 14106 A wide integer. 14107 14108`s' 14109 A string. 14110 14111`E' 14112 A vector of expressions. 14113 14114 A few other format characters are used occasionally: 14115 14116`u' 14117 `u' is equivalent to `e' except that it is printed differently in 14118 debugging dumps. It is used for pointers to insns. 14119 14120`n' 14121 `n' is equivalent to `i' except that it is printed differently in 14122 debugging dumps. It is used for the line number or code number of 14123 a `note' insn. 14124 14125`S' 14126 `S' indicates a string which is optional. In the RTL objects in 14127 core, `S' is equivalent to `s', but when the object is read, from 14128 an `md' file, the string value of this operand may be omitted. An 14129 omitted string is taken to be the null string. 14130 14131`V' 14132 `V' indicates a vector which is optional. In the RTL objects in 14133 core, `V' is equivalent to `E', but when the object is read from 14134 an `md' file, the vector value of this operand may be omitted. An 14135 omitted vector is effectively the same as a vector of no elements. 14136 14137`B' 14138 `B' indicates a pointer to basic block structure. 14139 14140`0' 14141 `0' means a slot whose contents do not fit any normal category. 14142 `0' slots are not printed at all in dumps, and are often used in 14143 special ways by small parts of the compiler. 14144 14145 There are macros to get the number of operands and the format of an 14146expression code: 14147 14148`GET_RTX_LENGTH (CODE)' 14149 Number of operands of an RTX of code CODE. 14150 14151`GET_RTX_FORMAT (CODE)' 14152 The format of an RTX of code CODE, as a C string. 14153 14154 Some classes of RTX codes always have the same format. For example, it 14155is safe to assume that all comparison operations have format `ee'. 14156 14157`1' 14158 All codes of this class have format `e'. 14159 14160`<' 14161`c' 14162`2' 14163 All codes of these classes have format `ee'. 14164 14165`b' 14166`3' 14167 All codes of these classes have format `eee'. 14168 14169`i' 14170 All codes of this class have formats that begin with `iuueiee'. 14171 *Note Insns::. Note that not all RTL objects linked onto an insn 14172 chain are of class `i'. 14173 14174`o' 14175`m' 14176`x' 14177 You can make no assumptions about the format of these codes. 14178 14179 14180File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL 14181 1418213.3 Access to Operands 14183======================= 14184 14185Operands of expressions are accessed using the macros `XEXP', `XINT', 14186`XWINT' and `XSTR'. Each of these macros takes two arguments: an 14187expression-pointer (RTX) and an operand number (counting from zero). 14188Thus, 14189 14190 XEXP (X, 2) 14191 14192accesses operand 2 of expression X, as an expression. 14193 14194 XINT (X, 2) 14195 14196accesses the same operand as an integer. `XSTR', used in the same 14197fashion, would access it as a string. 14198 14199 Any operand can be accessed as an integer, as an expression or as a 14200string. You must choose the correct method of access for the kind of 14201value actually stored in the operand. You would do this based on the 14202expression code of the containing expression. That is also how you 14203would know how many operands there are. 14204 14205 For example, if X is a `subreg' expression, you know that it has two 14206operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X, 142071)'. If you did `XINT (X, 0)', you would get the address of the 14208expression operand but cast as an integer; that might occasionally be 14209useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP 14210(X, 1)' would also compile without error, and would return the second, 14211integer operand cast as an expression pointer, which would probably 14212result in a crash when accessed. Nothing stops you from writing `XEXP 14213(X, 28)' either, but this will access memory past the end of the 14214expression with unpredictable results. 14215 14216 Access to operands which are vectors is more complicated. You can use 14217the macro `XVEC' to get the vector-pointer itself, or the macros 14218`XVECEXP' and `XVECLEN' to access the elements and length of a vector. 14219 14220`XVEC (EXP, IDX)' 14221 Access the vector-pointer which is operand number IDX in EXP. 14222 14223`XVECLEN (EXP, IDX)' 14224 Access the length (number of elements) in the vector which is in 14225 operand number IDX in EXP. This value is an `int'. 14226 14227`XVECEXP (EXP, IDX, ELTNUM)' 14228 Access element number ELTNUM in the vector which is in operand 14229 number IDX in EXP. This value is an RTX. 14230 14231 It is up to you to make sure that ELTNUM is not negative and is 14232 less than `XVECLEN (EXP, IDX)'. 14233 14234 All the macros defined in this section expand into lvalues and 14235therefore can be used to assign the operands, lengths and vector 14236elements as well as to access them. 14237 14238 14239File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL 14240 1424113.4 Access to Special Operands 14242=============================== 14243 14244Some RTL nodes have special annotations associated with them. 14245 14246`MEM' 14247 14248 `MEM_ALIAS_SET (X)' 14249 If 0, X is not in any alias set, and may alias anything. 14250 Otherwise, X can only alias `MEM's in a conflicting alias 14251 set. This value is set in a language-dependent manner in the 14252 front-end, and should not be altered in the back-end. In 14253 some front-ends, these numbers may correspond in some way to 14254 types, or other language-level entities, but they need not, 14255 and the back-end makes no such assumptions. These set 14256 numbers are tested with `alias_sets_conflict_p'. 14257 14258 `MEM_EXPR (X)' 14259 If this register is known to hold the value of some user-level 14260 declaration, this is that tree node. It may also be a 14261 `COMPONENT_REF', in which case this is some field reference, 14262 and `TREE_OPERAND (X, 0)' contains the declaration, or 14263 another `COMPONENT_REF', or null if there is no compile-time 14264 object associated with the reference. 14265 14266 `MEM_OFFSET_KNOWN_P (X)' 14267 True if the offset of the memory reference from `MEM_EXPR' is 14268 known. `MEM_OFFSET (X)' provides the offset if so. 14269 14270 `MEM_OFFSET (X)' 14271 The offset from the start of `MEM_EXPR'. The value is only 14272 valid if `MEM_OFFSET_KNOWN_P (X)' is true. 14273 14274 `MEM_SIZE_KNOWN_P (X)' 14275 True if the size of the memory reference is known. `MEM_SIZE 14276 (X)' provides its size if so. 14277 14278 `MEM_SIZE (X)' 14279 The size in bytes of the memory reference. This is mostly 14280 relevant for `BLKmode' references as otherwise the size is 14281 implied by the mode. The value is only valid if 14282 `MEM_SIZE_KNOWN_P (X)' is true. 14283 14284 `MEM_ALIGN (X)' 14285 The known alignment in bits of the memory reference. 14286 14287 `MEM_ADDR_SPACE (X)' 14288 The address space of the memory reference. This will 14289 commonly be zero for the generic address space. 14290 14291`REG' 14292 14293 `ORIGINAL_REGNO (X)' 14294 This field holds the number the register "originally" had; 14295 for a pseudo register turned into a hard reg this will hold 14296 the old pseudo register number. 14297 14298 `REG_EXPR (X)' 14299 If this register is known to hold the value of some user-level 14300 declaration, this is that tree node. 14301 14302 `REG_OFFSET (X)' 14303 If this register is known to hold the value of some user-level 14304 declaration, this is the offset into that logical storage. 14305 14306`SYMBOL_REF' 14307 14308 `SYMBOL_REF_DECL (X)' 14309 If the `symbol_ref' X was created for a `VAR_DECL' or a 14310 `FUNCTION_DECL', that tree is recorded here. If this value is 14311 null, then X was created by back end code generation routines, 14312 and there is no associated front end symbol table entry. 14313 14314 `SYMBOL_REF_DECL' may also point to a tree of class `'c'', 14315 that is, some sort of constant. In this case, the 14316 `symbol_ref' is an entry in the per-file constant pool; 14317 again, there is no associated front end symbol table entry. 14318 14319 `SYMBOL_REF_CONSTANT (X)' 14320 If `CONSTANT_POOL_ADDRESS_P (X)' is true, this is the constant 14321 pool entry for X. It is null otherwise. 14322 14323 `SYMBOL_REF_DATA (X)' 14324 A field of opaque type used to store `SYMBOL_REF_DECL' or 14325 `SYMBOL_REF_CONSTANT'. 14326 14327 `SYMBOL_REF_FLAGS (X)' 14328 In a `symbol_ref', this is used to communicate various 14329 predicates about the symbol. Some of these are common enough 14330 to be computed by common code, some are specific to the 14331 target. The common bits are: 14332 14333 `SYMBOL_FLAG_FUNCTION' 14334 Set if the symbol refers to a function. 14335 14336 `SYMBOL_FLAG_LOCAL' 14337 Set if the symbol is local to this "module". See 14338 `TARGET_BINDS_LOCAL_P'. 14339 14340 `SYMBOL_FLAG_EXTERNAL' 14341 Set if this symbol is not defined in this translation 14342 unit. Note that this is not the inverse of 14343 `SYMBOL_FLAG_LOCAL'. 14344 14345 `SYMBOL_FLAG_SMALL' 14346 Set if the symbol is located in the small data section. 14347 See `TARGET_IN_SMALL_DATA_P'. 14348 14349 `SYMBOL_REF_TLS_MODEL (X)' 14350 This is a multi-bit field accessor that returns the 14351 `tls_model' to be used for a thread-local storage 14352 symbol. It returns zero for non-thread-local symbols. 14353 14354 `SYMBOL_FLAG_HAS_BLOCK_INFO' 14355 Set if the symbol has `SYMBOL_REF_BLOCK' and 14356 `SYMBOL_REF_BLOCK_OFFSET' fields. 14357 14358 `SYMBOL_FLAG_ANCHOR' 14359 Set if the symbol is used as a section anchor. "Section 14360 anchors" are symbols that have a known position within 14361 an `object_block' and that can be used to access nearby 14362 members of that block. They are used to implement 14363 `-fsection-anchors'. 14364 14365 If this flag is set, then `SYMBOL_FLAG_HAS_BLOCK_INFO' 14366 will be too. 14367 14368 Bits beginning with `SYMBOL_FLAG_MACH_DEP' are available for 14369 the target's use. 14370 14371`SYMBOL_REF_BLOCK (X)' 14372 If `SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the `object_block' 14373 structure to which the symbol belongs, or `NULL' if it has not 14374 been assigned a block. 14375 14376`SYMBOL_REF_BLOCK_OFFSET (X)' 14377 If `SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the offset of X from 14378 the first object in `SYMBOL_REF_BLOCK (X)'. The value is negative 14379 if X has not yet been assigned to a block, or it has not been 14380 given an offset within that block. 14381 14382 14383File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL 14384 1438513.5 Flags in an RTL Expression 14386=============================== 14387 14388RTL expressions contain several flags (one-bit bit-fields) that are 14389used in certain types of expression. Most often they are accessed with 14390the following macros, which expand into lvalues. 14391 14392`CONSTANT_POOL_ADDRESS_P (X)' 14393 Nonzero in a `symbol_ref' if it refers to part of the current 14394 function's constant pool. For most targets these addresses are in 14395 a `.rodata' section entirely separate from the function, but for 14396 some targets the addresses are close to the beginning of the 14397 function. In either case GCC assumes these addresses can be 14398 addressed directly, perhaps with the help of base registers. 14399 Stored in the `unchanging' field and printed as `/u'. 14400 14401`RTL_CONST_CALL_P (X)' 14402 In a `call_insn' indicates that the insn represents a call to a 14403 const function. Stored in the `unchanging' field and printed as 14404 `/u'. 14405 14406`RTL_PURE_CALL_P (X)' 14407 In a `call_insn' indicates that the insn represents a call to a 14408 pure function. Stored in the `return_val' field and printed as 14409 `/i'. 14410 14411`RTL_CONST_OR_PURE_CALL_P (X)' 14412 In a `call_insn', true if `RTL_CONST_CALL_P' or `RTL_PURE_CALL_P' 14413 is true. 14414 14415`RTL_LOOPING_CONST_OR_PURE_CALL_P (X)' 14416 In a `call_insn' indicates that the insn represents a possibly 14417 infinite looping call to a const or pure function. Stored in the 14418 `call' field and printed as `/c'. Only true if one of 14419 `RTL_CONST_CALL_P' or `RTL_PURE_CALL_P' is true. 14420 14421`INSN_ANNULLED_BRANCH_P (X)' 14422 In a `jump_insn', `call_insn', or `insn' indicates that the branch 14423 is an annulling one. See the discussion under `sequence' below. 14424 Stored in the `unchanging' field and printed as `/u'. 14425 14426`INSN_DELETED_P (X)' 14427 In an `insn', `call_insn', `jump_insn', `code_label', 14428 `jump_table_data', `barrier', or `note', nonzero if the insn has 14429 been deleted. Stored in the `volatil' field and printed as `/v'. 14430 14431`INSN_FROM_TARGET_P (X)' 14432 In an `insn' or `jump_insn' or `call_insn' in a delay slot of a 14433 branch, indicates that the insn is from the target of the branch. 14434 If the branch insn has `INSN_ANNULLED_BRANCH_P' set, this insn 14435 will only be executed if the branch is taken. For annulled 14436 branches with `INSN_FROM_TARGET_P' clear, the insn will be 14437 executed only if the branch is not taken. When 14438 `INSN_ANNULLED_BRANCH_P' is not set, this insn will always be 14439 executed. Stored in the `in_struct' field and printed as `/s'. 14440 14441`LABEL_PRESERVE_P (X)' 14442 In a `code_label' or `note', indicates that the label is 14443 referenced by code or data not visible to the RTL of a given 14444 function. Labels referenced by a non-local goto will have this 14445 bit set. Stored in the `in_struct' field and printed as `/s'. 14446 14447`LABEL_REF_NONLOCAL_P (X)' 14448 In `label_ref' and `reg_label' expressions, nonzero if this is a 14449 reference to a non-local label. Stored in the `volatil' field and 14450 printed as `/v'. 14451 14452`MEM_KEEP_ALIAS_SET_P (X)' 14453 In `mem' expressions, 1 if we should keep the alias set for this 14454 mem unchanged when we access a component. Set to 1, for example, 14455 when we are already in a non-addressable component of an aggregate. 14456 Stored in the `jump' field and printed as `/j'. 14457 14458`MEM_VOLATILE_P (X)' 14459 In `mem', `asm_operands', and `asm_input' expressions, nonzero for 14460 volatile memory references. Stored in the `volatil' field and 14461 printed as `/v'. 14462 14463`MEM_NOTRAP_P (X)' 14464 In `mem', nonzero for memory references that will not trap. 14465 Stored in the `call' field and printed as `/c'. 14466 14467`MEM_POINTER (X)' 14468 Nonzero in a `mem' if the memory reference holds a pointer. 14469 Stored in the `frame_related' field and printed as `/f'. 14470 14471`REG_FUNCTION_VALUE_P (X)' 14472 Nonzero in a `reg' if it is the place in which this function's 14473 value is going to be returned. (This happens only in a hard 14474 register.) Stored in the `return_val' field and printed as `/i'. 14475 14476`REG_POINTER (X)' 14477 Nonzero in a `reg' if the register holds a pointer. Stored in the 14478 `frame_related' field and printed as `/f'. 14479 14480`REG_USERVAR_P (X)' 14481 In a `reg', nonzero if it corresponds to a variable present in the 14482 user's source code. Zero for temporaries generated internally by 14483 the compiler. Stored in the `volatil' field and printed as `/v'. 14484 14485 The same hard register may be used also for collecting the values 14486 of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero 14487 in this kind of use. 14488 14489`RTX_FRAME_RELATED_P (X)' 14490 Nonzero in an `insn', `call_insn', `jump_insn', `barrier', or 14491 `set' which is part of a function prologue and sets the stack 14492 pointer, sets the frame pointer, or saves a register. This flag 14493 should also be set on an instruction that sets up a temporary 14494 register to use in place of the frame pointer. Stored in the 14495 `frame_related' field and printed as `/f'. 14496 14497 In particular, on RISC targets where there are limits on the sizes 14498 of immediate constants, it is sometimes impossible to reach the 14499 register save area directly from the stack pointer. In that case, 14500 a temporary register is used that is near enough to the register 14501 save area, and the Canonical Frame Address, i.e., DWARF2's logical 14502 frame pointer, register must (temporarily) be changed to be this 14503 temporary register. So, the instruction that sets this temporary 14504 register must be marked as `RTX_FRAME_RELATED_P'. 14505 14506 If the marked instruction is overly complex (defined in terms of 14507 what `dwarf2out_frame_debug_expr' can handle), you will also have 14508 to create a `REG_FRAME_RELATED_EXPR' note and attach it to the 14509 instruction. This note should contain a simple expression of the 14510 computation performed by this instruction, i.e., one that 14511 `dwarf2out_frame_debug_expr' can handle. 14512 14513 This flag is required for exception handling support on targets 14514 with RTL prologues. 14515 14516`MEM_READONLY_P (X)' 14517 Nonzero in a `mem', if the memory is statically allocated and 14518 read-only. 14519 14520 Read-only in this context means never modified during the lifetime 14521 of the program, not necessarily in ROM or in write-disabled pages. 14522 A common example of the later is a shared library's global offset 14523 table. This table is initialized by the runtime loader, so the 14524 memory is technically writable, but after control is transferred 14525 from the runtime loader to the application, this memory will never 14526 be subsequently modified. 14527 14528 Stored in the `unchanging' field and printed as `/u'. 14529 14530`SCHED_GROUP_P (X)' 14531 During instruction scheduling, in an `insn', `call_insn', 14532 `jump_insn' or `jump_table_data', indicates that the previous insn 14533 must be scheduled together with this insn. This is used to ensure 14534 that certain groups of instructions will not be split up by the 14535 instruction scheduling pass, for example, `use' insns before a 14536 `call_insn' may not be separated from the `call_insn'. Stored in 14537 the `in_struct' field and printed as `/s'. 14538 14539`SET_IS_RETURN_P (X)' 14540 For a `set', nonzero if it is for a return. Stored in the `jump' 14541 field and printed as `/j'. 14542 14543`SIBLING_CALL_P (X)' 14544 For a `call_insn', nonzero if the insn is a sibling call. Stored 14545 in the `jump' field and printed as `/j'. 14546 14547`STRING_POOL_ADDRESS_P (X)' 14548 For a `symbol_ref' expression, nonzero if it addresses this 14549 function's string constant pool. Stored in the `frame_related' 14550 field and printed as `/f'. 14551 14552`SUBREG_PROMOTED_UNSIGNED_P (X)' 14553 Returns a value greater then zero for a `subreg' that has 14554 `SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is 14555 kept zero-extended, zero if it is kept sign-extended, and less 14556 then zero if it is extended some other way via the `ptr_extend' 14557 instruction. Stored in the `unchanging' field and `volatil' 14558 field, printed as `/u' and `/v'. This macro may only be used to 14559 get the value it may not be used to change the value. Use 14560 `SUBREG_PROMOTED_UNSIGNED_SET' to change the value. 14561 14562`SUBREG_PROMOTED_UNSIGNED_SET (X)' 14563 Set the `unchanging' and `volatil' fields in a `subreg' to reflect 14564 zero, sign, or other extension. If `volatil' is zero, then 14565 `unchanging' as nonzero means zero extension and as zero means 14566 sign extension. If `volatil' is nonzero then some other type of 14567 extension was done via the `ptr_extend' instruction. 14568 14569`SUBREG_PROMOTED_VAR_P (X)' 14570 Nonzero in a `subreg' if it was made when accessing an object that 14571 was promoted to a wider mode in accord with the `PROMOTED_MODE' 14572 machine description macro (*note Storage Layout::). In this case, 14573 the mode of the `subreg' is the declared mode of the object and 14574 the mode of `SUBREG_REG' is the mode of the register that holds 14575 the object. Promoted variables are always either sign- or 14576 zero-extended to the wider mode on every assignment. Stored in 14577 the `in_struct' field and printed as `/s'. 14578 14579`SYMBOL_REF_USED (X)' 14580 In a `symbol_ref', indicates that X has been used. This is 14581 normally only used to ensure that X is only declared external 14582 once. Stored in the `used' field. 14583 14584`SYMBOL_REF_WEAK (X)' 14585 In a `symbol_ref', indicates that X has been declared weak. 14586 Stored in the `return_val' field and printed as `/i'. 14587 14588`SYMBOL_REF_FLAG (X)' 14589 In a `symbol_ref', this is used as a flag for machine-specific 14590 purposes. Stored in the `volatil' field and printed as `/v'. 14591 14592 Most uses of `SYMBOL_REF_FLAG' are historic and may be subsumed by 14593 `SYMBOL_REF_FLAGS'. Certainly use of `SYMBOL_REF_FLAGS' is 14594 mandatory if the target requires more than one bit of storage. 14595 14596`PREFETCH_SCHEDULE_BARRIER_P (X)' 14597 In a `prefetch', indicates that the prefetch is a scheduling 14598 barrier. No other INSNs will be moved over it. Stored in the 14599 `volatil' field and printed as `/v'. 14600 14601 These are the fields to which the above macros refer: 14602 14603`call' 14604 In a `mem', 1 means that the memory reference will not trap. 14605 14606 In a `call', 1 means that this pure or const call may possibly 14607 infinite loop. 14608 14609 In an RTL dump, this flag is represented as `/c'. 14610 14611`frame_related' 14612 In an `insn' or `set' expression, 1 means that it is part of a 14613 function prologue and sets the stack pointer, sets the frame 14614 pointer, saves a register, or sets up a temporary register to use 14615 in place of the frame pointer. 14616 14617 In `reg' expressions, 1 means that the register holds a pointer. 14618 14619 In `mem' expressions, 1 means that the memory reference holds a 14620 pointer. 14621 14622 In `symbol_ref' expressions, 1 means that the reference addresses 14623 this function's string constant pool. 14624 14625 In an RTL dump, this flag is represented as `/f'. 14626 14627`in_struct' 14628 In `reg' expressions, it is 1 if the register has its entire life 14629 contained within the test expression of some loop. 14630 14631 In `subreg' expressions, 1 means that the `subreg' is accessing an 14632 object that has had its mode promoted from a wider mode. 14633 14634 In `label_ref' expressions, 1 means that the referenced label is 14635 outside the innermost loop containing the insn in which the 14636 `label_ref' was found. 14637 14638 In `code_label' expressions, it is 1 if the label may never be 14639 deleted. This is used for labels which are the target of 14640 non-local gotos. Such a label that would have been deleted is 14641 replaced with a `note' of type `NOTE_INSN_DELETED_LABEL'. 14642 14643 In an `insn' during dead-code elimination, 1 means that the insn is 14644 dead code. 14645 14646 In an `insn' or `jump_insn' during reorg for an insn in the delay 14647 slot of a branch, 1 means that this insn is from the target of the 14648 branch. 14649 14650 In an `insn' during instruction scheduling, 1 means that this insn 14651 must be scheduled as part of a group together with the previous 14652 insn. 14653 14654 In an RTL dump, this flag is represented as `/s'. 14655 14656`return_val' 14657 In `reg' expressions, 1 means the register contains the value to 14658 be returned by the current function. On machines that pass 14659 parameters in registers, the same register number may be used for 14660 parameters as well, but this flag is not set on such uses. 14661 14662 In `symbol_ref' expressions, 1 means the referenced symbol is weak. 14663 14664 In `call' expressions, 1 means the call is pure. 14665 14666 In an RTL dump, this flag is represented as `/i'. 14667 14668`jump' 14669 In a `mem' expression, 1 means we should keep the alias set for 14670 this mem unchanged when we access a component. 14671 14672 In a `set', 1 means it is for a return. 14673 14674 In a `call_insn', 1 means it is a sibling call. 14675 14676 In an RTL dump, this flag is represented as `/j'. 14677 14678`unchanging' 14679 In `reg' and `mem' expressions, 1 means that the value of the 14680 expression never changes. 14681 14682 In `subreg' expressions, it is 1 if the `subreg' references an 14683 unsigned object whose mode has been promoted to a wider mode. 14684 14685 In an `insn' or `jump_insn' in the delay slot of a branch 14686 instruction, 1 means an annulling branch should be used. 14687 14688 In a `symbol_ref' expression, 1 means that this symbol addresses 14689 something in the per-function constant pool. 14690 14691 In a `call_insn' 1 means that this instruction is a call to a const 14692 function. 14693 14694 In an RTL dump, this flag is represented as `/u'. 14695 14696`used' 14697 This flag is used directly (without an access macro) at the end of 14698 RTL generation for a function, to count the number of times an 14699 expression appears in insns. Expressions that appear more than 14700 once are copied, according to the rules for shared structure 14701 (*note Sharing::). 14702 14703 For a `reg', it is used directly (without an access macro) by the 14704 leaf register renumbering code to ensure that each register is only 14705 renumbered once. 14706 14707 In a `symbol_ref', it indicates that an external declaration for 14708 the symbol has already been written. 14709 14710`volatil' 14711 In a `mem', `asm_operands', or `asm_input' expression, it is 1 if 14712 the memory reference is volatile. Volatile memory references may 14713 not be deleted, reordered or combined. 14714 14715 In a `symbol_ref' expression, it is used for machine-specific 14716 purposes. 14717 14718 In a `reg' expression, it is 1 if the value is a user-level 14719 variable. 0 indicates an internal compiler temporary. 14720 14721 In an `insn', 1 means the insn has been deleted. 14722 14723 In `label_ref' and `reg_label' expressions, 1 means a reference to 14724 a non-local label. 14725 14726 In `prefetch' expressions, 1 means that the containing insn is a 14727 scheduling barrier. 14728 14729 In an RTL dump, this flag is represented as `/v'. 14730 14731 14732File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL 14733 1473413.6 Machine Modes 14735================== 14736 14737A machine mode describes a size of data object and the representation 14738used for it. In the C code, machine modes are represented by an 14739enumeration type, `machine_mode', defined in `machmode.def'. Each RTL 14740expression has room for a machine mode and so do certain kinds of tree 14741expressions (declarations and types, to be precise). 14742 14743 In debugging dumps and machine descriptions, the machine mode of an RTL 14744expression is written after the expression code with a colon to separate 14745them. The letters `mode' which appear at the end of each machine mode 14746name are omitted. For example, `(reg:SI 38)' is a `reg' expression 14747with machine mode `SImode'. If the mode is `VOIDmode', it is not 14748written at all. 14749 14750 Here is a table of machine modes. The term "byte" below refers to an 14751object of `BITS_PER_UNIT' bits (*note Storage Layout::). 14752 14753`BImode' 14754 "Bit" mode represents a single bit, for predicate registers. 14755 14756`QImode' 14757 "Quarter-Integer" mode represents a single byte treated as an 14758 integer. 14759 14760`HImode' 14761 "Half-Integer" mode represents a two-byte integer. 14762 14763`PSImode' 14764 "Partial Single Integer" mode represents an integer which occupies 14765 four bytes but which doesn't really use all four. On some 14766 machines, this is the right mode to use for pointers. 14767 14768`SImode' 14769 "Single Integer" mode represents a four-byte integer. 14770 14771`PDImode' 14772 "Partial Double Integer" mode represents an integer which occupies 14773 eight bytes but which doesn't really use all eight. On some 14774 machines, this is the right mode to use for certain pointers. 14775 14776`DImode' 14777 "Double Integer" mode represents an eight-byte integer. 14778 14779`TImode' 14780 "Tetra Integer" (?) mode represents a sixteen-byte integer. 14781 14782`OImode' 14783 "Octa Integer" (?) mode represents a thirty-two-byte integer. 14784 14785`XImode' 14786 "Hexadeca Integer" (?) mode represents a sixty-four-byte integer. 14787 14788`QFmode' 14789 "Quarter-Floating" mode represents a quarter-precision (single 14790 byte) floating point number. 14791 14792`HFmode' 14793 "Half-Floating" mode represents a half-precision (two byte) 14794 floating point number. 14795 14796`TQFmode' 14797 "Three-Quarter-Floating" (?) mode represents a 14798 three-quarter-precision (three byte) floating point number. 14799 14800`SFmode' 14801 "Single Floating" mode represents a four byte floating point 14802 number. In the common case, of a processor with IEEE arithmetic 14803 and 8-bit bytes, this is a single-precision IEEE floating point 14804 number; it can also be used for double-precision (on processors 14805 with 16-bit bytes) and single-precision VAX and IBM types. 14806 14807`DFmode' 14808 "Double Floating" mode represents an eight byte floating point 14809 number. In the common case, of a processor with IEEE arithmetic 14810 and 8-bit bytes, this is a double-precision IEEE floating point 14811 number. 14812 14813`XFmode' 14814 "Extended Floating" mode represents an IEEE extended floating point 14815 number. This mode only has 80 meaningful bits (ten bytes). Some 14816 processors require such numbers to be padded to twelve bytes, 14817 others to sixteen; this mode is used for either. 14818 14819`SDmode' 14820 "Single Decimal Floating" mode represents a four byte decimal 14821 floating point number (as distinct from conventional binary 14822 floating point). 14823 14824`DDmode' 14825 "Double Decimal Floating" mode represents an eight byte decimal 14826 floating point number. 14827 14828`TDmode' 14829 "Tetra Decimal Floating" mode represents a sixteen byte decimal 14830 floating point number all 128 of whose bits are meaningful. 14831 14832`TFmode' 14833 "Tetra Floating" mode represents a sixteen byte floating point 14834 number all 128 of whose bits are meaningful. One common use is the 14835 IEEE quad-precision format. 14836 14837`QQmode' 14838 "Quarter-Fractional" mode represents a single byte treated as a 14839 signed fractional number. The default format is "s.7". 14840 14841`HQmode' 14842 "Half-Fractional" mode represents a two-byte signed fractional 14843 number. The default format is "s.15". 14844 14845`SQmode' 14846 "Single Fractional" mode represents a four-byte signed fractional 14847 number. The default format is "s.31". 14848 14849`DQmode' 14850 "Double Fractional" mode represents an eight-byte signed 14851 fractional number. The default format is "s.63". 14852 14853`TQmode' 14854 "Tetra Fractional" mode represents a sixteen-byte signed 14855 fractional number. The default format is "s.127". 14856 14857`UQQmode' 14858 "Unsigned Quarter-Fractional" mode represents a single byte 14859 treated as an unsigned fractional number. The default format is 14860 ".8". 14861 14862`UHQmode' 14863 "Unsigned Half-Fractional" mode represents a two-byte unsigned 14864 fractional number. The default format is ".16". 14865 14866`USQmode' 14867 "Unsigned Single Fractional" mode represents a four-byte unsigned 14868 fractional number. The default format is ".32". 14869 14870`UDQmode' 14871 "Unsigned Double Fractional" mode represents an eight-byte unsigned 14872 fractional number. The default format is ".64". 14873 14874`UTQmode' 14875 "Unsigned Tetra Fractional" mode represents a sixteen-byte unsigned 14876 fractional number. The default format is ".128". 14877 14878`HAmode' 14879 "Half-Accumulator" mode represents a two-byte signed accumulator. 14880 The default format is "s8.7". 14881 14882`SAmode' 14883 "Single Accumulator" mode represents a four-byte signed 14884 accumulator. The default format is "s16.15". 14885 14886`DAmode' 14887 "Double Accumulator" mode represents an eight-byte signed 14888 accumulator. The default format is "s32.31". 14889 14890`TAmode' 14891 "Tetra Accumulator" mode represents a sixteen-byte signed 14892 accumulator. The default format is "s64.63". 14893 14894`UHAmode' 14895 "Unsigned Half-Accumulator" mode represents a two-byte unsigned 14896 accumulator. The default format is "8.8". 14897 14898`USAmode' 14899 "Unsigned Single Accumulator" mode represents a four-byte unsigned 14900 accumulator. The default format is "16.16". 14901 14902`UDAmode' 14903 "Unsigned Double Accumulator" mode represents an eight-byte 14904 unsigned accumulator. The default format is "32.32". 14905 14906`UTAmode' 14907 "Unsigned Tetra Accumulator" mode represents a sixteen-byte 14908 unsigned accumulator. The default format is "64.64". 14909 14910`CCmode' 14911 "Condition Code" mode represents the value of a condition code, 14912 which is a machine-specific set of bits used to represent the 14913 result of a comparison operation. Other machine-specific modes 14914 may also be used for the condition code. These modes are not used 14915 on machines that use `cc0' (*note Condition Code::). 14916 14917`BLKmode' 14918 "Block" mode represents values that are aggregates to which none of 14919 the other modes apply. In RTL, only memory references can have 14920 this mode, and only if they appear in string-move or vector 14921 instructions. On machines which have no such instructions, 14922 `BLKmode' will not appear in RTL. 14923 14924`VOIDmode' 14925 Void mode means the absence of a mode or an unspecified mode. For 14926 example, RTL expressions of code `const_int' have mode `VOIDmode' 14927 because they can be taken to have whatever mode the context 14928 requires. In debugging dumps of RTL, `VOIDmode' is expressed by 14929 the absence of any mode. 14930 14931`QCmode, HCmode, SCmode, DCmode, XCmode, TCmode' 14932 These modes stand for a complex number represented as a pair of 14933 floating point values. The floating point values are in `QFmode', 14934 `HFmode', `SFmode', `DFmode', `XFmode', and `TFmode', respectively. 14935 14936`CQImode, CHImode, CSImode, CDImode, CTImode, COImode' 14937 These modes stand for a complex number represented as a pair of 14938 integer values. The integer values are in `QImode', `HImode', 14939 `SImode', `DImode', `TImode', and `OImode', respectively. 14940 14941`BND32mode BND64mode' 14942 These modes stand for bounds for pointer of 32 and 64 bit size 14943 respectively. Mode size is double pointer mode size. 14944 14945 The machine description defines `Pmode' as a C macro which expands 14946into the machine mode used for addresses. Normally this is the mode 14947whose size is `BITS_PER_WORD', `SImode' on 32-bit machines. 14948 14949 The only modes which a machine description must support are `QImode', 14950and the modes corresponding to `BITS_PER_WORD', `FLOAT_TYPE_SIZE' and 14951`DOUBLE_TYPE_SIZE'. The compiler will attempt to use `DImode' for 149528-byte structures and unions, but this can be prevented by overriding 14953the definition of `MAX_FIXED_MODE_SIZE'. Alternatively, you can have 14954the compiler use `TImode' for 16-byte structures and unions. Likewise, 14955you can arrange for the C type `short int' to avoid using `HImode'. 14956 14957 Very few explicit references to machine modes remain in the compiler 14958and these few references will soon be removed. Instead, the machine 14959modes are divided into mode classes. These are represented by the 14960enumeration type `enum mode_class' defined in `machmode.h'. The 14961possible mode classes are: 14962 14963`MODE_INT' 14964 Integer modes. By default these are `BImode', `QImode', `HImode', 14965 `SImode', `DImode', `TImode', and `OImode'. 14966 14967`MODE_PARTIAL_INT' 14968 The "partial integer" modes, `PQImode', `PHImode', `PSImode' and 14969 `PDImode'. 14970 14971`MODE_FLOAT' 14972 Floating point modes. By default these are `QFmode', `HFmode', 14973 `TQFmode', `SFmode', `DFmode', `XFmode' and `TFmode'. 14974 14975`MODE_DECIMAL_FLOAT' 14976 Decimal floating point modes. By default these are `SDmode', 14977 `DDmode' and `TDmode'. 14978 14979`MODE_FRACT' 14980 Signed fractional modes. By default these are `QQmode', `HQmode', 14981 `SQmode', `DQmode' and `TQmode'. 14982 14983`MODE_UFRACT' 14984 Unsigned fractional modes. By default these are `UQQmode', 14985 `UHQmode', `USQmode', `UDQmode' and `UTQmode'. 14986 14987`MODE_ACCUM' 14988 Signed accumulator modes. By default these are `HAmode', 14989 `SAmode', `DAmode' and `TAmode'. 14990 14991`MODE_UACCUM' 14992 Unsigned accumulator modes. By default these are `UHAmode', 14993 `USAmode', `UDAmode' and `UTAmode'. 14994 14995`MODE_COMPLEX_INT' 14996 Complex integer modes. (These are not currently implemented). 14997 14998`MODE_COMPLEX_FLOAT' 14999 Complex floating point modes. By default these are `QCmode', 15000 `HCmode', `SCmode', `DCmode', `XCmode', and `TCmode'. 15001 15002`MODE_FUNCTION' 15003 Algol or Pascal function variables including a static chain. 15004 (These are not currently implemented). 15005 15006`MODE_CC' 15007 Modes representing condition code values. These are `CCmode' plus 15008 any `CC_MODE' modes listed in the `MACHINE-modes.def'. *Note Jump 15009 Patterns::, also see *note Condition Code::. 15010 15011`MODE_POINTER_BOUNDS' 15012 Pointer bounds modes. Used to represent values of pointer bounds 15013 type. Operations in these modes may be executed as NOPs depending 15014 on hardware features and environment setup. 15015 15016`MODE_RANDOM' 15017 This is a catchall mode class for modes which don't fit into the 15018 above classes. Currently `VOIDmode' and `BLKmode' are in 15019 `MODE_RANDOM'. 15020 15021 Here are some C macros that relate to machine modes: 15022 15023`GET_MODE (X)' 15024 Returns the machine mode of the RTX X. 15025 15026`PUT_MODE (X, NEWMODE)' 15027 Alters the machine mode of the RTX X to be NEWMODE. 15028 15029`NUM_MACHINE_MODES' 15030 Stands for the number of machine modes available on the target 15031 machine. This is one greater than the largest numeric value of any 15032 machine mode. 15033 15034`GET_MODE_NAME (M)' 15035 Returns the name of mode M as a string. 15036 15037`GET_MODE_CLASS (M)' 15038 Returns the mode class of mode M. 15039 15040`GET_MODE_WIDER_MODE (M)' 15041 Returns the next wider natural mode. For example, the expression 15042 `GET_MODE_WIDER_MODE (QImode)' returns `HImode'. 15043 15044`GET_MODE_SIZE (M)' 15045 Returns the size in bytes of a datum of mode M. 15046 15047`GET_MODE_BITSIZE (M)' 15048 Returns the size in bits of a datum of mode M. 15049 15050`GET_MODE_IBIT (M)' 15051 Returns the number of integral bits of a datum of fixed-point mode 15052 M. 15053 15054`GET_MODE_FBIT (M)' 15055 Returns the number of fractional bits of a datum of fixed-point 15056 mode M. 15057 15058`GET_MODE_MASK (M)' 15059 Returns a bitmask containing 1 for all bits in a word that fit 15060 within mode M. This macro can only be used for modes whose 15061 bitsize is less than or equal to `HOST_BITS_PER_INT'. 15062 15063`GET_MODE_ALIGNMENT (M)' 15064 Return the required alignment, in bits, for an object of mode M. 15065 15066`GET_MODE_UNIT_SIZE (M)' 15067 Returns the size in bytes of the subunits of a datum of mode M. 15068 This is the same as `GET_MODE_SIZE' except in the case of complex 15069 modes. For them, the unit size is the size of the real or 15070 imaginary part. 15071 15072`GET_MODE_NUNITS (M)' 15073 Returns the number of units contained in a mode, i.e., 15074 `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'. 15075 15076`GET_CLASS_NARROWEST_MODE (C)' 15077 Returns the narrowest mode in mode class C. 15078 15079 The following 3 variables are defined on every target. They can be 15080used to allocate buffers that are guaranteed to be large enough to hold 15081any value that can be represented on the target. The first two can be 15082overridden by defining them in the target's mode.def file, however, the 15083value must be a constant that can determined very early in the 15084compilation process. The third symbol cannot be overridden. 15085 15086`BITS_PER_UNIT' 15087 The number of bits in an addressable storage unit (byte). If you 15088 do not define this, the default is 8. 15089 15090`MAX_BITSIZE_MODE_ANY_INT' 15091 The maximum bitsize of any mode that is used in integer math. This 15092 should be overridden by the target if it uses large integers as 15093 containers for larger vectors but otherwise never uses the 15094 contents to compute integer values. 15095 15096`MAX_BITSIZE_MODE_ANY_MODE' 15097 The bitsize of the largest mode on the target. 15098 15099 The global variables `byte_mode' and `word_mode' contain modes whose 15100classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or 15101`BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode' 15102and `SImode', respectively. 15103 15104 15105File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL 15106 1510713.7 Constant Expression Types 15108============================== 15109 15110The simplest RTL expressions are those that represent constant values. 15111 15112`(const_int I)' 15113 This type of expression represents the integer value I. I is 15114 customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)', 15115 which is equivalent to `XWINT (EXP, 0)'. 15116 15117 Constants generated for modes with fewer bits than in 15118 `HOST_WIDE_INT' must be sign extended to full width (e.g., with 15119 `gen_int_mode'). For constants for modes with more bits than in 15120 `HOST_WIDE_INT' the implied high order bits of that constant are 15121 copies of the top bit. Note however that values are neither 15122 inherently signed nor inherently unsigned; where necessary, 15123 signedness is determined by the rtl operation instead. 15124 15125 There is only one expression object for the integer value zero; it 15126 is the value of the variable `const0_rtx'. Likewise, the only 15127 expression for integer value one is found in `const1_rtx', the only 15128 expression for integer value two is found in `const2_rtx', and the 15129 only expression for integer value negative one is found in 15130 `constm1_rtx'. Any attempt to create an expression of code 15131 `const_int' and value zero, one, two or negative one will return 15132 `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as 15133 appropriate. 15134 15135 Similarly, there is only one object for the integer whose value is 15136 `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If 15137 `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will 15138 point to the same object. If `STORE_FLAG_VALUE' is -1, 15139 `const_true_rtx' and `constm1_rtx' will point to the same object. 15140 15141`(const_double:M I0 I1 ...)' 15142 This represents either a floating-point constant of mode M or (on 15143 older ports that do not define `TARGET_SUPPORTS_WIDE_INT') an 15144 integer constant too large to fit into `HOST_BITS_PER_WIDE_INT' 15145 bits but small enough to fit within twice that number of bits. In 15146 the latter case, M will be `VOIDmode'. For integral values 15147 constants for modes with more bits than twice the number in 15148 `HOST_WIDE_INT' the implied high order bits of that constant are 15149 copies of the top bit of `CONST_DOUBLE_HIGH'. Note however that 15150 integral values are neither inherently signed nor inherently 15151 unsigned; where necessary, signedness is determined by the rtl 15152 operation instead. 15153 15154 On more modern ports, `CONST_DOUBLE' only represents floating 15155 point values. New ports define `TARGET_SUPPORTS_WIDE_INT' to make 15156 this designation. 15157 15158 If M is `VOIDmode', the bits of the value are stored in I0 and I1. 15159 I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and 15160 I1 with `CONST_DOUBLE_HIGH'. 15161 15162 If the constant is floating point (regardless of its precision), 15163 then the number of integers used to store the value depends on the 15164 size of `REAL_VALUE_TYPE' (*note Floating Point::). The integers 15165 represent a floating point number, but not precisely in the target 15166 machine's or host machine's floating point format. To convert 15167 them to the precise bit pattern used by the target machine, use 15168 the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data 15169 Output::). 15170 15171`(const_wide_int:M NUNITS ELT0 ...)' 15172 This contains an array of `HOST_WIDE_INT's that is large enough to 15173 hold any constant that can be represented on the target. This form 15174 of rtl is only used on targets that define 15175 `TARGET_SUPPORTS_WIDE_INT' to be nonzero and then `CONST_DOUBLE's 15176 are only used to hold floating-point values. If the target leaves 15177 `TARGET_SUPPORTS_WIDE_INT' defined as 0, `CONST_WIDE_INT's are not 15178 used and `CONST_DOUBLE's are as they were before. 15179 15180 The values are stored in a compressed format. The higher-order 0s 15181 or -1s are not represented if they are just the logical sign 15182 extension of the number that is represented. 15183 15184`CONST_WIDE_INT_VEC (CODE)' 15185 Returns the entire array of `HOST_WIDE_INT's that are used to 15186 store the value. This macro should be rarely used. 15187 15188`CONST_WIDE_INT_NUNITS (CODE)' 15189 The number of `HOST_WIDE_INT's used to represent the number. Note 15190 that this generally is smaller than the number of `HOST_WIDE_INT's 15191 implied by the mode size. 15192 15193`CONST_WIDE_INT_NUNITS (CODE,I)' 15194 Returns the `i'th element of the array. Element 0 is contains 15195 the low order bits of the constant. 15196 15197`(const_fixed:M ...)' 15198 Represents a fixed-point constant of mode M. The operand is a 15199 data structure of type `struct fixed_value' and is accessed with 15200 the macro `CONST_FIXED_VALUE'. The high part of data is accessed 15201 with `CONST_FIXED_VALUE_HIGH'; the low part is accessed with 15202 `CONST_FIXED_VALUE_LOW'. 15203 15204`(const_vector:M [X0 X1 ...])' 15205 Represents a vector constant. The square brackets stand for the 15206 vector containing the constant elements. X0, X1 and so on are the 15207 `const_int', `const_double' or `const_fixed' elements. 15208 15209 The number of units in a `const_vector' is obtained with the macro 15210 `CONST_VECTOR_NUNITS' as in `CONST_VECTOR_NUNITS (V)'. 15211 15212 Individual elements in a vector constant are accessed with the 15213 macro `CONST_VECTOR_ELT' as in `CONST_VECTOR_ELT (V, N)' where V 15214 is the vector constant and N is the element desired. 15215 15216`(const_string STR)' 15217 Represents a constant string with value STR. Currently this is 15218 used only for insn attributes (*note Insn Attributes::) since 15219 constant strings in C are placed in memory. 15220 15221`(symbol_ref:MODE SYMBOL)' 15222 Represents the value of an assembler label for data. SYMBOL is a 15223 string that describes the name of the assembler label. If it 15224 starts with a `*', the label is the rest of SYMBOL not including 15225 the `*'. Otherwise, the label is SYMBOL, usually prefixed with 15226 `_'. 15227 15228 The `symbol_ref' contains a mode, which is usually `Pmode'. 15229 Usually that is the only mode for which a symbol is directly valid. 15230 15231`(label_ref:MODE LABEL)' 15232 Represents the value of an assembler label for code. It contains 15233 one operand, an expression, which must be a `code_label' or a 15234 `note' of type `NOTE_INSN_DELETED_LABEL' that appears in the 15235 instruction sequence to identify the place where the label should 15236 go. 15237 15238 The reason for using a distinct expression type for code label 15239 references is so that jump optimization can distinguish them. 15240 15241 The `label_ref' contains a mode, which is usually `Pmode'. 15242 Usually that is the only mode for which a label is directly valid. 15243 15244`(const:M EXP)' 15245 Represents a constant that is the result of an assembly-time 15246 arithmetic computation. The operand, EXP, is an expression that 15247 contains only constants (`const_int', `symbol_ref' and `label_ref' 15248 expressions) combined with `plus' and `minus'. However, not all 15249 combinations are valid, since the assembler cannot do arbitrary 15250 arithmetic on relocatable symbols. 15251 15252 M should be `Pmode'. 15253 15254`(high:M EXP)' 15255 Represents the high-order bits of EXP, usually a `symbol_ref'. 15256 The number of bits is machine-dependent and is normally the number 15257 of bits specified in an instruction that initializes the high 15258 order bits of a register. It is used with `lo_sum' to represent 15259 the typical two-instruction sequence used in RISC machines to 15260 reference a global memory location. 15261 15262 M should be `Pmode'. 15263 15264 The macro `CONST0_RTX (MODE)' refers to an expression with value 0 in 15265mode MODE. If mode MODE is of mode class `MODE_INT', it returns 15266`const0_rtx'. If mode MODE is of mode class `MODE_FLOAT', it returns a 15267`CONST_DOUBLE' expression in mode MODE. Otherwise, it returns a 15268`CONST_VECTOR' expression in mode MODE. Similarly, the macro 15269`CONST1_RTX (MODE)' refers to an expression with value 1 in mode MODE 15270and similarly for `CONST2_RTX'. The `CONST1_RTX' and `CONST2_RTX' 15271macros are undefined for vector modes. 15272 15273 15274File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL 15275 1527613.8 Registers and Memory 15277========================= 15278 15279Here are the RTL expression types for describing access to machine 15280registers and to main memory. 15281 15282`(reg:M N)' 15283 For small values of the integer N (those that are less than 15284 `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine 15285 register number N: a "hard register". For larger values of N, it 15286 stands for a temporary value or "pseudo register". The compiler's 15287 strategy is to generate code assuming an unlimited number of such 15288 pseudo registers, and later convert them into hard registers or 15289 into memory references. 15290 15291 M is the machine mode of the reference. It is necessary because 15292 machines can generally refer to each register in more than one 15293 mode. For example, a register may contain a full word but there 15294 may be instructions to refer to it as a half word or as a single 15295 byte, as well as instructions to refer to it as a floating point 15296 number of various precisions. 15297 15298 Even for a register that the machine can access in only one mode, 15299 the mode must always be specified. 15300 15301 The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine 15302 description, since the number of hard registers on the machine is 15303 an invariant characteristic of the machine. Note, however, that 15304 not all of the machine registers must be general registers. All 15305 the machine registers that can be used for storage of data are 15306 given hard register numbers, even those that can be used only in 15307 certain instructions or can hold only certain types of data. 15308 15309 A hard register may be accessed in various modes throughout one 15310 function, but each pseudo register is given a natural mode and is 15311 accessed only in that mode. When it is necessary to describe an 15312 access to a pseudo register using a nonnatural mode, a `subreg' 15313 expression is used. 15314 15315 A `reg' expression with a machine mode that specifies more than 15316 one word of data may actually stand for several consecutive 15317 registers. If in addition the register number specifies a 15318 hardware register, then it actually represents several consecutive 15319 hardware registers starting with the specified one. 15320 15321 Each pseudo register number used in a function's RTL code is 15322 represented by a unique `reg' expression. 15323 15324 Some pseudo register numbers, those within the range of 15325 `FIRST_VIRTUAL_REGISTER' to `LAST_VIRTUAL_REGISTER' only appear 15326 during the RTL generation phase and are eliminated before the 15327 optimization phases. These represent locations in the stack frame 15328 that cannot be determined until RTL generation for the function 15329 has been completed. The following virtual register numbers are 15330 defined: 15331 15332 `VIRTUAL_INCOMING_ARGS_REGNUM' 15333 This points to the first word of the incoming arguments 15334 passed on the stack. Normally these arguments are placed 15335 there by the caller, but the callee may have pushed some 15336 arguments that were previously passed in registers. 15337 15338 When RTL generation is complete, this virtual register is 15339 replaced by the sum of the register given by 15340 `ARG_POINTER_REGNUM' and the value of `FIRST_PARM_OFFSET'. 15341 15342 `VIRTUAL_STACK_VARS_REGNUM' 15343 If `FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this 15344 points to immediately above the first variable on the stack. 15345 Otherwise, it points to the first variable on the stack. 15346 15347 `VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the 15348 register given by `FRAME_POINTER_REGNUM' and the value 15349 `STARTING_FRAME_OFFSET'. 15350 15351 `VIRTUAL_STACK_DYNAMIC_REGNUM' 15352 This points to the location of dynamically allocated memory 15353 on the stack immediately after the stack pointer has been 15354 adjusted by the amount of memory desired. 15355 15356 This virtual register is replaced by the sum of the register 15357 given by `STACK_POINTER_REGNUM' and the value 15358 `STACK_DYNAMIC_OFFSET'. 15359 15360 `VIRTUAL_OUTGOING_ARGS_REGNUM' 15361 This points to the location in the stack at which outgoing 15362 arguments should be written when the stack is pre-pushed 15363 (arguments pushed using push insns should always use 15364 `STACK_POINTER_REGNUM'). 15365 15366 This virtual register is replaced by the sum of the register 15367 given by `STACK_POINTER_REGNUM' and the value 15368 `STACK_POINTER_OFFSET'. 15369 15370`(subreg:M1 REG:M2 BYTENUM)' 15371 `subreg' expressions are used to refer to a register in a machine 15372 mode other than its natural one, or to refer to one register of a 15373 multi-part `reg' that actually refers to several registers. 15374 15375 Each pseudo register has a natural mode. If it is necessary to 15376 operate on it in a different mode, the register must be enclosed 15377 in a `subreg'. 15378 15379 There are currently three supported types for the first operand of 15380 a `subreg': 15381 * pseudo registers This is the most common case. Most 15382 `subreg's have pseudo `reg's as their first operand. 15383 15384 * mem `subreg's of `mem' were common in earlier versions of GCC 15385 and are still supported. During the reload pass these are 15386 replaced by plain `mem's. On machines that do not do 15387 instruction scheduling, use of `subreg's of `mem' are still 15388 used, but this is no longer recommended. Such `subreg's are 15389 considered to be `register_operand's rather than 15390 `memory_operand's before and during reload. Because of this, 15391 the scheduling passes cannot properly schedule instructions 15392 with `subreg's of `mem', so for machines that do scheduling, 15393 `subreg's of `mem' should never be used. To support this, 15394 the combine and recog passes have explicit code to inhibit 15395 the creation of `subreg's of `mem' when `INSN_SCHEDULING' is 15396 defined. 15397 15398 The use of `subreg's of `mem' after the reload pass is an area 15399 that is not well understood and should be avoided. There is 15400 still some code in the compiler to support this, but this 15401 code has possibly rotted. This use of `subreg's is 15402 discouraged and will most likely not be supported in the 15403 future. 15404 15405 * hard registers It is seldom necessary to wrap hard registers 15406 in `subreg's; such registers would normally reduce to a 15407 single `reg' rtx. This use of `subreg's is discouraged and 15408 may not be supported in the future. 15409 15410 15411 `subreg's of `subreg's are not supported. Using 15412 `simplify_gen_subreg' is the recommended way to avoid this problem. 15413 15414 `subreg's come in two distinct flavors, each having its own usage 15415 and rules: 15416 15417 Paradoxical subregs 15418 When M1 is strictly wider than M2, the `subreg' expression is 15419 called "paradoxical". The canonical test for this class of 15420 `subreg' is: 15421 15422 GET_MODE_SIZE (M1) > GET_MODE_SIZE (M2) 15423 15424 Paradoxical `subreg's can be used as both lvalues and rvalues. 15425 When used as an lvalue, the low-order bits of the source value 15426 are stored in REG and the high-order bits are discarded. 15427 When used as an rvalue, the low-order bits of the `subreg' are 15428 taken from REG while the high-order bits may or may not be 15429 defined. 15430 15431 The high-order bits of rvalues are in the following 15432 circumstances: 15433 15434 * `subreg's of `mem' When M2 is smaller than a word, the 15435 macro `LOAD_EXTEND_OP', can control how the high-order 15436 bits are defined. 15437 15438 * `subreg' of `reg's The upper bits are defined when 15439 `SUBREG_PROMOTED_VAR_P' is true. 15440 `SUBREG_PROMOTED_UNSIGNED_P' describes what the upper 15441 bits hold. Such subregs usually represent local 15442 variables, register variables and parameter pseudo 15443 variables that have been promoted to a wider mode. 15444 15445 15446 BYTENUM is always zero for a paradoxical `subreg', even on 15447 big-endian targets. 15448 15449 For example, the paradoxical `subreg': 15450 15451 (set (subreg:SI (reg:HI X) 0) Y) 15452 15453 stores the lower 2 bytes of Y in X and discards the upper 2 15454 bytes. A subsequent: 15455 15456 (set Z (subreg:SI (reg:HI X) 0)) 15457 15458 would set the lower two bytes of Z to Y and set the upper two 15459 bytes to an unknown value assuming `SUBREG_PROMOTED_VAR_P' is 15460 false. 15461 15462 Normal subregs 15463 When M1 is at least as narrow as M2 the `subreg' expression 15464 is called "normal". 15465 15466 Normal `subreg's restrict consideration to certain bits of 15467 REG. There are two cases. If M1 is smaller than a word, the 15468 `subreg' refers to the least-significant part (or "lowpart") 15469 of one word of REG. If M1 is word-sized or greater, the 15470 `subreg' refers to one or more complete words. 15471 15472 When used as an lvalue, `subreg' is a word-based accessor. 15473 Storing to a `subreg' modifies all the words of REG that 15474 overlap the `subreg', but it leaves the other words of REG 15475 alone. 15476 15477 When storing to a normal `subreg' that is smaller than a word, 15478 the other bits of the referenced word are usually left in an 15479 undefined state. This laxity makes it easier to generate 15480 efficient code for such instructions. To represent an 15481 instruction that preserves all the bits outside of those in 15482 the `subreg', use `strict_low_part' or `zero_extract' around 15483 the `subreg'. 15484 15485 BYTENUM must identify the offset of the first byte of the 15486 `subreg' from the start of REG, assuming that REG is laid out 15487 in memory order. The memory order of bytes is defined by two 15488 target macros, `WORDS_BIG_ENDIAN' and `BYTES_BIG_ENDIAN': 15489 15490 * `WORDS_BIG_ENDIAN', if set to 1, says that byte number 15491 zero is part of the most significant word; otherwise, it 15492 is part of the least significant word. 15493 15494 * `BYTES_BIG_ENDIAN', if set to 1, says that byte number 15495 zero is the most significant byte within a word; 15496 otherwise, it is the least significant byte within a 15497 word. 15498 15499 On a few targets, `FLOAT_WORDS_BIG_ENDIAN' disagrees with 15500 `WORDS_BIG_ENDIAN'. However, most parts of the compiler treat 15501 floating point values as if they had the same endianness as 15502 integer values. This works because they handle them solely 15503 as a collection of integer values, with no particular 15504 numerical value. Only real.c and the runtime libraries care 15505 about `FLOAT_WORDS_BIG_ENDIAN'. 15506 15507 Thus, 15508 15509 (subreg:HI (reg:SI X) 2) 15510 15511 on a `BYTES_BIG_ENDIAN', `UNITS_PER_WORD == 4' target is the 15512 same as 15513 15514 (subreg:HI (reg:SI X) 0) 15515 15516 on a little-endian, `UNITS_PER_WORD == 4' target. Both 15517 `subreg's access the lower two bytes of register X. 15518 15519 15520 A `MODE_PARTIAL_INT' mode behaves as if it were as wide as the 15521 corresponding `MODE_INT' mode, except that it has an unknown 15522 number of undefined bits. For example: 15523 15524 (subreg:PSI (reg:SI 0) 0) 15525 15526 accesses the whole of `(reg:SI 0)', but the exact relationship 15527 between the `PSImode' value and the `SImode' value is not defined. 15528 If we assume `UNITS_PER_WORD <= 4', then the following two 15529 `subreg's: 15530 15531 (subreg:PSI (reg:DI 0) 0) 15532 (subreg:PSI (reg:DI 0) 4) 15533 15534 represent independent 4-byte accesses to the two halves of 15535 `(reg:DI 0)'. Both `subreg's have an unknown number of undefined 15536 bits. 15537 15538 If `UNITS_PER_WORD <= 2' then these two `subreg's: 15539 15540 (subreg:HI (reg:PSI 0) 0) 15541 (subreg:HI (reg:PSI 0) 2) 15542 15543 represent independent 2-byte accesses that together span the whole 15544 of `(reg:PSI 0)'. Storing to the first `subreg' does not affect 15545 the value of the second, and vice versa. `(reg:PSI 0)' has an 15546 unknown number of undefined bits, so the assignment: 15547 15548 (set (subreg:HI (reg:PSI 0) 0) (reg:HI 4)) 15549 15550 does not guarantee that `(subreg:HI (reg:PSI 0) 0)' has the value 15551 `(reg:HI 4)'. 15552 15553 The rules above apply to both pseudo REGs and hard REGs. If the 15554 semantics are not correct for particular combinations of M1, M2 15555 and hard REG, the target-specific code must ensure that those 15556 combinations are never used. For example: 15557 15558 CANNOT_CHANGE_MODE_CLASS (M2, M1, CLASS) 15559 15560 must be true for every class CLASS that includes REG. 15561 15562 The first operand of a `subreg' expression is customarily accessed 15563 with the `SUBREG_REG' macro and the second operand is customarily 15564 accessed with the `SUBREG_BYTE' macro. 15565 15566 It has been several years since a platform in which 15567 `BYTES_BIG_ENDIAN' not equal to `WORDS_BIG_ENDIAN' has been 15568 tested. Anyone wishing to support such a platform in the future 15569 may be confronted with code rot. 15570 15571`(scratch:M)' 15572 This represents a scratch register that will be required for the 15573 execution of a single instruction and not used subsequently. It is 15574 converted into a `reg' by either the local register allocator or 15575 the reload pass. 15576 15577 `scratch' is usually present inside a `clobber' operation (*note 15578 Side Effects::). 15579 15580`(cc0)' 15581 This refers to the machine's condition code register. It has no 15582 operands and may not have a machine mode. There are two ways to 15583 use it: 15584 15585 * To stand for a complete set of condition code flags. This is 15586 best on most machines, where each comparison sets the entire 15587 series of flags. 15588 15589 With this technique, `(cc0)' may be validly used in only two 15590 contexts: as the destination of an assignment (in test and 15591 compare instructions) and in comparison operators comparing 15592 against zero (`const_int' with value zero; that is to say, 15593 `const0_rtx'). 15594 15595 * To stand for a single flag that is the result of a single 15596 condition. This is useful on machines that have only a 15597 single flag bit, and in which comparison instructions must 15598 specify the condition to test. 15599 15600 With this technique, `(cc0)' may be validly used in only two 15601 contexts: as the destination of an assignment (in test and 15602 compare instructions) where the source is a comparison 15603 operator, and as the first operand of `if_then_else' (in a 15604 conditional branch). 15605 15606 There is only one expression object of code `cc0'; it is the value 15607 of the variable `cc0_rtx'. Any attempt to create an expression of 15608 code `cc0' will return `cc0_rtx'. 15609 15610 Instructions can set the condition code implicitly. On many 15611 machines, nearly all instructions set the condition code based on 15612 the value that they compute or store. It is not necessary to 15613 record these actions explicitly in the RTL because the machine 15614 description includes a prescription for recognizing the 15615 instructions that do so (by means of the macro 15616 `NOTICE_UPDATE_CC'). *Note Condition Code::. Only instructions 15617 whose sole purpose is to set the condition code, and instructions 15618 that use the condition code, need mention `(cc0)'. 15619 15620 On some machines, the condition code register is given a register 15621 number and a `reg' is used instead of `(cc0)'. This is usually the 15622 preferable approach if only a small subset of instructions modify 15623 the condition code. Other machines store condition codes in 15624 general registers; in such cases a pseudo register should be used. 15625 15626 Some machines, such as the SPARC and RS/6000, have two sets of 15627 arithmetic instructions, one that sets and one that does not set 15628 the condition code. This is best handled by normally generating 15629 the instruction that does not set the condition code, and making a 15630 pattern that both performs the arithmetic and sets the condition 15631 code register (which would not be `(cc0)' in this case). For 15632 examples, search for `addcc' and `andcc' in `sparc.md'. 15633 15634`(pc)' 15635 This represents the machine's program counter. It has no operands 15636 and may not have a machine mode. `(pc)' may be validly used only 15637 in certain specific contexts in jump instructions. 15638 15639 There is only one expression object of code `pc'; it is the value 15640 of the variable `pc_rtx'. Any attempt to create an expression of 15641 code `pc' will return `pc_rtx'. 15642 15643 All instructions that do not jump alter the program counter 15644 implicitly by incrementing it, but there is no need to mention 15645 this in the RTL. 15646 15647`(mem:M ADDR ALIAS)' 15648 This RTX represents a reference to main memory at an address 15649 represented by the expression ADDR. M specifies how large a unit 15650 of memory is accessed. ALIAS specifies an alias set for the 15651 reference. In general two items are in different alias sets if 15652 they cannot reference the same memory address. 15653 15654 The construct `(mem:BLK (scratch))' is considered to alias all 15655 other memories. Thus it may be used as a memory barrier in 15656 epilogue stack deallocation patterns. 15657 15658`(concatM RTX RTX)' 15659 This RTX represents the concatenation of two other RTXs. This is 15660 used for complex values. It should only appear in the RTL 15661 attached to declarations and during RTL generation. It should not 15662 appear in the ordinary insn chain. 15663 15664`(concatnM [RTX ...])' 15665 This RTX represents the concatenation of all the RTX to make a 15666 single value. Like `concat', this should only appear in 15667 declarations, and not in the insn chain. 15668 15669 15670File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL 15671 1567213.9 RTL Expressions for Arithmetic 15673=================================== 15674 15675Unless otherwise specified, all the operands of arithmetic expressions 15676must be valid for mode M. An operand is valid for mode M if it has 15677mode M, or if it is a `const_int' or `const_double' and M is a mode of 15678class `MODE_INT'. 15679 15680 For commutative binary operations, constants should be placed in the 15681second operand. 15682 15683`(plus:M X Y)' 15684`(ss_plus:M X Y)' 15685`(us_plus:M X Y)' 15686 These three expressions all represent the sum of the values 15687 represented by X and Y carried out in machine mode M. They differ 15688 in their behavior on overflow of integer modes. `plus' wraps 15689 round modulo the width of M; `ss_plus' saturates at the maximum 15690 signed value representable in M; `us_plus' saturates at the 15691 maximum unsigned value. 15692 15693`(lo_sum:M X Y)' 15694 This expression represents the sum of X and the low-order bits of 15695 Y. It is used with `high' (*note Constants::) to represent the 15696 typical two-instruction sequence used in RISC machines to 15697 reference a global memory location. 15698 15699 The number of low order bits is machine-dependent but is normally 15700 the number of bits in a `Pmode' item minus the number of bits set 15701 by `high'. 15702 15703 M should be `Pmode'. 15704 15705`(minus:M X Y)' 15706`(ss_minus:M X Y)' 15707`(us_minus:M X Y)' 15708 These three expressions represent the result of subtracting Y from 15709 X, carried out in mode M. Behavior on overflow is the same as for 15710 the three variants of `plus' (see above). 15711 15712`(compare:M X Y)' 15713 Represents the result of subtracting Y from X for purposes of 15714 comparison. The result is computed without overflow, as if with 15715 infinite precision. 15716 15717 Of course, machines can't really subtract with infinite precision. 15718 However, they can pretend to do so when only the sign of the 15719 result will be used, which is the case when the result is stored 15720 in the condition code. And that is the _only_ way this kind of 15721 expression may validly be used: as a value to be stored in the 15722 condition codes, either `(cc0)' or a register. *Note 15723 Comparisons::. 15724 15725 The mode M is not related to the modes of X and Y, but instead is 15726 the mode of the condition code value. If `(cc0)' is used, it is 15727 `VOIDmode'. Otherwise it is some mode in class `MODE_CC', often 15728 `CCmode'. *Note Condition Code::. If M is `VOIDmode' or 15729 `CCmode', the operation returns sufficient information (in an 15730 unspecified format) so that any comparison operator can be applied 15731 to the result of the `COMPARE' operation. For other modes in 15732 class `MODE_CC', the operation only returns a subset of this 15733 information. 15734 15735 Normally, X and Y must have the same mode. Otherwise, `compare' 15736 is valid only if the mode of X is in class `MODE_INT' and Y is a 15737 `const_int' or `const_double' with mode `VOIDmode'. The mode of X 15738 determines what mode the comparison is to be done in; thus it must 15739 not be `VOIDmode'. 15740 15741 If one of the operands is a constant, it should be placed in the 15742 second operand and the comparison code adjusted as appropriate. 15743 15744 A `compare' specifying two `VOIDmode' constants is not valid since 15745 there is no way to know in what mode the comparison is to be 15746 performed; the comparison must either be folded during the 15747 compilation or the first operand must be loaded into a register 15748 while its mode is still known. 15749 15750`(neg:M X)' 15751`(ss_neg:M X)' 15752`(us_neg:M X)' 15753 These two expressions represent the negation (subtraction from 15754 zero) of the value represented by X, carried out in mode M. They 15755 differ in the behavior on overflow of integer modes. In the case 15756 of `neg', the negation of the operand may be a number not 15757 representable in mode M, in which case it is truncated to M. 15758 `ss_neg' and `us_neg' ensure that an out-of-bounds result 15759 saturates to the maximum or minimum signed or unsigned value. 15760 15761`(mult:M X Y)' 15762`(ss_mult:M X Y)' 15763`(us_mult:M X Y)' 15764 Represents the signed product of the values represented by X and Y 15765 carried out in machine mode M. `ss_mult' and `us_mult' ensure 15766 that an out-of-bounds result saturates to the maximum or minimum 15767 signed or unsigned value. 15768 15769 Some machines support a multiplication that generates a product 15770 wider than the operands. Write the pattern for this as 15771 15772 (mult:M (sign_extend:M X) (sign_extend:M Y)) 15773 15774 where M is wider than the modes of X and Y, which need not be the 15775 same. 15776 15777 For unsigned widening multiplication, use the same idiom, but with 15778 `zero_extend' instead of `sign_extend'. 15779 15780`(fma:M X Y Z)' 15781 Represents the `fma', `fmaf', and `fmal' builtin functions, which 15782 compute `X * Y + Z' without doing an intermediate rounding step. 15783 15784`(div:M X Y)' 15785`(ss_div:M X Y)' 15786 Represents the quotient in signed division of X by Y, carried out 15787 in machine mode M. If M is a floating point mode, it represents 15788 the exact quotient; otherwise, the integerized quotient. `ss_div' 15789 ensures that an out-of-bounds result saturates to the maximum or 15790 minimum signed value. 15791 15792 Some machines have division instructions in which the operands and 15793 quotient widths are not all the same; you should represent such 15794 instructions using `truncate' and `sign_extend' as in, 15795 15796 (truncate:M1 (div:M2 X (sign_extend:M2 Y))) 15797 15798`(udiv:M X Y)' 15799`(us_div:M X Y)' 15800 Like `div' but represents unsigned division. `us_div' ensures 15801 that an out-of-bounds result saturates to the maximum or minimum 15802 unsigned value. 15803 15804`(mod:M X Y)' 15805`(umod:M X Y)' 15806 Like `div' and `udiv' but represent the remainder instead of the 15807 quotient. 15808 15809`(smin:M X Y)' 15810`(smax:M X Y)' 15811 Represents the smaller (for `smin') or larger (for `smax') of X 15812 and Y, interpreted as signed values in mode M. When used with 15813 floating point, if both operands are zeros, or if either operand 15814 is `NaN', then it is unspecified which of the two operands is 15815 returned as the result. 15816 15817`(umin:M X Y)' 15818`(umax:M X Y)' 15819 Like `smin' and `smax', but the values are interpreted as unsigned 15820 integers. 15821 15822`(not:M X)' 15823 Represents the bitwise complement of the value represented by X, 15824 carried out in mode M, which must be a fixed-point machine mode. 15825 15826`(and:M X Y)' 15827 Represents the bitwise logical-and of the values represented by X 15828 and Y, carried out in machine mode M, which must be a fixed-point 15829 machine mode. 15830 15831`(ior:M X Y)' 15832 Represents the bitwise inclusive-or of the values represented by X 15833 and Y, carried out in machine mode M, which must be a fixed-point 15834 mode. 15835 15836`(xor:M X Y)' 15837 Represents the bitwise exclusive-or of the values represented by X 15838 and Y, carried out in machine mode M, which must be a fixed-point 15839 mode. 15840 15841`(ashift:M X C)' 15842`(ss_ashift:M X C)' 15843`(us_ashift:M X C)' 15844 These three expressions represent the result of arithmetically 15845 shifting X left by C places. They differ in their behavior on 15846 overflow of integer modes. An `ashift' operation is a plain shift 15847 with no special behavior in case of a change in the sign bit; 15848 `ss_ashift' and `us_ashift' saturates to the minimum or maximum 15849 representable value if any of the bits shifted out differs from 15850 the final sign bit. 15851 15852 X have mode M, a fixed-point machine mode. C be a fixed-point 15853 mode or be a constant with mode `VOIDmode'; which mode is 15854 determined by the mode called for in the machine description entry 15855 for the left-shift instruction. For example, on the VAX, the mode 15856 of C is `QImode' regardless of M. 15857 15858`(lshiftrt:M X C)' 15859`(ashiftrt:M X C)' 15860 Like `ashift' but for right shift. Unlike the case for left shift, 15861 these two operations are distinct. 15862 15863`(rotate:M X C)' 15864`(rotatert:M X C)' 15865 Similar but represent left and right rotate. If C is a constant, 15866 use `rotate'. 15867 15868`(abs:M X)' 15869 15870`(ss_abs:M X)' 15871 Represents the absolute value of X, computed in mode M. `ss_abs' 15872 ensures that an out-of-bounds result saturates to the maximum 15873 signed value. 15874 15875`(sqrt:M X)' 15876 Represents the square root of X, computed in mode M. Most often M 15877 will be a floating point mode. 15878 15879`(ffs:M X)' 15880 Represents one plus the index of the least significant 1-bit in X, 15881 represented as an integer of mode M. (The value is zero if X is 15882 zero.) The mode of X must be M or `VOIDmode'. 15883 15884`(clrsb:M X)' 15885 Represents the number of redundant leading sign bits in X, 15886 represented as an integer of mode M, starting at the most 15887 significant bit position. This is one less than the number of 15888 leading sign bits (either 0 or 1), with no special cases. The 15889 mode of X must be M or `VOIDmode'. 15890 15891`(clz:M X)' 15892 Represents the number of leading 0-bits in X, represented as an 15893 integer of mode M, starting at the most significant bit position. 15894 If X is zero, the value is determined by 15895 `CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Note that this is one 15896 of the few expressions that is not invariant under widening. The 15897 mode of X must be M or `VOIDmode'. 15898 15899`(ctz:M X)' 15900 Represents the number of trailing 0-bits in X, represented as an 15901 integer of mode M, starting at the least significant bit position. 15902 If X is zero, the value is determined by 15903 `CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Except for this case, 15904 `ctz(x)' is equivalent to `ffs(X) - 1'. The mode of X must be M 15905 or `VOIDmode'. 15906 15907`(popcount:M X)' 15908 Represents the number of 1-bits in X, represented as an integer of 15909 mode M. The mode of X must be M or `VOIDmode'. 15910 15911`(parity:M X)' 15912 Represents the number of 1-bits modulo 2 in X, represented as an 15913 integer of mode M. The mode of X must be M or `VOIDmode'. 15914 15915`(bswap:M X)' 15916 Represents the value X with the order of bytes reversed, carried 15917 out in mode M, which must be a fixed-point machine mode. The mode 15918 of X must be M or `VOIDmode'. 15919 15920 15921File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL 15922 1592313.10 Comparison Operations 15924=========================== 15925 15926Comparison operators test a relation on two operands and are considered 15927to represent a machine-dependent nonzero value described by, but not 15928necessarily equal to, `STORE_FLAG_VALUE' (*note Misc::) if the relation 15929holds, or zero if it does not, for comparison operators whose results 15930have a `MODE_INT' mode, `FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the 15931relation holds, or zero if it does not, for comparison operators that 15932return floating-point values, and a vector of either 15933`VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of 15934zeros if it does not, for comparison operators that return vector 15935results. The mode of the comparison operation is independent of the 15936mode of the data being compared. If the comparison operation is being 15937tested (e.g., the first operand of an `if_then_else'), the mode must be 15938`VOIDmode'. 15939 15940 There are two ways that comparison operations may be used. The 15941comparison operators may be used to compare the condition codes `(cc0)' 15942against zero, as in `(eq (cc0) (const_int 0))'. Such a construct 15943actually refers to the result of the preceding instruction in which the 15944condition codes were set. The instruction setting the condition code 15945must be adjacent to the instruction using the condition code; only 15946`note' insns may separate them. 15947 15948 Alternatively, a comparison operation may directly compare two data 15949objects. The mode of the comparison is determined by the operands; they 15950must both be valid for a common machine mode. A comparison with both 15951operands constant would be invalid as the machine mode could not be 15952deduced from it, but such a comparison should never exist in RTL due to 15953constant folding. 15954 15955 In the example above, if `(cc0)' were last set to `(compare X Y)', the 15956comparison operation is identical to `(eq X Y)'. Usually only one style 15957of comparisons is supported on a particular machine, but the combine 15958pass will try to merge the operations to produce the `eq' shown in case 15959it exists in the context of the particular insn involved. 15960 15961 Inequality comparisons come in two flavors, signed and unsigned. Thus, 15962there are distinct expression codes `gt' and `gtu' for signed and 15963unsigned greater-than. These can produce different results for the same 15964pair of integer values: for example, 1 is signed greater-than -1 but not 15965unsigned greater-than, because -1 when regarded as unsigned is actually 15966`0xffffffff' which is greater than 1. 15967 15968 The signed comparisons are also used for floating point values. 15969Floating point comparisons are distinguished by the machine modes of 15970the operands. 15971 15972`(eq:M X Y)' 15973 `STORE_FLAG_VALUE' if the values represented by X and Y are equal, 15974 otherwise 0. 15975 15976`(ne:M X Y)' 15977 `STORE_FLAG_VALUE' if the values represented by X and Y are not 15978 equal, otherwise 0. 15979 15980`(gt:M X Y)' 15981 `STORE_FLAG_VALUE' if the X is greater than Y. If they are 15982 fixed-point, the comparison is done in a signed sense. 15983 15984`(gtu:M X Y)' 15985 Like `gt' but does unsigned comparison, on fixed-point numbers 15986 only. 15987 15988`(lt:M X Y)' 15989`(ltu:M X Y)' 15990 Like `gt' and `gtu' but test for "less than". 15991 15992`(ge:M X Y)' 15993`(geu:M X Y)' 15994 Like `gt' and `gtu' but test for "greater than or equal". 15995 15996`(le:M X Y)' 15997`(leu:M X Y)' 15998 Like `gt' and `gtu' but test for "less than or equal". 15999 16000`(if_then_else COND THEN ELSE)' 16001 This is not a comparison operation but is listed here because it is 16002 always used in conjunction with a comparison operation. To be 16003 precise, COND is a comparison expression. This expression 16004 represents a choice, according to COND, between the value 16005 represented by THEN and the one represented by ELSE. 16006 16007 On most machines, `if_then_else' expressions are valid only to 16008 express conditional jumps. 16009 16010`(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' 16011 Similar to `if_then_else', but more general. Each of TEST1, 16012 TEST2, ... is performed in turn. The result of this expression is 16013 the VALUE corresponding to the first nonzero test, or DEFAULT if 16014 none of the tests are nonzero expressions. 16015 16016 This is currently not valid for instruction patterns and is 16017 supported only for insn attributes. *Note Insn Attributes::. 16018 16019 16020File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL 16021 1602213.11 Bit-Fields 16023================ 16024 16025Special expression codes exist to represent bit-field instructions. 16026 16027`(sign_extract:M LOC SIZE POS)' 16028 This represents a reference to a sign-extended bit-field contained 16029 or starting in LOC (a memory or register reference). The bit-field 16030 is SIZE bits wide and starts at bit POS. The compilation option 16031 `BITS_BIG_ENDIAN' says which end of the memory unit POS counts 16032 from. 16033 16034 If LOC is in memory, its mode must be a single-byte integer mode. 16035 If LOC is in a register, the mode to use is specified by the 16036 operand of the `insv' or `extv' pattern (*note Standard Names::) 16037 and is usually a full-word integer mode, which is the default if 16038 none is specified. 16039 16040 The mode of POS is machine-specific and is also specified in the 16041 `insv' or `extv' pattern. 16042 16043 The mode M is the same as the mode that would be used for LOC if 16044 it were a register. 16045 16046 A `sign_extract' can not appear as an lvalue, or part thereof, in 16047 RTL. 16048 16049`(zero_extract:M LOC SIZE POS)' 16050 Like `sign_extract' but refers to an unsigned or zero-extended 16051 bit-field. The same sequence of bits are extracted, but they are 16052 filled to an entire word with zeros instead of by sign-extension. 16053 16054 Unlike `sign_extract', this type of expressions can be lvalues in 16055 RTL; they may appear on the left side of an assignment, indicating 16056 insertion of a value into the specified bit-field. 16057 16058 16059File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL 16060 1606113.12 Vector Operations 16062======================= 16063 16064All normal RTL expressions can be used with vector modes; they are 16065interpreted as operating on each part of the vector independently. 16066Additionally, there are a few new expressions to describe specific 16067vector operations. 16068 16069`(vec_merge:M VEC1 VEC2 ITEMS)' 16070 This describes a merge operation between two vectors. The result 16071 is a vector of mode M; its elements are selected from either VEC1 16072 or VEC2. Which elements are selected is described by ITEMS, which 16073 is a bit mask represented by a `const_int'; a zero bit indicates 16074 the corresponding element in the result vector is taken from VEC2 16075 while a set bit indicates it is taken from VEC1. 16076 16077`(vec_select:M VEC1 SELECTION)' 16078 This describes an operation that selects parts of a vector. VEC1 16079 is the source vector, and SELECTION is a `parallel' that contains a 16080 `const_int' for each of the subparts of the result vector, giving 16081 the number of the source subpart that should be stored into it. 16082 The result mode M is either the submode for a single element of 16083 VEC1 (if only one subpart is selected), or another vector mode 16084 with that element submode (if multiple subparts are selected). 16085 16086`(vec_concat:M X1 X2)' 16087 Describes a vector concat operation. The result is a 16088 concatenation of the vectors or scalars X1 and X2; its length is 16089 the sum of the lengths of the two inputs. 16090 16091`(vec_duplicate:M X)' 16092 This operation converts a scalar into a vector or a small vector 16093 into a larger one by duplicating the input values. The output 16094 vector mode must have the same submodes as the input vector mode 16095 or the scalar modes, and the number of output parts must be an 16096 integer multiple of the number of input parts. 16097 16098 16099 16100File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL 16101 1610213.13 Conversions 16103================= 16104 16105All conversions between machine modes must be represented by explicit 16106conversion operations. For example, an expression which is the sum of 16107a byte and a full word cannot be written as `(plus:SI (reg:QI 34) 16108(reg:SI 80))' because the `plus' operation requires two operands of the 16109same machine mode. Therefore, the byte-sized operand is enclosed in a 16110conversion operation, as in 16111 16112 (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80)) 16113 16114 The conversion operation is not a mere placeholder, because there may 16115be more than one way of converting from a given starting mode to the 16116desired final mode. The conversion operation code says how to do it. 16117 16118 For all conversion operations, X must not be `VOIDmode' because the 16119mode in which to do the conversion would not be known. The conversion 16120must either be done at compile-time or X must be placed into a register. 16121 16122`(sign_extend:M X)' 16123 Represents the result of sign-extending the value X to machine 16124 mode M. M must be a fixed-point mode and X a fixed-point value of 16125 a mode narrower than M. 16126 16127`(zero_extend:M X)' 16128 Represents the result of zero-extending the value X to machine 16129 mode M. M must be a fixed-point mode and X a fixed-point value of 16130 a mode narrower than M. 16131 16132`(float_extend:M X)' 16133 Represents the result of extending the value X to machine mode M. 16134 M must be a floating point mode and X a floating point value of a 16135 mode narrower than M. 16136 16137`(truncate:M X)' 16138 Represents the result of truncating the value X to machine mode M. 16139 M must be a fixed-point mode and X a fixed-point value of a mode 16140 wider than M. 16141 16142`(ss_truncate:M X)' 16143 Represents the result of truncating the value X to machine mode M, 16144 using signed saturation in the case of overflow. Both M and the 16145 mode of X must be fixed-point modes. 16146 16147`(us_truncate:M X)' 16148 Represents the result of truncating the value X to machine mode M, 16149 using unsigned saturation in the case of overflow. Both M and the 16150 mode of X must be fixed-point modes. 16151 16152`(float_truncate:M X)' 16153 Represents the result of truncating the value X to machine mode M. 16154 M must be a floating point mode and X a floating point value of a 16155 mode wider than M. 16156 16157`(float:M X)' 16158 Represents the result of converting fixed point value X, regarded 16159 as signed, to floating point mode M. 16160 16161`(unsigned_float:M X)' 16162 Represents the result of converting fixed point value X, regarded 16163 as unsigned, to floating point mode M. 16164 16165`(fix:M X)' 16166 When M is a floating-point mode, represents the result of 16167 converting floating point value X (valid for mode M) to an 16168 integer, still represented in floating point mode M, by rounding 16169 towards zero. 16170 16171 When M is a fixed-point mode, represents the result of converting 16172 floating point value X to mode M, regarded as signed. How 16173 rounding is done is not specified, so this operation may be used 16174 validly in compiling C code only for integer-valued operands. 16175 16176`(unsigned_fix:M X)' 16177 Represents the result of converting floating point value X to 16178 fixed point mode M, regarded as unsigned. How rounding is done is 16179 not specified. 16180 16181`(fract_convert:M X)' 16182 Represents the result of converting fixed-point value X to 16183 fixed-point mode M, signed integer value X to fixed-point mode M, 16184 floating-point value X to fixed-point mode M, fixed-point value X 16185 to integer mode M regarded as signed, or fixed-point value X to 16186 floating-point mode M. When overflows or underflows happen, the 16187 results are undefined. 16188 16189`(sat_fract:M X)' 16190 Represents the result of converting fixed-point value X to 16191 fixed-point mode M, signed integer value X to fixed-point mode M, 16192 or floating-point value X to fixed-point mode M. When overflows 16193 or underflows happen, the results are saturated to the maximum or 16194 the minimum. 16195 16196`(unsigned_fract_convert:M X)' 16197 Represents the result of converting fixed-point value X to integer 16198 mode M regarded as unsigned, or unsigned integer value X to 16199 fixed-point mode M. When overflows or underflows happen, the 16200 results are undefined. 16201 16202`(unsigned_sat_fract:M X)' 16203 Represents the result of converting unsigned integer value X to 16204 fixed-point mode M. When overflows or underflows happen, the 16205 results are saturated to the maximum or the minimum. 16206 16207 16208File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL 16209 1621013.14 Declarations 16211================== 16212 16213Declaration expression codes do not represent arithmetic operations but 16214rather state assertions about their operands. 16215 16216`(strict_low_part (subreg:M (reg:N R) 0))' 16217 This expression code is used in only one context: as the 16218 destination operand of a `set' expression. In addition, the 16219 operand of this expression must be a non-paradoxical `subreg' 16220 expression. 16221 16222 The presence of `strict_low_part' says that the part of the 16223 register which is meaningful in mode N, but is not part of mode M, 16224 is not to be altered. Normally, an assignment to such a subreg is 16225 allowed to have undefined effects on the rest of the register when 16226 M is less than a word. 16227 16228 16229File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL 16230 1623113.15 Side Effect Expressions 16232============================= 16233 16234The expression codes described so far represent values, not actions. 16235But machine instructions never produce values; they are meaningful only 16236for their side effects on the state of the machine. Special expression 16237codes are used to represent side effects. 16238 16239 The body of an instruction is always one of these side effect codes; 16240the codes described above, which represent values, appear only as the 16241operands of these. 16242 16243`(set LVAL X)' 16244 Represents the action of storing the value of X into the place 16245 represented by LVAL. LVAL must be an expression representing a 16246 place that can be stored in: `reg' (or `subreg', `strict_low_part' 16247 or `zero_extract'), `mem', `pc', `parallel', or `cc0'. 16248 16249 If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then 16250 X must be valid for that mode. 16251 16252 If LVAL is a `reg' whose machine mode is less than the full width 16253 of the register, then it means that the part of the register 16254 specified by the machine mode is given the specified value and the 16255 rest of the register receives an undefined value. Likewise, if 16256 LVAL is a `subreg' whose machine mode is narrower than the mode of 16257 the register, the rest of the register can be changed in an 16258 undefined way. 16259 16260 If LVAL is a `strict_low_part' of a subreg, then the part of the 16261 register specified by the machine mode of the `subreg' is given 16262 the value X and the rest of the register is not changed. 16263 16264 If LVAL is a `zero_extract', then the referenced part of the 16265 bit-field (a memory or register reference) specified by the 16266 `zero_extract' is given the value X and the rest of the bit-field 16267 is not changed. Note that `sign_extract' can not appear in LVAL. 16268 16269 If LVAL is `(cc0)', it has no machine mode, and X may be either a 16270 `compare' expression or a value that may have any mode. The 16271 latter case represents a "test" instruction. The expression `(set 16272 (cc0) (reg:M N))' is equivalent to `(set (cc0) (compare (reg:M N) 16273 (const_int 0)))'. Use the former expression to save space during 16274 the compilation. 16275 16276 If LVAL is a `parallel', it is used to represent the case of a 16277 function returning a structure in multiple registers. Each element 16278 of the `parallel' is an `expr_list' whose first operand is a `reg' 16279 and whose second operand is a `const_int' representing the offset 16280 (in bytes) into the structure at which the data in that register 16281 corresponds. The first element may be null to indicate that the 16282 structure is also passed partly in memory. 16283 16284 If LVAL is `(pc)', we have a jump instruction, and the 16285 possibilities for X are very limited. It may be a `label_ref' 16286 expression (unconditional jump). It may be an `if_then_else' 16287 (conditional jump), in which case either the second or the third 16288 operand must be `(pc)' (for the case which does not jump) and the 16289 other of the two must be a `label_ref' (for the case which does 16290 jump). X may also be a `mem' or `(plus:SI (pc) Y)', where Y may 16291 be a `reg' or a `mem'; these unusual patterns are used to 16292 represent jumps through branch tables. 16293 16294 If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not 16295 be `VOIDmode' and the mode of X must be valid for the mode of LVAL. 16296 16297 LVAL is customarily accessed with the `SET_DEST' macro and X with 16298 the `SET_SRC' macro. 16299 16300`(return)' 16301 As the sole expression in a pattern, represents a return from the 16302 current function, on machines where this can be done with one 16303 instruction, such as VAXen. On machines where a multi-instruction 16304 "epilogue" must be executed in order to return from the function, 16305 returning is done by jumping to a label which precedes the 16306 epilogue, and the `return' expression code is never used. 16307 16308 Inside an `if_then_else' expression, represents the value to be 16309 placed in `pc' to return to the caller. 16310 16311 Note that an insn pattern of `(return)' is logically equivalent to 16312 `(set (pc) (return))', but the latter form is never used. 16313 16314`(simple_return)' 16315 Like `(return)', but truly represents only a function return, while 16316 `(return)' may represent an insn that also performs other functions 16317 of the function epilogue. Like `(return)', this may also occur in 16318 conditional jumps. 16319 16320`(call FUNCTION NARGS)' 16321 Represents a function call. FUNCTION is a `mem' expression whose 16322 address is the address of the function to be called. NARGS is an 16323 expression which can be used for two purposes: on some machines it 16324 represents the number of bytes of stack argument; on others, it 16325 represents the number of argument registers. 16326 16327 Each machine has a standard machine mode which FUNCTION must have. 16328 The machine description defines macro `FUNCTION_MODE' to expand 16329 into the requisite mode name. The purpose of this mode is to 16330 specify what kind of addressing is allowed, on machines where the 16331 allowed kinds of addressing depend on the machine mode being 16332 addressed. 16333 16334`(clobber X)' 16335 Represents the storing or possible storing of an unpredictable, 16336 undescribed value into X, which must be a `reg', `scratch', 16337 `parallel' or `mem' expression. 16338 16339 One place this is used is in string instructions that store 16340 standard values into particular hard registers. It may not be 16341 worth the trouble to describe the values that are stored, but it 16342 is essential to inform the compiler that the registers will be 16343 altered, lest it attempt to keep data in them across the string 16344 instruction. 16345 16346 If X is `(mem:BLK (const_int 0))' or `(mem:BLK (scratch))', it 16347 means that all memory locations must be presumed clobbered. If X 16348 is a `parallel', it has the same meaning as a `parallel' in a 16349 `set' expression. 16350 16351 Note that the machine description classifies certain hard 16352 registers as "call-clobbered". All function call instructions are 16353 assumed by default to clobber these registers, so there is no need 16354 to use `clobber' expressions to indicate this fact. Also, each 16355 function call is assumed to have the potential to alter any memory 16356 location, unless the function is declared `const'. 16357 16358 If the last group of expressions in a `parallel' are each a 16359 `clobber' expression whose arguments are `reg' or `match_scratch' 16360 (*note RTL Template::) expressions, the combiner phase can add the 16361 appropriate `clobber' expressions to an insn it has constructed 16362 when doing so will cause a pattern to be matched. 16363 16364 This feature can be used, for example, on a machine that whose 16365 multiply and add instructions don't use an MQ register but which 16366 has an add-accumulate instruction that does clobber the MQ 16367 register. Similarly, a combined instruction might require a 16368 temporary register while the constituent instructions might not. 16369 16370 When a `clobber' expression for a register appears inside a 16371 `parallel' with other side effects, the register allocator 16372 guarantees that the register is unoccupied both before and after 16373 that insn if it is a hard register clobber. For pseudo-register 16374 clobber, the register allocator and the reload pass do not assign 16375 the same hard register to the clobber and the input operands if 16376 there is an insn alternative containing the `&' constraint (*note 16377 Modifiers::) for the clobber and the hard register is in register 16378 classes of the clobber in the alternative. You can clobber either 16379 a specific hard register, a pseudo register, or a `scratch' 16380 expression; in the latter two cases, GCC will allocate a hard 16381 register that is available there for use as a temporary. 16382 16383 For instructions that require a temporary register, you should use 16384 `scratch' instead of a pseudo-register because this will allow the 16385 combiner phase to add the `clobber' when required. You do this by 16386 coding (`clobber' (`match_scratch' ...)). If you do clobber a 16387 pseudo register, use one which appears nowhere else--generate a 16388 new one each time. Otherwise, you may confuse CSE. 16389 16390 There is one other known use for clobbering a pseudo register in a 16391 `parallel': when one of the input operands of the insn is also 16392 clobbered by the insn. In this case, using the same pseudo 16393 register in the clobber and elsewhere in the insn produces the 16394 expected results. 16395 16396`(use X)' 16397 Represents the use of the value of X. It indicates that the value 16398 in X at this point in the program is needed, even though it may 16399 not be apparent why this is so. Therefore, the compiler will not 16400 attempt to delete previous instructions whose only effect is to 16401 store a value in X. X must be a `reg' expression. 16402 16403 In some situations, it may be tempting to add a `use' of a 16404 register in a `parallel' to describe a situation where the value 16405 of a special register will modify the behavior of the instruction. 16406 A hypothetical example might be a pattern for an addition that can 16407 either wrap around or use saturating addition depending on the 16408 value of a special control register: 16409 16410 (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3) 16411 (reg:SI 4)] 0)) 16412 (use (reg:SI 1))]) 16413 16414 This will not work, several of the optimizers only look at 16415 expressions locally; it is very likely that if you have multiple 16416 insns with identical inputs to the `unspec', they will be 16417 optimized away even if register 1 changes in between. 16418 16419 This means that `use' can _only_ be used to describe that the 16420 register is live. You should think twice before adding `use' 16421 statements, more often you will want to use `unspec' instead. The 16422 `use' RTX is most commonly useful to describe that a fixed 16423 register is implicitly used in an insn. It is also safe to use in 16424 patterns where the compiler knows for other reasons that the result 16425 of the whole pattern is variable, such as `movmemM' or `call' 16426 patterns. 16427 16428 During the reload phase, an insn that has a `use' as pattern can 16429 carry a reg_equal note. These `use' insns will be deleted before 16430 the reload phase exits. 16431 16432 During the delayed branch scheduling phase, X may be an insn. 16433 This indicates that X previously was located at this place in the 16434 code and its data dependencies need to be taken into account. 16435 These `use' insns will be deleted before the delayed branch 16436 scheduling phase exits. 16437 16438`(parallel [X0 X1 ...])' 16439 Represents several side effects performed in parallel. The square 16440 brackets stand for a vector; the operand of `parallel' is a vector 16441 of expressions. X0, X1 and so on are individual side effect 16442 expressions--expressions of code `set', `call', `return', 16443 `simple_return', `clobber' or `use'. 16444 16445 "In parallel" means that first all the values used in the 16446 individual side-effects are computed, and second all the actual 16447 side-effects are performed. For example, 16448 16449 (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1))) 16450 (set (mem:SI (reg:SI 1)) (reg:SI 1))]) 16451 16452 says unambiguously that the values of hard register 1 and the 16453 memory location addressed by it are interchanged. In both places 16454 where `(reg:SI 1)' appears as a memory address it refers to the 16455 value in register 1 _before_ the execution of the insn. 16456 16457 It follows that it is _incorrect_ to use `parallel' and expect the 16458 result of one `set' to be available for the next one. For 16459 example, people sometimes attempt to represent a jump-if-zero 16460 instruction this way: 16461 16462 (parallel [(set (cc0) (reg:SI 34)) 16463 (set (pc) (if_then_else 16464 (eq (cc0) (const_int 0)) 16465 (label_ref ...) 16466 (pc)))]) 16467 16468 But this is incorrect, because it says that the jump condition 16469 depends on the condition code value _before_ this instruction, not 16470 on the new value that is set by this instruction. 16471 16472 Peephole optimization, which takes place together with final 16473 assembly code output, can produce insns whose patterns consist of 16474 a `parallel' whose elements are the operands needed to output the 16475 resulting assembler code--often `reg', `mem' or constant 16476 expressions. This would not be well-formed RTL at any other stage 16477 in compilation, but it is OK then because no further optimization 16478 remains to be done. However, the definition of the macro 16479 `NOTICE_UPDATE_CC', if any, must deal with such insns if you 16480 define any peephole optimizations. 16481 16482`(cond_exec [COND EXPR])' 16483 Represents a conditionally executed expression. The EXPR is 16484 executed only if the COND is nonzero. The COND expression must 16485 not have side-effects, but the EXPR may very well have 16486 side-effects. 16487 16488`(sequence [INSNS ...])' 16489 Represents a sequence of insns. If a `sequence' appears in the 16490 chain of insns, then each of the INSNS that appears in the sequence 16491 must be suitable for appearing in the chain of insns, i.e. must 16492 satisfy the `INSN_P' predicate. 16493 16494 After delay-slot scheduling is completed, an insn and all the 16495 insns that reside in its delay slots are grouped together into a 16496 `sequence'. The insn requiring the delay slot is the first insn 16497 in the vector; subsequent insns are to be placed in the delay slot. 16498 16499 `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to 16500 indicate that a branch insn should be used that will conditionally 16501 annul the effect of the insns in the delay slots. In such a case, 16502 `INSN_FROM_TARGET_P' indicates that the insn is from the target of 16503 the branch and should be executed only if the branch is taken; 16504 otherwise the insn should be executed only if the branch is not 16505 taken. *Note Delay Slots::. 16506 16507 Some back ends also use `sequence' objects for purposes other than 16508 delay-slot groups. This is not supported in the common parts of 16509 the compiler, which treat such sequences as delay-slot groups. 16510 16511 DWARF2 Call Frame Address (CFA) adjustments are sometimes also 16512 expressed using `sequence' objects as the value of a 16513 `RTX_FRAME_RELATED_P' note. This only happens if the CFA 16514 adjustments cannot be easily derived from the pattern of the 16515 instruction to which the note is attached. In such cases, the 16516 value of the note is used instead of best-guesing the semantics of 16517 the instruction. The back end can attach notes containing a 16518 `sequence' of `set' patterns that express the effect of the parent 16519 instruction. 16520 16521 These expression codes appear in place of a side effect, as the body of 16522an insn, though strictly speaking they do not always describe side 16523effects as such: 16524 16525`(asm_input S)' 16526 Represents literal assembler code as described by the string S. 16527 16528`(unspec [OPERANDS ...] INDEX)' 16529`(unspec_volatile [OPERANDS ...] INDEX)' 16530 Represents a machine-specific operation on OPERANDS. INDEX 16531 selects between multiple machine-specific operations. 16532 `unspec_volatile' is used for volatile operations and operations 16533 that may trap; `unspec' is used for other operations. 16534 16535 These codes may appear inside a `pattern' of an insn, inside a 16536 `parallel', or inside an expression. 16537 16538`(addr_vec:M [LR0 LR1 ...])' 16539 Represents a table of jump addresses. The vector elements LR0, 16540 etc., are `label_ref' expressions. The mode M specifies how much 16541 space is given to each address; normally M would be `Pmode'. 16542 16543`(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)' 16544 Represents a table of jump addresses expressed as offsets from 16545 BASE. The vector elements LR0, etc., are `label_ref' expressions 16546 and so is BASE. The mode M specifies how much space is given to 16547 each address-difference. MIN and MAX are set up by branch 16548 shortening and hold a label with a minimum and a maximum address, 16549 respectively. FLAGS indicates the relative position of BASE, MIN 16550 and MAX to the containing insn and of MIN and MAX to BASE. See 16551 rtl.def for details. 16552 16553`(prefetch:M ADDR RW LOCALITY)' 16554 Represents prefetch of memory at address ADDR. Operand RW is 1 if 16555 the prefetch is for data to be written, 0 otherwise; targets that 16556 do not support write prefetches should treat this as a normal 16557 prefetch. Operand LOCALITY specifies the amount of temporal 16558 locality; 0 if there is none or 1, 2, or 3 for increasing levels 16559 of temporal locality; targets that do not support locality hints 16560 should ignore this. 16561 16562 This insn is used to minimize cache-miss latency by moving data 16563 into a cache before it is accessed. It should use only 16564 non-faulting data prefetch instructions. 16565 16566 16567File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL 16568 1656913.16 Embedded Side-Effects on Addresses 16570======================================== 16571 16572Six special side-effect expression codes appear as memory addresses. 16573 16574`(pre_dec:M X)' 16575 Represents the side effect of decrementing X by a standard amount 16576 and represents also the value that X has after being decremented. 16577 X must be a `reg' or `mem', but most machines allow only a `reg'. 16578 M must be the machine mode for pointers on the machine in use. 16579 The amount X is decremented by is the length in bytes of the 16580 machine mode of the containing memory reference of which this 16581 expression serves as the address. Here is an example of its use: 16582 16583 (mem:DF (pre_dec:SI (reg:SI 39))) 16584 16585 This says to decrement pseudo register 39 by the length of a 16586 `DFmode' value and use the result to address a `DFmode' value. 16587 16588`(pre_inc:M X)' 16589 Similar, but specifies incrementing X instead of decrementing it. 16590 16591`(post_dec:M X)' 16592 Represents the same side effect as `pre_dec' but a different 16593 value. The value represented here is the value X has before being 16594 decremented. 16595 16596`(post_inc:M X)' 16597 Similar, but specifies incrementing X instead of decrementing it. 16598 16599`(post_modify:M X Y)' 16600 Represents the side effect of setting X to Y and represents X 16601 before X is modified. X must be a `reg' or `mem', but most 16602 machines allow only a `reg'. M must be the machine mode for 16603 pointers on the machine in use. 16604 16605 The expression Y must be one of three forms: `(plus:M X Z)', 16606 `(minus:M X Z)', or `(plus:M X I)', where Z is an index register 16607 and I is a constant. 16608 16609 Here is an example of its use: 16610 16611 (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42) 16612 (reg:SI 48)))) 16613 16614 This says to modify pseudo register 42 by adding the contents of 16615 pseudo register 48 to it, after the use of what ever 42 points to. 16616 16617`(pre_modify:M X EXPR)' 16618 Similar except side effects happen before the use. 16619 16620 These embedded side effect expressions must be used with care. 16621Instruction patterns may not use them. Until the `flow' pass of the 16622compiler, they may occur only to represent pushes onto the stack. The 16623`flow' pass finds cases where registers are incremented or decremented 16624in one instruction and used as an address shortly before or after; 16625these cases are then transformed to use pre- or post-increment or 16626-decrement. 16627 16628 If a register used as the operand of these expressions is used in 16629another address in an insn, the original value of the register is used. 16630Uses of the register outside of an address are not permitted within the 16631same insn as a use in an embedded side effect expression because such 16632insns behave differently on different machines and hence must be treated 16633as ambiguous and disallowed. 16634 16635 An instruction that can be represented with an embedded side effect 16636could also be represented using `parallel' containing an additional 16637`set' to describe how the address register is altered. This is not 16638done because machines that allow these operations at all typically 16639allow them wherever a memory address is called for. Describing them as 16640additional parallel stores would require doubling the number of entries 16641in the machine description. 16642 16643 16644File: gccint.info, Node: Assembler, Next: Debug Information, Prev: Incdec, Up: RTL 16645 1664613.17 Assembler Instructions as Expressions 16647=========================================== 16648 16649The RTX code `asm_operands' represents a value produced by a 16650user-specified assembler instruction. It is used to represent an `asm' 16651statement with arguments. An `asm' statement with a single output 16652operand, like this: 16653 16654 asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z)); 16655 16656is represented using a single `asm_operands' RTX which represents the 16657value that is stored in `outputvar': 16658 16659 (set RTX-FOR-OUTPUTVAR 16660 (asm_operands "foo %1,%2,%0" "a" 0 16661 [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z] 16662 [(asm_input:M1 "g") 16663 (asm_input:M2 "di")])) 16664 16665Here the operands of the `asm_operands' RTX are the assembler template 16666string, the output-operand's constraint, the index-number of the output 16667operand among the output operands specified, a vector of input operand 16668RTX's, and a vector of input-operand modes and constraints. The mode 16669M1 is the mode of the sum `x+y'; M2 is that of `*z'. 16670 16671 When an `asm' statement has multiple output values, its insn has 16672several such `set' RTX's inside of a `parallel'. Each `set' contains 16673an `asm_operands'; all of these share the same assembler template and 16674vectors, but each contains the constraint for the respective output 16675operand. They are also distinguished by the output-operand index 16676number, which is 0, 1, ... for successive output operands. 16677 16678 16679File: gccint.info, Node: Debug Information, Next: Insns, Prev: Assembler, Up: RTL 16680 1668113.18 Variable Location Debug Information in RTL 16682================================================ 16683 16684Variable tracking relies on `MEM_EXPR' and `REG_EXPR' annotations to 16685determine what user variables memory and register references refer to. 16686 16687 Variable tracking at assignments uses these notes only when they refer 16688to variables that live at fixed locations (e.g., addressable variables, 16689global non-automatic variables). For variables whose location may 16690vary, it relies on the following types of notes. 16691 16692`(var_location:MODE VAR EXP STAT)' 16693 Binds variable `var', a tree, to value EXP, an RTL expression. It 16694 appears only in `NOTE_INSN_VAR_LOCATION' and `DEBUG_INSN's, with 16695 slightly different meanings. MODE, if present, represents the 16696 mode of EXP, which is useful if it is a modeless expression. STAT 16697 is only meaningful in notes, indicating whether the variable is 16698 known to be initialized or uninitialized. 16699 16700`(debug_expr:MODE DECL)' 16701 Stands for the value bound to the `DEBUG_EXPR_DECL' DECL, that 16702 points back to it, within value expressions in `VAR_LOCATION' 16703 nodes. 16704 16705 16706 16707File: gccint.info, Node: Insns, Next: Calls, Prev: Debug Information, Up: RTL 16708 1670913.19 Insns 16710=========== 16711 16712The RTL representation of the code for a function is a doubly-linked 16713chain of objects called "insns". Insns are expressions with special 16714codes that are used for no other purpose. Some insns are actual 16715instructions; others represent dispatch tables for `switch' statements; 16716others represent labels to jump to or various sorts of declarative 16717information. 16718 16719 In addition to its own specific data, each insn must have a unique 16720id-number that distinguishes it from all other insns in the current 16721function (after delayed branch scheduling, copies of an insn with the 16722same id-number may be present in multiple places in a function, but 16723these copies will always be identical and will only appear inside a 16724`sequence'), and chain pointers to the preceding and following insns. 16725These three fields occupy the same position in every insn, independent 16726of the expression code of the insn. They could be accessed with `XEXP' 16727and `XINT', but instead three special macros are always used: 16728 16729`INSN_UID (I)' 16730 Accesses the unique id of insn I. 16731 16732`PREV_INSN (I)' 16733 Accesses the chain pointer to the insn preceding I. If I is the 16734 first insn, this is a null pointer. 16735 16736`NEXT_INSN (I)' 16737 Accesses the chain pointer to the insn following I. If I is the 16738 last insn, this is a null pointer. 16739 16740 The first insn in the chain is obtained by calling `get_insns'; the 16741last insn is the result of calling `get_last_insn'. Within the chain 16742delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers must 16743always correspond: if INSN is not the first insn, 16744 16745 NEXT_INSN (PREV_INSN (INSN)) == INSN 16746 16747is always true and if INSN is not the last insn, 16748 16749 PREV_INSN (NEXT_INSN (INSN)) == INSN 16750 16751is always true. 16752 16753 After delay slot scheduling, some of the insns in the chain might be 16754`sequence' expressions, which contain a vector of insns. The value of 16755`NEXT_INSN' in all but the last of these insns is the next insn in the 16756vector; the value of `NEXT_INSN' of the last insn in the vector is the 16757same as the value of `NEXT_INSN' for the `sequence' in which it is 16758contained. Similar rules apply for `PREV_INSN'. 16759 16760 This means that the above invariants are not necessarily true for insns 16761inside `sequence' expressions. Specifically, if INSN is the first insn 16762in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn containing 16763the `sequence' expression, as is the value of `PREV_INSN (NEXT_INSN 16764(INSN))' if INSN is the last insn in the `sequence' expression. You 16765can use these expressions to find the containing `sequence' expression. 16766 16767 Every insn has one of the following expression codes: 16768 16769`insn' 16770 The expression code `insn' is used for instructions that do not 16771 jump and do not do function calls. `sequence' expressions are 16772 always contained in insns with code `insn' even if one of those 16773 insns should jump or do function calls. 16774 16775 Insns with code `insn' have four additional fields beyond the three 16776 mandatory ones listed above. These four are described in a table 16777 below. 16778 16779`jump_insn' 16780 The expression code `jump_insn' is used for instructions that may 16781 jump (or, more generally, may contain `label_ref' expressions to 16782 which `pc' can be set in that instruction). If there is an 16783 instruction to return from the current function, it is recorded as 16784 a `jump_insn'. 16785 16786 `jump_insn' insns have the same extra fields as `insn' insns, 16787 accessed in the same way and in addition contain a field 16788 `JUMP_LABEL' which is defined once jump optimization has completed. 16789 16790 For simple conditional and unconditional jumps, this field contains 16791 the `code_label' to which this insn will (possibly conditionally) 16792 branch. In a more complex jump, `JUMP_LABEL' records one of the 16793 labels that the insn refers to; other jump target labels are 16794 recorded as `REG_LABEL_TARGET' notes. The exception is `addr_vec' 16795 and `addr_diff_vec', where `JUMP_LABEL' is `NULL_RTX' and the only 16796 way to find the labels is to scan the entire body of the insn. 16797 16798 Return insns count as jumps, but since they do not refer to any 16799 labels, their `JUMP_LABEL' is `NULL_RTX'. 16800 16801`call_insn' 16802 The expression code `call_insn' is used for instructions that may 16803 do function calls. It is important to distinguish these 16804 instructions because they imply that certain registers and memory 16805 locations may be altered unpredictably. 16806 16807 `call_insn' insns have the same extra fields as `insn' insns, 16808 accessed in the same way and in addition contain a field 16809 `CALL_INSN_FUNCTION_USAGE', which contains a list (chain of 16810 `expr_list' expressions) containing `use', `clobber' and sometimes 16811 `set' expressions that denote hard registers and `mem's used or 16812 clobbered by the called function. 16813 16814 A `mem' generally points to a stack slot in which arguments passed 16815 to the libcall by reference (*note TARGET_PASS_BY_REFERENCE: 16816 Register Arguments.) are stored. If the argument is caller-copied 16817 (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot 16818 will be mentioned in `clobber' and `use' entries; if it's 16819 callee-copied, only a `use' will appear, and the `mem' may point 16820 to addresses that are not stack slots. 16821 16822 Registers occurring inside a `clobber' in this list augment 16823 registers specified in `CALL_USED_REGISTERS' (*note Register 16824 Basics::). 16825 16826 If the list contains a `set' involving two registers, it indicates 16827 that the function returns one of its arguments. Such a `set' may 16828 look like a no-op if the same register holds the argument and the 16829 return value. 16830 16831`code_label' 16832 A `code_label' insn represents a label that a jump insn can jump 16833 to. It contains two special fields of data in addition to the 16834 three standard ones. `CODE_LABEL_NUMBER' is used to hold the 16835 "label number", a number that identifies this label uniquely among 16836 all the labels in the compilation (not just in the current 16837 function). Ultimately, the label is represented in the assembler 16838 output as an assembler label, usually of the form `LN' where N is 16839 the label number. 16840 16841 When a `code_label' appears in an RTL expression, it normally 16842 appears within a `label_ref' which represents the address of the 16843 label, as a number. 16844 16845 Besides as a `code_label', a label can also be represented as a 16846 `note' of type `NOTE_INSN_DELETED_LABEL'. 16847 16848 The field `LABEL_NUSES' is only defined once the jump optimization 16849 phase is completed. It contains the number of times this label is 16850 referenced in the current function. 16851 16852 The field `LABEL_KIND' differentiates four different types of 16853 labels: `LABEL_NORMAL', `LABEL_STATIC_ENTRY', 16854 `LABEL_GLOBAL_ENTRY', and `LABEL_WEAK_ENTRY'. The only labels 16855 that do not have type `LABEL_NORMAL' are "alternate entry points" 16856 to the current function. These may be static (visible only in the 16857 containing translation unit), global (exposed to all translation 16858 units), or weak (global, but can be overridden by another symbol 16859 with the same name). 16860 16861 Much of the compiler treats all four kinds of label identically. 16862 Some of it needs to know whether or not a label is an alternate 16863 entry point; for this purpose, the macro `LABEL_ALT_ENTRY_P' is 16864 provided. It is equivalent to testing whether `LABEL_KIND (label) 16865 == LABEL_NORMAL'. The only place that cares about the distinction 16866 between static, global, and weak alternate entry points, besides 16867 the front-end code that creates them, is the function 16868 `output_alternate_entry_point', in `final.c'. 16869 16870 To set the kind of a label, use the `SET_LABEL_KIND' macro. 16871 16872`jump_table_data' 16873 A `jump_table_data' insn is a placeholder for the jump-table data 16874 of a `casesi' or `tablejump' insn. They are placed after a 16875 `tablejump_p' insn. A `jump_table_data' insn is not part o a 16876 basic blockm but it is associated with the basic block that ends 16877 with the `tablejump_p' insn. The `PATTERN' of a `jump_table_data' 16878 is always either an `addr_vec' or an `addr_diff_vec', and a 16879 `jump_table_data' insn is always preceded by a `code_label'. The 16880 `tablejump_p' insn refers to that `code_label' via its 16881 `JUMP_LABEL'. 16882 16883`barrier' 16884 Barriers are placed in the instruction stream when control cannot 16885 flow past them. They are placed after unconditional jump 16886 instructions to indicate that the jumps are unconditional and 16887 after calls to `volatile' functions, which do not return (e.g., 16888 `exit'). They contain no information beyond the three standard 16889 fields. 16890 16891`note' 16892 `note' insns are used to represent additional debugging and 16893 declarative information. They contain two nonstandard fields, an 16894 integer which is accessed with the macro `NOTE_LINE_NUMBER' and a 16895 string accessed with `NOTE_SOURCE_FILE'. 16896 16897 If `NOTE_LINE_NUMBER' is positive, the note represents the 16898 position of a source line and `NOTE_SOURCE_FILE' is the source 16899 file name that the line came from. These notes control generation 16900 of line number data in the assembler output. 16901 16902 Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a 16903 code with one of the following values (and `NOTE_SOURCE_FILE' must 16904 contain a null pointer): 16905 16906 `NOTE_INSN_DELETED' 16907 Such a note is completely ignorable. Some passes of the 16908 compiler delete insns by altering them into notes of this 16909 kind. 16910 16911 `NOTE_INSN_DELETED_LABEL' 16912 This marks what used to be a `code_label', but was not used 16913 for other purposes than taking its address and was 16914 transformed to mark that no code jumps to it. 16915 16916 `NOTE_INSN_BLOCK_BEG' 16917 `NOTE_INSN_BLOCK_END' 16918 These types of notes indicate the position of the beginning 16919 and end of a level of scoping of variable names. They 16920 control the output of debugging information. 16921 16922 `NOTE_INSN_EH_REGION_BEG' 16923 `NOTE_INSN_EH_REGION_END' 16924 These types of notes indicate the position of the beginning 16925 and end of a level of scoping for exception handling. 16926 `NOTE_EH_HANDLER' identifies which region is associated with 16927 these notes. 16928 16929 `NOTE_INSN_FUNCTION_BEG' 16930 Appears at the start of the function body, after the function 16931 prologue. 16932 16933 `NOTE_INSN_VAR_LOCATION' 16934 This note is used to generate variable location debugging 16935 information. It indicates that the user variable in its 16936 `VAR_LOCATION' operand is at the location given in the RTL 16937 expression, or holds a value that can be computed by 16938 evaluating the RTL expression from that static point in the 16939 program up to the next such note for the same user variable. 16940 16941 16942 These codes are printed symbolically when they appear in debugging 16943 dumps. 16944 16945`debug_insn' 16946 The expression code `debug_insn' is used for pseudo-instructions 16947 that hold debugging information for variable tracking at 16948 assignments (see `-fvar-tracking-assignments' option). They are 16949 the RTL representation of `GIMPLE_DEBUG' statements (*note 16950 `GIMPLE_DEBUG'::), with a `VAR_LOCATION' operand that binds a user 16951 variable tree to an RTL representation of the `value' in the 16952 corresponding statement. A `DEBUG_EXPR' in it stands for the 16953 value bound to the corresponding `DEBUG_EXPR_DECL'. 16954 16955 Throughout optimization passes, binding information is kept in 16956 pseudo-instruction form, so that, unlike notes, it gets the same 16957 treatment and adjustments that regular instructions would. It is 16958 the variable tracking pass that turns these pseudo-instructions 16959 into var location notes, analyzing control flow, value 16960 equivalences and changes to registers and memory referenced in 16961 value expressions, propagating the values of debug temporaries and 16962 determining expressions that can be used to compute the value of 16963 each user variable at as many points (ranges, actually) in the 16964 program as possible. 16965 16966 Unlike `NOTE_INSN_VAR_LOCATION', the value expression in an 16967 `INSN_VAR_LOCATION' denotes a value at that specific point in the 16968 program, rather than an expression that can be evaluated at any 16969 later point before an overriding `VAR_LOCATION' is encountered. 16970 E.g., if a user variable is bound to a `REG' and then a subsequent 16971 insn modifies the `REG', the note location would keep mapping the 16972 user variable to the register across the insn, whereas the insn 16973 location would keep the variable bound to the value, so that the 16974 variable tracking pass would emit another location note for the 16975 variable at the point in which the register is modified. 16976 16977 16978 The machine mode of an insn is normally `VOIDmode', but some phases 16979use the mode for various purposes. 16980 16981 The common subexpression elimination pass sets the mode of an insn to 16982`QImode' when it is the first insn in a block that has already been 16983processed. 16984 16985 The second Haifa scheduling pass, for targets that can multiple issue, 16986sets the mode of an insn to `TImode' when it is believed that the 16987instruction begins an issue group. That is, when the instruction 16988cannot issue simultaneously with the previous. This may be relied on 16989by later passes, in particular machine-dependent reorg. 16990 16991 Here is a table of the extra fields of `insn', `jump_insn' and 16992`call_insn' insns: 16993 16994`PATTERN (I)' 16995 An expression for the side effect performed by this insn. This 16996 must be one of the following codes: `set', `call', `use', 16997 `clobber', `return', `simple_return', `asm_input', `asm_output', 16998 `addr_vec', `addr_diff_vec', `trap_if', `unspec', 16999 `unspec_volatile', `parallel', `cond_exec', or `sequence'. If it 17000 is a `parallel', each element of the `parallel' must be one these 17001 codes, except that `parallel' expressions cannot be nested and 17002 `addr_vec' and `addr_diff_vec' are not permitted inside a 17003 `parallel' expression. 17004 17005`INSN_CODE (I)' 17006 An integer that says which pattern in the machine description 17007 matches this insn, or -1 if the matching has not yet been 17008 attempted. 17009 17010 Such matching is never attempted and this field remains -1 on an 17011 insn whose pattern consists of a single `use', `clobber', 17012 `asm_input', `addr_vec' or `addr_diff_vec' expression. 17013 17014 Matching is also never attempted on insns that result from an `asm' 17015 statement. These contain at least one `asm_operands' expression. 17016 The function `asm_noperands' returns a non-negative value for such 17017 insns. 17018 17019 In the debugging output, this field is printed as a number 17020 followed by a symbolic representation that locates the pattern in 17021 the `md' file as some small positive or negative offset from a 17022 named pattern. 17023 17024`LOG_LINKS (I)' 17025 A list (chain of `insn_list' expressions) giving information about 17026 dependencies between instructions within a basic block. Neither a 17027 jump nor a label may come between the related insns. These are 17028 only used by the schedulers and by combine. This is a deprecated 17029 data structure. Def-use and use-def chains are now preferred. 17030 17031`REG_NOTES (I)' 17032 A list (chain of `expr_list', `insn_list' and `int_list' 17033 expressions) giving miscellaneous information about the insn. It 17034 is often information pertaining to the registers used in this insn. 17035 17036 The `LOG_LINKS' field of an insn is a chain of `insn_list' 17037expressions. Each of these has two operands: the first is an insn, and 17038the second is another `insn_list' expression (the next one in the 17039chain). The last `insn_list' in the chain has a null pointer as second 17040operand. The significant thing about the chain is which insns appear 17041in it (as first operands of `insn_list' expressions). Their order is 17042not significant. 17043 17044 This list is originally set up by the flow analysis pass; it is a null 17045pointer until then. Flow only adds links for those data dependencies 17046which can be used for instruction combination. For each insn, the flow 17047analysis pass adds a link to insns which store into registers values 17048that are used for the first time in this insn. 17049 17050 The `REG_NOTES' field of an insn is a chain similar to the `LOG_LINKS' 17051field but it includes `expr_list' and `int_list' expressions in 17052addition to `insn_list' expressions. There are several kinds of 17053register notes, which are distinguished by the machine mode, which in a 17054register note is really understood as being an `enum reg_note'. The 17055first operand OP of the note is data whose meaning depends on the kind 17056of note. 17057 17058 The macro `REG_NOTE_KIND (X)' returns the kind of register note. Its 17059counterpart, the macro `PUT_REG_NOTE_KIND (X, NEWKIND)' sets the 17060register note type of X to be NEWKIND. 17061 17062 Register notes are of three classes: They may say something about an 17063input to an insn, they may say something about an output of an insn, or 17064they may create a linkage between two insns. There are also a set of 17065values that are only used in `LOG_LINKS'. 17066 17067 These register notes annotate inputs to an insn: 17068 17069`REG_DEAD' 17070 The value in OP dies in this insn; that is to say, altering the 17071 value immediately after this insn would not affect the future 17072 behavior of the program. 17073 17074 It does not follow that the register OP has no useful value after 17075 this insn since OP is not necessarily modified by this insn. 17076 Rather, no subsequent instruction uses the contents of OP. 17077 17078`REG_UNUSED' 17079 The register OP being set by this insn will not be used in a 17080 subsequent insn. This differs from a `REG_DEAD' note, which 17081 indicates that the value in an input will not be used subsequently. 17082 These two notes are independent; both may be present for the same 17083 register. 17084 17085`REG_INC' 17086 The register OP is incremented (or decremented; at this level 17087 there is no distinction) by an embedded side effect inside this 17088 insn. This means it appears in a `post_inc', `pre_inc', 17089 `post_dec' or `pre_dec' expression. 17090 17091`REG_NONNEG' 17092 The register OP is known to have a nonnegative value when this 17093 insn is reached. This is used so that decrement and branch until 17094 zero instructions, such as the m68k dbra, can be matched. 17095 17096 The `REG_NONNEG' note is added to insns only if the machine 17097 description has a `decrement_and_branch_until_zero' pattern. 17098 17099`REG_LABEL_OPERAND' 17100 This insn uses OP, a `code_label' or a `note' of type 17101 `NOTE_INSN_DELETED_LABEL', but is not a `jump_insn', or it is a 17102 `jump_insn' that refers to the operand as an ordinary operand. 17103 The label may still eventually be a jump target, but if so in an 17104 indirect jump in a subsequent insn. The presence of this note 17105 allows jump optimization to be aware that OP is, in fact, being 17106 used, and flow optimization to build an accurate flow graph. 17107 17108`REG_LABEL_TARGET' 17109 This insn is a `jump_insn' but not an `addr_vec' or 17110 `addr_diff_vec'. It uses OP, a `code_label' as a direct or 17111 indirect jump target. Its purpose is similar to that of 17112 `REG_LABEL_OPERAND'. This note is only present if the insn has 17113 multiple targets; the last label in the insn (in the highest 17114 numbered insn-field) goes into the `JUMP_LABEL' field and does not 17115 have a `REG_LABEL_TARGET' note. *Note JUMP_LABEL: Insns. 17116 17117`REG_CROSSING_JUMP' 17118 This insn is a branching instruction (either an unconditional jump 17119 or an indirect jump) which crosses between hot and cold sections, 17120 which could potentially be very far apart in the executable. The 17121 presence of this note indicates to other optimizations that this 17122 branching instruction should not be "collapsed" into a simpler 17123 branching construct. It is used when the optimization to 17124 partition basic blocks into hot and cold sections is turned on. 17125 17126`REG_SETJMP' 17127 Appears attached to each `CALL_INSN' to `setjmp' or a related 17128 function. 17129 17130 The following notes describe attributes of outputs of an insn: 17131 17132`REG_EQUIV' 17133`REG_EQUAL' 17134 This note is only valid on an insn that sets only one register and 17135 indicates that that register will be equal to OP at run time; the 17136 scope of this equivalence differs between the two types of notes. 17137 The value which the insn explicitly copies into the register may 17138 look different from OP, but they will be equal at run time. If the 17139 output of the single `set' is a `strict_low_part' expression, the 17140 note refers to the register that is contained in `SUBREG_REG' of 17141 the `subreg' expression. 17142 17143 For `REG_EQUIV', the register is equivalent to OP throughout the 17144 entire function, and could validly be replaced in all its 17145 occurrences by OP. ("Validly" here refers to the data flow of the 17146 program; simple replacement may make some insns invalid.) For 17147 example, when a constant is loaded into a register that is never 17148 assigned any other value, this kind of note is used. 17149 17150 When a parameter is copied into a pseudo-register at entry to a 17151 function, a note of this kind records that the register is 17152 equivalent to the stack slot where the parameter was passed. 17153 Although in this case the register may be set by other insns, it 17154 is still valid to replace the register by the stack slot 17155 throughout the function. 17156 17157 A `REG_EQUIV' note is also used on an instruction which copies a 17158 register parameter into a pseudo-register at entry to a function, 17159 if there is a stack slot where that parameter could be stored. 17160 Although other insns may set the pseudo-register, it is valid for 17161 the compiler to replace the pseudo-register by stack slot 17162 throughout the function, provided the compiler ensures that the 17163 stack slot is properly initialized by making the replacement in 17164 the initial copy instruction as well. This is used on machines 17165 for which the calling convention allocates stack space for 17166 register parameters. See `REG_PARM_STACK_SPACE' in *note Stack 17167 Arguments::. 17168 17169 In the case of `REG_EQUAL', the register that is set by this insn 17170 will be equal to OP at run time at the end of this insn but not 17171 necessarily elsewhere in the function. In this case, OP is 17172 typically an arithmetic expression. For example, when a sequence 17173 of insns such as a library call is used to perform an arithmetic 17174 operation, this kind of note is attached to the insn that produces 17175 or copies the final value. 17176 17177 These two notes are used in different ways by the compiler passes. 17178 `REG_EQUAL' is used by passes prior to register allocation (such as 17179 common subexpression elimination and loop optimization) to tell 17180 them how to think of that value. `REG_EQUIV' notes are used by 17181 register allocation to indicate that there is an available 17182 substitute expression (either a constant or a `mem' expression for 17183 the location of a parameter on the stack) that may be used in 17184 place of a register if insufficient registers are available. 17185 17186 Except for stack homes for parameters, which are indicated by a 17187 `REG_EQUIV' note and are not useful to the early optimization 17188 passes and pseudo registers that are equivalent to a memory 17189 location throughout their entire life, which is not detected until 17190 later in the compilation, all equivalences are initially indicated 17191 by an attached `REG_EQUAL' note. In the early stages of register 17192 allocation, a `REG_EQUAL' note is changed into a `REG_EQUIV' note 17193 if OP is a constant and the insn represents the only set of its 17194 destination register. 17195 17196 Thus, compiler passes prior to register allocation need only check 17197 for `REG_EQUAL' notes and passes subsequent to register allocation 17198 need only check for `REG_EQUIV' notes. 17199 17200 These notes describe linkages between insns. They occur in pairs: one 17201insn has one of a pair of notes that points to a second insn, which has 17202the inverse note pointing back to the first insn. 17203 17204`REG_CC_SETTER' 17205`REG_CC_USER' 17206 On machines that use `cc0', the insns which set and use `cc0' set 17207 and use `cc0' are adjacent. However, when branch delay slot 17208 filling is done, this may no longer be true. In this case a 17209 `REG_CC_USER' note will be placed on the insn setting `cc0' to 17210 point to the insn using `cc0' and a `REG_CC_SETTER' note will be 17211 placed on the insn using `cc0' to point to the insn setting `cc0'. 17212 17213 These values are only used in the `LOG_LINKS' field, and indicate the 17214type of dependency that each link represents. Links which indicate a 17215data dependence (a read after write dependence) do not use any code, 17216they simply have mode `VOIDmode', and are printed without any 17217descriptive text. 17218 17219`REG_DEP_TRUE' 17220 This indicates a true dependence (a read after write dependence). 17221 17222`REG_DEP_OUTPUT' 17223 This indicates an output dependence (a write after write 17224 dependence). 17225 17226`REG_DEP_ANTI' 17227 This indicates an anti dependence (a write after read dependence). 17228 17229 17230 These notes describe information gathered from gcov profile data. They 17231are stored in the `REG_NOTES' field of an insn. 17232 17233`REG_BR_PROB' 17234 This is used to specify the ratio of branches to non-branches of a 17235 branch insn according to the profile data. The note is represented 17236 as an `int_list' expression whose integer value is between 0 and 17237 REG_BR_PROB_BASE. Larger values indicate a higher probability that 17238 the branch will be taken. 17239 17240`REG_BR_PRED' 17241 These notes are found in JUMP insns after delayed branch scheduling 17242 has taken place. They indicate both the direction and the 17243 likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_* 17244 values. 17245 17246`REG_FRAME_RELATED_EXPR' 17247 This is used on an RTX_FRAME_RELATED_P insn wherein the attached 17248 expression is used in place of the actual insn pattern. This is 17249 done in cases where the pattern is either complex or misleading. 17250 17251 For convenience, the machine mode in an `insn_list' or `expr_list' is 17252printed using these symbolic codes in debugging dumps. 17253 17254 The only difference between the expression codes `insn_list' and 17255`expr_list' is that the first operand of an `insn_list' is assumed to 17256be an insn and is printed in debugging dumps as the insn's unique id; 17257the first operand of an `expr_list' is printed in the ordinary way as 17258an expression. 17259 17260 17261File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL 17262 1726313.20 RTL Representation of Function-Call Insns 17264=============================================== 17265 17266Insns that call subroutines have the RTL expression code `call_insn'. 17267These insns must satisfy special rules, and their bodies must use a 17268special RTL expression code, `call'. 17269 17270 A `call' expression has two operands, as follows: 17271 17272 (call (mem:FM ADDR) NBYTES) 17273 17274Here NBYTES is an operand that represents the number of bytes of 17275argument data being passed to the subroutine, FM is a machine mode 17276(which must equal as the definition of the `FUNCTION_MODE' macro in the 17277machine description) and ADDR represents the address of the subroutine. 17278 17279 For a subroutine that returns no value, the `call' expression as shown 17280above is the entire body of the insn, except that the insn might also 17281contain `use' or `clobber' expressions. 17282 17283 For a subroutine that returns a value whose mode is not `BLKmode', the 17284value is returned in a hard register. If this register's number is R, 17285then the body of the call insn looks like this: 17286 17287 (set (reg:M R) 17288 (call (mem:FM ADDR) NBYTES)) 17289 17290This RTL expression makes it clear (to the optimizer passes) that the 17291appropriate register receives a useful value in this insn. 17292 17293 When a subroutine returns a `BLKmode' value, it is handled by passing 17294to the subroutine the address of a place to store the value. So the 17295call insn itself does not "return" any value, and it has the same RTL 17296form as a call that returns nothing. 17297 17298 On some machines, the call instruction itself clobbers some register, 17299for example to contain the return address. `call_insn' insns on these 17300machines should have a body which is a `parallel' that contains both 17301the `call' expression and `clobber' expressions that indicate which 17302registers are destroyed. Similarly, if the call instruction requires 17303some register other than the stack pointer that is not explicitly 17304mentioned in its RTL, a `use' subexpression should mention that 17305register. 17306 17307 Functions that are called are assumed to modify all registers listed in 17308the configuration macro `CALL_USED_REGISTERS' (*note Register Basics::) 17309and, with the exception of `const' functions and library calls, to 17310modify all of memory. 17311 17312 Insns containing just `use' expressions directly precede the 17313`call_insn' insn to indicate which registers contain inputs to the 17314function. Similarly, if registers other than those in 17315`CALL_USED_REGISTERS' are clobbered by the called function, insns 17316containing a single `clobber' follow immediately after the call to 17317indicate which registers. 17318 17319 17320File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL 17321 1732213.21 Structure Sharing Assumptions 17323=================================== 17324 17325The compiler assumes that certain kinds of RTL expressions are unique; 17326there do not exist two distinct objects representing the same value. 17327In other cases, it makes an opposite assumption: that no RTL expression 17328object of a certain kind appears in more than one place in the 17329containing structure. 17330 17331 These assumptions refer to a single function; except for the RTL 17332objects that describe global variables and external functions, and a 17333few standard objects such as small integer constants, no RTL objects 17334are common to two functions. 17335 17336 * Each pseudo-register has only a single `reg' object to represent 17337 it, and therefore only a single machine mode. 17338 17339 * For any symbolic label, there is only one `symbol_ref' object 17340 referring to it. 17341 17342 * All `const_int' expressions with equal values are shared. 17343 17344 * There is only one `pc' expression. 17345 17346 * There is only one `cc0' expression. 17347 17348 * There is only one `const_double' expression with value 0 for each 17349 floating point mode. Likewise for values 1 and 2. 17350 17351 * There is only one `const_vector' expression with value 0 for each 17352 vector mode, be it an integer or a double constant vector. 17353 17354 * No `label_ref' or `scratch' appears in more than one place in the 17355 RTL structure; in other words, it is safe to do a tree-walk of all 17356 the insns in the function and assume that each time a `label_ref' 17357 or `scratch' is seen it is distinct from all others that are seen. 17358 17359 * Only one `mem' object is normally created for each static variable 17360 or stack slot, so these objects are frequently shared in all the 17361 places they appear. However, separate but equal objects for these 17362 variables are occasionally made. 17363 17364 * When a single `asm' statement has multiple output operands, a 17365 distinct `asm_operands' expression is made for each output operand. 17366 However, these all share the vector which contains the sequence of 17367 input operands. This sharing is used later on to test whether two 17368 `asm_operands' expressions come from the same statement, so all 17369 optimizations must carefully preserve the sharing if they copy the 17370 vector at all. 17371 17372 * No RTL object appears in more than one place in the RTL structure 17373 except as described above. Many passes of the compiler rely on 17374 this by assuming that they can modify RTL objects in place without 17375 unwanted side-effects on other insns. 17376 17377 * During initial RTL generation, shared structure is freely 17378 introduced. After all the RTL for a function has been generated, 17379 all shared structure is copied by `unshare_all_rtl' in 17380 `emit-rtl.c', after which the above rules are guaranteed to be 17381 followed. 17382 17383 * During the combiner pass, shared structure within an insn can exist 17384 temporarily. However, the shared structure is copied before the 17385 combiner is finished with the insn. This is done by calling 17386 `copy_rtx_if_shared', which is a subroutine of `unshare_all_rtl'. 17387 17388 17389File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL 17390 1739113.22 Reading RTL 17392================= 17393 17394To read an RTL object from a file, call `read_rtx'. It takes one 17395argument, a stdio stream, and returns a single RTL object. This routine 17396is defined in `read-rtl.c'. It is not available in the compiler 17397itself, only the various programs that generate the compiler back end 17398from the machine description. 17399 17400 People frequently have the idea of using RTL stored as text in a file 17401as an interface between a language front end and the bulk of GCC. This 17402idea is not feasible. 17403 17404 GCC was designed to use RTL internally only. Correct RTL for a given 17405program is very dependent on the particular target machine. And the RTL 17406does not contain all the information about the program. 17407 17408 The proper way to interface GCC to a new language front end is with 17409the "tree" data structure, described in the files `tree.h' and 17410`tree.def'. The documentation for this structure (*note GENERIC::) is 17411incomplete. 17412 17413 17414File: gccint.info, Node: Control Flow, Next: Loop Analysis and Representation, Prev: RTL, Up: Top 17415 1741614 Control Flow Graph 17417********************* 17418 17419A control flow graph (CFG) is a data structure built on top of the 17420intermediate code representation (the RTL or `GIMPLE' instruction 17421stream) abstracting the control flow behavior of a function that is 17422being compiled. The CFG is a directed graph where the vertices 17423represent basic blocks and edges represent possible transfer of control 17424flow from one basic block to another. The data structures used to 17425represent the control flow graph are defined in `basic-block.h'. 17426 17427 In GCC, the representation of control flow is maintained throughout 17428the compilation process, from constructing the CFG early in 17429`pass_build_cfg' to `pass_free_cfg' (see `passes.def'). The CFG takes 17430various different modes and may undergo extensive manipulations, but 17431the graph is always valid between its construction and its release. 17432This way, transfer of information such as data flow, a measured 17433profile, or the loop tree, can be propagated through the passes 17434pipeline, and even from `GIMPLE' to `RTL'. 17435 17436 Often the CFG may be better viewed as integral part of instruction 17437chain, than structure built on the top of it. Updating the compiler's 17438intermediate representation for instructions can not be easily done 17439without proper maintenance of the CFG simultaneously. 17440 17441* Menu: 17442 17443* Basic Blocks:: The definition and representation of basic blocks. 17444* Edges:: Types of edges and their representation. 17445* Profile information:: Representation of frequencies and probabilities. 17446* Maintaining the CFG:: Keeping the control flow graph and up to date. 17447* Liveness information:: Using and maintaining liveness information. 17448 17449 17450File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow 17451 1745214.1 Basic Blocks 17453================= 17454 17455A basic block is a straight-line sequence of code with only one entry 17456point and only one exit. In GCC, basic blocks are represented using 17457the `basic_block' data type. 17458 17459 Special basic blocks represent possible entry and exit points of a 17460function. These blocks are called `ENTRY_BLOCK_PTR' and 17461`EXIT_BLOCK_PTR'. These blocks do not contain any code. 17462 17463 The `BASIC_BLOCK' array contains all basic blocks in an unspecified 17464order. Each `basic_block' structure has a field that holds a unique 17465integer identifier `index' that is the index of the block in the 17466`BASIC_BLOCK' array. The total number of basic blocks in the function 17467is `n_basic_blocks'. Both the basic block indices and the total number 17468of basic blocks may vary during the compilation process, as passes 17469reorder, create, duplicate, and destroy basic blocks. The index for 17470any block should never be greater than `last_basic_block'. The indices 174710 and 1 are special codes reserved for `ENTRY_BLOCK' and `EXIT_BLOCK', 17472the indices of `ENTRY_BLOCK_PTR' and `EXIT_BLOCK_PTR'. 17473 17474 Two pointer members of the `basic_block' structure are the pointers 17475`next_bb' and `prev_bb'. These are used to keep doubly linked chain of 17476basic blocks in the same order as the underlying instruction stream. 17477The chain of basic blocks is updated transparently by the provided API 17478for manipulating the CFG. The macro `FOR_EACH_BB' can be used to visit 17479all the basic blocks in lexicographical order, except `ENTRY_BLOCK' and 17480`EXIT_BLOCK'. The macro `FOR_ALL_BB' also visits all basic blocks in 17481lexicographical order, including `ENTRY_BLOCK' and `EXIT_BLOCK'. 17482 17483 The functions `post_order_compute' and `inverted_post_order_compute' 17484can be used to compute topological orders of the CFG. The orders are 17485stored as vectors of basic block indices. The `BASIC_BLOCK' array can 17486be used to iterate each basic block by index. Dominator traversals are 17487also possible using `walk_dominator_tree'. Given two basic blocks A 17488and B, block A dominates block B if A is _always_ executed before B. 17489 17490 Each `basic_block' also contains pointers to the first instruction 17491(the "head") and the last instruction (the "tail") or "end" of the 17492instruction stream contained in a basic block. In fact, since the 17493`basic_block' data type is used to represent blocks in both major 17494intermediate representations of GCC (`GIMPLE' and RTL), there are 17495pointers to the head and end of a basic block for both representations, 17496stored in intermediate representation specific data in the `il' field 17497of `struct basic_block_def'. 17498 17499 For RTL, these pointers are `BB_HEAD' and `BB_END'. 17500 17501 In the RTL representation of a function, the instruction stream 17502contains not only the "real" instructions, but also "notes" or "insn 17503notes" (to distinguish them from "reg notes"). Any function that moves 17504or duplicates the basic blocks needs to take care of updating of these 17505notes. Many of these notes expect that the instruction stream consists 17506of linear regions, so updating can sometimes be tedious. All types of 17507insn notes are defined in `insn-notes.def'. 17508 17509 In the RTL function representation, the instructions contained in a 17510basic block always follow a `NOTE_INSN_BASIC_BLOCK', but zero or more 17511`CODE_LABEL' nodes can precede the block note. A basic block ends with 17512a control flow instruction or with the last instruction before the next 17513`CODE_LABEL' or `NOTE_INSN_BASIC_BLOCK'. By definition, a `CODE_LABEL' 17514cannot appear in the middle of the instruction stream of a basic block. 17515 17516 In addition to notes, the jump table vectors are also represented as 17517"pseudo-instructions" inside the insn stream. These vectors never 17518appear in the basic block and should always be placed just after the 17519table jump instructions referencing them. After removing the 17520table-jump it is often difficult to eliminate the code computing the 17521address and referencing the vector, so cleaning up these vectors is 17522postponed until after liveness analysis. Thus the jump table vectors 17523may appear in the insn stream unreferenced and without any purpose. 17524Before any edge is made "fall-thru", the existence of such construct in 17525the way needs to be checked by calling `can_fallthru' function. 17526 17527 For the `GIMPLE' representation, the PHI nodes and statements 17528contained in a basic block are in a `gimple_seq' pointed to by the 17529basic block intermediate language specific pointers. Abstract 17530containers and iterators are used to access the PHI nodes and 17531statements in a basic blocks. These iterators are called "GIMPLE 17532statement iterators" (GSIs). Grep for `^gsi' in the various `gimple-*' 17533and `tree-*' files. There is a `gimple_stmt_iterator' type for 17534iterating over all kinds of statement, and a `gphi_iterator' subclass 17535for iterating over PHI nodes. The following snippet will pretty-print 17536all PHI nodes the statements of the current function in the GIMPLE 17537representation. 17538 17539 basic_block bb; 17540 17541 FOR_EACH_BB (bb) 17542 { 17543 gphi_iterator pi; 17544 gimple_stmt_iterator si; 17545 17546 for (pi = gsi_start_phis (bb); !gsi_end_p (pi); gsi_next (&pi)) 17547 { 17548 gphi *phi = pi.phi (); 17549 print_gimple_stmt (dump_file, phi, 0, TDF_SLIM); 17550 } 17551 for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si)) 17552 { 17553 gimple stmt = gsi_stmt (si); 17554 print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM); 17555 } 17556 } 17557 17558 17559File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow 17560 1756114.2 Edges 17562========== 17563 17564Edges represent possible control flow transfers from the end of some 17565basic block A to the head of another basic block B. We say that A is a 17566predecessor of B, and B is a successor of A. Edges are represented in 17567GCC with the `edge' data type. Each `edge' acts as a link between two 17568basic blocks: The `src' member of an edge points to the predecessor 17569basic block of the `dest' basic block. The members `preds' and `succs' 17570of the `basic_block' data type point to type-safe vectors of edges to 17571the predecessors and successors of the block. 17572 17573 When walking the edges in an edge vector, "edge iterators" should be 17574used. Edge iterators are constructed using the `edge_iterator' data 17575structure and several methods are available to operate on them: 17576 17577`ei_start' 17578 This function initializes an `edge_iterator' that points to the 17579 first edge in a vector of edges. 17580 17581`ei_last' 17582 This function initializes an `edge_iterator' that points to the 17583 last edge in a vector of edges. 17584 17585`ei_end_p' 17586 This predicate is `true' if an `edge_iterator' represents the last 17587 edge in an edge vector. 17588 17589`ei_one_before_end_p' 17590 This predicate is `true' if an `edge_iterator' represents the 17591 second last edge in an edge vector. 17592 17593`ei_next' 17594 This function takes a pointer to an `edge_iterator' and makes it 17595 point to the next edge in the sequence. 17596 17597`ei_prev' 17598 This function takes a pointer to an `edge_iterator' and makes it 17599 point to the previous edge in the sequence. 17600 17601`ei_edge' 17602 This function returns the `edge' currently pointed to by an 17603 `edge_iterator'. 17604 17605`ei_safe_safe' 17606 This function returns the `edge' currently pointed to by an 17607 `edge_iterator', but returns `NULL' if the iterator is pointing at 17608 the end of the sequence. This function has been provided for 17609 existing code makes the assumption that a `NULL' edge indicates 17610 the end of the sequence. 17611 17612 17613 The convenience macro `FOR_EACH_EDGE' can be used to visit all of the 17614edges in a sequence of predecessor or successor edges. It must not be 17615used when an element might be removed during the traversal, otherwise 17616elements will be missed. Here is an example of how to use the macro: 17617 17618 edge e; 17619 edge_iterator ei; 17620 17621 FOR_EACH_EDGE (e, ei, bb->succs) 17622 { 17623 if (e->flags & EDGE_FALLTHRU) 17624 break; 17625 } 17626 17627 There are various reasons why control flow may transfer from one block 17628to another. One possibility is that some instruction, for example a 17629`CODE_LABEL', in a linearized instruction stream just always starts a 17630new basic block. In this case a "fall-thru" edge links the basic block 17631to the first following basic block. But there are several other 17632reasons why edges may be created. The `flags' field of the `edge' data 17633type is used to store information about the type of edge we are dealing 17634with. Each edge is of one of the following types: 17635 17636_jump_ 17637 No type flags are set for edges corresponding to jump instructions. 17638 These edges are used for unconditional or conditional jumps and in 17639 RTL also for table jumps. They are the easiest to manipulate as 17640 they may be freely redirected when the flow graph is not in SSA 17641 form. 17642 17643_fall-thru_ 17644 Fall-thru edges are present in case where the basic block may 17645 continue execution to the following one without branching. These 17646 edges have the `EDGE_FALLTHRU' flag set. Unlike other types of 17647 edges, these edges must come into the basic block immediately 17648 following in the instruction stream. The function 17649 `force_nonfallthru' is available to insert an unconditional jump 17650 in the case that redirection is needed. Note that this may 17651 require creation of a new basic block. 17652 17653_exception handling_ 17654 Exception handling edges represent possible control transfers from 17655 a trapping instruction to an exception handler. The definition of 17656 "trapping" varies. In C++, only function calls can throw, but for 17657 Java and Ada, exceptions like division by zero or segmentation 17658 fault are defined and thus each instruction possibly throwing this 17659 kind of exception needs to be handled as control flow instruction. 17660 Exception edges have the `EDGE_ABNORMAL' and `EDGE_EH' flags set. 17661 17662 When updating the instruction stream it is easy to change possibly 17663 trapping instruction to non-trapping, by simply removing the 17664 exception edge. The opposite conversion is difficult, but should 17665 not happen anyway. The edges can be eliminated via 17666 `purge_dead_edges' call. 17667 17668 In the RTL representation, the destination of an exception edge is 17669 specified by `REG_EH_REGION' note attached to the insn. In case 17670 of a trapping call the `EDGE_ABNORMAL_CALL' flag is set too. In 17671 the `GIMPLE' representation, this extra flag is not set. 17672 17673 In the RTL representation, the predicate `may_trap_p' may be used 17674 to check whether instruction still may trap or not. For the tree 17675 representation, the `tree_could_trap_p' predicate is available, 17676 but this predicate only checks for possible memory traps, as in 17677 dereferencing an invalid pointer location. 17678 17679_sibling calls_ 17680 Sibling calls or tail calls terminate the function in a 17681 non-standard way and thus an edge to the exit must be present. 17682 `EDGE_SIBCALL' and `EDGE_ABNORMAL' are set in such case. These 17683 edges only exist in the RTL representation. 17684 17685_computed jumps_ 17686 Computed jumps contain edges to all labels in the function 17687 referenced from the code. All those edges have `EDGE_ABNORMAL' 17688 flag set. The edges used to represent computed jumps often cause 17689 compile time performance problems, since functions consisting of 17690 many taken labels and many computed jumps may have _very_ dense 17691 flow graphs, so these edges need to be handled with special care. 17692 During the earlier stages of the compilation process, GCC tries to 17693 avoid such dense flow graphs by factoring computed jumps. For 17694 example, given the following series of jumps, 17695 17696 goto *x; 17697 [ ... ] 17698 17699 goto *x; 17700 [ ... ] 17701 17702 goto *x; 17703 [ ... ] 17704 17705 factoring the computed jumps results in the following code sequence 17706 which has a much simpler flow graph: 17707 17708 goto y; 17709 [ ... ] 17710 17711 goto y; 17712 [ ... ] 17713 17714 goto y; 17715 [ ... ] 17716 17717 y: 17718 goto *x; 17719 17720 However, the classic problem with this transformation is that it 17721 has a runtime cost in there resulting code: An extra jump. 17722 Therefore, the computed jumps are un-factored in the later passes 17723 of the compiler (in the pass called 17724 `pass_duplicate_computed_gotos'). Be aware of that when you work 17725 on passes in that area. There have been numerous examples already 17726 where the compile time for code with unfactored computed jumps 17727 caused some serious headaches. 17728 17729_nonlocal goto handlers_ 17730 GCC allows nested functions to return into caller using a `goto' 17731 to a label passed to as an argument to the callee. The labels 17732 passed to nested functions contain special code to cleanup after 17733 function call. Such sections of code are referred to as "nonlocal 17734 goto receivers". If a function contains such nonlocal goto 17735 receivers, an edge from the call to the label is created with the 17736 `EDGE_ABNORMAL' and `EDGE_ABNORMAL_CALL' flags set. 17737 17738_function entry points_ 17739 By definition, execution of function starts at basic block 0, so 17740 there is always an edge from the `ENTRY_BLOCK_PTR' to basic block 17741 0. There is no `GIMPLE' representation for alternate entry points 17742 at this moment. In RTL, alternate entry points are specified by 17743 `CODE_LABEL' with `LABEL_ALTERNATE_NAME' defined. This feature is 17744 currently used for multiple entry point prologues and is limited 17745 to post-reload passes only. This can be used by back-ends to emit 17746 alternate prologues for functions called from different contexts. 17747 In future full support for multiple entry functions defined by 17748 Fortran 90 needs to be implemented. 17749 17750_function exits_ 17751 In the pre-reload representation a function terminates after the 17752 last instruction in the insn chain and no explicit return 17753 instructions are used. This corresponds to the fall-thru edge 17754 into exit block. After reload, optimal RTL epilogues are used 17755 that use explicit (conditional) return instructions that are 17756 represented by edges with no flags set. 17757 17758 17759 17760File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow 17761 1776214.3 Profile information 17763======================== 17764 17765In many cases a compiler must make a choice whether to trade speed in 17766one part of code for speed in another, or to trade code size for code 17767speed. In such cases it is useful to know information about how often 17768some given block will be executed. That is the purpose for maintaining 17769profile within the flow graph. GCC can handle profile information 17770obtained through "profile feedback", but it can also estimate branch 17771probabilities based on statics and heuristics. 17772 17773 The feedback based profile is produced by compiling the program with 17774instrumentation, executing it on a train run and reading the numbers of 17775executions of basic blocks and edges back to the compiler while 17776re-compiling the program to produce the final executable. This method 17777provides very accurate information about where a program spends most of 17778its time on the train run. Whether it matches the average run of 17779course depends on the choice of train data set, but several studies 17780have shown that the behavior of a program usually changes just 17781marginally over different data sets. 17782 17783 When profile feedback is not available, the compiler may be asked to 17784attempt to predict the behavior of each branch in the program using a 17785set of heuristics (see `predict.def' for details) and compute estimated 17786frequencies of each basic block by propagating the probabilities over 17787the graph. 17788 17789 Each `basic_block' contains two integer fields to represent profile 17790information: `frequency' and `count'. The `frequency' is an estimation 17791how often is basic block executed within a function. It is represented 17792as an integer scaled in the range from 0 to `BB_FREQ_BASE'. The most 17793frequently executed basic block in function is initially set to 17794`BB_FREQ_BASE' and the rest of frequencies are scaled accordingly. 17795During optimization, the frequency of the most frequent basic block can 17796both decrease (for instance by loop unrolling) or grow (for instance by 17797cross-jumping optimization), so scaling sometimes has to be performed 17798multiple times. 17799 17800 The `count' contains hard-counted numbers of execution measured during 17801training runs and is nonzero only when profile feedback is available. 17802This value is represented as the host's widest integer (typically a 64 17803bit integer) of the special type `gcov_type'. 17804 17805 Most optimization passes can use only the frequency information of a 17806basic block, but a few passes may want to know hard execution counts. 17807The frequencies should always match the counts after scaling, however 17808during updating of the profile information numerical error may 17809accumulate into quite large errors. 17810 17811 Each edge also contains a branch probability field: an integer in the 17812range from 0 to `REG_BR_PROB_BASE'. It represents probability of 17813passing control from the end of the `src' basic block to the `dest' 17814basic block, i.e. the probability that control will flow along this 17815edge. The `EDGE_FREQUENCY' macro is available to compute how 17816frequently a given edge is taken. There is a `count' field for each 17817edge as well, representing same information as for a basic block. 17818 17819 The basic block frequencies are not represented in the instruction 17820stream, but in the RTL representation the edge frequencies are 17821represented for conditional jumps (via the `REG_BR_PROB' macro) since 17822they are used when instructions are output to the assembly file and the 17823flow graph is no longer maintained. 17824 17825 The probability that control flow arrives via a given edge to its 17826destination basic block is called "reverse probability" and is not 17827directly represented, but it may be easily computed from frequencies of 17828basic blocks. 17829 17830 Updating profile information is a delicate task that can unfortunately 17831not be easily integrated with the CFG manipulation API. Many of the 17832functions and hooks to modify the CFG, such as 17833`redirect_edge_and_branch', do not have enough information to easily 17834update the profile, so updating it is in the majority of cases left up 17835to the caller. It is difficult to uncover bugs in the profile updating 17836code, because they manifest themselves only by producing worse code, 17837and checking profile consistency is not possible because of numeric 17838error accumulation. Hence special attention needs to be given to this 17839issue in each pass that modifies the CFG. 17840 17841 It is important to point out that `REG_BR_PROB_BASE' and 17842`BB_FREQ_BASE' are both set low enough to be possible to compute second 17843power of any frequency or probability in the flow graph, it is not 17844possible to even square the `count' field, as modern CPUs are fast 17845enough to execute $2^32$ operations quickly. 17846 17847 17848File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow 17849 1785014.4 Maintaining the CFG 17851======================== 17852 17853An important task of each compiler pass is to keep both the control 17854flow graph and all profile information up-to-date. Reconstruction of 17855the control flow graph after each pass is not an option, since it may be 17856very expensive and lost profile information cannot be reconstructed at 17857all. 17858 17859 GCC has two major intermediate representations, and both use the 17860`basic_block' and `edge' data types to represent control flow. Both 17861representations share as much of the CFG maintenance code as possible. 17862For each representation, a set of "hooks" is defined so that each 17863representation can provide its own implementation of CFG manipulation 17864routines when necessary. These hooks are defined in `cfghooks.h'. 17865There are hooks for almost all common CFG manipulations, including 17866block splitting and merging, edge redirection and creating and deleting 17867basic blocks. These hooks should provide everything you need to 17868maintain and manipulate the CFG in both the RTL and `GIMPLE' 17869representation. 17870 17871 At the moment, the basic block boundaries are maintained transparently 17872when modifying instructions, so there rarely is a need to move them 17873manually (such as in case someone wants to output instruction outside 17874basic block explicitly). 17875 17876 In the RTL representation, each instruction has a `BLOCK_FOR_INSN' 17877value that represents pointer to the basic block that contains the 17878instruction. In the `GIMPLE' representation, the function `gimple_bb' 17879returns a pointer to the basic block containing the queried statement. 17880 17881 When changes need to be applied to a function in its `GIMPLE' 17882representation, "GIMPLE statement iterators" should be used. These 17883iterators provide an integrated abstraction of the flow graph and the 17884instruction stream. Block statement iterators are constructed using 17885the `gimple_stmt_iterator' data structure and several modifiers are 17886available, including the following: 17887 17888`gsi_start' 17889 This function initializes a `gimple_stmt_iterator' that points to 17890 the first non-empty statement in a basic block. 17891 17892`gsi_last' 17893 This function initializes a `gimple_stmt_iterator' that points to 17894 the last statement in a basic block. 17895 17896`gsi_end_p' 17897 This predicate is `true' if a `gimple_stmt_iterator' represents 17898 the end of a basic block. 17899 17900`gsi_next' 17901 This function takes a `gimple_stmt_iterator' and makes it point to 17902 its successor. 17903 17904`gsi_prev' 17905 This function takes a `gimple_stmt_iterator' and makes it point to 17906 its predecessor. 17907 17908`gsi_insert_after' 17909 This function inserts a statement after the `gimple_stmt_iterator' 17910 passed in. The final parameter determines whether the statement 17911 iterator is updated to point to the newly inserted statement, or 17912 left pointing to the original statement. 17913 17914`gsi_insert_before' 17915 This function inserts a statement before the `gimple_stmt_iterator' 17916 passed in. The final parameter determines whether the statement 17917 iterator is updated to point to the newly inserted statement, or 17918 left pointing to the original statement. 17919 17920`gsi_remove' 17921 This function removes the `gimple_stmt_iterator' passed in and 17922 rechains the remaining statements in a basic block, if any. 17923 17924 In the RTL representation, the macros `BB_HEAD' and `BB_END' may be 17925used to get the head and end `rtx' of a basic block. No abstract 17926iterators are defined for traversing the insn chain, but you can just 17927use `NEXT_INSN' and `PREV_INSN' instead. *Note Insns::. 17928 17929 Usually a code manipulating pass simplifies the instruction stream and 17930the flow of control, possibly eliminating some edges. This may for 17931example happen when a conditional jump is replaced with an 17932unconditional jump, but also when simplifying possibly trapping 17933instruction to non-trapping while compiling Java. Updating of edges is 17934not transparent and each optimization pass is required to do so 17935manually. However only few cases occur in practice. The pass may call 17936`purge_dead_edges' on a given basic block to remove superfluous edges, 17937if any. 17938 17939 Another common scenario is redirection of branch instructions, but 17940this is best modeled as redirection of edges in the control flow graph 17941and thus use of `redirect_edge_and_branch' is preferred over more low 17942level functions, such as `redirect_jump' that operate on RTL chain 17943only. The CFG hooks defined in `cfghooks.h' should provide the 17944complete API required for manipulating and maintaining the CFG. 17945 17946 It is also possible that a pass has to insert control flow instruction 17947into the middle of a basic block, thus creating an entry point in the 17948middle of the basic block, which is impossible by definition: The block 17949must be split to make sure it only has one entry point, i.e. the head 17950of the basic block. The CFG hook `split_block' may be used when an 17951instruction in the middle of a basic block has to become the target of 17952a jump or branch instruction. 17953 17954 For a global optimizer, a common operation is to split edges in the 17955flow graph and insert instructions on them. In the RTL representation, 17956this can be easily done using the `insert_insn_on_edge' function that 17957emits an instruction "on the edge", caching it for a later 17958`commit_edge_insertions' call that will take care of moving the 17959inserted instructions off the edge into the instruction stream 17960contained in a basic block. This includes the creation of new basic 17961blocks where needed. In the `GIMPLE' representation, the equivalent 17962functions are `gsi_insert_on_edge' which inserts a block statement 17963iterator on an edge, and `gsi_commit_edge_inserts' which flushes the 17964instruction to actual instruction stream. 17965 17966 While debugging the optimization pass, the `verify_flow_info' function 17967may be useful to find bugs in the control flow graph updating code. 17968 17969 17970File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow 17971 1797214.5 Liveness information 17973========================= 17974 17975Liveness information is useful to determine whether some register is 17976"live" at given point of program, i.e. that it contains a value that 17977may be used at a later point in the program. This information is used, 17978for instance, during register allocation, as the pseudo registers only 17979need to be assigned to a unique hard register or to a stack slot if 17980they are live. The hard registers and stack slots may be freely reused 17981for other values when a register is dead. 17982 17983 Liveness information is available in the back end starting with 17984`pass_df_initialize' and ending with `pass_df_finish'. Three flavors 17985of live analysis are available: With `LR', it is possible to determine 17986at any point `P' in the function if the register may be used on some 17987path from `P' to the end of the function. With `UR', it is possible to 17988determine if there is a path from the beginning of the function to `P' 17989that defines the variable. `LIVE' is the intersection of the `LR' and 17990`UR' and a variable is live at `P' if there is both an assignment that 17991reaches it from the beginning of the function and a use that can be 17992reached on some path from `P' to the end of the function. 17993 17994 In general `LIVE' is the most useful of the three. The macros 17995`DF_[LR,UR,LIVE]_[IN,OUT]' can be used to access this information. The 17996macros take a basic block number and return a bitmap that is indexed by 17997the register number. This information is only guaranteed to be up to 17998date after calls are made to `df_analyze'. See the file `df-core.c' 17999for details on using the dataflow. 18000 18001 The liveness information is stored partly in the RTL instruction stream 18002and partly in the flow graph. Local information is stored in the 18003instruction stream: Each instruction may contain `REG_DEAD' notes 18004representing that the value of a given register is no longer needed, or 18005`REG_UNUSED' notes representing that the value computed by the 18006instruction is never used. The second is useful for instructions 18007computing multiple values at once. 18008 18009 18010File: gccint.info, Node: Loop Analysis and Representation, Next: Machine Desc, Prev: Control Flow, Up: Top 18011 1801215 Analysis and Representation of Loops 18013*************************************** 18014 18015GCC provides extensive infrastructure for work with natural loops, i.e., 18016strongly connected components of CFG with only one entry block. This 18017chapter describes representation of loops in GCC, both on GIMPLE and in 18018RTL, as well as the interfaces to loop-related analyses (induction 18019variable analysis and number of iterations analysis). 18020 18021* Menu: 18022 18023* Loop representation:: Representation and analysis of loops. 18024* Loop querying:: Getting information about loops. 18025* Loop manipulation:: Loop manipulation functions. 18026* LCSSA:: Loop-closed SSA form. 18027* Scalar evolutions:: Induction variables on GIMPLE. 18028* loop-iv:: Induction variables on RTL. 18029* Number of iterations:: Number of iterations analysis. 18030* Dependency analysis:: Data dependency analysis. 18031* Omega:: A solver for linear programming problems. 18032 18033 18034File: gccint.info, Node: Loop representation, Next: Loop querying, Up: Loop Analysis and Representation 18035 1803615.1 Loop representation 18037======================== 18038 18039This chapter describes the representation of loops in GCC, and functions 18040that can be used to build, modify and analyze this representation. Most 18041of the interfaces and data structures are declared in `cfgloop.h'. 18042Loop structures are analyzed and this information disposed or updated 18043at the discretion of individual passes. Still most of the generic CFG 18044manipulation routines are aware of loop structures and try to keep them 18045up-to-date. By this means an increasing part of the compilation 18046pipeline is setup to maintain loop structure across passes to allow 18047attaching meta information to individual loops for consumption by later 18048passes. 18049 18050 In general, a natural loop has one entry block (header) and possibly 18051several back edges (latches) leading to the header from the inside of 18052the loop. Loops with several latches may appear if several loops share 18053a single header, or if there is a branching in the middle of the loop. 18054The representation of loops in GCC however allows only loops with a 18055single latch. During loop analysis, headers of such loops are split and 18056forwarder blocks are created in order to disambiguate their structures. 18057Heuristic based on profile information and structure of the induction 18058variables in the loops is used to determine whether the latches 18059correspond to sub-loops or to control flow in a single loop. This means 18060that the analysis sometimes changes the CFG, and if you run it in the 18061middle of an optimization pass, you must be able to deal with the new 18062blocks. You may avoid CFG changes by passing 18063`LOOPS_MAY_HAVE_MULTIPLE_LATCHES' flag to the loop discovery, note 18064however that most other loop manipulation functions will not work 18065correctly for loops with multiple latch edges (the functions that only 18066query membership of blocks to loops and subloop relationships, or 18067enumerate and test loop exits, can be expected to work). 18068 18069 Body of the loop is the set of blocks that are dominated by its header, 18070and reachable from its latch against the direction of edges in CFG. The 18071loops are organized in a containment hierarchy (tree) such that all the 18072loops immediately contained inside loop L are the children of L in the 18073tree. This tree is represented by the `struct loops' structure. The 18074root of this tree is a fake loop that contains all blocks in the 18075function. Each of the loops is represented in a `struct loop' 18076structure. Each loop is assigned an index (`num' field of the `struct 18077loop' structure), and the pointer to the loop is stored in the 18078corresponding field of the `larray' vector in the loops structure. The 18079indices do not have to be continuous, there may be empty (`NULL') 18080entries in the `larray' created by deleting loops. Also, there is no 18081guarantee on the relative order of a loop and its subloops in the 18082numbering. The index of a loop never changes. 18083 18084 The entries of the `larray' field should not be accessed directly. 18085The function `get_loop' returns the loop description for a loop with 18086the given index. `number_of_loops' function returns number of loops in 18087the function. To traverse all loops, use `FOR_EACH_LOOP' macro. The 18088`flags' argument of the macro is used to determine the direction of 18089traversal and the set of loops visited. Each loop is guaranteed to be 18090visited exactly once, regardless of the changes to the loop tree, and 18091the loops may be removed during the traversal. The newly created loops 18092are never traversed, if they need to be visited, this must be done 18093separately after their creation. The `FOR_EACH_LOOP' macro allocates 18094temporary variables. If the `FOR_EACH_LOOP' loop were ended using 18095break or goto, they would not be released; `FOR_EACH_LOOP_BREAK' macro 18096must be used instead. 18097 18098 Each basic block contains the reference to the innermost loop it 18099belongs to (`loop_father'). For this reason, it is only possible to 18100have one `struct loops' structure initialized at the same time for each 18101CFG. The global variable `current_loops' contains the `struct loops' 18102structure. Many of the loop manipulation functions assume that 18103dominance information is up-to-date. 18104 18105 The loops are analyzed through `loop_optimizer_init' function. The 18106argument of this function is a set of flags represented in an integer 18107bitmask. These flags specify what other properties of the loop 18108structures should be calculated/enforced and preserved later: 18109 18110 * `LOOPS_MAY_HAVE_MULTIPLE_LATCHES': If this flag is set, no changes 18111 to CFG will be performed in the loop analysis, in particular, 18112 loops with multiple latch edges will not be disambiguated. If a 18113 loop has multiple latches, its latch block is set to NULL. Most of 18114 the loop manipulation functions will not work for loops in this 18115 shape. No other flags that require CFG changes can be passed to 18116 loop_optimizer_init. 18117 18118 * `LOOPS_HAVE_PREHEADERS': Forwarder blocks are created in such a 18119 way that each loop has only one entry edge, and additionally, the 18120 source block of this entry edge has only one successor. This 18121 creates a natural place where the code can be moved out of the 18122 loop, and ensures that the entry edge of the loop leads from its 18123 immediate super-loop. 18124 18125 * `LOOPS_HAVE_SIMPLE_LATCHES': Forwarder blocks are created to force 18126 the latch block of each loop to have only one successor. This 18127 ensures that the latch of the loop does not belong to any of its 18128 sub-loops, and makes manipulation with the loops significantly 18129 easier. Most of the loop manipulation functions assume that the 18130 loops are in this shape. Note that with this flag, the "normal" 18131 loop without any control flow inside and with one exit consists of 18132 two basic blocks. 18133 18134 * `LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS': Basic blocks and edges in 18135 the strongly connected components that are not natural loops (have 18136 more than one entry block) are marked with `BB_IRREDUCIBLE_LOOP' 18137 and `EDGE_IRREDUCIBLE_LOOP' flags. The flag is not set for blocks 18138 and edges that belong to natural loops that are in such an 18139 irreducible region (but it is set for the entry and exit edges of 18140 such a loop, if they lead to/from this region). 18141 18142 * `LOOPS_HAVE_RECORDED_EXITS': The lists of exits are recorded and 18143 updated for each loop. This makes some functions (e.g., 18144 `get_loop_exit_edges') more efficient. Some functions (e.g., 18145 `single_exit') can be used only if the lists of exits are recorded. 18146 18147 These properties may also be computed/enforced later, using functions 18148`create_preheaders', `force_single_succ_latches', 18149`mark_irreducible_loops' and `record_loop_exits'. The properties can 18150be queried using `loops_state_satisfies_p'. 18151 18152 The memory occupied by the loops structures should be freed with 18153`loop_optimizer_finalize' function. When loop structures are setup to 18154be preserved across passes this function reduces the information to be 18155kept up-to-date to a minimum (only `LOOPS_MAY_HAVE_MULTIPLE_LATCHES' 18156set). 18157 18158 The CFG manipulation functions in general do not update loop 18159structures. Specialized versions that additionally do so are provided 18160for the most common tasks. On GIMPLE, `cleanup_tree_cfg_loop' function 18161can be used to cleanup CFG while updating the loops structures if 18162`current_loops' is set. 18163 18164 At the moment loop structure is preserved from the start of GIMPLE 18165loop optimizations until the end of RTL loop optimizations. During 18166this time a loop can be tracked by its `struct loop' and number. 18167 18168 18169File: gccint.info, Node: Loop querying, Next: Loop manipulation, Prev: Loop representation, Up: Loop Analysis and Representation 18170 1817115.2 Loop querying 18172================== 18173 18174The functions to query the information about loops are declared in 18175`cfgloop.h'. Some of the information can be taken directly from the 18176structures. `loop_father' field of each basic block contains the 18177innermost loop to that the block belongs. The most useful fields of 18178loop structure (that are kept up-to-date at all times) are: 18179 18180 * `header', `latch': Header and latch basic blocks of the loop. 18181 18182 * `num_nodes': Number of basic blocks in the loop (including the 18183 basic blocks of the sub-loops). 18184 18185 * `depth': The depth of the loop in the loops tree, i.e., the number 18186 of super-loops of the loop. 18187 18188 * `outer', `inner', `next': The super-loop, the first sub-loop, and 18189 the sibling of the loop in the loops tree. 18190 18191 There are other fields in the loop structures, many of them used only 18192by some of the passes, or not updated during CFG changes; in general, 18193they should not be accessed directly. 18194 18195 The most important functions to query loop structures are: 18196 18197 * `flow_loops_dump': Dumps the information about loops to a file. 18198 18199 * `verify_loop_structure': Checks consistency of the loop structures. 18200 18201 * `loop_latch_edge': Returns the latch edge of a loop. 18202 18203 * `loop_preheader_edge': If loops have preheaders, returns the 18204 preheader edge of a loop. 18205 18206 * `flow_loop_nested_p': Tests whether loop is a sub-loop of another 18207 loop. 18208 18209 * `flow_bb_inside_loop_p': Tests whether a basic block belongs to a 18210 loop (including its sub-loops). 18211 18212 * `find_common_loop': Finds the common super-loop of two loops. 18213 18214 * `superloop_at_depth': Returns the super-loop of a loop with the 18215 given depth. 18216 18217 * `tree_num_loop_insns', `num_loop_insns': Estimates the number of 18218 insns in the loop, on GIMPLE and on RTL. 18219 18220 * `loop_exit_edge_p': Tests whether edge is an exit from a loop. 18221 18222 * `mark_loop_exit_edges': Marks all exit edges of all loops with 18223 `EDGE_LOOP_EXIT' flag. 18224 18225 * `get_loop_body', `get_loop_body_in_dom_order', 18226 `get_loop_body_in_bfs_order': Enumerates the basic blocks in the 18227 loop in depth-first search order in reversed CFG, ordered by 18228 dominance relation, and breath-first search order, respectively. 18229 18230 * `single_exit': Returns the single exit edge of the loop, or `NULL' 18231 if the loop has more than one exit. You can only use this 18232 function if LOOPS_HAVE_MARKED_SINGLE_EXITS property is used. 18233 18234 * `get_loop_exit_edges': Enumerates the exit edges of a loop. 18235 18236 * `just_once_each_iteration_p': Returns true if the basic block is 18237 executed exactly once during each iteration of a loop (that is, it 18238 does not belong to a sub-loop, and it dominates the latch of the 18239 loop). 18240 18241 18242File: gccint.info, Node: Loop manipulation, Next: LCSSA, Prev: Loop querying, Up: Loop Analysis and Representation 18243 1824415.3 Loop manipulation 18245====================== 18246 18247The loops tree can be manipulated using the following functions: 18248 18249 * `flow_loop_tree_node_add': Adds a node to the tree. 18250 18251 * `flow_loop_tree_node_remove': Removes a node from the tree. 18252 18253 * `add_bb_to_loop': Adds a basic block to a loop. 18254 18255 * `remove_bb_from_loops': Removes a basic block from loops. 18256 18257 Most low-level CFG functions update loops automatically. The following 18258functions handle some more complicated cases of CFG manipulations: 18259 18260 * `remove_path': Removes an edge and all blocks it dominates. 18261 18262 * `split_loop_exit_edge': Splits exit edge of the loop, ensuring 18263 that PHI node arguments remain in the loop (this ensures that 18264 loop-closed SSA form is preserved). Only useful on GIMPLE. 18265 18266 Finally, there are some higher-level loop transformations implemented. 18267While some of them are written so that they should work on non-innermost 18268loops, they are mostly untested in that case, and at the moment, they 18269are only reliable for the innermost loops: 18270 18271 * `create_iv': Creates a new induction variable. Only works on 18272 GIMPLE. `standard_iv_increment_position' can be used to find a 18273 suitable place for the iv increment. 18274 18275 * `duplicate_loop_to_header_edge', 18276 `tree_duplicate_loop_to_header_edge': These functions (on RTL and 18277 on GIMPLE) duplicate the body of the loop prescribed number of 18278 times on one of the edges entering loop header, thus performing 18279 either loop unrolling or loop peeling. `can_duplicate_loop_p' 18280 (`can_unroll_loop_p' on GIMPLE) must be true for the duplicated 18281 loop. 18282 18283 * `loop_version', `tree_ssa_loop_version': These function create a 18284 copy of a loop, and a branch before them that selects one of them 18285 depending on the prescribed condition. This is useful for 18286 optimizations that need to verify some assumptions in runtime (one 18287 of the copies of the loop is usually left unchanged, while the 18288 other one is transformed in some way). 18289 18290 * `tree_unroll_loop': Unrolls the loop, including peeling the extra 18291 iterations to make the number of iterations divisible by unroll 18292 factor, updating the exit condition, and removing the exits that 18293 now cannot be taken. Works only on GIMPLE. 18294 18295 18296File: gccint.info, Node: LCSSA, Next: Scalar evolutions, Prev: Loop manipulation, Up: Loop Analysis and Representation 18297 1829815.4 Loop-closed SSA form 18299========================= 18300 18301Throughout the loop optimizations on tree level, one extra condition is 18302enforced on the SSA form: No SSA name is used outside of the loop in 18303that it is defined. The SSA form satisfying this condition is called 18304"loop-closed SSA form" - LCSSA. To enforce LCSSA, PHI nodes must be 18305created at the exits of the loops for the SSA names that are used 18306outside of them. Only the real operands (not virtual SSA names) are 18307held in LCSSA, in order to save memory. 18308 18309 There are various benefits of LCSSA: 18310 18311 * Many optimizations (value range analysis, final value replacement) 18312 are interested in the values that are defined in the loop and used 18313 outside of it, i.e., exactly those for that we create new PHI 18314 nodes. 18315 18316 * In induction variable analysis, it is not necessary to specify the 18317 loop in that the analysis should be performed - the scalar 18318 evolution analysis always returns the results with respect to the 18319 loop in that the SSA name is defined. 18320 18321 * It makes updating of SSA form during loop transformations simpler. 18322 Without LCSSA, operations like loop unrolling may force creation 18323 of PHI nodes arbitrarily far from the loop, while in LCSSA, the 18324 SSA form can be updated locally. However, since we only keep real 18325 operands in LCSSA, we cannot use this advantage (we could have 18326 local updating of real operands, but it is not much more efficient 18327 than to use generic SSA form updating for it as well; the amount 18328 of changes to SSA is the same). 18329 18330 However, it also means LCSSA must be updated. This is usually 18331straightforward, unless you create a new value in loop and use it 18332outside, or unless you manipulate loop exit edges (functions are 18333provided to make these manipulations simple). 18334`rewrite_into_loop_closed_ssa' is used to rewrite SSA form to LCSSA, 18335and `verify_loop_closed_ssa' to check that the invariant of LCSSA is 18336preserved. 18337 18338 18339File: gccint.info, Node: Scalar evolutions, Next: loop-iv, Prev: LCSSA, Up: Loop Analysis and Representation 18340 1834115.5 Scalar evolutions 18342====================== 18343 18344Scalar evolutions (SCEV) are used to represent results of induction 18345variable analysis on GIMPLE. They enable us to represent variables with 18346complicated behavior in a simple and consistent way (we only use it to 18347express values of polynomial induction variables, but it is possible to 18348extend it). The interfaces to SCEV analysis are declared in 18349`tree-scalar-evolution.h'. To use scalar evolutions analysis, 18350`scev_initialize' must be used. To stop using SCEV, `scev_finalize' 18351should be used. SCEV analysis caches results in order to save time and 18352memory. This cache however is made invalid by most of the loop 18353transformations, including removal of code. If such a transformation 18354is performed, `scev_reset' must be called to clean the caches. 18355 18356 Given an SSA name, its behavior in loops can be analyzed using the 18357`analyze_scalar_evolution' function. The returned SCEV however does 18358not have to be fully analyzed and it may contain references to other 18359SSA names defined in the loop. To resolve these (potentially 18360recursive) references, `instantiate_parameters' or `resolve_mixers' 18361functions must be used. `instantiate_parameters' is useful when you 18362use the results of SCEV only for some analysis, and when you work with 18363whole nest of loops at once. It will try replacing all SSA names by 18364their SCEV in all loops, including the super-loops of the current loop, 18365thus providing a complete information about the behavior of the 18366variable in the loop nest. `resolve_mixers' is useful if you work with 18367only one loop at a time, and if you possibly need to create code based 18368on the value of the induction variable. It will only resolve the SSA 18369names defined in the current loop, leaving the SSA names defined 18370outside unchanged, even if their evolution in the outer loops is known. 18371 18372 The SCEV is a normal tree expression, except for the fact that it may 18373contain several special tree nodes. One of them is `SCEV_NOT_KNOWN', 18374used for SSA names whose value cannot be expressed. The other one is 18375`POLYNOMIAL_CHREC'. Polynomial chrec has three arguments - base, step 18376and loop (both base and step may contain further polynomial chrecs). 18377Type of the expression and of base and step must be the same. A 18378variable has evolution `POLYNOMIAL_CHREC(base, step, loop)' if it is 18379(in the specified loop) equivalent to `x_1' in the following example 18380 18381 while (...) 18382 { 18383 x_1 = phi (base, x_2); 18384 x_2 = x_1 + step; 18385 } 18386 18387 Note that this includes the language restrictions on the operations. 18388For example, if we compile C code and `x' has signed type, then the 18389overflow in addition would cause undefined behavior, and we may assume 18390that this does not happen. Hence, the value with this SCEV cannot 18391overflow (which restricts the number of iterations of such a loop). 18392 18393 In many cases, one wants to restrict the attention just to affine 18394induction variables. In this case, the extra expressive power of SCEV 18395is not useful, and may complicate the optimizations. In this case, 18396`simple_iv' function may be used to analyze a value - the result is a 18397loop-invariant base and step. 18398 18399 18400File: gccint.info, Node: loop-iv, Next: Number of iterations, Prev: Scalar evolutions, Up: Loop Analysis and Representation 18401 1840215.6 IV analysis on RTL 18403======================= 18404 18405The induction variable on RTL is simple and only allows analysis of 18406affine induction variables, and only in one loop at once. The interface 18407is declared in `cfgloop.h'. Before analyzing induction variables in a 18408loop L, `iv_analysis_loop_init' function must be called on L. After 18409the analysis (possibly calling `iv_analysis_loop_init' for several 18410loops) is finished, `iv_analysis_done' should be called. The following 18411functions can be used to access the results of the analysis: 18412 18413 * `iv_analyze': Analyzes a single register used in the given insn. 18414 If no use of the register in this insn is found, the following 18415 insns are scanned, so that this function can be called on the insn 18416 returned by get_condition. 18417 18418 * `iv_analyze_result': Analyzes result of the assignment in the 18419 given insn. 18420 18421 * `iv_analyze_expr': Analyzes a more complicated expression. All 18422 its operands are analyzed by `iv_analyze', and hence they must be 18423 used in the specified insn or one of the following insns. 18424 18425 The description of the induction variable is provided in `struct 18426rtx_iv'. In order to handle subregs, the representation is a bit 18427complicated; if the value of the `extend' field is not `UNKNOWN', the 18428value of the induction variable in the i-th iteration is 18429 18430 delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)), 18431 18432 with the following exception: if `first_special' is true, then the 18433value in the first iteration (when `i' is zero) is `delta + mult * 18434base'. However, if `extend' is equal to `UNKNOWN', then 18435`first_special' must be false, `delta' 0, `mult' 1 and the value in the 18436i-th iteration is 18437 18438 subreg_{mode} (base + i * step) 18439 18440 The function `get_iv_value' can be used to perform these calculations. 18441 18442 18443File: gccint.info, Node: Number of iterations, Next: Dependency analysis, Prev: loop-iv, Up: Loop Analysis and Representation 18444 1844515.7 Number of iterations analysis 18446================================== 18447 18448Both on GIMPLE and on RTL, there are functions available to determine 18449the number of iterations of a loop, with a similar interface. The 18450number of iterations of a loop in GCC is defined as the number of 18451executions of the loop latch. In many cases, it is not possible to 18452determine the number of iterations unconditionally - the determined 18453number is correct only if some assumptions are satisfied. The analysis 18454tries to verify these conditions using the information contained in the 18455program; if it fails, the conditions are returned together with the 18456result. The following information and conditions are provided by the 18457analysis: 18458 18459 * `assumptions': If this condition is false, the rest of the 18460 information is invalid. 18461 18462 * `noloop_assumptions' on RTL, `may_be_zero' on GIMPLE: If this 18463 condition is true, the loop exits in the first iteration. 18464 18465 * `infinite': If this condition is true, the loop is infinite. This 18466 condition is only available on RTL. On GIMPLE, conditions for 18467 finiteness of the loop are included in `assumptions'. 18468 18469 * `niter_expr' on RTL, `niter' on GIMPLE: The expression that gives 18470 number of iterations. The number of iterations is defined as the 18471 number of executions of the loop latch. 18472 18473 Both on GIMPLE and on RTL, it necessary for the induction variable 18474analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL). 18475On GIMPLE, the results are stored to `struct tree_niter_desc' 18476structure. Number of iterations before the loop is exited through a 18477given exit can be determined using `number_of_iterations_exit' 18478function. On RTL, the results are returned in `struct niter_desc' 18479structure. The corresponding function is named `check_simple_exit'. 18480There are also functions that pass through all the exits of a loop and 18481try to find one with easy to determine number of iterations - 18482`find_loop_niter' on GIMPLE and `find_simple_exit' on RTL. Finally, 18483there are functions that provide the same information, but additionally 18484cache it, so that repeated calls to number of iterations are not so 18485costly - `number_of_latch_executions' on GIMPLE and 18486`get_simple_loop_desc' on RTL. 18487 18488 Note that some of these functions may behave slightly differently than 18489others - some of them return only the expression for the number of 18490iterations, and fail if there are some assumptions. The function 18491`number_of_latch_executions' works only for single-exit loops. The 18492function `number_of_cond_exit_executions' can be used to determine 18493number of executions of the exit condition of a single-exit loop (i.e., 18494the `number_of_latch_executions' increased by one). 18495 18496 18497File: gccint.info, Node: Dependency analysis, Next: Omega, Prev: Number of iterations, Up: Loop Analysis and Representation 18498 1849915.8 Data Dependency Analysis 18500============================= 18501 18502The code for the data dependence analysis can be found in 18503`tree-data-ref.c' and its interface and data structures are described 18504in `tree-data-ref.h'. The function that computes the data dependences 18505for all the array and pointer references for a given loop is 18506`compute_data_dependences_for_loop'. This function is currently used 18507by the linear loop transform and the vectorization passes. Before 18508calling this function, one has to allocate two vectors: a first vector 18509will contain the set of data references that are contained in the 18510analyzed loop body, and the second vector will contain the dependence 18511relations between the data references. Thus if the vector of data 18512references is of size `n', the vector containing the dependence 18513relations will contain `n*n' elements. However if the analyzed loop 18514contains side effects, such as calls that potentially can interfere 18515with the data references in the current analyzed loop, the analysis 18516stops while scanning the loop body for data references, and inserts a 18517single `chrec_dont_know' in the dependence relation array. 18518 18519 The data references are discovered in a particular order during the 18520scanning of the loop body: the loop body is analyzed in execution order, 18521and the data references of each statement are pushed at the end of the 18522data reference array. Two data references syntactically occur in the 18523program in the same order as in the array of data references. This 18524syntactic order is important in some classical data dependence tests, 18525and mapping this order to the elements of this array avoids costly 18526queries to the loop body representation. 18527 18528 Three types of data references are currently handled: ARRAY_REF, 18529INDIRECT_REF and COMPONENT_REF. The data structure for the data 18530reference is `data_reference', where `data_reference_p' is a name of a 18531pointer to the data reference structure. The structure contains the 18532following elements: 18533 18534 * `base_object_info': Provides information about the base object of 18535 the data reference and its access functions. These access functions 18536 represent the evolution of the data reference in the loop relative 18537 to its base, in keeping with the classical meaning of the data 18538 reference access function for the support of arrays. For example, 18539 for a reference `a.b[i][j]', the base object is `a.b' and the 18540 access functions, one for each array subscript, are: `{i_init, + 18541 i_step}_1, {j_init, +, j_step}_2'. 18542 18543 * `first_location_in_loop': Provides information about the first 18544 location accessed by the data reference in the loop and about the 18545 access function used to represent evolution relative to this 18546 location. This data is used to support pointers, and is not used 18547 for arrays (for which we have base objects). Pointer accesses are 18548 represented as a one-dimensional access that starts from the first 18549 location accessed in the loop. For example: 18550 18551 for1 i 18552 for2 j 18553 *((int *)p + i + j) = a[i][j]; 18554 18555 The access function of the pointer access is `{0, + 4B}_for2' 18556 relative to `p + i'. The access functions of the array are 18557 `{i_init, + i_step}_for1' and `{j_init, +, j_step}_for2' relative 18558 to `a'. 18559 18560 Usually, the object the pointer refers to is either unknown, or we 18561 can't prove that the access is confined to the boundaries of a 18562 certain object. 18563 18564 Two data references can be compared only if at least one of these 18565 two representations has all its fields filled for both data 18566 references. 18567 18568 The current strategy for data dependence tests is as follows: If 18569 both `a' and `b' are represented as arrays, compare 18570 `a.base_object' and `b.base_object'; if they are equal, apply 18571 dependence tests (use access functions based on base_objects). 18572 Else if both `a' and `b' are represented as pointers, compare 18573 `a.first_location' and `b.first_location'; if they are equal, 18574 apply dependence tests (use access functions based on first 18575 location). However, if `a' and `b' are represented differently, 18576 only try to prove that the bases are definitely different. 18577 18578 * Aliasing information. 18579 18580 * Alignment information. 18581 18582 The structure describing the relation between two data references is 18583`data_dependence_relation' and the shorter name for a pointer to such a 18584structure is `ddr_p'. This structure contains: 18585 18586 * a pointer to each data reference, 18587 18588 * a tree node `are_dependent' that is set to `chrec_known' if the 18589 analysis has proved that there is no dependence between these two 18590 data references, `chrec_dont_know' if the analysis was not able to 18591 determine any useful result and potentially there could exist a 18592 dependence between these data references, and `are_dependent' is 18593 set to `NULL_TREE' if there exist a dependence relation between the 18594 data references, and the description of this dependence relation is 18595 given in the `subscripts', `dir_vects', and `dist_vects' arrays, 18596 18597 * a boolean that determines whether the dependence relation can be 18598 represented by a classical distance vector, 18599 18600 * an array `subscripts' that contains a description of each 18601 subscript of the data references. Given two array accesses a 18602 subscript is the tuple composed of the access functions for a given 18603 dimension. For example, given `A[f1][f2][f3]' and 18604 `B[g1][g2][g3]', there are three subscripts: `(f1, g1), (f2, g2), 18605 (f3, g3)'. 18606 18607 * two arrays `dir_vects' and `dist_vects' that contain classical 18608 representations of the data dependences under the form of 18609 direction and distance dependence vectors, 18610 18611 * an array of loops `loop_nest' that contains the loops to which the 18612 distance and direction vectors refer to. 18613 18614 Several functions for pretty printing the information extracted by the 18615data dependence analysis are available: `dump_ddrs' prints with a 18616maximum verbosity the details of a data dependence relations array, 18617`dump_dist_dir_vectors' prints only the classical distance and 18618direction vectors for a data dependence relations array, and 18619`dump_data_references' prints the details of the data references 18620contained in a data reference array. 18621 18622 18623File: gccint.info, Node: Omega, Prev: Dependency analysis, Up: Loop Analysis and Representation 18624 1862515.9 Omega a solver for linear programming problems 18626=================================================== 18627 18628The data dependence analysis contains several solvers triggered 18629sequentially from the less complex ones to the more sophisticated. For 18630ensuring the consistency of the results of these solvers, a data 18631dependence check pass has been implemented based on two different 18632solvers. The second method that has been integrated to GCC is based on 18633the Omega dependence solver, written in the 1990's by William Pugh and 18634David Wonnacott. Data dependence tests can be formulated using a 18635subset of the Presburger arithmetics that can be translated to linear 18636constraint systems. These linear constraint systems can then be solved 18637using the Omega solver. 18638 18639 The Omega solver is using Fourier-Motzkin's algorithm for variable 18640elimination: a linear constraint system containing `n' variables is 18641reduced to a linear constraint system with `n-1' variables. The Omega 18642solver can also be used for solving other problems that can be 18643expressed under the form of a system of linear equalities and 18644inequalities. The Omega solver is known to have an exponential worst 18645case, also known under the name of "omega nightmare" in the literature, 18646but in practice, the omega test is known to be efficient for the common 18647data dependence tests. 18648 18649 The interface used by the Omega solver for describing the linear 18650programming problems is described in `omega.h', and the solver is 18651`omega_solve_problem'. 18652 18653 18654File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: Loop Analysis and Representation, Up: Top 18655 1865616 Machine Descriptions 18657*********************** 18658 18659A machine description has two parts: a file of instruction patterns 18660(`.md' file) and a C header file of macro definitions. 18661 18662 The `.md' file for a target machine contains a pattern for each 18663instruction that the target machine supports (or at least each 18664instruction that is worth telling the compiler about). It may also 18665contain comments. A semicolon causes the rest of the line to be a 18666comment, unless the semicolon is inside a quoted string. 18667 18668 See the next chapter for information on the C header file. 18669 18670* Menu: 18671 18672* Overview:: How the machine description is used. 18673* Patterns:: How to write instruction patterns. 18674* Example:: An explained example of a `define_insn' pattern. 18675* RTL Template:: The RTL template defines what insns match a pattern. 18676* Output Template:: The output template says how to make assembler code 18677 from such an insn. 18678* Output Statement:: For more generality, write C code to output 18679 the assembler code. 18680* Predicates:: Controlling what kinds of operands can be used 18681 for an insn. 18682* Constraints:: Fine-tuning operand selection. 18683* Standard Names:: Names mark patterns to use for code generation. 18684* Pattern Ordering:: When the order of patterns makes a difference. 18685* Dependent Patterns:: Having one pattern may make you need another. 18686* Jump Patterns:: Special considerations for patterns for jump insns. 18687* Looping Patterns:: How to define patterns for special looping insns. 18688* Insn Canonicalizations::Canonicalization of Instructions 18689* Expander Definitions::Generating a sequence of several RTL insns 18690 for a standard operation. 18691* Insn Splitting:: Splitting Instructions into Multiple Instructions. 18692* Including Patterns:: Including Patterns in Machine Descriptions. 18693* Peephole Definitions::Defining machine-specific peephole optimizations. 18694* Insn Attributes:: Specifying the value of attributes for generated insns. 18695* Conditional Execution::Generating `define_insn' patterns for 18696 predication. 18697* Define Subst:: Generating `define_insn' and `define_expand' 18698 patterns from other patterns. 18699* Constant Definitions::Defining symbolic constants that can be used in the 18700 md file. 18701* Iterators:: Using iterators to generate patterns from a template. 18702 18703 18704File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc 18705 1870616.1 Overview of How the Machine Description is Used 18707==================================================== 18708 18709There are three main conversions that happen in the compiler: 18710 18711 1. The front end reads the source code and builds a parse tree. 18712 18713 2. The parse tree is used to generate an RTL insn list based on named 18714 instruction patterns. 18715 18716 3. The insn list is matched against the RTL templates to produce 18717 assembler code. 18718 18719 18720 For the generate pass, only the names of the insns matter, from either 18721a named `define_insn' or a `define_expand'. The compiler will choose 18722the pattern with the right name and apply the operands according to the 18723documentation later in this chapter, without regard for the RTL 18724template or operand constraints. Note that the names the compiler looks 18725for are hard-coded in the compiler--it will ignore unnamed patterns and 18726patterns with names it doesn't know about, but if you don't provide a 18727named pattern it needs, it will abort. 18728 18729 If a `define_insn' is used, the template given is inserted into the 18730insn list. If a `define_expand' is used, one of three things happens, 18731based on the condition logic. The condition logic may manually create 18732new insns for the insn list, say via `emit_insn()', and invoke `DONE'. 18733For certain named patterns, it may invoke `FAIL' to tell the compiler 18734to use an alternate way of performing that task. If it invokes neither 18735`DONE' nor `FAIL', the template given in the pattern is inserted, as if 18736the `define_expand' were a `define_insn'. 18737 18738 Once the insn list is generated, various optimization passes convert, 18739replace, and rearrange the insns in the insn list. This is where the 18740`define_split' and `define_peephole' patterns get used, for example. 18741 18742 Finally, the insn list's RTL is matched up with the RTL templates in 18743the `define_insn' patterns, and those patterns are used to emit the 18744final assembly code. For this purpose, each named `define_insn' acts 18745like it's unnamed, since the names are ignored. 18746 18747 18748File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc 18749 1875016.2 Everything about Instruction Patterns 18751========================================== 18752 18753A `define_insn' expression is used to define instruction patterns to 18754which insns may be matched. A `define_insn' expression contains an 18755incomplete RTL expression, with pieces to be filled in later, operand 18756constraints that restrict how the pieces can be filled in, and an output 18757template or C code to generate the assembler output. 18758 18759 A `define_insn' is an RTL expression containing four or five operands: 18760 18761 1. An optional name. The presence of a name indicate that this 18762 instruction pattern can perform a certain standard job for the 18763 RTL-generation pass of the compiler. This pass knows certain 18764 names and will use the instruction patterns with those names, if 18765 the names are defined in the machine description. 18766 18767 The absence of a name is indicated by writing an empty string 18768 where the name should go. Nameless instruction patterns are never 18769 used for generating RTL code, but they may permit several simpler 18770 insns to be combined later on. 18771 18772 Names that are not thus known and used in RTL-generation have no 18773 effect; they are equivalent to no name at all. 18774 18775 For the purpose of debugging the compiler, you may also specify a 18776 name beginning with the `*' character. Such a name is used only 18777 for identifying the instruction in RTL dumps; it is equivalent to 18778 having a nameless pattern for all other purposes. Names beginning 18779 with the `*' character are not required to be unique. 18780 18781 2. The "RTL template": This is a vector of incomplete RTL expressions 18782 which describe the semantics of the instruction (*note RTL 18783 Template::). It is incomplete because it may contain 18784 `match_operand', `match_operator', and `match_dup' expressions 18785 that stand for operands of the instruction. 18786 18787 If the vector has multiple elements, the RTL template is treated 18788 as a `parallel' expression. 18789 18790 3. The condition: This is a string which contains a C expression. 18791 When the compiler attempts to match RTL against a pattern, the 18792 condition is evaluated. If the condition evaluates to `true', the 18793 match is permitted. The condition may be an empty string, which 18794 is treated as always `true'. 18795 18796 For a named pattern, the condition may not depend on the data in 18797 the insn being matched, but only the target-machine-type flags. 18798 The compiler needs to test these conditions during initialization 18799 in order to learn exactly which named instructions are available 18800 in a particular run. 18801 18802 For nameless patterns, the condition is applied only when matching 18803 an individual insn, and only after the insn has matched the 18804 pattern's recognition template. The insn's operands may be found 18805 in the vector `operands'. 18806 18807 For an insn where the condition has once matched, it cannot later 18808 be used to control register allocation by excluding certain 18809 register or value combinations. 18810 18811 4. The "output template" or "output statement": This is either a 18812 string, or a fragment of C code which returns a string. 18813 18814 When simple substitution isn't general enough, you can specify a 18815 piece of C code to compute the output. *Note Output Statement::. 18816 18817 5. The "insn attributes": This is an optional vector containing the 18818 values of attributes for insns matching this pattern (*note Insn 18819 Attributes::). 18820 18821 18822File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc 18823 1882416.3 Example of `define_insn' 18825============================= 18826 18827Here is an example of an instruction pattern, taken from the machine 18828description for the 68000/68020. 18829 18830 (define_insn "tstsi" 18831 [(set (cc0) 18832 (match_operand:SI 0 "general_operand" "rm"))] 18833 "" 18834 "* 18835 { 18836 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 18837 return \"tstl %0\"; 18838 return \"cmpl #0,%0\"; 18839 }") 18840 18841This can also be written using braced strings: 18842 18843 (define_insn "tstsi" 18844 [(set (cc0) 18845 (match_operand:SI 0 "general_operand" "rm"))] 18846 "" 18847 { 18848 if (TARGET_68020 || ! ADDRESS_REG_P (operands[0])) 18849 return "tstl %0"; 18850 return "cmpl #0,%0"; 18851 }) 18852 18853 This describes an instruction which sets the condition codes based on 18854the value of a general operand. It has no condition, so any insn with 18855an RTL description of the form shown may be matched to this pattern. 18856The name `tstsi' means "test a `SImode' value" and tells the RTL 18857generation pass that, when it is necessary to test such a value, an insn 18858to do so can be constructed using this pattern. 18859 18860 The output control string is a piece of C code which chooses which 18861output template to return based on the kind of operand and the specific 18862type of CPU for which code is being generated. 18863 18864 `"rm"' is an operand constraint. Its meaning is explained below. 18865 18866 18867File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc 18868 1886916.4 RTL Template 18870================= 18871 18872The RTL template is used to define which insns match the particular 18873pattern and how to find their operands. For named patterns, the RTL 18874template also says how to construct an insn from specified operands. 18875 18876 Construction involves substituting specified operands into a copy of 18877the template. Matching involves determining the values that serve as 18878the operands in the insn being matched. Both of these activities are 18879controlled by special expression types that direct matching and 18880substitution of the operands. 18881 18882`(match_operand:M N PREDICATE CONSTRAINT)' 18883 This expression is a placeholder for operand number N of the insn. 18884 When constructing an insn, operand number N will be substituted at 18885 this point. When matching an insn, whatever appears at this 18886 position in the insn will be taken as operand number N; but it 18887 must satisfy PREDICATE or this instruction pattern will not match 18888 at all. 18889 18890 Operand numbers must be chosen consecutively counting from zero in 18891 each instruction pattern. There may be only one `match_operand' 18892 expression in the pattern for each operand number. Usually 18893 operands are numbered in the order of appearance in `match_operand' 18894 expressions. In the case of a `define_expand', any operand numbers 18895 used only in `match_dup' expressions have higher values than all 18896 other operand numbers. 18897 18898 PREDICATE is a string that is the name of a function that accepts 18899 two arguments, an expression and a machine mode. *Note 18900 Predicates::. During matching, the function will be called with 18901 the putative operand as the expression and M as the mode argument 18902 (if M is not specified, `VOIDmode' will be used, which normally 18903 causes PREDICATE to accept any mode). If it returns zero, this 18904 instruction pattern fails to match. PREDICATE may be an empty 18905 string; then it means no test is to be done on the operand, so 18906 anything which occurs in this position is valid. 18907 18908 Most of the time, PREDICATE will reject modes other than M--but 18909 not always. For example, the predicate `address_operand' uses M 18910 as the mode of memory ref that the address should be valid for. 18911 Many predicates accept `const_int' nodes even though their mode is 18912 `VOIDmode'. 18913 18914 CONSTRAINT controls reloading and the choice of the best register 18915 class to use for a value, as explained later (*note Constraints::). 18916 If the constraint would be an empty string, it can be omitted. 18917 18918 People are often unclear on the difference between the constraint 18919 and the predicate. The predicate helps decide whether a given 18920 insn matches the pattern. The constraint plays no role in this 18921 decision; instead, it controls various decisions in the case of an 18922 insn which does match. 18923 18924`(match_scratch:M N CONSTRAINT)' 18925 This expression is also a placeholder for operand number N and 18926 indicates that operand must be a `scratch' or `reg' expression. 18927 18928 When matching patterns, this is equivalent to 18929 18930 (match_operand:M N "scratch_operand" CONSTRAINT) 18931 18932 but, when generating RTL, it produces a (`scratch':M) expression. 18933 18934 If the last few expressions in a `parallel' are `clobber' 18935 expressions whose operands are either a hard register or 18936 `match_scratch', the combiner can add or delete them when 18937 necessary. *Note Side Effects::. 18938 18939`(match_dup N)' 18940 This expression is also a placeholder for operand number N. It is 18941 used when the operand needs to appear more than once in the insn. 18942 18943 In construction, `match_dup' acts just like `match_operand': the 18944 operand is substituted into the insn being constructed. But in 18945 matching, `match_dup' behaves differently. It assumes that operand 18946 number N has already been determined by a `match_operand' 18947 appearing earlier in the recognition template, and it matches only 18948 an identical-looking expression. 18949 18950 Note that `match_dup' should not be used to tell the compiler that 18951 a particular register is being used for two operands (example: 18952 `add' that adds one register to another; the second register is 18953 both an input operand and the output operand). Use a matching 18954 constraint (*note Simple Constraints::) for those. `match_dup' is 18955 for the cases where one operand is used in two places in the 18956 template, such as an instruction that computes both a quotient and 18957 a remainder, where the opcode takes two input operands but the RTL 18958 template has to refer to each of those twice; once for the 18959 quotient pattern and once for the remainder pattern. 18960 18961`(match_operator:M N PREDICATE [OPERANDS...])' 18962 This pattern is a kind of placeholder for a variable RTL expression 18963 code. 18964 18965 When constructing an insn, it stands for an RTL expression whose 18966 expression code is taken from that of operand N, and whose 18967 operands are constructed from the patterns OPERANDS. 18968 18969 When matching an expression, it matches an expression if the 18970 function PREDICATE returns nonzero on that expression _and_ the 18971 patterns OPERANDS match the operands of the expression. 18972 18973 Suppose that the function `commutative_operator' is defined as 18974 follows, to match any expression whose operator is one of the 18975 commutative arithmetic operators of RTL and whose mode is MODE: 18976 18977 int 18978 commutative_integer_operator (x, mode) 18979 rtx x; 18980 machine_mode mode; 18981 { 18982 enum rtx_code code = GET_CODE (x); 18983 if (GET_MODE (x) != mode) 18984 return 0; 18985 return (GET_RTX_CLASS (code) == RTX_COMM_ARITH 18986 || code == EQ || code == NE); 18987 } 18988 18989 Then the following pattern will match any RTL expression consisting 18990 of a commutative operator applied to two general operands: 18991 18992 (match_operator:SI 3 "commutative_operator" 18993 [(match_operand:SI 1 "general_operand" "g") 18994 (match_operand:SI 2 "general_operand" "g")]) 18995 18996 Here the vector `[OPERANDS...]' contains two patterns because the 18997 expressions to be matched all contain two operands. 18998 18999 When this pattern does match, the two operands of the commutative 19000 operator are recorded as operands 1 and 2 of the insn. (This is 19001 done by the two instances of `match_operand'.) Operand 3 of the 19002 insn will be the entire commutative expression: use `GET_CODE 19003 (operands[3])' to see which commutative operator was used. 19004 19005 The machine mode M of `match_operator' works like that of 19006 `match_operand': it is passed as the second argument to the 19007 predicate function, and that function is solely responsible for 19008 deciding whether the expression to be matched "has" that mode. 19009 19010 When constructing an insn, argument 3 of the gen-function will 19011 specify the operation (i.e. the expression code) for the 19012 expression to be made. It should be an RTL expression, whose 19013 expression code is copied into a new expression whose operands are 19014 arguments 1 and 2 of the gen-function. The subexpressions of 19015 argument 3 are not used; only its expression code matters. 19016 19017 When `match_operator' is used in a pattern for matching an insn, 19018 it usually best if the operand number of the `match_operator' is 19019 higher than that of the actual operands of the insn. This improves 19020 register allocation because the register allocator often looks at 19021 operands 1 and 2 of insns to see if it can do register tying. 19022 19023 There is no way to specify constraints in `match_operator'. The 19024 operand of the insn which corresponds to the `match_operator' 19025 never has any constraints because it is never reloaded as a whole. 19026 However, if parts of its OPERANDS are matched by `match_operand' 19027 patterns, those parts may have constraints of their own. 19028 19029`(match_op_dup:M N[OPERANDS...])' 19030 Like `match_dup', except that it applies to operators instead of 19031 operands. When constructing an insn, operand number N will be 19032 substituted at this point. But in matching, `match_op_dup' behaves 19033 differently. It assumes that operand number N has already been 19034 determined by a `match_operator' appearing earlier in the 19035 recognition template, and it matches only an identical-looking 19036 expression. 19037 19038`(match_parallel N PREDICATE [SUBPAT...])' 19039 This pattern is a placeholder for an insn that consists of a 19040 `parallel' expression with a variable number of elements. This 19041 expression should only appear at the top level of an insn pattern. 19042 19043 When constructing an insn, operand number N will be substituted at 19044 this point. When matching an insn, it matches if the body of the 19045 insn is a `parallel' expression with at least as many elements as 19046 the vector of SUBPAT expressions in the `match_parallel', if each 19047 SUBPAT matches the corresponding element of the `parallel', _and_ 19048 the function PREDICATE returns nonzero on the `parallel' that is 19049 the body of the insn. It is the responsibility of the predicate 19050 to validate elements of the `parallel' beyond those listed in the 19051 `match_parallel'. 19052 19053 A typical use of `match_parallel' is to match load and store 19054 multiple expressions, which can contain a variable number of 19055 elements in a `parallel'. For example, 19056 19057 (define_insn "" 19058 [(match_parallel 0 "load_multiple_operation" 19059 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 19060 (match_operand:SI 2 "memory_operand" "m")) 19061 (use (reg:SI 179)) 19062 (clobber (reg:SI 179))])] 19063 "" 19064 "loadm 0,0,%1,%2") 19065 19066 This example comes from `a29k.md'. The function 19067 `load_multiple_operation' is defined in `a29k.c' and checks that 19068 subsequent elements in the `parallel' are the same as the `set' in 19069 the pattern, except that they are referencing subsequent registers 19070 and memory locations. 19071 19072 An insn that matches this pattern might look like: 19073 19074 (parallel 19075 [(set (reg:SI 20) (mem:SI (reg:SI 100))) 19076 (use (reg:SI 179)) 19077 (clobber (reg:SI 179)) 19078 (set (reg:SI 21) 19079 (mem:SI (plus:SI (reg:SI 100) 19080 (const_int 4)))) 19081 (set (reg:SI 22) 19082 (mem:SI (plus:SI (reg:SI 100) 19083 (const_int 8))))]) 19084 19085`(match_par_dup N [SUBPAT...])' 19086 Like `match_op_dup', but for `match_parallel' instead of 19087 `match_operator'. 19088 19089 19090 19091File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc 19092 1909316.5 Output Templates and Operand Substitution 19094============================================== 19095 19096The "output template" is a string which specifies how to output the 19097assembler code for an instruction pattern. Most of the template is a 19098fixed string which is output literally. The character `%' is used to 19099specify where to substitute an operand; it can also be used to identify 19100places where different variants of the assembler require different 19101syntax. 19102 19103 In the simplest case, a `%' followed by a digit N says to output 19104operand N at that point in the string. 19105 19106 `%' followed by a letter and a digit says to output an operand in an 19107alternate fashion. Four letters have standard, built-in meanings 19108described below. The machine description macro `PRINT_OPERAND' can 19109define additional letters with nonstandard meanings. 19110 19111 `%cDIGIT' can be used to substitute an operand that is a constant 19112value without the syntax that normally indicates an immediate operand. 19113 19114 `%nDIGIT' is like `%cDIGIT' except that the value of the constant is 19115negated before printing. 19116 19117 `%aDIGIT' can be used to substitute an operand as if it were a memory 19118reference, with the actual operand treated as the address. This may be 19119useful when outputting a "load address" instruction, because often the 19120assembler syntax for such an instruction requires you to write the 19121operand as if it were a memory reference. 19122 19123 `%lDIGIT' is used to substitute a `label_ref' into a jump instruction. 19124 19125 `%=' outputs a number which is unique to each instruction in the 19126entire compilation. This is useful for making local labels to be 19127referred to more than once in a single template that generates multiple 19128assembler instructions. 19129 19130 `%' followed by a punctuation character specifies a substitution that 19131does not use an operand. Only one case is standard: `%%' outputs a `%' 19132into the assembler code. Other nonstandard cases can be defined in the 19133`PRINT_OPERAND' macro. You must also define which punctuation 19134characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro. 19135 19136 The template may generate multiple assembler instructions. Write the 19137text for the instructions, with `\;' between them. 19138 19139 When the RTL contains two operands which are required by constraint to 19140match each other, the output template must refer only to the 19141lower-numbered operand. Matching operands are not always identical, 19142and the rest of the compiler arranges to put the proper RTL expression 19143for printing into the lower-numbered operand. 19144 19145 One use of nonstandard letters or punctuation following `%' is to 19146distinguish between different assembler languages for the same machine; 19147for example, Motorola syntax versus MIT syntax for the 68000. Motorola 19148syntax requires periods in most opcode names, while MIT syntax does 19149not. For example, the opcode `movel' in MIT syntax is `move.l' in 19150Motorola syntax. The same file of patterns is used for both kinds of 19151output syntax, but the character sequence `%.' is used in each place 19152where Motorola syntax wants a period. The `PRINT_OPERAND' macro for 19153Motorola syntax defines the sequence to output a period; the macro for 19154MIT syntax defines it to do nothing. 19155 19156 As a special case, a template consisting of the single character `#' 19157instructs the compiler to first split the insn, and then output the 19158resulting instructions separately. This helps eliminate redundancy in 19159the output templates. If you have a `define_insn' that needs to emit 19160multiple assembler instructions, and there is a matching `define_split' 19161already defined, then you can simply use `#' as the output template 19162instead of writing an output template that emits the multiple assembler 19163instructions. 19164 19165 If the macro `ASSEMBLER_DIALECT' is defined, you can use construct of 19166the form `{option0|option1|option2}' in the templates. These describe 19167multiple variants of assembler language syntax. *Note Instruction 19168Output::. 19169 19170 19171File: gccint.info, Node: Output Statement, Next: Predicates, Prev: Output Template, Up: Machine Desc 19172 1917316.6 C Statements for Assembler Output 19174====================================== 19175 19176Often a single fixed template string cannot produce correct and 19177efficient assembler code for all the cases that are recognized by a 19178single instruction pattern. For example, the opcodes may depend on the 19179kinds of operands; or some unfortunate combinations of operands may 19180require extra machine instructions. 19181 19182 If the output control string starts with a `@', then it is actually a 19183series of templates, each on a separate line. (Blank lines and leading 19184spaces and tabs are ignored.) The templates correspond to the 19185pattern's constraint alternatives (*note Multi-Alternative::). For 19186example, if a target machine has a two-address add instruction `addr' 19187to add into a register and another `addm' to add a register to memory, 19188you might write this pattern: 19189 19190 (define_insn "addsi3" 19191 [(set (match_operand:SI 0 "general_operand" "=r,m") 19192 (plus:SI (match_operand:SI 1 "general_operand" "0,0") 19193 (match_operand:SI 2 "general_operand" "g,r")))] 19194 "" 19195 "@ 19196 addr %2,%0 19197 addm %2,%0") 19198 19199 If the output control string starts with a `*', then it is not an 19200output template but rather a piece of C program that should compute a 19201template. It should execute a `return' statement to return the 19202template-string you want. Most such templates use C string literals, 19203which require doublequote characters to delimit them. To include these 19204doublequote characters in the string, prefix each one with `\'. 19205 19206 If the output control string is written as a brace block instead of a 19207double-quoted string, it is automatically assumed to be C code. In that 19208case, it is not necessary to put in a leading asterisk, or to escape the 19209doublequotes surrounding C string literals. 19210 19211 The operands may be found in the array `operands', whose C data type 19212is `rtx []'. 19213 19214 It is very common to select different ways of generating assembler code 19215based on whether an immediate operand is within a certain range. Be 19216careful when doing this, because the result of `INTVAL' is an integer 19217on the host machine. If the host machine has more bits in an `int' 19218than the target machine has in the mode in which the constant will be 19219used, then some of the bits you get from `INTVAL' will be superfluous. 19220For proper results, you must carefully disregard the values of those 19221bits. 19222 19223 It is possible to output an assembler instruction and then go on to 19224output or compute more of them, using the subroutine `output_asm_insn'. 19225This receives two arguments: a template-string and a vector of 19226operands. The vector may be `operands', or it may be another array of 19227`rtx' that you declare locally and initialize yourself. 19228 19229 When an insn pattern has multiple alternatives in its constraints, 19230often the appearance of the assembler code is determined mostly by 19231which alternative was matched. When this is so, the C code can test 19232the variable `which_alternative', which is the ordinal number of the 19233alternative that was actually satisfied (0 for the first, 1 for the 19234second alternative, etc.). 19235 19236 For example, suppose there are two opcodes for storing zero, `clrreg' 19237for registers and `clrmem' for memory locations. Here is how a pattern 19238could use `which_alternative' to choose between them: 19239 19240 (define_insn "" 19241 [(set (match_operand:SI 0 "general_operand" "=r,m") 19242 (const_int 0))] 19243 "" 19244 { 19245 return (which_alternative == 0 19246 ? "clrreg %0" : "clrmem %0"); 19247 }) 19248 19249 The example above, where the assembler code to generate was _solely_ 19250determined by the alternative, could also have been specified as 19251follows, having the output control string start with a `@': 19252 19253 (define_insn "" 19254 [(set (match_operand:SI 0 "general_operand" "=r,m") 19255 (const_int 0))] 19256 "" 19257 "@ 19258 clrreg %0 19259 clrmem %0") 19260 19261 If you just need a little bit of C code in one (or a few) alternatives, 19262you can use `*' inside of a `@' multi-alternative template: 19263 19264 (define_insn "" 19265 [(set (match_operand:SI 0 "general_operand" "=r,<,m") 19266 (const_int 0))] 19267 "" 19268 "@ 19269 clrreg %0 19270 * return stack_mem_p (operands[0]) ? \"push 0\" : \"clrmem %0\"; 19271 clrmem %0") 19272 19273 19274File: gccint.info, Node: Predicates, Next: Constraints, Prev: Output Statement, Up: Machine Desc 19275 1927616.7 Predicates 19277=============== 19278 19279A predicate determines whether a `match_operand' or `match_operator' 19280expression matches, and therefore whether the surrounding instruction 19281pattern will be used for that combination of operands. GCC has a 19282number of machine-independent predicates, and you can define 19283machine-specific predicates as needed. By convention, predicates used 19284with `match_operand' have names that end in `_operand', and those used 19285with `match_operator' have names that end in `_operator'. 19286 19287 All predicates are Boolean functions (in the mathematical sense) of 19288two arguments: the RTL expression that is being considered at that 19289position in the instruction pattern, and the machine mode that the 19290`match_operand' or `match_operator' specifies. In this section, the 19291first argument is called OP and the second argument MODE. Predicates 19292can be called from C as ordinary two-argument functions; this can be 19293useful in output templates or other machine-specific code. 19294 19295 Operand predicates can allow operands that are not actually acceptable 19296to the hardware, as long as the constraints give reload the ability to 19297fix them up (*note Constraints::). However, GCC will usually generate 19298better code if the predicates specify the requirements of the machine 19299instructions as closely as possible. Reload cannot fix up operands 19300that must be constants ("immediate operands"); you must use a predicate 19301that allows only constants, or else enforce the requirement in the 19302extra condition. 19303 19304 Most predicates handle their MODE argument in a uniform manner. If 19305MODE is `VOIDmode' (unspecified), then OP can have any mode. If MODE 19306is anything else, then OP must have the same mode, unless OP is a 19307`CONST_INT' or integer `CONST_DOUBLE'. These RTL expressions always 19308have `VOIDmode', so it would be counterproductive to check that their 19309mode matches. Instead, predicates that accept `CONST_INT' and/or 19310integer `CONST_DOUBLE' check that the value stored in the constant will 19311fit in the requested mode. 19312 19313 Predicates with this behavior are called "normal". `genrecog' can 19314optimize the instruction recognizer based on knowledge of how normal 19315predicates treat modes. It can also diagnose certain kinds of common 19316errors in the use of normal predicates; for instance, it is almost 19317always an error to use a normal predicate without specifying a mode. 19318 19319 Predicates that do something different with their MODE argument are 19320called "special". The generic predicates `address_operand' and 19321`pmode_register_operand' are special predicates. `genrecog' does not 19322do any optimizations or diagnosis when special predicates are used. 19323 19324* Menu: 19325 19326* Machine-Independent Predicates:: Predicates available to all back ends. 19327* Defining Predicates:: How to write machine-specific predicate 19328 functions. 19329 19330 19331File: gccint.info, Node: Machine-Independent Predicates, Next: Defining Predicates, Up: Predicates 19332 1933316.7.1 Machine-Independent Predicates 19334------------------------------------- 19335 19336These are the generic predicates available to all back ends. They are 19337defined in `recog.c'. The first category of predicates allow only 19338constant, or "immediate", operands. 19339 19340 -- Function: immediate_operand 19341 This predicate allows any sort of constant that fits in MODE. It 19342 is an appropriate choice for instructions that take operands that 19343 must be constant. 19344 19345 -- Function: const_int_operand 19346 This predicate allows any `CONST_INT' expression that fits in 19347 MODE. It is an appropriate choice for an immediate operand that 19348 does not allow a symbol or label. 19349 19350 -- Function: const_double_operand 19351 This predicate accepts any `CONST_DOUBLE' expression that has 19352 exactly MODE. If MODE is `VOIDmode', it will also accept 19353 `CONST_INT'. It is intended for immediate floating point 19354 constants. 19355 19356The second category of predicates allow only some kind of machine 19357register. 19358 19359 -- Function: register_operand 19360 This predicate allows any `REG' or `SUBREG' expression that is 19361 valid for MODE. It is often suitable for arithmetic instruction 19362 operands on a RISC machine. 19363 19364 -- Function: pmode_register_operand 19365 This is a slight variant on `register_operand' which works around 19366 a limitation in the machine-description reader. 19367 19368 (match_operand N "pmode_register_operand" CONSTRAINT) 19369 19370 means exactly what 19371 19372 (match_operand:P N "register_operand" CONSTRAINT) 19373 19374 would mean, if the machine-description reader accepted `:P' mode 19375 suffixes. Unfortunately, it cannot, because `Pmode' is an alias 19376 for some other mode, and might vary with machine-specific options. 19377 *Note Misc::. 19378 19379 -- Function: scratch_operand 19380 This predicate allows hard registers and `SCRATCH' expressions, 19381 but not pseudo-registers. It is used internally by 19382 `match_scratch'; it should not be used directly. 19383 19384The third category of predicates allow only some kind of memory 19385reference. 19386 19387 -- Function: memory_operand 19388 This predicate allows any valid reference to a quantity of mode 19389 MODE in memory, as determined by the weak form of 19390 `GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::). 19391 19392 -- Function: address_operand 19393 This predicate is a little unusual; it allows any operand that is a 19394 valid expression for the _address_ of a quantity of mode MODE, 19395 again determined by the weak form of `GO_IF_LEGITIMATE_ADDRESS'. 19396 To first order, if `(mem:MODE (EXP))' is acceptable to 19397 `memory_operand', then EXP is acceptable to `address_operand'. 19398 Note that EXP does not necessarily have the mode MODE. 19399 19400 -- Function: indirect_operand 19401 This is a stricter form of `memory_operand' which allows only 19402 memory references with a `general_operand' as the address 19403 expression. New uses of this predicate are discouraged, because 19404 `general_operand' is very permissive, so it's hard to tell what an 19405 `indirect_operand' does or does not allow. If a target has 19406 different requirements for memory operands for different 19407 instructions, it is better to define target-specific predicates 19408 which enforce the hardware's requirements explicitly. 19409 19410 -- Function: push_operand 19411 This predicate allows a memory reference suitable for pushing a 19412 value onto the stack. This will be a `MEM' which refers to 19413 `stack_pointer_rtx', with a side-effect in its address expression 19414 (*note Incdec::); which one is determined by the `STACK_PUSH_CODE' 19415 macro (*note Frame Layout::). 19416 19417 -- Function: pop_operand 19418 This predicate allows a memory reference suitable for popping a 19419 value off the stack. Again, this will be a `MEM' referring to 19420 `stack_pointer_rtx', with a side-effect in its address expression. 19421 However, this time `STACK_POP_CODE' is expected. 19422 19423The fourth category of predicates allow some combination of the above 19424operands. 19425 19426 -- Function: nonmemory_operand 19427 This predicate allows any immediate or register operand valid for 19428 MODE. 19429 19430 -- Function: nonimmediate_operand 19431 This predicate allows any register or memory operand valid for 19432 MODE. 19433 19434 -- Function: general_operand 19435 This predicate allows any immediate, register, or memory operand 19436 valid for MODE. 19437 19438Finally, there are two generic operator predicates. 19439 19440 -- Function: comparison_operator 19441 This predicate matches any expression which performs an arithmetic 19442 comparison in MODE; that is, `COMPARISON_P' is true for the 19443 expression code. 19444 19445 -- Function: ordered_comparison_operator 19446 This predicate matches any expression which performs an arithmetic 19447 comparison in MODE and whose expression code is valid for integer 19448 modes; that is, the expression code will be one of `eq', `ne', 19449 `lt', `ltu', `le', `leu', `gt', `gtu', `ge', `geu'. 19450 19451 19452File: gccint.info, Node: Defining Predicates, Prev: Machine-Independent Predicates, Up: Predicates 19453 1945416.7.2 Defining Machine-Specific Predicates 19455------------------------------------------- 19456 19457Many machines have requirements for their operands that cannot be 19458expressed precisely using the generic predicates. You can define 19459additional predicates using `define_predicate' and 19460`define_special_predicate' expressions. These expressions have three 19461operands: 19462 19463 * The name of the predicate, as it will be referred to in 19464 `match_operand' or `match_operator' expressions. 19465 19466 * An RTL expression which evaluates to true if the predicate allows 19467 the operand OP, false if it does not. This expression can only use 19468 the following RTL codes: 19469 19470 `MATCH_OPERAND' 19471 When written inside a predicate expression, a `MATCH_OPERAND' 19472 expression evaluates to true if the predicate it names would 19473 allow OP. The operand number and constraint are ignored. 19474 Due to limitations in `genrecog', you can only refer to 19475 generic predicates and predicates that have already been 19476 defined. 19477 19478 `MATCH_CODE' 19479 This expression evaluates to true if OP or a specified 19480 subexpression of OP has one of a given list of RTX codes. 19481 19482 The first operand of this expression is a string constant 19483 containing a comma-separated list of RTX code names (in lower 19484 case). These are the codes for which the `MATCH_CODE' will 19485 be true. 19486 19487 The second operand is a string constant which indicates what 19488 subexpression of OP to examine. If it is absent or the empty 19489 string, OP itself is examined. Otherwise, the string constant 19490 must be a sequence of digits and/or lowercase letters. Each 19491 character indicates a subexpression to extract from the 19492 current expression; for the first character this is OP, for 19493 the second and subsequent characters it is the result of the 19494 previous character. A digit N extracts `XEXP (E, N)'; a 19495 letter L extracts `XVECEXP (E, 0, N)' where N is the 19496 alphabetic ordinal of L (0 for `a', 1 for 'b', and so on). 19497 The `MATCH_CODE' then examines the RTX code of the 19498 subexpression extracted by the complete string. It is not 19499 possible to extract components of an `rtvec' that is not at 19500 position 0 within its RTX object. 19501 19502 `MATCH_TEST' 19503 This expression has one operand, a string constant containing 19504 a C expression. The predicate's arguments, OP and MODE, are 19505 available with those names in the C expression. The 19506 `MATCH_TEST' evaluates to true if the C expression evaluates 19507 to a nonzero value. `MATCH_TEST' expressions must not have 19508 side effects. 19509 19510 `AND' 19511 `IOR' 19512 `NOT' 19513 `IF_THEN_ELSE' 19514 The basic `MATCH_' expressions can be combined using these 19515 logical operators, which have the semantics of the C operators 19516 `&&', `||', `!', and `? :' respectively. As in Common Lisp, 19517 you may give an `AND' or `IOR' expression an arbitrary number 19518 of arguments; this has exactly the same effect as writing a 19519 chain of two-argument `AND' or `IOR' expressions. 19520 19521 * An optional block of C code, which should execute `return true' if 19522 the predicate is found to match and `return false' if it does not. 19523 It must not have any side effects. The predicate arguments, OP 19524 and MODE, are available with those names. 19525 19526 If a code block is present in a predicate definition, then the RTL 19527 expression must evaluate to true _and_ the code block must execute 19528 `return true' for the predicate to allow the operand. The RTL 19529 expression is evaluated first; do not re-check anything in the 19530 code block that was checked in the RTL expression. 19531 19532 The program `genrecog' scans `define_predicate' and 19533`define_special_predicate' expressions to determine which RTX codes are 19534possibly allowed. You should always make this explicit in the RTL 19535predicate expression, using `MATCH_OPERAND' and `MATCH_CODE'. 19536 19537 Here is an example of a simple predicate definition, from the IA64 19538machine description: 19539 19540 ;; True if OP is a `SYMBOL_REF' which refers to the sdata section. 19541 (define_predicate "small_addr_symbolic_operand" 19542 (and (match_code "symbol_ref") 19543 (match_test "SYMBOL_REF_SMALL_ADDR_P (op)"))) 19544 19545And here is another, showing the use of the C block. 19546 19547 ;; True if OP is a register operand that is (or could be) a GR reg. 19548 (define_predicate "gr_register_operand" 19549 (match_operand 0 "register_operand") 19550 { 19551 unsigned int regno; 19552 if (GET_CODE (op) == SUBREG) 19553 op = SUBREG_REG (op); 19554 19555 regno = REGNO (op); 19556 return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno)); 19557 }) 19558 19559 Predicates written with `define_predicate' automatically include a 19560test that MODE is `VOIDmode', or OP has the same mode as MODE, or OP is 19561a `CONST_INT' or `CONST_DOUBLE'. They do _not_ check specifically for 19562integer `CONST_DOUBLE', nor do they test that the value of either kind 19563of constant fits in the requested mode. This is because 19564target-specific predicates that take constants usually have to do more 19565stringent value checks anyway. If you need the exact same treatment of 19566`CONST_INT' or `CONST_DOUBLE' that the generic predicates provide, use 19567a `MATCH_OPERAND' subexpression to call `const_int_operand', 19568`const_double_operand', or `immediate_operand'. 19569 19570 Predicates written with `define_special_predicate' do not get any 19571automatic mode checks, and are treated as having special mode handling 19572by `genrecog'. 19573 19574 The program `genpreds' is responsible for generating code to test 19575predicates. It also writes a header file containing function 19576declarations for all machine-specific predicates. It is not necessary 19577to declare these predicates in `CPU-protos.h'. 19578 19579 19580File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Predicates, Up: Machine Desc 19581 1958216.8 Operand Constraints 19583======================== 19584 19585Each `match_operand' in an instruction pattern can specify constraints 19586for the operands allowed. The constraints allow you to fine-tune 19587matching within the set of operands allowed by the predicate. 19588 19589 Constraints can say whether an operand may be in a register, and which 19590kinds of register; whether the operand can be a memory reference, and 19591which kinds of address; whether the operand may be an immediate 19592constant, and which possible values it may have. Constraints can also 19593require two operands to match. Side-effects aren't allowed in operands 19594of inline `asm', unless `<' or `>' constraints are used, because there 19595is no guarantee that the side-effects will happen exactly once in an 19596instruction that can update the addressing register. 19597 19598* Menu: 19599 19600* Simple Constraints:: Basic use of constraints. 19601* Multi-Alternative:: When an insn has two alternative constraint-patterns. 19602* Class Preferences:: Constraints guide which hard register to put things in. 19603* Modifiers:: More precise control over effects of constraints. 19604* Machine Constraints:: Existing constraints for some particular machines. 19605* Disable Insn Alternatives:: Disable insn alternatives using attributes. 19606* Define Constraints:: How to define machine-specific constraints. 19607* C Constraint Interface:: How to test constraints from C code. 19608 19609 19610File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints 19611 1961216.8.1 Simple Constraints 19613------------------------- 19614 19615The simplest kind of constraint is a string full of letters, each of 19616which describes one kind of operand that is permitted. Here are the 19617letters that are allowed: 19618 19619whitespace 19620 Whitespace characters are ignored and can be inserted at any 19621 position except the first. This enables each alternative for 19622 different operands to be visually aligned in the machine 19623 description even if they have different number of constraints and 19624 modifiers. 19625 19626`m' 19627 A memory operand is allowed, with any kind of address that the 19628 machine supports in general. Note that the letter used for the 19629 general memory constraint can be re-defined by a back end using 19630 the `TARGET_MEM_CONSTRAINT' macro. 19631 19632`o' 19633 A memory operand is allowed, but only if the address is 19634 "offsettable". This means that adding a small integer (actually, 19635 the width in bytes of the operand, as determined by its machine 19636 mode) may be added to the address and the result is also a valid 19637 memory address. 19638 19639 For example, an address which is constant is offsettable; so is an 19640 address that is the sum of a register and a constant (as long as a 19641 slightly larger constant is also within the range of 19642 address-offsets supported by the machine); but an autoincrement or 19643 autodecrement address is not offsettable. More complicated 19644 indirect/indexed addresses may or may not be offsettable depending 19645 on the other addressing modes that the machine supports. 19646 19647 Note that in an output operand which can be matched by another 19648 operand, the constraint letter `o' is valid only when accompanied 19649 by both `<' (if the target machine has predecrement addressing) 19650 and `>' (if the target machine has preincrement addressing). 19651 19652`V' 19653 A memory operand that is not offsettable. In other words, 19654 anything that would fit the `m' constraint but not the `o' 19655 constraint. 19656 19657`<' 19658 A memory operand with autodecrement addressing (either 19659 predecrement or postdecrement) is allowed. In inline `asm' this 19660 constraint is only allowed if the operand is used exactly once in 19661 an instruction that can handle the side-effects. Not using an 19662 operand with `<' in constraint string in the inline `asm' pattern 19663 at all or using it in multiple instructions isn't valid, because 19664 the side-effects wouldn't be performed or would be performed more 19665 than once. Furthermore, on some targets the operand with `<' in 19666 constraint string must be accompanied by special instruction 19667 suffixes like `%U0' instruction suffix on PowerPC or `%P0' on 19668 IA-64. 19669 19670`>' 19671 A memory operand with autoincrement addressing (either 19672 preincrement or postincrement) is allowed. In inline `asm' the 19673 same restrictions as for `<' apply. 19674 19675`r' 19676 A register operand is allowed provided that it is in a general 19677 register. 19678 19679`i' 19680 An immediate integer operand (one with constant value) is allowed. 19681 This includes symbolic constants whose values will be known only at 19682 assembly time or later. 19683 19684`n' 19685 An immediate integer operand with a known numeric value is allowed. 19686 Many systems cannot support assembly-time constants for operands 19687 less than a word wide. Constraints for these operands should use 19688 `n' rather than `i'. 19689 19690`I', `J', `K', ... `P' 19691 Other letters in the range `I' through `P' may be defined in a 19692 machine-dependent fashion to permit immediate integer operands with 19693 explicit integer values in specified ranges. For example, on the 19694 68000, `I' is defined to stand for the range of values 1 to 8. 19695 This is the range permitted as a shift count in the shift 19696 instructions. 19697 19698`E' 19699 An immediate floating operand (expression code `const_double') is 19700 allowed, but only if the target floating point format is the same 19701 as that of the host machine (on which the compiler is running). 19702 19703`F' 19704 An immediate floating operand (expression code `const_double' or 19705 `const_vector') is allowed. 19706 19707`G', `H' 19708 `G' and `H' may be defined in a machine-dependent fashion to 19709 permit immediate floating operands in particular ranges of values. 19710 19711`s' 19712 An immediate integer operand whose value is not an explicit 19713 integer is allowed. 19714 19715 This might appear strange; if an insn allows a constant operand 19716 with a value not known at compile time, it certainly must allow 19717 any known value. So why use `s' instead of `i'? Sometimes it 19718 allows better code to be generated. 19719 19720 For example, on the 68000 in a fullword instruction it is possible 19721 to use an immediate operand; but if the immediate value is between 19722 -128 and 127, better code results from loading the value into a 19723 register and using the register. This is because the load into 19724 the register can be done with a `moveq' instruction. We arrange 19725 for this to happen by defining the letter `K' to mean "any integer 19726 outside the range -128 to 127", and then specifying `Ks' in the 19727 operand constraints. 19728 19729`g' 19730 Any register, memory or immediate integer operand is allowed, 19731 except for registers that are not general registers. 19732 19733`X' 19734 Any operand whatsoever is allowed, even if it does not satisfy 19735 `general_operand'. This is normally used in the constraint of a 19736 `match_scratch' when certain alternatives will not actually 19737 require a scratch register. 19738 19739`0', `1', `2', ... `9' 19740 An operand that matches the specified operand number is allowed. 19741 If a digit is used together with letters within the same 19742 alternative, the digit should come last. 19743 19744 This number is allowed to be more than a single digit. If multiple 19745 digits are encountered consecutively, they are interpreted as a 19746 single decimal integer. There is scant chance for ambiguity, 19747 since to-date it has never been desirable that `10' be interpreted 19748 as matching either operand 1 _or_ operand 0. Should this be 19749 desired, one can use multiple alternatives instead. 19750 19751 This is called a "matching constraint" and what it really means is 19752 that the assembler has only a single operand that fills two roles 19753 considered separate in the RTL insn. For example, an add insn has 19754 two input operands and one output operand in the RTL, but on most 19755 CISC machines an add instruction really has only two operands, one 19756 of them an input-output operand: 19757 19758 addl #35,r12 19759 19760 Matching constraints are used in these circumstances. More 19761 precisely, the two operands that match must include one input-only 19762 operand and one output-only operand. Moreover, the digit must be a 19763 smaller number than the number of the operand that uses it in the 19764 constraint. 19765 19766 For operands to match in a particular case usually means that they 19767 are identical-looking RTL expressions. But in a few special cases 19768 specific kinds of dissimilarity are allowed. For example, `*x' as 19769 an input operand will match `*x++' as an output operand. For 19770 proper results in such cases, the output template should always 19771 use the output-operand's number when printing the operand. 19772 19773`p' 19774 An operand that is a valid memory address is allowed. This is for 19775 "load address" and "push address" instructions. 19776 19777 `p' in the constraint must be accompanied by `address_operand' as 19778 the predicate in the `match_operand'. This predicate interprets 19779 the mode specified in the `match_operand' as the mode of the memory 19780 reference for which the address would be valid. 19781 19782OTHER-LETTERS 19783 Other letters can be defined in machine-dependent fashion to stand 19784 for particular classes of registers or other arbitrary operand 19785 types. `d', `a' and `f' are defined on the 68000/68020 to stand 19786 for data, address and floating point registers. 19787 19788 In order to have valid assembler code, each operand must satisfy its 19789constraint. But a failure to do so does not prevent the pattern from 19790applying to an insn. Instead, it directs the compiler to modify the 19791code so that the constraint will be satisfied. Usually this is done by 19792copying an operand into a register. 19793 19794 Contrast, therefore, the two instruction patterns that follow: 19795 19796 (define_insn "" 19797 [(set (match_operand:SI 0 "general_operand" "=r") 19798 (plus:SI (match_dup 0) 19799 (match_operand:SI 1 "general_operand" "r")))] 19800 "" 19801 "...") 19802 19803which has two operands, one of which must appear in two places, and 19804 19805 (define_insn "" 19806 [(set (match_operand:SI 0 "general_operand" "=r") 19807 (plus:SI (match_operand:SI 1 "general_operand" "0") 19808 (match_operand:SI 2 "general_operand" "r")))] 19809 "" 19810 "...") 19811 19812which has three operands, two of which are required by a constraint to 19813be identical. If we are considering an insn of the form 19814 19815 (insn N PREV NEXT 19816 (set (reg:SI 3) 19817 (plus:SI (reg:SI 6) (reg:SI 109))) 19818 ...) 19819 19820the first pattern would not apply at all, because this insn does not 19821contain two identical subexpressions in the right place. The pattern 19822would say, "That does not look like an add instruction; try other 19823patterns". The second pattern would say, "Yes, that's an add 19824instruction, but there is something wrong with it". It would direct 19825the reload pass of the compiler to generate additional insns to make 19826the constraint true. The results might look like this: 19827 19828 (insn N2 PREV N 19829 (set (reg:SI 3) (reg:SI 6)) 19830 ...) 19831 19832 (insn N N2 NEXT 19833 (set (reg:SI 3) 19834 (plus:SI (reg:SI 3) (reg:SI 109))) 19835 ...) 19836 19837 It is up to you to make sure that each operand, in each pattern, has 19838constraints that can handle any RTL expression that could be present for 19839that operand. (When multiple alternatives are in use, each pattern 19840must, for each possible combination of operand expressions, have at 19841least one alternative which can handle that combination of operands.) 19842The constraints don't need to _allow_ any possible operand--when this is 19843the case, they do not constrain--but they must at least point the way to 19844reloading any possible operand so that it will fit. 19845 19846 * If the constraint accepts whatever operands the predicate permits, 19847 there is no problem: reloading is never necessary for this operand. 19848 19849 For example, an operand whose constraints permit everything except 19850 registers is safe provided its predicate rejects registers. 19851 19852 An operand whose predicate accepts only constant values is safe 19853 provided its constraints include the letter `i'. If any possible 19854 constant value is accepted, then nothing less than `i' will do; if 19855 the predicate is more selective, then the constraints may also be 19856 more selective. 19857 19858 * Any operand expression can be reloaded by copying it into a 19859 register. So if an operand's constraints allow some kind of 19860 register, it is certain to be safe. It need not permit all 19861 classes of registers; the compiler knows how to copy a register 19862 into another register of the proper class in order to make an 19863 instruction valid. 19864 19865 * A nonoffsettable memory reference can be reloaded by copying the 19866 address into a register. So if the constraint uses the letter 19867 `o', all memory references are taken care of. 19868 19869 * A constant operand can be reloaded by allocating space in memory to 19870 hold it as preinitialized data. Then the memory reference can be 19871 used in place of the constant. So if the constraint uses the 19872 letters `o' or `m', constant operands are not a problem. 19873 19874 * If the constraint permits a constant and a pseudo register used in 19875 an insn was not allocated to a hard register and is equivalent to 19876 a constant, the register will be replaced with the constant. If 19877 the predicate does not permit a constant and the insn is 19878 re-recognized for some reason, the compiler will crash. Thus the 19879 predicate must always recognize any objects allowed by the 19880 constraint. 19881 19882 If the operand's predicate can recognize registers, but the constraint 19883does not permit them, it can make the compiler crash. When this 19884operand happens to be a register, the reload pass will be stymied, 19885because it does not know how to copy a register temporarily into memory. 19886 19887 If the predicate accepts a unary operator, the constraint applies to 19888the operand. For example, the MIPS processor at ISA level 3 supports an 19889instruction which adds two registers in `SImode' to produce a `DImode' 19890result, but only if the registers are correctly sign extended. This 19891predicate for the input operands accepts a `sign_extend' of an `SImode' 19892register. Write the constraint to indicate the type of register that 19893is required for the operand of the `sign_extend'. 19894 19895 19896File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints 19897 1989816.8.2 Multiple Alternative Constraints 19899--------------------------------------- 19900 19901Sometimes a single instruction has multiple alternative sets of possible 19902operands. For example, on the 68000, a logical-or instruction can 19903combine register or an immediate value into memory, or it can combine 19904any kind of operand into a register; but it cannot combine one memory 19905location into another. 19906 19907 These constraints are represented as multiple alternatives. An 19908alternative can be described by a series of letters for each operand. 19909The overall constraint for an operand is made from the letters for this 19910operand from the first alternative, a comma, the letters for this 19911operand from the second alternative, a comma, and so on until the last 19912alternative. Here is how it is done for fullword logical-or on the 1991368000: 19914 19915 (define_insn "iorsi3" 19916 [(set (match_operand:SI 0 "general_operand" "=m,d") 19917 (ior:SI (match_operand:SI 1 "general_operand" "%0,0") 19918 (match_operand:SI 2 "general_operand" "dKs,dmKs")))] 19919 ...) 19920 19921 The first alternative has `m' (memory) for operand 0, `0' for operand 199221 (meaning it must match operand 0), and `dKs' for operand 2. The 19923second alternative has `d' (data register) for operand 0, `0' for 19924operand 1, and `dmKs' for operand 2. The `=' and `%' in the 19925constraints apply to all the alternatives; their meaning is explained 19926in the next section (*note Class Preferences::). 19927 19928 If all the operands fit any one alternative, the instruction is valid. 19929Otherwise, for each alternative, the compiler counts how many 19930instructions must be added to copy the operands so that that 19931alternative applies. The alternative requiring the least copying is 19932chosen. If two alternatives need the same amount of copying, the one 19933that comes first is chosen. These choices can be altered with the `?' 19934and `!' characters: 19935 19936`?' 19937 Disparage slightly the alternative that the `?' appears in, as a 19938 choice when no alternative applies exactly. The compiler regards 19939 this alternative as one unit more costly for each `?' that appears 19940 in it. 19941 19942`!' 19943 Disparage severely the alternative that the `!' appears in. This 19944 alternative can still be used if it fits without reloading, but if 19945 reloading is needed, some other alternative will be used. 19946 19947`^' 19948 This constraint is analogous to `?' but it disparages slightly the 19949 alternative only if the operand with the `^' needs a reload. 19950 19951`$' 19952 This constraint is analogous to `!' but it disparages severely the 19953 alternative only if the operand with the `$' needs a reload. 19954 19955 When an insn pattern has multiple alternatives in its constraints, 19956often the appearance of the assembler code is determined mostly by which 19957alternative was matched. When this is so, the C code for writing the 19958assembler code can use the variable `which_alternative', which is the 19959ordinal number of the alternative that was actually satisfied (0 for 19960the first, 1 for the second alternative, etc.). *Note Output 19961Statement::. 19962 19963 19964File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints 19965 1996616.8.3 Register Class Preferences 19967--------------------------------- 19968 19969The operand constraints have another function: they enable the compiler 19970to decide which kind of hardware register a pseudo register is best 19971allocated to. The compiler examines the constraints that apply to the 19972insns that use the pseudo register, looking for the machine-dependent 19973letters such as `d' and `a' that specify classes of registers. The 19974pseudo register is put in whichever class gets the most "votes". The 19975constraint letters `g' and `r' also vote: they vote in favor of a 19976general register. The machine description says which registers are 19977considered general. 19978 19979 Of course, on some machines all registers are equivalent, and no 19980register classes are defined. Then none of this complexity is relevant. 19981 19982 19983File: gccint.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints 19984 1998516.8.4 Constraint Modifier Characters 19986------------------------------------- 19987 19988Here are constraint modifier characters. 19989 19990`=' 19991 Means that this operand is written to by this instruction: the 19992 previous value is discarded and replaced by new data. 19993 19994`+' 19995 Means that this operand is both read and written by the 19996 instruction. 19997 19998 When the compiler fixes up the operands to satisfy the constraints, 19999 it needs to know which operands are read by the instruction and 20000 which are written by it. `=' identifies an operand which is only 20001 written; `+' identifies an operand that is both read and written; 20002 all other operands are assumed to only be read. 20003 20004 If you specify `=' or `+' in a constraint, you put it in the first 20005 character of the constraint string. 20006 20007`&' 20008 Means (in a particular alternative) that this operand is an 20009 "earlyclobber" operand, which is written before the instruction is 20010 finished using the input operands. Therefore, this operand may 20011 not lie in a register that is read by the instruction or as part 20012 of any memory address. 20013 20014 `&' applies only to the alternative in which it is written. In 20015 constraints with multiple alternatives, sometimes one alternative 20016 requires `&' while others do not. See, for example, the `movdf' 20017 insn of the 68000. 20018 20019 A operand which is read by the instruction can be tied to an 20020 earlyclobber operand if its only use as an input occurs before the 20021 early result is written. Adding alternatives of this form often 20022 allows GCC to produce better code when only some of the read 20023 operands can be affected by the earlyclobber. See, for example, 20024 the `mulsi3' insn of the ARM. 20025 20026 Furthermore, if the "earlyclobber" operand is also a read/write 20027 operand, then that operand is written only after it's used. 20028 20029 `&' does not obviate the need to write `=' or `+'. As 20030 "earlyclobber" operands are always written, a read-only 20031 "earlyclobber" operand is ill-formed and will be rejected by the 20032 compiler. 20033 20034`%' 20035 Declares the instruction to be commutative for this operand and the 20036 following operand. This means that the compiler may interchange 20037 the two operands if that is the cheapest way to make all operands 20038 fit the constraints. `%' applies to all alternatives and must 20039 appear as the first character in the constraint. Only read-only 20040 operands can use `%'. 20041 20042 This is often used in patterns for addition instructions that 20043 really have only two operands: the result must go in one of the 20044 arguments. Here for example, is how the 68000 halfword-add 20045 instruction is defined: 20046 20047 (define_insn "addhi3" 20048 [(set (match_operand:HI 0 "general_operand" "=m,r") 20049 (plus:HI (match_operand:HI 1 "general_operand" "%0,0") 20050 (match_operand:HI 2 "general_operand" "di,g")))] 20051 ...) 20052 GCC can only handle one commutative pair in an asm; if you use 20053 more, the compiler may fail. Note that you need not use the 20054 modifier if the two alternatives are strictly identical; this 20055 would only waste time in the reload pass. The modifier is not 20056 operational after register allocation, so the result of 20057 `define_peephole2' and `define_split's performed after reload 20058 cannot rely on `%' to make the intended insn match. 20059 20060`#' 20061 Says that all following characters, up to the next comma, are to be 20062 ignored as a constraint. They are significant only for choosing 20063 register preferences. 20064 20065`*' 20066 Says that the following character should be ignored when choosing 20067 register preferences. `*' has no effect on the meaning of the 20068 constraint as a constraint, and no effect on reloading. For LRA 20069 `*' additionally disparages slightly the alternative if the 20070 following character matches the operand. 20071 20072 Here is an example: the 68000 has an instruction to sign-extend a 20073 halfword in a data register, and can also sign-extend a value by 20074 copying it into an address register. While either kind of 20075 register is acceptable, the constraints on an address-register 20076 destination are less strict, so it is best if register allocation 20077 makes an address register its goal. Therefore, `*' is used so 20078 that the `d' constraint letter (for data register) is ignored when 20079 computing register preferences. 20080 20081 (define_insn "extendhisi2" 20082 [(set (match_operand:SI 0 "general_operand" "=*d,a") 20083 (sign_extend:SI 20084 (match_operand:HI 1 "general_operand" "0,g")))] 20085 ...) 20086 20087 20088File: gccint.info, Node: Machine Constraints, Next: Disable Insn Alternatives, Prev: Modifiers, Up: Constraints 20089 2009016.8.5 Constraints for Particular Machines 20091------------------------------------------ 20092 20093Whenever possible, you should use the general-purpose constraint letters 20094in `asm' arguments, since they will convey meaning more readily to 20095people reading your code. Failing that, use the constraint letters 20096that usually have very similar meanings across architectures. The most 20097commonly used constraints are `m' and `r' (for memory and 20098general-purpose registers respectively; *note Simple Constraints::), and 20099`I', usually the letter indicating the most common immediate-constant 20100format. 20101 20102 Each architecture defines additional constraints. These constraints 20103are used by the compiler itself for instruction generation, as well as 20104for `asm' statements; therefore, some of the constraints are not 20105particularly useful for `asm'. Here is a summary of some of the 20106machine-dependent constraints available on some particular machines; it 20107includes both constraints that are useful for `asm' and constraints 20108that aren't. The compiler source file mentioned in the table heading 20109for each architecture is the definitive reference for the meanings of 20110that architecture's constraints. 20111 20112_AArch64 family--`config/aarch64/constraints.md'_ 20113 20114 `k' 20115 The stack pointer register (`SP') 20116 20117 `w' 20118 Floating point or SIMD vector register 20119 20120 `I' 20121 Integer constant that is valid as an immediate operand in an 20122 `ADD' instruction 20123 20124 `J' 20125 Integer constant that is valid as an immediate operand in a 20126 `SUB' instruction (once negated) 20127 20128 `K' 20129 Integer constant that can be used with a 32-bit logical 20130 instruction 20131 20132 `L' 20133 Integer constant that can be used with a 64-bit logical 20134 instruction 20135 20136 `M' 20137 Integer constant that is valid as an immediate operand in a 20138 32-bit `MOV' pseudo instruction. The `MOV' may be assembled 20139 to one of several different machine instructions depending on 20140 the value 20141 20142 `N' 20143 Integer constant that is valid as an immediate operand in a 20144 64-bit `MOV' pseudo instruction 20145 20146 `S' 20147 An absolute symbolic address or a label reference 20148 20149 `Y' 20150 Floating point constant zero 20151 20152 `Z' 20153 Integer constant zero 20154 20155 `Ush' 20156 The high part (bits 12 and upwards) of the pc-relative 20157 address of a symbol within 4GB of the instruction 20158 20159 `Q' 20160 A memory address which uses a single base register with no 20161 offset 20162 20163 `Ump' 20164 A memory address suitable for a load/store pair instruction 20165 in SI, DI, SF and DF modes 20166 20167 20168_ARC --`config/arc/constraints.md'_ 20169 20170 `q' 20171 Registers usable in ARCompact 16-bit instructions: `r0'-`r3', 20172 `r12'-`r15'. This constraint can only match when the `-mq' 20173 option is in effect. 20174 20175 `e' 20176 Registers usable as base-regs of memory addresses in 20177 ARCompact 16-bit memory instructions: `r0'-`r3', `r12'-`r15', 20178 `sp'. This constraint can only match when the `-mq' option 20179 is in effect. 20180 20181 `D' 20182 ARC FPX (dpfp) 64-bit registers. `D0', `D1'. 20183 20184 `I' 20185 A signed 12-bit integer constant. 20186 20187 `Cal' 20188 constant for arithmetic/logical operations. This might be 20189 any constant that can be put into a long immediate by the 20190 assmbler or linker without involving a PIC relocation. 20191 20192 `K' 20193 A 3-bit unsigned integer constant. 20194 20195 `L' 20196 A 6-bit unsigned integer constant. 20197 20198 `CnL' 20199 One's complement of a 6-bit unsigned integer constant. 20200 20201 `CmL' 20202 Two's complement of a 6-bit unsigned integer constant. 20203 20204 `M' 20205 A 5-bit unsigned integer constant. 20206 20207 `O' 20208 A 7-bit unsigned integer constant. 20209 20210 `P' 20211 A 8-bit unsigned integer constant. 20212 20213 `H' 20214 Any const_double value. 20215 20216_ARM family--`config/arm/constraints.md'_ 20217 20218 `h' 20219 In Thumb state, the core registers `r8'-`r15'. 20220 20221 `k' 20222 The stack pointer register. 20223 20224 `l' 20225 In Thumb State the core registers `r0'-`r7'. In ARM state 20226 this is an alias for the `r' constraint. 20227 20228 `t' 20229 VFP floating-point registers `s0'-`s31'. Used for 32 bit 20230 values. 20231 20232 `w' 20233 VFP floating-point registers `d0'-`d31' and the appropriate 20234 subset `d0'-`d15' based on command line options. Used for 64 20235 bit values only. Not valid for Thumb1. 20236 20237 `y' 20238 The iWMMX co-processor registers. 20239 20240 `z' 20241 The iWMMX GR registers. 20242 20243 `G' 20244 The floating-point constant 0.0 20245 20246 `I' 20247 Integer that is valid as an immediate operand in a data 20248 processing instruction. That is, an integer in the range 0 20249 to 255 rotated by a multiple of 2 20250 20251 `J' 20252 Integer in the range -4095 to 4095 20253 20254 `K' 20255 Integer that satisfies constraint `I' when inverted (ones 20256 complement) 20257 20258 `L' 20259 Integer that satisfies constraint `I' when negated (twos 20260 complement) 20261 20262 `M' 20263 Integer in the range 0 to 32 20264 20265 `Q' 20266 A memory reference where the exact address is in a single 20267 register (``m'' is preferable for `asm' statements) 20268 20269 `R' 20270 An item in the constant pool 20271 20272 `S' 20273 A symbol in the text segment of the current file 20274 20275 `Uv' 20276 A memory reference suitable for VFP load/store insns 20277 (reg+constant offset) 20278 20279 `Uy' 20280 A memory reference suitable for iWMMXt load/store 20281 instructions. 20282 20283 `Uq' 20284 A memory reference suitable for the ARMv4 ldrsb instruction. 20285 20286_AVR family--`config/avr/constraints.md'_ 20287 20288 `l' 20289 Registers from r0 to r15 20290 20291 `a' 20292 Registers from r16 to r23 20293 20294 `d' 20295 Registers from r16 to r31 20296 20297 `w' 20298 Registers from r24 to r31. These registers can be used in 20299 `adiw' command 20300 20301 `e' 20302 Pointer register (r26-r31) 20303 20304 `b' 20305 Base pointer register (r28-r31) 20306 20307 `q' 20308 Stack pointer register (SPH:SPL) 20309 20310 `t' 20311 Temporary register r0 20312 20313 `x' 20314 Register pair X (r27:r26) 20315 20316 `y' 20317 Register pair Y (r29:r28) 20318 20319 `z' 20320 Register pair Z (r31:r30) 20321 20322 `I' 20323 Constant greater than -1, less than 64 20324 20325 `J' 20326 Constant greater than -64, less than 1 20327 20328 `K' 20329 Constant integer 2 20330 20331 `L' 20332 Constant integer 0 20333 20334 `M' 20335 Constant that fits in 8 bits 20336 20337 `N' 20338 Constant integer -1 20339 20340 `O' 20341 Constant integer 8, 16, or 24 20342 20343 `P' 20344 Constant integer 1 20345 20346 `G' 20347 A floating point constant 0.0 20348 20349 `Q' 20350 A memory address based on Y or Z pointer with displacement. 20351 20352_Blackfin family--`config/bfin/constraints.md'_ 20353 20354 `a' 20355 P register 20356 20357 `d' 20358 D register 20359 20360 `z' 20361 A call clobbered P register. 20362 20363 `qN' 20364 A single register. If N is in the range 0 to 7, the 20365 corresponding D register. If it is `A', then the register P0. 20366 20367 `D' 20368 Even-numbered D register 20369 20370 `W' 20371 Odd-numbered D register 20372 20373 `e' 20374 Accumulator register. 20375 20376 `A' 20377 Even-numbered accumulator register. 20378 20379 `B' 20380 Odd-numbered accumulator register. 20381 20382 `b' 20383 I register 20384 20385 `v' 20386 B register 20387 20388 `f' 20389 M register 20390 20391 `c' 20392 Registers used for circular buffering, i.e. I, B, or L 20393 registers. 20394 20395 `C' 20396 The CC register. 20397 20398 `t' 20399 LT0 or LT1. 20400 20401 `k' 20402 LC0 or LC1. 20403 20404 `u' 20405 LB0 or LB1. 20406 20407 `x' 20408 Any D, P, B, M, I or L register. 20409 20410 `y' 20411 Additional registers typically used only in prologues and 20412 epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and 20413 USP. 20414 20415 `w' 20416 Any register except accumulators or CC. 20417 20418 `Ksh' 20419 Signed 16 bit integer (in the range -32768 to 32767) 20420 20421 `Kuh' 20422 Unsigned 16 bit integer (in the range 0 to 65535) 20423 20424 `Ks7' 20425 Signed 7 bit integer (in the range -64 to 63) 20426 20427 `Ku7' 20428 Unsigned 7 bit integer (in the range 0 to 127) 20429 20430 `Ku5' 20431 Unsigned 5 bit integer (in the range 0 to 31) 20432 20433 `Ks4' 20434 Signed 4 bit integer (in the range -8 to 7) 20435 20436 `Ks3' 20437 Signed 3 bit integer (in the range -3 to 4) 20438 20439 `Ku3' 20440 Unsigned 3 bit integer (in the range 0 to 7) 20441 20442 `PN' 20443 Constant N, where N is a single-digit constant in the range 0 20444 to 4. 20445 20446 `PA' 20447 An integer equal to one of the MACFLAG_XXX constants that is 20448 suitable for use with either accumulator. 20449 20450 `PB' 20451 An integer equal to one of the MACFLAG_XXX constants that is 20452 suitable for use only with accumulator A1. 20453 20454 `M1' 20455 Constant 255. 20456 20457 `M2' 20458 Constant 65535. 20459 20460 `J' 20461 An integer constant with exactly a single bit set. 20462 20463 `L' 20464 An integer constant with all bits set except exactly one. 20465 20466 `H' 20467 20468 `Q' 20469 Any SYMBOL_REF. 20470 20471_CR16 Architecture--`config/cr16/cr16.h'_ 20472 20473 `b' 20474 Registers from r0 to r14 (registers without stack pointer) 20475 20476 `t' 20477 Register from r0 to r11 (all 16-bit registers) 20478 20479 `p' 20480 Register from r12 to r15 (all 32-bit registers) 20481 20482 `I' 20483 Signed constant that fits in 4 bits 20484 20485 `J' 20486 Signed constant that fits in 5 bits 20487 20488 `K' 20489 Signed constant that fits in 6 bits 20490 20491 `L' 20492 Unsigned constant that fits in 4 bits 20493 20494 `M' 20495 Signed constant that fits in 32 bits 20496 20497 `N' 20498 Check for 64 bits wide constants for add/sub instructions 20499 20500 `G' 20501 Floating point constant that is legal for store immediate 20502 20503_Epiphany--`config/epiphany/constraints.md'_ 20504 20505 `U16' 20506 An unsigned 16-bit constant. 20507 20508 `K' 20509 An unsigned 5-bit constant. 20510 20511 `L' 20512 A signed 11-bit constant. 20513 20514 `Cm1' 20515 A signed 11-bit constant added to -1. Can only match when 20516 the `-m1reg-REG' option is active. 20517 20518 `Cl1' 20519 Left-shift of -1, i.e., a bit mask with a block of leading 20520 ones, the rest being a block of trailing zeroes. Can only 20521 match when the `-m1reg-REG' option is active. 20522 20523 `Cr1' 20524 Right-shift of -1, i.e., a bit mask with a trailing block of 20525 ones, the rest being zeroes. Or to put it another way, one 20526 less than a power of two. Can only match when the 20527 `-m1reg-REG' option is active. 20528 20529 `Cal' 20530 Constant for arithmetic/logical operations. This is like 20531 `i', except that for position independent code, no symbols / 20532 expressions needing relocations are allowed. 20533 20534 `Csy' 20535 Symbolic constant for call/jump instruction. 20536 20537 `Rcs' 20538 The register class usable in short insns. This is a register 20539 class constraint, and can thus drive register allocation. 20540 This constraint won't match unless `-mprefer-short-insn-regs' 20541 is in effect. 20542 20543 `Rsc' 20544 The the register class of registers that can be used to hold a 20545 sibcall call address. I.e., a caller-saved register. 20546 20547 `Rct' 20548 Core control register class. 20549 20550 `Rgs' 20551 The register group usable in short insns. This constraint 20552 does not use a register class, so that it only passively 20553 matches suitable registers, and doesn't drive register 20554 allocation. 20555 20556 `Car' 20557 Constant suitable for the addsi3_r pattern. This is a valid 20558 offset For byte, halfword, or word addressing. 20559 20560 `Rra' 20561 Matches the return address if it can be replaced with the 20562 link register. 20563 20564 `Rcc' 20565 Matches the integer condition code register. 20566 20567 `Sra' 20568 Matches the return address if it is in a stack slot. 20569 20570 `Cfm' 20571 Matches control register values to switch fp mode, which are 20572 encapsulated in `UNSPEC_FP_MODE'. 20573 20574_FRV--`config/frv/frv.h'_ 20575 20576 `a' 20577 Register in the class `ACC_REGS' (`acc0' to `acc7'). 20578 20579 `b' 20580 Register in the class `EVEN_ACC_REGS' (`acc0' to `acc7'). 20581 20582 `c' 20583 Register in the class `CC_REGS' (`fcc0' to `fcc3' and `icc0' 20584 to `icc3'). 20585 20586 `d' 20587 Register in the class `GPR_REGS' (`gr0' to `gr63'). 20588 20589 `e' 20590 Register in the class `EVEN_REGS' (`gr0' to `gr63'). Odd 20591 registers are excluded not in the class but through the use 20592 of a machine mode larger than 4 bytes. 20593 20594 `f' 20595 Register in the class `FPR_REGS' (`fr0' to `fr63'). 20596 20597 `h' 20598 Register in the class `FEVEN_REGS' (`fr0' to `fr63'). Odd 20599 registers are excluded not in the class but through the use 20600 of a machine mode larger than 4 bytes. 20601 20602 `l' 20603 Register in the class `LR_REG' (the `lr' register). 20604 20605 `q' 20606 Register in the class `QUAD_REGS' (`gr2' to `gr63'). 20607 Register numbers not divisible by 4 are excluded not in the 20608 class but through the use of a machine mode larger than 8 20609 bytes. 20610 20611 `t' 20612 Register in the class `ICC_REGS' (`icc0' to `icc3'). 20613 20614 `u' 20615 Register in the class `FCC_REGS' (`fcc0' to `fcc3'). 20616 20617 `v' 20618 Register in the class `ICR_REGS' (`cc4' to `cc7'). 20619 20620 `w' 20621 Register in the class `FCR_REGS' (`cc0' to `cc3'). 20622 20623 `x' 20624 Register in the class `QUAD_FPR_REGS' (`fr0' to `fr63'). 20625 Register numbers not divisible by 4 are excluded not in the 20626 class but through the use of a machine mode larger than 8 20627 bytes. 20628 20629 `z' 20630 Register in the class `SPR_REGS' (`lcr' and `lr'). 20631 20632 `A' 20633 Register in the class `QUAD_ACC_REGS' (`acc0' to `acc7'). 20634 20635 `B' 20636 Register in the class `ACCG_REGS' (`accg0' to `accg7'). 20637 20638 `C' 20639 Register in the class `CR_REGS' (`cc0' to `cc7'). 20640 20641 `G' 20642 Floating point constant zero 20643 20644 `I' 20645 6-bit signed integer constant 20646 20647 `J' 20648 10-bit signed integer constant 20649 20650 `L' 20651 16-bit signed integer constant 20652 20653 `M' 20654 16-bit unsigned integer constant 20655 20656 `N' 20657 12-bit signed integer constant that is negative--i.e. in the 20658 range of -2048 to -1 20659 20660 `O' 20661 Constant zero 20662 20663 `P' 20664 12-bit signed integer constant that is greater than 20665 zero--i.e. in the range of 1 to 2047. 20666 20667 20668_Hewlett-Packard PA-RISC--`config/pa/pa.h'_ 20669 20670 `a' 20671 General register 1 20672 20673 `f' 20674 Floating point register 20675 20676 `q' 20677 Shift amount register 20678 20679 `x' 20680 Floating point register (deprecated) 20681 20682 `y' 20683 Upper floating point register (32-bit), floating point 20684 register (64-bit) 20685 20686 `Z' 20687 Any register 20688 20689 `I' 20690 Signed 11-bit integer constant 20691 20692 `J' 20693 Signed 14-bit integer constant 20694 20695 `K' 20696 Integer constant that can be deposited with a `zdepi' 20697 instruction 20698 20699 `L' 20700 Signed 5-bit integer constant 20701 20702 `M' 20703 Integer constant 0 20704 20705 `N' 20706 Integer constant that can be loaded with a `ldil' instruction 20707 20708 `O' 20709 Integer constant whose value plus one is a power of 2 20710 20711 `P' 20712 Integer constant that can be used for `and' operations in 20713 `depi' and `extru' instructions 20714 20715 `S' 20716 Integer constant 31 20717 20718 `U' 20719 Integer constant 63 20720 20721 `G' 20722 Floating-point constant 0.0 20723 20724 `A' 20725 A `lo_sum' data-linkage-table memory operand 20726 20727 `Q' 20728 A memory operand that can be used as the destination operand 20729 of an integer store instruction 20730 20731 `R' 20732 A scaled or unscaled indexed memory operand 20733 20734 `T' 20735 A memory operand for floating-point loads and stores 20736 20737 `W' 20738 A register indirect memory operand 20739 20740_Intel IA-64--`config/ia64/ia64.h'_ 20741 20742 `a' 20743 General register `r0' to `r3' for `addl' instruction 20744 20745 `b' 20746 Branch register 20747 20748 `c' 20749 Predicate register (`c' as in "conditional") 20750 20751 `d' 20752 Application register residing in M-unit 20753 20754 `e' 20755 Application register residing in I-unit 20756 20757 `f' 20758 Floating-point register 20759 20760 `m' 20761 Memory operand. If used together with `<' or `>', the 20762 operand can have postincrement and postdecrement which 20763 require printing with `%Pn' on IA-64. 20764 20765 `G' 20766 Floating-point constant 0.0 or 1.0 20767 20768 `I' 20769 14-bit signed integer constant 20770 20771 `J' 20772 22-bit signed integer constant 20773 20774 `K' 20775 8-bit signed integer constant for logical instructions 20776 20777 `L' 20778 8-bit adjusted signed integer constant for compare pseudo-ops 20779 20780 `M' 20781 6-bit unsigned integer constant for shift counts 20782 20783 `N' 20784 9-bit signed integer constant for load and store 20785 postincrements 20786 20787 `O' 20788 The constant zero 20789 20790 `P' 20791 0 or -1 for `dep' instruction 20792 20793 `Q' 20794 Non-volatile memory for floating-point loads and stores 20795 20796 `R' 20797 Integer constant in the range 1 to 4 for `shladd' instruction 20798 20799 `S' 20800 Memory operand except postincrement and postdecrement. This 20801 is now roughly the same as `m' when not used together with `<' 20802 or `>'. 20803 20804_M32C--`config/m32c/m32c.c'_ 20805 20806 `Rsp' 20807 `Rfb' 20808 `Rsb' 20809 `$sp', `$fb', `$sb'. 20810 20811 `Rcr' 20812 Any control register, when they're 16 bits wide (nothing if 20813 control registers are 24 bits wide) 20814 20815 `Rcl' 20816 Any control register, when they're 24 bits wide. 20817 20818 `R0w' 20819 `R1w' 20820 `R2w' 20821 `R3w' 20822 $r0, $r1, $r2, $r3. 20823 20824 `R02' 20825 $r0 or $r2, or $r2r0 for 32 bit values. 20826 20827 `R13' 20828 $r1 or $r3, or $r3r1 for 32 bit values. 20829 20830 `Rdi' 20831 A register that can hold a 64 bit value. 20832 20833 `Rhl' 20834 $r0 or $r1 (registers with addressable high/low bytes) 20835 20836 `R23' 20837 $r2 or $r3 20838 20839 `Raa' 20840 Address registers 20841 20842 `Raw' 20843 Address registers when they're 16 bits wide. 20844 20845 `Ral' 20846 Address registers when they're 24 bits wide. 20847 20848 `Rqi' 20849 Registers that can hold QI values. 20850 20851 `Rad' 20852 Registers that can be used with displacements ($a0, $a1, $sb). 20853 20854 `Rsi' 20855 Registers that can hold 32 bit values. 20856 20857 `Rhi' 20858 Registers that can hold 16 bit values. 20859 20860 `Rhc' 20861 Registers chat can hold 16 bit values, including all control 20862 registers. 20863 20864 `Rra' 20865 $r0 through R1, plus $a0 and $a1. 20866 20867 `Rfl' 20868 The flags register. 20869 20870 `Rmm' 20871 The memory-based pseudo-registers $mem0 through $mem15. 20872 20873 `Rpi' 20874 Registers that can hold pointers (16 bit registers for r8c, 20875 m16c; 24 bit registers for m32cm, m32c). 20876 20877 `Rpa' 20878 Matches multiple registers in a PARALLEL to form a larger 20879 register. Used to match function return values. 20880 20881 `Is3' 20882 -8 ... 7 20883 20884 `IS1' 20885 -128 ... 127 20886 20887 `IS2' 20888 -32768 ... 32767 20889 20890 `IU2' 20891 0 ... 65535 20892 20893 `In4' 20894 -8 ... -1 or 1 ... 8 20895 20896 `In5' 20897 -16 ... -1 or 1 ... 16 20898 20899 `In6' 20900 -32 ... -1 or 1 ... 32 20901 20902 `IM2' 20903 -65536 ... -1 20904 20905 `Ilb' 20906 An 8 bit value with exactly one bit set. 20907 20908 `Ilw' 20909 A 16 bit value with exactly one bit set. 20910 20911 `Sd' 20912 The common src/dest memory addressing modes. 20913 20914 `Sa' 20915 Memory addressed using $a0 or $a1. 20916 20917 `Si' 20918 Memory addressed with immediate addresses. 20919 20920 `Ss' 20921 Memory addressed using the stack pointer ($sp). 20922 20923 `Sf' 20924 Memory addressed using the frame base register ($fb). 20925 20926 `Ss' 20927 Memory addressed using the small base register ($sb). 20928 20929 `S1' 20930 $r1h 20931 20932_MeP--`config/mep/constraints.md'_ 20933 20934 `a' 20935 The $sp register. 20936 20937 `b' 20938 The $tp register. 20939 20940 `c' 20941 Any control register. 20942 20943 `d' 20944 Either the $hi or the $lo register. 20945 20946 `em' 20947 Coprocessor registers that can be directly loaded ($c0-$c15). 20948 20949 `ex' 20950 Coprocessor registers that can be moved to each other. 20951 20952 `er' 20953 Coprocessor registers that can be moved to core registers. 20954 20955 `h' 20956 The $hi register. 20957 20958 `j' 20959 The $rpc register. 20960 20961 `l' 20962 The $lo register. 20963 20964 `t' 20965 Registers which can be used in $tp-relative addressing. 20966 20967 `v' 20968 The $gp register. 20969 20970 `x' 20971 The coprocessor registers. 20972 20973 `y' 20974 The coprocessor control registers. 20975 20976 `z' 20977 The $0 register. 20978 20979 `A' 20980 User-defined register set A. 20981 20982 `B' 20983 User-defined register set B. 20984 20985 `C' 20986 User-defined register set C. 20987 20988 `D' 20989 User-defined register set D. 20990 20991 `I' 20992 Offsets for $gp-rel addressing. 20993 20994 `J' 20995 Constants that can be used directly with boolean insns. 20996 20997 `K' 20998 Constants that can be moved directly to registers. 20999 21000 `L' 21001 Small constants that can be added to registers. 21002 21003 `M' 21004 Long shift counts. 21005 21006 `N' 21007 Small constants that can be compared to registers. 21008 21009 `O' 21010 Constants that can be loaded into the top half of registers. 21011 21012 `S' 21013 Signed 8-bit immediates. 21014 21015 `T' 21016 Symbols encoded for $tp-rel or $gp-rel addressing. 21017 21018 `U' 21019 Non-constant addresses for loading/saving coprocessor 21020 registers. 21021 21022 `W' 21023 The top half of a symbol's value. 21024 21025 `Y' 21026 A register indirect address without offset. 21027 21028 `Z' 21029 Symbolic references to the control bus. 21030 21031 21032_MicroBlaze--`config/microblaze/constraints.md'_ 21033 21034 `d' 21035 A general register (`r0' to `r31'). 21036 21037 `z' 21038 A status register (`rmsr', `$fcc1' to `$fcc7'). 21039 21040 21041_MIPS--`config/mips/constraints.md'_ 21042 21043 `d' 21044 An address register. This is equivalent to `r' unless 21045 generating MIPS16 code. 21046 21047 `f' 21048 A floating-point register (if available). 21049 21050 `h' 21051 Formerly the `hi' register. This constraint is no longer 21052 supported. 21053 21054 `l' 21055 The `lo' register. Use this register to store values that are 21056 no bigger than a word. 21057 21058 `x' 21059 The concatenated `hi' and `lo' registers. Use this register 21060 to store doubleword values. 21061 21062 `c' 21063 A register suitable for use in an indirect jump. This will 21064 always be `$25' for `-mabicalls'. 21065 21066 `v' 21067 Register `$3'. Do not use this constraint in new code; it is 21068 retained only for compatibility with glibc. 21069 21070 `y' 21071 Equivalent to `r'; retained for backwards compatibility. 21072 21073 `z' 21074 A floating-point condition code register. 21075 21076 `I' 21077 A signed 16-bit constant (for arithmetic instructions). 21078 21079 `J' 21080 Integer zero. 21081 21082 `K' 21083 An unsigned 16-bit constant (for logic instructions). 21084 21085 `L' 21086 A signed 32-bit constant in which the lower 16 bits are zero. 21087 Such constants can be loaded using `lui'. 21088 21089 `M' 21090 A constant that cannot be loaded using `lui', `addiu' or 21091 `ori'. 21092 21093 `N' 21094 A constant in the range -65535 to -1 (inclusive). 21095 21096 `O' 21097 A signed 15-bit constant. 21098 21099 `P' 21100 A constant in the range 1 to 65535 (inclusive). 21101 21102 `G' 21103 Floating-point zero. 21104 21105 `R' 21106 An address that can be used in a non-macro load or store. 21107 21108 `ZC' 21109 A memory operand whose address is formed by a base register 21110 and offset that is suitable for use in instructions with the 21111 same addressing mode as `ll' and `sc'. 21112 21113 `ZD' 21114 An address suitable for a `prefetch' instruction, or for any 21115 other instruction with the same addressing mode as `prefetch'. 21116 21117_Motorola 680x0--`config/m68k/constraints.md'_ 21118 21119 `a' 21120 Address register 21121 21122 `d' 21123 Data register 21124 21125 `f' 21126 68881 floating-point register, if available 21127 21128 `I' 21129 Integer in the range 1 to 8 21130 21131 `J' 21132 16-bit signed number 21133 21134 `K' 21135 Signed number whose magnitude is greater than 0x80 21136 21137 `L' 21138 Integer in the range -8 to -1 21139 21140 `M' 21141 Signed number whose magnitude is greater than 0x100 21142 21143 `N' 21144 Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate 21145 21146 `O' 21147 16 (for rotate using swap) 21148 21149 `P' 21150 Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate 21151 21152 `R' 21153 Numbers that mov3q can handle 21154 21155 `G' 21156 Floating point constant that is not a 68881 constant 21157 21158 `S' 21159 Operands that satisfy 'm' when -mpcrel is in effect 21160 21161 `T' 21162 Operands that satisfy 's' when -mpcrel is not in effect 21163 21164 `Q' 21165 Address register indirect addressing mode 21166 21167 `U' 21168 Register offset addressing 21169 21170 `W' 21171 const_call_operand 21172 21173 `Cs' 21174 symbol_ref or const 21175 21176 `Ci' 21177 const_int 21178 21179 `C0' 21180 const_int 0 21181 21182 `Cj' 21183 Range of signed numbers that don't fit in 16 bits 21184 21185 `Cmvq' 21186 Integers valid for mvq 21187 21188 `Capsw' 21189 Integers valid for a moveq followed by a swap 21190 21191 `Cmvz' 21192 Integers valid for mvz 21193 21194 `Cmvs' 21195 Integers valid for mvs 21196 21197 `Ap' 21198 push_operand 21199 21200 `Ac' 21201 Non-register operands allowed in clr 21202 21203 21204_Moxie--`config/moxie/constraints.md'_ 21205 21206 `A' 21207 An absolute address 21208 21209 `B' 21210 An offset address 21211 21212 `W' 21213 A register indirect memory operand 21214 21215 `I' 21216 A constant in the range of 0 to 255. 21217 21218 `N' 21219 A constant in the range of 0 to -255. 21220 21221 21222_MSP430-`config/msp430/constraints.md'_ 21223 21224 `R12' 21225 Register R12. 21226 21227 `R13' 21228 Register R13. 21229 21230 `K' 21231 Integer constant 1. 21232 21233 `L' 21234 Integer constant -1^20..1^19. 21235 21236 `M' 21237 Integer constant 1-4. 21238 21239 `Ya' 21240 Memory references which do not require an extended MOVX 21241 instruction. 21242 21243 `Yl' 21244 Memory reference, labels only. 21245 21246 `Ys' 21247 Memory reference, stack only. 21248 21249 21250_NDS32--`config/nds32/constraints.md'_ 21251 21252 `w' 21253 LOW register class $r0 to $r7 constraint for V3/V3M ISA. 21254 21255 `l' 21256 LOW register class $r0 to $r7. 21257 21258 `d' 21259 MIDDLE register class $r0 to $r11, $r16 to $r19. 21260 21261 `h' 21262 HIGH register class $r12 to $r14, $r20 to $r31. 21263 21264 `t' 21265 Temporary assist register $ta (i.e. $r15). 21266 21267 `k' 21268 Stack register $sp. 21269 21270 `Iu03' 21271 Unsigned immediate 3-bit value. 21272 21273 `In03' 21274 Negative immediate 3-bit value in the range of -7-0. 21275 21276 `Iu04' 21277 Unsigned immediate 4-bit value. 21278 21279 `Is05' 21280 Signed immediate 5-bit value. 21281 21282 `Iu05' 21283 Unsigned immediate 5-bit value. 21284 21285 `In05' 21286 Negative immediate 5-bit value in the range of -31-0. 21287 21288 `Ip05' 21289 Unsigned immediate 5-bit value for movpi45 instruction with 21290 range 16-47. 21291 21292 `Iu06' 21293 Unsigned immediate 6-bit value constraint for addri36.sp 21294 instruction. 21295 21296 `Iu08' 21297 Unsigned immediate 8-bit value. 21298 21299 `Iu09' 21300 Unsigned immediate 9-bit value. 21301 21302 `Is10' 21303 Signed immediate 10-bit value. 21304 21305 `Is11' 21306 Signed immediate 11-bit value. 21307 21308 `Is15' 21309 Signed immediate 15-bit value. 21310 21311 `Iu15' 21312 Unsigned immediate 15-bit value. 21313 21314 `Ic15' 21315 A constant which is not in the range of imm15u but ok for 21316 bclr instruction. 21317 21318 `Ie15' 21319 A constant which is not in the range of imm15u but ok for 21320 bset instruction. 21321 21322 `It15' 21323 A constant which is not in the range of imm15u but ok for 21324 btgl instruction. 21325 21326 `Ii15' 21327 A constant whose compliment value is in the range of imm15u 21328 and ok for bitci instruction. 21329 21330 `Is16' 21331 Signed immediate 16-bit value. 21332 21333 `Is17' 21334 Signed immediate 17-bit value. 21335 21336 `Is19' 21337 Signed immediate 19-bit value. 21338 21339 `Is20' 21340 Signed immediate 20-bit value. 21341 21342 `Ihig' 21343 The immediate value that can be simply set high 20-bit. 21344 21345 `Izeb' 21346 The immediate value 0xff. 21347 21348 `Izeh' 21349 The immediate value 0xffff. 21350 21351 `Ixls' 21352 The immediate value 0x01. 21353 21354 `Ix11' 21355 The immediate value 0x7ff. 21356 21357 `Ibms' 21358 The immediate value with power of 2. 21359 21360 `Ifex' 21361 The immediate value with power of 2 minus 1. 21362 21363 `U33' 21364 Memory constraint for 333 format. 21365 21366 `U45' 21367 Memory constraint for 45 format. 21368 21369 `U37' 21370 Memory constraint for 37 format. 21371 21372_Nios II family--`config/nios2/constraints.md'_ 21373 21374 `I' 21375 Integer that is valid as an immediate operand in an 21376 instruction taking a signed 16-bit number. Range -32768 to 21377 32767. 21378 21379 `J' 21380 Integer that is valid as an immediate operand in an 21381 instruction taking an unsigned 16-bit number. Range 0 to 21382 65535. 21383 21384 `K' 21385 Integer that is valid as an immediate operand in an 21386 instruction taking only the upper 16-bits of a 32-bit number. 21387 Range 32-bit numbers with the lower 16-bits being 0. 21388 21389 `L' 21390 Integer that is valid as an immediate operand for a shift 21391 instruction. Range 0 to 31. 21392 21393 `M' 21394 Integer that is valid as an immediate operand for only the 21395 value 0. Can be used in conjunction with the format modifier 21396 `z' to use `r0' instead of `0' in the assembly output. 21397 21398 `N' 21399 Integer that is valid as an immediate operand for a custom 21400 instruction opcode. Range 0 to 255. 21401 21402 `S' 21403 Matches immediates which are addresses in the small data 21404 section and therefore can be added to `gp' as a 16-bit 21405 immediate to re-create their 32-bit value. 21406 21407 `T' 21408 A `const' wrapped `UNSPEC' expression, representing a 21409 supported PIC or TLS relocation. 21410 21411 21412_PDP-11--`config/pdp11/constraints.md'_ 21413 21414 `a' 21415 Floating point registers AC0 through AC3. These can be 21416 loaded from/to memory with a single instruction. 21417 21418 `d' 21419 Odd numbered general registers (R1, R3, R5). These are used 21420 for 16-bit multiply operations. 21421 21422 `f' 21423 Any of the floating point registers (AC0 through AC5). 21424 21425 `G' 21426 Floating point constant 0. 21427 21428 `I' 21429 An integer constant that fits in 16 bits. 21430 21431 `J' 21432 An integer constant whose low order 16 bits are zero. 21433 21434 `K' 21435 An integer constant that does not meet the constraints for 21436 codes `I' or `J'. 21437 21438 `L' 21439 The integer constant 1. 21440 21441 `M' 21442 The integer constant -1. 21443 21444 `N' 21445 The integer constant 0. 21446 21447 `O' 21448 Integer constants -4 through -1 and 1 through 4; shifts by 21449 these amounts are handled as multiple single-bit shifts 21450 rather than a single variable-length shift. 21451 21452 `Q' 21453 A memory reference which requires an additional word (address 21454 or offset) after the opcode. 21455 21456 `R' 21457 A memory reference that is encoded within the opcode. 21458 21459 21460_PowerPC and IBM RS6000--`config/rs6000/constraints.md'_ 21461 21462 `b' 21463 Address base register 21464 21465 `d' 21466 Floating point register (containing 64-bit value) 21467 21468 `f' 21469 Floating point register (containing 32-bit value) 21470 21471 `v' 21472 Altivec vector register 21473 21474 `wa' 21475 Any VSX register if the -mvsx option was used or NO_REGS. 21476 21477 When using any of the register constraints (`wa', `wd', `wf', 21478 `wg', `wh', `wi', `wj', `wk', `wl', `wm', `ws', `wt', `wu', 21479 `wv', `ww', or `wy') that take VSX registers, you must use 21480 `%x<n>' in the template so that the correct register is used. 21481 Otherwise the register number output in the assembly file 21482 will be incorrect if an Altivec register is an operand of a 21483 VSX instruction that expects VSX register numbering. 21484 21485 asm ("xvadddp %x0,%x1,%x2" : "=wa" (v1) : "wa" (v2), "wa" (v3)); 21486 21487 is correct, but: 21488 21489 asm ("xvadddp %0,%1,%2" : "=wa" (v1) : "wa" (v2), "wa" (v3)); 21490 21491 is not correct. 21492 21493 `wd' 21494 VSX vector register to hold vector double data or NO_REGS. 21495 21496 `wf' 21497 VSX vector register to hold vector float data or NO_REGS. 21498 21499 `wg' 21500 If `-mmfpgpr' was used, a floating point register or NO_REGS. 21501 21502 `wh' 21503 Floating point register if direct moves are available, or 21504 NO_REGS. 21505 21506 `wi' 21507 FP or VSX register to hold 64-bit integers for VSX insns or 21508 NO_REGS. 21509 21510 `wj' 21511 FP or VSX register to hold 64-bit integers for direct moves 21512 or NO_REGS. 21513 21514 `wk' 21515 FP or VSX register to hold 64-bit doubles for direct moves or 21516 NO_REGS. 21517 21518 `wl' 21519 Floating point register if the LFIWAX instruction is enabled 21520 or NO_REGS. 21521 21522 `wm' 21523 VSX register if direct move instructions are enabled, or 21524 NO_REGS. 21525 21526 `wn' 21527 No register (NO_REGS). 21528 21529 `wr' 21530 General purpose register if 64-bit instructions are enabled 21531 or NO_REGS. 21532 21533 `ws' 21534 VSX vector register to hold scalar double values or NO_REGS. 21535 21536 `wt' 21537 VSX vector register to hold 128 bit integer or NO_REGS. 21538 21539 `wu' 21540 Altivec register to use for float/32-bit int loads/stores or 21541 NO_REGS. 21542 21543 `wv' 21544 Altivec register to use for double loads/stores or NO_REGS. 21545 21546 `ww' 21547 FP or VSX register to perform float operations under `-mvsx' 21548 or NO_REGS. 21549 21550 `wx' 21551 Floating point register if the STFIWX instruction is enabled 21552 or NO_REGS. 21553 21554 `wy' 21555 FP or VSX register to perform ISA 2.07 float ops or NO_REGS. 21556 21557 `wz' 21558 Floating point register if the LFIWZX instruction is enabled 21559 or NO_REGS. 21560 21561 `wD' 21562 Int constant that is the element number of the 64-bit scalar 21563 in a vector. 21564 21565 `wQ' 21566 A memory address that will work with the `lq' and `stq' 21567 instructions. 21568 21569 `h' 21570 `MQ', `CTR', or `LINK' register 21571 21572 `q' 21573 `MQ' register 21574 21575 `c' 21576 `CTR' register 21577 21578 `l' 21579 `LINK' register 21580 21581 `x' 21582 `CR' register (condition register) number 0 21583 21584 `y' 21585 `CR' register (condition register) 21586 21587 `z' 21588 `XER[CA]' carry bit (part of the XER register) 21589 21590 `I' 21591 Signed 16-bit constant 21592 21593 `J' 21594 Unsigned 16-bit constant shifted left 16 bits (use `L' 21595 instead for `SImode' constants) 21596 21597 `K' 21598 Unsigned 16-bit constant 21599 21600 `L' 21601 Signed 16-bit constant shifted left 16 bits 21602 21603 `M' 21604 Constant larger than 31 21605 21606 `N' 21607 Exact power of 2 21608 21609 `O' 21610 Zero 21611 21612 `P' 21613 Constant whose negation is a signed 16-bit constant 21614 21615 `G' 21616 Floating point constant that can be loaded into a register 21617 with one instruction per word 21618 21619 `H' 21620 Integer/Floating point constant that can be loaded into a 21621 register using three instructions 21622 21623 `m' 21624 Memory operand. Normally, `m' does not allow addresses that 21625 update the base register. If `<' or `>' constraint is also 21626 used, they are allowed and therefore on PowerPC targets in 21627 that case it is only safe to use `m<>' in an `asm' statement 21628 if that `asm' statement accesses the operand exactly once. 21629 The `asm' statement must also use `%U<OPNO>' as a placeholder 21630 for the "update" flag in the corresponding load or store 21631 instruction. For example: 21632 21633 asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val)); 21634 21635 is correct but: 21636 21637 asm ("st %1,%0" : "=m<>" (mem) : "r" (val)); 21638 21639 is not. 21640 21641 `es' 21642 A "stable" memory operand; that is, one which does not 21643 include any automodification of the base register. This used 21644 to be useful when `m' allowed automodification of the base 21645 register, but as those are now only allowed when `<' or `>' 21646 is used, `es' is basically the same as `m' without `<' and 21647 `>'. 21648 21649 `Q' 21650 Memory operand that is an offset from a register (it is 21651 usually better to use `m' or `es' in `asm' statements) 21652 21653 `Z' 21654 Memory operand that is an indexed or indirect from a register 21655 (it is usually better to use `m' or `es' in `asm' statements) 21656 21657 `R' 21658 AIX TOC entry 21659 21660 `a' 21661 Address operand that is an indexed or indirect from a 21662 register (`p' is preferable for `asm' statements) 21663 21664 `S' 21665 Constant suitable as a 64-bit mask operand 21666 21667 `T' 21668 Constant suitable as a 32-bit mask operand 21669 21670 `U' 21671 System V Release 4 small data area reference 21672 21673 `t' 21674 AND masks that can be performed by two rldic{l, r} 21675 instructions 21676 21677 `W' 21678 Vector constant that does not require memory 21679 21680 `j' 21681 Vector constant that is all zeros. 21682 21683 21684_RL78--`config/rl78/constraints.md'_ 21685 21686 `Int3' 21687 An integer constant in the range 1 ... 7. 21688 21689 `Int8' 21690 An integer constant in the range 0 ... 255. 21691 21692 `J' 21693 An integer constant in the range -255 ... 0 21694 21695 `K' 21696 The integer constant 1. 21697 21698 `L' 21699 The integer constant -1. 21700 21701 `M' 21702 The integer constant 0. 21703 21704 `N' 21705 The integer constant 2. 21706 21707 `O' 21708 The integer constant -2. 21709 21710 `P' 21711 An integer constant in the range 1 ... 15. 21712 21713 `Qbi' 21714 The built-in compare types-eq, ne, gtu, ltu, geu, and leu. 21715 21716 `Qsc' 21717 The synthetic compare types-gt, lt, ge, and le. 21718 21719 `Wab' 21720 A memory reference with an absolute address. 21721 21722 `Wbc' 21723 A memory reference using `BC' as a base register, with an 21724 optional offset. 21725 21726 `Wca' 21727 A memory reference using `AX', `BC', `DE', or `HL' for the 21728 address, for calls. 21729 21730 `Wcv' 21731 A memory reference using any 16-bit register pair for the 21732 address, for calls. 21733 21734 `Wd2' 21735 A memory reference using `DE' as a base register, with an 21736 optional offset. 21737 21738 `Wde' 21739 A memory reference using `DE' as a base register, without any 21740 offset. 21741 21742 `Wfr' 21743 Any memory reference to an address in the far address space. 21744 21745 `Wh1' 21746 A memory reference using `HL' as a base register, with an 21747 optional one-byte offset. 21748 21749 `Whb' 21750 A memory reference using `HL' as a base register, with `B' or 21751 `C' as the index register. 21752 21753 `Whl' 21754 A memory reference using `HL' as a base register, without any 21755 offset. 21756 21757 `Ws1' 21758 A memory reference using `SP' as a base register, with an 21759 optional one-byte offset. 21760 21761 `Y' 21762 Any memory reference to an address in the near address space. 21763 21764 `A' 21765 The `AX' register. 21766 21767 `B' 21768 The `BC' register. 21769 21770 `D' 21771 The `DE' register. 21772 21773 `R' 21774 `A' through `L' registers. 21775 21776 `S' 21777 The `SP' register. 21778 21779 `T' 21780 The `HL' register. 21781 21782 `Z08W' 21783 The 16-bit `R8' register. 21784 21785 `Z10W' 21786 The 16-bit `R10' register. 21787 21788 `Zint' 21789 The registers reserved for interrupts (`R24' to `R31'). 21790 21791 `a' 21792 The `A' register. 21793 21794 `b' 21795 The `B' register. 21796 21797 `c' 21798 The `C' register. 21799 21800 `d' 21801 The `D' register. 21802 21803 `e' 21804 The `E' register. 21805 21806 `h' 21807 The `H' register. 21808 21809 `l' 21810 The `L' register. 21811 21812 `v' 21813 The virtual registers. 21814 21815 `w' 21816 The `PSW' register. 21817 21818 `x' 21819 The `X' register. 21820 21821 21822_RX--`config/rx/constraints.md'_ 21823 21824 `Q' 21825 An address which does not involve register indirect 21826 addressing or pre/post increment/decrement addressing. 21827 21828 `Symbol' 21829 A symbol reference. 21830 21831 `Int08' 21832 A constant in the range -256 to 255, inclusive. 21833 21834 `Sint08' 21835 A constant in the range -128 to 127, inclusive. 21836 21837 `Sint16' 21838 A constant in the range -32768 to 32767, inclusive. 21839 21840 `Sint24' 21841 A constant in the range -8388608 to 8388607, inclusive. 21842 21843 `Uint04' 21844 A constant in the range 0 to 15, inclusive. 21845 21846 21847_S/390 and zSeries--`config/s390/s390.h'_ 21848 21849 `a' 21850 Address register (general purpose register except r0) 21851 21852 `c' 21853 Condition code register 21854 21855 `d' 21856 Data register (arbitrary general purpose register) 21857 21858 `f' 21859 Floating-point register 21860 21861 `I' 21862 Unsigned 8-bit constant (0-255) 21863 21864 `J' 21865 Unsigned 12-bit constant (0-4095) 21866 21867 `K' 21868 Signed 16-bit constant (-32768-32767) 21869 21870 `L' 21871 Value appropriate as displacement. 21872 `(0..4095)' 21873 for short displacement 21874 21875 `(-524288..524287)' 21876 for long displacement 21877 21878 `M' 21879 Constant integer with a value of 0x7fffffff. 21880 21881 `N' 21882 Multiple letter constraint followed by 4 parameter letters. 21883 `0..9:' 21884 number of the part counting from most to least 21885 significant 21886 21887 `H,Q:' 21888 mode of the part 21889 21890 `D,S,H:' 21891 mode of the containing operand 21892 21893 `0,F:' 21894 value of the other parts (F--all bits set) 21895 The constraint matches if the specified part of a constant 21896 has a value different from its other parts. 21897 21898 `Q' 21899 Memory reference without index register and with short 21900 displacement. 21901 21902 `R' 21903 Memory reference with index register and short displacement. 21904 21905 `S' 21906 Memory reference without index register but with long 21907 displacement. 21908 21909 `T' 21910 Memory reference with index register and long displacement. 21911 21912 `U' 21913 Pointer with short displacement. 21914 21915 `W' 21916 Pointer with long displacement. 21917 21918 `Y' 21919 Shift count operand. 21920 21921 21922_SPARC--`config/sparc/sparc.h'_ 21923 21924 `f' 21925 Floating-point register on the SPARC-V8 architecture and 21926 lower floating-point register on the SPARC-V9 architecture. 21927 21928 `e' 21929 Floating-point register. It is equivalent to `f' on the 21930 SPARC-V8 architecture and contains both lower and upper 21931 floating-point registers on the SPARC-V9 architecture. 21932 21933 `c' 21934 Floating-point condition code register. 21935 21936 `d' 21937 Lower floating-point register. It is only valid on the 21938 SPARC-V9 architecture when the Visual Instruction Set is 21939 available. 21940 21941 `b' 21942 Floating-point register. It is only valid on the SPARC-V9 21943 architecture when the Visual Instruction Set is available. 21944 21945 `h' 21946 64-bit global or out register for the SPARC-V8+ architecture. 21947 21948 `C' 21949 The constant all-ones, for floating-point. 21950 21951 `A' 21952 Signed 5-bit constant 21953 21954 `D' 21955 A vector constant 21956 21957 `I' 21958 Signed 13-bit constant 21959 21960 `J' 21961 Zero 21962 21963 `K' 21964 32-bit constant with the low 12 bits clear (a constant that 21965 can be loaded with the `sethi' instruction) 21966 21967 `L' 21968 A constant in the range supported by `movcc' instructions 21969 (11-bit signed immediate) 21970 21971 `M' 21972 A constant in the range supported by `movrcc' instructions 21973 (10-bit signed immediate) 21974 21975 `N' 21976 Same as `K', except that it verifies that bits that are not 21977 in the lower 32-bit range are all zero. Must be used instead 21978 of `K' for modes wider than `SImode' 21979 21980 `O' 21981 The constant 4096 21982 21983 `G' 21984 Floating-point zero 21985 21986 `H' 21987 Signed 13-bit constant, sign-extended to 32 or 64 bits 21988 21989 `P' 21990 The constant -1 21991 21992 `Q' 21993 Floating-point constant whose integral representation can be 21994 moved into an integer register using a single sethi 21995 instruction 21996 21997 `R' 21998 Floating-point constant whose integral representation can be 21999 moved into an integer register using a single mov instruction 22000 22001 `S' 22002 Floating-point constant whose integral representation can be 22003 moved into an integer register using a high/lo_sum 22004 instruction sequence 22005 22006 `T' 22007 Memory address aligned to an 8-byte boundary 22008 22009 `U' 22010 Even register 22011 22012 `W' 22013 Memory address for `e' constraint registers 22014 22015 `w' 22016 Memory address with only a base register 22017 22018 `Y' 22019 Vector zero 22020 22021 22022_SPU--`config/spu/spu.h'_ 22023 22024 `a' 22025 An immediate which can be loaded with the il/ila/ilh/ilhu 22026 instructions. const_int is treated as a 64 bit value. 22027 22028 `c' 22029 An immediate for and/xor/or instructions. const_int is 22030 treated as a 64 bit value. 22031 22032 `d' 22033 An immediate for the `iohl' instruction. const_int is 22034 treated as a 64 bit value. 22035 22036 `f' 22037 An immediate which can be loaded with `fsmbi'. 22038 22039 `A' 22040 An immediate which can be loaded with the il/ila/ilh/ilhu 22041 instructions. const_int is treated as a 32 bit value. 22042 22043 `B' 22044 An immediate for most arithmetic instructions. const_int is 22045 treated as a 32 bit value. 22046 22047 `C' 22048 An immediate for and/xor/or instructions. const_int is 22049 treated as a 32 bit value. 22050 22051 `D' 22052 An immediate for the `iohl' instruction. const_int is 22053 treated as a 32 bit value. 22054 22055 `I' 22056 A constant in the range [-64, 63] for shift/rotate 22057 instructions. 22058 22059 `J' 22060 An unsigned 7-bit constant for conversion/nop/channel 22061 instructions. 22062 22063 `K' 22064 A signed 10-bit constant for most arithmetic instructions. 22065 22066 `M' 22067 A signed 16 bit immediate for `stop'. 22068 22069 `N' 22070 An unsigned 16-bit constant for `iohl' and `fsmbi'. 22071 22072 `O' 22073 An unsigned 7-bit constant whose 3 least significant bits are 22074 0. 22075 22076 `P' 22077 An unsigned 3-bit constant for 16-byte rotates and shifts 22078 22079 `R' 22080 Call operand, reg, for indirect calls 22081 22082 `S' 22083 Call operand, symbol, for relative calls. 22084 22085 `T' 22086 Call operand, const_int, for absolute calls. 22087 22088 `U' 22089 An immediate which can be loaded with the il/ila/ilh/ilhu 22090 instructions. const_int is sign extended to 128 bit. 22091 22092 `W' 22093 An immediate for shift and rotate instructions. const_int is 22094 treated as a 32 bit value. 22095 22096 `Y' 22097 An immediate for and/xor/or instructions. const_int is sign 22098 extended as a 128 bit. 22099 22100 `Z' 22101 An immediate for the `iohl' instruction. const_int is sign 22102 extended to 128 bit. 22103 22104 22105_TI C6X family--`config/c6x/constraints.md'_ 22106 22107 `a' 22108 Register file A (A0-A31). 22109 22110 `b' 22111 Register file B (B0-B31). 22112 22113 `A' 22114 Predicate registers in register file A (A0-A2 on C64X and 22115 higher, A1 and A2 otherwise). 22116 22117 `B' 22118 Predicate registers in register file B (B0-B2). 22119 22120 `C' 22121 A call-used register in register file B (B0-B9, B16-B31). 22122 22123 `Da' 22124 Register file A, excluding predicate registers (A3-A31, plus 22125 A0 if not C64X or higher). 22126 22127 `Db' 22128 Register file B, excluding predicate registers (B3-B31). 22129 22130 `Iu4' 22131 Integer constant in the range 0 ... 15. 22132 22133 `Iu5' 22134 Integer constant in the range 0 ... 31. 22135 22136 `In5' 22137 Integer constant in the range -31 ... 0. 22138 22139 `Is5' 22140 Integer constant in the range -16 ... 15. 22141 22142 `I5x' 22143 Integer constant that can be the operand of an ADDA or a SUBA 22144 insn. 22145 22146 `IuB' 22147 Integer constant in the range 0 ... 65535. 22148 22149 `IsB' 22150 Integer constant in the range -32768 ... 32767. 22151 22152 `IsC' 22153 Integer constant in the range -2^20 ... 2^20 - 1. 22154 22155 `Jc' 22156 Integer constant that is a valid mask for the clr instruction. 22157 22158 `Js' 22159 Integer constant that is a valid mask for the set instruction. 22160 22161 `Q' 22162 Memory location with A base register. 22163 22164 `R' 22165 Memory location with B base register. 22166 22167 `S0' 22168 On C64x+ targets, a GP-relative small data reference. 22169 22170 `S1' 22171 Any kind of `SYMBOL_REF', for use in a call address. 22172 22173 `Si' 22174 Any kind of immediate operand, unless it matches the S0 22175 constraint. 22176 22177 `T' 22178 Memory location with B base register, but not using a long 22179 offset. 22180 22181 `W' 22182 A memory operand with an address that can't be used in an 22183 unaligned access. 22184 22185 `Z' 22186 Register B14 (aka DP). 22187 22188 22189_TILE-Gx--`config/tilegx/constraints.md'_ 22190 22191 `R00' 22192 `R01' 22193 `R02' 22194 `R03' 22195 `R04' 22196 `R05' 22197 `R06' 22198 `R07' 22199 `R08' 22200 `R09' 22201 `R10' 22202 Each of these represents a register constraint for an 22203 individual register, from r0 to r10. 22204 22205 `I' 22206 Signed 8-bit integer constant. 22207 22208 `J' 22209 Signed 16-bit integer constant. 22210 22211 `K' 22212 Unsigned 16-bit integer constant. 22213 22214 `L' 22215 Integer constant that fits in one signed byte when 22216 incremented by one (-129 ... 126). 22217 22218 `m' 22219 Memory operand. If used together with `<' or `>', the 22220 operand can have postincrement which requires printing with 22221 `%In' and `%in' on TILE-Gx. For example: 22222 22223 asm ("st_add %I0,%1,%i0" : "=m<>" (*mem) : "r" (val)); 22224 22225 `M' 22226 A bit mask suitable for the BFINS instruction. 22227 22228 `N' 22229 Integer constant that is a byte tiled out eight times. 22230 22231 `O' 22232 The integer zero constant. 22233 22234 `P' 22235 Integer constant that is a sign-extended byte tiled out as 22236 four shorts. 22237 22238 `Q' 22239 Integer constant that fits in one signed byte when incremented 22240 (-129 ... 126), but excluding -1. 22241 22242 `S' 22243 Integer constant that has all 1 bits consecutive and starting 22244 at bit 0. 22245 22246 `T' 22247 A 16-bit fragment of a got, tls, or pc-relative reference. 22248 22249 `U' 22250 Memory operand except postincrement. This is roughly the 22251 same as `m' when not used together with `<' or `>'. 22252 22253 `W' 22254 An 8-element vector constant with identical elements. 22255 22256 `Y' 22257 A 4-element vector constant with identical elements. 22258 22259 `Z0' 22260 The integer constant 0xffffffff. 22261 22262 `Z1' 22263 The integer constant 0xffffffff00000000. 22264 22265 22266_TILEPro--`config/tilepro/constraints.md'_ 22267 22268 `R00' 22269 `R01' 22270 `R02' 22271 `R03' 22272 `R04' 22273 `R05' 22274 `R06' 22275 `R07' 22276 `R08' 22277 `R09' 22278 `R10' 22279 Each of these represents a register constraint for an 22280 individual register, from r0 to r10. 22281 22282 `I' 22283 Signed 8-bit integer constant. 22284 22285 `J' 22286 Signed 16-bit integer constant. 22287 22288 `K' 22289 Nonzero integer constant with low 16 bits zero. 22290 22291 `L' 22292 Integer constant that fits in one signed byte when 22293 incremented by one (-129 ... 126). 22294 22295 `m' 22296 Memory operand. If used together with `<' or `>', the 22297 operand can have postincrement which requires printing with 22298 `%In' and `%in' on TILEPro. For example: 22299 22300 asm ("swadd %I0,%1,%i0" : "=m<>" (mem) : "r" (val)); 22301 22302 `M' 22303 A bit mask suitable for the MM instruction. 22304 22305 `N' 22306 Integer constant that is a byte tiled out four times. 22307 22308 `O' 22309 The integer zero constant. 22310 22311 `P' 22312 Integer constant that is a sign-extended byte tiled out as 22313 two shorts. 22314 22315 `Q' 22316 Integer constant that fits in one signed byte when incremented 22317 (-129 ... 126), but excluding -1. 22318 22319 `T' 22320 A symbolic operand, or a 16-bit fragment of a got, tls, or 22321 pc-relative reference. 22322 22323 `U' 22324 Memory operand except postincrement. This is roughly the 22325 same as `m' when not used together with `<' or `>'. 22326 22327 `W' 22328 A 4-element vector constant with identical elements. 22329 22330 `Y' 22331 A 2-element vector constant with identical elements. 22332 22333 22334_Visium--`config/visium/constraints.md'_ 22335 22336 `b' 22337 EAM register `mdb' 22338 22339 `c' 22340 EAM register `mdc' 22341 22342 `f' 22343 Floating point register 22344 22345 `k' 22346 Register for sibcall optimization 22347 22348 `l' 22349 General register, but not `r29', `r30' and `r31' 22350 22351 `t' 22352 Register `r1' 22353 22354 `u' 22355 Register `r2' 22356 22357 `v' 22358 Register `r3' 22359 22360 `G' 22361 Floating-point constant 0.0 22362 22363 `J' 22364 Integer constant in the range 0 .. 65535 (16-bit immediate) 22365 22366 `K' 22367 Integer constant in the range 1 .. 31 (5-bit immediate) 22368 22369 `L' 22370 Integer constant in the range -65535 .. -1 (16-bit negative 22371 immediate) 22372 22373 `M' 22374 Integer constant -1 22375 22376 `O' 22377 Integer constant 0 22378 22379 `P' 22380 Integer constant 32 22381 22382_x86 family--`config/i386/constraints.md'_ 22383 22384 `R' 22385 Legacy register--the eight integer registers available on all 22386 i386 processors (`a', `b', `c', `d', `si', `di', `bp', `sp'). 22387 22388 `q' 22389 Any register accessible as `Rl'. In 32-bit mode, `a', `b', 22390 `c', and `d'; in 64-bit mode, any integer register. 22391 22392 `Q' 22393 Any register accessible as `Rh': `a', `b', `c', and `d'. 22394 22395 `l' 22396 Any register that can be used as the index in a base+index 22397 memory access: that is, any general register except the stack 22398 pointer. 22399 22400 `a' 22401 The `a' register. 22402 22403 `b' 22404 The `b' register. 22405 22406 `c' 22407 The `c' register. 22408 22409 `d' 22410 The `d' register. 22411 22412 `S' 22413 The `si' register. 22414 22415 `D' 22416 The `di' register. 22417 22418 `A' 22419 The `a' and `d' registers. This class is used for 22420 instructions that return double word results in the `ax:dx' 22421 register pair. Single word values will be allocated either 22422 in `ax' or `dx'. For example on i386 the following 22423 implements `rdtsc': 22424 22425 unsigned long long rdtsc (void) 22426 { 22427 unsigned long long tick; 22428 __asm__ __volatile__("rdtsc":"=A"(tick)); 22429 return tick; 22430 } 22431 22432 This is not correct on x86-64 as it would allocate tick in 22433 either `ax' or `dx'. You have to use the following variant 22434 instead: 22435 22436 unsigned long long rdtsc (void) 22437 { 22438 unsigned int tickl, tickh; 22439 __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh)); 22440 return ((unsigned long long)tickh << 32)|tickl; 22441 } 22442 22443 `f' 22444 Any 80387 floating-point (stack) register. 22445 22446 `t' 22447 Top of 80387 floating-point stack (`%st(0)'). 22448 22449 `u' 22450 Second from top of 80387 floating-point stack (`%st(1)'). 22451 22452 `y' 22453 Any MMX register. 22454 22455 `x' 22456 Any SSE register. 22457 22458 `Yz' 22459 First SSE register (`%xmm0'). 22460 22461 `Y2' 22462 Any SSE register, when SSE2 is enabled. 22463 22464 `Yi' 22465 Any SSE register, when SSE2 and inter-unit moves are enabled. 22466 22467 `Ym' 22468 Any MMX register, when inter-unit moves are enabled. 22469 22470 `I' 22471 Integer constant in the range 0 ... 31, for 32-bit shifts. 22472 22473 `J' 22474 Integer constant in the range 0 ... 63, for 64-bit shifts. 22475 22476 `K' 22477 Signed 8-bit integer constant. 22478 22479 `L' 22480 `0xFF' or `0xFFFF', for andsi as a zero-extending move. 22481 22482 `M' 22483 0, 1, 2, or 3 (shifts for the `lea' instruction). 22484 22485 `N' 22486 Unsigned 8-bit integer constant (for `in' and `out' 22487 instructions). 22488 22489 `O' 22490 Integer constant in the range 0 ... 127, for 128-bit shifts. 22491 22492 `G' 22493 Standard 80387 floating point constant. 22494 22495 `C' 22496 SSE constant zero operand. 22497 22498 `e' 22499 32-bit signed integer constant, or a symbolic reference known 22500 to fit that range (for immediate operands in sign-extending 22501 x86-64 instructions). 22502 22503 `Z' 22504 32-bit unsigned integer constant, or a symbolic reference 22505 known to fit that range (for immediate operands in 22506 zero-extending x86-64 instructions). 22507 22508 22509_Xstormy16--`config/stormy16/stormy16.h'_ 22510 22511 `a' 22512 Register r0. 22513 22514 `b' 22515 Register r1. 22516 22517 `c' 22518 Register r2. 22519 22520 `d' 22521 Register r8. 22522 22523 `e' 22524 Registers r0 through r7. 22525 22526 `t' 22527 Registers r0 and r1. 22528 22529 `y' 22530 The carry register. 22531 22532 `z' 22533 Registers r8 and r9. 22534 22535 `I' 22536 A constant between 0 and 3 inclusive. 22537 22538 `J' 22539 A constant that has exactly one bit set. 22540 22541 `K' 22542 A constant that has exactly one bit clear. 22543 22544 `L' 22545 A constant between 0 and 255 inclusive. 22546 22547 `M' 22548 A constant between -255 and 0 inclusive. 22549 22550 `N' 22551 A constant between -3 and 0 inclusive. 22552 22553 `O' 22554 A constant between 1 and 4 inclusive. 22555 22556 `P' 22557 A constant between -4 and -1 inclusive. 22558 22559 `Q' 22560 A memory reference that is a stack push. 22561 22562 `R' 22563 A memory reference that is a stack pop. 22564 22565 `S' 22566 A memory reference that refers to a constant address of known 22567 value. 22568 22569 `T' 22570 The register indicated by Rx (not implemented yet). 22571 22572 `U' 22573 A constant that is not between 2 and 15 inclusive. 22574 22575 `Z' 22576 The constant 0. 22577 22578 22579_Xtensa--`config/xtensa/constraints.md'_ 22580 22581 `a' 22582 General-purpose 32-bit register 22583 22584 `b' 22585 One-bit boolean register 22586 22587 `A' 22588 MAC16 40-bit accumulator register 22589 22590 `I' 22591 Signed 12-bit integer constant, for use in MOVI instructions 22592 22593 `J' 22594 Signed 8-bit integer constant, for use in ADDI instructions 22595 22596 `K' 22597 Integer constant valid for BccI instructions 22598 22599 `L' 22600 Unsigned constant valid for BccUI instructions 22601 22602 22603 22604 22605File: gccint.info, Node: Disable Insn Alternatives, Next: Define Constraints, Prev: Machine Constraints, Up: Constraints 22606 2260716.8.6 Disable insn alternatives using the `enabled' attribute 22608-------------------------------------------------------------- 22609 22610There are three insn attributes that may be used to selectively disable 22611instruction alternatives: 22612 22613`enabled' 22614 Says whether an alternative is available on the current subtarget. 22615 22616`preferred_for_size' 22617 Says whether an enabled alternative should be used in code that is 22618 optimized for size. 22619 22620`preferred_for_speed' 22621 Says whether an enabled alternative should be used in code that is 22622 optimized for speed. 22623 22624 All these attributes should use `(const_int 1)' to allow an alternative 22625or `(const_int 0)' to disallow it. The attributes must be a static 22626property of the subtarget; they cannot for example depend on the 22627current operands, on the current optimization level, on the location of 22628the insn within the body of a loop, on whether register allocation has 22629finished, or on the current compiler pass. 22630 22631 The `enabled' attribute is a correctness property. It tells GCC to act 22632as though the disabled alternatives were never defined in the first 22633place. This is useful when adding new instructions to an existing 22634pattern in cases where the new instructions are only available for 22635certain cpu architecture levels (typically mapped to the `-march=' 22636command-line option). 22637 22638 In contrast, the `preferred_for_size' and `preferred_for_speed' 22639attributes are strong optimization hints rather than correctness 22640properties. `preferred_for_size' tells GCC which alternatives to 22641consider when adding or modifying an instruction that GCC wants to 22642optimize for size. `preferred_for_speed' does the same thing for 22643speed. Note that things like code motion can lead to cases where code 22644optimized for size uses alternatives that are not preferred for size, 22645and similarly for speed. 22646 22647 Although `define_insn's can in principle specify the `enabled' 22648attribute directly, it is often clearer to have subsiduary attributes 22649for each architectural feature of interest. The `define_insn's can 22650then use these subsiduary attributes to say which alternatives require 22651which features. The example below does this for `cpu_facility'. 22652 22653 E.g. the following two patterns could easily be merged using the 22654`enabled' attribute: 22655 22656 22657 (define_insn "*movdi_old" 22658 [(set (match_operand:DI 0 "register_operand" "=d") 22659 (match_operand:DI 1 "register_operand" " d"))] 22660 "!TARGET_NEW" 22661 "lgr %0,%1") 22662 22663 (define_insn "*movdi_new" 22664 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 22665 (match_operand:DI 1 "register_operand" " d,d,f"))] 22666 "TARGET_NEW" 22667 "@ 22668 lgr %0,%1 22669 ldgr %0,%1 22670 lgdr %0,%1") 22671 22672 to: 22673 22674 22675 (define_insn "*movdi_combined" 22676 [(set (match_operand:DI 0 "register_operand" "=d,f,d") 22677 (match_operand:DI 1 "register_operand" " d,d,f"))] 22678 "" 22679 "@ 22680 lgr %0,%1 22681 ldgr %0,%1 22682 lgdr %0,%1" 22683 [(set_attr "cpu_facility" "*,new,new")]) 22684 22685 with the `enabled' attribute defined like this: 22686 22687 22688 (define_attr "cpu_facility" "standard,new" (const_string "standard")) 22689 22690 (define_attr "enabled" "" 22691 (cond [(eq_attr "cpu_facility" "standard") (const_int 1) 22692 (and (eq_attr "cpu_facility" "new") 22693 (ne (symbol_ref "TARGET_NEW") (const_int 0))) 22694 (const_int 1)] 22695 (const_int 0))) 22696 22697 22698File: gccint.info, Node: Define Constraints, Next: C Constraint Interface, Prev: Disable Insn Alternatives, Up: Constraints 22699 2270016.8.7 Defining Machine-Specific Constraints 22701-------------------------------------------- 22702 22703Machine-specific constraints fall into two categories: register and 22704non-register constraints. Within the latter category, constraints 22705which allow subsets of all possible memory or address operands should 22706be specially marked, to give `reload' more information. 22707 22708 Machine-specific constraints can be given names of arbitrary length, 22709but they must be entirely composed of letters, digits, underscores 22710(`_'), and angle brackets (`< >'). Like C identifiers, they must begin 22711with a letter or underscore. 22712 22713 In order to avoid ambiguity in operand constraint strings, no 22714constraint can have a name that begins with any other constraint's 22715name. For example, if `x' is defined as a constraint name, `xy' may 22716not be, and vice versa. As a consequence of this rule, no constraint 22717may begin with one of the generic constraint letters: `E F V X g i m n 22718o p r s'. 22719 22720 Register constraints correspond directly to register classes. *Note 22721Register Classes::. There is thus not much flexibility in their 22722definitions. 22723 22724 -- MD Expression: define_register_constraint name regclass docstring 22725 All three arguments are string constants. NAME is the name of the 22726 constraint, as it will appear in `match_operand' expressions. If 22727 NAME is a multi-letter constraint its length shall be the same for 22728 all constraints starting with the same letter. REGCLASS can be 22729 either the name of the corresponding register class (*note 22730 Register Classes::), or a C expression which evaluates to the 22731 appropriate register class. If it is an expression, it must have 22732 no side effects, and it cannot look at the operand. The usual use 22733 of expressions is to map some register constraints to `NO_REGS' 22734 when the register class is not available on a given 22735 subarchitecture. 22736 22737 DOCSTRING is a sentence documenting the meaning of the constraint. 22738 Docstrings are explained further below. 22739 22740 Non-register constraints are more like predicates: the constraint 22741definition gives a Boolean expression which indicates whether the 22742constraint matches. 22743 22744 -- MD Expression: define_constraint name docstring exp 22745 The NAME and DOCSTRING arguments are the same as for 22746 `define_register_constraint', but note that the docstring comes 22747 immediately after the name for these expressions. EXP is an RTL 22748 expression, obeying the same rules as the RTL expressions in 22749 predicate definitions. *Note Defining Predicates::, for details. 22750 If it evaluates true, the constraint matches; if it evaluates 22751 false, it doesn't. Constraint expressions should indicate which 22752 RTL codes they might match, just like predicate expressions. 22753 22754 `match_test' C expressions have access to the following variables: 22755 22756 OP 22757 The RTL object defining the operand. 22758 22759 MODE 22760 The machine mode of OP. 22761 22762 IVAL 22763 `INTVAL (OP)', if OP is a `const_int'. 22764 22765 HVAL 22766 `CONST_DOUBLE_HIGH (OP)', if OP is an integer `const_double'. 22767 22768 LVAL 22769 `CONST_DOUBLE_LOW (OP)', if OP is an integer `const_double'. 22770 22771 RVAL 22772 `CONST_DOUBLE_REAL_VALUE (OP)', if OP is a floating-point 22773 `const_double'. 22774 22775 The *VAL variables should only be used once another piece of the 22776 expression has verified that OP is the appropriate kind of RTL 22777 object. 22778 22779 Most non-register constraints should be defined with 22780`define_constraint'. The remaining two definition expressions are only 22781appropriate for constraints that should be handled specially by 22782`reload' if they fail to match. 22783 22784 -- MD Expression: define_memory_constraint name docstring exp 22785 Use this expression for constraints that match a subset of all 22786 memory operands: that is, `reload' can make them match by 22787 converting the operand to the form `(mem (reg X))', where X is a 22788 base register (from the register class specified by 22789 `BASE_REG_CLASS', *note Register Classes::). 22790 22791 For example, on the S/390, some instructions do not accept 22792 arbitrary memory references, but only those that do not make use 22793 of an index register. The constraint letter `Q' is defined to 22794 represent a memory address of this type. If `Q' is defined with 22795 `define_memory_constraint', a `Q' constraint can handle any memory 22796 operand, because `reload' knows it can simply copy the memory 22797 address into a base register if required. This is analogous to 22798 the way an `o' constraint can handle any memory operand. 22799 22800 The syntax and semantics are otherwise identical to 22801 `define_constraint'. 22802 22803 -- MD Expression: define_address_constraint name docstring exp 22804 Use this expression for constraints that match a subset of all 22805 address operands: that is, `reload' can make the constraint match 22806 by converting the operand to the form `(reg X)', again with X a 22807 base register. 22808 22809 Constraints defined with `define_address_constraint' can only be 22810 used with the `address_operand' predicate, or machine-specific 22811 predicates that work the same way. They are treated analogously to 22812 the generic `p' constraint. 22813 22814 The syntax and semantics are otherwise identical to 22815 `define_constraint'. 22816 22817 For historical reasons, names beginning with the letters `G H' are 22818reserved for constraints that match only `const_double's, and names 22819beginning with the letters `I J K L M N O P' are reserved for 22820constraints that match only `const_int's. This may change in the 22821future. For the time being, constraints with these names must be 22822written in a stylized form, so that `genpreds' can tell you did it 22823correctly: 22824 22825 (define_constraint "[GHIJKLMNOP]..." 22826 "DOC..." 22827 (and (match_code "const_int") ; `const_double' for G/H 22828 CONDITION...)) ; usually a `match_test' 22829 22830 It is fine to use names beginning with other letters for constraints 22831that match `const_double's or `const_int's. 22832 22833 Each docstring in a constraint definition should be one or more 22834complete sentences, marked up in Texinfo format. _They are currently 22835unused._ In the future they will be copied into the GCC manual, in 22836*note Machine Constraints::, replacing the hand-maintained tables 22837currently found in that section. Also, in the future the compiler may 22838use this to give more helpful diagnostics when poor choice of `asm' 22839constraints causes a reload failure. 22840 22841 If you put the pseudo-Texinfo directive `@internal' at the beginning 22842of a docstring, then (in the future) it will appear only in the 22843internals manual's version of the machine-specific constraint tables. 22844Use this for constraints that should not appear in `asm' statements. 22845 22846 22847File: gccint.info, Node: C Constraint Interface, Prev: Define Constraints, Up: Constraints 22848 2284916.8.8 Testing constraints from C 22850--------------------------------- 22851 22852It is occasionally useful to test a constraint from C code rather than 22853implicitly via the constraint string in a `match_operand'. The 22854generated file `tm_p.h' declares a few interfaces for working with 22855constraints. At present these are defined for all constraints except 22856`g' (which is equivalent to `general_operand'). 22857 22858 Some valid constraint names are not valid C identifiers, so there is a 22859mangling scheme for referring to them from C. Constraint names that do 22860not contain angle brackets or underscores are left unchanged. 22861Underscores are doubled, each `<' is replaced with `_l', and each `>' 22862with `_g'. Here are some examples: 22863 22864 *Original* *Mangled* 22865 `x' `x' 22866 `P42x' `P42x' 22867 `P4_x' `P4__x' 22868 `P4>x' `P4_gx' 22869 `P4>>' `P4_g_g' 22870 `P4_g>' `P4__g_g' 22871 22872 Throughout this section, the variable C is either a constraint in the 22873abstract sense, or a constant from `enum constraint_num'; the variable 22874M is a mangled constraint name (usually as part of a larger identifier). 22875 22876 -- Enum: constraint_num 22877 For each constraint except `g', there is a corresponding 22878 enumeration constant: `CONSTRAINT_' plus the mangled name of the 22879 constraint. Functions that take an `enum constraint_num' as an 22880 argument expect one of these constants. 22881 22882 -- Function: inline bool satisfies_constraint_M (rtx EXP) 22883 For each non-register constraint M except `g', there is one of 22884 these functions; it returns `true' if EXP satisfies the 22885 constraint. These functions are only visible if `rtl.h' was 22886 included before `tm_p.h'. 22887 22888 -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num 22889 C) 22890 Like the `satisfies_constraint_M' functions, but the constraint to 22891 test is given as an argument, C. If C specifies a register 22892 constraint, this function will always return `false'. 22893 22894 -- Function: enum reg_class reg_class_for_constraint (enum 22895 constraint_num C) 22896 Returns the register class associated with C. If C is not a 22897 register constraint, or those registers are not available for the 22898 currently selected subtarget, returns `NO_REGS'. 22899 22900 Here is an example use of `satisfies_constraint_M'. In peephole 22901optimizations (*note Peephole Definitions::), operand constraint 22902strings are ignored, so if there are relevant constraints, they must be 22903tested in the C condition. In the example, the optimization is applied 22904if operand 2 does _not_ satisfy the `K' constraint. (This is a 22905simplified version of a peephole definition from the i386 machine 22906description.) 22907 22908 (define_peephole2 22909 [(match_scratch:SI 3 "r") 22910 (set (match_operand:SI 0 "register_operand" "") 22911 (mult:SI (match_operand:SI 1 "memory_operand" "") 22912 (match_operand:SI 2 "immediate_operand" "")))] 22913 22914 "!satisfies_constraint_K (operands[2])" 22915 22916 [(set (match_dup 3) (match_dup 1)) 22917 (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))] 22918 22919 "") 22920 22921 22922File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc 22923 2292416.9 Standard Pattern Names For Generation 22925========================================== 22926 22927Here is a table of the instruction names that are meaningful in the RTL 22928generation pass of the compiler. Giving one of these names to an 22929instruction pattern tells the RTL generation pass that it can use the 22930pattern to accomplish a certain task. 22931 22932`movM' 22933 Here M stands for a two-letter machine mode name, in lowercase. 22934 This instruction pattern moves data with that machine mode from 22935 operand 1 to operand 0. For example, `movsi' moves full-word data. 22936 22937 If operand 0 is a `subreg' with mode M of a register whose own 22938 mode is wider than M, the effect of this instruction is to store 22939 the specified value in the part of the register that corresponds 22940 to mode M. Bits outside of M, but which are within the same 22941 target word as the `subreg' are undefined. Bits which are outside 22942 the target word are left unchanged. 22943 22944 This class of patterns is special in several ways. First of all, 22945 each of these names up to and including full word size _must_ be 22946 defined, because there is no other way to copy a datum from one 22947 place to another. If there are patterns accepting operands in 22948 larger modes, `movM' must be defined for integer modes of those 22949 sizes. 22950 22951 Second, these patterns are not used solely in the RTL generation 22952 pass. Even the reload pass can generate move insns to copy values 22953 from stack slots into temporary registers. When it does so, one 22954 of the operands is a hard register and the other is an operand 22955 that can need to be reloaded into a register. 22956 22957 Therefore, when given such a pair of operands, the pattern must 22958 generate RTL which needs no reloading and needs no temporary 22959 registers--no registers other than the operands. For example, if 22960 you support the pattern with a `define_expand', then in such a 22961 case the `define_expand' mustn't call `force_reg' or any other such 22962 function which might generate new pseudo registers. 22963 22964 This requirement exists even for subword modes on a RISC machine 22965 where fetching those modes from memory normally requires several 22966 insns and some temporary registers. 22967 22968 During reload a memory reference with an invalid address may be 22969 passed as an operand. Such an address will be replaced with a 22970 valid address later in the reload pass. In this case, nothing may 22971 be done with the address except to use it as it stands. If it is 22972 copied, it will not be replaced with a valid address. No attempt 22973 should be made to make such an address into a valid address and no 22974 routine (such as `change_address') that will do so may be called. 22975 Note that `general_operand' will fail when applied to such an 22976 address. 22977 22978 The global variable `reload_in_progress' (which must be explicitly 22979 declared if required) can be used to determine whether such special 22980 handling is required. 22981 22982 The variety of operands that have reloads depends on the rest of 22983 the machine description, but typically on a RISC machine these can 22984 only be pseudo registers that did not get hard registers, while on 22985 other machines explicit memory references will get optional 22986 reloads. 22987 22988 If a scratch register is required to move an object to or from 22989 memory, it can be allocated using `gen_reg_rtx' prior to life 22990 analysis. 22991 22992 If there are cases which need scratch registers during or after 22993 reload, you must provide an appropriate secondary_reload target 22994 hook. 22995 22996 The macro `can_create_pseudo_p' can be used to determine if it is 22997 unsafe to create new pseudo registers. If this variable is 22998 nonzero, then it is unsafe to call `gen_reg_rtx' to allocate a new 22999 pseudo. 23000 23001 The constraints on a `movM' must permit moving any hard register 23002 to any other hard register provided that `HARD_REGNO_MODE_OK' 23003 permits mode M in both registers and `TARGET_REGISTER_MOVE_COST' 23004 applied to their classes returns a value of 2. 23005 23006 It is obligatory to support floating point `movM' instructions 23007 into and out of any registers that can hold fixed point values, 23008 because unions and structures (which have modes `SImode' or 23009 `DImode') can be in those registers and they may have floating 23010 point members. 23011 23012 There may also be a need to support fixed point `movM' 23013 instructions in and out of floating point registers. 23014 Unfortunately, I have forgotten why this was so, and I don't know 23015 whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed 23016 point values in floating point registers, then the constraints of 23017 the fixed point `movM' instructions must be designed to avoid ever 23018 trying to reload into a floating point register. 23019 23020`reload_inM' 23021`reload_outM' 23022 These named patterns have been obsoleted by the target hook 23023 `secondary_reload'. 23024 23025 Like `movM', but used when a scratch register is required to move 23026 between operand 0 and operand 1. Operand 2 describes the scratch 23027 register. See the discussion of the `SECONDARY_RELOAD_CLASS' 23028 macro in *note Register Classes::. 23029 23030 There are special restrictions on the form of the `match_operand's 23031 used in these patterns. First, only the predicate for the reload 23032 operand is examined, i.e., `reload_in' examines operand 1, but not 23033 the predicates for operand 0 or 2. Second, there may be only one 23034 alternative in the constraints. Third, only a single register 23035 class letter may be used for the constraint; subsequent constraint 23036 letters are ignored. As a special exception, an empty constraint 23037 string matches the `ALL_REGS' register class. This may relieve 23038 ports of the burden of defining an `ALL_REGS' constraint letter 23039 just for these patterns. 23040 23041`movstrictM' 23042 Like `movM' except that if operand 0 is a `subreg' with mode M of 23043 a register whose natural mode is wider, the `movstrictM' 23044 instruction is guaranteed not to alter any of the register except 23045 the part which belongs to mode M. 23046 23047`movmisalignM' 23048 This variant of a move pattern is designed to load or store a value 23049 from a memory address that is not naturally aligned for its mode. 23050 For a store, the memory will be in operand 0; for a load, the 23051 memory will be in operand 1. The other operand is guaranteed not 23052 to be a memory, so that it's easy to tell whether this is a load 23053 or store. 23054 23055 This pattern is used by the autovectorizer, and when expanding a 23056 `MISALIGNED_INDIRECT_REF' expression. 23057 23058`load_multiple' 23059 Load several consecutive memory locations into consecutive 23060 registers. Operand 0 is the first of the consecutive registers, 23061 operand 1 is the first memory location, and operand 2 is a 23062 constant: the number of consecutive registers. 23063 23064 Define this only if the target machine really has such an 23065 instruction; do not define this if the most efficient way of 23066 loading consecutive registers from memory is to do them one at a 23067 time. 23068 23069 On some machines, there are restrictions as to which consecutive 23070 registers can be stored into memory, such as particular starting or 23071 ending register numbers or only a range of valid counts. For those 23072 machines, use a `define_expand' (*note Expander Definitions::) and 23073 make the pattern fail if the restrictions are not met. 23074 23075 Write the generated insn as a `parallel' with elements being a 23076 `set' of one register from the appropriate memory location (you may 23077 also need `use' or `clobber' elements). Use a `match_parallel' 23078 (*note RTL Template::) to recognize the insn. See `rs6000.md' for 23079 examples of the use of this insn pattern. 23080 23081`store_multiple' 23082 Similar to `load_multiple', but store several consecutive registers 23083 into consecutive memory locations. Operand 0 is the first of the 23084 consecutive memory locations, operand 1 is the first register, and 23085 operand 2 is a constant: the number of consecutive registers. 23086 23087`vec_load_lanesMN' 23088 Perform an interleaved load of several vectors from memory operand 23089 1 into register operand 0. Both operands have mode M. The 23090 register operand is viewed as holding consecutive vectors of mode 23091 N, while the memory operand is a flat array that contains the same 23092 number of elements. The operation is equivalent to: 23093 23094 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 23095 for (j = 0; j < GET_MODE_NUNITS (N); j++) 23096 for (i = 0; i < c; i++) 23097 operand0[i][j] = operand1[j * c + i]; 23098 23099 For example, `vec_load_lanestiv4hi' loads 8 16-bit values from 23100 memory into a register of mode `TI'. The register contains two 23101 consecutive vectors of mode `V4HI'. 23102 23103 This pattern can only be used if: 23104 TARGET_ARRAY_MODE_SUPPORTED_P (N, C) 23105 is true. GCC assumes that, if a target supports this kind of 23106 instruction for some mode N, it also supports unaligned loads for 23107 vectors of mode N. 23108 23109`vec_store_lanesMN' 23110 Equivalent to `vec_load_lanesMN', with the memory and register 23111 operands reversed. That is, the instruction is equivalent to: 23112 23113 int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N); 23114 for (j = 0; j < GET_MODE_NUNITS (N); j++) 23115 for (i = 0; i < c; i++) 23116 operand0[j * c + i] = operand1[i][j]; 23117 23118 for a memory operand 0 and register operand 1. 23119 23120`vec_setM' 23121 Set given field in the vector value. Operand 0 is the vector to 23122 modify, operand 1 is new value of field and operand 2 specify the 23123 field index. 23124 23125`vec_extractM' 23126 Extract given field from the vector value. Operand 1 is the 23127 vector, operand 2 specify field index and operand 0 place to store 23128 value into. 23129 23130`vec_initM' 23131 Initialize the vector to given values. Operand 0 is the vector to 23132 initialize and operand 1 is parallel containing values for 23133 individual fields. 23134 23135`vcondMN' 23136 Output a conditional vector move. Operand 0 is the destination to 23137 receive a combination of operand 1 and operand 2, which are of 23138 mode M, dependent on the outcome of the predicate in operand 3 23139 which is a vector comparison with operands of mode N in operands 4 23140 and 5. The modes M and N should have the same size. Operand 0 23141 will be set to the value OP1 & MSK | OP2 & ~MSK where MSK is 23142 computed by element-wise evaluation of the vector comparison with 23143 a truth value of all-ones and a false value of all-zeros. 23144 23145`vec_permM' 23146 Output a (variable) vector permutation. Operand 0 is the 23147 destination to receive elements from operand 1 and operand 2, 23148 which are of mode M. Operand 3 is the "selector". It is an 23149 integral mode vector of the same width and number of elements as 23150 mode M. 23151 23152 The input elements are numbered from 0 in operand 1 through 2*N-1 23153 in operand 2. The elements of the selector must be computed 23154 modulo 2*N. Note that if `rtx_equal_p(operand1, operand2)', this 23155 can be implemented with just operand 1 and selector elements 23156 modulo N. 23157 23158 In order to make things easy for a number of targets, if there is 23159 no `vec_perm' pattern for mode M, but there is for mode Q where Q 23160 is a vector of `QImode' of the same width as M, the middle-end 23161 will lower the mode M `VEC_PERM_EXPR' to mode Q. 23162 23163`vec_perm_constM' 23164 Like `vec_perm' except that the permutation is a compile-time 23165 constant. That is, operand 3, the "selector", is a `CONST_VECTOR'. 23166 23167 Some targets cannot perform a permutation with a variable selector, 23168 but can efficiently perform a constant permutation. Further, the 23169 target hook `vec_perm_ok' is queried to determine if the specific 23170 constant permutation is available efficiently; the named pattern 23171 is never expanded without `vec_perm_ok' returning true. 23172 23173 There is no need for a target to supply both `vec_permM' and 23174 `vec_perm_constM' if the former can trivially implement the 23175 operation with, say, the vector constant loaded into a register. 23176 23177`pushM1' 23178 Output a push instruction. Operand 0 is value to push. Used only 23179 when `PUSH_ROUNDING' is defined. For historical reason, this 23180 pattern may be missing and in such case an `mov' expander is used 23181 instead, with a `MEM' expression forming the push operation. The 23182 `mov' expander method is deprecated. 23183 23184`addM3' 23185 Add operand 2 and operand 1, storing the result in operand 0. All 23186 operands must have mode M. This can be used even on two-address 23187 machines, by means of constraints requiring operands 1 and 0 to be 23188 the same location. 23189 23190`ssaddM3', `usaddM3' 23191`subM3', `sssubM3', `ussubM3' 23192`mulM3', `ssmulM3', `usmulM3' 23193`divM3', `ssdivM3' 23194`udivM3', `usdivM3' 23195`modM3', `umodM3' 23196`uminM3', `umaxM3' 23197`andM3', `iorM3', `xorM3' 23198 Similar, for other arithmetic operations. 23199 23200`addvM4' 23201 Like `addM3' but takes a `code_label' as operand 3 and emits code 23202 to jump to it if signed overflow occurs during the addition. This 23203 pattern is used to implement the built-in functions performing 23204 signed integer addition with overflow checking. 23205 23206`subvM4', `mulvM4' 23207 Similar, for other signed arithmetic operations. 23208 23209`umulvM4' 23210 Like `mulvM4' but for unsigned multiplication. That is to say, 23211 the operation is the same as signed multiplication but the jump is 23212 taken only on unsigned overflow. 23213 23214`addptrM3' 23215 Like `addM3' but is guaranteed to only be used for address 23216 calculations. The expanded code is not allowed to clobber the 23217 condition code. It only needs to be defined if `addM3' sets the 23218 condition code. If adds used for address calculations and normal 23219 adds are not compatible it is required to expand a distinct 23220 pattern (e.g. using an unspec). The pattern is used by LRA to emit 23221 address calculations. `addM3' is used if `addptrM3' is not 23222 defined. 23223 23224`fmaM4' 23225 Multiply operand 2 and operand 1, then add operand 3, storing the 23226 result in operand 0 without doing an intermediate rounding step. 23227 All operands must have mode M. This pattern is used to implement 23228 the `fma', `fmaf', and `fmal' builtin functions from the ISO C99 23229 standard. 23230 23231`fmsM4' 23232 Like `fmaM4', except operand 3 subtracted from the product instead 23233 of added to the product. This is represented in the rtl as 23234 23235 (fma:M OP1 OP2 (neg:M OP3)) 23236 23237`fnmaM4' 23238 Like `fmaM4' except that the intermediate product is negated 23239 before being added to operand 3. This is represented in the rtl as 23240 23241 (fma:M (neg:M OP1) OP2 OP3) 23242 23243`fnmsM4' 23244 Like `fmsM4' except that the intermediate product is negated 23245 before subtracting operand 3. This is represented in the rtl as 23246 23247 (fma:M (neg:M OP1) OP2 (neg:M OP3)) 23248 23249`sminM3', `smaxM3' 23250 Signed minimum and maximum operations. When used with floating 23251 point, if both operands are zeros, or if either operand is `NaN', 23252 then it is unspecified which of the two operands is returned as 23253 the result. 23254 23255`reduc_smin_M', `reduc_smax_M' 23256 Find the signed minimum/maximum of the elements of a vector. The 23257 vector is operand 1, and the result is stored in the least 23258 significant bits of operand 0 (also a vector). The output and 23259 input vector should have the same modes. These are legacy optabs, 23260 and platforms should prefer to implement `reduc_smin_scal_M' and 23261 `reduc_smax_scal_M'. 23262 23263`reduc_umin_M', `reduc_umax_M' 23264 Find the unsigned minimum/maximum of the elements of a vector. The 23265 vector is operand 1, and the result is stored in the least 23266 significant bits of operand 0 (also a vector). The output and 23267 input vector should have the same modes. These are legacy optabs, 23268 and platforms should prefer to implement `reduc_umin_scal_M' and 23269 `reduc_umax_scal_M'. 23270 23271`reduc_splus_M', `reduc_uplus_M' 23272 Compute the sum of the signed/unsigned elements of a vector. The 23273 vector is operand 1, and the result is stored in the least 23274 significant bits of operand 0 (also a vector). The output and 23275 input vector should have the same modes. These are legacy optabs, 23276 and platforms should prefer to implement `reduc_plus_scal_M'. 23277 23278`reduc_smin_scal_M', `reduc_smax_scal_M' 23279 Find the signed minimum/maximum of the elements of a vector. The 23280 vector is operand 1, and operand 0 is the scalar result, with mode 23281 equal to the mode of the elements of the input vector. 23282 23283`reduc_umin_scal_M', `reduc_umax_scal_M' 23284 Find the unsigned minimum/maximum of the elements of a vector. The 23285 vector is operand 1, and operand 0 is the scalar result, with mode 23286 equal to the mode of the elements of the input vector. 23287 23288`reduc_plus_scal_M' 23289 Compute the sum of the elements of a vector. The vector is operand 23290 1, and operand 0 is the scalar result, with mode equal to the mode 23291 of the elements of the input vector. 23292 23293`sdot_prodM' 23294`udot_prodM' 23295 Compute the sum of the products of two signed/unsigned elements. 23296 Operand 1 and operand 2 are of the same mode. Their product, which 23297 is of a wider mode, is computed and added to operand 3. Operand 3 23298 is of a mode equal or wider than the mode of the product. The 23299 result is placed in operand 0, which is of the same mode as 23300 operand 3. 23301 23302`ssadM' 23303 23304`usadM' 23305 Compute the sum of absolute differences of two signed/unsigned 23306 elements. Operand 1 and operand 2 are of the same mode. Their 23307 absolute difference, which is of a wider mode, is computed and 23308 added to operand 3. Operand 3 is of a mode equal or wider than the 23309 mode of the absolute difference. The result is placed in operand 23310 0, which is of the same mode as operand 3. 23311 23312`ssum_widenM3' 23313`usum_widenM3' 23314 Operands 0 and 2 are of the same mode, which is wider than the 23315 mode of operand 1. Add operand 1 to operand 2 and place the 23316 widened result in operand 0. (This is used express accumulation of 23317 elements into an accumulator of a wider mode.) 23318 23319`vec_shr_M' 23320 Whole vector right shift in bits, i.e. towards element 0. Operand 23321 1 is a vector to be shifted. Operand 2 is an integer shift amount 23322 in bits. Operand 0 is where the resulting shifted vector is 23323 stored. The output and input vectors should have the same modes. 23324 23325`vec_pack_trunc_M' 23326 Narrow (demote) and merge the elements of two vectors. Operands 1 23327 and 2 are vectors of the same mode having N integral or floating 23328 point elements of size S. Operand 0 is the resulting vector in 23329 which 2*N elements of size N/2 are concatenated after narrowing 23330 them down using truncation. 23331 23332`vec_pack_ssat_M', `vec_pack_usat_M' 23333 Narrow (demote) and merge the elements of two vectors. Operands 1 23334 and 2 are vectors of the same mode having N integral elements of 23335 size S. Operand 0 is the resulting vector in which the elements 23336 of the two input vectors are concatenated after narrowing them 23337 down using signed/unsigned saturating arithmetic. 23338 23339`vec_pack_sfix_trunc_M', `vec_pack_ufix_trunc_M' 23340 Narrow, convert to signed/unsigned integral type and merge the 23341 elements of two vectors. Operands 1 and 2 are vectors of the same 23342 mode having N floating point elements of size S. Operand 0 is the 23343 resulting vector in which 2*N elements of size N/2 are 23344 concatenated. 23345 23346`vec_unpacks_hi_M', `vec_unpacks_lo_M' 23347 Extract and widen (promote) the high/low part of a vector of signed 23348 integral or floating point elements. The input vector (operand 1) 23349 has N elements of size S. Widen (promote) the high/low elements 23350 of the vector using signed or floating point extension and place 23351 the resulting N/2 values of size 2*S in the output vector (operand 23352 0). 23353 23354`vec_unpacku_hi_M', `vec_unpacku_lo_M' 23355 Extract and widen (promote) the high/low part of a vector of 23356 unsigned integral elements. The input vector (operand 1) has N 23357 elements of size S. Widen (promote) the high/low elements of the 23358 vector using zero extension and place the resulting N/2 values of 23359 size 2*S in the output vector (operand 0). 23360 23361`vec_unpacks_float_hi_M', `vec_unpacks_float_lo_M' 23362`vec_unpacku_float_hi_M', `vec_unpacku_float_lo_M' 23363 Extract, convert to floating point type and widen the high/low 23364 part of a vector of signed/unsigned integral elements. The input 23365 vector (operand 1) has N elements of size S. Convert the high/low 23366 elements of the vector using floating point conversion and place 23367 the resulting N/2 values of size 2*S in the output vector (operand 23368 0). 23369 23370`vec_widen_umult_hi_M', `vec_widen_umult_lo_M' 23371`vec_widen_smult_hi_M', `vec_widen_smult_lo_M' 23372`vec_widen_umult_even_M', `vec_widen_umult_odd_M' 23373`vec_widen_smult_even_M', `vec_widen_smult_odd_M' 23374 Signed/Unsigned widening multiplication. The two inputs (operands 23375 1 and 2) are vectors with N signed/unsigned elements of size S. 23376 Multiply the high/low or even/odd elements of the two vectors, and 23377 put the N/2 products of size 2*S in the output vector (operand 0). 23378 A target shouldn't implement even/odd pattern pair if it is less 23379 efficient than lo/hi one. 23380 23381`vec_widen_ushiftl_hi_M', `vec_widen_ushiftl_lo_M' 23382`vec_widen_sshiftl_hi_M', `vec_widen_sshiftl_lo_M' 23383 Signed/Unsigned widening shift left. The first input (operand 1) 23384 is a vector with N signed/unsigned elements of size S. Operand 2 23385 is a constant. Shift the high/low elements of operand 1, and put 23386 the N/2 results of size 2*S in the output vector (operand 0). 23387 23388`mulhisi3' 23389 Multiply operands 1 and 2, which have mode `HImode', and store a 23390 `SImode' product in operand 0. 23391 23392`mulqihi3', `mulsidi3' 23393 Similar widening-multiplication instructions of other widths. 23394 23395`umulqihi3', `umulhisi3', `umulsidi3' 23396 Similar widening-multiplication instructions that do unsigned 23397 multiplication. 23398 23399`usmulqihi3', `usmulhisi3', `usmulsidi3' 23400 Similar widening-multiplication instructions that interpret the 23401 first operand as unsigned and the second operand as signed, then 23402 do a signed multiplication. 23403 23404`smulM3_highpart' 23405 Perform a signed multiplication of operands 1 and 2, which have 23406 mode M, and store the most significant half of the product in 23407 operand 0. The least significant half of the product is discarded. 23408 23409`umulM3_highpart' 23410 Similar, but the multiplication is unsigned. 23411 23412`maddMN4' 23413 Multiply operands 1 and 2, sign-extend them to mode N, add operand 23414 3, and store the result in operand 0. Operands 1 and 2 have mode 23415 M and operands 0 and 3 have mode N. Both modes must be integer or 23416 fixed-point modes and N must be twice the size of M. 23417 23418 In other words, `maddMN4' is like `mulMN3' except that it also 23419 adds operand 3. 23420 23421 These instructions are not allowed to `FAIL'. 23422 23423`umaddMN4' 23424 Like `maddMN4', but zero-extend the multiplication operands 23425 instead of sign-extending them. 23426 23427`ssmaddMN4' 23428 Like `maddMN4', but all involved operations must be 23429 signed-saturating. 23430 23431`usmaddMN4' 23432 Like `umaddMN4', but all involved operations must be 23433 unsigned-saturating. 23434 23435`msubMN4' 23436 Multiply operands 1 and 2, sign-extend them to mode N, subtract the 23437 result from operand 3, and store the result in operand 0. 23438 Operands 1 and 2 have mode M and operands 0 and 3 have mode N. 23439 Both modes must be integer or fixed-point modes and N must be twice 23440 the size of M. 23441 23442 In other words, `msubMN4' is like `mulMN3' except that it also 23443 subtracts the result from operand 3. 23444 23445 These instructions are not allowed to `FAIL'. 23446 23447`umsubMN4' 23448 Like `msubMN4', but zero-extend the multiplication operands 23449 instead of sign-extending them. 23450 23451`ssmsubMN4' 23452 Like `msubMN4', but all involved operations must be 23453 signed-saturating. 23454 23455`usmsubMN4' 23456 Like `umsubMN4', but all involved operations must be 23457 unsigned-saturating. 23458 23459`divmodM4' 23460 Signed division that produces both a quotient and a remainder. 23461 Operand 1 is divided by operand 2 to produce a quotient stored in 23462 operand 0 and a remainder stored in operand 3. 23463 23464 For machines with an instruction that produces both a quotient and 23465 a remainder, provide a pattern for `divmodM4' but do not provide 23466 patterns for `divM3' and `modM3'. This allows optimization in the 23467 relatively common case when both the quotient and remainder are 23468 computed. 23469 23470 If an instruction that just produces a quotient or just a remainder 23471 exists and is more efficient than the instruction that produces 23472 both, write the output routine of `divmodM4' to call 23473 `find_reg_note' and look for a `REG_UNUSED' note on the quotient 23474 or remainder and generate the appropriate instruction. 23475 23476`udivmodM4' 23477 Similar, but does unsigned division. 23478 23479`ashlM3', `ssashlM3', `usashlM3' 23480 Arithmetic-shift operand 1 left by a number of bits specified by 23481 operand 2, and store the result in operand 0. Here M is the mode 23482 of operand 0 and operand 1; operand 2's mode is specified by the 23483 instruction pattern, and the compiler will convert the operand to 23484 that mode before generating the instruction. The meaning of 23485 out-of-range shift counts can optionally be specified by 23486 `TARGET_SHIFT_TRUNCATION_MASK'. *Note 23487 TARGET_SHIFT_TRUNCATION_MASK::. Operand 2 is always a scalar type. 23488 23489`ashrM3', `lshrM3', `rotlM3', `rotrM3' 23490 Other shift and rotate instructions, analogous to the `ashlM3' 23491 instructions. Operand 2 is always a scalar type. 23492 23493`vashlM3', `vashrM3', `vlshrM3', `vrotlM3', `vrotrM3' 23494 Vector shift and rotate instructions that take vectors as operand 2 23495 instead of a scalar type. 23496 23497`bswapM2' 23498 Reverse the order of bytes of operand 1 and store the result in 23499 operand 0. 23500 23501`negM2', `ssnegM2', `usnegM2' 23502 Negate operand 1 and store the result in operand 0. 23503 23504`negvM3' 23505 Like `negM2' but takes a `code_label' as operand 2 and emits code 23506 to jump to it if signed overflow occurs during the negation. 23507 23508`absM2' 23509 Store the absolute value of operand 1 into operand 0. 23510 23511`sqrtM2' 23512 Store the square root of operand 1 into operand 0. 23513 23514 The `sqrt' built-in function of C always uses the mode which 23515 corresponds to the C data type `double' and the `sqrtf' built-in 23516 function uses the mode which corresponds to the C data type 23517 `float'. 23518 23519`fmodM3' 23520 Store the remainder of dividing operand 1 by operand 2 into 23521 operand 0, rounded towards zero to an integer. 23522 23523 The `fmod' built-in function of C always uses the mode which 23524 corresponds to the C data type `double' and the `fmodf' built-in 23525 function uses the mode which corresponds to the C data type 23526 `float'. 23527 23528`remainderM3' 23529 Store the remainder of dividing operand 1 by operand 2 into 23530 operand 0, rounded to the nearest integer. 23531 23532 The `remainder' built-in function of C always uses the mode which 23533 corresponds to the C data type `double' and the `remainderf' 23534 built-in function uses the mode which corresponds to the C data 23535 type `float'. 23536 23537`cosM2' 23538 Store the cosine of operand 1 into operand 0. 23539 23540 The `cos' built-in function of C always uses the mode which 23541 corresponds to the C data type `double' and the `cosf' built-in 23542 function uses the mode which corresponds to the C data type 23543 `float'. 23544 23545`sinM2' 23546 Store the sine of operand 1 into operand 0. 23547 23548 The `sin' built-in function of C always uses the mode which 23549 corresponds to the C data type `double' and the `sinf' built-in 23550 function uses the mode which corresponds to the C data type 23551 `float'. 23552 23553`sincosM3' 23554 Store the cosine of operand 2 into operand 0 and the sine of 23555 operand 2 into operand 1. 23556 23557 The `sin' and `cos' built-in functions of C always use the mode 23558 which corresponds to the C data type `double' and the `sinf' and 23559 `cosf' built-in function use the mode which corresponds to the C 23560 data type `float'. Targets that can calculate the sine and cosine 23561 simultaneously can implement this pattern as opposed to 23562 implementing individual `sinM2' and `cosM2' patterns. The `sin' 23563 and `cos' built-in functions will then be expanded to the 23564 `sincosM3' pattern, with one of the output values left unused. 23565 23566`expM2' 23567 Store the exponential of operand 1 into operand 0. 23568 23569 The `exp' built-in function of C always uses the mode which 23570 corresponds to the C data type `double' and the `expf' built-in 23571 function uses the mode which corresponds to the C data type 23572 `float'. 23573 23574`logM2' 23575 Store the natural logarithm of operand 1 into operand 0. 23576 23577 The `log' built-in function of C always uses the mode which 23578 corresponds to the C data type `double' and the `logf' built-in 23579 function uses the mode which corresponds to the C data type 23580 `float'. 23581 23582`powM3' 23583 Store the value of operand 1 raised to the exponent operand 2 into 23584 operand 0. 23585 23586 The `pow' built-in function of C always uses the mode which 23587 corresponds to the C data type `double' and the `powf' built-in 23588 function uses the mode which corresponds to the C data type 23589 `float'. 23590 23591`atan2M3' 23592 Store the arc tangent (inverse tangent) of operand 1 divided by 23593 operand 2 into operand 0, using the signs of both arguments to 23594 determine the quadrant of the result. 23595 23596 The `atan2' built-in function of C always uses the mode which 23597 corresponds to the C data type `double' and the `atan2f' built-in 23598 function uses the mode which corresponds to the C data type 23599 `float'. 23600 23601`floorM2' 23602 Store the largest integral value not greater than argument. 23603 23604 The `floor' built-in function of C always uses the mode which 23605 corresponds to the C data type `double' and the `floorf' built-in 23606 function uses the mode which corresponds to the C data type 23607 `float'. 23608 23609`btruncM2' 23610 Store the argument rounded to integer towards zero. 23611 23612 The `trunc' built-in function of C always uses the mode which 23613 corresponds to the C data type `double' and the `truncf' built-in 23614 function uses the mode which corresponds to the C data type 23615 `float'. 23616 23617`roundM2' 23618 Store the argument rounded to integer away from zero. 23619 23620 The `round' built-in function of C always uses the mode which 23621 corresponds to the C data type `double' and the `roundf' built-in 23622 function uses the mode which corresponds to the C data type 23623 `float'. 23624 23625`ceilM2' 23626 Store the argument rounded to integer away from zero. 23627 23628 The `ceil' built-in function of C always uses the mode which 23629 corresponds to the C data type `double' and the `ceilf' built-in 23630 function uses the mode which corresponds to the C data type 23631 `float'. 23632 23633`nearbyintM2' 23634 Store the argument rounded according to the default rounding mode 23635 23636 The `nearbyint' built-in function of C always uses the mode which 23637 corresponds to the C data type `double' and the `nearbyintf' 23638 built-in function uses the mode which corresponds to the C data 23639 type `float'. 23640 23641`rintM2' 23642 Store the argument rounded according to the default rounding mode 23643 and raise the inexact exception when the result differs in value 23644 from the argument 23645 23646 The `rint' built-in function of C always uses the mode which 23647 corresponds to the C data type `double' and the `rintf' built-in 23648 function uses the mode which corresponds to the C data type 23649 `float'. 23650 23651`lrintMN2' 23652 Convert operand 1 (valid for floating point mode M) to fixed point 23653 mode N as a signed number according to the current rounding mode 23654 and store in operand 0 (which has mode N). 23655 23656`lroundMN2' 23657 Convert operand 1 (valid for floating point mode M) to fixed point 23658 mode N as a signed number rounding to nearest and away from zero 23659 and store in operand 0 (which has mode N). 23660 23661`lfloorMN2' 23662 Convert operand 1 (valid for floating point mode M) to fixed point 23663 mode N as a signed number rounding down and store in operand 0 23664 (which has mode N). 23665 23666`lceilMN2' 23667 Convert operand 1 (valid for floating point mode M) to fixed point 23668 mode N as a signed number rounding up and store in operand 0 23669 (which has mode N). 23670 23671`copysignM3' 23672 Store a value with the magnitude of operand 1 and the sign of 23673 operand 2 into operand 0. 23674 23675 The `copysign' built-in function of C always uses the mode which 23676 corresponds to the C data type `double' and the `copysignf' 23677 built-in function uses the mode which corresponds to the C data 23678 type `float'. 23679 23680`ffsM2' 23681 Store into operand 0 one plus the index of the least significant 23682 1-bit of operand 1. If operand 1 is zero, store zero. M is the 23683 mode of operand 0; operand 1's mode is specified by the instruction 23684 pattern, and the compiler will convert the operand to that mode 23685 before generating the instruction. 23686 23687 The `ffs' built-in function of C always uses the mode which 23688 corresponds to the C data type `int'. 23689 23690`clrsbM2' 23691 Count leading redundant sign bits. Store into operand 0 the 23692 number of redundant sign bits in operand 1, starting at the most 23693 significant bit position. A redundant sign bit is defined as any 23694 sign bit after the first. As such, this count will be one less 23695 than the count of leading sign bits. 23696 23697`clzM2' 23698 Store into operand 0 the number of leading 0-bits in operand 1, 23699 starting at the most significant bit position. If operand 1 is 0, 23700 the `CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if 23701 the result is undefined or has a useful value. M is the mode of 23702 operand 0; operand 1's mode is specified by the instruction 23703 pattern, and the compiler will convert the operand to that mode 23704 before generating the instruction. 23705 23706`ctzM2' 23707 Store into operand 0 the number of trailing 0-bits in operand 1, 23708 starting at the least significant bit position. If operand 1 is 23709 0, the `CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if 23710 the result is undefined or has a useful value. M is the mode of 23711 operand 0; operand 1's mode is specified by the instruction 23712 pattern, and the compiler will convert the operand to that mode 23713 before generating the instruction. 23714 23715`popcountM2' 23716 Store into operand 0 the number of 1-bits in operand 1. M is the 23717 mode of operand 0; operand 1's mode is specified by the instruction 23718 pattern, and the compiler will convert the operand to that mode 23719 before generating the instruction. 23720 23721`parityM2' 23722 Store into operand 0 the parity of operand 1, i.e. the number of 23723 1-bits in operand 1 modulo 2. M is the mode of operand 0; operand 23724 1's mode is specified by the instruction pattern, and the compiler 23725 will convert the operand to that mode before generating the 23726 instruction. 23727 23728`one_cmplM2' 23729 Store the bitwise-complement of operand 1 into operand 0. 23730 23731`movmemM' 23732 Block move instruction. The destination and source blocks of 23733 memory are the first two operands, and both are `mem:BLK's with an 23734 address in mode `Pmode'. 23735 23736 The number of bytes to move is the third operand, in mode M. 23737 Usually, you specify `Pmode' for M. However, if you can generate 23738 better code knowing the range of valid lengths is smaller than 23739 those representable in a full Pmode pointer, you should provide a 23740 pattern with a mode corresponding to the range of values you can 23741 handle efficiently (e.g., `QImode' for values in the range 0-127; 23742 note we avoid numbers that appear negative) and also a pattern 23743 with `Pmode'. 23744 23745 The fourth operand is the known shared alignment of the source and 23746 destination, in the form of a `const_int' rtx. Thus, if the 23747 compiler knows that both source and destination are word-aligned, 23748 it may provide the value 4 for this operand. 23749 23750 Optional operands 5 and 6 specify expected alignment and size of 23751 block respectively. The expected alignment differs from alignment 23752 in operand 4 in a way that the blocks are not required to be 23753 aligned according to it in all cases. This expected alignment is 23754 also in bytes, just like operand 4. Expected size, when unknown, 23755 is set to `(const_int -1)'. 23756 23757 Descriptions of multiple `movmemM' patterns can only be beneficial 23758 if the patterns for smaller modes have fewer restrictions on their 23759 first, second and fourth operands. Note that the mode M in 23760 `movmemM' does not impose any restriction on the mode of 23761 individually moved data units in the block. 23762 23763 These patterns need not give special consideration to the 23764 possibility that the source and destination strings might overlap. 23765 23766`movstr' 23767 String copy instruction, with `stpcpy' semantics. Operand 0 is an 23768 output operand in mode `Pmode'. The addresses of the destination 23769 and source strings are operands 1 and 2, and both are `mem:BLK's 23770 with addresses in mode `Pmode'. The execution of the expansion of 23771 this pattern should store in operand 0 the address in which the 23772 `NUL' terminator was stored in the destination string. 23773 23774 This patern has also several optional operands that are same as in 23775 `setmem'. 23776 23777`setmemM' 23778 Block set instruction. The destination string is the first 23779 operand, given as a `mem:BLK' whose address is in mode `Pmode'. 23780 The number of bytes to set is the second operand, in mode M. The 23781 value to initialize the memory with is the third operand. Targets 23782 that only support the clearing of memory should reject any value 23783 that is not the constant 0. See `movmemM' for a discussion of the 23784 choice of mode. 23785 23786 The fourth operand is the known alignment of the destination, in 23787 the form of a `const_int' rtx. Thus, if the compiler knows that 23788 the destination is word-aligned, it may provide the value 4 for 23789 this operand. 23790 23791 Optional operands 5 and 6 specify expected alignment and size of 23792 block respectively. The expected alignment differs from alignment 23793 in operand 4 in a way that the blocks are not required to be 23794 aligned according to it in all cases. This expected alignment is 23795 also in bytes, just like operand 4. Expected size, when unknown, 23796 is set to `(const_int -1)'. Operand 7 is the minimal size of the 23797 block and operand 8 is the maximal size of the block (NULL if it 23798 can not be represented as CONST_INT). Operand 9 is the probable 23799 maximal size (i.e. we can not rely on it for correctness, but it 23800 can be used for choosing proper code sequence for a given size). 23801 23802 The use for multiple `setmemM' is as for `movmemM'. 23803 23804`cmpstrnM' 23805 String compare instruction, with five operands. Operand 0 is the 23806 output; it has mode M. The remaining four operands are like the 23807 operands of `movmemM'. The two memory blocks specified are 23808 compared byte by byte in lexicographic order starting at the 23809 beginning of each string. The instruction is not allowed to 23810 prefetch more than one byte at a time since either string may end 23811 in the first byte and reading past that may access an invalid page 23812 or segment and cause a fault. The comparison terminates early if 23813 the fetched bytes are different or if they are equal to zero. The 23814 effect of the instruction is to store a value in operand 0 whose 23815 sign indicates the result of the comparison. 23816 23817`cmpstrM' 23818 String compare instruction, without known maximum length. Operand 23819 0 is the output; it has mode M. The second and third operand are 23820 the blocks of memory to be compared; both are `mem:BLK' with an 23821 address in mode `Pmode'. 23822 23823 The fourth operand is the known shared alignment of the source and 23824 destination, in the form of a `const_int' rtx. Thus, if the 23825 compiler knows that both source and destination are word-aligned, 23826 it may provide the value 4 for this operand. 23827 23828 The two memory blocks specified are compared byte by byte in 23829 lexicographic order starting at the beginning of each string. The 23830 instruction is not allowed to prefetch more than one byte at a 23831 time since either string may end in the first byte and reading 23832 past that may access an invalid page or segment and cause a fault. 23833 The comparison will terminate when the fetched bytes are different 23834 or if they are equal to zero. The effect of the instruction is to 23835 store a value in operand 0 whose sign indicates the result of the 23836 comparison. 23837 23838`cmpmemM' 23839 Block compare instruction, with five operands like the operands of 23840 `cmpstrM'. The two memory blocks specified are compared byte by 23841 byte in lexicographic order starting at the beginning of each 23842 block. Unlike `cmpstrM' the instruction can prefetch any bytes in 23843 the two memory blocks. Also unlike `cmpstrM' the comparison will 23844 not stop if both bytes are zero. The effect of the instruction is 23845 to store a value in operand 0 whose sign indicates the result of 23846 the comparison. 23847 23848`strlenM' 23849 Compute the length of a string, with three operands. Operand 0 is 23850 the result (of mode M), operand 1 is a `mem' referring to the 23851 first character of the string, operand 2 is the character to 23852 search for (normally zero), and operand 3 is a constant describing 23853 the known alignment of the beginning of the string. 23854 23855`floatMN2' 23856 Convert signed integer operand 1 (valid for fixed point mode M) to 23857 floating point mode N and store in operand 0 (which has mode N). 23858 23859`floatunsMN2' 23860 Convert unsigned integer operand 1 (valid for fixed point mode M) 23861 to floating point mode N and store in operand 0 (which has mode N). 23862 23863`fixMN2' 23864 Convert operand 1 (valid for floating point mode M) to fixed point 23865 mode N as a signed number and store in operand 0 (which has mode 23866 N). This instruction's result is defined only when the value of 23867 operand 1 is an integer. 23868 23869 If the machine description defines this pattern, it also needs to 23870 define the `ftrunc' pattern. 23871 23872`fixunsMN2' 23873 Convert operand 1 (valid for floating point mode M) to fixed point 23874 mode N as an unsigned number and store in operand 0 (which has 23875 mode N). This instruction's result is defined only when the value 23876 of operand 1 is an integer. 23877 23878`ftruncM2' 23879 Convert operand 1 (valid for floating point mode M) to an integer 23880 value, still represented in floating point mode M, and store it in 23881 operand 0 (valid for floating point mode M). 23882 23883`fix_truncMN2' 23884 Like `fixMN2' but works for any floating point value of mode M by 23885 converting the value to an integer. 23886 23887`fixuns_truncMN2' 23888 Like `fixunsMN2' but works for any floating point value of mode M 23889 by converting the value to an integer. 23890 23891`truncMN2' 23892 Truncate operand 1 (valid for mode M) to mode N and store in 23893 operand 0 (which has mode N). Both modes must be fixed point or 23894 both floating point. 23895 23896`extendMN2' 23897 Sign-extend operand 1 (valid for mode M) to mode N and store in 23898 operand 0 (which has mode N). Both modes must be fixed point or 23899 both floating point. 23900 23901`zero_extendMN2' 23902 Zero-extend operand 1 (valid for mode M) to mode N and store in 23903 operand 0 (which has mode N). Both modes must be fixed point. 23904 23905`fractMN2' 23906 Convert operand 1 of mode M to mode N and store in operand 0 23907 (which has mode N). Mode M and mode N could be fixed-point to 23908 fixed-point, signed integer to fixed-point, fixed-point to signed 23909 integer, floating-point to fixed-point, or fixed-point to 23910 floating-point. When overflows or underflows happen, the results 23911 are undefined. 23912 23913`satfractMN2' 23914 Convert operand 1 of mode M to mode N and store in operand 0 23915 (which has mode N). Mode M and mode N could be fixed-point to 23916 fixed-point, signed integer to fixed-point, or floating-point to 23917 fixed-point. When overflows or underflows happen, the instruction 23918 saturates the results to the maximum or the minimum. 23919 23920`fractunsMN2' 23921 Convert operand 1 of mode M to mode N and store in operand 0 23922 (which has mode N). Mode M and mode N could be unsigned integer 23923 to fixed-point, or fixed-point to unsigned integer. When 23924 overflows or underflows happen, the results are undefined. 23925 23926`satfractunsMN2' 23927 Convert unsigned integer operand 1 of mode M to fixed-point mode N 23928 and store in operand 0 (which has mode N). When overflows or 23929 underflows happen, the instruction saturates the results to the 23930 maximum or the minimum. 23931 23932`extvM' 23933 Extract a bit-field from register operand 1, sign-extend it, and 23934 store it in operand 0. Operand 2 specifies the width of the field 23935 in bits and operand 3 the starting bit, which counts from the most 23936 significant bit if `BITS_BIG_ENDIAN' is true and from the least 23937 significant bit otherwise. 23938 23939 Operands 0 and 1 both have mode M. Operands 2 and 3 have a 23940 target-specific mode. 23941 23942`extvmisalignM' 23943 Extract a bit-field from memory operand 1, sign extend it, and 23944 store it in operand 0. Operand 2 specifies the width in bits and 23945 operand 3 the starting bit. The starting bit is always somewhere 23946 in the first byte of operand 1; it counts from the most 23947 significant bit if `BITS_BIG_ENDIAN' is true and from the least 23948 significant bit otherwise. 23949 23950 Operand 0 has mode M while operand 1 has `BLK' mode. Operands 2 23951 and 3 have a target-specific mode. 23952 23953 The instruction must not read beyond the last byte of the 23954 bit-field. 23955 23956`extzvM' 23957 Like `extvM' except that the bit-field value is zero-extended. 23958 23959`extzvmisalignM' 23960 Like `extvmisalignM' except that the bit-field value is 23961 zero-extended. 23962 23963`insvM' 23964 Insert operand 3 into a bit-field of register operand 0. Operand 1 23965 specifies the width of the field in bits and operand 2 the 23966 starting bit, which counts from the most significant bit if 23967 `BITS_BIG_ENDIAN' is true and from the least significant bit 23968 otherwise. 23969 23970 Operands 0 and 3 both have mode M. Operands 1 and 2 have a 23971 target-specific mode. 23972 23973`insvmisalignM' 23974 Insert operand 3 into a bit-field of memory operand 0. Operand 1 23975 specifies the width of the field in bits and operand 2 the 23976 starting bit. The starting bit is always somewhere in the first 23977 byte of operand 0; it counts from the most significant bit if 23978 `BITS_BIG_ENDIAN' is true and from the least significant bit 23979 otherwise. 23980 23981 Operand 3 has mode M while operand 0 has `BLK' mode. Operands 1 23982 and 2 have a target-specific mode. 23983 23984 The instruction must not read or write beyond the last byte of the 23985 bit-field. 23986 23987`extv' 23988 Extract a bit-field from operand 1 (a register or memory operand), 23989 where operand 2 specifies the width in bits and operand 3 the 23990 starting bit, and store it in operand 0. Operand 0 must have mode 23991 `word_mode'. Operand 1 may have mode `byte_mode' or `word_mode'; 23992 often `word_mode' is allowed only for registers. Operands 2 and 3 23993 must be valid for `word_mode'. 23994 23995 The RTL generation pass generates this instruction only with 23996 constants for operands 2 and 3 and the constant is never zero for 23997 operand 2. 23998 23999 The bit-field value is sign-extended to a full word integer before 24000 it is stored in operand 0. 24001 24002 This pattern is deprecated; please use `extvM' and `extvmisalignM' 24003 instead. 24004 24005`extzv' 24006 Like `extv' except that the bit-field value is zero-extended. 24007 24008 This pattern is deprecated; please use `extzvM' and 24009 `extzvmisalignM' instead. 24010 24011`insv' 24012 Store operand 3 (which must be valid for `word_mode') into a 24013 bit-field in operand 0, where operand 1 specifies the width in 24014 bits and operand 2 the starting bit. Operand 0 may have mode 24015 `byte_mode' or `word_mode'; often `word_mode' is allowed only for 24016 registers. Operands 1 and 2 must be valid for `word_mode'. 24017 24018 The RTL generation pass generates this instruction only with 24019 constants for operands 1 and 2 and the constant is never zero for 24020 operand 1. 24021 24022 This pattern is deprecated; please use `insvM' and `insvmisalignM' 24023 instead. 24024 24025`movMODEcc' 24026 Conditionally move operand 2 or operand 3 into operand 0 according 24027 to the comparison in operand 1. If the comparison is true, 24028 operand 2 is moved into operand 0, otherwise operand 3 is moved. 24029 24030 The mode of the operands being compared need not be the same as 24031 the operands being moved. Some machines, sparc64 for example, 24032 have instructions that conditionally move an integer value based 24033 on the floating point condition codes and vice versa. 24034 24035 If the machine does not have conditional move instructions, do not 24036 define these patterns. 24037 24038`addMODEcc' 24039 Similar to `movMODEcc' but for conditional addition. Conditionally 24040 move operand 2 or (operands 2 + operand 3) into operand 0 24041 according to the comparison in operand 1. If the comparison is 24042 false, operand 2 is moved into operand 0, otherwise (operand 2 + 24043 operand 3) is moved. 24044 24045`cstoreMODE4' 24046 Store zero or nonzero in operand 0 according to whether a 24047 comparison is true. Operand 1 is a comparison operator. Operand 24048 2 and operand 3 are the first and second operand of the 24049 comparison, respectively. You specify the mode that operand 0 24050 must have when you write the `match_operand' expression. The 24051 compiler automatically sees which mode you have used and supplies 24052 an operand of that mode. 24053 24054 The value stored for a true condition must have 1 as its low bit, 24055 or else must be negative. Otherwise the instruction is not 24056 suitable and you should omit it from the machine description. You 24057 describe to the compiler exactly which value is stored by defining 24058 the macro `STORE_FLAG_VALUE' (*note Misc::). If a description 24059 cannot be found that can be used for all the possible comparison 24060 operators, you should pick one and use a `define_expand' to map 24061 all results onto the one you chose. 24062 24063 These operations may `FAIL', but should do so only in relatively 24064 uncommon cases; if they would `FAIL' for common cases involving 24065 integer comparisons, it is best to restrict the predicates to not 24066 allow these operands. Likewise if a given comparison operator will 24067 always fail, independent of the operands (for floating-point 24068 modes, the `ordered_comparison_operator' predicate is often useful 24069 in this case). 24070 24071 If this pattern is omitted, the compiler will generate a 24072 conditional branch--for example, it may copy a constant one to the 24073 target and branching around an assignment of zero to the 24074 target--or a libcall. If the predicate for operand 1 only rejects 24075 some operators, it will also try reordering the operands and/or 24076 inverting the result value (e.g. by an exclusive OR). These 24077 possibilities could be cheaper or equivalent to the instructions 24078 used for the `cstoreMODE4' pattern followed by those required to 24079 convert a positive result from `STORE_FLAG_VALUE' to 1; in this 24080 case, you can and should make operand 1's predicate reject some 24081 operators in the `cstoreMODE4' pattern, or remove the pattern 24082 altogether from the machine description. 24083 24084`cbranchMODE4' 24085 Conditional branch instruction combined with a compare instruction. 24086 Operand 0 is a comparison operator. Operand 1 and operand 2 are 24087 the first and second operands of the comparison, respectively. 24088 Operand 3 is the `code_label' to jump to. 24089 24090`jump' 24091 A jump inside a function; an unconditional branch. Operand 0 is 24092 the `code_label' to jump to. This pattern name is mandatory on all 24093 machines. 24094 24095`call' 24096 Subroutine call instruction returning no value. Operand 0 is the 24097 function to call; operand 1 is the number of bytes of arguments 24098 pushed as a `const_int'; operand 2 is the number of registers used 24099 as operands. 24100 24101 On most machines, operand 2 is not actually stored into the RTL 24102 pattern. It is supplied for the sake of some RISC machines which 24103 need to put this information into the assembler code; they can put 24104 it in the RTL instead of operand 1. 24105 24106 Operand 0 should be a `mem' RTX whose address is the address of the 24107 function. Note, however, that this address can be a `symbol_ref' 24108 expression even if it would not be a legitimate memory address on 24109 the target machine. If it is also not a valid argument for a call 24110 instruction, the pattern for this operation should be a 24111 `define_expand' (*note Expander Definitions::) that places the 24112 address into a register and uses that register in the call 24113 instruction. 24114 24115`call_value' 24116 Subroutine call instruction returning a value. Operand 0 is the 24117 hard register in which the value is returned. There are three more 24118 operands, the same as the three operands of the `call' instruction 24119 (but with numbers increased by one). 24120 24121 Subroutines that return `BLKmode' objects use the `call' insn. 24122 24123`call_pop', `call_value_pop' 24124 Similar to `call' and `call_value', except used if defined and if 24125 `RETURN_POPS_ARGS' is nonzero. They should emit a `parallel' that 24126 contains both the function call and a `set' to indicate the 24127 adjustment made to the frame pointer. 24128 24129 For machines where `RETURN_POPS_ARGS' can be nonzero, the use of 24130 these patterns increases the number of functions for which the 24131 frame pointer can be eliminated, if desired. 24132 24133`untyped_call' 24134 Subroutine call instruction returning a value of any type. 24135 Operand 0 is the function to call; operand 1 is a memory location 24136 where the result of calling the function is to be stored; operand 24137 2 is a `parallel' expression where each element is a `set' 24138 expression that indicates the saving of a function return value 24139 into the result block. 24140 24141 This instruction pattern should be defined to support 24142 `__builtin_apply' on machines where special instructions are needed 24143 to call a subroutine with arbitrary arguments or to save the value 24144 returned. This instruction pattern is required on machines that 24145 have multiple registers that can hold a return value (i.e. 24146 `FUNCTION_VALUE_REGNO_P' is true for more than one register). 24147 24148`return' 24149 Subroutine return instruction. This instruction pattern name 24150 should be defined only if a single instruction can do all the work 24151 of returning from a function. 24152 24153 Like the `movM' patterns, this pattern is also used after the RTL 24154 generation phase. In this case it is to support machines where 24155 multiple instructions are usually needed to return from a 24156 function, but some class of functions only requires one 24157 instruction to implement a return. Normally, the applicable 24158 functions are those which do not need to save any registers or 24159 allocate stack space. 24160 24161 It is valid for this pattern to expand to an instruction using 24162 `simple_return' if no epilogue is required. 24163 24164`simple_return' 24165 Subroutine return instruction. This instruction pattern name 24166 should be defined only if a single instruction can do all the work 24167 of returning from a function on a path where no epilogue is 24168 required. This pattern is very similar to the `return' 24169 instruction pattern, but it is emitted only by the shrink-wrapping 24170 optimization on paths where the function prologue has not been 24171 executed, and a function return should occur without any of the 24172 effects of the epilogue. Additional uses may be introduced on 24173 paths where both the prologue and the epilogue have executed. 24174 24175 For such machines, the condition specified in this pattern should 24176 only be true when `reload_completed' is nonzero and the function's 24177 epilogue would only be a single instruction. For machines with 24178 register windows, the routine `leaf_function_p' may be used to 24179 determine if a register window push is required. 24180 24181 Machines that have conditional return instructions should define 24182 patterns such as 24183 24184 (define_insn "" 24185 [(set (pc) 24186 (if_then_else (match_operator 24187 0 "comparison_operator" 24188 [(cc0) (const_int 0)]) 24189 (return) 24190 (pc)))] 24191 "CONDITION" 24192 "...") 24193 24194 where CONDITION would normally be the same condition specified on 24195 the named `return' pattern. 24196 24197`untyped_return' 24198 Untyped subroutine return instruction. This instruction pattern 24199 should be defined to support `__builtin_return' on machines where 24200 special instructions are needed to return a value of any type. 24201 24202 Operand 0 is a memory location where the result of calling a 24203 function with `__builtin_apply' is stored; operand 1 is a 24204 `parallel' expression where each element is a `set' expression 24205 that indicates the restoring of a function return value from the 24206 result block. 24207 24208`nop' 24209 No-op instruction. This instruction pattern name should always be 24210 defined to output a no-op in assembler code. `(const_int 0)' will 24211 do as an RTL pattern. 24212 24213`indirect_jump' 24214 An instruction to jump to an address which is operand zero. This 24215 pattern name is mandatory on all machines. 24216 24217`casesi' 24218 Instruction to jump through a dispatch table, including bounds 24219 checking. This instruction takes five operands: 24220 24221 1. The index to dispatch on, which has mode `SImode'. 24222 24223 2. The lower bound for indices in the table, an integer constant. 24224 24225 3. The total range of indices in the table--the largest index 24226 minus the smallest one (both inclusive). 24227 24228 4. A label that precedes the table itself. 24229 24230 5. A label to jump to if the index has a value outside the 24231 bounds. 24232 24233 The table is an `addr_vec' or `addr_diff_vec' inside of a 24234 `jump_table_data'. The number of elements in the table is one 24235 plus the difference between the upper bound and the lower bound. 24236 24237`tablejump' 24238 Instruction to jump to a variable address. This is a low-level 24239 capability which can be used to implement a dispatch table when 24240 there is no `casesi' pattern. 24241 24242 This pattern requires two operands: the address or offset, and a 24243 label which should immediately precede the jump table. If the 24244 macro `CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then 24245 the first operand is an offset which counts from the address of 24246 the table; otherwise, it is an absolute address to jump to. In 24247 either case, the first operand has mode `Pmode'. 24248 24249 The `tablejump' insn is always the last insn before the jump table 24250 it uses. Its assembler code normally has no need to use the 24251 second operand, but you should incorporate it in the RTL pattern so 24252 that the jump optimizer will not delete the table as unreachable 24253 code. 24254 24255`decrement_and_branch_until_zero' 24256 Conditional branch instruction that decrements a register and 24257 jumps if the register is nonzero. Operand 0 is the register to 24258 decrement and test; operand 1 is the label to jump to if the 24259 register is nonzero. *Note Looping Patterns::. 24260 24261 This optional instruction pattern is only used by the combiner, 24262 typically for loops reversed by the loop optimizer when strength 24263 reduction is enabled. 24264 24265`doloop_end' 24266 Conditional branch instruction that decrements a register and 24267 jumps if the register is nonzero. Operand 0 is the register to 24268 decrement and test; operand 1 is the label to jump to if the 24269 register is nonzero. *Note Looping Patterns::. 24270 24271 This optional instruction pattern should be defined for machines 24272 with low-overhead looping instructions as the loop optimizer will 24273 try to modify suitable loops to utilize it. The target hook 24274 `TARGET_CAN_USE_DOLOOP_P' controls the conditions under which 24275 low-overhead loops can be used. 24276 24277`doloop_begin' 24278 Companion instruction to `doloop_end' required for machines that 24279 need to perform some initialization, such as loading a special 24280 counter register. Operand 1 is the associated `doloop_end' 24281 pattern and operand 0 is the register that it decrements. 24282 24283 If initialization insns do not always need to be emitted, use a 24284 `define_expand' (*note Expander Definitions::) and make it fail. 24285 24286`canonicalize_funcptr_for_compare' 24287 Canonicalize the function pointer in operand 1 and store the result 24288 into operand 0. 24289 24290 Operand 0 is always a `reg' and has mode `Pmode'; operand 1 may be 24291 a `reg', `mem', `symbol_ref', `const_int', etc and also has mode 24292 `Pmode'. 24293 24294 Canonicalization of a function pointer usually involves computing 24295 the address of the function which would be called if the function 24296 pointer were used in an indirect call. 24297 24298 Only define this pattern if function pointers on the target machine 24299 can have different values but still call the same function when 24300 used in an indirect call. 24301 24302`save_stack_block' 24303`save_stack_function' 24304`save_stack_nonlocal' 24305`restore_stack_block' 24306`restore_stack_function' 24307`restore_stack_nonlocal' 24308 Most machines save and restore the stack pointer by copying it to 24309 or from an object of mode `Pmode'. Do not define these patterns on 24310 such machines. 24311 24312 Some machines require special handling for stack pointer saves and 24313 restores. On those machines, define the patterns corresponding to 24314 the non-standard cases by using a `define_expand' (*note Expander 24315 Definitions::) that produces the required insns. The three types 24316 of saves and restores are: 24317 24318 1. `save_stack_block' saves the stack pointer at the start of a 24319 block that allocates a variable-sized object, and 24320 `restore_stack_block' restores the stack pointer when the 24321 block is exited. 24322 24323 2. `save_stack_function' and `restore_stack_function' do a 24324 similar job for the outermost block of a function and are 24325 used when the function allocates variable-sized objects or 24326 calls `alloca'. Only the epilogue uses the restored stack 24327 pointer, allowing a simpler save or restore sequence on some 24328 machines. 24329 24330 3. `save_stack_nonlocal' is used in functions that contain labels 24331 branched to by nested functions. It saves the stack pointer 24332 in such a way that the inner function can use 24333 `restore_stack_nonlocal' to restore the stack pointer. The 24334 compiler generates code to restore the frame and argument 24335 pointer registers, but some machines require saving and 24336 restoring additional data such as register window information 24337 or stack backchains. Place insns in these patterns to save 24338 and restore any such required data. 24339 24340 When saving the stack pointer, operand 0 is the save area and 24341 operand 1 is the stack pointer. The mode used to allocate the 24342 save area defaults to `Pmode' but you can override that choice by 24343 defining the `STACK_SAVEAREA_MODE' macro (*note Storage Layout::). 24344 You must specify an integral mode, or `VOIDmode' if no save area 24345 is needed for a particular type of save (either because no save is 24346 needed or because a machine-specific save area can be used). 24347 Operand 0 is the stack pointer and operand 1 is the save area for 24348 restore operations. If `save_stack_block' is defined, operand 0 24349 must not be `VOIDmode' since these saves can be arbitrarily nested. 24350 24351 A save area is a `mem' that is at a constant offset from 24352 `virtual_stack_vars_rtx' when the stack pointer is saved for use by 24353 nonlocal gotos and a `reg' in the other two cases. 24354 24355`allocate_stack' 24356 Subtract (or add if `STACK_GROWS_DOWNWARD' is undefined) operand 1 24357 from the stack pointer to create space for dynamically allocated 24358 data. 24359 24360 Store the resultant pointer to this space into operand 0. If you 24361 are allocating space from the main stack, do this by emitting a 24362 move insn to copy `virtual_stack_dynamic_rtx' to operand 0. If 24363 you are allocating the space elsewhere, generate code to copy the 24364 location of the space to operand 0. In the latter case, you must 24365 ensure this space gets freed when the corresponding space on the 24366 main stack is free. 24367 24368 Do not define this pattern if all that must be done is the 24369 subtraction. Some machines require other operations such as stack 24370 probes or maintaining the back chain. Define this pattern to emit 24371 those operations in addition to updating the stack pointer. 24372 24373`check_stack' 24374 If stack checking (*note Stack Checking::) cannot be done on your 24375 system by probing the stack, define this pattern to perform the 24376 needed check and signal an error if the stack has overflowed. The 24377 single operand is the address in the stack farthest from the 24378 current stack pointer that you need to validate. Normally, on 24379 platforms where this pattern is needed, you would obtain the stack 24380 limit from a global or thread-specific variable or register. 24381 24382`probe_stack_address' 24383 If stack checking (*note Stack Checking::) can be done on your 24384 system by probing the stack but without the need to actually 24385 access it, define this pattern and signal an error if the stack 24386 has overflowed. The single operand is the memory address in the 24387 stack that needs to be probed. 24388 24389`probe_stack' 24390 If stack checking (*note Stack Checking::) can be done on your 24391 system by probing the stack but doing it with a "store zero" 24392 instruction is not valid or optimal, define this pattern to do the 24393 probing differently and signal an error if the stack has 24394 overflowed. The single operand is the memory reference in the 24395 stack that needs to be probed. 24396 24397`nonlocal_goto' 24398 Emit code to generate a non-local goto, e.g., a jump from one 24399 function to a label in an outer function. This pattern has four 24400 arguments, each representing a value to be used in the jump. The 24401 first argument is to be loaded into the frame pointer, the second 24402 is the address to branch to (code to dispatch to the actual label), 24403 the third is the address of a location where the stack is saved, 24404 and the last is the address of the label, to be placed in the 24405 location for the incoming static chain. 24406 24407 On most machines you need not define this pattern, since GCC will 24408 already generate the correct code, which is to load the frame 24409 pointer and static chain, restore the stack (using the 24410 `restore_stack_nonlocal' pattern, if defined), and jump indirectly 24411 to the dispatcher. You need only define this pattern if this code 24412 will not work on your machine. 24413 24414`nonlocal_goto_receiver' 24415 This pattern, if defined, contains code needed at the target of a 24416 nonlocal goto after the code already generated by GCC. You will 24417 not normally need to define this pattern. A typical reason why 24418 you might need this pattern is if some value, such as a pointer to 24419 a global table, must be restored when the frame pointer is 24420 restored. Note that a nonlocal goto only occurs within a 24421 unit-of-translation, so a global table pointer that is shared by 24422 all functions of a given module need not be restored. There are 24423 no arguments. 24424 24425`exception_receiver' 24426 This pattern, if defined, contains code needed at the site of an 24427 exception handler that isn't needed at the site of a nonlocal 24428 goto. You will not normally need to define this pattern. A 24429 typical reason why you might need this pattern is if some value, 24430 such as a pointer to a global table, must be restored after 24431 control flow is branched to the handler of an exception. There 24432 are no arguments. 24433 24434`builtin_setjmp_setup' 24435 This pattern, if defined, contains additional code needed to 24436 initialize the `jmp_buf'. You will not normally need to define 24437 this pattern. A typical reason why you might need this pattern is 24438 if some value, such as a pointer to a global table, must be 24439 restored. Though it is preferred that the pointer value be 24440 recalculated if possible (given the address of a label for 24441 instance). The single argument is a pointer to the `jmp_buf'. 24442 Note that the buffer is five words long and that the first three 24443 are normally used by the generic mechanism. 24444 24445`builtin_setjmp_receiver' 24446 This pattern, if defined, contains code needed at the site of a 24447 built-in setjmp that isn't needed at the site of a nonlocal goto. 24448 You will not normally need to define this pattern. A typical 24449 reason why you might need this pattern is if some value, such as a 24450 pointer to a global table, must be restored. It takes one 24451 argument, which is the label to which builtin_longjmp transferred 24452 control; this pattern may be emitted at a small offset from that 24453 label. 24454 24455`builtin_longjmp' 24456 This pattern, if defined, performs the entire action of the 24457 longjmp. You will not normally need to define this pattern unless 24458 you also define `builtin_setjmp_setup'. The single argument is a 24459 pointer to the `jmp_buf'. 24460 24461`eh_return' 24462 This pattern, if defined, affects the way `__builtin_eh_return', 24463 and thence the call frame exception handling library routines, are 24464 built. It is intended to handle non-trivial actions needed along 24465 the abnormal return path. 24466 24467 The address of the exception handler to which the function should 24468 return is passed as operand to this pattern. It will normally 24469 need to copied by the pattern to some special register or memory 24470 location. If the pattern needs to determine the location of the 24471 target call frame in order to do so, it may use 24472 `EH_RETURN_STACKADJ_RTX', if defined; it will have already been 24473 assigned. 24474 24475 If this pattern is not defined, the default action will be to 24476 simply copy the return address to `EH_RETURN_HANDLER_RTX'. Either 24477 that macro or this pattern needs to be defined if call frame 24478 exception handling is to be used. 24479 24480`prologue' 24481 This pattern, if defined, emits RTL for entry to a function. The 24482 function entry is responsible for setting up the stack frame, 24483 initializing the frame pointer register, saving callee saved 24484 registers, etc. 24485 24486 Using a prologue pattern is generally preferred over defining 24487 `TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the 24488 prologue. 24489 24490 The `prologue' pattern is particularly useful for targets which 24491 perform instruction scheduling. 24492 24493`window_save' 24494 This pattern, if defined, emits RTL for a register window save. 24495 It should be defined if the target machine has register windows 24496 but the window events are decoupled from calls to subroutines. 24497 The canonical example is the SPARC architecture. 24498 24499`epilogue' 24500 This pattern emits RTL for exit from a function. The function 24501 exit is responsible for deallocating the stack frame, restoring 24502 callee saved registers and emitting the return instruction. 24503 24504 Using an epilogue pattern is generally preferred over defining 24505 `TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the 24506 epilogue. 24507 24508 The `epilogue' pattern is particularly useful for targets which 24509 perform instruction scheduling or which have delay slots for their 24510 return instruction. 24511 24512`sibcall_epilogue' 24513 This pattern, if defined, emits RTL for exit from a function 24514 without the final branch back to the calling function. This 24515 pattern will be emitted before any sibling call (aka tail call) 24516 sites. 24517 24518 The `sibcall_epilogue' pattern must not clobber any arguments used 24519 for parameter passing or any stack slots for arguments passed to 24520 the current function. 24521 24522`trap' 24523 This pattern, if defined, signals an error, typically by causing 24524 some kind of signal to be raised. Among other places, it is used 24525 by the Java front end to signal `invalid array index' exceptions. 24526 24527`ctrapMM4' 24528 Conditional trap instruction. Operand 0 is a piece of RTL which 24529 performs a comparison, and operands 1 and 2 are the arms of the 24530 comparison. Operand 3 is the trap code, an integer. 24531 24532 A typical `ctrap' pattern looks like 24533 24534 (define_insn "ctrapsi4" 24535 [(trap_if (match_operator 0 "trap_operator" 24536 [(match_operand 1 "register_operand") 24537 (match_operand 2 "immediate_operand")]) 24538 (match_operand 3 "const_int_operand" "i"))] 24539 "" 24540 "...") 24541 24542`prefetch' 24543 This pattern, if defined, emits code for a non-faulting data 24544 prefetch instruction. Operand 0 is the address of the memory to 24545 prefetch. Operand 1 is a constant 1 if the prefetch is preparing 24546 for a write to the memory address, or a constant 0 otherwise. 24547 Operand 2 is the expected degree of temporal locality of the data 24548 and is a value between 0 and 3, inclusive; 0 means that the data 24549 has no temporal locality, so it need not be left in the cache 24550 after the access; 3 means that the data has a high degree of 24551 temporal locality and should be left in all levels of cache 24552 possible; 1 and 2 mean, respectively, a low or moderate degree of 24553 temporal locality. 24554 24555 Targets that do not support write prefetches or locality hints can 24556 ignore the values of operands 1 and 2. 24557 24558`blockage' 24559 This pattern defines a pseudo insn that prevents the instruction 24560 scheduler and other passes from moving instructions and using 24561 register equivalences across the boundary defined by the blockage 24562 insn. This needs to be an UNSPEC_VOLATILE pattern or a volatile 24563 ASM. 24564 24565`memory_barrier' 24566 If the target memory model is not fully synchronous, then this 24567 pattern should be defined to an instruction that orders both loads 24568 and stores before the instruction with respect to loads and stores 24569 after the instruction. This pattern has no operands. 24570 24571`sync_compare_and_swapMODE' 24572 This pattern, if defined, emits code for an atomic compare-and-swap 24573 operation. Operand 1 is the memory on which the atomic operation 24574 is performed. Operand 2 is the "old" value to be compared against 24575 the current contents of the memory location. Operand 3 is the 24576 "new" value to store in the memory if the compare succeeds. 24577 Operand 0 is the result of the operation; it should contain the 24578 contents of the memory before the operation. If the compare 24579 succeeds, this should obviously be a copy of operand 2. 24580 24581 This pattern must show that both operand 0 and operand 1 are 24582 modified. 24583 24584 This pattern must issue any memory barrier instructions such that 24585 all memory operations before the atomic operation occur before the 24586 atomic operation and all memory operations after the atomic 24587 operation occur after the atomic operation. 24588 24589 For targets where the success or failure of the compare-and-swap 24590 operation is available via the status flags, it is possible to 24591 avoid a separate compare operation and issue the subsequent branch 24592 or store-flag operation immediately after the compare-and-swap. 24593 To this end, GCC will look for a `MODE_CC' set in the output of 24594 `sync_compare_and_swapMODE'; if the machine description includes 24595 such a set, the target should also define special `cbranchcc4' 24596 and/or `cstorecc4' instructions. GCC will then be able to take 24597 the destination of the `MODE_CC' set and pass it to the 24598 `cbranchcc4' or `cstorecc4' pattern as the first operand of the 24599 comparison (the second will be `(const_int 0)'). 24600 24601 For targets where the operating system may provide support for this 24602 operation via library calls, the `sync_compare_and_swap_optab' may 24603 be initialized to a function with the same interface as the 24604 `__sync_val_compare_and_swap_N' built-in. If the entire set of 24605 __SYNC builtins are supported via library calls, the target can 24606 initialize all of the optabs at once with `init_sync_libfuncs'. 24607 For the purposes of C++11 `std::atomic::is_lock_free', it is 24608 assumed that these library calls do _not_ use any kind of 24609 interruptable locking. 24610 24611`sync_addMODE', `sync_subMODE' 24612`sync_iorMODE', `sync_andMODE' 24613`sync_xorMODE', `sync_nandMODE' 24614 These patterns emit code for an atomic operation on memory. 24615 Operand 0 is the memory on which the atomic operation is performed. 24616 Operand 1 is the second operand to the binary operator. 24617 24618 This pattern must issue any memory barrier instructions such that 24619 all memory operations before the atomic operation occur before the 24620 atomic operation and all memory operations after the atomic 24621 operation occur after the atomic operation. 24622 24623 If these patterns are not defined, the operation will be 24624 constructed from a compare-and-swap operation, if defined. 24625 24626`sync_old_addMODE', `sync_old_subMODE' 24627`sync_old_iorMODE', `sync_old_andMODE' 24628`sync_old_xorMODE', `sync_old_nandMODE' 24629 These patterns emit code for an atomic operation on memory, and 24630 return the value that the memory contained before the operation. 24631 Operand 0 is the result value, operand 1 is the memory on which the 24632 atomic operation is performed, and operand 2 is the second operand 24633 to the binary operator. 24634 24635 This pattern must issue any memory barrier instructions such that 24636 all memory operations before the atomic operation occur before the 24637 atomic operation and all memory operations after the atomic 24638 operation occur after the atomic operation. 24639 24640 If these patterns are not defined, the operation will be 24641 constructed from a compare-and-swap operation, if defined. 24642 24643`sync_new_addMODE', `sync_new_subMODE' 24644`sync_new_iorMODE', `sync_new_andMODE' 24645`sync_new_xorMODE', `sync_new_nandMODE' 24646 These patterns are like their `sync_old_OP' counterparts, except 24647 that they return the value that exists in the memory location 24648 after the operation, rather than before the operation. 24649 24650`sync_lock_test_and_setMODE' 24651 This pattern takes two forms, based on the capabilities of the 24652 target. In either case, operand 0 is the result of the operand, 24653 operand 1 is the memory on which the atomic operation is 24654 performed, and operand 2 is the value to set in the lock. 24655 24656 In the ideal case, this operation is an atomic exchange operation, 24657 in which the previous value in memory operand is copied into the 24658 result operand, and the value operand is stored in the memory 24659 operand. 24660 24661 For less capable targets, any value operand that is not the 24662 constant 1 should be rejected with `FAIL'. In this case the 24663 target may use an atomic test-and-set bit operation. The result 24664 operand should contain 1 if the bit was previously set and 0 if 24665 the bit was previously clear. The true contents of the memory 24666 operand are implementation defined. 24667 24668 This pattern must issue any memory barrier instructions such that 24669 the pattern as a whole acts as an acquire barrier, that is all 24670 memory operations after the pattern do not occur until the lock is 24671 acquired. 24672 24673 If this pattern is not defined, the operation will be constructed 24674 from a compare-and-swap operation, if defined. 24675 24676`sync_lock_releaseMODE' 24677 This pattern, if defined, releases a lock set by 24678 `sync_lock_test_and_setMODE'. Operand 0 is the memory that 24679 contains the lock; operand 1 is the value to store in the lock. 24680 24681 If the target doesn't implement full semantics for 24682 `sync_lock_test_and_setMODE', any value operand which is not the 24683 constant 0 should be rejected with `FAIL', and the true contents 24684 of the memory operand are implementation defined. 24685 24686 This pattern must issue any memory barrier instructions such that 24687 the pattern as a whole acts as a release barrier, that is the lock 24688 is released only after all previous memory operations have 24689 completed. 24690 24691 If this pattern is not defined, then a `memory_barrier' pattern 24692 will be emitted, followed by a store of the value to the memory 24693 operand. 24694 24695`atomic_compare_and_swapMODE' 24696 This pattern, if defined, emits code for an atomic compare-and-swap 24697 operation with memory model semantics. Operand 2 is the memory on 24698 which the atomic operation is performed. Operand 0 is an output 24699 operand which is set to true or false based on whether the 24700 operation succeeded. Operand 1 is an output operand which is set 24701 to the contents of the memory before the operation was attempted. 24702 Operand 3 is the value that is expected to be in memory. Operand 24703 4 is the value to put in memory if the expected value is found 24704 there. Operand 5 is set to 1 if this compare and swap is to be 24705 treated as a weak operation. Operand 6 is the memory model to be 24706 used if the operation is a success. Operand 7 is the memory model 24707 to be used if the operation fails. 24708 24709 If memory referred to in operand 2 contains the value in operand 24710 3, then operand 4 is stored in memory pointed to by operand 2 and 24711 fencing based on the memory model in operand 6 is issued. 24712 24713 If memory referred to in operand 2 does not contain the value in 24714 operand 3, then fencing based on the memory model in operand 7 is 24715 issued. 24716 24717 If a target does not support weak compare-and-swap operations, or 24718 the port elects not to implement weak operations, the argument in 24719 operand 5 can be ignored. Note a strong implementation must be 24720 provided. 24721 24722 If this pattern is not provided, the `__atomic_compare_exchange' 24723 built-in functions will utilize the legacy `sync_compare_and_swap' 24724 pattern with an `__ATOMIC_SEQ_CST' memory model. 24725 24726`atomic_loadMODE' 24727 This pattern implements an atomic load operation with memory model 24728 semantics. Operand 1 is the memory address being loaded from. 24729 Operand 0 is the result of the load. Operand 2 is the memory 24730 model to be used for the load operation. 24731 24732 If not present, the `__atomic_load' built-in function will either 24733 resort to a normal load with memory barriers, or a compare-and-swap 24734 operation if a normal load would not be atomic. 24735 24736`atomic_storeMODE' 24737 This pattern implements an atomic store operation with memory model 24738 semantics. Operand 0 is the memory address being stored to. 24739 Operand 1 is the value to be written. Operand 2 is the memory 24740 model to be used for the operation. 24741 24742 If not present, the `__atomic_store' built-in function will 24743 attempt to perform a normal store and surround it with any 24744 required memory fences. If the store would not be atomic, then an 24745 `__atomic_exchange' is attempted with the result being ignored. 24746 24747`atomic_exchangeMODE' 24748 This pattern implements an atomic exchange operation with memory 24749 model semantics. Operand 1 is the memory location the operation 24750 is performed on. Operand 0 is an output operand which is set to 24751 the original value contained in the memory pointed to by operand 24752 1. Operand 2 is the value to be stored. Operand 3 is the memory 24753 model to be used. 24754 24755 If this pattern is not present, the built-in function 24756 `__atomic_exchange' will attempt to preform the operation with a 24757 compare and swap loop. 24758 24759`atomic_addMODE', `atomic_subMODE' 24760`atomic_orMODE', `atomic_andMODE' 24761`atomic_xorMODE', `atomic_nandMODE' 24762 These patterns emit code for an atomic operation on memory with 24763 memory model semantics. Operand 0 is the memory on which the 24764 atomic operation is performed. Operand 1 is the second operand to 24765 the binary operator. Operand 2 is the memory model to be used by 24766 the operation. 24767 24768 If these patterns are not defined, attempts will be made to use 24769 legacy `sync' patterns, or equivalent patterns which return a 24770 result. If none of these are available a compare-and-swap loop 24771 will be used. 24772 24773`atomic_fetch_addMODE', `atomic_fetch_subMODE' 24774`atomic_fetch_orMODE', `atomic_fetch_andMODE' 24775`atomic_fetch_xorMODE', `atomic_fetch_nandMODE' 24776 These patterns emit code for an atomic operation on memory with 24777 memory model semantics, and return the original value. Operand 0 24778 is an output operand which contains the value of the memory 24779 location before the operation was performed. Operand 1 is the 24780 memory on which the atomic operation is performed. Operand 2 is 24781 the second operand to the binary operator. Operand 3 is the 24782 memory model to be used by the operation. 24783 24784 If these patterns are not defined, attempts will be made to use 24785 legacy `sync' patterns. If none of these are available a 24786 compare-and-swap loop will be used. 24787 24788`atomic_add_fetchMODE', `atomic_sub_fetchMODE' 24789`atomic_or_fetchMODE', `atomic_and_fetchMODE' 24790`atomic_xor_fetchMODE', `atomic_nand_fetchMODE' 24791 These patterns emit code for an atomic operation on memory with 24792 memory model semantics and return the result after the operation 24793 is performed. Operand 0 is an output operand which contains the 24794 value after the operation. Operand 1 is the memory on which the 24795 atomic operation is performed. Operand 2 is the second operand to 24796 the binary operator. Operand 3 is the memory model to be used by 24797 the operation. 24798 24799 If these patterns are not defined, attempts will be made to use 24800 legacy `sync' patterns, or equivalent patterns which return the 24801 result before the operation followed by the arithmetic operation 24802 required to produce the result. If none of these are available a 24803 compare-and-swap loop will be used. 24804 24805`atomic_test_and_set' 24806 This pattern emits code for `__builtin_atomic_test_and_set'. 24807 Operand 0 is an output operand which is set to true if the previous 24808 previous contents of the byte was "set", and false otherwise. 24809 Operand 1 is the `QImode' memory to be modified. Operand 2 is the 24810 memory model to be used. 24811 24812 The specific value that defines "set" is implementation defined, 24813 and is normally based on what is performed by the native atomic 24814 test and set instruction. 24815 24816`mem_thread_fenceMODE' 24817 This pattern emits code required to implement a thread fence with 24818 memory model semantics. Operand 0 is the memory model to be used. 24819 24820 If this pattern is not specified, all memory models except 24821 `__ATOMIC_RELAXED' will result in issuing a `sync_synchronize' 24822 barrier pattern. 24823 24824`mem_signal_fenceMODE' 24825 This pattern emits code required to implement a signal fence with 24826 memory model semantics. Operand 0 is the memory model to be used. 24827 24828 This pattern should impact the compiler optimizers the same way 24829 that mem_signal_fence does, but it does not need to issue any 24830 barrier instructions. 24831 24832 If this pattern is not specified, all memory models except 24833 `__ATOMIC_RELAXED' will result in issuing a `sync_synchronize' 24834 barrier pattern. 24835 24836`get_thread_pointerMODE' 24837`set_thread_pointerMODE' 24838 These patterns emit code that reads/sets the TLS thread pointer. 24839 Currently, these are only needed if the target needs to support the 24840 `__builtin_thread_pointer' and `__builtin_set_thread_pointer' 24841 builtins. 24842 24843 The get/set patterns have a single output/input operand 24844 respectively, with MODE intended to be `Pmode'. 24845 24846`stack_protect_set' 24847 This pattern, if defined, moves a `ptr_mode' value from the memory 24848 in operand 1 to the memory in operand 0 without leaving the value 24849 in a register afterward. This is to avoid leaking the value some 24850 place that an attacker might use to rewrite the stack guard slot 24851 after having clobbered it. 24852 24853 If this pattern is not defined, then a plain move pattern is 24854 generated. 24855 24856`stack_protect_test' 24857 This pattern, if defined, compares a `ptr_mode' value from the 24858 memory in operand 1 with the memory in operand 0 without leaving 24859 the value in a register afterward and branches to operand 2 if the 24860 values were equal. 24861 24862 If this pattern is not defined, then a plain compare pattern and 24863 conditional branch pattern is used. 24864 24865`clear_cache' 24866 This pattern, if defined, flushes the instruction cache for a 24867 region of memory. The region is bounded to by the Pmode pointers 24868 in operand 0 inclusive and operand 1 exclusive. 24869 24870 If this pattern is not defined, a call to the library function 24871 `__clear_cache' is used. 24872 24873 24874 24875File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc 24876 2487716.10 When the Order of Patterns Matters 24878======================================== 24879 24880Sometimes an insn can match more than one instruction pattern. Then the 24881pattern that appears first in the machine description is the one used. 24882Therefore, more specific patterns (patterns that will match fewer 24883things) and faster instructions (those that will produce better code 24884when they do match) should usually go first in the description. 24885 24886 In some cases the effect of ordering the patterns can be used to hide 24887a pattern when it is not valid. For example, the 68000 has an 24888instruction for converting a fullword to floating point and another for 24889converting a byte to floating point. An instruction converting an 24890integer to floating point could match either one. We put the pattern 24891to convert the fullword first to make sure that one will be used rather 24892than the other. (Otherwise a large integer might be generated as a 24893single-byte immediate quantity, which would not work.) Instead of 24894using this pattern ordering it would be possible to make the pattern 24895for convert-a-byte smart enough to deal properly with any constant 24896value. 24897 24898 24899File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc 24900 2490116.11 Interdependence of Patterns 24902================================= 24903 24904In some cases machines support instructions identical except for the 24905machine mode of one or more operands. For example, there may be 24906"sign-extend halfword" and "sign-extend byte" instructions whose 24907patterns are 24908 24909 (set (match_operand:SI 0 ...) 24910 (extend:SI (match_operand:HI 1 ...))) 24911 24912 (set (match_operand:SI 0 ...) 24913 (extend:SI (match_operand:QI 1 ...))) 24914 24915Constant integers do not specify a machine mode, so an instruction to 24916extend a constant value could match either pattern. The pattern it 24917actually will match is the one that appears first in the file. For 24918correct results, this must be the one for the widest possible mode 24919(`HImode', here). If the pattern matches the `QImode' instruction, the 24920results will be incorrect if the constant value does not actually fit 24921that mode. 24922 24923 Such instructions to extend constants are rarely generated because 24924they are optimized away, but they do occasionally happen in nonoptimized 24925compilations. 24926 24927 If a constraint in a pattern allows a constant, the reload pass may 24928replace a register with a constant permitted by the constraint in some 24929cases. Similarly for memory references. Because of this substitution, 24930you should not provide separate patterns for increment and decrement 24931instructions. Instead, they should be generated from the same pattern 24932that supports register-register add insns by examining the operands and 24933generating the appropriate machine instruction. 24934 24935 24936File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc 24937 2493816.12 Defining Jump Instruction Patterns 24939======================================== 24940 24941GCC does not assume anything about how the machine realizes jumps. The 24942machine description should define a single pattern, usually a 24943`define_expand', which expands to all the required insns. 24944 24945 Usually, this would be a comparison insn to set the condition code and 24946a separate branch insn testing the condition code and branching or not 24947according to its value. For many machines, however, separating 24948compares and branches is limiting, which is why the more flexible 24949approach with one `define_expand' is used in GCC. The machine 24950description becomes clearer for architectures that have 24951compare-and-branch instructions but no condition code. It also works 24952better when different sets of comparison operators are supported by 24953different kinds of conditional branches (e.g. integer vs. 24954floating-point), or by conditional branches with respect to conditional 24955stores. 24956 24957 Two separate insns are always used if the machine description 24958represents a condition code register using the legacy RTL expression 24959`(cc0)', and on most machines that use a separate condition code 24960register (*note Condition Code::). For machines that use `(cc0)', in 24961fact, the set and use of the condition code must be separate and 24962adjacent(1), thus allowing flags in `cc_status' to be used (*note 24963Condition Code::) and so that the comparison and branch insns could be 24964located from each other by using the functions `prev_cc0_setter' and 24965`next_cc0_user'. 24966 24967 Even in this case having a single entry point for conditional branches 24968is advantageous, because it handles equally well the case where a single 24969comparison instruction records the results of both signed and unsigned 24970comparison of the given operands (with the branch insns coming in 24971distinct signed and unsigned flavors) as in the x86 or SPARC, and the 24972case where there are distinct signed and unsigned compare instructions 24973and only one set of conditional branch instructions as in the PowerPC. 24974 24975 ---------- Footnotes ---------- 24976 24977 (1) `note' insns can separate them, though. 24978 24979 24980File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc 24981 2498216.13 Defining Looping Instruction Patterns 24983=========================================== 24984 24985Some machines have special jump instructions that can be utilized to 24986make loops more efficient. A common example is the 68000 `dbra' 24987instruction which performs a decrement of a register and a branch if the 24988result was greater than zero. Other machines, in particular digital 24989signal processors (DSPs), have special block repeat instructions to 24990provide low-overhead loop support. For example, the TI TMS320C3x/C4x 24991DSPs have a block repeat instruction that loads special registers to 24992mark the top and end of a loop and to count the number of loop 24993iterations. This avoids the need for fetching and executing a 24994`dbra'-like instruction and avoids pipeline stalls associated with the 24995jump. 24996 24997 GCC has three special named patterns to support low overhead looping. 24998They are `decrement_and_branch_until_zero', `doloop_begin', and 24999`doloop_end'. The first pattern, `decrement_and_branch_until_zero', is 25000not emitted during RTL generation but may be emitted during the 25001instruction combination phase. This requires the assistance of the 25002loop optimizer, using information collected during strength reduction, 25003to reverse a loop to count down to zero. Some targets also require the 25004loop optimizer to add a `REG_NONNEG' note to indicate that the 25005iteration count is always positive. This is needed if the target 25006performs a signed loop termination test. For example, the 68000 uses a 25007pattern similar to the following for its `dbra' instruction: 25008 25009 (define_insn "decrement_and_branch_until_zero" 25010 [(set (pc) 25011 (if_then_else 25012 (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am") 25013 (const_int -1)) 25014 (const_int 0)) 25015 (label_ref (match_operand 1 "" "")) 25016 (pc))) 25017 (set (match_dup 0) 25018 (plus:SI (match_dup 0) 25019 (const_int -1)))] 25020 "find_reg_note (insn, REG_NONNEG, 0)" 25021 "...") 25022 25023 Note that since the insn is both a jump insn and has an output, it must 25024deal with its own reloads, hence the `m' constraints. Also note that 25025since this insn is generated by the instruction combination phase 25026combining two sequential insns together into an implicit parallel insn, 25027the iteration counter needs to be biased by the same amount as the 25028decrement operation, in this case -1. Note that the following similar 25029pattern will not be matched by the combiner. 25030 25031 (define_insn "decrement_and_branch_until_zero" 25032 [(set (pc) 25033 (if_then_else 25034 (ge (match_operand:SI 0 "general_operand" "+d*am") 25035 (const_int 1)) 25036 (label_ref (match_operand 1 "" "")) 25037 (pc))) 25038 (set (match_dup 0) 25039 (plus:SI (match_dup 0) 25040 (const_int -1)))] 25041 "find_reg_note (insn, REG_NONNEG, 0)" 25042 "...") 25043 25044 The other two special looping patterns, `doloop_begin' and 25045`doloop_end', are emitted by the loop optimizer for certain 25046well-behaved loops with a finite number of loop iterations using 25047information collected during strength reduction. 25048 25049 The `doloop_end' pattern describes the actual looping instruction (or 25050the implicit looping operation) and the `doloop_begin' pattern is an 25051optional companion pattern that can be used for initialization needed 25052for some low-overhead looping instructions. 25053 25054 Note that some machines require the actual looping instruction to be 25055emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting 25056the true RTL for a looping instruction at the top of the loop can cause 25057problems with flow analysis. So instead, a dummy `doloop' insn is 25058emitted at the end of the loop. The machine dependent reorg pass checks 25059for the presence of this `doloop' insn and then searches back to the 25060top of the loop, where it inserts the true looping insn (provided there 25061are no instructions in the loop which would cause problems). Any 25062additional labels can be emitted at this point. In addition, if the 25063desired special iteration counter register was not allocated, this 25064machine dependent reorg pass could emit a traditional compare and jump 25065instruction pair. 25066 25067 The essential difference between the `decrement_and_branch_until_zero' 25068and the `doloop_end' patterns is that the loop optimizer allocates an 25069additional pseudo register for the latter as an iteration counter. 25070This pseudo register cannot be used within the loop (i.e., general 25071induction variables cannot be derived from it), however, in many cases 25072the loop induction variable may become redundant and removed by the 25073flow pass. 25074 25075 25076File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc 25077 2507816.14 Canonicalization of Instructions 25079====================================== 25080 25081There are often cases where multiple RTL expressions could represent an 25082operation performed by a single machine instruction. This situation is 25083most commonly encountered with logical, branch, and multiply-accumulate 25084instructions. In such cases, the compiler attempts to convert these 25085multiple RTL expressions into a single canonical form to reduce the 25086number of insn patterns required. 25087 25088 In addition to algebraic simplifications, following canonicalizations 25089are performed: 25090 25091 * For commutative and comparison operators, a constant is always 25092 made the second operand. If a machine only supports a constant as 25093 the second operand, only patterns that match a constant in the 25094 second operand need be supplied. 25095 25096 * For associative operators, a sequence of operators will always 25097 chain to the left; for instance, only the left operand of an 25098 integer `plus' can itself be a `plus'. `and', `ior', `xor', 25099 `plus', `mult', `smin', `smax', `umin', and `umax' are associative 25100 when applied to integers, and sometimes to floating-point. 25101 25102 * For these operators, if only one operand is a `neg', `not', 25103 `mult', `plus', or `minus' expression, it will be the first 25104 operand. 25105 25106 * In combinations of `neg', `mult', `plus', and `minus', the `neg' 25107 operations (if any) will be moved inside the operations as far as 25108 possible. For instance, `(neg (mult A B))' is canonicalized as 25109 `(mult (neg A) B)', but `(plus (mult (neg B) C) A)' is 25110 canonicalized as `(minus A (mult B C))'. 25111 25112 * For the `compare' operator, a constant is always the second operand 25113 if the first argument is a condition code register or `(cc0)'. 25114 25115 * An operand of `neg', `not', `mult', `plus', or `minus' is made the 25116 first operand under the same conditions as above. 25117 25118 * `(ltu (plus A B) B)' is converted to `(ltu (plus A B) A)'. 25119 Likewise with `geu' instead of `ltu'. 25120 25121 * `(minus X (const_int N))' is converted to `(plus X (const_int 25122 -N))'. 25123 25124 * Within address computations (i.e., inside `mem'), a left shift is 25125 converted into the appropriate multiplication by a power of two. 25126 25127 * De Morgan's Law is used to move bitwise negation inside a bitwise 25128 logical-and or logical-or operation. If this results in only one 25129 operand being a `not' expression, it will be the first one. 25130 25131 A machine that has an instruction that performs a bitwise 25132 logical-and of one operand with the bitwise negation of the other 25133 should specify the pattern for that instruction as 25134 25135 (define_insn "" 25136 [(set (match_operand:M 0 ...) 25137 (and:M (not:M (match_operand:M 1 ...)) 25138 (match_operand:M 2 ...)))] 25139 "..." 25140 "...") 25141 25142 Similarly, a pattern for a "NAND" instruction should be written 25143 25144 (define_insn "" 25145 [(set (match_operand:M 0 ...) 25146 (ior:M (not:M (match_operand:M 1 ...)) 25147 (not:M (match_operand:M 2 ...))))] 25148 "..." 25149 "...") 25150 25151 In both cases, it is not necessary to include patterns for the many 25152 logically equivalent RTL expressions. 25153 25154 * The only possible RTL expressions involving both bitwise 25155 exclusive-or and bitwise negation are `(xor:M X Y)' and `(not:M 25156 (xor:M X Y))'. 25157 25158 * The sum of three items, one of which is a constant, will only 25159 appear in the form 25160 25161 (plus:M (plus:M X Y) CONSTANT) 25162 25163 * Equality comparisons of a group of bits (usually a single bit) 25164 with zero will be written using `zero_extract' rather than the 25165 equivalent `and' or `sign_extract' operations. 25166 25167 * `(sign_extend:M1 (mult:M2 (sign_extend:M2 X) (sign_extend:M2 Y)))' 25168 is converted to `(mult:M1 (sign_extend:M1 X) (sign_extend:M1 Y))', 25169 and likewise for `zero_extend'. 25170 25171 * `(sign_extend:M1 (mult:M2 (ashiftrt:M2 X S) (sign_extend:M2 Y)))' 25172 is converted to `(mult:M1 (sign_extend:M1 (ashiftrt:M2 X S)) 25173 (sign_extend:M1 Y))', and likewise for patterns using 25174 `zero_extend' and `lshiftrt'. If the second operand of `mult' is 25175 also a shift, then that is extended also. This transformation is 25176 only applied when it can be proven that the original operation had 25177 sufficient precision to prevent overflow. 25178 25179 25180 Further canonicalization rules are defined in the function 25181`commutative_operand_precedence' in `gcc/rtlanal.c'. 25182 25183 25184File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc 25185 2518616.15 Defining RTL Sequences for Code Generation 25187================================================ 25188 25189On some target machines, some standard pattern names for RTL generation 25190cannot be handled with single insn, but a sequence of RTL insns can 25191represent them. For these target machines, you can write a 25192`define_expand' to specify how to generate the sequence of RTL. 25193 25194 A `define_expand' is an RTL expression that looks almost like a 25195`define_insn'; but, unlike the latter, a `define_expand' is used only 25196for RTL generation and it can produce more than one RTL insn. 25197 25198 A `define_expand' RTX has four operands: 25199 25200 * The name. Each `define_expand' must have a name, since the only 25201 use for it is to refer to it by name. 25202 25203 * The RTL template. This is a vector of RTL expressions representing 25204 a sequence of separate instructions. Unlike `define_insn', there 25205 is no implicit surrounding `PARALLEL'. 25206 25207 * The condition, a string containing a C expression. This 25208 expression is used to express how the availability of this pattern 25209 depends on subclasses of target machine, selected by command-line 25210 options when GCC is run. This is just like the condition of a 25211 `define_insn' that has a standard name. Therefore, the condition 25212 (if present) may not depend on the data in the insn being matched, 25213 but only the target-machine-type flags. The compiler needs to 25214 test these conditions during initialization in order to learn 25215 exactly which named instructions are available in a particular run. 25216 25217 * The preparation statements, a string containing zero or more C 25218 statements which are to be executed before RTL code is generated 25219 from the RTL template. 25220 25221 Usually these statements prepare temporary registers for use as 25222 internal operands in the RTL template, but they can also generate 25223 RTL insns directly by calling routines such as `emit_insn', etc. 25224 Any such insns precede the ones that come from the RTL template. 25225 25226 * Optionally, a vector containing the values of attributes. *Note 25227 Insn Attributes::. 25228 25229 Every RTL insn emitted by a `define_expand' must match some 25230`define_insn' in the machine description. Otherwise, the compiler will 25231crash when trying to generate code for the insn or trying to optimize 25232it. 25233 25234 The RTL template, in addition to controlling generation of RTL insns, 25235also describes the operands that need to be specified when this pattern 25236is used. In particular, it gives a predicate for each operand. 25237 25238 A true operand, which needs to be specified in order to generate RTL 25239from the pattern, should be described with a `match_operand' in its 25240first occurrence in the RTL template. This enters information on the 25241operand's predicate into the tables that record such things. GCC uses 25242the information to preload the operand into a register if that is 25243required for valid RTL code. If the operand is referred to more than 25244once, subsequent references should use `match_dup'. 25245 25246 The RTL template may also refer to internal "operands" which are 25247temporary registers or labels used only within the sequence made by the 25248`define_expand'. Internal operands are substituted into the RTL 25249template with `match_dup', never with `match_operand'. The values of 25250the internal operands are not passed in as arguments by the compiler 25251when it requests use of this pattern. Instead, they are computed 25252within the pattern, in the preparation statements. These statements 25253compute the values and store them into the appropriate elements of 25254`operands' so that `match_dup' can find them. 25255 25256 There are two special macros defined for use in the preparation 25257statements: `DONE' and `FAIL'. Use them with a following semicolon, as 25258a statement. 25259 25260`DONE' 25261 Use the `DONE' macro to end RTL generation for the pattern. The 25262 only RTL insns resulting from the pattern on this occasion will be 25263 those already emitted by explicit calls to `emit_insn' within the 25264 preparation statements; the RTL template will not be generated. 25265 25266`FAIL' 25267 Make the pattern fail on this occasion. When a pattern fails, it 25268 means that the pattern was not truly available. The calling 25269 routines in the compiler will try other strategies for code 25270 generation using other patterns. 25271 25272 Failure is currently supported only for binary (addition, 25273 multiplication, shifting, etc.) and bit-field (`extv', `extzv', 25274 and `insv') operations. 25275 25276 If the preparation falls through (invokes neither `DONE' nor `FAIL'), 25277then the `define_expand' acts like a `define_insn' in that the RTL 25278template is used to generate the insn. 25279 25280 The RTL template is not used for matching, only for generating the 25281initial insn list. If the preparation statement always invokes `DONE' 25282or `FAIL', the RTL template may be reduced to a simple list of 25283operands, such as this example: 25284 25285 (define_expand "addsi3" 25286 [(match_operand:SI 0 "register_operand" "") 25287 (match_operand:SI 1 "register_operand" "") 25288 (match_operand:SI 2 "register_operand" "")] 25289 "" 25290 " 25291 { 25292 handle_add (operands[0], operands[1], operands[2]); 25293 DONE; 25294 }") 25295 25296 Here is an example, the definition of left-shift for the SPUR chip: 25297 25298 (define_expand "ashlsi3" 25299 [(set (match_operand:SI 0 "register_operand" "") 25300 (ashift:SI 25301 (match_operand:SI 1 "register_operand" "") 25302 (match_operand:SI 2 "nonmemory_operand" "")))] 25303 "" 25304 " 25305 25306 { 25307 if (GET_CODE (operands[2]) != CONST_INT 25308 || (unsigned) INTVAL (operands[2]) > 3) 25309 FAIL; 25310 }") 25311 25312This example uses `define_expand' so that it can generate an RTL insn 25313for shifting when the shift-count is in the supported range of 0 to 3 25314but fail in other cases where machine insns aren't available. When it 25315fails, the compiler tries another strategy using different patterns 25316(such as, a library call). 25317 25318 If the compiler were able to handle nontrivial condition-strings in 25319patterns with names, then it would be possible to use a `define_insn' 25320in that case. Here is another case (zero-extension on the 68000) which 25321makes more use of the power of `define_expand': 25322 25323 (define_expand "zero_extendhisi2" 25324 [(set (match_operand:SI 0 "general_operand" "") 25325 (const_int 0)) 25326 (set (strict_low_part 25327 (subreg:HI 25328 (match_dup 0) 25329 0)) 25330 (match_operand:HI 1 "general_operand" ""))] 25331 "" 25332 "operands[1] = make_safe_from (operands[1], operands[0]);") 25333 25334Here two RTL insns are generated, one to clear the entire output operand 25335and the other to copy the input operand into its low half. This 25336sequence is incorrect if the input operand refers to [the old value of] 25337the output operand, so the preparation statement makes sure this isn't 25338so. The function `make_safe_from' copies the `operands[1]' into a 25339temporary register if it refers to `operands[0]'. It does this by 25340emitting another RTL insn. 25341 25342 Finally, a third example shows the use of an internal operand. 25343Zero-extension on the SPUR chip is done by `and'-ing the result against 25344a halfword mask. But this mask cannot be represented by a `const_int' 25345because the constant value is too large to be legitimate on this 25346machine. So it must be copied into a register with `force_reg' and 25347then the register used in the `and'. 25348 25349 (define_expand "zero_extendhisi2" 25350 [(set (match_operand:SI 0 "register_operand" "") 25351 (and:SI (subreg:SI 25352 (match_operand:HI 1 "register_operand" "") 25353 0) 25354 (match_dup 2)))] 25355 "" 25356 "operands[2] 25357 = force_reg (SImode, GEN_INT (65535)); ") 25358 25359 _Note:_ If the `define_expand' is used to serve a standard binary or 25360unary arithmetic operation or a bit-field operation, then the last insn 25361it generates must not be a `code_label', `barrier' or `note'. It must 25362be an `insn', `jump_insn' or `call_insn'. If you don't need a real insn 25363at the end, emit an insn to copy the result of the operation into 25364itself. Such an insn will generate no code, but it can avoid problems 25365in the compiler. 25366 25367 25368File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc 25369 2537016.16 Defining How to Split Instructions 25371======================================== 25372 25373There are two cases where you should specify how to split a pattern 25374into multiple insns. On machines that have instructions requiring 25375delay slots (*note Delay Slots::) or that have instructions whose 25376output is not available for multiple cycles (*note Processor pipeline 25377description::), the compiler phases that optimize these cases need to 25378be able to move insns into one-instruction delay slots. However, some 25379insns may generate more than one machine instruction. These insns 25380cannot be placed into a delay slot. 25381 25382 Often you can rewrite the single insn as a list of individual insns, 25383each corresponding to one machine instruction. The disadvantage of 25384doing so is that it will cause the compilation to be slower and require 25385more space. If the resulting insns are too complex, it may also 25386suppress some optimizations. The compiler splits the insn if there is a 25387reason to believe that it might improve instruction or delay slot 25388scheduling. 25389 25390 The insn combiner phase also splits putative insns. If three insns are 25391merged into one insn with a complex expression that cannot be matched by 25392some `define_insn' pattern, the combiner phase attempts to split the 25393complex pattern into two insns that are recognized. Usually it can 25394break the complex pattern into two patterns by splitting out some 25395subexpression. However, in some other cases, such as performing an 25396addition of a large constant in two insns on a RISC machine, the way to 25397split the addition into two insns is machine-dependent. 25398 25399 The `define_split' definition tells the compiler how to split a 25400complex insn into several simpler insns. It looks like this: 25401 25402 (define_split 25403 [INSN-PATTERN] 25404 "CONDITION" 25405 [NEW-INSN-PATTERN-1 25406 NEW-INSN-PATTERN-2 25407 ...] 25408 "PREPARATION-STATEMENTS") 25409 25410 INSN-PATTERN is a pattern that needs to be split and CONDITION is the 25411final condition to be tested, as in a `define_insn'. When an insn 25412matching INSN-PATTERN and satisfying CONDITION is found, it is replaced 25413in the insn list with the insns given by NEW-INSN-PATTERN-1, 25414NEW-INSN-PATTERN-2, etc. 25415 25416 The PREPARATION-STATEMENTS are similar to those statements that are 25417specified for `define_expand' (*note Expander Definitions::) and are 25418executed before the new RTL is generated to prepare for the generated 25419code or emit some insns whose pattern is not fixed. Unlike those in 25420`define_expand', however, these statements must not generate any new 25421pseudo-registers. Once reload has completed, they also must not 25422allocate any space in the stack frame. 25423 25424 Patterns are matched against INSN-PATTERN in two different 25425circumstances. If an insn needs to be split for delay slot scheduling 25426or insn scheduling, the insn is already known to be valid, which means 25427that it must have been matched by some `define_insn' and, if 25428`reload_completed' is nonzero, is known to satisfy the constraints of 25429that `define_insn'. In that case, the new insn patterns must also be 25430insns that are matched by some `define_insn' and, if `reload_completed' 25431is nonzero, must also satisfy the constraints of those definitions. 25432 25433 As an example of this usage of `define_split', consider the following 25434example from `a29k.md', which splits a `sign_extend' from `HImode' to 25435`SImode' into a pair of shift insns: 25436 25437 (define_split 25438 [(set (match_operand:SI 0 "gen_reg_operand" "") 25439 (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] 25440 "" 25441 [(set (match_dup 0) 25442 (ashift:SI (match_dup 1) 25443 (const_int 16))) 25444 (set (match_dup 0) 25445 (ashiftrt:SI (match_dup 0) 25446 (const_int 16)))] 25447 " 25448 { operands[1] = gen_lowpart (SImode, operands[1]); }") 25449 25450 When the combiner phase tries to split an insn pattern, it is always 25451the case that the pattern is _not_ matched by any `define_insn'. The 25452combiner pass first tries to split a single `set' expression and then 25453the same `set' expression inside a `parallel', but followed by a 25454`clobber' of a pseudo-reg to use as a scratch register. In these 25455cases, the combiner expects exactly two new insn patterns to be 25456generated. It will verify that these patterns match some `define_insn' 25457definitions, so you need not do this test in the `define_split' (of 25458course, there is no point in writing a `define_split' that will never 25459produce insns that match). 25460 25461 Here is an example of this use of `define_split', taken from 25462`rs6000.md': 25463 25464 (define_split 25465 [(set (match_operand:SI 0 "gen_reg_operand" "") 25466 (plus:SI (match_operand:SI 1 "gen_reg_operand" "") 25467 (match_operand:SI 2 "non_add_cint_operand" "")))] 25468 "" 25469 [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3))) 25470 (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))] 25471 " 25472 { 25473 int low = INTVAL (operands[2]) & 0xffff; 25474 int high = (unsigned) INTVAL (operands[2]) >> 16; 25475 25476 if (low & 0x8000) 25477 high++, low |= 0xffff0000; 25478 25479 operands[3] = GEN_INT (high << 16); 25480 operands[4] = GEN_INT (low); 25481 }") 25482 25483 Here the predicate `non_add_cint_operand' matches any `const_int' that 25484is _not_ a valid operand of a single add insn. The add with the 25485smaller displacement is written so that it can be substituted into the 25486address of a subsequent operation. 25487 25488 An example that uses a scratch register, from the same file, generates 25489an equality comparison of a register and a large constant: 25490 25491 (define_split 25492 [(set (match_operand:CC 0 "cc_reg_operand" "") 25493 (compare:CC (match_operand:SI 1 "gen_reg_operand" "") 25494 (match_operand:SI 2 "non_short_cint_operand" ""))) 25495 (clobber (match_operand:SI 3 "gen_reg_operand" ""))] 25496 "find_single_use (operands[0], insn, 0) 25497 && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ 25498 || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)" 25499 [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4))) 25500 (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))] 25501 " 25502 { 25503 /* Get the constant we are comparing against, C, and see what it 25504 looks like sign-extended to 16 bits. Then see what constant 25505 could be XOR'ed with C to get the sign-extended value. */ 25506 25507 int c = INTVAL (operands[2]); 25508 int sextc = (c << 16) >> 16; 25509 int xorv = c ^ sextc; 25510 25511 operands[4] = GEN_INT (xorv); 25512 operands[5] = GEN_INT (sextc); 25513 }") 25514 25515 To avoid confusion, don't write a single `define_split' that accepts 25516some insns that match some `define_insn' as well as some insns that 25517don't. Instead, write two separate `define_split' definitions, one for 25518the insns that are valid and one for the insns that are not valid. 25519 25520 The splitter is allowed to split jump instructions into sequence of 25521jumps or create new jumps in while splitting non-jump instructions. As 25522the central flowgraph and branch prediction information needs to be 25523updated, several restriction apply. 25524 25525 Splitting of jump instruction into sequence that over by another jump 25526instruction is always valid, as compiler expect identical behavior of 25527new jump. When new sequence contains multiple jump instructions or new 25528labels, more assistance is needed. Splitter is required to create only 25529unconditional jumps, or simple conditional jump instructions. 25530Additionally it must attach a `REG_BR_PROB' note to each conditional 25531jump. A global variable `split_branch_probability' holds the 25532probability of the original branch in case it was a simple conditional 25533jump, -1 otherwise. To simplify recomputing of edge frequencies, the 25534new sequence is required to have only forward jumps to the newly 25535created labels. 25536 25537 For the common case where the pattern of a define_split exactly 25538matches the pattern of a define_insn, use `define_insn_and_split'. It 25539looks like this: 25540 25541 (define_insn_and_split 25542 [INSN-PATTERN] 25543 "CONDITION" 25544 "OUTPUT-TEMPLATE" 25545 "SPLIT-CONDITION" 25546 [NEW-INSN-PATTERN-1 25547 NEW-INSN-PATTERN-2 25548 ...] 25549 "PREPARATION-STATEMENTS" 25550 [INSN-ATTRIBUTES]) 25551 25552 INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used 25553as in `define_insn'. The NEW-INSN-PATTERN vector and the 25554PREPARATION-STATEMENTS are used as in a `define_split'. The 25555SPLIT-CONDITION is also used as in `define_split', with the additional 25556behavior that if the condition starts with `&&', the condition used for 25557the split will be the constructed as a logical "and" of the split 25558condition with the insn condition. For example, from i386.md: 25559 25560 (define_insn_and_split "zero_extendhisi2_and" 25561 [(set (match_operand:SI 0 "register_operand" "=r") 25562 (zero_extend:SI (match_operand:HI 1 "register_operand" "0"))) 25563 (clobber (reg:CC 17))] 25564 "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size" 25565 "#" 25566 "&& reload_completed" 25567 [(parallel [(set (match_dup 0) 25568 (and:SI (match_dup 0) (const_int 65535))) 25569 (clobber (reg:CC 17))])] 25570 "" 25571 [(set_attr "type" "alu1")]) 25572 25573 In this case, the actual split condition will be 25574`TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'. 25575 25576 The `define_insn_and_split' construction provides exactly the same 25577functionality as two separate `define_insn' and `define_split' 25578patterns. It exists for compactness, and as a maintenance tool to 25579prevent having to ensure the two patterns' templates match. 25580 25581 25582File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc 25583 2558416.17 Including Patterns in Machine Descriptions. 25585================================================= 25586 25587The `include' pattern tells the compiler tools where to look for 25588patterns that are in files other than in the file `.md'. This is used 25589only at build time and there is no preprocessing allowed. 25590 25591 It looks like: 25592 25593 25594 (include 25595 PATHNAME) 25596 25597 For example: 25598 25599 25600 (include "filestuff") 25601 25602 Where PATHNAME is a string that specifies the location of the file, 25603specifies the include file to be in `gcc/config/target/filestuff'. The 25604directory `gcc/config/target' is regarded as the default directory. 25605 25606 Machine descriptions may be split up into smaller more manageable 25607subsections and placed into subdirectories. 25608 25609 By specifying: 25610 25611 25612 (include "BOGUS/filestuff") 25613 25614 the include file is specified to be in 25615`gcc/config/TARGET/BOGUS/filestuff'. 25616 25617 Specifying an absolute path for the include file such as; 25618 25619 (include "/u2/BOGUS/filestuff") 25620 is permitted but is not encouraged. 25621 2562216.17.1 RTL Generation Tool Options for Directory Search 25623-------------------------------------------------------- 25624 25625The `-IDIR' option specifies directories to search for machine 25626descriptions. For example: 25627 25628 25629 genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md 25630 25631 Add the directory DIR to the head of the list of directories to be 25632searched for header files. This can be used to override a system 25633machine definition file, substituting your own version, since these 25634directories are searched before the default machine description file 25635directories. If you use more than one `-I' option, the directories are 25636scanned in left-to-right order; the standard default directory come 25637after. 25638 25639 25640File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc 25641 2564216.18 Machine-Specific Peephole Optimizers 25643========================================== 25644 25645In addition to instruction patterns the `md' file may contain 25646definitions of machine-specific peephole optimizations. 25647 25648 The combiner does not notice certain peephole optimizations when the 25649data flow in the program does not suggest that it should try them. For 25650example, sometimes two consecutive insns related in purpose can be 25651combined even though the second one does not appear to use a register 25652computed in the first one. A machine-specific peephole optimizer can 25653detect such opportunities. 25654 25655 There are two forms of peephole definitions that may be used. The 25656original `define_peephole' is run at assembly output time to match 25657insns and substitute assembly text. Use of `define_peephole' is 25658deprecated. 25659 25660 A newer `define_peephole2' matches insns and substitutes new insns. 25661The `peephole2' pass is run after register allocation but before 25662scheduling, which may result in much better code for targets that do 25663scheduling. 25664 25665* Menu: 25666 25667* define_peephole:: RTL to Text Peephole Optimizers 25668* define_peephole2:: RTL to RTL Peephole Optimizers 25669 25670 25671File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions 25672 2567316.18.1 RTL to Text Peephole Optimizers 25674--------------------------------------- 25675 25676A definition looks like this: 25677 25678 (define_peephole 25679 [INSN-PATTERN-1 25680 INSN-PATTERN-2 25681 ...] 25682 "CONDITION" 25683 "TEMPLATE" 25684 "OPTIONAL-INSN-ATTRIBUTES") 25685 25686The last string operand may be omitted if you are not using any 25687machine-specific information in this machine description. If present, 25688it must obey the same rules as in a `define_insn'. 25689 25690 In this skeleton, INSN-PATTERN-1 and so on are patterns to match 25691consecutive insns. The optimization applies to a sequence of insns when 25692INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next, 25693and so on. 25694 25695 Each of the insns matched by a peephole must also match a 25696`define_insn'. Peepholes are checked only at the last stage just 25697before code generation, and only optionally. Therefore, any insn which 25698would match a peephole but no `define_insn' will cause a crash in code 25699generation in an unoptimized compilation, or at various optimization 25700stages. 25701 25702 The operands of the insns are matched with `match_operands', 25703`match_operator', and `match_dup', as usual. What is not usual is that 25704the operand numbers apply to all the insn patterns in the definition. 25705So, you can check for identical operands in two insns by using 25706`match_operand' in one insn and `match_dup' in the other. 25707 25708 The operand constraints used in `match_operand' patterns do not have 25709any direct effect on the applicability of the peephole, but they will 25710be validated afterward, so make sure your constraints are general enough 25711to apply whenever the peephole matches. If the peephole matches but 25712the constraints are not satisfied, the compiler will crash. 25713 25714 It is safe to omit constraints in all the operands of the peephole; or 25715you can write constraints which serve as a double-check on the criteria 25716previously tested. 25717 25718 Once a sequence of insns matches the patterns, the CONDITION is 25719checked. This is a C expression which makes the final decision whether 25720to perform the optimization (we do so if the expression is nonzero). If 25721CONDITION is omitted (in other words, the string is empty) then the 25722optimization is applied to every sequence of insns that matches the 25723patterns. 25724 25725 The defined peephole optimizations are applied after register 25726allocation is complete. Therefore, the peephole definition can check 25727which operands have ended up in which kinds of registers, just by 25728looking at the operands. 25729 25730 The way to refer to the operands in CONDITION is to write 25731`operands[I]' for operand number I (as matched by `(match_operand I 25732...)'). Use the variable `insn' to refer to the last of the insns 25733being matched; use `prev_active_insn' to find the preceding insns. 25734 25735 When optimizing computations with intermediate results, you can use 25736CONDITION to match only when the intermediate results are not used 25737elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where INSN 25738is the insn in which you expect the value to be used for the last time 25739(from the value of `insn', together with use of `prev_nonnote_insn'), 25740and OP is the intermediate value (from `operands[I]'). 25741 25742 Applying the optimization means replacing the sequence of insns with 25743one new insn. The TEMPLATE controls ultimate output of assembler code 25744for this combined insn. It works exactly like the template of a 25745`define_insn'. Operand numbers in this template are the same ones used 25746in matching the original sequence of insns. 25747 25748 The result of a defined peephole optimizer does not need to match any 25749of the insn patterns in the machine description; it does not even have 25750an opportunity to match them. The peephole optimizer definition itself 25751serves as the insn pattern to control how the insn is output. 25752 25753 Defined peephole optimizers are run as assembler code is being output, 25754so the insns they produce are never combined or rearranged in any way. 25755 25756 Here is an example, taken from the 68000 machine description: 25757 25758 (define_peephole 25759 [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4))) 25760 (set (match_operand:DF 0 "register_operand" "=f") 25761 (match_operand:DF 1 "register_operand" "ad"))] 25762 "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])" 25763 { 25764 rtx xoperands[2]; 25765 xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1); 25766 #ifdef MOTOROLA 25767 output_asm_insn ("move.l %1,(sp)", xoperands); 25768 output_asm_insn ("move.l %1,-(sp)", operands); 25769 return "fmove.d (sp)+,%0"; 25770 #else 25771 output_asm_insn ("movel %1,sp@", xoperands); 25772 output_asm_insn ("movel %1,sp@-", operands); 25773 return "fmoved sp@+,%0"; 25774 #endif 25775 }) 25776 25777 The effect of this optimization is to change 25778 25779 jbsr _foobar 25780 addql #4,sp 25781 movel d1,sp@- 25782 movel d0,sp@- 25783 fmoved sp@+,fp0 25784 25785into 25786 25787 jbsr _foobar 25788 movel d1,sp@ 25789 movel d0,sp@- 25790 fmoved sp@+,fp0 25791 25792 INSN-PATTERN-1 and so on look _almost_ like the second operand of 25793`define_insn'. There is one important difference: the second operand 25794of `define_insn' consists of one or more RTX's enclosed in square 25795brackets. Usually, there is only one: then the same action can be 25796written as an element of a `define_peephole'. But when there are 25797multiple actions in a `define_insn', they are implicitly enclosed in a 25798`parallel'. Then you must explicitly write the `parallel', and the 25799square brackets within it, in the `define_peephole'. Thus, if an insn 25800pattern looks like this, 25801 25802 (define_insn "divmodsi4" 25803 [(set (match_operand:SI 0 "general_operand" "=d") 25804 (div:SI (match_operand:SI 1 "general_operand" "0") 25805 (match_operand:SI 2 "general_operand" "dmsK"))) 25806 (set (match_operand:SI 3 "general_operand" "=d") 25807 (mod:SI (match_dup 1) (match_dup 2)))] 25808 "TARGET_68020" 25809 "divsl%.l %2,%3:%0") 25810 25811then the way to mention this insn in a peephole is as follows: 25812 25813 (define_peephole 25814 [... 25815 (parallel 25816 [(set (match_operand:SI 0 "general_operand" "=d") 25817 (div:SI (match_operand:SI 1 "general_operand" "0") 25818 (match_operand:SI 2 "general_operand" "dmsK"))) 25819 (set (match_operand:SI 3 "general_operand" "=d") 25820 (mod:SI (match_dup 1) (match_dup 2)))]) 25821 ...] 25822 ...) 25823 25824 25825File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions 25826 2582716.18.2 RTL to RTL Peephole Optimizers 25828-------------------------------------- 25829 25830The `define_peephole2' definition tells the compiler how to substitute 25831one sequence of instructions for another sequence, what additional 25832scratch registers may be needed and what their lifetimes must be. 25833 25834 (define_peephole2 25835 [INSN-PATTERN-1 25836 INSN-PATTERN-2 25837 ...] 25838 "CONDITION" 25839 [NEW-INSN-PATTERN-1 25840 NEW-INSN-PATTERN-2 25841 ...] 25842 "PREPARATION-STATEMENTS") 25843 25844 The definition is almost identical to `define_split' (*note Insn 25845Splitting::) except that the pattern to match is not a single 25846instruction, but a sequence of instructions. 25847 25848 It is possible to request additional scratch registers for use in the 25849output template. If appropriate registers are not free, the pattern 25850will simply not match. 25851 25852 Scratch registers are requested with a `match_scratch' pattern at the 25853top level of the input pattern. The allocated register (initially) will 25854be dead at the point requested within the original sequence. If the 25855scratch is used at more than a single point, a `match_dup' pattern at 25856the top level of the input pattern marks the last position in the input 25857sequence at which the register must be available. 25858 25859 Here is an example from the IA-32 machine description: 25860 25861 (define_peephole2 25862 [(match_scratch:SI 2 "r") 25863 (parallel [(set (match_operand:SI 0 "register_operand" "") 25864 (match_operator:SI 3 "arith_or_logical_operator" 25865 [(match_dup 0) 25866 (match_operand:SI 1 "memory_operand" "")])) 25867 (clobber (reg:CC 17))])] 25868 "! optimize_size && ! TARGET_READ_MODIFY" 25869 [(set (match_dup 2) (match_dup 1)) 25870 (parallel [(set (match_dup 0) 25871 (match_op_dup 3 [(match_dup 0) (match_dup 2)])) 25872 (clobber (reg:CC 17))])] 25873 "") 25874 25875This pattern tries to split a load from its use in the hopes that we'll 25876be able to schedule around the memory load latency. It allocates a 25877single `SImode' register of class `GENERAL_REGS' (`"r"') that needs to 25878be live only at the point just before the arithmetic. 25879 25880 A real example requiring extended scratch lifetimes is harder to come 25881by, so here's a silly made-up example: 25882 25883 (define_peephole2 25884 [(match_scratch:SI 4 "r") 25885 (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" "")) 25886 (set (match_operand:SI 2 "" "") (match_dup 1)) 25887 (match_dup 4) 25888 (set (match_operand:SI 3 "" "") (match_dup 1))] 25889 "/* determine 1 does not overlap 0 and 2 */" 25890 [(set (match_dup 4) (match_dup 1)) 25891 (set (match_dup 0) (match_dup 4)) 25892 (set (match_dup 2) (match_dup 4)) 25893 (set (match_dup 3) (match_dup 4))] 25894 "") 25895 25896If we had not added the `(match_dup 4)' in the middle of the input 25897sequence, it might have been the case that the register we chose at the 25898beginning of the sequence is killed by the first or second `set'. 25899 25900 25901File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc 25902 2590316.19 Instruction Attributes 25904============================ 25905 25906In addition to describing the instruction supported by the target 25907machine, the `md' file also defines a group of "attributes" and a set of 25908values for each. Every generated insn is assigned a value for each 25909attribute. One possible attribute would be the effect that the insn 25910has on the machine's condition code. This attribute can then be used 25911by `NOTICE_UPDATE_CC' to track the condition codes. 25912 25913* Menu: 25914 25915* Defining Attributes:: Specifying attributes and their values. 25916* Expressions:: Valid expressions for attribute values. 25917* Tagging Insns:: Assigning attribute values to insns. 25918* Attr Example:: An example of assigning attributes. 25919* Insn Lengths:: Computing the length of insns. 25920* Constant Attributes:: Defining attributes that are constant. 25921* Mnemonic Attribute:: Obtain the instruction mnemonic as attribute value. 25922* Delay Slots:: Defining delay slots required for a machine. 25923* Processor pipeline description:: Specifying information for insn scheduling. 25924 25925 25926File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes 25927 2592816.19.1 Defining Attributes and their Values 25929-------------------------------------------- 25930 25931The `define_attr' expression is used to define each attribute required 25932by the target machine. It looks like: 25933 25934 (define_attr NAME LIST-OF-VALUES DEFAULT) 25935 25936 NAME is a string specifying the name of the attribute being defined. 25937Some attributes are used in a special way by the rest of the compiler. 25938The `enabled' attribute can be used to conditionally enable or disable 25939insn alternatives (*note Disable Insn Alternatives::). The `predicable' 25940attribute, together with a suitable `define_cond_exec' (*note 25941Conditional Execution::), can be used to automatically generate 25942conditional variants of instruction patterns. The `mnemonic' attribute 25943can be used to check for the instruction mnemonic (*note Mnemonic 25944Attribute::). The compiler internally uses the names `ce_enabled' and 25945`nonce_enabled', so they should not be used elsewhere as alternative 25946names. 25947 25948 LIST-OF-VALUES is either a string that specifies a comma-separated 25949list of values that can be assigned to the attribute, or a null string 25950to indicate that the attribute takes numeric values. 25951 25952 DEFAULT is an attribute expression that gives the value of this 25953attribute for insns that match patterns whose definition does not 25954include an explicit value for this attribute. *Note Attr Example::, 25955for more information on the handling of defaults. *Note Constant 25956Attributes::, for information on attributes that do not depend on any 25957particular insn. 25958 25959 For each defined attribute, a number of definitions are written to the 25960`insn-attr.h' file. For cases where an explicit set of values is 25961specified for an attribute, the following are defined: 25962 25963 * A `#define' is written for the symbol `HAVE_ATTR_NAME'. 25964 25965 * An enumerated class is defined for `attr_NAME' with elements of 25966 the form `UPPER-NAME_UPPER-VALUE' where the attribute name and 25967 value are first converted to uppercase. 25968 25969 * A function `get_attr_NAME' is defined that is passed an insn and 25970 returns the attribute value for that insn. 25971 25972 For example, if the following is present in the `md' file: 25973 25974 (define_attr "type" "branch,fp,load,store,arith" ...) 25975 25976the following lines will be written to the file `insn-attr.h'. 25977 25978 #define HAVE_ATTR_type 1 25979 enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, 25980 TYPE_STORE, TYPE_ARITH}; 25981 extern enum attr_type get_attr_type (); 25982 25983 If the attribute takes numeric values, no `enum' type will be defined 25984and the function to obtain the attribute's value will return `int'. 25985 25986 There are attributes which are tied to a specific meaning. These 25987attributes are not free to use for other purposes: 25988 25989`length' 25990 The `length' attribute is used to calculate the length of emitted 25991 code chunks. This is especially important when verifying branch 25992 distances. *Note Insn Lengths::. 25993 25994`enabled' 25995 The `enabled' attribute can be defined to prevent certain 25996 alternatives of an insn definition from being used during code 25997 generation. *Note Disable Insn Alternatives::. 25998 25999`mnemonic' 26000 The `mnemonic' attribute can be defined to implement instruction 26001 specific checks in e.g. the pipeline description. *Note Mnemonic 26002 Attribute::. 26003 26004 For each of these special attributes, the corresponding 26005`HAVE_ATTR_NAME' `#define' is also written when the attribute is not 26006defined; in that case, it is defined as `0'. 26007 26008 Another way of defining an attribute is to use: 26009 26010 (define_enum_attr "ATTR" "ENUM" DEFAULT) 26011 26012 This works in just the same way as `define_attr', except that the list 26013of values is taken from a separate enumeration called ENUM (*note 26014define_enum::). This form allows you to use the same list of values 26015for several attributes without having to repeat the list each time. 26016For example: 26017 26018 (define_enum "processor" [ 26019 model_a 26020 model_b 26021 ... 26022 ]) 26023 (define_enum_attr "arch" "processor" 26024 (const (symbol_ref "target_arch"))) 26025 (define_enum_attr "tune" "processor" 26026 (const (symbol_ref "target_tune"))) 26027 26028 defines the same attributes as: 26029 26030 (define_attr "arch" "model_a,model_b,..." 26031 (const (symbol_ref "target_arch"))) 26032 (define_attr "tune" "model_a,model_b,..." 26033 (const (symbol_ref "target_tune"))) 26034 26035 but without duplicating the processor list. The second example 26036defines two separate C enums (`attr_arch' and `attr_tune') whereas the 26037first defines a single C enum (`processor'). 26038 26039 26040File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes 26041 2604216.19.2 Attribute Expressions 26043----------------------------- 26044 26045RTL expressions used to define attributes use the codes described above 26046plus a few specific to attribute definitions, to be discussed below. 26047Attribute value expressions must have one of the following forms: 26048 26049`(const_int I)' 26050 The integer I specifies the value of a numeric attribute. I must 26051 be non-negative. 26052 26053 The value of a numeric attribute can be specified either with a 26054 `const_int', or as an integer represented as a string in 26055 `const_string', `eq_attr' (see below), `attr', `symbol_ref', 26056 simple arithmetic expressions, and `set_attr' overrides on 26057 specific instructions (*note Tagging Insns::). 26058 26059`(const_string VALUE)' 26060 The string VALUE specifies a constant attribute value. If VALUE 26061 is specified as `"*"', it means that the default value of the 26062 attribute is to be used for the insn containing this expression. 26063 `"*"' obviously cannot be used in the DEFAULT expression of a 26064 `define_attr'. 26065 26066 If the attribute whose value is being specified is numeric, VALUE 26067 must be a string containing a non-negative integer (normally 26068 `const_int' would be used in this case). Otherwise, it must 26069 contain one of the valid values for the attribute. 26070 26071`(if_then_else TEST TRUE-VALUE FALSE-VALUE)' 26072 TEST specifies an attribute test, whose format is defined below. 26073 The value of this expression is TRUE-VALUE if TEST is true, 26074 otherwise it is FALSE-VALUE. 26075 26076`(cond [TEST1 VALUE1 ...] DEFAULT)' 26077 The first operand of this expression is a vector containing an even 26078 number of expressions and consisting of pairs of TEST and VALUE 26079 expressions. The value of the `cond' expression is that of the 26080 VALUE corresponding to the first true TEST expression. If none of 26081 the TEST expressions are true, the value of the `cond' expression 26082 is that of the DEFAULT expression. 26083 26084 TEST expressions can have one of the following forms: 26085 26086`(const_int I)' 26087 This test is true if I is nonzero and false otherwise. 26088 26089`(not TEST)' 26090`(ior TEST1 TEST2)' 26091`(and TEST1 TEST2)' 26092 These tests are true if the indicated logical function is true. 26093 26094`(match_operand:M N PRED CONSTRAINTS)' 26095 This test is true if operand N of the insn whose attribute value 26096 is being determined has mode M (this part of the test is ignored 26097 if M is `VOIDmode') and the function specified by the string PRED 26098 returns a nonzero value when passed operand N and mode M (this 26099 part of the test is ignored if PRED is the null string). 26100 26101 The CONSTRAINTS operand is ignored and should be the null string. 26102 26103`(match_test C-EXPR)' 26104 The test is true if C expression C-EXPR is true. In non-constant 26105 attributes, C-EXPR has access to the following variables: 26106 26107 INSN 26108 The rtl instruction under test. 26109 26110 WHICH_ALTERNATIVE 26111 The `define_insn' alternative that INSN matches. *Note 26112 Output Statement::. 26113 26114 OPERANDS 26115 An array of INSN's rtl operands. 26116 26117 C-EXPR behaves like the condition in a C `if' statement, so there 26118 is no need to explicitly convert the expression into a boolean 0 26119 or 1 value. For example, the following two tests are equivalent: 26120 26121 (match_test "x & 2") 26122 (match_test "(x & 2) != 0") 26123 26124`(le ARITH1 ARITH2)' 26125`(leu ARITH1 ARITH2)' 26126`(lt ARITH1 ARITH2)' 26127`(ltu ARITH1 ARITH2)' 26128`(gt ARITH1 ARITH2)' 26129`(gtu ARITH1 ARITH2)' 26130`(ge ARITH1 ARITH2)' 26131`(geu ARITH1 ARITH2)' 26132`(ne ARITH1 ARITH2)' 26133`(eq ARITH1 ARITH2)' 26134 These tests are true if the indicated comparison of the two 26135 arithmetic expressions is true. Arithmetic expressions are formed 26136 with `plus', `minus', `mult', `div', `mod', `abs', `neg', `and', 26137 `ior', `xor', `not', `ashift', `lshiftrt', and `ashiftrt' 26138 expressions. 26139 26140 `const_int' and `symbol_ref' are always valid terms (*note Insn 26141 Lengths::,for additional forms). `symbol_ref' is a string 26142 denoting a C expression that yields an `int' when evaluated by the 26143 `get_attr_...' routine. It should normally be a global variable. 26144 26145`(eq_attr NAME VALUE)' 26146 NAME is a string specifying the name of an attribute. 26147 26148 VALUE is a string that is either a valid value for attribute NAME, 26149 a comma-separated list of values, or `!' followed by a value or 26150 list. If VALUE does not begin with a `!', this test is true if 26151 the value of the NAME attribute of the current insn is in the list 26152 specified by VALUE. If VALUE begins with a `!', this test is true 26153 if the attribute's value is _not_ in the specified list. 26154 26155 For example, 26156 26157 (eq_attr "type" "load,store") 26158 26159 is equivalent to 26160 26161 (ior (eq_attr "type" "load") (eq_attr "type" "store")) 26162 26163 If NAME specifies an attribute of `alternative', it refers to the 26164 value of the compiler variable `which_alternative' (*note Output 26165 Statement::) and the values must be small integers. For example, 26166 26167 (eq_attr "alternative" "2,3") 26168 26169 is equivalent to 26170 26171 (ior (eq (symbol_ref "which_alternative") (const_int 2)) 26172 (eq (symbol_ref "which_alternative") (const_int 3))) 26173 26174 Note that, for most attributes, an `eq_attr' test is simplified in 26175 cases where the value of the attribute being tested is known for 26176 all insns matching a particular pattern. This is by far the most 26177 common case. 26178 26179`(attr_flag NAME)' 26180 The value of an `attr_flag' expression is true if the flag 26181 specified by NAME is true for the `insn' currently being scheduled. 26182 26183 NAME is a string specifying one of a fixed set of flags to test. 26184 Test the flags `forward' and `backward' to determine the direction 26185 of a conditional branch. 26186 26187 This example describes a conditional branch delay slot which can 26188 be nullified for forward branches that are taken (annul-true) or 26189 for backward branches which are not taken (annul-false). 26190 26191 (define_delay (eq_attr "type" "cbranch") 26192 [(eq_attr "in_branch_delay" "true") 26193 (and (eq_attr "in_branch_delay" "true") 26194 (attr_flag "forward")) 26195 (and (eq_attr "in_branch_delay" "true") 26196 (attr_flag "backward"))]) 26197 26198 The `forward' and `backward' flags are false if the current `insn' 26199 being scheduled is not a conditional branch. 26200 26201 `attr_flag' is only used during delay slot scheduling and has no 26202 meaning to other passes of the compiler. 26203 26204`(attr NAME)' 26205 The value of another attribute is returned. This is most useful 26206 for numeric attributes, as `eq_attr' and `attr_flag' produce more 26207 efficient code for non-numeric attributes. 26208 26209 26210File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes 26211 2621216.19.3 Assigning Attribute Values to Insns 26213------------------------------------------- 26214 26215The value assigned to an attribute of an insn is primarily determined by 26216which pattern is matched by that insn (or which `define_peephole' 26217generated it). Every `define_insn' and `define_peephole' can have an 26218optional last argument to specify the values of attributes for matching 26219insns. The value of any attribute not specified in a particular insn 26220is set to the default value for that attribute, as specified in its 26221`define_attr'. Extensive use of default values for attributes permits 26222the specification of the values for only one or two attributes in the 26223definition of most insn patterns, as seen in the example in the next 26224section. 26225 26226 The optional last argument of `define_insn' and `define_peephole' is a 26227vector of expressions, each of which defines the value for a single 26228attribute. The most general way of assigning an attribute's value is 26229to use a `set' expression whose first operand is an `attr' expression 26230giving the name of the attribute being set. The second operand of the 26231`set' is an attribute expression (*note Expressions::) giving the value 26232of the attribute. 26233 26234 When the attribute value depends on the `alternative' attribute (i.e., 26235which is the applicable alternative in the constraint of the insn), the 26236`set_attr_alternative' expression can be used. It allows the 26237specification of a vector of attribute expressions, one for each 26238alternative. 26239 26240 When the generality of arbitrary attribute expressions is not required, 26241the simpler `set_attr' expression can be used, which allows specifying 26242a string giving either a single attribute value or a list of attribute 26243values, one for each alternative. 26244 26245 The form of each of the above specifications is shown below. In each 26246case, NAME is a string specifying the attribute to be set. 26247 26248`(set_attr NAME VALUE-STRING)' 26249 VALUE-STRING is either a string giving the desired attribute value, 26250 or a string containing a comma-separated list giving the values for 26251 succeeding alternatives. The number of elements must match the 26252 number of alternatives in the constraint of the insn pattern. 26253 26254 Note that it may be useful to specify `*' for some alternative, in 26255 which case the attribute will assume its default value for insns 26256 matching that alternative. 26257 26258`(set_attr_alternative NAME [VALUE1 VALUE2 ...])' 26259 Depending on the alternative of the insn, the value will be one of 26260 the specified values. This is a shorthand for using a `cond' with 26261 tests on the `alternative' attribute. 26262 26263`(set (attr NAME) VALUE)' 26264 The first operand of this `set' must be the special RTL expression 26265 `attr', whose sole operand is a string giving the name of the 26266 attribute being set. VALUE is the value of the attribute. 26267 26268 The following shows three different ways of representing the same 26269attribute value specification: 26270 26271 (set_attr "type" "load,store,arith") 26272 26273 (set_attr_alternative "type" 26274 [(const_string "load") (const_string "store") 26275 (const_string "arith")]) 26276 26277 (set (attr "type") 26278 (cond [(eq_attr "alternative" "1") (const_string "load") 26279 (eq_attr "alternative" "2") (const_string "store")] 26280 (const_string "arith"))) 26281 26282 The `define_asm_attributes' expression provides a mechanism to specify 26283the attributes assigned to insns produced from an `asm' statement. It 26284has the form: 26285 26286 (define_asm_attributes [ATTR-SETS]) 26287 26288where ATTR-SETS is specified the same as for both the `define_insn' and 26289the `define_peephole' expressions. 26290 26291 These values will typically be the "worst case" attribute values. For 26292example, they might indicate that the condition code will be clobbered. 26293 26294 A specification for a `length' attribute is handled specially. The 26295way to compute the length of an `asm' insn is to multiply the length 26296specified in the expression `define_asm_attributes' by the number of 26297machine instructions specified in the `asm' statement, determined by 26298counting the number of semicolons and newlines in the string. 26299Therefore, the value of the `length' attribute specified in a 26300`define_asm_attributes' should be the maximum possible length of a 26301single machine instruction. 26302 26303 26304File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes 26305 2630616.19.4 Example of Attribute Specifications 26307------------------------------------------- 26308 26309The judicious use of defaulting is important in the efficient use of 26310insn attributes. Typically, insns are divided into "types" and an 26311attribute, customarily called `type', is used to represent this value. 26312This attribute is normally used only to define the default value for 26313other attributes. An example will clarify this usage. 26314 26315 Assume we have a RISC machine with a condition code and in which only 26316full-word operations are performed in registers. Let us assume that we 26317can divide all insns into loads, stores, (integer) arithmetic 26318operations, floating point operations, and branches. 26319 26320 Here we will concern ourselves with determining the effect of an insn 26321on the condition code and will limit ourselves to the following possible 26322effects: The condition code can be set unpredictably (clobbered), not 26323be changed, be set to agree with the results of the operation, or only 26324changed if the item previously set into the condition code has been 26325modified. 26326 26327 Here is part of a sample `md' file for such a machine: 26328 26329 (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) 26330 26331 (define_attr "cc" "clobber,unchanged,set,change0" 26332 (cond [(eq_attr "type" "load") 26333 (const_string "change0") 26334 (eq_attr "type" "store,branch") 26335 (const_string "unchanged") 26336 (eq_attr "type" "arith") 26337 (if_then_else (match_operand:SI 0 "" "") 26338 (const_string "set") 26339 (const_string "clobber"))] 26340 (const_string "clobber"))) 26341 26342 (define_insn "" 26343 [(set (match_operand:SI 0 "general_operand" "=r,r,m") 26344 (match_operand:SI 1 "general_operand" "r,m,r"))] 26345 "" 26346 "@ 26347 move %0,%1 26348 load %0,%1 26349 store %0,%1" 26350 [(set_attr "type" "arith,load,store")]) 26351 26352 Note that we assume in the above example that arithmetic operations 26353performed on quantities smaller than a machine word clobber the 26354condition code since they will set the condition code to a value 26355corresponding to the full-word result. 26356 26357 26358File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes 26359 2636016.19.5 Computing the Length of an Insn 26361--------------------------------------- 26362 26363For many machines, multiple types of branch instructions are provided, 26364each for different length branch displacements. In most cases, the 26365assembler will choose the correct instruction to use. However, when 26366the assembler cannot do so, GCC can when a special attribute, the 26367`length' attribute, is defined. This attribute must be defined to have 26368numeric values by specifying a null string in its `define_attr'. 26369 26370 In the case of the `length' attribute, two additional forms of 26371arithmetic terms are allowed in test expressions: 26372 26373`(match_dup N)' 26374 This refers to the address of operand N of the current insn, which 26375 must be a `label_ref'. 26376 26377`(pc)' 26378 For non-branch instructions and backward branch instructions, this 26379 refers to the address of the current insn. But for forward branch 26380 instructions, this refers to the address of the next insn, because 26381 the length of the current insn is to be computed. 26382 26383 For normal insns, the length will be determined by value of the 26384`length' attribute. In the case of `addr_vec' and `addr_diff_vec' insn 26385patterns, the length is computed as the number of vectors multiplied by 26386the size of each vector. 26387 26388 Lengths are measured in addressable storage units (bytes). 26389 26390 Note that it is possible to call functions via the `symbol_ref' 26391mechanism to compute the length of an insn. However, if you use this 26392mechanism you must provide dummy clauses to express the maximum length 26393without using the function call. You can an example of this in the 26394`pa' machine description for the `call_symref' pattern. 26395 26396 The following macros can be used to refine the length computation: 26397 26398`ADJUST_INSN_LENGTH (INSN, LENGTH)' 26399 If defined, modifies the length assigned to instruction INSN as a 26400 function of the context in which it is used. LENGTH is an lvalue 26401 that contains the initially computed length of the insn and should 26402 be updated with the correct length of the insn. 26403 26404 This macro will normally not be required. A case in which it is 26405 required is the ROMP. On this machine, the size of an `addr_vec' 26406 insn must be increased by two to compensate for the fact that 26407 alignment may be required. 26408 26409 The routine that returns `get_attr_length' (the value of the `length' 26410attribute) can be used by the output routine to determine the form of 26411the branch instruction to be written, as the example below illustrates. 26412 26413 As an example of the specification of variable-length branches, 26414consider the IBM 360. If we adopt the convention that a register will 26415be set to the starting address of a function, we can jump to labels 26416within 4k of the start using a four-byte instruction. Otherwise, we 26417need a six-byte sequence to load the address from memory and then 26418branch to it. 26419 26420 On such a machine, a pattern for a branch instruction might be 26421specified as follows: 26422 26423 (define_insn "jump" 26424 [(set (pc) 26425 (label_ref (match_operand 0 "" "")))] 26426 "" 26427 { 26428 return (get_attr_length (insn) == 4 26429 ? "b %l0" : "l r15,=a(%l0); br r15"); 26430 } 26431 [(set (attr "length") 26432 (if_then_else (lt (match_dup 0) (const_int 4096)) 26433 (const_int 4) 26434 (const_int 6)))]) 26435 26436 26437File: gccint.info, Node: Constant Attributes, Next: Mnemonic Attribute, Prev: Insn Lengths, Up: Insn Attributes 26438 2643916.19.6 Constant Attributes 26440--------------------------- 26441 26442A special form of `define_attr', where the expression for the default 26443value is a `const' expression, indicates an attribute that is constant 26444for a given run of the compiler. Constant attributes may be used to 26445specify which variety of processor is used. For example, 26446 26447 (define_attr "cpu" "m88100,m88110,m88000" 26448 (const 26449 (cond [(symbol_ref "TARGET_88100") (const_string "m88100") 26450 (symbol_ref "TARGET_88110") (const_string "m88110")] 26451 (const_string "m88000")))) 26452 26453 (define_attr "memory" "fast,slow" 26454 (const 26455 (if_then_else (symbol_ref "TARGET_FAST_MEM") 26456 (const_string "fast") 26457 (const_string "slow")))) 26458 26459 The routine generated for constant attributes has no parameters as it 26460does not depend on any particular insn. RTL expressions used to define 26461the value of a constant attribute may use the `symbol_ref' form, but 26462may not use either the `match_operand' form or `eq_attr' forms 26463involving insn attributes. 26464 26465 26466File: gccint.info, Node: Mnemonic Attribute, Next: Delay Slots, Prev: Constant Attributes, Up: Insn Attributes 26467 2646816.19.7 Mnemonic Attribute 26469-------------------------- 26470 26471The `mnemonic' attribute is a string type attribute holding the 26472instruction mnemonic for an insn alternative. The attribute values 26473will automatically be generated by the machine description parser if 26474there is an attribute definition in the md file: 26475 26476 (define_attr "mnemonic" "unknown" (const_string "unknown")) 26477 26478 The default value can be freely chosen as long as it does not collide 26479with any of the instruction mnemonics. This value will be used 26480whenever the machine description parser is not able to determine the 26481mnemonic string. This might be the case for output templates 26482containing more than a single instruction as in 26483`"mvcle\t%0,%1,0\;jo\t.-4"'. 26484 26485 The `mnemonic' attribute set is not generated automatically if the 26486instruction string is generated via C code. 26487 26488 An existing `mnemonic' attribute set in an insn definition will not be 26489overriden by the md file parser. That way it is possible to manually 26490set the instruction mnemonics for the cases where the md file parser 26491fails to determine it automatically. 26492 26493 The `mnemonic' attribute is useful for dealing with instruction 26494specific properties in the pipeline description without defining 26495additional insn attributes. 26496 26497 (define_attr "ooo_expanded" "" 26498 (cond [(eq_attr "mnemonic" "dlr,dsgr,d,dsgf,stam,dsgfr,dlgr") 26499 (const_int 1)] 26500 (const_int 0))) 26501 26502 26503File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Mnemonic Attribute, Up: Insn Attributes 26504 2650516.19.8 Delay Slot Scheduling 26506----------------------------- 26507 26508The insn attribute mechanism can be used to specify the requirements for 26509delay slots, if any, on a target machine. An instruction is said to 26510require a "delay slot" if some instructions that are physically after 26511the instruction are executed as if they were located before it. 26512Classic examples are branch and call instructions, which often execute 26513the following instruction before the branch or call is performed. 26514 26515 On some machines, conditional branch instructions can optionally 26516"annul" instructions in the delay slot. This means that the 26517instruction will not be executed for certain branch outcomes. Both 26518instructions that annul if the branch is true and instructions that 26519annul if the branch is false are supported. 26520 26521 Delay slot scheduling differs from instruction scheduling in that 26522determining whether an instruction needs a delay slot is dependent only 26523on the type of instruction being generated, not on data flow between the 26524instructions. See the next section for a discussion of data-dependent 26525instruction scheduling. 26526 26527 The requirement of an insn needing one or more delay slots is indicated 26528via the `define_delay' expression. It has the following form: 26529 26530 (define_delay TEST 26531 [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 26532 DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 26533 ...]) 26534 26535 TEST is an attribute test that indicates whether this `define_delay' 26536applies to a particular insn. If so, the number of required delay 26537slots is determined by the length of the vector specified as the second 26538argument. An insn placed in delay slot N must satisfy attribute test 26539DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns 26540may be annulled if the branch is true. Similarly, ANNUL-FALSE-N 26541specifies which insns in the delay slot may be annulled if the branch 26542is false. If annulling is not supported for that delay slot, `(nil)' 26543should be coded. 26544 26545 For example, in the common case where branch and call insns require a 26546single delay slot, which may contain any insn other than a branch or 26547call, the following would be placed in the `md' file: 26548 26549 (define_delay (eq_attr "type" "branch,call") 26550 [(eq_attr "type" "!branch,call") (nil) (nil)]) 26551 26552 Multiple `define_delay' expressions may be specified. In this case, 26553each such expression specifies different delay slot requirements and 26554there must be no insn for which tests in two `define_delay' expressions 26555are both true. 26556 26557 For example, if we have a machine that requires one delay slot for 26558branches but two for calls, no delay slot can contain a branch or call 26559insn, and any valid insn in the delay slot for the branch can be 26560annulled if the branch is true, we might represent this as follows: 26561 26562 (define_delay (eq_attr "type" "branch") 26563 [(eq_attr "type" "!branch,call") 26564 (eq_attr "type" "!branch,call") 26565 (nil)]) 26566 26567 (define_delay (eq_attr "type" "call") 26568 [(eq_attr "type" "!branch,call") (nil) (nil) 26569 (eq_attr "type" "!branch,call") (nil) (nil)]) 26570 26571 26572File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes 26573 2657416.19.9 Specifying processor pipeline description 26575------------------------------------------------- 26576 26577To achieve better performance, most modern processors (super-pipelined, 26578superscalar RISC, and VLIW processors) have many "functional units" on 26579which several instructions can be executed simultaneously. An 26580instruction starts execution if its issue conditions are satisfied. If 26581not, the instruction is stalled until its conditions are satisfied. 26582Such "interlock (pipeline) delay" causes interruption of the fetching 26583of successor instructions (or demands nop instructions, e.g. for some 26584MIPS processors). 26585 26586 There are two major kinds of interlock delays in modern processors. 26587The first one is a data dependence delay determining "instruction 26588latency time". The instruction execution is not started until all 26589source data have been evaluated by prior instructions (there are more 26590complex cases when the instruction execution starts even when the data 26591are not available but will be ready in given time after the instruction 26592execution start). Taking the data dependence delays into account is 26593simple. The data dependence (true, output, and anti-dependence) delay 26594between two instructions is given by a constant. In most cases this 26595approach is adequate. The second kind of interlock delays is a 26596reservation delay. The reservation delay means that two instructions 26597under execution will be in need of shared processors resources, i.e. 26598buses, internal registers, and/or functional units, which are reserved 26599for some time. Taking this kind of delay into account is complex 26600especially for modern RISC processors. 26601 26602 The task of exploiting more processor parallelism is solved by an 26603instruction scheduler. For a better solution to this problem, the 26604instruction scheduler has to have an adequate description of the 26605processor parallelism (or "pipeline description"). GCC machine 26606descriptions describe processor parallelism and functional unit 26607reservations for groups of instructions with the aid of "regular 26608expressions". 26609 26610 The GCC instruction scheduler uses a "pipeline hazard recognizer" to 26611figure out the possibility of the instruction issue by the processor on 26612a given simulated processor cycle. The pipeline hazard recognizer is 26613automatically generated from the processor pipeline description. The 26614pipeline hazard recognizer generated from the machine description is 26615based on a deterministic finite state automaton (DFA): the instruction 26616issue is possible if there is a transition from one automaton state to 26617another one. This algorithm is very fast, and furthermore, its speed 26618is not dependent on processor complexity(1). 26619 26620 The rest of this section describes the directives that constitute an 26621automaton-based processor pipeline description. The order of these 26622constructions within the machine description file is not important. 26623 26624 The following optional construction describes names of automata 26625generated and used for the pipeline hazards recognition. Sometimes the 26626generated finite state automaton used by the pipeline hazard recognizer 26627is large. If we use more than one automaton and bind functional units 26628to the automata, the total size of the automata is usually less than 26629the size of the single automaton. If there is no one such 26630construction, only one finite state automaton is generated. 26631 26632 (define_automaton AUTOMATA-NAMES) 26633 26634 AUTOMATA-NAMES is a string giving names of the automata. The names 26635are separated by commas. All the automata should have unique names. 26636The automaton name is used in the constructions `define_cpu_unit' and 26637`define_query_cpu_unit'. 26638 26639 Each processor functional unit used in the description of instruction 26640reservations should be described by the following construction. 26641 26642 (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 26643 26644 UNIT-NAMES is a string giving the names of the functional units 26645separated by commas. Don't use name `nothing', it is reserved for 26646other goals. 26647 26648 AUTOMATON-NAME is a string giving the name of the automaton with which 26649the unit is bound. The automaton should be described in construction 26650`define_automaton'. You should give "automaton-name", if there is a 26651defined automaton. 26652 26653 The assignment of units to automata are constrained by the uses of the 26654units in insn reservations. The most important constraint is: if a 26655unit reservation is present on a particular cycle of an alternative for 26656an insn reservation, then some unit from the same automaton must be 26657present on the same cycle for the other alternatives of the insn 26658reservation. The rest of the constraints are mentioned in the 26659description of the subsequent constructions. 26660 26661 The following construction describes CPU functional units analogously 26662to `define_cpu_unit'. The reservation of such units can be queried for 26663an automaton state. The instruction scheduler never queries 26664reservation of functional units for given automaton state. So as a 26665rule, you don't need this construction. This construction could be 26666used for future code generation goals (e.g. to generate VLIW insn 26667templates). 26668 26669 (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME]) 26670 26671 UNIT-NAMES is a string giving names of the functional units separated 26672by commas. 26673 26674 AUTOMATON-NAME is a string giving the name of the automaton with which 26675the unit is bound. 26676 26677 The following construction is the major one to describe pipeline 26678characteristics of an instruction. 26679 26680 (define_insn_reservation INSN-NAME DEFAULT_LATENCY 26681 CONDITION REGEXP) 26682 26683 DEFAULT_LATENCY is a number giving latency time of the instruction. 26684There is an important difference between the old description and the 26685automaton based pipeline description. The latency time is used for all 26686dependencies when we use the old description. In the automaton based 26687pipeline description, the given latency time is only used for true 26688dependencies. The cost of anti-dependencies is always zero and the 26689cost of output dependencies is the difference between latency times of 26690the producing and consuming insns (if the difference is negative, the 26691cost is considered to be zero). You can always change the default 26692costs for any description by using the target hook 26693`TARGET_SCHED_ADJUST_COST' (*note Scheduling::). 26694 26695 INSN-NAME is a string giving the internal name of the insn. The 26696internal names are used in constructions `define_bypass' and in the 26697automaton description file generated for debugging. The internal name 26698has nothing in common with the names in `define_insn'. It is a good 26699practice to use insn classes described in the processor manual. 26700 26701 CONDITION defines what RTL insns are described by this construction. 26702You should remember that you will be in trouble if CONDITION for two or 26703more different `define_insn_reservation' constructions is TRUE for an 26704insn. In this case what reservation will be used for the insn is not 26705defined. Such cases are not checked during generation of the pipeline 26706hazards recognizer because in general recognizing that two conditions 26707may have the same value is quite difficult (especially if the conditions 26708contain `symbol_ref'). It is also not checked during the pipeline 26709hazard recognizer work because it would slow down the recognizer 26710considerably. 26711 26712 REGEXP is a string describing the reservation of the cpu's functional 26713units by the instruction. The reservations are described by a regular 26714expression according to the following syntax: 26715 26716 regexp = regexp "," oneof 26717 | oneof 26718 26719 oneof = oneof "|" allof 26720 | allof 26721 26722 allof = allof "+" repeat 26723 | repeat 26724 26725 repeat = element "*" number 26726 | element 26727 26728 element = cpu_function_unit_name 26729 | reservation_name 26730 | result_name 26731 | "nothing" 26732 | "(" regexp ")" 26733 26734 * `,' is used for describing the start of the next cycle in the 26735 reservation. 26736 26737 * `|' is used for describing a reservation described by the first 26738 regular expression *or* a reservation described by the second 26739 regular expression *or* etc. 26740 26741 * `+' is used for describing a reservation described by the first 26742 regular expression *and* a reservation described by the second 26743 regular expression *and* etc. 26744 26745 * `*' is used for convenience and simply means a sequence in which 26746 the regular expression are repeated NUMBER times with cycle 26747 advancing (see `,'). 26748 26749 * `cpu_function_unit_name' denotes reservation of the named 26750 functional unit. 26751 26752 * `reservation_name' -- see description of construction 26753 `define_reservation'. 26754 26755 * `nothing' denotes no unit reservations. 26756 26757 Sometimes unit reservations for different insns contain common parts. 26758In such case, you can simplify the pipeline description by describing 26759the common part by the following construction 26760 26761 (define_reservation RESERVATION-NAME REGEXP) 26762 26763 RESERVATION-NAME is a string giving name of REGEXP. Functional unit 26764names and reservation names are in the same name space. So the 26765reservation names should be different from the functional unit names 26766and can not be the reserved name `nothing'. 26767 26768 The following construction is used to describe exceptions in the 26769latency time for given instruction pair. This is so called bypasses. 26770 26771 (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES 26772 [GUARD]) 26773 26774 NUMBER defines when the result generated by the instructions given in 26775string OUT_INSN_NAMES will be ready for the instructions given in 26776string IN_INSN_NAMES. Each of these strings is a comma-separated list 26777of filename-style globs and they refer to the names of 26778`define_insn_reservation's. For example: 26779 (define_bypass 1 "cpu1_load_*, cpu1_store_*" "cpu1_load_*") 26780 defines a bypass between instructions that start with `cpu1_load_' or 26781`cpu1_store_' and those that start with `cpu1_load_'. 26782 26783 GUARD is an optional string giving the name of a C function which 26784defines an additional guard for the bypass. The function will get the 26785two insns as parameters. If the function returns zero the bypass will 26786be ignored for this case. The additional guard is necessary to 26787recognize complicated bypasses, e.g. when the consumer is only an 26788address of insn `store' (not a stored value). 26789 26790 If there are more one bypass with the same output and input insns, the 26791chosen bypass is the first bypass with a guard in description whose 26792guard function returns nonzero. If there is no such bypass, then 26793bypass without the guard function is chosen. 26794 26795 The following five constructions are usually used to describe VLIW 26796processors, or more precisely, to describe a placement of small 26797instructions into VLIW instruction slots. They can be used for RISC 26798processors, too. 26799 26800 (exclusion_set UNIT-NAMES UNIT-NAMES) 26801 (presence_set UNIT-NAMES PATTERNS) 26802 (final_presence_set UNIT-NAMES PATTERNS) 26803 (absence_set UNIT-NAMES PATTERNS) 26804 (final_absence_set UNIT-NAMES PATTERNS) 26805 26806 UNIT-NAMES is a string giving names of functional units separated by 26807commas. 26808 26809 PATTERNS is a string giving patterns of functional units separated by 26810comma. Currently pattern is one unit or units separated by 26811white-spaces. 26812 26813 The first construction (`exclusion_set') means that each functional 26814unit in the first string can not be reserved simultaneously with a unit 26815whose name is in the second string and vice versa. For example, the 26816construction is useful for describing processors (e.g. some SPARC 26817processors) with a fully pipelined floating point functional unit which 26818can execute simultaneously only single floating point insns or only 26819double floating point insns. 26820 26821 The second construction (`presence_set') means that each functional 26822unit in the first string can not be reserved unless at least one of 26823pattern of units whose names are in the second string is reserved. 26824This is an asymmetric relation. For example, it is useful for 26825description that VLIW `slot1' is reserved after `slot0' reservation. 26826We could describe it by the following construction 26827 26828 (presence_set "slot1" "slot0") 26829 26830 Or `slot1' is reserved only after `slot0' and unit `b0' reservation. 26831In this case we could write 26832 26833 (presence_set "slot1" "slot0 b0") 26834 26835 The third construction (`final_presence_set') is analogous to 26836`presence_set'. The difference between them is when checking is done. 26837When an instruction is issued in given automaton state reflecting all 26838current and planned unit reservations, the automaton state is changed. 26839The first state is a source state, the second one is a result state. 26840Checking for `presence_set' is done on the source state reservation, 26841checking for `final_presence_set' is done on the result reservation. 26842This construction is useful to describe a reservation which is actually 26843two subsequent reservations. For example, if we use 26844 26845 (presence_set "slot1" "slot0") 26846 26847 the following insn will be never issued (because `slot1' requires 26848`slot0' which is absent in the source state). 26849 26850 (define_reservation "insn_and_nop" "slot0 + slot1") 26851 26852 but it can be issued if we use analogous `final_presence_set'. 26853 26854 The forth construction (`absence_set') means that each functional unit 26855in the first string can be reserved only if each pattern of units whose 26856names are in the second string is not reserved. This is an asymmetric 26857relation (actually `exclusion_set' is analogous to this one but it is 26858symmetric). For example it might be useful in a VLIW description to 26859say that `slot0' cannot be reserved after either `slot1' or `slot2' 26860have been reserved. This can be described as: 26861 26862 (absence_set "slot0" "slot1, slot2") 26863 26864 Or `slot2' can not be reserved if `slot0' and unit `b0' are reserved 26865or `slot1' and unit `b1' are reserved. In this case we could write 26866 26867 (absence_set "slot2" "slot0 b0, slot1 b1") 26868 26869 All functional units mentioned in a set should belong to the same 26870automaton. 26871 26872 The last construction (`final_absence_set') is analogous to 26873`absence_set' but checking is done on the result (state) reservation. 26874See comments for `final_presence_set'. 26875 26876 You can control the generator of the pipeline hazard recognizer with 26877the following construction. 26878 26879 (automata_option OPTIONS) 26880 26881 OPTIONS is a string giving options which affect the generated code. 26882Currently there are the following options: 26883 26884 * "no-minimization" makes no minimization of the automaton. This is 26885 only worth to do when we are debugging the description and need to 26886 look more accurately at reservations of states. 26887 26888 * "time" means printing time statistics about the generation of 26889 automata. 26890 26891 * "stats" means printing statistics about the generated automata 26892 such as the number of DFA states, NDFA states and arcs. 26893 26894 * "v" means a generation of the file describing the result automata. 26895 The file has suffix `.dfa' and can be used for the description 26896 verification and debugging. 26897 26898 * "w" means a generation of warning instead of error for 26899 non-critical errors. 26900 26901 * "no-comb-vect" prevents the automaton generator from generating 26902 two data structures and comparing them for space efficiency. Using 26903 a comb vector to represent transitions may be better, but it can be 26904 very expensive to construct. This option is useful if the build 26905 process spends an unacceptably long time in genautomata. 26906 26907 * "ndfa" makes nondeterministic finite state automata. This affects 26908 the treatment of operator `|' in the regular expressions. The 26909 usual treatment of the operator is to try the first alternative 26910 and, if the reservation is not possible, the second alternative. 26911 The nondeterministic treatment means trying all alternatives, some 26912 of them may be rejected by reservations in the subsequent insns. 26913 26914 * "collapse-ndfa" modifies the behaviour of the generator when 26915 producing an automaton. An additional state transition to 26916 collapse a nondeterministic NDFA state to a deterministic DFA 26917 state is generated. It can be triggered by passing `const0_rtx' to 26918 state_transition. In such an automaton, cycle advance transitions 26919 are available only for these collapsed states. This option is 26920 useful for ports that want to use the `ndfa' option, but also want 26921 to use `define_query_cpu_unit' to assign units to insns issued in 26922 a cycle. 26923 26924 * "progress" means output of a progress bar showing how many states 26925 were generated so far for automaton being processed. This is 26926 useful during debugging a DFA description. If you see too many 26927 generated states, you could interrupt the generator of the pipeline 26928 hazard recognizer and try to figure out a reason for generation of 26929 the huge automaton. 26930 26931 As an example, consider a superscalar RISC machine which can issue 26932three insns (two integer insns and one floating point insn) on the 26933cycle but can finish only two insns. To describe this, we define the 26934following functional units. 26935 26936 (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline") 26937 (define_cpu_unit "port0, port1") 26938 26939 All simple integer insns can be executed in any integer pipeline and 26940their result is ready in two cycles. The simple integer insns are 26941issued into the first pipeline unless it is reserved, otherwise they 26942are issued into the second pipeline. Integer division and 26943multiplication insns can be executed only in the second integer 26944pipeline and their results are ready correspondingly in 8 and 4 cycles. 26945The integer division is not pipelined, i.e. the subsequent integer 26946division insn can not be issued until the current division insn 26947finished. Floating point insns are fully pipelined and their results 26948are ready in 3 cycles. Where the result of a floating point insn is 26949used by an integer insn, an additional delay of one cycle is incurred. 26950To describe all of this we could specify 26951 26952 (define_cpu_unit "div") 26953 26954 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 26955 "(i0_pipeline | i1_pipeline), (port0 | port1)") 26956 26957 (define_insn_reservation "mult" 4 (eq_attr "type" "mult") 26958 "i1_pipeline, nothing*2, (port0 | port1)") 26959 26960 (define_insn_reservation "div" 8 (eq_attr "type" "div") 26961 "i1_pipeline, div*7, div + (port0 | port1)") 26962 26963 (define_insn_reservation "float" 3 (eq_attr "type" "float") 26964 "f_pipeline, nothing, (port0 | port1)) 26965 26966 (define_bypass 4 "float" "simple,mult,div") 26967 26968 To simplify the description we could describe the following reservation 26969 26970 (define_reservation "finish" "port0|port1") 26971 26972 and use it in all `define_insn_reservation' as in the following 26973construction 26974 26975 (define_insn_reservation "simple" 2 (eq_attr "type" "int") 26976 "(i0_pipeline | i1_pipeline), finish") 26977 26978 ---------- Footnotes ---------- 26979 26980 (1) However, the size of the automaton depends on processor 26981complexity. To limit this effect, machine descriptions can split 26982orthogonal parts of the machine description among several automata: but 26983then, since each of these must be stepped independently, this does 26984cause a small decrease in the algorithm's performance. 26985 26986 26987File: gccint.info, Node: Conditional Execution, Next: Define Subst, Prev: Insn Attributes, Up: Machine Desc 26988 2698916.20 Conditional Execution 26990=========================== 26991 26992A number of architectures provide for some form of conditional 26993execution, or predication. The hallmark of this feature is the ability 26994to nullify most of the instructions in the instruction set. When the 26995instruction set is large and not entirely symmetric, it can be quite 26996tedious to describe these forms directly in the `.md' file. An 26997alternative is the `define_cond_exec' template. 26998 26999 (define_cond_exec 27000 [PREDICATE-PATTERN] 27001 "CONDITION" 27002 "OUTPUT-TEMPLATE" 27003 "OPTIONAL-INSN-ATTRIBUES") 27004 27005 PREDICATE-PATTERN is the condition that must be true for the insn to 27006be executed at runtime and should match a relational operator. One can 27007use `match_operator' to match several relational operators at once. 27008Any `match_operand' operands must have no more than one alternative. 27009 27010 CONDITION is a C expression that must be true for the generated 27011pattern to match. 27012 27013 OUTPUT-TEMPLATE is a string similar to the `define_insn' output 27014template (*note Output Template::), except that the `*' and `@' special 27015cases do not apply. This is only useful if the assembly text for the 27016predicate is a simple prefix to the main insn. In order to handle the 27017general case, there is a global variable `current_insn_predicate' that 27018will contain the entire predicate if the current insn is predicated, 27019and will otherwise be `NULL'. 27020 27021 OPTIONAL-INSN-ATTRIBUTES is an optional vector of attributes that gets 27022appended to the insn attributes of the produced cond_exec rtx. It can 27023be used to add some distinguishing attribute to cond_exec rtxs produced 27024that way. An example usage would be to use this attribute in conjunction 27025with attributes on the main pattern to disable particular alternatives 27026under certain conditions. 27027 27028 When `define_cond_exec' is used, an implicit reference to the 27029`predicable' instruction attribute is made. *Note Insn Attributes::. 27030This attribute must be a boolean (i.e. have exactly two elements in its 27031LIST-OF-VALUES), with the possible values being `no' and `yes'. The 27032default and all uses in the insns must be a simple constant, not a 27033complex expressions. It may, however, depend on the alternative, by 27034using a comma-separated list of values. If that is the case, the port 27035should also define an `enabled' attribute (*note Disable Insn 27036Alternatives::), which should also allow only `no' and `yes' as its 27037values. 27038 27039 For each `define_insn' for which the `predicable' attribute is true, a 27040new `define_insn' pattern will be generated that matches a predicated 27041version of the instruction. For example, 27042 27043 (define_insn "addsi" 27044 [(set (match_operand:SI 0 "register_operand" "r") 27045 (plus:SI (match_operand:SI 1 "register_operand" "r") 27046 (match_operand:SI 2 "register_operand" "r")))] 27047 "TEST1" 27048 "add %2,%1,%0") 27049 27050 (define_cond_exec 27051 [(ne (match_operand:CC 0 "register_operand" "c") 27052 (const_int 0))] 27053 "TEST2" 27054 "(%0)") 27055 27056generates a new pattern 27057 27058 (define_insn "" 27059 [(cond_exec 27060 (ne (match_operand:CC 3 "register_operand" "c") (const_int 0)) 27061 (set (match_operand:SI 0 "register_operand" "r") 27062 (plus:SI (match_operand:SI 1 "register_operand" "r") 27063 (match_operand:SI 2 "register_operand" "r"))))] 27064 "(TEST2) && (TEST1)" 27065 "(%3) add %2,%1,%0") 27066 27067 27068File: gccint.info, Node: Define Subst, Next: Constant Definitions, Prev: Conditional Execution, Up: Machine Desc 27069 2707016.21 RTL Templates Transformations 27071=================================== 27072 27073For some hardware architectures there are common cases when the RTL 27074templates for the instructions can be derived from the other RTL 27075templates using simple transformations. E.g., `i386.md' contains an 27076RTL template for the ordinary `sub' instruction-- `*subsi_1', and for 27077the `sub' instruction with subsequent zero-extension--`*subsi_1_zext'. 27078Such cases can be easily implemented by a single meta-template capable 27079of generating a modified case based on the initial one: 27080 27081 (define_subst "NAME" 27082 [INPUT-TEMPLATE] 27083 "CONDITION" 27084 [OUTPUT-TEMPLATE]) 27085 INPUT-TEMPLATE is a pattern describing the source RTL template, which 27086will be transformed. 27087 27088 CONDITION is a C expression that is conjunct with the condition from 27089the input-template to generate a condition to be used in the 27090output-template. 27091 27092 OUTPUT-TEMPLATE is a pattern that will be used in the resulting 27093template. 27094 27095 `define_subst' mechanism is tightly coupled with the notion of the 27096subst attribute (*note Subst Iterators::). The use of `define_subst' 27097is triggered by a reference to a subst attribute in the transforming 27098RTL template. This reference initiates duplication of the source RTL 27099template and substitution of the attributes with their values. The 27100source RTL template is left unchanged, while the copy is transformed by 27101`define_subst'. This transformation can fail in the case when the 27102source RTL template is not matched against the input-template of the 27103`define_subst'. In such case the copy is deleted. 27104 27105 `define_subst' can be used only in `define_insn' and `define_expand', 27106it cannot be used in other expressions (e.g. in 27107`define_insn_and_split'). 27108 27109* Menu: 27110 27111* Define Subst Example:: Example of `define_subst' work. 27112* Define Subst Pattern Matching:: Process of template comparison. 27113* Define Subst Output Template:: Generation of output template. 27114 27115 27116File: gccint.info, Node: Define Subst Example, Next: Define Subst Pattern Matching, Up: Define Subst 27117 2711816.21.1 `define_subst' Example 27119------------------------------ 27120 27121To illustrate how `define_subst' works, let us examine a simple 27122template transformation. 27123 27124 Suppose there are two kinds of instructions: one that touches flags and 27125the other that does not. The instructions of the second type could be 27126generated with the following `define_subst': 27127 27128 (define_subst "add_clobber_subst" 27129 [(set (match_operand:SI 0 "" "") 27130 (match_operand:SI 1 "" ""))] 27131 "" 27132 [(set (match_dup 0) 27133 (match_dup 1)) 27134 (clobber (reg:CC FLAGS_REG))] 27135 27136 This `define_subst' can be applied to any RTL pattern containing `set' 27137of mode SI and generates a copy with clobber when it is applied. 27138 27139 Assume there is an RTL template for a `max' instruction to be used in 27140`define_subst' mentioned above: 27141 27142 (define_insn "maxsi" 27143 [(set (match_operand:SI 0 "register_operand" "=r") 27144 (max:SI 27145 (match_operand:SI 1 "register_operand" "r") 27146 (match_operand:SI 2 "register_operand" "r")))] 27147 "" 27148 "max\t{%2, %1, %0|%0, %1, %2}" 27149 [...]) 27150 27151 To mark the RTL template for `define_subst' application, 27152subst-attributes are used. They should be declared in advance: 27153 27154 (define_subst_attr "add_clobber_name" "add_clobber_subst" "_noclobber" "_clobber") 27155 27156 Here `add_clobber_name' is the attribute name, `add_clobber_subst' is 27157the name of the corresponding `define_subst', the third argument 27158(`_noclobber') is the attribute value that would be substituted into 27159the unchanged version of the source RTL template, and the last argument 27160(`_clobber') is the value that would be substituted into the second, 27161transformed, version of the RTL template. 27162 27163 Once the subst-attribute has been defined, it should be used in RTL 27164templates which need to be processed by the `define_subst'. So, the 27165original RTL template should be changed: 27166 27167 (define_insn "maxsi<add_clobber_name>" 27168 [(set (match_operand:SI 0 "register_operand" "=r") 27169 (max:SI 27170 (match_operand:SI 1 "register_operand" "r") 27171 (match_operand:SI 2 "register_operand" "r")))] 27172 "" 27173 "max\t{%2, %1, %0|%0, %1, %2}" 27174 [...]) 27175 27176 The result of the `define_subst' usage would look like the following: 27177 27178 (define_insn "maxsi_noclobber" 27179 [(set (match_operand:SI 0 "register_operand" "=r") 27180 (max:SI 27181 (match_operand:SI 1 "register_operand" "r") 27182 (match_operand:SI 2 "register_operand" "r")))] 27183 "" 27184 "max\t{%2, %1, %0|%0, %1, %2}" 27185 [...]) 27186 (define_insn "maxsi_clobber" 27187 [(set (match_operand:SI 0 "register_operand" "=r") 27188 (max:SI 27189 (match_operand:SI 1 "register_operand" "r") 27190 (match_operand:SI 2 "register_operand" "r"))) 27191 (clobber (reg:CC FLAGS_REG))] 27192 "" 27193 "max\t{%2, %1, %0|%0, %1, %2}" 27194 [...]) 27195 27196 27197File: gccint.info, Node: Define Subst Pattern Matching, Next: Define Subst Output Template, Prev: Define Subst Example, Up: Define Subst 27198 2719916.21.2 Pattern Matching in `define_subst' 27200------------------------------------------ 27201 27202All expressions, allowed in `define_insn' or `define_expand', are 27203allowed in the input-template of `define_subst', except 27204`match_par_dup', `match_scratch', `match_parallel'. The meanings of 27205expressions in the input-template were changed: 27206 27207 `match_operand' matches any expression (possibly, a subtree in 27208RTL-template), if modes of the `match_operand' and this expression are 27209the same, or mode of the `match_operand' is `VOIDmode', or this 27210expression is `match_dup', `match_op_dup'. If the expression is 27211`match_operand' too, and predicate of `match_operand' from the input 27212pattern is not empty, then the predicates are compared. That can be 27213used for more accurate filtering of accepted RTL-templates. 27214 27215 `match_operator' matches common operators (like `plus', `minus'), 27216`unspec', `unspec_volatile' operators and `match_operator's from the 27217original pattern if the modes match and `match_operator' from the input 27218pattern has the same number of operands as the operator from the 27219original pattern. 27220 27221 27222File: gccint.info, Node: Define Subst Output Template, Prev: Define Subst Pattern Matching, Up: Define Subst 27223 2722416.21.3 Generation of output template in `define_subst' 27225------------------------------------------------------- 27226 27227If all necessary checks for `define_subst' application pass, a new 27228RTL-pattern, based on the output-template, is created to replace the old 27229template. Like in input-patterns, meanings of some RTL expressions are 27230changed when they are used in output-patterns of a `define_subst'. 27231Thus, `match_dup' is used for copying the whole expression from the 27232original pattern, which matched corresponding `match_operand' from the 27233input pattern. 27234 27235 `match_dup N' is used in the output template to be replaced with the 27236expression from the original pattern, which matched `match_operand N' 27237from the input pattern. As a consequence, `match_dup' cannot be used 27238to point to `match_operand's from the output pattern, it should always 27239refer to a `match_operand' from the input pattern. 27240 27241 In the output template one can refer to the expressions from the 27242original pattern and create new ones. For instance, some operands could 27243be added by means of standard `match_operand'. 27244 27245 After replacing `match_dup' with some RTL-subtree from the original 27246pattern, it could happen that several `match_operand's in the output 27247pattern have the same indexes. It is unknown, how many and what 27248indexes would be used in the expression which would replace 27249`match_dup', so such conflicts in indexes are inevitable. To overcome 27250this issue, `match_operands' and `match_operators', which were 27251introduced into the output pattern, are renumerated when all 27252`match_dup's are replaced. 27253 27254 Number of alternatives in `match_operand's introduced into the output 27255template `M' could differ from the number of alternatives in the 27256original pattern `N', so in the resultant pattern there would be `N*M' 27257alternatives. Thus, constraints from the original pattern would be 27258duplicated `N' times, constraints from the output pattern would be 27259duplicated `M' times, producing all possible combinations. 27260 27261 27262File: gccint.info, Node: Constant Definitions, Next: Iterators, Prev: Define Subst, Up: Machine Desc 27263 2726416.22 Constant Definitions 27265========================== 27266 27267Using literal constants inside instruction patterns reduces legibility 27268and can be a maintenance problem. 27269 27270 To overcome this problem, you may use the `define_constants' 27271expression. It contains a vector of name-value pairs. From that point 27272on, wherever any of the names appears in the MD file, it is as if the 27273corresponding value had been written instead. You may use 27274`define_constants' multiple times; each appearance adds more constants 27275to the table. It is an error to redefine a constant with a different 27276value. 27277 27278 To come back to the a29k load multiple example, instead of 27279 27280 (define_insn "" 27281 [(match_parallel 0 "load_multiple_operation" 27282 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 27283 (match_operand:SI 2 "memory_operand" "m")) 27284 (use (reg:SI 179)) 27285 (clobber (reg:SI 179))])] 27286 "" 27287 "loadm 0,0,%1,%2") 27288 27289 You could write: 27290 27291 (define_constants [ 27292 (R_BP 177) 27293 (R_FC 178) 27294 (R_CR 179) 27295 (R_Q 180) 27296 ]) 27297 27298 (define_insn "" 27299 [(match_parallel 0 "load_multiple_operation" 27300 [(set (match_operand:SI 1 "gpc_reg_operand" "=r") 27301 (match_operand:SI 2 "memory_operand" "m")) 27302 (use (reg:SI R_CR)) 27303 (clobber (reg:SI R_CR))])] 27304 "" 27305 "loadm 0,0,%1,%2") 27306 27307 The constants that are defined with a define_constant are also output 27308in the insn-codes.h header file as #defines. 27309 27310 You can also use the machine description file to define enumerations. 27311Like the constants defined by `define_constant', these enumerations are 27312visible to both the machine description file and the main C code. 27313 27314 The syntax is as follows: 27315 27316 (define_c_enum "NAME" [ 27317 VALUE0 27318 VALUE1 27319 ... 27320 VALUEN 27321 ]) 27322 27323 This definition causes the equivalent of the following C code to appear 27324in `insn-constants.h': 27325 27326 enum NAME { 27327 VALUE0 = 0, 27328 VALUE1 = 1, 27329 ... 27330 VALUEN = N 27331 }; 27332 #define NUM_CNAME_VALUES (N + 1) 27333 27334 where CNAME is the capitalized form of NAME. It also makes each 27335VALUEI available in the machine description file, just as if it had 27336been declared with: 27337 27338 (define_constants [(VALUEI I)]) 27339 27340 Each VALUEI is usually an upper-case identifier and usually begins 27341with CNAME. 27342 27343 You can split the enumeration definition into as many statements as 27344you like. The above example is directly equivalent to: 27345 27346 (define_c_enum "NAME" [VALUE0]) 27347 (define_c_enum "NAME" [VALUE1]) 27348 ... 27349 (define_c_enum "NAME" [VALUEN]) 27350 27351 Splitting the enumeration helps to improve the modularity of each 27352individual `.md' file. For example, if a port defines its 27353synchronization instructions in a separate `sync.md' file, it is 27354convenient to define all synchronization-specific enumeration values in 27355`sync.md' rather than in the main `.md' file. 27356 27357 Some enumeration names have special significance to GCC: 27358 27359`unspecv' 27360 If an enumeration called `unspecv' is defined, GCC will use it 27361 when printing out `unspec_volatile' expressions. For example: 27362 27363 (define_c_enum "unspecv" [ 27364 UNSPECV_BLOCKAGE 27365 ]) 27366 27367 causes GCC to print `(unspec_volatile ... 0)' as: 27368 27369 (unspec_volatile ... UNSPECV_BLOCKAGE) 27370 27371`unspec' 27372 If an enumeration called `unspec' is defined, GCC will use it when 27373 printing out `unspec' expressions. GCC will also use it when 27374 printing out `unspec_volatile' expressions unless an `unspecv' 27375 enumeration is also defined. You can therefore decide whether to 27376 keep separate enumerations for volatile and non-volatile 27377 expressions or whether to use the same enumeration for both. 27378 27379 Another way of defining an enumeration is to use `define_enum': 27380 27381 (define_enum "NAME" [ 27382 VALUE0 27383 VALUE1 27384 ... 27385 VALUEN 27386 ]) 27387 27388 This directive implies: 27389 27390 (define_c_enum "NAME" [ 27391 CNAME_CVALUE0 27392 CNAME_CVALUE1 27393 ... 27394 CNAME_CVALUEN 27395 ]) 27396 27397 where CVALUEI is the capitalized form of VALUEI. However, unlike 27398`define_c_enum', the enumerations defined by `define_enum' can be used 27399in attribute specifications (*note define_enum_attr::). 27400 27401 27402File: gccint.info, Node: Iterators, Prev: Constant Definitions, Up: Machine Desc 27403 2740416.23 Iterators 27405=============== 27406 27407Ports often need to define similar patterns for more than one machine 27408mode or for more than one rtx code. GCC provides some simple iterator 27409facilities to make this process easier. 27410 27411* Menu: 27412 27413* Mode Iterators:: Generating variations of patterns for different modes. 27414* Code Iterators:: Doing the same for codes. 27415* Int Iterators:: Doing the same for integers. 27416* Subst Iterators:: Generating variations of patterns for define_subst. 27417 27418 27419File: gccint.info, Node: Mode Iterators, Next: Code Iterators, Up: Iterators 27420 2742116.23.1 Mode Iterators 27422---------------------- 27423 27424Ports often need to define similar patterns for two or more different 27425modes. For example: 27426 27427 * If a processor has hardware support for both single and double 27428 floating-point arithmetic, the `SFmode' patterns tend to be very 27429 similar to the `DFmode' ones. 27430 27431 * If a port uses `SImode' pointers in one configuration and `DImode' 27432 pointers in another, it will usually have very similar `SImode' 27433 and `DImode' patterns for manipulating pointers. 27434 27435 Mode iterators allow several patterns to be instantiated from one 27436`.md' file template. They can be used with any type of rtx-based 27437construct, such as a `define_insn', `define_split', or 27438`define_peephole2'. 27439 27440* Menu: 27441 27442* Defining Mode Iterators:: Defining a new mode iterator. 27443* Substitutions:: Combining mode iterators with substitutions 27444* Examples:: Examples 27445 27446 27447File: gccint.info, Node: Defining Mode Iterators, Next: Substitutions, Up: Mode Iterators 27448 2744916.23.1.1 Defining Mode Iterators 27450................................. 27451 27452The syntax for defining a mode iterator is: 27453 27454 (define_mode_iterator NAME [(MODE1 "COND1") ... (MODEN "CONDN")]) 27455 27456 This allows subsequent `.md' file constructs to use the mode suffix 27457`:NAME'. Every construct that does so will be expanded N times, once 27458with every use of `:NAME' replaced by `:MODE1', once with every use 27459replaced by `:MODE2', and so on. In the expansion for a particular 27460MODEI, every C condition will also require that CONDI be true. 27461 27462 For example: 27463 27464 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 27465 27466 defines a new mode suffix `:P'. Every construct that uses `:P' will 27467be expanded twice, once with every `:P' replaced by `:SI' and once with 27468every `:P' replaced by `:DI'. The `:SI' version will only apply if 27469`Pmode == SImode' and the `:DI' version will only apply if `Pmode == 27470DImode'. 27471 27472 As with other `.md' conditions, an empty string is treated as "always 27473true". `(MODE "")' can also be abbreviated to `MODE'. For example: 27474 27475 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 27476 27477 means that the `:DI' expansion only applies if `TARGET_64BIT' but that 27478the `:SI' expansion has no such constraint. 27479 27480 Iterators are applied in the order they are defined. This can be 27481significant if two iterators are used in a construct that requires 27482substitutions. *Note Substitutions::. 27483 27484 27485File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Iterators, Up: Mode Iterators 27486 2748716.23.1.2 Substitution in Mode Iterators 27488........................................ 27489 27490If an `.md' file construct uses mode iterators, each version of the 27491construct will often need slightly different strings or modes. For 27492example: 27493 27494 * When a `define_expand' defines several `addM3' patterns (*note 27495 Standard Names::), each expander will need to use the appropriate 27496 mode name for M. 27497 27498 * When a `define_insn' defines several instruction patterns, each 27499 instruction will often use a different assembler mnemonic. 27500 27501 * When a `define_insn' requires operands with different modes, using 27502 an iterator for one of the operand modes usually requires a 27503 specific mode for the other operand(s). 27504 27505 GCC supports such variations through a system of "mode attributes". 27506There are two standard attributes: `mode', which is the name of the 27507mode in lower case, and `MODE', which is the same thing in upper case. 27508You can define other attributes using: 27509 27510 (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")]) 27511 27512 where NAME is the name of the attribute and VALUEI is the value 27513associated with MODEI. 27514 27515 When GCC replaces some :ITERATOR with :MODE, it will scan each string 27516and mode in the pattern for sequences of the form `<ITERATOR:ATTR>', 27517where ATTR is the name of a mode attribute. If the attribute is 27518defined for MODE, the whole `<...>' sequence will be replaced by the 27519appropriate attribute value. 27520 27521 For example, suppose an `.md' file has: 27522 27523 (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) 27524 (define_mode_attr load [(SI "lw") (DI "ld")]) 27525 27526 If one of the patterns that uses `:P' contains the string 27527`"<P:load>\t%0,%1"', the `SI' version of that pattern will use 27528`"lw\t%0,%1"' and the `DI' version will use `"ld\t%0,%1"'. 27529 27530 Here is an example of using an attribute for a mode: 27531 27532 (define_mode_iterator LONG [SI DI]) 27533 (define_mode_attr SHORT [(SI "HI") (DI "SI")]) 27534 (define_insn ... 27535 (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...) 27536 27537 The `ITERATOR:' prefix may be omitted, in which case the substitution 27538will be attempted for every iterator expansion. 27539 27540 27541File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Iterators 27542 2754316.23.1.3 Mode Iterator Examples 27544................................ 27545 27546Here is an example from the MIPS port. It defines the following modes 27547and attributes (among others): 27548 27549 (define_mode_iterator GPR [SI (DI "TARGET_64BIT")]) 27550 (define_mode_attr d [(SI "") (DI "d")]) 27551 27552 and uses the following template to define both `subsi3' and `subdi3': 27553 27554 (define_insn "sub<mode>3" 27555 [(set (match_operand:GPR 0 "register_operand" "=d") 27556 (minus:GPR (match_operand:GPR 1 "register_operand" "d") 27557 (match_operand:GPR 2 "register_operand" "d")))] 27558 "" 27559 "<d>subu\t%0,%1,%2" 27560 [(set_attr "type" "arith") 27561 (set_attr "mode" "<MODE>")]) 27562 27563 This is exactly equivalent to: 27564 27565 (define_insn "subsi3" 27566 [(set (match_operand:SI 0 "register_operand" "=d") 27567 (minus:SI (match_operand:SI 1 "register_operand" "d") 27568 (match_operand:SI 2 "register_operand" "d")))] 27569 "" 27570 "subu\t%0,%1,%2" 27571 [(set_attr "type" "arith") 27572 (set_attr "mode" "SI")]) 27573 27574 (define_insn "subdi3" 27575 [(set (match_operand:DI 0 "register_operand" "=d") 27576 (minus:DI (match_operand:DI 1 "register_operand" "d") 27577 (match_operand:DI 2 "register_operand" "d")))] 27578 "" 27579 "dsubu\t%0,%1,%2" 27580 [(set_attr "type" "arith") 27581 (set_attr "mode" "DI")]) 27582 27583 27584File: gccint.info, Node: Code Iterators, Next: Int Iterators, Prev: Mode Iterators, Up: Iterators 27585 2758616.23.2 Code Iterators 27587---------------------- 27588 27589Code iterators operate in a similar way to mode iterators. *Note Mode 27590Iterators::. 27591 27592 The construct: 27593 27594 (define_code_iterator NAME [(CODE1 "COND1") ... (CODEN "CONDN")]) 27595 27596 defines a pseudo rtx code NAME that can be instantiated as CODEI if 27597condition CONDI is true. Each CODEI must have the same rtx format. 27598*Note RTL Classes::. 27599 27600 As with mode iterators, each pattern that uses NAME will be expanded N 27601times, once with all uses of NAME replaced by CODE1, once with all uses 27602replaced by CODE2, and so on. *Note Defining Mode Iterators::. 27603 27604 It is possible to define attributes for codes as well as for modes. 27605There are two standard code attributes: `code', the name of the code in 27606lower case, and `CODE', the name of the code in upper case. Other 27607attributes are defined using: 27608 27609 (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")]) 27610 27611 Here's an example of code iterators in action, taken from the MIPS 27612port: 27613 27614 (define_code_iterator any_cond [unordered ordered unlt unge uneq ltgt unle ungt 27615 eq ne gt ge lt le gtu geu ltu leu]) 27616 27617 (define_expand "b<code>" 27618 [(set (pc) 27619 (if_then_else (any_cond:CC (cc0) 27620 (const_int 0)) 27621 (label_ref (match_operand 0 "")) 27622 (pc)))] 27623 "" 27624 { 27625 gen_conditional_branch (operands, <CODE>); 27626 DONE; 27627 }) 27628 27629 This is equivalent to: 27630 27631 (define_expand "bunordered" 27632 [(set (pc) 27633 (if_then_else (unordered:CC (cc0) 27634 (const_int 0)) 27635 (label_ref (match_operand 0 "")) 27636 (pc)))] 27637 "" 27638 { 27639 gen_conditional_branch (operands, UNORDERED); 27640 DONE; 27641 }) 27642 27643 (define_expand "bordered" 27644 [(set (pc) 27645 (if_then_else (ordered:CC (cc0) 27646 (const_int 0)) 27647 (label_ref (match_operand 0 "")) 27648 (pc)))] 27649 "" 27650 { 27651 gen_conditional_branch (operands, ORDERED); 27652 DONE; 27653 }) 27654 27655 ... 27656 27657 27658File: gccint.info, Node: Int Iterators, Next: Subst Iterators, Prev: Code Iterators, Up: Iterators 27659 2766016.23.3 Int Iterators 27661--------------------- 27662 27663Int iterators operate in a similar way to code iterators. *Note Code 27664Iterators::. 27665 27666 The construct: 27667 27668 (define_int_iterator NAME [(INT1 "COND1") ... (INTN "CONDN")]) 27669 27670 defines a pseudo integer constant NAME that can be instantiated as 27671INTI if condition CONDI is true. Each INT must have the same rtx 27672format. *Note RTL Classes::. Int iterators can appear in only those 27673rtx fields that have 'i' as the specifier. This means that each INT has 27674to be a constant defined using define_constant or define_c_enum. 27675 27676 As with mode and code iterators, each pattern that uses NAME will be 27677expanded N times, once with all uses of NAME replaced by INT1, once 27678with all uses replaced by INT2, and so on. *Note Defining Mode 27679Iterators::. 27680 27681 It is possible to define attributes for ints as well as for codes and 27682modes. Attributes are defined using: 27683 27684 (define_int_attr NAME [(INT1 "VALUE1") ... (INTN "VALUEN")]) 27685 27686 Here's an example of int iterators in action, taken from the ARM port: 27687 27688 (define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG]) 27689 27690 (define_int_attr absneg [(UNSPEC_VQABS "abs") (UNSPEC_VQNEG "neg")]) 27691 27692 (define_insn "neon_vq<absneg><mode>" 27693 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 27694 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 27695 (match_operand:SI 2 "immediate_operand" "i")] 27696 QABSNEG))] 27697 "TARGET_NEON" 27698 "vq<absneg>.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 27699 [(set_attr "type" "neon_vqneg_vqabs")] 27700 ) 27701 27702 This is equivalent to: 27703 27704 (define_insn "neon_vqabs<mode>" 27705 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 27706 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 27707 (match_operand:SI 2 "immediate_operand" "i")] 27708 UNSPEC_VQABS))] 27709 "TARGET_NEON" 27710 "vqabs.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 27711 [(set_attr "type" "neon_vqneg_vqabs")] 27712 ) 27713 27714 (define_insn "neon_vqneg<mode>" 27715 [(set (match_operand:VDQIW 0 "s_register_operand" "=w") 27716 (unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w") 27717 (match_operand:SI 2 "immediate_operand" "i")] 27718 UNSPEC_VQNEG))] 27719 "TARGET_NEON" 27720 "vqneg.<V_s_elem>\t%<V_reg>0, %<V_reg>1" 27721 [(set_attr "type" "neon_vqneg_vqabs")] 27722 ) 27723 27724 27725File: gccint.info, Node: Subst Iterators, Prev: Int Iterators, Up: Iterators 27726 2772716.23.4 Subst Iterators 27728----------------------- 27729 27730Subst iterators are special type of iterators with the following 27731restrictions: they could not be declared explicitly, they always have 27732only two values, and they do not have explicit dedicated name. 27733Subst-iterators are triggered only when corresponding subst-attribute is 27734used in RTL-pattern. 27735 27736 Subst iterators transform templates in the following way: the templates 27737are duplicated, the subst-attributes in these templates are replaced 27738with the corresponding values, and a new attribute is implicitly added 27739to the given `define_insn'/`define_expand'. The name of the added 27740attribute matches the name of `define_subst'. Such attributes are 27741declared implicitly, and it is not allowed to have a `define_attr' 27742named as a `define_subst'. 27743 27744 Each subst iterator is linked to a `define_subst'. It is declared 27745implicitly by the first appearance of the corresponding 27746`define_subst_attr', and it is not allowed to define it explicitly. 27747 27748 Declarations of subst-attributes have the following syntax: 27749 27750 (define_subst_attr "NAME" 27751 "SUBST-NAME" 27752 "NO-SUBST-VALUE" 27753 "SUBST-APPLIED-VALUE") 27754 27755 NAME is a string with which the given subst-attribute could be 27756referred to. 27757 27758 SUBST-NAME shows which `define_subst' should be applied to an 27759RTL-template if the given subst-attribute is present in the 27760RTL-template. 27761 27762 NO-SUBST-VALUE is a value with which subst-attribute would be replaced 27763in the first copy of the original RTL-template. 27764 27765 SUBST-APPLIED-VALUE is a value with which subst-attribute would be 27766replaced in the second copy of the original RTL-template. 27767 27768 27769File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top 27770 2777117 Target Description Macros and Functions 27772****************************************** 27773 27774In addition to the file `MACHINE.md', a machine description includes a 27775C header file conventionally given the name `MACHINE.h' and a C source 27776file named `MACHINE.c'. The header file defines numerous macros that 27777convey the information about the target machine that does not fit into 27778the scheme of the `.md' file. The file `tm.h' should be a link to 27779`MACHINE.h'. The header file `config.h' includes `tm.h' and most 27780compiler source files include `config.h'. The source file defines a 27781variable `targetm', which is a structure containing pointers to 27782functions and data relating to the target machine. `MACHINE.c' should 27783also contain their definitions, if they are not defined elsewhere in 27784GCC, and other functions called through the macros defined in the `.h' 27785file. 27786 27787* Menu: 27788 27789* Target Structure:: The `targetm' variable. 27790* Driver:: Controlling how the driver runs the compilation passes. 27791* Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'. 27792* Per-Function Data:: Defining data structures for per-function information. 27793* Storage Layout:: Defining sizes and alignments of data. 27794* Type Layout:: Defining sizes and properties of basic user data types. 27795* Registers:: Naming and describing the hardware registers. 27796* Register Classes:: Defining the classes of hardware registers. 27797* Stack and Calling:: Defining which way the stack grows and by how much. 27798* Varargs:: Defining the varargs macros. 27799* Trampolines:: Code set up at run time to enter a nested function. 27800* Library Calls:: Controlling how library routines are implicitly called. 27801* Addressing Modes:: Defining addressing modes valid for memory operands. 27802* Anchored Addresses:: Defining how `-fsection-anchors' should work. 27803* Condition Code:: Defining how insns update the condition code. 27804* Costs:: Defining relative costs of different operations. 27805* Scheduling:: Adjusting the behavior of the instruction scheduler. 27806* Sections:: Dividing storage into text, data, and other sections. 27807* PIC:: Macros for position independent code. 27808* Assembler Format:: Defining how to write insns and pseudo-ops to output. 27809* Debugging Info:: Defining the format of debugging output. 27810* Floating Point:: Handling floating point for cross-compilers. 27811* Mode Switching:: Insertion of mode-switching instructions. 27812* Target Attributes:: Defining target-specific uses of `__attribute__'. 27813* Emulated TLS:: Emulated TLS support. 27814* MIPS Coprocessors:: MIPS coprocessor support and how to customize it. 27815* PCH Target:: Validity checking for precompiled headers. 27816* C++ ABI:: Controlling C++ ABI changes. 27817* Named Address Spaces:: Adding support for named address spaces 27818* Misc:: Everything else. 27819 27820 27821File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros 27822 2782317.1 The Global `targetm' Variable 27824================================== 27825 27826 -- Variable: struct gcc_target targetm 27827 The target `.c' file must define the global `targetm' variable 27828 which contains pointers to functions and data relating to the 27829 target machine. The variable is declared in `target.h'; 27830 `target-def.h' defines the macro `TARGET_INITIALIZER' which is 27831 used to initialize the variable, and macros for the default 27832 initializers for elements of the structure. The `.c' file should 27833 override those macros for which the default definition is 27834 inappropriate. For example: 27835 #include "target.h" 27836 #include "target-def.h" 27837 27838 /* Initialize the GCC target structure. */ 27839 27840 #undef TARGET_COMP_TYPE_ATTRIBUTES 27841 #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes 27842 27843 struct gcc_target targetm = TARGET_INITIALIZER; 27844 27845Where a macro should be defined in the `.c' file in this manner to form 27846part of the `targetm' structure, it is documented below as a "Target 27847Hook" with a prototype. Many macros will change in future from being 27848defined in the `.h' file to being part of the `targetm' structure. 27849 27850 Similarly, there is a `targetcm' variable for hooks that are specific 27851to front ends for C-family languages, documented as "C Target Hook". 27852This is declared in `c-family/c-target.h', the initializer 27853`TARGETCM_INITIALIZER' in `c-family/c-target-def.h'. If targets 27854initialize `targetcm' themselves, they should set 27855`target_has_targetcm=yes' in `config.gcc'; otherwise a default 27856definition is used. 27857 27858 Similarly, there is a `targetm_common' variable for hooks that are 27859shared between the compiler driver and the compilers proper, documented 27860as "Common Target Hook". This is declared in `common/common-target.h', 27861the initializer `TARGETM_COMMON_INITIALIZER' in 27862`common/common-target-def.h'. If targets initialize `targetm_common' 27863themselves, they should set `target_has_targetm_common=yes' in 27864`config.gcc'; otherwise a default definition is used. 27865 27866 27867File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros 27868 2786917.2 Controlling the Compilation Driver, `gcc' 27870============================================== 27871 27872You can control the compilation driver. 27873 27874 -- Macro: DRIVER_SELF_SPECS 27875 A list of specs for the driver itself. It should be a suitable 27876 initializer for an array of strings, with no surrounding braces. 27877 27878 The driver applies these specs to its own command line between 27879 loading default `specs' files (but not command-line specified 27880 ones) and choosing the multilib directory or running any 27881 subcommands. It applies them in the order given, so each spec can 27882 depend on the options added by earlier ones. It is also possible 27883 to remove options using `%<OPTION' in the usual way. 27884 27885 This macro can be useful when a port has several interdependent 27886 target options. It provides a way of standardizing the command 27887 line so that the other specs are easier to write. 27888 27889 Do not define this macro if it does not need to do anything. 27890 27891 -- Macro: OPTION_DEFAULT_SPECS 27892 A list of specs used to support configure-time default options 27893 (i.e. `--with' options) in the driver. It should be a suitable 27894 initializer for an array of structures, each containing two 27895 strings, without the outermost pair of surrounding braces. 27896 27897 The first item in the pair is the name of the default. This must 27898 match the code in `config.gcc' for the target. The second item is 27899 a spec to apply if a default with this name was specified. The 27900 string `%(VALUE)' in the spec will be replaced by the value of the 27901 default everywhere it occurs. 27902 27903 The driver will apply these specs to its own command line between 27904 loading default `specs' files and processing `DRIVER_SELF_SPECS', 27905 using the same mechanism as `DRIVER_SELF_SPECS'. 27906 27907 Do not define this macro if it does not need to do anything. 27908 27909 -- Macro: CPP_SPEC 27910 A C string constant that tells the GCC driver program options to 27911 pass to CPP. It can also specify how to translate options you 27912 give to GCC into options for GCC to pass to the CPP. 27913 27914 Do not define this macro if it does not need to do anything. 27915 27916 -- Macro: CPLUSPLUS_CPP_SPEC 27917 This macro is just like `CPP_SPEC', but is used for C++, rather 27918 than C. If you do not define this macro, then the value of 27919 `CPP_SPEC' (if any) will be used instead. 27920 27921 -- Macro: CC1_SPEC 27922 A C string constant that tells the GCC driver program options to 27923 pass to `cc1', `cc1plus', `f771', and the other language front 27924 ends. It can also specify how to translate options you give to 27925 GCC into options for GCC to pass to front ends. 27926 27927 Do not define this macro if it does not need to do anything. 27928 27929 -- Macro: CC1PLUS_SPEC 27930 A C string constant that tells the GCC driver program options to 27931 pass to `cc1plus'. It can also specify how to translate options 27932 you give to GCC into options for GCC to pass to the `cc1plus'. 27933 27934 Do not define this macro if it does not need to do anything. Note 27935 that everything defined in CC1_SPEC is already passed to `cc1plus' 27936 so there is no need to duplicate the contents of CC1_SPEC in 27937 CC1PLUS_SPEC. 27938 27939 -- Macro: ASM_SPEC 27940 A C string constant that tells the GCC driver program options to 27941 pass to the assembler. It can also specify how to translate 27942 options you give to GCC into options for GCC to pass to the 27943 assembler. See the file `sun3.h' for an example of this. 27944 27945 Do not define this macro if it does not need to do anything. 27946 27947 -- Macro: ASM_FINAL_SPEC 27948 A C string constant that tells the GCC driver program how to run 27949 any programs which cleanup after the normal assembler. Normally, 27950 this is not needed. See the file `mips.h' for an example of this. 27951 27952 Do not define this macro if it does not need to do anything. 27953 27954 -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT 27955 Define this macro, with no value, if the driver should give the 27956 assembler an argument consisting of a single dash, `-', to 27957 instruct it to read from its standard input (which will be a pipe 27958 connected to the output of the compiler proper). This argument is 27959 given after any `-o' option specifying the name of the output file. 27960 27961 If you do not define this macro, the assembler is assumed to read 27962 its standard input if given no non-option arguments. If your 27963 assembler cannot read standard input at all, use a `%{pipe:%e}' 27964 construct; see `mips.h' for instance. 27965 27966 -- Macro: LINK_SPEC 27967 A C string constant that tells the GCC driver program options to 27968 pass to the linker. It can also specify how to translate options 27969 you give to GCC into options for GCC to pass to the linker. 27970 27971 Do not define this macro if it does not need to do anything. 27972 27973 -- Macro: LIB_SPEC 27974 Another C string constant used much like `LINK_SPEC'. The 27975 difference between the two is that `LIB_SPEC' is used at the end 27976 of the command given to the linker. 27977 27978 If this macro is not defined, a default is provided that loads the 27979 standard C library from the usual place. See `gcc.c'. 27980 27981 -- Macro: LIBGCC_SPEC 27982 Another C string constant that tells the GCC driver program how 27983 and when to place a reference to `libgcc.a' into the linker 27984 command line. This constant is placed both before and after the 27985 value of `LIB_SPEC'. 27986 27987 If this macro is not defined, the GCC driver provides a default 27988 that passes the string `-lgcc' to the linker. 27989 27990 -- Macro: REAL_LIBGCC_SPEC 27991 By default, if `ENABLE_SHARED_LIBGCC' is defined, the 27992 `LIBGCC_SPEC' is not directly used by the driver program but is 27993 instead modified to refer to different versions of `libgcc.a' 27994 depending on the values of the command line flags `-static', 27995 `-shared', `-static-libgcc', and `-shared-libgcc'. On targets 27996 where these modifications are inappropriate, define 27997 `REAL_LIBGCC_SPEC' instead. `REAL_LIBGCC_SPEC' tells the driver 27998 how to place a reference to `libgcc' on the link command line, 27999 but, unlike `LIBGCC_SPEC', it is used unmodified. 28000 28001 -- Macro: USE_LD_AS_NEEDED 28002 A macro that controls the modifications to `LIBGCC_SPEC' mentioned 28003 in `REAL_LIBGCC_SPEC'. If nonzero, a spec will be generated that 28004 uses `--as-needed' or equivalent options and the shared `libgcc' 28005 in place of the static exception handler library, when linking 28006 without any of `-static', `-static-libgcc', or `-shared-libgcc'. 28007 28008 -- Macro: LINK_EH_SPEC 28009 If defined, this C string constant is added to `LINK_SPEC'. When 28010 `USE_LD_AS_NEEDED' is zero or undefined, it also affects the 28011 modifications to `LIBGCC_SPEC' mentioned in `REAL_LIBGCC_SPEC'. 28012 28013 -- Macro: STARTFILE_SPEC 28014 Another C string constant used much like `LINK_SPEC'. The 28015 difference between the two is that `STARTFILE_SPEC' is used at the 28016 very beginning of the command given to the linker. 28017 28018 If this macro is not defined, a default is provided that loads the 28019 standard C startup file from the usual place. See `gcc.c'. 28020 28021 -- Macro: ENDFILE_SPEC 28022 Another C string constant used much like `LINK_SPEC'. The 28023 difference between the two is that `ENDFILE_SPEC' is used at the 28024 very end of the command given to the linker. 28025 28026 Do not define this macro if it does not need to do anything. 28027 28028 -- Macro: THREAD_MODEL_SPEC 28029 GCC `-v' will print the thread model GCC was configured to use. 28030 However, this doesn't work on platforms that are multilibbed on 28031 thread models, such as AIX 4.3. On such platforms, define 28032 `THREAD_MODEL_SPEC' such that it evaluates to a string without 28033 blanks that names one of the recognized thread models. `%*', the 28034 default value of this macro, will expand to the value of 28035 `thread_file' set in `config.gcc'. 28036 28037 -- Macro: SYSROOT_SUFFIX_SPEC 28038 Define this macro to add a suffix to the target sysroot when GCC is 28039 configured with a sysroot. This will cause GCC to search for 28040 usr/lib, et al, within sysroot+suffix. 28041 28042 -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC 28043 Define this macro to add a headers_suffix to the target sysroot 28044 when GCC is configured with a sysroot. This will cause GCC to 28045 pass the updated sysroot+headers_suffix to CPP, causing it to 28046 search for usr/include, et al, within sysroot+headers_suffix. 28047 28048 -- Macro: EXTRA_SPECS 28049 Define this macro to provide additional specifications to put in 28050 the `specs' file that can be used in various specifications like 28051 `CC1_SPEC'. 28052 28053 The definition should be an initializer for an array of structures, 28054 containing a string constant, that defines the specification name, 28055 and a string constant that provides the specification. 28056 28057 Do not define this macro if it does not need to do anything. 28058 28059 `EXTRA_SPECS' is useful when an architecture contains several 28060 related targets, which have various `..._SPECS' which are similar 28061 to each other, and the maintainer would like one central place to 28062 keep these definitions. 28063 28064 For example, the PowerPC System V.4 targets use `EXTRA_SPECS' to 28065 define either `_CALL_SYSV' when the System V calling sequence is 28066 used or `_CALL_AIX' when the older AIX-based calling sequence is 28067 used. 28068 28069 The `config/rs6000/rs6000.h' target file defines: 28070 28071 #define EXTRA_SPECS \ 28072 { "cpp_sysv_default", CPP_SYSV_DEFAULT }, 28073 28074 #define CPP_SYS_DEFAULT "" 28075 28076 The `config/rs6000/sysv.h' target file defines: 28077 #undef CPP_SPEC 28078 #define CPP_SPEC \ 28079 "%{posix: -D_POSIX_SOURCE } \ 28080 %{mcall-sysv: -D_CALL_SYSV } \ 28081 %{!mcall-sysv: %(cpp_sysv_default) } \ 28082 %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}" 28083 28084 #undef CPP_SYSV_DEFAULT 28085 #define CPP_SYSV_DEFAULT "-D_CALL_SYSV" 28086 28087 while the `config/rs6000/eabiaix.h' target file defines 28088 `CPP_SYSV_DEFAULT' as: 28089 28090 #undef CPP_SYSV_DEFAULT 28091 #define CPP_SYSV_DEFAULT "-D_CALL_AIX" 28092 28093 -- Macro: LINK_LIBGCC_SPECIAL_1 28094 Define this macro if the driver program should find the library 28095 `libgcc.a'. If you do not define this macro, the driver program 28096 will pass the argument `-lgcc' to tell the linker to do the search. 28097 28098 -- Macro: LINK_GCC_C_SEQUENCE_SPEC 28099 The sequence in which libgcc and libc are specified to the linker. 28100 By default this is `%G %L %G'. 28101 28102 -- Macro: LINK_COMMAND_SPEC 28103 A C string constant giving the complete command line need to 28104 execute the linker. When you do this, you will need to update 28105 your port each time a change is made to the link command line 28106 within `gcc.c'. Therefore, define this macro only if you need to 28107 completely redefine the command line for invoking the linker and 28108 there is no other way to accomplish the effect you need. 28109 Overriding this macro may be avoidable by overriding 28110 `LINK_GCC_C_SEQUENCE_SPEC' instead. 28111 28112 -- Common Target Hook: bool TARGET_ALWAYS_STRIP_DOTDOT 28113 True if `..' components should always be removed from directory 28114 names computed relative to GCC's internal directories, false 28115 (default) if such components should be preserved and directory 28116 names containing them passed to other tools such as the linker. 28117 28118 -- Macro: MULTILIB_DEFAULTS 28119 Define this macro as a C expression for the initializer of an 28120 array of string to tell the driver program which options are 28121 defaults for this target and thus do not need to be handled 28122 specially when using `MULTILIB_OPTIONS'. 28123 28124 Do not define this macro if `MULTILIB_OPTIONS' is not defined in 28125 the target makefile fragment or if none of the options listed in 28126 `MULTILIB_OPTIONS' are set by default. *Note Target Fragment::. 28127 28128 -- Macro: RELATIVE_PREFIX_NOT_LINKDIR 28129 Define this macro to tell `gcc' that it should only translate a 28130 `-B' prefix into a `-L' linker option if the prefix indicates an 28131 absolute file name. 28132 28133 -- Macro: MD_EXEC_PREFIX 28134 If defined, this macro is an additional prefix to try after 28135 `STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when the 28136 compiler is built as a cross compiler. If you define 28137 `MD_EXEC_PREFIX', then be sure to add it to the list of 28138 directories used to find the assembler in `configure.in'. 28139 28140 -- Macro: STANDARD_STARTFILE_PREFIX 28141 Define this macro as a C string constant if you wish to override 28142 the standard choice of `libdir' as the default prefix to try when 28143 searching for startup files such as `crt0.o'. 28144 `STANDARD_STARTFILE_PREFIX' is not searched when the compiler is 28145 built as a cross compiler. 28146 28147 -- Macro: STANDARD_STARTFILE_PREFIX_1 28148 Define this macro as a C string constant if you wish to override 28149 the standard choice of `/lib' as a prefix to try after the default 28150 prefix when searching for startup files such as `crt0.o'. 28151 `STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is 28152 built as a cross compiler. 28153 28154 -- Macro: STANDARD_STARTFILE_PREFIX_2 28155 Define this macro as a C string constant if you wish to override 28156 the standard choice of `/lib' as yet another prefix to try after 28157 the default prefix when searching for startup files such as 28158 `crt0.o'. `STANDARD_STARTFILE_PREFIX_2' is not searched when the 28159 compiler is built as a cross compiler. 28160 28161 -- Macro: MD_STARTFILE_PREFIX 28162 If defined, this macro supplies an additional prefix to try after 28163 the standard prefixes. `MD_EXEC_PREFIX' is not searched when the 28164 compiler is built as a cross compiler. 28165 28166 -- Macro: MD_STARTFILE_PREFIX_1 28167 If defined, this macro supplies yet another prefix to try after the 28168 standard prefixes. It is not searched when the compiler is built 28169 as a cross compiler. 28170 28171 -- Macro: INIT_ENVIRONMENT 28172 Define this macro as a C string constant if you wish to set 28173 environment variables for programs called by the driver, such as 28174 the assembler and loader. The driver passes the value of this 28175 macro to `putenv' to initialize the necessary environment 28176 variables. 28177 28178 -- Macro: LOCAL_INCLUDE_DIR 28179 Define this macro as a C string constant if you wish to override 28180 the standard choice of `/usr/local/include' as the default prefix 28181 to try when searching for local header files. `LOCAL_INCLUDE_DIR' 28182 comes before `NATIVE_SYSTEM_HEADER_DIR' (set in `config.gcc', 28183 normally `/usr/include') in the search order. 28184 28185 Cross compilers do not search either `/usr/local/include' or its 28186 replacement. 28187 28188 -- Macro: NATIVE_SYSTEM_HEADER_COMPONENT 28189 The "component" corresponding to `NATIVE_SYSTEM_HEADER_DIR'. See 28190 `INCLUDE_DEFAULTS', below, for the description of components. If 28191 you do not define this macro, no component is used. 28192 28193 -- Macro: INCLUDE_DEFAULTS 28194 Define this macro if you wish to override the entire default 28195 search path for include files. For a native compiler, the default 28196 search path usually consists of `GCC_INCLUDE_DIR', 28197 `LOCAL_INCLUDE_DIR', `GPLUSPLUS_INCLUDE_DIR', and 28198 `NATIVE_SYSTEM_HEADER_DIR'. In addition, `GPLUSPLUS_INCLUDE_DIR' 28199 and `GCC_INCLUDE_DIR' are defined automatically by `Makefile', and 28200 specify private search areas for GCC. The directory 28201 `GPLUSPLUS_INCLUDE_DIR' is used only for C++ programs. 28202 28203 The definition should be an initializer for an array of structures. 28204 Each array element should have four elements: the directory name (a 28205 string constant), the component name (also a string constant), a 28206 flag for C++-only directories, and a flag showing that the 28207 includes in the directory don't need to be wrapped in `extern `C'' 28208 when compiling C++. Mark the end of the array with a null element. 28209 28210 The component name denotes what GNU package the include file is 28211 part of, if any, in all uppercase letters. For example, it might 28212 be `GCC' or `BINUTILS'. If the package is part of a 28213 vendor-supplied operating system, code the component name as `0'. 28214 28215 For example, here is the definition used for VAX/VMS: 28216 28217 #define INCLUDE_DEFAULTS \ 28218 { \ 28219 { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \ 28220 { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \ 28221 { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \ 28222 { ".", 0, 0, 0}, \ 28223 { 0, 0, 0, 0} \ 28224 } 28225 28226 Here is the order of prefixes tried for exec files: 28227 28228 1. Any prefixes specified by the user with `-B'. 28229 28230 2. The environment variable `GCC_EXEC_PREFIX' or, if `GCC_EXEC_PREFIX' 28231 is not set and the compiler has not been installed in the 28232 configure-time PREFIX, the location in which the compiler has 28233 actually been installed. 28234 28235 3. The directories specified by the environment variable 28236 `COMPILER_PATH'. 28237 28238 4. The macro `STANDARD_EXEC_PREFIX', if the compiler has been 28239 installed in the configured-time PREFIX. 28240 28241 5. The location `/usr/libexec/gcc/', but only if this is a native 28242 compiler. 28243 28244 6. The location `/usr/lib/gcc/', but only if this is a native 28245 compiler. 28246 28247 7. The macro `MD_EXEC_PREFIX', if defined, but only if this is a 28248 native compiler. 28249 28250 Here is the order of prefixes tried for startfiles: 28251 28252 1. Any prefixes specified by the user with `-B'. 28253 28254 2. The environment variable `GCC_EXEC_PREFIX' or its automatically 28255 determined value based on the installed toolchain location. 28256 28257 3. The directories specified by the environment variable 28258 `LIBRARY_PATH' (or port-specific name; native only, cross 28259 compilers do not use this). 28260 28261 4. The macro `STANDARD_EXEC_PREFIX', but only if the toolchain is 28262 installed in the configured PREFIX or this is a native compiler. 28263 28264 5. The location `/usr/lib/gcc/', but only if this is a native 28265 compiler. 28266 28267 6. The macro `MD_EXEC_PREFIX', if defined, but only if this is a 28268 native compiler. 28269 28270 7. The macro `MD_STARTFILE_PREFIX', if defined, but only if this is a 28271 native compiler, or we have a target system root. 28272 28273 8. The macro `MD_STARTFILE_PREFIX_1', if defined, but only if this is 28274 a native compiler, or we have a target system root. 28275 28276 9. The macro `STANDARD_STARTFILE_PREFIX', with any sysroot 28277 modifications. If this path is relative it will be prefixed by 28278 `GCC_EXEC_PREFIX' and the machine suffix or `STANDARD_EXEC_PREFIX' 28279 and the machine suffix. 28280 28281 10. The macro `STANDARD_STARTFILE_PREFIX_1', but only if this is a 28282 native compiler, or we have a target system root. The default for 28283 this macro is `/lib/'. 28284 28285 11. The macro `STANDARD_STARTFILE_PREFIX_2', but only if this is a 28286 native compiler, or we have a target system root. The default for 28287 this macro is `/usr/lib/'. 28288 28289 28290File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros 28291 2829217.3 Run-time Target Specification 28293================================== 28294 28295Here are run-time target specifications. 28296 28297 -- Macro: TARGET_CPU_CPP_BUILTINS () 28298 This function-like macro expands to a block of code that defines 28299 built-in preprocessor macros and assertions for the target CPU, 28300 using the functions `builtin_define', `builtin_define_std' and 28301 `builtin_assert'. When the front end calls this macro it provides 28302 a trailing semicolon, and since it has finished command line 28303 option processing your code can use those results freely. 28304 28305 `builtin_assert' takes a string in the form you pass to the 28306 command-line option `-A', such as `cpu=mips', and creates the 28307 assertion. `builtin_define' takes a string in the form accepted 28308 by option `-D' and unconditionally defines the macro. 28309 28310 `builtin_define_std' takes a string representing the name of an 28311 object-like macro. If it doesn't lie in the user's namespace, 28312 `builtin_define_std' defines it unconditionally. Otherwise, it 28313 defines a version with two leading underscores, and another version 28314 with two leading and trailing underscores, and defines the original 28315 only if an ISO standard was not requested on the command line. For 28316 example, passing `unix' defines `__unix', `__unix__' and possibly 28317 `unix'; passing `_mips' defines `__mips', `__mips__' and possibly 28318 `_mips', and passing `_ABI64' defines only `_ABI64'. 28319 28320 You can also test for the C dialect being compiled. The variable 28321 `c_language' is set to one of `clk_c', `clk_cplusplus' or 28322 `clk_objective_c'. Note that if we are preprocessing assembler, 28323 this variable will be `clk_c' but the function-like macro 28324 `preprocessing_asm_p()' will return true, so you might want to 28325 check for that first. If you need to check for strict ANSI, the 28326 variable `flag_iso' can be used. The function-like macro 28327 `preprocessing_trad_p()' can be used to check for traditional 28328 preprocessing. 28329 28330 -- Macro: TARGET_OS_CPP_BUILTINS () 28331 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional 28332 and is used for the target operating system instead. 28333 28334 -- Macro: TARGET_OBJFMT_CPP_BUILTINS () 28335 Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional 28336 and is used for the target object format. `elfos.h' uses this 28337 macro to define `__ELF__', so you probably do not need to define 28338 it yourself. 28339 28340 -- Variable: extern int target_flags 28341 This variable is declared in `options.h', which is included before 28342 any target-specific headers. 28343 28344 -- Common Target Hook: int TARGET_DEFAULT_TARGET_FLAGS 28345 This variable specifies the initial value of `target_flags'. Its 28346 default setting is 0. 28347 28348 -- Common Target Hook: bool TARGET_HANDLE_OPTION (struct gcc_options 28349 *OPTS, struct gcc_options *OPTS_SET, const struct 28350 cl_decoded_option *DECODED, location_t LOC) 28351 This hook is called whenever the user specifies one of the 28352 target-specific options described by the `.opt' definition files 28353 (*note Options::). It has the opportunity to do some 28354 option-specific processing and should return true if the option is 28355 valid. The default definition does nothing but return true. 28356 28357 DECODED specifies the option and its arguments. OPTS and OPTS_SET 28358 are the `gcc_options' structures to be used for storing option 28359 state, and LOC is the location at which the option was passed 28360 (`UNKNOWN_LOCATION' except for options passed via attributes). 28361 28362 -- C Target Hook: bool TARGET_HANDLE_C_OPTION (size_t CODE, const char 28363 *ARG, int VALUE) 28364 This target hook is called whenever the user specifies one of the 28365 target-specific C language family options described by the `.opt' 28366 definition files(*note Options::). It has the opportunity to do 28367 some option-specific processing and should return true if the 28368 option is valid. The arguments are like for 28369 `TARGET_HANDLE_OPTION'. The default definition does nothing but 28370 return false. 28371 28372 In general, you should use `TARGET_HANDLE_OPTION' to handle 28373 options. However, if processing an option requires routines that 28374 are only available in the C (and related language) front ends, 28375 then you should use `TARGET_HANDLE_C_OPTION' instead. 28376 28377 -- C Target Hook: tree TARGET_OBJC_CONSTRUCT_STRING_OBJECT (tree 28378 STRING) 28379 Targets may provide a string object type that can be used within 28380 and between C, C++ and their respective Objective-C dialects. A 28381 string object might, for example, embed encoding and length 28382 information. These objects are considered opaque to the compiler 28383 and handled as references. An ideal implementation makes the 28384 composition of the string object match that of the Objective-C 28385 `NSString' (`NXString' for GNUStep), allowing efficient 28386 interworking between C-only and Objective-C code. If a target 28387 implements string objects then this hook should return a reference 28388 to such an object constructed from the normal `C' string 28389 representation provided in STRING. At present, the hook is used by 28390 Objective-C only, to obtain a common-format string object when the 28391 target provides one. 28392 28393 -- C Target Hook: void TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE 28394 (const char *CLASSNAME) 28395 Declare that Objective C class CLASSNAME is referenced by the 28396 current TU. 28397 28398 -- C Target Hook: void TARGET_OBJC_DECLARE_CLASS_DEFINITION (const 28399 char *CLASSNAME) 28400 Declare that Objective C class CLASSNAME is defined by the 28401 current TU. 28402 28403 -- C Target Hook: bool TARGET_STRING_OBJECT_REF_TYPE_P (const_tree 28404 STRINGREF) 28405 If a target implements string objects then this hook should return 28406 `true' if STRINGREF is a valid reference to such an object. 28407 28408 -- C Target Hook: void TARGET_CHECK_STRING_OBJECT_FORMAT_ARG (tree 28409 FORMAT_ARG, tree ARGS_LIST) 28410 If a target implements string objects then this hook should should 28411 provide a facility to check the function arguments in ARGS_LIST 28412 against the format specifiers in FORMAT_ARG where the type of 28413 FORMAT_ARG is one recognized as a valid string reference type. 28414 28415 -- Target Hook: void TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE (void) 28416 This target function is similar to the hook 28417 `TARGET_OPTION_OVERRIDE' but is called when the optimize level is 28418 changed via an attribute or pragma or when it is reset at the end 28419 of the code affected by the attribute or pragma. It is not called 28420 at the beginning of compilation when `TARGET_OPTION_OVERRIDE' is 28421 called so if you want to perform these actions then, you should 28422 have `TARGET_OPTION_OVERRIDE' call 28423 `TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE'. 28424 28425 -- Macro: C_COMMON_OVERRIDE_OPTIONS 28426 This is similar to the `TARGET_OPTION_OVERRIDE' hook but is only 28427 used in the C language frontends (C, Objective-C, C++, 28428 Objective-C++) and so can be used to alter option flag variables 28429 which only exist in those frontends. 28430 28431 -- Common Target Hook: const struct default_options * 28432TARGET_OPTION_OPTIMIZATION_TABLE 28433 Some machines may desire to change what optimizations are 28434 performed for various optimization levels. This variable, if 28435 defined, describes options to enable at particular sets of 28436 optimization levels. These options are processed once just after 28437 the optimization level is determined and before the remainder of 28438 the command options have been parsed, so may be overridden by other 28439 options passed explicitly. 28440 28441 This processing is run once at program startup and when the 28442 optimization options are changed via `#pragma GCC optimize' or by 28443 using the `optimize' attribute. 28444 28445 -- Common Target Hook: void TARGET_OPTION_INIT_STRUCT (struct 28446 gcc_options *OPTS) 28447 Set target-dependent initial values of fields in OPTS. 28448 28449 -- Common Target Hook: void TARGET_OPTION_DEFAULT_PARAMS (void) 28450 Set target-dependent default values for `--param' settings, using 28451 calls to `set_default_param_value'. 28452 28453 -- Macro: SWITCHABLE_TARGET 28454 Some targets need to switch between substantially different 28455 subtargets during compilation. For example, the MIPS target has 28456 one subtarget for the traditional MIPS architecture and another 28457 for MIPS16. Source code can switch between these two 28458 subarchitectures using the `mips16' and `nomips16' attributes. 28459 28460 Such subtargets can differ in things like the set of available 28461 registers, the set of available instructions, the costs of various 28462 operations, and so on. GCC caches a lot of this type of 28463 information in global variables, and recomputing them for each 28464 subtarget takes a significant amount of time. The compiler 28465 therefore provides a facility for maintaining several versions of 28466 the global variables and quickly switching between them; see 28467 `target-globals.h' for details. 28468 28469 Define this macro to 1 if your target needs this facility. The 28470 default is 0. 28471 28472 -- Target Hook: bool TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P 28473 (void) 28474 Returns true if the target supports IEEE 754 floating-point 28475 exceptions and rounding modes, false otherwise. This is intended 28476 to relate to the `float' and `double' types, but not necessarily 28477 `long double'. By default, returns true if the `adddf3' 28478 instruction pattern is available and false otherwise, on the 28479 assumption that hardware floating point supports exceptions and 28480 rounding modes but software floating point does not. 28481 28482 28483File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros 28484 2848517.4 Defining data structures for per-function information. 28486=========================================================== 28487 28488If the target needs to store information on a per-function basis, GCC 28489provides a macro and a couple of variables to allow this. Note, just 28490using statics to store the information is a bad idea, since GCC supports 28491nested functions, so you can be halfway through encoding one function 28492when another one comes along. 28493 28494 GCC defines a data structure called `struct function' which contains 28495all of the data specific to an individual function. This structure 28496contains a field called `machine' whose type is `struct 28497machine_function *', which can be used by targets to point to their own 28498specific data. 28499 28500 If a target needs per-function specific data it should define the type 28501`struct machine_function' and also the macro `INIT_EXPANDERS'. This 28502macro should be used to initialize the function pointer 28503`init_machine_status'. This pointer is explained below. 28504 28505 One typical use of per-function, target specific data is to create an 28506RTX to hold the register containing the function's return address. This 28507RTX can then be used to implement the `__builtin_return_address' 28508function, for level 0. 28509 28510 Note--earlier implementations of GCC used a single data area to hold 28511all of the per-function information. Thus when processing of a nested 28512function began the old per-function data had to be pushed onto a stack, 28513and when the processing was finished, it had to be popped off the 28514stack. GCC used to provide function pointers called 28515`save_machine_status' and `restore_machine_status' to handle the saving 28516and restoring of the target specific information. Since the single 28517data area approach is no longer used, these pointers are no longer 28518supported. 28519 28520 -- Macro: INIT_EXPANDERS 28521 Macro called to initialize any target specific information. This 28522 macro is called once per function, before generation of any RTL 28523 has begun. The intention of this macro is to allow the 28524 initialization of the function pointer `init_machine_status'. 28525 28526 -- Variable: void (*)(struct function *) init_machine_status 28527 If this function pointer is non-`NULL' it will be called once per 28528 function, before function compilation starts, in order to allow the 28529 target to perform any target specific initialization of the 28530 `struct function' structure. It is intended that this would be 28531 used to initialize the `machine' of that structure. 28532 28533 `struct machine_function' structures are expected to be freed by 28534 GC. Generally, any memory that they reference must be allocated 28535 by using GC allocation, including the structure itself. 28536 28537 28538File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros 28539 2854017.5 Storage Layout 28541=================== 28542 28543Note that the definitions of the macros in this table which are sizes or 28544alignments measured in bits do not need to be constant. They can be C 28545expressions that refer to static variables, such as the `target_flags'. 28546*Note Run-time Target::. 28547 28548 -- Macro: BITS_BIG_ENDIAN 28549 Define this macro to have the value 1 if the most significant bit 28550 in a byte has the lowest number; otherwise define it to have the 28551 value zero. This means that bit-field instructions count from the 28552 most significant bit. If the machine has no bit-field 28553 instructions, then this must still be defined, but it doesn't 28554 matter which value it is defined to. This macro need not be a 28555 constant. 28556 28557 This macro does not affect the way structure fields are packed into 28558 bytes or words; that is controlled by `BYTES_BIG_ENDIAN'. 28559 28560 -- Macro: BYTES_BIG_ENDIAN 28561 Define this macro to have the value 1 if the most significant byte 28562 in a word has the lowest number. This macro need not be a 28563 constant. 28564 28565 -- Macro: WORDS_BIG_ENDIAN 28566 Define this macro to have the value 1 if, in a multiword object, 28567 the most significant word has the lowest number. This applies to 28568 both memory locations and registers; see `REG_WORDS_BIG_ENDIAN' if 28569 the order of words in memory is not the same as the order in 28570 registers. This macro need not be a constant. 28571 28572 -- Macro: REG_WORDS_BIG_ENDIAN 28573 On some machines, the order of words in a multiword object differs 28574 between registers in memory. In such a situation, define this 28575 macro to describe the order of words in a register. The macro 28576 `WORDS_BIG_ENDIAN' controls the order of words in memory. 28577 28578 -- Macro: FLOAT_WORDS_BIG_ENDIAN 28579 Define this macro to have the value 1 if `DFmode', `XFmode' or 28580 `TFmode' floating point numbers are stored in memory with the word 28581 containing the sign bit at the lowest address; otherwise define it 28582 to have the value 0. This macro need not be a constant. 28583 28584 You need not define this macro if the ordering is the same as for 28585 multi-word integers. 28586 28587 -- Macro: BITS_PER_WORD 28588 Number of bits in a word. If you do not define this macro, the 28589 default is `BITS_PER_UNIT * UNITS_PER_WORD'. 28590 28591 -- Macro: MAX_BITS_PER_WORD 28592 Maximum number of bits in a word. If this is undefined, the 28593 default is `BITS_PER_WORD'. Otherwise, it is the constant value 28594 that is the largest value that `BITS_PER_WORD' can have at 28595 run-time. 28596 28597 -- Macro: UNITS_PER_WORD 28598 Number of storage units in a word; normally the size of a 28599 general-purpose register, a power of two from 1 or 8. 28600 28601 -- Macro: MIN_UNITS_PER_WORD 28602 Minimum number of units in a word. If this is undefined, the 28603 default is `UNITS_PER_WORD'. Otherwise, it is the constant value 28604 that is the smallest value that `UNITS_PER_WORD' can have at 28605 run-time. 28606 28607 -- Macro: POINTER_SIZE 28608 Width of a pointer, in bits. You must specify a value no wider 28609 than the width of `Pmode'. If it is not equal to the width of 28610 `Pmode', you must define `POINTERS_EXTEND_UNSIGNED'. If you do 28611 not specify a value the default is `BITS_PER_WORD'. 28612 28613 -- Macro: POINTERS_EXTEND_UNSIGNED 28614 A C expression that determines how pointers should be extended from 28615 `ptr_mode' to either `Pmode' or `word_mode'. It is greater than 28616 zero if pointers should be zero-extended, zero if they should be 28617 sign-extended, and negative if some other sort of conversion is 28618 needed. In the last case, the extension is done by the target's 28619 `ptr_extend' instruction. 28620 28621 You need not define this macro if the `ptr_mode', `Pmode' and 28622 `word_mode' are all the same width. 28623 28624 -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE) 28625 A macro to update M and UNSIGNEDP when an object whose type is 28626 TYPE and which has the specified mode and signedness is to be 28627 stored in a register. This macro is only called when TYPE is a 28628 scalar type. 28629 28630 On most RISC machines, which only have operations that operate on 28631 a full register, define this macro to set M to `word_mode' if M is 28632 an integer mode narrower than `BITS_PER_WORD'. In most cases, 28633 only integer modes should be widened because wider-precision 28634 floating-point operations are usually more expensive than their 28635 narrower counterparts. 28636 28637 For most machines, the macro definition does not change UNSIGNEDP. 28638 However, some machines, have instructions that preferentially 28639 handle either signed or unsigned quantities of certain modes. For 28640 example, on the DEC Alpha, 32-bit loads from memory and 32-bit add 28641 instructions sign-extend the result to 64 bits. On such machines, 28642 set UNSIGNEDP according to which kind of extension is more 28643 efficient. 28644 28645 Do not define this macro if it would never modify M. 28646 28647 -- Target Hook: machine_mode TARGET_PROMOTE_FUNCTION_MODE (const_tree 28648 TYPE, machine_mode MODE, int *PUNSIGNEDP, const_tree FUNTYPE, 28649 int FOR_RETURN) 28650 Like `PROMOTE_MODE', but it is applied to outgoing function 28651 arguments or function return values. The target hook should 28652 return the new mode and possibly change `*PUNSIGNEDP' if the 28653 promotion should change signedness. This function is called only 28654 for scalar _or pointer_ types. 28655 28656 FOR_RETURN allows to distinguish the promotion of arguments and 28657 return values. If it is `1', a return value is being promoted and 28658 `TARGET_FUNCTION_VALUE' must perform the same promotions done here. 28659 If it is `2', the returned mode should be that of the register in 28660 which an incoming parameter is copied, or the outgoing result is 28661 computed; then the hook should return the same mode as 28662 `promote_mode', though the signedness may be different. 28663 28664 TYPE can be NULL when promoting function arguments of libcalls. 28665 28666 The default is to not promote arguments and return values. You can 28667 also define the hook to 28668 `default_promote_function_mode_always_promote' if you would like 28669 to apply the same rules given by `PROMOTE_MODE'. 28670 28671 -- Macro: PARM_BOUNDARY 28672 Normal alignment required for function parameters on the stack, in 28673 bits. All stack parameters receive at least this much alignment 28674 regardless of data type. On most machines, this is the same as the 28675 size of an integer. 28676 28677 -- Macro: STACK_BOUNDARY 28678 Define this macro to the minimum alignment enforced by hardware 28679 for the stack pointer on this machine. The definition is a C 28680 expression for the desired alignment (measured in bits). This 28681 value is used as a default if `PREFERRED_STACK_BOUNDARY' is not 28682 defined. On most machines, this should be the same as 28683 `PARM_BOUNDARY'. 28684 28685 -- Macro: PREFERRED_STACK_BOUNDARY 28686 Define this macro if you wish to preserve a certain alignment for 28687 the stack pointer, greater than what the hardware enforces. The 28688 definition is a C expression for the desired alignment (measured 28689 in bits). This macro must evaluate to a value equal to or larger 28690 than `STACK_BOUNDARY'. 28691 28692 -- Macro: INCOMING_STACK_BOUNDARY 28693 Define this macro if the incoming stack boundary may be different 28694 from `PREFERRED_STACK_BOUNDARY'. This macro must evaluate to a 28695 value equal to or larger than `STACK_BOUNDARY'. 28696 28697 -- Macro: FUNCTION_BOUNDARY 28698 Alignment required for a function entry point, in bits. 28699 28700 -- Macro: BIGGEST_ALIGNMENT 28701 Biggest alignment that any data type can require on this machine, 28702 in bits. Note that this is not the biggest alignment that is 28703 supported, just the biggest alignment that, when violated, may 28704 cause a fault. 28705 28706 -- Target Hook: HOST_WIDE_INT TARGET_ABSOLUTE_BIGGEST_ALIGNMENT 28707 If defined, this target hook specifies the absolute biggest 28708 alignment that a type or variable can have on this machine, 28709 otherwise, `BIGGEST_ALIGNMENT' is used. 28710 28711 -- Macro: MALLOC_ABI_ALIGNMENT 28712 Alignment, in bits, a C conformant malloc implementation has to 28713 provide. If not defined, the default value is `BITS_PER_WORD'. 28714 28715 -- Macro: ATTRIBUTE_ALIGNED_VALUE 28716 Alignment used by the `__attribute__ ((aligned))' construct. If 28717 not defined, the default value is `BIGGEST_ALIGNMENT'. 28718 28719 -- Macro: MINIMUM_ATOMIC_ALIGNMENT 28720 If defined, the smallest alignment, in bits, that can be given to 28721 an object that can be referenced in one operation, without 28722 disturbing any nearby object. Normally, this is `BITS_PER_UNIT', 28723 but may be larger on machines that don't have byte or half-word 28724 store operations. 28725 28726 -- Macro: BIGGEST_FIELD_ALIGNMENT 28727 Biggest alignment that any structure or union field can require on 28728 this machine, in bits. If defined, this overrides 28729 `BIGGEST_ALIGNMENT' for structure and union fields only, unless 28730 the field alignment has been set by the `__attribute__ ((aligned 28731 (N)))' construct. 28732 28733 -- Macro: ADJUST_FIELD_ALIGN (FIELD, COMPUTED) 28734 An expression for the alignment of a structure field FIELD if the 28735 alignment computed in the usual way (including applying of 28736 `BIGGEST_ALIGNMENT' and `BIGGEST_FIELD_ALIGNMENT' to the 28737 alignment) is COMPUTED. It overrides alignment only if the field 28738 alignment has not been set by the `__attribute__ ((aligned (N)))' 28739 construct. 28740 28741 -- Macro: MAX_STACK_ALIGNMENT 28742 Biggest stack alignment guaranteed by the backend. Use this macro 28743 to specify the maximum alignment of a variable on stack. 28744 28745 If not defined, the default value is `STACK_BOUNDARY'. 28746 28747 28748 -- Macro: MAX_OFILE_ALIGNMENT 28749 Biggest alignment supported by the object file format of this 28750 machine. Use this macro to limit the alignment which can be 28751 specified using the `__attribute__ ((aligned (N)))' construct. If 28752 not defined, the default value is `BIGGEST_ALIGNMENT'. 28753 28754 On systems that use ELF, the default (in `config/elfos.h') is the 28755 largest supported 32-bit ELF section alignment representable on a 28756 32-bit host e.g. `(((uint64_t) 1 << 28) * 8)'. On 32-bit ELF the 28757 largest supported section alignment in bits is `(0x80000000 * 8)', 28758 but this is not representable on 32-bit hosts. 28759 28760 -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN) 28761 If defined, a C expression to compute the alignment for a variable 28762 in the static store. TYPE is the data type, and BASIC-ALIGN is 28763 the alignment that the object would ordinarily have. The value of 28764 this macro is used instead of that alignment to align the object. 28765 28766 If this macro is not defined, then BASIC-ALIGN is used. 28767 28768 One use of this macro is to increase alignment of medium-size data 28769 to make it all fit in fewer cache lines. Another is to cause 28770 character arrays to be word-aligned so that `strcpy' calls that 28771 copy constants to character arrays can be done inline. 28772 28773 -- Macro: DATA_ABI_ALIGNMENT (TYPE, BASIC-ALIGN) 28774 Similar to `DATA_ALIGNMENT', but for the cases where the ABI 28775 mandates some alignment increase, instead of optimization only 28776 purposes. E.g. AMD x86-64 psABI says that variables with array 28777 type larger than 15 bytes must be aligned to 16 byte boundaries. 28778 28779 If this macro is not defined, then BASIC-ALIGN is used. 28780 28781 -- Macro: CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN) 28782 If defined, a C expression to compute the alignment given to a 28783 constant that is being placed in memory. CONSTANT is the constant 28784 and BASIC-ALIGN is the alignment that the object would ordinarily 28785 have. The value of this macro is used instead of that alignment to 28786 align the object. 28787 28788 If this macro is not defined, then BASIC-ALIGN is used. 28789 28790 The typical use of this macro is to increase alignment for string 28791 constants to be word aligned so that `strcpy' calls that copy 28792 constants can be done inline. 28793 28794 -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN) 28795 If defined, a C expression to compute the alignment for a variable 28796 in the local store. TYPE is the data type, and BASIC-ALIGN is the 28797 alignment that the object would ordinarily have. The value of this 28798 macro is used instead of that alignment to align the object. 28799 28800 If this macro is not defined, then BASIC-ALIGN is used. 28801 28802 One use of this macro is to increase alignment of medium-size data 28803 to make it all fit in fewer cache lines. 28804 28805 If the value of this macro has a type, it should be an unsigned 28806 type. 28807 28808 -- Target Hook: HOST_WIDE_INT TARGET_VECTOR_ALIGNMENT (const_tree TYPE) 28809 This hook can be used to define the alignment for a vector of type 28810 TYPE, in order to comply with a platform ABI. The default is to 28811 require natural alignment for vector types. The alignment 28812 returned by this hook must be a power-of-two multiple of the 28813 default alignment of the vector element type. 28814 28815 -- Macro: STACK_SLOT_ALIGNMENT (TYPE, MODE, BASIC-ALIGN) 28816 If defined, a C expression to compute the alignment for stack slot. 28817 TYPE is the data type, MODE is the widest mode available, and 28818 BASIC-ALIGN is the alignment that the slot would ordinarily have. 28819 The value of this macro is used instead of that alignment to align 28820 the slot. 28821 28822 If this macro is not defined, then BASIC-ALIGN is used when TYPE 28823 is `NULL'. Otherwise, `LOCAL_ALIGNMENT' will be used. 28824 28825 This macro is to set alignment of stack slot to the maximum 28826 alignment of all possible modes which the slot may have. 28827 28828 If the value of this macro has a type, it should be an unsigned 28829 type. 28830 28831 -- Macro: LOCAL_DECL_ALIGNMENT (DECL) 28832 If defined, a C expression to compute the alignment for a local 28833 variable DECL. 28834 28835 If this macro is not defined, then `LOCAL_ALIGNMENT (TREE_TYPE 28836 (DECL), DECL_ALIGN (DECL))' is used. 28837 28838 One use of this macro is to increase alignment of medium-size data 28839 to make it all fit in fewer cache lines. 28840 28841 If the value of this macro has a type, it should be an unsigned 28842 type. 28843 28844 -- Macro: MINIMUM_ALIGNMENT (EXP, MODE, ALIGN) 28845 If defined, a C expression to compute the minimum required 28846 alignment for dynamic stack realignment purposes for EXP (a type 28847 or decl), MODE, assuming normal alignment ALIGN. 28848 28849 If this macro is not defined, then ALIGN will be used. 28850 28851 -- Macro: EMPTY_FIELD_BOUNDARY 28852 Alignment in bits to be given to a structure bit-field that 28853 follows an empty field such as `int : 0;'. 28854 28855 If `PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro. 28856 28857 -- Macro: STRUCTURE_SIZE_BOUNDARY 28858 Number of bits which any structure or union's size must be a 28859 multiple of. Each structure or union's size is rounded up to a 28860 multiple of this. 28861 28862 If you do not define this macro, the default is the same as 28863 `BITS_PER_UNIT'. 28864 28865 -- Macro: STRICT_ALIGNMENT 28866 Define this macro to be the value 1 if instructions will fail to 28867 work if given data not on the nominal alignment. If instructions 28868 will merely go slower in that case, define this macro as 0. 28869 28870 -- Macro: PCC_BITFIELD_TYPE_MATTERS 28871 Define this if you wish to imitate the way many other C compilers 28872 handle alignment of bit-fields and the structures that contain 28873 them. 28874 28875 The behavior is that the type written for a named bit-field (`int', 28876 `short', or other integer type) imposes an alignment for the entire 28877 structure, as if the structure really did contain an ordinary 28878 field of that type. In addition, the bit-field is placed within 28879 the structure so that it would fit within such a field, not 28880 crossing a boundary for it. 28881 28882 Thus, on most machines, a named bit-field whose type is written as 28883 `int' would not cross a four-byte boundary, and would force 28884 four-byte alignment for the whole structure. (The alignment used 28885 may not be four bytes; it is controlled by the other alignment 28886 parameters.) 28887 28888 An unnamed bit-field will not affect the alignment of the 28889 containing structure. 28890 28891 If the macro is defined, its definition should be a C expression; 28892 a nonzero value for the expression enables this behavior. 28893 28894 Note that if this macro is not defined, or its value is zero, some 28895 bit-fields may cross more than one alignment boundary. The 28896 compiler can support such references if there are `insv', `extv', 28897 and `extzv' insns that can directly reference memory. 28898 28899 The other known way of making bit-fields work is to define 28900 `STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'. Then 28901 every structure can be accessed with fullwords. 28902 28903 Unless the machine has bit-field instructions or you define 28904 `STRUCTURE_SIZE_BOUNDARY' that way, you must define 28905 `PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value. 28906 28907 If your aim is to make GCC use the same conventions for laying out 28908 bit-fields as are used by another compiler, here is how to 28909 investigate what the other compiler does. Compile and run this 28910 program: 28911 28912 struct foo1 28913 { 28914 char x; 28915 char :0; 28916 char y; 28917 }; 28918 28919 struct foo2 28920 { 28921 char x; 28922 int :0; 28923 char y; 28924 }; 28925 28926 main () 28927 { 28928 printf ("Size of foo1 is %d\n", 28929 sizeof (struct foo1)); 28930 printf ("Size of foo2 is %d\n", 28931 sizeof (struct foo2)); 28932 exit (0); 28933 } 28934 28935 If this prints 2 and 5, then the compiler's behavior is what you 28936 would get from `PCC_BITFIELD_TYPE_MATTERS'. 28937 28938 -- Macro: BITFIELD_NBYTES_LIMITED 28939 Like `PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited 28940 to aligning a bit-field within the structure. 28941 28942 -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELD (void) 28943 When `PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine 28944 whether unnamed bitfields affect the alignment of the containing 28945 structure. The hook should return true if the structure should 28946 inherit the alignment requirements of an unnamed bitfield's type. 28947 28948 -- Target Hook: bool TARGET_NARROW_VOLATILE_BITFIELD (void) 28949 This target hook should return `true' if accesses to volatile 28950 bitfields should use the narrowest mode possible. It should 28951 return `false' if these accesses should use the bitfield container 28952 type. 28953 28954 The default is `false'. 28955 28956 -- Target Hook: bool TARGET_MEMBER_TYPE_FORCES_BLK (const_tree FIELD, 28957 machine_mode MODE) 28958 Return true if a structure, union or array containing FIELD should 28959 be accessed using `BLKMODE'. 28960 28961 If FIELD is the only field in the structure, MODE is its mode, 28962 otherwise MODE is VOIDmode. MODE is provided in the case where 28963 structures of one field would require the structure's mode to 28964 retain the field's mode. 28965 28966 Normally, this is not needed. 28967 28968 -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED) 28969 Define this macro as an expression for the alignment of a type 28970 (given by TYPE as a tree node) if the alignment computed in the 28971 usual way is COMPUTED and the alignment explicitly specified was 28972 SPECIFIED. 28973 28974 The default is to use SPECIFIED if it is larger; otherwise, use 28975 the smaller of COMPUTED and `BIGGEST_ALIGNMENT' 28976 28977 -- Macro: MAX_FIXED_MODE_SIZE 28978 An integer expression for the size in bits of the largest integer 28979 machine mode that should actually be used. All integer machine 28980 modes of this size or smaller can be used for structures and 28981 unions with the appropriate sizes. If this macro is undefined, 28982 `GET_MODE_BITSIZE (DImode)' is assumed. 28983 28984 -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL) 28985 If defined, an expression of type `machine_mode' that specifies 28986 the mode of the save area operand of a `save_stack_LEVEL' named 28987 pattern (*note Standard Names::). SAVE_LEVEL is one of 28988 `SAVE_BLOCK', `SAVE_FUNCTION', or `SAVE_NONLOCAL' and selects 28989 which of the three named patterns is having its mode specified. 28990 28991 You need not define this macro if it always returns `Pmode'. You 28992 would most commonly define this macro if the `save_stack_LEVEL' 28993 patterns need to support both a 32- and a 64-bit mode. 28994 28995 -- Macro: STACK_SIZE_MODE 28996 If defined, an expression of type `machine_mode' that specifies 28997 the mode of the size increment operand of an `allocate_stack' 28998 named pattern (*note Standard Names::). 28999 29000 You need not define this macro if it always returns `word_mode'. 29001 You would most commonly define this macro if the `allocate_stack' 29002 pattern needs to support both a 32- and a 64-bit mode. 29003 29004 -- Target Hook: machine_mode TARGET_LIBGCC_CMP_RETURN_MODE (void) 29005 This target hook should return the mode to be used for the return 29006 value of compare instructions expanded to libgcc calls. If not 29007 defined `word_mode' is returned which is the right choice for a 29008 majority of targets. 29009 29010 -- Target Hook: machine_mode TARGET_LIBGCC_SHIFT_COUNT_MODE (void) 29011 This target hook should return the mode to be used for the shift 29012 count operand of shift instructions expanded to libgcc calls. If 29013 not defined `word_mode' is returned which is the right choice for 29014 a majority of targets. 29015 29016 -- Target Hook: machine_mode TARGET_UNWIND_WORD_MODE (void) 29017 Return machine mode to be used for `_Unwind_Word' type. The 29018 default is to use `word_mode'. 29019 29020 -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (const_tree 29021 RECORD_TYPE) 29022 This target hook returns `true' if bit-fields in the given 29023 RECORD_TYPE are to be laid out following the rules of Microsoft 29024 Visual C/C++, namely: (i) a bit-field won't share the same storage 29025 unit with the previous bit-field if their underlying types have 29026 different sizes, and the bit-field will be aligned to the highest 29027 alignment of the underlying types of itself and of the previous 29028 bit-field; (ii) a zero-sized bit-field will affect the alignment of 29029 the whole enclosing structure, even if it is unnamed; except that 29030 (iii) a zero-sized bit-field will be disregarded unless it follows 29031 another bit-field of nonzero size. If this hook returns `true', 29032 other macros that control bit-field layout are ignored. 29033 29034 When a bit-field is inserted into a packed record, the whole size 29035 of the underlying type is used by one or more same-size adjacent 29036 bit-fields (that is, if its long:3, 32 bits is used in the record, 29037 and any additional adjacent long bit-fields are packed into the 29038 same chunk of 32 bits. However, if the size changes, a new field 29039 of that size is allocated). In an unpacked record, this is the 29040 same as using alignment, but not equivalent when packing. 29041 29042 If both MS bit-fields and `__attribute__((packed))' are used, the 29043 latter will take precedence. If `__attribute__((packed))' is used 29044 on a single field when MS bit-fields are in use, it will take 29045 precedence for that field, but the alignment of the rest of the 29046 structure may affect its placement. 29047 29048 -- Target Hook: bool TARGET_DECIMAL_FLOAT_SUPPORTED_P (void) 29049 Returns true if the target supports decimal floating point. 29050 29051 -- Target Hook: bool TARGET_FIXED_POINT_SUPPORTED_P (void) 29052 Returns true if the target supports fixed-point arithmetic. 29053 29054 -- Target Hook: void TARGET_EXPAND_TO_RTL_HOOK (void) 29055 This hook is called just before expansion into rtl, allowing the 29056 target to perform additional initializations or analysis before 29057 the expansion. For example, the rs6000 port uses it to allocate a 29058 scratch stack slot for use in copying SDmode values between memory 29059 and floating point registers whenever the function being expanded 29060 has any SDmode usage. 29061 29062 -- Target Hook: void TARGET_INSTANTIATE_DECLS (void) 29063 This hook allows the backend to perform additional instantiations 29064 on rtl that are not actually in any insns yet, but will be later. 29065 29066 -- Target Hook: const char * TARGET_MANGLE_TYPE (const_tree TYPE) 29067 If your target defines any fundamental types, or any types your 29068 target uses should be mangled differently from the default, define 29069 this hook to return the appropriate encoding for these types as 29070 part of a C++ mangled name. The TYPE argument is the tree 29071 structure representing the type to be mangled. The hook may be 29072 applied to trees which are not target-specific fundamental types; 29073 it should return `NULL' for all such types, as well as arguments 29074 it does not recognize. If the return value is not `NULL', it must 29075 point to a statically-allocated string constant. 29076 29077 Target-specific fundamental types might be new fundamental types or 29078 qualified versions of ordinary fundamental types. Encode new 29079 fundamental types as `u N NAME', where NAME is the name used for 29080 the type in source code, and N is the length of NAME in decimal. 29081 Encode qualified versions of ordinary types as `U N NAME CODE', 29082 where NAME is the name used for the type qualifier in source code, 29083 N is the length of NAME as above, and CODE is the code used to 29084 represent the unqualified version of this type. (See 29085 `write_builtin_type' in `cp/mangle.c' for the list of codes.) In 29086 both cases the spaces are for clarity; do not include any spaces 29087 in your string. 29088 29089 This hook is applied to types prior to typedef resolution. If the 29090 mangled name for a particular type depends only on that type's 29091 main variant, you can perform typedef resolution yourself using 29092 `TYPE_MAIN_VARIANT' before mangling. 29093 29094 The default version of this hook always returns `NULL', which is 29095 appropriate for a target that does not define any new fundamental 29096 types. 29097 29098 29099File: gccint.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros 29100 2910117.6 Layout of Source Language Data Types 29102========================================= 29103 29104These macros define the sizes and other characteristics of the standard 29105basic data types used in programs being compiled. Unlike the macros in 29106the previous section, these apply to specific features of C and related 29107languages, rather than to fundamental aspects of storage layout. 29108 29109 -- Macro: INT_TYPE_SIZE 29110 A C expression for the size in bits of the type `int' on the 29111 target machine. If you don't define this, the default is one word. 29112 29113 -- Macro: SHORT_TYPE_SIZE 29114 A C expression for the size in bits of the type `short' on the 29115 target machine. If you don't define this, the default is half a 29116 word. (If this would be less than one storage unit, it is rounded 29117 up to one unit.) 29118 29119 -- Macro: LONG_TYPE_SIZE 29120 A C expression for the size in bits of the type `long' on the 29121 target machine. If you don't define this, the default is one word. 29122 29123 -- Macro: ADA_LONG_TYPE_SIZE 29124 On some machines, the size used for the Ada equivalent of the type 29125 `long' by a native Ada compiler differs from that used by C. In 29126 that situation, define this macro to be a C expression to be used 29127 for the size of that type. If you don't define this, the default 29128 is the value of `LONG_TYPE_SIZE'. 29129 29130 -- Macro: LONG_LONG_TYPE_SIZE 29131 A C expression for the size in bits of the type `long long' on the 29132 target machine. If you don't define this, the default is two 29133 words. If you want to support GNU Ada on your machine, the value 29134 of this macro must be at least 64. 29135 29136 -- Macro: CHAR_TYPE_SIZE 29137 A C expression for the size in bits of the type `char' on the 29138 target machine. If you don't define this, the default is 29139 `BITS_PER_UNIT'. 29140 29141 -- Macro: BOOL_TYPE_SIZE 29142 A C expression for the size in bits of the C++ type `bool' and C99 29143 type `_Bool' on the target machine. If you don't define this, and 29144 you probably shouldn't, the default is `CHAR_TYPE_SIZE'. 29145 29146 -- Macro: FLOAT_TYPE_SIZE 29147 A C expression for the size in bits of the type `float' on the 29148 target machine. If you don't define this, the default is one word. 29149 29150 -- Macro: DOUBLE_TYPE_SIZE 29151 A C expression for the size in bits of the type `double' on the 29152 target machine. If you don't define this, the default is two 29153 words. 29154 29155 -- Macro: LONG_DOUBLE_TYPE_SIZE 29156 A C expression for the size in bits of the type `long double' on 29157 the target machine. If you don't define this, the default is two 29158 words. 29159 29160 -- Macro: SHORT_FRACT_TYPE_SIZE 29161 A C expression for the size in bits of the type `short _Fract' on 29162 the target machine. If you don't define this, the default is 29163 `BITS_PER_UNIT'. 29164 29165 -- Macro: FRACT_TYPE_SIZE 29166 A C expression for the size in bits of the type `_Fract' on the 29167 target machine. If you don't define this, the default is 29168 `BITS_PER_UNIT * 2'. 29169 29170 -- Macro: LONG_FRACT_TYPE_SIZE 29171 A C expression for the size in bits of the type `long _Fract' on 29172 the target machine. If you don't define this, the default is 29173 `BITS_PER_UNIT * 4'. 29174 29175 -- Macro: LONG_LONG_FRACT_TYPE_SIZE 29176 A C expression for the size in bits of the type `long long _Fract' 29177 on the target machine. If you don't define this, the default is 29178 `BITS_PER_UNIT * 8'. 29179 29180 -- Macro: SHORT_ACCUM_TYPE_SIZE 29181 A C expression for the size in bits of the type `short _Accum' on 29182 the target machine. If you don't define this, the default is 29183 `BITS_PER_UNIT * 2'. 29184 29185 -- Macro: ACCUM_TYPE_SIZE 29186 A C expression for the size in bits of the type `_Accum' on the 29187 target machine. If you don't define this, the default is 29188 `BITS_PER_UNIT * 4'. 29189 29190 -- Macro: LONG_ACCUM_TYPE_SIZE 29191 A C expression for the size in bits of the type `long _Accum' on 29192 the target machine. If you don't define this, the default is 29193 `BITS_PER_UNIT * 8'. 29194 29195 -- Macro: LONG_LONG_ACCUM_TYPE_SIZE 29196 A C expression for the size in bits of the type `long long _Accum' 29197 on the target machine. If you don't define this, the default is 29198 `BITS_PER_UNIT * 16'. 29199 29200 -- Macro: LIBGCC2_GNU_PREFIX 29201 This macro corresponds to the `TARGET_LIBFUNC_GNU_PREFIX' target 29202 hook and should be defined if that hook is overriden to be true. 29203 It causes function names in libgcc to be changed to use a `__gnu_' 29204 prefix for their name rather than the default `__'. A port which 29205 uses this macro should also arrange to use `t-gnu-prefix' in the 29206 libgcc `config.host'. 29207 29208 -- Macro: TARGET_FLT_EVAL_METHOD 29209 A C expression for the value for `FLT_EVAL_METHOD' in `float.h', 29210 assuming, if applicable, that the floating-point control word is 29211 in its default state. If you do not define this macro the value of 29212 `FLT_EVAL_METHOD' will be zero. 29213 29214 -- Macro: WIDEST_HARDWARE_FP_SIZE 29215 A C expression for the size in bits of the widest floating-point 29216 format supported by the hardware. If you define this macro, you 29217 must specify a value less than or equal to the value of 29218 `LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the 29219 value of `LONG_DOUBLE_TYPE_SIZE' is the default. 29220 29221 -- Macro: DEFAULT_SIGNED_CHAR 29222 An expression whose value is 1 or 0, according to whether the type 29223 `char' should be signed or unsigned by default. The user can 29224 always override this default with the options `-fsigned-char' and 29225 `-funsigned-char'. 29226 29227 -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void) 29228 This target hook should return true if the compiler should give an 29229 `enum' type only as many bytes as it takes to represent the range 29230 of possible values of that type. It should return false if all 29231 `enum' types should be allocated like `int'. 29232 29233 The default is to return false. 29234 29235 -- Macro: SIZE_TYPE 29236 A C expression for a string describing the name of the data type 29237 to use for size values. The typedef name `size_t' is defined 29238 using the contents of the string. 29239 29240 The string can contain more than one keyword. If so, separate 29241 them with spaces, and write first any length keyword, then 29242 `unsigned' if appropriate, and finally `int'. The string must 29243 exactly match one of the data type names defined in the function 29244 `c_common_nodes_and_builtins' in the file `c-family/c-common.c'. 29245 You may not omit `int' or change the order--that would cause the 29246 compiler to crash on startup. 29247 29248 If you don't define this macro, the default is `"long unsigned 29249 int"'. 29250 29251 -- Macro: SIZETYPE 29252 GCC defines internal types (`sizetype', `ssizetype', `bitsizetype' 29253 and `sbitsizetype') for expressions dealing with size. This macro 29254 is a C expression for a string describing the name of the data 29255 type from which the precision of `sizetype' is extracted. 29256 29257 The string has the same restrictions as `SIZE_TYPE' string. 29258 29259 If you don't define this macro, the default is `SIZE_TYPE'. 29260 29261 -- Macro: PTRDIFF_TYPE 29262 A C expression for a string describing the name of the data type 29263 to use for the result of subtracting two pointers. The typedef 29264 name `ptrdiff_t' is defined using the contents of the string. See 29265 `SIZE_TYPE' above for more information. 29266 29267 If you don't define this macro, the default is `"long int"'. 29268 29269 -- Macro: WCHAR_TYPE 29270 A C expression for a string describing the name of the data type 29271 to use for wide characters. The typedef name `wchar_t' is defined 29272 using the contents of the string. See `SIZE_TYPE' above for more 29273 information. 29274 29275 If you don't define this macro, the default is `"int"'. 29276 29277 -- Macro: WCHAR_TYPE_SIZE 29278 A C expression for the size in bits of the data type for wide 29279 characters. This is used in `cpp', which cannot make use of 29280 `WCHAR_TYPE'. 29281 29282 -- Macro: WINT_TYPE 29283 A C expression for a string describing the name of the data type to 29284 use for wide characters passed to `printf' and returned from 29285 `getwc'. The typedef name `wint_t' is defined using the contents 29286 of the string. See `SIZE_TYPE' above for more information. 29287 29288 If you don't define this macro, the default is `"unsigned int"'. 29289 29290 -- Macro: INTMAX_TYPE 29291 A C expression for a string describing the name of the data type 29292 that can represent any value of any standard or extended signed 29293 integer type. The typedef name `intmax_t' is defined using the 29294 contents of the string. See `SIZE_TYPE' above for more 29295 information. 29296 29297 If you don't define this macro, the default is the first of 29298 `"int"', `"long int"', or `"long long int"' that has as much 29299 precision as `long long int'. 29300 29301 -- Macro: UINTMAX_TYPE 29302 A C expression for a string describing the name of the data type 29303 that can represent any value of any standard or extended unsigned 29304 integer type. The typedef name `uintmax_t' is defined using the 29305 contents of the string. See `SIZE_TYPE' above for more 29306 information. 29307 29308 If you don't define this macro, the default is the first of 29309 `"unsigned int"', `"long unsigned int"', or `"long long unsigned 29310 int"' that has as much precision as `long long unsigned int'. 29311 29312 -- Macro: SIG_ATOMIC_TYPE 29313 -- Macro: INT8_TYPE 29314 -- Macro: INT16_TYPE 29315 -- Macro: INT32_TYPE 29316 -- Macro: INT64_TYPE 29317 -- Macro: UINT8_TYPE 29318 -- Macro: UINT16_TYPE 29319 -- Macro: UINT32_TYPE 29320 -- Macro: UINT64_TYPE 29321 -- Macro: INT_LEAST8_TYPE 29322 -- Macro: INT_LEAST16_TYPE 29323 -- Macro: INT_LEAST32_TYPE 29324 -- Macro: INT_LEAST64_TYPE 29325 -- Macro: UINT_LEAST8_TYPE 29326 -- Macro: UINT_LEAST16_TYPE 29327 -- Macro: UINT_LEAST32_TYPE 29328 -- Macro: UINT_LEAST64_TYPE 29329 -- Macro: INT_FAST8_TYPE 29330 -- Macro: INT_FAST16_TYPE 29331 -- Macro: INT_FAST32_TYPE 29332 -- Macro: INT_FAST64_TYPE 29333 -- Macro: UINT_FAST8_TYPE 29334 -- Macro: UINT_FAST16_TYPE 29335 -- Macro: UINT_FAST32_TYPE 29336 -- Macro: UINT_FAST64_TYPE 29337 -- Macro: INTPTR_TYPE 29338 -- Macro: UINTPTR_TYPE 29339 C expressions for the standard types `sig_atomic_t', `int8_t', 29340 `int16_t', `int32_t', `int64_t', `uint8_t', `uint16_t', 29341 `uint32_t', `uint64_t', `int_least8_t', `int_least16_t', 29342 `int_least32_t', `int_least64_t', `uint_least8_t', 29343 `uint_least16_t', `uint_least32_t', `uint_least64_t', 29344 `int_fast8_t', `int_fast16_t', `int_fast32_t', `int_fast64_t', 29345 `uint_fast8_t', `uint_fast16_t', `uint_fast32_t', `uint_fast64_t', 29346 `intptr_t', and `uintptr_t'. See `SIZE_TYPE' above for more 29347 information. 29348 29349 If any of these macros evaluates to a null pointer, the 29350 corresponding type is not supported; if GCC is configured to 29351 provide `<stdint.h>' in such a case, the header provided may not 29352 conform to C99, depending on the type in question. The defaults 29353 for all of these macros are null pointers. 29354 29355 -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION 29356 The C++ compiler represents a pointer-to-member-function with a 29357 struct that looks like: 29358 29359 struct { 29360 union { 29361 void (*fn)(); 29362 ptrdiff_t vtable_index; 29363 }; 29364 ptrdiff_t delta; 29365 }; 29366 29367 The C++ compiler must use one bit to indicate whether the function 29368 that will be called through a pointer-to-member-function is 29369 virtual. Normally, we assume that the low-order bit of a function 29370 pointer must always be zero. Then, by ensuring that the 29371 vtable_index is odd, we can distinguish which variant of the union 29372 is in use. But, on some platforms function pointers can be odd, 29373 and so this doesn't work. In that case, we use the low-order bit 29374 of the `delta' field, and shift the remainder of the `delta' field 29375 to the left. 29376 29377 GCC will automatically make the right selection about where to 29378 store this bit using the `FUNCTION_BOUNDARY' setting for your 29379 platform. However, some platforms such as ARM/Thumb have 29380 `FUNCTION_BOUNDARY' set such that functions always start at even 29381 addresses, but the lowest bit of pointers to functions indicate 29382 whether the function at that address is in ARM or Thumb mode. If 29383 this is the case of your architecture, you should define this 29384 macro to `ptrmemfunc_vbit_in_delta'. 29385 29386 In general, you should not have to define this macro. On 29387 architectures in which function addresses are always even, 29388 according to `FUNCTION_BOUNDARY', GCC will automatically define 29389 this macro to `ptrmemfunc_vbit_in_pfn'. 29390 29391 -- Macro: TARGET_VTABLE_USES_DESCRIPTORS 29392 Normally, the C++ compiler uses function pointers in vtables. This 29393 macro allows the target to change to use "function descriptors" 29394 instead. Function descriptors are found on targets for whom a 29395 function pointer is actually a small data structure. Normally the 29396 data structure consists of the actual code address plus a data 29397 pointer to which the function's data is relative. 29398 29399 If vtables are used, the value of this macro should be the number 29400 of words that the function descriptor occupies. 29401 29402 -- Macro: TARGET_VTABLE_ENTRY_ALIGN 29403 By default, the vtable entries are void pointers, the so the 29404 alignment is the same as pointer alignment. The value of this 29405 macro specifies the alignment of the vtable entry in bits. It 29406 should be defined only when special alignment is necessary. */ 29407 29408 -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE 29409 There are a few non-descriptor entries in the vtable at offsets 29410 below zero. If these entries must be padded (say, to preserve the 29411 alignment specified by `TARGET_VTABLE_ENTRY_ALIGN'), set this to 29412 the number of words in each data entry. 29413 29414 29415File: gccint.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros 29416 2941717.7 Register Usage 29418=================== 29419 29420This section explains how to describe what registers the target machine 29421has, and how (in general) they can be used. 29422 29423 The description of which registers a specific instruction can use is 29424done with register classes; see *note Register Classes::. For 29425information on using registers to access a stack frame, see *note Frame 29426Registers::. For passing values in registers, see *note Register 29427Arguments::. For returning values in registers, see *note Scalar 29428Return::. 29429 29430* Menu: 29431 29432* Register Basics:: Number and kinds of registers. 29433* Allocation Order:: Order in which registers are allocated. 29434* Values in Registers:: What kinds of values each reg can hold. 29435* Leaf Functions:: Renumbering registers for leaf functions. 29436* Stack Registers:: Handling a register stack such as 80387. 29437 29438 29439File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers 29440 2944117.7.1 Basic Characteristics of Registers 29442----------------------------------------- 29443 29444Registers have various characteristics. 29445 29446 -- Macro: FIRST_PSEUDO_REGISTER 29447 Number of hardware registers known to the compiler. They receive 29448 numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first 29449 pseudo register's number really is assigned the number 29450 `FIRST_PSEUDO_REGISTER'. 29451 29452 -- Macro: FIXED_REGISTERS 29453 An initializer that says which registers are used for fixed 29454 purposes all throughout the compiled code and are therefore not 29455 available for general allocation. These would include the stack 29456 pointer, the frame pointer (except on machines where that can be 29457 used as a general register when no frame pointer is needed), the 29458 program counter on machines where that is considered one of the 29459 addressable registers, and any other numbered register with a 29460 standard use. 29461 29462 This information is expressed as a sequence of numbers, separated 29463 by commas and surrounded by braces. The Nth number is 1 if 29464 register N is fixed, 0 otherwise. 29465 29466 The table initialized from this macro, and the table initialized by 29467 the following one, may be overridden at run time either 29468 automatically, by the actions of the macro 29469 `CONDITIONAL_REGISTER_USAGE', or by the user with the command 29470 options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'. 29471 29472 -- Macro: CALL_USED_REGISTERS 29473 Like `FIXED_REGISTERS' but has 1 for each register that is 29474 clobbered (in general) by function calls as well as for fixed 29475 registers. This macro therefore identifies the registers that are 29476 not available for general allocation of values that must live 29477 across function calls. 29478 29479 If a register has 0 in `CALL_USED_REGISTERS', the compiler 29480 automatically saves it on function entry and restores it on 29481 function exit, if the register is used within the function. 29482 29483 -- Macro: CALL_REALLY_USED_REGISTERS 29484 Like `CALL_USED_REGISTERS' except this macro doesn't require that 29485 the entire set of `FIXED_REGISTERS' be included. 29486 (`CALL_USED_REGISTERS' must be a superset of `FIXED_REGISTERS'). 29487 This macro is optional. If not specified, it defaults to the value 29488 of `CALL_USED_REGISTERS'. 29489 29490 -- Macro: HARD_REGNO_CALL_PART_CLOBBERED (REGNO, MODE) 29491 A C expression that is nonzero if it is not permissible to store a 29492 value of mode MODE in hard register number REGNO across a call 29493 without some part of it being clobbered. For most machines this 29494 macro need not be defined. It is only required for machines that 29495 do not preserve the entire contents of a register across a call. 29496 29497 -- Target Hook: void TARGET_CONDITIONAL_REGISTER_USAGE (void) 29498 This hook may conditionally modify five variables `fixed_regs', 29499 `call_used_regs', `global_regs', `reg_names', and 29500 `reg_class_contents', to take into account any dependence of these 29501 register sets on target flags. The first three of these are of 29502 type `char []' (interpreted as Boolean vectors). `global_regs' is 29503 a `const char *[]', and `reg_class_contents' is a `HARD_REG_SET'. 29504 Before the macro is called, `fixed_regs', `call_used_regs', 29505 `reg_class_contents', and `reg_names' have been initialized from 29506 `FIXED_REGISTERS', `CALL_USED_REGISTERS', `REG_CLASS_CONTENTS', 29507 and `REGISTER_NAMES', respectively. `global_regs' has been 29508 cleared, and any `-ffixed-REG', `-fcall-used-REG' and 29509 `-fcall-saved-REG' command options have been applied. 29510 29511 If the usage of an entire class of registers depends on the target 29512 flags, you may indicate this to GCC by using this macro to modify 29513 `fixed_regs' and `call_used_regs' to 1 for each of the registers 29514 in the classes which should not be used by GCC. Also make 29515 `define_register_constraint's return `NO_REGS' for constraints 29516 that shouldn't be used. 29517 29518 (However, if this class is not included in `GENERAL_REGS' and all 29519 of the insn patterns whose constraints permit this class are 29520 controlled by target switches, then GCC will automatically avoid 29521 using these registers when the target switches are opposed to 29522 them.) 29523 29524 -- Macro: INCOMING_REGNO (OUT) 29525 Define this macro if the target machine has register windows. 29526 This C expression returns the register number as seen by the 29527 called function corresponding to the register number OUT as seen 29528 by the calling function. Return OUT if register number OUT is not 29529 an outbound register. 29530 29531 -- Macro: OUTGOING_REGNO (IN) 29532 Define this macro if the target machine has register windows. 29533 This C expression returns the register number as seen by the 29534 calling function corresponding to the register number IN as seen 29535 by the called function. Return IN if register number IN is not an 29536 inbound register. 29537 29538 -- Macro: LOCAL_REGNO (REGNO) 29539 Define this macro if the target machine has register windows. 29540 This C expression returns true if the register is call-saved but 29541 is in the register window. Unlike most call-saved registers, such 29542 registers need not be explicitly restored on function exit or 29543 during non-local gotos. 29544 29545 -- Macro: PC_REGNUM 29546 If the program counter has a register number, define this as that 29547 register number. Otherwise, do not define it. 29548 29549 29550File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers 29551 2955217.7.2 Order of Allocation of Registers 29553--------------------------------------- 29554 29555Registers are allocated in order. 29556 29557 -- Macro: REG_ALLOC_ORDER 29558 If defined, an initializer for a vector of integers, containing the 29559 numbers of hard registers in the order in which GCC should prefer 29560 to use them (from most preferred to least). 29561 29562 If this macro is not defined, registers are used lowest numbered 29563 first (all else being equal). 29564 29565 One use of this macro is on machines where the highest numbered 29566 registers must always be saved and the save-multiple-registers 29567 instruction supports only sequences of consecutive registers. On 29568 such machines, define `REG_ALLOC_ORDER' to be an initializer that 29569 lists the highest numbered allocable register first. 29570 29571 -- Macro: ADJUST_REG_ALLOC_ORDER 29572 A C statement (sans semicolon) to choose the order in which to 29573 allocate hard registers for pseudo-registers local to a basic 29574 block. 29575 29576 Store the desired register order in the array `reg_alloc_order'. 29577 Element 0 should be the register to allocate first; element 1, the 29578 next register; and so on. 29579 29580 The macro body should not assume anything about the contents of 29581 `reg_alloc_order' before execution of the macro. 29582 29583 On most machines, it is not necessary to define this macro. 29584 29585 -- Macro: HONOR_REG_ALLOC_ORDER 29586 Normally, IRA tries to estimate the costs for saving a register in 29587 the prologue and restoring it in the epilogue. This discourages 29588 it from using call-saved registers. If a machine wants to ensure 29589 that IRA allocates registers in the order given by REG_ALLOC_ORDER 29590 even if some call-saved registers appear earlier than call-used 29591 ones, then define this macro as a C expression to nonzero. Default 29592 is 0. 29593 29594 -- Macro: IRA_HARD_REGNO_ADD_COST_MULTIPLIER (REGNO) 29595 In some case register allocation order is not enough for the 29596 Integrated Register Allocator (IRA) to generate a good code. If 29597 this macro is defined, it should return a floating point value 29598 based on REGNO. The cost of using REGNO for a pseudo will be 29599 increased by approximately the pseudo's usage frequency times the 29600 value returned by this macro. Not defining this macro is 29601 equivalent to having it always return `0.0'. 29602 29603 On most machines, it is not necessary to define this macro. 29604 29605 29606File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers 29607 2960817.7.3 How Values Fit in Registers 29609---------------------------------- 29610 29611This section discusses the macros that describe which kinds of values 29612(specifically, which machine modes) each register can hold, and how many 29613consecutive registers are needed for a given mode. 29614 29615 -- Macro: HARD_REGNO_NREGS (REGNO, MODE) 29616 A C expression for the number of consecutive hard registers, 29617 starting at register number REGNO, required to hold a value of mode 29618 MODE. This macro must never return zero, even if a register 29619 cannot hold the requested mode - indicate that with 29620 HARD_REGNO_MODE_OK and/or CANNOT_CHANGE_MODE_CLASS instead. 29621 29622 On a machine where all registers are exactly one word, a suitable 29623 definition of this macro is 29624 29625 #define HARD_REGNO_NREGS(REGNO, MODE) \ 29626 ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \ 29627 / UNITS_PER_WORD) 29628 29629 -- Macro: HARD_REGNO_NREGS_HAS_PADDING (REGNO, MODE) 29630 A C expression that is nonzero if a value of mode MODE, stored in 29631 memory, ends with padding that causes it to take up more space than 29632 in registers starting at register number REGNO (as determined by 29633 multiplying GCC's notion of the size of the register when 29634 containing this mode by the number of registers returned by 29635 `HARD_REGNO_NREGS'). By default this is zero. 29636 29637 For example, if a floating-point value is stored in three 32-bit 29638 registers but takes up 128 bits in memory, then this would be 29639 nonzero. 29640 29641 This macros only needs to be defined if there are cases where 29642 `subreg_get_info' would otherwise wrongly determine that a 29643 `subreg' can be represented by an offset to the register number, 29644 when in fact such a `subreg' would contain some of the padding not 29645 stored in registers and so not be representable. 29646 29647 -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE) 29648 For values of REGNO and MODE for which 29649 `HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression 29650 returning the greater number of registers required to hold the 29651 value including any padding. In the example above, the value 29652 would be four. 29653 29654 -- Macro: REGMODE_NATURAL_SIZE (MODE) 29655 Define this macro if the natural size of registers that hold values 29656 of mode MODE is not the word size. It is a C expression that 29657 should give the natural size in bytes for the specified mode. It 29658 is used by the register allocator to try to optimize its results. 29659 This happens for example on SPARC 64-bit where the natural size of 29660 floating-point registers is still 32-bit. 29661 29662 -- Macro: HARD_REGNO_MODE_OK (REGNO, MODE) 29663 A C expression that is nonzero if it is permissible to store a 29664 value of mode MODE in hard register number REGNO (or in several 29665 registers starting with that one). For a machine where all 29666 registers are equivalent, a suitable definition is 29667 29668 #define HARD_REGNO_MODE_OK(REGNO, MODE) 1 29669 29670 You need not include code to check for the numbers of fixed 29671 registers, because the allocation mechanism considers them to be 29672 always occupied. 29673 29674 On some machines, double-precision values must be kept in even/odd 29675 register pairs. You can implement that by defining this macro to 29676 reject odd register numbers for such modes. 29677 29678 The minimum requirement for a mode to be OK in a register is that 29679 the `movMODE' instruction pattern support moves between the 29680 register and other hard register in the same class and that moving 29681 a value into the register and back out not alter it. 29682 29683 Since the same instruction used to move `word_mode' will work for 29684 all narrower integer modes, it is not necessary on any machine for 29685 `HARD_REGNO_MODE_OK' to distinguish between these modes, provided 29686 you define patterns `movhi', etc., to take advantage of this. This 29687 is useful because of the interaction between `HARD_REGNO_MODE_OK' 29688 and `MODES_TIEABLE_P'; it is very desirable for all integer modes 29689 to be tieable. 29690 29691 Many machines have special registers for floating point arithmetic. 29692 Often people assume that floating point machine modes are allowed 29693 only in floating point registers. This is not true. Any 29694 registers that can hold integers can safely _hold_ a floating 29695 point machine mode, whether or not floating arithmetic can be done 29696 on it in those registers. Integer move instructions can be used 29697 to move the values. 29698 29699 On some machines, though, the converse is true: fixed-point machine 29700 modes may not go in floating registers. This is true if the 29701 floating registers normalize any value stored in them, because 29702 storing a non-floating value there would garble it. In this case, 29703 `HARD_REGNO_MODE_OK' should reject fixed-point machine modes in 29704 floating registers. But if the floating registers do not 29705 automatically normalize, if you can store any bit pattern in one 29706 and retrieve it unchanged without a trap, then any machine mode 29707 may go in a floating register, so you can define this macro to say 29708 so. 29709 29710 The primary significance of special floating registers is rather 29711 that they are the registers acceptable in floating point arithmetic 29712 instructions. However, this is of no concern to 29713 `HARD_REGNO_MODE_OK'. You handle it by writing the proper 29714 constraints for those instructions. 29715 29716 On some machines, the floating registers are especially slow to 29717 access, so that it is better to store a value in a stack frame 29718 than in such a register if floating point arithmetic is not being 29719 done. As long as the floating registers are not in class 29720 `GENERAL_REGS', they will not be used unless some pattern's 29721 constraint asks for one. 29722 29723 -- Macro: HARD_REGNO_RENAME_OK (FROM, TO) 29724 A C expression that is nonzero if it is OK to rename a hard 29725 register FROM to another hard register TO. 29726 29727 One common use of this macro is to prevent renaming of a register 29728 to another register that is not saved by a prologue in an interrupt 29729 handler. 29730 29731 The default is always nonzero. 29732 29733 -- Macro: MODES_TIEABLE_P (MODE1, MODE2) 29734 A C expression that is nonzero if a value of mode MODE1 is 29735 accessible in mode MODE2 without copying. 29736 29737 If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R, 29738 MODE2)' are always the same for any R, then `MODES_TIEABLE_P 29739 (MODE1, MODE2)' should be nonzero. If they differ for any R, you 29740 should define this macro to return zero unless some other 29741 mechanism ensures the accessibility of the value in a narrower 29742 mode. 29743 29744 You should define this macro to return nonzero in as many cases as 29745 possible since doing so will allow GCC to perform better register 29746 allocation. 29747 29748 -- Target Hook: bool TARGET_HARD_REGNO_SCRATCH_OK (unsigned int REGNO) 29749 This target hook should return `true' if it is OK to use a hard 29750 register REGNO as scratch reg in peephole2. 29751 29752 One common use of this macro is to prevent using of a register that 29753 is not saved by a prologue in an interrupt handler. 29754 29755 The default version of this hook always returns `true'. 29756 29757 -- Macro: AVOID_CCMODE_COPIES 29758 Define this macro if the compiler should avoid copies to/from 29759 `CCmode' registers. You should only define this macro if support 29760 for copying to/from `CCmode' is incomplete. 29761 29762 29763File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers 29764 2976517.7.4 Handling Leaf Functions 29766------------------------------ 29767 29768On some machines, a leaf function (i.e., one which makes no calls) can 29769run more efficiently if it does not make its own register window. 29770Often this means it is required to receive its arguments in the 29771registers where they are passed by the caller, instead of the registers 29772where they would normally arrive. 29773 29774 The special treatment for leaf functions generally applies only when 29775other conditions are met; for example, often they may use only those 29776registers for its own variables and temporaries. We use the term "leaf 29777function" to mean a function that is suitable for this special 29778handling, so that functions with no calls are not necessarily "leaf 29779functions". 29780 29781 GCC assigns register numbers before it knows whether the function is 29782suitable for leaf function treatment. So it needs to renumber the 29783registers in order to output a leaf function. The following macros 29784accomplish this. 29785 29786 -- Macro: LEAF_REGISTERS 29787 Name of a char vector, indexed by hard register number, which 29788 contains 1 for a register that is allowable in a candidate for leaf 29789 function treatment. 29790 29791 If leaf function treatment involves renumbering the registers, 29792 then the registers marked here should be the ones before 29793 renumbering--those that GCC would ordinarily allocate. The 29794 registers which will actually be used in the assembler code, after 29795 renumbering, should not be marked with 1 in this vector. 29796 29797 Define this macro only if the target machine offers a way to 29798 optimize the treatment of leaf functions. 29799 29800 -- Macro: LEAF_REG_REMAP (REGNO) 29801 A C expression whose value is the register number to which REGNO 29802 should be renumbered, when a function is treated as a leaf 29803 function. 29804 29805 If REGNO is a register number which should not appear in a leaf 29806 function before renumbering, then the expression should yield -1, 29807 which will cause the compiler to abort. 29808 29809 Define this macro only if the target machine offers a way to 29810 optimize the treatment of leaf functions, and registers need to be 29811 renumbered to do this. 29812 29813 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' must 29814usually treat leaf functions specially. They can test the C variable 29815`current_function_is_leaf' which is nonzero for leaf functions. 29816`current_function_is_leaf' is set prior to local register allocation 29817and is valid for the remaining compiler passes. They can also test the 29818C variable `current_function_uses_only_leaf_regs' which is nonzero for 29819leaf functions which only use leaf registers. 29820`current_function_uses_only_leaf_regs' is valid after all passes that 29821modify the instructions have been run and is only useful if 29822`LEAF_REGISTERS' is defined. 29823 29824 29825File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers 29826 2982717.7.5 Registers That Form a Stack 29828---------------------------------- 29829 29830There are special features to handle computers where some of the 29831"registers" form a stack. Stack registers are normally written by 29832pushing onto the stack, and are numbered relative to the top of the 29833stack. 29834 29835 Currently, GCC can only handle one group of stack-like registers, and 29836they must be consecutively numbered. Furthermore, the existing support 29837for stack-like registers is specific to the 80387 floating point 29838coprocessor. If you have a new architecture that uses stack-like 29839registers, you will need to do substantial work on `reg-stack.c' and 29840write your machine description to cooperate with it, as well as 29841defining these macros. 29842 29843 -- Macro: STACK_REGS 29844 Define this if the machine has any stack-like registers. 29845 29846 -- Macro: STACK_REG_COVER_CLASS 29847 This is a cover class containing the stack registers. Define this 29848 if the machine has any stack-like registers. 29849 29850 -- Macro: FIRST_STACK_REG 29851 The number of the first stack-like register. This one is the top 29852 of the stack. 29853 29854 -- Macro: LAST_STACK_REG 29855 The number of the last stack-like register. This one is the 29856 bottom of the stack. 29857 29858 29859File: gccint.info, Node: Register Classes, Next: Stack and Calling, Prev: Registers, Up: Target Macros 29860 2986117.8 Register Classes 29862===================== 29863 29864On many machines, the numbered registers are not all equivalent. For 29865example, certain registers may not be allowed for indexed addressing; 29866certain registers may not be allowed in some instructions. These 29867machine restrictions are described to the compiler using "register 29868classes". 29869 29870 You define a number of register classes, giving each one a name and 29871saying which of the registers belong to it. Then you can specify 29872register classes that are allowed as operands to particular instruction 29873patterns. 29874 29875 In general, each register will belong to several classes. In fact, one 29876class must be named `ALL_REGS' and contain all the registers. Another 29877class must be named `NO_REGS' and contain no registers. Often the 29878union of two classes will be another class; however, this is not 29879required. 29880 29881 One of the classes must be named `GENERAL_REGS'. There is nothing 29882terribly special about the name, but the operand constraint letters `r' 29883and `g' specify this class. If `GENERAL_REGS' is the same as 29884`ALL_REGS', just define it as a macro which expands to `ALL_REGS'. 29885 29886 Order the classes so that if class X is contained in class Y then X 29887has a lower class number than Y. 29888 29889 The way classes other than `GENERAL_REGS' are specified in operand 29890constraints is through machine-dependent operand constraint letters. 29891You can define such letters to correspond to various classes, then use 29892them in operand constraints. 29893 29894 You must define the narrowest register classes for allocatable 29895registers, so that each class either has no subclasses, or that for 29896some mode, the move cost between registers within the class is cheaper 29897than moving a register in the class to or from memory (*note Costs::). 29898 29899 You should define a class for the union of two classes whenever some 29900instruction allows both classes. For example, if an instruction allows 29901either a floating point (coprocessor) register or a general register 29902for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS' 29903which includes both of them. Otherwise you will get suboptimal code, 29904or even internal compiler errors when reload cannot find a register in 29905the class computed via `reg_class_subunion'. 29906 29907 You must also specify certain redundant information about the register 29908classes: for each class, which classes contain it and which ones are 29909contained in it; for each pair of classes, the largest class contained 29910in their union. 29911 29912 When a value occupying several consecutive registers is expected in a 29913certain class, all the registers used must belong to that class. 29914Therefore, register classes cannot be used to enforce a requirement for 29915a register pair to start with an even-numbered register. The way to 29916specify this requirement is with `HARD_REGNO_MODE_OK'. 29917 29918 Register classes used for input-operands of bitwise-and or shift 29919instructions have a special requirement: each such class must have, for 29920each fixed-point machine mode, a subclass whose registers can transfer 29921that mode to or from memory. For example, on some machines, the 29922operations for single-byte values (`QImode') are limited to certain 29923registers. When this is so, each register class that is used in a 29924bitwise-and or shift instruction must have a subclass consisting of 29925registers from which single-byte values can be loaded or stored. This 29926is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to 29927return. 29928 29929 -- Data type: enum reg_class 29930 An enumerated type that must be defined with all the register 29931 class names as enumerated values. `NO_REGS' must be first. 29932 `ALL_REGS' must be the last register class, followed by one more 29933 enumerated value, `LIM_REG_CLASSES', which is not a register class 29934 but rather tells how many classes there are. 29935 29936 Each register class has a number, which is the value of casting 29937 the class name to type `int'. The number serves as an index in 29938 many of the tables described below. 29939 29940 -- Macro: N_REG_CLASSES 29941 The number of distinct register classes, defined as follows: 29942 29943 #define N_REG_CLASSES (int) LIM_REG_CLASSES 29944 29945 -- Macro: REG_CLASS_NAMES 29946 An initializer containing the names of the register classes as C 29947 string constants. These names are used in writing some of the 29948 debugging dumps. 29949 29950 -- Macro: REG_CLASS_CONTENTS 29951 An initializer containing the contents of the register classes, as 29952 integers which are bit masks. The Nth integer specifies the 29953 contents of class N. The way the integer MASK is interpreted is 29954 that register R is in the class if `MASK & (1 << R)' is 1. 29955 29956 When the machine has more than 32 registers, an integer does not 29957 suffice. Then the integers are replaced by sub-initializers, 29958 braced groupings containing several integers. Each 29959 sub-initializer must be suitable as an initializer for the type 29960 `HARD_REG_SET' which is defined in `hard-reg-set.h'. In this 29961 situation, the first integer in each sub-initializer corresponds to 29962 registers 0 through 31, the second integer to registers 32 through 29963 63, and so on. 29964 29965 -- Macro: REGNO_REG_CLASS (REGNO) 29966 A C expression whose value is a register class containing hard 29967 register REGNO. In general there is more than one such class; 29968 choose a class which is "minimal", meaning that no smaller class 29969 also contains the register. 29970 29971 -- Macro: BASE_REG_CLASS 29972 A macro whose definition is the name of the class to which a valid 29973 base register must belong. A base register is one used in an 29974 address which is the register value plus a displacement. 29975 29976 -- Macro: MODE_BASE_REG_CLASS (MODE) 29977 This is a variation of the `BASE_REG_CLASS' macro which allows the 29978 selection of a base register in a mode dependent manner. If MODE 29979 is VOIDmode then it should return the same value as 29980 `BASE_REG_CLASS'. 29981 29982 -- Macro: MODE_BASE_REG_REG_CLASS (MODE) 29983 A C expression whose value is the register class to which a valid 29984 base register must belong in order to be used in a base plus index 29985 register address. You should define this macro if base plus index 29986 addresses have different requirements than other base register 29987 uses. 29988 29989 -- Macro: MODE_CODE_BASE_REG_CLASS (MODE, ADDRESS_SPACE, OUTER_CODE, 29990 INDEX_CODE) 29991 A C expression whose value is the register class to which a valid 29992 base register for a memory reference in mode MODE to address space 29993 ADDRESS_SPACE must belong. OUTER_CODE and INDEX_CODE define the 29994 context in which the base register occurs. OUTER_CODE is the code 29995 of the immediately enclosing expression (`MEM' for the top level 29996 of an address, `ADDRESS' for something that occurs in an 29997 `address_operand'). INDEX_CODE is the code of the corresponding 29998 index expression if OUTER_CODE is `PLUS'; `SCRATCH' otherwise. 29999 30000 -- Macro: INDEX_REG_CLASS 30001 A macro whose definition is the name of the class to which a valid 30002 index register must belong. An index register is one used in an 30003 address where its value is either multiplied by a scale factor or 30004 added to another register (as well as added to a displacement). 30005 30006 -- Macro: REGNO_OK_FOR_BASE_P (NUM) 30007 A C expression which is nonzero if register number NUM is suitable 30008 for use as a base register in operand addresses. 30009 30010 -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE) 30011 A C expression that is just like `REGNO_OK_FOR_BASE_P', except that 30012 that expression may examine the mode of the memory reference in 30013 MODE. You should define this macro if the mode of the memory 30014 reference affects whether a register may be used as a base 30015 register. If you define this macro, the compiler will use it 30016 instead of `REGNO_OK_FOR_BASE_P'. The mode may be `VOIDmode' for 30017 addresses that appear outside a `MEM', i.e., as an 30018 `address_operand'. 30019 30020 -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE) 30021 A C expression which is nonzero if register number NUM is suitable 30022 for use as a base register in base plus index operand addresses, 30023 accessing memory in mode MODE. It may be either a suitable hard 30024 register or a pseudo register that has been allocated such a hard 30025 register. You should define this macro if base plus index 30026 addresses have different requirements than other base register 30027 uses. 30028 30029 Use of this macro is deprecated; please use the more general 30030 `REGNO_MODE_CODE_OK_FOR_BASE_P'. 30031 30032 -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, ADDRESS_SPACE, 30033 OUTER_CODE, INDEX_CODE) 30034 A C expression which is nonzero if register number NUM is suitable 30035 for use as a base register in operand addresses, accessing memory 30036 in mode MODE in address space ADDRESS_SPACE. This is similar to 30037 `REGNO_MODE_OK_FOR_BASE_P', except that that expression may 30038 examine the context in which the register appears in the memory 30039 reference. OUTER_CODE is the code of the immediately enclosing 30040 expression (`MEM' if at the top level of the address, `ADDRESS' 30041 for something that occurs in an `address_operand'). INDEX_CODE is 30042 the code of the corresponding index expression if OUTER_CODE is 30043 `PLUS'; `SCRATCH' otherwise. The mode may be `VOIDmode' for 30044 addresses that appear outside a `MEM', i.e., as an 30045 `address_operand'. 30046 30047 -- Macro: REGNO_OK_FOR_INDEX_P (NUM) 30048 A C expression which is nonzero if register number NUM is suitable 30049 for use as an index register in operand addresses. It may be 30050 either a suitable hard register or a pseudo register that has been 30051 allocated such a hard register. 30052 30053 The difference between an index register and a base register is 30054 that the index register may be scaled. If an address involves the 30055 sum of two registers, neither one of them scaled, then either one 30056 may be labeled the "base" and the other the "index"; but whichever 30057 labeling is used must fit the machine's constraints of which 30058 registers may serve in each capacity. The compiler will try both 30059 labelings, looking for one that is valid, and will reload one or 30060 both registers only if neither labeling works. 30061 30062 -- Target Hook: reg_class_t TARGET_PREFERRED_RENAME_CLASS (reg_class_t 30063 RCLASS) 30064 A target hook that places additional preference on the register 30065 class to use when it is necessary to rename a register in class 30066 RCLASS to another class, or perhaps NO_REGS, if no preferred 30067 register class is found or hook `preferred_rename_class' is not 30068 implemented. Sometimes returning a more restrictive class makes 30069 better code. For example, on ARM, thumb-2 instructions using 30070 `LO_REGS' may be smaller than instructions using `GENERIC_REGS'. 30071 By returning `LO_REGS' from `preferred_rename_class', code size 30072 can be reduced. 30073 30074 -- Target Hook: reg_class_t TARGET_PREFERRED_RELOAD_CLASS (rtx X, 30075 reg_class_t RCLASS) 30076 A target hook that places additional restrictions on the register 30077 class to use when it is necessary to copy value X into a register 30078 in class RCLASS. The value is a register class; perhaps RCLASS, 30079 or perhaps another, smaller class. 30080 30081 The default version of this hook always returns value of `rclass' 30082 argument. 30083 30084 Sometimes returning a more restrictive class makes better code. 30085 For example, on the 68000, when X is an integer constant that is 30086 in range for a `moveq' instruction, the value of this macro is 30087 always `DATA_REGS' as long as RCLASS includes the data registers. 30088 Requiring a data register guarantees that a `moveq' will be used. 30089 30090 One case where `TARGET_PREFERRED_RELOAD_CLASS' must not return 30091 RCLASS is if X is a legitimate constant which cannot be loaded 30092 into some register class. By returning `NO_REGS' you can force X 30093 into a memory location. For example, rs6000 can load immediate 30094 values into general-purpose registers, but does not have an 30095 instruction for loading an immediate value into a floating-point 30096 register, so `TARGET_PREFERRED_RELOAD_CLASS' returns `NO_REGS' when 30097 X is a floating-point constant. If the constant can't be loaded 30098 into any kind of register, code generation will be better if 30099 `TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 30100 instead of using `TARGET_PREFERRED_RELOAD_CLASS'. 30101 30102 If an insn has pseudos in it after register allocation, reload 30103 will go through the alternatives and call repeatedly 30104 `TARGET_PREFERRED_RELOAD_CLASS' to find the best one. Returning 30105 `NO_REGS', in this case, makes reload add a `!' in front of the 30106 constraint: the x86 back-end uses this feature to discourage usage 30107 of 387 registers when math is done in the SSE registers (and vice 30108 versa). 30109 30110 -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS) 30111 A C expression that places additional restrictions on the register 30112 class to use when it is necessary to copy value X into a register 30113 in class CLASS. The value is a register class; perhaps CLASS, or 30114 perhaps another, smaller class. On many machines, the following 30115 definition is safe: 30116 30117 #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS 30118 30119 Sometimes returning a more restrictive class makes better code. 30120 For example, on the 68000, when X is an integer constant that is 30121 in range for a `moveq' instruction, the value of this macro is 30122 always `DATA_REGS' as long as CLASS includes the data registers. 30123 Requiring a data register guarantees that a `moveq' will be used. 30124 30125 One case where `PREFERRED_RELOAD_CLASS' must not return CLASS is 30126 if X is a legitimate constant which cannot be loaded into some 30127 register class. By returning `NO_REGS' you can force X into a 30128 memory location. For example, rs6000 can load immediate values 30129 into general-purpose registers, but does not have an instruction 30130 for loading an immediate value into a floating-point register, so 30131 `PREFERRED_RELOAD_CLASS' returns `NO_REGS' when X is a 30132 floating-point constant. If the constant can't be loaded into any 30133 kind of register, code generation will be better if 30134 `TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate 30135 instead of using `TARGET_PREFERRED_RELOAD_CLASS'. 30136 30137 If an insn has pseudos in it after register allocation, reload 30138 will go through the alternatives and call repeatedly 30139 `PREFERRED_RELOAD_CLASS' to find the best one. Returning 30140 `NO_REGS', in this case, makes reload add a `!' in front of the 30141 constraint: the x86 back-end uses this feature to discourage usage 30142 of 387 registers when math is done in the SSE registers (and vice 30143 versa). 30144 30145 -- Target Hook: reg_class_t TARGET_PREFERRED_OUTPUT_RELOAD_CLASS (rtx 30146 X, reg_class_t RCLASS) 30147 Like `TARGET_PREFERRED_RELOAD_CLASS', but for output reloads 30148 instead of input reloads. 30149 30150 The default version of this hook always returns value of `rclass' 30151 argument. 30152 30153 You can also use `TARGET_PREFERRED_OUTPUT_RELOAD_CLASS' to 30154 discourage reload from using some alternatives, like 30155 `TARGET_PREFERRED_RELOAD_CLASS'. 30156 30157 -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS) 30158 A C expression that places additional restrictions on the register 30159 class to use when it is necessary to be able to hold a value of 30160 mode MODE in a reload register for which class CLASS would 30161 ordinarily be used. 30162 30163 Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when 30164 there are certain modes that simply can't go in certain reload 30165 classes. 30166 30167 The value is a register class; perhaps CLASS, or perhaps another, 30168 smaller class. 30169 30170 Don't define this macro unless the target machine has limitations 30171 which require the macro to do something nontrivial. 30172 30173 -- Target Hook: reg_class_t TARGET_SECONDARY_RELOAD (bool IN_P, rtx X, 30174 reg_class_t RELOAD_CLASS, machine_mode RELOAD_MODE, 30175 secondary_reload_info *SRI) 30176 Many machines have some registers that cannot be copied directly 30177 to or from memory or even from other types of registers. An 30178 example is the `MQ' register, which on most machines, can only be 30179 copied to or from general registers, but not memory. Below, we 30180 shall be using the term 'intermediate register' when a move 30181 operation cannot be performed directly, but has to be done by 30182 copying the source into the intermediate register first, and then 30183 copying the intermediate register to the destination. An 30184 intermediate register always has the same mode as source and 30185 destination. Since it holds the actual value being copied, reload 30186 might apply optimizations to re-use an intermediate register and 30187 eliding the copy from the source when it can determine that the 30188 intermediate register still holds the required value. 30189 30190 Another kind of secondary reload is required on some machines which 30191 allow copying all registers to and from memory, but require a 30192 scratch register for stores to some memory locations (e.g., those 30193 with symbolic address on the RT, and those with certain symbolic 30194 address on the SPARC when compiling PIC). Scratch registers need 30195 not have the same mode as the value being copied, and usually hold 30196 a different value than that being copied. Special patterns in the 30197 md file are needed to describe how the copy is performed with the 30198 help of the scratch register; these patterns also describe the 30199 number, register class(es) and mode(s) of the scratch register(s). 30200 30201 In some cases, both an intermediate and a scratch register are 30202 required. 30203 30204 For input reloads, this target hook is called with nonzero IN_P, 30205 and X is an rtx that needs to be copied to a register of class 30206 RELOAD_CLASS in RELOAD_MODE. For output reloads, this target hook 30207 is called with zero IN_P, and a register of class RELOAD_CLASS 30208 needs to be copied to rtx X in RELOAD_MODE. 30209 30210 If copying a register of RELOAD_CLASS from/to X requires an 30211 intermediate register, the hook `secondary_reload' should return 30212 the register class required for this intermediate register. If no 30213 intermediate register is required, it should return NO_REGS. If 30214 more than one intermediate register is required, describe the one 30215 that is closest in the copy chain to the reload register. 30216 30217 If scratch registers are needed, you also have to describe how to 30218 perform the copy from/to the reload register to/from this closest 30219 intermediate register. Or if no intermediate register is 30220 required, but still a scratch register is needed, describe the 30221 copy from/to the reload register to/from the reload operand X. 30222 30223 You do this by setting `sri->icode' to the instruction code of a 30224 pattern in the md file which performs the move. Operands 0 and 1 30225 are the output and input of this copy, respectively. Operands 30226 from operand 2 onward are for scratch operands. These scratch 30227 operands must have a mode, and a single-register-class output 30228 constraint. 30229 30230 When an intermediate register is used, the `secondary_reload' hook 30231 will be called again to determine how to copy the intermediate 30232 register to/from the reload operand X, so your hook must also have 30233 code to handle the register class of the intermediate operand. 30234 30235 X might be a pseudo-register or a `subreg' of a pseudo-register, 30236 which could either be in a hard register or in memory. Use 30237 `true_regnum' to find out; it will return -1 if the pseudo is in 30238 memory and the hard register number if it is in a register. 30239 30240 Scratch operands in memory (constraint `"=m"' / `"=&m"') are 30241 currently not supported. For the time being, you will have to 30242 continue to use `SECONDARY_MEMORY_NEEDED' for that purpose. 30243 30244 `copy_cost' also uses this target hook to find out how values are 30245 copied. If you want it to include some extra cost for the need to 30246 allocate (a) scratch register(s), set `sri->extra_cost' to the 30247 additional cost. Or if two dependent moves are supposed to have a 30248 lower cost than the sum of the individual moves due to expected 30249 fortuitous scheduling and/or special forwarding logic, you can set 30250 `sri->extra_cost' to a negative amount. 30251 30252 -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X) 30253 -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X) 30254 -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X) 30255 These macros are obsolete, new ports should use the target hook 30256 `TARGET_SECONDARY_RELOAD' instead. 30257 30258 These are obsolete macros, replaced by the 30259 `TARGET_SECONDARY_RELOAD' target hook. Older ports still define 30260 these macros to indicate to the reload phase that it may need to 30261 allocate at least one register for a reload in addition to the 30262 register to contain the data. Specifically, if copying X to a 30263 register CLASS in MODE requires an intermediate register, you were 30264 supposed to define `SECONDARY_INPUT_RELOAD_CLASS' to return the 30265 largest register class all of whose registers can be used as 30266 intermediate registers or scratch registers. 30267 30268 If copying a register CLASS in MODE to X requires an intermediate 30269 or scratch register, `SECONDARY_OUTPUT_RELOAD_CLASS' was supposed 30270 to be defined be defined to return the largest register class 30271 required. If the requirements for input and output reloads were 30272 the same, the macro `SECONDARY_RELOAD_CLASS' should have been used 30273 instead of defining both macros identically. 30274 30275 The values returned by these macros are often `GENERAL_REGS'. 30276 Return `NO_REGS' if no spare register is needed; i.e., if X can be 30277 directly copied to or from a register of CLASS in MODE without 30278 requiring a scratch register. Do not define this macro if it 30279 would always return `NO_REGS'. 30280 30281 If a scratch register is required (either with or without an 30282 intermediate register), you were supposed to define patterns for 30283 `reload_inM' or `reload_outM', as required (*note Standard 30284 Names::. These patterns, which were normally implemented with a 30285 `define_expand', should be similar to the `movM' patterns, except 30286 that operand 2 is the scratch register. 30287 30288 These patterns need constraints for the reload register and scratch 30289 register that contain a single register class. If the original 30290 reload register (whose class is CLASS) can meet the constraint 30291 given in the pattern, the value returned by these macros is used 30292 for the class of the scratch register. Otherwise, two additional 30293 reload registers are required. Their classes are obtained from 30294 the constraints in the insn pattern. 30295 30296 X might be a pseudo-register or a `subreg' of a pseudo-register, 30297 which could either be in a hard register or in memory. Use 30298 `true_regnum' to find out; it will return -1 if the pseudo is in 30299 memory and the hard register number if it is in a register. 30300 30301 These macros should not be used in the case where a particular 30302 class of registers can only be copied to memory and not to another 30303 class of registers. In that case, secondary reload registers are 30304 not needed and would not be helpful. Instead, a stack location 30305 must be used to perform the copy and the `movM' pattern should use 30306 memory as an intermediate storage. This case often occurs between 30307 floating-point and general registers. 30308 30309 -- Macro: SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M) 30310 Certain machines have the property that some registers cannot be 30311 copied to some other registers without using memory. Define this 30312 macro on those machines to be a C expression that is nonzero if 30313 objects of mode M in registers of CLASS1 can only be copied to 30314 registers of class CLASS2 by storing a register of CLASS1 into 30315 memory and loading that memory location into a register of CLASS2. 30316 30317 Do not define this macro if its value would always be zero. 30318 30319 -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE) 30320 Normally when `SECONDARY_MEMORY_NEEDED' is defined, the compiler 30321 allocates a stack slot for a memory location needed for register 30322 copies. If this macro is defined, the compiler instead uses the 30323 memory location defined by this macro. 30324 30325 Do not define this macro if you do not define 30326 `SECONDARY_MEMORY_NEEDED'. 30327 30328 -- Macro: SECONDARY_MEMORY_NEEDED_MODE (MODE) 30329 When the compiler needs a secondary memory location to copy 30330 between two registers of mode MODE, it normally allocates 30331 sufficient memory to hold a quantity of `BITS_PER_WORD' bits and 30332 performs the store and load operations in a mode that many bits 30333 wide and whose class is the same as that of MODE. 30334 30335 This is right thing to do on most machines because it ensures that 30336 all bits of the register are copied and prevents accesses to the 30337 registers in a narrower mode, which some machines prohibit for 30338 floating-point registers. 30339 30340 However, this default behavior is not correct on some machines, 30341 such as the DEC Alpha, that store short integers in floating-point 30342 registers differently than in integer registers. On those 30343 machines, the default widening will not work correctly and you 30344 must define this macro to suppress that widening in some cases. 30345 See the file `alpha.h' for details. 30346 30347 Do not define this macro if you do not define 30348 `SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is 30349 `BITS_PER_WORD' bits wide is correct for your machine. 30350 30351 -- Target Hook: bool TARGET_CLASS_LIKELY_SPILLED_P (reg_class_t RCLASS) 30352 A target hook which returns `true' if pseudos that have been 30353 assigned to registers of class RCLASS would likely be spilled 30354 because registers of RCLASS are needed for spill registers. 30355 30356 The default version of this target hook returns `true' if RCLASS 30357 has exactly one register and `false' otherwise. On most machines, 30358 this default should be used. For generally register-starved 30359 machines, such as i386, or machines with right register 30360 constraints, such as SH, this hook can be used to avoid excessive 30361 spilling. 30362 30363 This hook is also used by some of the global intra-procedural code 30364 transformations to throtle code motion, to avoid increasing 30365 register pressure. 30366 30367 -- Target Hook: unsigned char TARGET_CLASS_MAX_NREGS (reg_class_t 30368 RCLASS, machine_mode MODE) 30369 A target hook returns the maximum number of consecutive registers 30370 of class RCLASS needed to hold a value of mode MODE. 30371 30372 This is closely related to the macro `HARD_REGNO_NREGS'. In fact, 30373 the value returned by `TARGET_CLASS_MAX_NREGS (RCLASS, MODE)' 30374 target hook should be the maximum value of `HARD_REGNO_NREGS 30375 (REGNO, MODE)' for all REGNO values in the class RCLASS. 30376 30377 This target hook helps control the handling of multiple-word values 30378 in the reload pass. 30379 30380 The default version of this target hook returns the size of MODE 30381 in words. 30382 30383 -- Macro: CLASS_MAX_NREGS (CLASS, MODE) 30384 A C expression for the maximum number of consecutive registers of 30385 class CLASS needed to hold a value of mode MODE. 30386 30387 This is closely related to the macro `HARD_REGNO_NREGS'. In fact, 30388 the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be 30389 the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all 30390 REGNO values in the class CLASS. 30391 30392 This macro helps control the handling of multiple-word values in 30393 the reload pass. 30394 30395 -- Macro: CANNOT_CHANGE_MODE_CLASS (FROM, TO, CLASS) 30396 If defined, a C expression that returns nonzero for a CLASS for 30397 which a change from mode FROM to mode TO is invalid. 30398 30399 For example, loading 32-bit integer or floating-point objects into 30400 floating-point registers on Alpha extends them to 64 bits. 30401 Therefore loading a 64-bit object and then storing it as a 32-bit 30402 object does not store the low-order 32 bits, as would be the case 30403 for a normal register. Therefore, `alpha.h' defines 30404 `CANNOT_CHANGE_MODE_CLASS' as below: 30405 30406 #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ 30407 (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ 30408 ? reg_classes_intersect_p (FLOAT_REGS, (CLASS)) : 0) 30409 30410 Even if storing from a register in mode TO would be valid, if both 30411 FROM and `raw_reg_mode' for CLASS are wider than `word_mode', then 30412 we must prevent TO narrowing the mode. This happens when the 30413 middle-end assumes that it can load or store pieces of an N-word 30414 pseudo, and that the pseudo will eventually be allocated to N 30415 `word_mode' hard registers. Failure to prevent this kind of mode 30416 change will result in the entire `raw_reg_mode' being modified 30417 instead of the partial value that the middle-end intended. 30418 30419 30420 -- Target Hook: bool TARGET_LRA_P (void) 30421 A target hook which returns true if we use LRA instead of reload 30422 pass. It means that LRA was ported to the target. The default 30423 version of this target hook returns always false. 30424 30425 -- Target Hook: int TARGET_REGISTER_PRIORITY (int) 30426 A target hook which returns the register priority number to which 30427 the register HARD_REGNO belongs to. The bigger the number, the 30428 more preferable the hard register usage (when all other conditions 30429 are the same). This hook can be used to prefer some hard 30430 register over others in LRA. For example, some x86-64 register 30431 usage needs additional prefix which makes instructions longer. 30432 The hook can return lower priority number for such registers make 30433 them less favorable and as result making the generated code 30434 smaller. The default version of this target hook returns always 30435 zero. 30436 30437 -- Target Hook: bool TARGET_REGISTER_USAGE_LEVELING_P (void) 30438 A target hook which returns true if we need register usage 30439 leveling. That means if a few hard registers are equally good for 30440 the assignment, we choose the least used hard register. The 30441 register usage leveling may be profitable for some targets. 30442 Don't use the usage leveling for targets with conditional 30443 execution or targets with big register files as it hurts 30444 if-conversion and cross-jumping optimizations. The default 30445 version of this target hook returns always false. 30446 30447 -- Target Hook: bool TARGET_DIFFERENT_ADDR_DISPLACEMENT_P (void) 30448 A target hook which returns true if an address with the same 30449 structure can have different maximal legitimate displacement. 30450 For example, the displacement can depend on memory mode or on 30451 operand combinations in the insn. The default version of this 30452 target hook returns always false. 30453 30454 -- Target Hook: bool TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P (rtx SUBST) 30455 A target hook which returns `true' if SUBST can't substitute 30456 safely pseudos with equivalent memory values during register 30457 allocation. The default version of this target hook returns 30458 `false'. On most machines, this default should be used. For 30459 generally machines with non orthogonal register usage for 30460 addressing, such as SH, this hook can be used to avoid excessive 30461 spilling. 30462 30463 -- Target Hook: bool TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT (rtx 30464 *DISP, rtx *OFFSET, machine_mode MODE) 30465 A target hook which returns `true' if *DISP is legitimezed to 30466 valid address displacement with subtracting *OFFSET at memory mode 30467 MODE. The default version of this target hook returns `false'. 30468 This hook will benefit machines with limited base plus displacement 30469 addressing. 30470 30471 -- Target Hook: reg_class_t TARGET_SPILL_CLASS (reg_class_t, 30472 MACHINE_MODE) 30473 This hook defines a class of registers which could be used for 30474 spilling pseudos of the given mode and class, or `NO_REGS' if 30475 only memory should be used. Not defining this hook is equivalent 30476 to returning `NO_REGS' for all inputs. 30477 30478 -- Target Hook: machine_mode TARGET_CSTORE_MODE (enum insn_code ICODE) 30479 This hook defines the machine mode to use for the boolean result 30480 of conditional store patterns. The ICODE argument is the 30481 instruction code for the cstore being performed. Not definiting 30482 this hook is the same as accepting the mode encoded into operand 30483 0 of the cstore expander patterns. 30484 30485 30486File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Register Classes, Up: Target Macros 30487 3048817.9 Stack Layout and Calling Conventions 30489========================================= 30490 30491This describes the stack layout and calling conventions. 30492 30493* Menu: 30494 30495* Frame Layout:: 30496* Exception Handling:: 30497* Stack Checking:: 30498* Frame Registers:: 30499* Elimination:: 30500* Stack Arguments:: 30501* Register Arguments:: 30502* Scalar Return:: 30503* Aggregate Return:: 30504* Caller Saves:: 30505* Function Entry:: 30506* Profiling:: 30507* Tail Calls:: 30508* Stack Smashing Protection:: 30509* Miscellaneous Register Hooks:: 30510 30511 30512File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling 30513 3051417.9.1 Basic Stack Layout 30515------------------------- 30516 30517Here is the basic stack layout. 30518 30519 -- Macro: STACK_GROWS_DOWNWARD 30520 Define this macro if pushing a word onto the stack moves the stack 30521 pointer to a smaller address. 30522 30523 When we say, "define this macro if ...", it means that the 30524 compiler checks this macro only with `#ifdef' so the precise 30525 definition used does not matter. 30526 30527 -- Macro: STACK_PUSH_CODE 30528 This macro defines the operation used when something is pushed on 30529 the stack. In RTL, a push operation will be `(set (mem 30530 (STACK_PUSH_CODE (reg sp))) ...)' 30531 30532 The choices are `PRE_DEC', `POST_DEC', `PRE_INC', and `POST_INC'. 30533 Which of these is correct depends on the stack direction and on 30534 whether the stack pointer points to the last item on the stack or 30535 whether it points to the space for the next item on the stack. 30536 30537 The default is `PRE_DEC' when `STACK_GROWS_DOWNWARD' is defined, 30538 which is almost always right, and `PRE_INC' otherwise, which is 30539 often wrong. 30540 30541 -- Macro: FRAME_GROWS_DOWNWARD 30542 Define this macro to nonzero value if the addresses of local 30543 variable slots are at negative offsets from the frame pointer. 30544 30545 -- Macro: ARGS_GROW_DOWNWARD 30546 Define this macro if successive arguments to a function occupy 30547 decreasing addresses on the stack. 30548 30549 -- Macro: STARTING_FRAME_OFFSET 30550 Offset from the frame pointer to the first local variable slot to 30551 be allocated. 30552 30553 If `FRAME_GROWS_DOWNWARD', find the next slot's offset by 30554 subtracting the first slot's length from `STARTING_FRAME_OFFSET'. 30555 Otherwise, it is found by adding the length of the first slot to 30556 the value `STARTING_FRAME_OFFSET'. 30557 30558 -- Macro: STACK_ALIGNMENT_NEEDED 30559 Define to zero to disable final alignment of the stack during 30560 reload. The nonzero default for this macro is suitable for most 30561 ports. 30562 30563 On ports where `STARTING_FRAME_OFFSET' is nonzero or where there 30564 is a register save block following the local block that doesn't 30565 require alignment to `STACK_BOUNDARY', it may be beneficial to 30566 disable stack alignment and do it in the backend. 30567 30568 -- Macro: STACK_POINTER_OFFSET 30569 Offset from the stack pointer register to the first location at 30570 which outgoing arguments are placed. If not specified, the 30571 default value of zero is used. This is the proper value for most 30572 machines. 30573 30574 If `ARGS_GROW_DOWNWARD', this is the offset to the location above 30575 the first location at which outgoing arguments are placed. 30576 30577 -- Macro: FIRST_PARM_OFFSET (FUNDECL) 30578 Offset from the argument pointer register to the first argument's 30579 address. On some machines it may depend on the data type of the 30580 function. 30581 30582 If `ARGS_GROW_DOWNWARD', this is the offset to the location above 30583 the first argument's address. 30584 30585 -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL) 30586 Offset from the stack pointer register to an item dynamically 30587 allocated on the stack, e.g., by `alloca'. 30588 30589 The default value for this macro is `STACK_POINTER_OFFSET' plus the 30590 length of the outgoing arguments. The default is correct for most 30591 machines. See `function.c' for details. 30592 30593 -- Macro: INITIAL_FRAME_ADDRESS_RTX 30594 A C expression whose value is RTL representing the address of the 30595 initial stack frame. This address is passed to `RETURN_ADDR_RTX' 30596 and `DYNAMIC_CHAIN_ADDRESS'. If you don't define this macro, a 30597 reasonable default value will be used. Define this macro in order 30598 to make frame pointer elimination work in the presence of 30599 `__builtin_frame_address (count)' and `__builtin_return_address 30600 (count)' for `count' not equal to zero. 30601 30602 -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR) 30603 A C expression whose value is RTL representing the address in a 30604 stack frame where the pointer to the caller's frame is stored. 30605 Assume that FRAMEADDR is an RTL expression for the address of the 30606 stack frame itself. 30607 30608 If you don't define this macro, the default is to return the value 30609 of FRAMEADDR--that is, the stack frame address is also the address 30610 of the stack word that points to the previous frame. 30611 30612 -- Macro: SETUP_FRAME_ADDRESSES 30613 If defined, a C expression that produces the machine-specific code 30614 to setup the stack so that arbitrary frames can be accessed. For 30615 example, on the SPARC, we must flush all of the register windows 30616 to the stack before we can access arbitrary stack frames. You 30617 will seldom need to define this macro. 30618 30619 -- Target Hook: rtx TARGET_BUILTIN_SETJMP_FRAME_VALUE (void) 30620 This target hook should return an rtx that is used to store the 30621 address of the current frame into the built in `setjmp' buffer. 30622 The default value, `virtual_stack_vars_rtx', is correct for most 30623 machines. One reason you may need to define this target hook is if 30624 `hard_frame_pointer_rtx' is the appropriate value on your machine. 30625 30626 -- Macro: FRAME_ADDR_RTX (FRAMEADDR) 30627 A C expression whose value is RTL representing the value of the 30628 frame address for the current frame. FRAMEADDR is the frame 30629 pointer of the current frame. This is used for 30630 __builtin_frame_address. You need only define this macro if the 30631 frame address is not the same as the frame pointer. Most machines 30632 do not need to define it. 30633 30634 -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR) 30635 A C expression whose value is RTL representing the value of the 30636 return address for the frame COUNT steps up from the current 30637 frame, after the prologue. FRAMEADDR is the frame pointer of the 30638 COUNT frame, or the frame pointer of the COUNT - 1 frame if 30639 `RETURN_ADDR_IN_PREVIOUS_FRAME' is nonzero. 30640 30641 The value of the expression must always be the correct address when 30642 COUNT is zero, but may be `NULL_RTX' if there is no way to 30643 determine the return address of other frames. 30644 30645 -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME 30646 Define this macro to nonzero value if the return address of a 30647 particular stack frame is accessed from the frame pointer of the 30648 previous stack frame. The zero default for this macro is suitable 30649 for most ports. 30650 30651 -- Macro: INCOMING_RETURN_ADDR_RTX 30652 A C expression whose value is RTL representing the location of the 30653 incoming return address at the beginning of any function, before 30654 the prologue. This RTL is either a `REG', indicating that the 30655 return value is saved in `REG', or a `MEM' representing a location 30656 in the stack. 30657 30658 You only need to define this macro if you want to support call 30659 frame debugging information like that provided by DWARF 2. 30660 30661 If this RTL is a `REG', you should also define 30662 `DWARF_FRAME_RETURN_COLUMN' to `DWARF_FRAME_REGNUM (REGNO)'. 30663 30664 -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN 30665 A C expression whose value is an integer giving a DWARF 2 column 30666 number that may be used as an alternative return column. The 30667 column must not correspond to any gcc hard register (that is, it 30668 must not be in the range of `DWARF_FRAME_REGNUM'). 30669 30670 This macro can be useful if `DWARF_FRAME_RETURN_COLUMN' is set to a 30671 general register, but an alternative column needs to be used for 30672 signal frames. Some targets have also used different frame return 30673 columns over time. 30674 30675 -- Macro: DWARF_ZERO_REG 30676 A C expression whose value is an integer giving a DWARF 2 register 30677 number that is considered to always have the value zero. This 30678 should only be defined if the target has an architected zero 30679 register, and someone decided it was a good idea to use that 30680 register number to terminate the stack backtrace. New ports 30681 should avoid this. 30682 30683 -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char 30684 *LABEL, rtx PATTERN, int INDEX) 30685 This target hook allows the backend to emit frame-related insns 30686 that contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame 30687 debugging info engine will invoke it on insns of the form 30688 (set (reg) (unspec [...] UNSPEC_INDEX)) 30689 and 30690 (set (reg) (unspec_volatile [...] UNSPECV_INDEX)). 30691 to let the backend emit the call frame instructions. LABEL is the 30692 CFI label attached to the insn, PATTERN is the pattern of the insn 30693 and INDEX is `UNSPEC_INDEX' or `UNSPECV_INDEX'. 30694 30695 -- Macro: INCOMING_FRAME_SP_OFFSET 30696 A C expression whose value is an integer giving the offset, in 30697 bytes, from the value of the stack pointer register to the top of 30698 the stack frame at the beginning of any function, before the 30699 prologue. The top of the frame is defined to be the value of the 30700 stack pointer in the previous frame, just before the call 30701 instruction. 30702 30703 You only need to define this macro if you want to support call 30704 frame debugging information like that provided by DWARF 2. 30705 30706 -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL) 30707 A C expression whose value is an integer giving the offset, in 30708 bytes, from the argument pointer to the canonical frame address 30709 (cfa). The final value should coincide with that calculated by 30710 `INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable 30711 during virtual register instantiation. 30712 30713 The default value for this macro is `FIRST_PARM_OFFSET (fundecl) + 30714 crtl->args.pretend_args_size', which is correct for most machines; 30715 in general, the arguments are found immediately before the stack 30716 frame. Note that this is not the case on some targets that save 30717 registers into the caller's frame, such as SPARC and rs6000, and 30718 so such targets need to define this macro. 30719 30720 You only need to define this macro if the default is incorrect, 30721 and you want to support call frame debugging information like that 30722 provided by DWARF 2. 30723 30724 -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL) 30725 If defined, a C expression whose value is an integer giving the 30726 offset in bytes from the frame pointer to the canonical frame 30727 address (cfa). The final value should coincide with that 30728 calculated by `INCOMING_FRAME_SP_OFFSET'. 30729 30730 Normally the CFA is calculated as an offset from the argument 30731 pointer, via `ARG_POINTER_CFA_OFFSET', but if the argument pointer 30732 is variable due to the ABI, this may not be possible. If this 30733 macro is defined, it implies that the virtual register 30734 instantiation should be based on the frame pointer instead of the 30735 argument pointer. Only one of `FRAME_POINTER_CFA_OFFSET' and 30736 `ARG_POINTER_CFA_OFFSET' should be defined. 30737 30738 -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL) 30739 If defined, a C expression whose value is an integer giving the 30740 offset in bytes from the canonical frame address (cfa) to the 30741 frame base used in DWARF 2 debug information. The default is 30742 zero. A different value may reduce the size of debug information 30743 on some ports. 30744 30745 30746File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling 30747 3074817.9.2 Exception Handling Support 30749--------------------------------- 30750 30751 -- Macro: EH_RETURN_DATA_REGNO (N) 30752 A C expression whose value is the Nth register number used for 30753 data by exception handlers, or `INVALID_REGNUM' if fewer than N 30754 registers are usable. 30755 30756 The exception handling library routines communicate with the 30757 exception handlers via a set of agreed upon registers. Ideally 30758 these registers should be call-clobbered; it is possible to use 30759 call-saved registers, but may negatively impact code size. The 30760 target must support at least 2 data registers, but should define 4 30761 if there are enough free registers. 30762 30763 You must define this macro if you want to support call frame 30764 exception handling like that provided by DWARF 2. 30765 30766 -- Macro: EH_RETURN_STACKADJ_RTX 30767 A C expression whose value is RTL representing a location in which 30768 to store a stack adjustment to be applied before function return. 30769 This is used to unwind the stack to an exception handler's call 30770 frame. It will be assigned zero on code paths that return 30771 normally. 30772 30773 Typically this is a call-clobbered hard register that is otherwise 30774 untouched by the epilogue, but could also be a stack slot. 30775 30776 Do not define this macro if the stack pointer is saved and restored 30777 by the regular prolog and epilog code in the call frame itself; in 30778 this case, the exception handling library routines will update the 30779 stack location to be restored in place. Otherwise, you must define 30780 this macro if you want to support call frame exception handling 30781 like that provided by DWARF 2. 30782 30783 -- Macro: EH_RETURN_HANDLER_RTX 30784 A C expression whose value is RTL representing a location in which 30785 to store the address of an exception handler to which we should 30786 return. It will not be assigned on code paths that return 30787 normally. 30788 30789 Typically this is the location in the call frame at which the 30790 normal return address is stored. For targets that return by 30791 popping an address off the stack, this might be a memory address 30792 just below the _target_ call frame rather than inside the current 30793 call frame. If defined, `EH_RETURN_STACKADJ_RTX' will have already 30794 been assigned, so it may be used to calculate the location of the 30795 target call frame. 30796 30797 Some targets have more complex requirements than storing to an 30798 address calculable during initial code generation. In that case 30799 the `eh_return' instruction pattern should be used instead. 30800 30801 If you want to support call frame exception handling, you must 30802 define either this macro or the `eh_return' instruction pattern. 30803 30804 -- Macro: RETURN_ADDR_OFFSET 30805 If defined, an integer-valued C expression for which rtl will be 30806 generated to add it to the exception handler address before it is 30807 searched in the exception handling tables, and to subtract it 30808 again from the address before using it to return to the exception 30809 handler. 30810 30811 -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL) 30812 This macro chooses the encoding of pointers embedded in the 30813 exception handling sections. If at all possible, this should be 30814 defined such that the exception handling section will not require 30815 dynamic relocations, and so may be read-only. 30816 30817 CODE is 0 for data, 1 for code labels, 2 for function pointers. 30818 GLOBAL is true if the symbol may be affected by dynamic 30819 relocations. The macro should return a combination of the 30820 `DW_EH_PE_*' defines as found in `dwarf2.h'. 30821 30822 If this macro is not defined, pointers will not be encoded but 30823 represented directly. 30824 30825 -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE, 30826 ADDR, DONE) 30827 This macro allows the target to emit whatever special magic is 30828 required to represent the encoding chosen by 30829 `ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of 30830 pc-relative and indirect encodings; this must be defined if the 30831 target uses text-relative or data-relative encodings. 30832 30833 This is a C statement that branches to DONE if the format was 30834 handled. ENCODING is the format chosen, SIZE is the number of 30835 bytes that the format occupies, ADDR is the `SYMBOL_REF' to be 30836 emitted. 30837 30838 -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS) 30839 This macro allows the target to add CPU and operating system 30840 specific code to the call-frame unwinder for use when there is no 30841 unwind data available. The most common reason to implement this 30842 macro is to unwind through signal frames. 30843 30844 This macro is called from `uw_frame_state_for' in `unwind-dw2.c', 30845 `unwind-dw2-xtensa.c' and `unwind-ia64.c'. CONTEXT is an 30846 `_Unwind_Context'; FS is an `_Unwind_FrameState'. Examine 30847 `context->ra' for the address of the code being executed and 30848 `context->cfa' for the stack pointer value. If the frame can be 30849 decoded, the register save addresses should be updated in FS and 30850 the macro should evaluate to `_URC_NO_REASON'. If the frame 30851 cannot be decoded, the macro should evaluate to 30852 `_URC_END_OF_STACK'. 30853 30854 For proper signal handling in Java this macro is accompanied by 30855 `MAKE_THROW_FRAME', defined in `libjava/include/*-signal.h' 30856 headers. 30857 30858 -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS) 30859 This macro allows the target to add operating system specific code 30860 to the call-frame unwinder to handle the IA-64 `.unwabi' unwinding 30861 directive, usually used for signal or interrupt frames. 30862 30863 This macro is called from `uw_update_context' in libgcc's 30864 `unwind-ia64.c'. CONTEXT is an `_Unwind_Context'; FS is an 30865 `_Unwind_FrameState'. Examine `fs->unwabi' for the abi and 30866 context in the `.unwabi' directive. If the `.unwabi' directive 30867 can be handled, the register save addresses should be updated in 30868 FS. 30869 30870 -- Macro: TARGET_USES_WEAK_UNWIND_INFO 30871 A C expression that evaluates to true if the target requires unwind 30872 info to be given comdat linkage. Define it to be `1' if comdat 30873 linkage is necessary. The default is `0'. 30874 30875 30876File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling 30877 3087817.9.3 Specifying How Stack Checking is Done 30879-------------------------------------------- 30880 30881GCC will check that stack references are within the boundaries of the 30882stack, if the option `-fstack-check' is specified, in one of three ways: 30883 30884 1. If the value of the `STACK_CHECK_BUILTIN' macro is nonzero, GCC 30885 will assume that you have arranged for full stack checking to be 30886 done at appropriate places in the configuration files. GCC will 30887 not do other special processing. 30888 30889 2. If `STACK_CHECK_BUILTIN' is zero and the value of the 30890 `STACK_CHECK_STATIC_BUILTIN' macro is nonzero, GCC will assume 30891 that you have arranged for static stack checking (checking of the 30892 static stack frame of functions) to be done at appropriate places 30893 in the configuration files. GCC will only emit code to do dynamic 30894 stack checking (checking on dynamic stack allocations) using the 30895 third approach below. 30896 30897 3. If neither of the above are true, GCC will generate code to 30898 periodically "probe" the stack pointer using the values of the 30899 macros defined below. 30900 30901 If neither STACK_CHECK_BUILTIN nor STACK_CHECK_STATIC_BUILTIN is 30902defined, GCC will change its allocation strategy for large objects if 30903the option `-fstack-check' is specified: they will always be allocated 30904dynamically if their size exceeds `STACK_CHECK_MAX_VAR_SIZE' bytes. 30905 30906 -- Macro: STACK_CHECK_BUILTIN 30907 A nonzero value if stack checking is done by the configuration 30908 files in a machine-dependent manner. You should define this macro 30909 if stack checking is required by the ABI of your machine or if you 30910 would like to do stack checking in some more efficient way than 30911 the generic approach. The default value of this macro is zero. 30912 30913 -- Macro: STACK_CHECK_STATIC_BUILTIN 30914 A nonzero value if static stack checking is done by the 30915 configuration files in a machine-dependent manner. You should 30916 define this macro if you would like to do static stack checking in 30917 some more efficient way than the generic approach. The default 30918 value of this macro is zero. 30919 30920 -- Macro: STACK_CHECK_PROBE_INTERVAL_EXP 30921 An integer specifying the interval at which GCC must generate 30922 stack probe instructions, defined as 2 raised to this integer. 30923 You will normally define this macro so that the interval be no 30924 larger than the size of the "guard pages" at the end of a stack 30925 area. The default value of 12 (4096-byte interval) is suitable 30926 for most systems. 30927 30928 -- Macro: STACK_CHECK_MOVING_SP 30929 An integer which is nonzero if GCC should move the stack pointer 30930 page by page when doing probes. This can be necessary on systems 30931 where the stack pointer contains the bottom address of the memory 30932 area accessible to the executing thread at any point in time. In 30933 this situation an alternate signal stack is required in order to 30934 be able to recover from a stack overflow. The default value of 30935 this macro is zero. 30936 30937 -- Macro: STACK_CHECK_PROTECT 30938 The number of bytes of stack needed to recover from a stack 30939 overflow, for languages where such a recovery is supported. The 30940 default value of 75 words with the `setjmp'/`longjmp'-based 30941 exception handling mechanism and 8192 bytes with other exception 30942 handling mechanisms should be adequate for most machines. 30943 30944 The following macros are relevant only if neither STACK_CHECK_BUILTIN 30945nor STACK_CHECK_STATIC_BUILTIN is defined; you can omit them altogether 30946in the opposite case. 30947 30948 -- Macro: STACK_CHECK_MAX_FRAME_SIZE 30949 The maximum size of a stack frame, in bytes. GCC will generate 30950 probe instructions in non-leaf functions to ensure at least this 30951 many bytes of stack are available. If a stack frame is larger 30952 than this size, stack checking will not be reliable and GCC will 30953 issue a warning. The default is chosen so that GCC only generates 30954 one instruction on most systems. You should normally not change 30955 the default value of this macro. 30956 30957 -- Macro: STACK_CHECK_FIXED_FRAME_SIZE 30958 GCC uses this value to generate the above warning message. It 30959 represents the amount of fixed frame used by a function, not 30960 including space for any callee-saved registers, temporaries and 30961 user variables. You need only specify an upper bound for this 30962 amount and will normally use the default of four words. 30963 30964 -- Macro: STACK_CHECK_MAX_VAR_SIZE 30965 The maximum size, in bytes, of an object that GCC will place in the 30966 fixed area of the stack frame when the user specifies 30967 `-fstack-check'. GCC computed the default from the values of the 30968 above macros and you will normally not need to override that 30969 default. 30970 30971 30972File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling 30973 3097417.9.4 Registers That Address the Stack Frame 30975--------------------------------------------- 30976 30977This discusses registers that address the stack frame. 30978 30979 -- Macro: STACK_POINTER_REGNUM 30980 The register number of the stack pointer register, which must also 30981 be a fixed register according to `FIXED_REGISTERS'. On most 30982 machines, the hardware determines which register this is. 30983 30984 -- Macro: FRAME_POINTER_REGNUM 30985 The register number of the frame pointer register, which is used to 30986 access automatic variables in the stack frame. On some machines, 30987 the hardware determines which register this is. On other 30988 machines, you can choose any register you wish for this purpose. 30989 30990 -- Macro: HARD_FRAME_POINTER_REGNUM 30991 On some machines the offset between the frame pointer and starting 30992 offset of the automatic variables is not known until after register 30993 allocation has been done (for example, because the saved registers 30994 are between these two locations). On those machines, define 30995 `FRAME_POINTER_REGNUM' the number of a special, fixed register to 30996 be used internally until the offset is known, and define 30997 `HARD_FRAME_POINTER_REGNUM' to be the actual hard register number 30998 used for the frame pointer. 30999 31000 You should define this macro only in the very rare circumstances 31001 when it is not possible to calculate the offset between the frame 31002 pointer and the automatic variables until after register 31003 allocation has been completed. When this macro is defined, you 31004 must also indicate in your definition of `ELIMINABLE_REGS' how to 31005 eliminate `FRAME_POINTER_REGNUM' into either 31006 `HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'. 31007 31008 Do not define this macro if it would be the same as 31009 `FRAME_POINTER_REGNUM'. 31010 31011 -- Macro: ARG_POINTER_REGNUM 31012 The register number of the arg pointer register, which is used to 31013 access the function's argument list. On some machines, this is 31014 the same as the frame pointer register. On some machines, the 31015 hardware determines which register this is. On other machines, 31016 you can choose any register you wish for this purpose. If this is 31017 not the same register as the frame pointer register, then you must 31018 mark it as a fixed register according to `FIXED_REGISTERS', or 31019 arrange to be able to eliminate it (*note Elimination::). 31020 31021 -- Macro: HARD_FRAME_POINTER_IS_FRAME_POINTER 31022 Define this to a preprocessor constant that is nonzero if 31023 `hard_frame_pointer_rtx' and `frame_pointer_rtx' should be the 31024 same. The default definition is `(HARD_FRAME_POINTER_REGNUM == 31025 FRAME_POINTER_REGNUM)'; you only need to define this macro if that 31026 definition is not suitable for use in preprocessor conditionals. 31027 31028 -- Macro: HARD_FRAME_POINTER_IS_ARG_POINTER 31029 Define this to a preprocessor constant that is nonzero if 31030 `hard_frame_pointer_rtx' and `arg_pointer_rtx' should be the same. 31031 The default definition is `(HARD_FRAME_POINTER_REGNUM == 31032 ARG_POINTER_REGNUM)'; you only need to define this macro if that 31033 definition is not suitable for use in preprocessor conditionals. 31034 31035 -- Macro: RETURN_ADDRESS_POINTER_REGNUM 31036 The register number of the return address pointer register, which 31037 is used to access the current function's return address from the 31038 stack. On some machines, the return address is not at a fixed 31039 offset from the frame pointer or stack pointer or argument 31040 pointer. This register can be defined to point to the return 31041 address on the stack, and then be converted by `ELIMINABLE_REGS' 31042 into either the frame pointer or stack pointer. 31043 31044 Do not define this macro unless there is no other way to get the 31045 return address from the stack. 31046 31047 -- Macro: STATIC_CHAIN_REGNUM 31048 -- Macro: STATIC_CHAIN_INCOMING_REGNUM 31049 Register numbers used for passing a function's static chain 31050 pointer. If register windows are used, the register number as 31051 seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM', 31052 while the register number as seen by the calling function is 31053 `STATIC_CHAIN_REGNUM'. If these registers are the same, 31054 `STATIC_CHAIN_INCOMING_REGNUM' need not be defined. 31055 31056 The static chain register need not be a fixed register. 31057 31058 If the static chain is passed in memory, these macros should not be 31059 defined; instead, the `TARGET_STATIC_CHAIN' hook should be used. 31060 31061 -- Target Hook: rtx TARGET_STATIC_CHAIN (const_tree FNDECL_OR_TYPE, 31062 bool INCOMING_P) 31063 This hook replaces the use of `STATIC_CHAIN_REGNUM' et al for 31064 targets that may use different static chain locations for different 31065 nested functions. This may be required if the target has function 31066 attributes that affect the calling conventions of the function and 31067 those calling conventions use different static chain locations. 31068 31069 The default version of this hook uses `STATIC_CHAIN_REGNUM' et al. 31070 31071 If the static chain is passed in memory, this hook should be used 31072 to provide rtx giving `mem' expressions that denote where they are 31073 stored. Often the `mem' expression as seen by the caller will be 31074 at an offset from the stack pointer and the `mem' expression as 31075 seen by the callee will be at an offset from the frame pointer. The 31076 variables `stack_pointer_rtx', `frame_pointer_rtx', and 31077 `arg_pointer_rtx' will have been initialized and should be used to 31078 refer to those items. 31079 31080 -- Macro: DWARF_FRAME_REGISTERS 31081 This macro specifies the maximum number of hard registers that can 31082 be saved in a call frame. This is used to size data structures 31083 used in DWARF2 exception handling. 31084 31085 Prior to GCC 3.0, this macro was needed in order to establish a 31086 stable exception handling ABI in the face of adding new hard 31087 registers for ISA extensions. In GCC 3.0 and later, the EH ABI is 31088 insulated from changes in the number of hard registers. 31089 Nevertheless, this macro can still be used to reduce the runtime 31090 memory requirements of the exception handling routines, which can 31091 be substantial if the ISA contains a lot of registers that are not 31092 call-saved. 31093 31094 If this macro is not defined, it defaults to 31095 `FIRST_PSEUDO_REGISTER'. 31096 31097 -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS 31098 This macro is similar to `DWARF_FRAME_REGISTERS', but is provided 31099 for backward compatibility in pre GCC 3.0 compiled code. 31100 31101 If this macro is not defined, it defaults to 31102 `DWARF_FRAME_REGISTERS'. 31103 31104 -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO) 31105 Define this macro if the target's representation for dwarf 31106 registers is different than the internal representation for unwind 31107 column. Given a dwarf register, this macro should return the 31108 internal unwind column number to use instead. 31109 31110 See the PowerPC's SPE target for an example. 31111 31112 -- Macro: DWARF_FRAME_REGNUM (REGNO) 31113 Define this macro if the target's representation for dwarf 31114 registers used in .eh_frame or .debug_frame is different from that 31115 used in other debug info sections. Given a GCC hard register 31116 number, this macro should return the .eh_frame register number. 31117 The default is `DBX_REGISTER_NUMBER (REGNO)'. 31118 31119 31120 -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH) 31121 Define this macro to map register numbers held in the call frame 31122 info that GCC has collected using `DWARF_FRAME_REGNUM' to those 31123 that should be output in .debug_frame (`FOR_EH' is zero) and 31124 .eh_frame (`FOR_EH' is nonzero). The default is to return `REGNO'. 31125 31126 31127 -- Macro: REG_VALUE_IN_UNWIND_CONTEXT 31128 Define this macro if the target stores register values as 31129 `_Unwind_Word' type in unwind context. It should be defined if 31130 target register size is larger than the size of `void *'. The 31131 default is to store register values as `void *' type. 31132 31133 31134 -- Macro: ASSUME_EXTENDED_UNWIND_CONTEXT 31135 Define this macro to be 1 if the target always uses extended unwind 31136 context with version, args_size and by_value fields. If it is 31137 undefined, it will be defined to 1 when 31138 `REG_VALUE_IN_UNWIND_CONTEXT' is defined and 0 otherwise. 31139 31140 31141 31142File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling 31143 3114417.9.5 Eliminating Frame Pointer and Arg Pointer 31145------------------------------------------------ 31146 31147This is about eliminating the frame pointer and arg pointer. 31148 31149 -- Target Hook: bool TARGET_FRAME_POINTER_REQUIRED (void) 31150 This target hook should return `true' if a function must have and 31151 use a frame pointer. This target hook is called in the reload 31152 pass. If its return value is `true' the function will have a 31153 frame pointer. 31154 31155 This target hook can in principle examine the current function and 31156 decide according to the facts, but on most machines the constant 31157 `false' or the constant `true' suffices. Use `false' when the 31158 machine allows code to be generated with no frame pointer, and 31159 doing so saves some time or space. Use `true' when there is no 31160 possible advantage to avoiding a frame pointer. 31161 31162 In certain cases, the compiler does not know how to produce valid 31163 code without a frame pointer. The compiler recognizes those cases 31164 and automatically gives the function a frame pointer regardless of 31165 what `TARGET_FRAME_POINTER_REQUIRED' returns. You don't need to 31166 worry about them. 31167 31168 In a function that does not require a frame pointer, the frame 31169 pointer register can be allocated for ordinary usage, unless you 31170 mark it as a fixed register. See `FIXED_REGISTERS' for more 31171 information. 31172 31173 Default return value is `false'. 31174 31175 -- Macro: INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR) 31176 A C statement to store in the variable DEPTH-VAR the difference 31177 between the frame pointer and the stack pointer values immediately 31178 after the function prologue. The value would be computed from 31179 information such as the result of `get_frame_size ()' and the 31180 tables of registers `regs_ever_live' and `call_used_regs'. 31181 31182 If `ELIMINABLE_REGS' is defined, this macro will be not be used and 31183 need not be defined. Otherwise, it must be defined even if 31184 `TARGET_FRAME_POINTER_REQUIRED' always returns true; in that case, 31185 you may set DEPTH-VAR to anything. 31186 31187 -- Macro: ELIMINABLE_REGS 31188 If defined, this macro specifies a table of register pairs used to 31189 eliminate unneeded registers that point into the stack frame. If 31190 it is not defined, the only elimination attempted by the compiler 31191 is to replace references to the frame pointer with references to 31192 the stack pointer. 31193 31194 The definition of this macro is a list of structure 31195 initializations, each of which specifies an original and 31196 replacement register. 31197 31198 On some machines, the position of the argument pointer is not 31199 known until the compilation is completed. In such a case, a 31200 separate hard register must be used for the argument pointer. 31201 This register can be eliminated by replacing it with either the 31202 frame pointer or the argument pointer, depending on whether or not 31203 the frame pointer has been eliminated. 31204 31205 In this case, you might specify: 31206 #define ELIMINABLE_REGS \ 31207 {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \ 31208 {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \ 31209 {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}} 31210 31211 Note that the elimination of the argument pointer with the stack 31212 pointer is specified first since that is the preferred elimination. 31213 31214 -- Target Hook: bool TARGET_CAN_ELIMINATE (const int FROM_REG, const 31215 int TO_REG) 31216 This target hook should returns `true' if the compiler is allowed 31217 to try to replace register number FROM_REG with register number 31218 TO_REG. This target hook need only be defined if `ELIMINABLE_REGS' 31219 is defined, and will usually be `true', since most of the cases 31220 preventing register elimination are things that the compiler 31221 already knows about. 31222 31223 Default return value is `true'. 31224 31225 -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR) 31226 This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It 31227 specifies the initial difference between the specified pair of 31228 registers. This macro must be defined if `ELIMINABLE_REGS' is 31229 defined. 31230 31231 31232File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling 31233 3123417.9.6 Passing Function Arguments on the Stack 31235---------------------------------------------- 31236 31237The macros in this section control how arguments are passed on the 31238stack. See the following section for other macros that control passing 31239certain arguments in registers. 31240 31241 -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (const_tree FNTYPE) 31242 This target hook returns `true' if an argument declared in a 31243 prototype as an integral type smaller than `int' should actually be 31244 passed as an `int'. In addition to avoiding errors in certain 31245 cases of mismatch, it also makes for better code on certain 31246 machines. The default is to not promote prototypes. 31247 31248 -- Macro: PUSH_ARGS 31249 A C expression. If nonzero, push insns will be used to pass 31250 outgoing arguments. If the target machine does not have a push 31251 instruction, set it to zero. That directs GCC to use an alternate 31252 strategy: to allocate the entire argument block and then store the 31253 arguments into it. When `PUSH_ARGS' is nonzero, `PUSH_ROUNDING' 31254 must be defined too. 31255 31256 -- Macro: PUSH_ARGS_REVERSED 31257 A C expression. If nonzero, function arguments will be evaluated 31258 from last to first, rather than from first to last. If this macro 31259 is not defined, it defaults to `PUSH_ARGS' on targets where the 31260 stack and args grow in opposite directions, and 0 otherwise. 31261 31262 -- Macro: PUSH_ROUNDING (NPUSHED) 31263 A C expression that is the number of bytes actually pushed onto the 31264 stack when an instruction attempts to push NPUSHED bytes. 31265 31266 On some machines, the definition 31267 31268 #define PUSH_ROUNDING(BYTES) (BYTES) 31269 31270 will suffice. But on other machines, instructions that appear to 31271 push one byte actually push two bytes in an attempt to maintain 31272 alignment. Then the definition should be 31273 31274 #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) 31275 31276 If the value of this macro has a type, it should be an unsigned 31277 type. 31278 31279 -- Macro: ACCUMULATE_OUTGOING_ARGS 31280 A C expression. If nonzero, the maximum amount of space required 31281 for outgoing arguments will be computed and placed into 31282 `crtl->outgoing_args_size'. No space will be pushed onto the 31283 stack for each call; instead, the function prologue should 31284 increase the stack frame size by this amount. 31285 31286 Setting both `PUSH_ARGS' and `ACCUMULATE_OUTGOING_ARGS' is not 31287 proper. 31288 31289 -- Macro: REG_PARM_STACK_SPACE (FNDECL) 31290 Define this macro if functions should assume that stack space has 31291 been allocated for arguments even when their values are passed in 31292 registers. 31293 31294 The value of this macro is the size, in bytes, of the area 31295 reserved for arguments passed in registers for the function 31296 represented by FNDECL, which can be zero if GCC is calling a 31297 library function. The argument FNDECL can be the FUNCTION_DECL, 31298 or the type itself of the function. 31299 31300 This space can be allocated by the caller, or be a part of the 31301 machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says 31302 which. 31303 31304 -- Macro: INCOMING_REG_PARM_STACK_SPACE (FNDECL) 31305 Like `REG_PARM_STACK_SPACE', but for incoming register arguments. 31306 Define this macro if space guaranteed when compiling a function 31307 body is different to space required when making a call, a 31308 situation that can arise with K&R style function definitions. 31309 31310 -- Macro: OUTGOING_REG_PARM_STACK_SPACE (FNTYPE) 31311 Define this to a nonzero value if it is the responsibility of the 31312 caller to allocate the area reserved for arguments passed in 31313 registers when calling a function of FNTYPE. FNTYPE may be NULL 31314 if the function called is a library function. 31315 31316 If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls 31317 whether the space for these arguments counts in the value of 31318 `crtl->outgoing_args_size'. 31319 31320 -- Macro: STACK_PARMS_IN_REG_PARM_AREA 31321 Define this macro if `REG_PARM_STACK_SPACE' is defined, but the 31322 stack parameters don't skip the area specified by it. 31323 31324 Normally, when a parameter is not passed in registers, it is 31325 placed on the stack beyond the `REG_PARM_STACK_SPACE' area. 31326 Defining this macro suppresses this behavior and causes the 31327 parameter to be passed on the stack in its natural location. 31328 31329 -- Target Hook: int TARGET_RETURN_POPS_ARGS (tree FUNDECL, tree 31330 FUNTYPE, int SIZE) 31331 This target hook returns the number of bytes of its own arguments 31332 that a function pops on returning, or 0 if the function pops no 31333 arguments and the caller must therefore pop them all after the 31334 function returns. 31335 31336 FUNDECL is a C variable whose value is a tree node that describes 31337 the function in question. Normally it is a node of type 31338 `FUNCTION_DECL' that describes the declaration of the function. 31339 From this you can obtain the `DECL_ATTRIBUTES' of the function. 31340 31341 FUNTYPE is a C variable whose value is a tree node that describes 31342 the function in question. Normally it is a node of type 31343 `FUNCTION_TYPE' that describes the data type of the function. 31344 From this it is possible to obtain the data types of the value and 31345 arguments (if known). 31346 31347 When a call to a library function is being considered, FUNDECL 31348 will contain an identifier node for the library function. Thus, if 31349 you need to distinguish among various library functions, you can 31350 do so by their names. Note that "library function" in this 31351 context means a function used to perform arithmetic, whose name is 31352 known specially in the compiler and was not mentioned in the C 31353 code being compiled. 31354 31355 SIZE is the number of bytes of arguments passed on the stack. If 31356 a variable number of bytes is passed, it is zero, and argument 31357 popping will always be the responsibility of the calling function. 31358 31359 On the VAX, all functions always pop their arguments, so the 31360 definition of this macro is SIZE. On the 68000, using the standard 31361 calling convention, no functions pop their arguments, so the value 31362 of the macro is always 0 in this case. But an alternative calling 31363 convention is available in which functions that take a fixed 31364 number of arguments pop them but other functions (such as 31365 `printf') pop nothing (the caller pops all). When this convention 31366 is in use, FUNTYPE is examined to determine whether a function 31367 takes a fixed number of arguments. 31368 31369 -- Macro: CALL_POPS_ARGS (CUM) 31370 A C expression that should indicate the number of bytes a call 31371 sequence pops off the stack. It is added to the value of 31372 `RETURN_POPS_ARGS' when compiling a function call. 31373 31374 CUM is the variable in which all arguments to the called function 31375 have been accumulated. 31376 31377 On certain architectures, such as the SH5, a call trampoline is 31378 used that pops certain registers off the stack, depending on the 31379 arguments that have been passed to the function. Since this is a 31380 property of the call site, not of the called function, 31381 `RETURN_POPS_ARGS' is not appropriate. 31382 31383 31384File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling 31385 3138617.9.7 Passing Arguments in Registers 31387------------------------------------- 31388 31389This section describes the macros which let you control how various 31390types of arguments are passed in registers or how they are arranged in 31391the stack. 31392 31393 -- Target Hook: rtx TARGET_FUNCTION_ARG (cumulative_args_t CA, 31394 machine_mode MODE, const_tree TYPE, bool NAMED) 31395 Return an RTX indicating whether a function argument is passed in a 31396 register and if so, which register. 31397 31398 The arguments are CA, which summarizes all the previous arguments; 31399 MODE, the machine mode of the argument; TYPE, the data type of the 31400 argument as a tree node or 0 if that is not known (which happens 31401 for C support library functions); and NAMED, which is `true' for 31402 an ordinary argument and `false' for nameless arguments that 31403 correspond to `...' in the called function's prototype. TYPE can 31404 be an incomplete type if a syntax error has previously occurred. 31405 31406 The return value is usually either a `reg' RTX for the hard 31407 register in which to pass the argument, or zero to pass the 31408 argument on the stack. 31409 31410 The return value can be a `const_int' which means argument is 31411 passed in a target specific slot with specified number. Target 31412 hooks should be used to store or load argument in such case. See 31413 `TARGET_STORE_BOUNDS_FOR_ARG' and `TARGET_LOAD_BOUNDS_FOR_ARG' for 31414 more information. 31415 31416 The value of the expression can also be a `parallel' RTX. This is 31417 used when an argument is passed in multiple locations. The mode 31418 of the `parallel' should be the mode of the entire argument. The 31419 `parallel' holds any number of `expr_list' pairs; each one 31420 describes where part of the argument is passed. In each 31421 `expr_list' the first operand must be a `reg' RTX for the hard 31422 register in which to pass this part of the argument, and the mode 31423 of the register RTX indicates how large this part of the argument 31424 is. The second operand of the `expr_list' is a `const_int' which 31425 gives the offset in bytes into the entire argument of where this 31426 part starts. As a special exception the first `expr_list' in the 31427 `parallel' RTX may have a first operand of zero. This indicates 31428 that the entire argument is also stored on the stack. 31429 31430 The last time this hook is called, it is called with `MODE == 31431 VOIDmode', and its result is passed to the `call' or `call_value' 31432 pattern as operands 2 and 3 respectively. 31433 31434 The usual way to make the ISO library `stdarg.h' work on a machine 31435 where some arguments are usually passed in registers, is to cause 31436 nameless arguments to be passed on the stack instead. This is 31437 done by making `TARGET_FUNCTION_ARG' return 0 whenever NAMED is 31438 `false'. 31439 31440 You may use the hook `targetm.calls.must_pass_in_stack' in the 31441 definition of this macro to determine if this argument is of a 31442 type that must be passed in the stack. If `REG_PARM_STACK_SPACE' 31443 is not defined and `TARGET_FUNCTION_ARG' returns nonzero for such 31444 an argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is 31445 defined, the argument will be computed in the stack and then 31446 loaded into a register. 31447 31448 -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (machine_mode MODE, 31449 const_tree TYPE) 31450 This target hook should return `true' if we should not pass TYPE 31451 solely in registers. The file `expr.h' defines a definition that 31452 is usually appropriate, refer to `expr.h' for additional 31453 documentation. 31454 31455 -- Target Hook: rtx TARGET_FUNCTION_INCOMING_ARG (cumulative_args_t 31456 CA, machine_mode MODE, const_tree TYPE, bool NAMED) 31457 Define this hook if the target machine has "register windows", so 31458 that the register in which a function sees an arguments is not 31459 necessarily the same as the one in which the caller passed the 31460 argument. 31461 31462 For such machines, `TARGET_FUNCTION_ARG' computes the register in 31463 which the caller passes the value, and 31464 `TARGET_FUNCTION_INCOMING_ARG' should be defined in a similar 31465 fashion to tell the function being called where the arguments will 31466 arrive. 31467 31468 If `TARGET_FUNCTION_INCOMING_ARG' is not defined, 31469 `TARGET_FUNCTION_ARG' serves both purposes. 31470 31471 -- Target Hook: bool TARGET_USE_PSEUDO_PIC_REG (void) 31472 This hook should return 1 in case pseudo register should be created 31473 for pic_offset_table_rtx during function expand. 31474 31475 -- Target Hook: void TARGET_INIT_PIC_REG (void) 31476 Perform a target dependent initialization of pic_offset_table_rtx. 31477 This hook is called at the start of register allocation. 31478 31479 -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (cumulative_args_t CUM, 31480 machine_mode MODE, tree TYPE, bool NAMED) 31481 This target hook returns the number of bytes at the beginning of an 31482 argument that must be put in registers. The value must be zero for 31483 arguments that are passed entirely in registers or that are 31484 entirely pushed on the stack. 31485 31486 On some machines, certain arguments must be passed partially in 31487 registers and partially in memory. On these machines, typically 31488 the first few words of arguments are passed in registers, and the 31489 rest on the stack. If a multi-word argument (a `double' or a 31490 structure) crosses that boundary, its first few words must be 31491 passed in registers and the rest must be pushed. This macro tells 31492 the compiler when this occurs, and how many bytes should go in 31493 registers. 31494 31495 `TARGET_FUNCTION_ARG' for these arguments should return the first 31496 register to be used by the caller for this argument; likewise 31497 `TARGET_FUNCTION_INCOMING_ARG', for the called function. 31498 31499 -- Target Hook: bool TARGET_PASS_BY_REFERENCE (cumulative_args_t CUM, 31500 machine_mode MODE, const_tree TYPE, bool NAMED) 31501 This target hook should return `true' if an argument at the 31502 position indicated by CUM should be passed by reference. This 31503 predicate is queried after target independent reasons for being 31504 passed by reference, such as `TREE_ADDRESSABLE (type)'. 31505 31506 If the hook returns true, a copy of that argument is made in 31507 memory and a pointer to the argument is passed instead of the 31508 argument itself. The pointer is passed in whatever way is 31509 appropriate for passing a pointer to that type. 31510 31511 -- Target Hook: bool TARGET_CALLEE_COPIES (cumulative_args_t CUM, 31512 machine_mode MODE, const_tree TYPE, bool NAMED) 31513 The function argument described by the parameters to this hook is 31514 known to be passed by reference. The hook should return true if 31515 the function argument should be copied by the callee instead of 31516 copied by the caller. 31517 31518 For any argument for which the hook returns true, if it can be 31519 determined that the argument is not modified, then a copy need not 31520 be generated. 31521 31522 The default version of this hook always returns false. 31523 31524 -- Macro: CUMULATIVE_ARGS 31525 A C type for declaring a variable that is used as the first 31526 argument of `TARGET_FUNCTION_ARG' and other related values. For 31527 some target machines, the type `int' suffices and can hold the 31528 number of bytes of argument so far. 31529 31530 There is no need to record in `CUMULATIVE_ARGS' anything about the 31531 arguments that have been passed on the stack. The compiler has 31532 other variables to keep track of that. For target machines on 31533 which all arguments are passed on the stack, there is no need to 31534 store anything in `CUMULATIVE_ARGS'; however, the data structure 31535 must exist and should not be empty, so use `int'. 31536 31537 -- Macro: OVERRIDE_ABI_FORMAT (FNDECL) 31538 If defined, this macro is called before generating any code for a 31539 function, but after the CFUN descriptor for the function has been 31540 created. The back end may use this macro to update CFUN to 31541 reflect an ABI other than that which would normally be used by 31542 default. If the compiler is generating code for a 31543 compiler-generated function, FNDECL may be `NULL'. 31544 31545 -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL, 31546 N_NAMED_ARGS) 31547 A C statement (sans semicolon) for initializing the variable CUM 31548 for the state at the beginning of the argument list. The variable 31549 has type `CUMULATIVE_ARGS'. The value of FNTYPE is the tree node 31550 for the data type of the function which will receive the args, or 31551 0 if the args are to a compiler support library function. For 31552 direct calls that are not libcalls, FNDECL contain the declaration 31553 node of the function. FNDECL is also set when 31554 `INIT_CUMULATIVE_ARGS' is used to find arguments for the function 31555 being compiled. N_NAMED_ARGS is set to the number of named 31556 arguments, including a structure return address if it is passed as 31557 a parameter, when making a call. When processing incoming 31558 arguments, N_NAMED_ARGS is set to -1. 31559 31560 When processing a call to a compiler support library function, 31561 LIBNAME identifies which one. It is a `symbol_ref' rtx which 31562 contains the name of the function, as a string. LIBNAME is 0 when 31563 an ordinary C function call is being processed. Thus, each time 31564 this macro is called, either LIBNAME or FNTYPE is nonzero, but 31565 never both of them at once. 31566 31567 -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME) 31568 Like `INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls, 31569 it gets a `MODE' argument instead of FNTYPE, that would be `NULL'. 31570 INDIRECT would always be zero, too. If this macro is not defined, 31571 `INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is used instead. 31572 31573 -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME) 31574 Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of 31575 finding the arguments for the function being compiled. If this 31576 macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead. 31577 31578 The value passed for LIBNAME is always 0, since library routines 31579 with special calling conventions are never compiled with GCC. The 31580 argument LIBNAME exists for symmetry with `INIT_CUMULATIVE_ARGS'. 31581 31582 -- Target Hook: void TARGET_FUNCTION_ARG_ADVANCE (cumulative_args_t 31583 CA, machine_mode MODE, const_tree TYPE, bool NAMED) 31584 This hook updates the summarizer variable pointed to by CA to 31585 advance past an argument in the argument list. The values MODE, 31586 TYPE and NAMED describe that argument. Once this is done, the 31587 variable CUM is suitable for analyzing the _following_ argument 31588 with `TARGET_FUNCTION_ARG', etc. 31589 31590 This hook need not do anything if the argument in question was 31591 passed on the stack. The compiler knows how to track the amount 31592 of stack space used for arguments without any special help. 31593 31594 -- Macro: FUNCTION_ARG_OFFSET (MODE, TYPE) 31595 If defined, a C expression that is the number of bytes to add to 31596 the offset of the argument passed in memory. This is needed for 31597 the SPU, which passes `char' and `short' arguments in the preferred 31598 slot that is in the middle of the quad word instead of starting at 31599 the top. 31600 31601 -- Macro: FUNCTION_ARG_PADDING (MODE, TYPE) 31602 If defined, a C expression which determines whether, and in which 31603 direction, to pad out an argument with extra space. The value 31604 should be of type `enum direction': either `upward' to pad above 31605 the argument, `downward' to pad below, or `none' to inhibit 31606 padding. 31607 31608 The _amount_ of padding is not controlled by this macro, but by the 31609 target hook `TARGET_FUNCTION_ARG_ROUND_BOUNDARY'. It is always 31610 just enough to reach the next multiple of that boundary. 31611 31612 This macro has a default definition which is right for most 31613 systems. For little-endian machines, the default is to pad 31614 upward. For big-endian machines, the default is to pad downward 31615 for an argument of constant size shorter than an `int', and upward 31616 otherwise. 31617 31618 -- Macro: PAD_VARARGS_DOWN 31619 If defined, a C expression which determines whether the default 31620 implementation of va_arg will attempt to pad down before reading 31621 the next argument, if that argument is smaller than its aligned 31622 space as controlled by `PARM_BOUNDARY'. If this macro is not 31623 defined, all such arguments are padded down if `BYTES_BIG_ENDIAN' 31624 is true. 31625 31626 -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST) 31627 Specify padding for the last element of a block move between 31628 registers and memory. FIRST is nonzero if this is the only 31629 element. Defining this macro allows better control of register 31630 function parameters on big-endian machines, without using 31631 `PARALLEL' rtl. In particular, `MUST_PASS_IN_STACK' need not test 31632 padding and mode of types in registers, as there is no longer a 31633 "wrong" part of a register; For example, a three byte aggregate 31634 may be passed in the high part of a register if so required. 31635 31636 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_BOUNDARY 31637 (machine_mode MODE, const_tree TYPE) 31638 This hook returns the alignment boundary, in bits, of an argument 31639 with the specified mode and type. The default hook returns 31640 `PARM_BOUNDARY' for all arguments. 31641 31642 -- Target Hook: unsigned int TARGET_FUNCTION_ARG_ROUND_BOUNDARY 31643 (machine_mode MODE, const_tree TYPE) 31644 Normally, the size of an argument is rounded up to `PARM_BOUNDARY', 31645 which is the default value for this hook. You can define this 31646 hook to return a different value if an argument size must be 31647 rounded to a larger value. 31648 31649 -- Macro: FUNCTION_ARG_REGNO_P (REGNO) 31650 A C expression that is nonzero if REGNO is the number of a hard 31651 register in which function arguments are sometimes passed. This 31652 does _not_ include implicit arguments such as the static chain and 31653 the structure-value address. On many machines, no registers can be 31654 used for this purpose since all function arguments are pushed on 31655 the stack. 31656 31657 -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (const_tree TYPE) 31658 This hook should return true if parameter of type TYPE are passed 31659 as two scalar parameters. By default, GCC will attempt to pack 31660 complex arguments into the target's word size. Some ABIs require 31661 complex arguments to be split and treated as their individual 31662 components. For example, on AIX64, complex floats should be 31663 passed in a pair of floating point registers, even though a 31664 complex float would fit in one 64-bit floating point register. 31665 31666 The default value of this hook is `NULL', which is treated as 31667 always false. 31668 31669 -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void) 31670 This hook returns a type node for `va_list' for the target. The 31671 default version of the hook returns `void*'. 31672 31673 -- Target Hook: int TARGET_ENUM_VA_LIST_P (int IDX, const char 31674 **PNAME, tree *PTREE) 31675 This target hook is used in function `c_common_nodes_and_builtins' 31676 to iterate through the target specific builtin types for va_list. 31677 The variable IDX is used as iterator. PNAME has to be a pointer to 31678 a `const char *' and PTREE a pointer to a `tree' typed variable. 31679 The arguments PNAME and PTREE are used to store the result of this 31680 macro and are set to the name of the va_list builtin type and its 31681 internal type. If the return value of this macro is zero, then 31682 there is no more element. Otherwise the IDX should be increased 31683 for the next call of this macro to iterate through all types. 31684 31685 -- Target Hook: tree TARGET_FN_ABI_VA_LIST (tree FNDECL) 31686 This hook returns the va_list type of the calling convention 31687 specified by FNDECL. The default version of this hook returns 31688 `va_list_type_node'. 31689 31690 -- Target Hook: tree TARGET_CANONICAL_VA_LIST_TYPE (tree TYPE) 31691 This hook returns the va_list type of the calling convention 31692 specified by the type of TYPE. If TYPE is not a valid va_list 31693 type, it returns `NULL_TREE'. 31694 31695 -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree 31696 TYPE, gimple_seq *PRE_P, gimple_seq *POST_P) 31697 This hook performs target-specific gimplification of 31698 `VA_ARG_EXPR'. The first two parameters correspond to the 31699 arguments to `va_arg'; the latter two are as in 31700 `gimplify.c:gimplify_expr'. 31701 31702 -- Target Hook: bool TARGET_VALID_POINTER_MODE (machine_mode MODE) 31703 Define this to return nonzero if the port can handle pointers with 31704 machine mode MODE. The default version of this hook returns true 31705 for both `ptr_mode' and `Pmode'. 31706 31707 -- Target Hook: bool TARGET_REF_MAY_ALIAS_ERRNO (struct ao_ref *REF) 31708 Define this to return nonzero if the memory reference REF may 31709 alias with the system C library errno location. The default 31710 version of this hook assumes the system C library errno location 31711 is either a declaration of type int or accessed by dereferencing 31712 a pointer to int. 31713 31714 -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (machine_mode MODE) 31715 Define this to return nonzero if the port is prepared to handle 31716 insns involving scalar mode MODE. For a scalar mode to be 31717 considered supported, all the basic arithmetic and comparisons 31718 must work. 31719 31720 The default version of this hook returns true for any mode 31721 required to handle the basic C types (as defined by the port). 31722 Included here are the double-word arithmetic supported by the code 31723 in `optabs.c'. 31724 31725 -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (machine_mode MODE) 31726 Define this to return nonzero if the port is prepared to handle 31727 insns involving vector mode MODE. At the very least, it must have 31728 move patterns for this mode. 31729 31730 -- Target Hook: bool TARGET_ARRAY_MODE_SUPPORTED_P (machine_mode MODE, 31731 unsigned HOST_WIDE_INT NELEMS) 31732 Return true if GCC should try to use a scalar mode to store an 31733 array of NELEMS elements, given that each element has mode MODE. 31734 Returning true here overrides the usual `MAX_FIXED_MODE' limit and 31735 allows GCC to use any defined integer mode. 31736 31737 One use of this hook is to support vector load and store operations 31738 that operate on several homogeneous vectors. For example, ARM NEON 31739 has operations like: 31740 31741 int8x8x3_t vld3_s8 (const int8_t *) 31742 31743 where the return type is defined as: 31744 31745 typedef struct int8x8x3_t 31746 { 31747 int8x8_t val[3]; 31748 } int8x8x3_t; 31749 31750 If this hook allows `val' to have a scalar mode, then `int8x8x3_t' 31751 can have the same mode. GCC can then store `int8x8x3_t's in 31752 registers rather than forcing them onto the stack. 31753 31754 -- Target Hook: bool TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P 31755 (machine_mode MODE) 31756 Define this to return nonzero if libgcc provides support for the 31757 floating-point mode MODE, which is known to pass 31758 `TARGET_SCALAR_MODE_SUPPORTED_P'. The default version of this 31759 hook returns true for all of `SFmode', `DFmode', `XFmode' and 31760 `TFmode', if such modes exist. 31761 31762 -- Target Hook: bool TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P 31763 (machine_mode MODE) 31764 Define this to return nonzero for machine modes for which the port 31765 has small register classes. If this target hook returns nonzero 31766 for a given MODE, the compiler will try to minimize the lifetime 31767 of registers in MODE. The hook may be called with `VOIDmode' as 31768 argument. In this case, the hook is expected to return nonzero if 31769 it returns nonzero for any mode. 31770 31771 On some machines, it is risky to let hard registers live across 31772 arbitrary insns. Typically, these machines have instructions that 31773 require values to be in specific registers (like an accumulator), 31774 and reload will fail if the required hard register is used for 31775 another purpose across such an insn. 31776 31777 Passes before reload do not know which hard registers will be used 31778 in an instruction, but the machine modes of the registers set or 31779 used in the instruction are already known. And for some machines, 31780 register classes are small for, say, integer registers but not for 31781 floating point registers. For example, the AMD x86-64 31782 architecture requires specific registers for the legacy x86 31783 integer instructions, but there are many SSE registers for 31784 floating point operations. On such targets, a good strategy may 31785 be to return nonzero from this hook for `INTEGRAL_MODE_P' machine 31786 modes but zero for the SSE register classes. 31787 31788 The default version of this hook returns false for any mode. It 31789 is always safe to redefine this hook to return with a nonzero 31790 value. But if you unnecessarily define it, you will reduce the 31791 amount of optimizations that can be performed in some cases. If 31792 you do not define this hook to return a nonzero value when it is 31793 required, the compiler will run out of spill registers and print a 31794 fatal error message. 31795 31796 31797File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling 31798 3179917.9.8 How Scalar Function Values Are Returned 31800---------------------------------------------- 31801 31802This section discusses the macros that control returning scalars as 31803values--values that can fit in registers. 31804 31805 -- Target Hook: rtx TARGET_FUNCTION_VALUE (const_tree RET_TYPE, 31806 const_tree FN_DECL_OR_TYPE, bool OUTGOING) 31807 Define this to return an RTX representing the place where a 31808 function returns or receives a value of data type RET_TYPE, a tree 31809 node representing a data type. FN_DECL_OR_TYPE is a tree node 31810 representing `FUNCTION_DECL' or `FUNCTION_TYPE' of a function 31811 being called. If OUTGOING is false, the hook should compute the 31812 register in which the caller will see the return value. 31813 Otherwise, the hook should return an RTX representing the place 31814 where a function returns a value. 31815 31816 On many machines, only `TYPE_MODE (RET_TYPE)' is relevant. 31817 (Actually, on most machines, scalar values are returned in the same 31818 place regardless of mode.) The value of the expression is usually 31819 a `reg' RTX for the hard register where the return value is stored. 31820 The value can also be a `parallel' RTX, if the return value is in 31821 multiple places. See `TARGET_FUNCTION_ARG' for an explanation of 31822 the `parallel' form. Note that the callee will populate every 31823 location specified in the `parallel', but if the first element of 31824 the `parallel' contains the whole return value, callers will use 31825 that element as the canonical location and ignore the others. The 31826 m68k port uses this type of `parallel' to return pointers in both 31827 `%a0' (the canonical location) and `%d0'. 31828 31829 If `TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply 31830 the same promotion rules specified in `PROMOTE_MODE' if VALTYPE is 31831 a scalar type. 31832 31833 If the precise function being called is known, FUNC is a tree node 31834 (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This 31835 makes it possible to use a different value-returning convention 31836 for specific functions when all their calls are known. 31837 31838 Some target machines have "register windows" so that the register 31839 in which a function returns its value is not the same as the one 31840 in which the caller sees the value. For such machines, you should 31841 return different RTX depending on OUTGOING. 31842 31843 `TARGET_FUNCTION_VALUE' is not used for return values with 31844 aggregate data types, because these are returned in another way. 31845 See `TARGET_STRUCT_VALUE_RTX' and related macros, below. 31846 31847 -- Macro: FUNCTION_VALUE (VALTYPE, FUNC) 31848 This macro has been deprecated. Use `TARGET_FUNCTION_VALUE' for a 31849 new target instead. 31850 31851 -- Macro: LIBCALL_VALUE (MODE) 31852 A C expression to create an RTX representing the place where a 31853 library function returns a value of mode MODE. 31854 31855 Note that "library function" in this context means a compiler 31856 support routine, used to perform arithmetic, whose name is known 31857 specially by the compiler and was not mentioned in the C code being 31858 compiled. 31859 31860 -- Target Hook: rtx TARGET_LIBCALL_VALUE (machine_mode MODE, const_rtx 31861 FUN) 31862 Define this hook if the back-end needs to know the name of the 31863 libcall function in order to determine where the result should be 31864 returned. 31865 31866 The mode of the result is given by MODE and the name of the called 31867 library function is given by FUN. The hook should return an RTX 31868 representing the place where the library function result will be 31869 returned. 31870 31871 If this hook is not defined, then LIBCALL_VALUE will be used. 31872 31873 -- Macro: FUNCTION_VALUE_REGNO_P (REGNO) 31874 A C expression that is nonzero if REGNO is the number of a hard 31875 register in which the values of called function may come back. 31876 31877 A register whose use for returning values is limited to serving as 31878 the second of a pair (for a value of type `double', say) need not 31879 be recognized by this macro. So for most machines, this definition 31880 suffices: 31881 31882 #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) 31883 31884 If the machine has register windows, so that the caller and the 31885 called function use different registers for the return value, this 31886 macro should recognize only the caller's register numbers. 31887 31888 This macro has been deprecated. Use 31889 `TARGET_FUNCTION_VALUE_REGNO_P' for a new target instead. 31890 31891 -- Target Hook: bool TARGET_FUNCTION_VALUE_REGNO_P (const unsigned int 31892 REGNO) 31893 A target hook that return `true' if REGNO is the number of a hard 31894 register in which the values of called function may come back. 31895 31896 A register whose use for returning values is limited to serving as 31897 the second of a pair (for a value of type `double', say) need not 31898 be recognized by this target hook. 31899 31900 If the machine has register windows, so that the caller and the 31901 called function use different registers for the return value, this 31902 target hook should recognize only the caller's register numbers. 31903 31904 If this hook is not defined, then FUNCTION_VALUE_REGNO_P will be 31905 used. 31906 31907 -- Macro: APPLY_RESULT_SIZE 31908 Define this macro if `untyped_call' and `untyped_return' need more 31909 space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and 31910 restoring an arbitrary return value. 31911 31912 -- Target Hook: bool TARGET_OMIT_STRUCT_RETURN_REG 31913 Normally, when a function returns a structure by memory, the 31914 address is passed as an invisible pointer argument, but the 31915 compiler also arranges to return the address from the function 31916 like it would a normal pointer return value. Define this to true 31917 if that behaviour is undesirable on your target. 31918 31919 -- Target Hook: bool TARGET_RETURN_IN_MSB (const_tree TYPE) 31920 This hook should return true if values of type TYPE are returned 31921 at the most significant end of a register (in other words, if they 31922 are padded at the least significant end). You can assume that TYPE 31923 is returned in a register; the caller is required to check this. 31924 31925 Note that the register provided by `TARGET_FUNCTION_VALUE' must be 31926 able to hold the complete return value. For example, if a 1-, 2- 31927 or 3-byte structure is returned at the most significant end of a 31928 4-byte register, `TARGET_FUNCTION_VALUE' should provide an 31929 `SImode' rtx. 31930 31931 31932File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling 31933 3193417.9.9 How Large Values Are Returned 31935------------------------------------ 31936 31937When a function value's mode is `BLKmode' (and in some other cases), 31938the value is not returned according to `TARGET_FUNCTION_VALUE' (*note 31939Scalar Return::). Instead, the caller passes the address of a block of 31940memory in which the value should be stored. This address is called the 31941"structure value address". 31942 31943 This section describes how to control returning structure values in 31944memory. 31945 31946 -- Target Hook: bool TARGET_RETURN_IN_MEMORY (const_tree TYPE, 31947 const_tree FNTYPE) 31948 This target hook should return a nonzero value to say to return the 31949 function value in memory, just as large structures are always 31950 returned. Here TYPE will be the data type of the value, and FNTYPE 31951 will be the type of the function doing the returning, or `NULL' for 31952 libcalls. 31953 31954 Note that values of mode `BLKmode' must be explicitly handled by 31955 this function. Also, the option `-fpcc-struct-return' takes 31956 effect regardless of this macro. On most systems, it is possible 31957 to leave the hook undefined; this causes a default definition to 31958 be used, whose value is the constant 1 for `BLKmode' values, and 0 31959 otherwise. 31960 31961 Do not use this hook to indicate that structures and unions should 31962 always be returned in memory. You should instead use 31963 `DEFAULT_PCC_STRUCT_RETURN' to indicate this. 31964 31965 -- Macro: DEFAULT_PCC_STRUCT_RETURN 31966 Define this macro to be 1 if all structure and union return values 31967 must be in memory. Since this results in slower code, this should 31968 be defined only if needed for compatibility with other compilers 31969 or with an ABI. If you define this macro to be 0, then the 31970 conventions used for structure and union return values are decided 31971 by the `TARGET_RETURN_IN_MEMORY' target hook. 31972 31973 If not defined, this defaults to the value 1. 31974 31975 -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING) 31976 This target hook should return the location of the structure value 31977 address (normally a `mem' or `reg'), or 0 if the address is passed 31978 as an "invisible" first argument. Note that FNDECL may be `NULL', 31979 for libcalls. You do not need to define this target hook if the 31980 address is always passed as an "invisible" first argument. 31981 31982 On some architectures the place where the structure value address 31983 is found by the called function is not the same place that the 31984 caller put it. This can be due to register windows, or it could 31985 be because the function prologue moves it to a different place. 31986 INCOMING is `1' or `2' when the location is needed in the context 31987 of the called function, and `0' in the context of the caller. 31988 31989 If INCOMING is nonzero and the address is to be found on the 31990 stack, return a `mem' which refers to the frame pointer. If 31991 INCOMING is `2', the result is being used to fetch the structure 31992 value address at the beginning of a function. If you need to emit 31993 adjusting code, you should do it at this point. 31994 31995 -- Macro: PCC_STATIC_STRUCT_RETURN 31996 Define this macro if the usual system convention on the target 31997 machine for returning structures and unions is for the called 31998 function to return the address of a static variable containing the 31999 value. 32000 32001 Do not define this if the usual system convention is for the 32002 caller to pass an address to the subroutine. 32003 32004 This macro has effect in `-fpcc-struct-return' mode, but it does 32005 nothing when you use `-freg-struct-return' mode. 32006 32007 -- Target Hook: machine_mode TARGET_GET_RAW_RESULT_MODE (int REGNO) 32008 This target hook returns the mode to be used when accessing raw 32009 return registers in `__builtin_return'. Define this macro if the 32010 value in REG_RAW_MODE is not correct. 32011 32012 -- Target Hook: machine_mode TARGET_GET_RAW_ARG_MODE (int REGNO) 32013 This target hook returns the mode to be used when accessing raw 32014 argument registers in `__builtin_apply_args'. Define this macro 32015 if the value in REG_RAW_MODE is not correct. 32016 32017 32018File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling 32019 3202017.9.10 Caller-Saves Register Allocation 32021---------------------------------------- 32022 32023If you enable it, GCC can save registers around function calls. This 32024makes it possible to use call-clobbered registers to hold variables that 32025must live across calls. 32026 32027 -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS) 32028 A C expression specifying which mode is required for saving NREGS 32029 of a pseudo-register in call-clobbered hard register REGNO. If 32030 REGNO is unsuitable for caller save, `VOIDmode' should be 32031 returned. For most machines this macro need not be defined since 32032 GCC will select the smallest suitable mode. 32033 32034 32035File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling 32036 3203717.9.11 Function Entry and Exit 32038------------------------------- 32039 32040This section describes the macros that output function entry 32041("prologue") and exit ("epilogue") code. 32042 32043 -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE, 32044 HOST_WIDE_INT SIZE) 32045 If defined, a function that outputs the assembler code for entry 32046 to a function. The prologue is responsible for setting up the 32047 stack frame, initializing the frame pointer register, saving 32048 registers that must be saved, and allocating SIZE additional bytes 32049 of storage for the local variables. SIZE is an integer. FILE is 32050 a stdio stream to which the assembler code should be output. 32051 32052 The label for the beginning of the function need not be output by 32053 this macro. That has already been done when the macro is run. 32054 32055 To determine which registers to save, the macro can refer to the 32056 array `regs_ever_live': element R is nonzero if hard register R is 32057 used anywhere within the function. This implies the function 32058 prologue should save register R, provided it is not one of the 32059 call-used registers. (`TARGET_ASM_FUNCTION_EPILOGUE' must 32060 likewise use `regs_ever_live'.) 32061 32062 On machines that have "register windows", the function entry code 32063 does not save on the stack the registers that are in the windows, 32064 even if they are supposed to be preserved by function calls; 32065 instead it takes appropriate steps to "push" the register stack, 32066 if any non-call-used registers are used in the function. 32067 32068 On machines where functions may or may not have frame-pointers, the 32069 function entry code must vary accordingly; it must set up the frame 32070 pointer if one is wanted, and not otherwise. To determine whether 32071 a frame pointer is in wanted, the macro can refer to the variable 32072 `frame_pointer_needed'. The variable's value will be 1 at run 32073 time in a function that needs a frame pointer. *Note 32074 Elimination::. 32075 32076 The function entry code is responsible for allocating any stack 32077 space required for the function. This stack space consists of the 32078 regions listed below. In most cases, these regions are allocated 32079 in the order listed, with the last listed region closest to the 32080 top of the stack (the lowest address if `STACK_GROWS_DOWNWARD' is 32081 defined, and the highest address if it is not defined). You can 32082 use a different order for a machine if doing so is more convenient 32083 or required for compatibility reasons. Except in cases where 32084 required by standard or by a debugger, there is no reason why the 32085 stack layout used by GCC need agree with that used by other 32086 compilers for a machine. 32087 32088 -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE) 32089 If defined, a function that outputs assembler code at the end of a 32090 prologue. This should be used when the function prologue is being 32091 emitted as RTL, and you have some extra assembler that needs to be 32092 emitted. *Note prologue instruction pattern::. 32093 32094 -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE) 32095 If defined, a function that outputs assembler code at the start of 32096 an epilogue. This should be used when the function epilogue is 32097 being emitted as RTL, and you have some extra assembler that needs 32098 to be emitted. *Note epilogue instruction pattern::. 32099 32100 -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE, 32101 HOST_WIDE_INT SIZE) 32102 If defined, a function that outputs the assembler code for exit 32103 from a function. The epilogue is responsible for restoring the 32104 saved registers and stack pointer to their values when the 32105 function was called, and returning control to the caller. This 32106 macro takes the same arguments as the macro 32107 `TARGET_ASM_FUNCTION_PROLOGUE', and the registers to restore are 32108 determined from `regs_ever_live' and `CALL_USED_REGISTERS' in the 32109 same way. 32110 32111 On some machines, there is a single instruction that does all the 32112 work of returning from the function. On these machines, give that 32113 instruction the name `return' and do not define the macro 32114 `TARGET_ASM_FUNCTION_EPILOGUE' at all. 32115 32116 Do not define a pattern named `return' if you want the 32117 `TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target 32118 switches to control whether return instructions or epilogues are 32119 used, define a `return' pattern with a validity condition that 32120 tests the target switches appropriately. If the `return' 32121 pattern's validity condition is false, epilogues will be used. 32122 32123 On machines where functions may or may not have frame-pointers, the 32124 function exit code must vary accordingly. Sometimes the code for 32125 these two cases is completely different. To determine whether a 32126 frame pointer is wanted, the macro can refer to the variable 32127 `frame_pointer_needed'. The variable's value will be 1 when 32128 compiling a function that needs a frame pointer. 32129 32130 Normally, `TARGET_ASM_FUNCTION_PROLOGUE' and 32131 `TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially. 32132 The C variable `current_function_is_leaf' is nonzero for such a 32133 function. *Note Leaf Functions::. 32134 32135 On some machines, some functions pop their arguments on exit while 32136 others leave that for the caller to do. For example, the 68020 32137 when given `-mrtd' pops arguments in functions that take a fixed 32138 number of arguments. 32139 32140 Your definition of the macro `RETURN_POPS_ARGS' decides which 32141 functions pop their own arguments. `TARGET_ASM_FUNCTION_EPILOGUE' 32142 needs to know what was decided. The number of bytes of the current 32143 function's arguments that this function should pop is available in 32144 `crtl->args.pops_args'. *Note Scalar Return::. 32145 32146 * A region of `crtl->args.pretend_args_size' bytes of uninitialized 32147 space just underneath the first argument arriving on the stack. 32148 (This may not be at the very start of the allocated stack region 32149 if the calling sequence has pushed anything else since pushing the 32150 stack arguments. But usually, on such machines, nothing else has 32151 been pushed yet, because the function prologue itself does all the 32152 pushing.) This region is used on machines where an argument may 32153 be passed partly in registers and partly in memory, and, in some 32154 cases to support the features in `<stdarg.h>'. 32155 32156 * An area of memory used to save certain registers used by the 32157 function. The size of this area, which may also include space for 32158 such things as the return address and pointers to previous stack 32159 frames, is machine-specific and usually depends on which registers 32160 have been used in the function. Machines with register windows 32161 often do not require a save area. 32162 32163 * A region of at least SIZE bytes, possibly rounded up to an 32164 allocation boundary, to contain the local variables of the 32165 function. On some machines, this region and the save area may 32166 occur in the opposite order, with the save area closer to the top 32167 of the stack. 32168 32169 * Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a region of 32170 `crtl->outgoing_args_size' bytes to be used for outgoing argument 32171 lists of the function. *Note Stack Arguments::. 32172 32173 -- Macro: EXIT_IGNORE_STACK 32174 Define this macro as a C expression that is nonzero if the return 32175 instruction or the function epilogue ignores the value of the stack 32176 pointer; in other words, if it is safe to delete an instruction to 32177 adjust the stack pointer before a return from the function. The 32178 default is 0. 32179 32180 Note that this macro's value is relevant only for functions for 32181 which frame pointers are maintained. It is never safe to delete a 32182 final stack adjustment in a function that has no frame pointer, 32183 and the compiler knows this regardless of `EXIT_IGNORE_STACK'. 32184 32185 -- Macro: EPILOGUE_USES (REGNO) 32186 Define this macro as a C expression that is nonzero for registers 32187 that are used by the epilogue or the `return' pattern. The stack 32188 and frame pointer registers are already assumed to be used as 32189 needed. 32190 32191 -- Macro: EH_USES (REGNO) 32192 Define this macro as a C expression that is nonzero for registers 32193 that are used by the exception handling mechanism, and so should 32194 be considered live on entry to an exception edge. 32195 32196 -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree 32197 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT 32198 VCALL_OFFSET, tree FUNCTION) 32199 A function that outputs the assembler code for a thunk function, 32200 used to implement C++ virtual function calls with multiple 32201 inheritance. The thunk acts as a wrapper around a virtual 32202 function, adjusting the implicit object parameter before handing 32203 control off to the real function. 32204 32205 First, emit code to add the integer DELTA to the location that 32206 contains the incoming first argument. Assume that this argument 32207 contains a pointer, and is the one used to pass the `this' pointer 32208 in C++. This is the incoming argument _before_ the function 32209 prologue, e.g. `%o0' on a sparc. The addition must preserve the 32210 values of all other incoming arguments. 32211 32212 Then, if VCALL_OFFSET is nonzero, an additional adjustment should 32213 be made after adding `delta'. In particular, if P is the adjusted 32214 pointer, the following adjustment should be made: 32215 32216 p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)] 32217 32218 After the additions, emit code to jump to FUNCTION, which is a 32219 `FUNCTION_DECL'. This is a direct pure jump, not a call, and does 32220 not touch the return address. Hence returning from FUNCTION will 32221 return to whoever called the current `thunk'. 32222 32223 The effect must be as if FUNCTION had been called directly with 32224 the adjusted first argument. This macro is responsible for 32225 emitting all of the code for a thunk function; 32226 `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' 32227 are not invoked. 32228 32229 The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already 32230 been extracted from it.) It might possibly be useful on some 32231 targets, but probably not. 32232 32233 If you do not define this macro, the target-independent code in 32234 the C++ front end will generate a less efficient heavyweight thunk 32235 that calls FUNCTION instead of jumping to it. The generic 32236 approach does not support varargs. 32237 32238 -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (const_tree 32239 THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT 32240 VCALL_OFFSET, const_tree FUNCTION) 32241 A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would 32242 be able to output the assembler code for the thunk function 32243 specified by the arguments it is passed, and false otherwise. In 32244 the latter case, the generic approach will be used by the C++ 32245 front end, with the limitations previously exposed. 32246 32247 32248File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling 32249 3225017.9.12 Generating Code for Profiling 32251------------------------------------- 32252 32253These macros will help you generate code for profiling. 32254 32255 -- Macro: FUNCTION_PROFILER (FILE, LABELNO) 32256 A C statement or compound statement to output to FILE some 32257 assembler code to call the profiling subroutine `mcount'. 32258 32259 The details of how `mcount' expects to be called are determined by 32260 your operating system environment, not by GCC. To figure them out, 32261 compile a small program for profiling using the system's installed 32262 C compiler and look at the assembler code that results. 32263 32264 Older implementations of `mcount' expect the address of a counter 32265 variable to be loaded into some register. The name of this 32266 variable is `LP' followed by the number LABELNO, so you would 32267 generate the name using `LP%d' in a `fprintf'. 32268 32269 -- Macro: PROFILE_HOOK 32270 A C statement or compound statement to output to FILE some assembly 32271 code to call the profiling subroutine `mcount' even the target does 32272 not support profiling. 32273 32274 -- Macro: NO_PROFILE_COUNTERS 32275 Define this macro to be an expression with a nonzero value if the 32276 `mcount' subroutine on your system does not need a counter variable 32277 allocated for each function. This is true for almost all modern 32278 implementations. If you define this macro, you must not use the 32279 LABELNO argument to `FUNCTION_PROFILER'. 32280 32281 -- Macro: PROFILE_BEFORE_PROLOGUE 32282 Define this macro if the code for function profiling should come 32283 before the function prologue. Normally, the profiling code comes 32284 after. 32285 32286 -- Target Hook: bool TARGET_KEEP_LEAF_WHEN_PROFILED (void) 32287 This target hook returns true if the target wants the leaf flag 32288 for the current function to stay true even if it calls mcount. 32289 This might make sense for targets using the leaf flag only to 32290 determine whether a stack frame needs to be generated or not and 32291 for which the call to mcount is generated before the function 32292 prologue. 32293 32294 32295File: gccint.info, Node: Tail Calls, Next: Stack Smashing Protection, Prev: Profiling, Up: Stack and Calling 32296 3229717.9.13 Permitting tail calls 32298----------------------------- 32299 32300 -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree 32301 EXP) 32302 True if it is OK to do sibling call optimization for the specified 32303 call expression EXP. DECL will be the called function, or `NULL' 32304 if this is an indirect call. 32305 32306 It is not uncommon for limitations of calling conventions to 32307 prevent tail calls to functions outside the current unit of 32308 translation, or during PIC compilation. The hook is used to 32309 enforce these restrictions, as the `sibcall' md pattern can not 32310 fail, or fall over to a "normal" call. The criteria for 32311 successful sibling call optimization may vary greatly between 32312 different architectures. 32313 32314 -- Target Hook: void TARGET_EXTRA_LIVE_ON_ENTRY (bitmap REGS) 32315 Add any hard registers to REGS that are live on entry to the 32316 function. This hook only needs to be defined to provide registers 32317 that cannot be found by examination of FUNCTION_ARG_REGNO_P, the 32318 callee saved registers, STATIC_CHAIN_INCOMING_REGNUM, 32319 STATIC_CHAIN_REGNUM, TARGET_STRUCT_VALUE_RTX, 32320 FRAME_POINTER_REGNUM, EH_USES, FRAME_POINTER_REGNUM, 32321 ARG_POINTER_REGNUM, and the PIC_OFFSET_TABLE_REGNUM. 32322 32323 -- Target Hook: void TARGET_SET_UP_BY_PROLOGUE (struct 32324 hard_reg_set_container *) 32325 This hook should add additional registers that are computed by the 32326 prologue to the hard regset for shrink-wrapping optimization 32327 purposes. 32328 32329 -- Target Hook: bool TARGET_WARN_FUNC_RETURN (tree) 32330 True if a function's return statements should be checked for 32331 matching the function's return type. This includes checking for 32332 falling off the end of a non-void function. Return false if no 32333 such check should be made. 32334 32335 32336File: gccint.info, Node: Stack Smashing Protection, Next: Miscellaneous Register Hooks, Prev: Tail Calls, Up: Stack and Calling 32337 3233817.9.14 Stack smashing protection 32339--------------------------------- 32340 32341 -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void) 32342 This hook returns a `DECL' node for the external variable to use 32343 for the stack protection guard. This variable is initialized by 32344 the runtime to some random value and is used to initialize the 32345 guard value that is placed at the top of the local stack frame. 32346 The type of this variable must be `ptr_type_node'. 32347 32348 The default version of this hook creates a variable called 32349 `__stack_chk_guard', which is normally defined in `libgcc2.c'. 32350 32351 -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void) 32352 This hook returns a `CALL_EXPR' that alerts the runtime that the 32353 stack protect guard variable has been modified. This expression 32354 should involve a call to a `noreturn' function. 32355 32356 The default version of this hook invokes a function called 32357 `__stack_chk_fail', taking no arguments. This function is 32358 normally defined in `libgcc2.c'. 32359 32360 -- Common Target Hook: bool TARGET_SUPPORTS_SPLIT_STACK (bool REPORT, 32361 struct gcc_options *OPTS) 32362 Whether this target supports splitting the stack when the options 32363 described in OPTS have been passed. This is called after options 32364 have been parsed, so the target may reject splitting the stack in 32365 some configurations. The default version of this hook returns 32366 false. If REPORT is true, this function may issue a warning or 32367 error; if REPORT is false, it must simply return a value 32368 32369 32370File: gccint.info, Node: Miscellaneous Register Hooks, Prev: Stack Smashing Protection, Up: Stack and Calling 32371 3237217.9.15 Miscellaneous register hooks 32373------------------------------------ 32374 32375 -- Target Hook: bool TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS 32376 Set to true if each call that binds to a local definition 32377 explicitly clobbers or sets all non-fixed registers modified by 32378 performing the call. That is, by the call pattern itself, or by 32379 code that might be inserted by the linker (e.g. stubs, veneers, 32380 branch islands), but not including those modifiable by the callee. 32381 The affected registers may be mentioned explicitly in the call 32382 pattern, or included as clobbers in CALL_INSN_FUNCTION_USAGE. The 32383 default version of this hook is set to false. The purpose of this 32384 hook is to enable the fipa-ra optimization. 32385 32386 32387File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros 32388 3238917.10 Implementing the Varargs Macros 32390===================================== 32391 32392GCC comes with an implementation of `<varargs.h>' and `<stdarg.h>' that 32393work without change on machines that pass arguments on the stack. 32394Other machines require their own implementations of varargs, and the 32395two machine independent header files must have conditionals to include 32396it. 32397 32398 ISO `<stdarg.h>' differs from traditional `<varargs.h>' mainly in the 32399calling convention for `va_start'. The traditional implementation 32400takes just one argument, which is the variable in which to store the 32401argument pointer. The ISO implementation of `va_start' takes an 32402additional second argument. The user is supposed to write the last 32403named argument of the function here. 32404 32405 However, `va_start' should not use this argument. The way to find the 32406end of the named arguments is with the built-in functions described 32407below. 32408 32409 -- Macro: __builtin_saveregs () 32410 Use this built-in function to save the argument registers in 32411 memory so that the varargs mechanism can access them. Both ISO 32412 and traditional versions of `va_start' must use 32413 `__builtin_saveregs', unless you use 32414 `TARGET_SETUP_INCOMING_VARARGS' (see below) instead. 32415 32416 On some machines, `__builtin_saveregs' is open-coded under the 32417 control of the target hook `TARGET_EXPAND_BUILTIN_SAVEREGS'. On 32418 other machines, it calls a routine written in assembler language, 32419 found in `libgcc2.c'. 32420 32421 Code generated for the call to `__builtin_saveregs' appears at the 32422 beginning of the function, as opposed to where the call to 32423 `__builtin_saveregs' is written, regardless of what the code is. 32424 This is because the registers must be saved before the function 32425 starts to use them for its own purposes. 32426 32427 -- Macro: __builtin_next_arg (LASTARG) 32428 This builtin returns the address of the first anonymous stack 32429 argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns 32430 the address of the location above the first anonymous stack 32431 argument. Use it in `va_start' to initialize the pointer for 32432 fetching arguments from the stack. Also use it in `va_start' to 32433 verify that the second parameter LASTARG is the last named argument 32434 of the current function. 32435 32436 -- Macro: __builtin_classify_type (OBJECT) 32437 Since each machine has its own conventions for which data types are 32438 passed in which kind of register, your implementation of `va_arg' 32439 has to embody these conventions. The easiest way to categorize the 32440 specified data type is to use `__builtin_classify_type' together 32441 with `sizeof' and `__alignof__'. 32442 32443 `__builtin_classify_type' ignores the value of OBJECT, considering 32444 only its data type. It returns an integer describing what kind of 32445 type that is--integer, floating, pointer, structure, and so on. 32446 32447 The file `typeclass.h' defines an enumeration that you can use to 32448 interpret the values of `__builtin_classify_type'. 32449 32450 These machine description macros help implement varargs: 32451 32452 -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void) 32453 If defined, this hook produces the machine-specific code for a 32454 call to `__builtin_saveregs'. This code will be moved to the very 32455 beginning of the function, before any parameter access are made. 32456 The return value of this function should be an RTX that contains 32457 the value to use as the return of `__builtin_saveregs'. 32458 32459 -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (cumulative_args_t 32460 ARGS_SO_FAR, machine_mode MODE, tree TYPE, int 32461 *PRETEND_ARGS_SIZE, int SECOND_TIME) 32462 This target hook offers an alternative to using 32463 `__builtin_saveregs' and defining the hook 32464 `TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous 32465 register arguments into the stack so that all the arguments appear 32466 to have been passed consecutively on the stack. Once this is 32467 done, you can use the standard implementation of varargs that 32468 works for machines that pass all their arguments on the stack. 32469 32470 The argument ARGS_SO_FAR points to the `CUMULATIVE_ARGS' data 32471 structure, containing the values that are obtained after 32472 processing the named arguments. The arguments MODE and TYPE 32473 describe the last named argument--its machine mode and its data 32474 type as a tree node. 32475 32476 The target hook should do two things: first, push onto the stack 32477 all the argument registers _not_ used for the named arguments, and 32478 second, store the size of the data thus pushed into the 32479 `int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value 32480 that you store here will serve as additional offset for setting up 32481 the stack frame. 32482 32483 Because you must generate code to push the anonymous arguments at 32484 compile time without knowing their data types, 32485 `TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that 32486 have just a single category of argument register and use it 32487 uniformly for all data types. 32488 32489 If the argument SECOND_TIME is nonzero, it means that the 32490 arguments of the function are being analyzed for the second time. 32491 This happens for an inline function, which is not actually 32492 compiled until the end of the source file. The hook 32493 `TARGET_SETUP_INCOMING_VARARGS' should not generate any 32494 instructions in this case. 32495 32496 -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (cumulative_args_t 32497 CA) 32498 Define this hook to return `true' if the location where a function 32499 argument is passed depends on whether or not it is a named 32500 argument. 32501 32502 This hook controls how the NAMED argument to `TARGET_FUNCTION_ARG' 32503 is set for varargs and stdarg functions. If this hook returns 32504 `true', the NAMED argument is always true for named arguments, and 32505 false for unnamed arguments. If it returns `false', but 32506 `TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns `true', then all 32507 arguments are treated as named. Otherwise, all named arguments 32508 except the last are treated as named. 32509 32510 You need not define this hook if it always returns `false'. 32511 32512 -- Target Hook: void TARGET_CALL_ARGS (rtx, TREE) 32513 While generating RTL for a function call, this target hook is 32514 invoked once for each argument passed to the function, either a 32515 register returned by `TARGET_FUNCTION_ARG' or a memory location. 32516 It is called just before the point where argument registers are 32517 stored. The type of the function to be called is also passed as 32518 the second argument; it is `NULL_TREE' for libcalls. The 32519 `TARGET_END_CALL_ARGS' hook is invoked just after the code to copy 32520 the return reg has been emitted. This functionality can be used 32521 to perform special setup of call argument registers if a target 32522 needs it. For functions without arguments, the hook is called 32523 once with `pc_rtx' passed instead of an argument register. Most 32524 ports do not need to implement anything for this hook. 32525 32526 -- Target Hook: void TARGET_END_CALL_ARGS (void) 32527 This target hook is invoked while generating RTL for a function 32528 call, just after the point where the return reg is copied into a 32529 pseudo. It signals that all the call argument and return 32530 registers for the just emitted call are now no longer in use. 32531 Most ports do not need to implement anything for this hook. 32532 32533 -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED 32534 (cumulative_args_t CA) 32535 If you need to conditionally change ABIs so that one works with 32536 `TARGET_SETUP_INCOMING_VARARGS', but the other works like neither 32537 `TARGET_SETUP_INCOMING_VARARGS' nor 32538 `TARGET_STRICT_ARGUMENT_NAMING' was defined, then define this hook 32539 to return `true' if `TARGET_SETUP_INCOMING_VARARGS' is used, 32540 `false' otherwise. Otherwise, you should not define this hook. 32541 32542 -- Target Hook: rtx TARGET_LOAD_BOUNDS_FOR_ARG (rtx SLOT, rtx ARG, rtx 32543 SLOT_NO) 32544 This hook is used by expand pass to emit insn to load bounds of 32545 ARG passed in SLOT. Expand pass uses this hook in case bounds of 32546 ARG are not passed in register. If SLOT is a memory, then bounds 32547 are loaded as for regular pointer loaded from memory. If SLOT is 32548 not a memory then SLOT_NO is an integer constant holding number of 32549 the target dependent special slot which should be used to obtain 32550 bounds. Hook returns RTX holding loaded bounds. 32551 32552 -- Target Hook: void TARGET_STORE_BOUNDS_FOR_ARG (rtx ARG, rtx SLOT, 32553 rtx BOUNDS, rtx SLOT_NO) 32554 This hook is used by expand pass to emit insns to store BOUNDS of 32555 ARG passed in SLOT. Expand pass uses this hook in case BOUNDS of 32556 ARG are not passed in register. If SLOT is a memory, then BOUNDS 32557 are stored as for regular pointer stored in memory. If SLOT is 32558 not a memory then SLOT_NO is an integer constant holding number of 32559 the target dependent special slot which should be used to store 32560 BOUNDS. 32561 32562 -- Target Hook: rtx TARGET_LOAD_RETURNED_BOUNDS (rtx SLOT) 32563 This hook is used by expand pass to emit insn to load bounds 32564 returned by function call in SLOT. Hook returns RTX holding 32565 loaded bounds. 32566 32567 -- Target Hook: void TARGET_STORE_RETURNED_BOUNDS (rtx SLOT, rtx 32568 BOUNDS) 32569 This hook is used by expand pass to emit insn to store BOUNDS 32570 returned by function call into SLOT. 32571 32572 -- Target Hook: rtx TARGET_CHKP_FUNCTION_VALUE_BOUNDS (const_tree 32573 RET_TYPE, const_tree FN_DECL_OR_TYPE, bool OUTGOING) 32574 Define this to return an RTX representing the place where a 32575 function returns bounds for returned pointers. Arguments meaning 32576 is similar to `TARGET_FUNCTION_VALUE'. 32577 32578 -- Target Hook: void TARGET_SETUP_INCOMING_VARARG_BOUNDS 32579 (cumulative_args_t ARGS_SO_FAR, enum machine_mode MODE, tree 32580 TYPE, int *PRETEND_ARGS_SIZE, int SECOND_TIME) 32581 Use it to store bounds for anonymous register arguments stored 32582 into the stack. Arguments meaning is similar to 32583 `TARGET_SETUP_INCOMING_VARARGS'. 32584 32585 32586File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros 32587 3258817.11 Trampolines for Nested Functions 32589====================================== 32590 32591A "trampoline" is a small piece of code that is created at run time 32592when the address of a nested function is taken. It normally resides on 32593the stack, in the stack frame of the containing function. These macros 32594tell GCC how to generate code to allocate and initialize a trampoline. 32595 32596 The instructions in the trampoline must do two things: load a constant 32597address into the static chain register, and jump to the real address of 32598the nested function. On CISC machines such as the m68k, this requires 32599two instructions, a move immediate and a jump. Then the two addresses 32600exist in the trampoline as word-long immediate operands. On RISC 32601machines, it is often necessary to load each address into a register in 32602two parts. Then pieces of each address form separate immediate 32603operands. 32604 32605 The code generated to initialize the trampoline must store the variable 32606parts--the static chain value and the function address--into the 32607immediate operands of the instructions. On a CISC machine, this is 32608simply a matter of copying each address to a memory reference at the 32609proper offset from the start of the trampoline. On a RISC machine, it 32610may be necessary to take out pieces of the address and store them 32611separately. 32612 32613 -- Target Hook: void TARGET_ASM_TRAMPOLINE_TEMPLATE (FILE *F) 32614 This hook is called by `assemble_trampoline_template' to output, 32615 on the stream F, assembler code for a block of data that contains 32616 the constant parts of a trampoline. This code should not include a 32617 label--the label is taken care of automatically. 32618 32619 If you do not define this hook, it means no template is needed for 32620 the target. Do not define this hook on systems where the block 32621 move code to copy the trampoline into place would be larger than 32622 the code to generate it on the spot. 32623 32624 -- Macro: TRAMPOLINE_SECTION 32625 Return the section into which the trampoline template is to be 32626 placed (*note Sections::). The default value is 32627 `readonly_data_section'. 32628 32629 -- Macro: TRAMPOLINE_SIZE 32630 A C expression for the size in bytes of the trampoline, as an 32631 integer. 32632 32633 -- Macro: TRAMPOLINE_ALIGNMENT 32634 Alignment required for trampolines, in bits. 32635 32636 If you don't define this macro, the value of `FUNCTION_ALIGNMENT' 32637 is used for aligning trampolines. 32638 32639 -- Target Hook: void TARGET_TRAMPOLINE_INIT (rtx M_TRAMP, tree FNDECL, 32640 rtx STATIC_CHAIN) 32641 This hook is called to initialize a trampoline. M_TRAMP is an RTX 32642 for the memory block for the trampoline; FNDECL is the 32643 `FUNCTION_DECL' for the nested function; STATIC_CHAIN is an RTX 32644 for the static chain value that should be passed to the function 32645 when it is called. 32646 32647 If the target defines `TARGET_ASM_TRAMPOLINE_TEMPLATE', then the 32648 first thing this hook should do is emit a block move into M_TRAMP 32649 from the memory block returned by `assemble_trampoline_template'. 32650 Note that the block move need only cover the constant parts of the 32651 trampoline. If the target isolates the variable parts of the 32652 trampoline to the end, not all `TRAMPOLINE_SIZE' bytes need be 32653 copied. 32654 32655 If the target requires any other actions, such as flushing caches 32656 or enabling stack execution, these actions should be performed 32657 after initializing the trampoline proper. 32658 32659 -- Target Hook: rtx TARGET_TRAMPOLINE_ADJUST_ADDRESS (rtx ADDR) 32660 This hook should perform any machine-specific adjustment in the 32661 address of the trampoline. Its argument contains the address of 32662 the memory block that was passed to `TARGET_TRAMPOLINE_INIT'. In 32663 case the address to be used for a function call should be 32664 different from the address at which the template was stored, the 32665 different address should be returned; otherwise ADDR should be 32666 returned unchanged. If this hook is not defined, ADDR will be 32667 used for function calls. 32668 32669 Implementing trampolines is difficult on many machines because they 32670have separate instruction and data caches. Writing into a stack 32671location fails to clear the memory in the instruction cache, so when 32672the program jumps to that location, it executes the old contents. 32673 32674 Here are two possible solutions. One is to clear the relevant parts of 32675the instruction cache whenever a trampoline is set up. The other is to 32676make all trampolines identical, by having them jump to a standard 32677subroutine. The former technique makes trampoline execution faster; the 32678latter makes initialization faster. 32679 32680 To clear the instruction cache when a trampoline is initialized, define 32681the following macro. 32682 32683 -- Macro: CLEAR_INSN_CACHE (BEG, END) 32684 If defined, expands to a C expression clearing the _instruction 32685 cache_ in the specified interval. The definition of this macro 32686 would typically be a series of `asm' statements. Both BEG and END 32687 are both pointer expressions. 32688 32689 To use a standard subroutine, define the following macro. In addition, 32690you must make sure that the instructions in a trampoline fill an entire 32691cache line with identical instructions, or else ensure that the 32692beginning of the trampoline code is always aligned at the same point in 32693its cache line. Look in `m68k.h' as a guide. 32694 32695 -- Macro: TRANSFER_FROM_TRAMPOLINE 32696 Define this macro if trampolines need a special subroutine to do 32697 their work. The macro should expand to a series of `asm' 32698 statements which will be compiled with GCC. They go in a library 32699 function named `__transfer_from_trampoline'. 32700 32701 If you need to avoid executing the ordinary prologue code of a 32702 compiled C function when you jump to the subroutine, you can do so 32703 by placing a special label of your own in the assembler code. Use 32704 one `asm' statement to generate an assembler label, and another to 32705 make the label global. Then trampolines can use that label to 32706 jump directly to your special assembler code. 32707 32708 32709File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros 32710 3271117.12 Implicit Calls to Library Routines 32712======================================== 32713 32714Here is an explanation of implicit calls to library routines. 32715 32716 -- Macro: DECLARE_LIBRARY_RENAMES 32717 This macro, if defined, should expand to a piece of C code that 32718 will get expanded when compiling functions for libgcc.a. It can 32719 be used to provide alternate names for GCC's internal library 32720 functions if there are ABI-mandated names that the compiler should 32721 provide. 32722 32723 -- Target Hook: void TARGET_INIT_LIBFUNCS (void) 32724 This hook should declare additional library routines or rename 32725 existing ones, using the functions `set_optab_libfunc' and 32726 `init_one_libfunc' defined in `optabs.c'. `init_optabs' calls 32727 this macro after initializing all the normal library routines. 32728 32729 The default is to do nothing. Most ports don't need to define 32730 this hook. 32731 32732 -- Target Hook: bool TARGET_LIBFUNC_GNU_PREFIX 32733 If false (the default), internal library routines start with two 32734 underscores. If set to true, these routines start with `__gnu_' 32735 instead. E.g., `__muldi3' changes to `__gnu_muldi3'. This 32736 currently only affects functions defined in `libgcc2.c'. If this 32737 is set to true, the `tm.h' file must also `#define 32738 LIBGCC2_GNU_PREFIX'. 32739 32740 -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON) 32741 This macro should return `true' if the library routine that 32742 implements the floating point comparison operator COMPARISON in 32743 mode MODE will return a boolean, and FALSE if it will return a 32744 tristate. 32745 32746 GCC's own floating point libraries return tristates from the 32747 comparison operators, so the default returns false always. Most 32748 ports don't need to define this macro. 32749 32750 -- Macro: TARGET_LIB_INT_CMP_BIASED 32751 This macro should evaluate to `true' if the integer comparison 32752 functions (like `__cmpdi2') return 0 to indicate that the first 32753 operand is smaller than the second, 1 to indicate that they are 32754 equal, and 2 to indicate that the first operand is greater than 32755 the second. If this macro evaluates to `false' the comparison 32756 functions return -1, 0, and 1 instead of 0, 1, and 2. If the 32757 target uses the routines in `libgcc.a', you do not need to define 32758 this macro. 32759 32760 -- Macro: TARGET_HAS_NO_HW_DIVIDE 32761 This macro should be defined if the target has no hardware divide 32762 instructions. If this macro is defined, GCC will use an algorithm 32763 which make use of simple logical and arithmetic operations for 32764 64-bit division. If the macro is not defined, GCC will use an 32765 algorithm which make use of a 64-bit by 32-bit divide primitive. 32766 32767 -- Macro: TARGET_EDOM 32768 The value of `EDOM' on the target machine, as a C integer constant 32769 expression. If you don't define this macro, GCC does not attempt 32770 to deposit the value of `EDOM' into `errno' directly. Look in 32771 `/usr/include/errno.h' to find the value of `EDOM' on your system. 32772 32773 If you do not define `TARGET_EDOM', then compiled code reports 32774 domain errors by calling the library function and letting it 32775 report the error. If mathematical functions on your system use 32776 `matherr' when there is an error, then you should leave 32777 `TARGET_EDOM' undefined so that `matherr' is used normally. 32778 32779 -- Macro: GEN_ERRNO_RTX 32780 Define this macro as a C expression to create an rtl expression 32781 that refers to the global "variable" `errno'. (On certain systems, 32782 `errno' may not actually be a variable.) If you don't define this 32783 macro, a reasonable default is used. 32784 32785 -- Target Hook: bool TARGET_LIBC_HAS_FUNCTION (enum function_class 32786 FN_CLASS) 32787 This hook determines whether a function from a class of functions 32788 FN_CLASS is present at the runtime. 32789 32790 -- Macro: NEXT_OBJC_RUNTIME 32791 Set this macro to 1 to use the "NeXT" Objective-C message sending 32792 conventions by default. This calling convention involves passing 32793 the object, the selector and the method arguments all at once to 32794 the method-lookup library function. This is the usual setting 32795 when targeting Darwin/Mac OS X systems, which have the NeXT 32796 runtime installed. 32797 32798 If the macro is set to 0, the "GNU" Objective-C message sending 32799 convention will be used by default. This convention passes just 32800 the object and the selector to the method-lookup function, which 32801 returns a pointer to the method. 32802 32803 In either case, it remains possible to select code-generation for 32804 the alternate scheme, by means of compiler command line switches. 32805 32806 32807File: gccint.info, Node: Addressing Modes, Next: Anchored Addresses, Prev: Library Calls, Up: Target Macros 32808 3280917.13 Addressing Modes 32810====================== 32811 32812This is about addressing modes. 32813 32814 -- Macro: HAVE_PRE_INCREMENT 32815 -- Macro: HAVE_PRE_DECREMENT 32816 -- Macro: HAVE_POST_INCREMENT 32817 -- Macro: HAVE_POST_DECREMENT 32818 A C expression that is nonzero if the machine supports 32819 pre-increment, pre-decrement, post-increment, or post-decrement 32820 addressing respectively. 32821 32822 -- Macro: HAVE_PRE_MODIFY_DISP 32823 -- Macro: HAVE_POST_MODIFY_DISP 32824 A C expression that is nonzero if the machine supports pre- or 32825 post-address side-effect generation involving constants other than 32826 the size of the memory operand. 32827 32828 -- Macro: HAVE_PRE_MODIFY_REG 32829 -- Macro: HAVE_POST_MODIFY_REG 32830 A C expression that is nonzero if the machine supports pre- or 32831 post-address side-effect generation involving a register 32832 displacement. 32833 32834 -- Macro: CONSTANT_ADDRESS_P (X) 32835 A C expression that is 1 if the RTX X is a constant which is a 32836 valid address. On most machines the default definition of 32837 `(CONSTANT_P (X) && GET_CODE (X) != CONST_DOUBLE)' is acceptable, 32838 but a few machines are more restrictive as to which constant 32839 addresses are supported. 32840 32841 -- Macro: CONSTANT_P (X) 32842 `CONSTANT_P', which is defined by target-independent code, accepts 32843 integer-values expressions whose values are not explicitly known, 32844 such as `symbol_ref', `label_ref', and `high' expressions and 32845 `const' arithmetic expressions, in addition to `const_int' and 32846 `const_double' expressions. 32847 32848 -- Macro: MAX_REGS_PER_ADDRESS 32849 A number, the maximum number of registers that can appear in a 32850 valid memory address. Note that it is up to you to specify a 32851 value equal to the maximum number that 32852 `TARGET_LEGITIMATE_ADDRESS_P' would ever accept. 32853 32854 -- Target Hook: bool TARGET_LEGITIMATE_ADDRESS_P (machine_mode MODE, 32855 rtx X, bool STRICT) 32856 A function that returns whether X (an RTX) is a legitimate memory 32857 address on the target machine for a memory operand of mode MODE. 32858 32859 Legitimate addresses are defined in two variants: a strict variant 32860 and a non-strict one. The STRICT parameter chooses which variant 32861 is desired by the caller. 32862 32863 The strict variant is used in the reload pass. It must be defined 32864 so that any pseudo-register that has not been allocated a hard 32865 register is considered a memory reference. This is because in 32866 contexts where some kind of register is required, a 32867 pseudo-register with no hard register must be rejected. For 32868 non-hard registers, the strict variant should look up the 32869 `reg_renumber' array; it should then proceed using the hard 32870 register number in the array, or treat the pseudo as a memory 32871 reference if the array holds `-1'. 32872 32873 The non-strict variant is used in other passes. It must be 32874 defined to accept all pseudo-registers in every context where some 32875 kind of register is required. 32876 32877 Normally, constant addresses which are the sum of a `symbol_ref' 32878 and an integer are stored inside a `const' RTX to mark them as 32879 constant. Therefore, there is no need to recognize such sums 32880 specifically as legitimate addresses. Normally you would simply 32881 recognize any `const' as legitimate. 32882 32883 Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant 32884 sums that are not marked with `const'. It assumes that a naked 32885 `plus' indicates indexing. If so, then you _must_ reject such 32886 naked constant sums as illegitimate addresses, so that none of 32887 them will be given to `PRINT_OPERAND_ADDRESS'. 32888 32889 On some machines, whether a symbolic address is legitimate depends 32890 on the section that the address refers to. On these machines, 32891 define the target hook `TARGET_ENCODE_SECTION_INFO' to store the 32892 information into the `symbol_ref', and then check for it here. 32893 When you see a `const', you will have to look inside it to find the 32894 `symbol_ref' in order to determine the section. *Note Assembler 32895 Format::. 32896 32897 Some ports are still using a deprecated legacy substitute for this 32898 hook, the `GO_IF_LEGITIMATE_ADDRESS' macro. This macro has this 32899 syntax: 32900 32901 #define GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL) 32902 32903 and should `goto LABEL' if the address X is a valid address on the 32904 target machine for a memory operand of mode MODE. 32905 32906 Compiler source files that want to use the strict variant of this 32907 macro define the macro `REG_OK_STRICT'. You should use an `#ifdef 32908 REG_OK_STRICT' conditional to define the strict variant in that 32909 case and the non-strict variant otherwise. 32910 32911 Using the hook is usually simpler because it limits the number of 32912 files that are recompiled when changes are made. 32913 32914 -- Macro: TARGET_MEM_CONSTRAINT 32915 A single character to be used instead of the default `'m'' 32916 character for general memory addresses. This defines the 32917 constraint letter which matches the memory addresses accepted by 32918 `TARGET_LEGITIMATE_ADDRESS_P'. Define this macro if you want to 32919 support new address formats in your back end without changing the 32920 semantics of the `'m'' constraint. This is necessary in order to 32921 preserve functionality of inline assembly constructs using the 32922 `'m'' constraint. 32923 32924 -- Macro: FIND_BASE_TERM (X) 32925 A C expression to determine the base term of address X, or to 32926 provide a simplified version of X from which `alias.c' can easily 32927 find the base term. This macro is used in only two places: 32928 `find_base_value' and `find_base_term' in `alias.c'. 32929 32930 It is always safe for this macro to not be defined. It exists so 32931 that alias analysis can understand machine-dependent addresses. 32932 32933 The typical use of this macro is to handle addresses containing a 32934 label_ref or symbol_ref within an UNSPEC. 32935 32936 -- Target Hook: rtx TARGET_LEGITIMIZE_ADDRESS (rtx X, rtx OLDX, 32937 machine_mode MODE) 32938 This hook is given an invalid memory address X for an operand of 32939 mode MODE and should try to return a valid memory address. 32940 32941 X will always be the result of a call to `break_out_memory_refs', 32942 and OLDX will be the operand that was given to that function to 32943 produce X. 32944 32945 The code of the hook should not alter the substructure of X. If 32946 it transforms X into a more legitimate form, it should return the 32947 new X. 32948 32949 It is not necessary for this hook to come up with a legitimate 32950 address, with the exception of native TLS addresses (*note 32951 Emulated TLS::). The compiler has standard ways of doing so in 32952 all cases. In fact, if the target supports only emulated TLS, it 32953 is safe to omit this hook or make it return X if it cannot find a 32954 valid way to legitimize the address. But often a machine-dependent 32955 strategy can generate better code. 32956 32957 -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, 32958 WIN) 32959 A C compound statement that attempts to replace X, which is an 32960 address that needs reloading, with a valid memory address for an 32961 operand of mode MODE. WIN will be a C statement label elsewhere 32962 in the code. It is not necessary to define this macro, but it 32963 might be useful for performance reasons. 32964 32965 For example, on the i386, it is sometimes possible to use a single 32966 reload register instead of two by reloading a sum of two pseudo 32967 registers into a register. On the other hand, for number of RISC 32968 processors offsets are limited so that often an intermediate 32969 address needs to be generated in order to address a stack slot. 32970 By defining `LEGITIMIZE_RELOAD_ADDRESS' appropriately, the 32971 intermediate addresses generated for adjacent some stack slots can 32972 be made identical, and thus be shared. 32973 32974 _Note_: This macro should be used with caution. It is necessary 32975 to know something of how reload works in order to effectively use 32976 this, and it is quite easy to produce macros that build in too 32977 much knowledge of reload internals. 32978 32979 _Note_: This macro must be able to reload an address created by a 32980 previous invocation of this macro. If it fails to handle such 32981 addresses then the compiler may generate incorrect code or abort. 32982 32983 The macro definition should use `push_reload' to indicate parts 32984 that need reloading; OPNUM, TYPE and IND_LEVELS are usually 32985 suitable to be passed unaltered to `push_reload'. 32986 32987 The code generated by this macro must not alter the substructure of 32988 X. If it transforms X into a more legitimate form, it should 32989 assign X (which will always be a C variable) a new value. This 32990 also applies to parts that you change indirectly by calling 32991 `push_reload'. 32992 32993 The macro definition may use `strict_memory_address_p' to test if 32994 the address has become legitimate. 32995 32996 If you want to change only a part of X, one standard way of doing 32997 this is to use `copy_rtx'. Note, however, that it unshares only a 32998 single level of rtl. Thus, if the part to be changed is not at the 32999 top level, you'll need to replace first the top level. It is not 33000 necessary for this macro to come up with a legitimate address; 33001 but often a machine-dependent strategy can generate better code. 33002 33003 -- Target Hook: bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx ADDR, 33004 addr_space_t ADDRSPACE) 33005 This hook returns `true' if memory address ADDR in address space 33006 ADDRSPACE can have different meanings depending on the machine 33007 mode of the memory reference it is used for or if the address is 33008 valid for some modes but not others. 33009 33010 Autoincrement and autodecrement addresses typically have 33011 mode-dependent effects because the amount of the increment or 33012 decrement is the size of the operand being addressed. Some 33013 machines have other mode-dependent addresses. Many RISC machines 33014 have no mode-dependent addresses. 33015 33016 You may assume that ADDR is a valid address for the machine. 33017 33018 The default version of this hook returns `false'. 33019 33020 -- Target Hook: bool TARGET_LEGITIMATE_CONSTANT_P (machine_mode MODE, 33021 rtx X) 33022 This hook returns true if X is a legitimate constant for a 33023 MODE-mode immediate operand on the target machine. You can assume 33024 that X satisfies `CONSTANT_P', so you need not check this. 33025 33026 The default definition returns true. 33027 33028 -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X) 33029 This hook is used to undo the possibly obfuscating effects of the 33030 `LEGITIMIZE_ADDRESS' and `LEGITIMIZE_RELOAD_ADDRESS' target 33031 macros. Some backend implementations of these macros wrap symbol 33032 references inside an `UNSPEC' rtx to represent PIC or similar 33033 addressing modes. This target hook allows GCC's optimizers to 33034 understand the semantics of these opaque `UNSPEC's by converting 33035 them back into their original form. 33036 33037 -- Target Hook: bool TARGET_CONST_NOT_OK_FOR_DEBUG_P (rtx X) 33038 This hook should return true if X should not be emitted into debug 33039 sections. 33040 33041 -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (machine_mode MODE, 33042 rtx X) 33043 This hook should return true if X is of a form that cannot (or 33044 should not) be spilled to the constant pool. MODE is the mode of 33045 X. 33046 33047 The default version of this hook returns false. 33048 33049 The primary reason to define this hook is to prevent reload from 33050 deciding that a non-legitimate constant would be better reloaded 33051 from the constant pool instead of spilling and reloading a register 33052 holding the constant. This restriction is often true of addresses 33053 of TLS symbols for various targets. 33054 33055 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (machine_mode 33056 MODE, const_rtx X) 33057 This hook should return true if pool entries for constant X can be 33058 placed in an `object_block' structure. MODE is the mode of X. 33059 33060 The default version returns false for all constants. 33061 33062 -- Target Hook: bool TARGET_USE_BLOCKS_FOR_DECL_P (const_tree DECL) 33063 This hook should return true if pool entries for DECL should be 33064 placed in an `object_block' structure. 33065 33066 The default version returns true for all decls. 33067 33068 -- Target Hook: tree TARGET_BUILTIN_RECIPROCAL (unsigned FN, bool 33069 MD_FN, bool SQRT) 33070 This hook should return the DECL of a function that implements 33071 reciprocal of the builtin function with builtin function code FN, 33072 or `NULL_TREE' if such a function is not available. MD_FN is true 33073 when FN is a code of a machine-dependent builtin function. When 33074 SQRT is true, additional optimizations that apply only to the 33075 reciprocal of a square root function are performed, and only 33076 reciprocals of `sqrt' function are valid. 33077 33078 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void) 33079 This hook should return the DECL of a function F that given an 33080 address ADDR as an argument returns a mask M that can be used to 33081 extract from two vectors the relevant data that resides in ADDR in 33082 case ADDR is not properly aligned. 33083 33084 The autovectorizer, when vectorizing a load operation from an 33085 address ADDR that may be unaligned, will generate two vector loads 33086 from the two aligned addresses around ADDR. It then generates a 33087 `REALIGN_LOAD' operation to extract the relevant data from the two 33088 loaded vectors. The first two arguments to `REALIGN_LOAD', V1 and 33089 V2, are the two vectors, each of size VS, and the third argument, 33090 OFF, defines how the data will be extracted from these two 33091 vectors: if OFF is 0, then the returned vector is V2; otherwise, 33092 the returned vector is composed from the last VS-OFF elements of 33093 V1 concatenated to the first OFF elements of V2. 33094 33095 If this hook is defined, the autovectorizer will generate a call 33096 to F (using the DECL tree that this hook returns) and will use the 33097 return value of F as the argument OFF to `REALIGN_LOAD'. 33098 Therefore, the mask M returned by F should comply with the 33099 semantics expected by `REALIGN_LOAD' described above. If this 33100 hook is not defined, then ADDR will be used as the argument OFF to 33101 `REALIGN_LOAD', in which case the low log2(VS) - 1 bits of ADDR 33102 will be considered. 33103 33104 -- Target Hook: int TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST (enum 33105 vect_cost_for_stmt TYPE_OF_COST, tree VECTYPE, int MISALIGN) 33106 Returns cost of different scalar or vector statements for 33107 vectorization cost model. For vector memory operations the cost 33108 may depend on type (VECTYPE) and misalignment value (MISALIGN). 33109 33110 -- Target Hook: bool TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE 33111 (const_tree TYPE, bool IS_PACKED) 33112 Return true if vector alignment is reachable (by peeling N 33113 iterations) for the given type. 33114 33115 -- Target Hook: bool TARGET_VECTORIZE_VEC_PERM_CONST_OK (machine_mode, 33116 const unsigned char *SEL) 33117 Return true if a vector created for `vec_perm_const' is valid. 33118 33119 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_CONVERSION (unsigned 33120 CODE, tree DEST_TYPE, tree SRC_TYPE) 33121 This hook should return the DECL of a function that implements 33122 conversion of the input vector of type SRC_TYPE to type DEST_TYPE. 33123 The value of CODE is one of the enumerators in `enum tree_code' and 33124 specifies how the conversion is to be applied (truncation, 33125 rounding, etc.). 33126 33127 If this hook is defined, the autovectorizer will use the 33128 `TARGET_VECTORIZE_BUILTIN_CONVERSION' target hook when vectorizing 33129 conversion. Otherwise, it will return `NULL_TREE'. 33130 33131 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION 33132 (tree FNDECL, tree VEC_TYPE_OUT, tree VEC_TYPE_IN) 33133 This hook should return the decl of a function that implements the 33134 vectorized variant of the builtin function with builtin function 33135 code CODE or `NULL_TREE' if such a function is not available. The 33136 value of FNDECL is the builtin function declaration. The return 33137 type of the vectorized function shall be of vector type 33138 VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN. 33139 33140 -- Target Hook: bool TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT 33141 (machine_mode MODE, const_tree TYPE, int MISALIGNMENT, bool 33142 IS_PACKED) 33143 This hook should return true if the target supports misaligned 33144 vector store/load of a specific factor denoted in the MISALIGNMENT 33145 parameter. The vector store/load should be of machine mode MODE 33146 and the elements in the vectors should be of type TYPE. IS_PACKED 33147 parameter is true if the memory access is defined in a packed 33148 struct. 33149 33150 -- Target Hook: machine_mode TARGET_VECTORIZE_PREFERRED_SIMD_MODE 33151 (machine_mode MODE) 33152 This hook should return the preferred mode for vectorizing scalar 33153 mode MODE. The default is equal to `word_mode', because the 33154 vectorizer can do some transformations even in absence of 33155 specialized SIMD hardware. 33156 33157 -- Target Hook: unsigned int 33158TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES (void) 33159 This hook should return a mask of sizes that should be iterated 33160 over after trying to autovectorize using the vector size derived 33161 from the mode returned by `TARGET_VECTORIZE_PREFERRED_SIMD_MODE'. 33162 The default is zero which means to not iterate over other vector 33163 sizes. 33164 33165 -- Target Hook: void * TARGET_VECTORIZE_INIT_COST (struct loop 33166 *LOOP_INFO) 33167 This hook should initialize target-specific data structures in 33168 preparation for modeling the costs of vectorizing a loop or basic 33169 block. The default allocates three unsigned integers for 33170 accumulating costs for the prologue, body, and epilogue of the 33171 loop or basic block. If LOOP_INFO is non-NULL, it identifies the 33172 loop being vectorized; otherwise a single block is being 33173 vectorized. 33174 33175 -- Target Hook: unsigned TARGET_VECTORIZE_ADD_STMT_COST (void *DATA, 33176 int COUNT, enum vect_cost_for_stmt KIND, struct 33177 _stmt_vec_info *STMT_INFO, int MISALIGN, enum 33178 vect_cost_model_location WHERE) 33179 This hook should update the target-specific DATA in response to 33180 adding COUNT copies of the given KIND of statement to a loop or 33181 basic block. The default adds the builtin vectorizer cost for the 33182 copies of the statement to the accumulator specified by WHERE, 33183 (the prologue, body, or epilogue) and returns the amount added. 33184 The return value should be viewed as a tentative cost that may 33185 later be revised. 33186 33187 -- Target Hook: void TARGET_VECTORIZE_FINISH_COST (void *DATA, 33188 unsigned *PROLOGUE_COST, unsigned *BODY_COST, unsigned 33189 *EPILOGUE_COST) 33190 This hook should complete calculations of the cost of vectorizing 33191 a loop or basic block based on DATA, and return the prologue, 33192 body, and epilogue costs as unsigned integers. The default 33193 returns the value of the three accumulators. 33194 33195 -- Target Hook: void TARGET_VECTORIZE_DESTROY_COST_DATA (void *DATA) 33196 This hook should release DATA and any related data structures 33197 allocated by TARGET_VECTORIZE_INIT_COST. The default releases the 33198 accumulator. 33199 33200 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_TM_LOAD (tree) 33201 This hook should return the built-in decl needed to load a vector 33202 of the given type within a transaction. 33203 33204 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_TM_STORE (tree) 33205 This hook should return the built-in decl needed to store a vector 33206 of the given type within a transaction. 33207 33208 -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_GATHER (const_tree 33209 MEM_VECTYPE, const_tree INDEX_TYPE, int SCALE) 33210 Target builtin that implements vector gather operation. 33211 MEM_VECTYPE is the vector type of the load and INDEX_TYPE is 33212 scalar type of the index, scaled by SCALE. The default is 33213 `NULL_TREE' which means to not vectorize gather loads. 33214 33215 -- Target Hook: int TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN 33216 (struct cgraph_node *, struct cgraph_simd_clone *, TREE, INT) 33217 This hook should set VECSIZE_MANGLE, VECSIZE_INT, VECSIZE_FLOAT 33218 fields in SIMD_CLONE structure pointed by CLONE_INFO argument and 33219 also SIMDLEN field if it was previously 0. The hook should return 33220 0 if SIMD clones shouldn't be emitted, or number of VECSIZE_MANGLE 33221 variants that should be emitted. 33222 33223 -- Target Hook: void TARGET_SIMD_CLONE_ADJUST (struct cgraph_node *) 33224 This hook should add implicit `attribute(target("..."))' attribute 33225 to SIMD clone NODE if needed. 33226 33227 -- Target Hook: int TARGET_SIMD_CLONE_USABLE (struct cgraph_node *) 33228 This hook should return -1 if SIMD clone NODE shouldn't be used in 33229 vectorized loops in current function, or non-negative number if it 33230 is usable. In that case, the smaller the number is, the more 33231 desirable it is to use it. 33232 33233 33234File: gccint.info, Node: Anchored Addresses, Next: Condition Code, Prev: Addressing Modes, Up: Target Macros 33235 3323617.14 Anchored Addresses 33237======================== 33238 33239GCC usually addresses every static object as a separate entity. For 33240example, if we have: 33241 33242 static int a, b, c; 33243 int foo (void) { return a + b + c; } 33244 33245 the code for `foo' will usually calculate three separate symbolic 33246addresses: those of `a', `b' and `c'. On some targets, it would be 33247better to calculate just one symbolic address and access the three 33248variables relative to it. The equivalent pseudocode would be something 33249like: 33250 33251 int foo (void) 33252 { 33253 register int *xr = &x; 33254 return xr[&a - &x] + xr[&b - &x] + xr[&c - &x]; 33255 } 33256 33257 (which isn't valid C). We refer to shared addresses like `x' as 33258"section anchors". Their use is controlled by `-fsection-anchors'. 33259 33260 The hooks below describe the target properties that GCC needs to know 33261in order to make effective use of section anchors. It won't use 33262section anchors at all unless either `TARGET_MIN_ANCHOR_OFFSET' or 33263`TARGET_MAX_ANCHOR_OFFSET' is set to a nonzero value. 33264 33265 -- Target Hook: HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET 33266 The minimum offset that should be applied to a section anchor. On 33267 most targets, it should be the smallest offset that can be applied 33268 to a base register while still giving a legitimate address for 33269 every mode. The default value is 0. 33270 33271 -- Target Hook: HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET 33272 Like `TARGET_MIN_ANCHOR_OFFSET', but the maximum (inclusive) 33273 offset that should be applied to section anchors. The default 33274 value is 0. 33275 33276 -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X) 33277 Write the assembly code to define section anchor X, which is a 33278 `SYMBOL_REF' for which `SYMBOL_REF_ANCHOR_P (X)' is true. The 33279 hook is called with the assembly output position set to the 33280 beginning of `SYMBOL_REF_BLOCK (X)'. 33281 33282 If `ASM_OUTPUT_DEF' is available, the hook's default definition 33283 uses it to define the symbol as `. + SYMBOL_REF_BLOCK_OFFSET (X)'. 33284 If `ASM_OUTPUT_DEF' is not available, the hook's default definition 33285 is `NULL', which disables the use of section anchors altogether. 33286 33287 -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (const_rtx X) 33288 Return true if GCC should attempt to use anchors to access 33289 `SYMBOL_REF' X. You can assume `SYMBOL_REF_HAS_BLOCK_INFO_P (X)' 33290 and `!SYMBOL_REF_ANCHOR_P (X)'. 33291 33292 The default version is correct for most targets, but you might 33293 need to intercept this hook to handle things like target-specific 33294 attributes or target-specific sections. 33295 33296 33297File: gccint.info, Node: Condition Code, Next: Costs, Prev: Anchored Addresses, Up: Target Macros 33298 3329917.15 Condition Code Status 33300=========================== 33301 33302The macros in this section can be split in two families, according to 33303the two ways of representing condition codes in GCC. 33304 33305 The first representation is the so called `(cc0)' representation 33306(*note Jump Patterns::), where all instructions can have an implicit 33307clobber of the condition codes. The second is the condition code 33308register representation, which provides better schedulability for 33309architectures that do have a condition code register, but on which most 33310instructions do not affect it. The latter category includes most RISC 33311machines. 33312 33313 The implicit clobbering poses a strong restriction on the placement of 33314the definition and use of the condition code. In the past the 33315definition and use were always adjacent. However, recent changes to 33316support trapping arithmatic may result in the definition and user being 33317in different blocks. Thus, there may be a `NOTE_INSN_BASIC_BLOCK' 33318between them. Additionally, the definition may be the source of 33319exception handling edges. 33320 33321 These restrictions can prevent important optimizations on some 33322machines. For example, on the IBM RS/6000, there is a delay for taken 33323branches unless the condition code register is set three instructions 33324earlier than the conditional branch. The instruction scheduler cannot 33325perform this optimization if it is not permitted to separate the 33326definition and use of the condition code register. 33327 33328 For this reason, it is possible and suggested to use a register to 33329represent the condition code for new ports. If there is a specific 33330condition code register in the machine, use a hard register. If the 33331condition code or comparison result can be placed in any general 33332register, or if there are multiple condition registers, use a pseudo 33333register. Registers used to store the condition code value will 33334usually have a mode that is in class `MODE_CC'. 33335 33336 Alternatively, you can use `BImode' if the comparison operator is 33337specified already in the compare instruction. In this case, you are not 33338interested in most macros in this section. 33339 33340* Menu: 33341 33342* CC0 Condition Codes:: Old style representation of condition codes. 33343* MODE_CC Condition Codes:: Modern representation of condition codes. 33344 33345 33346File: gccint.info, Node: CC0 Condition Codes, Next: MODE_CC Condition Codes, Up: Condition Code 33347 3334817.15.1 Representation of condition codes using `(cc0)' 33349------------------------------------------------------- 33350 33351The file `conditions.h' defines a variable `cc_status' to describe how 33352the condition code was computed (in case the interpretation of the 33353condition code depends on the instruction that it was set by). This 33354variable contains the RTL expressions on which the condition code is 33355currently based, and several standard flags. 33356 33357 Sometimes additional machine-specific flags must be defined in the 33358machine description header file. It can also add additional 33359machine-specific information by defining `CC_STATUS_MDEP'. 33360 33361 -- Macro: CC_STATUS_MDEP 33362 C code for a data type which is used for declaring the `mdep' 33363 component of `cc_status'. It defaults to `int'. 33364 33365 This macro is not used on machines that do not use `cc0'. 33366 33367 -- Macro: CC_STATUS_MDEP_INIT 33368 A C expression to initialize the `mdep' field to "empty". The 33369 default definition does nothing, since most machines don't use the 33370 field anyway. If you want to use the field, you should probably 33371 define this macro to initialize it. 33372 33373 This macro is not used on machines that do not use `cc0'. 33374 33375 -- Macro: NOTICE_UPDATE_CC (EXP, INSN) 33376 A C compound statement to set the components of `cc_status' 33377 appropriately for an insn INSN whose body is EXP. It is this 33378 macro's responsibility to recognize insns that set the condition 33379 code as a byproduct of other activity as well as those that 33380 explicitly set `(cc0)'. 33381 33382 This macro is not used on machines that do not use `cc0'. 33383 33384 If there are insns that do not set the condition code but do alter 33385 other machine registers, this macro must check to see whether they 33386 invalidate the expressions that the condition code is recorded as 33387 reflecting. For example, on the 68000, insns that store in address 33388 registers do not set the condition code, which means that usually 33389 `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns. 33390 But suppose that the previous insn set the condition code based on 33391 location `a4@(102)' and the current insn stores a new value in 33392 `a4'. Although the condition code is not changed by this, it will 33393 no longer be true that it reflects the contents of `a4@(102)'. 33394 Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case 33395 to say that nothing is known about the condition code value. 33396 33397 The definition of `NOTICE_UPDATE_CC' must be prepared to deal with 33398 the results of peephole optimization: insns whose patterns are 33399 `parallel' RTXs containing various `reg', `mem' or constants which 33400 are just the operands. The RTL structure of these insns is not 33401 sufficient to indicate what the insns actually do. What 33402 `NOTICE_UPDATE_CC' should do when it sees one is just to run 33403 `CC_STATUS_INIT'. 33404 33405 A possible definition of `NOTICE_UPDATE_CC' is to call a function 33406 that looks at an attribute (*note Insn Attributes::) named, for 33407 example, `cc'. This avoids having detailed information about 33408 patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'. 33409 33410 33411File: gccint.info, Node: MODE_CC Condition Codes, Prev: CC0 Condition Codes, Up: Condition Code 33412 3341317.15.2 Representation of condition codes using registers 33414--------------------------------------------------------- 33415 33416 -- Macro: SELECT_CC_MODE (OP, X, Y) 33417 On many machines, the condition code may be produced by other 33418 instructions than compares, for example the branch can use 33419 directly the condition code set by a subtract instruction. 33420 However, on some machines when the condition code is set this way 33421 some bits (such as the overflow bit) are not set in the same way 33422 as a test instruction, so that a different branch instruction must 33423 be used for some conditional branches. When this happens, use the 33424 machine mode of the condition code register to record different 33425 formats of the condition code register. Modes can also be used to 33426 record which compare instruction (e.g. a signed or an unsigned 33427 comparison) produced the condition codes. 33428 33429 If other modes than `CCmode' are required, add them to 33430 `MACHINE-modes.def' and define `SELECT_CC_MODE' to choose a mode 33431 given an operand of a compare. This is needed because the modes 33432 have to be chosen not only during RTL generation but also, for 33433 example, by instruction combination. The result of 33434 `SELECT_CC_MODE' should be consistent with the mode used in the 33435 patterns; for example to support the case of the add on the SPARC 33436 discussed above, we have the pattern 33437 33438 (define_insn "" 33439 [(set (reg:CC_NOOV 0) 33440 (compare:CC_NOOV 33441 (plus:SI (match_operand:SI 0 "register_operand" "%r") 33442 (match_operand:SI 1 "arith_operand" "rI")) 33443 (const_int 0)))] 33444 "" 33445 "...") 33446 33447 together with a `SELECT_CC_MODE' that returns `CC_NOOVmode' for 33448 comparisons whose argument is a `plus': 33449 33450 #define SELECT_CC_MODE(OP,X,Y) \ 33451 (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ 33452 ? ((OP == LT || OP == LE || OP == GT || OP == GE) \ 33453 ? CCFPEmode : CCFPmode) \ 33454 : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ 33455 || GET_CODE (X) == NEG || GET_CODE (x) == ASHIFT) \ 33456 ? CC_NOOVmode : CCmode)) 33457 33458 Another reason to use modes is to retain information on which 33459 operands were used by the comparison; see `REVERSIBLE_CC_MODE' 33460 later in this section. 33461 33462 You should define this macro if and only if you define extra CC 33463 modes in `MACHINE-modes.def'. 33464 33465 -- Target Hook: void TARGET_CANONICALIZE_COMPARISON (int *CODE, rtx 33466 *OP0, rtx *OP1, bool OP0_PRESERVE_VALUE) 33467 On some machines not all possible comparisons are defined, but you 33468 can convert an invalid comparison into a valid one. For example, 33469 the Alpha does not have a `GT' comparison, but you can use an `LT' 33470 comparison instead and swap the order of the operands. 33471 33472 On such machines, implement this hook to do any required 33473 conversions. CODE is the initial comparison code and OP0 and OP1 33474 are the left and right operands of the comparison, respectively. 33475 If OP0_PRESERVE_VALUE is `true' the implementation is not allowed 33476 to change the value of OP0 since the value might be used in RTXs 33477 which aren't comparisons. E.g. the implementation is not allowed 33478 to swap operands in that case. 33479 33480 GCC will not assume that the comparison resulting from this macro 33481 is valid but will see if the resulting insn matches a pattern in 33482 the `md' file. 33483 33484 You need not to implement this hook if it would never change the 33485 comparison code or operands. 33486 33487 -- Macro: REVERSIBLE_CC_MODE (MODE) 33488 A C expression whose value is one if it is always safe to reverse a 33489 comparison whose mode is MODE. If `SELECT_CC_MODE' can ever 33490 return MODE for a floating-point inequality comparison, then 33491 `REVERSIBLE_CC_MODE (MODE)' must be zero. 33492 33493 You need not define this macro if it would always returns zero or 33494 if the floating-point format is anything other than 33495 `IEEE_FLOAT_FORMAT'. For example, here is the definition used on 33496 the SPARC, where floating-point inequality comparisons are given 33497 either `CCFPEmode' or `CCFPmode': 33498 33499 #define REVERSIBLE_CC_MODE(MODE) \ 33500 ((MODE) != CCFPEmode && (MODE) != CCFPmode) 33501 33502 -- Macro: REVERSE_CONDITION (CODE, MODE) 33503 A C expression whose value is reversed condition code of the CODE 33504 for comparison done in CC_MODE MODE. The macro is used only in 33505 case `REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in 33506 case machine has some non-standard way how to reverse certain 33507 conditionals. For instance in case all floating point conditions 33508 are non-trapping, compiler may freely convert unordered compares 33509 to ordered ones. Then definition may look like: 33510 33511 #define REVERSE_CONDITION(CODE, MODE) \ 33512 ((MODE) != CCFPmode ? reverse_condition (CODE) \ 33513 : reverse_condition_maybe_unordered (CODE)) 33514 33515 -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int 33516 *P1, unsigned int *P2) 33517 On targets which do not use `(cc0)', and which use a hard register 33518 rather than a pseudo-register to hold condition codes, the regular 33519 CSE passes are often not able to identify cases in which the hard 33520 register is set to a common value. Use this hook to enable a 33521 small pass which optimizes such cases. This hook should return 33522 true to enable this pass, and it should set the integers to which 33523 its arguments point to the hard register numbers used for 33524 condition codes. When there is only one such register, as is true 33525 on most systems, the integer pointed to by P2 should be set to 33526 `INVALID_REGNUM'. 33527 33528 The default version of this hook returns false. 33529 33530 -- Target Hook: machine_mode TARGET_CC_MODES_COMPATIBLE (machine_mode 33531 M1, machine_mode M2) 33532 On targets which use multiple condition code modes in class 33533 `MODE_CC', it is sometimes the case that a comparison can be 33534 validly done in more than one mode. On such a system, define this 33535 target hook to take two mode arguments and to return a mode in 33536 which both comparisons may be validly done. If there is no such 33537 mode, return `VOIDmode'. 33538 33539 The default version of this hook checks whether the modes are the 33540 same. If they are, it returns that mode. If they are different, 33541 it returns `VOIDmode'. 33542 33543 -- Target Hook: unsigned int TARGET_FLAGS_REGNUM 33544 If the target has a dedicated flags register, and it needs to use 33545 the post-reload comparison elimination pass, then this value 33546 should be set appropriately. 33547 33548 33549File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros 33550 3355117.16 Describing Relative Costs of Operations 33552============================================= 33553 33554These macros let you describe the relative speed of various operations 33555on the target machine. 33556 33557 -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO) 33558 A C expression for the cost of moving data of mode MODE from a 33559 register in class FROM to one in class TO. The classes are 33560 expressed using the enumeration values such as `GENERAL_REGS'. A 33561 value of 2 is the default; other values are interpreted relative to 33562 that. 33563 33564 It is not required that the cost always equal 2 when FROM is the 33565 same as TO; on some machines it is expensive to move between 33566 registers if they are not general registers. 33567 33568 If reload sees an insn consisting of a single `set' between two 33569 hard registers, and if `REGISTER_MOVE_COST' applied to their 33570 classes returns a value of 2, reload does not check to ensure that 33571 the constraints of the insn are met. Setting a cost of other than 33572 2 will allow reload to verify that the constraints are met. You 33573 should do this if the `movM' pattern's constraints do not allow 33574 such copying. 33575 33576 These macros are obsolete, new ports should use the target hook 33577 `TARGET_REGISTER_MOVE_COST' instead. 33578 33579 -- Target Hook: int TARGET_REGISTER_MOVE_COST (machine_mode MODE, 33580 reg_class_t FROM, reg_class_t TO) 33581 This target hook should return the cost of moving data of mode MODE 33582 from a register in class FROM to one in class TO. The classes are 33583 expressed using the enumeration values such as `GENERAL_REGS'. A 33584 value of 2 is the default; other values are interpreted relative to 33585 that. 33586 33587 It is not required that the cost always equal 2 when FROM is the 33588 same as TO; on some machines it is expensive to move between 33589 registers if they are not general registers. 33590 33591 If reload sees an insn consisting of a single `set' between two 33592 hard registers, and if `TARGET_REGISTER_MOVE_COST' applied to their 33593 classes returns a value of 2, reload does not check to ensure that 33594 the constraints of the insn are met. Setting a cost of other than 33595 2 will allow reload to verify that the constraints are met. You 33596 should do this if the `movM' pattern's constraints do not allow 33597 such copying. 33598 33599 The default version of this function returns 2. 33600 33601 -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN) 33602 A C expression for the cost of moving data of mode MODE between a 33603 register of class CLASS and memory; IN is zero if the value is to 33604 be written to memory, nonzero if it is to be read in. This cost 33605 is relative to those in `REGISTER_MOVE_COST'. If moving between 33606 registers and memory is more expensive than between two registers, 33607 you should define this macro to express the relative cost. 33608 33609 If you do not define this macro, GCC uses a default cost of 4 plus 33610 the cost of copying via a secondary reload register, if one is 33611 needed. If your machine requires a secondary reload register to 33612 copy between memory and a register of CLASS but the reload 33613 mechanism is more complex than copying via an intermediate, define 33614 this macro to reflect the actual cost of the move. 33615 33616 GCC defines the function `memory_move_secondary_cost' if secondary 33617 reloads are needed. It computes the costs due to copying via a 33618 secondary register. If your machine copies from memory using a 33619 secondary register in the conventional way but the default base 33620 value of 4 is not correct for your machine, define this macro to 33621 add some other value to the result of that function. The 33622 arguments to that function are the same as to this macro. 33623 33624 These macros are obsolete, new ports should use the target hook 33625 `TARGET_MEMORY_MOVE_COST' instead. 33626 33627 -- Target Hook: int TARGET_MEMORY_MOVE_COST (machine_mode MODE, 33628 reg_class_t RCLASS, bool IN) 33629 This target hook should return the cost of moving data of mode MODE 33630 between a register of class RCLASS and memory; IN is `false' if 33631 the value is to be written to memory, `true' if it is to be read 33632 in. This cost is relative to those in `TARGET_REGISTER_MOVE_COST'. 33633 If moving between registers and memory is more expensive than 33634 between two registers, you should add this target hook to express 33635 the relative cost. 33636 33637 If you do not add this target hook, GCC uses a default cost of 4 33638 plus the cost of copying via a secondary reload register, if one is 33639 needed. If your machine requires a secondary reload register to 33640 copy between memory and a register of RCLASS but the reload 33641 mechanism is more complex than copying via an intermediate, use 33642 this target hook to reflect the actual cost of the move. 33643 33644 GCC defines the function `memory_move_secondary_cost' if secondary 33645 reloads are needed. It computes the costs due to copying via a 33646 secondary register. If your machine copies from memory using a 33647 secondary register in the conventional way but the default base 33648 value of 4 is not correct for your machine, use this target hook 33649 to add some other value to the result of that function. The 33650 arguments to that function are the same as to this target hook. 33651 33652 -- Macro: BRANCH_COST (SPEED_P, PREDICTABLE_P) 33653 A C expression for the cost of a branch instruction. A value of 1 33654 is the default; other values are interpreted relative to that. 33655 Parameter SPEED_P is true when the branch in question should be 33656 optimized for speed. When it is false, `BRANCH_COST' should 33657 return a value optimal for code size rather than performance. 33658 PREDICTABLE_P is true for well-predicted branches. On many 33659 architectures the `BRANCH_COST' can be reduced then. 33660 33661 Here are additional macros which do not specify precise relative costs, 33662but only that certain actions are more expensive than GCC would 33663ordinarily expect. 33664 33665 -- Macro: SLOW_BYTE_ACCESS 33666 Define this macro as a C expression which is nonzero if accessing 33667 less than a word of memory (i.e. a `char' or a `short') is no 33668 faster than accessing a word of memory, i.e., if such access 33669 require more than one instruction or if there is no difference in 33670 cost between byte and (aligned) word loads. 33671 33672 When this macro is not defined, the compiler will access a field by 33673 finding the smallest containing object; when it is defined, a 33674 fullword load will be used if alignment permits. Unless bytes 33675 accesses are faster than word accesses, using word accesses is 33676 preferable since it may eliminate subsequent memory access if 33677 subsequent accesses occur to other fields in the same word of the 33678 structure, but to different bytes. 33679 33680 -- Macro: SLOW_UNALIGNED_ACCESS (MODE, ALIGNMENT) 33681 Define this macro to be the value 1 if memory accesses described 33682 by the MODE and ALIGNMENT parameters have a cost many times greater 33683 than aligned accesses, for example if they are emulated in a trap 33684 handler. 33685 33686 When this macro is nonzero, the compiler will act as if 33687 `STRICT_ALIGNMENT' were nonzero when generating code for block 33688 moves. This can cause significantly more instructions to be 33689 produced. Therefore, do not set this macro nonzero if unaligned 33690 accesses only add a cycle or two to the time for a memory access. 33691 33692 If the value of this macro is always zero, it need not be defined. 33693 If this macro is defined, it should produce a nonzero value when 33694 `STRICT_ALIGNMENT' is nonzero. 33695 33696 -- Macro: MOVE_RATIO (SPEED) 33697 The threshold of number of scalar memory-to-memory move insns, 33698 _below_ which a sequence of insns should be generated instead of a 33699 string move insn or a library call. Increasing the value will 33700 always make code faster, but eventually incurs high cost in 33701 increased code size. 33702 33703 Note that on machines where the corresponding move insn is a 33704 `define_expand' that emits a sequence of insns, this macro counts 33705 the number of such sequences. 33706 33707 The parameter SPEED is true if the code is currently being 33708 optimized for speed rather than size. 33709 33710 If you don't define this, a reasonable default is used. 33711 33712 -- Target Hook: bool TARGET_USE_BY_PIECES_INFRASTRUCTURE_P (unsigned 33713 HOST_WIDE_INT SIZE, unsigned int ALIGNMENT, enum 33714 by_pieces_operation OP, bool SPEED_P) 33715 GCC will attempt several strategies when asked to copy between two 33716 areas of memory, or to set, clear or store to memory, for example 33717 when copying a `struct'. The `by_pieces' infrastructure implements 33718 such memory operations as a sequence of load, store or move insns. 33719 Alternate strategies are to expand the `movmem' or `setmem' 33720 optabs, to emit a library call, or to emit unit-by-unit, 33721 loop-based operations. 33722 33723 This target hook should return true if, for a memory operation 33724 with a given SIZE and ALIGNMENT, using the `by_pieces' 33725 infrastructure is expected to result in better code generation. 33726 Both SIZE and ALIGNMENT are measured in terms of storage units. 33727 33728 The parameter OP is one of: `CLEAR_BY_PIECES', `MOVE_BY_PIECES', 33729 `SET_BY_PIECES', `STORE_BY_PIECES'. These describe the type of 33730 memory operation under consideration. 33731 33732 The parameter SPEED_P is true if the code is currently being 33733 optimized for speed rather than size. 33734 33735 Returning true for higher values of SIZE can improve code 33736 generation for speed if the target does not provide an 33737 implementation of the `movmem' or `setmem' standard names, if the 33738 `movmem' or `setmem' implementation would be more expensive than a 33739 sequence of insns, or if the overhead of a library call would 33740 dominate that of the body of the memory operation. 33741 33742 Returning true for higher values of `size' may also cause an 33743 increase in code size, for example where the number of insns 33744 emitted to perform a move would be greater than that of a library 33745 call. 33746 33747 -- Macro: MOVE_MAX_PIECES 33748 A C expression used by `move_by_pieces' to determine the largest 33749 unit a load or store used to copy memory is. Defaults to 33750 `MOVE_MAX'. 33751 33752 -- Macro: CLEAR_RATIO (SPEED) 33753 The threshold of number of scalar move insns, _below_ which a 33754 sequence of insns should be generated to clear memory instead of a 33755 string clear insn or a library call. Increasing the value will 33756 always make code faster, but eventually incurs high cost in 33757 increased code size. 33758 33759 The parameter SPEED is true if the code is currently being 33760 optimized for speed rather than size. 33761 33762 If you don't define this, a reasonable default is used. 33763 33764 -- Macro: SET_RATIO (SPEED) 33765 The threshold of number of scalar move insns, _below_ which a 33766 sequence of insns should be generated to set memory to a constant 33767 value, instead of a block set insn or a library call. Increasing 33768 the value will always make code faster, but eventually incurs high 33769 cost in increased code size. 33770 33771 The parameter SPEED is true if the code is currently being 33772 optimized for speed rather than size. 33773 33774 If you don't define this, it defaults to the value of `MOVE_RATIO'. 33775 33776 -- Macro: USE_LOAD_POST_INCREMENT (MODE) 33777 A C expression used to determine whether a load postincrement is a 33778 good thing to use for a given mode. Defaults to the value of 33779 `HAVE_POST_INCREMENT'. 33780 33781 -- Macro: USE_LOAD_POST_DECREMENT (MODE) 33782 A C expression used to determine whether a load postdecrement is a 33783 good thing to use for a given mode. Defaults to the value of 33784 `HAVE_POST_DECREMENT'. 33785 33786 -- Macro: USE_LOAD_PRE_INCREMENT (MODE) 33787 A C expression used to determine whether a load preincrement is a 33788 good thing to use for a given mode. Defaults to the value of 33789 `HAVE_PRE_INCREMENT'. 33790 33791 -- Macro: USE_LOAD_PRE_DECREMENT (MODE) 33792 A C expression used to determine whether a load predecrement is a 33793 good thing to use for a given mode. Defaults to the value of 33794 `HAVE_PRE_DECREMENT'. 33795 33796 -- Macro: USE_STORE_POST_INCREMENT (MODE) 33797 A C expression used to determine whether a store postincrement is 33798 a good thing to use for a given mode. Defaults to the value of 33799 `HAVE_POST_INCREMENT'. 33800 33801 -- Macro: USE_STORE_POST_DECREMENT (MODE) 33802 A C expression used to determine whether a store postdecrement is 33803 a good thing to use for a given mode. Defaults to the value of 33804 `HAVE_POST_DECREMENT'. 33805 33806 -- Macro: USE_STORE_PRE_INCREMENT (MODE) 33807 This macro is used to determine whether a store preincrement is a 33808 good thing to use for a given mode. Defaults to the value of 33809 `HAVE_PRE_INCREMENT'. 33810 33811 -- Macro: USE_STORE_PRE_DECREMENT (MODE) 33812 This macro is used to determine whether a store predecrement is a 33813 good thing to use for a given mode. Defaults to the value of 33814 `HAVE_PRE_DECREMENT'. 33815 33816 -- Macro: NO_FUNCTION_CSE 33817 Define this macro if it is as good or better to call a constant 33818 function address than to call an address kept in a register. 33819 33820 -- Macro: LOGICAL_OP_NON_SHORT_CIRCUIT 33821 Define this macro if a non-short-circuit operation produced by 33822 `fold_range_test ()' is optimal. This macro defaults to true if 33823 `BRANCH_COST' is greater than or equal to the value 2. 33824 33825 -- Target Hook: bool TARGET_RTX_COSTS (rtx X, int CODE, int 33826 OUTER_CODE, int OPNO, int *TOTAL, bool SPEED) 33827 This target hook describes the relative costs of RTL expressions. 33828 33829 The cost may depend on the precise form of the expression, which is 33830 available for examination in X, and the fact that X appears as 33831 operand OPNO of an expression with rtx code OUTER_CODE. That is, 33832 the hook can assume that there is some rtx Y such that `GET_CODE 33833 (Y) == OUTER_CODE' and such that either (a) `XEXP (Y, OPNO) == X' 33834 or (b) `XVEC (Y, OPNO)' contains X. 33835 33836 CODE is X's expression code--redundant, since it can be obtained 33837 with `GET_CODE (X)'. 33838 33839 In implementing this hook, you can use the construct 33840 `COSTS_N_INSNS (N)' to specify a cost equal to N fast instructions. 33841 33842 On entry to the hook, `*TOTAL' contains a default estimate for the 33843 cost of the expression. The hook should modify this value as 33844 necessary. Traditionally, the default costs are `COSTS_N_INSNS 33845 (5)' for multiplications, `COSTS_N_INSNS (7)' for division and 33846 modulus operations, and `COSTS_N_INSNS (1)' for all other 33847 operations. 33848 33849 When optimizing for code size, i.e. when `speed' is false, this 33850 target hook should be used to estimate the relative size cost of 33851 an expression, again relative to `COSTS_N_INSNS'. 33852 33853 The hook returns true when all subexpressions of X have been 33854 processed, and false when `rtx_cost' should recurse. 33855 33856 -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS, machine_mode 33857 MODE, addr_space_t AS, bool SPEED) 33858 This hook computes the cost of an addressing mode that contains 33859 ADDRESS. If not defined, the cost is computed from the ADDRESS 33860 expression and the `TARGET_RTX_COST' hook. 33861 33862 For most CISC machines, the default cost is a good approximation 33863 of the true cost of the addressing mode. However, on RISC 33864 machines, all instructions normally have the same length and 33865 execution time. Hence all addresses will have equal costs. 33866 33867 In cases where more than one form of an address is known, the form 33868 with the lowest cost will be used. If multiple forms have the 33869 same, lowest, cost, the one that is the most complex will be used. 33870 33871 For example, suppose an address that is equal to the sum of a 33872 register and a constant is used twice in the same basic block. 33873 When this macro is not defined, the address will be computed in a 33874 register and memory references will be indirect through that 33875 register. On machines where the cost of the addressing mode 33876 containing the sum is no higher than that of a simple indirect 33877 reference, this will produce an additional instruction and 33878 possibly require an additional register. Proper specification of 33879 this macro eliminates this overhead for such machines. 33880 33881 This hook is never called with an invalid address. 33882 33883 On machines where an address involving more than one register is as 33884 cheap as an address computation involving only one register, 33885 defining `TARGET_ADDRESS_COST' to reflect this can cause two 33886 registers to be live over a region of code where only one would 33887 have been if `TARGET_ADDRESS_COST' were not defined in that 33888 manner. This effect should be considered in the definition of 33889 this macro. Equivalent costs should probably only be given to 33890 addresses with different numbers of registers on machines with 33891 lots of registers. 33892 33893 33894File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros 33895 3389617.17 Adjusting the Instruction Scheduler 33897========================================= 33898 33899The instruction scheduler may need a fair amount of machine-specific 33900adjustment in order to produce good code. GCC provides several target 33901hooks for this purpose. It is usually enough to define just a few of 33902them: try the first ones in this list first. 33903 33904 -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void) 33905 This hook returns the maximum number of instructions that can ever 33906 issue at the same time on the target machine. The default is one. 33907 Although the insn scheduler can define itself the possibility of 33908 issue an insn on the same cycle, the value can serve as an 33909 additional constraint to issue insns on the same simulated 33910 processor cycle (see hooks `TARGET_SCHED_REORDER' and 33911 `TARGET_SCHED_REORDER2'). This value must be constant over the 33912 entire compilation. If you need it to vary depending on what the 33913 instructions are, you must use `TARGET_SCHED_VARIABLE_ISSUE'. 33914 33915 -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int 33916 VERBOSE, rtx_insn *INSN, int MORE) 33917 This hook is executed by the scheduler after it has scheduled an 33918 insn from the ready list. It should return the number of insns 33919 which can still be issued in the current cycle. The default is 33920 `MORE - 1' for insns other than `CLOBBER' and `USE', which 33921 normally are not counted against the issue rate. You should 33922 define this hook if some insns take more machine resources than 33923 others, so that fewer insns can follow them in the same cycle. 33924 FILE is either a null pointer, or a stdio stream to write any 33925 debug output to. VERBOSE is the verbose level provided by 33926 `-fsched-verbose-N'. INSN is the instruction that was scheduled. 33927 33928 -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx_insn *INSN, rtx 33929 LINK, rtx_insn *DEP_INSN, int COST) 33930 This function corrects the value of COST based on the relationship 33931 between INSN and DEP_INSN through the dependence LINK. It should 33932 return the new value. The default is to make no adjustment to 33933 COST. This can be used for example to specify to the scheduler 33934 using the traditional pipeline description that an output- or 33935 anti-dependence does not incur the same cost as a data-dependence. 33936 If the scheduler using the automaton based pipeline description, 33937 the cost of anti-dependence is zero and the cost of 33938 output-dependence is maximum of one and the difference of latency 33939 times of the first and the second insns. If these values are not 33940 acceptable, you could use the hook to modify them too. See also 33941 *note Processor pipeline description::. 33942 33943 -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx_insn *INSN, int 33944 PRIORITY) 33945 This hook adjusts the integer scheduling priority PRIORITY of 33946 INSN. It should return the new priority. Increase the priority to 33947 execute INSN earlier, reduce the priority to execute INSN later. 33948 Do not define this hook if you do not need to adjust the 33949 scheduling priorities of insns. 33950 33951 -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, 33952 rtx_insn **READY, int *N_READYP, int CLOCK) 33953 This hook is executed by the scheduler after it has scheduled the 33954 ready list, to allow the machine description to reorder it (for 33955 example to combine two small instructions together on `VLIW' 33956 machines). FILE is either a null pointer, or a stdio stream to 33957 write any debug output to. VERBOSE is the verbose level provided 33958 by `-fsched-verbose-N'. READY is a pointer to the ready list of 33959 instructions that are ready to be scheduled. N_READYP is a 33960 pointer to the number of elements in the ready list. The scheduler 33961 reads the ready list in reverse order, starting with 33962 READY[*N_READYP - 1] and going to READY[0]. CLOCK is the timer 33963 tick of the scheduler. You may modify the ready list and the 33964 number of ready insns. The return value is the number of insns 33965 that can issue this cycle; normally this is just `issue_rate'. 33966 See also `TARGET_SCHED_REORDER2'. 33967 33968 -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE, 33969 rtx_insn **READY, int *N_READYP, int CLOCK) 33970 Like `TARGET_SCHED_REORDER', but called at a different time. That 33971 function is called whenever the scheduler starts a new cycle. 33972 This one is called once per iteration over a cycle, immediately 33973 after `TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list 33974 and return the number of insns to be scheduled in the same cycle. 33975 Defining this hook can be useful if there are frequent situations 33976 where scheduling one insn causes other insns to become ready in 33977 the same cycle. These other insns can then be taken into account 33978 properly. 33979 33980 -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_P (void) 33981 This hook is used to check whether target platform supports macro 33982 fusion. 33983 33984 -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_PAIR_P (rtx_insn *PREV, 33985 rtx_insn *CURR) 33986 This hook is used to check whether two insns should be macro fused 33987 for a target microarchitecture. If this hook returns true for the 33988 given insn pair (PREV and CURR), the scheduler will put them into 33989 a sched group, and they will not be scheduled apart. The two 33990 insns will be either two SET insns or a compare and a conditional 33991 jump and this hook should validate any dependencies needed to fuse 33992 the two insns together. 33993 33994 -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK 33995 (rtx_insn *HEAD, rtx_insn *TAIL) 33996 This hook is called after evaluation forward dependencies of insns 33997 in chain given by two parameter values (HEAD and TAIL 33998 correspondingly) but before insns scheduling of the insn chain. 33999 For example, it can be used for better insn classification if it 34000 requires analysis of dependencies. This hook can use backward and 34001 forward dependencies of the insn scheduler because they are already 34002 calculated. 34003 34004 -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int 34005 MAX_READY) 34006 This hook is executed by the scheduler at the beginning of each 34007 block of instructions that are to be scheduled. FILE is either a 34008 null pointer, or a stdio stream to write any debug output to. 34009 VERBOSE is the verbose level provided by `-fsched-verbose-N'. 34010 MAX_READY is the maximum number of insns in the current scheduling 34011 region that can be live at the same time. This can be used to 34012 allocate scratch space if it is needed, e.g. by 34013 `TARGET_SCHED_REORDER'. 34014 34015 -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE) 34016 This hook is executed by the scheduler at the end of each block of 34017 instructions that are to be scheduled. It can be used to perform 34018 cleanup of any actions done by the other scheduling hooks. FILE 34019 is either a null pointer, or a stdio stream to write any debug 34020 output to. VERBOSE is the verbose level provided by 34021 `-fsched-verbose-N'. 34022 34023 -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int 34024 VERBOSE, int OLD_MAX_UID) 34025 This hook is executed by the scheduler after function level 34026 initializations. FILE is either a null pointer, or a stdio stream 34027 to write any debug output to. VERBOSE is the verbose level 34028 provided by `-fsched-verbose-N'. OLD_MAX_UID is the maximum insn 34029 uid when scheduling begins. 34030 34031 -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int 34032 VERBOSE) 34033 This is the cleanup hook corresponding to 34034 `TARGET_SCHED_INIT_GLOBAL'. FILE is either a null pointer, or a 34035 stdio stream to write any debug output to. VERBOSE is the verbose 34036 level provided by `-fsched-verbose-N'. 34037 34038 -- Target Hook: rtx TARGET_SCHED_DFA_PRE_CYCLE_INSN (void) 34039 The hook returns an RTL insn. The automaton state used in the 34040 pipeline hazard recognizer is changed as if the insn were scheduled 34041 when the new simulated processor cycle starts. Usage of the hook 34042 may simplify the automaton pipeline description for some VLIW 34043 processors. If the hook is defined, it is used only for the 34044 automaton based pipeline description. The default is not to 34045 change the state when the new simulated processor cycle starts. 34046 34047 -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void) 34048 The hook can be used to initialize data used by the previous hook. 34049 34050 -- Target Hook: rtx_insn * TARGET_SCHED_DFA_POST_CYCLE_INSN (void) 34051 The hook is analogous to `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used 34052 to changed the state as if the insn were scheduled when the new 34053 simulated processor cycle finishes. 34054 34055 -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void) 34056 The hook is analogous to `TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but 34057 used to initialize data used by the previous hook. 34058 34059 -- Target Hook: void TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE (void) 34060 The hook to notify target that the current simulated cycle is 34061 about to finish. The hook is analogous to 34062 `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used to change the state in 34063 more complicated situations - e.g., when advancing state on a 34064 single insn is not enough. 34065 34066 -- Target Hook: void TARGET_SCHED_DFA_POST_ADVANCE_CYCLE (void) 34067 The hook to notify target that new simulated cycle has just 34068 started. The hook is analogous to 34069 `TARGET_SCHED_DFA_POST_CYCLE_INSN' but used to change the state in 34070 more complicated situations - e.g., when advancing state on a 34071 single insn is not enough. 34072 34073 -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 34074 (void) 34075 This hook controls better choosing an insn from the ready insn 34076 queue for the DFA-based insn scheduler. Usually the scheduler 34077 chooses the first insn from the queue. If the hook returns a 34078 positive value, an additional scheduler code tries all 34079 permutations of `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD 34080 ()' subsequent ready insns to choose an insn whose issue will 34081 result in maximal number of issued insns on the same cycle. For 34082 the VLIW processor, the code could actually solve the problem of 34083 packing simple insns into the VLIW insn. Of course, if the rules 34084 of VLIW packing are described in the automaton. 34085 34086 This code also could be used for superscalar RISC processors. Let 34087 us consider a superscalar RISC processor with 3 pipelines. Some 34088 insns can be executed in pipelines A or B, some insns can be 34089 executed only in pipelines B or C, and one insn can be executed in 34090 pipeline B. The processor may issue the 1st insn into A and the 34091 2nd one into B. In this case, the 3rd insn will wait for freeing B 34092 until the next cycle. If the scheduler issues the 3rd insn the 34093 first, the processor could issue all 3 insns per cycle. 34094 34095 Actually this code demonstrates advantages of the automaton based 34096 pipeline hazard recognizer. We try quickly and easy many insn 34097 schedules to choose the best one. 34098 34099 The default is no multipass scheduling. 34100 34101 -- Target Hook: int 34102TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD (rtx_insn *INSN, 34103 int READY_INDEX) 34104 This hook controls what insns from the ready insn queue will be 34105 considered for the multipass insn scheduling. If the hook returns 34106 zero for INSN, the insn will be considered in multipass scheduling. 34107 Positive return values will remove INSN from consideration on the 34108 current round of multipass scheduling. Negative return values 34109 will remove INSN from consideration for given number of cycles. 34110 Backends should be careful about returning non-zero for highest 34111 priority instruction at position 0 in the ready list. READY_INDEX 34112 is passed to allow backends make correct judgements. 34113 34114 The default is that any ready insns can be chosen to be issued. 34115 34116 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN (void 34117 *DATA, signed char *READY_TRY, int N_READY, bool 34118 FIRST_CYCLE_INSN_P) 34119 This hook prepares the target backend for a new round of multipass 34120 scheduling. 34121 34122 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE (void 34123 *DATA, signed char *READY_TRY, int N_READY, rtx_insn *INSN, 34124 const void *PREV_DATA) 34125 This hook is called when multipass scheduling evaluates 34126 instruction INSN. 34127 34128 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK 34129 (const void *DATA, signed char *READY_TRY, int N_READY) 34130 This is called when multipass scheduling backtracks from 34131 evaluation of an instruction. 34132 34133 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END (const 34134 void *DATA) 34135 This hook notifies the target about the result of the concluded 34136 current round of multipass scheduling. 34137 34138 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT (void 34139 *DATA) 34140 This hook initializes target-specific data used in multipass 34141 scheduling. 34142 34143 -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI (void 34144 *DATA) 34145 This hook finalizes target-specific data used in multipass 34146 scheduling. 34147 34148 -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *DUMP, int 34149 VERBOSE, rtx_insn *INSN, int LAST_CLOCK, int CLOCK, int 34150 *SORT_P) 34151 This hook is called by the insn scheduler before issuing INSN on 34152 cycle CLOCK. If the hook returns nonzero, INSN is not issued on 34153 this processor cycle. Instead, the processor cycle is advanced. 34154 If *SORT_P is zero, the insn ready queue is not sorted on the new 34155 cycle start as usually. DUMP and VERBOSE specify the file and 34156 verbosity level to use for debugging output. LAST_CLOCK and CLOCK 34157 are, respectively, the processor cycle on which the previous insn 34158 has been issued, and the current processor cycle. 34159 34160 -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (struct _dep 34161 *_DEP, int COST, int DISTANCE) 34162 This hook is used to define which dependences are considered 34163 costly by the target, so costly that it is not advisable to 34164 schedule the insns that are involved in the dependence too close 34165 to one another. The parameters to this hook are as follows: The 34166 first parameter _DEP is the dependence being evaluated. The 34167 second parameter COST is the cost of the dependence as estimated 34168 by the scheduler, and the third parameter DISTANCE is the distance 34169 in cycles between the two insns. The hook returns `true' if 34170 considering the distance between the two insns the dependence 34171 between them is considered costly by the target, and `false' 34172 otherwise. 34173 34174 Defining this hook can be useful in multiple-issue out-of-order 34175 machines, where (a) it's practically hopeless to predict the 34176 actual data/resource delays, however: (b) there's a better chance 34177 to predict the actual grouping that will be formed, and (c) 34178 correctly emulating the grouping can be very important. In such 34179 targets one may want to allow issuing dependent insns closer to 34180 one another--i.e., closer than the dependence distance; however, 34181 not in cases of "costly dependences", which this hooks allows to 34182 define. 34183 34184 -- Target Hook: void TARGET_SCHED_H_I_D_EXTENDED (void) 34185 This hook is called by the insn scheduler after emitting a new 34186 instruction to the instruction stream. The hook notifies a target 34187 backend to extend its per instruction data structures. 34188 34189 -- Target Hook: void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void) 34190 Return a pointer to a store large enough to hold target scheduling 34191 context. 34192 34193 -- Target Hook: void TARGET_SCHED_INIT_SCHED_CONTEXT (void *TC, bool 34194 CLEAN_P) 34195 Initialize store pointed to by TC to hold target scheduling 34196 context. It CLEAN_P is true then initialize TC as if scheduler is 34197 at the beginning of the block. Otherwise, copy the current 34198 context into TC. 34199 34200 -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC) 34201 Copy target scheduling context pointed to by TC to the current 34202 context. 34203 34204 -- Target Hook: void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *TC) 34205 Deallocate internal data in target scheduling context pointed to 34206 by TC. 34207 34208 -- Target Hook: void TARGET_SCHED_FREE_SCHED_CONTEXT (void *TC) 34209 Deallocate a store for target scheduling context pointed to by TC. 34210 34211 -- Target Hook: int TARGET_SCHED_SPECULATE_INSN (rtx_insn *INSN, 34212 unsigned int DEP_STATUS, rtx *NEW_PAT) 34213 This hook is called by the insn scheduler when INSN has only 34214 speculative dependencies and therefore can be scheduled 34215 speculatively. The hook is used to check if the pattern of INSN 34216 has a speculative version and, in case of successful check, to 34217 generate that speculative pattern. The hook should return 1, if 34218 the instruction has a speculative form, or -1, if it doesn't. 34219 REQUEST describes the type of requested speculation. If the 34220 return value equals 1 then NEW_PAT is assigned the generated 34221 speculative pattern. 34222 34223 -- Target Hook: bool TARGET_SCHED_NEEDS_BLOCK_P (unsigned int 34224 DEP_STATUS) 34225 This hook is called by the insn scheduler during generation of 34226 recovery code for INSN. It should return `true', if the 34227 corresponding check instruction should branch to recovery code, or 34228 `false' otherwise. 34229 34230 -- Target Hook: rtx TARGET_SCHED_GEN_SPEC_CHECK (rtx_insn *INSN, 34231 rtx_insn *LABEL, unsigned int DS) 34232 This hook is called by the insn scheduler to generate a pattern 34233 for recovery check instruction. If MUTATE_P is zero, then INSN is 34234 a speculative instruction for which the check should be generated. 34235 LABEL is either a label of a basic block, where recovery code 34236 should be emitted, or a null pointer, when requested check doesn't 34237 branch to recovery code (a simple check). If MUTATE_P is nonzero, 34238 then a pattern for a branchy check corresponding to a simple check 34239 denoted by INSN should be generated. In this case LABEL can't be 34240 null. 34241 34242 -- Target Hook: void TARGET_SCHED_SET_SCHED_FLAGS (struct 34243 spec_info_def *SPEC_INFO) 34244 This hook is used by the insn scheduler to find out what features 34245 should be enabled/used. The structure *SPEC_INFO should be filled 34246 in by the target. The structure describes speculation types that 34247 can be used in the scheduler. 34248 34249 -- Target Hook: int TARGET_SCHED_SMS_RES_MII (struct ddg *G) 34250 This hook is called by the swing modulo scheduler to calculate a 34251 resource-based lower bound which is based on the resources 34252 available in the machine and the resources required by each 34253 instruction. The target backend can use G to calculate such 34254 bound. A very simple lower bound will be used in case this hook 34255 is not implemented: the total number of instructions divided by 34256 the issue rate. 34257 34258 -- Target Hook: bool TARGET_SCHED_DISPATCH (rtx_insn *INSN, int X) 34259 This hook is called by Haifa Scheduler. It returns true if 34260 dispatch scheduling is supported in hardware and the condition 34261 specified in the parameter is true. 34262 34263 -- Target Hook: void TARGET_SCHED_DISPATCH_DO (rtx_insn *INSN, int X) 34264 This hook is called by Haifa Scheduler. It performs the operation 34265 specified in its second parameter. 34266 34267 -- Target Hook: bool TARGET_SCHED_EXPOSED_PIPELINE 34268 True if the processor has an exposed pipeline, which means that 34269 not just the order of instructions is important for correctness 34270 when scheduling, but also the latencies of operations. 34271 34272 -- Target Hook: int TARGET_SCHED_REASSOCIATION_WIDTH (unsigned int 34273 OPC, machine_mode MODE) 34274 This hook is called by tree reassociator to determine a level of 34275 parallelism required in output calculations chain. 34276 34277 -- Target Hook: void TARGET_SCHED_FUSION_PRIORITY (rtx_insn *INSN, int 34278 MAX_PRI, int *FUSION_PRI, int *PRI) 34279 This hook is called by scheduling fusion pass. It calculates 34280 fusion priorities for each instruction passed in by parameter. 34281 The priorities are returned via pointer parameters. 34282 34283 INSN is the instruction whose priorities need to be calculated. 34284 MAX_PRI is the maximum priority can be returned in any cases. 34285 FUSION_PRI is the pointer parameter through which INSN's fusion 34286 priority should be calculated and returned. PRI is the pointer 34287 parameter through which INSN's priority should be calculated and 34288 returned. 34289 34290 Same FUSION_PRI should be returned for instructions which should 34291 be scheduled together. Different PRI should be returned for 34292 instructions with same FUSION_PRI. FUSION_PRI is the major sort 34293 key, PRI is the minor sort key. All instructions will be 34294 scheduled according to the two priorities. All priorities 34295 calculated should be between 0 (exclusive) and MAX_PRI 34296 (inclusive). To avoid false dependencies, FUSION_PRI of 34297 instructions which need to be scheduled together should be smaller 34298 than FUSION_PRI of irrelevant instructions. 34299 34300 Given below example: 34301 34302 ldr r10, [r1, 4] 34303 add r4, r4, r10 34304 ldr r15, [r2, 8] 34305 sub r5, r5, r15 34306 ldr r11, [r1, 0] 34307 add r4, r4, r11 34308 ldr r16, [r2, 12] 34309 sub r5, r5, r16 34310 34311 On targets like ARM/AArch64, the two pairs of consecutive loads 34312 should be merged. Since peephole2 pass can't help in this case 34313 unless consecutive loads are actually next to each other in 34314 instruction flow. That's where this scheduling fusion pass works. 34315 This hook calculates priority for each instruction based on its 34316 fustion type, like: 34317 34318 ldr r10, [r1, 4] ; fusion_pri=99, pri=96 34319 add r4, r4, r10 ; fusion_pri=100, pri=100 34320 ldr r15, [r2, 8] ; fusion_pri=98, pri=92 34321 sub r5, r5, r15 ; fusion_pri=100, pri=100 34322 ldr r11, [r1, 0] ; fusion_pri=99, pri=100 34323 add r4, r4, r11 ; fusion_pri=100, pri=100 34324 ldr r16, [r2, 12] ; fusion_pri=98, pri=88 34325 sub r5, r5, r16 ; fusion_pri=100, pri=100 34326 34327 Scheduling fusion pass then sorts all ready to issue instructions 34328 according to the priorities. As a result, instructions of same 34329 fusion type will be pushed together in instruction flow, like: 34330 34331 ldr r11, [r1, 0] 34332 ldr r10, [r1, 4] 34333 ldr r15, [r2, 8] 34334 ldr r16, [r2, 12] 34335 add r4, r4, r10 34336 sub r5, r5, r15 34337 add r4, r4, r11 34338 sub r5, r5, r16 34339 34340 Now peephole2 pass can simply merge the two pairs of loads. 34341 34342 Since scheduling fusion pass relies on peephole2 to do real fusion 34343 work, it is only enabled by default when peephole2 is in effect. 34344 34345 This is firstly introduced on ARM/AArch64 targets, please refer to 34346 the hook implementation for how different fusion types are 34347 supported. 34348 34349 34350File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros 34351 3435217.18 Dividing the Output into Sections (Texts, Data, ...) 34353========================================================== 34354 34355An object file is divided into sections containing different types of 34356data. In the most common case, there are three sections: the "text 34357section", which holds instructions and read-only data; the "data 34358section", which holds initialized writable data; and the "bss section", 34359which holds uninitialized data. Some systems have other kinds of 34360sections. 34361 34362 `varasm.c' provides several well-known sections, such as 34363`text_section', `data_section' and `bss_section'. The normal way of 34364controlling a `FOO_section' variable is to define the associated 34365`FOO_SECTION_ASM_OP' macro, as described below. The macros are only 34366read once, when `varasm.c' initializes itself, so their values must be 34367run-time constants. They may however depend on command-line flags. 34368 34369 _Note:_ Some run-time files, such `crtstuff.c', also make use of the 34370`FOO_SECTION_ASM_OP' macros, and expect them to be string literals. 34371 34372 Some assemblers require a different string to be written every time a 34373section is selected. If your assembler falls into this category, you 34374should define the `TARGET_ASM_INIT_SECTIONS' hook and use 34375`get_unnamed_section' to set up the sections. 34376 34377 You must always create a `text_section', either by defining 34378`TEXT_SECTION_ASM_OP' or by initializing `text_section' in 34379`TARGET_ASM_INIT_SECTIONS'. The same is true of `data_section' and 34380`DATA_SECTION_ASM_OP'. If you do not create a distinct 34381`readonly_data_section', the default is to reuse `text_section'. 34382 34383 All the other `varasm.c' sections are optional, and are null if the 34384target does not provide them. 34385 34386 -- Macro: TEXT_SECTION_ASM_OP 34387 A C expression whose value is a string, including spacing, 34388 containing the assembler operation that should precede 34389 instructions and read-only data. Normally `"\t.text"' is right. 34390 34391 -- Macro: HOT_TEXT_SECTION_NAME 34392 If defined, a C string constant for the name of the section 34393 containing most frequently executed functions of the program. If 34394 not defined, GCC will provide a default definition if the target 34395 supports named sections. 34396 34397 -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME 34398 If defined, a C string constant for the name of the section 34399 containing unlikely executed functions in the program. 34400 34401 -- Macro: DATA_SECTION_ASM_OP 34402 A C expression whose value is a string, including spacing, 34403 containing the assembler operation to identify the following data 34404 as writable initialized data. Normally `"\t.data"' is right. 34405 34406 -- Macro: SDATA_SECTION_ASM_OP 34407 If defined, a C expression whose value is a string, including 34408 spacing, containing the assembler operation to identify the 34409 following data as initialized, writable small data. 34410 34411 -- Macro: READONLY_DATA_SECTION_ASM_OP 34412 A C expression whose value is a string, including spacing, 34413 containing the assembler operation to identify the following data 34414 as read-only initialized data. 34415 34416 -- Macro: BSS_SECTION_ASM_OP 34417 If defined, a C expression whose value is a string, including 34418 spacing, containing the assembler operation to identify the 34419 following data as uninitialized global data. If not defined, and 34420 `ASM_OUTPUT_ALIGNED_BSS' not defined, uninitialized global data 34421 will be output in the data section if `-fno-common' is passed, 34422 otherwise `ASM_OUTPUT_COMMON' will be used. 34423 34424 -- Macro: SBSS_SECTION_ASM_OP 34425 If defined, a C expression whose value is a string, including 34426 spacing, containing the assembler operation to identify the 34427 following data as uninitialized, writable small data. 34428 34429 -- Macro: TLS_COMMON_ASM_OP 34430 If defined, a C expression whose value is a string containing the 34431 assembler operation to identify the following data as thread-local 34432 common data. The default is `".tls_common"'. 34433 34434 -- Macro: TLS_SECTION_ASM_FLAG 34435 If defined, a C expression whose value is a character constant 34436 containing the flag used to mark a section as a TLS section. The 34437 default is `'T''. 34438 34439 -- Macro: INIT_SECTION_ASM_OP 34440 If defined, a C expression whose value is a string, including 34441 spacing, containing the assembler operation to identify the 34442 following data as initialization code. If not defined, GCC will 34443 assume such a section does not exist. This section has no 34444 corresponding `init_section' variable; it is used entirely in 34445 runtime code. 34446 34447 -- Macro: FINI_SECTION_ASM_OP 34448 If defined, a C expression whose value is a string, including 34449 spacing, containing the assembler operation to identify the 34450 following data as finalization code. If not defined, GCC will 34451 assume such a section does not exist. This section has no 34452 corresponding `fini_section' variable; it is used entirely in 34453 runtime code. 34454 34455 -- Macro: INIT_ARRAY_SECTION_ASM_OP 34456 If defined, a C expression whose value is a string, including 34457 spacing, containing the assembler operation to identify the 34458 following data as part of the `.init_array' (or equivalent) 34459 section. If not defined, GCC will assume such a section does not 34460 exist. Do not define both this macro and `INIT_SECTION_ASM_OP'. 34461 34462 -- Macro: FINI_ARRAY_SECTION_ASM_OP 34463 If defined, a C expression whose value is a string, including 34464 spacing, containing the assembler operation to identify the 34465 following data as part of the `.fini_array' (or equivalent) 34466 section. If not defined, GCC will assume such a section does not 34467 exist. Do not define both this macro and `FINI_SECTION_ASM_OP'. 34468 34469 -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION) 34470 If defined, an ASM statement that switches to a different section 34471 via SECTION_OP, calls FUNCTION, and switches back to the text 34472 section. This is used in `crtstuff.c' if `INIT_SECTION_ASM_OP' or 34473 `FINI_SECTION_ASM_OP' to calls to initialization and finalization 34474 functions from the init and fini sections. By default, this macro 34475 uses a simple function call. Some ports need hand-crafted 34476 assembly code to avoid dependencies on registers initialized in 34477 the function prologue or to ensure that constant pools don't end 34478 up too far way in the text section. 34479 34480 -- Macro: TARGET_LIBGCC_SDATA_SECTION 34481 If defined, a string which names the section into which small 34482 variables defined in crtstuff and libgcc should go. This is useful 34483 when the target has options for optimizing access to small data, 34484 and you want the crtstuff and libgcc routines to be conservative 34485 in what they expect of your application yet liberal in what your 34486 application expects. For example, for targets with a `.sdata' 34487 section (like MIPS), you could compile crtstuff with `-G 0' so 34488 that it doesn't require small data support from your application, 34489 but use this macro to put small data into `.sdata' so that your 34490 application can access these variables whether it uses small data 34491 or not. 34492 34493 -- Macro: FORCE_CODE_SECTION_ALIGN 34494 If defined, an ASM statement that aligns a code section to some 34495 arbitrary boundary. This is used to force all fragments of the 34496 `.init' and `.fini' sections to have to same alignment and thus 34497 prevent the linker from having to add any padding. 34498 34499 -- Macro: JUMP_TABLES_IN_TEXT_SECTION 34500 Define this macro to be an expression with a nonzero value if jump 34501 tables (for `tablejump' insns) should be output in the text 34502 section, along with the assembler instructions. Otherwise, the 34503 readonly data section is used. 34504 34505 This macro is irrelevant if there is no separate readonly data 34506 section. 34507 34508 -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void) 34509 Define this hook if you need to do something special to set up the 34510 `varasm.c' sections, or if your target has some special sections 34511 of its own that you need to create. 34512 34513 GCC calls this hook after processing the command line, but before 34514 writing any assembly code, and before calling any of the 34515 section-returning hooks described below. 34516 34517 -- Target Hook: int TARGET_ASM_RELOC_RW_MASK (void) 34518 Return a mask describing how relocations should be treated when 34519 selecting sections. Bit 1 should be set if global relocations 34520 should be placed in a read-write section; bit 0 should be set if 34521 local relocations should be placed in a read-write section. 34522 34523 The default version of this function returns 3 when `-fpic' is in 34524 effect, and 0 otherwise. The hook is typically redefined when the 34525 target cannot support (some kinds of) dynamic relocations in 34526 read-only sections even in executables. 34527 34528 -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int 34529 RELOC, unsigned HOST_WIDE_INT ALIGN) 34530 Return the section into which EXP should be placed. You can 34531 assume that EXP is either a `VAR_DECL' node or a constant of some 34532 sort. RELOC indicates whether the initial value of EXP requires 34533 link-time relocations. Bit 0 is set when variable contains local 34534 relocations only, while bit 1 is set for global relocations. 34535 ALIGN is the constant alignment in bits. 34536 34537 The default version of this function takes care of putting 34538 read-only variables in `readonly_data_section'. 34539 34540 See also USE_SELECT_SECTION_FOR_FUNCTIONS. 34541 34542 -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS 34543 Define this macro if you wish TARGET_ASM_SELECT_SECTION to be 34544 called for `FUNCTION_DECL's as well as for variables and constants. 34545 34546 In the case of a `FUNCTION_DECL', RELOC will be zero if the 34547 function has been determined to be likely to be called, and 34548 nonzero if it is unlikely to be called. 34549 34550 -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC) 34551 Build up a unique section name, expressed as a `STRING_CST' node, 34552 and assign it to `DECL_SECTION_NAME (DECL)'. As with 34553 `TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial 34554 value of EXP requires link-time relocations. 34555 34556 The default version of this function appends the symbol name to the 34557 ELF section name that would normally be used for the symbol. For 34558 example, the function `foo' would be placed in `.text.foo'. 34559 Whatever the actual target object format, this is often good 34560 enough. 34561 34562 -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree 34563 DECL) 34564 Return the readonly data section associated with 34565 `DECL_SECTION_NAME (DECL)'. The default version of this function 34566 selects `.gnu.linkonce.r.name' if the function's section is 34567 `.gnu.linkonce.t.name', `.rodata.name' if function is in 34568 `.text.name', and the normal readonly-data section otherwise. 34569 34570 -- Target Hook: const char * TARGET_ASM_MERGEABLE_RODATA_PREFIX 34571 Usually, the compiler uses the prefix `".rodata"' to construct 34572 section names for mergeable constant data. Define this macro to 34573 override the string if a different section name should be used. 34574 34575 -- Target Hook: section * TARGET_ASM_TM_CLONE_TABLE_SECTION (void) 34576 Return the section that should be used for transactional memory 34577 clone tables. 34578 34579 -- Target Hook: section * TARGET_ASM_SELECT_RTX_SECTION (machine_mode 34580 MODE, rtx X, unsigned HOST_WIDE_INT ALIGN) 34581 Return the section into which a constant X, of mode MODE, should 34582 be placed. You can assume that X is some kind of constant in RTL. 34583 The argument MODE is redundant except in the case of a `const_int' 34584 rtx. ALIGN is the constant alignment in bits. 34585 34586 The default version of this function takes care of putting symbolic 34587 constants in `flag_pic' mode in `data_section' and everything else 34588 in `readonly_data_section'. 34589 34590 -- Target Hook: tree TARGET_MANGLE_DECL_ASSEMBLER_NAME (tree DECL, 34591 tree ID) 34592 Define this hook if you need to postprocess the assembler name 34593 generated by target-independent code. The ID provided to this 34594 hook will be the computed name (e.g., the macro `DECL_NAME' of the 34595 DECL in C, or the mangled name of the DECL in C++). The return 34596 value of the hook is an `IDENTIFIER_NODE' for the appropriate 34597 mangled name on your target system. The default implementation of 34598 this hook just returns the ID provided. 34599 34600 -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL, 34601 int NEW_DECL_P) 34602 Define this hook if references to a symbol or a constant must be 34603 treated differently depending on something about the variable or 34604 function named by the symbol (such as what section it is in). 34605 34606 The hook is executed immediately after rtl has been created for 34607 DECL, which may be a variable or function declaration or an entry 34608 in the constant pool. In either case, RTL is the rtl in question. 34609 Do _not_ use `DECL_RTL (DECL)' in this hook; that field may not 34610 have been initialized yet. 34611 34612 In the case of a constant, it is safe to assume that the rtl is a 34613 `mem' whose address is a `symbol_ref'. Most decls will also have 34614 this form, but that is not guaranteed. Global register variables, 34615 for instance, will have a `reg' for their rtl. (Normally the 34616 right thing to do with such unusual rtl is leave it alone.) 34617 34618 The NEW_DECL_P argument will be true if this is the first time 34619 that `TARGET_ENCODE_SECTION_INFO' has been invoked on this decl. 34620 It will be false for subsequent invocations, which will happen for 34621 duplicate declarations. Whether or not anything must be done for 34622 the duplicate declaration depends on whether the hook examines 34623 `DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is 34624 called for a constant. 34625 34626 The usual thing for this hook to do is to record flags in the 34627 `symbol_ref', using `SYMBOL_REF_FLAG' or `SYMBOL_REF_FLAGS'. 34628 Historically, the name string was modified if it was necessary to 34629 encode more than one bit of information, but this practice is now 34630 discouraged; use `SYMBOL_REF_FLAGS'. 34631 34632 The default definition of this hook, `default_encode_section_info' 34633 in `varasm.c', sets a number of commonly-useful bits in 34634 `SYMBOL_REF_FLAGS'. Check whether the default does what you need 34635 before overriding it. 34636 34637 -- Target Hook: const char * TARGET_STRIP_NAME_ENCODING (const char 34638 *NAME) 34639 Decode NAME and return the real name part, sans the characters 34640 that `TARGET_ENCODE_SECTION_INFO' may have added. 34641 34642 -- Target Hook: bool TARGET_IN_SMALL_DATA_P (const_tree EXP) 34643 Returns true if EXP should be placed into a "small data" section. 34644 The default version of this hook always returns false. 34645 34646 -- Target Hook: bool TARGET_HAVE_SRODATA_SECTION 34647 Contains the value true if the target places read-only "small 34648 data" into a separate section. The default value is false. 34649 34650 -- Target Hook: bool TARGET_PROFILE_BEFORE_PROLOGUE (void) 34651 It returns true if target wants profile code emitted before 34652 prologue. 34653 34654 The default version of this hook use the target macro 34655 `PROFILE_BEFORE_PROLOGUE'. 34656 34657 -- Target Hook: bool TARGET_BINDS_LOCAL_P (const_tree EXP) 34658 Returns true if EXP names an object for which name resolution 34659 rules must resolve to the current "module" (dynamic shared library 34660 or executable image). 34661 34662 The default version of this hook implements the name resolution 34663 rules for ELF, which has a looser model of global name binding 34664 than other currently supported object file formats. 34665 34666 -- Target Hook: bool TARGET_HAVE_TLS 34667 Contains the value true if the target supports thread-local 34668 storage. The default value is false. 34669 34670 34671File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros 34672 3467317.19 Position Independent Code 34674=============================== 34675 34676This section describes macros that help implement generation of position 34677independent code. Simply defining these macros is not enough to 34678generate valid PIC; you must also add support to the hook 34679`TARGET_LEGITIMATE_ADDRESS_P' and to the macro `PRINT_OPERAND_ADDRESS', 34680as well as `LEGITIMIZE_ADDRESS'. You must modify the definition of 34681`movsi' to do something appropriate when the source operand contains a 34682symbolic address. You may also need to alter the handling of switch 34683statements so that they use relative addresses. 34684 34685 -- Macro: PIC_OFFSET_TABLE_REGNUM 34686 The register number of the register used to address a table of 34687 static data addresses in memory. In some cases this register is 34688 defined by a processor's "application binary interface" (ABI). 34689 When this macro is defined, RTL is generated for this register 34690 once, as with the stack pointer and frame pointer registers. If 34691 this macro is not defined, it is up to the machine-dependent files 34692 to allocate such a register (if necessary). Note that this 34693 register must be fixed when in use (e.g. when `flag_pic' is true). 34694 34695 -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED 34696 A C expression that is nonzero if the register defined by 34697 `PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. If not defined, 34698 the default is zero. Do not define this macro if 34699 `PIC_OFFSET_TABLE_REGNUM' is not defined. 34700 34701 -- Macro: LEGITIMATE_PIC_OPERAND_P (X) 34702 A C expression that is nonzero if X is a legitimate immediate 34703 operand on the target machine when generating position independent 34704 code. You can assume that X satisfies `CONSTANT_P', so you need 34705 not check this. You can also assume FLAG_PIC is true, so you need 34706 not check it either. You need not define this macro if all 34707 constants (including `SYMBOL_REF') can be immediate operands when 34708 generating position independent code. 34709 34710 34711File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros 34712 3471317.20 Defining the Output Assembler Language 34714============================================ 34715 34716This section describes macros whose principal purpose is to describe how 34717to write instructions in assembler language--rather than what the 34718instructions do. 34719 34720* Menu: 34721 34722* File Framework:: Structural information for the assembler file. 34723* Data Output:: Output of constants (numbers, strings, addresses). 34724* Uninitialized Data:: Output of uninitialized variables. 34725* Label Output:: Output and generation of labels. 34726* Initialization:: General principles of initialization 34727 and termination routines. 34728* Macros for Initialization:: 34729 Specific macros that control the handling of 34730 initialization and termination routines. 34731* Instruction Output:: Output of actual instructions. 34732* Dispatch Tables:: Output of jump tables. 34733* Exception Region Output:: Output of exception region code. 34734* Alignment Output:: Pseudo ops for alignment and skipping data. 34735 34736 34737File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format 34738 3473917.20.1 The Overall Framework of an Assembler File 34740-------------------------------------------------- 34741 34742This describes the overall framework of an assembly file. 34743 34744 -- Target Hook: void TARGET_ASM_FILE_START (void) 34745 Output to `asm_out_file' any text which the assembler expects to 34746 find at the beginning of a file. The default behavior is 34747 controlled by two flags, documented below. Unless your target's 34748 assembler is quite unusual, if you override the default, you 34749 should call `default_file_start' at some point in your target 34750 hook. This lets other target files rely on these variables. 34751 34752 -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF 34753 If this flag is true, the text of the macro `ASM_APP_OFF' will be 34754 printed as the very first line in the assembly file, unless 34755 `-fverbose-asm' is in effect. (If that macro has been defined to 34756 the empty string, this variable has no effect.) With the normal 34757 definition of `ASM_APP_OFF', the effect is to notify the GNU 34758 assembler that it need not bother stripping comments or extra 34759 whitespace from its input. This allows it to work a bit faster. 34760 34761 The default is false. You should not set it to true unless you 34762 have verified that your port does not generate any extra 34763 whitespace or comments that will cause GAS to issue errors in 34764 NO_APP mode. 34765 34766 -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE 34767 If this flag is true, `output_file_directive' will be called for 34768 the primary source file, immediately after printing `ASM_APP_OFF' 34769 (if that is enabled). Most ELF assemblers expect this to be done. 34770 The default is false. 34771 34772 -- Target Hook: void TARGET_ASM_FILE_END (void) 34773 Output to `asm_out_file' any text which the assembler expects to 34774 find at the end of a file. The default is to output nothing. 34775 34776 -- Function: void file_end_indicate_exec_stack () 34777 Some systems use a common convention, the `.note.GNU-stack' 34778 special section, to indicate whether or not an object file relies 34779 on the stack being executable. If your system uses this 34780 convention, you should define `TARGET_ASM_FILE_END' to this 34781 function. If you need to do other things in that hook, have your 34782 hook function call this function. 34783 34784 -- Target Hook: void TARGET_ASM_LTO_START (void) 34785 Output to `asm_out_file' any text which the assembler expects to 34786 find at the start of an LTO section. The default is to output 34787 nothing. 34788 34789 -- Target Hook: void TARGET_ASM_LTO_END (void) 34790 Output to `asm_out_file' any text which the assembler expects to 34791 find at the end of an LTO section. The default is to output 34792 nothing. 34793 34794 -- Target Hook: void TARGET_ASM_CODE_END (void) 34795 Output to `asm_out_file' any text which is needed before emitting 34796 unwind info and debug info at the end of a file. Some targets emit 34797 here PIC setup thunks that cannot be emitted at the end of file, 34798 because they couldn't have unwind info then. The default is to 34799 output nothing. 34800 34801 -- Macro: ASM_COMMENT_START 34802 A C string constant describing how to begin a comment in the target 34803 assembler language. The compiler assumes that the comment will 34804 end at the end of the line. 34805 34806 -- Macro: ASM_APP_ON 34807 A C string constant for text to be output before each `asm' 34808 statement or group of consecutive ones. Normally this is 34809 `"#APP"', which is a comment that has no effect on most assemblers 34810 but tells the GNU assembler that it must check the lines that 34811 follow for all valid assembler constructs. 34812 34813 -- Macro: ASM_APP_OFF 34814 A C string constant for text to be output after each `asm' 34815 statement or group of consecutive ones. Normally this is 34816 `"#NO_APP"', which tells the GNU assembler to resume making the 34817 time-saving assumptions that are valid for ordinary compiler 34818 output. 34819 34820 -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME) 34821 A C statement to output COFF information or DWARF debugging 34822 information which indicates that filename NAME is the current 34823 source file to the stdio stream STREAM. 34824 34825 This macro need not be defined if the standard form of output for 34826 the file format in use is appropriate. 34827 34828 -- Target Hook: void TARGET_ASM_OUTPUT_SOURCE_FILENAME (FILE *FILE, 34829 const char *NAME) 34830 Output COFF information or DWARF debugging information which 34831 indicates that filename NAME is the current source file to the 34832 stdio stream FILE. 34833 34834 This target hook need not be defined if the standard form of 34835 output for the file format in use is appropriate. 34836 34837 -- Target Hook: void TARGET_ASM_OUTPUT_IDENT (const char *NAME) 34838 Output a string based on NAME, suitable for the `#ident' 34839 directive, or the equivalent directive or pragma in non-C-family 34840 languages. If this hook is not defined, nothing is output for the 34841 `#ident' directive. 34842 34843 -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING) 34844 A C statement to output the string STRING to the stdio stream 34845 STREAM. If you do not call the function `output_quoted_string' in 34846 your config files, GCC will only call it to output filenames to 34847 the assembler source. So you can use it to canonicalize the format 34848 of the filename using this macro. 34849 34850 -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME, 34851 unsigned int FLAGS, tree DECL) 34852 Output assembly directives to switch to section NAME. The section 34853 should have attributes as specified by FLAGS, which is a bit mask 34854 of the `SECTION_*' flags defined in `output.h'. If DECL is 34855 non-NULL, it is the `VAR_DECL' or `FUNCTION_DECL' with which this 34856 section is associated. 34857 34858 -- Target Hook: section * TARGET_ASM_FUNCTION_SECTION (tree DECL, enum 34859 node_frequency FREQ, bool STARTUP, bool EXIT) 34860 Return preferred text (sub)section for function DECL. Main 34861 purpose of this function is to separate cold, normal and hot 34862 functions. STARTUP is true when function is known to be used only 34863 at startup (from static constructors or it is `main()'). EXIT is 34864 true when function is known to be used only at exit (from static 34865 destructors). Return NULL if function should go to default text 34866 section. 34867 34868 -- Target Hook: void TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS (FILE 34869 *FILE, tree DECL, bool NEW_IS_COLD) 34870 Used by the target to emit any assembler directives or additional 34871 labels needed when a function is partitioned between different 34872 sections. Output should be written to FILE. The function decl 34873 is available as DECL and the new section is `cold' if NEW_IS_COLD 34874 is `true'. 34875 34876 -- Common Target Hook: bool TARGET_HAVE_NAMED_SECTIONS 34877 This flag is true if the target supports 34878 `TARGET_ASM_NAMED_SECTION'. It must not be modified by 34879 command-line option processing. 34880 34881 -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS 34882 This flag is true if we can create zeroed data by switching to a 34883 BSS section and then using `ASM_OUTPUT_SKIP' to allocate the space. 34884 This is true on most ELF targets. 34885 34886 -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL, 34887 const char *NAME, int RELOC) 34888 Choose a set of section attributes for use by 34889 `TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a 34890 section name, and whether or not the declaration's initializer may 34891 contain runtime relocations. DECL may be null, in which case 34892 read-write data should be assumed. 34893 34894 The default version of this function handles choosing code vs data, 34895 read-only vs read-write data, and `flag_pic'. You should only 34896 need to override this if your target has special flags that might 34897 be set via `__attribute__'. 34898 34899 -- Target Hook: int TARGET_ASM_RECORD_GCC_SWITCHES (print_switch_type 34900 TYPE, const char *TEXT) 34901 Provides the target with the ability to record the gcc command line 34902 switches that have been passed to the compiler, and options that 34903 are enabled. The TYPE argument specifies what is being recorded. 34904 It can take the following values: 34905 34906 `SWITCH_TYPE_PASSED' 34907 TEXT is a command line switch that has been set by the user. 34908 34909 `SWITCH_TYPE_ENABLED' 34910 TEXT is an option which has been enabled. This might be as a 34911 direct result of a command line switch, or because it is 34912 enabled by default or because it has been enabled as a side 34913 effect of a different command line switch. For example, the 34914 `-O2' switch enables various different individual 34915 optimization passes. 34916 34917 `SWITCH_TYPE_DESCRIPTIVE' 34918 TEXT is either NULL or some descriptive text which should be 34919 ignored. If TEXT is NULL then it is being used to warn the 34920 target hook that either recording is starting or ending. The 34921 first time TYPE is SWITCH_TYPE_DESCRIPTIVE and TEXT is NULL, 34922 the warning is for start up and the second time the warning 34923 is for wind down. This feature is to allow the target hook 34924 to make any necessary preparations before it starts to record 34925 switches and to perform any necessary tidying up after it has 34926 finished recording switches. 34927 34928 `SWITCH_TYPE_LINE_START' 34929 This option can be ignored by this target hook. 34930 34931 `SWITCH_TYPE_LINE_END' 34932 This option can be ignored by this target hook. 34933 34934 The hook's return value must be zero. Other return values may be 34935 supported in the future. 34936 34937 By default this hook is set to NULL, but an example implementation 34938 is provided for ELF based targets. Called ELF_RECORD_GCC_SWITCHES, 34939 it records the switches as ASCII text inside a new, string 34940 mergeable section in the assembler output file. The name of the 34941 new section is provided by the 34942 `TARGET_ASM_RECORD_GCC_SWITCHES_SECTION' target hook. 34943 34944 -- Target Hook: const char * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION 34945 This is the name of the section that will be created by the example 34946 ELF implementation of the `TARGET_ASM_RECORD_GCC_SWITCHES' target 34947 hook. 34948 34949 34950File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format 34951 3495217.20.2 Output of Data 34953---------------------- 34954 34955 -- Target Hook: const char * TARGET_ASM_BYTE_OP 34956 -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP 34957 -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP 34958 -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP 34959 -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP 34960 -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP 34961 -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP 34962 -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP 34963 -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP 34964 These hooks specify assembly directives for creating certain kinds 34965 of integer object. The `TARGET_ASM_BYTE_OP' directive creates a 34966 byte-sized object, the `TARGET_ASM_ALIGNED_HI_OP' one creates an 34967 aligned two-byte object, and so on. Any of the hooks may be 34968 `NULL', indicating that no suitable directive is available. 34969 34970 The compiler will print these strings at the start of a new line, 34971 followed immediately by the object's initial value. In most cases, 34972 the string should contain a tab, a pseudo-op, and then another tab. 34973 34974 -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int 34975 ALIGNED_P) 34976 The `assemble_integer' function uses this hook to output an 34977 integer object. X is the object's value, SIZE is its size in 34978 bytes and ALIGNED_P indicates whether it is aligned. The function 34979 should return `true' if it was able to output the object. If it 34980 returns false, `assemble_integer' will try to split the object 34981 into smaller parts. 34982 34983 The default implementation of this hook will use the 34984 `TARGET_ASM_BYTE_OP' family of strings, returning `false' when the 34985 relevant string is `NULL'. 34986 34987 -- Target Hook: void TARGET_ASM_DECL_END (void) 34988 Define this hook if the target assembler requires a special marker 34989 to terminate an initialized variable declaration. 34990 34991 -- Target Hook: bool TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA (FILE *FILE, 34992 rtx X) 34993 A target hook to recognize RTX patterns that `output_addr_const' 34994 can't deal with, and output assembly code to FILE corresponding to 34995 the pattern X. This may be used to allow machine-dependent 34996 `UNSPEC's to appear within constants. 34997 34998 If target hook fails to recognize a pattern, it must return 34999 `false', so that a standard error message is printed. If it 35000 prints an error message itself, by calling, for example, 35001 `output_operand_lossage', it may just return `true'. 35002 35003 -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN) 35004 A C statement to output to the stdio stream STREAM an assembler 35005 instruction to assemble a string constant containing the LEN bytes 35006 at PTR. PTR will be a C expression of type `char *' and LEN a C 35007 expression of type `int'. 35008 35009 If the assembler has a `.ascii' pseudo-op as found in the Berkeley 35010 Unix assembler, do not define the macro `ASM_OUTPUT_ASCII'. 35011 35012 -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N) 35013 A C statement to output word N of a function descriptor for DECL. 35014 This must be defined if `TARGET_VTABLE_USES_DESCRIPTORS' is 35015 defined, and is otherwise unused. 35016 35017 -- Macro: CONSTANT_POOL_BEFORE_FUNCTION 35018 You may define this macro as a C expression. You should define the 35019 expression to have a nonzero value if GCC should output the 35020 constant pool for a function before the code for the function, or 35021 a zero value if GCC should output the constant pool after the 35022 function. If you do not define this macro, the usual case, GCC 35023 will output the constant pool before the function. 35024 35025 -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE) 35026 A C statement to output assembler commands to define the start of 35027 the constant pool for a function. FUNNAME is a string giving the 35028 name of the function. Should the return type of the function be 35029 required, it can be obtained via FUNDECL. SIZE is the size, in 35030 bytes, of the constant pool that will be written immediately after 35031 this call. 35032 35033 If no constant-pool prefix is required, the usual case, this macro 35034 need not be defined. 35035 35036 -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, 35037 LABELNO, JUMPTO) 35038 A C statement (with or without semicolon) to output a constant in 35039 the constant pool, if it needs special treatment. (This macro 35040 need not do anything for RTL expressions that can be output 35041 normally.) 35042 35043 The argument FILE is the standard I/O stream to output the 35044 assembler code on. X is the RTL expression for the constant to 35045 output, and MODE is the machine mode (in case X is a `const_int'). 35046 ALIGN is the required alignment for the value X; you should output 35047 an assembler directive to force this much alignment. 35048 35049 The argument LABELNO is a number to use in an internal label for 35050 the address of this pool entry. The definition of this macro is 35051 responsible for outputting the label definition at the proper 35052 place. Here is how to do this: 35053 35054 `(*targetm.asm_out.internal_label)' (FILE, "LC", LABELNO); 35055 35056 When you output a pool entry specially, you should end with a 35057 `goto' to the label JUMPTO. This will prevent the same pool entry 35058 from being output a second time in the usual manner. 35059 35060 You need not define this macro if it would do nothing. 35061 35062 -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE) 35063 A C statement to output assembler commands to at the end of the 35064 constant pool for a function. FUNNAME is a string giving the name 35065 of the function. Should the return type of the function be 35066 required, you can obtain it via FUNDECL. SIZE is the size, in 35067 bytes, of the constant pool that GCC wrote immediately before this 35068 call. 35069 35070 If no constant-pool epilogue is required, the usual case, you need 35071 not define this macro. 35072 35073 -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C, STR) 35074 Define this macro as a C expression which is nonzero if C is used 35075 as a logical line separator by the assembler. STR points to the 35076 position in the string where C was found; this can be used if a 35077 line separator uses multiple characters. 35078 35079 If you do not define this macro, the default is that only the 35080 character `;' is treated as a logical line separator. 35081 35082 -- Target Hook: const char * TARGET_ASM_OPEN_PAREN 35083 -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN 35084 These target hooks are C string constants, describing the syntax 35085 in the assembler for grouping arithmetic expressions. If not 35086 overridden, they default to normal parentheses, which is correct 35087 for most assemblers. 35088 35089 These macros are provided by `real.h' for writing the definitions of 35090`ASM_OUTPUT_DOUBLE' and the like: 35091 35092 -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L) 35093 -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L) 35094 -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L) 35095 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L) 35096 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L) 35097 -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L) 35098 These translate X, of type `REAL_VALUE_TYPE', to the target's 35099 floating point representation, and store its bit pattern in the 35100 variable L. For `REAL_VALUE_TO_TARGET_SINGLE' and 35101 `REAL_VALUE_TO_TARGET_DECIMAL32', this variable should be a simple 35102 `long int'. For the others, it should be an array of `long int'. 35103 The number of elements in this array is determined by the size of 35104 the desired target floating point data type: 32 bits of it go in 35105 each `long int' array element. Each array element holds 32 bits 35106 of the result, even if `long int' is wider than 32 bits on the 35107 host machine. 35108 35109 The array element values are designed so that you can print them 35110 out using `fprintf' in the order they should appear in the target 35111 machine's memory. 35112 35113 35114File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format 35115 3511617.20.3 Output of Uninitialized Variables 35117----------------------------------------- 35118 35119Each of the macros in this section is used to do the whole job of 35120outputting a single uninitialized variable. 35121 35122 -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED) 35123 A C statement (sans semicolon) to output to the stdio stream 35124 STREAM the assembler definition of a common-label named NAME whose 35125 size is SIZE bytes. The variable ROUNDED is the size rounded up 35126 to whatever alignment the caller wants. It is possible that SIZE 35127 may be zero, for instance if a struct with no other member than a 35128 zero-length array is defined. In this case, the backend must 35129 output a symbol definition that allocates at least one byte, both 35130 so that the address of the resulting object does not compare equal 35131 to any other, and because some object formats cannot even express 35132 the concept of a zero-sized common symbol, as that is how they 35133 represent an ordinary undefined external. 35134 35135 Use the expression `assemble_name (STREAM, NAME)' to output the 35136 name itself; before and after that, output the additional 35137 assembler syntax for defining the name, and a newline. 35138 35139 This macro controls how the assembler definitions of uninitialized 35140 common global variables are output. 35141 35142 -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT) 35143 Like `ASM_OUTPUT_COMMON' except takes the required alignment as a 35144 separate, explicit argument. If you define this macro, it is used 35145 in place of `ASM_OUTPUT_COMMON', and gives you more flexibility in 35146 handling the required alignment of the variable. The alignment is 35147 specified as the number of bits. 35148 35149 -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE, 35150 ALIGNMENT) 35151 Like `ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable 35152 to be output, if there is one, or `NULL_TREE' if there is no 35153 corresponding variable. If you define this macro, GCC will use it 35154 in place of both `ASM_OUTPUT_COMMON' and 35155 `ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to 35156 see the variable's decl in order to chose what to output. 35157 35158 -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT) 35159 A C statement (sans semicolon) to output to the stdio stream 35160 STREAM the assembler definition of uninitialized global DECL named 35161 NAME whose size is SIZE bytes. The variable ALIGNMENT is the 35162 alignment specified as the number of bits. 35163 35164 Try to use function `asm_output_aligned_bss' defined in file 35165 `varasm.c' when defining this macro. If unable, use the expression 35166 `assemble_name (STREAM, NAME)' to output the name itself; before 35167 and after that, output the additional assembler syntax for defining 35168 the name, and a newline. 35169 35170 There are two ways of handling global BSS. One is to define this 35171 macro. The other is to have `TARGET_ASM_SELECT_SECTION' return a 35172 switchable BSS section (*note 35173 TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::). You do not need to do 35174 both. 35175 35176 Some languages do not have `common' data, and require a non-common 35177 form of global BSS in order to handle uninitialized globals 35178 efficiently. C++ is one example of this. However, if the target 35179 does not support global BSS, the front end may choose to make 35180 globals common in order to save space in the object file. 35181 35182 -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED) 35183 A C statement (sans semicolon) to output to the stdio stream 35184 STREAM the assembler definition of a local-common-label named NAME 35185 whose size is SIZE bytes. The variable ROUNDED is the size 35186 rounded up to whatever alignment the caller wants. 35187 35188 Use the expression `assemble_name (STREAM, NAME)' to output the 35189 name itself; before and after that, output the additional 35190 assembler syntax for defining the name, and a newline. 35191 35192 This macro controls how the assembler definitions of uninitialized 35193 static variables are output. 35194 35195 -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT) 35196 Like `ASM_OUTPUT_LOCAL' except takes the required alignment as a 35197 separate, explicit argument. If you define this macro, it is used 35198 in place of `ASM_OUTPUT_LOCAL', and gives you more flexibility in 35199 handling the required alignment of the variable. The alignment is 35200 specified as the number of bits. 35201 35202 -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE, 35203 ALIGNMENT) 35204 Like `ASM_OUTPUT_ALIGNED_DECL' except that DECL of the variable to 35205 be output, if there is one, or `NULL_TREE' if there is no 35206 corresponding variable. If you define this macro, GCC will use it 35207 in place of both `ASM_OUTPUT_DECL' and `ASM_OUTPUT_ALIGNED_DECL'. 35208 Define this macro when you need to see the variable's decl in 35209 order to chose what to output. 35210 35211 35212File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format 35213 3521417.20.4 Output and Generation of Labels 35215--------------------------------------- 35216 35217This is about outputting labels. 35218 35219 -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME) 35220 A C statement (sans semicolon) to output to the stdio stream 35221 STREAM the assembler definition of a label named NAME. Use the 35222 expression `assemble_name (STREAM, NAME)' to output the name 35223 itself; before and after that, output the additional assembler 35224 syntax for defining the name, and a newline. A default definition 35225 of this macro is provided which is correct for most systems. 35226 35227 -- Macro: ASM_OUTPUT_FUNCTION_LABEL (STREAM, NAME, DECL) 35228 A C statement (sans semicolon) to output to the stdio stream 35229 STREAM the assembler definition of a label named NAME of a 35230 function. Use the expression `assemble_name (STREAM, NAME)' to 35231 output the name itself; before and after that, output the 35232 additional assembler syntax for defining the name, and a newline. 35233 A default definition of this macro is provided which is correct 35234 for most systems. 35235 35236 If this macro is not defined, then the function name is defined in 35237 the usual manner as a label (by means of `ASM_OUTPUT_LABEL'). 35238 35239 -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME) 35240 Identical to `ASM_OUTPUT_LABEL', except that NAME is known to 35241 refer to a compiler-generated label. The default definition uses 35242 `assemble_name_raw', which is like `assemble_name' except that it 35243 is more efficient. 35244 35245 -- Macro: SIZE_ASM_OP 35246 A C string containing the appropriate assembler directive to 35247 specify the size of a symbol, without any arguments. On systems 35248 that use ELF, the default (in `config/elfos.h') is `"\t.size\t"'; 35249 on other systems, the default is not to define this macro. 35250 35251 Define this macro only if it is correct to use the default 35252 definitions of `ASM_OUTPUT_SIZE_DIRECTIVE' and 35253 `ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own 35254 custom definitions of those macros, or if you do not need explicit 35255 symbol sizes at all, do not define this macro. 35256 35257 -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE) 35258 A C statement (sans semicolon) to output to the stdio stream 35259 STREAM a directive telling the assembler that the size of the 35260 symbol NAME is SIZE. SIZE is a `HOST_WIDE_INT'. If you define 35261 `SIZE_ASM_OP', a default definition of this macro is provided. 35262 35263 -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME) 35264 A C statement (sans semicolon) to output to the stdio stream 35265 STREAM a directive telling the assembler to calculate the size of 35266 the symbol NAME by subtracting its address from the current 35267 address. 35268 35269 If you define `SIZE_ASM_OP', a default definition of this macro is 35270 provided. The default assumes that the assembler recognizes a 35271 special `.' symbol as referring to the current address, and can 35272 calculate the difference between this and another symbol. If your 35273 assembler does not recognize `.' or cannot do calculations with 35274 it, you will need to redefine `ASM_OUTPUT_MEASURED_SIZE' to use 35275 some other technique. 35276 35277 -- Macro: NO_DOLLAR_IN_LABEL 35278 Define this macro if the assembler does not accept the character 35279 `$' in label names. By default constructors and destructors in 35280 G++ have `$' in the identifiers. If this macro is defined, `.' is 35281 used instead. 35282 35283 -- Macro: NO_DOT_IN_LABEL 35284 Define this macro if the assembler does not accept the character 35285 `.' in label names. By default constructors and destructors in G++ 35286 have names that use `.'. If this macro is defined, these names 35287 are rewritten to avoid `.'. 35288 35289 -- Macro: TYPE_ASM_OP 35290 A C string containing the appropriate assembler directive to 35291 specify the type of a symbol, without any arguments. On systems 35292 that use ELF, the default (in `config/elfos.h') is `"\t.type\t"'; 35293 on other systems, the default is not to define this macro. 35294 35295 Define this macro only if it is correct to use the default 35296 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 35297 need your own custom definition of this macro, or if you do not 35298 need explicit symbol types at all, do not define this macro. 35299 35300 -- Macro: TYPE_OPERAND_FMT 35301 A C string which specifies (using `printf' syntax) the format of 35302 the second operand to `TYPE_ASM_OP'. On systems that use ELF, the 35303 default (in `config/elfos.h') is `"@%s"'; on other systems, the 35304 default is not to define this macro. 35305 35306 Define this macro only if it is correct to use the default 35307 definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you 35308 need your own custom definition of this macro, or if you do not 35309 need explicit symbol types at all, do not define this macro. 35310 35311 -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE) 35312 A C statement (sans semicolon) to output to the stdio stream 35313 STREAM a directive telling the assembler that the type of the 35314 symbol NAME is TYPE. TYPE is a C string; currently, that string 35315 is always either `"function"' or `"object"', but you should not 35316 count on this. 35317 35318 If you define `TYPE_ASM_OP' and `TYPE_OPERAND_FMT', a default 35319 definition of this macro is provided. 35320 35321 -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL) 35322 A C statement (sans semicolon) to output to the stdio stream 35323 STREAM any text necessary for declaring the name NAME of a 35324 function which is being defined. This macro is responsible for 35325 outputting the label definition (perhaps using 35326 `ASM_OUTPUT_FUNCTION_LABEL'). The argument DECL is the 35327 `FUNCTION_DECL' tree node representing the function. 35328 35329 If this macro is not defined, then the function name is defined in 35330 the usual manner as a label (by means of 35331 `ASM_OUTPUT_FUNCTION_LABEL'). 35332 35333 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in the definition 35334 of this macro. 35335 35336 -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL) 35337 A C statement (sans semicolon) to output to the stdio stream 35338 STREAM any text necessary for declaring the size of a function 35339 which is being defined. The argument NAME is the name of the 35340 function. The argument DECL is the `FUNCTION_DECL' tree node 35341 representing the function. 35342 35343 If this macro is not defined, then the function size is not 35344 defined. 35345 35346 You may wish to use `ASM_OUTPUT_MEASURED_SIZE' in the definition 35347 of this macro. 35348 35349 -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL) 35350 A C statement (sans semicolon) to output to the stdio stream 35351 STREAM any text necessary for declaring the name NAME of an 35352 initialized variable which is being defined. This macro must 35353 output the label definition (perhaps using `ASM_OUTPUT_LABEL'). 35354 The argument DECL is the `VAR_DECL' tree node representing the 35355 variable. 35356 35357 If this macro is not defined, then the variable name is defined in 35358 the usual manner as a label (by means of `ASM_OUTPUT_LABEL'). 35359 35360 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' and/or 35361 `ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro. 35362 35363 -- Target Hook: void TARGET_ASM_DECLARE_CONSTANT_NAME (FILE *FILE, 35364 const char *NAME, const_tree EXPR, HOST_WIDE_INT SIZE) 35365 A target hook to output to the stdio stream FILE any text necessary 35366 for declaring the name NAME of a constant which is being defined. 35367 This target hook is responsible for outputting the label 35368 definition (perhaps using `assemble_label'). The argument EXP is 35369 the value of the constant, and SIZE is the size of the constant in 35370 bytes. The NAME will be an internal label. 35371 35372 The default version of this target hook, define the NAME in the 35373 usual manner as a label (by means of `assemble_label'). 35374 35375 You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in this target 35376 hook. 35377 35378 -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME) 35379 A C statement (sans semicolon) to output to the stdio stream 35380 STREAM any text necessary for claiming a register REGNO for a 35381 global variable DECL with name NAME. 35382 35383 If you don't define this macro, that is equivalent to defining it 35384 to do nothing. 35385 35386 -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND) 35387 A C statement (sans semicolon) to finish up declaring a variable 35388 name once the compiler has processed its initializer fully and 35389 thus has had a chance to determine the size of an array when 35390 controlled by an initializer. This is used on systems where it's 35391 necessary to declare something about the size of the object. 35392 35393 If you don't define this macro, that is equivalent to defining it 35394 to do nothing. 35395 35396 You may wish to use `ASM_OUTPUT_SIZE_DIRECTIVE' and/or 35397 `ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro. 35398 35399 -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const 35400 char *NAME) 35401 This target hook is a function to output to the stdio stream 35402 STREAM some commands that will make the label NAME global; that 35403 is, available for reference from other files. 35404 35405 The default implementation relies on a proper definition of 35406 `GLOBAL_ASM_OP'. 35407 35408 -- Target Hook: void TARGET_ASM_GLOBALIZE_DECL_NAME (FILE *STREAM, 35409 tree DECL) 35410 This target hook is a function to output to the stdio stream 35411 STREAM some commands that will make the name associated with DECL 35412 global; that is, available for reference from other files. 35413 35414 The default implementation uses the TARGET_ASM_GLOBALIZE_LABEL 35415 target hook. 35416 35417 -- Target Hook: void TARGET_ASM_ASSEMBLE_UNDEFINED_DECL (FILE *STREAM, 35418 const char *NAME, const_tree DECL) 35419 This target hook is a function to output to the stdio stream 35420 STREAM some commands that will declare the name associated with 35421 DECL which is not defined in the current translation unit. Most 35422 assemblers do not require anything to be output in this case. 35423 35424 -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME) 35425 A C statement (sans semicolon) to output to the stdio stream 35426 STREAM some commands that will make the label NAME weak; that is, 35427 available for reference from other files but only used if no other 35428 definition is available. Use the expression `assemble_name 35429 (STREAM, NAME)' to output the name itself; before and after that, 35430 output the additional assembler syntax for making that name weak, 35431 and a newline. 35432 35433 If you don't define this macro or `ASM_WEAKEN_DECL', GCC will not 35434 support weak symbols and you should not define the `SUPPORTS_WEAK' 35435 macro. 35436 35437 -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE) 35438 Combines (and replaces) the function of `ASM_WEAKEN_LABEL' and 35439 `ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function 35440 or variable decl. If VALUE is not `NULL', this C statement should 35441 output to the stdio stream STREAM assembler code which defines 35442 (equates) the weak symbol NAME to have the value VALUE. If VALUE 35443 is `NULL', it should output commands to make NAME weak. 35444 35445 -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE) 35446 Outputs a directive that enables NAME to be used to refer to 35447 symbol VALUE with weak-symbol semantics. `decl' is the 35448 declaration of `name'. 35449 35450 -- Macro: SUPPORTS_WEAK 35451 A preprocessor constant expression which evaluates to true if the 35452 target supports weak symbols. 35453 35454 If you don't define this macro, `defaults.h' provides a default 35455 definition. If either `ASM_WEAKEN_LABEL' or `ASM_WEAKEN_DECL' is 35456 defined, the default definition is `1'; otherwise, it is `0'. 35457 35458 -- Macro: TARGET_SUPPORTS_WEAK 35459 A C expression which evaluates to true if the target supports weak 35460 symbols. 35461 35462 If you don't define this macro, `defaults.h' provides a default 35463 definition. The default definition is `(SUPPORTS_WEAK)'. Define 35464 this macro if you want to control weak symbol support with a 35465 compiler flag such as `-melf'. 35466 35467 -- Macro: MAKE_DECL_ONE_ONLY (DECL) 35468 A C statement (sans semicolon) to mark DECL to be emitted as a 35469 public symbol such that extra copies in multiple translation units 35470 will be discarded by the linker. Define this macro if your object 35471 file format provides support for this concept, such as the `COMDAT' 35472 section flags in the Microsoft Windows PE/COFF format, and this 35473 support requires changes to DECL, such as putting it in a separate 35474 section. 35475 35476 -- Macro: SUPPORTS_ONE_ONLY 35477 A C expression which evaluates to true if the target supports 35478 one-only semantics. 35479 35480 If you don't define this macro, `varasm.c' provides a default 35481 definition. If `MAKE_DECL_ONE_ONLY' is defined, the default 35482 definition is `1'; otherwise, it is `0'. Define this macro if you 35483 want to control one-only symbol support with a compiler flag, or if 35484 setting the `DECL_ONE_ONLY' flag is enough to mark a declaration to 35485 be emitted as one-only. 35486 35487 -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, int 35488 VISIBILITY) 35489 This target hook is a function to output to ASM_OUT_FILE some 35490 commands that will make the symbol(s) associated with DECL have 35491 hidden, protected or internal visibility as specified by 35492 VISIBILITY. 35493 35494 -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC 35495 A C expression that evaluates to true if the target's linker 35496 expects that weak symbols do not appear in a static archive's 35497 table of contents. The default is `0'. 35498 35499 Leaving weak symbols out of an archive's table of contents means 35500 that, if a symbol will only have a definition in one translation 35501 unit and will have undefined references from other translation 35502 units, that symbol should not be weak. Defining this macro to be 35503 nonzero will thus have the effect that certain symbols that would 35504 normally be weak (explicit template instantiations, and vtables 35505 for polymorphic classes with noninline key methods) will instead 35506 be nonweak. 35507 35508 The C++ ABI requires this macro to be zero. Define this macro for 35509 targets where full C++ ABI compliance is impossible and where 35510 linker restrictions require weak symbols to be left out of a 35511 static archive's table of contents. 35512 35513 -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME) 35514 A C statement (sans semicolon) to output to the stdio stream 35515 STREAM any text necessary for declaring the name of an external 35516 symbol named NAME which is referenced in this compilation but not 35517 defined. The value of DECL is the tree node for the declaration. 35518 35519 This macro need not be defined if it does not need to output 35520 anything. The GNU assembler and most Unix assemblers don't 35521 require anything. 35522 35523 -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF) 35524 This target hook is a function to output to ASM_OUT_FILE an 35525 assembler pseudo-op to declare a library function name external. 35526 The name of the library function is given by SYMREF, which is a 35527 `symbol_ref'. 35528 35529 -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (const char 35530 *SYMBOL) 35531 This target hook is a function to output to ASM_OUT_FILE an 35532 assembler directive to annotate SYMBOL as used. The Darwin target 35533 uses the .no_dead_code_strip directive. 35534 35535 -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME) 35536 A C statement (sans semicolon) to output to the stdio stream 35537 STREAM a reference in assembler syntax to a label named NAME. 35538 This should add `_' to the front of the name, if that is customary 35539 on your operating system, as it is in most Berkeley Unix systems. 35540 This macro is used in `assemble_name'. 35541 35542 -- Target Hook: tree TARGET_MANGLE_ASSEMBLER_NAME (const char *NAME) 35543 Given a symbol NAME, perform same mangling as `varasm.c''s 35544 `assemble_name', but in memory rather than to a file stream, 35545 returning result as an `IDENTIFIER_NODE'. Required for correct 35546 LTO symtabs. The default implementation calls the 35547 `TARGET_STRIP_NAME_ENCODING' hook and then prepends the 35548 `USER_LABEL_PREFIX', if any. 35549 35550 -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM) 35551 A C statement (sans semicolon) to output a reference to 35552 `SYMBOL_REF' SYM. If not defined, `assemble_name' will be used to 35553 output the name of the symbol. This macro may be used to modify 35554 the way a symbol is referenced depending on information encoded by 35555 `TARGET_ENCODE_SECTION_INFO'. 35556 35557 -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF) 35558 A C statement (sans semicolon) to output a reference to BUF, the 35559 result of `ASM_GENERATE_INTERNAL_LABEL'. If not defined, 35560 `assemble_name' will be used to output the name of the symbol. 35561 This macro is not used by `output_asm_label', or the `%l' 35562 specifier that calls it; the intention is that this macro should 35563 be set when it is necessary to output a label differently when its 35564 address is being taken. 35565 35566 -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const 35567 char *PREFIX, unsigned long LABELNO) 35568 A function to output to the stdio stream STREAM a label whose name 35569 is made from the string PREFIX and the number LABELNO. 35570 35571 It is absolutely essential that these labels be distinct from the 35572 labels used for user-level functions and variables. Otherwise, 35573 certain programs will have name conflicts with internal labels. 35574 35575 It is desirable to exclude internal labels from the symbol table 35576 of the object file. Most assemblers have a naming convention for 35577 labels that should be excluded; on many systems, the letter `L' at 35578 the beginning of a label has this effect. You should find out what 35579 convention your system uses, and follow it. 35580 35581 The default version of this function utilizes 35582 `ASM_GENERATE_INTERNAL_LABEL'. 35583 35584 -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM) 35585 A C statement to output to the stdio stream STREAM a debug info 35586 label whose name is made from the string PREFIX and the number 35587 NUM. This is useful for VLIW targets, where debug info labels may 35588 need to be treated differently than branch target labels. On some 35589 systems, branch target labels must be at the beginning of 35590 instruction bundles, but debug info labels can occur in the middle 35591 of instruction bundles. 35592 35593 If this macro is not defined, then 35594 `(*targetm.asm_out.internal_label)' will be used. 35595 35596 -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM) 35597 A C statement to store into the string STRING a label whose name 35598 is made from the string PREFIX and the number NUM. 35599 35600 This string, when output subsequently by `assemble_name', should 35601 produce the output that `(*targetm.asm_out.internal_label)' would 35602 produce with the same PREFIX and NUM. 35603 35604 If the string begins with `*', then `assemble_name' will output 35605 the rest of the string unchanged. It is often convenient for 35606 `ASM_GENERATE_INTERNAL_LABEL' to use `*' in this way. If the 35607 string doesn't start with `*', then `ASM_OUTPUT_LABELREF' gets to 35608 output the string, and may change it. (Of course, 35609 `ASM_OUTPUT_LABELREF' is also part of your machine description, so 35610 you should know what it does on your machine.) 35611 35612 -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER) 35613 A C expression to assign to OUTVAR (which is a variable of type 35614 `char *') a newly allocated string made from the string NAME and 35615 the number NUMBER, with some suitable punctuation added. Use 35616 `alloca' to get space for the string. 35617 35618 The string will be used as an argument to `ASM_OUTPUT_LABELREF' to 35619 produce an assembler label for an internal static variable whose 35620 name is NAME. Therefore, the string must be such as to result in 35621 valid assembler code. The argument NUMBER is different each time 35622 this macro is executed; it prevents conflicts between 35623 similarly-named internal static variables in different scopes. 35624 35625 Ideally this string should not be a valid C identifier, to prevent 35626 any conflict with the user's own symbols. Most assemblers allow 35627 periods or percent signs in assembler symbols; putting at least 35628 one of these between the name and the number will suffice. 35629 35630 If this macro is not defined, a default definition will be provided 35631 which is correct for most systems. 35632 35633 -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE) 35634 A C statement to output to the stdio stream STREAM assembler code 35635 which defines (equates) the symbol NAME to have the value VALUE. 35636 35637 If `SET_ASM_OP' is defined, a default definition is provided which 35638 is correct for most systems. 35639 35640 -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME, 35641 DECL_OF_VALUE) 35642 A C statement to output to the stdio stream STREAM assembler code 35643 which defines (equates) the symbol whose tree node is DECL_OF_NAME 35644 to have the value of the tree node DECL_OF_VALUE. This macro will 35645 be used in preference to `ASM_OUTPUT_DEF' if it is defined and if 35646 the tree nodes are available. 35647 35648 If `SET_ASM_OP' is defined, a default definition is provided which 35649 is correct for most systems. 35650 35651 -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE) 35652 A C statement that evaluates to true if the assembler code which 35653 defines (equates) the symbol whose tree node is DECL_OF_NAME to 35654 have the value of the tree node DECL_OF_VALUE should be emitted 35655 near the end of the current compilation unit. The default is to 35656 not defer output of defines. This macro affects defines output by 35657 `ASM_OUTPUT_DEF' and `ASM_OUTPUT_DEF_FROM_DECLS'. 35658 35659 -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE) 35660 A C statement to output to the stdio stream STREAM assembler code 35661 which defines (equates) the weak symbol NAME to have the value 35662 VALUE. If VALUE is `NULL', it defines NAME as an undefined weak 35663 symbol. 35664 35665 Define this macro if the target only supports weak aliases; define 35666 `ASM_OUTPUT_DEF' instead if possible. 35667 35668 -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME, 35669 SEL_NAME) 35670 Define this macro to override the default assembler names used for 35671 Objective-C methods. 35672 35673 The default name is a unique method number followed by the name of 35674 the class (e.g. `_1_Foo'). For methods in categories, the name of 35675 the category is also included in the assembler name (e.g. 35676 `_1_Foo_Bar'). 35677 35678 These names are safe on most systems, but make debugging difficult 35679 since the method's selector is not present in the name. 35680 Therefore, particular systems define other ways of computing names. 35681 35682 BUF is an expression of type `char *' which gives you a buffer in 35683 which to store the name; its length is as long as CLASS_NAME, 35684 CAT_NAME and SEL_NAME put together, plus 50 characters extra. 35685 35686 The argument IS_INST specifies whether the method is an instance 35687 method or a class method; CLASS_NAME is the name of the class; 35688 CAT_NAME is the name of the category (or `NULL' if the method is 35689 not in a category); and SEL_NAME is the name of the selector. 35690 35691 On systems where the assembler can handle quoted names, you can 35692 use this macro to provide more human-readable names. 35693 35694 35695File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format 35696 3569717.20.5 How Initialization Functions Are Handled 35698------------------------------------------------ 35699 35700The compiled code for certain languages includes "constructors" (also 35701called "initialization routines")--functions to initialize data in the 35702program when the program is started. These functions need to be called 35703before the program is "started"--that is to say, before `main' is 35704called. 35705 35706 Compiling some languages generates "destructors" (also called 35707"termination routines") that should be called when the program 35708terminates. 35709 35710 To make the initialization and termination functions work, the compiler 35711must output something in the assembler code to cause those functions to 35712be called at the appropriate time. When you port the compiler to a new 35713system, you need to specify how to do this. 35714 35715 There are two major ways that GCC currently supports the execution of 35716initialization and termination functions. Each way has two variants. 35717Much of the structure is common to all four variations. 35718 35719 The linker must build two lists of these functions--a list of 35720initialization functions, called `__CTOR_LIST__', and a list of 35721termination functions, called `__DTOR_LIST__'. 35722 35723 Each list always begins with an ignored function pointer (which may 35724hold 0, -1, or a count of the function pointers after it, depending on 35725the environment). This is followed by a series of zero or more function 35726pointers to constructors (or destructors), followed by a function 35727pointer containing zero. 35728 35729 Depending on the operating system and its executable file format, 35730either `crtstuff.c' or `libgcc2.c' traverses these lists at startup 35731time and exit time. Constructors are called in reverse order of the 35732list; destructors in forward order. 35733 35734 The best way to handle static constructors works only for object file 35735formats which provide arbitrarily-named sections. A section is set 35736aside for a list of constructors, and another for a list of destructors. 35737Traditionally these are called `.ctors' and `.dtors'. Each object file 35738that defines an initialization function also puts a word in the 35739constructor section to point to that function. The linker accumulates 35740all these words into one contiguous `.ctors' section. Termination 35741functions are handled similarly. 35742 35743 This method will be chosen as the default by `target-def.h' if 35744`TARGET_ASM_NAMED_SECTION' is defined. A target that does not support 35745arbitrary sections, but does support special designated constructor and 35746destructor sections may define `CTORS_SECTION_ASM_OP' and 35747`DTORS_SECTION_ASM_OP' to achieve the same effect. 35748 35749 When arbitrary sections are available, there are two variants, 35750depending upon how the code in `crtstuff.c' is called. On systems that 35751support a ".init" section which is executed at program startup, parts 35752of `crtstuff.c' are compiled into that section. The program is linked 35753by the `gcc' driver like this: 35754 35755 ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o 35756 35757 The prologue of a function (`__init') appears in the `.init' section 35758of `crti.o'; the epilogue appears in `crtn.o'. Likewise for the 35759function `__fini' in the ".fini" section. Normally these files are 35760provided by the operating system or by the GNU C library, but are 35761provided by GCC for a few targets. 35762 35763 The objects `crtbegin.o' and `crtend.o' are (for most targets) 35764compiled from `crtstuff.c'. They contain, among other things, code 35765fragments within the `.init' and `.fini' sections that branch to 35766routines in the `.text' section. The linker will pull all parts of a 35767section together, which results in a complete `__init' function that 35768invokes the routines we need at startup. 35769 35770 To use this variant, you must define the `INIT_SECTION_ASM_OP' macro 35771properly. 35772 35773 If no init section is available, when GCC compiles any function called 35774`main' (or more accurately, any function designated as a program entry 35775point by the language front end calling `expand_main_function'), it 35776inserts a procedure call to `__main' as the first executable code after 35777the function prologue. The `__main' function is defined in `libgcc2.c' 35778and runs the global constructors. 35779 35780 In file formats that don't support arbitrary sections, there are again 35781two variants. In the simplest variant, the GNU linker (GNU `ld') and 35782an `a.out' format must be used. In this case, `TARGET_ASM_CONSTRUCTOR' 35783is defined to produce a `.stabs' entry of type `N_SETT', referencing 35784the name `__CTOR_LIST__', and with the address of the void function 35785containing the initialization code as its value. The GNU linker 35786recognizes this as a request to add the value to a "set"; the values 35787are accumulated, and are eventually placed in the executable as a 35788vector in the format described above, with a leading (ignored) count 35789and a trailing zero element. `TARGET_ASM_DESTRUCTOR' is handled 35790similarly. Since no init section is available, the absence of 35791`INIT_SECTION_ASM_OP' causes the compilation of `main' to call `__main' 35792as above, starting the initialization process. 35793 35794 The last variant uses neither arbitrary sections nor the GNU linker. 35795This is preferable when you want to do dynamic linking and when using 35796file formats which the GNU linker does not support, such as `ECOFF'. In 35797this case, `TARGET_HAVE_CTORS_DTORS' is false, initialization and 35798termination functions are recognized simply by their names. This 35799requires an extra program in the linkage step, called `collect2'. This 35800program pretends to be the linker, for use with GCC; it does its job by 35801running the ordinary linker, but also arranges to include the vectors of 35802initialization and termination functions. These functions are called 35803via `__main' as described above. In order to use this method, 35804`use_collect2' must be defined in the target in `config.gcc'. 35805 35806 The following section describes the specific macros that control and 35807customize the handling of initialization and termination functions. 35808 35809 35810File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format 35811 3581217.20.6 Macros Controlling Initialization Routines 35813-------------------------------------------------- 35814 35815Here are the macros that control how the compiler handles initialization 35816and termination functions: 35817 35818 -- Macro: INIT_SECTION_ASM_OP 35819 If defined, a C string constant, including spacing, for the 35820 assembler operation to identify the following data as 35821 initialization code. If not defined, GCC will assume such a 35822 section does not exist. When you are using special sections for 35823 initialization and termination functions, this macro also controls 35824 how `crtstuff.c' and `libgcc2.c' arrange to run the initialization 35825 functions. 35826 35827 -- Macro: HAS_INIT_SECTION 35828 If defined, `main' will not call `__main' as described above. 35829 This macro should be defined for systems that control start-up code 35830 on a symbol-by-symbol basis, such as OSF/1, and should not be 35831 defined explicitly for systems that support `INIT_SECTION_ASM_OP'. 35832 35833 -- Macro: LD_INIT_SWITCH 35834 If defined, a C string constant for a switch that tells the linker 35835 that the following symbol is an initialization routine. 35836 35837 -- Macro: LD_FINI_SWITCH 35838 If defined, a C string constant for a switch that tells the linker 35839 that the following symbol is a finalization routine. 35840 35841 -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC) 35842 If defined, a C statement that will write a function that can be 35843 automatically called when a shared library is loaded. The function 35844 should call FUNC, which takes no arguments. If not defined, and 35845 the object format requires an explicit initialization function, 35846 then a function called `_GLOBAL__DI' will be generated. 35847 35848 This function and the following one are used by collect2 when 35849 linking a shared library that needs constructors or destructors, 35850 or has DWARF2 exception tables embedded in the code. 35851 35852 -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC) 35853 If defined, a C statement that will write a function that can be 35854 automatically called when a shared library is unloaded. The 35855 function should call FUNC, which takes no arguments. If not 35856 defined, and the object format requires an explicit finalization 35857 function, then a function called `_GLOBAL__DD' will be generated. 35858 35859 -- Macro: INVOKE__main 35860 If defined, `main' will call `__main' despite the presence of 35861 `INIT_SECTION_ASM_OP'. This macro should be defined for systems 35862 where the init section is not actually run automatically, but is 35863 still useful for collecting the lists of constructors and 35864 destructors. 35865 35866 -- Macro: SUPPORTS_INIT_PRIORITY 35867 If nonzero, the C++ `init_priority' attribute is supported and the 35868 compiler should emit instructions to control the order of 35869 initialization of objects. If zero, the compiler will issue an 35870 error message upon encountering an `init_priority' attribute. 35871 35872 -- Target Hook: bool TARGET_HAVE_CTORS_DTORS 35873 This value is true if the target supports some "native" method of 35874 collecting constructors and destructors to be run at startup and 35875 exit. It is false if we must use `collect2'. 35876 35877 -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY) 35878 If defined, a function that outputs assembler code to arrange to 35879 call the function referenced by SYMBOL at initialization time. 35880 35881 Assume that SYMBOL is a `SYMBOL_REF' for a function taking no 35882 arguments and with no return value. If the target supports 35883 initialization priorities, PRIORITY is a value between 0 and 35884 `MAX_INIT_PRIORITY'; otherwise it must be `DEFAULT_INIT_PRIORITY'. 35885 35886 If this macro is not defined by the target, a suitable default will 35887 be chosen if (1) the target supports arbitrary section names, (2) 35888 the target defines `CTORS_SECTION_ASM_OP', or (3) `USE_COLLECT2' 35889 is not defined. 35890 35891 -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY) 35892 This is like `TARGET_ASM_CONSTRUCTOR' but used for termination 35893 functions rather than initialization functions. 35894 35895 If `TARGET_HAVE_CTORS_DTORS' is true, the initialization routine 35896generated for the generated object file will have static linkage. 35897 35898 If your system uses `collect2' as the means of processing 35899constructors, then that program normally uses `nm' to scan an object 35900file for constructor functions to be called. 35901 35902 On certain kinds of systems, you can define this macro to make 35903`collect2' work faster (and, in some cases, make it work at all): 35904 35905 -- Macro: OBJECT_FORMAT_COFF 35906 Define this macro if the system uses COFF (Common Object File 35907 Format) object files, so that `collect2' can assume this format 35908 and scan object files directly for dynamic constructor/destructor 35909 functions. 35910 35911 This macro is effective only in a native compiler; `collect2' as 35912 part of a cross compiler always uses `nm' for the target machine. 35913 35914 -- Macro: REAL_NM_FILE_NAME 35915 Define this macro as a C string constant containing the file name 35916 to use to execute `nm'. The default is to search the path 35917 normally for `nm'. 35918 35919 -- Macro: NM_FLAGS 35920 `collect2' calls `nm' to scan object files for static constructors 35921 and destructors and LTO info. By default, `-n' is passed. Define 35922 `NM_FLAGS' to a C string constant if other options are needed to 35923 get the same output format as GNU `nm -n' produces. 35924 35925 If your system supports shared libraries and has a program to list the 35926dynamic dependencies of a given library or executable, you can define 35927these macros to enable support for running initialization and 35928termination functions in shared libraries: 35929 35930 -- Macro: LDD_SUFFIX 35931 Define this macro to a C string constant containing the name of 35932 the program which lists dynamic dependencies, like `ldd' under 35933 SunOS 4. 35934 35935 -- Macro: PARSE_LDD_OUTPUT (PTR) 35936 Define this macro to be C code that extracts filenames from the 35937 output of the program denoted by `LDD_SUFFIX'. PTR is a variable 35938 of type `char *' that points to the beginning of a line of output 35939 from `LDD_SUFFIX'. If the line lists a dynamic dependency, the 35940 code must advance PTR to the beginning of the filename on that 35941 line. Otherwise, it must set PTR to `NULL'. 35942 35943 -- Macro: SHLIB_SUFFIX 35944 Define this macro to a C string constant containing the default 35945 shared library extension of the target (e.g., `".so"'). `collect2' 35946 strips version information after this suffix when generating global 35947 constructor and destructor names. This define is only needed on 35948 targets that use `collect2' to process constructors and 35949 destructors. 35950 35951 35952File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format 35953 3595417.20.7 Output of Assembler Instructions 35955---------------------------------------- 35956 35957This describes assembler instruction output. 35958 35959 -- Macro: REGISTER_NAMES 35960 A C initializer containing the assembler's names for the machine 35961 registers, each one as a C string constant. This is what 35962 translates register numbers in the compiler into assembler 35963 language. 35964 35965 -- Macro: ADDITIONAL_REGISTER_NAMES 35966 If defined, a C initializer for an array of structures containing 35967 a name and a register number. This macro defines additional names 35968 for hard registers, thus allowing the `asm' option in declarations 35969 to refer to registers using alternate names. 35970 35971 -- Macro: OVERLAPPING_REGISTER_NAMES 35972 If defined, a C initializer for an array of structures containing a 35973 name, a register number and a count of the number of consecutive 35974 machine registers the name overlaps. This macro defines additional 35975 names for hard registers, thus allowing the `asm' option in 35976 declarations to refer to registers using alternate names. Unlike 35977 `ADDITIONAL_REGISTER_NAMES', this macro should be used when the 35978 register name implies multiple underlying registers. 35979 35980 This macro should be used when it is important that a clobber in an 35981 `asm' statement clobbers all the underlying values implied by the 35982 register name. For example, on ARM, clobbering the 35983 double-precision VFP register "d0" implies clobbering both 35984 single-precision registers "s0" and "s1". 35985 35986 -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR) 35987 Define this macro if you are using an unusual assembler that 35988 requires different names for the machine instructions. 35989 35990 The definition is a C statement or statements which output an 35991 assembler instruction opcode to the stdio stream STREAM. The 35992 macro-operand PTR is a variable of type `char *' which points to 35993 the opcode name in its "internal" form--the form that is written 35994 in the machine description. The definition should output the 35995 opcode name to STREAM, performing any translation you desire, and 35996 increment the variable PTR to point at the end of the opcode so 35997 that it will not be output twice. 35998 35999 In fact, your macro definition may process less than the entire 36000 opcode name, or more than the opcode name; but if you want to 36001 process text that includes `%'-sequences to substitute operands, 36002 you must take care of the substitution yourself. Just be sure to 36003 increment PTR over whatever text should not be output normally. 36004 36005 If you need to look at the operand values, they can be found as the 36006 elements of `recog_data.operand'. 36007 36008 If the macro definition does nothing, the instruction is output in 36009 the usual way. 36010 36011 -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS) 36012 If defined, a C statement to be executed just prior to the output 36013 of assembler code for INSN, to modify the extracted operands so 36014 they will be output differently. 36015 36016 Here the argument OPVEC is the vector containing the operands 36017 extracted from INSN, and NOPERANDS is the number of elements of 36018 the vector which contain meaningful data for this insn. The 36019 contents of this vector are what will be used to convert the insn 36020 template into assembler code, so you can change the assembler 36021 output by changing the contents of the vector. 36022 36023 This macro is useful when various assembler syntaxes share a single 36024 file of instruction patterns; by defining this macro differently, 36025 you can cause a large class of instructions to be output 36026 differently (such as with rearranged operands). Naturally, 36027 variations in assembler syntax affecting individual insn patterns 36028 ought to be handled by writing conditional output routines in 36029 those patterns. 36030 36031 If this macro is not defined, it is equivalent to a null statement. 36032 36033 -- Target Hook: void TARGET_ASM_FINAL_POSTSCAN_INSN (FILE *FILE, 36034 rtx_insn *INSN, rtx *OPVEC, int NOPERANDS) 36035 If defined, this target hook is a function which is executed just 36036 after the output of assembler code for INSN, to change the mode of 36037 the assembler if necessary. 36038 36039 Here the argument OPVEC is the vector containing the operands 36040 extracted from INSN, and NOPERANDS is the number of elements of 36041 the vector which contain meaningful data for this insn. The 36042 contents of this vector are what was used to convert the insn 36043 template into assembler code, so you can change the assembler mode 36044 by checking the contents of the vector. 36045 36046 -- Macro: PRINT_OPERAND (STREAM, X, CODE) 36047 A C compound statement to output to stdio stream STREAM the 36048 assembler syntax for an instruction operand X. X is an RTL 36049 expression. 36050 36051 CODE is a value that can be used to specify one of several ways of 36052 printing the operand. It is used when identical operands must be 36053 printed differently depending on the context. CODE comes from the 36054 `%' specification that was used to request printing of the 36055 operand. If the specification was just `%DIGIT' then CODE is 0; 36056 if the specification was `%LTR DIGIT' then CODE is the ASCII code 36057 for LTR. 36058 36059 If X is a register, this macro should print the register's name. 36060 The names can be found in an array `reg_names' whose type is `char 36061 *[]'. `reg_names' is initialized from `REGISTER_NAMES'. 36062 36063 When the machine description has a specification `%PUNCT' (a `%' 36064 followed by a punctuation character), this macro is called with a 36065 null pointer for X and the punctuation character for CODE. 36066 36067 -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE) 36068 A C expression which evaluates to true if CODE is a valid 36069 punctuation character for use in the `PRINT_OPERAND' macro. If 36070 `PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no 36071 punctuation characters (except for the standard one, `%') are used 36072 in this way. 36073 36074 -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X) 36075 A C compound statement to output to stdio stream STREAM the 36076 assembler syntax for an instruction operand that is a memory 36077 reference whose address is X. X is an RTL expression. 36078 36079 On some machines, the syntax for a symbolic address depends on the 36080 section that the address refers to. On these machines, define the 36081 hook `TARGET_ENCODE_SECTION_INFO' to store the information into the 36082 `symbol_ref', and then check for it here. *Note Assembler 36083 Format::. 36084 36085 -- Macro: DBR_OUTPUT_SEQEND (FILE) 36086 A C statement, to be executed after all slot-filler instructions 36087 have been output. If necessary, call `dbr_sequence_length' to 36088 determine the number of slots filled in a sequence (zero if not 36089 currently outputting a sequence), to decide how many no-ops to 36090 output, or whatever. 36091 36092 Don't define this macro if it has nothing to do, but it is helpful 36093 in reading assembly output if the extent of the delay sequence is 36094 made explicit (e.g. with white space). 36095 36096 Note that output routines for instructions with delay slots must be 36097prepared to deal with not being output as part of a sequence (i.e. when 36098the scheduling pass is not run, or when no slot fillers could be 36099found.) The variable `final_sequence' is null when not processing a 36100sequence, otherwise it contains the `sequence' rtx being output. 36101 36102 -- Macro: REGISTER_PREFIX 36103 -- Macro: LOCAL_LABEL_PREFIX 36104 -- Macro: USER_LABEL_PREFIX 36105 -- Macro: IMMEDIATE_PREFIX 36106 If defined, C string expressions to be used for the `%R', `%L', 36107 `%U', and `%I' options of `asm_fprintf' (see `final.c'). These 36108 are useful when a single `md' file must support multiple assembler 36109 formats. In that case, the various `tm.h' files can define these 36110 macros differently. 36111 36112 -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT) 36113 If defined this macro should expand to a series of `case' 36114 statements which will be parsed inside the `switch' statement of 36115 the `asm_fprintf' function. This allows targets to define extra 36116 printf formats which may useful when generating their assembler 36117 statements. Note that uppercase letters are reserved for future 36118 generic extensions to asm_fprintf, and so are not available to 36119 target specific code. The output file is given by the parameter 36120 FILE. The varargs input pointer is ARGPTR and the rest of the 36121 format string, starting the character after the one that is being 36122 switched upon, is pointed to by FORMAT. 36123 36124 -- Macro: ASSEMBLER_DIALECT 36125 If your target supports multiple dialects of assembler language 36126 (such as different opcodes), define this macro as a C expression 36127 that gives the numeric index of the assembler language dialect to 36128 use, with zero as the first variant. 36129 36130 If this macro is defined, you may use constructs of the form 36131 `{option0|option1|option2...}' 36132 in the output templates of patterns (*note Output Template::) or 36133 in the first argument of `asm_fprintf'. This construct outputs 36134 `option0', `option1', `option2', etc., if the value of 36135 `ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters 36136 within these strings retain their usual meaning. If there are 36137 fewer alternatives within the braces than the value of 36138 `ASSEMBLER_DIALECT', the construct outputs nothing. If it's needed 36139 to print curly braces or `|' character in assembler output 36140 directly, `%{', `%}' and `%|' can be used. 36141 36142 If you do not define this macro, the characters `{', `|' and `}' 36143 do not have any special meaning when used in templates or operands 36144 to `asm_fprintf'. 36145 36146 Define the macros `REGISTER_PREFIX', `LOCAL_LABEL_PREFIX', 36147 `USER_LABEL_PREFIX' and `IMMEDIATE_PREFIX' if you can express the 36148 variations in assembler language syntax with that mechanism. 36149 Define `ASSEMBLER_DIALECT' and use the `{option0|option1}' syntax 36150 if the syntax variant are larger and involve such things as 36151 different opcodes or operand order. 36152 36153 -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO) 36154 A C expression to output to STREAM some assembler code which will 36155 push hard register number REGNO onto the stack. The code need not 36156 be optimal, since this macro is used only when profiling. 36157 36158 -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO) 36159 A C expression to output to STREAM some assembler code which will 36160 pop hard register number REGNO off of the stack. The code need 36161 not be optimal, since this macro is used only when profiling. 36162 36163 36164File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format 36165 3616617.20.8 Output of Dispatch Tables 36167--------------------------------- 36168 36169This concerns dispatch tables. 36170 36171 -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL) 36172 A C statement to output to the stdio stream STREAM an assembler 36173 pseudo-instruction to generate a difference between two labels. 36174 VALUE and REL are the numbers of two internal labels. The 36175 definitions of these labels are output using 36176 `(*targetm.asm_out.internal_label)', and they must be printed in 36177 the same way here. For example, 36178 36179 fprintf (STREAM, "\t.word L%d-L%d\n", 36180 VALUE, REL) 36181 36182 You must provide this macro on machines where the addresses in a 36183 dispatch table are relative to the table's own address. If 36184 defined, GCC will also use this macro on all machines when 36185 producing PIC. BODY is the body of the `ADDR_DIFF_VEC'; it is 36186 provided so that the mode and flags can be read. 36187 36188 -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE) 36189 This macro should be provided on machines where the addresses in a 36190 dispatch table are absolute. 36191 36192 The definition should be a C statement to output to the stdio 36193 stream STREAM an assembler pseudo-instruction to generate a 36194 reference to a label. VALUE is the number of an internal label 36195 whose definition is output using 36196 `(*targetm.asm_out.internal_label)'. For example, 36197 36198 fprintf (STREAM, "\t.word L%d\n", VALUE) 36199 36200 -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE) 36201 Define this if the label before a jump-table needs to be output 36202 specially. The first three arguments are the same as for 36203 `(*targetm.asm_out.internal_label)'; the fourth argument is the 36204 jump-table which follows (a `jump_table_data' containing an 36205 `addr_vec' or `addr_diff_vec'). 36206 36207 This feature is used on system V to output a `swbeg' statement for 36208 the table. 36209 36210 If this macro is not defined, these labels are output with 36211 `(*targetm.asm_out.internal_label)'. 36212 36213 -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE) 36214 Define this if something special must be output at the end of a 36215 jump-table. The definition should be a C statement to be executed 36216 after the assembler code for the table is written. It should write 36217 the appropriate code to stdio stream STREAM. The argument TABLE 36218 is the jump-table insn, and NUM is the label-number of the 36219 preceding label. 36220 36221 If this macro is not defined, nothing special is output at the end 36222 of the jump-table. 36223 36224 -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (FILE *STREAM, tree 36225 DECL, int FOR_EH, int EMPTY) 36226 This target hook emits a label at the beginning of each FDE. It 36227 should be defined on targets where FDEs need special labels, and it 36228 should write the appropriate label, for the FDE associated with the 36229 function declaration DECL, to the stdio stream STREAM. The third 36230 argument, FOR_EH, is a boolean: true if this is for an exception 36231 table. The fourth argument, EMPTY, is a boolean: true if this is 36232 a placeholder label for an omitted FDE. 36233 36234 The default is that FDEs are not given nonlocal labels. 36235 36236 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL (FILE *STREAM) 36237 This target hook emits a label at the beginning of the exception 36238 table. It should be defined on targets where it is desirable for 36239 the table to be broken up according to function. 36240 36241 The default is that no label is emitted. 36242 36243 -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_PERSONALITY (rtx 36244 PERSONALITY) 36245 If the target implements `TARGET_ASM_UNWIND_EMIT', this hook may 36246 be used to emit a directive to install a personality hook into the 36247 unwind info. This hook should not be used if dwarf2 unwind info 36248 is used. 36249 36250 -- Target Hook: void TARGET_ASM_UNWIND_EMIT (FILE *STREAM, rtx_insn 36251 *INSN) 36252 This target hook emits assembly directives required to unwind the 36253 given instruction. This is only used when 36254 `TARGET_EXCEPT_UNWIND_INFO' returns `UI_TARGET'. 36255 36256 -- Target Hook: bool TARGET_ASM_UNWIND_EMIT_BEFORE_INSN 36257 True if the `TARGET_ASM_UNWIND_EMIT' hook should be called before 36258 the assembly for INSN has been emitted, false if the hook should 36259 be called afterward. 36260 36261 36262File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format 36263 3626417.20.9 Assembler Commands for Exception Regions 36265------------------------------------------------ 36266 36267This describes commands marking the start and the end of an exception 36268region. 36269 36270 -- Macro: EH_FRAME_SECTION_NAME 36271 If defined, a C string constant for the name of the section 36272 containing exception handling frame unwind information. If not 36273 defined, GCC will provide a default definition if the target 36274 supports named sections. `crtstuff.c' uses this macro to switch 36275 to the appropriate section. 36276 36277 You should define this symbol if your target supports DWARF 2 frame 36278 unwind information and the default definition does not work. 36279 36280 -- Macro: EH_FRAME_IN_DATA_SECTION 36281 If defined, DWARF 2 frame unwind information will be placed in the 36282 data section even though the target supports named sections. This 36283 might be necessary, for instance, if the system linker does garbage 36284 collection and sections cannot be marked as not to be collected. 36285 36286 Do not define this macro unless `TARGET_ASM_NAMED_SECTION' is also 36287 defined. 36288 36289 -- Macro: EH_TABLES_CAN_BE_READ_ONLY 36290 Define this macro to 1 if your target is such that no frame unwind 36291 information encoding used with non-PIC code will ever require a 36292 runtime relocation, but the linker may not support merging 36293 read-only and read-write sections into a single read-write section. 36294 36295 -- Macro: MASK_RETURN_ADDR 36296 An rtx used to mask the return address found via 36297 `RETURN_ADDR_RTX', so that it does not contain any extraneous set 36298 bits in it. 36299 36300 -- Macro: DWARF2_UNWIND_INFO 36301 Define this macro to 0 if your target supports DWARF 2 frame unwind 36302 information, but it does not yet work with exception handling. 36303 Otherwise, if your target supports this information (if it defines 36304 `INCOMING_RETURN_ADDR_RTX' and `OBJECT_FORMAT_ELF'), GCC will 36305 provide a default definition of 1. 36306 36307 -- Common Target Hook: enum unwind_info_type TARGET_EXCEPT_UNWIND_INFO 36308 (struct gcc_options *OPTS) 36309 This hook defines the mechanism that will be used for exception 36310 handling by the target. If the target has ABI specified unwind 36311 tables, the hook should return `UI_TARGET'. If the target is to 36312 use the `setjmp'/`longjmp'-based exception handling scheme, the 36313 hook should return `UI_SJLJ'. If the target supports DWARF 2 36314 frame unwind information, the hook should return `UI_DWARF2'. 36315 36316 A target may, if exceptions are disabled, choose to return 36317 `UI_NONE'. This may end up simplifying other parts of 36318 target-specific code. The default implementation of this hook 36319 never returns `UI_NONE'. 36320 36321 Note that the value returned by this hook should be constant. It 36322 should not depend on anything except the command-line switches 36323 described by OPTS. In particular, the setting `UI_SJLJ' must be 36324 fixed at compiler start-up as C pre-processor macros and builtin 36325 functions related to exception handling are set up depending on 36326 this setting. 36327 36328 The default implementation of the hook first honors the 36329 `--enable-sjlj-exceptions' configure option, then 36330 `DWARF2_UNWIND_INFO', and finally defaults to `UI_SJLJ'. If 36331 `DWARF2_UNWIND_INFO' depends on command-line options, the target 36332 must define this hook so that OPTS is used correctly. 36333 36334 -- Common Target Hook: bool TARGET_UNWIND_TABLES_DEFAULT 36335 This variable should be set to `true' if the target ABI requires 36336 unwinding tables even when exceptions are not used. It must not 36337 be modified by command-line option processing. 36338 36339 -- Macro: DONT_USE_BUILTIN_SETJMP 36340 Define this macro to 1 if the `setjmp'/`longjmp'-based scheme 36341 should use the `setjmp'/`longjmp' functions from the C library 36342 instead of the `__builtin_setjmp'/`__builtin_longjmp' machinery. 36343 36344 -- Macro: JMP_BUF_SIZE 36345 This macro has no effect unless `DONT_USE_BUILTIN_SETJMP' is also 36346 defined. Define this macro if the default size of `jmp_buf' buffer 36347 for the `setjmp'/`longjmp'-based exception handling mechanism is 36348 not large enough, or if it is much too large. The default size is 36349 `FIRST_PSEUDO_REGISTER * sizeof(void *)'. 36350 36351 -- Macro: DWARF_CIE_DATA_ALIGNMENT 36352 This macro need only be defined if the target might save registers 36353 in the function prologue at an offset to the stack pointer that is 36354 not aligned to `UNITS_PER_WORD'. The definition should be the 36355 negative minimum alignment if `STACK_GROWS_DOWNWARD' is defined, 36356 and the positive minimum alignment otherwise. *Note SDB and 36357 DWARF::. Only applicable if the target supports DWARF 2 frame 36358 unwind information. 36359 36360 -- Target Hook: bool TARGET_TERMINATE_DW2_EH_FRAME_INFO 36361 Contains the value true if the target should add a zero word onto 36362 the end of a Dwarf-2 frame info section when used for exception 36363 handling. Default value is false if `EH_FRAME_SECTION_NAME' is 36364 defined, and true otherwise. 36365 36366 -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG) 36367 Given a register, this hook should return a parallel of registers 36368 to represent where to find the register pieces. Define this hook 36369 if the register and its mode are represented in Dwarf in 36370 non-contiguous locations, or if the register should be represented 36371 in more than one register in Dwarf. Otherwise, this hook should 36372 return `NULL_RTX'. If not defined, the default is to return 36373 `NULL_RTX'. 36374 36375 -- Target Hook: machine_mode TARGET_DWARF_FRAME_REG_MODE (int REGNO) 36376 Given a register, this hook should return the mode which the 36377 corresponding Dwarf frame register should have. This is normally 36378 used to return a smaller mode than the raw mode to prevent call 36379 clobbered parts of a register altering the frame register size 36380 36381 -- Target Hook: void TARGET_INIT_DWARF_REG_SIZES_EXTRA (tree ADDRESS) 36382 If some registers are represented in Dwarf-2 unwind information in 36383 multiple pieces, define this hook to fill in information about the 36384 sizes of those pieces in the table used by the unwinder at runtime. 36385 It will be called by `expand_builtin_init_dwarf_reg_sizes' after 36386 filling in a single size corresponding to each hard register; 36387 ADDRESS is the address of the table. 36388 36389 -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM) 36390 This hook is used to output a reference from a frame unwinding 36391 table to the type_info object identified by SYM. It should return 36392 `true' if the reference was output. Returning `false' will cause 36393 the reference to be output using the normal Dwarf2 routines. 36394 36395 -- Target Hook: bool TARGET_ARM_EABI_UNWINDER 36396 This flag should be set to `true' on targets that use an ARM EABI 36397 based unwinding library, and `false' on other targets. This 36398 effects the format of unwinding tables, and how the unwinder in 36399 entered after running a cleanup. The default is `false'. 36400 36401 36402File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format 36403 3640417.20.10 Assembler Commands for Alignment 36405----------------------------------------- 36406 36407This describes commands for alignment. 36408 36409 -- Macro: JUMP_ALIGN (LABEL) 36410 The alignment (log base 2) to put in front of LABEL, which is a 36411 common destination of jumps and has no fallthru incoming edge. 36412 36413 This macro need not be defined if you don't want any special 36414 alignment to be done at such a time. Most machine descriptions do 36415 not currently define the macro. 36416 36417 Unless it's necessary to inspect the LABEL parameter, it is better 36418 to set the variable ALIGN_JUMPS in the target's 36419 `TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 36420 user's selection in ALIGN_JUMPS in a `JUMP_ALIGN' implementation. 36421 36422 -- Target Hook: int TARGET_ASM_JUMP_ALIGN_MAX_SKIP (rtx_insn *LABEL) 36423 The maximum number of bytes to skip before LABEL when applying 36424 `JUMP_ALIGN'. This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is 36425 defined. 36426 36427 -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL) 36428 The alignment (log base 2) to put in front of LABEL, which follows 36429 a `BARRIER'. 36430 36431 This macro need not be defined if you don't want any special 36432 alignment to be done at such a time. Most machine descriptions do 36433 not currently define the macro. 36434 36435 -- Target Hook: int TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP 36436 (rtx_insn *LABEL) 36437 The maximum number of bytes to skip before LABEL when applying 36438 `LABEL_ALIGN_AFTER_BARRIER'. This works only if 36439 `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 36440 36441 -- Macro: LOOP_ALIGN (LABEL) 36442 The alignment (log base 2) to put in front of LABEL that heads a 36443 frequently executed basic block (usually the header of a loop). 36444 36445 This macro need not be defined if you don't want any special 36446 alignment to be done at such a time. Most machine descriptions do 36447 not currently define the macro. 36448 36449 Unless it's necessary to inspect the LABEL parameter, it is better 36450 to set the variable `align_loops' in the target's 36451 `TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 36452 user's selection in `align_loops' in a `LOOP_ALIGN' implementation. 36453 36454 -- Target Hook: int TARGET_ASM_LOOP_ALIGN_MAX_SKIP (rtx_insn *LABEL) 36455 The maximum number of bytes to skip when applying `LOOP_ALIGN' to 36456 LABEL. This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 36457 36458 -- Macro: LABEL_ALIGN (LABEL) 36459 The alignment (log base 2) to put in front of LABEL. If 36460 `LABEL_ALIGN_AFTER_BARRIER' / `LOOP_ALIGN' specify a different 36461 alignment, the maximum of the specified values is used. 36462 36463 Unless it's necessary to inspect the LABEL parameter, it is better 36464 to set the variable `align_labels' in the target's 36465 `TARGET_OPTION_OVERRIDE'. Otherwise, you should try to honor the 36466 user's selection in `align_labels' in a `LABEL_ALIGN' 36467 implementation. 36468 36469 -- Target Hook: int TARGET_ASM_LABEL_ALIGN_MAX_SKIP (rtx_insn *LABEL) 36470 The maximum number of bytes to skip when applying `LABEL_ALIGN' to 36471 LABEL. This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined. 36472 36473 -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES) 36474 A C statement to output to the stdio stream STREAM an assembler 36475 instruction to advance the location counter by NBYTES bytes. 36476 Those bytes should be zero when loaded. NBYTES will be a C 36477 expression of type `unsigned HOST_WIDE_INT'. 36478 36479 -- Macro: ASM_NO_SKIP_IN_TEXT 36480 Define this macro if `ASM_OUTPUT_SKIP' should not be used in the 36481 text section because it fails to put zeros in the bytes that are 36482 skipped. This is true on many Unix systems, where the pseudo-op 36483 to skip bytes produces no-op instructions rather than zeros when 36484 used in the text section. 36485 36486 -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER) 36487 A C statement to output to the stdio stream STREAM an assembler 36488 command to advance the location counter to a multiple of 2 to the 36489 POWER bytes. POWER will be a C expression of type `int'. 36490 36491 -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER) 36492 Like `ASM_OUTPUT_ALIGN', except that the "nop" instruction is used 36493 for padding, if necessary. 36494 36495 -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP) 36496 A C statement to output to the stdio stream STREAM an assembler 36497 command to advance the location counter to a multiple of 2 to the 36498 POWER bytes, but only if MAX_SKIP or fewer bytes are needed to 36499 satisfy the alignment request. POWER and MAX_SKIP will be a C 36500 expression of type `int'. 36501 36502 36503File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros 36504 3650517.21 Controlling Debugging Information Format 36506============================================== 36507 36508This describes how to specify debugging information. 36509 36510* Menu: 36511 36512* All Debuggers:: Macros that affect all debugging formats uniformly. 36513* DBX Options:: Macros enabling specific options in DBX format. 36514* DBX Hooks:: Hook macros for varying DBX format. 36515* File Names and DBX:: Macros controlling output of file names in DBX format. 36516* SDB and DWARF:: Macros for SDB (COFF) and DWARF formats. 36517* VMS Debug:: Macros for VMS debug format. 36518 36519 36520File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info 36521 3652217.21.1 Macros Affecting All Debugging Formats 36523---------------------------------------------- 36524 36525These macros affect all debugging formats. 36526 36527 -- Macro: DBX_REGISTER_NUMBER (REGNO) 36528 A C expression that returns the DBX register number for the 36529 compiler register number REGNO. In the default macro provided, 36530 the value of this expression will be REGNO itself. But sometimes 36531 there are some registers that the compiler knows about and DBX 36532 does not, or vice versa. In such cases, some register may need to 36533 have one number in the compiler and another for DBX. 36534 36535 If two registers have consecutive numbers inside GCC, and they can 36536 be used as a pair to hold a multiword value, then they _must_ have 36537 consecutive numbers after renumbering with `DBX_REGISTER_NUMBER'. 36538 Otherwise, debuggers will be unable to access such a pair, because 36539 they expect register pairs to be consecutive in their own 36540 numbering scheme. 36541 36542 If you find yourself defining `DBX_REGISTER_NUMBER' in way that 36543 does not preserve register pairs, then what you must do instead is 36544 redefine the actual register numbering scheme. 36545 36546 -- Macro: DEBUGGER_AUTO_OFFSET (X) 36547 A C expression that returns the integer offset value for an 36548 automatic variable having address X (an RTL expression). The 36549 default computation assumes that X is based on the frame-pointer 36550 and gives the offset from the frame-pointer. This is required for 36551 targets that produce debugging output for DBX or COFF-style 36552 debugging output for SDB and allow the frame-pointer to be 36553 eliminated when the `-g' options is used. 36554 36555 -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X) 36556 A C expression that returns the integer offset value for an 36557 argument having address X (an RTL expression). The nominal offset 36558 is OFFSET. 36559 36560 -- Macro: PREFERRED_DEBUGGING_TYPE 36561 A C expression that returns the type of debugging output GCC should 36562 produce when the user specifies just `-g'. Define this if you 36563 have arranged for GCC to support more than one format of debugging 36564 output. Currently, the allowable values are `DBX_DEBUG', 36565 `SDB_DEBUG', `DWARF_DEBUG', `DWARF2_DEBUG', `XCOFF_DEBUG', 36566 `VMS_DEBUG', and `VMS_AND_DWARF2_DEBUG'. 36567 36568 When the user specifies `-ggdb', GCC normally also uses the value 36569 of this macro to select the debugging output format, but with two 36570 exceptions. If `DWARF2_DEBUGGING_INFO' is defined, GCC uses the 36571 value `DWARF2_DEBUG'. Otherwise, if `DBX_DEBUGGING_INFO' is 36572 defined, GCC uses `DBX_DEBUG'. 36573 36574 The value of this macro only affects the default debugging output; 36575 the user can always get a specific type of output by using 36576 `-gstabs', `-gcoff', `-gdwarf-2', `-gxcoff', or `-gvms'. 36577 36578 36579File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info 36580 3658117.21.2 Specific Options for DBX Output 36582--------------------------------------- 36583 36584These are specific options for DBX output. 36585 36586 -- Macro: DBX_DEBUGGING_INFO 36587 Define this macro if GCC should produce debugging output for DBX 36588 in response to the `-g' option. 36589 36590 -- Macro: XCOFF_DEBUGGING_INFO 36591 Define this macro if GCC should produce XCOFF format debugging 36592 output in response to the `-g' option. This is a variant of DBX 36593 format. 36594 36595 -- Macro: DEFAULT_GDB_EXTENSIONS 36596 Define this macro to control whether GCC should by default generate 36597 GDB's extended version of DBX debugging information (assuming 36598 DBX-format debugging information is enabled at all). If you don't 36599 define the macro, the default is 1: always generate the extended 36600 information if there is any occasion to. 36601 36602 -- Macro: DEBUG_SYMS_TEXT 36603 Define this macro if all `.stabs' commands should be output while 36604 in the text section. 36605 36606 -- Macro: ASM_STABS_OP 36607 A C string constant, including spacing, naming the assembler 36608 pseudo op to use instead of `"\t.stabs\t"' to define an ordinary 36609 debugging symbol. If you don't define this macro, `"\t.stabs\t"' 36610 is used. This macro applies only to DBX debugging information 36611 format. 36612 36613 -- Macro: ASM_STABD_OP 36614 A C string constant, including spacing, naming the assembler 36615 pseudo op to use instead of `"\t.stabd\t"' to define a debugging 36616 symbol whose value is the current location. If you don't define 36617 this macro, `"\t.stabd\t"' is used. This macro applies only to 36618 DBX debugging information format. 36619 36620 -- Macro: ASM_STABN_OP 36621 A C string constant, including spacing, naming the assembler 36622 pseudo op to use instead of `"\t.stabn\t"' to define a debugging 36623 symbol with no name. If you don't define this macro, 36624 `"\t.stabn\t"' is used. This macro applies only to DBX debugging 36625 information format. 36626 36627 -- Macro: DBX_NO_XREFS 36628 Define this macro if DBX on your system does not support the 36629 construct `xsTAGNAME'. On some systems, this construct is used to 36630 describe a forward reference to a structure named TAGNAME. On 36631 other systems, this construct is not supported at all. 36632 36633 -- Macro: DBX_CONTIN_LENGTH 36634 A symbol name in DBX-format debugging information is normally 36635 continued (split into two separate `.stabs' directives) when it 36636 exceeds a certain length (by default, 80 characters). On some 36637 operating systems, DBX requires this splitting; on others, 36638 splitting must not be done. You can inhibit splitting by defining 36639 this macro with the value zero. You can override the default 36640 splitting-length by defining this macro as an expression for the 36641 length you desire. 36642 36643 -- Macro: DBX_CONTIN_CHAR 36644 Normally continuation is indicated by adding a `\' character to 36645 the end of a `.stabs' string when a continuation follows. To use 36646 a different character instead, define this macro as a character 36647 constant for the character you want to use. Do not define this 36648 macro if backslash is correct for your system. 36649 36650 -- Macro: DBX_STATIC_STAB_DATA_SECTION 36651 Define this macro if it is necessary to go to the data section 36652 before outputting the `.stabs' pseudo-op for a non-global static 36653 variable. 36654 36655 -- Macro: DBX_TYPE_DECL_STABS_CODE 36656 The value to use in the "code" field of the `.stabs' directive for 36657 a typedef. The default is `N_LSYM'. 36658 36659 -- Macro: DBX_STATIC_CONST_VAR_CODE 36660 The value to use in the "code" field of the `.stabs' directive for 36661 a static variable located in the text section. DBX format does not 36662 provide any "right" way to do this. The default is `N_FUN'. 36663 36664 -- Macro: DBX_REGPARM_STABS_CODE 36665 The value to use in the "code" field of the `.stabs' directive for 36666 a parameter passed in registers. DBX format does not provide any 36667 "right" way to do this. The default is `N_RSYM'. 36668 36669 -- Macro: DBX_REGPARM_STABS_LETTER 36670 The letter to use in DBX symbol data to identify a symbol as a 36671 parameter passed in registers. DBX format does not customarily 36672 provide any way to do this. The default is `'P''. 36673 36674 -- Macro: DBX_FUNCTION_FIRST 36675 Define this macro if the DBX information for a function and its 36676 arguments should precede the assembler code for the function. 36677 Normally, in DBX format, the debugging information entirely 36678 follows the assembler code. 36679 36680 -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE 36681 Define this macro, with value 1, if the value of a symbol 36682 describing the scope of a block (`N_LBRAC' or `N_RBRAC') should be 36683 relative to the start of the enclosing function. Normally, GCC 36684 uses an absolute address. 36685 36686 -- Macro: DBX_LINES_FUNCTION_RELATIVE 36687 Define this macro, with value 1, if the value of a symbol 36688 indicating the current line number (`N_SLINE') should be relative 36689 to the start of the enclosing function. Normally, GCC uses an 36690 absolute address. 36691 36692 -- Macro: DBX_USE_BINCL 36693 Define this macro if GCC should generate `N_BINCL' and `N_EINCL' 36694 stabs for included header files, as on Sun systems. This macro 36695 also directs GCC to output a type number as a pair of a file 36696 number and a type number within the file. Normally, GCC does not 36697 generate `N_BINCL' or `N_EINCL' stabs, and it outputs a single 36698 number for a type number. 36699 36700 36701File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info 36702 3670317.21.3 Open-Ended Hooks for DBX Format 36704--------------------------------------- 36705 36706These are hooks for DBX format. 36707 36708 -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER) 36709 A C statement to output DBX debugging information before code for 36710 line number LINE of the current source file to the stdio stream 36711 STREAM. COUNTER is the number of time the macro was invoked, 36712 including the current invocation; it is intended to generate 36713 unique labels in the assembly output. 36714 36715 This macro should not be defined if the default output is correct, 36716 or if it can be made correct by defining 36717 `DBX_LINES_FUNCTION_RELATIVE'. 36718 36719 -- Macro: NO_DBX_FUNCTION_END 36720 Some stabs encapsulation formats (in particular ECOFF), cannot 36721 handle the `.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx 36722 extension construct. On those machines, define this macro to turn 36723 this feature off without disturbing the rest of the gdb extensions. 36724 36725 -- Macro: NO_DBX_BNSYM_ENSYM 36726 Some assemblers cannot handle the `.stabd BNSYM/ENSYM,0,0' gdb dbx 36727 extension construct. On those machines, define this macro to turn 36728 this feature off without disturbing the rest of the gdb extensions. 36729 36730 36731File: gccint.info, Node: File Names and DBX, Next: SDB and DWARF, Prev: DBX Hooks, Up: Debugging Info 36732 3673317.21.4 File Names in DBX Format 36734-------------------------------- 36735 36736This describes file names in DBX format. 36737 36738 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME) 36739 A C statement to output DBX debugging information to the stdio 36740 stream STREAM, which indicates that file NAME is the main source 36741 file--the file specified as the input file for compilation. This 36742 macro is called only once, at the beginning of compilation. 36743 36744 This macro need not be defined if the standard form of output for 36745 DBX debugging information is appropriate. 36746 36747 It may be necessary to refer to a label equal to the beginning of 36748 the text section. You can use `assemble_name (stream, 36749 ltext_label_name)' to do so. If you do this, you must also set 36750 the variable USED_LTEXT_LABEL_NAME to `true'. 36751 36752 -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY 36753 Define this macro, with value 1, if GCC should not emit an 36754 indication of the current directory for compilation and current 36755 source language at the beginning of the file. 36756 36757 -- Macro: NO_DBX_GCC_MARKER 36758 Define this macro, with value 1, if GCC should not emit an 36759 indication that this object file was compiled by GCC. The default 36760 is to emit an `N_OPT' stab at the beginning of every source file, 36761 with `gcc2_compiled.' for the string and value 0. 36762 36763 -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME) 36764 A C statement to output DBX debugging information at the end of 36765 compilation of the main source file NAME. Output should be 36766 written to the stdio stream STREAM. 36767 36768 If you don't define this macro, nothing special is output at the 36769 end of compilation, which is correct for most machines. 36770 36771 -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END 36772 Define this macro _instead of_ defining 36773 `DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at 36774 the end of compilation is an `N_SO' stab with an empty string, 36775 whose value is the highest absolute text address in the file. 36776 36777 36778File: gccint.info, Node: SDB and DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info 36779 3678017.21.5 Macros for SDB and DWARF Output 36781--------------------------------------- 36782 36783Here are macros for SDB and DWARF output. 36784 36785 -- Macro: SDB_DEBUGGING_INFO 36786 Define this macro if GCC should produce COFF-style debugging output 36787 for SDB in response to the `-g' option. 36788 36789 -- Macro: DWARF2_DEBUGGING_INFO 36790 Define this macro if GCC should produce dwarf version 2 format 36791 debugging output in response to the `-g' option. 36792 36793 -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (const_tree 36794 FUNCTION) 36795 Define this to enable the dwarf attribute 36796 `DW_AT_calling_convention' to be emitted for each function. 36797 Instead of an integer return the enum value for the `DW_CC_' 36798 tag. 36799 36800 To support optional call frame debugging information, you must also 36801 define `INCOMING_RETURN_ADDR_RTX' and either set 36802 `RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the 36803 prologue, or call `dwarf2out_def_cfa' and `dwarf2out_reg_save' as 36804 appropriate from `TARGET_ASM_FUNCTION_PROLOGUE' if you don't. 36805 36806 -- Macro: DWARF2_FRAME_INFO 36807 Define this macro to a nonzero value if GCC should always output 36808 Dwarf 2 frame information. If `TARGET_EXCEPT_UNWIND_INFO' (*note 36809 Exception Region Output::) returns `UI_DWARF2', and exceptions are 36810 enabled, GCC will output this information not matter how you 36811 define `DWARF2_FRAME_INFO'. 36812 36813 -- Target Hook: enum unwind_info_type TARGET_DEBUG_UNWIND_INFO (void) 36814 This hook defines the mechanism that will be used for describing 36815 frame unwind information to the debugger. Normally the hook will 36816 return `UI_DWARF2' if DWARF 2 debug information is enabled, and 36817 return `UI_NONE' otherwise. 36818 36819 A target may return `UI_DWARF2' even when DWARF 2 debug information 36820 is disabled in order to always output DWARF 2 frame information. 36821 36822 A target may return `UI_TARGET' if it has ABI specified unwind 36823 tables. This will suppress generation of the normal debug frame 36824 unwind information. 36825 36826 -- Macro: DWARF2_ASM_LINE_DEBUG_INFO 36827 Define this macro to be a nonzero value if the assembler can 36828 generate Dwarf 2 line debug info sections. This will result in 36829 much more compact line number tables, and hence is desirable if it 36830 works. 36831 36832 -- Target Hook: bool TARGET_WANT_DEBUG_PUB_SECTIONS 36833 True if the `.debug_pubtypes' and `.debug_pubnames' sections 36834 should be emitted. These sections are not used on most platforms, 36835 and in particular GDB does not use them. 36836 36837 -- Target Hook: bool TARGET_FORCE_AT_COMP_DIR 36838 True if the `DW_AT_comp_dir' attribute should be emitted for each 36839 compilation unit. This attribute is required for the darwin 36840 linker to emit debug information. 36841 36842 -- Target Hook: bool TARGET_DELAY_SCHED2 36843 True if sched2 is not to be run at its normal place. This usually 36844 means it will be run as part of machine-specific reorg. 36845 36846 -- Target Hook: bool TARGET_DELAY_VARTRACK 36847 True if vartrack is not to be run at its normal place. This 36848 usually means it will be run as part of machine-specific reorg. 36849 36850 -- Target Hook: bool TARGET_NO_REGISTER_ALLOCATION 36851 True if register allocation and the passes following it should not 36852 be run. Usually true only for virtual assembler targets. 36853 36854 -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2) 36855 A C statement to issue assembly directives that create a difference 36856 LAB1 minus LAB2, using an integer of the given SIZE. 36857 36858 -- Macro: ASM_OUTPUT_DWARF_VMS_DELTA (STREAM, SIZE, LABEL1, LABEL2) 36859 A C statement to issue assembly directives that create a difference 36860 between the two given labels in system defined units, e.g. 36861 instruction slots on IA64 VMS, using an integer of the given size. 36862 36863 -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL, SECTION) 36864 A C statement to issue assembly directives that create a 36865 section-relative reference to the given LABEL, using an integer of 36866 the given SIZE. The label is known to be defined in the given 36867 SECTION. 36868 36869 -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL) 36870 A C statement to issue assembly directives that create a 36871 self-relative reference to the given LABEL, using an integer of 36872 the given SIZE. 36873 36874 -- Macro: ASM_OUTPUT_DWARF_TABLE_REF (LABEL) 36875 A C statement to issue assembly directives that create a reference 36876 to the DWARF table identifier LABEL from the current section. This 36877 is used on some systems to avoid garbage collecting a DWARF table 36878 which is referenced by a function. 36879 36880 -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int 36881 SIZE, rtx X) 36882 If defined, this target hook is a function which outputs a 36883 DTP-relative reference to the given TLS symbol of the specified 36884 size. 36885 36886 -- Macro: PUT_SDB_... 36887 Define these macros to override the assembler syntax for the 36888 special SDB assembler directives. See `sdbout.c' for a list of 36889 these macros and their arguments. If the standard syntax is used, 36890 you need not define them yourself. 36891 36892 -- Macro: SDB_DELIM 36893 Some assemblers do not support a semicolon as a delimiter, even 36894 between SDB assembler directives. In that case, define this macro 36895 to be the delimiter to use (usually `\n'). It is not necessary to 36896 define a new set of `PUT_SDB_OP' macros if this is the only change 36897 required. 36898 36899 -- Macro: SDB_ALLOW_UNKNOWN_REFERENCES 36900 Define this macro to allow references to unknown structure, union, 36901 or enumeration tags to be emitted. Standard COFF does not allow 36902 handling of unknown references, MIPS ECOFF has support for it. 36903 36904 -- Macro: SDB_ALLOW_FORWARD_REFERENCES 36905 Define this macro to allow references to structure, union, or 36906 enumeration tags that have not yet been seen to be handled. Some 36907 assemblers choke if forward tags are used, while some require it. 36908 36909 -- Macro: SDB_OUTPUT_SOURCE_LINE (STREAM, LINE) 36910 A C statement to output SDB debugging information before code for 36911 line number LINE of the current source file to the stdio stream 36912 STREAM. The default is to emit an `.ln' directive. 36913 36914 36915File: gccint.info, Node: VMS Debug, Prev: SDB and DWARF, Up: Debugging Info 36916 3691717.21.6 Macros for VMS Debug Format 36918----------------------------------- 36919 36920Here are macros for VMS debug format. 36921 36922 -- Macro: VMS_DEBUGGING_INFO 36923 Define this macro if GCC should produce debugging output for VMS 36924 in response to the `-g' option. The default behavior for VMS is 36925 to generate minimal debug info for a traceback in the absence of 36926 `-g' unless explicitly overridden with `-g0'. This behavior is 36927 controlled by `TARGET_OPTION_OPTIMIZATION' and 36928 `TARGET_OPTION_OVERRIDE'. 36929 36930 36931File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros 36932 3693317.22 Cross Compilation and Floating Point 36934========================================== 36935 36936While all modern machines use twos-complement representation for 36937integers, there are a variety of representations for floating point 36938numbers. This means that in a cross-compiler the representation of 36939floating point numbers in the compiled program may be different from 36940that used in the machine doing the compilation. 36941 36942 Because different representation systems may offer different amounts of 36943range and precision, all floating point constants must be represented in 36944the target machine's format. Therefore, the cross compiler cannot 36945safely use the host machine's floating point arithmetic; it must emulate 36946the target's arithmetic. To ensure consistency, GCC always uses 36947emulation to work with floating point values, even when the host and 36948target floating point formats are identical. 36949 36950 The following macros are provided by `real.h' for the compiler to use. 36951All parts of the compiler which generate or optimize floating-point 36952calculations must use these macros. They may evaluate their operands 36953more than once, so operands must not have side effects. 36954 36955 -- Macro: REAL_VALUE_TYPE 36956 The C data type to be used to hold a floating point value in the 36957 target machine's format. Typically this is a `struct' containing 36958 an array of `HOST_WIDE_INT', but all code should treat it as an 36959 opaque quantity. 36960 36961 -- Macro: int REAL_VALUES_EQUAL (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 36962 Compares for equality the two values, X and Y. If the target 36963 floating point format supports negative zeroes and/or NaNs, 36964 `REAL_VALUES_EQUAL (-0.0, 0.0)' is true, and `REAL_VALUES_EQUAL 36965 (NaN, NaN)' is false. 36966 36967 -- Macro: int REAL_VALUES_LESS (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 36968 Tests whether X is less than Y. 36969 36970 -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X) 36971 Truncates X to a signed integer, rounding toward zero. 36972 36973 -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX 36974 (REAL_VALUE_TYPE X) 36975 Truncates X to an unsigned integer, rounding toward zero. If X is 36976 negative, returns zero. 36977 36978 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, 36979 machine_mode MODE) 36980 Converts STRING into a floating point number in the target 36981 machine's representation for mode MODE. This routine can handle 36982 both decimal and hexadecimal floating point constants, using the 36983 syntax defined by the C language for both. 36984 36985 -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X) 36986 Returns 1 if X is negative (including negative zero), 0 otherwise. 36987 36988 -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X) 36989 Determines whether X represents infinity (positive or negative). 36990 36991 -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X) 36992 Determines whether X represents a "NaN" (not-a-number). 36993 36994 -- Macro: void REAL_ARITHMETIC (REAL_VALUE_TYPE OUTPUT, enum tree_code 36995 CODE, REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y) 36996 Calculates an arithmetic operation on the two floating point values 36997 X and Y, storing the result in OUTPUT (which must be a variable). 36998 36999 The operation to be performed is specified by CODE. Only the 37000 following codes are supported: `PLUS_EXPR', `MINUS_EXPR', 37001 `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'. 37002 37003 If `REAL_ARITHMETIC' is asked to evaluate division by zero and the 37004 target's floating point format cannot represent infinity, it will 37005 call `abort'. Callers should check for this situation first, using 37006 `MODE_HAS_INFINITIES'. *Note Storage Layout::. 37007 37008 -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X) 37009 Returns the negative of the floating point value X. 37010 37011 -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X) 37012 Returns the absolute value of X. 37013 37014 37015File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros 37016 3701717.23 Mode Switching Instructions 37018================================= 37019 37020The following macros control mode switching optimizations: 37021 37022 -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY) 37023 Define this macro if the port needs extra instructions inserted 37024 for mode switching in an optimizing compilation. 37025 37026 For an example, the SH4 can perform both single and double 37027 precision floating point operations, but to perform a single 37028 precision operation, the FPSCR PR bit has to be cleared, while for 37029 a double precision operation, this bit has to be set. Changing 37030 the PR bit requires a general purpose register as a scratch 37031 register, hence these FPSCR sets have to be inserted before 37032 reload, i.e. you can't put this into instruction emitting or 37033 `TARGET_MACHINE_DEPENDENT_REORG'. 37034 37035 You can have multiple entities that are mode-switched, and select 37036 at run time which entities actually need it. 37037 `OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY 37038 that needs mode-switching. If you define this macro, you also 37039 have to define `NUM_MODES_FOR_MODE_SWITCHING', 37040 `TARGET_MODE_NEEDED', `TARGET_MODE_PRIORITY' and 37041 `TARGET_MODE_EMIT'. `TARGET_MODE_AFTER', `TARGET_MODE_ENTRY', and 37042 `TARGET_MODE_EXIT' are optional. 37043 37044 -- Macro: NUM_MODES_FOR_MODE_SWITCHING 37045 If you define `OPTIMIZE_MODE_SWITCHING', you have to define this as 37046 initializer for an array of integers. Each initializer element N 37047 refers to an entity that needs mode switching, and specifies the 37048 number of different modes that might need to be set for this 37049 entity. The position of the initializer in the 37050 initializer--starting counting at zero--determines the integer 37051 that is used to refer to the mode-switched entity in question. In 37052 macros that take mode arguments / yield a mode result, modes are 37053 represented as numbers 0 ... N - 1. N is used to specify that no 37054 mode switch is needed / supplied. 37055 37056 -- Target Hook: void TARGET_MODE_EMIT (int ENTITY, int MODE, int 37057 PREV_MODE, HARD_REG_SET REGS_LIVE) 37058 Generate one or more insns to set ENTITY to MODE. HARD_REG_LIVE is 37059 the set of hard registers live at the point where the insn(s) are 37060 to be inserted. PREV_MOXDE indicates the mode to switch from. Sets 37061 of a lower numbered entity will be emitted before sets of a higher 37062 numbered entity to a mode of the same or lower priority. 37063 37064 -- Target Hook: int TARGET_MODE_NEEDED (int ENTITY, rtx_insn *INSN) 37065 ENTITY is an integer specifying a mode-switched entity. If 37066 `OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro 37067 to return an integer value not larger than the corresponding 37068 element in `NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that 37069 ENTITY must be switched into prior to the execution of INSN. 37070 37071 -- Target Hook: int TARGET_MODE_AFTER (int ENTITY, int MODE, rtx_insn 37072 *INSN) 37073 ENTITY is an integer specifying a mode-switched entity. If this 37074 macro is defined, it is evaluated for every INSN during mode 37075 switching. It determines the mode that an insn results in (if 37076 different from the incoming mode). 37077 37078 -- Target Hook: int TARGET_MODE_ENTRY (int ENTITY) 37079 If this macro is defined, it is evaluated for every ENTITY that 37080 needs mode switching. It should evaluate to an integer, which is 37081 a mode that ENTITY is assumed to be switched to at function entry. 37082 If `TARGET_MODE_ENTRY' is defined then `TARGET_MODE_EXIT' must be 37083 defined. 37084 37085 -- Target Hook: int TARGET_MODE_EXIT (int ENTITY) 37086 If this macro is defined, it is evaluated for every ENTITY that 37087 needs mode switching. It should evaluate to an integer, which is 37088 a mode that ENTITY is assumed to be switched to at function exit. 37089 If `TARGET_MODE_EXIT' is defined then `TARGET_MODE_ENTRY' must be 37090 defined. 37091 37092 -- Target Hook: int TARGET_MODE_PRIORITY (int ENTITY, int N) 37093 This macro specifies the order in which modes for ENTITY are 37094 processed. 0 is the highest priority, 37095 `NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest. The value 37096 of the macro should be an integer designating a mode for ENTITY. 37097 For any fixed ENTITY, `mode_priority' (ENTITY, N) shall be a 37098 bijection in 0 ... `num_modes_for_mode_switching[ENTITY] - 1'. 37099 37100 37101File: gccint.info, Node: Target Attributes, Next: Emulated TLS, Prev: Mode Switching, Up: Target Macros 37102 3710317.24 Defining target-specific uses of `__attribute__' 37104====================================================== 37105 37106Target-specific attributes may be defined for functions, data and types. 37107These are described using the following target hooks; they also need to 37108be documented in `extend.texi'. 37109 37110 -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE 37111 If defined, this target hook points to an array of `struct 37112 attribute_spec' (defined in `tree.h') specifying the machine 37113 specific attributes for this target and some of the restrictions 37114 on the entities to which these attributes are applied and the 37115 arguments they take. 37116 37117 -- Target Hook: bool TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P (const_tree 37118 NAME) 37119 If defined, this target hook is a function which returns true if 37120 the machine-specific attribute named NAME expects an identifier 37121 given as its first argument to be passed on as a plain identifier, 37122 not subjected to name lookup. If this is not defined, the default 37123 is false for all machine-specific attributes. 37124 37125 -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (const_tree TYPE1, 37126 const_tree TYPE2) 37127 If defined, this target hook is a function which returns zero if 37128 the attributes on TYPE1 and TYPE2 are incompatible, one if they 37129 are compatible, and two if they are nearly compatible (which 37130 causes a warning to be generated). If this is not defined, 37131 machine-specific attributes are supposed always to be compatible. 37132 37133 -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE) 37134 If defined, this target hook is a function which assigns default 37135 attributes to the newly defined TYPE. 37136 37137 -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree 37138 TYPE2) 37139 Define this target hook if the merging of type attributes needs 37140 special handling. If defined, the result is a list of the combined 37141 `TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that 37142 `comptypes' has already been called and returned 1. This function 37143 may call `merge_attributes' to handle machine-independent merging. 37144 37145 -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree 37146 NEWDECL) 37147 Define this target hook if the merging of decl attributes needs 37148 special handling. If defined, the result is a list of the combined 37149 `DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate 37150 declaration of OLDDECL. Examples of when this is needed are when 37151 one attribute overrides another, or when an attribute is nullified 37152 by a subsequent definition. This function may call 37153 `merge_attributes' to handle machine-independent merging. 37154 37155 If the only target-specific handling you require is `dllimport' 37156 for Microsoft Windows targets, you should define the macro 37157 `TARGET_DLLIMPORT_DECL_ATTRIBUTES' to `1'. The compiler will then 37158 define a function called `merge_dllimport_decl_attributes' which 37159 can then be defined as the expansion of 37160 `TARGET_MERGE_DECL_ATTRIBUTES'. You can also add 37161 `handle_dll_attribute' in the attribute table for your port to 37162 perform initial processing of the `dllimport' and `dllexport' 37163 attributes. This is done in `i386/cygwin.h' and `i386/i386.c', 37164 for example. 37165 37166 -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (const_tree 37167 DECL) 37168 DECL is a variable or function with `__attribute__((dllimport))' 37169 specified. Use this hook if the target needs to add extra 37170 validation checks to `handle_dll_attribute'. 37171 37172 -- Macro: TARGET_DECLSPEC 37173 Define this macro to a nonzero value if you want to treat 37174 `__declspec(X)' as equivalent to `__attribute((X))'. By default, 37175 this behavior is enabled only for targets that define 37176 `TARGET_DLLIMPORT_DECL_ATTRIBUTES'. The current implementation of 37177 `__declspec' is via a built-in macro, but you should not rely on 37178 this implementation detail. 37179 37180 -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree 37181 *ATTR_PTR) 37182 Define this target hook if you want to be able to add attributes 37183 to a decl when it is being created. This is normally useful for 37184 back ends which wish to implement a pragma by using the attributes 37185 which correspond to the pragma's effect. The NODE argument is the 37186 decl which is being created. The ATTR_PTR argument is a pointer 37187 to the attribute list for this decl. The list itself should not 37188 be modified, since it may be shared with other decls, but 37189 attributes may be chained on the head of the list and `*ATTR_PTR' 37190 modified to point to the new attributes, or a copy of the list may 37191 be made if further changes are needed. 37192 37193 -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (const_tree 37194 FNDECL) 37195 This target hook returns `true' if it is OK to inline FNDECL into 37196 the current function, despite its having target-specific 37197 attributes, `false' otherwise. By default, if a function has a 37198 target specific attribute attached to it, it will not be inlined. 37199 37200 -- Target Hook: bool TARGET_OPTION_VALID_ATTRIBUTE_P (tree FNDECL, 37201 tree NAME, tree ARGS, int FLAGS) 37202 This hook is called to parse `attribute(target("..."))', which 37203 allows setting target-specific options on individual functions. 37204 These function-specific options may differ from the options 37205 specified on the command line. The hook should return `true' if 37206 the options are valid. 37207 37208 The hook should set the `DECL_FUNCTION_SPECIFIC_TARGET' field in 37209 the function declaration to hold a pointer to a target-specific 37210 `struct cl_target_option' structure. 37211 37212 -- Target Hook: void TARGET_OPTION_SAVE (struct cl_target_option *PTR, 37213 struct gcc_options *OPTS) 37214 This hook is called to save any additional target-specific 37215 information in the `struct cl_target_option' structure for 37216 function-specific options from the `struct gcc_options' structure. 37217 *Note Option file format::. 37218 37219 -- Target Hook: void TARGET_OPTION_RESTORE (struct gcc_options *OPTS, 37220 struct cl_target_option *PTR) 37221 This hook is called to restore any additional target-specific 37222 information in the `struct cl_target_option' structure for 37223 function-specific options to the `struct gcc_options' structure. 37224 37225 -- Target Hook: void TARGET_OPTION_POST_STREAM_IN (struct 37226 cl_target_option *PTR) 37227 This hook is called to update target-specific information in the 37228 `struct cl_target_option' structure after it is streamed in from 37229 LTO bytecode. 37230 37231 -- Target Hook: void TARGET_OPTION_PRINT (FILE *FILE, int INDENT, 37232 struct cl_target_option *PTR) 37233 This hook is called to print any additional target-specific 37234 information in the `struct cl_target_option' structure for 37235 function-specific options. 37236 37237 -- Target Hook: bool TARGET_OPTION_PRAGMA_PARSE (tree ARGS, tree 37238 POP_TARGET) 37239 This target hook parses the options for `#pragma GCC target', which 37240 sets the target-specific options for functions that occur later in 37241 the input stream. The options accepted should be the same as 37242 those handled by the `TARGET_OPTION_VALID_ATTRIBUTE_P' hook. 37243 37244 -- Target Hook: void TARGET_OPTION_OVERRIDE (void) 37245 Sometimes certain combinations of command options do not make 37246 sense on a particular target machine. You can override the hook 37247 `TARGET_OPTION_OVERRIDE' to take account of this. This hooks is 37248 called once just after all the command options have been parsed. 37249 37250 Don't use this hook to turn on various extra optimizations for 37251 `-O'. That is what `TARGET_OPTION_OPTIMIZATION' is for. 37252 37253 If you need to do something whenever the optimization level is 37254 changed via the optimize attribute or pragma, see 37255 `TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE' 37256 37257 -- Target Hook: bool TARGET_OPTION_FUNCTION_VERSIONS (tree DECL1, tree 37258 DECL2) 37259 This target hook returns `true' if DECL1 and DECL2 are versions of 37260 the same function. DECL1 and DECL2 are function versions if and 37261 only if they have the same function signature and different target 37262 specific attributes, that is, they are compiled for different 37263 target machines. 37264 37265 -- Target Hook: bool TARGET_CAN_INLINE_P (tree CALLER, tree CALLEE) 37266 This target hook returns `false' if the CALLER function cannot 37267 inline CALLEE, based on target specific information. By default, 37268 inlining is not allowed if the callee function has function 37269 specific target options and the caller does not use the same 37270 options. 37271 37272 37273File: gccint.info, Node: Emulated TLS, Next: MIPS Coprocessors, Prev: Target Attributes, Up: Target Macros 37274 3727517.25 Emulating TLS 37276=================== 37277 37278For targets whose psABI does not provide Thread Local Storage via 37279specific relocations and instruction sequences, an emulation layer is 37280used. A set of target hooks allows this emulation layer to be 37281configured for the requirements of a particular target. For instance 37282the psABI may in fact specify TLS support in terms of an emulation 37283layer. 37284 37285 The emulation layer works by creating a control object for every TLS 37286object. To access the TLS object, a lookup function is provided which, 37287when given the address of the control object, will return the address 37288of the current thread's instance of the TLS object. 37289 37290 -- Target Hook: const char * TARGET_EMUTLS_GET_ADDRESS 37291 Contains the name of the helper function that uses a TLS control 37292 object to locate a TLS instance. The default causes libgcc's 37293 emulated TLS helper function to be used. 37294 37295 -- Target Hook: const char * TARGET_EMUTLS_REGISTER_COMMON 37296 Contains the name of the helper function that should be used at 37297 program startup to register TLS objects that are implicitly 37298 initialized to zero. If this is `NULL', all TLS objects will have 37299 explicit initializers. The default causes libgcc's emulated TLS 37300 registration function to be used. 37301 37302 -- Target Hook: const char * TARGET_EMUTLS_VAR_SECTION 37303 Contains the name of the section in which TLS control variables 37304 should be placed. The default of `NULL' allows these to be placed 37305 in any section. 37306 37307 -- Target Hook: const char * TARGET_EMUTLS_TMPL_SECTION 37308 Contains the name of the section in which TLS initializers should 37309 be placed. The default of `NULL' allows these to be placed in any 37310 section. 37311 37312 -- Target Hook: const char * TARGET_EMUTLS_VAR_PREFIX 37313 Contains the prefix to be prepended to TLS control variable names. 37314 The default of `NULL' uses a target-specific prefix. 37315 37316 -- Target Hook: const char * TARGET_EMUTLS_TMPL_PREFIX 37317 Contains the prefix to be prepended to TLS initializer objects. 37318 The default of `NULL' uses a target-specific prefix. 37319 37320 -- Target Hook: tree TARGET_EMUTLS_VAR_FIELDS (tree TYPE, tree *NAME) 37321 Specifies a function that generates the FIELD_DECLs for a TLS 37322 control object type. TYPE is the RECORD_TYPE the fields are for 37323 and NAME should be filled with the structure tag, if the default of 37324 `__emutls_object' is unsuitable. The default creates a type 37325 suitable for libgcc's emulated TLS function. 37326 37327 -- Target Hook: tree TARGET_EMUTLS_VAR_INIT (tree VAR, tree DECL, tree 37328 TMPL_ADDR) 37329 Specifies a function that generates the CONSTRUCTOR to initialize a 37330 TLS control object. VAR is the TLS control object, DECL is the 37331 TLS object and TMPL_ADDR is the address of the initializer. The 37332 default initializes libgcc's emulated TLS control object. 37333 37334 -- Target Hook: bool TARGET_EMUTLS_VAR_ALIGN_FIXED 37335 Specifies whether the alignment of TLS control variable objects is 37336 fixed and should not be increased as some backends may do to 37337 optimize single objects. The default is false. 37338 37339 -- Target Hook: bool TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS 37340 Specifies whether a DWARF `DW_OP_form_tls_address' location 37341 descriptor may be used to describe emulated TLS control objects. 37342 37343 37344File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Emulated TLS, Up: Target Macros 37345 3734617.26 Defining coprocessor specifics for MIPS targets. 37347====================================================== 37348 37349The MIPS specification allows MIPS implementations to have as many as 4 37350coprocessors, each with as many as 32 private registers. GCC supports 37351accessing these registers and transferring values between the registers 37352and memory using asm-ized variables. For example: 37353 37354 register unsigned int cp0count asm ("c0r1"); 37355 unsigned int d; 37356 37357 d = cp0count + 3; 37358 37359 ("c0r1" is the default name of register 1 in coprocessor 0; alternate 37360names may be added as described below, or the default names may be 37361overridden entirely in `SUBTARGET_CONDITIONAL_REGISTER_USAGE'.) 37362 37363 Coprocessor registers are assumed to be epilogue-used; sets to them 37364will be preserved even if it does not appear that the register is used 37365again later in the function. 37366 37367 Another note: according to the MIPS spec, coprocessor 1 (if present) is 37368the FPU. One accesses COP1 registers through standard mips 37369floating-point support; they are not included in this mechanism. 37370 37371 37372File: gccint.info, Node: PCH Target, Next: C++ ABI, Prev: MIPS Coprocessors, Up: Target Macros 37373 3737417.27 Parameters for Precompiled Header Validity Checking 37375========================================================= 37376 37377 -- Target Hook: void * TARGET_GET_PCH_VALIDITY (size_t *SZ) 37378 This hook returns a pointer to the data needed by 37379 `TARGET_PCH_VALID_P' and sets `*SZ' to the size of the data in 37380 bytes. 37381 37382 -- Target Hook: const char * TARGET_PCH_VALID_P (const void *DATA, 37383 size_t SZ) 37384 This hook checks whether the options used to create a PCH file are 37385 compatible with the current settings. It returns `NULL' if so and 37386 a suitable error message if not. Error messages will be presented 37387 to the user and must be localized using `_(MSG)'. 37388 37389 DATA is the data that was returned by `TARGET_GET_PCH_VALIDITY' 37390 when the PCH file was created and SZ is the size of that data in 37391 bytes. It's safe to assume that the data was created by the same 37392 version of the compiler, so no format checking is needed. 37393 37394 The default definition of `default_pch_valid_p' should be suitable 37395 for most targets. 37396 37397 -- Target Hook: const char * TARGET_CHECK_PCH_TARGET_FLAGS (int 37398 PCH_FLAGS) 37399 If this hook is nonnull, the default implementation of 37400 `TARGET_PCH_VALID_P' will use it to check for compatible values of 37401 `target_flags'. PCH_FLAGS specifies the value that `target_flags' 37402 had when the PCH file was created. The return value is the same 37403 as for `TARGET_PCH_VALID_P'. 37404 37405 -- Target Hook: void TARGET_PREPARE_PCH_SAVE (void) 37406 Called before writing out a PCH file. If the target has some 37407 garbage-collected data that needs to be in a particular state on 37408 PCH loads, it can use this hook to enforce that state. Very few 37409 targets need to do anything here. 37410 37411 37412File: gccint.info, Node: C++ ABI, Next: Named Address Spaces, Prev: PCH Target, Up: Target Macros 37413 3741417.28 C++ ABI parameters 37415======================== 37416 37417 -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void) 37418 Define this hook to override the integer type used for guard 37419 variables. These are used to implement one-time construction of 37420 static objects. The default is long_long_integer_type_node. 37421 37422 -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void) 37423 This hook determines how guard variables are used. It should 37424 return `false' (the default) if the first byte should be used. A 37425 return value of `true' indicates that only the least significant 37426 bit should be used. 37427 37428 -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE) 37429 This hook returns the size of the cookie to use when allocating an 37430 array whose elements have the indicated TYPE. Assumes that it is 37431 already known that a cookie is needed. The default is `max(sizeof 37432 (size_t), alignof(type))', as defined in section 2.7 of the 37433 IA64/Generic C++ ABI. 37434 37435 -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void) 37436 This hook should return `true' if the element size should be 37437 stored in array cookies. The default is to return `false'. 37438 37439 -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int 37440 IMPORT_EXPORT) 37441 If defined by a backend this hook allows the decision made to 37442 export class TYPE to be overruled. Upon entry IMPORT_EXPORT will 37443 contain 1 if the class is going to be exported, -1 if it is going 37444 to be imported and 0 otherwise. This function should return the 37445 modified value and perform any other actions necessary to support 37446 the backend's targeted operating system. 37447 37448 -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void) 37449 This hook should return `true' if constructors and destructors 37450 return the address of the object created/destroyed. The default 37451 is to return `false'. 37452 37453 -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void) 37454 This hook returns true if the key method for a class (i.e., the 37455 method which, if defined in the current translation unit, causes 37456 the virtual table to be emitted) may be an inline function. Under 37457 the standard Itanium C++ ABI the key method may be an inline 37458 function so long as the function is not declared inline in the 37459 class definition. Under some variants of the ABI, an inline 37460 function can never be the key method. The default is to return 37461 `true'. 37462 37463 -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree 37464 DECL) 37465 DECL is a virtual table, virtual table table, typeinfo object, or 37466 other similar implicit class data object that will be emitted with 37467 external linkage in this translation unit. No ELF visibility has 37468 been explicitly specified. If the target needs to specify a 37469 visibility other than that of the containing class, use this hook 37470 to set `DECL_VISIBILITY' and `DECL_VISIBILITY_SPECIFIED'. 37471 37472 -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void) 37473 This hook returns true (the default) if virtual tables and other 37474 similar implicit class data objects are always COMDAT if they have 37475 external linkage. If this hook returns false, then class data for 37476 classes whose virtual table will be emitted in only one translation 37477 unit will not be COMDAT. 37478 37479 -- Target Hook: bool TARGET_CXX_LIBRARY_RTTI_COMDAT (void) 37480 This hook returns true (the default) if the RTTI information for 37481 the basic types which is defined in the C++ runtime should always 37482 be COMDAT, false if it should not be COMDAT. 37483 37484 -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void) 37485 This hook returns true if `__aeabi_atexit' (as defined by the ARM 37486 EABI) should be used to register static destructors when 37487 `-fuse-cxa-atexit' is in effect. The default is to return false 37488 to use `__cxa_atexit'. 37489 37490 -- Target Hook: bool TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT (void) 37491 This hook returns true if the target `atexit' function can be used 37492 in the same manner as `__cxa_atexit' to register C++ static 37493 destructors. This requires that `atexit'-registered functions in 37494 shared libraries are run in the correct order when the libraries 37495 are unloaded. The default is to return false. 37496 37497 -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE) 37498 TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has 37499 just been defined. Use this hook to make adjustments to the class 37500 (eg, tweak visibility or perform any other required target 37501 modifications). 37502 37503 -- Target Hook: tree TARGET_CXX_DECL_MANGLING_CONTEXT (const_tree DECL) 37504 Return target-specific mangling context of DECL or `NULL_TREE'. 37505 37506 37507File: gccint.info, Node: Named Address Spaces, Next: Misc, Prev: C++ ABI, Up: Target Macros 37508 3750917.29 Adding support for named address spaces 37510============================================= 37511 37512The draft technical report of the ISO/IEC JTC1 S22 WG14 N1275 standards 37513committee, `Programming Languages - C - Extensions to support embedded 37514processors', specifies a syntax for embedded processors to specify 37515alternate address spaces. You can configure a GCC port to support 37516section 5.1 of the draft report to add support for address spaces other 37517than the default address space. These address spaces are new keywords 37518that are similar to the `volatile' and `const' type attributes. 37519 37520 Pointers to named address spaces can have a different size than 37521pointers to the generic address space. 37522 37523 For example, the SPU port uses the `__ea' address space to refer to 37524memory in the host processor, rather than memory local to the SPU 37525processor. Access to memory in the `__ea' address space involves 37526issuing DMA operations to move data between the host processor and the 37527local processor memory address space. Pointers in the `__ea' address 37528space are either 32 bits or 64 bits based on the `-mea32' or `-mea64' 37529switches (native SPU pointers are always 32 bits). 37530 37531 Internally, address spaces are represented as a small integer in the 37532range 0 to 15 with address space 0 being reserved for the generic 37533address space. 37534 37535 To register a named address space qualifier keyword with the C front 37536end, the target may call the `c_register_addr_space' routine. For 37537example, the SPU port uses the following to declare `__ea' as the 37538keyword for named address space #1: 37539 #define ADDR_SPACE_EA 1 37540 c_register_addr_space ("__ea", ADDR_SPACE_EA); 37541 37542 -- Target Hook: machine_mode TARGET_ADDR_SPACE_POINTER_MODE 37543 (addr_space_t ADDRESS_SPACE) 37544 Define this to return the machine mode to use for pointers to 37545 ADDRESS_SPACE if the target supports named address spaces. The 37546 default version of this hook returns `ptr_mode' for the generic 37547 address space only. 37548 37549 -- Target Hook: machine_mode TARGET_ADDR_SPACE_ADDRESS_MODE 37550 (addr_space_t ADDRESS_SPACE) 37551 Define this to return the machine mode to use for addresses in 37552 ADDRESS_SPACE if the target supports named address spaces. The 37553 default version of this hook returns `Pmode' for the generic 37554 address space only. 37555 37556 -- Target Hook: bool TARGET_ADDR_SPACE_VALID_POINTER_MODE 37557 (machine_mode MODE, addr_space_t AS) 37558 Define this to return nonzero if the port can handle pointers with 37559 machine mode MODE to address space AS. This target hook is the 37560 same as the `TARGET_VALID_POINTER_MODE' target hook, except that 37561 it includes explicit named address space support. The default 37562 version of this hook returns true for the modes returned by either 37563 the `TARGET_ADDR_SPACE_POINTER_MODE' or 37564 `TARGET_ADDR_SPACE_ADDRESS_MODE' target hooks for the given 37565 address space. 37566 37567 -- Target Hook: bool TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P 37568 (machine_mode MODE, rtx EXP, bool STRICT, addr_space_t AS) 37569 Define this to return true if EXP is a valid address for mode MODE 37570 in the named address space AS. The STRICT parameter says whether 37571 strict addressing is in effect after reload has finished. This 37572 target hook is the same as the `TARGET_LEGITIMATE_ADDRESS_P' 37573 target hook, except that it includes explicit named address space 37574 support. 37575 37576 -- Target Hook: rtx TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS (rtx X, rtx 37577 OLDX, machine_mode MODE, addr_space_t AS) 37578 Define this to modify an invalid address X to be a valid address 37579 with mode MODE in the named address space AS. This target hook is 37580 the same as the `TARGET_LEGITIMIZE_ADDRESS' target hook, except 37581 that it includes explicit named address space support. 37582 37583 -- Target Hook: bool TARGET_ADDR_SPACE_SUBSET_P (addr_space_t SUBSET, 37584 addr_space_t SUPERSET) 37585 Define this to return whether the SUBSET named address space is 37586 contained within the SUPERSET named address space. Pointers to a 37587 named address space that is a subset of another named address space 37588 will be converted automatically without a cast if used together in 37589 arithmetic operations. Pointers to a superset address space can be 37590 converted to pointers to a subset address space via explicit casts. 37591 37592 -- Target Hook: rtx TARGET_ADDR_SPACE_CONVERT (rtx OP, tree FROM_TYPE, 37593 tree TO_TYPE) 37594 Define this to convert the pointer expression represented by the 37595 RTL OP with type FROM_TYPE that points to a named address space to 37596 a new pointer expression with type TO_TYPE that points to a 37597 different named address space. When this hook it called, it is 37598 guaranteed that one of the two address spaces is a subset of the 37599 other, as determined by the `TARGET_ADDR_SPACE_SUBSET_P' target 37600 hook. 37601 37602 37603File: gccint.info, Node: Misc, Prev: Named Address Spaces, Up: Target Macros 37604 3760517.30 Miscellaneous Parameters 37606============================== 37607 37608Here are several miscellaneous parameters. 37609 37610 -- Macro: HAS_LONG_COND_BRANCH 37611 Define this boolean macro to indicate whether or not your 37612 architecture has conditional branches that can span all of memory. 37613 It is used in conjunction with an optimization that partitions hot 37614 and cold basic blocks into separate sections of the executable. 37615 If this macro is set to false, gcc will convert any conditional 37616 branches that attempt to cross between sections into unconditional 37617 branches or indirect jumps. 37618 37619 -- Macro: HAS_LONG_UNCOND_BRANCH 37620 Define this boolean macro to indicate whether or not your 37621 architecture has unconditional branches that can span all of 37622 memory. It is used in conjunction with an optimization that 37623 partitions hot and cold basic blocks into separate sections of the 37624 executable. If this macro is set to false, gcc will convert any 37625 unconditional branches that attempt to cross between sections into 37626 indirect jumps. 37627 37628 -- Macro: CASE_VECTOR_MODE 37629 An alias for a machine mode name. This is the machine mode that 37630 elements of a jump-table should have. 37631 37632 -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY) 37633 Optional: return the preferred mode for an `addr_diff_vec' when 37634 the minimum and maximum offset are known. If you define this, it 37635 enables extra code in branch shortening to deal with 37636 `addr_diff_vec'. To make this work, you also have to define 37637 `INSN_ALIGN' and make the alignment for `addr_diff_vec' explicit. 37638 The BODY argument is provided so that the offset_unsigned and scale 37639 flags can be updated. 37640 37641 -- Macro: CASE_VECTOR_PC_RELATIVE 37642 Define this macro to be a C expression to indicate when jump-tables 37643 should contain relative addresses. You need not define this macro 37644 if jump-tables never contain relative addresses, or jump-tables 37645 should contain relative addresses only when `-fPIC' or `-fPIC' is 37646 in effect. 37647 37648 -- Target Hook: unsigned int TARGET_CASE_VALUES_THRESHOLD (void) 37649 This function return the smallest number of different values for 37650 which it is best to use a jump-table instead of a tree of 37651 conditional branches. The default is four for machines with a 37652 `casesi' instruction and five otherwise. This is best for most 37653 machines. 37654 37655 -- Macro: WORD_REGISTER_OPERATIONS 37656 Define this macro if operations between registers with integral 37657 mode smaller than a word are always performed on the entire 37658 register. Most RISC machines have this property and most CISC 37659 machines do not. 37660 37661 -- Macro: LOAD_EXTEND_OP (MEM_MODE) 37662 Define this macro to be a C expression indicating when insns that 37663 read memory in MEM_MODE, an integral mode narrower than a word, 37664 set the bits outside of MEM_MODE to be either the sign-extension 37665 or the zero-extension of the data read. Return `SIGN_EXTEND' for 37666 values of MEM_MODE for which the insn sign-extends, `ZERO_EXTEND' 37667 for which it zero-extends, and `UNKNOWN' for other modes. 37668 37669 This macro is not called with MEM_MODE non-integral or with a width 37670 greater than or equal to `BITS_PER_WORD', so you may return any 37671 value in this case. Do not define this macro if it would always 37672 return `UNKNOWN'. On machines where this macro is defined, you 37673 will normally define it as the constant `SIGN_EXTEND' or 37674 `ZERO_EXTEND'. 37675 37676 You may return a non-`UNKNOWN' value even if for some hard 37677 registers the sign extension is not performed, if for the 37678 `REGNO_REG_CLASS' of these hard registers 37679 `CANNOT_CHANGE_MODE_CLASS' returns nonzero when the FROM mode is 37680 MEM_MODE and the TO mode is any integral mode larger than this but 37681 not larger than `word_mode'. 37682 37683 You must return `UNKNOWN' if for some hard registers that allow 37684 this mode, `CANNOT_CHANGE_MODE_CLASS' says that they cannot change 37685 to `word_mode', but that they can change to another integral mode 37686 that is larger then MEM_MODE but still smaller than `word_mode'. 37687 37688 -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND 37689 Define this macro if loading short immediate values into registers 37690 sign extends. 37691 37692 -- Target Hook: unsigned int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL 37693 (machine_mode MODE) 37694 When `-ffast-math' is in effect, GCC tries to optimize divisions 37695 by the same divisor, by turning them into multiplications by the 37696 reciprocal. This target hook specifies the minimum number of 37697 divisions that should be there for GCC to perform the optimization 37698 for a variable of mode MODE. The default implementation returns 3 37699 if the machine has an instruction for the division, and 2 if it 37700 does not. 37701 37702 -- Macro: MOVE_MAX 37703 The maximum number of bytes that a single instruction can move 37704 quickly between memory and registers or between two memory 37705 locations. 37706 37707 -- Macro: MAX_MOVE_MAX 37708 The maximum number of bytes that a single instruction can move 37709 quickly between memory and registers or between two memory 37710 locations. If this is undefined, the default is `MOVE_MAX'. 37711 Otherwise, it is the constant value that is the largest value that 37712 `MOVE_MAX' can have at run-time. 37713 37714 -- Macro: SHIFT_COUNT_TRUNCATED 37715 A C expression that is nonzero if on this machine the number of 37716 bits actually used for the count of a shift operation is equal to 37717 the number of bits needed to represent the size of the object 37718 being shifted. When this macro is nonzero, the compiler will 37719 assume that it is safe to omit a sign-extend, zero-extend, and 37720 certain bitwise `and' instructions that truncates the count of a 37721 shift operation. On machines that have instructions that act on 37722 bit-fields at variable positions, which may include `bit test' 37723 instructions, a nonzero `SHIFT_COUNT_TRUNCATED' also enables 37724 deletion of truncations of the values that serve as arguments to 37725 bit-field instructions. 37726 37727 If both types of instructions truncate the count (for shifts) and 37728 position (for bit-field operations), or if no variable-position 37729 bit-field instructions exist, you should define this macro. 37730 37731 However, on some machines, such as the 80386 and the 680x0, 37732 truncation only applies to shift operations and not the (real or 37733 pretended) bit-field operations. Define `SHIFT_COUNT_TRUNCATED' 37734 to be zero on such machines. Instead, add patterns to the `md' 37735 file that include the implied truncation of the shift instructions. 37736 37737 You need not define this macro if it would always have the value 37738 of zero. 37739 37740 -- Target Hook: unsigned HOST_WIDE_INT TARGET_SHIFT_TRUNCATION_MASK 37741 (machine_mode MODE) 37742 This function describes how the standard shift patterns for MODE 37743 deal with shifts by negative amounts or by more than the width of 37744 the mode. *Note shift patterns::. 37745 37746 On many machines, the shift patterns will apply a mask M to the 37747 shift count, meaning that a fixed-width shift of X by Y is 37748 equivalent to an arbitrary-width shift of X by Y & M. If this is 37749 true for mode MODE, the function should return M, otherwise it 37750 should return 0. A return value of 0 indicates that no particular 37751 behavior is guaranteed. 37752 37753 Note that, unlike `SHIFT_COUNT_TRUNCATED', this function does 37754 _not_ apply to general shift rtxes; it applies only to instructions 37755 that are generated by the named shift patterns. 37756 37757 The default implementation of this function returns 37758 `GET_MODE_BITSIZE (MODE) - 1' if `SHIFT_COUNT_TRUNCATED' and 0 37759 otherwise. This definition is always safe, but if 37760 `SHIFT_COUNT_TRUNCATED' is false, and some shift patterns 37761 nevertheless truncate the shift count, you may get better code by 37762 overriding it. 37763 37764 -- Macro: TRULY_NOOP_TRUNCATION (OUTPREC, INPREC) 37765 A C expression which is nonzero if on this machine it is safe to 37766 "convert" an integer of INPREC bits to one of OUTPREC bits (where 37767 OUTPREC is smaller than INPREC) by merely operating on it as if it 37768 had only OUTPREC bits. 37769 37770 On many machines, this expression can be 1. 37771 37772 When `TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for 37773 modes for which `MODES_TIEABLE_P' is 0, suboptimal code can result. 37774 If this is the case, making `TRULY_NOOP_TRUNCATION' return 0 in 37775 such cases may improve things. 37776 37777 -- Target Hook: int TARGET_MODE_REP_EXTENDED (machine_mode MODE, 37778 machine_mode REP_MODE) 37779 The representation of an integral mode can be such that the values 37780 are always extended to a wider integral mode. Return 37781 `SIGN_EXTEND' if values of MODE are represented in sign-extended 37782 form to REP_MODE. Return `UNKNOWN' otherwise. (Currently, none 37783 of the targets use zero-extended representation this way so unlike 37784 `LOAD_EXTEND_OP', `TARGET_MODE_REP_EXTENDED' is expected to return 37785 either `SIGN_EXTEND' or `UNKNOWN'. Also no target extends MODE to 37786 REP_MODE so that REP_MODE is not the next widest integral mode and 37787 currently we take advantage of this fact.) 37788 37789 Similarly to `LOAD_EXTEND_OP' you may return a non-`UNKNOWN' value 37790 even if the extension is not performed on certain hard registers 37791 as long as for the `REGNO_REG_CLASS' of these hard registers 37792 `CANNOT_CHANGE_MODE_CLASS' returns nonzero. 37793 37794 Note that `TARGET_MODE_REP_EXTENDED' and `LOAD_EXTEND_OP' describe 37795 two related properties. If you define `TARGET_MODE_REP_EXTENDED 37796 (mode, word_mode)' you probably also want to define 37797 `LOAD_EXTEND_OP (mode)' to return the same type of extension. 37798 37799 In order to enforce the representation of `mode', 37800 `TRULY_NOOP_TRUNCATION' should return false when truncating to 37801 `mode'. 37802 37803 -- Macro: STORE_FLAG_VALUE 37804 A C expression describing the value returned by a comparison 37805 operator with an integral mode and stored by a store-flag 37806 instruction (`cstoreMODE4') when the condition is true. This 37807 description must apply to _all_ the `cstoreMODE4' patterns and all 37808 the comparison operators whose results have a `MODE_INT' mode. 37809 37810 A value of 1 or -1 means that the instruction implementing the 37811 comparison operator returns exactly 1 or -1 when the comparison is 37812 true and 0 when the comparison is false. Otherwise, the value 37813 indicates which bits of the result are guaranteed to be 1 when the 37814 comparison is true. This value is interpreted in the mode of the 37815 comparison operation, which is given by the mode of the first 37816 operand in the `cstoreMODE4' pattern. Either the low bit or the 37817 sign bit of `STORE_FLAG_VALUE' be on. Presently, only those bits 37818 are used by the compiler. 37819 37820 If `STORE_FLAG_VALUE' is neither 1 or -1, the compiler will 37821 generate code that depends only on the specified bits. It can also 37822 replace comparison operators with equivalent operations if they 37823 cause the required bits to be set, even if the remaining bits are 37824 undefined. For example, on a machine whose comparison operators 37825 return an `SImode' value and where `STORE_FLAG_VALUE' is defined as 37826 `0x80000000', saying that just the sign bit is relevant, the 37827 expression 37828 37829 (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0)) 37830 37831 can be converted to 37832 37833 (ashift:SI X (const_int N)) 37834 37835 where N is the appropriate shift count to move the bit being 37836 tested into the sign bit. 37837 37838 There is no way to describe a machine that always sets the 37839 low-order bit for a true value, but does not guarantee the value 37840 of any other bits, but we do not know of any machine that has such 37841 an instruction. If you are trying to port GCC to such a machine, 37842 include an instruction to perform a logical-and of the result with 37843 1 in the pattern for the comparison operators and let us know at 37844 <gcc@gcc.gnu.org>. 37845 37846 Often, a machine will have multiple instructions that obtain a 37847 value from a comparison (or the condition codes). Here are rules 37848 to guide the choice of value for `STORE_FLAG_VALUE', and hence the 37849 instructions to be used: 37850 37851 * Use the shortest sequence that yields a valid definition for 37852 `STORE_FLAG_VALUE'. It is more efficient for the compiler to 37853 "normalize" the value (convert it to, e.g., 1 or 0) than for 37854 the comparison operators to do so because there may be 37855 opportunities to combine the normalization with other 37856 operations. 37857 37858 * For equal-length sequences, use a value of 1 or -1, with -1 37859 being slightly preferred on machines with expensive jumps and 37860 1 preferred on other machines. 37861 37862 * As a second choice, choose a value of `0x80000001' if 37863 instructions exist that set both the sign and low-order bits 37864 but do not define the others. 37865 37866 * Otherwise, use a value of `0x80000000'. 37867 37868 Many machines can produce both the value chosen for 37869 `STORE_FLAG_VALUE' and its negation in the same number of 37870 instructions. On those machines, you should also define a pattern 37871 for those cases, e.g., one matching 37872 37873 (set A (neg:M (ne:M B C))) 37874 37875 Some machines can also perform `and' or `plus' operations on 37876 condition code values with less instructions than the corresponding 37877 `cstoreMODE4' insn followed by `and' or `plus'. On those 37878 machines, define the appropriate patterns. Use the names `incscc' 37879 and `decscc', respectively, for the patterns which perform `plus' 37880 or `minus' operations on condition code values. See `rs6000.md' 37881 for some examples. The GNU Superoptimizer can be used to find 37882 such instruction sequences on other machines. 37883 37884 If this macro is not defined, the default value, 1, is used. You 37885 need not define `STORE_FLAG_VALUE' if the machine has no store-flag 37886 instructions, or if the value generated by these instructions is 1. 37887 37888 -- Macro: FLOAT_STORE_FLAG_VALUE (MODE) 37889 A C expression that gives a nonzero `REAL_VALUE_TYPE' value that is 37890 returned when comparison operators with floating-point results are 37891 true. Define this macro on machines that have comparison 37892 operations that return floating-point values. If there are no 37893 such operations, do not define this macro. 37894 37895 -- Macro: VECTOR_STORE_FLAG_VALUE (MODE) 37896 A C expression that gives a rtx representing the nonzero true 37897 element for vector comparisons. The returned rtx should be valid 37898 for the inner mode of MODE which is guaranteed to be a vector 37899 mode. Define this macro on machines that have vector comparison 37900 operations that return a vector result. If there are no such 37901 operations, do not define this macro. Typically, this macro is 37902 defined as `const1_rtx' or `constm1_rtx'. This macro may return 37903 `NULL_RTX' to prevent the compiler optimizing such vector 37904 comparison operations for the given mode. 37905 37906 -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 37907 -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) 37908 A C expression that indicates whether the architecture defines a 37909 value for `clz' or `ctz' with a zero operand. A result of `0' 37910 indicates the value is undefined. If the value is defined for 37911 only the RTL expression, the macro should evaluate to `1'; if the 37912 value applies also to the corresponding optab entry (which is 37913 normally the case if it expands directly into the corresponding 37914 RTL), then the macro should evaluate to `2'. In the cases where 37915 the value is defined, VALUE should be set to this value. 37916 37917 If this macro is not defined, the value of `clz' or `ctz' at zero 37918 is assumed to be undefined. 37919 37920 This macro must be defined if the target's expansion for `ffs' 37921 relies on a particular value to get correct results. Otherwise it 37922 is not necessary, though it may be used to optimize some corner 37923 cases, and to provide a default expansion for the `ffs' optab. 37924 37925 Note that regardless of this macro the "definedness" of `clz' and 37926 `ctz' at zero do _not_ extend to the builtin functions visible to 37927 the user. Thus one may be free to adjust the value at will to 37928 match the target expansion of these operations without fear of 37929 breaking the API. 37930 37931 -- Macro: Pmode 37932 An alias for the machine mode for pointers. On most machines, 37933 define this to be the integer mode corresponding to the width of a 37934 hardware pointer; `SImode' on 32-bit machine or `DImode' on 64-bit 37935 machines. On some machines you must define this to be one of the 37936 partial integer modes, such as `PSImode'. 37937 37938 The width of `Pmode' must be at least as large as the value of 37939 `POINTER_SIZE'. If it is not equal, you must define the macro 37940 `POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to 37941 `Pmode'. 37942 37943 -- Macro: FUNCTION_MODE 37944 An alias for the machine mode used for memory references to 37945 functions being called, in `call' RTL expressions. On most CISC 37946 machines, where an instruction can begin at any byte address, this 37947 should be `QImode'. On most RISC machines, where all instructions 37948 have fixed size and alignment, this should be a mode with the same 37949 size and alignment as the machine instruction words - typically 37950 `SImode' or `HImode'. 37951 37952 -- Macro: STDC_0_IN_SYSTEM_HEADERS 37953 In normal operation, the preprocessor expands `__STDC__' to the 37954 constant 1, to signify that GCC conforms to ISO Standard C. On 37955 some hosts, like Solaris, the system compiler uses a different 37956 convention, where `__STDC__' is normally 0, but is 1 if the user 37957 specifies strict conformance to the C Standard. 37958 37959 Defining `STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host 37960 convention when processing system header files, but when 37961 processing user files `__STDC__' will always expand to 1. 37962 37963 -- C Target Hook: const char * TARGET_C_PREINCLUDE (void) 37964 Define this hook to return the name of a header file to be 37965 included at the start of all compilations, as if it had been 37966 included with `#include <FILE>'. If this hook returns `NULL', or 37967 is not defined, or the header is not found, or if the user 37968 specifies `-ffreestanding' or `-nostdinc', no header is included. 37969 37970 This hook can be used together with a header provided by the 37971 system C library to implement ISO C requirements for certain 37972 macros to be predefined that describe properties of the whole 37973 implementation rather than just the compiler. 37974 37975 -- C Target Hook: bool TARGET_CXX_IMPLICIT_EXTERN_C (const char*) 37976 Define this hook to add target-specific C++ implicit extern C 37977 functions. If this function returns true for the name of a 37978 file-scope function, that function implicitly gets extern "C" 37979 linkage rather than whatever language linkage the declaration 37980 would normally have. An example of such function is WinMain on 37981 Win32 targets. 37982 37983 -- Macro: NO_IMPLICIT_EXTERN_C 37984 Define this macro if the system header files support C++ as well 37985 as C. This macro inhibits the usual method of using system header 37986 files in C++, which is to pretend that the file's contents are 37987 enclosed in `extern "C" {...}'. 37988 37989 -- Macro: REGISTER_TARGET_PRAGMAS () 37990 Define this macro if you want to implement any target-specific 37991 pragmas. If defined, it is a C expression which makes a series of 37992 calls to `c_register_pragma' or `c_register_pragma_with_expansion' 37993 for each pragma. The macro may also do any setup required for the 37994 pragmas. 37995 37996 The primary reason to define this macro is to provide 37997 compatibility with other compilers for the same target. In 37998 general, we discourage definition of target-specific pragmas for 37999 GCC. 38000 38001 If the pragma can be implemented by attributes then you should 38002 consider defining the target hook `TARGET_INSERT_ATTRIBUTES' as 38003 well. 38004 38005 Preprocessor macros that appear on pragma lines are not expanded. 38006 All `#pragma' directives that do not match any registered pragma 38007 are silently ignored, unless the user specifies 38008 `-Wunknown-pragmas'. 38009 38010 -- Function: void c_register_pragma (const char *SPACE, const char 38011 *NAME, void (*CALLBACK) (struct cpp_reader *)) 38012 -- Function: void c_register_pragma_with_expansion (const char *SPACE, 38013 const char *NAME, void (*CALLBACK) (struct cpp_reader *)) 38014 Each call to `c_register_pragma' or 38015 `c_register_pragma_with_expansion' establishes one pragma. The 38016 CALLBACK routine will be called when the preprocessor encounters a 38017 pragma of the form 38018 38019 #pragma [SPACE] NAME ... 38020 38021 SPACE is the case-sensitive namespace of the pragma, or `NULL' to 38022 put the pragma in the global namespace. The callback routine 38023 receives PFILE as its first argument, which can be passed on to 38024 cpplib's functions if necessary. You can lex tokens after the 38025 NAME by calling `pragma_lex'. Tokens that are not read by the 38026 callback will be silently ignored. The end of the line is 38027 indicated by a token of type `CPP_EOF'. Macro expansion occurs on 38028 the arguments of pragmas registered with 38029 `c_register_pragma_with_expansion' but not on the arguments of 38030 pragmas registered with `c_register_pragma'. 38031 38032 Note that the use of `pragma_lex' is specific to the C and C++ 38033 compilers. It will not work in the Java or Fortran compilers, or 38034 any other language compilers for that matter. Thus if 38035 `pragma_lex' is going to be called from target-specific code, it 38036 must only be done so when building the C and C++ compilers. This 38037 can be done by defining the variables `c_target_objs' and 38038 `cxx_target_objs' in the target entry in the `config.gcc' file. 38039 These variables should name the target-specific, language-specific 38040 object file which contains the code that uses `pragma_lex'. Note 38041 it will also be necessary to add a rule to the makefile fragment 38042 pointed to by `tmake_file' that shows how to build this object 38043 file. 38044 38045 -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION 38046 Define this macro if macros should be expanded in the arguments of 38047 `#pragma pack'. 38048 38049 -- Macro: TARGET_DEFAULT_PACK_STRUCT 38050 If your target requires a structure packing default other than 0 38051 (meaning the machine default), define this macro to the necessary 38052 value (in bytes). This must be a value that would also be valid 38053 to use with `#pragma pack()' (that is, a small power of two). 38054 38055 -- Macro: DOLLARS_IN_IDENTIFIERS 38056 Define this macro to control use of the character `$' in 38057 identifier names for the C family of languages. 0 means `$' is 38058 not allowed by default; 1 means it is allowed. 1 is the default; 38059 there is no need to define this macro in that case. 38060 38061 -- Macro: INSN_SETS_ARE_DELAYED (INSN) 38062 Define this macro as a C expression that is nonzero if it is safe 38063 for the delay slot scheduler to place instructions in the delay 38064 slot of INSN, even if they appear to use a resource set or 38065 clobbered in INSN. INSN is always a `jump_insn' or an `insn'; GCC 38066 knows that every `call_insn' has this behavior. On machines where 38067 some `insn' or `jump_insn' is really a function call and hence has 38068 this behavior, you should define this macro. 38069 38070 You need not define this macro if it would always return zero. 38071 38072 -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN) 38073 Define this macro as a C expression that is nonzero if it is safe 38074 for the delay slot scheduler to place instructions in the delay 38075 slot of INSN, even if they appear to set or clobber a resource 38076 referenced in INSN. INSN is always a `jump_insn' or an `insn'. 38077 On machines where some `insn' or `jump_insn' is really a function 38078 call and its operands are registers whose use is actually in the 38079 subroutine it calls, you should define this macro. Doing so 38080 allows the delay slot scheduler to move instructions which copy 38081 arguments into the argument registers into the delay slot of INSN. 38082 38083 You need not define this macro if it would always return zero. 38084 38085 -- Macro: MULTIPLE_SYMBOL_SPACES 38086 Define this macro as a C expression that is nonzero if, in some 38087 cases, global symbols from one translation unit may not be bound 38088 to undefined symbols in another translation unit without user 38089 intervention. For instance, under Microsoft Windows symbols must 38090 be explicitly imported from shared libraries (DLLs). 38091 38092 You need not define this macro if it would always evaluate to zero. 38093 38094 -- Target Hook: tree TARGET_MD_ASM_CLOBBERS (tree OUTPUTS, tree 38095 INPUTS, tree CLOBBERS) 38096 This target hook should add to CLOBBERS `STRING_CST' trees for any 38097 hard regs the port wishes to automatically clobber for an asm. It 38098 should return the result of the last `tree_cons' used to add a 38099 clobber. The OUTPUTS, INPUTS and CLOBBER lists are the 38100 corresponding parameters to the asm and may be inspected to avoid 38101 clobbering a register that is an input or output of the asm. You 38102 can use `tree_overlaps_hard_reg_set', declared in `tree.h', to test 38103 for overlap with regards to asm-declared registers. 38104 38105 -- Macro: MATH_LIBRARY 38106 Define this macro as a C string constant for the linker argument 38107 to link in the system math library, minus the initial `"-l"', or 38108 `""' if the target does not have a separate math library. 38109 38110 You need only define this macro if the default of `"m"' is wrong. 38111 38112 -- Macro: LIBRARY_PATH_ENV 38113 Define this macro as a C string constant for the environment 38114 variable that specifies where the linker should look for libraries. 38115 38116 You need only define this macro if the default of `"LIBRARY_PATH"' 38117 is wrong. 38118 38119 -- Macro: TARGET_POSIX_IO 38120 Define this macro if the target supports the following POSIX file 38121 functions, access, mkdir and file locking with fcntl / F_SETLKW. 38122 Defining `TARGET_POSIX_IO' will enable the test coverage code to 38123 use file locking when exiting a program, which avoids race 38124 conditions if the program has forked. It will also create 38125 directories at run-time for cross-profiling. 38126 38127 -- Macro: MAX_CONDITIONAL_EXECUTE 38128 A C expression for the maximum number of instructions to execute 38129 via conditional execution instructions instead of a branch. A 38130 value of `BRANCH_COST'+1 is the default if the machine does not 38131 use cc0, and 1 if it does use cc0. 38132 38133 -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR) 38134 Used if the target needs to perform machine-dependent 38135 modifications on the conditionals used for turning basic blocks 38136 into conditionally executed code. CE_INFO points to a data 38137 structure, `struct ce_if_block', which contains information about 38138 the currently processed blocks. TRUE_EXPR and FALSE_EXPR are the 38139 tests that are used for converting the then-block and the 38140 else-block, respectively. Set either TRUE_EXPR or FALSE_EXPR to a 38141 null pointer if the tests cannot be converted. 38142 38143 -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR, 38144 FALSE_EXPR) 38145 Like `IFCVT_MODIFY_TESTS', but used when converting more 38146 complicated if-statements into conditions combined by `and' and 38147 `or' operations. BB contains the basic block that contains the 38148 test that is currently being processed and about to be turned into 38149 a condition. 38150 38151 -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN) 38152 A C expression to modify the PATTERN of an INSN that is to be 38153 converted to conditional execution format. CE_INFO points to a 38154 data structure, `struct ce_if_block', which contains information 38155 about the currently processed blocks. 38156 38157 -- Macro: IFCVT_MODIFY_FINAL (CE_INFO) 38158 A C expression to perform any final machine dependent 38159 modifications in converting code to conditional execution. The 38160 involved basic blocks can be found in the `struct ce_if_block' 38161 structure that is pointed to by CE_INFO. 38162 38163 -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO) 38164 A C expression to cancel any machine dependent modifications in 38165 converting code to conditional execution. The involved basic 38166 blocks can be found in the `struct ce_if_block' structure that is 38167 pointed to by CE_INFO. 38168 38169 -- Macro: IFCVT_MACHDEP_INIT (CE_INFO) 38170 A C expression to initialize any machine specific data for 38171 if-conversion of the if-block in the `struct ce_if_block' 38172 structure that is pointed to by CE_INFO. 38173 38174 -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG (void) 38175 If non-null, this hook performs a target-specific pass over the 38176 instruction stream. The compiler will run it at all optimization 38177 levels, just before the point at which it normally does 38178 delayed-branch scheduling. 38179 38180 The exact purpose of the hook varies from target to target. Some 38181 use it to do transformations that are necessary for correctness, 38182 such as laying out in-function constant pools or avoiding hardware 38183 hazards. Others use it as an opportunity to do some 38184 machine-dependent optimizations. 38185 38186 You need not implement the hook if it has nothing to do. The 38187 default definition is null. 38188 38189 -- Target Hook: void TARGET_INIT_BUILTINS (void) 38190 Define this hook if you have any machine-specific built-in 38191 functions that need to be defined. It should be a function that 38192 performs the necessary setup. 38193 38194 Machine specific built-in functions can be useful to expand 38195 special machine instructions that would otherwise not normally be 38196 generated because they have no equivalent in the source language 38197 (for example, SIMD vector instructions or prefetch instructions). 38198 38199 To create a built-in function, call the function 38200 `lang_hooks.builtin_function' which is defined by the language 38201 front end. You can use any type nodes set up by 38202 `build_common_tree_nodes'; only language front ends that use those 38203 two functions will call `TARGET_INIT_BUILTINS'. 38204 38205 -- Target Hook: tree TARGET_BUILTIN_DECL (unsigned CODE, bool 38206 INITIALIZE_P) 38207 Define this hook if you have any machine-specific built-in 38208 functions that need to be defined. It should be a function that 38209 returns the builtin function declaration for the builtin function 38210 code CODE. If there is no such builtin and it cannot be 38211 initialized at this time if INITIALIZE_P is true the function 38212 should return `NULL_TREE'. If CODE is out of range the function 38213 should return `error_mark_node'. 38214 38215 -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx 38216 SUBTARGET, machine_mode MODE, int IGNORE) 38217 Expand a call to a machine specific built-in function that was set 38218 up by `TARGET_INIT_BUILTINS'. EXP is the expression for the 38219 function call; the result should go to TARGET if that is 38220 convenient, and have mode MODE if that is convenient. SUBTARGET 38221 may be used as the target for computing one of EXP's operands. 38222 IGNORE is nonzero if the value is to be ignored. This function 38223 should return the result of the call to the built-in function. 38224 38225 -- Target Hook: tree TARGET_BUILTIN_CHKP_FUNCTION (unsigned FCODE) 38226 This hook allows target to redefine built-in functions used by 38227 Pointer Bounds Checker for code instrumentation. Hook should 38228 return fndecl of function implementing generic builtin whose code 38229 is passed in FCODE. Currently following built-in functions are 38230 obtained using this hook: 38231 38232 -- Built-in Function: __bounds_type __chkp_bndmk (const void *LB, 38233 size_t SIZE) 38234 Function code - BUILT_IN_CHKP_BNDMK. This built-in function 38235 is used by Pointer Bounds Checker to create bound values. LB 38236 holds low bound of the resulting bounds. SIZE holds size of 38237 created bounds. 38238 38239 -- Built-in Function: void __chkp_bndstx (const void *PTR, 38240 __bounds_type B, const void **LOC) 38241 Function code - `BUILT_IN_CHKP_BNDSTX'. This built-in 38242 function is used by Pointer Bounds Checker to store bounds B 38243 for pointer PTR when PTR is stored by address LOC. 38244 38245 -- Built-in Function: __bounds_type __chkp_bndldx (const void 38246 **LOC, const void *PTR) 38247 Function code - `BUILT_IN_CHKP_BNDLDX'. This built-in 38248 function is used by Pointer Bounds Checker to get bounds of 38249 pointer PTR loaded by address LOC. 38250 38251 -- Built-in Function: void __chkp_bndcl (const void *PTR, 38252 __bounds_type B) 38253 Function code - `BUILT_IN_CHKP_BNDCL'. This built-in 38254 function is used by Pointer Bounds Checker to perform check 38255 for pointer PTR against lower bound of bounds B. 38256 38257 -- Built-in Function: void __chkp_bndcu (const void *PTR, 38258 __bounds_type B) 38259 Function code - `BUILT_IN_CHKP_BNDCU'. This built-in 38260 function is used by Pointer Bounds Checker to perform check 38261 for pointer PTR against upper bound of bounds B. 38262 38263 -- Built-in Function: __bounds_type __chkp_bndret (void *PTR) 38264 Function code - `BUILT_IN_CHKP_BNDRET'. This built-in 38265 function is used by Pointer Bounds Checker to obtain bounds 38266 returned by a call statement. PTR passed to built-in is 38267 `SSA_NAME' returned by the call. 38268 38269 -- Built-in Function: __bounds_type __chkp_intersect 38270 (__bounds_type B1, __bounds_type B2) 38271 Function code - `BUILT_IN_CHKP_INTERSECT'. This built-in 38272 function returns intersection of bounds B1 and B2. 38273 38274 -- Built-in Function: __bounds_type __chkp_narrow (const void 38275 *PTR, __bounds_type B, size_t S) 38276 Function code - `BUILT_IN_CHKP_NARROW'. This built-in 38277 function returns intersection of bounds B and [PTR, PTR + S - 38278 `1']. 38279 38280 -- Built-in Function: size_t __chkp_sizeof (const void *PTR) 38281 Function code - `BUILT_IN_CHKP_SIZEOF'. This built-in 38282 function returns size of object referenced by PTR. PTR is 38283 always `ADDR_EXPR' of `VAR_DECL'. This built-in is used by 38284 Pointer Bounds Checker when bounds of object cannot be 38285 computed statically (e.g. object has incomplete type). 38286 38287 -- Built-in Function: const void *__chkp_extract_lower 38288 (__bounds_type B) 38289 Function code - `BUILT_IN_CHKP_EXTRACT_LOWER'. This built-in 38290 function returns lower bound of bounds B. 38291 38292 -- Built-in Function: const void *__chkp_extract_upper 38293 (__bounds_type B) 38294 Function code - `BUILT_IN_CHKP_EXTRACT_UPPER'. This built-in 38295 function returns upper bound of bounds B. 38296 38297 -- Target Hook: tree TARGET_CHKP_BOUND_TYPE (void) 38298 Return type to be used for bounds 38299 38300 -- Target Hook: enum machine_mode TARGET_CHKP_BOUND_MODE (void) 38301 Return mode to be used for bounds. 38302 38303 -- Target Hook: tree TARGET_CHKP_MAKE_BOUNDS_CONSTANT (HOST_WIDE_INT 38304 LB, HOST_WIDE_INT UB) 38305 Return constant used to statically initialize constant bounds with 38306 specified lower bound LB and upper bounds UB. 38307 38308 -- Target Hook: int TARGET_CHKP_INITIALIZE_BOUNDS (tree VAR, tree LB, 38309 tree UB, tree *STMTS) 38310 Generate a list of statements STMTS to initialize pointer bounds 38311 variable VAR with bounds LB and UB. Return the number of 38312 generated statements. 38313 38314 -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (unsigned int 38315 LOC, tree FNDECL, void *ARGLIST) 38316 Select a replacement for a machine specific built-in function that 38317 was set up by `TARGET_INIT_BUILTINS'. This is done _before_ 38318 regular type checking, and so allows the target to implement a 38319 crude form of function overloading. FNDECL is the declaration of 38320 the built-in function. ARGLIST is the list of arguments passed to 38321 the built-in function. The result is a complete expression that 38322 implements the operation, usually another `CALL_EXPR'. ARGLIST 38323 really has type `VEC(tree,gc)*' 38324 38325 -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, int N_ARGS, 38326 tree *ARGP, bool IGNORE) 38327 Fold a call to a machine specific built-in function that was set 38328 up by `TARGET_INIT_BUILTINS'. FNDECL is the declaration of the 38329 built-in function. N_ARGS is the number of arguments passed to 38330 the function; the arguments themselves are pointed to by ARGP. 38331 The result is another tree, valid for both GIMPLE and GENERIC, 38332 containing a simplified expression for the call's result. If 38333 IGNORE is true the value will be ignored. 38334 38335 -- Target Hook: bool TARGET_GIMPLE_FOLD_BUILTIN (gimple_stmt_iterator 38336 *GSI) 38337 Fold a call to a machine specific built-in function that was set up 38338 by `TARGET_INIT_BUILTINS'. GSI points to the gimple statement 38339 holding the function call. Returns true if any change was made to 38340 the GIMPLE stream. 38341 38342 -- Target Hook: int TARGET_COMPARE_VERSION_PRIORITY (tree DECL1, tree 38343 DECL2) 38344 This hook is used to compare the target attributes in two 38345 functions to determine which function's features get higher 38346 priority. This is used during function multi-versioning to figure 38347 out the order in which two versions must be dispatched. A 38348 function version with a higher priority is checked for dispatching 38349 earlier. DECL1 and DECL2 are the two function decls that will be 38350 compared. 38351 38352 -- Target Hook: tree TARGET_GET_FUNCTION_VERSIONS_DISPATCHER (void 38353 *DECL) 38354 This hook is used to get the dispatcher function for a set of 38355 function versions. The dispatcher function is called to invoke 38356 the right function version at run-time. DECL is one version from a 38357 set of semantically identical versions. 38358 38359 -- Target Hook: tree TARGET_GENERATE_VERSION_DISPATCHER_BODY (void 38360 *ARG) 38361 This hook is used to generate the dispatcher logic to invoke the 38362 right function version at run-time for a given set of function 38363 versions. ARG points to the callgraph node of the dispatcher 38364 function whose body must be generated. 38365 38366 -- Target Hook: bool TARGET_CAN_USE_DOLOOP_P (const widest_int 38367 &ITERATIONS, const widest_int &ITERATIONS_MAX, unsigned int 38368 LOOP_DEPTH, bool ENTERED_AT_TOP) 38369 Return true if it is possible to use low-overhead loops 38370 (`doloop_end' and `doloop_begin') for a particular loop. 38371 ITERATIONS gives the exact number of iterations, or 0 if not 38372 known. ITERATIONS_MAX gives the maximum number of iterations, or 38373 0 if not known. LOOP_DEPTH is the nesting depth of the loop, with 38374 1 for innermost loops, 2 for loops that contain innermost loops, 38375 and so on. ENTERED_AT_TOP is true if the loop is only entered 38376 from the top. 38377 38378 This hook is only used if `doloop_end' is available. The default 38379 implementation returns true. You can use 38380 `can_use_doloop_if_innermost' if the loop must be the innermost, 38381 and if there are no other restrictions. 38382 38383 -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (const 38384 rtx_insn *INSN) 38385 Take an instruction in INSN and return NULL if it is valid within a 38386 low-overhead loop, otherwise return a string explaining why doloop 38387 could not be applied. 38388 38389 Many targets use special registers for low-overhead looping. For 38390 any instruction that clobbers these this function should return a 38391 string indicating the reason why the doloop could not be applied. 38392 By default, the RTL loop optimizer does not use a present doloop 38393 pattern for loops containing function calls or branch on table 38394 instructions. 38395 38396 -- Target Hook: bool TARGET_LEGITIMATE_COMBINED_INSN (rtx_insn *INSN) 38397 Take an instruction in INSN and return `false' if the instruction 38398 is not appropriate as a combination of two or more instructions. 38399 The default is to accept all instructions. 38400 38401 -- Target Hook: bool TARGET_CAN_FOLLOW_JUMP (const rtx_insn *FOLLOWER, 38402 const rtx_insn *FOLLOWEE) 38403 FOLLOWER and FOLLOWEE are JUMP_INSN instructions; return true if 38404 FOLLOWER may be modified to follow FOLLOWEE; false, if it can't. 38405 For example, on some targets, certain kinds of branches can't be 38406 made to follow through a hot/cold partitioning. 38407 38408 -- Target Hook: bool TARGET_COMMUTATIVE_P (const_rtx X, int OUTER_CODE) 38409 This target hook returns `true' if X is considered to be 38410 commutative. Usually, this is just COMMUTATIVE_P (X), but the HP 38411 PA doesn't consider PLUS to be commutative inside a MEM. 38412 OUTER_CODE is the rtx code of the enclosing rtl, if known, 38413 otherwise it is UNKNOWN. 38414 38415 -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG) 38416 When the initial value of a hard register has been copied in a 38417 pseudo register, it is often not necessary to actually allocate 38418 another register to this pseudo register, because the original 38419 hard register or a stack slot it has been saved into can be used. 38420 `TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register 38421 allocation once for each hard register that had its initial value 38422 copied by using `get_func_hard_reg_initial_val' or 38423 `get_hard_reg_initial_val'. Possible values are `NULL_RTX', if 38424 you don't want to do any special allocation, a `REG' rtx--that 38425 would typically be the hard register itself, if it is known not to 38426 be clobbered--or a `MEM'. If you are returning a `MEM', this is 38427 only a hint for the allocator; it might decide to use another 38428 register anyways. You may use `current_function_is_leaf' or 38429 `REG_N_SETS' in the hook to determine if the hard register in 38430 question will not be clobbered. The default value of this hook is 38431 `NULL', which disables any special allocation. 38432 38433 -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned 38434 FLAGS) 38435 This target hook returns nonzero if X, an `unspec' or 38436 `unspec_volatile' operation, might cause a trap. Targets can use 38437 this hook to enhance precision of analysis for `unspec' and 38438 `unspec_volatile' operations. You may call `may_trap_p_1' to 38439 analyze inner elements of X in which case FLAGS should be passed 38440 along. 38441 38442 -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL) 38443 The compiler invokes this hook whenever it changes its current 38444 function context (`cfun'). You can define this function if the 38445 back end needs to perform any initialization or reset actions on a 38446 per-function basis. For example, it may be used to implement 38447 function attributes that affect register usage or code generation 38448 patterns. The argument DECL is the declaration for the new 38449 function context, and may be null to indicate that the compiler 38450 has left a function context and is returning to processing at the 38451 top level. The default hook function does nothing. 38452 38453 GCC sets `cfun' to a dummy function context during initialization 38454 of some parts of the back end. The hook function is not invoked 38455 in this situation; you need not worry about the hook being invoked 38456 recursively, or when the back end is in a partially-initialized 38457 state. `cfun' might be `NULL' to indicate processing at top level, 38458 outside of any function scope. 38459 38460 -- Macro: TARGET_OBJECT_SUFFIX 38461 Define this macro to be a C string representing the suffix for 38462 object files on your target machine. If you do not define this 38463 macro, GCC will use `.o' as the suffix for object files. 38464 38465 -- Macro: TARGET_EXECUTABLE_SUFFIX 38466 Define this macro to be a C string representing the suffix to be 38467 automatically added to executable files on your target machine. 38468 If you do not define this macro, GCC will use the null string as 38469 the suffix for executable files. 38470 38471 -- Macro: COLLECT_EXPORT_LIST 38472 If defined, `collect2' will scan the individual object files 38473 specified on its command line and create an export list for the 38474 linker. Define this macro for systems like AIX, where the linker 38475 discards object files that are not referenced from `main' and uses 38476 export lists. 38477 38478 -- Macro: MODIFY_JNI_METHOD_CALL (MDECL) 38479 Define this macro to a C expression representing a variant of the 38480 method call MDECL, if Java Native Interface (JNI) methods must be 38481 invoked differently from other methods on your target. For 38482 example, on 32-bit Microsoft Windows, JNI methods must be invoked 38483 using the `stdcall' calling convention and this macro is then 38484 defined as this expression: 38485 38486 build_type_attribute_variant (MDECL, 38487 build_tree_list 38488 (get_identifier ("stdcall"), 38489 NULL)) 38490 38491 -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void) 38492 This target hook returns `true' past the point in which new jump 38493 instructions could be created. On machines that require a 38494 register for every jump such as the SHmedia ISA of SH5, this point 38495 would typically be reload, so this target hook should be defined 38496 to a function such as: 38497 38498 static bool 38499 cannot_modify_jumps_past_reload_p () 38500 { 38501 return (reload_completed || reload_in_progress); 38502 } 38503 38504 -- Target Hook: reg_class_t TARGET_BRANCH_TARGET_REGISTER_CLASS (void) 38505 This target hook returns a register class for which branch target 38506 register optimizations should be applied. All registers in this 38507 class should be usable interchangeably. After reload, registers 38508 in this class will be re-allocated and loads will be hoisted out 38509 of loops and be subjected to inter-block scheduling. 38510 38511 -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool 38512 AFTER_PROLOGUE_EPILOGUE_GEN) 38513 Branch target register optimization will by default exclude 38514 callee-saved registers that are not already live during the 38515 current function; if this target hook returns true, they will be 38516 included. The target code must than make sure that all target 38517 registers in the class returned by 38518 `TARGET_BRANCH_TARGET_REGISTER_CLASS' that might need saving are 38519 saved. AFTER_PROLOGUE_EPILOGUE_GEN indicates if prologues and 38520 epilogues have already been generated. Note, even if you only 38521 return true when AFTER_PROLOGUE_EPILOGUE_GEN is false, you still 38522 are likely to have to make special provisions in 38523 `INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved 38524 target registers. 38525 38526 -- Target Hook: bool TARGET_HAVE_CONDITIONAL_EXECUTION (void) 38527 This target hook returns true if the target supports conditional 38528 execution. This target hook is required only when the target has 38529 several different modes and they have different conditional 38530 execution capability, such as ARM. 38531 38532 -- Target Hook: rtx TARGET_GEN_CCMP_FIRST (rtx *PREP_SEQ, rtx 38533 *GEN_SEQ, int CODE, tree OP0, tree OP1) 38534 This function prepares to emit a comparison insn for the first 38535 compare in a sequence of conditional comparisions. It returns a 38536 appropriate `CC' for passing to `gen_ccmp_next' or 38537 `cbranch_optab'. The insns to prepare the compare are saved in 38538 PREP_SEQ and the compare insns are saved in GEN_SEQ. They will 38539 be emitted when all the compares in the the conditional 38540 comparision are generated without error. CODE is the `rtx_code' 38541 of the compare for OP0 and OP1. 38542 38543 -- Target Hook: rtx TARGET_GEN_CCMP_NEXT (rtx *PREP_SEQ, rtx *GEN_SEQ, 38544 rtx PREV, int CMP_CODE, tree OP0, tree OP1, int BIT_CODE) 38545 This function prepare to emit a conditional comparison within a 38546 sequence of conditional comparisons. It returns a appropriate 38547 `CC' for passing to `gen_ccmp_next' or `cbranch_optab'. The 38548 insns to prepare the compare are saved in PREP_SEQ and the 38549 compare insns are saved in GEN_SEQ. They will be emitted when 38550 all the compares in the conditional comparision are generated 38551 without error. The PREV expression is the result of a prior call 38552 to `gen_ccmp_first' or `gen_ccmp_next'. It may return `NULL' if 38553 the combination of PREV and this comparison is not supported, 38554 otherwise the result must be appropriate for passing to 38555 `gen_ccmp_next' or `cbranch_optab'. CODE is the `rtx_code' of 38556 the compare for OP0 and OP1. BIT_CODE is `AND' or `IOR', which 38557 is the op on the two compares. 38558 38559 -- Target Hook: unsigned TARGET_LOOP_UNROLL_ADJUST (unsigned NUNROLL, 38560 struct loop *LOOP) 38561 This target hook returns a new value for the number of times LOOP 38562 should be unrolled. The parameter NUNROLL is the number of times 38563 the loop is to be unrolled. The parameter LOOP is a pointer to the 38564 loop, which is going to be checked for unrolling. This target hook 38565 is required only when the target has special constraints like 38566 maximum number of memory accesses. 38567 38568 -- Macro: POWI_MAX_MULTS 38569 If defined, this macro is interpreted as a signed integer C 38570 expression that specifies the maximum number of floating point 38571 multiplications that should be emitted when expanding 38572 exponentiation by an integer constant inline. When this value is 38573 defined, exponentiation requiring more than this number of 38574 multiplications is implemented by calling the system library's 38575 `pow', `powf' or `powl' routines. The default value places no 38576 upper bound on the multiplication count. 38577 38578 -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char 38579 *IPREFIX, int STDINC) 38580 This target hook should register any extra include files for the 38581 target. The parameter STDINC indicates if normal include files 38582 are present. The parameter SYSROOT is the system root directory. 38583 The parameter IPREFIX is the prefix for the gcc directory. 38584 38585 -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const 38586 char *IPREFIX, int STDINC) 38587 This target hook should register any extra include files for the 38588 target before any standard headers. The parameter STDINC 38589 indicates if normal include files are present. The parameter 38590 SYSROOT is the system root directory. The parameter IPREFIX is 38591 the prefix for the gcc directory. 38592 38593 -- Macro: void TARGET_OPTF (char *PATH) 38594 This target hook should register special include paths for the 38595 target. The parameter PATH is the include to register. On Darwin 38596 systems, this is used for Framework includes, which have semantics 38597 that are different from `-I'. 38598 38599 -- Macro: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL) 38600 This target macro returns `true' if it is safe to use a local alias 38601 for a virtual function FNDECL when constructing thunks, `false' 38602 otherwise. By default, the macro returns `true' for all 38603 functions, if a target supports aliases (i.e. defines 38604 `ASM_OUTPUT_DEF'), `false' otherwise, 38605 38606 -- Macro: TARGET_FORMAT_TYPES 38607 If defined, this macro is the name of a global variable containing 38608 target-specific format checking information for the `-Wformat' 38609 option. The default is to have no target-specific format checks. 38610 38611 -- Macro: TARGET_N_FORMAT_TYPES 38612 If defined, this macro is the number of entries in 38613 `TARGET_FORMAT_TYPES'. 38614 38615 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES 38616 If defined, this macro is the name of a global variable containing 38617 target-specific format overrides for the `-Wformat' option. The 38618 default is to have no target-specific format overrides. If defined, 38619 `TARGET_FORMAT_TYPES' must be defined, too. 38620 38621 -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT 38622 If defined, this macro specifies the number of entries in 38623 `TARGET_OVERRIDES_FORMAT_ATTRIBUTES'. 38624 38625 -- Macro: TARGET_OVERRIDES_FORMAT_INIT 38626 If defined, this macro specifies the optional initialization 38627 routine for target specific customizations of the system printf 38628 and scanf formatter settings. 38629 38630 -- Target Hook: bool TARGET_RELAXED_ORDERING 38631 If set to `true', means that the target's memory model does not 38632 guarantee that loads which do not depend on one another will access 38633 main memory in the order of the instruction stream; if ordering is 38634 important, an explicit memory barrier must be used. This is true 38635 of many recent processors which implement a policy of "relaxed," 38636 "weak," or "release" memory consistency, such as Alpha, PowerPC, 38637 and ia64. The default is `false'. 38638 38639 -- Target Hook: const char * TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN 38640 (const_tree TYPELIST, const_tree FUNCDECL, const_tree VAL) 38641 If defined, this macro returns the diagnostic message when it is 38642 illegal to pass argument VAL to function FUNCDECL with prototype 38643 TYPELIST. 38644 38645 -- Target Hook: const char * TARGET_INVALID_CONVERSION (const_tree 38646 FROMTYPE, const_tree TOTYPE) 38647 If defined, this macro returns the diagnostic message when it is 38648 invalid to convert from FROMTYPE to TOTYPE, or `NULL' if validity 38649 should be determined by the front end. 38650 38651 -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP, 38652 const_tree TYPE) 38653 If defined, this macro returns the diagnostic message when it is 38654 invalid to apply operation OP (where unary plus is denoted by 38655 `CONVERT_EXPR') to an operand of type TYPE, or `NULL' if validity 38656 should be determined by the front end. 38657 38658 -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP, 38659 const_tree TYPE1, const_tree TYPE2) 38660 If defined, this macro returns the diagnostic message when it is 38661 invalid to apply operation OP to operands of types TYPE1 and 38662 TYPE2, or `NULL' if validity should be determined by the front end. 38663 38664 -- Target Hook: const char * TARGET_INVALID_PARAMETER_TYPE (const_tree 38665 TYPE) 38666 If defined, this macro returns the diagnostic message when it is 38667 invalid for functions to include parameters of type TYPE, or 38668 `NULL' if validity should be determined by the front end. This is 38669 currently used only by the C and C++ front ends. 38670 38671 -- Target Hook: const char * TARGET_INVALID_RETURN_TYPE (const_tree 38672 TYPE) 38673 If defined, this macro returns the diagnostic message when it is 38674 invalid for functions to have return type TYPE, or `NULL' if 38675 validity should be determined by the front end. This is currently 38676 used only by the C and C++ front ends. 38677 38678 -- Target Hook: tree TARGET_PROMOTED_TYPE (const_tree TYPE) 38679 If defined, this target hook returns the type to which values of 38680 TYPE should be promoted when they appear in expressions, analogous 38681 to the integer promotions, or `NULL_TREE' to use the front end's 38682 normal promotion rules. This hook is useful when there are 38683 target-specific types with special promotion rules. This is 38684 currently used only by the C and C++ front ends. 38685 38686 -- Target Hook: tree TARGET_CONVERT_TO_TYPE (tree TYPE, tree EXPR) 38687 If defined, this hook returns the result of converting EXPR to 38688 TYPE. It should return the converted expression, or `NULL_TREE' 38689 to apply the front end's normal conversion rules. This hook is 38690 useful when there are target-specific types with special 38691 conversion rules. This is currently used only by the C and C++ 38692 front ends. 38693 38694 -- Macro: TARGET_USE_JCR_SECTION 38695 This macro determines whether to use the JCR section to register 38696 Java classes. By default, TARGET_USE_JCR_SECTION is defined to 1 38697 if both SUPPORTS_WEAK and TARGET_HAVE_NAMED_SECTIONS are true, 38698 else 0. 38699 38700 -- Macro: OBJC_JBLEN 38701 This macro determines the size of the objective C jump buffer for 38702 the NeXT runtime. By default, OBJC_JBLEN is defined to an 38703 innocuous value. 38704 38705 -- Macro: LIBGCC2_UNWIND_ATTRIBUTE 38706 Define this macro if any target-specific attributes need to be 38707 attached to the functions in `libgcc' that provide low-level 38708 support for call stack unwinding. It is used in declarations in 38709 `unwind-generic.h' and the associated definitions of those 38710 functions. 38711 38712 -- Target Hook: void TARGET_UPDATE_STACK_BOUNDARY (void) 38713 Define this macro to update the current function stack boundary if 38714 necessary. 38715 38716 -- Target Hook: rtx TARGET_GET_DRAP_RTX (void) 38717 This hook should return an rtx for Dynamic Realign Argument 38718 Pointer (DRAP) if a different argument pointer register is needed 38719 to access the function's argument list due to stack realignment. 38720 Return `NULL' if no DRAP is needed. 38721 38722 -- Target Hook: bool TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS (void) 38723 When optimization is disabled, this hook indicates whether or not 38724 arguments should be allocated to stack slots. Normally, GCC 38725 allocates stacks slots for arguments when not optimizing in order 38726 to make debugging easier. However, when a function is declared 38727 with `__attribute__((naked))', there is no stack frame, and the 38728 compiler cannot safely move arguments from the registers in which 38729 they are passed to the stack. Therefore, this hook should return 38730 true in general, but false for naked functions. The default 38731 implementation always returns true. 38732 38733 -- Target Hook: unsigned HOST_WIDE_INT TARGET_CONST_ANCHOR 38734 On some architectures it can take multiple instructions to 38735 synthesize a constant. If there is another constant already in a 38736 register that is close enough in value then it is preferable that 38737 the new constant is computed from this register using immediate 38738 addition or subtraction. We accomplish this through CSE. Besides 38739 the value of the constant we also add a lower and an upper 38740 constant anchor to the available expressions. These are then 38741 queried when encountering new constants. The anchors are computed 38742 by rounding the constant up and down to a multiple of the value of 38743 `TARGET_CONST_ANCHOR'. `TARGET_CONST_ANCHOR' should be the 38744 maximum positive value accepted by immediate-add plus one. We 38745 currently assume that the value of `TARGET_CONST_ANCHOR' is a 38746 power of 2. For example, on MIPS, where add-immediate takes a 38747 16-bit signed value, `TARGET_CONST_ANCHOR' is set to `0x8000'. 38748 The default value is zero, which disables this optimization. 38749 38750 -- Target Hook: unsigned HOST_WIDE_INT TARGET_ASAN_SHADOW_OFFSET (void) 38751 Return the offset bitwise ored into shifted address to get 38752 corresponding Address Sanitizer shadow memory address. NULL if 38753 Address Sanitizer is not supported by the target. 38754 38755 -- Target Hook: unsigned HOST_WIDE_INT TARGET_MEMMODEL_CHECK (unsigned 38756 HOST_WIDE_INT VAL) 38757 Validate target specific memory model mask bits. When NULL no 38758 target specific memory model bits are allowed. 38759 38760 -- Target Hook: unsigned char TARGET_ATOMIC_TEST_AND_SET_TRUEVAL 38761 This value should be set if the result written by 38762 `atomic_test_and_set' is not exactly 1, i.e. the `bool' `true'. 38763 38764 -- Target Hook: bool TARGET_HAS_IFUNC_P (void) 38765 It returns true if the target supports GNU indirect functions. 38766 The support includes the assembler, linker and dynamic linker. 38767 The default value of this hook is based on target's libc. 38768 38769 -- Target Hook: unsigned int TARGET_ATOMIC_ALIGN_FOR_MODE 38770 (machine_mode MODE) 38771 If defined, this function returns an appropriate alignment in bits 38772 for an atomic object of machine_mode MODE. If 0 is returned then 38773 the default alignment for the specified mode is used. 38774 38775 -- Target Hook: void TARGET_ATOMIC_ASSIGN_EXPAND_FENV (tree *HOLD, 38776 tree *CLEAR, tree *UPDATE) 38777 ISO C11 requires atomic compound assignments that may raise 38778 floating-point exceptions to raise exceptions corresponding to the 38779 arithmetic operation whose result was successfully stored in a 38780 compare-and-exchange sequence. This requires code equivalent to 38781 calls to `feholdexcept', `feclearexcept' and `feupdateenv' to be 38782 generated at appropriate points in the compare-and-exchange 38783 sequence. This hook should set `*HOLD' to an expression 38784 equivalent to the call to `feholdexcept', `*CLEAR' to an 38785 expression equivalent to the call to `feclearexcept' and `*UPDATE' 38786 to an expression equivalent to the call to `feupdateenv'. The 38787 three expressions are `NULL_TREE' on entry to the hook and may be 38788 left as `NULL_TREE' if no code is required in a particular place. 38789 The default implementation leaves all three expressions as 38790 `NULL_TREE'. The `__atomic_feraiseexcept' function from 38791 `libatomic' may be of use as part of the code generated in 38792 `*UPDATE'. 38793 38794 -- Target Hook: void TARGET_RECORD_OFFLOAD_SYMBOL (tree) 38795 Used when offloaded functions are seen in the compilation unit and 38796 no named sections are available. It is called once for each 38797 symbol that must be recorded in the offload function and variable 38798 table. 38799 38800 -- Target Hook: char * TARGET_OFFLOAD_OPTIONS (void) 38801 Used when writing out the list of options into an LTO file. It 38802 should translate any relevant target-specific options (such as the 38803 ABI in use) into one of the `-foffload' options that exist as a 38804 common interface to express such options. It should return a 38805 string containing these options, separated by spaces, which the 38806 caller will free. 38807 38808 38809 -- Macro: TARGET_SUPPORTS_WIDE_INT 38810 On older ports, large integers are stored in `CONST_DOUBLE' rtl 38811 objects. Newer ports define `TARGET_SUPPORTS_WIDE_INT' to be 38812 nonzero to indicate that large integers are stored in 38813 `CONST_WIDE_INT' rtl objects. The `CONST_WIDE_INT' allows very 38814 large integer constants to be represented. `CONST_DOUBLE' is 38815 limited to twice the size of the host's `HOST_WIDE_INT' 38816 representation. 38817 38818 Converting a port mostly requires looking for the places where 38819 `CONST_DOUBLE's are used with `VOIDmode' and replacing that code 38820 with code that accesses `CONST_WIDE_INT's. `"grep -i 38821 const_double"' at the port level gets you to 95% of the changes 38822 that need to be made. There are a few places that require a 38823 deeper look. 38824 38825 * There is no equivalent to `hval' and `lval' for 38826 `CONST_WIDE_INT's. This would be difficult to express in the 38827 md language since there are a variable number of elements. 38828 38829 Most ports only check that `hval' is either 0 or -1 to see if 38830 the value is small. As mentioned above, this will no longer 38831 be necessary since small constants are always `CONST_INT'. 38832 Of course there are still a few exceptions, the alpha's 38833 constraint used by the zap instruction certainly requires 38834 careful examination by C code. However, all the current code 38835 does is pass the hval and lval to C code, so evolving the c 38836 code to look at the `CONST_WIDE_INT' is not really a large 38837 change. 38838 38839 * Because there is no standard template that ports use to 38840 materialize constants, there is likely to be some futzing 38841 that is unique to each port in this code. 38842 38843 * The rtx costs may have to be adjusted to properly account for 38844 larger constants that are represented as `CONST_WIDE_INT'. 38845 38846 All and all it does not take long to convert ports that the 38847 maintainer is familiar with. 38848 38849 38850 38851File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top 38852 3885318 Host Configuration 38854********************* 38855 38856Most details about the machine and system on which the compiler is 38857actually running are detected by the `configure' script. Some things 38858are impossible for `configure' to detect; these are described in two 38859ways, either by macros defined in a file named `xm-MACHINE.h' or by 38860hook functions in the file specified by the OUT_HOST_HOOK_OBJ variable 38861in `config.gcc'. (The intention is that very few hosts will need a 38862header file but nearly every fully supported host will need to override 38863some hooks.) 38864 38865 If you need to define only a few macros, and they have simple 38866definitions, consider using the `xm_defines' variable in your 38867`config.gcc' entry instead of creating a host configuration header. 38868*Note System Config::. 38869 38870* Menu: 38871 38872* Host Common:: Things every host probably needs implemented. 38873* Filesystem:: Your host can't have the letter `a' in filenames? 38874* Host Misc:: Rare configuration options for hosts. 38875 38876 38877File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config 38878 3887918.1 Host Common 38880================ 38881 38882Some things are just not portable, even between similar operating 38883systems, and are too difficult for autoconf to detect. They get 38884implemented using hook functions in the file specified by the 38885HOST_HOOK_OBJ variable in `config.gcc'. 38886 38887 -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void) 38888 This host hook is used to set up handling for extra signals. The 38889 most common thing to do in this hook is to detect stack overflow. 38890 38891 -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int 38892 FD) 38893 This host hook returns the address of some space that is likely to 38894 be free in some subsequent invocation of the compiler. We intend 38895 to load the PCH data at this address such that the data need not 38896 be relocated. The area should be able to hold SIZE bytes. If the 38897 host uses `mmap', FD is an open file descriptor that can be used 38898 for probing. 38899 38900 -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS, 38901 size_t SIZE, int FD, size_t OFFSET) 38902 This host hook is called when a PCH file is about to be loaded. 38903 We want to load SIZE bytes from FD at OFFSET into memory at 38904 ADDRESS. The given address will be the result of a previous 38905 invocation of `HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we 38906 couldn't allocate SIZE bytes at ADDRESS. Return 0 if the memory 38907 is allocated but the data is not loaded. Return 1 if the hook has 38908 performed everything. 38909 38910 If the implementation uses reserved address space, free any 38911 reserved space beyond SIZE, regardless of the return value. If no 38912 PCH will be loaded, this hook may be called with SIZE zero, in 38913 which case all reserved address space should be freed. 38914 38915 Do not try to handle values of ADDRESS that could not have been 38916 returned by this executable; just return -1. Such values usually 38917 indicate an out-of-date PCH file (built by some other GCC 38918 executable), and such a PCH file won't work. 38919 38920 -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void); 38921 This host hook returns the alignment required for allocating 38922 virtual memory. Usually this is the same as getpagesize, but on 38923 some hosts the alignment for reserving memory differs from the 38924 pagesize for committing memory. 38925 38926 38927File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config 38928 3892918.2 Host Filesystem 38930==================== 38931 38932GCC needs to know a number of things about the semantics of the host 38933machine's filesystem. Filesystems with Unix and MS-DOS semantics are 38934automatically detected. For other systems, you can define the 38935following macros in `xm-MACHINE.h'. 38936 38937`HAVE_DOS_BASED_FILE_SYSTEM' 38938 This macro is automatically defined by `system.h' if the host file 38939 system obeys the semantics defined by MS-DOS instead of Unix. DOS 38940 file systems are case insensitive, file specifications may begin 38941 with a drive letter, and both forward slash and backslash (`/' and 38942 `\') are directory separators. 38943 38944`DIR_SEPARATOR' 38945`DIR_SEPARATOR_2' 38946 If defined, these macros expand to character constants specifying 38947 separators for directory names within a file specification. 38948 `system.h' will automatically give them appropriate values on Unix 38949 and MS-DOS file systems. If your file system is neither of these, 38950 define one or both appropriately in `xm-MACHINE.h'. 38951 38952 However, operating systems like VMS, where constructing a pathname 38953 is more complicated than just stringing together directory names 38954 separated by a special character, should not define either of these 38955 macros. 38956 38957`PATH_SEPARATOR' 38958 If defined, this macro should expand to a character constant 38959 specifying the separator for elements of search paths. The default 38960 value is a colon (`:'). DOS-based systems usually, but not 38961 always, use semicolon (`;'). 38962 38963`VMS' 38964 Define this macro if the host system is VMS. 38965 38966`HOST_OBJECT_SUFFIX' 38967 Define this macro to be a C string representing the suffix for 38968 object files on your host machine. If you do not define this 38969 macro, GCC will use `.o' as the suffix for object files. 38970 38971`HOST_EXECUTABLE_SUFFIX' 38972 Define this macro to be a C string representing the suffix for 38973 executable files on your host machine. If you do not define this 38974 macro, GCC will use the null string as the suffix for executable 38975 files. 38976 38977`HOST_BIT_BUCKET' 38978 A pathname defined by the host operating system, which can be 38979 opened as a file and written to, but all the information written 38980 is discarded. This is commonly known as a "bit bucket" or "null 38981 device". If you do not define this macro, GCC will use 38982 `/dev/null' as the bit bucket. If the host does not support a bit 38983 bucket, define this macro to an invalid filename. 38984 38985`UPDATE_PATH_HOST_CANONICALIZE (PATH)' 38986 If defined, a C statement (sans semicolon) that performs 38987 host-dependent canonicalization when a path used in a compilation 38988 driver or preprocessor is canonicalized. PATH is a malloc-ed path 38989 to be canonicalized. If the C statement does canonicalize PATH 38990 into a different buffer, the old path should be freed and the new 38991 buffer should have been allocated with malloc. 38992 38993`DUMPFILE_FORMAT' 38994 Define this macro to be a C string representing the format to use 38995 for constructing the index part of debugging dump file names. The 38996 resultant string must fit in fifteen bytes. The full filename 38997 will be the concatenation of: the prefix of the assembler file 38998 name, the string resulting from applying this format to an index 38999 number, and a string unique to each dump file kind, e.g. `rtl'. 39000 39001 If you do not define this macro, GCC will use `.%02d.'. You should 39002 define this macro if using the default will create an invalid file 39003 name. 39004 39005`DELETE_IF_ORDINARY' 39006 Define this macro to be a C statement (sans semicolon) that 39007 performs host-dependent removal of ordinary temp files in the 39008 compilation driver. 39009 39010 If you do not define this macro, GCC will use the default version. 39011 You should define this macro if the default version does not 39012 reliably remove the temp file as, for example, on VMS which allows 39013 multiple versions of a file. 39014 39015`HOST_LACKS_INODE_NUMBERS' 39016 Define this macro if the host filesystem does not report 39017 meaningful inode numbers in struct stat. 39018 39019 39020File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config 39021 3902218.3 Host Misc 39023============== 39024 39025`FATAL_EXIT_CODE' 39026 A C expression for the status code to be returned when the compiler 39027 exits after serious errors. The default is the system-provided 39028 macro `EXIT_FAILURE', or `1' if the system doesn't define that 39029 macro. Define this macro only if these defaults are incorrect. 39030 39031`SUCCESS_EXIT_CODE' 39032 A C expression for the status code to be returned when the compiler 39033 exits without serious errors. (Warnings are not serious errors.) 39034 The default is the system-provided macro `EXIT_SUCCESS', or `0' if 39035 the system doesn't define that macro. Define this macro only if 39036 these defaults are incorrect. 39037 39038`USE_C_ALLOCA' 39039 Define this macro if GCC should use the C implementation of 39040 `alloca' provided by `libiberty.a'. This only affects how some 39041 parts of the compiler itself allocate memory. It does not change 39042 code generation. 39043 39044 When GCC is built with a compiler other than itself, the C `alloca' 39045 is always used. This is because most other implementations have 39046 serious bugs. You should define this macro only on a system where 39047 no stack-based `alloca' can possibly work. For instance, if a 39048 system has a small limit on the size of the stack, GCC's builtin 39049 `alloca' will not work reliably. 39050 39051`COLLECT2_HOST_INITIALIZATION' 39052 If defined, a C statement (sans semicolon) that performs 39053 host-dependent initialization when `collect2' is being initialized. 39054 39055`GCC_DRIVER_HOST_INITIALIZATION' 39056 If defined, a C statement (sans semicolon) that performs 39057 host-dependent initialization when a compilation driver is being 39058 initialized. 39059 39060`HOST_LONG_LONG_FORMAT' 39061 If defined, the string used to indicate an argument of type `long 39062 long' to functions like `printf'. The default value is `"ll"'. 39063 39064`HOST_LONG_FORMAT' 39065 If defined, the string used to indicate an argument of type `long' 39066 to functions like `printf'. The default value is `"l"'. 39067 39068`HOST_PTR_PRINTF' 39069 If defined, the string used to indicate an argument of type `void 39070 *' to functions like `printf'. The default value is `"%p"'. 39071 39072 In addition, if `configure' generates an incorrect definition of any 39073of the macros in `auto-host.h', you can override that definition in a 39074host configuration header. If you need to do this, first see if it is 39075possible to fix `configure'. 39076 39077 39078File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top 39079 3908019 Makefile Fragments 39081********************* 39082 39083When you configure GCC using the `configure' script, it will construct 39084the file `Makefile' from the template file `Makefile.in'. When it does 39085this, it can incorporate makefile fragments from the `config' 39086directory. These are used to set Makefile parameters that are not 39087amenable to being calculated by autoconf. The list of fragments to 39088incorporate is set by `config.gcc' (and occasionally `config.build' and 39089`config.host'); *Note System Config::. 39090 39091 Fragments are named either `t-TARGET' or `x-HOST', depending on 39092whether they are relevant to configuring GCC to produce code for a 39093particular target, or to configuring GCC to run on a particular host. 39094Here TARGET and HOST are mnemonics which usually have some relationship 39095to the canonical system name, but no formal connection. 39096 39097 If these files do not exist, it means nothing needs to be added for a 39098given target or host. Most targets need a few `t-TARGET' fragments, 39099but needing `x-HOST' fragments is rare. 39100 39101* Menu: 39102 39103* Target Fragment:: Writing `t-TARGET' files. 39104* Host Fragment:: Writing `x-HOST' files. 39105 39106 39107File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments 39108 3910919.1 Target Makefile Fragments 39110============================== 39111 39112Target makefile fragments can set these Makefile variables. 39113 39114`LIBGCC2_CFLAGS' 39115 Compiler flags to use when compiling `libgcc2.c'. 39116 39117`LIB2FUNCS_EXTRA' 39118 A list of source file names to be compiled or assembled and 39119 inserted into `libgcc.a'. 39120 39121`CRTSTUFF_T_CFLAGS' 39122 Special flags used when compiling `crtstuff.c'. *Note 39123 Initialization::. 39124 39125`CRTSTUFF_T_CFLAGS_S' 39126 Special flags used when compiling `crtstuff.c' for shared linking. 39127 Used if you use `crtbeginS.o' and `crtendS.o' in `EXTRA-PARTS'. 39128 *Note Initialization::. 39129 39130`MULTILIB_OPTIONS' 39131 For some targets, invoking GCC in different ways produces objects 39132 that can not be linked together. For example, for some targets GCC 39133 produces both big and little endian code. For these targets, you 39134 must arrange for multiple versions of `libgcc.a' to be compiled, 39135 one for each set of incompatible options. When GCC invokes the 39136 linker, it arranges to link in the right version of `libgcc.a', 39137 based on the command line options used. 39138 39139 The `MULTILIB_OPTIONS' macro lists the set of options for which 39140 special versions of `libgcc.a' must be built. Write options that 39141 are mutually incompatible side by side, separated by a slash. 39142 Write options that may be used together separated by a space. The 39143 build procedure will build all combinations of compatible options. 39144 39145 For example, if you set `MULTILIB_OPTIONS' to `m68000/m68020 39146 msoft-float', `Makefile' will build special versions of `libgcc.a' 39147 using the following sets of options: `-m68000', `-m68020', 39148 `-msoft-float', `-m68000 -msoft-float', and `-m68020 -msoft-float'. 39149 39150`MULTILIB_DIRNAMES' 39151 If `MULTILIB_OPTIONS' is used, this variable specifies the 39152 directory names that should be used to hold the various libraries. 39153 Write one element in `MULTILIB_DIRNAMES' for each element in 39154 `MULTILIB_OPTIONS'. If `MULTILIB_DIRNAMES' is not used, the 39155 default value will be `MULTILIB_OPTIONS', with all slashes treated 39156 as spaces. 39157 39158 `MULTILIB_DIRNAMES' describes the multilib directories using GCC 39159 conventions and is applied to directories that are part of the GCC 39160 installation. When multilib-enabled, the compiler will add a 39161 subdirectory of the form PREFIX/MULTILIB before each directory in 39162 the search path for libraries and crt files. 39163 39164 For example, if `MULTILIB_OPTIONS' is set to `m68000/m68020 39165 msoft-float', then the default value of `MULTILIB_DIRNAMES' is 39166 `m68000 m68020 msoft-float'. You may specify a different value if 39167 you desire a different set of directory names. 39168 39169`MULTILIB_MATCHES' 39170 Sometimes the same option may be written in two different ways. 39171 If an option is listed in `MULTILIB_OPTIONS', GCC needs to know 39172 about any synonyms. In that case, set `MULTILIB_MATCHES' to a 39173 list of items of the form `option=option' to describe all relevant 39174 synonyms. For example, `m68000=mc68000 m68020=mc68020'. 39175 39176`MULTILIB_EXCEPTIONS' 39177 Sometimes when there are multiple sets of `MULTILIB_OPTIONS' being 39178 specified, there are combinations that should not be built. In 39179 that case, set `MULTILIB_EXCEPTIONS' to be all of the switch 39180 exceptions in shell case syntax that should not be built. 39181 39182 For example the ARM processor cannot execute both hardware floating 39183 point instructions and the reduced size THUMB instructions at the 39184 same time, so there is no need to build libraries with both of 39185 these options enabled. Therefore `MULTILIB_EXCEPTIONS' is set to: 39186 *mthumb/*mhard-float* 39187 39188`MULTILIB_REQUIRED' 39189 Sometimes when there are only a few combinations are required, it 39190 would be a big effort to come up with a `MULTILIB_EXCEPTIONS' list 39191 to cover all undesired ones. In such a case, just listing all the 39192 required combinations in `MULTILIB_REQUIRED' would be more 39193 straightforward. 39194 39195 The way to specify the entries in `MULTILIB_REQUIRED' is same with 39196 the way used for `MULTILIB_EXCEPTIONS', only this time what are 39197 required will be specified. Suppose there are multiple sets of 39198 `MULTILIB_OPTIONS' and only two combinations are required, one for 39199 ARMv7-M and one for ARMv7-R with hard floating-point ABI and FPU, 39200 the `MULTILIB_REQUIRED' can be set to: 39201 `MULTILIB_REQUIRED' = mthumb/march=armv7-m 39202 `MULTILIB_REQUIRED' += march=armv7-r/mfloat-abi=hard/mfpu=vfpv3-d16 39203 39204 The `MULTILIB_REQUIRED' can be used together with 39205 `MULTILIB_EXCEPTIONS'. The option combinations generated from 39206 `MULTILIB_OPTIONS' will be filtered by `MULTILIB_EXCEPTIONS' and 39207 then by `MULTILIB_REQUIRED'. 39208 39209`MULTILIB_REUSE' 39210 Sometimes it is desirable to reuse one existing multilib for 39211 different sets of options. Such kind of reuse can minimize the 39212 number of multilib variants. And for some targets it is better to 39213 reuse an existing multilib than to fall back to default multilib 39214 when there is no corresponding multilib. This can be done by 39215 adding reuse rules to `MULTILIB_REUSE'. 39216 39217 A reuse rule is comprised of two parts connected by equality sign. 39218 The left part is option set used to build multilib and the right 39219 part is option set that will reuse this multilib. The order of 39220 options in the left part matters and should be same with those 39221 specified in `MULTILIB_REQUIRED' or aligned with order in 39222 `MULTILIB_OPTIONS'. There is no such limitation for options in 39223 right part as we don't build multilib from them. But the equality 39224 sign in both parts should be replaced with period. 39225 39226 The `MULTILIB_REUSE' is different from `MULTILIB_MATCHES' in that 39227 it sets up relations between two option sets rather than two 39228 options. Here is an example to demo how we reuse libraries built 39229 in Thumb mode for applications built in ARM mode: 39230 `MULTILIB_REUSE' = mthumb/march.armv7-r=marm/march.armv7-r 39231 39232 Before the advent of `MULTILIB_REUSE', GCC select multilib by 39233 comparing command line options with options used to build 39234 multilib. The `MULTILIB_REUSE' is complementary to that way. 39235 Only when the original comparison matches nothing it will work to 39236 see if it is OK to reuse some existing multilib. 39237 39238`MULTILIB_EXTRA_OPTS' 39239 Sometimes it is desirable that when building multiple versions of 39240 `libgcc.a' certain options should always be passed on to the 39241 compiler. In that case, set `MULTILIB_EXTRA_OPTS' to be the list 39242 of options to be used for all builds. If you set this, you should 39243 probably set `CRTSTUFF_T_CFLAGS' to a dash followed by it. 39244 39245`MULTILIB_OSDIRNAMES' 39246 If `MULTILIB_OPTIONS' is used, this variable specifies a list of 39247 subdirectory names, that are used to modify the search path 39248 depending on the chosen multilib. Unlike `MULTILIB_DIRNAMES', 39249 `MULTILIB_OSDIRNAMES' describes the multilib directories using 39250 operating systems conventions, and is applied to the directories 39251 such as `lib' or those in the `LIBRARY_PATH' environment variable. 39252 The format is either the same as of `MULTILIB_DIRNAMES', or a set 39253 of mappings. When it is the same as `MULTILIB_DIRNAMES', it 39254 describes the multilib directories using operating system 39255 conventions, rather than GCC conventions. When it is a set of 39256 mappings of the form GCCDIR=OSDIR, the left side gives the GCC 39257 convention and the right gives the equivalent OS defined location. 39258 If the OSDIR part begins with a `!', GCC will not search in the 39259 non-multilib directory and use exclusively the multilib directory. 39260 Otherwise, the compiler will examine the search path for libraries 39261 and crt files twice; the first time it will add MULTILIB to each 39262 directory in the search path, the second it will not. 39263 39264 For configurations that support both multilib and multiarch, 39265 `MULTILIB_OSDIRNAMES' also encodes the multiarch name, thus 39266 subsuming `MULTIARCH_DIRNAME'. The multiarch name is appended to 39267 each directory name, separated by a colon (e.g. 39268 `../lib32:i386-linux-gnu'). 39269 39270 Each multiarch subdirectory will be searched before the 39271 corresponding OS multilib directory, for example 39272 `/lib/i386-linux-gnu' before `/lib/../lib32'. The multiarch name 39273 will also be used to modify the system header search path, as 39274 explained for `MULTIARCH_DIRNAME'. 39275 39276`MULTIARCH_DIRNAME' 39277 This variable specifies the multiarch name for configurations that 39278 are multiarch-enabled but not multilibbed configurations. 39279 39280 The multiarch name is used to augment the search path for 39281 libraries, crt files and system header files with additional 39282 locations. The compiler will add a multiarch subdirectory of the 39283 form PREFIX/MULTIARCH before each directory in the library and crt 39284 search path. It will also add two directories 39285 `LOCAL_INCLUDE_DIR'/MULTIARCH and 39286 `NATIVE_SYSTEM_HEADER_DIR'/MULTIARCH) to the system header search 39287 path, respectively before `LOCAL_INCLUDE_DIR' and 39288 `NATIVE_SYSTEM_HEADER_DIR'. 39289 39290 `MULTIARCH_DIRNAME' is not used for configurations that support 39291 both multilib and multiarch. In that case, multiarch names are 39292 encoded in `MULTILIB_OSDIRNAMES' instead. 39293 39294 More documentation about multiarch can be found at 39295 `http://wiki.debian.org/Multiarch'. 39296 39297`SPECS' 39298 Unfortunately, setting `MULTILIB_EXTRA_OPTS' is not enough, since 39299 it does not affect the build of target libraries, at least not the 39300 build of the default multilib. One possible work-around is to use 39301 `DRIVER_SELF_SPECS' to bring options from the `specs' file as if 39302 they had been passed in the compiler driver command line. 39303 However, you don't want to be adding these options after the 39304 toolchain is installed, so you can instead tweak the `specs' file 39305 that will be used during the toolchain build, while you still 39306 install the original, built-in `specs'. The trick is to set 39307 `SPECS' to some other filename (say `specs.install'), that will 39308 then be created out of the built-in specs, and introduce a 39309 `Makefile' rule to generate the `specs' file that's going to be 39310 used at build time out of your `specs.install'. 39311 39312`T_CFLAGS' 39313 These are extra flags to pass to the C compiler. They are used 39314 both when building GCC, and when compiling things with the 39315 just-built GCC. This variable is deprecated and should not be 39316 used. 39317 39318 39319File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments 39320 3932119.2 Host Makefile Fragments 39322============================ 39323 39324The use of `x-HOST' fragments is discouraged. You should only use it 39325for makefile dependencies. 39326 39327 39328File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top 39329 3933020 `collect2' 39331************* 39332 39333GCC uses a utility called `collect2' on nearly all systems to arrange 39334to call various initialization functions at start time. 39335 39336 The program `collect2' works by linking the program once and looking 39337through the linker output file for symbols with particular names 39338indicating they are constructor functions. If it finds any, it creates 39339a new temporary `.c' file containing a table of them, compiles it, and 39340links the program a second time including that file. 39341 39342 The actual calls to the constructors are carried out by a subroutine 39343called `__main', which is called (automatically) at the beginning of 39344the body of `main' (provided `main' was compiled with GNU CC). Calling 39345`__main' is necessary, even when compiling C code, to allow linking C 39346and C++ object code together. (If you use `-nostdlib', you get an 39347unresolved reference to `__main', since it's defined in the standard 39348GCC library. Include `-lgcc' at the end of your compiler command line 39349to resolve this reference.) 39350 39351 The program `collect2' is installed as `ld' in the directory where the 39352passes of the compiler are installed. When `collect2' needs to find 39353the _real_ `ld', it tries the following file names: 39354 39355 * a hard coded linker file name, if GCC was configured with the 39356 `--with-ld' option. 39357 39358 * `real-ld' in the directories listed in the compiler's search 39359 directories. 39360 39361 * `real-ld' in the directories listed in the environment variable 39362 `PATH'. 39363 39364 * The file specified in the `REAL_LD_FILE_NAME' configuration macro, 39365 if specified. 39366 39367 * `ld' in the compiler's search directories, except that `collect2' 39368 will not execute itself recursively. 39369 39370 * `ld' in `PATH'. 39371 39372 "The compiler's search directories" means all the directories where 39373`gcc' searches for passes of the compiler. This includes directories 39374that you specify with `-B'. 39375 39376 Cross-compilers search a little differently: 39377 39378 * `real-ld' in the compiler's search directories. 39379 39380 * `TARGET-real-ld' in `PATH'. 39381 39382 * The file specified in the `REAL_LD_FILE_NAME' configuration macro, 39383 if specified. 39384 39385 * `ld' in the compiler's search directories. 39386 39387 * `TARGET-ld' in `PATH'. 39388 39389 `collect2' explicitly avoids running `ld' using the file name under 39390which `collect2' itself was invoked. In fact, it remembers up a list 39391of such names--in case one copy of `collect2' finds another copy (or 39392version) of `collect2' installed as `ld' in a second place in the 39393search path. 39394 39395 `collect2' searches for the utilities `nm' and `strip' using the same 39396algorithm as above for `ld'. 39397 39398 39399File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top 39400 3940121 Standard Header File Directories 39402*********************************** 39403 39404`GCC_INCLUDE_DIR' means the same thing for native and cross. It is 39405where GCC stores its private include files, and also where GCC stores 39406the fixed include files. A cross compiled GCC runs `fixincludes' on 39407the header files in `$(tooldir)/include'. (If the cross compilation 39408header files need to be fixed, they must be installed before GCC is 39409built. If the cross compilation header files are already suitable for 39410GCC, nothing special need be done). 39411 39412 `GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It 39413is where `g++' looks first for header files. The C++ library installs 39414only target independent header files in that directory. 39415 39416 `LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't 39417install anything there. It is normally `/usr/local/include'. This is 39418where local additions to a packaged system should place header files. 39419 39420 `CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't 39421install anything there. 39422 39423 `TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is 39424the place for other packages to install header files that GCC will use. 39425For a cross-compiler, this is the equivalent of `/usr/include'. When 39426you build a cross-compiler, `fixincludes' processes any header files in 39427this directory. 39428 39429 39430File: gccint.info, Node: Type Information, Next: Plugins, Prev: Header Dirs, Up: Top 39431 3943222 Memory Management and Type Information 39433***************************************** 39434 39435GCC uses some fairly sophisticated memory management techniques, which 39436involve determining information about GCC's data structures from GCC's 39437source code and using this information to perform garbage collection and 39438implement precompiled headers. 39439 39440 A full C++ parser would be too complicated for this task, so a limited 39441subset of C++ is interpreted and special markers are used to determine 39442what parts of the source to look at. All `struct', `union' and 39443`template' structure declarations that define data structures that are 39444allocated under control of the garbage collector must be marked. All 39445global variables that hold pointers to garbage-collected memory must 39446also be marked. Finally, all global variables that need to be saved 39447and restored by a precompiled header must be marked. (The precompiled 39448header mechanism can only save static variables if they're scalar. 39449Complex data structures must be allocated in garbage-collected memory 39450to be saved in a precompiled header.) 39451 39452 The full format of a marker is 39453 GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...)) 39454 but in most cases no options are needed. The outer double parentheses 39455are still necessary, though: `GTY(())'. Markers can appear: 39456 39457 * In a structure definition, before the open brace; 39458 39459 * In a global variable declaration, after the keyword `static' or 39460 `extern'; and 39461 39462 * In a structure field definition, before the name of the field. 39463 39464 Here are some examples of marking simple data structures and globals. 39465 39466 struct GTY(()) TAG 39467 { 39468 FIELDS... 39469 }; 39470 39471 typedef struct GTY(()) TAG 39472 { 39473 FIELDS... 39474 } *TYPENAME; 39475 39476 static GTY(()) struct TAG *LIST; /* points to GC memory */ 39477 static GTY(()) int COUNTER; /* save counter in a PCH */ 39478 39479 The parser understands simple typedefs such as `typedef struct TAG 39480*NAME;' and `typedef int NAME;'. These don't need to be marked. 39481 39482 Since `gengtype''s understanding of C++ is limited, there are several 39483constructs and declarations that are not supported inside 39484classes/structures marked for automatic GC code generation. The 39485following C++ constructs produce a `gengtype' error on 39486structures/classes marked for automatic GC code generation: 39487 39488 * Type definitions inside classes/structures are not supported. 39489 39490 * Enumerations inside classes/structures are not supported. 39491 39492 If you have a class or structure using any of the above constructs, 39493you need to mark that class as `GTY ((user))' and provide your own 39494marking routines (see section *note User GC:: for details). 39495 39496 It is always valid to include function definitions inside classes. 39497Those are always ignored by `gengtype', as it only cares about data 39498members. 39499 39500* Menu: 39501 39502* GTY Options:: What goes inside a `GTY(())'. 39503* Inheritance and GTY:: Adding GTY to a class hierarchy. 39504* User GC:: Adding user-provided GC marking routines. 39505* GGC Roots:: Making global variables GGC roots. 39506* Files:: How the generated files work. 39507* Invoking the garbage collector:: How to invoke the garbage collector. 39508* Troubleshooting:: When something does not work as expected. 39509 39510 39511File: gccint.info, Node: GTY Options, Next: Inheritance and GTY, Up: Type Information 39512 3951322.1 The Inside of a `GTY(())' 39514============================== 39515 39516Sometimes the C code is not enough to fully describe the type 39517structure. Extra information can be provided with `GTY' options and 39518additional markers. Some options take a parameter, which may be either 39519a string or a type name, depending on the parameter. If an option 39520takes no parameter, it is acceptable either to omit the parameter 39521entirely, or to provide an empty string as a parameter. For example, 39522`GTY ((skip))' and `GTY ((skip ("")))' are equivalent. 39523 39524 When the parameter is a string, often it is a fragment of C code. Four 39525special escapes may be used in these strings, to refer to pieces of the 39526data structure being marked: 39527 39528`%h' 39529 The current structure. 39530 39531`%1' 39532 The structure that immediately contains the current structure. 39533 39534`%0' 39535 The outermost structure that contains the current structure. 39536 39537`%a' 39538 A partial expression of the form `[i1][i2]...' that indexes the 39539 array item currently being marked. 39540 39541 For instance, suppose that you have a structure of the form 39542 struct A { 39543 ... 39544 }; 39545 struct B { 39546 struct A foo[12]; 39547 }; 39548 and `b' is a variable of type `struct B'. When marking `b.foo[11]', 39549`%h' would expand to `b.foo[11]', `%0' and `%1' would both expand to 39550`b', and `%a' would expand to `[11]'. 39551 39552 As in ordinary C, adjacent strings will be concatenated; this is 39553helpful when you have a complicated expression. 39554 GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE" 39555 " ? TYPE_NEXT_VARIANT (&%h.generic)" 39556 " : TREE_CHAIN (&%h.generic)"))) 39557 39558 The available options are: 39559 39560`length ("EXPRESSION")' 39561 There are two places the type machinery will need to be explicitly 39562 told the length of an array of non-atomic objects. The first case 39563 is when a structure ends in a variable-length array, like this: 39564 struct GTY(()) rtvec_def { 39565 int num_elem; /* number of elements */ 39566 rtx GTY ((length ("%h.num_elem"))) elem[1]; 39567 }; 39568 39569 In this case, the `length' option is used to override the specified 39570 array length (which should usually be `1'). The parameter of the 39571 option is a fragment of C code that calculates the length. 39572 39573 The second case is when a structure or a global variable contains a 39574 pointer to an array, like this: 39575 struct gimple_omp_for_iter * GTY((length ("%h.collapse"))) iter; 39576 In this case, `iter' has been allocated by writing something like 39577 x->iter = ggc_alloc_cleared_vec_gimple_omp_for_iter (collapse); 39578 and the `collapse' provides the length of the field. 39579 39580 This second use of `length' also works on global variables, like: static GTY((length("reg_known_value_size"))) rtx *reg_known_value; 39581 39582 Note that the `length' option is only meant for use with arrays of 39583 non-atomic objects, that is, objects that contain pointers 39584 pointing to other GTY-managed objects. For other GC-allocated 39585 arrays and strings you should use `atomic'. 39586 39587`skip' 39588 If `skip' is applied to a field, the type machinery will ignore it. 39589 This is somewhat dangerous; the only safe use is in a union when 39590 one field really isn't ever used. 39591 39592 Use this to mark types that need to be marked by user gc routines, 39593 but are not refered to in a template argument. So if you have 39594 some user gc type T1 and a non user gc type T2 you can give T2 the 39595 for_user option so that the marking functions for T1 can call non 39596 mangled functions to mark T2. 39597 39598`desc ("EXPRESSION")' 39599`tag ("CONSTANT")' 39600`default' 39601 The type machinery needs to be told which field of a `union' is 39602 currently active. This is done by giving each field a constant 39603 `tag' value, and then specifying a discriminator using `desc'. 39604 The value of the expression given by `desc' is compared against 39605 each `tag' value, each of which should be different. If no `tag' 39606 is matched, the field marked with `default' is used if there is 39607 one, otherwise no field in the union will be marked. 39608 39609 In the `desc' option, the "current structure" is the union that it 39610 discriminates. Use `%1' to mean the structure containing it. 39611 There are no escapes available to the `tag' option, since it is a 39612 constant. 39613 39614 For example, 39615 struct GTY(()) tree_binding 39616 { 39617 struct tree_common common; 39618 union tree_binding_u { 39619 tree GTY ((tag ("0"))) scope; 39620 struct cp_binding_level * GTY ((tag ("1"))) level; 39621 } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope; 39622 tree value; 39623 }; 39624 39625 In this example, the value of BINDING_HAS_LEVEL_P when applied to a 39626 `struct tree_binding *' is presumed to be 0 or 1. If 1, the type 39627 mechanism will treat the field `level' as being present and if 0, 39628 will treat the field `scope' as being present. 39629 39630 The `desc' and `tag' options can also be used for inheritance to 39631 denote which subclass an instance is. See *note Inheritance and 39632 GTY:: for more information. 39633 39634`cache' 39635 When the `cache' option is applied to a global variable 39636 gt_clear_cache is called on that variable between the mark and 39637 sweep phases of garbage collection. The gt_clear_cache function 39638 is free to mark blocks as used, or to clear pointers in the 39639 variable. 39640 39641`deletable' 39642 `deletable', when applied to a global variable, indicates that when 39643 garbage collection runs, there's no need to mark anything pointed 39644 to by this variable, it can just be set to `NULL' instead. This 39645 is used to keep a list of free structures around for re-use. 39646 39647`mark_hook ("HOOK-ROUTINE-NAME")' 39648 If provided for a structure or union type, the given 39649 HOOK-ROUTINE-NAME (between double-quotes) is the name of a routine 39650 called when the garbage collector has just marked the data as 39651 reachable. This routine should not change the data, or call any ggc 39652 routine. Its only argument is a pointer to the just marked (const) 39653 structure or union. 39654 39655`maybe_undef' 39656 When applied to a field, `maybe_undef' indicates that it's OK if 39657 the structure that this fields points to is never defined, so long 39658 as this field is always `NULL'. This is used to avoid requiring 39659 backends to define certain optional structures. It doesn't work 39660 with language frontends. 39661 39662`nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")' 39663 The type machinery expects all pointers to point to the start of an 39664 object. Sometimes for abstraction purposes it's convenient to have 39665 a pointer which points inside an object. So long as it's possible 39666 to convert the original object to and from the pointer, such 39667 pointers can still be used. TYPE is the type of the original 39668 object, the TO EXPRESSION returns the pointer given the original 39669 object, and the FROM EXPRESSION returns the original object given 39670 the pointer. The pointer will be available using the `%h' escape. 39671 39672`chain_next ("EXPRESSION")' 39673`chain_prev ("EXPRESSION")' 39674`chain_circular ("EXPRESSION")' 39675 It's helpful for the type machinery to know if objects are often 39676 chained together in long lists; this lets it generate code that 39677 uses less stack space by iterating along the list instead of 39678 recursing down it. `chain_next' is an expression for the next 39679 item in the list, `chain_prev' is an expression for the previous 39680 item. For singly linked lists, use only `chain_next'; for doubly 39681 linked lists, use both. The machinery requires that taking the 39682 next item of the previous item gives the original item. 39683 `chain_circular' is similar to `chain_next', but can be used for 39684 circular single linked lists. 39685 39686`reorder ("FUNCTION NAME")' 39687 Some data structures depend on the relative ordering of pointers. 39688 If the precompiled header machinery needs to change that ordering, 39689 it will call the function referenced by the `reorder' option, 39690 before changing the pointers in the object that's pointed to by 39691 the field the option applies to. The function must take four 39692 arguments, with the signature 39693 `void *, void *, gt_pointer_operator, void *'. The first 39694 parameter is a pointer to the structure that contains the object 39695 being updated, or the object itself if there is no containing 39696 structure. The second parameter is a cookie that should be 39697 ignored. The third parameter is a routine that, given a pointer, 39698 will update it to its correct new value. The fourth parameter is 39699 a cookie that must be passed to the second parameter. 39700 39701 PCH cannot handle data structures that depend on the absolute 39702 values of pointers. `reorder' functions can be expensive. When 39703 possible, it is better to depend on properties of the data, like 39704 an ID number or the hash of a string instead. 39705 39706`atomic' 39707 The `atomic' option can only be used with pointers. It informs 39708 the GC machinery that the memory that the pointer points to does 39709 not contain any pointers, and hence it should be treated by the GC 39710 and PCH machinery as an "atomic" block of memory that does not 39711 need to be examined when scanning memory for pointers. In 39712 particular, the machinery will not scan that memory for pointers 39713 to mark them as reachable (when marking pointers for GC) or to 39714 relocate them (when writing a PCH file). 39715 39716 The `atomic' option differs from the `skip' option. `atomic' 39717 keeps the memory under Garbage Collection, but makes the GC ignore 39718 the contents of the memory. `skip' is more drastic in that it 39719 causes the pointer and the memory to be completely ignored by the 39720 Garbage Collector. So, memory marked as `atomic' is automatically 39721 freed when no longer reachable, while memory marked as `skip' is 39722 not. 39723 39724 The `atomic' option must be used with great care, because all 39725 sorts of problem can occur if used incorrectly, that is, if the 39726 memory the pointer points to does actually contain a pointer. 39727 39728 Here is an example of how to use it: 39729 struct GTY(()) my_struct { 39730 int number_of_elements; 39731 unsigned int * GTY ((atomic)) elements; 39732 }; 39733 In this case, `elements' is a pointer under GC, and the memory it 39734 points to needs to be allocated using the Garbage Collector, and 39735 will be freed automatically by the Garbage Collector when it is no 39736 longer referenced. But the memory that the pointer points to is 39737 an array of `unsigned int' elements, and the GC must not try to 39738 scan it to find pointers to mark or relocate, which is why it is 39739 marked with the `atomic' option. 39740 39741 Note that, currently, global variables can not be marked with 39742 `atomic'; only fields of a struct can. This is a known 39743 limitation. It would be useful to be able to mark global pointers 39744 with `atomic' to make the PCH machinery aware of them so that they 39745 are saved and restored correctly to PCH files. 39746 39747`special ("NAME")' 39748 The `special' option is used to mark types that have to be dealt 39749 with by special case machinery. The parameter is the name of the 39750 special case. See `gengtype.c' for further details. Avoid adding 39751 new special cases unless there is no other alternative. 39752 39753`user' 39754 The `user' option indicates that the code to mark structure fields 39755 is completely handled by user-provided routines. See section 39756 *note User GC:: for details on what functions need to be provided. 39757 39758 39759File: gccint.info, Node: Inheritance and GTY, Next: User GC, Prev: GTY Options, Up: Type Information 39760 3976122.2 Support for inheritance 39762============================ 39763 39764gengtype has some support for simple class hierarchies. You can use 39765this to have gengtype autogenerate marking routines, provided: 39766 39767 * There must be a concrete base class, with a discriminator 39768 expression that can be used to identify which subclass an instance 39769 is. 39770 39771 * Only single inheritance is used. 39772 39773 * None of the classes within the hierarchy are templates. 39774 39775 If your class hierarchy does not fit in this pattern, you must use 39776*note User GC:: instead. 39777 39778 The base class and its discriminator must be identified using the 39779"desc" option. Each concrete subclass must use the "tag" option to 39780identify which value of the discriminator it corresponds to. 39781 39782 Every class in the hierarchy must have a `GTY(())' marker, as gengtype 39783will only attempt to parse classes that have such a marker (1). 39784 39785 class GTY((desc("%h.kind"), tag("0"))) example_base 39786 { 39787 public: 39788 int kind; 39789 tree a; 39790 }; 39791 39792 class GTY((tag("1")) some_subclass : public example_base 39793 { 39794 public: 39795 tree b; 39796 }; 39797 39798 class GTY((tag("2")) some_other_subclass : public example_base 39799 { 39800 public: 39801 tree c; 39802 }; 39803 39804 The generated marking routines for the above will contain a "switch" 39805on "kind", visiting all appropriate fields. For example, if kind is 2, 39806it will cast to "some_other_subclass" and visit fields a, b, and c. 39807 39808 ---------- Footnotes ---------- 39809 39810 (1) Classes lacking such a marker will not be identified as being part 39811of the hierarchy, and so the marking routines will not handle them, 39812leading to a assertion failure within the marking routines due to an 39813unknown tag value (assuming that assertions are enabled). 39814 39815 39816File: gccint.info, Node: User GC, Next: GGC Roots, Prev: Inheritance and GTY, Up: Type Information 39817 3981822.3 Support for user-provided GC marking routines 39819================================================== 39820 39821The garbage collector supports types for which no automatic marking 39822code is generated. For these types, the user is required to provide 39823three functions: one to act as a marker for garbage collection, and two 39824functions to act as marker and pointer walker for pre-compiled headers. 39825 39826 Given a structure `struct GTY((user)) my_struct', the following 39827functions should be defined to mark `my_struct': 39828 39829 void gt_ggc_mx (my_struct *p) 39830 { 39831 /* This marks field 'fld'. */ 39832 gt_ggc_mx (p->fld); 39833 } 39834 39835 void gt_pch_nx (my_struct *p) 39836 { 39837 /* This marks field 'fld'. */ 39838 gt_pch_nx (tp->fld); 39839 } 39840 39841 void gt_pch_nx (my_struct *p, gt_pointer_operator op, void *cookie) 39842 { 39843 /* For every field 'fld', call the given pointer operator. */ 39844 op (&(tp->fld), cookie); 39845 } 39846 39847 In general, each marker `M' should call `M' for every pointer field in 39848the structure. Fields that are not allocated in GC or are not pointers 39849must be ignored. 39850 39851 For embedded lists (e.g., structures with a `next' or `prev' pointer), 39852the marker must follow the chain and mark every element in it. 39853 39854 Note that the rules for the pointer walker `gt_pch_nx (my_struct *, 39855gt_pointer_operator, void *)' are slightly different. In this case, 39856the operation `op' must be applied to the _address_ of every pointer 39857field. 39858 3985922.3.1 User-provided marking routines for template types 39860-------------------------------------------------------- 39861 39862When a template type `TP' is marked with `GTY', all instances of that 39863type are considered user-provided types. This means that the 39864individual instances of `TP' do not need to be marked with `GTY'. The 39865user needs to provide template functions to mark all the fields of the 39866type. 39867 39868 The following code snippets represent all the functions that need to 39869be provided. Note that type `TP' may reference to more than one type. 39870In these snippets, there is only one type `T', but there could be more. 39871 39872 template<typename T> 39873 void gt_ggc_mx (TP<T> *tp) 39874 { 39875 extern void gt_ggc_mx (T&); 39876 39877 /* This marks field 'fld' of type 'T'. */ 39878 gt_ggc_mx (tp->fld); 39879 } 39880 39881 template<typename T> 39882 void gt_pch_nx (TP<T> *tp) 39883 { 39884 extern void gt_pch_nx (T&); 39885 39886 /* This marks field 'fld' of type 'T'. */ 39887 gt_pch_nx (tp->fld); 39888 } 39889 39890 template<typename T> 39891 void gt_pch_nx (TP<T *> *tp, gt_pointer_operator op, void *cookie) 39892 { 39893 /* For every field 'fld' of 'tp' with type 'T *', call the given 39894 pointer operator. */ 39895 op (&(tp->fld), cookie); 39896 } 39897 39898 template<typename T> 39899 void gt_pch_nx (TP<T> *tp, gt_pointer_operator, void *cookie) 39900 { 39901 extern void gt_pch_nx (T *, gt_pointer_operator, void *); 39902 39903 /* For every field 'fld' of 'tp' with type 'T', call the pointer 39904 walker for all the fields of T. */ 39905 gt_pch_nx (&(tp->fld), op, cookie); 39906 } 39907 39908 Support for user-defined types is currently limited. The following 39909restrictions apply: 39910 39911 1. Type `TP' and all the argument types `T' must be marked with `GTY'. 39912 39913 2. Type `TP' can only have type names in its argument list. 39914 39915 3. The pointer walker functions are different for `TP<T>' and `TP<T 39916 *>'. In the case of `TP<T>', references to `T' must be handled by 39917 calling `gt_pch_nx' (which will, in turn, walk all the pointers 39918 inside fields of `T'). In the case of `TP<T *>', references to `T 39919 *' must be handled by calling the `op' function on the address of 39920 the pointer (see the code snippets above). 39921 39922 39923File: gccint.info, Node: GGC Roots, Next: Files, Prev: User GC, Up: Type Information 39924 3992522.4 Marking Roots for the Garbage Collector 39926============================================ 39927 39928In addition to keeping track of types, the type machinery also locates 39929the global variables ("roots") that the garbage collector starts at. 39930Roots must be declared using one of the following syntaxes: 39931 39932 * `extern GTY(([OPTIONS])) TYPE NAME;' 39933 39934 * `static GTY(([OPTIONS])) TYPE NAME;' 39935 The syntax 39936 * `GTY(([OPTIONS])) TYPE NAME;' 39937 is _not_ accepted. There should be an `extern' declaration of such a 39938variable in a header somewhere--mark that, not the definition. Or, if 39939the variable is only used in one file, make it `static'. 39940 39941 39942File: gccint.info, Node: Files, Next: Invoking the garbage collector, Prev: GGC Roots, Up: Type Information 39943 3994422.5 Source Files Containing Type Information 39945============================================= 39946 39947Whenever you add `GTY' markers to a source file that previously had 39948none, or create a new source file containing `GTY' markers, there are 39949three things you need to do: 39950 39951 1. You need to add the file to the list of source files the type 39952 machinery scans. There are four cases: 39953 39954 a. For a back-end file, this is usually done automatically; if 39955 not, you should add it to `target_gtfiles' in the appropriate 39956 port's entries in `config.gcc'. 39957 39958 b. For files shared by all front ends, add the filename to the 39959 `GTFILES' variable in `Makefile.in'. 39960 39961 c. For files that are part of one front end, add the filename to 39962 the `gtfiles' variable defined in the appropriate 39963 `config-lang.in'. Headers should appear before non-headers 39964 in this list. 39965 39966 d. For files that are part of some but not all front ends, add 39967 the filename to the `gtfiles' variable of _all_ the front ends 39968 that use it. 39969 39970 2. If the file was a header file, you'll need to check that it's 39971 included in the right place to be visible to the generated files. 39972 For a back-end header file, this should be done automatically. 39973 For a front-end header file, it needs to be included by the same 39974 file that includes `gtype-LANG.h'. For other header files, it 39975 needs to be included in `gtype-desc.c', which is a generated file, 39976 so add it to `ifiles' in `open_base_file' in `gengtype.c'. 39977 39978 For source files that aren't header files, the machinery will 39979 generate a header file that should be included in the source file 39980 you just changed. The file will be called `gt-PATH.h' where PATH 39981 is the pathname relative to the `gcc' directory with slashes 39982 replaced by -, so for example the header file to be included in 39983 `cp/parser.c' is called `gt-cp-parser.c'. The generated header 39984 file should be included after everything else in the source file. 39985 Don't forget to mention this file as a dependency in the 39986 `Makefile'! 39987 39988 39989 For language frontends, there is another file that needs to be included 39990somewhere. It will be called `gtype-LANG.h', where LANG is the name of 39991the subdirectory the language is contained in. 39992 39993 Plugins can add additional root tables. Run the `gengtype' utility in 39994plugin mode as `gengtype -P pluginout.h SOURCE-DIR FILE-LIST PLUGIN*.C' 39995with your plugin files PLUGIN*.C using `GTY' to generate the 39996PLUGINOUT.H file. The GCC build tree is needed to be present in that 39997mode. 39998 39999 40000File: gccint.info, Node: Invoking the garbage collector, Next: Troubleshooting, Prev: Files, Up: Type Information 40001 4000222.6 How to invoke the garbage collector 40003======================================== 40004 40005The GCC garbage collector GGC is only invoked explicitly. In contrast 40006with many other garbage collectors, it is not implicitly invoked by 40007allocation routines when a lot of memory has been consumed. So the only 40008way to have GGC reclaim storage is to call the `ggc_collect' function 40009explicitly. This call is an expensive operation, as it may have to 40010scan the entire heap. Beware that local variables (on the GCC call 40011stack) are not followed by such an invocation (as many other garbage 40012collectors do): you should reference all your data from static or 40013external `GTY'-ed variables, and it is advised to call `ggc_collect' 40014with a shallow call stack. The GGC is an exact mark and sweep garbage 40015collector (so it does not scan the call stack for pointers). In 40016practice GCC passes don't often call `ggc_collect' themselves, because 40017it is called by the pass manager between passes. 40018 40019 At the time of the `ggc_collect' call all pointers in the GC-marked 40020structures must be valid or `NULL'. In practice this means that there 40021should not be uninitialized pointer fields in the structures even if 40022your code never reads or writes those fields at a particular instance. 40023One way to ensure this is to use cleared versions of allocators unless 40024all the fields are initialized manually immediately after allocation. 40025 40026 40027File: gccint.info, Node: Troubleshooting, Prev: Invoking the garbage collector, Up: Type Information 40028 4002922.7 Troubleshooting the garbage collector 40030========================================== 40031 40032With the current garbage collector implementation, most issues should 40033show up as GCC compilation errors. Some of the most commonly 40034encountered issues are described below. 40035 40036 * Gengtype does not produce allocators for a `GTY'-marked type. 40037 Gengtype checks if there is at least one possible path from GC 40038 roots to at least one instance of each type before outputting 40039 allocators. If there is no such path, the `GTY' markers will be 40040 ignored and no allocators will be output. Solve this by making 40041 sure that there exists at least one such path. If creating it is 40042 unfeasible or raises a "code smell", consider if you really must 40043 use GC for allocating such type. 40044 40045 * Link-time errors about undefined `gt_ggc_r_foo_bar' and 40046 similarly-named symbols. Check if your `foo_bar' source file has 40047 `#include "gt-foo_bar.h"' as its very last line. 40048 40049 40050 40051File: gccint.info, Node: Plugins, Next: LTO, Prev: Type Information, Up: Top 40052 4005323 Plugins 40054********** 40055 40056GCC plugins are loadable modules that provide extra features to the 40057compiler. Like GCC itself they can be distributed in source and binary 40058forms. 40059 40060 GCC plugins provide developers with a rich subset of the GCC API to 40061allow them to extend GCC as they see fit. Whether it is writing an 40062additional optimization pass, transforming code, or analyzing 40063information, plugins can be quite useful. 40064 40065* Menu: 40066 40067* Plugins loading:: How can we load plugins. 40068* Plugin API:: The APIs for plugins. 40069* Plugins pass:: How a plugin interact with the pass manager. 40070* Plugins GC:: How a plugin Interact with GCC Garbage Collector. 40071* Plugins description:: Giving information about a plugin itself. 40072* Plugins attr:: Registering custom attributes or pragmas. 40073* Plugins recording:: Recording information about pass execution. 40074* Plugins gate:: Controlling which passes are being run. 40075* Plugins tracking:: Keeping track of available passes. 40076* Plugins building:: How can we build a plugin. 40077 40078 40079File: gccint.info, Node: Plugins loading, Next: Plugin API, Up: Plugins 40080 4008123.1 Loading Plugins 40082==================== 40083 40084Plugins are supported on platforms that support `-ldl -rdynamic'. They 40085are loaded by the compiler using `dlopen' and invoked at pre-determined 40086locations in the compilation process. 40087 40088 Plugins are loaded with 40089 40090 `-fplugin=/path/to/NAME.so' `-fplugin-arg-NAME-KEY1[=VALUE1]' 40091 40092 The plugin arguments are parsed by GCC and passed to respective 40093plugins as key-value pairs. Multiple plugins can be invoked by 40094specifying multiple `-fplugin' arguments. 40095 40096 A plugin can be simply given by its short name (no dots or slashes). 40097When simply passing `-fplugin=NAME', the plugin is loaded from the 40098`plugin' directory, so `-fplugin=NAME' is the same as `-fplugin=`gcc 40099-print-file-name=plugin`/NAME.so', using backquote shell syntax to 40100query the `plugin' directory. 40101 40102 40103File: gccint.info, Node: Plugin API, Next: Plugins pass, Prev: Plugins loading, Up: Plugins 40104 4010523.2 Plugin API 40106=============== 40107 40108Plugins are activated by the compiler at specific events as defined in 40109`gcc-plugin.h'. For each event of interest, the plugin should call 40110`register_callback' specifying the name of the event and address of the 40111callback function that will handle that event. 40112 40113 The header `gcc-plugin.h' must be the first gcc header to be included. 40114 4011523.2.1 Plugin license check 40116--------------------------- 40117 40118Every plugin should define the global symbol `plugin_is_GPL_compatible' 40119to assert that it has been licensed under a GPL-compatible license. If 40120this symbol does not exist, the compiler will emit a fatal error and 40121exit with the error message: 40122 40123 fatal error: plugin NAME is not licensed under a GPL-compatible license 40124 NAME: undefined symbol: plugin_is_GPL_compatible 40125 compilation terminated 40126 40127 The declared type of the symbol should be int, to match a forward 40128declaration in `gcc-plugin.h' that suppresses C++ mangling. It does 40129not need to be in any allocated section, though. The compiler merely 40130asserts that the symbol exists in the global scope. Something like 40131this is enough: 40132 40133 int plugin_is_GPL_compatible; 40134 4013523.2.2 Plugin initialization 40136---------------------------- 40137 40138Every plugin should export a function called `plugin_init' that is 40139called right after the plugin is loaded. This function is responsible 40140for registering all the callbacks required by the plugin and do any 40141other required initialization. 40142 40143 This function is called from `compile_file' right before invoking the 40144parser. The arguments to `plugin_init' are: 40145 40146 * `plugin_info': Plugin invocation information. 40147 40148 * `version': GCC version. 40149 40150 The `plugin_info' struct is defined as follows: 40151 40152 struct plugin_name_args 40153 { 40154 char *base_name; /* Short name of the plugin 40155 (filename without .so suffix). */ 40156 const char *full_name; /* Path to the plugin as specified with 40157 -fplugin=. */ 40158 int argc; /* Number of arguments specified with 40159 -fplugin-arg-.... */ 40160 struct plugin_argument *argv; /* Array of ARGC key-value pairs. */ 40161 const char *version; /* Version string provided by plugin. */ 40162 const char *help; /* Help string provided by plugin. */ 40163 } 40164 40165 If initialization fails, `plugin_init' must return a non-zero value. 40166Otherwise, it should return 0. 40167 40168 The version of the GCC compiler loading the plugin is described by the 40169following structure: 40170 40171 struct plugin_gcc_version 40172 { 40173 const char *basever; 40174 const char *datestamp; 40175 const char *devphase; 40176 const char *revision; 40177 const char *configuration_arguments; 40178 }; 40179 40180 The function `plugin_default_version_check' takes two pointers to such 40181structure and compare them field by field. It can be used by the 40182plugin's `plugin_init' function. 40183 40184 The version of GCC used to compile the plugin can be found in the 40185symbol `gcc_version' defined in the header `plugin-version.h'. The 40186recommended version check to perform looks like 40187 40188 #include "plugin-version.h" 40189 ... 40190 40191 int 40192 plugin_init (struct plugin_name_args *plugin_info, 40193 struct plugin_gcc_version *version) 40194 { 40195 if (!plugin_default_version_check (version, &gcc_version)) 40196 return 1; 40197 40198 } 40199 40200 but you can also check the individual fields if you want a less strict 40201check. 40202 4020323.2.3 Plugin callbacks 40204----------------------- 40205 40206Callback functions have the following prototype: 40207 40208 /* The prototype for a plugin callback function. 40209 gcc_data - event-specific data provided by GCC 40210 user_data - plugin-specific data provided by the plug-in. */ 40211 typedef void (*plugin_callback_func)(void *gcc_data, void *user_data); 40212 40213 Callbacks can be invoked at the following pre-determined events: 40214 40215 enum plugin_event 40216 { 40217 PLUGIN_PASS_MANAGER_SETUP, /* To hook into pass manager. */ 40218 PLUGIN_FINISH_TYPE, /* After finishing parsing a type. */ 40219 PLUGIN_FINISH_DECL, /* After finishing parsing a declaration. */ 40220 PLUGIN_FINISH_UNIT, /* Useful for summary processing. */ 40221 PLUGIN_PRE_GENERICIZE, /* Allows to see low level AST in C and C++ frontends. */ 40222 PLUGIN_FINISH, /* Called before GCC exits. */ 40223 PLUGIN_INFO, /* Information about the plugin. */ 40224 PLUGIN_GGC_START, /* Called at start of GCC Garbage Collection. */ 40225 PLUGIN_GGC_MARKING, /* Extend the GGC marking. */ 40226 PLUGIN_GGC_END, /* Called at end of GGC. */ 40227 PLUGIN_REGISTER_GGC_ROOTS, /* Register an extra GGC root table. */ 40228 PLUGIN_ATTRIBUTES, /* Called during attribute registration */ 40229 PLUGIN_START_UNIT, /* Called before processing a translation unit. */ 40230 PLUGIN_PRAGMAS, /* Called during pragma registration. */ 40231 /* Called before first pass from all_passes. */ 40232 PLUGIN_ALL_PASSES_START, 40233 /* Called after last pass from all_passes. */ 40234 PLUGIN_ALL_PASSES_END, 40235 /* Called before first ipa pass. */ 40236 PLUGIN_ALL_IPA_PASSES_START, 40237 /* Called after last ipa pass. */ 40238 PLUGIN_ALL_IPA_PASSES_END, 40239 /* Allows to override pass gate decision for current_pass. */ 40240 PLUGIN_OVERRIDE_GATE, 40241 /* Called before executing a pass. */ 40242 PLUGIN_PASS_EXECUTION, 40243 /* Called before executing subpasses of a GIMPLE_PASS in 40244 execute_ipa_pass_list. */ 40245 PLUGIN_EARLY_GIMPLE_PASSES_START, 40246 /* Called after executing subpasses of a GIMPLE_PASS in 40247 execute_ipa_pass_list. */ 40248 PLUGIN_EARLY_GIMPLE_PASSES_END, 40249 /* Called when a pass is first instantiated. */ 40250 PLUGIN_NEW_PASS, 40251 /* Called when a file is #include-d or given via the #line directive. 40252 This could happen many times. The event data is the included file path, 40253 as a const char* pointer. */ 40254 PLUGIN_INCLUDE_FILE, 40255 40256 PLUGIN_EVENT_FIRST_DYNAMIC /* Dummy event used for indexing callback 40257 array. */ 40258 }; 40259 40260 In addition, plugins can also look up the enumerator of a named event, 40261and / or generate new events dynamically, by calling the function 40262`get_named_event_id'. 40263 40264 To register a callback, the plugin calls `register_callback' with the 40265arguments: 40266 40267 * `char *name': Plugin name. 40268 40269 * `int event': The event code. 40270 40271 * `plugin_callback_func callback': The function that handles `event'. 40272 40273 * `void *user_data': Pointer to plugin-specific data. 40274 40275 For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, and 40276PLUGIN_REGISTER_GGC_ROOTS pseudo-events the `callback' should be null, 40277and the `user_data' is specific. 40278 40279 When the PLUGIN_PRAGMAS event is triggered (with a null pointer as 40280data from GCC), plugins may register their own pragmas. Notice that 40281pragmas are not available from `lto1', so plugins used with `-flto' 40282option to GCC during link-time optimization cannot use pragmas and do 40283not even see functions like `c_register_pragma' or `pragma_lex'. 40284 40285 The PLUGIN_INCLUDE_FILE event, with a `const char*' file path as GCC 40286data, is triggered for processing of `#include' or `#line' directives. 40287 40288 The PLUGIN_FINISH event is the last time that plugins can call GCC 40289functions, notably emit diagnostics with `warning', `error' etc. 40290 40291 40292File: gccint.info, Node: Plugins pass, Next: Plugins GC, Prev: Plugin API, Up: Plugins 40293 4029423.3 Interacting with the pass manager 40295====================================== 40296 40297There needs to be a way to add/reorder/remove passes dynamically. This 40298is useful for both analysis plugins (plugging in after a certain pass 40299such as CFG or an IPA pass) and optimization plugins. 40300 40301 Basic support for inserting new passes or replacing existing passes is 40302provided. A plugin registers a new pass with GCC by calling 40303`register_callback' with the `PLUGIN_PASS_MANAGER_SETUP' event and a 40304pointer to a `struct register_pass_info' object defined as follows 40305 40306 enum pass_positioning_ops 40307 { 40308 PASS_POS_INSERT_AFTER, // Insert after the reference pass. 40309 PASS_POS_INSERT_BEFORE, // Insert before the reference pass. 40310 PASS_POS_REPLACE // Replace the reference pass. 40311 }; 40312 40313 struct register_pass_info 40314 { 40315 struct opt_pass *pass; /* New pass provided by the plugin. */ 40316 const char *reference_pass_name; /* Name of the reference pass for hooking 40317 up the new pass. */ 40318 int ref_pass_instance_number; /* Insert the pass at the specified 40319 instance number of the reference pass. */ 40320 /* Do it for every instance if it is 0. */ 40321 enum pass_positioning_ops pos_op; /* how to insert the new pass. */ 40322 }; 40323 40324 40325 /* Sample plugin code that registers a new pass. */ 40326 int 40327 plugin_init (struct plugin_name_args *plugin_info, 40328 struct plugin_gcc_version *version) 40329 { 40330 struct register_pass_info pass_info; 40331 40332 ... 40333 40334 /* Code to fill in the pass_info object with new pass information. */ 40335 40336 ... 40337 40338 /* Register the new pass. */ 40339 register_callback (plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &pass_info); 40340 40341 ... 40342 } 40343 40344 40345File: gccint.info, Node: Plugins GC, Next: Plugins description, Prev: Plugins pass, Up: Plugins 40346 4034723.4 Interacting with the GCC Garbage Collector 40348=============================================== 40349 40350Some plugins may want to be informed when GGC (the GCC Garbage 40351Collector) is running. They can register callbacks for the 40352`PLUGIN_GGC_START' and `PLUGIN_GGC_END' events (for which the callback 40353is called with a null `gcc_data') to be notified of the start or end of 40354the GCC garbage collection. 40355 40356 Some plugins may need to have GGC mark additional data. This can be 40357done by registering a callback (called with a null `gcc_data') for the 40358`PLUGIN_GGC_MARKING' event. Such callbacks can call the `ggc_set_mark' 40359routine, preferably through the `ggc_mark' macro (and conversely, these 40360routines should usually not be used in plugins outside of the 40361`PLUGIN_GGC_MARKING' event). Plugins that wish to hold weak references 40362to gc data may also use this event to drop weak references when the 40363object is about to be collected. The `ggc_marked_p' function can be 40364used to tell if an object is marked, or is about to be collected. The 40365`gt_clear_cache' overloads which some types define may also be of use in 40366managing weak references. 40367 40368 Some plugins may need to add extra GGC root tables, e.g. to handle 40369their own `GTY'-ed data. This can be done with the 40370`PLUGIN_REGISTER_GGC_ROOTS' pseudo-event with a null callback and the 40371extra root table (of type `struct ggc_root_tab*') as `user_data'. 40372Running the `gengtype -p SOURCE-DIR FILE-LIST PLUGIN*.C ...' utility 40373generates these extra root tables. 40374 40375 You should understand the details of memory management inside GCC 40376before using `PLUGIN_GGC_MARKING' or `PLUGIN_REGISTER_GGC_ROOTS'. 40377 40378 40379File: gccint.info, Node: Plugins description, Next: Plugins attr, Prev: Plugins GC, Up: Plugins 40380 4038123.5 Giving information about a plugin 40382====================================== 40383 40384A plugin should give some information to the user about itself. This 40385uses the following structure: 40386 40387 struct plugin_info 40388 { 40389 const char *version; 40390 const char *help; 40391 }; 40392 40393 Such a structure is passed as the `user_data' by the plugin's init 40394routine using `register_callback' with the `PLUGIN_INFO' pseudo-event 40395and a null callback. 40396 40397 40398File: gccint.info, Node: Plugins attr, Next: Plugins recording, Prev: Plugins description, Up: Plugins 40399 4040023.6 Registering custom attributes or pragmas 40401============================================= 40402 40403For analysis (or other) purposes it is useful to be able to add custom 40404attributes or pragmas. 40405 40406 The `PLUGIN_ATTRIBUTES' callback is called during attribute 40407registration. Use the `register_attribute' function to register custom 40408attributes. 40409 40410 /* Attribute handler callback */ 40411 static tree 40412 handle_user_attribute (tree *node, tree name, tree args, 40413 int flags, bool *no_add_attrs) 40414 { 40415 return NULL_TREE; 40416 } 40417 40418 /* Attribute definition */ 40419 static struct attribute_spec user_attr = 40420 { "user", 1, 1, false, false, false, handle_user_attribute, false }; 40421 40422 /* Plugin callback called during attribute registration. 40423 Registered with register_callback (plugin_name, PLUGIN_ATTRIBUTES, register_attributes, NULL) 40424 */ 40425 static void 40426 register_attributes (void *event_data, void *data) 40427 { 40428 warning (0, G_("Callback to register attributes")); 40429 register_attribute (&user_attr); 40430 } 40431 40432 The PLUGIN_PRAGMAS callback is called once during pragmas 40433registration. Use the `c_register_pragma', 40434`c_register_pragma_with_data', `c_register_pragma_with_expansion', 40435`c_register_pragma_with_expansion_and_data' functions to register 40436custom pragmas and their handlers (which often want to call 40437`pragma_lex') from `c-family/c-pragma.h'. 40438 40439 /* Plugin callback called during pragmas registration. Registered with 40440 register_callback (plugin_name, PLUGIN_PRAGMAS, 40441 register_my_pragma, NULL); 40442 */ 40443 static void 40444 register_my_pragma (void *event_data, void *data) 40445 { 40446 warning (0, G_("Callback to register pragmas")); 40447 c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello); 40448 } 40449 40450 It is suggested to pass `"GCCPLUGIN"' (or a short name identifying 40451your plugin) as the "space" argument of your pragma. 40452 40453 Pragmas registered with `c_register_pragma_with_expansion' or 40454`c_register_pragma_with_expansion_and_data' support preprocessor 40455expansions. For example: 40456 40457 #define NUMBER 10 40458 #pragma GCCPLUGIN foothreshold (NUMBER) 40459 40460 40461File: gccint.info, Node: Plugins recording, Next: Plugins gate, Prev: Plugins attr, Up: Plugins 40462 4046323.7 Recording information about pass execution 40464=============================================== 40465 40466The event PLUGIN_PASS_EXECUTION passes the pointer to the executed pass 40467(the same as current_pass) as `gcc_data' to the callback. You can also 40468inspect cfun to find out about which function this pass is executed for. 40469Note that this event will only be invoked if the gate check (if 40470applicable, modified by PLUGIN_OVERRIDE_GATE) succeeds. You can use 40471other hooks, like `PLUGIN_ALL_PASSES_START', `PLUGIN_ALL_PASSES_END', 40472`PLUGIN_ALL_IPA_PASSES_START', `PLUGIN_ALL_IPA_PASSES_END', 40473`PLUGIN_EARLY_GIMPLE_PASSES_START', and/or 40474`PLUGIN_EARLY_GIMPLE_PASSES_END' to manipulate global state in your 40475plugin(s) in order to get context for the pass execution. 40476 40477 40478File: gccint.info, Node: Plugins gate, Next: Plugins tracking, Prev: Plugins recording, Up: Plugins 40479 4048023.8 Controlling which passes are being run 40481=========================================== 40482 40483After the original gate function for a pass is called, its result - the 40484gate status - is stored as an integer. Then the event 40485`PLUGIN_OVERRIDE_GATE' is invoked, with a pointer to the gate status in 40486the `gcc_data' parameter to the callback function. A nonzero value of 40487the gate status means that the pass is to be executed. You can both 40488read and write the gate status via the passed pointer. 40489 40490 40491File: gccint.info, Node: Plugins tracking, Next: Plugins building, Prev: Plugins gate, Up: Plugins 40492 4049323.9 Keeping track of available passes 40494====================================== 40495 40496When your plugin is loaded, you can inspect the various pass lists to 40497determine what passes are available. However, other plugins might add 40498new passes. Also, future changes to GCC might cause generic passes to 40499be added after plugin loading. When a pass is first added to one of 40500the pass lists, the event `PLUGIN_NEW_PASS' is invoked, with the 40501callback parameter `gcc_data' pointing to the new pass. 40502 40503 40504File: gccint.info, Node: Plugins building, Prev: Plugins tracking, Up: Plugins 40505 4050623.10 Building GCC plugins 40507========================== 40508 40509If plugins are enabled, GCC installs the headers needed to build a 40510plugin (somewhere in the installation tree, e.g. under `/usr/local'). 40511In particular a `plugin/include' directory is installed, containing all 40512the header files needed to build plugins. 40513 40514 On most systems, you can query this `plugin' directory by invoking 40515`gcc -print-file-name=plugin' (replace if needed `gcc' with the 40516appropriate program path). 40517 40518 Inside plugins, this `plugin' directory name can be queried by calling 40519`default_plugin_dir_name ()'. 40520 40521 Plugins may know, when they are compiled, the GCC version for which 40522`plugin-version.h' is provided. The constant macros 40523`GCCPLUGIN_VERSION_MAJOR', `GCCPLUGIN_VERSION_MINOR', 40524`GCCPLUGIN_VERSION_PATCHLEVEL', `GCCPLUGIN_VERSION' are integer 40525numbers, so a plugin could ensure it is built for GCC 4.7 with 40526 #if GCCPLUGIN_VERSION != 4007 40527 #error this GCC plugin is for GCC 4.7 40528 #endif 40529 40530 The following GNU Makefile excerpt shows how to build a simple plugin: 40531 40532 HOST_GCC=g++ 40533 TARGET_GCC=gcc 40534 PLUGIN_SOURCE_FILES= plugin1.c plugin2.cc 40535 GCCPLUGINS_DIR:= $(shell $(TARGET_GCC) -print-file-name=plugin) 40536 CXXFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC -fno-rtti -O2 40537 40538 plugin.so: $(PLUGIN_SOURCE_FILES) 40539 $(HOST_GCC) -shared $(CXXFLAGS) $^ -o $@ 40540 40541 A single source file plugin may be built with `g++ -I`gcc 40542-print-file-name=plugin`/include -fPIC -shared -fno-rtti -O2 plugin.c -o 40543plugin.so', using backquote shell syntax to query the `plugin' 40544directory. 40545 40546 When a plugin needs to use `gengtype', be sure that both `gengtype' 40547and `gtype.state' have the same version as the GCC for which the plugin 40548is built. 40549 40550 40551File: gccint.info, Node: LTO, Next: Match and Simplify, Prev: Plugins, Up: Top 40552 4055324 Link Time Optimization 40554************************* 40555 40556Link Time Optimization (LTO) gives GCC the capability of dumping its 40557internal representation (GIMPLE) to disk, so that all the different 40558compilation units that make up a single executable can be optimized as 40559a single module. This expands the scope of inter-procedural 40560optimizations to encompass the whole program (or, rather, everything 40561that is visible at link time). 40562 40563* Menu: 40564 40565* LTO Overview:: Overview of LTO. 40566* LTO object file layout:: LTO file sections in ELF. 40567* IPA:: Using summary information in IPA passes. 40568* WHOPR:: Whole program assumptions, 40569 linker plugin and symbol visibilities. 40570* Internal flags:: Internal flags controlling `lto1'. 40571 40572 40573File: gccint.info, Node: LTO Overview, Next: LTO object file layout, Up: LTO 40574 4057524.1 Design Overview 40576==================== 40577 40578Link time optimization is implemented as a GCC front end for a bytecode 40579representation of GIMPLE that is emitted in special sections of `.o' 40580files. Currently, LTO support is enabled in most ELF-based systems, as 40581well as darwin, cygwin and mingw systems. 40582 40583 Since GIMPLE bytecode is saved alongside final object code, object 40584files generated with LTO support are larger than regular object files. 40585This "fat" object format makes it easy to integrate LTO into existing 40586build systems, as one can, for instance, produce archives of the files. 40587Additionally, one might be able to ship one set of fat objects which 40588could be used both for development and the production of optimized 40589builds. A, perhaps surprising, side effect of this feature is that any 40590mistake in the toolchain that leads to LTO information not being used 40591(e.g. an older `libtool' calling `ld' directly). This is both an 40592advantage, as the system is more robust, and a disadvantage, as the 40593user is not informed that the optimization has been disabled. 40594 40595 The current implementation only produces "fat" objects, effectively 40596doubling compilation time and increasing file sizes up to 5x the 40597original size. This hides the problem that some tools, such as `ar' 40598and `nm', need to understand symbol tables of LTO sections. These 40599tools were extended to use the plugin infrastructure, and with these 40600problems solved, GCC will also support "slim" objects consisting of the 40601intermediate code alone. 40602 40603 At the highest level, LTO splits the compiler in two. The first half 40604(the "writer") produces a streaming representation of all the internal 40605data structures needed to optimize and generate code. This includes 40606declarations, types, the callgraph and the GIMPLE representation of 40607function bodies. 40608 40609 When `-flto' is given during compilation of a source file, the pass 40610manager executes all the passes in `all_lto_gen_passes'. Currently, 40611this phase is composed of two IPA passes: 40612 40613 * `pass_ipa_lto_gimple_out' This pass executes the function 40614 `lto_output' in `lto-streamer-out.c', which traverses the call 40615 graph encoding every reachable declaration, type and function. 40616 This generates a memory representation of all the file sections 40617 described below. 40618 40619 * `pass_ipa_lto_finish_out' This pass executes the function 40620 `produce_asm_for_decls' in `lto-streamer-out.c', which takes the 40621 memory image built in the previous pass and encodes it in the 40622 corresponding ELF file sections. 40623 40624 The second half of LTO support is the "reader". This is implemented 40625as the GCC front end `lto1' in `lto/lto.c'. When `collect2' detects a 40626link set of `.o'/`.a' files with LTO information and the `-flto' is 40627enabled, it invokes `lto1' which reads the set of files and aggregates 40628them into a single translation unit for optimization. The main entry 40629point for the reader is `lto/lto.c':`lto_main'. 40630 4063124.1.1 LTO modes of operation 40632----------------------------- 40633 40634One of the main goals of the GCC link-time infrastructure was to allow 40635effective compilation of large programs. For this reason GCC 40636implements two link-time compilation modes. 40637 40638 1. _LTO mode_, in which the whole program is read into the compiler 40639 at link-time and optimized in a similar way as if it were a single 40640 source-level compilation unit. 40641 40642 2. _WHOPR or partitioned mode_, designed to utilize multiple CPUs 40643 and/or a distributed compilation environment to quickly link large 40644 applications. WHOPR stands for WHOle Program optimizeR (not to be 40645 confused with the semantics of `-fwhole-program'). It partitions 40646 the aggregated callgraph from many different `.o' files and 40647 distributes the compilation of the sub-graphs to different CPUs. 40648 40649 Note that distributed compilation is not implemented yet, but since 40650 the parallelism is facilitated via generating a `Makefile', it 40651 would be easy to implement. 40652 40653 WHOPR splits LTO into three main stages: 40654 1. Local generation (LGEN) This stage executes in parallel. Every 40655 file in the program is compiled into the intermediate language and 40656 packaged together with the local call-graph and summary 40657 information. This stage is the same for both the LTO and WHOPR 40658 compilation mode. 40659 40660 2. Whole Program Analysis (WPA) WPA is performed sequentially. The 40661 global call-graph is generated, and a global analysis procedure 40662 makes transformation decisions. The global call-graph is 40663 partitioned to facilitate parallel optimization during phase 3. 40664 The results of the WPA stage are stored into new object files 40665 which contain the partitions of program expressed in the 40666 intermediate language and the optimization decisions. 40667 40668 3. Local transformations (LTRANS) This stage executes in parallel. 40669 All the decisions made during phase 2 are implemented locally in 40670 each partitioned object file, and the final object code is 40671 generated. Optimizations which cannot be decided efficiently 40672 during the phase 2 may be performed on the local call-graph 40673 partitions. 40674 40675 WHOPR can be seen as an extension of the usual LTO mode of 40676compilation. In LTO, WPA and LTRANS are executed within a single 40677execution of the compiler, after the whole program has been read into 40678memory. 40679 40680 When compiling in WHOPR mode, the callgraph is partitioned during the 40681WPA stage. The whole program is split into a given number of 40682partitions of roughly the same size. The compiler tries to minimize 40683the number of references which cross partition boundaries. The main 40684advantage of WHOPR is to allow the parallel execution of LTRANS stages, 40685which are the most time-consuming part of the compilation process. 40686Additionally, it avoids the need to load the whole program into memory. 40687 40688 40689File: gccint.info, Node: LTO object file layout, Next: IPA, Prev: LTO Overview, Up: LTO 40690 4069124.2 LTO file sections 40692====================== 40693 40694LTO information is stored in several ELF sections inside object files. 40695Data structures and enum codes for sections are defined in 40696`lto-streamer.h'. 40697 40698 These sections are emitted from `lto-streamer-out.c' and mapped in all 40699at once from `lto/lto.c':`lto_file_read'. The individual functions 40700dealing with the reading/writing of each section are described below. 40701 40702 * Command line options (`.gnu.lto_.opts') 40703 40704 This section contains the command line options used to generate the 40705 object files. This is used at link time to determine the 40706 optimization level and other settings when they are not explicitly 40707 specified at the linker command line. 40708 40709 Currently, GCC does not support combining LTO object files compiled 40710 with different set of the command line options into a single 40711 binary. At link time, the options given on the command line and 40712 the options saved on all the files in a link-time set are applied 40713 globally. No attempt is made at validating the combination of 40714 flags (other than the usual validation done by option processing). 40715 This is implemented in `lto/lto.c':`lto_read_all_file_options'. 40716 40717 * Symbol table (`.gnu.lto_.symtab') 40718 40719 This table replaces the ELF symbol table for functions and 40720 variables represented in the LTO IL. Symbols used and exported by 40721 the optimized assembly code of "fat" objects might not match the 40722 ones used and exported by the intermediate code. This table is 40723 necessary because the intermediate code is less optimized and thus 40724 requires a separate symbol table. 40725 40726 Additionally, the binary code in the "fat" object will lack a call 40727 to a function, since the call was optimized out at compilation time 40728 after the intermediate language was streamed out. In some special 40729 cases, the same optimization may not happen during link-time 40730 optimization. This would lead to an undefined symbol if only one 40731 symbol table was used. 40732 40733 The symbol table is emitted in 40734 `lto-streamer-out.c':`produce_symtab'. 40735 40736 * Global declarations and types (`.gnu.lto_.decls') 40737 40738 This section contains an intermediate language dump of all 40739 declarations and types required to represent the callgraph, static 40740 variables and top-level debug info. 40741 40742 The contents of this section are emitted in 40743 `lto-streamer-out.c':`produce_asm_for_decls'. Types and symbols 40744 are emitted in a topological order that preserves the sharing of 40745 pointers when the file is read back in 40746 (`lto.c':`read_cgraph_and_symbols'). 40747 40748 * The callgraph (`.gnu.lto_.cgraph') 40749 40750 This section contains the basic data structure used by the GCC 40751 inter-procedural optimization infrastructure. This section stores 40752 an annotated multi-graph which represents the functions and call 40753 sites as well as the variables, aliases and top-level `asm' 40754 statements. 40755 40756 This section is emitted in `lto-streamer-out.c':`output_cgraph' 40757 and read in `lto-cgraph.c':`input_cgraph'. 40758 40759 * IPA references (`.gnu.lto_.refs') 40760 40761 This section contains references between function and static 40762 variables. It is emitted by `lto-cgraph.c':`output_refs' and read 40763 by `lto-cgraph.c':`input_refs'. 40764 40765 * Function bodies (`.gnu.lto_.function_body.<name>') 40766 40767 This section contains function bodies in the intermediate language 40768 representation. Every function body is in a separate section to 40769 allow copying of the section independently to different object 40770 files or reading the function on demand. 40771 40772 Functions are emitted in `lto-streamer-out.c':`output_function' 40773 and read in `lto-streamer-in.c':`input_function'. 40774 40775 * Static variable initializers (`.gnu.lto_.vars') 40776 40777 This section contains all the symbols in the global variable pool. 40778 It is emitted by `lto-cgraph.c':`output_varpool' and read in 40779 `lto-cgraph.c':`input_cgraph'. 40780 40781 * Summaries and optimization summaries used by IPA passes 40782 (`.gnu.lto_.<xxx>', where `<xxx>' is one of `jmpfuncs', 40783 `pureconst' or `reference') 40784 40785 These sections are used by IPA passes that need to emit summary 40786 information during LTO generation to be read and aggregated at 40787 link time. Each pass is responsible for implementing two pass 40788 manager hooks: one for writing the summary and another for reading 40789 it in. The format of these sections is entirely up to each 40790 individual pass. The only requirement is that the writer and 40791 reader hooks agree on the format. 40792 40793 40794File: gccint.info, Node: IPA, Next: WHOPR, Prev: LTO object file layout, Up: LTO 40795 4079624.3 Using summary information in IPA passes 40797============================================ 40798 40799Programs are represented internally as a _callgraph_ (a multi-graph 40800where nodes are functions and edges are call sites) and a _varpool_ (a 40801list of static and external variables in the program). 40802 40803 The inter-procedural optimization is organized as a sequence of 40804individual passes, which operate on the callgraph and the varpool. To 40805make the implementation of WHOPR possible, every inter-procedural 40806optimization pass is split into several stages that are executed at 40807different times during WHOPR compilation: 40808 40809 * LGEN time 40810 1. _Generate summary_ (`generate_summary' in `struct 40811 ipa_opt_pass_d'). This stage analyzes every function body 40812 and variable initializer is examined and stores relevant 40813 information into a pass-specific data structure. 40814 40815 2. _Write summary_ (`write_summary' in `struct ipa_opt_pass_d'). 40816 This stage writes all the pass-specific information generated 40817 by `generate_summary'. Summaries go into their own 40818 `LTO_section_*' sections that have to be declared in 40819 `lto-streamer.h':`enum lto_section_type'. A new section is 40820 created by calling `create_output_block' and data can be 40821 written using the `lto_output_*' routines. 40822 40823 * WPA time 40824 1. _Read summary_ (`read_summary' in `struct ipa_opt_pass_d'). 40825 This stage reads all the pass-specific information in exactly 40826 the same order that it was written by `write_summary'. 40827 40828 2. _Execute_ (`execute' in `struct opt_pass'). This performs 40829 inter-procedural propagation. This must be done without 40830 actual access to the individual function bodies or variable 40831 initializers. Typically, this results in a transitive 40832 closure operation over the summary information of all the 40833 nodes in the callgraph. 40834 40835 3. _Write optimization summary_ (`write_optimization_summary' in 40836 `struct ipa_opt_pass_d'). This writes the result of the 40837 inter-procedural propagation into the object file. This can 40838 use the same data structures and helper routines used in 40839 `write_summary'. 40840 40841 * LTRANS time 40842 1. _Read optimization summary_ (`read_optimization_summary' in 40843 `struct ipa_opt_pass_d'). The counterpart to 40844 `write_optimization_summary'. This reads the interprocedural 40845 optimization decisions in exactly the same format emitted by 40846 `write_optimization_summary'. 40847 40848 2. _Transform_ (`function_transform' and `variable_transform' in 40849 `struct ipa_opt_pass_d'). The actual function bodies and 40850 variable initializers are updated based on the information 40851 passed down from the _Execute_ stage. 40852 40853 The implementation of the inter-procedural passes are shared between 40854LTO, WHOPR and classic non-LTO compilation. 40855 40856 * During the traditional file-by-file mode every pass executes its 40857 own _Generate summary_, _Execute_, and _Transform_ stages within 40858 the single execution context of the compiler. 40859 40860 * In LTO compilation mode, every pass uses _Generate summary_ and 40861 _Write summary_ stages at compilation time, while the _Read 40862 summary_, _Execute_, and _Transform_ stages are executed at link 40863 time. 40864 40865 * In WHOPR mode all stages are used. 40866 40867 To simplify development, the GCC pass manager differentiates between 40868normal inter-procedural passes and small inter-procedural passes. A 40869_small inter-procedural pass_ (`SIMPLE_IPA_PASS') is a pass that does 40870everything at once and thus it can not be executed during WPA in WHOPR 40871mode. It defines only the _Execute_ stage and during this stage it 40872accesses and modifies the function bodies. Such passes are useful for 40873optimization at LGEN or LTRANS time and are used, for example, to 40874implement early optimization before writing object files. The simple 40875inter-procedural passes can also be used for easier prototyping and 40876development of a new inter-procedural pass. 40877 4087824.3.1 Virtual clones 40879--------------------- 40880 40881One of the main challenges of introducing the WHOPR compilation mode 40882was addressing the interactions between optimization passes. In LTO 40883compilation mode, the passes are executed in a sequence, each of which 40884consists of analysis (or _Generate summary_), propagation (or 40885_Execute_) and _Transform_ stages. Once the work of one pass is 40886finished, the next pass sees the updated program representation and can 40887execute. This makes the individual passes dependent on each other. 40888 40889 In WHOPR mode all passes first execute their _Generate summary_ stage. 40890Then summary writing marks the end of the LGEN stage. At WPA time, the 40891summaries are read back into memory and all passes run the _Execute_ 40892stage. Optimization summaries are streamed and sent to LTRANS, where 40893all the passes execute the _Transform_ stage. 40894 40895 Most optimization passes split naturally into analysis, propagation 40896and transformation stages. But some do not. The main problem arises 40897when one pass performs changes and the following pass gets confused by 40898seeing different callgraphs between the _Transform_ stage and the 40899_Generate summary_ or _Execute_ stage. This means that the passes are 40900required to communicate their decisions with each other. 40901 40902 To facilitate this communication, the GCC callgraph infrastructure 40903implements _virtual clones_, a method of representing the changes 40904performed by the optimization passes in the callgraph without needing 40905to update function bodies. 40906 40907 A _virtual clone_ in the callgraph is a function that has no 40908associated body, just a description of how to create its body based on 40909a different function (which itself may be a virtual clone). 40910 40911 The description of function modifications includes adjustments to the 40912function's signature (which allows, for example, removing or adding 40913function arguments), substitutions to perform on the function body, 40914and, for inlined functions, a pointer to the function that it will be 40915inlined into. 40916 40917 It is also possible to redirect any edge of the callgraph from a 40918function to its virtual clone. This implies updating of the call site 40919to adjust for the new function signature. 40920 40921 Most of the transformations performed by inter-procedural 40922optimizations can be represented via virtual clones. For instance, a 40923constant propagation pass can produce a virtual clone of the function 40924which replaces one of its arguments by a constant. The inliner can 40925represent its decisions by producing a clone of a function whose body 40926will be later integrated into a given function. 40927 40928 Using _virtual clones_, the program can be easily updated during the 40929_Execute_ stage, solving most of pass interactions problems that would 40930otherwise occur during _Transform_. 40931 40932 Virtual clones are later materialized in the LTRANS stage and turned 40933into real functions. Passes executed after the virtual clone were 40934introduced also perform their _Transform_ stage on new functions, so 40935for a pass there is no significant difference between operating on a 40936real function or a virtual clone introduced before its _Execute_ stage. 40937 40938 Optimization passes then work on virtual clones introduced before 40939their _Execute_ stage as if they were real functions. The only 40940difference is that clones are not visible during the _Generate Summary_ 40941stage. 40942 40943 To keep function summaries updated, the callgraph interface allows an 40944optimizer to register a callback that is called every time a new clone 40945is introduced as well as when the actual function or variable is 40946generated or when a function or variable is removed. These hooks are 40947registered in the _Generate summary_ stage and allow the pass to keep 40948its information intact until the _Execute_ stage. The same hooks can 40949also be registered during the _Execute_ stage to keep the optimization 40950summaries updated for the _Transform_ stage. 40951 4095224.3.2 IPA references 40953--------------------- 40954 40955GCC represents IPA references in the callgraph. For a function or 40956variable `A', the _IPA reference_ is a list of all locations where the 40957address of `A' is taken and, when `A' is a variable, a list of all 40958direct stores and reads to/from `A'. References represent an oriented 40959multi-graph on the union of nodes of the callgraph and the varpool. See 40960`ipa-reference.c':`ipa_reference_write_optimization_summary' and 40961`ipa-reference.c':`ipa_reference_read_optimization_summary' for details. 40962 4096324.3.3 Jump functions 40964--------------------- 40965 40966Suppose that an optimization pass sees a function `A' and it knows the 40967values of (some of) its arguments. The _jump function_ describes the 40968value of a parameter of a given function call in function `A' based on 40969this knowledge. 40970 40971 Jump functions are used by several optimizations, such as the 40972inter-procedural constant propagation pass and the devirtualization 40973pass. The inliner also uses jump functions to perform inlining of 40974callbacks. 40975 40976 40977File: gccint.info, Node: WHOPR, Next: Internal flags, Prev: IPA, Up: LTO 40978 4097924.4 Whole program assumptions, linker plugin and symbol visibilities 40980===================================================================== 40981 40982Link-time optimization gives relatively minor benefits when used alone. 40983The problem is that propagation of inter-procedural information does 40984not work well across functions and variables that are called or 40985referenced by other compilation units (such as from a dynamically 40986linked library). We say that such functions and variables are 40987_externally visible_. 40988 40989 To make the situation even more difficult, many applications organize 40990themselves as a set of shared libraries, and the default ELF visibility 40991rules allow one to overwrite any externally visible symbol with a 40992different symbol at runtime. This basically disables any optimizations 40993across such functions and variables, because the compiler cannot be 40994sure that the function body it is seeing is the same function body that 40995will be used at runtime. Any function or variable not declared 40996`static' in the sources degrades the quality of inter-procedural 40997optimization. 40998 40999 To avoid this problem the compiler must assume that it sees the whole 41000program when doing link-time optimization. Strictly speaking, the 41001whole program is rarely visible even at link-time. Standard system 41002libraries are usually linked dynamically or not provided with the 41003link-time information. In GCC, the whole program option 41004(`-fwhole-program') asserts that every function and variable defined in 41005the current compilation unit is static, except for function `main' 41006(note: at link time, the current unit is the union of all objects 41007compiled with LTO). Since some functions and variables need to be 41008referenced externally, for example by another DSO or from an assembler 41009file, GCC also provides the function and variable attribute 41010`externally_visible' which can be used to disable the effect of 41011`-fwhole-program' on a specific symbol. 41012 41013 The whole program mode assumptions are slightly more complex in C++, 41014where inline functions in headers are put into _COMDAT_ sections. 41015COMDAT function and variables can be defined by multiple object files 41016and their bodies are unified at link-time and dynamic link-time. 41017COMDAT functions are changed to local only when their address is not 41018taken and thus un-sharing them with a library is not harmful. COMDAT 41019variables always remain externally visible, however for readonly 41020variables it is assumed that their initializers cannot be overwritten 41021by a different value. 41022 41023 GCC provides the function and variable attribute `visibility' that can 41024be used to specify the visibility of externally visible symbols (or 41025alternatively an `-fdefault-visibility' command line option). ELF 41026defines the `default', `protected', `hidden' and `internal' 41027visibilities. 41028 41029 The most commonly used is visibility is `hidden'. It specifies that 41030the symbol cannot be referenced from outside of the current shared 41031library. Unfortunately, this information cannot be used directly by 41032the link-time optimization in the compiler since the whole shared 41033library also might contain non-LTO objects and those are not visible to 41034the compiler. 41035 41036 GCC solves this problem using linker plugins. A _linker plugin_ is an 41037interface to the linker that allows an external program to claim the 41038ownership of a given object file. The linker then performs the linking 41039procedure by querying the plugin about the symbol table of the claimed 41040objects and once the linking decisions are complete, the plugin is 41041allowed to provide the final object file before the actual linking is 41042made. The linker plugin obtains the symbol resolution information 41043which specifies which symbols provided by the claimed objects are bound 41044from the rest of a binary being linked. 41045 41046 Currently, the linker plugin works only in combination with the Gold 41047linker, but a GNU ld implementation is under development. 41048 41049 GCC is designed to be independent of the rest of the toolchain and 41050aims to support linkers without plugin support. For this reason it 41051does not use the linker plugin by default. Instead, the object files 41052are examined by `collect2' before being passed to the linker and 41053objects found to have LTO sections are passed to `lto1' first. This 41054mode does not work for library archives. The decision on what object 41055files from the archive are needed depends on the actual linking and 41056thus GCC would have to implement the linker itself. The resolution 41057information is missing too and thus GCC needs to make an educated guess 41058based on `-fwhole-program'. Without the linker plugin GCC also assumes 41059that symbols are declared `hidden' and not referred by non-LTO code by 41060default. 41061 41062 41063File: gccint.info, Node: Internal flags, Prev: WHOPR, Up: LTO 41064 4106524.5 Internal flags controlling `lto1' 41066====================================== 41067 41068The following flags are passed into `lto1' and are not meant to be used 41069directly from the command line. 41070 41071 * -fwpa This option runs the serial part of the link-time optimizer 41072 performing the inter-procedural propagation (WPA mode). The 41073 compiler reads in summary information from all inputs and performs 41074 an analysis based on summary information only. It generates 41075 object files for subsequent runs of the link-time optimizer where 41076 individual object files are optimized using both summary 41077 information from the WPA mode and the actual function bodies. It 41078 then drives the LTRANS phase. 41079 41080 * -fltrans This option runs the link-time optimizer in the 41081 local-transformation (LTRANS) mode, which reads in output from a 41082 previous run of the LTO in WPA mode. In the LTRANS mode, LTO 41083 optimizes an object and produces the final assembly. 41084 41085 * -fltrans-output-list=FILE This option specifies a file to which 41086 the names of LTRANS output files are written. This option is only 41087 meaningful in conjunction with `-fwpa'. 41088 41089 * -fresolution=FILE This option specifies the linker resolution 41090 file. This option is only meaningful in conjunction with `-fwpa' 41091 and as option to pass through to the LTO linker plugin. 41092 41093 41094File: gccint.info, Node: Match and Simplify, Next: Funding, Prev: LTO, Up: Top 41095 4109625 Match and Simplify 41097********************* 41098 41099The GIMPLE and GENERIC pattern matching project match-and-simplify 41100tries to address several issues. 41101 41102 1. unify expression simplifications currently spread and duplicated 41103 over separate files like fold-const.c, gimple-fold.c and 41104 builtins.c 41105 41106 2. allow for a cheap way to implement building and simplifying 41107 non-trivial GIMPLE expressions, avoiding the need to go through 41108 building and simplifying GENERIC via fold_buildN and then 41109 gimplifying via force_gimple_operand 41110 41111 To address these the project introduces a simple domain specific 41112language to write expression simplifications from which code targeting 41113GIMPLE and GENERIC is auto-generated. The GENERIC variant follows the 41114fold_buildN API while for the GIMPLE variant and to address 2) new APIs 41115are introduced. 41116 41117* Menu: 41118 41119* GIMPLE API:: 41120* The Language:: 41121 41122 41123File: gccint.info, Node: GIMPLE API, Next: The Language, Up: Match and Simplify 41124 4112525.1 GIMPLE API 41126=============== 41127 41128 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 41129 gimple_seq *, tree (*)(tree)) 41130 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 41131 tree, gimple_seq *, tree (*)(tree)) 41132 -- GIMPLE function: tree gimple_simplify (enum tree_code, tree, tree, 41133 tree, tree, gimple_seq *, tree (*)(tree)) 41134 -- GIMPLE function: tree gimple_simplify (enum built_in_function, 41135 tree, tree, gimple_seq *, tree (*)(tree)) 41136 -- GIMPLE function: tree gimple_simplify (enum built_in_function, 41137 tree, tree, tree, gimple_seq *, tree (*)(tree)) 41138 -- GIMPLE function: tree gimple_simplify (enum built_in_function, 41139 tree, tree, tree, gimple_seq *, tree (*)(tree)) 41140 The main GIMPLE API entry to the expression simplifications 41141 mimicing that of the GENERIC fold_{unary,binary,ternary} functions. 41142 41143 thus providing n-ary overloads for operation or function. The 41144additional arguments are a gimple_seq where built statements are 41145inserted on (if `NULL' then simplifications requiring new statements 41146are not performed) and a valueization hook that can be used to tie 41147simplifications to a SSA lattice. 41148 41149 In addition to those APIs `fold_stmt' is overloaded with a 41150valueization hook: 41151 41152 -- bool: fold_stmt (gimple_stmt_iterator *, tree (*)(tree)); 41153 41154 Ontop of these a `fold_buildN'-like API for GIMPLE is introduced: 41155 41156 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 41157 tree_code, tree, tree, tree (*valueize) (tree) = NULL); 41158 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 41159 tree_code, tree, tree, tree, tree (*valueize) (tree) = NULL); 41160 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 41161 tree_code, tree, tree, tree, tree, tree (*valueize) (tree) = 41162 NULL); 41163 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 41164 built_in_function, tree, tree, tree (*valueize) (tree) = 41165 NULL); 41166 -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum 41167 built_in_function, tree, tree, tree, tree (*valueize) (tree) 41168 = NULL); 41169 -- GIMPLE function: tree gimple_convert (gimple_seq *, location_t, 41170 tree, tree); 41171 41172 which is supposed to replace `force_gimple_operand (fold_buildN (...), 41173...)' and calls to `fold_convert'. Overloads without the `location_t' 41174argument exist. Built statements are inserted on the provided sequence 41175and simplification is performed using the optional valueization hook. 41176 41177 41178File: gccint.info, Node: The Language, Prev: GIMPLE API, Up: Match and Simplify 41179 4118025.2 The Language 41181================= 41182 41183The language to write expression simplifications in resembles other 41184domain-specific languages GCC uses. Thus it is lispy. Lets start with 41185an example from the match.pd file: 41186 41187 (simplify 41188 (bit_and @0 integer_all_onesp) 41189 @0) 41190 41191 This example contains all required parts of an expression 41192simplification. A simplification is wrapped inside a `(simplify ...)' 41193expression. That contains at least two operands - an expression that 41194is matched with the GIMPLE or GENERIC IL and a replacement expression 41195that is returned if the match was successful. 41196 41197 Expressions have an operator ID, `bit_and' in this case. Expressions 41198can be lower-case tree codes with `_expr' stripped off or builtin 41199function code names in all-caps, like `BUILT_IN_SQRT'. 41200 41201 `@n' denotes a so-called capture. It captures the operand and lets 41202you refer to it in other places of the match-and-simplify. In the 41203above example it is refered to in the replacement expression. Captures 41204are `@' followed by a number or an identifier. 41205 41206 (simplify 41207 (bit_xor @0 @0) 41208 { build_zero_cst (type); }) 41209 41210 In this example `@0' is mentioned twice which constrains the matched 41211expression to have two equal operands. This example also introduces 41212operands written in C code. These can be used in the expression 41213replacements and are supposed to evaluate to a tree node which has to 41214be a valid GIMPLE operand (so you cannot generate expressions in C 41215code). 41216 41217 (simplify 41218 (trunc_mod integer_zerop@0 @1) 41219 (if (!integer_zerop (@1))) 41220 @0) 41221 41222 Here `@0' captures the first operand of the trunc_mod expression which 41223is also predicated with `integer_zerop'. Expression operands may be 41224either expressions, predicates or captures. Captures can be 41225unconstrained or capture expresions or predicates. 41226 41227 This example introduces an optional operand of simplify, the 41228if-expression. This condition is evaluated after the expression 41229matched in the IL and is required to evaluate to true to enable the 41230replacement expression. The expression operand of the `if' is a 41231standard C expression which may contain references to captures. 41232 41233 A `if' expression can be used to specify a common condition for 41234multiple simplify patterns, avoiding the need to repeat that multiple 41235times: 41236 41237 (if (!TYPE_SATURATING (type) 41238 && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) 41239 (simplify 41240 (minus (plus @0 @1) @0) 41241 @1) 41242 (simplify 41243 (minus (minus @0 @1) @0) 41244 (negate @1))) 41245 41246 Ifs can be nested. 41247 41248 Captures can also be used for capturing results of sub-expressions. 41249 41250 #if GIMPLE 41251 (simplify 41252 (pointer_plus (addr@2 @0) INTEGER_CST_P@1) 41253 (if (is_gimple_min_invariant (@2))) 41254 { 41255 HOST_WIDE_INT off; 41256 tree base = get_addr_base_and_unit_offset (@0, &off); 41257 off += tree_to_uhwi (@1); 41258 /* Now with that we should be able to simply write 41259 (addr (mem_ref (addr @base) (plus @off @1))) */ 41260 build1 (ADDR_EXPR, type, 41261 build2 (MEM_REF, TREE_TYPE (TREE_TYPE (@2)), 41262 build_fold_addr_expr (base), 41263 build_int_cst (ptr_type_node, off))); 41264 }) 41265 #endif 41266 41267 In the above example, `@2' captures the result of the expression 41268`(addr @0)'. For outermost expression only its type can be captured, 41269and the keyword `type' is reserved for this purpose. The above example 41270also gives a way to conditionalize patterns to only apply to `GIMPLE' 41271or `GENERIC' by means of using the pre-defined preprocessor macros 41272`GIMPLE' and `GENERIC' and using preprocessor directives. 41273 41274 (simplify 41275 (bit_and:c integral_op_p@0 (bit_ior:c (bit_not @0) @1)) 41276 (bit_and @1 @0)) 41277 41278 Here we introduce flags on match expressions. There is currently a 41279single flag, `c', which denotes that the expression should be also 41280matched commutated. Thus the above match expression is really the 41281following four match expressions: 41282 41283 (bit_and integral_op_p@0 (bit_ior (bit_not @0) @1)) (bit_and 41284(bit_ior (bit_not @0) @1) integral_op_p@0) (bit_and integral_op_p@0 41285(bit_ior @1 (bit_not @0))) (bit_and (bit_ior @1 (bit_not @0)) 41286integral_op_p@0) 41287 41288 Usual canonicalizations you know from GENERIC expressions are applied 41289before matching, so for example constant operands always come second in 41290commutative expressions. 41291 41292 More features exist to avoid too much repetition. 41293 41294 (for op (plus pointer_plus minus bit_ior bit_xor) 41295 (simplify 41296 (op @0 integer_zerop) 41297 @0)) 41298 41299 A `for' expression can be used to repeat a pattern for each operator 41300specified, substituting `op'. `for' can be nested and a `for' can have 41301multiple operators to iterate. 41302 41303 (for opa (plus minus) 41304 opb (minus plus) 41305 (for opc (plus minus) 41306 (simplify... 41307 41308 In this example the pattern will be repeated four times with `opa, 41309opb, opc' being `plus, minus, plus', `plus, minus, minus', `minus, 41310plus, plus', `minus, plus, minus'. 41311 41312 To avoid repeating operator lists in `for' you can name them via 41313 41314 (define_operator_list pmm plus minus mult) 41315 41316 and use them in `for' operator lists where they get expanded. 41317 41318 (for opa (pmm trunc_div) 41319 (simplify... 41320 41321 So this example iterates over `plus', `minus', `mult' and `trunc_div'. 41322 41323 Using operator lists can also remove the need to explicitely write a 41324`for'. All operator list uses that appear in a `simplify' or `match' 41325pattern in operator positions will implicitely be added to a new `for'. 41326For example 41327 41328 (define_operator_list SQRT BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL) 41329 (define_operator_list POW BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL) 41330 (simplify 41331 (SQRT (POW @0 @1)) 41332 (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); }))) 41333 41334 is the same as 41335 41336 (for SQRT (BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL) 41337 POW (BUILT_IN_POWF BUILT_IN_POW BUILT_IN_POWL) 41338 (simplify 41339 (SQRT (POW @0 @1)) 41340 (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); })))) 41341 41342 Another building block are `with' expressions in the result expression 41343which nest the generated code in a new C block followed by its argument: 41344 41345 (simplify 41346 (convert (mult @0 @1)) 41347 (with { tree utype = unsigned_type_for (type); } 41348 (convert (mult (convert:utype @0) (convert:utype @1))))) 41349 41350 This allows code nested in the `with' to refer to the declared 41351variables. In the above case we use the feature to specify the type of 41352a generated expression with the `:type' syntax where `type' needs to be 41353an identifier that refers to the desired type. Usually the types of 41354the generated result expressions are determined from the context, but 41355sometimes like in the above case it is required that you specify them 41356explicitely. 41357 41358 As intermediate conversions are often optional there is a way to avoid 41359the need to repeat patterns both with and without such conversions. 41360Namely you can mark a conversion as being optional with a `?': 41361 41362 (simplify 41363 (eq (convert@0 @1) (convert? @2)) 41364 (eq @1 (convert @2))) 41365 41366 which will match both `(eq (convert @1) (convert @2))' and `(eq 41367(convert @1) @2)'. The optional converts are supposed to be all either 41368present or not, thus `(eq (convert? @1) (convert? @2))' will result in 41369two patterns only. If you want to match all four combinations you have 41370access to two additional conditional converts as in `(eq (convert1? @1) 41371(convert2? @2))'. 41372 41373 Predicates available from the GCC middle-end need to be made available 41374explicitely via `define_predicates': 41375 41376 (define_predicates 41377 integer_onep integer_zerop integer_all_onesp) 41378 41379 You can also define predicates using the pattern matching language and 41380the `match' form: 41381 41382 (match negate_expr_p 41383 INTEGER_CST 41384 (if (TYPE_OVERFLOW_WRAPS (type) 41385 || may_negate_without_overflow_p (t)))) 41386 (match negate_expr_p 41387 (negate @0)) 41388 41389 This shows that for `match' expressions there is `t' available which 41390captures the outermost expression (something not possible in the 41391`simplify' context). As you can see `match' has an identifier as first 41392operand which is how you refer to the predicate in patterns. Multiple 41393`match' for the same identifier add additional cases where the predicate 41394matches. 41395 41396 Predicates can also match an expression in which case you need to 41397provide a template specifying the identifier and where to get its 41398operands from: 41399 41400 (match (logical_inverted_value @0) 41401 (eq @0 integer_zerop)) 41402 (match (logical_inverted_value @0) 41403 (bit_not truth_valued_p@0)) 41404 41405 You can use the above predicate like 41406 41407 (simplify 41408 (bit_and @0 (logical_inverted_value @0)) 41409 { build_zero_cst (type); }) 41410 41411 Which will match a bitwise and of an operand with its logical inverted 41412value. 41413 41414 41415File: gccint.info, Node: Funding, Next: GNU Project, Prev: Match and Simplify, Up: Top 41416 41417Funding Free Software 41418********************* 41419 41420If you want to have more free software a few years from now, it makes 41421sense for you to help encourage people to contribute funds for its 41422development. The most effective approach known is to encourage 41423commercial redistributors to donate. 41424 41425 Users of free software systems can boost the pace of development by 41426encouraging for-a-fee distributors to donate part of their selling price 41427to free software developers--the Free Software Foundation, and others. 41428 41429 The way to convince distributors to do this is to demand it and expect 41430it from them. So when you compare distributors, judge them partly by 41431how much they give to free software development. Show distributors 41432they must compete to be the one who gives the most. 41433 41434 To make this approach work, you must insist on numbers that you can 41435compare, such as, "We will donate ten dollars to the Frobnitz project 41436for each disk sold." Don't be satisfied with a vague promise, such as 41437"A portion of the profits are donated," since it doesn't give a basis 41438for comparison. 41439 41440 Even a precise fraction "of the profits from this disk" is not very 41441meaningful, since creative accounting and unrelated business decisions 41442can greatly alter what fraction of the sales price counts as profit. 41443If the price you pay is $50, ten percent of the profit is probably less 41444than a dollar; it might be a few cents, or nothing at all. 41445 41446 Some redistributors do development work themselves. This is useful 41447too; but to keep everyone honest, you need to inquire how much they do, 41448and what kind. Some kinds of development make much more long-term 41449difference than others. For example, maintaining a separate version of 41450a program contributes very little; maintaining the standard version of a 41451program for the whole community contributes much. Easy new ports 41452contribute little, since someone else would surely do them; difficult 41453ports such as adding a new CPU to the GNU Compiler Collection 41454contribute more; major new features or packages contribute the most. 41455 41456 By establishing the idea that supporting further development is "the 41457proper thing to do" when distributing free software for a fee, we can 41458assure a steady flow of resources into making more free software. 41459 41460 Copyright (C) 1994 Free Software Foundation, Inc. 41461 Verbatim copying and redistribution of this section is permitted 41462 without royalty; alteration is not permitted. 41463 41464 41465File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top 41466 41467The GNU Project and GNU/Linux 41468***************************** 41469 41470The GNU Project was launched in 1984 to develop a complete Unix-like 41471operating system which is free software: the GNU system. (GNU is a 41472recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".) 41473Variants of the GNU operating system, which use the kernel Linux, are 41474now widely used; though these systems are often referred to as "Linux", 41475they are more accurately called GNU/Linux systems. 41476 41477 For more information, see: 41478 `http://www.gnu.org/' 41479 `http://www.gnu.org/gnu/linux-and-gnu.html' 41480 41481 41482File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top 41483 41484GNU General Public License 41485************************** 41486 41487 Version 3, 29 June 2007 41488 41489 Copyright (C) 2007 Free Software Foundation, Inc. `http://fsf.org/' 41490 41491 Everyone is permitted to copy and distribute verbatim copies of this 41492 license document, but changing it is not allowed. 41493 41494Preamble 41495======== 41496 41497The GNU General Public License is a free, copyleft license for software 41498and other kinds of works. 41499 41500 The licenses for most software and other practical works are designed 41501to take away your freedom to share and change the works. By contrast, 41502the GNU General Public License is intended to guarantee your freedom to 41503share and change all versions of a program-to make sure it remains free 41504software for all its users. We, the Free Software Foundation, use the 41505GNU General Public License for most of our software; it applies also to 41506any other work released this way by its authors. You can apply it to 41507your programs, too. 41508 41509 When we speak of free software, we are referring to freedom, not 41510price. Our General Public Licenses are designed to make sure that you 41511have the freedom to distribute copies of free software (and charge for 41512them if you wish), that you receive source code or can get it if you 41513want it, that you can change the software or use pieces of it in new 41514free programs, and that you know you can do these things. 41515 41516 To protect your rights, we need to prevent others from denying you 41517these rights or asking you to surrender the rights. Therefore, you 41518have certain responsibilities if you distribute copies of the software, 41519or if you modify it: responsibilities to respect the freedom of others. 41520 41521 For example, if you distribute copies of such a program, whether 41522gratis or for a fee, you must pass on to the recipients the same 41523freedoms that you received. You must make sure that they, too, receive 41524or can get the source code. And you must show them these terms so they 41525know their rights. 41526 41527 Developers that use the GNU GPL protect your rights with two steps: 41528(1) assert copyright on the software, and (2) offer you this License 41529giving you legal permission to copy, distribute and/or modify it. 41530 41531 For the developers' and authors' protection, the GPL clearly explains 41532that there is no warranty for this free software. For both users' and 41533authors' sake, the GPL requires that modified versions be marked as 41534changed, so that their problems will not be attributed erroneously to 41535authors of previous versions. 41536 41537 Some devices are designed to deny users access to install or run 41538modified versions of the software inside them, although the 41539manufacturer can do so. This is fundamentally incompatible with the 41540aim of protecting users' freedom to change the software. The 41541systematic pattern of such abuse occurs in the area of products for 41542individuals to use, which is precisely where it is most unacceptable. 41543Therefore, we have designed this version of the GPL to prohibit the 41544practice for those products. If such problems arise substantially in 41545other domains, we stand ready to extend this provision to those domains 41546in future versions of the GPL, as needed to protect the freedom of 41547users. 41548 41549 Finally, every program is threatened constantly by software patents. 41550States should not allow patents to restrict development and use of 41551software on general-purpose computers, but in those that do, we wish to 41552avoid the special danger that patents applied to a free program could 41553make it effectively proprietary. To prevent this, the GPL assures that 41554patents cannot be used to render the program non-free. 41555 41556 The precise terms and conditions for copying, distribution and 41557modification follow. 41558 41559TERMS AND CONDITIONS 41560==================== 41561 41562 0. Definitions. 41563 41564 "This License" refers to version 3 of the GNU General Public 41565 License. 41566 41567 "Copyright" also means copyright-like laws that apply to other 41568 kinds of works, such as semiconductor masks. 41569 41570 "The Program" refers to any copyrightable work licensed under this 41571 License. Each licensee is addressed as "you". "Licensees" and 41572 "recipients" may be individuals or organizations. 41573 41574 To "modify" a work means to copy from or adapt all or part of the 41575 work in a fashion requiring copyright permission, other than the 41576 making of an exact copy. The resulting work is called a "modified 41577 version" of the earlier work or a work "based on" the earlier work. 41578 41579 A "covered work" means either the unmodified Program or a work 41580 based on the Program. 41581 41582 To "propagate" a work means to do anything with it that, without 41583 permission, would make you directly or secondarily liable for 41584 infringement under applicable copyright law, except executing it 41585 on a computer or modifying a private copy. Propagation includes 41586 copying, distribution (with or without modification), making 41587 available to the public, and in some countries other activities as 41588 well. 41589 41590 To "convey" a work means any kind of propagation that enables other 41591 parties to make or receive copies. Mere interaction with a user 41592 through a computer network, with no transfer of a copy, is not 41593 conveying. 41594 41595 An interactive user interface displays "Appropriate Legal Notices" 41596 to the extent that it includes a convenient and prominently visible 41597 feature that (1) displays an appropriate copyright notice, and (2) 41598 tells the user that there is no warranty for the work (except to 41599 the extent that warranties are provided), that licensees may 41600 convey the work under this License, and how to view a copy of this 41601 License. If the interface presents a list of user commands or 41602 options, such as a menu, a prominent item in the list meets this 41603 criterion. 41604 41605 1. Source Code. 41606 41607 The "source code" for a work means the preferred form of the work 41608 for making modifications to it. "Object code" means any 41609 non-source form of a work. 41610 41611 A "Standard Interface" means an interface that either is an 41612 official standard defined by a recognized standards body, or, in 41613 the case of interfaces specified for a particular programming 41614 language, one that is widely used among developers working in that 41615 language. 41616 41617 The "System Libraries" of an executable work include anything, 41618 other than the work as a whole, that (a) is included in the normal 41619 form of packaging a Major Component, but which is not part of that 41620 Major Component, and (b) serves only to enable use of the work 41621 with that Major Component, or to implement a Standard Interface 41622 for which an implementation is available to the public in source 41623 code form. A "Major Component", in this context, means a major 41624 essential component (kernel, window system, and so on) of the 41625 specific operating system (if any) on which the executable work 41626 runs, or a compiler used to produce the work, or an object code 41627 interpreter used to run it. 41628 41629 The "Corresponding Source" for a work in object code form means all 41630 the source code needed to generate, install, and (for an executable 41631 work) run the object code and to modify the work, including 41632 scripts to control those activities. However, it does not include 41633 the work's System Libraries, or general-purpose tools or generally 41634 available free programs which are used unmodified in performing 41635 those activities but which are not part of the work. For example, 41636 Corresponding Source includes interface definition files 41637 associated with source files for the work, and the source code for 41638 shared libraries and dynamically linked subprograms that the work 41639 is specifically designed to require, such as by intimate data 41640 communication or control flow between those subprograms and other 41641 parts of the work. 41642 41643 The Corresponding Source need not include anything that users can 41644 regenerate automatically from other parts of the Corresponding 41645 Source. 41646 41647 The Corresponding Source for a work in source code form is that 41648 same work. 41649 41650 2. Basic Permissions. 41651 41652 All rights granted under this License are granted for the term of 41653 copyright on the Program, and are irrevocable provided the stated 41654 conditions are met. This License explicitly affirms your unlimited 41655 permission to run the unmodified Program. The output from running 41656 a covered work is covered by this License only if the output, 41657 given its content, constitutes a covered work. This License 41658 acknowledges your rights of fair use or other equivalent, as 41659 provided by copyright law. 41660 41661 You may make, run and propagate covered works that you do not 41662 convey, without conditions so long as your license otherwise 41663 remains in force. You may convey covered works to others for the 41664 sole purpose of having them make modifications exclusively for 41665 you, or provide you with facilities for running those works, 41666 provided that you comply with the terms of this License in 41667 conveying all material for which you do not control copyright. 41668 Those thus making or running the covered works for you must do so 41669 exclusively on your behalf, under your direction and control, on 41670 terms that prohibit them from making any copies of your 41671 copyrighted material outside their relationship with you. 41672 41673 Conveying under any other circumstances is permitted solely under 41674 the conditions stated below. Sublicensing is not allowed; section 41675 10 makes it unnecessary. 41676 41677 3. Protecting Users' Legal Rights From Anti-Circumvention Law. 41678 41679 No covered work shall be deemed part of an effective technological 41680 measure under any applicable law fulfilling obligations under 41681 article 11 of the WIPO copyright treaty adopted on 20 December 41682 1996, or similar laws prohibiting or restricting circumvention of 41683 such measures. 41684 41685 When you convey a covered work, you waive any legal power to forbid 41686 circumvention of technological measures to the extent such 41687 circumvention is effected by exercising rights under this License 41688 with respect to the covered work, and you disclaim any intention 41689 to limit operation or modification of the work as a means of 41690 enforcing, against the work's users, your or third parties' legal 41691 rights to forbid circumvention of technological measures. 41692 41693 4. Conveying Verbatim Copies. 41694 41695 You may convey verbatim copies of the Program's source code as you 41696 receive it, in any medium, provided that you conspicuously and 41697 appropriately publish on each copy an appropriate copyright notice; 41698 keep intact all notices stating that this License and any 41699 non-permissive terms added in accord with section 7 apply to the 41700 code; keep intact all notices of the absence of any warranty; and 41701 give all recipients a copy of this License along with the Program. 41702 41703 You may charge any price or no price for each copy that you convey, 41704 and you may offer support or warranty protection for a fee. 41705 41706 5. Conveying Modified Source Versions. 41707 41708 You may convey a work based on the Program, or the modifications to 41709 produce it from the Program, in the form of source code under the 41710 terms of section 4, provided that you also meet all of these 41711 conditions: 41712 41713 a. The work must carry prominent notices stating that you 41714 modified it, and giving a relevant date. 41715 41716 b. The work must carry prominent notices stating that it is 41717 released under this License and any conditions added under 41718 section 7. This requirement modifies the requirement in 41719 section 4 to "keep intact all notices". 41720 41721 c. You must license the entire work, as a whole, under this 41722 License to anyone who comes into possession of a copy. This 41723 License will therefore apply, along with any applicable 41724 section 7 additional terms, to the whole of the work, and all 41725 its parts, regardless of how they are packaged. This License 41726 gives no permission to license the work in any other way, but 41727 it does not invalidate such permission if you have separately 41728 received it. 41729 41730 d. If the work has interactive user interfaces, each must display 41731 Appropriate Legal Notices; however, if the Program has 41732 interactive interfaces that do not display Appropriate Legal 41733 Notices, your work need not make them do so. 41734 41735 A compilation of a covered work with other separate and independent 41736 works, which are not by their nature extensions of the covered 41737 work, and which are not combined with it such as to form a larger 41738 program, in or on a volume of a storage or distribution medium, is 41739 called an "aggregate" if the compilation and its resulting 41740 copyright are not used to limit the access or legal rights of the 41741 compilation's users beyond what the individual works permit. 41742 Inclusion of a covered work in an aggregate does not cause this 41743 License to apply to the other parts of the aggregate. 41744 41745 6. Conveying Non-Source Forms. 41746 41747 You may convey a covered work in object code form under the terms 41748 of sections 4 and 5, provided that you also convey the 41749 machine-readable Corresponding Source under the terms of this 41750 License, in one of these ways: 41751 41752 a. Convey the object code in, or embodied in, a physical product 41753 (including a physical distribution medium), accompanied by the 41754 Corresponding Source fixed on a durable physical medium 41755 customarily used for software interchange. 41756 41757 b. Convey the object code in, or embodied in, a physical product 41758 (including a physical distribution medium), accompanied by a 41759 written offer, valid for at least three years and valid for 41760 as long as you offer spare parts or customer support for that 41761 product model, to give anyone who possesses the object code 41762 either (1) a copy of the Corresponding Source for all the 41763 software in the product that is covered by this License, on a 41764 durable physical medium customarily used for software 41765 interchange, for a price no more than your reasonable cost of 41766 physically performing this conveying of source, or (2) access 41767 to copy the Corresponding Source from a network server at no 41768 charge. 41769 41770 c. Convey individual copies of the object code with a copy of 41771 the written offer to provide the Corresponding Source. This 41772 alternative is allowed only occasionally and noncommercially, 41773 and only if you received the object code with such an offer, 41774 in accord with subsection 6b. 41775 41776 d. Convey the object code by offering access from a designated 41777 place (gratis or for a charge), and offer equivalent access 41778 to the Corresponding Source in the same way through the same 41779 place at no further charge. You need not require recipients 41780 to copy the Corresponding Source along with the object code. 41781 If the place to copy the object code is a network server, the 41782 Corresponding Source may be on a different server (operated 41783 by you or a third party) that supports equivalent copying 41784 facilities, provided you maintain clear directions next to 41785 the object code saying where to find the Corresponding Source. 41786 Regardless of what server hosts the Corresponding Source, you 41787 remain obligated to ensure that it is available for as long 41788 as needed to satisfy these requirements. 41789 41790 e. Convey the object code using peer-to-peer transmission, 41791 provided you inform other peers where the object code and 41792 Corresponding Source of the work are being offered to the 41793 general public at no charge under subsection 6d. 41794 41795 41796 A separable portion of the object code, whose source code is 41797 excluded from the Corresponding Source as a System Library, need 41798 not be included in conveying the object code work. 41799 41800 A "User Product" is either (1) a "consumer product", which means 41801 any tangible personal property which is normally used for personal, 41802 family, or household purposes, or (2) anything designed or sold for 41803 incorporation into a dwelling. In determining whether a product 41804 is a consumer product, doubtful cases shall be resolved in favor of 41805 coverage. For a particular product received by a particular user, 41806 "normally used" refers to a typical or common use of that class of 41807 product, regardless of the status of the particular user or of the 41808 way in which the particular user actually uses, or expects or is 41809 expected to use, the product. A product is a consumer product 41810 regardless of whether the product has substantial commercial, 41811 industrial or non-consumer uses, unless such uses represent the 41812 only significant mode of use of the product. 41813 41814 "Installation Information" for a User Product means any methods, 41815 procedures, authorization keys, or other information required to 41816 install and execute modified versions of a covered work in that 41817 User Product from a modified version of its Corresponding Source. 41818 The information must suffice to ensure that the continued 41819 functioning of the modified object code is in no case prevented or 41820 interfered with solely because modification has been made. 41821 41822 If you convey an object code work under this section in, or with, 41823 or specifically for use in, a User Product, and the conveying 41824 occurs as part of a transaction in which the right of possession 41825 and use of the User Product is transferred to the recipient in 41826 perpetuity or for a fixed term (regardless of how the transaction 41827 is characterized), the Corresponding Source conveyed under this 41828 section must be accompanied by the Installation Information. But 41829 this requirement does not apply if neither you nor any third party 41830 retains the ability to install modified object code on the User 41831 Product (for example, the work has been installed in ROM). 41832 41833 The requirement to provide Installation Information does not 41834 include a requirement to continue to provide support service, 41835 warranty, or updates for a work that has been modified or 41836 installed by the recipient, or for the User Product in which it 41837 has been modified or installed. Access to a network may be denied 41838 when the modification itself materially and adversely affects the 41839 operation of the network or violates the rules and protocols for 41840 communication across the network. 41841 41842 Corresponding Source conveyed, and Installation Information 41843 provided, in accord with this section must be in a format that is 41844 publicly documented (and with an implementation available to the 41845 public in source code form), and must require no special password 41846 or key for unpacking, reading or copying. 41847 41848 7. Additional Terms. 41849 41850 "Additional permissions" are terms that supplement the terms of 41851 this License by making exceptions from one or more of its 41852 conditions. Additional permissions that are applicable to the 41853 entire Program shall be treated as though they were included in 41854 this License, to the extent that they are valid under applicable 41855 law. If additional permissions apply only to part of the Program, 41856 that part may be used separately under those permissions, but the 41857 entire Program remains governed by this License without regard to 41858 the additional permissions. 41859 41860 When you convey a copy of a covered work, you may at your option 41861 remove any additional permissions from that copy, or from any part 41862 of it. (Additional permissions may be written to require their own 41863 removal in certain cases when you modify the work.) You may place 41864 additional permissions on material, added by you to a covered work, 41865 for which you have or can give appropriate copyright permission. 41866 41867 Notwithstanding any other provision of this License, for material 41868 you add to a covered work, you may (if authorized by the copyright 41869 holders of that material) supplement the terms of this License 41870 with terms: 41871 41872 a. Disclaiming warranty or limiting liability differently from 41873 the terms of sections 15 and 16 of this License; or 41874 41875 b. Requiring preservation of specified reasonable legal notices 41876 or author attributions in that material or in the Appropriate 41877 Legal Notices displayed by works containing it; or 41878 41879 c. Prohibiting misrepresentation of the origin of that material, 41880 or requiring that modified versions of such material be 41881 marked in reasonable ways as different from the original 41882 version; or 41883 41884 d. Limiting the use for publicity purposes of names of licensors 41885 or authors of the material; or 41886 41887 e. Declining to grant rights under trademark law for use of some 41888 trade names, trademarks, or service marks; or 41889 41890 f. Requiring indemnification of licensors and authors of that 41891 material by anyone who conveys the material (or modified 41892 versions of it) with contractual assumptions of liability to 41893 the recipient, for any liability that these contractual 41894 assumptions directly impose on those licensors and authors. 41895 41896 All other non-permissive additional terms are considered "further 41897 restrictions" within the meaning of section 10. If the Program as 41898 you received it, or any part of it, contains a notice stating that 41899 it is governed by this License along with a term that is a further 41900 restriction, you may remove that term. If a license document 41901 contains a further restriction but permits relicensing or 41902 conveying under this License, you may add to a covered work 41903 material governed by the terms of that license document, provided 41904 that the further restriction does not survive such relicensing or 41905 conveying. 41906 41907 If you add terms to a covered work in accord with this section, you 41908 must place, in the relevant source files, a statement of the 41909 additional terms that apply to those files, or a notice indicating 41910 where to find the applicable terms. 41911 41912 Additional terms, permissive or non-permissive, may be stated in 41913 the form of a separately written license, or stated as exceptions; 41914 the above requirements apply either way. 41915 41916 8. Termination. 41917 41918 You may not propagate or modify a covered work except as expressly 41919 provided under this License. Any attempt otherwise to propagate or 41920 modify it is void, and will automatically terminate your rights 41921 under this License (including any patent licenses granted under 41922 the third paragraph of section 11). 41923 41924 However, if you cease all violation of this License, then your 41925 license from a particular copyright holder is reinstated (a) 41926 provisionally, unless and until the copyright holder explicitly 41927 and finally terminates your license, and (b) permanently, if the 41928 copyright holder fails to notify you of the violation by some 41929 reasonable means prior to 60 days after the cessation. 41930 41931 Moreover, your license from a particular copyright holder is 41932 reinstated permanently if the copyright holder notifies you of the 41933 violation by some reasonable means, this is the first time you have 41934 received notice of violation of this License (for any work) from 41935 that copyright holder, and you cure the violation prior to 30 days 41936 after your receipt of the notice. 41937 41938 Termination of your rights under this section does not terminate 41939 the licenses of parties who have received copies or rights from 41940 you under this License. If your rights have been terminated and 41941 not permanently reinstated, you do not qualify to receive new 41942 licenses for the same material under section 10. 41943 41944 9. Acceptance Not Required for Having Copies. 41945 41946 You are not required to accept this License in order to receive or 41947 run a copy of the Program. Ancillary propagation of a covered work 41948 occurring solely as a consequence of using peer-to-peer 41949 transmission to receive a copy likewise does not require 41950 acceptance. However, nothing other than this License grants you 41951 permission to propagate or modify any covered work. These actions 41952 infringe copyright if you do not accept this License. Therefore, 41953 by modifying or propagating a covered work, you indicate your 41954 acceptance of this License to do so. 41955 41956 10. Automatic Licensing of Downstream Recipients. 41957 41958 Each time you convey a covered work, the recipient automatically 41959 receives a license from the original licensors, to run, modify and 41960 propagate that work, subject to this License. You are not 41961 responsible for enforcing compliance by third parties with this 41962 License. 41963 41964 An "entity transaction" is a transaction transferring control of an 41965 organization, or substantially all assets of one, or subdividing an 41966 organization, or merging organizations. If propagation of a 41967 covered work results from an entity transaction, each party to that 41968 transaction who receives a copy of the work also receives whatever 41969 licenses to the work the party's predecessor in interest had or 41970 could give under the previous paragraph, plus a right to 41971 possession of the Corresponding Source of the work from the 41972 predecessor in interest, if the predecessor has it or can get it 41973 with reasonable efforts. 41974 41975 You may not impose any further restrictions on the exercise of the 41976 rights granted or affirmed under this License. For example, you 41977 may not impose a license fee, royalty, or other charge for 41978 exercise of rights granted under this License, and you may not 41979 initiate litigation (including a cross-claim or counterclaim in a 41980 lawsuit) alleging that any patent claim is infringed by making, 41981 using, selling, offering for sale, or importing the Program or any 41982 portion of it. 41983 41984 11. Patents. 41985 41986 A "contributor" is a copyright holder who authorizes use under this 41987 License of the Program or a work on which the Program is based. 41988 The work thus licensed is called the contributor's "contributor 41989 version". 41990 41991 A contributor's "essential patent claims" are all patent claims 41992 owned or controlled by the contributor, whether already acquired or 41993 hereafter acquired, that would be infringed by some manner, 41994 permitted by this License, of making, using, or selling its 41995 contributor version, but do not include claims that would be 41996 infringed only as a consequence of further modification of the 41997 contributor version. For purposes of this definition, "control" 41998 includes the right to grant patent sublicenses in a manner 41999 consistent with the requirements of this License. 42000 42001 Each contributor grants you a non-exclusive, worldwide, 42002 royalty-free patent license under the contributor's essential 42003 patent claims, to make, use, sell, offer for sale, import and 42004 otherwise run, modify and propagate the contents of its 42005 contributor version. 42006 42007 In the following three paragraphs, a "patent license" is any 42008 express agreement or commitment, however denominated, not to 42009 enforce a patent (such as an express permission to practice a 42010 patent or covenant not to sue for patent infringement). To 42011 "grant" such a patent license to a party means to make such an 42012 agreement or commitment not to enforce a patent against the party. 42013 42014 If you convey a covered work, knowingly relying on a patent 42015 license, and the Corresponding Source of the work is not available 42016 for anyone to copy, free of charge and under the terms of this 42017 License, through a publicly available network server or other 42018 readily accessible means, then you must either (1) cause the 42019 Corresponding Source to be so available, or (2) arrange to deprive 42020 yourself of the benefit of the patent license for this particular 42021 work, or (3) arrange, in a manner consistent with the requirements 42022 of this License, to extend the patent license to downstream 42023 recipients. "Knowingly relying" means you have actual knowledge 42024 that, but for the patent license, your conveying the covered work 42025 in a country, or your recipient's use of the covered work in a 42026 country, would infringe one or more identifiable patents in that 42027 country that you have reason to believe are valid. 42028 42029 If, pursuant to or in connection with a single transaction or 42030 arrangement, you convey, or propagate by procuring conveyance of, a 42031 covered work, and grant a patent license to some of the parties 42032 receiving the covered work authorizing them to use, propagate, 42033 modify or convey a specific copy of the covered work, then the 42034 patent license you grant is automatically extended to all 42035 recipients of the covered work and works based on it. 42036 42037 A patent license is "discriminatory" if it does not include within 42038 the scope of its coverage, prohibits the exercise of, or is 42039 conditioned on the non-exercise of one or more of the rights that 42040 are specifically granted under this License. You may not convey a 42041 covered work if you are a party to an arrangement with a third 42042 party that is in the business of distributing software, under 42043 which you make payment to the third party based on the extent of 42044 your activity of conveying the work, and under which the third 42045 party grants, to any of the parties who would receive the covered 42046 work from you, a discriminatory patent license (a) in connection 42047 with copies of the covered work conveyed by you (or copies made 42048 from those copies), or (b) primarily for and in connection with 42049 specific products or compilations that contain the covered work, 42050 unless you entered into that arrangement, or that patent license 42051 was granted, prior to 28 March 2007. 42052 42053 Nothing in this License shall be construed as excluding or limiting 42054 any implied license or other defenses to infringement that may 42055 otherwise be available to you under applicable patent law. 42056 42057 12. No Surrender of Others' Freedom. 42058 42059 If conditions are imposed on you (whether by court order, 42060 agreement or otherwise) that contradict the conditions of this 42061 License, they do not excuse you from the conditions of this 42062 License. If you cannot convey a covered work so as to satisfy 42063 simultaneously your obligations under this License and any other 42064 pertinent obligations, then as a consequence you may not convey it 42065 at all. For example, if you agree to terms that obligate you to 42066 collect a royalty for further conveying from those to whom you 42067 convey the Program, the only way you could satisfy both those 42068 terms and this License would be to refrain entirely from conveying 42069 the Program. 42070 42071 13. Use with the GNU Affero General Public License. 42072 42073 Notwithstanding any other provision of this License, you have 42074 permission to link or combine any covered work with a work licensed 42075 under version 3 of the GNU Affero General Public License into a 42076 single combined work, and to convey the resulting work. The terms 42077 of this License will continue to apply to the part which is the 42078 covered work, but the special requirements of the GNU Affero 42079 General Public License, section 13, concerning interaction through 42080 a network will apply to the combination as such. 42081 42082 14. Revised Versions of this License. 42083 42084 The Free Software Foundation may publish revised and/or new 42085 versions of the GNU General Public License from time to time. 42086 Such new versions will be similar in spirit to the present 42087 version, but may differ in detail to address new problems or 42088 concerns. 42089 42090 Each version is given a distinguishing version number. If the 42091 Program specifies that a certain numbered version of the GNU 42092 General Public License "or any later version" applies to it, you 42093 have the option of following the terms and conditions either of 42094 that numbered version or of any later version published by the 42095 Free Software Foundation. If the Program does not specify a 42096 version number of the GNU General Public License, you may choose 42097 any version ever published by the Free Software Foundation. 42098 42099 If the Program specifies that a proxy can decide which future 42100 versions of the GNU General Public License can be used, that 42101 proxy's public statement of acceptance of a version permanently 42102 authorizes you to choose that version for the Program. 42103 42104 Later license versions may give you additional or different 42105 permissions. However, no additional obligations are imposed on any 42106 author or copyright holder as a result of your choosing to follow a 42107 later version. 42108 42109 15. Disclaimer of Warranty. 42110 42111 THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY 42112 APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE 42113 COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" 42114 WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, 42115 INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 42116 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE 42117 RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. 42118 SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL 42119 NECESSARY SERVICING, REPAIR OR CORRECTION. 42120 42121 16. Limitation of Liability. 42122 42123 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN 42124 WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES 42125 AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU 42126 FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR 42127 CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE 42128 THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA 42129 BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD 42130 PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER 42131 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF 42132 THE POSSIBILITY OF SUCH DAMAGES. 42133 42134 17. Interpretation of Sections 15 and 16. 42135 42136 If the disclaimer of warranty and limitation of liability provided 42137 above cannot be given local legal effect according to their terms, 42138 reviewing courts shall apply local law that most closely 42139 approximates an absolute waiver of all civil liability in 42140 connection with the Program, unless a warranty or assumption of 42141 liability accompanies a copy of the Program in return for a fee. 42142 42143 42144END OF TERMS AND CONDITIONS 42145=========================== 42146 42147How to Apply These Terms to Your New Programs 42148============================================= 42149 42150If you develop a new program, and you want it to be of the greatest 42151possible use to the public, the best way to achieve this is to make it 42152free software which everyone can redistribute and change under these 42153terms. 42154 42155 To do so, attach the following notices to the program. It is safest 42156to attach them to the start of each source file to most effectively 42157state the exclusion of warranty; and each file should have at least the 42158"copyright" line and a pointer to where the full notice is found. 42159 42160 ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES. 42161 Copyright (C) YEAR NAME OF AUTHOR 42162 42163 This program is free software: you can redistribute it and/or modify 42164 it under the terms of the GNU General Public License as published by 42165 the Free Software Foundation, either version 3 of the License, or (at 42166 your option) any later version. 42167 42168 This program is distributed in the hope that it will be useful, but 42169 WITHOUT ANY WARRANTY; without even the implied warranty of 42170 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU 42171 General Public License for more details. 42172 42173 You should have received a copy of the GNU General Public License 42174 along with this program. If not, see `http://www.gnu.org/licenses/'. 42175 42176 Also add information on how to contact you by electronic and paper 42177mail. 42178 42179 If the program does terminal interaction, make it output a short 42180notice like this when it starts in an interactive mode: 42181 42182 PROGRAM Copyright (C) YEAR NAME OF AUTHOR 42183 This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'. 42184 This is free software, and you are welcome to redistribute it 42185 under certain conditions; type `show c' for details. 42186 42187 The hypothetical commands `show w' and `show c' should show the 42188appropriate parts of the General Public License. Of course, your 42189program's commands might be different; for a GUI interface, you would 42190use an "about box". 42191 42192 You should also get your employer (if you work as a programmer) or 42193school, if any, to sign a "copyright disclaimer" for the program, if 42194necessary. For more information on this, and how to apply and follow 42195the GNU GPL, see `http://www.gnu.org/licenses/'. 42196 42197 The GNU General Public License does not permit incorporating your 42198program into proprietary programs. If your program is a subroutine 42199library, you may consider it more useful to permit linking proprietary 42200applications with the library. If this is what you want to do, use the 42201GNU Lesser General Public License instead of this License. But first, 42202please read `http://www.gnu.org/philosophy/why-not-lgpl.html'. 42203 42204 42205File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top 42206 42207GNU Free Documentation License 42208****************************** 42209 42210 Version 1.3, 3 November 2008 42211 42212 Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. 42213 `http://fsf.org/' 42214 42215 Everyone is permitted to copy and distribute verbatim copies 42216 of this license document, but changing it is not allowed. 42217 42218 0. PREAMBLE 42219 42220 The purpose of this License is to make a manual, textbook, or other 42221 functional and useful document "free" in the sense of freedom: to 42222 assure everyone the effective freedom to copy and redistribute it, 42223 with or without modifying it, either commercially or 42224 noncommercially. Secondarily, this License preserves for the 42225 author and publisher a way to get credit for their work, while not 42226 being considered responsible for modifications made by others. 42227 42228 This License is a kind of "copyleft", which means that derivative 42229 works of the document must themselves be free in the same sense. 42230 It complements the GNU General Public License, which is a copyleft 42231 license designed for free software. 42232 42233 We have designed this License in order to use it for manuals for 42234 free software, because free software needs free documentation: a 42235 free program should come with manuals providing the same freedoms 42236 that the software does. But this License is not limited to 42237 software manuals; it can be used for any textual work, regardless 42238 of subject matter or whether it is published as a printed book. 42239 We recommend this License principally for works whose purpose is 42240 instruction or reference. 42241 42242 1. APPLICABILITY AND DEFINITIONS 42243 42244 This License applies to any manual or other work, in any medium, 42245 that contains a notice placed by the copyright holder saying it 42246 can be distributed under the terms of this License. Such a notice 42247 grants a world-wide, royalty-free license, unlimited in duration, 42248 to use that work under the conditions stated herein. The 42249 "Document", below, refers to any such manual or work. Any member 42250 of the public is a licensee, and is addressed as "you". You 42251 accept the license if you copy, modify or distribute the work in a 42252 way requiring permission under copyright law. 42253 42254 A "Modified Version" of the Document means any work containing the 42255 Document or a portion of it, either copied verbatim, or with 42256 modifications and/or translated into another language. 42257 42258 A "Secondary Section" is a named appendix or a front-matter section 42259 of the Document that deals exclusively with the relationship of the 42260 publishers or authors of the Document to the Document's overall 42261 subject (or to related matters) and contains nothing that could 42262 fall directly within that overall subject. (Thus, if the Document 42263 is in part a textbook of mathematics, a Secondary Section may not 42264 explain any mathematics.) The relationship could be a matter of 42265 historical connection with the subject or with related matters, or 42266 of legal, commercial, philosophical, ethical or political position 42267 regarding them. 42268 42269 The "Invariant Sections" are certain Secondary Sections whose 42270 titles are designated, as being those of Invariant Sections, in 42271 the notice that says that the Document is released under this 42272 License. If a section does not fit the above definition of 42273 Secondary then it is not allowed to be designated as Invariant. 42274 The Document may contain zero Invariant Sections. If the Document 42275 does not identify any Invariant Sections then there are none. 42276 42277 The "Cover Texts" are certain short passages of text that are 42278 listed, as Front-Cover Texts or Back-Cover Texts, in the notice 42279 that says that the Document is released under this License. A 42280 Front-Cover Text may be at most 5 words, and a Back-Cover Text may 42281 be at most 25 words. 42282 42283 A "Transparent" copy of the Document means a machine-readable copy, 42284 represented in a format whose specification is available to the 42285 general public, that is suitable for revising the document 42286 straightforwardly with generic text editors or (for images 42287 composed of pixels) generic paint programs or (for drawings) some 42288 widely available drawing editor, and that is suitable for input to 42289 text formatters or for automatic translation to a variety of 42290 formats suitable for input to text formatters. A copy made in an 42291 otherwise Transparent file format whose markup, or absence of 42292 markup, has been arranged to thwart or discourage subsequent 42293 modification by readers is not Transparent. An image format is 42294 not Transparent if used for any substantial amount of text. A 42295 copy that is not "Transparent" is called "Opaque". 42296 42297 Examples of suitable formats for Transparent copies include plain 42298 ASCII without markup, Texinfo input format, LaTeX input format, 42299 SGML or XML using a publicly available DTD, and 42300 standard-conforming simple HTML, PostScript or PDF designed for 42301 human modification. Examples of transparent image formats include 42302 PNG, XCF and JPG. Opaque formats include proprietary formats that 42303 can be read and edited only by proprietary word processors, SGML or 42304 XML for which the DTD and/or processing tools are not generally 42305 available, and the machine-generated HTML, PostScript or PDF 42306 produced by some word processors for output purposes only. 42307 42308 The "Title Page" means, for a printed book, the title page itself, 42309 plus such following pages as are needed to hold, legibly, the 42310 material this License requires to appear in the title page. For 42311 works in formats which do not have any title page as such, "Title 42312 Page" means the text near the most prominent appearance of the 42313 work's title, preceding the beginning of the body of the text. 42314 42315 The "publisher" means any person or entity that distributes copies 42316 of the Document to the public. 42317 42318 A section "Entitled XYZ" means a named subunit of the Document 42319 whose title either is precisely XYZ or contains XYZ in parentheses 42320 following text that translates XYZ in another language. (Here XYZ 42321 stands for a specific section name mentioned below, such as 42322 "Acknowledgements", "Dedications", "Endorsements", or "History".) 42323 To "Preserve the Title" of such a section when you modify the 42324 Document means that it remains a section "Entitled XYZ" according 42325 to this definition. 42326 42327 The Document may include Warranty Disclaimers next to the notice 42328 which states that this License applies to the Document. These 42329 Warranty Disclaimers are considered to be included by reference in 42330 this License, but only as regards disclaiming warranties: any other 42331 implication that these Warranty Disclaimers may have is void and 42332 has no effect on the meaning of this License. 42333 42334 2. VERBATIM COPYING 42335 42336 You may copy and distribute the Document in any medium, either 42337 commercially or noncommercially, provided that this License, the 42338 copyright notices, and the license notice saying this License 42339 applies to the Document are reproduced in all copies, and that you 42340 add no other conditions whatsoever to those of this License. You 42341 may not use technical measures to obstruct or control the reading 42342 or further copying of the copies you make or distribute. However, 42343 you may accept compensation in exchange for copies. If you 42344 distribute a large enough number of copies you must also follow 42345 the conditions in section 3. 42346 42347 You may also lend copies, under the same conditions stated above, 42348 and you may publicly display copies. 42349 42350 3. COPYING IN QUANTITY 42351 42352 If you publish printed copies (or copies in media that commonly 42353 have printed covers) of the Document, numbering more than 100, and 42354 the Document's license notice requires Cover Texts, you must 42355 enclose the copies in covers that carry, clearly and legibly, all 42356 these Cover Texts: Front-Cover Texts on the front cover, and 42357 Back-Cover Texts on the back cover. Both covers must also clearly 42358 and legibly identify you as the publisher of these copies. The 42359 front cover must present the full title with all words of the 42360 title equally prominent and visible. You may add other material 42361 on the covers in addition. Copying with changes limited to the 42362 covers, as long as they preserve the title of the Document and 42363 satisfy these conditions, can be treated as verbatim copying in 42364 other respects. 42365 42366 If the required texts for either cover are too voluminous to fit 42367 legibly, you should put the first ones listed (as many as fit 42368 reasonably) on the actual cover, and continue the rest onto 42369 adjacent pages. 42370 42371 If you publish or distribute Opaque copies of the Document 42372 numbering more than 100, you must either include a 42373 machine-readable Transparent copy along with each Opaque copy, or 42374 state in or with each Opaque copy a computer-network location from 42375 which the general network-using public has access to download 42376 using public-standard network protocols a complete Transparent 42377 copy of the Document, free of added material. If you use the 42378 latter option, you must take reasonably prudent steps, when you 42379 begin distribution of Opaque copies in quantity, to ensure that 42380 this Transparent copy will remain thus accessible at the stated 42381 location until at least one year after the last time you 42382 distribute an Opaque copy (directly or through your agents or 42383 retailers) of that edition to the public. 42384 42385 It is requested, but not required, that you contact the authors of 42386 the Document well before redistributing any large number of 42387 copies, to give them a chance to provide you with an updated 42388 version of the Document. 42389 42390 4. MODIFICATIONS 42391 42392 You may copy and distribute a Modified Version of the Document 42393 under the conditions of sections 2 and 3 above, provided that you 42394 release the Modified Version under precisely this License, with 42395 the Modified Version filling the role of the Document, thus 42396 licensing distribution and modification of the Modified Version to 42397 whoever possesses a copy of it. In addition, you must do these 42398 things in the Modified Version: 42399 42400 A. Use in the Title Page (and on the covers, if any) a title 42401 distinct from that of the Document, and from those of 42402 previous versions (which should, if there were any, be listed 42403 in the History section of the Document). You may use the 42404 same title as a previous version if the original publisher of 42405 that version gives permission. 42406 42407 B. List on the Title Page, as authors, one or more persons or 42408 entities responsible for authorship of the modifications in 42409 the Modified Version, together with at least five of the 42410 principal authors of the Document (all of its principal 42411 authors, if it has fewer than five), unless they release you 42412 from this requirement. 42413 42414 C. State on the Title page the name of the publisher of the 42415 Modified Version, as the publisher. 42416 42417 D. Preserve all the copyright notices of the Document. 42418 42419 E. Add an appropriate copyright notice for your modifications 42420 adjacent to the other copyright notices. 42421 42422 F. Include, immediately after the copyright notices, a license 42423 notice giving the public permission to use the Modified 42424 Version under the terms of this License, in the form shown in 42425 the Addendum below. 42426 42427 G. Preserve in that license notice the full lists of Invariant 42428 Sections and required Cover Texts given in the Document's 42429 license notice. 42430 42431 H. Include an unaltered copy of this License. 42432 42433 I. Preserve the section Entitled "History", Preserve its Title, 42434 and add to it an item stating at least the title, year, new 42435 authors, and publisher of the Modified Version as given on 42436 the Title Page. If there is no section Entitled "History" in 42437 the Document, create one stating the title, year, authors, 42438 and publisher of the Document as given on its Title Page, 42439 then add an item describing the Modified Version as stated in 42440 the previous sentence. 42441 42442 J. Preserve the network location, if any, given in the Document 42443 for public access to a Transparent copy of the Document, and 42444 likewise the network locations given in the Document for 42445 previous versions it was based on. These may be placed in 42446 the "History" section. You may omit a network location for a 42447 work that was published at least four years before the 42448 Document itself, or if the original publisher of the version 42449 it refers to gives permission. 42450 42451 K. For any section Entitled "Acknowledgements" or "Dedications", 42452 Preserve the Title of the section, and preserve in the 42453 section all the substance and tone of each of the contributor 42454 acknowledgements and/or dedications given therein. 42455 42456 L. Preserve all the Invariant Sections of the Document, 42457 unaltered in their text and in their titles. Section numbers 42458 or the equivalent are not considered part of the section 42459 titles. 42460 42461 M. Delete any section Entitled "Endorsements". Such a section 42462 may not be included in the Modified Version. 42463 42464 N. Do not retitle any existing section to be Entitled 42465 "Endorsements" or to conflict in title with any Invariant 42466 Section. 42467 42468 O. Preserve any Warranty Disclaimers. 42469 42470 If the Modified Version includes new front-matter sections or 42471 appendices that qualify as Secondary Sections and contain no 42472 material copied from the Document, you may at your option 42473 designate some or all of these sections as invariant. To do this, 42474 add their titles to the list of Invariant Sections in the Modified 42475 Version's license notice. These titles must be distinct from any 42476 other section titles. 42477 42478 You may add a section Entitled "Endorsements", provided it contains 42479 nothing but endorsements of your Modified Version by various 42480 parties--for example, statements of peer review or that the text 42481 has been approved by an organization as the authoritative 42482 definition of a standard. 42483 42484 You may add a passage of up to five words as a Front-Cover Text, 42485 and a passage of up to 25 words as a Back-Cover Text, to the end 42486 of the list of Cover Texts in the Modified Version. Only one 42487 passage of Front-Cover Text and one of Back-Cover Text may be 42488 added by (or through arrangements made by) any one entity. If the 42489 Document already includes a cover text for the same cover, 42490 previously added by you or by arrangement made by the same entity 42491 you are acting on behalf of, you may not add another; but you may 42492 replace the old one, on explicit permission from the previous 42493 publisher that added the old one. 42494 42495 The author(s) and publisher(s) of the Document do not by this 42496 License give permission to use their names for publicity for or to 42497 assert or imply endorsement of any Modified Version. 42498 42499 5. COMBINING DOCUMENTS 42500 42501 You may combine the Document with other documents released under 42502 this License, under the terms defined in section 4 above for 42503 modified versions, provided that you include in the combination 42504 all of the Invariant Sections of all of the original documents, 42505 unmodified, and list them all as Invariant Sections of your 42506 combined work in its license notice, and that you preserve all 42507 their Warranty Disclaimers. 42508 42509 The combined work need only contain one copy of this License, and 42510 multiple identical Invariant Sections may be replaced with a single 42511 copy. If there are multiple Invariant Sections with the same name 42512 but different contents, make the title of each such section unique 42513 by adding at the end of it, in parentheses, the name of the 42514 original author or publisher of that section if known, or else a 42515 unique number. Make the same adjustment to the section titles in 42516 the list of Invariant Sections in the license notice of the 42517 combined work. 42518 42519 In the combination, you must combine any sections Entitled 42520 "History" in the various original documents, forming one section 42521 Entitled "History"; likewise combine any sections Entitled 42522 "Acknowledgements", and any sections Entitled "Dedications". You 42523 must delete all sections Entitled "Endorsements." 42524 42525 6. COLLECTIONS OF DOCUMENTS 42526 42527 You may make a collection consisting of the Document and other 42528 documents released under this License, and replace the individual 42529 copies of this License in the various documents with a single copy 42530 that is included in the collection, provided that you follow the 42531 rules of this License for verbatim copying of each of the 42532 documents in all other respects. 42533 42534 You may extract a single document from such a collection, and 42535 distribute it individually under this License, provided you insert 42536 a copy of this License into the extracted document, and follow 42537 this License in all other respects regarding verbatim copying of 42538 that document. 42539 42540 7. AGGREGATION WITH INDEPENDENT WORKS 42541 42542 A compilation of the Document or its derivatives with other 42543 separate and independent documents or works, in or on a volume of 42544 a storage or distribution medium, is called an "aggregate" if the 42545 copyright resulting from the compilation is not used to limit the 42546 legal rights of the compilation's users beyond what the individual 42547 works permit. When the Document is included in an aggregate, this 42548 License does not apply to the other works in the aggregate which 42549 are not themselves derivative works of the Document. 42550 42551 If the Cover Text requirement of section 3 is applicable to these 42552 copies of the Document, then if the Document is less than one half 42553 of the entire aggregate, the Document's Cover Texts may be placed 42554 on covers that bracket the Document within the aggregate, or the 42555 electronic equivalent of covers if the Document is in electronic 42556 form. Otherwise they must appear on printed covers that bracket 42557 the whole aggregate. 42558 42559 8. TRANSLATION 42560 42561 Translation is considered a kind of modification, so you may 42562 distribute translations of the Document under the terms of section 42563 4. Replacing Invariant Sections with translations requires special 42564 permission from their copyright holders, but you may include 42565 translations of some or all Invariant Sections in addition to the 42566 original versions of these Invariant Sections. You may include a 42567 translation of this License, and all the license notices in the 42568 Document, and any Warranty Disclaimers, provided that you also 42569 include the original English version of this License and the 42570 original versions of those notices and disclaimers. In case of a 42571 disagreement between the translation and the original version of 42572 this License or a notice or disclaimer, the original version will 42573 prevail. 42574 42575 If a section in the Document is Entitled "Acknowledgements", 42576 "Dedications", or "History", the requirement (section 4) to 42577 Preserve its Title (section 1) will typically require changing the 42578 actual title. 42579 42580 9. TERMINATION 42581 42582 You may not copy, modify, sublicense, or distribute the Document 42583 except as expressly provided under this License. Any attempt 42584 otherwise to copy, modify, sublicense, or distribute it is void, 42585 and will automatically terminate your rights under this License. 42586 42587 However, if you cease all violation of this License, then your 42588 license from a particular copyright holder is reinstated (a) 42589 provisionally, unless and until the copyright holder explicitly 42590 and finally terminates your license, and (b) permanently, if the 42591 copyright holder fails to notify you of the violation by some 42592 reasonable means prior to 60 days after the cessation. 42593 42594 Moreover, your license from a particular copyright holder is 42595 reinstated permanently if the copyright holder notifies you of the 42596 violation by some reasonable means, this is the first time you have 42597 received notice of violation of this License (for any work) from 42598 that copyright holder, and you cure the violation prior to 30 days 42599 after your receipt of the notice. 42600 42601 Termination of your rights under this section does not terminate 42602 the licenses of parties who have received copies or rights from 42603 you under this License. If your rights have been terminated and 42604 not permanently reinstated, receipt of a copy of some or all of 42605 the same material does not give you any rights to use it. 42606 42607 10. FUTURE REVISIONS OF THIS LICENSE 42608 42609 The Free Software Foundation may publish new, revised versions of 42610 the GNU Free Documentation License from time to time. Such new 42611 versions will be similar in spirit to the present version, but may 42612 differ in detail to address new problems or concerns. See 42613 `http://www.gnu.org/copyleft/'. 42614 42615 Each version of the License is given a distinguishing version 42616 number. If the Document specifies that a particular numbered 42617 version of this License "or any later version" applies to it, you 42618 have the option of following the terms and conditions either of 42619 that specified version or of any later version that has been 42620 published (not as a draft) by the Free Software Foundation. If 42621 the Document does not specify a version number of this License, 42622 you may choose any version ever published (not as a draft) by the 42623 Free Software Foundation. If the Document specifies that a proxy 42624 can decide which future versions of this License can be used, that 42625 proxy's public statement of acceptance of a version permanently 42626 authorizes you to choose that version for the Document. 42627 42628 11. RELICENSING 42629 42630 "Massive Multiauthor Collaboration Site" (or "MMC Site") means any 42631 World Wide Web server that publishes copyrightable works and also 42632 provides prominent facilities for anybody to edit those works. A 42633 public wiki that anybody can edit is an example of such a server. 42634 A "Massive Multiauthor Collaboration" (or "MMC") contained in the 42635 site means any set of copyrightable works thus published on the MMC 42636 site. 42637 42638 "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 42639 license published by Creative Commons Corporation, a not-for-profit 42640 corporation with a principal place of business in San Francisco, 42641 California, as well as future copyleft versions of that license 42642 published by that same organization. 42643 42644 "Incorporate" means to publish or republish a Document, in whole or 42645 in part, as part of another Document. 42646 42647 An MMC is "eligible for relicensing" if it is licensed under this 42648 License, and if all works that were first published under this 42649 License somewhere other than this MMC, and subsequently 42650 incorporated in whole or in part into the MMC, (1) had no cover 42651 texts or invariant sections, and (2) were thus incorporated prior 42652 to November 1, 2008. 42653 42654 The operator of an MMC Site may republish an MMC contained in the 42655 site under CC-BY-SA on the same site at any time before August 1, 42656 2009, provided the MMC is eligible for relicensing. 42657 42658 42659ADDENDUM: How to use this License for your documents 42660==================================================== 42661 42662To use this License in a document you have written, include a copy of 42663the License in the document and put the following copyright and license 42664notices just after the title page: 42665 42666 Copyright (C) YEAR YOUR NAME. 42667 Permission is granted to copy, distribute and/or modify this document 42668 under the terms of the GNU Free Documentation License, Version 1.3 42669 or any later version published by the Free Software Foundation; 42670 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover 42671 Texts. A copy of the license is included in the section entitled ``GNU 42672 Free Documentation License''. 42673 42674 If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, 42675replace the "with...Texts." line with this: 42676 42677 with the Invariant Sections being LIST THEIR TITLES, with 42678 the Front-Cover Texts being LIST, and with the Back-Cover Texts 42679 being LIST. 42680 42681 If you have Invariant Sections without Cover Texts, or some other 42682combination of the three, merge those two alternatives to suit the 42683situation. 42684 42685 If your document contains nontrivial examples of program code, we 42686recommend releasing these examples in parallel under your choice of 42687free software license, such as the GNU General Public License, to 42688permit their use in free software. 42689 42690 42691File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top 42692 42693Contributors to GCC 42694******************* 42695 42696The GCC project would like to thank its many contributors. Without 42697them the project would not have been nearly as successful as it has 42698been. Any omissions in this list are accidental. Feel free to contact 42699<law@redhat.com> or <gerald@pfeifer.com> if you have been left out or 42700some of your contributions are not listed. Please keep this list in 42701alphabetical order. 42702 42703 * Analog Devices helped implement the support for complex data types 42704 and iterators. 42705 42706 * John David Anglin for threading-related fixes and improvements to 42707 libstdc++-v3, and the HP-UX port. 42708 42709 * James van Artsdalen wrote the code that makes efficient use of the 42710 Intel 80387 register stack. 42711 42712 * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta 42713 Series port. 42714 42715 * Alasdair Baird for various bug fixes. 42716 42717 * Giovanni Bajo for analyzing lots of complicated C++ problem 42718 reports. 42719 42720 * Peter Barada for his work to improve code generation for new 42721 ColdFire cores. 42722 42723 * Gerald Baumgartner added the signature extension to the C++ front 42724 end. 42725 42726 * Godmar Back for his Java improvements and encouragement. 42727 42728 * Scott Bambrough for help porting the Java compiler. 42729 42730 * Wolfgang Bangerth for processing tons of bug reports. 42731 42732 * Jon Beniston for his Microsoft Windows port of Java and port to 42733 Lattice Mico32. 42734 42735 * Daniel Berlin for better DWARF2 support, faster/better 42736 optimizations, improved alias analysis, plus migrating GCC to 42737 Bugzilla. 42738 42739 * Geoff Berry for his Java object serialization work and various 42740 patches. 42741 42742 * David Binderman tests weekly snapshots of GCC trunk against Fedora 42743 Rawhide for several architectures. 42744 42745 * Laurynas Biveinis for memory management work and DJGPP port fixes. 42746 42747 * Uros Bizjak for the implementation of x87 math built-in functions 42748 and for various middle end and i386 back end improvements and bug 42749 fixes. 42750 42751 * Eric Blake for helping to make GCJ and libgcj conform to the 42752 specifications. 42753 42754 * Janne Blomqvist for contributions to GNU Fortran. 42755 42756 * Segher Boessenkool for various fixes. 42757 42758 * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and 42759 other Java work. 42760 42761 * Neil Booth for work on cpplib, lang hooks, debug hooks and other 42762 miscellaneous clean-ups. 42763 42764 * Steven Bosscher for integrating the GNU Fortran front end into GCC 42765 and for contributing to the tree-ssa branch. 42766 42767 * Eric Botcazou for fixing middle- and backend bugs left and right. 42768 42769 * Per Bothner for his direction via the steering committee and 42770 various improvements to the infrastructure for supporting new 42771 languages. Chill front end implementation. Initial 42772 implementations of cpplib, fix-header, config.guess, libio, and 42773 past C++ library (libg++) maintainer. Dreaming up, designing and 42774 implementing much of GCJ. 42775 42776 * Devon Bowen helped port GCC to the Tahoe. 42777 42778 * Don Bowman for mips-vxworks contributions. 42779 42780 * Dave Brolley for work on cpplib and Chill. 42781 42782 * Paul Brook for work on the ARM architecture and maintaining GNU 42783 Fortran. 42784 42785 * Robert Brown implemented the support for Encore 32000 systems. 42786 42787 * Christian Bruel for improvements to local store elimination. 42788 42789 * Herman A.J. ten Brugge for various fixes. 42790 42791 * Joerg Brunsmann for Java compiler hacking and help with the GCJ 42792 FAQ. 42793 42794 * Joe Buck for his direction via the steering committee from its 42795 creation to 2013. 42796 42797 * Craig Burley for leadership of the G77 Fortran effort. 42798 42799 * Stephan Buys for contributing Doxygen notes for libstdc++. 42800 42801 * Paolo Carlini for libstdc++ work: lots of efficiency improvements 42802 to the C++ strings, streambufs and formatted I/O, hard detective 42803 work on the frustrating localization issues, and keeping up with 42804 the problem reports. 42805 42806 * John Carr for his alias work, SPARC hacking, infrastructure 42807 improvements, previous contributions to the steering committee, 42808 loop optimizations, etc. 42809 42810 * Stephane Carrez for 68HC11 and 68HC12 ports. 42811 42812 * Steve Chamberlain for support for the Renesas SH and H8 processors 42813 and the PicoJava processor, and for GCJ config fixes. 42814 42815 * Glenn Chambers for help with the GCJ FAQ. 42816 42817 * John-Marc Chandonia for various libgcj patches. 42818 42819 * Denis Chertykov for contributing and maintaining the AVR port, the 42820 first GCC port for an 8-bit architecture. 42821 42822 * Scott Christley for his Objective-C contributions. 42823 42824 * Eric Christopher for his Java porting help and clean-ups. 42825 42826 * Branko Cibej for more warning contributions. 42827 42828 * The GNU Classpath project for all of their merged runtime code. 42829 42830 * Nick Clifton for arm, mcore, fr30, v850, m32r, msp430 rx work, 42831 `--help', and other random hacking. 42832 42833 * Michael Cook for libstdc++ cleanup patches to reduce warnings. 42834 42835 * R. Kelley Cook for making GCC buildable from a read-only directory 42836 as well as other miscellaneous build process and documentation 42837 clean-ups. 42838 42839 * Ralf Corsepius for SH testing and minor bug fixing. 42840 42841 * Stan Cox for care and feeding of the x86 port and lots of behind 42842 the scenes hacking. 42843 42844 * Alex Crain provided changes for the 3b1. 42845 42846 * Ian Dall for major improvements to the NS32k port. 42847 42848 * Paul Dale for his work to add uClinux platform support to the m68k 42849 backend. 42850 42851 * Dario Dariol contributed the four varieties of sample programs 42852 that print a copy of their source. 42853 42854 * Russell Davidson for fstream and stringstream fixes in libstdc++. 42855 42856 * Bud Davis for work on the G77 and GNU Fortran compilers. 42857 42858 * Mo DeJong for GCJ and libgcj bug fixes. 42859 42860 * DJ Delorie for the DJGPP port, build and libiberty maintenance, 42861 various bug fixes, and the M32C, MeP, MSP430, and RL78 ports. 42862 42863 * Arnaud Desitter for helping to debug GNU Fortran. 42864 42865 * Gabriel Dos Reis for contributions to G++, contributions and 42866 maintenance of GCC diagnostics infrastructure, libstdc++-v3, 42867 including `valarray<>', `complex<>', maintaining the numerics 42868 library (including that pesky `<limits>' :-) and keeping 42869 up-to-date anything to do with numbers. 42870 42871 * Ulrich Drepper for his work on glibc, testing of GCC using glibc, 42872 ISO C99 support, CFG dumping support, etc., plus support of the 42873 C++ runtime libraries including for all kinds of C interface 42874 issues, contributing and maintaining `complex<>', sanity checking 42875 and disbursement, configuration architecture, libio maintenance, 42876 and early math work. 42877 42878 * Franc,ois Dumont for his work on libstdc++-v3, especially 42879 maintaining and improving `debug-mode' and associative and 42880 unordered containers. 42881 42882 * Zdenek Dvorak for a new loop unroller and various fixes. 42883 42884 * Michael Eager for his work on the Xilinx MicroBlaze port. 42885 42886 * Richard Earnshaw for his ongoing work with the ARM. 42887 42888 * David Edelsohn for his direction via the steering committee, 42889 ongoing work with the RS6000/PowerPC port, help cleaning up Haifa 42890 loop changes, doing the entire AIX port of libstdc++ with his bare 42891 hands, and for ensuring GCC properly keeps working on AIX. 42892 42893 * Kevin Ediger for the floating point formatting of num_put::do_put 42894 in libstdc++. 42895 42896 * Phil Edwards for libstdc++ work including configuration hackery, 42897 documentation maintainer, chief breaker of the web pages, the 42898 occasional iostream bug fix, and work on shared library symbol 42899 versioning. 42900 42901 * Paul Eggert for random hacking all over GCC. 42902 42903 * Mark Elbrecht for various DJGPP improvements, and for libstdc++ 42904 configuration support for locales and fstream-related fixes. 42905 42906 * Vadim Egorov for libstdc++ fixes in strings, streambufs, and 42907 iostreams. 42908 42909 * Christian Ehrhardt for dealing with bug reports. 42910 42911 * Ben Elliston for his work to move the Objective-C runtime into its 42912 own subdirectory and for his work on autoconf. 42913 42914 * Revital Eres for work on the PowerPC 750CL port. 42915 42916 * Marc Espie for OpenBSD support. 42917 42918 * Doug Evans for much of the global optimization framework, arc, 42919 m32r, and SPARC work. 42920 42921 * Christopher Faylor for his work on the Cygwin port and for caring 42922 and feeding the gcc.gnu.org box and saving its users tons of spam. 42923 42924 * Fred Fish for BeOS support and Ada fixes. 42925 42926 * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ. 42927 42928 * Peter Gerwinski for various bug fixes and the Pascal front end. 42929 42930 * Kaveh R. Ghazi for his direction via the steering committee, 42931 amazing work to make `-W -Wall -W* -Werror' useful, and testing 42932 GCC on a plethora of platforms. Kaveh extends his gratitude to 42933 the CAIP Center at Rutgers University for providing him with 42934 computing resources to work on Free Software from the late 1980s 42935 to 2010. 42936 42937 * John Gilmore for a donation to the FSF earmarked improving GNU 42938 Java. 42939 42940 * Judy Goldberg for c++ contributions. 42941 42942 * Torbjorn Granlund for various fixes and the c-torture testsuite, 42943 multiply- and divide-by-constant optimization, improved long long 42944 support, improved leaf function register allocation, and his 42945 direction via the steering committee. 42946 42947 * Jonny Grant for improvements to `collect2's' `--help' 42948 documentation. 42949 42950 * Anthony Green for his `-Os' contributions, the moxie port, and 42951 Java front end work. 42952 42953 * Stu Grossman for gdb hacking, allowing GCJ developers to debug 42954 Java code. 42955 42956 * Michael K. Gschwind contributed the port to the PDP-11. 42957 42958 * Richard Biener for his ongoing middle-end contributions and bug 42959 fixes and for release management. 42960 42961 * Ron Guilmette implemented the `protoize' and `unprotoize' tools, 42962 the support for Dwarf symbolic debugging information, and much of 42963 the support for System V Release 4. He has also worked heavily on 42964 the Intel 386 and 860 support. 42965 42966 * Sumanth Gundapaneni for contributing the CR16 port. 42967 42968 * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload 42969 GCSE. 42970 42971 * Bruno Haible for improvements in the runtime overhead for EH, new 42972 warnings and assorted bug fixes. 42973 42974 * Andrew Haley for his amazing Java compiler and library efforts. 42975 42976 * Chris Hanson assisted in making GCC work on HP-UX for the 9000 42977 series 300. 42978 42979 * Michael Hayes for various thankless work he's done trying to get 42980 the c30/c40 ports functional. Lots of loop and unroll 42981 improvements and fixes. 42982 42983 * Dara Hazeghi for wading through myriads of target-specific bug 42984 reports. 42985 42986 * Kate Hedstrom for staking the G77 folks with an initial testsuite. 42987 42988 * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64 42989 work, loop opts, and generally fixing lots of old problems we've 42990 ignored for years, flow rewrite and lots of further stuff, 42991 including reviewing tons of patches. 42992 42993 * Aldy Hernandez for working on the PowerPC port, SIMD support, and 42994 various fixes. 42995 42996 * Nobuyuki Hikichi of Software Research Associates, Tokyo, 42997 contributed the support for the Sony NEWS machine. 42998 42999 * Kazu Hirata for caring and feeding the Renesas H8/300 port and 43000 various fixes. 43001 43002 * Katherine Holcomb for work on GNU Fortran. 43003 43004 * Manfred Hollstein for his ongoing work to keep the m88k alive, lots 43005 of testing and bug fixing, particularly of GCC configury code. 43006 43007 * Steve Holmgren for MachTen patches. 43008 43009 * Mat Hostetter for work on the TILE-Gx and TILEPro ports. 43010 43011 * Jan Hubicka for his x86 port improvements. 43012 43013 * Falk Hueffner for working on C and optimization bug reports. 43014 43015 * Bernardo Innocenti for his m68k work, including merging of 43016 ColdFire improvements and uClinux support. 43017 43018 * Christian Iseli for various bug fixes. 43019 43020 * Kamil Iskra for general m68k hacking. 43021 43022 * Lee Iverson for random fixes and MIPS testing. 43023 43024 * Balaji V. Iyer for Cilk+ development and merging. 43025 43026 * Andreas Jaeger for testing and benchmarking of GCC and various bug 43027 fixes. 43028 43029 * Martin Jambor for his work on inter-procedural optimizations, the 43030 switch conversion pass, and scalar replacement of aggregates. 43031 43032 * Jakub Jelinek for his SPARC work and sibling call optimizations as 43033 well as lots of bug fixes and test cases, and for improving the 43034 Java build system. 43035 43036 * Janis Johnson for ia64 testing and fixes, her quality improvement 43037 sidetracks, and web page maintenance. 43038 43039 * Kean Johnston for SCO OpenServer support and various fixes. 43040 43041 * Tim Josling for the sample language treelang based originally on 43042 Richard Kenner's "toy" language. 43043 43044 * Nicolai Josuttis for additional libstdc++ documentation. 43045 43046 * Klaus Kaempf for his ongoing work to make alpha-vms a viable 43047 target. 43048 43049 * Steven G. Kargl for work on GNU Fortran. 43050 43051 * David Kashtan of SRI adapted GCC to VMS. 43052 43053 * Ryszard Kabatek for many, many libstdc++ bug fixes and 43054 optimizations of strings, especially member functions, and for 43055 auto_ptr fixes. 43056 43057 * Geoffrey Keating for his ongoing work to make the PPC work for 43058 GNU/Linux and his automatic regression tester. 43059 43060 * Brendan Kehoe for his ongoing work with G++ and for a lot of early 43061 work in just about every part of libstdc++. 43062 43063 * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the 43064 MIL-STD-1750A. 43065 43066 * Richard Kenner of the New York University Ultracomputer Research 43067 Laboratory wrote the machine descriptions for the AMD 29000, the 43068 DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the 43069 support for instruction attributes. He also made changes to 43070 better support RISC processors including changes to common 43071 subexpression elimination, strength reduction, function calling 43072 sequence handling, and condition code support, in addition to 43073 generalizing the code for frame pointer elimination and delay slot 43074 scheduling. Richard Kenner was also the head maintainer of GCC 43075 for several years. 43076 43077 * Mumit Khan for various contributions to the Cygwin and Mingw32 43078 ports and maintaining binary releases for Microsoft Windows hosts, 43079 and for massive libstdc++ porting work to Cygwin/Mingw32. 43080 43081 * Robin Kirkham for cpu32 support. 43082 43083 * Mark Klein for PA improvements. 43084 43085 * Thomas Koenig for various bug fixes. 43086 43087 * Bruce Korb for the new and improved fixincludes code. 43088 43089 * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3 43090 effort. 43091 43092 * Maxim Kuvyrkov for contributions to the instruction scheduler, the 43093 Android and m68k/Coldfire ports, and optimizations. 43094 43095 * Charles LaBrec contributed the support for the Integrated Solutions 43096 68020 system. 43097 43098 * Asher Langton and Mike Kumbera for contributing Cray pointer 43099 support to GNU Fortran, and for other GNU Fortran improvements. 43100 43101 * Jeff Law for his direction via the steering committee, 43102 coordinating the entire egcs project and GCC 2.95, rolling out 43103 snapshots and releases, handling merges from GCC2, reviewing tons 43104 of patches that might have fallen through the cracks else, and 43105 random but extensive hacking. 43106 43107 * Walter Lee for work on the TILE-Gx and TILEPro ports. 43108 43109 * Marc Lehmann for his direction via the steering committee and 43110 helping with analysis and improvements of x86 performance. 43111 43112 * Victor Leikehman for work on GNU Fortran. 43113 43114 * Ted Lemon wrote parts of the RTL reader and printer. 43115 43116 * Kriang Lerdsuwanakij for C++ improvements including template as 43117 template parameter support, and many C++ fixes. 43118 43119 * Warren Levy for tremendous work on libgcj (Java Runtime Library) 43120 and random work on the Java front end. 43121 43122 * Alain Lichnewsky ported GCC to the MIPS CPU. 43123 43124 * Oskar Liljeblad for hacking on AWT and his many Java bug reports 43125 and patches. 43126 43127 * Robert Lipe for OpenServer support, new testsuites, testing, etc. 43128 43129 * Chen Liqin for various S+core related fixes/improvement, and for 43130 maintaining the S+core port. 43131 43132 * Weiwen Liu for testing and various bug fixes. 43133 43134 * Manuel Lo'pez-Iba'n~ez for improving `-Wconversion' and many other 43135 diagnostics fixes and improvements. 43136 43137 * Dave Love for his ongoing work with the Fortran front end and 43138 runtime libraries. 43139 43140 * Martin von Lo"wis for internal consistency checking infrastructure, 43141 various C++ improvements including namespace support, and tons of 43142 assistance with libstdc++/compiler merges. 43143 43144 * H.J. Lu for his previous contributions to the steering committee, 43145 many x86 bug reports, prototype patches, and keeping the GNU/Linux 43146 ports working. 43147 43148 * Greg McGary for random fixes and (someday) bounded pointers. 43149 43150 * Andrew MacLeod for his ongoing work in building a real EH system, 43151 various code generation improvements, work on the global 43152 optimizer, etc. 43153 43154 * Vladimir Makarov for hacking some ugly i960 problems, PowerPC 43155 hacking improvements to compile-time performance, overall 43156 knowledge and direction in the area of instruction scheduling, and 43157 design and implementation of the automaton based instruction 43158 scheduler. 43159 43160 * Bob Manson for his behind the scenes work on dejagnu. 43161 43162 * John Marino for contributing the DragonFly BSD port. 43163 43164 * Philip Martin for lots of libstdc++ string and vector iterator 43165 fixes and improvements, and string clean up and testsuites. 43166 43167 * Michael Matz for his work on dominance tree discovery, the x86-64 43168 port, link-time optimization framework and general optimization 43169 improvements. 43170 43171 * All of the Mauve project contributors, for Java test code. 43172 43173 * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements. 43174 43175 * Adam Megacz for his work on the Microsoft Windows port of GCJ. 43176 43177 * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS, 43178 powerpc, haifa, ECOFF debug support, and other assorted hacking. 43179 43180 * Jason Merrill for his direction via the steering committee and 43181 leading the G++ effort. 43182 43183 * Martin Michlmayr for testing GCC on several architectures using the 43184 entire Debian archive. 43185 43186 * David Miller for his direction via the steering committee, lots of 43187 SPARC work, improvements in jump.c and interfacing with the Linux 43188 kernel developers. 43189 43190 * Gary Miller ported GCC to Charles River Data Systems machines. 43191 43192 * Alfred Minarik for libstdc++ string and ios bug fixes, and turning 43193 the entire libstdc++ testsuite namespace-compatible. 43194 43195 * Mark Mitchell for his direction via the steering committee, 43196 mountains of C++ work, load/store hoisting out of loops, alias 43197 analysis improvements, ISO C `restrict' support, and serving as 43198 release manager from 2000 to 2011. 43199 43200 * Alan Modra for various GNU/Linux bits and testing. 43201 43202 * Toon Moene for his direction via the steering committee, Fortran 43203 maintenance, and his ongoing work to make us make Fortran run fast. 43204 43205 * Jason Molenda for major help in the care and feeding of all the 43206 services on the gcc.gnu.org (formerly egcs.cygnus.com) 43207 machine--mail, web services, ftp services, etc etc. Doing all 43208 this work on scrap paper and the backs of envelopes would have 43209 been... difficult. 43210 43211 * Catherine Moore for fixing various ugly problems we have sent her 43212 way, including the haifa bug which was killing the Alpha & PowerPC 43213 Linux kernels. 43214 43215 * Mike Moreton for his various Java patches. 43216 43217 * David Mosberger-Tang for various Alpha improvements, and for the 43218 initial IA-64 port. 43219 43220 * Stephen Moshier contributed the floating point emulator that 43221 assists in cross-compilation and permits support for floating 43222 point numbers wider than 64 bits and for ISO C99 support. 43223 43224 * Bill Moyer for his behind the scenes work on various issues. 43225 43226 * Philippe De Muyter for his work on the m68k port. 43227 43228 * Joseph S. Myers for his work on the PDP-11 port, format checking 43229 and ISO C99 support, and continuous emphasis on (and contributions 43230 to) documentation. 43231 43232 * Nathan Myers for his work on libstdc++-v3: architecture and 43233 authorship through the first three snapshots, including 43234 implementation of locale infrastructure, string, shadow C headers, 43235 and the initial project documentation (DESIGN, CHECKLIST, and so 43236 forth). Later, more work on MT-safe string and shadow headers. 43237 43238 * Felix Natter for documentation on porting libstdc++. 43239 43240 * Nathanael Nerode for cleaning up the configuration/build process. 43241 43242 * NeXT, Inc. donated the front end that supports the Objective-C 43243 language. 43244 43245 * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to 43246 the search engine setup, various documentation fixes and other 43247 small fixes. 43248 43249 * Geoff Noer for his work on getting cygwin native builds working. 43250 43251 * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance 43252 tracking web pages, GIMPLE tuples, and assorted fixes. 43253 43254 * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64, 43255 FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and 43256 related infrastructure improvements. 43257 43258 * Alexandre Oliva for various build infrastructure improvements, 43259 scripts and amazing testing work, including keeping libtool issues 43260 sane and happy. 43261 43262 * Stefan Olsson for work on mt_alloc. 43263 43264 * Melissa O'Neill for various NeXT fixes. 43265 43266 * Rainer Orth for random MIPS work, including improvements to GCC's 43267 o32 ABI support, improvements to dejagnu's MIPS support, Java 43268 configuration clean-ups and porting work, and maintaining the 43269 IRIX, Solaris 2, and Tru64 UNIX ports. 43270 43271 * Hartmut Penner for work on the s390 port. 43272 43273 * Paul Petersen wrote the machine description for the Alliant FX/8. 43274 43275 * Alexandre Petit-Bianco for implementing much of the Java compiler 43276 and continued Java maintainership. 43277 43278 * Matthias Pfaller for major improvements to the NS32k port. 43279 43280 * Gerald Pfeifer for his direction via the steering committee, 43281 pointing out lots of problems we need to solve, maintenance of the 43282 web pages, and taking care of documentation maintenance in general. 43283 43284 * Andrew Pinski for processing bug reports by the dozen. 43285 43286 * Ovidiu Predescu for his work on the Objective-C front end and 43287 runtime libraries. 43288 43289 * Jerry Quinn for major performance improvements in C++ formatted 43290 I/O. 43291 43292 * Ken Raeburn for various improvements to checker, MIPS ports and 43293 various cleanups in the compiler. 43294 43295 * Rolf W. Rasmussen for hacking on AWT. 43296 43297 * David Reese of Sun Microsystems contributed to the Solaris on 43298 PowerPC port. 43299 43300 * Volker Reichelt for keeping up with the problem reports. 43301 43302 * Joern Rennecke for maintaining the sh port, loop, regmove & reload 43303 hacking and developing and maintaining the Epiphany port. 43304 43305 * Loren J. Rittle for improvements to libstdc++-v3 including the 43306 FreeBSD port, threading fixes, thread-related configury changes, 43307 critical threading documentation, and solutions to really tricky 43308 I/O problems, as well as keeping GCC properly working on FreeBSD 43309 and continuous testing. 43310 43311 * Craig Rodrigues for processing tons of bug reports. 43312 43313 * Ola Ro"nnerup for work on mt_alloc. 43314 43315 * Gavin Romig-Koch for lots of behind the scenes MIPS work. 43316 43317 * David Ronis inspired and encouraged Craig to rewrite the G77 43318 documentation in texinfo format by contributing a first pass at a 43319 translation of the old `g77-0.5.16/f/DOC' file. 43320 43321 * Ken Rose for fixes to GCC's delay slot filling code. 43322 43323 * Ira Rosen for her contributions to the auto-vectorizer. 43324 43325 * Paul Rubin wrote most of the preprocessor. 43326 43327 * Pe'tur Runo'lfsson for major performance improvements in C++ 43328 formatted I/O and large file support in C++ filebuf. 43329 43330 * Chip Salzenberg for libstdc++ patches and improvements to locales, 43331 traits, Makefiles, libio, libtool hackery, and "long long" support. 43332 43333 * Juha Sarlin for improvements to the H8 code generator. 43334 43335 * Greg Satz assisted in making GCC work on HP-UX for the 9000 series 43336 300. 43337 43338 * Roger Sayle for improvements to constant folding and GCC's RTL 43339 optimizers as well as for fixing numerous bugs. 43340 43341 * Bradley Schatz for his work on the GCJ FAQ. 43342 43343 * Peter Schauer wrote the code to allow debugging to work on the 43344 Alpha. 43345 43346 * William Schelter did most of the work on the Intel 80386 support. 43347 43348 * Tobias Schlu"ter for work on GNU Fortran. 43349 43350 * Bernd Schmidt for various code generation improvements and major 43351 work in the reload pass, serving as release manager for GCC 43352 2.95.3, and work on the Blackfin and C6X ports. 43353 43354 * Peter Schmid for constant testing of libstdc++--especially 43355 application testing, going above and beyond what was requested for 43356 the release criteria--and libstdc++ header file tweaks. 43357 43358 * Jason Schroeder for jcf-dump patches. 43359 43360 * Andreas Schwab for his work on the m68k port. 43361 43362 * Lars Segerlund for work on GNU Fortran. 43363 43364 * Dodji Seketeli for numerous C++ bug fixes and debug info 43365 improvements. 43366 43367 * Tim Shen for major work on `<regex>'. 43368 43369 * Joel Sherrill for his direction via the steering committee, RTEMS 43370 contributions and RTEMS testing. 43371 43372 * Nathan Sidwell for many C++ fixes/improvements. 43373 43374 * Jeffrey Siegal for helping RMS with the original design of GCC, 43375 some code which handles the parse tree and RTL data structures, 43376 constant folding and help with the original VAX & m68k ports. 43377 43378 * Kenny Simpson for prompting libstdc++ fixes due to defect reports 43379 from the LWG (thereby keeping GCC in line with updates from the 43380 ISO). 43381 43382 * Franz Sirl for his ongoing work with making the PPC port stable 43383 for GNU/Linux. 43384 43385 * Andrey Slepuhin for assorted AIX hacking. 43386 43387 * Trevor Smigiel for contributing the SPU port. 43388 43389 * Christopher Smith did the port for Convex machines. 43390 43391 * Danny Smith for his major efforts on the Mingw (and Cygwin) ports. 43392 Retired from GCC maintainership August 2010, having mentored two 43393 new maintainers into the role. 43394 43395 * Randy Smith finished the Sun FPA support. 43396 43397 * Ed Smith-Rowland for his continuous work on libstdc++-v3, special 43398 functions, `<random>', and various improvements to C++11 features. 43399 43400 * Scott Snyder for queue, iterator, istream, and string fixes and 43401 libstdc++ testsuite entries. Also for providing the patch to G77 43402 to add rudimentary support for `INTEGER*1', `INTEGER*2', and 43403 `LOGICAL*1'. 43404 43405 * Zdenek Sojka for running automated regression testing of GCC and 43406 reporting numerous bugs. 43407 43408 * Jayant Sonar for contributing the CR16 port. 43409 43410 * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique. 43411 43412 * Richard Stallman, for writing the original GCC and launching the 43413 GNU project. 43414 43415 * Jan Stein of the Chalmers Computer Society provided support for 43416 Genix, as well as part of the 32000 machine description. 43417 43418 * Nigel Stephens for various mips16 related fixes/improvements. 43419 43420 * Jonathan Stone wrote the machine description for the Pyramid 43421 computer. 43422 43423 * Graham Stott for various infrastructure improvements. 43424 43425 * John Stracke for his Java HTTP protocol fixes. 43426 43427 * Mike Stump for his Elxsi port, G++ contributions over the years 43428 and more recently his vxworks contributions 43429 43430 * Jeff Sturm for Java porting help, bug fixes, and encouragement. 43431 43432 * Shigeya Suzuki for this fixes for the bsdi platforms. 43433 43434 * Ian Lance Taylor for the Go frontend, the initial mips16 and mips64 43435 support, general configury hacking, fixincludes, etc. 43436 43437 * Holger Teutsch provided the support for the Clipper CPU. 43438 43439 * Gary Thomas for his ongoing work to make the PPC work for 43440 GNU/Linux. 43441 43442 * Philipp Thomas for random bug fixes throughout the compiler 43443 43444 * Jason Thorpe for thread support in libstdc++ on NetBSD. 43445 43446 * Kresten Krab Thorup wrote the run time support for the Objective-C 43447 language and the fantastic Java bytecode interpreter. 43448 43449 * Michael Tiemann for random bug fixes, the first instruction 43450 scheduler, initial C++ support, function integration, NS32k, SPARC 43451 and M88k machine description work, delay slot scheduling. 43452 43453 * Andreas Tobler for his work porting libgcj to Darwin. 43454 43455 * Teemu Torma for thread safe exception handling support. 43456 43457 * Leonard Tower wrote parts of the parser, RTL generator, and RTL 43458 definitions, and of the VAX machine description. 43459 43460 * Daniel Towner and Hariharan Sandanagobalane contributed and 43461 maintain the picoChip port. 43462 43463 * Tom Tromey for internationalization support and for his many Java 43464 contributions and libgcj maintainership. 43465 43466 * Lassi Tuura for improvements to config.guess to determine HP 43467 processor types. 43468 43469 * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes. 43470 43471 * Andy Vaught for the design and initial implementation of the GNU 43472 Fortran front end. 43473 43474 * Brent Verner for work with the libstdc++ cshadow files and their 43475 associated configure steps. 43476 43477 * Todd Vierling for contributions for NetBSD ports. 43478 43479 * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML 43480 guidance. 43481 43482 * Dean Wakerley for converting the install documentation from HTML 43483 to texinfo in time for GCC 3.0. 43484 43485 * Krister Walfridsson for random bug fixes. 43486 43487 * Feng Wang for contributions to GNU Fortran. 43488 43489 * Stephen M. Webb for time and effort on making libstdc++ shadow 43490 files work with the tricky Solaris 8+ headers, and for pushing the 43491 build-time header tree. Also, for starting and driving the 43492 `<regex>' effort. 43493 43494 * John Wehle for various improvements for the x86 code generator, 43495 related infrastructure improvements to help x86 code generation, 43496 value range propagation and other work, WE32k port. 43497 43498 * Ulrich Weigand for work on the s390 port. 43499 43500 * Zack Weinberg for major work on cpplib and various other bug fixes. 43501 43502 * Matt Welsh for help with Linux Threads support in GCJ. 43503 43504 * Urban Widmark for help fixing java.io. 43505 43506 * Mark Wielaard for new Java library code and his work integrating 43507 with Classpath. 43508 43509 * Dale Wiles helped port GCC to the Tahoe. 43510 43511 * Bob Wilson from Tensilica, Inc. for the Xtensa port. 43512 43513 * Jim Wilson for his direction via the steering committee, tackling 43514 hard problems in various places that nobody else wanted to work 43515 on, strength reduction and other loop optimizations. 43516 43517 * Paul Woegerer and Tal Agmon for the CRX port. 43518 43519 * Carlo Wood for various fixes. 43520 43521 * Tom Wood for work on the m88k port. 43522 43523 * Chung-Ju Wu for his work on the Andes NDS32 port. 43524 43525 * Canqun Yang for work on GNU Fortran. 43526 43527 * Masanobu Yuhara of Fujitsu Laboratories implemented the machine 43528 description for the Tron architecture (specifically, the Gmicro). 43529 43530 * Kevin Zachmann helped port GCC to the Tahoe. 43531 43532 * Ayal Zaks for Swing Modulo Scheduling (SMS). 43533 43534 * Xiaoqiang Zhang for work on GNU Fortran. 43535 43536 * Gilles Zunino for help porting Java to Irix. 43537 43538 43539 The following people are recognized for their contributions to GNAT, 43540the Ada front end of GCC: 43541 * Bernard Banner 43542 43543 * Romain Berrendonner 43544 43545 * Geert Bosch 43546 43547 * Emmanuel Briot 43548 43549 * Joel Brobecker 43550 43551 * Ben Brosgol 43552 43553 * Vincent Celier 43554 43555 * Arnaud Charlet 43556 43557 * Chien Chieng 43558 43559 * Cyrille Comar 43560 43561 * Cyrille Crozes 43562 43563 * Robert Dewar 43564 43565 * Gary Dismukes 43566 43567 * Robert Duff 43568 43569 * Ed Falis 43570 43571 * Ramon Fernandez 43572 43573 * Sam Figueroa 43574 43575 * Vasiliy Fofanov 43576 43577 * Michael Friess 43578 43579 * Franco Gasperoni 43580 43581 * Ted Giering 43582 43583 * Matthew Gingell 43584 43585 * Laurent Guerby 43586 43587 * Jerome Guitton 43588 43589 * Olivier Hainque 43590 43591 * Jerome Hugues 43592 43593 * Hristian Kirtchev 43594 43595 * Jerome Lambourg 43596 43597 * Bruno Leclerc 43598 43599 * Albert Lee 43600 43601 * Sean McNeil 43602 43603 * Javier Miranda 43604 43605 * Laurent Nana 43606 43607 * Pascal Obry 43608 43609 * Dong-Ik Oh 43610 43611 * Laurent Pautet 43612 43613 * Brett Porter 43614 43615 * Thomas Quinot 43616 43617 * Nicolas Roche 43618 43619 * Pat Rogers 43620 43621 * Jose Ruiz 43622 43623 * Douglas Rupp 43624 43625 * Sergey Rybin 43626 43627 * Gail Schenker 43628 43629 * Ed Schonberg 43630 43631 * Nicolas Setton 43632 43633 * Samuel Tardieu 43634 43635 43636 The following people are recognized for their contributions of new 43637features, bug reports, testing and integration of classpath/libgcj for 43638GCC version 4.1: 43639 * Lillian Angel for `JTree' implementation and lots Free Swing 43640 additions and bug fixes. 43641 43642 * Wolfgang Baer for `GapContent' bug fixes. 43643 43644 * Anthony Balkissoon for `JList', Free Swing 1.5 updates and mouse 43645 event fixes, lots of Free Swing work including `JTable' editing. 43646 43647 * Stuart Ballard for RMI constant fixes. 43648 43649 * Goffredo Baroncelli for `HTTPURLConnection' fixes. 43650 43651 * Gary Benson for `MessageFormat' fixes. 43652 43653 * Daniel Bonniot for `Serialization' fixes. 43654 43655 * Chris Burdess for lots of gnu.xml and http protocol fixes, `StAX' 43656 and `DOM xml:id' support. 43657 43658 * Ka-Hing Cheung for `TreePath' and `TreeSelection' fixes. 43659 43660 * Archie Cobbs for build fixes, VM interface updates, 43661 `URLClassLoader' updates. 43662 43663 * Kelley Cook for build fixes. 43664 43665 * Martin Cordova for Suggestions for better `SocketTimeoutException'. 43666 43667 * David Daney for `BitSet' bug fixes, `HttpURLConnection' rewrite 43668 and improvements. 43669 43670 * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo 43671 2D support. Lots of imageio framework additions, lots of AWT and 43672 Free Swing bug fixes. 43673 43674 * Jeroen Frijters for `ClassLoader' and nio cleanups, serialization 43675 fixes, better `Proxy' support, bug fixes and IKVM integration. 43676 43677 * Santiago Gala for `AccessControlContext' fixes. 43678 43679 * Nicolas Geoffray for `VMClassLoader' and `AccessController' 43680 improvements. 43681 43682 * David Gilbert for `basic' and `metal' icon and plaf support and 43683 lots of documenting, Lots of Free Swing and metal theme additions. 43684 `MetalIconFactory' implementation. 43685 43686 * Anthony Green for `MIDI' framework, `ALSA' and `DSSI' providers. 43687 43688 * Andrew Haley for `Serialization' and `URLClassLoader' fixes, gcj 43689 build speedups. 43690 43691 * Kim Ho for `JFileChooser' implementation. 43692 43693 * Andrew John Hughes for `Locale' and net fixes, URI RFC2986 43694 updates, `Serialization' fixes, `Properties' XML support and 43695 generic branch work, VMIntegration guide update. 43696 43697 * Bastiaan Huisman for `TimeZone' bug fixing. 43698 43699 * Andreas Jaeger for mprec updates. 43700 43701 * Paul Jenner for better `-Werror' support. 43702 43703 * Ito Kazumitsu for `NetworkInterface' implementation and updates. 43704 43705 * Roman Kennke for `BoxLayout', `GrayFilter' and `SplitPane', plus 43706 bug fixes all over. Lots of Free Swing work including styled text. 43707 43708 * Simon Kitching for `String' cleanups and optimization suggestions. 43709 43710 * Michael Koch for configuration fixes, `Locale' updates, bug and 43711 build fixes. 43712 43713 * Guilhem Lavaux for configuration, thread and channel fixes and 43714 Kaffe integration. JCL native `Pointer' updates. Logger bug fixes. 43715 43716 * David Lichteblau for JCL support library global/local reference 43717 cleanups. 43718 43719 * Aaron Luchko for JDWP updates and documentation fixes. 43720 43721 * Ziga Mahkovec for `Graphics2D' upgraded to Cairo 0.5 and new regex 43722 features. 43723 43724 * Sven de Marothy for BMP imageio support, CSS and `TextLayout' 43725 fixes. `GtkImage' rewrite, 2D, awt, free swing and date/time fixes 43726 and implementing the Qt4 peers. 43727 43728 * Casey Marshall for crypto algorithm fixes, `FileChannel' lock, 43729 `SystemLogger' and `FileHandler' rotate implementations, NIO 43730 `FileChannel.map' support, security and policy updates. 43731 43732 * Bryce McKinlay for RMI work. 43733 43734 * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus 43735 testing and documenting. 43736 43737 * Kalle Olavi Niemitalo for build fixes. 43738 43739 * Rainer Orth for build fixes. 43740 43741 * Andrew Overholt for `File' locking fixes. 43742 43743 * Ingo Proetel for `Image', `Logger' and `URLClassLoader' updates. 43744 43745 * Olga Rodimina for `MenuSelectionManager' implementation. 43746 43747 * Jan Roehrich for `BasicTreeUI' and `JTree' fixes. 43748 43749 * Julian Scheid for documentation updates and gjdoc support. 43750 43751 * Christian Schlichtherle for zip fixes and cleanups. 43752 43753 * Robert Schuster for documentation updates and beans fixes, 43754 `TreeNode' enumerations and `ActionCommand' and various fixes, XML 43755 and URL, AWT and Free Swing bug fixes. 43756 43757 * Keith Seitz for lots of JDWP work. 43758 43759 * Christian Thalinger for 64-bit cleanups, Configuration and VM 43760 interface fixes and `CACAO' integration, `fdlibm' updates. 43761 43762 * Gael Thomas for `VMClassLoader' boot packages support suggestions. 43763 43764 * Andreas Tobler for Darwin and Solaris testing and fixing, `Qt4' 43765 support for Darwin/OS X, `Graphics2D' support, `gtk+' updates. 43766 43767 * Dalibor Topic for better `DEBUG' support, build cleanups and Kaffe 43768 integration. `Qt4' build infrastructure, `SHA1PRNG' and 43769 `GdkPixbugDecoder' updates. 43770 43771 * Tom Tromey for Eclipse integration, generics work, lots of bug 43772 fixes and gcj integration including coordinating The Big Merge. 43773 43774 * Mark Wielaard for bug fixes, packaging and release management, 43775 `Clipboard' implementation, system call interrupts and network 43776 timeouts and `GdkPixpufDecoder' fixes. 43777 43778 43779 In addition to the above, all of which also contributed time and 43780energy in testing GCC, we would like to thank the following for their 43781contributions to testing: 43782 43783 * Michael Abd-El-Malek 43784 43785 * Thomas Arend 43786 43787 * Bonzo Armstrong 43788 43789 * Steven Ashe 43790 43791 * Chris Baldwin 43792 43793 * David Billinghurst 43794 43795 * Jim Blandy 43796 43797 * Stephane Bortzmeyer 43798 43799 * Horst von Brand 43800 43801 * Frank Braun 43802 43803 * Rodney Brown 43804 43805 * Sidney Cadot 43806 43807 * Bradford Castalia 43808 43809 * Robert Clark 43810 43811 * Jonathan Corbet 43812 43813 * Ralph Doncaster 43814 43815 * Richard Emberson 43816 43817 * Levente Farkas 43818 43819 * Graham Fawcett 43820 43821 * Mark Fernyhough 43822 43823 * Robert A. French 43824 43825 * Jo"rgen Freyh 43826 43827 * Mark K. Gardner 43828 43829 * Charles-Antoine Gauthier 43830 43831 * Yung Shing Gene 43832 43833 * David Gilbert 43834 43835 * Simon Gornall 43836 43837 * Fred Gray 43838 43839 * John Griffin 43840 43841 * Patrik Hagglund 43842 43843 * Phil Hargett 43844 43845 * Amancio Hasty 43846 43847 * Takafumi Hayashi 43848 43849 * Bryan W. Headley 43850 43851 * Kevin B. Hendricks 43852 43853 * Joep Jansen 43854 43855 * Christian Joensson 43856 43857 * Michel Kern 43858 43859 * David Kidd 43860 43861 * Tobias Kuipers 43862 43863 * Anand Krishnaswamy 43864 43865 * A. O. V. Le Blanc 43866 43867 * llewelly 43868 43869 * Damon Love 43870 43871 * Brad Lucier 43872 43873 * Matthias Klose 43874 43875 * Martin Knoblauch 43876 43877 * Rick Lutowski 43878 43879 * Jesse Macnish 43880 43881 * Stefan Morrell 43882 43883 * Anon A. Mous 43884 43885 * Matthias Mueller 43886 43887 * Pekka Nikander 43888 43889 * Rick Niles 43890 43891 * Jon Olson 43892 43893 * Magnus Persson 43894 43895 * Chris Pollard 43896 43897 * Richard Polton 43898 43899 * Derk Reefman 43900 43901 * David Rees 43902 43903 * Paul Reilly 43904 43905 * Tom Reilly 43906 43907 * Torsten Rueger 43908 43909 * Danny Sadinoff 43910 43911 * Marc Schifer 43912 43913 * Erik Schnetter 43914 43915 * Wayne K. Schroll 43916 43917 * David Schuler 43918 43919 * Vin Shelton 43920 43921 * Tim Souder 43922 43923 * Adam Sulmicki 43924 43925 * Bill Thorson 43926 43927 * George Talbot 43928 43929 * Pedro A. M. Vazquez 43930 43931 * Gregory Warnes 43932 43933 * Ian Watson 43934 43935 * David E. Young 43936 43937 * And many others 43938 43939 And finally we'd like to thank everyone who uses the compiler, provides 43940feedback and generally reminds us why we're doing this work in the first 43941place. 43942 43943 43944File: gccint.info, Node: Option Index, Next: Concept Index, Prev: Contributors, Up: Top 43945 43946Option Index 43947************ 43948 43949GCC's command line options are indexed here without any initial `-' or 43950`--'. Where an option has both positive and negative forms (such as 43951`-fOPTION' and `-fno-OPTION'), relevant entries in the manual are 43952indexed under the most appropriate form; it may sometimes be useful to 43953look up both forms. 43954 43955[index] 43956* Menu: 43957 43958* fltrans: Internal flags. (line 18) 43959* fltrans-output-list: Internal flags. (line 23) 43960* fresolution: Internal flags. (line 27) 43961* fwpa: Internal flags. (line 9) 43962* msoft-float: Soft float library routines. 43963 (line 6) 43964 43965 43966File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top 43967 43968Concept Index 43969************* 43970 43971[index] 43972* Menu: 43973 43974* ! in constraint: Multi-Alternative. (line 47) 43975* # in constraint: Modifiers. (line 78) 43976* # in template: Output Template. (line 66) 43977* #pragma: Misc. (line 387) 43978* $ in constraint: Multi-Alternative. (line 56) 43979* % in constraint: Modifiers. (line 52) 43980* % in GTY option: GTY Options. (line 18) 43981* % in template: Output Template. (line 6) 43982* & in constraint: Modifiers. (line 25) 43983* (: GIMPLE API. (line 31) 43984* (nil): RTL Objects. (line 73) 43985* * in constraint: Modifiers. (line 83) 43986* * in template: Output Statement. (line 29) 43987* *gimple_build_asm_vec: GIMPLE_ASM. (line 9) 43988* *gimple_build_assign: GIMPLE_ASSIGN. (line 7) 43989* *gimple_build_bind: GIMPLE_BIND. (line 8) 43990* *gimple_build_call: GIMPLE_CALL. (line 8) 43991* *gimple_build_call_from_tree: GIMPLE_CALL. (line 16) 43992* *gimple_build_call_vec: GIMPLE_CALL. (line 25) 43993* *gimple_build_catch: GIMPLE_CATCH. (line 8) 43994* *gimple_build_cond: GIMPLE_COND. (line 8) 43995* *gimple_build_cond_from_tree: GIMPLE_COND. (line 16) 43996* *gimple_build_debug_bind: GIMPLE_DEBUG. (line 8) 43997* *gimple_build_eh_filter: GIMPLE_EH_FILTER. (line 8) 43998* *gimple_build_goto: GIMPLE_GOTO. (line 7) 43999* *gimple_build_label: GIMPLE_LABEL. (line 7) 44000* *gimple_build_omp_atomic_load: GIMPLE_OMP_ATOMIC_LOAD. 44001 (line 8) 44002* *gimple_build_omp_atomic_store: GIMPLE_OMP_ATOMIC_STORE. 44003 (line 8) 44004* *gimple_build_omp_continue: GIMPLE_OMP_CONTINUE. 44005 (line 8) 44006* *gimple_build_omp_critical: GIMPLE_OMP_CRITICAL. 44007 (line 8) 44008* *gimple_build_omp_for: GIMPLE_OMP_FOR. (line 9) 44009* *gimple_build_omp_parallel: GIMPLE_OMP_PARALLEL. 44010 (line 8) 44011* *gimple_build_omp_sections: GIMPLE_OMP_SECTIONS. 44012 (line 8) 44013* *gimple_build_omp_single: GIMPLE_OMP_SINGLE. (line 8) 44014* *gimple_build_resx: GIMPLE_RESX. (line 7) 44015* *gimple_build_return: GIMPLE_RETURN. (line 7) 44016* *gimple_build_switch: GIMPLE_SWITCH. (line 8) 44017* *gimple_build_try: GIMPLE_TRY. (line 8) 44018* + in constraint: Modifiers. (line 12) 44019* -fsection-anchors <1>: Anchored Addresses. (line 6) 44020* -fsection-anchors: Special Accessors. (line 120) 44021* /c in RTL dump: Flags. (line 221) 44022* /f in RTL dump: Flags. (line 229) 44023* /i in RTL dump: Flags. (line 274) 44024* /j in RTL dump: Flags. (line 286) 44025* /s in RTL dump: Flags. (line 245) 44026* /u in RTL dump: Flags. (line 296) 44027* /v in RTL dump: Flags. (line 328) 44028* 0 in constraint: Simple Constraints. (line 130) 44029* < in constraint: Simple Constraints. (line 48) 44030* = in constraint: Modifiers. (line 8) 44031* > in constraint: Simple Constraints. (line 61) 44032* ? in constraint: Multi-Alternative. (line 41) 44033* \: Output Template. (line 46) 44034* ^ in constraint: Multi-Alternative. (line 52) 44035* __absvdi2: Integer library routines. 44036 (line 107) 44037* __absvsi2: Integer library routines. 44038 (line 106) 44039* __addda3: Fixed-point fractional library routines. 44040 (line 45) 44041* __adddf3: Soft float library routines. 44042 (line 23) 44043* __adddq3: Fixed-point fractional library routines. 44044 (line 33) 44045* __addha3: Fixed-point fractional library routines. 44046 (line 43) 44047* __addhq3: Fixed-point fractional library routines. 44048 (line 30) 44049* __addqq3: Fixed-point fractional library routines. 44050 (line 29) 44051* __addsa3: Fixed-point fractional library routines. 44052 (line 44) 44053* __addsf3: Soft float library routines. 44054 (line 22) 44055* __addsq3: Fixed-point fractional library routines. 44056 (line 31) 44057* __addta3: Fixed-point fractional library routines. 44058 (line 47) 44059* __addtf3: Soft float library routines. 44060 (line 25) 44061* __adduda3: Fixed-point fractional library routines. 44062 (line 53) 44063* __addudq3: Fixed-point fractional library routines. 44064 (line 41) 44065* __adduha3: Fixed-point fractional library routines. 44066 (line 49) 44067* __adduhq3: Fixed-point fractional library routines. 44068 (line 37) 44069* __adduqq3: Fixed-point fractional library routines. 44070 (line 35) 44071* __addusa3: Fixed-point fractional library routines. 44072 (line 51) 44073* __addusq3: Fixed-point fractional library routines. 44074 (line 39) 44075* __adduta3: Fixed-point fractional library routines. 44076 (line 55) 44077* __addvdi3: Integer library routines. 44078 (line 111) 44079* __addvsi3: Integer library routines. 44080 (line 110) 44081* __addxf3: Soft float library routines. 44082 (line 27) 44083* __ashlda3: Fixed-point fractional library routines. 44084 (line 351) 44085* __ashldi3: Integer library routines. 44086 (line 14) 44087* __ashldq3: Fixed-point fractional library routines. 44088 (line 340) 44089* __ashlha3: Fixed-point fractional library routines. 44090 (line 349) 44091* __ashlhq3: Fixed-point fractional library routines. 44092 (line 337) 44093* __ashlqq3: Fixed-point fractional library routines. 44094 (line 336) 44095* __ashlsa3: Fixed-point fractional library routines. 44096 (line 350) 44097* __ashlsi3: Integer library routines. 44098 (line 13) 44099* __ashlsq3: Fixed-point fractional library routines. 44100 (line 338) 44101* __ashlta3: Fixed-point fractional library routines. 44102 (line 353) 44103* __ashlti3: Integer library routines. 44104 (line 15) 44105* __ashluda3: Fixed-point fractional library routines. 44106 (line 359) 44107* __ashludq3: Fixed-point fractional library routines. 44108 (line 348) 44109* __ashluha3: Fixed-point fractional library routines. 44110 (line 355) 44111* __ashluhq3: Fixed-point fractional library routines. 44112 (line 344) 44113* __ashluqq3: Fixed-point fractional library routines. 44114 (line 342) 44115* __ashlusa3: Fixed-point fractional library routines. 44116 (line 357) 44117* __ashlusq3: Fixed-point fractional library routines. 44118 (line 346) 44119* __ashluta3: Fixed-point fractional library routines. 44120 (line 361) 44121* __ashrda3: Fixed-point fractional library routines. 44122 (line 371) 44123* __ashrdi3: Integer library routines. 44124 (line 19) 44125* __ashrdq3: Fixed-point fractional library routines. 44126 (line 368) 44127* __ashrha3: Fixed-point fractional library routines. 44128 (line 369) 44129* __ashrhq3: Fixed-point fractional library routines. 44130 (line 365) 44131* __ashrqq3: Fixed-point fractional library routines. 44132 (line 364) 44133* __ashrsa3: Fixed-point fractional library routines. 44134 (line 370) 44135* __ashrsi3: Integer library routines. 44136 (line 18) 44137* __ashrsq3: Fixed-point fractional library routines. 44138 (line 366) 44139* __ashrta3: Fixed-point fractional library routines. 44140 (line 373) 44141* __ashrti3: Integer library routines. 44142 (line 20) 44143* __bid_adddd3: Decimal float library routines. 44144 (line 25) 44145* __bid_addsd3: Decimal float library routines. 44146 (line 21) 44147* __bid_addtd3: Decimal float library routines. 44148 (line 29) 44149* __bid_divdd3: Decimal float library routines. 44150 (line 68) 44151* __bid_divsd3: Decimal float library routines. 44152 (line 64) 44153* __bid_divtd3: Decimal float library routines. 44154 (line 72) 44155* __bid_eqdd2: Decimal float library routines. 44156 (line 259) 44157* __bid_eqsd2: Decimal float library routines. 44158 (line 257) 44159* __bid_eqtd2: Decimal float library routines. 44160 (line 261) 44161* __bid_extendddtd2: Decimal float library routines. 44162 (line 92) 44163* __bid_extendddtf: Decimal float library routines. 44164 (line 140) 44165* __bid_extendddxf: Decimal float library routines. 44166 (line 134) 44167* __bid_extenddfdd: Decimal float library routines. 44168 (line 147) 44169* __bid_extenddftd: Decimal float library routines. 44170 (line 107) 44171* __bid_extendsddd2: Decimal float library routines. 44172 (line 88) 44173* __bid_extendsddf: Decimal float library routines. 44174 (line 128) 44175* __bid_extendsdtd2: Decimal float library routines. 44176 (line 90) 44177* __bid_extendsdtf: Decimal float library routines. 44178 (line 138) 44179* __bid_extendsdxf: Decimal float library routines. 44180 (line 132) 44181* __bid_extendsfdd: Decimal float library routines. 44182 (line 103) 44183* __bid_extendsfsd: Decimal float library routines. 44184 (line 145) 44185* __bid_extendsftd: Decimal float library routines. 44186 (line 105) 44187* __bid_extendtftd: Decimal float library routines. 44188 (line 149) 44189* __bid_extendxftd: Decimal float library routines. 44190 (line 109) 44191* __bid_fixdddi: Decimal float library routines. 44192 (line 170) 44193* __bid_fixddsi: Decimal float library routines. 44194 (line 162) 44195* __bid_fixsddi: Decimal float library routines. 44196 (line 168) 44197* __bid_fixsdsi: Decimal float library routines. 44198 (line 160) 44199* __bid_fixtddi: Decimal float library routines. 44200 (line 172) 44201* __bid_fixtdsi: Decimal float library routines. 44202 (line 164) 44203* __bid_fixunsdddi: Decimal float library routines. 44204 (line 187) 44205* __bid_fixunsddsi: Decimal float library routines. 44206 (line 178) 44207* __bid_fixunssddi: Decimal float library routines. 44208 (line 185) 44209* __bid_fixunssdsi: Decimal float library routines. 44210 (line 176) 44211* __bid_fixunstddi: Decimal float library routines. 44212 (line 189) 44213* __bid_fixunstdsi: Decimal float library routines. 44214 (line 180) 44215* __bid_floatdidd: Decimal float library routines. 44216 (line 205) 44217* __bid_floatdisd: Decimal float library routines. 44218 (line 203) 44219* __bid_floatditd: Decimal float library routines. 44220 (line 207) 44221* __bid_floatsidd: Decimal float library routines. 44222 (line 196) 44223* __bid_floatsisd: Decimal float library routines. 44224 (line 194) 44225* __bid_floatsitd: Decimal float library routines. 44226 (line 198) 44227* __bid_floatunsdidd: Decimal float library routines. 44228 (line 223) 44229* __bid_floatunsdisd: Decimal float library routines. 44230 (line 221) 44231* __bid_floatunsditd: Decimal float library routines. 44232 (line 225) 44233* __bid_floatunssidd: Decimal float library routines. 44234 (line 214) 44235* __bid_floatunssisd: Decimal float library routines. 44236 (line 212) 44237* __bid_floatunssitd: Decimal float library routines. 44238 (line 216) 44239* __bid_gedd2: Decimal float library routines. 44240 (line 277) 44241* __bid_gesd2: Decimal float library routines. 44242 (line 275) 44243* __bid_getd2: Decimal float library routines. 44244 (line 279) 44245* __bid_gtdd2: Decimal float library routines. 44246 (line 304) 44247* __bid_gtsd2: Decimal float library routines. 44248 (line 302) 44249* __bid_gttd2: Decimal float library routines. 44250 (line 306) 44251* __bid_ledd2: Decimal float library routines. 44252 (line 295) 44253* __bid_lesd2: Decimal float library routines. 44254 (line 293) 44255* __bid_letd2: Decimal float library routines. 44256 (line 297) 44257* __bid_ltdd2: Decimal float library routines. 44258 (line 286) 44259* __bid_ltsd2: Decimal float library routines. 44260 (line 284) 44261* __bid_lttd2: Decimal float library routines. 44262 (line 288) 44263* __bid_muldd3: Decimal float library routines. 44264 (line 54) 44265* __bid_mulsd3: Decimal float library routines. 44266 (line 50) 44267* __bid_multd3: Decimal float library routines. 44268 (line 58) 44269* __bid_nedd2: Decimal float library routines. 44270 (line 268) 44271* __bid_negdd2: Decimal float library routines. 44272 (line 78) 44273* __bid_negsd2: Decimal float library routines. 44274 (line 76) 44275* __bid_negtd2: Decimal float library routines. 44276 (line 80) 44277* __bid_nesd2: Decimal float library routines. 44278 (line 266) 44279* __bid_netd2: Decimal float library routines. 44280 (line 270) 44281* __bid_subdd3: Decimal float library routines. 44282 (line 39) 44283* __bid_subsd3: Decimal float library routines. 44284 (line 35) 44285* __bid_subtd3: Decimal float library routines. 44286 (line 43) 44287* __bid_truncdddf: Decimal float library routines. 44288 (line 153) 44289* __bid_truncddsd2: Decimal float library routines. 44290 (line 94) 44291* __bid_truncddsf: Decimal float library routines. 44292 (line 124) 44293* __bid_truncdfsd: Decimal float library routines. 44294 (line 111) 44295* __bid_truncsdsf: Decimal float library routines. 44296 (line 151) 44297* __bid_trunctddd2: Decimal float library routines. 44298 (line 98) 44299* __bid_trunctddf: Decimal float library routines. 44300 (line 130) 44301* __bid_trunctdsd2: Decimal float library routines. 44302 (line 96) 44303* __bid_trunctdsf: Decimal float library routines. 44304 (line 126) 44305* __bid_trunctdtf: Decimal float library routines. 44306 (line 155) 44307* __bid_trunctdxf: Decimal float library routines. 44308 (line 136) 44309* __bid_trunctfdd: Decimal float library routines. 44310 (line 119) 44311* __bid_trunctfsd: Decimal float library routines. 44312 (line 115) 44313* __bid_truncxfdd: Decimal float library routines. 44314 (line 117) 44315* __bid_truncxfsd: Decimal float library routines. 44316 (line 113) 44317* __bid_unorddd2: Decimal float library routines. 44318 (line 235) 44319* __bid_unordsd2: Decimal float library routines. 44320 (line 233) 44321* __bid_unordtd2: Decimal float library routines. 44322 (line 237) 44323* __bswapdi2: Integer library routines. 44324 (line 162) 44325* __bswapsi2: Integer library routines. 44326 (line 161) 44327* __builtin_classify_type: Varargs. (line 51) 44328* __builtin_next_arg: Varargs. (line 42) 44329* __builtin_saveregs: Varargs. (line 24) 44330* __chkp_bndcl: Misc. (line 651) 44331* __chkp_bndcu: Misc. (line 657) 44332* __chkp_bndldx: Misc. (line 645) 44333* __chkp_bndmk: Misc. (line 632) 44334* __chkp_bndret: Misc. (line 662) 44335* __chkp_bndstx: Misc. (line 639) 44336* __chkp_intersect: Misc. (line 669) 44337* __chkp_narrow: Misc. (line 674) 44338* __chkp_sizeof: Misc. (line 679) 44339* __clear_cache: Miscellaneous routines. 44340 (line 10) 44341* __clzdi2: Integer library routines. 44342 (line 131) 44343* __clzsi2: Integer library routines. 44344 (line 130) 44345* __clzti2: Integer library routines. 44346 (line 132) 44347* __cmpda2: Fixed-point fractional library routines. 44348 (line 451) 44349* __cmpdf2: Soft float library routines. 44350 (line 164) 44351* __cmpdi2: Integer library routines. 44352 (line 87) 44353* __cmpdq2: Fixed-point fractional library routines. 44354 (line 441) 44355* __cmpha2: Fixed-point fractional library routines. 44356 (line 449) 44357* __cmphq2: Fixed-point fractional library routines. 44358 (line 438) 44359* __cmpqq2: Fixed-point fractional library routines. 44360 (line 437) 44361* __cmpsa2: Fixed-point fractional library routines. 44362 (line 450) 44363* __cmpsf2: Soft float library routines. 44364 (line 163) 44365* __cmpsq2: Fixed-point fractional library routines. 44366 (line 439) 44367* __cmpta2: Fixed-point fractional library routines. 44368 (line 453) 44369* __cmptf2: Soft float library routines. 44370 (line 165) 44371* __cmpti2: Integer library routines. 44372 (line 88) 44373* __cmpuda2: Fixed-point fractional library routines. 44374 (line 458) 44375* __cmpudq2: Fixed-point fractional library routines. 44376 (line 448) 44377* __cmpuha2: Fixed-point fractional library routines. 44378 (line 455) 44379* __cmpuhq2: Fixed-point fractional library routines. 44380 (line 444) 44381* __cmpuqq2: Fixed-point fractional library routines. 44382 (line 443) 44383* __cmpusa2: Fixed-point fractional library routines. 44384 (line 456) 44385* __cmpusq2: Fixed-point fractional library routines. 44386 (line 446) 44387* __cmputa2: Fixed-point fractional library routines. 44388 (line 460) 44389* __CTOR_LIST__: Initialization. (line 25) 44390* __ctzdi2: Integer library routines. 44391 (line 138) 44392* __ctzsi2: Integer library routines. 44393 (line 137) 44394* __ctzti2: Integer library routines. 44395 (line 139) 44396* __divda3: Fixed-point fractional library routines. 44397 (line 227) 44398* __divdc3: Soft float library routines. 44399 (line 252) 44400* __divdf3: Soft float library routines. 44401 (line 48) 44402* __divdi3: Integer library routines. 44403 (line 25) 44404* __divdq3: Fixed-point fractional library routines. 44405 (line 223) 44406* __divha3: Fixed-point fractional library routines. 44407 (line 225) 44408* __divhq3: Fixed-point fractional library routines. 44409 (line 220) 44410* __divqq3: Fixed-point fractional library routines. 44411 (line 219) 44412* __divsa3: Fixed-point fractional library routines. 44413 (line 226) 44414* __divsc3: Soft float library routines. 44415 (line 250) 44416* __divsf3: Soft float library routines. 44417 (line 47) 44418* __divsi3: Integer library routines. 44419 (line 24) 44420* __divsq3: Fixed-point fractional library routines. 44421 (line 221) 44422* __divta3: Fixed-point fractional library routines. 44423 (line 229) 44424* __divtc3: Soft float library routines. 44425 (line 254) 44426* __divtf3: Soft float library routines. 44427 (line 50) 44428* __divti3: Integer library routines. 44429 (line 26) 44430* __divxc3: Soft float library routines. 44431 (line 256) 44432* __divxf3: Soft float library routines. 44433 (line 52) 44434* __dpd_adddd3: Decimal float library routines. 44435 (line 23) 44436* __dpd_addsd3: Decimal float library routines. 44437 (line 19) 44438* __dpd_addtd3: Decimal float library routines. 44439 (line 27) 44440* __dpd_divdd3: Decimal float library routines. 44441 (line 66) 44442* __dpd_divsd3: Decimal float library routines. 44443 (line 62) 44444* __dpd_divtd3: Decimal float library routines. 44445 (line 70) 44446* __dpd_eqdd2: Decimal float library routines. 44447 (line 258) 44448* __dpd_eqsd2: Decimal float library routines. 44449 (line 256) 44450* __dpd_eqtd2: Decimal float library routines. 44451 (line 260) 44452* __dpd_extendddtd2: Decimal float library routines. 44453 (line 91) 44454* __dpd_extendddtf: Decimal float library routines. 44455 (line 139) 44456* __dpd_extendddxf: Decimal float library routines. 44457 (line 133) 44458* __dpd_extenddfdd: Decimal float library routines. 44459 (line 146) 44460* __dpd_extenddftd: Decimal float library routines. 44461 (line 106) 44462* __dpd_extendsddd2: Decimal float library routines. 44463 (line 87) 44464* __dpd_extendsddf: Decimal float library routines. 44465 (line 127) 44466* __dpd_extendsdtd2: Decimal float library routines. 44467 (line 89) 44468* __dpd_extendsdtf: Decimal float library routines. 44469 (line 137) 44470* __dpd_extendsdxf: Decimal float library routines. 44471 (line 131) 44472* __dpd_extendsfdd: Decimal float library routines. 44473 (line 102) 44474* __dpd_extendsfsd: Decimal float library routines. 44475 (line 144) 44476* __dpd_extendsftd: Decimal float library routines. 44477 (line 104) 44478* __dpd_extendtftd: Decimal float library routines. 44479 (line 148) 44480* __dpd_extendxftd: Decimal float library routines. 44481 (line 108) 44482* __dpd_fixdddi: Decimal float library routines. 44483 (line 169) 44484* __dpd_fixddsi: Decimal float library routines. 44485 (line 161) 44486* __dpd_fixsddi: Decimal float library routines. 44487 (line 167) 44488* __dpd_fixsdsi: Decimal float library routines. 44489 (line 159) 44490* __dpd_fixtddi: Decimal float library routines. 44491 (line 171) 44492* __dpd_fixtdsi: Decimal float library routines. 44493 (line 163) 44494* __dpd_fixunsdddi: Decimal float library routines. 44495 (line 186) 44496* __dpd_fixunsddsi: Decimal float library routines. 44497 (line 177) 44498* __dpd_fixunssddi: Decimal float library routines. 44499 (line 184) 44500* __dpd_fixunssdsi: Decimal float library routines. 44501 (line 175) 44502* __dpd_fixunstddi: Decimal float library routines. 44503 (line 188) 44504* __dpd_fixunstdsi: Decimal float library routines. 44505 (line 179) 44506* __dpd_floatdidd: Decimal float library routines. 44507 (line 204) 44508* __dpd_floatdisd: Decimal float library routines. 44509 (line 202) 44510* __dpd_floatditd: Decimal float library routines. 44511 (line 206) 44512* __dpd_floatsidd: Decimal float library routines. 44513 (line 195) 44514* __dpd_floatsisd: Decimal float library routines. 44515 (line 193) 44516* __dpd_floatsitd: Decimal float library routines. 44517 (line 197) 44518* __dpd_floatunsdidd: Decimal float library routines. 44519 (line 222) 44520* __dpd_floatunsdisd: Decimal float library routines. 44521 (line 220) 44522* __dpd_floatunsditd: Decimal float library routines. 44523 (line 224) 44524* __dpd_floatunssidd: Decimal float library routines. 44525 (line 213) 44526* __dpd_floatunssisd: Decimal float library routines. 44527 (line 211) 44528* __dpd_floatunssitd: Decimal float library routines. 44529 (line 215) 44530* __dpd_gedd2: Decimal float library routines. 44531 (line 276) 44532* __dpd_gesd2: Decimal float library routines. 44533 (line 274) 44534* __dpd_getd2: Decimal float library routines. 44535 (line 278) 44536* __dpd_gtdd2: Decimal float library routines. 44537 (line 303) 44538* __dpd_gtsd2: Decimal float library routines. 44539 (line 301) 44540* __dpd_gttd2: Decimal float library routines. 44541 (line 305) 44542* __dpd_ledd2: Decimal float library routines. 44543 (line 294) 44544* __dpd_lesd2: Decimal float library routines. 44545 (line 292) 44546* __dpd_letd2: Decimal float library routines. 44547 (line 296) 44548* __dpd_ltdd2: Decimal float library routines. 44549 (line 285) 44550* __dpd_ltsd2: Decimal float library routines. 44551 (line 283) 44552* __dpd_lttd2: Decimal float library routines. 44553 (line 287) 44554* __dpd_muldd3: Decimal float library routines. 44555 (line 52) 44556* __dpd_mulsd3: Decimal float library routines. 44557 (line 48) 44558* __dpd_multd3: Decimal float library routines. 44559 (line 56) 44560* __dpd_nedd2: Decimal float library routines. 44561 (line 267) 44562* __dpd_negdd2: Decimal float library routines. 44563 (line 77) 44564* __dpd_negsd2: Decimal float library routines. 44565 (line 75) 44566* __dpd_negtd2: Decimal float library routines. 44567 (line 79) 44568* __dpd_nesd2: Decimal float library routines. 44569 (line 265) 44570* __dpd_netd2: Decimal float library routines. 44571 (line 269) 44572* __dpd_subdd3: Decimal float library routines. 44573 (line 37) 44574* __dpd_subsd3: Decimal float library routines. 44575 (line 33) 44576* __dpd_subtd3: Decimal float library routines. 44577 (line 41) 44578* __dpd_truncdddf: Decimal float library routines. 44579 (line 152) 44580* __dpd_truncddsd2: Decimal float library routines. 44581 (line 93) 44582* __dpd_truncddsf: Decimal float library routines. 44583 (line 123) 44584* __dpd_truncdfsd: Decimal float library routines. 44585 (line 110) 44586* __dpd_truncsdsf: Decimal float library routines. 44587 (line 150) 44588* __dpd_trunctddd2: Decimal float library routines. 44589 (line 97) 44590* __dpd_trunctddf: Decimal float library routines. 44591 (line 129) 44592* __dpd_trunctdsd2: Decimal float library routines. 44593 (line 95) 44594* __dpd_trunctdsf: Decimal float library routines. 44595 (line 125) 44596* __dpd_trunctdtf: Decimal float library routines. 44597 (line 154) 44598* __dpd_trunctdxf: Decimal float library routines. 44599 (line 135) 44600* __dpd_trunctfdd: Decimal float library routines. 44601 (line 118) 44602* __dpd_trunctfsd: Decimal float library routines. 44603 (line 114) 44604* __dpd_truncxfdd: Decimal float library routines. 44605 (line 116) 44606* __dpd_truncxfsd: Decimal float library routines. 44607 (line 112) 44608* __dpd_unorddd2: Decimal float library routines. 44609 (line 234) 44610* __dpd_unordsd2: Decimal float library routines. 44611 (line 232) 44612* __dpd_unordtd2: Decimal float library routines. 44613 (line 236) 44614* __DTOR_LIST__: Initialization. (line 25) 44615* __eqdf2: Soft float library routines. 44616 (line 194) 44617* __eqsf2: Soft float library routines. 44618 (line 193) 44619* __eqtf2: Soft float library routines. 44620 (line 195) 44621* __extenddftf2: Soft float library routines. 44622 (line 68) 44623* __extenddfxf2: Soft float library routines. 44624 (line 69) 44625* __extendsfdf2: Soft float library routines. 44626 (line 65) 44627* __extendsftf2: Soft float library routines. 44628 (line 66) 44629* __extendsfxf2: Soft float library routines. 44630 (line 67) 44631* __ffsdi2: Integer library routines. 44632 (line 144) 44633* __ffsti2: Integer library routines. 44634 (line 145) 44635* __fixdfdi: Soft float library routines. 44636 (line 88) 44637* __fixdfsi: Soft float library routines. 44638 (line 81) 44639* __fixdfti: Soft float library routines. 44640 (line 94) 44641* __fixsfdi: Soft float library routines. 44642 (line 87) 44643* __fixsfsi: Soft float library routines. 44644 (line 80) 44645* __fixsfti: Soft float library routines. 44646 (line 93) 44647* __fixtfdi: Soft float library routines. 44648 (line 89) 44649* __fixtfsi: Soft float library routines. 44650 (line 82) 44651* __fixtfti: Soft float library routines. 44652 (line 95) 44653* __fixunsdfdi: Soft float library routines. 44654 (line 108) 44655* __fixunsdfsi: Soft float library routines. 44656 (line 101) 44657* __fixunsdfti: Soft float library routines. 44658 (line 115) 44659* __fixunssfdi: Soft float library routines. 44660 (line 107) 44661* __fixunssfsi: Soft float library routines. 44662 (line 100) 44663* __fixunssfti: Soft float library routines. 44664 (line 114) 44665* __fixunstfdi: Soft float library routines. 44666 (line 109) 44667* __fixunstfsi: Soft float library routines. 44668 (line 102) 44669* __fixunstfti: Soft float library routines. 44670 (line 116) 44671* __fixunsxfdi: Soft float library routines. 44672 (line 110) 44673* __fixunsxfsi: Soft float library routines. 44674 (line 103) 44675* __fixunsxfti: Soft float library routines. 44676 (line 117) 44677* __fixxfdi: Soft float library routines. 44678 (line 90) 44679* __fixxfsi: Soft float library routines. 44680 (line 83) 44681* __fixxfti: Soft float library routines. 44682 (line 96) 44683* __floatdidf: Soft float library routines. 44684 (line 128) 44685* __floatdisf: Soft float library routines. 44686 (line 127) 44687* __floatditf: Soft float library routines. 44688 (line 129) 44689* __floatdixf: Soft float library routines. 44690 (line 130) 44691* __floatsidf: Soft float library routines. 44692 (line 122) 44693* __floatsisf: Soft float library routines. 44694 (line 121) 44695* __floatsitf: Soft float library routines. 44696 (line 123) 44697* __floatsixf: Soft float library routines. 44698 (line 124) 44699* __floattidf: Soft float library routines. 44700 (line 134) 44701* __floattisf: Soft float library routines. 44702 (line 133) 44703* __floattitf: Soft float library routines. 44704 (line 135) 44705* __floattixf: Soft float library routines. 44706 (line 136) 44707* __floatundidf: Soft float library routines. 44708 (line 146) 44709* __floatundisf: Soft float library routines. 44710 (line 145) 44711* __floatunditf: Soft float library routines. 44712 (line 147) 44713* __floatundixf: Soft float library routines. 44714 (line 148) 44715* __floatunsidf: Soft float library routines. 44716 (line 140) 44717* __floatunsisf: Soft float library routines. 44718 (line 139) 44719* __floatunsitf: Soft float library routines. 44720 (line 141) 44721* __floatunsixf: Soft float library routines. 44722 (line 142) 44723* __floatuntidf: Soft float library routines. 44724 (line 152) 44725* __floatuntisf: Soft float library routines. 44726 (line 151) 44727* __floatuntitf: Soft float library routines. 44728 (line 153) 44729* __floatuntixf: Soft float library routines. 44730 (line 154) 44731* __fractdadf: Fixed-point fractional library routines. 44732 (line 636) 44733* __fractdadi: Fixed-point fractional library routines. 44734 (line 633) 44735* __fractdadq: Fixed-point fractional library routines. 44736 (line 616) 44737* __fractdaha2: Fixed-point fractional library routines. 44738 (line 617) 44739* __fractdahi: Fixed-point fractional library routines. 44740 (line 631) 44741* __fractdahq: Fixed-point fractional library routines. 44742 (line 614) 44743* __fractdaqi: Fixed-point fractional library routines. 44744 (line 630) 44745* __fractdaqq: Fixed-point fractional library routines. 44746 (line 613) 44747* __fractdasa2: Fixed-point fractional library routines. 44748 (line 618) 44749* __fractdasf: Fixed-point fractional library routines. 44750 (line 635) 44751* __fractdasi: Fixed-point fractional library routines. 44752 (line 632) 44753* __fractdasq: Fixed-point fractional library routines. 44754 (line 615) 44755* __fractdata2: Fixed-point fractional library routines. 44756 (line 619) 44757* __fractdati: Fixed-point fractional library routines. 44758 (line 634) 44759* __fractdauda: Fixed-point fractional library routines. 44760 (line 627) 44761* __fractdaudq: Fixed-point fractional library routines. 44762 (line 624) 44763* __fractdauha: Fixed-point fractional library routines. 44764 (line 625) 44765* __fractdauhq: Fixed-point fractional library routines. 44766 (line 621) 44767* __fractdauqq: Fixed-point fractional library routines. 44768 (line 620) 44769* __fractdausa: Fixed-point fractional library routines. 44770 (line 626) 44771* __fractdausq: Fixed-point fractional library routines. 44772 (line 622) 44773* __fractdauta: Fixed-point fractional library routines. 44774 (line 629) 44775* __fractdfda: Fixed-point fractional library routines. 44776 (line 1025) 44777* __fractdfdq: Fixed-point fractional library routines. 44778 (line 1022) 44779* __fractdfha: Fixed-point fractional library routines. 44780 (line 1023) 44781* __fractdfhq: Fixed-point fractional library routines. 44782 (line 1020) 44783* __fractdfqq: Fixed-point fractional library routines. 44784 (line 1019) 44785* __fractdfsa: Fixed-point fractional library routines. 44786 (line 1024) 44787* __fractdfsq: Fixed-point fractional library routines. 44788 (line 1021) 44789* __fractdfta: Fixed-point fractional library routines. 44790 (line 1026) 44791* __fractdfuda: Fixed-point fractional library routines. 44792 (line 1033) 44793* __fractdfudq: Fixed-point fractional library routines. 44794 (line 1030) 44795* __fractdfuha: Fixed-point fractional library routines. 44796 (line 1031) 44797* __fractdfuhq: Fixed-point fractional library routines. 44798 (line 1028) 44799* __fractdfuqq: Fixed-point fractional library routines. 44800 (line 1027) 44801* __fractdfusa: Fixed-point fractional library routines. 44802 (line 1032) 44803* __fractdfusq: Fixed-point fractional library routines. 44804 (line 1029) 44805* __fractdfuta: Fixed-point fractional library routines. 44806 (line 1034) 44807* __fractdida: Fixed-point fractional library routines. 44808 (line 975) 44809* __fractdidq: Fixed-point fractional library routines. 44810 (line 972) 44811* __fractdiha: Fixed-point fractional library routines. 44812 (line 973) 44813* __fractdihq: Fixed-point fractional library routines. 44814 (line 970) 44815* __fractdiqq: Fixed-point fractional library routines. 44816 (line 969) 44817* __fractdisa: Fixed-point fractional library routines. 44818 (line 974) 44819* __fractdisq: Fixed-point fractional library routines. 44820 (line 971) 44821* __fractdita: Fixed-point fractional library routines. 44822 (line 976) 44823* __fractdiuda: Fixed-point fractional library routines. 44824 (line 983) 44825* __fractdiudq: Fixed-point fractional library routines. 44826 (line 980) 44827* __fractdiuha: Fixed-point fractional library routines. 44828 (line 981) 44829* __fractdiuhq: Fixed-point fractional library routines. 44830 (line 978) 44831* __fractdiuqq: Fixed-point fractional library routines. 44832 (line 977) 44833* __fractdiusa: Fixed-point fractional library routines. 44834 (line 982) 44835* __fractdiusq: Fixed-point fractional library routines. 44836 (line 979) 44837* __fractdiuta: Fixed-point fractional library routines. 44838 (line 984) 44839* __fractdqda: Fixed-point fractional library routines. 44840 (line 544) 44841* __fractdqdf: Fixed-point fractional library routines. 44842 (line 566) 44843* __fractdqdi: Fixed-point fractional library routines. 44844 (line 563) 44845* __fractdqha: Fixed-point fractional library routines. 44846 (line 542) 44847* __fractdqhi: Fixed-point fractional library routines. 44848 (line 561) 44849* __fractdqhq2: Fixed-point fractional library routines. 44850 (line 540) 44851* __fractdqqi: Fixed-point fractional library routines. 44852 (line 560) 44853* __fractdqqq2: Fixed-point fractional library routines. 44854 (line 539) 44855* __fractdqsa: Fixed-point fractional library routines. 44856 (line 543) 44857* __fractdqsf: Fixed-point fractional library routines. 44858 (line 565) 44859* __fractdqsi: Fixed-point fractional library routines. 44860 (line 562) 44861* __fractdqsq2: Fixed-point fractional library routines. 44862 (line 541) 44863* __fractdqta: Fixed-point fractional library routines. 44864 (line 545) 44865* __fractdqti: Fixed-point fractional library routines. 44866 (line 564) 44867* __fractdquda: Fixed-point fractional library routines. 44868 (line 557) 44869* __fractdqudq: Fixed-point fractional library routines. 44870 (line 552) 44871* __fractdquha: Fixed-point fractional library routines. 44872 (line 554) 44873* __fractdquhq: Fixed-point fractional library routines. 44874 (line 548) 44875* __fractdquqq: Fixed-point fractional library routines. 44876 (line 547) 44877* __fractdqusa: Fixed-point fractional library routines. 44878 (line 555) 44879* __fractdqusq: Fixed-point fractional library routines. 44880 (line 550) 44881* __fractdquta: Fixed-point fractional library routines. 44882 (line 559) 44883* __fracthada2: Fixed-point fractional library routines. 44884 (line 572) 44885* __fracthadf: Fixed-point fractional library routines. 44886 (line 590) 44887* __fracthadi: Fixed-point fractional library routines. 44888 (line 587) 44889* __fracthadq: Fixed-point fractional library routines. 44890 (line 570) 44891* __fracthahi: Fixed-point fractional library routines. 44892 (line 585) 44893* __fracthahq: Fixed-point fractional library routines. 44894 (line 568) 44895* __fracthaqi: Fixed-point fractional library routines. 44896 (line 584) 44897* __fracthaqq: Fixed-point fractional library routines. 44898 (line 567) 44899* __fracthasa2: Fixed-point fractional library routines. 44900 (line 571) 44901* __fracthasf: Fixed-point fractional library routines. 44902 (line 589) 44903* __fracthasi: Fixed-point fractional library routines. 44904 (line 586) 44905* __fracthasq: Fixed-point fractional library routines. 44906 (line 569) 44907* __fracthata2: Fixed-point fractional library routines. 44908 (line 573) 44909* __fracthati: Fixed-point fractional library routines. 44910 (line 588) 44911* __fracthauda: Fixed-point fractional library routines. 44912 (line 581) 44913* __fracthaudq: Fixed-point fractional library routines. 44914 (line 578) 44915* __fracthauha: Fixed-point fractional library routines. 44916 (line 579) 44917* __fracthauhq: Fixed-point fractional library routines. 44918 (line 575) 44919* __fracthauqq: Fixed-point fractional library routines. 44920 (line 574) 44921* __fracthausa: Fixed-point fractional library routines. 44922 (line 580) 44923* __fracthausq: Fixed-point fractional library routines. 44924 (line 576) 44925* __fracthauta: Fixed-point fractional library routines. 44926 (line 583) 44927* __fracthida: Fixed-point fractional library routines. 44928 (line 943) 44929* __fracthidq: Fixed-point fractional library routines. 44930 (line 940) 44931* __fracthiha: Fixed-point fractional library routines. 44932 (line 941) 44933* __fracthihq: Fixed-point fractional library routines. 44934 (line 938) 44935* __fracthiqq: Fixed-point fractional library routines. 44936 (line 937) 44937* __fracthisa: Fixed-point fractional library routines. 44938 (line 942) 44939* __fracthisq: Fixed-point fractional library routines. 44940 (line 939) 44941* __fracthita: Fixed-point fractional library routines. 44942 (line 944) 44943* __fracthiuda: Fixed-point fractional library routines. 44944 (line 951) 44945* __fracthiudq: Fixed-point fractional library routines. 44946 (line 948) 44947* __fracthiuha: Fixed-point fractional library routines. 44948 (line 949) 44949* __fracthiuhq: Fixed-point fractional library routines. 44950 (line 946) 44951* __fracthiuqq: Fixed-point fractional library routines. 44952 (line 945) 44953* __fracthiusa: Fixed-point fractional library routines. 44954 (line 950) 44955* __fracthiusq: Fixed-point fractional library routines. 44956 (line 947) 44957* __fracthiuta: Fixed-point fractional library routines. 44958 (line 952) 44959* __fracthqda: Fixed-point fractional library routines. 44960 (line 498) 44961* __fracthqdf: Fixed-point fractional library routines. 44962 (line 514) 44963* __fracthqdi: Fixed-point fractional library routines. 44964 (line 511) 44965* __fracthqdq2: Fixed-point fractional library routines. 44966 (line 495) 44967* __fracthqha: Fixed-point fractional library routines. 44968 (line 496) 44969* __fracthqhi: Fixed-point fractional library routines. 44970 (line 509) 44971* __fracthqqi: Fixed-point fractional library routines. 44972 (line 508) 44973* __fracthqqq2: Fixed-point fractional library routines. 44974 (line 493) 44975* __fracthqsa: Fixed-point fractional library routines. 44976 (line 497) 44977* __fracthqsf: Fixed-point fractional library routines. 44978 (line 513) 44979* __fracthqsi: Fixed-point fractional library routines. 44980 (line 510) 44981* __fracthqsq2: Fixed-point fractional library routines. 44982 (line 494) 44983* __fracthqta: Fixed-point fractional library routines. 44984 (line 499) 44985* __fracthqti: Fixed-point fractional library routines. 44986 (line 512) 44987* __fracthquda: Fixed-point fractional library routines. 44988 (line 506) 44989* __fracthqudq: Fixed-point fractional library routines. 44990 (line 503) 44991* __fracthquha: Fixed-point fractional library routines. 44992 (line 504) 44993* __fracthquhq: Fixed-point fractional library routines. 44994 (line 501) 44995* __fracthquqq: Fixed-point fractional library routines. 44996 (line 500) 44997* __fracthqusa: Fixed-point fractional library routines. 44998 (line 505) 44999* __fracthqusq: Fixed-point fractional library routines. 45000 (line 502) 45001* __fracthquta: Fixed-point fractional library routines. 45002 (line 507) 45003* __fractqida: Fixed-point fractional library routines. 45004 (line 925) 45005* __fractqidq: Fixed-point fractional library routines. 45006 (line 922) 45007* __fractqiha: Fixed-point fractional library routines. 45008 (line 923) 45009* __fractqihq: Fixed-point fractional library routines. 45010 (line 920) 45011* __fractqiqq: Fixed-point fractional library routines. 45012 (line 919) 45013* __fractqisa: Fixed-point fractional library routines. 45014 (line 924) 45015* __fractqisq: Fixed-point fractional library routines. 45016 (line 921) 45017* __fractqita: Fixed-point fractional library routines. 45018 (line 926) 45019* __fractqiuda: Fixed-point fractional library routines. 45020 (line 934) 45021* __fractqiudq: Fixed-point fractional library routines. 45022 (line 931) 45023* __fractqiuha: Fixed-point fractional library routines. 45024 (line 932) 45025* __fractqiuhq: Fixed-point fractional library routines. 45026 (line 928) 45027* __fractqiuqq: Fixed-point fractional library routines. 45028 (line 927) 45029* __fractqiusa: Fixed-point fractional library routines. 45030 (line 933) 45031* __fractqiusq: Fixed-point fractional library routines. 45032 (line 929) 45033* __fractqiuta: Fixed-point fractional library routines. 45034 (line 936) 45035* __fractqqda: Fixed-point fractional library routines. 45036 (line 474) 45037* __fractqqdf: Fixed-point fractional library routines. 45038 (line 492) 45039* __fractqqdi: Fixed-point fractional library routines. 45040 (line 489) 45041* __fractqqdq2: Fixed-point fractional library routines. 45042 (line 471) 45043* __fractqqha: Fixed-point fractional library routines. 45044 (line 472) 45045* __fractqqhi: Fixed-point fractional library routines. 45046 (line 487) 45047* __fractqqhq2: Fixed-point fractional library routines. 45048 (line 469) 45049* __fractqqqi: Fixed-point fractional library routines. 45050 (line 486) 45051* __fractqqsa: Fixed-point fractional library routines. 45052 (line 473) 45053* __fractqqsf: Fixed-point fractional library routines. 45054 (line 491) 45055* __fractqqsi: Fixed-point fractional library routines. 45056 (line 488) 45057* __fractqqsq2: Fixed-point fractional library routines. 45058 (line 470) 45059* __fractqqta: Fixed-point fractional library routines. 45060 (line 475) 45061* __fractqqti: Fixed-point fractional library routines. 45062 (line 490) 45063* __fractqquda: Fixed-point fractional library routines. 45064 (line 483) 45065* __fractqqudq: Fixed-point fractional library routines. 45066 (line 480) 45067* __fractqquha: Fixed-point fractional library routines. 45068 (line 481) 45069* __fractqquhq: Fixed-point fractional library routines. 45070 (line 477) 45071* __fractqquqq: Fixed-point fractional library routines. 45072 (line 476) 45073* __fractqqusa: Fixed-point fractional library routines. 45074 (line 482) 45075* __fractqqusq: Fixed-point fractional library routines. 45076 (line 478) 45077* __fractqquta: Fixed-point fractional library routines. 45078 (line 485) 45079* __fractsada2: Fixed-point fractional library routines. 45080 (line 596) 45081* __fractsadf: Fixed-point fractional library routines. 45082 (line 612) 45083* __fractsadi: Fixed-point fractional library routines. 45084 (line 609) 45085* __fractsadq: Fixed-point fractional library routines. 45086 (line 594) 45087* __fractsaha2: Fixed-point fractional library routines. 45088 (line 595) 45089* __fractsahi: Fixed-point fractional library routines. 45090 (line 607) 45091* __fractsahq: Fixed-point fractional library routines. 45092 (line 592) 45093* __fractsaqi: Fixed-point fractional library routines. 45094 (line 606) 45095* __fractsaqq: Fixed-point fractional library routines. 45096 (line 591) 45097* __fractsasf: Fixed-point fractional library routines. 45098 (line 611) 45099* __fractsasi: Fixed-point fractional library routines. 45100 (line 608) 45101* __fractsasq: Fixed-point fractional library routines. 45102 (line 593) 45103* __fractsata2: Fixed-point fractional library routines. 45104 (line 597) 45105* __fractsati: Fixed-point fractional library routines. 45106 (line 610) 45107* __fractsauda: Fixed-point fractional library routines. 45108 (line 604) 45109* __fractsaudq: Fixed-point fractional library routines. 45110 (line 601) 45111* __fractsauha: Fixed-point fractional library routines. 45112 (line 602) 45113* __fractsauhq: Fixed-point fractional library routines. 45114 (line 599) 45115* __fractsauqq: Fixed-point fractional library routines. 45116 (line 598) 45117* __fractsausa: Fixed-point fractional library routines. 45118 (line 603) 45119* __fractsausq: Fixed-point fractional library routines. 45120 (line 600) 45121* __fractsauta: Fixed-point fractional library routines. 45122 (line 605) 45123* __fractsfda: Fixed-point fractional library routines. 45124 (line 1009) 45125* __fractsfdq: Fixed-point fractional library routines. 45126 (line 1006) 45127* __fractsfha: Fixed-point fractional library routines. 45128 (line 1007) 45129* __fractsfhq: Fixed-point fractional library routines. 45130 (line 1004) 45131* __fractsfqq: Fixed-point fractional library routines. 45132 (line 1003) 45133* __fractsfsa: Fixed-point fractional library routines. 45134 (line 1008) 45135* __fractsfsq: Fixed-point fractional library routines. 45136 (line 1005) 45137* __fractsfta: Fixed-point fractional library routines. 45138 (line 1010) 45139* __fractsfuda: Fixed-point fractional library routines. 45140 (line 1017) 45141* __fractsfudq: Fixed-point fractional library routines. 45142 (line 1014) 45143* __fractsfuha: Fixed-point fractional library routines. 45144 (line 1015) 45145* __fractsfuhq: Fixed-point fractional library routines. 45146 (line 1012) 45147* __fractsfuqq: Fixed-point fractional library routines. 45148 (line 1011) 45149* __fractsfusa: Fixed-point fractional library routines. 45150 (line 1016) 45151* __fractsfusq: Fixed-point fractional library routines. 45152 (line 1013) 45153* __fractsfuta: Fixed-point fractional library routines. 45154 (line 1018) 45155* __fractsida: Fixed-point fractional library routines. 45156 (line 959) 45157* __fractsidq: Fixed-point fractional library routines. 45158 (line 956) 45159* __fractsiha: Fixed-point fractional library routines. 45160 (line 957) 45161* __fractsihq: Fixed-point fractional library routines. 45162 (line 954) 45163* __fractsiqq: Fixed-point fractional library routines. 45164 (line 953) 45165* __fractsisa: Fixed-point fractional library routines. 45166 (line 958) 45167* __fractsisq: Fixed-point fractional library routines. 45168 (line 955) 45169* __fractsita: Fixed-point fractional library routines. 45170 (line 960) 45171* __fractsiuda: Fixed-point fractional library routines. 45172 (line 967) 45173* __fractsiudq: Fixed-point fractional library routines. 45174 (line 964) 45175* __fractsiuha: Fixed-point fractional library routines. 45176 (line 965) 45177* __fractsiuhq: Fixed-point fractional library routines. 45178 (line 962) 45179* __fractsiuqq: Fixed-point fractional library routines. 45180 (line 961) 45181* __fractsiusa: Fixed-point fractional library routines. 45182 (line 966) 45183* __fractsiusq: Fixed-point fractional library routines. 45184 (line 963) 45185* __fractsiuta: Fixed-point fractional library routines. 45186 (line 968) 45187* __fractsqda: Fixed-point fractional library routines. 45188 (line 520) 45189* __fractsqdf: Fixed-point fractional library routines. 45190 (line 538) 45191* __fractsqdi: Fixed-point fractional library routines. 45192 (line 535) 45193* __fractsqdq2: Fixed-point fractional library routines. 45194 (line 517) 45195* __fractsqha: Fixed-point fractional library routines. 45196 (line 518) 45197* __fractsqhi: Fixed-point fractional library routines. 45198 (line 533) 45199* __fractsqhq2: Fixed-point fractional library routines. 45200 (line 516) 45201* __fractsqqi: Fixed-point fractional library routines. 45202 (line 532) 45203* __fractsqqq2: Fixed-point fractional library routines. 45204 (line 515) 45205* __fractsqsa: Fixed-point fractional library routines. 45206 (line 519) 45207* __fractsqsf: Fixed-point fractional library routines. 45208 (line 537) 45209* __fractsqsi: Fixed-point fractional library routines. 45210 (line 534) 45211* __fractsqta: Fixed-point fractional library routines. 45212 (line 521) 45213* __fractsqti: Fixed-point fractional library routines. 45214 (line 536) 45215* __fractsquda: Fixed-point fractional library routines. 45216 (line 529) 45217* __fractsqudq: Fixed-point fractional library routines. 45218 (line 526) 45219* __fractsquha: Fixed-point fractional library routines. 45220 (line 527) 45221* __fractsquhq: Fixed-point fractional library routines. 45222 (line 523) 45223* __fractsquqq: Fixed-point fractional library routines. 45224 (line 522) 45225* __fractsqusa: Fixed-point fractional library routines. 45226 (line 528) 45227* __fractsqusq: Fixed-point fractional library routines. 45228 (line 524) 45229* __fractsquta: Fixed-point fractional library routines. 45230 (line 531) 45231* __fracttada2: Fixed-point fractional library routines. 45232 (line 643) 45233* __fracttadf: Fixed-point fractional library routines. 45234 (line 664) 45235* __fracttadi: Fixed-point fractional library routines. 45236 (line 661) 45237* __fracttadq: Fixed-point fractional library routines. 45238 (line 640) 45239* __fracttaha2: Fixed-point fractional library routines. 45240 (line 641) 45241* __fracttahi: Fixed-point fractional library routines. 45242 (line 659) 45243* __fracttahq: Fixed-point fractional library routines. 45244 (line 638) 45245* __fracttaqi: Fixed-point fractional library routines. 45246 (line 658) 45247* __fracttaqq: Fixed-point fractional library routines. 45248 (line 637) 45249* __fracttasa2: Fixed-point fractional library routines. 45250 (line 642) 45251* __fracttasf: Fixed-point fractional library routines. 45252 (line 663) 45253* __fracttasi: Fixed-point fractional library routines. 45254 (line 660) 45255* __fracttasq: Fixed-point fractional library routines. 45256 (line 639) 45257* __fracttati: Fixed-point fractional library routines. 45258 (line 662) 45259* __fracttauda: Fixed-point fractional library routines. 45260 (line 655) 45261* __fracttaudq: Fixed-point fractional library routines. 45262 (line 650) 45263* __fracttauha: Fixed-point fractional library routines. 45264 (line 652) 45265* __fracttauhq: Fixed-point fractional library routines. 45266 (line 646) 45267* __fracttauqq: Fixed-point fractional library routines. 45268 (line 645) 45269* __fracttausa: Fixed-point fractional library routines. 45270 (line 653) 45271* __fracttausq: Fixed-point fractional library routines. 45272 (line 648) 45273* __fracttauta: Fixed-point fractional library routines. 45274 (line 657) 45275* __fracttida: Fixed-point fractional library routines. 45276 (line 991) 45277* __fracttidq: Fixed-point fractional library routines. 45278 (line 988) 45279* __fracttiha: Fixed-point fractional library routines. 45280 (line 989) 45281* __fracttihq: Fixed-point fractional library routines. 45282 (line 986) 45283* __fracttiqq: Fixed-point fractional library routines. 45284 (line 985) 45285* __fracttisa: Fixed-point fractional library routines. 45286 (line 990) 45287* __fracttisq: Fixed-point fractional library routines. 45288 (line 987) 45289* __fracttita: Fixed-point fractional library routines. 45290 (line 992) 45291* __fracttiuda: Fixed-point fractional library routines. 45292 (line 1000) 45293* __fracttiudq: Fixed-point fractional library routines. 45294 (line 997) 45295* __fracttiuha: Fixed-point fractional library routines. 45296 (line 998) 45297* __fracttiuhq: Fixed-point fractional library routines. 45298 (line 994) 45299* __fracttiuqq: Fixed-point fractional library routines. 45300 (line 993) 45301* __fracttiusa: Fixed-point fractional library routines. 45302 (line 999) 45303* __fracttiusq: Fixed-point fractional library routines. 45304 (line 995) 45305* __fracttiuta: Fixed-point fractional library routines. 45306 (line 1002) 45307* __fractudada: Fixed-point fractional library routines. 45308 (line 858) 45309* __fractudadf: Fixed-point fractional library routines. 45310 (line 881) 45311* __fractudadi: Fixed-point fractional library routines. 45312 (line 878) 45313* __fractudadq: Fixed-point fractional library routines. 45314 (line 855) 45315* __fractudaha: Fixed-point fractional library routines. 45316 (line 856) 45317* __fractudahi: Fixed-point fractional library routines. 45318 (line 876) 45319* __fractudahq: Fixed-point fractional library routines. 45320 (line 852) 45321* __fractudaqi: Fixed-point fractional library routines. 45322 (line 875) 45323* __fractudaqq: Fixed-point fractional library routines. 45324 (line 851) 45325* __fractudasa: Fixed-point fractional library routines. 45326 (line 857) 45327* __fractudasf: Fixed-point fractional library routines. 45328 (line 880) 45329* __fractudasi: Fixed-point fractional library routines. 45330 (line 877) 45331* __fractudasq: Fixed-point fractional library routines. 45332 (line 853) 45333* __fractudata: Fixed-point fractional library routines. 45334 (line 860) 45335* __fractudati: Fixed-point fractional library routines. 45336 (line 879) 45337* __fractudaudq: Fixed-point fractional library routines. 45338 (line 868) 45339* __fractudauha2: Fixed-point fractional library routines. 45340 (line 870) 45341* __fractudauhq: Fixed-point fractional library routines. 45342 (line 864) 45343* __fractudauqq: Fixed-point fractional library routines. 45344 (line 862) 45345* __fractudausa2: Fixed-point fractional library routines. 45346 (line 872) 45347* __fractudausq: Fixed-point fractional library routines. 45348 (line 866) 45349* __fractudauta2: Fixed-point fractional library routines. 45350 (line 874) 45351* __fractudqda: Fixed-point fractional library routines. 45352 (line 766) 45353* __fractudqdf: Fixed-point fractional library routines. 45354 (line 791) 45355* __fractudqdi: Fixed-point fractional library routines. 45356 (line 787) 45357* __fractudqdq: Fixed-point fractional library routines. 45358 (line 761) 45359* __fractudqha: Fixed-point fractional library routines. 45360 (line 763) 45361* __fractudqhi: Fixed-point fractional library routines. 45362 (line 785) 45363* __fractudqhq: Fixed-point fractional library routines. 45364 (line 757) 45365* __fractudqqi: Fixed-point fractional library routines. 45366 (line 784) 45367* __fractudqqq: Fixed-point fractional library routines. 45368 (line 756) 45369* __fractudqsa: Fixed-point fractional library routines. 45370 (line 764) 45371* __fractudqsf: Fixed-point fractional library routines. 45372 (line 790) 45373* __fractudqsi: Fixed-point fractional library routines. 45374 (line 786) 45375* __fractudqsq: Fixed-point fractional library routines. 45376 (line 759) 45377* __fractudqta: Fixed-point fractional library routines. 45378 (line 768) 45379* __fractudqti: Fixed-point fractional library routines. 45380 (line 789) 45381* __fractudquda: Fixed-point fractional library routines. 45382 (line 780) 45383* __fractudquha: Fixed-point fractional library routines. 45384 (line 776) 45385* __fractudquhq2: Fixed-point fractional library routines. 45386 (line 772) 45387* __fractudquqq2: Fixed-point fractional library routines. 45388 (line 770) 45389* __fractudqusa: Fixed-point fractional library routines. 45390 (line 778) 45391* __fractudqusq2: Fixed-point fractional library routines. 45392 (line 774) 45393* __fractudquta: Fixed-point fractional library routines. 45394 (line 782) 45395* __fractuhada: Fixed-point fractional library routines. 45396 (line 799) 45397* __fractuhadf: Fixed-point fractional library routines. 45398 (line 822) 45399* __fractuhadi: Fixed-point fractional library routines. 45400 (line 819) 45401* __fractuhadq: Fixed-point fractional library routines. 45402 (line 796) 45403* __fractuhaha: Fixed-point fractional library routines. 45404 (line 797) 45405* __fractuhahi: Fixed-point fractional library routines. 45406 (line 817) 45407* __fractuhahq: Fixed-point fractional library routines. 45408 (line 793) 45409* __fractuhaqi: Fixed-point fractional library routines. 45410 (line 816) 45411* __fractuhaqq: Fixed-point fractional library routines. 45412 (line 792) 45413* __fractuhasa: Fixed-point fractional library routines. 45414 (line 798) 45415* __fractuhasf: Fixed-point fractional library routines. 45416 (line 821) 45417* __fractuhasi: Fixed-point fractional library routines. 45418 (line 818) 45419* __fractuhasq: Fixed-point fractional library routines. 45420 (line 794) 45421* __fractuhata: Fixed-point fractional library routines. 45422 (line 801) 45423* __fractuhati: Fixed-point fractional library routines. 45424 (line 820) 45425* __fractuhauda2: Fixed-point fractional library routines. 45426 (line 813) 45427* __fractuhaudq: Fixed-point fractional library routines. 45428 (line 809) 45429* __fractuhauhq: Fixed-point fractional library routines. 45430 (line 805) 45431* __fractuhauqq: Fixed-point fractional library routines. 45432 (line 803) 45433* __fractuhausa2: Fixed-point fractional library routines. 45434 (line 811) 45435* __fractuhausq: Fixed-point fractional library routines. 45436 (line 807) 45437* __fractuhauta2: Fixed-point fractional library routines. 45438 (line 815) 45439* __fractuhqda: Fixed-point fractional library routines. 45440 (line 702) 45441* __fractuhqdf: Fixed-point fractional library routines. 45442 (line 723) 45443* __fractuhqdi: Fixed-point fractional library routines. 45444 (line 720) 45445* __fractuhqdq: Fixed-point fractional library routines. 45446 (line 699) 45447* __fractuhqha: Fixed-point fractional library routines. 45448 (line 700) 45449* __fractuhqhi: Fixed-point fractional library routines. 45450 (line 718) 45451* __fractuhqhq: Fixed-point fractional library routines. 45452 (line 697) 45453* __fractuhqqi: Fixed-point fractional library routines. 45454 (line 717) 45455* __fractuhqqq: Fixed-point fractional library routines. 45456 (line 696) 45457* __fractuhqsa: Fixed-point fractional library routines. 45458 (line 701) 45459* __fractuhqsf: Fixed-point fractional library routines. 45460 (line 722) 45461* __fractuhqsi: Fixed-point fractional library routines. 45462 (line 719) 45463* __fractuhqsq: Fixed-point fractional library routines. 45464 (line 698) 45465* __fractuhqta: Fixed-point fractional library routines. 45466 (line 703) 45467* __fractuhqti: Fixed-point fractional library routines. 45468 (line 721) 45469* __fractuhquda: Fixed-point fractional library routines. 45470 (line 714) 45471* __fractuhqudq2: Fixed-point fractional library routines. 45472 (line 709) 45473* __fractuhquha: Fixed-point fractional library routines. 45474 (line 711) 45475* __fractuhquqq2: Fixed-point fractional library routines. 45476 (line 705) 45477* __fractuhqusa: Fixed-point fractional library routines. 45478 (line 712) 45479* __fractuhqusq2: Fixed-point fractional library routines. 45480 (line 707) 45481* __fractuhquta: Fixed-point fractional library routines. 45482 (line 716) 45483* __fractunsdadi: Fixed-point fractional library routines. 45484 (line 1555) 45485* __fractunsdahi: Fixed-point fractional library routines. 45486 (line 1553) 45487* __fractunsdaqi: Fixed-point fractional library routines. 45488 (line 1552) 45489* __fractunsdasi: Fixed-point fractional library routines. 45490 (line 1554) 45491* __fractunsdati: Fixed-point fractional library routines. 45492 (line 1556) 45493* __fractunsdida: Fixed-point fractional library routines. 45494 (line 1707) 45495* __fractunsdidq: Fixed-point fractional library routines. 45496 (line 1704) 45497* __fractunsdiha: Fixed-point fractional library routines. 45498 (line 1705) 45499* __fractunsdihq: Fixed-point fractional library routines. 45500 (line 1702) 45501* __fractunsdiqq: Fixed-point fractional library routines. 45502 (line 1701) 45503* __fractunsdisa: Fixed-point fractional library routines. 45504 (line 1706) 45505* __fractunsdisq: Fixed-point fractional library routines. 45506 (line 1703) 45507* __fractunsdita: Fixed-point fractional library routines. 45508 (line 1708) 45509* __fractunsdiuda: Fixed-point fractional library routines. 45510 (line 1720) 45511* __fractunsdiudq: Fixed-point fractional library routines. 45512 (line 1715) 45513* __fractunsdiuha: Fixed-point fractional library routines. 45514 (line 1717) 45515* __fractunsdiuhq: Fixed-point fractional library routines. 45516 (line 1711) 45517* __fractunsdiuqq: Fixed-point fractional library routines. 45518 (line 1710) 45519* __fractunsdiusa: Fixed-point fractional library routines. 45520 (line 1718) 45521* __fractunsdiusq: Fixed-point fractional library routines. 45522 (line 1713) 45523* __fractunsdiuta: Fixed-point fractional library routines. 45524 (line 1722) 45525* __fractunsdqdi: Fixed-point fractional library routines. 45526 (line 1539) 45527* __fractunsdqhi: Fixed-point fractional library routines. 45528 (line 1537) 45529* __fractunsdqqi: Fixed-point fractional library routines. 45530 (line 1536) 45531* __fractunsdqsi: Fixed-point fractional library routines. 45532 (line 1538) 45533* __fractunsdqti: Fixed-point fractional library routines. 45534 (line 1541) 45535* __fractunshadi: Fixed-point fractional library routines. 45536 (line 1545) 45537* __fractunshahi: Fixed-point fractional library routines. 45538 (line 1543) 45539* __fractunshaqi: Fixed-point fractional library routines. 45540 (line 1542) 45541* __fractunshasi: Fixed-point fractional library routines. 45542 (line 1544) 45543* __fractunshati: Fixed-point fractional library routines. 45544 (line 1546) 45545* __fractunshida: Fixed-point fractional library routines. 45546 (line 1663) 45547* __fractunshidq: Fixed-point fractional library routines. 45548 (line 1660) 45549* __fractunshiha: Fixed-point fractional library routines. 45550 (line 1661) 45551* __fractunshihq: Fixed-point fractional library routines. 45552 (line 1658) 45553* __fractunshiqq: Fixed-point fractional library routines. 45554 (line 1657) 45555* __fractunshisa: Fixed-point fractional library routines. 45556 (line 1662) 45557* __fractunshisq: Fixed-point fractional library routines. 45558 (line 1659) 45559* __fractunshita: Fixed-point fractional library routines. 45560 (line 1664) 45561* __fractunshiuda: Fixed-point fractional library routines. 45562 (line 1676) 45563* __fractunshiudq: Fixed-point fractional library routines. 45564 (line 1671) 45565* __fractunshiuha: Fixed-point fractional library routines. 45566 (line 1673) 45567* __fractunshiuhq: Fixed-point fractional library routines. 45568 (line 1667) 45569* __fractunshiuqq: Fixed-point fractional library routines. 45570 (line 1666) 45571* __fractunshiusa: Fixed-point fractional library routines. 45572 (line 1674) 45573* __fractunshiusq: Fixed-point fractional library routines. 45574 (line 1669) 45575* __fractunshiuta: Fixed-point fractional library routines. 45576 (line 1678) 45577* __fractunshqdi: Fixed-point fractional library routines. 45578 (line 1529) 45579* __fractunshqhi: Fixed-point fractional library routines. 45580 (line 1527) 45581* __fractunshqqi: Fixed-point fractional library routines. 45582 (line 1526) 45583* __fractunshqsi: Fixed-point fractional library routines. 45584 (line 1528) 45585* __fractunshqti: Fixed-point fractional library routines. 45586 (line 1530) 45587* __fractunsqida: Fixed-point fractional library routines. 45588 (line 1641) 45589* __fractunsqidq: Fixed-point fractional library routines. 45590 (line 1638) 45591* __fractunsqiha: Fixed-point fractional library routines. 45592 (line 1639) 45593* __fractunsqihq: Fixed-point fractional library routines. 45594 (line 1636) 45595* __fractunsqiqq: Fixed-point fractional library routines. 45596 (line 1635) 45597* __fractunsqisa: Fixed-point fractional library routines. 45598 (line 1640) 45599* __fractunsqisq: Fixed-point fractional library routines. 45600 (line 1637) 45601* __fractunsqita: Fixed-point fractional library routines. 45602 (line 1642) 45603* __fractunsqiuda: Fixed-point fractional library routines. 45604 (line 1654) 45605* __fractunsqiudq: Fixed-point fractional library routines. 45606 (line 1649) 45607* __fractunsqiuha: Fixed-point fractional library routines. 45608 (line 1651) 45609* __fractunsqiuhq: Fixed-point fractional library routines. 45610 (line 1645) 45611* __fractunsqiuqq: Fixed-point fractional library routines. 45612 (line 1644) 45613* __fractunsqiusa: Fixed-point fractional library routines. 45614 (line 1652) 45615* __fractunsqiusq: Fixed-point fractional library routines. 45616 (line 1647) 45617* __fractunsqiuta: Fixed-point fractional library routines. 45618 (line 1656) 45619* __fractunsqqdi: Fixed-point fractional library routines. 45620 (line 1524) 45621* __fractunsqqhi: Fixed-point fractional library routines. 45622 (line 1522) 45623* __fractunsqqqi: Fixed-point fractional library routines. 45624 (line 1521) 45625* __fractunsqqsi: Fixed-point fractional library routines. 45626 (line 1523) 45627* __fractunsqqti: Fixed-point fractional library routines. 45628 (line 1525) 45629* __fractunssadi: Fixed-point fractional library routines. 45630 (line 1550) 45631* __fractunssahi: Fixed-point fractional library routines. 45632 (line 1548) 45633* __fractunssaqi: Fixed-point fractional library routines. 45634 (line 1547) 45635* __fractunssasi: Fixed-point fractional library routines. 45636 (line 1549) 45637* __fractunssati: Fixed-point fractional library routines. 45638 (line 1551) 45639* __fractunssida: Fixed-point fractional library routines. 45640 (line 1685) 45641* __fractunssidq: Fixed-point fractional library routines. 45642 (line 1682) 45643* __fractunssiha: Fixed-point fractional library routines. 45644 (line 1683) 45645* __fractunssihq: Fixed-point fractional library routines. 45646 (line 1680) 45647* __fractunssiqq: Fixed-point fractional library routines. 45648 (line 1679) 45649* __fractunssisa: Fixed-point fractional library routines. 45650 (line 1684) 45651* __fractunssisq: Fixed-point fractional library routines. 45652 (line 1681) 45653* __fractunssita: Fixed-point fractional library routines. 45654 (line 1686) 45655* __fractunssiuda: Fixed-point fractional library routines. 45656 (line 1698) 45657* __fractunssiudq: Fixed-point fractional library routines. 45658 (line 1693) 45659* __fractunssiuha: Fixed-point fractional library routines. 45660 (line 1695) 45661* __fractunssiuhq: Fixed-point fractional library routines. 45662 (line 1689) 45663* __fractunssiuqq: Fixed-point fractional library routines. 45664 (line 1688) 45665* __fractunssiusa: Fixed-point fractional library routines. 45666 (line 1696) 45667* __fractunssiusq: Fixed-point fractional library routines. 45668 (line 1691) 45669* __fractunssiuta: Fixed-point fractional library routines. 45670 (line 1700) 45671* __fractunssqdi: Fixed-point fractional library routines. 45672 (line 1534) 45673* __fractunssqhi: Fixed-point fractional library routines. 45674 (line 1532) 45675* __fractunssqqi: Fixed-point fractional library routines. 45676 (line 1531) 45677* __fractunssqsi: Fixed-point fractional library routines. 45678 (line 1533) 45679* __fractunssqti: Fixed-point fractional library routines. 45680 (line 1535) 45681* __fractunstadi: Fixed-point fractional library routines. 45682 (line 1560) 45683* __fractunstahi: Fixed-point fractional library routines. 45684 (line 1558) 45685* __fractunstaqi: Fixed-point fractional library routines. 45686 (line 1557) 45687* __fractunstasi: Fixed-point fractional library routines. 45688 (line 1559) 45689* __fractunstati: Fixed-point fractional library routines. 45690 (line 1562) 45691* __fractunstida: Fixed-point fractional library routines. 45692 (line 1730) 45693* __fractunstidq: Fixed-point fractional library routines. 45694 (line 1727) 45695* __fractunstiha: Fixed-point fractional library routines. 45696 (line 1728) 45697* __fractunstihq: Fixed-point fractional library routines. 45698 (line 1724) 45699* __fractunstiqq: Fixed-point fractional library routines. 45700 (line 1723) 45701* __fractunstisa: Fixed-point fractional library routines. 45702 (line 1729) 45703* __fractunstisq: Fixed-point fractional library routines. 45704 (line 1725) 45705* __fractunstita: Fixed-point fractional library routines. 45706 (line 1732) 45707* __fractunstiuda: Fixed-point fractional library routines. 45708 (line 1746) 45709* __fractunstiudq: Fixed-point fractional library routines. 45710 (line 1740) 45711* __fractunstiuha: Fixed-point fractional library routines. 45712 (line 1742) 45713* __fractunstiuhq: Fixed-point fractional library routines. 45714 (line 1736) 45715* __fractunstiuqq: Fixed-point fractional library routines. 45716 (line 1734) 45717* __fractunstiusa: Fixed-point fractional library routines. 45718 (line 1744) 45719* __fractunstiusq: Fixed-point fractional library routines. 45720 (line 1738) 45721* __fractunstiuta: Fixed-point fractional library routines. 45722 (line 1748) 45723* __fractunsudadi: Fixed-point fractional library routines. 45724 (line 1622) 45725* __fractunsudahi: Fixed-point fractional library routines. 45726 (line 1618) 45727* __fractunsudaqi: Fixed-point fractional library routines. 45728 (line 1616) 45729* __fractunsudasi: Fixed-point fractional library routines. 45730 (line 1620) 45731* __fractunsudati: Fixed-point fractional library routines. 45732 (line 1624) 45733* __fractunsudqdi: Fixed-point fractional library routines. 45734 (line 1596) 45735* __fractunsudqhi: Fixed-point fractional library routines. 45736 (line 1592) 45737* __fractunsudqqi: Fixed-point fractional library routines. 45738 (line 1590) 45739* __fractunsudqsi: Fixed-point fractional library routines. 45740 (line 1594) 45741* __fractunsudqti: Fixed-point fractional library routines. 45742 (line 1598) 45743* __fractunsuhadi: Fixed-point fractional library routines. 45744 (line 1606) 45745* __fractunsuhahi: Fixed-point fractional library routines. 45746 (line 1602) 45747* __fractunsuhaqi: Fixed-point fractional library routines. 45748 (line 1600) 45749* __fractunsuhasi: Fixed-point fractional library routines. 45750 (line 1604) 45751* __fractunsuhati: Fixed-point fractional library routines. 45752 (line 1608) 45753* __fractunsuhqdi: Fixed-point fractional library routines. 45754 (line 1576) 45755* __fractunsuhqhi: Fixed-point fractional library routines. 45756 (line 1574) 45757* __fractunsuhqqi: Fixed-point fractional library routines. 45758 (line 1573) 45759* __fractunsuhqsi: Fixed-point fractional library routines. 45760 (line 1575) 45761* __fractunsuhqti: Fixed-point fractional library routines. 45762 (line 1578) 45763* __fractunsuqqdi: Fixed-point fractional library routines. 45764 (line 1570) 45765* __fractunsuqqhi: Fixed-point fractional library routines. 45766 (line 1566) 45767* __fractunsuqqqi: Fixed-point fractional library routines. 45768 (line 1564) 45769* __fractunsuqqsi: Fixed-point fractional library routines. 45770 (line 1568) 45771* __fractunsuqqti: Fixed-point fractional library routines. 45772 (line 1572) 45773* __fractunsusadi: Fixed-point fractional library routines. 45774 (line 1612) 45775* __fractunsusahi: Fixed-point fractional library routines. 45776 (line 1610) 45777* __fractunsusaqi: Fixed-point fractional library routines. 45778 (line 1609) 45779* __fractunsusasi: Fixed-point fractional library routines. 45780 (line 1611) 45781* __fractunsusati: Fixed-point fractional library routines. 45782 (line 1614) 45783* __fractunsusqdi: Fixed-point fractional library routines. 45784 (line 1586) 45785* __fractunsusqhi: Fixed-point fractional library routines. 45786 (line 1582) 45787* __fractunsusqqi: Fixed-point fractional library routines. 45788 (line 1580) 45789* __fractunsusqsi: Fixed-point fractional library routines. 45790 (line 1584) 45791* __fractunsusqti: Fixed-point fractional library routines. 45792 (line 1588) 45793* __fractunsutadi: Fixed-point fractional library routines. 45794 (line 1632) 45795* __fractunsutahi: Fixed-point fractional library routines. 45796 (line 1628) 45797* __fractunsutaqi: Fixed-point fractional library routines. 45798 (line 1626) 45799* __fractunsutasi: Fixed-point fractional library routines. 45800 (line 1630) 45801* __fractunsutati: Fixed-point fractional library routines. 45802 (line 1634) 45803* __fractuqqda: Fixed-point fractional library routines. 45804 (line 672) 45805* __fractuqqdf: Fixed-point fractional library routines. 45806 (line 695) 45807* __fractuqqdi: Fixed-point fractional library routines. 45808 (line 692) 45809* __fractuqqdq: Fixed-point fractional library routines. 45810 (line 669) 45811* __fractuqqha: Fixed-point fractional library routines. 45812 (line 670) 45813* __fractuqqhi: Fixed-point fractional library routines. 45814 (line 690) 45815* __fractuqqhq: Fixed-point fractional library routines. 45816 (line 666) 45817* __fractuqqqi: Fixed-point fractional library routines. 45818 (line 689) 45819* __fractuqqqq: Fixed-point fractional library routines. 45820 (line 665) 45821* __fractuqqsa: Fixed-point fractional library routines. 45822 (line 671) 45823* __fractuqqsf: Fixed-point fractional library routines. 45824 (line 694) 45825* __fractuqqsi: Fixed-point fractional library routines. 45826 (line 691) 45827* __fractuqqsq: Fixed-point fractional library routines. 45828 (line 667) 45829* __fractuqqta: Fixed-point fractional library routines. 45830 (line 674) 45831* __fractuqqti: Fixed-point fractional library routines. 45832 (line 693) 45833* __fractuqquda: Fixed-point fractional library routines. 45834 (line 686) 45835* __fractuqqudq2: Fixed-point fractional library routines. 45836 (line 680) 45837* __fractuqquha: Fixed-point fractional library routines. 45838 (line 682) 45839* __fractuqquhq2: Fixed-point fractional library routines. 45840 (line 676) 45841* __fractuqqusa: Fixed-point fractional library routines. 45842 (line 684) 45843* __fractuqqusq2: Fixed-point fractional library routines. 45844 (line 678) 45845* __fractuqquta: Fixed-point fractional library routines. 45846 (line 688) 45847* __fractusada: Fixed-point fractional library routines. 45848 (line 829) 45849* __fractusadf: Fixed-point fractional library routines. 45850 (line 850) 45851* __fractusadi: Fixed-point fractional library routines. 45852 (line 847) 45853* __fractusadq: Fixed-point fractional library routines. 45854 (line 826) 45855* __fractusaha: Fixed-point fractional library routines. 45856 (line 827) 45857* __fractusahi: Fixed-point fractional library routines. 45858 (line 845) 45859* __fractusahq: Fixed-point fractional library routines. 45860 (line 824) 45861* __fractusaqi: Fixed-point fractional library routines. 45862 (line 844) 45863* __fractusaqq: Fixed-point fractional library routines. 45864 (line 823) 45865* __fractusasa: Fixed-point fractional library routines. 45866 (line 828) 45867* __fractusasf: Fixed-point fractional library routines. 45868 (line 849) 45869* __fractusasi: Fixed-point fractional library routines. 45870 (line 846) 45871* __fractusasq: Fixed-point fractional library routines. 45872 (line 825) 45873* __fractusata: Fixed-point fractional library routines. 45874 (line 830) 45875* __fractusati: Fixed-point fractional library routines. 45876 (line 848) 45877* __fractusauda2: Fixed-point fractional library routines. 45878 (line 841) 45879* __fractusaudq: Fixed-point fractional library routines. 45880 (line 837) 45881* __fractusauha2: Fixed-point fractional library routines. 45882 (line 839) 45883* __fractusauhq: Fixed-point fractional library routines. 45884 (line 833) 45885* __fractusauqq: Fixed-point fractional library routines. 45886 (line 832) 45887* __fractusausq: Fixed-point fractional library routines. 45888 (line 835) 45889* __fractusauta2: Fixed-point fractional library routines. 45890 (line 843) 45891* __fractusqda: Fixed-point fractional library routines. 45892 (line 731) 45893* __fractusqdf: Fixed-point fractional library routines. 45894 (line 754) 45895* __fractusqdi: Fixed-point fractional library routines. 45896 (line 751) 45897* __fractusqdq: Fixed-point fractional library routines. 45898 (line 728) 45899* __fractusqha: Fixed-point fractional library routines. 45900 (line 729) 45901* __fractusqhi: Fixed-point fractional library routines. 45902 (line 749) 45903* __fractusqhq: Fixed-point fractional library routines. 45904 (line 725) 45905* __fractusqqi: Fixed-point fractional library routines. 45906 (line 748) 45907* __fractusqqq: Fixed-point fractional library routines. 45908 (line 724) 45909* __fractusqsa: Fixed-point fractional library routines. 45910 (line 730) 45911* __fractusqsf: Fixed-point fractional library routines. 45912 (line 753) 45913* __fractusqsi: Fixed-point fractional library routines. 45914 (line 750) 45915* __fractusqsq: Fixed-point fractional library routines. 45916 (line 726) 45917* __fractusqta: Fixed-point fractional library routines. 45918 (line 733) 45919* __fractusqti: Fixed-point fractional library routines. 45920 (line 752) 45921* __fractusquda: Fixed-point fractional library routines. 45922 (line 745) 45923* __fractusqudq2: Fixed-point fractional library routines. 45924 (line 739) 45925* __fractusquha: Fixed-point fractional library routines. 45926 (line 741) 45927* __fractusquhq2: Fixed-point fractional library routines. 45928 (line 737) 45929* __fractusquqq2: Fixed-point fractional library routines. 45930 (line 735) 45931* __fractusqusa: Fixed-point fractional library routines. 45932 (line 743) 45933* __fractusquta: Fixed-point fractional library routines. 45934 (line 747) 45935* __fractutada: Fixed-point fractional library routines. 45936 (line 893) 45937* __fractutadf: Fixed-point fractional library routines. 45938 (line 918) 45939* __fractutadi: Fixed-point fractional library routines. 45940 (line 914) 45941* __fractutadq: Fixed-point fractional library routines. 45942 (line 888) 45943* __fractutaha: Fixed-point fractional library routines. 45944 (line 890) 45945* __fractutahi: Fixed-point fractional library routines. 45946 (line 912) 45947* __fractutahq: Fixed-point fractional library routines. 45948 (line 884) 45949* __fractutaqi: Fixed-point fractional library routines. 45950 (line 911) 45951* __fractutaqq: Fixed-point fractional library routines. 45952 (line 883) 45953* __fractutasa: Fixed-point fractional library routines. 45954 (line 891) 45955* __fractutasf: Fixed-point fractional library routines. 45956 (line 917) 45957* __fractutasi: Fixed-point fractional library routines. 45958 (line 913) 45959* __fractutasq: Fixed-point fractional library routines. 45960 (line 886) 45961* __fractutata: Fixed-point fractional library routines. 45962 (line 895) 45963* __fractutati: Fixed-point fractional library routines. 45964 (line 916) 45965* __fractutauda2: Fixed-point fractional library routines. 45966 (line 909) 45967* __fractutaudq: Fixed-point fractional library routines. 45968 (line 903) 45969* __fractutauha2: Fixed-point fractional library routines. 45970 (line 905) 45971* __fractutauhq: Fixed-point fractional library routines. 45972 (line 899) 45973* __fractutauqq: Fixed-point fractional library routines. 45974 (line 897) 45975* __fractutausa2: Fixed-point fractional library routines. 45976 (line 907) 45977* __fractutausq: Fixed-point fractional library routines. 45978 (line 901) 45979* __gedf2: Soft float library routines. 45980 (line 206) 45981* __gesf2: Soft float library routines. 45982 (line 205) 45983* __getf2: Soft float library routines. 45984 (line 207) 45985* __gtdf2: Soft float library routines. 45986 (line 224) 45987* __gtsf2: Soft float library routines. 45988 (line 223) 45989* __gttf2: Soft float library routines. 45990 (line 225) 45991* __ledf2: Soft float library routines. 45992 (line 218) 45993* __lesf2: Soft float library routines. 45994 (line 217) 45995* __letf2: Soft float library routines. 45996 (line 219) 45997* __lshrdi3: Integer library routines. 45998 (line 31) 45999* __lshrsi3: Integer library routines. 46000 (line 30) 46001* __lshrti3: Integer library routines. 46002 (line 32) 46003* __lshruda3: Fixed-point fractional library routines. 46004 (line 390) 46005* __lshrudq3: Fixed-point fractional library routines. 46006 (line 384) 46007* __lshruha3: Fixed-point fractional library routines. 46008 (line 386) 46009* __lshruhq3: Fixed-point fractional library routines. 46010 (line 380) 46011* __lshruqq3: Fixed-point fractional library routines. 46012 (line 378) 46013* __lshrusa3: Fixed-point fractional library routines. 46014 (line 388) 46015* __lshrusq3: Fixed-point fractional library routines. 46016 (line 382) 46017* __lshruta3: Fixed-point fractional library routines. 46018 (line 392) 46019* __ltdf2: Soft float library routines. 46020 (line 212) 46021* __ltsf2: Soft float library routines. 46022 (line 211) 46023* __lttf2: Soft float library routines. 46024 (line 213) 46025* __main: Collect2. (line 15) 46026* __moddi3: Integer library routines. 46027 (line 37) 46028* __modsi3: Integer library routines. 46029 (line 36) 46030* __modti3: Integer library routines. 46031 (line 38) 46032* __morestack_current_segment: Miscellaneous routines. 46033 (line 46) 46034* __morestack_initial_sp: Miscellaneous routines. 46035 (line 47) 46036* __morestack_segments: Miscellaneous routines. 46037 (line 45) 46038* __mulda3: Fixed-point fractional library routines. 46039 (line 171) 46040* __muldc3: Soft float library routines. 46041 (line 241) 46042* __muldf3: Soft float library routines. 46043 (line 40) 46044* __muldi3: Integer library routines. 46045 (line 43) 46046* __muldq3: Fixed-point fractional library routines. 46047 (line 159) 46048* __mulha3: Fixed-point fractional library routines. 46049 (line 169) 46050* __mulhq3: Fixed-point fractional library routines. 46051 (line 156) 46052* __mulqq3: Fixed-point fractional library routines. 46053 (line 155) 46054* __mulsa3: Fixed-point fractional library routines. 46055 (line 170) 46056* __mulsc3: Soft float library routines. 46057 (line 239) 46058* __mulsf3: Soft float library routines. 46059 (line 39) 46060* __mulsi3: Integer library routines. 46061 (line 42) 46062* __mulsq3: Fixed-point fractional library routines. 46063 (line 157) 46064* __multa3: Fixed-point fractional library routines. 46065 (line 173) 46066* __multc3: Soft float library routines. 46067 (line 243) 46068* __multf3: Soft float library routines. 46069 (line 42) 46070* __multi3: Integer library routines. 46071 (line 44) 46072* __muluda3: Fixed-point fractional library routines. 46073 (line 179) 46074* __muludq3: Fixed-point fractional library routines. 46075 (line 167) 46076* __muluha3: Fixed-point fractional library routines. 46077 (line 175) 46078* __muluhq3: Fixed-point fractional library routines. 46079 (line 163) 46080* __muluqq3: Fixed-point fractional library routines. 46081 (line 161) 46082* __mulusa3: Fixed-point fractional library routines. 46083 (line 177) 46084* __mulusq3: Fixed-point fractional library routines. 46085 (line 165) 46086* __muluta3: Fixed-point fractional library routines. 46087 (line 181) 46088* __mulvdi3: Integer library routines. 46089 (line 115) 46090* __mulvsi3: Integer library routines. 46091 (line 114) 46092* __mulxc3: Soft float library routines. 46093 (line 245) 46094* __mulxf3: Soft float library routines. 46095 (line 44) 46096* __nedf2: Soft float library routines. 46097 (line 200) 46098* __negda2: Fixed-point fractional library routines. 46099 (line 299) 46100* __negdf2: Soft float library routines. 46101 (line 56) 46102* __negdi2: Integer library routines. 46103 (line 47) 46104* __negdq2: Fixed-point fractional library routines. 46105 (line 289) 46106* __negha2: Fixed-point fractional library routines. 46107 (line 297) 46108* __neghq2: Fixed-point fractional library routines. 46109 (line 287) 46110* __negqq2: Fixed-point fractional library routines. 46111 (line 286) 46112* __negsa2: Fixed-point fractional library routines. 46113 (line 298) 46114* __negsf2: Soft float library routines. 46115 (line 55) 46116* __negsq2: Fixed-point fractional library routines. 46117 (line 288) 46118* __negta2: Fixed-point fractional library routines. 46119 (line 300) 46120* __negtf2: Soft float library routines. 46121 (line 57) 46122* __negti2: Integer library routines. 46123 (line 48) 46124* __neguda2: Fixed-point fractional library routines. 46125 (line 305) 46126* __negudq2: Fixed-point fractional library routines. 46127 (line 296) 46128* __neguha2: Fixed-point fractional library routines. 46129 (line 302) 46130* __neguhq2: Fixed-point fractional library routines. 46131 (line 292) 46132* __neguqq2: Fixed-point fractional library routines. 46133 (line 291) 46134* __negusa2: Fixed-point fractional library routines. 46135 (line 303) 46136* __negusq2: Fixed-point fractional library routines. 46137 (line 294) 46138* __neguta2: Fixed-point fractional library routines. 46139 (line 307) 46140* __negvdi2: Integer library routines. 46141 (line 119) 46142* __negvsi2: Integer library routines. 46143 (line 118) 46144* __negxf2: Soft float library routines. 46145 (line 58) 46146* __nesf2: Soft float library routines. 46147 (line 199) 46148* __netf2: Soft float library routines. 46149 (line 201) 46150* __paritydi2: Integer library routines. 46151 (line 151) 46152* __paritysi2: Integer library routines. 46153 (line 150) 46154* __parityti2: Integer library routines. 46155 (line 152) 46156* __popcountdi2: Integer library routines. 46157 (line 157) 46158* __popcountsi2: Integer library routines. 46159 (line 156) 46160* __popcountti2: Integer library routines. 46161 (line 158) 46162* __powidf2: Soft float library routines. 46163 (line 233) 46164* __powisf2: Soft float library routines. 46165 (line 232) 46166* __powitf2: Soft float library routines. 46167 (line 234) 46168* __powixf2: Soft float library routines. 46169 (line 235) 46170* __satfractdadq: Fixed-point fractional library routines. 46171 (line 1153) 46172* __satfractdaha2: Fixed-point fractional library routines. 46173 (line 1154) 46174* __satfractdahq: Fixed-point fractional library routines. 46175 (line 1151) 46176* __satfractdaqq: Fixed-point fractional library routines. 46177 (line 1150) 46178* __satfractdasa2: Fixed-point fractional library routines. 46179 (line 1155) 46180* __satfractdasq: Fixed-point fractional library routines. 46181 (line 1152) 46182* __satfractdata2: Fixed-point fractional library routines. 46183 (line 1156) 46184* __satfractdauda: Fixed-point fractional library routines. 46185 (line 1166) 46186* __satfractdaudq: Fixed-point fractional library routines. 46187 (line 1162) 46188* __satfractdauha: Fixed-point fractional library routines. 46189 (line 1164) 46190* __satfractdauhq: Fixed-point fractional library routines. 46191 (line 1159) 46192* __satfractdauqq: Fixed-point fractional library routines. 46193 (line 1158) 46194* __satfractdausa: Fixed-point fractional library routines. 46195 (line 1165) 46196* __satfractdausq: Fixed-point fractional library routines. 46197 (line 1160) 46198* __satfractdauta: Fixed-point fractional library routines. 46199 (line 1168) 46200* __satfractdfda: Fixed-point fractional library routines. 46201 (line 1506) 46202* __satfractdfdq: Fixed-point fractional library routines. 46203 (line 1503) 46204* __satfractdfha: Fixed-point fractional library routines. 46205 (line 1504) 46206* __satfractdfhq: Fixed-point fractional library routines. 46207 (line 1501) 46208* __satfractdfqq: Fixed-point fractional library routines. 46209 (line 1500) 46210* __satfractdfsa: Fixed-point fractional library routines. 46211 (line 1505) 46212* __satfractdfsq: Fixed-point fractional library routines. 46213 (line 1502) 46214* __satfractdfta: Fixed-point fractional library routines. 46215 (line 1507) 46216* __satfractdfuda: Fixed-point fractional library routines. 46217 (line 1515) 46218* __satfractdfudq: Fixed-point fractional library routines. 46219 (line 1512) 46220* __satfractdfuha: Fixed-point fractional library routines. 46221 (line 1513) 46222* __satfractdfuhq: Fixed-point fractional library routines. 46223 (line 1509) 46224* __satfractdfuqq: Fixed-point fractional library routines. 46225 (line 1508) 46226* __satfractdfusa: Fixed-point fractional library routines. 46227 (line 1514) 46228* __satfractdfusq: Fixed-point fractional library routines. 46229 (line 1510) 46230* __satfractdfuta: Fixed-point fractional library routines. 46231 (line 1517) 46232* __satfractdida: Fixed-point fractional library routines. 46233 (line 1456) 46234* __satfractdidq: Fixed-point fractional library routines. 46235 (line 1453) 46236* __satfractdiha: Fixed-point fractional library routines. 46237 (line 1454) 46238* __satfractdihq: Fixed-point fractional library routines. 46239 (line 1451) 46240* __satfractdiqq: Fixed-point fractional library routines. 46241 (line 1450) 46242* __satfractdisa: Fixed-point fractional library routines. 46243 (line 1455) 46244* __satfractdisq: Fixed-point fractional library routines. 46245 (line 1452) 46246* __satfractdita: Fixed-point fractional library routines. 46247 (line 1457) 46248* __satfractdiuda: Fixed-point fractional library routines. 46249 (line 1464) 46250* __satfractdiudq: Fixed-point fractional library routines. 46251 (line 1461) 46252* __satfractdiuha: Fixed-point fractional library routines. 46253 (line 1462) 46254* __satfractdiuhq: Fixed-point fractional library routines. 46255 (line 1459) 46256* __satfractdiuqq: Fixed-point fractional library routines. 46257 (line 1458) 46258* __satfractdiusa: Fixed-point fractional library routines. 46259 (line 1463) 46260* __satfractdiusq: Fixed-point fractional library routines. 46261 (line 1460) 46262* __satfractdiuta: Fixed-point fractional library routines. 46263 (line 1465) 46264* __satfractdqda: Fixed-point fractional library routines. 46265 (line 1098) 46266* __satfractdqha: Fixed-point fractional library routines. 46267 (line 1096) 46268* __satfractdqhq2: Fixed-point fractional library routines. 46269 (line 1094) 46270* __satfractdqqq2: Fixed-point fractional library routines. 46271 (line 1093) 46272* __satfractdqsa: Fixed-point fractional library routines. 46273 (line 1097) 46274* __satfractdqsq2: Fixed-point fractional library routines. 46275 (line 1095) 46276* __satfractdqta: Fixed-point fractional library routines. 46277 (line 1099) 46278* __satfractdquda: Fixed-point fractional library routines. 46279 (line 1111) 46280* __satfractdqudq: Fixed-point fractional library routines. 46281 (line 1106) 46282* __satfractdquha: Fixed-point fractional library routines. 46283 (line 1108) 46284* __satfractdquhq: Fixed-point fractional library routines. 46285 (line 1102) 46286* __satfractdquqq: Fixed-point fractional library routines. 46287 (line 1101) 46288* __satfractdqusa: Fixed-point fractional library routines. 46289 (line 1109) 46290* __satfractdqusq: Fixed-point fractional library routines. 46291 (line 1104) 46292* __satfractdquta: Fixed-point fractional library routines. 46293 (line 1113) 46294* __satfracthada2: Fixed-point fractional library routines. 46295 (line 1119) 46296* __satfracthadq: Fixed-point fractional library routines. 46297 (line 1117) 46298* __satfracthahq: Fixed-point fractional library routines. 46299 (line 1115) 46300* __satfracthaqq: Fixed-point fractional library routines. 46301 (line 1114) 46302* __satfracthasa2: Fixed-point fractional library routines. 46303 (line 1118) 46304* __satfracthasq: Fixed-point fractional library routines. 46305 (line 1116) 46306* __satfracthata2: Fixed-point fractional library routines. 46307 (line 1120) 46308* __satfracthauda: Fixed-point fractional library routines. 46309 (line 1132) 46310* __satfracthaudq: Fixed-point fractional library routines. 46311 (line 1127) 46312* __satfracthauha: Fixed-point fractional library routines. 46313 (line 1129) 46314* __satfracthauhq: Fixed-point fractional library routines. 46315 (line 1123) 46316* __satfracthauqq: Fixed-point fractional library routines. 46317 (line 1122) 46318* __satfracthausa: Fixed-point fractional library routines. 46319 (line 1130) 46320* __satfracthausq: Fixed-point fractional library routines. 46321 (line 1125) 46322* __satfracthauta: Fixed-point fractional library routines. 46323 (line 1134) 46324* __satfracthida: Fixed-point fractional library routines. 46325 (line 1424) 46326* __satfracthidq: Fixed-point fractional library routines. 46327 (line 1421) 46328* __satfracthiha: Fixed-point fractional library routines. 46329 (line 1422) 46330* __satfracthihq: Fixed-point fractional library routines. 46331 (line 1419) 46332* __satfracthiqq: Fixed-point fractional library routines. 46333 (line 1418) 46334* __satfracthisa: Fixed-point fractional library routines. 46335 (line 1423) 46336* __satfracthisq: Fixed-point fractional library routines. 46337 (line 1420) 46338* __satfracthita: Fixed-point fractional library routines. 46339 (line 1425) 46340* __satfracthiuda: Fixed-point fractional library routines. 46341 (line 1432) 46342* __satfracthiudq: Fixed-point fractional library routines. 46343 (line 1429) 46344* __satfracthiuha: Fixed-point fractional library routines. 46345 (line 1430) 46346* __satfracthiuhq: Fixed-point fractional library routines. 46347 (line 1427) 46348* __satfracthiuqq: Fixed-point fractional library routines. 46349 (line 1426) 46350* __satfracthiusa: Fixed-point fractional library routines. 46351 (line 1431) 46352* __satfracthiusq: Fixed-point fractional library routines. 46353 (line 1428) 46354* __satfracthiuta: Fixed-point fractional library routines. 46355 (line 1433) 46356* __satfracthqda: Fixed-point fractional library routines. 46357 (line 1064) 46358* __satfracthqdq2: Fixed-point fractional library routines. 46359 (line 1061) 46360* __satfracthqha: Fixed-point fractional library routines. 46361 (line 1062) 46362* __satfracthqqq2: Fixed-point fractional library routines. 46363 (line 1059) 46364* __satfracthqsa: Fixed-point fractional library routines. 46365 (line 1063) 46366* __satfracthqsq2: Fixed-point fractional library routines. 46367 (line 1060) 46368* __satfracthqta: Fixed-point fractional library routines. 46369 (line 1065) 46370* __satfracthquda: Fixed-point fractional library routines. 46371 (line 1072) 46372* __satfracthqudq: Fixed-point fractional library routines. 46373 (line 1069) 46374* __satfracthquha: Fixed-point fractional library routines. 46375 (line 1070) 46376* __satfracthquhq: Fixed-point fractional library routines. 46377 (line 1067) 46378* __satfracthquqq: Fixed-point fractional library routines. 46379 (line 1066) 46380* __satfracthqusa: Fixed-point fractional library routines. 46381 (line 1071) 46382* __satfracthqusq: Fixed-point fractional library routines. 46383 (line 1068) 46384* __satfracthquta: Fixed-point fractional library routines. 46385 (line 1073) 46386* __satfractqida: Fixed-point fractional library routines. 46387 (line 1402) 46388* __satfractqidq: Fixed-point fractional library routines. 46389 (line 1399) 46390* __satfractqiha: Fixed-point fractional library routines. 46391 (line 1400) 46392* __satfractqihq: Fixed-point fractional library routines. 46393 (line 1397) 46394* __satfractqiqq: Fixed-point fractional library routines. 46395 (line 1396) 46396* __satfractqisa: Fixed-point fractional library routines. 46397 (line 1401) 46398* __satfractqisq: Fixed-point fractional library routines. 46399 (line 1398) 46400* __satfractqita: Fixed-point fractional library routines. 46401 (line 1403) 46402* __satfractqiuda: Fixed-point fractional library routines. 46403 (line 1415) 46404* __satfractqiudq: Fixed-point fractional library routines. 46405 (line 1410) 46406* __satfractqiuha: Fixed-point fractional library routines. 46407 (line 1412) 46408* __satfractqiuhq: Fixed-point fractional library routines. 46409 (line 1406) 46410* __satfractqiuqq: Fixed-point fractional library routines. 46411 (line 1405) 46412* __satfractqiusa: Fixed-point fractional library routines. 46413 (line 1413) 46414* __satfractqiusq: Fixed-point fractional library routines. 46415 (line 1408) 46416* __satfractqiuta: Fixed-point fractional library routines. 46417 (line 1417) 46418* __satfractqqda: Fixed-point fractional library routines. 46419 (line 1043) 46420* __satfractqqdq2: Fixed-point fractional library routines. 46421 (line 1040) 46422* __satfractqqha: Fixed-point fractional library routines. 46423 (line 1041) 46424* __satfractqqhq2: Fixed-point fractional library routines. 46425 (line 1038) 46426* __satfractqqsa: Fixed-point fractional library routines. 46427 (line 1042) 46428* __satfractqqsq2: Fixed-point fractional library routines. 46429 (line 1039) 46430* __satfractqqta: Fixed-point fractional library routines. 46431 (line 1044) 46432* __satfractqquda: Fixed-point fractional library routines. 46433 (line 1056) 46434* __satfractqqudq: Fixed-point fractional library routines. 46435 (line 1051) 46436* __satfractqquha: Fixed-point fractional library routines. 46437 (line 1053) 46438* __satfractqquhq: Fixed-point fractional library routines. 46439 (line 1047) 46440* __satfractqquqq: Fixed-point fractional library routines. 46441 (line 1046) 46442* __satfractqqusa: Fixed-point fractional library routines. 46443 (line 1054) 46444* __satfractqqusq: Fixed-point fractional library routines. 46445 (line 1049) 46446* __satfractqquta: Fixed-point fractional library routines. 46447 (line 1058) 46448* __satfractsada2: Fixed-point fractional library routines. 46449 (line 1140) 46450* __satfractsadq: Fixed-point fractional library routines. 46451 (line 1138) 46452* __satfractsaha2: Fixed-point fractional library routines. 46453 (line 1139) 46454* __satfractsahq: Fixed-point fractional library routines. 46455 (line 1136) 46456* __satfractsaqq: Fixed-point fractional library routines. 46457 (line 1135) 46458* __satfractsasq: Fixed-point fractional library routines. 46459 (line 1137) 46460* __satfractsata2: Fixed-point fractional library routines. 46461 (line 1141) 46462* __satfractsauda: Fixed-point fractional library routines. 46463 (line 1148) 46464* __satfractsaudq: Fixed-point fractional library routines. 46465 (line 1145) 46466* __satfractsauha: Fixed-point fractional library routines. 46467 (line 1146) 46468* __satfractsauhq: Fixed-point fractional library routines. 46469 (line 1143) 46470* __satfractsauqq: Fixed-point fractional library routines. 46471 (line 1142) 46472* __satfractsausa: Fixed-point fractional library routines. 46473 (line 1147) 46474* __satfractsausq: Fixed-point fractional library routines. 46475 (line 1144) 46476* __satfractsauta: Fixed-point fractional library routines. 46477 (line 1149) 46478* __satfractsfda: Fixed-point fractional library routines. 46479 (line 1490) 46480* __satfractsfdq: Fixed-point fractional library routines. 46481 (line 1487) 46482* __satfractsfha: Fixed-point fractional library routines. 46483 (line 1488) 46484* __satfractsfhq: Fixed-point fractional library routines. 46485 (line 1485) 46486* __satfractsfqq: Fixed-point fractional library routines. 46487 (line 1484) 46488* __satfractsfsa: Fixed-point fractional library routines. 46489 (line 1489) 46490* __satfractsfsq: Fixed-point fractional library routines. 46491 (line 1486) 46492* __satfractsfta: Fixed-point fractional library routines. 46493 (line 1491) 46494* __satfractsfuda: Fixed-point fractional library routines. 46495 (line 1498) 46496* __satfractsfudq: Fixed-point fractional library routines. 46497 (line 1495) 46498* __satfractsfuha: Fixed-point fractional library routines. 46499 (line 1496) 46500* __satfractsfuhq: Fixed-point fractional library routines. 46501 (line 1493) 46502* __satfractsfuqq: Fixed-point fractional library routines. 46503 (line 1492) 46504* __satfractsfusa: Fixed-point fractional library routines. 46505 (line 1497) 46506* __satfractsfusq: Fixed-point fractional library routines. 46507 (line 1494) 46508* __satfractsfuta: Fixed-point fractional library routines. 46509 (line 1499) 46510* __satfractsida: Fixed-point fractional library routines. 46511 (line 1440) 46512* __satfractsidq: Fixed-point fractional library routines. 46513 (line 1437) 46514* __satfractsiha: Fixed-point fractional library routines. 46515 (line 1438) 46516* __satfractsihq: Fixed-point fractional library routines. 46517 (line 1435) 46518* __satfractsiqq: Fixed-point fractional library routines. 46519 (line 1434) 46520* __satfractsisa: Fixed-point fractional library routines. 46521 (line 1439) 46522* __satfractsisq: Fixed-point fractional library routines. 46523 (line 1436) 46524* __satfractsita: Fixed-point fractional library routines. 46525 (line 1441) 46526* __satfractsiuda: Fixed-point fractional library routines. 46527 (line 1448) 46528* __satfractsiudq: Fixed-point fractional library routines. 46529 (line 1445) 46530* __satfractsiuha: Fixed-point fractional library routines. 46531 (line 1446) 46532* __satfractsiuhq: Fixed-point fractional library routines. 46533 (line 1443) 46534* __satfractsiuqq: Fixed-point fractional library routines. 46535 (line 1442) 46536* __satfractsiusa: Fixed-point fractional library routines. 46537 (line 1447) 46538* __satfractsiusq: Fixed-point fractional library routines. 46539 (line 1444) 46540* __satfractsiuta: Fixed-point fractional library routines. 46541 (line 1449) 46542* __satfractsqda: Fixed-point fractional library routines. 46543 (line 1079) 46544* __satfractsqdq2: Fixed-point fractional library routines. 46545 (line 1076) 46546* __satfractsqha: Fixed-point fractional library routines. 46547 (line 1077) 46548* __satfractsqhq2: Fixed-point fractional library routines. 46549 (line 1075) 46550* __satfractsqqq2: Fixed-point fractional library routines. 46551 (line 1074) 46552* __satfractsqsa: Fixed-point fractional library routines. 46553 (line 1078) 46554* __satfractsqta: Fixed-point fractional library routines. 46555 (line 1080) 46556* __satfractsquda: Fixed-point fractional library routines. 46557 (line 1090) 46558* __satfractsqudq: Fixed-point fractional library routines. 46559 (line 1086) 46560* __satfractsquha: Fixed-point fractional library routines. 46561 (line 1088) 46562* __satfractsquhq: Fixed-point fractional library routines. 46563 (line 1083) 46564* __satfractsquqq: Fixed-point fractional library routines. 46565 (line 1082) 46566* __satfractsqusa: Fixed-point fractional library routines. 46567 (line 1089) 46568* __satfractsqusq: Fixed-point fractional library routines. 46569 (line 1084) 46570* __satfractsquta: Fixed-point fractional library routines. 46571 (line 1092) 46572* __satfracttada2: Fixed-point fractional library routines. 46573 (line 1175) 46574* __satfracttadq: Fixed-point fractional library routines. 46575 (line 1172) 46576* __satfracttaha2: Fixed-point fractional library routines. 46577 (line 1173) 46578* __satfracttahq: Fixed-point fractional library routines. 46579 (line 1170) 46580* __satfracttaqq: Fixed-point fractional library routines. 46581 (line 1169) 46582* __satfracttasa2: Fixed-point fractional library routines. 46583 (line 1174) 46584* __satfracttasq: Fixed-point fractional library routines. 46585 (line 1171) 46586* __satfracttauda: Fixed-point fractional library routines. 46587 (line 1187) 46588* __satfracttaudq: Fixed-point fractional library routines. 46589 (line 1182) 46590* __satfracttauha: Fixed-point fractional library routines. 46591 (line 1184) 46592* __satfracttauhq: Fixed-point fractional library routines. 46593 (line 1178) 46594* __satfracttauqq: Fixed-point fractional library routines. 46595 (line 1177) 46596* __satfracttausa: Fixed-point fractional library routines. 46597 (line 1185) 46598* __satfracttausq: Fixed-point fractional library routines. 46599 (line 1180) 46600* __satfracttauta: Fixed-point fractional library routines. 46601 (line 1189) 46602* __satfracttida: Fixed-point fractional library routines. 46603 (line 1472) 46604* __satfracttidq: Fixed-point fractional library routines. 46605 (line 1469) 46606* __satfracttiha: Fixed-point fractional library routines. 46607 (line 1470) 46608* __satfracttihq: Fixed-point fractional library routines. 46609 (line 1467) 46610* __satfracttiqq: Fixed-point fractional library routines. 46611 (line 1466) 46612* __satfracttisa: Fixed-point fractional library routines. 46613 (line 1471) 46614* __satfracttisq: Fixed-point fractional library routines. 46615 (line 1468) 46616* __satfracttita: Fixed-point fractional library routines. 46617 (line 1473) 46618* __satfracttiuda: Fixed-point fractional library routines. 46619 (line 1481) 46620* __satfracttiudq: Fixed-point fractional library routines. 46621 (line 1478) 46622* __satfracttiuha: Fixed-point fractional library routines. 46623 (line 1479) 46624* __satfracttiuhq: Fixed-point fractional library routines. 46625 (line 1475) 46626* __satfracttiuqq: Fixed-point fractional library routines. 46627 (line 1474) 46628* __satfracttiusa: Fixed-point fractional library routines. 46629 (line 1480) 46630* __satfracttiusq: Fixed-point fractional library routines. 46631 (line 1476) 46632* __satfracttiuta: Fixed-point fractional library routines. 46633 (line 1483) 46634* __satfractudada: Fixed-point fractional library routines. 46635 (line 1351) 46636* __satfractudadq: Fixed-point fractional library routines. 46637 (line 1347) 46638* __satfractudaha: Fixed-point fractional library routines. 46639 (line 1349) 46640* __satfractudahq: Fixed-point fractional library routines. 46641 (line 1344) 46642* __satfractudaqq: Fixed-point fractional library routines. 46643 (line 1343) 46644* __satfractudasa: Fixed-point fractional library routines. 46645 (line 1350) 46646* __satfractudasq: Fixed-point fractional library routines. 46647 (line 1345) 46648* __satfractudata: Fixed-point fractional library routines. 46649 (line 1353) 46650* __satfractudaudq: Fixed-point fractional library routines. 46651 (line 1361) 46652* __satfractudauha2: Fixed-point fractional library routines. 46653 (line 1363) 46654* __satfractudauhq: Fixed-point fractional library routines. 46655 (line 1357) 46656* __satfractudauqq: Fixed-point fractional library routines. 46657 (line 1355) 46658* __satfractudausa2: Fixed-point fractional library routines. 46659 (line 1365) 46660* __satfractudausq: Fixed-point fractional library routines. 46661 (line 1359) 46662* __satfractudauta2: Fixed-point fractional library routines. 46663 (line 1367) 46664* __satfractudqda: Fixed-point fractional library routines. 46665 (line 1276) 46666* __satfractudqdq: Fixed-point fractional library routines. 46667 (line 1271) 46668* __satfractudqha: Fixed-point fractional library routines. 46669 (line 1273) 46670* __satfractudqhq: Fixed-point fractional library routines. 46671 (line 1267) 46672* __satfractudqqq: Fixed-point fractional library routines. 46673 (line 1266) 46674* __satfractudqsa: Fixed-point fractional library routines. 46675 (line 1274) 46676* __satfractudqsq: Fixed-point fractional library routines. 46677 (line 1269) 46678* __satfractudqta: Fixed-point fractional library routines. 46679 (line 1278) 46680* __satfractudquda: Fixed-point fractional library routines. 46681 (line 1290) 46682* __satfractudquha: Fixed-point fractional library routines. 46683 (line 1286) 46684* __satfractudquhq2: Fixed-point fractional library routines. 46685 (line 1282) 46686* __satfractudquqq2: Fixed-point fractional library routines. 46687 (line 1280) 46688* __satfractudqusa: Fixed-point fractional library routines. 46689 (line 1288) 46690* __satfractudqusq2: Fixed-point fractional library routines. 46691 (line 1284) 46692* __satfractudquta: Fixed-point fractional library routines. 46693 (line 1292) 46694* __satfractuhada: Fixed-point fractional library routines. 46695 (line 1304) 46696* __satfractuhadq: Fixed-point fractional library routines. 46697 (line 1299) 46698* __satfractuhaha: Fixed-point fractional library routines. 46699 (line 1301) 46700* __satfractuhahq: Fixed-point fractional library routines. 46701 (line 1295) 46702* __satfractuhaqq: Fixed-point fractional library routines. 46703 (line 1294) 46704* __satfractuhasa: Fixed-point fractional library routines. 46705 (line 1302) 46706* __satfractuhasq: Fixed-point fractional library routines. 46707 (line 1297) 46708* __satfractuhata: Fixed-point fractional library routines. 46709 (line 1306) 46710* __satfractuhauda2: Fixed-point fractional library routines. 46711 (line 1318) 46712* __satfractuhaudq: Fixed-point fractional library routines. 46713 (line 1314) 46714* __satfractuhauhq: Fixed-point fractional library routines. 46715 (line 1310) 46716* __satfractuhauqq: Fixed-point fractional library routines. 46717 (line 1308) 46718* __satfractuhausa2: Fixed-point fractional library routines. 46719 (line 1316) 46720* __satfractuhausq: Fixed-point fractional library routines. 46721 (line 1312) 46722* __satfractuhauta2: Fixed-point fractional library routines. 46723 (line 1320) 46724* __satfractuhqda: Fixed-point fractional library routines. 46725 (line 1224) 46726* __satfractuhqdq: Fixed-point fractional library routines. 46727 (line 1221) 46728* __satfractuhqha: Fixed-point fractional library routines. 46729 (line 1222) 46730* __satfractuhqhq: Fixed-point fractional library routines. 46731 (line 1219) 46732* __satfractuhqqq: Fixed-point fractional library routines. 46733 (line 1218) 46734* __satfractuhqsa: Fixed-point fractional library routines. 46735 (line 1223) 46736* __satfractuhqsq: Fixed-point fractional library routines. 46737 (line 1220) 46738* __satfractuhqta: Fixed-point fractional library routines. 46739 (line 1225) 46740* __satfractuhquda: Fixed-point fractional library routines. 46741 (line 1236) 46742* __satfractuhqudq2: Fixed-point fractional library routines. 46743 (line 1231) 46744* __satfractuhquha: Fixed-point fractional library routines. 46745 (line 1233) 46746* __satfractuhquqq2: Fixed-point fractional library routines. 46747 (line 1227) 46748* __satfractuhqusa: Fixed-point fractional library routines. 46749 (line 1234) 46750* __satfractuhqusq2: Fixed-point fractional library routines. 46751 (line 1229) 46752* __satfractuhquta: Fixed-point fractional library routines. 46753 (line 1238) 46754* __satfractunsdida: Fixed-point fractional library routines. 46755 (line 1834) 46756* __satfractunsdidq: Fixed-point fractional library routines. 46757 (line 1831) 46758* __satfractunsdiha: Fixed-point fractional library routines. 46759 (line 1832) 46760* __satfractunsdihq: Fixed-point fractional library routines. 46761 (line 1828) 46762* __satfractunsdiqq: Fixed-point fractional library routines. 46763 (line 1827) 46764* __satfractunsdisa: Fixed-point fractional library routines. 46765 (line 1833) 46766* __satfractunsdisq: Fixed-point fractional library routines. 46767 (line 1829) 46768* __satfractunsdita: Fixed-point fractional library routines. 46769 (line 1836) 46770* __satfractunsdiuda: Fixed-point fractional library routines. 46771 (line 1850) 46772* __satfractunsdiudq: Fixed-point fractional library routines. 46773 (line 1844) 46774* __satfractunsdiuha: Fixed-point fractional library routines. 46775 (line 1846) 46776* __satfractunsdiuhq: Fixed-point fractional library routines. 46777 (line 1840) 46778* __satfractunsdiuqq: Fixed-point fractional library routines. 46779 (line 1838) 46780* __satfractunsdiusa: Fixed-point fractional library routines. 46781 (line 1848) 46782* __satfractunsdiusq: Fixed-point fractional library routines. 46783 (line 1842) 46784* __satfractunsdiuta: Fixed-point fractional library routines. 46785 (line 1852) 46786* __satfractunshida: Fixed-point fractional library routines. 46787 (line 1786) 46788* __satfractunshidq: Fixed-point fractional library routines. 46789 (line 1783) 46790* __satfractunshiha: Fixed-point fractional library routines. 46791 (line 1784) 46792* __satfractunshihq: Fixed-point fractional library routines. 46793 (line 1780) 46794* __satfractunshiqq: Fixed-point fractional library routines. 46795 (line 1779) 46796* __satfractunshisa: Fixed-point fractional library routines. 46797 (line 1785) 46798* __satfractunshisq: Fixed-point fractional library routines. 46799 (line 1781) 46800* __satfractunshita: Fixed-point fractional library routines. 46801 (line 1788) 46802* __satfractunshiuda: Fixed-point fractional library routines. 46803 (line 1802) 46804* __satfractunshiudq: Fixed-point fractional library routines. 46805 (line 1796) 46806* __satfractunshiuha: Fixed-point fractional library routines. 46807 (line 1798) 46808* __satfractunshiuhq: Fixed-point fractional library routines. 46809 (line 1792) 46810* __satfractunshiuqq: Fixed-point fractional library routines. 46811 (line 1790) 46812* __satfractunshiusa: Fixed-point fractional library routines. 46813 (line 1800) 46814* __satfractunshiusq: Fixed-point fractional library routines. 46815 (line 1794) 46816* __satfractunshiuta: Fixed-point fractional library routines. 46817 (line 1804) 46818* __satfractunsqida: Fixed-point fractional library routines. 46819 (line 1760) 46820* __satfractunsqidq: Fixed-point fractional library routines. 46821 (line 1757) 46822* __satfractunsqiha: Fixed-point fractional library routines. 46823 (line 1758) 46824* __satfractunsqihq: Fixed-point fractional library routines. 46825 (line 1754) 46826* __satfractunsqiqq: Fixed-point fractional library routines. 46827 (line 1753) 46828* __satfractunsqisa: Fixed-point fractional library routines. 46829 (line 1759) 46830* __satfractunsqisq: Fixed-point fractional library routines. 46831 (line 1755) 46832* __satfractunsqita: Fixed-point fractional library routines. 46833 (line 1762) 46834* __satfractunsqiuda: Fixed-point fractional library routines. 46835 (line 1776) 46836* __satfractunsqiudq: Fixed-point fractional library routines. 46837 (line 1770) 46838* __satfractunsqiuha: Fixed-point fractional library routines. 46839 (line 1772) 46840* __satfractunsqiuhq: Fixed-point fractional library routines. 46841 (line 1766) 46842* __satfractunsqiuqq: Fixed-point fractional library routines. 46843 (line 1764) 46844* __satfractunsqiusa: Fixed-point fractional library routines. 46845 (line 1774) 46846* __satfractunsqiusq: Fixed-point fractional library routines. 46847 (line 1768) 46848* __satfractunsqiuta: Fixed-point fractional library routines. 46849 (line 1778) 46850* __satfractunssida: Fixed-point fractional library routines. 46851 (line 1811) 46852* __satfractunssidq: Fixed-point fractional library routines. 46853 (line 1808) 46854* __satfractunssiha: Fixed-point fractional library routines. 46855 (line 1809) 46856* __satfractunssihq: Fixed-point fractional library routines. 46857 (line 1806) 46858* __satfractunssiqq: Fixed-point fractional library routines. 46859 (line 1805) 46860* __satfractunssisa: Fixed-point fractional library routines. 46861 (line 1810) 46862* __satfractunssisq: Fixed-point fractional library routines. 46863 (line 1807) 46864* __satfractunssita: Fixed-point fractional library routines. 46865 (line 1812) 46866* __satfractunssiuda: Fixed-point fractional library routines. 46867 (line 1824) 46868* __satfractunssiudq: Fixed-point fractional library routines. 46869 (line 1819) 46870* __satfractunssiuha: Fixed-point fractional library routines. 46871 (line 1821) 46872* __satfractunssiuhq: Fixed-point fractional library routines. 46873 (line 1815) 46874* __satfractunssiuqq: Fixed-point fractional library routines. 46875 (line 1814) 46876* __satfractunssiusa: Fixed-point fractional library routines. 46877 (line 1822) 46878* __satfractunssiusq: Fixed-point fractional library routines. 46879 (line 1817) 46880* __satfractunssiuta: Fixed-point fractional library routines. 46881 (line 1826) 46882* __satfractunstida: Fixed-point fractional library routines. 46883 (line 1864) 46884* __satfractunstidq: Fixed-point fractional library routines. 46885 (line 1859) 46886* __satfractunstiha: Fixed-point fractional library routines. 46887 (line 1861) 46888* __satfractunstihq: Fixed-point fractional library routines. 46889 (line 1855) 46890* __satfractunstiqq: Fixed-point fractional library routines. 46891 (line 1854) 46892* __satfractunstisa: Fixed-point fractional library routines. 46893 (line 1862) 46894* __satfractunstisq: Fixed-point fractional library routines. 46895 (line 1857) 46896* __satfractunstita: Fixed-point fractional library routines. 46897 (line 1866) 46898* __satfractunstiuda: Fixed-point fractional library routines. 46899 (line 1880) 46900* __satfractunstiudq: Fixed-point fractional library routines. 46901 (line 1874) 46902* __satfractunstiuha: Fixed-point fractional library routines. 46903 (line 1876) 46904* __satfractunstiuhq: Fixed-point fractional library routines. 46905 (line 1870) 46906* __satfractunstiuqq: Fixed-point fractional library routines. 46907 (line 1868) 46908* __satfractunstiusa: Fixed-point fractional library routines. 46909 (line 1878) 46910* __satfractunstiusq: Fixed-point fractional library routines. 46911 (line 1872) 46912* __satfractunstiuta: Fixed-point fractional library routines. 46913 (line 1882) 46914* __satfractuqqda: Fixed-point fractional library routines. 46915 (line 1201) 46916* __satfractuqqdq: Fixed-point fractional library routines. 46917 (line 1196) 46918* __satfractuqqha: Fixed-point fractional library routines. 46919 (line 1198) 46920* __satfractuqqhq: Fixed-point fractional library routines. 46921 (line 1192) 46922* __satfractuqqqq: Fixed-point fractional library routines. 46923 (line 1191) 46924* __satfractuqqsa: Fixed-point fractional library routines. 46925 (line 1199) 46926* __satfractuqqsq: Fixed-point fractional library routines. 46927 (line 1194) 46928* __satfractuqqta: Fixed-point fractional library routines. 46929 (line 1203) 46930* __satfractuqquda: Fixed-point fractional library routines. 46931 (line 1215) 46932* __satfractuqqudq2: Fixed-point fractional library routines. 46933 (line 1209) 46934* __satfractuqquha: Fixed-point fractional library routines. 46935 (line 1211) 46936* __satfractuqquhq2: Fixed-point fractional library routines. 46937 (line 1205) 46938* __satfractuqqusa: Fixed-point fractional library routines. 46939 (line 1213) 46940* __satfractuqqusq2: Fixed-point fractional library routines. 46941 (line 1207) 46942* __satfractuqquta: Fixed-point fractional library routines. 46943 (line 1217) 46944* __satfractusada: Fixed-point fractional library routines. 46945 (line 1327) 46946* __satfractusadq: Fixed-point fractional library routines. 46947 (line 1324) 46948* __satfractusaha: Fixed-point fractional library routines. 46949 (line 1325) 46950* __satfractusahq: Fixed-point fractional library routines. 46951 (line 1322) 46952* __satfractusaqq: Fixed-point fractional library routines. 46953 (line 1321) 46954* __satfractusasa: Fixed-point fractional library routines. 46955 (line 1326) 46956* __satfractusasq: Fixed-point fractional library routines. 46957 (line 1323) 46958* __satfractusata: Fixed-point fractional library routines. 46959 (line 1328) 46960* __satfractusauda2: Fixed-point fractional library routines. 46961 (line 1339) 46962* __satfractusaudq: Fixed-point fractional library routines. 46963 (line 1335) 46964* __satfractusauha2: Fixed-point fractional library routines. 46965 (line 1337) 46966* __satfractusauhq: Fixed-point fractional library routines. 46967 (line 1331) 46968* __satfractusauqq: Fixed-point fractional library routines. 46969 (line 1330) 46970* __satfractusausq: Fixed-point fractional library routines. 46971 (line 1333) 46972* __satfractusauta2: Fixed-point fractional library routines. 46973 (line 1341) 46974* __satfractusqda: Fixed-point fractional library routines. 46975 (line 1248) 46976* __satfractusqdq: Fixed-point fractional library routines. 46977 (line 1244) 46978* __satfractusqha: Fixed-point fractional library routines. 46979 (line 1246) 46980* __satfractusqhq: Fixed-point fractional library routines. 46981 (line 1241) 46982* __satfractusqqq: Fixed-point fractional library routines. 46983 (line 1240) 46984* __satfractusqsa: Fixed-point fractional library routines. 46985 (line 1247) 46986* __satfractusqsq: Fixed-point fractional library routines. 46987 (line 1242) 46988* __satfractusqta: Fixed-point fractional library routines. 46989 (line 1250) 46990* __satfractusquda: Fixed-point fractional library routines. 46991 (line 1262) 46992* __satfractusqudq2: Fixed-point fractional library routines. 46993 (line 1256) 46994* __satfractusquha: Fixed-point fractional library routines. 46995 (line 1258) 46996* __satfractusquhq2: Fixed-point fractional library routines. 46997 (line 1254) 46998* __satfractusquqq2: Fixed-point fractional library routines. 46999 (line 1252) 47000* __satfractusqusa: Fixed-point fractional library routines. 47001 (line 1260) 47002* __satfractusquta: Fixed-point fractional library routines. 47003 (line 1264) 47004* __satfractutada: Fixed-point fractional library routines. 47005 (line 1379) 47006* __satfractutadq: Fixed-point fractional library routines. 47007 (line 1374) 47008* __satfractutaha: Fixed-point fractional library routines. 47009 (line 1376) 47010* __satfractutahq: Fixed-point fractional library routines. 47011 (line 1370) 47012* __satfractutaqq: Fixed-point fractional library routines. 47013 (line 1369) 47014* __satfractutasa: Fixed-point fractional library routines. 47015 (line 1377) 47016* __satfractutasq: Fixed-point fractional library routines. 47017 (line 1372) 47018* __satfractutata: Fixed-point fractional library routines. 47019 (line 1381) 47020* __satfractutauda2: Fixed-point fractional library routines. 47021 (line 1395) 47022* __satfractutaudq: Fixed-point fractional library routines. 47023 (line 1389) 47024* __satfractutauha2: Fixed-point fractional library routines. 47025 (line 1391) 47026* __satfractutauhq: Fixed-point fractional library routines. 47027 (line 1385) 47028* __satfractutauqq: Fixed-point fractional library routines. 47029 (line 1383) 47030* __satfractutausa2: Fixed-point fractional library routines. 47031 (line 1393) 47032* __satfractutausq: Fixed-point fractional library routines. 47033 (line 1387) 47034* __splitstack_find: Miscellaneous routines. 47035 (line 18) 47036* __ssaddda3: Fixed-point fractional library routines. 47037 (line 67) 47038* __ssadddq3: Fixed-point fractional library routines. 47039 (line 63) 47040* __ssaddha3: Fixed-point fractional library routines. 47041 (line 65) 47042* __ssaddhq3: Fixed-point fractional library routines. 47043 (line 60) 47044* __ssaddqq3: Fixed-point fractional library routines. 47045 (line 59) 47046* __ssaddsa3: Fixed-point fractional library routines. 47047 (line 66) 47048* __ssaddsq3: Fixed-point fractional library routines. 47049 (line 61) 47050* __ssaddta3: Fixed-point fractional library routines. 47051 (line 69) 47052* __ssashlda3: Fixed-point fractional library routines. 47053 (line 402) 47054* __ssashldq3: Fixed-point fractional library routines. 47055 (line 399) 47056* __ssashlha3: Fixed-point fractional library routines. 47057 (line 400) 47058* __ssashlhq3: Fixed-point fractional library routines. 47059 (line 396) 47060* __ssashlsa3: Fixed-point fractional library routines. 47061 (line 401) 47062* __ssashlsq3: Fixed-point fractional library routines. 47063 (line 397) 47064* __ssashlta3: Fixed-point fractional library routines. 47065 (line 404) 47066* __ssdivda3: Fixed-point fractional library routines. 47067 (line 261) 47068* __ssdivdq3: Fixed-point fractional library routines. 47069 (line 257) 47070* __ssdivha3: Fixed-point fractional library routines. 47071 (line 259) 47072* __ssdivhq3: Fixed-point fractional library routines. 47073 (line 254) 47074* __ssdivqq3: Fixed-point fractional library routines. 47075 (line 253) 47076* __ssdivsa3: Fixed-point fractional library routines. 47077 (line 260) 47078* __ssdivsq3: Fixed-point fractional library routines. 47079 (line 255) 47080* __ssdivta3: Fixed-point fractional library routines. 47081 (line 263) 47082* __ssmulda3: Fixed-point fractional library routines. 47083 (line 193) 47084* __ssmuldq3: Fixed-point fractional library routines. 47085 (line 189) 47086* __ssmulha3: Fixed-point fractional library routines. 47087 (line 191) 47088* __ssmulhq3: Fixed-point fractional library routines. 47089 (line 186) 47090* __ssmulqq3: Fixed-point fractional library routines. 47091 (line 185) 47092* __ssmulsa3: Fixed-point fractional library routines. 47093 (line 192) 47094* __ssmulsq3: Fixed-point fractional library routines. 47095 (line 187) 47096* __ssmulta3: Fixed-point fractional library routines. 47097 (line 195) 47098* __ssnegda2: Fixed-point fractional library routines. 47099 (line 316) 47100* __ssnegdq2: Fixed-point fractional library routines. 47101 (line 313) 47102* __ssnegha2: Fixed-point fractional library routines. 47103 (line 314) 47104* __ssneghq2: Fixed-point fractional library routines. 47105 (line 311) 47106* __ssnegqq2: Fixed-point fractional library routines. 47107 (line 310) 47108* __ssnegsa2: Fixed-point fractional library routines. 47109 (line 315) 47110* __ssnegsq2: Fixed-point fractional library routines. 47111 (line 312) 47112* __ssnegta2: Fixed-point fractional library routines. 47113 (line 317) 47114* __sssubda3: Fixed-point fractional library routines. 47115 (line 129) 47116* __sssubdq3: Fixed-point fractional library routines. 47117 (line 125) 47118* __sssubha3: Fixed-point fractional library routines. 47119 (line 127) 47120* __sssubhq3: Fixed-point fractional library routines. 47121 (line 122) 47122* __sssubqq3: Fixed-point fractional library routines. 47123 (line 121) 47124* __sssubsa3: Fixed-point fractional library routines. 47125 (line 128) 47126* __sssubsq3: Fixed-point fractional library routines. 47127 (line 123) 47128* __sssubta3: Fixed-point fractional library routines. 47129 (line 131) 47130* __subda3: Fixed-point fractional library routines. 47131 (line 107) 47132* __subdf3: Soft float library routines. 47133 (line 31) 47134* __subdq3: Fixed-point fractional library routines. 47135 (line 95) 47136* __subha3: Fixed-point fractional library routines. 47137 (line 105) 47138* __subhq3: Fixed-point fractional library routines. 47139 (line 92) 47140* __subqq3: Fixed-point fractional library routines. 47141 (line 91) 47142* __subsa3: Fixed-point fractional library routines. 47143 (line 106) 47144* __subsf3: Soft float library routines. 47145 (line 30) 47146* __subsq3: Fixed-point fractional library routines. 47147 (line 93) 47148* __subta3: Fixed-point fractional library routines. 47149 (line 109) 47150* __subtf3: Soft float library routines. 47151 (line 33) 47152* __subuda3: Fixed-point fractional library routines. 47153 (line 115) 47154* __subudq3: Fixed-point fractional library routines. 47155 (line 103) 47156* __subuha3: Fixed-point fractional library routines. 47157 (line 111) 47158* __subuhq3: Fixed-point fractional library routines. 47159 (line 99) 47160* __subuqq3: Fixed-point fractional library routines. 47161 (line 97) 47162* __subusa3: Fixed-point fractional library routines. 47163 (line 113) 47164* __subusq3: Fixed-point fractional library routines. 47165 (line 101) 47166* __subuta3: Fixed-point fractional library routines. 47167 (line 117) 47168* __subvdi3: Integer library routines. 47169 (line 123) 47170* __subvsi3: Integer library routines. 47171 (line 122) 47172* __subxf3: Soft float library routines. 47173 (line 35) 47174* __truncdfsf2: Soft float library routines. 47175 (line 76) 47176* __trunctfdf2: Soft float library routines. 47177 (line 73) 47178* __trunctfsf2: Soft float library routines. 47179 (line 75) 47180* __truncxfdf2: Soft float library routines. 47181 (line 72) 47182* __truncxfsf2: Soft float library routines. 47183 (line 74) 47184* __ucmpdi2: Integer library routines. 47185 (line 93) 47186* __ucmpti2: Integer library routines. 47187 (line 95) 47188* __udivdi3: Integer library routines. 47189 (line 54) 47190* __udivmoddi4: Integer library routines. 47191 (line 61) 47192* __udivmodti4: Integer library routines. 47193 (line 63) 47194* __udivsi3: Integer library routines. 47195 (line 52) 47196* __udivti3: Integer library routines. 47197 (line 56) 47198* __udivuda3: Fixed-point fractional library routines. 47199 (line 246) 47200* __udivudq3: Fixed-point fractional library routines. 47201 (line 240) 47202* __udivuha3: Fixed-point fractional library routines. 47203 (line 242) 47204* __udivuhq3: Fixed-point fractional library routines. 47205 (line 236) 47206* __udivuqq3: Fixed-point fractional library routines. 47207 (line 234) 47208* __udivusa3: Fixed-point fractional library routines. 47209 (line 244) 47210* __udivusq3: Fixed-point fractional library routines. 47211 (line 238) 47212* __udivuta3: Fixed-point fractional library routines. 47213 (line 248) 47214* __umoddi3: Integer library routines. 47215 (line 71) 47216* __umodsi3: Integer library routines. 47217 (line 69) 47218* __umodti3: Integer library routines. 47219 (line 73) 47220* __unorddf2: Soft float library routines. 47221 (line 173) 47222* __unordsf2: Soft float library routines. 47223 (line 172) 47224* __unordtf2: Soft float library routines. 47225 (line 174) 47226* __usadduda3: Fixed-point fractional library routines. 47227 (line 85) 47228* __usaddudq3: Fixed-point fractional library routines. 47229 (line 79) 47230* __usadduha3: Fixed-point fractional library routines. 47231 (line 81) 47232* __usadduhq3: Fixed-point fractional library routines. 47233 (line 75) 47234* __usadduqq3: Fixed-point fractional library routines. 47235 (line 73) 47236* __usaddusa3: Fixed-point fractional library routines. 47237 (line 83) 47238* __usaddusq3: Fixed-point fractional library routines. 47239 (line 77) 47240* __usadduta3: Fixed-point fractional library routines. 47241 (line 87) 47242* __usashluda3: Fixed-point fractional library routines. 47243 (line 421) 47244* __usashludq3: Fixed-point fractional library routines. 47245 (line 415) 47246* __usashluha3: Fixed-point fractional library routines. 47247 (line 417) 47248* __usashluhq3: Fixed-point fractional library routines. 47249 (line 411) 47250* __usashluqq3: Fixed-point fractional library routines. 47251 (line 409) 47252* __usashlusa3: Fixed-point fractional library routines. 47253 (line 419) 47254* __usashlusq3: Fixed-point fractional library routines. 47255 (line 413) 47256* __usashluta3: Fixed-point fractional library routines. 47257 (line 423) 47258* __usdivuda3: Fixed-point fractional library routines. 47259 (line 280) 47260* __usdivudq3: Fixed-point fractional library routines. 47261 (line 274) 47262* __usdivuha3: Fixed-point fractional library routines. 47263 (line 276) 47264* __usdivuhq3: Fixed-point fractional library routines. 47265 (line 270) 47266* __usdivuqq3: Fixed-point fractional library routines. 47267 (line 268) 47268* __usdivusa3: Fixed-point fractional library routines. 47269 (line 278) 47270* __usdivusq3: Fixed-point fractional library routines. 47271 (line 272) 47272* __usdivuta3: Fixed-point fractional library routines. 47273 (line 282) 47274* __usmuluda3: Fixed-point fractional library routines. 47275 (line 212) 47276* __usmuludq3: Fixed-point fractional library routines. 47277 (line 206) 47278* __usmuluha3: Fixed-point fractional library routines. 47279 (line 208) 47280* __usmuluhq3: Fixed-point fractional library routines. 47281 (line 202) 47282* __usmuluqq3: Fixed-point fractional library routines. 47283 (line 200) 47284* __usmulusa3: Fixed-point fractional library routines. 47285 (line 210) 47286* __usmulusq3: Fixed-point fractional library routines. 47287 (line 204) 47288* __usmuluta3: Fixed-point fractional library routines. 47289 (line 214) 47290* __usneguda2: Fixed-point fractional library routines. 47291 (line 331) 47292* __usnegudq2: Fixed-point fractional library routines. 47293 (line 326) 47294* __usneguha2: Fixed-point fractional library routines. 47295 (line 328) 47296* __usneguhq2: Fixed-point fractional library routines. 47297 (line 322) 47298* __usneguqq2: Fixed-point fractional library routines. 47299 (line 321) 47300* __usnegusa2: Fixed-point fractional library routines. 47301 (line 329) 47302* __usnegusq2: Fixed-point fractional library routines. 47303 (line 324) 47304* __usneguta2: Fixed-point fractional library routines. 47305 (line 333) 47306* __ussubuda3: Fixed-point fractional library routines. 47307 (line 148) 47308* __ussubudq3: Fixed-point fractional library routines. 47309 (line 142) 47310* __ussubuha3: Fixed-point fractional library routines. 47311 (line 144) 47312* __ussubuhq3: Fixed-point fractional library routines. 47313 (line 138) 47314* __ussubuqq3: Fixed-point fractional library routines. 47315 (line 136) 47316* __ussubusa3: Fixed-point fractional library routines. 47317 (line 146) 47318* __ussubusq3: Fixed-point fractional library routines. 47319 (line 140) 47320* __ussubuta3: Fixed-point fractional library routines. 47321 (line 150) 47322* abort: Portability. (line 21) 47323* abs: Arithmetic. (line 199) 47324* abs and attributes: Expressions. (line 85) 47325* ABS_EXPR: Unary and Binary Expressions. 47326 (line 6) 47327* absence_set: Processor pipeline description. 47328 (line 224) 47329* absM2 instruction pattern: Standard Names. (line 587) 47330* absolute value: Arithmetic. (line 199) 47331* access to operands: Accessors. (line 6) 47332* access to special operands: Special Accessors. (line 6) 47333* accessors: Accessors. (line 6) 47334* ACCUM_TYPE_SIZE: Type Layout. (line 88) 47335* ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 49) 47336* ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 135) 47337* ADA_LONG_TYPE_SIZE: Type Layout. (line 26) 47338* Adding a new GIMPLE statement code: Adding a new GIMPLE statement code. 47339 (line 6) 47340* ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 15) 47341* addM3 instruction pattern: Standard Names. (line 263) 47342* addMODEcc instruction pattern: Standard Names. (line 1117) 47343* addptrM3 instruction pattern: Standard Names. (line 293) 47344* addr_diff_vec: Side Effects. (line 315) 47345* addr_diff_vec, length of: Insn Lengths. (line 26) 47346* ADDR_EXPR: Storage References. (line 6) 47347* addr_vec: Side Effects. (line 310) 47348* addr_vec, length of: Insn Lengths. (line 26) 47349* address constraints: Simple Constraints. (line 164) 47350* address_operand <1>: Simple Constraints. (line 168) 47351* address_operand: Machine-Independent Predicates. 47352 (line 63) 47353* addressing modes: Addressing Modes. (line 6) 47354* addvM4 instruction pattern: Standard Names. (line 279) 47355* ADJUST_FIELD_ALIGN: Storage Layout. (line 197) 47356* ADJUST_INSN_LENGTH: Insn Lengths. (line 41) 47357* ADJUST_REG_ALLOC_ORDER: Allocation Order. (line 23) 47358* aggregates as return values: Aggregate Return. (line 6) 47359* alias: Alias analysis. (line 6) 47360* ALL_REGS: Register Classes. (line 17) 47361* allocate_stack instruction pattern: Standard Names. (line 1434) 47362* alternate entry points: Insns. (line 146) 47363* anchored addresses: Anchored Addresses. (line 6) 47364* and: Arithmetic. (line 157) 47365* and and attributes: Expressions. (line 50) 47366* and, canonicalization of: Insn Canonicalizations. 47367 (line 52) 47368* andM3 instruction pattern: Standard Names. (line 269) 47369* ANNOTATE_EXPR: Unary and Binary Expressions. 47370 (line 6) 47371* annotations: Annotations. (line 6) 47372* APPLY_RESULT_SIZE: Scalar Return. (line 112) 47373* ARG_POINTER_CFA_OFFSET: Frame Layout. (line 196) 47374* ARG_POINTER_REGNUM: Frame Registers. (line 41) 47375* ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65) 47376* arg_pointer_rtx: Frame Registers. (line 104) 47377* ARGS_GROW_DOWNWARD: Frame Layout. (line 35) 47378* argument passing: Interface. (line 36) 47379* arguments in registers: Register Arguments. (line 6) 47380* arguments on stack: Stack Arguments. (line 6) 47381* arithmetic library: Soft float library routines. 47382 (line 6) 47383* arithmetic shift: Arithmetic. (line 172) 47384* arithmetic shift with signed saturation: Arithmetic. (line 172) 47385* arithmetic shift with unsigned saturation: Arithmetic. (line 172) 47386* arithmetic, in RTL: Arithmetic. (line 6) 47387* ARITHMETIC_TYPE_P: Types for C++. (line 61) 47388* array: Types. (line 6) 47389* ARRAY_RANGE_REF: Storage References. (line 6) 47390* ARRAY_REF: Storage References. (line 6) 47391* ARRAY_TYPE: Types. (line 6) 47392* AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 89) 47393* ashift: Arithmetic. (line 172) 47394* ashift and attributes: Expressions. (line 85) 47395* ashiftrt: Arithmetic. (line 189) 47396* ashiftrt and attributes: Expressions. (line 85) 47397* ashlM3 instruction pattern: Standard Names. (line 558) 47398* ashrM3 instruction pattern: Standard Names. (line 568) 47399* ASM_APP_OFF: File Framework. (line 78) 47400* ASM_APP_ON: File Framework. (line 71) 47401* ASM_COMMENT_START: File Framework. (line 66) 47402* ASM_DECLARE_FUNCTION_NAME: Label Output. (line 111) 47403* ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 126) 47404* ASM_DECLARE_OBJECT_NAME: Label Output. (line 139) 47405* ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 168) 47406* ASM_FINAL_SPEC: Driver. (line 82) 47407* ASM_FINISH_DECLARE_OBJECT: Label Output. (line 176) 47408* ASM_FORMAT_PRIVATE_NAME: Label Output. (line 402) 47409* asm_fprintf: Instruction Output. (line 151) 47410* ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 162) 47411* ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 386) 47412* asm_input: Side Effects. (line 297) 47413* asm_input and /v: Flags. (line 76) 47414* ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 82) 47415* ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 79) 47416* asm_noperands: Insns. (line 308) 47417* asm_operands and /v: Flags. (line 76) 47418* asm_operands, RTL sharing: Sharing. (line 45) 47419* asm_operands, usage: Assembler. (line 6) 47420* ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 9) 47421* ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 26) 47422* ASM_OUTPUT_ALIGN: Alignment Output. (line 86) 47423* ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 91) 47424* ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 46) 47425* ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 30) 47426* ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 38) 47427* ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 91) 47428* ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 83) 47429* ASM_OUTPUT_ASCII: Data Output. (line 55) 47430* ASM_OUTPUT_CASE_END: Dispatch Tables. (line 51) 47431* ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 38) 47432* ASM_OUTPUT_COMMON: Uninitialized Data. (line 10) 47433* ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 374) 47434* ASM_OUTPUT_DEF: Label Output. (line 423) 47435* ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 431) 47436* ASM_OUTPUT_DWARF_DELTA: SDB and DWARF. (line 78) 47437* ASM_OUTPUT_DWARF_OFFSET: SDB and DWARF. (line 87) 47438* ASM_OUTPUT_DWARF_PCREL: SDB and DWARF. (line 93) 47439* ASM_OUTPUT_DWARF_TABLE_REF: SDB and DWARF. (line 98) 47440* ASM_OUTPUT_DWARF_VMS_DELTA: SDB and DWARF. (line 82) 47441* ASM_OUTPUT_EXTERNAL: Label Output. (line 303) 47442* ASM_OUTPUT_FDESC: Data Output. (line 64) 47443* ASM_OUTPUT_FUNCTION_LABEL: Label Output. (line 17) 47444* ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 29) 47445* ASM_OUTPUT_LABEL: Label Output. (line 9) 47446* ASM_OUTPUT_LABEL_REF: Label Output. (line 347) 47447* ASM_OUTPUT_LABELREF: Label Output. (line 325) 47448* ASM_OUTPUT_LOCAL: Uninitialized Data. (line 70) 47449* ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 95) 47450* ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 53) 47451* ASM_OUTPUT_OPCODE: Instruction Output. (line 36) 47452* ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 114) 47453* ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 77) 47454* ASM_OUTPUT_REG_POP: Instruction Output. (line 208) 47455* ASM_OUTPUT_REG_PUSH: Instruction Output. (line 203) 47456* ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 47) 47457* ASM_OUTPUT_SKIP: Alignment Output. (line 73) 47458* ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 85) 47459* ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 89) 47460* ASM_OUTPUT_SYMBOL_REF: Label Output. (line 340) 47461* ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 101) 47462* ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 449) 47463* ASM_OUTPUT_WEAKREF: Label Output. (line 235) 47464* ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 67) 47465* ASM_SPEC: Driver. (line 74) 47466* ASM_STABD_OP: DBX Options. (line 36) 47467* ASM_STABN_OP: DBX Options. (line 43) 47468* ASM_STABS_OP: DBX Options. (line 29) 47469* ASM_WEAKEN_DECL: Label Output. (line 227) 47470* ASM_WEAKEN_LABEL: Label Output. (line 214) 47471* assemble_name: Label Output. (line 8) 47472* assemble_name_raw: Label Output. (line 28) 47473* assembler format: File Framework. (line 6) 47474* assembler instructions in RTL: Assembler. (line 6) 47475* ASSEMBLER_DIALECT: Instruction Output. (line 174) 47476* assigning attribute values to insns: Tagging Insns. (line 6) 47477* ASSUME_EXTENDED_UNWIND_CONTEXT: Frame Registers. (line 164) 47478* asterisk in template: Output Statement. (line 29) 47479* atan2M3 instruction pattern: Standard Names. (line 670) 47480* atomic: GTY Options. (line 196) 47481* atomic_add_fetchMODE instruction pattern: Standard Names. (line 1867) 47482* atomic_addMODE instruction pattern: Standard Names. (line 1838) 47483* atomic_and_fetchMODE instruction pattern: Standard Names. (line 1867) 47484* atomic_andMODE instruction pattern: Standard Names. (line 1838) 47485* atomic_compare_and_swapMODE instruction pattern: Standard Names. 47486 (line 1774) 47487* atomic_exchangeMODE instruction pattern: Standard Names. (line 1826) 47488* atomic_fetch_addMODE instruction pattern: Standard Names. (line 1852) 47489* atomic_fetch_andMODE instruction pattern: Standard Names. (line 1852) 47490* atomic_fetch_nandMODE instruction pattern: Standard Names. (line 1852) 47491* atomic_fetch_orMODE instruction pattern: Standard Names. (line 1852) 47492* atomic_fetch_subMODE instruction pattern: Standard Names. (line 1852) 47493* atomic_fetch_xorMODE instruction pattern: Standard Names. (line 1852) 47494* atomic_loadMODE instruction pattern: Standard Names. (line 1805) 47495* atomic_nand_fetchMODE instruction pattern: Standard Names. (line 1867) 47496* atomic_nandMODE instruction pattern: Standard Names. (line 1838) 47497* atomic_or_fetchMODE instruction pattern: Standard Names. (line 1867) 47498* atomic_orMODE instruction pattern: Standard Names. (line 1838) 47499* atomic_storeMODE instruction pattern: Standard Names. (line 1815) 47500* atomic_sub_fetchMODE instruction pattern: Standard Names. (line 1867) 47501* atomic_subMODE instruction pattern: Standard Names. (line 1838) 47502* atomic_test_and_set instruction pattern: Standard Names. (line 1884) 47503* atomic_xor_fetchMODE instruction pattern: Standard Names. (line 1867) 47504* atomic_xorMODE instruction pattern: Standard Names. (line 1838) 47505* attr <1>: Tagging Insns. (line 54) 47506* attr: Expressions. (line 165) 47507* attr_flag: Expressions. (line 140) 47508* attribute expressions: Expressions. (line 6) 47509* attribute specifications: Attr Example. (line 6) 47510* attribute specifications example: Attr Example. (line 6) 47511* ATTRIBUTE_ALIGNED_VALUE: Storage Layout. (line 179) 47512* attributes: Attributes. (line 6) 47513* attributes, defining: Defining Attributes. 47514 (line 6) 47515* attributes, target-specific: Target Attributes. (line 6) 47516* autoincrement addressing, availability: Portability. (line 21) 47517* autoincrement/decrement addressing: Simple Constraints. (line 30) 47518* automata_option: Processor pipeline description. 47519 (line 305) 47520* automaton based pipeline description: Processor pipeline description. 47521 (line 6) 47522* automaton based scheduler: Processor pipeline description. 47523 (line 6) 47524* AVOID_CCMODE_COPIES: Values in Registers. 47525 (line 153) 47526* backslash: Output Template. (line 46) 47527* barrier: Insns. (line 177) 47528* barrier and /f: Flags. (line 107) 47529* barrier and /v: Flags. (line 44) 47530* BASE_REG_CLASS: Register Classes. (line 114) 47531* basic block: Basic Blocks. (line 6) 47532* Basic Statements: Basic Statements. (line 6) 47533* basic-block.h: Control Flow. (line 6) 47534* BASIC_BLOCK: Basic Blocks. (line 14) 47535* basic_block: Basic Blocks. (line 6) 47536* BB_HEAD, BB_END: Maintaining the CFG. 47537 (line 77) 47538* bb_seq: GIMPLE sequences. (line 73) 47539* BIGGEST_ALIGNMENT: Storage Layout. (line 164) 47540* BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 190) 47541* BImode: Machine Modes. (line 22) 47542* BIND_EXPR: Unary and Binary Expressions. 47543 (line 6) 47544* BINFO_TYPE: Classes. (line 6) 47545* bit-fields: Bit-Fields. (line 6) 47546* BIT_AND_EXPR: Unary and Binary Expressions. 47547 (line 6) 47548* BIT_IOR_EXPR: Unary and Binary Expressions. 47549 (line 6) 47550* BIT_NOT_EXPR: Unary and Binary Expressions. 47551 (line 6) 47552* BIT_XOR_EXPR: Unary and Binary Expressions. 47553 (line 6) 47554* BITFIELD_NBYTES_LIMITED: Storage Layout. (line 402) 47555* BITS_BIG_ENDIAN: Storage Layout. (line 12) 47556* BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8) 47557* BITS_PER_UNIT: Machine Modes. (line 355) 47558* BITS_PER_WORD: Storage Layout. (line 51) 47559* bitwise complement: Arithmetic. (line 153) 47560* bitwise exclusive-or: Arithmetic. (line 167) 47561* bitwise inclusive-or: Arithmetic. (line 162) 47562* bitwise logical-and: Arithmetic. (line 157) 47563* BLKmode: Machine Modes. (line 186) 47564* BLKmode, and function return values: Calls. (line 23) 47565* BLOCK_FOR_INSN, gimple_bb: Maintaining the CFG. 47566 (line 29) 47567* BLOCK_REG_PADDING: Register Arguments. (line 244) 47568* blockage instruction pattern: Standard Names. (line 1637) 47569* Blocks: Blocks. (line 6) 47570* BND32mode: Machine Modes. (line 210) 47571* BND64mode: Machine Modes. (line 210) 47572* bool: Misc. (line 998) 47573* BOOL_TYPE_SIZE: Type Layout. (line 44) 47574* BOOLEAN_TYPE: Types. (line 6) 47575* branch prediction: Profile information. 47576 (line 24) 47577* BRANCH_COST: Costs. (line 105) 47578* break_out_memory_refs: Addressing Modes. (line 135) 47579* BREAK_STMT: Statements for C++. (line 6) 47580* BSS_SECTION_ASM_OP: Sections. (line 68) 47581* bswap: Arithmetic. (line 246) 47582* bswapM2 instruction pattern: Standard Names. (line 576) 47583* btruncM2 instruction pattern: Standard Names. (line 688) 47584* build0: Macros and Functions. 47585 (line 16) 47586* build1: Macros and Functions. 47587 (line 17) 47588* build2: Macros and Functions. 47589 (line 18) 47590* build3: Macros and Functions. 47591 (line 19) 47592* build4: Macros and Functions. 47593 (line 20) 47594* build5: Macros and Functions. 47595 (line 21) 47596* build6: Macros and Functions. 47597 (line 22) 47598* builtin_longjmp instruction pattern: Standard Names. (line 1534) 47599* builtin_setjmp_receiver instruction pattern: Standard Names. 47600 (line 1524) 47601* builtin_setjmp_setup instruction pattern: Standard Names. (line 1513) 47602* byte_mode: Machine Modes. (line 368) 47603* BYTES_BIG_ENDIAN: Storage Layout. (line 24) 47604* BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 221) 47605* C statements for assembler output: Output Statement. (line 6) 47606* C_COMMON_OVERRIDE_OPTIONS: Run-time Target. (line 137) 47607* c_register_pragma: Misc. (line 410) 47608* c_register_pragma_with_expansion: Misc. (line 412) 47609* cache: GTY Options. (line 124) 47610* call <1>: Side Effects. (line 92) 47611* call: Flags. (line 221) 47612* call instruction pattern: Standard Names. (line 1174) 47613* call usage: Calls. (line 10) 47614* call, in call_insn: Flags. (line 33) 47615* call, in mem: Flags. (line 81) 47616* call-clobbered register: Register Basics. (line 35) 47617* call-saved register: Register Basics. (line 35) 47618* call-used register: Register Basics. (line 35) 47619* CALL_EXPR: Unary and Binary Expressions. 47620 (line 6) 47621* call_insn: Insns. (line 95) 47622* call_insn and /c: Flags. (line 33) 47623* call_insn and /f: Flags. (line 107) 47624* call_insn and /i: Flags. (line 24) 47625* call_insn and /j: Flags. (line 161) 47626* call_insn and /s: Flags. (line 49) 47627* call_insn and /u: Flags. (line 19) 47628* call_insn and /u or /i: Flags. (line 29) 47629* call_insn and /v: Flags. (line 44) 47630* CALL_INSN_FUNCTION_USAGE: Insns. (line 101) 47631* call_pop instruction pattern: Standard Names. (line 1202) 47632* CALL_POPS_ARGS: Stack Arguments. (line 139) 47633* CALL_REALLY_USED_REGISTERS: Register Basics. (line 46) 47634* CALL_USED_REGISTERS: Register Basics. (line 35) 47635* call_used_regs: Register Basics. (line 59) 47636* call_value instruction pattern: Standard Names. (line 1194) 47637* call_value_pop instruction pattern: Standard Names. (line 1202) 47638* calling conventions: Stack and Calling. (line 6) 47639* calling functions in RTL: Calls. (line 6) 47640* can_create_pseudo_p: Standard Names. (line 75) 47641* can_fallthru: Basic Blocks. (line 67) 47642* canadian: Configure Terms. (line 6) 47643* CANNOT_CHANGE_MODE_CLASS: Register Classes. (line 538) 47644* CANNOT_CHANGE_MODE_CLASS and subreg semantics: Regs and Memory. 47645 (line 280) 47646* canonicalization of instructions: Insn Canonicalizations. 47647 (line 6) 47648* canonicalize_funcptr_for_compare instruction pattern: Standard Names. 47649 (line 1365) 47650* caret: Multi-Alternative. (line 52) 47651* CASE_VECTOR_MODE: Misc. (line 27) 47652* CASE_VECTOR_PC_RELATIVE: Misc. (line 40) 47653* CASE_VECTOR_SHORTEN_MODE: Misc. (line 31) 47654* casesi instruction pattern: Standard Names. (line 1296) 47655* cbranchMODE4 instruction pattern: Standard Names. (line 1163) 47656* cc0 <1>: CC0 Condition Codes. 47657 (line 6) 47658* cc0: Regs and Memory. (line 307) 47659* cc0, RTL sharing: Sharing. (line 27) 47660* cc0_rtx: Regs and Memory. (line 333) 47661* CC1_SPEC: Driver. (line 56) 47662* CC1PLUS_SPEC: Driver. (line 64) 47663* cc_status: CC0 Condition Codes. 47664 (line 6) 47665* CC_STATUS_MDEP: CC0 Condition Codes. 47666 (line 17) 47667* CC_STATUS_MDEP_INIT: CC0 Condition Codes. 47668 (line 23) 47669* CCmode <1>: MODE_CC Condition Codes. 47670 (line 6) 47671* CCmode: Machine Modes. (line 179) 47672* CDImode: Machine Modes. (line 205) 47673* CEIL_DIV_EXPR: Unary and Binary Expressions. 47674 (line 6) 47675* CEIL_MOD_EXPR: Unary and Binary Expressions. 47676 (line 6) 47677* ceilM2 instruction pattern: Standard Names. (line 704) 47678* CFA_FRAME_BASE_OFFSET: Frame Layout. (line 228) 47679* CFG verification: Maintaining the CFG. 47680 (line 119) 47681* CFG, Control Flow Graph: Control Flow. (line 6) 47682* cfghooks.h: Maintaining the CFG. 47683 (line 6) 47684* cgraph_finalize_function: Parsing pass. (line 52) 47685* chain_circular: GTY Options. (line 162) 47686* chain_next: GTY Options. (line 162) 47687* chain_prev: GTY Options. (line 162) 47688* change_address: Standard Names. (line 47) 47689* CHAR_TYPE_SIZE: Type Layout. (line 39) 47690* check_stack instruction pattern: Standard Names. (line 1452) 47691* CHImode: Machine Modes. (line 205) 47692* CILK_PLUS: Cilk Plus Transformation. 47693 (line 6) 47694* class definitions, register: Register Classes. (line 6) 47695* class preference constraints: Class Preferences. (line 6) 47696* class, scope: Classes. (line 6) 47697* CLASS_MAX_NREGS: Register Classes. (line 526) 47698* CLASS_TYPE_P: Types for C++. (line 65) 47699* classes of RTX codes: RTL Classes. (line 6) 47700* CLASSTYPE_DECLARED_CLASS: Classes. (line 6) 47701* CLASSTYPE_HAS_MUTABLE: Classes. (line 85) 47702* CLASSTYPE_NON_POD_P: Classes. (line 90) 47703* CLEANUP_DECL: Statements for C++. (line 6) 47704* CLEANUP_EXPR: Statements for C++. (line 6) 47705* CLEANUP_POINT_EXPR: Unary and Binary Expressions. 47706 (line 6) 47707* CLEANUP_STMT: Statements for C++. (line 6) 47708* Cleanups: Cleanups. (line 6) 47709* clear_cache instruction pattern: Standard Names. (line 1944) 47710* CLEAR_INSN_CACHE: Trampolines. (line 99) 47711* CLEAR_RATIO: Costs. (line 205) 47712* clobber: Side Effects. (line 106) 47713* clrsb: Arithmetic. (line 215) 47714* clrsbM2 instruction pattern: Standard Names. (line 769) 47715* clz: Arithmetic. (line 222) 47716* CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 305) 47717* clzM2 instruction pattern: Standard Names. (line 776) 47718* cmpmemM instruction pattern: Standard Names. (line 917) 47719* cmpstrM instruction pattern: Standard Names. (line 896) 47720* cmpstrnM instruction pattern: Standard Names. (line 883) 47721* code generation RTL sequences: Expander Definitions. 47722 (line 6) 47723* code iterators in .md files: Code Iterators. (line 6) 47724* CODE_LABEL: Basic Blocks. (line 50) 47725* code_label: Insns. (line 125) 47726* code_label and /i: Flags. (line 59) 47727* code_label and /v: Flags. (line 44) 47728* CODE_LABEL_NUMBER: Insns. (line 125) 47729* codes, RTL expression: RTL Objects. (line 47) 47730* COImode: Machine Modes. (line 205) 47731* COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32) 47732* COLLECT_EXPORT_LIST: Misc. (line 870) 47733* COLLECT_SHARED_FINI_FUNC: Macros for Initialization. 47734 (line 44) 47735* COLLECT_SHARED_INIT_FUNC: Macros for Initialization. 47736 (line 33) 47737* commit_edge_insertions: Maintaining the CFG. 47738 (line 107) 47739* compare: Arithmetic. (line 43) 47740* compare, canonicalization of: Insn Canonicalizations. 47741 (line 37) 47742* comparison_operator: Machine-Independent Predicates. 47743 (line 111) 47744* compiler passes and files: Passes. (line 6) 47745* complement, bitwise: Arithmetic. (line 153) 47746* COMPLEX_CST: Constant expressions. 47747 (line 6) 47748* COMPLEX_EXPR: Unary and Binary Expressions. 47749 (line 6) 47750* COMPLEX_TYPE: Types. (line 6) 47751* COMPONENT_REF: Storage References. (line 6) 47752* Compound Expressions: Compound Expressions. 47753 (line 6) 47754* Compound Lvalues: Compound Lvalues. (line 6) 47755* COMPOUND_EXPR: Unary and Binary Expressions. 47756 (line 6) 47757* COMPOUND_LITERAL_EXPR: Unary and Binary Expressions. 47758 (line 6) 47759* COMPOUND_LITERAL_EXPR_DECL: Unary and Binary Expressions. 47760 (line 378) 47761* COMPOUND_LITERAL_EXPR_DECL_EXPR: Unary and Binary Expressions. 47762 (line 378) 47763* computed jump: Edges. (line 128) 47764* computing the length of an insn: Insn Lengths. (line 6) 47765* concat: Regs and Memory. (line 385) 47766* concatn: Regs and Memory. (line 391) 47767* cond: Comparisons. (line 90) 47768* cond and attributes: Expressions. (line 37) 47769* cond_exec: Side Effects. (line 254) 47770* COND_EXPR: Unary and Binary Expressions. 47771 (line 6) 47772* condition code register: Regs and Memory. (line 307) 47773* condition code status: Condition Code. (line 6) 47774* condition codes: Comparisons. (line 20) 47775* conditional execution: Conditional Execution. 47776 (line 6) 47777* Conditional Expressions: Conditional Expressions. 47778 (line 6) 47779* conditions, in patterns: Patterns. (line 43) 47780* configuration file <1>: Host Misc. (line 6) 47781* configuration file: Filesystem. (line 6) 47782* configure terms: Configure Terms. (line 6) 47783* CONJ_EXPR: Unary and Binary Expressions. 47784 (line 6) 47785* const: Constants. (line 140) 47786* CONST0_RTX: Constants. (line 160) 47787* const0_rtx: Constants. (line 21) 47788* CONST1_RTX: Constants. (line 160) 47789* const1_rtx: Constants. (line 21) 47790* CONST2_RTX: Constants. (line 160) 47791* const2_rtx: Constants. (line 21) 47792* CONST_DECL: Declarations. (line 6) 47793* const_double: Constants. (line 37) 47794* const_double, RTL sharing: Sharing. (line 29) 47795* CONST_DOUBLE_LOW: Constants. (line 54) 47796* const_double_operand: Machine-Independent Predicates. 47797 (line 21) 47798* const_fixed: Constants. (line 93) 47799* const_int: Constants. (line 8) 47800* const_int and attribute tests: Expressions. (line 47) 47801* const_int and attributes: Expressions. (line 10) 47802* const_int, RTL sharing: Sharing. (line 23) 47803* const_int_operand: Machine-Independent Predicates. 47804 (line 16) 47805* const_string: Constants. (line 112) 47806* const_string and attributes: Expressions. (line 20) 47807* const_true_rtx: Constants. (line 31) 47808* const_vector: Constants. (line 100) 47809* const_vector, RTL sharing: Sharing. (line 32) 47810* CONST_WIDE_INT: Constants. (line 67) 47811* CONST_WIDE_INT_ELT: Constants. (line 89) 47812* CONST_WIDE_INT_NUNITS: Constants. (line 84) 47813* CONST_WIDE_INT_VEC: Constants. (line 80) 47814* constant attributes: Constant Attributes. 47815 (line 6) 47816* constant definitions: Constant Definitions. 47817 (line 6) 47818* CONSTANT_ADDRESS_P: Addressing Modes. (line 29) 47819* CONSTANT_ALIGNMENT: Storage Layout. (line 245) 47820* CONSTANT_P: Addressing Modes. (line 36) 47821* CONSTANT_POOL_ADDRESS_P: Flags. (line 10) 47822* CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 69) 47823* constants in constraints: Simple Constraints. (line 70) 47824* constm1_rtx: Constants. (line 21) 47825* constraint modifier characters: Modifiers. (line 6) 47826* constraint, matching: Simple Constraints. (line 142) 47827* constraint_num: C Constraint Interface. 47828 (line 31) 47829* constraint_satisfied_p: C Constraint Interface. 47830 (line 44) 47831* constraints: Constraints. (line 6) 47832* constraints, defining: Define Constraints. (line 6) 47833* constraints, machine specific: Machine Constraints. 47834 (line 6) 47835* constraints, testing: C Constraint Interface. 47836 (line 6) 47837* CONSTRUCTOR: Unary and Binary Expressions. 47838 (line 6) 47839* constructors, automatic calls: Collect2. (line 15) 47840* constructors, output of: Initialization. (line 6) 47841* container: Containers. (line 6) 47842* CONTINUE_STMT: Statements for C++. (line 6) 47843* contributors: Contributors. (line 6) 47844* controlling register usage: Register Basics. (line 73) 47845* controlling the compilation driver: Driver. (line 6) 47846* conventions, run-time: Interface. (line 6) 47847* conversions: Conversions. (line 6) 47848* CONVERT_EXPR: Unary and Binary Expressions. 47849 (line 6) 47850* copy_rtx: Addressing Modes. (line 190) 47851* copy_rtx_if_shared: Sharing. (line 64) 47852* copysignM3 instruction pattern: Standard Names. (line 750) 47853* cosM2 instruction pattern: Standard Names. (line 616) 47854* costs of instructions: Costs. (line 6) 47855* CP_INTEGRAL_TYPE: Types for C++. (line 57) 47856* cp_namespace_decls: Namespaces. (line 49) 47857* CP_TYPE_CONST_NON_VOLATILE_P: Types for C++. (line 33) 47858* CP_TYPE_CONST_P: Types for C++. (line 24) 47859* cp_type_quals: Types for C++. (line 6) 47860* CP_TYPE_RESTRICT_P: Types for C++. (line 30) 47861* CP_TYPE_VOLATILE_P: Types for C++. (line 27) 47862* CPLUSPLUS_CPP_SPEC: Driver. (line 51) 47863* CPP_SPEC: Driver. (line 44) 47864* CQImode: Machine Modes. (line 205) 47865* cross compilation and floating point: Floating Point. (line 6) 47866* CRT_CALL_STATIC_FUNCTION: Sections. (line 121) 47867* crtl->args.pops_args: Function Entry. (line 106) 47868* crtl->args.pretend_args_size: Function Entry. (line 112) 47869* crtl->outgoing_args_size: Stack Arguments. (line 48) 47870* CRTSTUFF_T_CFLAGS: Target Fragment. (line 15) 47871* CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 19) 47872* CSImode: Machine Modes. (line 205) 47873* cstoreMODE4 instruction pattern: Standard Names. (line 1124) 47874* CTImode: Machine Modes. (line 205) 47875* ctrapMM4 instruction pattern: Standard Names. (line 1606) 47876* ctz: Arithmetic. (line 230) 47877* CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 306) 47878* ctzM2 instruction pattern: Standard Names. (line 785) 47879* CUMULATIVE_ARGS: Register Arguments. (line 142) 47880* current_function_is_leaf: Leaf Functions. (line 51) 47881* current_function_uses_only_leaf_regs: Leaf Functions. (line 51) 47882* current_insn_predicate: Conditional Execution. 47883 (line 27) 47884* DAmode: Machine Modes. (line 155) 47885* data bypass: Processor pipeline description. 47886 (line 106) 47887* data dependence delays: Processor pipeline description. 47888 (line 6) 47889* Data Dependency Analysis: Dependency analysis. 47890 (line 6) 47891* data structures: Per-Function Data. (line 6) 47892* DATA_ABI_ALIGNMENT: Storage Layout. (line 237) 47893* DATA_ALIGNMENT: Storage Layout. (line 224) 47894* DATA_SECTION_ASM_OP: Sections. (line 53) 47895* DBR_OUTPUT_SEQEND: Instruction Output. (line 135) 47896* dbr_sequence_length: Instruction Output. (line 134) 47897* DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 103) 47898* DBX_CONTIN_CHAR: DBX Options. (line 66) 47899* DBX_CONTIN_LENGTH: DBX Options. (line 56) 47900* DBX_DEBUGGING_INFO: DBX Options. (line 9) 47901* DBX_FUNCTION_FIRST: DBX Options. (line 97) 47902* DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 109) 47903* DBX_NO_XREFS: DBX Options. (line 50) 47904* DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 34) 47905* DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 9) 47906* DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX. 47907 (line 42) 47908* DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 9) 47909* DBX_REGISTER_NUMBER: All Debuggers. (line 9) 47910* DBX_REGPARM_STABS_CODE: DBX Options. (line 87) 47911* DBX_REGPARM_STABS_LETTER: DBX Options. (line 92) 47912* DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 82) 47913* DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 73) 47914* DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 78) 47915* DBX_USE_BINCL: DBX Options. (line 115) 47916* DCmode: Machine Modes. (line 200) 47917* DDmode: Machine Modes. (line 93) 47918* De Morgan's law: Insn Canonicalizations. 47919 (line 52) 47920* dead_or_set_p: define_peephole. (line 65) 47921* debug_expr: Debug Information. (line 22) 47922* DEBUG_EXPR_DECL: Declarations. (line 6) 47923* debug_insn: Insns. (line 239) 47924* DEBUG_SYMS_TEXT: DBX Options. (line 25) 47925* DEBUGGER_ARG_OFFSET: All Debuggers. (line 37) 47926* DEBUGGER_AUTO_OFFSET: All Debuggers. (line 28) 47927* decimal float library: Decimal float library routines. 47928 (line 6) 47929* DECL_ALIGN: Declarations. (line 6) 47930* DECL_ANTICIPATED: Functions for C++. (line 42) 47931* DECL_ARGUMENTS: Function Basics. (line 36) 47932* DECL_ARRAY_DELETE_OPERATOR_P: Functions for C++. (line 158) 47933* DECL_ARTIFICIAL <1>: Function Properties. 47934 (line 47) 47935* DECL_ARTIFICIAL <2>: Function Basics. (line 6) 47936* DECL_ARTIFICIAL: Working with declarations. 47937 (line 24) 47938* DECL_ASSEMBLER_NAME: Function Basics. (line 6) 47939* DECL_ATTRIBUTES: Attributes. (line 22) 47940* DECL_BASE_CONSTRUCTOR_P: Functions for C++. (line 88) 47941* DECL_COMPLETE_CONSTRUCTOR_P: Functions for C++. (line 84) 47942* DECL_COMPLETE_DESTRUCTOR_P: Functions for C++. (line 98) 47943* DECL_CONST_MEMFUNC_P: Functions for C++. (line 71) 47944* DECL_CONSTRUCTOR_P: Functions for C++. (line 77) 47945* DECL_CONTEXT: Namespaces. (line 31) 47946* DECL_CONV_FN_P: Functions for C++. (line 105) 47947* DECL_COPY_CONSTRUCTOR_P: Functions for C++. (line 92) 47948* DECL_DESTRUCTOR_P: Functions for C++. (line 95) 47949* DECL_EXTERN_C_FUNCTION_P: Functions for C++. (line 46) 47950* DECL_EXTERNAL <1>: Function Properties. 47951 (line 25) 47952* DECL_EXTERNAL: Declarations. (line 6) 47953* DECL_FUNCTION_MEMBER_P: Functions for C++. (line 61) 47954* DECL_FUNCTION_SPECIFIC_OPTIMIZATION <1>: Function Properties. 47955 (line 61) 47956* DECL_FUNCTION_SPECIFIC_OPTIMIZATION: Function Basics. (line 6) 47957* DECL_FUNCTION_SPECIFIC_TARGET <1>: Function Properties. 47958 (line 55) 47959* DECL_FUNCTION_SPECIFIC_TARGET: Function Basics. (line 6) 47960* DECL_GLOBAL_CTOR_P: Functions for C++. (line 108) 47961* DECL_GLOBAL_DTOR_P: Functions for C++. (line 112) 47962* DECL_INITIAL <1>: Function Basics. (line 51) 47963* DECL_INITIAL: Declarations. (line 6) 47964* DECL_LINKONCE_P: Functions for C++. (line 50) 47965* DECL_LOCAL_FUNCTION_P: Functions for C++. (line 38) 47966* DECL_MAIN_P: Functions for C++. (line 34) 47967* DECL_NAME <1>: Namespaces. (line 20) 47968* DECL_NAME <2>: Function Basics. (line 6) 47969* DECL_NAME: Working with declarations. 47970 (line 7) 47971* DECL_NAMESPACE_ALIAS: Namespaces. (line 35) 47972* DECL_NAMESPACE_STD_P: Namespaces. (line 45) 47973* DECL_NON_THUNK_FUNCTION_P: Functions for C++. (line 138) 47974* DECL_NONCONVERTING_P: Functions for C++. (line 80) 47975* DECL_NONSTATIC_MEMBER_FUNCTION_P: Functions for C++. (line 68) 47976* DECL_OVERLOADED_OPERATOR_P: Functions for C++. (line 102) 47977* DECL_PURE_P: Function Properties. 47978 (line 40) 47979* DECL_RESULT: Function Basics. (line 41) 47980* DECL_SAVED_TREE: Function Basics. (line 44) 47981* DECL_SIZE: Declarations. (line 6) 47982* DECL_STATIC_FUNCTION_P: Functions for C++. (line 65) 47983* DECL_STMT: Statements for C++. (line 6) 47984* DECL_STMT_DECL: Statements for C++. (line 6) 47985* DECL_THUNK_P: Functions for C++. (line 116) 47986* DECL_VIRTUAL_P: Function Properties. 47987 (line 44) 47988* DECL_VOLATILE_MEMFUNC_P: Functions for C++. (line 74) 47989* declaration: Declarations. (line 6) 47990* declarations, RTL: RTL Declarations. (line 6) 47991* DECLARE_LIBRARY_RENAMES: Library Calls. (line 9) 47992* decrement_and_branch_until_zero instruction pattern: Standard Names. 47993 (line 1334) 47994* default: GTY Options. (line 88) 47995* default_file_start: File Framework. (line 8) 47996* DEFAULT_GDB_EXTENSIONS: DBX Options. (line 18) 47997* DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 35) 47998* DEFAULT_SIGNED_CHAR: Type Layout. (line 124) 47999* define_address_constraint: Define Constraints. (line 107) 48000* define_asm_attributes: Tagging Insns. (line 73) 48001* define_attr: Defining Attributes. 48002 (line 6) 48003* define_automaton: Processor pipeline description. 48004 (line 53) 48005* define_bypass: Processor pipeline description. 48006 (line 197) 48007* define_c_enum: Constant Definitions. 48008 (line 49) 48009* define_code_attr: Code Iterators. (line 6) 48010* define_code_iterator: Code Iterators. (line 6) 48011* define_cond_exec: Conditional Execution. 48012 (line 13) 48013* define_constants: Constant Definitions. 48014 (line 6) 48015* define_constraint: Define Constraints. (line 48) 48016* define_cpu_unit: Processor pipeline description. 48017 (line 68) 48018* define_delay: Delay Slots. (line 25) 48019* define_enum: Constant Definitions. 48020 (line 118) 48021* define_enum_attr <1>: Constant Definitions. 48022 (line 136) 48023* define_enum_attr: Defining Attributes. 48024 (line 83) 48025* define_expand: Expander Definitions. 48026 (line 11) 48027* define_insn: Patterns. (line 6) 48028* define_insn example: Example. (line 6) 48029* define_insn_and_split: Insn Splitting. (line 170) 48030* define_insn_reservation: Processor pipeline description. 48031 (line 106) 48032* define_int_attr: Int Iterators. (line 6) 48033* define_int_iterator: Int Iterators. (line 6) 48034* define_memory_constraint: Define Constraints. (line 88) 48035* define_mode_attr: Substitutions. (line 6) 48036* define_mode_iterator: Defining Mode Iterators. 48037 (line 6) 48038* define_peephole: define_peephole. (line 6) 48039* define_peephole2: define_peephole2. (line 6) 48040* define_predicate: Defining Predicates. 48041 (line 6) 48042* define_query_cpu_unit: Processor pipeline description. 48043 (line 90) 48044* define_register_constraint: Define Constraints. (line 28) 48045* define_reservation: Processor pipeline description. 48046 (line 186) 48047* define_special_predicate: Defining Predicates. 48048 (line 6) 48049* define_split: Insn Splitting. (line 32) 48050* define_subst <1>: Subst Iterators. (line 6) 48051* define_subst <2>: Define Subst Output Template. 48052 (line 6) 48053* define_subst <3>: Define Subst Pattern Matching. 48054 (line 6) 48055* define_subst <4>: Define Subst Example. 48056 (line 6) 48057* define_subst: Define Subst. (line 6) 48058* define_subst_attr: Subst Iterators. (line 6) 48059* defining attributes and their values: Defining Attributes. 48060 (line 6) 48061* defining constraints: Define Constraints. (line 6) 48062* defining jump instruction patterns: Jump Patterns. (line 6) 48063* defining looping instruction patterns: Looping Patterns. (line 6) 48064* defining peephole optimizers: Peephole Definitions. 48065 (line 6) 48066* defining predicates: Defining Predicates. 48067 (line 6) 48068* defining RTL sequences for code generation: Expander Definitions. 48069 (line 6) 48070* delay slots, defining: Delay Slots. (line 6) 48071* deletable: GTY Options. (line 131) 48072* DELETE_IF_ORDINARY: Filesystem. (line 79) 48073* Dependent Patterns: Dependent Patterns. (line 6) 48074* desc: GTY Options. (line 88) 48075* destructors, output of: Initialization. (line 6) 48076* deterministic finite state automaton: Processor pipeline description. 48077 (line 6) 48078* DFmode: Machine Modes. (line 76) 48079* digits in constraint: Simple Constraints. (line 130) 48080* DImode: Machine Modes. (line 45) 48081* DIR_SEPARATOR: Filesystem. (line 18) 48082* DIR_SEPARATOR_2: Filesystem. (line 19) 48083* directory options .md: Including Patterns. (line 44) 48084* disabling certain registers: Register Basics. (line 73) 48085* dispatch table: Dispatch Tables. (line 8) 48086* div: Arithmetic. (line 115) 48087* div and attributes: Expressions. (line 85) 48088* division: Arithmetic. (line 115) 48089* divM3 instruction pattern: Standard Names. (line 269) 48090* divmodM4 instruction pattern: Standard Names. (line 538) 48091* DO_BODY: Statements for C++. (line 6) 48092* DO_COND: Statements for C++. (line 6) 48093* DO_STMT: Statements for C++. (line 6) 48094* dollar sign: Multi-Alternative. (line 56) 48095* DOLLARS_IN_IDENTIFIERS: Misc. (line 454) 48096* doloop_begin instruction pattern: Standard Names. (line 1356) 48097* doloop_end instruction pattern: Standard Names. (line 1344) 48098* DONE: Expander Definitions. 48099 (line 77) 48100* DONT_USE_BUILTIN_SETJMP: Exception Region Output. 48101 (line 79) 48102* DOUBLE_TYPE_SIZE: Type Layout. (line 53) 48103* DQmode: Machine Modes. (line 118) 48104* driver: Driver. (line 6) 48105* DRIVER_SELF_SPECS: Driver. (line 9) 48106* dump examples: Dump examples. (line 6) 48107* dump setup: Dump setup. (line 6) 48108* dump types: Dump types. (line 6) 48109* dump verbosity: Dump output verbosity. 48110 (line 6) 48111* dump_basic_block: Dump types. (line 30) 48112* dump_generic_expr: Dump types. (line 33) 48113* dump_gimple_stmt: Dump types. (line 36) 48114* dump_printf: Dump types. (line 6) 48115* DUMPFILE_FORMAT: Filesystem. (line 67) 48116* DWARF2_ASM_LINE_DEBUG_INFO: SDB and DWARF. (line 50) 48117* DWARF2_DEBUGGING_INFO: SDB and DWARF. (line 13) 48118* DWARF2_FRAME_INFO: SDB and DWARF. (line 30) 48119* DWARF2_FRAME_REG_OUT: Frame Registers. (line 150) 48120* DWARF2_UNWIND_INFO: Exception Region Output. 48121 (line 40) 48122* DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 154) 48123* DWARF_CIE_DATA_ALIGNMENT: Exception Region Output. 48124 (line 91) 48125* DWARF_FRAME_REGISTERS: Frame Registers. (line 110) 48126* DWARF_FRAME_REGNUM: Frame Registers. (line 142) 48127* DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 134) 48128* DWARF_ZERO_REG: Frame Layout. (line 165) 48129* DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 92) 48130* E in constraint: Simple Constraints. (line 89) 48131* earlyclobber operand: Modifiers. (line 25) 48132* edge: Edges. (line 6) 48133* edge in the flow graph: Edges. (line 6) 48134* edge iterators: Edges. (line 15) 48135* edge splitting: Maintaining the CFG. 48136 (line 107) 48137* EDGE_ABNORMAL: Edges. (line 128) 48138* EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 172) 48139* EDGE_ABNORMAL, EDGE_EH: Edges. (line 96) 48140* EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 122) 48141* EDGE_FALLTHRU, force_nonfallthru: Edges. (line 86) 48142* EDOM, implicit usage: Library Calls. (line 59) 48143* EH_FRAME_IN_DATA_SECTION: Exception Region Output. 48144 (line 20) 48145* EH_FRAME_SECTION_NAME: Exception Region Output. 48146 (line 10) 48147* eh_return instruction pattern: Standard Names. (line 1540) 48148* EH_RETURN_DATA_REGNO: Exception Handling. (line 7) 48149* EH_RETURN_HANDLER_RTX: Exception Handling. (line 39) 48150* EH_RETURN_STACKADJ_RTX: Exception Handling. (line 22) 48151* EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output. 48152 (line 29) 48153* EH_USES: Function Entry. (line 158) 48154* ei_edge: Edges. (line 43) 48155* ei_end_p: Edges. (line 27) 48156* ei_last: Edges. (line 23) 48157* ei_next: Edges. (line 35) 48158* ei_one_before_end_p: Edges. (line 31) 48159* ei_prev: Edges. (line 39) 48160* ei_safe_safe: Edges. (line 47) 48161* ei_start: Edges. (line 19) 48162* ELIMINABLE_REGS: Elimination. (line 47) 48163* ELSE_CLAUSE: Statements for C++. (line 6) 48164* Embedded C: Fixed-point fractional library routines. 48165 (line 6) 48166* Empty Statements: Empty Statements. (line 6) 48167* EMPTY_CLASS_EXPR: Statements for C++. (line 6) 48168* EMPTY_FIELD_BOUNDARY: Storage Layout. (line 315) 48169* Emulated TLS: Emulated TLS. (line 6) 48170* enabled: Disable Insn Alternatives. 48171 (line 6) 48172* ENDFILE_SPEC: Driver. (line 156) 48173* endianness: Portability. (line 21) 48174* ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 10) 48175* enum reg_class: Register Classes. (line 72) 48176* ENUMERAL_TYPE: Types. (line 6) 48177* enumerations: Constant Definitions. 48178 (line 49) 48179* epilogue: Function Entry. (line 6) 48180* epilogue instruction pattern: Standard Names. (line 1578) 48181* EPILOGUE_USES: Function Entry. (line 152) 48182* eq: Comparisons. (line 52) 48183* eq and attributes: Expressions. (line 85) 48184* eq_attr: Expressions. (line 106) 48185* EQ_EXPR: Unary and Binary Expressions. 48186 (line 6) 48187* equal: Comparisons. (line 52) 48188* errno, implicit usage: Library Calls. (line 71) 48189* EXACT_DIV_EXPR: Unary and Binary Expressions. 48190 (line 6) 48191* examining SSA_NAMEs: SSA. (line 214) 48192* exception handling <1>: Exception Handling. (line 6) 48193* exception handling: Edges. (line 96) 48194* exception_receiver instruction pattern: Standard Names. (line 1504) 48195* exclamation point: Multi-Alternative. (line 47) 48196* exclusion_set: Processor pipeline description. 48197 (line 224) 48198* exclusive-or, bitwise: Arithmetic. (line 167) 48199* EXIT_EXPR: Unary and Binary Expressions. 48200 (line 6) 48201* EXIT_IGNORE_STACK: Function Entry. (line 140) 48202* expander definitions: Expander Definitions. 48203 (line 6) 48204* expM2 instruction pattern: Standard Names. (line 645) 48205* EXPR_FILENAME: Working with declarations. 48206 (line 14) 48207* EXPR_LINENO: Working with declarations. 48208 (line 20) 48209* expr_list: Insns. (line 548) 48210* EXPR_STMT: Statements for C++. (line 6) 48211* EXPR_STMT_EXPR: Statements for C++. (line 6) 48212* expression: Expression trees. (line 6) 48213* expression codes: RTL Objects. (line 47) 48214* extendMN2 instruction pattern: Standard Names. (line 975) 48215* extensible constraints: Simple Constraints. (line 173) 48216* EXTRA_SPECS: Driver. (line 183) 48217* extv instruction pattern: Standard Names. (line 1066) 48218* extvM instruction pattern: Standard Names. (line 1011) 48219* extvmisalignM instruction pattern: Standard Names. (line 1021) 48220* extzv instruction pattern: Standard Names. (line 1084) 48221* extzvM instruction pattern: Standard Names. (line 1035) 48222* extzvmisalignM instruction pattern: Standard Names. (line 1038) 48223* F in constraint: Simple Constraints. (line 94) 48224* FAIL: Expander Definitions. 48225 (line 83) 48226* fall-thru: Edges. (line 69) 48227* FATAL_EXIT_CODE: Host Misc. (line 6) 48228* FDL, GNU Free Documentation License: GNU Free Documentation License. 48229 (line 6) 48230* features, optional, in system conventions: Run-time Target. 48231 (line 59) 48232* ffs: Arithmetic. (line 210) 48233* ffsM2 instruction pattern: Standard Names. (line 759) 48234* FIELD_DECL: Declarations. (line 6) 48235* file_end_indicate_exec_stack: File Framework. (line 41) 48236* files and passes of the compiler: Passes. (line 6) 48237* files, generated: Files. (line 6) 48238* final_absence_set: Processor pipeline description. 48239 (line 224) 48240* FINAL_PRESCAN_INSN: Instruction Output. (line 61) 48241* final_presence_set: Processor pipeline description. 48242 (line 224) 48243* final_sequence: Instruction Output. (line 145) 48244* FIND_BASE_TERM: Addressing Modes. (line 119) 48245* FINI_ARRAY_SECTION_ASM_OP: Sections. (line 114) 48246* FINI_SECTION_ASM_OP: Sections. (line 99) 48247* finite state automaton minimization: Processor pipeline description. 48248 (line 305) 48249* FIRST_PARM_OFFSET: Frame Layout. (line 67) 48250* FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65) 48251* FIRST_PSEUDO_REGISTER: Register Basics. (line 9) 48252* FIRST_STACK_REG: Stack Registers. (line 27) 48253* FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 48254* fix: Conversions. (line 66) 48255* FIX_TRUNC_EXPR: Unary and Binary Expressions. 48256 (line 6) 48257* fix_truncMN2 instruction pattern: Standard Names. (line 962) 48258* fixed register: Register Basics. (line 15) 48259* fixed-point fractional library: Fixed-point fractional library routines. 48260 (line 6) 48261* FIXED_CONVERT_EXPR: Unary and Binary Expressions. 48262 (line 6) 48263* FIXED_CST: Constant expressions. 48264 (line 6) 48265* FIXED_POINT_TYPE: Types. (line 6) 48266* FIXED_REGISTERS: Register Basics. (line 15) 48267* fixed_regs: Register Basics. (line 59) 48268* fixMN2 instruction pattern: Standard Names. (line 942) 48269* fixuns_truncMN2 instruction pattern: Standard Names. (line 966) 48270* fixunsMN2 instruction pattern: Standard Names. (line 951) 48271* flags in RTL expression: Flags. (line 6) 48272* float: Conversions. (line 58) 48273* FLOAT_EXPR: Unary and Binary Expressions. 48274 (line 6) 48275* float_extend: Conversions. (line 33) 48276* FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 33) 48277* FLOAT_STORE_FLAG_VALUE: Misc. (line 287) 48278* float_truncate: Conversions. (line 53) 48279* FLOAT_TYPE_SIZE: Type Layout. (line 49) 48280* FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 42) 48281* FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory. 48282 (line 226) 48283* floating point and cross compilation: Floating Point. (line 6) 48284* floatMN2 instruction pattern: Standard Names. (line 934) 48285* floatunsMN2 instruction pattern: Standard Names. (line 938) 48286* FLOOR_DIV_EXPR: Unary and Binary Expressions. 48287 (line 6) 48288* FLOOR_MOD_EXPR: Unary and Binary Expressions. 48289 (line 6) 48290* floorM2 instruction pattern: Standard Names. (line 680) 48291* flow-insensitive alias analysis: Alias analysis. (line 6) 48292* flow-sensitive alias analysis: Alias analysis. (line 6) 48293* fma: Arithmetic. (line 111) 48294* fmaM4 instruction pattern: Standard Names. (line 303) 48295* fmodM3 instruction pattern: Standard Names. (line 598) 48296* fmsM4 instruction pattern: Standard Names. (line 310) 48297* fnmaM4 instruction pattern: Standard Names. (line 316) 48298* fnmsM4 instruction pattern: Standard Names. (line 322) 48299* FOR_BODY: Statements for C++. (line 6) 48300* FOR_COND: Statements for C++. (line 6) 48301* FOR_EXPR: Statements for C++. (line 6) 48302* FOR_INIT_STMT: Statements for C++. (line 6) 48303* FOR_STMT: Statements for C++. (line 6) 48304* for_user: GTY Options. (line 82) 48305* FORCE_CODE_SECTION_ALIGN: Sections. (line 145) 48306* force_reg: Standard Names. (line 36) 48307* fract_convert: Conversions. (line 82) 48308* FRACT_TYPE_SIZE: Type Layout. (line 68) 48309* fractional types: Fixed-point fractional library routines. 48310 (line 6) 48311* fractMN2 instruction pattern: Standard Names. (line 984) 48312* fractunsMN2 instruction pattern: Standard Names. (line 999) 48313* frame layout: Frame Layout. (line 6) 48314* FRAME_ADDR_RTX: Frame Layout. (line 116) 48315* FRAME_GROWS_DOWNWARD: Frame Layout. (line 31) 48316* FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory. 48317 (line 69) 48318* FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 214) 48319* frame_pointer_needed: Function Entry. (line 34) 48320* FRAME_POINTER_REGNUM: Frame Registers. (line 14) 48321* FRAME_POINTER_REGNUM and virtual registers: Regs and Memory. 48322 (line 74) 48323* frame_pointer_rtx: Frame Registers. (line 104) 48324* frame_related: Flags. (line 229) 48325* frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags. 48326 (line 107) 48327* frame_related, in mem: Flags. (line 85) 48328* frame_related, in reg: Flags. (line 94) 48329* frame_related, in symbol_ref: Flags. (line 165) 48330* frequency, count, BB_FREQ_BASE: Profile information. 48331 (line 30) 48332* ftruncM2 instruction pattern: Standard Names. (line 957) 48333* function <1>: Functions for C++. (line 6) 48334* function: Functions. (line 6) 48335* function call conventions: Interface. (line 6) 48336* function entry and exit: Function Entry. (line 6) 48337* function entry point, alternate function entry point: Edges. 48338 (line 181) 48339* function properties: Function Properties. 48340 (line 6) 48341* function-call insns: Calls. (line 6) 48342* FUNCTION_ARG_OFFSET: Register Arguments. (line 212) 48343* FUNCTION_ARG_PADDING: Register Arguments. (line 219) 48344* FUNCTION_ARG_REGNO_P: Register Arguments. (line 267) 48345* FUNCTION_BOUNDARY: Storage Layout. (line 161) 48346* FUNCTION_DECL <1>: Functions for C++. (line 6) 48347* FUNCTION_DECL: Functions. (line 6) 48348* FUNCTION_MODE: Misc. (line 342) 48349* FUNCTION_PROFILER: Profiling. (line 9) 48350* FUNCTION_TYPE: Types. (line 6) 48351* FUNCTION_VALUE: Scalar Return. (line 52) 48352* FUNCTION_VALUE_REGNO_P: Scalar Return. (line 78) 48353* functions, leaf: Leaf Functions. (line 6) 48354* fundamental type: Types. (line 6) 48355* g in constraint: Simple Constraints. (line 120) 48356* G in constraint: Simple Constraints. (line 98) 48357* garbage collector, invocation: Invoking the garbage collector. 48358 (line 6) 48359* garbage collector, troubleshooting: Troubleshooting. (line 6) 48360* GCC and portability: Portability. (line 6) 48361* GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36) 48362* gcov_type: Profile information. 48363 (line 41) 48364* ge: Comparisons. (line 72) 48365* ge and attributes: Expressions. (line 85) 48366* GE_EXPR: Unary and Binary Expressions. 48367 (line 6) 48368* GEN_ERRNO_RTX: Library Calls. (line 72) 48369* gencodes: RTL passes. (line 18) 48370* general_operand: Machine-Independent Predicates. 48371 (line 105) 48372* GENERAL_REGS: Register Classes. (line 23) 48373* generated files: Files. (line 6) 48374* generating assembler output: Output Statement. (line 6) 48375* generating insns: RTL Template. (line 6) 48376* GENERIC <1>: GENERIC. (line 6) 48377* GENERIC: Parsing pass. (line 6) 48378* generic predicates: Machine-Independent Predicates. 48379 (line 6) 48380* genflags: RTL passes. (line 18) 48381* get_attr: Expressions. (line 101) 48382* get_attr_length: Insn Lengths. (line 52) 48383* GET_CLASS_NARROWEST_MODE: Machine Modes. (line 345) 48384* GET_CODE: RTL Objects. (line 47) 48385* get_frame_size: Elimination. (line 34) 48386* get_insns: Insns. (line 34) 48387* get_last_insn: Insns. (line 34) 48388* GET_MODE: Machine Modes. (line 292) 48389* GET_MODE_ALIGNMENT: Machine Modes. (line 332) 48390* GET_MODE_BITSIZE: Machine Modes. (line 316) 48391* GET_MODE_CLASS: Machine Modes. (line 306) 48392* GET_MODE_FBIT: Machine Modes. (line 323) 48393* GET_MODE_IBIT: Machine Modes. (line 319) 48394* GET_MODE_MASK: Machine Modes. (line 327) 48395* GET_MODE_NAME: Machine Modes. (line 303) 48396* GET_MODE_NUNITS: Machine Modes. (line 341) 48397* GET_MODE_SIZE: Machine Modes. (line 313) 48398* GET_MODE_UNIT_SIZE: Machine Modes. (line 335) 48399* GET_MODE_WIDER_MODE: Machine Modes. (line 309) 48400* GET_RTX_CLASS: RTL Classes. (line 6) 48401* GET_RTX_FORMAT: RTL Classes. (line 131) 48402* GET_RTX_LENGTH: RTL Classes. (line 128) 48403* get_thread_pointerMODE instruction pattern: Standard Names. 48404 (line 1915) 48405* geu: Comparisons. (line 72) 48406* geu and attributes: Expressions. (line 85) 48407* GGC: Type Information. (line 6) 48408* ggc_collect: Invoking the garbage collector. 48409 (line 6) 48410* GIMPLE <1>: GIMPLE. (line 6) 48411* GIMPLE <2>: Gimplification pass. 48412 (line 6) 48413* GIMPLE: Parsing pass. (line 14) 48414* GIMPLE API: GIMPLE API. (line 6) 48415* GIMPLE class hierarchy: Class hierarchy of GIMPLE statements. 48416 (line 6) 48417* GIMPLE Exception Handling: GIMPLE Exception Handling. 48418 (line 6) 48419* GIMPLE instruction set: GIMPLE instruction set. 48420 (line 6) 48421* GIMPLE sequences: GIMPLE sequences. (line 6) 48422* GIMPLE statement iterators <1>: Maintaining the CFG. 48423 (line 34) 48424* GIMPLE statement iterators: Basic Blocks. (line 78) 48425* gimple_addresses_taken: Manipulating GIMPLE statements. 48426 (line 90) 48427* GIMPLE_ASM: GIMPLE_ASM. (line 6) 48428* gimple_asm_clobber_op: GIMPLE_ASM. (line 41) 48429* gimple_asm_input_op: GIMPLE_ASM. (line 25) 48430* gimple_asm_nclobbers: GIMPLE_ASM. (line 21) 48431* gimple_asm_ninputs: GIMPLE_ASM. (line 15) 48432* gimple_asm_noutputs: GIMPLE_ASM. (line 18) 48433* gimple_asm_output_op: GIMPLE_ASM. (line 33) 48434* gimple_asm_set_clobber_op: GIMPLE_ASM. (line 45) 48435* gimple_asm_set_input_op: GIMPLE_ASM. (line 29) 48436* gimple_asm_set_output_op: GIMPLE_ASM. (line 37) 48437* gimple_asm_set_volatile: GIMPLE_ASM. (line 56) 48438* gimple_asm_string: GIMPLE_ASM. (line 48) 48439* gimple_asm_volatile_p: GIMPLE_ASM. (line 52) 48440* GIMPLE_ASSIGN: GIMPLE_ASSIGN. (line 6) 48441* gimple_assign_cast_p <1>: GIMPLE_ASSIGN. (line 105) 48442* gimple_assign_cast_p: Logical Operators. (line 160) 48443* gimple_assign_lhs: GIMPLE_ASSIGN. (line 63) 48444* gimple_assign_lhs_ptr: GIMPLE_ASSIGN. (line 66) 48445* gimple_assign_rhs1: GIMPLE_ASSIGN. (line 69) 48446* gimple_assign_rhs1_ptr: GIMPLE_ASSIGN. (line 72) 48447* gimple_assign_rhs2: GIMPLE_ASSIGN. (line 76) 48448* gimple_assign_rhs2_ptr: GIMPLE_ASSIGN. (line 79) 48449* gimple_assign_rhs3: GIMPLE_ASSIGN. (line 83) 48450* gimple_assign_rhs3_ptr: GIMPLE_ASSIGN. (line 86) 48451* gimple_assign_rhs_class: GIMPLE_ASSIGN. (line 58) 48452* gimple_assign_rhs_code: GIMPLE_ASSIGN. (line 53) 48453* gimple_assign_set_lhs: GIMPLE_ASSIGN. (line 90) 48454* gimple_assign_set_rhs1: GIMPLE_ASSIGN. (line 93) 48455* gimple_assign_set_rhs2: GIMPLE_ASSIGN. (line 97) 48456* gimple_assign_set_rhs3: GIMPLE_ASSIGN. (line 101) 48457* gimple_bb: Manipulating GIMPLE statements. 48458 (line 18) 48459* GIMPLE_BIND: GIMPLE_BIND. (line 6) 48460* gimple_bind_add_seq: GIMPLE_BIND. (line 36) 48461* gimple_bind_add_stmt: GIMPLE_BIND. (line 32) 48462* gimple_bind_append_vars: GIMPLE_BIND. (line 19) 48463* gimple_bind_block: GIMPLE_BIND. (line 40) 48464* gimple_bind_body: GIMPLE_BIND. (line 23) 48465* gimple_bind_set_block: GIMPLE_BIND. (line 45) 48466* gimple_bind_set_body: GIMPLE_BIND. (line 28) 48467* gimple_bind_set_vars: GIMPLE_BIND. (line 15) 48468* gimple_bind_vars: GIMPLE_BIND. (line 12) 48469* gimple_block: Manipulating GIMPLE statements. 48470 (line 21) 48471* gimple_build: GIMPLE API. (line 36) 48472* gimple_build_nop: GIMPLE_NOP. (line 7) 48473* gimple_build_omp_master: GIMPLE_OMP_MASTER. (line 7) 48474* gimple_build_omp_ordered: GIMPLE_OMP_ORDERED. (line 7) 48475* gimple_build_omp_return: GIMPLE_OMP_RETURN. (line 7) 48476* gimple_build_omp_section: GIMPLE_OMP_SECTION. (line 7) 48477* gimple_build_omp_sections_switch: GIMPLE_OMP_SECTIONS. 48478 (line 14) 48479* gimple_build_wce: GIMPLE_WITH_CLEANUP_EXPR. 48480 (line 7) 48481* GIMPLE_CALL: GIMPLE_CALL. (line 6) 48482* gimple_call_arg: GIMPLE_CALL. (line 66) 48483* gimple_call_arg_ptr: GIMPLE_CALL. (line 71) 48484* gimple_call_chain: GIMPLE_CALL. (line 57) 48485* gimple_call_copy_skip_args: GIMPLE_CALL. (line 92) 48486* gimple_call_fn: GIMPLE_CALL. (line 38) 48487* gimple_call_fndecl: GIMPLE_CALL. (line 46) 48488* gimple_call_lhs: GIMPLE_CALL. (line 29) 48489* gimple_call_lhs_ptr: GIMPLE_CALL. (line 32) 48490* gimple_call_noreturn_p: GIMPLE_CALL. (line 88) 48491* gimple_call_num_args: GIMPLE_CALL. (line 63) 48492* gimple_call_return_type: GIMPLE_CALL. (line 54) 48493* gimple_call_set_arg: GIMPLE_CALL. (line 76) 48494* gimple_call_set_chain: GIMPLE_CALL. (line 60) 48495* gimple_call_set_fn: GIMPLE_CALL. (line 42) 48496* gimple_call_set_fndecl: GIMPLE_CALL. (line 51) 48497* gimple_call_set_lhs: GIMPLE_CALL. (line 35) 48498* gimple_call_set_tail: GIMPLE_CALL. (line 80) 48499* gimple_call_tail_p: GIMPLE_CALL. (line 85) 48500* GIMPLE_CATCH: GIMPLE_CATCH. (line 6) 48501* gimple_catch_handler: GIMPLE_CATCH. (line 20) 48502* gimple_catch_set_handler: GIMPLE_CATCH. (line 28) 48503* gimple_catch_set_types: GIMPLE_CATCH. (line 24) 48504* gimple_catch_types: GIMPLE_CATCH. (line 13) 48505* gimple_catch_types_ptr: GIMPLE_CATCH. (line 16) 48506* gimple_code: Manipulating GIMPLE statements. 48507 (line 15) 48508* GIMPLE_COND: GIMPLE_COND. (line 6) 48509* gimple_cond_code: GIMPLE_COND. (line 21) 48510* gimple_cond_false_label: GIMPLE_COND. (line 60) 48511* gimple_cond_lhs: GIMPLE_COND. (line 30) 48512* gimple_cond_make_false: GIMPLE_COND. (line 64) 48513* gimple_cond_make_true: GIMPLE_COND. (line 67) 48514* gimple_cond_rhs: GIMPLE_COND. (line 38) 48515* gimple_cond_set_code: GIMPLE_COND. (line 26) 48516* gimple_cond_set_false_label: GIMPLE_COND. (line 56) 48517* gimple_cond_set_lhs: GIMPLE_COND. (line 34) 48518* gimple_cond_set_rhs: GIMPLE_COND. (line 42) 48519* gimple_cond_set_true_label: GIMPLE_COND. (line 51) 48520* gimple_cond_true_label: GIMPLE_COND. (line 46) 48521* gimple_convert: GIMPLE API. (line 49) 48522* gimple_copy: Manipulating GIMPLE statements. 48523 (line 147) 48524* GIMPLE_DEBUG: GIMPLE_DEBUG. (line 6) 48525* GIMPLE_DEBUG_BIND: GIMPLE_DEBUG. (line 6) 48526* gimple_debug_bind_get_value: GIMPLE_DEBUG. (line 48) 48527* gimple_debug_bind_get_value_ptr: GIMPLE_DEBUG. (line 53) 48528* gimple_debug_bind_get_var: GIMPLE_DEBUG. (line 45) 48529* gimple_debug_bind_has_value_p: GIMPLE_DEBUG. (line 70) 48530* gimple_debug_bind_p: Logical Operators. (line 164) 48531* gimple_debug_bind_reset_value: GIMPLE_DEBUG. (line 66) 48532* gimple_debug_bind_set_value: GIMPLE_DEBUG. (line 62) 48533* gimple_debug_bind_set_var: GIMPLE_DEBUG. (line 58) 48534* gimple_def_ops: Manipulating GIMPLE statements. 48535 (line 94) 48536* GIMPLE_EH_FILTER: GIMPLE_EH_FILTER. (line 6) 48537* gimple_eh_filter_failure: GIMPLE_EH_FILTER. (line 19) 48538* gimple_eh_filter_set_failure: GIMPLE_EH_FILTER. (line 29) 48539* gimple_eh_filter_set_types: GIMPLE_EH_FILTER. (line 24) 48540* gimple_eh_filter_types: GIMPLE_EH_FILTER. (line 12) 48541* gimple_eh_filter_types_ptr: GIMPLE_EH_FILTER. (line 15) 48542* gimple_eh_must_not_throw_fndecl: GIMPLE_EH_FILTER. (line 34) 48543* gimple_eh_must_not_throw_set_fndecl: GIMPLE_EH_FILTER. (line 38) 48544* gimple_expr_code: Manipulating GIMPLE statements. 48545 (line 31) 48546* gimple_expr_type: Manipulating GIMPLE statements. 48547 (line 24) 48548* GIMPLE_GOTO: GIMPLE_GOTO. (line 6) 48549* gimple_goto_dest: GIMPLE_GOTO. (line 10) 48550* gimple_goto_set_dest: GIMPLE_GOTO. (line 13) 48551* gimple_has_mem_ops: Manipulating GIMPLE statements. 48552 (line 72) 48553* gimple_has_ops: Manipulating GIMPLE statements. 48554 (line 69) 48555* gimple_has_volatile_ops: Manipulating GIMPLE statements. 48556 (line 134) 48557* GIMPLE_LABEL: GIMPLE_LABEL. (line 6) 48558* gimple_label_label: GIMPLE_LABEL. (line 11) 48559* gimple_label_set_label: GIMPLE_LABEL. (line 14) 48560* gimple_loaded_syms: Manipulating GIMPLE statements. 48561 (line 122) 48562* gimple_locus: Manipulating GIMPLE statements. 48563 (line 42) 48564* gimple_locus_empty_p: Manipulating GIMPLE statements. 48565 (line 48) 48566* gimple_modified_p: Manipulating GIMPLE statements. 48567 (line 130) 48568* gimple_no_warning_p: Manipulating GIMPLE statements. 48569 (line 51) 48570* GIMPLE_NOP: GIMPLE_NOP. (line 6) 48571* gimple_nop_p: GIMPLE_NOP. (line 10) 48572* gimple_num_ops <1>: Manipulating GIMPLE statements. 48573 (line 75) 48574* gimple_num_ops: Logical Operators. (line 78) 48575* GIMPLE_OMP_ATOMIC_LOAD: GIMPLE_OMP_ATOMIC_LOAD. 48576 (line 6) 48577* gimple_omp_atomic_load_lhs: GIMPLE_OMP_ATOMIC_LOAD. 48578 (line 18) 48579* gimple_omp_atomic_load_rhs: GIMPLE_OMP_ATOMIC_LOAD. 48580 (line 26) 48581* gimple_omp_atomic_load_set_lhs: GIMPLE_OMP_ATOMIC_LOAD. 48582 (line 14) 48583* gimple_omp_atomic_load_set_rhs: GIMPLE_OMP_ATOMIC_LOAD. 48584 (line 22) 48585* GIMPLE_OMP_ATOMIC_STORE: GIMPLE_OMP_ATOMIC_STORE. 48586 (line 6) 48587* gimple_omp_atomic_store_set_val: GIMPLE_OMP_ATOMIC_STORE. 48588 (line 13) 48589* gimple_omp_atomic_store_val: GIMPLE_OMP_ATOMIC_STORE. 48590 (line 17) 48591* gimple_omp_body: GIMPLE_OMP_PARALLEL. 48592 (line 24) 48593* GIMPLE_OMP_CONTINUE: GIMPLE_OMP_CONTINUE. 48594 (line 6) 48595* gimple_omp_continue_control_def: GIMPLE_OMP_CONTINUE. 48596 (line 14) 48597* gimple_omp_continue_control_def_ptr: GIMPLE_OMP_CONTINUE. 48598 (line 19) 48599* gimple_omp_continue_control_use: GIMPLE_OMP_CONTINUE. 48600 (line 28) 48601* gimple_omp_continue_control_use_ptr: GIMPLE_OMP_CONTINUE. 48602 (line 33) 48603* gimple_omp_continue_set_control_def: GIMPLE_OMP_CONTINUE. 48604 (line 23) 48605* gimple_omp_continue_set_control_use: GIMPLE_OMP_CONTINUE. 48606 (line 37) 48607* GIMPLE_OMP_CRITICAL: GIMPLE_OMP_CRITICAL. 48608 (line 6) 48609* gimple_omp_critical_name: GIMPLE_OMP_CRITICAL. 48610 (line 14) 48611* gimple_omp_critical_name_ptr: GIMPLE_OMP_CRITICAL. 48612 (line 18) 48613* gimple_omp_critical_set_name: GIMPLE_OMP_CRITICAL. 48614 (line 23) 48615* GIMPLE_OMP_FOR: GIMPLE_OMP_FOR. (line 6) 48616* gimple_omp_for_clauses: GIMPLE_OMP_FOR. (line 18) 48617* gimple_omp_for_clauses_ptr: GIMPLE_OMP_FOR. (line 21) 48618* gimple_omp_for_cond: GIMPLE_OMP_FOR. (line 81) 48619* gimple_omp_for_final: GIMPLE_OMP_FOR. (line 49) 48620* gimple_omp_for_final_ptr: GIMPLE_OMP_FOR. (line 52) 48621* gimple_omp_for_incr: GIMPLE_OMP_FOR. (line 59) 48622* gimple_omp_for_incr_ptr: GIMPLE_OMP_FOR. (line 62) 48623* gimple_omp_for_index: GIMPLE_OMP_FOR. (line 29) 48624* gimple_omp_for_index_ptr: GIMPLE_OMP_FOR. (line 32) 48625* gimple_omp_for_initial: GIMPLE_OMP_FOR. (line 39) 48626* gimple_omp_for_initial_ptr: GIMPLE_OMP_FOR. (line 42) 48627* gimple_omp_for_pre_body: GIMPLE_OMP_FOR. (line 68) 48628* gimple_omp_for_set_clauses: GIMPLE_OMP_FOR. (line 25) 48629* gimple_omp_for_set_cond: GIMPLE_OMP_FOR. (line 78) 48630* gimple_omp_for_set_final: GIMPLE_OMP_FOR. (line 56) 48631* gimple_omp_for_set_incr: GIMPLE_OMP_FOR. (line 65) 48632* gimple_omp_for_set_index: GIMPLE_OMP_FOR. (line 36) 48633* gimple_omp_for_set_initial: GIMPLE_OMP_FOR. (line 46) 48634* gimple_omp_for_set_pre_body: GIMPLE_OMP_FOR. (line 73) 48635* GIMPLE_OMP_MASTER: GIMPLE_OMP_MASTER. (line 6) 48636* GIMPLE_OMP_ORDERED: GIMPLE_OMP_ORDERED. (line 6) 48637* GIMPLE_OMP_PARALLEL: GIMPLE_OMP_PARALLEL. 48638 (line 6) 48639* gimple_omp_parallel_child_fn: GIMPLE_OMP_PARALLEL. 48640 (line 44) 48641* gimple_omp_parallel_child_fn_ptr: GIMPLE_OMP_PARALLEL. 48642 (line 49) 48643* gimple_omp_parallel_clauses: GIMPLE_OMP_PARALLEL. 48644 (line 31) 48645* gimple_omp_parallel_clauses_ptr: GIMPLE_OMP_PARALLEL. 48646 (line 35) 48647* gimple_omp_parallel_combined_p: GIMPLE_OMP_PARALLEL. 48648 (line 16) 48649* gimple_omp_parallel_data_arg: GIMPLE_OMP_PARALLEL. 48650 (line 58) 48651* gimple_omp_parallel_data_arg_ptr: GIMPLE_OMP_PARALLEL. 48652 (line 63) 48653* gimple_omp_parallel_set_child_fn: GIMPLE_OMP_PARALLEL. 48654 (line 54) 48655* gimple_omp_parallel_set_clauses: GIMPLE_OMP_PARALLEL. 48656 (line 39) 48657* gimple_omp_parallel_set_combined_p: GIMPLE_OMP_PARALLEL. 48658 (line 20) 48659* gimple_omp_parallel_set_data_arg: GIMPLE_OMP_PARALLEL. 48660 (line 67) 48661* GIMPLE_OMP_RETURN: GIMPLE_OMP_RETURN. (line 6) 48662* gimple_omp_return_nowait_p: GIMPLE_OMP_RETURN. (line 14) 48663* gimple_omp_return_set_nowait: GIMPLE_OMP_RETURN. (line 11) 48664* GIMPLE_OMP_SECTION: GIMPLE_OMP_SECTION. (line 6) 48665* gimple_omp_section_last_p: GIMPLE_OMP_SECTION. (line 12) 48666* gimple_omp_section_set_last: GIMPLE_OMP_SECTION. (line 16) 48667* GIMPLE_OMP_SECTIONS: GIMPLE_OMP_SECTIONS. 48668 (line 6) 48669* gimple_omp_sections_clauses: GIMPLE_OMP_SECTIONS. 48670 (line 30) 48671* gimple_omp_sections_clauses_ptr: GIMPLE_OMP_SECTIONS. 48672 (line 33) 48673* gimple_omp_sections_control: GIMPLE_OMP_SECTIONS. 48674 (line 17) 48675* gimple_omp_sections_control_ptr: GIMPLE_OMP_SECTIONS. 48676 (line 21) 48677* gimple_omp_sections_set_clauses: GIMPLE_OMP_SECTIONS. 48678 (line 37) 48679* gimple_omp_sections_set_control: GIMPLE_OMP_SECTIONS. 48680 (line 26) 48681* gimple_omp_set_body: GIMPLE_OMP_PARALLEL. 48682 (line 28) 48683* GIMPLE_OMP_SINGLE: GIMPLE_OMP_SINGLE. (line 6) 48684* gimple_omp_single_clauses: GIMPLE_OMP_SINGLE. (line 14) 48685* gimple_omp_single_clauses_ptr: GIMPLE_OMP_SINGLE. (line 17) 48686* gimple_omp_single_set_clauses: GIMPLE_OMP_SINGLE. (line 21) 48687* gimple_op <1>: Manipulating GIMPLE statements. 48688 (line 81) 48689* gimple_op: Logical Operators. (line 81) 48690* gimple_op_ptr: Manipulating GIMPLE statements. 48691 (line 84) 48692* gimple_ops <1>: Manipulating GIMPLE statements. 48693 (line 78) 48694* gimple_ops: Logical Operators. (line 84) 48695* GIMPLE_PHI: GIMPLE_PHI. (line 6) 48696* gimple_phi_arg <1>: SSA. (line 63) 48697* gimple_phi_arg: GIMPLE_PHI. (line 25) 48698* gimple_phi_arg_def: SSA. (line 69) 48699* gimple_phi_arg_edge: SSA. (line 66) 48700* gimple_phi_capacity: GIMPLE_PHI. (line 7) 48701* gimple_phi_num_args <1>: SSA. (line 59) 48702* gimple_phi_num_args: GIMPLE_PHI. (line 11) 48703* gimple_phi_result <1>: SSA. (line 56) 48704* gimple_phi_result: GIMPLE_PHI. (line 16) 48705* gimple_phi_result_ptr: GIMPLE_PHI. (line 19) 48706* gimple_phi_set_arg: GIMPLE_PHI. (line 30) 48707* gimple_phi_set_result: GIMPLE_PHI. (line 22) 48708* gimple_plf: Manipulating GIMPLE statements. 48709 (line 66) 48710* GIMPLE_RESX: GIMPLE_RESX. (line 6) 48711* gimple_resx_region: GIMPLE_RESX. (line 13) 48712* gimple_resx_set_region: GIMPLE_RESX. (line 16) 48713* GIMPLE_RETURN: GIMPLE_RETURN. (line 6) 48714* gimple_return_retval: GIMPLE_RETURN. (line 10) 48715* gimple_return_set_retval: GIMPLE_RETURN. (line 14) 48716* gimple_seq_add_seq: GIMPLE sequences. (line 32) 48717* gimple_seq_add_stmt: GIMPLE sequences. (line 26) 48718* gimple_seq_alloc: GIMPLE sequences. (line 62) 48719* gimple_seq_copy: GIMPLE sequences. (line 67) 48720* gimple_seq_deep_copy: GIMPLE sequences. (line 37) 48721* gimple_seq_empty_p: GIMPLE sequences. (line 70) 48722* gimple_seq_first: GIMPLE sequences. (line 44) 48723* gimple_seq_init: GIMPLE sequences. (line 59) 48724* gimple_seq_last: GIMPLE sequences. (line 47) 48725* gimple_seq_reverse: GIMPLE sequences. (line 40) 48726* gimple_seq_set_first: GIMPLE sequences. (line 55) 48727* gimple_seq_set_last: GIMPLE sequences. (line 51) 48728* gimple_seq_singleton_p: GIMPLE sequences. (line 79) 48729* gimple_set_block: Manipulating GIMPLE statements. 48730 (line 39) 48731* gimple_set_def_ops: Manipulating GIMPLE statements. 48732 (line 98) 48733* gimple_set_has_volatile_ops: Manipulating GIMPLE statements. 48734 (line 138) 48735* gimple_set_locus: Manipulating GIMPLE statements. 48736 (line 45) 48737* gimple_set_op: Manipulating GIMPLE statements. 48738 (line 87) 48739* gimple_set_plf: Manipulating GIMPLE statements. 48740 (line 62) 48741* gimple_set_use_ops: Manipulating GIMPLE statements. 48742 (line 105) 48743* gimple_set_vdef_ops: Manipulating GIMPLE statements. 48744 (line 119) 48745* gimple_set_visited: Manipulating GIMPLE statements. 48746 (line 55) 48747* gimple_set_vuse_ops: Manipulating GIMPLE statements. 48748 (line 112) 48749* gimple_simplify: GIMPLE API. (line 8) 48750* gimple_statement_base: Tuple representation. 48751 (line 14) 48752* gimple_statement_with_ops: Tuple representation. 48753 (line 96) 48754* gimple_stored_syms: Manipulating GIMPLE statements. 48755 (line 126) 48756* GIMPLE_SWITCH: GIMPLE_SWITCH. (line 6) 48757* gimple_switch_default_label: GIMPLE_SWITCH. (line 43) 48758* gimple_switch_index: GIMPLE_SWITCH. (line 25) 48759* gimple_switch_label: GIMPLE_SWITCH. (line 33) 48760* gimple_switch_num_labels: GIMPLE_SWITCH. (line 16) 48761* gimple_switch_set_default_label: GIMPLE_SWITCH. (line 47) 48762* gimple_switch_set_index: GIMPLE_SWITCH. (line 29) 48763* gimple_switch_set_label: GIMPLE_SWITCH. (line 38) 48764* gimple_switch_set_num_labels: GIMPLE_SWITCH. (line 21) 48765* GIMPLE_TRY: GIMPLE_TRY. (line 6) 48766* gimple_try_catch_is_cleanup: GIMPLE_TRY. (line 20) 48767* gimple_try_cleanup: GIMPLE_TRY. (line 27) 48768* gimple_try_eval: GIMPLE_TRY. (line 23) 48769* gimple_try_kind: GIMPLE_TRY. (line 16) 48770* gimple_try_set_catch_is_cleanup: GIMPLE_TRY. (line 32) 48771* gimple_try_set_cleanup: GIMPLE_TRY. (line 40) 48772* gimple_try_set_eval: GIMPLE_TRY. (line 35) 48773* gimple_use_ops: Manipulating GIMPLE statements. 48774 (line 101) 48775* gimple_vdef_ops: Manipulating GIMPLE statements. 48776 (line 115) 48777* gimple_visited_p: Manipulating GIMPLE statements. 48778 (line 58) 48779* gimple_vuse_ops: Manipulating GIMPLE statements. 48780 (line 108) 48781* gimple_wce_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 48782 (line 11) 48783* gimple_wce_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 48784 (line 18) 48785* gimple_wce_set_cleanup: GIMPLE_WITH_CLEANUP_EXPR. 48786 (line 15) 48787* gimple_wce_set_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR. 48788 (line 22) 48789* GIMPLE_WITH_CLEANUP_EXPR: GIMPLE_WITH_CLEANUP_EXPR. 48790 (line 6) 48791* gimplification <1>: Gimplification pass. 48792 (line 6) 48793* gimplification: Parsing pass. (line 14) 48794* gimplifier: Parsing pass. (line 14) 48795* gimplify_assign: GIMPLE_ASSIGN. (line 43) 48796* gimplify_expr: Gimplification pass. 48797 (line 18) 48798* gimplify_function_tree: Gimplification pass. 48799 (line 18) 48800* GLOBAL_INIT_PRIORITY: Functions for C++. (line 141) 48801* global_regs: Register Basics. (line 59) 48802* GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 91) 48803* greater than: Comparisons. (line 60) 48804* gsi_after_labels: Sequence iterators. (line 76) 48805* gsi_bb: Sequence iterators. (line 83) 48806* gsi_commit_edge_inserts <1>: Maintaining the CFG. 48807 (line 107) 48808* gsi_commit_edge_inserts: Sequence iterators. (line 194) 48809* gsi_commit_one_edge_insert: Sequence iterators. (line 190) 48810* gsi_end_p <1>: Maintaining the CFG. 48811 (line 49) 48812* gsi_end_p: Sequence iterators. (line 60) 48813* gsi_for_stmt: Sequence iterators. (line 157) 48814* gsi_insert_after <1>: Maintaining the CFG. 48815 (line 61) 48816* gsi_insert_after: Sequence iterators. (line 147) 48817* gsi_insert_before <1>: Maintaining the CFG. 48818 (line 67) 48819* gsi_insert_before: Sequence iterators. (line 136) 48820* gsi_insert_on_edge <1>: Maintaining the CFG. 48821 (line 107) 48822* gsi_insert_on_edge: Sequence iterators. (line 174) 48823* gsi_insert_on_edge_immediate: Sequence iterators. (line 185) 48824* gsi_insert_seq_after: Sequence iterators. (line 154) 48825* gsi_insert_seq_before: Sequence iterators. (line 143) 48826* gsi_insert_seq_on_edge: Sequence iterators. (line 179) 48827* gsi_last <1>: Maintaining the CFG. 48828 (line 45) 48829* gsi_last: Sequence iterators. (line 50) 48830* gsi_last_bb: Sequence iterators. (line 56) 48831* gsi_link_after: Sequence iterators. (line 115) 48832* gsi_link_before: Sequence iterators. (line 105) 48833* gsi_link_seq_after: Sequence iterators. (line 110) 48834* gsi_link_seq_before: Sequence iterators. (line 99) 48835* gsi_move_after: Sequence iterators. (line 161) 48836* gsi_move_before: Sequence iterators. (line 166) 48837* gsi_move_to_bb_end: Sequence iterators. (line 171) 48838* gsi_next <1>: Maintaining the CFG. 48839 (line 53) 48840* gsi_next: Sequence iterators. (line 66) 48841* gsi_one_before_end_p: Sequence iterators. (line 63) 48842* gsi_prev <1>: Maintaining the CFG. 48843 (line 57) 48844* gsi_prev: Sequence iterators. (line 69) 48845* gsi_remove <1>: Maintaining the CFG. 48846 (line 73) 48847* gsi_remove: Sequence iterators. (line 90) 48848* gsi_replace: Sequence iterators. (line 130) 48849* gsi_seq: Sequence iterators. (line 86) 48850* gsi_split_seq_after: Sequence iterators. (line 120) 48851* gsi_split_seq_before: Sequence iterators. (line 125) 48852* gsi_start <1>: Maintaining the CFG. 48853 (line 41) 48854* gsi_start: Sequence iterators. (line 40) 48855* gsi_start_bb: Sequence iterators. (line 46) 48856* gsi_stmt: Sequence iterators. (line 72) 48857* gsi_stmt_ptr: Sequence iterators. (line 80) 48858* gt: Comparisons. (line 60) 48859* gt and attributes: Expressions. (line 85) 48860* GT_EXPR: Unary and Binary Expressions. 48861 (line 6) 48862* gtu: Comparisons. (line 64) 48863* gtu and attributes: Expressions. (line 85) 48864* GTY: Type Information. (line 6) 48865* H in constraint: Simple Constraints. (line 98) 48866* HAmode: Machine Modes. (line 147) 48867* HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 444) 48868* HANDLER: Statements for C++. (line 6) 48869* HANDLER_BODY: Statements for C++. (line 6) 48870* HANDLER_PARMS: Statements for C++. (line 6) 48871* hard registers: Regs and Memory. (line 9) 48872* HARD_FRAME_POINTER_IS_ARG_POINTER: Frame Registers. (line 58) 48873* HARD_FRAME_POINTER_IS_FRAME_POINTER: Frame Registers. (line 51) 48874* HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 20) 48875* HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 53) 48876* HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 11) 48877* HARD_REGNO_MODE_OK: Values in Registers. 48878 (line 58) 48879* HARD_REGNO_NREGS: Values in Registers. 48880 (line 11) 48881* HARD_REGNO_NREGS_HAS_PADDING: Values in Registers. 48882 (line 25) 48883* HARD_REGNO_NREGS_WITH_PADDING: Values in Registers. 48884 (line 43) 48885* HARD_REGNO_RENAME_OK: Values in Registers. 48886 (line 119) 48887* HAS_INIT_SECTION: Macros for Initialization. 48888 (line 19) 48889* HAS_LONG_COND_BRANCH: Misc. (line 9) 48890* HAS_LONG_UNCOND_BRANCH: Misc. (line 18) 48891* HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11) 48892* HAVE_POST_DECREMENT: Addressing Modes. (line 12) 48893* HAVE_POST_INCREMENT: Addressing Modes. (line 11) 48894* HAVE_POST_MODIFY_DISP: Addressing Modes. (line 18) 48895* HAVE_POST_MODIFY_REG: Addressing Modes. (line 24) 48896* HAVE_PRE_DECREMENT: Addressing Modes. (line 10) 48897* HAVE_PRE_INCREMENT: Addressing Modes. (line 9) 48898* HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 17) 48899* HAVE_PRE_MODIFY_REG: Addressing Modes. (line 23) 48900* HCmode: Machine Modes. (line 200) 48901* HFmode: Machine Modes. (line 61) 48902* high: Constants. (line 150) 48903* HImode: Machine Modes. (line 29) 48904* HImode, in insn: Insns. (line 272) 48905* HONOR_REG_ALLOC_ORDER: Allocation Order. (line 37) 48906* host configuration: Host Config. (line 6) 48907* host functions: Host Common. (line 6) 48908* host hooks: Host Common. (line 6) 48909* host makefile fragment: Host Fragment. (line 6) 48910* HOST_BIT_BUCKET: Filesystem. (line 51) 48911* HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45) 48912* HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 12) 48913* HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 45) 48914* HOST_HOOKS_GT_PCH_GET_ADDRESS: Host Common. (line 17) 48915* HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 26) 48916* HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89) 48917* HOST_LONG_FORMAT: Host Misc. (line 45) 48918* HOST_LONG_LONG_FORMAT: Host Misc. (line 41) 48919* HOST_OBJECT_SUFFIX: Filesystem. (line 40) 48920* HOST_PTR_PRINTF: Host Misc. (line 49) 48921* HOT_TEXT_SECTION_NAME: Sections. (line 43) 48922* HQmode: Machine Modes. (line 110) 48923* I in constraint: Simple Constraints. (line 81) 48924* i in constraint: Simple Constraints. (line 70) 48925* identifier: Identifiers. (line 6) 48926* IDENTIFIER_LENGTH: Identifiers. (line 22) 48927* IDENTIFIER_NODE: Identifiers. (line 6) 48928* IDENTIFIER_OPNAME_P: Identifiers. (line 27) 48929* IDENTIFIER_POINTER: Identifiers. (line 17) 48930* IDENTIFIER_TYPENAME_P: Identifiers. (line 33) 48931* IEEE 754-2008: Decimal float library routines. 48932 (line 6) 48933* IF_COND: Statements for C++. (line 6) 48934* IF_STMT: Statements for C++. (line 6) 48935* if_then_else: Comparisons. (line 80) 48936* if_then_else and attributes: Expressions. (line 32) 48937* if_then_else usage: Side Effects. (line 56) 48938* IFCVT_MACHDEP_INIT: Misc. (line 568) 48939* IFCVT_MODIFY_CANCEL: Misc. (line 562) 48940* IFCVT_MODIFY_FINAL: Misc. (line 556) 48941* IFCVT_MODIFY_INSN: Misc. (line 550) 48942* IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 543) 48943* IFCVT_MODIFY_TESTS: Misc. (line 532) 48944* IMAGPART_EXPR: Unary and Binary Expressions. 48945 (line 6) 48946* Immediate Uses: SSA Operands. (line 261) 48947* immediate_operand: Machine-Independent Predicates. 48948 (line 11) 48949* IMMEDIATE_PREFIX: Instruction Output. (line 155) 48950* in_struct: Flags. (line 245) 48951* in_struct, in code_label and note: Flags. (line 59) 48952* in_struct, in insn and jump_insn and call_insn: Flags. (line 49) 48953* in_struct, in insn, call_insn, jump_insn and jump_table_data: Flags. 48954 (line 148) 48955* in_struct, in subreg: Flags. (line 187) 48956* include: Including Patterns. (line 6) 48957* INCLUDE_DEFAULTS: Driver. (line 328) 48958* inclusive-or, bitwise: Arithmetic. (line 162) 48959* INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 185) 48960* INCOMING_REG_PARM_STACK_SPACE: Stack Arguments. (line 74) 48961* INCOMING_REGNO: Register Basics. (line 87) 48962* INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 141) 48963* INCOMING_STACK_BOUNDARY: Storage Layout. (line 156) 48964* INDEX_REG_CLASS: Register Classes. (line 143) 48965* indirect_jump instruction pattern: Standard Names. (line 1292) 48966* indirect_operand: Machine-Independent Predicates. 48967 (line 71) 48968* INDIRECT_REF: Storage References. (line 6) 48969* INIT_ARRAY_SECTION_ASM_OP: Sections. (line 107) 48970* INIT_CUMULATIVE_ARGS: Register Arguments. (line 164) 48971* INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 191) 48972* INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 185) 48973* INIT_ENVIRONMENT: Driver. (line 306) 48974* INIT_EXPANDERS: Per-Function Data. (line 39) 48975* INIT_EXPR: Unary and Binary Expressions. 48976 (line 6) 48977* init_machine_status: Per-Function Data. (line 45) 48978* init_one_libfunc: Library Calls. (line 15) 48979* INIT_SECTION_ASM_OP <1>: Macros for Initialization. 48980 (line 10) 48981* INIT_SECTION_ASM_OP: Sections. (line 91) 48982* INITIAL_ELIMINATION_OFFSET: Elimination. (line 85) 48983* INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 83) 48984* INITIAL_FRAME_POINTER_OFFSET: Elimination. (line 35) 48985* initialization routines: Initialization. (line 6) 48986* inlining: Target Attributes. (line 95) 48987* insert_insn_on_edge: Maintaining the CFG. 48988 (line 107) 48989* insn: Insns. (line 63) 48990* insn and /f: Flags. (line 107) 48991* insn and /j: Flags. (line 157) 48992* insn and /s: Flags. (line 49) 48993* insn and /u: Flags. (line 39) 48994* insn and /v: Flags. (line 44) 48995* insn attributes: Insn Attributes. (line 6) 48996* insn canonicalization: Insn Canonicalizations. 48997 (line 6) 48998* insn includes: Including Patterns. (line 6) 48999* insn lengths, computing: Insn Lengths. (line 6) 49000* insn notes, notes: Basic Blocks. (line 52) 49001* insn splitting: Insn Splitting. (line 6) 49002* insn-attr.h: Defining Attributes. 49003 (line 34) 49004* INSN_ANNULLED_BRANCH_P: Flags. (line 39) 49005* INSN_CODE: Insns. (line 299) 49006* INSN_DELETED_P: Flags. (line 44) 49007* INSN_FROM_TARGET_P: Flags. (line 49) 49008* insn_list: Insns. (line 548) 49009* INSN_REFERENCES_ARE_DELAYED: Misc. (line 471) 49010* INSN_SETS_ARE_DELAYED: Misc. (line 460) 49011* INSN_UID: Insns. (line 23) 49012* INSN_VAR_LOCATION: Insns. (line 239) 49013* insns: Insns. (line 6) 49014* insns, generating: RTL Template. (line 6) 49015* insns, recognizing: RTL Template. (line 6) 49016* instruction attributes: Insn Attributes. (line 6) 49017* instruction latency time: Processor pipeline description. 49018 (line 6) 49019* instruction patterns: Patterns. (line 6) 49020* instruction splitting: Insn Splitting. (line 6) 49021* insv instruction pattern: Standard Names. (line 1090) 49022* insvM instruction pattern: Standard Names. (line 1042) 49023* insvmisalignM instruction pattern: Standard Names. (line 1052) 49024* int iterators in .md files: Int Iterators. (line 6) 49025* INT16_TYPE: Type Layout. (line 217) 49026* INT32_TYPE: Type Layout. (line 218) 49027* INT64_TYPE: Type Layout. (line 219) 49028* INT8_TYPE: Type Layout. (line 216) 49029* INT_FAST16_TYPE: Type Layout. (line 233) 49030* INT_FAST32_TYPE: Type Layout. (line 234) 49031* INT_FAST64_TYPE: Type Layout. (line 235) 49032* INT_FAST8_TYPE: Type Layout. (line 232) 49033* INT_LEAST16_TYPE: Type Layout. (line 225) 49034* INT_LEAST32_TYPE: Type Layout. (line 226) 49035* INT_LEAST64_TYPE: Type Layout. (line 227) 49036* INT_LEAST8_TYPE: Type Layout. (line 224) 49037* INT_TYPE_SIZE: Type Layout. (line 12) 49038* INTEGER_CST: Constant expressions. 49039 (line 6) 49040* INTEGER_TYPE: Types. (line 6) 49041* Interdependence of Patterns: Dependent Patterns. (line 6) 49042* interfacing to GCC output: Interface. (line 6) 49043* interlock delays: Processor pipeline description. 49044 (line 6) 49045* intermediate representation lowering: Parsing pass. (line 14) 49046* INTMAX_TYPE: Type Layout. (line 193) 49047* INTPTR_TYPE: Type Layout. (line 240) 49048* introduction: Top. (line 6) 49049* INVOKE__main: Macros for Initialization. 49050 (line 51) 49051* ior: Arithmetic. (line 162) 49052* ior and attributes: Expressions. (line 50) 49053* ior, canonicalization of: Insn Canonicalizations. 49054 (line 52) 49055* iorM3 instruction pattern: Standard Names. (line 269) 49056* IRA_HARD_REGNO_ADD_COST_MULTIPLIER: Allocation Order. (line 46) 49057* IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 125) 49058* is_gimple_addressable: Logical Operators. (line 115) 49059* is_gimple_asm_val: Logical Operators. (line 119) 49060* is_gimple_assign: Logical Operators. (line 151) 49061* is_gimple_call: Logical Operators. (line 154) 49062* is_gimple_call_addr: Logical Operators. (line 122) 49063* is_gimple_constant: Logical Operators. (line 130) 49064* is_gimple_debug: Logical Operators. (line 157) 49065* is_gimple_ip_invariant: Logical Operators. (line 139) 49066* is_gimple_ip_invariant_address: Logical Operators. (line 144) 49067* is_gimple_mem_ref_addr: Logical Operators. (line 126) 49068* is_gimple_min_invariant: Logical Operators. (line 133) 49069* is_gimple_omp: Logical Operators. (line 168) 49070* is_gimple_val: Logical Operators. (line 109) 49071* iterators in .md files: Iterators. (line 6) 49072* IV analysis on GIMPLE: Scalar evolutions. (line 6) 49073* IV analysis on RTL: loop-iv. (line 6) 49074* JMP_BUF_SIZE: Exception Region Output. 49075 (line 84) 49076* jump: Flags. (line 286) 49077* jump instruction pattern: Standard Names. (line 1169) 49078* jump instruction patterns: Jump Patterns. (line 6) 49079* jump instructions and set: Side Effects. (line 56) 49080* jump, in call_insn: Flags. (line 161) 49081* jump, in insn: Flags. (line 157) 49082* jump, in mem: Flags. (line 70) 49083* JUMP_ALIGN: Alignment Output. (line 9) 49084* jump_insn: Insns. (line 73) 49085* jump_insn and /f: Flags. (line 107) 49086* jump_insn and /s: Flags. (line 49) 49087* jump_insn and /u: Flags. (line 39) 49088* jump_insn and /v: Flags. (line 44) 49089* JUMP_LABEL: Insns. (line 80) 49090* jump_table_data: Insns. (line 166) 49091* jump_table_data and /s: Flags. (line 148) 49092* jump_table_data and /v: Flags. (line 44) 49093* JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 151) 49094* Jumps: Jumps. (line 6) 49095* LABEL_ALIGN: Alignment Output. (line 58) 49096* LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 27) 49097* LABEL_ALT_ENTRY_P: Insns. (line 146) 49098* LABEL_ALTERNATE_NAME: Edges. (line 181) 49099* LABEL_DECL: Declarations. (line 6) 49100* LABEL_KIND: Insns. (line 146) 49101* LABEL_NUSES: Insns. (line 142) 49102* LABEL_PRESERVE_P: Flags. (line 59) 49103* label_ref: Constants. (line 127) 49104* label_ref and /v: Flags. (line 65) 49105* label_ref, RTL sharing: Sharing. (line 35) 49106* LABEL_REF_NONLOCAL_P: Flags. (line 65) 49107* lang_hooks.gimplify_expr: Gimplification pass. 49108 (line 18) 49109* lang_hooks.parse_file: Parsing pass. (line 6) 49110* language-dependent trees: Language-dependent trees. 49111 (line 6) 49112* language-independent intermediate representation: Parsing pass. 49113 (line 14) 49114* large return values: Aggregate Return. (line 6) 49115* LAST_STACK_REG: Stack Registers. (line 31) 49116* LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51) 49117* lceilMN2: Standard Names. (line 745) 49118* LCSSA: LCSSA. (line 6) 49119* LD_FINI_SWITCH: Macros for Initialization. 49120 (line 29) 49121* LD_INIT_SWITCH: Macros for Initialization. 49122 (line 25) 49123* LDD_SUFFIX: Macros for Initialization. 49124 (line 122) 49125* le: Comparisons. (line 76) 49126* le and attributes: Expressions. (line 85) 49127* LE_EXPR: Unary and Binary Expressions. 49128 (line 6) 49129* leaf functions: Leaf Functions. (line 6) 49130* leaf_function_p: Standard Names. (line 1254) 49131* LEAF_REG_REMAP: Leaf Functions. (line 39) 49132* LEAF_REGISTERS: Leaf Functions. (line 25) 49133* left rotate: Arithmetic. (line 194) 49134* left shift: Arithmetic. (line 172) 49135* LEGITIMATE_PIC_OPERAND_P: PIC. (line 32) 49136* LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 153) 49137* length: GTY Options. (line 50) 49138* less than: Comparisons. (line 68) 49139* less than or equal: Comparisons. (line 76) 49140* leu: Comparisons. (line 76) 49141* leu and attributes: Expressions. (line 85) 49142* lfloorMN2: Standard Names. (line 740) 49143* LIB2FUNCS_EXTRA: Target Fragment. (line 11) 49144* LIB_SPEC: Driver. (line 108) 49145* LIBCALL_VALUE: Scalar Return. (line 56) 49146* libgcc.a: Library Calls. (line 6) 49147* LIBGCC2_CFLAGS: Target Fragment. (line 8) 49148* LIBGCC2_GNU_PREFIX: Type Layout. (line 103) 49149* LIBGCC2_UNWIND_ATTRIBUTE: Misc. (line 1104) 49150* LIBGCC_SPEC: Driver. (line 116) 49151* library subroutine names: Library Calls. (line 6) 49152* LIBRARY_PATH_ENV: Misc. (line 511) 49153* LIMIT_RELOAD_CLASS: Register Classes. (line 300) 49154* LINK_COMMAND_SPEC: Driver. (line 237) 49155* LINK_EH_SPEC: Driver. (line 143) 49156* LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 233) 49157* LINK_LIBGCC_SPECIAL_1: Driver. (line 228) 49158* LINK_SPEC: Driver. (line 101) 49159* list: Containers. (line 6) 49160* Liveness representation: Liveness information. 49161 (line 6) 49162* lo_sum: Arithmetic. (line 24) 49163* load address instruction: Simple Constraints. (line 164) 49164* LOAD_EXTEND_OP: Misc. (line 60) 49165* load_multiple instruction pattern: Standard Names. (line 137) 49166* Local Register Allocator (LRA): RTL passes. (line 188) 49167* LOCAL_ALIGNMENT: Storage Layout. (line 258) 49168* LOCAL_CLASS_P: Classes. (line 73) 49169* LOCAL_DECL_ALIGNMENT: Storage Layout. (line 295) 49170* LOCAL_INCLUDE_DIR: Driver. (line 313) 49171* LOCAL_LABEL_PREFIX: Instruction Output. (line 153) 49172* LOCAL_REGNO: Register Basics. (line 101) 49173* LOG_LINKS: Insns. (line 318) 49174* Logical Operators: Logical Operators. (line 6) 49175* logical-and, bitwise: Arithmetic. (line 157) 49176* LOGICAL_OP_NON_SHORT_CIRCUIT: Costs. (line 273) 49177* logM2 instruction pattern: Standard Names. (line 653) 49178* LONG_ACCUM_TYPE_SIZE: Type Layout. (line 93) 49179* LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 58) 49180* LONG_FRACT_TYPE_SIZE: Type Layout. (line 73) 49181* LONG_LONG_ACCUM_TYPE_SIZE: Type Layout. (line 98) 49182* LONG_LONG_FRACT_TYPE_SIZE: Type Layout. (line 78) 49183* LONG_LONG_TYPE_SIZE: Type Layout. (line 33) 49184* LONG_TYPE_SIZE: Type Layout. (line 22) 49185* longjmp and automatic variables: Interface. (line 52) 49186* Loop analysis: Loop representation. 49187 (line 6) 49188* Loop manipulation: Loop manipulation. (line 6) 49189* Loop querying: Loop querying. (line 6) 49190* Loop representation: Loop representation. 49191 (line 6) 49192* Loop-closed SSA form: LCSSA. (line 6) 49193* LOOP_ALIGN: Alignment Output. (line 41) 49194* LOOP_EXPR: Unary and Binary Expressions. 49195 (line 6) 49196* looping instruction patterns: Looping Patterns. (line 6) 49197* lowering, language-dependent intermediate representation: Parsing pass. 49198 (line 14) 49199* lrintMN2: Standard Names. (line 730) 49200* lroundMN2: Standard Names. (line 735) 49201* LSHIFT_EXPR: Unary and Binary Expressions. 49202 (line 6) 49203* lshiftrt: Arithmetic. (line 189) 49204* lshiftrt and attributes: Expressions. (line 85) 49205* lshrM3 instruction pattern: Standard Names. (line 568) 49206* lt: Comparisons. (line 68) 49207* lt and attributes: Expressions. (line 85) 49208* LT_EXPR: Unary and Binary Expressions. 49209 (line 6) 49210* LTGT_EXPR: Unary and Binary Expressions. 49211 (line 6) 49212* lto: LTO. (line 6) 49213* ltrans: LTO. (line 6) 49214* ltu: Comparisons. (line 68) 49215* m in constraint: Simple Constraints. (line 17) 49216* machine attributes: Target Attributes. (line 6) 49217* machine description macros: Target Macros. (line 6) 49218* machine descriptions: Machine Desc. (line 6) 49219* machine mode conversions: Conversions. (line 6) 49220* machine modes: Machine Modes. (line 6) 49221* machine specific constraints: Machine Constraints. 49222 (line 6) 49223* machine-independent predicates: Machine-Independent Predicates. 49224 (line 6) 49225* machine_mode: Machine Modes. (line 6) 49226* macros, target description: Target Macros. (line 6) 49227* maddMN4 instruction pattern: Standard Names. (line 491) 49228* MAKE_DECL_ONE_ONLY: Label Output. (line 257) 49229* make_safe_from: Expander Definitions. 49230 (line 151) 49231* makefile fragment: Fragments. (line 6) 49232* makefile targets: Makefile. (line 6) 49233* MALLOC_ABI_ALIGNMENT: Storage Layout. (line 175) 49234* Manipulating GIMPLE statements: Manipulating GIMPLE statements. 49235 (line 6) 49236* mark_hook: GTY Options. (line 137) 49237* marking roots: GGC Roots. (line 6) 49238* MASK_RETURN_ADDR: Exception Region Output. 49239 (line 35) 49240* Match and Simplify: Match and Simplify. (line 6) 49241* match_dup <1>: define_peephole2. (line 28) 49242* match_dup: RTL Template. (line 73) 49243* match_dup and attributes: Insn Lengths. (line 16) 49244* match_op_dup: RTL Template. (line 163) 49245* match_operand: RTL Template. (line 16) 49246* match_operand and attributes: Expressions. (line 55) 49247* match_operator: RTL Template. (line 95) 49248* match_par_dup: RTL Template. (line 219) 49249* match_parallel: RTL Template. (line 172) 49250* match_scratch <1>: define_peephole2. (line 28) 49251* match_scratch: RTL Template. (line 58) 49252* match_test and attributes: Expressions. (line 64) 49253* matching constraint: Simple Constraints. (line 142) 49254* matching operands: Output Template. (line 49) 49255* math library: Soft float library routines. 49256 (line 6) 49257* math, in RTL: Arithmetic. (line 6) 49258* MATH_LIBRARY: Misc. (line 504) 49259* matherr: Library Calls. (line 59) 49260* MAX_BITS_PER_WORD: Storage Layout. (line 55) 49261* MAX_BITSIZE_MODE_ANY_INT: Machine Modes. (line 359) 49262* MAX_BITSIZE_MODE_ANY_MODE: Machine Modes. (line 365) 49263* MAX_CONDITIONAL_EXECUTE: Misc. (line 526) 49264* MAX_FIXED_MODE_SIZE: Storage Layout. (line 441) 49265* MAX_MOVE_MAX: Misc. (line 106) 49266* MAX_OFILE_ALIGNMENT: Storage Layout. (line 212) 49267* MAX_REGS_PER_ADDRESS: Addressing Modes. (line 43) 49268* MAX_STACK_ALIGNMENT: Storage Layout. (line 205) 49269* maxM3 instruction pattern: Standard Names. (line 328) 49270* may_trap_p, tree_could_trap_p: Edges. (line 115) 49271* maybe_undef: GTY Options. (line 145) 49272* mcount: Profiling. (line 12) 49273* MD_EXEC_PREFIX: Driver. (line 268) 49274* MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 94) 49275* MD_HANDLE_UNWABI: Exception Handling. (line 114) 49276* MD_STARTFILE_PREFIX: Driver. (line 296) 49277* MD_STARTFILE_PREFIX_1: Driver. (line 301) 49278* mem: Regs and Memory. (line 374) 49279* mem and /c: Flags. (line 81) 49280* mem and /f: Flags. (line 85) 49281* mem and /j: Flags. (line 70) 49282* mem and /u: Flags. (line 134) 49283* mem and /v: Flags. (line 76) 49284* mem, RTL sharing: Sharing. (line 40) 49285* MEM_ADDR_SPACE: Special Accessors. (line 49) 49286* MEM_ALIAS_SET: Special Accessors. (line 9) 49287* MEM_ALIGN: Special Accessors. (line 46) 49288* MEM_EXPR: Special Accessors. (line 20) 49289* MEM_KEEP_ALIAS_SET_P: Flags. (line 70) 49290* MEM_NOTRAP_P: Flags. (line 81) 49291* MEM_OFFSET: Special Accessors. (line 32) 49292* MEM_OFFSET_KNOWN_P: Special Accessors. (line 28) 49293* MEM_POINTER: Flags. (line 85) 49294* MEM_READONLY_P: Flags. (line 134) 49295* MEM_REF: Storage References. (line 6) 49296* mem_signal_fenceMODE instruction pattern: Standard Names. (line 1903) 49297* MEM_SIZE: Special Accessors. (line 40) 49298* MEM_SIZE_KNOWN_P: Special Accessors. (line 36) 49299* mem_thread_fenceMODE instruction pattern: Standard Names. (line 1895) 49300* MEM_VOLATILE_P: Flags. (line 76) 49301* memory model: Memory model. (line 6) 49302* memory reference, nonoffsettable: Simple Constraints. (line 256) 49303* memory references in constraints: Simple Constraints. (line 17) 49304* memory_barrier instruction pattern: Standard Names. (line 1644) 49305* MEMORY_MOVE_COST: Costs. (line 54) 49306* memory_operand: Machine-Independent Predicates. 49307 (line 58) 49308* METHOD_TYPE: Types. (line 6) 49309* MIN_UNITS_PER_WORD: Storage Layout. (line 65) 49310* MINIMUM_ALIGNMENT: Storage Layout. (line 308) 49311* MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 183) 49312* minM3 instruction pattern: Standard Names. (line 328) 49313* minus: Arithmetic. (line 36) 49314* minus and attributes: Expressions. (line 85) 49315* minus, canonicalization of: Insn Canonicalizations. 49316 (line 27) 49317* MINUS_EXPR: Unary and Binary Expressions. 49318 (line 6) 49319* MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6) 49320* miscellaneous register hooks: Miscellaneous Register Hooks. 49321 (line 6) 49322* mnemonic attribute: Mnemonic Attribute. (line 6) 49323* mod: Arithmetic. (line 135) 49324* mod and attributes: Expressions. (line 85) 49325* mode classes: Machine Modes. (line 226) 49326* mode iterators in .md files: Mode Iterators. (line 6) 49327* mode switching: Mode Switching. (line 6) 49328* MODE_ACCUM: Machine Modes. (line 256) 49329* MODE_BASE_REG_CLASS: Register Classes. (line 119) 49330* MODE_BASE_REG_REG_CLASS: Register Classes. (line 125) 49331* MODE_CC <1>: MODE_CC Condition Codes. 49332 (line 6) 49333* MODE_CC: Machine Modes. (line 275) 49334* MODE_CODE_BASE_REG_CLASS: Register Classes. (line 133) 49335* MODE_COMPLEX_FLOAT: Machine Modes. (line 267) 49336* MODE_COMPLEX_INT: Machine Modes. (line 264) 49337* MODE_DECIMAL_FLOAT: Machine Modes. (line 244) 49338* MODE_FLOAT: Machine Modes. (line 240) 49339* MODE_FRACT: Machine Modes. (line 248) 49340* MODE_FUNCTION: Machine Modes. (line 271) 49341* MODE_INT: Machine Modes. (line 232) 49342* MODE_PARTIAL_INT: Machine Modes. (line 236) 49343* MODE_POINTER_BOUNDS: Machine Modes. (line 280) 49344* MODE_RANDOM: Machine Modes. (line 285) 49345* MODE_UACCUM: Machine Modes. (line 260) 49346* MODE_UFRACT: Machine Modes. (line 252) 49347* MODES_TIEABLE_P: Values in Registers. 49348 (line 129) 49349* modifiers in constraints: Modifiers. (line 6) 49350* MODIFY_EXPR: Unary and Binary Expressions. 49351 (line 6) 49352* MODIFY_JNI_METHOD_CALL: Misc. (line 877) 49353* modM3 instruction pattern: Standard Names. (line 269) 49354* modulo scheduling: RTL passes. (line 124) 49355* MOVE_MAX: Misc. (line 101) 49356* MOVE_MAX_PIECES: Costs. (line 200) 49357* MOVE_RATIO: Costs. (line 149) 49358* movM instruction pattern: Standard Names. (line 11) 49359* movmemM instruction pattern: Standard Names. (line 810) 49360* movmisalignM instruction pattern: Standard Names. (line 126) 49361* movMODEcc instruction pattern: Standard Names. (line 1104) 49362* movstr instruction pattern: Standard Names. (line 845) 49363* movstrictM instruction pattern: Standard Names. (line 120) 49364* msubMN4 instruction pattern: Standard Names. (line 514) 49365* mulhisi3 instruction pattern: Standard Names. (line 467) 49366* mulM3 instruction pattern: Standard Names. (line 269) 49367* mulqihi3 instruction pattern: Standard Names. (line 471) 49368* mulsidi3 instruction pattern: Standard Names. (line 471) 49369* mult: Arithmetic. (line 92) 49370* mult and attributes: Expressions. (line 85) 49371* mult, canonicalization of: Insn Canonicalizations. 49372 (line 27) 49373* MULT_EXPR: Unary and Binary Expressions. 49374 (line 6) 49375* MULT_HIGHPART_EXPR: Unary and Binary Expressions. 49376 (line 6) 49377* MULTIARCH_DIRNAME: Target Fragment. (line 170) 49378* MULTILIB_DEFAULTS: Driver. (line 253) 49379* MULTILIB_DIRNAMES: Target Fragment. (line 44) 49380* MULTILIB_EXCEPTIONS: Target Fragment. (line 70) 49381* MULTILIB_EXTRA_OPTS: Target Fragment. (line 132) 49382* MULTILIB_MATCHES: Target Fragment. (line 63) 49383* MULTILIB_OPTIONS: Target Fragment. (line 24) 49384* MULTILIB_OSDIRNAMES: Target Fragment. (line 139) 49385* MULTILIB_REQUIRED: Target Fragment. (line 82) 49386* MULTILIB_REUSE: Target Fragment. (line 103) 49387* multiple alternative constraints: Multi-Alternative. (line 6) 49388* MULTIPLE_SYMBOL_SPACES: Misc. (line 484) 49389* multiplication: Arithmetic. (line 92) 49390* multiplication with signed saturation: Arithmetic. (line 92) 49391* multiplication with unsigned saturation: Arithmetic. (line 92) 49392* mulvM4 instruction pattern: Standard Names. (line 285) 49393* n in constraint: Simple Constraints. (line 75) 49394* N_REG_CLASSES: Register Classes. (line 83) 49395* name: Identifiers. (line 6) 49396* named address spaces: Named Address Spaces. 49397 (line 6) 49398* named patterns and conditions: Patterns. (line 49) 49399* names, pattern: Standard Names. (line 6) 49400* namespace, scope: Namespaces. (line 6) 49401* NAMESPACE_DECL <1>: Namespaces. (line 6) 49402* NAMESPACE_DECL: Declarations. (line 6) 49403* NATIVE_SYSTEM_HEADER_COMPONENT: Driver. (line 323) 49404* ne: Comparisons. (line 56) 49405* ne and attributes: Expressions. (line 85) 49406* NE_EXPR: Unary and Binary Expressions. 49407 (line 6) 49408* nearbyintM2 instruction pattern: Standard Names. (line 712) 49409* neg: Arithmetic. (line 81) 49410* neg and attributes: Expressions. (line 85) 49411* neg, canonicalization of: Insn Canonicalizations. 49412 (line 27) 49413* NEGATE_EXPR: Unary and Binary Expressions. 49414 (line 6) 49415* negation: Arithmetic. (line 81) 49416* negation with signed saturation: Arithmetic. (line 81) 49417* negation with unsigned saturation: Arithmetic. (line 81) 49418* negM2 instruction pattern: Standard Names. (line 580) 49419* negvM3 instruction pattern: Standard Names. (line 583) 49420* nested functions, trampolines for: Trampolines. (line 6) 49421* nested_ptr: GTY Options. (line 152) 49422* next_bb, prev_bb, FOR_EACH_BB, FOR_ALL_BB: Basic Blocks. (line 25) 49423* NEXT_INSN: Insns. (line 30) 49424* NEXT_OBJC_RUNTIME: Library Calls. (line 83) 49425* nil: RTL Objects. (line 73) 49426* NM_FLAGS: Macros for Initialization. 49427 (line 111) 49428* NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 26) 49429* NO_DBX_FUNCTION_END: DBX Hooks. (line 20) 49430* NO_DBX_GCC_MARKER: File Names and DBX. (line 28) 49431* NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 23) 49432* NO_DOLLAR_IN_LABEL: Label Output. (line 67) 49433* NO_DOT_IN_LABEL: Label Output. (line 73) 49434* NO_FUNCTION_CSE: Costs. (line 269) 49435* NO_IMPLICIT_EXTERN_C: Misc. (line 382) 49436* NO_PROFILE_COUNTERS: Profiling. (line 28) 49437* NO_REGS: Register Classes. (line 17) 49438* NON_LVALUE_EXPR: Unary and Binary Expressions. 49439 (line 6) 49440* nondeterministic finite state automaton: Processor pipeline description. 49441 (line 305) 49442* nonimmediate_operand: Machine-Independent Predicates. 49443 (line 101) 49444* nonlocal goto handler: Edges. (line 172) 49445* nonlocal_goto instruction pattern: Standard Names. (line 1476) 49446* nonlocal_goto_receiver instruction pattern: Standard Names. 49447 (line 1493) 49448* nonmemory_operand: Machine-Independent Predicates. 49449 (line 97) 49450* nonoffsettable memory reference: Simple Constraints. (line 256) 49451* nop instruction pattern: Standard Names. (line 1287) 49452* NOP_EXPR: Unary and Binary Expressions. 49453 (line 6) 49454* normal predicates: Predicates. (line 31) 49455* not: Arithmetic. (line 153) 49456* not and attributes: Expressions. (line 50) 49457* not equal: Comparisons. (line 56) 49458* not, canonicalization of: Insn Canonicalizations. 49459 (line 27) 49460* note: Insns. (line 185) 49461* note and /i: Flags. (line 59) 49462* note and /v: Flags. (line 44) 49463* NOTE_INSN_BASIC_BLOCK: Basic Blocks. (line 50) 49464* NOTE_INSN_BLOCK_BEG: Insns. (line 210) 49465* NOTE_INSN_BLOCK_END: Insns. (line 210) 49466* NOTE_INSN_DELETED: Insns. (line 200) 49467* NOTE_INSN_DELETED_LABEL: Insns. (line 205) 49468* NOTE_INSN_EH_REGION_BEG: Insns. (line 216) 49469* NOTE_INSN_EH_REGION_END: Insns. (line 216) 49470* NOTE_INSN_FUNCTION_BEG: Insns. (line 223) 49471* NOTE_INSN_VAR_LOCATION: Insns. (line 227) 49472* NOTE_LINE_NUMBER: Insns. (line 185) 49473* NOTE_SOURCE_FILE: Insns. (line 185) 49474* NOTE_VAR_LOCATION: Insns. (line 227) 49475* NOTICE_UPDATE_CC: CC0 Condition Codes. 49476 (line 31) 49477* NUM_MACHINE_MODES: Machine Modes. (line 298) 49478* NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 31) 49479* Number of iterations analysis: Number of iterations. 49480 (line 6) 49481* o in constraint: Simple Constraints. (line 23) 49482* OACC_CACHE: OpenACC. (line 6) 49483* OACC_DATA: OpenACC. (line 6) 49484* OACC_DECLARE: OpenACC. (line 6) 49485* OACC_ENTER_DATA: OpenACC. (line 6) 49486* OACC_EXIT_DATA: OpenACC. (line 6) 49487* OACC_HOST_DATA: OpenACC. (line 6) 49488* OACC_KERNELS: OpenACC. (line 6) 49489* OACC_LOOP: OpenACC. (line 6) 49490* OACC_PARALLEL: OpenACC. (line 6) 49491* OACC_UPDATE: OpenACC. (line 6) 49492* OBJC_GEN_METHOD_LABEL: Label Output. (line 459) 49493* OBJC_JBLEN: Misc. (line 1099) 49494* OBJECT_FORMAT_COFF: Macros for Initialization. 49495 (line 97) 49496* OFFSET_TYPE: Types. (line 6) 49497* offsettable address: Simple Constraints. (line 23) 49498* OImode: Machine Modes. (line 51) 49499* Omega a solver for linear programming problems: Omega. (line 6) 49500* OMP_ATOMIC: OpenMP. (line 6) 49501* OMP_CLAUSE: OpenMP. (line 6) 49502* OMP_CONTINUE: OpenMP. (line 6) 49503* OMP_CRITICAL: OpenMP. (line 6) 49504* OMP_FOR: OpenMP. (line 6) 49505* OMP_MASTER: OpenMP. (line 6) 49506* OMP_ORDERED: OpenMP. (line 6) 49507* OMP_PARALLEL: OpenMP. (line 6) 49508* OMP_RETURN: OpenMP. (line 6) 49509* OMP_SECTION: OpenMP. (line 6) 49510* OMP_SECTIONS: OpenMP. (line 6) 49511* OMP_SINGLE: OpenMP. (line 6) 49512* one_cmplM2 instruction pattern: Standard Names. (line 807) 49513* operand access: Accessors. (line 6) 49514* Operand Access Routines: SSA Operands. (line 119) 49515* operand constraints: Constraints. (line 6) 49516* Operand Iterators: SSA Operands. (line 119) 49517* operand predicates: Predicates. (line 6) 49518* operand substitution: Output Template. (line 6) 49519* operands <1>: Patterns. (line 55) 49520* operands: SSA Operands. (line 6) 49521* Operands: Operands. (line 6) 49522* operator predicates: Predicates. (line 6) 49523* optc-gen.awk: Options. (line 6) 49524* OPTGROUP_ALL: Optimization groups. 49525 (line 25) 49526* OPTGROUP_INLINE: Optimization groups. 49527 (line 15) 49528* OPTGROUP_IPA: Optimization groups. 49529 (line 9) 49530* OPTGROUP_LOOP: Optimization groups. 49531 (line 12) 49532* OPTGROUP_OTHER: Optimization groups. 49533 (line 21) 49534* OPTGROUP_VEC: Optimization groups. 49535 (line 18) 49536* optimization dumps: Optimization info. (line 6) 49537* optimization groups: Optimization groups. 49538 (line 6) 49539* optimization info file names: Dump files and streams. 49540 (line 6) 49541* Optimization infrastructure for GIMPLE: Tree SSA. (line 6) 49542* OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 9) 49543* option specification files: Options. (line 6) 49544* OPTION_DEFAULT_SPECS: Driver. (line 26) 49545* optional hardware or system features: Run-time Target. (line 59) 49546* options, directory search: Including Patterns. (line 44) 49547* order of register allocation: Allocation Order. (line 6) 49548* ordered_comparison_operator: Machine-Independent Predicates. 49549 (line 116) 49550* ORDERED_EXPR: Unary and Binary Expressions. 49551 (line 6) 49552* Ordering of Patterns: Pattern Ordering. (line 6) 49553* ORIGINAL_REGNO: Special Accessors. (line 54) 49554* other register constraints: Simple Constraints. (line 173) 49555* outgoing_args_size: Stack Arguments. (line 48) 49556* OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 80) 49557* OUTGOING_REGNO: Register Basics. (line 94) 49558* output of assembler code: File Framework. (line 6) 49559* output statements: Output Statement. (line 6) 49560* output templates: Output Template. (line 6) 49561* output_asm_insn: Output Statement. (line 53) 49562* OUTPUT_QUOTED_STRING: File Framework. (line 108) 49563* OVERLAPPING_REGISTER_NAMES: Instruction Output. (line 21) 49564* OVERLOAD: Functions for C++. (line 6) 49565* OVERRIDE_ABI_FORMAT: Register Arguments. (line 155) 49566* OVL_CURRENT: Functions for C++. (line 6) 49567* OVL_NEXT: Functions for C++. (line 6) 49568* p in constraint: Simple Constraints. (line 164) 49569* PAD_VARARGS_DOWN: Register Arguments. (line 236) 49570* parallel: Side Effects. (line 210) 49571* parameters, c++ abi: C++ ABI. (line 6) 49572* parameters, miscellaneous: Misc. (line 6) 49573* parameters, precompiled headers: PCH Target. (line 6) 49574* parity: Arithmetic. (line 242) 49575* parityM2 instruction pattern: Standard Names. (line 800) 49576* PARM_BOUNDARY: Storage Layout. (line 135) 49577* PARM_DECL: Declarations. (line 6) 49578* PARSE_LDD_OUTPUT: Macros for Initialization. 49579 (line 127) 49580* pass dumps: Passes. (line 6) 49581* pass_duplicate_computed_gotos: Edges. (line 162) 49582* passes and files of the compiler: Passes. (line 6) 49583* passing arguments: Interface. (line 36) 49584* PATH_SEPARATOR: Filesystem. (line 31) 49585* PATTERN: Insns. (line 288) 49586* pattern conditions: Patterns. (line 43) 49587* pattern names: Standard Names. (line 6) 49588* Pattern Ordering: Pattern Ordering. (line 6) 49589* patterns: Patterns. (line 6) 49590* pc: Regs and Memory. (line 361) 49591* pc and attributes: Insn Lengths. (line 20) 49592* pc, RTL sharing: Sharing. (line 25) 49593* PC_REGNUM: Register Basics. (line 108) 49594* pc_rtx: Regs and Memory. (line 366) 49595* PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 334) 49596* PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 65) 49597* PDImode: Machine Modes. (line 40) 49598* peephole optimization, RTL representation: Side Effects. (line 244) 49599* peephole optimizer definitions: Peephole Definitions. 49600 (line 6) 49601* per-function data: Per-Function Data. (line 6) 49602* percent sign: Output Template. (line 6) 49603* PHI nodes: SSA. (line 31) 49604* PIC: PIC. (line 6) 49605* PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 26) 49606* PIC_OFFSET_TABLE_REGNUM: PIC. (line 16) 49607* pipeline hazard recognizer: Processor pipeline description. 49608 (line 6) 49609* Plugins: Plugins. (line 6) 49610* plus: Arithmetic. (line 14) 49611* plus and attributes: Expressions. (line 85) 49612* plus, canonicalization of: Insn Canonicalizations. 49613 (line 27) 49614* PLUS_EXPR: Unary and Binary Expressions. 49615 (line 6) 49616* Pmode: Misc. (line 330) 49617* pmode_register_operand: Machine-Independent Predicates. 49618 (line 35) 49619* pointer: Types. (line 6) 49620* POINTER_PLUS_EXPR: Unary and Binary Expressions. 49621 (line 6) 49622* POINTER_SIZE: Storage Layout. (line 71) 49623* POINTER_TYPE: Types. (line 6) 49624* POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 77) 49625* pop_operand: Machine-Independent Predicates. 49626 (line 88) 49627* popcount: Arithmetic. (line 238) 49628* popcountM2 instruction pattern: Standard Names. (line 794) 49629* pops_args: Function Entry. (line 106) 49630* portability: Portability. (line 6) 49631* position independent code: PIC. (line 6) 49632* post_dec: Incdec. (line 25) 49633* post_inc: Incdec. (line 30) 49634* post_modify: Incdec. (line 33) 49635* post_order_compute, inverted_post_order_compute, walk_dominator_tree: Basic Blocks. 49636 (line 34) 49637* POSTDECREMENT_EXPR: Unary and Binary Expressions. 49638 (line 6) 49639* POSTINCREMENT_EXPR: Unary and Binary Expressions. 49640 (line 6) 49641* POWI_MAX_MULTS: Misc. (line 967) 49642* powM3 instruction pattern: Standard Names. (line 661) 49643* pragma: Misc. (line 387) 49644* pre_dec: Incdec. (line 8) 49645* PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 127) 49646* pre_inc: Incdec. (line 22) 49647* pre_modify: Incdec. (line 51) 49648* PREDECREMENT_EXPR: Unary and Binary Expressions. 49649 (line 6) 49650* predefined macros: Run-time Target. (line 6) 49651* predicates: Predicates. (line 6) 49652* predicates and machine modes: Predicates. (line 31) 49653* predication: Conditional Execution. 49654 (line 6) 49655* predict.def: Profile information. 49656 (line 24) 49657* PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 42) 49658* PREFERRED_RELOAD_CLASS: Register Classes. (line 253) 49659* PREFERRED_STACK_BOUNDARY: Storage Layout. (line 149) 49660* prefetch: Side Effects. (line 325) 49661* prefetch and /v: Flags. (line 214) 49662* prefetch instruction pattern: Standard Names. (line 1621) 49663* PREFETCH_SCHEDULE_BARRIER_P: Flags. (line 214) 49664* PREINCREMENT_EXPR: Unary and Binary Expressions. 49665 (line 6) 49666* presence_set: Processor pipeline description. 49667 (line 224) 49668* preserving SSA form: SSA. (line 74) 49669* preserving virtual SSA form: SSA. (line 182) 49670* pretend_args_size: Function Entry. (line 112) 49671* prev_active_insn: define_peephole. (line 60) 49672* PREV_INSN: Insns. (line 26) 49673* PRINT_OPERAND: Instruction Output. (line 96) 49674* PRINT_OPERAND_ADDRESS: Instruction Output. (line 124) 49675* PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 117) 49676* probe_stack instruction pattern: Standard Names. (line 1468) 49677* probe_stack_address instruction pattern: Standard Names. (line 1461) 49678* processor functional units: Processor pipeline description. 49679 (line 6) 49680* processor pipeline description: Processor pipeline description. 49681 (line 6) 49682* product: Arithmetic. (line 92) 49683* profile feedback: Profile information. 49684 (line 14) 49685* profile representation: Profile information. 49686 (line 6) 49687* PROFILE_BEFORE_PROLOGUE: Profiling. (line 35) 49688* PROFILE_HOOK: Profiling. (line 23) 49689* profiling, code generation: Profiling. (line 6) 49690* program counter: Regs and Memory. (line 362) 49691* prologue: Function Entry. (line 6) 49692* prologue instruction pattern: Standard Names. (line 1559) 49693* PROMOTE_MODE: Storage Layout. (line 88) 49694* pseudo registers: Regs and Memory. (line 9) 49695* PSImode: Machine Modes. (line 32) 49696* PTRDIFF_TYPE: Type Layout. (line 164) 49697* purge_dead_edges <1>: Maintaining the CFG. 49698 (line 82) 49699* purge_dead_edges: Edges. (line 104) 49700* push address instruction: Simple Constraints. (line 164) 49701* PUSH_ARGS: Stack Arguments. (line 18) 49702* PUSH_ARGS_REVERSED: Stack Arguments. (line 26) 49703* push_operand: Machine-Independent Predicates. 49704 (line 81) 49705* push_reload: Addressing Modes. (line 177) 49706* PUSH_ROUNDING: Stack Arguments. (line 32) 49707* pushM1 instruction pattern: Standard Names. (line 256) 49708* PUT_CODE: RTL Objects. (line 47) 49709* PUT_MODE: Machine Modes. (line 295) 49710* PUT_REG_NOTE_KIND: Insns. (line 352) 49711* PUT_SDB_: SDB and DWARF. (line 110) 49712* QCmode: Machine Modes. (line 200) 49713* QFmode: Machine Modes. (line 57) 49714* QImode: Machine Modes. (line 25) 49715* QImode, in insn: Insns. (line 272) 49716* QQmode: Machine Modes. (line 106) 49717* qualified type <1>: Types for C++. (line 6) 49718* qualified type: Types. (line 6) 49719* querying function unit reservations: Processor pipeline description. 49720 (line 90) 49721* question mark: Multi-Alternative. (line 41) 49722* quotient: Arithmetic. (line 115) 49723* r in constraint: Simple Constraints. (line 66) 49724* RDIV_EXPR: Unary and Binary Expressions. 49725 (line 6) 49726* READONLY_DATA_SECTION_ASM_OP: Sections. (line 63) 49727* real operands: SSA Operands. (line 6) 49728* REAL_ARITHMETIC: Floating Point. (line 66) 49729* REAL_CST: Constant expressions. 49730 (line 6) 49731* REAL_LIBGCC_SPEC: Driver. (line 125) 49732* REAL_NM_FILE_NAME: Macros for Initialization. 49733 (line 106) 49734* REAL_TYPE: Types. (line 6) 49735* REAL_VALUE_ABS: Floating Point. (line 82) 49736* REAL_VALUE_ATOF: Floating Point. (line 50) 49737* REAL_VALUE_FIX: Floating Point. (line 41) 49738* REAL_VALUE_ISINF: Floating Point. (line 59) 49739* REAL_VALUE_ISNAN: Floating Point. (line 62) 49740* REAL_VALUE_NEGATE: Floating Point. (line 79) 49741* REAL_VALUE_NEGATIVE: Floating Point. (line 56) 49742* REAL_VALUE_TO_TARGET_DECIMAL128: Data Output. (line 149) 49743* REAL_VALUE_TO_TARGET_DECIMAL32: Data Output. (line 147) 49744* REAL_VALUE_TO_TARGET_DECIMAL64: Data Output. (line 148) 49745* REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 145) 49746* REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 146) 49747* REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 144) 49748* REAL_VALUE_TYPE: Floating Point. (line 26) 49749* REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 45) 49750* REAL_VALUES_EQUAL: Floating Point. (line 32) 49751* REAL_VALUES_LESS: Floating Point. (line 38) 49752* REALPART_EXPR: Unary and Binary Expressions. 49753 (line 6) 49754* recog_data.operand: Instruction Output. (line 54) 49755* recognizing insns: RTL Template. (line 6) 49756* RECORD_TYPE <1>: Classes. (line 6) 49757* RECORD_TYPE: Types. (line 6) 49758* redirect_edge_and_branch: Profile information. 49759 (line 71) 49760* redirect_edge_and_branch, redirect_jump: Maintaining the CFG. 49761 (line 92) 49762* reduc_plus_scal_M instruction pattern: Standard Names. (line 367) 49763* reduc_smax_M instruction pattern: Standard Names. (line 334) 49764* reduc_smax_scal_M instruction pattern: Standard Names. (line 357) 49765* reduc_smin_M instruction pattern: Standard Names. (line 334) 49766* reduc_smin_scal_M instruction pattern: Standard Names. (line 357) 49767* reduc_splus_M instruction pattern: Standard Names. (line 350) 49768* reduc_umax_M instruction pattern: Standard Names. (line 342) 49769* reduc_umax_scal_M instruction pattern: Standard Names. (line 362) 49770* reduc_umin_M instruction pattern: Standard Names. (line 342) 49771* reduc_umin_scal_M instruction pattern: Standard Names. (line 362) 49772* reduc_uplus_M instruction pattern: Standard Names. (line 350) 49773* reference: Types. (line 6) 49774* REFERENCE_TYPE: Types. (line 6) 49775* reg: Regs and Memory. (line 9) 49776* reg and /f: Flags. (line 94) 49777* reg and /i: Flags. (line 89) 49778* reg and /v: Flags. (line 98) 49779* reg, RTL sharing: Sharing. (line 17) 49780* REG_ALLOC_ORDER: Allocation Order. (line 9) 49781* REG_BR_PRED: Insns. (line 534) 49782* REG_BR_PROB: Insns. (line 527) 49783* REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information. 49784 (line 82) 49785* REG_BR_PROB_BASE, EDGE_FREQUENCY: Profile information. 49786 (line 52) 49787* REG_CC_SETTER: Insns. (line 498) 49788* REG_CC_USER: Insns. (line 498) 49789* REG_CLASS_CONTENTS: Register Classes. (line 93) 49790* reg_class_contents: Register Basics. (line 59) 49791* reg_class_for_constraint: C Constraint Interface. 49792 (line 50) 49793* REG_CLASS_NAMES: Register Classes. (line 88) 49794* REG_CROSSING_JUMP: Insns. (line 411) 49795* REG_DEAD: Insns. (line 363) 49796* REG_DEAD, REG_UNUSED: Liveness information. 49797 (line 32) 49798* REG_DEP_ANTI: Insns. (line 520) 49799* REG_DEP_OUTPUT: Insns. (line 516) 49800* REG_DEP_TRUE: Insns. (line 513) 49801* REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 110) 49802* REG_EQUAL: Insns. (line 426) 49803* REG_EQUIV: Insns. (line 426) 49804* REG_EXPR: Special Accessors. (line 60) 49805* REG_FRAME_RELATED_EXPR: Insns. (line 540) 49806* REG_FUNCTION_VALUE_P: Flags. (line 89) 49807* REG_INC: Insns. (line 379) 49808* reg_label and /v: Flags. (line 65) 49809* REG_LABEL_OPERAND: Insns. (line 393) 49810* REG_LABEL_TARGET: Insns. (line 402) 49811* reg_names <1>: Instruction Output. (line 108) 49812* reg_names: Register Basics. (line 59) 49813* REG_NONNEG: Insns. (line 385) 49814* REG_NOTE_KIND: Insns. (line 352) 49815* REG_NOTES: Insns. (line 325) 49816* REG_OFFSET: Special Accessors. (line 64) 49817* REG_OK_STRICT: Addressing Modes. (line 100) 49818* REG_PARM_STACK_SPACE: Stack Arguments. (line 59) 49819* REG_PARM_STACK_SPACE, and TARGET_FUNCTION_ARG: Register Arguments. 49820 (line 57) 49821* REG_POINTER: Flags. (line 94) 49822* REG_SETJMP: Insns. (line 420) 49823* REG_UNUSED: Insns. (line 372) 49824* REG_USERVAR_P: Flags. (line 98) 49825* REG_VALUE_IN_UNWIND_CONTEXT: Frame Registers. (line 157) 49826* REG_WORDS_BIG_ENDIAN: Storage Layout. (line 36) 49827* register allocation order: Allocation Order. (line 6) 49828* register class definitions: Register Classes. (line 6) 49829* register class preference constraints: Class Preferences. (line 6) 49830* register pairs: Values in Registers. 49831 (line 69) 49832* Register Transfer Language (RTL): RTL. (line 6) 49833* register usage: Registers. (line 6) 49834* REGISTER_MOVE_COST: Costs. (line 10) 49835* REGISTER_NAMES: Instruction Output. (line 9) 49836* register_operand: Machine-Independent Predicates. 49837 (line 30) 49838* REGISTER_PREFIX: Instruction Output. (line 152) 49839* REGISTER_TARGET_PRAGMAS: Misc. (line 388) 49840* registers arguments: Register Arguments. (line 6) 49841* registers in constraints: Simple Constraints. (line 66) 49842* REGMODE_NATURAL_SIZE: Values in Registers. 49843 (line 50) 49844* REGNO_MODE_CODE_OK_FOR_BASE_P: Register Classes. (line 176) 49845* REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 153) 49846* REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 163) 49847* REGNO_OK_FOR_BASE_P: Register Classes. (line 149) 49848* REGNO_OK_FOR_INDEX_P: Register Classes. (line 190) 49849* REGNO_REG_CLASS: Register Classes. (line 108) 49850* regs_ever_live: Function Entry. (line 21) 49851* regular expressions: Processor pipeline description. 49852 (line 6) 49853* relative costs: Costs. (line 6) 49854* RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 263) 49855* reload_completed: Standard Names. (line 1254) 49856* reload_in instruction pattern: Standard Names. (line 99) 49857* reload_in_progress: Standard Names. (line 57) 49858* reload_out instruction pattern: Standard Names. (line 99) 49859* reloading: RTL passes. (line 171) 49860* remainder: Arithmetic. (line 135) 49861* remainderM3 instruction pattern: Standard Names. (line 607) 49862* reorder: GTY Options. (line 176) 49863* representation of RTL: RTL. (line 6) 49864* reservation delays: Processor pipeline description. 49865 (line 6) 49866* rest_of_decl_compilation: Parsing pass. (line 52) 49867* rest_of_type_compilation: Parsing pass. (line 52) 49868* restore_stack_block instruction pattern: Standard Names. (line 1381) 49869* restore_stack_function instruction pattern: Standard Names. 49870 (line 1381) 49871* restore_stack_nonlocal instruction pattern: Standard Names. 49872 (line 1381) 49873* RESULT_DECL: Declarations. (line 6) 49874* return: Side Effects. (line 72) 49875* return instruction pattern: Standard Names. (line 1227) 49876* return values in registers: Scalar Return. (line 6) 49877* RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 135) 49878* RETURN_ADDR_OFFSET: Exception Handling. (line 60) 49879* RETURN_ADDR_RTX: Frame Layout. (line 124) 49880* RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 65) 49881* RETURN_EXPR: Statements for C++. (line 6) 49882* RETURN_STMT: Statements for C++. (line 6) 49883* return_val: Flags. (line 274) 49884* return_val, in call_insn: Flags. (line 24) 49885* return_val, in reg: Flags. (line 89) 49886* return_val, in symbol_ref: Flags. (line 202) 49887* returning aggregate values: Aggregate Return. (line 6) 49888* returning structures and unions: Interface. (line 10) 49889* reverse probability: Profile information. 49890 (line 66) 49891* REVERSE_CONDITION: MODE_CC Condition Codes. 49892 (line 93) 49893* REVERSIBLE_CC_MODE: MODE_CC Condition Codes. 49894 (line 78) 49895* right rotate: Arithmetic. (line 194) 49896* right shift: Arithmetic. (line 189) 49897* rintM2 instruction pattern: Standard Names. (line 720) 49898* RISC: Processor pipeline description. 49899 (line 6) 49900* roots, marking: GGC Roots. (line 6) 49901* rotate: Arithmetic. (line 194) 49902* rotatert: Arithmetic. (line 194) 49903* rotlM3 instruction pattern: Standard Names. (line 568) 49904* rotrM3 instruction pattern: Standard Names. (line 568) 49905* ROUND_DIV_EXPR: Unary and Binary Expressions. 49906 (line 6) 49907* ROUND_MOD_EXPR: Unary and Binary Expressions. 49908 (line 6) 49909* ROUND_TYPE_ALIGN: Storage Layout. (line 432) 49910* roundM2 instruction pattern: Standard Names. (line 696) 49911* RSHIFT_EXPR: Unary and Binary Expressions. 49912 (line 6) 49913* RTL addition: Arithmetic. (line 14) 49914* RTL addition with signed saturation: Arithmetic. (line 14) 49915* RTL addition with unsigned saturation: Arithmetic. (line 14) 49916* RTL classes: RTL Classes. (line 6) 49917* RTL comparison: Arithmetic. (line 43) 49918* RTL comparison operations: Comparisons. (line 6) 49919* RTL constant expression types: Constants. (line 6) 49920* RTL constants: Constants. (line 6) 49921* RTL declarations: RTL Declarations. (line 6) 49922* RTL difference: Arithmetic. (line 36) 49923* RTL expression: RTL Objects. (line 6) 49924* RTL expressions for arithmetic: Arithmetic. (line 6) 49925* RTL format: RTL Classes. (line 72) 49926* RTL format characters: RTL Classes. (line 77) 49927* RTL function-call insns: Calls. (line 6) 49928* RTL insn template: RTL Template. (line 6) 49929* RTL integers: RTL Objects. (line 6) 49930* RTL memory expressions: Regs and Memory. (line 6) 49931* RTL object types: RTL Objects. (line 6) 49932* RTL postdecrement: Incdec. (line 6) 49933* RTL postincrement: Incdec. (line 6) 49934* RTL predecrement: Incdec. (line 6) 49935* RTL preincrement: Incdec. (line 6) 49936* RTL register expressions: Regs and Memory. (line 6) 49937* RTL representation: RTL. (line 6) 49938* RTL side effect expressions: Side Effects. (line 6) 49939* RTL strings: RTL Objects. (line 6) 49940* RTL structure sharing assumptions: Sharing. (line 6) 49941* RTL subtraction: Arithmetic. (line 36) 49942* RTL subtraction with signed saturation: Arithmetic. (line 36) 49943* RTL subtraction with unsigned saturation: Arithmetic. (line 36) 49944* RTL sum: Arithmetic. (line 14) 49945* RTL vectors: RTL Objects. (line 6) 49946* RTL_CONST_CALL_P: Flags. (line 19) 49947* RTL_CONST_OR_PURE_CALL_P: Flags. (line 29) 49948* RTL_LOOPING_CONST_OR_PURE_CALL_P: Flags. (line 33) 49949* RTL_PURE_CALL_P: Flags. (line 24) 49950* RTX (See RTL): RTL Objects. (line 6) 49951* RTX codes, classes of: RTL Classes. (line 6) 49952* RTX_FRAME_RELATED_P: Flags. (line 107) 49953* run-time conventions: Interface. (line 6) 49954* run-time target specification: Run-time Target. (line 6) 49955* s in constraint: Simple Constraints. (line 102) 49956* SAD_EXPR: Vectors. (line 6) 49957* same_type_p: Types. (line 88) 49958* SAmode: Machine Modes. (line 151) 49959* sat_fract: Conversions. (line 90) 49960* satfractMN2 instruction pattern: Standard Names. (line 992) 49961* satfractunsMN2 instruction pattern: Standard Names. (line 1005) 49962* satisfies_constraint_: C Constraint Interface. 49963 (line 37) 49964* SAVE_EXPR: Unary and Binary Expressions. 49965 (line 6) 49966* save_stack_block instruction pattern: Standard Names. (line 1381) 49967* save_stack_function instruction pattern: Standard Names. (line 1381) 49968* save_stack_nonlocal instruction pattern: Standard Names. (line 1381) 49969* SBSS_SECTION_ASM_OP: Sections. (line 76) 49970* Scalar evolutions: Scalar evolutions. (line 6) 49971* scalars, returned as values: Scalar Return. (line 6) 49972* SCHED_GROUP_P: Flags. (line 148) 49973* SCmode: Machine Modes. (line 200) 49974* scratch: Regs and Memory. (line 298) 49975* scratch operands: Regs and Memory. (line 298) 49976* scratch, RTL sharing: Sharing. (line 35) 49977* scratch_operand: Machine-Independent Predicates. 49978 (line 50) 49979* SDATA_SECTION_ASM_OP: Sections. (line 58) 49980* SDB_ALLOW_FORWARD_REFERENCES: SDB and DWARF. (line 128) 49981* SDB_ALLOW_UNKNOWN_REFERENCES: SDB and DWARF. (line 123) 49982* SDB_DEBUGGING_INFO: SDB and DWARF. (line 9) 49983* SDB_DELIM: SDB and DWARF. (line 116) 49984* SDB_OUTPUT_SOURCE_LINE: SDB and DWARF. (line 133) 49985* SDmode: Machine Modes. (line 88) 49986* sdot_prodM instruction pattern: Standard Names. (line 372) 49987* search options: Including Patterns. (line 44) 49988* SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 396) 49989* SECONDARY_MEMORY_NEEDED: Register Classes. (line 452) 49990* SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 471) 49991* SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 462) 49992* SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 397) 49993* SECONDARY_RELOAD_CLASS: Register Classes. (line 395) 49994* SELECT_CC_MODE: MODE_CC Condition Codes. 49995 (line 7) 49996* sequence: Side Effects. (line 260) 49997* Sequence iterators: Sequence iterators. (line 6) 49998* set: Side Effects. (line 15) 49999* set and /f: Flags. (line 107) 50000* SET_ASM_OP: Label Output. (line 426) 50001* set_attr: Tagging Insns. (line 31) 50002* set_attr_alternative: Tagging Insns. (line 49) 50003* set_bb_seq: GIMPLE sequences. (line 76) 50004* SET_DEST: Side Effects. (line 69) 50005* SET_IS_RETURN_P: Flags. (line 157) 50006* SET_LABEL_KIND: Insns. (line 146) 50007* set_optab_libfunc: Library Calls. (line 15) 50008* SET_RATIO: Costs. (line 217) 50009* SET_SRC: Side Effects. (line 69) 50010* set_thread_pointerMODE instruction pattern: Standard Names. 50011 (line 1915) 50012* SET_TYPE_STRUCTURAL_EQUALITY: Types. (line 6) 50013* setmemM instruction pattern: Standard Names. (line 856) 50014* SETUP_FRAME_ADDRESSES: Frame Layout. (line 102) 50015* SFmode: Machine Modes. (line 69) 50016* sharing of RTL components: Sharing. (line 6) 50017* shift: Arithmetic. (line 172) 50018* SHIFT_COUNT_TRUNCATED: Misc. (line 113) 50019* SHLIB_SUFFIX: Macros for Initialization. 50020 (line 135) 50021* SHORT_ACCUM_TYPE_SIZE: Type Layout. (line 83) 50022* SHORT_FRACT_TYPE_SIZE: Type Layout. (line 63) 50023* SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 87) 50024* SHORT_TYPE_SIZE: Type Layout. (line 16) 50025* sibcall_epilogue instruction pattern: Standard Names. (line 1591) 50026* sibling call: Edges. (line 122) 50027* SIBLING_CALL_P: Flags. (line 161) 50028* SIG_ATOMIC_TYPE: Type Layout. (line 215) 50029* sign_extend: Conversions. (line 23) 50030* sign_extract: Bit-Fields. (line 8) 50031* sign_extract, canonicalization of: Insn Canonicalizations. 50032 (line 88) 50033* signed division: Arithmetic. (line 115) 50034* signed division with signed saturation: Arithmetic. (line 115) 50035* signed maximum: Arithmetic. (line 140) 50036* signed minimum: Arithmetic. (line 140) 50037* SImode: Machine Modes. (line 37) 50038* simple constraints: Simple Constraints. (line 6) 50039* simple_return: Side Effects. (line 86) 50040* simple_return instruction pattern: Standard Names. (line 1243) 50041* sincosM3 instruction pattern: Standard Names. (line 632) 50042* sinM2 instruction pattern: Standard Names. (line 624) 50043* SIZE_ASM_OP: Label Output. (line 35) 50044* SIZE_TYPE: Type Layout. (line 138) 50045* SIZETYPE: Type Layout. (line 154) 50046* skip: GTY Options. (line 77) 50047* SLOW_BYTE_ACCESS: Costs. (line 118) 50048* SLOW_UNALIGNED_ACCESS: Costs. (line 133) 50049* smax: Arithmetic. (line 140) 50050* smin: Arithmetic. (line 140) 50051* sms, swing, software pipelining: RTL passes. (line 124) 50052* smulM3_highpart instruction pattern: Standard Names. (line 483) 50053* soft float library: Soft float library routines. 50054 (line 6) 50055* special: GTY Options. (line 237) 50056* special predicates: Predicates. (line 31) 50057* SPECS: Target Fragment. (line 191) 50058* speed of instructions: Costs. (line 6) 50059* split_block: Maintaining the CFG. 50060 (line 99) 50061* splitting instructions: Insn Splitting. (line 6) 50062* SQmode: Machine Modes. (line 114) 50063* sqrt: Arithmetic. (line 206) 50064* sqrtM2 instruction pattern: Standard Names. (line 590) 50065* square root: Arithmetic. (line 206) 50066* ss_abs: Arithmetic. (line 199) 50067* ss_ashift: Arithmetic. (line 172) 50068* ss_div: Arithmetic. (line 115) 50069* ss_minus: Arithmetic. (line 36) 50070* ss_mult: Arithmetic. (line 92) 50071* ss_neg: Arithmetic. (line 81) 50072* ss_plus: Arithmetic. (line 14) 50073* ss_truncate: Conversions. (line 43) 50074* SSA: SSA. (line 6) 50075* SSA_NAME_DEF_STMT: SSA. (line 217) 50076* SSA_NAME_VERSION: SSA. (line 222) 50077* ssaddM3 instruction pattern: Standard Names. (line 269) 50078* ssadM instruction pattern: Standard Names. (line 381) 50079* ssashlM3 instruction pattern: Standard Names. (line 558) 50080* ssdivM3 instruction pattern: Standard Names. (line 269) 50081* ssmaddMN4 instruction pattern: Standard Names. (line 506) 50082* ssmsubMN4 instruction pattern: Standard Names. (line 530) 50083* ssmulM3 instruction pattern: Standard Names. (line 269) 50084* ssnegM2 instruction pattern: Standard Names. (line 580) 50085* sssubM3 instruction pattern: Standard Names. (line 269) 50086* ssum_widenM3 instruction pattern: Standard Names. (line 391) 50087* stack arguments: Stack Arguments. (line 6) 50088* stack frame layout: Frame Layout. (line 6) 50089* stack smashing protection: Stack Smashing Protection. 50090 (line 6) 50091* STACK_ALIGNMENT_NEEDED: Frame Layout. (line 48) 50092* STACK_BOUNDARY: Storage Layout. (line 141) 50093* STACK_CHECK_BUILTIN: Stack Checking. (line 32) 50094* STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 83) 50095* STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 74) 50096* STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 90) 50097* STACK_CHECK_MOVING_SP: Stack Checking. (line 54) 50098* STACK_CHECK_PROBE_INTERVAL_EXP: Stack Checking. (line 46) 50099* STACK_CHECK_PROTECT: Stack Checking. (line 63) 50100* STACK_CHECK_STATIC_BUILTIN: Stack Checking. (line 39) 50101* STACK_DYNAMIC_OFFSET: Frame Layout. (line 75) 50102* STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory. 50103 (line 83) 50104* STACK_GROWS_DOWNWARD: Frame Layout. (line 9) 50105* STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 90) 50106* STACK_POINTER_OFFSET: Frame Layout. (line 58) 50107* STACK_POINTER_OFFSET and virtual registers: Regs and Memory. 50108 (line 93) 50109* STACK_POINTER_REGNUM: Frame Registers. (line 9) 50110* STACK_POINTER_REGNUM and virtual registers: Regs and Memory. 50111 (line 83) 50112* stack_pointer_rtx: Frame Registers. (line 104) 50113* stack_protect_set instruction pattern: Standard Names. (line 1925) 50114* stack_protect_test instruction pattern: Standard Names. (line 1935) 50115* STACK_PUSH_CODE: Frame Layout. (line 17) 50116* STACK_REG_COVER_CLASS: Stack Registers. (line 23) 50117* STACK_REGS: Stack Registers. (line 20) 50118* STACK_SAVEAREA_MODE: Storage Layout. (line 448) 50119* STACK_SIZE_MODE: Storage Layout. (line 459) 50120* STACK_SLOT_ALIGNMENT: Storage Layout. (line 279) 50121* standard pattern names: Standard Names. (line 6) 50122* STANDARD_STARTFILE_PREFIX: Driver. (line 275) 50123* STANDARD_STARTFILE_PREFIX_1: Driver. (line 282) 50124* STANDARD_STARTFILE_PREFIX_2: Driver. (line 289) 50125* STARTFILE_SPEC: Driver. (line 148) 50126* STARTING_FRAME_OFFSET: Frame Layout. (line 39) 50127* STARTING_FRAME_OFFSET and virtual registers: Regs and Memory. 50128 (line 74) 50129* Statement and operand traversals: Statement and operand traversals. 50130 (line 6) 50131* Statement Sequences: Statement Sequences. 50132 (line 6) 50133* statements <1>: Statements for C++. (line 6) 50134* statements: Function Properties. 50135 (line 6) 50136* Statements: Statements. (line 6) 50137* Static profile estimation: Profile information. 50138 (line 24) 50139* static single assignment: SSA. (line 6) 50140* STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 78) 50141* STATIC_CHAIN_REGNUM: Frame Registers. (line 77) 50142* stdarg.h and register arguments: Register Arguments. (line 51) 50143* STDC_0_IN_SYSTEM_HEADERS: Misc. (line 351) 50144* STMT_EXPR: Unary and Binary Expressions. 50145 (line 6) 50146* STMT_IS_FULL_EXPR_P: Statements for C++. (line 22) 50147* storage layout: Storage Layout. (line 6) 50148* STORE_FLAG_VALUE: Misc. (line 202) 50149* store_multiple instruction pattern: Standard Names. (line 160) 50150* strcpy: Storage Layout. (line 231) 50151* STRICT_ALIGNMENT: Storage Layout. (line 329) 50152* strict_low_part: RTL Declarations. (line 9) 50153* strict_memory_address_p: Addressing Modes. (line 187) 50154* STRING_CST: Constant expressions. 50155 (line 6) 50156* STRING_POOL_ADDRESS_P: Flags. (line 165) 50157* strlenM instruction pattern: Standard Names. (line 927) 50158* structure value address: Aggregate Return. (line 6) 50159* STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 321) 50160* structures, returning: Interface. (line 10) 50161* subM3 instruction pattern: Standard Names. (line 269) 50162* SUBOBJECT: Statements for C++. (line 6) 50163* SUBOBJECT_CLEANUP: Statements for C++. (line 6) 50164* subreg: Regs and Memory. (line 97) 50165* subreg and /s: Flags. (line 187) 50166* subreg and /u: Flags. (line 180) 50167* subreg and /u and /v: Flags. (line 170) 50168* subreg, in strict_low_part: RTL Declarations. (line 9) 50169* SUBREG_BYTE: Regs and Memory. (line 289) 50170* SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 170) 50171* SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 180) 50172* SUBREG_PROMOTED_VAR_P: Flags. (line 187) 50173* SUBREG_REG: Regs and Memory. (line 289) 50174* subst iterators in .md files: Subst Iterators. (line 6) 50175* subvM4 instruction pattern: Standard Names. (line 285) 50176* SUCCESS_EXIT_CODE: Host Misc. (line 12) 50177* SUPPORTS_INIT_PRIORITY: Macros for Initialization. 50178 (line 58) 50179* SUPPORTS_ONE_ONLY: Label Output. (line 266) 50180* SUPPORTS_WEAK: Label Output. (line 240) 50181* SWITCH_BODY: Statements for C++. (line 6) 50182* SWITCH_COND: Statements for C++. (line 6) 50183* SWITCH_STMT: Statements for C++. (line 6) 50184* SWITCHABLE_TARGET: Run-time Target. (line 165) 50185* SYMBOL_FLAG_ANCHOR: Special Accessors. (line 120) 50186* SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 102) 50187* SYMBOL_FLAG_FUNCTION: Special Accessors. (line 95) 50188* SYMBOL_FLAG_HAS_BLOCK_INFO: Special Accessors. (line 116) 50189* SYMBOL_FLAG_LOCAL: Special Accessors. (line 98) 50190* SYMBOL_FLAG_SMALL: Special Accessors. (line 107) 50191* SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 111) 50192* symbol_ref: Constants. (line 117) 50193* symbol_ref and /f: Flags. (line 165) 50194* symbol_ref and /i: Flags. (line 202) 50195* symbol_ref and /u: Flags. (line 10) 50196* symbol_ref and /v: Flags. (line 206) 50197* symbol_ref, RTL sharing: Sharing. (line 20) 50198* SYMBOL_REF_ANCHOR_P: Special Accessors. (line 120) 50199* SYMBOL_REF_BLOCK: Special Accessors. (line 133) 50200* SYMBOL_REF_BLOCK_OFFSET: Special Accessors. (line 138) 50201* SYMBOL_REF_CONSTANT: Special Accessors. (line 81) 50202* SYMBOL_REF_DATA: Special Accessors. (line 85) 50203* SYMBOL_REF_DECL: Special Accessors. (line 69) 50204* SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 102) 50205* SYMBOL_REF_FLAG: Flags. (line 206) 50206* SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 277) 50207* SYMBOL_REF_FLAGS: Special Accessors. (line 89) 50208* SYMBOL_REF_FUNCTION_P: Special Accessors. (line 95) 50209* SYMBOL_REF_HAS_BLOCK_INFO_P: Special Accessors. (line 116) 50210* SYMBOL_REF_LOCAL_P: Special Accessors. (line 98) 50211* SYMBOL_REF_SMALL_P: Special Accessors. (line 107) 50212* SYMBOL_REF_TLS_MODEL: Special Accessors. (line 111) 50213* SYMBOL_REF_USED: Flags. (line 197) 50214* SYMBOL_REF_WEAK: Flags. (line 202) 50215* symbolic label: Sharing. (line 20) 50216* sync_addMODE instruction pattern: Standard Names. (line 1690) 50217* sync_andMODE instruction pattern: Standard Names. (line 1690) 50218* sync_compare_and_swapMODE instruction pattern: Standard Names. 50219 (line 1650) 50220* sync_iorMODE instruction pattern: Standard Names. (line 1690) 50221* sync_lock_releaseMODE instruction pattern: Standard Names. (line 1755) 50222* sync_lock_test_and_setMODE instruction pattern: Standard Names. 50223 (line 1729) 50224* sync_nandMODE instruction pattern: Standard Names. (line 1690) 50225* sync_new_addMODE instruction pattern: Standard Names. (line 1722) 50226* sync_new_andMODE instruction pattern: Standard Names. (line 1722) 50227* sync_new_iorMODE instruction pattern: Standard Names. (line 1722) 50228* sync_new_nandMODE instruction pattern: Standard Names. (line 1722) 50229* sync_new_subMODE instruction pattern: Standard Names. (line 1722) 50230* sync_new_xorMODE instruction pattern: Standard Names. (line 1722) 50231* sync_old_addMODE instruction pattern: Standard Names. (line 1705) 50232* sync_old_andMODE instruction pattern: Standard Names. (line 1705) 50233* sync_old_iorMODE instruction pattern: Standard Names. (line 1705) 50234* sync_old_nandMODE instruction pattern: Standard Names. (line 1705) 50235* sync_old_subMODE instruction pattern: Standard Names. (line 1705) 50236* sync_old_xorMODE instruction pattern: Standard Names. (line 1705) 50237* sync_subMODE instruction pattern: Standard Names. (line 1690) 50238* sync_xorMODE instruction pattern: Standard Names. (line 1690) 50239* SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 177) 50240* SYSROOT_SUFFIX_SPEC: Driver. (line 172) 50241* t-TARGET: Target Fragment. (line 6) 50242* table jump: Basic Blocks. (line 67) 50243* tablejump instruction pattern: Standard Names. (line 1316) 50244* tag: GTY Options. (line 88) 50245* tagging insns: Tagging Insns. (line 6) 50246* tail calls: Tail Calls. (line 6) 50247* TAmode: Machine Modes. (line 159) 50248* target attributes: Target Attributes. (line 6) 50249* target description macros: Target Macros. (line 6) 50250* target functions: Target Structure. (line 6) 50251* target hooks: Target Structure. (line 6) 50252* target makefile fragment: Target Fragment. (line 6) 50253* target specifications: Run-time Target. (line 6) 50254* TARGET_ABSOLUTE_BIGGEST_ALIGNMENT: Storage Layout. (line 170) 50255* TARGET_ADDR_SPACE_ADDRESS_MODE: Named Address Spaces. 50256 (line 45) 50257* TARGET_ADDR_SPACE_CONVERT: Named Address Spaces. 50258 (line 88) 50259* TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P: Named Address Spaces. 50260 (line 63) 50261* TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS: Named Address Spaces. 50262 (line 72) 50263* TARGET_ADDR_SPACE_POINTER_MODE: Named Address Spaces. 50264 (line 38) 50265* TARGET_ADDR_SPACE_SUBSET_P: Named Address Spaces. 50266 (line 79) 50267* TARGET_ADDR_SPACE_VALID_POINTER_MODE: Named Address Spaces. 50268 (line 52) 50269* TARGET_ADDRESS_COST: Costs. (line 310) 50270* TARGET_ALIGN_ANON_BITFIELD: Storage Layout. (line 406) 50271* TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 814) 50272* TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS: Misc. (line 1121) 50273* TARGET_ALWAYS_STRIP_DOTDOT: Driver. (line 247) 50274* TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 98) 50275* TARGET_ARM_EABI_UNWINDER: Exception Region Output. 50276 (line 135) 50277* TARGET_ARRAY_MODE_SUPPORTED_P: Register Arguments. (line 349) 50278* TARGET_ASAN_SHADOW_OFFSET: Misc. (line 1149) 50279* TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 10) 50280* TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 8) 50281* TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 9) 50282* TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 11) 50283* TARGET_ASM_ASSEMBLE_UNDEFINED_DECL: Label Output. (line 208) 50284* TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 278) 50285* TARGET_ASM_BYTE_OP: Data Output. (line 7) 50286* TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 207) 50287* TARGET_ASM_CLOSE_PAREN: Data Output. (line 135) 50288* TARGET_ASM_CODE_END: File Framework. (line 59) 50289* TARGET_ASM_CONSTRUCTOR: Macros for Initialization. 50290 (line 69) 50291* TARGET_ASM_DECL_END: Data Output. (line 39) 50292* TARGET_ASM_DECLARE_CONSTANT_NAME: Label Output. (line 154) 50293* TARGET_ASM_DESTRUCTOR: Macros for Initialization. 50294 (line 83) 50295* TARGET_ASM_EMIT_EXCEPT_PERSONALITY: Dispatch Tables. (line 82) 50296* TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL: Dispatch Tables. (line 74) 50297* TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 63) 50298* TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 313) 50299* TARGET_ASM_FILE_END: File Framework. (line 37) 50300* TARGET_ASM_FILE_START: File Framework. (line 9) 50301* TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 17) 50302* TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 31) 50303* TARGET_ASM_FINAL_POSTSCAN_INSN: Instruction Output. (line 84) 50304* TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 61) 50305* TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 55) 50306* TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 68) 50307* TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 11) 50308* TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 215) 50309* TARGET_ASM_FUNCTION_SECTION: File Framework. (line 124) 50310* TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS: File Framework. 50311 (line 134) 50312* TARGET_ASM_GLOBALIZE_DECL_NAME: Label Output. (line 199) 50313* TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 190) 50314* TARGET_ASM_INIT_SECTIONS: Sections. (line 160) 50315* TARGET_ASM_INTEGER: Data Output. (line 27) 50316* TARGET_ASM_INTERNAL_LABEL: Label Output. (line 357) 50317* TARGET_ASM_JUMP_ALIGN_MAX_SKIP: Alignment Output. (line 22) 50318* TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP: Alignment Output. 50319 (line 36) 50320* TARGET_ASM_LABEL_ALIGN_MAX_SKIP: Alignment Output. (line 69) 50321* TARGET_ASM_LOOP_ALIGN_MAX_SKIP: Alignment Output. (line 54) 50322* TARGET_ASM_LTO_END: File Framework. (line 54) 50323* TARGET_ASM_LTO_START: File Framework. (line 49) 50324* TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 320) 50325* TARGET_ASM_MERGEABLE_RODATA_PREFIX: Sections. (line 222) 50326* TARGET_ASM_NAMED_SECTION: File Framework. (line 116) 50327* TARGET_ASM_OPEN_PAREN: Data Output. (line 134) 50328* TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 44) 50329* TARGET_ASM_OUTPUT_ANCHOR: Anchored Addresses. (line 44) 50330* TARGET_ASM_OUTPUT_DWARF_DTPREL: SDB and DWARF. (line 105) 50331* TARGET_ASM_OUTPUT_IDENT: File Framework. (line 102) 50332* TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 165) 50333* TARGET_ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 94) 50334* TARGET_ASM_RECORD_GCC_SWITCHES: File Framework. (line 165) 50335* TARGET_ASM_RECORD_GCC_SWITCHES_SECTION: File Framework. (line 209) 50336* TARGET_ASM_RELOC_RW_MASK: Sections. (line 169) 50337* TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 232) 50338* TARGET_ASM_SELECT_SECTION: Sections. (line 181) 50339* TARGET_ASM_TM_CLONE_TABLE_SECTION: Sections. (line 227) 50340* TARGET_ASM_TRAMPOLINE_TEMPLATE: Trampolines. (line 29) 50341* TARGET_ASM_TTYPE: Exception Region Output. 50342 (line 129) 50343* TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 14) 50344* TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 12) 50345* TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 13) 50346* TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 15) 50347* TARGET_ASM_UNIQUE_SECTION: Sections. (line 202) 50348* TARGET_ASM_UNWIND_EMIT: Dispatch Tables. (line 89) 50349* TARGET_ASM_UNWIND_EMIT_BEFORE_INSN: Dispatch Tables. (line 94) 50350* TARGET_ATOMIC_ALIGN_FOR_MODE: Misc. (line 1169) 50351* TARGET_ATOMIC_ASSIGN_EXPAND_FENV: Misc. (line 1175) 50352* TARGET_ATOMIC_TEST_AND_SET_TRUEVAL: Misc. (line 1159) 50353* TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 11) 50354* TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P: Target Attributes. (line 19) 50355* TARGET_BINDS_LOCAL_P: Sections. (line 309) 50356* TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc. (line 911) 50357* TARGET_BRANCH_TARGET_REGISTER_CLASS: Misc. (line 903) 50358* TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 287) 50359* TARGET_BUILTIN_CHKP_FUNCTION: Misc. (line 624) 50360* TARGET_BUILTIN_DECL: Misc. (line 605) 50361* TARGET_BUILTIN_RECIPROCAL: Addressing Modes. (line 264) 50362* TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 109) 50363* TARGET_C_PREINCLUDE: Misc. (line 362) 50364* TARGET_CALL_ARGS: Varargs. (line 127) 50365* TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS: Miscellaneous Register Hooks. 50366 (line 7) 50367* TARGET_CALLEE_COPIES: Register Arguments. (line 130) 50368* TARGET_CAN_ELIMINATE: Elimination. (line 75) 50369* TARGET_CAN_FOLLOW_JUMP: Misc. (line 801) 50370* TARGET_CAN_INLINE_P: Target Attributes. (line 166) 50371* TARGET_CAN_USE_DOLOOP_P: Misc. (line 767) 50372* TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 237) 50373* TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 890) 50374* TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P: Register Classes. (line 597) 50375* TARGET_CANONICAL_VA_LIST_TYPE: Register Arguments. (line 308) 50376* TARGET_CANONICALIZE_COMPARISON: MODE_CC Condition Codes. 50377 (line 57) 50378* TARGET_CASE_VALUES_THRESHOLD: Misc. (line 47) 50379* TARGET_CC_MODES_COMPATIBLE: MODE_CC Condition Codes. 50380 (line 122) 50381* TARGET_CHECK_PCH_TARGET_FLAGS: PCH Target. (line 28) 50382* TARGET_CHECK_STRING_OBJECT_FORMAT_ARG: Run-time Target. (line 121) 50383* TARGET_CHKP_BOUND_MODE: Misc. (line 699) 50384* TARGET_CHKP_BOUND_TYPE: Misc. (line 696) 50385* TARGET_CHKP_FUNCTION_VALUE_BOUNDS: Varargs. (line 188) 50386* TARGET_CHKP_INITIALIZE_BOUNDS: Misc. (line 708) 50387* TARGET_CHKP_MAKE_BOUNDS_CONSTANT: Misc. (line 703) 50388* TARGET_CLASS_LIKELY_SPILLED_P: Register Classes. (line 494) 50389* TARGET_CLASS_MAX_NREGS: Register Classes. (line 511) 50390* TARGET_COMMUTATIVE_P: Misc. (line 807) 50391* TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 27) 50392* TARGET_COMPARE_VERSION_PRIORITY: Misc. (line 742) 50393* TARGET_CONDITIONAL_REGISTER_USAGE: Register Basics. (line 60) 50394* TARGET_CONST_ANCHOR: Misc. (line 1132) 50395* TARGET_CONST_NOT_OK_FOR_DEBUG_P: Addressing Modes. (line 232) 50396* TARGET_CONVERT_TO_TYPE: Misc. (line 1085) 50397* TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 9) 50398* TARGET_CSTORE_MODE: Register Classes. (line 621) 50399* TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 87) 50400* TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 38) 50401* TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 62) 50402* TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 25) 50403* TARGET_CXX_DECL_MANGLING_CONTEXT: C++ ABI. (line 93) 50404* TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 54) 50405* TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 18) 50406* TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 12) 50407* TARGET_CXX_GUARD_TYPE: C++ ABI. (line 7) 50408* TARGET_CXX_IMPLICIT_EXTERN_C: Misc. (line 374) 50409* TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 30) 50410* TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 43) 50411* TARGET_CXX_LIBRARY_RTTI_COMDAT: C++ ABI. (line 69) 50412* TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 74) 50413* TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT: C++ ABI. (line 80) 50414* TARGET_DEBUG_UNWIND_INFO: SDB and DWARF. (line 37) 50415* TARGET_DECIMAL_FLOAT_SUPPORTED_P: Storage Layout. (line 512) 50416* TARGET_DECLSPEC: Target Attributes. (line 73) 50417* TARGET_DEFAULT_PACK_STRUCT: Misc. (line 448) 50418* TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 130) 50419* TARGET_DEFAULT_TARGET_FLAGS: Run-time Target. (line 56) 50420* TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 441) 50421* TARGET_DELAY_SCHED2: SDB and DWARF. (line 66) 50422* TARGET_DELAY_VARTRACK: SDB and DWARF. (line 70) 50423* TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 223) 50424* TARGET_DIFFERENT_ADDR_DISPLACEMENT_P: Register Classes. (line 590) 50425* TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 55) 50426* TARGET_DWARF_CALLING_CONVENTION: SDB and DWARF. (line 18) 50427* TARGET_DWARF_FRAME_REG_MODE: Exception Region Output. 50428 (line 115) 50429* TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 174) 50430* TARGET_DWARF_REGISTER_SPAN: Exception Region Output. 50431 (line 106) 50432* TARGET_EDOM: Library Calls. (line 60) 50433* TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS: Emulated TLS. (line 68) 50434* TARGET_EMUTLS_GET_ADDRESS: Emulated TLS. (line 19) 50435* TARGET_EMUTLS_REGISTER_COMMON: Emulated TLS. (line 24) 50436* TARGET_EMUTLS_TMPL_PREFIX: Emulated TLS. (line 45) 50437* TARGET_EMUTLS_TMPL_SECTION: Emulated TLS. (line 36) 50438* TARGET_EMUTLS_VAR_ALIGN_FIXED: Emulated TLS. (line 63) 50439* TARGET_EMUTLS_VAR_FIELDS: Emulated TLS. (line 49) 50440* TARGET_EMUTLS_VAR_INIT: Emulated TLS. (line 57) 50441* TARGET_EMUTLS_VAR_PREFIX: Emulated TLS. (line 41) 50442* TARGET_EMUTLS_VAR_SECTION: Emulated TLS. (line 31) 50443* TARGET_ENCODE_SECTION_INFO: Sections. (line 253) 50444* TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes. 50445 (line 83) 50446* TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 128) 50447* TARGET_END_CALL_ARGS: Varargs. (line 141) 50448* TARGET_ENUM_VA_LIST_P: Register Arguments. (line 292) 50449* TARGET_EXCEPT_UNWIND_INFO: Exception Region Output. 50450 (line 48) 50451* TARGET_EXECUTABLE_SUFFIX: Misc. (line 864) 50452* TARGET_EXPAND_BUILTIN: Misc. (line 615) 50453* TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 67) 50454* TARGET_EXPAND_TO_RTL_HOOK: Storage Layout. (line 518) 50455* TARGET_EXPR: Unary and Binary Expressions. 50456 (line 6) 50457* TARGET_EXTRA_INCLUDES: Misc. (line 978) 50458* TARGET_EXTRA_LIVE_ON_ENTRY: Tail Calls. (line 21) 50459* TARGET_EXTRA_PRE_INCLUDES: Misc. (line 985) 50460* TARGET_FIXED_CONDITION_CODE_REGS: MODE_CC Condition Codes. 50461 (line 107) 50462* TARGET_FIXED_POINT_SUPPORTED_P: Storage Layout. (line 515) 50463* target_flags: Run-time Target. (line 52) 50464* TARGET_FLAGS_REGNUM: MODE_CC Condition Codes. 50465 (line 134) 50466* TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P: Run-time Target. 50467 (line 185) 50468* TARGET_FLT_EVAL_METHOD: Type Layout. (line 111) 50469* TARGET_FN_ABI_VA_LIST: Register Arguments. (line 303) 50470* TARGET_FOLD_BUILTIN: Misc. (line 725) 50471* TARGET_FORCE_AT_COMP_DIR: SDB and DWARF. (line 61) 50472* TARGET_FORMAT_TYPES: Misc. (line 1005) 50473* TARGET_FRAME_POINTER_REQUIRED: Elimination. (line 9) 50474* TARGET_FUNCTION_ARG: Register Arguments. (line 12) 50475* TARGET_FUNCTION_ARG_ADVANCE: Register Arguments. (line 201) 50476* TARGET_FUNCTION_ARG_BOUNDARY: Register Arguments. (line 255) 50477* TARGET_FUNCTION_ARG_ROUND_BOUNDARY: Register Arguments. (line 261) 50478* TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 95) 50479* TARGET_FUNCTION_INCOMING_ARG: Register Arguments. (line 74) 50480* TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 8) 50481* TARGET_FUNCTION_VALUE: Scalar Return. (line 11) 50482* TARGET_FUNCTION_VALUE_REGNO_P: Scalar Return. (line 97) 50483* TARGET_GEN_CCMP_FIRST: Misc. (line 932) 50484* TARGET_GEN_CCMP_NEXT: Misc. (line 943) 50485* TARGET_GENERATE_VERSION_DISPATCHER_BODY: Misc. (line 759) 50486* TARGET_GET_DRAP_RTX: Misc. (line 1115) 50487* TARGET_GET_FUNCTION_VERSIONS_DISPATCHER: Misc. (line 752) 50488* TARGET_GET_PCH_VALIDITY: PCH Target. (line 7) 50489* TARGET_GET_RAW_ARG_MODE: Aggregate Return. (line 82) 50490* TARGET_GET_RAW_RESULT_MODE: Aggregate Return. (line 77) 50491* TARGET_GIMPLE_FOLD_BUILTIN: Misc. (line 735) 50492* TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 314) 50493* TARGET_HANDLE_C_OPTION: Run-time Target. (line 75) 50494* TARGET_HANDLE_OPTION: Run-time Target. (line 62) 50495* TARGET_HARD_REGNO_SCRATCH_OK: Values in Registers. 50496 (line 144) 50497* TARGET_HAS_IFUNC_P: Misc. (line 1163) 50498* TARGET_HAS_NO_HW_DIVIDE: Library Calls. (line 53) 50499* TARGET_HAVE_CONDITIONAL_EXECUTION: Misc. (line 925) 50500* TARGET_HAVE_CTORS_DTORS: Macros for Initialization. 50501 (line 64) 50502* TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 141) 50503* TARGET_HAVE_SRODATA_SECTION: Sections. (line 298) 50504* TARGET_HAVE_SWITCHABLE_BSS_SECTIONS: File Framework. (line 146) 50505* TARGET_HAVE_TLS: Sections. (line 318) 50506* TARGET_IN_SMALL_DATA_P: Sections. (line 294) 50507* TARGET_INIT_BUILTINS: Misc. (line 588) 50508* TARGET_INIT_DWARF_REG_SIZES_EXTRA: Exception Region Output. 50509 (line 121) 50510* TARGET_INIT_LIBFUNCS: Library Calls. (line 16) 50511* TARGET_INIT_PIC_REG: Register Arguments. (line 93) 50512* TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 82) 50513* TARGET_INSTANTIATE_DECLS: Storage Layout. (line 526) 50514* TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN: Misc. (line 1039) 50515* TARGET_INVALID_BINARY_OP: Misc. (line 1058) 50516* TARGET_INVALID_CONVERSION: Misc. (line 1045) 50517* TARGET_INVALID_PARAMETER_TYPE: Misc. (line 1064) 50518* TARGET_INVALID_RETURN_TYPE: Misc. (line 1071) 50519* TARGET_INVALID_UNARY_OP: Misc. (line 1051) 50520* TARGET_INVALID_WITHIN_DOLOOP: Misc. (line 783) 50521* TARGET_KEEP_LEAF_WHEN_PROFILED: Profiling. (line 40) 50522* TARGET_LEGITIMATE_ADDRESS_P: Addressing Modes. (line 50) 50523* TARGET_LEGITIMATE_COMBINED_INSN: Misc. (line 795) 50524* TARGET_LEGITIMATE_CONSTANT_P: Addressing Modes. (line 216) 50525* TARGET_LEGITIMIZE_ADDRESS: Addressing Modes. (line 132) 50526* TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT: Register Classes. (line 607) 50527* TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 43) 50528* TARGET_LIBC_HAS_FUNCTION: Library Calls. (line 79) 50529* TARGET_LIBCALL_VALUE: Scalar Return. (line 66) 50530* TARGET_LIBFUNC_GNU_PREFIX: Library Calls. (line 25) 50531* TARGET_LIBGCC_CMP_RETURN_MODE: Storage Layout. (line 468) 50532* TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P: Register Arguments. 50533 (line 373) 50534* TARGET_LIBGCC_SDATA_SECTION: Sections. (line 132) 50535* TARGET_LIBGCC_SHIFT_COUNT_MODE: Storage Layout. (line 474) 50536* TARGET_LOAD_BOUNDS_FOR_ARG: Varargs. (line 158) 50537* TARGET_LOAD_RETURNED_BOUNDS: Varargs. (line 177) 50538* TARGET_LOOP_UNROLL_ADJUST: Misc. (line 959) 50539* TARGET_LRA_P: Register Classes. (line 563) 50540* TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 573) 50541* TARGET_MANGLE_ASSEMBLER_NAME: Label Output. (line 332) 50542* TARGET_MANGLE_DECL_ASSEMBLER_NAME: Sections. (line 243) 50543* TARGET_MANGLE_TYPE: Storage Layout. (line 530) 50544* TARGET_MAX_ANCHOR_OFFSET: Anchored Addresses. (line 39) 50545* TARGET_MD_ASM_CLOBBERS: Misc. (line 494) 50546* TARGET_MEM_CONSTRAINT: Addressing Modes. (line 109) 50547* TARGET_MEM_REF: Storage References. (line 6) 50548* TARGET_MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 421) 50549* TARGET_MEMMODEL_CHECK: Misc. (line 1155) 50550* TARGET_MEMORY_MOVE_COST: Costs. (line 81) 50551* TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 47) 50552* TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 39) 50553* TARGET_MIN_ANCHOR_OFFSET: Anchored Addresses. (line 33) 50554* TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 92) 50555* TARGET_MODE_AFTER: Mode Switching. (line 59) 50556* TARGET_MODE_DEPENDENT_ADDRESS_P: Addressing Modes. (line 199) 50557* TARGET_MODE_EMIT: Mode Switching. (line 44) 50558* TARGET_MODE_ENTRY: Mode Switching. (line 65) 50559* TARGET_MODE_EXIT: Mode Switching. (line 72) 50560* TARGET_MODE_NEEDED: Mode Switching. (line 51) 50561* TARGET_MODE_PRIORITY: Mode Switching. (line 79) 50562* TARGET_MODE_REP_EXTENDED: Misc. (line 177) 50563* TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 485) 50564* TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 67) 50565* TARGET_MUST_PASS_IN_STACK, and TARGET_FUNCTION_ARG: Register Arguments. 50566 (line 57) 50567* TARGET_N_FORMAT_TYPES: Misc. (line 1010) 50568* TARGET_NARROW_VOLATILE_BITFIELD: Storage Layout. (line 412) 50569* TARGET_NO_REGISTER_ALLOCATION: SDB and DWARF. (line 74) 50570* TARGET_OBJC_CONSTRUCT_STRING_OBJECT: Run-time Target. (line 90) 50571* TARGET_OBJC_DECLARE_CLASS_DEFINITION: Run-time Target. (line 111) 50572* TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE: Run-time Target. 50573 (line 106) 50574* TARGET_OBJECT_SUFFIX: Misc. (line 859) 50575* TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 46) 50576* TARGET_OFFLOAD_OPTIONS: Misc. (line 1199) 50577* TARGET_OMIT_STRUCT_RETURN_REG: Scalar Return. (line 117) 50578* TARGET_OPTF: Misc. (line 992) 50579* TARGET_OPTION_DEFAULT_PARAMS: Run-time Target. (line 161) 50580* TARGET_OPTION_FUNCTION_VERSIONS: Target Attributes. (line 159) 50581* TARGET_OPTION_INIT_STRUCT: Run-time Target. (line 158) 50582* TARGET_OPTION_OPTIMIZATION_TABLE: Run-time Target. (line 144) 50583* TARGET_OPTION_OVERRIDE: Target Attributes. (line 145) 50584* TARGET_OPTION_POST_STREAM_IN: Target Attributes. (line 127) 50585* TARGET_OPTION_PRAGMA_PARSE: Target Attributes. (line 139) 50586* TARGET_OPTION_PRINT: Target Attributes. (line 133) 50587* TARGET_OPTION_RESTORE: Target Attributes. (line 121) 50588* TARGET_OPTION_SAVE: Target Attributes. (line 114) 50589* TARGET_OPTION_VALID_ATTRIBUTE_P: Target Attributes. (line 102) 50590* TARGET_OS_CPP_BUILTINS: Run-time Target. (line 42) 50591* TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE: Run-time Target. (line 127) 50592* TARGET_OVERRIDES_FORMAT_ATTRIBUTES: Misc. (line 1014) 50593* TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc. (line 1020) 50594* TARGET_OVERRIDES_FORMAT_INIT: Misc. (line 1024) 50595* TARGET_PASS_BY_REFERENCE: Register Arguments. (line 118) 50596* TARGET_PCH_VALID_P: PCH Target. (line 13) 50597* TARGET_POSIX_IO: Misc. (line 518) 50598* TARGET_PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 289) 50599* TARGET_PREFERRED_RELOAD_CLASS: Register Classes. (line 218) 50600* TARGET_PREFERRED_RENAME_CLASS: Register Classes. (line 206) 50601* TARGET_PREPARE_PCH_SAVE: PCH Target. (line 35) 50602* TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 149) 50603* TARGET_PROFILE_BEFORE_PROLOGUE: Sections. (line 302) 50604* TARGET_PROMOTE_FUNCTION_MODE: Storage Layout. (line 113) 50605* TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 11) 50606* TARGET_PROMOTED_TYPE: Misc. (line 1077) 50607* TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 258) 50608* TARGET_RECORD_OFFLOAD_SYMBOL: Misc. (line 1193) 50609* TARGET_REF_MAY_ALIAS_ERRNO: Register Arguments. (line 325) 50610* TARGET_REGISTER_MOVE_COST: Costs. (line 33) 50611* TARGET_REGISTER_PRIORITY: Register Classes. (line 568) 50612* TARGET_REGISTER_USAGE_LEVELING_P: Register Classes. (line 580) 50613* TARGET_RELAXED_ORDERING: Misc. (line 1029) 50614* TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 714) 50615* TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 17) 50616* TARGET_RETURN_IN_MSB: Scalar Return. (line 124) 50617* TARGET_RETURN_POPS_ARGS: Stack Arguments. (line 100) 50618* TARGET_RTX_COSTS: Costs. (line 279) 50619* TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 332) 50620* TARGET_SCHED_ADJUST_COST: Scheduling. (line 37) 50621* TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 52) 50622* TARGET_SCHED_ALLOC_SCHED_CONTEXT: Scheduling. (line 297) 50623* TARGET_SCHED_CLEAR_SCHED_CONTEXT: Scheduling. (line 312) 50624* TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 103) 50625* TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 258) 50626* TARGET_SCHED_DFA_POST_ADVANCE_CYCLE: Scheduling. (line 174) 50627* TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 158) 50628* TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE: Scheduling. (line 167) 50629* TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 146) 50630* TARGET_SCHED_DISPATCH: Scheduling. (line 366) 50631* TARGET_SCHED_DISPATCH_DO: Scheduling. (line 371) 50632* TARGET_SCHED_EXPOSED_PIPELINE: Scheduling. (line 375) 50633* TARGET_SCHED_FINISH: Scheduling. (line 123) 50634* TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 140) 50635* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK: Scheduling. (line 237) 50636* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN: Scheduling. (line 226) 50637* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling. 50638 (line 182) 50639* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling. 50640 (line 211) 50641* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END: Scheduling. (line 242) 50642* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI: Scheduling. (line 252) 50643* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT: Scheduling. (line 247) 50644* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE: Scheduling. (line 232) 50645* TARGET_SCHED_FREE_SCHED_CONTEXT: Scheduling. (line 316) 50646* TARGET_SCHED_FUSION_PRIORITY: Scheduling. (line 386) 50647* TARGET_SCHED_GEN_SPEC_CHECK: Scheduling. (line 339) 50648* TARGET_SCHED_H_I_D_EXTENDED: Scheduling. (line 292) 50649* TARGET_SCHED_INIT: Scheduling. (line 113) 50650* TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 163) 50651* TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 155) 50652* TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 132) 50653* TARGET_SCHED_INIT_SCHED_CONTEXT: Scheduling. (line 302) 50654* TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 269) 50655* TARGET_SCHED_ISSUE_RATE: Scheduling. (line 12) 50656* TARGET_SCHED_MACRO_FUSION_P: Scheduling. (line 88) 50657* TARGET_SCHED_MACRO_FUSION_PAIR_P: Scheduling. (line 93) 50658* TARGET_SCHED_NEEDS_BLOCK_P: Scheduling. (line 332) 50659* TARGET_SCHED_REASSOCIATION_WIDTH: Scheduling. (line 381) 50660* TARGET_SCHED_REORDER: Scheduling. (line 60) 50661* TARGET_SCHED_REORDER2: Scheduling. (line 77) 50662* TARGET_SCHED_SET_SCHED_CONTEXT: Scheduling. (line 308) 50663* TARGET_SCHED_SET_SCHED_FLAGS: Scheduling. (line 351) 50664* TARGET_SCHED_SMS_RES_MII: Scheduling. (line 357) 50665* TARGET_SCHED_SPECULATE_INSN: Scheduling. (line 320) 50666* TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 24) 50667* TARGET_SECONDARY_RELOAD: Register Classes. (line 318) 50668* TARGET_SECTION_TYPE_FLAGS: File Framework. (line 152) 50669* TARGET_SET_CURRENT_FUNCTION: Misc. (line 841) 50670* TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 34) 50671* TARGET_SET_UP_BY_PROLOGUE: Tail Calls. (line 31) 50672* TARGET_SETUP_INCOMING_VARARG_BOUNDS: Varargs. (line 195) 50673* TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 76) 50674* TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 140) 50675* TARGET_SIMD_CLONE_ADJUST: Addressing Modes. (line 418) 50676* TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN: Addressing Modes. 50677 (line 411) 50678* TARGET_SIMD_CLONE_USABLE: Addressing Modes. (line 422) 50679* TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P: Register Arguments. 50680 (line 381) 50681* TARGET_SPILL_CLASS: Register Classes. (line 615) 50682* TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 275) 50683* TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection. 50684 (line 17) 50685* TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection. 50686 (line 7) 50687* TARGET_STATIC_CHAIN: Frame Registers. (line 92) 50688* TARGET_STORE_BOUNDS_FOR_ARG: Varargs. (line 168) 50689* TARGET_STORE_RETURNED_BOUNDS: Varargs. (line 183) 50690* TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 112) 50691* TARGET_STRING_OBJECT_REF_TYPE_P: Run-time Target. (line 116) 50692* TARGET_STRIP_NAME_ENCODING: Sections. (line 290) 50693* TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 45) 50694* TARGET_SUPPORTS_SPLIT_STACK: Stack Smashing Protection. 50695 (line 27) 50696* TARGET_SUPPORTS_WEAK: Label Output. (line 248) 50697* TARGET_SUPPORTS_WIDE_INT: Misc. (line 1208) 50698* TARGET_TERMINATE_DW2_EH_FRAME_INFO: Exception Region Output. 50699 (line 100) 50700* TARGET_TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 75) 50701* TARGET_TRAMPOLINE_INIT: Trampolines. (line 56) 50702* TARGET_UNSPEC_MAY_TRAP_P: Misc. (line 833) 50703* TARGET_UNWIND_TABLES_DEFAULT: Exception Region Output. 50704 (line 74) 50705* TARGET_UNWIND_WORD_MODE: Storage Layout. (line 480) 50706* TARGET_UPDATE_STACK_BOUNDARY: Misc. (line 1111) 50707* TARGET_USE_ANCHORS_FOR_SYMBOL_P: Anchored Addresses. (line 55) 50708* TARGET_USE_BLOCKS_FOR_CONSTANT_P: Addressing Modes. (line 251) 50709* TARGET_USE_BLOCKS_FOR_DECL_P: Addressing Modes. (line 257) 50710* TARGET_USE_BY_PIECES_INFRASTRUCTURE_P: Costs. (line 167) 50711* TARGET_USE_JCR_SECTION: Misc. (line 1093) 50712* TARGET_USE_PSEUDO_PIC_REG: Register Arguments. (line 89) 50713* TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 126) 50714* TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 68) 50715* TARGET_VALID_POINTER_MODE: Register Arguments. (line 320) 50716* TARGET_VECTOR_ALIGNMENT: Storage Layout. (line 272) 50717* TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 343) 50718* TARGET_VECTORIZE_ADD_STMT_COST: Addressing Modes. (line 373) 50719* TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES: Addressing Modes. 50720 (line 353) 50721* TARGET_VECTORIZE_BUILTIN_CONVERSION: Addressing Modes. (line 315) 50722* TARGET_VECTORIZE_BUILTIN_GATHER: Addressing Modes. (line 404) 50723* TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 273) 50724* TARGET_VECTORIZE_BUILTIN_TM_LOAD: Addressing Modes. (line 395) 50725* TARGET_VECTORIZE_BUILTIN_TM_STORE: Addressing Modes. (line 399) 50726* TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST: Addressing Modes. 50727 (line 300) 50728* TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION: Addressing Modes. 50729 (line 327) 50730* TARGET_VECTORIZE_DESTROY_COST_DATA: Addressing Modes. (line 390) 50731* TARGET_VECTORIZE_FINISH_COST: Addressing Modes. (line 384) 50732* TARGET_VECTORIZE_INIT_COST: Addressing Modes. (line 361) 50733* TARGET_VECTORIZE_PREFERRED_SIMD_MODE: Addressing Modes. (line 346) 50734* TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT: Addressing Modes. 50735 (line 337) 50736* TARGET_VECTORIZE_VEC_PERM_CONST_OK: Addressing Modes. (line 311) 50737* TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE: Addressing Modes. 50738 (line 306) 50739* TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 311) 50740* TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 305) 50741* TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 294) 50742* TARGET_WANT_DEBUG_PUB_SECTIONS: SDB and DWARF. (line 56) 50743* TARGET_WARN_FUNC_RETURN: Tail Calls. (line 36) 50744* TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 284) 50745* targetm: Target Structure. (line 7) 50746* targets, makefile: Makefile. (line 6) 50747* TCmode: Machine Modes. (line 200) 50748* TDmode: Machine Modes. (line 97) 50749* TEMPLATE_DECL: Declarations. (line 6) 50750* Temporaries: Temporaries. (line 6) 50751* termination routines: Initialization. (line 6) 50752* testing constraints: C Constraint Interface. 50753 (line 6) 50754* TEXT_SECTION_ASM_OP: Sections. (line 38) 50755* TFmode: Machine Modes. (line 101) 50756* The Language: The Language. (line 6) 50757* THEN_CLAUSE: Statements for C++. (line 6) 50758* THREAD_MODEL_SPEC: Driver. (line 163) 50759* THROW_EXPR: Unary and Binary Expressions. 50760 (line 6) 50761* THUNK_DECL: Declarations. (line 6) 50762* THUNK_DELTA: Declarations. (line 6) 50763* TImode: Machine Modes. (line 48) 50764* TImode, in insn: Insns. (line 272) 50765* TLS_COMMON_ASM_OP: Sections. (line 81) 50766* TLS_SECTION_ASM_FLAG: Sections. (line 86) 50767* tm.h macros: Target Macros. (line 6) 50768* TQFmode: Machine Modes. (line 65) 50769* TQmode: Machine Modes. (line 122) 50770* TRAMPOLINE_ALIGNMENT: Trampolines. (line 49) 50771* TRAMPOLINE_SECTION: Trampolines. (line 40) 50772* TRAMPOLINE_SIZE: Trampolines. (line 45) 50773* trampolines for nested functions: Trampolines. (line 6) 50774* TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 111) 50775* trap instruction pattern: Standard Names. (line 1601) 50776* tree <1>: Macros and Functions. 50777 (line 6) 50778* tree: Tree overview. (line 6) 50779* Tree SSA: Tree SSA. (line 6) 50780* TREE_CHAIN: Macros and Functions. 50781 (line 6) 50782* TREE_CODE: Tree overview. (line 6) 50783* tree_fits_shwi_p: Constant expressions. 50784 (line 6) 50785* tree_fits_uhwi_p: Constant expressions. 50786 (line 6) 50787* TREE_INT_CST_ELT: Constant expressions. 50788 (line 6) 50789* tree_int_cst_equal: Constant expressions. 50790 (line 6) 50791* TREE_INT_CST_LOW: Constant expressions. 50792 (line 6) 50793* tree_int_cst_lt: Constant expressions. 50794 (line 6) 50795* TREE_INT_CST_NUNITS: Constant expressions. 50796 (line 6) 50797* TREE_LIST: Containers. (line 6) 50798* TREE_OPERAND: Expression trees. (line 6) 50799* TREE_PUBLIC <1>: Function Properties. 50800 (line 28) 50801* TREE_PUBLIC: Function Basics. (line 6) 50802* TREE_PURPOSE: Containers. (line 6) 50803* TREE_READONLY: Function Properties. 50804 (line 37) 50805* tree_size: Macros and Functions. 50806 (line 13) 50807* TREE_STATIC: Function Properties. 50808 (line 31) 50809* TREE_STRING_LENGTH: Constant expressions. 50810 (line 6) 50811* TREE_STRING_POINTER: Constant expressions. 50812 (line 6) 50813* TREE_THIS_VOLATILE: Function Properties. 50814 (line 34) 50815* tree_to_shwi: Constant expressions. 50816 (line 6) 50817* tree_to_uhwi: Constant expressions. 50818 (line 6) 50819* TREE_TYPE <1>: Types for C++. (line 6) 50820* TREE_TYPE <2>: Function Basics. (line 47) 50821* TREE_TYPE <3>: Expression trees. (line 6) 50822* TREE_TYPE <4>: Working with declarations. 50823 (line 11) 50824* TREE_TYPE <5>: Types. (line 6) 50825* TREE_TYPE: Macros and Functions. 50826 (line 6) 50827* TREE_VALUE: Containers. (line 6) 50828* TREE_VEC: Containers. (line 6) 50829* TREE_VEC_ELT: Containers. (line 6) 50830* TREE_VEC_LENGTH: Containers. (line 6) 50831* TRULY_NOOP_TRUNCATION: Misc. (line 163) 50832* TRUNC_DIV_EXPR: Unary and Binary Expressions. 50833 (line 6) 50834* TRUNC_MOD_EXPR: Unary and Binary Expressions. 50835 (line 6) 50836* truncate: Conversions. (line 38) 50837* truncMN2 instruction pattern: Standard Names. (line 970) 50838* TRUTH_AND_EXPR: Unary and Binary Expressions. 50839 (line 6) 50840* TRUTH_ANDIF_EXPR: Unary and Binary Expressions. 50841 (line 6) 50842* TRUTH_NOT_EXPR: Unary and Binary Expressions. 50843 (line 6) 50844* TRUTH_OR_EXPR: Unary and Binary Expressions. 50845 (line 6) 50846* TRUTH_ORIF_EXPR: Unary and Binary Expressions. 50847 (line 6) 50848* TRUTH_XOR_EXPR: Unary and Binary Expressions. 50849 (line 6) 50850* TRY_BLOCK: Statements for C++. (line 6) 50851* TRY_HANDLERS: Statements for C++. (line 6) 50852* TRY_STMTS: Statements for C++. (line 6) 50853* Tuple specific accessors: Tuple specific accessors. 50854 (line 6) 50855* tuples: Tuple representation. 50856 (line 6) 50857* type: Types. (line 6) 50858* type declaration: Declarations. (line 6) 50859* TYPE_ALIGN <1>: Types for C++. (line 6) 50860* TYPE_ALIGN: Types. (line 6) 50861* TYPE_ARG_TYPES <1>: Types for C++. (line 6) 50862* TYPE_ARG_TYPES: Types. (line 6) 50863* TYPE_ASM_OP: Label Output. (line 79) 50864* TYPE_ATTRIBUTES: Attributes. (line 25) 50865* TYPE_BINFO: Classes. (line 6) 50866* TYPE_BUILT_IN: Types for C++. (line 68) 50867* TYPE_CANONICAL: Types. (line 6) 50868* TYPE_CONTEXT <1>: Types for C++. (line 6) 50869* TYPE_CONTEXT: Types. (line 6) 50870* TYPE_DECL: Declarations. (line 6) 50871* TYPE_FIELDS <1>: Classes. (line 6) 50872* TYPE_FIELDS <2>: Types for C++. (line 6) 50873* TYPE_FIELDS: Types. (line 6) 50874* TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 96) 50875* TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 81) 50876* TYPE_HAS_MUTABLE_P: Classes. (line 86) 50877* TYPE_HAS_NEW_OPERATOR: Classes. (line 93) 50878* TYPE_MAIN_VARIANT <1>: Types for C++. (line 6) 50879* TYPE_MAIN_VARIANT: Types. (line 6) 50880* TYPE_MAX_VALUE: Types. (line 6) 50881* TYPE_METHOD_BASETYPE <1>: Types for C++. (line 6) 50882* TYPE_METHOD_BASETYPE: Types. (line 6) 50883* TYPE_METHODS: Classes. (line 6) 50884* TYPE_MIN_VALUE: Types. (line 6) 50885* TYPE_NAME <1>: Types for C++. (line 6) 50886* TYPE_NAME: Types. (line 6) 50887* TYPE_NOTHROW_P: Functions for C++. (line 154) 50888* TYPE_OFFSET_BASETYPE <1>: Types for C++. (line 6) 50889* TYPE_OFFSET_BASETYPE: Types. (line 6) 50890* TYPE_OPERAND_FMT: Label Output. (line 90) 50891* TYPE_OVERLOADS_ARRAY_REF: Classes. (line 104) 50892* TYPE_OVERLOADS_ARROW: Classes. (line 107) 50893* TYPE_OVERLOADS_CALL_EXPR: Classes. (line 100) 50894* TYPE_POLYMORPHIC_P: Classes. (line 77) 50895* TYPE_PRECISION <1>: Types for C++. (line 6) 50896* TYPE_PRECISION: Types. (line 6) 50897* TYPE_PTR_P: Types for C++. (line 74) 50898* TYPE_PTRDATAMEM_P: Types for C++. (line 6) 50899* TYPE_PTRFN_P: Types for C++. (line 78) 50900* TYPE_PTROB_P: Types for C++. (line 81) 50901* TYPE_PTROBV_P: Types for C++. (line 6) 50902* TYPE_QUAL_CONST <1>: Types for C++. (line 6) 50903* TYPE_QUAL_CONST: Types. (line 6) 50904* TYPE_QUAL_RESTRICT <1>: Types for C++. (line 6) 50905* TYPE_QUAL_RESTRICT: Types. (line 6) 50906* TYPE_QUAL_VOLATILE <1>: Types for C++. (line 6) 50907* TYPE_QUAL_VOLATILE: Types. (line 6) 50908* TYPE_RAISES_EXCEPTIONS: Functions for C++. (line 149) 50909* TYPE_SIZE <1>: Types for C++. (line 6) 50910* TYPE_SIZE: Types. (line 6) 50911* TYPE_STRUCTURAL_EQUALITY_P: Types. (line 6) 50912* TYPE_UNQUALIFIED <1>: Types for C++. (line 6) 50913* TYPE_UNQUALIFIED: Types. (line 6) 50914* TYPE_VFIELD: Classes. (line 6) 50915* TYPENAME_TYPE: Types for C++. (line 6) 50916* TYPENAME_TYPE_FULLNAME <1>: Types for C++. (line 6) 50917* TYPENAME_TYPE_FULLNAME: Types. (line 6) 50918* TYPEOF_TYPE: Types for C++. (line 6) 50919* UDAmode: Machine Modes. (line 171) 50920* udiv: Arithmetic. (line 129) 50921* udivM3 instruction pattern: Standard Names. (line 269) 50922* udivmodM4 instruction pattern: Standard Names. (line 555) 50923* udot_prodM instruction pattern: Standard Names. (line 373) 50924* UDQmode: Machine Modes. (line 139) 50925* UHAmode: Machine Modes. (line 163) 50926* UHQmode: Machine Modes. (line 131) 50927* UINT16_TYPE: Type Layout. (line 221) 50928* UINT32_TYPE: Type Layout. (line 222) 50929* UINT64_TYPE: Type Layout. (line 223) 50930* UINT8_TYPE: Type Layout. (line 220) 50931* UINT_FAST16_TYPE: Type Layout. (line 237) 50932* UINT_FAST32_TYPE: Type Layout. (line 238) 50933* UINT_FAST64_TYPE: Type Layout. (line 239) 50934* UINT_FAST8_TYPE: Type Layout. (line 236) 50935* UINT_LEAST16_TYPE: Type Layout. (line 229) 50936* UINT_LEAST32_TYPE: Type Layout. (line 230) 50937* UINT_LEAST64_TYPE: Type Layout. (line 231) 50938* UINT_LEAST8_TYPE: Type Layout. (line 228) 50939* UINTMAX_TYPE: Type Layout. (line 204) 50940* UINTPTR_TYPE: Type Layout. (line 241) 50941* umaddMN4 instruction pattern: Standard Names. (line 502) 50942* umax: Arithmetic. (line 148) 50943* umaxM3 instruction pattern: Standard Names. (line 269) 50944* umin: Arithmetic. (line 148) 50945* uminM3 instruction pattern: Standard Names. (line 269) 50946* umod: Arithmetic. (line 135) 50947* umodM3 instruction pattern: Standard Names. (line 269) 50948* umsubMN4 instruction pattern: Standard Names. (line 526) 50949* umulhisi3 instruction pattern: Standard Names. (line 474) 50950* umulM3_highpart instruction pattern: Standard Names. (line 488) 50951* umulqihi3 instruction pattern: Standard Names. (line 474) 50952* umulsidi3 instruction pattern: Standard Names. (line 474) 50953* umulvM4 instruction pattern: Standard Names. (line 288) 50954* unchanging: Flags. (line 296) 50955* unchanging, in call_insn: Flags. (line 19) 50956* unchanging, in jump_insn, call_insn and insn: Flags. (line 39) 50957* unchanging, in mem: Flags. (line 134) 50958* unchanging, in subreg: Flags. (line 170) 50959* unchanging, in symbol_ref: Flags. (line 10) 50960* UNEQ_EXPR: Unary and Binary Expressions. 50961 (line 6) 50962* UNGE_EXPR: Unary and Binary Expressions. 50963 (line 6) 50964* UNGT_EXPR: Unary and Binary Expressions. 50965 (line 6) 50966* UNION_TYPE <1>: Classes. (line 6) 50967* UNION_TYPE: Types. (line 6) 50968* unions, returning: Interface. (line 10) 50969* UNITS_PER_WORD: Storage Layout. (line 61) 50970* UNKNOWN_TYPE <1>: Types for C++. (line 6) 50971* UNKNOWN_TYPE: Types. (line 6) 50972* UNLE_EXPR: Unary and Binary Expressions. 50973 (line 6) 50974* UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 49) 50975* UNLT_EXPR: Unary and Binary Expressions. 50976 (line 6) 50977* UNORDERED_EXPR: Unary and Binary Expressions. 50978 (line 6) 50979* unshare_all_rtl: Sharing. (line 58) 50980* unsigned division: Arithmetic. (line 129) 50981* unsigned division with unsigned saturation: Arithmetic. (line 129) 50982* unsigned greater than: Comparisons. (line 64) 50983* unsigned less than: Comparisons. (line 68) 50984* unsigned minimum and maximum: Arithmetic. (line 148) 50985* unsigned_fix: Conversions. (line 77) 50986* unsigned_float: Conversions. (line 62) 50987* unsigned_fract_convert: Conversions. (line 97) 50988* unsigned_sat_fract: Conversions. (line 103) 50989* unspec <1>: Constant Definitions. 50990 (line 111) 50991* unspec: Side Effects. (line 300) 50992* unspec_volatile <1>: Constant Definitions. 50993 (line 99) 50994* unspec_volatile: Side Effects. (line 300) 50995* untyped_call instruction pattern: Standard Names. (line 1212) 50996* untyped_return instruction pattern: Standard Names. (line 1276) 50997* UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59) 50998* update_ssa: SSA. (line 74) 50999* update_stmt <1>: SSA Operands. (line 6) 51000* update_stmt: Manipulating GIMPLE statements. 51001 (line 141) 51002* update_stmt_if_modified: Manipulating GIMPLE statements. 51003 (line 144) 51004* UQQmode: Machine Modes. (line 126) 51005* us_ashift: Arithmetic. (line 172) 51006* us_minus: Arithmetic. (line 36) 51007* us_mult: Arithmetic. (line 92) 51008* us_neg: Arithmetic. (line 81) 51009* us_plus: Arithmetic. (line 14) 51010* us_truncate: Conversions. (line 48) 51011* usaddM3 instruction pattern: Standard Names. (line 269) 51012* usadM instruction pattern: Standard Names. (line 382) 51013* USAmode: Machine Modes. (line 167) 51014* usashlM3 instruction pattern: Standard Names. (line 558) 51015* usdivM3 instruction pattern: Standard Names. (line 269) 51016* use: Side Effects. (line 168) 51017* USE_C_ALLOCA: Host Misc. (line 19) 51018* USE_LD_AS_NEEDED: Driver. (line 136) 51019* USE_LOAD_POST_DECREMENT: Costs. (line 234) 51020* USE_LOAD_POST_INCREMENT: Costs. (line 229) 51021* USE_LOAD_PRE_DECREMENT: Costs. (line 244) 51022* USE_LOAD_PRE_INCREMENT: Costs. (line 239) 51023* USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 194) 51024* USE_STORE_POST_DECREMENT: Costs. (line 254) 51025* USE_STORE_POST_INCREMENT: Costs. (line 249) 51026* USE_STORE_PRE_DECREMENT: Costs. (line 264) 51027* USE_STORE_PRE_INCREMENT: Costs. (line 259) 51028* used: Flags. (line 314) 51029* used, in symbol_ref: Flags. (line 197) 51030* user: GTY Options. (line 243) 51031* user gc: User GC. (line 6) 51032* USER_LABEL_PREFIX: Instruction Output. (line 154) 51033* USING_STMT: Statements for C++. (line 6) 51034* usmaddMN4 instruction pattern: Standard Names. (line 510) 51035* usmsubMN4 instruction pattern: Standard Names. (line 534) 51036* usmulhisi3 instruction pattern: Standard Names. (line 478) 51037* usmulM3 instruction pattern: Standard Names. (line 269) 51038* usmulqihi3 instruction pattern: Standard Names. (line 478) 51039* usmulsidi3 instruction pattern: Standard Names. (line 478) 51040* usnegM2 instruction pattern: Standard Names. (line 580) 51041* USQmode: Machine Modes. (line 135) 51042* ussubM3 instruction pattern: Standard Names. (line 269) 51043* usum_widenM3 instruction pattern: Standard Names. (line 392) 51044* UTAmode: Machine Modes. (line 175) 51045* UTQmode: Machine Modes. (line 143) 51046* V in constraint: Simple Constraints. (line 43) 51047* VA_ARG_EXPR: Unary and Binary Expressions. 51048 (line 6) 51049* values, returned by functions: Scalar Return. (line 6) 51050* VAR_DECL: Declarations. (line 6) 51051* var_location: Debug Information. (line 14) 51052* varargs implementation: Varargs. (line 6) 51053* variable: Declarations. (line 6) 51054* Variable Location Debug Information in RTL: Debug Information. 51055 (line 6) 51056* vashlM3 instruction pattern: Standard Names. (line 572) 51057* vashrM3 instruction pattern: Standard Names. (line 572) 51058* vcondMN instruction pattern: Standard Names. (line 214) 51059* vec_concat: Vector Operations. (line 28) 51060* vec_duplicate: Vector Operations. (line 33) 51061* vec_extractM instruction pattern: Standard Names. (line 204) 51062* vec_initM instruction pattern: Standard Names. (line 209) 51063* vec_load_lanesMN instruction pattern: Standard Names. (line 166) 51064* VEC_LSHIFT_EXPR: Vectors. (line 6) 51065* vec_merge: Vector Operations. (line 11) 51066* VEC_PACK_FIX_TRUNC_EXPR: Vectors. (line 6) 51067* VEC_PACK_SAT_EXPR: Vectors. (line 6) 51068* vec_pack_sfix_trunc_M instruction pattern: Standard Names. (line 418) 51069* vec_pack_ssat_M instruction pattern: Standard Names. (line 411) 51070* VEC_PACK_TRUNC_EXPR: Vectors. (line 6) 51071* vec_pack_trunc_M instruction pattern: Standard Names. (line 404) 51072* vec_pack_ufix_trunc_M instruction pattern: Standard Names. (line 418) 51073* vec_pack_usat_M instruction pattern: Standard Names. (line 411) 51074* vec_perm_constM instruction pattern: Standard Names. (line 242) 51075* vec_permM instruction pattern: Standard Names. (line 224) 51076* VEC_RSHIFT_EXPR: Vectors. (line 6) 51077* vec_select: Vector Operations. (line 19) 51078* vec_setM instruction pattern: Standard Names. (line 199) 51079* vec_shr_M instruction pattern: Standard Names. (line 398) 51080* vec_store_lanesMN instruction pattern: Standard Names. (line 188) 51081* VEC_UNPACK_FLOAT_HI_EXPR: Vectors. (line 6) 51082* VEC_UNPACK_FLOAT_LO_EXPR: Vectors. (line 6) 51083* VEC_UNPACK_HI_EXPR: Vectors. (line 6) 51084* VEC_UNPACK_LO_EXPR: Vectors. (line 6) 51085* vec_unpacks_float_hi_M instruction pattern: Standard Names. 51086 (line 440) 51087* vec_unpacks_float_lo_M instruction pattern: Standard Names. 51088 (line 440) 51089* vec_unpacks_hi_M instruction pattern: Standard Names. (line 425) 51090* vec_unpacks_lo_M instruction pattern: Standard Names. (line 425) 51091* vec_unpacku_float_hi_M instruction pattern: Standard Names. 51092 (line 440) 51093* vec_unpacku_float_lo_M instruction pattern: Standard Names. 51094 (line 440) 51095* vec_unpacku_hi_M instruction pattern: Standard Names. (line 433) 51096* vec_unpacku_lo_M instruction pattern: Standard Names. (line 433) 51097* VEC_WIDEN_MULT_HI_EXPR: Vectors. (line 6) 51098* VEC_WIDEN_MULT_LO_EXPR: Vectors. (line 6) 51099* vec_widen_smult_even_M instruction pattern: Standard Names. 51100 (line 449) 51101* vec_widen_smult_hi_M instruction pattern: Standard Names. (line 449) 51102* vec_widen_smult_lo_M instruction pattern: Standard Names. (line 449) 51103* vec_widen_smult_odd_M instruction pattern: Standard Names. (line 449) 51104* vec_widen_sshiftl_hi_M instruction pattern: Standard Names. 51105 (line 460) 51106* vec_widen_sshiftl_lo_M instruction pattern: Standard Names. 51107 (line 460) 51108* vec_widen_umult_even_M instruction pattern: Standard Names. 51109 (line 449) 51110* vec_widen_umult_hi_M instruction pattern: Standard Names. (line 449) 51111* vec_widen_umult_lo_M instruction pattern: Standard Names. (line 449) 51112* vec_widen_umult_odd_M instruction pattern: Standard Names. (line 449) 51113* vec_widen_ushiftl_hi_M instruction pattern: Standard Names. 51114 (line 460) 51115* vec_widen_ushiftl_lo_M instruction pattern: Standard Names. 51116 (line 460) 51117* vector: Containers. (line 6) 51118* vector operations: Vector Operations. (line 6) 51119* VECTOR_CST: Constant expressions. 51120 (line 6) 51121* VECTOR_STORE_FLAG_VALUE: Misc. (line 294) 51122* verify_flow_info: Maintaining the CFG. 51123 (line 119) 51124* virtual operands: SSA Operands. (line 6) 51125* VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59) 51126* VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87) 51127* VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78) 51128* VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69) 51129* VLIW: Processor pipeline description. 51130 (line 6) 51131* vlshrM3 instruction pattern: Standard Names. (line 572) 51132* VMS: Filesystem. (line 37) 51133* VMS_DEBUGGING_INFO: VMS Debug. (line 9) 51134* void: Misc. (line 687) 51135* VOID_TYPE: Types. (line 6) 51136* VOIDmode: Machine Modes. (line 193) 51137* volatil: Flags. (line 328) 51138* volatil, in insn, call_insn, jump_insn, code_label, jump_table_data, barrier, and note: Flags. 51139 (line 44) 51140* volatil, in label_ref and reg_label: Flags. (line 65) 51141* volatil, in mem, asm_operands, and asm_input: Flags. (line 76) 51142* volatil, in reg: Flags. (line 98) 51143* volatil, in subreg: Flags. (line 170) 51144* volatil, in symbol_ref: Flags. (line 206) 51145* volatile memory references: Flags. (line 329) 51146* volatile, in prefetch: Flags. (line 214) 51147* voting between constraint alternatives: Class Preferences. (line 6) 51148* vrotlM3 instruction pattern: Standard Names. (line 572) 51149* vrotrM3 instruction pattern: Standard Names. (line 572) 51150* walk_dominator_tree: SSA. (line 228) 51151* walk_gimple_op: Statement and operand traversals. 51152 (line 32) 51153* walk_gimple_seq: Statement and operand traversals. 51154 (line 50) 51155* walk_gimple_stmt: Statement and operand traversals. 51156 (line 13) 51157* WCHAR_TYPE: Type Layout. (line 172) 51158* WCHAR_TYPE_SIZE: Type Layout. (line 180) 51159* which_alternative: Output Statement. (line 59) 51160* WHILE_BODY: Statements for C++. (line 6) 51161* WHILE_COND: Statements for C++. (line 6) 51162* WHILE_STMT: Statements for C++. (line 6) 51163* whopr: LTO. (line 6) 51164* WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 117) 51165* window_save instruction pattern: Standard Names. (line 1572) 51166* WINT_TYPE: Type Layout. (line 185) 51167* word_mode: Machine Modes. (line 368) 51168* WORD_REGISTER_OPERATIONS: Misc. (line 54) 51169* WORDS_BIG_ENDIAN: Storage Layout. (line 29) 51170* WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 217) 51171* wpa: LTO. (line 6) 51172* X in constraint: Simple Constraints. (line 124) 51173* x-HOST: Host Fragment. (line 6) 51174* XCmode: Machine Modes. (line 200) 51175* XCOFF_DEBUGGING_INFO: DBX Options. (line 13) 51176* XEXP: Accessors. (line 6) 51177* XFmode: Machine Modes. (line 82) 51178* XImode: Machine Modes. (line 54) 51179* XINT: Accessors. (line 6) 51180* xm-MACHINE.h <1>: Host Misc. (line 6) 51181* xm-MACHINE.h: Filesystem. (line 6) 51182* xor: Arithmetic. (line 167) 51183* xor, canonicalization of: Insn Canonicalizations. 51184 (line 79) 51185* xorM3 instruction pattern: Standard Names. (line 269) 51186* XSTR: Accessors. (line 6) 51187* XVEC: Accessors. (line 41) 51188* XVECEXP: Accessors. (line 48) 51189* XVECLEN: Accessors. (line 44) 51190* XWINT: Accessors. (line 6) 51191* zero_extend: Conversions. (line 28) 51192* zero_extendMN2 instruction pattern: Standard Names. (line 980) 51193* zero_extract: Bit-Fields. (line 30) 51194* zero_extract, canonicalization of: Insn Canonicalizations. 51195 (line 88) 51196 51197 51198 51199Tag Table: 51200Node: Top1842 51201Node: Contributing5024 51202Node: Portability5765 51203Node: Interface7553 51204Node: Libgcc10593 51205Node: Integer library routines12434 51206Node: Soft float library routines19402 51207Node: Decimal float library routines31339 51208Node: Fixed-point fractional library routines47096 51209Node: Exception handling routines147494 51210Node: Miscellaneous routines148601 51211Node: Languages150721 51212Node: Source Tree152270 51213Node: Configure Terms152852 51214Node: Top Level155810 51215Node: gcc Directory159296 51216Node: Subdirectories160246 51217Node: Configuration162413 51218Node: Config Fragments163133 51219Node: System Config164362 51220Node: Configuration Files165298 51221Node: Build168123 51222Node: Makefile168535 51223Ref: Makefile-Footnote-1175338 51224Ref: Makefile-Footnote-2175483 51225Node: Library Files175555 51226Node: Headers176117 51227Node: Documentation178200 51228Node: Texinfo Manuals179059 51229Node: Man Page Generation181392 51230Node: Miscellaneous Docs183307 51231Node: Front End184701 51232Node: Front End Directory188394 51233Node: Front End Config189714 51234Node: Front End Makefile192540 51235Node: Back End196322 51236Node: Testsuites200119 51237Node: Test Idioms201050 51238Node: Test Directives204447 51239Node: Directives204974 51240Node: Selectors215284 51241Node: Effective-Target Keywords216642 51242Ref: arm_neon_ok224510 51243Ref: arm_neonv2_ok224668 51244Ref: arm_neon_fp16_ok224840 51245Ref: arm_vfp3_ok225280 51246Node: Add Options235808 51247Node: Require Support237125 51248Node: Final Actions239632 51249Node: Ada Tests244799 51250Node: C Tests246131 51251Node: libgcj Tests250554 51252Node: LTO Testing251681 51253Node: gcov Testing253328 51254Node: profopt Testing256315 51255Node: compat Testing258030 51256Node: Torture Tests262270 51257Node: Options263887 51258Node: Option file format264327 51259Node: Option properties271317 51260Node: Passes284875 51261Node: Parsing pass285765 51262Node: Cilk Plus Transformation289300 51263Node: Gimplification pass292687 51264Node: Pass manager294532 51265Node: Tree SSA passes296377 51266Node: RTL passes317576 51267Node: Optimization info329897 51268Node: Dump setup330715 51269Node: Optimization groups331837 51270Node: Dump files and streams332720 51271Node: Dump output verbosity333911 51272Node: Dump types334962 51273Node: Dump examples336452 51274Node: GENERIC337794 51275Node: Deficiencies339669 51276Node: Tree overview339910 51277Node: Macros and Functions344037 51278Node: Identifiers344862 51279Node: Containers346473 51280Node: Types347630 51281Node: Declarations359726 51282Node: Working with declarations360221 51283Node: Internal structure365827 51284Node: Current structure hierarchy366211 51285Node: Adding new DECL node types368305 51286Node: Attributes372590 51287Node: Expression trees373835 51288Node: Constant expressions375588 51289Node: Storage References378894 51290Node: Unary and Binary Expressions382413 51291Node: Vectors402564 51292Node: Statements407755 51293Node: Basic Statements408287 51294Node: Blocks412794 51295Node: Statement Sequences414198 51296Node: Empty Statements414531 51297Node: Jumps415105 51298Node: Cleanups415758 51299Node: OpenMP417526 51300Node: OpenACC423361 51301Node: Functions424393 51302Node: Function Basics424864 51303Node: Function Properties428549 51304Node: Language-dependent trees431331 51305Node: C and C++ Trees432217 51306Node: Types for C++435121 51307Node: Namespaces440099 51308Node: Classes443206 51309Node: Functions for C++448284 51310Node: Statements for C++454537 51311Node: C++ Expressions463307 51312Node: Java Trees464808 51313Node: GIMPLE464921 51314Node: Tuple representation468583 51315Node: Class hierarchy of GIMPLE statements475561 51316Node: GIMPLE instruction set480564 51317Node: GIMPLE Exception Handling482248 51318Node: Temporaries484162 51319Ref: Temporaries-Footnote-1485477 51320Node: Operands485540 51321Node: Compound Expressions486302 51322Node: Compound Lvalues486536 51323Node: Conditional Expressions487298 51324Node: Logical Operators487956 51325Node: Manipulating GIMPLE statements494821 51326Node: Tuple specific accessors500755 51327Node: `GIMPLE_ASM'501592 51328Node: `GIMPLE_ASSIGN'503980 51329Node: `GIMPLE_BIND'508690 51330Node: `GIMPLE_CALL'510509 51331Node: `GIMPLE_CATCH'514542 51332Node: `GIMPLE_COND'515698 51333Node: `GIMPLE_DEBUG'518499 51334Node: `GIMPLE_EH_FILTER'521883 51335Node: `GIMPLE_LABEL'523452 51336Node: `GIMPLE_GOTO'524071 51337Node: `GIMPLE_NOP'524600 51338Node: `GIMPLE_OMP_ATOMIC_LOAD'524968 51339Node: `GIMPLE_OMP_ATOMIC_STORE'525970 51340Node: `GIMPLE_OMP_CONTINUE'526674 51341Node: `GIMPLE_OMP_CRITICAL'528159 51342Node: `GIMPLE_OMP_FOR'529158 51343Node: `GIMPLE_OMP_MASTER'532580 51344Node: `GIMPLE_OMP_ORDERED'532963 51345Node: `GIMPLE_OMP_PARALLEL'533363 51346Node: `GIMPLE_OMP_RETURN'536139 51347Node: `GIMPLE_OMP_SECTION'536789 51348Node: `GIMPLE_OMP_SECTIONS'537455 51349Node: `GIMPLE_OMP_SINGLE'539070 51350Node: `GIMPLE_PHI'540021 51351Node: `GIMPLE_RESX'541305 51352Node: `GIMPLE_RETURN'542030 51353Node: `GIMPLE_SWITCH'542610 51354Node: `GIMPLE_TRY'544489 51355Node: `GIMPLE_WITH_CLEANUP_EXPR'546266 51356Node: GIMPLE sequences547149 51357Node: Sequence iterators550355 51358Node: Adding a new GIMPLE statement code558813 51359Node: Statement and operand traversals560188 51360Node: Tree SSA562788 51361Node: Annotations564574 51362Node: SSA Operands564979 51363Node: SSA579059 51364Node: Alias analysis590091 51365Node: Memory model593871 51366Node: RTL595234 51367Node: RTL Objects597422 51368Node: RTL Classes601296 51369Node: Accessors606343 51370Node: Special Accessors608737 51371Node: Flags614507 51372Node: Machine Modes629269 51373Node: Constants642921 51374Node: Regs and Memory651007 51375Node: Arithmetic668908 51376Node: Comparisons678961 51377Node: Bit-Fields683253 51378Node: Vector Operations684805 51379Node: Conversions686687 51380Node: RTL Declarations691185 51381Node: Side Effects692006 51382Node: Incdec709021 51383Node: Assembler712356 51384Node: Debug Information713901 51385Node: Insns715099 51386Node: Calls741533 51387Node: Sharing744126 51388Node: Reading RTL747236 51389Node: Control Flow748228 51390Node: Basic Blocks749996 51391Node: Edges755452 51392Node: Profile information764084 51393Node: Maintaining the CFG768768 51394Node: Liveness information774631 51395Node: Loop Analysis and Representation776757 51396Node: Loop representation777867 51397Node: Loop querying785432 51398Node: Loop manipulation788265 51399Node: LCSSA790633 51400Node: Scalar evolutions792705 51401Node: loop-iv795949 51402Node: Number of iterations797875 51403Node: Dependency analysis800684 51404Node: Omega807051 51405Node: Machine Desc808627 51406Node: Overview811190 51407Node: Patterns813231 51408Node: Example816739 51409Node: RTL Template818200 51410Node: Output Template828856 51411Node: Output Statement832821 51412Node: Predicates837160 51413Node: Machine-Independent Predicates840078 51414Node: Defining Predicates845023 51415Node: Constraints850988 51416Node: Simple Constraints852457 51417Node: Multi-Alternative865313 51418Node: Class Preferences868440 51419Node: Modifiers869332 51420Node: Machine Constraints874064 51421Node: Disable Insn Alternatives931767 51422Node: Define Constraints935256 51423Node: C Constraint Interface942043 51424Node: Standard Names945183 51425Ref: shift patterns970065 51426Ref: prologue instruction pattern1015352 51427Ref: window_save instruction pattern1015845 51428Ref: epilogue instruction pattern1016120 51429Node: Pattern Ordering1033691 51430Node: Dependent Patterns1034927 51431Node: Jump Patterns1036547 51432Ref: Jump Patterns-Footnote-11038691 51433Node: Looping Patterns1038737 51434Node: Insn Canonicalizations1043465 51435Node: Expander Definitions1048056 51436Node: Insn Splitting1056268 51437Node: Including Patterns1065870 51438Node: Peephole Definitions1067650 51439Node: define_peephole1068903 51440Node: define_peephole21075234 51441Node: Insn Attributes1078300 51442Node: Defining Attributes1079482 51443Ref: define_enum_attr1082970 51444Node: Expressions1084005 51445Node: Tagging Insns1090754 51446Node: Attr Example1095107 51447Node: Insn Lengths1097481 51448Node: Constant Attributes1100889 51449Node: Mnemonic Attribute1102065 51450Node: Delay Slots1103584 51451Node: Processor pipeline description1106807 51452Ref: Processor pipeline description-Footnote-11125620 51453Node: Conditional Execution1125942 51454Node: Define Subst1129422 51455Node: Define Subst Example1131456 51456Node: Define Subst Pattern Matching1134450 51457Node: Define Subst Output Template1135675 51458Node: Constant Definitions1137745 51459Ref: define_enum1141527 51460Node: Iterators1142015 51461Node: Mode Iterators1142593 51462Node: Defining Mode Iterators1143571 51463Node: Substitutions1145065 51464Node: Examples1147306 51465Node: Code Iterators1148754 51466Node: Int Iterators1151033 51467Node: Subst Iterators1153476 51468Node: Target Macros1155168 51469Node: Target Structure1158180 51470Node: Driver1160295 51471Node: Run-time Target1179105 51472Node: Per-Function Data1188803 51473Node: Storage Layout1191568 51474Node: Type Layout1217341 51475Node: Registers1230971 51476Node: Register Basics1231945 51477Node: Allocation Order1237380 51478Node: Values in Registers1239868 51479Node: Leaf Functions1247357 51480Node: Stack Registers1250215 51481Node: Register Classes1251487 51482Node: Stack and Calling1283895 51483Node: Frame Layout1284461 51484Node: Exception Handling1295433 51485Node: Stack Checking1301653 51486Node: Frame Registers1306464 51487Node: Elimination1314729 51488Node: Stack Arguments1318956 51489Node: Register Arguments1326137 51490Node: Scalar Return1347195 51491Node: Aggregate Return1353651 51492Node: Caller Saves1357839 51493Node: Function Entry1358582 51494Node: Profiling1369684 51495Node: Tail Calls1371798 51496Node: Stack Smashing Protection1373699 51497Node: Miscellaneous Register Hooks1375362 51498Node: Varargs1376228 51499Node: Trampolines1386350 51500Node: Library Calls1392393 51501Node: Addressing Modes1397077 51502Node: Anchored Addresses1418019 51503Node: Condition Code1420668 51504Node: CC0 Condition Codes1422995 51505Node: MODE_CC Condition Codes1426241 51506Node: Costs1433046 51507Node: Scheduling1449913 51508Node: Sections1473097 51509Node: PIC1488790 51510Node: Assembler Format1490850 51511Node: File Framework1491988 51512Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS1498929 51513Node: Data Output1502194 51514Node: Uninitialized Data1510147 51515Node: Label Output1515158 51516Node: Initialization1538516 51517Node: Macros for Initialization1544478 51518Node: Instruction Output1551201 51519Node: Dispatch Tables1561836 51520Node: Exception Region Output1566236 51521Node: Alignment Output1573264 51522Node: Debugging Info1577866 51523Node: All Debuggers1578536 51524Node: DBX Options1581391 51525Node: DBX Hooks1586840 51526Node: File Names and DBX1588149 51527Node: SDB and DWARF1590261 51528Node: VMS Debug1596521 51529Node: Floating Point1597108 51530Node: Mode Switching1601000 51531Node: Target Attributes1605433 51532Node: Emulated TLS1614143 51533Node: MIPS Coprocessors1617533 51534Node: PCH Target1618692 51535Node: C++ ABI1620534 51536Node: Named Address Spaces1625326 51537Node: Misc1630240 51538Ref: TARGET_SHIFT_TRUNCATION_MASK1636977 51539Node: Host Config1693679 51540Node: Host Common1694747 51541Node: Filesystem1697126 51542Node: Host Misc1701241 51543Node: Fragments1703690 51544Node: Target Fragment1704885 51545Node: Host Fragment1715518 51546Node: Collect21715758 51547Node: Header Dirs1718394 51548Node: Type Information1719817 51549Node: GTY Options1723097 51550Node: Inheritance and GTY1734745 51551Ref: Inheritance and GTY-Footnote-11736308 51552Node: User GC1736576 51553Node: GGC Roots1740311 51554Node: Files1741027 51555Node: Invoking the garbage collector1743734 51556Node: Troubleshooting1745237 51557Node: Plugins1746313 51558Node: Plugins loading1747442 51559Node: Plugin API1748311 51560Node: Plugins pass1755870 51561Node: Plugins GC1757839 51562Node: Plugins description1759554 51563Node: Plugins attr1760089 51564Node: Plugins recording1762360 51565Node: Plugins gate1763210 51566Node: Plugins tracking1763801 51567Node: Plugins building1764389 51568Node: LTO1766178 51569Node: LTO Overview1767050 51570Node: LTO object file layout1772882 51571Node: IPA1777514 51572Node: WHOPR1786479 51573Node: Internal flags1791170 51574Node: Match and Simplify1792582 51575Node: GIMPLE API1793543 51576Node: The Language1796165 51577Node: Funding1805014 51578Node: GNU Project1807512 51579Node: Copying1808161 51580Node: GNU Free Documentation License1845692 51581Node: Contributors1870832 51582Node: Option Index1909603 51583Node: Concept Index1910480 51584 51585End Tag Table 51586